EP1771827A1 - Procede et systeme de paiement electronique universel - Google Patents

Procede et systeme de paiement electronique universel

Info

Publication number
EP1771827A1
EP1771827A1 EP04767533A EP04767533A EP1771827A1 EP 1771827 A1 EP1771827 A1 EP 1771827A1 EP 04767533 A EP04767533 A EP 04767533A EP 04767533 A EP04767533 A EP 04767533A EP 1771827 A1 EP1771827 A1 EP 1771827A1
Authority
EP
European Patent Office
Prior art keywords
payment
proxy
order
remote
multimedia terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04767533A
Other languages
German (de)
English (en)
Inventor
Mohammed Boutahar
Aymeric De Solages
Jean-Claude Pailles
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1771827A1 publication Critical patent/EP1771827A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/16—Payments settled via telecommunication systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Definitions

  • connections are intended either to obtain the agreement of the remote system SD, for the execution of the payment transaction, or to inform the latter of the expenses made by this customer, for billing purposes.
  • Remote systems which manage customers' financial resources, are usually contacted by the service provider or merchant. Order taking and enjoyment of the good or service purchased are done either on the mobile terminal of the user, or through another terminal, dedicated terminal for example.
  • mobile telephony terminals are commonly used to browse NNTERNET, according to the conventional protocol or in VVAP, to obtain information some of which, because of their value, can be obtained for a fee.
  • the telepayment there is the telepayment, the proximity payment or the internal payment.
  • the user of the mobile terminal has a means of payment on which his expenses are recorded.
  • this means of payment is managed in the network and this type of transaction therefore requires that the mobile terminal is in radio coverage, to be connected to the network, such as the GSM network.
  • An example of this situation concerns transactions paid by means of a bank card, in which the mobile terminal makes it possible to trigger the same type of banking transactions as those which are executed from a personal computer connected to the INTERNET .
  • proximity payment mobile telephony terminals or multimedia terminals equipped with communication functions, because of their deployment, the speed with which users change them, their characteristics and security qualities, because these the last are connected to the network when used in radio coverage, and that they have dialogue interfaces, such as keyboard and display device available, can become a means of payment of proximity to make purchases on payment terminals or PLCs. Such achievements have been proposed for demonstration in Europe, Japan and Korea. In the case of internal payment, the safer environment for transactions made from a mobile terminal is used.
  • the present invention instead has the object of implementing a method and a substantially universal electronic payment system, independently, substantially, the mode of payment, telepayment, proximity payment or internal payment finally retained.
  • Another object of the present invention is, for example, in the case of the implementation of a telepayment, in particular of a very small amount, the realization of such a telepayment in the absence of transmission of messages on air interface (OTA messages in English), via the GSM radio network for example, between the mobile terminal and a payment server, which makes it possible to deal with this type of transaction more quickly and more economically.
  • OTA messages in English air interface
  • Another object of the present invention is finally the implementation of a method and an electronic payment system provided with strong or strong security mechanisms so that a payment process of proximity may not be liable to prejudice the beneficiary of this payment, in particular, the registration of such a transaction being rendered indelible, the subsequent delivery to the managing body of the user's funds being ensured and no misappropriation or diversion can not be envisaged.
  • the electronic payment method between a multimedia terminal and a remote payment management system which is the subject of the present invention, is remarkable in that it consists in transmitting, from the multimedia terminal to a local proxy to this multimedia terminal, a payment order from at least one application hosted by this multimedia terminal, discriminating, at the level of this local payment proxy, this payment order on specific local processing criterion respectively remote from this multimedia terminal, proceed to a payment according to a payment mode. local payment of this payment order at said payment proxy on the local processing criterion selected from this payment order, otherwise transmitting at least this payment order to this remote system, to make a payment according to a remote payment method .
  • the electronic payment system between a multimedia terminal and a remote payment management system is remarkable in that this multimedia terminal comprises at least one payment proxy, this multimedia payment proxy being cut off between this application and this communication interface, so as to intercept any payment order issued by this application, this payment proxy comprising at least one discriminating module of this payment order on local treatment specific criterion respectively remote from this payment order, a local processing module of this payment order, on local processing specific criterion retained of this payment order and a transmission module of this payment order to this p server to make a payment using a remote payment method, otherwise, via this communication interface.
  • the method and electronic payment system objects of the present invention find application to the execution of payment transactions in the most diverse situations, including electronic payment online or nearby.
  • FIG. 1 represents, by way of illustration, a diagram of symbolic representation of transactions implemented by the method and the electronic payment system object of the present invention
  • FIG. 2a represents, by way of illustration, a flowchart of the essential steps for implementing the method that is the subject of the present invention
  • FIG. 2b represents, for purely illustrative purposes, a detail of implementation of payment order discrimination steps B, of local processing execution execution D and of transmission execution for remote processing illustrated in FIG. 2a. ;
  • FIG. 3 represents, for purely illustrative purposes, a block diagram of an electronic payment system in accordance with the subject of the present invention, more particularly intended for online payment;
  • FIG. 4 represents, for illustrative purposes, a block diagram of an electronic payment system according to the object of the present invention, more particularly intended, although not exclusively, a proximity payment.
  • an interaction noted by a two-way arrow, ITS corresponds to the sending of one or more messages between two entities B and C. It is oriented from B to C by an arrow, ITSi, when B is at the origin of this interaction and C is the target or vice versa for ITS2. These orientations may be indicated as shown for the ITSi and ITS2 interactions. Simplified representations are shown for ITi and IT 2 transactions. The last-mentioned representations can be used for the sending of a message by B to C in IT-) or in IT 2 for the reception of a message by B of a message sent by C.
  • An interaction is said to be composed for describe an exchange between two entities comprising a succession of simple interactions. It can be noted, as represented in ITS, ITSi or ITS 2 , as shown in FIG. 1, or be detailed as a succession of simple interactions.
  • Two interactions are called nested if the latter are not sequential, that is to say if one of them begins before the end of the other.
  • An interaction J is an under-interaction of I, where J is contained in I, if the simple interactions that make up the interaction J are also part of the succession of simple interactions that define I.
  • FIG. 2a A more detailed description of the electronic payment method between a multimedia terminal and a remote payment management system according to the subject of the present invention will now be given in connection with FIG. 2a.
  • the electronic payment method object of the present invention is implemented between a multimedia terminal, denoted TM, and a remote payment management system, denoted SD.
  • a multimedia terminal TM is defined as any terminal equipped with a mobile telephony function.
  • the multimedia terminal TM is deemed to implement one or more multimedia applications, labeled AMM, for example.
  • a multimedia application is a paid application, because some of the possible actions via this application implemented via the multimedia terminal TM make the object of a payment managed by the remote system SD comprising one or more payment servers.
  • the AMM application may be an application that has been the subject of a download paid or not beforehand, a special case being that of applications written in Java.
  • An AMM application may also be constituted by the client part, on the multimedia terminal TM, of a client / server type AMMC multimedia application.
  • This AMM client part contains the presentation layer of AMMC and is likely to use the Internet browser of the multimedia terminal TM.
  • the AMM multimedia application is then in interaction with AMMC's AMM2 application layer hosted on a remote server of this application.
  • the AMM client part is called simply "AMMC presentation layer" in the following.
  • the method that is the subject of the invention consists in transmitting, in a step A, from the terminal TM to a local payment proxy to this multimedia terminal, proxy noted PP, a payment order coming from at least an AMM multimedia application hosted by the terminal TM.
  • Step A is followed by a step B consisting in discriminating, at the level of the local payment PP proxy, the payment order on local processing specific criterion respectively distant from this payment order.
  • step B is represented as a test step intended to determine the local or remote character of the processing carried out on the payment order M p , according to the symbolic relation
  • step B is then followed by a step C consisting in making a payment according to a local payment method of this order of payment at the PP payment proxy level on the selected local processing criterion of this payment order.
  • step B is followed by a step D of transmitting at least the payment order to the remote system to make a payment in a remote payment mode.
  • step D is represented by the symbolic relationship according to the transaction:
  • the terminal TM hosts the PP payment proxy application belonging to the remote system SD and accessible to the paid applications via an A.P.I. (application programing interface, application programming interface in French) called A.P.I. P. (for A.P.I.
  • the AMM application sends its payment orders to the payment proxy PP, when its operation requires it.
  • the payment orders can come from the application layer AMM 2 and be transferred to the PP payment proxy by the AMM presentation layer, as will be described later in the description.
  • the payment proxy PP has and implements two payment methods:
  • the use of the local payment method by the PP payment proxy can be related to various situations:
  • the PP payment proxy can be configured to aggregate successive transactions for the same remote system SD, aggregated transactions are then seen by the system remote as a single transaction for example. In all cases, the payment transaction assumes a connection PP payment proxy with the remote system SD before or after the payment itself.
  • proxy corresponds to that of an application controlled by the remote system SD. This concept covers that of a proxy payment server controlled by the remote system SD.
  • step B of discriminating the local or remote character of the processing of the payment order is defined from a plurality of payment types executed by the payment proxy PP.
  • the payment proxy PP thus has a plurality of payment types, such as, for example, as represented in step B0 of FIG. 2b:
  • the proximity payment is the payment in which the multimedia terminal TM is in connection with a payment terminal constituted for example by a TPE electronic payment terminal or a dedicated vending machine in a department store or other;
  • - T 2 internal payment.
  • Internal payment is the payment in which the payment method, local payment, is used regardless of the availability of the network.
  • Telepay is the payment method in which remote payment is preferred.
  • the method of payment used may nevertheless be a local payment, when the network is unavailable.
  • an example of implementation of the discrimination process at the payment proxy level of the payment order on specific criteria of local processing respectively remote from the latter, that is to say from the step B in FIG. 2a may include but not be limited to the following steps: step B i : discriminating the type of payment from the available payment types Ti 1 T2, T3, Mp of type Ti or T2 or T3.
  • step B 2 On positive response to the test Bi, one of the aforementioned payment types being discriminated, if it is a type of internal payment T 2 , then the processing mode is local in step C, as shown in Figure 2b. If the payment order M p corresponds to a type of proximity payment Ti or telepayment T 3 , then a step B 2 is called consisting in discriminating the presence respectively the absence of the phase ⁇ mobile network coverage.
  • Step B 2 is represented as a test relative to the existence of phases according to the relation: 3 ⁇
  • the local processing execution payment step C can be called.
  • the local character of this processing may make it necessary a further interaction K 2 with the remote system SD, as mentioned later in the description.
  • a test B 3 may be called relative to the value of the transaction, ie the amount invoiced MF, vis-à-vis a determined threshold value MF O.
  • the execution of the payment processing according to a local processing C can then be called, regardless of whether the payment type is a type of proximity payment Ti or telepayment T 3 .
  • test B 3 On the contrary, on a positive response to the test B 3 , the execution of the remote processing D can then be called for the payment types Ti of proximity respectively T 3 of telepayment.
  • the mode of implementation of tests Bi, B 2 and B 3 is not limiting, other combinations may be envisaged.
  • specific payment means may be retained, these specific payment means defining in particular the method of execution of the payment by the user of the terminal.
  • multimedia TM to obtain the requested service via the AMM application.
  • the local or remote processing of the payment orders is, according to a particularly advantageous aspect of the method that is the subject of the present invention executed, via a means of payment.
  • This payment method uses a payment process chosen from the prepaid payment process, virtual wallet, postpaid or electronic wallet, for example.
  • a payment process chosen from the prepaid payment process, virtual wallet, postpaid or electronic wallet, for example.
  • the above enumeration is not limiting, other means of payment with access control criteria for example can be envisaged.
  • a means of payment is a means of making the payment, that is to say a means for charging a user client.
  • a plurality of payment means is denoted MPj
  • the payment means accessible to the user C of a multimedia terminal TM are denoted MPj 0 , for example.
  • a means of payment MP k is a prepayment means, when the operator of MP k makes the user pay the amount necessary to pay a purchase using MP k before the implementation of MPk.
  • the payment means MP k is a means of postpay or that MP k is postpaid. It is noted that a payment means MP k can of course manage payment transactions from different issuing points, including other than the multimedia terminal TM. A multimedia terminal TM therefore manages a subset of the payment transactions managed by an MPk payment means. When TM is the only emission point of MP k , we say that MP k is dedicated to TM.
  • the remote system SD comprises at least one payment server, in particular a payment server to be used SP-i, interconnected to the mobile telephone network for example, denoted N by a user interface. communication rated IM.
  • Other payment servers rated SPj may also be provided, the different payment servers can be implemented, in particular, by one or more applications of the multimedia terminal TM.
  • the multimedia terminal TM comprises at least one communication interface, denoted MC, mobile radiotelephony, which can be connected to the payment server via the network N.
  • the multimedia terminal TM comprises at least one payment proxy PP which receives, from a multimedia application, hosted by the multimedia terminal TM, messages or control commands.
  • a multimedia application hosted by the multimedia terminal TM
  • messages or control commands it indicates that it includes of course the parts of a mobile phone device such as the display device, the KB keyboard and OS operating system, as well as of course applications implemented in permanent memory of the latter.
  • the complete multimedia application AMMC is deemed, in the example of Figure 3, to consist of the paid application and, in particular, consist of an AMM portion located on the multimedia terminal TM, AMM including AMMC presentation module including and possibly consist of another AMM 2 part located on a remote server in connection with AMM by via an interaction K 3 , via the mobile radio communication interface MC and, of course, the network N.
  • the payment proxy PP is cut off between AMM, that is to say the TM TM local part, and the communication interface MC, so as to intercept all payment order issued by AMM, to the remote system SD and in particular, the SPi payment server deemed to manage all payment orders and possibly the access conditions corresponding to the service requested by the multimedia application AMMC.
  • the user of the multimedia terminal TM is deemed to generate, from the KB keyboard for example, and of course from the operating system OS of this terminal, an interaction h with the local AMM portion of the multimedia application, the latter addressing to the payment proxy a payment order Mo during an interaction I 2 to allow access to the requested service during the interaction li.
  • the payment order MB normally sent to the communication interface MC to be transmitted to SD is intercepted by the payment proxy PP, as shown in Figure 3.
  • the payment proxy PP advantageously comprises, as represented in FIG. 3, a module 1 for discriminating this payment order on local processing specific criterion respectively distant from this payment order, a module 2 for local processing of this payment order on the local processing criteria selected for this payment order, as previously described in the description, in connection with FIGS. 2a and 2b, and a module 3 for transmission of the payment order MO to the payment server. payment to make a payment according to a remote payment method, in the case where the specific criterion of local processing has not been retained for the payment order M 0 considered.
  • FIG. 3 shows the interaction! 2 (M 0 ) and its response r, response of the payment proxy PP to the multimedia application AMM according to the conventions mentioned above.
  • the payment proxy PP can contact the user of the multimedia terminal TM during a interaction 1 3 (CA) in order to obtain the agreement of the latter or simply notify him of the payment made.
  • the aforementioned Is (CA) interaction contains a command or display command CA sent to the mobile telephone terminal, in particular to the OS and display parts of the multimedia terminal TM.
  • the above command displays a confirmation request to the user.
  • the display command message CA contains for this purpose the elements of the transaction allowing the user of the multimedia terminal TM to make an informed decision.
  • a response r 0 may be sent, the positive response being denoted OK represented in square brackets in FIG. 3.
  • the response message r 0 advantageously comprises personal identification data denoted [PIN] .
  • the processing of the payment order is continued according to the local or remote processing mode, as described previously in the description. If the user's response is negative, NOK, then the AMM multimedia application is immediately informed by the payment proxy PP, via the response r to the interaction 1 2 (MB).
  • the display command or command CA may contain an authentication request from the user of the multimedia terminal TM as will be described later in the description.
  • the multimedia terminal TM is constituted by a mobile telephone terminal, for example GSM, provided with a SIM card
  • the payment proxy PP is then particularly advantageously hosted at least partially on the SIM card. This mode of implementation is not reserved for GSM mobile telephone terminals.
  • the multimedia terminal TM includes a multimedia terminal security module SM
  • this module is of course used for the purpose of ensuring the integrity of the payment proxy PP.
  • this security module SM is formed by the SIM card (for "Subscriber Identification Module") of the latter.
  • the payment proxy PP is advantageously constituted by an application, that is to say an application software directly downloadable on the multimedia terminal TM.
  • the integrity of the downloaded code can then be controlled by the security module SM, in particular the SIM card, the latter having necessary cryptographic elements or resources.
  • the code of the application downloaded to perform the PP payment proxy function can be signed, this signature being controlled by the security module SM, and, in particular, the previously mentioned SIM card, which holds the public key of the entity having signed the code of the aforementioned application.
  • the integrity of the public key is also protected by the multimedia terminal TM and in particular by hosting the aforementioned public key in the security module SM.
  • the security modules can be removable.
  • SIM card including a chip or security module, the whole being designated SIM card.
  • the original card When changing the SIM card, the original card can be placed in another multimedia terminal.
  • the security module SM can then simply be inserted into a new compatible terminal so that the system which is the subject of the invention is able to function correctly.
  • a security module SM is used and the latter is also removable and if the payment proxy PP is wholly or partially hosted elsewhere than in the security module, the part of the payment proxy PP that is not hosted in the security module SM can be loaded into the latter if it has sufficient free memory space, before removal of the security module SM. Otherwise, a software vault can advantageously be used to protect the PP payment proxy or part thereof that is not hosted in the security module SM, before moving it into the new multimedia terminal.
  • a software vault is defined as a means of encrypting and decrypting data and which can be implemented by means of a password, the same password being itself used to encrypt and decrypt data to protect.
  • Symmetric encryption / decryption with a single key can be used, for example.
  • the software safe can be loaded into the security module SM, when the security module has sufficient free memory space. Alternatively, it can also be "downloaded" to a dedicated server, waiting to be downloaded to the new terminal. Such a procedure for implementing the system that is the subject of the invention assumes the establishment of the necessary cryptographic key and algorithm infrastructure.
  • the multimedia terminal TM furthermore comprises a short-range interface, denoted ICP, making it possible to execute an application via an external electronic payment terminal, denoted by TP, on the same figure.
  • ICP short-range interface
  • TP external electronic payment terminal
  • the ICP short-range interface may be present at the mobile telephone terminal hosting the corresponding AMM application.
  • the user of the multimedia terminal TM is in the so-called proximity situation.
  • it is in the enclosure of a traditional business and has its multimedia terminal TM.
  • the aforementioned traditional trade is equipped with a payment terminal, such as an electronic payment terminal TP, for example, provided with a standardized interface using short-range electromagnetic waves.
  • a payment terminal such as an electronic payment terminal TP, for example, provided with a standardized interface using short-range electromagnetic waves.
  • This ICP short-range interface may be constituted by an infrared type interface (IRDA), RFID type (RFIDi 4443 ) for example, Bluetooth type or Wifi.
  • IRDA infrared type interface
  • RFIDi 4443 RFID type
  • Bluetooth type Wireless Fidelity
  • the user of the multimedia terminal TM in a proximity situation can also be in front of a PLC, for example a vending machine also equipped with a short-range interface.
  • the multimedia terminal TM is supposed to have the means necessary to interact with the electronic payment terminal TP. All of these means grouped under the term short-range interface ICP also contains the resources needed to route messages to their destination, especially when multiple destinations are possible. This is the case for example if the optional interaction li, shown in FIG. 4, is provided and it comprises at least one sending of messages from the ICP short-range interface to the operating system OS of the terminal. mobile telephony.
  • the interaction h allows dialogue with the operating system, essentially the multimedia terminal except the functions specific to the subject of the invention, or independently of the payment proxy PP.
  • the aforementioned interaction is optional because the messages it conveys can also pass, if necessary, through the payment proxy PP, for example during the interactions b and I 3 shown in FIG. 4 or in the course of unrepresented interactions.
  • the payment proxy PP When such a dialogue passes through the payment proxy PP, the latter is then able to control the dialogue between the electronic payment terminal TP and the user.
  • the user of the multimedia terminal TM in the situation of FIG. 4, that is to say the use of a short-range ICP interface provided with its terminal multimedia TM, is invited to approach the payment terminal TP sufficiently for the aforementioned short-range system to work.
  • the cashier of the store makes the necessary manipulations on the electronic payment terminal TP, these manipulations having the effect of triggering the interaction J initiated by the terminal of payment
  • the customer is invited to authorize the use of his multimedia terminal TM for payment type proximity payment and thus to allow the dialogue of his mobile terminal TM with the payment terminal TP.
  • the interaction I 2 already described in the context of the first embodiment represented in FIG. 3, enables the electronic payment terminal TP to send a payment order Mo to the payment proxy PP, in respecting the format imposed by its APIP interface.
  • the payment proxy PP as described above, initiates the interaction I 3 with the mobile terminal and in particular the operating system OS of the latter to obtain the agreement of the user.
  • the payment proxy PP interprets the response ro and if it deduces that the user has been correctly authenticated and that his agreement, when the latter is required, has actually been given, processes the payment order received in I2, and as previously described in the description.
  • the response r 2 of the short-range interface ICP to the payment terminal TP contains the useful elements of the answer r.
  • some of the elements of the response r can be signed by the payment proxy PP and / or the remote system SD.
  • The, or the signatures produced, can be transmitted via response r 2 to the electronic payment terminal TP to serve as proof of payment.
  • the electronic payment system object of the present invention has a high level of security.
  • the payment proxy PP is advantageously protected in write / read access by an access control module and encryption / decryption of data by password, module 4 previously described in the description.
  • the multimedia terminal TM comprises a security module containing cryptographic resources for verifying the signature of the payment proxy PP, when the latter is downloaded as an application in the multimedia terminal.
  • trade security is provided in a particularly strict manner under the following conditions.
  • the response r to the payment order b (MO) or certain elements of this response can be signed using a private key (CP) protected by the terminal.
  • CP private key
  • the private key CP is represented as accessible by the payment proxy PP in FIGS. 3 and 4.
  • the private key CP is the one for which a certificate of the associated public key has been published.
  • the elements of the response r can in particular include the data signed by the remote system SD and from the response ⁇ to the transaction K- ⁇ (Mi), shown in Figures 3 and 4.
  • the aforementioned signatures allow the AMMC multimedia application to retain a proof of payment, which can be used in case of dispute, when the credit of the account of the operator of the AMMC application is not recognized.
  • the aforementioned proof may for example be transmitted to the remote multimedia application AMM 2 , shown in Figure 3, or where appropriate be regularly filed on another server.
  • the aforementioned private key CP may have been defined within the framework of a pre-existing PKI system and may advantageously be housed in the SIM card of the mobile terminal constituting the multimedia terminal TM.
  • the SIM card can be replaced by the WIM module for Wireless
  • a payment means MPk is associated with a payment server SP k .muni an interface If k , allowing it to receive payment messages for which it gives or not in real time a response.
  • a payment message for a payment means MP 0 may be a request for authorization if the interface l f0 of MPo allows it.
  • the response to this payment message can be positive or negative.
  • the Ifo interface In the case where an authorization request message is sent, the Ifo interface must provide for the management of a payment confirmation which is another type of payment message.
  • Such confirmation of payment is sent only after a request for authorization whose response was positive.
  • the customer is actually billed by the MPo payment means only if the payment communication has been received.
  • the response to a confirmation of payment can be a simple acknowledgment indicating the consideration by the payment server SPo of the message in question.
  • a confirmation of payment may be designated as a discount or capture, particularly if it is significantly deferred from the time of payment by the requesting customer.
  • a payment message can also be a debit request in addition followed by a positive or negative response.
  • a positive response to this payment message means that the requesting customer is or will be billed anyway.
  • the subset of the transactions managed by the multimedia terminal TM for a payment means MP k in fact comprises all the transactions managed by the payment means considered MP k , then all the payments made using the payment means MP k are in the processing field of the payment proxy PP. It is said that the payment means MP k considered is dedicated to the payment proxy PP and therefore ultimately to the multimedia terminal.
  • the payment proxy PP is a protected local application, as described previously in the description, held by the remote system SD, although hosted in the multimedia terminal TM, its behavior can not be modified by the user's user. multimedia terminal TM.
  • the payment proxy PP processes this payment order using its local information base and sends the response r to the AMM local part of the AMMC multimedia application.
  • the response r can be transmitted to the remote part AMM 2 , when it exists.
  • the local payment is advantageously made according to a particular case, when the method of payment is a local electronic wallet.
  • the remote or local payment mode essentially depends on the availability of the network, that is to say the test of step B 2 of FIG. 2b.
  • the proxy's response payment PP to the multimedia application AMMC can obviously vary depending on whether the connection to the remote system SD is possible or not, the unavailability of the network phase forcing the payment proxy PP to use local criteria to make the decision to allow or not a payment order.
  • the payment type is the telepayment type T 3 and the network is available in accordance with test B 2 of FIG. 2b, the payment method, remote payment is used by calling step D in FIG. 2b.
  • a payment order Mi is transmitted via a Ki interaction to the remote system SD, as shown in FIGS. 3 and 4.
  • the first payment message sent to the remote system SD may be a request for authorization.
  • this authorization request follows a payment order:
  • a delayed K 2 transaction can be implemented to confirm the transaction.
  • the remote system SD Due to the fact that the remote system SD was available and accessible, the latter returns the response ⁇ to the payment proxy PP. The latter eventually processes this response, in particular using its local information base and sends its own response r to the AMM local part of the multimedia application AMMC.
  • This response includes the u response elements useful to the AMMC application.
  • the local payment method step C on the same figure above is used.
  • the payment order M 0 is then processed locally by the payment proxy PP. Since the remote system SD was not available, the payment proxy PP processes the payment order locally using the information it has in its local information base.
  • the lack of cooperation of the remote system SD may for example lead to the use of stricter criteria for sending a positive response to the payment order.
  • the multimedia terminal is constituted from a mobile telephone terminal
  • the GSM network the availability of the network can be known from the SIM card if it questions MC, which can then communicate this information directly to the PP payment proxy.
  • a delayed interaction K 2 can be used to send the elements of the transaction to the remote system SD, as was previously indicated in the case of remote payment.
  • the triggering of the delayed interaction K 2 may be linked to an external event independent for example during another payment from the customer or following an explicit request from the remote part AMM 2 of the multimedia application AMMC or linked to a date-type event for example.
  • the interaction K 2 may be triggered by the payment proxy PP, for example after expiry of a certain predetermined period.
  • the expiry of the aforementioned period can be controlled by the PP payment proxy, for example by a regular reading of the date received from the network.
  • the elements of several transactions can be sent during the same interaction K 2 in a group discount.
  • the aforementioned transaction K 2 may contain the sum of the amounts of the transactions it carries. When this sum is present in the transaction K 2 , the amounts of the individual transactions may not be transmitted. It is said that we transmit an aggregate of transactions.
  • the response r of the PP payment proxy to the multimedia application AMMC is given according to an information base stored locally.
  • the following description gives examples of locally stored information for or by the PP payment proxy and processing associated with that information.
  • variable used corresponds to the management of the payment means MP k . History of payment orders and answers given
  • the payment proxy PP is able to manage for each means of payment MP k the history of payment orders OP k j where j is a transaction reference number for example.
  • the payment proxy PP can also manage the response history ⁇ , already given locally, and remotely by the remote system SD, where j is the number of the transaction.
  • the PP payment proxy can manage the payment method profile
  • MP k namely the fact that the means of payment uses a prepaid payment process, postpaid or electronic wallet for example.
  • the payment proxy PP may for example manage a local electronic wallet, denoted PMVL k , consisting of a set of variables including at least the balance of the wallet Sk.
  • Such an electronic purse uses exclusively the payment type "internal payment" for example.
  • the authorities using the PP payment proxy and the payment means MP k must then offer the customer a means of payment. reloading balance S k .
  • the reloading of the means of payment MP k may possibly use another means of payment MP j with j ⁇ k or finally any other means of payment.
  • the payment proxy PP can manage a local package denoted FF k formed by a set of variables comprising at least the balance of the package S k .
  • the payment method MP k is then a local package using exclusively the payment type "internal payment".
  • the customer who owns the multimedia terminal actually buys a local package MP k of amount S and has this sum for a defined period of time P called "period". At the end of the period, the remaining amount becomes unusable.
  • the aforementioned operators in the case of the electronic wallet then allow the user possessing the above-mentioned local package to have a means of purchase of this local package so as to set up a means for initializing the balance S k to the value S.
  • the payment proxy PP can also manage a recurring local flat rate denoted FLR k formed by a set of variables comprising at least the balance of the package S k .
  • the MPk payment means is a recurring local plan using exclusively the payment type "internal payment”.
  • period the sum S for a defined period of time P called "period”.
  • the balance S k is reset to the value S independently of the previous value.
  • the sum S becomes available again for the next period, generally of the same duration as the previous one, and so on.
  • the operators of the recurring local plan must offer the user customer a means of subscribing and unsubscribing to the recurring local plan, as well as a means of resetting the balance periodically, and thus making the payment necessary for the subscription.
  • the payment proxy PP may allow management of a local balance noted SL k , for example when the payment means MP k used is a virtual wallet, and a total amount of expenditure made locally MTDL k .
  • the variables SL k and MTDL k must constantly check the MTDL relation k ⁇ SL k . When connected to the remote system SD, these two variables are updated: MTDL k is reset and SLk takes a new value, which takes into account, in particular, payments made with MP k but without TM, if MP k is not dedicated to TM.
  • the payment proxy PP can also manage the total amount spent MTD k and the spending limit PD k over a given period in a manner known per se.
  • the total amount spent on MTD k should be understood as the sum of all the expenditure made in the current period with the payment method MP k and which was the subject of a payment order via the payment proxy. PP.
  • the current period is defined as a period containing the moment when the value of BAT k "total amount spent" is taken into consideration.
  • the current period may be for example the time interval between two delivery messages provided by the payment means MP k .
  • the current period can also be the time interval between two payments with connection to the remote system SD enabled by the availability of the network.

Abstract

L'invention concerne un procédé et un système de paiement électronique universel. On transmet (A) d'un terminal multimédia (TM) à un proxy de paiement (PP) local un ordre de paiement (MP) provenant d'au moins une application (AMM) multimédia hébergée par (TM), on discrimine (B) au niveau de (PP) l'ordre de paiement sur critère spécifique de traitement local respectivement distant, on procède (C) à un paiement local au niveau du proxy de paiement (PP) sur critère spécifique de paiement local retenu, sinon, on transmet (D) l'ordre de paiement à un système distant (SD) pour effectuer un paiement distant. Application à des transactions de paiement de proximité, de paiement externe ou de télépaiement par voie électronique.

Description

Procédé et système de paiement électronique universel.
Les systèmes de paiement électronique d'accès à un service au moyen d'un terminal de téléphonie mobile, pour le commerce de proximité ou le commerce en ligne, pour lesquels une ou plusieurs connexions à au moins un système distant SD, gérant les ressources financières de l'utilisateur possesseur de ce terminal de téléphonie mobile, sont à l'heure actuelle indispensables, pour la promotion du commerce électronique.
Ces connexions ont pour but soit d'obtenir l'accord du système distant SD, pour l'exécution de la transaction de paiement, soit d'informer ce dernier des dépenses effectuées par ce client, en vue de leur facturation. Les systèmes distants, qui gèrent les ressources financières des clients, sont en général contactés par le prestataire de service ou le marchand. La prise de commande et la jouissance du bien ou du service acheté se font soit sur le terminal mobile de l'utilisateur, soit par l'intermédiaire d'un autre terminal, terminal dédié par exemple. Actuellement, les terminaux de téléphonie mobile sont couramment utilisés pour naviguer sur NNTERNET, selon le protocole classique ou en VVAP, afin d'obtenir des informations dont certaines, en raison de leur valeur, peuvent être obtenues à titre onéreux.
Parmi les modes de paiement envisageables, on distingue le télépaiement, le paiement de proximité ou encore le paiement interne. Dans tous les cas, l'utilisateur du terminal de téléphonie mobile dispose d'un moyen de paiement sur lequel ses dépenses sont enregistrées.
Dans le cas du télépaiement, ce moyen de paiement est géré dans le réseau et ce type de transactions impose donc que le terminal de téléphonie mobile soit en couverture radio, pour être connecté au réseau, tel que le réseau GSM. Un exemple de cette situation concerne les transactions payées au moyen d'une carte bancaire, dans lesquelles le terminal de téléphonie mobile permet de déclencher le même type de transactions bancaires que celles qui sont exécutées à partir d'un ordinateur personnel connecté à l'INTERNET. Dans le cas du paiement de proximité, les terminaux de téléphonie mobile ou les terminaux multimédia dotés de fonctions de communication, en raison de leur déploiement, de la rapidité avec laquelle les utilisateurs en changent, de leurs caractéristiques et qualités sécuritaires, du fait que ces derniers sont connectés au réseau lorsqu'on les utilise en couverture radio, et qu'ils disposent d'interfaces de dialogue, tels que clavier et dispositif d'affichage disponibles, peuvent devenir un moyen de paiement de proximité pour réaliser des achats sur des terminaux de paiement ou automates. De telles réalisations ont été proposées à titre de démonstration en Europe, au Japon et en Corée. Dans le cas du paiement interne, l'environnement plus sûr des transactions effectuées à partir d'un terminal de téléphonie mobile est mis à profit.
Par exemple, les jeux sur les terminaux de téléphonie mobile prennent à l'heure actuelle une importance de plus en plus grande. Les éditeurs de jeu sont, en conséquence, intéressés par des formules de vente à la carte, à la séance, ou lorsque chaque fois qu'un nouveau niveau de jeu est accessible. Cette notion correspond sensiblement à celle qui est connue en télévision sous le nom de télévision à la carte, « pay per view » en anglais. Un tel type d'accès à des services ou produits n'est pas développé dans le monde des terminaux ou ordinateurs PC connectés à l'INTERNET, en raison des problèmes de sécurité qui rendent hasardeux, pour les éditeurs, fournisseurs de prestations de services, de telles transactions.
Les différents types de contexte de paiement précités sont, à l'heure actuelle, traités dans des mises en œuvre pratiquement indépendantes, et, dans tous les cas, trop partielles.
La présente invention a au contraire pour objet la mise en œuvre d'un procédé et d'un système de paiement électronique sensiblement universel, indépendamment, sensiblement, du mode de paiement, télépaiement, paiement de proximité ou paiement interne finalement retenu. Un autre objet de la présente invention est, par exemple, dans le cas de la mise en œuvre d'un télépaiement, en particulier d'un très petit montant, la réalisation d'un tel télépaiement en l'absence de transmission de messages sur interface aérienne (messages OTA en anglais), par l'intermédiaire du réseau de radiotéléphonie GSM par exemple, entre le terminal de téléphonie mobile et un serveur de paiement, ce qui permet de traiter ce type de transaction de manière plus rapide et plus économique.
Un autre objet de la présente invention est enfin la mise en œuvre d'un procédé et d'un système de paiement électronique munis de mécanismes de sécurité puissants ou suffisamment forts afin qu'un processus de paiement de proximité ne puisse pas être susceptible de léser le bénéficiaire de ce paiement, en particulier, l'enregistrement d'une telle transaction étant rendu indélébile, la remise ultérieure auprès de l'organisme gestionnaire des fonds de l'utilisateur étant assurée et aucune malversation ou détournement ne pouvant être envisagée.
Le procédé de paiement électronique entre un terminal multimédia et un système distant gestionnaire de paiements, objet de la présente invention, est remarquable en ce qu'il consiste à transmettre, du terminal multimédia à un proxy local à ce terminal multimédia, un ordre de paiement en provenance d'au moins une application hébergée par ce terminal multimédia, discriminer, au niveau de ce proxy de paiement local, cet ordre de paiement sur critère spécifique de traitement local respectivement distant de ce terminal multimédia, procéder à un paiement selon un mode de paiement local de cet ordre de paiement au niveau dudit proxy de paiement sur critère spécifique de traitement local retenu de cet ordre de paiement, sinon transmettre au moins cet ordre de paiement à ce système distant, pour procéder à un paiement selon un mode de paiement distant.
Le système de paiement électronique entre un terminal multimédia et un système distant gestionnaire de paiements, ce système distant comportant au moins un serveur de paiement et ce terminal multimédia comportant au moins une interface de communication de radiotéléphonie mobile, objet de la présente invention, est remarquable en ce que ce terminal multimédia comporte au moins un proxy de paiement, ce proxy de paiement multimédia étant monté en coupure entre cette application et cette interface de communication, de façon à intercepter tout ordre de paiement émis par cette application, ce proxy de paiement comportant au moins un module de discrimination de cet ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement, un module de traitement local de cet ordre de paiement, sur critère spécifique de traitement local retenu de cet ordre de paiement et un module de transmission de cet ordre de paiement à ce serveur de paiement, pour procéder à un paiement selon un mode de paiement distant, sinon, par l'intermédiaire de cette interface de communication.
Le procédé et le système de paiement électronique objets de la présente invention trouvent application à l'exécution de transactions de paiement dans les situations les plus diverses, notamment paiement électronique en ligne ou de proximité.
Ils seront mieux compris à la lecture de la description et des dessins ci-après dans lesquels : - la figure 1 représente, à titre illustratif, un schéma de représentation symbolique de transactions mises en œuvre par le procédé et le système de paiement électronique objets de la présente invention ;
- la figure 2a représente, à titre illustratif, un organigramme des étapes essentielles de mise en œuvre du procédé objet de la présente invention ; - la figure 2b représente, à titre purement illustratif, un détail de mise en œuvre des étapes B de discrimination d'un ordre de paiement, d'exécution C de traitement local et d'exécution D de transmission pour traitement distant illustrés en figure 2a ;
- la figure 3 représente, à titre purement illustratif, un schéma fonctionnel d'un système de paiement électronique conforme à l'objet de la présente invention, plus particulièrement destiné à un paiement en ligne ;
- la figure 4 représente, à titre purement illustratif, un schéma fonctionnel d'un système de paiement électronique conforme à l'objet de la présente invention, plus particulièrement destiné, bien que de manière non exclusive, à un paiement de proximité.
Préalablement à la description proprement dite du procédé et du système de paiement électronique, objets de la présente invention, différentes indications relatives à des interactions, c'est-à-dire des échanges de messages entre les différentes entités mises en œuvre par le procédé et le système de paiement électronique objets de l'invention, seront données en liaison avec la figure 1.
D'une manière générale, en référence à la figure précitée, une interaction notée par une flèche à double sens, ITS, correspond à l'envoi d'un ou plusieurs messages entre deux entités B et C. Elle est orientée de B vers C par une flèche, ITSi, lorsque B est à l'origine de cette interaction et que C en est la cible ou réciproquement pour ITS2. Ces orientations peuvent être indiquées ainsi que représenté pour les interactions ITSi et ITS2. Des représentations simplifiées sont représentées pour les transactions ITi et IT2. Les représentations dernièrement citées peuvent être utilisées pour l'envoi d'un message par B à C en IT-) ou en IT2 pour la réception d'un message par B d'un message émis par C. Une interaction est dite composée pour qualifier un échange entre deux entités comprenant une succession d'interactions simples. Elle peut être notée, ainsi que représenté en ITS, ITSi ou ITS2 , ainsi que représenté en figure 1 , ou être détaillée comme succession d'interactions simples.
Des données échangées au cours d'une interaction, l'interaction li(di) représentée en figure 1 , sont indiquées au-dessus et au-dessous d'une flèche d'interaction, la donnée di notée au-dessus de la double flèche de l'interaction indiquant tout ou partie d'un message envoyé par l'entité d'origine de l'interaction, une donnée notée d2 dans le cas de la figure 1 et de l'interaction h indiquant tout ou partie du message envoyé par l'entité cible C de l'interaction h en réponse au message envoyé.
Deux interactions sont dites imbriquées si ces dernières ne sont pas séquentielles, c'est-à-dire si l'une d'entre elles commence avant la fin de l'autre.
Une interaction J est une sous-interaction de I, ou J est contenue dans I, si les interactions simples qui composent l'interaction J font aussi partie de la succession des interactions simples qui définissent I.
Une description plus détaillée du procédé de paiement électronique entre un terminal multimédia et un système distant gestionnaire des paiements conforme à l'objet de la présente invention sera maintenant donnée en liaison avec la figure 2a. D'une manière générale, on rappelle que le procédé de paiement électronique objet de la présente invention est mis en œuvre entre un terminal multimédia, noté TM, et un système distant gestionnaire des paiements, noté SD.
On rappelle qu'un terminal multimédia TM est défini comme tout terminal muni d'une fonction de téléphonie mobile. Le terminal multimédia TM est réputé mettre en œuvre une ou plusieurs applications multimédia, notées AMM, par exemple.
On rappelle en outre qu'une application multimédia est une application payante, du fait que certaines des actions possibles par l'intermédiaire de cette application mise en œuvre par l'intermédiaire du terminal multimédia TM font l'objet d'un paiement géré par le système distant SD comprenant un ou plusieurs serveurs de paiement.
A titre d'exemple non limitatif, on indique que l'application AMM peut être une application ayant fait l'objet d'un téléchargement payant ou non au préalable, un cas particulier important étant celui des applications écrites en langage java.
Une application AMM peut également être constituée par la partie client, sur le terminal multimédia TM, d'une application multimédia AMMC de type client/serveur. Cette partie client AMM contient la couche présentation de AMMC et est susceptible d'utiliser le navigateur Internet du terminal multimédia TM. L'application multimédia AMM est alors en interaction avec la couche applicative AMM2 de AMMC hébergée sur un serveur distant de cette application. Dans le cas d'une application client/serveur AMMC, la partie client AMM est appelée simplement « couche présentation de AMMC » dans la suite. En référence à la figure 2a, le procédé objet de l'invention consiste à transmettre en une étape A, du terminal TM à un proxy de paiement local à ce terminal multimédia, proxy noté PP, un ordre de paiement en provenance d'au moins une application multimédia AMM hébergée par le terminal TM.
L'opération précitée est représentée de manière symbolique par la relation :
TM Mp > PP .
Dans la relation précédente, Mp désigne l'ordre ou message de paiement conformément à la convention précédemment définie dans l'introduction à la description. L'étape A est suivie d'une étape B consistant à discriminer, au niveau du proxy de paiement PP local, l'ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement.
Sur la figure 2a, l'étape B est représentée comme une étape de test visant à déterminer le caractère local ou distant du traitement effectué sur l'ordre de paiement Mp, selon la relation symbolique
Traitement local de Mp ?
L'étape B précédente est alors suivie d'une étape C consistant à procéder à un paiement selon un mode de paiement local de cet ordre de paiement au niveau du proxy de paiement PP sur critère spécifique de traitement local retenu de cet ordre de paiement.
Sinon, l'étape B est suivie d'une étape D consistant à transmettre au moins l'ordre de paiement au système distant pour procéder à un paiement selon un mode de paiement distant.
Sur la figure 2a, l'opération réalisée à l'étape D est représentée par la relation symbolique selon la transaction :
_ pp Mp >SD .
En liaison avec la figure 2a, on indique que selon un aspect particulièrement avantageux du procédé objet de la présente invention, les paiements nécessaires pour l'utilisation de l'application AMM sont autorisés par le système distant SD.
Le terminal TM héberge l'application proxy de paiement PP appartenant au système distant SD et accessible aux applications payantes par l'intermédiaire d'une A.P.I. (application programing interface, interface de programmation d'applications en français) appelée A.P.I. P. (pour A.P.I. de
Paiement). Cette interface peut donner lieu à une normalisation.
D'une manière plus spécifique, on indique que l'application AMM envoie ses ordres de paiement au proxy de paiement PP, lorsque son fonctionnement l'exige.
Lorsque l'application AMMC est du type client-serveur, c'est-à-dire constituée de la couche de présentation AMM et de la couche applicative AMM2 précédemment décrites, les ordres de paiement peuvent provenir de la couche applicative AMM2 et être transférés au proxy de paiement PP par la couche de présentation AMM, ainsi qu'il sera décrit ultérieurement dans la description.
Ainsi que représenté sur la figure 2a, on comprend que le proxy de paiement PP dispose et met en œuvre deux modes de paiement :
- le paiement local ;
- le paiement distant. L'utilisation du mode de paiement local par le proxy de paiement PP peut être liée à diverses situations :
- absence du signal réseau de téléphonie mobile, laquelle oblige à différer le contact avec le système distant SD ; - choix délibéré en raison, par exemple, d'un coût de mise en œuvre important d'un paiement distant comparé au montant de la transaction de paiement exécutée, telle qu'une transaction unitaire, un choix autre tel qu'un paiement distant étant considéré comme déraisonnable ; - choix délibéré en vue d'alléger le coût de mise en œuvre d'un paiement distant, Ie proxy de paiement PP pouvant ainsi être configuré pour agréger des transactions successives pour un même système distant SD, les transactions agrégées étant alors vues par le système distant comme une transaction unique par exemple. Dans tous les cas, l'opération de paiement suppose une mise en relation du proxy de paiement PP avec le système distant SD antérieurement ou postérieurement au paiement proprement dit.
Enfin, on rappellera que la notion de proxy correspond à celle d'une application contrôlée par le système distant SD. Cette notion recouvre celle d'un serveur de paiement mandataire contrôlé par le système distant SD.
Une description plus détaillée de l'étape B de discrimination du caractère local respectivement distant du traitement de l'ordre de paiement sera maintenant donnée en liaison avec la figure 2b. D'une manière générale, l'étape B consistant à discriminer l'ordre de paiement est définie à partir d'une pluralité de types de paiement exécutés par le proxy de paiement PP.
En référence à la figure 2b, on indique que le proxy de paiement PP dispose ainsi d'une pluralité de types de paiement, tels que par exemple, ainsi que représenté à l'étape Bo de la figure 2b :
- Ti : paiement de proximité. Le paiement de proximité est le paiement dans lequel le terminal multimédia TM est en relation avec un terminal de paiement constitué par exemple par un terminal de paiement électronique TPE ou un automate distributeur dédié dans un grand magasin ou autre ; - T2 : paiement interne. Le paiement interne est le paiement dans lequel le mode de paiement, paiement local, est utilisé indépendamment de la disponibilité du réseau.
Il s'agit donc essentiellement, mais de manière non limitative d'un paiement interne au terminal TM ; - T3 : paiement par télépaiement. Le télépaiement est le mode de paiement dans lequel le paiement distant est préféré. Lorsque le paiement est de type télépaiement, le mode de paiement utilisé peut être néanmoins un paiement local, lorsque le réseau est indisponible. En référence à la figure 2b, un exemple de mise en œuvre du processus de discrimination au niveau du proxy de paiement de l'ordre de paiement sur critères spécifiques de traitement local respectivement distant de ce dernier, c'est-à-dire de l'étape B de la figure 2a, peut comprendre de manière non limitative les étapes ci-après : - étape Bi : consistant à discriminer le type de paiement parmi les types de paiement disponibles Ti1 T2, T3, Mp de type Ti ou T2 ou T3.
Sur réponse positive au test B-i, l'un des types de paiement précités étant discriminé, s'il s'agit d'un type de paiement interne T2, alors le mode de traitement est local à l'étape C, ainsi que représenté sur la figure 2b. Si l'ordre de paiement Mp correspond à un type de paiement de proximité Ti ou de télépaiement T3, alors une étape B2 est appelée consistant à discriminer la présence respectivement l'absence de la phase φ de couverture réseau de téléphonie mobile.
L'étape B2 est représentée comme un test relativement à l'existence de phases selon la relation : 3 φ
Sur réponse négative au test B2, l'étape C de paiement d'exécution de traitement local peut être appelée. Le caractère local de ce traitement pouvant rendre nécessaire une interaction ultérieure K2, avec le système distant SD, ainsi que mentionné ultérieurement dans la description.
Sur réponse positive au test B2, un test B3 peut être appelé relativement à la valeur de la transaction, c'est-à-dire du montant facturé MF, vis- à-vis d'une valeur de seuil déterminée MFO.
Sur réponse négative au test B3, l'exécution du traitement de paiement selon un traitement local C peut alors être appelée, que le type de paiement soit un type de paiement de proximité Ti ou de télépaiement T3.
Au contraire, sur réponse positive au test B3, l'exécution du traitement distant D, peut alors être appelée pour les types de paiement Ti de proximité respectivement T3 de télépaiement. Le mode de mise en œuvre des tests Bi, B2 et B3 n'est pas limitatif, d'autres combinaisons pouvant être envisagées.
Afin de faciliter la mise en œuvre du paiement électronique conforme à l'objet de la présente invention, des moyens de paiement spécifiques peuvent être retenus, ces moyens de paiement spécifiques définissant en particulier le mode d'exécution du paiement par l'utilisateur du terminal multimédia TM pour l'obtention du service demandé par l'intermédiaire de l'application AMM.
Ainsi, le traitement local respectivement distant des ordres de paiement est, conformément à un aspect particulièrement avantageux du procédé objet de la présente invention exécuté, par l'intermédiaire d'un moyen de paiement.
Ce moyen de paiement utilise un processus de paiement choisi parmi les processus de paiement prépayé, porte-monnaie virtuel, post-payé ou de porte-monnaie électronique par exemple. L'énumération précédente n'est pas limitative, d'autres moyens de paiement assortis à des critères de contrôle d'accès par exemple pouvant être envisagés.
En particulier, lors de l'accès à des services vidéo, un moyen de paiement du type pay per view, précédemment mentionné dans la description, peut être envisagé.
D'une manière générale, on indique qu'un moyen de paiement est un moyen d'effectuer le paiement, c'est-à-dire un moyen permettant de faire payer un client utilisateur.
Ainsi, une pluralité de moyens de paiement est notée MPj, et les moyens de paiement accessibles pour l'utilisateur C d'un terminal multimédia TM sont notés MPj0, par exemple.
La notion de facturation recouvre alors l'utilisation d'un moyen de paiement suite à une action ayant pour but de faire payer.
Ainsi, un moyen de paiement MPk est un moyen de prépaiement, lorsque l'exploitant de MPk fait payer à l'utilisateur la somme nécessaire au paiement d'un achat utilisant MPk avant la mise en œuvre de MPk.
Dans le cas contraire, on dit que le moyen de paiement MPk est un moyen de post-paiement ou que MPk est post-payé. On note qu'un moyen de paiement MPk peut bien entendu gérer des transactions de paiement provenant de différents points d'émission, notamment autres que le terminal multimédia TM. Un terminal multimédia TM gère donc un sous-ensemble des transactions de paiement géré par un moyen de paiement MPk. Lorsque TM est le seul point d'émission de MPk, on dit que MPk est dédié à TM.
Une description plus détaillée d'un système de paiement électronique entre un terminal multimédia TM et un système distant SD gestionnaire de paiement conforme à l'objet de la présente invention sera maintenant donné en liaison avec la figure 3 et la figure 4.
En référence à la figure 3, on indique que le système distant SD comporte au moins un serveur de paiement, en particulier, un serveur de paiement à utiliser SP-i, interconnecté au réseau de téléphonie mobile par exemple, noté N par une interface de communication notée IM. D'autres serveurs de paiement notés SPj peuvent en outre être prévus, les différents serveurs de paiement pouvant être mis en œuvre, en particulier, par une ou plusieurs applications du terminal multimédia TM.
Le terminal multimédia TM comporte au moins une interface de communication, notée MC, de radiotéléphonie mobile, laquelle peut être reliée au serveur de paiement par l'intermédiaire du réseau N.
Ainsi que représenté en outre sur la figure 3, on indique que le terminal multimédia TM comporte au moins un proxy de paiement PP lequel reçoit en provenance d'une application multimédia, hébergé par le terminal multimédia TM, des messages ou ordres de commande. En ce qui concerne le terminal multimédia TM, on indique que celui-ci comporte bien entendu les parties d'un appareil de téléphonie mobile telles que le dispositif d'affichage, le clavier KB et le système d'exploitation OS, ainsi que bien entendu les applications implantées en mémoire permanente de ce dernier.
L'application multimédia complète AMMC est réputée, dans l'exemple de la figure 3, consister en l'application payante et, en particulier, consister en une partie AMM implantée sur le terminal multimédia TM, AMM contenant notamment le module de présentation de AMMC et consister éventuellement en une autre partie AMM2 située sur un serveur distant en liaison avec AMM par l'intermédiaire d'une interaction K3, par l'intermédiaire de l'interface de communication de radiotéléphonie mobile MC et bien entendu, du réseau N.
En référence à la figure 3, on indique que le proxy de paiement PP est monté en coupure entre AMM, c'est-à-dire la partie locale à TM de AMMC, et l'interface de communication MC, de façon à intercepter tout ordre de paiement émis par AMM, à destination du système distant SD et en particulier, du serveur de paiement SPi réputé gérer tous les ordres de paiement et éventuellement, les conditions d'accès correspondant au service demandé par l'application multimédia AMMC. A titre d'exemple non limitatif, ainsi que représenté sur la figure 3, l'utilisateur du terminal multimédia TM est réputé engendrer, à partir du clavier KB par exemple, et bien entendu du système d'exploitation OS de ce terminal, une interaction h avec la partie locale AMM de l'application multimédia, cette dernière adressant au proxy de paiement un ordre de paiement Mo au cours d'une interaction I2 afin de permettre l'accès au service demandé au cours de l'interaction l-i.
En raison de l'existence du proxy de paiement PP et des caractéristiques de ce dernier, l'ordre de paiement Mo adressé normalement à l'interface de communication MC pour être transmis à SD est intercepté par le proxy de paiement PP, ainsi que représenté sur la figure 3.
Sur réception de l'ordre de paiement Mo, le processus de traitement en mode de traitement local respectivement distant est alors mis en œuvre par le proxy de paiement PP, ainsi que mentionné précédemment dans la description. Dans ce but, le proxy de paiement PP comporte avantageusement, ainsi que représenté en figure 3, un module 1 de discrimination de cet ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement, un module 2 de traitement local de cet ordre de paiement sur critères spécifiques de traitement local retenu de cet ordre de paiement, ainsi que décrit précédemment dans la description, en liaison avec les figures 2a et 2b, et un module 3 de transmission de l'ordre de paiement MO au serveur de paiement pour procéder à un paiement selon un mode de paiement distant, dans le cas où le critère spécifique de traitement local n'a pas été retenu pour l'ordre de paiement M0 considéré. La transmission de l'ordre de paiement Mo au serveur de paiement, en particulier au serveur de paiement SPi est bien entendu réalisée par l'intermédiaire de l'interface de communication de radiotéléphonie mobile MC dont dispose le terminal multimédia TM. Sur la figure 3, on a représenté l'interaction !2(M0) et sa réponse r, réponse du proxy de paiement PP à l'application multimédia AMM selon les conventions précédemment mentionnées.
Toutefois, entre la réception de l'ordre de paiement Mo et la réponse r précitée, le proxy de paiement PP peut contacter l'utilisateur du terminal multimédia TM au cours d'une interaction 13(CA) afin d'obtenir l'accord de ce dernier ou simplement lui notifier le paiement effectué. L'interaction Is(CA) précitée contient une commande ou ordre d'affichage CA envoyée au terminal de téléphonie mobile, en particulier aux parties OS et afficheur du terminal multimédia TM. La commande précitée permet d'afficher une demande de confirmation à l'utilisateur.
Si la commande d'affichage CA a pour objet d'obtenir l'accord de l'utilisateur, c'est-à-dire s'il ne s'agit pas d'une simple notification, le message de commande d'affichage CA contient dans ce but les éléments de la transaction permettant au titulaire utilisateur du terminal multimédia TM de prendre sa décision en connaissance de cause.
Si la réponse de l'utilisateur est positive, une réponse r0 peut être envoyée, la réponse positive étant notée OK représentée entre crochets sur la figure 3. Le message de réponse r0 comporte avantageusement des données d'identification personnelle notées [PIN].
Lorsque la réponse est positive OK, le traitement de l'ordre de paiement est poursuivi selon le mode de traitement local ou distant, ainsi que décrit précédemment dans la description. Si la réponse de l'utilisateur est négative, NOK, alors l'application multimédia AMM est immédiatement informée par le proxy de paiement PP, par l'intermédiaire de la réponse r à l'interaction 12(Mo).
Le traitement de l'ordre de paiement Mo n'est alors pas poursuivi. Dans un mode de réalisation préférentiel, l'ordre ou commande d'affichage CA peut contenir une demande d'authentificàtion de l'utilisateur du terminal multimédia TM ainsi qu'il sera décrit ultérieurement dans la description.
En particulier, lorsque le terminal multimédia TM est constitué par un terminal de téléphonie mobile, par exemple GSM, muni d'une carte SIM, le proxy de paiement PP est alors de manière particulièrement avantageuse hébergé au moins partiellement sur Ia carte SIM. Ce mode de mise en œuvre n'est pas réservé aux terminaux de téléphonie mobile GSM.
En particulier, lorsque le terminal multimédia TM comporte un module de sécurité de terminal multimédia SM, ce module est bien entendu utilisé aux fins d'assurer l'intégrité du proxy de paiement PP.
En particulier, lorsque le terminal de téléphonie mobile est un terminal GSM, ce module de sécurité SM est formé par la carte SIM (pour « Subscriber Identification Module ») de ce dernier. De préférence, le proxy de paiement PP est constitué avantageusement par une application, c'est-à-dire un logiciel d'application directement téléchargeable sur le terminal multimédia TM.
On comprend en particulier que le logiciel ou application téléchargeable précitée permet alors de réaliser la fonction de serveur mandataire précédemment mentionnée dans la description dans les conditions de discrimination du mode de traitement local respectivement distant ainsi que décrit précédemment dans la description, en liaison avec les figures 2a, 2b.
L'intégrité du code téléchargé peut alors être contrôlé par le module de sécurité SM, en particulier, la carte SIM, ces derniers disposant d'éléments ou ressources de cryptographie nécessaires.
Par exemple, le code de l'application téléchargée pour réaliser la fonction de proxy de paiement PP peut être signé, cette signature étant contrôlée par le module de sécurité SM, et, en particulier, la carte SIM précédemment mentionnée, laquelle détient la clé publique de l'entité ayant signé le code de l'application précitée.
L'intégrité de la clé publique est également protégée par le terminal multimédia TM et en particulier par l'hébergement de la clé publique précitée dans le module de sécurité SM. D'une manière générale, on indique que les modules de sécurité peuvent être amovibles.
C'est en particulier le cas des terminaux de téléphonie mobile du réseau GSM, lesquels utilisent une carte SIM comprenant une puce ou module de sécurité, l'ensemble étant désigné carte SIM.
Lors du changement de la carte SIM, la carte d'origine peut être placée dans un autre terminal multimédia.
Lorsque un module de sécurité SM est utilisé et que ce dernier est amovible, et si le proxy de paiement PP est totalement hébergé dans le module de sécurité SM, alors le changement de terminal ne pose pas de problème.
Le module de sécurité SM peut alors être simplement inséré dans un nouveau terminal compatible pour que le système objet de l'invention soit en mesure de fonctionner correctement.
Si un module de sécurité SM est utilisé et que ce dernier est également amovible et si le proxy de paiement PP est hébergé totalement ou en partie ailleurs que dans le module de sécurité, la partie du proxy de paiement PP qui n'est pas hébergée dans le module de sécurité SM peut être chargée dans ce dernier si celui-ci dispose d'un espace mémoire libre suffisant, avant retrait du module de sécurité SM. Sinon, un coffre-fort logiciel peut avantageusement être utilisé pour protéger le proxy de paiement PP ou la partie de ce dernier qui n'est pas hébergée dans le module de sécurité SM, avant son déplacement dans le nouveau terminal multimédia.
On rappelle qu'un coffre-fort logiciel est défini comme un moyen de chiffrer et de déchiffrer des données et qui peut être mis en œuvre à l'aide d'un mot de passe, le même mot de passe étant lui-même utilisé pour chiffrer et déchiffrer des données à protéger.
Un chiffrement/déchiffrement symétrique à clé unique peut être par exemple utilisé. Le coffre-fort logiciel peut être chargé dans le module de sécurité SM, lorsque ce dernier dispose d'un espace mémoire libre suffisant. Sinon, il peut également être « télédéchargé » sur un serveur prévu à cet effet, en attendant d'être téléchargé dans le nouveau terminal. Un tel mode opératoire de mise en œuvre du système objet de l'invention suppose la mise en place de l'infrastructure de clés et algorithmes cryptographiques nécessaires.
On précise que la notion de télédéchargement est utilisée pour traduire le terme anglais « upload » désignant le transfert de données vers le serveur.
Une variante de mise en œuvre du système de paiement électronique objet de la présente invention sera maintenant décrite en liaison avec la figure 4.
En référence à la figure précitée, le terminal multimédia TM comporte en outre une interface à courte portée, notée ICP, permettant d'exécuter une application par l'intermédiaire d'un terminal de paiement électronique externe, noté TP, sur la même figure.
Ceci permet de gérer les types de paiement de proximité par l'intermédiaire du proxy de paiement PP, ainsi qu'il sera décrit ci-après. On comprend en particulier que l'interface à courte portée ICP peut être présente au niveau du terminal de téléphonie mobile hébergeant l'application AMM correspondante.
Dans cette situation, l'utilisateur du terminal multimédia TM est en situation dite de proximité. A titre d'exemple, il se trouve dans l'enceinte d'un commerce traditionnel et dispose de son terminal multimédia TM.
Le commerce traditionnel précité est équipé d'un terminal de paiement, tel qu'un terminal de paiement électronique TP, par exemple, muni d'une interface standardisée utilisant des ondes électromagnétiques à courte portée.
Cette interface à courte portée ICP peut être constituée par une interface de type infrarouge (IRDA), de type RFID (RFIDi4443) par exemple, de type Bluetooth ou encore Wifi.
L'utilisateur du terminal multimédia TM en situation de proximité peut également se trouver en face d'un automate, par exemple un automate distributeur muni également d'une interface à courte portée.
Le terminal multimédia TM est supposé disposer des moyens nécessaires pour dialoguer avec le terminal de paiement électronique TP. L'ensemble de ces moyens regroupés sous le terme d'interface à courte portée ICP contient également les ressources nécessaires afin de router des messages vers leur destination, notamment lorsque plusieurs destinations sont possibles. C'est le cas par exemple si l'interaction optionnelle l-i, représentée en figure 4, est prévue et qu'elle comporte au moins un envoi de messages de l'interface à courte portée ICP vers le système d'exploitation OS du terminal de téléphonie mobile.
L'interaction h permet de dialoguer avec le système d'exploitation, essentiellement le terminal multimédia excepté les fonctions spécifiques à l'objet de l'invention, soit indépendamment du proxy de paiement PP.
L'interaction précitée est optionnelle car les messages qu'elle véhicule peuvent également transiter le cas échéant par le proxy de paiement PP, par exemple au cours des interactions b et I3 représentées en figure 4 ou au cours d'interactions non représentées.
Lorsqu'un tel dialogue transite par l'intermédiaire du proxy de paiement PP, ce dernier est alors à même de contrôler le dialogue entre le terminal de paiement électronique TP et l'utilisateur.
Après avoir signifié son intention de procéder à un paiement, l'utilisateur du terminal multimédia TM, dans la situation de la figure 4, c'est-à-dire de l'utilisation d'une interface à courte portée ICP munie de son terminal multimédia TM, est invité à se rapprocher du terminal de paiement TP suffisamment pour que le système à courte portée précité fonctionne.
Dans le cas d'un commerce de proximité avec un terminal de paiement électronique, l'hôtesse de caisse du magasin effectue les manipulations nécessaires sur le terminal de paiement électronique TP, ces manipulations ayant pour effet de déclencher l'interaction J initiée par le terminal de paiement
TP.
Dans le cas d'un automate, ce sont les manipulations de l'utilisateur lui-même sur le terminal multimédia TM qui déclenchent cette interaction.
Par l'intermédiaire de l'interaction h, le client est invité à autoriser l'utilisation de son terminal multimédia TM pour un paiement de type paiement de proximité et donc à autoriser le dialogue de son terminal mobile TM avec le terminal de paiement TP. Lorsque cette autorisation est accordée, l'interaction I2, déjà décrite dans le cadre du premier mode de réalisation représenté en figure 3, permet au terminal de paiement électronique TP, d'envoyer un ordre de paiement Mo au proxy de paiement PP, en respectant le format imposé par son interface APIP. Le proxy de paiement PP, ainsi que décrit précédemment, initie l'interaction I3 avec le terminal de téléphonie mobile et en particulier, le système d'exploitation OS de ce dernier pour obtenir l'accord de l'utilisateur.
Ce dernier peut alors être invité à saisir un code d'identification, code PIN personnel afin de réaliser l'authentification de l'utilisateur. Le proxy de paiement PP interprète la réponse ro et s'il en déduit que l'utilisateur a été correctement authentifié et que son accord, lorsque ce dernier est requis, a effectivement été donné, traite l'ordre de paiement reçu en I2, ainsi que décrit précédemment dans la description.
La réponse r2 de l'interface à courte portée ICP au terminal de paiement TP contient les éléments utiles de la réponse r.
Ainsi que décrit dans le scénario précédent de proximité, certains des éléments de la réponse r peuvent être signés par le proxy de paiement PP et/ou le système distant SD. La, ou les signatures produites, peuvent être transmises par l'intermédiaire de la réponse r2 au terminal de paiement électronique TP pour servir de preuve de paiement.
Différentes indications seront données ci-après relatives à la mise en œuvre de certaines fonctionnalités dans le cadre du premier et du deuxième mode de réalisation représentés en figures 3 et 4 du système de paiement électronique objet de la présente invention. D'une manière générale, le système de paiement électronique objet de la présente invention présente un haut niveau de sécurité.
Dans ce but, le proxy de paiement PP est avantageusement protégé en accès écriture/lecture par un module de contrôle d'accès et de chiffrement/déchiffrement des données par mot de passe, module 4 précédemment décrit dans la description.
En particulier, le terminal multimédia TM comporte un module de sécurité contenant des ressources cryptographiques permettant de vérifier la signature du proxy de paiement PP, lorsque ce dernier est téléchargé sous forme d'une application dans le terminal multimédia. En outre, la sécurité des échanges est assurée de manière particulièrement stricte dans les conditions ci-après.
En référence aux figures 3 et 4, on indique que la réponse r à l'ordre de paiement b (MO) ou bien certains éléments de cette réponse peuvent être signés à l'aide d'une clé privée (CP) protégée par le terminal de téléphonie mobile et bien entendu, par le proxy de paiement PP.
La clé privée CP est représentée comme accessible par le proxy de paiement PP sur les figures 3 et 4.
La clé privée CP est celle pour laquelle un certificat de la clé publique associée a été publiée.
Parmi les éléments de la réponse r peuvent en particulier figurer les données signées par le système distant SD et provenant de la réponse π à la transaction K-ι(Mi), représentée sur les figures 3 et 4.
Les signatures précitées permettent à l'application multimédia AMMC de conserver une preuve de paiement, laquelle peut être utilisée en cas de contestation, lorsque le crédit du compte de l'exploitant de l'application AMMC n'est pas reconnu.
La preuve précitée peut être par exemple transmise à l'application multimédia déportée AMM2, représentée sur la figure 3, ou le cas échéant être déposée régulièrement sur un autre serveur.
Ainsi que représenté sur les figures 3 et 4, la clé privée CP précitée peut avoir été définie dans le cadre d'un système PKI préexistant et peut avantageusement être hébergée dans la carte SIM du terminal de téléphonie mobile constitutif du terminal multimédia TM. La carte SIM peut être remplacée par le module WIM pour Wireless
Identification Module du terminal de téléphonie mobile ou par la carte UICC (Universal Integrated Circuit Card).
Différents scenarii de paiement mis en œuvre conjointement par le premier mode de réalisation représenté en figure 3 et le deuxième mode de réalisation représenté en figure 4 du système de paiement électronique objet de la présente invention, le cas échéant de scenarii spécifiques à chacun d'eux, seront maintenant donnés ci-après.
D'une manière générale, on indique qu'un moyen de paiement MPk est associé à un serveur de paiement SPk.muni d'une interface Ifk, lui permettant de recevoir des messages de paiement pour lesquels il donne ou non en temps réel une réponse.
Ces messages sont échangés au cours d'interactions notées Kj.
A titre d'exemple, un message de paiement pour un moyen de paiement MP0 peut être une demande d'autorisation si l'interface lf0 de MPo le permet.
La réponse à ce message de paiement peut être positive ou négative.
Dans le cas où un message de demande d'autorisation est envoyé, l'interface Ifo doit prévoir la gestion d'une confirmation de paiement qui est un autre type de message de paiement.
Une telle confirmation de paiement n'est envoyée que suite à une demande d'autorisation dont la réponse était positive. Le client n'est effectivement facturé par le moyen de paiement MPo que si la communication de paiement a été reçue. La réponse à une confirmation de paiement peut être un simple acquittement indiquant la prise en compte par le serveur de paiement SPo du message considéré.
Une confirmation de paiement peut être désignée comme remise ou encore capture, notamment si elle est notablement différée par rapport au moment du paiement du client demandeur.
Un message de paiement peut également être une demande de débit en outre suivie d'une réponse positive ou négative.
Une réponse positive à ce message de paiement signifie alors que le client demandeur est ou sera de toute façon facturé. Lorsque le sous-ensemble des transactions gérées par le terminal multimédia TM pour un moyen de paiement MPk comprend en fait toutes les transactions gérées par le moyen de paiement considéré MPk, alors tous les paiements effectués à l'aide du moyen de paiement MPk sont dans le champ de traitement du proxy de paiement PP. On dit alors que le moyen de paiement MPk considéré est dédié au proxy de paiement PP et donc finalement au terminal multimédia.
Une telle situation de recouvrement facilite la gestion des paiements par le proxy de paiement PP, ainsi qu'il sera expliqué ci-après. La description ci-après décrit un scénario pour les types de paiement précédemment décrits dans la description T2 paiement interne ou T3 télépaiement.
Initialisation du paiement. Lorsque l'utilisateur initie une action payante au cours de l'utilisation de l'application AMMC, cette dernière détecte la nécessité d'un paiement et la partie locale AMM de l'application multimédia AMMC transmet un ordre de paiement M0 via l'interaction I2 précédemment décrite en liaison avec les figures 3 et 4 au proxy de paiement PP par l'intermédiaire de l'API, APIP. Cet ordre de paiement M0 est pris en charge par le proxy de paiement
PP.
Protection du proxy de paiement PP et sécurité de l'application de paiement.
En raison du fait que le proxy de paiement PP est une application locale protégée, ainsi que décrit précédemment dans la description, détenu par le système distant SD, quoique hébergé dans le terminal multimédia TM, son comportement ne peut être modifié par le détenteur utilisateur du terminal multimédia TM.
Traitement local de l'ordre de paiement, cas du paiement interne : Si le type de paiement correspond au type T2, paiement interne, l'ordre de paiement Mo est traité en local par le proxy de paiement PP, indépendamment de la disponibilité du réseau, branche joignant la sortie positive du test Bi de la figure 2b pour T2, à l'étape C de la figure 2b.
Le proxy de paiement PP traite cet ordre de paiement à l'aide de sa base d'informations locales et envoie la réponse r à la partie locale AMM de l'application multimédia AMMC. La réponse r peut être transmise à la partie distante AMM2, lorsque celle-ci existe.
On indique en particulier que le paiement local est avantageusement réalisé selon un cas particulier, lorsque le mode de paiement est un porte- monnaie électronique local.
Traitement local de l'ordre de paiement, cas du télépaiement :
Dans ce cas, ainsi que représenté en figure 2b, le mode de paiement distant ou local dépend essentiellement de la disponibilité du réseau, c'est-à-dire du test de l'étape B2 de la figure 2b. On note que la réponse du proxy de paiement PP à l'application multimédia AMMC peut évidemment varier selon que la connexion au système distant SD est possible ou non, l'indisponibilité de la phase réseau forçant le proxy de paiement PP à utiliser des critères locaux pour prendre la décision d'autoriser ou non un ordre de paiement. a) Cas du réseau disponible :
Si le type de paiement est le type T3 de télépaiement et si le réseau est disponible conformément au test B2 de la figure 2b, le mode de paiement, paiement distant est utilisé par appel de l'étape D à la figure 2b.
Suite à la réception de l'ordre de paiement Mo, un ordre de paiement Mi est transmis, par l'intermédiaire d'une interaction Ki au système distant SD, ainsi que représenté en figures 3 et 4.
On note en outre que, dans le cas du télépaiement, le premier message de paiement envoyé au système distant SD peut être une demande d'autorisation. Dans le cadre de la mise en œuvre du système objet de la présente invention, cette demande d'autorisation fait suite à un ordre de paiement :
Si Mi est une demande d'autorisation, une transaction K2 différée peut être mise en œuvre pour confirmer la transaction.
En raison du fait que le système distant SD était disponible et accessible, ce dernier renvoie la réponse π au proxy de paiement PP. Ce dernier traite éventuellement cette réponse, notamment à l'aide de sa base d'informations locales puis envoie sa propre réponse r à la partie locale AMM de l'application multimédia AMMC.
Cette réponse comprend notamment les éléments de la réponse u utiles à l'application AMMC.
Des éléments utiles précités peuvent alors être transmis à la partie déportée AMM2 de l'application multimédia, lorsque celle-ci existe. b) Cas du réseau indisponible :
Dans le cas où le type de paiement est T3 télépaiement et si le réseau n'est pas disponible, c'est-à-dire sur réponse négative au test B2 de la figure 2b, le mode de paiement local étape C sur la même figure précitée est utilisé. L'ordre de paiement M0 est alors traité en local par le proxy de paiement PP. Puisque le système distant SD n'était pas disponible, le proxy de paiement PP traite l'ordre de paiement en local à l'aide des informations dont il dispose dans sa base d'informations locales.
L'absence de coopération du système distant SD peut par exemple conduire à l'utilisation de critères plus stricts pour l'envoi d'une réponse positive à l'ordre de paiement.
Dans tous les cas, on rappelle que la réponse r du proxy de paiement PP à l'ordre de paiement Mo, réponse positive ou négative peut être signée.
Enfin, on indique que dans le cas où le terminal multimédia est constitué à partir d'un terminal de téléphonie mobile, du réseau GSM, la disponibilité du réseau peut être connue de la carte SIM si elle interroge MC, laquelle peut alors communiquer cette information directement au proxy de paiement PP.
Dans cette situation, l'hébergement de ce dernier dans le module de sécurité et, en particulier, dans la carte SIM, apparaît particulièrement avantageux.
Traitement différé, description de l'interaction K? représentée en figure 3 et 4.
Lorsque le mode de traitement de paiement correspond à un paiement local, c'est-à-dire que l'ordre de paiement Mo a été traité en local, soit dans le cas du paiement interne ou du télépaiement avec réseau indisponible, une interaction différée K2 peut être utilisée pour envoyer les éléments de la transaction au système distant SD, ainsi qu'il a été indiqué précédemment dans le cas du télépaiement. Le déclenchement de l'interaction différée K2 peut être lié à un événement extérieur indépendant par exemple à l'occasion d'un autre paiement du client ou encore suite à une demande explicite de la partie déportée AMM2 de l'application multimédia AMMC ou lié à un événement de type date par exemple. Ainsi, l'interaction K2 peut être déclenchée par le proxy de paiement PP, par exemple après expiration d'un certain délai déterminé.
L'expiration du délai précité peut être contrôlée par le proxy de paiement PP, par exemple grâce à une lecture régulière de la date reçue du réseau. Les éléments de plusieurs transactions peuvent être envoyées au cours de la même interaction K2 en une remise groupée.
La transaction K2 précitée peut contenir la somme des montants des transactions qu'elle transporte. Lorsque cette somme est présente dans la transaction K2, les montants des transactions individuelles peuvent ne pas être transmis. On dit alors que l'on transmet un agrégat de transactions.
Traitement en local de l'ordre de paiement
La réponse r du proxy de paiement PP à l'application multimédia AMMC est donnée en fonction d'une base d'informations conservée en local. La description qui suit donne des exemples d'informations conservées localement pour ou par le proxy de paiement PP et de traitements associés à ces informations.
Dans la description qui suit, lorsqu'une variable est munie d'un indice k, la variable utilisée correspond à la gestion du moyen de paiement MPk. Historique des ordres de paiement et des réponses données
Le proxy de paiement PP est en mesure de gérer pour chaque moyen de paiement MPk l'historique des ordres de paiement OPkj où j est un numéro de référence de transaction par exemple.
Le proxy de paiement PP peut également gérer l'historique des réponses η, déjà données en local, et en distant par le système distant SD, où j est le numéro de la transaction.
Ces historiques peuvent être utilisés pour la constitution de messages de paiement de remise avec connexion au système distant SD.
Profil du moyen de paiement Le proxy de paiement PP peut gérer le profil du moyen de paiement
MPk à savoir le fait que la moyen de paiement utilise un processus de paiement prépayé, post payé ou de porte-monnaie électronique par exemple.
Porte-monnaie électronique local :
Le proxy de paiement PP peut gérer par exemple un porte-monnaie électronique local, noté PMVLk, constitué par un ensemble de variables comportant au moins le solde du porte-monnaie Sk.
Un tel porte-monnaie électronique utilise exclusivement le type de paiement « paiement interne » par exemple. Les autorités exploitant le proxy de paiement PP et le moyen de paiement MPk doivent alors offrir au client un moyen de rechargement du solde Sk. Le rechargement du moyen de paiement MPk peut utiliser éventuellement un autre moyen de paiement MPj avec j ≠k ou finalement tout autre moyen de paiement.
D'une manière générale on indique que le proxy de paiement PP peut gérer un forfait local noté FFk formé par un ensemble de variables comportant au moins le solde du forfait Sk. Le moyen de paiement MPk est alors un forfait local utilisant exclusivement le type de paiement « paiement interne ». Le client possesseur du terminal multimédia achète en fait un forfait local MPk de montant S et dispose de cette somme pendant un intervalle de temps défini P appelé « période ». En fin de période, le montant restant devient alors inutilisable. Les exploitants précédemment cités dans le cas du porte-monnaie électronique permettent alors à l'utilisateur possesseur du forfait local précité de disposer d'un moyen d'achat de ce forfait local de façon à mettre en place un moyen d'initialisation du solde Sk à la valeur S. Le proxy de paiement PP peut également gérer un forfait local récurrent noté FLRk formé par un ensemble de variables comportant au moins le solde du forfait Sk. Dans cette situation, le moyen de paiement MPk est un forfait local récurrent utilisant exclusivement le type de paiement « paiement interne ». Lorsque le client utilisateur s'abonne à un forfait local MPk il dispose alors de la somme S pendant un intervalle de temps défini P appelé « période ». En fin de période le solde Sk est réinitialisé à la valeur S indépendamment de la valeur précédente. La somme S devient à nouveau disponible pour la période suivante, en général de même durée que la précédente, et ainsi de suite. Les exploitants du forfait local récurrent doivent offrir au client utilisateur un moyen d'abonnement et de désabonnement au forfait local récurrent ainsi qu'un moyen de réinitialiser le solde périodiquement, et donc d'effectuer le paiement nécessaire à l'abonnement.
Enfin, le proxy de paiement PP peut permettre la gestion d'un solde local noté SLk, par exemple lorsque le moyen de paiement MPk utilisé est un porte-monnaie virtuel, et d'un montant total des dépenses effectuées en local MTDLk. Les variables SLk et MTDLk doivent constamment vérifier la relation MTDLk < SLk. Lors d'une connexion au système distant SD, ces deux variables sont remises à jour : MTDLk est remis à zéro et SLk prend une nouvelle valeur, qui tient compte, notamment, des paiements effectués avec MPk mais sans TM, si MPk n'est pas dédié à TM.
On indique à titre d'exemple non limitatif que le proxy de paiement PP peut également gérer le montant total dépensé MTDk et le plafond de dépenses PDk sur une période donnée de manière connue en tant que telle. Le montant total dépensé MTDk doit être compris comme la somme de toutes les dépenses effectuées sur la période en cours avec le moyen de paiement MPk et qui ont fait l'objet d'un ordre de paiement par l'intermédiaire du proxy de paiement PP.
En particulier, lorsque le moyen de paiement est dédié au proxy de paiement PP, les notions de plafond et montant de dépenses locaux précédemment cités sont identiques aux mêmes notions définies pour le moyen de paiement MPk dans son ensemble, car le proxy de paiement PP est compétent pour traiter tous les paiements utilisant MPk.
La période en cours est définie comme une période contenant l'instant où la valeur de MTDk « montant total dépensé » est prise en considération.
Si le moyen de paiement MPk est un moyen de paiement interne, la période en cours peut être par exemple l'intervalle de temps entre deux messages de remise prévus par le moyen de paiement MPk.
Si MPk est un moyen de télépaiement, la période en cours peut être aussi l'intervalle de temps entre deux paiements avec connexion au système distant SD permise par la disponibilité du réseau.
En ce qui concerne la gestion du plafond de dépenses PDk, ce dernier peut être considéré comme valable pour chaque période considérée. D'autres modes de gestion d'entités de porte-monnaie électronique peuvent également être introduites, sans sortir du cadre de l'objet de la présente invention.

