THE PATENTS ACT, 1970
COMPLETE SPECIFICATION SECTION 10
A SYSTEM TO FACILITATE PAYMENTS THROUGH MOBILE
COMMUNICATING DEVICES BY SECURELY STORING PAYMENT
CARD INFORMATION ON THE MOBILE COMMUNICATING
DEVICE AND READING THE SAME OPTICALLY VIA MOBILE
COMMUNICATING DEVICE'S SCREEN USING A PHOTO
CAPTURE DEVICE
ATOM TECHNOLOGIES LIMITED, a company registered in India,
having its registered office at 1st Floor, Malkani Chambers, Off Nehru
Road, Vile-Parle (East), Mumbai- 400 099 (Indian).
The following specification describes the invention and the manner in
which it is to be performed:-

TECHNICAL FIELD;
This invention relates to implementing secure electronic transactions through mobile communicating devices.
This invention more particularly relates to a system which provides a fast, secure and convenient platform for the merchant and the customer to transact through mobile communicating device. The customer shows his / her identification details (credit / debit / loyalty card, PIN etc.) to the merchant encoded in a unique 2D barcode appearing on the mobile communicating device which is read by any photo capture capable device (scanner / camera etc.) attached / integrated (wireline / wireless) to the merchant's device (point of sale / computer etc.). The information is then securely sent to the bank for authorization.
Under this invention the following methods are developed viz. Generating a unique 2D barcode image every time through an application (j2me / symbian / windows mobile) on the mobile communicating device containing encrypted / unencrypted information (credit / debit / loyalty card information along with security PIN and amount) required for transaction; reading the thus generated image through an application on the merchant's device (computer / point of sale etc) via a photo capture device (scanner / camera) from the screen / display of mobile communicating device-, sending the information read from the screen of the mobile communicating device and other relevant transaction information (merchant id, terminal id, amount, PIN) in a secure manner through the application on the merchant's device via Internet for authorization; switching system to send transaction details to authorizing

institution(s) for appropriate credits and debits; an authentication mechanism to ensure 2D bar coded image cannot be reused.
PRIOR ART;
The idea of paying for goods and services electronically is not a new one. All around we see evidences of transactions taking place where at least part of the process is carried out electronically. Since the late 1970's and the early 1980's a variety of schemes have been allowed payment to be affected across a computer network.
The Current System:
In current card payment scenario the following parties are involved:
1) Merchant
2) Merchant Acquiring Bank (who gives the Point of Sale terminal to the Merchant)
3) Card Issuing Bank (who gives the payment card to the Customer)
4) Clearing and Settlement Agency (an organization which settles between the Acquiring and Issuing Bank)
Card and Terminal Based Payment System: Figure - A
Figure - A : illustrates the current physical card / terminal payment system in which the customer presents the card to the merchant who then swipes the same in the physical Point of Sale (PoS) Terminal. PoS dials out to NAC (Network Access Concentrator) which then connects to Acquiring bank Host. Acquiring Bank Host routes the transaction to Visa

Access Point (VAP), which is in-turn, connected to the Issuing Bank Host. Issuing Bank Host validates the card and sends it back to Acquirer Host via VAP. The Acquiring Bank Host sends it back to PoS and then receipts are printed by the PoS to be kept by the customer and merchant respectively.
According to our patent application being Application No. 678/BOM/2006:
ATOM Transaction Platform (ATP) enabled the customers and the merchants to use the mobile phones for conducting secure financial transactions. In addition to mobile based merchant, the platform also facilitated PC based merchant and the internet merchant to connect to ATP.
ATP Platform merchant is expected to register with it to avail its Platform merchant services and later registers with the Acquirer as a Merchant to perform payment transaction. Similarly customer is expected to register with it to avail its Platform customer services and later registers with the issuer as a cardholder to perform payment transaction.
Simplified Representation of ATOM Platform: Figure - B.
How it works
ATOM has created a transaction platform to enable transactions through mobile phones. The application has two parts - Application on the mobile phone (Front-end Application) and ATOM Transaction Platform (ATP).

The merchant initiates the transaction from his mobile phone and enters the customer id and amount. This request is received by ATP and sent to customer's mobile phone for payment. Customer selects the appropriate card stored on the mobile and sends the card details for authorization. ATP receives the details from the customer and sends to Acquiring Bank for authorization from Issuing Bank. On receiving the confirmation from Acquiring Bank, ATP sends receipts to Customer and Merchant.
Shortcomings of the system
1. The system is more suited for payments where the time taken for a transaction is of little significance
Places like large shopping stores etc cannot effectively use such a payment method as it slows down their operations. The time taken for completing a transaction is very large mainly because:
1) The transaction has five steps:
a) Merchant sending payment request to ATP
b) ATP sending the payment request to customer
c) Customer responding with card details to ATP
ATP seeking authorization from bank
d) ATP sending receipt to customer
e) ATP sending receipt to merchant
2) SMS delivery time is uncertain:

With most of the customer using sms as a channel for communicating with ATP one can never be certain how much time the transaction will take as sms delivery is dependent on mobile network congestion at that time.
2. The system requires mobile network at the place of transaction
Our Present Invention
To do a transaction the customer's payment card (credit / debit / loyalty) information stored in the mobile communicating device needs to be sent for authorization. For the same we have created a system to represent the payment card in a unique 2d barcode on the phone screen. This is read by a photo capture device available with the merchant and is sent for authorization thereby eliminating the need for first three steps (a to c) described above. In our invention:
1) Customer shows his / her mobile communicating device containing the card information represented as image on the screen of the device to the photo capture device available with the merchant
2) The merchant side software converts the image into card data and along with other transaction details (merchant id , terminal id, amount etc.) send it to ATP
ATP seeks authorization from bank
3) ATP sends receipt to merchant device (computer / point of sale with
internet connection)

3) ATP sends receipt to customer mobile communicating device over sms
/gprs
The customer sends the card information optically (read by photo capture device) and the merchant sends transaction information and receives receipt from ATP via Internet so there is no need for the mobile network at the place of transaction
The transaction time is much lesser as there are fewer steps in completing the transaction and no dependence on mobile network to receive payment request.
Introduction
The Transaction Platform (ATP) of the present invention enables the customers to do faster over the counter (face-to-face) transactions with merchants equipped with a photo capture device like camera phone or webcam attached to the PC.
In this Platform merchant is expected to register with it to avail its Platform merchant services and later register with the Acquirer as a Merchant to perform payment transaction.
In this Platform customer is expected to register with it to avail its Platform customer services and later registers with the issuer as a cardholder to perform payment transaction.
Simplified Representation of ATOM Platform: Figure - B.

The following abbreviations and notations are used in this document
ICCID Integrated Circuit Card Identification. Unique
identifier identifies a SIM Card.
Acquirer/Acquiring Bank Obtains merchant's credit card transactions
and processes them for payment

ATOM Customer ID Unique ID assigned to every customer by the ATOM Platform to identify the customer.

ATOM Merchant ID Unique ID assigned to every merchant by the ATOM Platform to identify the customer.

Authorization Code A code that a credit card issuing bank returns in an electronic message to POS that indicates approval of the transaction. The code serves as proof of authorization
Authorization Response An issuing financial institution's
electronic message reply to an authorization request, which may include:
Approval - transaction was approved
Decline - transaction was not approved
Referral - response pending more information, merchant must call the toll-free

Authorization The process of verifying the credit card has sufficient funds (credit) available to cover the amount of the transaction. An authorization is obtained for every sale

Card Association Any entity whose members issue credit or debit cards or acquire card payment transactions on behalf of their customers.

Card Index The location on which the Card detail is stored inside the customer SIM.

Card Number Uniquely identifies the card (Debit Card/ Credit Card/ Pre Paid Card like Sodex Ho)

Customer/Cardholder Customer associated with the primary account
number requesting the transaction from the card acceptor.

DES
ECC

Data Encryption Standard. A block cipher that encrypts data in 64-bit blocks. DES is a symmetric algorithm that uses the same algorithm and key for encryption and decryption.
Developed in the early 1970s, DES is also known as the DEA (Data Encryption Algorithm) by ANSI and the DEA-1 by ISO.
Elliptical curve cryptography (ECC) is a public key encryption technique based on elliptic curve theory that can be used to create faster, smaller,


and more efficient cryptographic keys. ECC generates keys through the properties of the elliptic curve equation instead of the traditional method of generation as the product of very large prime numbers.
Encryption Encryption scrambles and unscrambles
information using mathematical equations and a secret code called a key.
GSM GSM (Global System for Mobile communication)
is a digital mobile telephone system that is widely used in Europe and other parts of the world. GSM uses a variation of time division multiple access (TDMA) and is the most widely used of the three digital wireless telephone technologies (TDMA, GSM, and CDMA). GSM digitizes and compresses data, then sends it down a channel with two other streams of user data, each in its own time slot. It operates at either the 900 MHz or 1800 MHz frequency band.
Issuer / Issuing Bank Organizations like banks, building societies and
others, which give out cards to customers, are called issuers.
J2ME Java 2 Platform, Micro Edition (J2ME) is the
edition of the Java platform that is targeted at small, standalone or connectable consumer and

embedded devices, such as cellular phones and personal digital assistants (PDAs). The J2ME technology consists of a virtual machine and a set of APIs suitable for tailored runtime environments for these devices. The J2ME technology has two primary kinds of components-configurations and profiles.
Loyalty Program A program designed to lower the turnover among
users of a product or service by rewarding a customer with incentives or other benefits for remaining a customer.
MAC An algorithm that allows a receiver to ensure that a block of data has retained its integrity from the time it was sent until the time it was received.
Merchant A retailer, or any other person, firm, or corporation that, according to a Merchant Agreement, agrees to accept credit cards, debit cards, or both, when properly presented.
Merchant ID Uniquely identifies a given merchant. The acquirer assigns Merchant ID during merchant registration.
Merchant Category Code Classifies the type of business being done by
the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code.


