Claims:CLAIMS:
I/We claim:

1. A method for performing multi-factor authentication for an e-commerce transaction, the method comprising:
providing, by a server system, a user interface on a child cardholder’s device to enable a child cardholder to enter a pre-assigned unique identifier wherein the child cardholder is provided a child card number based on a request from a parent cardholder possessing a parent card number and wherein the child card number is entered by the child cardholder on the child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder;
validating, by the server system, the unique identifier;
upon successful validation of the unique identifier, retrieving, by the server system, a contact information of the child cardholder associated with the unique identifier;
sending, by the server system, a One-time Password (OTP) to the associated contact information of the child cardholder, the OTP generated for performing multi-factor authentication; and
upon successful verification of the OTP entered by the child cardholder using the child cardholder’s device, processing, by the server system, the e-commerce transaction.

2. The method as claimed in claim 1, further comprising:
sending an authentication response of successfully performed multi-factor authentication via a merchant plug-in to a merchant server, the merchant server configured to send an authorization request to a payment server via an acquirer server.

3. The method as claimed in claim 2, wherein the server system is a payment server and wherein the method further comprises:
replacing the child card number with the parent card number, wherein the parent card number is provided by an issuer to the parent cardholder and wherein the child card number is generated by the payment server based on receiving a request to generate the child card number from a parent cardholder’s device.

4. The method as claimed in claim 3, wherein the unique identifier comprises a combination of a parent cardholder identifier and a child cardholder identifier, wherein the parent cardholder identifier is generated by the issuer and wherein the child cardholder identifier is generated by the parent cardholder.

5. The method as claimed in claim 2, wherein the server system is the issuer server and wherein the method further comprises:
receiving the parent card number and a transaction amount;
verifying the parent card number and the transaction amount;
upon successful verification, debiting the transaction amount from an issuer account of the parent cardholder;
sending a notification of debiting of the transaction amount to the acquirer server, the acquirer server configured to credit the transaction amount into a merchant account; and
processing completion of the e-commerce transaction upon sending a transaction status to the child cardholder’s device via the merchant plug-in.

6. The method as claimed in claim 2, wherein the server system is an access control server identified by a directory server using the child card number based on receiving a request from the merchant plug-in to verify if the access control server has participated for performing multi-factor authentication.

7. The method as claimed in claim 6, wherein the directory server comprises a list of one or more Bank Identifier Numbers (BINs), each of the one or more BINs stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more access control servers participating for performing multi-factor authentication.

8. The method as claimed in claim 6, further comprising:
receiving the contact information of the child cardholder associated to the unique identifier prior to processing the e-commerce transaction; and
storing the contact information of the child cardholder associated to the unique identifier.

9. The method as claimed in claim 1, wherein the contact information of the child cardholder comprises at least one of a mobile number and an email ID of the child cardholder.

10. A server system for performing multi-factor authentication for an e-commerce transaction, the server system comprising:
a communication interface;
a memory comprising executable instructions; and
a processor communicably coupled to the communication interface and configured to execute the instructions to cause the server system to at least:
provide a user interface on a child cardholder’s device to enable a child cardholder to enter a pre-assigned unique identifier wherein the child cardholder is provided a child card number based on a request from a parent cardholder possessing a parent card number and wherein the child card number is entered by the child cardholder on the child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder;
validate the unique identifier;
upon successful validation of the unique identifier, retrieve contact information of the child cardholder associated with the unique identifier;
send, via the communication interface, a One-time Password (OTP) to the associated contact information of the child cardholder, the OTP generated for performing multi-factor authentication; and
upon successful verification of the OTP entered by child cardholder using the child cardholder’s device, process the e-commerce transaction.

11. The server system as claimed in claim 10, wherein the server system is further caused to:
send an authentication response of successfully performed multi-factor authentication via a merchant plug-in to a merchant server, the merchant server configured to send an authorization request to a payment server via an acquirer server.

12. The server system as claimed in claim 11, wherein the server system is a payment server and wherein the server system is further caused to:
replace the child card number with the parent card number, wherein the parent card number is provided by an issuer to the parent cardholder and wherein the child card number is generated by the payment server based on receiving a request to generate the child card number from a parent cardholder’s device.

13. The server system as claimed in claim 12, wherein the unique identifier comprises a combination of a parent cardholder identifier and a child cardholder identifier, wherein the parent cardholder identifier is generated by the issuer and wherein the child cardholder identifier is generated by the parent cardholder.

14. The server system as claimed in claim 11, wherein the server system is the issuer server and wherein the server system is further caused to:
receive the parent card number and a transaction amount;
verify the parent card number and the transaction amount;
upon successful verification, debit the transaction amount from an issuer account of the parent cardholder;
send a notification of debiting of the transaction amount to the acquirer server, the acquirer server configured to credit the transaction amount into a merchant account; and
process completion of the e-commerce transaction upon sending a transaction status to the child cardholder’s device via the merchant plug-in.

15. The server system as claimed in claim 11, wherein the server system is an access control server identified by a directory server using the child card number based on receiving a request from the merchant plug-in to verify if the access control server has participated for performing multi-factor authentication.

16. The server system as claimed in claim 15, wherein the directory server comprises a list of one or more Bank Identifier Numbers (BINs), each of the one or more BINs stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more access control servers participating for performing multi-factor authentication.

17. The server system as claimed in claim 15, wherein the server system is further caused to:
receive the contact information of the child cardholder associated to the unique identifier prior to processing the e-commerce transaction; and
store the contact information of the child cardholder associated to the unique identifier.

18. The server system as claimed in claim 10, wherein the contact information of the child cardholder comprises at least one of a mobile number and an email ID of the child cardholder.

19. A directory server in a payment network for performing multi-factor authentication for an e-commerce transaction, the directory server comprising:
a communication module configured to receive a child card number along with a request to verify if an access control server has participated for performing multi-factor authentication wherein the child card number is provided to a child cardholder based on a request from a parent cardholder possessing a parent card number and wherein the child card number is entered by the child cardholder on a child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder;
a database comprising a list of one or more Bank Identifier Numbers (BINs), each of the one or more BINs stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more access control servers participating for performing multi-factor authentication;
a memory comprising executable instructions; and
a processing module communicably coupled to the communication module and the database, the processing module configured to execute the instructions to cause the directory server to at least:
verify if the access control server has participated for performing multi-factor authentication using a corresponding BIN extracted from the child card number;
upon successful verification, retrieve a corresponding URL stored against the corresponding BIN;
send the corresponding URL to the child cardholder’s device, wherein the URL is used by the access control server to provide a user interface on the child cardholder’s device to enable the child cardholder to enter a pre-assigned unique identifier and wherein the access control server sends a One-time Password (OTP) to a contact information of the child cardholder associated with the unique identifier for performing multi-factor authentication.

20. The directory server as claimed in claim 19, wherein the directory server is caused to:
send the corresponding URL to the child cardholder’s device via a merchant plug-in, the merchant plug-in configured to send the child card number along with the request to verify if the access control server has participated for performing multi-factor authentication. , Description:FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR PERFORMING MULTI-FACTOR AUTHENTICATION FOR AN E-COMMERCE TRANSACTION

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

METHODS AND SYSTEMS FOR PERFORMING MULTI-FACTOR AUTHENTICATION FOR AN E-COMMERCE TRANSACTION

TECHNICAL FIELD

[0001] The present disclosure relates to electronic payment transactions and, more particularly to, methods and systems for performing multi-factor authentication for delegated virtual card based e-commerce transaction.
BACKGROUND

