DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0047] Referring to FIG. 1 , the inventive software component is schematically shown in operative mode installed at a user's computer workstation. The workstation is communications-equipped for communication with remote services, for example by modem, which services are also shown schematically. Only relevant software and hardware components of the system are shown.

[0048] Relevant components at the workstation comprise operating system services 10 , a containing information product 12 , an information transport component or module 14 , herein also referenced as a “transporter” which may be a stand-alone product or, in preferred embodiments is embedded or contained in the containing information product 12 . Information transport component 14 provides a general purpose facility for sending and fetching information objects between an end user's computer (the client) and a central server. Information transport component 14 is not customized to the containing information product 12 , but is intended to be used in conjunction with any of a wide range of electronic information products.

[0049] Operating system services 10 provide capabilities for the containing information product 12 and the information transport component 14 to access a readable information storage device 16 which may, for example, be an optical disk drive such as a read-only CD-ROM where product information 17 is stored. In addition, a read/write information storage device 18 , for example, a conventional hard disk is accessed via the operating system services 10 for storage of a fetched additional information object 26 . The storage media used for hard disks and the like are often described as nonvolatile and the type of storage is frequently referenced as “permanent.” however, the more recently used term “persistent storage,” which references the manner of storage as well as the physical storage media and distinguishes from transient storage where objects may be automatically erased after some interval, or event, without supervisory control or awareness of the erasure, is a more suitable descriptive term for the purposes of the present invention.

[0050] As necessary, different, or modified, information transporter components 14 can be supplied for users of different operating systems or system families, notably DOS (available in several versions, for example from Microsoft Corp, IBM Corporation, Novell, Inc.) Windows (trademark, Microsoft Corp.), Apple Computer Corp.'s operating systems, possibly IBM Corporation's OS/2 (trademark), and any distinct operating systems developed for personal digital assistants, pen-based computers and the like.

[0051] Information transport component 14 also uses operating system services 10 for external communication with a communications network 20 through which the information transport component 14 can access a remote server 22 , or server-client network, supporting a data storage device 24 where desired additional information object 26 is located.

[0052] Communications network 20 can be any electronic distribution system suitable for transporting information objects 26 including wired and wireless common carriers such as telephone networks, cable television systems or networks and mobile telecommunications or data communications networks and extends also to emerging and future systems of providing electronic communication between users of diversified equipment. The term “common carrier” is used herein to embrace all such data communication systems as will reasonably meet the purposes of the invention. The term “modem” is used herein to embrace any network interface device enabling a user station to communicate on such a communications network 20 .

[0053] While the containing information product 12 can take many different forms, as described herein, and as will also be apparent to those skilled in the art, a preferred embodiment is that of a periodically issuing publication or publications, for example, a news magazine or a collection of patents. Again, the additional information object 26 could be any information of interest to the user, having some relevance to the containing information product 12 , but the invention and its unique capabilities enable the additional information object 24 to be fully integrated with the containing product 12 in a manner that can be automated to be transparent to the user.

[0054] The inventive information transport component 14 is designed to require a minimum of user input. A bare minimum will be a user's ID which can be entered by the user in a product setup and automatically accessed for information transport, or could by pre-loaded by the vendor from data supplied by the user at purchase.

[0055] A product ID is preferably pre-loaded into the containing information product 12 by the information product vendor or publisher to be available for use by the information transport component 14 . However, even this may not be required. In an alternative embodiment, the product ID can be automatically incorporated into the product in a product replication process that permits individualized coding of unique ID's. In most cases, a user-actuated menu selection is provided in the containing information product 12 after integration with the inventive information transport component 14 to activate transport of an additional information object, and preferably, selection of transport activation drops down a menu of transport choices such as “FETCH UPDATE”, “FETCH CATALOG OF UPDATES”, “SEND DATA” and the like, each of which then runs automatically upon selection.

[0056] Updating can also be totally automatic, and other than an obviously desirable user notification, be completely invisible to or transparent to the user, running in background on their system, while the user's screen is available for other processing such as running the containing information product 12 . Where updates are made available on a known schedule, a totally automated product can be provided that fetches an update without any user intervention, on the specified release date, or as soon thereafter as the user's system, or the containing information product 12 , is activated. In practice, most users will probably prefer an opportunity to confirm that the fetch transaction should proceed. A preferred embodiment monitors the user's system clock and alerts a user to the arrival of an update release date and asks the user to confirm that the system should seek and fetch the scheduled update, if available.

[0057] Thus, the invention is particularly suitable for importing updates of information or information processing products, such as periodically issuing literature, or software upgrades. Accordingly, additional information object 24 preferably comprises updates which can be integrated with the information product 12 to provide, for example, a coherent body or continuous sequence of materials that can be commonly searched and indexed preferably in a manner giving the user the appearance of a common logical file formed from physically distinct files. The appearance of integration can be achieved by searching new and then old indexes in series and making the search and navigation logic of the containing product smart enough to combine new and old information. For example a new object can have an index file similar to that for the original information product 12 . A search engine can first search the new index, then the old one, and then produce a combined set of results. Preferably, the files are not actually merged or otherwise combined as to do so could be unduly complex.

