Reverse charge exchange system and method

Abstract

A method of establishing a reverse charge exchange between an initiating party (12) and a responding party (14) is provided. The method comprises receiving a reverse charge exchange request from the initiating party (12), the reverse charge exchange request specifying an identifier for the intended responding party (14) and indicating the exchange or resource that the at least one initiating party (12) wishes to use or access; verifying the responding party identifier (14) and compiling a reverse charge request message containing the initiating-party identifier and the exchange or resource desired by the initiating party (12); dispatching the reverse charge request message to the identified responding party (14) via a communication channel; receiving acceptance of the reverse charge exchange request from the responding party (14); and upon acceptance establishing a live exchange session between at least the at least one initiating party (12) and the exchange or resource desired by the at least one initiating party (12), via the at least one responding party (14).

Description

[0001] REVERSE CHARGE EXCHANGE SYSTEM AND METHOD

[0002] FIELD OF THE INVENTION

[0003] This invention relates to a method of and related system for establishing and managing a reverse charge exchange between at least one initiating party and at least one responding party (collectively, “transacting entities”). More particularly, the invention provides techniques whereby a responding party voluntarily assumes liability for charges arising from a payment request for a particular purpose, product, goods or service, a digital exchange or a resource utilisation request instigated by an initiating party.

[0004] The invention finds application across numerous industries and network environments, including, without limitation, payments for goods or services, telecommunications, cloud computing, energy distribution, digital content delivery, and Internet-of-Things (loT) ecosystems, and is expressly adaptable to domestic and cross-border transactions subject to differing regulatory regimes.

[0005] BACKGROUND TO THE INVENTION

[0006] Reverse charging for traditional voice calls is well known. However, conventional solutions are generally restricted to bilateral telephony scenarios and do not contemplate: multi-party or group interactions; reverse charging for goods and services; reverse charging for varied digital resources (e.g., network bandwidth, compute cycles, energy credits, or access rights to subscription content); modem payment modalities such as sponsor funding, subscription credits, smart contracts, or digital wallets; heterogeneous communication channels and adaptive networking; or decentralised, peer-to-peer, or distributed deployment architectures with advanced security requirements. Accordingly, there exists a need for a flexible, scalable, and secure framework that generalises the reverse charge concept beyond legacy use-cases and supports emerging technological paradigms.

[0007] SUMMARY OF THE INVENTION

[0008] According to a first aspect of the invention there is provided a method of establishing a reverse charge exchange (or transaction in broad terms) between at least one initiating party and at least one responding party, the method comprising: receiving, by at least one processor, a reverse charge exchange request from at least one initiating party, the reverse charge exchange request specifying an identifier (i.e. contact details) for at least one intended responding party and indicating the type of exchange or resource that the at least one initiating party wishes to use or access; verifying, by at least one processor, each responding party identifier and compiling a reverse charge request message containing at least one initiating- party identifier and the exchange or resource desired by the initiating party; dispatching, by at least one processor, the reverse charge request message to each identified responding party via one or more available communication channels; receiving, by at least one processor, acceptance of the reverse charge exchange request from at least one responding party, the acceptance including confirmation of liability for charges; upon acceptance of the reverse charge exchange request, establishing, by at least one processor, a live exchange session between the at least one initiating party and the exchange or resource desired by the at least one initiating party, via the at least one responding party receiving, by at least one processor, a notification once the live exchange session has been terminated; and settling charges, by at least one processor, in accordance with at least one selected charging model.

[0009] In one embodiment, the request from the at least one initiating party includes a payment request to enable money to be transferred from the at least one responding party to the at least one initiating party, the request from the at least one initiating party including a related parameter corresponding to a product or service provided by a third party that the at least one initiating party wishes to procure using the payment request. In this embodiment, the exchange or resource corresponds to at least one financial account associated with each of the at least one responding party, with the live exchange session being established between the at least one initiating party, the financial account of the at least one responding party and the third party, via the at least one responding party, to ensure payment is made to the third party for the benefit of the at least one initiating party.

[0010] In another embodiment, the exchange or resource desired by the at least one initiating party includes a data exchange or data bandwidth to enable data or data bandwidth to be transferred from the at least one responding party to the at least one initiating party. In this embodiment, the reverse charge exchange request from the at least one initiating party includes a related parameter of the exchange or resource desired by the initiating party, the related parameter including a live exchange session duration and / or a data exchange or data bandwidth limit.

[0011] Alternatively, or in addition, the exchange or resource desired by the at least one initiating party includes computing power, storage capacity, energy credits, or content access rights. Again, in this embodiment, the reverse charge exchange request includes a related parameter associated with the exchange resource desired by the initiating party, the related parameter including computing power quotas, energy allotments, or content access limits. In all cases, the reverse charge request message includes the related parameter associated with the requested exchange or resource desired by the initiating party, with the step of receiving acceptance of the reverse charge exchange request from at least one responding party including the step of receiving acceptance of the related parameter. Thus, in an embodiment, the method includes compiling and sending terms to the at least one initiating party and / or the at least one responding party, which may include the related parameter, with the method further including the step of receiving agreement to these terms from the at least one initiating party and / or the at least one responding party, failing which the live exchange session is not established.

[0012] In an embodiment, the method includes the steps of receiving a revised reverse charge request message including at least one revised parameter from the at least one responding party, sending the revised reverse charge request message to the at least one initiating party, and receiving acceptance of the revised reverse charge message by the at least one initiating party. In other words, this step allows the parties to negotiate, where necessary, the terms of the exchange or resource to be provided to the initiating party.

