TITLE
A Low – value Digital Payment System with separate storage Compartment
FIELD OF INVENTION
The invention relates to a Digital Payment eco system through one 5 single card comprising of
dual payment systems; payments through contact (ATM/ EMV and POS transactions) and
contactless payment system. The said card also consists of separate secure storage areas/ service
compartments which can be owned by the acquirer to implement special functions alongwith
EMV based payments on specific terminal along with creating or modifying the said storage
10 areas/service compartment to let the merchants use their own space on the card. The said card
can be issued as debit card, credit card or prepaid card with stored value.
Further, the said ecosystem provides for a low value payment system to facilitate a cashless
transaction environment which can work in online mode as well as offline mode.
15 BACKGROUND AND PRIOR ART
With the new era of personal digital assistant system various digital payment system for low –
value transaction through smart phones, Lap-tops, and other wireless systems, mobile and user
friendly digital payment systems are at forefront
20 The consumers and end –users are no longer restricted by location with regards to
communications and their individual computing - needs. Consumers are relying predominantly
on user friendly digital payment system, as a whole the society at large and industry is moving
towards virtual payments, challenges and opportunities spring-up.
Payment processing industry is facing many challenges like fraud, interoperability, difficulties,
25 etc., with E-commerce spreading its wings this has become more severe.
3
The payment processing industry is also looking for solutions that can help deal with all the
challenges, which can result in fast, lowered cost of processing transactions and increased
customer satisfaction.
Patent US20080156873A1 provides an automatic fare collection (AFC) systems and methods
for transit systems based on the use of RFID-enabled contactless 5 payment cards issued by
commercial card issuers. The RFID-enabled contactless payment cards conform to open industry
standards (e.g., ISO 14443 Standard) for contactless payment cards
Patent US20060287964A1 discloses a contact/contactless interface Smart card processor and a
QChip MEMS magnetic device embedded in part of a magnetic stripe to support both the
10 existing magnetic-stripe type legacy payment card systems and infrastructure, and the newer
contact/contactless Smart card systems and infrastructure.
Patent US660965 provides a smart card system and method for providing a smart card for
serving travel-related and entertainment-related functions which also facilitates automatic fare,
15 fee and toll payment for such travel-related and entertainment-related functions. It also provides
a system and method for using a smart card with contact and contactless interfaces to pay fares,
fees and tolls and a contact interface for obtaining information.
However, none of the said inventions discloses payment through offline mode, or disclose any
20 offline transaction balance stored in the card or has any facility for storage areas wherein
information can be stored and which can be used in offline mode for both financial and nonfinancial
transactions.
The present Invention is an attempt to provide a dual interface payment
25 application for various retail payments through contact and contactless interfaces at merchant
Point of Services (PoS) terminals with an extended feature for a store value cards.
The present invention provides for both online and offline digital payment system with
interoperability and High transaction speed, thereby having increased customers convenience, as
it would allow them to use the same card for all payments i.e. tickets at metros / buses, passes of
30 various transit operators, payments in cafeteria, pay at parking, toll or at college campus .
4
The present invention also has extended feature known as Service, which enables different transit
operators, acquirers, merchants to create and use their own space on the card to build specific
programs. This data can be of payment related or non-payment related. This can be Open loop,
Semi Closed loop or closed loop as per the business model. This also have capabilities to store
multi level Wallets in the card, which can be used for any 5 low value payment in offline mode.
OBJECT OF THE INVENTION
The primary object of the Invention is to provide for a dual digital Payment eco system which is
vendor agnostic, scaleable, inter-operable, secured, user friendly and cost effective for
10 facilitating low-value payments.
It is yet another object of the invention to provide a mechanism for low value payments within
the gambit of electronic payments i.e. one card many benefits system.
It is yet another object of the invention to provide a digital payment mechanism with separate
secure storage areas/ service compartments which are owned by merchants and can be modified
15 by the said merchants accordingly.
SUMMARY OF INVENTION
The present invention is intended to be used in both payment and transit or any low value
payment. This dual Interface EMV Card can be issued as Debit or Credit card with an extended
20 feature of pre-paid or stored value cards. This card can work in Offline and Online mode and
also have capabilities to store multi level Wallets, which can be used while Offline transactions
are being done. These Cards shall come with a special feature that would enable Acquirers or
Service Owners to own independent memory blocks on the payment device. These blocks of
memory are referred to as “Service areas “and their own specific programs are called “Services”.
25 This is a reserved space on card for acquirer or operator specific program implementation. The
payment data storage is isolated from any other Service related data. Each service area or
memory block on the card are protected by specific keys that can be accessed only by
5
acquirer/transit operator who owns it. Data modification to the service area is controlled through
various security procedures which involve data integrity and data authentication checks. These
security checks require various keys to be derived at various points during the process. Although
transit applications are described in detail herein, other non-payment and/or venue access
transactions like loyalty, parking, toll etc. can be programmed in these areas 5 as per their business
needs and as per agreements with the card Issuer.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a Payment transaction overview diagram that describes the payment transaction
10 authorisation flow involving entities like Issuer, Acquirer, Payment system.
Figure 2 shows schematic view of the payment card architecture. The said payment system is
based on the card specification, further down which is based on the EMV & ISO specifications
Figure 3 is a representation diagram of the Service Architecture in the payment card.
Figure 4 describes flow for service creation on card through issuer’s approval.
15 Figure 5 shows Logical relation between Global balance, local balance and Host balance
Figure 6 is a pictorial representation of the architecture of the contactless terminal
Figure 7 is a process work flow of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
20 The present invention will now be described with the help of the accompanying drawings
However, the drawings only illustrate the invention and in no way limit the invention.
The invention provides for a dual interface specification which is predominantly based on EMV
Open Standard for Cards, Terminal and Mobile Devices. It supports both Contact & Contactless
25 transactions across the EMV payment ecosystem with an extended feature for a multi-levelled
6
store value cards. It supports Card based and Account based Online & Off-line transactions. This
has capabilities to perform high value and low value transactions as per the EMV guidelines for
the retail payments, also supports EMV Offline capabilities to perform low value transactions
such as in transit, toll, parking etc. This specification also has capabilities to perform Payment,
Non-Payment or proprietary programs on the Card/Mobile in an open-5 loop, semi-closed loop or
close loop as per the need of the Issuer. These devices (card/mobile) can also be used as ID
Cards. Other non-payment secure details like PAN Card, driving license etc. can also be stored
into the Card and can be retrieved only by the Authorised Service Owner.
10 In a preferable embodiment of the said invention, as per Figure 2 of the description the
contactless card architecture is built in a plurality of layers preferably the layers being of four
kind:
1) ISO / IEC Specifications: The said specification covers the basic smart card functionality
including the communications which are performed to and from the card, electrical
15 characteristics, the logical interface, and the transmission protocols of the card product
containing EMV Applications.
2) EMVCo Specifications: These cover the core EMV functionality, including the way in which
messages are structured as well as the core processing concepts.
20 3) Chip Specifications: The said layer comprises of specifications and processing requirements,
which are based on the said EMV and ISO/IEC Specifications.
4) Contactless Application: The said layer comprises of specifications and processing
requirements to carry out the contactless payment functionality. The said layer also possesses the
25 requirements for records are generated and stored in said storage areas/ service compartments.
In essence, the system is built over on EMV standards with certain proprietary features as
follows:-
7
A) Storage Areas/ Service Compartments
B) Offline Balance Management
A) 1) Storage Areas/ Service Compartment
The present invention comprises of a feature that enable Acquirers or Service 5 Owners to create
and use their own space on the card, referred to as Service Compartment or just Service and the
area that holds all the Services is referred to as Service Area.
The said service area/compartment or memory block on the card can be accessed only by the
acquirer/service operator who owns the key to that service area. There may exist multiple
10 independent service areas on the same payment device catering to different business
implementations of same or multiple acquirers. The said payment card comprises of a maximum
number of service areas that can be made available to the acquirer or the service operator as well
as the maximum number of service that can be supported on a single card.
As per the preferable embodiment of the said invention, a maximum of 20 services on card can
15 be enabled to ensure maximum performance of the said card with minimum optimization.
With regard to the storage space of the said service compartment, each service can store a
maximum data of 96 bytes and hence the Service Area must be equal to the maximum number of
services to be supported multiplied by 96 bytes. The acquirers/service operators may write their
20 own specific programs or data called as per their business needs and as per agreements with the
card Issuer. Further each Service area in card will be referred by a unique “service ID”.
Further, the said service can be written on the card only post issuance of card. To create a
permanent service on the card, the requisite permission from the card Issuer will be mandatory
25 With regard to security, the said service areas are protected against any unauthorized access
using a security algorithm and a service key which will be unique for each service. The said
service key will let the service owner/operator update only their own Service area and any other
service area cannot be accessed by that service operator.
30
8
A) 2) Service Architecture
For each Service created on the Card, a data is generated and stored in the Service area specific
to that service. a unique Service Directory is maintained by the said Card which contains
information about the services present in the Service Area. 5 The Composition of Service
Directory Header is as defined below:
Service Version: This indicates the version of Service feature.
10 Service Label: This is the concatenation of Card Number and Card sequence number. The
Terminal may use this data for blacklist and torn transaction processing.
Service Limit: This is the maximum number of Services allowed to be created on the said card.
15 A) 3) Types of Services supported:
The said Card supports two types of services in card.
1. Permanent Service: This type of Service creation shall require successful issuer authorization
20 and shall remain active until the Service owner or the issuer deactivates the service. The area
allocated to such a service shall be locked for the lifetime.
2. Temporary Service: Unlike Permanent Service, the memory associated with these types of
service compartments is auto-released by card application and is made available to other
25 Services. Each temporary service expires within two days of its creation. In case the card runs
out of space delimited for temporary services, it reallocates the space occupied by the expired
Temporary Services to new temporary services.
9
A) 4) Service Creation:
As per Figure 4, service creation in the said card is a onetime process wherein data and key
exchange take place during the same time.
5
The said Service creation takes place in two steps - referred to as
1) Service booking: The said terminal sends the Service ID (unique ID for each service) to
the card. The said Card searches the Service ID requested by the terminal in active Service stack.
If the Service ID is not found, then the said Card sends the Service Availability 10 Information to
the terminal or alternatively the said card returns the Service data associated with the requested
Service ID. If Service ID is not found & space (maximum space required for storing a service
record) is available on card, the said card reserves the space on a temporary basis for the
requested Service ID
15
2) Service check-in: As part of service creation transaction, terminal sets the Service
Management Information data, in addition to various other data and sends it to the card. The
Card performs various security checks for authentication and integrity verification before
20 approving/ rejecting the Service creation request. In case all security checks passes, card creates
the desired service is generated.
A) 5) Service Directory and Service Record
25 The said Card shall have a unique Service Directory which contains information about the
services present in the Service Area. For each Service, a record needs to be created in the Service
Area which contains information pertaining to that specific Service. Each Service record consists
of two types of data i.e. Public Data and Private Data. The Private Data is completely internal to
the card and not accessible by any command.
30
10
Service Registers:
During service creation various parameters and data elements need to be populated. Some of
these data elements point to the location where their actual values are stored. These data
elements are called service registers and the file holding the actual value is 5 termed as Register
File. Each Service Register refers to a record in Register file using a unique Register ID.
Following are some of the major service registers used in a Service;
10 o Service Balance: As part of the service creation process, service owner needs to either link
the service to the card’s global balance or define a wallet local to the service. Service
Balance registers points to the balance used by the Service i.e. either Service local balance or
card’s global balance.
o Service Balance Limit: This is the maximum value a Service Balance can be topped up to.
15 Card may reject or direct the transaction to online after this limit reached up.
o Service Currency Code: This register points to the currency code of the balance.
Card has one Register file which holds multiple records. These records can be identified using a
unique Register ID. Each record in Registers file shall have the following data elements;
20
o Register Id: A unique ID to identify each record in the Registers File. Each register ID is
unique across all services.
o Register Type: This is a flag to indicate whether the record is storing accumulator or
counter. This specification supports storing of amount only as accumulator. Accumulators
25 shall have length of six bytes and counters shall have length of two bytes. Value 0 indicates
record is a counter and Value 1 indicates it is an Accumulator.
o Register Code: In case if the record is an accumulator, then this represents the currency code
of the accumulator. Otherwise this field is populated with all Hex F’s
o Register Value: This is the actual value of corresponding data element
30
11
Service Data Management
o Service Availability Info This data element provides information regarding the space
availability on the card for creation of respective service types i.e. either permanent or
5 temporary.
o Service Management Info
Service transactions could be categorized in to two types, one in which service is created and
other in which already created service is updated. This data element is used for multiple purposes
10 during service creation as well as service modification.
2. Offline Balance Management
The said specification allows two types of balances Global balance and Local balance. The
global balance is maintained at the card level and the issuer is responsible for management of
15 this balance. The local balance is maintained in the Service Data Area of the card and the owner
of the service area is responsible for management of this data. The said card uses either one of
them according to how the service area is configured. The service area may either be created
during personalization or during card usage using specific transaction process flow.
20
Balance Type Data Element Description
Host Balance NA  Limit and rules to maintain this balance
will be as per the bank policy applicable for
Debit/Credit/Prepaid card
 This balance signifies Balance amount
