[001]The present invention relates to the domain of electronic payment transactions,
and more particularly to methods, systems and computer program products for electronic token based payment transactions that can be implemented in absence of network connectivity.
Background of the invention
[002]Electronic payment transactions involving payors making payments to
merchants, retailers or service providers electronically for goods or services are increasingly common. A popular type of electronic payment transaction involves initiating payment from a payor's electronic payment account to a payee's electronic payment account through a payment wallet application on a terminal device (such as a mobile communication device or smartphone) associated with the payor.
[003] Figure 1 illustrates a prior art system environment 100 for implementing
electronic payment transactions. System environment 100 comprises a payor 102 having access to payor terminal 104, a payee terminal 108, network 110, acquirer server 112 and issuer server 114.
[004] Payor terminal 104 may comprise any communication terminal configured for
network based communication. In specific embodiments, payor terminal 104 may comprise a mobile communication device or a smartphone or any other data processing terminal having network communication capabilities. Said payor terminal 104 may include a display 1042, a user interface 1044, a processor 1046, communication transceiver 1048 and memory 1050, which memory 1050 may include transitory memory and / or non-transitory memory. In an exemplary embodiment, memory 1050 may have stored therewithin, (i) an

operating system 1052 configured for managing device hardware and software resources configured to providing common services for software programs implemented within payor terminal 104, and (ii) a mobile wallet application (or a software payment application) 1054 configured to enable electronic payments from payor terminal 104.
[005] Payee terminal 108 may comprise any processor implemented payee terminal
having data processing capabilities and network communication capabilities. Exemplary devices that may be used as a payee terminal 108 include a computing device 1082, a mobile communication device / smartphone 1084 and /or a point-of-sale (POS) terminal 1086 configured to enable electronic payment transactions for crediting funds from a payment account associated with a payor into a payment account associated with the payee.
[006] Each of payor terminal 104 and payee terminal 108 may be connected to network
110 - which network may comprise any communication network configured to enable data communication between entities communicatively coupled with network 110. Payor terminal 104 may be configured for data communication with issuer server 114 through network 110 - wherein issuer server 114 is a server associated with an issuer, and with whom a payment account associated with the payor is maintained. Payee terminal 108 may be configured for data communication with acquirer server 112 through network 110 -wherein acquirer server 112 is a server associated with an acquirer, with whom a payment account associated with the payee is maintained. Acquirer server 112 and issuer server 114 may be additionally be configured to communicate with each other through network 110.
[007] Figure 2 illustrates a conventional method for implementing an electronic
payment transaction within the system environment of Figure 1.
[008] Step 202 comprises receiving payor payment account information, payee
payment account information and a payment transaction amount, at payor terminal 104. In an embodiment (i) the payor payment account information includes at least a payor payment account identifier, and optionally an identifier associated with an issuer with which the payor payment account is maintained, and / or (ii) the payee payment account

information includes at least a payee payment account identifier, and optionally an identifier associated with an acquirer with which the payee payment account is maintained. In an embodiment, the payee payment account information and the payment transaction amount may be received from the payor 102 through user interface 1044 of payor terminal 104. The payor payment account information may in an embodiment be retrieved from a mobile wallet application 1054 within payor terminal 104, or in certain embodiments may be determined based on input received from payor 102 through user interface 1044 of payor terminal 104.
[009] Step 204 comprises transmitting, from payor terminal 104 to issuer server 114, a payment request or a payment transaction instruction, along with the payor payment account information, payee payment account information and transaction amount.
[0010] Step 206 comprises ascertaining at issuer server 114, whether the payor payment account has sufficient available funds to carry out the requested payment - and thereafter responding to a determination that the payor payment account has sufficient funds for implementing the payment transaction, by initiating an identity authentication process flow. The identity authentication process flow may be based on any one or more identity authentication methods - including in particular embodiments, personal identification number (PIN) based authentication, one-time-password (OTP) based identity authentication, secret question based identity authentication, biometric identity authentication and / or any other identity authentication method that would be apparent to the skilled person. The identity authentication process flow may comprise a call-response process flow between issuer server 114 and payor terminal 104 for the purposes of verifying the identity of a user who is operating payor terminal 104.
[0011] At step 208, responsive to the payor's identity (i.e. the identity of the individual who is operating payor terminal 104) being satisfactorily verified, issuer server 114 debits the payment transaction amount from the payor payment account and initiates the process of crediting the payment transaction amount to the payee payment account by communicating with acquirer server 112.

[0012] Thereafter, step 210 comprises transmitting a transaction completion message to one or both of payor terminal 104 and payee terminal 108.
[0013] System environments and methods of the type illustrated in Figures 1 and 2 are ineffective in circumstances where one or both of payor terminal 104 and payee terminal / POS terminal 108 does not have network access or network connectivity and is therefore unable to communicate with one or both of issuer server 114 or acquirer server 112 or with any other network entity that is involved in implementing the desired electronic payment transaction.
[0014] In absence of network connectivity, a payor terminal 104 would be unable to communicate with an issuer server 114 (or other necessary network entity) for the purposes of requesting implementation of a payment transaction, and likewise a payee terminal 108 would be unable to communicate with an acquirer server 112 (or other necessary network entity) for the purposes of implementation of the payment transaction.
[0015] Additionally, even if there were mechanisms for implementing a payment transaction without network connectivity, entities participating in the payment transaction would be unable to ascertain sufficiency of funds in a payor payment account prior to authorizing the requested payment from the payor payment account to the payee payment account. As a result, in such situations there is no mechanism for ascertaining whether the transaction should be permitted, nor for instructing the issuer server 114, to initiate transfer of payment from the payor payment account to the payee payment account. Allowing a payment transaction without first ascertaining sufficiency of transaction funds available to the payor creates transaction uncertainly - since a payor could carry out a payment transaction in absence of network connectivity, and the payee would have no way of ascertaining whether the transaction will subsequently be rejected for insufficiency of funds in the payor payment account.

[0016] The lack of network connectivity is often faced in moving vehicles (for example,
when trying to make payment for taxi services in a low network signal area or when trying
to make payments within a metro or subway), and in locations where data network signal
strength is inherently low or is entirely absent (for example within basements, or within the
5 interiors or underground floors of buildings, or in other locations where network beam
penetration or network signal penetration is low or entirely absent) – as a result of which, parties to a payment transaction are unable to conclude such transactions electronically, and instead are forced to rely on cash payments.
10 [0017] There is accordingly a requirement for a solution that enables an electronic
payment transaction to be completed even in the absence of network access, while simultaneously eliminating the risk of subsequent transaction rejection (and of payment fraud) for insufficiency of funds in a payor payment account.
15 Summary
[0018] The invention provides methods, systems and computer program products for
electronic token based payment transactions that can be implemented in absence of network connectivity.
20
[0019] The invention provides, a method for implementing an electronic payment
transaction. The method comprises the steps of (i) receiving at a payor terminal, a payment instruction for initiating an electronic payment transaction for transferring a payment transaction amount from a payor payment account to a payee payment account, (ii)
25 responsive to a determination of unavailability of network connectivity between the payor
terminal and at least a first network entity required for the electronic payment transaction, retrieving from a memory coupled with the payor terminal, a first payor payment account state image, wherein the first payor payment account state image includes at least an available account balance associated with the payor payment account, (iii) extracting a first
30 account balance from the retrieved first payor payment account state image, wherein the
first account balance is the available account balance associated with the payor payment
6

account that is included within the retrieved first payor payment account state image, (iv)
responsive to a determination that the first account balance is sufficient for transferring the
payment transaction amount to the payee payment account, generating an electronic
payment token at the payor terminal, wherein the electronic payment token encodes the
5 payment transaction amount and payor account information, (v) generating and storing in
the memory coupled with the payor terminal, a second payor payment account state image associated with the payor payment account, wherein the second payor payment account state image comprises a second account balance that is determined by debiting the payment transaction amount from the first account balance, (vi) providing the generated electronic
10 token to a payee terminal, and (vii) responsive to resumption of network connectivity with
the first network entity required for the electronic payment transaction, initiating updating of an account state of the payor payment account at an issuer server associated with the payor payment account, wherein updating the account state of the payor payment account is based on data extracted from the second payor payment account state image.
15
[0020] In an embodiment, of the method (i) updating the account state of the payor
payment account is also based on a transaction metadata record associated with the payor payment account and transmitted to the issuer server, and (ii) the transaction metadata record associated with the payor payment account comprises a data record of electronic
20 payment transactions associated with the payor payment account.
[0021] In a further method embodiment, the transaction metadata record associated
with the payor payment account has been updated at the payor terminal to record at least,
debiting the payment transaction amount from the first account balance, and the payee
25 account information.
[0022] In a particular method embodiment, updating of the account state of the payor
payment account at the issuer server comprises recording the second account balance as the account balance associated with the payor payment account. 30
7

