METHOD AND SYSTEM FOR REFUNDING A PURCHASE

Abstract

A system and method for refunding selected purchases from a considerable number of purchases made during a given accumulation period. The refunding is based on a specific time of the execution of the transaction during the given accumulation period. The refund process is further based on the acceptance of the refund by the user on a main user device during a notification period or, alternatively, in the absence of the approval of the refund from the main user device during the notification period, the acceptance of the refund on an alternative user device. In the absence of acceptance of the refund from the alternative user device after an other notification period, the refund is sent to a quarantine account for claiming by the user for a quarantine period after which the refund will be diffused for alternative uses.

Claims

1. A system for crediting a refund to a user account of a user, the system comprising: a refund server having a refund processor and a refund computer-readable memory for storing instructions to be executed by the refund processor, and a notification server having a notification processor and a notification computer-readable memory for storing instructions to be executed by the notification server, the notification server being linked for data communication to the refund server; the refund server being linked for data communication to: merchant interfaces remotely located from the refund server, the merchant interfaces being configured to collect data from payments for respective transactions, each payment having a payment identification (ID) associated thereto, wherein the merchant interfaces are configured to generate, for each transaction, a unique time stamp based on a specific time of the transaction; a user account database for storing entries of user accounts; a transaction database for storing transaction data, each transaction data being associated with a transaction associated with a payment; and a trust account for accumulating a pool of funds; based on the instructions stored in the refund computer-readable memory, the refund server is configured: to generate entries of user accounts in the user account database, each entry of a user account comprising an identification of a main user device; for each transaction during a given accumulation period: to receive, from the merchant interfaces, the transaction data comprising the unique time stamp, a transaction ID, and a number representative of a purchase price; simultaneously with receiving the transaction data, to receive and to transmit to the trust account, a portion of the number representative of the purchase price to accumulate a balance amount of the trust account, the portion of the number representative of the purchase price being less than the purchase price; to store the transaction data in the transaction database with sequenced transactions, the sequenced transactions being ordered based on time and executed during the given accumulation period; and to select a subset of the sequenced transactions and labeling the transactions of the subset of the sequenced transactions as labeled transactions, the subset of the sequenced transactions being selected starting from a first labeled transaction being the most cotemporal to a given time within the given accumulation period based on the unique time stamp of the first labeled transaction, and ending with a cut-off labeled transaction, where a sum of each number representative of the purchase price of the transactions, for the labeled transactions between and including the first labeled transaction and at least a portion of the cut-off labeled transaction, is equal to or more than the balance amount; for each labeled transaction of the subset of the sequenced transactions: to determine, at the user account database, a labeled user account corresponding to the labeled transaction; and to generate a notification script and transferring the notification script to the notification server, the notification script comprising identification of the labeled user account, an amount of the refund, an address of the notification server, and the identification of the main user device comprising an address of the main user device; to receive and to execute a refund script received from the notification server to credit the refund to the user account by transferring funds from the trust account to the user account; and based on the instructions stored in the notification computer-readable memory, the notification server being configured: to execute the notification script resulting in sending a prompt to the main user device to approve the refund; and in response to an approval of the refund received from the main user device to generate, by the notification processor, the refund script for crediting the user account, the refund script comprising the identification of the user account and an amount of refund.

2. The system of claim 1, wherein: the payments are made using payment cards; the merchant interfaces comprise merchant terminals remotely located from the refund server; the merchant terminals form part of the system for crediting a refund; the merchant terminals are configured to collect data from the payment cards for respective transactions when one of the payment cards is read by one of the merchant terminals, each payment card having a card identification (ID) associated thereto; and for each transaction executed between a payment card and an associated merchant terminal during the given accumulation period, the merchant terminals are configured: to sense a payment card to perform the transaction and to receive a card identification (ID); and to generate the unique time stamp based on the specific time of the transaction.

3. The system of claim 2, wherein the user account database, the transaction database and the trust account form part of the system for crediting a refund.

4. The system of claim 1, wherein executing the notification script by the notification server by sending the prompt to the main user device to approve the refund further comprises: generating and sending, by the notification server, a notification to the main user device, the notification including the amount of the refund to be credited to the labeled user account; and monitoring during a notification period, by the notification server, approval of the refund from the main user device.

5. The system of claim 4, wherein in the absence of the approval of the refund from the main user device during the notification period: generating, by the notification server, a primary expiry script to request an alternative user device ID of an alternative user device, the primary expiry script comprising a main user device ID of the main user device and the address of the notification server; sending the primary expiry script to the refund server; executing the primary expiry script at the refund server to determine an alternative user device; and using the alternative user device instead of the main user device for execution to generate another notification script thereby resulting in sending the notification to the alternative user device for monitoring, by the notification server, during an other notification period.

6. The system of claim 5, wherein the refund server is further linked for data communication to a quarantine account, and further wherein, in the absence of the approval of the refund from the alternative user device during the other notification period, generating, by the notification server, a secondary expiry script for execution by the refund server to transfer the refund to the quarantine account.

7. The system of claim 6, wherein, after a quarantine period, the notification server: generates and sends a quarantine notification to the main user device, the quarantine notification including the amount of the refund to be credited to the labeled user account; and monitors, during a quarantine notification period, approval of the refund from the main user device.

8. The system of claim 7, wherein in the absence of the approval of the refund from the main user device during the quarantine notification period generating, by the notification server, a quarantine expiry script for execution by the refund server to diffuse the refund for alternative uses.

9. The system of claim 1, wherein: the notification server: generates an authentication script to request a login information to the user account; transmits, to the user device, the authentication script to request the login information to the user account; in response to receiving a notification from the main user device that the user clicked on a notification link, displays a login page and prompting the user to enter an account login ID and password requested from the main user device; and requests, from the main user device, a passcode captured in response to the user entering the passcode at the main user device; the refund server verifies the passcode received from the main user device; and the notification server receives a notification of acceptance of the refund, from the main user device, in response to the user clicking on a refund link.

10. A method for crediting a refund to a user account of a user, the method executed by: a refund server having a refund processor and a refund computer-readable memory for storing instructions to be executed by the refund processor, and a notification server having a notification processor and a notification computer-readable memory for storing instructions to be executed by the notification server, the notification server being linked for data communication to the refund server; the refund server being linked for data communication to: merchant interfaces remotely located from the refund server, the merchant interfaces being configured to collect data from payments for respective transactions, each payment having a payment identification (ID) associated thereto; a user account database for storing entries of user accounts; a transaction database for storing transaction data, each transaction data being associated with a transaction associated with a payment; and a trust account for accumulating a pool of funds; the instructions stored in the refund computer-readable memory and the instructions stored in the notification computer-readable memory implement the method comprising: generating, by the refund processor, entries of user accounts in the user account database, each entry of a user account comprising an identification of a main user device; for each transaction during a given accumulation period: receiving, at the merchant interface, the payment identification (ID) while performing the transaction; generating, by the associated merchant interface, a unique time stamp based on a specific time of the execution of the transaction; receiving, by the refund server from the associated merchant interface, the transaction data comprising the payment ID, the unique time stamp, a transaction ID, and a number representative of a purchase price; while receiving the transaction data, receiving at the refund server and transmitting to the trust account, a portion of the number representative of the purchase price to accumulate a balance amount in the trust account, the portion of the number representative of the purchase price being less than the purchase price; storing the transaction data in the transaction database with sequenced transactions, the sequenced transactions being ordered according to their respective unique time stamp within the given accumulation period; and selecting a subset of the sequenced transactions and labeling the transactions of the subset of the sequenced transactions as labeled transactions, the subset of the sequenced transactions being selected starting from a first labeled transaction being the most cotemporal to a given time within the given accumulation period based on the unique time stamp of the first labeled transaction, and ending with a cut-off labeled transaction, where a sum of each number representative of the purchase price of the transactions, for the labeled transactions between and including the first labeled transaction and at least a portion of the cut-off labeled transaction, is equal to or more than the balance amount; for each labeled transaction of the subset of the sequenced transactions: determining, by the refund server at the user account database, a labeled user account corresponding to the labeled transaction; generating, by the refund processor, a notification script and transferring the notification script to the notification server, the notification script comprising identification of the labeled user account, an amount of the refund, an address of the notification server, and the identification of the main user device comprising an address of the main user device; executing the notification script by the notification server resulting in sending a prompt to the main user device to approve the refund; in response to an approval of the refund received from the main user device; generating, by the notification processor, a refund script for crediting the user account, the refund script comprising the identification of the user account and an amount of the refund; and receiving and executing the refund script by the refund processor, the refund script having instructions to credit the refund to the user account by transferring the funds from the trust account to the user account.