[0002] Nowadays, many consumers use several banking cards, such as credit cards, debit cards, prepaid cards, etc., for performing financial transactions (e.g., payment transaction). The various banking cards are herein referred to as payment cards. Online purchases done using credit or debit cards are referred to as Card Not Present (CNP) transactions. Authentication refers to the consumer proving to an issuer bank that it is indeed him/her performing a transaction. CNP transactions can be particularly vulnerable to fraudulent activities because it is difficult for a merchant to verify whether the person buying a product using the payment card actually is authorized to use it. To avoid such risks, there exists a mandatory multi-factor authentication regulation in countries such as India for all e-commerce transactions. For example, during a CNP transaction along with the details available on the payment card, the second level of identification is needed e.g., a long-term password or a One-Time Password (OTP) for performing two-factor authentication. The banks typically leverage a Three-Domain (3-D) Secure messaging protocol to enable a consumer to authenticate himself with his card issuer by sending the OTP to the mobile number or the email ID which is registered with the payment card number of the consumer.
[0003] In scenarios, where a physical / real cardholder (hereinafter alternatively referred to as parent cardholder) wants another authorized person (hereinafter alternatively referred to as child cardholder) to process a payment transaction on-behalf of the parent cardholder, the parent cardholder is required to share the payment card details with the child cardholder to process the transaction. An example of such a scenario is a commercial transaction in a corporate entity, enterprise or any organization. The commercial transaction can be performed by an employee (an example of "child cardholder") who is authorized by the main authority (an example of "parent cardholder") of the corporate entity. During multi-factor authentication, the parent cardholder receives an OTP on his registered mobile number or the email ID. The parent cardholder also needs to share the OTP with the child cardholder for performing authentication. This is a time consuming and inconvenient process for both the cardholders. Further, the sharing of real card details with others brings risks of misuse of the payment card. Currently, there are several means available to digitize plastic cards into mobile phones, wearable devices etc., using technologies, such as tokenization, Card-on-File (COF) transactions, digital wallets and the like. The token / virtual card number may contain a 16-digit number, an expiry date and a Card Verification Value (CVV) which resemble the actual / real payment card information. Transactions performed using tokens are more secure as the actual card information is protected against theft and misuse.
[0004] For instance, there exists a platform that provides a facility to a parent cardholder to generate a token / virtual card number (hereinafter alternatively referred to as "child card number") for delegation to a child cardholder to process an on-behalf transaction. For example, an employee (i.e., a child cardholder / an authorized person) needs to make a purchase of office supplies. A customized child card number (e.g., one-time purchase limit) may be generated by his manager (i.e., a parent cardholder / a real cardholder) using the platform. The child card number then can be used by the employee on a merchant interface to make the on-behalf payment for purchasing the office supplies. However, in such scenarios, the multi-factor authentication cannot be performed because of the limitation of association of the contact information of the parent cardholder with the real card number. It means the OTP for performing multi-factor authentication would be sent to the mobile number of the manager. The authorized employee would not have access to the OTP and therefore would be unable to process the transaction.
[0005] Accordingly, there is a need for techniques that enable multi-factor authentication where the parent cardholder and the child cardholder are different and only the delegated child card number travels through various channels during the online payment transaction.
SUMMARY

[0006] Various embodiments of the present disclosure provide systems, methods, electronic devices and computer program products to enable multi-factor authentication for an e-commerce transaction especially for users such as, but not limited to, corporate or enterprise users.
[0007] In an embodiment, a method for performing multi-factor authentication for an e-commerce transaction is disclosed. The method includes providing, by a server system, a user interface on a child cardholder’s device to enable a child cardholder to enter a pre-assigned unique identifier. The child cardholder is provided a child card number based on a request from a parent cardholder possessing a parent card number. The child card number is entered by the child cardholder on the child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder. The method includes validating the unique identifier. Upon successful validation of the unique identifier, the method includes retrieving a contact information of the child cardholder associated with the unique identifier. The method further includes sending a One-time Password (OTP) to the associated contact information of the child cardholder. The OTP is generated for performing multi-factor authentication. Upon successful verification of the OTP entered by the child cardholder using the child cardholder’s device, the method includes processing the e-commerce transaction.
[0008] In another embodiment, a server system for performing multi-factor authentication for an e-commerce transaction is provided. The server system includes a communication interface. The server system includes a memory comprising executable instructions and a processor communicably coupled to the communication interface. The processor is configured to execute the instructions to cause the server system to at least provide a user interface on a child cardholder’s device to enable a child cardholder to enter a pre-assigned unique identifier. The child cardholder is provided a child card number based on a request from a parent cardholder possessing a parent card number. The child card number is entered by the child cardholder on the child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder. The server system is further caused to validate the unique identifier. Upon successful validation of the unique identifier, the server system is further caused to retrieve a contact information of the child cardholder associated with the unique identifier. The server system is further caused to send an OTP to the associated contact information of the child cardholder via the communication interface. The OTP is generated for performing multi-factor authentication. Upon successful verification of the OTP entered by the child cardholder using the child cardholder’s device, the server system is further caused to process the e-commerce transaction.
[0009] In yet another embodiment, a directory server in a payment network for performing multi-factor authentication for an e-commerce transaction is provided. The directory server includes a communication module configured to receive a child card number along with a request to verify if an access control server has participated for performing multi-factor authentication. The child card number is provided to a child cardholder based on a request from a parent cardholder possessing a parent card number. The child card number is entered by the child cardholder on the child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder. The directory server includes a database including a list of one or more Bank Identifier Numbers (BINs). Each of the one or more BINs is stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more access control servers participating for performing multi-factor authentication. The directory server includes a memory comprising executable instructions and a processing module communicably coupled to the communication interface and the database. The processing module is configured to execute the instructions to cause the directory server to at least verify if the access control server has participated for performing multi-factor authentication using a corresponding BIN extracted from the child card number. Upon successful verification, the directory server is further caused to retrieve a corresponding URL stored against the corresponding BIN. The directory server is further caused to send the corresponding URL to the child cardholder’s device. The URL is used by the access control server to provide a user interface on the child cardholder’s device to enable the child cardholder to enter a pre-assigned unique identifier. The access control server sends an OTP to a contact information of the child cardholder associated with the unique identifier for performing multi-factor authentication.

BRIEF DESCRIPTION OF THE FIGURES

[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0011] FIG. 1 illustrates an example representation of an environment, related to at least some example embodiments of the present disclosure;
[0012] FIG. 2 represents a list of unique identifiers associated with respective contact information of respective child cardholders, in accordance with an example embodiment;
[0013] FIG. 3 represents a sequence flow diagram representing verification of an access control server participated for performing multi-factor authentication, in accordance with an example embodiment;
[0014] FIG. 4 represents a sequence flow diagram representing multi-factor authentication performed by the access control server for an e-commerce transaction, in accordance with an example embodiment;
[0015] FIG. 5 represents a sequence flow diagram representing an authorization of a child card number for an e-commerce transaction, in accordance with an example embodiment;
[0016] FIG. 6 illustrates a flow diagram of a method for performing multi-factor authentication for an e-commerce transaction, in accordance with an example embodiment;
[0017] FIG. 7 is a simplified block diagram of a server system, in accordance with one embodiment of the present disclosure;
[0018] FIG. 8 is a simplified block diagram of a merchant server, in accordance with one embodiment of the present disclosure;
[0019] FIG. 9 is a simplified block diagram of an issuer server, in accordance with one embodiment of the present disclosure;
[0020] FIG. 10 is a simplified block diagram of an acquirer server, in accordance with one embodiment of the present disclosure;
[0021] FIG. 11 is a simplified block diagram of a payment server, in accordance with one embodiment of the present disclosure;
[0022] FIG. 12 is a simplified block diagram of a directory server, in accordance with one embodiment of the present disclosure;
[0023] FIG. 13 is a simplified block diagram of an access control server, in accordance with one embodiment of the present disclosure; and
[0024] FIG. 14 shows simplified block diagram of an electronic device capable of implementing at least some embodiments of the present disclosure.
[0025] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION

[0026] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0027] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” at various places in the specification is not necessarily all referring to the same embodiment, nor to separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0028] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0029] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by digital wallet or other payment application.
[0030] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard.
[0031] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be used to fund a financial transaction to a merchant or any such facility via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data (e.g., a digital token or a virtual account number) stored in a user device, where the data is associated with the payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0032] The term "multi-factor authentication", used throughout the description, refers to a security control that requires users to verify their identities by providing multiple pieces of evidence before gaining access to a device or an application. The user can prove he is who he claims to be by providing information only he knows, like a password or answers to challenge questions (e.g., a single-factor authentication), by entering a One-Time Password (OTP) (e.g., a two-factor authentication), and by providing a characteristic unique to who he is, such as a fingerprint, a retina scan, or a voice recognition (e.g., a three-factor authentication). Multi-factor authentication involves two of the factors or it could involve all three factors or many more factors. As per the Payment Card Industry Data Security Standard (PCI DSS), references to two-factor authentication are replaced with multi-factor authentication. However, organizations can use two of the three factors to be in PCI compliance.
[0033] The term "parent cardholder", used throughout the description, refers to a real / actual cardholder who possesses a real payment card that has a real card number provided by an issuer to which a contact information such as a registered mobile number and / or an email ID of the real cardholder are associated. The parent cardholder is an actual holder of a payment card account and may be referred as a primary account holder.
[0034] The term "child cardholder", used throughout the description, refers to an authorized virtual cardholder to make an on-behalf payment transaction using a child card number generated from a parent cardholder’s device. The child card number is an example of a virtual card number or a token provided to the child cardholder. The child cardholder is determined and authorized by the parent cardholder and the child cardholder does not have the ultimate liability to the card issuer for the purchases.
OVERVIEW