[0013] In an embodiment, the method includes the step of monitoring usage of the live exchange session, with the method further including the step of terminating the session in line with the agreed at least one parameter. The live exchange session may be implemented using a centralised, distributed, or peer-to-peer architecture, the session being optionally protected by adaptive encryption, multi-factor authentication, and real-time fraud detection.

[0014] In an embodiment, the step of settling charges in accordance with at least one selected charging model includes direct account debit, post-paid invoicing, sponsor or advertiser subsidy, subscription credit deduction, blockchain-based smart-contract execution, or digital-wallet transfer. In an embodiment, the step of receiving acceptance of the reverse charge exchange request from at least one responding party includes the step of receiving the preferred charging model from the at least one responding party.

[0015] In the version in which the exchange or resource desired by the at least one initiating party includes a data exchange or data bandwidth to enable data to be transferred, the step of settling charges includes the step of adding the initiating party to the data plan of the at least one responding party, sending data or data bandwidth from the at least one responding party to the at least one initiating party via a data gifting service, or simply invoicing the at least one responding party for the data used.

[0016] In an embodiment, there is a plurality of initiating parties, in which case the method includes the steps of receiving, by at least one processor, a plurality of reverse charge exchange requests from the plurality of initiating parties, the requests specifying an identifier (i.e. contact details) for at least one intended responding party and indicating the exchange or resource that the plurality of parties wishes to use or access.

[0017] In this version, the method includes receiving an indication from one of the plurality of initiating parties that a plurality of reverse charge exchange requests will be received from the plurality of initiating parties, the method including initiating a timer to enable the remaining initiating parties to send their reverse charge exchange requests before proceeding.

[0018] In an embodiment, there is a plurality of responding parties, in which case the method includes the steps of dispatching, by at least one processor, a plurality of reverse charge request messages to the plurality of responding parties via one or more available communication channels.

[0019] In this case, the method includes the step of receiving, by at least one processor, acceptance of the reverse charge exchange request from a first responding party, the method including initiating a timer to enable the remaining responding parties to send their acceptance / s of the reverse charge exchange request before proceeding. Once all the acceptances of the reverse charge exchange request are received from the plurality of responding parties, the method includes prompting the plurality of responding parties to collectively confirm liability for charges and / or to specify how the charges for the live exchange session are to be allocated between the plurality of responding parties.

[0020] In an embodiment, the method includes the step of generating a usage record of the live exchange session once the live exchange session has been terminated, and then sending the usage record to the at least one initiating party and the at least one responding party. The usage record may be immutably recorded on a blockchain ledger.

[0021] In an embodiment, the at least one initiating party makes and sends the reverse charge exchange request via a first device associated with each initiating party, either a mobile device or a computer device, and the at least one responding party accepts the reverse charge exchange request via a second device associated with the responding party, also either a mobile device or a computer device, with the first and second devices typically being used to allow and facilitate the live exchange session between the at least one initiating party and the exchange or resource desired by the at least one initiating party, via the at least one responding party.

[0022] In an embodiment, the one or more available communication channels is selected from, but not limited to: SMS, LISSD, HTTP / HTTPS APIs, NFC handshakes, QR code scans, Bluetooth signals, 5G messaging, mesh-network broadcasts, satellite links, WiFi, or ad-hoc peer-to-peer networking, or an instant messaging channel, such as WhatsApp.

[0023] In one version, the reverse charge exchange request from the at least one initiating party takes the form of a request via a proprietary software application on the first device, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)). Similarly, the responding party’s acceptance of the reverse charge exchange request from the initiating party takes the form of an acceptance message (or signal in the broad sense) via a corresponding proprietary software application on the second device, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)). In one version, the method includes the steps of interrogating a data set to check whether the responding party had previously agreed to accept a reverse charge exchange request from the initiating party, in which case, the method simply proceeds to establish the exchange between the at least one initiating party and the exchange or resource desired by the at least one initiating party, via the at least one responding party.

[0024] According to a second aspect of the invention there is provided a system for establishing a reverse charge exchange between at least one initiating party and at least one responding party, the system comprising: at least one processor; and a memory device containing instructions which when executed cause the processor to: receive a reverse charge exchange request from at least one initiating party, the reverse charge exchange request specifying an identifier (i.e. contact details) for at least one intended responding party and indicating the type of exchange or resource that the at least one initiating party wishes to use or access; verify each responding party identifier and compiling a reverse charge request message containing at least one initiating-party identifier and the exchange or resource desired by the initiating party; dispatch the reverse charge request message to each identified responding party via one or more available communication channels; receive acceptance of the reverse charge exchange request from at least one responding party, the acceptance including confirmation of liability for charges; upon acceptance of the reverse charge exchange request, establish a live exchange session between at least the at least one initiating party and the exchange or resource desired by the at least one initiating party, via the at least one responding party; receive a notification once the live exchange session has been terminated; and settle charges in accordance with at least one selected charging model.

[0025] In one embodiment, the request from the at least one initiating party includes a payment request to enable money to be transferred from the at least one responding party to the at least one initiating party, the request from the at least one initiating party including a related parameter corresponding to a product or service provided by a third party that the at least one initiating party wishes to procure using the payment request. In this embodiment, the exchange or resource corresponds to at least one financial account associated with each of the at least one responding party, with the live exchange session being established between the at least one initiating party, the financial account of the at least one responding party and the third party, via the at least one responding party, to ensure payment is made to the third party for the benefit of the at least one initiating party.

