[go: up one dir, main page]

WO2023023782A1 - Procédés et systèmes de résolution de transactions - Google Patents

Procédés et systèmes de résolution de transactions Download PDF

Info

Publication number
WO2023023782A1
WO2023023782A1 PCT/AU2022/051009 AU2022051009W WO2023023782A1 WO 2023023782 A1 WO2023023782 A1 WO 2023023782A1 AU 2022051009 W AU2022051009 W AU 2022051009W WO 2023023782 A1 WO2023023782 A1 WO 2023023782A1
Authority
WO
WIPO (PCT)
Prior art keywords
bill
payment
data
user
processor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/AU2022/051009
Other languages
English (en)
Inventor
Andrew Ellett
Rowan Wilde
Jacques Botes
Ana Petreska
Jonathan Thia
Chris Newton
Chanmony Tha
Craig Cameron
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Helppay Pty Ltd
Original Assignee
Helppay Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2021902740A external-priority patent/AU2021902740A0/en
Application filed by Helppay Pty Ltd filed Critical Helppay Pty Ltd
Priority to AU2022332709A priority Critical patent/AU2022332709A1/en
Publication of WO2023023782A1 publication Critical patent/WO2023023782A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

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/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • 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/04—Payment circuits
    • G06Q20/047—Payment circuits using payment protocols involving electronic receipts
    • 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
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • 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/14—Payment architectures specially adapted for billing systems
    • 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/16—Payments settled via telecommunication systems
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/403—Solvency checks
    • 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

  • Embodiments generally relate to methods, systems and devices for resolving transactions. Specifically, embodiments relate to methods, systems and devices for resolving electronic transactions involving multiple transacting parties.
  • the recipient of the bill may calculate the amount owing by each payor and ask them to pay the amount to the recipient’s account, so the recipient can settle the balance of the bill.
  • the payors may not be sure that their payment is going to the payment of the bill, as opposed to the payee’s personal bank account.
  • the recipient may ask each payor to contribute to the bill directly, by providing them with payment details.
  • multiple transacting parties may not know how much has already been contributed and the bill may be overpaid or underpaid.
  • Some embodiments relate to a method for facilitating a transaction, the method comprising: receiving, from a payor device, a request to access payment data; checking access data associated with the payment data; based on the access data indicating that the payment data is accessible, updating the access data to indicate that the payment data is not accessible and subsequently providing the payment data to the payor device; receiving payment details generated at the payor device in response to receiving the payment data; causing a payment to be processed based on the received payment details; and in response to the payment being processed, further updating the access data to indicate that the payment data is accessible.
  • Some embodiments further comprise: based on the access data indicating that the payment data is not accessible, providing an error to a second payor device notifying the second payor device that the payment data is not accessible.
  • the access data stores information indicating whether the payment data is currently being accessed, where the access data indicates that the payment data is accessible when the payment data is not currently being accessed, and the access data indicates that the payment data is not accessible when the payment data is currently being accessed.
  • the access data comprises an access flag.
  • the access flag is set when the payment data is being accessed, and cleared when the payment data is not being accessed.
  • the payment data corresponds to a bill.
  • the payment data comprises a web page hosting information associated with a bill.
  • providing the payment data to the payor device causes the payor device to display the web page data within a browser application.
  • providing the payment data to the payor device causes the payor device to display the web page data within a native application.
  • the payment data comprises information associated with a bill.
  • the information associated with the bill comprises a remaining bill amount.
  • the remaining bill amount is updated by subtracting the payment amount from the remaining bill amount to produce an updated remaining bill amount.
  • a payment amount is determined based on the received payment details and the payment amount is compared to a remaining bill amount.
  • Some embodiments further comprise, upon determining that the payment amount is higher than the remaining bill amount, automatically adjusting the payment amount to be equal to the remaining bill amount.
  • the request to access the payment data is sent by the payor device in response to the payor device attempting to access a URL associated with the payment data.
  • the URL is provided to the payor device by a message sent on behalf of a bill recipient via a bill recipient computing device.
  • the message is generated by a bill management application executing on the bill recipient computing device.
  • the message is generated by the bill management application in response to a user of the bill recipient computing device requesting assistance with a bill.
  • the message is generated by the bill management application in response to a bill being uploaded that is associated with the payor device. In some embodiments, the association is based on the payor having indicated that bills issued by a particular bill issuer to the bill recipient should automatically be forwarded to the payor device.
  • providing the payment data to the payor device causes the payor device to communicate the payment data to a user of the payor device via a user interface.
  • the payment data comprises information generated based on bill data retrieved from a computing system associated with a bill issuer.
  • the bill data is automatically retrieved from the computing system associated with the bill issuer via an API.
  • the payment data comprises information generated based on bill data entered by a user of a bill recipient device.
  • the bill data entered by a user comprises a biller identification number, and wherein the method further comprise verifying that the biller identification number corresponds to a valid biller.
  • Some embodiments relate to a device comprising: a memory storing executable code; a processor configured to access the memory to execute the executable code; wherein when executing the executable code, the processor is caused to perform the method of some other embodiments.
  • Some embodiments relate to a computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the method of some other embodiments.
  • Figure 1 shows a schematic diagram of a system for resolving electronic transactions according to some embodiments
  • Figure 2 shows a flowchart illustrating a method of facilitating transactions between multiple transacting parties as performed by the system of Figure 1;
  • Figure 3 shows a flowchart illustrating a method of paying a bill as facilitated by the system of Figure 1 ;
  • Figure 4 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a login process of a bill management application
  • Figure 5 shows a further screenshot shown to a user of the bill recipient device of Figure 1 during a login process of a bill management application
  • Figure 6 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a registration process of a bill management application
  • Figure 7 shows a screenshot of a home screen of a bill management application shown to a user of the bill recipient device of Figure 1;
  • Figure 8 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a bill adding process of a bill management application
  • Figure 9 shows a further screenshot shown to a user of the bill recipient device of Figure 1 during a bill adding process of a bill management application
  • Figure 10 shows a screenshot of a bill management screen of a bill management application shown to a user of the bill recipient device of Figure 1
  • Figure 11 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a process of requesting assistance with a bill using a bill management application
  • Figure 12 shows a further screenshot shown to a user of the bill recipient device of Figure 1 during a process of requesting assistance with a bill using a bill management application;
  • Figure 13 shows a screenshot shown to a user of the payor device of Figure 1 during a process of attempted bill payment using a bill management application
  • Figure 14 shows a further screenshot shown to a user of the payor device of Figure 1 during a process of attempted bill payment using a bill management application;
  • Figure 15 shows a further screenshot shown to a user of the payor device of Figure 1 during a process of attempted bill payment using a bill management application;
  • Figure 16 shows a screenshot shown to a user of the payor device of Figure 1 after a successful bill payment using a bill management application
  • Figure 17 shows a computing device according to some embodiments.
  • Embodiments generally relate to methods, systems and devices for resolving transactions. Specifically, embodiments relate to methods, systems and devices for resolving electronic transactions involving multiple transacting parties.
  • FIG. 1 shows a transaction system 100 according to some embodiments.
  • Transaction system 100 may allow a bill recipient to share the payment of one or more bills between one or more payors.
  • transaction system 100 may allow a bill recipient to share the payment of one or more bills with any number of payors, who may each be able to select whether or not to contribute to the bill, and how much, if any, funds to contribute.
  • the system 100 may allow the payors to remain anonymous to each other and/or to the bill recipient, so that each payor and/or the bill recipient is unaware of who else has contributed, or how much each payor has contributed.
  • system 100 allows a series of payors to sequentially contribute to a single bill without overpaying, as described below.
  • Transaction system 100 includes a bill recipient device 110 in communication with a transaction facilitation server system 130, over a network 120.
  • Transaction system 100 may further include at least one biller server system 140., and at least one payor device 150.
  • Bill recipient device 110 may be a smart phone, tablet, laptop, PC or other computing device.
  • Bill recipient device 110 comprises a processor 111 and a memory 113 accessible to processor 111.
  • Processor 111 may be configured to access data stored in memory 113, to execute instructions stored in memory 113, and to read and write data to and from memory 113.
  • Processor 111 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.
  • CPUs central processing units
  • ASIPs application specific instruction set processors
  • Memory 113 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 113 may be configured to store executable applications for execution by processor 111. For example, memory 113 may store at least one bill management application 114 configured to allow a user to manage their bills, and to share their bills with multiple payors. According to some embodiments, bill management application 114 may be a native application. According to some embodiments, bill management application 114 may be a browser application configured to perform bill management functions via a web based platform.
  • Bill recipient device 110 further comprises user input and output peripherals 116 to allow a user to communication with bill recipient device 110.
  • User I/O 116 may comprise a display screen 117, which may be a touchscreen display, as well as one or more of a keyboard, a mouse, a camera, a microphone, a speaker, buttons, sliders, and LEDs.
  • bill recipient device 110 further comprises a communications module 112.
  • Communications module 112 may allow for wired and/or wireless communication between bill recipient device 110 and external computing devices and components. Communications module 112 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 112 may facilitate communication with external devices and systems, such as transaction facilitation server system 130, via network 120.
  • Network 120 may comprise one or more local area networks or wide area networks that facilitate communication between elements of system 100.
  • network 120 may be the internet.
  • network 120 may comprise at least a portion of any one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, some combination thereof, or so forth.
  • Network 120 may include, for example, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a packet- switched network, a circuit- switched network, an ad hoc network, an infrastructure network, a public- switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fibre-optic network, or some combination thereof.
  • a wireless network a wired network
  • an internet an intranet
  • a public network a packet- switched network
  • a circuit- switched network an ad hoc network
  • an infrastructure network a public- switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fibre-optic network, or some combination thereof.
  • PSTN public- switched telephone network
  • Transaction facilitation server system 130 may comprise one or more computing devices and/or server devices, such as one or more servers, databases, and/or processing devices in communication over a network. Transaction facilitation server system 130 may be configured to host an transaction facilitation platform that can be used by a user of device 110 to allow for management and sharing of bills among multiple payors. Transaction facilitation server system 130 comprises a processor 131 and a memory 133 accessible to processor 131. Processor 131 may be configured to access data stored in memory 133, to execute instructions stored in memory 133, and to read and write data to and from memory 133. Processor 131 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.
  • CPUs central processing units
  • ASIPs application specific instruction set processors
  • Memory 133 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 133 may be configured to store executable applications for execution by processor 131. For example, memory 133 may store program code 134 configured to cause processor 131 to perform transaction facilitation actions as described in further detail below. Memory 133 may also store data, such as user account data 135. Account data 135 may store user account details such as names, authentication details, contact details, and billers associated with the user account.
  • transaction facilitation server system 130 further comprises a communications module 132.
  • Communications module 132 may allow for wired and/or wireless communication between authentication server system 130 and external computing devices and components. Communications module 132 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 132 may facilitate communication with external devices and systems such as bill recipient device 110 and biller server system 140 via network 120.
  • Biller server system 140 may comprise one or more computing devices and/or server devices, such as one or more servers, databases, and/or processing devices in communication over a network.
  • Biller server system 140 may be operated by a bill issuer, which may be a service or utilities provider that generates bills for payment by a bill recipient, such as the user of device 110.
  • biller server system 140 may be operated by an electricity provider, insurance company, landlord, water utility, internet provider or another provider of goods and/or services.
  • Biller server system 140 comprises a processor 141 and a memory 143 accessible to processor 141.
  • Processor 141 may be configured to access data stored in memory 143, to execute instructions stored in memory 143, and to read and write data to and from memory 143.
  • Processor 141 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.
  • CPUs central processing units
  • ASIPs application specific instruction set processors
  • Memory 143 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 143 may be configured to store executable applications for execution by processor 141. For example, memory 143 may store program code 144 configured to cause processor 141 to perform billing actions as described in further detail below.
  • Memory 143 may also store data, such as user account data 145, which may store details of one or more user accounts including account names and contact details, as well as billing details such as bill amount and due dates.
  • user account data 145 may store details of one or more user accounts including account names and contact details, as well as billing details such as bill amount and due dates.
  • biller server system 140 further comprises a communications module 142.
  • Communications module 142 may allow for wired and/or wireless communication between biller server system 140 and external computing devices and components. Communications module 142 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 142 may facilitate communication with external devices and systems such as transaction facilitation server system 130 via network 120. According to some embodiments, biller server system 140 may be integrated with transaction facilitation server system 130 by way of an API, which may automatically cause billing data from biller server system 140 to be transmitted to transaction facilitation server system 130 via communications module 142.
  • Payor device 150 may be a smart phone, tablet, laptop, PC or other computing device. According to some embodiments, payor device 150 may be any internet connected device, such as a whitegoods product, smart home display, or car.
  • Bill recipient device 150 comprises a processor 151 and a memory 153 accessible to processor 151.
  • Processor 151 may be configured to access data stored in memory 153, to execute instructions stored in memory 153, and to read and write data to and from memory 153.
  • Processor 151 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.
  • CPUs central processing units
  • ASIPs application specific instruction set processors
  • Memory 153 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 153 may be configured to store executable applications for execution by processor 111. For example, memory 113 may store at least one browser application 154 configured to interpret and display web page content. According to some embodiments, memory 153 may alternatively or additionally also store a bill management application configured to allow a user to contribute toward the payment of bills. According to some embodiments, the bill management application may be substantially similar to bill management application 114 as described above with reference to bill recipient device 110.
  • Payor device 150 further comprises user input and output peripherals 156 to allow a user to communication with payor device 150.
  • User I/O 156 may comprise a display screen 157, which may be a touchscreen display, as well as one or more of a keyboard, a mouse, a camera, a microphone, a speaker, a microphone, buttons, sliders, and LEDs.
  • user I/O 156 may not include display screen 157, and may instead include alternative input and/or output peripherals to allow for communication with a user.
  • user I/O 156 may comprise a speaker and microphone to allow for audio communication with a user by way of voice commands.
  • payor device 150 further comprises a communications module 152.
  • Communications module 152 may allow for wired and/or wireless communication between payor device 150 and external computing devices and components. Communications module 152 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 152 may facilitate communication with external devices and systems, such as transaction facilitation server system 130, via network 120.
  • Figure 2 shows a flowchart illustrating a method 200 performed by system 100 to facilitate a transaction involving multiple transacting parties.
  • method 200 relates to an example scenario where a user uses bill recipient device 110 to receive data related to, view details of, manage, and request assistance with a bill generated by biller server system 140, and a second user uses payor device 150 to partially pay the bill.
  • Transaction facilitation server system 130 facilitates in the management and payment of the bill.
  • Method 200 illustrates one example of how a user may interact with bill management application 114, but the displayed steps may not be performed each time a user accesses bill management application 114. Furthermore, the steps may be performed in an order that differs to the order displayed in Figure 2.
  • Method 200 starts at step 205, at which processor 111 is caused to initiate bill management application 114. This may be in response to a user interacting with user I/O 116 to request that bill management application 114 is initiated. For example, the user may interact with a virtual button or icon representing bill management application 114 using display screen 117.
  • processor 111 executing bill management application 114 is caused to request authentication details to allow the user to login to bill management application 114.
  • the request may be for the user to enter a username and/or password log in.
  • the request may alternatively or additionally be for a contact number or address associated with the user account.
  • processor 111 executing bill management application 114 may be further caused to send a verification code to a contact number or address associated with the user account, and to ask the user to enter the verification code to authenticate their account.
  • the user may be requested to log in using a biometric authentication process, such as using a fingerprint, retina scan, or facial recognition.
  • the user may be able to log in using a linked account, which may be a social media or email account such as a Google® or Facebook® account, that has previously been linked to the user account for the bill management application 114.
  • bill management application 114 may use a third party authentication service to facilitate the log in process, which may be by authenticating a user or user account.
  • a third party authentication service such as Okta® or Azure AD® may be used, for example.
  • processor 111 executing bill management application 114 may provide the user with an opportunity to create an account, by providing their contact details and setting an authentication method.
  • the user provides the requested authentication details.
  • processor 111 via communications module 112 communicates the received details to transaction facilitation server system 130.
  • Processor 131 executing program code 134 receives the details via network 120 using communications module 132, and authenticates the user by comparing the received details to those stored in account data 135. According to some alternative embodiments, the received details may be processed by an authentication system such as Okta®, for example. Having verified the authentication details, processor 131 executing program code 134 sends a response to bill recipient device 110 via network 120 and using communications module 132 indicating whether the user was authenticated.
  • processor 111 executing bill management application 114 receives the response from transaction facilitation server system 130.
  • processor 111 executing bill management application 114 interprets the response from transaction facilitation server system 130 to determine whether the user was authenticated.
  • processor 111 may request that the user re-enter their authentication details, and return to step 215..
  • processor 111 executing bill management application may load a graphical user interface associated with bill management application 114 and cause this to be displayed on display screen 117.
  • the graphical user interface may present virtual buttons, options, tabs, and other graphical user interface elements that a user can interact with to perform various actions.
  • the graphical user interface may present user interface elements that allow the user to perform tasks such as managing their associated billers, viewing bills received from billers, making payments towards bills, requesting assistance with payment of bills, managing their contacts, and managing their account details and preferences.
  • processor 111 executing bill management application 114 receives a request from the user of bill recipient device 110 to view their bills. This may be by a user interacting with a graphical user interface element displayed on display screen 117 that represents a “view bills” action. Alternatively, bill management application 114 may default to displaying the user’s existing bills when the user first logs on to their account.
  • processor 111 executing bill management application 114 processes the request by retrieving bill information.
  • processor 111 communicates with transaction facilitation server system 130 to retrieve information associated with bills stored in account data 135.
  • the information may include one or more of bill amount, bill due date, biller details, and/or other data associated with the bill.
  • processor 111 executing bill management application 114 may additionally or alternatively retrieve biller information associated with the user account from account data 135, and may then communicate with an associated biller server system 140 to retrieve bill information associated with the user account.
  • the bill information retrieved by processor 111 may include a biller code, bill amount and a due date.
  • the biller code may be a code corresponding to an existing bill processing or transaction system, such as BPAY®, in some embodiments, or another bill management, bill payment, or biller authentication system. All retrieved bills associated with the user account may be displayed on display screen 117. According to some embodiments, the bills may be listed by ascending due date, and may be grouped by month in some embodiments. According to some embodiments, bills that are nearing or past their due data may be visually emphasised. For example, overdue bills may be displayed with a red background in some embodiments.
  • any such shared bills may also be displayed on display screen 117. According to some embodiments, these may be displayed in a separate area of the user interface to the user’s personal bills.
  • processor 111 receives a request to add a new bill to the user’s account.
  • the request may be generated in response to a user interacting with a graphical user interface element that represents an “add bill” action.
  • processor 111 executing bill management application 114 presents a page to the user via display screen 117 that allows the user to enter details relating to the bill and the biller that issued the bill.
  • the page may request that the user select the biller user enters a biller code and a customer reference number associated with that biller.
  • the biller code may be a BPAY® biller code, for example.
  • the page may request or provide the user with an option to scan a copy of their bill, which may be done by taking a photograph or screenshot of their bill.
  • Processor 111 may be configured to receive the scanned data and to extract bill information such as bill amount, due date and biller details, for example.
  • processor 111 receives the biller details from the user via user I/O 116.
  • processor 111 executing bill management application 114 is caused to forward the biller details to transaction facilitation server system 130 via network 120 using communications module 112.
  • biller server system 140 may be integrated with transaction facilitation server system 130 by way of an API, which may automatically cause billing data from biller server system 140 to be transmitted to transaction facilitation server system 130.
  • data from biller server system 140 may be integrated with transaction facilitation server system 130 by way of a batch upload of billing data from biller server system 140 to transaction facilitation server system 130, which may occur on a periodic basis.
  • processor 131 executing program code 134 may be caused to associate the biller with the user account, and to store the relationship in account data 135.
  • Processor 131 may further be caused to retrieve bill data corresponding to the user account from biller server system 140, and to forward that data to bill recipient device 110 via network 120 at step 265.
  • Bill recipient device 110 receives the retrieved bill information, and determines that the bill corresponds to a known biller at step 267.
  • Processor 111 executing bill management application 114 is caused to display the retrieved bill information to the user via display screen 117 at step 270.
  • transaction facilitation server system 130 may be caused to send a notification to bill recipient device 110 that no associated biller with that biller code exists in the system at step 265. Having received the notification, processor 111 determines that no known biller exists at step 267. Further at step 269, processor 111 is caused to notify the user that that biller does not exist in the system, and request that the user manually enter the bill details. The user may enter the details by interacting with user VO 116. For example, the user may use a physical or virtual keyboard to enter details such as the bill amount and due date.
  • the user may upload an electronic copy of the bill or an electronic copy of data from a bill to bill management application 114, and processor 111 executing bill management application 114 may parse the electronic document to extract information such as the payment amount and due date.
  • processor 111 executing bill management application 114 may use a camera to capture an image of the bill, and processor 111 executing bill management application 114 may use optical character recognition processes to translate the image to text, and then parse the text to extract information such as the payment amount and due date.
  • processor 111 may communicate the information to transaction facilitation server system 130 for storing in account data 135 associated with the user account.
  • transaction facilitation server system 130 may verify that the entered details relate to a biller account, and not to a personal bank account, such as by checking that a valid biller identification number has been entered, before storing the details.
  • the updated bill information is displayed to the user within the list of bills associated with their account.
  • processor 111 executing bill management application 114 receives a request from the user via user I/O 116 to make a payment against a bill. The request may include the bill to be paid, and an amount to be paid.
  • processor 111 may cause the payment to be processed, such as by sending details of the request to transaction facilitation server system 130 for processing.
  • Processor 131 executing program code 134 receives the details of the transaction including the bill details and the payment amount.
  • payment method details such as credit card details
  • Processor 131 may be stored by a user in association with their user account.
  • Processor 131 may retrieve payment method details from account data 135, and cause the payment to be processed for the required amount.
  • the user may have entered their payment details at the time of submitting the payment request using user I/O 116, and processor 131 may receive the details from bill recipient device 110 via communications module 132.
  • Processor 131 may receive the payment method details and cause the payment to be processed for the required amount.
  • processor 131 may cause the payment to be processed by sending the transaction details to a payment processing service, such as Stripe®, for example, which may also store the user’s payment details in some embodiments. Processor 131 may then send confirmation to bill recipient device 110 confirming that the transaction has been successfully carried out.
  • a payment processing service such as Stripe®, for example
  • processor 131 determines the amount remaining on the bill by subtracting the payment amount from the bill amount.
  • An updated bill amount is stored in account data 135.
  • details of the transaction and the new bill amount may also be forwarded to bill server system 140 associated with the issuer of the bill, for storing in account data 145 in association with the user’s account details.
  • processor 111 receives confirmation that the payment has been successfully processed, and displays the completed transaction to the user, including the updated bill amount reflecting the amount still owing on the bill.
  • processor 111 executing bill management application 114 receives a request from the user via user I/O 116 to ask for assistance to pay a bill.
  • the request may include information relating to the bill to be paid, and contact details relating to a person that the user wishes to ask for assistance.
  • the contact details may include the name of the contact that the user wishes to request assistance from, for example.
  • the contact details may be of an existing contact of the user that are stored in account data 135. Existing contacts may be ones that the user has previously manually entered as contacts via bill management application 114, or may have been automatically populated based on a contact list stored in memory 113 of bill recipient device 110.
  • Processor 111 may retrieve the contact details by communication with transaction facilitation server system 130.
  • Processor 131 executing program code 134 may receive a name or other reference relating to the desired contact, and be caused to retrieve the contact details from account data 135 and send them to bill recipient device 110 via network 120 using communications module 152. According to some embodiments, the user may use user I/O 116 to enter directly contact details of a person they wish to ask for assistance.
  • processor 111 executing bill management application 114 generates a URL that facilitates payment of the bill by payors other than the user of bill recipient device 110, such as the user of a payor device 150.
  • the URL may be a mini URL, and accessing the URL may cause the payor device 150 to retrieve data from a server relating to a request for assistance with a bill.
  • the data may be displayed on a web browser of payor device 150 as a web page that allows for a visitor to the page to make a payment toward the specified bill.
  • the data may be communicated to a user of payor device 150 in another manner via user I/O 156.
  • the data may be presented via a native application on display screen 157, or communicated to the user in audible form.
  • the data may include a request for a payment amount to put toward the bill, and payment method details.
  • the data may be hosted by transaction facilitation server system 130.
  • processor 111 causes the URL to be sent to the payor via a contact number, address, or other contact information of the payor.
  • the URL may be sent to the payor via a text message, email, an in-app message or other messaging service.
  • transaction facilitation server system 130 may use a messaging service such as Twilio® or SendGrid® to send the URL to payor device 150.
  • the generated URL may instead be displayed on display screen 117 as a shareable link, and the user of bill recipient device 110 may be able to copy the link and share it with their contacts via a message, email, or social media platform.
  • the message may be received by payor device 150, and allow a user of payor device 150 to access the data pointed to by the URL, and make a payment as described in further detail below with reference to Figure 3.
  • processor 131 updates the bill data stored in account data 135 in association with the paid bill. Where the payment was a partial payment of the bill, processor 131 determines a new bill amount, being the previous bill amount minus the payment amount.
  • processor 111 may receive a confirmation from transaction facilitation server system 130 confirming that a payment was made. According to some embodiments, processor 111 may generate a notification to inform the user of bill recipient device 110 that a payment has been made against the specified bill. According to some embodiments, the notification may be a push notification or real-time alert that is displayed by user I/O 116. According to some embodiments, the notification may be sent via bill management application 114, email SMS, voice, or other messaging services. In some embodiments, the notification may be a message that is asynchronously displayed to the user of bill recipient device 110 when the user next initiates bill management application 114. According to some embodiments, details of who made the payment may not be displayed to the user of bill recipient device 110. Steps 290 to 296 may be repeated for any number of additional payors each having a payor device 150.
  • Figure 3 shows a method 300 performed by transaction facilitation server system 130 to facilitate payment of a bill by one or more payor devices 150.
  • method 300 may be performed by processor 131 executing program code 134, and may be performed after step 294 of method 200 as described above with reference to Figure 2.
  • transaction facilitation server system 130 receives a request from payor device 150 via network 120 to access bill payment data hosted by transaction facilitation server system 130.
  • the bill payment data may be in the form of a web page, in some embodiments.
  • the request may be in the form of a URI request, for example.
  • the request may be generated by payor device 150 in response to a user of payor device 150 navigating to a URL generated by transaction facilitation server system 130 and sent to payor device 150, as described with respect to steps 292 and 294 of method 200.
  • processor 131 executing program code 134 checks access data associated with the bill payment data to determine whether an alternative payor device 150 is currently viewing bill payment data. This may be by checking a location in memory 133 associated with the requested bill payment data, to determine whether an access flag has been set.
  • processor 131 determines whether the requested bill payment data is currently being viewed by a different payor device 150, based on the retrieved access flag information. If processor 131 determines that the bill payment data is already being viewed, at step 320 processor 131 may send instructions to payor device 150 to cause an error, notification, warning or exception to be communicated to the user via user I/O 156 of payor device 150. For example, the error, notification, warning or exception may be displayed via display screen 157. The error may note that a payment is currently in progress, and ask the user of payor device 150 to try again later. According to some embodiments, a “try again” virtual button may be displayed to the user. The user may attempt to access the bill payment data again, which may be by interacting with the “try again” virtual button in some embodiments. Processor 131 receives the request at step 322 and continues to execute method 300 from step 310.
  • processor 131 may be caused to update the access data associated with the requested bill payment data. For example, processor 131 may be caused to set a flag in memory 133, indicating that the bill payment data is currently being viewed.
  • processor 131 is caused to send the bill payment data to payor device 150 via network 121, using communications module 132.
  • the bill payment data may be retrieved from memory 133, and may comprise a HTML page in some embodiments.
  • the bill payment data may comprise executable client-side language scripts, such as CSS and/or JavaScript scripts, for example.
  • Payor device 150 may receive the bill payment data, and in some embodiments processor 151 executing browser application 154 may be caused to interpret the bill payment data and display an associated web page on display screen 157.
  • processor 151 may be caused to communicate the bill payment data to the user via alternative means, such as by displaying the data via display screen 157 in a native application or by communicating the data audibly.
  • the bill payment data may include details relating to a bill to be paid, such as details of the original bill recipient, the type of bill, the bill issuer, and the remaining bill amount, being the amount still owning on the bill.
  • the bill payment data may request that the user of payor device 150 enter payment details to allow a payment to be processed, which may include a payment amount, payment method information, and payor contact details in some embodiments.
  • the payment may be made by way of direct deposit, credit card payment, or payment with a cryptocurrency, for example.
  • the payor may be able to optionally add their name to the payment, which may be sent to the bill recipient so that the bill recipient is made aware of who contributed to the payment of the bill.
  • the payor may be able to submit their payment anonymously.
  • the payor may be able to optionally a description to the payment, which may include an identifiable or non-identifiable description, for example.
  • transaction facilitation server system 130 receives a payment amount from payor device 150.
  • the payment amount may be transmitted by payor device 150 after a user enters a payment amount via user I/O 156 and processor 151 executing browser application 154 is caused to transmit the entered amount to transaction facilitation server system 130 via network 120 using communications module 152.
  • processor 131 executing program code 134 is caused to compare the received payment amount with the remaining bill amount associated with the bill which the user of payor device 150 has been asked to contribute to.
  • Processor 131 may retrieve the remaining bill amount from memory 133.
  • processor 131 executing program code 134 determines whether the received payment amount is greater than the retrieved remaining bill amount. If the payment amount entered by the user of payor device 150 is greater than the remaining bill amount, then at step 350 processor 131 is caused to send instructions to payor device 150 to cause processor 151 executing browser application 154 to display a message on display 157, suggesting a smaller payment amount. When a new payment amount is received, such as by the user accepting the suggestion, method 300 continues from step 335.
  • processor 131 is caused to process the payment amount.
  • the payment may be processed using payment method details entered by the user of payor device 150.
  • the payment may be processed via a payment platform or payment gateway such as Stripe®.
  • the processed funds may be held by an account operated by transaction facilitation server system 130, before being transmitted to an count of the biller server system 140 associated with the bill.
  • processor 131 may be caused to send a notification or payment receipt to payor device 150 or to contact details provided by the payor once the transaction is successfully processed.
  • processor 131 executing program code 134 is caused to update the remaining bill amount stored in memory 133 associated with the bill being paid.
  • the updated remaining bill amount may be the previous remaining bill amount minus the processed payment amount. This updated remaining bill amount may be displayed to users of other payment devices 150 who subsequently access the bill payment data.
  • processor 131 executing program code 134 receives a notification from payor device 150 that the user has closed, navigated away, or is otherwise no longer viewing the bill payment data.
  • processor 131 In response to receiving the notification, at step 370 processor 131 updates the access data stored in memory 133. For example, processor 131 may clear a flag, indicating that no devices are currently accessing the bill payment data.
  • method 300 may be executed with reference to a payor device 150 executing a browser application 154, according to some embodiments method 300 may be executed with reference to a payor device 150 executing a bill management application, such as bill management application 114, for example.
  • navigating to the URL provided to payor device 150 at step 294 of method 200 may cause processor 151 to present a page corresponding to the requested bill payment data within a user interface of the bill management application stored on payor device 150.
  • payment method details may be stored by transaction facilitation server system 130 in association with the user account of payor device 150, so that the user does not need to provide their payment method details during method 300.
  • Figure 4 shows an example screenshot 400 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 400 may be displayed when a user first causes bill management application 114 to be initiated, as described above with reference to step 205 of method 200.
  • Screenshot 400 includes a sign in button 410 and a register button 420.
  • a user of bill recipient device 110 may be able to sign in to an existing user account associated with bill management application 114 by interacting with button 410, and may be able to register for a new user account associated with bill management application 114 by interacting with button 420.
  • Figure 5 shows an example screenshot 500 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 500 may be displayed when a user interacts with button 410 of screen 400, indicating that they wish to sign in to an existing user account associated with bill management application 114.
  • Screen 500 may be displayed as a request for authentication details, as described above with reference to step 210 of method 200.
  • Screen 500 includes graphical user interface elements via which a user can enter authentication details.
  • the illustrated embodiment includes an email address text box 510 and a password text box 520, allowing a user to enter an email and password pair that they have registered as their authentication details.
  • buttons 540 buttons 540.
  • a user may be able to sign in to their account via their Facebook®, Google®, or Apple® account.
  • Figure 6 shows an example screenshot 600 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 600 may be displayed when a user interacts with button 420 of screen 400, indicating that they wish to create a new user account associated with bill management application 114, as described above with reference to step 210 of method 200.
  • Screen 600 includes buttons 610 that allow a user to register for a user account associated with application 114 using an existing social media account.
  • a user may be able to create a new user account using an existing Facebook®, Google®, or Apple® account.
  • a user may register for a new user account without using an existing social media account by interacting with button 620, which allows them to register for a new account with an email address.
  • Figure 7 shows an example screenshot 700 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 700 may be displayed when a user has successfully logged in to their user account, and once their bill information has been retrieved and displayed, as described above with reference to step 240 of method 200.
  • Screen 700 includes a banner 710 highlighting a particular selected time period associated with the displayed bills. For example, in the illustrated embodiment, banner 710 shows ‘October’ highlighted, indicating that the displayed bills are due in October. According to some embodiments, bills may be displayed in ascending order of due date, and banner 710 may be automatically updated as a user scrolls through their bills.
  • Screen 700 may further display a number of bills 730. Each bill may be displayed with a summary of information associated with the bill. For example, each bill may show the biller 731, a due date 732, how many payors have been requested to assist with the bill at 733, an amount of the bill still outstanding at 734, and a number of contributors 735. Screen 700 may also provide a button 740 allowing a user to add a new bill, as described above with reference to steps 245 to 270 of method 200.
  • Screen 700 may also include a number of navigation buttons, allowing a user to access various functions within bill management application 114. These may include a “bills” navigation button 750, a “help others” navigation button 760, a “contacts” navigation button 770 and a “profile” navigation button 780. Interacting with “bills” navigation button 750 may allow a user to manage their personal bills by adding new bills, paying existing bills, editing bills, deleting bills, and requesting assistance with payment of bills. Interacting with “help others” navigation button 760 may allow a user to assist other users with the payment of bills by causing bill recipient device 110 to act as a payor device 150 and execute a method such as method 300.
  • a “bills” navigation button 750 may allow a user to manage their personal bills by adding new bills, paying existing bills, editing bills, deleting bills, and requesting assistance with payment of bills.
  • Interacting with “help others” navigation button 760 may allow a user to assist other users with the payment of bills by causing
  • Interacting with “contacts” navigation button 770 may allow a user to manage contacts associated with their user profile, such as by adding new contacts, editing contacts and deleting contacts.
  • Interacting with “profile” navigation button 780 may allow a user to make changes to their profile settings, such as editing their authentication details, adding or editing payment method details, managing notifications and managing privacy preferences, for example.
  • Figure 8 shows an example screenshot 800 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 800 may be displayed when a user has requested to add a new bill by interacting with button 740, as described above with reference to step 245 of method 200.
  • Screen 800 includes a pop-up 810 directing the user to either link a new biller or provider to their account by interacting with button 820, or to add a bill by interacting with button 830.
  • Interacting with button 820 may allow the user to link a biller with their account, such that all bills generated by that biller and associated with the user account are automatically populated within bill management application 114, as described above with reference to steps 250 to 270 of method 200.
  • Interacting with button 830 may allow the user to manually add a single bill to their user account, as described above with reference to steps 269 to 270 of method 200.
  • Figure 9 shows an example screenshot 900 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 900 may be displayed when a user has requested to add a new bill manually by interacting with button 830.
  • Screen 900 includes a number of graphical user interface elements allowing a user to enter various details associated with the bill they wish to add.
  • screen 900 includes a biller code text box 910, a biller name text box 920, a reference number text box 930, and a bill type drop-down box 940.
  • Other details such as a bill amount and a due date, may be enterable by scrolling down screen 900.
  • Figure 10 shows an example screenshot 1000 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 1000 may be displayed when a user has requested to view the details of a particular bill by interacting with a bill listing such as bill 730 as displayed on screen 700.
  • Screen 900 shows more information about a selected bill, including a biller 1010, a due date 1020, an amount left to pay 1030, and an original bill amount 1040.
  • Screen 1000 also includes a button 1060 to allow a user to request assistance with payment of the bill, as described above with reference to step 290 of method 200; and a button 1050 to allow a user to make a payment to the bill, as described above with reference to step 275 of method 200.
  • Screen 1000 further includes information such as a list 1070 displaying contacts that have already been asked to contribute to payment of the bill. Screen 1000 further allows a user to perform bill management actions such as marking the bill as paid by interacting with button 1080, or updating the bill details by interacting with button 1090.
  • Figure 11 shows an example screenshot 1100 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 1100 may be displayed when a user has requested assistance with payment of a bill, such as by interacting with button 1060 of screen 1000, as described above with reference to step 290 of method 200.
  • Screen 1100 shows a pop-up 1110 displaying a unique URL 1120 generated at step 292 of method 200.
  • a user may be able to share the link by copying it using button 1130, allowing the user to share it in a message, email, social media post or other communication.
  • a user may interact with button 1140 to cause the link 1120 to be sent directly to one of the contacts associated with their user account.
  • Figure 12 shows an example screenshot 1200 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114.
  • screenshot 1200 may be displayed when a user has interacted with button 1120 of screen 1100 to cause a generated URL 1120 to be sent to one of their contacts, as described above with reference to step 294 of method 200.
  • Screen 1100 shows details of the bill to be paid, including a biller 1210, a due date 1220, and a remaining bill amount 1230.
  • Screen 1200 also includes a text box 1240 for a user to enter the contact to which they wish the URL 1120 to be sent.
  • processor 111 executing bill management application 114 may cause contact names to be autocompleted as the user starts typing on text box 1240.
  • a user may be able to select multiple contacts to whom the request for assistance will be sent.
  • Screen 1200 further includes a checkbox 1250, allowing the user to indicate whether they wish future bills from the biller 1210 to be automatically forwarded to the selected contact or contacts. Once the user has entered the required data, they may interact with button 1260 to cause the request for assistance to be sent to the selected contact or contacts, as described above with reference to step 294 of method 200.
  • Figure 13 shows an example screenshot 1300 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154.
  • screenshot 1300 may be displayed when a user of payor device 150 is attempting to access bill payment data via a URL sent by a bill recipient device 110 as described above with reference to step 294 of method 200, and when a different payor device is already accessing the URL, as described above with reference to step 320 of method 300.
  • Screen 1300 displays a pop-up 1310 indicating that another user is already trying to make a payment, and requesting that the user of payor device 150 try again.
  • Screen 1300 includes a “try again” button 1320, which may cause the payor device 150 to re-attempt access of the bill payment data, as described above with reference to step 322 of method 300.
  • Figure 14 shows an example screenshot 1400 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154.
  • screenshot 1400 may be displayed when a user of payor device 150 successfully accesses bill payment data via a URL sent by a bill recipient device 110, as described above with reference to step 330 of method 300.
  • Screen 1400 displays a message 1410 thanking the user for contributing to the bill, and provides some bill details such as the due date 1420 and total amount due 1430.
  • the displayed total amount due 1430 may be the remaining bill amount taking into account any payments already processed against the bill.
  • Screen 1400 further provides a button 1440 allowing a user to log in if they have an existing account with bill management application 114. Alternatively, the user is provided an opportunity to make a manual payment, by entering a payment amount in text box 1450.
  • Figure 15 shows an example screenshot 1500 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154.
  • screenshot 1500 may be displayed when a user of payor device 150 attempts to make a payment that is higher than an amount remaining on the bill, as described above with reference to step 350 of method 300.
  • Screen 1500 displays a pop-up 1510 notifying the user that the entered amount was higher than the amount owing, and indicating that the payment amount has been adjusted to the total amount owing on the bill. The user can indicate agreement with the suggested lower payment amount by interacting with button 1520.
  • Figure 16 shows an example screenshot 1600 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154.
  • screenshot 1600 may be displayed when a user of payor device 150 has successfully made a payment against a bill, as described above with reference to step 360 of method 300.
  • Screen 1600 displays a message 1610 indicating that the payment was successful, and provides some details of the payment made at 1620, such as the amount paid and the biller that the payment was sent to.
  • Screen 1600 further provides a button 1630 allowing a user to view their contact’s other bills, to see which other bills they are able to contribute to.
  • Figure 17 illustrates an example computer system 1700.
  • one or more computer systems 1700 perform one or more steps of one or more methods described or illustrated herein.
  • one or more computer systems 1700 provide functionality described or illustrated herein.
  • software running on one or more computer systems 1700 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein.
  • Particular embodiments include one or more portions of one or more computer systems 1700.
  • reference to a computer system may encompass a computing device, and vice versa, where appropriate.
  • reference to a computer system may encompass one or more computer systems, where appropriate.
  • the bill recipient device 110, transaction facilitation server system 130, biller server system 140, and/or payor device 150 may each incorporate a subset or all of the computing components described with reference to the computer system 1700 to provide the functionality described in this specification.
  • Computer system 1700 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on- module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these.
  • SOC system-on-chip
  • SBC single-board computer system
  • COM computer-on-module
  • SOM system-on- module
  • computer system 1700 may include one or more computer systems 1700; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks.
  • one or more computer systems 1700 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein.
  • one or more computer systems 1700 may perform in real-time or in batch mode one or more steps of one or more methods described or illustrated herein.
  • One or more computer systems 1700 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.
  • computer system 1700 includes a processor 1702, memory 1704, storage 1706, an input/output (I/O) interface 1708, a communication interface 1710, and a bus 1712.
  • Memory 1704 may be equivalent to, comprise, or form part of one or more of memory 113, memory 133, memory 143 or memory 153.
  • Storage 1706 may be equivalent to, comprise, or form part of one or more of memory 113, memory 133, memory 143 or memory 153.
  • I/O interface 1708 may be equivalent to, comprise, or form part of one or more of user I/O 116 or user I/O 156.
  • Communication interface 1710 may be equivalent to, comprise, or form part of one or more of communications module 112, communications module 132, communications module 142 or communications module 152.
  • processor 1702 includes hardware for executing instructions, such as those making up a computer program.
  • processor 1702 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1704, or storage 1706; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 1704, or storage 1706.
  • processor 1702 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 1702 including any suitable number of any suitable internal caches, where appropriate.
  • processor 1702 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs).
  • TLBs translation lookaside buffers
  • Instructions in the instruction caches may be copies of instructions in memory 1704 or storage 1706, and the instruction caches may speed up retrieval of those instructions by processor 1702.
  • Data in the data caches may be copies of data in memory 1704 or storage 1706 for instructions executing at processor 1702 to operate on; the results of previous instructions executed at processor 1702 for access by subsequent instructions executing at processor 1702 or for writing to memory 1704 or storage 1706; or other suitable data.
  • the data caches may speed up read or write operations by processor 1702.
  • the TLBs may speed up virtual-address translation for processor 1702.
  • processor 1702 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 1702 including any suitable number of any suitable internal registers, where appropriate.
  • processor 1702 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 1702.
  • ALUs arithmetic logic units
  • memory 1704 includes main memory for storing instructions for processor 1702 to execute or data for processor 1702 to operate on.
  • computer system 1700 may load instructions from storage 1706 or another source (such as, for example, another computer system 1700) to memory 1704.
  • Processor 1702 may then load the instructions from memory 1704 to an internal register or internal cache.
  • processor 1702 may retrieve the instructions from the internal register or internal cache and decode them.
  • processor 1702 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 1702 may then write one or more of those results to memory 1704. In particular embodiments, processor 1702 executes only instructions in one or more internal registers or internal caches or in memory 1704 (as opposed to storage 1706 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 1704 (as opposed to storage 1706 or elsewhere).
  • One or more memory buses (which may each include an address bus and a data bus) may couple processor 1702 to memory 1704.
  • Bus 1712 may include one or more memory buses, as described below.
  • memory 1704 includes random access memory (RAM).
  • RAM random access memory
  • This RAM may be volatile memory, where appropriate.
  • this RAM may be dynamic RAM (DRAM) or static RAM (SRAM).
  • DRAM dynamic RAM
  • SRAM static RAM
  • this RAM may be single-ported or multi-ported RAM.
  • Memory 1704 may include one or more memories 1704, where appropriate.
  • storage 1706 includes mass storage for data or instructions.
  • storage 1706 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these.
  • Storage 1706 may include removable or non-removable (or fixed) media, where appropriate.
  • Storage 1706 may be internal or external to computer system 1700, where appropriate.
  • storage 1706 is non-volatile, solid-state memory.
  • storage 1706 includes read-only memory (ROM).
  • this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these.
  • This disclosure contemplates mass storage 1706 taking any suitable physical form.
  • Storage 1706 may include one or more storage control units facilitating communication between processor 1702 and storage 1706, where appropriate.
  • storage 1706 may include one or more storages 1706.
  • VO interface 1708 includes hardware, software, or both, providing one or more interfaces for communication between computer system 1700 and one or more I/O devices.
  • Computer system 1700 may include one or more of these I/O devices, where appropriate.
  • One or more of these VO devices may enable communication between a person and computer system 1700.
  • an VO device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these.
  • An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces 1708 for them.
  • VO interface 1708 may include one or more device or software drivers enabling processor 1702 to drive one or more of these I/O devices.
  • VO interface 1708 may include one or more VO interfaces 1708, where appropriate.
  • communication interface 1710 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 1700 and one or more other computer systems 1700 or one or more networks.
  • communication interface 1710 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network.
  • NIC network interface controller
  • WNIC wireless NIC
  • WI-FI network a wireless network
  • computer system 1700 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these.
  • PAN personal area network
  • LAN local area network
  • WAN wide area network
  • MAN metropolitan area network
  • One or more portions of one or more of these networks may be wired or wireless.
  • computer system 1700 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WLMAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these.
  • WPAN wireless PAN
  • WI-FI wireless personal area network
  • WLMAX wireless personal area network
  • a cellular telephone network such as, for example, a Global System for Mobile Communications (GSM) network
  • GSM Global System for Mobile Communications
  • Computer system 1700 may include any suitable communication interface 1710 for any of these networks, where appropriate.
  • Communication interface 1710 may include one or more communication interfaces 1710, where appropriate.
  • bus 1712 includes hardware, software, or both coupling components of computer system 1700 to each other.
  • bus 1712 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these.
  • Bus 1712 may include one or more buses 1712, where appropriate.
  • a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application- specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate.
  • ICs semiconductor-based or other integrated circuits
  • HDDs hard disk drives
  • HHDs hybrid hard drives
  • ODDs optical disc drives
  • magneto-optical discs magneto-optical drives
  • FDDs floppy diskettes
  • FDDs floppy disk drives
  • SSDs

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Des modes de réalisation concernent de manière générale un procédé pour faciliter une transaction. Le procédé consiste à recevoir, d'un dispositif payeur, une demande d'accès à des données de paiement ; vérifier des données d'accès associées aux données de paiement ; sur la base des données d'accès indiquant que les données de paiement sont accessibles, mettre à jour les données d'accès pour indiquer que les données de paiement ne sont pas accessibles et fournir par la suite les données de paiement au dispositif payeur ; recevoir des détails de paiement générés au niveau du dispositif payeur en réponse à la réception des données de paiement ; amener un paiement à être traité sur la base des détails de paiement reçus ; et en réponse au traitement du paiement, mettre à jour en outre les données d'accès pour indiquer que les données de paiement sont accessibles.
PCT/AU2022/051009 2021-08-25 2022-08-25 Procédés et systèmes de résolution de transactions Ceased WO2023023782A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2022332709A AU2022332709A1 (en) 2021-08-25 2022-08-25 Methods and systems for resolving transactions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2021902740A AU2021902740A0 (en) 2021-08-25 Methods and systems for resolving transactions
AU2021902740 2021-08-25

Publications (1)

Publication Number Publication Date
WO2023023782A1 true WO2023023782A1 (fr) 2023-03-02

Family

ID=85322182

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2022/051009 Ceased WO2023023782A1 (fr) 2021-08-25 2022-08-25 Procédés et systèmes de résolution de transactions

Country Status (2)

Country Link
AU (1) AU2022332709A1 (fr)
WO (1) WO2023023782A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180225649A1 (en) * 2017-02-06 2018-08-09 American Express Travel Related Services Company, Inc. Charge splitting across multiple payment systems
US10134023B2 (en) * 2011-06-22 2018-11-20 Jpmorgan Chase Bank, N.A. System and method for division and management of expenses
US20190228414A1 (en) * 2018-01-24 2019-07-25 Mastercard International Incorporated Method and system for shared payments with tokenized and digitized payment cards
US20200160296A1 (en) * 2017-04-12 2020-05-21 Harex Infotech Inc. Bill splitting system
US20200265394A1 (en) * 2017-11-07 2020-08-20 Line Pay Corporation Information processing program, method, device, and system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10134023B2 (en) * 2011-06-22 2018-11-20 Jpmorgan Chase Bank, N.A. System and method for division and management of expenses
US20180225649A1 (en) * 2017-02-06 2018-08-09 American Express Travel Related Services Company, Inc. Charge splitting across multiple payment systems
US20200160296A1 (en) * 2017-04-12 2020-05-21 Harex Infotech Inc. Bill splitting system
US20200265394A1 (en) * 2017-11-07 2020-08-20 Line Pay Corporation Information processing program, method, device, and system
US20190228414A1 (en) * 2018-01-24 2019-07-25 Mastercard International Incorporated Method and system for shared payments with tokenized and digitized payment cards

Also Published As

Publication number Publication date
AU2022332709A1 (en) 2024-03-14

Similar Documents

Publication Publication Date Title
US11514421B2 (en) Payment via messaging application
US12333576B2 (en) Network security linkage
US10269004B2 (en) QR code-enabled P2P payment systems and methods
US9767458B2 (en) Transferring money using email
KR102112063B1 (ko) 전자상거래 결제를 용이하게 하는 방법 및 시스템
US9536232B2 (en) Transferring money using email
US20130080323A1 (en) Restricted funding source
US10579996B2 (en) Presenting a document to a remote user to obtain authorization from the user
US12346956B1 (en) Method, computer-readable non-transitory storage media, and system for embedded one-click checkout
US20150134508A1 (en) Expedited person to person payment
CA3165099A1 (fr) Systeme et procede d'evaluation d'une interaction numerique avec un service de compte tiers numerique
KR102129371B1 (ko) 제3자 체크아웃 옵션의 동적 제공
US20210241371A1 (en) System for Dynamically Adjusting a Pre-Approval Letter
US20250131396A1 (en) Payment delegation and linking system
US11900452B1 (en) Systems and methods for collateral deposit identification
AU2013315881B2 (en) Obtaining a signature from a remote user
US20210319517A1 (en) System and method for remotely obtaining an electronic signature
US20230401558A1 (en) Systems and methods for message-enabled transfers
JP2020177453A (ja) 第１のサーバの制御方法、端末の情報処理方法、第２のサーバの制御方法、プログラム、第１のサーバ、端末、第２のサーバ
ES2929487T3 (es) Sistema y método para procesar una transacción digital
WO2022212066A1 (fr) Déploiement de représentations de caractéristiques compressées de manière optimale pour rafraîchissement automatisé dans des paradigmes d'apprentissage induits par des événements
US20180357620A1 (en) Methods, Systems, Networks, And Media For Collecting Funds Via Virtual Account Numbers
US20180376277A1 (en) Transaction terminal and system for obtaining third-party locaton based services and method thereof
US20210326836A1 (en) Computerized payments for transaction authorization
WO2023023782A1 (fr) Procédés et systèmes de résolution de transactions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22859669

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022332709

Country of ref document: AU

Ref document number: AU2022332709

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2022332709

Country of ref document: AU

Date of ref document: 20220825

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 19.07.2024)

122 Ep: pct application non-entry in european phase

Ref document number: 22859669

Country of ref document: EP

Kind code of ref document: A1