FR2852419A1 - Electronic data file transaction process for use in distributed computer network, involves delivering data file from substitute location to destination if verification of key condition in corresponding table is true - Google Patents

Abstract

The process involves receiving a request for delivery of a data file with a chosen destination from a client device. A corresponding table with a substitute location for the client device and a key condition for the delivery of the data files from the substitute location is placed at the destination. The data file is delivered from the substitute location to the destination if the verification of key condition is true. Independent claims are also included for the following: (a) an electronic data file transaction device with an intermediary payment device (b) a readable information support of a computer system includes a set of instructions of a program allowing the implementation of electronic data file transaction process (c) a stored computer program on an information support, and including a set of instructions allowing the implementation of electronic data file transaction process.

Description

i

  The present invention relates to the processing of an electronic transaction between a client device and a server device, via an intermediate payment device equipped with a cache.

  It finds general application in electronic transactions within a computer network distributed according to a client / server or peer-to-peer architecture, and more particularly in the centralization of the processing of electronic payments at the level of a device serving as an intermediary. payment for electronic transactions implemented between client and server devices within a distributed computer network. A method of processing an electronic transaction between a client device and a server device is already known, in which an intermediate device receives on the one hand a payment emanating from the client device for carrying out the transaction, and on the other hand performs the corresponding payment to the server device at the end of the transaction.

  Such a method is relatively satisfactory insofar as it allows a client device to establish only one means of payment (the configuration of which is generally costly in computing time) with an intermediate device instead of establishing one. with each of the server devices to which he wants to pay for purchases, Similarly, such an intermediate payment device 20 allows the server devices to receive payments only from the intermediate payment device instead of receiving them from each of the client devices.

  However, such a method poses a problem when the transaction between the server device and the client device is not (or hardly) carried out after the payment operation of the client device with the intermediate device.

  This can be the case when the server device is not (or hardly) accessible, in particular when the said server device is not in operation or is not connected to the network.

  This can also be the case when the bandwidth of the connection 30 of the server device is relatively low or insignificant compared to the amount of data requested from said server device.

  The present invention precisely provides a solution to the problem of availability of server devices delivering data and / or services in a client / server or peer-to-peer communication network.

  It relates to a method for processing an electronic transaction 5 between a client device and a server device on a communication network, said method being implemented within an intermediate device of the communication network serving as a payment intermediary. for said transaction.

  According to a general definition of the invention, the method comprises, at the level of the intermediate device, the following steps: - coming from the client device, receiving a request for delivery of a data file having a chosen designation; - obtain a correspondence table between a designation of a data file, at least one substitute location thereof, and at least one key condition for the delivery of the data file from one of the 15 substitute locations; and - check whether at least one of the key conditions obtained is true, and in the event of a positive check, deliver the data file to one of the substitute locations to the client device.

  Thus, according to the method according to the invention, the intermediate device 20 acts as a cache to store selected data, which makes it possible to improve the availability of this data, for example the most requested, when the server device is out of use or low bandwidth.

  In addition, the method according to the invention makes it possible to reduce the demand on the server devices and also to reduce the response time for the client devices.

  According to one embodiment, in which the request is also accompanied by a payment amount corresponding to the delivery, the method further comprises the step in which it is planned to establish the correspondence 30 with a price associated with the delivery of said delivery. data file, to compare the amount of payment thus received with the delivery price, and in the event of a negative comparison not to deliver the data file from one of the substitute locations.

  According to another embodiment, at least one key condition is defined as a function of the frequency of requests, of obsolescence and / or of a characteristic of each data file to be delivered.

  According to yet another embodiment, at least one key condition is defined as a function of at least one characteristic of the server device.

  For example, at least one characteristic of the server device participating in the definition of a key condition is the availability of the server and / or the bandwidth of the server.

  According to another embodiment, all the key conditions obtained 10 must be verified positively so that the data file is delivered from one of the substitute locations.

  According to yet another embodiment, the correspondence table comprises at least two substitute locations respectively having at least one associated key condition and at least one key condition associated with a substitute location is not associated with at least one different substitute location.

  In practice, provision is made for maintaining and / or updating the correspondence table as a function of the frequency of requests, of obsolescence and / or of a characteristic of each data file to be delivered or as a function of server availability and / or bandwidth.

  The present invention also relates to a device for processing an electronic transaction between a client device and a server device on a communication network, said processing device being capable of being incorporated in an intermediate device of the communication network, serving as a payment intermediary for said transaction.

  According to one embodiment, the intermediate device comprises: - means for receiving a request for delivery of a data file having a chosen designation; - a correspondence table representative of a correspondence 30 between a designation of a data file, at least one substitute location thereof, and at least one key condition for the delivery of the data file from one of these alternate locations; and - processing means able to access the table, to check whether at least one of the key conditions for the delivery of the data file associated with said file thus designated is true and in the event of positive verification, to be delivered to the destination client device the data file from one of these alternate locations.

  The present invention also relates to an intermediate device comprising means suitable for implementing a treatment method as briefly described above.

  The invention also relates to an intermediate device comprising a processing device as briefly described above.

  The invention also relates to an electronic transaction system in a communications network comprising an intermediate device as briefly described above.

  The invention also relates to an information medium readable by a computer system, possibly totally or partially removable, in particular CD-ROM or magnetic medium, such as a hard disk or a floppy disk, or transmissible medium, such as an electrical or optical signal, and comprising instructions of a computer program allowing the implementation of a processing method as briefly described above, when this program is loaded and executed by a computer system.

  The invention also relates to a computer program stored on an information medium, said program comprising instructions allowing the implementation of a processing method as briefly described above, when this program is loaded and executed by a computer system.

  The advantages and specific characteristics specific to the processing devices, to the intermediate devices, to the electronic transaction system, to the information medium and to the computer program being the same as those described above concerning the processing method according to the invention , they will not be recalled here.

  Other aspects and advantages of the present invention will appear more clearly on reading the description of particular embodiments which follows, this description being given solely by way of nonlimiting example and made with reference to the appended drawings in which: - Figure 1 shows a payment system comprising an intermediate payment device without cache; - Figure 2 shows, in the form of a flowchart, the main steps implemented by an intermediate device equipped with a cover, in accordance with the present invention; FIG. 3 represents, in the form of a flowchart, the process according to which the intermediate device returns an error message, in accordance with the present invention; FIG. 4 represents, in the form of a flowchart, the process according to which the intermediate device returns a response to the client device in the presence of a valid payment in accordance with the present invention; - Figure 5 shows, in the form of a flowchart, the processing of a delivery authorization request by an intermediate device according to the present invention; FIG. 6 represents, in the form of a flowchart, the main steps for updating the correspondence table, in accordance with the present invention; and - Figure 7 schematically shows an intermediate device suitable for implementing a transaction method according to the invention.

  With reference to FIG. 1, an electronic transaction is implemented between a client device C and a server device S, via and within an intermediate IP payment device, devoid of cache.

  In the example described in FIG. 1, the client device C wishes to obtain an image I from the server device S, but the mechanism 25 used would be equivalent for another type of transaction or another type of document.

  Image I is chargeable but, as described above, payment is not made directly by the client device C for the benefit of the server device S. On the contrary, the intermediate device IP serves as a payment intermediary between the client device C and the server device S. Prior to any purchase from the server device S, the client device C sends a RAT request for transaction authorization to the intermediate IP device.

  The RAT request includes the address S of the server device S the identifier I of the image I to obtain; MP payment amount; and at least one electronic part Pj (C, IP) belonging to all of the electronic parts usable by the customer C to make a payment with the intermediate device IP.

  The reception of a transaction authorization RAT request is followed by a step during which the intermediate device IP verifies the validity of the payment associated with the transaction authorization RAT request.

  This verification is carried out, in the preferred embodiment described here, by verifying whether the at least one electronic part Pj (C, IP) contained in the authorization RAT request makes it possible to make a payment of amount MP, this amount also included in the RAT authorization request.

  Thus, if the payment is correct, the intermediate device IP returns a response containing an acknowledgment of receipt OK, signifying to the client C that it can request the image l from the server S. On the other hand, if the payment associated with the request RAT transaction authorization is not validated, the test result is negative. This test is then followed by a step during which the intermediate device IP notifies the client device C of an error.

  After sending the transaction authorization request RAT, the client device C sends to the server device S, a transaction initiation RDT request, this request comprising the identifier I of the image I to be obtained.

  On receipt of the transaction initiation RDT request, the server device S sends to the intermediate device IP a RAL request for delivery authorization of the image I to the client device C. This RAL request for delivery authorization comprises the identifier I of the image I requested by the client device and the identifier of the client C; and the payment amount MP1 requested by the server device S to supply the image I to the client device C. On receipt of this RAL request for delivery authorization, the intermediate device IP checks whether it has received a RAT request d authorization of the client device C to obtain the image I. In other words, the intermediate device IP checks whether the payment has been made by the client C for the image I. If this is the case, the intermediate device IP sends a transaction validity MVT message to the server device S, this transaction validity MVT message 5 comprising at least one part Pk (IP, S) belonging to all of the electronic parts usable by the intermediate device IP for adjusting the server device S for the MPI amount.

  On reception of the transaction validity message MVT, the server S checks the validity of the payment received from the intermediate device IP in the previous step, and transmits the image I to the client device C when this payment is validated.

  As will be seen in more detail below, when the cache of the intermediary device can be used, the response of the intermediary device IP to the client device C contains not only an acknowledgment of payment 15 OKI, but also the document or the image requested I. According to the invention, the intermediate device IP is equipped with a correspondence table TC between a designation of a data file, at least one substitute location thereof, and at least one item of information linked to a condition key for the delivery of the data file from this substitute location.

  Substitute locations are used to store cached data. For example, the data stored are images or other similar documents.

  A key condition is a test to determine if the intermediate IP device must use the alternate location for the delivery of the data file.

  For example, a key condition is that the frequency of request for a data file is greater than a minimum frequency. The intermediate IP device may use one or more key conditions to determine whether the data file should be delivered from the alternate location.

  The key condition (s) may depend on the type or characteristics of the data file. For example, for images, only one key condition linked to the frequency of request of the data file can be used, while for films two key conditions can be used, one linked to the frequency of request of the data file and the other related to the size of the data file.

  Furthermore, if the correspondence table TC contains several 5 substitute locations for the same data file, then each of these substitute locations can be associated with a different set of key conditions.

  For example, a substitute location having a relatively long access time may have a key condition comparing the frequency of request of a data file with a relatively low minimum frequency, while a second substitute location having a time of shorter access may have a key condition comparing the frequency of request for a data file with a higher minimum frequency.

  When several substitute locations exist for the same data file, the correspondence table TC includes the order of use of these substitute locations.

  In addition to the data to be kept, the correspondence table TC contains all the information necessary for the operation of a cache.

  For example, the TC table has the following structure 20 Identifier Frequency Price Validity Image image ID request FD PX VL I Image_1 5 Image_2 50 1 E 24h image_2.jpg The first column of the TC correspondence table contains the ID identifiers of each image I The identifier ID belongs to the group formed by a name, a URI type address or any other identifier of the image to be delivered.

  The second column of the table TC contains the frequency FD of requests for each image. This frequency FD can be a simple number reflecting the number of requests for this image, or can contain the date of each request or any other information giving an indication of the quantity of requests for this image. This frequency FD makes it possible to evaluate for this image a key condition linked to the frequency of requests.

  The third column of the table TC contains the price PX of each image, so that the intermediate device can check the price paid by the client device.

  The fourth column of the table TC contains the validity period VL of each image, so that the intermediary knows when he must load a new version of the corresponding image.

  Finally, the fifth column of the table TC contains the image I 10 itself. The fifth column thus forms the substitute locations of the cache intended to contain the images to be delivered.

  In practice, the first two columns are completed. The other columns are only filled in if the image is actually kept in the cache.

  The images thus preserved in the table TC can be returned to the client device C and thus avoid download requests to unavailable server devices.

  FIG. 2 represents the main steps E100 to E185 implemented by an intermediate device IP equipped with a table TC during a transaction in accordance with the present invention.

  In the preferred embodiment described here, payments are made using the PayWord system as proposed by Rivest and Shamir.

  A description of this system can be found at the Internet address http://theory.Ics.mit.edu/-rivest/RivestShamir-mpay.ps.

  This system generally consists in recursively generating, from a random number Pn and a hash function h (in English Hash function), a series of electronic parts Pn Pn-1, ... , Po by the formula P-1. = h (P1).

  This hash function has the distinction of not being reversible so that it is in practice impossible, from a number Pn-1, to find the previous number P1.

  The end P0 of the chain thus obtained is called the root coin (in English Root Coin) and makes it possible to verify the authenticity of the other coins.

  In the following description, we will adopt the notation P (M, N) to designate the series of coins used by a device M to make a payment with a device N. For example, according to this notation, the series of electronic coins P (C, IP) is a series of coins used by the client device C to make a payment with the intermediary device IP.

  During step E100, originating from the client device C, the intermediate device IP receives a transaction authorization request RAT comprising: - the address S of the server device S - the identifier I of the image I to get; - MP payment amount; and 15 - at least one piece Pj (C, IP) belonging to the set of pieces P (C, IP) usable by the client device C to make a payment with the intermediate device IP.

  In the embodiment based on the PayWord payment system, this at least one electronic piece Pj (C, IP) is such that all the 20 pieces of index strictly less than j of the set of pieces P (C, IP ) have already been validated for previous payments by the IP intermediary device.

  Step E100 is followed by step E105 during which the intermediate device extracts the payment from the RAT request. The step E105 is then followed by a step E110 during which the intermediate device 25 extracts the reference I from the image I. If no image reference I is present in the RAT request or if the payment is invalid (the parts received do not belong to all of the parts P (C, IP)), test E115 negative the intermediate device IP processes the request in a manner similar to that described with reference to FIG. 1, namely the intermediate device IP notifies the client device C of an error (step E120).

  The processing of this error message is described in more detail below with reference to FIG. 3.

  In the presence of a payment and an image reference, the intermediary device checks whether the payment is valid.

  In response to a valid payment (test E115 positive), the intermediate device IP checks whether it knows the requested image (step E125).

  In the event of positive verification, that is to say in the presence, in the table TC, of a line corresponding to the image, the intermediate device updates (step E130) the request frequency FD of the image I, by adding 1 in the second column of the line corresponding to image I. In the event of negative verification, that is to say in the absence, in table 10 TC, of a line corresponding to image 1, the intermediate device creates a new line for this image in the table TC (step E135).

  This new line contains the image ID reference and a request frequency FD with a value equal to 1.

  At this stage, the sections corresponding to the PX prices, validity period 15 VL and image I are not yet completed.

  Then (step E140), the intermediate device IP checks whether the image I is in a substitute location of the table TC.

  In practice, the intermediate device IP checks whether the fifth column of the line corresponding to the image contains data.

  In addition, if the image is cached, the intermediary checks whether the content of the cache is still valid.

  If at least one of these checks gives a negative result, the intermediate device checks (step E145) if the request frequency FD of the image is greater than or equal to a predefined minimum frequency, fmin.

  The test E145 is here an example of verification of a key condition for the delivery of image I from the substitute location of the table TC.

  If the frequency FD is less than the minimum frequency fmin, the intermediate device IP sends the client device (step E150) a response signifying that the payment has been accepted. The processing of this response is described in more detail below with reference to Figure 4.

  If on the contrary the request frequency FD of the image is greater than the minimum frequency, the intermediate device IP downloads the image I and the corresponding price PX from the server device (step E155).

  The intermediate device IP checks whether the download is successful (step E160). In practice, the intermediate device checks whether the substitute location of the corresponding table TC contains the image thus downloaded.

  If the download fails (step E165), the intermediate device 5 sends the client C a response signifying that the payment has been accepted. The processing of this response is described in more detail below with reference to FIG. 4.

  If the image is in the TC table (step E140), or if the image has been downloaded successfully (step E160), the intermediate device obtains the PX price of the image from the TC table (step E170).

  The intermediate device IP then checks whether the payment made by the customer is correct, that is to say greater than or equal to the price PX of the image (step E175). This verification is another example of verification of a key condition for the delivery of the image from the table TC.

  In the event of a negative comparison, the intermediate device IP returns an error message (step E180), the processing of which is described in detail with reference to FIG. 3.

  In the event of a positive comparison, the intermediate device IP returns the image I (step El 85) to the client device C. In practice, in addition to the image I and the price PX, the intermediate device IP also downloads the period of validity of the image.

  The period of validity can be indicated in fields reserved for this use in the protocol used to transmit the image.

  For example, the HTTP protocol proposes a header named 25 "Expires" indicating the expiry date of the content of the request.

  A server device S can refuse that the images it sells be kept in caches, either for technical reasons (a real-time graph of the stock market, an image of a web-cam type camera, etc.) , or for commercial reasons (the server device does not trust the intermediate device, or wants to retrieve information from each client device).

  In this case, during the downloading of the image, the server device indicates such a refusal of downloading to the intermediate device (via for example the protocol used) and the test E160 becomes negative.

  In practice, the server device S only provides an image against payment or against proof of payment from an intermediate device.

  However, the intermediate IP device may not wish to pay to be able to perform the cache service.

  A first solution is to set up a special downloading procedure in which the intermediate IP device sends a payment slip indicating that it acts as a cache intermediary.

  The server device S then knows that it can return the image, but that it should not wait for payment in return. This information can be useful when the server device wishes to keep accounts of the requests to which it responds and which generate a payment for it.

  A second solution is for the intermediate device to actually pay for the server device. In return, the intermediary device does not return to the server device the sum paid by the client device for which the process of FIG. 2 is running.

  This second solution has the advantage of being transparent for the server device which does not have to manage a particular processing for the intermediate devices.

  On the other hand, the intermediary device must carry out this operation with caution to be sure of recouping its costs. For example, before paying the server device, the intermediary device ensures that the client device has paid it a correct and complete payment.

  FIG. 3 describes the process returning an error message to a client device C (step E200).

  The intermediate device creates an E210 response and then adds an error message to this E220 response.

  This error message indicates the reason for the error.

  If the client device has made a valid payment (test E230), the intermediary device generates a refund (E240) and includes it in the response (E250). For example, the reimbursement of the client device is made using electronic parts P (IP, C), the payment having been collected by the intermediary device beforehand.

  This scenario can also occur during step E175 in the presence of a valid but insufficient payment.

  The response thus generated is sent by the intermediate IP device to the client device C (E260).

  FIG. 4 describes the process according to which the intermediate device returns a response to the client device (step E300) in the presence of a valid payment and in the absence of a delivery of the image from the cache.

  During step E310, the intermediate device creates a response in response to a situation in which the payment is valid and in which the intermediate device does not play the role of cache.

  During step E320, a message is added in the response thus created to signify that the payment is correct and that the client device C can download the image from the server device S instead of calling on the cache of the intermediate device .

  During step E330, the intermediate IP device sends the response thus constructed to the client device C. Then (step E340), the intermediate IP device extracts information identifying the client device in the RAT request sent by the client. This information can for example be the customer's email address.

  The intermediate device IP then creates an authorization for this client C, with the price paid and the image requested (step E350) and stores this information in a table created for this purpose (step E360).

  This authorization makes it possible to respond positively to any request from the server device asking whether the payment has been made by the client device.

  The authorization table can have the following form: 30 Customer Price paid Image requested C 5 ID The first column contains the identifier of customer C. The second column contains the price paid for the delivery of the image. The third column contains the identifier of the image thus paid for.

  FIG. 5 describes the process making it possible to return an image coming from the table TC of the intermediate device and bound for the client device C (step E400).

  During step E410, the intermediate device IP begins by collecting the payment.

  For example, the collection sets up the payment system of the PayWord type mentioned above.

  Then (step E420), the intermediate device IP creates a response, adds to it the image I obtained from the table TC (step E430) and finally returns the response containing the image to the client device (step E440).

  FIG. 6 describes the process for updating the table TC (step E500) This process makes it possible to remove from the table TC the images which are no longer necessary, in order to limit the size of the table TC.

  For example, this process is performed regularly at predefined intervals (for example daily or weekly).

  During step E505, the intermediate device begins by obtaining the identifier ID of an image I for which there is a row in the table TC.

  During step E510, the intermediate device applies a forgetting factor to the frequency.

  For example, step E510 consists in multiplying the request frequency FD associated with the image by a number less than 1. Thus, using a factor of 0.5, two requests in the previous period count as much as one request in the current period.

  Then the new value of the frequency FD of the image is compared with a predefined frequency frem called "update" (step E515). If the frequency of the FD image is lower than the frem frequency, then the image will not be kept in the TC table.

  In this case (step E520), the image is removed from the fifth column of the table TC forming a cache. Only the data corresponding to the image, its price and its period of validity are removed from the TC table. On the other hand, the identifier ID and the request frequency FD of the image are kept in the table TC.

  Then, the new value of the frequency of the image FD is compared with another predefined frequency called “suppression” fdel (step E525). If the frequency of the image FD is less than the suppression frequency fdel, then in step E530, all the data (in particular identifier ID and frequency FD) 10 of the line corresponding to the image are removed from the table TC .

  The process is repeated in a loop (steps E535, E540) until the last image contained in the table TC is processed (step E545).

  The choice of frequencies frem and fdel determines the proper functioning of the mechanism.

  If the frequency of "update" frem is equal to the minimum frequency fmin, the same limit is used to put an image in the cache or to remove it. However, in certain configurations, this can lead to continuously adding and removing an image from the table TC, since the frequency 20 for requesting this image is close to the frequency fmin. To solve this problem, it is possible to choose the frem frequency strictly lower than the fmin frequency. We thus obtain a Hysteresis principle to cache the image, the frequency must pass a certain limit, but to remove it, the frequency must go back well below this limit.

  If the frequency of "deletion" fdel is lower than the frequency of "update" frem, the frequency of deletion corresponds to a value indicating that the image has not been requested for several periods and that it is therefore not useful to keep information in relation to this image.

  A variant of this system consists in counting the number of 30 requests for an image for each period. Thus, for each image, there is a counting table containing the numbers of requests for each period. For example, the counting table has the following structure: 34 ... 54 34 The column Wn corresponds to the oldest period kept, the column W0 corresponds to the current period.

  During the update, the value of the column Wn is forgotten, while the values of the other columns are shifted to the left. The value of In practice, the tests are carried out with respect to the predefined frequencies fmin, frem and fdel. The frequency of the FD image is recalculated from this counting table. A coefficient is applied to each column, the coefficient of each column being less than or equal to the coefficient of the column to its right (thus, the coefficient of Wn is less than or equal to that of Wn-1, ...).

  Such a variant makes it possible to take account of the requests with respect to periods, for example weekly or daily, in order to maintain the table TC and if necessary delete the relatively little requested images.

  Another variant consists in using information relating to the bandwidth b (or bit rate) of the server device, this information being capable of being stored in the table TC.

  For example, this information is regularly retrieved by the intermediate IP device by an appropriate process (for example detection of the bandwidth b, verification of the value thus detected with respect to a threshold and storage in the event of positive verification).

  Thus, for each image whose request frequency FD is greater than a predetermined value, the intermediate device IP tests the response capacity of the server device S by sending it a test message. This test makes it possible to supply the intermediate device with a value b indicating the size of the bandwidth of the server device. The higher the bandwidth, the higher this value b.

  For example, the tests for putting an image in the substitute locations of the cache or removing it from said cache can then take this value b into account, for example by comparing FD / b at the frequency fmin or at the frequency frem in accordance with steps described with reference to Figure 2.

  This comparison is another example of a key condition for delivering a data file from an alternate location.

  Thus, the intermediate IP device will tend to cache more easily an image supplied by a server device having a low capacity to respond to a large demand than another image supplied by a server device having a large capacity to respond to a large demand. significant demand.

  Similarly, another variant consists in using information relating to the availability of the server device. Instead of measuring the bandwidth of the server, the intermediate IP device regularly checks whether the server device responds to its requests and how quickly it responds to requests (this mechanism uses the principle of the "ping" command which tests the availability of 'a computer in a network).

  This variant is yet another example of a key condition for the delivery of a data file from a substitute location.

  FIG. 7 schematically represents an intermediate payment device suitable for implementing a processing method in accordance with the present invention, in a preferred embodiment.

  This intermediate processing device can in particular be constituted by a computer.

  In the embodiment described here, the intermediate payment device comprises a communication card 807 for connecting the intermediate device to a communication network, a keyboard 810, a screen 809, connected to an input-output port 803 d 'an 801 treatment card.

  The processing card 801 comprises, linked together by an address and data bus 802: - a central processing unit 800 - a random access memory RAM 804; - ROM 805 read only memory; - a non-volatile FLASH memory 806 and - the input-output port 803.

  Each of the elements illustrated in FIG. 7 is well known to those skilled in the art of microcomputers and, more generally, information processing systems. These common elements are therefore not described here.

  The random access memory 804 comprises in particular: a REQUESTED register for storing any type of request received from the client device C or from the server device S, namely in particular a request for transaction authorization RAT and a request RAL for delivery authorization; a MESSAGE register for storing, prior to their sending, the messages intended for the client device C and the server device S and in particular the MVT messages of validity of the transaction and of acknowledgment of receipt of the OKI payment.

  The non-volatile memory FLASH 806 comprises registers for storing, in accordance with the PayWord payment system, the root piece P0 15 and the last piece validly received or issued Pi, for the series of pieces P (C, IP), P (IP, C) and P (IP, S), respectively used for: - payments made by the client device C for the benefit of the intermediate device IP; - the reimbursements made by the intermediate IP device to the benefit of the client device C in the event of cancellation of the transaction; and - the payments made by the intermediate IP device for the benefit of the server device S in the event of validation of the transaction.

  The read-only memory 805 is adapted to keep the operating program of the central processing unit 800. It notably comprises a "Program" register for storing the instructions of a program implementing a processing method according to the invention , as described above with reference to the flowcharts in Figures 2 to 6.

  For example, the correspondence table TC, the counting table and the authorization table are stored in the RAM memory of the computer. These 30 tables can be stored in any other storage means of the intermediate device.

  The processing device comprises conventional communication means known to those skilled in the art, adapted to communicate, by means of requests and messages with other devices of the communication network.

  These communication means are in particular constituted by the communication card 807 and portions of computer code stored in the ROM read-only memory 805 implementing conventional protocol layers such as TCP / IP for example.

  Anyway these means of communication constitute means of reception adapted to receive and / or send requests and / or 10 RAT, RAL, OK, and MVT messages.

  The communication means are in particular suitable for recognizing the type of a request received and for extracting the different fields therefrom.

Claims (22)

  1. Method for processing an electronic transaction between a client device 5 (C) and a server device (S) on a communication network, said processing method being implemented within an intermediate device (IP) of the communication network serving as a payment intermediary for said transaction, characterized in that it comprises the following steps: - from the client device (C), receiving a delivery request (RAT) from a data file ( 1) having a chosen designation (ID); - obtain a correspondence table (TC) between a designation of a data file (ID), at least one substitute location thereof, and at least one key condition for the delivery of the data file from the one of the substitute locations - check if at least one of the key conditions obtained is true, and in the event of a positive verification, deliver the data file (1) to one of the locations to the client device (C) substitutes.   2. Method according to claim 1, in which the request (RAT) is further accompanied by a payment amount (MP) corresponding to the delivery, characterized in that the method further comprises the step in which it is planned to establish the correspondence with a price associated with the delivery (PX) of said data file, to compare the amount of payment (MP) thus received with the price (PX) of delivery, and in case of negative comparison not deliver the data file (1) from one of the alternate locations.   3. Processing method according to claim 1 or claim 2, characterized in that at least one key condition is defined as a function of the frequency of requests, of obsolescence and / or of a characteristic of each file of data to be delivered.   4. Processing method according to one of claims 1 to 3, characterized in that at least one key condition is defined as a function of at least one characteristic of the server device.   5. Processing method according to claim 4, characterized in that at least one characteristic of the server device participating in the definition of a key condition is the availability of the server and / or the bandwidth (b) of the server.   6. Method according to one of claims 1 to 5, in which all the 10 key conditions obtained must be verified positively so that the data file (1) is delivered from one of the substitute locations 7. Processing method according to one of claims 1 to 6, characterized in that the correspondence table (TC) comprises at least two substitute locations having respectively at least one associated key condition and in that at least one condition key associated with a substitute location is not associated with at least one different substitute location.   8. Processing method according to one of claims 1 to 7, characterized in that it is planned to maintain and / or update the correspondence table (TC) according to the frequency of requests, the obsolescence and / or of a characteristic of each data file to be delivered or according to the availability and / or the bandwidth (b) of the server.   9. Device for processing an electronic transaction between a client device (C) and a server device (S) on a communication network, said processing device being capable of being incorporated into an intermediate device (IP) of the network. communication and characterized in that it comprises: means for receiving a request (RAT) for delivery of a data file having a chosen designation (ID); - a correspondence table (TC) representative of a correspondence between a designation (ID) of a data file (1), at least one substitute location thereof, and at least one key condition for the delivery of the file of data from one of these substitute locations and - processing means able to access the table (TC), to check whether at least one of the key conditions for the delivery of the data file 5 associated with said file thus designated is true and in the event of a positive verification, to deliver the data file from one of these substitute locations to the client device.   10. Processing device according to claim 9, characterized in that said correspondence table (TC) further comprises an indication relating to the price (PX) associated with the delivery of said data file, in that the reception means are capable of receiving a request (RAT) accompanied by a payment amount (MP) corresponding to the delivery, and in that the processing means are able to compare the amount of payment (MP) thus received with the price (PX ) of delivery, and in case of negative comparison not to deliver the data file (1) from the substitute location.   11. Treatment device according to claim 9 or claim 10, characterized in that at least one key condition is defined as a function of the frequency of requests (FD), obsolescence and / or a characteristic of each data file to be delivered.   12. Processing device according to one of claims 9 to 11, characterized in that at least one characteristic of the server device participating in the definition of a key condition is the availability of the server and / or the bandwidth (b ) from the server.   13. Processing device according to claim 12, characterized in that the processing means comprise detection means able to detect the bandwidth (b) of the server device (S).   14. Processing device according to one of claims 9 to 13, in which all the key conditions obtained must be verified positively so that the data file (1) is delivered from one of the substitute locations.   15. Device according to one of claims 9 to 14, characterized in that the correspondence table (TC) comprises at least two substitute locations respectively having at least one associated key condition and in that at least one key condition associated with an alternate location is not associated with at least one separate alternate location. 10 16. Treatment device according to one of claims 9 to 15, characterized in that the treatment means comprise means for maintaining and / or updating the correspondence table (TC) as a function of the frequency of requests, obsolescence and / or a characteristic of each data file to be delivered or depending on the availability and / or the bandwidth (b) of the server.   17. Processing device according to one of claims 9 to 16, characterized in that the processing means comprise filling means 20 capable of downloading the data file to be delivered (1) from the server device (S) and to one of the corresponding substitute locations.   18. Intermediate device characterized in that it comprises means suitable for implementing a treatment method according to any one of claims 1 to 8.   19. Intermediate device characterized in that it comprises a treatment device according to any one of claims 9 to 17.   20. Electronic transaction system in a communication network characterized in that it comprises an intermediate device according to claim 18 or claim 19.   21. Information medium readable by a computer system, possibly totally or partially removable, in particular CD-ROM or magnetic medium, such as a hard disk or a floppy disk, or transmissible medium, such as an electrical or optical signal, characterized in that it includes instructions 5 of a computer program allowing the implementation of a processing method according to any one of claims 1 to 8, when this program is loaded and executed by a computer system.   22. Computer program stored on an information medium, said program comprising instructions allowing the implementation of a processing method according to any one of claims 1 to 8, when this program is loaded and executed by a computer system.