FR3095540A1 - Method for processing a set of orders in a computerized environment - Google Patents

Abstract

The invention relates to a computer implemented method for processing a set of commands in a computerized environment comprising the following steps: a) receiving a set of commands from a set of respective users, each of the commands comprising a product value, a pricing currency associated with the value of the product, a payment currency associated with the user's payment means, said pricing currency and said payment currency being different, each order being associated with a duration limit for the finalization of the execution of the order, b) determining whether said set of received orders comprises a first order and a group of at least one second order, one of the group of at least one second order having as currency of payment the pricing currency of the first order and one of the group of at least one second order having as pricing currency the payment currency of the first order, c) in this case, before the shortest period of the first and at least a second order, the execution of the first order using the means of payment of said at least one second order and 'execution of one of said at least second order using the means of payment of the first order. Figure for short: Fig. 3

Description

Method for processing a set of orders in a computerized environment

The invention relates to the field of client server architectures notably dedicated to electronic commerce, subsequently called e-commerce.

E-commerce has been growing with the development of the Internet. In particular, electronic payment enables users to purchase goods or services (hereafter called products), for example travel tickets which are sold by remote merchants. The remote merchant can be established in the same monetary zone than the user, using the same currency. In that case, the pricing currency of the merchant (also referred to hereafter as “target currency”) and the currency of the bank account of the user are same, which obviates the need for conversion.

However, the pricing currency of the merchant and the currency of the bank account of the user may be different. This may happen if the price of the product is really attractive, or if the product is available only from that precise merchant. In that case, the bank of the user takes a commission. The amount of the commission is in a range of about 3% of the amount of the transaction. The percentage corresponding to the bank commission depends on the rules of the bank, which creates uncertainty for the user. Moreover, the actual exchange rate between the pricing currency and the user currency also itself depends on the bank. The final price that a user has to pay can thus fluctuate and cannot be accurately identified by the user.

Such uncertainty still increases when a purchase is done across several monetary zones. For example, in the travel industry, a user having a bank account in euros may purchase a flight ticket in dollars by an American airline, for a flight from Europe to the United States. Then, he may travel from the United States to Japan, and purchase a flight tickets in yen for that leg from a Japanese airline. Thus, it is not possible to accurately assess on the one hand the bank commission and the conversion rate from euro to dollar, and on the other hand the bank commission and the conversion rate from Euro to Yen.

Due to such unclear information, a user may hesitate to complete a transaction. This impacts the number of sales, which can represent a significant loss of revenue for the product provider.

To address such problem, an existing approach used in the travel industry is to propose alternative currencies at the point-of-sale of travel providers. However, this generally depends on the bank of the merchant, which may charge for local accounts in different currencies. In practice, a very few number of currencies is generally accepted (mainly dollars). The number of eligible users is therefore limited.

In another existing approach, a Dynamic Currency Conversion process (DCC) is used which represents a process in which the amount of a Visa or MasterCard transaction is converted by the merchant into the currency of the payment card's country. However, according to such regulated scheme, the exchange rate markups are mostly higher than the card user’s currency conversion fees that DCC avoids. Thus, in almost all cases, DCC results in a higher charge to the user.

In still another approach, a Multi-Currency Pricing (MCP) is used. MCP represents a financial service which allows merchants to price products in a variety of foreign currencies, while continuing to receive the payment in their currency. MCP is currently available only for Visa and MasterCard cardholders.

Both DCC and MCP are schemes whereby a user can select his or her originating country or the currency according to which the prices are to be displayed to him. The user payment for a purchase will be then charged in the selected currency. Further, the amount displayed to the user at check-out is the same amount than the amount which will appear on his account statement. Both solutions shift the exchange rate commission to the merchant, which in turn forwards a commission for using this service to the user.

There is accordingly a need for a system and a method that reduce and even remove any commission imposed on the user for a product purchased in a currency which is different from the currency of his credit card.

It is proposed, according to one aspect of the invention, a computer-implemented method for processing a set of orders in a computerized environment, comprising the steps of:
a) receiving a set of orders from a set of respective users, each of the orders comprising a product value, a pricing currency associated to the product value, a payment currency associated to a means of payment of the user, said pricing currency and said payment currency being different, each order being associated with a time limit for completion of the execution of the order,
b) determining if said set of received orders comprised of a first order and a group of at least one second order, one of the group of at least one second order having as payment currency the pricing currency of the first order, and one of the group of at least one second order having as pricing currency the payment currency of the first order,
c) if so, before the lowest time limit of the first and at least one of the at least one second order, executing the first order using the means of payment of one of the at least one second order, and executing one of the at least second order by using the means of payment of the first order.

In some embodiments, the group may comprehend at least one second order comprehend a unique second order, and step b) may comprehend determining if said first order and said second order comprehend an opposite couple of pricing currency and payment currency.

