WO2010000884A1 - Method for making secure payment and collection transactions by means of terminals with a data connection - Google Patents

Method for making secure payment and collection transactions by means of terminals with a data connection Download PDF

Info

Publication number
WO2010000884A1
WO2010000884A1 PCT/ES2008/070129 ES2008070129W WO2010000884A1 WO 2010000884 A1 WO2010000884 A1 WO 2010000884A1 ES 2008070129 W ES2008070129 W ES 2008070129W WO 2010000884 A1 WO2010000884 A1 WO 2010000884A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
payment
user
collector
server
Prior art date
Application number
PCT/ES2008/070129
Other languages
Spanish (es)
French (fr)
Inventor
José Pelayo DEL RIEGO PALACIOS
Original Assignee
Visiers Sanz, Irache
MURUAIS MOSQUERA, Andrés
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 Visiers Sanz, Irache, MURUAIS MOSQUERA, Andrés filed Critical Visiers Sanz, Irache
Priority to PCT/ES2008/070129 priority Critical patent/WO2010000884A1/en
Publication of WO2010000884A1 publication Critical patent/WO2010000884A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • 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/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention falls within the technical sector of information and communication technologies (ICT) and specifically refers to a method for making secure payment and collection transactions using documents based on visual codes and using telephone-based terminals mobiles, computers or other terminals with data connection, preferably through the Internet.
  • ICT information and communication technologies
  • Document KR20040082790 describes an apparatus for making a payment using a bar code model, and a method for facilitating payment by downloading that code to a mobile terminal.
  • a user terminal transmits a request message to a provider server to issue a barcode, to receive a barcode with information related to the amount to be paid.
  • the provider's server generates the barcode corresponding to the request message and issues the barcode and transmits it to the user terminal.
  • the device that processes the payment reads the barcode shown on the screen of the user terminal to make the payment.
  • the method of the invention provides for the use of a "virtual ticket" in the form of a barcode, but in this case the barcode is associated with a URL of very difficult repetition or localization by computer means, since it contains a pseudorandom code which hinders its location. Through this URL the entity is contrasted issuer of said ticket, its existence, amount, user acquiring it and another series of data that make this process a procedure to make secure payment and collection transactions.
  • the function of the barcode is not to carry the information for the execution of a predefined transaction, but rather to carry a value on which a user can initiate a payment request, of any value less than maximum associated with the barcode and that will be read by any user (not restricted) who wishes to make a payment;
  • the transaction (which is not closed and has no defined amount and recipient until the final stage of the process) must be initiated by another user through a terminal in whose browser the address contained within the barcode is acquired.
  • the method proposed here includes the following stages: a) The initial stage we will call "balance recharge” is the acquisition by the user of this means of payment of tickets or unit payment methods, which is carried out on a server issuing tickets that are accessed through a web page, either through the mobile phone or a computer, in which the paying user purchases tickets with indeterminate amounts chosen by him. Each user who signs up for this service must provide, in addition to certain personal data to communicate with him such as his email and mobile phone number. He User recharges the balance using the usual means of electronic commerce, such as bank transfer, account charge or credit card. The user account maintains a "balance" data that will represent the amount of the "balance top-ups", plus payments received from other users through this service, less payments issued.
  • the balance (optionally, the "maximum allowable balance” configurable by the user for your account) must be equal to the amount represented by the "barcodes"("virtualtickets") in force in the system.
  • This "maximum allowable balance” is a limiting amount that serves as a security safeguard.
  • the user's balance is € IOOO, if the maximum issued balance is € 200, only € 200 will be in circulation for this user. After acquiring a ticket, the server proceeds to issue it.
  • the issuing server associates with each ticket a URL that contains a specific "random pseudo identification string" data, which is encoded in a barcode or visual code that it sends to the terminal or mobile phone of the user who has acquired the ticket using the medium preferred by the user (email, MMS, etc.).
  • This URL is generated pseudorandomly and has a length that makes its determination impossible even by computer means, to ensure that Only that barcode corresponds to that URL and therefore with a certain ticket, issued with a specific amount and belonging to a specific acquirer.
  • the issuer optionally establishes, since the user can disable this mechanism completely or partially, a safeguard key, associated with each ticket or each user buying tickets.
  • This safeguard key can be chosen by the user who acquires the ticket itself, or generated at random by the ticket issuing server, and can be sent by it to the user acquiring the ticket through SMS, email, printed on the ticket itself or , simply, it is not sent and must be remembered by the user who owns the ticket (in case of a fixed code).
  • the payer shows the seller or collector of the operation the visual code of his payment ticket by any means, either on the screen of the mobile phone, of a computer, on a printed paper or directly As a graphic data file, it is preferred to display it on the screen of your mobile phone.
  • the collector through his mobile or a computer provided or associated with a camera or graphic file interpretation software, acquires and reads said code and, through a program that transforms this code into the specific URL assigned to it, connects with said URL and validates said ticket, verifying that it is valid, has been issued for the amount and, optionally, the specific user.
  • the transaction validation stage is carried out when the seller transfers the ticket protection key to the issuing server (except if the mechanism has been disabled at the will of the ticket holder), until then held by the buyer, the amount to be collected from it and your payment destination user data. If all these data coincide with what is stored on the server, the latter transfers a balance to the user account of the collector for the amount of the transaction.
  • the ticket issuing server sends you an encrypted key, previously agreed upon and known only to the collector and the payment system ("shared secret"). This key validates that the collector has connected to the legitimate payment system, avoiding the falsification of any of these elements.
  • the server cancels the previously issued ticket for it and increases the balance in the biller's user account to the same extent that the balance in the payer's account decreases; immediately upon cancellation of the ticket, new tickets are issued to honor the new balances of both the payer and the collector. For example, if in the phase prior there is O € in the balance of the collector and there is € OO in the balance of the payer, whether there is a € billete bill held by the payer; If the transaction is € 30, € O € is not deducted from the payer, but only € 30 is passed to the collector. The accounts remain: € 70 in the payer and € 30 in the balance of the collector. The € O € ticket is canceled and issued: one of € 50 and one of € 20 for the payer and one of € 30 for the collector; the return, therefore, is made in the form of tickets, but there is no such concept of return associated with transfers or balance transfers.
  • the maintenance of the payment system recommended here is first paid for by the advertising incorporated in each ticket issued by the issuing server.
  • the tickets purchased by the users, while not being used in any transaction are money in deposit in the account of the issuing entity, which can generate a financial return.
  • Figure 1 shows a schematic view of the process of acquisition and issuance of documents or means of payment.
  • Figure 2 shows a schematic view of the payment and collection process of a secure transaction.
  • Figure 3 represents a type ticket issued for the payment of transactions according to the method of the invention.
  • At least one server (Serv ⁇ ) and a series of mobile phones, personal computers or any other type of mobile terminal with Internet connection capability are necessary.
  • the server incorporates a specific information management software and database manager, in which the following data is processed: a) User data, which includes personal data, username, user code and password of user access. b) Accounting data, in which the refills requested by the user are stored in the store / web portal; the charges and payments that users make. c) Data of the assets issued, which store the tickets, their validity, value, identifier, user, etc. d) Finally, the data of the advertising campaigns associated with the images that are added to the tickets.
  • the mobile phone of the paying user (Pl) and the transaction collector (Cl) must be a GPRSE mobile phone, programmable. Specifically, the collector's telephone (Cl) must also implement a visual code reader software, such as: i-nigma, KAYWA Reader, UpCode, etc.
  • phase 1 the paying user, through his mobile phone or from a computer (Pl) with an Internet connection, requests on one web page implemented on the issuing server (Served) the issuance of one or more bills, for the amounts chosen by him, after registering as such a user, a process in which he has already provided the server with his personal data, username, user code, access code and shared secret.
  • the user In order to request the issuance of tickets, the user must have made a "balance recharge"
  • the server issues the ticket or payment method, keeping the validity, value, identifier, user in an internal database.
  • Each ticket is associated with a URL that has been generated in a pseudo random way and with a length long enough to be very difficult to locate.
  • it incorporates an advertising message chosen among the advertising campaigns proposed at that moment.
  • the server sends the paying user (Pl), through an SMS, an email, or printed on the body of the ticket a safeguard key, or the key is already known by the user and its sending is not necessary.
  • This key can be specific to each ticket or each user and may be generated randomly by the server or provided by the user during the registration process in the system.
  • the paying user shows the billing user (Cl) the ticket, for example, on the screen of his mobile phone.
  • the collector purchases the same through a software for reading visual codes and interprets the URL associated with that code.
  • the charging user (Cl), in phase 5, connects its terminal via the Internet with the URL hidden in the visual code of the ticket, with the server (Serv ⁇ ) which receives a series of validation data, such as the validity status and the value of the ticket.
  • the charging user responds through the same screen with: the amount to collect from that ticket, the recipient of the payment
  • the server transfers the balance to your user account for the amount of the transaction and communicates this eventuality to the collector (Cl), as staged in the phase

