Claims:WE CLAIM:
1. A method for authorizing transactions, the method comprising:
receiving, by an application server from a user device of a user, a first device identifier of the user device and a beacon identifier of a beacon associated with a terminal device, in response to the user device being within a communication range of the beacon;
receiving, by the application server, a status request for enquiring the device status of the user device from an issuer of a transaction card that is linked to the user device, wherein the status request is communicated by the issuer based on a transaction initiated at the terminal device by way of the transaction card; and
communicating, by the application server, a response indicating the device status of the user device to the issuer based on the received status request, wherein the transaction is authorized by the issuer based on the response indicating the device status.
2. The method of claim 1, wherein the terminal device is one of an automated teller machine, a bunch note acceptor, a currency recycler, a point-of-purchase device, a point-of-interaction device, and a point-of-sale device.
3. The method of claim 1, further comprising:
receiving, by the application server from a merchant device of a merchant that is associated with the terminal device, the beacon identifier of the beacon, a second device identifier of the terminal device, and a merchant identifier of the merchant; and
storing, by the application server, the beacon identifier, the second device identifier, and the merchant identifier in a memory associated with the application server, for registering the beacon with the application server.
4. The method of claim 3, wherein upon the registration of the beacon, a beacon signal including the beacon identifier is periodically broadcasted by the beacon within the communication range.
5. The method of claim 4, wherein receiving the first device identifier and the beacon identifier is based on an activation of a service application installed on the user device, and wherein the service application is activated when the user device is within the communication range of the beacon and receives the broadcasted beacon signal.
6. The method of claim 1, wherein the status request includes the first device identifier of the user device and at least one of a second device identifier of the terminal device and a merchant identifier of a merchant associated with the terminal device.
7. The method of claim 1, further comprising:
storing, by the application server in a memory associated with the application server, the determined device status of the user device; and
accessing, by the application server upon the reception of the status request, the memory for retrieving the stored device status of the user device.
8. The method of claim 1, further comprising:
receiving, by the application server from the user device, an exit notification in response to the user device exiting the communication range of the beacon;
updating, by the application server based on the exit notification, the device status of the user device to indicate an absence of the user device in the communication range of the beacon; and
storing, by the application server in a memory associated with the application server, the updated device status of the user device.
9. The method of claim 1, wherein the beacon is located in an immediate vicinity of the terminal device.
10. A system for authorizing transactions, the system comprising:
an application server configured to:
receive, from a user device of a user, a first device identifier of the user device and a beacon identifier of a beacon associated with a terminal device, in response to the user device being within a communication range of the beacon;
determine a device status of the user device based on the received first device identifier and the received beacon identifier, wherein the device status indicates that the user device is present within the communication range of the beacon;
receive a status request for enquiring the device status of the user device from an issuer of a transaction card that is linked to the user device, wherein the issuer communicates the status request based on a transaction initiated at the terminal device by way of the transaction card; and
communicate a response indicating the device status of the user device to the issuer based on the received status request, wherein the issuer authorizes the transaction based on the response indicating the device status.
11. The system of claim 10, wherein the terminal device is one of an automated teller machine, a bunch note acceptor, a currency recycler, a point-of-purchase device, a point-of-interaction device, and a point-of-sale device.
12. The system of claim 10, further comprising a memory associated with the application server, wherein the application server is further configured to:
receive, from a merchant device of a merchant that is associated with the terminal device, the beacon identifier of the beacon, a second device identifier of the terminal device, and a merchant identifier of the merchant; and
store the beacon identifier, the second device identifier, and the merchant identifier in the memory, for registering the beacon with the application server.
13. The system of claim 12, wherein the beacon is located in an immediate vicinity of the terminal device, and wherein upon the registration of the beacon, the beacon periodically broadcasts a beacon signal including the beacon identifier within the communication range.
14. The system of claim 13, wherein the application server receives the first device identifier and the beacon identifier based on an activation of a service application installed on the user device, and wherein the service application is activated when the user device is within the communication range of the beacon and receives the broadcasted beacon signal.
15. The system of claim 10, wherein the status request includes the first device identifier of the user device and at least one of a second device identifier of the terminal device and a merchant identifier of a merchant associated with the terminal device.
16. The system of claim 10, further comprising a memory associated with the application server, wherein the application server is further configured to:
store, in the memory, the determined device status of the user device; and
access, upon the reception of the status request, the memory for retrieving the stored device status of the user device.
17. The system of claim 10, further comprising a memory associated with the application server, wherein the application server is further configured to:
receive, from the user device, an exit notification in response to the user device exiting the communication range of the beacon;
update, based on the exit notification, the device status of the user device to indicate an absence of the user device in the communication range of the beacon; and
store, in the memory, the updated device status of the user device.
18. A method for authorizing transactions, the method comprising:
receiving, by an issuer server, an authorization request for a transaction initiated at a terminal device by way of a transaction card of a user;
communicating, by the issuer server based on the received authorization request, a status request to an application server for enquiring a device status of a user device linked to the transaction card, wherein the device status indicates a presence or an absence of the user device within a communication range of a beacon associated with the terminal device;
receiving, by the issuer server from the application server in response to the communicated status request, a response indicating the device status of the user device; and
authorizing, by the issuer server, the transaction when the device status in the received response indicates that the user device is present within the communication range of the beacon.
19. The method of claim 18, wherein the status request includes a first device identifier of the user device and at least one of a second device identifier of the terminal device and a merchant identifier of a merchant associated with the terminal device, and wherein the authorization request includes one or more details of the transaction card and at least one of the second device identifier and the merchant identifier.
20. The method of claim 18, wherein the transaction is authorized by the issuer server without requiring an authentication parameter from the user
, Description:METHOD AND SYSTEM FOR AUTHORIZING TRANSACTIONS

BACKGROUND

FIELD OF THE DISCLOSURE

Various embodiments of the disclosure relate generally to processing electronic transactions. More specifically, various embodiments of the disclosure relate to a method and a system for authorizing electronic transactions.

DESCRIPTION OF THE RELATED ART

Emergence of transaction cards has revolutionized the way transactions are performed at terminal devices, such as automated teller machines (ATMs), point-of-sale (POS) devices, or the like. A transaction performed at a terminal device using a transaction card involves authentication of a user for authorizing the transaction. For authentication, the user typically provides an authentication parameter associated with the transaction card at the terminal device. The authentication parameter may be a personal identification number (PIN), biometric information, a one-time password (OTP), or the like. An issuer of the transaction card is responsible for authenticating the user and authorizing the transaction. To authenticate the user, the issuer compares the authentication parameter provided by the user with a registered authentication parameter, and authorizes the transaction based on the authentication of the user.
While the use of the authentication parameter assists in assuring that the user is a valid card holder, the entire process is wearisome. For example, the user is required to remember the PIN linked to the transaction card. The user may usually have multiple transaction cards, each of which requires the user to remember a password or a PIN. In the event that the user does not remember the PIN, the user is unable to complete the transaction. The use of PINs thus is inconvenient for the user. In case of OTPs, the user is required to read an OTP sent to a user device of the user and then manually enter the received OTP into the terminal device for authentication. Similarly, the user is required to provide the biometric information to the terminal device or a biometric device associated with the terminal device. This adds to the inconvenience experienced by the user. Further, if an input means of the terminal device or the biometric device is non-operational or faulty, the user is unable to complete the transaction. This inadvertently results in delays during the authorization process, causing inconvenience to the user. Thus, the use of authentication parameter for authenticating the user and authorizing the transaction is inefficient and vitiates a transaction experience of the user.
In light of the foregoing, there exists a need for a solution that solves the abovementioned problems and provides a mechanism to perform seamless transactions.

SUMMARY

