Method and apparatus for automatic gas pump charging cost of gasoline to auto computer using pan technology

0001The present invention relates to a vehicle onboard computer system that controls various vehicle onboard systems and subsystems. More specifically, the present invention relates to a system and method for implementing user specific commercial transactions between the vehicle onboard computer system and a vendor's computer system. Still more particularly, the present invention relates to a system and method for identifying and authorizing users and implementing user specific parameters relating to electronic commerce transactions that require very little user interaction at the time the transaction occurs.

0002It has been well known in prior art to conduct cash transactions with a vendor involving some aspect of operating a vehicle. These transactions may include such things as fueling the vehicle, maintenance and upkeep, and transactions concerning governmental fees and licenses. In the past, these transactions have been largely manual transactions requiring the user to perform a number of tasks associated with the transaction. The transaction is usually transacted on a cash basis; however, personal credit cards and commercial credit cards and debit accounts have recently been a popular means of conducting transactions. Each one of these bases requires the user to make a certain number of option selections at the time of the transaction even though the user may have predetermined what those selections will be.

0003Another problem associated with the transactions described above is the problem of user accountability especially pertaining to a fleet operation involving large numbers of vehicles. Although cash is universally accepted, cash transactions are extremely undesirable because of accounting and accountability problems. Although commercial credit cards have somewhat alleviated accounting problems, accountability still remains a problem because, generally, the commercial account is not indexed to an individual vehicle or user.

0004What is needed is a means to pre-select user options before transactions occur thereby saving the user valuable time at the time of the transaction and also giving the administrators of the system greater control over making the selections. Additionally, a means of indexing each transaction to a specific vehicle and a specific vehicle operator would allow administrators greater flexibility in tracking commercial transactions among fleet vehicles and greater insight in the planning of future transactions.

0005A vehicle processes a commodity transaction between a vendor computer system and an onboard computer system where the transaction data is stored available to the vendor computer with little interaction required by the vehicle operator. The onboard computer system communicates to the vendor computer system using personal area network technology adapted to a vehicle. In that way, the user initiates the sequence of events by performing a related function. In the preferred embodiment, the operator connects a fuel nozzle to the vehicle. Then, the transaction may be performed between the vehicle computer and the vendor computer without any assistance from the operator. The transaction may include selecting a commodity or service, debiting a cash account for the selected commodity and enacting a fault sequence in case of a system fault. The transaction accounts can be specific to the vehicle identification or the operator identification.

0006Accordingly the present invention provides a method for performing a commodity transaction from a vehicle wherein the method is performed on a data processing system, the method comprising: communicating to a second data processing system with an onboard data processing system; identifying the second data processing system; accessing commodity transaction data in a memory associated with the identity of the second data processing system; transferring at least a portion of the commodity transaction data to the second data processing system; performing a commodity transaction in response to transferring at least a portion of the commodity transaction data; and verifying an occurrence of the commodity transaction. More suitably the step communicating to the second data processing system further comprises: handshaking between systems. The memory may or may not be included in the onboard data processing system as appropriate, or alternatively the memory is included in a hand-held memory structure. Preferably the onboard data system is included within a personal area network onboard a vehicle. The commodity transaction may suitably involve one of fuel, toll, maintenance, governmental fee or process, and commercial service.

0007In a further embodiment of the invention there is provided a method for performing a commodity transaction with a vehicle wherein the method is performed on a vendor data processing system, the method comprising: communicating to an onboard data processing system; identifying the onboard data processing system; receiving commodity transaction data from the onboard data processing system; in response to receiving commodity transaction data, accessing vendor commodity transaction data in a memory associated with the identity of the onboard data processing system; performing a commodity transaction in response to identifying the onboard data processing system, receiving commodity transaction data, and accessing vendor commodity transaction; and verifying an occurrence of the commodity transaction. More suitably the step communicating to the onboard data processing system further comprises: handshaking between systems. The memory may be included in the vendor data processing system. Preferably the method further comprises: transmitting at least a portion of the vendor commodity data to the onboard data processing system, and optionally further comprises: transmitting data to the onboard data processing system while performing the commodity transaction. More preferably the step of communication with an onboard data further comprises: linking to a personal area network onboard the vehicle. The transaction type may suitably be one of fuel, toll, maintenance, governmental process, and commercial service.

0008In yet a further embodiment of the present invention there is provided a data processing system for performing a commodity transaction from a vehicle, the system comprising: communicating means for communicating to a second data processing system with an onboard data processing system; identifying means for identifying the second data processing system; accessing means for accessing commodity transaction data in a memory associated with the identity of the second data processing system; transferring means for transferring at least a portion of the commodity transaction data to the second data processing system; performing means for performing a commodity transaction in response to transferring at least a portion of the commodity transaction data; and verifying means for verifying an occurrence of the commodity transaction. More suitably the communicating means for communicating to the second data processing system further comprises: handshaking means for handshaking between systems. The memory may or may not be included in the onboard data processing system as appropriate, or alternatively the memory is included in a hand-held memory structure. Preferably the onboard data system is included within a personal area network onboard a vehicle. The commodity transaction may suitably involve one of fuel, toll, maintenance, governmental fee or process, and commercial service.

0009In yet a further embodiment of the present invention there is provided a vendor data processing system for performing a commodity transaction with a vehicle, the system comprising: communicating means for communicating to an onboard data processing system; identifying means for identifying the onboard data processing system; receiving means for receiving commodity transaction data from the onboard data processing system; accessing means for accessing vendor commodity transaction data in a memory associated with the identity of the onboard data processing system; performing means for performing a commodity transaction in response to identifying the onboard data processing system, receiving commodity transaction data, and accessing vendor commodity transaction; and verifying means for verifying an occurrence of the commodity transaction. More suitably the communicating means for communicating to the onboard data processing system further comprises: handshaking means for handshaking between systems. The memory may be included in the vendor data processing system. Preferably the system further comprises: transmitting means for transmitting at least a portion of the vendor commodity data to the onboard data processing system, and optionally further comprises: transmitting means for transmitting data to the onboard data processing system while performing the commodity transaction. More preferably the communication means for communication with an onboard data further comprises: linking means for linking to a personal area network onboard the vehicle. The transaction type may suitably be one of fuel, toll, maintenance, governmental process, and commercial

0010The present invention further provides a computer program product for performing a commodity transaction from a vehicle wherein the product implemented in a series of instructions on a computer readable medium and performed on data processing system, the instructions comprising: instructions for communicating to a second data processing system with an onboard data processing system; instructions for identifying the second data processing system; instructions for accessing commodity transaction data in a memory associated with the identity of the second data processing system; instructions for transferring at least a portion of the commodity transaction data to the second data processing system; instructions for performing a commodity transaction in response to transferring at least a portion of the commodity transaction data; and instructions for verifying an occurrence of the commodity transaction. More suitably the instructions for communicating to the second data processing system further comprise instructions for handshaking between systems Preferably the onboard data system is included within a personal area network onboard a vehicle.

0011The present invention yet further provides a computer program product for performing a commodity transaction with a vehicle wherein the computer program product is implemented as a series of instruction on a computer readable medium and performed on a vendor data processing system, the instructions comprising: instructions for communicating to an onboard data processing system; instructions for identifying the onboard data processing system; instructions for receiving commodity transaction data from the onboard data processing system; instructions for in response to receiving commodity transaction data, accessing vendor commodity transaction data in a memory associated with the identity of the onboard data processing system; instructions for performing a commodity transaction in response to identifying the onboard data processing system, receiving commodity transaction data, and accessing vendor commodity transaction; and instructions for verifying an occurrence of the commodity transaction.

0012The present invention yet further provides a method in a host data processing system for processing a fuel transfer at a station from the station to a vehicle containing a mobile computing system, the method comprising the data processing system implemented steps of: responsive to detecting a connection between the station and the vehicle via a fuel transfer conduit, establishing communications between a host data processing system and a mobile computing system through the fuel transfer conduit connecting the vehicle with the station; and responsive to establishing a communications link though the fuel transfer conduit, performing a transaction to pay for the fuel transfer to the vehicle. More suitably the method recited in claim 33 wherein the fuel is gasoline. Preferably the step of performing transaction steps of details of querying for data and approval. The method also preferably further comprises allowing fuel transfer responsive to performing the transaction. In a preferred version of the method the fuel transfer automatically starts.

0013The invention will now be described by way of example and with reference to the accompanying drawings in which: <ul id="ul0001" list-style="none" compact="compact"><li><b>Figure 1</b> depicts a block diagram illustrating a data processing system of the present invention.</li><li><b>Figure 2</b> depicts the onboard systems of the present invention as defined in a preferred embodiment of the present invention.</li><li><b>Figure 3</b> depicts the suspension and ride system of the vehicle.</li><li><b>Figure 4</b> illustrates the comfort system of the vehicle.</li><li><b>Figure 5</b> illustrates another system under the control of the onboard computer, the communications interface system.</li><li><b>Figure 6</b> illustrates another system under the control of the onboard computer, the navigation and tracking system.</li><li><b>Figure 7</b> illustrates another system under the control of the onboard computer, the audio system.</li><li><b>Figure 8</b> illustrates the safety system as implemented in the present invention.</li><li><b>Figure 9</b> illustrates the engine performance system as related to the present invention.</li><li><b>Figure 10</b> illustrates the user interface system as implemented in the present invention.</li><li><b>Figure 11</b> illustrates one embodiment of the present invention utilizing a personal area network.</li><li><b>Figure 12</b> illustrates another embodiment of the present invention involving a fault occurrence during the fuel transfer process.</li><li><b>Figure 13</b> illustrates another embodiment of the present invention involving a fault occurrence during the fuel transfer process, taken from the perspective of the vehicle's onboard computer.</li><li><b>Figure 14</b> illustrates the data structure stored in a memory of the present invention.</li><li><b>Figure 15</b> illustrates the user ID data structure.</li><li><b>Figure 16</b> illustrates the verification data structure.</li><li><b>Figure 17</b> illustrates the security level data structure.</li><li><b>Figure 18</b> illustrates an extremely abbreviated data structure of possible preferences.</li><li><b>Figure 19</b> illustrates the preference limits data structure.</li><li><b>Figure 20</b> illustrates the data structure of user logged data.</li><li><b>Figure 21</b> illustrates an example of how the onboard computer authorizes user preferences by user security level.</li><li><b>Figure 22</b> illustrates a preferred embodiment of the present invention involving electronic commerce between a vehicle and a vendor.</li><li><b>Figure 23</b> illustrates a representation of the modulated signal passing between the vehicle and the fuel pump using personal area network</li></ul>

