US5682428A - Personal access management system - Google Patents

Abstract

A multi-component system for linking a user to a product or service provider includes a user processing device, a storage device, and a provider device. The storage device stores provider-specific application software, user-specific data, and a file management program. The storage device and the processing device are coupled to each other to form a user device which communicates with the provider device. Under direction of the file management program, the processing device carries out a recognition methodology which determines whether the processing device and the storage device are authorized to operate with each other. This aspect of the system makes it possible to render the storage device operable only with a specific user processing device, referred to as the principal processing device. This, in turn, reduces the possibility of fraud since the storage device cannot be used without the principal processing device. Once it is determined that the processing and storage devices are authorized to interact with each other, the processing device executes the provider-specific application software to exchange information with the provider device. Together, the user and provider devices implement unique recognition and comprehension methodologies to ensure that the parties are authorized to communicate with each other and to ensure that the information exchanged cannot be understood by third parties. Overall, the system provides a highly secure mechanism for transferring information from one party to another.

Description

FIELD OF THE INVENTION

This invention relates generally to transactional, communication, and authorization systems, and more particularly to a multi-component system which implements unique recognition and comprehension methodologies to verify party identities and to ensure session security.

BACKGROUND OF THE INVENTION

For a number of years now, tremendous efforts have been devoted to devising systems for linking consumers with product and service providers which would allow the consumers to communicate and to transact with the providers from remote locations, such as from their homes. Such efforts have produced some systems which have received a small degree of acceptance. Examples include home shopping networks (such as QVC), home entertainment systems (such as DirecTV), remote stock transaction systems (such as Reuters), and automatic teller machine (ATM) systems. While these remote systems have gained some acceptance, there still is, for the most part, an absence of a generally and widely accepted system for conducting business from a remote site.

The failure of the presently existing systems can be attributed to a number of different factors. One possible factor is cost, both in terms of the providers' cost and the cost to the consumers. Currently, consumers are typically linked to providers not directly but through aggregators. The presence of an aggregator adds a middleman to the business process which in turn increases the cost to the consumers. High cost is a reason that many consumers hesitate to buy products through an electronic system. The reason that aggregators are necessary is that the linking systems currently used consist of complex, proprietary equipment which are expensive to operate and to maintain. The high cost of such a system presents a formidable barrier to providers who wish to link themselves directly to consumers.

Another possible factor for the failure of the existing systems is the lack of an overall standard system which can be applied generally to a number of different applications. The existing linking systems are, for the most part, application-specific systems. That is, each system is specifically designed to carry out a particular purpose. Typically, proprietary methodologies are implemented and proprietary equipment is used. Application-specific systems are usually effective for their intended purposes; however, they do have a significant practical drawback in that they tend to proliferate the use of a large number of different methods and systems. The problem with the proliferation of a myriad of methods and systems is that they force consumers to buy different equipment for each application, and to learn to use a different system for each application. This makes it very expensive for a consumer to be linked to a large number of providers, and it also imposes a heavy time burden on the consumer. Many consumers are unwilling to invest the money or the time needed to take advantage of the existing proprietary linking systems. A more general system, usable in a variety of different applications, would be more readily accepted.

High cost and the lack of a generally applicable system are factors which have contributed to the failure of the existing linking systems, but probably the most important factor is that of security. Many people inherently distrust machines and, hence, are reluctant to conduct important matters by way of machines in the first place. This distrust is only exacerbated by reports of fraud being perpetrated on electronic systems. In order to be successful, a linking system needs to ensure that user transactions and communications will be secure. This involves both verifying that the proper parties are conducting the transaction, and ensuring that information transferred between the parties cannot be intercepted and used fraudulently by third parties. Thus far, no generally applicable system which is cost effective and convenient to use performs this function satisfactorily. Hence, there exists a need for an improved system for linking users to providers.

SUMMARY OF THE INVENTION

In accordance with the present invention, there is provided a multi-component system, comprising a processing device, a storage device, and a provider device, which implements unique recognition and comprehension methodologies to ensure that transactions conducted from remote locations are secure. In the system of the present invention, the processing device and the storage device couple to each other to form an overall user device, and once formed, this user device establishes a link with the provider device to communicate with a particular provider or a particular group of providers. In the preferred embodiment, the processing device provides the processing and communication capabilities, while the storage device provides the instructions necessary for communicating with a specific provider device. Preferably, the processing device executes the instructions stored on the storage device to communicate with the specific provider. In the system of the present invention, to communicate with another provider, all a user needs to do is to couple another storage device to the same processing device, and to instruct the processing device to execute the provider-specific instructions stored on that new storage device. This aspect of the present invention allows it to be generally applied to a number of different applications involving a number of different providers.

To ensure party recognition, a recognition methodology is preferably implemented both between the processing device and the storage device, and between the user device and the provider device. Consequently, only the proper devices may be coupled together to form a user device, and only a valid user device may communicate with the provider device. To ensure information security, data stored on the storage device is encrypted, and information transferred between the user and provider devices is also encrypted. Thus, even if a storage device is lost, or information sent between the user device and the provider device is intercepted, no comprehensible information can be derived therefrom. As an extra measure of security, the parameters used to effect the recognition and encryption methodologies are preferably dynamically and regularly updated. By so doing, even if a third party is able to fraudulently obtain the parameters needed to "break in" to the system, that information is rendered useful only for a short period of time. Once the parameters are changed, the stolen information is useless. Thus, updating the parameters serves to minimize the damage caused by system breaches. Overall, the system of the present invention provides a highly secure mechanism for linking users to providers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram providing a broad overview of thesystem 10 of the present invention.

FIG. 2a is a detailed block diagram of a first preferred embodiment of the processing device (UAS) 12 of the present invention.

FIG. 2b is a detailed block diagram of an alternative embodiment of theUAS 12 of the present invention.

FIG. 3 is a block diagram of the master EKE 70 which interfaces with theprocessing device 12 to establish certain parameters.

FIG. 4a is an operational flow diagram for the masterEKE control program 72 stored on the master EKE 70.

FIG. 4b is a detailed flow diagram of theinitialization step 804 of FIG. 4a.

FIG. 4c is a detailed flow diagram of theUAS restoration step 860 of FIG. 4a.

FIG. 4d is a detailed flow diagram of the masterEKE restoration step 912 of FIG. 4a.

FIG. 4e is a detailed flow diagram of theDPIN modification step 948 of FIG. 4a.

FIG. 4f is an operational flow diagram for the decryption logic stored insection 62 of thenon-volatile memory 38 of theUAS 12.

FIG. 5a depicts the manner in which the recognition and comprehension parameters (the operational key file names and the corresponding operational key codes) are organized and stored inRAM 40 of theUAS 12.

FIG. 5b depicts the manner in which the recognition and comprehension parameters are organized and stored inRAM 40 of theUAS 12 after aregular EKE 14 has been initialized.

FIG. 6 is a detailed block diagram of the storage device (EKE) 14 of the present invention illustrating theprograms 140, 141, 172 and the data files 148-170 stored on theEKE 14.

FIGS. 7a is an overall operational flow diagram for the UAS-EKE control portion 142 of thePFM 140.

FIG. 7b is a detailed flow diagram of theinitialization step 182 of FIG. 7a.

FIG. 7c is a detailed flow diagram of therecognition methodology step 186 of FIG. 7a.

FIG. 7d is a detailed flow diagram of thefile management step 192 of FIG. 7a.

FIG. 7e is a detailed flow diagram of the recognitionparameter update step 204 of FIG. 7a.

FIG. 7f is a detailed flow diagram of the file managementparameter update step 206 of FIG. 7a.

FIG. 8a shows a file management table 370 which is maintained infile 152 ofEKE 14 for use in coordinating access to the managed files 154-164, 170.

FIG. 8b shows the possible contents of table 370 after theEKE 14 is initialized with file management parameters.

FIG. 8c shows the possible contents of table 370 after the file management parameters have been updated.

FIG. 9a shows the contents of theRAM 40 after thePFM 140 on theEKE 14 has been decrypted.

FIG. 9b shows the contents of theRAM 40 afterstep 192 of FIG. 7a has been performed.

FIG. 10 is a block diagram representation of thePAS 18 of the present invention.

FIG. 11 is an operational flow diagram for a first preferred embodiment of the user device-PASinteraction control portion 144 of thePFM 140.

FIG. 12 is an operational flow diagram for a first preferred embodiment of the recognition andcomprehension control program 408 of thePAS 18.

FIG. 13 is an operational flow diagram for a second preferred embodiment of the user device-PASinteraction control portion 144 of thePFM 140.

FIG. 14 is an operational flow diagram for a second preferred embodiment of the recognition andcomprehension control program 408 of thePAS 18.

FIG. 15 is a block diagram representation of apaging system 1300 having the present invention incorporated therein.

FIG. 16 is a block diagram representation of anelectronic polling system 1320 having the present invention incorporated therein.

FIG. 17 is a block diagram representation of anelectronic banking system 1340 having the present invention incorporated therein.

FIG. 18 is a block diagram representation of anelectronic authorization system 1360 having the present invention incorporated therein.

FIG. 19 is a block diagram representation of anauthorizational system 1370, having the present invention incorporated therein, for controlling the operation of an automobile.

FIG. 20 is a block diagram representation of asystem 1400 wherein aPAS 1402, 1404 having a userdevice emulation module 1406, 1408 incorporated therein, communicates directly with another PAS.

FIG. 21 is a block diagram representation of asystem 1420 wherein auser device 1422, 1424 having aPAS emulation module 1430, 1436 incorporated therein, communicates directly with another user device.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A broad overview of thesystem 10 of the present invention is shown in FIG. 1, wherein thesystem 10 preferably comprises aprocessing device 12, astorage device 14, and aprovider device 18.Storage device 14 preferably couples to processingdevice 12 to form asingle user device 16 which communicates with theprovider device 18 via a communications link. Insystem 10,device 12 provides the processing capability, the communications interface needed to communicate with theprovider device 18, and the user interface necessary for interfacing with a user.Device 12, however, contains a minimum of software instructions. Hence, on its own,device 12 is incapable of communicating or transacting with theprovider device 18. In the preferred embodiment,device 12 is a general purpose processing device capable of carrying out any desired function so long as the proper instructions are provided.

It isstorage device 14 which provides the specific program instructions and data needed by processingdevice 12 to operate and to interact with theprovider device 18.Storage device 14 preferably contains therein: (1) a management program which controls interaction between theprocessing device 12 and thestorage device 14, and interaction between theuser device 16 and theprovider device 18; (2) a provider-specific program which generates the messages (referred to herein as session codes) to be sent to theprovider device 18; and (3) user-specific data which is used and manipulated by the two programs.Processing device 12 preferably accesses and executes the instructions stored on thestorage device 14 once thestorage device 14 is coupled thereto. Insystem 10,storage device 14 may take on a number of different forms including magnetic media (e.g. hard and floppy disks, magnetic stripe cards, etc.), optical media (e.g. CD-ROM), and semiconductor memory (e.g. RAM, PROM, flash memory, etc.). Any form is acceptable so long as it is capable of storing instructions and data, and can interface with theprocessing device 12.

As mentioned above,processing device 12 is a general purpose processing device, and as such, it is capable of interacting with and executing instructions from a number of different storage devices. A practical consequence of this is that the same processing device may be used to communicate with a number of different providers. All the user has to do to communicate with a different provider is to couple adifferent storage device 14 to theprocessing device 12. This aspect of the invention is advantageous because it significantly limits the cost to the user of implementingsystem 10. A user need invest in only one processing device. Thereafter, only the storage devices need to be supplemented, replaced and updated. Since it is contemplated that providers will provide storage devices to users at little or no cost, the cost to the user of communicating directly with a provider will be kept to a minimum. This aspect of the invention makes it much more practicable than most, if not all, of the prior art systems.

Theprovider device 18 ofsystem 10 acts as a gateway between auser device 16 and a particular provider or a particular group of providers. Before auser device 16 can access the services and products of the provider, it must first satisfy the requirements of theprovider device 18.Device 18 preferably implements a recognition methodology to ensure that theuser device 16 is a valid device, and preferably implements a comprehension methodology to decipher messages from the user device into a form that the provider can understand. Once the message is deciphered, theprovider device 18 may process the message itself, or it may relay the message on to a separate provider processing device which actually performs the processing function. Whether the message is processed or relayed bydevice 18 is a matter of design choice.

Whenever business is conducted from a remote location, i.e. in a non face-to-face setting, there is always concern over the possibility of fraud. In a system such assystem 10, there are at least three major concerns: (1) the possibility of loss or theft of thestorage device 14; (2) the possibility that improper parties are communicating; and (3) the possibility that third parties will intercept and use the information transferred betweenuser device 16 andprovider device 18. Thesystem 10 of the present invention addresses and provides a solution to all of these concerns.

With regard to the possibility of loss or theft of thestorage device 14, the management program stored on thestorage device 14 forestalls the use of the lost or stolen device by an improper user. To elaborate, whenstorage device 14 is coupled toprocessing device 12, theprocessing device 12 executes the management program stored on thestorage device 14 to carry out a recognition methodology whereby it is determined whether theprocessing device 12 and thestorage device 14 are authorized to interact with each other. The recognition methodology (described in detail in a later section) is preferably carried out by processing and comparing selected sets of recognition data stored in thestorage device 14 with recognition data stored in theprocessing device 12. Only if the two sets of recognition data are consistent will interaction between thedevices 12, 14 be allowed to continue.

An important point to note here is that when a storage device is used with aprocessing device 12 for the first time, the management program stores customized recognition data in both the storage device and the processing device. This customized recognition data establishes a unique relationship between the storage device and theprocessing device 12 that cannot be established between the storage device and any other processing device (except in the highly unlikely event that another processing device has the same customized recognition data stored therein). As a consequence, once customized recognition data is established between a processing device and a storage device, the storage device is rendered inoperable with any other processing device. Hence, insystem 10, if a user loses thestorage device 14, system security is not compromised because the finder of the storage device cannot use the storage device with his own processing device. This aspect of the present invention greatly enhances system security. At this point, it should be noted that while a storage device establishes a unique relationship with preferably only one processing device, a processing device can establish a unique relationship with more than one storage device. This allows a single processing device to be used with a plurality of different storage devices.

System 10 also serves to ensure that only proper parties are allowed to communicate with each other. The function of party recognition and verification is carded out by both theuser device 16 and theprovider device 18. In communicating with theprovider device 18,processing device 12 executes both the management program and the provider-specific program stored instorage device 14. These two programs cause theprocessing device 12 to: (1) retrieve selected recognition parameters from thestorage device 14 which are unique to thedevice 14; (2) generate session codes to send to theprovider device 18; (3) process the parameters and the session codes; and (4) send the processed parameters and processed session codes to theprovider device 18. In response,provider device 18 processes the information received from theuser device 16 and determines whether the user device is a valid device, i.e. is a recognized device. Access to the provider is granted only if theuser device 16 is a recognized device. In addition to performing the recognition function, theprovider device 18 also preferably coordinates the dynamic and regular alteration of the recognition parameters. Regularly changing the recognition parameters is desirable because it renders any fraudulently obtained information useful for only a short period of time. Insystem 10, the combination of implementing a recognition methodology and dynamically altering the recognition parameters makes it extremely difficult for a non-valid device to gain access to the provider. Thus,system 10 virtually assures that only the proper parties are allowed to communicate with each other.

Furthermore, thesystem 10 of the present invention provides a measure for shielding information transmitted between theuser device 16 and theprovider device 18 from third parties. Whenever information is sent from one device to another, the information is preferably encrypted. In addition, the encryption keys used in the encryption/decryption process are preferably regularly updated. Sending information in this manner makes it virtually impossible for a third party to derive any useful information from the information transmissions. Hence, session security is virtually guaranteed.

As shown by the above discussion, thesystem 10 of the present invention addresses and overcomes the three major security problems typically encountered in communications systems. Overall, a highly secure communications system is provided by the present invention. With this background information in mind, the invention will now be described in detail with reference to specific embodiments. In the following sections,system 10 will be referred to as the personal access management system (PAMS),processing device 12 will be designated as the user access system (UAS),storage device 14 will be referred to as the electronic key executive (EKE), andprovider device 18 will be designated as the provider access system (PAS).

UAS

With reference to FIG. 2a, there is shown a detailed block diagram of a first preferred embodiment of theUAS 12 of the present invention, wherein theUAS 12 preferably comprises a general purpose processor 30 (such as an 80186 microprocessor manufactured by Intel Corporation), astorage device interface 32, acommunications interface 34, auser interface 36, anon-volatile memory 38, and a random access memory (RAM) 40. In the preferred embodiment,UAS 12 takes the form of a hand-held, portable computing device; however, it should be noted that if so desired,UAS 12 may take on various other forms such as a desktop, laptop, or notebook computer, or some other form.UAS 12 is preferably a general purpose processing device. As such, it stores a minimum of its own program instructions. Preferably,processor 30 carries out desired functions by executing program instructions stored on external storage devices.Interface 32 enables theprocessor 30 to execute instructions stored on external devices by receiving one of a number of different storage devices, and coupling the storage device to theprocessor 30.Interface 32 may take on a number of different forms, but in the preferred embodiment,interface 32 is a PCMCIA port for receiving a PCMCIA compatible storage device, such as a PCMCIA memory card.

A major function ofUAS 12 is to allow a user to communicate with a provider from a remote location. Consequently,UAS 12 preferably comprises acommunications interface 34 for forming a communications link with the provider. Preferably,interface 34 comprises a modem 41 (such as a XE1414VS2 interface manufactured by Xecom), and a plurality of communications ports 42-46 coupled thereto. The communications ports preferably includetelephone port 42 for connecting to a universal telephone network, and ananalog 44 and a digital I/O port 46 for communicating by RF, optical, or cable means. These various ports give a user a good degree of flexibility in choosing the type of communications link to form with a provider. Also included ininterface 34 is acomputer port 48.Port 48 allowsUAS 12 to readily link with a standard computer to receive information therefrom and to download information thereto.

UAS 12 also comprises auser interface 36 for communicating with a user.Interface 36 preferably comprises adisplay subsystem 50 for sending information to the user, and akeyboard subsystem 52 for receiving input from the user.

UAS 12 preferably further comprises memory for storing information, including anon-volatile memory 38 for storing information permanently in theUAS 12, and aRAM 40 for temporarily storing current program instructions and associated data. Several sets of instructions and data are preferably stored in thenon-volatile memory 38. First, alldrivers 54 which are needed to operate the components of theUAS 12, such as the display and keyboard drivers, are stored infile 54.

Also, data encryption modules 56 are stored inmemory 38. These modules 56, when executed byprocessor 30, are capable of performing two major functions. First, they encrypt and decrypt data according to a selected algorithm. The encryption algorithms implemented by modules 56 may include DES, SKIPJACK, and various other algorithms. To maintain an open architecture, modules 56 preferably implement encryption algorithms which are industry accepted standards; however, if so desired, modules 56 may implement proprietary algorithms to limit UAS compatibility. A second function performed by modules 56 is that of generating random numbers. As will become clear, this aspect of the modules 56 is very useful in the process of dynamically altering recognition and comprehension parameters. In theUAS 12 shown in FIG. 2a, the encryption/decryption function is performed by havingprocessor 30 execute the encryption modules 56 stored in thenon-volatile memory 38. It should be noted, however, that the encryption/decryption function can be achieved in various other ways. For example, a hardware encryption component (not shown) may be coupled to and called upon by theprocessor 30 to carry out the encryption function. Also, an encryption processor may be incorporated into theprocessor 30 itself to perform the necessary encryption functions. These and other embodiments are within the contemplation of the present invention.

Non-volatile memory 38 furtherstores communications modules 58 for controlling the sending and receiving of information. Whenever information is sent via a communications link, certain protocols need to be observed.Modules 58, when executed byprocessor 30, ensure that outgoing messages are packaged and transmitted using the proper protocol, and that incoming messages are deciphered using the proper protocol.Non-volatile memory 38 further contains asection 60 for storing encrypted recognition and comprehension parameters. When aUAS 12 is new, thissection 60 will not contain any data, but once theUAS 12 is initialized, encrypted recognition and comprehension parameters will be stored insection 60. As will be explained later, the parameters stored insection 60 are manipulated byprocessor 30 in implementing the recognition and comprehension methodologies of the present invention.

Finally,non-volatile memory 38 preferably stores dynamic personal identification number (DPIN) logic anddata 62.Section 62 initially preferably stores a UAS identification code which is unique to theUAS 12, hash code generation logic, and decryption logic. After theUAS 12 is initialized,section 62 will also store a master key code and a master hash code. As will be explained in a later section, the hash code generation logic insection 62 will be executed byprocessor 30 to aid in generating two different key codes given a single DPIN, and the decryption logic insection 62 will be executed byprocessor 30 to render the information insection 60 comprehensible and useful in actual operation. Preferably, both the key generation and the decryption logic insection 62 are executed byprocessor 30 each time theUAS 12 is powered up.

Distributed UAS

Thus far, theUAS 12 has been described as a single dedicated device comprising all of the necessary components. As an alternative embodiment, theUAS 12 may take on a distributed form wherein the components of theUAS 12 are separated into multiple component blocks. An example of such an embodiment is shown in FIG. 2b, wherein theUAS 12 is divided into two component blocks: (1) astandard hardware block 80 comprising the processing, communication, and interfacing components (hardware block 80 may be, for example, a standard personal computer having two PCMCIA ports); and (2) a software block, stored on astorage device 82, comprising the control programs and the data which render theUAS 12 unique. Preferably,storage device 82 takes the form of a PCMCIA compatible memory card. To form theoverall UAS 12, thestorage device 82 is simply coupled to thehardware block 80 via one of the storage device interfaces 86, 88.

In the distributed UAS embodiment shown in FIG. 2b, thehardware block 80 preferably comprises a standard,general purpose processor 84, and a plurality of components coupled thereto. These components include two storage device interfaces 86, 88, acommunications interface 90, auser interface 92, and aRAM 94. Components 84-94 are preferably analogous to the corresponding components 30-36, 40 shown in FIG. 2a. Thus, these components need not be described again here. With regard to thesoftware block 82, a plurality of control programs and data are preferably stored therein. Specifically, block 82 comprisesencryption modules 100,communications module 102, encrypted recognition andcomprehension parameters 104, and DPIN logic anddata 106. Elements 100-106 are analogous to elements 56-62 shown in FIG. 2a; thus, they need not be re-described here.

For the most part, the two embodiments of theUAS 12 are quite similar. One notable difference, though, is the presence of theintegration utility 108 in the distributed embodiment. In the distributed embodiment, one of the issues that needs to be addressed is how to make the twoportions 80, 82 function as a unit. More specifically, there needs to be a mechanism for linking thesoftware block 82 to thehardware block 80 so that theprocessor 84 in thehardware block 80 will know how to access and manipulate the programs and data stored in thesoftware block 82. In the preferred embodiment shown in FIG. 2b, theintegration utility 108 provides this linking mechanism. Preferably, when thestorage device 82 is coupled to thehardware block 80 via theinterface 86, the user directs theprocessor 84 to execute theintegration utility 108 stored on thestorage device 82. Under control ofutility 108,processor 84 will set up certain procedures for accessing the programs and data stored on thestorage device 82. Thereafter, theprocessor 84 will know how and when to access and to execute the elements 100-106 in thesoftware block 82. Thus, the twoseparate blocks 80, 82 are transformed into a single working UAS. The specific structure of theintegration utility 108 will vary depending upon the particular type of hardware block to which thestorage device 82 is to be coupled. Thus, the integration utility is application-specific. Once formed, the distributed UAS 12 (FIG. 2b) will operate in the same manner as the integrated UAS (FIG. 2a). Namely, the distributedUAS 12 will accept a second storage device viainterface 88 and will interact therewith.

The distributed embodiment of theUAS 12 shown in FIG. 2b 2b is quite advantageous in that it is very versatile and convenient to use. As mentioned above, thehardware block 80 which forms a part of the distributedUAS 12 may be a typical personal computer having two PCMCIA ports. This means that any compatible personal computer can be transformed into a UAS by inserting thestorage device 82 into one of the PCMCIA ports. This in turn means that with the distributed embodiment, a user need not carry a UAS with him, but instead may simply carry thestorage device 82. Whenever he needs the use of a UAS, he simply inserts thestorage device 82 into a compatible personal computer and a UAS is thereby created. A drawback of the distributed architecture, though, is that thestorage device 82, because it is smaller, is easier to lose than the dedicated UAS shown in FIG. 2a. Thus, there is a slightly higher risk of a security breach. Which embodiment should be used in any particular application depends on the needs of the application. Both embodiments are effective for their intended purposes.

Initialization of the UAS Using a Master EKE

Regardless of which embodiment is used, aUAS 12 by itself is incapable of communicating with a provider. Only when aUAS 12 is coupled to aproper storage device 14 will anoverall user device 16 be formed which can interact with thePAS 18. Before aUAS 12 can interact with any storage device, however, it first needs to be initialized. Initialization is preferably achieved by way of a master EKE 70 (FIG. 3), which in the preferred embodiment, takes the form of a PCMCIA memory card having a PCMCIA interface (not shown) which interfaces with theUAS 12 through interface 32 (FIG. 2a) or interface 88 (FIG. 2b). Themaster EKE 70 preferably contains a masterEKE control program 72 which is accessed and executed byprocessor 30 to carry out the initialization process. An operational flow diagram for thecontrol program 72 is shown in FIG. 4a. As noted above, the distributed and integrated UAS embodiments (shown in FIGS. 2a and 2b) operate in the same manner. Thus, for the sake of simplicity, the initialization process will be described with reference only to the integrated UAS 12 (FIG. 2a). It should be understood, though, that the distributed UAS 12 (FIG. 2b) may be initialized in the same manner.