11. The method of claim 10, wherein executing the notification script by the notification server by sending the prompt to the main user device to approve the refund further comprises: generating and sending, by the notification server, a notification to the main user device, the notification including the amount of the refund to be credited to the labeled user account; and monitoring during a notification period, by the notification server, approval of the refund from the main user device.

12. The method of claim 11, wherein in the absence of the approval of the refund from the main user device during the notification period: generating, by the notification server, a primary expiry script to request an alternative user device ID of an alternative user device, the primary expiry script comprising a main user device ID of the main user device and the address of the notification server; sending the primary expiry script to the refund server; executing the primary expiry script at the refund server to determine an alternative user device; and using the alternative user device instead of the main user device for execution to generate another notification script thereby resulting in sending the notification to the alternative user device for monitoring, by the notification server, during an other notification period.

13. The method of claim 12, wherein the refund server is further linked for data communication to a quarantine account, and further wherein the method further comprises, in the absence of the approval of the refund from the alternative user device during the other notification period, generating, by the notification server, a secondary expiry script for execution by the refund server to transfer the refund to the quarantine account.

14. The method of claim 13, further comprising, after a quarantine period: generating and sending, by the notification server, a quarantine notification to the main user device, the quarantine notification including the amount of the refund to be credited to the labeled user account; and monitoring during a quarantine notification period, by the notification server, approval of the refund from the main user device.

15. The method of claim 14, wherein in the absence of the approval of the refund from the main user device during the quarantine notification period generating, by the notification server, a quarantine expiry script for execution by the refund server to diffuse the refund for alternative uses.

16. The method of claim 10, further comprising: generating, by the notification server, an authentication script to request a login information to the user account; transmitting, from the notification server to the user device, the authentication script to request the login information to the user account; in response to receiving a notification from the main user device that the user clicked on a notification link, displaying a login page and prompting the user to enter an account login ID and password requested from the main user device; requesting, from the main user device, by the notification server, a passcode captured in response to the user entering the passcode at the main user device; verifying, by the refund server, the passcode received from the main user device; and receiving a notification of acceptance of the refund, from the main user device, in response to the user clicking on a refund link.

17. The method of claim 10, wherein: the prompt sent by the notification server further comprises a prompt to identify at least one user-designated account; the instruction received from the main user device further comprising an identification of the at least one user-designated account; the refund script further comprising the identification of the at least one user-designated account; and wherein generating and executing the refund script comprises transferring the funds from the trust account to the at least one user-designated account.

18. The method of claim 10, wherein the user account database comprises entries of the user accounts further comprising addresses to communicate with corresponding main user device and alternative user device associated to a user.

19. The method of claim 10, further comprises selecting the sequenced transactions according to at least one of: a forward time order of the transactions; and a backward time order of the transactions.

20. A method for crediting a refund to a user account of a user, the method executed by: a refund server having a refund processor and a refund computer-readable memory for storing instructions to be executed by the refund processor, and a notification server having a notification processor and a notification computer-readable memory for storing instructions to be executed by the notification server, the notification server being linked for data communication to the refund server; the refund server being linked for data communication to: merchant terminals remotely located from the refund server, the merchant terminals being configured to collect data from payment cards during respective transactions when a payment card is read by one of the merchant terminals, each payment card having a card identification (ID) associated thereto; a user account database for storing entries of user accounts; a transaction database for storing transaction data, each transaction data being associated with a transaction performed between the payment card and one of the merchant terminals; and a trust account for accumulating funds; the instructions stored in the refund computer-readable memory and the instructions stored in the notification computer-readable memory implement the method comprising: generating, by the refund processor, entries of user accounts in the user account database, each entry of a user account comprising an identification of a main user device; for each transaction executed between a payment card and an associated merchant terminal during a given accumulation period: sensing a payment card by the associated merchant terminal to perform the transaction and to receive a card identification (ID); generating, by the associated merchant terminal, a unique time stamp based on a specific time of the execution of the transaction; receiving, by the refund server from the associated merchant terminal, the transaction data comprising the card ID, the unique time stamp, a transaction ID, and a number representative of a purchase price; while receiving the transaction data, receiving at the refund server and transmitting to the trust account, a portion of the number representative of the purchase price to accumulate a balance amount in the trust account, the portion of the number representative of the purchase price being less than the purchase price; storing the transaction data in the transaction database and creating a table of sequenced transactions, the sequenced transactions being ordered based on time; and selecting a subset of the sequenced transactions and labeling the transactions of the subset of the sequenced transactions as labeled transactions, the subset of the sequenced transactions being selected starting from a first labeled transaction being the most cotemporal to a given time within the given accumulation period based on the unique time stamp of the first labeled transaction, and ending with a cut-off labeled transaction, where a sum of each number representative of the purchase price of the transactions, for the labeled transactions between and including the first labeled transaction and at least a portion of the cut-off labeled transaction, is equal to or more than the balance amount; for each labeled transaction of the subset of the sequenced transactions: determining, by the refund server at the user account database, a labeled user account corresponding to the labeled transaction; generating, by the refund processor, a notification script and transferring the notification script to the notification server, the notification script comprising identification of the labeled user account, an amount of the refund, an address of the notification server, and the identification of the main user device comprising an address of the main user device; executing the notification script by the notification server resulting in sending a prompt to the main user device to approve the refund; in response to an approval of the refund received from the main user device: generating, by the notification processor, a refund script for crediting the user account, the refund script comprising the identification of the user account and an amount of the refund; and receiving and executing the refund script by the refund processor, the refund script having instructions to credit the refund to the user account by transferring the funds from the trust account to the user account.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0132] Further features and advantages of the present disclosure will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0133] FIG. 1 is a flowchart diagram showing a process for a merchant's program registration, in accordance with an embodiment;

[0134] FIG. 2 is a flowchart diagram showing a process for a buyer's program registration, in accordance with an embodiment;

[0135] FIG. 3 is a flowchart diagram showing a process for a buyer's deposit of monetary funds in his purchasing account, in accordance with an embodiment;

[0136] FIG. 4 is a flowchart diagram showing a process for a buyer's purchase transaction, in accordance with an embodiment;

[0137] FIG. 5 is a flowchart diagram showing a process for a refund of monetary funds, in accordance with an embodiment;

[0138] FIG. 6 is a block diagram of a purchase refund system, in accordance with an embodiment;

[0139] FIG. 7 is a flow chart of a method of transferring funds data between payment cards, merchant terminals and an operator database, in accordance with an embodiment;

[0140] FIG. 8 is a table of transaction data created in the operator database, in accordance with an embodiment;

[0141] FIG. 9 is a table of sequenced transactions created in the operator database, in accordance with an embodiment;

[0142] FIG. 10 is a table of a subset of the sequenced transactions created in the operator database, in accordance with an embodiment;

[0143] FIG. 11 illustrates a system for refunding funds to a user account, according to at least one embodiment of the present disclosure;

[0144] FIGS. 12A, 12B illustrate a flow chart of a method for refunding funds to a user account, according to at least one embodiment of the present disclosure;

[0145] FIGS. 13A, 13B illustrate another flow chart of the method for refunding funds to a user account, according to at least one embodiment of the present disclosure;

[0146] FIGS. 14A, 14B, 14C illustrate a flow chart of subroutines in the method for refunding funds to a user account, according to at least one embodiment of the present disclosure; and

[0147] FIG. 15 illustrates another flow chart of subroutines in the method for refunding funds to a user account, according to at least one embodiment of the present disclosure.

[0148] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

DETAILED DESCRIPTION