Claims

REVENDICATIONS
1. Procédé de paiement électronique entre un terminal multimédia et un système distant gestionnaire de paiements, caractérisé en ce qu'il consiste à :
- transmettre du terminal multimédia à un proxy de paiement local à ce terminal multimédia, un ordre de paiement, en provenance d'au moins une application multimédia hébergée par ledit terminal multimédia ;
- discriminer, au niveau dudit proxy de paiement local, ledit ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement ; - procéder à un paiement selon un mode de paiement local de cet ordre de paiement au niveau dudit proxy de paiement sur critère spécifique de traitement local retenu de cet ordre de paiement ; sinon,
- transmettre au moins ledit ordre de paiement audit système distant, pour procéder à un paiement, selon un mode de traitement distant.
2. Procédé de paiement électronique selon la revendication 1 , caractérisé en ce que l'étape consistant à discriminer ledit ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement est définie à partir d'une pluralité de types de paiement exécutés par ledit proxy.
3. Procédé selon la revendication 2, caractérisé en ce que ledit proxy est apte à exécuter au moins :
- le paiement de proximité ;
- le paiement interne ;
- le télépaiement.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que le critère de sélection de l'exécution du type de paiement est fonction de la présence respectivement l'absence de la couverture réseau.
5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que ledit mode de traitement local respectivement distant est exécuté par l'intermédiaire d'un moyen de paiement, ledit moyen de paiement utilisant un processus de paiement choisi au moins parmi les processus de paiement prépayé, post-payé ou de porte-monnaie électronique.
6. Système de paiement électronique entre un terminal multimédia et un système distant gestionnaire de paiements, ledit système distant comportant au moins un serveur de paiement, ledit terminal multimédia comportant au moins une interface de communication de radiotéléphonie mobile reliée auxdits serveurs de paiement, caractérisé en ce que ledit terminal multimédia comporte au moins un proxy de paiement recevant, en provenance d'au moins une application multimédia hébergée par ledit terminal multimédia, un ordre de paiement et monté en coupure entre ladite application et ladite interface de communication, de façon à intercepter tout ordre de paiement émis par ladite application, ledit proxy de paiement comportant au moins :
- des moyens de discrimination de cet ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement ;
- des moyens de traitement local de cet ordre de paiement, sur critère spécifique de traitement local retenu de cet ordre de paiement ;
- des moyens de transmission dudit ordre de paiement auxdits serveurs de paiement, pour procéder à un paiement selon un mode de paiement distant, sinon, par l'intermédiaire de ladite interface de communication.
7. Système selon la revendication 6, caractérisé en ce que ledit terminal multimédia étant constitué par un terminal de téléphonie mobile GSM muni d'une carte SIM, ledit proxy de paiement est hébergé sur ladite carte SIM.
8. Système selon l'une des revendications 6 ou 7, caractérisé en ce que ledit proxy de paiement est constitué par une application directement téléchargeable sur ledit terminal multimédia.
9. Système selon l'une des revendications 6 à 8 précédentes, caractérisé en ce que ledit terminal multimédia comporte en outre une interface à courte portée, permettant d'exécuter une application par l'intermédiaire d'un terminal de paiement électronique externe, ce qui permet de gérer les types de paiement de proximité par l'intermédiaire dudit proxy de paiement.
10. Système selon l'une des revendications 6 à 9, caractérisé en ce que ledit proxy de paiement est protégé en accès écriture/lecture par un module de contrôle d'accès et de chiffrement/déchiffrement des données par mot de passe.
11. Système selon l'une des revendications 6 à 10, caractérisé en ce que ladite application hébergée par ledit terminal multimédia et ledit proxy de paiement sont gérés par au moins un même serveur de paiement constituant ledit système distant.
12. Système selon l'une des revendications 6 à 11 , caractérisé en ce que ledit terminal multimédia comporte un module de sécurité, ledit module contenant au moins des ressources cryptographiques permettant de vérifier la signature dudit proxy de paiement, lorsque ce dernier est téléchargé sous forme d'une application dans ledit terminal multimédia.
13. Terminal multimédia, comportant au moins une interface de communication de radiotéléphonie mobile, caractérisé en ce qu'il comporte au moins un proxy de paiement recevant, en provenance d'au moins une application multimédia hébergée dans ce terminal multimédia, un ordre de paiement, ledit proxy de paiement étant monté en coupure entre ladite application et ladite interface de communication, de façon à intercepter tout ordre de paiement émis par ladite application.
14. Produit logiciel enregistré sur un support de mémorisation pour exécution par un microprocesseur installé dans un proxy de paiement, ledit produit logiciel comportant au moins :
- un module de discrimination d'un ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement ;
- un module de traitement local de cet ordre de paiement, sur critère spécifique de traitement local retenu de cet ordre de paiement ; - un module de transmission de cet ordre de paiement à au moins un serveur de paiement, pour procéder à un paiement selon un mode de paiement distant, sinon, par l'intermédiaire d'une interface de communication.
EP04767533A 2004-06-30 2004-06-30 Procede et systeme de paiement electronique universel Ceased EP1771827A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR2004/001690 WO2006010800A1 (fr) 2004-06-30 2004-06-30 Procede et systeme de paiement electronique universel