[0023] In one method embodiment, updating the account state of the payor payment
account at the issuer server includes initiation of transfer of the payment transaction amount from the payor payment account to the payee payment account, by the issuer server.
5 [0024] In a specific embodiment of the method, the first network entity required for the
electronic payment transaction is the issuer server.
[0025] In an embodiment of the method, the payee terminal (i) extracts from the
electronic token, the encoded payment transaction amount and payor account information,
10 (ii) responsive to a determination of unavailability of network connectivity between the
payee terminal and at least a second network entity required for the electronic payment transaction, retrieves from a memory coupled with the payee terminal, a first payee payment account state image, wherein the first payee payment account state image includes at least an available account balance associated with the payee payment account, (iii) extracts a third
15 account balance from the retrieved first payee payment account state image, wherein the
third account balance is the available account balance associated with the payee payment account that is included within the retrieved first payee payment account state image, (iv) generates and stores in the memory coupled with the payor terminal, a second payee payment account state image associated with the payee payment account, wherein the
20 second payee payment account state image comprises a fourth account balance that is
determined by adding the payment transaction amount to the third account balance, and (v) responsive to resumption of network connectivity with the second network entity required for the electronic payment transaction, initiates updating of an account state of the payee payment account at an acquirer server associated with the payee payment account, wherein
25 updating the account state of the payee payment account is based on data extracted from the
second payee payment account state image.
[0026] The method may additionally include the steps of (i) updating the account state
of the payee payment account is also based on a transaction metadata record associated with
30 the payee payment account and transmitted to the acquirer server, and (ii) the transaction
8

metadata record associated with the payee payment account comprises a data record of electronic payment transactions associated with the payee payment account.
[0027] In an embodiment of the method, the transaction metadata record associated with
5 the payee payment account has been updated at the payee terminal to record at least, adding
the payment transaction amount to the third account balance, and the payor account information.
[0028] In a further embodiment of the method, updating of the account state of the payee
10 payment account at the acquirer server comprises recording the fourth account balance as
the account balance associated with the payee payment account.
[0029] In a particular method embodiment, the second network entity required for the
electronic payment transaction is the acquirer server.
15
[0030] The invention additionally provides a system for implementing an electronic
payment transaction. The system comprises a processor implemented payor terminal configured to implement the steps of (i) receiving a payment instruction for initiating an electronic payment transaction for transferring a payment transaction amount from a payor
20 payment account to a payee payment account, (ii) responsive to a determination of
unavailability of network connectivity between the payor terminal and at least a first network entity required for the electronic payment transaction, retrieving from a memory coupled with the payor terminal, a first payor payment account state image, wherein the first payor payment account state image includes at least an available account balance associated
25 with the payor payment account, (iii) extracting a first account balance from the retrieved
first payor payment account state image, wherein the first account balance is the available account balance associated with the payor payment account that is included within the retrieved first payor payment account state image, (iv) responsive to a determination that the first account balance is sufficient for transferring the payment transaction amount to the
30 payee payment account, generating an electronic payment token at the payor terminal,
wherein the electronic payment token encodes the payment transaction amount and payor
9

account information, (v) generating and storing in the memory coupled with the payor
terminal, a second payor payment account state image associated with the payor payment
account, wherein the second payor payment account state image comprises a second account
balance that is determined by debiting the payment transaction amount from the first
5 account balance, (vi) providing the generated electronic token to a payee terminal, and (vii)
responsive to resumption of network connectivity with the first network entity required for
the electronic payment transaction, initiating updating of an account state of the payor
payment account at an issuer server associated with the payor payment account, wherein
updating the account state of the payor payment account is based on data extracted from the
10 second payor payment account state image.
[0031] In an embodiment, the system may be configured such that (i) updating the
account state of the payor payment account is also based on a transaction metadata record
associated with the payor payment account and transmitted to the issuer server, and (ii) the
15 transaction metadata record associated with the payor payment account comprises a data
record of electronic payment transactions associated with the payor payment account.
[0032] The system may be configured such that the transaction metadata record
associated with the payor payment account has been updated at the payor terminal to record
20 at least, debiting the payment transaction amount from the first account balance, and the
payee account information.
[0033] In another embodiment, the system is configured such that, wherein updating of
the account state of the payor payment account at the issuer server comprises recording the
25 second account balance as the account balance associated with the payor payment account.
[0034] In a particular embodiment, the system may be configured so that, updating the
account state of the payor payment account at the issuer server includes initiation of transfer
of the payment transaction amount from the payor payment account to the payee payment
30 account, by the issuer server.
10

[0035] The system may also be configured such that the first network entity required for
the electronic payment transaction is the issuer server.
[0036] In a specific embodiment of the system, the payee terminal is configured to (i)
5 extract from the electronic token, the encoded payment transaction amount and payor
account information, (ii) responsive to a determination of unavailability of network connectivity between the payee terminal and at least a second network entity required for the electronic payment transaction, retrieve from a memory coupled with the payee terminal, a first payee payment account state image, wherein the first payee payment
10 account state image includes at least an available account balance associated with the payee
payment account, (iii) extract a third account balance from the retrieved first payee payment account state image, wherein the third account balance is the available account balance associated with the payee payment account that is included within the retrieved first payee payment account state image, generate and store in the memory coupled with the payor
15 terminal, a second payee payment account state image associated with the payee payment
account, wherein the second payee payment account state image comprises a fourth account balance that is determined by adding the payment transaction amount to the third account balance, and (iv) responsive to resumption of network connectivity with the second network entity required for the electronic payment transaction, initiate updating of an account state
20 of the payee payment account at an acquirer server associated with the payee payment
account, wherein updating the account state of the payee payment account is based on data extracted from the second payee payment account state image.
[0037] In a particular configuration of the system, (i) updating the account state of the
25 payee payment account is also based on a transaction metadata record associated with the
payee payment account and transmitted to the acquirer server, and (ii) the transaction metadata record associated with the payee payment account comprises a data record of electronic payment transactions associated with the payee payment account.
30 [0038] The system may be configured such that the transaction metadata record
associated with the payee payment account has been updated at the payee terminal to record
11

at least, adding the payment transaction amount to the third account balance, and the payor account information.
[0039] The system may further be configured such that, updating of the account state of
5 the payee payment account at the acquirer server comprises recording the fourth account
balance as the account balance associated with the payee payment account.
[0040] In an embodiment of the system, the second network entity required for the
electronic payment transaction is the acquirer server.
10
[0041] The invention also provides a computer program product for implementing an
electronic token based payment transaction,. The computer program product comprises a non-transitory computer usable medium having a computer readable program code embodied therein, the computer readable program code comprising instructions for (i)
15 receiving at a payor terminal, a payment instruction for initiating an electronic payment
transaction for transferring a payment transaction amount from a payor payment account to a payee payment account, (ii) responsive to a determination of unavailability of network connectivity between the payor terminal and at least a first network entity required for the electronic payment transaction, retrieving from a memory coupled with the payor terminal,
20 a first payor payment account state image, wherein the first payor payment account state
image includes at least an available account balance associated with the payor payment account, (iii) extracting a first account balance from the retrieved first payor payment account state image, wherein the first account balance is the available account balance associated with the payor payment account that is included within the retrieved first payor
25 payment account state image, (iv) responsive to a determination that the first account
balance is sufficient for transferring the payment transaction amount to the payee payment account, generating an electronic payment token at the payor terminal, wherein the electronic payment token encodes the payment transaction amount and payor account information, (v) generating and storing in the memory coupled with the payor terminal, a
30 second payor payment account state image associated with the payor payment account,
wherein the second payor payment account state image comprises a second account balance
12

that is determined by debiting the payment transaction amount from the first account
balance, (vi) providing the generated electronic token to a payee terminal, and (vii)
responsive to resumption of network connectivity with the first network entity required for
the electronic payment transaction, initiating updating of an account state of the payor
5 payment account at an issuer server associated with the payor payment account, wherein
updating the account state of the payor payment account is based on data extracted from the second payor payment account state image.
10 Brief description of the accompanying drawings
[0042] Figure 1 illustrates a prior art system environment for implementing electronic
payment transactions.
15 [0043] Figure 2 illustrates a method for implementing an electronic payment transaction
within the system environment of Figure 1.
[0044] Figure 3 illustrates a system environment in accordance with the teachings of the
present invention, configured for implementing electronic payment transactions in absence
20 of network connectivity.
[0045] Figure 4 illustrates in further detail communicating entities within the system
environment of Figure 3.
25 [0046] Figure 5 is a flowchart illustrating a method of updating a local memory of a
terminal device with payment account information received from a server associated with the payment account.
[0047] Figure 6 is a communication flow diagram illustrating communication flow
30 between system entities for implementing the method of Figure 5.
13

