MX2010014176A - Esquema de ordenamiento. - Google Patents

Abstract

Se describe un esquema de ordenamiento, por ejemplo, un esquema de ordenamiento y pago para dispositivos de comunicación móvil; el esquema de ordenamiento permite que una tienda de Internet u otro proveedor de servicio emita ofertas vinculantes a un dispositivo de comunicación móvil o similar y reciba una aceptación de la oferta desde el dispositivo móvil; la aceptación es encriptada utilizando una clave privada de dispositivo móvil y la oferta puede ser encriptada utilizando una clave privada del proveedor de servicio; el proveedor de servicio se vincula con un contratista de pago y un sistema de cargo para controlar la transferencia de fondos desde el usuario al proveedor de servicio; se puede proporcionar un sistema de gestión de identidad para controlar el acceso a los módulos del esquema de ordenamiento.

Description

ESQUEMA. DE ORDENAMIENTO CAMPO DE LA INVENCION La presente invención se refiere a un esqu namiento, tal como, por ejemplo, un esque namiento y pago para dispositivos de comuni l.

AN ,TE,C-,-E.„—DE.N..T , m.E,r .S DE LA INVENCION La compra remota se ha expandido enormemen recientes. Por ejemplo, la compra por Internet to algo común. Las órdenes de compra enviadas ositivos de comunicación móviles, tal como tel les, también se han vuelto algo común.

Un primer problema con la compra remota, ta ra por Internet, es proporcionar tanto a proveedo acidad. Los consumidores son renuentes a proporci proveedores de servicios y productos información como nombres completos, direcciones, detall eta de crédito y contraseñas. Esto es particula to cuando el proveedor no es una marca de confi conocido .

Además, aunque se sabe que los operador icios de telecomunicaciones proporcionan sistem ago y otros sistemas para el cargo de servicios ntes, en general, estos sistemas de cargo ringidos a servicios proporcionados por el operad icio de telecomunicaciones particular. Aunqu adores del servicio de telecomunicaciones tien cidad técnica para proporcionar servicios financi eedores de servicios terceros, la implementaci os sistemas ha resultado difícil. Un problema e SUMARIO DE LA INVENCION La presente invención proporciona un métoc rende los pasos de: un proveedor de servicio {ta tienda de Internet) que emite una oferta a un dispo usuario (tal como una computadora o un dispositi nicación móvil), en donde la oferta comprende un aje que incluye información (tal como descripcio ios de productos /servicios ) relacionada con un ar es ofrecido; y el dispositivo de usuario que env tación de la oferta al proveedor de servicios, en aceptación comprende un segundo mensaje y en don tación' está codificada utilizando una clave priva ositivo de usuario. El proveedor de servicio en e validar que la aceptación fue firmada p ositivo de usuario (utilizando la clave públic ositivo de usuario) . un producto que está siendo ofrecido; y el disposit rio está configurado para enviar una aceptación ta al proveedor de servicio, en donde la acep rende un segundo mensaje y en donde el segundo mens ficado utilizando una clave privada del dispositi rio. El proveedor de servicio entonces puede valid aceptación fue firmada por el dispositivo de u lizando la clave pública del dispositivo de usuario) El envió de una aceptación codificada de la e el dispositivo de usuario al proveedor de se orciona al proveedor de servicio evi tográficamente segura de que la orden fue hecha nte autorizado. La evidencia es fuerte y segura de solamente el dispositivo de usuario debiera cono e privada relevante. Tal como se analiza con lie a continuación, el proveedor de servicio pue En algunas formas de la invención, el pri ndo mensajes son los mismos de manera que, a f tar la oferta, el dispositivo de usuario simpl fica el primer mensaje y envía el mensaje codific eso al proveedor de servicio.