Preferably,processor 30 begins the initialization process by accessing and executing thecontrol program 72 on themaster EKE 70. Under control ofprogram 72,processor 30 first determines 800 whether theUAS 12 is new (i.e. uninitialized). Step 800 is preferably carried out by checking a "new" flag stored in theUAS 12. When aUAS 12 is new, as it is in the present instance, this "new" flag should be set. If the UAS "new" flag is set, thenprocessor 30 proceeds to step 802 to determine whether themaster EKE 70 is new. Similar to theUAS 12, a "new" flag is stored on themaster EKE 70, and this flag should be set when themaster EKE 70 is new. If both "new" flags are found to be set, thenprocessor 30 goes on to implement theinitialization process 804 to initialize both theUAS 12 and themaster EKE 70 with data that will be used in the recognition and comprehension processes.

Thestep 804 of initializing theUAS 12 with recognition and comprehension data is shown in greater detail in FIG. 4b. As shown in FIG. 4b,processor 30 starts the data initialization process by prompting 810 the user for a dynamic personal identification number (DPIN) or code. This DPIN may be any desired alpha-numeric which the user wants to use as an identification code. Step 810 is preferably carried out by sending a user prompt to thedisplay subsystem 50 and soliciting a response from the user via thekeyboard subsystem 52. Once a DPIN is received from thekeyboard subsystem 52,processor 30 proceeds to generate 814 a master hash code and a master key code using the DPIN as input. As will be explained later, this master key code is used to encrypt information stored on themaster EKE 70. Preferably,processor 30 generates the master key code in two steps. First,processor 30 executes the hash code generation logic stored insection 62 of thenon-volatile memory 38, using the DPIN as input, to generate a master hash code.Processor 30 preferably generates the master hash code by implementing a hashing algorithm. In the preferred embodiment, the Secure Hash Algorithm (SHA), developed by the National Institute of Standards and Technology, and published as a federal information processing standard (FIPS PUB 180), is used as the hashing algorithm. SHA is described in "SHA: The Secure Hash Algorithm" by Willie Stallings, Dr. Dobb's Journal, April 1994, which is incorporated herein by this reference. A point to note about a hash code is that, given the same input, the same hash code will be generated each and every time. Thus, given the same DPIN, the same master hash code will be generated every time. However, given a certain hash code, the input cannot be derived. This means that an input cannot be "reverse engineered" from a hash code. This feature of a hash code is useful for protecting the identity of the DPIN. Once the master hash code is generated, it is stored insection 62 of thenon-volatile memory 38, as shown in FIG. 2a. As will be explained in a later section, the master hash code is used for user verification purposes.

Once the master hash code is generated and stored, it is used byprocessor 30 to generate the master key code. Preferably,processor 30 generates the master key code by implementing a selected key generation algorithm using the master hash code as input. The key generation algorithm may be any desired algorithm which converts the hash code into a key having a desired length. The specific key generation algorithm used is a matter of design choice. Once the master key code is generated, it is stored insection 62 of thenon-volatile memory 38, and inRAM 40 for subsequent reference. Note that the master key code is not stored on themaster EKE 70. This is to preclude the possibility of another party extracting the master key code from themaster EKE 70 and thereafter decrypting the information on the master EKE using the master key code.

Once the master hash code and the master key code are generated and stored,processor 30 proceeds to step 818 to generate a UAS hash code and a UAS key code. As will be explained later, the UAS key code is used to encrypt information stored insection 60 of thenon-volatile memory 38. The UAS hash code and the UAS key code are generated in much the same manner as the master codes described above except that the UAS identification code stored insection 62 of thenon-volatile memory 38 is used as an additional input factor. More particularly,processor 30 preferably first combines the UAS identification code with the DPIN to derive a modified DPIN. Then,processor 30 executes the hash code generation logic stored insection 62, using the modified DPIN as input, to generate the UAS hash code. Like the master hash code, the UAS hash code is preferably generated by implementing the SHA. Once generated, the UAS hash code is stored in section 74 of themaster EKE 70 for subsequent access.

After the UAS hash code is generated,processor 30 uses it to generate the UAS key code. Preferably, the UAS key code is derived by implementing a selected key generation algorithm (which may be the same key generation algorithm as that used to generate the master key code) to convert the UAS hash code into a UAS key code having a desired length. Again, the specific key generation algorithm used is a matter of design choice. Once the UAS key code is generated, it is stored inRAM 40 for subsequent access. Note that unlike the master key code, the UAS key code is not stored permanently insection 62 of thenon-volatile memory 38, but only in thevolatile RAM 40. Since information stored inRAM 40 is lost each time theUAS 12 is deactivated, the UAS key code will need to be newly generated each time theUAS 12 is turned on. The UAS key code is managed in this manner to prevent an unauthorized party from extracting the UAS key code from thenon-volatile memory 38 and thereafter using the UAS key code to decrypt the recognition and comprehension parameter information stored insection 60 of thenon-volatile memory 38.

After the master key code and the UAS key code are generated, theprocessor 30 is ready to generate the operational key codes and the operational key file names which will be used in the recognition and comprehension processes. Data generation preferably begins with theprocessor 30 determining 822 the manner in which an operational key code will be derived. If the user indicates that he wants to manually input an operational key code, thenprocessor 30 simply receives 830 a multi-bit binary code from the user via thekeyboard subsystem 52. On the other hand, if the user indicates that he wants the operational key code to be automatically generated, thenprocessor 30 executes the encryption modules 56 to randomly generate 826 a multi-bit binary code which is used as the operational key code. In the preferred embodiment, the operational key code is a 512-bit binary code. The number of bits may vary, however, depending upon which encryption algorithm is implemented by the encryption modules 56. The algorithm implemented by modules 56 is a matter of design choice. Whichever method is used, once an operational key code is derived,processor 30 generates 834 an operational key file name to associate with the operational key code. This key file name, which preferably is a variable length alpha having up to ten characters, is generated byprocessor 30 by executing the encryption modules 56. Once the operational key file name is generated,processor 30 creates a file in theRAM 40 of theUAS 12, assigns the file the operational key file name, andstores 838 the operational key code as a record in the file. Thereafter,processor 30 determines 842 whether more key codes need to be derived and stored; if so,processor 30 loops back to step 822 to process another key code. Preferably, steps 822-842 are repeated an n number of times to derive and to store an n number of unique operational key codes. In the preferred embodiment, twenty operational key codes are derived, but it should be noted that any desired number of operational key codes may be derived. At the end of this process 822-842, twenty files will be created and stored in theRAM 40 of theUAS 12. As illustrated in FIG. 5a, each file will have a unique operational key file name, and each file will contain a unique operational key code as a record therein. The operational key codes and their corresponding operational key files names are thus established.

Note that the operational key file names and the operational key codes are thus far stored only in theRAM 40 of theUAS 12. This information will be lost once theUAS 12 is deactivated due to the volatile nature of theRAM 40. In order to preserve the information for future reference, the information is preferably stored insection 60 of thenon-volatile memory 38, and in section 76 of themaster EKE 70. For security reasons, though, it is not desirable to store this information unprotected on either theUAS 12 or themaster EKE 70. Because of this security concern,processor 30, in storing the information onto theUAS 12 and themaster EKE 70, preferably first encrypts the information. Thus, instep 846,processor 30 preferably first encrypts the operational key codes stored inRAM 40 using the UAS key code as the encryption key. Once that is done,processor 30 stores the encrypted data, including the operational key file names and the encrypted operational key codes, intosection 60 of thenon-volatile memory 38. Encrypted recognition and comprehension parameters are thus permanently stored in theUAS 12. Similarly, instep 850,processor 30 first encrypts the operational key codes using the master key code (instead of the UAS key code) as the encryption key. Thereafter,processor 30 stores the operational key file names and the encrypted operational key codes into section 76 of themaster EKE 70. In bothsteps 846 and 850,processor 30 preferably carries out the encryption process by executing the encryption modules 56 innon-volatile memory 38. After the encrypted operational key codes and operational key file names are stored,processor 30 proceeds to encrypt and store 852 the UAS identification code (stored insection 62 of the non-volatile memory 38) into section 74 of themaster EKE 70. Preferably, the UAS identification code is encrypted using the master key code as the encryption key. Afterstep 852, both theUAS 12 and themaster EKE 70 are fully initialized. All that remains is forprocessor 30 to reset 854 the "new" flags in both theUAS 12 and themaster EKE 70 to indicate that the devices are no longer new. Once that is done, initialization is complete.

Restoration and Backup Functions of the Master EKE

Thus far, the masterEKE control program 72 has been described only with regard to the initialization process. It should be noted, though, thatprogram 72 is capable of performing several other important functions. These functions include UAS recovery, master EKE recovery, and DPIN replacement and updating. These functions become important as thesystem 10 is used over a long period of time. To elaborate, in the course of using thesystem 10, it is probably inevitable that a user will at one time or another lose theUAS 12, lose themaster EKE 70, or forget the DPIN. Without an effective recovery mechanism, the loss of one of these components could cause system functionality to be lost. One of the great advantages of thesystem 10 of the present invention is that, given any two of the three components (master EKE, UAS, DPIN), system recovery can be achieved. Hence, the loss of one component will not jeopardize system functionality. With reference to FIGS. 4a, 4c, 4d, and 4e, the other functions of the masterEKE control program 72 will now be described.

UAS Recovery

One of the loss/recovery scenarios that can arise in the system of the present invention is that of a user losing theUAS 12. If the user still has themaster EKE 70, and still remembers the DPIN, anew UAS 12 can be set up to function in the same manner as the lost UAS. To properly configure the new UAS, a user first inserts themaster EKE 70 into theuser interface 32 of the new UAS. Thereafter, theprocessor 30 on thenew UAS 12 accesses and executes thecontrol program 72 on themaster EKE 70 to implement the recovery process. Specifically, theprocessor 30, under control ofprogram 72, determines 800, 802 (FIG. 4a)whether theUAS 12 and themaster EKE 70 are new. In the present scenario, theprocessor 30 will find that theUAS 12 is new but that themaster EKE 70 is not new. Given these conditions,processor 30 will branch to step 860 to implement the UAS restoration process.

Step 860 is shown in greater detail in FIG. 4C. The UAS recovery process begins with theprocessor 30 prompting 862 the user for a DPIN. Once the DPIN is received from the user via thekeyboard subsystem 52, theprocessor 30 uses the DPIN to generate 864 a master key code. Preferably,step 864 is performed by first executing the hash code generation logic stored insection 62 of the new UAS 12 (which preferably causes the SHA previously discussed to be implemented) to generate a master hash code. Then, using the master hash code as input,processor 30 implements a selected key generation algorithm to generate a master key code. Preferably, the key generation algorithm implemented in this process is the same as that previously described in connection withstep 814 of FIG. 4b.

Once generated, the master key code is used byprocessor 30 to verify 866 the accuracy of the DPIN provided by the user. TheDPIN verification process 866 involves four major steps. First,processor 30 uses the generated master key code to decrypt the encrypted UAS ID code stored in section 74 of themaster EKE 70 to derive a decrypted UAS ID code. This step is preferably carried out by executing the encryption modules 56. Thereafter,processor 30 combines the decrypted UAS ID code with the DPIN to derive a modified DPIN. Then, using the modified DPIN as input,processor 30 executes the hash code generation logic insection 62 of thenon-volatile memory 38 to generate a UAS hash code. Finally,processor 30 compares the generated UAS hash code with the UAS hash code already stored on themaster EKE 70 to determine whether they are consistent. If they are not consistent, then it means that an improper DPIN was entered by the user. In such a case,processor 30 terminates operation. On the other hand, ifprocessor 30 determines that the two hash codes are consistent, thereby meaning that the proper DPIN was entered, then UAS restoration is allowed to continue.

If it is determined that the proper DPIN was entered, thenprocessor 30 proceeds to step 870 to decrypt the encrypted recognition and comprehension parameters stored in section 76 of themaster EKE 70. Preferably,processor 30 decrypts the encrypted parameters by executing encryption modules 56, using the master key code as the decryption key. Once decrypted, the operational key codes and key file names are stored 874 in theRAM 40 of thenew UAS 12.

Thereafter,processor 30 proceeds to step 878 to generate a new UAS hash code and a new UAS key code. In generating the new UAS hash code,processor 30 first derives a new modified DPIN by combining the new UAS ID code stored insection 62 of thenew UAS 12 with the DPIN. Once the new modified DPIN is derived,processor 30 generates the new UAS hash code by executing the hash code generation logic stored insection 62 of the new UAS, using the new modified DPIN as input. Once generated, the new UAS hash code is stored in section 74 of themaster EKE 70 replacing the old UAS hash code which is currently residing therein. Then, using the new UAS hash code as input,processor 30 implements a key generation algorithm to generate a new UAS key code. Preferably, the key generation algorithm used in this process is the same as that previously described in connection withstep 818 of FIG. 4b. Note that the new UAS key code will be different from that Used by the lost UAS. This is because the new modified DPIN used to generate the new UAS key code is different (due to the different UAS ID code) from the modified DPIN used to generate the UAS key code used by the lost UAS. This different UAS key code will not prevent the new UAS from achieving identical functionality, however.

Once the new UAS key code is derived, it is stored inRAM 40 of thenew UAS 12 for subsequent reference. It is also used byprocessor 30 to encrypt 882 the operational key codes stored inRAM 40. Preferably,step 882 is carried out by executing the encryption modules 56, using the new UAS key code as the encryption key. After the operational key codes are encrypted,processor 30stores 886 the operational key file names and the encrypted operational key codes (i.e. the encrypted recognition and comprehension parameters) intosection 60 of thenon-volatile memory 38 of thenew UAS 12 for subsequent reference.

To complete the UAS restoration process,processor 30 preferably carries out four more steps. First,processor 30stores 890 the previously generated master hash code and master key code intosection 62 of thenon-volatile memory 38 for subsequent reference. Second,processor 30 encrypts 894 the new UAS identification code stored insection 62 of thenon-volatile memory 38 using the master key code as the encryption key, and thereafter stores the encrypted new UAS ID code into section 74 of themaster EKE 70. Third,processor 30 preferably deletes 898 the encrypted UAS identification code of the lost UAS from section 74 of themaster EKE 70. Finally,processor 30resets 900 the "new" flag on the new UAS to indicate that the UAS has now been initialized. The UAS restoration process is now complete.

Master EKE Recovery

Another loss/recovery scenario which may arise is one in which the user loses themaster EKE 70. If the user still has theUAS 12, and still remembers the DPIN, anew master EKE 70 can be configured to function in the same manner as the lost master EKE. To properly configure a new master EKE, thenew master EKE 70 is inserted intointerface 32 of theUAS 12. Thereafter, theprocessor 30 accesses and executes thecontrol program 72 on the new master EKE. Under control ofprogram 72,processor 30 begins processing by determining 800, 910 (FIG. 4a) whether theUAS 12 and thenew master EKE 70 are new. In this particular instance, theprocessor 30 will find theUAS 12 to be already initialized but themaster EKE 70 to be new.

Given these conditions, theprocessor 30 will branch to step 912 to implement the master EKE restoration process. Step 912 is shown in greater detail in FIG. 4d.

Processor 30 preferably begins therestoration process 912 by prompting 916 the user for a DPIN. When the DPIN from the user is received via thekeyboard subsystem 52,processor 30 uses the DPIN to generate 918 a master hash code.Processor 30 preferably generates the master hash code by executing the hash code generation logic stored insection 62 of thenon-volatile memory 38, using the DPIN as input. Once generated, the master hash code is used to verify 920 the accuracy of the DPIN.Processor 30 preferably carries outstep 920 by comparing the generated master hash code with the master hash code already stored insection 62 of thenon-volatile memory 38. If the two hash codes are inconsistent, then it means that an improper DPIN was entered by the user. In such an instance,processor 30 terminates operation. On the other hand, if the two hash codes are consistent, then the validity of the DPIN is verified and the master EKE restoration process is allowed to continue.

If the proper DPIN was entered, thenprocessor 30 proceeds to step 924 to generate a UAS hash code and a UAS key code. In generating the UAS hash code,processor 30 preferably performs several sub-steps. First,processor 30 combines the UAS identification code stored insection 62 of thenon-volatile memory 38 with the DPIN to derive a modified DPIN. Then,processor 30 uses the modified DPIN to generate the UAS hash code. Preferably, the UAS hash code is generated by executing the hash code generation logic stored insection 62, using the modified DPIN as input. Once generated, the UAS hash code is preferably stored in section 74 of thenew master EKE 70. Thereafter,processor 30 generates the UAS key code by implementing the key generation algorithm described above in connection withstep 818 of FIG. 4b, using the generated UAS hash code as input. Once the UAS key code is derived, it is stored inRAM 40. Thereafter,processor 30 uses the UAS key code to decrypt 928 the encrypted recognition and comprehension parameters stored insection 60 of thenon-volatile memory 38. Step 928 is preferably carried out by executing modules 56. The operational key codes are thus decrypted and derived. Once decrypted, the operational key codes and the operational key file names are stored inRAM 40.

Afterstep 928,processor 30 prepares to store the recognition and comprehension parameters onto thenew master EKE 70. Before storing the parameters, though,processor 30 preferablyfirst reencrypts 932 the recognition and comprehension parameters (i.e. the operational key file names and operational key codes) stored in theRAM 40 using a master key code as the encryption key. The master key code may be retrieved fromsection 62 of the non-volatile memory or, if so desired, may be newly generated using the DPIN. In addition,processor 30 also preferably encrypts the UAS identification code stored insection 62 of thenon-volatile memory 38 using the master key code as the encryption key. Oncestep 932 is carried out,processor 30stores 936 the encrypted recognition and comprehension parameters into section 76 of thenew master EKE 70, and the encrypted UAS identification code into section 74 of thenew master EKE 70. Thenew master EKE 70 is now configured to function in the same manner as the lost master EKE. All that remains for theprocessor 30 to do is to reset 940 the "new" flag on themaster EKE 70 to indicate that the master EKE is no longer uninitialized. Once that is done, the master EKE restoration process is complete.

DPIN Modification/Recovery

One other loss/recovery scenario to be considered is the one in which the user forgets the DPIN used to generate the master and UAS key codes. As made clear by the above discussions, the DPIN plays a vital role in the proper encryption and decryption of the recognition and comprehension parameters. To recover from the loss of the DPIN, the user will need to have both theoriginal UAS 12 and theoriginal master EKE 70. The user initiates the recovery process by inserting themaster EKE 70 intointerface 32 of theUAS 12. Thereafter, theprocessor 30 accesses and executes thecontrol program 72 on themaster EKE 70 to implement the recovery process. As shown in FIG. 4a,processor 30, under control ofprogram 72, begins operation by determining 800, 910 whether theUAS 12 and themaster EKE 70 are new. In this particular instance, neither component is new; hence,processor 30 will proceed to step 942.

Instep 942,processor 30 implements a recognition methodology to determine whether theUAS 12 and themaster EKE 70 are authorized to interact with each other at all. Preferably,processor 30 carries outstep 942 by first retrieving the master key code previously stored insection 62 of thenon-volatile memory 38. Thereafter,processor 30 uses the master key code to decrypt the encrypted UAS identification code stored in section 74 of themaster EKE 70. Once decrypted, the UAS identification code from themaster EKE 70 is compared with the UAS identification code stored insection 62 of thenon-volatile memory 38. If the two codes are not consistent, then the twocomponents 12, 70 are not authorized to interact with each other. Hence, communication therebetween is terminated. On the other hand, if the two codes are consistent, then authorization is verified, and theprocessor 30 is allowed to proceed to step 946.

It is insteps 946 and 948 that the user is allowed to override the current DPIN and to establish a new DPIN. Specifically, instep 946,processor 30 queries the user as to whether the user wishes to set a new DPIN. If so, thenprocessor 30 implements theDPIN modification process 948. Step 948 is shown in greater detail in FIG. 4e, wherein the first step in the DPIN modification process is to retrieve 980 the master key code previously stored insection 62 of thenon-volatile memory 38. Once retrieved, this master key code is used by theprocessor 30 to decrypt 982 the encrypted recognition and comprehension parameters stored in section 76 of themaster EKE 70. The recognition and comprehension parameters (i.e. the operational key codes and operational key file names) are thus derived. Once derived, the parameters are stored 984 inRAM 40 for subsequent reference.

Thereafter,processor 30prompts 986 the user for a new DPIN with which to replace the forgotten DPIN. Upon receiving the new DPIN via thekeyboard subsystem 52,processor 30 proceeds to generate 988 a new master key code. Preferably,processor 30 generates the new master key code in two steps. First,processor 30 executes the hash code generation logic stored insection 62 of thenon-volatile memory 38, using the new DPIN as input, to generate a new master hash code. This new master hash code is stored insection 62 of thenon-volatile memory 38, preferably replacing the master hash code currently stored therein. Then, using the new master hash code as input,processor 30 implements a key generation algorithm to generate a new master key code having a desired length. Preferably, the key generation algorithm implemented here is the same as that previously described in connection withstep 814 of FIG. 4b. Once generated, the new master key code is preferably stored both insection 62 of thenon-volatile memory 38 and inRAM 40. Thereafter, the new master key code is used by theprocessor 30 to encrypt 990 both the parameters stored in theRAM 40 and the UAS identification code stored insection 62 of thenon-volatile memory 38. Once that is done,processor 30stores 992 the encrypted recognition and comprehension parameters into section 76 of themaster EKE 70, and the encrypted UAS identification code into section 74 of themaster EKE 70. Preferably, once this new encrypted information is stored in sections 74 and 76, the information previously stored in these same sections is deleted.Master EKE 70 is thus updated.

A similar process is performed byprocessor 30 to update theUAS 12. Specifically,processor 30 begins the UAS updating process by generating 994 a new UAS hash code and a new UAS key code. Preferably,processor 30 generates the new UAS hash code by combining the UAS identification code stored insection 62 with the new DPIN to derive a modified DPIN. Then, using the modified DPIN as input,processor 30 executes the hash code generation logic stored insection 62 of thenon-volatile memory 38 to generate the new UAS hash code. Once generated, the new UAS hash code is stored in section 74 of themaster EKE 70, preferably replacing the UAS hash code previously stored therein. Thereafter,processor 30 uses the new UAS hash code to generate the new UAS key code. Preferably,processor 30 generates the new UAS key code by implementing a key generation algorithm, using the new UAS hash code as input. The key generation algorithm implemented here is preferably the same as that previously described in connection withstep 818 of FIG. 4b. Once the new UAS key code is generated, it is stored inRAM 40 and is used as an encryption key byprocessor 30 to encrypt 996 the recognition and comprehension parameters stored in theRAM 40. Once that is performed,processor 30stores 998 the encrypted recognition and comprehension parameters intosection 60 of thenon-volatile memory 38 for future reference. As an additional step,processor 30 preferably deletes the encrypted parameters previously stored insection 60. Afterstep 998 is performed, the DPIN modification process is complete. As shown by this discussion, the system of the present invention is quite robust in that it can recover from the loss of any one of these three components: UAS, master EKE, and DPIN.

Other Functions of the Master EKE

Thus far, the masterEKE control program 72 has been described as being used only in the initialization and recovery processes. However, as shown in FIG. 4a,control program 72 is also capable of performing several other functions. One such function is that of override. More specifically, steps 954 and 956 may be implemented (if a user so wishes) to change the recognition and comprehension parameters currently stored in theUAS 12 and the master EKE. New operational key codes and operational key file names may be generated in much the same manner as that described in conjunction with FIG. 4b. Hence, step 956 need not be described in detail here.

Another additional function performed by the masterEKE control program 72 is that of data backup. Note that the recognition and comprehension parameters are encrypted and stored not only in theUAS 12 but also in themaster EKE 70. This extra storing procedure is performed to ensure that, if the information stored inUAS 12 is somehow lost or erased, the information can be restored by consulting themaster EKE 70. Steps 950-952 of FIG. 4a deal with this backup aspect of the masterEKE control program 72. Wheneverprogram 72 is executed byprocessor 30, the user is given anoption 950 to restore information into theUAS 12. If the user chooses this option, thenprocessor 30 preferably performsstep 952, which involves a series of sub-steps. In carrying outstep 952,processor 30 first uses the master key code stored insection 62 of theUAS 12 to decrypt the encrypted parameter information stored in section 76 of themaster EKE 72. The parameters, thus decrypted, are stored inRAM 40. Then,processor 30 prompts the user for a DPIN. Upon receiving the DPIN, theprocessor 30 generates a master hash code in the manner described above. Once generated, this master hash code is used to verify the validity of the entered DPIN. More specifically, the generated master hash code is compared with the master hash code stored insection 62 of thenon-volatile memory 38. If the two hash codes are consistent, then it is verified that the entered DPIN is accurate. After the DPIN is verified,processor 30 generates a UAS key code. This is preferably achieved by first generating a UAS hash code, and then using the UAS hash code to generate the UAS key code, in the manner described above. Once generated, the UAS key code is used as an encryption key to encrypt the parameters stored inRAM 40. Once that is done,processor 30 stores the encrypted parameters intosection 60 of thenon-volatile memory 38. Data restoration is thus achieved.