0014With reference now to <b>Figure 1,</b> a block diagram illustrates a data processing system in which the present invention may be implemented. Data Processing system <b>100</b> is an example of a client computer. Data Processing system <b>100</b> employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Micro Channel and ISA may be used. Processor <b>102</b> and Main Memory <b>104</b> are connected to PCI local Bus <b>106</b> through Host/PCI Cache/Bridge <b>108.</b> Host/PCI Cache/Bridge <b>108</b> also may include an integrated memory controller and cache memory for Processor <b>102.</b> Additional connections to PCI local Bus <b>106</b> may be made through direct component interconnection or through add-in boards. In the depicted example, Local Area Network (LAN) Adapter <b>110,</b> SCSI Host Bus Adapter <b>112,</b> and Expansion Bus Interface <b>114</b> are connected to PCI local Bus <b>106</b> by direct component connection. In contrast, Audio Adapter <b>116,</b> Graphics Adapter <b>118,</b> and Audio/Video Adapter (A/V) <b>119</b> are connected to PCI local Bus <b>106</b> by add-in boards inserted into expansion slots. Expansion Bus Interface <b>114</b> provides a connection for a Keyboard and Mouse Adapter <b>120,</b> Modem <b>122,</b> and additional Memory <b>124.</b> Additional Memory <b>124</b> may consist of any type of memory including flash memory. SCSI Host Bus Adapter <b>112</b> provides a connection for hard Disk drive <b>126,</b> Tape drive <b>128,</b> and CD-ROM drive <b>130.</b> Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

0015An operating system runs on Processor <b>102</b> and is used to coordinate and provide control of various components within Data Processing system <b>100</b> in <b>Figure 1.</b> The operating system may be a commercially available operating system such as OS/2, which is available from International Business Machines Corporation. "OS/2" is a trademark of International Business Machines Corporation. The operating system may also be a real time operating system (RTOS), such as QNX Neutrino™ from QNX Software Systems Ltd., 175 Terranence Matthews Crescent, Kanata, Ontario, Canada K2MLW8. An object oriented programming system such as Java may run in conjunction with the operating system and provide calls to the operating system from Java programs or applications executing on Data Processing system <b>100</b> via a Java Virtual Machine. "Java" is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard Disk drive <b>126,</b> and may be loaded into Main Memory <b>104</b> for execution by Processor <b>102.</b>

0016Those of ordinary skill in the art will appreciate that the hardware in <b>Figure 1</b> may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash ROM (or equivalent nonvolatile memory) or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in <b>Figure 1.</b> Also, the processes of the present invention may be applied to a multiprocessor data processing system.

0017For example, Data Processing system <b>100,</b> if optionally configured as a network computer, may not include SCSI Host Bus Adapter <b>112,</b> hard Disk drive <b>126,</b> Tape drive <b>128,</b> and CD-ROM <b>130,</b> as noted by dotted line <b>132</b> in <b>Figure 1</b> denoting optional inclusion. In that case, the computer, to be properly called a client computer, must include some type of network communication interface, such as LAN Adapter <b>110,</b> Modem <b>122,</b> or the like. For mobile vehicle applications, the preferred network communication interface might be a wireless network circuit for communicating digital packets of information to and from the central fleet server. As another example, Data Processing system <b>100</b> may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not Data Processing system <b>100</b> comprises some type of network communication interface. As a further example, Data Processing system <b>100</b> may be a Personal Digital Assistant (PDA) device which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.

0018The depicted example in <b>Figure 1</b> and above-described examples are not meant to imply architectural limitations with respect to the present invention. Although <b>Figure 1</b> provides examples of configurations of computer systems on which the present invention may execute, the following background information may provide a context for understanding the overall computing environment in which the present invention may be used.

0019<b>Figure 2</b> describes the systems of the present invention as defined in a preferred embodiment of the present invention. In the present invention, the vehicle may contain one or more Onboard Computer(s) <b>20.</b> Users control different systems within the vehicle through Onboard computer <b>20.</b> A specific user can only gain as much control of a system or subsystem as authorized by Onboard Computer <b>20.</b> A user may fall into one or more security level(s), for instance, low level security, master level security, administrator, service attendant, parking attendant or semi-user. The varying levels of security allow users having different access priorities to access only the systems authorized by the level of security that corresponds to the user's security level. Other, more specialized security levels might also be available for special purpose operation of the vehicle, such as thief and drunk driver levels which severely limit access and performance of the vehicle. Implementing the different security levels is primarily, a software function which authorizes security levels in a series of IF tests in a logic flow. This is an extremely effective means of implementing security levels because the preferred embodiment consists of a closed system which is protected from arbitrary software being installed from unknown sources. Alternatively, each security level could be a separate level of hardware. Onboard Computer <b>20</b> also contains an onboard computer Memory <b>22</b> which would store the software logic described above. Onboard Computer system <b>20</b> is intended to be exemplary in nature, and it is not intended in any way to restrict the implementation of this invention.

0020In one embodiment of this invention, Onboard Computer <b>20</b> controls several onboard systems through its different security levels. For simplicity, the invention is described largely as consisting of two security levels, low and high, corresponding to two different levels of user security. One feature of this invention is that accessing and changing preferences relating to any one of these systems can be done only by the user who has a corresponding security level for the security level which controls the specific system.

0021Taking first the lower level security, a low level security user may access and change preference settings for one or more of the following onboard systems: Suspension and Ride system <b>300;</b> Comfort system <b>400;</b> Communications/Interface system <b>500;</b> Navigation and Tracking system <b>600;</b> Audio system <b>700;</b> and Systems Monitoring system <b>290</b> for the above-mentioned onboard systems.

0022A user possessing a higher security level, such as a master security level as authorized by Onboard Computer <b>20,</b> in addition to resetting and adjusting the preference settings for the systems requiring a lower level security level for access, may also adjust the preference settings of the systems requiring a higher level of security for authorization. Higher level security authorization is required for: Safety system <b>800;</b> Engine Performance system <b>900;</b> and Theft Deterrence and Recovery system <b>210.</b>

0023<b>Figure 3</b> depicts the suspension and ride system of the vehicle. The dashed line around the subsystems depicts which functions are controlled by the system. Suspension and Ride system <b>300</b> and associated subsystems are controlled by preferences which set functions associated with the particular subsystems. Suspension and Ride system <b>300</b> includes Suspension Performance Tuning <b>350.</b> By the user specifying suspension performance tuning parameters, the vehicle's ride attributes, such as pitch, yaw, roll and stiffness, can be changed.

0024As the user is identified through the use of a user ID via User Interface <b>28,</b> Onboard Computer <b>20</b> extracts certain performance settings from onboard Memory <b>22</b> which are indexed to the user's name or ID number. These performance settings include user specific parameters which are used to modify each of the functions described above. One example is that a user may prefer a stiffer ride and may prefer a certain feel when he operates the vehicle. Therefore, the user may select certain parameters having to do with suspension performance tuning to affect the vehicle's ride. These parameters adjust each one of the functions mentioned above associated with the subsystem in order to give that user the ride which he desires. Systems Monitoring <b>290</b> continually monitors pitch, yaw, roll and stiffness attributes of the vehicle's ride and transmits the information to Onboard Computer system <b>20.</b> In another embodiment of this invention, Systems Monitoring system <b>290</b> continually updates the suspension performance tuning in order to maintain that overall riding effect desired by the user. Therefore, as suspension and ride parts such as tires, shocks, struts, springs and bearings wear, Systems Monitoring system <b>290</b> monitors each one of the functions for the desired effect. If the results monitored by Systems Monitoring system <b>210</b> are not within the user's set preference, Onboard Computer system <b>20</b> may attempt to adjust each one of the functions automatically in an attempt to adjust the ride to the user's desired preferences--in other words, reset the user specified ride parameters automatically.

0025In another embodiment, the user merely sets parameters associated with suspension performance tuning, and Systems Monitoring system <b>290</b> merely monitors the functions and transfers the functional output to Onboard Computer <b>20.</b> In this embodiment, it is left up to the user to manually set each one of the ride and suspension parameters, and as the parts of the vehicle change with respect to wear or damage, the user is expected to manually update each one of the parameters. Although this is possible, it is unlikely that the ordinary user would possess the skill necessary to make those adjustments autonomously, thus requiring Onboard Computer <b>20</b> to calculate those functional parameters for the user. Therefore, while expert drivers such as race car drivers, mechanics and the like may possess the knowledge needed to adjust these parameters, the ordinary weekend vehicle operator might rely on a routine stored within Onboard Computer <b>20</b> to make those adjustments.

0026<b>Figure 4</b> illustrates another system under the control of every user, the Comfort system <b>400.</b> Comfort system <b>400</b> includes: Air Temperature and Flow subsystem <b>410;</b> Seats and Steering Wheel subsystem <b>420;</b> and Mirrors and Windows subsystem <b>430.</b> Once the user has been identified by Onboard Computer <b>20</b> via User Interface <b>28,</b> Onboard Computer <b>20</b> retrieves user specific parameters from system Memory <b>22.</b> Those user specific parameters are used to adjust the various subsystems of Comfort system <b>400.</b> If a user enjoys the air temperature somewhat lower and the flow higher than other users, as the user is identified by Onboard Computer <b>20,</b> Air Temperature and Flow subsystem <b>410</b> are automatically adjusted to the user specific parameters stored in Memory <b>22.</b> Therefore, the user would not have to readjust the air temperature and flow parameters every time the user enters the car, but rather merely satisfy identification to Onboard Computer <b>20,</b> and Onboard Computer <b>20</b> would retrieve the user's specific user parameters from Memory <b>22</b> and adjust Comfort system <b>400</b> accordingly.