La oferta puede ser codificada; por ejempl er mensaje puede ser codificado utilizando la ada del proveedor de servicio. Por lo tanto, el en ferta desde el proveedor de servicio al disposit rio proporciona al usuario evidencia criptográfic ra de que la oferta fue hecha y los términos e es se realizó la oferta {por ejemplo, el precio encia es fuerte y segura debido a que solamen eedor de servicio debiera conocer la clave p vante .

La información de la orden recibida des avés del equipo de usuario; una vez más, la inforr a orden podría ser encriptada con cualquiera de la ada del proveedor de servicio o la clave privad rio .

En muchas formas de la invención en la cu rmación de la orden es enviada al contratista de pa rmación enviada al contratista de pago contiene men información incluida en la oferta. En particula as formas de la invención, datos relacionados c es y servicios que están siendo comprados n uidos. El motivo detrás de esto es que el contrati no necesita conocer la naturaleza de los bie icios involucrados cuando se determina si el pago d izarse o no. Dado que estos datos no son necesari erible no incluir dichos datos en mensajes al contr ago, tanto en términos de la minimizacion de los uir al menos algunos de: un pseudo-nombre del usuar tificador del proveedor de servicio, preci ripciones de los bienes y/oJ servicios que se ciendo, la hora actual y un nonce (número utiliza , cuyos datos pueden ser codificados utilizando la ada del proveedor de servicio. La aceptación del suario al proveedor de servicio puede contener los i s, aunque estos datos pueden ser codificados util lave privada del equipo de usuario. Los datos envia ratista de pago pueden omitir los' datos relacionad bienes y/o servicios.

A manera de ejemplo adicional, los datos de ados desde el proveedor de servicio al equipo de u en incluir al menos algunos des : un pseudo-nombr rio, un identificador del proveedor de servicio, p escripciones de los bienes y/o servicios que se son enviados a un servicio de cargo. En muchas for nvención en la cual la información de pago es envi icio de cargo, la información enviada al servic o contiene menos que la información incluida en la la información enviada al contratista de pag icular, en muchas formas de la invención, cionados con los bienes o servicios que se iriendo no son incluidos y los datos que identifi eedor de servicio no son incluidos . El motivo det es que el servicio de cargo no necesita conoc raleza de los bienes o servicios involucrados, eedor de servicio en cuestión cuando se determina debiera realizarse o no. ¦ En algunas formas de la invención, se genera ajes separados, un primer mensaje que forma la a por el proveedor del servicio, un segundo mensaj ios y descripciones de los bienes y/o servicios n ofreciendo, y el precio total. Alternativament er mensaje puede comprender un pseudo-nombre del us identificador del proveedor de servicio, el pre ripciones de los bienes y/o servicios que se ciendo, la hora actual y un nonce (número utiliza . También son posibles otros formatos de mensaje.

El segundo mensaje puede comprender un p re del usuario, un identificador del proveed icio, y el precio total . Alternativamente, el s aje puede comprender un pseudo-nombre del usuari tificador del proveedor de servicio, precios d es y/o servicios que se estén ofreciendo, la hora nonce (número utilizado una vez) . También son po s formatos de mensaje.

El tercer mensaje puede comprender un pseudo-uir el límite de crédito del usuario. En una fo nvención, el límite de crédito es proporcionado eedor de identidad. El límite ' de crédito, orciona, puede ser encriptado utilizando la ica del contratista de pago de manera que solame ratista de pago puede ver los datos de lími ito .

El contratista de pago puede validar que los ados a éste fueron enviados por el proveed icio al desencriptar los datos utilizando la ica del proveedor de servicio. Se debería observ paso puede ser llevado a cabo sin considerar s son recibidos directamente desde el proveed icio o a través del equipo de. usuario ya qu quier caso, los datos pueden ser encriptados eedor de servicio utilizando la clave privad contratista de pago necesitaría desencriptar esos izando la clave publica apropiada.

El contratista de pago puede confirma pción de los datos de la orden al proveed icio. La recepción puede ser encriptada utiliza e privada del contratista de pago. El proveed icio puede emitir el recibo de pago al equi rio, por ejemplo, encriptado utilizando la ada del proveedor de servicio.

En una forma de la invención, el contratis encripta la información de la orden utilizand e privada del contratista de pago y enví rmación de la orden encriptada a un sistema de g dentidad. Además, la información de la. orden encr e ser enviada desde el contratista de pago al s estión de identidad a través del equipo de usuario rio son autenticados, un recibo de pago pued ado al equipo de usuario. En una forma altérnat nvención en la cual la información de orden es e ctamente desde el contratista de pago al siste ión de identidad, el sistema de gestión de ide lemente puede autenticar al contratista de pago ién al equipo de usuario) .

En muchas formas de la invención, un reci es emitido al usuario cuando el pago ha irmado. Este recibo de pago puede ser encriptad plo, utilizando la clave privada del proveed icio. El proveedor de servicio puede enviar tañ bo de orden como un recibo de pago al us quiera o ambos de los cuales puede estar encr izando la clave privada del proveedor de servici bos de orden y pago pueden ser enviados juntos glo para permitir a un usuario registrarse c eedor de servicio. A manera de ejemplo, se orcionar un arreglo de registro sencillo ba rol del sistema de gestión de identidad.

BREVE DESCRIPCION DE LAS FIGURAS La presente invención se describirá ahora, a i ejemplo únicamente, con referencia a las sigu ras numeradas .

La figura 1 es un diagrama en bloques ema de acuerdo con un primer aspecto de la pr nción ; La figura 2 es un gráfico de flujo que demues ritmo de acuerdo con un aspecto de la presente inve La figura 3 demuestra una secuencia de mensa rdo con un aspecto de la presente invención; relo con un aspecto de la presente invención.

DESCRIPCION DETALLADA DE LA INVENCION La figura 1 muestra un sistema, in ralmente por .el número de referencia 2, de acuerdo cto de la presente invención. El sistema 2 com po de usuario 4 (tal como una computadora ositivo de comunicación móvil), un proveedor de se al como una tienda de Internet) , un sistema de gest tidad 8, u contratista de pago 10, y un sistema de tal como un sistema de cargo del operador de servic comunicaciones ) .