One further point should be noted regarding the data backup aspect of thecontrol program 72. In normal use, theUAS 12 is operated without themaster EKE 70. Also, in normal operation, the recognition and comprehension parameters stored insection 60 of thenon-volatile memory 38 of theUAS 12 can be updated. Thus, at times,section 60 of thenon-volatile memory 38 will contain fresh or updated information that is not stored on themaster EKE 70. Preferably,processor 30 sets a "new data" flag whenever any new or modified data is stored insection 60, and whenever existing data is deleted fromsection 60. That way, whenever themaster EKE 70 is inserted and the masterEKE control program 72 is executed, theprocessor 30 can check 958 for the "new data" flag, and if the flag is set, thenprocessor 30 can store 960 the updated data fromsection 60 into themaster EKE 70. Preferably,processor 30 performsstep 960 by first generating a UAS key code in the manner described above. Then, the UAS key code is used to decrypt all of the encrypted parameters stored insection 60 of thenon-volatile memory 38. Once that is done, the decrypted recognition and comprehension parameters are stored inRAM 40. Thereafter,processor 30 uses the master key code stored insection 62 of thenon-volatile memory 38 to encrypt the decrypted parameters in theRAM 40. Then,processor 30 stores the newly encrypted recognition and comprehension parameters into section 76 of themaster EKE 70, preferably replacing the parameters previously stored therein. Themaster EKE 70 is thus updated. Once the new data is backed up onto themaster EKE 70,processor 30 resets the "new. data" flag. By updating themaster EKE 70 in this manner, the masterEKE control program 72 optimizes the master EKE's ability to function effectively as a backup device.

UAS Start-up

OnceUAS 12 is initialized as described above, themaster EKE 70 is decoupled from thestorage device interface 32 of theUAS 12. TheUAS 12 is thereafter able to receive aregular EKE 14 throughinterface 32. Recall that when theUAS 12 was initialized, the recognition and comprehension parameters were stored insection 60 of thenon-volatile memory 30 in encrypted form. Before these parameters can be used in actual operation, they first need to be decrypted. This decryption function is preferably performed by theprocessor 30 under control of the decryption logic stored insection 62 of thenon-volatile memory 38 each time the UAS is powered up. A flow diagram for this decryption logic is shown in FIG. 4f. With reference to FIG. 4f,processor 30 begins the decryption process by prompting 1000 the user to enter a DPIN. Once the DPIN is received via thekeyboard subsystem 52,processor 30 uses the DPIN to generate 1002 a master hash code. Preferably,processor 30 generates the master hash code by executing the hash code generation logic stored insection 62 of thenon-volatile memory 38, using the DPIN as input. Once generated, the master hash code is compared 1004 with the master hash code stored insection 62 of thenon-volatile memory 38. If the two hash codes are inconsistent, then it means that an improper DPIN was entered by the user. In such a case,processor 30 terminates operation to prevent an unauthorized user from using theUAS 12. On the other hand, if the two hash codes are consistent, thenprocessor 30 proceeds to step 1008.

Instep 1008,processor 30 uses the DPIN to generate a UAS key code. More specifically,processor 30 preferably first combines the UAS ID code stored insection 62 of thenon-volatile memory 38 with the DPIN to derive a modified DPIN. Then, using the modified DPIN as input,processor 30 executes the hash code generation logic stored insection 62 to generate a UAS hash code. Once generated, the UAS hash code is used byprocessor 30 to generate a UAS key code. More specifically,processor 30 implements a key generation algorithm (preferably the same as that discussed above with regard to step 818 of FIG. 4b) using the UAS hash code as input to generate a UAS key code having a desired length. Once generated, the UAS key code is stored 1010 inRAM 40 for subsequent reference. Thereafter,processor 30 uses the UAS key code as a decryption key to decrypt 1012 the recognition and comprehension parameters stored insection 60 of thenon-volatile memory 38. Preferably,processor 30 carries outstep 1012 by executing the encryption modules 56. Once decrypted, the recognition and comprehension parameters (i.e. the operational key file names and operational key codes) are stored 1014 in theRAM 40 of theUAS 12. The parameters are now in a form which can be used in normal operation. Thus, theUAS 12 is now ready for operation with aregular EKE 14. One additional point to note is that because the decrypted parameters and the UAS key code are stored in thevolatile RAM 40 of theUAS 12, this information will be lost when theUAS 12 is deactivated. This means that the decrypted parameters and the UAS key code will need to be newly generated the next time theUAS 12 is used. Hence,processor 30 preferably executes the decryption logic stored insection 62 of thenon-volatile memory 38 each time theUAS 12 is powered up.

Thus far, the process (shown in FIG. 4f) of verifying the accuracy of the DPIN and of decrypting the recognition and comprehension parameters has been described as being implemented byprocessor 30 under control of the decryption logic insection 62 of thenon-volatile memory 38. It should be noted, however, that the process shown in FIG. 4f may also be implemented by way of a hardwired circuit. The design of such a circuit, given FIG. 4f, is within the skill of one of ordinary skill in the art. Such an implementation is within the contemplation of the present invention.

EKE

Once theUAS 12 is powered up, and the recognition and comprehension parameters are decrypted and stored inRAM 40, theUAS 12 is ready to interact with a regular EKE. With reference to FIG. 6, there is shown a detailed block diagram of anEKE 14 of the present invention. In thepreferred embodiment EKE 14 takes the form of a PCMCIA memory card having a PCMCIA interface (not shown) for coupling to interface 32 of theUAS 12. As shown in FIG. 6,EKE 14 preferably stores a plurality of data files 148-170, and at least two control programs: (1) the PAMS file manager (PFM) 140; and (2) the provider-specific software 141. Optionally,EKE 14 may store a third control program 172 (the encryption modules) which may be executed to perform encryption/decryption functions.

OnEKE 14, thePFM 140 is the main program which is accessed and executed byprocessor 30 to coordinate interaction among all of thecomponents 12, 14, 16, 18 of thesystem 10.PFM 140 preferably comprises a UAS-EKEinteraction control portion 142 for controlling interaction between theUAS 12 and theEKE 14, and a user device-PAS control portion 144 for coordinating interaction between a user device (formed byUAS 12 and EKE 14) and thePAS 18.Control portion 142 is the portion which is accessed and executed first byprocessor 30.

When executed,control portion 142 preferably causesprocessor 30 to perform a number of different functions. First,portion 142 causesprocessor 30 to implement a recognition methodology to verify thatUAS 12 andEKE 14 are authorized to interact with each other. If interaction is not authorized, thenportion 142 terminates communication with theUAS 12. This verification function is important because it renders anEKE 14 usable with only one particular UAS 12 (referred to herein as the "principal UAS"). This means that if theEKE 14 is lost or stolen, system security is not compromised because the holder of the lost or stolenEKE 14 will not be able to use the EKE with hisown UAS 12. Thus,control portion 142 greatly enhances system security. Second,portion 142 causesprocessor 30 to strictly coordinate access to the other resources stored on theEKE 14, such as the managed files 154-164, 170. This adds an extra layer of protection, just in case a user is somehow able to obtain authorization fraudulently. Third,portion 142 causesprocessor 30 to coordinate the encryption and decryption of data stored in the files 154-164, 170. This encryption or comprehension function ensures that even if theEKE 14 is lost, no comprehensible information can be extracted therefrom. Fourth,portion 142 causesprocessor 30 to coordinate the dynamic alteration and update of the parameters used in the above three functions. By dynamically and regularly changing these parameters,portion 142 makes it virtually impossible for anyone to ascertain, at any particular time, what parameters are being used. This in turn makes it extremely difficult to "break in" to thesystem 10. Therefore,portion 142 ofPFM 140 ensures the security of theEKE 14.

PFM 140 also preferably comprises a user device-PASinteraction control portion 144 for coordinating interaction between theuser device 16 and thePAS 18.Control portion 144, when executed byprocessor 30, preferably causes theprocessor 30 to properly coordinate the exchange of information with thePAS 18. In performing this coordination function,portion 144 preferably causes theuser device 16 to implement the unique recognition and comprehension methodologies of the present invention, in conjunction with theprovider device 18, to verify party identities and to ensure session security. By so doing,portion 144 ensures that only proper devices will be allowed to communicate with each other, and that information transferred between theuser device 16 and thePAS 18 will be secure from third parties. Together,portions 142 and 144 coordinate the overall secure operation of the UAS-EKE assembly.

The provider-specific software 141 on theEKE 14 provides the program instructions necessary for communicating with a particular provider or a particular group of providers.Program 141 preferably includes anapplication portion 145 for generating the messages or session codes which are sent to thePAS 18, and acommunications portion 146 for organizing the information sent to thePAS 18 in a manner expected by thePAS 18. Theseprogram portions 145, 146 are executed under the direction ofportion 144 of thePFM 140. As the name suggests, provider-specific software 141 is preferably tailored to communicate with one or a group of specific providers. Consequently, theapplication 145 and thecommunications 146 portions can and probably will be customized for each provider, which means thatsoftware 141 will vary from EKE to EKE. In contrast, thePFM 140, because it is not necessarily provider-specific, may be identical for all EKE's. In the preferred embodiment shown in FIG. 6, there is only one provider-specific program 141 stored on theEKE 14. However, if so desired, anEKE 14 may store more than one provider-specific program to allow a user to communicate with a plurality of providers using only oneEKE 14. Such a modification is within the scope of the present invention.

The data files, also referred to herein as storage units, 148-170 on theEKE 14 contain user-specific (i.e. EKE-specific) data which are manipulated byPFM 140 in carrying out its recognition and comprehension methodologies. More specifically,PFM 140 uses the information in these data files 148-170 to determine whether theUAS 12 and theEKE 14 are authorized to interact, to manage access and updates to files on theEKE 14, and to communicate with thePAS 18. Some of the information in the data files or storage units will be provided by the provider, while some of the information will be generated by thePFM 140. More will be said about data files 148-170 in later sections as the operation of theUAS 12, theEKE 14, and thePAS 18 is described.

Protection of the Information on the EKE

In the preferred embodiment, theEKE 14 is a portable, compact memory card. As such, theEKE 14 is quite easy to lose. To prevent a third party from being able to extract useful information from a lostEKE 14, selected files and programs on theEKE 14 are preferably stored encrypted at all times. Portions of theEKE 14 which are encrypted include: (1) PFM 140 (except unencrypted portion 143); (2) managed files 152-164; and (3) a portion offile 170. Due to the nature in which some of the files are used, some of the files on the EKE 14 (e.g. files 148, 150, 167, 168) are left unencrypted. In the preferred embodiment, the provider-specific software 141 is left unencrypted; however, if so desired,software 141 may also be stored onEKE 14 in encrypted form.

ThePFM 140 is stored onEKE 14 in encrypted form in order to prevent an unauthorized party from tampering with, and thereby altering, the program instructions. Note, however, that not all of thePFM 140 is stored in encrypted form. A relativelysmall portion 143 of the UAS-EKE control portion 142 is left unencrypted to allow theprocessor 30 to initially interface with theEKE 14. The instructions inportion 143 are analogous to boot-up code. To elaborate, whenEKE 14 is coupled to interface 32 of theUAS 12, theprocessor 30 first accesses and executes theunencrypted portion 143 of UAS-EKE control portion 142. Under control ofportion 143,processor 30 performs checks to determine whether to proceed further. If certain requirements are met, thenprocessor 30 is allowed to decrypt the remainder ofportion 142 and the entirety ofportion 144, and to store the decrypted instructions into theRAM 40 of theUAS 12. Thereafter,processor 30 is allowed to execute the decrypted PFM instructions stored in theRAM 40 to carry out the functions dictated by thePFM 140. By managing thePFM 140 in this manner, it is possible to both protect the integrity of the PFM (by encryption) and to provide a convenient interface between theUAS 12 and theEKE 14. With this background information in mind, interaction between theUAS 12 and theEKE 14 will now be described in greater detail.

UAS-EKE Interaction

Anoverall user device 16 is formed by coupling theEKE 14 to theUAS 12 via thestorage device interface 32. Once coupled, theprocessor 30 on theUAS 12 accesses and executes thePFM 140 stored on theEKE 14. More specifically,processor 30 first accesses and executes theunencrypted portion 143 of the UAS-EKEinteraction control portion 142. Under control ofportion 143,processor 30 begins the process of controlling interaction between theUAS 12 and theEKE 14. To describeportions 143 and 142 in greater detail, reference will now be made to FIGS. 7a-7f. FIG. 7a provides an overall operational flow diagram forportion 142, including those parts which pertain to theunencrypted portion 143, while FIGS. 7b-7f provide more detailed flow diagrams for selected aspects ofportion 142.

Referring now to FIG. 7a, the portions of FIG. 7a which pertain to theunencrypted portion 143 include: (1) processes 174-180; (2) processes 184-190; (3) processes 216-224; and (4) processes 225-227. In other words,unencrypted portion 143 comprises the instructions necessary for carrying out processes 174-180, 184-190, 216-224, and 225-227. The remaining processes 191-214 shown in FIG. 7a pertain to the remainder of the UAS-EKEinteraction control portion 142. The instructions necessary for implementing these remaining processes 191-214 are preferably stored on theEKE 14 in encrypted form.

As mentioned above, whenEKE 14 is interfaced withUAS 12,processor 30 accesses and executes the unencrypted instructions stored inportion 143. Under control ofportion 143,processor 30 begins operation by determining 174 whetherencryption modules 172 are stored on theEKE 14. If not, thenprocessor 30 proceeds to step 177. However, ifencryption modules 172 are found on theEKE 14, thenprocessor 30loads 175 theencryption modules 172 into theRAM 40, and sets 176 an "override" flag. If the "override" flag is set, then all subsequent encryption/decryption functions will be carried out by executing the encryption modules stored inRAM 40 instead of executing the encryption modules 56 stored in theUAS 12. This feature of the invention allows a provider to dictate, by storingmodules 172 on theEKE 14, the particular encryption algorithm to be used. This is a very useful feature, especially if the encryption modules 56 stored in theUAS 12 become obsolete. For the sake of simplicity, though, it will be assumed for the purposes of description thatEKE 14 does not contain a set of overridingencryption modules 172. Thus, the invention will be described hereinafter with reference to the encryption modules 56 in theUAS 12.

Initialization of a New EKE

After determining whether to load encryption modules into theRAM 40,processor 30 goes on to step 177, wherein it is determined whether theEKE 14 is new, i.e. uninitialized. Preferably this determination is made by looking for an operational key file name infile 148 of theEKE 14. If no operational key file name is stored infile 148, then theEKE 14 has not yet been used. IfEKE 14 is new, thenprocessor 30 proceeds to step 178 to begin implementing an initial decrypting process. To elaborate, when a user first receives anEKE 14, thePFM 140 and the data files 152-164 on theEKE 14 are incomprehensible because they are stored in encrypted form. The key needed to decrypt these files is known only to the provider. This is done in order to protect the information on theEKE 14 from unauthorized third parties during possible transport. When the provider gives thenew EKE 14 to the user, the provider also preferably gives the user the key (referred to hereinafter as the "initial key code") used to encrypt the PFM and the data files. For security reasons, separate means are preferably used to convey theEKE 14 and the initial key code to the user so that a third party cannot link the key to theEKE 14. Armed with the initial key code, the user can access the resources on theEKE 14.

Referring again to FIG. 7a, once it has been determined that theEKE 14 is new,processor 30prompts 178 the user to provide the initial key code used to encrypt thePFM 140 and the data files 152-164 on thenew EKE 14. Once this key code is received from the user via thekeyboard subsystem 52,processor 30 uses the key code to decrypt 179 the encrypted portions of thePFM 140, including the encrypted portion of the UAS-EKE control portion 142, and the user device-PAS control portion 144. Preferably,step 179 is carried out by executing encryption modules 56. After thePFM 140 is decrypted, it is stored 180 in its entirety (including the unencrypted portion 143) inRAM 40. FIG. 9a shows the contents ofRAM 40 after this decryption process. As shown,RAM 40 now contains anunencrypted version 1140 of thePFM 140 stored on theEKE 14. Theunencrypted PFM 1140 preferably comprises an unencrypted UAS-EKEinteraction control portion 1142 which corresponds toportions 143 and 142 on theEKE 14, and an unencrypted user device-PASinteraction control portion 1144 which corresponds toportion 144 on theEKE 14. In addition,RAM 40 also contains a UAS key code and a decryptedversion 1160 of the recognition and comprehension parameters stored insection 60 of thenon-volatile memory 38. Theseparameters 1160 were stored in theRAM 40 upon power-up of theUAS 12.

Before going further, it should be noted here that thePFM 140 on theEKE 14 is not altered by this decryption process. ThePFM 140 is still stored onEKE 14 in encrypted form. The only unencrypted version of thePFM 140 is in theRAM 40. ThePFM 140 on theEKE 14 remains encrypted so that there is never a time at which thePFM 140 is left unprotected.

Once thePFM 140 is decrypted and stored inRAM 40,processor 30 begins executing theunencrypted PFM instructions 1140 stored in theRAM 40. At this point,processor 30 is still controlling interaction between theUAS 12 and theEKE 14. Thus,processor 30 continues operation by executing the unencrypted instructions inportion 1142. Under control ofportion 1142,processor 30 proceeds to step 182 to establish a unique relationship between theUAS 12 and theEKE 14. In other words,processor 30 proceeds to initialize thenew EKE 14. As an overview, the initialization process has two major objectives. First, the process stores customized recognition data in both theUAS 12 and theEKE 14 to establish a unique relationship between the two components. This serves to render theEKE 14 inoperable with anyother UAS 12. Second, the initialization process establishes file management parameters which are used later to coordinate access to the managed files 154-164, 170.

The initialization process is shown in greater detail in FIG. 7b. Preferably,processor 30 begins the process by selecting 230 one of the operational key file names stored in section 1160 (FIG. 9a) of theRAM 40. Once selected, the operational key file name is stored 232 infile 148 of theEKE 14. Then, using the selected operational key file name,processor 30retrieves 234 the operational key code corresponding to the selected operational key file name. For example, with reference to FIG. 5a (which shows the operational key file names and the operational key codes currently stored in RAM 40), if operational key file name₁ is selected, then operational key code₁ is retrieved fromRAM 40. Thereafter,processor 30retrieves 235 the EKE identification code fromfile 150 of theEKE 14, and processes 236 the EKE identification code using the retrieved operational key code. Preferably, the step of processing 236 the EKE identification code entails the encryption of the EKE identification code. This encryption step is preferably carried out by executing the encryption modules 56 stored in theUAS 12, using the operational key code as the encryption key. Consequently, the product ofstep 236 is an encrypted EKE identification code. Once derived, the encrypted EKE identification code is stored 237 insection 1160 of theRAM 40. Preferably, the encrypted EKE identification code, otherwise referred to as the EKE reference code, is stored as a record under the selected operational key file name. That is, as shown in FIG. 5b, if operational key file name₁ is the selected key file name, then the EKE reference code is stored as a record under operational key file name₁.

By storing the EKE reference code as a record under the selected operational key file name,processor 30 has updated the recognition and comprehension parameters stored insection 1160 of theRAM 40. This change needs to be reflected insection 60 of thenon-volatile memory 38. To updatesection 60,processor 30 preferably first encrypts 238 the parameters stored insection 1160 of theRAM 40 using the UAS key code as the encryption key to derive a new set of encrypted recognition and comprehension parameters. Then, the new encrypted parameters are stored 239 insection 60 of thenon-volatile memory 38, preferably replacing the parameters previously stored therein.Section 60 is thus updated. Sincesection 60 now contains new information,processor 30 preferably sets 240 the "new data" flag to indicate to the master EKE control program 70 (when it is next executed by processor 30) thatsection 60 now contains new data which should be copied into themaster EKE 70 for backup purposes. By carrying out steps 230-240,processor 30 establishes customized recognition data between theUAS 12 and theEKE 14 which may be used later to verify that thecomponents 12, 14 are authorized to interact with each other. In short, the customized recognition data serves to establish a unique relationship between theUAS 12 and theEKE 14.

Thus far, the customized recognition data establishment process has been described as comprising a processing step. That is, the EKE identification code has been described as being processed (encrypted) before being stored under the appropriate operational key file name in theRAM 40. As an alternative, it is possible to establish customized recognition data between theUAS 12 and theEKE 14 without the processing step. More particularly, the establishment process may be carried out as follows. First, one of the operational key file names stored in theRAM 40 is selected. This file name is preferably stored infile 148 of theEKE 14. Then, the EKE identification code stored infile 150 is stored, without encryption, into the file corresponding to the chosen operational key file name. Since the EKE identification code is preferably unique to theEKE 14, customized recognition data is established between theUAS 12 and theEKE 14 by this process. The process just described is less secure than the establishment process previously described but it is a possible alternative.

Encryption of the PFM Stored in RAM

To further cement the unique relationship between theUAS 12 and theEKE 14, a link is preferably formed between thePFM 140 stored on theEKE 14 and theUAS 12. To elaborate, thePFM 140 on theEKE 14 is currently encrypted using the initial key code provided by the provider, as previously explained. This key code is just an arbitrary key code chosen by the provider. There is no link between the initial key code and theUAS 12. To provide this link, thePFM 140 on theEKE 14 is preferably encrypted using one of the operational key codes specific to theUAS 12. In the preferred embodiment, the operational key code used to encrypt thePFM 140 is preferably the same as that used to encrypt the EKE identification code, as discussed in the two previous paragraphs. It should be noted, however, that any of the operational key codes specific to theUAS 12 may be used for this purpose. With this background information in mind, the PFM encryption process will now be described.

Referring again to FIG. 7b,processor 30 begins theencryption process 242 by retrieving a selected operational key code fromRAM 40. In the example used above, operational key code₁ was used to encrypt the EKE identification code. Thus, to continue the example, operational key code₁ is retrieved here fromsection 1160 of theRAM 40. Once retrieved, operational key code₁ is used byprocessor 30 as the encryption key to encrypt 242 theunencrypted PFM instructions 1140 currently stored in theRAM 40. Preferably, processor encrypts all of thePFM instructions 1140 stored in theRAM 40 except for those instructions (unencrypted portion 143) pertaining to processes 174-180, 184-190, 216-224, and 225-227 of FIG. 7a, which are left unencrypted. The product ofstep 242 is a new encrypted PFM. Once the new encrypted PFM is derived,processor 30stores 243 the newencrypted PFM 140 onto theEKE 14, preferably replacing the encrypted PFM currently stored thereon. Like the old encrypted PFM, the new encrypted PFM will have anunencrypted portion 143 which is capable of carrying out processes 174-180, 184-190, 216-224, and 225-227 of FIG. 7a. Unlike the old encrypted PFM, however, the new encrypted PFM is encrypted using one of the operational key codes specific to theUAS 12. Because of this, there now exists a unique link between the new encrypted PFM and theUAS 12. Unless another UAS has the same operational key code stored under the same operational key file name (the probability of which is negligible), no other UAS will be able to decrypt or execute the new encrypted PFM. Thus, even if theEKE 14 is now lost or stolen, thePFM 140 on theEKE 14 is safe from tampering.

At this point, it should be noted that the PFM encryption process described above does not alter thePFM instructions 1140 stored in theRAM 40. The unencrypted PFM instructions in theRAM 40 remain unencrypted, even after the encryption process. Thus, these instructions remain available for execution by theprocessor 30. All that is changed by the PFM encryption process is theencrypted PFM 140 stored on theEKE 14.

Establishment of File Management Parameters

After storing the newencrypted PFM 140 onto theEKE 14,processor 30 proceeds to establish parameters for use in managing access to the data files 154-164, 170 on theEKE 14.Processor 30 preferably begins the establishment process by decrypting 244 the information stored infile 152 of theEKE 14. Preferably, the information stored infile 152 is decrypted by executing encryption modules 56, using the initial key code provided by the user as the decryption key. Once decrypted, the information fromfile 152 is stored inRAM 40 for subsequent access and manipulation. Note that this decryption process does not alter file 152 stored on theEKE 14. File 152 remains encrypted.

FIG. 8a shows the contents offile 152, stored inRAM 40, after decryption. As shown in FIG. 8a, a table 370 of file information is preferably maintained withinfile 152. For each of the managed data files 154-164, 170, there are six corresponding parameters: (1) a file name; (2) a file address; (3) a file identification code; (4) a file status; (5) an operational key file name; and (6) a file reference code. The file name, file address, and file identification code are preferably assigned by the provider for each of the files 154-164, 170, along with a status flag indicating that the file is closed. However, no operational key file names or file reference codes are assigned by the provider. These parameters need to be established by theUAS 12. Thus, one of the purposes of steps 246-260 is to establish an operational key file name and a file reference code for each of the managed files 154-164, 170. A second purpose is to encrypt the information in each of the managed files 154-164, 170 using an appropriate operational key code. This second purpose will become more clear as steps 246-260 are described.