0027Other conveniences include adjusting seats and steering wheel positions, and mirrors and windows for particular users. As the user's height and proportions tend to change from user to user, it would be advantageous for each user to preset such settings as the seat position setting and the steering wheel position, along with mirror positions and window positions for the individual user. As the user drives the vehicle, and climate conditions or tastes change, the user may have occasion to adjust certain of the above-mentioned subsystems. As the user adjusts the subsystems, Systems Monitoring system <b>290</b> notes these adjustments and transmits the adjustments to Onboard Computer <b>20.</b> Onboard Computer <b>20</b> then may store the adjustments to system Memory <b>22.</b> On exiting the vehicle, the user need not reset the various user parameters that were initially stored in Memory <b>22,</b> as these have been updated while the user operated the vehicle.

0028In one embodiment, Onboard Computer <b>20</b> merely retains the updated user specific parameters within Memory <b>22</b> as the user exits the vehicle, retrieving them again as the user specific parameters when the user is again identified to Onboard Computer <b>20.</b> In another embodiment, updates fed to Onboard Computer <b>20</b> via Systems Monitoring system <b>290</b> are merely transient. In that embodiment, the updates are lost once the user exits the vehicle unless the user takes some affirmative action to save them. In that embodiment, once the user exits the vehicle the updated parameters are lost in lieu of the initial user specific parameters.

0029<b>Figure 5</b> illustrates another system under the control of the onboard computer, the communications and interface system. Another system that may be under the control of lower level security users is Communications/Interface <b>500.</b> In a fully integrated onboard computer system, the ability to access large amounts of data for the convenience and safety of the operator becomes more and more important. Also, as the complexity of vehicles increases, the maintenance of those vehicles is expedited by allowing access to Onboard Computer <b>20</b> and the various systems through a specialized maintenance interface.

0030One embodiment of the present invention, Communications/Interface system <b>500,</b> consists of various subsystems as fulfill the various above-mentioned needs. These include: Satellite Com Link <b>510;</b> Cellular/PCS communications <b>520;</b> Personal Area Network Port <b>530;</b> Fleet Docking Port <b>540;</b> Maintenance Port <b>550;</b> Home Docking Port <b>560;</b> and Regulatory Docking Port <b>570.</b> Depending upon the intended use of the vehicle, some or all of these communications subsystems may be eliminated or substituted with other types of communications subsystems. Other subsystems, such as Satellite Com Link <b>510</b> and Cellular/PCS communications <b>520</b> may contain extensive local memories for holding user specific data like earth link addresses and telephone numbers. Alternatively, earth link addresses and telephone numbers may be stored on a personal memory such as a SmartCard or magnetic swipe card, or in system Memory <b>22,</b> and indexed by user.

0031In one example of the communications subsystems, for instance a fleet vehicle operation, vehicles could be continually tracked via Satellite Com Link <b>510.</b> The fleet dispatcher, therefore, could watch the progress of vehicles and goods from the origin to the destination. If the dispatcher detects a delay somewhere along the route, he could immediately contact the vehicle through Cellular/PCS <b>520</b> link or Satellite Com Link <b>510</b> to ascertain the problem and try to help the vehicle operator formulate an alternate route.

0032Personal Area Network Port <b>530</b> would be useful for such things as ascertaining if a vehicle is authorized to, for instance, go through a toll booth. There, Onboard Computer <b>20</b> would automatically link with a computer at the toll booth via Personal Area Network Port <b>530</b> and communicate to the toll booth computer an electronic cash account number by which the toll computer could access and debit the cash amount of the toll, thereby eliminating the need for the driver of the vehicle to stop the vehicle and pay a toll. This would also eliminate the need for the driver to carry any cash while enroute; and in fact, the vehicle itself may not even need to have the cash account, as it could merely link to the home or fleet headquarters and debit a financial account for the cash.

0033Another interface particularly helpful in fleet operation is a Fleet Docking Port <b>540.</b> Although in the preferred embodiment, Fleet Docking Port <b>540</b> is a specific hardware port, fleet docking may also be realized by using the wireless network circuit described above in reference to <b>Figure 1.</b> Fleet Docking Port <b>540</b> would be useful for an operation that tracks several vehicles up to several thousand vehicles. As the vehicle would enter the home terminal, the vehicle could park for transfer of cargo or maintenance, or whatever, and then be linked via Fleet Docking Port <b>540</b> to the terminal computer which in turn would be linked to the main operational computer. Thus, as the truck receives maintenance, or on or off loads cargo, the information concerning the prior trip could be downloaded from Onboard Computer <b>20</b> Memory <b>22,</b> and information pertaining to the next scheduled trip, including maps, itinerary, electronic cash and the like, could be loaded onto Onboard Computer <b>20</b> Memory <b>22.</b> Vehicle operators could also be authorized and de-authorized for the vehicle.

0034As noted above, detailed maintenance records are also important, especially as the number of vehicles in a fleet operation increases. Therefore, a specific Maintenance Port <b>550</b> would be useful. Maintenance Port <b>550</b> would provide instant access to certain files or records and allow for testing of onboard systems simultaneously with other fleet interface operations. While Maintenance Port <b>550</b> indicates that, primarily, the access is limited to maintenance of the engine and onboard systems and subsystems, Maintenance Port <b>550</b> should also have access to Onboard Computer <b>20</b> main Memory <b>22</b> to ascertain such things as fuel and mileage logs, distances traveled, environments traveled in and the like. In this way, an expert mechanic could determine the overall maintenance condition of the unit by comparing it to its previous performance.

0035Home Docking Port <b>560</b> would also be useful in a fleet operation where the vehicle operator may be required to bring the vehicle home. In that case, the vehicle operator would merely dock the vehicle at the home port and, using the user's home computer, the fleet operations could interface with the computer, for instance while the operator was away or asleep or on another task. In this way, Onboard Computer <b>20</b> Memory <b>22</b> could be uploaded with pertinent information about an upcoming trip.

0036<b>Figure 6</b> illustrates another system under the control of the onboard computer, the navigation and tracking system. Another important onboard system is Navigation and Tracking system <b>600.</b> A typical Navigation and Tracking system <b>600</b> may include GPS <b>610</b> for ascertaining the exact vehicle position via geosynchronous positioned satellites. Maps and Databases <b>620</b> would probably reside in the system Memory <b>22.</b> Maps and Databases <b>620</b> might also be fairly transient, being uploaded and downloaded as the intended route of the vehicle changes. In another aspect of the invention, Maps and Databases <b>620</b> may be downloaded via Satellite Corn Link <b>510</b> or Cellular/PCS <b>520</b> connection to the vehicle's home terminal.

0037Navigation and Tracking system <b>600</b> may also include Locator Beacon <b>630.</b> While Locator Beacon <b>630</b> could take many forms and work in cooperation with one of the communication systems, either Satellite Com Link <b>510</b> or Cellular/PCS <b>520,</b> Locator Beacon <b>630</b> may be a separate subsystem providing a radio frequency beacon used to locate the vehicle in case of emergency or possibly to track vehicle movements within a local area for a fleet dispatcher.

0038Another important set of tracking databases might be Maintenance Log <b>640</b> and Driving Log <b>650,</b> which are somewhat related. For an expert mechanic to properly maintain a vehicle, it is useful to have within the vehicle's Maintenance Log <b>640</b> the prior routes and conditions in which that vehicle was driven. In that way, when the vehicle experiences what appears to be a sudden loss in performance over the last few trips, a master mechanic can examine the log to note if there is any difference in the driving pattern. Along that same vein, Driving Log <b>650</b> could also be useful to a master mechanic in examining the actual driving performance of the vehicle driver. Therefore, by carefully examining these two logs, a master mechanic might merely conclude that what appears to be poor vehicle and engine performance can merely be attributed to the change in drivers, driving patterns or routes.

0039Additionally, Driving Log <b>640</b> and Maintenance Log <b>650</b> can be used together to assemble data in User Logged Data <b>2000, Figure 20.</b> User logged data is indexed by user and might contain fields such as the operation of the vehicle, a specific trip and other data. The log could be displayed on User Interface <b>28</b> or at the user's home terminal by a user having an administrator security level. User Logged Data <b>2000</b> is an extremely useful resource for setting preference limits as shown on data structure <b>1900, Figure 19.</b> The performance of each user under a specific security level can be monitored by analyzing User Logged Data <b>2000,</b> and specific preferences can be set for that user. For instance, if a user appears to be prone to extremely fast accelerations, an administrator examining the Maximum Acceleration field of User Logged Data <b>2000,</b> may limit that user. The administrator can limit vehicle acceleration to a more moderate rate by changing 5 feet per second² to 3.5 feet per second² in the Maximum Forward Acceleration field of Performance Limits data structure <b>1900.</b>

0040Working in close association with Navigation and Tracking system <b>600</b> would be Communications/Interface system <b>500</b> and especially Cellular/PCS subsystem <b>520.</b> Additionally, Theft Deterrence and Recovery system <b>210</b> and Collision Avoidance subsystem <b>870</b> of Safety system <b>800</b> could also make extensive use of Navigation and Tracking system <b>600.</b>

0041In one example, if a vehicle is identified as being stolen or being used in an unauthorized manner, the vehicle can automatically ascertain its position via use of GPS subsystem <b>610</b> and Maps and Databases subsystem <b>620.</b> Onboard Computer <b>20</b> could then use Communications/Interface system <b>500</b> to transmit the information through either Cellular/PCS subsystem <b>520</b> or Satellite Com Link subsystem <b>510</b> to the fleet dispatcher or local authorities. Additionally, once it has been positively confirmed that the vehicle has been stolen, Locator Beacon <b>630</b> could be turned on to aid the police in determining the location of the vehicle.

0042Another important feature of this invention, Safety system <b>800,</b> including Collision Avoidance subsystem <b>870,</b> would make extensive use of Maps and Databases <b>620</b> and GPS <b>610</b> subsystems in the event of an accident. For instance, Collision Avoidance subsystem <b>870</b> might, through some combination of events, detect that an accident that is likely to cause injury or death is imminent. In that case, rather than waiting for the accident to actually occur, Onboard Computer <b>20,</b> using one of Communications/Interface <b>500</b> subsystems, either Cellular/PCS <b>520</b> or Satellite Com Link <b>510,</b> can place an emergency call to the fleet dispatcher, to the vehicle's home or possibly to the local authorities, such as a 911 emergency call. In that way, once the accident actually occurs and the vehicle becomes inoperable, including Onboard Computer <b>20,</b> a distress signal has already been issued by Onboard Computer <b>20.</b> If, on the other hand, the accident which was determined by Onboard Computer <b>20</b> to be imminent does not occur, or the severity of the accident is limited, the user may merely cancel the imminent distress call.

