FR2819960A1 - Method for undoing from one customer station a server operation initiated by another station, comprises calculation of undoing cost and return to initiating station of annulling payment less cost - Google Patents

Abstract

An undoing request (E1) is received from a station (Ua) and execution is checked (E3). The station calling for undoing is identified (E5) and the undoing cost and execution payment (Ca,Pa) are obtained (E6,E7). The identity of the station (Up) which initiated the original operation is established (E18) and a balance (M) for repayment is calculated (E19). After an iterative process the repayments are made (E27) : Independent claims are made for equipment and communication systems used by the method.

Description

<Desc / Clms Page number 1>

 The present invention relates to a method for canceling an operation executed remotely on a server station.

 Today, more and more computers work on a network and use services provided by other computers. Thus, it is common on a communication network for a client station, connected via the network to one or more server stations, to use the services of one of the server stations.

 These services can for example be the remote execution of an operation or a function on a computer object hosted on the server station. For example, the client station can use the services provided by the server station to manipulate an image remotely.

 These services can also be the provision of a document by the server station.

 Generally, on a communication network, these services provided by the server stations are remunerated and billed to each client station.

 Thus, each operation is associated with an execution cost stored on the server station. During the execution of each of these operations, the latter are billed on the fly to the client station, that is to say as and when these operations are carried out.

 The invention relates more particularly to the cancellation of an operation executed remotely on a server station.

 The cancellation of such an operation (in English "undo") makes it possible to cancel the effects of a function executed remotely.

 Indeed, it is not uncommon for a user to wish to return to a starting point on a manipulated object, for example after an unfortunate manipulation of the object.

<Desc / Clms Page number 2>

 It is also common for a user to use a successive key to modify an object such as an image, and regularly go back to remove certain undesirable effects.

 We know for example the Adobe Photoshopo software which processes a digital photograph and successively applies various digital filters to find the most suitable filter.

 This possibility of going back and canceling an operation is unanimously acclaimed and generally incorporated into most software on the market.

 The object of the present invention is to maintain this cancellation function in a system in which the services provided by the server stations are remunerated and billed to a client station on the network.

 It allows in particular to cancel functions in a collaborative environment in which several client stations have access to the services of a server station.

 To this end, the cancellation method aimed at by the invention makes it possible to remotely cancel a function executed by a first client station on a computer object stored on a server station of a communication network, the execution of the function being adapted to manipulate the object from a previous state to a manipulated state.

fonction, émise par une station client du réseau de communication ; obtention dudit état antérieur de l'objet manipulé ; et envoi d'une réponse à la première station client via le réseau de communication, ladite réponse comprenant une somme de monnaie électronique au plus égale à un coût d'exécution associé à ladite fonction. According to the invention, this cancellation method comprises the following steps: - reception of a request to cancel the execution of a

function, issued by a client station of the communication network; obtaining said previous state of the object handled; and sending a response to the first client station via the communication network, said response comprising an amount of electronic money at most equal to an execution cost associated with said function.

 The cancellation method according to the invention allows a client station to cancel an operation carried out previously and to reimburse at least part of the costs incurred for this execution to the client station of the network having requested the execution of the function.

<Desc / Clms Page number 3>

 Thus, the user can be compensated for the costs incurred for the execution of a remote function when it is canceled.

 In addition, sending the response allows the first client station to be informed of the cancellation of the function previously executed on its request.

 According to a preferred characteristic of the invention, in the sending step, the sum of electronic money is less than or equal to an amount collected by the server station for the execution of said function.

 Thus, a reimbursement amount is determined from the amount actually received by the server station for the execution of the function, which may notably include possible discounts on the cost of performing the function.

 According to another advantageous characteristic of the invention, the sum of electronic money is strictly less than said amount received.

 Thus, the reimbursement is partial.

 Although a full refund is obviously more interesting for the user, the latter would risk abusing the function of cancellation of operations in such a case.

 Partial reimbursement thus forces users to use the function of canceling a function more sparingly, while still allowing them to correct any handling errors.

 According to another preferred characteristic of the invention, this cancellation method further comprises a step of calculating a cancellation cost associated with the cancellation request received, the sum of electronic money being calculated after deduction of the cost d 'cancellation.

 Thus, the cancellation function can itself be chargeable like the other functions executable remotely on the server station.

 This cost of executing the cancellation function, or cancellation cost, is thus deducted from the amount to be reimbursed.

 According to another preferred characteristic of the invention, the cancellation method further comprises a step of generating electronic money on said server station, associated with said first client station.

<Desc / Clms Page number 4>

 Thus, the server station generates its own electronic money to reimburse the client station that required the execution of the canceled function.

 In practice, when the remuneration for each operation executed is achieved by means of electronic money generated by the client station, it is not possible to cancel this payment by returning the money received.

 Indeed, there is no guarantee to the client station that the server station will not keep a copy of the electronic coins reimbursed for fraudulent use.

 The generation of an electronic money suitable for reimbursement solves this problem.

 According to a preferred characteristic of the invention, the cancellation method comprises a step of receiving a request to cancel the execution of a function, sent by a second client station of the communication network, this request for cancellation comprising an amount of electronic money, and a step of sending a second response to the second client station via the communication network, the second response comprising an amount of electronic money at most equal to the amount of electronic money included in the cancellation request.

 For each request for cancellation of a function, it is possible to identify the client station having requested the prior execution of the function so that the sum of electronic money corresponding to the at least partial reimbursement of the execution cost is effectively sent to the client station that requested the execution of the function.

 Thus, when the client station requesting the cancellation of a function is different from the client station having requested its execution, the server station sends two responses: a first response to the first client station having requested the execution of the function, in which a reimbursement amount is included, and a second response to the second client station, having requested the cancellation of the function.

 This second response may include an amount of electronic money equal to the amount of electronic money included in the cancellation request, in which case the cancellation of the function does not cost the second