[0058] As shown in FIG. 1 , the containing information product 12 comprises a user interface 28 enabling the user to view, search, excerpt and print or otherwise export or process selected information items from product information 17 . The user interface 28 provides standard information product features, as conventionally supplied by the product publisher, supplemented by appropriate fetch or send options to activate the features of the inventive information transport component 14 .

[0059] Also shown in FIG. 1 are a database management module 3 0 and a data structure definition module 32 . Database management module 30 provides retrieval-oriented database processing of the information product including indexed searching and selective retrieval capabilities using one or more index keys such as an issue or item number, or full text searching, and may provide hypertext and hypermedia linkages. The data structure definition 32 provides the database structure of relevant files as classified by field or element, name, type, size and the like. After successful completion of a fetch operation, control is returned to containing information product 12 to process the new information in essentially the same manner as the original information, or in any other manner for which it has been equipped.

[0060] Major modules comprised in the inventive information transport component 14 are a user interface 34 , a communications module 36 and fetch-send protocol 38 . In addition, the information transport component 14 preferably comprises its own built-in application programming interfaces (APIs) such as a user interface API 40 and a communications API 42 , enabling the information transport component 14 's user interface and communications modules respectively, readily to be incorporated with, or plugged into a wide range of containing information products 14 . Such incorporation, in the currently best known embodiment of the invention, is effected by software engineers familiar with and having access to the containing information product 12 , but future developments may enable the incorporation process to be effected by skilled users.

[0061] References herein to an applications programming interface (API) will be understood to embrace any program interconnection technique which supports direct, seamless interaction between one program and another, including procedural calls, object encapsulation, or emerging techniques like Microsoft Corp.'s Object Linking and Embedding (OLE) or Apple Computer's Open Doc.

[0062] API 40 is responsible for providing means for the user to interact with the information transport functions of the invention and interface as seen by the user and API 42 is responsible for handling internal processes of communications and data management.

[0063] The APIs 40 and 42 are intended to enable the information transport component 14 to be used by a range of product programs controlling a variety of information products and to enable each API 40 and 42 to be free to exercise flexibility and creativity in extending its associated user interface 28 , data management module 30 and database structure 32 to fully address the provision of transport functions for the purposes described herein.

[0064] API 42 operates on a transport function level involving high level interactions between the containing product 12 or the user (or the optional user interface) and the transporter 14 before and after communications while the detailed low-level interactions between the transporter client and the server during communications are handled by fetch-send protocol 38 , without involvement of the containing product 12 or the user. “High level” is used to refer to a level at which software interacts with a user, typically in simple, readily comprehensible, function-oriented, graphic or everyday language terms, while “low-level” refers to a level of detailed procedural interaction with an operating system, or device (modem, port etc.) in obscure program or machine language terms incomprehensible to most users.

[0065] Fetch-send protocol 38 is, in the preferred embodiment shown, a component of a novel client-server communications procedure designed to manage the transaction-oriented transmissions required to achieve satisfactory transport of desired server stored information objects, and optionally, central reporting of user information in a predetermined format. Alternatively, one or more existing protocols could be used.

[0066] Preferably, the API's 40 and 42 and the fetch-send protocol 38 are structured to use a manifest list to control the exchange of information objects. The manifest list can be provided in fetch-send protocol 38 , and can be forwarded to remote server 22 to provide better efficiency, error control, and management of the operation. Alternatively the manifest list may remain resident at the user's station. The manifest is valuable operating at the client station, at the API level, to specify the actions required during a transport session and can in one embodiment comprise a list of send and fetch operations which are individually controlled.

[0067] This software mechanism, employing novel communications procedures and applications interfaces that reference an object manifest, provides a new way for performing a wide variety of information exchange functions in a simple, standardized and economical manner.

[0068] API Functions:

[0069] 1) Product Setup

[0070] In preferred embodiments, API 40 and API 42 include a product setup routine of an s application-specific configuration, which is used by the publisher or product developer, prior to publication, to establish seamless compatibility between the containing information product 12 and the information transport component 14 for smooth execution of desired transport functions. A completion status code is also specified.

[0071] The application-specific configuration posts user and product ID information, as needed to process password or other access code authentication and posts files information, including designation of an application work directory and a transporter work directory for performing the transporter functions of information transport component 14 .

[0072] Additionally, the application-specific configuration sets up an appropriate decompression (or compression for send objects) technique according to the expected format and condition of fetched information objects 46 , which information is pre-coded into communications component 36 .

[0073] The application-specific configuration established through API 40 selects either a standard user interface, as furnished with information transport component 14 , or an application-controlled user interface. Control settings are established for connection problem handling, disk error handling, abort and server condition handling, access denial, unavailability of information object files and any other error situations which may occur during transport.

