A method for the intelligent and frictionless facilitation of account-to-account payments

Abstract

Introduced here is a method for aggregating, by a payment service, payment account information from various account providers either prior to or during a payment transaction, such that during the payment transaction a proxy can be used by the payment service to intelligently and independently select the payment account details required to fulfill the payment transaction via a pull payment mechanism

Description

[0001] A METHOD FOR THE INTELLIGENT AND FRICTIONLESS FACILITATION OF ACCOUNT-TO-ACCOUNT PAYMENTS

[0002] DESCRIPTION

[0003] SUMMARY OF THE INVENTION

[0004] Current art teaches that for a payment service to facilitate a payment transaction between a paying and a receiving party, both parties must open accounts, register payment account details, contact information like phone numbers or email addresses, and in certain instances prefund their accounts, with the same payment service.1,2

[0005] Introduced here is a novel method for processing payment transactions without one or more parties taking the inconvenient first step of registering their payment account and / or other details, or prefunding their accounts with the payment service; and also without the inconvenient step of remembering and utilizing authentication credentials from various account providers.

[0006] Here, an account provider is defined as any entity that provides account services to an account holder. Account providers may include financial institutions like banks and credit card companies, and non-financial institutions like merchants and telecommunications companies, just to mention a few.

[0007] All that is required is for account providers to pre-supply relevant data associated with accounts held by said account providers to a payment service. By doing so, the payment service is able to utilize any phone number, email address or any other unique identifier associated with a party at any of the account providers as an alias to intelligently and independently select and / or recommend one or more accounts, with or without input from the user, using several selection criteria.

[0008] Where the pre-supply of account data is not feasible, the invention provides for instant enquiry from a cluster of account providers that are most likely to hold the relevant data for the one or more parties involved in the transaction.

[0009] The invention also utilizes the functionality of one-time passwords to optionally provide a uniform authentication method to effect payment from any account held at any account provider without the need of remembering or utilizing multiple passwords associated with the various account providers.

[0010] Therefore, the method described and claimed in this disclosure introduces a level of convenience and frictionless operation to parties of a payment transaction that is hitherto non-existent to the art.

[0011] SUBSTITUTE SHEET (RULE 26) BACKGROUND OF THE INVENTION

[0012] Aliases are an important way of effecting payments without revealing account details. However, current art teaches that an alias or proxy, used as an alternative to account details, has to be registered by a user of a payment system before the alias can be utilized in carrying out payment transactions.1

[0013] One of the objects of this invention is to do away with the need for users to take the extra step of registering any alias, and / or payment details, and / or prefunding any account with any payment system provider.1,2In addition, conventional systems require both the payer and the payee to be registered to the same payment system in order to facilitate a payment transaction.6,7This results in both the sender and the recipient of funds to take one or more inconvenient steps in order to register with a payment service that they might not use often or at all subsequently.1,3,6

[0014] Introduced here is a platform-agnostic technology for enabling payment without the need for presenting any cards or entering any account credentials, or pre-registering any such credentials by the parties, or downloading and installing any payment application by the parties, or pre-funding accounts, or registering both parties on the same payment platform, or opening new accounts. This invention eliminates all these inconvenient steps. In addition, with this invention, during a payment transaction, users are not required to select payment accounts from any list, as is the case in current art.7Instead, accounts are automatically selected for all parties that are represented by aliases.

[0015] All that is required is for account providers that hold accounts to connect to a payment service, pre-supply relevant data associated with these accounts to the payment service, and allow the payment service to send debit and credit instructions for execution. By doing so, the payment service is able to utilize any phone number, email address or any other unique identifier that is registered at the account provider as an alias in completing a payment transaction.

[0016] In addition, credit and debit cards are by far the most popular means by which merchants collect payments from their customers. Cards allow for instant confirmation of payments and simply require that merchants own, for in-store payments, proprietary card-accepting point of sale (POS) devices. However, as successful and as ubiquitous as card-based payments have been, not every merchant, especially those in the developing world, can afford a POS device, and not every cardholder may have a card handy at the time of purchase. There are several reasons for this; the card may be lost, expired, damaged, malfunctioning, or simply left behind. This invention will do away with the need to have physical cards. It not only allows for direct access to bank accounts without the intermediate need for cards, but also allows for non-physical access to card accounts in case a card is not handy when needed. In addition, the invention would allow traditional or specialized POS devices to be replaced by any type of phone or handheld device,

[0017] SUBSTITUTE SHEET (RULE 26) especially feature phones which are much cheaper than smartphones and which are much more ubiquitous in the developing world, as a means of accepting payments.

[0018] Furthermore, current art also teaches that both merchants and customers would need to possess smartphones in order to facilitate an integrated, cardless, bank account to bank account payment system.1This invention allows users without smartphones to carry out payment transactions. As previously mentioned, this innovation is platform-agnostic. In this invention, data communication between the payment application and any party may occur via USSD (Unstructured Supplementary Service Data), IVR (Interactive Voice Response), web or mobile web, or any other data communication technology supported by the various computing apparatus involved in executing the method. Therefore, with this invention, it is permissible for both the payer and the payee to use feature phones as their primary payment devices to communicate with a payment application that is associated with a telecommunications company.

[0019] Also, in such cases where merchants use smartphones as payment devices for account to account payments, current art typically restricts them to only one smartphone per bank account which makes it difficult to implement existing technology in a multiple point of sale retail setting.1This invention resolves this problem by introducing the unique ability for a single merchant to process account to account payments using a plurality of smartphones and computing devices simultaneously.