<Desc / Clms Page number 5>

 client station. It can also be strictly lower than the sum of electronic money included in the cancellation request, in which case a certain cancellation cost is borne by the second client station of the communication network.

 In practice, the cancellation method comprises a step of calculating a cancellation cost associated with the cancellation request received from the second client station of the communication network, and, in the step of sending the second answer, the sum of electronic money is calculated by deducting said cancellation cost from the sum of electronic money included in the cancellation request.

 Thus, a cancellation cost is also borne by the user requesting the cancellation of the execution of a function. This prevents a user of the communication network from too frequently canceling functions previously performed by other users of the communication network.

 In practice, a cancellation cost can be invoiced both to the first client station, having requested and paid for the execution of the function, and to the second client station, having requested the cancellation of the function. Cancellation fees can thus be shared between the different users of the communication network.

 Correlatively, the present invention relates to a device for canceling a function executed by a first client station on a computer object stored on a server station of a communication network, the execution of the function being adapted to handle said object d 'a previous state towards a manipulated state.

 This cancellation device comprises: - means for receiving a request to cancel the execution of a function, sent by a client station of the communication network; means for obtaining said previous state of the manipulated object; and

<Desc / Clms Page number 6>

 means for sending a response to said first client station via the communication network, said response comprising a sum of money at most equal to an execution cost associated with said function.

 This operation cancellation device, incorporated in a server station, has characteristics and advantages similar to those described above for the method of canceling an operation on a server station.

 The present invention also relates to a server station suitable for implementing the method for canceling an operation according to the invention.

 It also relates to a computer and a communication network suitable for implementing the method of canceling an operation according to the invention.

 Finally, the present invention relates to a computer program, readable by a microprocessor, comprising portions of software code adapted to implement the method of canceling an operation according to the invention when the computer program is loaded. on a microprocessor.

 This communication network, this computer, this server station and the computer program have characteristics and advantages similar to those described above.

 Other features and advantages of the invention will appear in the description below.

 In the appended drawings, given by way of nonlimiting examples: - Figure 1 is a block diagram illustrating a client station and a server station of a communication network adapted to implement the method of canceling a compliant operation to the invention; - Figure 2 is a block diagram illustrating a computer adapted to implement the invention; - Figure 3 is an algorithm illustrating the method of canceling an operation implemented on a server station according to an embodiment of the invention;

<Desc / Clms Page number 7>

 - Figure 4 is an algorithm detailing the procedure for calculating a cancellation cost used in Figure 3; - Figure 5 is an algorithm detailing the procedure for calculating an amount to be reimbursed used in Figure 3; - Figure 6 is an algorithm detailing the procedure for sending a refund used in Figure 3; - Figure 7 is an algorithm detailing the procedure for obtaining a sum of money used in Figure 6; - Figure 8 is an algorithm illustrating a method of canceling at a distance an operation implemented on a client station; - Figure 9 is an algorithm detailing the procedure for obtaining an execution cost of an operation used in Figure 8; and FIG. 10 is an algorithm illustrating a procedure for processing a bill of exchange implemented on a client station.

 We will first describe, with reference to Figure 1, a communication network adapted to implement the method of canceling an operation according to the invention.

 In the following, we consider a client station U connected to a server station H. Of course, in a communication network, the different computers on the network can be in turn client station U or server station H.

 In addition, in a communication network, several client stations are actually connected to each server station H.

 In this example, the client station U can use the services of the server station H. In particular, the client station U can request the execution of an operation directly on the server station H.

 Each operation corresponds to a series of instructions from a computer program.

 Of course, the client station U could also request other services from the server station H, for example the supply of a document.

<Desc / Clms Page number 8>

 For example, and in no way limiting, the server station can host digital images, and a user can, through the client station U, perform operations on one of the images of the server station H.

 The operations can be the conversion of an image into black and white, the rotation of the image or a symmetry with respect to a horizontal or vertical axis of the image.

 During a remote execution of such an operation, the image will be constantly stored on the server station H and will not pass over the communication network. The client station will simply send a request for remote execution of the operation to the server station.

 We will consider in the following description, an object-oriented distributed system (in English "distributed object system"). A computer object is an element comprising data, also called attributes, and functions (in English "functions" or "methods") possibly using parameters ("input arguments" in English). In such a system, functions can be called or invoked (in English "invoked") to manipulate the data of the object.

 The set of functions applicable to an object and attributes constitutes its interface.

 In practice, the client station U comprises means of execution and payment 10 for the execution of a remote function f on an object o stored on the server station H.

 These means do not need to be described in detail here for the remainder of the description of the invention.

 For the implementation of the invention, the client station U comprises means 11 for sending a request to cancel a function f previously executed on the server station H.

 As will be well described below, this function f to be canceled may have been executed on request from any client station of the communication network.

 It also includes means 12 for receiving a reimbursement amount returned by a server station H.

<Desc / Clms Page number 9>

 Validation and collection means 13 of the amount received make it possible to validate the reimbursement amount returned by the server station H.

 In particular, storage means 14 make it possible to store bills of exchange making it possible to authenticate the amount of reimbursement received.

 The implementation of these different means will be explained in detail with reference to FIGS. 6 to 8.

 Correlatively, the server station H comprises execution and remuneration means 20 for executing functions following the reception of an execution request sent by a client station U.

 These execution and payment means 20 cooperate with the execution request and payment means 10 of the client station U so as to execute and invoice each function f on a computer object o.

 These execution and remuneration means 20 cooperate with storage means 29 making it possible to memorize the identity of each client station Up of the communication network in association with each function f executed at the request of this client station Up.

 It also includes means 21 for receiving a request to cancel a function f and means 22 for canceling this function f making it possible to return to a state of the object o preceding the execution of this function f .

 In this embodiment, storage means 23 make it possible to store the amount received Cf by the server station H for the execution of each function f. These storage means 23 cooperate with calculation means 24 making it possible to read and calculate the amount of reimbursement.

 These obtaining means 24 also comprise methods for calculating a cancellation cost and means for comparing the number of cancellation requests received, stored in a cancellation table 28, with a predetermined threshold value.

<Desc / Clms Page number 10>

 Obtaining means 25 make it possible to obtain a sum of money S corresponding to the reimbursement amount.

 These obtaining means 25 cooperate with parts storage means 26 so as to collect a sufficient number of parts, and at least equal to the reimbursement amount associated with the function to be canceled.

 Sending means 27 make it possible to send the reimbursement amount to each client station.

 The operation of all of these means making it possible to reimburse a client station during the cancellation of the execution of a function f will be explained later with reference to Figures 3 and following.

 All of these means 10-14 and 20-29 can be incorporated both at a client station U and at the server station H in a computer as shown in FIG. 2.

 This computer conventionally comprises a microprocessor 30, a read only memory 31 (Read Only Memory or ROM) and a random access memory 32 (Random Access Memory or RAM) comprising different registers for implementing the method according to the invention.

 The computer includes in particular a communication interface 39 which can be connected to a communication network 3 to receive or transfer requests or information.

 In addition, the computer includes document storage means, such as a hard disk 36, or is adapted to cooperate by means of a disk drive 37 with removable storage means 38 such as floppy disks, disks compacts or computer cards (PC Cards).

 These fixed or removable storage means may include the code of the process for carrying out operations in accordance with the invention which, once read by the microprocessor 30, will be stored in the hard disk 36.

 As a variant, the program allowing the device to implement the invention may be stored in the read-only memory 31.

 In the second variant, the program can be received to be stored as described above via the communication network 3.

