Sign In to Follow Application
View All Documents & Correspondence

System And Method For Facilitating A Transaction With A Telephone Number

Abstract: A server for facilitating a transaction with a telephone number is described. The server is configured to receive a transaction request from a device, and the transaction request includes a telephone number and transaction information. The server is also configured to send an authentication request to the device, generate and transmit an authentication code to the telephone number in response to the transaction request, receive an authentication input from the device and compare the received authentication input with the authentication code. On the condition that the received authentication input matches the authentication code, the server is further configured to determine one or more payment accounts information associated with the telephone number. The server is also configured to display the one or more payment accounts information, receive an input from the device to select from the one or more payment accounts, and forward the transaction request with the selected payment account information to a payment network server. A method and a non-transitory computer readable medium for facilitating a transaction with a telephone number are also described. FIG. 1

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
20 September 2019
Publication Number
14/2020
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
ipo@epiphanyipsolutions.com
Parent Application

Applicants

MASTERCARD INTERNATIONAL INCORPORATED
2000 Purchase Street, Purchase, NY 10577

Inventors

1. Viraj Sunil Shah
A-604, Victoria Garden, Near Aga Khan Palace, Nagar Road, Kalyani Nagar, Pune-411006
2. Rohit Yog
C-1201, Godrej Horizon, S No 2 (p) & 3 (p), Behind Corinthians Club, NIBM Annexe Undri, Pune- 411048
3. Isha Bhadauria
C-1201, Godrej Horizon, S No 2 (p) & 3 (p), Behind Corinthians Club, NIBM Annexe Undri, Pune- 411048
4. Akhil Jain
Flat #32, Fifth Floor, Sreemangal Pearl, Survey no 14/1/2, Kharadi, Pune-411014

Specification

Claims:CLAIMS
We claim:

1. A server for facilitating a transaction with a telephone number, the server comprising:
at least one processor; and
at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to:
receive a transaction request from a device, the transaction request comprising at least a telephone number and transaction information;
send an authentication request to the device, generate and transmit an authentication code to the telephone number in response to the transaction request, wherein the authentication request requires an authentication input;
receive an authentication input from the device and compare the received authentication input with the authentication code;
determine one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code;
receive an input from the device to select from the one or more payment accounts; and
forward the transaction request with the selected payment account information to a payment network server.

2. The server of claim 1, wherein the server is caused to determine one or more payment accounts information associated with the telephone number, the at least one memory and the computer program code are configured to, with the at least one processor, cause the system at least to:
obtain the one or more payment accounts information from one or more issuers, wherein the telephone number is used to create the one or more payment accounts with the one or more issuers prior to the transaction.

3. The server of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the system further to:
store a plurality of telephone numbers and payment accounts information associated with each of the plurality of telephone numbers in a mapping file prior to the transaction.

4. The server of claim 3, wherein the at least one memory and the computer program code are configured to, with the at least one processor, for each of the one or more payment accounts, cause the system further to:
update the mapping file periodically at a predetermined interval.

5. The server of any one of the preceding claims, wherein the at least one memory and the computer program code are configured to, with the at least one processor, for each of the one or more payment accounts, cause the system further to:
display the one or more payment accounts information associated with the telephone number via the device.

6. The server of any one of the preceding claims, wherein the server is the same server as the payment network server.

7. A method for facilitating a transaction with a telephone number, the method comprising:
receiving a transaction request from a device, the transaction request comprising at least a telephone number and transaction information;
sending an authentication request to the device, generating and transmitting an authentication code to the telephone number in response to the transaction request, wherein the authentication request requires an authentication input;
receiving an authentication input from the device and comparing the received authentication input with the authentication code;
determining one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code;
receiving an input from the device to select from the one or more payment accounts; and
forwarding the transaction request with the selected payment account information to a payment network server.

8. The method of claim 7, wherein the determining one or more payment accounts information associated with the telephone number further comprising:
obtaining the one or more payment accounts information from one or more issuers, wherein the telephone number is used to create the one or more payment accounts with the one or more issuers prior to the transaction.

9. The method of claim 7, the method further comprising:
storing a plurality of telephone numbers and one or more payment accounts information associated with each of the plurality of telephone numbers in a mapping file prior to the transaction.

10. The method of claim 9, the method further comprising:
updating the mapping file periodically at a predetermined interval.

11. The method of any one of the claims 7 to 10, the method further comprising:
displaying the one or more payment accounts information associated with the telephone number via the device.

12. The method of any one of the claims 7 to 11, wherein the server is the same server as the payment network server.

13. A non-transitory computer readable medium having stored thereon an application which when executed by a computer causes the computer to perform steps comprising:
receiving a transaction request from a device, the transaction request comprising at least a telephone number and transaction information;
sending an authentication request to the device, generating and transmitting an authentication code to the telephone number in response to the transaction request, wherein the authentication request requires an authentication input;
receiving an authentication input from the device and comparing the received authentication input with the authentication code;
determining one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code;
receiving an input from the device to select from the one or more payment accounts; and
forwarding the transaction request with the selected payment account information to a payment network server. , 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:
SYSTEM AND METHOD FOR FACILITATING A TRANSACTION WITH A TELEPHONE NUMBER

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States

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)


SYSTEM AND METHOD FOR FACILITATING A TRANSACTION WITH A TELEPHONE NUMBER

Technical Field
[0001] The present invention relates broadly, but not exclusively, to systems and methods for facilitating a transaction with a telephone number.