[0074] If desired, optional, advanced controls for scheduled automatic calling can be included in the application-specific configuration used in preparing the containing information product 12 for publication.

[0075] Preparation of containing information product 12 and incorporation of information transport component 14 therein, with an application specific configuration, as described is carried out prior to publication to build a customized, ready to run version of the product with automated update capability.

[0076] Communications API 42 establishes a product-specific transport method choice list for selection of an appropriate file transfer protocol as between direct dial, data network dial, and other modes of transport. Communications protocols specify necessary connection parameters such as access number and network addressing or other routing information. Optional script choices can provide for different modes of transport.

[0077] These product-specific configurations and protocols enable information transport component 14 to be packaged in executable form with containing information product 12 , with all necessary product-specific components and settings, including a standard user interface if selected, ready for inclusion in the product package.

[0078] If desired, at the option of the information product publisher, a standard user interface may be included. Such an optional standard user interface can have all facilities needed to select transportable objects from a predefined list, perform all user setup functions, and invoke information object transport.

[0079] Additional options are standard software that would allow the user to search, view and print the transported objects totally independently of the user interface and database search components of the containing product. Both such options enable a publisher to exploit the inventive transport product for efficiently and economically providing updates without having to make changes to the publisher's containing product, simply by configuring the transporter or information transport component 14 and physically including it, and the optional components, within the containing product.

[0080] A standard viewer might handle only ASCII text, but it preferably could provide for other useful formats such as standard word processor, spreadsheet or database formats, or multimedia formats such as video, sound and HTML (hypertext markup language), a format becoming popular on the Internet and which provides the ubiquitous Web pages for the Internet's World Wide Web.

[0081] API Functions:

[0082] 2) User Setup

[0083] Compatibility with the user's system is effected by API 40 establishing a user-specific configuration, and creating or updating the necessary control files.

[0084] Parameters established in the user-specific configuration include a setup ID number to permit use of multiple setups, for example, for different transport options, and a product ID number.

[0085] The user-specific configuration posts user ID information and a password or other access code authentication and posts files information, including disk and drive designation for work and data directories. Autocal options and a completion status code are also specified.

[0086] API 40 provides information for communications module 36 , specifying a user communications protocol for the user's hardware, operating system, line configuration, and so on. Thus, for a standard telephone connection, comm port, speed (baud rate), interrupt settings, modem type and control strings, dial prefix, dial 9 , pulse or tone, call waiting shut-off, and the like are specified, as appropriate. Additionally, the user communications protocol includes access number and connection parameters, optionally with script selection for routing choices via data networks, and so on.

[0087] The resultant user-specific configuration and communications protocols generated through API 40 create a setup ready to call and places it in the designated transporter work area. A validation procedure checks entries and reports obvious errors in parameter settings.

[0088] Preferably, multiple product ID setups are provided to enable multiple information products to use the transporter with an appropriate, compatible transporter version. Preferably also, the user-specific configuration accommodates shared use of the transporter work areas by multiple information product applications resident on the same user's system.

[0089] Mechanism of Fetch-Send Protocols 38 (User) and 44 (Server)

[0090] User fetch-send protocol 38 working in cooperation with server fetch-send protocol 44 controls the desired information object transport function, calling remote server 22 and exchanging data objects. It performs or supervises communications between the user's system and remote server 22 .

[0091] Communications module 36 uses a setup ID number specified through API 40 or 42 , selects which setup to use for a call, calls remote server 22 using protocol 38 , and in a preferred embodiment, sends an object manifest comprising a send object list, a fetch object list or both. Such manifest is created under control of user interface 28 from a pre-existing set of choices supplied with the product or obtained during previous update operations, or both.

[0092] Alternatively fetch-send protocol 38 may refer to a pre-existing manifest list stored at the user's station, or may be directed by remote server 22 to select one of multiple pre-existing manifest lists stored at the user's station. As another alternative, although it is convenient and advantageous to transmit the manifest list to the server 22 , the relevant status and management information can simply be used locally by communications module 36 and be integrated into the individual fetch and send protocols.

[0093] A send object list comprises object action codes specifying the type of server action required, if any, object names, object sizes and response object size, if any. A fetch object list comprises object names, object sizes and an object availability date.

[0094] A completed object manifest is employed to convey the status of the transport operation and to provide for additional information transport, if desired. The completed object manifest adds the following to the request object manifest: send object additional information; object acceptance codes returned by server 22 ; time of acceptance; and a response object name, if called for by the object action code.

[0095] For a fetch operation, the completed object manifest adds the following to the request object manifest: fetch object additional information; a fetch confirmation or failure code; the time of completion or failure and a revised availability date if the requested fetch object was unavailable.

[0096] If a scheduled update or polling option is present and selected, a scheduling or polling indicator is included, and a completion of processing or import function to call through API 42 is specified.

[0097] A completion status code terminates the fetch or send operation and returns control to the information product application or the provided user interface.

[0098] Information Transport Using Communications Module 36