<Desc / Clms Page number 11>

 Conventionally, the computer also has a screen 33 allowing for example to serve as an interface with an operator using a keyboard 34 or a mouse 35 or any other means.

 The central unit or microprocessor 30 (CPU) will execute instructions relating to the implementation of the invention.

 During power-up, the programs and methods relating to the invention, stored in a non-volatile memory, for example read-only memory 31, are transferred to the random access memory 32 which will then contain the executable code of the invention as well as the variables necessary for the implementation of the invention.

 Thus, the random access memory 32 incorporated in a client station of a communication network will include registers 14 for storing in particular the bills of exchange issued by each server station H.

 Likewise, the random access memory 32 incorporated in a server station of a communication network will include registers for storing at least one table of parts 26, the amount received 23 for the execution of each function, the identity 29 of the station client associated with the execution of each function and a cancellation table 28.

 A communication bus 40 allows communication between the different sub-elements of the computer or linked to it.

 The representation of the bus is not limiting and in particular the microprocessor is capable of communicating instructions to any sub-element directly or through another sub-element.

 We will now describe, with reference to FIG. 3, the method for canceling an operation as it is implemented on the server station H of the communication network, according to a preferred embodiment of the invention.

 The method for canceling an operation firstly comprises a step E1 of receiving a request to cancel the execution of an operation.

 This cancellation request is issued by a first client station UA of the communication network.

<Desc / Clms Page number 12>

 It is recalled here that each computer object o is written in a programming language used by the computer application specific to the computer which hosts o and that it is therefore necessary to use a communication language common to the communication network in order to to share computer objects and in particular to remotely call functions on these objects o.

 On the Internet, you can use a communication language such as XML ("eXtended Markup Language" in English).

 The use of this communication language, making it possible to describe computer objects on the network and remotely invoke functions on these objects, is described in detail in European patent application 00 401 754.7 filed by Canon Research Center France S. A.

 We recall below the description of the different data fields which it is necessary to translate into the network communication language in order to remotely invoke functions on o objects.

Field: interfaces
This field allows you to send multiple interfaces to remote applications.

<interfaces><interface> ... </ interface></interfaces>
Field: interface
This field corresponds to the generic concept of an object class, as defined in the JAVA or C ++ languages.

 An interface describes the operations or functions which are supported by a computer object o.

 These operations generally use parameters and possibly provide a result.

 An interface also describes the attributes or data field that all objects supporting this interface contain when they are translated into the communication language.

<Desc / Clms Page number 13>

 An interface can also contain a reference to other interfaces, either that they extend to these other interfaces or only provide a shortcut (in English "short hand") to use these other interfaces. The object then supports all of these other referenced interfaces.

Field: attribute
This field contains the list of attributes that an object supporting the interface contains when it is translated into the communication language.

Field: functions
This field contains the list of functions or operations associated with the IT object supporting this interface.

<functions><function> ... </ function></functions>
Field: function
This field corresponds to the generic concept of function. A function is identified by its signature, for example a name, the type of parameter used and the type of object obtained during the execution of this function.

Field: arguments
This field contains the list of parameters (in English "input arguments") that a function needs for its implementation.

<arguments><arg> ... </ arg></arguments>
Field: argument
This field corresponds to a parameter of a function and can for example be a literal object or a complex object.

 The function field thus makes it possible to invoke a function on a remote object. We must specify the target object 0 and the parameters of the function as described above.

<Desc / Clms Page number 14>

According to the invention, the function field makes it possible to invoke the "cancel" function on a remote object o.

 The name of the function to cancel is included in the argument field of the "cancel" function.

 An extraction step E2 makes it possible to extract the identity of an operation which is here a function f executed on an object o.

 A test step E3 makes it possible to check whether this function f has already been executed on the object o on the server station H following an execution request sent by a client station U of the communication network.

 If not, the server station H sends back in a sending step E9 to the first client station UA a response signaling the impossibility of canceling an operation f not executed.

 If the operation f has already been executed, in a step of obtaining E4, the list of functions to be canceled is obtained.

 Indeed, if this function f is not the last function executed on the object o on the server station, the obtaining step E4 makes it possible to obtain the list of operations executed after the execution of this operation f at to cancel.

 Of course, if the function f to be canceled is the last function executed, this list is restricted to this single function f.

 An obtaining step E5 is implemented to obtain the identity of the client station UA, generally incorporated in the request to cancel the execution of an operation.

 A step of obtaining E6 is then implemented in order to obtain a cancellation cost CA.

 Indeed, as described later, the amount of the reimbursement made upon the cancellation of a function is calculated from an amount received and preferably takes into account a CA cancellation cost.

 Indeed, a full refund, corresponding to the amount actually received for the execution of the function is more attractive for each user of the communication network, but risks overloading the server station H.

<Desc / Clms Page number 15>

 Since the canceled operations cost the users nothing, they risk abusing them. On the other hand, a partial refund forces users to be more parsimonious in the use of the cancellation function while allowing them to correct any manipulation errors despite everything.

 Thus, in other words, the cancellation function is itself chargeable like the other functions executable remotely on the server station H.

 We can thus calculate a CA cancellation cost associated with each cancellation request.

 An example of calculation will be described below with reference to FIG. 4.

 Preferably, the server station will apply a declining scale so that each new cancellation will be reimbursed a little less than the previous one.

 In practice, the cancellation cost CA will be increased with each new cancellation request received by the server station H and sent by the same client station UA of the communication network.

 Preferably also this declining scale will not come into place immediately. Each client station U will benefit from a certain cancellation "credit" so that the cancellation cost will be zero if the number of cancellation requests n sent by the client station U remains below a prefixed threshold value T .

 The procedure for calculating the cancellation cost CA will be described in an exemplary embodiment with reference to FIG. 4.

 An initialization step E401 firstly makes it possible to initialize the value of the cancellation cost CA at zero.

 Then, a step of obtaining E402 makes it possible to obtain the identity of the client station U having sent a request for cancellation of a function.

 A test step E403 makes it possible to check whether this client station U is known to the server station S.

