WO2003027919A2

WO2003027919A2 - Data processing installation for electronic wallets, and related method

Info

Publication number: WO2003027919A2
Application number: PCT/FR2002/003215
Authority: WO
Inventors: Pierre-Michel Guilhen
Original assignee: Pierre-Michel Guilhen
Priority date: 2001-09-21
Filing date: 2002-09-20
Publication date: 2003-04-03
Also published as: WO2003027919B1; AU2002347257A1; FR2830099A1; WO2003027919A3

Abstract

The invention concerns a data processing installation comprising a management terminal (3) for data exchange with communication devices (4) associated with identifiers representing remote account numbers, each communication device (4) comprising a so-called local account memory for storing a value representing a so-called local current sum. The installation further comprises first means for carrying out transactions with the management terminal (3), for controlled transfer of data representing sums between the remote account, associated with the communication device (4) concerned, and the local account memory, and with other first means for transfer of data representing part at least of a current local sum of a so-called buyer communication device to a so-called seller communication device, and second means coupled with the first means for modifying the value representing the current local sum in response to a transaction.

Description

DATA PROCESSING INSTALLATION FOR ELECTRONIC PURSE HOLDERS, AND ASSOCIATED METHOD

The invention relates to the field of data processing, and more precisely the installations and methods for exchanging and processing data representative of transactions.

Numerous facilities have been proposed to allow buyers to carry out transactions with sellers (or banking or credit organizations). We thus know of installations in which a paying third party stores, in a service terminal connected to a communication network and to at least one bank server, the bank identifier of each client (buyer and seller) in correspondence with a personal identifier . When the buyer and the seller (who are obligatorily customers of the paying party) have agreed on the amount of the transaction, the buyer and / or the seller establish a connection, via Internet, with the paying party, send him their personal identifiers by SMS messages, and upon receipt of the identifiers the third-party payer extracts the corresponding bank identifiers and then performs the transaction by connecting to the bank server. This installation requires at least one of the two customers involved in the transaction to send at least one SMS message to the third-party payer or to the bank server, the third-party payer generally being paid for the transactions carried out. This transaction cost is a major drawback when the amount is reduced, typically less than 10 or 20 FRF ("micro-payment"). In addition, payments are not anonymous vis-à-vis the third-party payer or the bank server, since each transaction must be recorded at the third-party payer level, for security reasons.

There are also known installations in which a service terminal, connected to a communication network, manages the number of value units which are associated with prepaid cards and which are used for make small purchases on the Internet. The prepaid card is used here as an electronic purse. All transactions passing through the service terminal, because it provides payment for transactions, there is no anonymity. There are also known installations in which transactions are carried out using mobile telephones equipped with a SIM card adapted so as to ensure the function of bank card. As the payment method is substantially identical to that of a real bank card, there is no anonymity in terms of transactions. No known installation brings complete satisfaction in terms of transaction anonymity and / or simplicity of implementation or use.

The invention aims to solve all or part of these drawbacks. To this end, it offers a data processing installation comprising a management terminal capable of exchanging data with communication devices, associated with identifiers representative of remote account numbers and comprising i) a so-called “local account” memory. storing a value representative of a local sum, called “in progress”, ii) first means for carrying out transactions, on the one hand, with the management terminal, for transferring data representative of sums, in a controlled manner, between the remote account, associated with the communication device concerned, and the local account memory, and on the other hand, with other first means for transferring data representative of at least part of a local sum being a communication device called "buyer" to a communication device called "seller", and iii) second means coupled to the first means and capable of modi trust the representative value of the local sum in progress in response to a transaction.

In this way, the two players in a transaction each have an electronic wallet which allows them to transfer data representative of the amount of this transaction, without going through an intermediate terminal and therefore completely anonymously. The buyer can also transfer part of his account to his wallet by performing an electronic transaction with the management terminal, while the seller can transfer all or part of the content of his wallet to his account by performing a transaction with this same management terminal.