[0099] Communications module 36 employing the described fetch-send mechanism comprised by cooperating protocols 38 and 44 performs the functions necessary to complete an information transport operation, as described herein, under a variety of circumstances, with tolerance for a common range of error conditions, open drives, inadequate disk space, lost line connections and the like, without losing control of the user's system. Using correct, verified ID, naming and routing information, the information transport operation employing the inventive information transport component 14 is less error-prone than many computer users would be were they effecting the transport operation with conventional technology requiring them to enter routing and storage information and the like, manually.

[0100] Communications module 36 verifies that all send objects are as specified, that all fetch objects are scheduled to be available, verifies that sufficient disk space is available for all fetch objects and for compressed transmission copies of all objects, and returns an error report if any of these requirements is not fulfilled.

[0101] Communications module 36 performs communications, then returns a completed object manifest, and logs all activity in a transporter log file. If an optional scheduling/polling feature is selected, the communication is deferred until the scheduled time.

[0102] These general objectives are achieved by carrying out the following process steps after an application (or optionally a transporter user interface) requests a transport function:

[0103] 1) Local validation of the request returning a failure code if the request is improperly specified.

[0104] 2) Compression of all send objects for transmission and placing them in the designated transporter work area.

[0105] 3) Connection attempts to remote server 22 , returning a failure code if necessary. Connections are made via phone line or network. The system handshakes and identifies the call to the server.

[0106] 4) Presentation of the object manifest, if utilized, for validation and action.

[0107] 5) On receiving a go-ahead, transport of each send object, logging each as sent, and receipt of object acceptance codes from the server and logs them, when received.

[0108] 6) Receipt of all fetch objects from the server, placing them in the transporter work area, and logs them as received. Fetch object names may be precise, or generic or alias names may be used to request a latest installment.

[0109] 7) Receipt and logging of a completed object manifest from the server. (If receipt of response objects is implied by the action codes, first receives a revised object manifest, and fetches the response objects, then receives the completed object manifest.)

[0110] 8) Disconnection from server.

[0111] 9) Decompression and unpacking of all fetch objects into application work area, and logs completion status.

[0112] 10) Returns control to the application (or optional transporter user interface).

[0113] The product checks the completion code, and completed object manifest to deal with any error conditions. The application performs any required import processing on fetched objects to integrate the data and indexes with prior data, as desired, to enable seamless use. If desired, import processing can include, or offer as a user selection, file maintenance functions relevant to the information product including, for example, file purging to remove obsolete information files and preserve the user's storage space. Specifications of files to be deleted can be included with the original product or with a fetch object. In either event the responsibility for accurate specification is passed to the vendor, relieving the user of the risk of making erroneous deletions and anxiety attendant thereon. After such import processing the containing information product (or the optional separate user interface) then returns control to the user for use of the received data.

[0114] Those skilled in the art will appreciate that the identification of files in the object manifest, or for file maintenance functions as the user station, or for any other purpose of the invention, can be effected generically, for example by using wild card characters, as is customary in file specification, and which effectively permits multiple objects to be specified as a class related by file name characteristics, or related individually, thereby providing options for specifying of such class of multiple objects to proceed at one time or in a series of transports over time. Other algebraical identification methods can be used which may reference object versions in series or comparable characteristics.

[0115] The foregoing steps are illustrated in the flow block diagram of FIG. 2 . When containing information product 12 issues an information transport call 50 , setup filter 52 runs setup routine 54 if this is a first call and no information transport setup was run on installation of containing information product 12 . At block 56 , an object manifest is retrieved for pre-transport preparation at block 58 . After prepping, a call to server 22 is established at block 60 and when the connection is made, and a handshake performed, one or more objects is transported at block 62 .

[0116] After completion of transport and receipt of a completion manifest, server 22 is disconnected at block 64 , received objects are decompressed and unpacked at block 66 and stored in a designated disk storage location at block 68 . Object storage triggers containing information product 12 's import processing to assimilate the information update with the original information product at block 70 , following which a completion report is issued at 72 and control is returned to the containing information product 12 at 74 .

[0117] Optional Schedule Function

[0118] An optional transport function module for scheduled or poll-responsive information object transport can be provided to defer the fetching of an update or to defer another information transport operation to a specified later time, or until called by the server.

[0119] The optional transport function schedules a request, waits, then automatically performs the transport operation at the scheduled time. In polling mode, it activates (and, if necessary, interrupts and then reactivates) the user station's ability to receive calls.

[0120] Mechanics of the optional transport function include a request for an ID number, an indicator for calling or polling mode and a schedule iterating a call time, a retry protocol, call activation and timing, along with an authentication procedure for the server and a completion status code.

[0121] Client-Server Communications Protocol

[0122] Communications between the information transport component 14 , functioning as a client, and the server 22 follow a predefined communications procedure having cooperative user components comprising user fetch-send protocol 38 and server fetch-send protocol 44 .

[0123] Server-client intercommunication can be broken down into five steps, a) login, b) manifest transmission, c) send operation, d) fetch operation and e) logout, as described in more detail below.