In an embodiment of the disclosure, a method for authorizing transactions is provided. A first device identifier of a user device of a user and a beacon identifier of a beacon associated with a terminal device, are received by an application server from the user device. The first device identifier and the beacon identifier are received by the application server in response to the user device being within a communication range of the beacon. Based on the received first device identifier and the received beacon identifier, a device status of the user device is determined by the application server. The device status indicates that the user device is present within the communication range of the beacon. Further, a status request for enquiring the device status of the user device is received by the application server from an issuer of a transaction card that is linked to the user device. The status request is communicated by the issuer based on a transaction initiated at the terminal device by way of the transaction card. Based on the received status request, a response indicating the device status of the user device is communicated by the application server to the issuer. The transaction is authorized by the issuer based on the response indicating the device status.
In another embodiment of the disclosure, a system for authorizing transactions is provided. The system includes an application server that is configured to receive, from a user device of a user, a first device identifier of the user device and a beacon identifier of a beacon associated with a terminal device, in response to the user device being within a communication range of the beacon. The application server is further configured to determine a device status of the user device based on the received first device identifier and the received beacon identifier. The device status indicates that the user device is present within the communication range of the beacon. The application server is further configured to receive a status request for enquiring the device status of the user device from an issuer of a transaction card that is linked to the user device. The issuer communicates the status request based on a transaction initiated at the terminal device by way of the transaction card. The application server is further configured to communicate a response indicating the device status of the user device to the issuer based on the received status request. The issuer authorizes the transaction based on the response indicating the device status.
In another embodiment of the disclosure, a method for authorizing transactions is provided. An authorization request for a transaction initiated at a terminal device by way of a transaction card of a user is received by an issuer server. Based on the received authorization request, a status request is communicated by the issuer server to an application server for enquiring a device status of a user device linked to the transaction card. The device status indicates a presence or an absence of the user device within a communication range of a beacon associated with the terminal device. In response to the communicated status request, a response indicating the device status of the user device is received by the issuer server. The transaction is authorized by the issuer server when the device status in the received response indicates that the user device is present within the communication range of the beacon.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings illustrate the various embodiments of systems, methods, and other aspects of the disclosure. It will be apparent to a person skilled in the art that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element shown as an internal component of one element may be implemented as an external component in another, and vice versa.
Various embodiments of the disclosure are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements:
FIG. 1 is a block diagram that illustrates an exemplary environment for authorizing transactions, in accordance with an exemplary embodiment of the disclosure;
FIG. 2 is a process flow diagram that illustrates an exemplary scenario for registering a beacon with an application server for a proximity-based authorization program, in accordance with an exemplary embodiment of the disclosure;
FIGS. 3A-3D, collectively represent a process flow diagram that illustrates an exemplary scenario for authorizing a transaction initiated by a user at a terminal device, in accordance with an exemplary embodiment of the disclosure;
FIG. 4 is an exemplary scenario that illustrates a merchant store including the beacon that is registered for the proximity-based authorization program, in accordance with an exemplary embodiment of the disclosure;
FIG. 5 is a block diagram that illustrates an issuer server, in accordance with an exemplary embodiment of the disclosure;
FIG. 6 is a block diagram that illustrates the application server, in accordance with an exemplary embodiment of the disclosure;
FIG. 7 is a block diagram that illustrates system architecture of a computer system, in accordance with an exemplary embodiment of the disclosure;
FIG. 8 represents a flow chart that illustrates a method for registering the beacon with the application server for the proximity-based authorization program, in accordance with an exemplary embodiment of the disclosure;
FIG. 9 represents a flow chart that illustrates a method for facilitating authorization of the transaction initiated at the terminal device by using a transaction card, in accordance with an exemplary embodiment of the disclosure;
FIG. 10 represents a flow chart that illustrates a method for authorizing the transaction initiated at the terminal device by using the transaction card, in accordance with an exemplary embodiment of the disclosure;
FIG. 11 represents a high-level flow chart that illustrates a method for authorizing the transactions, in accordance with an exemplary embodiment of the disclosure; and
FIG. 12 represents a high-level flow chart that illustrates a method for authorizing the transactions, in accordance with an exemplary embodiment of the disclosure.
Further areas of applicability of the disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments is intended for illustration purposes only and is, therefore, not intended to necessarily limit the scope of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