Landscapes

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

Abstract

Method for making secure payment and collection transactions by means of terminals with a data connection and the use of documents based on sponsored visual codes, which method comprises an initial stage in which the user obtains unitary payment notes or means; a note-issuing stage in which the issuing server transforms each note into a specific pseudo-random URL coded in a visual barcode; a payment stage in which the payer shows the seller or collector of the operation the visual code from his payment note, the validity of which is checked by the collector when transferring, to the note-issuing server, a number of data items via his terminal and/or the specific URL of each note.

Description

DESCRIPCIÓN DESCRIPTION
Método para efectuar transacciones seguras de pago y cobro, por medio de terminales con una conexión de datos .Method to carry out secure payment and collection transactions, through terminals with a data connection.
Objeto de la invenciónObject of the invention
La presente invención se encuadra en el sector técnico de las tecnologías de la información y la comunicación (TIC) y en concreto se refiere a un método para efectuar transacciones seguras de pago y cobro mediante documentos basados en códigos visuales y que emplea terminales basados en teléfonos móviles, ordenadores u otros terminales con conexión de datos, preferentemente a través de Internet.The present invention falls within the technical sector of information and communication technologies (ICT) and specifically refers to a method for making secure payment and collection transactions using documents based on visual codes and using telephone-based terminals mobiles, computers or other terminals with data connection, preferably through the Internet.
Antecedentes de la invenciónBackground of the invention
Hasta la fecha se han desarrollado numerosas propuestas para la realización de procesos de verificación de la autorización de procesos de pago utilizando teléfonos móviles u ordenadores personales con conexión a Internet o de un enlace de telecomunicaciones tipo X.25, etc. En general los procesos de pago conocidos emplean como medio de identificación de la tarjeta SIM del teléfono móvil del usuario.To date, numerous proposals have been developed to carry out verification processes for the authorization of payment processes using mobile phones or personal computers with an Internet connection or a telecommunications link type X.25, etc. In general, the known payment processes employ as a means of identifying the SIM card of the user's mobile phone.
En el documento KR20040082790 se describe un aparato para efectuar un pago usando un modelo de código de barras, y un método para facilitar pagar descargando ese código a un terminal móvil. Un terminal de usuario transmite un mensaje de solicitud a un servidor del proveedor para emitir un código de barras, para recibir un código de barras con la información relacionada con la cantidad que va a ser pagada. El servidor del proveedor genera el código de barras correspondiente al mensaje de petición y emite el código de barras y lo transmite al terminal de usuario. El aparato que procesa el pago lee el código de barras mostrado en la pantalla del terminal de usuario para efectuar el pago.Document KR20040082790 describes an apparatus for making a payment using a bar code model, and a method for facilitating payment by downloading that code to a mobile terminal. A user terminal transmits a request message to a provider server to issue a barcode, to receive a barcode with information related to the amount to be paid. The provider's server generates the barcode corresponding to the request message and issues the barcode and transmits it to the user terminal. The device that processes the payment reads the barcode shown on the screen of the user terminal to make the payment.
El empleo de un código de barras para identificar la cantidad que va a ser pagada permite una encriptación de los datos remitidos, pero no ofrece por si sola ninguna garantía de seguridad con respecto al emisor de dicho código y puede ser fácilmente falseada. El proceso descrito en el documento KR20040082790, por tanto, describe un proceso que se inicia en un código de barras cuya función es ejecutar una solicitud de transacción puntual, de valor definido con punto de inicio en el documento que incorpora el código y que deberá ser leido por un usuario definido que tenga la intención de realizar un pago por esa transacción, que ya tiene su importe y destinatario del pago antes de iniciar el proceso.The use of a bar code to identify the amount to be paid allows an encryption of the data submitted, but does not offer any guarantee of security with respect to the issuer of that code and can be easily falsified. The process described in document KR20040082790, therefore, describes a process that starts in a barcode whose function is to execute a specific transaction request, of defined value with starting point in the document that incorporates the code and that should be read by a defined user who intends to make a payment for that transaction, which already has its amount and recipient of the payment before starting the process.
Descripción de la invenciónDescription of the invention
El método de la invención prevé el uso de un "billete virtual" en forma de código de barras, pero en este caso el código de barras está asociado a una URL de muy difícil repetición o localización por medios informáticos, ya que contiene un código pseudoaleatorio que dificulta su localización. Por medio de esta URL se contrasta con la entidad emisora de dicho billete, su existencia, importe, usuario adquirente del mismo y otra serie de datos que hacen de este proceso un procedimiento para efectuar transacciones seguras de pago y cobro. En este modelo de proceso, la función del código de barras no consiste en portar la información para la ejecución de una transacción predefinida, sino que consiste en portar un valor sobre el cual un usuario puede iniciar una solicitud de pago, de cualquier valor inferior al máximo asociado al código de barras y que será leido por cualquier usuario (no restringido) que desee realizar un cobro; en este caso, la transacción (que no es cerrada y no tiene definido importe y destinatario hasta la fase final del proceso) deberá ser iniciada por otro usuario mediante un terminal en cuyo navegador se adquiera la dirección contenida dentro del código de barras.The method of the invention provides for the use of a "virtual ticket" in the form of a barcode, but in this case the barcode is associated with a URL of very difficult repetition or localization by computer means, since it contains a pseudorandom code which hinders its location. Through this URL the entity is contrasted issuer of said ticket, its existence, amount, user acquiring it and another series of data that make this process a procedure to make secure payment and collection transactions. In this process model, the function of the barcode is not to carry the information for the execution of a predefined transaction, but rather to carry a value on which a user can initiate a payment request, of any value less than maximum associated with the barcode and that will be read by any user (not restricted) who wishes to make a payment; In this case, the transaction (which is not closed and has no defined amount and recipient until the final stage of the process) must be initiated by another user through a terminal in whose browser the address contained within the barcode is acquired.
El método aqui propuesto comprende las siguientes etapas: a) La etapa inicial que llamaremos "recarga de saldo" es la de adquisición por parte del usuario de este medio de pago de billetes o medios unitarios de pago, que se efectúa en un servidor emisor de billetes al que se accede a través de una página web, ya sea por medio del teléfono móvil o de un ordenador, en la cual el usuario pagador adquiere billetes con importes indeterminados elegidos por él mismo. Cada usuario que se da de alta en este servicio ha de facilitar, además de ciertos datos personales para comunicar con él como pueden ser su email y número de teléfono móvil. El usuario realiza la recarga de saldo utilizando los medios habituales en el comercio electrónico, como puede ser transferencia bancaria, cargo en cuenta o tarjeta de crédito. La cuenta de usuario mantiene un dato de "saldo" que representará el importe de las "recargas de saldo", más los pagos recibidos de otros usuarios a través de este servicio, menos los pagos emitidos. En todo momento, el saldo (optativamente el "saldo máximo emisible" configurable por el usuario para su cuenta) ha de ser igual al importe representado por los "códigos de barras" ("billetes virtuales") con vigencia en el sistema. Este "saldo máximo emisible" es una cantidad limitante que sirve como salvaguarda de seguridad. Aunque el saldo del usuario sea ÍOOO€, si el saldo máximo emisible es de 200€ sólo habrá en circulación para este usuario una cantidad de 200€. Después de la adquisición de un billete, el servidor procede a su emisión. En esta etapa el servidor emisor asocia a cada billete una URL que contiene un dato "cadena identificadora pseudo aleatoria" especifica, el cual se codifica en un código de barras o código visual que envia al terminal o teléfono móvil del usuario que ha adquirido al billete utilizando el medio preferido por el usuario (correo electrónico, MMS, etc.) . Esta URL se genera pseudoaleatoriamente y tiene una longitud tal que hace imposible su determinación aún por medios informáticos, para garantizar que únicamente ese código de barras se corresponde con esa URL y por tanto con un cierto billete, emitido con un importe concreto y perteneciente a un usuario adquirente especifico. El emisor establece optativamente, ya que el usuario puede deshabilitar este mecanismo completa o parcialmente, una clave de salvaguarda, asociada a cada billete o a cada usuario comprador de billetes. Esta clave de salvaguarda puede ser elegida por el propio usuario adquirente del billete, o generada al azar por el servidor emisor de billetes, y puede ser remitida por éste al usuario adquirente del billete por medio de SMS, email, impresa en el propio billete o, sencillamente, no se envia y debe ser recordada por el usuario poseedor del billete (en caso de clave fija) . Cuando se efectúa el pago de una transacción, el pagador muestra al vendedor o cobrador de la operación el código visual de su billete de pago por cualquier medio, ya sea en la pantalla del teléfono móvil, de un ordenador, en un papel impreso o directamente como archivo de datos gráficos, siendo preferente mostrarlo en la pantalla de su teléfono móvil. El cobrador, a través de su móvil o de un ordenador provisto o asociado a una cámara o a software de interpretación de archivos gráficos, adquiere y lee dicho código y, por medio de un programa que transforma este código en la URL especifica asignada al mismo, conecta con dicha dirección URL y efectúa la validación de dicho billete, comprobando que está vigente, ha sido emitido por el importe y, optativamente, el usuario específicos . d) La etapa de validación de la transacción, se desarrolla cuando el vendedor trasfiere al servidor emisor del billete la clave de protección del billete (salvo si el mecanismo ha sido deshabilitado a voluntad del poseedor del billete) , hasta entonces en poder del comprador, el importe a cobrar del mismo y sus datos de usuario de destino de pago. Si todos estos datos coinciden con lo almacenado en el servidor, éste realiza un traspaso de saldo a la cuenta de usuario del cobrador por importe de la transacción. Optativamente, para impedir el falseo de todos estos datos y garantizar al vendedor que el cobro que acaba de efectuar ha sido real y efectivo, inmediatamente después de efectuada la validación de la compra el servidor emisor del billete le envia una clave encriptada, previamente acordada y conocida únicamente por el cobrador y el sistema de pago ("secreto compartido") . Esta clave valida que el cobrador se ha conectado al sistema de pago legitimo, evitando el falseamiento de cualquiera de estos elementos.The method proposed here includes the following stages: a) The initial stage we will call "balance recharge" is the acquisition by the user of this means of payment of tickets or unit payment methods, which is carried out on a server issuing tickets that are accessed through a web page, either through the mobile phone or a computer, in which the paying user purchases tickets with indeterminate amounts chosen by him. Each user who signs up for this service must provide, in addition to certain personal data to communicate with him such as his email and mobile phone number. He User recharges the balance using the usual means of electronic commerce, such as bank transfer, account charge or credit card. The user account maintains a "balance" data that will represent the amount of the "balance top-ups", plus payments received from other users through this service, less payments issued. At all times, the balance (optionally, the "maximum allowable balance" configurable by the user for your account) must be equal to the amount represented by the "barcodes"("virtualtickets") in force in the system. This "maximum allowable balance" is a limiting amount that serves as a security safeguard. Although the user's balance is € IOOO, if the maximum issued balance is € 200, only € 200 will be in circulation for this user. After acquiring a ticket, the server proceeds to issue it. At this stage, the issuing server associates with each ticket a URL that contains a specific "random pseudo identification string" data, which is encoded in a barcode or visual code that it sends to the terminal or mobile phone of the user who has acquired the ticket using the medium preferred by the user (email, MMS, etc.). This URL is generated pseudorandomly and has a length that makes its determination impossible even by computer means, to ensure that Only that barcode corresponds to that URL and therefore with a certain ticket, issued with a specific amount and belonging to a specific acquirer. The issuer optionally establishes, since the user can disable this mechanism completely or partially, a safeguard key, associated with each ticket or each user buying tickets. This safeguard key can be chosen by the user who acquires the ticket itself, or generated at random by the ticket issuing server, and can be sent by it to the user acquiring the ticket through SMS, email, printed on the ticket itself or , simply, it is not sent and must be remembered by the user who owns the ticket (in case of a fixed code). When payment of a transaction is made, the payer shows the seller or collector of the operation the visual code of his payment ticket by any means, either on the screen of the mobile phone, of a computer, on a printed paper or directly As a graphic data file, it is preferred to display it on the screen of your mobile phone. The collector, through his mobile or a computer provided or associated with a camera or graphic file interpretation software, acquires and reads said code and, through a program that transforms this code into the specific URL assigned to it, connects with said URL and validates said ticket, verifying that it is valid, has been issued for the amount and, optionally, the specific user. d) The transaction validation stage is carried out when the seller transfers the ticket protection key to the issuing server (except if the mechanism has been disabled at the will of the ticket holder), until then held by the buyer, the amount to be collected from it and your payment destination user data. If all these data coincide with what is stored on the server, the latter transfers a balance to the user account of the collector for the amount of the transaction. Optionally, to prevent the falsification of all these data and guarantee the seller that the payment that has just been made has been real and effective, immediately after the validation of the purchase has been made, the ticket issuing server sends you an encrypted key, previously agreed upon and known only to the collector and the payment system ("shared secret"). This key validates that the collector has connected to the legitimate payment system, avoiding the falsification of any of these elements.
Cuando se efectúa una transacción el servidor anula el billete emitido previamente para la misma e incrementa el saldo en la cuenta de usuario del cobrador en la misma medida en que disminuye el saldo en la cuenta del pagador; inmediatamente a la anulación del billete, se emiten nuevos billetes para hacer honor a los nuevos saldos tanto de pagador como de cobrador. Por ejemplo, si en la fase previa hay O€ en el saldo del cobrador y hay ÍOO€ en el saldo del pagador, sea que hay un billete de ÍOO€ en poder del pagador; si la transacción es de 30€, no se restan ÍOO€ al pagador, sino sólo 30€ que pasan al cobrador. Quedan las cuentas como: 70€ en el pagador y 30€ en saldo del cobrador. El billete de ÍOO€ se anula y se emiten: uno de 50€ y uno de 20€ para el pagador y uno de 30€ para el cobrador; el retorno, por tanto, se efectúa en forma de billetes, pero no existe tal concepto de retorno asociado a transferencias o traspasos de saldo.When a transaction is made, the server cancels the previously issued ticket for it and increases the balance in the biller's user account to the same extent that the balance in the payer's account decreases; immediately upon cancellation of the ticket, new tickets are issued to honor the new balances of both the payer and the collector. For example, if in the phase prior there is O € in the balance of the collector and there is € OO in the balance of the payer, whether there is a € billete bill held by the payer; If the transaction is € 30, € O € is not deducted from the payer, but only € 30 is passed to the collector. The accounts remain: € 70 in the payer and € 30 in the balance of the collector. The € O € ticket is canceled and issued: one of € 50 and one of € 20 for the payer and one of € 30 for the collector; the return, therefore, is made in the form of tickets, but there is no such concept of return associated with transfers or balance transfers.
El mantenimiento del sistema de pago aqui preconizado se costea en primer lugar con la publicidad incorporada en cada billete emitido por el servidor emisor de los mismos. Además los billetes adquiridos por los usuarios, mientras no son empleados en alguna transacción, son dinero en depósito en la cuenta de la entidad emisora, que pueden generar un rendimiento financiero.The maintenance of the payment system recommended here is first paid for by the advertising incorporated in each ticket issued by the issuing server. In addition, the tickets purchased by the users, while not being used in any transaction, are money in deposit in the account of the issuing entity, which can generate a financial return.
Descripción de las figurasDescription of the figures
Para complementar la descripción que se está realizando y con objeto de facilitar la comprensión de las características de la invención, se acompaña a la presente memoria descriptiva un juego de dibujos en los que, con carácter ilustrativo y no limitativo, se ha representado lo siguiente:To complement the description that is being made and in order to facilitate the understanding of the characteristics of the invention, a set of drawings is attached to the present specification in which, for illustrative and non-limiting purposes, the following has been represented:
La figura 1 muestra una vista esquemática del proceso de adquisición y emisión de los documentos o medios de pago.Figure 1 shows a schematic view of the process of acquisition and issuance of documents or means of payment.
La figura 2 muestra una vista esquemática del proceso de pago y cobro de una transacción segura. La figura 3 representa un billete tipo emitido para el pago de transacciones según el método de la invención .Figure 2 shows a schematic view of the payment and collection process of a secure transaction. Figure 3 represents a type ticket issued for the payment of transactions according to the method of the invention.
Realización preferente de la invenciónPreferred Embodiment of the Invention
Como se puede observar en las figuras 1 y 2 para el desarrollo de esta metodología son necesarios al menos un servidor (Serví) y una serie de teléfonos móviles, ordenadores personales o cualquier otro tipo de terminal móvil con capacidad de conexión a Internet.As can be seen in Figures 1 and 2 for the development of this methodology, at least one server (Serví) and a series of mobile phones, personal computers or any other type of mobile terminal with Internet connection capability are necessary.
El servidor (Serví) incorpora un software de tratamiento de la información y gestor de bases de datos especifico, en el que se tratan los siguientes datos : a) Datos de usuarios, que incluye datos personales, nombre de usuario, código de usuario y clave de acceso de los usuarios. b) Datos contables, en los que se guardan las recargas solicitadas por el usuario en la tienda/portal web; los cobros y pagos que hacen los usuarios . c) Datos de los activos emitidos, que almacenan los billetes, su vigencia, valor, identificador, usuario, etc. d) Por último los datos de las campañas publicitarias asociadas a las imágenes que se añaden a los billetes.The server (Serví) incorporates a specific information management software and database manager, in which the following data is processed: a) User data, which includes personal data, username, user code and password of user access. b) Accounting data, in which the refills requested by the user are stored in the store / web portal; the charges and payments that users make. c) Data of the assets issued, which store the tickets, their validity, value, identifier, user, etc. d) Finally, the data of the advertising campaigns associated with the images that are added to the tickets.
El teléfono móvil del usuario pagador (Pl) y del cobrador de la transacción (Cl) ha de ser un teléfono móvil GPRSE, programable. En concreto el teléfono del cobrador (Cl) ha de implementar además un software lector de códigos visuales, como puede ser: i-nigma, KAYWA Reader, UpCode, etc.The mobile phone of the paying user (Pl) and the transaction collector (Cl) must be a GPRSE mobile phone, programmable. Specifically, the collector's telephone (Cl) must also implement a visual code reader software, such as: i-nigma, KAYWA Reader, UpCode, etc.
Haciendo referencia en primer lugar a la figura 1, se observa en ella el proceso de adquisición y emisión de los billetes o documentos de pago, que se efectúa en las siguientes fases:Referring first to Figure 1, the process of acquiring and issuing banknotes or payment documents is observed, which is carried out in the following phases:
En la fase 1 el usuario pagador, a través de su teléfono móvil o desde un ordenador (Pl) con conexión a Internet, solicita en una página web implementada en el servidor emisor (Serví) la emisión de uno o más billetes, por los importes elegidos por él, después de haberse dado de alta como tal usuario, proceso en el cual ya ha facilitado al servidor sus datos personales, nombre de usuario, código de usuario, clave de acceso y secreto compartido. Para poder solicitar la emisión de billetes, el usuario deberá haber realizado alguna "recarga de saldo"In phase 1 the paying user, through his mobile phone or from a computer (Pl) with an Internet connection, requests on one web page implemented on the issuing server (Served) the issuance of one or more bills, for the amounts chosen by him, after registering as such a user, a process in which he has already provided the server with his personal data, username, user code, access code and shared secret. In order to request the issuance of tickets, the user must have made a "balance recharge"
En la fase 2, el servidor (Serví) emite el billete o medio de pago, guardando en una base de datos interna la vigencia, valor, identificador, usuario. Cada billete está asociado a una URL que ha sido generada de forma pseudo aleatoria y con una longitud suficientemente larga para que sea de muy difícil localización. Asi mismo, incorpora un mensaje publicitario elegido entre las campañas publicitarias propuestas en ese instante.In phase 2, the server (Serví) issues the ticket or payment method, keeping the validity, value, identifier, user in an internal database. Each ticket is associated with a URL that has been generated in a pseudo random way and with a length long enough to be very difficult to locate. Likewise, it incorporates an advertising message chosen among the advertising campaigns proposed at that moment.
Asi mismo en la fase 3 el servidor (Serví) envia al usuario pagador (Pl) , a través de un SMS, un email, o impreso en el propio cuerpo del billete una clave de salvaguarda, o bien la clave es ya conocida por el usuario y no es necesario su envió. Esta clave puede ser especifica de cada billete o de cada usuario y podrá generarse al azar por el servidor o haberla proporcionado el usuario durante el proceso de alta en el sistema.Also in phase 3 the server (Serví) sends the paying user (Pl), through an SMS, an email, or printed on the body of the ticket a safeguard key, or the key is already known by the user and its sending is not necessary. This key can be specific to each ticket or each user and may be generated randomly by the server or provided by the user during the registration process in the system.
El billete se ha representado con más detalle en la figura 3, se trata de un documento visual que incluye las siguientes zonas:The ticket has been represented in more detail in Figure 3, it is a visual document that includes the following areas:
A.- Un código visual, elegido entre cualquiera de los códigos estandarizados existentes: QR-Code,A.- A visual code, chosen from any of the existing standardized codes: QR-Code,
Datamatrix, etc., que representa la dirección URL en la cual se localizan los datos el billete en el servidor .Datamatrix, etc., which represents the URL in which the ticket data is located on the server.
B.- Un texto, que es opcional y representa información del propietario, si asi lo decide el mismo . C- Un mensaje publicitario.B.- A text, which is optional and represents information of the owner, if so decided by the same. C- An advertising message.
D.- Un texto, también opcional, que indica el importe del billete emitido, la clave, etc.D.- A text, also optional, that indicates the amount of the ticket issued, the key, etc.
El proceso de transacción pago/cobro se observa en la figura 2 y se desarrolla en las siguientes fases :The payment / collection transaction process is observed in Figure 2 and is carried out in the following phases:
En la fase 4 el usuario pagador (Pl) muestra al usuario cobrador (Cl) el billete, por ejemplo, en la pantalla de su teléfono móvil. El cobrador realiza la adquisición del mismo mediante un software de lectura de códigos visuales e interpreta la URL asociada a dicho código.In phase 4 the paying user (Pl) shows the billing user (Cl) the ticket, for example, on the screen of his mobile phone. The collector purchases the same through a software for reading visual codes and interprets the URL associated with that code.
El usuario cobrador (Cl), en la fase 5, conecta su terminal a través de Internet con la URL oculta en el código visual del billete, con el servidor (Serví) el cual recibe una serie de datos de validación, como pueden ser el estado de vigencia y la el valor del billete. El usuario cobrador responde mediante la misma pantalla con: el importe a cobrar de ese billete, el destinatario del pagoThe charging user (Cl), in phase 5, connects its terminal via the Internet with the URL hidden in the visual code of the ticket, with the server (Serví) which receives a series of validation data, such as the validity status and the value of the ticket. The charging user responds through the same screen with: the amount to collect from that ticket, the recipient of the payment
(su código de usuario) y, si se requiere, la clave de salvaguarda del billete. Si los datos suministrados son correctos el servidor efectúa un traspaso de saldo a su cuenta de usuario por importe de la transacción y comunica esta eventualidad al cobrador (Cl) , tal y como se escenifica en la fase(your user code) and, if required, the ticket safeguard key. If the data provided is correct, the server transfers the balance to your user account for the amount of the transaction and communicates this eventuality to the collector (Cl), as staged in the phase
6.6.
Como medida de prevención ante posibles falsificaciones, teniendo en cuenta que el usuario puede ser inducido a usar un servidor ilegitimo mediante un código visual con una URL preparada para ello, se ha previsto que a continuación, es decir después de realizada una transacción, el servidor (Serví) la autentifique mediante el envió de un secreto compartido (7) al cobrador (Cl) , encriptado de forma que sólo él pueda comprobar que efectivamente ha sido enviada por el servidor legitimo y que por tanto todo el proceso ha sido desarrollado de forma real y efectiva.As a preventive measure against possible falsifications, taking into account that the user can be induced to use an illegitimate server by means of a visual code with a URL prepared for it, it is foreseen that then, that is, after a transaction has been carried out, the server (I served) authenticate it by sending a shared secret (7) to the collector (Cl), encrypted so that only he can verify that it has actually been sent by the legitimate server and that therefore the entire process has been developed in a way Real and effective.
Una vez descrita suficientemente la naturaleza de la invención, asi como un ejemplo de realización preferente, se hace constar a los efectos oportunos que los materiales, forma, tamaño y disposición de los elementos descritos podrán ser modificados, siempre y cuando ello no suponga una alteración de las características esenciales de la invención que se reivindican a continuación: Once the nature of the invention has been sufficiently described, as well as an example of a preferred embodiment, it is stated for the appropriate purposes that the materials, shape, size and arrangement of the described elements may be modified, provided that this does not imply an alteration. of the essential features of the invention claimed below:

Claims

REIVINDICACIONES
1.- Método para efectuar transacciones seguras de pago y cobro, por medio de terminales con una conexión de datos, mediante documentos basados en códigos visuales, que se transmiten a través de teléfonos móviles u otros terminales con conexión electrónica, preferentemente a través de Internet, o infraestructuras tipo X25 o Frame Relay, caracterizado porque comprende las siguientes etapas : a) Una etapa inicial de adquisición por parte del usuario de este medio de pago de billetes o medios unitarios de pago, que se efectúa en un servidor emisor de billetes al que se accede a través de una página web, ya sea por medio del teléfono móvil o de un ordenador, en la cual el usuario pagador adquiere saldo que justifique la asignación de billetes con importes indeterminados elegidos por él mismo; b) Una etapa de emisión del o de los billete (s) o medio (s) unitario (s) de pago, en la cual el servidor emisor transforma cada billete en una URL pseudo aleatoria especifica, que codifica en un código de barras o código visual, el cual envia al terminal del usuario que ha adquirido el billete, optativamente junto con una clave de salvaguarda, asociada a cada billete o a cada usuario comprador de billetes; c) Una etapa de pago, en cuya ejecución el pagador muestra al vendedor o cobrador de la operación el código visual de su billete de pago el cual, a través de su móvil o de un ordenador provisto o asociado a una cámara, lee dicho código y, por medio de un programa que transforma este código en la URL especifica asignada al mismo, conecta con dicha dirección URL y efectúa la validación de dicho billete, comprobando que ha sido emitido por el importe reivindicado y que está vigente; d) Una etapa de validación de la transacción durante la cual el vendedor trasfiere al servidor emisor del billete, el importe a cobrar de dicho billete, su dato de usuario de destino de pago y, si es requerida, la clave de emisión del billete en poder del comprador, provocando el servidor un traspaso de saldo a su cuenta por importe de la transacción, cuando la validación ha sido correcta.1.- Method for carrying out secure payment and collection transactions, through terminals with a data connection, through documents based on visual codes, which are transmitted through mobile phones or other terminals with electronic connection, preferably through the Internet , or infrastructures type X25 or Frame Relay, characterized in that it comprises the following stages: a) An initial stage of acquisition by the user of this means of payment of bills or unitary means of payment, which is carried out in a ticket issuing server at that is accessed through a web page, either through the mobile phone or a computer, in which the paying user acquires a balance that justifies the allocation of tickets with indeterminate amounts chosen by him; b) A stage of issuance of the ticket (s) or unit means (s) of payment, in which the issuing server transforms each bill into a specific pseudo random URL, which encodes in a barcode or visual code, which sends to the terminal of the user who has acquired the ticket, optionally together with a safeguard key, associated with each ticket or each user buying tickets; c) A payment stage, in whose execution the payer shows the seller or collector of the operation the visual code of his payment ticket which, through his mobile or a computer provided or associated with a camera, reads said code and, through a program that transforms this code into the specific URL assigned to it, connects with said URL and validates said ticket, verifying that it has been issued for the claimed amount and that is in force; d) A stage of validation of the transaction during which the seller transfers to the issuing server of the ticket, the amount to be collected from said ticket, its payment destination user data and, if required, the ticket issuance key in buyer's power, causing the server to transfer the balance to his account for the amount of the transaction, when the validation has been correct.
2.- Método, según la reivindicación anterior, caracterizado porque inmediatamente después de efectuada la validación de la compra el servidor emisor del billete envia al vendedor o cobrador de la operación una clave secreta, compartida y encriptada, previamente configurada en el servidor y conocida únicamente por el cobrador, la cual garantiza la legitimidad del servidor, evitando el falseamiento de cualquiera de estos elementos.2. Method according to the preceding claim, characterized in that immediately after the validation of the purchase has been made, the ticket issuing server sends to the seller or collector of the operation a secret key, shared and encrypted, previously configured on the server and known only by the collector, which guarantees the legitimacy of the server, avoiding the falsification of any of these elements.
3.- Método, según las reivindicaciones anteriores, caracterizado porque cada billete emitido por el servidor emisor de los mismos comprende, además de una imagen visual codificada y opcionalmente el importe del billete en un formato legible u otro texto informativo, una imagen y/o mensaje publicitario que permite la generación de ingresos por esta aplicación.3. Method according to the preceding claims, characterized in that each ticket issued by the issuing server thereof comprises, in addition to a coded visual image and optionally the amount of the ticket in a readable format or other informational text, an image and / or message advertising that allows the generation of income through this application.
4.- Método, según las reivindicaciones anteriores, caracterizado porque la clave de salvaguarda de cada billete es elegida por el propio usuario adquirente del billete, o generada al azar por el servidor emisor de billetes, y remitida (o no) por éste a dicho usuario por medio de SMS, email, o impresa en el propio billete.4. Method according to the preceding claims, characterized in that the safeguard key of each ticket is chosen by the user who acquires the ticket itself, or randomly generated by the ticket issuing server, and sent (or not) by it to said ticket. user via SMS, email, or printed on the ticket itself.
5.- Método, según las reivindicaciones anteriores, caracterizado porque cuando se efectúa una transacción se anula el billete emitido previamente para la misma, generando el servidor emisor de billetes un traspaso que incrementa el saldo en la cuenta de usuario del cobrador en la misma medida en que disminuye el saldo en la cuenta del pagador; inmediatamente a la anulación del billete empleado, se emiten nuevos billetes para hacer honor a los nuevos saldos tanto de pagador como de cobrador. 5. Method according to the preceding claims, characterized in that when a transaction is made, the previously issued ticket for the same is canceled, generating the ticket issuing server that increases the balance in the user account of the collector to the same extent in which the balance in the payer's account decreases; Immediately upon cancellation of the ticket used, new tickets are issued to honor the new balances of both the payer and the collector.
PCT/ES2008/070129 2008-07-01 2008-07-01 Method for making secure payment and collection transactions by means of terminals with a data connection WO2010000884A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/ES2008/070129 WO2010000884A1 (en) 2008-07-01 2008-07-01 Method for making secure payment and collection transactions by means of terminals with a data connection

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2008/070129 WO2010000884A1 (en) 2008-07-01 2008-07-01 Method for making secure payment and collection transactions by means of terminals with a data connection