Merchant Discretionary Data Any merchant related data sent to the
customer mobile. Eg., A/C number for bill payment.
Message A set of data elements used to exchange
information between Customer, Merchant, ATOM Platform and institutions (or their agents).
Message Type Unique message identifier identifies the type of
the message. Message type is part of the message header to identify the message type.
PAN Primary Account Number, the cardholder's
account number to which transactions are to be charged.
PIN Personal Identification Number. The confidential
individual number or code used by a cardholder to authenticate card ownership for ATM or POS terminal transactions.
PoS Point of Sale. Location where transaction is
originated.
PSN PAN Sequence Number, Identifies and
differentiates cards with the same PAN.
Pseudo-random number A number extracted from a pseudo-random sequence.

Pseudo-random sequence A deterministic function which produces a
sequence of bits with qualities similar to that of a truly random sequence.
Random Number As opposed to a pseudo-random number, a truly
random number is a number produced independently of its generating criteria. For cryptographic purposes, numbers based on physical measurements, such as a Geiger counter, are considered random.
Retrieval Reference Number This twelve-character fixed length field
contains the transaction retrieval reference number returned by the authorizing system. The reference number should be printed on the receipt.

Secret Key In secret-key cryptography, this is the key used both for encryption and decryption.
Service ID Unique ID identifies the service to which the message is to be delivered by the ATOM Platform. In ATOM Platform service ID '03' refers to payment service.
Session Key A key for symmetric-key cryptosystems which is used for the duration of one message or communication session.

SMS

Short Message Service. A service for sending messages of up to 160 characters to mobile phones that use Global System for Mobile (GSM) communication.

Symbian
Track 2

An open operating system designed for cell phones that support multimedia messaging, Bluetooth, and Java.
The second magnetic track on a financial transaction card. It is read-only, and its contents are defined in ISO 7813.

Terminal ID
Transaction ID
Virtual NAC / PoS
Triple DES/3DES

Designates the unique location of a terminal at a merchant. The acquirer issues Terminal ID during merchant registration.
Unique Identifier assigned to a transaction in the ATOM Platform. The Transaction ID is valid only till the completion of the transaction.
Software implementation of a Standard Point of Sale terminal / Network Access Controller. An electronic system that accepts financial data and transmits that data to a computer or authorization network for reporting activity, authorization and transaction logging.
A variation of the DES block cipher algorithm that encrypts plain text with one key, encrypts the resulting cipher text with a second key, and

finally, encrypts the result of the second encryption with a third key. Triple DES is a symmetric algorithm that uses the same algorithm and keys for encryption and decryption.
ATOM Platform
ATOM is a scheme that has been successful in taking the e-payments one step ahead to m-payments (mobile payments). To achieve the same ATOM has developed a secure and robust interoperable transaction platform called the ATOM Transaction Platform abbreviated as ATP.
In the case of mobile payments as envisaged by ATOM in the figure B above, ATOM will be playing the role as described in the illustration above.
Client side Payment Application
The core payment engine is Java 2 Micro Edition (J2ME) / Pocket PC based Customer application. The phone application shall be loaded into the mobile supporting J2ME CLDC1.0/MIDP2.0 or Pocket PC specification.
The Customer application residing in the mobile is developed as J2ME / Pocket PC application so that it can be loaded into the J2ME / Pocket PC based mobile phones.
The merchant application is either a j2me application running on a camera mobile phone (supporting J2ME CLDC1.0/MIDP2.0 or Pocket PC

specifications) or an application on the PC equipped with photo capture device like webcam
Loading Phone Application
The ATOM Phone application should be loaded into the customer and merchant mobile phone to enable mobile payment. The J2ME MIDP 2.0 or Pocket PC phone is required for the application to get loaded into it. The application shall be loaded in the following ways:
1) Data cable connected to PC
2) GPRS internet access
3) Bluetooth and
4) Infrared
5) Pre-installed by the handset manufacturer
Loading PC Application
The ATOM PC application for merchant should be loaded into merchant's PC to enable mobile payments. The application shall be loaded in the following ways:
1) via CD / DVD
2) Internet
3) USB pen drive
4) Pre-installed by the PC manufacturer

Brief Description of Drawings:
The invention will be now more clearly explained with the following non limiting figures, where
Fig-1 shows the process of merchant requesting for registration with the Platform
Fig-S shows the process of the Platform Registering the Merchant
Fig-3 shows the process of Merchant - Acquirer confirmation detail loading into the Merchant Mobile
Fig-4 shows the process of Customer requesting for registration with the Platform
Fig-5 shows the process of Platform Registering Customer
Fig-6 shows the process of Electronic card loading into the customer Mobile
Fig-7 shows the process of Electronic card load Confirmation sent back to the Platform
Fig-8 shows the process of Sale Transaction
Steps Involved for a Merchant to perform Payment Transaction Merchant Registration with ATOM Platform