Processor 30 preferably begins establishing file management data by choosing one of the managed files (file 154, for example) and selecting 246 an operational key file name to associate with the file. This selecting step is preferably carried out by accessingsection 1160 ofRAM 40, and selecting one of the operational key file names stored therein. For illustrative purposes, it will be assumed that operational key file name₂ is selected. Once selected, the operational key file name is stored 248 in table 370 inRAM 40, as shown in FIG. 8b. Thereafter,processor 30 uses the selected operational key file name to retrieve 250 fromsection 1160 ofRAM 40 the operational key code corresponding to the selected operational key file name. In the present example, since operational key file name₂ was selected, operational key code₂ will be retrieved. After retrieving the operational key code,processor 30retrieves 252 the file identification code corresponding to file 154 (ID Code₁₅₄), and processes 254 the file identification code using the retrieved operational key code. Preferably,processor 30 carries out processingstep 254 by encrypting the file identification code, using the operational key code as the encryption key. The product ofprocessing step 254 is an encrypted file identification code, also referred to herein as a file reference code. Under the current example, the file reference code forfile 154 will be an encrypted version of ID Code₁₅₄, encrypted using operational key code₂ as the encryption key. Once this file reference code is derived, it is stored 255 in table 370 inRAM 40, as shown in FIG. 8b. With regard to the entries in the "File Reference Code" column of table 370, the ! are used to indicate that the quantity contained therein is encrypted, while the number following the E denotes the operational key code used as the encryption key. Thus, the entry " ID Code154!E2" indicates that the file reference code was derived by encrypting ID Code₁₅₄ using operational key code₂ as the encryption key. By implementing steps 246-255 as described above, an operational key file name and a file reference code are established forfile 154.

Steps 246-255 accomplish the first purpose of the file management parameter establishment process. The second purpose that of re-encrypting the data in a selected managed file 154-164, 170, is accomplished by steps 256-259.Processor 30 preferably begins the re-encrypting process by first decrypting 256 the information stored in the selected data file (file 154 in the present example). Recall thatfile 154 and the other data files 156-164 on theEKE 14 were initially encrypted using the initial key code chosen by the provider. Thus, to decryptfile 154,processor 30 preferably uses the initial key code (previously provided by the user via keyboard subsystem 52) as the decryption key. Once decrypted, the data fromfile 154 is stored 257 inRAM 40 for subsequent reference and manipulation. Thereafter,processor 30reencrypts 258 the data fromfile 154 using a selected operational key code as the encryption key. Preferably, the operational key code used to re-encrypt the data from a file is the same as that used to derive the file reference code for that file. In the present example, operational key code₂ was used to derive the file reference code forfile 154. Thus, operational key code₂ is preferably used to re-encrypt the data fromfile 154. After the data fromfile 154 is re-encrypted, the re-encrypted data is stored 259 back intofile 154 on theEKE 14, preferably overwriting the information that was previously stored therein. Thus, after step 259, file 154 on theEKE 14 has been changed. The data infile 154 is no longer encrypted using the initial key code chosen by the provider. Instead, the data is now encrypted using one of the operational key codes specific to theUAS 12. Consequently, a unique relationship is established betweenfile 154 and theUAS 12. OnlyUAS 12 can now decrypt the information infile 154. The file management parameter establishment process forfile 154 is now complete.

After carrying out step 259,processor 30 proceeds to step 260 to determine whether more managed files remain to be processed. If so, thenprocessor 30 loops back to step 246 to repeat the file management parameter establishment process for another managed file. Steps 246-260 are preferably repeated until all of the managed files 154-164, 170 have been processed as described above forfile 154. Once all managed files are processed, the EKE initialization process is complete.

At this point, a special aspect of the providerhistorical file 170 should be noted. As background, the providerhistorical file 170 acts as a repository for historical information received from the provider. File 170 preferably contains a plurality of historical entries, with each entry having a unique entry designation associated therewith. In the preferred embodiment, each of the historical entries bears provider encryption (i.e. encryption to which the user does not have the encryption key); hence, these entries cannot be understood by the user's UAS/EKE assembly. Since the entries themselves are already encrypted by the provider,processor 30 need not protect them further by encrypting them. The entry designations, on the other hand, do not bear provider encryption. To protect these designations from third parties,processor 30 preferably encrypts the designations in accordance with the method described above. Thus when a statement is made herein that the providerhistorical file 170 is encrypted, it should be understood that it is the designations which are being encrypted.

After the file management parameter establishment process has been performed for all of the managed files 154-164, 170, table 370 stored inRAM 40 may resemble that shown in FIG. 8b, wherein each of the managed files has an operational key file name and a file reference code associated therewith. Several points should be noted from FIG. 8b. First, note that the same operational key file name (operational key file name₂, for example) may be associated with more than one file. There is no requirement that there be a unique exclusive relationship between a file and its corresponding operational key file name. Second, note that there is no discernible pattern in the association of file with operational key file name. This shows that no constraints are placed on the association of files with operational key file names. Overall, there is great flexibility in selecting the parameters used in the file management process.

The completion of table 370 inRAM 40 is only one of the consequences of the file management parameter establishment process. A second consequence is that each of the managed files 154-164, 170 on theEKE 14 is overwritten. As discussed above in connection with steps 256-259, once an operational key file name is associated with a file, the data in that file is decrypted and then re-encrypted using the operational key code corresponding to the selected operational key file name. The re-encrypted data is thereafter stored back into the file on theEKE 14, preferably overwriting the data previously stored in the file. Thus, after file management parameters are selected, the information in the managed files 154-164, 170 will no longer be encrypted according to the initial key code provided by the provider. Instead, each managed file will be encrypted according to a particular operational key code.

To illustrate this more clearly, reference will be made to FIG. 8b, which shows that: (1) operational key file name₂ is associated withfiles 154 and 160; (2) operational key file name₁₀ is associated withfile 156; (3) operational key file name₂₀ is associated withfiles 158 and 162; (4) operational key file name₁₉ is associated withfile 164; and (5) operational key file name₁₃ is associated withfile 170. Based on this information, the following conclusions can be drawn with regard to the managed files 154-164, 170 stored on theEKE 14 after the file management parameter establishment process is carried out: (1) the information infiles 154 and 160 are now encrypted using operational key code₂ as the encryption key; (2) the information infile 156 is now encrypted using operational key code₁₀ as the encryption key; (3) the information infiles 158 and 162 are now encrypted using operational key code₂₀ as the encryption key; (4) the information infile 164 is now encrypted using operational key code₁₉ as the encryption key; and (5) the information infile 170 is now encrypted using operational key code₁₃ as the encryption key. As this example illustrates, the file management parameter establishment process reencrypts the information in each of the managed files 152-164, 170 using one of the operational key codes stored within theUAS 12. This serves to establish a unique relationship between each of the managed files and theUAS 12. Noother UAS 12, unless it has the same operational key codes stored under the same operational key file names, can now decrypt these managed files.

A third consequence of the file management parameter establishment process is the storage of a plurality of unencrypted data files withinRAM 40. To elaborate, insteps 257 and 258 of FIG. 7b, the information in each of the managed files 154-164, 170 was decrypted and stored inRAM 40. Thus, as shown in FIG. 9b,RAM 40 now contains a plurality of unencrypted data files 1254-1264, 1270. These unencrypted data files 1254-164, 1270 correspond to the encrypted data files 154-164, 170 on theEKE 14. That isunencrypted file 1254 contains an unencrypted version of the information contained inencrypted file 154,unencrypted file 1256 contains an unencrypted version of the information contained inencrypted file 156, and so on. The creation of these data files 1254-1264, 1270 is useful because it providesprocessor 30 with unencrypted data that it can use in communicating with thePAS 18 and in the file management parameter updating process. Files 1254-1264, 1270 will be discussed in greater detail in later sections.

Post-initialization Activity

Referring again to FIG. 7a, afterstep 182 is completed, thenew EKE 14 is fully initialized. After initialization, the UAS-EKE assembly 16 is ready to interact with thePAS 18. Accordingly, instep 200, control is transferred from the UAS-EKE control portion 1142 of the PFM 1140 (FIG. 9a) to the user device-PAS control portion 1144 of thePFM 1140. Thereafter,processor 30 executes the unencrypted instructions inportion 1144 to coordinate interaction between theuser device 16 and the PAS. Under control ofportion 1144,processor 30 may execute theapplication portion 145 of the provider-specific software 141 to generate messages or session codes to send to thePAS 18.Processor 30 may also execute thecommunications modules 146 of the provider-specific software 141 to package the session codes in a proper manner. In addition, if the user chooses to actually send the session codes to thePAS 18, thenprocessor 30, under control ofportion 1144, coordinates the exchange of information between theuser device 16 and thePAS 18.Portion 1144 will be described in greater detail in a later section. Once all of the user device-PAS control functions desired by the user are performed under control ofportion 1144, then control is preferably transferred back 202 to the UAS-EKE control portion 1142. In response,processor 30 once again executes the instructions inportion 1142. More specifically,processor 30 resumes performing UAS-EKE control functions by carrying outstep 203.

Updating of the Recognition Parameters

As mentioned above, one of the major objectives of the present invention is to ensure system security. This objective is furthered by dynamically and regularly changing the parameters used in implementing the recognition and comprehension methodologies and in managing the files 154-164, 170. By changing or updating these parameters on a regular basis, any information which is fraudulently obtained will be rendered useful for only a short period of time. Once the parameters are changed, the stolen information will be of little value. Thus, the dynamic alteration of parameters serves to limit the damage caused by intercepted or stolen information. This in turn lessens the incentive to try to steal information from thesystem 10.

A number of different strategies may be implemented to achieve effective dynamic alteration of parameters. In the preferred embodiment, the processor 30: (1) updates the recognition parameters whenever the user instructs it to do so; and (2) updates the file management parameters each time theUAS 12 andEKE 14 interact. However, if so desired, other strategies may be used, such as updating all of the parameters every time theUAS 12 andEKE 14 interact, or updating the parameters every other time theUAS 12 andEKE 14 interact, or updating the parameters on a random basis. These and other strategies are within the contemplation of the present invention.

Referring again to FIG. 7a, onceportion 1142 regains control fromportion 1144,portion 1142 causes theprocessor 30 to begin carrying out the updating function. Preferably,processor 30 begins performing this function by querying 203 the user as to whether the user wishes to update the recognition parameters. As used in this discussion, the recognition parameters include the operational key file name stored infile 148 of theEKE 14, and the EKE reference code stored in bothsection 1160 of theRAM 40 andsection 60 of the non-volatile memory 38 (in encrypted form). If the user indicates that he does not wish to update the recognition parameters, thenprocessor 30 proceeds to step 206. However, if the user indicates that updates are desired, thenprocessor 30 branches to step 204 to implement the updates. Step 204 is shown in greater detail in FIG. 7e.

Processor 30 preferably begins the updating process by selecting 290 a new operational key file name. This is preferably achieved by accessingsection 1160 ofRAM 40, and selecting one of the other operational key file names stored therein. For illustrative purposes, it will be assumed that operational key file name₂ is selected. Once the new operational key file name is selected, it is stored 290 infile 148 of theEKE 14, preferably replacing the old operational key file name. Thereafter,processor 30retrieves 292 fromsection 1160 ofRAM 40 the operational key code stored as a record under the new operational key file name. In the current example, operational key code₂ will be retrieved. Once retrieved, the new operational key code is used byprocessor 30 to process 294 the EKE identification code stored infile 150 of theEKE 14. Preferably, instep 294,processor 30 encrypts the EKE identification code using the new operational key code as the encryption key to derive a new encrypted identification code, referred to as the new EKE reference code. The encrypting function is preferably carried out by executing the encryption modules 56. Once derived, the new EKE reference code is stored 296 insection 1160 of theRAM 40 as a record under the new operational key file name. In the present example, the new reference code will be stored as a record under operational key file name₂. Once that is done,processor 30 preferably deletes 298 the old EKE reference code stored under the old operational key file name. The update of the recognition parameters is thus complete.

By storing the new EKE reference code, and by deleting the old EKE reference code,processor 30 has changed the recognition and comprehension parameters stored insection 1160 of theRAM 40. This change needs to be reflected insection 60 of thenon-volatile memory 38. To updatesection 60,processor 30 preferably first encrypts 300 the parameters now stored insection 1160 of theRAM 40 using the UAS key code as the encryption key to derive a new set of encrypted recognition and comprehension parameters.Processor 30 then stores 302 the new encrypted parameters intosection 60 of thenon-volatile memory 38, preferably replacing the parameters previously stored therein.Section 60 is thus updated. Sincesection 60 now contains new information,processor 30 preferably sets 304 the "new data" flag to indicate to the master EKE control program 70 (the next time it is executed by processor 30) thatsection 60 now contains new data which should be copied into themaster EKE 70 for backup purposes.

Twosteps 306, 308 still remain to be performed beforeprocess 204 is fully implemented. These steps relate to re-encryption of thePFM 140 on theEKE 14. Recall from a previous discussion relating tosteps 242 and 243 of FIG. 7b that thePFM 140 stored on theEKE 14 is preferably encrypted using the same operational key code as that used to derive the EKE reference code. In the above updating steps 290-296, the operational key code used to derive the EKE reference code was changed. Thus, thePFM 140 now needs to be re-encrypted using the new operational key code. Accordingly, instep 306,processor 30 encrypts thePFM 1140 stored inRAM 40, using the new operational key code (operational key code₂ in the present example) as the encryption key. Preferably,processor 30 encrypts all of thePFM instructions 1140 stored in theRAM 40 except for those instructions pertaining to processes 174-180, 184-190, 216-224, and 225-227 of FIG. 7a, which are left unencrypted. The product ofstep 306 is a new encrypted PFM, encrypted using the same operational key code as that used to derive the new EKE reference code. Once the new encrypted PFM is derived,processor 30stores 308 the newencrypted PFM 140 onto theEKE 14, preferably replacing the encrypted PFM currently stored thereon. As was the case with the old encrypted PFM, the new encrypted PFM will have anunencrypted portion 143 which is capable of carrying out processes 174-180, 184-190, 216-224, and 225-227 of FIG. 7a. Afterstep 308 is performed, the recognitionparameter updating step 204 is fully implemented.

Updating of the File Management Parameters

Referring again to FIG. 7a, regardless of whether the recognition parameters are updated,processor 30 preferably carries outstep 206 to update the file management parameters stored in table 370 of theRAM 40. The process of updating the file management parameters is shown in greater detail in FIG. 7f. Like the file management parameter establishment process, the updating process has two purposes. The first purpose is to establish a new operational key file name and a new file reference code for each of the managed files 154-164, 170. The second purpose is to encrypt each of the managed files using a new operational key code. With this background information in mind, the file management parameter updating process will now be described with reference to FIGS. 7f, 8b, 8c, and 9b.

Preferably,processor 30 begins the updating process by selecting one of the managed files 154-164, 170 to update. Again, it will be assumed thatfile 154 is selected. Once that is done,processor 30 preferably selects 324 a new operational key file name to associate with the selected file. As shown in FIG. 8b, file 154 currently has operational key file name₂ associated therewith. Thus, instep 324, an operational key file name different from operational key file name₂ is preferably selected forfile 154. Preferably,processor 30 carries outstep 324 by accessingsection 1160 ofRAM 40, and selecting one of the other operational key files names stored therein. For illustrative purposes, it will be assumed that operational key name₁₁ is selected forfile 154 instep 324. Once selected, the new operational key file name is stored in table 370 (as shown in FIG. 8c), preferably replacing the old operational key file name. Thereafter,processor 30 proceeds to step 326 to retrieve fromsection 1160 of theRAM 40 the operational key code corresponding to the new operational key file name. In the present example, since operational key file name₁₁ was selected, operational key code₁₁ will be retrieved. Once retrieved, the new operational key code is used byprocessor 30 to process 328 the file identification code (ID Code₁₅₄) corresponding to file 154. Preferably, instep 328,processor 30 encrypts the file identification code using the new operational key code as the encryption key to derive a new file reference code forfile 154. In the present example, the new file reference code will be an encrypted version of ID Code₁₅₄, encrypted using operational key code₁₁ as the encryption key. Once the new file reference code is derived, it is stored 330 in table 370 (as shown in FIG. 8c), preferably replacing the old file reference code. The entries in table 370 corresponding to file 154 are thus updated. Afterstep 330,processor 30 proceeds to step 332 to determine whether more managed files remain to be updated. If so, thenprocessor 30 loops back to step 324 to update the parameters for another managed file. Preferably, steps 324-332 are repeated until the file management parameters for all of the managed files 154-164, 170 are updated. After steps 324-332, table 370 may resemble that shown in FIG. 9c. A comparison of FIG. 9c with FIG. 9b will reveal that the file management parameters for all of the managed files have indeed been updated. Thus, the first purpose of the file management parameter update process is achieved.

To achieve the second purpose (that of re-encrypting each of the managed files using a new operational key code), the updated file management table 370 shown in FIG. 8c will be used as a guide.Processor 30 preferably begins the re-encryption process by selecting one of the managed files 154-164, 170 to process. Again, it will be assumedfile 154 is first selected. Once the file is selected,processor 30retrieves 334 from table 370 stored inRAM 40 the new operational key file name corresponding to the selected file. With reference to FIG. 8c, operational key file name₁₁ will be retrieved forfile 154 in the present example. Thereafter,processor 30 uses the retrieved operational key file name to accesssection 1160 of theRAM 40 to retrieve 336 therefrom the operational key code corresponding to the retrieved operational key file name. In the current example, operational key code₁₁ will be retrieved. Once that is performed,processor 30 retrieves fromRAM 40 the unencrypted data 1254 (FIG. 9b) corresponding to file 154. Recall that insteps 256 and 257 of FIG. 7b, the data infile 154 and the rest of the managed files 156-164, 170 were decrypted and stored inRAM 40 as unencrypted data files 1254-1264, 1270, as shown in FIG. 9b. These unencrypted data files 1254-1264, 1270 can now be used byprocessor 30 for encryption purposes.

Once theunencrypted data 1254 forfile 154 is retrieved fromRAM 40,processor 30 encrypts 340 the data using the new operational key code (operational key code₁₁) as the encryption key to derive a new set of encrypted file data. Once derived, this new encrypted file data is stored 342 infile 154 of theEKE 14, preferably overwriting the data that is currently stored therein. Thus, file 154 on theEKE 14 is updated. More specifically, the data infile 154 has been re-encrypted using a new operational key code. Afterstep 342, processing offile 154 is finished. Thereafter,processor 30 proceeds to step 344 to determine whether more managed files 154-164, 170 remain to be updated. If so, thenprocessor 30 loops back to step 334 to re-encrypt the data in another file. Preferably, steps 334-344 are repeated until all of the managed files 154-164, 170 have been processed. At the end of this process, all of the managed files 154-164, 170 on theEKE 14 will have been re-encrypted using a new operational key code specific to theUAS 12. The file managementparameter update process 206 is now complete.

Termination of UAS-EKE Interaction

After the file management parameters have been updated,processor 30 is almost ready to terminate interaction between theUAS 12 and theEKE 14. Before interaction is terminated, however,processor 30 performs two more tasks. First,processor 30 stores the updated file management information contained in table 370 intofile 152 of theEKE 14. Because table 370 contains important file access information, it should not be stored onEKE 14 unprotected. Thus, in storing the file management information ontoEKE 14,processor 30 preferably first encrypts 208 the information in table 370. Step 208 is preferably carried out by first setting all of the status flags in table 370 to "closed". Thereafter,processor 30 retrieves fromfile 148 of theEKE 14 the operational key file name stored therein. Then, using this operational key file name,processor 30accesses section 1160 of theRAM 40 to retrieve therefrom the operational key code corresponding to the operational key file name. Thereafter, using the retrieved operational key code as the encryption key,processor 30 encrypts the information in table 370 stored inRAM 40 to derive a set of encrypted file management data. Once that is done,processor 30stores 210 the encrypted file management data intofile 152 of theEKE 14, preferably overwriting any information that is currently stored therein. Thus, file management data is stored on theEKE 14 in a safe and protected fashion.

As a final task,processor 30checks 212 the status of a "pause mode" flag. If the flag is set, thenprocessor 30 encrypts the information stored infile 166 of theEKE 14. As will be explained in more detail later, pause mode is a mode of operation which allows a user to store session codes for later access. This mode of operation is useful for prematurely halting the generation of session codes. For example, if a user has generated some but not all of the session codes he wishes to send to aPAS 18, and for some reason, needs to stop, he can prematurely end the session code generation process by invoking pause mode. When invoked, pause mode causes the already generated session codes to be stored infile 166 so that the user can retrieve them at a later time. Thus, when invoked, pause mode causes unencrypted session codes to be stored intofile 166 of theEKE 14.

As mentioned earlier, it is undesirable to store any information on theEKE 14 unprotected. Thus, if session codes are stored infile 166, thenprocessor 30 preferably encrypts 214 the session codes to protect them from unauthorized access.Encryption step 214 is quite similar toencryption step 208 discussed above. More particularly,processor 30 preferably encrypts the session codes by first retrieving fromfile 148 of theEKE 14 the operational key file name stored therein. Then, using this operational key file name,processor 30accesses section 1160 of theRAM 40 to retrieve therefrom the operational key code corresponding to the operational key file name. Thereafter, using the retrieved operational key code as the encryption key,processor 30 encrypts the session codes stored infile 166 to derive a set of encrypted session codes. Once that is done,processor 30 stores the encrypted session codes intofile 166 of theEKE 14, preferably overwriting the session codes currently stored therein. The session codes are now protected. At this point,processor 30, under control of the UAS-EKE control portion 1142 of theunencrypted PFM 1140, has performed all of its necessary control functions. Thus, the initial session between theUAS 12 and theEKE 14 can now be terminated.

As mentioned previously, the integrated and distributed embodiments (FIGS. 2a and 2b) of theUAS 12 function in substantially the same manner. For the most part, this is true. However, with regard to the distributed embodiment, one additional consideration needs to be taken into account. This consideration relates to the storage of the unencrypted data from files 152-164, 170 in the RAM 94 (FIG. 2b). To elaborate, in the integrated embodiment, the user has full control over theUAS 12. Hence, after operation, the user is free to deactivate theUAS 12. By deactivating theUAS 12, the user is in effect purging from thevolatile RAM 40 all of the unencrypted information stored therein. Hence, after deactivation, no records remain of the unencrypted data, which is a desirable result. In the distributed embodiment, however, because thehardware portion 80 of theUAS 12 may be under the control of a third party, the user may not have the luxury of being able to deactivate thehardware portion 80 to purge theRAM 94 of its contents. Hence, in the distributed embodiment, unless some procedure is implemented to eradicate the data stored inRAM 94, unencrypted data from files 152-164, 170 will remain in theRAM 94, freely accessible to any device which knows how to access it. This is a very undesirable and dangerous scenario.

To prevent such a scenario from arising, the UAS-EKE control portion 1142 of the PFM preferably causes theprocessor 80 to perform one further process before terminating interaction between theUAS 12 and theEKE 14. This process involves overwriting all of the RAM, or at least portions of theRAM 94 in which unencrypted data was stored, with random data. As an example,processor 80 may write a "1" into all of the selected portions of theRAM 94, orprocessor 80 may write a "0" into all of the selected portions, orprocessor 80 may write any combination of "1" and "0" into the selected portions. Any data pattern may be written into theRAM 94 so long as the unencrypted data contained therein is eradicated. Once theRAM 94 is purged in this manner, then interaction between theUAS 12 and theEKE 14 can be terminated.

Normal UAS-EKE Operation

Thenext time UAS 12 andEKE 14 are coupled to each other viastorage device interface 32,processor 30 will again first access and execute theunencrypted portion 143 of thePFM 140 stored on theEKE 14. Under control ofportion 143,processor 30 will determine 174 whethermodules 172 are stored on theEKE 14. If so, thenprocessor 30 will load the modules into theRAM 40 and set the "override" flag. Thereafter,processor 30 will again determine 177 whether theEKE 14 is a new one by checkingfile 148 for an operational key file name. This time, however, there will be a file name stored infile 148; thus,processor 30 will not perform the initialization steps 178-182. Instead,processor 30 will settle into regular operational mode. This mode of operation will now be described with reference to FIG. 7a.

Still under control ofportion 143,processor 30 continues processing by checking 184 for a "delayed transmission" flag. If the flag is set, then it indicates that delayed transmission mode has been invoked. In such a case,processor 30 branches to step 225 to implement the delayed transmission mode of operation. Before describing steps 225-227 and steps 216-224 in detail, however, a short discussion of the delayed transmission mode of operation will be provided.

Delayed Transmission Mode

Delayed transmission mode is a mode of operation which is designed to increase convenience to the user. To elaborate, in normal operation, thePFM 140 on theEKE 14 causesprocessor 30 to implement a recognition methodology to determine whether theEKE 14 and theUAS 12 are authorized to interact with each other. As discussed above, thesystem 10 of the present invention is set up such that eachEKE 14 is preferably authorized to interact with only oneprincipal UAS 12. While this aspect of the invention greatly enhances system security, there may be instances where a user wishes to use anEKE 14 with a UAS other than the principal UAS. To allow for such a scenario, the present invention provides a delayed transmission mode whereby anEKE 14 may be operated with any compatible UAS. In delayed transmission mode, thePFM 140 does not cause the processor in the UAS to implement a recognition methodology; hence, any UAS may interact with the EKE. At the same time, though,PFM 140 does not allow theprocessor 30 to access any of the files 148-172 orprograms 141 on theEKE 14. Instead, theprocessor 60 is allowed to access only file 166 of theEKE 14 wherein pregenerated messages or session codes are stored, and file 167. Even with this limited access, however, a UAS and an EKE can communicate with a provider device by accessing and sending the stored session codes infile 166 to the provider device, and by receiving and storing confirmation information from the provider device infile 167. Hence, delayed transmission mode provides a good compromise between security and flexibility. It allows anEKE 14 to be used with any compatible UAS to communicate with a provider while, at the same time, preserving the security of the files on theEKE 14. With this background information in mind, delayed transmission mode will now be described.