The installation according to the invention can include additional characteristics taken separately and in combination, and in particular: - each buyer communication device, at least, can be equipped with man / machine interface means, coupled to the first means, for data entry, in particular transaction;

- the first means can compare the amount of a transaction with the value of the local sum in progress, and authorize the transaction when the amount is less than this value;

- the amount of the transaction can be transmitted to the first means by the interface means, or by the seller's communication device;

- the first means, in particular buyers' devices, can compare the value of the current local sum which is stored with a first selected threshold, configurable by their user, and initiate a transaction consisting of debiting the account from a first sum associated remote, to credit the local account with this first sum when the value is less than the first threshold;

- the first means, in particular vendor devices, can compare the value of the current local sum stored with a selected second threshold, configurable by the user, and initiate a transaction consisting of debiting the associated local account for a second selected sum, to credit this second sum to the associated remote account when the value is greater than the second threshold; - at least one of the first and second sums can be either previously chosen, is determined by the first means so that the value of the current local sum is substantially equal to a chosen constant, configurable by the user. The first means can then be arranged to carry out the comparison according to a chosen periodicity or as soon as the amount exceeds a chosen sum;

- the communication devices and said management terminal can be equipped with encryption means making it possible to encrypt according to an algorithm chosen at least some of the data representative of the transaction, to be exchanged; - the first means of the buyer communication devices, at least, can be arranged so as to initiate a transaction upon receipt of a chosen auxiliary identifier;

the devices can comprise transmission / reception means coupled to the first means for exchanging data, the data exchange then taking place according to at least one channel chosen from a group comprising the wave channel, for example in the infrared or radio spectrum (according to a protocol chosen from the bluetooth and SMS protocols), and the wired channel, for example via a private and / or public type communications network; r the communication devices can be equipped with display means making it possible to display at least some of the data representative of a transaction and or the value of their local sum in progress;

- at least some of the communication devices can be fixed or portable telephones, or telecommunication terminals. In this case, some of them may include a smart card comprising the first and second means, for example of the SIM type;

- the management terminal can be connected to at least one bank terminal managing the data of remote accounts in response to transactions. In this case, at least one of the management terminal and bank terminal may include a memory storing a correspondence table between the identifier of each communication device and the representative identifier the associated remote account number.

The invention further relates to a data processing method between communication devices associated with identifiers representative of remote account numbers and a management terminal, comprising the following steps: a) storing in each communication device a value representative of 'a local sum, called' in progress', b) establish a link between a communication device called 'buyer' and a communication device called 'seller', c) transfer data representative of at least part of the sum current local stored in the buyer communication device to the seller communication device, and d) adding the value representative of the part of the local sum transferred to the value representative of the local sum stored in the seller communication device, to store in the seller device, as the current local value, the result of the addition, and subtract ire the value representative of the part of the local sum transferred from the value representative of the local sum stored in the i buyer communication device, to store in the buyer device, as the current local value, the result of the subtraction.

> The method according to the invention may include additional characteristics taken separately and in combination, and in particular:

- in step c) the transfer can be made after entering the amount of the transaction; - in step c) the amount of the transaction can be compared with the value of the local sum in progress, and authorize the transaction when the amount is less than the value;

- an additional step in which the value of the current local sum stored is compared to a first chosen, configurable threshold, and a transaction is carried out consisting of debiting the associated remote account from a first sum, to credit said local account with this first sum when said value is less than said first threshold;

- an additional step in which the value of the current local sum stored is compared to a second chosen, configurable threshold, and a transaction is carried out consisting in debiting the associated local account with a second chosen sum, to credit the remote account associated with this second sum when said value is greater than the second threshold;

- At least one of the first and second sums can be either chosen beforehand, or determined by the first means so that the value of the current local sum is substantially equal to a chosen constant, which can be configured;

- the comparison can be made periodically;

