Distributed application and data dissemination system

REFERENCE TO RELATED PATENT APPLICATIONS

[0001] The following applications are all assigned to assignee of this invention and are incorporated herein by reference:

[0002] 1. U.S. Ser. No. 07/700,704 entitled “SYSTEM FOR COUPLING A MULTIPLICITY OF RF DATA COLLECTION TERMINALS WITH HOST COMPUTER MEANS” filed on May 14, 1991 in the names of Gollnick et al., now abandoned in favor of U.S. Ser. No. 07/857,603, filed Mar. 30, 1992, now abandoned in favor of U.S. Ser. No. 07/947,102, filed Sep. 14, 1992, now abandoned; and

[0003] 2. U.S. Ser. No. 07/660,618 entitled “SYSTEM FOR PROCESSING COMMUNICATIONS WITH MULTIPLE PORTABLE RF DATA COLLECTION TERMINALS” filed Feb. 25, 1991 in the name of P. Miller, now abandoned in favor of U.S. Ser. No. 07/830,561, filed Jan. 30, 1992, now abandoned.

AUTHORIZATION PURSUANT TO 37 CFR 1.71(d) AND (e)

[0004] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0005] The present invention relates to a data capture system <b>10</b> illustrated in FIG. 1 for entering data at a plurality of remote locations using means such as a plurality of portable data collection terminals <b>12</b><i>a, b</i>-<i>n</i>. The data capture system <b>10</b> is applicable to receive and collect a wide variety of data and has found particular application in warehouses or retail store where a data capture system <b>10</b> would be used to keep an up-to-date record of the products to be marketed. Typically, the system <b>10</b> would be capable of updating on a real time basis the inventory count of products, and to use stock locator data to identify where each product of the remaining inventory is stored, when a product is moved from one place to another, and which employee has current charge of that product. In addition, when a product is sold, the price and sales person who sold the product are recorded.

[0006] Such data may be inputted into a terminal <b>12</b> by means of its keyboard <b>13</b>. For example, a terminal user could count the number of one type of product and enter that number via the terminal's keyboard <b>13</b>. Alternatively, data could be entered to the terminal <b>10</b> via a CCD bar code scanner <b>22</b>, which is electrically coupled by a cable <b>20</b> to its terminal <b>12</b>. In an illustrative embodiment of this invention, the scanner as illustratively identified in FIG. 1 by the numeral <b>22</b><i>a </i>and its terminal <b>12</b><i>a </i>could take the form of that modular scanner/terminal described in PCT international application WO90/16033 published Dec. 27, 1990. Differing types of scanners <b>22</b><i>b </i>and <b>22</b><i>n </i>could also be used with the terminals <b>12</b> and may illustratively take the form of those scanners described in U.S. Pat. No. 4,970,379 of Danstrom, U.S. Pat No. 4,882,476 of White, U.S. Pat. No. 4,894,523 of Chadima, U.S. Pat No. 4,877,949 of Danielson et al., U.S. Pat. No. 5,019,669 of Adams et al. and U.S. Pat. No. 4,924,462 of Sojka; International Application No. PCT/US90/03282 of Koenck et al.; and European Patent Publication No. 0 353 759 of Mahany et al.

[0007] The data capture system <b>10</b> utilizes illustratively RF transmission to bilaterally transmit data between each of the plurality of terminals <b>12</b><i>a, b </i>- - - <i>n </i>and a base radio transceiver <b>14</b>. By way of example, the base radio transceiver may illustratively take the form of that model RB3000 base radio transceiver manufactured by Norand Corporation, Cedar Rapids of Iowa. In turn, the base radio transceiver <b>14</b> is connected via a communications multiplexer <b>16</b><i>a </i>or a communications controller <b>16</b><i>b </i>to a host computer <b>18</b>. Illustratively, the multiplexer <b>16</b><i>a </i>could take the form of that model RM3200 as manufactured by Norand Corporation and the controller <b>16</b><i>b </i>could take the form of that controller identified as model RC2250 of Norand Corporation. The host computer <b>18</b> may illustratively be an International Business Machines Corporation PC of AT class or higher. As illustrated in FIG. 1, the host computer <b>18</b> includes a keyboard <b>28</b>, a display <b>24</b> and a system unit <b>26</b>.

[0008] Each of the portable data collection terminals <b>12</b><i>a, b </i>- - - <i>n </i>includes a transceiver (not shown in FIG. 1) for transmitting RF messages to and from the base radio transceiver <b>14</b>. A transmitted message comprises an initialization sequence, an address indicative of the particular terminal <b>12</b><i>a, b</i>- or <i>n </i>from or to which the message is directed, a message identifier and system information, the message data and/or control commands, error control, and an end of message indication. U.S. Pat. Nos. 4,910,794; 4,924,462; and 4,940,974, each assigned to the assignee of this invention and incorporated herein by reference, provide further information on RF data collection terminals and systems.

[0009] In a RF data capture system similar to that shown in FIG. 1 known as the RT1200 system of Norand Corporation, controlled RF transmission between a plurality of terminals and a radio base is established using a communications multiplexer similar to that of the multiplexer <b>16</b><i>a </i>shown in FIG. 1 to provide access to a particular one of the terminals <b>12</b><i>a, b </i>- - - <i>n</i>. The RT1200 system utilizes time division multiplexing on a single frequency channel. The RT1200 communications protocol is based on a sequential polling method that transmits a query addressed to each portable terminal in succession, and allows a specified amount of time for the addressed terminal to respond when the addressed terminal has a data message ready for transmission. U.S. Pat. No. 4,940,974 describes an improved, adaptive data communications system wherein the base radio transceiver <b>14</b> transmits a multi-terminal polling signal to each of its terminals <b>12</b><i>a, b </i>- - - <i>n</i>. That multi-terminal polling signal defines a series of successive response time slots in which the terminals <b>12</b> may randomly select to respond. A terminal <b>12</b> having a message to be transmitted to the host computer <b>18</b> via the base radio transceiver <b>14</b> transmits a brief response burst in the selected time slot giving its own unique identification address. After receiving the responses from the ready terminals <b>12</b>, the base radio transceiver <b>14</b> polls each of the responding terminals <b>12</b>, ignoring those terminals without messages to be transmitted. This system is adaptive in that the number of time slots may be changed depending upon the number of active terminals ready to transmit data messages.

[0010] The present invention is particularly related to adapting such data capture system <b>10</b> as shown in FIG. 1 to employ distributed processing concepts. Each of the portable data collection terminals <b>12</b> has a computer processing capability in the illustrative form of a microprocessor, whereby the entire system's processing capability may be distributed between the host computer <b>18</b> and the portable terminals <b>12</b>. The system <b>10</b> is structured in accordance with a client/server architecture whereby the host computer <b>18</b> acts as a server to each of the plurality of client terminals <b>12</b>, whereby programs may be dynamically loaded across that RF (or any serial) data link established between the host computer <b>18</b> and its terminals <b>12</b>.

[0011] The use of distributed processing is enhanced by relational database technology and the use of Structured Query Language (SQL) developed by the International Business Machines Company to provide access to relational databases. The use of relational database technology depends on organizing data in tables (or relations); each row of the table represents a record and each column represents an attribute. Various operations may be performed on these relations and, since the mathematics of these operations is very well understood, the results are predictable. An example of these operations is the “join”, where two or more relations may be put together based on some common attribute. The advantage of this organization is that data may be easily retrieved in a form not envisioned by the designers; that is, ad hoc retrievals are quite easy to perform.

[0012] A further concept of distributed processing is to partition the system so that data is available to all network users but the data physically resides where it is most likely to be processed This provides universal access without incurring severe communication overhead penalties. In the context of the data capture system <b>10</b> illustrated in FIG. 1, data is made available to each of the terminals <b>12</b> and to the host computer <b>18</b> by the use of the RF transmission between each of terminals <b>12</b> and the base radio transceiver <b>14</b>. However, employing the concept of distributed processing would direct that more data and application programs be stored within each of the terminals <b>12</b>, where such data is used or such programs executed. As a result, overhead penalties, primarily in terms of delays as would occur by the transmission of data between the terminals <b>12</b> and its host computer <b>18</b> are avoided.

