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.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=34958622

Family Applications (1)

Country Status (5)

Families Citing this family (37)

Citations (1)

Family Cites Families (28)

• 2004
  • 2004-06-30 EP EP04767533A patent/EP1771827A1/de not_active Ceased
  • 2004-06-30 WO PCT/FR2004/001690 patent/WO2006010800A1/fr not_active Application Discontinuation
  • 2004-06-30 US US11/631,172 patent/US8341088B2/en active Active
  • 2004-06-30 KR KR1020067027964A patent/KR101048729B1/ko active IP Right Grant
  • 2004-06-30 JP JP2007518632A patent/JP4730694B2/ja not_active Expired - Lifetime

Patent Citations (1)

Also Published As

Similar Documents

Legal Events