Claims:1. An authentication method for a transaction, the authentication method comprising:
receiving, by a server from a first user device, an authentication request for the transaction initiated by a first user for electronically transferring a first amount from a first account of the first user to a second account associated with a second user;
actuating, by the server, based on the authentication request, at least one image-capturing device of the first user device for capturing a first facial image of the first user and a second facial image of the second user;
receiving, by the server, the first and second facial images and transaction data of the transaction from the first user device over a communication network; and
authenticating, by the server, the first and second users based on the received first and second facial images, respectively, wherein the transaction is processed as per the transaction data based on the authentication of the first and second users.

2. The authentication method of claim 1, further comprising:
receiving, by the server from the first user device, a registration request including one or more details of the first account and the first facial image of the first user;
communicating, by the server to an issuer associated with the first account, the one or more details of the first account for verification;
linking, by the server, the one or more details of the first account to the first facial image of the first user based on the verification; and
storing, by the server, the one or more details of the first account and the first facial image in a database associated with the server based on the linking.

3. The authentication method of claim 1, further comprising:
receiving, by the server from a second user device, a registration request including one or more details of the second account and the second facial image of the second user;
communicating, by the server to an issuer associated with the second account, the one or more details of the second account for verification;
linking, by the server, the one or more details of the second account to the second facial image of the second user based on the verification; and
storing, by the server, the one or more details of the second account and the second facial image in a database associated with the server based on the linking.

4. The authentication method of claim 1, further comprising identifying, by the server, the first and second accounts that are linked to the first and second facial images, respectively, based on the authentication of the first and second users.

5. The authentication method of claim 4, further comprising communicating, by the server to an issuer associated with the identified first account, the transaction data for processing the transaction.

6. The authentication method of claim 1, wherein the first and second users are authenticated when a match of each of the first and second facial images is available in a database associated with the server.

7. The authentication method of claim 1, wherein the first and second facial images are captured by the at least one image-capturing device simultaneously.

8. The authentication method of claim 1, wherein the first and second facial images are captured by the at least one image-capturing device at first and second time-instances, respectively.

9. The authentication method of claim 1, wherein the first and second facial images are captured by the at least one image-capturing device when the first and second users are present at a same geographical location.

10. The authentication method of claim 1, wherein the transaction data indicates the first amount that is to be transferred from the first account to the second account.

11. An authentication system for a transaction, the authentication system comprising:
a server that is configured to:
receive, from a first user device, an authentication request for the transaction initiated by a first user for electronically transferring a first amount from a first account of the first user to a second account associated with a second user,
actuate at least one image-capturing device of the first user device based on the authentication request, for capturing a first facial image of the first user and a second facial image of the second user,
receive the first and second facial images and transaction data of the transaction from the first user device over a communication network, and
authenticate the first and second users based on the received first and second facial images, respectively, wherein the transaction is processed as per the transaction data based on the authentication of the first and second users.

12. The authentication system of claim 11, wherein the server is further configured to:
receive, from the first user device, a registration request including one or more details of the first account and the first facial image of the first user,
communicate, to an issuer associated with the first account, the one or more details of the first account for verification,
link the one or more details of the first account to the first facial image of the first user based on the verification, and
store the one or more details of the first account and the first facial image based on the linking.

13. The authentication system of claim 11, wherein the server is further configured to:
receive, from a second user device, a registration request including one or more details of the second account and the second facial image of the second user,
communicate, to an issuer associated with the second account, the one or more details of the second account for verification,
link the one or more details of the second account to the second facial image of the second user based on the verification, and
store the one or more details of the second account and the second facial image based on the linking.

14. The authentication system of claim 11, wherein the server is further configured to identify the first and second accounts that are linked to the first and second facial images, respectively, based on the authentication of the first and second users.

15. The authentication system of claim 14, wherein the server is further configured to communicate, to an issuer associated with the identified first account, the transaction data for processing the transaction.

16. The authentication system of claim 11, wherein the first and second users are authenticated when a match of each of the first and second facial images is available in a database associated with the server.

17. The authentication system of claim 11, wherein the first and second facial images are captured by the at least one image-capturing device simultaneously.

18. The authentication system of claim 11, wherein the first and second facial images are captured by the at least one image-capturing device at first and second time-instances, respectively.

19. The authentication system of claim 11, wherein the first and second facial images are captured by the at least one image-capturing device when the first and second users are present at a same geographical location.
20. The authentication system of claim 11, wherein the transaction data indicates the first amount that is to be transferred from the first account to the second account.
, Description:METHOD AND SYSTEM FOR AUTHENTICATING USERS FOR TRANSACTIONS

BACKGROUND

FIELD OF THE DISCLOSURE

Various embodiments of the disclosure relate generally to transaction processing systems. More specifically, various embodiments of the disclosure relate to a method and a system for authenticating users for a transaction.

DESCRIPTION OF THE RELATED ART

With proliferation of the Internet, electronic transactions have become a preferred means for users to carry out financial transactions. Processing of such a transaction typically includes authenticating various entities (for example, a payer and a payee) involved in the transaction. Authenticating the payer and the payee corresponds to an act of ensuring that the payer and the payee are authorized to participate in the transaction.
Authentication methods that are deployed by existing transaction platforms for authenticating a payer, who initiates the transaction, typically use a unique passkey assigned to the payer. Examples of such unique passkeys may include authentication passwords, personal identification numbers (PINs), one-time-passwords (OTPs), quick response (QR) codes, or the like. The payer is required to enter the corresponding unique passkey into a registered user device of the payer or a terminal device of a payee for authentication. While the use of such passkeys assists in authenticating the payer, the authentication process becomes wearisome for the payer. The authentication methods further include authentication of the payee, who is involved in the transaction. In one exemplary scenario, the payer is required to scan a QR code associated with an account of the payee for authenticating the payee. Scanning of such QR codes not only increases an overall time required for carrying out the transaction but also adds to the inconvenience experienced by the payer.
In light of foregoing, there exists a need for a solution that solves the abovementioned problems and provides a seamless authentication mechanism for authenticating various entities involved in a transaction.