[0149] As mentioned above, many everyday life actions involve the use of user accounts typically embodied as accounts stored in a database on a server. Various websites involve logging in to a user account for performing transactions. Other contexts, such as the use of membership cars, payment cards, credit cards, etc., permit operations (i.e., financial operations or transactions) which involve user accounts. Operations are performed remotely, where the user is not located by the server in which the user account data are stored, nor is he or she located close to the server in which the operations involving the user account are performed (since such a server may be different). More specifically, it is likely that more than one server in view of the popularity of cloud computing, server clusters, data centers and the like. A server can therefore mean (i.e., be the functional equivalent of) a plurality of servers working together.

[0150] As a specific example of uses which involve user accounts and which are not necessarily involving a login to a website, there are incentive programs to buyers and customers (aka purchasers) which exist in the context of performing a buying transaction from merchants/sellers of different commodities and services. Most of them provide points or rewards of different types that are credited to a buyer's or purchaser's account when a purchase is performed from a pool of merchants/sellers of different commodities and services. By way of example, these points and rewards are preset values related to the amount of the purchase and/or are provided by a random process of selection. Such programs typically involve a multiplication of parties which implies that many user accounts and corresponding data base entries, as well as server queries, need to be performed during a transaction and also beyond the transaction.

[0151] For example, the transaction may involve the actual transaction, whether in-store or on the web, where the user gives a payment card, debit card or credit card containing a chip or magnetic band to perform the transaction using the card. In addition to the use of that card for payment, another card can be used for the incentive program for the accumulation of points. It means that the transaction involves, from the point-of-sale (POS) system, a communication of information to the server of the payment card (or equivalent thereof), and an additional communication of information to the server of the incentive program. Each of these two different parties need to maintain their own server, which comprise a respective user account for the same person, and communications (typically bi-directional, as confirmations are needed) need to be made to both servers for a single transaction. After completion of the transaction, the user may even use the points awarded in the incentive program to make purchases of predefined items in participating merchants, where additional accounts need to be made as the managers of the incentive program need to create user accounts on their servers for the merchants (in addition to the customers) to account for the merchandise sold by the merchants to the customers via the incentive program, thereby adding a certain number of user accounts in the database of the servers and also adding a significant number of server operations.

[0152] Some of the technical problems involved in improving such systems are the load on the servers used during a transaction, which can be significant when many transactions are made. Moreover, in view of the remote operations involving user accounts, such as transaction, it is critical to provide timely information concerning specific data of the remote operations, such as credits/refunds to user, determining and selecting to which payment cards used for performing the transactions credits/funds should be attributed, determining the structure of the tables of data to be used and maintaining updated data in the database, distinguishing each transaction (i.e., uniquely identifying each transactions to discriminate them) to be able to perform a selection amongst them, etc. These tasks, which are a technical complexity per se, are also a burden on the servers when a high number of transactions occur.

[0153] The present description proposes a system and method to optimize, and even reduce in comparison with other methods such as the typical incentive programs, the load (processing power, working memory, memory on the servers, database queries and quantity of stored data) on the servers for making remote operations involving user accounts. The example of transactions involving an incentive reward program is giving as a suitable example where the proposed method is manifestly useful.

[0154] Processing such as computing, the execution of operations, queries/requests by the client(s), preparation of responses, responses to queries to the client(s), retrieval of files, queries of database(s), etc., are all considered as a load for the server, which requires an amount of the limited computing processing power and working memory of the server and consumes energy and computing processing power and working memory in a datacenter/farm/cluster of servers which is also limited. Moreover, several of these operations, especially files and data in databases (user account database entries, transaction entries), require an amount of long-term memory which also requires hardware (memory), consumes energy and space as more devices are required.

[0155] From a computer hardware perspective and in view of the significantly high number of remote operations performed using servers nowadays, such operations need to be made in a more optimized manner to ensure that the load on the server is kept at a reasonable level, to allow scaling without having to add several server computers uselessly to perform unoptimized tasks.

[0156] In practice, in addition to the technical advantage (i.e., reducing the load on the server) obtained from the method, the method and system running the method can be used to enhance sales, by providing a full refund or a multiple of the value of a purchase transaction, to eligible buyers/owners from selling accounts, thru the use of a program, which is executed in selected time intervals on a daily basis or otherwise. Alternatively, the program, or algorithm, can be executed in multiples or fractions of an hour during a calendar day within geographical (time) zones on a given territory (e.g., the USA). In other embodiments, it would be applied on a world-wide basis.

[0157] Based on simple market economics, the method is presented in the following paragraphs.

[0158] The market's (economics) simplest theory is the availability of a supply and a demand. The basic interest of any purchaser/buyer is to get benefit of his purchases, whether in the form of monetary funds, goods, commodities, services, bonuses, rewards, cash back, loyalty points, points for air mileage, and points for purchasing gas being common examples of this fact. The basic interest of the merchant/seller is to increase (in quantity and value) his sales and revenues.

[0159] The mediums of credit-debit, online, e-commerce and/or similar payment methods available in the prior art, except cash, charge certain fees, which the buyer ends up paying and, in some applications, getting the benefits of his transaction in the form of rewards, points and few cash-back percentage points applied on a selected pool of merchants/sellers and not on all purchases but on some selected groups, services and/or commodities.

[0160] An objective of this program is to provide the opportunity of a refund that fully covers the value of the purchase price and, in particular embodiments, even refunds that can cover the multiples of the purchase price. The refund objective is in the form of a monetary refund and will encourage the buyer to use this medium more than the presently available refund services as explained above.

[0161] The direct consequence of this advantage, i.e., monetary refund, will enhance the sales at an outlet/merchant/seller/point of sale using this facility, as compared to those who do not provide it. Consequently, the basic theory of supply and demand will be energized.

Application Example

[0162] The following steps form part of an example according to an embodiment: [0163] 1—Provide the monetary refund facility, thru available technology, such as payment cards, online transaction, smart phone transactions, etc. [0164] 2—Register all buyers/owners of purchasing accounts in the system thru and in a purchasing account identification package, which includes as a minimum, name, account number, nationality, date of birth, gender, profession, address, mobile number, email, ID (identification) number, etc. (see FIG. 2). Each buyer has a single user account for the payment and the incentive reward program considered altogether. [0165] 3—Create points of sales, either by using available data initiation terminal/merchant terminal and/or introducing new data initiation terminal/merchant terminal belonging exclusively to this application (see FIG. 1). [0166] 4—Allow buyers/owners of purchasing accounts to deposit monetary funds in their purchasing account (see FIG. 3). [0167] 5—Allow the sales through the data initiation terminal/merchant terminal in point 3 above (see FIG. 4). [0168] 6—Register the details of the purchase, i.e., point of sales, value of purchase, date, time, etc. (see FIG. 4). [0169] 7—Segregate the details of the purchase (see FIG. 4). [0170] 8—Deduct from the purchasing account of the merchant/seller, in monetary form, certain percentage points of the total sales of the purchase transaction, and deposit the total accumulations of such monetary values of the certain percentage points in a pool of funds (TRUST) (see FIG. 5). [0171] 9—Split monetary purchase value of the purchase transaction into merchant's/seller's monetary earnings and the monetary value of the certain percentage points. Transfer merchant's/seller's monetary earnings into his selling account; and deposit the monetary value of the certain percentage points (the fees) in a separate account for the pool of funds (TRUST) belonging to the system operator/developer (see FIG. 5).

Monetary Refund Mechanism:

[0172] According to an embodiment, the refund to eligible purchasers/buyers/purchasing account holders is deposited in the purchasing account of the owner thereof from the monetary funds of given accumulation periods and deposited in the pool of funds (TRUST) is performed as described in the following paragraphs.

[0173] The individual refund monetary value of eligible buyers will come from the BALANCE which is defined as being the difference between total deposits (TRUST) and the costs (COST):

[00001]$\mathrm{BALANCE}=\mathrm{TRUST}-\mathrm{COST}.$

[0174] The costs include, but are not limited to, operational and management costs, legal expenses like taxes or otherwise, reasonably legal profits and alike. The costs are paid to the operator/developer of the system.