<Desc / Clms Page number 16>

 If not, an addition step E404 makes it possible to store in a cancellation table 28 the identity of this client station U in association with the number of cancellation requests n sent by this client station U, initialized here at value 0.

 A reading step E405 makes it possible to read from the cancellation table 28, after the adding step E404 or directly after the testing step E403 if the client station U is known, the number of cancellations n carried out previously for client station U.

 A obtaining step E406 makes it possible to obtain the function to be canceled F requested by the client station U.

 It is then checked in a test step E407 if the number of cancellations n is greater than or equal to a prefixed threshold value T, for example equal to 20.

 If not, that is to say if the number of cancellations n emitted by the client station U remains strictly less than this threshold value T, a step of updating the number of cancellations E411 is implemented so that the number of cancellations n is incremented by one.

 Otherwise, if at the end of the test step E407, the number of cancellations n is greater than or equal to the threshold value T, a step of obtaining E408 makes it possible to obtain from the storage means 23 the amount received CF for the execution of function F to be canceled.

 A calculation step E409 then makes it possible to calculate the unit cancellation cost C for this function to be canceled F.

 In practice, this cancellation cost C represents a fraction of the amount received CF.

Here, by way of nonlimiting example, the cancellation cost C is calculated by the following formula:

The value of the cancellation cost C can thus vary between 0 and CFxt. The parameter t thus represents the maximum reimbursable rate of the execution cost perceived for the execution of the function to be canceled.

<Desc / Clms Page number 17>

 The larger the parameter D, the more slowly the cancellation cost C varies.

 In fact, when n-T = D, the cancellation cost C is equal to half the maximum reimbursement value CF x t.

An update step E410 of the value of the cancellation cost CA is then implemented so that:

The unit cancellation cost associated with the cancellation of the function F is thus added to the overall cancellation cost CA.

 The updating step E411 described previously is then implemented so that the number of cancellations n is incremented by one.

 A test step E412 makes it possible to check whether another function must be canceled in the list of functions obtained previously in the step of obtaining E4.

 Indeed, the cancellation of a function may require, as described above, the cancellation of other functions executed subsequently to the function F to be canceled.

 If so, in a step E413 the following function F to be canceled is obtained and the set of steps E407 to E412 described above is repeated for this.

 When all the functions to be canceled have been processed, and thus each unit cost C associated with each function F has been calculated and added to each other, an update step E414 makes it possible to update in the table of cancellation 28 the cancellation number n associated with the client station U having requested the cancellation of a function.

 A response step E415 makes it possible to address the calculated value of the cancellation cost CA for the rest of the implementation of the cancellation method as illustrated in FIG. 3.

 Returning to FIG. 3, an extraction step E7 is then implemented in order to extract a payment PA included in the cancellation request sent by the client station UA.

<Desc / Clms Page number 18>

 Indeed, as described above, the cancellation function is preferably a paid function, at least from a certain number of cancellations requested by the client station, so that a PA payment must be included in the cancellation request for the execution of this cancellation.

 This payment can be made by entering an amount of electronic money in the cancellation request.

 A test step E8 makes it possible to compare the value of the cancellation cost CA obtained in step E6 with the value of the payment PA extracted in step E7.

 If the payment value PA is strictly less than the cancellation cost CA, an error message is returned in a response step E9 in order to signal to the client station UA the impossibility of canceling the requested function F .

 Otherwise, when the cancellation cost CA is less than or equal to the value of the payment PA, the following steps E10 to E27 are implemented in order to determine the amount of the reimbursements to be made and the client stations U of the communication network to be reimbursed. and in order to carry out the actual cancellation of the functions identified in step E4.

 When canceling a function F on the server station H, it is fair to reimburse the client station that requested the execution of this function and thus paid for its execution.

 In practice, an initialization step E10 makes it possible to initialize a reimbursement table R.

 This reimbursement table R makes it possible to associate with each client station U of the network, a sum S corresponding to a reimbursement amount to be returned to this client station U.

 An EU update step makes it possible first of all to add to the reimbursement table R the sum to be reimbursed to the first client station UA having requested the cancellation of a function.

<Desc / Clms Page number 19>

 In practice, the identity of the station UA is stored and a sum S = PA-CA thus corresponding to the payment received PA from the client station UA from which the cancellation cost CA calculated previously is deducted.

 A selection step E12 then makes it possible to select the last function executed in the list obtained in the obtaining step E4.

 In a test step E13, it is checked whether this function is invertible, that is to say whether there is an inverse function making it possible to return to a previous state on the object o.

 As an example of an invertible function, one can cite when manipulating an image a rotation of the image by a quarter turn to the right, whose inverse function is the rotation of the image by a quarter turn left, a symmetry with respect to an axis, the inverse function of which is the function itself, and / or an enlargement function of a predetermined ratio, the inverse function of which is the image reduction function of the same ratio.

 In the case where this function is invertible, its inverse function is obtained in a step of obtaining E14 and then, in a step E15, this inverse function is applied to the object o to be handled.

 Otherwise, if the function is not invertible, in a step E16, the previous state is obtained which was memorized during the execution of the function to be canceled, and this previous state is applied in a step E17.

 Indeed, it is then necessary to memorize the state of the system before each execution of each function and to return to this previous state during the cancellation.

 This is the case in particular of the functions making it possible to transform an image into black and white, to apply filters making it possible to blur or even to accentuate the details of an image.

 For example, the PhotoShop software keeps in memory each successive version of an image in order to allow the cancellation of any of the operations performed.

 These two mechanisms for canceling an operation are well known to those skilled in the art and will not be described in more detail here.