[0013] In a client/server model, the server provides a general function to several client processes. Some of the more useful implementations of this concept are distributed databases, remote procedure calls and networked pipes. The distributed databases currently rely on some form of communication through Structured Query Language (SQL). These databases are comprised of front-end applications and a database server. The application interacts with the user. When database access is required, the application sends an SQL request to the database server which services the request across a network. This allows most of the processing to be done locally, but provides for a central data store that may be shared by many distributed users.

[0014] The remote procedure call concept allows systems to become specialized servers so that many applications may use their specialized hardware. To access these remote services, the application program makes a procedure call that is like any procedure call to the program's code. The difference is that the call results in a request to a remote system to provide the computation designated by the call.

[0015] The concept of “pipes” relates to supplying the output of one process to the input of another process. If the two processes are on different computers then this becomes a method of distributed processing. A variant of this method is the named pipe which allows select output to be input to another process over a named connection. This is the primary method of distributed inter-process communications with an OS/2 LAN Manager.

[0016] The efficient transmission of data to a remote terminal of a system is key to distributed processing. IBM's solution is their Distributed Data Management (DDM) protocols. These are a set of published IBM protocols that describe how to access files and databases on a remote system. IBM also developed a System Application Architecture (SAA) with common programming interfaces for program access to remote data on IBM SAA compliant systems. The importance of these protocols (which use LU 6.2 protocols for inter-system communication) is that a remote system such as a PC may access IBM host databases and files without having to program the host computer.

[0017] Remote data access in the non-IBM world is also becoming standard. The Network File System (NFS™) protocols (developed by Sun Microsystems but placed in the public domain) may be used to access or create files on any system running an NFS server. Novell Corporation is also providing similar services to a wide range of systems with its portable Netware™.

[0018] In current data capture systems employing a plurality of remote terminals <b>12</b>, the application program is run in the centrally disposed host computer <b>18</b> for real time control of the remote terminals <b>12</b>. Placing control in the host computer <b>18</b> increases significantly the hardware and software complexity forcing the host computer <b>18</b> to run multiple processes. Such application programs residing in the host computer <b>18</b> are complicated by the need to assure the concurrent control over shared data. Further, the host computer <b>18</b> must be fast enough to service all remote terminals <b>12</b> in real time. In such current data capture systems, the host computer <b>18</b> must normally validate data entry by the user and must respond to all user input, thus requiring significant amounts of data to be sent back and forth over an RF link between each of the terminals <b>10</b> and its host computer <b>18</b> as well as increasing the number of data transition session between the host computer <b>18</b> and its terminals <b>12</b>.

[0019] The present invention is related to the use of distributed processing concepts in a RF data capture system <b>10</b> as generally shown in FIG. 1 and, in particular, to improve the efficiency of such overall systems by improving the speed and efficiency of data transmission over the RF link between each of the terminals <b>12</b><i>a, b </i>- - - <i>n </i>and the base radio transceiver <b>14</b>.

SUMMARY OF THE INVENTION

[0020] It is therefore an object of this invention to enlarge and extend the range of a system for data collection.

[0021] It is a still further object of this invention to provide a new and improved mobile server which may be selectively moved from location to location, whereby data may be gathered from data collecting terminals at each of the locations.

[0022] It is a still further object of this invention to provide a new and improved system of distributive processing information stored at a main information center, at one or more remote sites and at an intermediate, mobile server.

[0023] It is another object of this invention to provide to employ a flexible wireless communication link or links which permit efficient transmission of data from a remote site to a main information center.

[0024] It is a still further object of this invention to provide a flexible wireless communication system which permits efficient radio transmission of data over different ranges to from one or more remote sites to a main information center.

[0025] It is another object of this invention to provide a new and improved distributed processing system employing a mobile client/server unit which acts as a server to a computerized data terminal disposed at a remote site and as a client to a server at the main information center.

[0026] In accordance with these and other objects of this invention, a system is described for collecting data from at least one remote site and transmitting the collected data to a main information center. The data collecting system has information distributed throughout and is divided into first, second, and third portions.

[0027] The system includes at least one portable terminal for collecting data at the remote site. The terminal comprises a device for collecting data and a first memory for storing the first information portion. The terminal operates illustratively by a programmed computer to sense the need for information for its use to generate an information call identifying the needed information, and to respond to the information call for searching its first memory for the presence or absence of that needed information. If that needed information is available in the first memory of the terminal, it is supplied for use by the portable terminal.

[0028] The data collecting system further comprises a first mobile server to be transported to various locations with respect to the main information center and the remote cite. The first mobile server comprises a second memory for storing the second information portion, and responds to the information call for searching the second memory for presence or absence of that needed information. The data collection system further includes a second server at the main formation center. The second server comprises a third memory for storing the third information portion, and operates as by a programmed computer to search the third memory for the presence or absence of that needed information. A first communication path interconnects the first mobile server and the data collection terminal for transmitting the collected data from the data collection terminal to the first mobile server. The programmed computer of the data collection terminal is responsive to the absence of that needed information within the first memory for transmitting from the calling terminal the information call via the first communication link to the first mobile server. The programmed computer of the first mobile server responds to the receipt of the transmitted information call to search the second memory for the presence therein of the needed information and, if present, for accessing the needed information from the second memory and for transmitting it via the first communication link for use by the calling terminal.

[0029] The data collection system further includes a second communication link which interconnects the first mobile server and the second server for transmitting the collected data from the first mobile server to the second server. The programmed computer of the first mobile server responds to the receipt of the transmitted information call from the calling terminal for searching the second memory for that needed information, and if absent, for retransmitting the information call via the second communication link from the first mobile server to the second server. The programmed computer of the second server responds to the receipt of the retransmitted information call from the first mobile server to search the third memory for that needed information and, if present, for accessing and transmitting that needed information via the first and second communication links for use by the calling terminal.

[0030] In a further aspect of this invention, the data collecting terminal comprises a first radio having a first transmission range. The first mobile server has a second radio of the first transmission range and a third radio of a second transmission range. The second server has a fourth radio of the second transmission range. The second transmission range is longer than the first range. The second server has a fifth radio of the first transmission range. The second communication link operates alternatively in a first short range mode wherein the second communication means comprises the first radio and the fifth radio when the first mobile server is transported to a location within the first transmission range from the main information center or in second long range mode wherein the second communication link comprises the third and fourth radios when the first mobile server is transported to a location beyond the first range.

[0031] In a further aspect of this invention, the first mobile server comprises at least first and second ports. The first communication link is coupled to both of the first and second ports. The programmed computer of the first mobile server periodically transmits through each of the first and second ports a message that the first mobile server is available to receive and to respond to the transmitted information call. The first communication link connects the data collecting terminal to one of the first and second ports. The data collecting terminal responds to the available message for transmitting via the connected one port a response message. The first mobile server senses which connected one port received the most recent response message from the data collecting terminal and transmits back to the data collecting terminal that needed information over the sensed one connected port, regardless of whether the data collecting terminal has been recently been reconnected to a different one of the first and second ports.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032]FIG. 1 is diagrammatic illustration of an existing prior art data capture system which may be upgraded to incorporate features of the present invention;

[0033]FIG. 2 is diagrammatic illustration of a data capture system configured in a client/server architecture to effect distributed processing in accordance with the teachings of this inventions

[0034]FIG. 3 is a functional block diagram illustrating the architecture of a portable data collection terminal as shown in FIG. 2;

[0035]FIG. 4 is diagram of the application program architecture as stored within the ROM of the portable data collection terminal shown in FIG. 3;