present at Issuer Host
 This balance will be utilized during online
transactions e.g. retail purchase, ATM (cash
withdrawal) and ECOM
12
Global Balance Card Balance  The global balance is maintained at the card
level.
 There is only one global balance stored on
the card.
 Issuer is responsible for management of
this balance
 Max balance of card can be Rs 2000
Local Balance Service Balance  This is service level balance.
Operator/Acquirer may use its own balance
(local balance) as defined in Service area
 Management of Operator created balance in
service area is operator’s discretion and
outside the scope of this document.
 Service Balance may be linked to card
balance i.e. global balance.
Figure 5 illustrates the logical relation that exists between (1) the Customer account hosted by
the Issuer and the Global balance on the Card, (2) the Customer account hosted by the
Merchant/Operator and the corresponding Service Compartment on the 5 Card linked to its Local
Balance, and (3) the Customer account hosted by the Merchant/Operator and the corresponding
Service Compartment on the Card linked to the Global Balance.
 Global Balance
10 Logical link (1) in the figure depicts the relation between a Customer account hosted at the Issuer
end and the Global balance stored on the Card.
Card Global balance is managed by issuer using the load/ money-add transaction. The issuer may
add money to this balance using Issuer Application Data (refer Appendix A.9 Issuer Application
13
Data )and it will be prepared according to ARPC Method 2 (16 bytes) as described in EMV 4.3
Book 2 section 8.2.2.
 Local Balance