[0175] Consequently, the objective of this scheme is to refund the BALANCE to the eligible buyers/purchasing account holders.

[0176] The diffusion/attribution will be performed based on time intervals (aka given accumulation period), which can be multiples or fractions of hours, during one calendar day or otherwise. Such criteria can be reconsidered from time to time. Alternatively, the program, or algorithm, can be executed in multiples or fractions of an hour during a calendar day or otherwise within geographical (time) zones on a given territory (e.g., the USA). In other embodiments, it would be applied on a world-wide basis.

[0177] According to an embodiment, eligible refund buyers will be the buyers of the first refund time or second refund time of a given refund time in the forward and backward time order according to the relevant time stamp or similar and/or other similar algorithms of similar or distinct time intervals or other applications.

[0178] According to an embodiment, refund policy can be subject to change based on holiday period, occasion, and promotional packages.

[0179] According to an embodiment, the total diffusion/attribution/refund of each time interval will be made to the number of eligible buyers/purchasing account holders such that the BALANCE in the given refund time interval is zeroed; i.e., if the balance is x dollars and the number of eligible buyers to a refund, or other algorithms, is such that the x dollars is completely diffused as full refund of the transactions, then the total number of the eligible buyers to a refund, or other algorithms, are identified, and accordingly the total number of eligible buyers can be any number such that this number exhausts/diffuses the BALANCE available of the given refund time interval.

[0180] The attribution of funds to purchasing account holders is illustrated by the following particular example of the eligible buyers to a refund. If the balance contains $1,000, such balance will be diffused equally between the eligible buyers of the forward time order and the backward time order of a given refund time to a refund associated to a time stamp, 50/50, i.e., $500 to the eligible buyers of the forward time order of a given refund time and $500 to the eligible buyers of the backward time order of a given refund time, such that the first $500 will be diffused to any number of eligible buyers of the forward time order until the first $500 is zeroed, and the second $500 will be diffused to any number of eligible buyers of the backward time order until the $500 is zeroed for the selected given refund time of the interval of time associated to time stamps applicable to this algorithm.

[0181] According to an embodiment, the daily transactions information (or at another frequency established by the operator) will be available to the public on a daily basis or otherwise and accessible to everyone thru a dedicated website, social media sites, mobile applications and the like. The transactions information will provide total number and value of purchases showing the progress of accumulation of the BALANCE available for diffusion for each time interval.

[0182] According to an embodiment, eligible buyers will be notified of their winnings thru a dedicated website, social media sites, mobile applications, text messages, emails and/or the like upon the completion of the eligibility process. The eligible buyers will be credited the full value of their refunds in their purchasing accounts within the program.

[0183] According to an embodiment, the list of actual eligible buyers for each time interval thru any algorithm will be made available thru a dedicated website. The daily transactions information will be available to the public on a daily basis or otherwise, accessible to all thru a dedicated website, social medias, mobile applications and the like. The transaction information will provide total number and value of purchases showing the BALANCE available for diffusion of each time interval.

[0184] Now referring to FIG. 1, there is described a process 100 for a merchant's program registration, in accordance with an embodiment. The process 100 comprises the steps of: Registration of the merchant in the program (step 102); Storage of merchant information (step 104); Issue of machines for accepting buyer's payment card (step 106); and Installation of machines at point of sales/data initiation terminal (step 108). Alternatively, machines already in place can be used to accept buyer's payment card.

[0185] Now referring to FIG. 2, there is described a process 200 for a buyer's program registration, in accordance with an embodiment. The process 200 comprises the steps of: Registration of buyer in the program (step 202); Storage of buyer information (step 204); Issue of payment card to buyer (step 206); and Receipt of payment card (step 208).

[0186] Now referring to FIG. 3, there is described a process 300 for a buyer's deposit of monetary funds in his purchasing account, in accordance with an embodiment. The process 300 comprises the steps of: Deposit of funds by buyer (step 302); Increase of monetary funds in purchasing account (step 304); Sending of deposit's detail (step 306); and Receipt of notification (SMS) about deposit details (step 308).

[0187] Now referring to FIG. 4, there is described a process 400 for a buyer's purchase transaction, in accordance with an embodiment. The process 400 comprises the steps of: Usage of payment card for purchase (step 402); Sending of buyer information (step 404); Verifying buyer's available funds (step 406); Sending of transaction's approval or rejection (step 408); Display and printing of transaction confirmation (step 410); Receipt of notification (SMS) about transaction details (step 412); Confirmation of the approval of the transaction (step 414); Storage of transaction details (step 416); Deduct transaction value from buyer's purchasing account (step 418); Increase Merchant's selling account with transaction value less fees (step 420); Deposit fees monetary value in the operator's/developer's account/pool of funds/TRUST (step 422).

[0188] Now referring to FIG. 5, there is described a process 500 for a refund of monetary funds, in accordance with an embodiment. The process 500 comprises the steps of: Ending of fees collection process of given refund time intervals and deposit in the TRUST (step 502); Deduction of COSTS from the TRUST and credit the COSTS to the developer's/operator's account such that TRUST−COST=BALANCE (step 504). The BALANCE is identified as the monetary funds ready to be diffused as refunds to eligible buyers; Execution of algorithm for selection of eligible buyers (step 506); Diffusion of BALANCE into eligible buyers purchasing account (step 508); Notifying eligible buyers of their monetary refund (step 510); Receipt of notification (SMS) about monetary refund (step 512); and Publishing on website of time interval's transactions list and diffusion details of monetary refunds (step 514).

[0189] Now referring to FIG. 6, there is described a purchase refund system 600, in accordance with an embodiment. The system 600 comprises a programmer/operator secure network 602 which provides secure communications between: [0190] 1—the buyers and merchant's registration office 604; [0191] 2—the seller's/merchant's point of sales (merchant terminal 612); [0192] 3—the developer's/operator's data and processing server 610; [0193] 4—the developer's/operator's notification server 608; and [0194] 5—the developer's/operator's web server 606 (also referred to herein as “operator web server 606”).

[0195] The developer's/operator's notification server 608 and the developer's/operator's web server 606 in turn communicate, thru public networks 614 (such as the internet and telecom networks), with buyer's smart phones 616 and buyer's web access 618 (e.g., web-enabled computing devices).

[0196] According to an embodiment, the information which is exchanged within system 600 comprises: [0197] 1—registration of information concerning merchants and buyers/purchasers 620; [0198] 2—purchase transaction details 622; [0199] 3—notifications to buyers concerning deposit of funds; [0200] 4—transaction approvals/rejections; [0201] 5—refund of transactions 624; and [0202] 6—Web publication of transaction lists and refunds diffusion/attribution details 626.

[0203] The operator data and processing server 610 is for providing a refund to an eligible purchasing account, in which monetary funds are held, for a purchase made at a purchase price at a specific time to which is associated a time stamp. The operator data and processing server 610 comprises: a memory (not shown) for storing data and instructions; and a processor (not shown) in communication with the memory. The processor is for executing the instructions. The instructions comprise the steps of: receiving a portion of the purchase price in a pool of funds, defined as a trust; and determining the refund to be transferred from the trust to the eligible purchasing account based on the time stamp, the refund covering at least a part of or, on given occasions, a multiple of the purchase price. According to separate and distinct embodiments, the instructions also include the other steps, in combination or individually, of the method for providing a refund described herein.