[0048] Figure 7A illustrates an exemplary data record of a type that may be used to store
a payment account state image within a local memory of a terminal device.
[0049] Figure 7B illustrates an exemplary data record of a type that may be encoded
5 within an electronic token, in accordance with the teachings of the present invention.
[0050] Figure 8 is a flowchart illustrating method steps implemented at a payor terminal
that is configured for implementing electronic payment transactions in absence of network connectivity in accordance with the teachings of the present invention. 10
[0051] Figure 9 is a communication flow diagram illustrating communication flow
between system entities for implementing the method of Figure 8.
[0052] Figure 10 is a flowchart illustrating method steps implemented at a payee
15 terminal that is configured for implementing electronic payment transactions in absence of
network connectivity in accordance with the teachings of the present invention.
[0053] Figure 11 is a communication flow diagram illustrating communication flow
between system entities for implementing the method of Figure 10. 20
[0054] Figure 12 illustrates an exemplary computer system according to which various
embodiments of the present invention may be implemented.
Detailed description
25
[0055] The invention provides methods, systems and computer program products for
electronic token based payment transactions that can be implemented in absence of network connectivity.
30 [0056] For the purposes of the present invention, the following terms shall be understood
to have the corresponding meanings provided below.
14

[0057] “Acquirer” shall mean a business (e.g., a financial institution or a merchant bank)
that contracts with a merchant or payee to coordinate with an issuer of a payor’s payment card or payment account. 5
[0058] “Acquirer server” shall refer to one or more servers, including hardware, software
and other equipment used by an acquirer to transmit and process payment card based transactions or payment account based transactions and information related to merchants, customers, payment cards, payment accounts and / or transactions. 10
[0059] “Card holder” or “Account holder” shall mean an authorized payment card user or
an authorized user of a payment account who is making a purchase or effecting an electronic transaction with a payment card or a payment account.
15 [0060] “Electronic token” shall mean any machine-readable object that encodes
transaction information, payee information or payor information – and may comprise any code, cipher, machine readable data representation, or 1-dimensional or 2-dimensional bar code(s) (including by way of example linear bar codes or QR codes) that is readable by an appropriately configured terminal device or optical machine reader.
20
[0061] “Issuer” shall mean a financial institution that issues payment cards or payment
accounts to users.
[0062] “Issuer server” shall refer to one or more servers, including hardware, software
25 and other equipment used by an issuer to transmit and process payment card transactions
or payment account transactions and information related to customers, payment cards, payment accounts and/or transactions.
[0063] “Merchant” shall mean an authorized acceptor of payment cards or payment from
30 a payment account for the payment of goods or services sold by the merchant.
15

[0064] “Merchant server” shall refer to one or more servers, including hardware,
software and other equipment used by a merchant to transmit and process payment card transactions or payment account transactions and information related to customers, payment cards, payment accounts and/or transactions. 5
[0065] “Payee” and “Merchant” may be used interchangeably to designate an individual
or entity receiving an electronic payment.
[0066] “Payee payment account information” shall mean payment account information
10 corresponding to a payee in an electronic payment transaction.
[0067] “Payment account” shall mean any account that may be used for the purposes of
effecting an electronic payment or electronic transaction, and shall include any electronic transaction account, payment card account, bank account or electronic wallet account.
15
[0068] “Payment account information” shall mean information identifying a payment
account and / or properties or attributes of said payment account, and shall include without limitation any of an account number, account identifier, account issuer, and / or account type.
20
[0069] “Payment card” shall mean a card or data associated with a payment account that
may be provided to a merchant or payee in order to enable a financial transaction via the associated payment account. Payment cards may include credit cards, debit cards, charge cards, stored-value cards, prepaid cards, fleet cards, virtual payment numbers, virtual card
25 numbers, controlled payment numbers, etc. A payment card may be a physical card that may
be provided to a merchant, or may be data representing the associated payment account (e.g., as stored in a communication device, such as a smart phone or computer). For example, in some instances, data including a payment account number may be considered a payment card for the processing of a transaction funded by the associated payment account. In some
30 instances, a check may be considered a payment card where applicable.
16

[0070] “Payment network” shall refer to any intermediary network communicatively
disposed between any two or more of the merchant server, acquirer bank server and issuer
bank server. In certain embodiments, the payment network may comprise a card network
that enables communication between the issuer bank and the acquirer bank (for example,
5 Mastercard® or Visa®). In such embodiments, the card network primarily coordinates
payment card transactions between acquirers and issuers, and additionally coordinates clearing and settlement services to transfer payments from issuers to merchants.
[0071] “Payor”, “consumer” and “customer” may be used interchangeably to designate an
10 individual or entity making an electronic payment.
[0072] “Payor payment account information” shall mean payment account information
corresponding to a payor in an electronic payment transaction.
15 [0073] Figure 3 illustrates a system environment 300 in accordance with the teachings
of the present invention, configured for implementing electronic payment transactions in absence of network connectivity.
[0074] System environment 300 includes a payor 302 having access to payor terminal
20 304, a payee terminal 308, network 310, acquirer server 312 and issuer server 314.
[0075] Payor terminal 304 may comprise any communication terminal configured for
network based communication. In specific embodiments, payor terminal 304 may comprise a mobile communication device or a smartphone. Said payor terminal 304 may include a
25 display 3042, a user interface 3044, a processor 3046, communication transceiver 3048 and
memory 3050, which memory 3050 may include transitory memory and / or non-transitory memory. In an exemplary embodiment, memory 3050 may have stored therewithin, (i) an operating system 3052 configured for managing device hardware and software resources and configured to provide common services for software programs implemented within
30 payor terminal 304, (ii) a mobile wallet application (or a software payment application)
3054 configured to enable initiation of electronic payments from payor terminal 304, (iii) an
17

image generator 3056 configured to generate an image or a data record representing a data
state corresponding to a payment account associated with payor 302 or payor terminal 304
- which information may have been retrieved from issuer server 314 and (iv) a token
generator 3058 configured to generate an electronic token (for example electronic token
5 306) comprising encoded and / or encrypted information corresponding to an electronic
payment transaction, and which encoded / encrypted information may include one or more
of payor payment account information, payee payment account information and a payment
transaction amount associated with a payment transaction under implementation. The
functionality of image generator 3056 and token generator 3058 is discussed in more detail
10 subsequently in this written description.
[0076] Payee terminal 308 may comprise any processor implemented terminal device
having data processing capabilities and network communication capabilities. Exemplary
devices that may be used as a payee terminal 308 may comprise a computing device 3082, a
15 mobile communication device / smartphone 3084 and /or a point-of-sale (POS) terminal
3086, configured to enable electronic payment transactions into a payment account associated with the payee.
[0077] Each of payor terminal 304 and payee terminal 308 are connected to network 310
20 – which network may comprise any communication network configured to enable data
communication between entities communicatively coupled with network 310. Payor
terminal 304 may be configured for data communication with issuer server 314 through
network 310 – wherein issuer server 314 is a server associated with an issuer, with whom a
payment account associated with the payor is maintained. Payee terminal 308 may be
25 configured for data communication with acquirer server 312 through network 310 –
wherein acquirer server 312 is a server associated with an acquirer, with whom a payment account associated with the payee is maintained. Acquirer server 312 and issuer server 314 may be additionally be configured to communicate with each other through network 310
30 [0078] Figure 4 illustrates in further detail, the communicating entities within the system
environment 300 of Figure 3.
18

[0079] As illustrated in Figure 4, payor terminal 304 comprises hardware 3060 (which
may include any of display 3042, user interface 3044, processor 3046, communication
transceiver 3048 and memory 3050, as illustrated in Figure 3), and has implemented
5 therewithin, mobile wallet application (or a software payment application) 3054, image
generator 3056, and token generator 3058.
[0080] Image generator 3056 may be configured to generate an image or a data record
representing a data state corresponding to a payment account associated with payor 302 or
10 payor terminal 304 – which information may have been retrieved from issuer server 314.
Token generator 3058 may be configured to generate an electronic token 306 comprising encoded and / or encrypted information corresponding to an electronic payment transaction involving payor terminal 304 and payee terminal 308 – and which electronic token 306 includes one or more of payor payment account information, payee payment account
15 information and a payment transaction amount associated with a payment transaction
under implementation.
[0081] Payee terminal 308 may comprise hardware 3088 (which may include any of a
display, a user interface, a processor, a communication transceiver, and transitory and / or
20 non-transitory memory), and has implemented therewithin, a payment application 3082,
token reader 3084, and image generator 3086.
[0082] Token reader 3084 is a processor implemented reader that may be configured to
receive electronic token 306 and to parse, decode, decrypt and / or extract from electronic
25 token 306, the information corresponding to the electronic payment transaction involving
payor terminal 304 and payee terminal 308 – including one or more of payor payment account information, payee payment account information and a transaction amount associated with a payment transaction under implementation.
30 [0083] Image generator 3086 may be configured to generate an image or a data record
representing a data state corresponding to a payment account associated with the payee or
19