In some embodiments, the group may comprise at least one second order may include:
-a second order comprising a second product value, a second pricing currency (also referred to hereafter as “second target currency”) associated with the second product value, a second payment currency associated with a means of payment of a second user, said second payment currency and said pricing currency of the first order being identical,
- a third order comprising a third product value, a third pricing currency (also referred to hereafter as “third target currency”) associated with the third product value and being identical to the payment currency of the first order, a third payment currency associated with a means of payment of a third user, said third payment currency and said pricing currency of the second order being identical,
step c) may include, before the lowest time limit of the first, second and third orders, executing the first order by using the means of payment of the second order, executing the second order by using the means of payment of the third order, and executing the third order by using the means of payment of the first order.

In some embodiments, step a) may comprise transmitting to the user from which an order has been received a message related to the probability of completion of the execution of the order of the user before the time limit.

In some embodiments, step a) may comprehend, for each of the orders of the set of orders, checking the solvency of the means of payment of the user relative to the product value associated to the order, and transmitting the corresponding order to a bank associated with the means of payment of the user if the solvency is not ensured.

In some embodiments, the computer-implemented method may comprise a step of storing the orders in a database, said database comprising a plurality of sub-databases, the orders which have the same user currency being grouped in a same sub-database.

In some embodiments, the computer-implemented method may comprise a step of removing the order from the sub-database, if the execution of the order is completed and/or if the time limit of the order has elapsed.

In some embodiments, the computer-implemented method may include:
-a step of selecting among the set of orders a master order and at least one corresponding auxiliary order, the at least one auxiliary order contributing to the execution of the master order, the sum of the product values of the auxiliary orders being higher or equal to the product value of the master order
-a step of generating at least one agreement transaction, the agreement transaction comprising a reference to the master order, and a reference to each of the at least one auxiliary order.

In some embodiments, the computer-implemented method may comprise a step of determining an auxiliary order to be split and a step of splitting said auxiliary order into a remaining order and a completing order for the execution of the master order, and wherein, in response to the execution of the master order, the method comprising a step of generating another supplementary transaction, said another supplementary transaction comprising a reference to the remaining order as a new master order, and a reference to each of the at least one auxiliary order contributing to the execution of the new master order.

In some embodiments, wherein the step of determining an auxiliary order to be split may comprise determining the corresponding remaining order whose product value is minimized.

In some embodiments, the computer-implemented method may comprise a step of transmitting at least a part of the orders to a bank associated with the means of payment of the user, if the execution of the order is partially completed or not completed at all when the time limit of the order has elapsed.

In some embodiments, the computer-implemented method may comprise a step of transmitting a message to the user related to the result of step b).

In some embodiments, the computer-implemented method may comprise a step of storing a history of the orders for which the execution is completed.

In some embodiments, the order may be a purchase order.

It is also proposed a system for processing a set of orders in a computerized environment, the system being configured to:
a) receive, at a computer, a set of orders from a set of respective users, each of the orders comprising a product value, a pricing currency associated to the product value, a user currency associated to a means of payment of the user, said pricing currency and said user currency being different, each order being associated with a time limit for completion of the execution of the order,
b) determine, by the computer, if said set of received orders comprised of a first order and a group of at least one second order, one of the group of at least one second order having as payment currency the pricing currency of the first order, and one of the group of at least one second order having as pricing currency the payment currency of the first order,
c) if so, before the lowest time limit of the first and at least one of the at least one second order, execute the first order using the means of payment of one of the at least one second order, and executing one of the at least second order by using the means of payment of the first order.

In some embodiments, the group comprehends at least one second order comprising a unique second order, the system is further configured to determine if said first order and said second order comprehend an opposite couple of pricing currency and payment currency.

In some embodiments, the group comprising at least one second order includes:
- a second order comprising a second product value, a second pricing currency associated to the second product value, a second payment currency associated to a means of payment of a second user, said second payment currency and said pricing currency of the first order being identical ,
- a third order comprising a third product value, a third pricing currency associated to the third product value and being identical to the payment currency of the first order, a third payment currency associated to a means of payment of a third user, said third payment currency and said pricing currency of the second order being identical,
the system is further configured to, before the lowest time limit of the first, second and third orders, execute the first order by using the means of payment of the second order, executing the second order by using the means of payment of the third order , and executing the third order by using the means of payment of the first order.

In some embodiments, the system is further configured to transmit to the user from which an order has been received a message related to the probability of completion of the execution of the order of the user before the time limit.

In some embodiments, the system is further configured to check, for each of the first and second order, the solvency of the means of payment of the user relative to the product value associated to the order, and transmitting the corresponding order to a bank associated with the means of payment of the user if the solvency is not ensured.

In some embodiments, the system is further configured to store the orders in a database, said database comprising a plurality of sub-databases, the orders which have the same user currency being grouped in a same sub-database.

In some embodiments, the system is further configured to remove the order from the sub-database, if the execution of the order is completed and/or if the time limit of the order has elapsed.