Background
[0002] Cashless payments such as by credit cards, debit cards and digital wallets constitute a major part of financial transactions. For payment by credit card for example, in addition to its convenience, it attracts numerous users by offering rebates, cashbacks and discounts from different product or service providers. Nowadays it is common for users to own multiple payment accounts so as to enjoy a wide range of benefits, and millions of card transactions are taking place on a daily basis.
[0003] In scenarios of card payments, users present their cards at retail locations and payment terminals (in-person transaction) or enter their payment account details for transactions online. As a consequence, data associated with the payment accounts that would routinely and necessarily be available to a merchant during a legitimate transaction could be exposed inevitably, which could lead to the compromise of accounts. With the rapid growth of card use, card fraud has become a severe issue and has caused huge financial losses.
[0004] Besides the security concerns, as the number of payment accounts increases, keeping track of the different payment accounts available for use or remembering the payment account details, such as 16-digit card numbers, expiry dates, passwords and personal identification numbers (PINs), can be a challenge. To solve this problem, it is common to use an application (e.g. password manager) to store all the passwords in an encrypted database. However, the application itself will require a password to access any information stored in the database and it is not applicable to in-person transactions.
[0005] Accordingly, what is needed is a system and method for facilitating a transaction that seeks to address one or more of the above-mentioned problems. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.

Summary
[0006] According to a first aspect, there is provided a server for facilitating a transaction with a telephone number, the server comprising at least one processor and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to: receive a transaction request from a device, the transaction request comprising at least a telephone number and transaction information; send an authentication request to the device, generate and transmit an authentication code to the telephone number in response to the transaction request, wherein the authentication request requires an authentication input; receive an authentication input from the device and compare the received authentication input with the authentication code; determine one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code; receive an input from the device to select from the one or more payment accounts; and forward the transaction request with the selected payment account information to a payment network server.
[0007] In one embodiment, wherein the server is caused to determine one or more payment accounts information associated with the telephone number, the at least one memory and the computer program code may be configured to, with the at least one processor, cause the system at least to obtain the one or more payment accounts information from one or more issuers, wherein the telephone number is used to create the one or more payment accounts with the one or more issuers prior to the transaction.
[0008] In one embodiment, the at least one memory and the computer program code may be configured to, with the at least one processor, cause the system further to store a plurality of telephone numbers and payment accounts information associated with each of the plurality of telephone numbers in a mapping file prior to the transaction.
[0009] In one embodiment, the at least one memory and the computer program code may be configured to, with the at least one processor, for each of the one or more payment accounts, cause the system further to update the mapping file periodically at a predetermined interval.
[0010] In one embodiment, the at least one memory and the computer program code may be configured to, with the at least one processor, for each of the one or more payment accounts, cause the system further to display the one or more payment accounts information associated with the telephone number via the device.
[0011] In one embodiment, the server may be the same server as the payment network server.
[0012] According to a second aspect, there is provided a method of facilitating a transaction with a telephone number, the method comprising: receiving a transaction request from a device, the transaction request comprising at least a telephone number and transaction information; sending an authentication request to the device, generating and transmitting an authentication code to the telephone number in response to the transaction request, wherein the authentication request requires an authentication input; receiving an authentication input from the device and comparing the received authentication input with the authentication code; determining one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code; receiving an input from the device to select from the one or more payment accounts; and forwarding the transaction request with the selected payment account information to a payment network server.
[0013] In one embodiment, the step of determining one or more payment accounts information associated with the telephone number may further comprise obtaining the one or more payment accounts information from one or more issuers, wherein the telephone number is used to create the one or more payment accounts with the one or more issuers prior to the transaction.
[0014] In one embodiment, the method may further comprise storing a plurality of telephone numbers and one or more payment accounts information associated with each of the plurality of telephone numbers in a mapping file prior to the transaction.
[0015] In one embodiment, the method may further comprise updating the mapping file periodically at a predetermined interval.
[0016] In one embodiment, the method may further comprise displaying the one or more payment accounts information associated with the telephone number via the device.
[0017] In one embodiment, the server may be the same server as the payment network server.
[0018] According to a third aspect, there is provided a non-transitory computer readable medium having stored thereon an application which when executed by a computer causes the computer to perform steps comprising: receiving a transaction request from a device, the transaction request comprising at least a telephone number and transaction information; sending an authentication request to the device, generating and transmitting an authentication code to the telephone number in response to the transaction request, wherein the authentication request requires an authentication input; receiving an authentication input from the device and comparing the received authentication input with the authentication code; determining one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code; receiving an input from the device to select from the one or more payment accounts; and forwarding the transaction request with the selected payment account information to a payment network server.

Brief Description of Drawings
[0019] Embodiments of the disclosure will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:
[0020] FIG. 1 depicts a schematic diagram of a system configured to facilitate a transaction with a telephone number in accordance with embodiments of the disclosure.
[0021] FIG. 2 depicts a flowchart illustrating a method for facilitating a transaction with a telephone number in accordance with embodiments of the disclosure.
[0022] FIG. 3 depicts an illustration 300 of a process of facilitating an online transaction with a mobile number in accordance with embodiments of the disclosure.
[0023] FIG. 4 depicts a schematic diagram of an exemplary server including modules for facilitating a transaction with a telephone number in accordance with embodiments of the disclosure.
[0024] FIG. 5 depicts a schematic diagram of a computer system suitable for use in the systems depicted in FIG. 1 in accordance with embodiments of the disclosure.
[0025] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been depicted to scale. For example, the dimensions of some of the elements in the illustrations, block diagrams or flowcharts may be exaggerated in respect to other elements to help to improve understanding of the present embodiments.