[0204] The Following Paragraphs List Advantages of the Presently Described System and Method: [0205] 1—All payment cards, which provide rewards like loyalty points and cashbacks, do not refund the full monetary value and the possibility of the multiples of the value of a purchase transaction. The scheme described herein does provide such a refund. [0206] 2—The scheme described herein provides the refund of the full monetary value of a purchase transaction and, in given occasions, opportunities of multiples of the full monetary value of a transaction. [0207] 3—The refund of the scheme described herein can be used in the acquisition of ANY consumer commodity from ANY supplier within the refund limit, unconditionally, without restrictions on using the refund at the same merchant terminal where the purchase eligible for refund was made. [0208] 4—The process is a straightforward user-friendly program. [0209] 5—The selection of eligible buyers can be made based on a simple algorithm or randomly. [0210] 6—The scheme described herein does not limit the value of a particular purchase transaction, as such a purchase transaction can be refunded from the available funds in the BALANCE corresponding to the given refund time, when the particular transaction is performed in the event that the available funds in the balance are at least sufficient to refund the value of the particular purchase transaction and, if not, a part of the transaction such that the BALANCE is zeroed and/or diffused in full. [0211] 7—The scheme described herein is applicable with all merchants/sellers and the rewards are paid from the BALANCE and not from the particular merchants/sellers. [0212] 8—The scheme described herein is a continuous process. [0213] 9—The permutation of the scheme described herein is performed on the basis of complete hours or fraction of these hours or otherwise. [0214] 10—The scheme described herein displays, on the web, the progress of the BALANCE collected for diffusion of refund and the progress of diffusion. [0215] 11—The scheme described herein displays the number of eligible buyers and the respective refunds of every eligible buyer for a given refund time. [0216] 12—The scheme described herein can accommodate virtual accounts, which can be linked to an existing purchasing account, to allow the buyer to participate in the program. [0217] 13—The scheme described herein can accommodate all forms of payments, such as, for example, payment cards, wire transfers, online payments, check deposits, etc. [0218] 14—The scheme described herein can be versatile and used for detailed data collection for various applications and promotions of different merchants/sellers of the components of the detailed collected data. [0219] 15—The scheme described herein can create point of sales, either by using available data initiation terminal/merchant terminal and/or introducing new data initiation terminal/merchant terminal belonging exclusively to this application. [0220] 16-Regardless of the credit standing of the buyer, a person is an eligible buyer since he is depositing funds (monetary funds) in his purchasing account. [0221] 17—The scheme described herein is versatile and enables the launching of particular rewards on a time-to-time basis and particular occasions. For example, the accumulation of a certain portion of the BALANCE to release it in a one-shot or surprise refund on a given occasion like Valentine's Day. [0222] 18—The scheme described herein is applicable to all kinds of consumer commodities. [0223] 19—The scheme described herein can be elaborated to monitor the consumption of different consumer commodities. The information can then be communicated/transmitted back officially to interested parties with the objective of enhancing the interest of all related parties.

[0224] Now turning to FIG. 7, a method 700 for automatically and/or systematically transferring, storing and exchanging funds data between payment cards, merchant terminals and an operator database according to an embodiment is disclosed. It should be noted that the funds data concern transactions performed using the payment cards and that each one of the payment cards has associated thereto a card ID (identification), a payment card account and an amount of funds available for performing transactions.

[0225] The method 700 is implemented on an operator data and processing server (see FIG. 6) which performs the steps detailed below.

[0226] In step 702, a table of transaction data is created in the operator database. The transaction data results from the use of a plurality of the payment cards at at least one of the merchant terminals which generates the transaction data. The transaction data includes, for each use, a transaction ID (identification), the respective card ID, a number representative of the value of the transaction and a unique time stamp representative of a specific time at which the use took place. According to an embodiment, the use takes place within a given accumulation period which comprises multiples or fractions of hours during one calendar day. In this example of the table of transaction data, the transaction ID is the unique key that is used to ensure each transaction is uniquely identified.

[0227] In at least one embodiment, the transaction data is generated as a result of (in response to) reading of the data of the payment card by the merchant terminal. Such reading of the payment card 605 may be executed by various technologies, such as, for example, by radio-frequency identification (RFID) or near-field communication (NFC) technology. The unique time stamp is generated at the exact moment of reading of the data from the payment card. The merchant terminal 612 comprises a merchant terminal processor and an input element, such as, for example, a merchant terminal keyboard, a merchant terminal display, and/or a merchant terminal touchscreen.

[0228] Alternatively, the transaction data 1132 (FIG. 11) may be generated at the merchant terminal 612 as a result of (in other words, in response to) receiving an input of the payment card number at the merchant terminal 612. The unique time stamp, which becomes part of the transaction data, may be generated by a merchant terminal processor of the merchant terminal 612 at the moment when the merchant terminal 612 receives the number of the payment card (for example, right after the “OK” button of the terminal is pressed on a keyboard or on a touchscreen of the merchant terminal 612). The transaction data 1132 is then transmitted to the refund processor 1110 of the refund server 610. It should be noted that the merchant terminal 612 can be a physical device in certain embodiments while in other embodiment (e.g., for online transactions), it can be referred to as a merchant interface.

[0229] According to an embodiment, the details of the purchased item and associated data form part of the transaction data stored in the operator database.

[0230] In step 704, trust numbers are calculated by applying a percentage that is less than 100% to each number representative of the value of the transaction.

[0231] In step 706, all the trust numbers within the given accumulation period are summed thereby defining a trust account amount.

[0232] In step 708, a balance amount is calculated by applying a percentage that less than 100% to the trust account amount.

[0233] In step 710, a table of sequenced transactions by transaction ID is created in the operator database. The sequenced transactions are ordered according to their respective unique time stamp within the given accumulation period. As for the table of transaction data, the unique key for the table of sequenced transactions is the transaction ID according to an embodiment.

[0234] In step 712, a subset of the sequenced transactions is selected. The subset is selected starting from a first transaction in the sequenced transactions, the first transaction being the most cotemporal to the given time, and ending with a cut-off transaction which is the transaction where the sum of all the numbers representative of the value of transactions, for the transactions between and including the first and at least a portion of the cut-off transaction, is equal to or more than the balance amount.

[0235] In step 714, a table of the subset of the sequenced transactions is created in the operator database. The table of the subset of the sequenced transactions comprises the transaction IDs and the corresponding number representative of the value of transactions for each transaction of the subset of the sequenced transactions. As for the table of transaction data, the unique key for the table of the subset of the sequenced transactions is the transaction ID according to an embodiment.

[0236] In step 716, the corresponding numbers representative of the value of the transaction are respectively added to the amount of funds associated to the payment cards which correspond to the transactions in the subset of the sequenced transactions within the given accumulation period.

[0237] According to an embodiment, the steps of selecting a subset of the sequenced transactions (step 712), creating a table of the subset of the sequenced transactions in the operator database (step 714) and respectively adding each corresponding number representative of the value of the transaction to the amount of funds associated to the payment cards which correspond to the transactions in the subset of the sequenced transactions (step 716) are performed after the given accumulation period.

[0238] According to an embodiment, the steps which are performed after the given accumulation period (e.g., step 712, 714 and 716) are performed in less than 5 minutes. According to an embodiment, the steps which are performed after the given accumulation period (e.g., step 712, 714 and 716) are performed in less than 1 minute. According to an embodiment, the steps which are performed after the given accumulation period (e.g., step 712, 714 and 716) are performed in less than 10 seconds. According to an embodiment, the steps which are performed after the given accumulation period (e.g., step 712, 714 and 716) are performed in less than 1 second. According to an embodiment all steps of the method performed after the given accumulation period are performed according to the periods set out above. According to an embodiment all steps of the method are performed according to the periods set out above.

[0239] According to an embodiment, the number of transactions involved in the steps of the method within a given accumulation period is more than 3,600. According to an embodiment, the number of transactions involved in the steps of the method within a given accumulation period is more than 10,000. According to an embodiment, the number of transactions involved in the steps of the method within a given accumulation period is more than 100,000. According to an embodiment, the number of transactions involved in the steps of the method within a given accumulation period is more than 1,000,000. The number of transactions being potentially very high, it is technically advantageous, in terms of server usage and optimization of the usage, to ensure that transactions entries have the double effect of performing not only the financial transaction itself, but also providing the eligibility to the incentive reward program, at the same time (i.e., the payment in itself, alone, provides both effects). Each financial transaction also acts as a contribution to the reward program (i.e., the portion of the amount transferred to the fund).

[0240] According to an embodiment, the rate of transactions involved in the steps of the method is more than 1 per second. According to an embodiment, the rate of transactions involved in the steps of the method is more than 10 per second. According to an embodiment, the rate of transactions involved in the steps of the method is more than 100 per second. According to an embodiment, the rate of transactions involved in the steps of the method is more than 1,000 per second.