La figura 2 es un gráfico de flujo que mues ritmo ejemplar, indicado generalmente por el núme rencia 20, para permitir a un usuario que utili po de usuario 4 comprar productos o servicio suario es desconocido, el algoritmo se mueve al pa cuyo punto al usuario se le solicita registrarse 9. Si el usuario se registra con éxito en el I ritmo 20 se mueve al paso 28 donde el usuar nticado; de otra forma el algoritmo termina en e Del paso 28 el algoritmo 20 se mueve al pa e. el usuario realiza compras en el proveedor de ser ejemplo, llenando un carrito de compras en linea ra bien conocida en la técnica.

Una vez que el usuario ha terminado sus compr ra una orden y se le solicita al usuario, en el pa confirme la orden. Si la orden es confirmad ritmo 20 se mueve al paso 34. De otra forma, el alg ermina en el paso 38.

En el paso 34, el usuario busca pagar la ante un dispositivo con un navegador y decide utili do-nombre (registrado con el sistema de gesti tidad 8) para comprar en la Internet, visitando uno eedores de servicio 6 para hacerlo. El sistema de s compartido en cierta forma con el sistema de gest tidad 8. El sistema de gestión de identidad eedor de servicio 6 y el contratista de pago 10 p uno, un par de claves privada y pública para firm ajes y tener publicadas su clave pública para permi ficación de su firma mediante los receptores d ajes para proporcionar el origen de los mensajes.

La figura 3 muestra una secuencia de m plar, indicada generalmente por el número de refe entre el equipo de usuario 4, el proveedor de serv i sistema de gestión de identidad 8. La secuenc aje 40 es una implementación ejemplar de los pasos nticación es reenviada por el equipo de usuario ema de gestión de identidad 8 junto con una gall ón para autenticar al usuario, si dicha gallega h íamente almacenada en el equipo de usuario. Estos> pueden llevar a cabo automáticamente cuando el u nta tener acceso al proveedor de servici ementando así un algoritmo de registro sencillo.