[0026] In another embodiment, the exchange or resource desired by the at least one initiating party includes a data exchange or data bandwidth to enable data or data bandwidth to be transferred from the at least one responding party to the at least one initiating party. In this embodiment, the reverse charge exchange request from the at least one initiating party includes a related parameter of the exchange or resource desired by the initiating party, the related parameter including a live exchange session duration and / or a data exchange or data bandwidth limit.

[0027] Alternatively, or in addition, the exchange or resource desired by the at least one initiating party includes computing power, storage capacity, energy credits, or content access rights. Again, in this embodiment, the reverse charge exchange request includes a related parameter associated with the exchange or resource desired by the initiating party, the related parameter including computing power quotas, energy allotments, or content access limits.

[0028] In all cases, the reverse charge request message includes the related parameter associated with the requested exchange or resource desired by the initiating party, with the step of receiving acceptance of the reverse charge exchange request from at least one responding party including the step of receiving acceptance of the related parameter. Thus, in an embodiment, the memory device contains instructions which when executed cause the processor to compile and send terms to the at least one initiating party and / or the at least one responding party, which may include the related parameter, with the memory device containing instructions which when executed cause the processor to receive agreement to these terms from the at least one initiating party and / or the at least one responding party, failing which the live exchange session is not established.

[0029] In an embodiment, the memory device contains instructions which when executed cause the processor to receive a revised reverse charge request message including at least one revised parameter from the at least one responding party, send the revised reverse charge request message to the at least one initiating party, and receive acceptance of the revised reverse charge message by the at least one initiating party. In other words, this step allows the parties to negotiate, where necessary, the terms of the exchange or resource to be provided to the initiating party.

[0030] In an embodiment, the memory device contains instructions which when executed cause the processor to monitor usage of the live exchange session, with the memory device containing instructions which when executed cause the processor to terminate the session in line with the agreed at least one parameter.

[0031] In an embodiment, the memory device contains instructions which when executed cause the processor to receive the preferred charging model from the at least one responding party. In the version in which the exchange or resource desired by the at least one initiating party includes a data exchange or data bandwidth to enable data to be transferred, the step of settling charges includes the step of adding the initiating party to the data plan of the at least one responding party, sending data or data bandwidth from the at least one responding party to the at least one initiating party via a data gifting service, or simply invoicing the at least one responding party for the data used.

[0032] In an embodiment, there is a plurality of initiating parties, in which case the memory device contains instructions which when executed cause the processor to receive a plurality of reverse charge exchange requests from the plurality of initiating parties, the requests specifying an identifier (i.e. contact details) for at least one intended responding party and indicating the exchange or resource that the plurality of parties wishes to use or access.

[0033] In this version, the memory device contains instructions which when executed cause the processor to receive an indication from one of the plurality of initiating parties that a plurality of reverse charge exchange requests will be received from the plurality of initiating parties, the memory device contains instructions which when executed cause the processor to initiate a timer to enable the remaining initiating parties to send their reverse charge exchange requests before proceeding.

[0034] In an embodiment, there is a plurality of responding parties, in which case the memory device contains instructions which when executed cause the processor to dispatch a plurality of reverse charge request messages to the plurality of responding parties via one or more available communication channels.

[0035] In this case, the memory device contains instructions which when executed cause the processor to receive acceptance of the reverse charge exchange request from a first responding party, the memory device containing instructions which when executed cause the processor to initiate a timer to enable the remaining responding parties to send their acceptance / s of the reverse charge exchange request before proceeding. Once all the acceptances of the reverse charge exchange request are received from the plurality of responding parties, the memory device contains instructions which when executed cause the processor to prompt the plurality of responding parties to collectively confirm liability for charges and / or to specify how the charges for the live exchange session are to be allocated between the plurality of responding parties.

[0036] In an embodiment, the memory device contains instructions which when executed cause the processor to generate a usage record of the live exchange session once the live exchange session has been terminated, and then send the usage record to the at least one initiating party and the at least one responding party.

[0037] In an embodiment, the at least one initiating party makes and sends the reverse charge exchange request via a first device associated with each initiating party, either a mobile device or a computer device, and the at least one responding party accepts the reverse charge exchange request via a second device associated with the responding party, also either a mobile device or a computer device, with the first and second devices typically being used to allow and facilitate the live exchange session between the at least one initiating party and the exchange or resource desired by the at least one initiating party, via the at least one responding party.

[0038] In an embodiment, the one or more available communication channels is selected from, but not limited to: SMS, LISSD, HTTP / HTTPS APIs, NFC handshakes, QR code scans, Bluetooth signals, 5G messaging, mesh-network broadcasts, satellite links, WiFi, or ad-hoc peer-to-peer networking, or an instant messaging channel, such as WhatsApp.

[0039] In one version, the reverse charge exchange request from the at least one initiating party takes the form of a request via a proprietary software application on the first device, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)). Similarly, the responding party’s acceptance of the reverse charge exchange request from the initiating party takes the form of an acceptance message (or signal in the broad sense) via a corresponding proprietary software application on the second device, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)).

[0040] In one version, the memory device contains instructions which when executed cause the processor to interrogate a data set to check whether the responding party had previously agreed to accept a reverse charge exchange request from the initiating party, in which case, the memory device contains instructions which when executed cause the processor to proceed to establish the live exchange session between the at least one initiating party and the digital exchange or resource desired by the at least one initiating party, via the at least one responding party.

[0041] BRIEF DESCRIPTION OF DRAWINGS