The Merchant is expected to first register with ATOM Platform as an ATOM Merchant. This is a pre-registration process for any merchant to avail ATOM Platform merchant services.
Merchant request for registration with ATOM Platform
The Merchant application loaded into the merchant Mobile / PC is a generic ATOM Merchant application without any merchant specific details. To get the application personalized for a particular merchant, the application needs to be registered with Merchant specific information. To avail ATOM Platform merchant services, the interested merchant is first expected to get register with ATOM Platform. Fig-1
The merchant registration request logic is built into the Merchant application as part of the standard functionality.
The registration request data is sent in a single SMS on phone or via Internet on PC.
ATOM Platform Registering Merchant
ATOM platform on receiving registration request from the interested merchant will perform necessary validation in the system for duplicate request and generates a unique ATOM Merchant ID. ATOM platform also generates Merchant specific security keys for loading into the merchant application.
Fig-2
The registration data is sent in a single SMS on phone or via Internet on PC.

Merchant Registration with Acquirer
To perform payment transaction the ATOM merchant should require arrangement with acquiring bank.
Merchant - Acquirer confirmation detail loaded into the Merchant Mobile
The Acquiring bank on processing the merchant request shall register the merchant in their system; the acquirer will send the merchant detail to ATOM platform to load it on to the merchant.
Fig-3
ATOM Platform receives the merchant registration detail from the Acquiring bank and sends it to the merchant mobile / PC application. The merchant can carry out payment transaction only after the registration data is personalized into his application.
The communication channel for transferring the merchant registration detail between ATOM platform and the acquiring bank shall be through agreed upon medium. It may be through e-mail, CD, etc. The communication channel between ATOM platform and Merchant Mobile is through SMS/GPRS.
Steps involved for a Customer to perform Payment Transaction
The customer is expected to register with ATOM platform to avail atom customer services. The ATOM platform enables the registered customer to perform payment transactions securely and conveniently. The person interested in performing payment transaction in his mobile shall first register with ATOM platform and later, request the Issuing bank to load the electronic Credit / Debit card into his mobile.

Customer Registration with ATOM platform
Customer request for registration with ATOM Platform
The Customer application loaded into the customer mobile is a generic ATOM Customer application without any customer specific details. To get the application personalized for a particular customer, the application needs to be loaded with customer specific information. To avail ATOM Platform customer services, the interested customer is first expected to register with ATOM Platform.
Fig-4
The customer registration request logic is built into the customer applet as part of the standard functionality.
ATOM Platform Registering Customer
ATOM platform on receiving registration request from the interested customer will perform necessary validation in the system to check for duplicate request and generates security Keys and registers the customer with ATOM loyalty scheme for availing loyalty points in the system.
Fig-5
The registration data is sent in a single SMS.
Electronic card load into the customer Mobile
The customer's card Issuing bank after verifying the interested customer shall prepare card personalization data and transfers the electronic card data to ATOM platform.

The Issuing bank shall first registers with ATOM and shall generate the required Master Key(s) into the HSM residing with ATOM. ATOM uses this key to encrypt the card data of the customer before loading it into the customer mobile.
The transaction performed by the customers using the electronic card loaded into their mobile is treated as a card present transaction
Fig-6
Electronic card load Confirmation sent back to ATOM Platform
The customer mobile on receiving the card load data will respond with confirmation detail to ATOM platform.
FIG-7
How it works
ATOM has created a transaction platform to enable transactions through mobile phones. The application has two parts - Application on the mobile phone or PC (Front-end Application) and ATOM Transaction Platform (Backend).
Customer initiates a payment after selecting the appropriate card stored on the mobile, entering the amount to pay and card PIN. This generates a random 2d image on the customer's mobile phone screen. This image is shown by the customer to the merchant's photo capture device camera phone or webcam attached to PC etc. The merchant's application on the device picks up the image and after decrypting the image and adding merchant specific details sends the request to ATOM Transaction

Backend for authorization. ATOM Transaction Platform (Backend) receives the details from the merchant and sends to Acquiring Bank for authorization. On receiving the confirmation from Acquiring Bank, Transaction Platform (Backend) sends receipts to Customer and Merchant.
ATOM enables secure electronic transactions through mobile phone.
ATOM has developed a method for:
1. Securely loading the customer's electronic card directly on customer's mobile phone
2. Securely loading the merchant electronic terminal directly on merchant's mobile phone / PC
3. Capturing the customer card details from his / her mobile phone screen via photo capture device at merchant's end
4. Securely sending the card and terminal details back to the bank whenever required for authorization during a transaction
Card issuers (banks) will use electronic cards on mobile phone provided there is a secure method of transmitting the card information to / from the phone. If the Track 2 data is sent in clear to / from the mobile phone there is a possibility of data being intercepted and misused. Therefore it is necessary to send the data in an encrypted format.
It is possible to use PKI (Public Key Infrastructure - RSA or ECC, Asymmetric Cryptography) and encrypt the Track 2 data. However, it takes a lot of time due to limited resources on the phone to decrypt data using asymmetric cryptography. It would therefore become impractical to use mobile phone as a payment device because of the time taken to do these encryption / decryption operation during a transaction. Symmetric