Detailed Description
Overview
[0026] In the context of this specification, the term “user” refers to the user that initiates a transaction and makes payment with a telephone number, wherein the telephone number (e.g. a mobile number, a landline number, a facsimile number) is associated with one or more payment accounts information. It is to be appreciated that a telephone number is one that is not managed by a server that is an entity in a payment system. It is also to be appreciated that the user may or may not be the owner of the one or more payment accounts. Furthermore, the user may or may not be the owner or subscriber of the telephone number. However, the user is the one who uses the telephone number to initiate a transaction request and makes payment with the one or more payment accounts information associated with the telephone number. In instances where the user users the telephone number to initiate a transaction request with a merchant, the user is also the customer.
[0027] Various embodiments of the present disclosure provide a system and a method for facilitating a transaction with a telephone number. In various embodiments below where a telephone number is used, it is not necessary for the user, who has initiated the transaction request, to provide details relating to the payment account. More specifically, embodiments of the present disclosure provide an alternative user identification and/or authentication system and method for performing transactions which advantageously requires only the user’s telephone number, which efficiently addresses and/or mitigates the aforementioned drawbacks in respect of cashless transactions. In contrast to the more complicated payment accounts information (e.g. 16-digit card number, expiry date, PIN), a telephone number is easy to remember due to the intensive use of mobile phones or other telephones. As an example, current technology of performing fund transfers via a mobile number (e.g. PayLah!, PayNow) has proven to be well received. However, a smartphone is required for such technology and each mobile number is only allowed to register with one account. Further, technologies like PayLah! and PayNow are more intended for user-to-user fund transfer, rather than for transaction with merchants.
[0028] In various embodiments, the telephone number, being associated with one or more payment accounts information, can be used in lieu of the payment accounts information for a transaction. That is, the telephone number can be used as an identifier that maps back to the payment accounts information of the one or more payment accounts. The authentication can be beneficially implemented during the transaction process. In an embodiment, the one or more payment accounts may be presented to the user as selections. Advantageously, the user can select and use any one of the payment accounts associated with the telephone number for the transaction, without the necessity of providing the payment accounts information such as card number or expiry date. Furthermore, the telephone number is presented as a substitute for one or more payment accounts information that may be sensitive in at least a part of the transaction process, thereby minimising exposure of the payment accounts information and lowering the risk of compromised and/or unauthorised access to these information. As will be described in further details, the telephone number can be appropriately used as an identifier for user access to transaction services. These transaction services include, but are not limited to online transactions (e.g. online banking and e-commerce) and in-person transactions (e.g. transactions at retail locations, at payment terminals such as automated teller machines (ATMs) and retail banking).
Mapping Arrangement
[0029] In various embodiments of the present disclosure, the user has a telephone number that is associated with one or more payment accounts information. The association of a telephone number with a payment account can be established when the user creates the payment account with an issuer. The issuer of the payment account is an entity (e.g. a company or organisation) typically issues (e.g. establishes, manages, administers) a payment account (e.g. a credit card account, a debit card account linked to a bank account, or a stored value card).The association of the telephone number with the payment account information from the issuer serves as a mapping record. The mapping record can be maintained and/or updated by the issuer. For example, new payment accounts information can be added to an existing telephone number when more payment accounts are created using the same telephone number. In another example, an existing telephone number can be updated to a new telephone number, with all the payment accounts information remaining the same and associated to the new telephone number, when the owner of the payment accounts changes his/her telephone number and provides the new telephone number to the issuer(s).
[0030] In embodiments of the present disclosure, a payment facilitator (e.g. Mastercard®) functions as an intermediary that links the different parties involved in a financial transaction. The payment facilitator is an entity (e.g. a company or organisation) which operates to process transactions, clear and settle funds for payments between two other entities (e.g. two banks). The payment facilitator also manages rules for accounts that may be issued by issuers and facilitates funds exchange between accounts. The mapping records can be consolidated as a mapping file, which can be maintained and/or periodically updated by either the payment facilitator or any one of the issuers. The mapping file can be in any type of form, such as text files, spreadsheet files, lookup tables, or the like. The mapping records can alternatively be accessed on an ad-hoc basis, meaning that the payment facilitator or the issuers will fetch the associated payment accounts information when a transaction request using a telephone number is initiated.
[0031] The mapping file can be stored or managed by a server associated with the entity that is responsible for facilitating a transaction with a telephone number (referred to as “the mapping server”). As will be described in the following description, the entity can be the payment facilitator or the issuer. Each mapping record in the mapping file can include (i) the telephone number, (ii) one or more payment accounts information associated with the telephone number, and optionally (iii) user information (i.e. name, identity number) and/or the issuer information (e.g. name of the bank).
Transaction Process
[0032] In various embodiments, the telephone number can be entered on a device (e.g. a transaction terminal or an e-commerce website) without any payment account information to initiate a transaction. That is, the telephone number can be used as an identification and/or authentication method for user access to transaction services once the telephone number is associated with the one or more payment accounts information (associated when creating the payment accounts).
[0033] The transaction process is initiated when a system configured to facilitate a transaction receives a transaction request from the device. The transaction request includes the telephone number and information related to the transaction (e.g. merchant details, time of transaction, transaction amount). The transaction request is routed to the mapping server, which is a server associated with the entity that is responsible for mapping the telephone number to the one or more payment accounts information associated with the telephone number. As will be described in the following description, the entity can be the payment facilitator or the issuer.
[0034] Upon receiving the transaction request, the mapping server can send an authentication request to the device, wherein the authentication request requires an input from the user. Meanwhile the mapping server can generate and transmit an authentication code to the telephone number. For example, the authentication code can be in the form of short message service (SMS) to a mobile phone number or programmatic voice message to a landline number. The authentication code can be received by the user and entered into an authentication input field on the device. On the condition that the received authentication input matches the previously transmitted authentication code, the mapping server can be configured to determine the one or more payment accounts information associated with the telephone number. In various embodiments, the mapping server is also configured to display the one or more payment accounts on the device and receive an input from the user to select from the one or more payment accounts. Subsequently, the mapping server is configured to forward the transaction request together with the selected payment account information to a payment network server for further processing.
[0035] Accordingly, embodiments of the present disclosure can advantageously provide a simplified, streamlined system and method for facilitating a transaction with a telephone number. Various embodiments provide a system and method that can receive, determine and communicate authenticity and payment card information in a safe and efficient manner.
Terms Description (in Addition to Plain and Dictionary Meaning of Terms)
[0036] Unless context dictates otherwise, the following terms will be given the meaning provided here:
[0037] A telephone number refers to a sequence of digits assigned to a fixed-line telephone subscriber station connected to a telephone line or to a wireless electronic telephony device, such as a radio telephone or a mobile telephone, or to other devices for data transmission via the public switched telephone network (PSTN) or other private networks, or to communication services over the public internet, such as Voice over Internet Protocol (VoiP).
[0038] A payment account refers to one that is suitable for a transaction. The payment account can be used for the purpose of purchasing goods and/or services. The payment account can be a deposit account, a credit card account, a current account, or any other type of account offered by a financial institution, and represents the funds that an account holder has entrusted to the financial institution and from which the account holder can make withdrawals. Alternatively, a payment account can be a loan account in which case the account holder owes money to the financial institution. Moreover, the payment account may be a payment card or a digital wallet. A payment card is a card that can be used by an account holder for a transaction with a merchant. In the following disclosure, the term “payment cards” refer to any suitable transaction cards, such as credit cards, debit cards, prepaid cards, charge cards, membership cards, promotional cards, frequent flyer cards, identification cards, gift cards, and/or any other device that may hold payment account information, such as mobile phones, smartphones, smartwatches, tablets, personal digital assistants (PDAs), and/or computers. Each type of payment card can be used as a method of payment for performing a transaction. A digital wallet refers to an account that can be used by a digital wallet user for a transaction with a merchant. The digital wallet is usually linked to a digital wallet user’s bank account or a digital wallet user’s payment card. Typically, the payments by digital wallets are facilitated by a different entity such as Google®, Apple® or Paypal®, or Grab®. Additionally or alternatively, the payments by digital wallets are facilitated by an entity who also manages the payment cards such as Mastercard®. Such transactions that are made using the digital wallets are also known as wallet-based transactions.
[0039] An acquirer refers to a bank or financial institution that processes credit or debit payments on behalf of the merchant. The acquirer may manage a corresponding acquirer server which may allow merchants to accept payments using a payment account (e.g. debit or credit cards) from the card-issuing banks (i.e. issuers). The acquiring bank may enter into a contract or arrangement with the merchant and may offer the merchant a corresponding merchant account. This arrangement provides the merchant with a line of credit. Under the agreement, the acquiring bank exchanges funds with issuers on behalf of the merchant, and pays the merchant for its daily payment-card activity's net balance, that is, gross sales minus reversals, interchange fees, and acquirer fees. The acquirer may impose acquirer fees for an additional cost mark-up added to an association of interchange fees and may vary according to the acquirer's discretion. The acquirer may also maintain an acquiring channel that drives a network for a transaction terminal. The transaction terminal may be provided by the acquirer and the network may have the capability of accepting transactions from the transaction terminal connected to the acquirer’s interface.
[0040] A database, or databases refer to any databases located within a computing system or remote server such as a computer in a cloud server. The database or databases may each be a cloud database running on a cloud computing platform.
[0041] An issuer refers to a bank or credit union who offers credit means to consumers (or users), such as credit cards. The issuer makes the credit limit available to cardholders (i.e. users) and is responsible for sending payments to the acquirer or merchants for purchases made with credit cards from that bank. The issuer may manage a corresponding issuer server which interlinks the user and the acquirer by contracting with the cardholders for the terms of the repayment of transactions. The issuer server is generally associated with the payment account issuer, i.e. the issuer of the account associated with the payment account information and used to fund the transaction. The issuer server may include one or more computing devices that are used to process funding of the transaction. The issuer may be an entity (e.g. a company or organisation) which issues (e.g. establishes, manages, administers) a payment account (e.g. a credit card account, a stored value card, or a debit card account linked to a bank account) and payment account information. The issuer server may include one or more computing devices that are used to establish communication with another server by exchanging messages with and/or passing information to the other server. Further, in various embodiments, the issuer server can also establish communication with the other server to complete a process or step that may be external to the transaction process. For example, the other server may be associated with a service, and the issuer server can be configured to communicate with the server to register a user to the service, or to verify and/or authenticate the user to the service.
[0042] A payment device refers to a device on which transactions can be made. In the following disclosure, the payment device can belong to the user (i.e. a user device) and may be a portable computing device on which the user is able to install and view the application program. That is, the user may register as a registered user of the application program executing on the payment device. Examples of a payment device include but not limited to mobile phones, smartphones, smartwatches, tablets, personal digital assistants (PDAs), and/or computers. Importantly, a payment device can also include a transaction terminal (see below).
[0043] A transaction terminal refers to a device which interfaces with payment cards to facilitate a transaction. In the following disclosure, the transaction terminal may be a device located at the merchant’s store, a portable computing device or a payment gateway in the merchant’s website. Examples of such a terminal include but not limited to a point-of sale (POS) terminal, an automated teller machine, a mobile phone, a laptop or a tablet.
[0044] A payment network server is used to settle financial transactions through the transfer of monetary value, and include the institutions, instruments, people, rules, procedures, standards, and technologies that make such an exchange possible. The payment network server may be managed by a payment network facilitator which is an intermediary that links the different parties involved in a financial transaction. For example, when a user uses his payment card at the payment device to initiate a transaction request, the payment network server (or payment network facilitator) may route the transaction request from the transaction terminal to the issuer and may route an approval from the issuer to the acquirer. A further example of the payment network server is one that manages rules for accounts that may be issued by issuers and facilitates funds exchange between accounts. Therefore, the payment network server may connect the issuer associated to an account of the user and the merchant for the transfer of funds between the issuer and the merchant. The payment network server (or payment network facilitator) may also generate programming codes and instructions relating to the transaction. Further, in embodiments, the payment network server can be configured to route information to a social network service server to register, verify and/or authenticate the user.
[0045] A transaction generally includes a financial transaction, and can effect a change in the balance of financial accounts of two or more parties. A financial transaction can also include an agreement, or communication, carried out between a buyer (e.g. a user or account holder) and a seller (e.g. a merchant) to exchange goods and/or services for payment. Accordingly, a transaction request includes information that is exchanged or provided to facilitate the transaction. A typical transaction request can include the user’s payment account information (e.g. user’s payment card details). The user’s payment account information can include an issuer’s identifier identifying the issuer managing the user’s payment account. The transaction request can also include the value of the goods and/or services, a description of the goods and/or services and details of the merchant involved in the transaction. The transaction request can also include information relating to the merchant, e.g. a merchant’s account identifying an acquirer managing the merchant’s account. The transaction can also include an electronic funds transfer (i.e. the electronic transfer of money from one financial account to another, either within a single financial institution or across multiple institutions via computer-based systems). In embodiments of the disclosure, a social network account identifier can be included in the transaction request.
Exemplary Embodiments
[0046] Embodiments of the present disclosure will be described, by way of example only, with reference to the drawings. Like reference numerals and characters in the drawings refer to like elements or equivalents.
[0047] Some portions of the description which follows are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.
[0048] Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as “associating”, “registering”, “comparing”, “determining”, “generating”, “identifying”, “including”, “inserting”, “modifying”, “sending”, “transmitting”, “forwarding”, “receiving”, “fetching”, “retrieving”, “replacing”, “recording”, or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices.
[0049] The present specification also discloses apparatus for performing the operations of the methods. Such apparatus may be specially constructed for the required purposes, or may include a computer or other computing device selectively activated or reconfigured by a computer program stored therein. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate. The structure of a computer will appear from the description below.
[0050] In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the disclosure.
[0051] Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer program when loaded and executed on a computer effectively results in an apparatus that implements the steps of the preferred method.
[0052] In embodiments of the present disclosure, use of the term ‘server’ may mean a single computing device or at least a computer network of interconnected computing devices which operate together to perform a particular function. In other words, the server may be contained within a single hardware unit or be distributed among several or many different hardware units.
[0053] FIG. 1 depicts a schematic diagram 100 of a system configured to facilitate a transaction with a telephone number in accordance with embodiments of the disclosure. The system 100 includes a device 102, an acquirer server 104, a payment network server 106, an issuer server 108, a mapping server 112, and a telephone 120. The device 102 can be a payment device that belongs to the user with an application program installed or with an online portal (e.g. HTML website) associated with the merchant. The device 102 can alternatively be a payment terminal (e.g. a POS terminal, an ATM). The device 102 is in direct communication with the acquirer server 104, and the payment network server 106 is in direct communication with the acquirer server 104 and the issuer server 108. The system 100 comprising the mapping server 112 can be used to implement method 200 for facilitating a transaction with a telephone number as depicted in FIG. 2 in accordance with embodiments of the disclosure. The method 200 broadly includes:

step 202: receiving a transaction request from a device 102, the transaction request comprising at least a telephone number and transaction information;

step 204: sending an authentication request to the device 102, generating and transmitting an authentication code to the telephone number, wherein the authentication request requires an authentication input;

step 206: receiving an authentication input from the device 202 and comparing the received authentication input with the authentication code;

step 208: determining one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code;

step 210: receiving an input from the device 202 to select from the one or more payment accounts; and

step 212: forwarding the transaction request with the selected payment account information to a payment network server 106.

[0054] At step 202, a transaction request from a device 102 can be received by the mapping server 112. The transaction request can include a telephone number and information related to the transaction (e.g. merchant information, time of transaction, transaction amount). The device 102 is typically a payment device which can serve as a main conduit for transmitting the transaction request and for receiving an authorisation/ failure response of the transaction request. In embodiments of the present disclosure, the device 102 can be a device belonging to the user that is configured to function as a payment device. In other embodiments, the device 102 can be a transaction terminal. Examples of a transaction terminal include POS terminal, an ATM and the like. The device 102 can also be a laptop computer, smartphone, smartwatch or a tablet with an operating system can which host an application configured to generate and transmit the transaction request. It can be appreciated that the telephone number can be inputted into the device 102 by the user, or presented to the device 102 by means known in the art (e.g. voice input, QR code scanning).
[0055] In various embodiments, the transaction request can include an ISO 8583 formatted message. ISO 8583 is an international standard for systems that exchange electronic transactions initiated using payment card information. ISO 8583 defines a message format and a communication flow so that different systems can exchange such transaction requests and authorisation messages. An ISO 8583 formatted message can comprise a message type indicator (MTI), one or more bitmaps indicating which data elements are present and data elements representing the fields of the message. In embodiments of the present disclosure, the ISO 8583 formatted message can include data element field entries storing at least the telephone number. In other words, the transaction request can be compliant with the ISO 8583 standard and includes data elements which carry transaction information generated by the device 102.
[0056] Notably, as payment account information is not included at the time of generating the transaction request, it can be appreciated that data element fields relating to payment account information can either be blank, or filled with dummy values (i.e. placeholder values). Further, the ISO 8583 formatted message can further include a data element field entry indicating that the transaction request is generated with a telephone number identifier, rather than a typical transaction request which includes payment account information such as a payment card number (PAN) of the payment account. That is, the ISO 8583 formatted message can include an identifier indicating that the transaction request includes a telephone number, and the identifier can be advantageously used to allow the payment network to differentiate between such transaction request and a typical transaction request. For example, the identifier may be stored a predetermined binary format data element entry field, and the device 102 can be configured to populate the identifier with a binary value of “1” if a transaction request includes a telephone number. Consequently, the device 102 can be configured to populate the identifier with a binary value of “0” if a transaction request does not include a telephone number (e.g. the transaction request is a typical request including payment account information).
[0057] In various embodiments, the transaction request can be complaint with ISO 8583 standard and can include data elements (DE) which carry the transaction information. The transaction request would be similar to typical transaction requests, except that the data element fields relating to payment account information would either be blank, or filled with dummy values (i.e. placeholder values). Thus, the embodiments in the present disclosure may be advantageously implemented on existing payment systems without modification to existing software and/or hardware, provided that the device 102 additionally supports alphanumeric entry of the telephone numbers.
[0058] At step 204, the mapping server 112 can send an authentication request to the device 102 in response to receiving the transaction request. In the meantime the mapping server 112 can generate and transmit an authentication code to the telephone number included in the transaction request. In an embodiment of the present disclosure, when the telephone number is a mobile number and the telephone 120 is a mobile phone, the authentication code can be transmitted to the mobile number via SMS. In an alternative embodiment, when the telephone number is a landline number and the telephone 120 is a landline telephone, the authentication code can be transmitted to the landline number in a form of programmatic voice message using text-to-speech conversion. In another alternative embodiment, when the telephone number is a VoiP number (e.g. Skype) and the telephone 120 can be a smartphone or a computer/laptop installed with a program provided by the VoiP provider, the authentication code can be transmitted as a message via internet. It can be appreciated that the generated authentication code can be encrypted with various schemes prior to transmission. In embodiments of the disclosure, the authentication code can be an OTP. The OTP can be generated by the mapping server 112 using a pseudorandom number generator, a true random number generator or alike.
[0059] At step 206, the mapping server 112 can receive an authentication input from the device 102 and compare the received authentication input with the authentication code generated and transmitted at step 204. By authenticating the transaction request, it can advantageously prevent unauthorized use of the telephone number for transactions. For example, a fraudulent user might initiate a transaction request using a random telephone number (which the fraudulent user has no access to). In response to the transaction request, the real owner of the telephone number would receive the authentication code and the fraudulent user would not be able to see the payment accounts information associated with the telephone number without providing the authentication input matching the authentication code.
[0060] At step 208, the mapping server 112 can determine one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code. The one or more payment accounts information associated with the telephone number can be determined by mapping the telephone number to the payment accounts information according to the mapping file stored in the mapping server 112. The mapping can be realized by means in the art, such as lookup functions.
[0061] At step 210, the mapping server 112 can further receive an input from the device 102 such that the user can select from the one or more payment accounts. In various embodiments, after step 208, the mapping server 112 can be configured to send the one or more payment accounts information to the device 102 and display the information on the device 102. In an alternative embodiment, the mapping server 112 can send the one or more payment accounts information to the telephone number, and receive an input from the telephone. The input can be entered into the device 102 or the telephone 120 by means known in the art (e.g. voice input, text messaging, QR code scanning, near-field communication, etc.).
[0062] At step 212, the mapping server 112 can forward the transaction request with the selected payment account information to a payment network server 106 for further processing. The payment network server 106 can be operated by a payment facilitator. For example, the payment network server 106 may be a Banknet network operated by the payment facilitator (e.g. Mastercard®). In embodiments of the disclosure, the payment network server 106 is configured to route information between the acquirer server 104 and the issuer server 108. In various embodiments, the payment network server 106 can be the same server as the mapping server 112, or can be configured to communicate with the mapping server 112. For example, the payment network server 106 can determine the payment account information by accessing the mapping file stored on the mapping server 112.
[0063] The issuer server 108, corresponding to the payment account selected by the user at step 210, is configured to receive the transaction request forwarded by the payment network server 106. The issuer server 108 can process the transaction request and in turn generate and transmit a response back to the payment network server 106. The response can include data indicative of an authorisation of transfer of funds from the user, or a transaction failure message including a response code indicating a reason for the transaction failure. The payment network server 106 then transmits the response back to the acquirer server 104 which in turn routes the message to device 102.
[0064] FIG. 3 depicts an illustration 300 of a process of facilitating an online transaction with a mobile number in accordance with embodiments of the disclosure. The process in FIG. 3 is an exemplary implementation of the method 200 depicted in FIG. 2. In an online shopping scenario, the user finalizes the products in the shopping cart and proceeds to the checkout page. The user selects the option of “Pay with Mobile Number” in the checkout payment options, and provides a mobile number to initiate the transaction (step 202). In response to receiving the transaction request, authentication is triggered by generating an OTP in the authentication layer in the mapping server 112 and transmitting the OTP to the mobile number (step 204). In the meantime, the user will be prompted to enter the OTP on the webpage. Input from the user will be subsequently received by the authentication layer and will be compared with the previously generated OTP (step 206).
[0065] On the condition that the input from the user matches the OTP, the mapping server 112 will determine the payment accounts information associated with the mobile number based on the mapping file (step 208). In this example, three cards are linked to the mobile number provided, and the three cards are displayed to the user on the webpage. The mapping file, constructed by fetching the telephone numbers and payment accounts information from different issuers, is stored and maintained by a secured central repository in the mapping server 112. In the next step, the user selects one of the three cards for making the payment and the input will be received by the mapping server 112 (step 210). The mapping server 112 will forward the transaction request with the selected card information to a payment network server 106 to process the payment. Regular procedures for authentication, such as using Card Verification Value (CVV), can be used to complete the payment.
[0066] FIG. 5 depicts an exemplary computing device 500, hereinafter interchangeably referred to as a computer system 500, where one or more such computing devices 500 may be used to execute the methods 200 of FIG. 2. One or more components of the exemplary computing device 500 can also be used to implement the systems 100as well as the device 102, the acquirer server 104, the payment network server 106, the mapping server 112, and the issuer server 108. The computing device 500 can also be used to implement an exemplary server 400. The following description of the computing device 500 is provided by way of example only and is not intended to be limiting.
[0067] As shown in Fig. 5, the example computing device 500 includes a processor 502 for executing software routines. Although a single processor is shown for the sake of clarity, the computing device 500 may also include a multi-processor system. The processor 502 is connected to a communication infrastructure 506 for communication with other components of the computing device 500. The communication infrastructure 506 may include, for example, a communications bus, cross-bar, or network.
[0068] The computing device 500 further includes a main memory 504, such as a random access memory (RAM), and a secondary memory 510. The secondary memory 510 may include, for example, a storage drive 512, which may be a hard disk drive, a solid state drive or a hybrid drive and/or a removable storage drive 514, which may include a magnetic tape drive, an optical disk drive, a solid state storage drive (such as a USB flash drive, a flash memory device, a solid state drive or a memory card), or the like. The removable storage drive 514 reads from and/or writes to a removable storage medium 518 in a well-known manner. The removable storage medium 518 may include magnetic tape, optical disk, non-volatile memory storage medium, or the like, which is read by and written to by removable storage drive 514. As will be appreciated by persons skilled in the relevant art(s), the removable storage medium 518 includes a computer readable storage medium having stored therein computer executable program code instructions and/or data.
[0069] In an alternative implementation, the secondary memory 510 may additionally or alternatively include other similar means for allowing computer programs or other instructions to be loaded into the computing device 500. Such means can include, for example, a removable storage unit 522 and an interface 520. Examples of a removable storage unit 522 and interface 520 include a program cartridge and cartridge interface (such as that found in video game console devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a removable solid state storage drive (such as a USB flash drive, a flash memory device, a solid state drive or a memory card), and other removable storage units 522 and interfaces 520 which allow software and data to be transferred from the removable storage unit 522 to the computer system 500.
[0070] The computing device 500 also includes at least one communication interface 524. The communication interface 524 allows software and data to be transferred between computing device 500 and external devices via a communication path 526. In various embodiments of the disclosure, the communication interface 524 permits data to be transferred between the computing device 500 and a data communication network, such as a public data or private data communication network. The communication interface 524 may be used to exchange data between different computing devices 500 which such computing devices 500 form part an interconnected computer network. Examples of a communication interface 524 can include a modem, a network interface (such as an Ethernet card), a communication port (such as a serial, parallel, printer, GPIB, IEEE 1394, RJ45, USB), an antenna with associated circuitry and the like. The communication interface 524 may be wired or may be wireless. Software and data transferred via the communication interface 524 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communication interface 524. These signals are provided to the communication interface via the communication path 526.
[0071] As shown in Fig. 5, the computing device 500 further includes a display interface 528 which performs operations for rendering images to an associated display 530 and an audio interface 532 for performing operations for playing audio content via associated speaker(s) 534.
[0072] As used herein, the term "computer program product" may refer, in part, to removable storage medium 518, removable storage unit 522, a hard disk installed in storage drive 512, or a carrier wave carrying software over communication path 526 (wireless link or cable) to communication interface 524. Computer readable storage media refers to any non-transitory, non-volatile tangible storage medium that provides recorded instructions and/or data to the computing device 500 for execution and/or processing. Examples of such storage media include magnetic tape, CD-ROM, DVD, Blu-rayTM Disc, a hard disk drive, a ROM or integrated circuit, a solid state storage drive (such as a USB flash drive, a flash memory device, a solid state drive or a memory card), a hybrid drive, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computing device 500. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computing device 500 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.
[0073] The computer programs (also called computer program code) are stored in main memory 504 and/or secondary memory 510. Computer programs can also be received via the communication interface 524. Such computer programs, when executed, enable the computing device 500 to perform one or more features of embodiments discussed herein. In various embodiments, the computer programs, when executed, enable the processor 607 to perform features of the above-described embodiments. Accordingly, such computer programs represent controllers of the computer system 500.
[0074] Software may be stored in a computer program product and loaded into the computing device 600 using the removable storage drive 514, the storage drive 512, or the interface 520. The computer program product may be a non-transitory computer readable medium. Alternatively, the computer program product may be downloaded to the computer system 500 over the communication path 526. The software, when executed by the processor 502, causes the computing device 500 to perform the necessary operations to execute the method 200as shown in FIG. 2.
[0075] It is to be understood that the embodiment of Fig. 5 is presented merely by way of example to explain the operation and structure of the system 500. Therefore, in some embodiments one or more features of the computing device 500 may be omitted. Also, in some embodiments, one or more features of the computing device 500 may be combined together. Additionally, in some embodiments, one or more features of the computing device 500 may be split into one or more component parts.
[0076] It will be appreciated that the elements illustrated in Fig. 5 function to provide means for performing the various functions and operations of the system as described in the above embodiments.
[0077] When the computing device 500 is configured to realize the system 100 to facilitate a transaction with a telephone number, the system 100 will have a non-transitory computer readable medium having stored thereon an application which when executed causes the system 100 to perform steps comprising: (i) receiving a transaction request from a device, the transaction request comprising at least a telephone number and transaction information; (ii) sending an authentication request to the device, generating and transmitting an authentication code to the telephone number, wherein the authentication request requires an authentication input; (ii) comparing the received authentication input with the authentication code; (iv) determining one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches the authentication code; (v) receiving an input from the device to select from the one or more payment accounts; and (vi) forwarding the transaction request with the selected payment account information to a payment network server.
[0078] It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present disclosure as shown in the specific embodiments without departing from the spirit or scope of the disclosure as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.
[0079] FIG. 4 depicts a schematic diagram 400 of an exemplary server including modules for facilitating a transaction with a telephone number in accordance with embodiments of the disclosure. In implementations, the mapping server 112 can be generally described as one or more physical devices (i.e. servers) including at least one processor 402 and at least one memory 404 including computer program code. The at least one memory 404 and the computer program code are configured to, with the at least one processor 402, cause the server to implement the method 200 described in FIG. 2. The server 400 can include a receiver module 406, a comparison module 408, an update module 410 and a transmitter module 412. With reference to FIG. 1 and FIG. 2, the receiver module 606 is configured to receive the transaction request from a device, the transaction request comprising the telephone number. The generator module 416 is configured to generate the authentication request and authentication code. The transmitter module 412 is configured to transmit the authentication request to the device and the authentication code to the telephone number. The comparison module 408 is configured to compare the received authentication input with the authentication code. The update module 410 is configured to determine the one or more payment accounts information associated with the telephone number, on the condition that the received authentication input matches to the authentication code.

Documents

Application Documents

# Name Date
1 201944037942-CLAIMS [11-02-2022(online)].pdf 2022-02-11
1 201944037942-STATEMENT OF UNDERTAKING (FORM 3) [20-09-2019(online)].pdf 2019-09-20
2 201944037942-FER_SER_REPLY [11-02-2022(online)].pdf 2022-02-11
2 201944037942-REQUEST FOR EXAMINATION (FORM-18) [20-09-2019(online)].pdf 2019-09-20
3 201944037942-PROOF OF RIGHT [20-09-2019(online)].pdf 2019-09-20
3 201944037942-OTHERS [11-02-2022(online)].pdf 2022-02-11
4 201944037942-PRIORITY DOCUMENTS [20-09-2019(online)].pdf 2019-09-20
4 201944037942-FER.pdf 2021-10-17
5 201944037942-POWER OF AUTHORITY [20-09-2019(online)].pdf 2019-09-20
5 201944037942-FORM 3 [10-06-2020(online)].pdf 2020-06-10
6 Correspondence by Agent_General Power of Attorney_25-09-2019.pdf 2019-09-25
6 201944037942-FORM 18 [20-09-2019(online)].pdf 2019-09-20
7 abstract 201944037942.jpg 2019-09-23
7 201944037942-FORM 1 [20-09-2019(online)].pdf 2019-09-20
8 201944037942-COMPLETE SPECIFICATION [20-09-2019(online)].pdf 2019-09-20
8 201944037942-DRAWINGS [20-09-2019(online)].pdf 2019-09-20
9 201944037942-DECLARATION OF INVENTORSHIP (FORM 5) [20-09-2019(online)].pdf 2019-09-20
10 201944037942-DRAWINGS [20-09-2019(online)].pdf 2019-09-20
10 201944037942-COMPLETE SPECIFICATION [20-09-2019(online)].pdf 2019-09-20
11 abstract 201944037942.jpg 2019-09-23
11 201944037942-FORM 1 [20-09-2019(online)].pdf 2019-09-20
12 Correspondence by Agent_General Power of Attorney_25-09-2019.pdf 2019-09-25
12 201944037942-FORM 18 [20-09-2019(online)].pdf 2019-09-20
13 201944037942-POWER OF AUTHORITY [20-09-2019(online)].pdf 2019-09-20
13 201944037942-FORM 3 [10-06-2020(online)].pdf 2020-06-10
14 201944037942-PRIORITY DOCUMENTS [20-09-2019(online)].pdf 2019-09-20
14 201944037942-FER.pdf 2021-10-17
15 201944037942-PROOF OF RIGHT [20-09-2019(online)].pdf 2019-09-20
15 201944037942-OTHERS [11-02-2022(online)].pdf 2022-02-11
16 201944037942-REQUEST FOR EXAMINATION (FORM-18) [20-09-2019(online)].pdf 2019-09-20
16 201944037942-FER_SER_REPLY [11-02-2022(online)].pdf 2022-02-11
17 201944037942-STATEMENT OF UNDERTAKING (FORM 3) [20-09-2019(online)].pdf 2019-09-20
17 201944037942-CLAIMS [11-02-2022(online)].pdf 2022-02-11

Search Strategy

1 search201944037942E_05-04-2021.pdf