[0035] Various example embodiments of the present disclosure provide methods, systems, user devices and computer program products for performing multi-factor authentication for a delegated virtual card based e-commerce transaction for corporate / enterprise users, or any other use cases where authorized users of an organization or even a family can make e-commerce transactions.
[0036] In various example embodiments, the present disclosure provides a server system e.g., a payment server in a payment network configured to receive a request to generate a child card number from a parent cardholder’s device. A parent cardholder is a real cardholder who possesses a real card number provided by an issuer to which a contact information such as a registered mobile number and / or an email ID of the real cardholder are associated. The generated child card number is provided to a child cardholder to make payment transactions on behalf of the parent cardholder. The child cardholder is an authorized virtual cardholder to make on-behalf payment transactions using the child card number. The child card number is an example of a virtual card number or a token provided to the child cardholder. In an example embodiment, the parent cardholder is an authorized person e.g., a manager or a finance manager of a corporate and the child cardholder is an employee of the corporate. When the child cardholder uses the child card number on a merchant application provided by a merchant server to process an e-commerce payment transaction, multi-factor authentication process is initiated by a Merchant Plug-in (MPI) associated with the merchant server.
[0037] The MPI interacts with a directory server to verify if an Access Control Server (ACS) has participated for performing multi-factor authentication. The issuer needs to deploy an ACS to receive Three-Domain (3-D) Secure messages, process the messages, and authenticate the cardholder. The directory server includes a list of one or more Bank Identifier Numbers (BINs). Each of the one or more BINs is stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more ACSs participating / enrolled for performing multi-factor authentication. The directory server verifies if the ACS has participated for performing multi-factor authentication using a corresponding BIN extracted from the child card number. Upon successful verification, the directory server retrieves a corresponding URL stored against the corresponding BIN. The directory server sends the corresponding URL to the child cardholder’s device via the MPI.
[0038] The browser of the child cardholder’s device reads the URL and sends a request to load corresponding User Interfaces (UIs) to the identified ACS. Accordingly, the ACS provides a user interface on the child cardholder’s device to enable the child cardholder to enter a unique identifier. The unique identifier is pre-assigned to the child cardholder by the parent cardholder. The unique identifier includes a combination of a parent cardholder identifier and a child cardholder identifier. The parent cardholder identifier is generated by the issuer / card issuer and the child cardholder identifier is generated by the parent cardholder. For example, the corporate manager being the parent cardholder generates the unique identifier for a corporate employee being the child cardholder that is combination of a corporate ID provided by the issuer and an employee ID of the corporate employee generated by the corporate. The unique identifier is associated with a contact information of the child cardholder. The unique identifier and the contact information of the child cardholder are sent to the ACS prior to processing the e-commerce transaction. The ACS stores this information for performing multi-factor authentication later.
[0039] Once the child cardholder enters the unique identifier on the UI provided by the ACS, the ACS validates the unique identifier. Thereafter, the ACS retrieves the stored mobile number and / or the email ID of the child cardholder associated with the unique identifier. The ACS sends an OTP to the associated mobile number and / or the email ID of the child cardholder. Upon successful verification of the OTP entered by the child cardholder using the child cardholder’s device, the ACS sends a response of successful verification of the OTP via the MPI to the merchant server. The merchant server sends an authorization request to an acquirer server of the merchant. The acquirer server sends the authorization request to the payment server. The payment server replaces the child card number with the parent card number and sends the parent card number to the issuer server.
[0040] The issuer server is configured to verify the parent card number and a transaction amount to complete the authorization process. Upon successful verification of the parent card number, the payment server receives a notification from the issuer sever. The issuer server debits the transaction amount from an issuer account of the parent cardholder. The issuer server sends a notification of debiting of the transaction amount to the acquirer server which is configured to credit the transaction amount into a merchant account. The e-commerce transaction is completed upon sending a transaction status to the child cardholder’s device via the merchant plug-in. Various example embodiments of present disclosure are described hereinafter with reference to FIGS. 1 to 14.
[0041] FIG. 1 illustrates an example representation of an environment 100, in which at least some example embodiments of the present disclosure can be implemented. A parent cardholder 102 is shown using an electronic device 102a (e.g., a desktop computer 102a, also hereinafter referred to as a parent cardholder’s device 102a) on which a commercial payment application 102c is shown as running. Other examples of the electronic device 102a include, but are not limited to, a personal computer (PC), a mobile phone, a tablet device, a Personal Digital Assistant (PDA), a voice activated assistant, a Virtual Reality (VR) device, a smartphone and a laptop. A User Interface 102b (UI 102b) of the commercial payment application 102c is shown to display an information field 102d displaying text, ‘generate a child card number’. The parent cardholder 102 clicks a button 102e labelled ‘submit’ to submit the request of child card number generation on the commercial payment application 102c.
[0042] In one embodiment, the commercial payment application 102c is provided by a payment server 140 associated with a payment network 145. In one example embodiment, the parent cardholder 102 is an authorized person such as a finance manager of a corporate (hereinafter alternatively referred as "corporate manager" 102) who is provided a parent payment card / real payment card by a card issuer such as an issuer bank. A corresponding issuer server 135 is associated with a financial institution normally called as an "issuer bank" or "issuing bank" or simply "issuer", in which the parent cardholder 102 may have an account, which issues a payment card, such as a credit card or a debit card. The parent cardholder 102 can use the payment card details (e.g., the parent card number) associated with the payment card to tender payment for a purchase from a merchant.
[0043] The submission of the request by the parent cardholder 102 results in generation of a child card number / child account number for a delegated child cardholder such as the child cardholder 104 by the payment server 140. In one example embodiment, the child cardholder 104 is an employee of a corporate (hereinafter alternatively referred as "corporate employee 104") for whom the corporate manager 102 generates a child card number using the commercial payment application 102c. The corporate employee 104 uses the child card number for making purchases on behalf of the corporate manager 102. Alternatively, the child cardholder 104 may be a vendor or a supplier to whom the corporate manager 102 desires to make a payment using the child card number. Large corporates may need to process payments of a huge number of invoices every quarter. The commercial payment application 102c provides an automation platform to link the invoices to a delegated child card number that is automatically and randomly generated based on the request of the corporate manager 102 possessing the parent card number. The invoices linked to the child card number are passed to the merchant that has also registered to use the automation platform.
[0044] In one embodiment, generation of child card number is customizable. The parent cardholder 102 may be required to create a purchase request on the commercial payment application 102c using a UI (not shown) on which all the criteria for generating a child card number may be entered. Some non-exhaustive examples of the criteria include a supplier category, a supplier name, a transaction amount, a number of uses, a date, a data range, a type of purchase, a currency code, a child cardholder name, an associated email ID, a description of purchase, a merchant name based restriction, a merchant category code based restriction, an assignment of the child card number to a specific device, channel, merchant or geographic location, or a combination of these to restrict the transaction within that domain and the like. The purchase request also includes the underlying parent card information of the parent payment card to be linked for generation of a child card number. The payment server 140 is configured to generate a custom child card number from the purchase request and send it to the child cardholder 104 via the email ID provided by the parent cardholder 102 while making the purchase request.
[0045] In various embodiments, the child card number may be a child account number or a digital token or a virtual card number. In an example embodiment, the payment server 140 is configured to generate the child card number for any funding source of the parent cardholder 102 other than the parent payment card. The child card number values vary in format and may be cryptographically or non-cryptographically generated. Further, the child card number format may be a PAN-formatted replacement value based on a designated child card number Bank Identification Number (BIN) or child card number range. For example, the child card number may contain a replacement value for each of a sixteen-digit number, an expiry date (actually applicable for the validity of the child card number), a CVV, etc., of a physical / parent payment card of the parent cardholder 102 so as to use it at various merchant payment interfaces. Further, a single PAN may be mapped to multiple child card numbers for different scenarios. Also, in place of an account PAN of the parent cardholder 102, a 16-digit child card number may be generated such that the use of the number rather than a PAN minimizes the impact of account data compromise.
[0046] If compromised or stolen, the child card number reduces the likelihood of subsequent fraud since it has no value outside a specific device, merchant or acceptance channel. The generated child card number and the original PAN it maps to are stored securely in a database of the payment server 140 and the mapping is used during the authorization process. The payment server 140 is further configured to continually manage the child card number through suspension, deletions, updates, etc.
[0047] In one embodiment, the child cardholder 104 is enabled to use the child card number on an affiliated merchant application 104c provided by a merchant server 115. The merchant application 104c is an example of an e-commerce application running on an electronic device 104a (e.g., a desktop computer 104a, also hereinafter alternatively referred to as "child cardholder’s device 104a") of the child cardholder 104. Other examples of the electronic device 104a include, but are not limited to, a personal computer (PC), a mobile phone, a tablet device, a Personal Digital Assistant (PDA), a voice activated assistant, a virtual reality (VR) device, a smartphone and a laptop. A UI 104b of the merchant application 104c is shown to display a checkout page (an example of a merchant payment interface for online payment transactions).
[0048] A payment method of pay using cards is selected by the child cardholder 104 for initiating processing of the on-behalf e-commerce transaction. The child cardholder 104 is asked to enter payment card details 104d. Examples of the payment card details 104d include a payment card number (e.g., xxxx xxxx xxxx xxxx where 'x' is an integral number) of the payment card, expiry date (e.g., MM/YYYY, month and year of expiry), Card Verification Value (CVV) number (e.g., *** where * is an integral number) and the like. Alternatively, the payment card details 104d may include information such as cardholder's payment account number, or any identification number associated with the payment card. The child cardholder 104 enters the child card number as the payment card details 104d on the merchant application 104c. The child cardholder 104 clicks a button 104e labelled ‘submit’ to submit the child card number to initiate the processing of the e-commerce transaction.
[0049] As the child card number is generated on the fly by the parent cardholder 102 using the commercial payment application 102c, there is no registration of the child card number to the issuer. Therefore, corresponding contact information of the child cardholder 104 is not available with the issuer to send an OTP for performing multi-factor authentication. In such scenario, the corporate manager 102 is unable to use the platform provided by the payment server 140 and has to opt for existing payment clearance methods such as net banking for the merchants / suppliers. The clearance amount is usually substantial for the corporate. Also, the net banking payment method has per day amount clearance limit regulations. Therefore, even if the corporate manager 102 possesses a corporate card (i.e., the parent payment card), he is unable to utilize various benefits of the platform because of the inability to perform multi-factor authentication.
[0050] Various embodiments of the present disclosure provide mechanisms such that multi-factor authentication is enabled / performed for delegated child card number based e-commerce transaction. In one embodiment, the merchant application 104c sends the child card number to a Merchant Plug-In (MPI) 110. The MPI 110 is an ecommerce software installed on the merchant server 115. The MPI 110 may be provided by a third-party developer. The MPI 110 communicates directly with the card issuers’ servers to identify if the cardholder's account number is enrolled for 3-D Secure. The MPI 110 also interacts with a directory server 120 in the payment network 145 to verify if an access control server (e.g., the access control server (ACS) 125, hereinafter alternatively referred to as "ACS 125") has participated for performing multi-factor authentication.
[0051] In the 3-D Secure messaging protocol, the ACS 125 is installed in the issuer domain (banks). Each card issuer is required to maintain an ACS which is used to support cardholder authentication. In one embodiment, the ACS 125 is Payment Card Industry (PCI) compliant. The ACS 125 may be deployed by the issuer associated with the issuer server 135. Alternatively, the issuer may outsource the ACS 125 to a third-party developer.
[0052] The directory server 120 identifies the ACS 125 enrolled for performing multi-factor authentication using a corresponding Bank Identifier Number (BIN). Once identified, the ACS 125 provides a UI on the child cardholder’s device 104a to enable the child cardholder 104 to enter a unique identifier pre-assigned to the child cardholder 104. In at least one embodiment, the ACS 125 sends a One-time Password (OTP) to a mobile number and / or an email ID of the child cardholder 104 associated with the unique identifier for performing multi-factor authentication after validating the unique identifier entered by the child cardholder 104. Apart from the OTP, the ACS 125 is capable of authenticating a static password, a combination of static and dynamic password, an ID card authentication and the like.
[0053] In a non-limiting example, the process of multi-factor authentication and authorization of the child card number for completion of the e-commerce payment transaction is processed by a combination of the merchant server 115, the directory server 120, the ACS 125, an acquirer server 130, the issuer server 135, and the payment server 140. In one embodiment, the payment server 140 and the directory server 120 are associated with the payment network 145. To accept payment, the merchant will first establish an account with a financial institution that is part of the financial payment system. This financial institution is usually called the “merchant bank” or the “acquiring bank” or “acquirer bank” or simply “acquirer”. The acquirer server 130 is associated with the acquirer bank. In one embodiment, the acquirer server 130 initiates the authorization process by sending the child card number to the payment server 140.
[0054] Using the payment network 145, the computers of the acquirer bank / the acquirer server 130 or a merchant computer will communicate with the computers of the issuer / the issuer server 135 to determine whether the customer’s account (i.e., the parent cardholder 102’s account) is in good standing and whether the purchase is covered by the customer’s available account balance. Based on these determinations, authorization of the payment transaction is declined or accepted. When the authorization is accepted, the available balance of the customer’s account is decreased. According to a process of one payment network operator, a charge is not posted immediately to the customer’s account as a merchant will not charge, or “capture,” a transaction amount until goods are shipped or services are delivered. When the merchant ships or delivers the goods or services, the merchant captures the transaction amount by, for example, appropriate data entry procedures on the merchant application. If the customer cancels a transaction before it is captured, a “void” is generated. If the customer returns goods after the transaction has been captured, a “credit” is generated.
[0055] After a transaction is captured, the transaction is settled between the merchant, the acquirer and the issuer. Settlement refers to the transfer of financial data or funds between the merchant's account, the acquirer, and the issuer, related to the transaction. Transactions may be captured and accumulated into a “batch”, which is settled as a group.
[0056] The electronic device 102a, the electronic device 104a, the issuer server 135, the acquirer server 130, the merchant server 115, the payment server 140, the directory server 120, and the ACS 125 communicate with one another using a communication network 150. Examples of the network 150 may include any type of wired network, wireless network, or a combination of wired and wireless networks. A wireless network may be a wireless local area network (“WLAN”), a wireless wide area network (“WWAN”), or any other type of wireless network now known or later developed. Additionally, the network 150 may be or include the Internet, intranets, extranets, microwave networks, satellite communications, cellular systems, personal communication services (“PCS”), infrared communications, global area networks, or other suitable networks, etc., or any combination of two or more such networks.
[0057] In existing (conventional) Business to Business (B2B) payment transaction methods (i.e., not in accordance with the present disclosure), corporates are not able to use the on-behalf payment solution because the OTP based multi-factor authentication at the merchant’s / employee’s end is not possible as the parent card number to which the contact information is associated is never exposed to the employee / merchant who is performing the transaction. In contrast to the existing B2B payment transaction methods, by using the embodiments of the present disclosure, the contact information of the child cardholder 104 is associated with a unique identifier generated by the parent cardholder 102 and sent to the ACS 125 in advance. Therefore, the enablement of multi-factor authentication for making on-behalf transactions, not only digitizes the commercial payment sector, but also frees up capital for corporates by enabling credit payments to their merchants. Some non-exhaustive example embodiments of completing child card number based online payment transactions by performing multi-factor authentication are described with reference to the following description, particularly with reference to FIG. 2 to FIG. 5.
[0058] FIG. 2 represents a list 200 of unique identifiers associated with contact information of respective child cardholders, in accordance with an example embodiment. The list 200 includes a plurality of columns such as a name 205, a unique identifier 210, a mobile number 215, and an email ID 220. A row 202a in the list 200 is shown to include corresponding information of respective child cardholder. For example, a child cardholder named ‘John’ is assigned a unique identifier ‘ABC123’ associated with a mobile number ‘9849123456’ and an email ID ‘John@example1.com’ in the row 202a. Accordingly, the rows 202b and 202c include information of subsequent authorized child cardholders assigned with the unique identifiers associated with the contact information of the child cardholders.
[0059] In at least one embodiment, the unique identifier is generated and assigned to the child cardholder by the parent cardholder. In one example embodiment, the unique identifier is combination of a parent cardholder identifier and a child cardholder identifier. The parent cardholder identifier is generated by the issuer and the child cardholder identifier is generated by the parent cardholder. For example, the unique identifier may be a combination of a corporate ID (defined by the issuer) and an employee ID (defined by the corporate) for the corporate employee 104 of FIG. 1. For instance, the unique identifier ‘DEF456’ represented in the row 202b may be a combination of ‘DEF’ being a parent cardholder identifier (e.g., the corporate ID) and ‘456’ being a child cardholder identifier (e.g., the employee ID). Alternatively, the unique identifier ‘DEF329’ (not shown) may be a combination of ‘DEF’ being the same parent cardholder identifier (e.g., the corporate ID) and ‘329’ being a different child cardholder identifier (e.g., another employee ID). The mobile number may be a personal mobile number of the child cardholder or a corporate provided mobile number. Similarly, the email ID may also be a personal email ID or the corporate email ID. Also, the email ID can be a group email ID for a supplier.
[0060] Further, the list 200 is shared in advance by the parent cardholder with the ACS 125 for using in future during multi-factor authentication. In one example embodiment, the list 200 may be transmitted to the ACS 125 via an email. Alternatively, the list 200 may be uploaded through a Universal Resource Locator (URL) link provided by the ACS 125. Additionally, the list 200 may be transferred using Secure File Transfer Protocol (SFTP). For example, login IDs may be created for project team members of the stakeholders of the corporate using which the list 200 is transferred using SFTP. In an example embodiment, a project team member may be aware that these are the authorized employees who can make purchases on his behalf or are the authorized persons who can receive payments from him for good and services delivered from the list 200 at the time of requesting the child card number, although the project team member may not be able to associate the child card number to a specific authorized employee at the point of origination of the consumption.
[0061] FIG. 3 represents a sequence flow diagram 300 representing verification of an access control server participated for performing multi-factor authentication, in accordance with an example embodiment. As explained with reference to FIG. 1, the payment server 140 is configured to generate a child card number and send the child card number to a registered email ID of the child cardholder 104.
[0062] At 305, the child cardholder 104 enters the child card number using the merchant application 104c running on the electronic device 104a to process an on-behalf payment transaction. The merchant application 104c can be a merchant website, mobile or desktop applications, or third-party websites or applications using which the consumer/user may purchase goods or services from a remote location.
[0063] At 310, the merchant application 104c running on the electronic device 104a sends the child card number entered by the child cardholder 104 to the MPI 110.
[0064] At 315, the MPI 110 sends a verification request along with the child card number to the directory server 120 to verify if the ACS 125 has participated for performing multi-factor authentication. The first step in the authentication process is to validate that the cardholder account number is part of an issuer’s card range, which is participating in 3-D Secure. After determining that a cardholder is enrolled to participate in 3-D Secure, the actual process of authentication is performed for each online purchase. The Verification Request/Response (VEReq/VERes) messages are sent from the MPI 110 to the directory server 120 to check card range eligibility. The directory server 120 includes a list of Bank Identifier Numbers (BINs). A BIN, in an example, is the initial four to six numbers that appear on a credit card. The BIN uniquely identifies the institution issuing the card. The BIN is key in the process of matching transactions to the issuer of the charged card. In at least one embodiment, each BIN is stored against each of one or more corresponding URLs of each of one or more ACSs participating for performing multi-factor authentication.
[0065] At 320, the directory server 120 extracts corresponding BIN from the child card number. At 325, the directory server 120 verifies if the ACS 125 has enrolled for performing multi-factor authentication using the BIN. Upon successful verification, at 330, the directory server 120 retrieves the corresponding URL of the ACS 125.
[0066] At 335, the directory server 120 sends the corresponding URL to the MPI 110. At 340, the MPI 110 sends the URL to the child cardholder’s device 104a. In one embodiment, the Payer Authentication Request/Response (PAReq/PARes) messages are sent from the MPI 110 to the ACS 125 to initiate the actual authentication. At 345, the browser of the child cardholder’s device 104a reads the URL. The process completes at 350.
[0067] FIG. 4 represents a sequence flow diagram 400 representing multi-factor authentication performed by the access control server for an e-commerce transaction, in accordance with an example embodiment. As explained with reference to FIG. 3, once the browser of the child cardholder’s device 104a reads the URL, the browser sends a request to load corresponding User Interfaces (UIs) to the ACS 125.
[0068] At 405, the ACS 125 provides a corresponding UI on the child cardholder’s device 104a to enable the child cardholder 104 to enter a unique identifier pre-assigned to the child cardholder 104.
[0069] At 410, the child cardholder 104 enters the pre-assigned unique identifier on the electronic device 104a using the UI. As explained with reference to FIG. 2, the unique identifier is generated and assigned to the child cardholder 104 by the parent cardholder 102. Further, the list that includes the associated mobile number and the email ID of the child cardholder 104 is shared in advance by the parent cardholder 102 with the ACS 125.
[0070] At 415, the unique identifier is received by the ACS 125 from the electronic device 104a. At 420, the ACS 125 validates the unique identifier by matching with the pre-received and stored unique identifier in a database.
[0071] Upon successful validation, at 425, the ACS 125 retrieves a contact information of the child cardholder 104 associated with the unique identifier from the database. For example, the mobile number and the email ID of the child cardholder 104 may be retrieved.
[0072] At 430, the ACS 125 sends an OTP to the contact information of the child cardholder 104 associated with the unique identifier. For example, the child cardholder 104 may have logged in his email via a browser running on the desktop computer 104a on which he may be able to receive the email and access the OTP. Alternatively, if the child cardholder 104 is checking out from a mobile application of a merchant using his smartphone, he may be able to access the OTP sent from the ACS 125 in the SMS application and / or the email application present in the smartphone.
[0073] At 435, the OTP is entered on a corresponding UI displayed on the electronic device 104a by the child cardholder 104. At 440, the OTP is received by the ACS 125. At 445, the ACS 125 validates the OTP entered by the child cardholder 104 by matching with the OTP that was sent.
[0074] Upon successful validation, at 450, the ACS 125 sends a digitally signed authentication response of successfully performed multi-factor authentication to the MPI 110. In one embodiment, the response includes Accountholder Authentication Value (AAV) generated by the ACS 125 to indicate a proof of a fully authenticated transaction. At 455, the MPI 110 verifies the digital signatures and initiates an authorization of the child card number. The multi-factor authentication process completes at 460.
[0075] FIG. 5 represents a sequence flow diagram 500 representing an authorization of a child card number for an e-commerce transaction, in accordance with an example embodiment. Authorization is the verification by the issuer of the validity of the card details provided by the cardholder and consent to the charge based on internal rules (ecommerce allowed, acquiring country allowed, funds available, etc.).
[0076] At 505, the MPI 110 sends an authorization request to the acquirer server 130 of the merchant. After cardholder authentication is complete, the merchant is required to pass the corresponding AAV to the acquirer server 130 within the authorization message. AAV is generally populated in data element (DE) 48 in an authorization log. AAV is later passed from the acquirer server 130 to the issuer server 135 as part of the authorization message. When received by the issuer server 135, the AAV is validated as part of authorization request processing. In one example embodiment, the authorization request also includes a Service Level Indicator (SLI) for a fully authenticated transaction. According to a process of one payment network operator, the SLI values for e-commerce transactions is 212, last two digits of which determine that it is a fully authenticated transaction.
[0077] At 510, the acquirer server 130 sends the authorization request to the payment server 140. As explained with reference to FIG. 1, the child card number is generated by the payment server 140 based on receiving the request from the parent cardholder 102 for use by the child cardholder 104. Therefore, during the authorization process, the acquirer server 130 needs to send the authorization request to the payment server 140 instead of directly sending the request to the issuer server 135 because the issuer server 135 would not be capable of authorizing the child card number. The acquirer server 130 may also send a transaction amount and AAV to the payment server 140 for validation. The acquirer server 130 also determines the acquirer account of the merchant and sends the acquirer account details to the payment server 140.
[0078] At 515, the payment server 140 replaces the child card number with the parent card number. Further, the payment server 140 identifies the merchant using the acquirer details received from the acquirer server 130 for processing the payment transaction after successful authorization. The payment server 140 further validates if the requested payment transaction is in line with any transaction limitations or restrictions for the use of the child card number as stored in the database of the payment server 140. If any of the validations fails, the payment server 140 rejects the transaction and notifies the acquirer server 130 accordingly. In an embodiment, the payment server 140 is configured to store the child card number and the associated payment credentials, such as the card information and the like in a cloud storage.
[0079] At 520, the payment server 140 sends the parent card number to the issuer server 135 for verification. The transaction amount and AAV are also sent to the issuer server 135 for authorization. At 525, the issuer server 135 performs authorization of the parent card number and transaction amount by verifying the card information of the parent card, available balance amount in the parent cardholder’s account against the received transaction amount, issuer account information and the like. Some non-exhaustive examples of the issuer account information include Bank Identifier Code (BIC), account number, payment card number and the like.
[0080] At 530, the issuer server 135 notifies the payment server 140 of the successful authorization of the parent card number, the parent cardholder 102 and the transaction amount. At 535, the issuer server 135 debits the transaction amount from the parent cardholder’s account. At 540, the issuer server 135 sends a notification of debiting of the transaction amount to the acquirer server 130 via the payment network 145. At 545, the acquirer server 130 credits the transaction amount in the merchant account. At 550, the acquirer server 130 sends the transaction status to the MPI 110. The transaction status may include successful, failure or pending. At 555, the MPI 110 sends the transaction status on the electronic device 104a via the merchant application 104c. The transaction process completes at operation 560.
[0081] Thus, a payment transaction flow using the child card number, as explained collectively with reference to FIG. 2 to FIG. 5, with enablement of multi-factor authentication provides benefits to the corporates to perform e-commerce based transactions by delegating the child card numbers to the authorized employees. The unique child card number is created for each payment transaction and is mapped to the parent card number. The parent card number is neither exposed to the child cardholder, nor to the merchant where the transaction is being performed. Since, only the child card number flows through the various channels, it prevents misuse of the parent card information. The child card number is mapped to the parent card number during the authorization processing. Thus, various embodiments of the present disclosure are aimed at simplifying B2B payments by introduction of a robust child card number based payment solution that offers enhanced efficiency, control and security for the corporate while easing the process of large corporate payments.
[0082] Although various embodiments of the present disclosure are explained with an example of B2B payment and the parent cardholder 102, and child cardholder 104 are referred as the corporate manager 102 and the corporate employee 104 respectively, the performance of multi-factor authentication may be enabled for any e-commerce transaction where the parent cardholder and the child cardholder are two different persons having any of a parent-child, a primary-secondary, or a principal-agent relationship without deviating from the scope of the disclosure. For example, the embodiments of the disclosure are capable of being used for parental control of card spending by the children. In such a scenario, the parent cardholder being one of a parent / a mother possessing a real payment card may generate a virtual card number with limited use or limited transaction amount for the child so as to limit when, where and how the money is spent by the child. The mother may also provide the unique identifier to the child for enabling multi-factor authentication process while the child gets to use the customized virtual card number for e-commerce transactions.
[0083] FIG. 6 illustrates a flow diagram of a method 600 for performing multi-factor authentication for an e-commerce transaction, in accordance with an example embodiment. More specifically, the method 600 for performing multi-factor authentication for an on-behalf e-commerce transaction by an authorized child cardholder provided with a child card number is disclosed. The method 600 depicted in the flow diagram may be executed by, for example, the at least one server system such as the acquirer server 130, the issuer server 135, the merchant server 115, the directory server 120, the ACS 125 and the payment server 140 explained with reference to FIG. 1. Operations of the method 600, and combinations of operation in the method 600, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 600 are described herein with help of the server systems 130, 135, 120, 125, 115 or 140. It is noted that the operations of the method 600 can be described and/or practiced by using a system other than these server systems. The method 600 starts at operation 602.
[0084] At 602, the method 600 includes providing, by a server system, a user interface on a child cardholder’s device to enable a child cardholder to enter a pre-assigned unique identifier. The child cardholder is provided a child card number based on a request from a parent cardholder possessing a parent card number. The child card number is entered by the child cardholder on the child cardholder’s device to initiate processing of an e-commerce transaction on behalf of the parent cardholder. In one embodiment, the server system is an access control server identified by a directory server using the child card number based on receiving a request from a merchant plug-in to verify if the access control server has participated for performing multi-factor authentication.
[0085] At 604, the method 600 includes, validating, by the server system, the unique identifier. The unique identifier includes a combination of a parent cardholder identifier and a child cardholder identifier. The parent cardholder identifier is generated by the issuer and the child cardholder identifier is generated by the parent cardholder.
[0086] Upon successful validation of the unique identifier, at 606, the method 600 includes retrieving, by the server system, a contact information of the child cardholder associated with the unique identifier. The contact information of the child cardholder includes at least one of a mobile number and an email ID of the child cardholder. The contact information of the child cardholder associated to the unique identifier is received by the access control server prior to processing the e-commerce transaction.
[0087] At 608, the method 600 includes sending, by the server system, an OTP to the associated contact information of the child cardholder. The OTP is generated for performing multi-factor authentication.
[0088] Upon successful verification of the OTP entered by the child cardholder using the child cardholder’s device, at 610, the method 600 includes processing, by the server system, the e-commerce transaction. The processing of the e-commerce transaction includes an authorization of the child card number and upon successful authorization, completing the e-commerce transaction by sending a transaction status to the child cardholder’s device via the merchant plug-in. The method 600 ends at operation 610.
[0089] FIG. 7 is a simplified block diagram of a server system 700, in accordance with one embodiment of the present disclosure. Examples of the server system 700 include, but are not limited to, the acquirer server 130, the issuer server 135, the merchant server 115, the directory server 120, the access control server 125, and the payment server 140. The server system 700 includes a computer system 705 and a database 710.
[0090] The computer system 705 includes at least one processor 715 for executing instructions. Instructions may be stored in, for example, but not limited to, a memory 720. The processor 715 may include one or more processing units (e.g., in a multi-core configuration). The processor 715 is operatively coupled to a communication interface 725 such that the computer system 705 is capable of communicating with a remote device such as a parent cardholder’s device 735 (e.g., the electronic device 102a) or a child cardholder’s device 740 (e.g., the electronic device 104a) or communicating with any entity within the payment network 145.
[0091] The processor 715 may also be operatively coupled to the database 710. The database 710 is any computer-operated hardware suitable for storing and/or retrieving data, such as, but not limited to, transaction data generated as part of sales activities conducted over the bankcard network including data relating to merchants, account holders or customers, and purchases. The database 710 may also store information related to a plurality of users’ payment accounts. Each user account data includes at least one of a user name, a user address, an account number, a contact information, PIN, and other account identifiers. The database 710 may also store device identifiers, platform IDs of the users, parent card numbers and the child card numbers.
[0092] The database 710 may also store a merchant identifier that identifies each merchant registered to use the payment network 145, and instructions for settling transactions including merchant bank account information (e.g., a plurality of payment accounts related to the merchant interfaces associated with merchants). The database 710 may further include issuer account information, BINs, URLs of the access control servers etc. The database 710 may also include unique identifiers pre-assigned to the child cardholders. The database 710 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 710 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[0093] In some embodiments, the database 710 is integrated within the computer system 705. For example, the computer system 705 may include one or more hard disk drives as the database 710. In other embodiments, the database 710 is external to the computer system 705 and may be accessed by the computer system 705 using a storage interface 730. The storage interface 730 is any component capable of providing the processor 715 with access to the database 710. The storage interface 730 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 715 with access to the database 710.
[0094] The processor 715 is configured to generate a child card number based on a request received from the parent cardholder’s device 735 via the communication interface 725. The processor 715 is configured to identify an Access Control Server (ACS) participating for multi-factor authentication using the child card number. The corresponding URL of the identified ACS is retrieved from the database 710 by the processor 715. The processor 715 is configured to provide a user interface on the child cardholder’s device 740 to enable a child cardholder to enter the pre-assigned unique identifier upon receiving a request via the communication interface 725. The request is generated based on the child card number being entered by the child cardholder on the child cardholder’s device 740 to initiate processing of an e-commerce transaction on behalf of the parent cardholder. The processor 715 is configured to validate the pre-assigned unique identifier by matching with a respective unique identifier stored in the database 710. The processor 715 is configured to send a One-time Password (OTP) to the associated contact information of the child cardholder for performing multi-factor authentication. The contact information is associated with the unique identifier and stored in the database 710.
[0095] Further, the processor 715 is configured to replace the child card number with the parent card number for authorization purposes. The authorization of the payment card information of the parent card number may also be performed by the processor 715 by validating the payment card information of the parent card using the associated card information stored in the database 710. The processor 715 is further configured to approve the transaction amount by verifying against the available balance in the issuer account of the parent cardholder, as stored in the database 710. In an embodiment, the processor 715 may be configured to notify the child cardholder’s device 740 of the transaction status via the communication interface 725.
[0096] FIG. 8 is a simplified block diagram of a merchant server 800, in accordance with one embodiment of the present disclosure. The merchant server 800 is an example of the merchant server 115 of FIG. 1. The merchant server 800 provides mobile and web merchant applications / e-commerce applications to provide its registered users to purchase goods and services from remote locations by making card-less payments. The merchant server 800 includes at least one processing module 805 communicably coupled to a communication interface 810, at least one memory 815 and a Merchant Plug-In (MPI) 825. In at least one embodiment, the merchant server 800 may be accessible to remote devices, such as a remote device 830, through the network 150 or the payment network 145.
[0097] The processing module 805 is capable of executing the stored machine executable instructions of a merchant application 820 (e.g., the merchant application 104c of FIG. 1) in the memory 815 or within the processing module 805 or any storage location accessible to the processing module 805. The communication interface 810 is configured to cause display of user interfaces on the remote device 830 (e.g., the parent cardholder’s device 735 or the child cardholder’s device 740). Via the merchant application 820, the processing module 805 is configured to provide a plurality of payment methods to the consumer for performing e-commerce transaction. Some non-exhaustive examples of the plurality of payment methods include payment using payment cards, digital tokens / child card numbers, net banking, wallet applications etc.
[0098] The MPI 825 is an ecommerce software module installed on the merchant server 800. The MPI 825 assists 3-D Secure verifications to help prevent credit card fraud. When a consumer begins an online checkout process, the MPI 825 identifies the credit card account number the consumer has entered and contacts the card issuer for authorization. The MPI 825 handles the passing of information from the consumer to the merchant's platform and to the credit card issuer and then back again, making a three-point system of checks and balances to prevent fraud.
[0099] In one embodiment, the processing module 805 receives the child card number entered by the child cardholder on the merchant application 820 to initiate processing of an on-behalf e-commerce transaction. The processing module 805, in conjunction with the MPI 825, sends the virtual card number and a request to verify if the ACS has participated for performing multi-factor authentication to a directory server of the payment network. The processing module 805 receives a digitally signed authentication response of successfully performed multi-factor authentication from the ACS via the MPI 825. The processing module 805 verifies the digital signatures of the authentication response. The processing module 805 also sends the virtual card number to an acquirer server associated with an acquirer of the merchant to initiate the authorization process.
[00100] FIG. 9 is a simplified block diagram of an issuer server 900, in accordance with one embodiment of the present disclosure. The issuer server 900 is an example of the issuer server 135 of FIG. 1, or may be embodied in the issuer server 135. The issuer server 900 is associated with an issuer bank / issuer, in which a user such as a parent cardholder may have an account. The issuer server 900 includes a processing module 905 operatively coupled to a storage module 910, an authorization module 915, and a communication module 920. The components of the issuer server 900 provided herein may not be exhaustive, and that the issuer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 900 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00101] The storage module 910 is configured to store machine executable instructions to be accessed by the processing module 905. Additionally, the storage module 910 stores information related to, contact information of the user (e.g., the parent cardholder 102 of FIG. 1), identification information of the user, bank account number, BICs, payment card details, internet banking information, PIN, mobile personal identification number (MPIN) for mobile banking and the like. The PIN is a four-digit identification code issued by the issuer bank of the user while registering for electronic payment transactions or while issuing the payment card to the user. For example, the PIN may be issued for swipe based transactions, mobile banking, internet banking, and the like. The PIN is needed to be verified for authentication of the user’s identity and association with the issuer bank to process the payment transaction. This information is retrieved by the processing module 905 for cross-verification during payment transactions.
[00102] The processing module 905, in conjunction with the authorization module 915, is configured to validate the payment card information of the parent card possessed by the parent cardholder as received from the payment server 140 via the communication module 920. Additionally, the processing module 905 is configured to verify the PIN (e.g., whether the four-digit numeric code matches the PIN issued by the issuer), the sufficient funds in the issuer account and the like. The processing module 905 is further configured to validate Accountholder Authentication Value (AAV) as part of authorization request processing. Upon successful authorization of the payment card information and the cardholder only, the payment transaction is processed further by the processing module 905 by debiting the transaction amount from the issuer account of the user.
[00103] The processing module 905 is further configured to communicate with one or more remote devices such as a remote device 925 using the communication module 920 over the network 150 or the payment network 145 of FIG. 1. The examples of the remote device 925 include, the payment server 140, the acquirer server 130, the merchant server 800, other computing systems of issuer and the payment network 145 and the like. The communication module 920 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. In one embodiment, the issuer server 900 is configured to include an ACS module (not shown) to perform multi-factor authentication. In another embodiment, the ACS is a separate entity from the issuer server 900.
[00104] FIG. 10 is a simplified block diagram of an acquirer server 1000, in accordance with one embodiment of the present disclosure. The acquirer server 1000 is associated with the acquirer of a merchant where the merchant has established an account to accept payment performed using the child card number. The acquirer server 1000 is an example of the acquirer server 130 of FIG. 1, or may be embodied in the acquirer server 130. The acquirer server 1000 includes a processing module 1005 communicably coupled to a merchant database 1010 and a communication module 1015. The components of the acquirer server 1000 provided herein may not be exhaustive, and that the acquirer server 1000 may include more or fewer components than those depicted in FIG. 10. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 1000 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00105] The merchant database 1010 includes data related to merchant, such as, but not limited to, a merchant primary account number (PAN), a merchant name, a merchant category code (MCC), a merchant city, a merchant postal code, a merchant brand name, a merchant ID and the like. The processing module 1005 is configured to use the merchant ID to identify the merchant during the normal processing of payment transactions, adjustments, chargebacks, end-of-month fees and so forth. The merchant ID is different from other merchant account numbers, particularly from those that identify merchants to the equipments (e.g., the POS terminals or any other merchant electronic devices / interfaces) they use for processing transactions. A merchant with a single merchant processing account number may use several terminals at one location, resulting in one merchant ID and several Terminal Identification numbers (TIDs). The processing module 1005 may be configured to store and update such merchant information in the merchant database 1010 for later retrieval.
[00106] In an embodiment, the communication module 1015 is capable of facilitating operative communication with a remote device 1020 (e.g., the issuer server 900, the merchant server 800, and/or the payment server 140) using API calls. The communication may be achieved over the network 150. For example, the processing module 1005 may receive the child card number and the transaction amount from the merchant server 800 using the communication module 1015. Further, the processing module 1005 is configured to receive the debited transaction amount from the payment server 140 or the issuer server 135 (or the issuer server 900) using the communication module 1015. Thereafter, the processing module 1005 may retrieve merchant PAN from the merchant database 1010 to credit the transaction amount in the acquirer account of the merchant. Further, in an example embodiment, the processing module 1005 may be configured to send the transaction status to a merchant device of the merchant and the child cardholder’s device 740.
[00107] FIG. 11 is a simplified block diagram of a payment server 1100, in accordance with one embodiment of the present disclosure. The payment server 1100 may correspond to the payment server 140 of FIG. 1. As explained with reference to FIG. 1, the payment server 140 is associated with a payment network 145. The payment network 145 may be used by the merchant server 800, the issuer server 900, the acquirer server 1000, the directory server 120 and the ACS 125 as a payment interchange network. The payment server 1100 includes a processing system 1105 configured to extract programming instructions from a memory 1110 to provide various features of the present disclosure. The components of the payment server 1100 provided herein may not be exhaustive, and that the payment server 1100 may include more or fewer components than those depicted in FIG. 11. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 1100 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00108] The processing system 1105 is capable of executing the stored machine executable instructions of a commercial payment application 1140 (e.g., the commercial payment application 102c of FIG. 1) in the memory 1110 or within the processing system 1105 or any storage location accessible to the processing system 1105. The communication interface 1120 is configured to cause display of user interfaces on the remote device 1135 (e.g., the parent cardholder’s device 735 or the child cardholder’s device 740). The commercial payment application 1140 running on the parent cardholder’s device 735 sends a request to generate a child card number to the processing system 1105 using the communication interface 1120. The communication may be achieved through API calls, without loss of generality.
[00109] A child card number generation module 1125, operatively coupled to the processing system 1105, is configured to generate the child card number to be associated with the payment card / parent card number of the parent cardholder. The child card number values vary in format and may be cryptographically or non-cryptographically generated. For example, in place of an account PAN of the user, the cryptogram may be accompanied by a 16-digit reference number (e.g., unique virtual card number) that may be used to minimize misuse of account data. The generated child card numbers and the original PANs or the payment card numbers they map to are stored securely in a database 1115 and the mapping is used during the authorization process of a payment transaction. In one example embodiment, the child card number and the contact information of the child cardholder is sent in real time through API calls by the processing system 1105 to the ACS 125. Alternatively, the child card number and the contact information of the child cardholder may be uploaded through a URL provided by the ACS 125. During the authorization process, the processing system 1105 is configured to replace the child card number by the parent card number and send the parent card number along with a transaction amount and AAV to the issuer server 900 for verification.
[00110] The processing system 1105 is further configured to continually manage the customized child card numbers through suspension, deletions, updates, etc. The processing system 1105 may be configured to perform various functions such as maintenance and operation of the database 1115 based on a predefined criteria and at a predetermined periodic basis, child card number issuance and provisioning, child card number restriction controls (e.g., the child card number may be used only for a specific supplier) and the like. Additionally, payment card information of the payment card, PIN, the transaction amount, acquirer account information, transaction records, merchant account information, and the like may also be stored in the database 1115.
[00111] FIG. 12 is a simplified block diagram of a directory server 1200, in accordance with one embodiment of the present disclosure. The directory server 1200 is an example of the directory server 120 of FIG. 1. The directory server 1200 is associated with the payment network 145. The directory server 1200 is a 3-D Secure compliant directory server responsible for handling request and response authentication messages between merchants and issuers in the interoperability domain of the 3-D Secure authentication process.
[00112] The directory server 1200 includes a processing module 1205 operatively coupled to a database 1210, a memory 1215, and a communication module 1220. The components of the directory server 1200 provided herein may not be exhaustive, and that the directory server 1200 may include more or fewer components than those depicted in FIG. 12. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the directory server 1200 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00113] The memory 1215 is configured to store machine executable instructions to be accessed by the processing module 1205. The memory 1215 can be any type of storage accessible to the processing module 1205. For example, the memory 1215 may include volatile or non-volatile memories, or a combination thereof. In some non-limiting examples, the memory 1215 can be four to sixty-four Megabytes (MB) of Dynamic Random Access Memory (“DRAM”) or Static Random Access Memory (“SRAM”). In addition, some examples may include supplementary flash memory installed via a PCMCIA slot.
[00114] The processing module 1205 is configured to communicate with one or more remote devices such as a remote device 1225 using the communication module 1220 over the network 150 or the payment network 145 of FIG. 1. The examples of the remote device 1225 include, the MPI 825, the ACS 125, other computing systems of the issuer and the payment network 145 and the like. The processing module 1205 is configured to receive authentication requests for card numbers from merchants (e.g., via the MPI 825), determine if the card numbers are in an enrolled Issuer Bank Identifier Number (BIN) range, direct a request for cardholder authentication to the appropriate Issuer Access Control Server (ACS) and then respond back to the merchant indicating whether payment authentication is available for the queried card number.
[00115] To provide this service, the database 1210 of the directory server 1200 is configured to store card ranges with the appropriate Internet addresses (URLs) to specific issuers, who determine cardholder participation in the 3-D Secure program. For example, when the processing module 1205, via the communication module 1220, receives a child card number along with a request to verify if an access control server has participated for performing multi-factor authentication from the MPI 825, the processing module 1205 extracts a corresponding BIN from the child card number. The extracted BIN is matched with the stored BIN in the database 1210. Upon successful verification, the processing module 1205 retrieves a corresponding URL of the ACS stored against the corresponding BIN and sends the URL to the child cardholder’s device 740. The URL is used by the ACS to provide a user interface on the child cardholder’s device 740 to enable multi-factor authentication.
[00116] FIG. 13 is a simplified block diagram of an Access Control Server (ACS) 1300, in accordance with one embodiment of the present disclosure. The ACS 1300 may correspond to the ACS 125 of FIG. 1. Further, the ACS 1300 may be deployed on the issuer server 900 as a software module in the 3-D Secure protocol. Alternatively, the issuer bank / issuer outsources development and management of the ACS 1300 to a third party. Commonly, the buyer's web browser shows the domain name of the ACS provider, rather than the bank's domain name. The ACS 1300 includes a processor 1305 configured to extract programming instructions from a memory 1310 to provide various features of the present disclosure. The components of the ACS 1300 provided herein may not be exhaustive, and that the ACS 1300 may include more or fewer components than those depicted in FIG. 13. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the ACS 1300 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00117] In an embodiment, the processor 1305 may be embodied as one or more of various processing devices, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.
[00118] Via the communication interface 1320, the processor 1305 receives a unique identifier associated with a contact information of a child cardholder from a parent cardholder and stores them in a database 1315 for later retrieval. The communication interface 1320 is configured to cause display of user interfaces on a remote device 1335 (e.g., the child cardholder’s device 740) to enable a child cardholder to enter a pre-assigned unique identifier. In one embodiment, the communication interface 1320 includes a transceiver for wirelessly communicating information to, or receiving information from, the remote device 1335 or other suitable display device, and/or another type of remote processing device. In another embodiment, the communication interface 1320 is capable of facilitating operative communication with the remote devices and a cloud server using Application Program Interface (API) calls, without loss of generality. The communication may be achieved over the communication network 150.
[00119] A validation module 1330 is configured to validate the unique identifier by matching with the unique identifier received in advance and stored in the database 1315. A One-Time Password (OTP) generation module 1325, operatively coupled to the processor 1305, is configured to generate the OTP to be sent at the contact information of the child cardholder via the communication interface 1320. The validation module 1330 interacts with the OTP generation module 1325 to validate the OTP entered by the child cardholder using the corresponding UI. Upon successful verification of the OTP, the processor 1305 generates an authentication response and digitally signs the authentication response. The processor 1305 notifies the merchant server 800 via the MPI 825 by sending the digitally signed successful multi-factor authentication response. The processor 1305 also generates an Accountholder Authentication Value (AAV) and sends the AAV to the merchant server 800 via the MPI 825.
[00120] Apart from authentication of the transactions, the processor 1305 is configured to provide one or more features such as, but not limited to, new customer registration for authentication, bank web portal, existing customer data upload, user access control, BIN checking, customer authentication while registration process, risk management, payment analytics and the like. Further, the processor 1305 is capable of performing multi-factor authentication where the user is needed to authenticate himself using a static password (e.g., single-factor authentication), an OTP sent to his mobile number and email ID (e.g., two-factor authentication) and a biometric scan such as finger print scan (e.g., multi-factor authentication). Apart from the static password and OTP, the processor 1305 provides various authentication options such as ID card authentication, combination of static and dynamic password, Automated Teller Machine (ATM) PIN and the like.
[00121] FIG. 14 shows simplified block diagram of an electronic device 1400 capable of implementing the various embodiments of the present disclosure. For example, the electronic device 1400 may correspond to the electronic device 102a or the electronic device 104a of FIG. 1. The electronic device 1400 is depicted to include one or more applications, such as a commercial payment application and a merchant application. The commercial payment application and the merchant application is capable of communicating with any of the servers 115, 120, 125, 130, 135, and 140 for completing the child card number based payment transaction by performing multi-factor authentication.
[00122] It should be understood that the electronic device 1400 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the electronic device 1400 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 14. As such, among other examples, the electronic device 1400 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00123] The illustrated electronic device 1400 includes a controller or a processor 1402 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing tasks such as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1404 controls the allocation and usage of the components of the electronic device 1400 and supports for one or more payment application programs (see, applications 1406), that implements one or more of the innovative features as described herein. In addition, the applications 1406 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00124] The illustrated electronic device 1400 includes one or more memory components, for example, a non-removable memory 1408 and/or a removable memory 1410. The non-removable memory 1408 and/or the removable memory 1410 may be collectively known as database in an embodiment. The non-removable memory 1408 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1410 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1404 and the applications 1406. The electronic device 1400 may further include a user identity module (UIM) 1412. The UIM 1412 may be a memory device having a processor built in. The UIM 1412 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1412 typically stores information elements related to a mobile subscriber. The UIM 1412 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA9000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00125] The electronic device 1400 can support one or more input devices 1420 and one or more output devices 1430. Examples of the input devices 1420 may include, but are not limited to, a touch screen / a display screen 1422 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1424 (e.g., capable of capturing voice input), a camera module 1426 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1428. Examples of the output devices 1430 may include but are not limited to a speaker 1432 and a display 1434. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1422 and the display 1434 can be combined into a single input/output device.
[00126] A wireless modem 1440 can be coupled to one or more antennas (not shown in the FIG. 14) and can support two-way communications between the processor 1402 and external devices, as is well understood in the art. The wireless modem 1440 is shown generically and can include, for example, a cellular modem 1442 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1444 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1446. The wireless modem 1440 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the electronic device 1400 and a public switched telephone network (PSTN).
[00127] The electronic device 1400 can further include one or more input/output ports 1450, a power supply 1452, one or more sensors 1454 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the electronic device 1400 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1456 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1460, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00128] The disclosed method with reference to FIG. 6, or one or more operations of the method 600 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media), such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard drives or solid-state non-volatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means includes, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00129] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00130] Particularly, the server systems 115, 120, 125, 130, 135, and 140 its various components such as the computer system 705 and the database 710 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.
[00131] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and are well within the spirit and scope of the invention.
[00132] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.