Si el usuario es conocido para el siste ión de identidad 8, entonces el sistema de gest tidad envía un mensaje de autorización al equi rio 4 para reenvío por parte del equipo de usua eedor de servicio 6. El equipo de usuario 4 reen rización al proveedor de servicio 6 y el provee icio permite que el equipo de usuario tenga acc eedor de servicio y confirme esto reenviando un m xito al equipo de usuario. ica/privada SA; 2. - La clave pública del equipo de usuario ada al sistema de gestión de identidad 8; 3. - El sistema de gestión de identidad 8 so suario proporcionar sus credenciales; 4. - El usuario proporciona las creden eridas (por ejemplo, nombre de usuario y contras és del equipo de usuario 4; 5. - El sistema de gestión de identidad 8 re credenciales de usuario y responde enviando una g esión al equipo de usuario para uso en una autenti erior .

Se conocen y podrían utilizar otros mecanismo strar el equipo de usuario 4 con el sistema de gest tidad 8.

La figura 4 es un gráfico de flujo que mues ían utilizar otros formatos de mensaje, por supuest ienen la información de pago, el pseudo-nombr rio y detalles de los productos/ servicios que ha nados. Estos mensajes se refieren a continuación n A, Orden B y Orden C e incluyen los siguientes da Orden A: Srv, ps, g, p, t; Orden B: Srv, ps, t; Orden C: ps, t. e : • Srv identifica al proveedor de servicio; • ps es el pseudo-nombre del usuario; • g es una descripción de los bienes o servicio, ro de artículo; • p es el precio de los bienes o servicios indivi uestión; y • t es el precio total para los bienes y ser irmación incluyendo los detalles de la orden q ada al usuario, junto con los mensajes de Orden A, Orden 'C. La página de confirmación representa una ulante (posiblemente de duración limitada) hecha eedor de servicio al usuario. La página de confir enta al usuario una caja de diálogo preguntan rio que confirme que la orden debiera ser procesa irmación del usuario (paso 44 del algoritmo 41) resultado que los mensajes de Orden A, Orden B y O firmados por la clave privada del equipo de us a confirmación representa una aceptación vinculan suario de la oferta del proveedor de servicio.

Los mensajes encriptados son enviados de regr eedor de servicio 6. El proveedor de servicio 6 en da la firma del usuario para cada uno de los ajes (paso 46) utilizando la clave pública del equ El contratista de pago 10 recibe los me iptados Orden B y Orden C desde el equipo de usuar da los mensajes utilizando la clave pública del pro ervicio (paso 50) . Si se valida la firma del provee icio, entonces el algoritmo 41 se mueve al paso forma, el algoritmo 41 termina en el paso 62 era observar que en una forma alternativa nción, los mensajes encriptados Orden B y Orden ados al contratista de pago a través del siste ión de identidad 8: en dicho arreglo, el siste ión de identidad puede verificar las firmas d ajes Orden B y Orden C más que el contratista d En el paso 52, el contratista de pago 10 fi aje Orden C utilizando su clave privada y env aje encriptado al sistema de gestión de identida ermina en el paso 62.

En el paso 56, el sistema de gestión de ident acta el sistema de cargo 12 para deducir la ca citada de la cuenta del usuario en el sistema de el sistema de cargo confirma que esto ha ocurri ritmo se mueve al paso 58; de otra forma, el alg liza en le paso 62.

En el paso 58, el sistema de gestión de ide ra una confirmación firmada de pago y envía es ratista de pago. El contratista de pago 10 verif a del sistema de gestión de identidad utilizando la ica del -sistema de gestión de identidad. Si la fi ficada, el algoritmo 41 se mueve al paso 60; d a el algoritmo 41 termina en el paso 62.

En el paso 60, el contratista de pago 10 disp sferencia de la suma confirmada a la cuenta del pro ) 23 servicio de manera similar puede retener una v iptada de la aceptación. Los datos de orden encri transferidos entre el proveedor de servici ratista de pago, el sistema de gestión de identida ema de cargo. Los datos que son enviados son restri manera que el contratista de pago no recibe cionados con los bienes o servicios ordenados o el os artículos individuales (solamente un precio gene sistema de cargo recibe solamente un pseudo-nomb rio y la cantidad total de dinero que se va a trans A continuación se describe una segunda modali nvención con referencia a las figuras 5 a 7.

La figura 5 muestra un sistema, in ralmente por el número de referencia 102, de acuer aspecto de la invención. El sistema 102 compren eedor de identidad 104, equipo de usuario 10 icio es vendido al usuario.

El proveedor de servicio 108 obtiene el pag productos o servicios vendidos mediante el envío de vantes al contratista de pago 110. El contratista d a su vez se vincula con el servicio de cargo 112 e pera el pago del usuario, por ejemplo, realizan o al usuario por medio de una cuenta telefónica.

La figura 6 muestra un algoritmo 120 de acuer egunda modalidad de la presente invención.

El algoritmo 120 inicia en el paso 122 en cuy equipo de usuario 106 selecciona productos o ser orcionados por el proveedor de servicio 108 que rés para el usuario. A continuación, el algorit e al paso 124 en cuyo punto una oferta vinc cionada con los productos y/o servicios selecciona ada desde el servicio 108 al usuario 106. Tal c rados, el algoritmo 120 termina en el paso 128. po de usuario 106 indica que los productos y/o ser eran ser comprados, el algoritmo 120 se mueve a En el paso 130, el equipo de usuario envi n criptográficamente protegida al proveedor de se Tal como se describe adicionalmente a continuaci rio también puede enviar campos adicionales, los ién pueden ser criptográficamente seguros, per ienen menos información que la orden complet eedor de servicio 108 entonces puede reenviar los vantes al contratista de pago 110 y/o el sistema de para probar que el usuario realmente ordenó un pro proceso puede ser acomodado para proteger la priv usuario al omitir información relacionada c tidad del usuario, tal como se describe adicionalm bos han sido expedidos, el algoritmo 120 termina1 128.

Antes que cualesquiera órdenes realizadas po de usuario 106 puedan ser procesadas en el s se debe establecer la confianza entre los element ema 102. Inicialmente se asume que el proveed tidad 104, el proveedor de servicio 108, el contr ago 110 y el sistema de cargo 112 utilizan certif una autoridad de certificado de raíz común (CA) s, que todos estos elementos del sistema 102 ificados firmados por las autoridades de certifica reconocidas por todos los elementos en el sistema.

El usuario 106 puede generar credenciales, ta s de claves públicas/privadas y pseudo-nombr citar al proveedor de identidad 104 certificarla e que los usuarios ya tienen otras credenciales enciales con regularidad evita que los proveedo icio rastreen a los usuarios sobre periodos de ongados .

La figura 7 muestra una secuencia de men cada generalmente por el número de referencia 140, lidad ejemplar de la presente invención. La secuenc tra mensajes enviados entre el proveedor de ide el equipo de usuario 106, el proveedor de servici ontratista de pago 110 y el sistema de cargo 112.

Se asume que antes que del flujo de m rado en la figura 1, el equipo de usuario 106 ha ar de claves pública/privada {PKU, K) y que el pro dentidad 104 ha recibido o verificado de forma seg te de crédito (L) del usuario y ha creado o verific do-nombre para el usuario (ps) .

El primer mensaje, indicado por el núme • PKU es la clave privada del usuario.

El mensaje 142 es enviado para registrar al u y su clave pública K con el proveedor, de identidad amente necesita realizarse una vez para cada us autenticar, el usuario 106 utiliza las credencial iene (que no se muestran) . En este arreglo, el pro identidad 104 ya conoce la clave pública del equ rio 106 y, por lo tanto, puede desencriptar el m El segundo mensaje 144 es un bloque de gorizado (token) Ti enviado desde el proveed tidad 104 al equipo de usuario 106. El bloque de gorizado Ti es de la siguiente forma: {ps, L, K, e : • ps es un pseudo-nombre del usuario (por ej NO) ; suario al proveedor de servicio 108 {mensaje 146). o, el proveedor de servicio 108 recibe un m iptado que contiene el pseudo-nombre del usuari te de crédito del usuario, la clave pública del usu tiempo de máxima validez para el bloque de gorizado. El proveedor de servicio 108 conoce la ica del proveedor de identidad 104 y, por lo tanto, ncriptar el mensaje 146.

En respuesta, el proveedor de servicio env aje 148, el cual define una oferta vinculante a por el proveedor de servicio al usuario (impleme el paso 124 del gráfico de flujo 120) . El mensaje de la siguiente forma: {ps, Srv, p, g, t, n}s, donde • ps es un pseudo-nombre del usuario; • Srv identifica al proveedor de servicio; • p es el precio de los bienes o servicios indivi cita al usuario la autorización y le pide realiz ba de posesión del bloque de texto categorizado ndo mensaje 146. El equipo de usuario .106 conoce la ica del proveedor de servicio y, por lo tanto, ncriptar el mensaje 148.

En respuesta, el equipo de usuario 106 en aje 150 al proveedor de servicio 108. El mensaje a siguiente forma: {ps, Srv, p, g, t, }PKur donde lave privada del usuario (es decir, la confirmación n 148 es desencriptada por el equipo de usuario y d lemente encriptada otra ' vez utilizando la clave p equipo de usuario) . De esta forma, el equipo de u acepta la oferta (completando así el paso 130 del g flujo 120) firmando la información de la trans liada con su clave privada PKU.' Además de enviar el mensaje 150, incluyen icio. El bloque de texto categorizado T3 es iente forma: {ps, p, t, n}s. Por lo tanto, el blo o categorizado T3 omite tanto información referente uctos o servicios ordenados como información refere eedor de servicio 108.

Cuando el proveedor de servicio recibe el m un mensaje 152 es enviado desde el proveedor de se al usuario 106. El mensaje 152 es de la siguiente , t, n, 1}S- El mensaje 152 sirve como un rec n, implementando asi parte del paso 132 del gráf o 120.

Con la orden confirmada, el proveedor de se envía un mensaje 154 al contratista de pago ll aje 154 comprende los bloques de texto categorizado y opcionalmente también incluye el bloque de gorizado T3. Al recibir los bloques de icio 108. En la secuencia de mensaje ejemplar 140 bo de pago asume la forma de un mensaje 156 que com bloque de texto categorizado T2 encriptado utiliza e privada del contratista de pago 110.

El contratista de pago 110 también infor ema de cargo 112 respecto del pago enviando cual bloque de texto categorizado T2 o T3 al operador saje 158) . (Se puede preferir el envío del blo o categorizado T3 ya que omite información refere eedor de servicio, limitando así la información e sistema de cargo 112 únicamente a la información ema de cargo necesita conocer a fin de complet n) . El servicio de facturación del sistema de car nces puede facturar al usuario y posiblemente ajus te de crédito restante del usuario.

Finalmente, cuando el proveedor de servic eedor de servicio ofreció un producto o servici tas condiciones (incluyendo el precio) .

Además, el proveedor de servicio recibe un m saje 150) encriptado utilizando la clave priva rio que puede ser utilizada como prueba de que el u nó un producto particular o servicio.

