WO2006016000A1 - Metodo para realizar transacciones de pago o cobro seguras, utilizando telefonos moviles programables - Google Patents

Metodo para realizar transacciones de pago o cobro seguras, utilizando telefonos moviles programables Download PDF

Info

Publication number
WO2006016000A1
WO2006016000A1 PCT/ES2005/070115 ES2005070115W WO2006016000A1 WO 2006016000 A1 WO2006016000 A1 WO 2006016000A1 ES 2005070115 W ES2005070115 W ES 2005070115W WO 2006016000 A1 WO2006016000 A1 WO 2006016000A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
mobile phone
transaction
application
transaction server
Prior art date
Application number
PCT/ES2005/070115
Other languages
English (en)
French (fr)
Inventor
José Ignacio Bas Bayod
Francisco Bas Bayod
Fernando Bas Bayod
Original Assignee
Bas Bayod Jose Ignacio
Francisco Bas Bayod
Fernando Bas Bayod
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 Bas Bayod Jose Ignacio, Francisco Bas Bayod, Fernando Bas Bayod filed Critical Bas Bayod Jose Ignacio
Priority to EP05782628A priority Critical patent/EP1772832A1/en
Priority to US11/658,950 priority patent/US20080091614A1/en
Publication of WO2006016000A1 publication Critical patent/WO2006016000A1/es
Priority to US13/069,759 priority patent/US9342664B2/en

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • 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/04—Payment circuits
    • 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/322—Aspects of commerce using mobile devices [M-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/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
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • 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/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/081—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying self-generating credentials, e.g. instead of receiving credentials from an authority or from another peer, the credentials are generated at the entity itself
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Definitions

  • the present invention falls within the technical sector of telecommunications and refers to a valid method for terminals based on programmable mobile phones with Internet connection, for payment or payment transactions, in which the use of up to 5 verification elements of the user by the system, make such transactions safe.
  • the 5 elements used by the system to identify a user can be: 1) the data of the credit / debit card, or debit bank account; 2) the user's mobile phone number 3) the user's personal identification number (PIN); 4) the information on the user's SIM card that the mobile terminal sends as an identifier when it connects to the Internet, currently using HTTP headers, information that can be read by the server for transactions; and 5) an access code (CA) that the application server assigns to the new user, which is stored in the memory of the mobile phone.
  • CA access code
  • the use of a specific application loaded on the phone allows the introduction and sending of data, the authorization of the transaction and the verification of this by the user to be carried out on the same connection and in a simple way, which makes it more flexible system.
  • the universality of the application also allows the system to be used unchanged with any mobile phone, in any country and using any mobile phone operator with Internet access service.
  • the use of a specific application and the robustness and security of the system allow the seller not to have card reader devices, or other auxiliary elements, other than their own mobile phone, to make their charges. On the other hand, the buyer does not need to have his mobile phone when making the purchase, since the seller's terminal can be used to fully carry out the transaction.
  • the system to which the method is applied consists of a transaction server and a plurality of programmable mobile phones, in which it has previously been downloaded
  • REPLACEMENT SHEET (Rule 26) an application for this purpose (eg written in Java).
  • the purchase application is designed to make payments, being mainly used in non-face-to-face sales transactions (by reference, payments in virtual merchants or vending machines).
  • the user starts the application, enters the amount to be paid, the personal identification number (PIN), the telephone number of the seller
  • the transaction server sends a different session encryption key for each connection.
  • the application loaded on the phone encrypts the session key with the fixed encryption key, assigned to each user at the time of registration, thus generating a modified session key, adds the phone's own number to the data entered by the user and the access key (CA), both extracted from the memory of the mobile phone itself, and sends them encrypted with the modified session key, to the transaction server.
  • the transaction server will receive the encrypted data, encrypt the session key that it previously generated with the fixed encryption key, and with this modified key it will decrypt that data.
  • Another option would be to use the SSL protocol, in which case it would not be necessary to generate encryption keys for each user, said encryption / decryption process being automatically performed by the system.
  • the user receives an acceptance message.
  • the application for sales is designed to make collections.
  • it is the seller who starts the application.
  • the seller enters the amount receivable and optionally the reference number of the sale (RV), and asks the customer to enter the mobile phone number assigned to the transaction system and his personal identification number .
  • the transaction server will then send the session encryption key.
  • This key is in turn encrypted by the application loaded on the phone with the fixed encryption key, thus generating a modified session key.
  • REPLACEMENT SHEET (Rule 26) Access code (CA), retrieved by the application from the phone memory, are encrypted with the modified session key and sent to the transaction server.
  • the server will recover the buyer's fixed encryption key from his mobile phone number, encrypt the original session key using said fixed key, generating the modified session key and decrypt the data received using said modified key.
  • the option to use the SSL protocol is also applicable here.
  • both terminals, the seller's and the buyer's receive, where appropriate, two messages of the acceptance of the operation.
  • the server receives the information, reads the content of the HTTP headers (in each headers each SIM card is identified), and decrypted, in its In this case, the data received as explained (except for the mobile phone number of the buyer, in the case of a sale transaction), using all this information to identify the users involved in the transaction and finally carry out said transaction, or deny it .
  • the operation once validated, will consist of a monetary transfer between the account assigned to the buyer user and the account of the seller user, both identified by the HTTP headers generated by the mobile terminal for each SIM card, or by the numbers of their mobile phones or for both at the same time.
  • the registration of a user in the system can be done through the user's access to a WEB page on the transaction server, where personal data and credit / debit cards are entered. other bank accounts, and is identified, by means of a registration reference, authenticating it later, in a preferred execution of the invention, by sending a short SMS message by the user (in case of using the mobile phone number as
  • REPLACEMENT SHEET (Rule 26) identifier) and an HTTP connection to said server, which must include said registration reference in the communication.
  • the transaction server extracts the mobile phone number and HTTP headers and after validating all the data of the bank cards or accounts, saves all this information in its database, for the subsequent identification of the user who is registered.
  • Electronic payment is a modality that has become popular over time.
  • systems that allow you to perform this payment method. In principle, these systems were based entirely on traditional telephone wire communications and magnetic card readers located in stores. But with the advent of the Internet and mobile telephony, new methods of remote payment have been appearing.
  • a mobile phone payment system is known, which is based on the association of a credit / debit card number with a PIN and a mobile phone number on the transaction server.
  • the procedure followed by this system is basically the authorization of the operation by the user, once the transaction data has been received on his mobile phone. The transaction is not made as long as the user does not confirm it through their terminal, entering their secret PIN.
  • the communication with the user, in order to authorize said transaction is carried out by means of a data call from the transaction server, which controls the introduction of data from the keypad and the representation of information on the telephone screen.
  • a POS In face-to-face purchase, a POS is required and it needs to be prepared for payment with that system, since it must initiate the transaction through a special call to a telephone number, managed by the transaction server.
  • This system suffers from rigidity, because communication with the user is carried out through a data call, which makes it difficult for the system to be transnational, having to have transaction servers in each country.
  • the system requires taking control of the mobile terminal, and said control depends on the different brands and models of mobile phones, not being said standardized control, it is required to have different modules for each existing model, and include those of the new models, which
  • REPLACEMENT SHEET (Rule 26) subtract universality.
  • the user is forced to learn new operations when using different models.
  • a connection through the WAP protocol which allows for greater standardization, would significantly increase the process for the user, due to the large amount of data required in such connections.
  • the use of the limited keypad of the mobile terminal for the introduction of alphanumeric data required in the transactions, in a WAP connection would slow the process of those, in case the mobile terminal is used as a buy / sell terminal.
  • the actual conception of the system itself requires the presence and use of POS terminals in stores.
  • the buy / sell terminals are the mobile phones of the users of the system.
  • the phones are programmable and must be loaded with a specific application (eg written in Java), downloaded by the user from an application server, or from another storage medium, such as a computer equipped with disk readers, or pre-charged by the phone manufacturer.
  • a specific application eg written in Java
  • Another storage medium such as a computer equipped with disk readers, or pre-charged by the phone manufacturer.
  • System security is achieved through user verification, being able to use up to 5 significant elements (ES) of unrelated information, or difficult relationship, such as a) personal data and credit / debit cards, or other accounts financial, b) the personal identification number (PIN), c) the mobile phone number, d) the HTTP headers of information of the SIM cards, sent by the mobile terminals and e) an access key (CA), assigned to each user by the transaction server and stored in the mobile phone memory when downloading the application, or in a subsequent configuration.
  • ES significant elements
  • PIN personal identification number
  • CA access key
  • REPLACEMENT SHEET (Rule 26) any country and using any mobile phone operator.
  • Cost The cost of transactions for the user or for the transaction server manager is minimal, due once again to the fact that the application loaded on the phone allows an optimal flow of data between the terminal and the transaction server.
  • Fig. 1 shows a preferred execution of the patent to carry out both purchase and sale transactions.
  • Fig. 2 shows a preferred execution of the registration process of a user in the system.
  • Fig. 3 shows a preferred execution of the application download process in the mobile terminal
  • Fig. 4 shows a preferred execution of the mobile terminal configuration process
  • Fig. 5 shows a preferred execution of a purchase transaction
  • Fig. 6 shows a preferred execution of a sales transaction
  • the user In order for the system to be used, the user is required to register with the system. In fig. 2 you can see how the user starts the registration process on the transaction server. This registration, as seen in this preferred execution, can be done on a web page designed for this purpose, and consists of the introduction of your personal data and the data of credit / debit cards or financial accounts.
  • the system generates a registration reference. Subsequently, the user sends an SMS (short message) to the transaction server containing said registration reference.
  • the server reads the SMS and extracts the mobile telephone number and the registration reference, attaching said telephone number to the user's data and
  • REPLACEMENT SHEET (Rule 26) entered, and identified by said reference. Using the mobile phone number could enhance security in the future, in addition to simplifying its memorization.
  • the user using a mobile phone with the same SIM card with which he sent the previous SMS, if necessary, makes an HTTP connection to a web page of the server, and also sends the previous registration reference.
  • the transaction server reads the registration reference and the HTTP header relative to the identification of the user's SIM card.
  • the server generates a fixed encryption key, associated with each user, stores it in the database, in the registry associated with the user, and shows it to the user through the registration web page, page that will be downloaded in the user's computer system using a secure protocol.
  • the user must copy said encryption key to their mobile phone when configuring the terminal, using the latter's keyboard.
  • This encryption key could also be automatically uploaded to the phone in the configuration process, using a secure protocol, such as SSL.
  • the transaction server will generate a different access key (CA) for each user and also store it in the database. Once this process is done, the user can download the application to his terminal, as seen in fig. 3, without more than accessing a web page of the server and start the download.
  • CA access key
  • the transaction server will read the mobile phone number and the access code (CA) associated with the user, encrypt both data with the fixed encryption key and add both data to the file to be downloaded, along with the application itself. Finally, the file will be downloaded to the mobile phone.
  • the data attached to the application are stored in the memory of the mobile phone for later use. This data will be subsequently decrypted and stored by the application, when the user configures and stores the fixed encryption key in the terminal.
  • the mobile phone number and alphanumeric key (CA) can also be loaded manually, using the mobile phone's own keypad, or remotely, via a secure post-Internet connection (for example using the SSL protocol), or using any other type of electronic communication, in the configuration process.
  • REPLACEMENT SHEET (Rule 26) purchase, (3) sale, (4) transaction verification. Initially, only the configuration option is enabled. In figure 4 you can see how the application allows you to configure the terminal either in PURCHASE mode or in SALE mode. Once the terminal has been configured, the PURCHASE (2) or SALE (3) options, and the transaction verification option (4) will be enabled, and the terminal will be ready to perform transactions.
  • the user To initiate a purchase transaction, the user must start the application and select the PURCHASE option (2) from the menu. As seen in fig. 5, when accessing the purchase option, the application shows 3 empty fields in which the user must enter the amount to be paid, the personal identification number and the mobile phone number of the seller. The application will then interrogate the user about the need to use a purchase reference (RC) in the transaction. If the answer is yes, a fourth empty field will appear, where the user will enter said purchase reference (RC), assigned by the seller. After connection, the terminal will send to the server the telephone number corresponding to the buyer, recovered from the terminal's memory.
  • RC purchase reference
  • the transaction server will then generate and send to the terminal a session encryption key, in turn encrypted by means of the fixed encryption key corresponding to the buyer, determined by the telephone number previously sent, if it exists in the database.
  • the transaction would be finalized, sending a message to the user through the connection still open.
  • This key will be received and decrypted by the application using the fixed encryption key, stored in the terminal memory, thus obtaining the session key, which will be known by both terminal and server.
  • the data corresponding to the transaction together with the access code (CA) and the number of the mobile phone itself, recovered from the terminal's memory, are encrypted by the application with that session key, and sent via GPRS , UMTS or other cellular data transmission protocol, to the transaction server, over the Internet.
  • CA access code
  • the transaction server accesses the associated database, where it searches for the record identified by the corresponding HTTP header, or by the user's own mobile phone number, where appropriate, that would be sent without encrypt. If there is no such registration, the transaction will be terminated, a message is sent to the user in
  • the transaction will be terminated, also sending a warning message to the user through the established connection. If they match, the mobile phone number and the access code (CA) sent with those existing in the database will be compared. If any comparison is unsuccessful, the transaction ends, sending the corresponding warning message to the user. If all the data match, the transaction will be considered correct.
  • CA access code
  • a transfer of funds will be made between the account associated with the user referred to in the identified registry and the account belonging to the user referred by the seller's mobile phone number, previously entered by the buyer and sent by the mobile terminal, and corresponding to the purchase referenced in the optional purchase reference (RC) field that was previously sent from the terminal, or quantified by the transaction amount field, also sent from the terminal.
  • RC optional purchase reference
  • the transaction will be terminated, and a confirmation message will be sent to the user, using the same connection, still open, and encrypted using the session key. This message will show the most relevant data of the transaction.
  • the transaction server will keep a history of all transactions made by the system, whether correct or erroneous.
  • the SSL protocol could be used in this case in an equivalent way.
  • fig. 6 shows the process followed in a sale transaction.
  • the seller must start the application and select in the menu the option of SALE (3).
  • RV sales reference field
  • the seller asks the buyer to enter his mobile phone number and personal identification number, which will conclude the data entry.
  • the application will finally retrieve the vendor's own mobile phone number and the access code (CA), from the terminal's memory.
  • the application then connects to the transaction server through a GPRS connection, UMTS or other data transmission protocol and sends the
  • REPLACEMENT SHEET Telephone number corresponding to the seller.
  • the transaction server sends a session encryption key, in turn encrypted with the fixed encryption key corresponding to the seller, if it exists in the database.
  • the application receives and decrypts the session key by means of the fixed encryption key, stored in the terminal's memory, a session key that will be known by both the terminal and the server. Then it encrypts the previous transaction data using said session key and sends them to the server. All data is encrypted, except the seller's mobile phone number, if applicable, that is sent without encryption.
  • the transaction server receives certain information from the encrypted seller and buyer, the seller's phone number, as well as the HTTP identification headers of the SIM card.
  • the transaction server decrypts the information using the session key and checks whether both the record referenced by the corresponding HTTP header (or by the vendor's own mobile phone number, if applicable), As the buyer's record, referenced by their phone number, they exist. If any of these records is non-existent, the transaction ends, sending an error message to the seller's terminal, through the connection still open. If the personal identification number of the buyer thus decrypted does not match the PIN that is associated with the buyer registration through the mobile phone number received in the connection, the transaction ends, and an error message is sent to the seller's terminal. If both NBPs match, the vendor's mobile phone number associated with the HTTP identification header and the access code (CA) will be read (if applicable).
  • CA access code
  • the transaction is considered correct and the transfer of funds is made between the buyer's account, referenced by his mobile phone number, and the seller's account, referenced by the HTTP header corresponding (or by your mobile phone number).
  • the transaction server keeps a history of all transactions made, whether valid or erroneous, including the sales reference (RV), attached if it has been entered by the seller in the terminal.
  • a confirmation message will be sent to the seller's terminal, using the connection still open, being previously encrypted using the session key. If the buyer wants to know the result of the transaction, he must use option (4) of his transactions menu.
  • PIN personal identification number
  • REPLACEMENT SHEET (Rule 26) Buyer's mobile.
  • the transaction server will receive the HTTP header of the SIM card identification, or if necessary, the mobile phone number of the buyer, will read the record associated with the user in the database, generate and send the session encryption key to the terminal , encrypted said key with the fixed encryption key associated with the buyer, and will send the confirmation message encrypted with said session key.
  • the server will encrypt and also send the corresponding PIN to the user.
  • the application will decrypt the session key with the fixed encryption key, stored in the terminal memory, obtaining the session key, it will decrypt the confirmation message using said session key, it will also decrypt the sent PIN, compare it with the entered PIN and if both match, it will show the confirmation message on the terminal screen.
  • the option of using the SSL secure protocol could be used in an equivalent manner.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Método para realizar transacciones de pago o cobro seguras, utilizando teléfonos móviles programables. La utilización de teléfonos programables -como por ejemplo con tecnología Java-, en los cuales se carga una aplicaciÌn (p. ej. aplicación Java), permite su uso como terminales de transacciones de cobro o pago seguras. La aplicación permite al comprador/vendedor realizar la transacción, incluyendo la verificación, en una sola conexión. Los datos enviados son encriptados y transmitidos mediante GPRS u otro protocolo de transmisión de datos a un servidor de transacciones, donde las transacciones son verificadas y autorizadas. La seguridad del proceso la confiere principalmente el uso de hasta cinco elementos de identificación no relacionados, incluyendo una clave de acceso única para cada usuario, almacenada en el teléfono móvil.

Description

Descripción
MÉTODO PARA REALIZAR TRANSACCIONES DE PAGO O COBRO SEGURAS, UTILIZANDO TELEFONOS MÓVILES PROGRAMABLES
La presente invención se encuadra en el sector técnico de las telecomunicaciones y se refiere a un método válido para terminales basados en teléfonos móviles programables con conexión a Internet, para transacciones de cobro o pago, en el que el uso de hasta 5 elementos de verificación del usuario por el sistema, hacen que dichas transacciones sean seguras. Los 5 elementos utilizados por el sistema para identificar a un usuario pueden ser: 1) los datos de la tarjeta de crédito/débito, o cuenta bancaria de débito; 2) el número del teléfono móvil del usuario 3) el número de identificación personal del usuario (NIP); 4) la información sobre la tarjeta SIM del usuario que el terminal móvil envía como identificador cuando conecta a Internet, actualmente mediante cabeceras HTTP, información que puede ser leída por el servidor de, transacciones; y 5) una clave de acceso (CA) que el servidor de aplicaciones asigna al nuevo usuario, siendo ésta almacenada en la memoria del teléfono móvil.
Asimismo, el uso de una aplicación específica cargada en el teléfono permite que la introducción y envío de datos, la autorización de la transacción y la verificación de ésta por el usuario se realicen en la misma conexión y de una manera sencilla, lo que flexibiliza el sistema. La universalidad de la aplicación permite además que el sistema sea usado sin cambios con cualquier teléfono móvil, en cualquier país y utilizando cualquier operador de telefonía móvil con servicio de acceso a Internet. Además, el uso de una aplicación específica y la robustez y seguridad del sistema permiten que el vendedor no requiera disponer de dispositivos lectores de tarjetas, ni otros elementos auxiliares, que no sean su propio teléfono móvil, para realizar sus cobros. Por otro lado, el comprador no requiere disponer de su teléfono móvil al realizar la compra, ya que el terminal del vendedor se puede utilizar para realizar íntegramente la transacción.
El sistema al que se aplica el método está compuesto por un servidor de transacciones y una pluralidad de teléfonos móviles programables, en los que previamente se ha descargado
HOJA DE REEMPLAZO (Regla 26) una aplicación al efecto (p. ej. escrita en Java). La aplicación para compras está diseñada para realizar pagos, siendo principalmente usada en transacciones de venta no presencial (por referencia, pagos en comercios virtuales o en máquinas vending). En este caso, en una ejecución preferida de la invención, el usuario inicia la aplicación, introduce la cantidad a pagar, el número de identificación personal (NIP), el número telefónico del vendedor
(indicado por la máquina expendedora o el comercio virtual) y en su caso el número de referencia de la compra, y envía dichos datos al servidor de transacciones. Previamente, el servidor de transacciones envía una clave de encriptación de sesión diferente para cada conexión. La aplicación cargada en el teléfono encripta la clave de sesión con la clave de encriptación fija, asignada a cada usuario en el momento del alta, generando pues una clave de sesión modificada, añade a los datos introducidos por el usuario el número propio del teléfono y la clave de acceso (CA), extraídos ambos de la memoria del propio teléfono móvil, y los envía encriptados con la clave de sesión modificada, al servidor de transacciones. El servidor de transacciones recibirá los datos encriptados, encriptará la clave de sesión que previamente generó con la clave de encriptación fija, y con esta clave modificada desencriptará dichos datos. Otra opción sería utilizar el protocolo SSL, en cuyo caso no sería necesaria la generación de claves de encriptación para cada usuario, siendo dicho proceso de encriptación/desencriptación automáticamente realizado por el sistema.
Una vez validada la operación, mediante la comprobación de la identidad del usuario, disponibilidad de crédito y en su caso, de la existencia de una referencia válida asociada a un determinado importe, el usuario recibe un mensaje de aceptación.
La aplicación para ventas está diseñada para realizar cobros. En este caso, es el vendedor quién inicia la aplicación. En una ejecución preferida de la invención, el vendedor introduce la cantidad a cobrar y opcionalmente el número de referencia de la venta (RV), y pide al cliente que introduzca el número de teléfono móvil asignado al sistema de transacciones y su número de identificación personal. El servidor de transacciones enviará entonces la clave de encriptación de sesión. Dicha clave es a su vez encriptada por la aplicación cargada en el teléfono con la clave de encriptación fija, generando pues una clave de sesión modificada. Por último, estos datos, salvo el número de teléfono del comprador, que se envía sin encriptar, además del número telefónico propio del terminal del vendedor y de la
HOJA DE REEMPLAZO (Regla 26) clave de acceso (CA), recuperados por la aplicación de la memoria del teléfono, son encriptados con la clave de sesión modificada y enviados al servidor de transacciones. El servidor recuperará la clave de encriptación fija del comprador a partir de su número de teléfono móvil, encriptará la clave de sesión original utilizando dicha clave fija, generando la clave de sesión modificada y desencriptará los datos recibidos utilizando dicha clave modificada. La opción de utilización del protocolo SSL es aquí también aplicable.
Una vez validada la operación por el servidor de transacciones, ambos terminales, el del vendedor y el del comprador reciben, en su caso, sendos mensajes de la aceptación de la operación.
Tanto en la aplicación de compras, como en la de ventas, en una ejecución preferida de la invención, el servidor recibe la información, lee el contenido de las cabeceras HTTP (en dichas cabeceras se identifica cada tarjeta SIM), y desencripta, en su caso, los datos recibidos como se ha explicado (salvo el número del teléfono móvil del comprador, en el caso de una transacción de venta), usando toda esa información para identificar a los usuarios implicados en la transacción y realizar finalmente dicha transacción, o denegarla. La operación, una vez validada, consistirá en un traspaso monetario entre la cuenta asignada al usuario comprador y la cuenta del usuario vendedor, ambas identificadas por las cabeceras HTTP generadas por el terminal móvil para cada tarjeta SIM, o por los números de sus teléfonos móviles o por ambos a la vez. En caso de no utilizar las cabeceras HTTP en la identificación del usuario, los teléfonos móviles propios de los usuarios, tanto en modo compra como en modo venta, serían enviados sin encriptar. Ambas aplicaciones (de compra y venta), pueden ser incluidas, por economía y uniformidad, en una sola aplicación, configurable por el usuario para operar en un modo u otro.
El alta de un usuario en el sistema, sin ser excluyente de un medio presencial, puede realizarse mediante el acceso del usuario a una página WEB en el servidor de transacciones, en donde se introducen los datos personales y de las tarjetas de crédito/débito u otras cuentas bancarias, y es identificada, mediante una referencia de alta, autentificándose ésta posteriormente, en una ejecución preferida de la invención, mediante el envío por el usuario de un mensaje corto SMS (en caso de utilizar el número de teléfono móvil como
HOJA DE REEMPLAZO (Regla 26) identificador) y una conexión HTTP a dicho servidor, los cuales deben incluir dicha referencia de alta en la comunicación. El servidor de transacciones extrae el número del teléfono móvil y las cabeceras HTTP y tras validar todos los datos de las tarjetas o cuentas bancarias, guarda toda esta información en su base de datos, para la posterior identificación del usuario que se da de alta.
ANTECEDENTES DE LA INVENCIÓN
El pago electrónico es una modalidad que ha ido popularizándose a lo largo del tiempo. Existen multitud de sistemas conocidos que permiten realizar dicha modalidad de pago. En principio, estos sistemas se basaban completamente en las comunicaciones telefónicas tradicionales por cable y en lectores de tarjetas de banda magnética situados en los comercios. Pero con el advenimiento de Internet y de la telefonía móvil, nuevos métodos de pago a distancia han ido apareciendo. En concreto, es conocido un sistema de pago mediante teléfonos móviles, el cuál está basado en la asociación de un número de tarjeta de crédito/débito con un PIN y un número de teléfono móvil en el servidor de transacciones. El procedimiento seguido por este sistema es, básicamente, la autorización de la operación por el usuario, una vez recibidos los datos de la transacción en su teléfono móvil. La transacción no es realizada en tanto en cuanto el usuario no la confirme mediante su terminal, introduciendo su PIN secreto. La comunicación con el usuario, para autorizar dicha transacción, se realiza mediante una llamada de datos desde el servidor de transacciones, el cuál pasa a controlar la introducción de datos desde el teclado y la representación de información en la pantalla del teléfono. En compra presencial, un TPV es requerido y éste requiere estar preparado para pago con ese sistema, puesto que debe iniciar la transacción mediante una llamada especial a un número telefónico, gestionado por el servidor de transacciones.
Este sistema adolece de rigidez, debido a que la comunicación con el usuario se realiza a través de una llamada de datos, lo que dificulta que el sistema sea transnacional, debiendo tener servidores de transacciones en cada país. Por otro lado, debido a que el sistema requiere tomar el control del terminal móvil, y dicho control depende de las distintas marcas y modelos de teléfonos móviles, no estando dicho control estandarizado, se requiere disponer de módulos distintos para cada modelo existente, e incluir los de los nuevos modelos, lo que le
HOJA DE REEMPLAZO (Regla 26) resta universalidad. Además al usuario se le fuerza a aprender nuevas operatorias cuando usa distintos modelos. Una conexión a través del protocolo WAP, la cual permite lograr una mayor estandarización, encarecería notablemente el proceso para el usuario, debido a la gran cantidad de datos requeridos en las conexiones de dicho tipo. De otro lado, la utilización del limitado teclado del terminal móvil para la introducción de datos alfanuméricos requeridos en las transacciones, en una conexión WAP, haría lento el proceso de aquéllas, en caso de utilizarse el terminal móvil como terminal de compra/venta. Por último, la propia concepción actual del sistema requiere la presencia y uso de terminales TPV en los comercios.
EXPLICACIÓN DE LA INVENCIÓN
Para mejorar los sistemas antes mencionados, se ha desarrollado un nuevo método de cobro/pago mediante teléfono móvil, con las siguientes características:
1) Los terminales de compra/venta son los propios teléfonos móviles de los usuarios del sistema. Los teléfonos son programables y deben ser cargados con una aplicación específica (p. ej. escrita en Java), descargada por el usuario de un servidor de aplicaciones, o desde otro medio de almacenamiento, como por ejemplo un ordenador equipado con lectores de disco, o bien pre-cargada por el fabricante del teléfono. 2) Seguridad. La seguridad del sistema se consigue mediante la verificación del usuario, pudiendo usar hasta 5 elementos significativos (ES) de información no relacionada, o de difícil relación, como son a) los datos personales y de las tarjetas de crédito/débito, u otras cuentas financieras, b) el número de identificación personal (NIP), c) el número del teléfono móvil, d) las cabeceras HTTP de información de las tarjetas SIM, enviadas por los terminales móviles y e) una clave de acceso (CA), asignada a cada usuario por el servidor de transacciones y almacenada en la memoria del teléfono móvil al realizar la descarga de la aplicación, o en una configuración posterior.
3) Flexibilidad. La flexibilidad del sistema se debe a que todos los datos a introducir en una transacción pueden ser numéricos, lo que permite una cómoda introducción de éstos mediante el teclado del teléfono móvil.
4) Universalidad. Debida a la utilización de una aplicación específica en el teléfono móvil, lo que permite al teléfono ser usado como terminal de compra/venta en
HOJA DE REEMPLAZO (Regla 26) cualquier país y utilizando cualquier operador de telefonía móvil.
5) Coste. El coste de las transacciones para el usuario o para el gestor del servidor de transacciones es mínimo, debido una vez más a que la aplicación cargada en el teléfono permite un flujo óptimo de datos entre el terminal y el servidor de transacciones.
El alcance y contenido de la presente invención se mostrará con más claridad mediante dibujos, que muestran una ejecución preferida de la misma, donde:
La fig. 1 muestra una ejecución preferida de la patente para realizar transacciones tanto de compra como de venta.
La fig. 2 muestra una ejecución preferida del proceso de alta de un usuario en el sistema.
La fig. 3 muestra una ejecución preferida del proceso de descarga de la aplicación en el terminal móvil La fig. 4 muestra una ejecución preferida del proceso de configuración del terminal móvil
La fig. 5 muestra una ejecución preferida de una transacción de compra
La fig. 6 muestra una ejecución preferida de una transacción de venta
En la fig. 1 se pueden ver varios terminales de compra/venta, cargados con la aplicación Java, lo que les permite transmitir los datos de identificación del usuario al servidor de transacciones, para que éste verifique y valide las transacciones. Asimismo, la aplicación les permite recibir y visualizar los resultados de las últimas transacciones realizadas.
Para que el sistema pueda ser usado, se requiere que el usuario se dé de alta en el sistema. En la fig. 2 se puede ver cómo el usuario comienza el proceso de alta en el servidor de transacciones. Esta alta, según se ve en esta ejecución preferida, puede ser realizada en una página WEB diseñada al efecto, y consiste en la introducción de sus datos personales y los datos de las tarjetas de crédito/débito o cuentas financieras. El sistema genera una referencia de alta. Posteriormente, el usuario envía al servidor de transacciones un SMS (mensaje corto) conteniendo dicha referencia de alta. El servidor lee el SMS y extrae el número de teléfono móvil y la referencia de alta, adjuntando dicho número telefónico a los datos del usuario ya
HOJA DE REEMPLAZO (Regla 26) introducidos, e identificados por dicha referencia. El hecho de utilizar el número de teléfono móvil podría potenciar la seguridad en el futuro, además de simplificar su memorización.
Finalmente, el usuario, utilizando un teléfono móvil con la misma tarjeta SIM con la que ha enviado el SMS anterior, en su caso, realiza una conexión HTTP a una página WEB del servidor, y envía asimismo la anterior referencia de alta. El servidor de transacciones lee la referencia de alta y la cabecera HTTP relativa a la identificación de la tarjeta SIM del usuario.
Finalmente almacena dicha cabecera junto con los datos de usuario ya introducidos, identificados por la referencia de alta previamente enviada mediante el SMS (mensaje corto).
En este mismo proceso, el servidor genera una clave de encriptación fija, asociada a cada usuario, la almacena en la base de datos, en el registro asociado al usuario, y la muestra a éste mediante la página WEB de altas, página que será descargada en el sistema informático del usuario utilizando un protocolo seguro. El usuario deberá copiar dicha clave de encriptación en su teléfono móvil a la hora de configurar el terminal, utilizando el teclado de éste. Esta clave de encriptación podría ser también cargada automáticamente en el teléfono en el proceso de configuración, utilizando un protocolo seguro, como SSL. Finalmente, el servidor de transacciones generará una clave de acceso (CA) distinta para cada usuario y la almacenará asimismo en la base de datos. Una vez realizado este proceso, el usuario puede descargar la aplicación en su terminal, según se ve en la fig. 3, sin más que acceder a una página WEB del servidor e iniciar la descarga. El servidor de transacciones leerá el número de teléfono móvil y la clave de acceso (CA) asociados al usuario, encriptará ambos datos con la clave de encriptación fija y añadirá ambos datos al fichero a descargar, junto con la propia aplicación. Finalmente, el fichero será descargado en el teléfono móvil. Los datos adjuntados a la aplicación son almacenados en la memoria del teléfono móvil para su posterior uso. Esos datos serán posteriormente desencriptados y almacenados por la aplicación, cuando el usuario configure y almacene la clave de encriptación fija en el terminal. La carga del número de teléfono móvil y de la clave alfanumérica (CA) podría también realizarse de forma manual, utilizando el teclado del propio teléfono móvil, o de forma remota, mediante conexión segura posterior a Internet (por ejemplo utilizando el protocolo SSL), o usando cualquier otro tipo de comunicación electrónica, en el proceso de configuración.
Una vez ha sido instalada la aplicación, el usuario puede iniciarla y acceder a un menú en el que hay varias opciones. Entre ellas están las siguientes: (1) configuración, (2)
HOJA DE REEMPLAZO (Regla 26) compra, (3) venta, (4) verificación de transacciones. Inicialmente, sólo la opción de configuración está habilitada. En la figura 4 se puede ver como la aplicación permite configurar el terminal bien en modo COMPRA o bien en modo VENTA. Una vez el terminal ha sido configurado, las opciones de COMPRA (2) o VENTA (3), y la opción de verificación de transacciones (4) se habilitarán, y el terminal quedará listo para realizar transacciones.
Para iniciar una transacción de compra, el usuario deberá iniciar la aplicación y seleccionar la opción de COMPRA (2) en el menú. Según se ve en la fig. 5, al acceder a la opción de compra, la aplicación muestra 3 campos vacíos en los que el usuario debe introducir la cantidad a pagar, el número de identificación personal y el número de teléfono móvil del vendedor. La aplicación interrogará entonces al usuario sobre la necesidad de utilización de referencia de compra (RC) en la transacción. Si la respuesta es afirmativa, aparecerá un cuarto campo vacío, donde el usuario introducirá dicha referencia de compra (RC), asignada por el vendedor. Tras la conexión, el terminal enviará al servidor el número de teléfono correspondiente al comprador, recuperado de la memoria del terminal. El servidor de transacciones generará y enviará entonces al terminal una clave de encriptación de sesión, encriptada a su vez mediante la clave de encriptación fija correspondiente al comprador, determinada mediante el número de teléfono previamente enviado, si éste existe en la base de datos. En otro caso, la transacción sería finalizada, enviándose un mensaje al usuario mediante la conexión todavía abierta. Dicha clave será recibida y desencriptada por la aplicación usando la clave de encriptación fija, almacenada en la memoria del terminal, obteniéndose pues la clave de sesión, que será conocida por ambos, terminal y servidor. Una vez introducidos, los datos correspondientes a la transacción, junto con la clave de acceso (CA) y el número del propio teléfono móvil, recuperados de la memoria del terminal, son encriptados por la aplicación con esa clave de sesión, y enviados mediante GPRS, UMTS u otro protocolo celular de transmisión de datos, al servidor de transacciones, a través de Internet. En la figura 5 se puede ver cómo el servidor recibe dichos datos encriptados, así como, en su caso, las cabeceras HTTP de identificación de la tarjeta SIM. Una vez recibidos los datos, el servidor de transacciones accede a la base de datos asociada, donde realiza la búsqueda del registro identificado por la cabecera HTTP correspondiente, o por el número del teléfono móvil propio del usuario, en su caso, que se enviaría sin encriptar. Si no existiera dicho registro, la transacción se dará por finalizada, enviándose un mensaje al usuario en este
HOJA DE REEMPLAZO (Regla 26) 0115
sentido, usando la conexión todavía abierta. Si el registro existe, la información recibida es desencriptada usando dicha clave de encriptación de sesión, y se comparará el número de identificación personal enviado con el existente en la base de datos. Si no coinciden, la transacción se dará por finalizada, enviándose asimismo un mensaje de aviso al usuario mediante la conexión establecida. Si coinciden, se compararán el número de teléfono móvil y la clave de acceso (CA) enviados con los existentes en la base de datos. Si alguna comparación es fallida, la transacción finaliza, enviándose el mensaje de aviso correspondiente al usuario. Si todos los datos coinciden, la transacción será considerada correcta. En este caso se procederá a realizar una transferencia de fondos entre la cuenta asociada al usuario referido en el registro identificado y la cuenta perteneciente al usuario referido mediante el número de teléfono móvil del vendedor, introducido previamente por el comprador y enviado por el terminal móvil, y correspondiente a la compra referenciada en el campo opcional de referencia de compra (RC) que fue enviada previamente desde el terminal, o cuantificada por el campo de cantidad de la transacción, enviado asimismo desde el terminal. Una vez realizada la transferencia, la transacción se dará por finalizada, y un mensaje de confirmación será enviado al usuario, utilizando la misma conexión, todavía abierta, y encriptado usando la clave de sesión. En este mensaje se mostrarán los datos más relevantes de la transacción. El servidor de transacciones guardará un histórico de todas las transacciones realizadas por el sistema, ya sean correctas o erróneas. El protocolo SSL podría ser utilizado en este caso de manera equivalente.
En la fig. 6 se muestra el proceso seguido en una transacción de venta. En este caso, el vendedor debe iniciar la aplicación y seleccionar en el menú la opción de VENTA (3). Al hacer esto, obtiene una pantalla con cuatro campos, relativos a la cantidad de la transacción, la referencia de venta (RV), el número de teléfono móvil del comprador y el número de identificación personal de éste. Los dos primeros deben ser rellenados por el vendedor, aunque el campo de referencia de venta (RV) es opcional. Una vez introducidos dichos datos, el vendedor pide al comprador que introduzca su número de teléfono móvil y su número de identificación personal, lo que concluirá la introducción de datos. La aplicación finalmente recuperará el número propio del teléfono móvil del vendedor y la clave de acceso (CA), de la memoria del terminal. La aplicación conecta entonces con el servidor de transacciones mediante una conexión GPRS, UMTS u otro protocolo de transmisión de datos y envía el
HOJA DE REEMPLAZO (Regla 26) número de teléfono correspondiente al vendedor. Entonces el servidor de transacciones envía una clave de encriptación de sesión, encriptada a su vez con la clave de encriptación fija correspondiente al vendedor, si éste existiera en la base de datos. La aplicación recibe y desencripta la clave de sesión mediante la clave de encriptación fija, almacenada en la memoria del terminal, clave de sesión que será conocida por tanto por el terminal y por el servidor. Entonces encripta los anteriores datos de la transacción utilizando dicha clave de sesión y los envía al servidor. Todos los datos son encriptados, excepto el número de teléfono móvil del vendedor, en su caso, que se envía sin encriptar. El servidor de transacciones recibe pues ciertos datos del vendedor y del comprador encriptados, el número del teléfono del vendedor, así como las cabeceras HTTP de identificación de la tarjeta SIM. Al igual que en la transacción de compra, el servidor de transacciones desencripta la información mediante la clave de sesión y comprueba si tanto el registro referenciado por la cabecera HTTP correspondiente (o por el número propio del teléfono móvil del vendedor, en su caso), como el registro del comprador, referenciado por su número de teléfono, existen. Si alguno de esos registros es inexistente, la transacción finaliza, enviándose un mensaje de error al terminal del vendedor, mediante la conexión todavía abierta. Si el número de identificación personal del comprador así desencriptado no coincide con el NIP que está asociado al registro de comprador mediante el número de teléfono móvil recibido en la conexión, la transacción finaliza, y un mensaje de error es enviado al terminal del vendedor. Si ambos NBP coinciden, se leerá (en su caso) el número del teléfono móvil del vendedor asociado a la cabecera HTTP de identificación y la clave de acceso (CA). Si dichos datos coinciden con los recientemente desencriptados, pertenecientes al vendedor, la transacción se considera correcta y se realiza la transferencia de fondos entre la cuenta del comprador, referenciada por su número de teléfono móvil, y la cuenta del vendedor, referenciada por la cabecera HTTP correspondiente (o por su número de teléfono móvil). El servidor de transacciones guarda un histórico de todas las transacciones realizadas, ya sean válidas o erróneas, incluyendo la referencia de venta (RV), adjuntada si ésta ha sido introducida por el vendedor en el terminal. Un mensaje de confirmación será enviado al terminal del vendedor, utilizando la conexión todavía abierta, siendo encriptado previamente mediante la clave de sesión. Si el comprador quiere saber el resultado de la transacción, deberá usar la opción (4) de su menú de transacciones. Una vez iniciada la aplicación, debe introducir su número de identificación personal (NIP) y hacer la petición al servidor de transacciones. La aplicación enviará .el número propio del teléfono
HOJA DE REEMPLAZO (Regla 26) móvil del comprador. El servidor de transacciones recibirá la cabecera HTTP de identificación de tarjeta SIM, o en su caso, el número de teléfono móvil del comprador, leerá el registro asociado al usuario en la base de datos, generará y enviará al terminal la clave de encriptación de sesión, encriptada dicha clave con la clave de encriptación fija asociada al comprador, y enviará el mensaje de confirmación encriptado con dicha clave de sesión. El servidor encriptará y enviará también el NIP correspondiente al usuario. La aplicación desencriptará la clave de sesión con la clave de encriptación fija, almacenada en la memoria del terminal, obteniendo la clave de sesión, desenciptará el mensaje de confirmación utilizando dicha clave de sesión, desencriptará asimismo el NIP enviado, lo comparará con el NIP introducido y si ambos coinciden, mostrará el mensaje de confirmación en la pantalla del terminal. En este caso la opción de usar el protocolo seguro SSL podría utilizarse de manera equivalente.
Si se desea dotar al sistema de mayor seguridad, al producirse tres conexiones erróneas conteniendo una misma cabecera HTTP de identificación (o un mismo número de teléfono móvil, en su caso), el registro de usuario asociado a dicha cabecera HTTP podría ser bloqueado.
Naturalmente, la invención no se limita a las realizaciones antes descritas y mostradas en las figuras, sino que se puede modificar dentro del alcance de las reivindicaciones anexas.
HOJA DE REEMPLAZO (Regla 26)