Publications (1)

Publication Number Publication Date
WO2010000884A1 true WO2010000884A1 (en) 2010-01-07

Family

ID=41465517

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2008/070129 WO2010000884A1 (en) 2008-07-01 2008-07-01 Method for making secure payment and collection transactions by means of terminals with a data connection

Country Status (1)

Country Link
WO (1) WO2010000884A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2525317A1 (en) * 2011-05-18 2012-11-21 Alcatel Lucent Method and apparatus for conducting a payment transaction
EP2535857A1 (en) * 2011-06-15 2012-12-19 UMS - United Mobility Services AG Payment process with an optical code
ES2401898R1 (en) * 2011-08-03 2013-08-06 Munoz Samuel Peral PROCEDURE TO OPERATE IN AUTOMATIC POCKETS AND POS terminals
WO2015145335A3 (en) * 2014-03-24 2016-03-17 Cellum Innovacios es Szolgaltato Zrt. Systems and methods for an issuer certified card and a quick card

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002029740A1 (en) * 2000-10-05 2002-04-11 Qentis Holding Gmbh Network oriented payment service
WO2002033518A2 (en) * 2000-10-20 2002-04-25 International Barcode Corporation System and method for linking a paper based barcode to a webpage

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002029740A1 (en) * 2000-10-05 2002-04-11 Qentis Holding Gmbh Network oriented payment service
WO2002033518A2 (en) * 2000-10-20 2002-04-25 International Barcode Corporation System and method for linking a paper based barcode to a webpage

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2525317A1 (en) * 2011-05-18 2012-11-21 Alcatel Lucent Method and apparatus for conducting a payment transaction
EP2535857A1 (en) * 2011-06-15 2012-12-19 UMS - United Mobility Services AG Payment process with an optical code
ES2401898R1 (en) * 2011-08-03 2013-08-06 Munoz Samuel Peral PROCEDURE TO OPERATE IN AUTOMATIC POCKETS AND POS terminals
WO2015145335A3 (en) * 2014-03-24 2016-03-17 Cellum Innovacios es Szolgaltato Zrt. Systems and methods for an issuer certified card and a quick card