- at least some of the data exchanged, representative of the transaction, can be encrypted according to a chosen algorithm; - in step c) the transfer can be authorized when a chosen auxiliary identifier is received.

Other characteristics and advantages of the invention will become apparent on examining the detailed description below, and the appended drawings, in which: - Figure 1 schematically illustrates an example of installation of

; ^s data processing according to the invention,

FIG. 2 is a diagram illustrating the main steps of an example of an automated method for supplying a secondary account,

FIG. 3 is a diagram illustrating the main steps of an example of an automated method for supplying a local electronic purse account (PME), and

- Figure 4 is a diagram illustrating the main steps of an example of use of a buyer SME in the context of a transaction with a seller SME. The attached drawings are, for the most part, certain. In Consequently, they can not only serve to complete the invention, but also contribute to its definition, if necessary.

Firstly, reference is made to FIG. 1 to describe a nonlimiting example of a data processing installation, suitable for electronic transactions between buying customers and selling customers. More precisely, in this example, each client (or user) has a main account, managed by a banking establishment (materialized by a banking terminal 2 connected to a banking server), and a secondary account, created and managed by a management center. (materialized by a management terminal 3). Of course, provision could be made for an installation in which the management center is integrated into the banking center and therefore each user has only one main account. In another variant, a management center independent of the banking centers could be provided, and therefore each user only has a dedicated auxiliary account. The management terminal 3 and the bank server 2 are connected to a communication network, so as to be able to exchange data.

In addition, each client has an autonomous communication device (or tool) 4, such as for example a mobile telephone equipped with an infrared port and means defining an PME electronic purse 1 associated with a representative value. of a local sum in progress. More specifically, the PME 1 is defined by first means intended for carrying out transactions, on the one hand, with the management terminal 3, for transferring sums, in a controlled manner, and second means coupled to the first means and capable of modify the value of the current local sum in response to a transaction. The first and / or second means can be produced in the form of one or more software modules stored in a memory of the device 4, and / or in the form of electronic circuits. For example, these means can be stored in the SIM card of the mobile phone which then assumes the function of SME. Of course, all the communication devices 4 are not necessarily portable devices, such as a portable telephone. he could be a fixed telephone, or more generally a (tele) communication terminal connected to a public or private network.

The infrared port is coupled to the first means so as to allow the direct exchange of data representative of a transaction with another customer, or in other words to allow the electronic transfer of a sum from an SME to another SME. Of course, many other means of exchanging data between devices can be envisaged, by waves and / or by wire. Mention will be made, for example, of transmitters / receivers making it possible to exchange radion messages according to the SMS or bluetooth protocol, possibly via a communications network of the private type (Intranet or Extranet) and / or public, such as the Internet.

Each customer is subscribed to the wallet management center (in fact he subscribes to a service) and, as a result, the center includes a database in which is stored for each customer an identifier representative of his main account ( bank), an identifier representative of its secondary account, and an identifier representative of its call number (so that it can be recognized automatically when it calls, or to be contacted if necessary). <For each user subscribed to the service, the management center withdraws directly, preferably periodically and automatically, via its management terminal 3, from the user's main bank account, a sum of money whose value is stored on its secondary account, and which is used to supply the PME 1 with its communication device 4 and contributes to forming the current local sum.

As indicated above, it is possible to envisage supplying the PME 1 directly to the communication device 4 of the user by a direct link with its banking center, via the banking server 2. There is then no longer any need for a management terminal 3, independent of the bank server 2, to control the loading / unloading movements of the PME 1. Such an installation is obviously simpler to implement, but it is also less secure, because the users of PME 1 are put directly in contact with their main bank accounts.

The amount allocated by the management center to the secondary account of a user will therefore allow transfers to be made between the management terminal 3, and more precisely the secondary account associated with this user, and the local account associated with his SME. 1 in his communication device

4.

Two methods of supplying an SME 1 can be envisaged. If the procedure is automated, the first means initiate a supply procedure either periodically, for example daily or weekly, or upon detection of a crossing of a lower threshold, for example as soon as it is observed ( by comparison) that the current local sum is less than 5 francs.