Claims

Reivindicaciones
1. Método para realizar transacciones de compra/venta utilizando teléfonos móviles programables (p. ej. con tecnología Java), que convierte un teléfono móvil programable (p. ej. con tecnología Java) en un terminal de compra/venta, y que comprende los pasos de: a) Dar de alta al usuario, almacenando hasta 5 elementos significativos (ES), en la base de datos del servidor de transacciones, que conforman la información principal del usuario. En este proceso de alta, se generará también mía clave de encriptación, diferente para cada usuario. Este paso se realiza una única vez por cada usuario y puede realizarse de forma presencial o no presencial, a través de Internet. Los datos quedan almacenados en la base de datos del servidor de transacciones. b) Descargar la aplicación específica (p. ej. escrita en Java) para convertir el teléfono móvil del usuario en un terminal de compra/venta, mediante un servidor WEB alojado o conectado con el servidor de transacciones, aplicándose una vez para cada usuario. c) Encriptar y descargar en el terminal móvil el número propio del teléfono móvil del usuario y la clave de acceso (CA) única para cada usuario, generada por el servidor de transacciones, para que puedan ser utilizados por la aplicación en cada transacción realizada. Este paso es realizado una única vez por el servidor de transacciones. d) Introducir en el terminal la clave de encriptación fija, única para cada usuario. Este paso será realizado por el usuario del sistema, utilizando los medios suministrados por el mencionado teléfono móvil programable, controlados por la aplicación (escrita en Java, por ejemplo) residente en éste, siendo dicho paso realizado sólo una vez. e) Desencriptar y almacenar en la memoria del teléfono móvil, el número propio del teléfono móvil y la clave de acceso (CA) previamente descargadas. Este paso será realizado automáticamente por la aplicación cargada en el teléfono móvil, y será realizado sólo una vez. f) Iniciar la aplicación en el teléfono móvil. Este paso será realizado por el usuario, utilizando los medios suministrados por el teléfono móvil programable, controlados por la aplicación residente en éste, cada vez que dicho usuario quiera efectuar una transacción. g) En el caso de que el terminal, controlado por la aplicación, opere en modo de compra, introducir el número de teléfono del vendedor, el número personal de identificación (NIP),
HOJA DE REEMPLAZO (Regla 26) la cantidad a pagar, y la referencia de compra (RC), si existe, en los campos correspondientes generados por dicha aplicación. Este paso será realizado por el usuario, utilizando los medios suministrados por el teléfono móvil programable, controlados por la aplicación residente en éste, cada vez que dicho usuario quiera efectuar una transacción de compra. h) En el caso de que el terminal, controlado por la aplicación, opere en modo de venta, introducir la cantidad a cobrar, en su caso la referencia de venta (RV), el número de teléfono móvil del comprador y el número de identificación personal (NIP) de éste, en los correspondientes campos. Este paso será realizado por los usuarios -comprador y vendedor-, utilizando los medios suministrados por el teléfono móvil programable, controlados por la aplicación residente en éste, cada vez que dichos usuarios quieran efectuar una transacción. i) Recuperar el número de teléfono móvil y la clave de acceso (CA) de la memoria del teléfono móvil que inicia la operación de compra o venta. Este paso será realizado automáticamente por la aplicación (escrita en Java, por ejemplo) sobre el teléfono móvil, j) Encriptar dichos datos, salvo los necesarios para la identificación de los usuarios implicados en la transacción, por parte del servidor de transacciones. Este paso será realizado automáticamente por la mencionada aplicación (escrita en Java, por ejemplo) sobre el teléfono móvil. k) Conectar con el servidor de transacciones. Este paso será realizado automáticamente por la mencionada aplicación (escrita en Java, por ejemplo) entre el teléfono móvil y el servidor de transacciones.
1) Enviar los datos recolectados al servidor de transacciones. Este paso será realizado automáticamente por la aplicación (escrita en Java, por ejemplo) entre el teléfono móvil y el servidor de transacciones, mediante una conexión GPRS, UMTS, u otro protocolo de conexión a Internet. m) Recibir los datos recolectados, más la cabecera de identificación de la tarjeta SIM del terminal del usuario conectado, en su caso, en el servidor de transacciones. Este paso será realizado automáticamente por el servidor de transacciones. n) Utilizar la cabecera de identificación de SIM, o el número del teléfono móvil de el/los usuarios, para localizar los registros correspondientes a los usuarios implicados en la transacción. Este paso será realizado automáticamente por el servidor de transacciones.
HOJA DE REEMPLAZO (Regla 26) o) Desencriptar y procesar el resto de los datos para comprobar la correcta identidad de los usuarios, contra los datos almacenados en la base de datos. Este paso será realizado automáticamente por el servidor de transacciones. p) Validar y realizar, en su caso, la transacción entre comprador y vendedor. Este paso será realizado automáticamente por el servidor de transacciones. q) Encriptar y enviar un mensaje de confirmación al terminal móvil del usuario que está conectado. Este paso será realizado automáticamente por el servidor de transacciones entre dicho servidor de transacciones y el terminal móvil del usuario conectado a aquél, mediante una conexión GPRS, UMTS, u otro protocolo de conexión a Internet. r) Almacenar la transacción en un histórico. Este paso será realizado automáticamente por el servidor de transacciones. s) Encriptar y enviar al terminal del usuario que no ha iniciado la transacción, y a petición de éste, un informe de la última transacción efectuada. Este paso será realizado automáticamente por el servidor de transacciones entre dicho servidor de transacciones y el terminal de usuario conectado a aquél, mediante una conexión GPRS, UMTS, u otro protocolo de conexión a Internet.
2. Método de acuerdo con la reivindicación 2, caracterizado porque el paso b) también puede realizarse mediante la descarga de la aplicación desde cualquier dispositivo de almacenamiento de datos, una vez el usuario se ha dado de alta, o ser realizado por el propio fabricante del teléfono móvil.
3. Método de acuerdo con la reivindicación 2, caracterizado porque el paso d) también puede realizarse de manera automática, mediante la comunicación segura de la clave de encriptación fija al teléfono móvil, por el servidor de transacciones, en el proceso de configuración.
HOJA DE REEMPLAZO (Regla 26)
PCT/ES2005/070115 2004-07-30 2005-07-29 Metodo para realizar transacciones de pago o cobro seguras, utilizando telefonos moviles programables WO2006016000A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP05782628A EP1772832A1 (en) 2004-07-30 2005-07-29 Method of making secure payment or collection transactions using programmable mobile telephones
US11/658,950 US20080091614A1 (en) 2004-07-30 2005-07-29 Method To Make Payment Or Charge Safe Transactions Using Programmable Mobile Telephones
US13/069,759 US9342664B2 (en) 2004-07-30 2011-03-23 Method to make payment or charge safe transactions using programmable mobile telephones

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ES200401988A ES2263344B1 (es) 2004-07-30 2004-07-30 Metodo para realizar transacciones de pago o cobro seguras, utilizando telefonos moviles programables.
ESP200401988 2004-07-30

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US11/658,950 A-371-Of-International US20080091614A1 (en) 2004-07-30 2005-07-29 Method To Make Payment Or Charge Safe Transactions Using Programmable Mobile Telephones
US65895007A A-371-Of-International 2004-07-30 2007-01-29
US13/069,759 Continuation US9342664B2 (en) 2004-07-30 2011-03-23 Method to make payment or charge safe transactions using programmable mobile telephones