[0020] In addition, current art teaches that when payment is to be made from a customers’ bank account without the use of a debit card, the customer would typically leave the merchants’ checkout application and login to a banking application from where a push payment is executed to the merchants’ account at a specified financial institution. Upon the successful execution of the push payment, the merchant application is typically not updated unless a specific payment code that was pre-supplied by the merchants’ application is referenced by the customer in the push payment,4or unless the payment was made into an account that is specifically associated with both the merchant and the enabling payment service.

[0021] In most cases, merchant systems are not integrated with bank systems and so there is no automated way of knowing that a payment authorization has occurred. Merchants typically rely on either checking their bank accounts or looking out for email or SMS alerts to notify them of such payments. Traditional card-acceptance devices do not have this problem since a pull mechanism is adopted and the devices are all integrated with the payment authorization systems. This invention will eliminate the need for payers to use separate systems to make payments because a pull mechanism for making payments is utilized to directly draw funds from bank or card accounts without the payer supplying bank or card account details. This innovation ensures that the merchant system is immediately notified once payment is authorized.

[0022] SUBSTITUTE SHEET (RULE 26) In addition, with this invention, users are able to authorize transactions that draw on funds from various accounts across various account providers by utilizing a single uniform authentication method. This means that users are not required to remember or utilize each of the login details associated with their respective account providers or with the payment service. Therefore, this invention introduces a unique level of integration and universal ubiquity that is currently non-existent in the art.1,3

[0023] The invention teaches how account data related to account holders from several account providers can be aggregated into a database by the payment service such that account data can be easily retrieved based on aliases. This database is kept current with data related to both existing accounts and newly created accounts through regular and periodic updates. In addition, where proactive data storage with the payment service is not feasible, real time data requests can be made to a select cluster of account providers that are most likely to hold data related to the parties.

[0024] The invention also teaches how the payment service is able to independently and intelligently select which account or accounts are to be utilized for each party in fulfilling a payment request, especially if a party has more than one account. The invention describes various selection criteria used in determining which account or accounts amongst many would be utilized in the payment transaction.

[0025] The invention also allows for more than one account to be selected in the event that a single account may not have sufficient funds required to fulfill a payment. It provides the payment service with the unique functionality of being able to independently determine the amount that is to be withdrawn from each account that is selected in order to make a single payment while ensuring that the sum of each amount withdrawn from each account is equal to the single payment to be made.

[0026] Also, in the event that a payer has insufficient funds either in a single account or in a plurality of accounts collectively, or in the event that the payer has been prequalified for credit by a participating account provider, or in any other case, the invention provides the payment service with the option of either requesting for credit from any interested account provider or retrieving any pre-qualified credit for the payer, and providing the payer with the option of accepting the credit offer.

[0027] Another important feature is the ability of a payment request to be partially fulfilled and / or to remain in queue until the payer has sufficient funds to completely fulfill the payment request. This means that the invention has the unique ability to monitor all the accounts associated with a payer globally and to debit any account that receives any new funds. This feature can be particularly useful for debt collection.

[0028] SUBSTITUTE SHEET (RULE 26) Additionally, in the event that a payee does not have an account already present with the payment service, the invention provides for the payment service to be able to instantly open an account for the payee at any of the participating account providers. This feature is particularly useful for boosting financial inclusion in underserved and low-income communities where bank accounts are not easily available.

[0029] This disclosure also includes how a party may receive a payment into more than one account by monitoring any pre-set limits associated with the parties’ accounts. For example, if an account provider specifies, for an account, a maximum deposit limit, or a maximum balance limit, or a maximum withdrawal limit, the payment service is able to monitor these limits and to select the one or more accounts that are most suitable to make or receive payment on behalf of the party.

[0030] Finally, the invention claims an ability for third-party applications to implement the functionalities of the payment service via the use of application programming interface methods. With this functionality, any application that interacts with users may be used as a payment application. Such applications may be associated with messaging services, social network services, automated teller machines, electronic toll collection systems, telecommunication services, and lending services.

[0031] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure. Thus, the following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure can be references to the same embodiment or any embodiment; and, such references mean at least one of the embodiments.

[0033] Reference 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 disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are 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.

[0034] SUBSTITUTE SHEET (RULE 26) The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Alternative language and synonyms may be used for any one or more of the terms discussed herein, and no special significance should be placed upon whether or not a term is elaborated or discussed herein. In some cases, synonyms for certain terms are provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any terms discussed herein is illustrative only, and is not intended to further limit the scope and meaning of the disclosure or of any example term. Likewise, the disclosure is not limited to various embodiments given in this specification.

[0035] Without intent to limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the embodiments of the present disclosure are given below. Note that titles or subtitles may be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, technical and scientific terms used herein have the meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, the present document, including definitions will control.

[0036] Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.

[0037] One embodiment of the present disclosure provides a method for facilitating, by a payment service, a payment transaction between parties, wherein said parties are identified by aliases, and wherein the details of the transaction are contained in a payment request received from a payment application. A basic representation of this embodiment is illustrated in Figure 14.

[0038] The invention allows for multiple parties with one or more payers, as well as one or more payees. This functionality allows for various payment scenarios: one payer to one payee; one payer to multiple payees; multiple payers to multiple payees; and, multiple payers to one payee. A generalized representation of an embodiment of the method is illustrated in Figure 1.

[0039] While the payment application would typically be associated with a payee or a merchant that receives payments from customers in either online, in-store, or offline scenarios. The payment application may also be associated with any third-party entity that is not a party to the transaction either as a payer or payee. All that is required for an application that is associated with a

[0040] SUBSTITUTE SHEET (RULE 26) third-party entity to become a payment application is to implement an application programming interface with the payment service. Examples of such third-party entities are payment services, banks, messaging or social media application providers, like Whatsapp or Messenger, or any entities that provide platforms where parties can interact.