If the procedure is not automated, the user joins the management center with his communication device 4 (a "key" of function, ordering a routine program can be provided for this purpose), and asks him to transfer to his SME 1 all or part of the amount available on his secondary account. This interrogation is preferably carried out by entering the desired amount by the user using the man / machine interface (or keyboard) of the communication device. Of course, it is preferable that this transfer request is secure, at least by providing a user identifier, or auxiliary identifier. It can simply be the PIN code allowing access to the functions of the communication device, or any other identifier. Once the PME 1 has been supplied, the user can carry out transactions with other users. In other words, the purchasing customer can exchange data representing sums of money directly with selling customers, electronically.

When the value of the current local sum of an SME 1 is deemed too large by the user, he can transfer all or part of his account local to his secondary account. This procedure is more particularly suited to selling customers, but it can also apply to buying customers.

The management center then takes care of transferring all or part of the amount transferred by the client's SME to his main account.

When a customer subscribes (or subscribes), the customer himself defines the conditions of use for his SME 1, according to his needs and / or possibilities. The customer specifies, for example, the maximum amount he wishes to spend each day, and / or each week, and / or each month using his PME 1, and / or the maximum amount he wishes to hold on his PME 1. He can also define secondary parameters making it possible to reinforce the security of use of his PME 1, such as for example the maximum amount authorized for each transaction.

Once the conditions of use have been set (they are preferably modifiable by the customer according to the evolution of their needs), the PME 1 becomes fully autonomous.

We now refer to FIG. 2 to describe, in more detail, an example of an automated supply procedure for an SME 1. i In this example, the supply is of periodic type. For example, at the start of each month, the management terminal 3 supplies the customer's secondary account by direct debit from their main account, here managed by a bank via the bank server 2.

Preferably, the amount of the sum withdrawn from the main account of the customer corresponds to the amount necessary to obtain in his secondary account a maximum sum, chosen by the customer, and usable monthly on his SME 1. The supply is therefore not necessarily systematic. Indeed, if the previous month, the user spent only a very small amount with his PME 1, then the value of the amount stored in the secondary account has been little or not changed. Consequently, the management terminal 3 does not replenish the secondary account. To manage the secondary account, the management terminal 3 therefore periodically checks (for example each week or each beginning of the month), the value of the sum stored in the secondary account (or available balance SD). This constitutes a step 10. Then, in a step 20, the management terminal 3 will search in its database the maximum sum SM that the client is authorized to use each month, in accordance with his request. The management terminal 3 then calculates, in a step 30, the difference SA = SM - SD which will allow it to determine whether or not there is a need to replenish the secondary account (step 40). If the difference SA is greater than a minimum sum Smini chosen, the restocking is carried out (typically Smini is of the order of a few francs). This constitutes step 50. Otherwise, the replenishment is not carried out, which constitutes step 55.

If a debit is decided, the management terminal 3 takes the difference SA directly from the client's main account. To do this, it first checks whether the main account is sufficiently funded (step 60). If this is not the case, the service is interrupted (step 65). If this is the case, the sum SA is withdrawn from the main account and credited to the secondary account so that its new value is substantially equal to SM (step 70).

Alternatively, the account could be replenished with a predetermined value, without taking into account the value of SA. Of course, this operation can only be done if the user's account is provisioned. Preferably, the other transfer operations from a main, or secondary, or even local account, to a local, or secondary, or even main account, are triggered on the order of the client who manages his SME as he wishes. the user can choose between transferring the entire amount available to his secondary account at once to his PME 1, or split his money transfers to his PME 1, in order to limit the amount of money available on his local account. In this case, the transfer request is conditioned by the balance available on the account local of his PME 1 (or local sum in progress), which can be displayed on a screen of the communication device 4.