Referring again to FIG. 7a,processor 30, under control ofunencrypted portion 143, preferably begins operating in delayed transmission mode by querying 225 the user as to whether the user wishes to abort the transmission. If so, thenprocessor 30 deletes 226 the session codes stored infile 166, resets 227 the "delayed transmission" flag, and terminates operation. On the other hand, if the user wishes to continue with the transmission, thenprocessor 30 proceeds to step 216 to access file 166 to retrieve the session codes stored therein. Preferably, the stored session codes contain all of the information needed to properly communicate with a provider, and are in a form expected by the provider. After the session codes are retrieved,processor 30 executes thecommunications modules 58 stored innon-volatile memory 38 to send 218 the session codes to the provider via thecommunications interface 34. Once sent, the session codes are preferably purged 220 fromfile 166. Thereafter,processor 30 waits for a response from the provider. When confirmation information or confirmation codes are received 221 from the provider,processor 30stores 221 the confirmation codes infile 167 for subsequent processing.Processor 30 then sets 222 an update flag. As will be explained in a subsequent section, this update flag causes theprincipal UAS 12, the next time it interacts with theEKE 14, to process the confirmation codes stored infile 167 to implement any necessary updates. Once that is done, the delayed transmission flag is reset 224 to indicate that delayed transmission mode has been implemented, and to place theEKE 14 back into normal operational mode. Thereafter,portion 143 causesprocessor 30 to terminate interaction between theUAS 12 and theEKE 14.

Recognition Methodology

Returning to step 184, if the delayed transmission flag is not set, thenprocessor 30 proceeds to implement 186 the recognition methodology of the present invention. Step 186 is shown in greater detail in FIG. 7c.Processor 30 begins the recognition process by retrieving 262 the operational key file name and the EKE identification code stored infiles 148 and 150, respectively, of theEKE 14. Then, using the retrieved operational key file name as an index,processor 30retrieves 264 fromsection 1160 of theRAM 40 the operational key code stored as a record under the retrieved operational key file name. If the retrieved operational key file name is not found in theRAM 40, then it most likely means that theUAS 12 is not the proper UAS. In such a case, interaction between theUAS 12 and theEKE 14 is terminated in order to prevent unauthorized access of theEKE 14.

On the other hand, if the retrieved operational key file name is found in theRAM 40, then the operational key code corresponding to the retrieved operational key file name is retrieved from theRAM 40. Once retrieved, this operational key code is used to process 266 the EKE identification code. Preferably, instep 266,processor 30 encrypts (by executing encryption modules 56) the EKE identification code using the operational key code as the encryption key to derive a processed EKE identification code. Thereafter, the processed EKE identification code is compared 268 to the EKE reference code stored as a record under the retrieved operational key file name insection 1160 of theRAM 40. Recall that in the previous session conducted between theUAS 12 and theEKE 14, the EKE reference code was derived by encrypting the same EKE identification code using the same operational key code. Thus, the processed EKE identification code and the EKE reference code should be consistent. If they are not, then it means that theEKE 14 contains the wrong operational key file name, or the wrong EKE identification code, or both. Whatever the reason, if the two codes are not consistent, then theEKE 14 is not a recognized EKE. Referring again to FIG. 7a, if theEKE 14 is not a recognized EKE, then it means that theUAS 12 and theEKE 14 are not authorized to interact with each other. Consequently,processor 30 terminates interaction between the two unauthorized components.

Thus far, the recognition methodology of the present invention has been described as including aprocessing step 266 wherein the EKE identification code is processed using the operational key code before being compared to the EKE reference code stored in theRAM 40. While this is the preferred embodiment, it should be noted that a simpler but less secure process may be employed if so desired. Under this alternative method, recognition is carried out byprocessor 30 by first retrieving the operational key file name and the EKE identification code fromfiles 148 and 150, respectively, of theEKE 14. Then, using the operational key file name,processor 30 retrieves a pre-stored EKE reference code stored under the operational key file name inRAM 40. Thereafter,processor 30 compares the EKE reference code to the EKE identification code to determine if they are consistent. If the two codes are not consistent, then theEKE 14 is not a recognized EKE. Consequently,processor 30 terminates interaction between theUAS 12 and theEKE 14.

Decryption of the PFM on the EKE

Returning to step 188 of FIG. 7a, if theEKE 14 is a recognized EKE, thenprocessor 30 proceeds to decrypt 189 the remainder of thePFM 140, including the encrypted parts ofportion 142 and the entirety ofportion 144. Preferably,step 189 is performed as follows. First,processor 30 retrieves the operational key file name stored infile 148 of theEKE 14. Then, using this operational key file name,processor 30 retrieves fromsection 1160 of theRAM 40 the operational key code corresponding to the operational key file name. Once this operational key code is retrieved, it is used byprocessor 30 as a decryption key to decrypt thePFM 140 stored on theEKE 14. Once decrypted, the decrypted PFM is stored in its entirety (including those portions corresponding to unencrypted portion 143) inRAM 40. FIG. 9a shows the contents ofRAM 40 after this decryption process. As shown,RAM 40 now contains anunencrypted version 1140 of thePFM 140 on theEKE 14, comprising an unencrypted UAS-EKE control portion 1142 and an unencrypted user device-PAS control portion 1144. Once thePFM 140 is decrypted and stored inRAM 40,processor 30 begins executing the unencrypted PFM instructions stored in theRAM 40. At this point,processor 30 is still controlling interaction between theUAS 12 and theEKE 14. Thus, processor continues operation by executing the unencrypted instructions inportion 1142.

File Management

Under control ofportion 1142,processor 30 proceeds to step 191 to decrypt the encrypted file management data stored infile 152 of theEKE 14. This decryption process is quite similar to that performed for decrypting thePFM 140. More specifically,processor 30 beginsprocess 191 by retrieving the operational key file name stored infile 148 of theEKE 14. Then, using this operational key file name,processor 30accesses section 1160 of theRAM 40 to retrieve therefrom the operational key code corresponding to the operational key file name. After the operational key code is retrieved,processor 30 uses the key code as a decryption key to decrypt the data infile 152. Once decrypted, the data in file 152 (which in actuality is table 370 of FIG. 8c containing the file management parameters) is stored inRAM 40. Thus, afterstep 191,RAM 40 contains table 370, which in turn contains the file management parameters needed to obtain access to the managed files 154-164, 170 on theEKE 14. Withfile 152 decrypted and table 370 of FIG. 8c derived, theprocessor 30 can now use the information in table 370 to perform itsfile management function 192.

FIG. 7d provides a more detailed flow diagram forprocess 192. Preferably,processor 30 performs the file management function by first selecting 270 one of the managed files 154-164, 170, and then retrieving 270 from table 370 the operational key file name and the file identification code corresponding to the chosen file.Processor 30 then uses the operational key file name as an index to retrieve 272 fromsection 1160 of theRAM 40 the operational key code corresponding to the operational key file name. If this operational key file name is not found in theRAM 40, then it most likely means that theEKE 14 is interacting with an improper UAS (i.e. a UAS other than the principal UAS). In such a case,processor 30 preferably halts operation.

On the other hand, if the operational key file name is found in theRAM 40, then the operational key code corresponding to the operational key file name is retrieved. Once retrieved, the operational key code is used byprocessor 30 to process 274 the file identification code. Preferably, instep 274,processor 30 derives a processed file identification code by encrypting the file identification code, using the operational key code as the encryption key. Once the processed file identification code is derived, it is compared 276 with the file reference code stored in table 370 for the selected file. If the file reference code is inconsistent with the processed file identification code, then an accessing error has occurred, which could mean that an unauthorized user is trying to access the managed files 154-164, 170. To prevent unauthorized access to the managed files,processor 30 preferably prematurely terminates interaction between theUAS 12 and theEKE 14.

On the other hand, if the processed file identification code is consistent with the file reference code stored in table 370 for the selected file, then the file status flag in table 370 corresponding to the selected file is set 280 to "open". Thereafter,processor 30 determines whether more managed files remain to be processed. If so, thenprocessor 30 loops back to step 270 to select and to process another managed file. Preferably, steps 270-282 are repeated until either the status of all of the managed files 154-164, 170 has been set to "open" or an accessing error is encountered.

If all of the status flags in table 370 have been set to "open", thenprocessor 30 proceeds to step 286 to decrypt and store the data in all of the managed files 154-164, 170 intoRAM 40 for subsequent access and manipulation.Process 286 will be described with reference to table 370 of FIG. 8c.Process 286 preferably begins withprocessor 30 selecting one of the files (file 154, for example) listed in the table 370. Then,processor 30 retrieves from the table 370 the operational key file name (operational key file name₁₁) associated with the selectedfile 154. Once retrieved, the operational key file name₁₁ is used byprocessor 30 to accesssection 1160 of theRAM 40, and to retrieve therefrom the operational key code (operational key code₁₁) corresponding to the operational key file name₁₁. Once that is done,processor 30 uses the operational key code₁₁ as a decryption key to decrypt the data contained infile 154 of theEKE 14. Once decrypted, the data fromfile 154 is stored in section 1254 (FIG. 9b) ofRAM 40. Thus, theRAM 40 now contains an unencrypted version of the data infile 154 which can be manipulated. The decryption process forfile 154 is now complete.

To continueprocess 286,processor 30 selects another listed file (file 156, for example). Once the file is selected,processor 30 retrieves from table 370 the operational key file name (operational key file name₁₅) associated with the selectedfile 156. Then, using the retrieved operational key file name₁₅,processor 30accesses section 1160 of theRAM 40 and retrieves therefrom the operational key code (operational key code₁₅) corresponding to the operational key file name15. Once retrieved, the operational key code₁₅ is used byprocessor 30 as a decryption key to decrypt the data contained infile 156 of theEKE 14. Once decrypted, the data fromfile 156 is stored in section 1256 (FIG. 9b) ofRAM 40.RAM 40 now contains unencrypted data fromfile 156 which can be manipulated. Thus, the decryption process forfile 156 is complete.

Processor 30 preferably repeats this process of selecting, decrypting, and storing data files until all of the files listed in table 370 have been processed. Afterprocess 286 is completed, the contents ofRAM 40 will resemble that shown in FIG. 9b, wherein theRAM 40 contains unencrypted data from all of the managed files 154-164, 170. This unencrypted data 1254-1256, 1270 will be manipulated and possibly altered in the course of communicating with thePAS 18. At this point; it should be noted thatdecryption process 286 does not alter the files 154-164, 170 on theEKE 14. These files remain encrypted. The only unencrypted version of the data in files 154-164, 170 is stored in sections 1154-1264, 1270 of theRAM 40.

One last function performed inprocess 286 is that of decrypting the session codes stored infile 166 of theEKE 14. Recall from a previous discussion relating tosteps 212 and 214 of FIG. 7a that if pause mode is invoked, the session codes stored infile 166 will be encrypted. If the session codes infile 166 were encrypted in a previous session, then they will need to be decrypted in the current session. Thus, as part of thedecryption process 286,processor 30 preferably checks the status of the "pause mode" flag. If this flag is set, thenprocessor 30 will decrypt the encrypted session codes stored infile 166.Processor 30 preferably carries out this decryption process by retrieving fromfile 148 of theEKE 14 the operational key file name stored therein. Then, using the operational key file name,processor 30 retrieves fromsection 1160 of theRAM 40 the operational key code corresponding to the operational key file name. Once retrieved, the operation key code is used byprocessor 30 as a decryption key to decrypt the encrypted session codes infile 166. Once decrypted, the sessions codes are stored back intofile 166.Process 286 has now been fully explained.

Transfer of Control to the User Device-PAS Control Portion of the PFM

Referring again to FIG. 7a, once data from the managed files 154-164, 170 have been decrypted and stored inRAM 40,processor 30 has all of the data it will need to communicate with thePAS 18. Thus,processor 30 is now ready to coordinate the exchange of information with thePAS 18. Hence, instep 200, control is transferred from the UAS-EKE control portion 1142 over to the user devicePAS control portion 1144 of the unencrypted PFM 1140 (FIG. 9b). Thereafter,processor 30 begins executing the unencrypted instructions inportion 1144 to coordinate communication with thePAS 18. Steps 200-214 are carried out here in the same manner as in the previous session. Thus, they need not be described again. It should just be noted that after the current session, the file management parameters and possibly the recognition parameters will once again be updated so that the next time theUAS 12 and theEKE 14 interact, they will use different parameters. The UAS-EKE control portion 1142 of thePFM 1140 has now been fully described.

Before proceeding to the other features of the invention, one unique aspect of theEKE 14 and theUAS 12 should be emphasized. Note that in the system of the present invention, recognition between theUAS 12 and theEKE 14 is carried out by having theprocessor 30 in theUAS 12 access and execute the instructions inunencrypted portion 143 of thePFM 140. Put another way, theprocessor 30 relies on the instructions stored on the external storage device (the EKE) to determine whether it can further access that particular storage device. This is a very unique arrangement. In contrast, in the prior art systems, a processing device contains all of the processing capability and the logic necessary for determining whether it can interact with a storage device. It does not rely on any instructions stored on the storage device. An ATM is an example. A typical ATM determines whether a storage device (an ATM card) is a proper device by executing instructions stored within the ATM itself. The ATM does not rely on any instructions from the ATM card for carrying out the verification process.

A major advantage of the arrangement disclosed in the present invention is that it allows a storage device, having no processing power of its own, to be its own protector. To elaborate, in the prior art systems, the processing device is entrusted with the entire verification function. The sole purpose of the storage device is to provide information, not instructions, to be used in the verification process. In such an arrangement, recognition is a one-way street; the processing device can determine whether the storage device is valid, but the storage device has no way of verifying that the processing device is a valid device. In such a system, it is a relatively simple matter for an invalid processing device to steal information from a storage device. Such is not the case in the present invention. Insystem 10 of the present invention, a processing device, in order to gain access to the data and programs stored on the storage device, must first access and execute theunencrypted control instructions 143 on the storage device. Only if theprocessor 30, under control ofportion 143, is satisfied that the processing device and the storage device are authorized to interact with each other will further access to the storage device be granted. Thus, insystem 10, recognition is a two-way street; interaction between the processing device and the storage device will be allowed only if both devices are valid. Thus, due to the presence of the UAS-EKE control instructions 142 (including unencrypted portion 143), the storage device of the present invention is able to protect itself from invalid processing devices. This unique aspect of the invention makessystem 10 much more secure than the systems of the prior art. The UAS-EKE control portion 142 of thePFM 140, and the interaction between theUAS 12 and theEKE 14, have now been fully described.

User Device-PAS Interaction

The UAS-EKE control portion 142 is only one part of thePFM 140. ThePFM 140 also includes a user device-PAS Control portion 144. It is thisportion 144, when executed byprocessor 30, which coordinates the exchange of information between the user device 16 (formed byUAS 12 and the EKE 14) and thePAS 18.

As a recap,processor 30, under control of theunencrypted portion 143 of thePFM 140, determines whether theUAS 12 and theEKE 14 are authorized to interact with each other. Onceprocessor 30 determines that interaction is authorized,processor 30 carries out steps 189-190 of FIG. 7a to decrypt thePFM 140 on theEKE 14, and to store theunencrypted PFM 1140 into theRAM 40. As stored inRAM 40, theunencrypted PFM 1140 includes an unencrypted UAS-EKE control portion 1142 and an unencrypted user device-PAS control portion 1144. After theunencrypted PFM 1140 is stored inRAM 40,processor 30 begins executing the instructions in the UAS-EKE control portion 1142. Under control ofportion 1142,processor 30 carries outsteps 191 and 192 of FIG. 7a. More specifically,processor 30 decrypts and stores table 370 intoRAM 40. Further,processor 30 decrypts and store the data in files 154-164, 170 intoRAM 40. By the end ofstep 192, the contents ofRAM 40 resemble that shown in FIG. 9b. At this point,RAM 40 contains all of the data needed to communicate with thePAS 18. Thus, instep 200 of FIG. 7a, control is transferred from the UAS-EKE control portion 1142 to the user device-PAS Control portion 1144. Thereafter,processor 30 begins executing the instructions stored inportion 1144 to carry out the user device-PAS control functions.

Control portion 1144 is responsible for coordinating the exchange of information between theuser device 16 and thePAS 18. In carrying out this overall coordination function,portion 1144cause processor 30 to perform a number of sub-functions. First,processor 30 generates the messages or session codes which are to be sent to thePAS 18. Preferably,processor 30 performs this function by executing theapplication portion 145 of the provider-specific software 141 (FIG. 6). Second,processor 30 packages the session codes in a manner expected by thePAS 18. This function is preferably performed by executing thecommunications modules 146 of the provider-specific software 141. Third,processor 30 implements the recognition and comprehension methodologies of the present invention. More specifically,processor 30 cooperates with thePAS 18 to carry out a recognition procedure for ensuring that only proper parties are allowed to communicate.Processor 30 also preferably carries out an encryption/decryption methodology to prevent third parties from comprehending the information exchanged between theuser device 16 and thePAS 18. In addition,processor 30 cooperates with thePAS 18 to dynamically alter the parameters used in the recognition and comprehension processes to make thesystem 10 more difficult to break into, and to minimize the damage caused by fraudulently obtained information. Overall,portion 1144 causes theprocessor 30 to work in conjunction with thePAS 18 to ensure that communications between theuser device 16 and thePAS 18 are secured. Because the operation ofportion 1144 is so entwined with that of thePAS 18, the operation ofportion 1144 will be best understood if described in conjunction with the operation ofPAS 18. Hence.PAS 18 will first be described.

PAS

With reference to FIG. 10, there is shown a block diagram representation of thePAS 18 of the present invention.PAS 18 preferably comprises aprocessor 400, aprogram memory 402 for storing the programs executed byprocessor 400, acommunications interface 404 for forming a communications link with theuser device 16, and astorage device 406 for storing recognition and comprehension parameter information for each user device with which thePAS 18 communicates. In the preferred embodiment,storage device 406 may take on a number of different forms including a hard drive, an optical drive, a memory, or some other device capable of storing information.Storage device 406 may be a part of thePAS 18, as shown in FIG. 10, or it may be a separate and distinct component which is accessed by thePAS 18. Both embodiments are contemplated in the present invention.

As mentioned above, thestorage device 406 stores specific recognition and comprehension information for each user device with which thePAS 18 communicates. This information preferably includes (for each user device) a user device file name which uniquely identifies the user device to thePAS 18, an EKE identification code, an encrypted application address (EAA) associated with the user device, the key codes used in implementing the recognition and comprehension methodologies, and at least some of the provider historical file entries maintained in the providerhistorical file 170 of theEKE 14. Preferably, this information is stored instorage 406 in such a way that, for each user device, a user file is created. The user file is assigned the user device file name, and the parameters associated with the particular user device are stored as records in the user file. Preferably, this same recognition and comprehension information is stored in files 154-162, 170 of the EKE 14 (in encrypted form). This ensures that when theuser device 16 and thePAS 18 communicate, they will be able to understand one another.

Note that the only information stored in the user file of thePAS storage 406 is recognition and comprehension information relating to the user device. There is no other user-specific information, such as actual account information, demographics, etc., stored in the user file. Instead, this information is stored at a location derived from the EAA. More specifically, the EAA is an encrypted address which was encrypted using a secret provider key code known only to the provider. When the EAA is decrypted using the secret provider key code, an encrypted transaction address (ETA) is derived therefrom. This ETA represents the location in the provider system wherein the user-specific information is actually stored. The ETA may be represented by a number of sub-addresses which, in turn, represent separate user sub-accounts. These sub-accounts are usually accessed by specific session codes and accompanying DPIN's. The user-specific information is stored in this manner to prevent parties at the provider's site. (such as employees) from being able to access the information without authorization. Even if the employee has the user's EAA, he will not be able to access the user's specific information because he will not know, unless he decrypts the EAA, where the information is actually located.

To enable thePAS 18 to communicate with theuser device 16,PAS 18 comprises thecommunications interface 404.Interface 404 preferably comprises amodem 415, atelephone port 416 coupled to themodem 415 for connecting to and communicating via a universal telephone line, and ananalog 418 and adigital port 420, both of which are coupled to themodem 415, for communicating through RF, optical, or cable means. Because of the various ports,communications interface 404 allowsPAS 18 to communicate with theuser device 16 through a variety of avenues.

The programs or modules which are needed byprocessor 400 to carry out its intended functions are stored inprogram memory 402. Preferably,memory 402 contains therein a recognition andcomprehension control program 408, acommunications control program 410,encryption modules 412, and optionally, a sessioncode processing program 414. Recognition andcomprehension control program 408 is the main program which is executed byprocessor 400 to carry out most of the functions of thePAS 18. More specifically,control program 408 causesprocessor 400 to implement the recognition methodology of the present invention. In addition,control program 408 coordinates the encryption/decryption of messages, and the updating of recognition and encryption parameters. It iscontrol program 408 which coordinates the execution of the other programs or modules inmemory 402.Program 408 will be described in greater detail in a subsequent section.

In the preferred embodiment, substantially all of the control functions performed by thePAS 18 are carried out byprocessor 400 under control of the recognition andcomprehension control program 408. It should be noted, however, that if so desired, some or all of the functions performed byprocessor 400 andprogram 408 may be carried out by a hardwired logic circuit instead. That is,processor 400 andprogram 408 may be replaced, in whole or in part, with a logic circuit designed to perform equivalent functions. As an example,processor 400 andprogram 408 may carry out the recognition portion of the methodology of the present invention while a logic circuit performs the updating of the recognition parameters. Other divisions of functions are of course possible. As a matter of practicality, the processor/program implementation is preferred because it is more flexible and cost efficient than the alternatives. Nonetheless, the hardwired logic circuit is a possible alternative. Such implementations are within the scope and contemplation of the present invention.

In communicating with the user device via the communications link, certain communications protocols will need to be observed. The function of thecommunications control program 410 is to ensure that outgoing messages are sent using the proper protocol, and that incoming messages are deciphered using the proper protocol. There exists a variety of protocols which may be employed to carry out the exchange of information. Which protocol is implemented byprogram 410 is determined by thecontrol program 408, as will be explained in a subsequent section.

Also stored inmemory 402 are theencryption modules 412. Like the encryption modules 56 inUAS 12,modules 412 preferably perform two major functions. First,modules 412 implement one or more selected encryption/decryption algorithms to encrypt/decrypt data according to a certain encryption key. The algorithms implemented bymodules 412 may be industry accepted standard algorithms such as DES, SKIPJACK, and other well known algorithms, or they may be proprietary algorithms. In the preferred embodiment,modules 412 implement industry accepted algorithms in order to maximize compatibility. Second,modules 412 may be called upon to generate random numbers. This feature ofmodule 412 is used in updating the recognition and comprehension parameters.

As an option,program memory 402 may further contain therein a sessioncode processing program 414. Once thePAS 18 has determined that a user device is a valid device, and has decrypted the incoming session codes, the session codes need to be processed to carry out the transaction desired by the user. The function ofprogram 414 is to process these session codes. Because the incoming session codes are customized to a specific provider, the sessioncode processing program 414 is also preferably customized to the same provider. As an alternative, thePAS 18 need not process the session codes at all, but instead, may relay the codes, along with the EAA, on to a separate provider processing device (not shown) which actually performs the processing function. In such a case,program 414 need not be maintained inmemory 402. Both embodiments are contemplated by the present invention.

Normal User Device-PAS Operation

With reference to FIGS. 11 and 12, the operation of theuser device 16 and thePAS 18 will now be described in detail. FIG. 11 is an operational flow diagram for the user device-PAS control portion 1144 of thePFM 1140, while FIG. 12 is an operational flow diagram for the recognition andcomprehension control program 408 of thePAS 18. Since it is theuser device 16 which initiates communication between the two components, the operation ofuser device 16 will first be described.

Referring now to FIG. 11,processor 30, under control ofportion 1144, preferably begins operation by determining 450 whether the update flag on theEKE 14 is set. The update flag will be set if, in a previous session involving theEKE 14, delayed transmission mode was invoked. To elaborate, recall that delayed transmission mode is a mode of operation which allows theEKE 14, using anycompatible UAS 12, to send a set of session codes to thePAS 18. A result of this mode of operation is that a set of confirmation codes, received from thePAS 18 after the session codes are processed, will be stored infile 167 of theEKE 14. These confirmation codes may and probably will contain updates to some of the recognition and comprehension parameters stored on theEKE 14. These updates may include new key codes, a new user device file name, a new EAA, privileges to be stored infile 168, and updates to thehistorical files 164 and 170. These updates are important and should be processed by theprincipal UAS 12 before any further session codes are generated or sent to thePAS 18. For this reason,processor 30 preferably checks the status of the update flag before proceeding with any other function.