0043In a further aspect of the invention, once the distress call has been received by the local authorities or the vehicle dispatcher, the receiver of the call may attempt to communicate to the vehicle via Communications/Interface system <b>500</b> to ascertain the exact condition of the, vehicle and driver. If no response is mirrored from the vehicle, it could be rightly assumed by the fleet dispatcher that the accident has occurred and the local authorities could be alerted of the likelihood that a serious accident involving that specific vehicle has occurred. The approximate vehicle location which was issued during the distress call could be provided.

0044Of course, under ordinary use, vehicles tend to break down or have mechanical difficulties of one type or another; and somehow, the likelihood is that, when that occurs, the vehicle operator will not have a clear idea of the vehicle's location within a particular driving area. By using the integrated Navigation and Tracking system <b>600,</b> the vehicle operator can quickly determine the vehicle's location at the time of the incident and, using Communications/Interface system <b>500,</b> call either a dispatcher, mechanic or a service company for aide.

0045In other embodiments, performance limits may be adjusted to limit the maximum distance a vehicle is authorized to travel from its home base or in deviation from a predetermined route of travel. Working in combination with Safety system <b>800</b> and Engine Performance system <b>900,</b> Warnings, Gauges and Lights subsystem <b>830</b> uses visual or audio indicators to gently remind the vehicle operator that the limits of travel are being exceeded (see <b>Figure 8).</b> Finally, when the infraction becomes critical, the vehicle is gently caused to come to a stop by reducing the maximum vehicle speed parameter limit which reduces the vehicle's speed using vehicle Speed subsystem <b>920, Figure 9.</b>

0046However, prudent safety operation dictates that the vehicle should always be allowed to move very short distances, such as one hundred feet, just in case the vehicle operator becomes de-authorized at a point which is unsafe, such as a railroad crossing. This gives the de-authorized operator an extra measure of distance to travel.

0047Finally, a user may be restricted from operating the vehicle further than a certain number of miles from its home to reduce unauthorized trips and joy riding. A regular route vehicle may be limited to a prescribed route of travel and any variation might be strictly prohibited. However, in most instances the parameters are not so strict as to allow the vehicle to be maneuvered around detours.

0048<b>Figure 7</b> illustrates another system under the control of the onboard computer, the audio system. Another onboard system which would be particularly convenient for multiple vehicle users would be Audio system <b>700.</b> Audio system <b>700</b> connects to Onboard Computer <b>20,</b> which restricts access to users who do not possess the required security level. Users such as parking attendants and the like who may be required to operate the vehicle only for short distances, are not expected to use the vehicle's audio system. Audio system <b>700</b> would allow each operator to select preferred AM/FM radio stations, compact disks or tape selections for listening. In addition, it would allow the individual users to select unique preferences for volume levels, tone and other audio quality settings. Audio system <b>700</b> contains: Volume subsystem <b>710</b> for adjusting the volume of Audio system <b>700;</b> Balance subsystem <b>720</b> for adjusting the balance between left and right outputs of Audio system <b>700;</b> Fade subsystem <b>730</b> for adjusting front and rear outputs of Audio system <b>700;</b> and Tone subsystem <b>740</b> or comparable subsystem for adjusting the frequency response or spectral response of the outputted sound. Audio system <b>700</b> may also include Selector <b>750,</b> which selects the user specific devices such as CD, tape, AM/FM radio or other possible outputs. Audio system <b>700</b> may also contain CD/Tape Carousel <b>760,</b> which stores a variety of CDs or tapes on a ready-to-use basis, allowing the user to merely select from an available selection in CD/Tape Carousel <b>760</b> rather than having to reload CDs or tapes. Finally, Audio system <b>700</b> could include AM/FM Station Frequencies subsystem <b>770,</b> which includes the user's preferred station settings, along with possible station types and a menu of stations in the vehicle's area.

0049Audio system <b>700</b> works in a fashion similar to the other systems in that the user is identified to Onboard Computer <b>20</b> via User Interface <b>28.</b> Once the computer recognizes the user, the computer then accesses audio preferences which can be stored in computer Memory <b>22.</b> Those preferences are then transmitted to Audio system <b>700</b> because the user has been authorized by the software security logic performed on Onboard Computer <b>20.</b> Pre-stored user specific preference settings for volume, balance, fade and tone of the outputted audio adjust the various subsystems such as Volume subsystem <b>710,</b> Balance subsystem <b>720,</b> Fade subsystem <b>730</b> and Tone subsystem <b>740.</b> In addition, user-defined preferences stored in Memory <b>22</b> would determine which output device the user has chosen to listen to and transmit that information to Selector <b>750,</b> which then activates the appropriate device, either radio or CD or tape. Once that device is activated, it in turn accesses the tape and selection or CD and selection from the CD/Tape Carousel subsystem <b>760</b> or the AM/FM Station Frequencies subsystem <b>770</b> and plays the appropriate selection which the user has predefined and stored in Memory <b>22.</b> In addition, as the user operates the vehicle, Systems Monitoring system <b>290</b> continually monitors manual adjustments by the user to each one of these subsystems. Those adjustments can be used to update the user preferences in the onboard system Memory <b>22.</b> When the user exits the vehicle, these preferences may be used to replace the previous user specific preferences stored in Memory <b>22</b> or may merely be decimated in favor of the pre-stored user specific preferences in Memory <b>22.</b>

0050<b>Figure 8</b> illustrates Safety system <b>800</b> as implemented in the present invention. Safety system <b>800</b> is contained within the dashed lines of <b>Figure 8.</b> Safety system <b>800</b> of the present invention is authorized only for higher security, level users than the systems discussed thus far. Therefore, as the user accesses Onboard Computer <b>20</b> via User Interface <b>28,</b> the user's ID is ascertained by Onboard Computer <b>20.</b> The user ID is then compared to a list of IDs to ascertain the level of security that is authorized for the user associated with this particular ID. Again, as in the other systems described above, Onboard Computer <b>20</b> would then authorize the user's ID number and retrieve user specific parameters from system Memory <b>22.</b> The user is granted access to Safety system <b>800</b> only if he is authorized for a higher level of security than the normal user. Therefore, Onboard Computer <b>20</b> will only grant control of Safety system <b>800</b> to users possessing a master or higher level of security authorization. The user specific parameters would be accessed and applied to the various subsystems within Safety system <b>800.</b> Safety system <b>800</b> contains various subsystems which relate to the safety of the vehicle. Those subsystems include: Airbags <b>810;</b> Antilock Braking <b>820;</b> Warnings, Gauges and Lights <b>830;</b> Passenger Restraints <b>840;</b> Exterior Lights <b>850;</b> Spark and Fire Abatement <b>860;</b> and Collision Avoidance subsystem <b>870.</b>

0051In one embodiment, Airbags <b>810,</b> may be either enabled or disabled depending upon the user's preferences or safety needs. For instance, in normal user mode all of the airbags in the car would be active. However, certain users with access to the necessary security level may disable certain airbags via Airbags subsystem <b>810.</b> In cases where a parent always drives with a young child in a car seat, the airbags adjacent to the car seat might be disabled by setting the appropriate user specific preferences. Alternatively, the user or certain passengers might be of such slight stature that deployment of the airbags may be more hazardous than the accident itself, especially in a low-speed accident. In that case, that user may prefer to disable one or more of the airbags in the passenger compartment via Airbags subsystem <b>810.</b>

0052Other preferences might disable antilock braking for certain users via Antilock Braking subsystem <b>820.</b> Also, Warnings, Gauges and Lights subsystem <b>830</b> may have preferences as far as warning defaults and the like, to be set depending on the user's preferences. These may consist of configuring graphic displays to setting warnings messages as either visual, text, voice or audio warnings. Passenger Restraints subsystem <b>840</b> might be set to require all passengers to be fully restrained before the vehicle will move. One method of implementing this requirement totally within Safety system <b>800</b> would be for vehicle Antilock Braking subsystem <b>820</b> to engage the brakes, thereby prohibiting the vehicle from moving until all passengers are fully restrained.

0053Other subsystems include Exterior Lights subsystem <b>850,</b> which monitors and controls the exterior lights. Therefore, when an exterior light burns out or is damaged, Systems Monitoring system <b>290</b> immediately communicates the status to Onboard Computer <b>20,</b> and the information is conveyed to the user via User Interface <b>28</b> or through Warnings, Gauges and Lights subsystem <b>830.</b> Another subsystem important to safety is Spark and Fire Abatement subsystem <b>860.</b> While most modern cars and trucks contain only minimal spark and fire subsystems, in the case of airplanes and marine vehicles, because of the extreme danger uncontrolled heat and fire pose to those vehicles' safety, they contain more sophisticated spark and fire abatement subsystems.

0054Another subsystem important to the safety of operation is Collision Avoidance subsystem <b>870.</b> Because collision avoidance is one of the most rapidly changing safety items on a vehicle today, even more advancement in the area of collision avoidance is expected in the future. A collision avoidance subsystem may be further partitioned into front and rear subsystems or even into xyz direction subsystems for vehicles that do not travel along a plane. In one embodiment, Collision Avoidance subsystem <b>870</b> is linked inexorably to Antilock Braking subsystem <b>820,</b> Passenger Restraints subsystem <b>840</b> and Airbags subsystem <b>810.</b> In addition, Collision Avoidance subsystem <b>870</b> is connected to Communications/Interface system <b>500.</b> Collision Avoidance subsystem <b>870</b> will continually monitor the vehicle's position with respect to the positions of all other vehicles and obstacles in the proximity of the vehicle. Once the possibility of a collision is detected by Collision Avoidance subsystem <b>870,</b> Collision Avoidance subsystem <b>870</b> attempts to warn the operator through Warnings, Gauges and Lights subsystem <b>830</b> using audible and visible alerts intended to make the operator aware that a collision involving this vehicle is likely. At some point before an imminent collision, Collision Avoidance subsystem <b>870</b> may act autonomously to avoid the collision. For instance, Collision Avoidance subsystem <b>870</b> may set the antilock brakes via Antilock Braking subsystem <b>820.</b> Collision Avoidance subsystem <b>870</b> may also communicate to the local authorities via Communications/Interface system <b>500</b> that a collision involving the vehicle is likely or imminent. Collision Avoidance subsystem <b>870</b> may also allow airbags to deploy faster by using Airbags subsystem <b>810</b> in combination with Collision Avoidance subsystem <b>870.</b> Then, rather than relying on the airbags to deploy in response to impact sensors along the bumpers and sides of the vehicle, the user modifies the user specific parameters associated with Collision Avoidance subsystem <b>870</b> to deploy the airbags when the vehicle reaches a threshold proximity to the obstruction. Therefore, rather than the airbag being triggered by a certain amount of front or rear-end deformation of the vehicle, the airbag deployment is triggered just before the vehicle impacts with the obstruction, thereby saving valuable milliseconds in deployment. Also, changing the user specific parameters to deploy airbags sooner allows for lower speeds of acceleration within the airbags, which has been determined to be advantageous to smaller and lighter users and passengers.

