Abstract:
In an exemplary embodiment a companion processor system is provided which pairs a secure processor with a general processor. The secure processor can, for example, include a signal port, a power port and a ground port. The general processor is, in for example, operative to power up the secure processor by applying, directly or indirectly, at least one of power and ground to the power port and ground port, respectively of the secure processor when it wishes to communicate with the secure processor via the signal port. In another exemplary embodiment a method for providing secure transactions is disclosed includes: detecting an input with a general processor of the initiation of a desired transaction; powering up a secure processor under the direction of the general processor; and communicating between the general processor and the secure processor to provide at least one secure transaction.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Ser. No. 60/594300, filed Mar. 26, 2005, and further claims the benefit of U.S. Ser. No. 60/675,388, filed Apr. 27, 2005, both of which are incorporated herein by reference. 
     
    
     BACKGROUND 
       [0002]    Exemplary embodiments disclosed herein pertain to electronic security. More particularly, exemplary embodiments disclosed herein pertain to electronic cards implementing security protocols. 
         [0003]    There are a great many applications for electronic security. For example, security is desirable or required for financial transactions, or for providing access to various physical and non-physical resources. One area of great concern for electronic security is in the field of financial transaction cards, e.g. credit and debit cards. 
         [0004]    Conventional credit cards, debit cards and other financial transaction cards hereafter “transaction card” have a typically plastic body upon which is embossed a 16 digit account number and other data. A magnetic strip, usually referred to as a “stripe”, is adhered to the back of the card, and also includes the account number and other data. The stripe allows the transaction card to be read by a card reader, hereafter referred to as a “legacy card reader.” 
         [0005]    There are many security problems with conventional transaction cards. For one, the stripe is static and is not encrypted, allowing transaction card thieves to “steal”, in the virtual sense, the data from the stripe and use it for unauthorized transactions. Also, a stolen conventional card can be freely used by the thief unless until it is cancelled. 
         [0006]    In addition to a lack of security, conventional transaction cards are also quite limited in storage capacity. To address this problem, the “Smart Card”, i.e. a transaction card including an on-board processor and digital memory, has been developed. By providing an on-board processor and digital memory, a transaction card can implement security protocols such as encryption, store user information, etc. 
         [0007]    A common standard for Smart Cards is referred to as the ISO 7816 standard. With this protocol, a Smart Card is provided with an electrical interface including a number of electrically conductive and externally accessible contact pads which are coupled to an embedded secure processor. The Smart Card is inserted into a Smart Card reader which makes electrical contact with the contact pads to provide power to and communications with the secure processor. Smart cards can also include a conventional stripe, which does not in any way interact with the secure processor. 
         [0008]    While broadly adopted abroad, Smart Cards have not been extensively adopted in the U.S. A major reason for this is the investment made by millions of merchants in legacy card readers, which cannot communicate with the secure processors of Smart Cards. Also, Smart Cards conforming to the ISO 7816 standard suffer from their own limitations, including severely restricted I/O, an inability to provide “smart” transactions with legacy card readers, etc. 
         [0009]    A third approach, not yet in use, uses a general processor and a stripe emulator which work with legacy card readers. As used here, the term “stripe emulator” will refer to a transaction card where data transmitted to a legacy card reader can be changed under the control of the general processor. This third approach will be referred to herein as an “emulator card.” 
         [0010]    Emulator cards potentially have a number of distinct advantages over conventional credit cards. For one, a single card can emulate a number of different transaction cards, greatly reducing the bulk in one&#39;s wallet. For example, an emulator card can emulate a Visa card, a MasterCard, and an ATM card. Also, since the emulator card includes a processor, it is possible to implement additional functionality, such as security functions. 
         [0011]    However, emulator cards, too, have their limitations. For one, since general processors are used the security level of the card is reduced. For example, a hacker could potentially obtain data stored in unsecured electronic memory. Also, emulator cards do not address Smart Card protocols, as they are designed to work with legacy card readers. For example, as with conventional credit cards, data flows from the emulator card to the legacy card reader, and not vice versa. Still further, the information that can be provided by the emulator card is limited to the amount of information that a conventional stripe can hold and that a legacy card reader can read. 
         [0012]    These and other limitations of the prior art will become apparent to those of skill in the art upon a reading of the following descriptions and a study of the several figures of the drawing. 
       SUMMARY 
       [0013]    Embodiments are disclosed which provide examples of enhanced electronic security. A number of non-limiting examples of transaction cards which address aforementioned problems and limitations of prior transaction cards are presented. As will be apparent to those skilled in the art, the methods and apparatus as disclosed herein are applicable to a wide variety of problems which require or could be improved with electronic security measures. 
         [0014]    In one embodiment presented by way of example and not limitation, an enhanced Smart Card includes a card body, a secure processor and a general processor. The card body may be provided with an externally accessible card interface including a signal port, a power port, and a ground port. The secure processor is carried by the card body and is coupled to the signal port, the power port, and the ground port. The general processor is also carried by the card body, the general processor being coupled to a power source and being operative to provide power to and communicate with the secure processor when the secure processor is being used in an enhanced Smart Card mode. 
         [0015]    In an exemplary embodiment, the secure processor is a Smart Chip processor compliant with the ISO 7816 standard. In other embodiments, the secure processor is compliant with other standards, or is proprietary in nature. In another exemplary embodiment, the general processor has a plurality of I/O ports. These ports can provide I/O for such devices as displays, switches and stripe emulators. 
         [0016]    In another embodiment, set forth by way of example and not limitation, a secure transaction card includes a card body carrying a secure processor, a strip emulator and a general processor. The general processor is interposed between the secure processor and the stripe emulator such that there is not a direct connection between the stripe emulator and the secure processor. 
         [0017]    In one embodiment, the general processor selectively powers the secure processor. For example, the general processor may directly power the secure processor or may cause the secure processor to be powered. In an alternative embodiment, the secure processor is ISO 7816 compliant. In another alternative embodiment, the secure transaction card may be provided with inputs such as switches or keypads, and outputs such as LEDs and flat panel displays. 
         [0018]    In another embodiment which is generally applicable electronic security applications in addition to transaction card security application, a companion processor system is provided. The companion processor system pairs a secure processor with a general processor. The secure processor can, for example, include a signal port, a power port and a ground port. The general processor is, in this example, operative to power up the secure processor by applying, directly or indirectly, at least one of power and ground to the power port and ground port, respectively of the secure processor when it wishes to communicate with the secure processor via the signal port. 
         [0019]    In another embodiment which is generally applicable electronic security applications in addition to transaction card security applications, a method for providing secure transactions is disclosed. The method, by way of example and not limitation, includes: detecting an input with a general processor of the initiation of a desired transaction; powering up a secure processor under the direction of the general processor; and communicating between the general processor and the secure processor to provide at least one secure transaction. 
         [0020]    These and other embodiments and advantages will become apparent to those of skill in the art upon a reading of the following descriptions and a study of the several figures of the drawing. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0021]    Several exemplary embodiments will now be described with reference to the drawings, wherein like components are provided with like reference numerals. The exemplary embodiments are intended to illustrate, but not to limit, the invention. The drawings include the following figures: 
           [0022]      FIG. 1  is a top plan view of an exemplary transaction card; 
           [0023]      FIG. 2  is a bottom plan view of the exemplary transaction card of  FIG. 1 ; 
           [0024]      FIG. 3  is a block diagram of an exemplary circuit for the transaction card illustrated in  FIGS. 1 and 2 ; 
           [0025]      FIG. 4  is a block diagram of an exemplary secure processor of  FIG. 3 ; 
           [0026]      FIG. 5  is a flow diagram of an exemplary main process running on the secure processor of  FIG. 3 ; 
           [0027]      FIG. 6  is a flow diagram of an exemplary operation  116  “Handle Smart Card Terminal” of  FIG. 5 ; 
           [0028]      FIG. 7  is a flow diagram of an exemplary operation  128  “Process Command” of  FIG. 6 ; 
           [0029]      FIG. 8  is a flow diagram of an exemplary operation  132  “GET DATA—Serial Number” of  FIG. 7 ; 
           [0030]      FIG. 9  is a flow diagram of an exemplary operation  134  “GET DATA—Key ID” of  FIG. 7 ; 
           [0031]      FIG. 10  is a flow diagram of an exemplary operation  136  “GET CHALLENGE” of  FIG. 7 ; 
           [0032]      FIG. 11  is a flow diagram of an exemplary operation  138  “EXTERNAL AUTHENTICATE” of  FIG. 7 ; 
           [0033]      FIG. 12  is a flow diagram of an exemplary operation  140  “GET DATA—Personalization” of  FIG. 7 ; 
           [0034]      FIG. 13  is a flow diagram of an exemplary operation  142  “PUT DATA—Update EEPROM Firmware” of  FIG. 7 ; 
           [0035]      FIG. 14  is a flow diagram of an exemplary operation  144  “PUT DATA—Activate EEPROM Firmware” of  FIG. 7 ; 
           [0036]      FIG. 15  is a flow diagram of an exemplary operation  146  “PUT DATA—Reset Firmware to ROM Version” of  FIG. 7 ; 
           [0037]      FIG. 16  is a flow diagram of an exemplary operation  148  “GET DATA—ROM Firmware” of  FIG. 7 ; 
           [0038]      FIG. 17  is a flow diagram of an exemplary operation  150  “GET DATA—EEPROM Firmware Version” of  FIG. 7 ; 
           [0039]      FIG. 18  is a flow diagram of an exemplary operation  152  “PUT DATA—Initialize Diverse Key” of  FIG. 7 ; 
           [0040]      FIG. 19  is a flow diagram of an exemplary operation  154  “PUT DATA—Personalize” of  FIG. 7 ; 
           [0041]      FIG. 20  is a flow diagram of an exemplary operation  156  “PUT DATA—Enable” of  FIG. 7 ; 
           [0042]      FIG. 21  is a flow diagram of an exemplary operation  118  “Handle M 2 ” of  FIG. 5 ; 
           [0043]      FIG. 22  is an exemplary and highly simplified block diagram of the general processor of  FIG. 3 ; 
           [0044]      FIG. 23  is a flow diagram which illustrates an example of a main process of the general processor of  FIG. 3 ; 
           [0045]      FIG. 24  is a flow diagram of an exemplary operation  372  “INITIALIZE HELPER CHIP State” of  FIG. 23 ; 
           [0046]      FIG. 25  is a flow diagram of an exemplary operation  384  “MENU State” of  FIG. 24 ; 
           [0047]      FIG. 26  is a flow diagram of an exemplary operation  410  “INITIALIZE SMARTCHIP State” of  FIG. 25 ; 
           [0048]      FIG. 27  is a flow diagram of an exemplary operation  476  “DATA State” of  FIG. 26 ; 
           [0049]      FIG. 28  is a flow diagram of an exemplary operation  516  “ACTIVE State” of  FIG. 27 ; 
           [0050]      FIG. 29  is a flow diagram of an exemplary operation  540  “SHUTDOWN State” of  FIG. 28  as well as exemplary operation  396  of  FIG. 25 ; 
           [0051]      FIG. 30  is a flow diagram of an exemplary operation  420  “ERROR State” of  FIG. 26  also referenced as operation  490  “ERROR State” of  FIG. 27 ; 
           [0052]      FIG. 31  is a flow diagram of an exemplary operation  438  “BIST State” of  FIG. 26 ; 
           [0053]      FIG. 32  is a block diagram of an exemplary process for signal conversion; 
           [0054]      FIG. 33  is a diagram of an exemplary broadcaster  68  of  FIG. 3 ; 
           [0055]      FIG. 34  is a diagram of an exemplary broadcaster  68  interface; 
           [0056]      FIG. 35  is a diagram showing the various waveforms of an exemplary signal conversion; 
           [0057]      FIG. 36  is a block diagram of an exemplary ASIC embodiment; 
           [0058]      FIG. 37  is a schematic diagram of an exemplary RC network of buffering circuit  66 ; 
           [0059]      FIG. 38  is a graph of a waveform generated by an exemplary buffering circuit  66 ; and 
           [0060]      FIGS. 39A-39D  are graphs of dual track waveforms generated by an exemplary buffering circuit  66 . 
       
    
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
       [0061]    As noted, there are a great many applications for enhanced electronic security. One of many applications is to provide security for financial transactions, e.g. financial transactions using transactions cards such as credit cards and debit cards. In the following exemplary embodiments, particular emphasis will be place on transaction card security, with the understanding that other uses for enhanced electronic security are within the true spirit and scope of the invention. 
         [0062]      FIG. 1  is an exemplary embodiment of a transaction card  10  which includes a card body  11  typically including thermoplastic material in an exemplary embodiment; other materials are also contemplated. The transaction card  10  of this non-limiting example has a front surface  12  which is provided with an electrical interface  16 . The illustrated electrical interface includes a number of contact pads, preferably formed in a configuration which is compliant with the International Standards Organization “Smart Card” standard ISO 7816, incorporated herein by reference. In this exemplary embodiment, the transaction card is usable as a legacy mode Smart Card. In an alternative exemplary embodiment, the interface  16  may be omitted. Also shown on the front surface  12  is an institution identifier  18 , an institution number  20 , an account number  22 , and a client name  24 . The account number is preferably embossed on the transaction card  10  to provide raised numerals for credit card imprint machines. 
         [0063]      FIG. 2  illustrates a back surface  14  of the exemplary transaction card  10 . In this exemplary embodiment, a magnetic stripe emulator  26  is provided on the back surface  14  which can communicate with legacy magnetic stripe readers of the prior art. The card back  14  may also have an on/off button  28 , an “on” indicator  30 , and an “off” indicator  32 . In this exemplary embodiment, “on” indicator  30  may be a green LED and the “off” indicator  32  may be a red LED. Also placed on the card back  14  may be a plurality of account interfaces  34 . Each account interface  34  preferably has account indicator LED  36  and an account selector switch  38 . Each account interface  34  may also have, for example, printed information identifying the account and expiration date. Back surface  14  also has, in this example, instructions  40 , an institution identifier  41 , a signature box  42 , various other optional printed information. 
         [0064]      FIG. 3  is a block diagram of an embodiment of exemplary circuitry, presented by way of example but not limitation, of the transaction card  10 . In this example, the transaction card  10  includes a secure processor  44 , a general processor  52 , and a magnetic stripe emulator  64 . In this embodiment, both the secure processor  44  and the general processor  52  are coupled to the ISO 7816 interface  16  by a bus  48 . 
         [0065]    Secure processor  44  is preferably a commercially available Smart Card chip which has various tamper resistant properties such as a secure cryptographic function and tamper resistant storage  46 . An exemplary embodiment of secure processor  44 , given by way of example and not limitation, is a P8WE6032 processor manufactured by Phillips of Germany. Similar devices are manufactured by Hitachi, Infineon, Toshiba, ST and others. As noted previously, in this example secure processor  44  is connected electrically to the interface  16  a bus  48 . This bus is therefore preferably ISO 7816 compliant. 
         [0066]    General processor  52  is, in this example, also connected to the bus  48  and, therefore, to both the secure processor  44  and the interface  16 . Additionally, in this example, the general processor  52  is coupled to the secure processor  44  by an I/O  2  line  50 . In the currently exemplary embodiment, memory  54  is coupled to the general processor  52 . General processor  52  is also coupled, in this example, to power source  56 , display  58 , switches  60 , and other I/O  62 . Power source  56  is preferably a battery disposed within the card body  10 . Alternative exemplary embodiments include a battery operable to be a primary (non-rechargeable) and a battery operable to be a secondary (rechargeable). The exemplary rechargeable battery may, for example, be recharged through electrical interface  16 , or through magnetic induction, a solar cell, another electrical connector, or other means. These exemplary embodiments are given by way of example and not limitation. Other alternative power sources will be apparent to those of skill in the art. 
         [0067]    General processor  52  may be, for example, a PIC16 micro controller. In an alternative embodiment, general processor  52  may comprise an ASIC chip. In still further embodiments, general processor may be any form of logic (e.g. a state machine) which performs the desired functions. 
         [0068]    Display  58  may be, for example, LED devices as disclosed previously. As another non-limiting example, display  58  is may comprise a flexible LCD display. Switches  60  can be any form of electrical switches to allow for configuring the operation of general processor  52  and associated I/O apparatus. The processor  52  may provide software debouncing algorithms with respect to such switches. Other I/O  62  may comprise any number of alternative I/O subsystems. These may include, by way of example and not limitation, audio, tactile, RF, IR, optical, keyboard, biometric I/O or other I/O. 
         [0069]    Also coupled to general processor  52  is magnetic stripe emulator  64 , which allows the card body  10  to be used in a mode which emulates the magnetic stripe card of the prior art. Magnetic stripe emulator  64 , in this non-limiting example, is comprised of a buffering circuit  66 , which converts digital output from general processor  52  into a wave form appropriate for magnetic stripe emulation. In this exemplary embodiment, buffering circuit  66  includes an RC signal conversion circuit which is typically implemented as an RC network. RC networks are well known to those skilled in the art. 
         [0070]    In this example, magnetic stripe emulator  64  is further comprised of a broadcaster  68 . Broadcaster  68  may be electrically coupled to buffering circuit  66  and preferably receives two tracks of signal which are converted by broadcaster  68  into magnetic impulses for magnetic stripe emulation. Alternative embodiments include a single track embodiment, and three or more tracks. Broadcaster  68  may include on e or more electrical coils to convert electrical signal into magnetic impulses. Broadcaster  68  of this example may further include one or more sensors  70 , which are electrically coupled to general processor  52 . These sensors are used to signal to general processor  52  that the physical act of swiping the card body  10  through a legacy card reader has commenced. Sensors  70  also communicate to general processor  52  when contact is lost with the magnetic stripe reader  72 , which receives and interprets magnetic flux impulses from the broadcaster. 
         [0071]    As noted previously, the transaction card  10  of this example includes an electrical interface  16 . In this example, electrical connectors  16  are used in a manner compliant with ISO 7816 to communicate with an ISO 7816 reader device  74 . 
         [0072]    When used in a legacy Smart Card mode, secure processor  44  is powered by bus  48  from a Smart Card reader device  74 . The reader device  74  can be used to program and personalize secure processor  44  with various information including, by way of example and not limitation, firmware code, account numbers, cryptographic keys, PIN numbers, etc. This information, once loaded into secure processor  44 , prepares secure processor  44  for an operational mode which no longer requires the use of reader device  74 . 
         [0073]    In this “independent” mode, secure processor  44  communicates with general processor  52  and provides services such as cryptographic functions and the dynamic generation of authentication information which is used to communicate via general processor  52  and magnetic stripe emulator  64  with magnetic stripe reader  72 . Also in this example, the authentication code may be used only once for a single transaction. Subsequent transactions require new authentication codes to be generated. 
         [0074]    In an alternative embodiment, the card body  10  continues to be used with reader device  74  and also with magnetic stripe reader device  72 . In this alternate embodiment, the card detects the mode in which it is being used and automatically switches the usage of bus  48  appropriately for the detected mode of operation. This is achieved in optional bus arbitrator  76 . Optional bus arbitrator  76  can detect when it is being used with reader device  74  because power is provided by reader device  74  via electrical connectors  16  to bus  48 . Similarly, optional bus arbitrator  76  can detect that power is being provided by general processor  52  and switch to the corresponding mode of operation, which services general processor  52  and the various I/O devices connected thereto. In yet another alternative embodiment, optional bus arbitrator  76  allows for the dynamic communication of both general processor  52  and secure processor  44  with each other respectively, and with reader device  74 . This requires bus arbitration logic which is well known to those skilled in the art. In a further alterative embodiment, general processor  52  is interposed between secure processor  44  and electrical connectors  16 . In this alternative embodiment, general processor  52  acts as a “go-between” or a “front end” for secure processor  44 . 
         [0075]      FIG. 4  shows an exemplary secure processor  44  of  FIG. 3  in greater detail. Secure processor  44  of this example is an ISO 7816 compliant micro controller comprising power apparatus  78 , security sensors  80 , reset generator  82 , clock input filter  84 , CPU  86 , interrupt system  88 , and internal bus  90 . Coupled to internal bus  90  is tamper resistant storage  46 , which may be comprised of RAM  91 , EEPROM  93 , or both. Both RAM  91  and EEPROM  93  are coupled to internal bus  90 , in a preferred embodiment. Also coupled to bus  90  is crypto processor  92 , which handles encryption and decryption. Also coupled of bus  90  are timers  94  and ROM  96 , which is used for storing the firmware necessary for secure processor  44  to operate, UART  98 , which is used for serial communications via bus  48  and electrical connectors  16  with reader device  74 . Also connected to bus  90  is I/O subsystem  100  and random number generator  102 . Secure processors  44  as described above are commercially available from a variety of sources including Philips, Hitachi, Infineon, Toshiba, ST, and others. A suitable secure processor  44  for use in the disclosed exemplary embodiment is the model P8WE6032 processor made by Philips of Germany. 
         [0076]      FIG. 5  illustrates by way of example and not limitation a main process to be implemented by secure processor  44 . This main process can be, for example, encoded into either the ROM  96  or EEPROM  93  of secure processor  44 . The process begins in operation  110  which passes control to operation  112  wherein the power to secure processor  44  is turned on by the general processor  52  or by reader device  74 . As used herein, an “operation” is a specified act performed by a processor. Then, in operation  114 , secure processor  44  detects its mode of operation and branches to an appropriate handler for the detected mode. One of the operation modes handles operation with reader device  74 . Operation  116  passes control to a handler which handles this mode of operation. Operation  118  passes control to a handler which handles communication with general processor  52 . Operation  120  handles other modes of operation. For example, this handler could handle a mode of operation involving both secure processor  44  and general processor  52  communicating cooperatively with each other respectively, and with reader device  74 . This alternative embodiment is given by way of example and not limitation. Once the communication is handled, the power is turned off in operation  122 , which completes the process. 
         [0077]      FIG. 6  illustrates, by way of example, one embodiment for operation  116  of  FIG. 5  in more detail. The process begins in operation  123 , and continues in operation  124  with secure processor  44  sending a signal called “answer to reset,” which indicates that secure processor  44  is online and ready to communicate, preferably via asynchronous serial communications utilizing UART  98 . Then, in operation  126 , secure processor  44  waits for a command to be received. If a command is not received, it continues waiting. In an alternative embodiment, this period of waiting could be used to perform some computational task in the background, such as authentication code generation based on a pseudo random sequence. When a command is received, control is passed to operation  128 , which processes the command. Once the command is processed, control is passed back to operation  126  which waits for another command. Commands are processed in the above described manner until this process is interrupted by the power being turned off. 
         [0078]      FIG. 7  shows an exemplary operation  128  of  FIG. 6  in more detail. The process begins with operation  129  which passes control to a branching operation  130 . Operation  130  dispatches control to one of several handlers for the various messages that may be received. Operation  130  passes control to only one of the handlers shown in  FIG. 7 . 
         [0079]    The selection of which handler to which to branch is determined by an examination of the message received. In a preferred embodiment, the message received contains a selector code which identifies the handler to be used. Operation  132  is a handler which processes the message “GET DATA—Serial Number” Operation  134  handles a command called “GET DATA—Key ID.” Operation  136  is a handler which handles the “GET CHALLENGE.” Operation  138  is a handler for “EXTERNAL AUTHENTICATE.” Operation  140  is a handler for “GET DATA—Personalization.” Operation  142  is a handler for “PUT DATA—Update EEPROM Firmware.” Operation  144  is a handler for “PUT DATA—Activate EEPROM Firmware.” Operation  146  is a handler for “PUT DATA—Reset Firmware to ROM Version.” Operation  148  is a handler for “GET DATA—ROM Firmware Version.” Operation  150  is a handler for “GET DATA—EEPROM Firmware Version.” Operation  152  is a handler for “PUT DATA—Initialize Diverse Key.” Operation  154  is a handler for “PUT DATA—Personalize.” Operation  156  is a handler for “PUT DATA—Enable.” Operation  158  is a handler for “Other.” 
         [0080]    Operation  158  is shown to represent any additional handler that one may wish to introduce to enhance communication with or the internal processes of secure processor  44 . An example of such a command is to initiate a background task to perform authentication code generation in the background. Another example of such a command would be a self-destruct command which would render the card unusable. This embodiment would be used in the event that it was clear that fraud was taking place. These embodiments are given by way of example and not limitation. 
         [0081]      FIG. 8  shows an exemplary operation  132  of  FIG. 7  in more detail. The purpose of this process is to allow the retrieval of a unique serial number from secure processor  44 . The process begins with operation  162 ; control is passed to operation  164  which retrieves the unique serial number which is stored within the secure processor  44  and its associated storage. In one embodiment, this serial number is encoded into EEPROM  93 . In another embodiment, the serial number is encoded into ROM  96 . Once the unique serial number has been retrieved control is passed to operation  166 , which formats a message containing the serial number. Control is then passed to operation  168 , which sends the message back to the source which requested it. It should be noted that this information may be either encrypted or unencrypted and both embodiments are contemplated. The process is completed in operation  170 . 
         [0082]      FIG. 9  shows an exemplary operation  134  of  FIG. 7  in greater detail. The process begins in operation  172 , control is passed to operation  174  which retrieves a key ID from secure processor  44  and its associated storage. Control is passed to operation  176 , which formats a message containing the key ID. The message is then sent in operation  178 . The entire message or parts of the message may be encrypted. The process is completed in operation  180 . 
         [0083]      FIG. 10  shows an exemplary operation  136  of  FIG. 7  in greater detail. The process begins in operation  182 ; control is passed to operation  184  which generates a random number using random number generator  110 . This random number is used as part of an authentication sequence in connection with operation  138  of  FIG. 7 . The random number is stored within secure processor  44  and its associated storage, preferably in RAM  91 . Later, during authentication, this number is recalled and compared to a message generated externally. After the random number is stored in operation  186  control is passed to operation  188 , which formats a message containing the random number. In operation  190 , this random number is sent back to the client that requested it. The process is completed in operation  192 . 
         [0084]      FIG. 11  shows an exemplary operation  138  of  FIG. 7  in greater detail. The process begins with operation  194 . Operation  196  accesses a challenge response parameter in the incoming message from the client. The challenge response parameter represents the client&#39;s attempt to replicate in encrypted form the random number that it has previously received. Control is then passed to operation  198 , which compares the challenge response parameter to the previously stored random number. If these two numbers match, it means that the client has successfully replicated the number in encrypted form and returned it to secure processor  44  in an effort to authenticate itself to the secure processor  44 . If the challenge response is correct, control is passed to operation  200 , which sets an unlocked state in secure processor  44 , preferably, in RAM  91 . Once this unlocked state has been set, subsequent commands requiring authentication will be able to detect that authentication has occurred. Any subsequent reset or power cycle of secure processor  44  resets the chip to a locked condition, requiring the client to authenticate anew. After the unlocked state is set in operation  200 , control is passed to operation  202 , which formats a message indicating the status of secure processor  44  as well as the status of the present process. This message is then sent in operation  204  and the process is completed with operation  206 . If, in operation  198 , the challenge response was incorrect, then control is passed to operation  208 , which formats a message indicating failure. This message is subsequently sent in operation  204  to the client and the process terminates with operation  206 . 
         [0085]      FIG. 12  shows an exemplary operation  140  of  FIG. 7  in greater detail. The process begins in operation  210 ; control is passed to operation  212  which determines whether or not the secure processor  44  is locked. Secure processor  44  can only be unlocked if a previous authentication during the present communication session was successful. If secure processor  44  is unlocked, control is passed to operation  214 , which accesses a parameter in the incoming message specifying the account to be accessed. Control is passed to operation  216 , which retrieves personalization data for the specified account. This data is retrieved from the storage associated with secure processor  44 . In operation  218 , the message is formatted containing the encrypted account data that was requested. This account data pertains to the account specified in the message. This encrypted account data is then sent to the client in operation  220 . The process is then completed in operation  222 . If, in operation  212 , it is found that secure processor  44  is locked, then, control is passed to operation  224 , which formats and sends a message specifying that secure processor  44  is locked and, therefore refuses to provide the requested information. Control is then passed to operation  222 , which completes the process. 
         [0086]      FIG. 13  shows an exemplary operation  142  of  FIG. 7  in greater detail. The process begins in operation  226 , control is then passed to operation  228  which determines whether or not secure processor  44  is locked. If secure processor  44  is not locked, control is passed to operation  230 , which determines whether or not the secure processor  44  is in an appropriate state for the firmware to be updated. If secure processor  44  is in an appropriate state for the firmware to be updated, control is passed to operation  232 , which verifies that the data length of the incoming firmware update is valid. If it is determined in operation  232  that the data length is valid, control is passed to operation  234 , which examines a parameter in the message identifying the address to be updated in the firmware of EEPROM  91 . If the address is found to be in a range of addresses that is suitable to store firmware updates, control is passed to operation  236 , which updates the firmware at the specified address in EEPROM  91  with data from the message. Control is then passed to operation  238 , which formats and sends to the client, a message indicating the status of secure processor  44  and the present process. Control is then passed to operation  240 , which completes the process. If, in operation  228 , it is determined that secure processor  44  is locked, control is passed to operation  242 , which formats and sends a message to the client indicating failure and the reason for the failure. Similarly, if it is found in operation  230  that secure processor  44  is not in an appropriate state for the firmware to be updated, control is passed to operation  242 , which signals an error. Likewise, if, in operation  232 , it is found that the data length is not valid, control is passed to operation  242 , which signals an error by formatting a message to contain error status information and sending it. Finally, if, in operation  234 , it is found that the address for the firmware update is not appropriate, control is passed to operation  242 , which signals an error. Once the error is signaled in operation  242 , control is passed to operation  240  and the process is completed. 
         [0087]      FIG. 14  shows an exemplary operation  144  of  FIG. 7  in greater detail. The process begins with operation  244 ; control is passed to operation  246 , which determines whether or not the secure processor  44  is in a locked condition. If it is determined that secure processor  44  is not locked, control is then passed to operation  248 , which sets the internal state of secure processor  44  to indicate that the software that has been loaded into the EEPROM  93  should be executed after the next reset. This allows secure processor  44  to transition from a state where it automatically executes the firmware stored in the ROM  96  to a state where it is executing the firmware that has been loaded into the EEPROM  93 . In operation  250  a message which indicates the status of secure processor  44  and the present process is formatted and sent to the client. The process is then completed in operation  252 . If it is determined in operation  246  that the secure processor  44  is in a locked condition, control is passed to operation  254  which formats and sends to the client a message indicating failure of the present process and the reason for the failure. Control is then passed to operation  252  which ends the process. 
         [0088]      FIG. 15  shows an exemplary operation  146  of  FIG. 7  in greater detail. The process is started in operation  256 ; control is passed to operation  258 , which determines whether or not secure processor  44  is in a locked condition. If it is determined in operation  258  that the secure processor  44  is not in a locked condition, control is passed to operation  260  which sets the internal state of secure processor  44  to indicate that the firmware in ROM  96  should be executed after the next reset. This allows the secure processor  44  to transition to a state where it executes the firmware stored in ROM  96  which is known to be storing the original firmware of secure processor  44 . Control is then passed to operation  262 , which signals the status of secure processor  44  as well as the status of the present process. This status message is formatted and sent to the client. The process then terminates in operation  264 . If it is determined in operation  258  that the secure processor  44  is in a locked condition, control is passed to operation  266  which formats and sends a message to the client indicating failure and the reason for the failure. 
         [0089]      FIG. 16  shows an exemplary operation  148  of  FIG. 7  in greater detail. The process begins in operation  268 , control is passed to operation  270 , which retrieves from ROM  96  the version number of the information stored in ROM  96 . Control is then passed to operation  272 , which formats a message containing the ROM  96  version number. Preferably, this information is in unencrypted form. Operation  274 , then, sends the message to the client and the process terminates with operation  276 . In an alternate embodiment, this information is encrypted. 
         [0090]      FIG. 17  shows an exemplary operation  150  of  FIG. 7  in greater detail. The process begins in operation  278 ; control is passed to operation  280 , which retrieves the firmware version of EEPROM  93 . This information is preferably stored in EEPROM  93 . Control is then passed to operation  282 , which formats a message containing the EEPROM  93  firmware version. Preferably, this version information is in unencrypted form. Control is then passed to operation  284 , which sends the message to the client. The process is then terminated in operation  286 . In an alternate embodiment, this information is encrypted. 
         [0091]    In  FIG. 18 , an exemplary operation  152  of  FIG. 7  is explained in greater detail. The process  152  begins with at  288 , and, in a decision operation  290  it is determined whether it is locked. If it is locked, operation  292  signals an error by formatting a message containing error status information and sending it to the client, and the process is completed at  294 . If decision operation  290  determines that it is not locked, operation  296  accesses a parameter containing the card diverse transport key (CDTK) which must be decrypted since it is transmitted by the client in encrypted form using the transpork key of secure processor  44 . Next, in operation  298 , the process updates the internal CDTK with a specified value. Next, in an operation  300 , a message is formatted to indicate the status of secure processor  44  and the present process. The message is then sent in an opreation  302  and the process  152  is completed at operation  294 . 
         [0092]    In  FIG. 19 , an exemplary operation  154  PUT DATA-Personalize of  FIG. 7  is described in greater detail. The process  154  begins at  304  and, in a decision operation  306  it is determined whether it is locked. If it is locked, an operation  308  signals an error by formatting and sending a message indicating error status to the client and the process  154  is completed at  310 . If operation  306  determines that it is not locked, operation  312  decrypts and updates the personalization data stored in EEPROM as specified in the message. Next, in an operation  314 , a message is formatted to indicate the status of secure processor  44  and the present process. Finally, in operation  316 , the message is sent and the process  154  is complete at  310 . 
         [0093]      FIG. 20  describes an exemplary process of operation  156  of  FIG. 7  in greater detail. The process begins at operation  318 ; control is then passed to decision operation  320  which determines whether or not secure processor  44  is in a locked condition. If secure processor  44  is locked, then control is passed to operation  322  which formats and sends a message containing error information to the client. Control is then passed to operation  324  which terminates the process. If in operation  320  it is determined that secure processor  44  is not locked, control passes to operation  326  which sets the internal state of secure processor  44  to indicate that the card is enabled for normal operation. In a preferred embodiment, this internal state is stored in EEPROM  93 . Control is then passed to operation  328  which formats a message indicating the status of processor  44  and of the present process. The message is then sent in operation  340 . The process then ends in operation  324 . 
         [0094]      FIG. 21  shows an exemplary process of operation  118  of  FIG. 5  in greater detail. The process begins with operation  342 , control is then passed to operation  344 , which sends an “I am here” message to general processor  52 . At this point, secure processor  44  begins listening for a command to be sent from the client, general processor  52 . This is handled in operation  346 . Then, in a decision operation  348 , it is determined whether or not a request has been received. If not, control is passed back to operation  346 . 
         [0095]    If a request has been received from the client, control is passed to operation  350 . In operation  350 , the incoming request or command is examined for a selector code that is used to dispatch the message to an appropriate handler. One such handler is operation  352 , which retrieves account data specified in the command and returns it to the client. Another such handler is operation  354 , which retrieves configuration data for secure processor  44  and returns it to the client. Operation  356  could be used to handle any other kind of communication between general processor  52  and secure processor  44 . By way of example, and not limitation, this command could be used to allow the general processor to access the random number generator  102  on secure processor  44 . Similarly, such a handler could be disposed to provide access to the other functions that are unique to secure processor  44  such as crypto processor  92 . Steps  352 ,  354 , and  356 , when completed, return control to operation  346 , which listens for a subsequent command. This process continues until the power is interrupted. 
         [0096]    In an alternative embodiment an external event other than a power interruption event, would cause the loop of the present process to terminate. It should be noted that communications between general processor  52  and secure processor  44  may optionally use additional connections such as auxiliary connector  50 . One exemplary embodiment of this communication uses one communication line on bus  48  in concert with auxiliary connector  50 , to establish synchronous serial communications between general processor  52  and secure processor  44 . This is especially useful in situations where general processor  52  does not have a UART for asynchronous serial communications. Auxiliary connector  50  and the I/O communications line of bus  48  can be used in a wide variety of ways to achieve synchronous communication. In one exemplary embodiment, one of the two processors  52  and  44  will send a message to the other processor which uses one of the two communication lines to signal the receipt of each bit by transitioning the state of said communication line from one to zero or from zero to one. 
         [0097]      FIG. 22  is an exemplary and highly simplified block diagram of general processor  52  on  FIG. 3 . General processor  52  is comprised of a CPU  358 , a bus  360 , an I/O subsystem  362 , ROM  364 , SRAM  366 , and EEPROM  368 . I/O subsystem  362  drives display  58 , switches  60 , other I/O  62 , and the interface with magnetic stripe emulator  64 , which sends signal data to the broadcaster and receives sensor data from the broadcaster. Switches  60  include on/off button  28 , and account selector  38 , of  FIG. 2 . 
         [0098]      FIG. 23  illustrates, by way of example and not limitation, a main process of general processor  52 . General processor  52  is initially in an off state when the on/off button  28  is pressed. When the on/off button  28  is released, control is passed from operation  370  to operation  372 . If the amount of time that the on/off button  28  remains pressed exceeds a certain threshold, general processor  52  passes control to operation  374 , which blinks on indicator  30  and off indicator  32 , twice, simultaneously. Control is then passed to operation  370 . At the moment on/off button  28  is pressed, general processor  52  receives power so that it can perform these operations. If on/off button  28  is not released, the on indicator  30  and off indicator  32  continue to blink twice, simultaneously, every two seconds until on/off button  28  is released. 
         [0099]      FIG. 24  shows an exemplary process of operation  372  of  FIG. 23  in greater detail. The process begins with the operation  376  and continues with operation  378 , which initializes the general processor  52 . Then, in a decision operation  380 , a determination is made whether an error has occurred during said initialization operation. If no error has occurred, control is passed to operation  382 , which blinks on indicator  30  twice, and passes control to operation  384 , which enters the menu state. If in operation  380 , an error has occurred, control is passed to operation  386 , which sets an error code to one and blinks off indicator  32  three times. In subsequent operation  388 , control is then passed to operation  390 , which enters an error state. 
         [0100]      FIG. 25  illustrates an exemplary operation  384  of  FIG. 24  in greater detail. The process begins in operation  392 , which discriminates between a number of different events that are induced externally. 
         [0101]    For example, if the on/off button  28  is released or a time-out threshold is exceeded, control is passed to operation  394 , which blinks off indicator  32  twice. Control is, then passed to operation  396 , which enters a shut down state. If, on the other hand, in operation  392 , it is determined that account button one has been pressed, control is passed to operation  398 , which blinks account indicator  36  for account one once. Control is, then, passed to operation  400 , which sets an internal account buffer to one, indicating that the data for account one is to be accessed subsequently. 
         [0102]    Similarly, if it is determined in operation  392  that account selector  38  for account number two has been pressed, control is passed to operation  402 , which blinks the account indicator  36  for account two once. Control is, then passed to operation  404 , which sets an internal account buffer to two, indicating that subsequent account activity should pertain to account two. Likewise, if it is determined in operation  392  that the account selector  38  for account three has been selected, control is passed to operation  406 , which blinks the account indicator  36  for account three once, and passes control to operation  408 , which sets the account buffer to three, indicating that the account data for account three is to be accessed subsequently. Control is, then passed to operation  410 . Steps  400  and  404  also transition to operation  410  upon completion. 
         [0103]    If it is determined in operation  392  that the power button timeout has been detected, control is passed to operation  412 , which blinks on indicator  30  and off indicator  32  twice, simultaneously. Control is, then passed back to operation  392 , which Continues to monitor external events. It is contemplated that additional events and event handlers could be added to the present process, such as operation  414 , which could, for example, detect a chord which would be produced by a combination of buttons on card back  14 . Such a chord could be used, for example, to instruct the card to enter a self-diagnostic mode, or a demonstration mode which flashes various LEDs, or a game mode. In another embodiment, operation  414  could render the card unusable for a period of time or until a special code is entered. Such an embodiment would be useful if, for example, the card were temporarily not in one&#39;s possession. These various alternative embodiments are given by way of example and not limitation. 
         [0104]      FIG. 26  shows an exemplary operation  410  of  FIG. 25  in greater detail. The process begins with operation  416 ; control is passed to operation  418 , which powers up secure processor  44  and performs a handshake to verify that secure processor  44  is operating properly. In decision operation  420 , it is determined whether or not a timeout has expired while waiting for the handshake to be completed. If a timeout does occur, control is passed to operation  414 , which powers off the secure processor  44 . Control is, then passed to operation  416 , which blinks off indicator  32  three times. Control is, then passed to operation  418 , which sets an error code to nine. Once this is completed, control is passed to error operation  420 . If it is determined in operation  412  that a timeout has not expired, control is passed to operation  422  which waits for an “I am here” message from secure processor  44 . Then, in decision operation  424 , it is determined whether or not a timeout has expired while waiting for the “I am here” message. If a timeout has expired, control is passed to operation  426  which powers off secure processor  44 . Control is then passed to operation  428 , which blinks off indicator  32  three times. Then in operation  430 , an error code is set to two and then control passes to error operation  420 . If in operation  424  it is determined that a timeout has not expired, control is passed to decision operation  432 , which determines whether or not a mode is enabled or enabled for self-test. If it is not then control is passed to operation  434 , which powers off secure processor  44 . Control is then passed to operation  436 , which blinks the off indicator  32  three times. Control is then passed to operation  438 , which enters a BIST state. If, in operation  432 , it is determined that mode is enabled or enabled for test, control is passed to operation  440 , which determines whether or not some other error has occurred. If so, control is passed to operation  442 , which powers off secure processor  44 . At this point control is passed to operation  444 , which blinks off indicator  32  three times. Then control passes to operation  446 , which sets an error code. Control is then passed to  420 , which processes the error. If in operation  440  it is determined that no other error has occurred, control is passed to operation  448 , which sends a message to secure processor  44  requesting configuration parameters. Then, in decision operation  450 , it is determined whether or not an error has occurred. If so, control passes to operation  452  which powers off secure processor  44 . Control is then passed to operation  454 , which blinks off indicator  32  three times. Control then passes to operation  456 , which sets an error code and passes control to operation  420 , which processes the error. 
         [0105]    If it is determined in operation  450  that no error has occurred in sending the request for configuration parameters to secure processor  44 , control is passed to operation  458 , which waits for a response from secure processor  44  regarding the request of operation  448 . Then, in a decision operation  460 , it is determined whether or not a timeout has expired. If so, control is passed to operation  462 , which powers off secure processor  44 . Control is then passed to operation  464 , which blinks off indicator  32  three times. Then, in operation  466 , an error code is set to three and control is passed to operation  420 , which processes the error. 
         [0106]    If, in operation  460 , it is determined that the timeout has not expired, control is passed to a decision operation  468 , which determines whether or not another error has occurred. If an error has occurred, control is passed to operation  470 , which powers off secure processor  44 . Then, in operation  472 , off indicator  32  is blinked three times and control is passed to operation  474  which sets an error control and passes control to operation  420 , which processes the error. If, in operation  468 , it is determined that no error has occurred, control is passed to operation  476 , which enters a data state. 
         [0107]      FIG. 27  illustrates an exemplary operation  476  of  FIG. 26  in greater detail. The process begins with operation  478 ; control is then passed to operation  480 , which sends a “Get user data” request to secure processor  44 . Then, in a decision operation  482 , it is determined whether or not an error has occurred while sending the request. If it is determined that an error has occurred, control is passed to operation  484 , which powers off secure processor  44 . Control is, then, passed to operation  486 , which blinks off indicator  32  three times. Then, in operation  488 , an error code is set and in operation  490 , an error state is entered which processes the error. 
         [0108]    If, in operation  482 , it is determined that no error has occurred while sending the request, control is passed to operation  492 , which waits for a response to the request of operation  480 . Then, in a decision operation  494 , it is determined whether or not there has been a timeout while waiting for the response from secure processor  44 . If it is determined that there has been a timeout, control is passed to operation  496 , which powers off secure processor  44 . Control is then passed to operation  498 , which blinks off indicator  32  three times and passes control to operation  500 , which sets an error code to five and passes control to operation  490 , which processes the error. 
         [0109]    If, in operation  494 , it is determined that no timeout has occurred while waiting for the response from secure processor  44 , then, operation  502  powers off secure processor  44 . Then, in decision operation  504 , it is determined whether or not all dynamic authentication codes have been used. If so, control is passed to operation  506 , which blinks off indicator  32  three times and passes control to operation  508 , which sets an error code to six and, then, an error state  490  is entered, which processes the error. 
         [0110]    If, in operation  504  it is determined that not all dynamic authentication codes have been used, control is passed to decision operation  506 , which determines whether or not another error has occurred. If so, control is passed to operation  508  which blinks off indicator  32  three times. Control is, then, passed to operation  510  which sets an error code and control is passed to operation  490 , which processes the error. 
         [0111]    If, in operation  506 , it is determined that no error has occurred, control is passed to operation  512 , which blinks on indicator  30  twice. Then, in operation  514 , the account data which was received from secure processor  44  is placed into the track two buffer. Control is, then, passed to operation  516 , which enters an active state. 
         [0112]      FIG. 28  shows exemplary operation  516  of  FIG. 27  in greater detail. The process begins with operation  518 , which detects various events and dispatches them. If it is determined that a blink timeout has occurred, control is passed to operation  520 , which blinks the account indicator  36  for the selected account once. Then, in operation  522 , the blink timeout is reset and control is passed back to operation  518 . 
         [0113]    If it is determined in operation  518  that an account selector  38  has been selected, control is passed to operation  524 . In decision operation  524 , it is determined whether or not account selector  38  for the currently selected account has been selected. If not, control is passed back to operation  518 . On the other hand, if the account selector  38  for the currently selected account is selected, control is passed to operation  526 , which turns on the on indicator  30 . Then, in operation  528 , the track two data buffer, or alternatively data from the data buffers of multiple tracks is sent to the encoder. Then, in operation  530 , on indicator  30  is turned off. Then, in operation  532 , the timer mode is set to short. Then, in operation  534 , the active state timer is reset and control is passed back to operation  518 . If, in operation  518 , it is determined that a swipe sensor has been triggered, control is passed to operation  526 , which processes the event as previously described in the discussion of operation  526  above. 
         [0114]    If it is determined in operation  518 , that an active state timeout has occurred or on/off button  28  has been released, control is passed to operation  536 , which blinks off indicator  32  twice. Control is, then, passed to operation  538 , which clears the track two data buffer and, then, passes control to operation  540 , which enters a shutdown state. If it is determined in operation  518  that there has been a power button timeout, control is passed to operation  542 , which blinks on indicator  30  and off indicator  32  twice, simultaneously. Control is, then, passed to operation  518 . 
         [0115]      FIG. 29  shows exemplary operation  540  of  FIG. 28 , as well as exemplary operation  396  of  FIG. 25 . It also describes the process labeled as “A” on  FIGS. 30 and 31 . The process begins with operation  544 ; control is passed to operation  546 , which prepares general processor  52  for removal of power. Then, in operation  548 , the power is turned off. At this point, the process enters operation  550 , wherein the card is deprived of power until power is reintroduced. The diagram for this stage is shown on  FIG. 23 , as previously discussed. 
         [0116]      FIG. 30  shows exemplary operation  420  of  FIG. 26  and operation  490  of  FIG. 27  in greater detail. The process starts with operation  552 , which is entered when an error has occurred. Operation  552  waits for various events to occur and dispatches them appropriately. If an account indicator  36  is pressed, control is passed to operation  554 , which ignores the press and controls pass back to operation  552 . If a swipe sensor is triggered, control is passed to operation  556 , which blinks an error code in binary on the various LEDs of card back  14 . Then, control is passed to operation  558 , which resets the blink interval timeout. Control is, then, passed back to operation  552 . If, in operation  552  it is determined that on/off button  28  has been released, control is passed to operation  560 , which blinks off indicator  32  twice. At this point, control is passed to operation  562 , which enters a shutdown state. If it is determined in operation  552  that an error state blink interval timeout has occurred, control is passed to operation  564 , which blinks off indicator  32  once and passes control to operation  566 . In operation  566 , the error state counter is incremented and control is passed to decision operation  568 , which determines whether or not the error state counter is equal to  20 . If so, control is passed to operation  562 , which enters a shutdown state. If it is determined in operation  568  that the error state counter is not equal to  20 , control is passed to operation  570 , which resets the blink interval timeout and passes control back to operation  552 . If it is determined in operation  552 , that a power button timeout has occurred, control is passed to operation  572 , which blinks on indicator  30  and off indicator  32  twice, simultaneously. 
         [0117]      FIG. 31  shows exemplary operation  438  of  FIG. 26  in greater detail. The process begins with operation  574  which waits for various events to occur and dispatches them accordingly. If, in state  574 , it is determined that account selector  38  corresponding to account one has been selected, account indicator  36  for account one is blinked along with the account indicator  36  for account two, on indicator  30 , off indicator  32 , all simultaneously. This is accomplished in operation  576 . If it is determined in operation  574  that the account selector  38  for account two has been selected, or the left swipe sensor, or the right swipe sensor, has been activated, control is passed to operation  578 , which turns on selected LEDs on card back  14  to indicate a version number. Control is, then, passed to operation  580 , which activates track two with test data. At this point, control is passed to operation  582 , which turns off all LEDs. Then, in operation  584 , a timer associated with the BIST state is reset and control is passed back to operation  574 . Likewise, upon completion of operation  576 , operation  584  is entered, which resets this timer and control is likewise passed subsequently passed to operation  574 . 
         [0118]    If it is determined in operation  574  that account selector  38  corresponding to account three is selected, account indicator  36  for account two, along with account indicator  36  for account three, on indicator  30 , and off indicator  32 , are all blinked once simultaneously in operation  586 . Control is then passed to operation  584 , which resets the timer as previously discussed and passes control to operation  574 . If it is determined in operation  574  that there has been a BIST timeout or on/off button  28  has been released, control is passed to operation  588 , which blinks off indicator  32  twice. Control is, then, passed to operation  590 , which enters a shutdown state. If, in operation  574  it is determined that there has been a power button timeout associated with on/off button  28 , control is passed to operation  592 , which blinks on indicator  30  and off indicator  32  twice simultaneously. At this point, control is passed to operation  574 . 
         [0119]      FIG. 32  shows an exemplary process for signal conversion which is used to transform the digital square wave output of general processor  52  into the custom waveforms needed to drive broadcaster  68 . The digital square wave output of general processor  52  is used to drive the RC network of buffering circuit  66  which produces an analog waveform as output. This is, in turn, used to drive broadcaster  68  which produces magnetic impulses to be received by a magnetic stripe reader. 
         [0120]      FIG. 33  shows the exemplary broadcaster  68  of  FIG. 3  in greater detail. In this exemplary embodiment, the broadcaster dynamically creates the magnetic signals which can be read by a conventional magnetic stripe reader. The output waveform is converted herein to compliant magnetic flux reversal broadcast in broadcaster  68 . Broadcaster  68  includes a core of specialty material chosen for its magnetic permeability as well as other chemically related properties. The core is surrounded by the multiple waveform circuit configurations made of another type of specialty material chosen for its electrical and magnetic properties. Cancellation system  594  is shown here which reduces crosstalk of the magnetic field that is broadcast. An advantage of this exemplary embodiment is reduced cross talk in cases where multiple tracks are used. The broadcaster is also comprised of sensors  70  which indicate when a transaction has begun and when the transaction has ended. In the exemplary embodiment shown in  FIG. 33 , the various tracks are labeled “ 1 ” and “ 2 ”. This example should not be construed as a limitation to the number of tracks which can be broadcast by broadcaster  68 . The cancellation tracks are labeled “ 1 ′” and “ 2 ′” to provide cancellation for tracks  1  and  2  respectively. 
         [0121]      FIG. 34  describes an emulated magnetic stripe signal created by the exemplary broadcaster  68  interface. The diagram indicates the temporal and spatial orientation of the broadcaster  68  to the magnetic stripe reader  72  to detect and use the magnetic stripe data. 
         [0122]      FIG. 35  shows a sample of exemplary waveforms generated. These exemplary wave forms are representative only, and demonstrate the relationship between the square wave output of general processor  52  and the analog output of buffer circuit  66 . In an exemplary embodiment, the RCCN takes the output from general processor  52  and uses the Integrated Circuit including its capacitors and resistors to convert the magnetic stripe data that is readable by a conventional magnetic stripe reader. 
         [0123]      FIG. 36  shows an alternative embodiment wherein an application specific integrated circuit (ASIC) referred to hereinafter as ASIC  596 . ASIC  596  is used in place of general processor  52 . In this embodiment, it is contemplated that ASIC  596  includes a digital to analog converter  598 . The analog signal is output to a buffering circuit  66  which outputs an F2F signal; no RC network is needed. In one exemplary embodiment, the ASIC uses alternative means of shaping the broadcast not through a proximate broadcaster but either through a processor with a Digital to Analog converter or by a processor that could effect the wave shape through the circuit. 
         [0124]      FIG. 37  shows an exemplary RC network comprised of resistors and capacitors. RC networks are well known to those skilled in the art. An exemplary embodiment of the RC network enables the proximate broadcasters to send an emulated or simulated magnetic stripe message to the read head of a magnetic stripe reader. 
         [0125]      FIG. 38  shows a waveform of an exemplary broadcaster  68 . The figure indicates the role of the sensor for creating the timing necessary to effect the broadcast in the proper temporal and spatial alignment to the read head so that it can be detected and used to close a financial transaction. 
         [0126]      FIG. 39A through 39D  show exemplary waveforms from both track  1  and track  2  overlaid one upon the other. Alternative means of generating this wave form is either the Digital to Analog processor or the in-circuit cancellation as depicted in  FIG. 36 . 
         [0127]    Although various embodiments have been described using specific terms and devices, such description is for illustrative purposes only. The words used are words of description rather than of limitation. It is to be understood that changes and variations may be made by those of ordinary skill in the art without departing from the spirit or the scope of the present invention, which is set forth in the following claims. In addition, it should be understood that aspects of various other embodiments may be interchanged either in whole or in part. It is therefore intended that the claims be interpreted in accordance with the true spirit and scope of the invention without limitation or estoppel.