Publications (1)

Publication Number Publication Date
WO2006016000A1 true WO2006016000A1 (es) 2006-02-16

Family

ID=35839159

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2005/070115 WO2006016000A1 (es) 2004-07-30 2005-07-29 Metodo para realizar transacciones de pago o cobro seguras, utilizando telefonos moviles programables

Country Status (4)

Country Link
US (1) US20080091614A1 (es)
EP (1) EP1772832A1 (es)
ES (1) ES2263344B1 (es)
WO (1) WO2006016000A1 (es)

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9342664B2 (en) * 2004-07-30 2016-05-17 Etrans L.C. Method to make payment or charge safe transactions using programmable mobile telephones
US7962896B2 (en) * 2005-10-31 2011-06-14 Eazypaper Inc. Method and system for automatically configuring software
KR100822802B1 (ko) * 2006-09-21 2008-04-18 삼성전자주식회사 안테나를 내장한 심카드 및 그것을 포함하는 시스템
JP4274242B2 (ja) * 2006-12-28 2009-06-03 ブラザー工業株式会社 処理実行装置及び電話番号登録装置
US8768778B2 (en) * 2007-06-29 2014-07-01 Boku, Inc. Effecting an electronic payment
BRPI0703112A2 (pt) * 2007-07-19 2009-07-21 Itautec Sa Grupo Itautec sistema e método para transferência de créditos com uso de dispositivo móvel
US8306880B1 (en) * 2007-08-03 2012-11-06 Intuit Inc. System and method for determining foreign paid taxes
SE532268C2 (sv) 2007-12-04 2009-11-24 Accumulate Ab Förfarande för säkra transaktioner
CA2632793A1 (en) * 2008-04-01 2009-10-01 Allone Health Group, Inc. Information server and mobile delivery system and method
GB0809381D0 (en) * 2008-05-23 2008-07-02 Vidicom Ltd Funds transfer electronically
GB0809383D0 (en) 2008-05-23 2008-07-02 Vidicom Ltd Customer to supplier funds transfer
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8977567B2 (en) 2008-09-22 2015-03-10 Visa International Service Association Recordation of electronic payment transaction information
US9824355B2 (en) 2008-09-22 2017-11-21 Visa International Service Association Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US10706402B2 (en) 2008-09-22 2020-07-07 Visa International Service Association Over the air update of payment transaction data stored in secure memory
US9652761B2 (en) * 2009-01-23 2017-05-16 Boku, Inc. Systems and methods to facilitate electronic payments
US8548426B2 (en) * 2009-02-20 2013-10-01 Boku, Inc. Systems and methods to approve electronic payments
US9990623B2 (en) 2009-03-02 2018-06-05 Boku, Inc. Systems and methods to provide information
US8700530B2 (en) * 2009-03-10 2014-04-15 Boku, Inc. Systems and methods to process user initiated transactions
US8224727B2 (en) 2009-05-27 2012-07-17 Boku, Inc. Systems and methods to process transactions based on social networking
US8160943B2 (en) * 2009-03-27 2012-04-17 Boku, Inc. Systems and methods to process transactions based on social networking
TWI385998B (zh) * 2009-04-17 2013-02-11 Chunghwa Telecom Co Ltd Real - time streaming service system and method with authorized function
US8131258B2 (en) * 2009-04-20 2012-03-06 Boku, Inc. Systems and methods to process transaction requests
US20100299220A1 (en) * 2009-05-19 2010-11-25 Boku, Inc. Systems and Methods to Confirm Transactions via Mobile Devices
US20100306015A1 (en) * 2009-05-29 2010-12-02 Boku, Inc. Systems and Methods to Schedule Transactions
SE0950411A1 (sv) * 2009-06-04 2010-09-21 Accumulate Ab Metod för säkra transaktioner
SE533421C2 (sv) * 2009-06-04 2010-09-21 Accumulate Ab Metod för säkra transaktioner
US9595028B2 (en) 2009-06-08 2017-03-14 Boku, Inc. Systems and methods to add funds to an account via a mobile communication device
US20100312645A1 (en) * 2009-06-09 2010-12-09 Boku, Inc. Systems and Methods to Facilitate Purchases on Mobile Devices
US9697510B2 (en) 2009-07-23 2017-07-04 Boku, Inc. Systems and methods to facilitate retail transactions
US9519892B2 (en) * 2009-08-04 2016-12-13 Boku, Inc. Systems and methods to accelerate transactions
US8660911B2 (en) 2009-09-23 2014-02-25 Boku, Inc. Systems and methods to facilitate online transactions
US20110078077A1 (en) * 2009-09-29 2011-03-31 Boku, Inc. Systems and Methods to Facilitate Online Transactions
US8224709B2 (en) * 2009-10-01 2012-07-17 Boku, Inc. Systems and methods for pre-defined purchases on a mobile communication device
US9516017B2 (en) 2009-10-23 2016-12-06 Apriva, Llc System and device for consolidating SIM, personal token, and associated applications for electronic wallet transactions
EP2491524A4 (en) * 2009-10-23 2014-10-01 Apriva Llc SYSTEM AND DEVICE FOR CONSOLIDATING SIM, PERSONAL TOKEN AND ASSOCIATED APPLICATIONS
US20110238580A1 (en) * 2009-10-23 2011-09-29 Apriva, Llc System and device for consolidating sim, personal token, and associated applications for secure transmission of sensitive data
US9112857B2 (en) * 2009-10-23 2015-08-18 Apriva, Llc System and device for facilitating a wireless transaction by consolidating SIM, personal token, and associated applications
US9544303B2 (en) * 2009-10-23 2017-01-10 Apriva, Llc System and device for consolidating SIM, personal token, and associated applications for selecting a transaction settlement entity
US20110238579A1 (en) * 2009-10-23 2011-09-29 Apriva, Llc System and device for facilitating a secure transaction with a validated token
US20110237224A1 (en) * 2009-10-23 2011-09-29 Apriva, Llc System and device for facilitating remote invocation of personal token capabilities
US8412626B2 (en) 2009-12-10 2013-04-02 Boku, Inc. Systems and methods to secure transactions via mobile devices
US20110143710A1 (en) * 2009-12-16 2011-06-16 Boku, Inc. Systems and methods to facilitate electronic payments
US8566188B2 (en) * 2010-01-13 2013-10-22 Boku, Inc. Systems and methods to route messages to facilitate online transactions
US20110213671A1 (en) * 2010-02-26 2011-09-01 Boku, Inc. Systems and Methods to Process Payments
US8219542B2 (en) 2010-03-25 2012-07-10 Boku, Inc. Systems and methods to provide access control via mobile phones
US20110238483A1 (en) * 2010-03-29 2011-09-29 Boku, Inc. Systems and Methods to Distribute and Redeem Offers
US8583504B2 (en) * 2010-03-29 2013-11-12 Boku, Inc. Systems and methods to provide offers on mobile devices
CA2808093A1 (en) 2010-08-11 2012-02-16 Boku, Inc. Systems and methods to identify carrier information for transmission of premium messages
WO2012064280A1 (en) * 2010-11-10 2012-05-18 Smart Hub Pte. Ltd. Method of performing a financial transaction via unsecured public telecommunication infrastructure and an apparatus for same
US8699994B2 (en) 2010-12-16 2014-04-15 Boku, Inc. Systems and methods to selectively authenticate via mobile communications
US8412155B2 (en) 2010-12-20 2013-04-02 Boku, Inc. Systems and methods to accelerate transactions based on predictions
US8583496B2 (en) 2010-12-29 2013-11-12 Boku, Inc. Systems and methods to process payments via account identifiers and phone numbers
US8700524B2 (en) 2011-01-04 2014-04-15 Boku, Inc. Systems and methods to restrict payment transactions
US9495701B2 (en) * 2011-04-05 2016-11-15 Airservice Digital Pty Ltd Retail venue ordering system and method
US8543087B2 (en) 2011-04-26 2013-09-24 Boku, Inc. Systems and methods to facilitate repeated purchases
US9191217B2 (en) 2011-04-28 2015-11-17 Boku, Inc. Systems and methods to process donations
US9830622B1 (en) 2011-04-28 2017-11-28 Boku, Inc. Systems and methods to process donations
US8862767B2 (en) 2011-09-02 2014-10-14 Ebay Inc. Secure elements broker (SEB) for application communication channel selector optimization
US9846863B2 (en) * 2011-11-18 2017-12-19 Ncr Corporation Techniques for automating a retail transaction
US8924711B2 (en) 2012-04-04 2014-12-30 Zooz Mobile Ltd. Hack-deterring system for storing sensitive data records
US20150302506A1 (en) * 2012-08-01 2015-10-22 Postecom S.P.A. Method for Securing an Order or Purchase Operation Means of a Client Device
BE1023561B1 (nl) * 2013-07-24 2017-05-04 Midw3 Bvba Werkwijze en systeem voor beveiligde electronische transakties
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US10769625B2 (en) * 2013-12-20 2020-09-08 Cellco Partnership Dynamic generation of quick response (QR) codes for secure communication from/to a mobile device
WO2017074281A1 (en) * 2015-10-27 2017-05-04 DOGAN, Mustafa Cemal Multi-dimensional authentication system and method for cardless banking transactions and other transactions involving high-level security
CN109982451A (zh) * 2019-03-29 2019-07-05 深圳市艾尚美科技有限公司 远程语音播报收款方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000031699A1 (en) * 1998-11-22 2000-06-02 Easy Charge Cellular (Pty) Limited Method of, and apparatus for, conducting electronic transactions
WO2002041271A1 (en) * 2000-11-15 2002-05-23 Mahmoud Nabih Youssef Haidar Electronic payment and associated systems

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590038A (en) * 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
US6999936B2 (en) * 1997-05-06 2006-02-14 Sehr Richard P Electronic ticketing system and methods utilizing multi-service visitor cards
US20020138390A1 (en) * 1997-10-14 2002-09-26 R. Raymond May Systems, methods and computer program products for subject-based addressing in an electronic trading system
US7720742B1 (en) * 1999-03-01 2010-05-18 Ubs Ag Computer trading system method and interface
US6705520B1 (en) * 1999-11-15 2004-03-16 Satyan G. Pitroda Point of sale adapter for electronic transaction device
US7349871B2 (en) * 2002-08-08 2008-03-25 Fujitsu Limited Methods for purchasing of goods and services

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000031699A1 (en) * 1998-11-22 2000-06-02 Easy Charge Cellular (Pty) Limited Method of, and apparatus for, conducting electronic transactions
WO2002041271A1 (en) * 2000-11-15 2002-05-23 Mahmoud Nabih Youssef Haidar Electronic payment and associated systems