with payee terminal 308 – which information may have been retrieved from acquirer server 314.
[0084] Each of payor terminal 304 and payee terminal 308 are communicably coupled
5 with network 310 – and may through network 310, communicate with acquirer server 312
and / or issuer server 314.
[0085] In specific embodiments of system environment 300, electronic token 306
generated by payor terminal 304 may comprise any machine-readable object that encodes
10 transaction information, payee information or payor information – and may comprise any
code, cipher, machine readable data representation, or 1-dimensional or 2-dimensional bar codes (including by way of example linear bar codes or QR codes) that is readable by an appropriately configured terminal device or optical machine reader. Electronic token 306 may be transferred from payor terminal 304 to payee terminal 308 through wireless or
15 wired transmission. In certain embodiments, where electronic token 306 is an optical code
such as a 1-dimensional or 2-dimensional bar code (for example a linear bar code or QR code), electronic token 306 may be displayed on a display 3042 controlled by payor terminal 304 and may be scanned or imaged by an imaging assembly or image sensor or other sensor provided within or communicably coupled with payee terminal 308, and may be transmitted
20 from the imaging assembly or image sensor or other sensor to a processor within payee
terminal 308 for subsequent parsing and data extraction.
[0086] As explained in more detail below, the system environment of Figures 3 and 4 is
configured to enable electronic payment transactions that can be implemented in absence of
25 network connectivity. The system environment 300 achieves this based on (i) stored images
or data records representing the most current or a most recently retrieved data state corresponding to a payment account – which data state has been retrieved from an issuer server associated with an issuer of the payment account, and which has been stored in a local memory of a terminal device associated with the payment account or with an account holder
30 of the payment account and (ii) an electronic token generated by a payor terminal which can
be generated and transmitted from the payor terminal to a payee terminal even in absence
20

of network connectivity with one or both of an acquirer server and issuer server – and which
electronic token comprises encoded and / or encrypted information corresponding to an
electronic payment transaction, including one or more of payor payment account
information, payee payment account information and a transaction amount associated with
5 the payment transaction under implementation.
[0087] Figure 5 is a flowchart illustrating a method of updating a local memory of a
terminal device with payment account information retrieved or received from a server
associated with the payment account – for the purpose of storing images or data records
10 representing a current or recent data state corresponding to the payment account, and which
has been retrieved from an issuer server associated with the issuer of the payment account.
[0088] Step 502 comprises detecting at a terminal device associated with a payment
account, a state image generation trigger event.
15
[0089] The terminal device at step 502 is a device that is associated with the payment
account or with the payment account holder in the records of the issuer – for example, a registered mobile device or a mobile device or computing device that is running a registered instance of a software application that is associated with the card holder or account holder
20 in the records of the issuer.
[0090] The detected state generation trigger event may comprise any detectable trigger
event that has been predefined (in either the local memory of the terminal device or at a server associated with the payment account) as an event that triggers storage of a current
25 data state associated with the payment account in a local memory of the terminal device
associated with that payment account. Non-limiting exemplary instances of state image generation trigger events that may be detected at step 502 may comprise any of (i) detection of a defined date and / or time event, (ii) elapse of a predefined time interval since the immediately preceding detected state image generation trigger event, (iii) detection of
30 network signal strength or network connectivity or network speed equal to or above a
predefined value, (iv) detection of network signal strength or network connectivity or
21

network speed below a predefined value, (v) detection of any predefined network parameter, geographic parameter or data connectivity parameter, or (vi) detection of any software event or hardware event at the terminal device or at the server associated with the payment account. 5
[0091] At step 504, responsive to detection of the state image generation trigger event,
and responsive to availability of network connectivity between the terminal device and an issuer server associated with the payment account, state information corresponding to the payment account is retrieved from a state information database associated with the issuer
10 server. The state information corresponding to the payment account includes at least a
current account balance associated with the payment account, and may additionally include one or more of, an account identifier associated with the payment account, and a time stamp associated with the state information retrieved from the state information database – which time stamp may represent a time at which the state information was transmitted by or
15 retrieved from the state information database.
[0092] Step 506 comprises generating, based on the retrieved state information, a
payment account state image corresponding to the payment account. The generated
payment account state image may encode and / or store within a data record, the state
20 information corresponding to the payment account that has been retrieved from the state
information database associated with the issuer server.
[0093] At step 508, the payment account state image generated at step 506 is retrievably
stored within a local memory of the terminal device associated with the payment account. In
25 an embodiment, the payment account state image is stored along with a time stamp or other
data that enables the terminal device to identify from among a plurality of payment account state images stored within the local memory, a current or most recently generated payment account state image associated with the payment account.
22

[0094] Figure 7A illustrates an exemplary data record 700A of a kind that may be used to
store a payment account state image that has been generated in accordance with step 506 of Figure 5, within a local memory of a terminal device.
5 [0095] As illustrated in Figure 7A, data record 700A may be configured to include at least
a first data field 702A configured to store a payment account identifier associated with the
payment account, a second data field 704A configured to store information representing
available funds in the payment account, and a third data field 706A configured to store a time
stamp representing a time and / or date at which the payment account state information was
10 retrieved from an issuer server, or at which the payment account state image has been
generated.
[0096] Figure 6 is a communication flow diagram illustrating communication flow
between a terminal device 602 and an issuer server 604 for implementing the method of
15 Figure 5.
[0097] As shown in Figure 6, at step 6002, responsive to detection of a state image
generation trigger event, and responsive to availability of network connectivity between terminal device 602 and issuer server 604 associated with the concerned payment account (i.e. a payment account with which terminal device 602 is associated), terminal device 602 requests payment account state information corresponding to the concerned payment account from issuer server 604. Issuer server 604 retrieves the requested payment account state information (for example from a state information database coupled with issuer server 604) and at step 6004, transmits the payment account state information to terminal device 602.
[0098] Terminal device 602 thereafter generates (based on the received payment
account state information), a payment account state image corresponding to the payment
account. The generated payment account state image may encode and / or store within a
30 data record, the state information corresponding to the payment account that has been
retrieved from the state information database associated with issuer server 604. In other
23

embodiments, the payment account state image may be generated at issuer server 604 and may be transmitted to terminal device 602 at step 6004.
[0099] At step 6006, the generated payment account state image is stored within a local
5 memory of terminal device 602. In an embodiment, the payment account state image is
stored along with a time stamp or other data that enables terminal device 602 to identify from among a plurality of payment account state images stored within the local memory, a current or most recently generated payment account state image associated with the payment account.
10
[00100] Figure 8 is a flowchart illustrating method steps implemented at a payor terminal for implementing electronic payment transactions in absence of network connectivity in accordance with the teachings of the present invention. In certain embodiments, the payor terminal of Figure 8 may comprise a payor terminal 304 in accordance with the
15 configurations described above in connection with Figures 3 and 4.
[00101] Step 802 comprises receiving at payor terminal 304 associated with a payor payment account, a payment instruction for initiating an electronic payment transaction transferring a transaction payment amount from a payor payment account to a payee
20 payment account. Payor terminal 304 may comprise any data processing terminal
configured for network based communication. In specific embodiments, payor terminal 304 may comprise a mobile communication device or a smartphone. Payor terminal 304 is a device that is associated with the payor payment account or with the payor in the records of an issuer – for example, a registered mobile device or a mobile device or computing device
25 that is running a registered instance of a software application that is associated with the
payor in the records of the issuer. Additionally, payor terminal 304 may comprise a terminal device that has a current (or recent) payment account state image associated with the payor payment account, stored within a local memory of said terminal device – which payment account state image has been generated and stored in the local memory in accordance with
30 the method described above in connection with Figure 5. The payment instruction of step
802 may be initiated based on user input received at payor terminal 304.
24