If the update flag is not set, thenprocessor 30 proceeds to step 462 to begin coordinating communication with thePAS 18. However, if the update flag is set, thenprocessor 30 preferably carries out the updating process 452-460 shown in FIG. 11. More specifically,processor 30 begins by retrieving the update information stored infile 167. Once retrieved, the information infile 167 is preferably purged. Thereafter,processor 30 processes 452 the information fromfile 167 to derive meaningful data therefrom. A point to note is that when update information is received fromPAS 18, the information is preferably encrypted according to a current session key code. Hence, in order to derive meaningful information fromfile 167, the information stored therein is first decrypted. Thus, in step 452,processor 30 decrypts the information stored infile 167 by first deriving the current session key code. This is preferably achieved by: (1) retrieving a current user key code (CUKC) fromfile 1258 of theRAM 40; (2) retrieving a current provider key code (CPKC) fromfile 1260 of theRAM 40; and (3) combining the CUKC and the CPKC to derive the current session key code (CSKC). Once the CSKC is derived,processor 30 executes the encryption modules 56 inUAS 12, using the CSKC as the decryption key, to decrypt the information infile 167.

Thereafter,processor 30 extracts a user device file name from the decrypted information, and compares 454 this file name with the user device file name stored infile 1254 of theRAM 40. If the two file names are not consistent, then recognition between theuser device 16 andPAS 18 is not confirmed. As a result, the update information is disregarded 456. On the other hand, if the two file names are consistent, thenprocessor 30 proceeds to update 460 the parameters and historical files on theEKE 14 with the decrypted information fromfile 167. Step 460 may entail storing a new user device file name infile 1254, storing a new EAA infile 1256, storing new key codes infiles 1260 and 1262, and storing new information infiles 1264 and 1270 of theRAM 40. Step 460 may also entail storing remote privileges intofile 168 of theEKE 14. Once the files in theRAM 40, and possibly the files on theEKE 14 are updated,processor 30 goes on to step 462 to begin carrying out its regular coordination function.

Atstep 462,processor 30 determines, by prompting the user, whether the user wishes to prepare for communication with thePAS 18. In the present invention, it is not required that theuser device 16 communicate with thePAS 18 each time the user device-PAS portion 1144 is executed. A user may runportion 1144 simply to update theEKE 14 with information fromfile 167 as described above. Whatever the reason, if communication with thePAS 18 is not desired, then control is transferred 470 back to the UAS-EKE control portion 1142 of theRAM 40. On the other hand, if the user does wish to prepare for communication With thePAS 18, thenprocessor 30 proceeds to step 463 to check the status of the "pause mode" flag on theEKE 14. This flag will be set if, in a previous session, the user prematurely halted the process of generating session codes, thereby causing the session codes already generated to be stored infile 166 of theEKE 14. If the "pause mode" flag is not set, thenprocessor 30 proceeds to step 466. However, if the flag is set, thenprocessor 30retrieves 464 the stored session codes fromfile 166 of theEKE 14. This allows the user to use, in the current session, the session codes generated in a previous session. Preferably, once the session codes are retrieved fromfile 166,processor 30 purges the session codes from thefile 166, and resets the "pause mode" flag.

Thereafter,processor 30 proceeds to step 466, wherein theprocessor 30 executes theapplication potion 145 of the provider-specific software 141 to allow the user to generate session codes to send to thePAS 18. The session codes generated in this step may be text messages, orders for products, transaction codes, etc. Sinceportion 145 is provider-specific, step 466 can generate any session codes dictated by the provider.Application portion 145 may also include logic for generating and changing DPIN's if DPIN's are required by the provider for some or all of the session codes. Again, sinceportion 145 is provider-specific, it can contain logic for causing theprocessor 30 to perform any function desired by the provider. After step 466 is implemented,processor 30 queries 467 the user as to whether the user wishes to invoke pause mode. Here,processor 30 gives the user the chance to prematurely halt the process of generating session codes. If the user indicates that pause mode is desired, thenprocessor 30stores 468 the session codes already generated in the current session intofile 166 of theEKE 14, and sets 469 the "pause mode" flag. Thereafter,processor 30transfers 470 control back to the UAS-EKE control portion 1142 of theRAM 40. On the other hand, if the user does not want to invoke pause mode, thenprocessor 30 proceeds to step 474.

In step 474,processor 30 retrieves selected recognition parameters from theRAM 40. These parameters include the user device file name fromfile 1254 which uniquely identifies theuser device 16 to thePAS 18, and one or more sets of identification information. Identification information may include the EKE identification code from file 1250, the EAA fromfile 1256, and a selected provider historical file entry fromfile 170 of theEKE 14. Preferably, these parameters were preset and pre-stored by the provider when the provider issued theEKE 14. The same parameters are preferably stored instorage device 406 of thePAS 18 so that whenuser device 16 andPAS 18 communicate, they will use the same parameters and hence, be able to recognize one another. After step 474,processor 30 generates and stores 476 a future user key code (FUKC) intofile 1258. This key code, as explained later, will be used to generate a subsequent session key code for use in the recognition and comprehension processes. Preferably, the FUKC is generated by using the random number generating capability of the encryption modules 56.