0055Another embodiment of the present invention, Theft Deterrence and Recovery subsystem <b>210,</b> might be connected with both Antilock Braking subsystem <b>820</b> and Exterior Lights subsystem <b>850.</b> This combination would allow Theft Deterrence and Recovery subsystem <b>210</b> to activate certain exterior lighting configurations and/or antilock brakes at certain times during a vehicle theft. In one example, the user may pre-set certain user specific parameters that would allow a vehicle theft to occur only in certain places. For instance, it might be that the user would allow the vehicle to be stolen from the user's home but not the user's place of business. This is an important safety consideration, being that there is a likelihood of violence occurring during a frustrated theft attempt. Therefore, in attempt to avoid frustrating a potential vehicle thief at the user's home, the user may elect to allow the vehicle to be stolen and then alert the local authorities via Communications/Interface system <b>500.</b> In addition, Theft Deterrence and Recovery system <b>210</b> could reconfigure certain exterior lights that are not visible to the present unauthorized operator. For instance, a vehicle that is being operated by an unauthorized user might be configured to flash one exterior brake light each time the brake pedal is pressed. Therefore, authorities witnessing a flashing rear brake light might have reasonable suspicion to stop such a vehicle and inspect it. In another embodiment, the Antilock Braking subsystem <b>820</b> may be set to trigger the brakes upon the unauthorized user traveling one or two miles from the user's home. In that case, the vehicle would become completely inoperable and the unauthorized user would hopefully abandon the vehicle. Thus, the vehicle would be available for safe recovery.

0056<b>Figure 9</b> illustrates Engine Performance system <b>900</b> as related to the present invention. Like Safety system <b>800,</b> Engine Performance system <b>900</b> requires higher level security for authorization by Onboard Computer <b>20.</b> User preferences are stored in Onboard Computer <b>20</b> system Memory <b>22</b> just as in the cases described above. Engine Performance system <b>900</b> consists of several possible subsystems, including Engine RPM (i.e., revolutions per minute) subsystem <b>910;</b> Vehicle Speed subsystem <b>920;</b> Vehicle Acceleration subsystem <b>930;</b> Engine Emissions subsystem <b>940;</b> Fuel Miser subsystem <b>950;</b> and Load/Altitude Adjustment subsystem <b>960.</b> Once the user is identified to Onboard Computer <b>20</b> via User Interface <b>28,</b> Onboard Computer <b>20</b> analyzes the user ID to ascertain the user's security level. If the user has a sufficiently high security level, as authorized by Onboard Computer <b>20,</b> then the user may reset the user specific parameters for the engine performance subsystems in Engine Performance system <b>900.</b> It would be conducive to safe operation of the vehicle for certain users who do not possess the necessary skill, age or expertise to operate the vehicle safely, to be limited by the vehicle's performance. One way to limit the vehicle's performance is by limiting or restricting the engine's RPM via Engine RPM subsystem <b>910.</b> The engine might only be allowed to rev up to a certain level, say 4000 RPMs. Such a limitation would be advantageous where there is a possibility that a younger user might have the tendency to race an engine at a stoplight or in a garage to extremely high RPM levels which could damage the interior components of the engine. Another important aspect of the present invention is limitation of the vehicle's speed via Vehicle Speed subsystem <b>920.</b> Invariably, speed is an important factor in both the frequency and severity of on-the-road accidents. By limiting the vehicle's speed for novice users, the number and severity of these accidents can possibly be decreased. This is also an important concept for vehicles other than on-the-road vehicles, such as airplanes and marine vehicles.

0057Vehicle acceleration is another important component of a vehicle safety program. If vehicle acceleration is limited via Vehicle Acceleration subsystem <b>930,</b> the user can only accelerate the vehicle at a certain rate. This reduces the likelihood that younger users who enjoy the fast take-off from a red light or stop sign would participate in such activities. In the case of other vehicles, such as aircraft and marine vehicles, vehicle acceleration may also be measured in deceleration. Extremely rapid deceleration in an airplane or boat can cause the vehicle to become unstable. For instance, in an aircraft extremely rapid deceleration may cause the aircraft to flip or go into a spin that is not recoverable because the vehicle's forward momentum has been lost. Extremely rapid deceleration of a boat causes a wake of water to come over the stern of the boat, thus swamping the vehicle. Therefore, extremely rapid deceleration in aircraft or marine vehicles is highly undesirable.

0058Another subsystem controlled by Engine Performance system <b>900</b> is the Engine Emissions subsystem <b>940.</b> While Engine Emissions subsystem <b>940</b> would generally be inaccessible to the vehicle's operators, it might be advantageous to reduce engine emissions even further below the Environmental Protection Agency (EPA) recommended standards. Therefore, on certain days such as smog alert days and the like, engine emissions may be set to an even stricter standard via Engine Emissions subsystem <b>940.</b> Clearly this would have a detrimental effect on the performance of the vehicle and would not be appreciated by certain users. In a similar manner, Fuel Miser subsystem <b>950</b> may be set to require the vehicle's overall performance to maintain a certain vehicle fuel mileage. Although the vehicle operator may be allowed one or two quick accelerations, thereafter the performance of the vehicle would be strictly limited to make up for those accelerations and maintain the overall fuel efficiency of the vehicle.

0059Finally, Engine Performance system <b>900</b> contains Load/Altitude Adjustment subsystem <b>960.</b> Load/Altitude Adjustment subsystem <b>960</b> would change the engine's performance depending upon the altitude of the vehicle and the load the vehicle is carrying. Thus, when the vehicle is heavily loaded, as in the case of a truck pulling a boat, the vehicle performance characteristics would change from being a faster or faster accelerating vehicle to that of being a vehicle that is more adept for towing, especially up hills, boat ramps and the like. This, of course, would be at the expense of other performance characteristics in the subsystem.

0060As in Safety system <b>800,</b> Engine Performance system <b>900</b> would be inexorably linked to Theft Deterrence and Recovery subsystem <b>210.</b> Once Theft Deterrence and Recovery subsystem <b>210</b> detected an unauthorized user, the engine performance parameters stored in Memory <b>22</b> would set Engine Performance system <b>900</b> to levels that would make the vehicle inoperable. For instance, Vehicle Speed <b>920</b> parameters might be set to limit the vehicle to zero speed, and Engine RPM subsystem <b>910</b> might be set to limit the engine to zero RPM. Also, Vehicle Acceleration subsystem <b>930</b> could be set to zero. Thus, the vehicle's engine would be rendered inoperable.

0061Another important aspect of the present invention is how the user interfaces with Onboard Computer <b>20. Figure 10</b> illustrates the user interface system as implemented in the present invention. User Interface system <b>28</b> may employ a variety of different subsystems, singularly or in combination with each other. One of the exciting new concepts to be available involves SmartCard <b>1015</b> and SmartCard Reader <b>1010.</b> SmartCards are well known in the industry and will not be described in detail here; but for the purpose of this invention, SmartCard <b>1015</b> contains at least Memory <b>1016</b> which is read by SmartCard Reader <b>1010.</b> When a user enters the vehicle, the user is identified by swiping SmartCard <b>1015</b> in SmartCard Reader <b>1010.</b> Onboard Computer <b>20</b> recognizes the input from SmartCard Reader <b>1010</b> and accesses Memory <b>22</b> for information concerning the user. In one embodiment, Onboard Computer <b>20</b> merely checks the data available from Memory <b>1016</b> on SmartCard <b>1015</b> with the data for the particular user stored in onboard system Memory <b>22.</b> In other embodiments, Onboard Computer <b>20</b> works in concert with a processor (not shown) on SmartCard <b>1015</b> in a series of ID verification steps designed to authorize the user.

0062Another advantage of SmartCard <b>1015</b> is that SmartCard Memory <b>1016</b> may contain other than merely numeric data. Memory <b>1016</b> may include all data pertaining to the owner of the SmartCard, including all user specific preferences applied in setting the various functions and sub-functions of the vehicle. Memory <b>1016</b> might also include user identification data such as the user's fingerprint pattern, the user's voice print pattern, the user's iris print pattern or the user's handwriting pattern. In one example, the card could actually initiate the authorization process via Onboard Computer <b>20.</b> The user would then be required to confirm identity on a second user interface, such as Fingerprint Reader <b>1020.</b>

0063Importantly, SmartCart Memory <b>1016</b> can be used to store user specific parameters for one vehicle or for several vehicles. In that same way, Memory <b>22</b> may store the user specific parameters for all users authorized to operate the vehicle.

0064System fraud and vehicle theft could be greatly reduced if the intended user who has authorized SmartCard <b>1015</b> could also be confirmed as the actual operator of the vehicle. The surest way to achieve this goal is to register some biological attribute, or biometric information, of the user with the vehicle interface. The most widely used biometric data which identifies users is an image or picture of the user. The second most useful biometric, and probably the easiest for an onboard system to analyze, would be a user's fingerprint. In another embodiment of the present invention, once SmartCard <b>1015</b> is read by SmartCard Reader <b>1010</b> and authorized by Onboard Computer <b>20,</b> the user is then required to input User's Finger <b>1025</b> via Fingerprint Reader <b>1020.</b> Onboard Computer <b>20</b> then compares the user's fingerprint pattern to either a fingerprint identified with the user's data stored in onboard Memory <b>22</b> or stored on SmartCard Memory <b>1016.</b> Once the user has been identified by Onboard Computer <b>20</b> as the rightful possessor of the SmartCard <b>1015,</b> Onboard Computer <b>20</b> then allows the user to access the highest level of security authorized within Onboard Computer <b>20.</b>