[0041] A few embodiments of how a payment transaction can be initiated via various applications are illustrated in the drawings, and these include:

[0042] • Requests initiated via a service of a mobile phone company - Figure 17;

[0043] In this embodiment, a phone subscriber, who could be a payer, a payee, or a third party, is able to use the USSD or IVR or any other service provided by a phone company to facilitate a payment transaction. Here, all inputs for a payment request can be entered and submitted by the phone subscriber to the payment service via:

[0044] • a USSD session that is called from a phone application by dialing a service code that is associated with the payment service; or

[0045] • a USSD message string comprising of the service code and submitted to the phone company via the phone application; or

[0046] • an IVR session that is called from a phone application by dialing a phone number that is associated with the payment service;

[0047] • Requests initiated via a messaging or social media application - Figure 18;

[0048] In this embodiment, a messaging app may be able to facilitate payment between its users via the messages sent between the users. A messaging app may be configured with a parser such that when a message is sent from a first user to a second user via the app, the app intercepts the message and via the parser, determines whether or not a payment request is embedded in the message, and, thereafter, in response to a determination that a payment request exists in the message, determines whether or not the parties to the transaction have one or more accounts stored in the database associated with the payment service. If a determination is made that a valid payment request exists, then the message is delivered to the message interface associated with the first and second users. Once the payer consents to proceed with the transaction, the messaging app sends the payment request to the payment service for processing.

[0049] • Requests initiated via an electronic toll company (ETS) application - Figure 19;

[0050] Due to the payment services’ ability to receive data from various sources, this invention makes the interoperability of various ETS systems possible. This means that a vehicle that has a tag from a first ETS may go through a toll plaza associated with a second ETS and still be charged even though the vehicle tag is not registered to the second ETS. It also means that even when a vehicle that is not registered to any ETS passes through a toll plaza, the vehicle license plate may be captured by a camera and upon extraction of

[0051] SUBSTITUTE SHEET (RULE 26) the plate number, the database associated with the payment service or payment service may be searched for the plate number thus leading to the identification of eligible accounts to be debited for the toll fee.

[0052] • Requests initiated via a payment link;

[0053] Current art teaches that a payment link must be registered with the payment service. However, this disclosure teaches a new method whereby a payment link is constructed using a published URL format such that when the constructed link is delivered to the payer and subsequently activated by the payer, the payment service is able to read the fields contained in the link and thereafter request for additional information from the payer. At its simplest, the payment link may consist of only one field - an alias associated with the payee. In this case, once a payer clicks on the link the payer would be prompted to provide an alias associated with the payer, and an amount and corresponding currency in order to create a payment request for execution.

[0054] This invention teaches that, in order to participate in a payment transaction, it is optional for any entity to download and install a payment application onto the computing apparatus associated with the entity, or to register one or more aliases, or to store personal information, including credentials for one or more authorized payment methods, wherein such data may be stored either in the payment application or within the payment service.

[0055] A key feature of this disclosure is the upfront and regular aggregation of account data from participating account providers. This feature ensures that an account holder does not need to enter critical payment credentials into any payment application that implements an interface with the payment service.

[0056] An account provider is any entity that provides account services to an entity, including financial institutions like banks and credit card companies and non-financial institutions like merchants and telecommunications companies, just to name a few.

[0057] An example of an alias is a phone number or an email address that belongs to an account holder at an account provider like a bank where the alias is already registered to the account holders’ account. Due to the fact that there are several unique account holder attributes that are stored with account providers, it means that there are potentially many aliases that could be used in this invention.

[0058] Upon receipt of a payment request from a payment application, a search is performed in the database associated with the payment service to determine if the aliases have any associated accounts. Upon retrieval of accounts, the payment service conducts the step of selecting the relevant accounts for each entity by using one or more methods.

[0059] SUBSTITUTE SHEET (RULE 26) Once the accounts for all parties have been successfully identified, and the payers have been optionally authenticated, then the next step of executing payment instructions commences. This involves sending payment and settlement instructions to the relevant account providers associated with the selected accounts to effect the transfer of value between the accounts. An embodiment of this step is illustrated in Figure 1.

[0060] The invention provides for many scenarios in which an account may be selected or deselected. Once one or more accounts are retrieved from the database on the basis of an alias, the invention teaches deselecting, by the payment service, in order to obtain eligible accounts, from the one or more retrieved accounts:

[0061] • any account that is associated with a payer and is restricted from debit operations by the account provider associated with the account and / or the payment service;

[0062] • any account that is associated with a payee and is restricted from credit operations by the account provider associated with the account and / or the payment service;

[0063] • any account that is denominated in a first currency that can not be exchanged by the payment service into a second currency required by one or more payees; and

[0064] • if the party is a payer, and if real-time settlement is required by one or more account providers associated with one or more payees, any account that is associated with an account provider that has insufficient funds to participate in real-time settlement;

[0065] The invention also teaches that the account or set of accounts selected for a payer are expected to have a total available balance that is sufficient to fulfill the payment request. Initially, the payment service attempts to select only one account to fulfill the transaction. However, if there is no single account that has the sufficient funds, then the payment service proceeds to select one or more additional accounts.

[0066] Similarly, the invention teaches that the payment service attempts to first select an account for a payee that is identified by an alias. If this fails, then the payment service proceeds to the following options:

[0067] • If no account exists for the payee, then an instant account is opened for the payee.

[0068] • If an account exists for the payee and if the account has a maximum account balance limit that may be breached if the inflow to the account is allowed, or if the amount to be credited to the account is greater than a maximum deposit limit, then the payment service is configured to select one or more additional accounts for the payee. In doing this, one or more instant accounts may be opened for the payee.