[0241] According to an embodiment, the foregoing steps performed by the operator data and processing server are performed without human intervention. By performing the steps disclosed herein, the operator data and processing server becomes a special purpose server; i.e., one performing functions which no other server has performed before. The operator data and processing server is therefore essential to the method described herein.

[0242] According to an embodiment, the performance of the method by the operator data and processing server covers a particular application of the addition of the value of a transaction to the amount of funds associated to the payment cards which correspond to the transactions in the subset of the sequenced transactions. According to another embodiment, the performance of the method by the operator data and processing server covers a particular application of a method of processing a refund.

[0243] Furthermore, because of time constraints and the number of operations involved in performing the method for a high volume of transactions, it would neither be useful nor practical to perform steps by a person or a team of persons however large the team would be. The shear coordination problem related to updating the tables of data, calculating, summing and updating the amount of funds associated to the payment cards would render the task impossible.

[0244] According to an embodiment, the selecting of the subset comprises selecting sequenced transactions according to at least one of: a forward time order of the purchases; and a backward time order of the purchases.

[0245] According to an embodiment, the given time comprises a first time and a second time, wherein a first portion of the balance amount is attributed to a period starting from the first time and a second portion of the balance is attributed to a period starting from the second time.

[0246] According to an embodiment, a first portion of the balance is used in the adding step from the first time according to a forward time order and a second portion of the balance is used in the adding step from the second time according to a backward time order.

[0247] According to an embodiment, the first time corresponds to a beginning of the given accumulation period and the second time corresponds to an end of the given accumulation period.

[0248] According to an embodiment, the first portion of the balance amount and the second portion of the balance amount are equal.

[0249] According to an embodiment, the method further comprises remotely accessing, for each one of the payment cards, the payment card account for recording and validating the amount of funds available for performing transactions.

[0250] According to an embodiment, the method further comprises adding the trust account amount of each accumulation period to a trust account. The trust account is separate and distinct from the payment card account and is inaccessible by a user having access to the payment card account.

[0251] According to an embodiment, the method further comprises, before adding the corresponding numbers representative of the value of the transaction to the amount of funds associated to the payment cards, identifying, based on the transaction ID key in the table of transaction data, the respective card IDs and the associated amount of funds available for performing transactions.

[0252] According to an embodiment, the method further comprises receiving from a plurality of the merchant terminals the transaction data over a secure communication network.

[0253] According to an embodiment, the method further comprises associating the respective card IDs to respective users having previously associated an address of a computing device to the respective user and sending a notification to the computing devices advising the respective users that the adding the corresponding numbers representative of the value of the transaction to the amount of funds associated to the payment cards took place.

[0254] According to an embodiment, the given accumulation period comprises multiples or fractions of hours during one calendar day.

[0255] Now turning to FIGS. 8, 9 and 10, a transaction data table 800, sequenced transactions table 900 and a subset of the sequenced transactions table 1000 are respectively shown. According to an embodiment, the foregoing tables are created in the operator database (not shown) which is part of, or at least in communication with, the operator data and processing server (see FIG. 6).

[0256] According to an embodiment, the transaction data table 800, sequenced transactions table 900 and a subset of the sequenced transactions table 1000 all have the same columns: Transaction ID column 802, Time Stamp column 804, Card ID column 806, Number (value) column 808 (e.g., dollars), Accumulation Period column 810 (e.g., one-hour periods) and Date column 812 (e.g., yyyymmdd).

[0257] As stated earlier the transaction data table 800 results from the use of a plurality of the payment cards at at least one of the merchant terminals which generates the transaction data. In this example, the transactions are in no particular order. Transaction ID 1 and 3 are performed using the same Card ID (X123) within two distinct Accumulation Periods on the same Date and at distinct and/or at the same merchant terminals.

[0258] The sequenced transactions table 900 shows that the transactions are reordered (i.e., sequenced) according to their respective time stamp within a given accumulation period. Accordingly, the date of the transactions is also used when reordering the transactions. In this example, all transactions are performed on the same date. This example now shows that the transaction sequence with a given accumulation period (e.g., 0800 to 0900 which represents 8 am to 9 pm on May 1, 2015) is 1, 2, 4, 7, 5, 6. Transaction 3 is not in the list since it occurs in a different given accumulation period.

[0259] The subset of the sequenced transactions table 1000 shows that only three transactions (7, 4 and 2) remain. In this example, the given time is 0815 and the balance amount is calculated to be 4,912.74 in view of all the transactions made during the accumulation period. This exemplary balance amount (4,912.74) is obtained from the trust which is generated by applying a certain percentage, say 4%, on a hypothetical value of 205,072.50 being the sum of the value of transactions within a given accumulation period (i.e., the sum of all the numbers representative of the value of the transactions within a given accumulation period) yielding a value of the trust equal to 8,202.90 to which another percentage is applied, in this case 60%, to generate the balance which in this case becomes 4,921.74.

[0260] The transactions are first reordered (re-sequenced) starting with the transaction ID which is most cotemporal to the given time. In this case, transaction ID 7 is the most cotemporal to 0815. The next is transaction ID 4 and then transaction ID 2. The next one would have been transaction ID 1 which took place 2 ms before transaction ID 2 and therefore is less cotemporal to 0815. The cut-off transaction is identified in this example as being transaction ID 2 since it is the transaction where the sum of all the numbers representative of the value of transactions, for the transactions between and including the first and at least a portion of the cut-off transaction (i.e., 613.98+25.76+12,244.02=12,883.76), is equal to or more than the balance amount (i.e., 4,912.74).

[0261] According to other embodiments, supplementary criteria are added to reorder the transactions. The supplementary criteria could be to limit the reordered transactions to those which are after the given time or, alternatively, to those which precede the given time.

[0262] This example further shows that the value of the transaction which are respectively added to the amount of funds associated to the payment cards which correspond to the transactions in the subset of the sequenced transactions are as follows: “613.98” is added to the amount of funds in the account associated with payment card Z730; “25.76” is added to the amount of funds in the account associated with payment card Z224; and “4,273.00” is added to the amount of funds in the account associated with payment card X159. In this example, 4,273.00 is the amount which remains from the balance amount once the first two additions to the amounts of funds in the accounts associated with payment cards Z730 and Z224 are performed (i.e., 4,912.74−613.98−25.76=4,273.00). Therefore, for the cut-off transaction, 7,971.02 of the 12,244.02 will remain unpaid. According to another embodiment, the system operator could decide to fully refund the entirety of the cut-off transaction or, to the contrary, not reimburse the cut-off transaction since it cannot be fully refunded.

[0263] Now referring back to the initial goal of the method, it can be appreciated that the method described above involves far less server operations, and therefore optimizes the load on the server, in comparison with other methods of associating an incentive program account with a specific transaction. The payment acts, alone and only by itself, as an action both performing a financial transaction and providing eligibility to the incentive reward program. Database table entries for both the user accounts and the for the financial transactions are reduced by two, compared to a typical situation where the reward card is distinct and separate from the payment card, reducing server usage.

[0264] Considering that the number of transactions can be significantly high, the method described above involves a smaller number of parties, by eliminating the need for all servers managed by an incentive program provider. The user account first created for the payment card is the same (no redundancy) as the user account for the incentive program provider since, in the present invention, there is no distinct incentive program provider in addition to the payment card provider. This means that from a user perspective, less operations need to be made. From a manager perspective, the same is true. Finally, it is clear that there are less databases required since the number of user accounts and the required memory is approximately cut in half.

[0265] Moreover, as mentioned above, during a typical transaction involving an incentive program, there are remote communications with the servers of both parties (both providers). In the present case, there is a single provider, with a single communication required from the point-of-sale system. Communications are reduced. It means that server queries, the computing processing resources for preparing a response, and the response from the server to the client are in reduced number (divided by two).