[0124] a) Login

[0125] Login establishes a session with an authorized client. A handshake process between user protocol 38 and server protocol 44 identifies the user's transporter client system to remote server 22 by product ID and user ID, and a password or other authentication code. A failure reason code is given to rejected clients.

[0126] b) Manifest Transmission

[0127] Preferably, via user protocol 38 , the user system issues an information object transport request manifest to server 22 . Server 22 verifies its ability to meet the request by returning a manifest acknowledgment specifying which elements will be processed and provides reason codes for declined elements. Alternatively, as stated previously, manifest functions can be listed in individual send and fetch protocols.

[0128] c) Send Operation

[0129] If the user system outputs a send object, through information transport component 14 and protocol 38 , server 22 receives and accepts the send objects and stores them, identified by product ID and user ID. Error control and retry mechanisms are employed and successful receipt of the send object is acknowledged and logged.

[0130] If the action code calls for a response object, the server obtains necessary processing from a pre-designated external source (corresponding to the product ID and action code) and returns the response as a fetch object, called a response object.

[0131] d) Fetch Operation

[0132] The server obtains requested fetch objects by product ID and object name and forwards them to the transporter at the user. Error control and retry mechanisms are employed and successful transmissions are acknowledged and logged.

[0133] e) Logout

[0134] The server transmits the completed object manifest to the transporter, confirins and logs receipt, and ends the session.

[0135] The Inventive Transporter Compared with a Conventional Communications Product

[0136] FIGS. 5 and 6 illustrate schematically the simplicity and ease-of-use benefits the invention provides FIG. 6 to a user 100 in fetching an information object from a remote server 22 as compared with the use of a conventional communications product ( FIG. 5 ), such, for example, as CENTRAL POINT COMMUTE (trademark) or PROCOM (trademark).

[0137] In the prior art embodiment of FIG. 5 , many operations require active participation by the user who, for example, must at least initiate any pre-transport preparation 104 of the information object, such as checking the specifications, checking work space available to store a fetched object and conducting any other preliminary checks. The user has to activate a communications product 102 , specify a call route, and after the call connection is established, specify the objects and initiate a transport operation. Communications product 102 , operating in a cooperative manner with remote server 22 , will execute establish call connection 60 after the call route (phone number) has been specified and will execute transport objects 62 after the objects to be transported are specified by the user. Disconnection 64 is usually effected by a user executing a call termination command, which if the user is inattentive, or inefficient, may be delayed longer than necessary to complete the transport operation, running up unnecessary line or air time charges.

[0138] After completion of the transport operations, user 100 has to deactivate the communications product 102 and then initiate any required storing and processing of the fetched product 106 . While some of these steps may be automated via one or more batch files, scripts or macros, a vendor of a containing information product 12 has great difficulty in furnishing such a batch file or macro for a mass market distribution because of the different systems and communications products encountered in a mass market, which systems and products have a variety of different specifications, performance characteristics and unique, incompatible scripting languages.

[0139] Equally, while some more skilled users 100 might be able to write their own batch files without undue difficulty to automate some of these steps. Many users will lack the ability or the inclination to do so. Also the effort would not be justified for a single transport operation. Nor is the result of such efforts likely to match the ease and simplicity of the results achieved by the present invention which enables even a first update to be obtained effortlessly with the software running in unattended mode, after initiation.

[0140] FIG. 6 clearly shows how the inventive information transport component 14 relieves user 100 of many tedious communication functions such as activating a communications product, specifying a call route, specifying the objects to be transported and deactivating the communications product. In addition, preferred embodiments of the invention also relieve the user of optional pre-transport preparation 104 and execution of store-and-process-fetched-product 106 if these functions are appropriate to the containing information product.

[0141] Referring to FIG. 6 , user 100 selects a transport operation from a user interface screen in containing information product 12 , whereupon the latter calls information transport component 14 to activate transport. Information transport component 14 implements any necessary pre-transport preparation 104 and then, employing its own communications module 36 , and server fetch-send protocol 44 , proceeds in unattended mode, without requiring user intervention to establish call connection 60 , to execute transport object 62 and automatically perform a disconnect 64 , as described herein.

[0142] Automatic transport control and disconnection is a useful feature of the invention providing economy of line or air time charges and reducing congestion on the communications carrier. Using conventional communications products, (especially with online services) the duration of the connection may be unnecessarily extended by the delays and potential errors inherent in user control, resulting in increased communications costs and failures. The inventive transporter 14 provides software control of the connection duration, enabling it to be confined to a period sufficient to effect said unattended object transfer, enhancing efficient use of the communications medium.

[0143] Also as described, the operation can be monitored or controlled by employing an object manifest and is facilitated by the use of pre-specified addresses and transport characteristics. After satisfactorily completing the transport, the information transport component 14 automatically deactivates and returns control to containing information product 12 , preferably with a satisfactory completion report which containing information product 12 notifies to user 100 through the containing information product 125 user interface.