[00102] Step 804 comprises receiving at payor terminal 304, a payment transaction
amount, and optionally payee account information – for implementing the payment
transaction. The payment transaction amount and payee information may be received
5 through user input at payor terminal 304 – for example through user interface 3044.
[00103] At step 806, responsive to determining that network connectivity with an issuer server 314 or with another network entity that is involved in (or required for) the payment transaction, is unavailable, a payor payment account state image is retrieved from the local memory 3050 of payor terminal 304. In embodiments of the method, where the local memory 3050 stores a plurality of payor payment account state images associated with the payor payment account, the payor payment account state image that is retrieved at step 806 may comprise the payor payment account state image that represents the most current or most recently recorded data state of the payor payment account. The payor payment account state image that represents the current or most recently recorded data state of the payor payment account may in certain embodiments be identified based on time stamp information within or associated with each payor payment account state image. The retrieved payor payment account state image may in an embodiment comprise a payor payment account state image that has been generated and stored by image generator 3056 in accordance with the method of Figure 5.
[00104] At step 808, a first account balance is extracted from the retrieved payor payment
account stage image – where the first account balance represents the available account
balance associated with the payor payment account that is recorded within the retrieved
25 payor payment account state image.
[00105] At step 810, (i) responsive to the first account balance indicating sufficiency of
funds within the payor payment account for the purpose of transferring the payment
transaction amount from the payor payment account to the payee payment account, and (ii)
30 optionally, responsive to successful identity authentication of the person operating the payor
terminal (in accordance with any identity authentication methods or process flows that
25

would be apparent to the skilled person) – payor terminal 304 generates an electronic token
306 which encodes, encrypts or otherwise records at least the (a) payor account information
and (b) the payment transaction amount and (c) optionally payee account information. In
an embodiment, electronic token 306 may be generated by token generator 3058 within
5 payor terminal 304.
[00106] Step 812 comprises generating and storing in a local memory associated with the
payor terminal, an updated payor payment account state image associated with the payor
payment account – wherein the updated payor payment account state image comprises a
10 second account balance that is determined by debiting the payment transaction amount
from the first account balance.
[00107] Step 814 comprises optionally updating a transaction metadata record that is associated with the payor payment account to record one or more of (i) the debiting of the payment transaction amount from the first account balance, (ii) the payee account information, and (iii) any other details corresponding to the electronic payment transaction. The transaction metadata record comprises a data record of electronic payment transactions associated with the payor payment account – and may include any one or more of, a description of each transaction, payor payment account information, payee payment account information, payment transaction amount, transaction type (e.g. credit transaction or debit transaction), a time stamp associated with such transaction, and / or any other relevant information, each associated with such transaction. The transaction metadata record may comprise a record of all transactions associated with the payor payment account. In another embodiment, the transaction metadata record may comprise a record of all transactions associated with the payor payment account that has been implemented through payor terminal 304.
[00108] At step 816, payor terminal 304 provides the generated electronic token 306 to a
payee terminal 308. Electronic token 306 may be transmitted from payor terminal 304 to
30 payee terminal 308 wirelessly or over one or more wired connections, or over a combination
of both. In an embodiment where electronic token 306 is an optically readable code, said
26

electronic token 306 may be displayed on a display 3042 controlled by payor terminal 304 and may be scanned or imaged by a scanner or image sensor or a token reader 3084 within or communicatively coupled with payee terminal 308.
5 [00109] Thereafter, at step 818, responsive to resumption of network connectivity with
issuer server 314 or with such other network entity involved in the payment transaction with whom network connectivity was previously unavailable, payor terminal 304 initiates updating of an account state of the payor payment account at issuer server 314. The update of an account state of the payor payment account at issuer server 314 is based on one or both
10 of the updated payor payment account state image generated at step 812 and the updated
transaction metadata record generated at step 814. It would be understood that for the purposes of the update at step 818, a request for updating an account state of the payor payment account at issuer server 314, along with one or both of the updated payor payment account state image and the updated transaction metadata record, are transmitted from
15 payor terminal 304 to issuer server 314 – based on a network connection between the two
entities. Issuer server 314 may thereafter update an account state of the payor payment account based on the received request, data extracted from the updated payor payment account state image and / or data extracted from the updated transaction metadata record. The update to the account state of the payor payment account may reflect the payment
20 transaction, the debit of funds to the previous account balance of the payor payment account,
the credit of funds to a payee payment account and / or the new reduced account balance associated with the payor payment account. The update to the account state of the payor payment account may additionally include initiation of transfer of the payment transaction amount from the payor payment account to the payee payment account by the issuer server.
25
[00110] Figure 7B illustrates an exemplary data record of a type that may be encoded within an electronic token 306, for the purposes of implementing the teachings of Figure 8.
[00111] As illustrated in Figure 7B, data record 700B may be configured to include at least
30 a first data field 702B configured to store a unique electronic token identifier 702B, a second
data field 704B configured to store payor payment account information, a third data field
27

706B configured to store payee account information, and a fourth data field 708B configured to store a transaction amount associated with electronic token 306.
[00112] In implementing the method of Figure 8, a particular concern from an issuer
5 perspective, is that in certain circumstances, permitting a payor terminal 304 to carry out
payment transactions in absence of network connectivity could result in debit transactions for payment amounts that exceed the available fund balance associated with the payor payment account.
[00113] This concern primarily arises where an available balance associated with the payor payment account may have changed since the most recent payor payment account state image was generated and stored by payor terminal 304. By way of example, one or more debits may have been made from the payor payment account through channels other than payor terminal 304, after a loss of network connectivity between payor terminal 304 and issuer server 314. As a result of such subsequent debits, the actual available balance associated with the payor payment account may be less than the available balance shown in the most recent payor payment account stage image that has been generated and stored by payor terminal 304 – resulting in payor terminal 304 permitting debits in excess of the actual available balance associated with the payor payment account.
[00114] It would be understood that, such debits that occur after loss of network connectivity with payor terminal 304, could potentially occur through channels other than payor terminal 304 (for example, through a payment card presented at a POS terminal, submission of a cheque drawn on the payment account, or by way of an electronic debit instruction received from a terminal other than payor terminal 304).
[00115] In a specific embodiment of the method described in connection with Figure 8,
issuer server 314 may be configured to address this risk by periodically ascertaining a state
of network connectivity between payor terminal 304 and issuer server 314 – i.e. to
30 periodically ascertain whether payor terminal 304 is in network communication with, or is
responding to network data messages transmitted from issuer server 314. The step of
28

ascertaining a state of network connectivity between payor terminal 304 and issuer server
314 may be achieved by one or more call-response type data messages or ping data messages
initiated by issuer server 314, targeting payor terminal 304. Depending on a response (or
lack of response) received from payor terminal 304, issuer server 314 determines or
5 evaluates a state of network connectivity between payor terminal 304 and issuer server 314.
[00116] Responsive to issuer server 314 determining that payor terminal 304 is not in network communication with issuer server 314 (or that a state of network communication between payor terminal 304 and issuer server 314 is unsatisfactory or unreliable), issuer
10 server 314 modifies one or more transaction permission state(s) associated with the payor
payment account. The modified transaction permission state(s) prevent implementation of any debit transactions from the payor payment account. The one or more modified transaction permission state(s) that prevent implementation of any debit transactions from the payor payment account, are maintained until issuer server 314 determines that network
15 connectivity (or satisfactory or reliable network connectivity) between payor terminal 304
and issuer server 314 has been restored. At such time, the modified transaction permission state(s) may be revoked or rolled back, so as to permit regular debit transactions from the payor payment account.
20 [00117] By imposing one or more modified transaction permissions state(s) on the payor
payment account, issuer server 314 ensures that while payor terminal 304 is out of network communication with issuer server 314, no debit transactions can be implemented through any channels other than payor terminal 304. As a result, any offline transactions that payor terminal 304 implements based on the last payor payment account state image stored at
25 payor terminal 304, cannot exceed the available funds balance associated with said payor
payment account.
[00118] One further concern that arises out of this embodiment (involving restriction of
debit transactions through other channels while a payor terminal is out of network
30 communication with an issuer server), is that there may be situations where the authorized
holder of the payor payment account is aware that payor terminal 304 is out of coverage
29

area, and nevertheless wants to implement a payment transaction through another payment channel (for example from another terminal device, or from a POS terminal or any other mechanism), instead of using the offline transaction mechanism through payor terminal 304 in accordance with the method of Figure 8. 5
[00119] To address such situations, issuer server 314 may be configured to receive from a terminal device, a suspension instruction initiated by the authorized holder or authorized operator of the payor payment account, wherein the suspension instruction (i) identifies a particular payor terminal 304 that is offline or out of network communication with issuer
10 server 314, or that is expected to be offline or out of network communication with issuer
server 314 at some point in the future and (ii) instructs issuer server 314 not to implement a modified transaction permission state(s) that would prevent implementation of any debit transactions from the payor payment account, despite a determination that the identified payor terminal 304 is out of network communication with issuer server 314.
15
[00120] The suspension instruction from the authorized holder or authorized operator of the payment account may require to be supported or verified based on one or more appropriate identity authentication methods (for example, biometric or password or OTP based identity verification). Issuer server 314 may be configured so that, subject to
20 appropriate identity authentication, and until the suspension instruction is revoked or
expires or is otherwise terminated, issuer server 314 does not implement a modified transaction permission state(s) that would prevent implementation of debit transactions from the payor payment account, despite any determination that the identified payor terminal 304 is out of network communication with issuer server 314. In a further
25 embodiment, as a result of implementation of the suspension instruction, any offline debit
transactions associated with the payor payment account that are sought to be implemented by identified payor terminal 304 while such suspension instruction is valid and in force at issuer server 314, shall be disregarded or rejected by the issuer server 314.
30 [00121] In another embodiment of the invention, issuer server 314 may be authorized to
temporarily suspend a modified transaction permission state(s) that has been imposed on a
30