SUMMARY
In an embodiment of the disclosure, an authentication method for a transaction is provided. An authentication request for the transaction is received by a server from a first user device, when the transaction is initiated by a first user for electronically transferring a first amount from a first account of the first user to a second account associated with a second user. Based on the authentication request, at least one image-capturing device of the first user device is actuated by the server for capturing a first facial image of the first user and a second facial image of the second user. The first and second facial images and transaction data of the transaction are received by the server from the first user device over a communication network. Based on the received first and second facial images, the respective first and second users are authenticated by the server. Based on the authentication of the first and second users, the transaction is processed as per the transaction data.
In another embodiment of the disclosure, an authentication system for a transaction is provided. The authentication system includes a server that is configured to receive, from a first user device, an authentication request for the transaction initiated by a first user for electronically transferring a first amount from a first account of the first user to a second account associated with a second user. Based on the authentication request, the server actuates at least one image-capturing device of the first user device for capturing a first facial image of the first user and a second facial image of the second user. The server receives the first and second facial images and transaction data of the transaction from the first user device over a communication network. Based on the received first and second facial images, the server authenticates the first and second users, respectively. The transaction is processed as per the transaction data based on the authentication of the first and second users.

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 present disclosure are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements, and in which:
FIG. 1 is a block diagram that illustrates an exemplary environment for authenticating users involved in a transaction, in accordance with an exemplary embodiment of the disclosure;
FIG. 2 is a process flow diagram that illustrates an exemplary scenario for registering users with an authentication server of FIG. 1, in accordance with an exemplary embodiment of the disclosure;
FIGS. 3A and 3B, collectively represent a process flow diagram that illustrates an exemplary scenario for authenticating users involved in a transaction, in accordance with an exemplary embodiment of the disclosure;
FIGS. 4A and 4B, collectively represent an exemplary scenario that illustrates user interface (UI) screens rendered on a first user device of FIG. 1 for authenticating users involved in a transaction, in accordance with an exemplary embodiment of the disclosure;
FIG. 5 is a block diagram that illustrates an authentication server of FIG. 1, in accordance with an exemplary embodiment of the disclosure;
FIG. 6 is a block diagram that illustrates an issuer server of FIG. 1, in accordance with an exemplary embodiment of the disclosure;
FIGS. 7A and 7B, collectively represent a flow chart that illustrates an authentication method for a transaction, in accordance with an exemplary embodiment of the disclosure;
FIG. 8 represents a high-level flow chart that illustrates an authentication method for a transaction, in accordance with an exemplary embodiment of the disclosure; and
FIG. 9 is a block diagram that illustrates system architecture of a computer system, 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
When a transaction is initiated, various entities (for example, a payer and a payee) that are involved in the transaction are authenticated before processing the transaction. Authentication methods that are deployed by existing transaction platforms are not only time consuming but also adds to the inconvenience experienced by the payer and the payee.
Various embodiments of the present disclosure provide a method and a system that solve the abovementioned problems by offering a seamless authentication mechanism for authenticating various entities involved in a transaction. The system includes an authentication server that hosts a service application, executable on user devices, for offering a seamless authentication service for transactions. Users, who want to avail the authentication service, are required to register with the authentication server. After registration, the users may access the service application on corresponding user devices for availing the authentication service for the transactions. In one exemplary scenario, a first user, who is registered with the authentication server, may initiate the transaction by accessing the service application running on a first user device. The first user (i.e., a payer) may initiate the transaction for electronically transferring a first amount from a first account of the first user to a second account associated with a second user (i.e., a payee), who is also registered with the authentication server. The transaction may be a business-to-business (B2B) transaction, a business-to-consumer (B2C) transaction, or a consumer-to-consumer (C2C) transaction. The authentication server receives an authentication request from the first user device for authenticating the first and second users involved in the transaction. Based on the received authentication request, the authentication server actuates at least one image-capturing device of the first user device for capturing first and second facial images of the first and second users, respectively. The at least one image-capturing device may capture the first and second facial images either simultaneously or one after the other. The authentication server receives transaction data of the transaction and the captured first and second facial images from the first user device, and authenticates the first and second users based on the received first and second facial images, respectively. The authentication server communicates the transaction data to an issuer associated with the transaction based on the successful authentication of the first and second users. Thus, the authentication server utilizes facial recognition to authenticate various entities involved in the transaction in a seamless manner.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
Transaction is an exchange of funds between two or more entities. For example, the transaction may include transferring a transaction amount from an account of a user to an account of a merchant, when the user makes a purchase from the merchant. In another example, the transaction may include transferring the transaction amount from one account to another account or from one merchant account to another merchant account.
Image-capturing device is a device that is capable of recognizing and capturing digital images. In one example, the image-capturing device is a camera included in a user device, such as a smartphone.
Facial image is a digital image of a face of a user and is captured by an image-capturing device, such as a camera in a smartphone. Various facial recognition techniques may be applied on the captured facial image to confirm an identity (i.e., to authenticate) of the user. In a scenario where multiple users (for example, a payer and a payee) are involved in a transaction, facial images of the users are captured to authenticate the users for the transaction.
Server is a physical or cloud data processing system on which a server program runs. The server may be implemented in hardware or software, or a combination thereof. In one embodiment, the server may be implemented in computer programs executing on programmable computers, such as personal computers, laptops, or a network of computer systems. The server may correspond to one of an authentication server, an acquirer server, a payment network server, an issuer server, or a third-party server.
FIG. 1 is a block diagram that illustrates an exemplary environment 100 for authenticating users involved in a transaction, in accordance with an exemplary embodiment of the disclosure. The exemplary environment 100 includes first and second users 102 and 104 in possession of first and second user devices 106 and 108, respectively, an authentication server 110, and an issuer server 112. The first and second user devices 106 and 108, the authentication server 110, and the issuer server 112 communicate with each other by way of a communication network 114 or through separate communication networks established therebetween.
The first user 102 is an individual, who is an account holder of a first account maintained at a financial institution, such as an issuer. The first user 102 may be a payer who wants to transfer funds electronically from the first account to one or more accounts of other users (for example, the second user 104). The first account may be associated with various virtual and physical payment modes that enable the first user 102 to initiate transactions from the first account. Examples of such payment modes may include debit cards, credit cards, prepaid cards, gift cards, promotional cards, digital wallets, Unified Payment Interface (UPI) link, Net banking, and/or the like.
The second user 104 is an individual associated with a second account, maintained at a financial institution, such as the issuer. The second user 104 may be a payee who receives the funds that are electronically transferred by the first user 102 from the first account to the second account. The second user 104 may be an independent account holder of the second account or a joint account holder of the second account.
The transaction that takes place between the first and second users 102 and 104 may be a B2B transaction, a B2C transaction, a peer-to-peer (P2P) transaction, or a C2C transaction. For example, when both the first and second users 102 and 104 are business merchants, the transaction between the first and second users 102 and 104 corresponds to a B2B transaction. In another example, when the first user 102 is a consumer and the second user 104 is a merchant or a salesperson employed by a merchant, the transaction between the first and second users 102 and 104 corresponds to a B2C transaction. In another example, when both the first and second users 102 and 104 are peers or consumers, the transaction between the first and second users 102 and 104 corresponds to a C2C or P2P transaction.
The first user device 106 is a communication device of the first user 102. The first user device 106 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for executing a service application (shown in FIG. 2) hosted by the authentication server 110. The first user device 106 may be utilized by the first user 102 to register with the authentication server 110 for accessing the service application. The first user device 106 may be further utilized by the first user 102 to initiate a transaction from the first account. The first user device 106 may be configured to communicate transaction data of the transaction to the authentication server 110. The transaction data may include details of the first account and a first amount associated with the transaction. Examples of the first user device 106 may include a mobile phone, a smartphone, a laptop, a tablet, a phablet, or any other device capable of communicating via the communication network 114.
The first user device 106 may include first and second image-capturing devices 116a and 116b. The first and second image-capturing devices 116a and 116b may be configured to capture digital images, when actuated. Upon actuation, the first image-capturing device 116a may capture a front-view digital image and the second image-capturing device 116b may capture a rear-view digital image. In one embodiment, the first and second image-capturing devices 116a and 116b may be actuated simultaneously to capture front-view and rear-view digital images simultaneously. The first and second image-capturing devices 116a and 116b may be actuated manually by the first user 102 based on requirement. The first and second image-capturing devices 116a and 116b may be further actuated automatically by the authentication server 110, based on the consent of the first user 102. When the first and second image-capturing devices 116a and 116b are actuated by the authentication server 110, the first user device 106 may be configured to communicate the digital images captured by the first and second image-capturing devices 116a and 116b to the authentication server 110.
The second user device 108 is a communication device of the second user 104. The second user device 108 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for executing the service application hosted by the authentication server 110. The second user device 108 may be functionally similar to the first user device 106, and include third and fourth image-capturing devices 118a and 118b. The third and fourth image-capturing devices 118a and 118b are functionally similar to the first and second image-capturing devices 116a and 116b, respectively.
Examples of the first through fourth image-capturing devices 116a, 116b, 118a, and 118b may include digital cameras, video-capturing devices, image sensors capable of capturing digital images, or other devices that are capable of capturing digital images when actuated. In one example, the first and third image-capturing devices 116a and 118a are front-view cameras, and the second and fourth image-capturing devices 116b and 118b are rear-view cameras.
It will be apparent to a person of ordinary skill in the art that the scope of the disclosure is not limited to the first and second user devices 106 and 108 to include only two image-capturing devices. In another embodiment, the first and second user devices 106 and 108 may include any number of image-capturing devices without deviating from the scope of the disclosure.
The authentication server 110 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for hosting the service application. The authentication server 110 is a computing server, an apparatus, or a system that offers an authentication service for authenticating various entities (for example, the first and second users 102 and 104) involved in electronic transactions. The authentication server 110 may offer the authentication service to users, who are registered with the authentication server 110, by way of the service application. The registration of the first user 102 for the authentication service is described in detail in conjunction with FIG. 2. The authentication server 110 may be configured to utilize facial recognition techniques for authenticating various entities involved in electronic transactions. The authentication of the first and second users 102 and 104 for a transaction is described in detail in conjunction with FIGS. 3A and 3B. Based on successful authentication of the first and second users 102 and 104, the authentication server 110 may be configured to communicate the transaction data of the transaction to the issuer server 112 associated with the transaction for processing the transaction.
The issuer server 112 is a computing server that is operated by the issuer and includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for processing transactions. The issuer is a financial institution that manages accounts of multiple users, such as the first and second users 102 and 104. Account details of the accounts, such as the first and second accounts of the first and second users 102 and 104, respectively, established with the issuer are stored as account profiles in a memory (not shown) of the issuer server 112 or on a cloud server associated with the issuer server 112. The account details may include an account balance, an available credit line, details of an account holder, transaction history of the account holder, account information, or the like. The details of the account holder may include name, age, gender, physical attributes, registered contact number, alternate contact number, registered e-mail ID, or the like of the account holder.
The issuer server 112 may be configured to process various transactions as per the transaction data received from the authentication server 110. The issuer server 112 may further generate authorization responses indicating whether the transactions are approved or declined. Methods for processing transactions via the issuer server 112 will be apparent to a person of ordinary skill in the art and may include processing the transaction via the traditional four-party system or the traditional three-party system.
Examples of the authentication server 110 and the issuer server 112 may include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that can execute a machine-readable code, cloud-based servers, distributed server networks, a network of computer systems, or a combination thereof.
Though the authentication server 110 is shown to be a standalone entity in FIG. 1, in other embodiments, the authentication server 110 may be integrated with an acquirer server (not shown), a payment network server (not shown), the issuer server 112, or any other third-party server, without deviating from the scope of the disclosure. For example, if the authentication server 110 is integrated with the issuer server 112, the functionality of the authentication server 110 may be implemented by the issuer server 112.
The communication network 114 is a medium through which content and messages are transmitted between the first and second user devices 106 and 108, the authentication server 110, the issuer server 112, or other entities involved in transaction processing. Examples of the communication network 114 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 exemplary environment 100 may connect to the communication network 114 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.
In operation, the first and second users 102 and 104 may utilize the respective first and second user devices 106 and 108 to register with the authentication server 110. For registration, the first and second users 102 and 104 may provide corresponding registration details through the respective first and second user devices 106 and 108 to the authentication server 110. The registration details of the first user 102 may include personal details (e.g., name, address, contact information, or the like) of the first user 102, details of the first account of the first user 102, and a first facial image of the first user 102. The details of the first account may further include a first set of payment modes that is associated with the first account. For example, the first set of payment modes may include a first debit card, a first credit card, a first digital wallet, and/or a first UPI link associated with the first account. Likewise, the registration details of the second user 104 may include personal details (e.g., name, address, contact information, or the like) of the second user 104, details of the second account of the second user 104, and a second facial image of the second user 104. The details of the second account may further include a second set of payment modes that is associated with the second account. For example, the second set of payment modes may include a second debit card, a second credit card, a second digital wallet, and/or a second UPI link. The authentication server 110 verifies the registration details of the first and second users 102 and 104. Upon verification, the authentication server 110 stores the registration details of the first and second users 102 and 104 in a memory of the authentication server 110. After successful registration of the first and second users 102 and 104, the first and second users 102 and 104 are allowed to access the service application on their respective first and second user devices 106 and 108 for initiating transactions using their registered accounts (for example, the first and second accounts).
In one exemplary scenario, the first user device 106 may be utilized by the first user 102 for transferring the first amount from the first account to the second account of the second user 104. The first user 102 may access the service application running on the first user device 106 to initiate the transaction for transferring the first amount. The authentication server 110 may receive an authentication request for authenticating various entities (here, the first and second users 102 and 104) involved in the initiated transaction. Based on the authentication request, the authentication server 110 may be configured to actuate at least one of the first and second image-capturing devices 116a and 116b for capturing the first and second facial images of the respective first and second users 102 and 104 involved in the transaction. The authentication server 110 may actuate at least one of the first and second image-capturing devices 116a and 116b by way of the service application running on the first user device 106. At least one of the first and second image-capturing devices 116a and 116b that is actuated captures the first and second facial images of the first and second users 102 and 104, respectively. In one embodiment, the authentication server 110 may actuate both the first and second image-capturing devices 116a and 116b for capturing the first and second facial images, simultaneously. The first user device 106 then communicates the transaction data of the transaction and the captured first and second facial images to the authentication server 110 for authentication. The authentication server 110 may authenticate the first and second users 102 and 104 by comparing the received first and second facial images with the stored first and second facial images of the first and second users 102 and 104, respectively. When the authentication of the first and second users 102 and 104 is successful, the authentication server 110 may communicate the transaction data to the issuer server 112 for processing the transaction. Based on the transaction data, the issuer server 112 may process the transaction and generate the authorization response for the transaction.
FIG. 2 is a process flow diagram 200 that illustrates an exemplary scenario for registering users with the authentication server 110, in accordance with an exemplary embodiment of the disclosure. Hereinafter, the service application hosted by the authentication server 110 is designated and referred to as “the service application 202”. The service application 202 is executable on the first and second user devices 106 and 108 and may serve as a gateway to the authentication server 110. For the sake of brevity, the registration process is described with respect to the first user 102.
For registering with the authentication server 110, the first user 102 accesses (i.e., opens) the service application 202 running on the first user device 106 (as shown by arrow 204). The first user 102 further provides registration details through the first user device 106 (as shown by arrow 206). The registration details of the first user 102 may include the personal details of the first user 102, the first account details, and the first facial image of the first user 102. The registration details may further include the details of the first set of payment modes associated with the first account. For example, the first set of payment modes may include the first debit card, the first credit card, the first digital wallet, and the first UPI link. For example, the details of the first debit card may include a debit card number of the first debit card, an expiry date of the debit card, or the like. Each of the first set of payment modes may enable the first user 102 to carry out the transaction from the first account. For providing the first facial image, the first user 102 may manually actuate one of the first and second image-capturing devices 116a and 116b. One of the first and second image-capturing devices 116a and 116b that is actuated captures the first facial image of the first user 102.
The first user device 106 then communicates a registration request including the registration details provided by the first user 102 to the authentication server 110 over the communication network 114 (as shown by arrow 208). Based on the received registration request, the authentication server 110 identifies an issuer that is associated with the first account of the first user 102. For example, the authentication server 110 may identify that the first account is associated with the issuer server 112.
The authentication server 110 communicates the registration details (i.e., the received personal details of the first user 102, the first account details, and the details of the first set of payment modes) to the identified issuer server 112 for verification (as shown by arrow 210). The issuer server 112 receives and verifies the personal details of the first user 102, the first account details, and the details of the first set of payment modes (as shown by arrow 212). In one exemplary scenario, based on the first account details the issuer server 112 may determine that the first account is invalid. In such a scenario, the issuer server 112 communicates an acknowledgement to the authentication server 110 indicating that the first account is invalid. Based on the acknowledgement, the authentication server 110 requests the first user 102, by way of the service application 202 that runs on the first user device 106, to either re-submit the first account details or to submit details of another account. In another exemplary scenario, when the first account is identified to be valid, the issuer server 112 communicates an acknowledgement to the authentication server 110 indicating that the first account is successfully verified (as shown by arrow 214). After receiving the acknowledgement indicating that the first account is successfully verified, the authentication server 110 links the first account to the first facial image of the first user 102 (as shown by arrow 216). Based on the linking of the first facial image to the first account, the authentication server 110 stores the first facial image, the first account details, and the details of the first set of payment modes in a database (as shown in FIG. 5) maintained at the authentication server 110 (as shown by arrow 218). The authentication server 110 then communicates a registration notification to the first user device 106 indicating a successful registration of the first user 102 and the first account (as shown by arrow 220). The service application 202 may further display the successful registration message on a user interface of the first user device 106.
In one embodiment, the first user 102 may be associated with multiple accounts. For example, the first user 102 is associated with the first account and a third account. In such a scenario, the authentication server 110 may allow the first user 102 register multiple accounts (i.e., the first and third account) and corresponding payment modes. The authentication server 110 may further link both the first and third accounts to the first facial image of the first user 102.
Likewise, the authentication server 110 may be configured to register other users (for example, the second user 104) who want to avail the authentication service offered by the authentication server 110. For registering the second user 104, the authentication server 110 links the second facial image of the second user 104 to the second account associated with the second user 104, and stores the linked second facial image and the second account details in the database maintained at the authentication server 110. In one embodiment, the second user 104 is a merchant of a retail store who has registered with the authentication server 110. In another embodiment, the second user 104 may be a salesperson employed by a merchant to handle a payment front-desk in the retail store of the merchant. In such a scenario, the merchant may register the second user 104 and request the authentication server 110 to link the second facial image of the second user 104 with the merchant account (i.e., the second account). Likewise, the merchant may also request the authentication server 110 to link facial images of other salespersons with the merchant account.
FIGS. 3A and 3B, collectively represent a process flow diagram 300 that illustrates an exemplary scenario for authenticating users involved in a transaction, in accordance with an exemplary embodiment of the disclosure. The process flow diagram 300 involves the first user device 106, the authentication server 110, and the issuer server 112.
The first user 102 may want to conduct a transaction for electronically transferring the first amount from the first account to the second account associated with the second user 104. In one example, the first user 102 may want to conduct the transaction for purchasing a product and/or service from a retail store associated with the second user 104. The first and second users 102 and 104 are present at the same geographical location, for example, at the retail store. For initiating the transaction, the first user 102 may access (i.e., open) the service application 202 running on the first user device 106 (as shown by arrow 302). The service application 202 may be password protected, i.e., locked by way of a password. For unlocking the service application 202, the first user device 106 may prompt the first user 102 to enter a password or a unique key set (as shown by arrow 304). In a non-limiting example, it is assumed that the service application 202 may be unlocked with a password (for example, a fingerprint, a pattern lock, an alphanumeric PIN, or the like) set for locking and unlocking the first user device 106. The first user 102 enters the password and unlocks the service application 202 (as shown by arrow 306). After unlocking the service application 202, the first user 102 may utilize the service application 202 for initiating the transaction (as shown by arrow 308). The first user device 106 communicates an authentication request to the authentication server 110 based on the initiation of the transaction (as shown by arrow 310). The authentication server 110 receives the authentication request and generates an actuation command for actuating at least one of the first and second image-capturing devices 116a and 116b (as shown by arrow 312). For the sake of brevity, it is assumed that the authentication server 110 generates the actuation command for actuating both the first and second image-capturing devices 116a and 116b, simultaneously.
The authentication server 110 then communicates the actuation command to the first user device 106 (as shown by arrow 314). Based on the actuation command, the first and second image-capturing devices 116a and 116b are actuated, simultaneously (as shown by arrow 316). In one example, the first user 102 may have given permission to the authentication server 110 to access (e.g., for actuation) the first and second image-capturing devices 116a and 116b by way of the service application 202 that runs on the first user device 106. Upon actuation, the first and second image-capturing devices 116a and 116b capture the first and second facial images of the first and second users 102 and 104, respectively (as shown by arrow 318). In one example, the first user device 106 may display a message on a display screen of the first user device 106 to prompt the first user 102 to hold the first user device 106 in a manner that the first and second image-capturing devices 116a and 116b are capable of capturing the first and second facial images of the first and second users 102 and 104, respectively. In one embodiment, the first and second image-capturing devices 116a and 116b may simultaneously (i.e., at the same time-instance) capture the respective first and second facial images. In another embodiment, the first and second image-capturing devices 116a and 116b may capture the respective first and second facial images one after the other without any intervention from the first user 102. The first user device 106 then communicates the first and second facial images to the authentication server 110 (as shown by arrow 320).
With reference to FIG. 3B, the authentication server 110 receives the first and second facial images and authenticates the first and second users 102 and 104 based on the respective first and second facial images (as shown by arrow 322). For authenticating the first and second users 102 and 104, the authentication server 110 determines whether a match of the first and second facial images is available in the database maintained at the authentication server 110. In one example, at least one of the first and second facial images may not match with any available images in the database. In such a scenario, the authentication server 110 may communicate an error notification indicating that authentication is unsuccessful. In another example, the authentication server 110 may find a match for each of the first and second facial images in the database. In such a scenario, the authentication server 110 may determine that the first and second users 102 and 104 are successfully authenticated and identify the registered accounts (for example, the first and second accounts) that are linked to the first and second facial images.
The authentication server 110 may further select payment modes from the first set of payment modes that are similar with respect to the second set of payment modes (as shown by arrow 324). For example, the authentication server 110 may identify that the first and second digital wallets included in the first and second set of payment modes, respectively, correspond to PayPal® digital wallets. Thus, the first digital wallet (i.e., the PayPal digital wallet) is selected as a common payment mode. The authentication server 110 may further select other generic payment modes from the first set of payment modes associated with the first account. Examples of the generic payment modes may include transaction cards, Net banking, or UPI links. After selecting the common and generic payment modes, the authentication server 110 communicates a list of the selected payment modes to the first user device 106 for user selection (as shown by arrow 326). The list of the selected payment modes is displayed on the display screen of the first user device 106 (as shown by arrow 328). The first user 102 may select any one of the displayed payment modes for carrying out the transaction (as shown by arrow 330). In one example, the first user 102 may select the first debit card for carrying out the transaction. In another example, the first user 102 may select the first UPI link for carrying out the transaction. The first user 102 further enters the first amount of the transaction through the first user device 106 (as shown by arrow 332). The details of the selected payment mode and the first amount are collectively referred to as transaction data of the transaction. The first user device 106 then communicates the transaction data to the authentication server 110 (as shown by arrow 334) and the authentication server 110 communicates the transaction data to the identified issuer server 112 for processing the transaction (as shown by arrow 336). The issuer server 112 receives the transaction data from the authentication server 110 and processes (i.e., authorizes) the transaction as per the transaction data (as shown by arrow 338). Methods for processing transactions via the issuer server 112 will be apparent to a person of ordinary skill in the art. For example, the transaction processing via the issuer server 112 may involve an acquirer and a payment network associated with the transaction. In one scenario where the first and second accounts are maintained at the same financial institution, the acquirer and the issuer are same.
In one exemplary scenario, the issuer server 112 may decline the transition due insufficient balance or poor network connectivity. In another exemplary scenario, the issuer server 112 may process the transaction successfully. In this scenario, the first user device 106 may receive an authorization notification to the first user device 106 that the transaction is processed successfully and the first amount is deducted from the first account of the first user 102. The second user device 108 may receive a credit notification indicating that the transaction is processed successfully and the first amount is credited to the second account linked to the second facial image of the second user 104.
In another embodiment, the first and second image-capturing devices 116a and 116b may capture the first and second facial images, respectively, at different time-instances. For example, the first image-capturing device 116a captures the first facial image at a first time-instance and the second image-capturing device 116b captures the second facial image at a second time-instance that is different from the first time-instance. The difference between the first and second time-instances may vary based on a processing speed of the first user device 106. In one embodiment, the first user device 106 may have only one image-capturing device (for example, the first image-capturing device 116a) to capture both, the first and second facial images. In such a scenario, the first image-capturing device 116a captures the first and second facial images one after the other.
FIGS. 4A and 4B, collectively represent an exemplary scenario 400 that illustrates first through sixth user interface (UI) screens 402-412 rendered on the first user device 106 for authenticating users involved in a transaction, in accordance with an exemplary embodiment of the disclosure.
When the first user 102 interacts with the service application 202 through the first user device 106, the first UI screen 402 is rendered on a display of the first user device 106. The first UI screen 402 may prompt the first user 102 to unlock the service application 202 using the device password of the first user device 106 or a unique password set for the service application 202 by the first user 102. Examples of the device password or the unique password may be a pattern code, an alphanumeric code, a numeric combination, a biometric password, or a fingerprint scan. The first UI screen 402 may display a first input box 414 for the first user 102 to enter the device password or the unique password. The first UI screen 402 may further display a first submit button 416, which is selectable by the first user 102 for submitting the device password or the unique password. When the first user 102 provides the device password or the unique password, and selects or activates the first submit button 416, the service application 202 is opened on the first user device 106 and the second UI screen 404 is rendered.
The second UI screen 404 may prompt the first user 102 to select one of a ‘pay’ button 418 or a ‘receive’ button 420. The ‘pay’ button 418 enables the first user 102 to initiate a transaction for transferring the first amount from the first account to another account of a payee. The ‘receive’ button 420 enables that the first user 102 to initiate a transaction for receiving a transaction amount in the first account from another account of a payer. When the first user 102 selects the ‘pay’ button 418, the first user 102 acts as the payer and a transaction for transferring funds from the first account is initiated. When the first user 102 selects the ‘receive’ button 420, the first user 102 acts as the payee and a transaction for receiving funds in the first account is initiated. For the sake of brevity, it is assumed that the first user 102 selects the ‘pay’ button 418 for transferring the first amount from the first account to the second account associated with the second user 104. Based on the selection of the ‘pay’ button 418, the authentication server 110 actuates at least one of the first and second image-capturing devices 116a and 116b, and the third UI screen 406 is rendered on the first user device 106.
Upon actuation, the first and second image-capturing devices 116a and 116b may capture the first and second facial images of the first and second users 102 and 104, respectively. Hereinafter, the first and second facial images are designated and referred to as “the first and second facial images 422 and 424”, respectively. The third UI screen 406 may display the captured first and second facial images 422 and 424 to the first user 102. In one embodiment (as shown in FIG. 4A), the display screen of the first user device 106 may virtually split into two sections 426 and 428 to display the captured first and second facial images 422 and 424, respectively, to the first user 102. The first user device 106 communicates the first and second facial images 422 and 424 to the authentication server 110 and the authentication server 110 authenticates the first and second users 102 and 104 based on the first and second facial images 422 and 424, respectively (as described in FIGS. 3A and 3B). Based on the authentication of the first and second users 102 and 104, the authentication server 110 may identify the accounts that are linked to the first and second facial images 422 and 424, and display first and second registered usernames of the first and second users 102 and 104 in the sections 426 and 428, respectively. For example, the first username of the first user 102 is ‘Jane Doe’. Thus, the username ‘Jane Doe’ is displayed in the section 426 corresponding to the first facial image 422. Similarly, the username ‘John Doe’ of the second user 104 is displayed in the section 428 corresponding to the second facial image 424. Based on the authentication of the first and second users 102 and 104, the authentication server 110 selects the common and generic payment modes of the first user 102 and communicates the selected payment modes list to the first user device 106. The authentication server 110 may further render the fourth UI screen 408 for displaying the list of selected payment modes for user selection.
The fourth UI screen 408 prompts the first user 102 to select one of the displayed payment modes for carrying out the transaction. For the sake of brevity, the list of displayed payment modes is shown to include first, second, and third payment modes represented by buttons 430, 432, and 434, respectively. In one example, the first, second, and third payment modes may correspond to the first digital wallet, the first UPI link, and the first debit card, respectively. The first user 102 may select any one of the buttons 430-434 for carrying out the transaction. Based on the selection of a displayed payment mode (e.g., the button 434), the authentication server 110 renders the fifth UI screen 410.
With reference to FIG. 4B, the fifth UI screen 410 may prompt the first user 102 to enter the transaction amount of the transaction. The fifth UI screen 410 may display a second input box 436 to enter the transaction amount of the transaction. The fifth UI screen 410 may further display a second submit button 438 which is selectable by the first user 102. When the transaction amount is entered in the second input box 436 and the second submit button 438 is activated or selected, the transaction data including the details of the selected payment mode and the transaction amount is communicated to the authentication server 110 by the first user device 106. The authentication server 110 communicates the transaction data to the issuer server 112 for processing the transaction. The sixth UI screen 412 is then rendered on the first user device 106 to display a message indicating whether the transaction is approved or declined by the issuer server 112.
In another embodiment, the second user 104 may select the ‘receive’ button 420 that is displayed on the second UI screen 404, rendered in the second user device 108, for initiating a transaction to receive funds in the second account. Based on the selection of the ‘receive’ button 420, the third and fourth image-capturing devices 118a and 118b may be actuated by the authentication server 110 to capture the first and second facial images 422 and 424 of the first and second users 102 and 104, respectively, for authentication.
FIG. 5 is a block diagram that illustrates the authentication server 110, in accordance with an exemplary embodiment of the disclosure. The authentication server 110 includes first processing circuitry 502, a 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 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for authenticating various users involved in a transaction initiated by using the service application 202. Examples of the first processing circuitry 502 may include, but are not limited to, 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 processing circuitry 502 includes a memory manager 510, an application host 512, an authentication manager 514, and a comparator 516.
The memory manager 510 is configured to manage the first memory 504 of the authentication server 110. The memory manager 510 is configured to store, in the database (hereinafter, designated and referred to as “the database 518”) maintained in the first memory 504, the account details of the registered accounts, the details of various payment modes associated with the registered accounts, and the facial images of the registered users. For example, the memory manager 510 stores the first account details, the details of the first set of payment modes associated with the first account, and the first facial image 422 of the first user 102 that is linked to the first account in the database 518. The memory manager 510 may be configured to execute various database management operations (such as, storing data, updating stored data, or deleting the data) for managing the database 518.
The application host 512 is configured to host the service application 202 that is executable on various user devices, such as the first and second user devices 106 and 108. By way of the service application 202, the application host 512 allows the first and second users 102 and 104 to register with the authentication server 110 for availing the offered authentication service. The application host 512 further allows the first and second users 102 and 104 to initiate transactions using the service application 202.
The authentication manager 514 is configured to request the issuer server 112 to verify the registration details of the first and second users 102 and 104, who want to register with the authentication server 110. The authentication manager 514 is further configured to authenticate the first and second users 102 and 104 involved in a transaction initiated by way of the service application 202. The authentication manager 514 is configured to instruct the comparator 516 to identify a match of the received first and second facial images 422 and 424 in the database 518. The authentication manager 514 is configured to authenticate the first and second users 102 and 104 when a match of the received first and second facial images 422 and 424 is available in the database 518 maintained at the first memory 504. The authentication manager 514 is further configured to communicate the transaction data of the transaction to the issuer server 112 for processing the transaction.
The comparator 516 is configured to compare the received first and second facial images 422 and 424 with the images stored in the database 518 maintained in the first memory 504 to identify a match. The comparator 516 may utilize one or more facial recognition algorithms known in the art for identifying the match of the first and second facial images 422 and 424. For example, the comparator 516 may look up the database 518 to identify a match of each of the first and second facial images 422 and 424. The comparator 516 is further configured to select the common and generic payment modes from the first set of payment modes of the first user 102 for user selection (as described in FIG. 3B).
The first memory 504 includes suitable logic, circuitry, interfaces, and/or codes, executable by the circuitry, for storing the database 518 that includes the facial images (for example, the first and second facial images 422 and 424) of the registered users, the account details (for example, the first and second account details), and the details of the payment modes (for example, the first and second set of payment modes) associated with the registered accounts. In one example, the database 518 may be a tabular database that includes rows and columns such that each row represents the registration details of a registered user and all column entries of a row are linked to each other. Examples of the first memory 504 may include, but are not limited to, 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 of ordinary skill in the art that the scope of the disclosure is not limited to realizing the first memory 504 in the authentication server 110, as described herein. In another embodiment, the first memory 504 may be realized in form of a database server or a cloud storage working in conjunction with the authentication server 110, 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 114 using one or more communication protocols. The first transceiver 506 transmits various requests and messages to the first user device 106 and the issuer server 112. For example, the first transceiver 506 may transmit the list of common and generic payment modes to the first user device 106. The first transceiver 506 may transmit the verification requests to the issuer server 112 for verifying the users (for example, the first and second users 102 and 104) who want to register with the authentication server 110. The first transceiver 506 receives various requests and messages from the first user device 106 and the issuer server 112. For example, the first transceiver 506 may receive the registration and authentication requests from the first user device 106. The first transceiver 506 further receives the acknowledgement from the issuer server 112 indicating the verification of the account details of the first and second users 102 and 104. 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 issuer server 112, in accordance with an exemplary embodiment of the disclosure. The issuer server 112 includes second processing circuitry 602, a 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 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for processing transactions. Examples of the second processing circuitry 602 may include, but are not limited to, an ASIC processor, a RISC processor, a CISC processor, a FPGA, or the like. The second processing circuitry 602 includes a verification manager 610 and a transaction manager 612.
The verification manager 610 receives the verification requests from the authentication server 110 for verifying the registration details of users (for example, the first and second users 102 and 104). Based on the verification requests, the verification manager 610 determines whether the registration details provided by the first and second users 102 and 104 are valid or not. The verification manager 610 generates acknowledgements indicating results of the verification of the registration details of the users.
The transaction manager 612 performs one or more operations, as known to those skilled in the art, for processing the transactions that correspond to the issuer server 112. For example, the transaction manager 612 deducts the transaction amount from the first account of the first user 102 when the transaction is successfully completed. The transaction manager 612 may be configured to generate authorization responses indicating success or failure of processed transactions. The transaction manager 612 further generates credit or debit acknowledgements when the first account of the first user 102 is credited or debited, respectively.
The second memory 604 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, for storing the account profiles of various accounts that are maintained at the issuer server 112. Examples of the second memory 604 may include, but are not limited to, 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 issuer server 112, as described herein. In another embodiment, the second memory 604 may be realized in form of a database server or a cloud storage working in conjunction with the issuer server 112, 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 114 using one or more communication protocols. The second transceiver 606 receives various requests and messages from the authentication server 110. For example, the second transceiver 606 receives the verification requests from the authentication server 110 for verifying the users (for example, the first and second users 102 and 104). The second transceiver 606 further receives the transaction data from the authentication server 110 for processing the transactions. The second transceiver 606 transmits various requests and messages to the authentication server 110. For example, the second transceiver 606 transmits the acknowledgement, indicating the verification of the users (for example, the first and second users 102 and 104) to the authentication server 110. 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.
FIGS. 7A and 7B, collectively represent a flow chart 700 that illustrates an authentication method for a transaction, in accordance with an exemplary embodiment of the disclosure. The first user 102 may utilize the service application 202 running on the first user device 106 for initiating the transaction for electronically transferring the first amount from the first account of the first user 102 to the second account associated with the second user 104.
With reference to FIG. 7A, at step 702, the authentication server 110 may receive the authentication request from the first user device 106 based on the initiation of the transaction by the first user 102 at the first user device 106. At step 704, based on the received authentication request, the authentication server 110 generates the actuation command for actuating the first and second image-capturing devices 116a and 116b of the first user device 106. At step 706, the authentication server 110 communicates the actuation command to the first user device 106. Based on the actuation command, the first and second image-capturing devices 116a and 116b are actuated for capturing the first and second facial images 422 and 424 of the first and second users 102 and 104, respectively. The first and second image-capturing devices 116a and 116b may be actuated simultaneously or one after the other, without deviating from the scope of the disclosure.
At step 708, the authentication server 110 receives the first and second facial images 422 and 424 of the first and second users 102 and 104, respectively, from the first user device 106 for authentication. At step 710, the authentication server 110 determines whether a match for each of the first and second facial images 422 and 424 is available in the database 518. If at step 710, it is determined that no match is available for at least one of the first and second facial images 422 and 424 in the database 518, the authentication server 110 communicates a notification that the authentication has failed and the process stops. If at step 710, it is determined that a match for each of the first and second facial images 422 and 424 is available in the database 518, step 712 is performed.
At step 712, the authentication server 110 authenticates the first and second users 102 and 104. In other words, when a match for each of the first and second facial images 422 and 424 is available in the database 518, the first and second users 102 and 104 are authenticated successfully. At step 714, the authentication server 110 identifies the first and second accounts that are linked to the first and second facial images 422 and 424, respectively. At step 716, the authentication server 110 selects the common and generic payment modes from the first set of payment modes that is associated with the identified first account. At step 718, the authentication server 110 communicates the list of selected payment modes to the first user device 106 for user selection. The first user device 106 displays and presents the list of selected payment modes to the first user 102 for selection. The first user 102 may select one of the displayed payment modes for carrying out the transaction and enter the transaction amount of the transaction. The selected payment mode and the transaction amount of the transaction are collectively referred to as the transaction data.
With reference to FIG. 7B, at step 720, the authentication server 110 receives the transaction data from the first user device 106. At step 722, the authentication server 110 communicates the transaction data to the issuer server 112 for processing the transaction. The transaction is processed by the issuer server 112 as per the transaction data.
FIG. 8 represents a high-level flow chart 800 that illustrates an authentication method for a transaction, in accordance with an exemplary embodiment of the disclosure. At step 802, the authentication server 110, receives from the first user device 106, the authentication request for the transaction initiated by the first user 102 for electronically transferring the first amount from the first account of the first user 102 to the second account associated with the second user 104. At step 804, the authentication server 110 actuates, based on the authentication request, at least one of the first and second image-capturing devices 116a and 116b of the first user device 106 for capturing the first facial image 422 of the first user 102 and the second facial image 424 of the second user 104. At step 806, the authentication server 110 receives the first and second facial images 422 and 424 and the transaction data of the transaction from the first user device 106 over the communication network 114. At step 808, the authentication server 110 authenticates the first and second users 102 and 104 based on the received first and second facial images 422 and 424, respectively. The transaction is processed as per the transaction data, based on the authentication of the first and second users 102 and 104.
FIG. 9 is a block diagram that illustrates system architecture of a computer system 900, in accordance with an exemplary embodiment of the present disclosure. An exemplary embodiment of the present disclosure, or portions thereof, may be implemented as computer readable code on the computer system 900. In one example, the first and second user devices 106 and 108, the authentication server 110, and the issuer server 112 of FIG. 1 may be implemented in the computer system 900. Hardware, software, or any combination thereof may embody modules and components used to implement the methods of FIGS. 7A and 7B, and 8.
The computer system 900 includes a processor 902 that may be a special-purpose or a general-purpose processing device. The processor 902 may be a single processor, multiple processors, or combinations thereof. The processor 902 may have one or more processor cores. In one example, the processor 902 is an octa-core processor. The processor 902 may be connected to a communication infrastructure 904, such as a bus, message queue, multi-core message-passing scheme, and the like. The computer system 900 may further include a main memory 906 and a secondary memory 908. Examples of the main memory 906 may include RAM, ROM, and the like. The secondary memory 908 may include a hard disk drive 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 900 further includes an input/output (I/O) interface 910 and a communication interface 912. The I/O interface 910 includes various input and output devices that are configured to communicate with the processor 902. 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 912 may be configured to allow data to be transferred between the computer system 900 and various devices that are communicatively coupled to the computer system 900. Examples of the communication interface 912 may include a modem, a network interface, i.e., an Ethernet card, a communication port, and the like. Data transferred via the communication interface 912 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art. The signals may travel via a communication channel (not shown) which may be configured to transmit the signals to devices that are communicatively coupled to the computer system 900. Examples of the communication channel may include, but are not limited to, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, and the like.
A person having 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 digitally 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 by single or multiprocessor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.
Thus, technological improvements in the authentication server 110 enables the users (for example, the first and second users 102 and 104) to perform seamless and fast transactions. By utilizing facial recognition technology, the authentication server 110 simultaneously authenticates the first and second users 102 and 104 involved in the transaction. Thus, the processing time of the transaction is decreased. Once the first and second users 102 and 104 are authenticated, the first or second user 102 or 104 is not required to provide any further authentication information for the transaction. This increases the ease of operation for performing the transaction for the first user 102. The method and system of present disclosure offers a seamless user experience for carrying out transactions, which may encourage users to carry out more cashless transactions.
Techniques consistent with the present disclosure provide, among other features, systems and methods for authenticating users for 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.
Unless stated otherwise, terms such as “first” and “second” in claims 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.