encryption becomes the only method to do secure electronic transactions through mobile phone within a reasonable time.
However, if the same (one common key) symmetric key is used to send / receive encrypted data to / from every user at any stage (registration with ATOM, Request for a card / terminal, Sale transaction etc) then it is possible for someone to hack and retrieve the key. With this key the hacker can then read all encrypted data sent / received by the system to all customers. Therefore the symmetric key used for encryption / decryption should be different for every customer. This means the application installed by the customer on the mobile phone should contain a unique symmetric key for every customer.
ATOM application resides on the customer's / merchant's mobile phone / PC and achieves the above in following steps.
1. On starting the application it generates a public key and private key pair for the customer / merchant using Asymmetric Cryptography -ECC (Elliptic Curve Cryptography 192 bit).
2. The private key is stored in the mobile phone / PC.
3. The public key of the customer / merchant is sent to ATOM system for registration over sms / gprs / ussd / internet.
4. ATOM registers the customer / merchant on its systems and generates a symmetric key for the customer / merchant, which will be used for decrypting any data sent from ATOM system to the customer / merchant mobile phone / PC.

5. A copy of customer / merchant symmetric key is encrypted using the customer / merchant public key sent to ATOM during registration.
6. The encrypted symmetric key is then sent to the customer / merchant's mobile phone / PC over sms / gprs / ussd / internet.
7. Even if an intruder intercepts the data between ATOM's system and customer / merchant's mobile phone they cannot retrieve the customer / merchant's symmetric key.
8. ATOM application residing on the customer / merchant's mobile phone / PC receives this encrypted message and retrieves the symmetric key using the private key, which was stored in the mobile phone / PC.
9. The symmetric key (CCMK) is then stored in the mobile phone / PC.
This way every customer / merchant gets a unique symmetric key which will be used for encrypting / decrypting the data while sending / receiving.
After a customer is registered with ATOM and has received the symmetric key, the bank does the necessary processing before issuing a card to the customer and once the bank decides to issue a card to the customer it generates a Track 2 file. This Track 2 information is sent to ATOM for loading on the customer mobile.
Once the Track 2 information is sent to ATOM by the bank for loading it in the phone ATOM encrypts using a customer specific symmetric key (T2EK generated using the parameters defined by the bank) and also generates a card specific PIN block encryption key CAMK. The encrypted Track 2 data and CAMK is then encrypted using the CCMK (already stored on customer's mobile) and sent to the customer mobile phone. The

application in the phone receives the data and stores encrypted Track 2 and CAMK after decrypting it using the CCMK already sent.
This way ATOM securely loads an electronic card on the customer's mobile phone. A similar process is followed for loading an electronic terminal on the merchant's mobile phone / PC.
Whenever the customer initiates a payment request from the phone customer authorizes the transaction by entering the card specific PIN. the encrypted Track 2 data (stored on the mobile phone) and PIN encrypted under CAMK session key along with transaction data is used to generate a random image on the phone screen. Merchant's photo capture device picks up this image and after adding merchant specific data to it sends it back to the ATOM Transaction platform backend. The ATOM Transaction Backend has a copy of CAMK and can therefore successfully decrypt and compare the data received from the customer's mobile phone. This way the card issuer can securely receive the data from the customer mobile phone during any transaction authorization.
ATOM has created a unique process for securely loading the electronic card and terminal on the mobile phone. The application architecture provides maximum data security while transmitting information to / fro from the mobile phone. The electronic card / terminal can be requested by the customer / merchant directly from the mobile phone.
Security
One of the core services of the any transaction platform is to provide maximum end-to-end transaction security. ATOM platform uses PKI based Asymmetric cryptography (used only in key exchange) and

symmetric key based cryptography (for data encryption and MAC) to secure the mobile transactions.
ATOM generates its own master key for deriving merchant/customer specific master keys for data encryption and generating Message Authentication Key (MAC) using ICCID. Every merchant terminal and the customer card are loaded with the derived keys unique to the customer or the merchant. Encryption using session key, which is derived from the card specific master keys maximizes overall data security providing further protection to all the transactions.
The issuer will generate their own Issuer Master Key for deriving customer specific and card specific encryption key. This key is used for deriving session key for encrypting the payment data transferred from the customer mobile to ATOM platform.
The advantage of using session key is that for every session new key is derived and the derived session key is used for encrypting the data. This enables the ATOM platform to be most securing payment platform.
Typically the critical messages are secured as follows.
The data elements are concatenated together to form a data packet and are encrypted with the derived session key (Key unique per session) and the header for the data is prepared. The Header and the encrypted data packet are concatenated together and Message Authentication Code is calculated using the derived MAC session key (Key unique per session). The final payload will have MAC, HEADER and the ENCRYPTED DATA.

The security of Atom Transaction Platform can be broadly categorized under
A. Transaction Security
B. Operational Security
A. Transaction Security
ATP being a financial platform, security is of prime importance. Every financial and non - financial message to and from Customer and Mobile terminals to Atom Transaction Platform and vice versa is encrypted using well-defined security algorithms like DES3 and Elliptic Curve.
Most cryptographic algorithms works on blocks of data obfuscating it with cipher text derived using a key. Similar is the case with Atom.
B. Process / Operational Security
I. PIN based Security
i. Encryption & Decryption of PIN
The clear pin entered by the customer is encrypted using the session key generated using a random number and the Card Account Master Key (CAMK) of the customer. Once the encrypted clear pin reaches the ATP switch, the encrypted PIN and the Random number are sent to the switch's HSM where the clear PIN is decrypted using the session key generated by the HSM using the random number and is re-encrypted using the Terminal Pin Key (TPK) of the Acquirer.

ii. PIN Translation
In the case where the transaction is an OFF-US transaction the customer Pin has to be authenticated by the Issuer. In such a case the Pin entered by the atom customer, which is, encrypted using the session key generated under the Customer Card Master Key has to be re-encrypted under the Terminal PIN key of the Acquirer to be sent to the Acquirer. This process is called Pin translation. The Switch HSM of ATOM does the necessary pin translation.
iii. PIN Storage
Pins are never stored at ATOM databases. Instead PIN offsets are generated for the clear pin, which are mapped to mobile numbers / ICCID. The Switch HSM calculates the natural pin from the clear pin and the pin offset and returns a status flag depending on the pin validation result. So at no point of time is the clear pin available to ATOM.
iv. PIN Selection
During the card load process for the customer, as explained as part of ATP- Process, the Issuer performs the due diligence on the customer before issuing him a credit or a debit card. Once this is complete the Issuer authorizes the issuance of an electronic card though the ATOM Transaction Platform. Once the card is loaded on to the customer's terminal he is asked to enter a 4-digit pin of his choice. This pin is encrypted using the Customer Account Master Key (CAMK), which is loaded during the card load response. This

clear pin is sent to the Issuer using an IS08583 Change pin message.
Financial Transactions
ATOM platform supports the following financial transactions:
1) Sale
2) Void
3) Refund
Sale Transaction
Sale refers to a transaction type that approves a transaction and
settles it at the next settlement period.
In Atom platform, the merchant is expected to initiate the sale
transaction.
Fig-8
Step l:
The Merchant initiates the sale transaction by choosing the terminal from the list of personalized terminals (Merchant shall have more than one terminal loaded into the same mobile / PC application), enters the amount in the ATOM merchant application and waits for the customer to flash his / her mobile phone in front of the photo capture device like camera phone or webcam connected to the PC.