payor payment account (in accordance with the embodiments discussed above) in response
to a determination that the identified payor terminal 304 is out of network communication
with issuer server 314. The need for a temporary suspension may arise for example where
payor terminal 304 is out of network communication with issuer server 314, during which
5 time, an authorized holder or authorized operator of the payor payment account wishes to
implement a payment-card based (i.e. a card-present) transaction or an electronic payment transaction involving the payor payment account through one or more other terminal devices that have network connectivity with issuer server 314 (for example, through a POS terminal or through another network communication enabled terminal device).
10
[00122] In such instances, issuer server 314 may be configured to (i) verify the identity of the person requesting the payment transaction from such other terminal device (for example, through biometric or password or OTP based identity verification) to ensure that such person is an authorized holder or operator of the payor payment account and (ii)
15 optionally verify that payor terminal 304 (which has been determined to be in an offline
state by issuer server 314) is present with the person requesting the payment transaction from such other terminal device (for example based on Bluetooth or Near-Field-Communication based communication between payor terminal 304 and the other terminal device at which the payment transaction is being requested – to verify the identity of payor
20 terminal 304 based on one or more device identifiers or software instance identifiers
associated with payor terminal 304).
[00123] Subject to verification of the above, issuer server 314 suspends a modified
transaction permission state(s) that has been imposed on a payor payment account (in
25 accordance with the embodiments discussed above), and permits the requested payment
transaction through such other terminal device.
[00124] Figure 9 is a communication flow diagram illustrating communication flow between system entities for implementing the method of Figure 8. 30
31

[00125] Step 9002 comprises receiving at payor terminal 902 (which payor terminal 902
is associated with a payor payment account), user input comprising a payment instruction
for initiating an electronic payment transaction from a payor payment account to a payee
payment account. The payment instruction received at step 9002 may include a payment
5 transaction amount, and optionally payor account information and / or payee account
information – for implementing the payment transaction.
[00126] Payor terminal 902 thereafter determines availability of required network
connectivity with an issuer server 904 (or with any other network entity that is involved in
10 the payment transaction). At step 9004, responsive to determining that network
connectivity with an issuer server 904 (or with any other network entity that is involved in the payment transaction), is unavailable, a payor payment account state image is retrieved from a local memory of payor terminal 902.
15 [00127] Payor terminal 902 thereafter extracts an account balance associated with the
payor payment account – and ascertains based on the extracted account balance, whether the payor payment account has sufficient funds to implement the payment instruction received at step 9002. Responsive to a determination that the payor payment account has sufficient funds available to implement the payment instruction, payor terminal 902
20 generates an electronic token - which electronic token encodes, encrypts or otherwise
includes at least (a) payor account information (b) the payment transaction amount and (c) optionally payee account information.
[00128] Step 9006 comprises generating and storing in a local memory associated with
25 payor terminal 902, an updated payor payment account state image associated with the
payor payment account – wherein the updated payor payment account state image
comprises a second account balance that is determined by debiting the payment transaction
amount from the first account balance. Step 9006 may additionally comprise updating a
transaction metadata record that is associated with the payor account. The transaction
30 metadata record comprises a data record of electronic payment transactions associated with
the payor payment account – and may include any one or more of, a description of each
32

transaction, payor payment account information, payee payment account information, payment transaction amount, transaction type (e.g. credit transaction or debit transaction), a time stamp associated with such transaction, and / or any other relevant information, each associated with such transaction. 5
[00129] At step 9008, responsive to resumption of network connectivity with issuer
server 904 or with such other network entity involved in the payment transaction with
whom network connectivity was previously unavailable, payor terminal 902 initiates
transmission of the updated payor payment account state image and / or the updated
10 transaction metadata record that has been generated and stored at step 9006.
[00130] At step 9010, issuer server 904 may thereafter update a data state or one or more
issuer records associated with the payor payment account - based on the received request,
the updated payor payment account state image and / or the updated transaction metadata
15 record – to reflect the payment transaction, the debit of funds to the previous account
balance of the payor payment account, the credit of funds to a payee payment account and / or the new reduced account balance associated with the payor payment account.
[00131] Figure 10 is a flowchart illustrating method steps implemented at a payee
20 terminal for implementing electronic payment transactions in absence of network
connectivity in accordance with the teachings of the present invention.
[00132] The payee terminal of Figure 10 may comprise a payee terminal 308 in accordance with the configurations described above in connection with Figure 3 and Figure 4.
25
[00133] Step 1002 comprises receiving at a payee terminal 308 (associated with a payee or with a payee payment account involved in an electronic payment transaction), an electronic token 306 that has been generated by a payor terminal 304. It would be understood that the electronic token 306 received at step 1002 may comprise an electronic
30 token 306 that has been generated by payor terminal 304 in accordance with step 810 of
Figure 8.
33

[00134] Electronic token 306 may be received at payee terminal 308 from payor terminal
304 either through wireless transmission or over one or more wired connections, or over a
combination of both. In an embodiment where electronic token 306 is an optically readable
5 code, said electronic token 306 may be displayed on a display 3042 of payor terminal 304
and may be scanned or imaged by a scanner or image sensor or a token reader 3084 within payee terminal 308.
[00135] Step 1004 comprises extracting from received electronic token 306, payor
10 payment account information and a payment transaction amount that has been encoded,
encrypted or otherwise stored within electronic token 306. In certain embodiments, step
1004 may additionally or optionally include extraction of payee account information from
electronic token 306. It would be understood that payee account information may be
encoded or stored within electronic token 306 in embodiments where the electronic token
15 is configured to be redeemed only by a specific payee or at a specific payee payment account
(or by one of a set of specific payees or at a payee payment account selected from among a
set of specific payee payment accounts) – and in which case, extraction of the payee account
information from electronic token 306 would enable the transacting entities to ensure that
the electronic payment token 306 is being redeemed by or at an authorized payee or
20 authorized payee payment account. The extraction of data at step 1004 may be implemented
at payee terminal 308, and in certain embodiments may be implemented through token
reader 3084 within payee terminal 308.
[00136] At step 1006, responsive to determining that network connectivity with an
25 acquirer server 312 or with another network entity that is involved in the payment
transaction, is unavailable, a payee payment account state image is retrieved from a local
memory of payee terminal 308. In embodiments of the method where the local memory of
payee terminal 308 stores a plurality of payee payment account state images associated with
the payee payment account, the payee payment account state image that is retrieved at step
30 1006 may comprise the payee payment account state image that represents the most current
or most recently recorded data state of the payee payment account. The payee payment
34

account state image that represents the current or most recently recorded data state of the
payee payment account may in certain embodiments be identified based on time stamp
information within or associated with each payee payment account state image. The
retrieved payee payment account state image may in an embodiment comprise a payee
5 payment account state image that has been generated and stored by payee terminal 308 in
accordance with the method of Figure 5.
[00137] At step 1008, a first account balance is extracted from the retrieved payee
payment account stage image – where the first account balance represents the available
10 account balance associated with the payee payment account that is recorded within the
retrieved payee payment account state image.
[00138] Step 1010 comprises generating and storing in a local memory associated with
the payee terminal 308, an updated payee payment account state image associated with the
15 payee payment account – wherein the updated payee payment account state image
comprises a second account balance that is determined by adding the payment transaction amount to the first account balance. Step 1010 may, in an embodiment, be implemented at payee terminal 308.
20 [00139] Step 1012 comprises optionally updating a transaction metadata record that is
associated with the payee account. The transaction metadata record comprises a data record of electronic payment transactions associated with the payee payment account – and may include any one or more of, a description of each transaction, payor payment account information, payee payment account information, payment transaction amount, transaction
25 type (e.g. credit transaction or debit transaction), a time stamp associated with such
transaction, and / or any other relevant information, each associated with such transaction. The transaction metadata record may comprise a record of all transactions associated with the payee payment account. In another embodiment, the transaction metadata record may comprise a record of all transactions associated with the payee payment account that has
30 been implemented through payee terminal 308.
35

[00140] Thereafter, at step 1014, responsive to resumption of network connectivity with
acquirer server 312 or with such other network entity involved in the payment transaction
with whom network connectivity was previously unavailable, payee terminal 308 initiates
updating of an account state of the payee payment account at acquirer server 312. The
5 update of the account state of the payee payment account at acquirer server 312 may be
based on one or both of the updated payee payment account state image generated at step 1010 and the updated transaction metadata record generated at step 1012. It would be understood that for the purposes of the update at step 1014, a request for updating an account state of the payee payment account at acquirer server 312, along with one or both
10 of the updated payee payment account state image and the updated transaction metadata
record, is transmitted from payee terminal 308 to acquirer server 312 – based on a network connection between the two entities. Acquirer server 312 may thereafter update an account state of the payee payment account based on the received request, updated payee payment account state image and / or updated transaction metadata record. The update to the
15 account state of the payee payment account may reflect the payment transaction, the credit
of funds to the account balance previously associated with the payee payment account, the corresponding debit of funds from a payor payment account and / or the new incremented account balance associated with the payee payment account.
20 [00141] Figure 11 is a communication flow diagram illustrating communication flow
between system entities for implementing the method of Figure 10.
[00142] Step 11002 comprises receiving at payee terminal 1102 (which payee terminal
1102 is associated with a payee payment account), an electronic token 306 that has been
25 generated by a payor terminal – and which electronic token may have been generated by the
payor terminal in accordance with step 810 of Figure 8.
[00143] Payee terminal 1102 extracts from received electronic token 306, payor payment
account information and a payment transaction amount that has been encoded, encrypted
30 or otherwise stored within electronic token 306, and optionally may also extract payee
account information that is included within electronic token 306.
36