Publications (1)

Publication Number Publication Date
EP1771827A1 true EP1771827A1 (fr) 2007-04-11

Family

ID=34958622

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04767533A Ceased EP1771827A1 (fr) 2004-06-30 2004-06-30 Procede et systeme de paiement electronique universel

Country Status (5)

Country Link
US (1) US8341088B2 (fr)
EP (1) EP1771827A1 (fr)
JP (1) JP4730694B2 (fr)
KR (1) KR101048729B1 (fr)
WO (1) WO2006010800A1 (fr)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200929974A (en) * 2007-11-19 2009-07-01 Ibm System and method for performing electronic transactions
US9098869B2 (en) 2008-06-25 2015-08-04 Telefonaktiebolaget L M Ericsson (Publ) Dynamic payment methods and devices
US9734496B2 (en) 2009-05-29 2017-08-15 Paypal, Inc. Trusted remote attestation agent (TRAA)
US9135424B2 (en) * 2009-05-29 2015-09-15 Paypal, Inc. Secure identity binding (SIB)
US20100306531A1 (en) * 2009-05-29 2010-12-02 Ebay Inc. Hardware-Based Zero-Knowledge Strong Authentication (H0KSA)
US20100306076A1 (en) * 2009-05-29 2010-12-02 Ebay Inc. Trusted Integrity Manager (TIM)
US8650614B2 (en) * 2009-05-29 2014-02-11 Ebay Inc. Interactive phishing detection (IPD)
KR20130116905A (ko) * 2010-12-30 2013-10-24 에스케이씨앤씨 주식회사 모바일 지갑 및 그의 관련 정보 관리 시스템 및 방법
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US9691056B2 (en) 2012-03-07 2017-06-27 Clearxchange, Llc System and method for transferring funds
US20140025581A1 (en) * 2012-07-19 2014-01-23 Bank Of America Corporation Mobile transactions using authorized tokens
US9043609B2 (en) 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
US10176478B2 (en) * 2012-10-23 2019-01-08 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
WO2014158331A1 (fr) * 2013-03-26 2014-10-02 Jvl Ventures, Llc Systèmes, procédés et produits de programmes informatiques permettant de gérer l'activation de portefeuilles
FR3009107B1 (fr) * 2013-07-26 2016-12-23 Cie Ind Et Financiere D'ingenierie Ingenico Dispositif de securisation d'un clavier capacitif et terminal correspondant.
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151566B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11138582B2 (en) * 2017-06-14 2021-10-05 The Toronto-Dominion Bank Real-time execution of data exchanges between computing systems based on selectively allocated parameters

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040117623A1 (en) * 2002-08-30 2004-06-17 Kabushiki Kaisha Toshiba Methods and apparatus for secure data communication links

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
EP0917119A3 (fr) * 1997-11-12 2001-01-10 Citicorp Development Center, Inc. Portemonnaie électronique réparti basé sur un reseau
US6272492B1 (en) * 1997-11-21 2001-08-07 Ibm Corporation Front-end proxy for transparently increasing web server functionality
FR2779896B1 (fr) * 1998-06-15 2000-10-13 Sfr Sa PROCEDE POUR PAYER A DISTANCE, AU MOYEN D'UN RADIOTELEPHONIQUE MOBILE, l'ACQUISITION D'UN BIEN ET/OU D'UN SERVICE ET SYSTEME ET RADIOTELEPHONE MOBILE CORRESPONDANTS
US6250557B1 (en) * 1998-08-25 2001-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for a smart card wallet and uses thereof
FI105243B (fi) * 1999-01-13 2000-06-30 Sonera Oyj Menetelmä ja järjestelmä maksunhallintaan
DE19903822C2 (de) * 1999-02-02 2001-09-20 Mathias Entenmann Verfahren zur Durchführung bargeldloser Zahlungen und System zur Durchführung des Verfahrens
FI105364B (fi) * 1999-02-09 2000-07-31 Sonera Oyj Menetelmä ja järjestelmä sanomien välitykseen
FI106495B (fi) * 1999-04-12 2001-02-15 Nokia Mobile Phones Ltd Verkkoelementti
AU5450900A (en) * 1999-06-03 2000-12-28 Automated Business Companies Advanced wireless phone system
FR2800540B1 (fr) * 1999-10-28 2001-11-30 Bull Cp8 Terminal securise muni d'un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
EP1107198B1 (fr) * 1999-11-30 2007-01-10 Citibank, Na Système et méthode pour effectuer une transaction électronique avec un portefeuille électronique à l'aide d'un mandataire de transaction
WO2001071681A2 (fr) 2000-03-17 2001-09-27 Virtual Money, Inc. Interface de paiement electronique a zone d'entree unique sur internet
US6542872B1 (en) * 2000-05-16 2003-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Brand positioning within electronic personal devices
AU2002250134A1 (en) * 2001-02-21 2002-09-12 Citibank, N.A. Method and system for electronic commerce using a mobile communication system
WO2002080121A2 (fr) * 2001-03-29 2002-10-10 Telefonaktiebolaget L M Ericsson (Publ) Procede et systeme d'achat de biens
US7542942B2 (en) * 2001-07-10 2009-06-02 American Express Travel Related Services Company, Inc. System and method for securing sensitive information during completion of a transaction
FI20011312A (fi) * 2001-06-20 2002-12-21 Nokia Corp Parannettu menetelmä ja järjestely sähköisen maksumenettelyn hoitamiseksi
US7463133B2 (en) * 2001-07-10 2008-12-09 American Express Travel Related Services Company, Inc. Systems and methods for providing a RF transaction device operable to store multiple distinct calling card accounts
WO2003044710A1 (fr) * 2001-10-11 2003-05-30 Trustcopy Pte Ltd Appareil, procede et systeme de paiement faisant appel a un dispositif mobile
US7536181B2 (en) * 2002-02-15 2009-05-19 Telefonaktiebolaget L M Ericsson (Publ) Platform system for mobile terminals
GB0204620D0 (en) * 2002-02-28 2002-04-10 Europay Internat N V Chip authentication programme
KR100475654B1 (ko) * 2002-03-15 2005-03-15 주식회사 하렉스인포텍 휴대단말기를 이용한 금융결제의 사용자 인터페이스 방법
GB2387253B (en) * 2002-04-03 2004-02-18 Swivel Technologies Ltd System and method for secure credit and debit card transactions
US7792759B2 (en) * 2002-07-29 2010-09-07 Emv Co. Llc Methods for performing transactions in a wireless environment
US7149510B2 (en) * 2002-09-23 2006-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Security access manager in middleware
KR20040052132A (ko) * 2002-12-13 2004-06-19 에스케이 텔레콤주식회사 이동통신 단말기로의 가맹점 멤버쉽 프로그램 다운로드방법 및 시스템
US7357309B2 (en) * 2004-01-16 2008-04-15 Telefonaktiebolaget Lm Ericsson (Publ) EMV transactions in mobile terminals

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040117623A1 (en) * 2002-08-30 2004-06-17 Kabushiki Kaisha Toshiba Methods and apparatus for secure data communication links