[0036]FIG. 5 is a flow diagram of the Program Manager program shown in the architecture diagram of FIG <b>4</b>;

[0037]FIG. 6 is a flow diagram of the Transaction Manager program shown in the architecture diagram of FIG. 4;

[0038]FIG. 7 is a functional block diagram of the database server shown in FIG. 2;

[0039]FIG. 8 is a diagrammatic showing of the architecture of the database server memory;

[0040]FIG. 9 is a flow diagram of the Presentation Manager program shown in the architecture diagram of FIG. 8;

[0041]FIG. 10 is a diagrammatic illustration of an expanded data capture system configured in a manner similar to that of FIG. 2 in a client/server architecture to effect distributed processing between a plurality of portable date collection terminals employing computers for executing programs and a mass storage for storing application programs and/or data to be selectively transmitted under the control of a data base server for use by the computer of a designated terminal, but further including a wide area network to which the mass storage is connected and a mobile access server (MAS) for controlling in response to a call from a determined one of the terminals the flow of application programs and/or data from the mass storage to the determined terminal;

[0042]FIG. 11 is a functional block diagram illustrating the architecture of the mobile access server as shown in FIG. 10;

[0043]FIG. 12 is a flow diagram of the program executed by a computer included within the mobile access server as shown in FIG. 11; and

[0044]FIG. 13 is a flow diagram of a subroutine incorporated within the program of FIG. 12 for keeping track of the present location of those determined portable terminals within the system of FIG. 10 which place a call for a further application program or part thereof, and/or data.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0045] Referring now to the drawings and, in particular to FIG. 2, there is shown a data capture system <b>110</b> in accordance with the teachings of this invention, where elements similar to those of FIG. 1 are identified by like numerals but in the 100's series. The data capture system <b>110</b> includes a plurality of portable data collection terminals <b>112</b><i>a, b </i>- - - <i>n</i>, which in an illustrative embodiment of this invention may take the form of that terminal RT1100 as manufactured by Norand Corporation. Each terminal <b>112</b> includes, as shown in FIG. 3, a radio module <b>152</b> which is capable of receiving and transmitting RF signals to a base radio transceiver <b>114</b>, which may illustratively take the form of that model RB3000 base radio transceiver as manufactured by Norand Corporation. The RB3000 base radio transceiver <b>114</b> is capable of operating at multiple baud rates as described in U.S. Pat. No. 4,910,794. In turn, the received signals are transmitted to a database server <b>130</b>, which in response to the received signals applies signals to the base radio transceiver <b>114</b> to be transmitted to a selected one of the plurality of the terminals <b>112</b>. Each message transmitted between one of the terminals <b>112</b> and the transceiver <b>114</b> includes an identification number or ID indicating the originating terminal <b>112</b> or its user. In turn, the database server <b>130</b> is coupled to a host computer <b>118</b>. In an illustrative embodiment of this invention, the host computer <b>118</b> may take the form of an IBM 3090 main frame with a DB2 database engine. As will be explained in detail below, each terminal <b>112</b> is programmed to compose an SQL request that will cause the database server <b>130</b> to return an application program, a memory overlay or application specific data to the requesting terminal <b>112</b>. The host computer <b>118</b> may also access the database server <b>130</b> by generating and transmitting SQL request messages thereto.

[0046] The host computer <b>118</b> has a database, which is accessible through the database server <b>130</b> to respond to the SQL request from one of the terminals <b>112</b>, supplying to the requesting terminal <b>112</b> a computer program, memory overlays or application specific data. The host computer <b>118</b> may illustratively take the form of an IBM 3090 main frame with a DB2 database engine and would have a memory of a capacity many orders greater than that of the terminals <b>112</b>. Much of the data and software to be used by the terminals <b>112</b> need not be stored with in the terminal's memory, but rather may reside in the database of the server <b>130</b> or in the memory of the host computer <b>118</b>. Thus, when that data and/or program stored in the database server <b>130</b> is needed, the needing terminal <b>112</b> formulates its SQL request message, transmits that message via the base radio transceiver <b>14</b> to be processed by the database server <b>130</b>, which accesses its database (or the memory of the host computer <b>118</b>) and retransmits the requested data or programs back to the requesting terminal <b>112</b>. At least two tables are defined as shown in FIG. 7 in a memory of the database server <b>130</b> including a first program table <b>139</b> and a second authorization table <b>141</b>. The program table <b>139</b> keeps track of all of the programs, the overlays and the locations where they are stored in the database of the server <b>130</b>. The programs are typically stored as a “bulk” or “binary” data type. The program table requires at a minimum the following fields or attributes: <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><thead><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row><row>&lt;entry /&gt;<entry>attribute</entry><entry>type</entry><entry>description</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>program</entry><entry>char</entry><entry>Name of the program</entry></row><row>&lt;entry /&gt;<entry>name</entry></row><row>&lt;entry /&gt;<entry>overlay</entry><entry>char</entry><entry>root or other named overlay</entry></row><row>&lt;entry /&gt;<entry>date</entry><entry>char or date</entry><entry>Date program was created (revision</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>control)</entry></row><row>&lt;entry /&gt;<entry>program</entry><entry>varbinary or</entry><entry>The actual program or overlay</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>varchar</entry></row><row>&lt;entry /&gt;<entry>size</entry><entry>integer</entry><entry>The size of the binary to be</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>loaded</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0047] As will be explained later with respect to FIG. 7, the first, program table <b>139</b> and the second authorization table <b>141</b> may be established within a hard disk drive <b>137</b> of the database server <b>130</b>. The SQL request includes an attribute to identify whether a new program or an overlay is to be accessed and sent by the requesting terminal <b>112</b>, and the address or name of the first program table <b>139</b>. The SQL request does not need to have the address of the requested program or overlay, but accesses the program table <b>139</b>, which provides an address within the hard disk drive <b>137</b> in accordance with the attribute. As will be explained, the database server <b>130</b> in response to the SQL request accesses a particular program or overlay and transmits it back to the requesting terminal <b>112</b>.

[0048] The second authorization table <b>141</b> identities the relationship between a particular user and each of the programs which that user is authorized to access. For example, each user has an ID and the authorization table <b>141</b> would list the program names which may be accessed by that particular user ID. Similarly, the SQL includes the ID and an address for the authorization table <b>141</b>. Thus, the SQL request accesses the authorization table <b>141</b> to see if the requesting terminal <b>112</b> or its user as identified by the ID is permitted to use a particular program or overlay. If there is a match between the ID and one of the listed programs stored in the authorization table <b>141</b>, then as will be explained, the database server <b>130</b> will access that program or overlay and transmit it back to the requesting terminal <b>112</b>. On the other hand, if the ID is not found within the authorization table <b>141</b>, the requested program or overlay is not transmitted back to the requesting terminal <b>112</b>.

[0049]FIG. 3 shows an illustrative embodiment of the hardware architecture of the elements of the portable data collection terminals <b>112</b>. Each terminal <b>112</b> includes a data bus <b>142</b> for interconnecting the element of the terminal <b>112</b>, which may include a ROM <b>144</b> for the bootstrap loader a flash ROM <b>150</b> for storing system and application programs, a static RAM (SRAM) <b>146</b> for storing data, programs and dynamically loadable program overlays, a microprocessor <b>140</b> which may take the form of that processor made by NEC as a model V25, the radio module <b>152</b>, a serial communication interface (UART) <b>148</b> for the radio module <b>152</b>, a bar coding scanning interface <b>149</b>, a manual input system such as a keyboard <b>113</b> and a display <b>115</b>. The serial communication interface <b>148</b> permit messages to be transmitted and received via the radio module <b>152</b>. The keyboard <b>113</b> and the-bar code scanning interface <b>149</b> permit data entry respectively by the terminal user and a CCD bar code scanner similar to those identified in FIG. 1 by the numeral <b>22</b>. As is well known in the art, a scanner <b>22</b> would be moved across coded data to provide data descriptive of the item to which the bar code was attached, typically including a description of the item, its price and/or other inventory data.