[0069] • If an account exists for the payee and if funding the account is likely to cause a breach of a maximum account provider limit, then the payment service is configured to select one

[0070] SUBSTITUTE SHEET (RULE 26) or more additional accounts for the payee, albeit from one or more different account providers . In doing this, one or more instant accounts may be opened for the payee.

[0071] Any of the limits mentioned above may be specified by the payee or by the account provider.

[0072] The invention teaches that if the payment service is unable to select any account associated with an entity, or if the payment service selects an account that is not preferred by the entity, then the entity is provided with the ability to specify either a preferred account or set of preferred accounts to be used in fulfilling the payment request.

[0073] While there could be many embodiments of the step of selecting accounts, one embodiment of this step is collectively illustrated in Figure 2, Figure 3 and Figure 4.

[0074] The invention teaches various selection criteria for selecting one or more accounts for each transaction party. These selection criteria include, but are not limited to: a. selecting, for a payer, any eligible account that is associated with an available balance or credit limit that is sufficient to fulfill the transaction amount associated with the payer; alternatively, if partial payment is permitted by one or more payees, or if more than one account is to be selected, then the selection criteria includes selecting any eligible account that is associated with an available balance or credit limit that is sufficient to partially fulfill the payment request subject to any minimum required payment specified by the one or more payees; wherein if the payment request is unfulfilled or partially fulfilled, then the payment request may remain in queue, and, at periodic intervals specified either by any of the one or more payees or by the payment service, until the partially-fulfilled payment request is completely fulfilled, the steps associated with processing a payment request may be re-executed, by the payment service, for the unfulfilled portion of the payment request; b. selecting, for a payer, any eligible account that is a loyalty or reward account associated with the payment application or a payee; c. selecting any eligible account that is the most preferred by the party associated with the account; d. selecting, for a payer, any eligible account that is associated with an account provider whose settlement account has sufficient funds to accommodate each debit instruction; e. selecting any eligible account that is associated with an account provider, wherein the account provider is also associated with all the accounts selected or specified for all the parties, thus obviating the need for settlement across various different account providers; f. selecting any eligible account that is most preferred by any other party associated with the payment request;

[0075] SUBSTITUTE SHEET (RULE 26) g. selecting any eligible account that is most preferred by the entity associated with the payment application; h. selecting, for a payee, more than one account if selecting a single account is likely to cause a maximum deposit limit or a maximum account provider limit to be breached;

[0076] The invention also teaches that authentication may be carried out by the payment application using any authentication method that is known to the art.

[0077] In an embodiment of this disclosure, a payment application like a banking application may require a payer who is also an account holder at the bank to use existing login credentials to gain access to the mobile banking application that also serves as the payment application that interfaces with the payment service. Upon successful login and authorization of the pending transaction, the banking application authenticates the payer and notifies the payment service accordingly.

[0078] In another embodiment of this disclosure, a messaging or social media application may also serve as a payment application by implementing an API interface with the payment service. In order to authenticate the payer, who also happens to be a registered entity of the messaging or social networking application, the payer is requested to enter a password that the application typically uses for authentication. Upon successful authentication, the messaging or social media application notifies the payment service accordingly. See Figure 18.

[0079] In another embodiment of this disclosure, the payment service may send a one-time password to the account provider-registered phone number of a payer, who in turn submits this password to a payee, who in turn enters this password into the payment application. The payment application then transmits this password to the payment service who then authenticates the payer by successfully matching the password that was sent with the password that was received.

[0080] An embodiment of a one-time password authentication method implemented by the payment service in an in-person scenario is illustrated in Figure 5 and Figure 6.

[0081] In addition, an embodiment wherein an authentication carried out by biometric facial recognition is illustrated in Figure 12.

[0082] It should be noted that data messaging between the various computing apparatuses and devices is platform-agnostic. Data communication between the payment application and any party may occur via USSD (Unstructured Supplementary Service Data), IVR (Interactive Voice Response), web or mobile web, or any other data communication technology supported by the various computing apparatus involved in executing the method.

[0083] SUBSTITUTE SHEET (RULE 26) An embodiment of the invention wherein a payment request is sent via USSD from any phone type, feature phone or smartphone, is described in Figure 19. In this embodiment, it is permissible for both the payers’ phone and the payees’ phone to be feature phones, wherein both phones are not connected to the Internet, and wherein a payment request can be successfully processed without both parties revealing their account details to any third party either before or during the transaction.

[0084] In an embodiment of an online scenario, a merchant receives customer information on a website and proceeds to determine if the alias provided by the customer returns any accounts. Once this is established, the payment service notifies the merchant of its ability to process the payment request. This gives the merchant the opportunity to seek the consent of the customer to proceed with the payment transaction. In response to the customer consenting to proceed, the payment service proceeds to authenticate the customer by sending a one-time password to the phone number registered at the account provider associated with the selected account. The customer then enters this password into the checkout page on the website which automatically leads to a payment authorization if the authentication is successful. An illustration of this embodiment is illustrated in Figure 7.

[0085] Further extensions or embodiments of this online scenario include when the payment service intelligently selects and presents, for payment processing:

[0086] • an option to pay with a bank account - Figure 10;

[0087] • an option to pay with a credit card - Figure 11 ;

[0088] • an option to make a split payment with two bank accounts - Figure 8.

[0089] This split payment feature is particularly useful if the payment service is unable to identify any single account with a sufficient balance to fulfill the payment request. Under such circumstances, the payment service is able to select more than one account for the payment request;

[0090] • an option to pay with either a loan or a bank account - Figure 15.

[0091] In this embodiment, the payment service presents more than one mode of payment to the payer. The loan is an offer from a credit provider who is a participant in the payment scheme and who is able to instantly determine the payers’ eligibility for a loan;