Similar Documents

Publication Publication Date Title
US20090276347A1 (en) Method and apparatus for use of a temporary financial transaction number or code
CN101840550A (en) Method for realizing purposes of generating and paying bill on site
ES2284667T3 (en) PROCEDURE FOR PAYMENT THROUGH THE MOBILE PHONE AT ANY POINTS OF SALE OR SERVICES.
US11868976B2 (en) Payment system based on a global database of invoices
BRPI0721200A2 (en) METHOD, AND COMPUTER-READABLE MEANS
CA2896763A1 (en) Systems and methods for providing pre-paid multicards
GB2362012A (en) Payment for goods and services using a portable communications terminal
SG186863A1 (en) Method and devices for creating and using an identification document that can be displayed on a mobile device
US20230052863A1 (en) Payment system based on a global database of invoices
RU2744698C2 (en) Systems and methods for providing, replenishing and reimbursing prepaid cards used in transport applications
JP2009123013A (en) Information communication system, communication apparatus, two-dimensional barcode, and method for managing issue of electronic coupon
US20200090160A1 (en) Time Limited Code
KR20140145190A (en) Electronic transaction method
WO2010000884A1 (en) Method for making secure payment and collection transactions by means of terminals with a data connection
CN101351809A (en) System and method for secured account numbers in proximity devices
JP6132923B2 (en) System and method for securely storing and transferring electronic money
ES2564668T3 (en) Methods, devices and systems for obtaining and / or using goods and / or services in a controlled manner
US20180357639A1 (en) Method, system, and apparatus for data transmission and transactions
ES2272533T3 (en) PROCEDURE TO PROVIDE IDENTIFICATION DATA OF A PAYMENT CARD TO A USER.
JP2010267040A (en) Payment terminal device, program, and payment system
ES2422805B1 (en) Procedure for payment by mobile phone in shops
WO2001022309A1 (en) System for effecting prepayment of products or services purchased by electronic means
JP2007140988A (en) Identification system
ES2261666T3 (en) PROCEDURE FOR THE PERFORMANCE OF SAFE TRANSACTIONS BY PAYMENT ELECTRONIC CARDS.
JP2000306032A (en) Electronic currency utilizing portable telephone and electronic wallet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08787663

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08787663

Country of ref document: EP

Kind code of ref document: A1