5
Logical link (2) in figure 8 depicts the relation between a Customer’s account hosted at the
Merchant or Operator and an associated Service linked to the Local Balance on the Card. This is
service level balance. Operator/Acquirer may use its own balance (local balance) as defined in
Service area or it may use card’s global balance. Management of Operator created balance in
service area is operator’s discretion and outside the scope of this 10 document. Service Balance
works on same principle as card global balance.
 Service Linked to Global Balance
Logical link (3) in figure 8 depicts the relation between a Customer’s account hosted at the Issuer
15 end and an associated Service linked to the Global Balance on the Card. The advantage of this
setup is that the balance management is delegated to the Issuer.
 Transaction Security on Offline Balance
Terminal may use global or local balance in an offline transaction. The balances are protected
20 with security algorithms providing different levels of security. Global balance is deducted only
after successful completion of Offline Data Authentication while Local balance is deducted after
successful completion of at least Service Security check (offline data authentication being
optional).
25 In case of global as well as local balance successful security verification shall be carried out i.e.
Service Signature and Service Summary shall be verified.
14
Terminal
The said payment system card terminal specifications are based on the EMVCo standards and are
compliant with these standards. Contact Interface follows EMVCo guidelines for terminal kernel
& hardware. Figure 6 is a pictorial representation of the architecture of 5 the contactless terminal.
Money Add Transaction
Online Mode:
10
Money Add is a financial transaction which is initiated by Customer from a concerned dedicated
contactless terminal deployed at merchant side, to add/top-up money into the wallet of the card.
This transaction will go online and get approved or declined by the Issuer as per standard EMV
payment rule. After successful approval, top up amount will be written/ topped up into the card.
15 Balance is updated on the card and at the host in case of money add transaction. Money Add can
be performed by a customer using below modes:
1) By Cash
2) A customer may approach a merchant or kiosk authorised to perform top up transaction
20 3) The customer will pay the amount to be topped-up in Cash to the
4) merchant/operator and the operator will tap the card on the POS and perform a money
add/reload transaction
5) This money add transaction shall be authorised by the issuer host and topped-up amount
will be added at the host side in ‘Global Balance’
25 6) This amount will be added into ‘Card Balance’ of the contactless Card post successful
issuer authorization
7) During settlement topped-up amount will be settled between Issuer and acquirer
15
By Issuer Host Account Balance
A customer may approach acquirer/operator or kiosk to perform top up of the card using account.
All such money add transactions shall be authorised by the issuer host. Topped up amount will
be transfer from ‘Issuer Host Prepaid Account Balance’ to the 5 ‘Host Global Card Balance’.
Topped up balance will be added to the contactless card in ‘Card Balance’ after successful
approval from Issuer. No settlement is required since amount is directly transfer from ‘Issuer
Host Prepaid Account Balance’ to the ‘Host Global Card Balance’.
10
CLEARING AND SETTLEMENT:
The transaction can be settled through online mode as well as offline mode.
15 Offline Transaction Processing:
Transaction which will be commenced in offline mode & approved by the acquirer in an offline
environment
1. This includes settlement of below offline transactions performed using the said card:
20 a. Offline Purchase – Any successful offline transaction performed using Card’s Store Value
b. Offline Balance Enquiry – No settlement requires, since it is non-financial transaction
2. Transactions will be presented for settlement via acquirer in the RGCS system
3. All offline transactions which have been done by a customer using card global balance will be
settled at the end of the day. For offline transactions settlement acquirer will submit presentment
25 file to issuer. The format of offline presentment file has been described by NPCI. Refer RGCS
technical specification for offline presentment file format.
Online Transaction Processing:
30 Transaction which will be commenced in online mode & approved by the issuer in real time
1. This includes settlement of below online transactions performed using the said card:
16
a. Retail purchase – Purchase transaction performed on the concerned accepted terminal
b. ECOM – Internet purchase transaction
c. Money Add by CASH – Transaction which will be initiated from the concerned dedicated
terminal for the said card
2. Transactions will be presented for settlement via issuer in the RGCS 5 system. However, In case
of Money add transaction there will be an exception and acquirer
would present the file for settlement.
3. All transactions which will be processed by a customer online using his/her prepaid
10 account/Host account will be settled once from acquirer to Issuer by submitting the
required file.
The said present invention offers solutions across various segments including retail payments,
15 transit fare payment system, toll payments, parking payments, campus payments and other
payments.
NAYAN RAWAL
No. IN PA 654
20 Applicant’s Patent Agent
17
I/We claim:
1) A dual Payment ecosystem which enable contact payment and contactless payments,
which comprises of service compartments which are operable by acquirers and wherein the said
payment system can be functional in an offline mode and an online mode.
5
2) A dual payment ecosystem as claimed in claim 1, wherein payments transactions can
occur through the contact mode as well as contactless mode.
3) A dual payment ecosystem as claimed in claim 1, wherein the said system comprises of
service compartments which can be acquired by an acquirer and 10 wherein information can be
stored and used in online mode and/or in offline mode for both financial and non financial
transactions.
4) A dual payment ecosystem as claimed in claim 1, which is interoperable and can
15 facilitate low value payments including payments for public utilities.