<Desc / Clms Page number 20>

 The identity of the client station Up having requested, and thus paid for, the execution of the previously canceled function is then obtained in a step E18.

 A calculation step E19, detailed in FIG. 5, makes it possible to calculate an amount M to be reimbursed to this client station Up for the cancellation of this function.

 This reimbursement calculation procedure M will be described in an exemplary embodiment with reference to FIG. 5.

 An obtaining step E501 makes it possible to obtain the identity of the client station U having executed and paid for the function to be canceled.

 A test step E502 makes it possible to check whether this client station U is known to the server station S.

 If not, an adding step E503 makes it possible to store in a cancellation table 28 this client station U in association with the number m of requests for execution of functions which are then canceled, sent by this client station U. This number m is initialized here to the value 0.

 A reading step E504 allows, after the adding step E503 or directly after the testing step E502 if the client station U is known, to read from the cancellation table 28 the number of function executions then canceled m previously performed by the client station U.

 A reading step E505 makes it possible to read in the storage means 23 the amount received CF during the execution of the function.

 Indeed, for each function, an execution cost c is associated and generally stored in the interface of the object o.

 However, the amount actually received CF by the server station H may be less than this execution cost c, in particular when the server station applies discounts.

 The reimbursement amount M will therefore always be less than or equal to the execution cost c associated with the function, and in particular less than or equal to the amount actually received CF during the execution of this function by the server station.

<Desc / Clms Page number 21>

 It is then checked in a test step E506 if the number of executions of canceled functions m is greater than or equal to a prefixed threshold value T, for example equal to 20.

 If not, that is to say if the number of canceled function executions m emitted by the client station U is strictly less than this threshold value T, a calculation step E509 of the amount M to be reimbursed is set in work so that this amount M = CF.

 Thus, as long as the number of executions of canceled functions m remains below the threshold value T, the amount reimbursed to the client station U exactly corresponds to the amount invoiced CF during the execution of the function to be canceled.

 An update step E510 of the number m is then implemented so that the number of function executions then canceled m is incremented by one.

 Otherwise, if at the end of the test step E506, the number of executions of canceled functions m is greater than or equal to the threshold value T, a calculation step E507 of a cancellation cost C is put implemented as before.

By way of nonlimiting example, the cancellation cost C is calculated by the following formula:

As before, the value of the cancellation cost C can vary between 0 and CF X tR, WHERE tR is a maximum rate of reimbursement depending on the amount actually received CF during the execution of the function.

An association step E508 then makes it possible to calculate the reimbursement amount M so that:

There is thus deducted from the amount actually received CF a cancellation cost C depending on the number of executions of canceled functions m required by the client station U.

<Desc / Clms Page number 22>

The reimbursement amount M will therefore be strictly lower than the amount actually received CF during the execution of the function.

 The step E510 of updating the number of executions of canceled functions m is also implemented after the calculation step E508 so as to increment this number m by one.

 Then, in an updating step E511, the cancellation table 28 is updated from this new value m, then the reimbursement calculation procedure M is finished and the calculated value M is addressed for the rest of the setting. implementation of the cancellation process as illustrated in FIG. 3.

 We then update the reimbursement table R.

 In practice, it is checked whether the client Up having paid for the execution of the function and for which the amount M to be reimbursed has just been calculated is known and already stored in the reimbursement table R.

 If not, an addition step E21 makes it possible to store the identity of this client station Up in the reimbursement table R in association with a sum S to be reimbursed, here initialized at 0.

 A reading step E22 then makes it possible to read the sum Sp associated with the station Up to be reimbursed from the value stored in the reimbursement table R.

 This reading step E22 is implemented directly at the end of the test step E20 when the client station Up is already stored in the reimbursement table R.

The sum to be reimbursed Sp at this client station Up is then updated in a calculation step E23 in which:

The reimbursement amount M previously calculated in the calculation step E19 is thus added to the overall amount to be reimbursed at the station Up.

 An update step E24 then makes it possible to store this new sum value to be reimbursed Sp in the reimbursement table R in association with the identity of the client station Up.

 A test step E25 makes it possible to check whether the list of functions to be canceled has been exhausted.

<Desc / Clms Page number 23>

 If not, the previous function in this list is selected in a selection step E26 and the set of steps E12 to E25 described above is repeated on this function.

 The amount M to be reimbursed is therefore calculated for each function to be canceled in association with the client station U having paid for the execution of this function to be canceled.

 When the list of functions to be canceled is exhausted, at the end of the test step E25, a sending step E27 makes it possible to send the reimbursements proper to each client station of the communication network, from the identity of these client stations and the associated reimbursement values S stored in the reimbursement table R.

 In practice, as illustrated in FIG. 6, to send reimbursements, several response messages are generated for the attention of client stations of the communication network.

 In a step E601, we read a first line of table R, that is to say the identity of a client station U and an amount to be reimbursed S calculated previously.

 A response message A is then generated in a step E602 intended for the client station U.

 A step E603 is then implemented to obtain an amount S corresponding to the total amount to be reimbursed.

 This step is described in detail in Figure 7.

 Generally during this step, an electronic money is generated on the server station H, this electronic money being associated with the client station U to be reimbursed and the amount of electronic money generated being greater than or equal to the amount to be reimbursed S.

 In practice, the server station generates a chain of coins for each client station, this chain of coins being used for consecutive reimbursements of various operations canceled by this client station.

 In order to obtain this sum of money S, it is necessary to generate an electronic money on the server station H making it possible to create a suite

<Desc / Clms Page number 24>

 coins which can then be spent on the communication network to reimburse the client station U.

 To use this example, a PayWord system proposed by Rivest and Shamir is used to generate this electronic money.

 A description of this system can be found at http: // theory. lcs. began. edu / -rivest / RivestShamir-mpay. ps.

 This system generally consists, from a random number Wn, of generating a sequence of numbers using a hash function (in English Hash function).

 This PayWord system has the advantage of being reliable and of not requiring the approval of a third party (bank, notary, etc.) to validate each individual payment.

 In practice, it is checked in a test step E70 if the client station U is known to the server station H. If not, the server station draws a number at random in a random drawing step E73. Let be the random number Wn.

Then, in a coin striking step E74, recursively, a known hash function is applied such as:

This hash function h has the particularity of not being reversible so that it is impossible, from a number Wn-1 to find the previous number Wn.

 We thus obtain a series of parts Wn, Wn-1, ... W2, W1, Wo.

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

 This PayWord system advantageously makes it possible to verify the authenticity of the coins by simple application of the hash function.

 When generating such an electronic money, it is necessary for the server station H to obtain a certificate from a bank in order to prove its identity.

 Two certificates are used:

<Desc / Clms Page number 25>

 - a bank certificate C (PKe), issued by a bank in response to a request from the server station; and - a bill of exchange C (Wo) generated directly by the server station H.

 The bank certificate C (PKe) is an assurance for each user that the bank will honor any request for redemption of authentic documents. The bill of exchange C (Wo) is an assurance for each user that the documents produced by the server station are authentic and will be honored by the bank.

 In practice, the server station sends to a banking organization the number of its credit card as well as its public key PKe.

 The banking organization returns a bank certificate C (PKe) which contains the identity of the banking organization, the identity of the server station and the public key of the server station PKe. This certificate also includes an electronic signature authenticating the information it contains, this signature being produced by the bank using its private key SKb.

 Once the various pieces Wo, Wu, ..., Wn have been generated, these pieces are stored in a storage step E75 in the parts table 26 as illustrated in FIG. 1 in association with an identifier of the client station U and an index i, initialized to the value 0, corresponding to the index of the last part used in the table of parts 26.

 In addition, from the bank certificate C (PKe) obtained from the bank, the server station H generates, in a step of creating bill of exchange E76, a certificate or bill of exchange intended for the client station U.

 Each bill of exchange contains the bank certificate C (PKe) previously received, the identity of the client U for which it is intended, as well as the root coin Wo. This bill of exchange also includes an electronic signature authenticating the information it contains, this signature being produced by the server station using its private key SKe.

 After this step of creating E76 of a bill of exchange, the latter is sent in a step of sending E77 to the client station U.

<Desc / Clms Page number 26>

 Bills of exchange and coins are specific to a given user.

station serveur, la clé publique de la station serveur PKe, et la pièce racine Wo. Ultimately, the client station U receives the following information via the certificate C (PKe): the identity of the banking organization, the

server station, the public key of the PKe server station, and the root piece Wo.

 It is recalled that the public key of the PKe server station is contained in the certificate of bank C (PKe). The authenticity of this key can therefore be established by comparing the value obtained by decoding the signature of this certificate using the public key of the bank PKb, with the initial information contained in this certificate (signature excluded).

 Furthermore, it is recalled that the document Wo is contained in the bill of exchange of the server station C (Wo). The authenticity of this document can therefore be established by comparing the value obtained by decoding the signature of the certificate using the PKe public key previously authenticated, with the initial information contained in this certificate (signature excluded).

 Thus, by the play of a double signature, each client is able to verify that he is indeed in possession of a Wo root coin issued by a server, known to the bank, and authorized by the latter to issue coins. electronic money.

 If at the end of the test step E70 the client station U is already known, it is checked in a test step E71 whether the parts table 26 contains enough parts usable by this server station H to reimburse the reimbursement amount S at client station U.

 If not, a deletion step E72 makes it possible to delete the remaining parts in the parts table 26 and the steps described above E73 to E77 are implemented to generate new parts usable by the server station H to reimburse the client station U.

 Thus, the parts table 26 is automatically filled as soon as it no longer contains enough electronic money to reimburse the client station U.

<Desc / Clms Page number 27>

 The number of coins generated by the server station H may possibly depend on the frequency of use of this server station H by the client station U.

 This number of pieces can also be constant and determined once and for all.

 Note that it is preferable to generate a large number of coins during the coin striking step E74 and to store them in the coin table 26 for later use, that is to say when several functions executed by the client station U are canceled by itself or by another client station of the communication network.

 The generated parts each have a length for example of 32 bytes. The index of the part in the sequence of generated parts can be coded on 16 bits, which makes it possible to generate 216 parts.

 Returning to FIG. 6, the server station H implements a reading step E604 making it possible to read from the parts table 26 the index of the last part used.

 For a reimbursement sum S, and assuming that each piece W, corresponds to a unit fraction of this sum S, we take S pieces from the table of pieces 26.

* Here, the amount of money S reimbursed for the cancellation of the function f is entered directly in the response sent to the client station U.

 In practice, the value (W, s, i + S) is entered in the response.

 Of course, at the reimbursement stage, each calculated reimbursement amount M or the total reimbursement sum S could be credited to an account associated with the client station U, then be used to remunerate the execution of functions later.

 After this registration step E605, a storage step E606 makes it possible to store the new index i + S corresponding to the last part used in the parts table 26 for the client station U.

 Thus, the response A transmitted by the server station H during the sending step E607 contains the sum of money S corresponding to the cancellation of the requested function.

<Desc / Clms Page number 28>

 Then, in a test step E608, it is checked whether there is another line in the reimbursement table R, that is to say another client station U to be reimbursed with a sum of money S.

 If so, all the steps E601 to E607 described above are repeated.

 When all the rows of the reimbursement table R have been processed, the reimbursement procedure is terminated. Thus, a response message A is both sent to the first client station UA of the communication network having requested the cancellation of a function and to one or more other client stations of the communication network which have previously executed and paid for the or the functions to be canceled.

 Of course, when the first UA client station requests the cancellation of a function for which it has requested itself and paid for the execution, it receives by way of reimbursement the amount actually received during the execution of this function which is possibly deducts a CA cancellation cost.

 In parallel with the implementation of this method of canceling operations on the server station H, a method of requesting the cancellation of a remote function is implemented on the client station UA, as illustrated in FIG. figure 8.

 This method for requesting the cancellation of a remote function firstly comprises a step E801 of generating a request to cancel a remote function.

 This cancellation request includes a PA payment, which can use the Payword payment system described above.

 The request for the remote cancellation of a function on an object o is then sent in a sending step E802 by the client station U to the server station H.

 Then, a step E803 of receiving a result makes it possible to receive a response A sent by the server station H at the end of the process of cancellation of operations as described previously with reference to FIGS. 3 and following.

<Desc / Clms Page number 29>

 A test E804 makes it possible to check whether there is a bill of exchange in table 14 of the client station U corresponding to the server station H. The storage of such a bill of exchange will be described later with reference to FIG. 9.

 If not, an information step E815 informs the user of this anomaly.

 If this bill of exchange exists, a test step E805 makes it possible to verify that the response does indeed include in a specific field a sum of money S corresponding to a refund.

 As described above, when the client station UA requests the cancellation of a function for which it has itself paid and requested the remote execution, the sum to be reimbursed S corresponds to the sum of the payment sent PA and the cost perceived CF by the server station for the execution of the function, from which a CA cancellation cost is deducted.

 If this client station UA has not itself required the execution of the function to be canceled, the sum to be reimbursed S will not include the amount received CF by the server station H for the execution of the function.

 If no reimbursement is included in response A, the response processing procedure is also interrupted.

 Otherwise, an extraction step E806 is implemented in order to read the memorized amount, here corresponding to a coin Wi and to its index i in the chain of coins generated at the server station H.

 From reading the bill of exchange in table 14, we can obtain the value of the root coin Wo in a reading step E807.

 A validation step E808 then makes it possible to verify the authenticity of the piece W ,.