[0042] The objects of this invention and the manner of obtaining them, will become more apparent, and the invention itself will be better understood, by reference to the following description of embodiments of the invention taken in conjunction with the accompanying diagrammatic drawing, wherein:

[0043] Figure 1 shows a high-level flowchart summarising a method of establishing a reverse charge exchange between at least one initiating party and at least one responding party, according to the present invention;

[0044] Figure 2 shows a more detailed schematic process flow overview of the method shown in Figure 1 ; and

[0045] Figure 3 shows a high-level block diagram of a system to establish a reverse charge exchange between at least one initiating party and at least one responding party, according to a further aspect of the present invention.

[0046] DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0047] The following description of the invention is provided as an enabling teaching of the invention. Those skilled in the relevant art will recognise that many changes can be made to the embodiment described, while still attaining the beneficial results of the present invention. It will also be apparent that some of the desired benefits of the present invention can be attained by selecting some of the features of the present invention without utilising other features. Accordingly, those skilled in the art will recognise that modifications and adaptations to the present invention are possible and can even be desirable in certain circumstances, and are a part of the present invention. Thus, the following description is provided as illustrative of the principles of the present invention and not a limitation thereof.

[0048] Referring first to Figure 1 , a method 10 of establishing a reverse charge exchange between at least one initiating party 12 (also referred to as first user 12) and at least one responding party 14 (also referred to as a second user 14) is shown. The method 10 comprises the step of receiving a reverse charge exchange request from the first user / initiating party 12 to make a reverse charge exchange with the second user / responding party 14, as indicated by block 16. The request typically includes an identifier for the second user / responding party 14, including, but not limited to, an email address, telephone number or some other predetermined identifier uniquely linked to the second user / responding party 14. The request typically further includes the type of exchange or resource that the at least one initiating party 12 wishes to consume, use or access.

[0049] In one embodiment, the request from the at least one initiating party 12 includes a payment request to enable money to be transferred from the at least one responding party 14 to the at least one initiating party 12. The request from the at least one initiating party 12 may include a related parameter corresponding to a product or service provided by a third party (not shown) that the at least one initiating party 12 wishes to procure using the payment request. In this embodiment, the exchange or resource corresponds to at least one financial account associated with each of the at least one responding party 14, with a live exchange session being established between the at least one initiating party 12, the financial account of the at least one responding party 14 and the third party, via the at least one responding party 14, to ensure payment is made to the third party for the benefit of the at least one initiating party 12.

[0050] Some examples of this first embodiment include are as follows, in which a request for money is based on a specific amount to be used for a specific purpose: Example 1 : The initiating party 12 requests the responding party 14 for a specific and defined amount of money for the specific and defined purpose of buying groceries at a specific retailer. The funds cannot be used for any other purpose as specifically provided for in the request.

[0051] Example 2: - The initiating party 12 requests a specific value of pre-paid airtime for a mobile phone service provider. If it is approved, by the responding party, the live exchange session will only allow the responding party to buy such specific and defined amount, as stipulated in the request, from the specified mobile phone service provider. The funds cannot be used for any other purpose as specifically provided for in the request.

[0052] In another embodiment, the exchange or resource desired by the at least one initiating party 12 includes a data exchange or data bandwidth to enable data or data bandwidth to be transferred between the at least one initiating party 12 and the at least one responding party 14 (and typically from the at least one responding party to the at least one initiating party). In this embodiment, the reverse charge exchange request from the at least one initiating party 12 includes a related parameter of the exchange or resource desired by the initiating party 12, the related parameter including a live exchange session duration and / or a data exchange or data bandwidth limit.

[0053] In this version, the data exchange could be for various purposes such as sharing files, playing online games, or accessing a shared service. At a practical level, the first user / initiating party 12, who may not have a sufficient data balance or does not wish to use their own data, requests the second user / responding party 14 to pay for the data charges incurred during the requested connection.

[0054] Alternatively, or in addition, the exchange or resource desired by the at least one initiating party 12 includes computing power, storage capacity, energy credits, or content access rights. Again, in this embodiment, the exchange request includes a related parameter associated with the requested exchange or resource desired by the initiating party 12, the related parameter including computing power quotas, energy allotments, or content access limits. The method 10 then includes the step of verifying the second user’s / responding party’s identifier and compiling and sending a reverse charge exchange request to the second user / responding party 14, as indicated by block 18, via one or more available communication channels. The reverse charge exchange request includes an identifier for the first user / initiating party 12, which again may include an email address, telephone number or some other predetermined identifier uniquely linked to the first user / initiating party 12. The reverse charge exchange request further includes the type of digital exchange or resource desired by the initiating party 12.

[0055] The method 10 then includes the step of receiving acceptance of the reverse charge exchange request from the second user / responding party 14, as indicated by block 20.

[0056] In all cases, the reverse charge request message includes the related parameter associated with the requested exchange or resource desired by the initiating party 12. The step of receiving acceptance of the reverse charge exchange request from at least one responding party 14 may include the step of receiving acceptance of the related parameter. Thus, in an embodiment, the method 10 includes compiling and sending terms to the at least one initiating party 12 and / or the at least one responding party 14, which may include the related parameter. The method 10 may further include the step of receiving agreement to these terms from the at least one initiating party 12 and / or the at least one responding party 14, failing which the live exchange session is not established.

[0057] In an embodiment, the method 10 includes the steps of receiving a revised reverse charge request message including at least one revised parameter from the at least one responding party 14, sending the revised reverse charge request message to the at least one initiating party 12, and receiving acceptance of the revised reverse charge message by the at least one initiating party 12. In other words, this step allows the parties 12, 14 to negotiate, where necessary, the terms of the exchange or resource to be provided to the initiating party 12.