Step 2:
Customer enters the amount to pay and tip (if any), chooses the card for making payment from the list of loaded cards before entering the card PIN for the chosen card. The customer mobile phone application takes the user input and along with payment card details, using the security keys already stored in the application, encrypts the data and represents it as a random 2d image on the phone screen. The customer flashes this 2d image in front of the merchant's photo capture device.
Step 3:
Merchant application picks up customer details from the 2d image captured through the photo capture device from customer's mobile phone screen, validates the amount customer entered and appends merchant specific details to the data. Entire data is encrypted and transferred to ATOM platform for authorization.
Step 4:
ATOM platform decrypts the sale request and validates the Cryptogram, decrypts the payload and send it to Virtual POS to process the payment by sending the Payment authorization request to acquirer host. The Virtual POS simulates the actual hardware POS and the message format will be similar to the actual POS message format (ISO 8583). To the acquirer host the data will look like as it is from the actual POS. So there is no need for change in

any of the module in the acquirer side to accept ATOM platform request.
Step 5:
The acquirer host on receiving the payment authorization validates the merchant and sends the authorization request to the issuer bank. The Issuer bank then sends the authorization response back to the acquirer host with the retrieval reference number which is then forwarded to the Virtual POS in the ATOM platform.
Step 6:
ATOM platform generates Authorization Response Cryptogram and sends the confirmation or the failure receipt based on the Authorization response Code to the merchant.
Step 7:
ATOM platform generates Authorization Response Cryptogram, calculates the ATOM loyalty points awarded and sends the confirmation or the failure receipt based on the Authorization response Code to the customer.
Void Transaction
Void transaction refers to reversal of an approved transaction, one that has been authorized but not settled. Settled transactions require processing of a credit in order to be reversed.

In ATOM platform merchant initiates the void transaction and is carried out in a similar manner as the Sale transaction above with the customer selecting the card in the mobile phone application and entering the Pin for the card to generate the 2d image which is picked up by the merchant scanner and then sent onwards to the bank for processing along with necessary merchant details. The Bank on processing sends confirmation to both customer and merchant.
Refund. Transaction
Refund is a transaction type that transfers funds to the cardholder's account, rather than from the account. This transaction type is typically used to refund a customer's money for an order that was previously settled, e.g., returns or overcharges.
In ATOM platform merchant initiates the refund transaction and is carried out in a similar manner as the void transaction above.

We claim :-
1) A system of facilitating payments through mobile communicating devices by securely storing payment card information on the mobile communicating device and reading the same optically from mobile communicating device's screen using a photo capture device and sending the same for authorization thereby comprising of the following steps which entail requesting of an electronic card / terminal from the mobile phone; securely loading the customer's electronic card directly on customer's mobile phone; securely sending the card information back to the card issuer (bank) whenever required for authorization during a transaction; securely loading the merchant electronic terminal directly on the merchant's mobile phone and securely sending the terminal details to terminal issuer (acquiring bank) whenever the merchant initiates a sale transaction.
2) A system to facilitate payments through mobile communicating devices by securely storing payment card information on the mobile communicating device comprising:

a) a mobile communicating device programmed for Generating a unique barcode image every time through an application (j2me / symbian / windows mobile) on the mobile communicating device containing encrypted / unencrypted information (credit / debit / loyalty card information along with security PIN and amount) required for transaction;
b) a merchant's device (computer / point of sale etc) having a photo capture device (scanner / camera) programmed for reading the thus

generated image through an application on the merchant's device (computer / point of sale etc),
c) a means for sending the information read from the screen of the mobile communicating device and other relevant transaction information (merchant id, terminal id, amount, PIN) in a secure manner through the application on the merchant's device via Internet for authorization;
d) a switching system to send transaction details to authorizing institution(s) for appropriate credits and debits;
e) an authentication mechanism to ensure bar coded image cannot be reused.
f) a robust and secure transaction platform capable of providing rich set of merchant and customer services; the said platform comprises means for registering the merchant and the customer, means for validating the users, means for using PKI based asymmetric cryptography(ECC) to distribute symmetric key used for secure data transfer; ATOM platform uses PKI based Asymmetric cryptography (used only in key exchange) and symmetric key based cryptography (for data encryption and MAC) to secure the mobile transactions.
ATOM application resides on the customer's / merchant's mobile phone PC / PoS and achieves the above in following steps.
(i) On starting the application it generates a public key and private key pair for the customer / merchant using

Asymmetric Cryptography - ECC (Elliptic Curve
Cryptography 192 bit),
(ii) The private key is stored in the mobile phone / PC.
(iii) The public key of the customer / merchant is sent to ATOM
system for registration over sms / gprs / ussd / Internet,
(iv) ATOM registers the customer / merchant on its systems and
generates a symmetric key for the customer / merchant, which
will be used for decrypting any data sent from ATOM system
to the customer / merchant mobile phone / PC.
(v) A copy of customer / merchant symmetric key is encrypted
using the customer / merchant public key sent to ATOM
during registration,
(vi) The encrypted symmetric key is then sent to the customer /
merchant's mobile phone / PC over sms / gprs / ussd /
Internet,
(vii) Even if an intruder intercepts the data between ATOM's
system and customer / merchant's mobile phone they cannot
retrieve the customer / merchant's symmetric key.
(viii) ATOM application residing on the customer / merchant's
mobile phone / PC receives this encrypted message and
retrieves the symmetric key using the private key, which was
stored in the mobile phone / PC.
(ix) The symmetric key (CCMK) is then stored in the mobile
phone / PC.
This way every customer / merchant gets a unique symmetric key which will be used for encrypting / decrypting the data while sending / receiving.

3) An invention as claimed in claims 1 and 2 above which enables
secure transactions via mobile phones through the use of a transaction
platform which application has two parts - Application on the mobile
phone / PC (Front-end Application) and ATOM Transaction Platform
(Backend).
The merchant initiates the transaction from his device and enters the amount, customer selects the card and enters the PIN for the card and amount in the mobile phone application. This data the mobile phone application converts in a 2d image which is represented on the phone screen. The photo capture device / scanner attached to the merchant's device picks up this image, deciphers the data, compares the amount and then sends to the Backend for processing. ATOM Transaction Platform (Backend) validates the data and then it is sent to the Acquiring Bank for authorization from Issuing Bank. On receiving the confirmation from Acquiring Bank, Transaction Platform (Backend) sends receipts to Customer and Merchant.
4) An invention as claimed in claim 1 and 2 above wherein use of the ATOM platform by the said means maintains various master keys to generate customer/merchant specific keys.
5) An invention as claimed in claim 1 and 2 above wherein use of the ATOM platform by the said means also uses session key (valid only for that session) to maximize overall data security,
6) A method of transaction through mobile communicating device comprising the steps of registering the merchant and the customer and

loading electronic card in to the customer mobile and electronic terminal in the merchant device (PC or PoS) which includes
the merchant pre-registering with the Platform for availing the service of financial and non financial transaction, wherein a generic application software is loaded to the merchant's device (PC / PoS) without any merchant specific details and the application get personalized for a particular merchant with Merchant specific information. A merchant registration request logic is built into the Merchant application as part of the standard functionality,
Sending the registration request data to the backend using the application,
Receiving registration request from the interested merchant by the Platform and performing necessary validation in the system for duplicate request, generating a unique Merchant ID and merchant specific security keys for loading into the merchant mobile,
merchant registering with the acquiring bank, wherein the Acquiring bank on registering the merchant in their system, sending the merchant detail to the platform to subsequently load it on to the merchant, which is built
into the Platform and Merchant Application as part of the standard functionality,
Customer registering with the platform to perform payment transaction, where in utilizing the customer registration request logic which is built into the customer applet as part of the standard functionality, the customer sends a registration request to the platform via SMS/GPRS,