[00144] Payee terminal 1102 thereafter determines availability of network connectivity
with an acquirer server 1104 or with another network entity that is involved in the payment
transaction. At step 11004, responsive to determining that network connectivity with an
5 acquirer server 1104 or with another network entity that is involved in the payment
transaction, is unavailable, a current or most recently updated payee payment account state image is retrieved from a local memory of payee terminal 1102.
[00145] Payee terminal 1102 extracts a first account balance from the retrieved payee
10 payment account stage image – wherein the first account balance represents the available
account balance associated with the payee payment account that is recorded within the retrieved payee payment account state image.
[00146] Payee terminal 1102 thereafter generates an updated payee payment account
15 state image associated with the payee payment account – wherein the updated payee
payment account state image comprises a second account balance that is determined by
adding the payment transaction amount to the first account balance. Payee terminal 1102
may also optionally update a transaction metadata record that is associated with the payee
account – wherein the transaction metadata record comprises a data record of electronic
20 payment transactions associated with the payee payment account – and may include any one
or more of, a description of each transaction, payor payment account information, payee
payment account information, payment transaction amount, transaction type (e.g. credit
transaction or debit transaction), a time stamp associated with such transaction, and / or
any other relevant information, each associated with such transaction.
25
[00147] At step 11006, the updated payee payment account state image and / or updated transaction metadata record may be stored in a local memory associated with payee terminal 1102.
30 [00148] At step 11008, responsive to resumption of network connectivity with acquirer
server 1104 or with such other network entity involved in the payment transaction with
37

whom network connectivity was previously unavailable, payee terminal 1102 transmits one or both of the updated payee payment account state image and the updated transaction metadata record to acquirer server 1104.
5 [00149] At step 11010, acquirer server 1104 updates an account state of the payee
payment account at acquirer server 1104, based on one or both of the updated payee payment account state image transmitted at step 11008 and optionally the updated transaction metadata record transmitted at step 11008. It would be understood that for the purposes of the update at step 11010, a request for updating an account state of the payee
10 payment account at acquirer server 1104, along with one or both of the updated payee
payment account state image and the updated transaction metadata record, may be transmitted from payee terminal 1102 to acquirer server 1104– based on a network connection between the two entities. The effected update to the account state of the payee payment account may reflect the payment transaction, the credit of funds to the previous
15 account balance of the payee payment account, the corresponding debit of funds to a payor
payment account and / or the new incremented account balance associated with the payee payment account.
[00150] It would be understood that by implementing one or more of the system configurations of Figures 3 and 4, and / or the methods discussed above in connection with Figures 5, 6, and 8 to 11, the present invention enables electronic payment transactions to be completed even in the absence of network access, while simultaneously eliminating the risk of subsequent transaction rejection (and of payment fraud) for insufficiency of funds in a payor payment account.
[00151] Figure 12 illustrates an exemplary system 1200 for implementing the present invention.
[00152] System 1200 includes computer system 1202 which in turn comprises one or
30 more processors 1204 and at least one memory 1206. Processor 1204 is configured to
execute program instructions - and may be a real processor or a virtual processor. It will be
38

understood that computer system 1202 does not suggest any limitation as to scope of use or
functionality of described embodiments. The computer system 1202 may include, but is not
be limited to, one or more of a general-purpose computer, a programmed microprocessor, a
micro-controller, an integrated circuit, and other devices or arrangements of devices that are
5 capable of implementing the steps that constitute the method of the present invention.
Exemplary embodiments of a computer system 1202 in accordance with the present invention may include one or more servers, desktops, laptops, tablets, smart phones, mobile phones, mobile communication devices, phablets and personal digital assistants. In an embodiment of the present invention, the memory 1206 may store software for
10 implementing various embodiments of the present invention. The computer system 1202
may have additional components. For example, the computer system 1202 may include one or more communication channels 1208, one or more input devices 1210, one or more output devices 1212, and storage 1214. An interconnection mechanism (not shown) such as a bus, controller, or network, interconnects the components of the computer system 1202. In
15 various embodiments of the present invention, operating system software (not shown)
provides an operating environment for various software(s) executing in the computer system 1202 using a processor 1204, and manages different functionalities of the components of the computer system 1202.
[00153] The communication channel(s) 1208 allow communication over a
communication medium to various other computing entities. The communication medium provides information such as program instructions, or other data in a communication media. The communication media includes, but is not limited to, wired or wireless methodologies implemented with an electrical, optical, RF, infrared, acoustic, microwave, Bluetooth or other transmission media.
[00154] The input device(s) 1210 may include, but is not limited to, a touch screen,
a keyboard, mouse, pen, joystick, trackball, a voice device, a scanning device, or any another
device that is capable of providing input to the computer system 1202. In an embodiment of
30 the present invention, the input device(s) 1210 may be a sound card or similar device that
accepts audio input in analog or digital form. The output device(s) 1212 may include, but not
39

be limited to, a user interface on CRT, LCD, LED display, or any other display associated with any of servers, desktops, laptops, tablets, smart phones, mobile phones, mobile communication devices, phablets and personal digital assistants, printer, speaker, CD/DVD writer, or any other device that provides output from the computer system 1202. 5
[00155] The storage 1214 may include, but not be limited to, magnetic disks,
magnetic tapes, CD-ROMs, CD-RWs, DVDs, any types of computer memory, magnetic stripes,
smart cards, printed barcodes or any other transitory or non-transitory medium which can
be used to store information and can be accessed by the computer system 1202. In various
10 embodiments of the present invention, the storage 1214 may contain program instructions
for implementing any of the described embodiments.
[00156] In an embodiment of the present invention, the computer system 1202 is
part of a distributed network or a part of a set of available cloud resources.
15
[00157] The present invention may be implemented in numerous ways including as
a system, a method, or a computer program product such as a computer readable storage medium or a computer network wherein programming instructions are communicated from a remote location.
20
[00158] The present invention may suitably be embodied as a computer program
product for use with the computer system 1202. The method described herein is typically implemented as a computer program product, comprising a set of program instructions that is executed by the computer system 1202 or any other similar device. The set of program
25 instructions may be a series of computer readable codes stored on a tangible medium, such
as a computer readable storage medium (storage 1214), for example, diskette, CD-ROM, ROM, flash drives or hard disk, or transmittable to the computer system 1202, via a modem or other interface device, over either a tangible medium, including but not limited to optical or analogue communications channel(s) 1208. The implementation of the invention as a
30 computer program product may be in an intangible form using wireless techniques,
including but not limited to microwave, infrared, Bluetooth or other transmission
40

techniques. These instructions can be preloaded into a system or recorded on a storage medium such as a CD-ROM, or made available for downloading over a network such as the Internet or a mobile telephone network. The series of computer readable instructions may embody all or part of the functionality previously described herein.
[00159] Based on the above, it would be apparent that the present invention offers significant advantages - including enabling electronic token based payment transactions that are secure and which enable completion of transactions even in the absence of network access, while simultaneously ensure that a payment transaction is not implemented unless the payor payment account has sufficient available funds to implement the transaction.
[00160] While the exemplary embodiments of the present invention are described and illustrated herein, it will be appreciated that they are merely illustrative. It will be understood by those skilled in the art that various modifications in form and detail may be made therein without departing from or offending the spirit and scope of the invention as defined by the appended claims. Additionally, the invention illustratively disclose herein suitably may be practiced in the absence of any element which is not specifically disclosed herein - and in a particular embodiment that is specifically contemplated, the invention is intended to be practiced in the absence of any one or more element which are not specifically disclosed herein.

We Claim:

A method for implementing an electronic payment transaction, comprising
the steps of:
receiving at a payor terminal, a payment instruction for initiating an electronic payment transaction for transferring a payment transaction amount from a payor payment account to a payee payment account;
responsive to a determination of unavailability of network connectivity between the payor terminal and at least a first network entity required for the electronic payment transaction, retrieving from a memory coupled with the payor terminal, a first payor payment account state image, wherein the first payor payment account state image includes at least an available account balance associated with the payor payment account;
extracting a first account balance from the retrieved first payor payment account state image, wherein the first account balance is the available account balance associated with the payor payment account that is included within the retrieved first payor payment account state image;
responsive to a determination that the first account balance is sufficient for transferring the payment transaction amount to the payee payment account, generating an electronic payment token at the payor terminal, wherein the electronic payment token encodes the payment transaction amount and payor account information;
generating and storing in the memory coupled with the payor terminal, a second payor payment account state image associated with the payor payment account, wherein the second payor payment account state image comprises a second account balance that is determined by debiting the payment transaction amount from the first account balance;
providing the generated electronic token to a payee terminal; and

