U.S. patent application number 13/937199 was filed with the patent office on 2014-01-09 for embedded electronic payment system and integrated circuit.
The applicant listed for this patent is Terry L. Glatt. Invention is credited to Terry L. Glatt.
Application Number | 20140012762 13/937199 |
Document ID | / |
Family ID | 49879273 |
Filed Date | 2014-01-09 |
United States Patent
Application |
20140012762 |
Kind Code |
A1 |
Glatt; Terry L. |
January 9, 2014 |
Embedded Electronic Payment System and Integrated Circuit
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.
Inventors: |
Glatt; Terry L.; (Pompano
Beach, FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Glatt; Terry L. |
Pompano Beach |
FL |
US |
|
|
Family ID: |
49879273 |
Appl. No.: |
13/937199 |
Filed: |
July 8, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61668960 |
Jul 6, 2012 |
|
|
|
Current U.S.
Class: |
705/65 ;
705/41 |
Current CPC
Class: |
G06Q 20/18 20130101;
G07F 7/0873 20130101; G06Q 20/353 20130101; G06Q 20/30 20130101;
G06Q 20/3829 20130101; G06Q 20/40975 20130101; G06Q 20/40 20130101;
G06Q 20/3563 20130101; G07F 7/088 20130101; G06Q 20/341
20130101 |
Class at
Publication: |
705/65 ;
705/41 |
International
Class: |
G06Q 20/34 20060101
G06Q020/34 |
Claims
1. An integrated circuit for processing payment instrument and
transaction data into approval-request data that is to be evaluated
by a payment transaction acquirer, a processor, or a payment
instrument issuer, comprising: a plate of semiconductor material; a
set of electronic circuits on said plate of semiconductor material,
said set of electronic circuits defining a hardware stack of memory
and a logic unit for implementing a merchant account protocol
required for interacting with the payment transaction acquirer, the
payment processor, or the payment instrument issuer; an input for
receiving said payment instrument data, said input being connected
to said logic unit and said memory; and an output for sending
approval-request data to the electronic payment transaction
acquirer, the payment processor, or the payment instrument issuer,
said output being connected to said logic unit and said memory.
2. The integrated circuit according to claim 1, wherein: said set
of circuits further defines a security element including: an
encrypted public key stored in said memory; said memory being
configured to store a private key sent by the electronic payment
transaction acquirer, the payment processor, or the payment
instrument issuer, said private key being configured to decrypt
said encrypted public key into a decrypted public key; a first
logic unit being configured to decrypt said encrypted pubic key
with said private key to produce the decrypted public key, said
memory being configured to store said decrypted public key; said
memory being configured to store an encrypted entitlement message
from the payment acquirer; a second logic unit for decrypting said
encrypted entitlement message with said decrypted public key to
produce a decrypted entitlement message, said memory being
configured to store said decrypted entitlement message; said memory
being configured to store the payment instrument and transaction
data; and a third logic unit for encrypting said payment instrument
data with said decrypted entitlement message to create encrypted
approval-request data, said memory being configured to store said
encrypted approval-request data; said input for receiving said
payment instrument and transaction data, said input being connected
to said logic units and said memory; and an output for sending said
encrypted approval-request data to an electronic payment
transaction acquirer, a processor, or a payment instrument issuer,
said output being connected to said logic units and said
memory.
3. The integrated circuit according to claim 2, wherein: said input
receives encrypted acquirer transaction data from the electronic
payment transaction acquirer, the processor, or the payment
instrument issuer; and said memory of said security element stores
a fourth logic unit for decrypting the encrypted acquirer
transaction data into customer transaction data by using said
decrypted public key.
4. The integrated circuit according to claim 1, wherein said plate
of semiconductor material and said set of electronic circuits are a
programmable logic device.
5. The integrated circuit according to claim 4, wherein said
programmable logic device is programmable using VHDL.
6. The integrated circuit according to claim 2, further comprising
a secure interface for inputting said unique encrypted public key
to said memory.
7. The integrated circuit according to claim 6, wherein said secure
interface is a one-time write interface.
8. The integrated circuit according to claim 1, wherein said third
logic unit encrypts said control words with said entitlement key to
form an encrypted control word and said third logic unit utilizes
said encrypted word when encrypting said payment instrument
data.
9. An appliance for processing electronic payments, comprising a
printed circuit board with an interface configured to connect to
the integrated circuit according to claim 1; said interface having
an output to be connected to the input of the integrated circuit,
said output being further configured to transmit the payment
instrument data to the integrated circuit; and said interface
further having an input to be connected to the output of the
integrated circuit said input being further configured to transmit
the encrypted approval-request data to the electronic payment
transaction acquirer, the payment processor, or the payment
instrument issuer.
10. The integrated circuit chip according to claim 1, wherein said
payment instrument and transaction data is selected from the group
consisting of credit card data, payment card data, fob data, memory
device data, smartcard data, and mobile wallet data.
11. The integrated circuit according to claim 1, wherein said plate
of semiconductor material and said set of electronic circuits form
a microprocessor.
12. The integrated circuit according to claim 1, wherein said plate
of semiconductor material and said set of electronic circuits form
an application specific microcontroller.
13. The integrated circuit according to claim 1, wherein said set
of circuits define a controller interface.
14. The integrated circuit according to claim 1, wherein said set
of circuits define a payment instrument interface.
15. The integrated circuit according to claim 1, wherein said set
of circuits define a general purpose interface.
16. The integrated circuit according to claim 1, wherein said set
of circuits define a network interface.
17. A system, comprising: the integrated circuit according to claim
1; and a security element external to said integrated circuit and
interfaced with the integrated circuit.
18. A method for processing payment instrument and transaction data
into approval-request data that is to be evaluated by a payment
transaction acquirer, a processor, or a payment instrument issuer,
which comprises: providing the integrated circuit according to
claim 1; receiving the payment instrument and transaction data at
said input; processing said payment instrument and transaction data
into said approval request data with said logic unit; and
outputting said approval request data from said output.
19. A method for processing payment instrument and transaction data
into approval-request data that is to be evaluated by a payment
transaction acquirer, a processor, or a payment instrument issuer,
which comprises: providing the integrated circuit according to
claim 2; receiving the private key; decrypting said encrypted
public key with said first logic unit; receiving the encrypted
entitlement message; decrypting said encrypted entitlement message
with said second logic unit; receiving the payment instrument data;
encrypting the payment instrument data with said third logic unit;
and transmitting said encrypted approval request data to the
payment acquirer.
20. A method for making an integrated circuit for processing
payment instrument and transaction data into approval-request data
that is to be evaluated by a payment transaction acquirer, a
processor, or a payment instrument issuer, which comprises: writing
a first hardware description program for decrypting a public key
with a private key that complies with VHDL; configuring a
programmable logic controller to create said first logic unit based
on said first hardware description program; writing a second
hardware description program for decrypting an encrypted
entitlement message with a decrypted public key that complies with
VHDL; configuring said programmable logic controller to create said
second logic unit based on said second hardware description
program; writing a third hardware description program for
encrypting payment instrument data with a decrypted entitlement
message that complies with VHDL; configuring a programmable logic
controller to create said third logic unit based on said third
hardware description program; and embedding an encrypted public key
in said programmable logic controller.
21. The method according to claim 16, wherein said programmable
logic controller includes a write-once interface and said encrypted
public key is written in said programmable logic controller.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 61/668,960, filed Jul. 6, 2012, which is 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'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'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'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.RTM. 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.RTM. 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'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.RTM. 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.
[0055] Security Element
[0056] 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.
[0057] 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.
[0058] Subject to possible standardization of details by payment
industry consortia, the security element 101 provides for secure
validation of a device's entitlement to transact and secure
processing of transactions.
[0059] In a preferred embodiment, entitlement control is
accomplished by seeding a unique encrypted public key (EPK) 102
into each device'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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
PK=EPK.times.PVK
EK=EEM.times.PK
CW=ECW.times.EK
TD=ET.times.CW
[0064] FIG. 4 shows how data is being encyrpted 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 transactio ndata. 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
enctrypted 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.
[0065] The SE can implement failsafe messages that can kill a rogue
device by altering its entitlement.
[0066] 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.
[0067] Abbreviations:
[0068] ECW=Encrypted Control Words
[0069] EEP=Embedded Electronic Payment
[0070] EEM=Encrypted Entitle Messages
[0071] EK=Entitlement Keys
[0072] EM=Entitlement message
[0073] EPK=Encrypted Public Key
[0074] PK=Public Key
[0075] PVK=private key
[0076] SE=Security Element or Security Module
[0077] TD=Transaction Data
* * * * *