[0144] If the transport object 62 was a product update, optionally a store-and-process-of-fetched-object 106 is initiated by information transport component 14 and execution of the store and process operation may be passed to the containing information product 12 . The user can now use the updated product.

[0145] As FIG. 6 shows, when read, in comparison with FIG. 5 , the invention enables a user 100 to be relieved of all duties save for minimal selection and notification functions, while no complex added functionality is demanded of containing information product 12 . Optional store-and-processor-fetched-object 106 is contemplated as requiring only minimal modification of existing containing information product 12 functions while other more complex procedural and detailed transport related functions are handled by the information transport component 14 .

[0146] Some non-limiting examples illustrative of practical commercial and industrial applications of the invention will now be described.

EXAMPLE 1

[0147] A News Magazine Distributed on CD-ROM

[0148] Some weekly news magazines offer subscriptions to a quarterly CD-ROM which contains multimedia material plus a searchable full-text database of the most recent quarter's weekly magazine issues and enabling application software. Newer issues are not provided until the next quarterly disc is mailed. Accordingly the CD-ROM electronic magazine product steadily becomes out of date and its value lessens.

[0149] The invention incorporates an information transport component 14 with a news magazine product stored on a CD-ROM 16 , to enable a user to fetch an information object 46 in the form of new issues (and their associated search indexes) from a remote server 22 , as they become available, for example weekly. The fetched updates are stored on a consumer's computer hard disk storage device 24 . Because of the size of rich content multimedia files, the updates are limited to text material including full texts of interim issues and associated files such as indexes. Because it knows the storage location of the updates, the next CD-ROM issue can include, as an install option, or upon first access, a request to delete the old now-outdated updates from hard disk 24 , creating space for new updates.

[0150] User interface 28 in conjunction with user interface 34 contains code providing a menu selection enabling a user to activate the update fetch operation and then to provide integrated or seamless access to the combined data, searching both the hard disk storage device 24 and the CD, using both sets of indexes, so that the contents are viewable as a single collection, although an additional independent searching/viewing function for the updates could be provided, if desired.

[0151] A product setup routine adapts the information transport component 14 to work with the news magazine CD-ROM's existing software for creation of a user interface, searching and viewing. Communications options may be limited to direct telephone dial only. A simple user interface addition controls a setup process allowing the user to enter a unique user ID, provided with each copy of the CD-ROM distribution disk, and to create predetermined work areas on the user's hard disk.

[0152] A schedule of updates with names, dates, and files sizes is provided in the containing news magazine product on the CD-ROM and is accessed via user interface 28 in conjunction with user interface 34 to create a fetch object manifest 48 . Optionally, user interface 28 in conjunction with user interface 34 creates a send object manifest 48 to control transport of user demographics for market analysis or for renewals, or the like, in the opposite direction from the user to the server, with the send operation being triggered whenever the next transport operation is activated, or optionally, by allowing the user to trigger it.

[0153] A fetched information object 46 , such as an update, is automatically decompressed and stored on hard disk storage device 18 as additional information object 26 for integration with the original CD-ROM product so that the user can view both the update and the original issues, and run searches across the entire collection.

[0154] Optionally, initial location of additional information object 26 may be an application work area location on storage device 18 , and communications component 36 may be pre-set to pass control via API 42 to database management module 30 which will do further processing to integrate additional objects in accordance with the existing database structure 32 to provide a more complete level of integration permitting, for example, viewing of combined menus, nullification of obsoleted items, and cross-linking of hypertext elements.

[0155] If a send object has been prepared and included in the object manifest, such as a send object containing user information entered during the install process, or subscription request information obtained from the user, it is sent to server 22 to be stored and identified by product and user ID for appropriate action in due course. Acknowledgment of receipt of the send object is noted by communications component 36 and passed back to the user if such provision is made in user interface 28 .

[0156] Both the fetch and send operations are closed ended in the sense of being operations that are pre-described in the original information product and once triggered, can be completed without human intervention of any kind.

[0157] To service the automated update facility running at the user's workstation, remote server 22 is set up to accept calls from valid user ID's, and is loaded with new issue text and index files, in the form of update information object 46 , according to a publication schedule.

EXAMPLE 2

[0158] Open-ended Fetch of a Supplementary News Magazine Object

[0159] Open-ended access to supplemental information objects not described in the original information product can be obtained by providing in the original product means to fetch a directory of added features. This can be used, for example, by a news magazine publisher to provide special news features on an unplanned basis, or each weekly issue could be packaged with a directory of additional features available. The user first specifies a fetch of the new directory, or receives it along with a fetched update they have specified from a user interface menu, and then views the fetched additional features directory and initiates a fetch of a selected additional item or items in a second information object transport operation, using an information object manifest built from the new features directory.

[0160] The original, containing product news magazine CD-ROM user interface 28 preferably has provision for importing and viewing any information objects listed on a completed fetch manifest and delivered by the information transport component 14 into the designated work areas. Alternatively, a standard information transport component 14 user interface 34 can be used to provide this function in a less integrated form.