In some embodiments, the system is further configured, if step b) fails, to select among the set of orders a master order and at least one corresponding auxiliary order, the at least one auxiliary order contributing to the execution of the master order, the sum of the product values of the auxiliary orders being higher or equal to the product value of the master order, and to generate at least one agreement transaction, the agreement transaction comprising a reference to the master order, and a reference to each of the at least one auxiliary order.

In some embodiments, the system is further configured to determine an auxiliary order to be split and a to split said auxiliary order into a remaining order and a completing order for the execution of the master order, and wherein, in response to the execution of the master order, the system is configured to generate another supplementary transaction, said another supplementary transaction comprising a reference to the remaining order as a new master order, and a reference to each of the at least one auxiliary order contributing to the execution of the new master order..

In some embodiments, the system is further configured to determine the corresponding remaining order whose product value is minimized.

In some embodiments, the system is further configured to transmit at least a part of the orders to a bank associated with the means of payment of the user, if the execution of the order is partially completed or not completed at all when the time limit of the order has elapsed.

In some embodiments, the system is further configured to store a history of the orders for which the execution is completed.

In some embodiments, the order is a purchase order.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with the general description of the invention given above, and the detailed description of the embodiments given below, serve to explain the embodiments of the invention:

illustrates a use case of purchases using the method according to the invention.

illustrates another use case of purchases using the method according to the invention.

is a diagram illustrating an exemplary implementation of a system according to the invention.

is a diagram illustrating the computer environment of the system according to the invention.

illustrates a time diagram of the method according to the invention.

illustrates another time diagram of the method according to the invention.

is a schematic representation illustrating the case in which an auxiliary order becomes a master order.

is a first representation of the buckets which are used in the method according to the invention.

is a second representation of the buckets which are used in the method according to the invention

is a third representation of the buckets which are used in the method according to the invention.

The terms “purchase order” or “order” hereafter refer to a user command that triggers the purchase from a merchant, hereafter referred to product provider, of a product in response to the execution of a user command.

The invention is based on the fact that some merchants are intermediary for a huge number of payment transactions per day. This is the case for example for merchant of the travel industry, in particular Global Distribution Systems. A Global Distribution System is a computerized network system which enables transactions between travel industry service providers, mainly airlines, hotels, car rental companies, and travel agencies. The major online retailers are also intermediary for a huge number of payment transactions per day.

The method is executed by a dedicated platform of a merchant. For example, as illustrated by figure 1, a first user, who has a means of payment in a first currency, for example a credit card in dollars, wants to purchase a flight ticket from a French airline, which is sold in euros. The currency of the means of payment of the first user is different from the currency of the bank account of the company which sells the flight ticket. The flight ticket that the first user wants to buy has the price up to 100 euros.

On the other side, a second user, who has a means of payment in a second currency, for example a credit card in euros, wants to purchase a flight ticket from an American airline, which is sold in dollars. The currency of the means of payment of the second user is different from the currency of the bank account of the company which sells the flight ticket. The flight ticket that the second user wants to buy has the price up to 115 dollars.

At the day of the requests, the Bankers Selling Rate (BSR) from euro to dollars amounts 1.15. In that case, the product value of the first user perfectly matches the product value of the second user. Therefore, the platform is able to proceed with the purchase of the payment of the flight ticket in euro with the means of payment in euros, and the purchase of the payment of the flight ticket in dollars with the means of payment in dollars. Therefore, the users can purchase the flight tickets, without any bank commission.

Figure 2 illustrates another scenario, in which the matching between different orders can be made with more than two users. In that case, a first user, which has a means of payment in dollars, wants to buy a flight ticket for 150 euros, which is equivalent to 172 dollars according to the Bankers selling rate from euro to dollars. A second user, who has a means of payment in euros, wants to buy a flight ticket for 126 dollars. A third user, who has a means of payment in euros, wants to buy a flight ticket for 46 dollars.

A matching operation between the three orders can be made. Indeed, the order of the first user is split into two transactions. On one side, the first user purchases both flight tickets (the flight ticket of 126 dollars and the flight ticket of 46 dollars) in dollars with the means of payment in dollars. On the other side, both users who have means of payment in euros are gathered so as to purchase the flight ticket which is sold in euros.

In that case also, the users can purchase the flight tickets, without any bank commission.

The invention can be applied to any kind of electronic means of payment, notably by credit card.

Figure 3 is a diagram illustrating an exemplary implementation of a system according to the invention.

In a first step of the method according to the invention, the platform receives a set purchase orders respectively from a set of users, who trigger the purchase orders through a client device 300. In figure 1, only one user and one client device 300 are depicted, for simplicity of presentation. Each purchase order comprises a product value, which may be converted to a standard currency which may be common for all the orders. The conversion can be made according to according to a Bankers Selling Rate. The BSR is a daily exchange rate. It is the official source for international payment currency conversions used by the industry for pricing and ticketing (used in sells). It contains the exchange rates at a given time. In the travel industry, GDS can source the BSR from IATA (International Air Transport Association).