[0050] Appreciating that each terminal <b>112</b> is battery operated, a plurality of memories <b>144</b>, <b>146</b> and <b>150</b> are provided therein to store various types and sizes of data and programs dependent upon their use and to the end, that battery drain be minimized. The ROM <b>144</b> stores the operating system and basic input/output system (BIOS) for the microprocessor <b>140</b>. The SRAM <b>146</b> stores the dynamically loadable program overlays and data. The flash ROM <b>150</b> stores the system operating program and the application programs to be executed by the microprocessor <b>140</b>, typically carrying out the various inventory functions for which a terminal <b>112</b> may be programmed. A portion of the SRAM <b>146</b> is partitioned into tables for application specific data, i.e., data to be used by the stored application programs. It is a significant aspect of this invention, that not all of the application programs or application specific data which may be used by a terminal <b>112</b>, should be stored in the SRAM <b>146</b>, but rather that significant portions of the application programs and specific data may be stored in the database server <b>130</b> (or even in the host computer <b>118</b>) to be accessed when needed by a particular terminal <b>112</b>.

[0051] The architecture of the software stored in the flash ROM <b>150</b> is shown in FIG. 4. The flash ROM <b>150</b> stores a plurality of application programs <b>154</b>, e.g., inventory tracking, a program manager program <b>156</b> explained below with respect to FIG. S for transmitting the SOL request to the database server <b>130</b> to obtain an overlay module or a new program, a transaction manager <b>158</b> as explained below in detail with respect to FIG. 6 for opening a new session to receive or to transmit streams of data thereto, and a radio protocol stack <b>160</b> for effecting the RF transmission of a data stream <b>161</b><i>a </i>out to the database server <b>130</b> and for receiving an RF transmission via a data stream input <b>161</b><i>b </i>from the database server <b>130</b>. An application interface <b>155</b> is established between the application programs <b>154</b> and the program manager <b>156</b>, whereby any of the application programs can request the services of the program manager <b>156</b>, which may be illustratively thought of as a collection of sub-routine calls for new overlay modules or a new program as will be explained below with respect to FIG. 5. Further, the application programs <b>154</b> have a transaction application programming interface (API) <b>157</b> with the transaction manager <b>158</b> as will be explained below with respect to FIG. 6. The transaction API <b>157</b> permits an application to transmit a SQL request to the database server <b>130</b>. In turn, the transaction manager <b>158</b> has an interface <b>159</b> as exemplified by a NetBIOS with the radio protocol stack <b>160</b>, which effects by RF transmission the sending and receiving of data to and from the database server <b>130</b>. As indicated by the architecture of the data stored within the flash ROM <b>150</b> shown in FIG. 4, the radio protocol stack <b>160</b> is transparent with respect to an application program, i.e., the application program need not be programmed to effect radio transmission but only to place a call to transmit or to receive data, Either the program manager <b>156</b> or the transaction manager <b>158</b> carries out that step without any special program of the application programs <b>154</b>.

[0052] The database server <b>130</b>, as shown generally in FIG. 2, may illustratively take the form of an IBM PS/2 model 80 computer running IBM's OS/2 Extended Edition operating system. Generally, the database server <b>130</b> responds to a SQL request transmitted by a radio module <b>152</b> of a data collection terminal <b>112</b> (see FIG. 3), or from the host computer <b>118</b>. The response of the database server <b>130</b> to the SQL request is determined by the semantics of that SQL request, which is formatted in the ANSI standard SQL. The database server <b>130</b> need not store state information about each of the terminals <b>112</b><i>a, b </i>- - - <i>n</i>. Data relating to a particular or specific terminal <b>112</b> is assigned to its own memory table, which may be illustratively formed at its unique address within a DRAM <b>136</b> of the database server <b>130</b> as shown in FIG. 7. That table for terminal specific data may be used as a buffer, where the addressed location within the DRAM 1436 acts as a buffer memory to be addressed by a SQL request and in response thereto, to transmit the data stored in that buffer to the requesting terminal <b>112</b>. Alternatively, the terminal specific data could be stored in the hard disk drive <b>137</b> of the database server <b>130</b> and could be accessed by assigning an identifier attribute for that data to each terminal <b>112</b>, whereby the appropriate relation in the hard disk drive <b>137</b> of the database server <b>130</b> could be defined. As will be explained, each SQL request identifies a new program, an overlay or application specific data which is required by the requesting terminal <b>112</b>; the database server <b>130</b> responds to that request and transmits in turn the requested program, memory overlay or application specific data to the particular requesting terminal <b>112</b>.

[0053]FIG. 7 shows the hardware architecture of the database server <b>130</b>, including a data bus <b>134</b> for connecting the various elements thereof, a microprocessor <b>132</b> illustratively taking the form of that processor manufactured by Intel under its model No. 80386, a ROM <b>135</b> for the computer power up program, the diagnostic programs and the BIOS program, the dynamic RAM (DRAM) <b>136</b> serving as a memory for a database server program, server data, and a “cache” memory for the database, and a mass storage in the illustrative form of the hard disk drive <b>137</b> for storing all of the partitioned application programs and application specific data to be called by the plurality of terminals <b>112</b><i>a, b </i>- - - <i>n</i>. The database server <b>130</b> may provide gateway functions to other databases, e.g., DB2. In an operational sense, a gateway function permits access to a remote database by passing and/or reformatting the request. In other words, the SQL request could be translated into a format that would correspond and be recognized by that format of the remote database.

[0054] Referring now to FIG. 3, the SRAM <b>146</b> of a portable data collection terminal <b>112</b> is significantly smaller than the disk drive <b>137</b> of a database server <b>130</b> and may have a capacity insufficient to store all of an application program and data to be executed by its microprocessor <b>140</b>. Distributed processing is accomplished in the context of this data capture system <b>110</b> employing a plurality of terminals <b>112</b> and a database server <b>130</b>, by partitioning each application program into a plurality of parts or modules. The first program part is known as a root module and will be loaded first when a request for a new program is issued by the microprocessor <b>140</b> at power up or entered by a user through the terminal's key board <b>113</b>. There will be at least one and typically many further parts known as memory overlays or overlay modules. The root module and the overlay modules will be given unique identifiers so that they may be loaded when requested. When the microprocessor <b>140</b> is executing the last instruction of a root module or an overlay module, then it is necessary to request and retrieve the next overlay module to permit the application program to continue to be executed without interruption. As will be explained below, this data capture system <b>110</b> is capable of formatting a SQL request for that original program or root module and for the subsequent overlay modules. In the simplest embodiment of this invention, the programmer builds into the application program a request to the program manager program <b>156</b> (see FIG. 4) to request and load an overlay module and jump to it. In a more sophisticated version, a program in the development environment determines the external function calls in program and substitutes a call to the program manager program <b>156</b>. The development in partitioning of an application program is accomplished on the database server <b>130</b> using a data collection terminal emulator system that emulates the keyboard <b>113</b>, the display <b>115</b> and other possible peripherals of the terminal <b>112</b>. The only programming to be done specific to the database server <b>130</b> is to create the database tables and load them with any application specific data.

[0055] The software architecture of the DRAM <b>136</b> as shown in FIG. 7 is further described in FIG. 8, as being partitioned to store a commercial database management system <b>212</b> such as the SQL Server (Microsoft), a database gateway <b>214</b>, e.g., a DB2 Gateway by IBM, a presentation manager <b>216</b> to be more fully disclosed in the flow diagram of FIG. 9, a network protocol stack <b>218</b>, and a radio protocol stack <b>220</b>.