Wo. In practice, the hash function h is applied recursively to this current part W, and here i times: h (h (... h (Wi)))
The value thus obtained is compared with the value of the root coin

Wo.

<Desc / Clms Page number 30>

 One can also, to accelerate this validation step E808, apply, recursively, ij times the hash function h, that is to say a number of times just sufficient to find a part W ,, of index j lower than the current index i, and already sent by the server for the reimbursement of the execution of a function to be canceled.

 If the value obtained is different, the procedure for processing the function execution request is interrupted.

 The verification of the reimbursement by the client station U is a simple operation, consisting in applying a hash function. In particular, it is neither necessary to call on a banking organization for verification, nor to implement costly cryptographic methods.

 After validation of the received documents, it is checked in a test step E809 if the client station U having received the reimbursement is also the client station having previously requested the execution of the function. In practice, with reference to the algorithm of FIG. 3, it is checked whether the client station having requested UA cancellation is also the client station Up having requested and paid for the execution of the function. If so, a step E810 of obtaining the cost c associated with the execution of the function f applied to the object o is implemented.

 This step of obtaining E810 of the cost is implemented as described below with reference to FIG. 9.

 The execution cost c can be included directly in the response A sent by the server station.

 Otherwise, a particular procedure can be implemented to obtain this execution cost, as illustrated in FIG. 9.

 This procedure for obtaining the execution cost c of the function f firstly includes a test E91 to check whether the interface associated with the object o is available on the client station U.

 In practice, it is checked whether a corresponding interface has already been stored in the cache memory 15 of the client station U.

 If not, a step E92 is implemented to obtain this interface from the server station H.

<Desc / Clms Page number 31>

 The request for obtaining an interface includes the computer address of the interface.

 When the server station H receives the request for obtaining an interface, the server station extracts from this request the computer address referencing the requested interface.

 The server station can, from a table, find the requested interface and transmit it to the client station U, after possibly translating this interface into the communication language of the communication network.

 As described above, this interface includes one or more functions associated with the code for executing these functions.

 Each function is also associated with a cost of performing this function.

An example is given below of an interface for manipulating an image remotely.

This interface has three functions: - "ConvertToB & W" whose price is constant. This function converts an image to black and white; - "Rotate" whose price depends on the size of the image and the angle of rotation. The price is expressed in the form of an expression that the client station can evaluate: this function allows you to change the orientation of an image.

http ://oceania/web-obj/ctass/) rnage. xm) #ftip#price Cette fonction permet d'appliquer une symétrie à l'image. - "Flip" whose price depends on parameters determined by the server station. The customer is not able to calculate the price himself; the price is for example available at the following computer address:

http: // oceania / web-obj / ctass /) rnage. xm) # ftip # price This function allows you to apply symmetry to the image.

 <interface name = "1 mage" href = http: // oceania / web-obi / class / lmage. xml /> <attributes> <int name = "width" price = "0.01 FF" /> <int name = "height" price = "0.01 FF" />

<Desc / Clms Page number 32>

<string name = "encoding"/></attributes><functions><function name = "convertToB &W" price = "0. 5 FF"></function><function name = "rotate"><arguments>< int name = "angle"/></arguments><price> currency name = "FF"/><value language = "JavaScript"> function price (width, height, angle) {return width * height * angle; } </ value></price></function><function name = "flip"><price><currency name = "FF"/><value/></price></function></functions>< / interface>
After reception of the interface, a storage step E93 makes it possible to store the interface for later use in the cache memory 15 of the client station U.

 A reading step E94 makes it possible to read the cost c associated with the function f that one wishes to cancel in the interface received.

<Desc / Clms Page number 33>

 In a test step E95, it is checked whether the cost is an expression to be calculated.

 If so, an evaluation step E96 makes it possible to evaluate the cost of the function to be executed from the expression received.

 This is the case for example for the rotation function "rotate".

 Otherwise, we check in a test step E97 if the cost of the function is fixed. This is the case, for example, for the transformation of an image into black and white.

le coût de la fonction à la station serveur. Tel est ici le cas pour la fonction symétrie"flip". Otherwise, an E98 obtaining step is implemented to request

the cost of the function at the server station. This is the case here for the "flip" symmetry function.

 We thus obtain, at the end of step E810 of FIG. 8, the cost c associated with the function f that we wish to cancel.

 Then, a reading step E811 makes it possible to read the index j of the last piece received, and a test step E812 makes it possible to check whether the number of pieces received i-j is very different from the cost c of the function to be canceled.

 In practice, the following inequality is verified in test step E812: ij c where c is the cost associated with the function f, i is the index of the current part, and j is the index of the last part received by client station U.

 If the reimbursement included in the response is not sufficient, the procedure for processing this response is interrupted and the anomaly is reported to the user at information step E815.

 Otherwise, a storage step E813 makes it possible to store the new index i as index j of the last piece received.

 If at the end of the test step E809, the client station UA having received the reimbursement is not the client station Up having paid and required the execution of the function, the storage step E813 can be directly set in action.

 Alternatively, the verification steps E810 to E812 can also be implemented by this client station UA.

<Desc / Clms Page number 34>

 An addition step E814 then makes it possible to store the withdrawn coin W, associated with its index i in an electronic purse of the client station U.

 Periodically, each client station U can retransmit the values W, associated with each index i, stored in the electronic purse to the bank, in order to recover the monetary value.

 Alternatively, at the adding step E814, a prepaid card or a computer card as disclosed in FIGS. 4 and 8 of American patent US Pat. No. 5,937,395 can be used as the electronic purse of the client station U.

 We will now describe, with reference to FIG. 10, the procedure for processing a bill of exchange received by a client station U upon receipt of a first reimbursement sent by the server station H.

 After receipt of this bill of exchange, an obtaining step E101 allows the client station U to obtain from a certification body the public key of the bank PKb corresponding to the signature procedure used by the bank.

 As described above, a verification step E102 of the bank certificate C (PKe) can be implemented using the public bank key PKb in order to verify the signature.

 At the end of a test step E103, if this signature is invalid, the procedure is interrupted.

 Otherwise, a reading step E104 is implemented in order to read the public key of the server station PKe. This public key PKe makes it possible to verify in a step E105 the signature of the bill of exchange C (Wo) received by the client station.

 At the end of a test step E106, if this signature is invalid, the procedure is interrupted.

 Otherwise, a reading step E107 is implemented in order to know the identity of the server station H.

 A storage step E108 then makes it possible to store the bill of exchange in the bill of exchange table 14 of the client station U.