The product value represents the price of the goods or service. The purchase order also comprises a pricing currency associated to the product value, also referred to as the target currency. The pricing currency represents the currency in which the product is sold. In other words, the pricing currency is the currency of the bank account of the seller. The purchase order also comprises a user currency associated with a means of payment of the user.

The platform 100 comprised an opt-in server 101. The registration of the user to the matching operation is managed by the opt-in server 101. The opt-in server 101 has three functions, which are the filtering of the users, the acknowledgment of participation, and the solvency checking of the user. In a first step, the opt-in server 101 asks the user if he wants to take part in the process of payment matching. If the answer is positive, the opt-in server 101 provides to the user an estimation of the fulfillment of the payment matching. The estimation is based on the purchase order of the user: the product value, the pricing currency associated to the product value, the user currency associated to a means of payment of the user and the time limit for the completion of the purchase.

At this stage, the opt-in server 101 also checks the solvency of the user, relative to the product value. The solvency may be assessed in view of an evaluation of the balance of the bank account of the user if the purchase order was completed. In particular, the balance has to be above a predefined level if the purchase was completed. If the opt-in server 101 determines that the user is solvent, an authorization is given by the opt-in server 101 to the user to access the platform. This authorization is associated with an identification to be reused afterwards in the process in the action center. The action of this verification is done by the action center on request of the opt-in server. In case the solvency is not verified, the opt-in server 101 denies the user request, and he is informed that the order will be transmitted to the bank associated to the means of payment of the user. Therefore, there is no reviewing of the chain of order matching, which reduces the complexity of the process.

The opt-in server 101 receives from the order book 102 information concerning the availability of some currencies, as it will be described below. The opt-in server 101 may also give an estimate of completion of the order depending on the time of the day. For example, due to the time difference between North America and Europe, a European user who would like to pay a product in dollars in the morning, may have to wait for a few hours. As from the beginning of the afternoon in Europe, most the American customers start their shopping sessions. Therefore, the time slot between different monetary zones is a parameter which is taken into account by the opt-in server 101 to estimate a percentage of satisfaction of the user request.

In another embodiment, the opt-in server 101 may refuse the matching operation, if there isn’t any historical demand for matching between two predetermined currencies. Instead of refusing the user request, the opt-in server 101 provides percentage estimation, even very low. If the percentage is very low, the opt-in server 101 may advise the user not to take part in the matching operation. The user may also be warned that the transaction can be completed by his bank in order to satisfy his order if it is not 100% completed.

The percentage of completion of the order through the platform is also computed for a given time; which is time limit for the completion of the purchase. The time limit is a data which is associated with the order. It may be a time limit which is imposed by the merchant. In an example of the invention in the travel industry, once the user has taken an option on a flight through the airline website, or through an online travel agency, the option may be booked for a predetermined time, and then released, if the user has not completed the purchase.

The order book 102 stores all the purchase orders that users who wish to participate have passed. A time limit is associated with each order. The order book 102 stores orders using the time keeper 103, which determines, for each order, the deadline of the payment.

The order book 102 is a database which contains orders and transactions, and which includes buckets. A bucket is a sub-division, or sub-database, of the order book 102, which contains the orders having the currency of origin, that is to say the same user currency. The bucket contains only orders that have the same currency of origin. Therefore, each bucket functionally groups elements of the same nature.

For example, a first user inputs an order in which the user currency is euros; so as to purchase a product in dollars. A second user inputs an order in which the user currency is euros; so as to purchase a product in Yen. Both orders are stored in the same bucket associated with euros.

The allocation according to the user currency increases the speed of the matching process. Indeed, the payment matcher 105 knows where it can find a determined currency, since all the orders which made that currency available are stored in that bucket.

Moreover, the exact amount of available value in each currency can be determined, by summing the cells of the bucket which contains the product value. Therefore, when the opt-in server 101 receives a request to find a corresponding order with the opposite currencies, the opt-in server 101 determines the sum of the corresponding bucket, and determines if it is possible to match the incoming order with another one .

In each bucket, the purchase orders can be indexed with a tag to have quicker access to transactions and orders according to their identifier. The tag is a unique identifier assigned by a database to a record. For example, the tag can be attributed according to the order of arrival in the order book 102.

Each bucket stores transactions which have not been satisfied. Indeed, transactions which have been satisfied are removed from the order book 102.

The payment matcher 105 reads the orders which are stored in the order book 102, and checks whether it can associate an order to another other, or to several orders, according to the currencies of the orders, as illustrated in figures 1 and 2. When the payment matcher 105 has determined a transaction which is complete, it will transmit the transaction to the action center 104.

The action center 104 interacts with the payment platform 200. It proceeds with the purchase of the products for which the matching operation has been completed. It also historizes all the information relating to the order which has been satisfied.

The order book 102 stores the orders as long as the purchase orders have not been entirely completed, that is to say as long as the product has not been paid and validated.