platform registering customer, where in on receiving registration request from the interested customer ,the platform performs necessary validation in the system to check for duplicate request and generates security Keys and registers the customer with ATOM loyalty scheme for availing loyalty points in the system and send the registration data in a single SMS to the customer mobile,
customer requesting for loading electronic card into the Mobile, where in Customer sends the card load request to the platform after registering with the platform to perform financial transactions, the platform receives the request from the customer and sends it to the appropriate issuing bank to process the customer request for card loading,
issuing bank loading the Electronic card load into the customer Mobile where in the Issuing bank after verifying the interested customer prepares card personalization data and transfers the electronic card data to the platform, the Issuing bank first registers with the platform and generates the required Master Key(s) into the HSM residing with the platform and the platform uses this key to encrypt the card data of the customer before loading it into the customer mobile,
Sending Confirmation of card loading back to Platform, where in the customer mobile on receiving the card load data responds with confirmation detail to the platform.
7) An invention which enables a financial transaction to be securely conducted via mobile phone and through the use of an ATOM transaction Platform which operates on two modes of Security viz. Transaction Security and Operational Security, by the use of various Keys.

8) An invention which transacts a sale utilizing the mobile devices, this includes
Step 1:
The Merchant initiating the sale transaction by choosing the terminal from the list of personalized terminals (Merchant shall have more than one terminal loaded into the same mobile / PC application), entering the amount in the ATOM merchant application and waiting for the customer to flash his / her mobile phone in front of the photo capture device like camera phone or webcam connected to the PC.
Step 2:
Customer entering the amount to pay and tip (if any), choosing the card for making payment from the list of loaded cards before entering the card PIN for the chosen card. The customer mobile phone application taking the user input and along with payment card details, using the security keys already stored in the application, encrypting the data and representing it as a random 2d image on the phone screen. The customer flashing this 2d image in front of the merchant's photo capture device.
Step 3:
Merchant application picking up customer details from the 2d image captured through the photo capture device from customer's mobile phone screen, validating the amount customer entered and appends merchant specific details to the data. Entire data then

being encrypted and transferred to ATOM platform for authorization.
Step 4:
ATOM platform decrypting the sale request and validating, the Cryptogram, decrypting the payload and sending it to Virtual POS to process the payment by sending the Payment authorization request to acquirer host. The Virtual POS simulating the actual hardware POS with the message format of the actual POS message format (ISO 8583). To the acquirer host the data looking like as it is from the actual POS. So there is no need for change in any of the module in the acquirer side to accept ATOM platform request.
Step 5:
The acquirer host on receiving the payment authorization validating the merchant and sends the authorization request to the issuer bank. The Issuer bank then sends the authorization response back to the acquirer host with the retrieval reference number which is then forwarded to the Virtual POS in the ATOM platform.
Step 6:
ATOM platform generates Authorization Response Cryptogram and sends the confirmation or the failure receipt based on the Authorization response Code to the merchant.

Step 7:
ATOM platform generates Authorization Response Cryptogram, calculates the ATOM loyalty points awarded and sends the confirmation or the failure receipt based on the Authorization response Code to the customer.
9) A method of doing a void transaction through mobile communicating device, when the merchant and the customer are registered with the platform and the acquiring bank as claimed in claim 1 with similar steps as Sale mentioned above
10) A method of doing a refund transaction through mobile communicating device, when the merchant and the customer are registered with the platform and the acquiring bank as claimed in claim 1, with similar steps as in Sale mentioned above
11) A method of conducting secure transaction through mobile communicating device as described substantially here in with reference to the figures of the accompanying drawings wherein a merchant first requests for its registration with an ATOM Platform which upon receiving such request performs necessary validation and generates an unique ATOM Merchant ID and merchant specific security keys and forwards the merchant request to the acquiring bank for registration which confirmation details are loaded into the merchant mobile.
13) A method of conducting secure transaction through mobile communicating device as described substantially herein with reference to the figures of the accompanying drawings wherein a customer can perform

the payment transaction by first requesting for its registration with the ATOM Platform which upon such receipt confirms registration of a customer with it by loading an electronic card into the customer's mobile phone issued by the issuing bank. This data is forwarded to the issuing bank which then prepares an electronic card personalization data and transfers the same to the ATOM Platform and in addition thereto generates the required Master Key into the HSM residing with ATOM which in turn uses this key to encrypt the card data of the customer before loading it on the customer mobile and the customer upon receiving the card load data respond with confirmation detail to ATOM Platform thus ensuring safe transaction thereof.

ABSTRACT OF THE INVENTION
This invention relates to enabling secure electronic transactions through mobile communicating devices thereby providing for a fast, secure and convenient platform for the merchant and the customer to transact without the need for mobile network at the place of transaction. Under this invention the following methods are developed viz. Generating a unique 2D barcode image every time through an application (j2me / symbian / windows mobile) on the mobile communicating device containing encrypted / unencypted information (credit / debit / loyalty card information along with security PIN and amount) required for transaction; Reading the thus generated image through an application on the merchant's device (computer / point of sale etc) via a photo capture device (scanner / camera) from the screen / display of mobile communicating device; sending the information read from the screen of the mobile communicating device and other relevant transaction information (merchant id, terminal id, amount, PIN) in a secure manner through the application on the merchant's device via Internet for authorization; Switching system to send transaction details to authorizing institution (s) for appropriate credits and debits; An authentication mechanism to ensure 2D bar coded image cannot be reused.