0065Verification of a user's ID may be accomplished by a number of other means, including Touch Pad <b>1060</b> or Number Pad <b>1070</b> via Graphical User Interface (GUI) <b>1080.</b> While GUI <b>1080</b> is advantageous, it is not essential to practice the present invention. In fact, GUI <b>1080</b> may include Touch Pad <b>1060</b> or it may not, or it may include Number Pad <b>1070</b> or it may not, or any one of the three could be used in combination.

0066In another embodiment, the present invention may require biometric user identification via a voice print stored in system Memory <b>22</b> or on SmartCard <b>1015</b> Memory <b>1016.</b> In that case, User Interface system <b>28</b> includes Microphone <b>1030.</b> The user interfaces with the system by inputting User's Voice <b>1035</b> to Microphone <b>1030</b> and then Onboard Computer <b>20</b> compares the voice pattern with that of the user's voice pattern stored in system Memory <b>22</b> or SmartCard <b>1015</b> Memory <b>1016.</b>

0067Biometric information stored in Computer memory <b>22,</b> or some other convenient memory, is useful for practicing certain aspects of the present invention other than verification of the user's identification. In an alternative embodiment of the present invention, the user is authorized by Onboard Computer system <b>20</b> by verbally entering the user's password into Microphone <b>1030,</b> rather than using Touch Pad <b>1060</b> or Number Pad <b>1070.</b> User identity verification is performed simultaneously by Onboard Computer system <b>20</b> rather than as a second step, thus saving the user the time needed for authorization. Changing user specific preferences associated with one or more onboard systems could also be performed simultaneously by merely speaking into Microphone <b>1030.</b> For instance, rather than the user first being authorized by Onboard Computer <b>20</b> and then entering the user specific preference via GUI <b>1080,</b> the user merely changes the preferences orally. Onboard Computer system <b>20</b> simultaneously recognizes the user's voice pattern from the voice pattern stored in memory and recognizes the user's speech commands. The user's speech is parsed for recognizable commands while authorizing the user's voice. Onboard System <b>20</b> then performs the user's commands, such as changing user specific preferences.

0068In an extreme example of one embodiment of the present invention, in an emergency, a rider in a vehicle might actually override the vehicle operator's access authority and change the operator's user specific performance preferences. For instance, if a vehicle operator is operating the vehicle in a careless or unsafe manner, or if the operator becomes disabled or unresponsive, the rider may verbally change the performance preferences, causing the vehicle to come to a stop. Because the rider's voice pattern and speech are recognized by Onboard Computer system <b>20,</b> the rider need not manually interface with the onboard computer.

0069Speech or voice recognition, as a general proposition, is well know in the art, and different methods are understood by those skilled in man-machine interfaces such as: U.S. Patent Number 5,671,328, "Method And Apparatus For Automatic Creation Of A Voice Recognition Template Entry", Fitzpatrick, September 23, 1997, Gregory P. <i>et al</i>, directed to a data processing system for automatically creating voice processing template entries from a plurality of commands received by the data processing system; U.S. Patent Number 5,664,061, "Interactive Computer System Recognizing Spoken Commands", September 2, 1997, Andreshak, <i>et al</i>, directed to an interactive computer system having a processor executing a target computer program and having a speech recognizer for converting an utterance into a command signal for the target computer program; and U.S. Patent Number 5,649,060, "Automatic Indexing And Aligning Of Audio And Text Using Speech Recognition", July 15, 1997, Ellozy, <i>et al</i>, directed to a method of automatically aligning a written transcript with speech in video and audio clips by using an automatic speech recognizer which decodes speech (recorded on a tape) and produces a file with a decoded text. Each of the above are assigned to the assignee of the present application and are incorporated by reference in their entirety.

0070Another important aspect of the present invention is pre-authorizing electronic transactions, E-Commerce, by merely verbalizing the transaction information. In so doing, the vehicle operator is free to generate commodity transaction data concerning a specific vendor while operating the vehicle. For instance, while entering the fueling station from the highway, a user might set parameters for authorization of a particular fuel vendor, grade and amount of fuel, and designation of a payment method. Thus, all information needed to conduct the transaction is compiled in advance of the vehicle entering the fueling station. Because the entire transaction is stored in onboard computer Memory <b>22</b>, once the vehicle is at the fuel pump, fueling is virtually automatic, requiring almost no interaction from the vehicle operator.

0071Other goods and services might also be initiated using speech recognition technology while operating the vehicle. Placing telephone calls, transmitting facsimiles, checking e-mail and accessing personal pagers would all be easily and safely accomplished while operating the vehicle using Cellular/PCS subsystem <b>520.</b> Even accessing long distance carriers and the Internet, and downloading pay-per-view entertainment events could be accomplished from within the vehicle. Alternatively, the present invention could be utilized for such mundane tasks as purchasing take-out fast food in advance while operating the vehicle so that the food is ready for pick-up when the vehicle arrives at the restaurant's drive-in window. While the present invention primarily utilizes a personal area network (PAN) technology for transferring pre-stored commodity transaction data between the vehicle and the vendor, Satellite Com Link subsystem <b>510</b> or Cellular/PCS subsystem <b>520</b> could easily perform the identical task.

0072The present invention would be especially helpful in situations such as long haul trucking where a vehicle operator is constantly picking up and delivering cargo, and entering into new payment and bond arrangements with different carriers.

0073Another possible means of verifying the user's identity includes the user's iris pattern. In this case, CCD Camera <b>1040</b> would input an image of User's Eye <b>1045</b> to Onboard Computer <b>20</b> for analysis and comparison with an iris pattern stored in system Memory <b>22</b> or on SmartCard Memory <b>1016.</b> In another embodiment, User Interface <b>28</b> might include a sample of the user's handwriting within system Memory <b>22</b> or within SmartCard Memory <b>1016.</b> The user would input a pre-determined sentence or series of words on Touch Pad <b>1060</b> as directed by the output of GUI <b>1080.</b> Onboard Computer <b>20</b> then compares that series of slashes and gestures with the pattern stored in system Memory <b>22.</b>

0074In another embodiment of the present invention, the user is merely required to enter the proper personal User's PIN <b>1075</b> via Number Pad <b>1070.</b> Although generally the personal identification number is an unchanging number that the user always possesses, recently and with the advent of GUIs, the personal identification number is more than merely a number. For instance, the personal identification number can actually be an operation the user applies to a number, or an 'algorithmic password.' An example of an algorithmic password is to display a number to the user, such as '1234,' via GUI <b>1080.</b> An algorithm known only to the user might be to subtract each of the outside digits from 10 and transpose the two inner digits. Thus, in response to seeing the number '1234,' the user inputs the number '9326' on GUI <b>1080.</b> Even someone watching the user input that number would have no idea what algorithm the user applied to the display number, as the operation is known only to the user. More complicated algorithms can be formulated to test the dexterity of the user. Such dexterity tests are well known as effective in deterring intoxicated users and users who are incapable of safely operating a vehicle due to lack of sleep or illness. In the final embodiment, User Interface <b>28</b> may include Breathalyzer <b>1050</b> to test User's Breath <b>1055</b> for alcohol content. A user that has been prone to drive while under the influence of drugs or alcohol would be required to demonstrate sobriety before being allowed to operate the vehicle. In this case, User's Breath <b>1055</b> can be analyzed by Onboard Computer <b>20</b> to detect the presence of known intoxicants. The user may be given several opportunities to pass the breathalyzer test before the user is de-authorized and the vehicle is disabled by Onboard Computer <b>20.</b>

0075Finally, a user possessing a sufficiently high security level, such as a master user or an administrator, may authorize subsequent identification verification by proxy, thereby allowing access to certain onboard systems by users which have been denied access on a verification basis. This is an important feature for resolving identification verification problems brought about by failure of an identification verification subsystem.

0076An important aspect of the present invention is that one or all of these identification verification subsystems can be included in User Interface system <b>28.</b> The advantage of SmartCard <b>1015</b> is that it contains Memory <b>1016,</b> which can be updated and obliterated while not in contact with Onboard Computer <b>20.</b> Unlike onboard computer Memory <b>22,</b> SmartCard <b>1015</b> can be read and updated while the user is not in the vehicle, in fact while the vehicle is not even in the user's possession. Therefore, the user specific preferences stored on SmartCard Memory <b>1016</b> can be updated by someone other than the user, placing the user at the mercy of the fleet dispatcher or vehicle owner or parents, or whomever is ultimately responsible for the vehicle. Also, the SmartCard might contain user preferences for a variety of different vehicles.

0077Alternatively, SmartCard Memory <b>1016</b> contains user specified parameters in an independent device format. By using an independent device format for storing user specified parameters, the user may set specified parameters which are desired for use by a variety of different vehicles and vehicle types. The device-independent parameters would then be transformed into device-dependent parameters by the onboard computer of any vehicle in which the SmartCard is inserted. While some parameters may require some fine tuning or tweaking once the user becomes accustomed to each different vehicle, the majority of the user specified parameters will fulfill the user's expectations without tweaking. Tremendous memory savings are achieved by storing user specific parameters in device-independent format on the SmartCard. Rather than storing multiple sets of user specific parameters on a variety of different vehicles, the one set of user specified parameters which is stored on the SmartCard is transformed into device-dependent parameters by any onboard computer of a specific vehicle into which the SmartCard is inserted.

0078<b>Figure 22</b> illustrates a preferred embodiment of the present invention involving electronic commerce between a vehicle and a vendor. In a preferred embodiment of the present invention, the vehicle operator commences the fueling operation between a vehicle equipped with personal area network (PAN) technology, and a vendor computer system designed to communicate with a vehicle which incorporates PAN technology. PAN Technology is the subject of U.S. Patent No. 5,796,827, August 18, 1998, System And Method For Near-Field Human-Body Coupling For Encrypted Communication With Identification Cards, Coppersmith, Don <i>et al</i>, assigned to the assignee of the present application and is incorporated in its entirety herewithin. In this example, a vehicle such as a car with encrypted identification modulated on an electric field carrier communicates with a fuel pump which receives the modulated data indexed to the specific vehicle identification. Through the use of PAN technology, the means of transmission is through one of the fuel hose, the fuel itself or a hidden conductor incorporated in the fuel hose/nozzle apparatus. In such a configuration, the user merely connects the fuel nozzle to the fuel port in the vehicle and PAN technology transmission means authenticates both the vehicle and the vendor computer systems.

