Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1997-10-15
2001-02-06
Feild, Joseph H. (Department: 2776)
Data processing: database and file management or data structures
Database design
Data structure types
C345S215000
Reexamination Certificate
active
06185590
ABSTRACT:
FIELD OF THE INVENTION
The present invention is generally related to a computer architecture and process for image viewing in a stand-alone and/or distributed environment, and more particularly to a computer architecture and process for image viewing 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 “C”-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 “C” 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.
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.
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 represents any set of features/functions on the other side. The component factory migrates the original “C”-level API from its original state into the generic interface defined by the topmost layer. The first feature that can be demonstrated is that there is a topmost layer that can define a component interface that can represent the features/functions of most core technologies.
The component factory migrates the “C”-level API to the topmost level. Doing this in one large step would be impossible since the “C”-level API has a near-infinite variety of styles. However, the architecture advantageously has enough well-defined and well-structured layers for implementing the topmost component interface, for creating the component factory.
The computer architecture is designed for managing a diverse set of independent core technologies (“engines”) using a single consistent framework. The architecture balances two seemingly opposing requirements: the need to provide a single consistent interface to many different engines with the ability to access the unique features of each engine.
The benefit of the architecture is that it enables a company to rapidly “wrap” a sophisticated technology so that other high-level developers can easily learn and implement the core technology. The computer architecture is therefore a middleware or enabling technology.
Another benefit of the architecture is that it provides a high-level specification for a consistent interface to any core technology. Once a high-level developer learns the interface described herein for one engine, that knowledge is easily transferable to other engines that are implemented using the architecture. For example, once a high-level developer learns to use the computer architecture for OCR (Optical Character Recognition), using the computer architecture for other engines, such as barcode recognition or forms processing, is trivial.
The architect
Donner Irah H.
Feild Joseph H.
Hale and Dorr LLP
Imagination Software
Kindred Alford W.
LandOfFree
Process and architecture for use on stand-alone machine and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Process and architecture for use on stand-alone machine and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Process and architecture for use on stand-alone machine and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2575578