The present invention relates to a method and system to enable offline transaction. Moreover, the invention provides a method and system for secured offline transaction by tokenized units of digital money (referred to hereinafter as "tokeNotes"), wherein, the money in the form of tokens are transferred in an 5 encrypted form in appropriate denomination and which is stored in a user's device such as a smart phone.
BACKGROUND OF THE INVENTION
All online/electronic payment systems today require internet connectivity for an issuer to be able to authorize a transaction. This presents a unique challenge of 10 enabling payments where internet connectivity cannot be availed at all times. One such example where internet is barred is on airplanes where the phones do not have internet connectivity either because of regulation, flight safety or prohibitive costs. Therefore in such conditions, if an issuer needs to authorize transactions then there are seldom any options available. 15
Although, there exist protocols for offline card payments, usually for credit cards, those protocols risk the transaction due to requirement of the local authorization and it is possible to easily exploit these protocols for financial misappropriations by the entities involved. In other words, these protocols may enable local offline payments, but come at a significant cost due to the risk involved. 20
The prior arts also provide Crypto currencies which present a possibility for making payments without a central authority due to its essentially decentralized peer-to-peer nature. However, even crypto-currency payments would need connectivity to N number of peers for transactions to be authenticated.
In CN103077456 the invention discloses a mobile method in an off-line mode. The 25 mobile method comprises the following steps that a payer sends information and a payee responds and replies the information through a non-contact communication
3
way based on a mobile internet device; the payer reads local information and inputs the corresponding trade information, and a system will check out whether a transaction amount exceeds local account balance, and then carry out the information encrypted storage and send the information to the payee when the transaction amount is not more than the local account balance; the payee authorizes 5 the information, modifies the local account balance and replies the deal close confirming information to the payer, and finally modifies the local account balance after the payer confirms the information, and completes the off-line trade. From a technical perspective, based on a special electronic account separated from an account, the account balance is stored in a security chip of a mobile device and 10 synthesized with a financial gateway at regular time in a networking state, and the safe and effective verification on the account is carried out simultaneously.
In US9015063 the embodiment of the invention discloses an off-line mode identity and transaction authentication method and a terminal. The method comprises the following steps that: a first terminal sends a payment request message including a 15 first digital sign and transaction data to a second terminal; the second terminal receives the payment request message and carries out identity authentication on the first digital sign, and after the authentication is passed, a payment agreement message including a second digital sign is sent to the first terminal; the first terminal receives the payment agreement message and carries out identity authentication on 20 the second digital sign, and after the authentication is passed, a payment confirming message is sent to the second terminal; and the second terminal receives the payment confirming message and carries out off-line payment operation on the first terminal according to the transaction data. The terminal provided by the invention can be used for realizing the method. When the method and the terminal are adopted, the 25 safe authentication in the off-line transaction process of the terminal can be realized, the safety of the off-line transaction is improved, and good foundation is laid for the fast popularization of the off-line transaction application.
CN101211435 The invention discloses a system and a method for realizing offline transfer transaction, which can achieve point-to-pint offline transfer transaction by a 30
4
mobile communication device in the case of without network support, in which the system comprises the following parts: a back stage transaction system for recording and managing the account and transaction information of transfer transaction user; a paying side mobile communication device which has a wireless communication interface, and a microprocessor of the device is provided with a transaction software; 5 a gathering side mobile communication device which has a wireless communication interface which matches with the paying side mobile communication device, and a microprocessor of the device is also provided with a transaction software. The method comprises the following steps: performing pre-charging for the paying side mobile communication device through the back stage transaction system; the paying 10 side user and the gathering side user use respectively the paying side mobile communication device and the gathering side mobile communication device to perform offline transfer transaction activity; the paying side user and the gathering side user perform respectively liquidation through the back stage transaction system.
All these system provides a method of offline transfer transaction activity and further 15 provide protection via chip or digital sign, but none of the invention provides detailed illustration of method and system for implementing offline security transfer transaction activity, so that even offline security features may be implemented for online transactions.
20
OBJECT OF THE INVENTION
The main object of the invention is to provide a system and method to facilitate electronic money transfer in offline mode.
Yet another object of the invention is to provide a secure offline electronic money 25 transfer in flight mode or with no internet.
Yet another object of the invention is to secure offline electronic money transfer in flight mode or with no internet via asymmetric key cryptography.
5
Yet another object of the invention is to provide a system and method to facilitate offline electronic money transfer by connecting two or more offline devices present in the same vicinity.
Yet another object of the invention is to provide system and method to facilitate 5 offline electronic money transfer by demarcating offline balances in the customer's wallet for 'offline modes only'.
Yet another object of the invention is to provide a system and method to facilitate offline electronic money transfer by demarcating the offline balance into the available 10 denominations and in the currency of the merchant.
Still another object of the invention is to provide a method and system for securing the offline transaction by tokeNotes, which are transferred in an encrypted form in appropriate denomination and stored in a user's device such as a smart phone in the 15 form of a bar code, before turning the system in the flight mode. Further in flight mode, a merchant requiring payment may scan the bar code with the smart phone to in an offline mode by matching 6 digit pseudorandom part of the tokeNote sequence and OTP's.
SUMMARY OF THE INVENTION 20
The present invention provides a method and system to enable electronic transactions in offline mode. Further, the invention provides a method of securing the offline transaction by tokeNotes, which are transferred in an encrypted form in appropriate denomination and stored in a user's device such as a smart phone in the form of a bar code. Further in offline/flight mode, a merchant requiring payment 25 may scan the bar code with the smart phone to in an offline mode by matching numeric pseudorandom part of the tokeNote sequence and OTP. The system and protocol is designed to enable guaranteed electronic payments in situations where the only communication option available at the time of the transaction is between the
6
merchant and the customer under consideration and that too, non-radio based communication modes.
In an embodiment of the current invention the system uses existing asymmetric key cryptography to ensure secure communication with the server. The key distribution is as follows: 5
Server.privateKey Merchant (n).publicKey Customer (n).publicKey
Server
Server.publicKey Merchant (n).privateKey
Merchant (n) 10
Server.publicKey Customer (n).privateKey 15
Customer (n)
In addition, for the functional aspect the key distribution, each merchant is securely seeded with "N" unique symmetric keys by the server from time to time. One key is generated for each currency denomination being presented. Thus, both the server and merchant will have an identical copy of these keys. For illustration, each key has a secure pseudorandom sequence of certain characters typically 20 bytes long, as in 20 OTP algorithms, but could be of any other length as well. The first 3 characters in the key represents the currency, the next 1 character is for the multiplier (single digit from 1 to 9) the next 1 character for the power of 10 (single digit from 0 to 9) are reserved for the denomination being represented, followed by the pseudorandom sequence of 15 characters, making the entire length 20 bytes. 25
7
Therefore for each Merchant (n) there exists:
tokeNote [0].key tokeNote [1].key tokeNote [2].key . 5
.
. tokeNote [n].key
For the currency INR, the typical denominations would be 1, 5, 10, 50, 100, 500, and 1000. 10
In a different embodiment, the server and merchants are provided assymetric keys such that the server can only generate tokenNotes and the merchant application can only verify them.
Additionally there exists a counter seed for each merchant, which is a pseudorandom number generated and stored by the server with a copy being stored securely on the 15 merchant app as well.
In yet another embodiment of the present invention a system and a method is designed to enable guaranteed electronic payments in situations where the only communication option available at the time of the transaction is non-radio based, and is facilitated by tokeNotes. 20
In an embodiment of the present invention the invention provides a method to enable offline transaction comprising of steps of demarcating a balance in a wallet for paying a merchant in offline only mode from a available balance by a customer; recording a last known location and feeding the location for physical transaction; providing a compiled list of all registered merchants in the area of the customer; 25 allowing the customer to select a particular registered merchant and sending interest;
8
receiving a transaction acknowledgement and converting the wallet balance; activating an offline mode or an airplane mode; initiating transfer on acquiring physical proximity with the merchant, performing fund transfer by exchanging the wallet balance, and synchronizing with the server on coming back online and furnishing the latest balance; wherein: wallet balance or funds are represented as 5 tokeNotes in 1D or 2D bar codes or tones, which are converted to desired denomination and currency of registered merchant once particular registered merchant is selected before initiating offline mode or airplane mode known as signed encrypted virtual money which is essentially pseudorandom sequence, OTP and secret key; OTP and secret key are temporary passcode attached to each converted to 10 desired denomination and currency of registered merchant and shared to the merchant and to the customer; and signed encrypted virtual money that are stored in the wallet of the customer are decrypted by merchants phone by matching the OTP and secret key, therefore transferring of funds or data payload passed from the customer to merchant is performed only when the storage device is appropriately 15 placed.
In an embodiment of the present invention the invention provides a system to enable offline transaction comprising of a communication module allowing the customer to select a particular registered merchant and sending interest; receiving a transaction acknowledgement and converting the wallet balance; activating offline mode or 20 airplane mode; and synchronizing with the server on coming back online and furnishing the latest balance; and a server providing the compiled list of all registered merchants in the area of the customer; demarcating a balance in the wallet for paying the merchants in "offline only" mode from the available balance by a customer, recording the last known location and feeding the location for physical transaction; 25 initiating transfer on acquiring physical proximity with the merchant, performing fund transfer by exchanging wallet balance, balance or funds are represented as server encrypted virtual money pseudorandom sequence, which are converted to denomination of registered merchant once particular registered merchant is selected before initiating offline mode (or airplane mode), known as tokeNotes that are 30
9
represented as 1D or 2D bar codes or tones that are stored in the wallet of the customer and are decrypted by merchants phone, therefore transferring of funds or data payload passed from the customer to merchant is performed only when the storage device is appropriately placed.
DETAILED DESCRIPTION OF THE INVENTION 5
The present invention will now be described more fully hereinafter with reference to the accompanying description in which a preferred embodiment of the invention is described. This invention may, however, be embodied in many different forms and should not be construed as being limited to the embodiment set forth herein. Rather, the embodiment is provided so that this disclosure will be thorough, and will fully 10 convey the scope of the invention to those skilled in the art.
Definitions
Issuer server
The term "Merchant" shall refer to merchant(s) who may be an entity who sells goods or services in lieu of which remuneration is paid. Typically, this remuneration is in the form of money. In physical transactions, the money could be physical bank : The term "Issuer server" shall refer to the server which normally authorizes a customer’s transaction since it hosts the latest balance(s) and has access to the transaction history of the customer(s). This server can also be referred as the 15 ‘source of funds’. In a typical mobile money system, the issuer server hosts the customer’s ‘wallet’ or ‘account’ and all front-end applications and connects devices to it and act as transaction initiation points and transaction response delivery points. Thus, in a scenario where connectivity to this server is lost, a customer or a merchant’s device has no way of determining the actual balance or to know if there 20 are any pending transactions that needs to be authorized or declined. The issuer server is also the custodian of all the cryptography keys and implements a robust public key infrastructure. The issuer server is just a simplified term for the purpose of this discussion and itself may be comprised of multiple servers, devices, software, and even multiple hosting locations. 25
10
notes (currency notes) that may be exchanged. In electronic transactions, the transaction acquiring bank (with whom the merchant has a contractual relationship) provides a guarantee of payment through authorization codes which it itself procures from the issuer server for the customer. The actual payment into the merchant’s designated account takes place later (T+n days) where the acquirer transfers the net 5 amount due to the merchant after deducting due commissions that the merchant pays for availing the electronic payment acceptance service.
In present invention, a merchant is an entity who may also be offline (without access to the internet) but would still want to get paid by a customer who may be in close proximity. It may be noted that the merchant could also be online. The settlement 10 will happen at a later time and that there would be synchronization time when the merchant gains connectivity to the internet.
The issuer and the acquirer servers are the same entity because the system of settlement between an acquirer and an issuer, if different is known art and uses existing methods and processes. Further, the merchant has access to a programmable 15 internet capable device like a mobile smart-phone through which transaction will be executed.
Customer
In present invention, a customer is an entity who is offline (without access to the internet) but would still want to pay a merchant in close proximity. : The term "Customer" refers to an entity that keeps electronic balance with an issuer. The customer also has some shared secret(s)/authorization modes with the issuer server which he or she uses to authenticate a transaction or an 20 instruction where both the customer and the issuer need to be sure of each other. When a customer needs to make a payment transaction, the customer provides her identity in the form of some token, like a bank card, to the merchant. The merchant has some connected device which is used to send the merchant’s identity, the customer’s identity, the amount and optionally some authentication factor such as a 25 customer’s PIN.
11
Mobile Device
Working Sequence of the Invention: : The term "mobile device" refers to the programmable internet access device like a mobile smart-phone, tablet, or any other similar portable device.
In most preferred embodiment the method of typical sequence of events that leads to an offline payment accomplished using the proposed tokeNotes system includes: 5
Step 1. Customer indicates going offline
a. A customer using the system indicates intent for initiating an offline status (hereinafter referred to as ‘offline mode’). This would typically mean that the customer’s mobile phone would then enter into an ‘airplane mode’ or there is no internet access, further all available radio emitting and 10 receiving modules on the device may also be turned off.
b. The system further communicates with the server and records the current location of the customer. The server then extracts the location of all known merchants in the vicinity and sends the compiled list to the 15 customer.
c. The customer then selects a particular merchant that may be interested in offline transactions. For example, if the customer intends to catch a Flight, the Smartphone will typically have a SMS and/ or the email ticket for the 20 same. This shall allow the system in proactively suggesting and selecting the correct merchant from the list thus presented from the server.
d. The server shall then check the available balance in the wallet of the customer. The server demarcates certain balance to be utilized in 'offline 25 only mode'. It may be possible that the server may apply additional business logic to determine the amount (may be less than the total available balance) than the entire available balance of the customer in the
12
'offline only mode'. In the 'offline only mode', the demarcated amount can only be transacted by the customer's device, which was initially used to initiate the 'offline only mode' payment. The demarcated balance will be deducted from the customer’s available balance for all offline or server based transactions until the customer’s device indicates that it is no longer 5 in the offline mode.
e. Now, the server reduces the demarcated offline balance into the available denominations and in the currency of the merchant. For instance if the demarcated balance of the customer is INR 800, the server will break it 10 down as follows:
(INR 1 x 10) + (INR 10 x 9) + (INR 50 x 2) + (INR 100 x 1) + (INR 500 x 1)
f. This indicates a total of 23 individual units of different denominations 15 aggregating to a total of INR 800.
g. Then for the selected merchant, for each denomination, it will fetch the tokeNote key from its database, generate a random number N(such that max number of digits in Nis 5) and pass it to the OTP token generation 20 algorithm. An OTP generation algorithm generates a 6 digit OTP as follows: OTP (n) = f (key, N). Thus both the server and the client having access to the shared secret ‘key’ and a counter N should produce the same OTP. This may be any of the standard OTP generation algorithms available. Thus for each such unit of money, the server will derive a 25 unique 12 digit token. The first 3 characters in the token will represent the currency eg: INR, the next 1 character for the multiplier (single digit from 1 to 9) eg: 5, the next 1 character for the power of 10 (single digit from 0 to 9) eg: 1 = 10^1. Therefore the denomination being represented with INR51 = INR 5x10^1 = INR 50, next 5 digits indicating a sequence 30
13
number offset and the next 6 digits OTP into a 16 digit long token called the tokeNote.
h. The server passes back to the customer the tokeNotes for the demarcated amount. These notes are passed encrypted and digitally signed by the 5 server.
i. Each tokeNote thus derived on the server represents an individual unit of money being held in the online account of the customer but represented as unique tokens generated for the merchant selected for the offline 10 transaction.
j. The customer receives and stores these tokeNotes securely on device and then turns off all its radio modules/ enters the airplane mode.
15
k. The server also passes a copy of the merchant’s public key (Merchant (n).publicKey) to the customer.
l. The data payload passed from the server to the customer is encrypted using the public key of the customer Customer (n).publicKey and digitally 20 signed by the Server.privateKey for authenticity. Thus only the intended customer can decrypt the data passed and can verify that it was indeed sent by the original server.
Step 2. Merchant indicates Amount Payable 25
The merchant indicates the amount to be collected from a customer in his app. This information is passed on to the customer’s app using either sound tones (audio, captured using the microphone on the customer’s device) or a barcode (visually, captured using the camera on the customer’s device) or manually conveyed by the merchant to the customer who, in turn feeds it into his application. 30
14
Step 3. Customer initiates payment module
The customer’s app initiates its payment module. The process comprises the following steps:
a. The customer’s app which is now in the 'offline mode' picks up tokens of the appropriate denominations from the customer’s stored list of tokens in 5 the customer's device such that the exact amount is debited. E.g. If the amount is INR 205, the app will pick 1 token of INR 100, since no other tokens of INR 100 are available, would pick 2 tokens of INR 50 and then 1 token of INR 5. Thus, 4 unique tokens (tokeNotes) adding up to INR 205. Each of these tokens is then encrypted using the merchant’s public 10 key (merchant (n).publicKey) temporarily made available to the customer in the offline mode.
b. These tokens are shown as a carousel of 1 D bar codes, or a 2 D bar code or encoded as tones on the customer’s mobile phone (refer to prior art that already exists). The first code to be transmitted however contains the 15 identity of the customer (e.g. 10 digit mobile number). This information could also be digitally encrypted and signed.
c. The merchant’s mobile application when positioned correctly, reads the bar codes displayed on the customer’s mobile phone using the camera or by using the microphone to read the tones being played by the customer’s 20 mobile phones, will be able to read as an input all the tokens from the customer’s phone.
d. Once a token is in the carousel, it is deleted from the database i.e. it is deemed to have been used.
e. For each such token read, the merchant application first decrypts using 25 private key Merchant (n).privateKey and uses its OTP generation algorithm (identical to the one on the server). From each token, it derives the denomination, for which it pulls up the appropriate key for the denomination (from its secure local database). From each token, it also derives the 5 digit sequence number which it adds to the secret offset 30
15
seeded by the server to get the actual sequence number N. It then passes the key and N to the OTP functions to generate an OTP. If the generated OTP and the 6 digit pseudorandom part of the tokeNote sequence received from the customer’s phone match, the tokeNote is accepted! This act is the electronic and verified equivalent of a customer handing over an 5 equivalent physical note of a said denomination and the merchant accepting the same after due diligence on its authenticity.
Step 4. Merchant acknowledges transaction
Transaction acknowledgement is executed by the following steps: 10
a. For each accepted tokeNote, the merchant app optionally generates some acknowledgement tone/visual code that may be used by the customer app as a definitive confirmation that the payment is complete. The burden of confirmation is however with the merchant app.
b. In case the OTP's do not match, it is evident that either the tokens have 15 been tampered with or the tokens were intended for a different merchant. In either case, the merchant cannot accept these tokens and the transaction is declined.
c. In case there is some change/ cash back/ in the case of a declined transaction, the merchant’s app displays a visual carousel/ audio tone tag 20 of tokeNotes which the customer's app can read and store securely in its database.
Step 5. Synchronization with the server on going back online
a. After the transaction when a customer or a merchant connects their 25 respective devices to internet, the merchant app passes all the verified tokens it received to the server. The server marks them as used after verifying each (since server also has a copy of the merchant’s tokeNotes)
16
keys and then passes the amount as a transaction in the online transaction history of the customer.
b. Once a customer or a merchant app makes the synchronization, the server waits for the customer to get online. As soon as the customer app gets online, it passes all the unused tokens back to the server. The server 5 then pushes the latest balance and the offline transaction done back to the customer’s app.
c. All tokeNotes and the merchant key stored on the customer’s app are invalidated and are deleted from the customer’s mobile phone.
d. If a customer’s mobile device goes online before the merchant gets a 10 chance to synchronize/ upload his set of transactions and tokens. In this case, the outstanding tokens if any, with the customer are restored as the available online balance and the customer is now freed up to do more online transactions or to go offline again if required. However, this is now subject to verification by the data expected from the next time the 15 merchant’s app goes online.
Step 6. Reconciliation
In case there are any sync issues, appropriate logs available with the server, the merchant and the customer are used to understand the sequence of events and the 20 transaction events and its consequences are updated to all concerned.
Although the invention has been illustrated and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification. In addition, while a particular feature of the invention may have been disclosed with 25 respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. The names are purely indicative and are provided just to best describe the nature of the fund allocation.
17
In an embodiment of the present invention the invention provides a method to enable offline transaction comprising of steps of demarcating a balance in a wallet for paying a merchant in offline only mode from a available balance by a customer; recording a last known location and feeding the location for physical transaction; providing a compiled list of all registered merchants in the area of the customer; 5 allowing the customer to select a particular registered merchant and sending interest; receiving a transaction acknowledgement and converting the wallet balance; activating an offline mode or an airplane mode; initiating transfer on acquiring physical proximity with the merchant, performing fund transfer by exchanging the wallet balance, and synchronizing with the server on coming back online and 10 furnishing the latest balance; wherein: wallet balance or funds are represented as server encrypted virtual money pseudorandom sequence of a customer in 1D or 2D bar codes or tones, which are converted to desired denomination and currency of registered merchant once particular registered merchant is selected before initiating offline mode or airplane mode known as signed encrypted virtual money which is 15 essentially pseudorandom sequence, OTP and secret key; OTP and secret key are temporary passcode attached to each converted to desired denomination and currency of registered merchant and shared to the merchant and to the customer; and signed encrypted virtual money that are stored in the wallet of the customer are decrypted by merchants phone by matching the OTP and secret key, therefore 20 transferring of funds or data payload passed from the customer to merchant is performed only when the storage device is appropriately placed.
In an embodiment of the present invention the invention provides a systemto enable offline transaction comprising of a communication module allowing the customer to select a particular registered merchant and sending interest; receiving a transaction 25 acknowledgement and converting the wallet balance; activating offline mode or airplane mode; and synchronizing with the server on coming back online and furnishing the latest balance; and a server providing the compiled list of all registered merchants in the area of the customer; demarcating a balance in the wallet for paying the merchants in "offline only" mode from the available balance by a customer, 30
18
recording the last known location and feeding the location for physical transaction; initiating transfer on acquiring physical proximity with the merchant, performing fund transfer by exchanging wallet balance, balance or funds are represented as server encrypted virtual money pseudorandom sequence, which are converted to denomination of registered merchant once particular registered merchant is selected 5 before initiating offline mode or airplane mode known as signed encrypted virtual money pseudorandom sequence and OTP; and signed encrypted virtual money are 1D or 2D bar codes or tones that are stored in the wallet of the customer and are decrypted by merchants phone, therefore transferring of funds or data payload passed from the customer to merchant is performed only when the storage device is 10 appropriately placed.
Therefore, the foregoing is considered as illustrative only of the principles of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, all suitable 15 modifications and equivalents may be resorted to, falling within the scope of the invention.
19