0079It is important to note that while a preferred embodiment of the present invention utilizes PAN technology for affecting the transaction data transfer, PAN need not be the only communications link and is not meant to limit the practice of the invention in any way. Satellite Com Link subsystem <b>510</b> or Cellular/PCS subsystem <b>520,</b> could easily perform transactional data transfer tasks, in advance of the vehicle connecting to the vendor's PAN data port or simultaneous with the commodity transaction.

0080<b>Figure 23</b> illustrates a representation of the modulated signal passing between the vehicle and the fuel pump using PAN technology. In one embodiment of the present invention, a modulated signal passes encrypted information between the vehicle and the fuel pump by either passing extremely low voltages through the hose itself or through a receiver in the pump which capacitively senses the modulated signal on the electronic field carrier of the vehicle. Again, the information contained on the carrier would be encrypted in order to protect both the vendor and the vehicle operator.

0081<b>Figure 11</b> illustrates one embodiment of the present invention. Through the use of a personal area network utilizing Personal Area Network (PAN) Technology, a vehicle can communicate autonomously with a vendor for predetermined goods and services with very little interaction from the user. In one embodiment of the present invention, the vendor is a fuel distributor. In this case, the process starts at step <b>1100.</b> The user inserts the fuel pump nozzle into the vehicle (step <b>1105</b>). The user may not need to insert the fuel nozzle; rather, the fuel nozzle may couple automatically to the vehicle, depending on the pumping configuration provided by the vendor. Additionally, the system may include infrared data sensing technology incorporated on the fuel nozzle, which would automatically sense proper insertion of the nozzle to the vehicle port. Standards set for infrared sensing protocols through The Infrared Data Association™ (IrDA), Walnut Creek, California. Using a nanovolt signal that passes through the hose between the vehicle and the pump computers, the pump computer attempts a handshake with the vehicle computer (step <b>1110).</b> If for some reason the handshake does not occur, the process ends and manual fueling by conventional means becomes necessary (step <b>1165).</b> If the handshake is successful, the pump computer receives data from the vehicle computer, including the vehicle and user identification parameters, the EFT cash ID number, the grade of fuel selected, the cash amount authorized, the reporting TCP/IP address and other optional parameters (step <b>1115).</b> An important feature of the present invention is that the user is relieved of the responsibility for any interaction with the vendor because all options concerning the transaction can be predetermined, selected in advance and included with the data to be transmitted to the vendor via the pump computer. The pump computer then transfers pump data to the vehicle computer, including the vendor or business and affiliation parameters, the grade of fuel, the cash amount intended to be transferred and other optional parameters provided by the vendor (step <b>1120).</b> The pump computer then receives a final authorization to debit from the cash account from the vehicle computer (step <b>1125).</b> The default cash amount can be held from the EFT cash account, SmartCard or personal/commercial credit card account, and the pump computer authorizes fueling up to the default amount (step <b>1130).</b> The user then begins fueling or, alternatively, the fueling begins automatically (step <b>1135).</b>

0082In one embodiment, while fuel is transferred from the pump to the vehicle, the fueling data corresponding to the fuel transfer is also transferred to the vehicle computer while fueling is in process (step <b>1140).</b> At some time, the fueling is discontinued (step <b>1145).</b> Fueling can either be discontinued on the operator's accord, or as an automatic function when the vehicle is full or as the default amount to be debited is reached. The pump computer then tallies the fuel transfer and the EFT cash transfer (step <b>1150).</b> During this procedure, the vehicle computer and the pump computer send status signals. If the flow of status signals between the vehicle computer and the pump computer is broken, the status at the time of the break is known by both the vehicle computer and the pump computer. In one embodiment, after fueling is complete and the fuel and cash transfers have been tallied, the pump computer will then access the vehicle's home base or reporting site either as an e-mail or through some other protocol using a TCP/IP address. The pump computer communicates the reports of the transaction as provided by the vehicle computer to the pump computer in step <b>1115,</b> to the designated reporting site. Optionally, this information may be secured by transmitting the signals as encrypted data between the vehicle computer and the pump computer. The report includes any fault that may have occurred during the fueling (step <b>1155).</b> During this reporting, if there is a discrepancy between the fuel transfer and the EFT cash transfer, or if a fault occurs during the fueling, or if a personal credit card is used, the pump computer notes this occurrence and attempts to reconcile the two accounts with the computer at the vehicle's home base. The pump computer or the affiliate's computer flags the EFT cash account and the user ID on the affiliate's network computer (step <b>1160).</b> In that way, the affiliate system can keep better track of this particular EFT cash account and user ID for any suspicious activity and also ensure that the EFT cash was actually debited from the user's account. The process ends at step <b>1165.</b>

0083Returning to step <b>1155,</b> the pump computer attempts to communicate to the reporting site via either cellular, PCS, satellite communication link or some other communication means. This information may be communicated via land line to the reporting site's TCP/IP address as an e-mail or through some other more sophisticated protocol. This is an important feature of the present invention because, in so doing, the reporting site, which may be a large vehicle terminal, can enter the data to the vehicle, and the user of the vehicle then may transfer the data in reconciled form back to the vehicle via Communications/Interface system <b>500.</b>

0084The communications system then enters the fueling data to the appropriate log, such as Maintenance Log <b>640</b> and Driving Log <b>650.</b> In this way, the vehicle itself can automatically track its performance based on the amount of fuel the vehicle requires at certain times while enroute. As a result, an expert mechanic can read Maintenance Log <b>640</b> and compare it to Driving Log <b>650</b> and thus determine the efficiency level of fuel consumption. A mechanic can also, by evaluating Maintenance Log <b>640</b> and Driving Log <b>650,</b> gather other important information. For instance, after the vehicle has been refueled at a number of various stations, the mechanic can determine which brand of fuel produces the best performance from which vehicles. As well, the mechanic can determine if there is any pilfering of fuel from the vehicles while they are parked for the next day's use. Maintenance Log <b>640</b> could also have automatic functions that alert the user via GUI subsystem <b>1080</b> as to what the fuel efficiency is over a period of time and/or as the user is operating the vehicle.

0085<b>Figure 12</b> illustrates another embodiment of the present invention involving a fault occurrence during the fuel transfer process. <b>Figure 12,</b> steps <b>1200</b> to <b>1235,</b> are identical to steps <b>1100</b> to <b>1135</b> in the previous illustration (<b>Figure 11).</b> Beginning at step <b>1235,</b> the fuel is transferred from the pump to the vehicle along with the corresponding data about the fuel transfer. At some time during the process, a system fault is detected by the pump (step <b>1240).</b> Fueling is immediately aborted (step <b>1245).</b> The pump then tallies the fuel transfer and the EFT cash transfer (step <b>1250).</b> Then however, rather than completing the process, the pump computer determines if the communications have been interrupted between the pump and the vehicle (step <b>1253).</b> If there has been an interruption, control is passed back to step <b>1210</b> where the pump again attempts a handshake between itself and the vehicle computer. If the handshake is successful, the process starts anew and fueling is resumed where it left off at step <b>1210.</b> If no handshake can be established, the process is ended. If, however, there is no communication between the pump and Onboard Computer <b>20,</b> there may be a fault in either the pump communication system or the PAN interface of the vehicle computer. In this case, the pump accesses the reporting site as described above and transfers the transmission data to the reporting site, including the fault occurrence information (step <b>1255).</b> Step <b>1255</b> is also performed if communication between the pump computer and the vehicle computer remains intact. Again, because there was an interruption in the fueling, whether or not a communication link exists between the pump and vehicle, the user's cash account and the user ID are flagged on the affiliate's network computer. Flagging alerts the vendor that there was a problem with the last fuel transfer between the vehicle and the computer (step <b>1260).</b> The process then ends at step <b>1265.</b>

0086<b>Figure 13</b> is identical to <b>Figure 12,</b> except that it takes the perspective of the vehicle's onboard computer. The process starts at step <b>1300</b> where the vehicle operator inserts the fuel nozzle into the vehicle at step <b>1305.</b> The vehicle Onboard Computer <b>20</b> looks for a handshake between the pump computer and the vehicle computer (step <b>1310).</b> The handshake data will be transferred to the vehicle onboard computer through a Personal Area Network Port <b>530</b> of Communications/Interface system <b>500.</b> If no handshake data is transferred from the pump computer to the vehicle computer, then it cannot be assumed that the vendor is equipped to handle PAN technology and the process ends at step <b>1370.</b> If the transfer is successful, the vehicle transfers certain data from the vehicle's computer, including the identity of the vehicle and data, the EFT number, the grade of fuel desired, the cash amount authorized, the reporting TCP/IP address or communications ports, and optional parameters (step <b>1315).</b> This step relieves the user of many of the mundane tasks that a vehicle operator typically must perform at a fuel stop. For instance, the user need not select the grade of fuel, turn on the pump or pay the cashier; and in some cases, the user may not even need to insert the fuel nozzle into the vehicle because that activity is automated as well.

0087Onboard Computer <b>20</b> then receives pump data from the pump computer, including the business and affiliation parameters, the grade of fuel intended to be transferred, the cash amount intended for transfer which was mirrored from the vehicle in step <b>1315,</b> and other optional parameters (step <b>1320).</b> Onboard Computer <b>20</b> then authorizes the affiliate to debit from the EFT cash account the amount agreed upon in steps <b>1315</b> and <b>1320</b> (step <b>1325).</b> The fueling process begins at step <b>1330.</b> As the fueling process progresses, the onboard computer receives fueling data from the pump computer, including the amount of fuel transferred and the status of the systems during the transfer (step <b>1335).</b> If Onboard Computer <b>20</b> detects a fault during the fuel transfer process (step <b>1340),</b> the fueling is immediately aborted (step <b>1445).</b> Because the transfer of fuel is largely controlled by the pump, aborting the fueling process might consist of the vehicle onboard computer notifying the pump computer that fueling has been completed, thereby attempting to force the pump computer to terminate the fueling process. Also, because a fault during the fueling process could be a safety issue, Onboard Computer <b>20</b> might attempt to warn the user via Warnings, Gauges and Lights subsystem <b>830</b> or GUI subsystem <b>1080.</b>