[0058] In an embodiment, the first user / initiating party 12 makes the reverse charge exchange request via a first device 22 associated with the first user / initiating party 12, either a mobile device or a computer device, the second user accepts the reverse charge exchange request via a second device 24 associated with the second user / responding party 14, also either a mobile device or a computer device, with the first and second devices 22, 24 typically being used to allow and facilitate the data exchange between the first user / initiating party 12 and the second user / responding party 14.

[0059] In an embodiment, the one or more available communication channels is selected from, but not limited to: SMS, LISSD, HTTP / HTTPS APIs, NFC handshakes, QR code scans, Bluetooth signals, 5G messaging, mesh-network broadcasts, satellite links, WiFi, or ad-hoc peer-to-peer networking, or an instant messaging channel, such as WhatsApp.

[0060] In an embodiment, the reverse charge exchange request from the first user / initiating party 12 takes the form of a request via a proprietary software application on the device 22 associated with the first user / initiating party 12, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)). Similarly, acceptance from the second user / responding party 14 of the reverse charge exchange request from the first user / initiating party 12 takes the form of an acceptance message (or signal in the broad sense) via a corresponding proprietary software application on the device 24 associated with the second user / responding party 14, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)).

[0061] The method 10 then includes the step of establishing the live exchange session between at least the first user / initiating party 12 and / or the second user / responding party 14 and / or the exchange or resource (depending upon the nature of the desired exchange or resource), as indicated by block 26, typically using the internet or a mobile telephone network or a satellite network. In this regard, in one version, the HTTP protocol and JSON API payload are used to facilitate a web-based exchange of data between the first user / initiating party 12 and the second user / responding party 14.

[0062] The method 10 then includes the step of receiving a notification once the exchange has been terminated, as indicated by block 28. The method 10 then concludes by settling charges, in accordance with at least one selected charging model. This includes the step of determining the exchange charge and accordingly charging the second user / responding party 14 for the live exchange session or connection, as indicated by block 30.

[0063] In one version, as indicated above, the method 10 includes compiling and sending terms, to the first user / initiating party 12 and / or second user / responding party 14, which may include the duration of the connection, the maximum amount of data that may be used, and the payment method. The method 10 includes the step of receiving agreement to these terms from the first user / initiating party 12 and / or second user / responding party 14, failing which the exchange is not established.

[0064] The step of settling charges in accordance with at least one selected charging model includes direct account debit, post-paid invoicing, sponsor or advertiser subsidy, subscription credit deduction, blockchain-based smart-contract execution, or digitalwallet transfer. In an embodiment, the step of receiving acceptance of the reverse charge exchange request from at least one responding party 14 includes the step of receiving the preferred charging model from the at least one responding party 14.

[0065] As such, the step of charging the second user / responding party 14 for the exchange may be done through various methods, depending upon the nature of the desired exchange or resource. In the case of data or data bandwidth, for example, the first user / initiating party 12 may simply be added to the second user’s data plan, and / or data may be sent from the second user / responding party 14 to the first user / initiating party 12 via a data gifting service, and / or the second user / responding party 14 may simply be invoiced for the data used.

[0066] In one version, the method 10 includes the steps of interrogating a data set to check whether the second user / responding party 14 had previously agreed to accept a reverse charge exchange request from the first user / initiating party 12, in which case, the method simply proceeds to establish the exchange between the first user / initiating party 12 and the second user / responding party 14. Turning now to Figure 2, in a bit more detail, a related process flow 50 is shown, to establish a reverse charge exchange between a first user / initiating party 12 and a second user / responding party 14, via a platform engine 52.

[0067] The process flow 50 includes an exchange initiation stage 54 in which the first user / initiating party 12 either initiates a reverse charge exchange request or selects an option to make a reverse charge exchange request (block 56). The first user / initiating party 12 is then prompted to enter the second user's / responding party’s 14 unique identifier or select them from a list (if available) (block 58).

[0068] The process flow 50 further includes a processing request stage 60, in which the engine 52 verifies the second user's / responding party’s 14 unique identifier (block 62) and then sends a reverse charge exchange request to the second user / responding party 14 (block 64). As described above, the reverse charge request message includes details (and related parameters) of the exchange or resource desired by the initiating party 12.

[0069] In an exchange request stage 66 the second user / responding party 14 receives the notification about the incoming reverse charge exchange request (block 68) and is presented with options to either accept or decline the exchange request (block 70). If the second user / responding party 14 declines the exchange request (block 72) the first user / initiating party 12 is notified accordingly (block 74). If there is no response from the second user / responding party 14 within a predetermined time period (block 76), the engine 52 cancels the exchange request (block 78), and the first user / initiating party 12 is notified accordingly (block 80).

[0070] If, however, the second user / responding party 14 accepts the exchange request (block 82), the second user / responding party 14 is prompted to confirm their agreement to pay for the exchange (block 84). In an exchange acceptance and charges acknowledgement stage 86, if the second user / responding party 14 declines to pay for the exchange (block 88), the first user / initiating party 12 is notified accordingly (block 90) and the engine 52 cancels the exchange request (block 92). If the second user / responding party 14 agrees to pay for the exchange (block 94), an exchange establishment stage 96 is initiated, in which a live exchange session between the first user / initiating party 12 and / or the second user / responding party 14 and / or the desired exchange or resource and / or a third party is established (block 98). In this stage 96, the first user / initiating party 12 and the second user / responding party 14 are notified that an active exchange has been established (blocks 100 and 102, respectively).