EXAMPLE 3

[0161] Retail Catalog on CD-ROM with Merchandise Order Entry at the Server

[0162] Multimedia product catalogs with 800 ordering numbers are now available on CD-ROM and also with pre-installed software packages on new computer hard disks. In this example, the multimedia (or text and graphic) product catalog is a read-only information product 17 which can be furnished with an information transport component 14 according to the invention, to facilitate order placement from such electronic product catalogs providing an easier order placing process than has heretofore been possible. Employing the inventive information transport component 14 , a catalog vendor can enable a customer to place the order directly, via modem, without requiring a voice call and ensuing verbal product identification, by pointing and clicking a “Place Order” or “Mark for Order” button on the user's computer screen. The order is transported to remote server 22 using the novel information transport component 14 . Preferably a verification routine is included, requiring order confirmation with a user-supplied password, and possibly keying of the total amount to prevent unauthorized or inadvertent product ordering, for example by children.

[0163] Order fulfillment is effected by processing of the information in due course after receipt by the remote server 22 and any additional information required centrally is collected during product setup and held locally for transmission with an order. For example, setup can capture the user's charge card information, shipping address, and the like and create a header for an electronic order form.

[0164] When the user clicks the “Mark Order” button, procedures supplied with the user interface 28 , as modified through user interface API 40 , add order item identification information to an electronic order form. When the user clicks the “Place Order” button, user interface 28 triggers a transport request to server 22 , to include the order form as a send information object 46 . Transport of the send object, including the order form, from the user's station to the server is executed employing an object manifest 48 , as described herein.

[0165] If not located at a vendor's or merchant's premises, server 22 can forward received electronic orders to the merchant for fulfillment, at appropriate intervals, via a vendor link 50 .

[0166] This simple, low cost mechanism for automated order placement, can complement telephone ordering but lacks the credit-checking and inventory status capabilities that are frequently provided by phone. However, such a catalog application could allow the user to request the fetching of an inventory and price update object for use prior to the preparation of an order.

EXAMPLE 4

[0167] Merchandise Order Processing and Confirmation Retail Catalog on CD-ROM

[0168] A powerful electronic merchandising tool can be provided by providing the user with a full-function order generating capability and employing transporter 14 to transmit a user-created merchandise order, effortlessly and seamlessly, to a remote order-processing server. To this end, server 22 should be interfaced to the necessary merchant processing services for checking and reporting credit and inventory status.

[0169] An additional valuable option enables the system to apply pre-specified user instructions, previously obtained through user interface 28 , to determine whether out-of-stock items are to be dropped, back-ordered, or substituted in color or other aspect. This information can be added to the electronic order form object, listed in object manifest 48 and become the subject of a further transport dialog between the user's station and server 22 . In this manner a sophisticated purchase transaction is completed in a substantially unattended manner (save for deciding about back orders off-line), in as much as the customer does not have to maintain a phone conversation, while fully achieving the capabilities of telephone order placement. A further user benefit can be obtained by the providing a permanent record of the transaction (a stored electronic file) without user intervention. This not possible with telephone ordering.

[0170] This novel, automated, modem driven, order placement system effectively shields a merchant from having to deal with the problems of establishing communications with a mass of unknown end user computer systems, while automating the process and relieving the merchant of the costs of telephone sales staff. This aspect of the invention is valuable in avoiding troublesome, support intensive, communications which are subject to rapid technical change as new products are absorbed into the marketplace. In contrast, the merchant's special purpose vendor link 50 to the server 22 , can remain relatively stable, while the customer interface at server 22 , depending upon the sophistication and universality of the API's 40 and 42 , and also upon any emergent communications standards, can be adapted to accommodate a range of future products.

EXAMPLE 5

[0171] Further Applications of the Invention: Locked Information Products

[0172] As discussed in the “BACKGROUND OF THE INVENTION” hereinabove, some vendors, for example Microsoft Corporation, distribute information products in locked, inaccessible form, accompanied by (user-accessible) promotional information and demo versions. The prospective purchaser then calls an 800 number to order the product and is given a code which is entered to unlock the item for use. The inventive information transport component 14 and cooperative server component 22 , can be used to simplify this process, and eliminate the voice call.

[0173] The information transport component 14 is used to place the order and as a subsequent step concomitant with satisfaction of the merchants purchase requirements (payment, etc) can, employing a suitable line entry or entries in the object manifest 48 , fetch the access code, as an information object 46 , in the same way as an order acknowledgment or other information update. The user interface and data management components of the distribution CD, or original information product, can be programmed automatically to use the code to unlock the product.

[0174] Employing the novel, digital, modem-enabled communications products of the invention, more sophisticated access codes than are suitable for verbalizing to a caller, can be used, and may include small programs or decompression utilities (although these would better be stored in the locked product), or customer-specific coding employing user-derived information. Thus, as a safeguard against fraud, being equipped with specific user or user product information, the access code can be a key or product uniquely matched to the user's locked product copy.