Each of the sub-elements of the platform 100, the client device 300, the payment platform 200, as well as other systems or devices of the operating environment such as the reservation platform 400 may be implemented on one or more computing devices or systems, referred to collectively as a computer, such as computer 26, and illustrated in figure 4. The computer 26 may include a processor 28, a memory 30, a mass storage memory device 32, an input/output (I/O) interface 34, and a Human Machine Interface (HMI) 36. The computer 26 may also be operatively coupled to one or more external resources 38 via the network 24 or I/O interface 34. External resources may include, but are not limited to, servers, databases , mass storage devices, peripheral devices, cloud-based network services, or any other suitable computer resource that may be used by the computer 26.

The processor 28 may include one or more devices selected from microprocessors, micro-controllers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, or any other devices that manipulate signals (analog or digital) based on operational instructions that are stored in the memory 30. The memory 30 may include a single memory device or a plurality of memory devices including, but not limited, to read-only memory (ROM ), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any other device capable of storing information. The mass storage memory device 32 may include data storage devices such as a hard drive, optical drive, tape drive, non-volatile solid state device, or any other device capable of storing information.

The processor 28 may operate under the control of an operating system 40 that resides in the memory 30. The operating system 40 may manage computer resources so that computer program code embodied as one or more computer software applications, such as an application 42 residing in memory 30, may have instructions executed by the processor 28. In an alternative embodiment, the processor 28 may execute the application 42 directly, in which case the operating system 40 may be omitted. One or more data structures 44 may also reside in memory 30, and may be used by the processor 28, operating system 40, or application 42 to store or manipulate data.

The I/O interface 34 may provide a machine interface that operatively couples the processor 28 to other devices and systems, such as the network 24 or the one or more external resources 38. The application 42 may thereby work cooperatively with the network 24 or the external resources 38 by communicating via the I/O interface 34 to provide the various features, functions, applications, processes, or modules comprising embodiments of the invention. The application 42 may also have program code that is executed by the one or more external resources 38, or otherwise rely on functions or signals provided by other system or network components external to the computer 26. Indeed, given the nearly endless hardware and software configurations possible, persons having ordinary skill in the art will understand that embodiments of the invention may include applications that are located externally to the computer 26, distributed among multiple computers or other external resources 38, or provided by computing resources (hardware and software) that are provided as a service over the network 24, such as a cloud computing service.

The HMI 36 may be operatively coupled to the processor 28 of computer 26 in a known manner to allow a user to interact directly with the computer 26. The HMI 36 may include video or alphanumeric displays, a touch screen, a speaker, and any other suitable audio and visual indicators capable of providing data to the user. The HMI 36 may also include input devices and controls such as an alphanumeric keyboard, a pointing device, keypads, pushbuttons, control knobs, microphones, etc., capable of accepting commands or input from the user and transmitting the entered input to the processor 28 .

A database 46 may reside on the mass storage memory device 32, and may be used to collect and organize data used by the various systems and modules described herein. The database 46 may include data and supporting data structures that store and organize the data. In particular, the database 46 may be arranged with any database organization or structure including, but not limited to, a relational database, a hierarchical database, a network database, or combinations thereof. A database management system in the form of a computer software application executing as instructions on the processor 28 may be used to access the information or data stored in records of the database 46 in response to a query, where a query may be dynamically determined and executed by the operating system 40, other applications 42, or one or more modules.

Figures 5 illustrates a time diagram of the method according to the invention. The different steps of the method are executed according to a time scale symbolized by time axis. The two-way communications between the different sub-elements of the platform 100, and the communications between the platform and the systems which are external to the platform, are denominated “MSGn” (n=1…12). The MSGn messages are also illustrated in figure 3. In a first step, the user submits order X to the opt-in server 101 (MSG1). In a particular embodiment of the invention applied to the travel industry, order X is a purchase order to buy a travel product, for example a flight ticket, in a currency which is different from the currency of the means of payment of the user. The opt-in server 101 analyzes order X. The opt-in server 101 checks the solvency of the means of payment of the user relative to the product value associated to order X (MSG2), which results in a blocking of the corresponding amount of money. The blocking step is performed by the action center 104. The latter transmits the corresponding order to a bank associated with the means of payment of the user if the solvency is not ensured.

Upon acknowledgment of the user, order X is stored in the order book 102 (MSG2bis), in the appropriate bucket corresponding to the user currency. As long as order X is stored in the order book 102, a watchdog function is executed by the time keeper 103, in communication with the order book 102 (MSG7). As order X contains a time limit, the completion of the order has to be processed as long as the time limit has not elapsed.

Then, order X is added to the payment matcher 105 (MSG3). The payment matcher 105 reads the orders which could match with order X. The payment matcher 105 reads the bucket of the product currency of order X. For example, if, in order X, the user currency is euros, and the product currency is dollars , then the payment matcher 105 reads the bucket associated with dollars. When a best match has been found by the payment matcher 105, as illustrated by figures 1 and 2, the payment matcher 105 locks the orders of the best match, and a list of orders which would be compatible with order X is sent by the payment matcher 105 to the action center 104, in order to validate the feasibility of the payment, regarding in particular the solvency of the users (MSG4).