The disclosure is best understood with reference to the detailed figures and description set forth herein. Various embodiments are discussed below with reference to the figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to the figures are simply for explanatory purposes as the methods and systems may extend beyond the described embodiments. In one example, the teachings presented and the needs of a particular application may yield multiple alternate and suitable approaches to implement the functionality of any detail described herein. Therefore, any approach may extend beyond the particular implementation choices in the following embodiments that are described and shown.
References to “an embodiment”, “another embodiment”, “yet another embodiment”, “one example”, “another example”, “yet another example”, “for example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in an embodiment” does not necessarily refer to the same embodiment.
OVERVIEW
Typically, when a user performs a transaction at a terminal device, the user is required to provide an authentication parameter (such as a personal identification number (PIN), biometric information, a one-time password (OTP), or the like) at the terminal device, and the transaction is authorized based on the authentication parameter. The use of the authentication parameter to authorize the transaction makes the authorization process wearisome, and vitiates a transaction experience of the user.
Various embodiments of the disclosure provide a method and a system to solve the abovementioned problems by authorizing transactions initiated by users without requiring any authentication parameter from the users. An application server offers a proximity-based authorization program. Various merchants register corresponding beacons with the application server for the proximity-based authorization program. Upon the registration, each beacon is automatically activated and periodically broadcasts a beacon signal within a communication range of the corresponding beacon.
A user may visit a merchant store that has a registered beacon installed therein. When the user, carrying a user device, enters the communication range of the beacon, the user device receives the beacon signal broadcasted by the beacon. The beacon signal includes a unique beacon identifier (ID) of the beacon. The user device has a service application installed thereon that is hosted by the application server. When the user device receives the beacon signal, the service application is activated. Upon the activation of the service application, the user device communicates the beacon ID and a first device ID of the user device to the application server. The application server determines a device status of the user device based on the beacon ID and the first device ID received from the user device. The device status indicates that the user device is present within the communication range of the beacon. The application server stores the device status, in a memory of the application server, in association with the registered beacon.
The user may then select a product for purchase and utilize a transaction card to make a payment for the purchase. For initiating a transaction for the purchase, the transaction card is used at a terminal device that is linked to the registered beacon. When the transaction is initiated at the terminal device, an issuer server associated with the transaction card receives an authorization request for the transaction. The authorization request includes card details of the transaction card and a second device ID of the terminal device. The authorization request may additionally include a merchant ID of a merchant associated with the merchant store. The issuer server identifies the first device ID of the user device that is linked to the transaction card based on the card details. The issuer server communicates a status request, including the first and second device IDs and may additionally include the merchant ID, to the application server for enquiring the device status of the user device. Based on the status request, the application server accesses the memory to retrieve the device status of the user device. The retrieved device status may indicate an absence or a presence of the user device within the communication range of the beacon. The application server communicates the retrieved device status to the issuer as a response to the status request. The issuer server authorizes the transaction when the device status indicates that the user device is present within the communication range of the beacon.
When the user exits the communication range of the beacon, the user device communicates an exit notification to the application server. Based on the exit notification, the application server updates the device status of the user device to indicate an absence of the user device in the communication range of the beacon, and stores the updated device status in the memory. Since the application server facilitates authorization of transactions without requiring any authentication parameter from the user, the authorization process of the disclosure is more seamless and hassle-free as compared to the conventional authorization processes.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
Transaction is an exchange of funds between two or more parties. For example, the transaction may include transferring a transaction amount from a user account to a merchant account, when the user makes a purchase from the merchant. In another example, the transaction may include dispensing cash, at an automated teller machine (ATM), equivalent to a transaction amount debited from a financial account of the user.
Terminal device is a computing device affiliated with a financial institution (such as an acquirer) or a merchant. The terminal device enables users to perform various electronic transactions, such as cash withdrawals, cash deposits, purchase payments, funds transfer, or the like. Examples of the terminal device may include a point-of-sale (POS) device, a point-of-purchase (POP) device, a point-of-interaction (POI) device, an ATM, a bunch note acceptor (BNA), a currency recycler, or the like. The terminal device has a device identifier associated therewith, and is linked to a beacon by way of the device identifier.
Application server is a computing server that facilitates a proximity-based authorization program for seamless authorization of transactions. The transactions are authorized based on distances between user devices, that are linked to transaction cards utilized for performing such transactions, and beacons that are linked to terminal devices where the transactions are initiated. The application server may be implemented in hardware or software, or a combination thereof. In one embodiment, the application server may be implemented in computer programs executing on programmable computers, such as personal computers, laptops, or a network of computer systems.
Beacon is a near field communication (NFC) device that broadcasts a beacon signal within a communication range thereof. The beacon signal includes a unique beacon ID of the beacon. The beacon may broadcast the beacon signal in a specific direction or in all directions depending upon a transmitter used in the beacon. Further, the communication range of the beacon varies based on the direction of the broadcast and strength of the beacon signal. The beacon may be installed in an immediate proximity of a terminal device. In one example, the beacon is a Bluetooth Low Energy (BLE) beacon.
Exit notification is a message that is communicated by a user device to an application server when the user device exits a communication range of a beacon registered with the application server. The exit notification indicates that the user device has stopped receiving a beacon signal from the beacon. Based on the exit notification, the application server updates a device status of the user device to indicate an absence of the user device in the communication range of the beacon.
Authentication parameter of a user is a unique identifier that is used to authenticate an identity of the user. Examples of the authentication parameters include a personal identification number (PIN), a one-time password (OTP), biometric information, or the like. Conventionally, when the user initiates a transaction, the user is required to provide the authentication parameter for authorization of the transaction.
FIG. 1 is a block diagram that illustrates an exemplary environment 100 for authorizing transactions, in accordance with an exemplary embodiment of the disclosure. The environment 100 includes a user 102, a user device 104 of the user 102, and a transaction card 106 of the user 102. The environment 100 further includes a merchant store 108, a store operative 110, a merchant device 112, a terminal device 114, and a beacon 116. The environment 100 further includes an acquirer server 118, a payment network server 120, an issuer server 122, and an application server 124. The user device 104, the merchant device 112, the terminal device 114, the acquirer server 118, the payment network server 120, the issuer server 122, and the application server 124 may communicate with each other by way of a communication network 126 or through separate communication networks established therebetween. Additionally, the user device 104 and the beacon 116 may communicate with each other by way of a communication link 128 established therebetween. In one embodiment, the communication link 128 is a short-range low-energy wireless link.
The user 102 is an individual who is an account holder of a financial account maintained at a financial institution, such as an issuer. The financial account is linked to the user device 104 of the user 102, as part of a registration procedure performed by the issuer. The user 102 may perform transactions from the financial account.
The user device 104 is a communication device of the user 102. Examples of the user device 104 may include, but are not limited to, a mobile phone, a smartphone, a laptop, a tablet, a phablet, or any other communication device. The user device 104 has a first device identifier (ID) associated therewith and is linked to the financial account by way of the first device ID. Examples of the first device ID may include a unique equipment number (such as International Mobile Equipment Identity (IMEI) number) of the user device 104, a contact number of the user 102, an electronic mail (e-mail) ID of the user 102, or the like. Additionally, the user device 104 has a service application installed thereon, which may be hosted by the application server 124, and acts as a gateway between the user device 104 and the application server 124. The service application is activated based on the communication between the user device 104 and the beacon 116 over the communication link 128. Upon the activation, the service application may serve as a medium to communicate various details (as described in the foregoing description of FIGS. 3A-3D) from the user device 104 to the application server 124.
The transaction card 106 is a physical payment mode linked to the financial account of the user 102, and stores information (hereinafter referred to as “account information”) of the financial account. The account information of the financial account may be stored in an electronic chip or a machine-readable magnetic strip embedded in the transaction card 106. The account information may include an account number, a name of an account holder, and the like. The transaction card 106 has a unique card number, an expiry date, a card security code, and a card type associated to it. The card number, the expiry date, the card security code, and the card type constitute card details of the transaction card 106. The transaction card 106 is issued to the user 102 by the issuer for enabling the user 102 to perform the transactions from the financial account maintained at the issuer. Further, since the user device 104 is linked to the financial account of the user 102 and the transaction card 106 is issued in association with the financial account, the transaction card 106 is further linked to the user device 104. Examples of the transaction card 106 include a credit card, a debit card, a charge card, a prepaid card, or the like.
The merchant store 108 is a brick and mortar store that sells various products or offers various services to users (e.g., the user 102). The user 102 may utilize the transaction card 106 at the merchant store 108 to perform the transactions for purchasing one or more products or availing one or more services. The merchant store 108 is managed by the store operative 110 and includes the merchant device 112, the terminal device 114, and the beacon 116 for facilitating the transactions performed at the merchant store 108. For the sake of brevity, the merchant store 108 is shown to be managed by a single store operative 110 and to include one merchant device 112, one terminal device 114, and one beacon 116. However, in various other embodiments, the merchant store 108 may be managed by multiple store operatives and may include multiple merchant devices, terminal devices, and beacons for facilitating the transactions performed at the merchant store 108, without deviating from the scope of the disclosure. In such a scenario, operations performed by each store operative are similar to the operations performed by the store operative 110.
The store operative 110 is an individual who manages the merchant store 108. For example, the store operative 110 may be an owner of the merchant store 108 or a sales representative at the merchant store 108. The store operative 110 facilitates purchases made by the users from the merchant store 108. Further, the store operative 110 registers the beacon 116 with the application server 124 for a proximity-based authorization program facilitated by the application server 124. For registering the beacon 116 with the application server 124, the merchant device 112 is utilized by the store operative 110 to communicate merchant details to the application server 124. The merchant details include a merchant ID of a merchant associated with the merchant store 108, a second device ID of the terminal device 114, and a beacon ID of the beacon 116. In an example, the merchant ID is a unique merchant code of the merchant, the second device ID is a unique equipment number of the terminal device 114, and the beacon ID is a unique equipment number of the beacon 116.
The merchant device 112 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for managing various operations associated with the merchant store 108. For example, the merchant device 112 maintains a log including details of the products available for sale at the merchant store 108, historical purchase data (i.e., details of products sold and services offered by the merchant store 108), or the like. Additionally, the merchant device 112 may facilitate the registration of the beacon 116 with the application server 124 by communicating the merchant details to the application server 124. Examples of the merchant device 112 may include a mobile phone, a smartphone, a laptop, a tablet, a phablet, a computer, or the like.
The terminal device 114 includes suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, to allow the users to perform purchase transactions at the merchant store 108. The terminal device 114 may be associated with a financial institution, such as an acquirer, or the merchant. When a transaction is initiated by the user 102 at the terminal device 114 by way of the transaction card 106, the terminal device 114 records the card details of the transaction card 106. The terminal device 114 may record other details such as a type of transaction (such as a purchase payment), a transaction amount, or the like. Further, the terminal device 114 provides transaction details of the transaction to the issuer for authorizing the transaction. The transaction details include the card details of the transaction card 106, the type of transaction, the transaction amount, and the second device ID of the terminal device 114. The transaction details may additionally include the merchant ID of the merchant. Examples of the terminal device 114 may include a point-of-purchase (POP) device, a point-of-interaction (POI) device, a point-of-sale (POS) device, or the like.
The beacon 116 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for broadcasting a beacon signal within a communication range (as shown in FIG. 4) of the beacon 116. The beacon signal includes the unique beacon ID of the beacon 116. The beacon 116 may broadcast the beacon signal in a specific direction or in all directions depending upon a transmitter (not shown) used in the beacon 116. Further, the communication range of the beacon 116 varies based on the direction of the broadcast and the strength of the beacon signal.
The beacon 116 may be installed in an immediate proximity of the terminal device 114. In other words, the beacon 116 is installed within a predetermined distance from the terminal device 114. For example, the beacon 116 may be installed at a distance that is less than or equal to 20 centimetres from the terminal device 114. For the sake of brevity, it is assumed that the beacon 116 is a Bluetooth Low Energy (BLE) beacon (i.e., the communication link 128 is a Bluetooth link). However, in various other embodiments, any type of low energy consuming device, i.e., a device capable of transmitting and/or receiving a signal wirelessly using a low power or low energy connection to a network, may be utilized, without deviating from the scope of the disclosure.
The acquirer server 118 is a computing server that is operated by the acquirer, and includes suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, for processing the transactions. The acquirer server 118 communicates with the terminal device 114 for receiving the transaction details of the transactions performed at the terminal device 114. The acquirer server 118 further communicates with the payment network server 120 for processing the transactions performed at the terminal device 114.
The payment network server 120 is a computing server that is operated by a payment network, and includes suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, for processing transactions that are performed using transaction cards (e.g., the transaction card 106). The payment network server 120 represents an intermediate entity between the acquirer server 118 and the issuer server 122 for processing the transactions.
The issuer server 122 is a computing server that is operated by the issuer, and includes suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, for authorizing the transactions performed by way of the transaction card 106 or any other payment mode issued by the issuer. The issuer is a financial institution that manages financial accounts of multiple users, such as the user 102. Account details of the financial accounts established with the issuer are stored as account profiles in a first memory (as shown in FIG. 5) of the issuer server 122, in an external database (not shown) associated with the issuer server 122, or on a cloud server (not shown) associated with the issuer server 122. The account details may include details of the account holders, account numbers of the financial accounts, account balances of the financial accounts, details of the issued transaction cards, device IDs of the linked user devices, or the like. The details of the account holders include name, age, gender, registered contact number, registered e-mail ID, or the like.
When the user 102 initiates the transaction at the terminal device 114 by way of the transaction card 106, the issuer server 122 receives the transaction details of the transaction. Based on the received transaction details, the issuer server 122 identifies the user device 104 linked to the transaction card 106 and the first device ID of the user device 104. The issuer server 122 communicates a status request, including the first and second device IDs, to the application server 124 for enquiring the device status of the user device 104. The status request may additionally include the merchant ID. The device status of the user device 104 is indicative of a presence or an absence of the user device 104 within the communication range of the beacon 116. The issuer server 122 may authorize the transaction based on a response received from the application server 124 indicating that the user device 104 is present within the communication range of the beacon 116.
The application server 124 is a computing server that includes suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, for facilitating the transactions performed by the users. The application server 124 facilitates the proximity-based authorization program. An objective of the proximity-based authorization program is to facilitate authorization of transactions performed at various terminal devices of merchants without requiring any authentication parameter from the users. Examples of the authentication parameters may include a personal identification number (PIN), a one-time password (OTP), biometric information, or the like. The transactions are authorized based on distances between user devices, that are linked to transaction cards utilized for performing such transactions, and beacons that are linked to terminal devices where the transactions are initiated. Various merchants and their corresponding beacons (e.g., the beacon 116) are registered with the application server 124 for the proximity-based authorization program.
When the store operative 110 initiates the registration of the beacon 116 for the proximity-based authorization program, the application server 124 receives the merchant ID of the merchant, the second device ID of the terminal device 114, and the beacon ID of the beacon 116. The application server 124 stores the merchant ID, the beacon ID, and the second device ID in a second memory (as shown in FIG. 6) of the application server 124 for registering the beacon 116 with the application server 124. Further, the application server 124 hosts the service application installed on the user device 104. In an embodiment, to access the service application, the user 102 may be required to enter a password, draw a pattern, or the like. Further, the user 102 may be required to access the service application at least once in a predetermined time interval for ensuring data security. The service application includes a library (not shown) that stores a list of beacons (i.e., beacon IDs) registered with the application server 124. When a new beacon is registered with the application server 124, the application server 124 updates the library to include the beacon ID of the newly registered beacon 116.
When the user device 104 is present within the communication range of the registered beacon 116, the application server 124 receives the beacon ID of the registered beacon 116 and the first device ID of the user device 104 from the user device 104. Based on the received beacon ID and the first device ID, the application server 124 determines the device status of the user device 104. The device status indicates that the user device 104 is present within the communication range of the beacon 116. The application server 124 stores the device status in the second memory.
When the user 102 initiates the transaction at the terminal device 114, the application server 124 receives the status request from the issuer server 122. Based on the received status request, the application server 124 accesses the second memory to retrieve the stored device status of the user device 104. The application server 124 communicates the retrieved device status to the issuer server 122. The transaction is authorized by the issuer server 122 when the retrieved device status indicates that the user device 104 is present within the communication range of the beacon 116.
When the user device 104 exits the communication range of the registered beacon 116, the application server 124 receives an exit notification from the user device 104. Based on the received exit notification, the application server 124 updates the device status of the user device 104 to indicate the absence of the user device 104 in the communication range of the beacon 116. The application server 124 stores the updated device status in the second memory.
In FIG. 1, the application server 124 is shown to be a standalone entity. However, in other embodiments, the application server 124 may be maintained at the merchant store 108, the issuer, the payment network (e.g., Mastercard®), or a third-party service provider. Thus, when the application server 124 is maintained at the merchant store 108, the functionalities of the application server 124 may be integrated into the merchant device 112. Similarly, when the application server 124 is maintained at the payment network, the functionalities of the application server 124 may be integrated into the payment network server 120, and when the application server 124 is maintained at the issuer, the functionalities of the application server 124 may be integrated into the issuer server 122. Further, in FIG. 1, the terminal device 114 and the beacon 116 are shown as two separate devices. However, in other embodiments, the beacon 116 may be integrated with the terminal device 114 to form a single electronic device for facilitating transactions.
Examples of the acquirer server 118, the payment network server 120, the issuer server 122, and the application server 124 may include, but are not limited to, personal computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machine that can execute a machine-readable code, cloud-based servers, distributed server networks, or a network of computer systems. The acquirer server 118, the payment network server 120, the issuer server 122, and the application server 124 may be realized through various web-based technologies such as, but not limited to, a Java web-framework, a .NET framework, a personal home page (PHP) framework, or any other web-application framework.
The communication network 126 is a medium through which content and messages are transmitted between user device 104, the merchant device 112, the terminal device 114, the acquirer server 118, the payment network server 120, the application server 124, the issuer server 122, or other entities that are pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard. Examples of the communication network 126 may include, but are not limited to, a Wi-Fi network, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, and combinations thereof. Various entities in the environment 100 may connect to the communication network 126 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE) communication protocols, or any combination thereof.
FIG. 2 is a process flow diagram 200 that illustrates an exemplary scenario for registering the beacon 116 with the application server 124 for the proximity-based authorization program, in accordance with an exemplary embodiment of the disclosure. The merchant device 112 is utilized by the store operative 110 to initiate the registration of the beacon 116. For the sake of brevity, it is assumed that the merchant store 108 includes a single beacon (i.e., the beacon 116). However, it will be apparent to a person skilled in the art that the merchant store 108 may include multiple beacons (such that each beacon is linked to a terminal device), without deviating from the scope of the disclosure. In such a scenario, each beacon is registered with the application server 124 in a manner similar to the registration of the beacon 116 as described below.
The merchant device 112 may be utilized by the store operative 110 to communicate the merchant ID of the merchant to the application server 124 (as shown by arrow 202). The application server 124 stores the received merchant ID in the second memory (as shown by arrow 204), and creates a merchant account of the merchant based on the received merchant ID (as shown by arrow 206). Further, the application server 124 communicates information pertaining to the merchant account (hereinafter referred to as “merchant account information”) to the merchant device 112 (as shown by arrow 208). The merchant account information may include an account number of the merchant account, a temporary password associated with the merchant account, or the like.
The merchant device 112 may then be utilized by the store operative 110 to communicate the beacon ID of the beacon 116 and the second device ID of the terminal device 114 to the application server 124 (as shown by arrow 210). The merchant ID, the beacon ID, and the second device ID constitute the merchant details of the merchant. The application server 124 stores the beacon ID and the second device ID in the second memory for linking the terminal device 114 to the beacon 116 and registering the beacon 116 with the application server 124 for the proximity-based authorization program (as shown by arrow 212). In one example, the application server 124 may create a tabular database (not shown) having various rows and columns for storing registration information associated with various registered beacons. Each row of the tabular database corresponds to a unique beacon. For example, each row may store merchant details such as a merchant ID of a merchant associated with the registered beacon, a device ID of a terminal device associated with the registered beacon, and a beacon ID of the registered beacon. The beacon 116 is thus registered with the application server 124 for the proximity-based authorization program. Additionally, the application server 124 updates the library of the service application to include the beacon ID of the registered beacon 116 (as shown by arrow 214). The application server 124 may then communicate a “Beacon Successfully Registered” message to the merchant device 112 for presenting to the store operative 110 (as shown by arrow 216). Upon the registration of the beacon 116, the beacon 116 is automatically activated and the beacon signal including the beacon ID is periodically broadcasted by the activated beacon 116 within the communication range.
FIGS. 3A-3D, collectively represent a process flow diagram 300 that illustrates an exemplary scenario for authorizing the transaction initiated by the user 102 at the terminal device 114, in accordance with an exemplary embodiment of the disclosure.
With reference to FIG. 3A, the registered beacon 116 is installed in the merchant store 108 and periodically broadcasts the beacon signal, including the beacon ID of the beacon 116, within the communication range (as shown by arrow 302). The user 102, carrying the user device 104, may visit the merchant store 108 for making a purchase. While on the premises of the merchant store 108, the user 102 having the user device 104 may enter the communication range of the beacon 116. Thus, the user device 104 also enters the communication range of the beacon 116 (as shown by arrow 304). When the user device 104 is present within the communication range of the beacon 116, the user device 104 receives the beacon signal broadcasted by the beacon 116 (as shown by arrow 306).
Upon the reception of the beacon signal, the service application installed on the user device 104 is activated or triggered. The service application is activated automatically (i.e., sans any input from the user 102). Once activated, the service application runs in the background on the user device 104, and hence does not require any input from the user 102. Further, upon the activation of the service application, the user device 104 checks the validity of the received beacon ID, i.e., determines whether the received beacon ID is a valid beacon ID (as shown by arrow 308). The user device 104 may access the library of the service application to determine whether the received beacon ID is a registered beacon ID. For example, if the received beacon ID is present in the library, the received beacon ID is valid, else the received beacon ID is determined to be invalid. When the received beacon ID is determined to be invalid, the received beacon ID is discarded by the user device 104 (i.e., the user device 104 does not communicate the received beacon ID to the application server 124). For the sake of brevity, it is assumed that the received beacon ID is a valid (i.e., a registered) beacon ID.
The user device 104 (i.e., the service application) then communicates the validated beacon ID and the first device ID of the user device 104 to the application server 124 (as shown by arrow 310). Based on the beacon ID and the first device ID received from the user device 104, the application server 124 determines the device status of the user device 104 (as shown by arrow 312). The device status indicates that the user device 104 is present within the communication range of the beacon 116. In one embodiment, the user device 104 may additionally communicate signal strength of the beacon signal received by the user device 104. In such a scenario, the application server 124 may determine the device status further based on the signal strength. For example, the application server 124 may determine that the user device 104 is present within the communication range of the beacon 116 when the signal strength of the beacon signal is greater than or equal to a threshold value, and alternatively determine that the user device 104 is outside the communication range of the beacon 116 when the signal strength of the beacon signal is less than the threshold value. The application server 124 stores the determined device status in the second memory (as shown by arrow 314). In one example, the application server 124 may add, to the tabular database, a column corresponding to the beacon 116 to include the device status of the user device 104.
With reference to FIG. 3B, the user 102 may then select a first product for purchasing from the merchant store 108 and may utilize the transaction card 106 for initiating the transaction (i.e., a purchase payment). In one example, the transaction card 106 may be inserted in a card slot (not shown) of the terminal device 114 for initiating the transaction. In another example, the transaction card 106 may be swiped across the card slot of the terminal device 114 for initiating the transaction. In another example, the transaction card 106 may be tapped on the terminal device 114 for initiating the transaction. In another example, transaction card 106 may be presented in the vicinity of the card slot for initiating the transaction.
The terminal device 114, by way of the card reader, records the card details of the transaction card 106 (as shown by arrow 316). Additionally, the terminal device 114 records other details of the transaction, such as the type of transaction (e.g., a purchase payment), the transaction amount, or the like. The terminal device 114 then communicates the transaction details of the transaction to the acquirer server 118 (as shown by arrow 318). The transaction details include the card details of the transaction card 106, the type of transaction, the transaction amount, and the second device ID of the terminal device 114. The transaction details may additionally include the merchant ID of the merchant.
The acquirer server 118 receives the transaction details from the terminal device 114 and identifies a payment network associated with the transaction card 106, as known by those skilled in the art. The acquirer server 118 then generates an authorization request for authorizing the transaction (as shown by arrow 320). The authorization request is pursuant to one or more standards for the interchange of transaction messages (such as the ISO8583 standard), and includes various fields (such as data elements) for storing various transaction details. The authorization request includes the card details of the transaction card 106, the second device ID of the terminal device 114, the merchant ID of the merchant, the type of transaction, and the transaction amount.
The acquirer server 118 then communicates the authorization request to the payment network server 120 of the identified payment network (as shown by arrow 322). The payment network server 120 receives the authorization request, and identifies the issuer that corresponds to the transaction card 106, as known by those skilled in the art. Once the issuer is identified, the payment network server 120 communicates the authorization request to the issuer server 122 of the identified issuer (as shown by arrow 324).
The issuer server 122 identifies the first device ID of the user device 104 that is linked to the transaction card 106 based on the card details included in the received authorization request (as shown by arrow 326). In one example, the issuer server 122 may access the account profile of the user 102 to identify the first device ID of the user device 104 that is linked to the transaction card 106. The issuer server 122 then generates the status request for enquiring the device status of the user device 104 (as shown by arrow 328). By enquiring the device status of the user device 104, the issuer server 122 validates the presence of the user 102 in the merchant store 108 where the transaction is initiated. The status request may include the first and second device IDs, and may additionally include the merchant ID. The issuer server 122 communicates the status request to the application server 124 via the communication network 126 (as shown by arrow 330).
With reference to FIG. 3C, the application server 124, based on the received status request, accesses the second memory to retrieve the device status of the user device 104 (as shown by arrow 332). For example, the application server 124 may refer to the tabular database stored in the second memory, and retrieve the stored device status corresponding to the first and second device IDs and the merchant ID. The application server 124 then communicates the retrieved device status of the user device 104 to the issuer server 122 as a response to the status request (as shown by arrow 334).
The device status of the user device 104 indicates whether the user device 104 is present within or outside the communication range of the beacon 116 that is linked to the terminal device 114 at which the transaction is initiated. The issuer server 122 authorizes the transaction when the received device status indicates that the user device 104 is present within the communication range of the beacon 116 (as shown by arrow 336). Alternatively, when the device status of the user device 104 received by the issuer server 122 indicates that the user device 104 is outside the communication range of the beacon 116, the issuer server 122 may decline the transaction, or may process the transaction as per the conventional authorization protocol, i.e., based on an authentication parameter provided by the user 102.
The issuer server 122 may additionally perform various other authorization checks to authorize the transaction. In an example, the issuer server 122 determines whether the transaction amount is less than or equal to the account balance of the financial account of the user 102. If the transaction amount is less than or equal to the account balance, the issuer server 122 authorizes the transaction. If the transaction amount is more than the account balance, the issuer server 122 declines the transaction. In another example, the issuer server 122 determines if the transaction amount is less than or equal to an overdraft amount. If the transaction amount is less than or equal to the overdraft amount, the issuer server 122 authorizes the transaction. If the transaction amount is more than the overdraft amount, the issuer server 122 declines the transaction. For the sake of brevity, it is assumed that the issuer server 122 authorizes the transaction.
The issuer server 122 generates the authorization response indicating that the transaction is authorized (as shown by arrow 338), and communicates the authorization response to the terminal device 114 by way of the payment network server 120 and the acquirer server 118 (as shown by arrows 340, 342, and 344). Upon reception of the authorization response, the terminal device 114 may display a “Transaction Successful” message to the store operative 110, and the store operative 110 hands over the first product to the user 102.
With reference to FIG. 3D, upon receiving the first product, the user 102 may exit the merchant store 108. The user device 104 thus exits the communication range of the beacon 116 (as shown by arrow 346). As the user device 104 is outside the communication range of the beacon 116, the user device 104 does not receive the beacon signal. The user device 104 (i.e., the service application) communicates the exit notification to the application server 124 (as shown by arrow 348). The exit notification indicates that the user device 104 has stopped receiving the beacon signal from the beacon 116. Based on the received exit notification, the application server 124 updates the device status of the user device 104 to indicate the absence of the user device 104 in the communication range of the beacon 116 (as shown by arrow 350). The application server 124 stores the updated device status in the second memory (as shown by arrow 352).
In another embodiment, the merchant store 108 may include multiple beacons and each beacon is linked to a terminal device. In one example, each beacon is linked to a different terminal device. In another example, two or more beacons may be linked to a single terminal device. Each beacon may have a corresponding communication range that encompasses different sections of the merchant store 108. In such a scenario, the transaction initiated at a terminal device by the user 102 is authorized when the user device 104 of the user 102 is present within the communication range of the beacon associated with the corresponding terminal device.
Although FIGS. 3A-3D describe that the terminal device 114 (e.g., a POS device) is installed in the merchant store 108, the scope of the disclosure is not limited to it. In various other embodiments, the terminal device 114 may not be associated with any merchant store 108, without deviating from the disclosure. Examples of such a terminal device may include an automated teller machine (ATM), a bunch note acceptor (BNA), a currency recycler, or the like. Further, it will be apparent to a person skilled in the art that the authorization of the transaction initiated at such a terminal device is similar to the authorization process described above in FIGS. 3A-3D.
FIG. 4 is an exemplary scenario 400 that illustrates the merchant store 108 including the beacon 116 that is registered for the proximity-based authorization program, in accordance with an exemplary embodiment of the disclosure. As illustrated in FIG. 4, the merchant store 108 has the beacon 116 installed in the immediate vicinity of the terminal device 114 (i.e., within the predetermined distance d1 from the terminal device 114) and the beacon 116 has the communication range 402. The user 102, carrying the user device 104, is shown to be present within the communication range 402. Since the user device 104 is present within the communication range 402, the device status of the user device 104 as stored in the second memory of the application server 124 indicates that the user device 104 is present within the communication range 402 of the beacon 116.
As shown in FIG. 4, other users 404 and 406, carrying their respective user devices 408 and 410, are also present on the premises of the merchant store 108. As the user devices 408 and 410 are shown to be present outside the communication range 402, device IDs of the user devices 408 and 410 may not be stored in the second memory in association with the beacon 116. Thus, the device statuses of the user devices 408 and 410 indicate that the user devices 408 and 410 are not present within the communication range 402. Alternatively, if the user devices 408 and 410 have exited the communication range 402, the device IDs of the user devices 408 and 410 may be stored in the second memory in association with the beacon 116 and the device statuses of the user devices 408 and 410 may indicate that the user devices 408 and 410 have exited the communication range 402. Thus, in this scenario, only the user 102 having the user device 104 is able to perform a transaction at the terminal device 114 by using the transaction card 106 and without requiring to provide the authentication parameter of the transaction card 106.
FIG. 5 is a block diagram that illustrates the issuer server 122, in accordance with an exemplary embodiment of the disclosure. The issuer server 122 includes first processing circuitry 502, the first memory 504, and a first transceiver 506. The first processing circuitry 502, the first memory 504, and the first transceiver 506 communicate with each other by way of a first communication bus 508.
The first processing circuitry 502 may include suitable logic, circuitry, interfaces, and/or code for authorizing transactions that are initiated by utilizing transaction cards (such as the transaction card 106) issued by the issuer. When the user 102 initiates the transaction at the terminal device 114, the first processing circuitry 502 receives the authorization request including the transaction details of the transaction. Based on the received transaction details, the first processing circuitry 502 identifies the user device 104 linked to the transaction card 106, and the first device ID of the user device 104. The first processing circuitry 502 generates the status request that includes the first and second device IDs, and may additionally include the merchant ID, and communicates the status request to the application server 124 for enquiring the device status of the user device 104. The first processing circuitry 502 authorizes the transaction when the device status received from the application server 124 indicates that the user device 104 is present within the communication range 402 of the beacon 116. Examples of the first processing circuitry 502 may include an application specific integrated circuit (ASIC) processor, a reduced instruction set computer (RISC) processor, a complex instruction set computer (CISC) processor, a field programmable gate array (FPGA), or the like.
The first memory 504 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for storing the account profiles of various financial accounts that are maintained at the issuer. Examples of the first memory 504 may include a random access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard-disk drive (HDD), a flash memory, a solid-state memory, or the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the first memory 504 in the issuer server 122, as described herein. In another embodiment, the first memory 504 may be realized in the form of a database server or a cloud storage working in conjunction with the issuer server 122, without departing from the scope of the disclosure.
The first transceiver 506 includes suitable logic, circuitry, interfaces and/or code, executable by the circuitry, for transmitting and receiving data over the communication network 126 using one or more communication protocols. The first transceiver 506 receives various requests and messages from the payment network server 120. For example, the first transceiver 506 receives the authorization request from the payment network server 120. The first transceiver 506 transmits various requests and messages to the payment network server 120. For example, the first transceiver 506 transmits the authorization response to the payment network server 120. Further, the first transceiver 506 transmits various requests and messages to the application server 124. For example, the first transceiver 506 transmits the status request to the application server 124. The first transceiver 506 similarly receives various requests and messages from the application server 124. For example, the first transceiver 506 receives the response to the status request from the application server 124. Examples of the first transceiver 506 may include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an Ethernet port, a universal serial bus (USB) port, or any other device configured to transmit and receive data.
FIG. 6 is a block diagram that illustrates the application server 124, in accordance with an exemplary embodiment of the disclosure. The application server 124 includes second processing circuitry 602, the second memory 604, and a second transceiver 606. The second processing circuitry 602, the second memory 604, and the second transceiver 606 communicate with each other by way of a second communication bus 608.
The second processing circuitry 602 may include suitable logic, circuitry, interfaces, and/or code for managing the proximity-based authorization program. The second processing circuitry 602 may include a registration manager 610, a service application host 612, and a device status manager 614.
The registration manager 610 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry for registering various beacons associated with various merchants (such as the merchant of the merchant store 108). When a store operative (such as the store operative 110) associated with the merchant initiates the registration with the application server 124 for the proximity-based authorization program, the registration manager 610 receives the merchant ID of the merchant, and creates the merchant account of the merchant based on the received merchant ID. The registration manager 610 may further receive the beacon ID of the beacon 116 and the second device ID of the terminal device 114, and stores the merchant ID, the beacon ID, and the second device ID in the second memory 604 (e.g., the tabular database) for registering the beacon 116 for the proximity-based authorization program. Examples of the registration manager 610 may include an ASIC processor, a RISC processor, a CISC processor, an FPGA, or the like.
The service application host 612 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry for hosting and managing the service application installed on user devices of various users (such as the user device 104 of the user 102). The service application host 612 manages the library of the service application. When a new beacon (such as the beacon 116) is registered for the proximity-based authorization program, the service application host 612 updates the library to include the beacon ID of the newly registered beacon 116. Examples of the service application host 612 may include an ASIC processor, a RISC processor, a CISC processor, an FPGA, or the like.
The device status manager 614 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry for maintaining device statuses of various devices. The device status manager 614 receives, from the user device 104, the beacon ID of the beacon 116 and the first device ID of the user device 104 when the user device 104 is present within the communication range 402 of the beacon 116. Based on the received beacon ID and the first device ID, the device status manager 614 determines the device status of the user device 104. The device status indicates that the user device 104 is present within the communication range 402 of the beacon 116, and stores the determined device status in the second memory 604 (e.g., the tabular database). In one embodiment, the device status may be represented as a Boolean variable. For example, the device status may have a value ‘1’ or ‘true’ to indicate that the user device 104 is present within the communication range 402 of the beacon 116 and a value ‘0’ or ‘false’ to indicate that the user device 104 has exited the communication range 402.
When the user 102 initiates the transaction at the terminal device 114, the device status manager 614 receives the status request from the issuer server 122. Based on the received status request, the device status manager 614 accesses the second memory 604 to retrieve the stored device status of the user device 104. The device status manager 614 then communicates the retrieved device status of the user device 104 to the issuer server 122 as a response to the status request. When the user device 104 exits the communication range 402 of the beacon 116, the device status manager 614 receives the exit notification from the user device 104. Based on the received exit notification, the device status manager 614 updates the device status of the user device 104 to indicate the absence of the user device 104 in the communication range 402 of the beacon 116, and stores the updated device status in the second memory 604. Examples of the device status manager 614 may include an ASIC processor, a RISC processor, a CISC processor, an FPGA, or the like.
The second memory 604 includes suitable logic, circuitry, and/or interfaces to store one or more instructions that are executed by the registration manager 610, the service application host 612, and the device status manager 614. The second memory 604 further stores the tabular database. Examples of the second memory 604 may include a RAM, a ROM, a removable storage drive, an HDD, a flash memory, a solid-state memory, or the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the second memory 604 in the application server 124, as described herein. In another embodiment, the second memory 604 may be realized in the form of a database server or a cloud storage working in conjunction with the application server 124, without departing from the scope of the disclosure.
The second transceiver 606 includes suitable logic, circuitry, interfaces and/or code, executable by the circuitry, for transmitting and receiving data over the communication network 126 using one or more communication protocols. The second transceiver 606 receives various requests and messages from the user device 104, the merchant device 112, and the issuer server 122. For example, during the registration of the beacon 116, the second transceiver 606 receives the merchant ID of the merchant, the second device ID of the terminal device 114, and the beacon ID of the beacon 116 from the merchant device 112. Further, when the user device 104 is present within the communication range 402 of the beacon 116, the second transceiver 606 receives the beacon ID and the first device ID from the user device 104. Similarly, when the user device 104 exits the communication range 402 of the beacon 116, the second transceiver 606 receives the exit notification from the user device 104. Additionally, when the user 102 initiates the transaction at the terminal device 114, the second transceiver 606 receives the status request from the issuer server 122.
The second transceiver 606 transmits various requests and messages to the merchant device 112 and the issuer server 122. For example, the second transceiver 606 communicates the merchant account information to the merchant device 112. Additionally, the second transceiver 606 communicates the response to the status request to the issuer server 122. Examples of the second transceiver 606 may include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, an Ethernet port, a USB port, or any other device configured to transmit and receive data.
FIG. 7 is a block diagram that illustrates system architecture of a computer system 700, in accordance with an exemplary embodiment of the disclosure. An embodiment of disclosure, or portions thereof, may be implemented as computer readable code on the computer system 700. In one example, the user device 104, the merchant device 112, the terminal device 114, the acquirer server 118, the payment network server 120, the issuer server 122, and the application server 124 may be implemented as the computer system 700.
Hardware, software, or any combination thereof may embody modules and components used to implement methods of FIGS. 8-12. The computer system 700 includes a processor 702 that may be a special-purpose or a general-purpose processing device. The processor 702 may be a single processor, multiple processors, or combinations thereof. Further, the processor 702 may be connected to a communication infrastructure 704, such as a bus, message queue, multi-core message-passing scheme, and the like. The computer system 700 may further include a main memory 706 and a secondary memory 708. Examples of the main memory 706 may include a RAM, a ROM, and the like. The secondary memory 708 may include an HDD or a removable storage drive, such as a floppy disk drive, a magnetic tape drive, a compact disc, an optical disk drive, a flash memory, and the like.
The computer system 700 further includes an input/output (I/O) interface 710 and a communication interface 712. The I/O interface 710 includes various input and output devices that are configured to communicate with the processor 702. Examples of the input devices may include a keyboard, a mouse, a joystick, a touchscreen, a microphone, and the like. Examples of the output devices may include a display screen, a speaker, headphones, and the like. The communication interface 712 may be configured to allow data to be transferred between the computer system 700 and various devices that are communicatively coupled to the computer system 700. Examples of the communication interface 712 may include a modem, a network interface, i.e., an Ethernet card, a communications port, and the like. Data transferred via the communication interface 712 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art.
A person of ordinary skill in the art will appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device. Further, the operations may be described as a sequential process, however some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.
FIG. 8 represents a flow chart 800 that illustrates a method for registering the beacon 116 with the application server 124 for the proximity-based authorization program, in accordance with an exemplary embodiment of the disclosure. The merchant device 112 is utilized by the store operative 110 to initiate the registration of the beacon 116. At step 802, the application server 124 receives the merchant ID from the merchant device 112. At step 804, the application server 124 stores the received merchant ID in the second memory 604. At step 806, the application server 124 creates the merchant account of the merchant based on the received merchant ID. At step 808, the application server 124 communicates the merchant account information to the merchant device 112.
At step 810, the application server 124 receives the beacon ID and the second device ID from the merchant device 112. The merchant ID, the beacon ID, and the second device ID constitute the merchant details of the merchant. At step 812, the application server 124 stores the beacon ID and the second device ID in the second memory 604 for registering the beacon 116 (and the terminal device 114) with the application server 124 for the proximity-based authorization program. The beacon 116 is thus linked to the terminal device 114 and registered with the application server 124. At step 814, the application server 124 updates the library of the service application to include the beacon ID of the registered beacon 116. At step 816, the application server 124 communicates the “Beacon Successfully Registered” message to the merchant device 112 for presenting to the store operative 110. Upon the registration of the beacon 116, the beacon 116 is automatically activated and the beacon signal including the beacon ID is periodically broadcasted by the activated beacon 116 within the communication range 402.
FIG. 9 represents a flow chart 900 that illustrates a method for facilitating authorization of the transaction initiated at the terminal device 114 by using the transaction card 106, in accordance with an exemplary embodiment of the disclosure. The registered beacon 116 installed in the merchant store 108 periodically broadcasts the beacon signal, including the beacon ID of the beacon 116, within the communication range 402. When the user 102, carrying the user device 104, enters the communication range 402, the user device 104 receives the beacon signal broadcasted by the beacon 116.
At step 902, the application server 124 receives the beacon ID of the beacon 116 and the first device ID of the user device 104 from the user device 104. The user device 104 may validate the beacon ID of the beacon signal, prior to communicating the beacon ID and the first device ID to application server 124. At step 904, the application server 124 determines the device status of the user device 104 based on the beacon ID and the first device ID received from the user device 104. The device status indicates that the user device 104 is present within the communication range 402 of the beacon 116. At step 906, the application server 124 stores the device status in the second memory 604.
The user 102 may then select the first product for purchasing from the merchant store 108, and utilize the transaction card 106 at the terminal device 114 for initiating the transaction (i.e., a purchase payment). The issuer server 122 receives the authorization request for the transaction initiated at the terminal device 114 and communicates the status request for enquiring the device status of the user device 104 to the application server 124. At step 908, the application server 124 receives the status request from the issuer server 122. The status request includes the first and the second device IDs, and may additionally include the merchant ID.
At step 910, the application server 124, based on the status request, accesses the second memory 604 to retrieve the device status of the user device 104. At step 912, the application server 124 communicates the retrieved device status of the user device 104 to the issuer server 122 as a response to the status request. The device status of the user device 104 indicates whether the user device 104 is present within or outside the communication range 402. The issuer server 122 authorizes the transaction when the received device status indicates that the user device 104 is present within the communication range 402 of the beacon 116.
Upon receiving the first product, the user 102 may exit the merchant store 108. The user device 104 thus exits the communication range 402 of the beacon 116. At step 914, the application server 124 receives the exit notification from the user device 104 (i.e., the service application) indicating that the user device 104 has stopped receiving the beacon signal from the beacon 116. At step 916, the application server 124 updates, based on the received exit notification, the device status of the user device 104 to indicate the absence of the user device 104 in the communication range 402 of the beacon 116. At step 918, the application server 124 stores the updated device status in the second memory 604.
FIG. 10 represents a flow chart 1000 that illustrates a method for authorizing the transaction initiated at the terminal device 114 by using the transaction card 106, in accordance with an exemplary embodiment of the disclosure. At step 1002, the issuer server 122 receives the authorization request from the payment network server 120 when the transaction (i.e., the purchase payment for the first product) is initiated at the terminal device 114 by way of the transaction card 106. At step 1004, the issuer server 122 identifies the first device ID of the user device 104 that is linked to the transaction card 106 based on the card details of the transaction card 106. At step 1006, the issuer server 122 generates the status request for enquiring the device status of the user device 104. The status request includes the first and second device IDs, and may additionally include the merchant ID. At step 1008, the issuer server 122 communicates the status request to the application server 124. At step 1010, the receives the device status of the user device 104 from the application server 124 as a response to the status request.
The device status of the user device 104 indicates whether the user device 104 is present within or outside the communication range 402 of the beacon 116. At step 1012, the issuer server 122 authorizes the transaction when the received device status indicates that the user device 104 is present within the communication range 402 of the beacon 116. Alternatively, when the device status of the user device 104 received by the issuer server 122 indicates that the user device 104 is outside the communication range 402 of the beacon 116, the issuer server 122 may decline the transaction, or may process the transaction as per the conventional authorization protocol, i.e., based on the authentication parameter provided by the user 102. For the sake of brevity, it is assumed that the issuer server 122 authorizes the transaction.
At step 1014, the issuer server 122 generates the authorization response indicating that the transaction is authorized. At step 1016, the issuer server 122 communicates the authorization response to the payment network server 120 for communicating to the terminal device 114. Upon reception of the authorization response, the terminal device 114 may display a “Transaction Successful” message to the store operative 110, and the store operative 110 hands over the first product to the user 102.
FIG. 11 represents a high-level flow chart 1100 that illustrates a method for authorizing transactions, in accordance with an exemplary embodiment of the disclosure. At step 1102, the application server 124 receives, from the user device 104 of the user 102, the first device ID of the user device 104 and the beacon ID of the beacon 116. The application server 124 receives the first device ID and the beacon ID in response to the user device 104 being within the communication range 402 of the beacon 116. At step 1104, the application server 124 determines, based on the received first device ID and the received beacon ID, the device status of the user device 104. The device status indicates that the user device 104 is present within the communication range 402. At step 1106, the application server 124 receives the status request for enquiring the device status of the user device 104 from the issuer server 122 operated by the issuer of the transaction card 106 that is linked to the user device 104. The status request is communicated by the issuer server 122 based on the transaction initiated at the terminal device 114 by way of the transaction card 106. At step 1108, the application server 124 communicates the response indicating the device status of the user device 104 to the issuer server 122 based on the received status request. The transaction is authorized by the issuer server 122 based on the response indicating the device status.
FIG. 12 represents a high-level flow chart 1200 that illustrates a method for authorizing transactions, in accordance with an exemplary embodiment of the disclosure. At step 1202, the issuer server 122 receives the authorization request for the transaction initiated at the terminal device 114 by way of the transaction card 106 of the user 102. At step 1204, the issuer server 122 communicates, based on the received authorization request, the status request to the application server 124 for enquiring the device status of the user device 104 linked to the transaction card 106. The device status indicates a presence or an absence of the user device 104 within the communication range 402 of the beacon 116 associated with the terminal device 114. At step 1206, the issuer server 122 receivers, in response to the communicated status request, a response indicating the device status of the user device 104. At step 1208, the issuer server 122 authorizes the transaction when the device status in the received response indicates that the user device 104 is present within the communication range 402 of the beacon 116.
Technological improvements in the application server 124 enable the issuer server 122 to authorize transactions without requiring any authentication parameter from users (such as the user 102). The user 102 thus does not have to remember PINs, provide biometric information, or manually enter OTPs. Further, since the need for providing the biometric information or entering the OTP is eliminated, a non-operational or faulty input means of the terminal device 114 (or an associated biometric device) does not hinder the user 102 from completing the transaction. Thus, the authorization process of the disclosure is more seamless and hassle-free as compared to the conventional authorization processes. Further, the user 102 is required to access the service application, by entering a password or drawing a pattern, at least once in the predetermined time interval. This ensures that the user device 104 of the user 102 is under the custody of the user 102, and makes it difficult for a perpetrator to utilize a stolen user device of the user 102 (i.e., the user device 104) to perform transactions. The authorization process of the disclosure is thus not only seamless but also secure, and therefore more efficient as compared to the conventional authorization processes.
Techniques consistent with the disclosure provide, among other features, systems and methods for authorizing transactions. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the disclosure, without departing from the breadth or scope.
In the claims, the words ‘comprising’, ‘including’ and ‘having’ do not exclude the presence of other elements or steps then those listed in a claim. The terms “a” or “an”, as used herein, are defined as one or more than one. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
While various embodiments of the disclosure have been illustrated and described, it will be clear that the disclosure is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the disclosure, as described in the claims.