[0056] The program manager program <b>156</b> generally shown in the software architecture diagram of FIG. 4 is more fully shown in the flow diagram of FIG. 5. Basically, the program manager program <b>156</b> is disposed in the next lower layer below an application program, e.g., an inventory program, and responds to its request for either a new program or a memory overlay, to configure and transmit an SQL request to the database server <b>130</b>. Upon receipt of the requested program or memory overlay, the program manager program <b>156</b> stores it in SRAM <b>146</b> before initiating its execution by the microprocessor <b>140</b>. A start <b>162</b> is initiated in a number of ways by the associated application program. At power up when typically there is no application being executed, the operating system program, which is stored in the ROM <b>144</b>, places a call to the program manager <b>156</b>. Alternatively, a new application program may be called by the operator by actuating a selected key(s) of the keyboard <b>113</b>. Appreciating that all of a particular application program need not be stored in the SRAM <b>146</b>, overlay modules of the application program presently being executed may be stored in the database of the server <b>130</b> and may be called by the program manager program <b>156</b>. The application program continues to be executed until it recognizes that the next step is not available, at which time it places a call through the start step <b>162</b> for the next section or overlay module of the application program to be retrieved and placed in the SRAM <b>146</b> of the requesting terminal <b>112</b>.

[0057] After a start has been provided in any of these ways, step <b>164</b> determines whether a new program or memory overlay is being requested. If a new program is requested, step <b>166</b> accesses the database in the server <b>130</b> for the requested program. In particular, step <b>166</b> initiates the radio protocol stack program <b>160</b>, whereby the radio module <b>152</b> (see FIG. 3) is activated to transmit the SOL request to the database server <b>130</b> via the transceiver <b>114</b> (see FIG. 2). The SQL request initiated by step <b>166</b> seeks as will be described below a list of programs which are stored in the database server <b>130</b> and is available to this originating terminal <b>112</b>. Initially, step <b>166</b> calls the radio protocol stack program <b>160</b> (see FIG. 4), whereby access is made through the UART <b>148</b> (see FIG. 3) to the radio module <b>152</b> turning module <b>152</b> “on” to transmit the SQL request to the transceiver <b>114</b>. In addition to actuating the radio module <b>152</b>, the radio protocol stack <b>160</b> provides the protocols and media access to allow the SQL request to be sent via the transceiver <b>114</b> to the database server <b>130</b>. Illustratively, the radio protocol stack <b>160</b> would include the RTC system as described in U.S. Pat. No. 4,940,974. When the radio protocol stack <b>160</b> is called to initiate transmission, a session is said to be held between the requesting terminal <b>112</b> and the database server <b>130</b>. For example, when a SQL request is generated by the transaction manager <b>158</b> (see FIG. 4), a session is opened. Each session enjoys a logical relationship between the requesting terminal <b>112</b> and the database, e.g., the hard disk drive <b>137</b>, within the database server <b>130</b>. Each session includes one or more data packets, the data packet being the maximum byte size of the data stream appearing on the output <b>161</b><i>a </i>that may be transmitted by the radio module <b>152</b>. The radio protocol stack <b>160</b> functions to segregate a data stream out <b>161</b><i>a </i>to be transmitted to the database server <b>130</b>, into a number of data packets and, in similar fashion, to reassemble the data packets of an incoming data stream appearing at the input <b>161</b><i>b </i>into a continuous data stream. Each SQL request includes an address or ID of its originating terminal <b>112</b>. As will be explained later, the database server <b>130</b> uses a presentation manager program <b>216</b> to store the relationship mapping) between the terminal ID and the operating system session identifier, which is stored in a known location within the DRAM <b>136</b> of the database server <b>130</b>. In this way, the database server <b>130</b> remembers to which of the plurality of terminals <b>112</b><i>a, b </i>- - - <i>n </i>that the requested data or memory overlay, should be transmitted.

[0058] The database server <b>130</b> operating as will be explained, will respond to the SQL request for a program overlay by accessing a list of programs authorized for the particular requesting terminal <b>112</b> or user and transmitting that list back via the transceiver <b>114</b> to the requesting terminal <b>112</b>. Illustratively, step <b>166</b> may format an SQL request in the following manner:

[0059] select distinct program_name from authorization where user_id=“morrismd”

[0060] Here the SQL request is seeking a list of distinct programs, not duplicates, which have been authorized for transmission to a particular user, i.e., a particular terminal <b>112</b>. In the illustrative request, the user ID is “morrismd”; in other words, all program names having an ID attribute “morrismd” are distributed to the requesting terminal <b>112</b>. Next, step <b>168</b> displays the received list of authorized programs on the terminal's display <b>115</b>.

[0061] In step <b>170</b> of FIG. 5, the terminal user selects from that list of available programs as displayed in step <b>168</b> and enters via the terminal keyboard <b>113</b> the selected program to be requested from the database of the server <b>130</b>. When a program is selected from the menu displayed upon the display <b>115</b> (see FIG. 2) by user actuation of the keyboard <b>113</b>, the transaction manager <b>158</b> (see FIG. 6) is called to format the SQL request to retrieve from the remote database the particular program selected in step <b>170</b>. An illustrative example of such an SQL request may take the form of:

[0062] select program from program_table where program_name=“inventory.exe” and overlay=“root”

[0063] Illustratively, the SQL request accesses the first, program table <b>139</b> (see FIG. 7) to obtain the address in the hard disk drive <b>137</b> of the requested program, e.g. the “inventory.exe” program, which is an original program or it's root overlay.

[0064] After transmission of the SQL request for a new program, step <b>174</b> waits for a returned message to the terminal <b>112</b> and will time out after a set period, e.g., 30 seconds. If no response is received by the requesting terminal <b>112</b> within this period, step <b>176</b> generates a return error message and returns it to the calling application program. On the other hand if the requested original program is received within the period, step <b>178</b> updates a mapping memory or table, which may be illustratively included within the SRAM <b>146</b> (see FIG. 3) of the terminal <b>112</b>. A record of the application program or module thereof presently being executed by the microprocessor <b>140</b> is recorded in the mapping memory in terms of its starting address and length. When a new program is received and loaded into SRAM <b>146</b>, step <b>178</b> records its starting address and length in the mapping memory, before loading the root module of the new program into a designated location of the SRAM <b>146</b> and, thereafter, initiates execution of the received and loaded program instead of returning control to the application program. The SRAM <b>146</b> is used as a “cache” memory to receive the <b>140</b> programs and memory overlays to be executed by the microprocessor <b>140</b>. Thus, the SRAM <b>146</b> provides a local memory from which the application program may be executed, whereas the remaining sections or memory overlays of the application program and other original programs may be stored distantly in the database of the server <b>130</b>.

[0065] It is appreciated that application programs are sometimes larger than it's sections or memory overlays. Therefore to efficiently use the local memory, e.g., the SRAM <b>146</b>, new programs are illustratively stored in the database of the server <b>130</b>, whereas program overlays may be stored in both the database of the server <b>130</b> and in the local memory, i.e., the SRAM <b>146</b>. Therefore, if step <b>164</b> determines that the application is not requesting a new program, but rather an overlay module, step <b>180</b> examines the SRAM <b>146</b> and if the requested overlay module is in SRAM <b>146</b>, the program moves to step <b>178</b> to initiate execution of the overlay module and control is passed to the overlay module. However, if the requested overlay module is not in the SRAM <b>146</b>, step <b>180</b> moves control moves to the transaction manager <b>158</b>, which formulates and transmits a SQL request via the transceiver <b>114</b> to retrieve the needed overlay module from the database of the server <b>130</b>. The requested memory overlay is transmitted back via the transceiver <b>114</b> and is loaded into SRAM <b>146</b> and, thereafter, the local mapping memory in SRAM <b>146</b> is updated in terms of its starting address and length. After step <b>174</b> determines that the requested program has been timely received as explained above, step <b>178</b> initiates execution of the overlay module before returning control to the application program.