Then, the action center 104 sends a request for historizing the successful transaction (MSG9). The historical data will be used to compute eligibility criteria for the opt-in server 101. It also requests the payment server to proceed with the payment of the orders associated to the successful transaction (MSG10). In a particular embodiment of the invention to the travel industry, the purchase process ends with the update of the reservation of the ticket, including the update of the PNR (Passenger Name Record). For that purpose, the action center 104 communicates with the reservation platform 400 (MSG11). Each PNR is updated with the form of payments which will be used for ticket issuance. The hidden fields in the form of payments are updated with the information of the user credit card information, which may be useful to perform refunds for instance. Subsequently, the orders which have been implied in the successful transaction are removed from the order book 102 (MSG6), and the watchdog function is inhibited for these orders (MSG7). Finally, the users who have taken part in the transaction are advised by the action center 104 (MSG12).

It can be noted that the action center 104 can also be able to ensure that the various matches done will not fail later due to a failing authorization which would block the funds for each user. It is critical to ensure successful authorization. If one authorization fails, this could trigger a rollback of all the matches done so far. Also as authorization process with the bank is blocking the funds on a user account for a few days, roll-back of already authorized amounts would be problematic. Since the overall amount to be blocked in the currency of the means of payment of the user is known, it is possible to perform this authorization up-front.

In a particular embodiment of the invention which is applied to the travel industry, there may be notably two ways to perform such action:

The action center 104 can request an authorization directly with the credit card schemes, and then each involved airline will settle the (possibly partial) funds with their acquirer based on the authorization;

The action center 104 can authorize the amount and generate with a partner a pre-funded virtual credit card number, which will be used in subsequent authorizations by the airlines. This allows full reliability that the transactions will not fail. This virtual card will never be seen by the end users, but will be used only for the transactions.

In any case, the initial authorization blocking the amount is associated with the relevant order.

Figure 6 illustrates a time diagram of an embodiment of the method according to the invention, when no match has been found within the time limit of order X. In that case, the time keeper 103 sends a message to the payment matcher 105 that time has elapsed for order X, by applying the watchdog function (MSG8). Then, the payment matcher 105 requests the action center 104 to treat order X by asking the bank of the user to complete the purchase (MSG4). The action center 104 requests the transaction histizer 106 to histize the transaction (MSG9). The historization of transactions may help the opt-in server 101 to determine a percentage of success of completion of a new incoming order, based on the results of the preceding requests. Then, the action center 104 requests the payment server to proceed with the payment of the orders associated to the successful transaction (MSG10). In a particular embodiment of the invention to the travel industry, the purchase process ends with the update of the reservation of the ticket, including the update of the inventory of the airline, and the assignment of a PNR (Passenger Name Record) to the user (MSG11). Subsequently, order X is removed from the order book 102 (MSG6). Finally, the user of order X is advised by the action center 104 that no match has been found (MSG12), and that the purchase has been completed by using his bank, which could lead to a bank commission.

Figure 7 is a schematic representation illustrating the case in which an auxiliary order becomes a master order. So as to generate a transaction, an order Ord1 is selected by the action center 104. This order Ord1 is called master order of the first transaction TR1: it contains the order that the transaction TR1 must satisfy.

As illustrated by figure 7, all the orders of the product currency associated with the master order O1 of the first transaction TR1 may be considered as auxiliary orders. The master order O1 has a reference to the transaction TR1, referred to as agreement transaction, in which it is master, and the other orders have a reference to the agreement transaction TR1 in which they are participants. When almost the entire master order O1 is matched with one or several auxiliary orders (one auxiliary order O2 in figure 7), there are few chances to find an order which exactly matches the amount which remains. If there is an order which exactly matches the amount which remains, then the execution of the master order is totally completed. This case is illustrated in figure 2, which has already been described.

If not, a first option is to call upon the bank of the user, for the small amount which remains. With the first option, the commission which is charged by the bank is lower than the state of the art methods. The second option is to split an auxiliary order (order O3), which is referred to as auxiliary order O3 to be split. The auxiliary order to be split O3 has a first part, referred to as completing order, to complete the agreement transaction TR1; the other part of the auxiliary order to be split O3 is referred to as remaining order, which becomes a master order in the next transaction TR2, called supplementary transaction. Therefore, the new master order of the supplementary transaction TR2 is completed on priority basis. For example, in figure 7, order O4 is an auxiliary order for transaction TR2.

Optionally, the time limit of the master order is lower than the time limit of each of the auxiliary orders.

In a particular embodiment of the invention, among all the potential auxiliary orders which are able to complete the transaction TR1, the auxiliary order to be split is the one whose corresponding remaining order has a product value which is minimized. Therefore, should the supplementary transaction TR2 not be completed, the amount to be converted by the bank would be minimized.