Además, el usuario recibe mensajes (mensajes encriptados utilizando la clave privada del provee icio que pueden ser utilizados como prueba de eedor de servicio confirmó la recepción de la orden roveedor de servicio confirmó la recepción del pago Tal como se analizó anteriormente, la pr nción incluye la transmisión de limites de crédi te de crédito de un usuario puede ser parte del blo o categorizado emitido por el proveedor de identid presente, éste informa al proveedor de servicio ador de la red esté garantizado para pagar al pro servicio por la transacción actual. Se debiera ob la revisión del limite de crédito por el provee icio puede tener consecuencias en la vida mación que contiene el limite de crédito.

El algoritmo 120 antes descrito emprende un pasos para proteger la privacidad del usuario. ritmo 120, el contratista de pago 110 necesita cono idad de dinero que se va a transferir, pero no ne cer los productos o servicios o el tipo de produ icios que son ordenados por el equipo de usuario 10 tanto, los bloques de texto categorizados T2 y uyen información relacionada con los productos. Po e, el proveedor de servicio 108 necesita sab cción IP del usuario, pero t no la identida umidor . Por consiguiente, al proveedor de servicio incluirán varios proveedores de identidad 104, ratistas de pago 110, varios sistemas de cargo os proveedores de servicio 108 y muchos usuarios 1 ra similar, el arreglo de la figura 1 puede i os sistemas de gestión de identidad 8, ratistas de pago 10, varios sistemas de cargo 12, eedores de servicio 6 y muchos equipos de usuario 4.

La presente invención se ha descrito anterio referencia a dos modalidades detalladas. Tal como aparente para aquellos expertos en la té cteristicas descritas con referencia a una modali ían incorporar en la otra modalidad. A menos que r ble hacerlo, la presente invención incluye toda inaciones de las dos modalidades.

Las modalidades de la invención antes descrit trativas en lugar de restrictivas . Resultará ap

Claims (1)

1. NOVEDAD DE LA INVENCION Habiendo descrito el presente invento, idera como una novedad y, por lo tanto, se reclam ridad lo contenido en las siguientes: REIVINDICACIONES 1.- Un método que comprende los pasos de: un proveedor de servicio que emite una ofert ositivo de usuario, en donde" la oferta compren er mensaje incluyendo información relacionada co culo que se está ofreciendo; y el dispositivo de usuario envía una aceptaci ferta al proveedor de servicio, en donde la acep rende un segundo mensaje y en donde la aceptaci iptada utilizando una clave privada del dispositi io . nviar información de la orden a un contratista de 5. - El método de conformidad con la reivindi aracterizado porque la información de la orden e ontratista de pago contiene menos información que ta . 6. - El método de conformidad con la reivindi 5, car cterizado porque el primer mensaje incluy era porción y una segunda porción, en donde la s ión es para enviarse al contratista de pago. 7. - El método de conformidad con la reivindi caracterizado porque el segundo mensaje incluy era porción y una segunda porción, en donde la s ión es para enviarse al contratista de pago, y en rimera y segunda porciones son encriptadas por se izando la clave privada del dispositivo de usuario 8. - El método de conformidad con cualquiera rmación de la orden encriptada a un sistema de g dentidad. 10. - El método de conformidad con indicación 9, caracterizado porque la información n encriptada es enviada desde el contratista de p ema de gestión de identidad a través del equi rio . 11. - El método de conformidad con indicación 10, caracterizado porque el siste ión de identidad autentica tanto al contratista d al equipo de usuario desde el cual se env rmación de orden encriptada. 12. - El método de conformidad con indicación 11, caracterizado porque si tant ratista de pago como el equipo de usuario nticados, el sistema de gestión de identidad info el proveedor de servicio está configurado ir una oferta al dispositivo de usuario, en don ta comprende un primer mensaje que incluye infor cionada con un producto que es ofrecido; y el dispositivo de usuario est configurado ar una aceptación de la oferta al proveed icio, en donde la aceptación comprende un s aje y en donde el segundo mensaje está encr izando una clave privada del dispositivo de usuari 15. - El sistema de conformidad co indicación 14, caracterizado porque el proveed icio está configurado para encriptar el primer m izando una clave privada del proveedor de servicio 16. - El sistema de conformidad co indicación 14 o 15, que además comprende un contr ago, en donde el proveedor de servicio está confi indicación 16 o 17, caracterizado porque el contr ago está adaptado para validar que la información n fue enviada por el proveedor de servicio. 19. - El sistema de conformidad con cualquie reivindicaciones 14 a 18, que además compren ema de gestión de identidad, en donde el contrati está adaptado para encriptar la información n utilizando una clave privada del contratista d ra enviar la orden encriptada al sistema de gest t idad . 20. - El sistema de conformidad co indicación 19, caracterizado porque el siste ión de identidad está configurado para autenticar ontratista de pago como al equipo de usuario des se envía la información de la orden encriptada. 21. - El sistema de conformidad con cualquie