[0071] During an active exchange stage 104 of the live exchange session, the first user / initiating party 12 and the second user / responding party 14 can communicate with each other (blocks 106 and 108, respectively), with the engine 52 simultaneously initiating a timer (or similar notification system) to indicate the duration and / or data usage of the exchange (block 110).

[0072] At the end of the exchange between the first user / initiating party 12 and the second user / responding party 14, in an ending exchange stage 112, either of the first user / initiating party 12 or the second user / responding party 14 can terminate the exchange (blocks 114 and 116, respectively), with the engine 52 then terminating the exchange (block 118).

[0073] In a post termination process stage 120, the first user / initiating party 12 and the second user / responding party 14 receive a notification that the exchange has been terminated (blocks 122 and 124, respectively). The engine 52 then creates a summary of the exchange charges (block 126), which it then sends to the second user / responding party 14 (block 128). The related charges are then deducted from an account of the second user / responding party 14 or billed to the second user / responding party 14 for the exchange in terms of an underlying service agreement (block 130).

[0074] In an optional feedback stage 132, the first user / initiating party 12 and the second user / responding party 14 are prompted to rate the service and / or provide feedback (blocks 134 and 136, respectively).

[0075] Turning now to Figure 3, according to a further embodiment of the invention, there is provided a system 150 for establishing a reverse charge exchange between a first user / initiating party 12 and a second user / responding party 14. The system 150 comprises at least one processor or controller 152 and a memory device 154 containing instructions which when executed cause the processor 152 to receive a request from the first user / initiating party 12 to make a reverse charge exchange with the second user / responding party 14, as indicated by arrow 156. As indicated above, the request typically includes an identifier for the second user / responding party 14.

[0076] The processor 152 is then arranged to verify the second user’s identifier, typically with reference to a related data set 158, and then compile and send a reverse charge exchange request to the second user / responding party 14, as indicated by arrow 160. As indicated above, the reverse charge exchange request typically includes an identifier for the first user / initiating party 12.

[0077] The processor 152 is then arranged to receive acceptance of the reverse charge exchange request from the second user / responding party 14, as indicated by arrow 162, in response to which the processor 152 instructs an exchange system 164 to establish the exchange between the first user / initiating party 12 and the second user / responding party 14, as indicated by arrows 166.

[0078] As described above, upon receipt of a notification that the exchange has been terminated, the processor 152 is arranged to determine the exchange charge and accordingly charging the second user / responding party 14 for the connection, via a billing module 168.

[0079] In one version, the memory device 154 contains instructions which when executed cause the processor 152 to compile and send terms, to the first user / initiating party 12 and / or the second user / responding party 14, which may include the duration of the connection, the amount of data to be used, and the payment method. The memory device 154 contains instructions which when executed cause the processor 152 to receive agreement to these terms from the first user / initiating party 12 and / or second user / responding party 14, failing which the exchange is not established.

[0080] In an embodiment, the first user / initiating party 12 makes the request 156 via a first device 22 associated with the first user, either a mobile device or a computer device, the second user / responding party 14 accepts the request via a second device 24 associated with the second user / responding party 14, also either a mobile device or a computer device, with the first and second devices 22, 24 typically being used to allow and facilitate the exchange 166 between the first user / initiating party 12 and the second user / responding party 14.

[0081] In an embodiment, the request from the first user / initiating party 12 takes the form of a request via a proprietary software application on the first user’s device 22, or a text or instant message (e.g. WhatsApp message) or a LISSD code or a web request (via an application programming interface (API)). Similarly, the second user’s acceptance of the reverse charge exchange request from the first user / initiating party 12 takes the form of an acceptance message (or signal in the broad sense) via a corresponding proprietary software application on the second user’s device 24, or a text or instant message or a LISSD code or a web request (via an application programming interface (API)).

[0082] In one version, the memory device 154 contains instructions which when executed cause the processor 152 to interrogate the data set 158 to check whether the second user / responding party 14 had previously agreed to accept a reverse charge from the first user / initiating party 12, in which case, the processor 152 simply proceeds to instruct the exchange system 164 to establish the exchange between the first user / initiating party 12 and the second user / responding party 14.

Claims

CLAIMS1 . A method of establishing a reverse charge exchange between at least one initiating party and at least one responding party, the method comprising: receiving, by at least one processor, a reverse charge exchange request from at least one initiating party, the reverse charge exchange request specifying an identifier for at least one intended responding party and indicating the type of exchange that the at least one initiating party wishes to use or access; verifying, by at least one processor, each responding party identifier and compiling a reverse charge request message containing at least one in itiating-party identifier and the exchange desired by the initiating party; dispatching, by at least one processor, the reverse charge request message to each identified responding party via one or more available communication channels; receiving, by at least one processor, acceptance of the reverse charge exchange request from at least one responding party, the acceptance including confirmation of liability for charges; upon acceptance of the reverse charge exchange request, establishing, by at least one processor, a live exchange session between the at least one initiating party and the exchange desired by the at least one initiating party, via the at least one responding party; receiving, by at least one processor, a notification once the live exchange session has been terminated; and settling charges, by at least one processor, in accordance with at least one selected charging model.

2. The method of claim 1 , wherein the request from the at least one initiating party includes a payment request to enable money to be transferred from the at least one responding party to the at least one initiating party, the request from the at least one initiating party including a related parameter corresponding to a product or service provided by a third party that the at least one initiating party wishes to procure using the payment request.