[0092] • an option to defer payment - Figure 16.

[0093] In this embodiment, the store or payee may directly offer credit to the payer and allow the payer to defer payment to a later date. The payment service may treat this transaction as an interest-free loan;

[0094] In an example of an offline scenario, a merchant may send an email to a customer with an invoice and a payment link or a pay button such that upon clicking on the link or on the button, the payment service automatically presents an account associated with the customer for payment on behalf of the customer and asks the customer to proceed to authenticate the transaction by

[0095] SUBSTITUTE SHEET (RULE 26) receiving and inputting an OTP. Illustrations of this embodiment are described in Figure 9 and Figure 10.

[0096] A further embodiment, that describes how a payer account with a different currency from a payee account can be selected and presented, along with an exchange rate, to the payer, is illustrated in Figure 11. In another embodiment, the payment application may be associated with a payer that invites a payee to participate in a payment transaction. An illustration of this embodiment is illustrated in Figure 12.

[0097] The invention also allows a payment application to determine, upfront, if the payment service has the ability to process a payment request involving a particular entity. In practice, this could prove useful, for example, as a preliminary check in determining whether or not a payment application should eventually present a payment request to the payment service. A particular embodiment of this feature is illustrated in Figure 13.

[0098] In conclusion, while the above is a complete description of the preferred embodiments of the invention, it should be noted that there are various alternatives, modifications, and equivalents that can be used. It should also be evident that the invention is equally applicable by making appropriate modifications to the embodiments described above. Therefore, the above description along with the accompanying drawings should not be taken as limiting the scope of the invention that is defined by the metes and bounds of the appended claims along with their full scope of equivalents.

[0099] REFERENCES

[0100] SUBSTITUTE SHEET (RULE 26)

[0101] CLASSIFICATIONS

[0102] 1. G06Q20 / 10 - Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems

[0103] 2. G06Q20 / 16 - Payments settled via telecommunication systems

[0104] 3. G06Q20 / 227 - Payment schemes or models characterized in that multiple accounts are available, e.g. to the payer

[0105] 4. G06Q20 / 326 - Payment applications installed on the mobile devices

[0106] 5. G06Q20 / 3274 - Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device

[0107] 6. G06Q20 / 3278 - RFID or NFC payments by means of M-devices

[0108] 7. G06Q20 / 385 - Payment protocols; Details thereof using an alias or single-use codes

[0109] 8. G06Q50 / 01 - Social networking

[0110] 9. G07B 15 / 063 Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station

[0111] 10. H04L51 / 04 Real-time or near real-time messaging, e.g. instant messaging [IM]

[0112] SUBSTITUTE SHEET (RULE 26) BRIEF DESCRIPTION OF THE DRAWINGS

[0113] To illustrate the manner in which the advantages and features of the invention are obtained, a description of the present invention is given with reference to the attached drawings. These drawings only illustrate selected aspects of the invention and thus do not fully determine the invention's scope.

[0114] Figure 1 illustrates the different generalized payment process workflows that include Figures 1, 2, 3, 4, 5, 6, 7 and 8.

[0115] Figure 2 and Figure 3 illustrate how accounts are independently selected by the payment service.

[0116] Figure 4 illustrates the account selection when partial payments are allowed.

[0117] Figure 5 illustrates an in-person or in-store payment transaction process flow

[0118] Figure 6 illustrates a sequence of user interfaces for an in-person or in-store payment transaction.

[0119] Figure 7 illustrates an online payment transaction process flow.

[0120] Figure 8 illustrates a sequence of user interfaces for an online payment transaction where payment is made from two bank accounts belonging to a payer.

[0121] Figure 9 illustrates an offline payment process flow in which a payer is invited to participate in a payment transaction by a payer.

[0122] Figure 10 illustrates a sequence of user interfaces for an offline payment transaction in which a payer is invited to participate in a payment transaction by a payer.

[0123] Figure 11 illustrates a sequence of user interfaces for an offline payment transaction in which the selected paying account has a different currency from the payee account.

[0124] Figure 12 illustrates an offline payment process flow in which a payee is invited to participate in a payment transaction by a payer with biometric authentication

[0125] Figure 13 illustrates how a payment request to determine whether or not the payment service is capable of processing a payment request involving a payer is handled.

[0126] Figure 14 illustrates a generalized embodiment of the process flow for processing a payment request

[0127] RECTIFIED SHEET (RULE 91 ) Figure 15 illustrates a sequence of user interfaces for an online payment transaction where a payer is offered the opportunity of drawing on a loan to make payment.

[0128] Figure 16 illustrates a sequence of user interfaces for an online payment transaction where deferred payment is offered to a payer.

[0129] Figure 17 illustrates a user interface and process flow for a USSD implementation of an in-person payment transaction where the payee and payer may have relied exclusively on feature phones without any internet connectivity.

[0130] Figure 18 illustrates a process flow for a messaging or social media application implementation of a payment transaction where the payee and payer are both users of the messaging or social media application.

[0131] Figure 19 illustrates a process flow for an electronic toll gate application.

[0132] RECTIFIED SHEET (RULE 91 )

Claims

CLAIMSWhat I claim is:

1. A computer- implemented method for facilitating, by a payment service, a payment transaction involving a plurality of parties and their respective account providers, wherein, prior to or during the payment transaction, it is optional for any party: to register or enroll, with any other party or the payment service, any information associated with the party; or to provide, to any other party or the payment service, any payment account information associated with the party; or to select, from any list presented by the payment service, any payment account information associated with the party; or to be authenticated by any account provider associated with the party; said method comprising of the following steps: receiving, by the payment service, from one or more account providers associated with the payment service, prior to the payment transaction, into a data repository associated with the payment service, account information associated with each account held at each account provider; initiating, by a party or a third party via a payment application associated with the payment service, a payment request; wherein the payment request may include, but is not limited to, an alias associated with the payee, an alias associated with the payer, a payment amount, and a payment currency; wherein the payment application may receive input associated with the payment request from any party either manually or via any data communication method associated with any computing apparatus associated with the party, including, but not limited to, via a browser, or via a quick response (QR) code, or via a wireless data transfer, or via a payment card, or via a camera, or via a scanner;SUBSTITUTE SHEET (RULE 26)sending, by the payment application, to the payment service, the payment request for processing; retrieving, by the payment service, for each alias contained in the payment request, from the data repository, one or more account providers associated with each alias, and, if available, the account information associated with each alias at the one or more account providers; and / or retrieving, by the payment service, for each alias contained in the payment request, from one or more account providers associated with the payment service, account information associated with each alias at the one or more account providers; retrieving, optionally, by the payment service, for each alias contained in the payment request, from the one or more account providers associated with each alias, updated account information associated with each alias; sending, optionally, by the payment service, to the payment application, if the account information retrieval is successful, a notice of successful account retrieval; selecting, by the payment service, for each party represented by an alias, from the retrieved payment account information, any one or more of the retrieved payment accounts to be used for fulfilling the payment request; sending, optionally, by the payment service, to the application, in response to a successful account selection, a notice of successful account selection; authenticating, optionally, by the payment service, each payer; fulfilling, by the payment service, the payment request; wherein each account information is associated with a payment account and includes at least an alias and an account provider identifier; wherein an alias includes a phone number, an email address, a tax identification number, or any other unique identifier associated with the party;2. The computer-implemented method as claimed in claim 1, wherein if the payment application is associated with a payment link, then said method may further comprise of the following steps:SUBSTITUTE SHEET (RULE 26)constructing, by an initiating entity, prior to the payment transaction, the payment link; wherein the payment link is comprised of a uniform resource locator (URL) associated with the payment service; wherein the initiating entity may be a payee or a third party; wherein the payment link may be constructed with a URL format comprising of a field representing an alias associated with the third party, if any; and a field representing an alias associated with the payee; and, at least, any one or more of the following fields: an alias associated with the payer; a payment amount; and a payment currency; sending or presenting, by the initiating entity, to the payer, the payment link; activating, by the payer, the payment link; receiving, by the payment service, from the payer, the payment link; extracting, by the payment service, from the payment link, the one or more fields contained in it; retrieving, by the payment service, for the alias associated with the payee, from the data repository, and, optionally, from the one or more account providers associated with the payment service, account information associated with one or more payment accounts held by the payee; sending or presenting, by the payment service, to the payer, if account information was successfully retrieved for the payee, a request for any one or more elements not extracted from the payment link, such elements including, but not limited to, an alias associated with the payer; a payment amount; and a payment currency; retrieving, by the payment service, for the alias associated with the payer, from the payment service, and, optionally, from the one or more account providers associated with the alias, account information associated with one or more payment accounts held by the payer; generating, by the payment service, if at least one payment account is successfully retrieved for each party, a payment request comprised of, at least, the alias associated with the payee, the alias associated with the payer, the payment amount, and the payment currency;SUBSTITUTE SHEET (RULE 26)authenticating, optionally, by the payment service, the payer; selecting, by the payment service, from the retrieved one or more payment accounts, for each party, any one or more payment accounts to be used for fulfilling the payment request; fulfilling, by the payment service, the payment request;3. The computer-implemented method as claimed in claim 1, wherein if the payment application is associated with a messaging or social networking application, then said method may further comprise of the following steps: posting, by a first user on the messaging or social networking application, a message to a message interface of the messaging or social networking application associated with the first user and, at least, a second user; wherein the message interface may include, but is not limited to, a chat room, intercepting, by a payment application running in the background of the messaging or social networking application, the message before transmittal to the message interface; examining, by the payment application, the intercepted message, to identify any pattern using one or more methods of machine learning and / or artificial intelligence, and / or any keywords, and / or any references to one or more parties, and / or any numerical amounts, and / or any currencies, that may suggest that the intercepted message includes a payment request; retrieving, by the payment application, from the messaging or social networking application, if it is determined that the message includes a payment request, and if it is also determined that one or more of the parties identified in the payment request are users of the messaging or social media application, the phone number and / or email address associated with the users; sending, by the payment application, to the payment service, for each party, the phone number and / or email address and / or user identifier associated with the party; retrieving, by the payment service, from the data repository and / or one or more account providers, for each alias, one or more payment accounts;SUBSTITUTE SHEET (RULE 26)sending, by the payment service, to the payment application, if at least one payment account is retrieved for each user, a notice of successful account retrieval; generating, by the payment application, in response to receiving the notice of successful account retrieval, a payment request comprised of, at least, an alias associated with the first user or payee, an alias associated with a second user or payer, a payment amount, and a payment currency; prompting, by the messaging or social networking application, the first user to validate the payment request generated by the payment application; transmitting, by the messaging or social networking application, in response to the validation of the payment request by the first user, the message to the message interface; receiving, by the second user on the messaging or social networking application, the message; obtaining, by the messaging or social networking application, from the second user, if the second user is a payer, confirmation to proceed with the payment request; authenticating, optionally, by the messaging application, the payer; selecting, by the payment service, from the retrieved one or more payment accounts, for each party, any one or more payment accounts to be used for fulfilling the payment request; fulfilling, by the payment service, the payment request;4. The computer-implemented method as claimed in claim 1, wherein if the payment application is associated with an unstructured supplementary service data (USSD) service of a mobile communications provider, then said method may further comprise of the following steps: initiating, by an initiating entity, on a phone or a phone interface, a USSD session, by constructing and sending a text string to the USSD service; wherein the initiating entity may be a payee or a third party; wherein the text string may be constructed with a format comprising of:SUBSTITUTE SHEET (RULE 26)a field representing a USSD code associated with the payment service; and, optionally, an alias associated with the payee; an alias associated with the payer; a payment amount; and a payment currency; or, an alias associated with the payer; a payment amount; and a payment currency; or an alias associated with the payer; and a payment amount; wherein if the required fields for a payment request are not included in the text string, then the initiating entity is prompted to provide any one or more inputs required for generating the payment request; sending, by the USSD service, to the payment service, the fields contained in the USSD session, and the phone number associated with the initiating entity; retrieving, by the payment service, for the alias associated with each party, from the data repository, and, optionally, from the one or more account providers associated with the payment service, account information associated with one or more payment accounts held by each party; generating, by the payment service, if at least one payment account is successfully retrieved for each party, a payment request comprised of, at least, the alias associated with the payee, the alias associated with the payer, the payment amount, and the payment currency; authenticating, optionally, by the payment service, the payer; selecting, by the payment service, for each party, from the retrieved one or more payment accounts, any one or more payment accounts to be used for fulfilling the payment request; fulfilling, by the payment service, the payment request;5. The computer-implemented method as claimed in claim 1, wherein if the payment application is associated with an interactive voice response (IVR) service of a telecommunications provider, then said method may further comprise of the following steps:SUBSTITUTE SHEET (RULE 26)dialing, by an initiating entity, to initiate a session associated with the IVR service, a phone number associated with the IVR service; wherein the initiating entity may be a payee or a third party; providing, by the initiating entity, to each request within the session, the requested inputs; wherein the inputs expected to be provided during the session include, at least, an alias associated with a payer, a payment amount, a payment currency; sending, by the IVR service, to the payment service, the payment request inputs including the phone number of the payee; retrieving, by the payment service, for the alias associated with each party, from the data repository, and, optionally, from the one or more account providers associated with the payment service, payment account information associated with one or more payment accounts; generating, by the payment service, if at least one payment account is successfully retrieved for each party, a payment request; selecting, by the payment service, from the retrieved one or more payment accounts, for each party, any one or more payment accounts to be used for fulfilling the payment request; authenticating, optionally, by the payment service, the payer; fulfilling, by the payment service, the payment request;6. The computer-implemented method as claimed in claim 1, wherein if the payment application is associated with a pay wall service of a content provider, then said method may further comprise of the following steps: receiving, by the paywall service, from a content user, a request to access content hosted by the content provider, wherein access to said content is restricted by the paywall service; receiving, by the content user, from the content provider, a request to provide an alias associated with the content user;SUBSTITUTE SHEET (RULE 26)receiving, by the paywall service via the content provider, from the content user, one or more aliases associated with the content user; wherein the alias may be provided by the content user manually, or extracted by the content provider from any object associated with the content user, including, but not limited to, a cookie, or a hypertext transport protocol (HTTP) session; sending, by the pay wall service, to the payment service, the received and / or extracted one or more aliases; retrieving, by the payment service, for each alias, from the data repository, and, optionally, from the one or more account providers associated with the payment service, payment account information associated with one or more payment accounts; sending, optionally, by the payment service, to the paywall service, if the retrieval is successful, a notice of successful account retrieval; generating, by the paywall service, a payment request comprising of at least, an alias associated with the content provider or payee, the one or more aliases associated with the content user or payer, a payment amount, and a payment currency; sending, by the paywall service, to the payment service, a payment request for processing; selecting, by the payment service, from the retrieved one or more payment accounts, for each party, any one or more payment accounts to be used for fulfilling the payment request; sending, optionally, by the payment service, to the paywall service, in response to a successful account selection, a notice of successful account selection; authenticating, optionally, by the payment service, the payer; fulfilling, by the payment service, the payment request; granting, by the paywall service, to the content user, in response to receiving a notice of successful payment execution, permission to access the restricted content;SUBSTITUTE SHEET (RULE 26)7. The computer-implemented method as claimed in claim 1, wherein if the payment application is associated with an electronic tolling service (ETS), then said method may further comprise of the following steps: reading, by a transceiver and / or an image capturing device associated with the ETS, when a vehicle passes through a toll facility associated with the ETS, a unique identifier associated with a signal-emitting device located in or on the vehicle, and / or, a vehicle license plate number associated with the vehicle; sending, by the transceiver and / or the image capturing device, to the ETS, the unique identifier associated with the signal-emitting device and / or the vehicle license plate number; retrieving, by the ETS, from the data repository and / or from the ETS, one or more aliases associated with the vehicle owner using the unique identifier associated with the signal-emitting device and / or the vehicle license plate number; generating, by the ETS, if at least one alias is retrieved, a payment request comprised of, at least, an alias associated with the ETS or payee, the one or more aliases associated with the vehicle owner or payer, a payment amount, and a payment currency; sending, by the ETS, to the payment service, the payment request; retrieving, by the payment service, for each alias associated with each party in the payment request, from the data repository, and, optionally, from the one or more account providers associated with the payment service, payment account information associated with one or more payment accounts; selecting, by the payment service, from the retrieved one or more payment accounts, for each party, any one or more payment accounts to be used for fulfilling the payment request; authenticating, optionally, by the payment service, the payer; fulfilling, by the payment service, the payment request; granting, optionally, by the ETS, to the vehicle, in response to a notice of successful payment execution from the payment service, access to pass through the tolling facility;8. The computer-implemented method as claimed in claim 7,SUBSTITUTE SHEET (RULE 26)wherein, for interoperability between a plurality of electronic tolling services in order to allow a vehicle that is registered with a first ETS to make a payment to a second ETS, the payment service, prior to the payment transaction, may receive account data, for a plurality of vehicles belonging to a plurality of vehicle owners from the plurality of ETS, including, from the first ETS and second ETS;9. The computer-implemented method as claimed in claim 7, wherein, for interoperability between a plurality of electronic tolling services in order to allow a vehicle that is not registered with any ETS to make a payment at the ETS, the payment service, prior to the payment transaction, may receive account data for a plurality of vehicles belonging to a plurality of vehicle owners from one or more vehicle licensing agencies;10. The computer-implemented method as claimed in claims 1 to 7, wherein, if a payer is represented by one or more aliases, then the step of selecting a payment account for the payer further comprises of the following steps: deselecting, by the payment service, from the retrieved accounts, any account whose account status indicates a restriction on the withdrawal of funds from the account; or, any account that is neither denominated in the currency requested by the payee, nor denominated in a currency that is convertible to the currency requested by the payee; or, any account that is associated with an account provider that has insufficient funds required for real-time settlement of the payment request, if real-time settlement is required; selecting, optionally, by the payment service, any account associated with a loyalty or reward program that is offered by the payee to fully or partially fulfill the payment request; selecting, optionally, by the payment service, any account that is associated with the account provider that is associated with the payee’s account; selecting, optionally, by the payment service, any account that has the highest net benefit attributable to the payer, or to the payee, or to the payment service; selecting, optionally, by the payment service, any account that is most likely to be selected by the payer based on account provider data;SUBSTITUTE SHEET (RULE 26)selecting, by the payment service, any single account that has sufficient funds to completely fulfill the payment request; or, any plurality of accounts that collectively have sufficient funds to completely fulfill the payment request, wherein none of the selected accounts breaches any payment limit associated with the account; or, any one or more accounts that collectively have sufficient funds to partially fulfill the payment request, if partial payment is permitted by the payee; allocating, by the payment service, if the payment service selects more than one account, to each of the selected accounts, a payment amount; wherein, if a payee is represented by one or more aliases, then the step of selecting an account for the payee further consists of the following steps: deselecting, by the payment service, from the retrieved accounts, any account whose status indicates a restriction on the deposit of funds into the account; selecting, by the payment service, from the retrieved accounts less any deselected accounts, any one account, or any plurality of accounts, subject to no selected account breaching any deposit limit associated with the account; allocating, by the payment service, if the payment service selects more than one account, to each of the selected accounts, a payment amount; opening, by the payment service, if the account selection is unsuccessful, an account for the payee, and, thereafter, selecting the newly opened account; said method further comprising of the following steps: sending, by the payment service, to the application, in response to a successful account selection, a notice of successful account selection; providing, optionally, by the application, in response to receiving a notice of successful account selection, each payer with an opportunity to replace the one or more selected accounts with any other one or more retrieved accounts;11. The computer-implemented method as claimed in claims 1 to 7, wherein the step of selecting a payment account for the payer may further comprise of the following steps:SUBSTITUTE SHEET (RULE 26)retrieving, by the payment service, from the payment service and / or one or more account providers, one or more deferred payment offers associated with the one or more aliases; selecting, by the payment service, any one of the received offers; sending, by the payment service, to the application, the selected offer; presenting, by the application, to the payer, the option of accepting the selected offer;12. The computer-implemented method as claimed in claims 1 to 7, wherein an alias associated with a first account holder may be linked by the payment service to a second account holder, such that when the alias is presented by a payer in a payment transaction, the payment service selects, for the payer, one or more accounts associated with the second account holder, subject to any payment limits set for the one or more accounts by the second account holder;13. The computer-implemented method as claimed in claims 1 to 7, wherein, prior to sending the debit instruction to the relevant account provider, the payment application may authenticate the payer by using: any authentication method implemented by the payment application; or an authentication method associated with the payment service, said method comprising of the following steps: causing, by the payment application, the payment service to send a one-time password (OTP) to the phone number and / or email address of the payer; providing, by the payer, to the initiating entity associated with the payment application, the OTP; or entering, by the payer, into the payment application, the OTP; sending, by the payment application, to the payment service, the OTP received from the payer; and receiving, by the payment application, a response from the payment service on the validity of the received OTP with respect to the sent OTP;SUBSTITUTE SHEET (RULE 26)14. The computer-implemented method as claimed in claims 1 to 7, wherein the step of fulfilling the payment request is further comprised of the following steps: generating, by the payment service, for each selected account associated with the payer, a debit instruction consisting of, at least, an identifier associated with the selected account, and a payment amount; sending, by the payment service, to each account provider associated with a debit instruction, the debit instruction; executing, by each account provider, each debit instruction; sending, by each account provider, to the payment service, if the execution is successful, a notice of successful payment execution; sending, by the payment service, to the payment application, and, optionally, to the payer and the payee, in response to receiving the notice of successful payment execution for all the one or more debit instructions, a notice of successful payment execution; performing, by the payment application, in response to receiving the notice of successful payment execution, any post-payment operation; generating, by the payment service, in response to the successful execution for all the one or more debit instructions, for each account selected for the payee, a credit instruction consisting of, at least, an identifier associated with the selected account, and a payment amount; sending, by the payment service, to each account provider associated with a credit instruction, either instantly or on a deferred basis, the credit instruction;15. The computer-implemented method as claimed in claims 1 to 7, wherein, if the payment request is partially fulfilled, then the payment service may keep the payment request in a queue, and, at regular intervals or at a fixed date in the future, reprocess the payment request by: re-selecting one or more payment accounts for the payer; and fulfilling the payment request for the unfulfilled payment amount;SUBSTITUTE SHEET (RULE 26)

Images