After FUKC is generated,processor 30 executes 478 thecommunications modules 146 portion of the provider-specific software 141 to properly package the session codes.Modules 146 may dictate the length of certain message segments, the manner and order in which the sessions codes should be arranged, and various other provider-specific parameters.Modules 146 may also add on additional information, such as specific information needed to form a communications link with the provider (the provider's telephone number, for example). In short,modules 146 ensure that the session codes are in a format expected by the provider.

After executingmodules 146,processor 30 proceeds to step 480 to derive a current session key code (CSKC). Preferably, the CSKC is derived by: (1) retrieving a current user key code (CUKC) fromfile 1258 of theRAM 40; (2) retrieving a current provider key code (CPKC) fromfile 1260 of theRAM 40; and (3) combining the CUKC and the CPKC to derive the CSKC. Preferably, like the recognition parameters, the CUKC and the CPKC were preset and pre-stored on theEKE 14 by the provider when the provider issued theEKE 14. Also, the same key codes are preferably stored instorage device 406 ofPAS 18 so that whenuser device 16 andPAS 18 communicate, they will use the same key codes and thus, be able to understand one another.

Once the CSKC is derived,processor 30processes 482 the identification information (also referred to herein as the parameters) and session codes using the CSKC. Instep 482,processor 30 preferably first places the parameters and sessions codes into proper order. In the preferred embodiment, the user device file name is placed at the beginning of the sequence, followed by the identification information (i.e. the EAA, the EKE identification code, and the provider historical file entry), the FUKC, and the session codes. The parameters and session codes are now ready to be processed. Preferably,processor 30 processes the parameters and session codes by encrypting (by executing modules 56) the EAA, the EKE identification code, the provider historical file entry, the FUKC, and the session codes using the CSKC as the encryption key. Preferably, the user device file name is left unencrypted.

As an option that would conform with the digital signature standard (DSS) set forth by the National Institute of Standards and Technology (NIST), the identification information, before being encrypted using the CSKC, may be first encrypted using the digital signature algorithm (DSA) proposed by the NIST. If this is done, then the identification information will be double-encrypted when encrypted using the CSKC. The identification information, processed in this manner, will serve as the digital signature of theuser device 16, compliant with the federal standard.

Once the parameters and session codes are processed,processor 30packages 484 the processed parameters and session codes using the proper protocol. Step 484 is preferably carried out by executingcommunications modules 58 and specifying a particular protocol to be used. Once packaged, the information is ready to be sent to thePAS 18.

At this point,processor 30queries 485 the user as to whether delayed transmission mode is desired. If delayed transmission mode is desired, then it means that the processed information should not be sent to thePAS 18 at this time but instead should be stored infile 166 for later transmission. In such a case,processor 30stores 486 the processed parameters and session codes intofile 166 of theEKE 14, sets 487 the delayed transmission flag, and thereafter transfers control 488 back to the UAS-EKE control portion 1142 of theRAM 40.

On the other hand, if delayed transmission mode is not desired, thenprocessor 30 sends 490 the processed parameters and session codes to thePAS 18 via thecommunications interface 34, and then waits 490 for a response.

The flow of operation now switches to thePAS 18. With reference to FIGS. 10 and 12, the operation ofPAS 18 will now be described. As mentioned above,processor 400 executescontrol program 408 to carry out the recognition and comprehension functions of thePAS 18. Under control ofprogram 408,processor 400 receives 510 the transmission from theuser device 16 via thePAS communications interface 404. Once the transmission is received,processor 400 executes 512 thecommunications modules 410 to disassemble the transmission using the proper protocol. The protocol used is dictated bycontrol program 408. After the transmission is disassembled,processor 400 extracts 514 from the transmission the user device file name. Recall that the user device file name was preferably left unencrypted byuser device 16; hence, it need not be processed to be understood. Also recall that the user device file name uniquely identifies theuser device 16 to thePAS 18, and that all of the parameters associated withuser device 16 are stored instorage device 406 in a user file having the user device file name as a name. Therefore, using the user device file name as a reference or an index,processor 400 should be able to access 516 the recognition and comprehension parameters corresponding to thespecific user device 16. Note, however, that if none of the user files stored in thestorage device 406 have the user device file name as a file name, then it means that theuser device 16 is an unrecognized device. In such a case,processor 400 preferably terminates communication with theuser device 16 to prevent unauthorized access to the provider.

Assuming that one of the user files instorage device 406 has the user device file name as a file name, then the recognition and comprehension parameters corresponding to theuser device 16 are accessed. Once the parameters are accessed,processor 400 proceeds to derive 518 a current session key code (CSKC) for use in processing the processed parameters and session codes. Preferably, the CSKC is derived by combining a current user key code (CUKC) stored in the user file with a current provider key code (CPKC) stored in the user file. If all is set up and functioning properly, the CUKC and the CPKC stored in the user file at thePAS 18 should be the same as the CUKC and the CPKC stored on the EKE 14 (in encrypted form). Hence, the CSKC derived byprocessor 400 should be the same as that used by theuser device 16. After the CSKC is derived, the processed parameters and session codes are processed 520 using the CSKC. Preferably, instep 520,processor 400 executes theencryption modules 412 to decrypt the processed parameters and session codes using the CSKC as the decryption key. If the DSA option was implemented by theuser device 16, thenprocessor 400 will further decrypt the identification information using the DSA. Once the processed parameters and session codes are decrypted, the EKE identification code, the EAA, and the provider historical file entry are compared 522 with the reference EKE identification code, the reference EAA, and the reference historical file entry stored in the user file. Only if these parameters are consistent with their corresponding reference parameters will recognition be established.

If recognition is not established the first time,processor 400 preferably grants theuser device 16 several more chances to properly identify itself. If after several attempts recognition is not established, thenprocessor 400 implements 525 its default routine. Ideally, communication between theuser device 16 and thePAS 18 should be terminated immediately if thePAS 18 does not recognize theuser device 16. However, because communications channels are not perfect media, information will sometimes be lost or corrupted on the channels. Hence, theuser device 16 may not have properly received update information sent by thePAS 18 in a previous session. To make allowances for such imperfections,PAS 18 grants theuser device 16 an alternative (default) method by which to identify itself. Instep 525,processor 400 preferably sends a special code to theuser device 16 to invoke default mode. Preferably included with this special code are three requests: (1) a request that theuser device 16 retrieve some information that is unique to the user device 16 (this information may include parameters from both the last complete and incomplete sessions, for example); (2) a request to process this information using the default key code; and (3) a request to send the processed information to thePAS 18.

In response to the special code and to the requests, theuser device 16 implements its default procedures 494 (FIG. 12). Preferably,user device 16 carries outstep 494 by retrieving the information requested, processing the information using the default key code infile 1262 of theRAM 40, and sending the processed information to thePAS 18 for verification. Preferably, the requested information is encrypted using the default key code as the encryption key.

Upon receiving the alternate transmission from theuser device 16,processor 400 of thePAS 18 decrypts the transmission using the default key code stored in the user file corresponding to theuser device 16. This default key code should be the same as that stored infile 162 of theEKE 14 if theuser device 16 is a valid device. Thereafter,processor 400 compares the information sent by theuser device 16 with reference information stored in the user file. If the two sets of information are inconsistent due to the wrong information being sent or the wrong default key code being used, thenprocessor 400 terminates 527 communication with theuser device 16. Invalid user devices are thus precluded from communicating with thePAS 18. On the other hand, if the two sets of information are consistent, then recognition is established and communication between theuser device 16 and thePAS 18 is allowed to continue. In such a case,PAS 18 sends a request to theuser device 16 to encrypt the FUKC and the session codes using the default key code infile 1262 of theRAM 40, and to send the encrypted information. Upon receiving the requested information from theuser device 16,processor 400 decrypts the information using the default key code stored in the user file and derives therefrom the FUKC and the session codes.Recovery 528 from a previous incomplete session is thus achieved.

Once recognition is established betweenuser device 16 andPAS 18,processor 400 proceeds to step 529 to determine whether any of the session codes received from theuser device 16 requires an accompanying DPIN. For each set of session codes which requires a DPIN,processor 400checks 548 for whether a DPIN has been included. If not, then the session codes are disregarded 556. If a DPIN is included, thenprocessor 400 determines 550 whether the DPIN matches the reference DPIN stored in the user file. If the DPIN's do not match, the session codes are disregarded. However, if the DPIN's do match, thenprocessor 400 proceeds to check 552 for an instruction to change a DPIN. If a proper "change DPIN" instruction including a new DPIN is found, thenprocessor 400 replaces the old DPIN with the new DPIN.

Processor 400 thereafter proceeds to step 530 to either process the session codes or to relay the session codes to a separate provider processing device (not shown). Whether thePAS 18 processes the session codes or relays the session codes to another device is a matter of design choice. If the session codes are processed byPAS 18, thenprocessor 400 executes the sessioncode processing module 410 to carry out the processing function. The steps taken in processing the session codes will vary greatly from application to application. Regardless of whether thePAS 18 processes or relays the session codes, once the session codes are processed, a set of confirmation codes is generated. These confirmation codes may include updates to the userhistorical file 164 on theEKE 14, remote privileges to be stored infile 168 of theEKE 14, and updates to the providerhistorical file 170 on theEKE 14. Preferably, all remote privileges and updates to the providerhistorical file 170 are encrypted using a secret provider key code which is unknown to the user device. This ensures that theuser device 16 will not be able to access, alter, or comprehend this information. This aspect of the invention is especially useful for the providerhistorical file 170. Since neither the user nor theuser device 16 can access or alter the information contained infile 170, this file can be used as an objective record to resolve account disputes. At this point, it should be noted that each provider historical file update sent by the provider contains two parts: a substantive update portion and a corresponding entry designation. As noted above, the substantive update portion is preferably encrypted using a secret provider code. However, the corresponding entry designation is preferably not encrypted using the secret provider code. This is done to allow theuser device 16 to understand and to manipulate the entry designation.

After the confirmation codes are generated,processor 400 goes on to update 534 the recognition and comprehension parameters. Preferably,step 534 is carried out by first storing in the user file instorage 406 the FUKC received from the user device. Along the same line,processor 400 also generates and stores a future provider key code (FPKC) in the user file. Preferably, the FPKC is generated by executing theencryption modules 412, using its random number generating capabilities. These future key codes FUKC, FPKC will be used by theuser device 16 and thePAS 18 to derive key codes used in a future communication session between the two devices. In addition,processor 400 preferably further generates a new provider historical file entry designation. This new entry designation indicates to theuser device 16 which provider historical file entry to send as identification information in the future communication session.

After the FPKC and the new entry designation are generated, and after the future key codes (FUKC, FPKC) are stored,processor 400 goes on to derive a new user device file name. This new user device file name, which preferably is unique, will be used by theuser device 16 to identify itself to thePAS 18 in a subsequent communication session. Hence, the user device file name used in the current session will not be valid in the future session. Once the new user device file name is derived,processor 400 changes the name of the user file, wherein all of the parameters corresponding to theuser device 16 are stored, to the new user device file name. This ensures that when the new user device file name is used as a reference or index in a subsequent session, all of the parameters corresponding to theuser device 16 will be found. In addition to the key codes and the user device file name,processor 400 may also update the EAA associated with theuser device 16. Once that is done, the updating process is complete.

Afterstep 534,processor 400 begins preparing a return transmission to the user device.Processor 534 begins the preparation process by placing 536 the various portions of the return transmission into the proper recognition and comprehension sequence. Any desired sequence may be used, but in the preferred embodiment, the user device file name used in the current session is placed first, followed by the confirmation codes, the FPKC, the new user device file name, the new EAA, and the new entry designation. Positioned in the proper sequence, the message components are now ready to be processed 538.

Preferably,processor 400 carries out theprocessing step 538 by encrypting (by executing modules 412) all of the message components using a new current session key code. This new current session key code is preferably derived by combining the FUKC and the CPKC stored in the user file. Once the message components are encrypted using the new current session key code as the encryption key, thenprocessor 400 executes thecommunications control module 410 to assemble the encrypted message components using the proper protocol. Thereafter,processor 400 sends 540 the assembled message components to theuser device 16 via thecommunications interface 404. The flow of operation now switches back to theuser device 16.

Referring again to FIG. 11, when the return message from thePAS 18 is received 496 by theuser device 16 via thecommunications interface 34, theprocessor 30 begins processing 496 the return message. Preferably,processor 30 carries outstep 496 by first executing thecommunications modules 58 to disassemble the message using the proper protocol. Thereafter,processor 30 decrypts the return message using a new current session key code. Preferably,processor 30 derives the new current session key code by combining the FUKC stored infile 1258 of theRAM 40 with the CPKC stored infile 1260 of theRAM 40. Once the return message is decrypted using the new current session key code,processor 30 extracts a decrypted user device file name therefrom and compares 498 this file name with the user device file name stored infile 1254 of theRAM 40. If the file names are not consistent, then recognition is not established; hence,processor 30disregards 499 the return message.

On the other hand, if the file names are consistent, thenprocessor 30 goes on to update 500 the recognition and comprehension parameters and the historical files. More specifically,processor 30 stores the new user device file name, the new EAA, and the FPKC received from thePAS 18 intofiles 1254, 1256, and 1260 of theRAM 40, respectively. In addition,processor 30 stores the new entry designation. Furthermore,processor 30 stores user updates into the userhistorical file 1264, stores encrypted provider updates into the providerhistorical file 170, stores the entry designations corresponding to the encrypted provider updates intofile 1270, and stores any encrypted remote privileges into the remoteprivilege authorization file 168 of theEKE 14. The updating process is thus complete. The current communication session between theuser device 16 and thePAS 18 is also complete. Hence,processor 30transfers 502 control back to the UAS-EKE control portion 1142.

The next time theuser device 16 communicates with thePAS 18, the same general process shown in FIGS. 11 and 12 will be implemented. However, note that in the next communication session, different recognition and comprehension parameters will be used. In particular, the new user device file name will be used by theuser device 16 to identify itself to thePAS 18. Also, the new EAA will be sent to thePAS 18 instead of the EAA used in this past session. In addition, a different provider historical file entry, indicated by the new entry designation, will be sent to thePAS 18. Furthermore, the session key code which will be used to process the parameters and session codes will be derived by combining the future user key code (FUKC) and the future provider key code (FPKC) stored infiles 1258 and 1260 of theRAM 40, respectively. The same updated parameters are preferably also stored in the user file stored in the PAS storage device 406 (assuming that the previous session was properly completed); hence; theuser device 16 and thePAS 18 will be able to recognize and comprehend one another. In the manner described above, theuser device 16 and thePAS 18 of the present invention are able to effect secure communication through a general purpose communications link.

User Device-PAS Operation Using Public Key Exchange Scheme

Thus far, the invention has been described as implementing a communication methodology wherein a single current session key code is used both to encrypt and to decrypt information transferred between theuser device 16 and thePAS 18. While this methodology is effective, there are other methodologies which may be used. One possible alternative methodology involves the use of a public key exchange (PKE) scheme. The basic concept underlying the PKE scheme is that a key code may be split into two portions: a public portion and a private portion. The public portion is used to encrypt information, while the private portion is used to decrypt the encrypted information. Important points to note are that: (1) the public portion of the code cannot be used to decrypt the encrypted information; and (2) it is extremely difficult to derive the private portion given just the public portion. Thus, under the PKE scheme, a number of different components can have and use the public portion of the code to encrypt information, but only a component having the private portion of the code can decrypt and, thus, understand the information. Such an encryption scheme can be implemented advantageously in the system of the present invention.

Insystem 10, a PKE scheme is implemented preferably by using two public/private codes. First, a user code, having a public portion and a private portion, is used to communicate with theuser device 16. Specifically, the public portion of the user code is used by thePAS 18 to encrypt information sent to theuser device 16, while the private portion of the user code is used by theuser device 16 to decrypt information received from thePAS 18. Second, a provider code, also having a public and a private portion, is used to communicate with thePAS 18. In particular, the public portion of the provider code is used by theuser device 16 to encrypt information sent to thePAS 18, while the private portion of the provider code is used by thePAS 18 to decrypt information received from theuser device 16. These two public/private codes are preferably updated in accordance with the teachings of the present invention to enhance the security of the system. To ensure that theuser device 16 and thePAS 18 will be able to understand each other in an initial communication session, code portions are preferably pre-stored in both components. Specifically, the private portion of the user code and the public portion of the provider code are preferably pre-stored infiles 158 and 160, respectively, of theEKE 14. Likewise, the public part of the user code and the private part of the provider code are preferably pre-stored in the user file corresponding to theuser device 16 in thestorage 406.

In order to implement a PKE scheme insystem 10 of the present invention, the user device-PAS control portion 1144 (FIG. 9b) and the recognition and comprehension control program 408 (FIG. 10) will need to be modified. Preferably,portion 1144 takes the new form shown in FIG. 13, andprogram 408 takes the new form shown in FIG. 14. Note that the flow diagram of FIG. 13 is substantially similar to that of FIG. 11, and that the flow diagram of FIG. 14 is substantially similar to the flow diagram of FIG. 12. This similarity arises from the fact that for the most part, the functions performed bycontrol programs 1144, 408 remain the same for the public/private key code embodiment. The only difference is that information is exchanged in a different manner.

With reference to FIGS. 13 and 14, the exchange of information insystem 10 using public/private codes will now be described in detail. As stated previously,user device 16 commences interaction with thePAS 18 by havingprocessor 30 execute the user device-PAS control portion 1144. Under control ofportion 1144,processor 30 begins the interaction process by checking 600 for the update flag. If the update flag is not set, thenprocessor 30 proceeds to step 610. However, if the update flag is set, then it means that delayed transmission mode was invoked in a previous session, which in turn means that there is a return message from thePAS 18 stored infile 167 of theEKE 14 which requires processing. In such a case,processor 30 carries outstep 602 to process the stored message. Specifically,processor 30 retrieves a current user private code (CUPRC) fromfile 1258 of the RAM 40 (which represents the private portion of the current user code), and uses this CUPRC to decrypt the return message from thePAS 18. Once the return message is decrypted (and thereafter preferably purged from file 167),processor 30 extracts a user device file name therefrom and compares 604 the extracted file name to the user device file name stored infile 1254 of theRAM 40. If the two file names are not consistent, then recognition is not established. Hence, the return message is disregarded 606. On the other hand, if the two file names are consistent, thenprocessor 30 goes on to update 608 the recognition and comprehension parameters and the historical files using the decrypted information fromfile 167. The parameter updates may include storing a new user device file name infile 1254, storing a future provider public code infile 1260, and possibly some other updates. After updating theuser device 18,processor 30 proceeds to step 610 to carry out its regular preparation functions.

Instep 610,processor 30 determines whether the user wishes to prepare a transmission for sending to thePAS 18. This determination is preferably made by soliciting a response from the user. If transmission preparation is not desired, thenprocessor 30transfers 619 control back to the UAS-EKE control portion 1142. However, if the user wishes to prepare a transmission for thePAS 18, thenprocessor 30 proceeds to step 613 to check for the "pause mode" flag. If this flag is set, then it means that session codes from a previous session are stored infile 166 of theEKE 14. In such a case,processor 30 preferably retrieves 614 (and thereafter purges) the session codes fromfile 166 so that the previously generated session codes may be used in the current session. If the "pause mode" flag is not set, thenprocessor 30 skips step 614 and proceeds to step 615.

Instep 615,processor 30 executes theapplication portion 145 of the provider-specific software 141 to allow the user to generate session codes to send to thePAS 18. Afterstep 615 is implemented,processor 30 queries 616 the user as to whether the user wishes to invoke pause mode. If so, thenprocessor 30stores 617 the already generated session codes intofile 166 of theEKE 14, sets 618 the "pause mode" flag, and thereafter transfers 619 control back to the UAS-EKE control portion 1142. On the other hand, if the user does not want to invoke pause mode, thenprocessor 30 proceeds to step 624, wherein theprocessor 30 retrieves selected recognition parameters from theRAM 40. These parameters include the user device file name stored infile 1254 and at least one set of identification information. In the preferred embodiment, the identification information includes the EKE identification code, the EAA, and a selected entry from the providerhistorical file 170. This identification information is included for recognition purposes.

After retrieving the recognition parameters,processor 30 executes the encryption modules 56 to generate 628 a future user code. This user code preferably includes a public portion, referred to as the future user public code (FUPUC) and a private portion, referred to as the future user private code (FUPRC). The FUPRC is stored infile 1258 for future reference, while the FUPUC will be sent to thePAS 18. These future codes will be used in a future communication session to achieve comprehension with theuser device 16. Once the future user key code is generated,processor 30 executes 632 thecommunications modules portion 146 of the provider-specific software 141. As noted previously,portion 146 causes the session codes to be organized in a manner expected by thePAS 18.

Afterstep 632,processor 30 proceeds to step 640 to process the parameters and key codes. Instep 640,processor 30 preferably first places the parameters and session codes into proper order. In the preferred embodiment, the user device file name is placed at the beginning of the sequence, followed by the identification information, the session codes, and the FUPUC, Once properly sequenced, the message components are processed 640. Preferably,processor 30 processes the parameters and session codes by first retrieving a current provider public code (CPPUC) fromfile 1260 of theRAM 40, which represents the public portion of the current provider code used by thePAS 18. Thereafter,processor 30 preferably uses the CPPUC as an encryption key to encrypt all of the message components except for the user device file name. Preferably, encryption is carried out by executing the encryption modules 56. As an option, to conform with the NIST's digital signature standard, the identification information may be encrypted using the DSA before being encrypted using the CPPUC. If this option is chose, then the identification information will be double-encrypted when sent to thePAS 18. The identification information thus processed will serve as the digital signature of theuser device 16. After the message components are processed,processor 30 executes thecommunications module 58 to package 644 the processed message components using the proper protocol. Afterstep 644, the information packet is ready to be sent to thePAS 18.

At this point,processor 30 prompts the user to determine whether the user wishes to invoke delayed transmission mode. If so, thenprocessor 30stores 648 the information packet intofile 166 for subsequent transmission to thePAS 18, sets 649 the delayed transmission flag, and transfers 650 control back to the UAS-EKE control portion 1142. On the other hand, if delayed transmission mode is not desired, thenprocessor 30 sends 652 the information packet to thePAS 18 via thecommunications interface 34 and waits for a response. The flow of operation now switches to thePAS 18.

Referring now to FIG. 14, thePAS processor 400, under control of the recognition andcomprehension control program 408, receives 700 the information packet from theuser device 16 via the communications interface. Upon receiving the packet,processor 30 executes thecommunications module 410 to disassemble the packet using the proper protocol. Once the packet is disassembled,processor 400 extracts 708 the unencrypted user device file name from the packet and, using this user device file name as a reference, theprocessor 400 accesses 712 the user file instorage 406 corresponding to theuser device 16. This user file contains all of the relevant recognition and comprehension information for theuser device 16. Once the user file is accessed,processor 400 retrieves a current provider private code (CPPRC) from the user file, and uses this CPPRC to process 716 the information in the packet. Preferably, instep 716,processor 400 executes theencryption modules 412 to decrypt the information in the packet using the CPPRC as the decryption key. If the DSA option was implemented by theuser device 16, thenprocessor 400 will further decrypt the identification information using the DSA. After the information is decrypted, the identification information included in the packet is compared 720 with reference identification information stored in the user file. More specifically, the EKE identification code is compared with a reference identification code, the EAA is compared with a reference EAA, and the provider historical file entry is compared with a reference file entry. If the two sets of identification information are consistent, then recognition is established. Otherwise,processor 400 grants theuser device 16 several more chances to identify itself. If after these additional opportunities recognition is still not established, thenprocessor 400 preferably carries out its default/recovery procedure 726-729. Steps 726-729 are substantially the same as steps 525-528 previously described; hence, they need not be described again here. Also, the default procedure implemented by theuser device 16 in step 658 (FIG. 13) is substantially the same as that implemented instep 494, which was previously described. Thus, step 658 need not be described again here.

Once recognition is established,processor 400 proceeds to step 730 to determine whether any of the session codes received from theuser device 16 requires an accompanying DPIN. For each set of session codes which requires a DPIN,processor 400checks 732 for whether a DPIN has been included. If not, then the session codes are disregarded 734. If a DPIN is included, thenprocessor 400 determines 736 whether the DPIN matches the reference DPIN stored in the user file. If the DPIN's do not match, the session codes are disregarded. However, if the DPIN's do match, thenprocessor 400checks 738 for an instruction to change a DPIN. If a proper "change DPIN" instruction is found, thenprocessor 400 replaces 740 the old DPIN with the new DPIN included in the "change DPIN" instruction.

Thereafter,processor 400 proceeds to step 742 to either process the session codes or to relay the session codes to a separate provider processing device (not shown). Whether theprocessor 400 processes or relays the session codes is a matter of design choice. If theprocessor 400 is responsible for processing the session codes, then it executes the sessioncode processing program 414 to carry out this function. Regardless of whether thePAS 18 processes or relays the session codes, once the session codes are processed, a set of confirmation codes is generated. Preferably, the confirmation codes contain information such as updates to the user historical file, encrypted (using provider encryption unknown to the user) updates to the provider historical file, and encrypted (using provider encryption unknown to the user) remote privileges to be stored infile 168.

Once the confirmation codes are derived 746,processor 400 begins updating 750 the recognition and comprehension parameters. A number of operations are performed instep 750. First,processor 400 generates a future provider code having a public portion, referred to as the future provider public code (FPPUC), and a private portion, referred to as the future provider private code (FPPRC). These future codes FPPUC, FPPRC will be used in a subsequent communication session to achieve comprehension with thePAS 18. The FPPRC is preferably stored in the user file for future reference by theprocessor 400, While the FPPUC is sent as an update to theuser device 16. Also, instep 750,processor 400 stores the FUPUC received from theuser device 16 in the user file for future reference. This future code will be used to encrypt a future message to the user device. In addition, instep 750,processor 400 generates a new user device file name to be used by the user device in a subsequent session to identify itself to thePAS 18. Once the new user device file name is generated,processor 400 changes the name of the user file to the new user device file name. This ensures that when the new user device file name is later used as a reference, the proper user file will be accessed. Furthermore, a new EAA may be generated. Finally, instep 750, processor preferably sets a new entry designation for theuser device 16. Recall that in identifying itself to thePAS 18, theuser device 16 sends a designated entry of the provider historical file to thePAS 18 as identification information. Changing the entry designation will cause the user device to send a different set of identification information in the next session. Hence, the identification information is indirectly changed and updated.

Afterstep 750,processor 400 begins preparing a return message to theuser device 16. First,processor 400places 754 all of the message components into the proper recognition and comprehension sequence. Preferably, the user device file name is placed first in the sequence, followed by the confirmation codes, the FPPUC, the new user device file name, the new EAA, and the new entry designation. Once in the proper sequence, the message components are processed 758 using a current user public code (CUPUC) stored in the user file. Preferably, instep 758,processor 400 executes theencryption modules 412 to encrypt the message components using the CUPUC as the encryption key. After the message components are processed,processor 400 executes thecommunication module 410 to package the return message components using the proper protocol. Thereafter, the return message is sent 762 to the user device via thecommunications interface 404. The flow of operation now switches back to theuser device 16.

Referring again to FIG. 13,processor 30 of theuser device 16 receives the return message from thePAS 18 via thecommunications interface 34. Upon receipt of the return message,processor 30 beginsprocessing 662. Preferably,processor 30 processes the return message by first executing thecommunication modules 58 to disassemble the return message using the proper protocol. Once the message is disassembled,processor 30 decrypts the message components using a current user private code (CUPRC) stored infile 1258 of theRAM 40. After the message is decrypted, theprocessor 30 extracts the user device file name from the message, and compares 666 it to the user device file name stored infile 1254 of theRAM 40. If the two file names are not consistent, then recognition is not established; hence, the return message is disregarded 668. On the other hand, if the two file names are consistent, thenprocessor 30 proceeds to update 670 the parameters and historical files. More particularly,processor 30 stores the new device file name intofile 1254 of theRAM 40, and the new EAA intofile 1256. Also,processor 30 stores the FPPUC received from thePAS 18 intofile 1260 for future reference. In addition,processor 30 stores user historical updates intofile 1264, provider encrypted historical updates intofile 170, and encrypted remote privileges intofile 168. Finally,processor 30 stores the new entry designation received from thePAS 18. This new designation will be used in the next communication session to determine which entry of the providerhistorical file 170 to send to thePAS 18 as identification information. After updating theuser device 16 as described, the current communication session is completed. Thus, control is transferred 674 back to the UAS-EKE control portion 1140.

In the next communication session between theuser device 16 and thePAS 18, the same general sequence of operation as that described in connection with FIGS. 13 and 14 will take place. However, in the next session, different recognition and comprehension parameters will be used. Specifically,user device 16 will identify itself using the new user device file name instead of the user device file name used in this past session. A different set of identification information will be sent to thePAS 18, including a new EAA and a different provider historical file entry. Theuser device 16 will use the FPPUC to encrypt the information sent to thePAS 18. ThePAS 18 will use the FPPRC to decrypt the information received from theuser device 16. ThePAS 18 will use the FUPUC to encrypt the return message to theuser device 16. Finally, theuser device 16 will use the FUPRC to decrypt the return message from thePAS 18. As shown by the above description, thesystem 10 of the present invention is quite dynamic. This dynamic nature, combined with the implementation of the unique recognition and comprehension methodologies, makes thesystem 10 highly secure. This high level of security in turn makes it possible to conduct important transactions via a general purpose communications link. This desirable result was not realistically achievable with the prior art systems. Hence, the present invention provides a significant improvement over the prior art.

Representative Applications of the Present Invention

As noted above, one of the major advantages of the present invention is that it can be implemented in a wide variety of applications to achieve a wide variety of purposes. To illustrate the versatility of the invention, several representative applications will now be described. Overall, the invention may be applied to at least three broad categories of systems: (1) communications systems; (2) transactional systems; and (3) authorization systems. As used herein, a communications system refers to a system wherein two devices exchange information via a communications link, a transactional system refers to a system wherein two devices cooperate to complete one or more transactions via a communications link, and an authorization system refers to a system wherein a requesting device receives authorization from a coordinating device via a communications link. As defined, these categories are not mutually exclusive; hence, some of the systems described below may fall within more than one of these categories.

Communications Applications

One of the communications systems in which the present invention may be implemented is a personal message management system. A block diagram of such asystem 1300 is shown in FIG. 15, comprising auser sending device 1302, a pagingservice provider PAS 1304, and auser receiving device 1306. Insystem 1300,user sending device 1302 generates a message for thereceiving device 1306, and thereafter passes the message on to thePAS 1304. In turn, thePAS 1304 processes the message and passes it on to theappropriate receiving device 1306. No human intervention is needed. To generate a message, theuser sending device 1302 is first formed by coupling thesender UAS 1310 to thesender EKE 1312. Preferably, whendevices 1310 and 1312 are coupled together, they implement the recognition and comprehension methodologies of the present invention to ensure that they are authorized to interact with each other. Once it is determined that thedevices 1310, 1312 may interact, a message is generated using theuser sending device 1302. This message may be encrypted in accordance with an encryption key which is pre-established between the sendingdevice 1302 and thereceiving device 1306. Encrypting the message in this manner ensures that the service provider will not be able to understand the message. Once the message is generated and encrypted, the sendingdevice 1302 passes the message on to thePAS 1304. Preferably, the recognition and comprehension methodologies described above with regard touser device 16 andPAS 18 are implemented betweendevices 1302 and 1304. This serves: (1) to verify that thedevices 1302, 1304 are authorized to communicate with one another; and (2) to ensure that communication between the sendingdevice 1302 and thePAS 1304 is secured. Note that by the time the message arrives at thePAS 1304, the message has been double-encrypted. It was first encrypted using the encryption key established betweendevice 1302 and 1306. It was double-encrypted using an encryption key pre-established betweendevice 1302 and thePAS 1304.

When thePAS 1304 receives the message from sendingdevice 1302, it carries out the recognition and comprehension methodologies of the present invention to determine whether the sendingdevice 1302 is a recognized or valid device. Once the pagingservice provider PAS 1304 determines that sendingdevice 1302 is a recognized device, it decrypts the message from the sendingdevice 1302 using the encryption key pre-established between the sendingdevice 1302 and thePAS 1304. Thereafter, thePAS 1304 reencrypts the message using an encryption key pre-established between thePAS 1304 and thereceiving device 1306. After this procedure, the message is again double encrypted. More particularly, the message carries both the encryption imposed by the sendingdevice 1302, and the encryption imposed by thePAS 18. Thereafter,PAS 1304 relays the double encrypted message to thereceiver EKE 1314 of thereceiving device 1306. In the preferred embodiment, thereceiver EKE 1314, in addition to being a regular EKE, further comprises areceiving mechanism 1318 for receiving and storing the message from thePAS 1304. The receiving mechanism may be a standard receiving mechanism, such as that found on currently available pagers. Once received, the message is stored onEKE 1314 for subsequent reference.

To read the message from the sendingdevice 1302, thereceiver EKE 1314 is coupled to thereceiver UAS 1316. Preferably, the recognition and comprehension methodologies described above in connection withUAS 12 andEKE 14 are carried out betweendevices 1314 and 1316 to verify that the devices are authorized to interact. Once authorization is verified, thereceiving device 1306 decrypts the message by first using the encryption key pre-established between thePAS 1304 and thereceiving device 1306, and then by using the encryption key pre-established between the sendingdevice 1302 and thereceiving device 1306. Once decrypted, the message is read by the user via the display of thereceiver UAS 1316. The message is thus conveyed from the sender to the receiver. In the manner described, thesystem 1300 of FIG. 15 allows a message to be securely sent from one user to another with no human intervention.

Another communications system in which the present invention may be implemented is an electronic polling management system. Such asystem 1320 is shown in FIG. 16, comprising apolling device 1322, formed by apolling UAS 1326 and apolling EKE 1328, and apolling management PAS 1324. In thesystem 1320 of FIG. 16, it is envisioned that thePAS 1324 will be managed and operated by a polling authority, and that thepolling EKE 1328 will be provided by the polling authority containing all of the necessary information and software. Preferably, eachpolling EKE 1328 is assigned to one and only one voter and is uniquely recognizable by thePAS 1324. This ensures that each voter can vote only once in each poll or election.

Insystem 1320, to cast a vote, a voter inserts thepolling EKE 1328 into hisown UAS 1326. Preferably,devices 1326 and 1328 implement the recognition and comprehension methodologies of the present invention to verify that the devices are authorized to interact with each other. After it is determined that the devices are authorized to interact, theUAS 1326 runs the balloting software on thepolling EKE 1328 to allow the voter to enter his vote or votes. Once the votes are entered, thepolling device 1322 processes and sends the polling information on to thePAS 1324 via the communications link. Preferably, in processing and sending the polling information, thepolling device 1322 implements the recognition and comprehension methodologies of the present invention. When the processed polling information is received by thepolling management PAS 1324, thePAS 1324 in turn implements the recognition and comprehension methodologies of the present invention. More specifically,PAS 1324 determines whether thepolling device 1322 is a valid device. If so, thenPAS 1324 decrypts the polling information using an encryption key pre-established between thepolling device 1322 and thePAS 1324 to extract the original polling information therefrom. Once decrypted, the polling information is entered and properly processed. In the manner described, thesystem 1320 of FIG. 16 allows a voter to vote securely from a remote location.

At this point, it should be noted that insystem 1320, thesame polling EKE 1328 may be used over and over again to vote in multiple polls and elections. This is because the polling information sent by thepolling device 1322 to thePAS 1324 is just a series of alpha or numeric choices. No poll-specific or election-specific information is included in the transmission or in thepolling EKE 1328. Instead, thePAS 1324 ascertains what each choice from thepolling device 1322 represents by consulting the official ballot published for that particular poll or election. The voter enters his choices into thepolling device 1322 using the same official ballot. Thus, by using the official ballot as a common reference, theuser device 1322 and thePAS 1324 are able to understand one another. In the next poll or election, a different official ballot will be published; thus, each choice from thepolling device 1322 will represent a different vote for a different matter. By using the official ballot as the election reference guide, no election-specific or poll-specific information will need to be installed on thepolling EKE 1328. As a consequence, thesame polling EKE 1328 can be used for each and every poll or election. All that needs to be newly provided for each poll or election is the official ballot. By setting thesystem 1320 up in this manner, component costs are kept to a minimum.

Transactional Applications

The present invention may also be applied to transactional systems. A transactional system in which the present invention is implemented is shown in FIG. 17. The personalbanking management system 1340 of FIG. 17 is quite similar to the basic system to shown in FIG. 1, comprising a user UAS 1344 and a user EKE 1346 (which together form the overall user device 1342), and aninstitution PAS 1348. Insystem 1340, it is envisioned that thePAS 1348 is managed and operated by a financial or securities institution, and that theuser EKE 1346 is provided by the institution containing all of the information and software needed to communicate with theinstitution PAS 1348.

In general,system 1340 operates in much the same manner as thebasic system 10 described above. Particularly, theuser EKE 1346 couples to the user UAS 1344 to form theoverall user device 1342 which communicates with theinstitution PAS 1348. Before operating as a unit, however,devices 1344 and 1346 implement the recognition and comprehension methodologies of the present invention to verify that they are authorized to interact, to decrypt the encrypted information stored on theuser EKE 1346, to perform file management functions, and to dynamically update the recognition and comprehension parameters. Once recognition and comprehension is achieved,devices 1344 and 1346 operate as a unit to communicate with thePAS 1348. Preferably,user device 1342 andPAS 1348 cooperate to carry out the recognition and comprehension methodologies of the present invention to determine whether theuser device 1342 and thePAS 1348 are authorized to transact, and to ensure that communication between the devices is secure. In addition, thedevices 1342, 1348 cooperate to dynamically update the recognition and comprehension parameters. These aspects of the invention were previously described and need not be described again here.

Assuming that all of the proper components are used and that recognition and comprehension is established among all of the components, a user can remotely access hisaccount using system 1340 by sending an encrypted transaction address (EAA) to thePAS 1348. This EAA will be decrypted by the provider to derive an encrypted transaction address (ETA). This ETA, when derived, grants access to themain file 1350 in thePAS 1348 in which all of the account information pertaining to the user is stored. The ETA file may have a DPIN associated therewith, in which case, the user will need to provide a DPIN along with the ETA in order to access the main file. As shown in FIG. 17, contained in the main file may be a plurality of sub-files 1352(a)-1352(n), with each sub-file having an associated sub-address and possibly a DPIN. These sub-files may represent different sub-accounts within the main file, such as a checking account, a savings account, a credit card account, or a dynamicmoney line account 1354. To access these sub-files, the user will need to provide the sub-address and the DPIN for each accessed sub-file. Once the sub-files are properly accessed, the user may manipulate the accounts as he wishes, including transferring funds from one sub-account to another. Among the parameters that a user can manipulate are the DPIN's. The user can change any or all of the DPIN's by sending the proper instructions to thePAS 1348.

An interesting and useful aspect of thesystem 1340 of FIG. 17 is the direct money line account (DMLA) 1354. In the preferred embodiment, this account is used as the base account for a direct money line card (DMLC), which may be used in the same manner as a debit card. Each time the DMLC is used, the DMLA is accessed and funds are deducted therefrom. To increase the amount that can be spent using the DMLC, a user simply needs to transfer more funds from one or more of the other sub-accounts into theDMLA 1354. Conversely, to limit the amount that can be spent using the DMLC, a cap amount can be placed in the DMLA. This aspect of the invention is quite useful for imposing limits on the amount of money that can be spent by an individual using the DMLC. In addition to absolute spending limits, several other parameters may also be imposed on the DMLA. For example, a maximum amount per period may be imposed on the DMLA to limit the amount that can be spent using the DMLC during any period of time. Also, dollar dependent DPIN's may be set in the DMLA so that in order to access larger amounts of funds, higher order DPIN's are required. In addition, a notification parameter can be set in the DMLA which dictates that when a certain condition occurs (e.g. when a certain amount of funds is withdrawn from the DMLA), thePAS 1348 pages or otherwise notifies the user. This feature is useful in notifying the user of possible fraudulent use of the DMLC. Furthermore, certain retailer code restrictions may be imposed on the DMLA so that certain items (such as liquor, firearms, etc.) cannot be purchased using the DMLC. As these examples illustrate, the combination of the DMLA and the DMLC gives a user a great deal of control over his liquid funds, control that is not attainable with cash. By usingsystem 1340 to manipulate the DMLA, a user can freely control, from practically anywhere, the amount of electronic cash immediately available to him through the DMLC, and the manner in which that electronic cash is used. With a DMLC, a DMLA, and the present invention, a user will no longer need to visit an ATM or to carry cash.

Once a user has an ETA established with his bank, then that ETA may be used by other parties to post transaction notices. These notices may be payment requests from creditors or deposits from debtors. Preferably, only parties which have been granted permission by the user may post notices in the user's ETA account. These account-to-account postings may be effected over normal settlement or dedicated networks in accordance with rules and conventions established by PAS operators. When a notice is posted in the user's ETA account, that posting will appear the next time the user accesses his ETA account. At that point, the user can decide whether to take action in response to the posting. More specifically, the user can decide whether to make the requested payment from one of his sub-accounts, and whether to accept the deposit into one of his sub-accounts. No action will be taken unless authorized by the user. Thus,system 1340 of the present invention offers a user the convenience of account-to-account postings without any sacrifice in security.

Insystem 1340, after a transaction is completed, thePAS 1348 generates and sends confirmation codes to theuser device 1342. These confirmation codes, which include records of the transaction, are stored as updates in both the userhistorical file 164 and the provider historical file 170 (FIG. 6) of theuser EKE 1346. These records serve as a memorial of the transaction. The userhistorical file 164 of theuser EKE 1346 can be accessed and reviewed by the user (using the user UAS 1344) at any time. Hence, the user historical file serves as a partial running statement of all of the user's accounts.

Thus far, the transactional aspect of the present invention has been described with reference to a banking system. It should be noted, however, that the present invention may be applied to many other transactional systems. For example, thesystem 1340 shown in FIG. 17 may be used to effect direct purchase transactions between consumers and product and service providers. Also,system 1340 may be used to directly effect securities transactions between investors and market operators. In addition,system 1340 may be used by users to directly manage their personal benefits portfolio without employer support. These and other transactional applications are within the scope and contemplation of the present invention.

Authorizational Applications

As mentioned above, the present invention may also be applied to authorization systems. An example of anauthorization system 1360 in which the present invention is implemented is shown in FIG. 18.System 1360 preferably comprises the three basic components of the present invention: auser UAS 1364; auser EKE 1366 which couples to the user UAS to form theoverall user device 1362; and a travelservice provider PAS 1368.System 1360 is quite similar to thetransactional system 1340 shown in FIG. 17, both in form and in configuration. Likesystem 1340,system 1360 carries out a transaction between theuser device 1362 and theprovider PAS 1368. Also likesystem 1340,system 1360 implements the recognition, comprehension, file management, and parameter updating functions of the present invention. The only difference is that at the end of a transaction, thePAS 1368 ofsystem 1360 sends an authorization code to theuser device 1362. In response, theuser device 1362 stores this authorization code in the remoteprivilege authorization file 168 of theuser EKE 1366. Armed with this authorization code, theuser EKE 1366 may thereafter be used as verification that a certain travel service has been purchased. When interfaced with a proper reading device (not shown), theuser EKE 1366 can be read to show that the service has indeed been purchased. Thus, thesystem 1360 of FIG. 18 turns theuser EKE 1366 into a general purpose ticketing device. Consequently, theuser EKE 1366 may be used as an airplane ticket, a bus ticket, a rental car voucher, a hotel voucher, or any other type of ticket or voucher. In fact, there is nothing to limitsystem 1360 to travel services. It is envisioned that theuser EKE 1366 may be used for admission to various other services and events such as movies, plays, concerts, museums, restaurants, resorts, etc. The possible applications are limitless.

In addition to being used as a means for admission, the user EKE 1366 (having an authorization code stored thereon) may also be used as an authorization device for an entertainment management system. To elaborate, it is envisioned that in the near future, a user will be able to receive a plurality of scrambled signals (representing movies, programs, music, and other forms of entertainment) through an entertainment interface (not shown) installed in his home. The user can unscramble these signals, and thus, access the entertainment materials if he can provide a proper authorization code to the entertainment interface. That is where thesystem 1360 of FIG. 18 becomes involved. By usingsystem 1360, a user can remotely transact with an entertainment provider to receive an authorization code therefrom. Once the authorization code is stored on theuser EKE 1366, theEKE 1366 is coupled to the entertainment interface. The entertainment interface, in turn, accesses the authorization code stored on theEKE 1366 and uses this code to unscramble the proper signals in the proper manner. The user is thus granted access to the desired entertainment material. As shown by this example,system 1360 gives a user the ability to access, easily and conveniently, any desired entertainment material.

FIG. 19 shows anotherauthorizational system 1370 in which the present invention may be advantageously implemented. As shown,system 1370 preferably comprises adriver UAS 1371, adriver EKE 1372, anautomobile control supervisor 1374, and a plurality of control systems commonly found in automobiles. These control systems may include aspeed control system 1376, astarter control system 1378, anelectrical distribution mechanism 1380 for controlling distribution of power to electrical components in the automobile, on-board distributedprocessors 1382 for controlling the operation of selected components in the automobile, and a fuel flow management mechanism 1384.System 1370 allows anEKE 1372 to be used as a vehicle controlling device.

To take advantage ofsystem 1370, thedriver EKE 1372 is first programmed using the driver UAS. Preferably, when theEKE 1372 is coupled to the driver UAS, the components implement the recognition and comprehension methodologies of the present invention to ensure that the components are authorized to interact with each other. Once authorization is verified, the processor in the driver UAS preferably executes a control program on thedriver EKE 1372 to generate certain control codes. Once generated, the control codes are stored into the remoteprivilege authorization file 168 of thedriver EKE 1372. TheEKE 1372 is now programmed with the codes that it will need to operate thesystem 1370. Interaction between the driver UAS and thedriver EKE 1372 is then terminated.

Thereafter, when the driver wishes to operate the automobile, the driver couples thedriver EKE 1372 to theautomobile control supervisor 1374, which may be a device situated within the console of the car. Once coupled, thecontrol supervisor 1374 reads the control codes stored withinfile 168 of thedriver EKE 1372 and controls the systems 1376-1378 in the automobile accordingly.System 1370 may be used as a convenient electronic starting mechanism (replacing ignition keys).System 1370 may also be used as a means for controlling operation of the automobile. For example, a parent may prevent a child from exceeding the speed limit by storing control codes within thedriver EKE 1372 which prohibit thespeed control system 1376 from allowing the automobile to reach a certain speed. As a further example, selected control codes may be stored in thedriver EKE 1372 to control theelectrical distribution mechanism 1380 to prevent selected components from receiving power. As yet a further example, control codes may be stored in thedriver EKE 1372 to enable or disable selected on-board processors such that certain operations, e.g. transmission shifting, fuel flow management, fuel injection control, etc., are prohibited. This and other control functions may be achieved usingsystem 1370. Overall,system 1370 provides a powerful tool for controlling the operation of an automobile.

PAS to PAS Communication

Thus far, the invention has only been described with reference to user devices communicating with PAS's. It should be noted, however, that with minor modifications, PAS's can communicate directly with each other. FIG. 20 shows asystem 1400 wherein a PAS communicates directly with another PAS, thesystem 1400 preferably comprising afirst PAS 1402 having a userdevice emulation module 1406 incorporated therein, and asecond PAS 1404 also having a userdevice emulation module 1408 incorporated therein. The PAS's 1402, 1404 shown insystem 1400 are substantially identical in construction to thePAS 18 shown in FIG. 10 except that PAS's 1402 and 1404 preferably further comprise a userdevice emulation module 1406, 1408 in theprogram memory 402. Thesemodules 1406, 1408 are executed byprocessor 400 whenever the PAS's 1402, 1404 wish to communicate directly with another PAS. Thus far,modules 1406 and 1408 have been described as software modules which are executed byprocessor 400. It should be noted, however, thatmodules 1406 and 1408 may also be implemented in hardware. This is within the contemplation of the present invention.

To describe the operation ofsystem 1400, suppose thatPAS 1402 wishes to send a message toPAS 1404. To do so, the processor inPAS 1402 executes the userdevice emulation module 1406 in the program memory to emulate the operation of a user device. Oncemodule 1406 is executed, thePAS 1402 behaves in the same manner as anormal user device 16, i.e. carries out the functions shown in FIGS. 11 and 13. More specifically,PAS 1402 cooperates with thePAS 1404 to implement the recognition and comprehension methodologies of the present invention. In addition,PAS 1402 cooperates with thePAS 1404 to dynamically update the parameters used in the recognition and comprehension methodologies. Throughout this entire process,PAS 1404 treats thePAS 1402 in the same manner as it would a normal user device. Preferably, recognition and comprehension parameters are pre-established between the PAS's 1402, 1404 so that they will be able to understand each other in their initial session. In this manner,PAS 1402 is able to communicate directly withPAS 1404.PAS 1404, by executing userdevice emulation module 1408, can communicate directly withPAS 1402 in the same manner.

As shown by this example, direct communication between PAS's can be achieved relatively simply. By incorporating a user device emulation module, quite similar to the user device-PAS control portion 144 of thePFM 140, into theprogram memory 404 of aPAS 18, a regular PAS can be transformed into one which is capable of direct PAS to PAS communication. This embodiment of the PAS will be quite useful in many applications, such as in setting accounts between different providers.

User Device to User Device Communication

Along the same line, a user device (comprising a UAS and an EKE) can also be adapted to communicate directly with another user device. Such asystem 1420 is shown in FIG. 21, comprising afirst user device 1422, formed byUAS 1426 andEKE 1428, and asecond user device 1424, formed byUAS 1432 andEKE 1434. Notice that each of the EKE's 1428, 1434 has incorporated therein aPAS emulation module 1430, 1436, respectively. In the preferred embodiment,modules 1430 and 1436 are software modules stored on the EKE's which are executed and by the processors in the UAS's 1426, 1432. If so desired, however,modules 1430 and 1436 may be implemented in hardware in the UAS's 1426, 1432. This is within the contemplation of the present invention.

When sending out messages,user devices 1422, 1424 function as normal user devices. To receive messages, however, user device 1422 (for example) executes thePAS emulation module 1430 stored WithinEKE 1428 to emulate the behavior of a PAS. When executed,module 1430 causes theuser device 1422 to perform the functions of a regular PAS. i.e. perform the functions shown in FIGS. 12 and 14. More specifically, the receivinguser device 1422 cooperates with the sendinguser device 1424 to implement the recognition and comprehension methodologies of the present invention, and to update the parameters used in the recognition and comprehension processes. To ensure that thedevices 1422, 1424 will be able understand each other in their initial communication, recognition and comprehension parameters are preferably pre-established between the devices. By executingPAS emulation module 1430,user device 1422 will be able to receive and process communications fromuser device 1424. Likewise, by executingPAS emulation module 1436,user device 1424 will be able to receive and process communications fromuser device 1422. Thus, a direct user communication system is provided.

As shown by this example, direct communication between user devices can be achieved relatively simply. By incorporating a PAS emulation module, quite similar to the recognition andcomprehension control program 408 shown in FIG. 10, into the EKE of a user device, a regular user device can be transformed into one which is capable of direct user-device-to-user-device communication. This greatly enhances the versatility of a user device.

The invention has now been fully described. While the invention has been described with reference to specific embodiments, the invention should not be construed to be so limited. Various modifications can be made by those of ordinary skill in the art with the benefit of this disclosure without departing from the spirit of the invention. For example, thePFM 140 on theEKE 14 may be stored unencrypted. That way,processor 30 may execute the PFM instructions on theEKE 14 without having to first decrypt and store the instructions in theRAM 40. This and other modifications are within the spirit of the invention. Therefore, the invention should not be limited by the specific embodiments used to illustrate it but only by the scope of the appended claims.

Claims (35)

What is claimed is:

1. A communications system, comprising:

a sending device having a device file name and a set of identification information stored therein, said sending device generating a message and encrypting said message using a first key code to derive an encrypted message, said sending device further encrypting said identification information using at least a portion of a second key code to derive a set of encrypted identification information, said sending device sending said device file name, said encrypted identification information, and said encrypted message onto a first communications link;

a provider device having a user file stored therein which contains recognition parameters corresponding to said sending device including a set of reference information, said provider device receiving said device file name, said encrypted identification information, and said encrypted message via said first communications link, said provider device accessing said user file using said device file name as an index and deriving at least a portion of said second key code from said recognition parameters, said provider device decrypting said encrypted identification information using the portion of said second key code derived from said recognition parameters to derive a set of decrypted identification information, said provider device comparing said decrypted identification information with said reference information and, in response to a determination that said decrypted identification information is consistent with said reference information, said provider device sending said encrypted message onto a second communications link; and

a receiving device for receiving said encrypted message via said second communications link and storing said encrypted message, said receiving device further decrypting said encrypted message using said first key code to derive a decrypted message.

2. The system of claim 1, wherein said sending device comprises:

a processing device comprising a processor and a communications interface coupled to said processor for forming said first communications link with said provider device; and

a storage device coupled to said processor, comprising:

a first storage unit for storing said device file name;

a second storage unit for storing said identification information;

means for causing said processor to determine whether said processing device and said storage device are authorized to interact with each other;

means for causing said processor to terminate interaction between said processing device and said storage device in response to a determination that said processing device and said storage device are not authorized to interact with each other;

means for causing said processor to generate said message;

means for causing said processor to encrypt said message using said first key code to derive said encrypted message;

means for causing said processor to retrieve said device file name and said identification information from said first and second storage units;

means for causing said processor to encrypt said identification information using at least a portion of said second key code to derive said encrypted identification information; and

means for causing said processor to send said device file name, said encrypted identification information, and said encrypted message onto said first communications link via said communications interface.

3. The system of claim 2, wherein said provider device comprises:

a provider communications interface for forming said first and second communications links, said communications interface receiving said device file name, said encrypted identification information, and said encrypted message;

a storage for storing said user file;

means for accessing said user file in said storage using said device file name as an index;

means for deriving at least a portion of said second key code using said recognition parameters;

means for decrypting said encrypted identification information using the portion of said second key code derived from said recognition parameters to derive a set of decrypted identification information;

means for comparing said decrypted identification information with said reference information stored in said user file; and

means for sending said encrypted message onto said second communications link via said provider communications interface in response to a determination that said decrypted identification information is consistent with said reference information.

4. The system of claim 3, wherein said receiving device comprises:

a second processing device comprising a second processor and a display coupled to said second processor;

a receiving mechanism for receiving said encrypted message via said second communications link; and

a second storage device coupled to said second processor and said receiving mechanism, said second storage device comprising:

a third storage unit for storing said encrypted message received by said receiving mechanism;

means for causing said second processor to decrypt said encrypted message using said first key code to derive a decrypted message; and

means for causing said second processor to display said decrypted message on said display.

5. A communications system, comprising:

a sending device having a device file name and a set of identification information stored therein, said sending device generating a message and encrypting said message using a first key code to derive a single-encrypted message, said sending device further encrypting said identification information and said single-encrypted message using at least a portion of a second key code to derive a set of encrypted identification information and a double-encrypted message, said sending device sending said device file name, said encrypted identification information, and said double-encrypted message onto a first communications link;

a provider device having a user file stored therein which contains recognition parameters corresponding to said sending device including a set of reference information, said provider device receiving said device file name, said encrypted identification information, and said double-encrypted message via said first communications link, said provider device accessing said user file using said device file name as an index and deriving at least a portion of said second key code from said recognition parameters, said provider device decrypting said encrypted identification information using the portion of said second key code derived from said recognition parameters to derive a set of decrypted identification information, said provider device comparing said decrypted identification information with said reference information and, in response to a determination that said decrypted identification information is consistent with said reference information, said provider device decrypting said double-encrypted message using the portion of said second key code derived from said recognition parameters to re-derive said single-encrypted message, said provider device thereafter sending said single-encrypted message onto a second communications link; and

a receiving device for receiving said single-encrypted message via said second communications link and storing said single-encrypted message, said receiving device further decrypting said single-encrypted message using said first key code to derive a decrypted message.

6. The system of claim 5, wherein said sending device comprises:

a processing device comprising a processor and a communications interface coupled to said processor for forming said first communications link with said provider device; and

a storage device coupled to said processor, comprising:

a first storage unit for storing said device file name;

a second storage unit for storing said identification information;

means for causing said processor to determine whether said processing device and said storage device are authorized to interact with each other;

means for causing said processor to terminate interaction between said processing device and said storage device in response to a determination that said processing device and said storage device are not authorized to interact with each other;

means for causing said processor to generate said message;

means for causing said processor to encrypt said message using said first key code to derive said single-encrypted message;

means for causing said processor to retrieve said device file name and said identification information from said first and second storage units;

means for causing said processor to encrypt said identification information and said single-encrypted message using at least a portion of said second key code to derive said encrypted identification information and said double-encrypted message; and

means for causing said processor to send said device file name, said encrypted identification information, and said double-encrypted message onto said first communications link via said communications interface.

7. The system of claim 6, wherein said provider device comprises:

a provider communications interface for forming said first and second communications links, said communications interface receiving said device file name, said encrypted identification information, and said encrypted message;

a storage for storing said user file;

means for accessing said user file in said storage using said device file name as an index;

means for deriving at least a portion of said second key code using said recognition parameters;

means for decrypting said encrypted identification information using the portion of said second key code derived from said recognition parameters to derive a set of decrypted identification information;

means for comparing said decrypted identification information with said reference information stored in said user file;

means for decrypting, in response to a determination that said decrypted identification information is consistent with said reference information, said double-encrypted message using the portion of said second key code derived from said recognition parameters to re-derive said single-encrypted message; and

means for sending said single-encrypted message onto said second communications link via said provider communications interface.

8. The system of claim 7, wherein said receiving device comprises:

a second processing device comprising a second processor and a display coupled to said second processor;

a receiving mechanism for receiving said single-encrypted message via said second communications link; and

a second storage device coupled to said second processor and said receiving mechanism, said second storage device comprising:

a third storage unit for storing said single-encrypted message received by said receiving mechanism;

means for causing said second processor to decrypt said single-encrypted message using said first key code to derive a decrypted message; and

means for causing said second processor to display said decrypted message on said display.

9. A system for voting, comprising:

a voter device having a voter file name and a set of identification information stored therein, said voter device generating a message representing at least one voting selection, said voter device encrypting said identification information and said message using at least a portion of a key code to derive a set of encrypted identification information and an encrypted message, said voter device sending said voter file name, said encrypted identification information, and said encrypted message onto a communications link; and

a voter management device having a voter file stored therein which contains recognition parameters corresponding to said voter device including a set of reference information, said voter management device receiving said voter file name, said encrypted identification information, and said encrypted message via said communications link, said voter management device accessing said voter file using said voter file name as an index and deriving at least a portion of said key code from said recognition parameters, said voter management device decrypting said encrypted identification information using the portion of said key code derived from said recognition parameters to derive a set of decrypted identification information, said voter management device comparing said decrypted identification information with said reference information and, in response to a determination that said decrypted identification information is consistent with said reference information, said voter management device decrypting said message using the portion of said key code derived from said recognition parameters to derive a decrypted message, said voter management device thereafter extracting at least one voting selection from said decrypted message and processing said one voting selection.

10. The system of claim 9, wherein said voter device comprises:

a voter processing device comprising a processor and a communications interface coupled to said processor for forming said communications link with said voter management device; and

a voter storage device coupled to said processor, comprising:

a first storage unit for storing said voter file name;

a second storage unit for storing said identification information;

means for causing said processor to determine whether said voter processing device and said voter storage device are authorized to interact with each other;

means for causing said processor to terminate interaction between said voter processing device and said voter storage device in response to a determination that said voter processing device and said voter storage device are not authorized to interact with each other;

means for causing said processor to generate said message;

means for causing said processor to retrieve said voter file name and said identification information from said first and second storage units;

means for causing said processor to encrypt said identification information and said message using at least a portion of said key code to derive said encrypted identification information and said encrypted message; and

means for causing said processor to send said voter file name, said encrypted identification information, and said encrypted message onto said first communications link via said communications interface.

11. The system of claim 10, wherein said voter management device comprises:

a second communications interface for forming said communications link with said voter device, said second communications interface receiving said voter file name, said encrypted identification information, and said encrypted message;

a storage for storing said voter file;

means for accessing said voter file in said storage using said voter file name as an index;

means for deriving at least a portion of said key code using said recognition parameters;

means for decrypting said encrypted identification information using the portion of said key code derived from said recognition parameters to derive a set of decrypted identification information;

means for comparing said decrypted identification information with said reference information stored in said voter file;

means for decrypting, in response to a determination that said decrypted identification information is consistent with said reference information, said encrypted message using the portion of said key code derived from said recognition parameters to derive said decrypted message;

means for extracting from said decrypted message at least one voting selection; and

means for processing at least said one voting selection.

12. A transactional system, comprising:

a user device having a user file name and a set of identification information stored therein, said user device generating a message and encrypting said identification information and said message using at least a portion of a key code to derive a set of encrypted identification information and an encrypted message, said user device sending said user file name, said encrypted identification information, and said encrypted message onto a communications link; and

a provider device having a user file stored therein which contains recognition parameters corresponding to said user device including a set of reference information, said provider device receiving said user file name, said encrypted identification information, and said encrypted message via said communications link, said provider device accessing said user file using said user file name as an index and deriving at least a portion of said key code from said recognition parameters, said provider device decrypting said encrypted identification information using the portion of said key code derived from said recognition parameters to derive a set of decrypted identification information, said provider device comparing said decrypted identification information with said reference information and, in response to a determination that said decrypted identification information is consistent with said reference information, said provider device decrypting said encrypted message using the portion of said key code derived from said recognition parameters to derive a decrypted message, said provider device thereafter processing said decrypted message to carry out a transaction.

13. The system of claim 12, wherein said user device comprises:

a user processing device comprising a processor and a communications interface coupled to said processor for forming said communications link with said provider device; and

a user storage device coupled to said processor, comprising:

a first storage unit for storing said user file name;

a second storage unit for storing said identification information;

means for causing said processor to determine whether said user processing device and said user storage device are authorized to interact with each other;

means for causing said processor to terminate interaction between said user processing device and said user storage device in response to a determination that said user processing device and said user storage device are not authorized to interact with each other;

means for causing said processor to generate said message;

means for causing said processor to retrieve said user file name and said identification information from said first and second storage units;

means for causing said processor to encrypt said identification information and said message using at least a portion of said key code to derive said encrypted identification information and said encrypted message; and

means for causing said processor to send said user file name, said encrypted identification information, and said encrypted message onto said first communications link via said communications interface.

14. The system of claim 13, wherein said provider device comprises:

a second communications interface for forming said communications link with said user device, said second communications interface receiving said user file name, said encrypted identification information, and said encrypted message;

a storage for storing said user file;

means for accessing said user file in said storage using said user file name as an index;

means for deriving at least a portion of said key code using said recognition parameters;

means for decrypting said encrypted identification information using the portion of said key code derived from said recognition parameters to derive a set of decrypted identification information;

means for comparing said decrypted identification information with said reference information stored in said user file;

means for decrypting, in response to a determination that said decrypted identification information is consistent with said reference information, said encrypted message using the portion of said key code derived from said recognition parameters to derive said decrypted message; and

means for processing said decrypted message to carry out a transaction.

15. The system of claim 14, wherein said decrypted message includes an encrypted application address (EAA), and wherein said provider device further comprises:

means for decrypting said EAA using a secret provider key code to derive an encrypted transaction address (ETA); and

means for accessing an account residing at said ETA.

16. The system of claim 15, wherein said decrypted message further includes a transaction instruction, and wherein said provider device further comprises:

means for processing said transaction instruction to manipulate resources within said account.

17. The system of claim 15, wherein said decrypted message further includes a sub-address, and wherein said provider device further comprises:

means for accessing a sub-account residing it said sub-address.

18. The system of claim 17, wherein said decrypted message further includes a transaction instruction, and wherein said provider device further comprises:

means for processing said transaction instruction to manipulate resources within said sub-account.

19. The system of claim 15, wherein said decrypted message further includes a sub-address; and wherein said provider device further comprises:

means for accessing a direct money line account (DMLA) residing at said sub-address, said DMLA usable as a debit account from which funds may be withdrawn using a debit card.

20. The system of claim 19, wherein said decrypted message further includes a transaction instruction, and wherein said provider device further comprises: means for processing said transaction instruction to either transfer funds into or out of said DMLA.

21. The system of claim 19, wherein said decrypted message further includes a set of criteria for governing the manner in which funds in said DMLA may be manipulated using the debit card, and wherein said provider device further comprises:

means for imposing said set of criteria on said DMLA.

22. The system of claim 21, wherein said set of criteria comprises a spending limit, and wherein said provider device further comprises:

means for precluding an amount greater than said spending limit from being withdrawn from said DMLA using the debit card.

23. The system of claim 21, wherein said set of criteria comprises a restriction on what products may be purchased using funds from said DMLA, and wherein said provider device further comprises:

means for precluding selected items from being purchased using funds from said DMLA.

24. The system of claim 21, wherein said provider device further comprises:

means for notifying a user when said set of criteria is met.

25. The system of claim 15,

wherein said provider device further comprises:

means for sending a transaction pending notice and a posting ETA to said user device;

wherein said storage device in said user device further comprises:

means for causing said processor to generate a transfer instruction; and

means for causing said processor to send said transfer instruction to said provider device via said communications interface; and

wherein said provider device further comprises:

means for processing said transfer instruction to transfer resources from said account to another account residing at said posting ETA.

26. The system of claim 15,

wherein said provider device further comprises:

means for sending a transaction pending notice to said user device;

wherein said storage device in said user device further comprises:

means for causing said processor to generate a receive instruction; and

means for causing said processor to send said receive instruction to said provider device via said communications interface; and

wherein said provider device further comprises:

means for processing said receive instruction to receive resources into said account.

27. The system of claim 14, wherein said user file further contains a reference access code, wherein said decrypted message includes an encrypted application address (EAA) and an access code, and wherein said provider device further comprises:

means for decrypting said EAA using a secret provider key code to derive an encrypted transaction address (ETA);

means for comparing said access code with said reference access code; and

means for accessing an account residing at said ETA in response to a determination that said access code is consistent with said reference access code.

28. The system of claim 27, wherein said decrypted message further includes a transaction instruction, and wherein said provider device further comprises:

means for processing said transaction instruction to manipulate resources within said account.

29. The system of claim 27, wherein said user file further contains a reference sub-access code, wherein said decrypted message further includes a sub-address and a sub-access code, and wherein said provider device comprises:

means for comparing said sub-access code with said reference sub-access code; and

means for accessing a sub-account residing at said sub-address in response to a determination that said sub-access code is consistent with said reference sub-access code.

30. The system of claim 29, wherein said decrypted message further includes a transaction instruction, and wherein said provider device further comprises:

means for processing said transaction instruction to manipulate resources within said sub-account.

31. The system of claim 27,

wherein said provider device further comprises:

means for sending a transaction pending notice and a posting ETA to said user device;

wherein said storage device in said user device further comprises:

means for causing said processor to generate a transfer instruction; and

means for causing said processor to send said transfer instruction to said provider device via said communications interface; and

wherein said provider device further comprises:

means for processing said transfer instruction to transfer resources from said account to another account residing at said posting ETA.

32. The system of claim 27,

wherein said provider device further comprises:

means for sending a transaction pending notice to said user device;

wherein said storage device in said user device further comprises:

means for causing said processor to generate a receive instruction; and

means for causing said processor to send said receive instruction to said provider device via said communications interface; and

wherein said provider device further comprises:

means for processing said receive instruction to receive resources into said account.

33. An authorizational system, comprising:

a user device having a user file name and a set of identification information stored therein, said user device generating a message and encrypting said identification information and said message using at least a portion of a key code to derive a set of encrypted identification information and an encrypted message, said user device sending said user file name, said encrypted identification information, and said encrypted message onto a communications link; and

a provider device having a user file stored therein which contains recognition parameters corresponding to said user device including a set of reference information, said provider device receiving said user file name, said encrypted identification information, and said encrypted message via said communications link, said provider device accessing said user file using said user file name as an index and deriving at least a portion of said key code from said recognition parameters, said provider device decrypting said encrypted identification information using the portion of said key code derived from said recognition parameters to derive a set of decrypted identification information, said provider device comparing said decrypted identification information with said reference information and, in response to a determination that said decrypted identification information is consistent with said reference information, said provider device decrypting said encrypted message using the portion of said key code derived from said recognition parameters to derive a decrypted message, said provider device processing said decrypted message to derive a set of authorization codes, said provider device sending said authorization codes to said user device via said communications link to be stored within said user device.

34. The system of claim 33, wherein said user device comprises:

a user processing device comprising a processor and a communications interface coupled to said processor for forming said communications link with said provider device; and

a user storage device coupled to said processor, comprising:

a first storage unit for storing said user file name;

a second storage unit for storing said identification information;

a third storage unit;

means for causing said processor to determine whether said user processing device and said user storage device are authorized to interact with each other;

means for causing said processor to terminate interaction between said user processing device and said user storage device in response to a determination that said user processing device and said user storage device are not authorized to interact with each other;

means for causing said processor to generate said message;

means for causing said processor to retrieve said user file name and said identification information from said first and second storage units;

means for causing said processor to encrypt said identification information and said message using at least a portion of said key code to derive said encrypted identification information and said encrypted message;

means for causing said processor to send said user file name, said encrypted identification information, and said encrypted message onto said first communications link via said communications interface;

means for causing said processor to receive said authorization codes from said provider device via said communications interface; and

means for causing said processor to store said authorization codes into said third storage unit.

35. The system of claim 34, wherein said provider device comprises:

a second communications interface for forming said communications link with said user device, said second communications interface receiving said user file name, said encrypted identification information, and said encrypted message;

a storage for storing said user file;

means for accessing said user file in said storage using said user file name as an index;

means for deriving at least a portion of said key code using said recognition parameters;

means for decrypting said encrypted identification information using the portion of said key code derived from said recognition parameters to derive a set of decrypted identification information;

means for comparing said decrypted identification information with said reference information stored in said user file;

means for decrypting, in response to a determination that said decrypted identification information is consistent with said reference information, said encrypted message using the portion of said key code derived from said recognition parameters to derive said decrypted message;

means for processing said decrypted message;

means for generating said authorization codes; and

means for sending said authorization codes to said user device via said second communications interface.

Images