[0066] Referring now to FIG. 6, there is shown the transaction manager program <b>158</b> which responds to a call from the application program <b>154</b> (see FIG. 4) for data to be processed thereby and provides an application programming interface (API) <b>157</b> to the application program which allows it to access the database in the server <b>130</b>. The transaction manager program <b>158</b> also supports the program manager program <b>156</b> to access programs stored in the database of the server <b>130</b>. Thus, it is seen that the program manager program <b>156</b> of FIG. 5 accesses remote programs and overlay modules whereas the transaction manager <b>158</b> of FIG. 6 accesses any kind of data. Initially, step <b>194</b> determines whether the requested data is in the local memory, i.e., SRAM <b>146</b>, and, if so stored, step <b>208</b> returns the local data to be processed by the application program. If not, step <b>196</b> formats an SQL request for the requested data and step <b>198</b> calls the radio protocol stack program <b>160</b> (see FIG. 4) thus actuating the radio module <b>152</b> and transmitting the SQL request via the transceiver <b>114</b> to access the requested data in the database of the server <b>130</b>. Step <b>200</b> waits while the server <b>130</b> accesses the requested data and transmits it via the transceiver <b>114</b> to the requesting terminal <b>112</b>. Step <b>200</b> times a response period, e.g., 1 minute, and if that period is exceeded indicating an error condition, step <b>202</b> returns an error message to the calling application program. If the data is received within the response period, step <b>204</b> formats the requested data in a form usable by the calling application program, before step.<b>206</b> returns that data to the application program. Step <b>206</b> returns the data to the SRAM <b>146</b>, whereby control is passed to the application program which uses the returned data.

[0067] The presentation manager program <b>216</b>, shown in FIG. 9, processes the SQL request transmitted from one of the terminals <b>112</b> (see FIG. 2) via the transceiver <b>114</b> and a standard interface, e.g. Unix sockets or IBM NetBIOS, to the database manager program <b>212</b> (see FIG. 8). The database manager program <b>212</b> interprets the SQL request and accesses the hard disk drive <b>137</b> accordingly (see FIG. 7). This allows an application program being executed by the microprocessor <b>140</b> (see FIG. 3) to establish sessions with any SQL accessible database as maybe formed within the hard disk drive <b>137</b> of the database server <b>130</b>. The principle function of the presentation manager program <b>216</b> is to translate between that format used by the transaction manager program <b>158</b> of a terminal <b>112</b> and the SQL format of the database of the hard disk drive <b>137</b>, if these formats are different. The SQL request to be applied to the database management program <b>212</b> is semantically configured in accordance with the function to be achieved. The SQL request may direct that data be inserted into the disk drive <b>137</b>, that data be accessed and retrieved, that a new program or overlay module be retrieved from the disk drive <b>137</b>, that data be added to one or more fields in a set of records stored in the disk drive <b>137</b> or that data be deleted from one or more records of the disk drive <b>137</b>. Updating involves the transmitting of new variable values from the originating terminal <b>112</b>.

[0068] Referring now to the flow diagram of FIG. 9, the presentation manager program <b>216</b> enters through start step <b>230</b> to step <b>232</b>, which waits for a SQL request to be forwarded from the radio protocol stack <b>220</b> (see FIG. 8). As will be described below, the SQL request is directed toward the database manager program <b>212</b>. step <b>234</b> receives the SQL request as a sequence of bytes. Step <b>236</b> comes into play only if some reformulation of the SQL request is necessary. In a first instance, if the database manager program <b>212</b> was not adapted to support the ANSI standard SQL format or if the SQL request was compressed, then step <b>236</b> would be necessary to decompress the data or to translate the format of the SQL request into that of the particular database manager program <b>212</b> employed in the system. Next, step <b>238</b> provides the data to the database manager program <b>212</b> through an interface in the illustrative form of the IBM NetBIOS interface. The translation step <b>236</b> is identical to the formatting request <b>196</b> of the transaction manager program <b>158</b> of FIG. 6 and, ordinarily, it would be only necessary to perform the formatting or translation step once upon a particular SQL request, preferably in the presentation manager program <b>216</b>. Step <b>240</b> waits for the database manager program <b>212</b> to access the disk drive <b>137</b> for a predetermined time period. If the requested material, i.e., the application specific data, root overlay or memory overlay, is received within the time period, it is translated in step <b>242</b> to the format of the requesting terminal <b>112</b>, before calling in step <b>244</b> the radio protocol stack program <b>220</b> to transmit the accessed material back to the requesting terminal <b>112</b>. On the other hand, if the SQL request is one to add or delete data from the hard disk drive <b>137</b>, step <b>240</b> generates a status message indicating that the change of the hard disk drive <b>137</b> has been completed, before step <b>242</b> translates that status message into the terminal format and the radio protocol stack <b>220</b> is called in step <b>244</b> to send that message back to the requesting terminal <b>112</b>. If the time period set in step <b>240</b> times out, without receiving the requested material, step <b>246</b> transmits an error packet to the radio protocol stack program <b>220</b>, whereby an error message is returned to the requesting terminal <b>112</b>.

[0069] Thus, there has been described a data capture system <b>110</b> that distributes the application program between the memory of a terminal <b>112</b> and a database server <b>130</b> serving a plurality of such terminals <b>112</b>. In this fashion, the complexity of the program to be executed upon a terminal <b>112</b> is minimized by permitting the data base server <b>130</b> and its hard disk <b>137</b> to store a large variety of application programs to be served to its client terminals <b>112</b>. The above data capture system <b>110</b> permits dynamic loading of the original programs or root modules and subsequent memory overlays from the hard disk <b>137</b>, whereby the size of the SRAM <b>146</b> of a terminal <b>112</b> and the power required by the terminal <b>112</b> is minimized. Further, the amount of data transmitted via the RF link between each of the plurality of terminals <b>112</b> and the database server <b>130</b> is minimized. Further, the database server <b>130</b> provides a “user friendly” environment for the development of application programs for the terminals <b>112</b>. In particular, the database server <b>130</b> is capable of readily developing both the client and server portions of the application programs to be executed by the terminals microprocessor <b>140</b>.

[0070] Referring now to FIG. 10, there is shown a further, alternative embodiment of this invention in the form of a data capture system <b>310</b> where elements similar to those shown in FIGS. <b>2</b>-<b>9</b> are identified by like numerals but in the 300 series. In particular, the data capture system <b>310</b> comprises a plurality of portable data collection terminals <b>312</b><i>a, b </i>- - - <i>n</i>, a vehicle <b>329</b> for transporting a mobile access server (MAS) <b>331</b> as will be described in detail below with respect of FIG. 11, a mass storage as incorporated into an application server <b>330</b> and a wide area network <b>333</b> to which the application server <b>330</b> is connected.

[0071] Generally the purpose of the data capture system <b>310</b> is similar to that of the system <b>110</b>. In particular, the system conveys data from the data collection terminals <b>312</b> as deployed at a remote location in the illustrative form of a warehouse or delivery site <b>308</b>, to a main information or control center <b>306</b>. In return, the system <b>310</b> responds to a call from a determined data collection terminal <b>312</b> to convey selected portions of a new application program, an application overlay and/or application specific data to the determined, calling terminal <b>312</b> for use by a computer incorporated within each of the terminals <b>312</b>.

[0072] The wide area network <b>333</b> is illustratively coupled via a bidirectional data/program transmission path, e.g., a leased telephone line <b>337</b>, to a gateway <b>339</b>, which in turn is connected to a second bidirectional data/program transmission path in the illustrative form of an ethernet <b>341</b>. The wide area network is also connected to a long range radio module <b>347</b>, which in turn is connected to an antenna <b>335</b>. It is appreciated that any number of antennae <b>335</b> and related modules <b>347</b> may be also connected to the network, and/or that the wide area network <b>333</b> may permit transmission over great distances from each of the antennae to the main information center <b>306</b>. The gateway <b>339</b> interconnects the transmissions lines <b>337</b> and <b>341</b>. AS shown in FIG. 10, the ethernet <b>341</b> is coupled to the application server <b>330</b> which incorporates the mass storage, a transceiver <b>314</b> and a terminal or remote server <b>343</b>. The remote server <b>343</b> permits access to the application server via a suitable dial up link such as conventional telephone lines. The gateway <b>339</b> controls or directs the flow of data and/or programs between the leased line <b>337</b> and selected of the devices <b>330</b>, <b>314</b> and <b>343</b> as may be connected to the ethernet <b>341</b>. In particular, the gateway <b>339</b> functions to address the information flow from the line <b>337</b> to selected of the connected devices <b>330</b>, <b>314</b> and <b>343</b>.