Also Published As

Publication number Publication date
ES2263344B1 (es) 2007-11-16
EP1772832A1 (en) 2007-04-11
US20080091614A1 (en) 2008-04-17
ES2263344A1 (es) 2006-12-01

Similar Documents

Publication Publication Date Title
ES2263344B1 (es) Metodo para realizar transacciones de pago o cobro seguras, utilizando telefonos moviles programables.
RU2679343C1 (ru) Верификация бесконтактной платежной карты для выдачи платежного удостоверения мобильному устройству
US9240009B2 (en) Mobile devices for commerce over unsecured networks
US6847816B1 (en) Method for making a payment secure
US7275685B2 (en) Method for electronic payment
US10270587B1 (en) Methods and systems for electronic transactions using multifactor authentication
US20120130838A1 (en) Method and apparatus for personalizing secure elements in mobile devices
US20120129452A1 (en) Method and apparatus for provisioning applications in mobile devices
TWI517644B (zh) 經由未受保全公共電信基礎設施執行金融交易之方法及其裝置
US9342664B2 (en) Method to make payment or charge safe transactions using programmable mobile telephones
US20190172062A1 (en) Method and apparatus for personalizing secure elements in mobile devices
US20030154376A1 (en) Optical storage medium for storing, a public key infrastructure (pki)-based private key and certificate, a method and system for issuing the same and a method for using
US20080249938A1 (en) System and method for merchant discovery and transfer of payment data
ES2823592T3 (es) Sistema de pago seguro
US9836735B2 (en) Method for initiating and performing a CNP business transaction, software for the same and a communication device comprising such software
CN1726686B (zh) 为交易提供便利和认证
EP1724720B1 (fr) Procédé de paiement de service d'affranchissement dans une machine de traitement de courrier en libre accès
US20170154329A1 (en) Secure transaction system and virtual wallet
JP2003504759A (ja) トランザクションを実行するためのシステム
WO2008154872A1 (fr) Terminal mobile, procédé et système pour télécharger des informations de carte de banque ou des informations d'application de paiement
US20170323302A1 (en) Security systems and methods
KR100822957B1 (ko) 금융거래 처리용 프로그램을 기록한 것을 특징으로 하는기록매체와, 이를 이용한 금융거래 처리방법 및 시스템
ES2971660T3 (es) Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente
KR100928412B1 (ko) 가상 가맹점 망을 이용한 결제처리 시스템
KR20150144362A (ko) 종단 간 매체 소유 인증과 일회용 인증코드 인증을 이용한 가맹점 결제 처리 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 11658950

Country of ref document: US

Ref document number: 2005782628

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005782628

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11658950

Country of ref document: US