However, certain transfers, in particular from the secondary account to the local account of PME 1 can be automated. The transfer of an amount between the different accounts of a client can be done by telephone call or by Internet, in particular. This money transfer procedure which will be detailed below, with reference to FIG. 3, is preferably secure.

In a first step 100, the client selects, in the main menu of his communication device 4, the function

"Supply" of the SME. In a step 110, the client is preferably invited by the software part of the first means of the PME 1, dedicated to managing the transactions, to enter his confidential code. It may be the PIN code of the device 4, or any other code or identifier previously stored. The code entered is then verified

(step 115). In the same way as for a bank card, if the user enters the wrong code several times in a row, the software (first means) instantly blocks the use of the PME (step 120). i After authentication of the user code, the software (first r oyens) attempts to automatically establish a telephone connection or

Internet with the management terminal 3 (step 130). As soon as the link is established, the management terminal 3 performs a certain number of control operations, including in particular:

- checking the identifier of the calling client (step 140). This involves, for example, checking the telephone number or IP address in the database. Only a communication device 4 registered in the base when joining the service can be used to make transfers. Any attempt to communicate with the management terminal 3 using an undeclared communication device results in the immediate interruption of the service (step 145); - checking the integrity of the data transmitted (step 150): for example: recognized caller, valid authorization to use the service by the caller, etc. If the transmitted data poses a problem, the provisioning procedure is interrupted (step 155). When the control operations have been carried out successfully, the client is invited by the management terminal 3 to enter the value of the sum which it wishes to transfer to its PME 1 (step 160).

The management terminal 3 checks whether this sum is compatible with the operating parameters of the PME 1, previously specified by the user (step 170). We check in particular if this value is compatible with the maximum sum usable monthly on the PME. To do this, the available balance SD is extracted from the secondary account and the difference SD-SU is calculated, SU being the amount requested by the client (step 172).

If the difference is positive, the management terminal 3 transfers the amount requested by the user from his secondary account to the local account of his PME 1 (step 180). Otherwise, the customer is asked to enter a new amount (step 185). If the client actually enters a new amount (or new value), we return to step 160. On the other hand, if the client refuses to enter a new value, he is invited to modify the supply parameters of his PME 1 ( step 190). If the customer refuses, the supply procedure is interrupted (step 200). On the other hand, if the client accepts, a procedure for modifying parameters is initiated (step 205).

The data necessary for carrying out the transfer are preferably encrypted, for example using a key algorithm, and are sent to the communication device 4 of the requesting client, either by telephone communication (for example GSM type), or via the Internet (for example according to the WAP protocol).

At the end of step 180, the management terminal 3 checks whether the transfer has taken place correctly (step 210). If the operation went well, the management terminal 3 updates the secondary account of the client, and the second means of the PME 1 update the value of the local sum (step 215). Otherwise, the supply procedure is canceled (step 220). The SME 1 supply procedure, detailed above, is reversible. The user can, by following a similar scheme, transfer all or part of the local sum associated with his PME 1, to his secondary account. According to a procedure previously defined between the client and the management center, the management terminal 3 then transfers all or part of this sum to the main account of the user. This transfer procedure is particularly suitable for selling customers.

We now refer to FIG. 4 to describe in detail a data processing procedure making it possible to carry out a direct transaction between two communication devices 4. A buying customer who wishes to carry out a transaction with a selling customer (for example to buy him bread or newspaper) selects from the main menu of its communication device 4 the "Payment" function of the PME 1 (step 300). The client is then invited by the management software (first means) of the PME 1 to enter the value of the amount to be paid (step 310). Alternatively, the value can be communicated by the seller's communication device.

The software (first means) performs a first verification loop in which it compares the value of the amount to be paid with the operating parameters set by the user: maximum amount of a transaction, cumulative amount of all transactions on a day, a week, a month, etc. (step 320).

If the value entered is incompatible with the chosen parameters, the software (first means) refuses the transaction (step 330).