[0266] Moreover, since the refund of the incentive program is in the same currency as the financial transactions, there is no need for a catalogue where the incentive points would be used, and also no need for maintaining user accounts of the incentive program provider for the merchants offering merchandise for purchase in such a catalogue. Therefore, there is no need for a database comprising product data, and no need for a database comprising data on the merchants and data on the business performed within the catalogue of the incentive provider, thereby saving memory for such unneeded databases and also saving on the server operations that are not performed when compared to traditional incentive program providers.

[0267] From a modern perspective where server computer processing power and memory are often shared over multiple servers (cloud computing, servers, data centers, etc.), the reduction of operations and the reduction of required memory lower (i.e., optimized) the load on the servers for running the method when a great number of transactions are made. The remote operations therefore have a reduce load on the servers (or on the single server if there is only one).

[0268] Referring now to FIG. 11, shown therein is a block diagram showing the system 1100 for refunding funds to a user account, according to at least one embodiment of the present disclosure. The refund server 610 comprises a refund processor 1110 and a refund computer-readable memory 1112 of the refund server for storing instructions to be executed by the refund processor 1110. The refund server 610 also comprises or is linked for data communication to a user account database 1120 and the trust account 1130. The user account database entries described above of the user account data are stored in a user account database 1120. The pool of funds is accumulated in the trust account 1130.

[0269] The refund server 610 is linked for data communication to merchant terminals 612 which are remotely located from the refund server 610. The merchant terminals 612 are configured to collect data from payment cards 605 during each transaction when one payment card 605 is read by one of the merchant terminals 612, each payment card 605 having a card identification (ID) associated to the payment card 605.

[0270] The transaction data described above is stored in a transaction database 1115. The transaction database 1115 may be located in the refund server 610 or, alternatively, the transaction database 1115 may be located remotely from the refund server 610 and communicate with the refund server 610 via the network 614. As described above, each transaction data is associated with each transaction performed between the payment card 605 and a merchant terminal 612.

[0271] The system 1100 also comprises a notification server 608, linked for data communication to the refund server 610. The notification server 608 comprises a notification processor 1162 and a notification computer-readable memory 1164.

[0272] The system 1100 may also comprise the operator web server 606. The operator web server 606 comprises a web server processor 1172 and a web server computer-readable memory 1174.

[0273] The refund server 610 may communicate with the notification server 608, the operator web server 606 via the public networks 614. The merchant terminals 612 communicate with the refund server 610, and in particular with the refund processor 1110, via the public networks 614.

[0274] FIGS. 12A-12B illustrate the method 1200 for refunding funds to a user account, in accordance with the embodiments of the present disclosure.

[0275] FIGS. 13A-13B illustrate a flow diagram of the method 1200 for refunding funds to a user account, in accordance with the embodiments of the present disclosure. The method 1200 is described herein with reference to FIGS. 11, 12A, 12B, 13A,13B.

[0276] At step 1302, the refund processor 1110 generates entries of user accounts in the user account database 1120. Each one of the user accounts in the user account database 1120 is associated to one payment card 605 of the user. Each entry of the user account comprises an amount of funds available for performing transactions. Each one of the payment accounts is associated with a main user device 616a.

[0277] In the user account database 1120, each entry of the user account comprises an identification of a main user device 616a. The information about this main user device 616a may comprise at least one of an Internet Protocol (IP) address of the main user device 616a. For example, the entry of the user account may also comprise a cellular phone number related to the main user device. In addition to the main device 616a, each one of the user accounts may be associated with one alternative user device 616b. Each one of the user accounts may be also associated with one second alternative user device 616c. Accordingly, the entry of the user account may comprise an identification of an alternative user device and, in some embodiments, an identification of a second alternative user device 616c.

[0278] To perform a transaction, a user swipes the payment card 605 at the merchant terminal 612. In other words, the transaction is executed between a payment card 605 and an associated merchant terminal 612. Such transaction may be executed when a user buys an item at an entity (such as, for example, a boutique) and then pays for that item with the payment card 605. There may be many merchant terminals, and many transactions may be executed during a given accumulation period. As illustrated in FIG. 12A, during the given accumulation period, transactions 1 . . . Nt may be performed, where Nt is an integer.

[0279] At step 1304 of the method, when performing the transaction, the associated merchant terminal 612 senses the payment card 605 to receive a card identification (ID). Sensing the payment card 605 may be during the scanning the payment card 605. The merchant terminal 612 then generates a unique time stamp based on a specific time of the execution of the transaction. The merchant terminal 612 thus collects the transaction data 1212 during each transaction and then transmits the transaction data 1212 to the refund server 610. the transaction data 1212 is then transmitted to the refund processor 1110 of the refund server 610. During the given accumulation period, which may be determined by an operator and/or described above, the refund processor 1110 receives the transaction data from various merchant terminals 612.

[0280] The transaction data comprises the card ID, the unique time stamp generated by the merchant terminal and representative of a specific time at which the transaction took place, a transaction ID generated by the merchant terminal, and a number representative of the purchase price for the transaction. In some, examples, the card ID may be received during scanning of a code.

[0281] In an alternative embodiment, for some or all transactions executed during the given accumulation period, the card ID may be collected by the merchant terminal 612 when the user or a merchant enters the card ID in a respective box of the prompt at the merchant terminal 612. In such embodiments, the merchant terminal 612 may be a computer device and the user may make a purchase on that computer device, and the merchant terminal 612 receives an input of the card ID and generates the time stamp at the moment of receiving the input with the card ID at step 1306. At step 1308, the transaction data 1212 is received by the refund server 610.

[0282] According to an embodiment, each merchant terminal 612 has a transmitter (not shown) and a receiver (not shown) to collect an information signal when scanning the payment card 605. The transaction performed within the given accumulation period between the payment card 605 and the merchant terminal 612 (when the user uses the payment card 605 to purchase an item) comprises scanning, by the merchant terminal 612, the payment card 605 by transmitting a requesting signal towards the payment card 605 and receiving an information signal by the merchant terminal 612, wherein the information signal received from the payment card 605 during the transaction comprises the card ID.

[0283] According to a further embodiment, the merchant terminal 612 determines the unique time stamp of the transaction based on the time of receiving of the information signal from the payment card when the payment card 605 is located in proximity of the merchant terminal 612.

[0284] According to yet another embodiment, the merchant terminal 612 determines the unique time stamp of the transaction based at the time of clicking or pushing of a submit button in response to a prompt to enter the payment card ID on the merchant terminal 612.

[0285] At step 1308, simultaneously with receiving the transaction data 1212 by the refund server, a portion of the number representative of the purchase price (the purchase price being a part of the transaction data 1212) is received and then transmitted to the trust account 1130 to accumulate a balance amount of the trust account 1130. The portion of the number representative of the purchase price is also referred to herein and schematically illustrated in FIG. 12A as a “portion of the purchase price 1213”. The portion of the purchase price 1213 is less than the purchase price, as described above.

[0286] The transaction data is then stored in the transaction database 1115 with other transaction entries at step 1312. The transaction entries are organized in the transaction database 1115 as sequenced transactions—as described above and as illustrated, for example, in FIG. 8. As described above, the sequenced transactions in the transaction database 1115 are ordered based on time. For each transaction executed during the given accumulation period, the transaction data 1212 is thus received and stored in the transaction database 1115, as illustrated in FIG. 12A.

[0287] After the given accumulation period has been expired, at step 1214 (FIG. 12A), the refund processor 1110 selects a subset of the sequenced transactions (step 1216) in the transaction database 1115, from all the transactions executed during the given accumulation period. A given refund time is then determined as described above.

[0288] The refund processor 1110 then, at step 1218, labels the transactions of the subset of the sequenced transactions 1220 as labeled transactions. Such subset of the sequenced transactions for labeling is selected starting with a first labeled transaction, which is the most cotemporal to the given time based on the unique time stamp of the first labeled transaction. The subset of the sequenced transactions ends with a cut-off labeled transaction, where a sum of each number representative of the value of the transactions, for the labeled transactions between and including the first labeled transaction and at least a portion of the cut-off labeled transaction, is equal to or more than the balance amount.