3. The method of claim 2, wherein the exchange corresponds to at least one financial account associated with each of the at least one responding party, with the live exchange session being established between the at least one initiating party, the financial account of the at least one responding party and the third party, via the at least one responding party, to ensure payment is made to the third party for the benefit of the at least one initiating party.

4. The method of claim 1 , wherein the exchange desired by the at least one initiating party includes a data exchange or data bandwidth to enable data or data bandwidth to be transferred from the at least one responding party to the at least one initiating party.

5. The method of claim 4, wherein the reverse charge exchange request from the at least one initiating party includes a related parameter of the exchange desired by the initiating party, the related parameter including a live exchange session duration and / or a data exchange or data bandwidth limit.

6. The method of claim 1 , wherein the exchange desired by the at least one initiating party includes computing power, storage capacity, energy credits, or content access rights, with the reverse charge exchange request including a related parameter associated with the exchange desired by the initiating party, the related parameter including computing power quotas, energy allotments, or content access limits.

7. The method of any one of preceding claims 2 to 6, wherein the reverse charge request message includes the related parameter associated with the requested exchange desired by the initiating party, with the step of receiving acceptanceof the reverse charge exchange request from at least one responding party including the step of receiving acceptance of the related parameter.

8. The method of claim 7, wherein the method includes compiling and sending terms to the at least one initiating party and / or the at least one responding party, which include the related parameter, with the method further including the step of receiving agreement to these terms from the at least one initiating party and / or the at least one responding party, failing which the live exchange session is not established.

9. The method of claim 8, wherein the method includes the steps of receiving a revised reverse charge request message including at least one revised parameter from the at least one responding party, sending the revised reverse charge request message to the at least one initiating party, and receiving acceptance of the revised reverse charge message by the at least one initiating party.

10. The method of any one of claims 2 to 9, wherein the method includes the step of monitoring usage of the live exchange session, with the method further including the step of terminating the session in line with the agreed at least one parameter.

11. The method of any preceding claim, wherein the step of settling charges in accordance with at least one selected charging model includes direct account debit, post-paid invoicing, sponsor or advertiser subsidy, subscription credit deduction, blockchain-based smart-contract execution, or digital-wallet transfer.

12. The method of claim 11 , wherein the step of receiving acceptance of the reverse charge exchange request from at least one responding party includes the step of receiving the preferred charging model from the at least one responding party.

13. The method of any preceding claim, when dependent upon either claim 4 or claim 5, wherein the step of settling charges includes the step of adding the initiating party to the data plan of the at least one responding party, sending data or data bandwidth from the at least one responding party to the at least one initiating party via a data gifting service, or invoicing the at least one responding party for the data used.

14. The method of any preceding claim, which includes a plurality of initiating parties, in which case the method includes the steps of receiving, by at least one processor, a plurality of reverse charge exchange requests from the plurality of initiating parties, the requests specifying an identifier for at least one intended responding party and indicating the exchange that the plurality of parties wishes to use or access.

15. The method of claim 14, wherein the method includes receiving an indication from one of the plurality of initiating parties that a plurality of reverse charge exchange requests will be received from the plurality of initiating parties, the method including initiating a timer to enable the remaining initiating parties to send their reverse charge exchange requests before proceeding.

16. The method of either claim 14 or claim 15, which includes a plurality of responding parties, in which case the method includes the steps of dispatching, by at least one processor, a plurality of reverse charge request messages to the plurality of responding parties via one or more available communication channels.

17. The method of claim 16, wherein the method includes the step of receiving, by at least one processor, acceptance of the reverse charge exchange request from a first responding party, the method including initiating a timer to enable the remaining responding parties to send their acceptance / s of the reverse charge exchange request before proceeding.

18. The method of claim 17, wherein once all the acceptances of the reverse charge exchange request are received from the plurality of responding parties, themethod includes prompting the plurality of responding parties to collectively confirm liability for charges and / or to specify how the charges for the live exchange session are to be allocated between the plurality of responding parties.

19. The method of any preceding claim, wherein the method includes the step of generating a usage record of the live exchange session once the live exchange session has been terminated, and then sending the usage record to the at least one initiating party and the at least one responding party.

20. A system for establishing a reverse charge exchange between at least one initiating party and at least one responding party, the system comprising: at least one processor; and a memory device containing instructions which when executed cause the processor to: receive a reverse charge exchange request from at least one initiating party, the reverse charge exchange request specifying an identifier for at least one intended responding party and indicating the exchange that the at least one initiating party wishes to use or access; verify each responding party identifier and compiling a reverse charge request message containing at least one initiating-party identifier and the exchange desired by the initiating party; dispatch the reverse charge request message to each identified responding party via one or more available communication channels;receive acceptance of the reverse charge exchange request from at least one responding party, the acceptance including confirmation of liability for charges; upon acceptance of the reverse charge exchange request, establish a live exchange session between the at least one initiating party and the exchange desired by the at least one initiating party, via the at least one responding party; receive a notification once the live exchange session has been terminated; and settle charges in accordance with at least one selected charging model.21 . The system of claim 20, wherein the request from the at least one initiating party includes a payment request to enable money to be transferred from the at least one responding party to the at least one initiating party, the request from the at least one initiating party including a related parameter corresponding to a product or service provided by a third party that the at least one initiating party wishes to procure using the payment request.

22. The system of claim 21 , wherein the exchange corresponds to at least one financial account associated with each of the at least one responding party, with the live exchange session being established between the at least one initiating party, the financial account of the at least one responding party and the third party, via the at least one responding party, to ensure payment is made to the third party for the benefit of the at least one initiating party.