responsive to resumption of network connectivity with the first network entity required for the electronic payment transaction, initiating updating of an account state of the payor payment account at an issuer server associated with the payor payment account, wherein updating the account state of the payor payment account is based on data extracted from the second payor payment account state image.
2. The method as claimed in claim 1, wherein:
updating the account state of the payor payment account is also based on a transaction metadata record associated with the payor payment account and transmitted to the issuer server; and
the transaction metadata record associated with the payor payment account comprises a data record of electronic payment transactions associated with the payor payment account.
3. The method as claimed in claim 2, wherein the transaction metadata record associated with the payor payment account has been updated at the payor terminal to record at least, debiting the payment transaction amount from the first account balance, and the payee account information.
4. The method as claimed in claim 1, wherein updating of the account state of the payor payment account at the issuer server comprises recording the second account balance as the account balance associated with the payor payment account.
5. The method as claimed in claim 1, wherein updating the account state of the payor payment account at the issuer server includes initiation of transfer of the payment transaction amount from the payor payment account to the payee payment account, by the issuer server.

6. The method as claimed in claim 1, wherein the first network entity required for the electronic payment transaction is the issuer server.
7. The method as claimed in claim 1, wherein the payee terminal:
extracts from the electronic token, the encoded payment transaction amount and payor account information;
responsive to a determination of unavailability of network connectivity between the payee terminal and at least a second network entity required for the electronic payment transaction, retrieves from a memory coupled with the payee terminal, a first payee payment account state image, wherein the first payee payment account state image includes at least an available account balance associated with the payee payment account;
extracts a third account balance from the retrieved first payee payment account state image, wherein the third account balance is the available account balance associated with the payee payment account that is included within the retrieved first payee payment account state image;
generates and stores in the memory coupled with the payor terminal, a second payee payment account state image associated with the payee payment account, wherein the second payee payment account state image comprises a fourth account balance that is determined by adding the payment transaction amount to the third account balance; and
responsive to resumption of network connectivity with the second network entity required for the electronic payment transaction, initiates updating of an account state of the payee payment account at an acquirer server associated with the payee payment account, wherein updating the account state of the payee payment account is based on data extracted from the second payee payment account state image.
The method as claimed in claim 7, wherein:

updating the account state of the payee payment account is also based on a transaction metadata record associated with the payee payment account and transmitted to the acquirer server; and
the transaction metadata record associated with the payee payment account comprises a data record of electronic payment transactions associated with the payee payment account.
9. The method as claimed in claim 8, wherein the transaction metadata record associated with the payee payment account has been updated at the payee terminal to record at least, adding the payment transaction amount to the third account balance, and the payor account information.
10. The method as claimed in claim 7, wherein updating of the account state of the payee payment account at the acquirer server comprises recording the fourth account balance as the account balance associated with the payee payment account.
11. The method as claimed in claim 7, wherein the second network entity required for the electronic payment transaction is the acquirer server.
12. A system for implementing an electronic payment transaction, comprising a processor implemented payor terminal configured to implement the steps of:
receiving a payment instruction for initiating an electronic payment transaction for transferring a payment transaction amount from a payor payment account to a payee payment account;
responsive to a determination of unavailability of network connectivity between the payor terminal and at least a first network entity required for the electronic payment transaction, retrieving from a memory coupled with the payor terminal, a first payor payment account

state image, wherein the first payor payment account state image includes at least an available account balance associated with the payor payment account;
extracting a first account balance from the retrieved first payor payment account state image, wherein the first account balance is the available account balance associated with the payor payment account that is included within the retrieved first payor payment account state image;
responsive to a determination that the first account balance is sufficient for transferring the payment transaction amount to the payee payment account, generating an electronic payment token at the payor terminal, wherein the electronic payment token encodes the payment transaction amount and payor account information;
generating and storing in the memory coupled with the payor terminal, a second payor payment account state image associated with the payor payment account, wherein the second payor payment account state image comprises a second account balance that is determined by debiting the payment transaction amount from the first account balance;
providing the generated electronic token to a payee terminal; and
responsive to resumption of network connectivity with the first network entity required for the electronic payment transaction, initiating updating of an account state of the payor payment account at an issuer server associated with the payor payment account, wherein updating the account state of the payor payment account is based on data extracted from the second payor payment account state image.
13. The system as claimed in claim 12, wherein:
updating the account state of the payor payment account is also based on a transaction metadata record associated with the payor payment account and transmitted to the issuer server; and

the transaction metadata record associated with the payor payment account comprises a data record of electronic payment transactions associated with the payor payment account.
14. The system as claimed in claim 11, wherein the transaction metadata record associated with the payor payment account has been updated at the payor terminal to record at least, debiting the payment transaction amount from the first account balance, and the payee account information.
15. The system as claimed in claim 12, wherein updating of the account state of the payor payment account at the issuer server comprises recording the second account balance as the account balance associated with the payor payment account.
16. The system as claimed in claim 12, wherein updating the account state of the payor payment account at the issuer server includes initiation of transfer of the payment transaction amount from the payor payment account to the payee payment account, by the issuer server.
17. The system as claimed in claim 12, wherein the first network entity required for the electronic payment transaction is the issuer server.
18. The system as claimed in claim 12, wherein the payee terminal is configured to:
extract from the electronic token, the encoded payment transaction amount and payor account information;
responsive to a determination of unavailability of network connectivity between the payee terminal and at least a second network entity required for the electronic payment transaction, retrieve from a memory coupled with the payee terminal, a first payee payment

account state image, wherein the first payee payment account state image includes at least an available account balance associated with the payee payment account;
extract a third account balance from the retrieved first payee payment account state image, wherein the third account balance is the available account balance associated with the payee payment account that is included within the retrieved first payee payment account state image;
generate and store in the memory coupled with the payor terminal, a second payee payment account state image associated with the payee payment account, wherein the second payee payment account state image comprises a fourth account balance that is determined by adding the payment transaction amount to the third account balance; and
responsive to resumption of network connectivity with the second network entity required for the electronic payment transaction, initiate updating of an account state of the payee payment account at an acquirer server associated with the payee payment account, wherein updating the account state of the payee payment account is based on data extracted from the second payee payment account state image.
19. The system as claimed in claim 18, wherein:
updating the account state of the payee payment account is also based on a transaction metadata record associated with the payee payment account and transmitted to the acquirer server; and
the transaction metadata record associated with the payee payment account comprises a data record of electronic payment transactions associated with the payee payment account.
20. The system as claimed in claim 19, wherein the transaction metadata record
associated with the payee payment account has been updated at the payee terminal to record

at least, adding the payment transaction amount to the third account balance, and the payor account information.
21. The system as claimed in claim 18, wherein updating of the account state of the payee payment account at the acquirer server comprises recording the fourth account balance as the account balance associated with the payee payment account.
22. The system as claimed in claim 18, wherein the second network entity required for the electronic payment transaction is the acquirer server.
23. A computer program product for implementing an electronic token based payment transaction, comprising a non-transitory computer usable medium having a computer readable program code embodied therein, the computer readable program code comprising instructions for:
receiving at a payor terminal, a payment instruction for initiating an electronic payment transaction for transferring a payment transaction amount from a payor payment account to a payee payment account;
responsive to a determination of unavailability of network connectivity between the payor terminal and at least a first network entity required for the electronic payment transaction, retrieving from a memory coupled with the payor terminal, a first payor payment account state image, wherein the first payor payment account state image includes at least an available account balance associated with the payor payment account;
extracting a first account balance from the retrieved first payor payment account state image, wherein the first account balance is the available account balance associated with the payor payment account that is included within the retrieved first payor payment account state image;

responsive to a determination that the first account balance is sufficient for transferring the payment transaction amount to the payee payment account, generating an electronic payment token at the payor terminal, wherein the electronic payment token encodes the payment transaction amount and payor account information;
generating and storing in the memory coupled with the payor terminal, a second payor payment account state image associated with the payor payment account, wherein the second payor payment account state image comprises a second account balance that is determined by debiting the payment transaction amount from the first account balance;
providing the generated electronic token to a payee terminal; and
responsive to resumption of network connectivity with the first network entity required for the electronic payment transaction, initiating updating of an account state of the payor payment account at an issuer server associated with the payor payment account, wherein updating the account state of the payor payment account is based on data extracted from the second payor payment account state image.