[0073] A first wireless communication capability as identified by the numeral <b>347</b> exists between the MAS <b>331</b> and each of the plurality of data collection terminals <b>312</b><i>a, b </i>- - - <i>n</i>. A second wireless communication capability as identified by the numeral <b>349</b> is established between the MAS <b>331</b> and the wide area network <b>335</b> and, in particular, the antenna <b>335</b> connected to one end of the network <b>335</b>. It is significant that the MAS <b>331</b> be mobile to permit it to move, e.g., to be transported by the vehicle <b>329</b>, to any number of sites. For example, the data collection system <b>310</b> in contrast to the system <b>110</b> is adapted to collect data at a plurality of sites and from distinct pluralities of terminals <b>312</b> as are located at corresponding sites. Such operation contemplates that the vehicle <b>329</b> is capable of transporting its MAS <b>331</b> from site to site, whereat the MAS <b>331</b> will facilitate the transmission of the collected data from the corresponding set or plurality of data collection terminals <b>312</b> to the wide area network <b>335</b>. Alternatively, the vehicle <b>329</b> may be equipped with docks (not shown) which are coupled by hardwired links to the MAS <b>331</b>. Such an arrangement would permit the data collection terminals <b>312</b> to be brought to the vehicle <b>329</b> and loaded into a dock before the collected would be downloaded over the hardwired link to the MAS <b>331</b>.

[0074] As illustrated in FIG. 10, the MAS <b>331</b> may move from that position adjacent to the delivery site <b>308</b> to another position adjacent the main information center <b>306</b>; in this latter position, a third wireless communication capability identified by the numeral <b>351</b> is available to transmit the information flow directly between the MAS <b>331</b> and the ethernet <b>341</b>, without the need for using the leased line <b>337</b>. As will be described in detail below, each of the wireless communication capabilities <b>347</b>, <b>349</b> and <b>351</b> respectively include a single transceiver coupled with and operated under the control of the MAS <b>331</b> and a transceiver included within each of the data collection terminals <b>312</b><i>a, b </i>- - - <i>n</i>, a transceiver (not shown) as connected with the antenna <b>335</b> and the transceiver <b>314</b>, respectively. It is appreciated that the cost of using such capabilities <b>349</b> as compared to the data packet costs of transmission over the leased line <b>337</b>, is relatively low. As will be explained later, such cost factors influence significantly where the computer application and application specific data are stored; in particular, such cost considerations will dictate that most of and the most popular computer applications and application specific data as used by the calling terminal <b>312</b> are stored as will be described below with respect to PIG. <b>11</b> in that memory incorporated in the MAS <b>331</b> as opposed to being stored in the mass memory associated with the application server <b>330</b>.

[0075] Appreciating that the diagrammatic illustration of FIG. 10 is not drawn to scale, the wireless communication capabilities <b>347</b>, <b>349</b> and <b>351</b> are designed to transmit the collected data, the program applications and the application specific data over varying distances. For example, the wireless communication capabilities <b>347</b> and <b>351</b> would be designed in terms of power and data rate to transmit over relatively short distances, appreciating that the vehicle <b>329</b> would be capable of approaching within 500-1,000 feet of either of the delivery site <b>308</b> and the plurality of data collection terminals <b>312</b> disposed therein, and the transceiver <b>314</b> disposed at the main information center <b>306</b>. The wireless communication capability <b>349</b> differs from the capabilities <b>347</b> and <b>351</b> in that it is designed in terms of its power rating and data transmission speed to transmit the information flow over substantially greater distances; such a characteristic permits the MAS <b>331</b> to be transported to different delivery sites <b>308</b> at significant distances, e.g., 5-30 miles, from the antenna <b>335</b> and its radio module <b>347</b>. As illustrated in FIG. 10, the transmission distance between the center <b>306</b> and the MAS <b>331</b> may be significantly increased by using utilizing transmission via a satellite <b>345</b> from the MAS <b>331</b> to the transceiver associated with the antenna <b>335</b>. System of satellites disposed in geosynchronous orbits are capable of bidirectionally transmitting data between a MAS <b>331</b> disposed anywhere in the USA or anywhere in the world, and the main information center <b>306</b>. As will be described below with respect to FIG. 11, the MAS <b>331</b> employs at least two different transceivers or radio modules of different power and data rate specification to permit the transmission of the information flow over these different ranges.

[0076] Referring now to the functional block diagram of FIG. 11, there is shown the hardware architecture of the MAS <b>331</b>, including a data bus <b>334</b> for connecting the various elements thereof, a mirocprocessor <b>332</b> illustratively taking the form of that processor manufactured by Intel under its model number 80486, a dynamic random access memory (DRAM) <b>346</b>, a flash ROM <b>350</b> and the mass storage device <b>337</b> which may illustratively take the form of Disc/CD-ROM for storing the new application programs, application overlays and application specific data. The DRAM <b>346</b> is adapted to store the programs controlling the operations of the MAS <b>331</b>, for example the program as shown in FIG. 12, and any data used by such programs. The flash ROM <b>350</b> is adapted to store the BIOS programs required for the operation of the processor <b>332</b>. As indicated above, the MAS <b>331</b> includes at least two different types of transceivers or radio modules adapted to transmit the bidirectional data flow over distinct ranges of distance. The first transceiver, the wide area radio module <b>314</b>, and the radio module <b>347</b> are a part of the wireless communication capacity <b>349</b> for transmitting the bidirectional information flow between the MAS <b>331</b> and the wide area network <b>333</b>. A serial communication interface (UART) <b>338</b> interconnects the wide area radio module to the data bus <b>334</b>. The second transceiver, i.e., the radio module <b>356</b>, is a part of the wireless communication capacity <b>347</b> for transmitting the bidirectional information flow between the MAS <b>331</b> and each of the plurality of data collection terminals <b>312</b>. A PCMCIA controller <b>355</b> interconnects the radio module <b>356</b> to the data bus <b>334</b>. FIG. 11 further illustrates that at least two other data collection terminals <b>312</b><i>e </i>and <b>312</b><i>g </i>are connected directly to the data bus <b>334</b> by a UART <b>338</b>′ and the ethernet <b>353</b>. The high speed data transmission characteristics of the ethernet <b>353</b> as compared to those of serial communication interface <b>338</b>′ make it a preferable data link between the MAS <b>331</b> and a dock (not shown) for receiving a plurality of the data collection terminals <b>312</b>. The dock would be permanently mounted on the vehicle <b>329</b> thereby permitting the terminals to be securely transported by the vehicle <b>329</b>, and further to permit downloading of the collected data from the terminals <b>312</b> loaded in the dock for transmission to the wide area network <b>335</b>.

[0077] The flow diagram of FIG. 12 illustrates the operation of the MAS <b>331</b> as carried out by the processor <b>332</b> executing the corresponding control program. In a start step <b>401</b>, the MAS <b>331</b> waits until a call is received from one of the plurality of data collection terminals <b>312</b><i>a, b </i>- - - <i>n</i>. As described above, each call is formatted in the SQL language and further identifies which of the terminals <b>312</b> from which it was transmitted. The SQL call further identifies the information needed to continue the further operation of the identified terminal <b>312</b>, e.g., a new application program, an overlay and/or application specific data. In this regard, the structure and operation of the terminals <b>312</b> in the embodiment of FIGS. <b>10</b>-<b>14</b> corresponds respectively to the hardware architecture of FIG. 3, the memory architecture of FIG. 4 (flash ROM <b>150</b>), and the program manager program <b>156</b> illustrated in FIG. 5 for formulating the SQL call for the next overlay or a new application program and the transaction manager program <b>158</b> illustrated in FIG. 6 for formulating the SQL call for application specific data.

