Data processing: presentation processing of document – operator i – Presentation processing of document – Layout
Reexamination Certificate
1999-04-14
2003-12-02
Feild, Joseph H. (Department: 2176)
Data processing: presentation processing of document, operator i
Presentation processing of document
Layout
C715S252000, C341S050000, C709S246000, C708S204000
Reexamination Certificate
active
06658625
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to converting data between formats or types. More specifically, this invention relates to a generic data convertor that uses a data description to convert data.
2. Background Art
Modem computer systems vary in their design and architecture, with many different models available to achieve the desired combination of speed, power and efficiency for any given computing environment. This multitude of different computing environments allows a consumer to select the right computer for a particular job. For instance, an engineering firm might need a computer aided design station, which necessitates a very powerful, fast computer. Meanwhile, a home user might simply want to connect to the Internet to send and receive email, which does not require a fast computer. Thus, the proliferation of different computing environments has,.been beneficial.
There are drawbacks to this multitude of computer systems, however. Because each computer system (and the operating systems on those computer systems) are designed differently, the way that data is actually stored on each computer system may be different. For instance, how an “integer” (a whole number such as 0, 1, 2, etc.) is stored on one computer may be different than how integers are stored on another computer: some computers store integers in a “Little Endian” format, while other computers store them in a “Big Endian” format. Character (letters of the alphabet) data is another common data type that can be stored differently: some computers store characters as ASCII (American Standard Code for Information Interchange) data; other computers use EBCDIC (Extended Binary Coded Decimal Interchange Code) data; and many current computers and operating systems use Unicode. These exemplary differences between the way data is stored on one computer and the way the same data is stored on another computer require that the data be converted into the correct format for the computer or operating system that desires the information.
Data taken or received from one computer will generally be stored (perhaps on the second computer or on a data medium such as a disk) as a series of bytes, words, or double words, depending on the format of the medium holding the data. This data is then converted, usually by a “hard-coded” program, from one format to the proper format required for the computer requesting the data. This program is written to “know” where every data element in the data is and how to convert each data element to the format that the requesting computer requires. Once the data is received or the program is asked to convert the data, the program converts all of the data elements from the format they are in to the format required by the requesting computer. If the data changes in some way, however, the program must be modified or rewritten to deal with the changes. For instance, if the data is the output of a database, and the database is changed to add additional data elements, the program must be modified to know where these new data elements are, what format they are in, and how to convert the data elements to the correct formats. This process of rewriting and modifying data conversion programs can be tedious and time consuming.
This is especially true for dissimilar computers that are connected in a client-server architecture. Many networks have “client-server” architectures that allow many clients to connect to one or more servers. With this architecture comes many benefits. For instance, files and other data may be placed on the server and accessed by the clients; devices such as printers or scanners may be connected to the server and used by the clients; and programs may reside on the server that can be accessed and executed by the clients.
Placing programs on the server is felicitous because servers are typically much faster and have much more storage space than clients. This is important for programs that involve complex calculations or a tremendous amount of data, as servers tend to outperform clients in these applications. In addition, because the data is then generally stored along with the application on the server, the server can provide a convenient and secure location to and from which database information may be accessed. For instance, having airline ticket information stored on the server allows ticketing agencies around the world to determine which seats are open on which flights. By storing the data on the server, data coherency can be more easily maintained, which assures that only one person is sold a ticket for a particular seat.
When the client calls a server program or Application Programming Interface (API), the program or API will usually return a set of values. The number of values that the program or API may return can change. For instance, if the program is returning a list of the available seats on an airline flight, the number of seats can vary from zero (the flight is completely booked) to the capacity of the plane (there have been no seats sold). This may become more complex if the seats are further divided into categories such as isle or window seats, first and second class seats, the type of dinners available, etc. Along with changing the actual data types to reflect the differences in data storage between the client and the server, a client application must also decipher the actual varying length data received from the server program or API. In addition, some servers like to store and send data on “boundaries,” meaning that there may be extraneous data at the end of a data set that is there just to ensure that data exists on these boundaries. These extraneous data must be skipped to get to actual data.
Thus, the client application must search through the data received from the server program (or API) and extract the needed information. The server program helps this process somewhat by providing information in the stream of data that it is sending; this information tells the client program a bit about how the data is structured. For instance, the server program might send the number 20 and then 20 seat positions. The number 20 would indicate that there are 20 seats that follow. The client application, upon receiving the “20”, would then know that 20 seats follow.
In this manner, client applications can be made to read and convert varying length data returned from server programs. Unfortunately, such applications are, as explained previously, then “hard coded” with the data format and structure. If the data format changes (a different server is used that stores the data differently than the previous server) or if the data structure changes (a third class of seats is added, for instance)+then the application must be modified to adapt to these changes. Modifying applications in this manner can, as stated previously, be very costly and complex.
While allowing computers of different architectures to exchange data provides added speed, security, consumer choice, and connectivity, data conversion between different systems can be problematic. Without a method for allowing easy and quick modifications when data structures or servers change, client and data conversion applications will continue to need to be rewritten to allow for such data changes.
DISCLOSURE OF INVENTION
The preferred embodiments of the present invention provide a method and apparatus for generic data conversion. A generic data convertor interprets a data description that has configurable data definitions that can accommodate changes in the data. The data definitions can allow the data type, character set, location, and length of data elements in the data stream or file to be easily modified. The data convertor uses the data description to determine how to convert the data and, if necessary, where data elements are in the data. The data convertor is particularly useful for converting data that is sent to and/or received from a server. The data convertor and data description cooperate to support calling multiple releases of the server using the same data description. In addit
Bieneman Charles
Feild Joseph H.
International Business Machines - Corporation
Schmeiser Olsen & Watts LLP
LandOfFree
Apparatus and method for generic data conversion does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for generic data conversion, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for generic data conversion will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3170465