Facsimile and static presentation processing – Static presentation processing – Communication
Reexamination Certificate
1999-11-12
2004-08-03
Evans, Arthur G. (Department: 2622)
Facsimile and static presentation processing
Static presentation processing
Communication
C358S001100
Reexamination Certificate
active
06771381
ABSTRACT:
FIELD OF THE INVENTION
The present invention is generally related to a computer architecture and process for stand-alone and/or distributed environment, and more particularly to a computer architecture and process using a substantially uniform management in a stand-alone and/or distributed computing environment including, for example, client server and/or intranet and/or internet operating environments.
BACKGROUND OF THE RELATED ART
A “C” or “C++”- Level API (hereinafter “C” Level), which is the native language and interface for a vast repository of core technologies from small software vendors and research laboratories, are unique to each designer. The designer of a text retrieval “C”-API will generally implement an interface that is completely different than a second inventor creating a “C”-level API for OCR.
Every “C”-level API is unique, both in its choice of API syntax as well as its method for implementing the syntax. Some API's consist of one or two functions that take parameters offering options for different features offered by the technology. Other APIs consist of hundreds of functions with few arguments, where each function is associated with a particular feature of the core technology. Other APIs provide a mixture of some features being combined with one function with many arguments, while other features are separated into individual function calls.
Without any constraints, each designer of a core technology chooses to implement his or her technology with an interface that is suitable to the subject or simply was the most expedient choice of the moment. Since there are no constraints, a “IC”-level API has a totally unpredictable interface that can often be the hindrance to using the core technology.
Additionally, every API manages errors differently further complicating the problems described above. Some APIs return a consistent error code for each function. Error management in this case is very organized and manageable. Other APIs return error codes as one of the parameters passed to the function. There are APIs that mix the choice of error management and have some functions return an error code while other functions pass the error code as a parameter of a function. Errors can also be managed by a callback function, eliminating the need for passing any error code as part of the function. In some instances of a poorly implemented API the errors are not passed back at all.
Every engine, such as a text retrieval or an OCR (Optical Character Recognition) engine, has a unique interface. This interface is generally a “C”-level API (Application Program Interface). Further, an API can at any time be synchronous, asynchronous, manage one or more callbacks, require input, pass back output, carry a variety of different styles of functions, return values or not return values, and implement the unpredictable. This unpredictability in APIs further compounds the problem of developing a sane way of interfacing between components and APIs.
To date, because of the complexities of “C”-level APIs and components interfacing thereto, the only way to create a component out of an existing “C”-level API is to have an experienced programmer in the field to do the work. Humans can intelligently analyze an API, and create a component based on intelligent decisions and experiences. In most cases, the learning curve for understanding and integrating a new engine can be one man-month to several man-years and generally requires highly experienced “IC” programmers. Requiring a human to perform the necessary work is costly, and subject to real-life human constraints.
Since there is no structure or format for implementing “C”-level APIs, the ability to automatically transform a unique API into a standard component would seem impossible, since that would take a nearly-human level of intelligence.
In addition, in spite of the continued automation of business processes, companies are increasing their paper use by 25-30% and spending up to 15% of their total budget on managing paper. Companies are often running dual processes—a computerized process along with the corresponding paper filing system—and paying an extraordinary price for it. Just a few examples will illustrate the problem: 1) accounting clerks are maintaining paper invoices with information that is also being re-keyed into accounting systems, 2) administrative assistants are filing incoming correspondence in cabinets for customers whose records are also being electronically maintained by contact management systems, 3) help desk operators are storing complaints sent in on paper while also tracking those complaints in a computerized system. Additional industry trends include the following:
For every $100M in increased revenues, a company will use 8.8 million additional pages of paper
The Document Management market is expected to grow at 30% per year
The digital device market is growing at 20% per year
Estimates show the web-based document imaging market growing at 50% per year
The digital device manufacturers, especially the copier companies, are heavily promoting the ability to connect their devices to networks, but have not been able to deliver an effective software solution to date.
Businesses continue to automate more processes, but managing the associated paper is often ignored, resulting in inefficiency and higher costs.
I have determined that a component factory, if it is to be truly automated or manually expedited, must be able to take any “C”-level API and transform it into a component.
I have also determined an efficient and workable design for an architecture to define the migration path for any “C”-level API into a component.
I have also determined that it is desirable to develop software tools for automatically generating reusable software components from core software technologies, thus making these software technologies available to a much larger user base.
I have further determined that it is desirable to design a distributed computer architecture and process for manually and/or automatically generating reusable software components. The computer architecture may be implemented using a client server and/or intranet and/or internet operating environments.
I have further determined that it is desirable to design a computer architecture and process for image viewing in a stand-alone and/or distributed environment. The computer architecture and process optionally uses a substantially uniform management layer in a stand-alone and/or distributed computing environment including, for example, client server and/or intranet and/or internet operating environments.
I have further determined that it is desirable to enable a typical PC user to add electronic paper processing to their existing business process.
I have further determined that it is desirable to enable software that manages paper so that it can be electronically and seamlessly copied in and out of devices and business applications (such as Microsoft Office, Microsoft Exchange, Lotus Notes) with an optional single-step Go operation.
SUMMARY OF THE INVENTION
One would expect the translating a “C”-level API from its native state into a component would require human-level intelligence. This is mainly because “C”-level APIs have virtually no constraints as to how they can be implemented. This means that there are an infinity variations of APIs, which can only be managed by human-level intelligence. While this point is true, I have determined that the appropriate solution starts at the other side of the equation, which is the component itself.
My solution starts out with a definition of a component that can sustain the feature/function requirements of any API. In other words, the interface of a generic component can be defined such that the features and functions of virtually any API can be re-implemented within its bounds. The two known end-points are, for example, the “C”-level API that generally starts with each component (although other programming languages may also be used and are within the scope of the present invention), and the component interface that repr
Donner, Esq. Irah H.
Evans Arthur G.
Wilmer, Cutter, Pickering Hale and Dorr LLP
LandOfFree
Distributed computer architecture and process for virtual... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Distributed computer architecture and process for virtual..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Distributed computer architecture and process for virtual... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3339011