Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
  • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/22—Payment schemes or models
  • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4014—Identity check for transactions
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4015—Transaction verification using location information
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/405—Establishing or using transaction specific rules

Definitions

• FIG. l is a diagram of an example computing environment for an automated multi-party transaction decisioning system, in accordance with one or more aspects described herein.
• Current systems lack the ability to proactively identify, detect, and/or predict transactions that are likely multi-party transactions or to identify, detect, and/or predict events that may result in such multi-party transactions.
• Current systems also lack the ability to link payments received from others, in response to a request to share or split a transaction, with an original transaction at the source so that the requesting user is aware that the received payment is associated with a prior request to split a particular transaction.
• Current systems are unable to address these problems because such systems are generally third- party systems that do not source the transactions. These systems do not have access to the information or the data necessary to actively identify transactions that are potential multi-party transactions or to manage receipt of requested payments for such multi-party transactions by associating such received payments with their original counterpart transactions.
• the multi-party transaction decisioning device 110 may be a computing device, such as a server, used by a banking institution or other financial institution to provide functionality associated with processing banking and/or credit card transactions; determining, detecting, predicting, and/or identifying transactions that may be associated with more than one party, such as transactions for expenses shared by multiple individuals; identifying parties to such shared or multi-party transactions; and delegating portions of the amounts of such multi-party transactions to the various identified parties.
• a computing device such as a server, used by a banking institution or other financial institution to provide functionality associated with processing banking and/or credit card transactions; determining, detecting, predicting, and/or identifying transactions that may be associated with more than one party, such as transactions for expenses shared by multiple individuals; identifying parties to such shared or multi-party transactions; and delegating portions of the amounts of such multi-party transactions to the various identified parties.
• the database 130 may store information used by the multi-party transaction decisioning device 110, the one or more user computing devices 140, the one or more delegate computing devices 150, and/or the payment processing system 160.
• the database 130 may comprise one or more of a relational database, a hierarchical database, a distributed database, an in-memory database, a flat file database, an XML database, a NoSQL database, a graph database, or the like.
• the second user computing device 140b may access, using a website and via the public network 180, the banking application 111 installed at the multi-party transaction decisioning device 110.
• the multiparty transaction decisioning device 110 may be embodied in the one or more user computing devices 140.
• the one or more user computing devices 140 may be any type of computing device or combination of devices capable of performing the particular functions disclosed herein.
• the one or more user computing devices 140 may be and/or include server computers, desktop computers, laptop computers, tablet computers, smart phones, fitness devices, or the like that may include one or more processors, memories, communication interfaces, storage devices, and/or other components.
• the one or more user computing devices 140 in some instances, may be or include special-purpose computing devices configured to perform the functions disclosed herein. In some instances, some or all of the functionality of the multi-party transaction decisioning device 110 may instead be performed by any of the one or more user computing devices 140 alone or in combination with the multi-party transaction decisioning device 110.
• the memory 215 may store software to provide instructions to the one or more processors 203 allowing the computing device 200 to perform various actions.
• the memory 215 may store software used by the computing device 200, such as the operating system 217, applications 219, and/or the database 221.
• the various hardware memory units in the memory 215 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data.
• the memory 215 may include one or more physical persistent memory devices and/or one or more non-persistent memory devices.
• the multi-party event generation module 118 may be used by the multi-party transaction decisioning device 110 to generate a new multi-party event in the multi-party transaction decisioning system 100. For instance, as described above, if the event detection module 115 detects a potential event and the user confirms that potential event is a multi-party event that should be created in the multi-party transaction decisioning system 100, the multi-party transaction decisioning device 110 may control the multi-party event generation module 118 to generate and store a new multi-party event in the database 130 and/or in a memory associated with the user computing device 140a.
• the multi-party event generation module 118 may automatically identify and pre-populate the user interface with contact information, such as an email address, a phone number, a social media handle, etc., associated with the identified parties using the user’ s contact data, social media data or the like. Alternatively or additionally, the multi-party event generation module 118 may provide the user with prompts to manually enter or import contact information for the identified parties or to manually link the identified parties with corresponding contact information stored at the user’s device, such as the user computing device 140a.
• contact information such as an email address, a phone number, a social media handle, etc.
• the machine learning module 119 may be used by the multi-party transaction decisioning device 110 to train one or more machine learning models and/or algorithms used for identifying multi-party transactions.
• the multi-party transaction decisioning device 110 may use various machine learning models and/or algorithms, such as, but not limited to, supervised learning algorithms, unsupervised learning algorithms, regression algorithms (e.g., linear regression, logistic regression, etc.), instance based algorithms (e.g., learning vector quantization, locally weighted learning, etc.), regularization algorithms (e.g., ridge regression, least-angle regression, etc.), decision tree algorithms, Bayesian algorithms, clustering algorithms, artificial neural network algorithms, classification algorithms, ranking algorithms, etc.
• supervised learning algorithms e.g., unsupervised learning algorithms, regression algorithms (e.g., linear regression, logistic regression, etc.), instance based algorithms (e.g., learning vector quantization, locally weighted learning, etc.), regularization algorithms (e.g., ridge regression, least-angle regression, etc.), decision tree algorithms, Bayesian
• the machine learning model may determine, using the user’s spend profile, that the user normally spends in the range of $20-$50 at restaurants similar to The Best Restaurant and, using the merchant profile, may determine that customers, on average, spend between $40-$70 at The Best Restaurant.
• the model may determine that the user’s $200 transaction represents a spike above a threshold amount, relative to the user’s spend profile and/or the merchant profile, and may determine with 90% confidence that the transaction is likely a multi-party transaction.
• the model may output a prediction that the transaction is a multi-party transaction with a confidence score of 90.
• the system may determine that the confidence score satisfies a confidence score threshold and as a result may determine that the transaction is a candidate multi-party transaction.
• the party identification module 116 may alternatively or additionally attempt to identify parties associated with the candidate multi-party transactions, by monitoring or analyzing the transaction data or other data, such as email accounts, social media data, calendar data, location data, etc., of other users to identify transactions that may be related to the multi-party transaction.
• the party identification module 116 may identify contacts or friends of the user by accessing the user’s social media data or contacts data. The party identification module 116 may then monitor and/or analyze the transactions of those contacts or friends also participating in the multi-party transaction decisioning system 100 and who have provided permission for such monitoring and analysis.
• the transaction amount may be divided evenly between the user and the three additional parties, such that each is given a default allocation of 25% of the transaction amount.
• the user interface may provide prompts for the user to change, delete, or modify the identified parties, the corresponding contact information, and/or the default allocation amounts.
• step 412 if the user indicates that the candidate multi-party transaction is not a multiparty transaction, the process may proceed to step 414, where the transaction may be tagged as an individual transaction. Tagging the transaction as an individual transaction may involve the multi-party transaction identification module 114 storing, in the database 130 and/or in a memory of the user computing device 140a, an indication that the transaction is an individual transaction.
• the system may further scan John’s email containing the receipt for the rental car transaction and may identify other drivers identified as being associated with the rental car purchase.
• the system may determine that Ellen Smith and Bobby Smith are named in the receipt as additional drivers.
• the system may identify Bobby Smith as a potential party to the event and may exclude Ellen Smith as a potential party in view of the user’s preference during system configuration to exclude his wife Ellen as a party to a multi-party event or multi-party transaction.
• the multi-party event generation module 118 may create a new event after automatically identifying a multi-party transaction (see FIG. 4, step 424), after automatically detecting a potential event (see FIG. 5, step 18), or after a user requests the manual creation of a new event.
• the multi-party event generation module 118 may output a user interface to the banking application 111, which provides prompts for entering information related to the multiparty event, such as a name, a description, a start and end date, types of merchants/transactions to be associated with the event, a location associated with the event, parties associated with the event, and/or a share or percentage of transaction amounts that should be allocated to each of the parties.
• the system may output, to the banking application 111, a user interface for generating a new multi-party event and may prepopulate the user interface with the name “Trip to Houston, Texas,” start date of “June 1 st ,” end date of “June 7 th ,” and location of “Houston, Texas.”
• the user may indicate, via the user interface, that only restaurant, hotel, and sporting event related transactions/merchants should be monitored for multi-party transactions for the event.
• the notification module 117 may send the parties associated with the multiparty event a request to join the multi-party event and to share/associate their own transactions occurring during multi-party event with the generated multi-party event and/or to allow their own data to be monitored and analyzed.
• the request may be sent to the parties using the contact information indicated in the generated multi-party event.
• the multi-party transaction identification module 114 may determine whether the process to settle the transactions associated with the multi-party event should be initiated. If the user indicates that the transactions should not be settled now, the process may proceed to step 614, where the notification module 117 may be configured to set up a reminder to send a subsequent notification to the user reminding the user of the unaddressed transactions associated with the multi-party event. In some instances, the notification module 117 may prompt the user for information on when such reminder should be provided.
• the user may request to allocate to each party to the transaction only those items from the transaction actually associated with that particular party.
• the $200 dinner transaction may include amounts, or line items, for four entrees, three drinks, two appetizers, tax, and tip.
• John may have had lasagna for $20 and a beer for $9; Ellen may have had lobster for $30; Kate may have had ribeye steak for $25 and a glass of wine for $12; and Ben may have had a salad for $15 and a glass of wine for $12.
• the group may have shared appetizers for a total of $23.50.
• the tax may have totaled $13.50 and the tip $40. Accordingly, the user may wish to adjust the allocations so that each party is only allocated the items that they consumed and a portion of the amount of the items shared between the group, such as for the appetizers, the tax, and the tip.
• the payment delegation module 120 may output a user interface, via the banking application 111, displaying a listing of the net amounts owed to each party and the corresponding amounts delegated to the various parties based on the determined optimized payment scheme.
• the information may additionally include the name and contact information for the party to whom the amount is being deleted, e.g., email address, phone number, social media handle, etc.
• the delegation request may be stored in the database 130 and/or in a memory associated with the user computing device 140a.
• the payment token may comprise a URL link to a script configured to access information associated with delegation requests associated with the multi-party transaction or the multi-party event.
• the payment token link may be compressed using, for example, a URL shortener to reduce the length of the link for convenience in transmission.
• delegation messages may be generated and transmitted to John, Kate, and Ben, for the amounts delegated to each.
• a first delegation message may be transmitted to John indicating that $57.50 has been delegated to him for payment to Bobby.
• a second delegation message may be transmitted to John indicating that $120 has been delegated to him for payment to David.
• a third delegation message may be transmitted to Kate indicating that $336.25 has been delegated to her for payment to Bobby.
• a fourth delegation message may be transmitted to Ben indicating that $326.25 has been delegated to him for payment to Bobby.
• a single delegation message may be sent to the party and may include the multiple delegation requests therein. John, Kate, and Bobby may each initiate payment of their delegated amounts to their respective payees.
• the payment delegation module 120 may use the payment token to link the payment transaction with the original delegated multi-party transaction or multi-party event. For instance, the payment delegation module 120 may query the database 130, using the payment token, to identify the delegated multi-party transaction or the multi-party event having the same payment token stored therewith. The payment delegation module 120 may store, in association with the multi-party transaction or the multi-party event, the transaction identifier identifying the received payment transaction so that the payment transaction received from the delegate may be linked with the multi-party transaction or the multi-party event. The payment delegation module 120 may additionally update the corresponding stored delegation request to indicate that payment has been received from the delegate.
• the notification module 117 may cause a notification to be sent to the user notifying that a payment associated with a delegation request has been received. For instance, the notification module 117 may send an email or a text message to the user, or may output a notification via the banking application 111, notifying of receipt of a payment from the delegate.
• the notification may include a link to a user interface of the banking application 111 for displaying the multi-party transaction or the multiparty event and information associated with the received payment.
• the payment delegation module 120 may cause the banking application 111 to output a user interface displaying a transaction summary comprising the multi-party transaction with any received payment transactions attached thereto or an event summary comprising information associated with the multi-party event along with any received payment transactions attached thereto.
• the payment delegation module 140 may cause the banking application 111 to output a user interface that displays the received payment transactions underneath the original multi-party transaction, for example, to indicate that the received payment transactions are associated with the original multi-party transaction.
• the user may be able to select a multi-party transaction and an option to view associated received payments, and a list of received payments may be displayed. Additionally, received payments may be output in a similar manner when associated with a multi-party event.
• the delegate may access the payment URL by clicking on the link displayed in the delegation message or by copying and pasting the link into a web browser. Accessing the link may cause a payment process to be initiated for submitting payment from the delegate to the payee. For instance, accessing the link may trigger the execution of a script at the one or more delegate computing devices 150.
• the script may cause an application or website associated with a default payment method associated with the one or more delegate computing devices 150 to be identified and executed. Alternatively or additionally, the script may cause a request to be output at the one or more delegate computing devices 150 for the delegate to select a preferred payment method application for using in making payment to the user.
• the one or more delegate computing devices 150 may execute the application or website associated with the default or selected payment method.
• the script may call one or more APIs for interfacing with the payment application or website.
• the script and/or the API may cause one or more fields associated with the payment application or website to be prepopulated with the payment information associated with the delegation request, such as a payment amount and recipient information identifying where payment should be made.
• the recipient information need not be sensitive financial information, such as a bank account or credit card number of the user, and instead may be information identifying the payee associated with the delegation request by an email address or a phone number associated with the user, which may later be used at a secure source device, such as the multi-party transaction decisioning device 110, to access the payee’s financial information.
• the delegate may adjust the prepopulated fields as needed. For instance the delegate may adjust the payment amount to enter a different amount.
• the script and/or API executing at the one or more delegate computing devices 150 may determine whether to adjust the payment amount from the amount requested in the delegation request to a different amount. Such an adjustment may be necessary if delegation requests for a selected transaction were sent to more than one delegate and one or more of the delegates made a payment exceeding their respective requested amount, thus causing the remaining amount, of the total requested, needing to be paid by a final delegate to be less than the amount the requesting user originally requested. For instance, prior to the delegate’s submission of payment, the script and/or API may query the multi-party transaction decisioning device 110 to determine if the requested payment amount for the delegate exceeds an outstanding or remaining amount to be paid toward the delegated transaction. If the requested payment amount exceeds the remaining amount to be paid toward the delegated transaction, the delegate’s payment amount may be adjusted.
• the multi-party transaction decisioning device 110 may ultimately receive the payment transaction record associated with the delegate’s payment and may credit the payee’s payment account with the payment amount.
• the received payment transaction record may be embedded with the payment token stored therein at step 716, so that upon receipt at the payee’s bank may be recognized as a payment for a multi-party transaction or multi-party event.
• One or more aspects disclosed herein may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein.
• program modules include routines, programs, objects, components, data structures, or the like that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device.
• the modules may be written in a source code programming language that is subsequently compiled for execution, or may be written in a scripting language, such as (but not limited to) HTML or XML.
• the computer-executable instructions may be stored on a computer-readable medium, such as a hard disk, optical disk, removable storage media, solid- state memory, RAM, or the like.
• the functionality of the program modules may be combined or distributed as desired in various embodiments.
• the functionality may be embodied in whole, or in part, in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), or the like.
• Particular data structures may be used to more effectively implement one or more aspects disclosed herein, and such data structures are contemplated within the scope of computerexecutable instructions and computer-usable data described herein.
• Various aspects disclosed herein may be embodied as a method, a computing device, a system, and/or a computer program product.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=83362644

Family Applications (1)

Country Status (2)

Family Cites Families (3)

• 2022
  • 2022-08-18 EP EP22773349.0A patent/EP4388481A1/de active Pending
  • 2022-08-18 WO PCT/US2022/040790 patent/WO2023023270A1/en not_active Ceased

Also Published As

Similar Documents

Legal Events