[0289] Thus, the refund processor 1110 labels several accounts—also referred to herein as “labeled accounts”—which are stored in the user account database 1120 and which correspond to the subset of the sequenced transactions 1220. In other words, based on the subset of the sequenced transactions 1220 determined earlier, the refund processor 1110 determines a subset of labeled user accounts 1222 of the user account database 1120. Each labeled account of the labeled user accounts 1222 corresponds to at least one labeled transaction. A transitional step 1290 in FIGS. 12A and 12B illustrates how the flow chart of the method 1200 continues from FIG. 12A to FIG. 12B.

[0290] Referring to FIG. 12B, where the step 1218 is illustrated in further details, for each transaction that has a time stamp that is cotemporal with the given refund time, or later than the given refund time, and while the amount in the trust account 1130 is more than 0, the refund server 610 labels the transactions to get labeled transactions, and the corresponding user account as the labeled user account. The label may be added by the refund server 610 to the account database entry corresponding to the labeled transaction.

[0291] Now referring to FIG. 11 and FIG. 12B, after the refund processor 1110 has determined the labeled the user account, the refund processor 1110 generates a corresponding notification script 1142 at step 1240 and transfers, at step 1241 (FIG. 14A), the notification script 1142 to the notification server 608 (in some embodiments, via the network 614).

[0292] The notification script 1142 comprises identification of the user account, amount of the refund, the address of the notification server, and the identification of the main user device 616a. The identification of the main user device 616a may comprise at least one of an Internet Protocol (IP) address of the main user device and a cellular phone number related to the main user device.

[0293] In some embodiments, the notification scripts 1142 for all or several labeled accounts are generated and transmitted to the notification server 608. The notification server 608 has a notification processor 1162 and a notification computer-readable memory 1164 for instructions to be executed by the notification processor 1162. The notification script 1142 is a computer script and is configured to be executed by the notification server 608. In addition to data specified above, the notification script 1142 comprises instructions to communicate and to maintain communication with main user device 616a, or other user device 616b, 616c.

[0294] Upon receipt of the notification script 1142, the notification server 608 executes the notification script 1142 by the notification server 608, at step 1242, by sending a prompt to the main user device 616a to approve the refund. At step 1344, in response to receiving the instructions from the main user device 616a, the instructions comprising an approval of the refund, the notification processor 1162 generates a refund script for crediting the user account, the refund script 1144 comprising the identification of the user account and an amount of refund.

[0295] The refund script 1144 is then received and executed by the refund processor 1110 at step 1346. The refund script 1144 is executed based on the instructions in that refund script 1144 to credit the refund to the user account by transferring the funds of the refund from the trust account 1130 to the user account by increasing, by the amount of the refund, the amount of funds available in the user account, and reducing the trust account 1130 by the funds for a next accumulation period. At step 1348, the execution of the refund script 1144 is confirmed and the new amount of funds available in the user account is forwarded to the refund server 610. Reference numbers 1391 and 1392 are provided in FIGS. 13A and 13B to illustrate continuation between these flow charts.

[0296] The steps 1218, 1240, 1242, 1344, 1346, 1348 described above are executed for each labeled transaction of the subset of the sequenced transactions, and therefore for each labeled user account.

[0297] In some embodiments, the user account, to which the refund is transferred, is the labeled user account, from which the items were paid during the transaction or after the transaction.

[0298] FIG. 14A is a flowchart illustrating steps 1240, 1241, 1242 of the method, in accordance with at least one embodiment of the present disclosure. In some embodiments, when executing the notification script by the notification server 608 by sending, to the main user device 616a, a prompt to approve the refund further comprises, the notification server 608 generates and sends a notification to the main user device 616a. Such a notification may also include the amount of the refund to be credited to the user account, along with the prompt to approve the refund. At step 1452, the notification server 608 monitors, during a notification period, the instructions received from the main user device 616a which corresponds to (is associated with) the labeled user account. The notification period may be pre-determined and may be, for example, 30 minutes, one day, or another period.

[0299] At step 1454, the main user device 616a generates and pushes an acceptance message to the notification server, the acceptance message (instructions) comprising the main user device ID/address previously identified by the user, the address of the notification server, the confirmation of acceptance of the refund

[0300] At step 1456, if, before the end of a notification period, the notification server 608 receives instructions from the main user device 616a, the instructions comprising a user account ID and an approval of the refund, continue to next step. If not, following the step 1501 (FIG. 15), at step 1503, the notification server 608 generates a primary expiry script to request an alternative user device ID or an address of an alternative user device, the primary expiry script comprising the main device ID (which may include, for example, address) previously identified by the user and the address of the notification server 608.

[0301] At step 1505, the primary expiry script is sent to the refund server 610. At step 1507, the primary expiry script is executed at the refund server 610 to determine an alternative user device. At step 1509, the alternative user device 616b is used, instead of the main user device 616a, for execution of the following steps, such as step 1240 (FIG. 14A), for example, to generate another notification script.

[0302] If the given period has expired for the alternative user device 616b, the notification server 608 may prepare a secondary expiry script to return the funds to the trust account 1130, the secondary expiry script comprising the address or computing device ID of the second alternative user device 616c and the address of the notification server 608, previously identified by the user and recorded previously in the user account database 1120. Then, the secondary expiry script is sent to the refund server 610. The secondary expiry script is then executed at the refund server 610 to return the funds to the trust account.

[0303] According to an embodiment, the refund server 610 is further linked for data communication to a quarantine account (not shown), and further wherein the method further comprises, in the absence of the approval of the refund from the alternative user device 616b, 616c during the other notification period, generating, by the notification server 608, a secondary expiry script for execution by the refund server to transfer the refund to the quarantine account.

[0304] According to another embodiment, the method further comprises, after a quarantine period: generating and sending, by the notification server 608, a quarantine notification to the main user device 616a, the quarantine notification including the amount of the refund to be credited to the labeled user account; and monitoring during a quarantine notification period, by the notification server 608, approval of the refund from the main user device 616a.

[0305] According to yet another embodiment, in the absence of the approval of the refund from the main user device 616a during the quarantine notification period generating, by the notification server 608, a quarantine expiry script for execution by the refund server 610 to diffuse the refund for alternative uses. The alternative uses include, but are not limited to, using the funds for special occasions as described herein; or adding the funds to the balance of the trust account for diffusion in association with another given accumulation period.

[0306] Referring now to FIG. 14B, in some embodiments, at step 1462, the notification server 608 generates an authentication script to request a login information to the user account. At step 1464, from the notification server to the user device, transmitting the authentication script to request the login information to the user account. At step 1466, in response to receiving a notification from the main user device 616a that the user clicked on the notification link, a login page is displayed and prompts the user to enter (input) an account login ID and password requested on the main user device 616a. At step 1468, the notification server requests, from the main user device 616a, a passcode. The passcode is captured in response to the user entering the passcode at the main user device 616a. At step 1470, the refund server 610 verifies the passcode received from the main user device 616a. At step 1472, in response to the user clicking on the refund link, a notification of acceptance of the refund is received from the main user device 616a.

[0307] Referring to FIG. 14C, in some embodiments, the prompt sent by the notification server 608 may also comprises a prompt to identify at least one user-designated account. The instruction received from the main user device 616a may also comprise an identification of the at least one user-designated account and the refund script may also comprise the identification of the at least one user-designated account. For example, the user may request to transfer the funds to more than one account and the data regarding these additional user-designated accounts may be transmitted from the main user device 616a.

[0308] Still referring to FIG. 14C, the method comprises, at step 1474, prompting the user to select whether the refund should be credited to the user account or to another account or to other purchasing accounts (PayPal, Amazon, Cryptocurrencies). If the user selects the user account, at step 1476, a confirmation is received from the user device that the refund should be credited to the user account (which becomes a “user-designated account”). If the user does not select the user account, at step 1478, a confirmation is received that the refund should be credited to an account other than the user account, so-called user-designated account. Then, at step 1480, an identification of the user-designated account (which becomes the “user account” for execution of further steps) is received.

[0309] While preferred embodiments have been described above and illustrated in the accompanying drawings, it will be evident to those skilled in the art that modifications may be made without departing from the concept and method of this disclosure. Such modifications are considered as possible variants comprised in the concept and method of this disclosure.