If the value entered is compatible with the chosen parameters, the software (first means) checks whether it is compatible with the value of the sum local in progress (step 340).

If the current local sum is insufficient, the software (first means) offers the customer to restock his PME 1 (step 350). If the customer agrees to replenish, the software (first means) is then positioned directly on the "Supply" function (step 360) and proceeds to said supply in the manner described above with reference to Figure 3. In the case on the contrary, the software (first means) refuses the transaction (step 370).

When the current local sum makes it possible to carry out the transaction, the software (first means) performs another verification loop before starting the transfer of money to the SME 1 of the selling client (step 365).

It can be envisaged that the first means generate a message intended to be displayed on the screen of the communication device 4 and requiring the entry of the confidential code (step 375). When subscribing to the service, we can indeed offer the customer the choice of several levels of security. The user can thus decide to provide his confidential code before each transaction, or to supply his confidential code as soon as the cumulative amount of transactions carried out since the last introduction of the confidential code exceeds a chosen amount, or to never supply a confidential code before a transaction, for example.

In the same way as for a bank card, if the user repeatedly enters the wrong code, the software (first means) instantly blocks the use of PME 1 (step 380).

When the verification loops have gone well, the PME 1 is ready to transfer a sum to the SME of the selling customer.

To do this, the first means of the buyer's PME 1 attempt to establish, in collaboration with the transmitter / receiver (for example the infrared port) of the communication device 4, a connection with the first means of the PME 1 of the selling customer, via their transmitter / receiver (for example an infrared port) (step 390). As previously stated, the exchange of data between the two communication devices is preferably carried out by waves, in the infrared spectrum. However, other spectral bands can be used, such as radio waves (possibly with a protocol of the Bluetooth or SMS type). If the connection cannot be made (step 395), we return to step 390.

For example, after three unsuccessful attempts, the transaction is refused (step 397).

When the connection is established between the two PME 1s, the software (first means) managing the PME 1 of the purchasing client transfers electronically the sum corresponding to the amount of the transaction to the PME 1 of the selling client (step 400). The software (first means) of the SME 1 of the purchasing customer verifies that the money transfer has gone smoothly (step 410), then the second means of the PME 1 of the purchasing customer update the value of the local sum (step 420), while the second means of the SME 1 of the selling customer update the value of the local sum. The sum corresponding to the amount of the transaction is thus directly transferred from one communication device to another without going through an intermediary, by a simple data transfer. _$ The protocol for exchanging data, for example by infrared or radio signals, between two communicating devices (two mobile (or mobile) phones or a mobile phone and a specific terminal), is preferably carried out secure.

For example, during a data transfer corresponding to a transfer of money between two devices, any third-party device is prohibited from capturing the data and therefore from fraudulently being credited with its PME 1 wallet. two devices identify each other with each data transfer by communicating their respective identification codes. If a third device interferes with the other two, it is immediately identified by its own identification code and, for example, the data transfer is immediately interrupted. An explanatory message is then displayed on the screen of each device. In order to limit the risks of data piracy, it is preferable that the devices be equipped with a short-range transmitter / receiver, typically the data transmission power does not allow the transfer between two remote devices of more than a few tens of centimeters, and at most a few meters.

Several operating diagrams can be envisaged to secure the data transfer according to the technique used to implement the data exchange protocol between two devices.

Thus, after having “emulated” the PME 1 of its communicating device, the “purchasing” user can, for example, enter the identifier of the “seller” before initiating the transaction. The “buying” device then seeks to establish a connection with the “selling” device which responds to the required identifier. When the connection is established, the “purchasing” user specifies the amount to be paid, then transfers the data. Alternatively, the buyer can check the connection before confirming the data transfer. To do this, the user “buyer” specifies the amount to be paid and orders his device 4 to transfer certain data to the device of the “seller”. Before confirming the transaction, the “buying” device checks that the “selling” device has received the information. If necessary, the “buying” user and / or the “selling” user can confirm the transaction by entering their confidential code on their device.

