An overview of object-oriented programming techniques used for storing, managing and sharing objects in a computer system

The following quoted text (beginning at the bullet) is taken from the statement of prior art in US Patent 5,682,532 entitled System and method having programmable containers with functionality for managing objects and filed in 1994 by Microsoft Corporation.

• "Permanent storage devices of conventional computer systems are arranged in a hierarchical fashion. This hierarchy is formed through the use of directories or folders. A folder is a logical grouping of files and other folders. When a user wishes to store information on the permanent storage device of a computer system, the user creates a folder and moves, copies, or creates files in the folder. The functionality associated with a folder is typically defined by a computer system. This functionality may include simply adding and deleting files of a folder. Thus, in conventional computer systems, the user has little control over the functionality of the folder. For example, a user cannot typically restrict the types of files that are stored in a folder nor can a user modify a folder so that all users must observe a checkin-checkout protocol when accessing the files in the folder.
  
  The present invention is described below using some object-oriented techniques; thus, an overview of well-known object-oriented programming techniques is provided. Two common characteristics of object-oriented programming languages are support for data encapsulation and data type inheritance. Data encapsulation refers to the binding of functions and data. Inheritance refers to the ability to declare a data type in terms of other data types. In the C++ language, data encapsulation and inheritance are supported through the use of classes. A class is a user-defined type. A class declaration describes the data members and function members of the class. A function member is also referred to as a method of a class. The data members and function members of a class are bound together in that the function operates on an instance of the class. An instance of a class is also called an object of the class. Thus, a class provides a definition for a group of objects with similar properties and common behavior.
  
  To allocate storage for an object of a particular type (class), an object is instantiated. Once instantiated, data can be assigned to the data members of the particular object. Also, once instantiated, the function members of the particular object can be invoked to access and manipulate the data members. Thus, in this manner, the function members implement the behavior of the object, and the object provides a structure for encapsulating data and behavior into a single entity.
  
  To support the concept of inheritance, classes may be derived from (based upon the declaration of) other classes. A derived class is a class that inherits the characteristics--data members and function members--of its base classes. A class that inherits the characteristics of another class is a derived class. A class that does not inherit the characteristics of another class is a primary (root) class. A class whose characteristics are inherited by another class is a base class. A derived class may inherit the characteristics of several classes; that is, a derived class may have several base classes. This is referred to as multiple inheritance.
  
  A class may also specify whether its function members are virtual. Declaring that a function member is virtual means that the function can be overridden by a function of the same name and type in a derived class. If a virtual function is declared without providing an implementation, then it is referred to as a pure virtual function. A pure virtual function is a virtual function declared with the pure specifier, "=0". If a class specifies a pure virtual function, then any derived class needs to specify an implementation for that function member before that function member may be invoked. A class which contains at least one pure virtual function member is an abstract class.
  
  [Original image modified for size and/or readability]FIG. 1 is a block diagram illustrating typical data structures used to represent an object. An object is composed of instance data (data members) and function members, which implement the behavior of the object. The data structures used to represent an object comprise instance data structure 101, virtual function table 102, and the function members 103, 104, 105. The instance data structure 101 contains a pointer to the virtual function table 102 and contains data members. The virtual function table 102 contains an entry for each virtual function member defined for the object. Each entry contains a reference to the code that implements the corresponding function member. The layout of this sample object conforms to models defined in U.S. Pat. No. 5,297,284, entitled "A Method for Implementing Virtual Functions and Virtual Bases in a Compiler for an Object Oriented Programming Language," which is hereby incorporated by reference. In the following, an object will be described as an instance of a class as defined by the C++ programming language. One skilled in the art would appreciate that other object models can be defined using other programming languages.
  
  An advantage of using object-oriented techniques is that these techniques can be used to facilitate the sharing of objects. For example, a program implementing the function members of an instantiated object (a "server program") can share the object with another program (a "client program"). To allow an object of an arbitrary class to be shared with a client program, interfaces are defined through which an object can be accessed without the need for the client program to have access to the class definitions at compile time. An interface is a named set of logically related function members ("methods) and data members ("properties"). In C++, an interface is an abstract class with no data members and whose virtual functions are all pure. Thus, an interface provides a published protocol for two programs to communicate. Interfaces are typically used for derivation: a program defines (implements) classes that provide implementations for the interfaces the classes are derived from. Thereafter, objects are created as instances of these derived classes. Objects instantiated from a derived class implementing particular interfaces are said to "support" the interfaces. An object supports one or more interfaces depending upon the desired functionality.
  
  When a client program desires to share an object, the client program needs access to the code that implements the interfaces for the object (the derived class code). To access the derived class code (also referred to as class code), each class implementation is given a unique class identifier (a "CLSID"). For example, code implementing a spreadsheet object developed by Microsoft Corporation may have a class identifier of "MSSpreadsheet," while code implementing a spreadsheet object developed by another corporation may have a class identifier of "LTSSpreadsheet." A persistent registry in each computer system is maintained that maps each CLSID to the code that implements the class. Typically, when a spreadsheet program is installed on a computer system, the persistent registry is updated to reflect the availability of that class of spreadsheet objects. So long as a spreadsheet developer implements each function member defined by the interfaces to be supported by spreadsheet objects and so long as the persistent registry is maintained, the client program can access the function members of shared spreadsheet objects without regard to which server program has implemented them or how they have been implemented.
  
  Since an object may support some interfaces and not others, a client program would need to determine at runtime whether a particular object supports a particular interface. To enable this determination, every object supports the interface IUnknown, which contains a function member, QueryInterface, that indicates which interfaces are implemented for the object. The method QueryInterface is defined as follows:
  
  The method QueryInterface is passed an interface identifier in parameter iid (of type REFIID) and returns in parameter ppv a pointer to the implementation of the identified interface of the object for which the method is invoked. If the object does not support the interface, then the method returns a false. The type HRESULT indicates a predefined status.
  
  [Original image modified for size and/or readability]FIG. 2 is a symbolic representation of an object. In the following description, an object data structure is represented by the shape 201 labeled with the interfaces through which the object may be accessed .....
  
  In accordance with a first aspect of the present invention, a method is executed in a distributed system having a Dumber (sic) of computer systems that are connected by a network. In accordance with this method of the first aspect of the present invention, at least one of the computers has a container for storing objects and links. This method provides for the programmability of the container. The programmability of the container is provided through replacing the methods of the container and extending the functionality of the container.
  
  In accordance with a second aspect of the present invention, an improved storage mechanism is provided. The storage mechanism of the preferred embodiment provides for a programmable container. The container of the preferred embodiment contains methods that are replaceable as well as a command unit that extends the functionality of the container .....
  
  A preferred embodiment of the present invention provides for an improved method and system for storing information in a computer system. In a preferred embodiment, information is stored through the use of a container. A container is an object that contains a collection of data ("contained objects") and that provides an interface through which to access the collection of data. The contained objects can include files, databases, electronic mail messages, bitmaps, other objects, other containers, and various other types of data. In the preferred embodiment, a container is programmable. This programmability is provided by allowing for replacement of the implementation of the interface of the container ("replaceability") and by allowing for the extension of the functionality provided by the interface ("extendibility"). Because containers are replaceable and extendible, the functionality of a container can be tailored to the needs of a user. For example, a user can extend the functionality of a container to limit the types of data that are stored within the container. Thus, containers are a more flexible storage mechanism than conventional folders."

I am filing this entry in the Reference Library to this blog.

Dreaming of a Universal Information Database

The following quoted text (beginning at the bullet, below) is taken from the statement of prior art in US Patent 5,673,322 entitled System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks and filed in 1996 by Bell Communications Research.

For those of you who have always wanted somebody to just tell you how the Web works without all the technological jargon, this statement of prior art comes as close to your wish as is possible. This is a wonderful overview of where the Internet, and then the Web, came from without being technologically overwhelming. Ignore the references to low data speeds and data transmission rates, and don't let this fool you into thinking that the fantastically faster data speeds of today makes the following discussion irrelevant. The invention (not presented here) sought by Bell Communications Research relates to an improved WWW interface with protocol translation, security and automatic configuring features that is just as relevant today to as it was in the mid-1990s.

• "For fifty years, people have dreamed of a universal information database--data that would not only be accessible to people around the world, but organized such that related information is easily discovered and so that the most relevant data for a particular need is quickly found and accessed by a user.
  
  In the 1960's, this idea was explored further, giving rise to visions of a "docuverse" that would revolutionize all aspects of human-information interaction, particularly in the educational field. Only recently has the technology started to fulfill these visions, making it possible to implement them on a global scale.
  
  The Internet has evolved through a cooperative effort by universities, corporations and government. Years ago, the Defense Department started interconnecting the computer networks of universities, private organizations and sometimes corporations with whom research was being conducted. This network of networks has, over time, evolved into a global network commonly referred to as the Internet or the World Wide Web (WWW). The official description for the WWW is a "wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents."
  
  As the WWW became more popular and subject to wider public use, the Department of Defense curtailed its involvement. Today, many government-funded links on the Internet have been turned over to commercial enterprises that maintain the interconnection of Local Area Networks (LANs) between universities, companies, etc.
  
  Though the WWW is proving to be an extremely valuable resource for corporate enterprises (for communicating via electronic mail (e-mail), accessing information on-line, etc.), corporations are concerned about the security of their intellectual property, trade secrets, financial records and other confidential information stored on their computer networks. There is also concern about electronic vandalism -- unauthorized access of a computer network over the WWW for the purpose of destroying or distorting computerized information.
  
  [Original image modified for size and/or readability]In response to these concerns, some connections to the WWW have been protected with "Network Security Firewalls." As shown in FIG. 1, a firewall is commonly a specific piece of hardware and/or software bridging the connection between a private computer or computer network (LAN) 10 and the WWW 12. The main purpose of a firewall is to screen data traffic into and out of the network that is to be protected. If a network intruder is detected, the firewall has the capability of sifting through the data traffic and disabling the intruder's access. In early forms of Internet firewalls, it was generally difficult to ascertain which data traffic was good or bad, i.e., relating to a corporate user or an intruder. This created a problem for corporate users (inside the corporate LAN) of Internet applications, such as File Transfer Protocol (FTP), because their applications would sometimes get incorrectly blocked by the firewall. The firewalls needed more intelligence about application data traversing a firewall so that desirable traffic was not hindered.
  
  Internet engineers designed "proxy" services on Internet firewalls to meet this need. These proxies are computer processes that completely understand specific applications like an FTP application. It became a straightforward matter for network administrators to add multiple proxies to the firewall system based on the type of applications the internal corporate users wanted to execute. For example, WWW browsers (described below) would use a Hyper Text Transport Protocol (HTTP) proxy to transfer Hyper Text Markup Language (HTML) documents.
  
  To facilitate use of the WWW, "browsing" software 6 was developed. Browsers, such as the popular Netscape.TM. and Mosaic.TM. browsers, allow WWW users to browse information available on computers linked to the WWW. A related invention by the assignee, described in U.S. patent application Ser. No. 08/309,336 (hereinafter "the '336 application), provides users on computer networks with a consistent means to access a variety of media in a simplified fashion. Making use of browsing software, the invention of the '336 application has changed the way people view and create information--it has created the first true global hypermedia network.
  
  [Editor's Note: U.S. patent application Ser. No. 08/309,336 was issued in 1998 as US Patent 5,742,905 entitled Personal communications internetworking]. 
  
  One responsibility of an HTTP proxy is to receive requests from browsers or software applications 6 within the protected network 10 and relay those requests to the WWW 12. The proxy also monitors access to the protected computer or network 10 from the WWW 12. Thus, the proxy 4 can allow a system administrator to monitor information and requests flowing between the protected network 10 and the WWW 12. If illicit activity is discovered, the proxy 4 can interrupt the connection to the WWW 12. This proxy-driven firewall 2, 4 allows corporations and those with similar concerns to make use of the valuable resources of the WWW 12 while maintaining a degree of security.
  
  To effect links between computers and software applications across the WWW, protocols have been developed to govern the transmission of computerized data. A protocol organizes data to be transmitted over the WWW in a standard way recognizable by the receiving computer. There are seven layers in the open systems interconnection (OSI) model of a computer protocol. Each layer adds additional organizational capabilities that facilitate the transmission of data.
  
  Internet Protocol (IP) is the third layer in the OSI model and the basic "language" that is spoken on the Internet. The fourth layer, Transmission Control Protocol (TCP), is a more specialized protocol contained in IP. To use the WWW, a computer must be able to communicate using a protocol that incorporates IP and, consequently, TCP.
  
  The WWW and technologies surrounding Internet access have seen explosive growth. Many companies have evolved to allow subscribers access to the WWW using standard telephony. A group called Internet Service Providers (ISP) represents many of these service providers.
  
  A promising area for further expansion of Internet access is wide-area wireless data networks. The wireless networks include cellular digital packet data (CDPD, provided by cellular carriers), circuit-switched cellular networks, such as the Mobitex.TM. network (provided by RAM Mobile data in the U.S.), the Ardis.TM. network, and a host of emerging national wireless data providers.
  
  All of the listed data network providers offer traditional Internet Protocol (IP) service and are capable of integrating with the WWW. The data speeds range from 4,800 to 28,8000 bps and have latencies that range from milliseconds to 10 seconds.
  
  Despite the popularity of the WWW, there are still technical and security issues that must be overcome in accessing the Internet. Some of these problems are particularly acute for wireless systems trying to access the WWW.
  
  Problem 1
  
  The first problem is caused by data latency (described in more detail below). Data latency refers to the time delays created by multiple hops and slow links as data travels across various nodes within the WWW. This particular problem is exacerbated when the WWW is accessed using a wireless modem. Most wide area wireless, and some wireline, data networks were not originally designed to support the TCP/IP protocol. Latencies are increased even further by encapsulating IP data into the networks' original data protocols.
  
  When TCP is organizing data for transmission over the WWW, it breaks the data into discrete "packets" of information. TCP then transmits the individual packets. Each packet includes instructions to the receiving system for reassembling the packets into the complete data structure being transmitted. Each packet also includes a cyclic redundancy check that allows the receiving system to check that the packet was not corrupted or broken up during transmission.
  
  TCP is typically configured to transmit a number of packets and then wait for a confirmation from the receiving system that the packets have been received properly. The amount of time required to transmit a data packet and receive confirmation of its arrival is known as the "latency" of the system.
  
  If TCP does not receive confirmation that the data packet was properly received, it will assume that the packet was lost during transmission and re-transmit the packet. If the latency of the system gets too high, TCP will assume, prematurely, that the packet was lost and flood the network with re-transmissions of the same data packets before the original packets reach their destination. This is also a problem because many service providers charge users per data packet transmitted. If TCP is flooding the system with unnecessary duplicates of packets still in transmission, the cost to the user will be greatly increased. Thus, TCP cannot operate properly over a connection with a high latency. If the latency of the system exceeds approximately 3 to 5 seconds, TCP will begin to malfunction.
  
  When the WWW is accessed over standard phone lines that do not support TCP, the TCP datagram must be encapsulated (i.e., translated) into a form that can be sent over the telephone line. The datagram is then unpacked and used by the receiving computer. While this approach works, it adds to the latency of the transmission.
  
  A further problem with accessing the WWW using a wireless modem is the increased latencies that are introduced by the wireless network. A general trend is the wider the area served by a wireless data network, the lower the bandwidth (in bps) of the transmission. For example, present wireless communication systems in use in the United States are capable of transmitting 4,800 bits of data per second. This results in latencies up to as much as 10 seconds.
  
  Related art on wireless WWW access exists at: 1. Carnegie Mellon University's Information Networking Institute, Wireless Andrew Initiative. 2. Rutgers University's Winlab, Dataman project. 3. University of Washington's CS&E, Mobisaic. 4. Xerox's Palo Alto Research Center, PDA and virtual office computing concepts. 5. Computer Networks & ISDN Systems Volume 0028, Number 1-2 ISSN:0169-7552, December '95, "PDAs as Mobile WWW Browsers", Gessler S., Kotulla A. 6. General Magic's, Magicap OS version of a WWW browser with enhancements for Telescript agent technology.
  
  All of these projects and papers either require the modification of a browser, specification of new protocols (still based on TCP), or defining generic inter-networking specifications for connecting wireless and low-bandwidth networks to the Internet for WWW access.
  
  Thus, there is a need for a method of translating TCP in connections over high-latency wireless and wireline networks.
  
  Problem 2
  
  A second problem is that current WWW access software does not provide standard mechanisms for compression, encryption, or filtering. Compression entails decreasing the size of transmissions of data over the network without changing the content of the information. Most proposals for compression support require external utilities from the browser to decompress the data, and then return usable output to the browser through the use of Multipurpose Internet Mail Extension (MIME, Nathaniel Borenstein et. al RFC 1521) types.
  
  Encryption is the coding of data transmissions. Encryption helps to provide security since encrypted data transmissions are much more difficult for an unauthorized party to intercept and access. Unfortunately, it is unlikely that generic, open standards for these desirable services could be created to support all WWW client requests. Standards are evolving for encryption in WWW software (i.e., Secure Socket Layer (SSL)). However, at current levels of computer hacking, it is unlikely that any open standard for encryption will be able to maintain integrity for long.
  
  Most advanced browsing technologies, therefore, have installed proprietary encryption schemes and are only capable of working between a WWW server that supports the encryption scheme. This option goes against the open standards design of the WWW.
  
  Filtering refers to global control of a WWW response based on data size, type, or some other characteristic whereby a user can customize the receipt of data. Work is being done in this area through WWW search engines, specialized caching utilities on advanced browsers, etc.
  
  The filtering referred to here is a global safety net for unwary users that could potentially misuse a wireless/low-bandwidth data network by requesting too much data, retrieving spurious information, or some other unwanted side effect resulting from a WWW request. For example, a user may request a data object from the WWW that a user is not aware is extremely large, and perhaps costly, to transmit. AS a safety net, the user may configure a filter to automatically prevent a particular request from being executed.
  
  Thus, there is a need for an implementation of compression, encryption and filtering features in a WWW interface.
  
  Problem 3
  
  A third problem exists in that there is no standard way for WWW access software to receive asynchronous or unsolicited updates from the network. Existing browser technology is client based. The most popular browsers, such as the Netscape.TM., Mosaic.TM., Lynx.TM. browsers, as well as other less popular browsers, require users to initiate some form of request before response data will be delivered to the respective browser.
  
  For example, it is desirable for a company providing access to the WWW to be able to remotely configure a subscriber's WWW access system from within the network. Since regular browsers do not offer this feature, subscribers must configure and update their access software manually. This may require the support of the service provider through a traditional voice customer support line or custom agent software on the user's host system.
  
  Thus, there is a need for a WWW interface that can receive and implement unsolicited transmissions from the network or service provider, particularly to automatically configure software for accessing the network."

I am filing this entry in the Reference Library to this blog.

USDA Takes Action on Mandatory Country of Origin Labeling

WASHINGTON, July 29, 2008 -- The U.S. Department of Agriculture today issued an interim final rule for the mandatory country of origin labeling (COOL) program that will become effective on Sept. 30.

The rule covers muscle cuts and ground beef (including veal), lamb, chicken, goat, and pork; perishable agricultural commodities (fresh and frozen fruits and vegetables); macadamia nuts; pecans; ginseng; and peanuts -- as required by the 2002 and 2008 Farm Bills. USDA implemented the COOL program for fish and shellfish covered commodities in October 2004.

Commodities covered under COOL must be labeled at retail to indicate their country of origin. However, they are excluded from mandatory COOL if they are an ingredient in a processed food item.

USDA has also revised the definition of a processed food item so that items derived from a covered commodity that has undergone a physical or chemical change (e.g., cooking, curing, smoking) or that has been combined with other covered commodities or other substantive food components (e.g., chocolate, breading, tomato sauce) are excluded from COOL labeling.

Food service establishments, such as restaurants, lunchrooms, cafeterias, food stands, bars, lounges, and similar enterprises are exempt from the mandatory country of origin labeling requirements.

The rule outlines the requirements for labeling covered commodities. It reduces the recordkeeping retention requirements for suppliers and centrally-located retail records to one year and removes the requirement to maintain records at the retail store. The law provides for penalties for both suppliers and retailers found in violation of the law of up to $1,000 per violation.

The rule will become effective on Sept. 30, 2008. To allow time for covered commodities that are already in the chain of commerce -- and for which no origin information is known or been provided -- to clear the system, the requirements of this rule will not apply to covered commodities produced or packaged before Sept. 30, 2008.

The rule prescribes specific criteria that must be met for a covered commodity to bear a "United States country of origin" declaration. In addition, the rule also contains provisions for labeling covered commodities of foreign origin, meat products from multiple origins, ground meat products, as well as commingled covered commodities.

USDA plans to conduct education and outreach activities during the six months following the rule's effective date to help the industry comply with the law.

The full text of the interim final rule will be published in the Aug. 1, 2008, Federal Register.

Copies of the interim final rule and additional information can be found at: http://www.ams.usda.gov/COOL.

The challenges in interacting independent computer applications across a heterogeneous data processing network

The following quoted text (beginning at the bullet) is taken from the statement of prior art in US Patent 5,619,710 entitled Method and apparatus for object-oriented invocation of a server application by a client application and filed in 1994 by Digital Equipment Corporation.

• "Computers communicate with each other over data processing networks. The computers themselves are referred to generally as "nodes," and a specific type of computer, that is a specific type of hardware using a specific type of operating system, is referred to as a "platform." Networks containing different types of platforms are called "heterogeneous networks." One purpose for connecting platforms in a network is to provide different environments in which to execute application programs (referred to as "applications" for brevity) on shared data.
  
  In the typical data processing network, different platforms and applications running on different platforms store information in their own specific manner. For example, in a VAX.VMS platform, text editing tasks may be accomplished using a TPU text editor, while in a MIPS.ULTRIX platform, text editing tasks may be accomplished using an EMACS text editor. Users of a network having both platforms may wish to use operations from the different text editors on the different platforms without having to know the details of those platforms and text editors.
  
  This compatibility has not previously been possible. Instead, conventional networks require users of a heterogeneous network to employ the specific interface each application requires for operations on specific platforms. Conventional networks fail to provide users with a capability to communicate between applications using a standard interface.
  
  As an example of the difficulties of interapplication communication on a conventional heterogeneous network, suppose that the user of a text editor application on one platform desired to access a multi-user data base retrieval service, such as DIALOG for scientific articles or LEXIS for court opinions, on another platform. To do so on a conventional network, the text editor application's operation would have to be suspended, and the data base retrieval service would have to be invoked using commands and messages specific to the data base retrieval service. The user would not only need to know the specific names of each service desired, but would also have to know the location of the service in the network and would have to be familiar with the different commands and command formats employed by each service.
  
  As yet no standard interface has been developed to allow an application in one platform to invoke an application on a different platform in a heterogeneous network in an efficient arid uncomplicated manner. Instead, conventional interapplication communication merely provides mechanisms for physically transporting messages and data between applications.
  
  One example of a mechanism which is presently used to allow an application on one platform to communicate with an application on a different platform is a Remote Procedure Call (RPC) system. An RPC system on one platform responds to queries from an "invoking" application by first translating that application's messages into a network data format, and then transmitting the translated queries over the network to a receiving platform. At the receiving platform, another component of the RPC system decodes translated messages into queries in a data format acceptable to the application invoked. The original messages from the invoking platform, however, need to be consistent with a syntax dictated by the invoked application.
  
  Another difficulty with conventional networks occurs when the application on a remote node is not currently loaded and running. Many RPC systems only allow remote invocation of applications that are already loaded and running. If this is not the case, the user of the client applications must find some way to load the server application on the remote platform before invoking it. This can be severely limiting.
  
  One obstacle to implementing a network-wide system to facilitate interapplication communication has been the large amount of system resources which had been thought to be required of a system in order to handle all the different types of data, operations and applications in a network. As a network expands, the systems, resources, and requirements would increase as well, making many proposed implementations completely unwieldy.
  
  There is, therefore, a need for an efficient and simple manner for applications on different platforms to communicate with each other, such as through a uniform and consistent interface for applications. There is also a need for a dynamic invocation environment for applications in a distributed heterogeneous environment. This includes providing the ability to invoke applications that are not yet loaded and running as well as those which are."

The solution presented relates to the organization of a data processing network in accordance with an object-oriented model and the interaction of independent applications across such a heterogeneous network environment. I am filing this entry in the Reference Library to this blog.

The challenges in automated data transfer and data translation

The following quoted text (beginning at the bullet) is taken from the statement of prior art in US Patent 5,608,874 entitled System and method for automatic data file format translation and transmission having advanced features and filed in 1995.

• "Computerized data, or electronically stored information, must frequently be moved from one computer to another. In the case of accounting data, for example, banks generally keep computerized records of all of transactions affecting their client's accounts--information which the clients often also wish to keep track of on their own computerized accounting systems. In response to this, a variety of sophisticated computer accounting programs have recently become available to users of small and medium powered computers. However, due to a variety of reasons discussed below, such clients usually have to re-enter data manually from paper printouts obtained from the data provider, for example, from statements from a bank. Manual re-entry of data is not only time-consuming, and hence expensive to undertake in terms of man-hours, but it also is likely to introduce errors into the data set. It has been estimated that manual data re-entry, verification, and validation costs several dollars per transaction.
  
  Methods of automated data transfer are known in the art. The "Intellicharge" system for Quicken (Intuit Inc., Menlo Park, Calif.) downloads credit card transaction information to a Quicken user's computer. The data used, however, comes from a uniform source--a single bank. Hence, Intellicharge does not employ a multiple-format data translation scheme, nor a multiple-source data transmission scheme. Similarly, in the United States Internal Revenue Service "Electronic Filing" program, data is entered and transmitted in a single, specific pre-prescribed format, to a single recipient.
  
  Methods of data translation are also known in the art. A software application entitled "Data Junction" (Tools and Techniques, Inc., Austin, Tex.) translates multiple formats of data. However, the package depends on manual operation to designate the files to be translated, and the formats of the source and destination files. Furthermore, this software does not perform any data transfer, verification, validation, exception reporting, or journal entry correction.
  
  Conventional electronic data exchange (EDI) systems involve two or more companies that have agreed to interact with one another according to a pre-designated standard dictated by the industry in which the transaction is taking place. In order for such a system to work for a given industry, there must be an agreed-upon standard that is used-much like in the case of the IRS system described above. Those industries that do not have such a standard cannot participate. Data analysis, such as exception reporting or statistical analysis, are not features of such systems. Obviously, such systems lack flexibility and versatility. Additionally, the computer systems that support conventional EDI are expensive to operate and maintain because they are specialized to serve specific industry segments, and hence cannot achieve the efficiency and low cost that economies of scale might permit in a more widely applicable system.
  
  In summary, conventional methods of automated data transfer, and of data translation, are quite limited, due primarily to limited network transfer capabilities, and the lack of universal data format standards. Hence, anyone wishing to automatically transfer data from a variety of computer systems to a variety of others must contend with a plethora of incompatible formats, and a lack of reliable transfer and error detection means. For these reasons, existing data transfer systems have been tailored to work with only one, or very few types of data sources and recipients, and these data translation methods rely heavily on manual intervention. Data transfer technologies and data translation technologies have not, in the prior art, been efficiently integrated."

I am filing this entry in the Reference Library to this blog.