What follows describes the different constraints which are taken into account for the completion of the orders.

Let note TRi the transaction having tag “i”.

The transaction TRi includes a unique identifier (i in the above notation), a reference to the Master Order MO to satisfy, the time limit of the transaction, which is equal to Master Order MO time stamp, and a list of references to the auxiliary orders AOi (i=0…n) participating to complete the master order MO.

A transaction TRi integrates orders with the following constraints: a guarantee that no timeout from auxiliary orders AOk will break the transaction during its generation: for each auxiliary order AOi, tMO < tAOi; and the time limit of the transaction is lower than the time limit of the order.

No more than one order is split to perform the transaction:

.

The sum of the values of auxiliary orders plus the value of the auxiliary order to be split AOk is upper or equal to the amount of the master order.

T( ) returns the value of the target currency (pricing currency) for the order i.

M( ) returns the value of the currency for the order i.

The rest is minimized:

,

Figure 8 illustrates the view in buckets of a transaction. In each bucket, M#order, CDcur = T#order, TGcur * RTGcur, CDcur, where M#order, CDcur is the available amount in the payment currency CDcur (corresponding to the product value) for order #order, T#order , TGcur is the product value in the target currency TGcur for order #order (also referred to as pricing currency), and RTGcur, CDcur is the conversion rate between the payment currency CDcur and the target currency TGcur. According to a particular embodiment, the conversion rate is the Banker's Selling Rate (BSR), which can be daily loaded and updated.

The bucket CUR0 contains all the orders which are associated with means of payment in the currency CUR0. In particular, the bucket CUR0 contains an order O1, associated to a time limit t1 for completion of the execution of the order O1. M1,0 is the available amount in the currency CUR0 for order O1 (equivalent to the product value, but in the currency CUR0), and the user of order O1 wants to buy a product having a product value T1,1 in the target currency (pricing currency CUR1 for the order O1). Each bucket contains as many columns as required by the target currencies. The bucket CUR1 contains an order O2, associated to a time limit t2 for completion of the execution of the order O2. M2,1 is the available amount in the currency CUR1 for order O2, and the user of order O2 wants to buy a product having a product value T2,0 in the target currency (pricing currency CUR0 for the order O2).

An agreement transaction TR1 is generated. Since the time limit t1 is inferior to the time limit t2, order O1 is the master order. Order O2 is an auxiliary order in the agreement transaction TR1, since it is stored in bucket CUR1, and it is associated with currency CUR0.

The available amount in the currency CUR0 is converted into the currency CUR1, according to a Banker's Selling Rate (BSR) between currencies CUR0 and CUR1.

After the execution of the agreement transaction TR1, the available amount in the currency CUR0 for order O1 is M1,0-T2,0, and there is still an amount of T1,1-M2,1 to convert in the target currency CUR1.

Then, as illustrated by figure 9, another order O3, which is stored in the bucket CUR1, is implied and participates to the transaction agreement TR1. Order O3 is associated with a time limit t3 for completion of the execution of the order O3. M3,1 is the available amount in the currency CUR1 for order O3, and the user of order O3 wants to buy a product having a product value T3,0 in the target currency (pricing currency CUR0 for the order O3).

Order 3 is split to complete the execution of transaction TR1. Therefore, when the agreement transaction TR1 has been executed, the available amount in currency CUR0 is null. In the bucket CUR1, order O3 has a residual available amount in currency CUR1. Therefore, another supplementary transaction TR2 is generated. The master order is order O3.

A transaction can also involve more than two currencies, as illustrated by figure 10.

Among the received orders, a first order is determined, notably the one which has the shortest time limit (order O1). The first order O1 is received from a first user, comprising a first product value T1,1, a first pricing currency CUR1 associated to the first product value, a first user currency CUR0 associated to a means of payment of the first user. The first pricing currency CUR1 is also referred to as first target currency.

A second order O5 is received from a second user, comprising a second product value T5,2, a second pricing currency CUR2 associated to the second product value, a second user currency CUR1 associated to a means of payment of the second user, said second user currency and said first pricing currency being identical. The second pricing currency CUR2 is also referred to as second target currency

A third order O6 is received from a third user comprising a third product value T6,0, a third pricing currency CUR0 associated to the third product value, a third payment currency CUR2 associated to a means of payment of a third user, said third payment currency and said pricing currency of the second order being identical. The third pricing currency and the payment currency of the first order are identical. The third pricing currency CUR2 is also referred to as third target currency

Before the lowest time limit of the first, second and third orders, the first order O1 is executed by using the means of payment of the second order O5; the second order O5 is executed by using the means of payment of the third order O6; and the third order is executed by using the means of payment of the first order O1.

In figure 10, three currencies are involved. The same method could be implemented for more than three currencies.