23. The system of claim 20, wherein the exchange desired by the at least one initiating party includes a data exchange or data bandwidth to enable data or data bandwidth to be transferred from the at least one responding party to the at least one initiating party.

24. The system of claim 23, wherein the reverse charge exchange request from the at least one initiating party includes a related parameter of the exchange desired by the initiating party, the related parameter including a live exchange session duration and / or a data exchange or data bandwidth limit.

25. The system of claim 20, wherein the exchange desired by the at least one initiating party includes computing power, storage capacity, energy credits, or content access rights, with the reverse charge exchange request includes a related parameter associated with the exchange desired by the initiating party, the related parameter including computing power quotas, energy allotments, or content access limits.

26. The system of any one of preceding claims 21 to 25, wherein the reverse charge request message includes the related parameter associated with the requested exchange desired by the initiating party, with the step of receiving acceptance of the reverse charge exchange request from at least one responding party including the step of receiving acceptance of the related parameter.

27. The system of claim 26, wherein the memory device contains instructions which when executed cause the processor to compile and send terms to the at least one initiating party and / or the at least one responding party, which may include the related parameter, with the memory device containing instructions which when executed cause the processor to receive agreement to these terms from the at least one initiating party and / or the at least one responding party, failing which the live exchange session is not established.

28. The system of claim 27, wherein the memory device contains instructions which when executed cause the processor to receive a revised reverse charge request message including at least one revised parameter from the at least one responding party, send the revised reverse charge request message to the at least one initiating party, and receive acceptance of the revised reverse charge message by the at least one initiating party.

29. The system of any one of preceding claims 21 to 28, wherein the memory device contains instructions which when executed cause the processor to monitor usage of the live exchange session, with the memory device containing instructions which when executed cause the processor to terminate the session in line with the agreed at least one parameter.

30. The system of any one of preceding claims 20 to 29, wherein the memory device contains instructions which when executed cause the processor to receive the preferred charging model from the at least one responding party, the charging model being selected from a group comprising direct account debit, post-paid invoicing, sponsor or advertiser subsidy, subscription credit deduction, blockchain-based smart-contract execution, or digital-wallet transfer.

31. The system of any one of preceding claims 20 to 30, when dependent upon either claim 23 or 24, wherein the memory device contains instructions which when executed cause the processor to add the initiating party to the data plan of the at least one responding party, send data or data bandwidth from the at least one responding party to the at least one initiating party via a data gifting service, or invoicing the at least one responding party for the data used.

32. The system of any one of preceding claims 20 to 31 , which includes a plurality of initiating parties, in which case the memory device contains instructions which when executed cause the processor to receive a plurality of reverse charge exchange requests from the plurality of initiating parties, the requests specifying an identifier for at least one intended responding party and indicating the exchange that the plurality of parties wishes to use or access.

33. The system of claim 32, wherein the memory device contains instructions which when executed cause the processor to receive an indication from one of the plurality of initiating parties that a plurality of reverse charge exchange requests will be received from the plurality of initiating parties, the memory device contains instructions which when executed cause the processor to initiate atimer to enable the remaining initiating parties to send their reverse charge exchange requests before proceeding.

34. The system of either claim 32 or claim 33, which includes a plurality of responding parties, in which case the memory device contains instructions which when executed cause the processor to dispatch a plurality of reverse charge request messages to the plurality of responding parties via one or more available communication channels.

35. The system of claim 34, wherein the memory device contains instructions which when executed cause the processor to receive acceptance of the reverse charge exchange request from a first responding party, the memory device containing instructions which when executed cause the processor to initiate a timer to enable the remaining responding parties to send their acceptance / s of the reverse charge exchange request before proceeding.

36. The system of any claim 35, wherein once all the acceptances of the reverse charge exchange request are received from the plurality of responding parties, the memory device contains instructions which when executed cause the processor to prompt the plurality of responding parties to collectively confirm liability for charges and / or to specify how the charges for the live exchange session are to be allocated between the plurality of responding parties.

37. The system of any one of preceding claims 20 to 36, wherein the memory device contains instructions which when executed cause the processor to generate a usage record of the live exchange session once the live exchange session has been terminated, and then send the usage record to the at least one initiating party and the at least one responding party.

38. The system of any one of preceding claims 20 to 37, wherein the at least one initiating party makes and sends the reverse charge exchange request via a first device associated with each initiating party, either a mobile device or a computer device, and the at least one responding party accepts the reverse charge exchange request via a second device associated with the respondingparty, also either a mobile device or a computer device, with the first and second devices typically being used to allow and facilitate the live exchange session between the at least one initiating party and / or the exchange desired by the at least one initiating party, via the at least one responding party.

39. The system of any one of preceding claims 20 to 38, wherein the one or more available communication channels is selected from, but not limited to: SMS, LISSD, HTTP / HTTPS APIs, NFC handshakes, QR code scans, Bluetooth signals, 5G messaging, mesh-network broadcasts, satellite links, Wi-Fi, ad-hoc peer-to-peer networking, or an instant messaging channel.

40. The system of claim 39, wherein the reverse charge exchange request from the at least one initiating party takes the form of a request via a proprietary software application on the first device, or a text or instant message or a LISSD code or a web request, and the responding party’s acceptance of the reverse charge exchange request from the initiating party takes the form of an acceptance message via a corresponding proprietary software application on the second device, or a text or instant message or a LISSD code or a web request.

Images