<Desc / Clms Page number 35>

In practice, each identifier of server station H is stored in association with the certificate of authenticity or bill of exchange C (Wo), and more precisely with the value of the root coin Wo.

 This bill of exchange thus allows the client station U to authenticate the documents received from the server station H and to validate the reimbursement amount received S.

 Once this step has been completed, the reimbursement is taken for granted.

 Thanks to this generation of electronic money on the server station H, the latter does not send the customer his own coins, which cannot be implemented reliably, but instead uses a separate set of electronic coins such as previously described.

 The reimbursement mechanism described in this embodiment is implemented symmetrically with the mechanism implemented to remunerate the functions executed on the server station.

 Of course, many modifications can be made to the example description described above without departing from the scope of the invention.

 Thus, in the embodiment described above, a cancellation cost is borne both by the client station UA having requested the cancellation of the function and the client station Up having previously requested the execution of the function.

 Of course, the cancellation cost could only be charged to the UA client station that requested the cancellation of the function.

 The server station could also propose to redo canceled functions. In this case, the cost to perform a function again could be equal to either: - the amount reimbursed when the function is canceled; - at the initial cost of performing the function; or - a different cost, between the amount reimbursed upon cancellation and the initial cost of execution so that a new execution of a canceled function would cost less than the initial execution of the

<Desc / Clms Page number 36>

 function. This can be justified as soon as the server station has kept in memory the result of the execution of the function after its cancellation.

Claims (18)

 1. Method for canceling a function (f) executed by a first client station (Up) on a computer object stored on a server station (H) of a communication network, the execution of the function (f) being adapted to handle said object from a previous state to a manipulated state, characterized in that it comprises the following steps:

 reception (E1) of a request to cancel the execution of an operation (f), sent by a client station (UA) of the communication network; obtaining (E12-E17) of said previous state of the manipulated object; and sending (E27) a response to the first client station (Up) via the communication network, said response comprising a sum of electronic money at most equal to an execution cost (c) associated with said function (f) .  2. Cancellation method according to claim 1, characterized in that it comprises a step of generating (E603) an electronic money on said server station (H), associated with said first client station (Up).  3. Cancellation method according to one of claims 1 or 2, characterized in that at the sending step (E27), the sum of electronic money is less than or equal to an amount collected (CF) by the server station (H) for the execution of said function (F).  4. Cancellation method according to claim 3, characterized in that the sum of electronic money is strictly less than said amount received (CF).  5. Cancellation method according to one of claims 1 to 4, characterized in that it further comprises a step of calculating (E502-507) a cancellation cost (C) associated with the request d 'cancellation received; and in that the sum of electronic money is calculated after deduction of said cancellation cost (F).  6. Cancellation method according to claim 5, characterized in that the cancellation cost (C) is zero if the number of execution requests <Desc / Clms Page number 38>  of canceled functions (m) sent by the client station (Up) is less than a prefixed threshold value (T).  7. Cancellation method according to one of claims 1 to 6, characterized in that it comprises the following steps: reception (E1) of a request to cancel the execution of a function (f) , issued by a second client station (UA) of the communication network, said cancellation request comprising a sum of electronic money (PA); and sending (E27) a second response (CA) to the second client station (UA) via the communication network, said second response comprising a sum of electronic money at most equal to said sum of electronic money (PA) included in the cancellation request.  8. Cancellation method according to claim 7, characterized in that it comprises a step of generating (E603) an electronic money on said server station associated with said second client station (UA).  9. Cancellation method according to one of claims 7 or 8, characterized in that it comprises a step of calculating (E6) a cancellation cost (CA) associated with the cancellation request received from the second client station (UA) of the communication network; and in that in the sending step (E27) of said second response (A), the sum of electronic money is calculated by deducting said cancellation cost (CA) from the sum of electronic money (PA) included in said cancellation request.  10. Cancellation method according to one of claims 1 to 9, characterized in that in the obtaining step (E13-E15), an inverse operation of said function (f) is executed.  11. Cancellation method according to one of claims 1 to 9, characterized in that it is implemented on a list of functions executed subsequently to a function (f) to be canceled.  12. Device for remote cancellation of a function (f) executed by a first client station (Up) on a computer object stored on a server station (H) of a communication network, the execution of the function ( f) being <Desc / Clms Page number 39>  adapted to handle said object from a previous state to a manipulated state, characterized in that it comprises: means (21) for receiving a request to cancel the execution of a function (f), sent by a client station (U) of the communication network; means for obtaining (22) said previous state of the object handled; and means for sending (27) a response to said first client station (U) via the communication network, said response comprising a sum of money at most equal to an execution cost (c) associated with said function (f).  13. Cancellation device according to claim 12, characterized in that it comprises means for generating (25,26) an electronic money on said server station (H), associated with said first client station (U) .  14. Cancellation device according to one of claims 12 or 13, characterized in that said sending means (27) are adapted to send a second response to a second client station (UA) via the communication network, said second response comprising a sum of electronic money at most equal to a sum of electronic money (PA) included in a request to cancel the execution of said function (f) sent by said second client station (UA).  15. Cancellation device according to one of claims 12 to 14, characterized in that it is incorporated in: a microprocessor (30); a read only memory (31) adapted to store a program for canceling functions remotely; and

 a random access memory (32) comprising registers (23, 26, 28, 29) adapted to store variables modified during the execution of said program.  16. Server station of a communication network, characterized in that it comprises means suitable for implementing the method <Desc / Clms Page number 40>  remote cancellation of a function according to one of claims 1 to 11.  17. Communication network, characterized in that it comprises a device for the remote cancellation of an operation in accordance with one of claims 12 to 15.  18. Communication network, characterized in that it comprises means suitable for implementing the method of remote cancellation of a function according to one of claims 1 to 11.