0088In any case, some time after the fault is detected the fueling process is aborted. The onboard computer then reads the last fuel transfer data transferred from the pump computer and checks the EFT cash transfer on the SmartCard account (step <b>1350).</b> The onboard computer then tries to determine if there has been an interruption in communication between the pump and the vehicle. If so, Onboard Computer <b>20</b> looks for another handshake between the pump and computer and returns to step <b>1310.</b> If the handshake is completed, the process begins anew at step <b>1315.</b> However, if no communication is apparent between the pump computer and the vehicle computer, the vehicle computer will access the reporting TCP/IP address of its reporting site and report the transaction fault, including the amount transferred. The vehicle computer will also alert the reporting site to the possibility of a hold placed on the EFT account (step <b>1355).</b> This could normally be done through Communications/Interface system <b>500</b> either via Cellular PCS subsystem <b>520</b> or Satellite Com Link <b>510.</b> The reporting site is thus aware that the fault has occurred in the fueling process; and when the affiliate which controls the pump computer contacts the reporting site, the reporting site is available with the vehicle data to reconcile the report as it comes in from the affiliate. At some point, the vehicle must reconcile its own EFT cash account record with the vehicle transaction report received from the affiliate's network computer. If the handshake has been reestablished or no fault occurred, this is a normal step in the process. If not, the pump computer may require communications back from the vehicle's home reporting site before the reconciliation can be accomplished at step <b>1360.</b> Once the appropriate communications have been established and reconciliation occurs at the vehicle's home site, the vehicle can then reconcile its own EFT cash account or SmartCard. Confirmation is then reported to the home site via the TCP/IP address (step <b>1365).</b> The process then ends at step <b>1370.</b>

0089Other embodiments of the present invention are also possible. For instance, rather than having the cash available on a SmartCard, the pump computer may contact the affiliate or the affiliate's financial institution to debit it automatically from the home user's financial account. A record still could be kept by Onboard Computer <b>20</b> and/or at the vehicle's home reporting site. However, no actual transferable cash would be held on a SmartCard or in a vehicle computer's memory. In another embodiment, the system may utilize both cash transfer options. For instance, the primary option would be to transfer from the user's financial institution a cash amount to cover the fuel transfer. However, if for some reason the link to the financial institution is down or some other problem occurs within either the user's system, the financial network or the pump system, cash may be available on a SmartCard in an emergency. In that case, the SmartCard is debited for the cash amount of the fuel transfer.

0090In other embodiments, PAN technology works in concert with the other systems controlled by Onboard Computer <b>20.</b> For instance, when the operator of the vehicle detects that the fuel level is nearing a point where the fuel needs to be replenished, Maintenance Log <b>640</b> may automatically evaluate which fuel brands and grades provide the best performance for the vehicle. That information could then be transferred to Maps and Databases subsystem <b>620,</b> and the operator of the vehicle could then be informed as to the identities of those vendors of the best performing brands along the vehicle's route. The vehicle operator could even be given directions from the exact position where the vehicle is located to the next possible refueling stop along the route via GPS subsystem <b>610</b> (for locating the vehicle) and Maps and Databases subsystem <b>620.</b> If Onboard Computer <b>20</b> detects that the vehicle has passed a suitable vendor, the system could identify the next possible vendor along the vehicle's route via Maps and Databases subsystem <b>620</b> and provide directions for that vendor to the vehicle operator based on the vehicle position ascertained by GPS subsystem <b>610.</b>

0091As can be seen, the fully integrated PAN technology, along with Onboard Computer system <b>20,</b> provides significant convenience and time savings for the vehicle operator. More importantly, detailed records of performance, maintenance and cost control are provided to the fleet controllers of the vehicle. The problem of maintenance and use costs increases exponentially with the number of vehicles, yet with the system of the present invention in place, the amount of physical activity needed to be performed in many aspects actually decreases. This is because the time required for updating maintenance logs, driving records and performance records does not significantly increase as the number of vehicles in use increases. Therefore, problems associated with vehicle performance or efficiency, or issues associated with vendor problems, would come to light much earlier than with a single vehicle thereby further reducing the cost of the system and increasing its convenience.

0092<b>Figures 14 to 21</b> illustrate the data structure of the present invention, which can be stored in SmartCard Memory <b>1016,</b> Onboard Computer <b>20</b> Memory <b>22,</b> or even as encrypted information on a swipe card. At a low level, the data structure contains several fields of data which are unique to the user. User Record <b>1400</b> shows fields having user ID verification, security level preference limits and user logged data. Each field of User Record <b>1400</b> is in turn dynamically linked to other lists containing more detail associated with the fields listed under User Record <b>1400.</b>

0093<b>Figure 15</b> illustrates the User ID data structure. User ID data structure <b>1500</b> has two fields, the user's name and the user's ID number. Either of these fields can be used as a means to identify a user and then retrieve data concerning the user from one of the above-mentioned memories.

0094<b>Figure 16</b> illustrates the Verification data structure <b>1600.</b> Once the user has been identified, a verification sequence takes place as described above discussing User Interface <b>28.</b> Pertinent data used in identification of the user are stored in Verification <b>1600</b> data structure or, alternatively, links may be provided for memory addresses where pertinent data is located in memory. Verification <b>1600</b> data structure contains a password known only to the user which may be in the form of a pin number, algorithmic password, handshake data for verifying the user's SmartCard, pertinent finger print data, eye print data, voice print data, and finally, a field for verifying a proxy which has been authorized by a user at the master security level or higher. The information contained in these fields is used to verify that the person intending to operate the vehicle is actually the person who is identified in User ID <b>1500.</b>

0095<b>Figure 17</b> illustrates Security Level data structure <b>1700.</b> Once positive identification of the user has been established, the user is granted a security level by Onboard Computer <b>20.</b> Security Level <b>1700</b> data structure shows different levels of security. As mentioned before, these are normal user, master user, administrator, service center, parking attendant or semi-user, thief and, finally, drunk driver. Each level of security authorizes the user to access a prescribed set of preferences and preference limits that are associated with that particular security level. As described above, a normal user is granted access to all of the non-critical systems of the vehicle. Therefore, the normal user can then re-set preferences in any one of those non-critical systems or subsystems. A master user, on the other hand, is given access to even more systems, including the more critical systems. A master user can not only set preferences associated with the non-critical systems, but can also set preferences associated with the critical systems.

0096<b>Figure 18</b> illustrates an extremely abbreviated data structure of possible Preferences. Preferences <b>1800</b> data structure includes seat adjustments, temperature adjustments, radio/entertainment system adjustments, telephone number settings, ride preferences, acceleration preferences, warning message preferences and airbag settings fields. In actuality, the number of potential preferences to be set would at least be equal to the number of subsystems being controlled by Onboard Computer <b>20</b> and may include many times more, as each subsystem may have several associated user specific preferences. An administrator, however, may be authorized to do more than set preferences, whether critical or non-critical. An administrator may be authorized to set preference limits for all users of the particular vehicle.

0097<b>Figure 19</b> illustrates Preference Limits <b>1900</b> data structure. In many ways, preference limits would act as system default preferences. Once preference limits are entered in the fields associated with Preference Limits <b>1900</b> data structure, they would be retained in Onboard Computer <b>20</b> Memory <b>22</b> as the system defaults. In this example, preference limits can only be reset by a user having an administrator security level. Therefore, while certain users such as master level users may be able to adjust user specific preference settings within these limits, a master user may not be able to adjust user specific preferences above the preference limits.

0098<b>Figure 20</b> illustrates User Logged Data <b>2000</b> data structure. As briefly discussed above, User Logged Data <b>2000</b> data structure is indexed by user and compiled by Onboard Computer <b>20</b> from events occurring during the user's control of the vehicle. For instance, the first three fields contain routine maintenance and operator log information, hours of engine time, hours logged in and miles traveled. The fourth field concerns the amount of money that was spent by the user. In one embodiment, the SmartCard may have a pre-determined cash value. As the user proceeds along the trip and consumes goods and services needed during that trip, the amount of cash consumed could be automatically logged in this field. Other fields concerning the vehicle's operation include maximum speed attained, the average speed maintained, the average acceleration, maximum engine RPM, data regarding antilock brake engagement, traction control data and data regarding airbag deployment. Other fields that might be useful for an administrator or persons having responsibility for the vehicle, might be the maximum distance from home the vehicle traveled, the maximum distance from a set route the vehicle traveled, the maximum distance tracked from a pre-set destination and a GPS trip tracking field. A GPS trip tracking field would probably be linked to graphic data compiled by Navigation and Tracking system <b>600</b> using Maps and Databases subsystem <b>620</b> and GPS system <b>610.</b> There, an administrator could view a graphic image of the exact routes the vehicle traveled, including time annotations. Finally, a field for services used while a particular user operated the vehicle is provided. This also may be linked to another list tracking such things as the amount of fuel purchased, services rendered to the vehicle such as washings or lube jobs, etc. or towing amounts.

0099<b>Figure 21</b> illustrates an example of how Onboard Computer <b>20</b> authorizes user specific preferences by user security level. In the example in <b>Figure 21,</b> Security Level <b>1700</b> data structure indicates that the user has been identified as a normal user. This is seen as the normal user field being highlighted while the remaining user fields are de-emphasized and presented in italics. When Preferences <b>1800</b> data structure is pulled up for the user authorized as a normal user, certain fields remain active while other fields are de-activated. Active fields for a normal user would include such preferences as seat adjustments, temperature adjustments, radio/entertainment system adjustments, telephone number settings and ride preferences. Preferences not under the control of a normal user might be acceleration, warning message preferences and airbag settings. This is an important concept because, while a user may be allowed to set the user's own specific preferences in every field, Onboard Computer <b>20</b> will only accept those fields which have been authorized under that security level. In the depicted example, a normal user is not authorized to set acceleration preferences, warning message preferences or airbag settings. Therefore, even if a user record contains entries in those fields, Onboard Computer <b>20</b> uses the default settings already available to it in Memory <b>22,</b> which were preset by a system administrator, thereby prohibiting the normal user from inputting the entries in those fields.

0100It is important to note that, while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in a form of a computer readable medium of instructions and a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such as floppy discs, hard disk drives, RAM, CD-ROMs and transmission-type media such as digital and analog communications links.

0101The description of the present invention has been presented for purposes of illustration and description but is not limited to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. This embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular uses contemplated.