CLAIMS
We Claim:
1. A method to enable offline transaction comprising of steps
demarcating a balance in a wallet for paying a merchant in offline only mode from a available balance by a customer;
recording a last known location and feeding the location for physical transaction;
providing a compiled list of all registered merchants in the area of the customer;
allowing the customer to select a particular registered merchant and sending interest;
receiving a transaction acknowledgement and converting the wallet balance;
activating an offline mode or an airplane mode;
initiating transfer on acquiring physical proximity with the merchant,
performing fund transfer by exchanging the wallet balance, and
synchronizing with the server on coming back online and furnishing the latest balance;
wherein:
wallet balance or funds are represented as server encrypted virtual money pseudorandom sequence of a customer in 1D or 2D bar codes or tones, which are converted to desired denomination and currency of registered merchant once particular registered merchant is selected before initiating offline mode or airplane mode known as signed encrypted virtual money which is essentially pseudorandom sequence, OTP and secret key;
20
OTP and secret key are temporary passcode attached to each converted to desired denomination and currency of registered merchant and shared to the merchant and to the customer; and
signed encrypted virtual money that are stored in the wallet of the customer are decrypted by merchants phone by matching the OTP and secret key, therefore transferring of funds or data payload passed from the customer to merchant is performed only when the storage device is appropriately placed.
2. The method as claimed in claim 1, wherein the demarcated offline balance is converted into available denominations and in the currency of the merchants.
3. The method as claimed in claim 1, wherein the location for physical transaction is independent of geographical boundaries.
4. The method as claimed in claim 1, wherein for a transaction matching numeric pseudorandom sequence and OTP should be matching.
5. A system to enable offline transaction comprising of
a communication module allowing the customer to select a particular registered merchant and sending interest; receiving a transaction acknowledgement and converting the wallet balance; activating offline mode or airplane mode; and synchronizing with the server on coming back online and furnishing the latest balance; and
a server providing the compiled list of all registered merchants in the area of the customer; demarcating a balance in the wallet for paying the merchants in "offline only" mode from the available balance by a customer, recording the last known location and feeding the location for physical transaction; initiating transfer on acquiring physical proximity with the merchant, performing fund transfer by exchanging wallet balance, balance or funds are represented as server encrypted virtual money pseudorandom sequence, which are converted to denomination of registered merchant once particular registered merchant is selected before
21
initiating offline mode or airplane mode known as signed encrypted virtual money pseudorandom sequence and OTP; and signed encrypted virtual money are 1D or 2D bar codes or tones that are stored in the wallet of the customer and are decrypted by merchants phone, therefore transferring of funds or data payload passed from the customer to merchant is performed only when the storage device is appropriately placed.
6. The system to enable offline transaction as claimed in claim 5, wherein said system uses existing asymmetric key cryptography to ensure secure communication with the server.
7. The system to enable offline transaction as claimed in claim 5, wherein appropriate logs available with said server which enables the merchant and the customer to understand the sequence of events and the transaction events.
8. The system to enable offline transaction as claimed in claim 5, wherein said offline transaction information is passed on to the customer either sound tones or a barcode or manually conveyed by the merchant to the customer who, in turn feeds it into his device.
9. The system to enable offline transaction as claimed in claim 5, wherein said data payload passed from the server to the customer is encrypted using the public key of the customer Customer (n).publicKey and digitally signed by the Server.privateKey for authenticity.