The invention has been previously described in terms of data processing installation, but it can also be described in terms of data processing method between communication devices 4, associated with identifiers representative of remote account numbers, and a management terminal 3, possibly coupled to at least one banking terminal 2.

This process comprises at least the four stages described below. In a first step we store in a memory of each communication device 4 a value representative of a local sum, called "in progress". This value depends on the choice of the user of the communication device.

In a second step, a connection is established between a communication device called "buyer" and a communication device called "seller", in an attempt to carry out a direct transaction.

In a third step, all or part of the current local sum, the value of which is stored in the buyer's communication device, is transferred to the seller's communication device. In fact, the amount that is transferred is that which corresponds to the amount of the transaction.

In a fourth step we add the value of the local sum, transferred from the buyer's communication device, to the value of the local sum, stored in the seller's communication device, in order to store in its device, as new local value in progress, the result of the addition. Then, the value of the local sum transferred is subtracted from the value of the local sum stored in the buyer communication device, in order to store in the buyer's device, as new current local value, the result of the substraction. 'Preferably, the third transfer step includes a prior phase of entering the amount of the transaction. Alternatively, however, the amount could be transferred from the seller's device to the buyer's device.

Furthermore, the transfer carried out during the third step preferably includes a phase of comparing the amount of the transaction with the value of the local sum in progress, so that the transaction is only authorized when the amount is less than the stored value .

These steps can be accompanied, preceded or followed by additional steps. Thus, a local account provisioning step can be provided in which the value of the local sum in comparison with a first chosen, configurable threshold (for example when subscribing to the service) is compared. stored price, and a first sum is debited from the associated remote account (main or secondary depending on the options) to credit said local account with this first sum when the value is less than the first threshold. We can also provide a transfer step, or “load shedding” (more generally intended for local accounts of sellers although not exclusively), in which we compare to a second threshold chosen, configurable (for example when joining service), the value of the current local sum stored, then a second selected sum is debited from said associated local account, to credit this second sum for the associated remote account (secondary or main depending on the options) when the value is greater than the second threshold.

At least one of the first and second sums can be chosen beforehand, or else determined by the communication devices so that the value of the current local sum is substantially equal to a chosen, configurable constant (for example during membership in the service).

The threshold comparison steps can be performed periodically, or at the request of the user or the management terminal. _t In addition, the data transfer steps may include an encryption phase intended to reinforce the security of the transactions.

Finally, the transfer steps can be made dependent on the provision of an auxiliary identifier (or confidential code) specific to the communication device concerned.

The invention is not limited to the plant and method embodiments described above, only by way of example, but it encompasses all the variants that a person skilled in the art may envisage within the framework of the claims below.

Claims

1. Data processing installation, comprising a management terminal (3) capable of exchanging data with communication devices (4) associated with identifiers representative of remote account numbers, characterized in that each communication device (4 ) comprises a so-called “local account” memory capable of storing a value representative of a local sum, known as “in progress”, of the first means arranged to carry out transactions, on the one hand, with said management terminal (3) , to transfer data representative of sums, in a controlled manner, between the remote account, associated with the communication device (4) concerned, and the local account memory, and on the other hand, with other first means for transferring data representative of at least part of a local sum in progress from a so-called “buyer” communication device to a so-called “seller” communication device, and seconds means coupled to said first means and capable of modifying the value representative of the local sum in progress in response to a transaction.

2. Installation according to claim 1, characterized in that at least phaque buyer communication device (4) is equipped with man / machine interface means, coupled to said first means, for data entry, in particular transaction.

3. Installation according to one of claims 1 and 2, characterized in that said first means are arranged to compare the amount of a transaction with the value representative of the local sum in progress, and to authorize the transaction when said amount is less than said value.

4. Installation according to claim 1 to 3, characterized in that said amount of the transaction is transmitted to said first means by said interface means.