Also Published As

Publication number Publication date
JP2008504618A (ja) 2008-02-14
JP4730694B2 (ja) 2011-07-20
US8341088B2 (en) 2012-12-25
KR101048729B1 (ko) 2011-07-14
US20080294563A1 (en) 2008-11-27
WO2006010800A1 (fr) 2006-02-02
KR20070028484A (ko) 2007-03-12

Similar Documents

Publication Publication Date Title
EP1771827A1 (fr) Procede et systeme de paiement electronique universel
EP3243176B1 (fr) Procédé de traitement d&#39;une transaction à partir d&#39;un terminal de communication
EP1004101B1 (fr) Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
EP2715631B1 (fr) Procede de paiement a distance, a partir d&#39;un dispositif utilisateur, d&#39;un panier d&#39;achat sur un serveur marchand et systeme associe
WO2002065414A1 (fr) Procede et systeme de telepaiement
EP1709598A2 (fr) Dispositif transactionnel a pre-traitement anticipe
WO2015059389A1 (fr) Procede d&#39;execution d&#39;une transaction entre un premier terminal et un deuxieme terminal
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d&#39;ordinateur et methode correspondants.
EP3132403A1 (fr) Dispositif de traitement de données en provenance de carte à mémoire sans contact, méthode et programme d&#39;ordinateur correspondant
FR3069356A1 (fr) Procede et systeme de gestion d&#39;un paiement par porte-monnaie electronique
WO2002001432A1 (fr) Procede de distribution commerciale en ligne de biens numeriques par l&#39;intermediaire d&#39;un reseau de communication et dispositif electronique d&#39;achat de biens numeriques distribues par ce procede
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
WO2020128240A1 (fr) Traitement d&#39;un service de tickets electroniques
FR3104760A1 (fr) Procede, serveur et systeme d’authentification de transaction utilisant deux canaux de communication
EP3113094B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d&#39;information bancaire sur le reseau public et quasi-public
EP3382628A1 (fr) Procédé de traitement de données par un terminal de paiement, terminal de paiement et programme correspondant
FR2980890A1 (fr) Procede et systeme de paiement, application a la location automatisee de vehicules.
EP1965342A1 (fr) Procédé pour effectuer une transaction entre un module de paiement et un module de sécurité
WO2005088568A1 (fr) Procede et systeme de micropaiement
EP4348459A1 (fr) Procédé de traitement d&#39;une transaction, dispositif et programme correspondant
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l&#39;un d&#39;eux
FR2995711A1 (fr) Procede et systeme de paiement adapte a un equipement communicant de type horodateur ou distributeur automatique

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061222

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: PAILLES, JEAN-CLAUDE

Inventor name: DE SOLAGES, AYMERIC

Inventor name: BOUTAHAR, MOHAMMED

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20071009

RIN1 Information on inventor provided before grant (corrected)

Inventor name: PAILLES, JEAN-CLAUDE

Inventor name: BOUTAHAR, MOHAMMED

Inventor name: DE SOLAGES, AYMERIC

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BOUTAHAR, MOHAMMED

Inventor name: PAILLES, JEAN-CLAUDE

Inventor name: DE SOLAGES, AYMERIC

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20210902