Therefore, even orders implying minor currencies (i.e. currencies with small volumes of transactions) can be executed.

The embodiment of the invention implying three currencies or more can also implement the splitting of auxiliary orders, in order to complete the agreement transaction, as it has been seen previously between two currencies.

It has been shown that the method according to the invention guarantees that a transaction is always closed, even if it means using the bank of the user. The method also guarantees that an order or a transaction (one to one or one to more) is always preferred to a bank exchange, so as to close a transaction. Therefore, the bank commissions are minimized.

Claims (15)

A computer-implemented method for processing a set of orders in a computerized environment, comprising the steps of:
a) receiving a set of orders from a set of respective users, each of the orders comprising a product value, a pricing currency associated to the product value, a payment currency associated to a means of payment of the user, said pricing currency and said payment currency being different, each order being associated with a time limit for completion of the execution of the order,
b) determining if said set of received orders included a first order and a group of at least one second order, one of the group of at least one second order having as payment currency the pricing currency of the first order, and one of the group of at least one second order having as pricing currency the payment currency of the first order,
c) if so, before the lowest time limit of the first and at least one of the at least one second order, executing the first order using the means of payment of one of the at least one second order, and executing one of the at least second order by using the means of payment of the first order. The computer-implemented method according to claim 1 wherein the group comprising at least one second order included a unique second order, and wherein step b) included determining if said first order and said second order included an opposite couple of pricing currency and payment currency. The computer-implemented method according to claim 1 wherein the group comprising at least one second order included:
-a second order comprising a second product value, a second pricing currency associated with the second product value, a second payment currency associated to a means of payment of a second user, said second payment currency and said pricing currency of the first order being identical ,
- a third order comprising a third product value, a third pricing currency associated with the third product value and being identical to the payment currency of the first order, a third payment currency associated to a means of payment of a third user, said third payment currency and said pricing currency of the second order being identical,
step c) comprising, before the lowest time limit of the first, second and third orders, executing the first order by using the means of payment of the second order, executing the second order by using the means of payment of the third order, and executing the third order by using the means of payment of the first order. The computer-implemented method according to any of the preceding claims, wherein step a) included transmitting to the user from which an order has been received a message related to the probability of completion of the execution of the order of the user before the time limit . The computer-implemented method according to any of the preceding claims, wherein step a) understood, for each of the orders of the set of orders, checking the solvency of the means of payment of the user relative to the product value associated to the order , and transmitting the corresponding order to a bank associated with the means of payment of the user if the solvency is not ensured. The computer-implemented method according to any of the preceding claims, comprising a step of storing the orders in a database, said database comprising a plurality of sub-databases, the orders which have the same user currency being regrouped in a same sub-database . The computer-implemented method according to claim 6, comprising a step of removing the order from the sub-database, if the execution of the order is completed and / or if the time limit of the order has elapsed. The computer-implemented method according to any of the preceding claims, comprising:
-a step of selecting among the set of orders a master order and at least one corresponding auxiliary order, the at least one auxiliary order contributing to the execution of the master order, the sum of the product values of the auxiliary orders being higher or equal to the product value of the master order
-a step of generating at least one agreement transaction, the agreement transaction comprising a reference to the master order, and a reference to each of the at least one auxiliary order. The computer-implemented method according to claim 8, wherein it included a step of determining an auxiliary order to be split and a step of splitting said auxiliary order into a remaining order and a completing order for the execution of the master order, and wherein, in response to the execution of the master order, the method comprising a step of generating another supplementary transaction, said another supplementary transaction comprising a reference to the remaining order as a new master order, and a reference to each of the at least one auxiliary order contributing to the execution of the new master order. The computer-implemented method according to claim 9, wherein the step of determining an auxiliary order to be split included determining the corresponding remaining order whose product value is minimized. The computer-implemented method according to any of the preceding claims, wherein it included a step of transmitting at least a part of the orders to a bank associated with the means of payment of the user, if the execution of the order is partially completed or not completed at all when the time limit of the order has elapsed. The computer-implemented method according to any of the preceding claims, wherein it included a step of transmitting a message to the user related to the result of step b). The computer-implemented method according to any of the preceding claims, wherein it included a step of storing a history of the orders for which the execution is completed. The computer-implemented method according to any of the preceding claims, wherein the order is a purchase order. A system (100) for processing a set of orders in a computerized environment, the system being configured to:
a) receive, at a computer, a set of orders from a set of respective users, each of the orders comprising a product value, a pricing currency associated to the product value, a user currency associated to a means of payment of the user, said pricing currency and said user currency being different, each order being associated with a time limit for completion of the execution of the order,
b) determine, by the computer, if said set of received orders included a first order and a group of at least one second order, one of the group of at least one second order having as payment currency the pricing currency of the first order, and one of the group of at least one second order having as pricing currency the payment currency of the first order,
c) if so, before the lowest time limit of the first and at least one of the at least one second order, execute the first order using the means of payment of one of the at least one second order, and executing one of the