5. Installation according to one of claims 1 to 4, characterized in that said first means are arranged to compare with a first threshold chosen, configurable, the value representative of the current local sum stored, and to initiate a transaction consisting of debiting a first sum from the associated remote account, to credit said local account with this first sum when said value is less than said first threshold .

6. Installation according to one of claims 1 to 5, characterized in that said first means are arranged to compare to a second selected threshold, configurable, the value representative of the local sum being stored, and to initiate a transaction consisting in debit said associated local account with a second selected sum, to credit this second sum with said associated remote account when said value is greater than said second threshold.

7. Installation according to one of claims 5 and 6, characterized in that said first means are arranged to perform said comparison according to a chosen periodicity.

8. Installation according to one of claims 1 to 7, characterized in that said communication devices (4) and said management terminal (3) are equipped with own encryption means to encrypt according to an algorithm chosen at least some of the data representative of the transaction, to be changed.

9 ^* . Installation according to one of claims 2 to 8, characterized in that said first means of at least the buyer communication devices (4) are arranged to initiate a transaction upon receipt of a chosen auxiliary identifier.

10. Installation according to one of claims 1 to 9, characterized in that said communication devices (4) comprise transmission / reception means coupled to the first means for exchanging data, said data exchange taking place according to at least one path chosen from a group comprising the wave path and the wire path.

11. Installation according to one of claims 1 to 10, characterized in that said communication devices (4) are equipped with display means suitable for displaying at least some of the data representative of a transaction and / or the value of their local sum in progress.

12. Installation according to one of claims 1 to 11, characterized in that at least some of the communication devices (4) are chosen from a group comprising fixed or portable telephones and telecommunication terminals.

13. Installation according to claim 12, characterized in that at least some of the communication devices (4) comprise a smart card comprising said first and second means.

14. Installation according to one of claims 1 to 13, characterized in that said management terminal (3) is connected to at least one bank terminal (2) capable of managing the data of the remote accounts in response to transactions.

15. Installation according to one of claims 11 to 14, characterized in that at least one of said management terminal (3) and bank terminal (2) comprises a memory storing a correspondence table between the identifier of each device and the identifier representative of the associated remote account number.

16. Method for processing data between communication devices (4) associated with identifiers representative of remote account numbers and a management terminal (2), characterized in that it comprises the following steps: a. store in each communication device (4) a value representative of a local sum, called "in progress", b. establish a link between a communication device called "buyer" and a communication device called "seller", c. transfer data representative of at least part of the current local sum stored in the purchasing communication device to the selling communication device, and d. add the value representative of the part of the local sum transferred to the value representative of the local sum stored in the seller communication device, for storing in said seller device, as the current local value, the result of the addition, and subtracting the representative value of the part of the local sum transferred from the representative value of the local sum stored in the buyer communication device, for storing in said buyer device, as a current local value, the result of the subtraction.

17. The method of claim 16, characterized in that in step c) the amount of the transaction is compared to the value of the local sum in progress, and the transaction is authorized when said amount is less than said value.

18. Method according to one of claims 16 and 17, characterized in that it comprises a step in which the value of the local sum being stored stored is compared to a first selected, configurable threshold, and a consistent transaction is initiated debiting the associated remote account with a first sum, to credit said local account with this first sum when said value is less than said first threshold.

19. Method according to one of claims 16 to 18, characterized in that it comprises a step in which the value of the local sum being stored stored is compared to a second chosen, configurable threshold, and a consistent transaction is initiated debiting said associated local account with a second selected sum, to credit said associated remote account with this second sum when said value is greater than said second threshold.

20. Method according to one of claims 16 to 19, characterized in that said comparison is carried out periodically.

21. Method according to one of claims 16 to 20, characterized in that at least some of the data exchanged, representative of the transaction, are encrypted according to a chosen algorithm.

22. Method according to one of claims 16 to 21, characterized in that in step c) the transfer is authorized on receipt of a chosen auxiliary identifier.