Abstract:
An embedded electronic payment (EEP) system allows various devices and appliances to act as a merchant to accept electronic payments. The EEP system can be formed on an integrated circuit or as a software applet to run on a virtual machine. The integrated chip can be a standard IC, an application specific integrated chip, programmable logic device, or a multiprocessor based microcontroller. The EEP system operates with a standard interface that can be adapted to many applications. As a result, the cost of payment integration is reduced. The reduced cost of inclusion allows electronic payment systems to be applied in systems and devices where cost margins previously prohibited custom electronic payment systems. When the EEP system is included as an integrated chip, the system has improved security and power consumption compared to software solutions.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. application Ser. No. 13/937,199 filed Jul. 8, 2013 and claims the benefit of U.S. Provisional Application No. 61/668,960, filed Jul. 6, 2012, which are hereby incorporated by reference. 
     
    
     STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
       [0002]    Not Applicable 
       THE NAMES OF PARTIES TO A JOINT RESEARCH AGREEMENT 
       [0003]    Not Applicable 
       INCORPORATION-BY-REFERENCE OF MATERIAL SUBMITTED ON A COMPACT DISC 
       [0004]    Not Applicable 
       BACKGROUND OF THE INVENTION 
       [0005]    1. Field of the Invention 
         [0006]    The invention relates to devices and systems including and utilizing Embedded Electronic Payment (EEP) systems. 
         [0007]    2. Description of the Related Art 
         [0008]    Credit cards as a form of electronic payment processing traditionally involves the following transaction functions associated with a merchant account implementation which heretofore is implemented in software. 
         [0009]    Authorization: The cardholder presents the card as payment to the merchant and the merchant submits the transaction to the acquirer (acquiring bank). The acquirer verifies the credit card number, the transaction type and the amount with the issuer (Card-issuing bank) and reserves that amount of the cardholder&#39;s credit limit for the merchant. An authorization will generate an approval code, which the merchant stores with the transaction. 
         [0010]    Batching: Authorized transactions are stored in “batches”, which are sent to the acquirer. Batches are typically submitted once per day at the end of the business day. If a transaction is not submitted in the batch, the authorization will stay valid for a period determined by the issuer, after which the held amount will be returned to the cardholder&#39;s available credit (see authorization hold). Some transactions may be submitted in the batch without prior authorizations; these are either transactions falling under the merchant&#39;s floor limit or ones where the authorization was unsuccessful but the merchant still attempts to force the transaction through. (Such may be the case when the cardholder is not present but owes the merchant additional money, such as extending a hotel stay or car rental.) 
         [0011]    Clearing and Settlement: The acquirer sends the batch transactions through the credit card association, which debits the issuers for payment and credits the acquirer. Essentially, the issuer pays the acquirer for the transaction. 
         [0012]    Funding: Once the acquirer has been paid, the acquirer pays the merchant. The merchant receives the amount totaling the funds in the batch minus either the “discount rate,” “mid-qualified rate”, or “non-qualified rate” which are tiers of fees the merchant pays the acquirer for processing the transactions. 
         [0013]    Chargebacks: A chargeback is an event in which money in a merchant account is held due to a dispute relating to the transaction. Chargebacks are typically initiated by the cardholder. In the event of a chargeback, the issuer returns the transaction to the acquirer for resolution. The acquirer then forwards the chargeback to the merchant, who must either accept the chargeback or contest it. 
         [0014]    An acquiring bank (or acquirer) is the bank or financial institution that processes credit and or debit card payments for products or services for a merchant. The term acquirer indicates that the bank accepts or acquires credit card payment from the card-issuing banks within an association. 
         [0015]    For a software or developer to create software and hardware applications to work with a particular acquirer, the acquirer will require that the application be reviewed and certified before the application can be distributed. 
         [0016]    Development of a particular electronic payment system requires significant labor, cost, development time, and certification time. Furthermore, a given electronic payment system is difficult to apply to situations other than the originally-intended application (i.e. inflexible). Different credit card transaction acquirers set different requirements with which a particular electronic payment system may not be compatible. A particular payment system will provide a particular security level that may not be acceptable in other applications. Upgrading a particular electronic payment system may be costly and/or impossible. 
         [0017]    Development effort is steep for implementing a payment processing, or merchant account interface. There are number of acquirers: e.g. TSYS, Global Payments, First Data, Paymentech, and Heartland, etc. Each acquirer has its own unique protocol that must be implemented through software code and compiled for a particular platform, e.g. Windows or Android. Acquirers exist for various electronic payment systems, not just credit cards. 
         [0018]    In software electronic payment systems, discrete software development efforts are needed for each implementation. Then, each acquirer requires certification and security assessments. 
         [0019]    High development costs of software electronic payment systems prevent the inclusion of such solutions as commodities into appliances, computers, phones, etc. 
         [0020]    Certification. Each acquirer requires its own certification of a particular electronic payment system. Examples of acquirers requiring specific certifications are TSYS, Global Payments, First Data, Paymentech, and Heartland. 
         [0021]    The costs of development prevent the inclusion of electronic payment systems on particular devices that otherwise might be used to receive payments. 
         [0022]    Security is a big concern surrounding electronic payments. Software payment applications and utilizing devices are largely implemented on operating systems such as Windows® and Linux with full software stacks. These stacks have interfaces that expose the implementations to hacking, malware, and other intrusions. 
       BRIEF SUMMARY OF THE INVENTION 
       [0023]    The invention encompasses an embedded electronic payment system and an integrated circuit implementing, employing, and enabling an embedded electronic payment system merchant account. 
         [0024]    An object of the invention is to provide two solutions for simplifying development of payment processes with particular acquirers. A first solution is to provide a standard transaction protocol module that will implement a standard interface to various participating acquirers. A second solution is to provide a programmable transaction module that can be programmed via a programming interface and an application programming interface (API) to implement a desired specific protocol. 
         [0025]    The data that is to be processed is received from a payment instrument. Payment instruments is a term meant to include data sources that deliver account information for a transaction. Examples of payment instruments include credit cards, other payment cards, fobs, mobile wallets, and the like. 
         [0026]    A further object of the invention is to reduce development time for adding payment processing to any device. By providing the EEP chip, engineers can add the EEP chip to the device hardware configuration along with interfaces to card readers, security programming, and networks, thereby embedding merchant account payment transaction ability into the device. 
         [0027]    A further object of the invention is to encourage inclusion of the electronic payments capability in more appliances by lowering the inclusion cost for payment processing. As discussed, the availability of the EEP chip will reduce the cost to appliance developers. Reduced costs will allow for inclusion in devices with tight pricing margins where large marginal costs of otherwise including payment processing would be prohibitive. 
         [0028]    By providing an EEP chip, appliance (i.e. devices generally) manufacturers can add electronic payment acceptance to any appliance with a printed circuit board and standard chip implementation design. Furthermore, because the EEP chip is prequalified by the electronic payment transaction acquirer, the appliance manufacture does not need to have the particular appliance approved by the acquirer. In addition, the EEP chip provides the additional security of using a hardware stack for its encryption and decryption. 
         [0029]    For example, a vending machine can be adopted to take credit card payments by incorporating the EEP chip on a circuit board in the vending machine, essentially making the vending machine a merchant. An interface for reading credit card data can be added to the outside of the vending machine and connected to the circuit board to feed transaction data. The vending machine is then connected via a suitable network to the electronic payment transaction acquirer. The EEP chip creates encrypted approval request data to be sent to the acquirer. When the acquirer approves the transaction, the acquirer sends encrypted acquirer transaction data to the EEP chip. The EEP chip decrypts the encrypted acquirer transaction data and approves the transaction. The EEP chip instructs the vending machine to dispense the goods. In this way, a customer can use his credit card to buy the goods. More importantly, the vending machine manufacturer can add the electronic payment functionality with built-in approval by the acquirer, by virtue of using the EEP chip. 
         [0030]    A further object of the invention is to simplify the acquirer certification process. Implementing the payment engine in a chip makes the certification process simple. The certification can be provided to the chip. Then, developers of appliances that utilize the certified chip will not need to certify their end appliances; the chip carries the certification. 
         [0031]    A further object of the invention is to provide a flexible payment acceptance system. Flexibility is addressed in two ways: either with an industry standard acquiring interface protocol or a programmable one. In a standard acquiring interface protocol, the standard can be designed with built-in flexibility, such as register setting for various values. In the programmable side, the protocol can be fully programmable even as a proprietary protocol. This programmability can also be accomplished in a virtual machine running on an embedded microcontroller. 
         [0032]    A further object of the invention is to increase the types of devices that can accept electronic payment. Existing devices can be modified to include the EEP chip in the device so that the device can take payments. Therefore, many different devices can have electronic payment capability built in. Existing devices can be upgraded or re-commissioned to include the EEP chip. 
         [0033]    A further object of the invention is to increase the security in devices that accept electronic payments. Embedding the payment layers in an integrated circuit (i.e. chip) is a much more secure implementation than software implementations. The stack in a chip implementation is virtually inaccessible. 
         [0034]    A further object of the invention is to reduce to practice the interfaces and protocols required for conducting electronic payments with an acquirer of electronic transactions, to an integrated circuit (IC), for use in embedded applications. This IC, or chip, can be implemented in the circuitry of devices/appliances to allow that device to “take” an electronic payment from a user. For example, a home appliance manufacturer like GENERAL ELECTRIC® could add the EEP chip to the circuitry of its laundry appliances to enable the laundry appliances to accept electronic payment, e.g. credit card payment, with a built-in (i.e. not a separate) device. Another example would be point of sale kiosks where the devices could include EEP Chips embedded in their circuitry for taking electronic payments. Even an automobile could be a merchant and take payments services, songs, maps, fares, etc. 
         [0035]    The solution also can be implemented as a design module available to be added to the design of another chip, much like an ALU or memory is a library module that a chip designer can add to an Application Specific Integrated Chip (ASIC). The EEP Chip also can be included in the design of computer-based systems or adapter cards or the like for easy implementation of a merchant account for taking electronic payments. 
         [0036]    Today, typically, there are a number of layers of software required for securing, registering, and conducting payment transactions. The process for creating an implementation to allow a merchant&#39;s device to transact is very cumbersome, time consuming, and requires many man hours. Processor certification and security validation of each software implementation is tedious and costly. The transaction path is also subject to potential intrusion as it is made up of some open/common interfaces/buses etc., this poses significant security risk and liability that has proven to be costly. 
         [0037]    In view of the objects, an apparatus adds embedded electronic payment taking to an appliance. The apparatus includes an integrated circuit with inputs and outputs. The number of physical inputs and outputs can be reduced by utilizing multipurpose input/output ports. The integrated circuit has a first input configured to receive data from a payment instrument, such as credit-card data. A first output is configured to transmit approval-request data to an electronic payment transaction acquirer. A second input is configured to receive acquirer transaction data from the acquirer. A second output configured to transmit customer transaction data. The integrated circuit is programmed to process the payment data received at the first input into approval-request data for processing by the transaction acquirer and to transmit the approval-request data from the first output. The integrated circuit is further programmed to process the transaction data received at the second input into the customer transaction data and to transmit the customer transaction data from the second output. 
         [0038]    The integrated circuit can be programmed or designed to process credit-card data into approval-request data for processing by a transaction acquirer. The phrase “programmed or designed” is to include dynamic and static implementations of an integrated circuit. 
         [0039]    A further object of the invention is to provide a system with an EEP Chip. The system would enable any EEP-enabled device/appliance to be a standalone access point for taking electronic payments. Examples of potential devices and appliances are cell phones and other wireless devices. This eliminates the requirement for the more typical “heavy” connectivity to a network device or gateway for secondarily conducting the transaction with the acquirer. As shown in  FIG. 2 , another example is an EEP-enabled map kiosk  400  in the middle of a mountain trail for the purchase of selling hiking maps. The kiosk  400  with EEP is essentially a merchant, with a merchant account, much like any retail store. The kiosk  400  includes a printed circuit board (PCB)  403 . A chip with an embedded electronic payment chip is connected to the PCB  403 . A card reader  401  is connected to the PCB  403  to provide transaction data. A cellular data interface  404  is connected to the PCB  403  for transmitting approval-request data via a cellular antenna  405  across the world wide web  406  to the acquirer  407 . If the transaction is approved by the acquirer  407 , approval information is transmitted to the PCB  403 , which then triggers the map dispenser  402  to dispense a map. A solar panel  408  is included to power the kiosk  400 . 
         [0040]    Other features of the invention are set forth in the appended claims. 
         [0041]    Although the invention is illustrated and described herein as embodied in an embedded electronic payment system and an integrated chip for electronic payment processing, the invention is not limited to the details shown because various modifications and structural changes may be made without departing from the invention and the equivalents of the claims. However, the construction and method of operation of the invention together with additional objects and advantages thereof will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 
         [0042]      FIG. 1  is a schematic view of an embedded electronic payment system according to the invention. 
           [0043]      FIG. 2  is a schematic view of a solar powered map dispenser with an embedded electronic payment system according to the invention. 
           [0044]      FIG. 3  is a schematic view of a security element according to the invention. 
           [0045]      FIG. 4  is a schematic view showing the encryption and decryption of data in the security element. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0046]    Embodiments of the invention are described below and are shown in the figures of the drawing. 
         [0047]    There are at least four different embodiments of the invention. 
         [0048]    First, the embedded electronic payment (EEP) module can be embodied as an integrated circuit (IC) or application specific integrated circuit (ASIC) for use on printed circuit boards (PCB) as part of a device or appliance. Examples of devices and appliances include a personal computer (PC), a washing machine, a vending machine, a television set-top box, a telephone, an entryway access control device, a jukebox, an automobile, a train, an arcade, etc. 
         [0049]    Second, the EEP module can be embodied as a design element in a design element library for design into other integrated circuits, e.g. a microcontroller, so that the embedded payment function can be part of that chip. 
         [0050]    Third, the EEP module can be embodied as a library element that can be “burned” into a programmable logic device such as those available from Altera or Xilinx, which allow for flexible design of PCBs as required by the over system engineer, as typical where programmable logic is used, even on demand. 
         [0051]    Fourth, the EEP module can be embodied as a portable applet (i.e. a single purpose application), such as one to be run in a virtual machine such as JAVA® and the like. In such applets, the embedded electronic payment engine can be loaded into an on-demand run-time engine, e.g. Java Virtual Machine. 
         [0052]    The embedded electronic payment functionality can be described using schematics, VHDL, a high level programming language, or any other generic or specific descriptive design-entry means that can be reduced (synthesized, compiled, or interpreted) into the form that is required for any of the above. 
         [0053]    VHDL (VHSIC (very-high-speed integrated circuit) hardware description language) is a hardware description language used in electronic design automation to describe digital and mixed-signal systems such as field-programmable gate arrays and integrated circuits. 
         [0054]    The above embodiments are different from the traditional “software stack” that is typical of payment applications that are compiled or interpreted software solutions that run from memory on a generic microprocessor-based system, such as a credit card terminal or point of sale (POS) computer. 
       Security Element 
       [0055]      FIGS. 1 and 3  show a preferred embodiment of an embedded electronic payment (EEP) chip  100 . The embedded electronic payment chip  100  is a plate of semiconductor material, preferably silicon, with a set of electronic circuits formed in the semiconductor material. The embedded electronic payment chip  100  includes a tamperproof security element  101 . 
         [0056]    An important component to the EEP chip  100  is the tamperproof Security Element (SE)  101  (SE), which also can be referred to as the security module. The SE  101  performs entitlement control and transaction data encryption and decryption. 
         [0057]    Subject to possible standardization of details by payment industry consortia, the security element  101  provides for secure validation of a device&#39;s entitlement to transact and secure processing of transactions. 
         [0058]    In a preferred embodiment, entitlement control is accomplished by seeding a unique encrypted public key (EPK)  102  into each device&#39;s SE  101  at the time of manufacture of the EEP chip  100  itself In an alternate embodiment, the encrypted public key  102  is programmed into the SE  101  at the time of assembly into an appliance via a secure interface  208 . The secure interface  208  is preferably a one-time write interface. 
         [0059]    Depending on desired entitlement control, an electronic payment transaction acquirer provides a private key (PVK)  103  to the EEP chip  100 . The private key  103  is stored in the security element  101 . The private key  103  can decrypt the encrypted public key (EPK) to create a decrypted public key or more-simply a public key (PK). The private key  103  is generated with public key and is kept by the device manufacturer or acquirer. Entitlement messages (EM) determine which transactions the embedded electronic payment chip  100  is entitled to process on behalf of the electronic payment transaction acquirer. For example, the presence and/or absence of particular entitlement messages enable whether the EEP chip  100  will accept debit payments, credit-card payments, or other types of payments, or not. Encrypted entitlement messages (EEM)  105  contain decrypted entitlement keys or more simply Entitlement Keys (EK)  106  and are decrypted in the security element  101  using the decrypted public key  104 . A computer program for decrypting entitlement keys (i.e. a decrypter)  107  with the public key  104  is stored in the security element  101 . Encrypted Entitlement Messages can be provided by an entitlement server controlled by the electronic payment transaction acquirer at design time or at another time, for example, at a periodic upgrade or transaction time. 
         [0060]    The embedded electronic payment chip  100  will encrypt Transaction Data (TD)  109  when authorized according to the entitlement keys (EKs)  106 . Examples of typical transaction data include payment account identifiers, transaction amount, terminal identifiers, and the like. Transaction data can be entered, for example, from an attached device such as a credit-card reader, a computer, telephone, smartphone, appliance, or the like. Transaction data can further include approval information such as approvals, denials, and transaction limits. 
         [0061]    Yet another layer of encryption is possible (if desired) where the Transaction Data is encrypted with Encrypted Control Words (ECW)  110  that are encrypted themselves by the Entitlement Keys (EK)  106 . A computer program for encrypting (i.e. an encrypter)  108  the transaction data with the encrypted control words is stored in the security element  101 . Control words are the beginning of the transaction encryption chain, as opposed to an entitlement encryption chain. Control words are used in the encryption of transaction data. Control words are encrypted in the ECW for use later to decrypt the encrypted transaction data. 
         [0062]    The relationships between encrypted data and decrypted data are shown in the following functions and is further illustrated in  FIG. 4 . In the functions x represents a decrypt function, preferably, 3DES or AES, but could be another cryptography algorithm. In cryptography, 3DES, also known as Triple DES, is the common name for the Triple Data Encryption Algorithm (TDEA or Triple DEA) block cipher, which applies the Data Encryption Standard (DES) cipher algorithm three times to each data block. The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001. 
         [0000]    
       
      
       PK=EPK×PVK  
      
     
         [0000]    
       
      
       EK=EEM×PK  
      
     
         [0000]    
       
      
       CW=ECW×EK  
      
     
         [0000]    
       
      
       TD=ET×CW  
      
     
         [0063]      FIG. 4  shows how data is being encrypted and decrypted by the security element. An entitlement server  300  connected to the security element provides entitlement keys. Control words  301  are generated from the transaction data. Control words  301  are used for transaction encryption  302  of the transaction data. For added security, ECW encryption  303  can be added by encrypting the control words  301  using an entitlement key from an entitlement server  300  to create encrypted entitlement control messages  304 . The encrypted transaction data and/or to encrypted entitlement control messages can be transmitted to a multiplexer  305 , which in turn can be connected to a GPIO. 
         [0064]    The SE can implement failsafe messages that can kill a rogue device by altering its entitlement. 
         [0065]    The EEP chip  100  includes the following additional features. The additional features are exemplary and are not necessarily required in other embodiments. A controller interface  220  receives information regarding addressing of data and timing. The controller interface  220  is comprised of an address bus interface  201  for connecting to an address bus, a data bus interface  202  for connecting to a data bus, a clock/control interface  203  for connecting to a system clock and control signals. A card interface  230  provides interfaces for various payment instrument devices. The card interface  230  includes an EMV PED Interface  204 . EMV stands for EMV stands for Europay, MasterCard and Visa, a global standard for inter-operation of integrated circuit cards (IC cards or “chip cards”) and IC card capable point of sale (POS) terminals and automated teller machines (ATMs), for authenticating credit and debit card transactions. The card interfaces  230  include a serial interface  205 . The card interface  230  may include other payment interfaces  206 . The EEP chip  100  includes a chip power/clock/control  212 . The EEP chip  100  has a network interface  240  for sending and/or receiving data from the electronic payment transaction acquirer. The network interface  240  includes a Wi-Fi interface  209 , a cellular interface  210 , and other network interface  211 . The EEP chip  110  includes a General Purpose Input/Output (GPIO)  250 , which is a generic pin on the chip  100  whose behavior (including whether it is an input or output pin) can be programmed. The EEP chip  100  includes a CPU/microcontroller  260 . The EEP chip  100  includes memory  270 , in particular, RAM, ROM, and protocol ROM. 
       Abbreviations: 
       [0066]    ECW=Encrypted Control Words 
         [0067]    EEP=Embedded Electronic Payment 
         [0068]    EEM=Encrypted Entitle Messages 
         [0069]    EK=Entitlement Keys 
         [0070]    EM=Entitlement message 
         [0071]    EPK=Encrypted Public Key 
         [0072]    PK=Public Key 
         [0073]    PVK=private key 
         [0074]    SE=Security Element or Security Module 
         [0075]    TD=Transaction Data