[0175] Computer Software Updates: For distribution of updates to software products, the original distribution version of the software product can provide registered users with an appropriate ID code and update schedule. Should the revision be delayed, a revised schedule can be fetched.

[0176] Tax or other governmental filings and exchanges: An example of the generality of the inventive information transport system for sending and fetching well-defined information objects of many kinds is in the filing of tax returns. A send information object can be created and manifested to submit electronic tax filings to the IRS, as described above, for electronic product order forms. A fetch object can be created to obtain updated tax forms and the program logic relating to them, and to get information on new regulations. Analogous uses will be apparent to those skilled in the relevant arts of, for example, financial planning and portfolio management systems, to obtain current statistics, place orders, and the like.

[0177] Packaging of Transporter with User Interface/Database Search Software Facilities

[0178] In a modified embodiment, the inventive information transport component 14 is integrated with a general purpose user interface/database search (UI/DB) software package and tools. Such packages and tools, sometimes referred to as “authoring packages”, are now used to produce CD-ROM's and similar information products. Thus a single UI/DB product may contain the inventive information transport component 14 , and be supplied to publishers to be used to develop a family or diversity of information products, as a standard tool box.

[0179] A combination of the inventive information transporter product with such UI/DB products could facilitate development of applications by allowing much of the work of integrating a containing product's user interface 28 and database functions 30 and 32 (which could be controlled through the UI/DB product) with the inventive information transport component 14 to be performed once, in advance, by a UI/DB software vendor's skilled specialists, for use in a diverse range of products using that vendor's software. Such integrated offering would be advantageous to both the software vendor (by enriching its offering) and to the software vendor's publisher-customers by facilitating the desired function.

[0180] Electronic Product Distribution Service

[0181] In a valuable application of the novel electronic information transport products of the invention, remote server 22 can be operated to provide an electronic data product distribution service for multiple containing information products 12 , each equipped with an information transport component 14 , the whole facility providing a complete network distribution service, including network, technical and end-user support. Provision of such a distribution service is greatly facilitated by the novel transporter 14 , described herein, the use of which for each vended product greatly simplifies the problems of handling updates to multiple products. However, such a novel service could also be operated with conventional software communications products by relying upon users of each to execute an appropriate sequence of menu selection and command line instructions to obtain an update by modem via their own pre-existing communications software. Similarly, While special advantages of seamless user adoption and integration into an original product accrue from the use of the inventive transporter to distribute product updates, such a distribution service can be used with advantage to distribute any type of electronic information product.

[0182] For many publishers (and for providers of UI/DB authoring software) the task of operating a publicly available server 22 , and of supplying associated technical support to a wide base of customers using a diversity of communications products, even with the simplification benefits provided by the inventive transport product, is a task requiring specialized skills and staffing that a publisher, even one experienced in electronic publishing, will generally lack. Such a specialist capability is intimidating to provide and difficult to cost-justify for the limited number of information products that one publisher can supply.

[0183] By providing a new turnkey service or service bureau a specializing, skilled vendor would enable the publisher to avoid such burden. A provider of such a novel service can spread the costs of such operational activities and skilled staff across a large number of publishers and information products, achieving economies of scale and specialization.

[0184] The inventive information transport products extend to software implemented at server 22 , or at one or more clients or satellite servers, of a network served by server 22 , to provide the server-location functions of such an electronic product distribution service. Such distribution software can be separately marketed to publishers or UI/DB vendors who wish to operate such a service.

[0185] Gatewayed. “Open” Server

[0186] Example 4, above, shows how information transporter 14 , as well as server 22 can remain simple yet provide a highly general and extensible service. In that example, server 22 provides the functionality of a general-purpose transaction gateway or interface to an external function processor. In this particular case, the external function processor gatewayed by server 22 via vendor link 50 , is the merchant's order processing system, which receives the order, determines its disposition, and responds with order status information which is relayed back to server 22 for return to the customer as a response object in accord with protocols 38 and 44 . The user need not be aware of such complexities, nor do the client transport components 14 of the inventive product need to be aware of, or provide information for remote routing via vendor link 50 . Only the server 22 needs this information, and server 22 needs only to know that send objects with names that fall within a specified class for a specified product ID, must be forwarded to a specified external processor, and that the corresponding responses from that processor must be routed back to an originating client as response objects. Thus the inventive information transport component 14 , by virtue of its simplicity has general applicability and many uses, as described herein and as will further be apparent to those skilled in the art.

[0187] In implementing an ordering service using the inventive information transport component 14 , order and response objects are preferably formatted by the containing information product 12 to be consistent with existing or future electronic data interchange (EDI) standards which define protocols and formats for data interchange between customers and vendors. The information transport component 14 and the server protocol 44 provide the low-level EDI transport functions and are independent of object content defined by higher layers of the EDI protocol. Preferably, the server has added routing layer information to move objects to and from the external processor.

[0188] To provide a suitable EDI-compatible function, server <