[0078] When a call is received from an identified data collection terminal <b>312</b>, step <b>402</b> saves in the DRAM <b>346</b> the ID of the calling data collection terminal <b>312</b>, as well an indication of which communication path was used to transmit the received SQL call to the MAS <b>331</b>. As shown in FIG. 11, the SQL call may be transmitted to the MAS <b>331</b> variously by the radio module <b>356</b>, or directly from the terminal <b>312</b><i>e </i>via the serial communication interface <b>338</b>′ or from the terminal <b>312</b><i>g </i>via the ethernet <b>353</b>. The stored communication path indication identifies from where the calling terminal <b>312</b> is calling and facilitates the transmission of the requested information back to the calling terminal <b>312</b>.

[0079] Next in step <b>404</b>, it is determined whether the called new program, application overlay or application specific data is locally stored in the MAS <b>331</b>, i.e., whether the requested information is stored in the mass storage <b>337</b>. If locally stored, step <b>416</b> transmits the requested information back to the calling terminal <b>312</b>. As will be described below with respect to FIG. 13, step <b>416</b> determines where the calling terminal <b>312</b> is presently located and selectively actuates one of the radio module <b>356</b>, ethernet <b>353</b> or the serial communication interface <b>338</b> to transmit the requested information back to the portable calling terminal <b>312</b> at its present location. In the process implemented by steps <b>401</b>, <b>402</b>, <b>404</b> and <b>416</b>, the MAS <b>331</b> functions as a server to the data collection terminals <b>312</b>, in a manner similar to the server relationship of the data base server <b>130</b> to the plurality of date collection terminals <b>112</b><i>a, b </i>- - - <i>n. </i>

[0080] If the requested information is not locally stored in the MAS <b>331</b>, step <b>406</b> formats a request or SQL call, before step <b>408</b> transmits the formulated SQL call from the MAS <b>331</b> via the wireless communication capability <b>349</b> to the wide area network <b>335</b> and, in particular, to the remote or application server <b>330</b> which is connected to the wide area network <b>335</b> and its ethernet <b>341</b> as shown in FIG. 10. In particular, step <b>408</b> selectively actuates one of the long range radio module <b>314</b> or the short range radio module <b>356</b>, before transmitting the SQL request to the application server <b>330</b> via the actuated radio module. The contemplated radio module selection could be carried out in different ways. The vehicle operator as he or she is approaching the main information center <b>306</b>, may enter that indication via a suitable keyed data input device (not shown) Alternatively, the transceiver <b>314</b> disposed at the main information center <b>306</b> could continuously transmit a message coded to indicate that it is transmitted from the transceiver <b>314</b>. When the short range radio module <b>356</b> begins to receive positively the message of the transceiver <b>314</b>, the MAS <b>331</b> sets a flag indicating that further communications may be now made via the short range radio <b>356</b> to the transceiver <b>314</b>. It is contemplated that in one illustrative embodiment that steps <b>406</b> and <b>408</b> would perform functions similar to those carried out by the program manager program <b>156</b>, the transaction manager program <b>158</b> and the radio protocol stack <b>160</b> as variously shown in FIGS. 4, 5 and <b>6</b>. The process implemented by the steps <b>406</b> and <b>408</b> functions as a client to the application server <b>318</b> in a fashion similar to the client relationship between the plurality of data collection terminal <b>112</b><i>a, b </i>- - - <i>n </i>and the data base server <b>130</b> as shown in FIG. 2.

[0081] Step <b>410</b> initiates upon the transmission of the SQL call to the application server <b>318</b> the timing of a period in which to receive back from the server <b>318</b> the requested new application, application overlay and/or application specific data. The application server <b>330</b> in one illustrative embodiment thereof operates in a manner similar to the database server <b>130</b>, whose hardware structure, the memory architecture and programming are illustrated respectively in FIGS. 7, 8 and <b>9</b>. If the requested information is timely received before the period times out, step <b>414</b> selectively actuates (in a manner similar to that of step <b>416</b> and as will be explained below with respect to FIG.13) one of the long range module <b>314</b> and short range module <b>356</b> to transmit the requested information to the calling data collection terminal <b>312</b>. Upon receipt, the calling terminal <b>312</b> will continue to operate, using the received information. If the period times out without receiving the requested information, step <b>412</b> selectively actuates one of the modules <b>314</b> or <b>356</b> to transmit an error message back to the calling data collection terminal <b>312</b> to inform it that the requested information is at least not currently available. The response of the calling terminal <b>312</b> depends on the nature of application currently being run by the calling terminal <b>312</b>. For example if a particular application can not continue to operate without the requested information, the calling terminal <b>312</b> will place calls for that information until it is received. On the other hand if the application can continue to operate without that information, the calling terminal <b>312</b> will place a limited number of calls and, if the requested information is not received in response to those calls, then the calling terminal <b>312</b> will perform another function or use default information.

[0082] In FIG. 13, a subroutine is provided to further explain the operation of step <b>414</b> or <b>416</b>. The problem solved by the illustrated subroutine is to identify where the calling data collection terminal <b>312</b> is presently located and, correspondingly, which link or port serves to presently connect that calling terminal <b>312</b> to the MAS <b>331</b>, i.e., the ethernet <b>353</b>, the serial communications interface <b>338</b>′ or the radio module <b>356</b>. After initiation in a start step <b>420</b>, the MAS <b>331</b> in step <b>422</b> repetitively, e.g., every 2 seconds sends out on all 3 ports a “foreign agent advertisement”, i.e., a message that the MAS <b>331</b> is presently available as a server to receive its call and to respond by returning the requested information. In step <b>423</b>, the MAS <b>331</b> initiates the timing of a period in which a call over any of the three ports of the MAS <b>331</b> should be received and listens for a message from a terminal <b>312</b> over all of the ports or channels. The processor within the data collecting terminal <b>312</b> is programmed to transmit a registration message, which indicates that the transmitting terminal <b>312</b> is responding to a received available message as was generated earlier by the MAS <b>331</b> in step <b>422</b>; the terminal's processor is also programmed to generate an advertisement solicitation or request to generate the “foreign agent advertisement” or available message. If that period set in step <b>423</b> times out without receiving any message, a return is made to step <b>422</b> prompting a further “advertisements” to be transmitted. Next step <b>424</b> examines the received message and, if the received signal is a registration message, then step <b>426</b> will update the indication stored within the DRAM <b>346</b> as to which port has been enabled to transmit information from the MAS <b>331</b> to the calling terminal <b>312</b>. On the other hand if the received message is an advertisement request or solicitation, the subroutine will return to step <b>422</b> to again transmit a “foreign agent advertisement.” Thus when the MAS <b>331</b> has received data from the application server <b>318</b> as determined in step <b>410</b>, the MAS <b>331</b> knows the current port by which to transmit the called information to the calling terminal <b>312</b>, even if the link may have changed between the time when the terminal originally transmitted its call for information to the MAS <b>331</b> and the time that collected information is transmitted back to the calling terminal <b>312</b>. The changing of the link may oft occur when the size of the requested data and, consequently, the transmission times from the MAS <b>331</b> to the calling terminal <b>312</b> are large. Noting that typical transmission times for a single packet of data, i.e., 500 bytes, is in the order of 5 seconds, the transmission time of an overlay of 35 K bytes would require five minutes and a new application of 0.5 Megabytes would be approximately 1½ hours.

[0083] It will be apparent that many modifications and variations may be effected without departing from the scope of the teachings and concepts of the present disclosure.