MX2008013116A - Autentificacion para una transaccion comercial utilizando un modulo movil. - Google Patents

Autentificacion para una transaccion comercial utilizando un modulo movil.

Info

Publication number
MX2008013116A
MX2008013116A MX2008013116A MX2008013116A MX2008013116A MX 2008013116 A MX2008013116 A MX 2008013116A MX 2008013116 A MX2008013116 A MX 2008013116A MX 2008013116 A MX2008013116 A MX 2008013116A MX 2008013116 A MX2008013116 A MX 2008013116A
Authority
MX
Mexico
Prior art keywords
payment
merchant
mobile
services
goods
Prior art date
Application number
MX2008013116A
Other languages
English (en)
Inventor
Bruce E Johnson
Chung Webster-Lam
Original Assignee
Microsoft Corp
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 Microsoft Corp filed Critical Microsoft Corp
Publication of MX2008013116A publication Critical patent/MX2008013116A/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06—COMPUTING OR CALCULATING; 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q30/0601—Electronic shopping [e-shopping]

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Las modalidades actuales proporcionan la autorización pago de una transacción comercial en línea entre un comprador y un comerciante, que incluyen la verificación de una identidad del comprador y una verificación de la capacidad que tiene el comprador para pagar por la transacción, en donde el proveedor de identidad y el proveedor de pago con frecuencia son entidades de red diferentes. Otras modalidades también proporcionan protocolos, sistemas de cómputo y otros mecanismos que permiten la autentificación de identidad y pago utilizando un módulo móvil, el cual establece una seguridad de nivel simple o de nivel múltiple a través de una red no confiable (por ejemplo, la Internet). Aún otras modalidades también proporcionan una comunicación segura de tres vías entre un comerciante, consumidor y proveedor de pago, de modo que la información sensible de la cuenta no sea visible para el comerciante, quedando aún lo suficientemente confiado el comerciante de la capacidad que tiene el consumidor para pagar por las compras solicitadas. Aún en otra modalidad, se utiliza la información de facturación electrónica con propósitos de autorización, auditoria, federación de pago y otros propósitos.

Description

AUTENTIFICACIÓN PARA UNA TRANSACCIÓN COMERCIAL UTILIZANDO UN MÓDULO MÓVIL Campo de la Invención La presente invención se refiere a sistemas de transacción en red y a métodos para llevar a cabo transacciones en línea. Antecedentes de la Invención La proliferación de sistemas de cómputo en red ha abierto nuevas posibilidades con respecto a como llevan a cabo los negocios las corporaciones e individuos. Por ejemplo, los usuarios de extremo conectados a una red (por ejemplo la Internet) a través de un aparato en red tal como una computadora, PDA, teléfono celular, etc., pueden llevar a cabo transacciones comerciales en la red para comprar servicios y/o mercancías, llevar a cabo transacciones financieras o conducir de otra forma negocios o llevar a cabo transacciones personales en la red. Un problema inherente con las transacciones en línea es la seguridad, particularmente cuando está implicada en la transacción la transferencia de dinero, fondos y/o información confidencial financiera, personal u otra.
Muchas de las transacciones en línea convencionales se llevan a cabo de acuerdo con uno o de dos modelos diferentes, aunque relacionados. Ambos modelos emplean un buscador en la interfase para manejar la transferencia de información entre las partes implicadas en la transacción. En el primer modelo, un comerciante ofrece bienes y servicios en línea a través de un buscador. El término "comerciante" se refiere en la presente invención de manera general a cualquier entidad que ofrece bienes y/o servicios para compra. El término "comerciante" no se utiliza para describir cualquier estado comercial en particular o para describir a un vendedor con licencia, a menos que se manifieste de manera específica. Más bien, el término describe de manera general cualquier vendedor o entidad que ofrece bienes y/o servicios para compra o venta. El término proveedor de servicios se utiliza en la presente invención de manera intercambiable con el término comerciante, y a menos que se manifieste lo contrario, tienen el mismo significado. En una transacción en línea convencional, un comerciante puede tener un sitio web que describe, despliega u ofrece de otra forma bienes y/o servicios para venta. Un usuario final indica el deseo de comprar uno o más bienes o servicios, seleccionando normalmente el artículo a través de la interfase del buscador. Posteriormente el buscador despliega una página de transacción que permita al usuario final seleccionar uno o más tipos de pago, e ingresar información necesaria para completar la transacción. Por ejemplo, la página de transacción desplegada por el buscador, puede permitir al usuario final seleccionar un tipo de pago, tal como una tarjeta de crédito (por ejemplo VISA, MasterCard, American Express, etc.) e ingresar información de transacción tal como número de tarjeta de crédito, fecha de expiración de la tarjeta, etc. La página de transacción también puede solicitar al usuario final información personal tal como nombre, dirección de facturación, dirección de envío, etc. El usuario final posteriormente presenta la información y el comerciante procesa la información presentada. En este primer modelo, el comerciante normalmente es el "dueño" del sitio web. Esto es, el comerciante que mantiene el sitio web, es responsable del contenido, y recibe y procesa la información de transacción proporcionada por el usuario final. El comerciante puede establecer una cuenta con el usuario final antes de llevar a cabo la primera transacción, y el usuario final puede posteriormente accesar a dicha cuenta a través de un registro establecido por el usuario y una contraseña cada vez que el usuario final lleve a cabo una transacción con el comerciante. Esto es, el usuario final normalmente elige un nombre y una contraseña que será utilizada en subsecuentes cesiones o transacciones. Después de que el usuario final ha presentado la información solicitada por la página(s) de transacción, el comerciante procesa la información para asegurarse que la información es suficiente para completar la transacción. Por ejemplo, el comerciante puede asegurar que el número de tarjeta de crédito es válido y tiene suficientes fondos para cubrir el costo de los bienes y/o servicios. El segundo modelo normalmente incluye un proveedor de transacción de tercera parte que maneja la parte de pago de la transacción. La tercera parte forma una relación tanto con el usuario final como con el comerciante. En particular, el usuario final puede establecer una cuenta con la tercera parte que puede ser acezada a través de un registro y password, tal como se describió anteriormente. Para establecer la cuenta, el usuario final puede proporcionar información personal y de pago a la tercera parte (por ejemplo, el usuario final puede proporcionar información personal que identifica al usuario e información de pago tal como uno o más números de tarjeta de crédito, fechas de expiración, etc. El usuario final también puede establecer una cuenta de fondos electrónicos proporcionando dinero al proveedor de transacción de tercera parte, cuyo saldo se puede utilizar para comprar bienes y/o servicios en línea. La tercera parte archiva la información de la cuenta proporcionada por el usuario final y/o mantiene el saldo del usuario final. La tercera parte también establece una relación con el comerciante, en donde la tercera parte maneja el procesamiento de pago de la transacción. En particular, la tercera parte está de acuerdo en hacer pagos al comerciante cuando el usuario final con una cuenta solicita una transferencia de fondos para realizar una compra. El comerciante puede proporcionar la opción de utilizar la tercera parte, señalando la disponibilidad de esta opción en su sitio web, en donde se están vendiendo los bienes y servicios. Por ejemplo, cuando un usuario visita un sitio web del comerciante y decide realizar una compra, posteriormente al usuario se le puede presentar una opción para pagar la compra utilizando el proveedor de transacción de tercera parte. Cuando el usuario final selecciona la opción de pagar al comerciante utilizando el proveedor de transacción de tercera parte, el buscador del usuario final es redirigido a un sitio web que pertenece al proveedor de transacción de tercera parte. Posteriormente el usuario final se registra en su cuenta a través de la combinación de registro/contraseña y selecciona un tipo de pago (por ejemplo tarjeta de crédito) para utilizar una transacción, o solicita una transferencia de fondos de la cuenta de fondos del usuario a la cuenta del comerciante. Una vez que el comerciante determina que el pago ha sido transferido en forma adecuada por parte del proveedor de la transacción, el comerciante puede proceder a enviar el producto comprado o proporcionar el servicio comprado al usuario final. En el segundo modelo, la tercera parte es responsable de mantener la información personal y financiera del usuario final, y .de procesar la transacción. Breve Descripción de la Invención Las transacciones en línea convencionales, por ejemplo, la compra de bienes y/o servicios a través de una red, son vulnerables a violaciones que dan como resultado la pérdida de información personal, financiera y/o otra información confidencial. Además, en una red no confiable (por ejemplo la Internet), tanto los comerciantes como compradores están en riesgo de ingresar en una transacción con un actor de mala intención, de modo que una parte del negocio no se puede mantener. Los modelos de transacción en línea convencionales también pueden requerir que un comerciante archive la información confidencial del comprador y puede requerir que manejen aspectos de pago de la transacción. Además, los modelos de transacción en línea convencionales son incómodos para el comprador y producen una experiencia de transacción generalmente no intuitiva. Por ejemplo, las transacciones en línea convencionales se llevan a cabo a través de un buscador utilizando un paradigma de registro/contraseña que es confuso y difícil de manejar. El solicitante ha identificado y apreciado que el delegar parte de las responsabilidades de transacción manejadas por el comprador y buscador en modelos convencionales a un sistema de menor nivel (y fuera del buscador y usuario final) puede facilitar una estructura de transacciones comerciales en línea más simples y más seguras. Por ejemplo, se pueden manejar una o más tareas de transacción a través del sistema de operación en uno o en ambos del usuario final y comerciante, en donde la información puede guardarse en forma más segura. Al incrustar una o más tareas en el sistema de operación, los usuarios pueden liberarse de parte de la carga de transferir información de transacción, hacer más intuitiva la experiencia y aumentar la seguridad. Además, el comerciante puede ser liberado de mantener información del comprador, manejar la información de pago y/o procesar la transacción. El solicitante ha apreciado además que los problemas asociados con la validación de la identidad de un comprador, pueden ser eliminados explotando tecnologías más seguras y convenientes que el modelo de registro/contraseña. En una modalidad, la información de identidad con respecto a un comprador es proporcionada por una tarjeta de módulo de identidad de suscriptor (SIM), la cual almacena la información de identidad con respecto al usuario final que puede ser emitida en forma programada, creando una experiencia de compra menos confusa y más sencilla. Además, las modalidades aquí proporcionadas son protocolos, métodos, sistemas de cómputo y otros mecanismos configurados para autentificación simple o de nivel múltiple utilizando un aparato SIM en una red de otra forma no confiable y no segura (por ejemplo la Internet). El solicitante ha apreciado además que el proporcionar varios elementos de transacciones comerciales en línea utilizando terceras partes generalmente desinteresadas, eliminan los riesgos implicados tanto para el comprador para el comerciante. En un aspecto de la presente invención, se proporciona un sistema de transacción comercial en donde una primera entidad de red proporciona la verificación de la identidad de un comprador y una diferente entidad de red, proporciona la verificación de la capacidad del usuario para pagar la compra, de modo que un comerciante y un comprador que son extraños entre sí, pueden llevar a cabo una transacción con seguridad relativa. Aún otras modalidades, permite una transacción comercial segura de tres vías entre un comerciante, un consumidor, y un pago, en tal forma que la información de la cuenta de facturación sensible no sea visible para el comerciante y las terceras partes. En dicha modalidad, las fichas de pago se pasan a través del consumidor entre el comerciante y el proveedor de pago. Dichas fichas de pago se encríptan o señalan de tal forma que el comerciante y otros no controlen u obtengan información de la cuenta sensible alguna del consumidor. Sin embargo, el comerciante aún puede validar de manera confidencial la señal de pago que indica la capacidad del consumidor para pagar los servicios y/o bienes proporcionados. En otra modalidad, se utiliza información de facturación electrónica para autorizar al pago, auditoria y otros propósitos. En esta modalidad, varias entidades de red (por ejemplo, el consumidor, comerciante, proveedor de pagos, etc.) se abastecen con una factura electrónica legible en máquina, la cual se utiliza para solicitar y validar el pago en forma automática, crear un historial de transacción, presentar una descripción más precisa del pago de los bienes/servicios y para otros propósitos en una transacción comercial en línea. Esta información de facturación también se puede utilizar para pagos a la federación de un solo pago de un consumidor a varios socios del negocio del comerciante. Por ejemplo, el comerciante puede tener una relación contractual con varios socios del negocio que proporcionan servicios y/o bienes en la transacción comercial. La información de facturación puede incluir las partes de pagos que serán distribuidas entre los diversos socios, de modo que la federación del pago pueda ocurrir automáticamente sin la necesidad de interacción del usuario o mecanismos separados de auditoria y pago. También se proporcionan en la presente invención mecanismos para decisiones automáticas de una transacción comercial utilizando reglas o descripciones definidas por cualquier número de entidades de red, incluyendo el consumidor, el comerciante, el proveedor de pago, etc. Por ejemplo, las opciones de pago aceptadas por el comerciante pueden compararse con opciones de pago disponibles para' el consumidor. Con base en dicha comparación, el consumidor se le puede presentar únicamente las opciones que coincidan. Como alternativa, la opción de pago puede ser elegida automáticamente con base en dicha comparación y/o con base en reglas o descripciones adicionales. Por ejemplo, el consumidor puede limitar el tipo de pagos con base en una confianza establecida con el comerciante. Por ejemplo, pueden haber muchos otros tipos de reglas y/o restricciones que determinen que pueden ocurrir varias acciones en la transacción comercial. Las características y ventajas adicionales de la presente invención serán establecidas en la descripción que se encuentra a continuación, y serán obvias en parte a partir de la presente descripción, o pueden ser aprendidas a través de la práctica de la misma. Las características y ventajas de la presente invención pueden ser realizadas y obtenidas por medio de los instrumentos y combinaciones señalados de manera particular en las reivindicaciones adjuntas. Estas y otras características de la presente invención serán más fácilmente apreciadas a partir de la descripción que se encuentra más adelante y las reivindicaciones adjuntas, o puede ser aprendida a través de la práctica de la misma, tal como se establece más adelante. Breve Descripción de los Dibujos Con el objeto de describir la forma en la cual se pueden obtener las ventajas y características de la presente invención antes mencionadas, una descripción más particular de · la presente invención descrita en forma breve anteriormente, se convertirá mediante la referencia a modalidades específicas de la misma, las cuales se ilustran en los dibujos adjuntos. La comprensión de que estos dibujos ilustran únicamente modalidades típicas de la presente invención, y por consiguiente no serán consideradas como limitante de su alcance, la presente invención será descrita y explicada con especificidad y detalles adicionales a través del uso de los dibujos adjuntos en los cuales: La figura 1, ilustra un diagrama de bloque de un sistema de cómputo en red para llevar a cabo transacciones en línea, de acuerdo con una modalidad de la presente invención; La figura 2, ilustra un diagrama de un sistema y método para iniciar y llevar a cabo verificación de identidad en una transacción en línea, de acuerdo con una modalidad de la presente invención; La figura 3, ilustra un diagrama de un sistema y método para llevar a cabo negociaciones de pago, verificación y/o certificación en una transacción en línea, de acuerdo con una modalidad de la presente invención; La figura 4, ¡lustra un sistema de cómputo en red para llevar a cabo transacciones en línea, en donde las transacciones son manejadas, al menos en parte, mediante un software de transacción instalado en computadoras conectadas a la red, de acuerdo con una modalidad de la presente invención ; La figura 5, ilustra un sistema de cómputo en red para llevar a cabo transacciones en línea, en donde las transacciones son manejadas, al menos en parte, por un software de transacción instalado en computadoras conectadas a la red, de acuerdo con una modalidad de la presente invención; La figura 6, ilustra un sistema de cómputo en red para llevar a cabo la generación de licencias para aplicaciones instaladas en una computadora del usuario final, en donde la licencia se obtiene a través de una transacción en línea, de acuerdo con una modalidad de la presente invención; La figura 7A, ilustra un sistema utilizado para autentificar un módulo móvil de una red para establecer una comunicación segura entre ellos de acuerdo con modalidades de ejemplo; La figura 7B, ilustra un sistema utilizado para autentificar un usuario de una red utilizando un módulo móvil cuando se establece un canal de comunicación segura de acuerdo con modalidades de ejemplo; La figura 7C, ilustra un sistema configurado para verificación simple o de nivel múltiple de varios diferentes servicios utilizando un módulo móvil de acuerdo con modalidades de ejemplo; La figura 8, ilustra un intercambio seguro de tres vías de información de pago y federación de pago de acuerdo con modalidades de ejemplo; La figura 9, ilustra varios usos de un subsistema de transacción comercial y presentación de factura de acuerdo con modalidades de ejemplo; La figura 10, ilustra el uso de opciones de pago y reglas para determinar que tipo de proveedor de pago debe ser utilizado para una transacción comercial de acuerdo con modalidades de ejemplo; La figura 11, ilustra un aparato de módulo de identidad de suscriptor (SIM) configurado con un Sistema Firewall (sistema diseñado para prevenir el acceso ¡legal a/o desde una red privada conectada a Internet) para adaptarse a los protocolos de comunicación de red de radio establecida cuando se utilizan para transacciones comerciales de acuerdo con modalidades de ejemplo. Descripción Detallada de la Invención Los modelos convencionales para transacciones comerciales en red, se enfocan en el buscador como la interfase para requerir y presentar información personal y financiera entre un comprador, usuario final, y un comerciante o proveedor de servicios, ya sea directamente a través del comerciante o a través de un proveedor de transacción de tercera parte. En el primer caso, el comerciante está cargado con la creación y mantenimiento de una infraestructura con la capacidad de solicitar, obtener, manejar y procesar información personal y financiera, normalmente con un mínimo nivel de seguridad. Además, el comerciante puede ser responsable de mantener cuentas e información de cuentas de cada uno de sus clientes (lo cual normalmente incluye información confidencial tanto personal como financiera). Un comprador debe dejar información personal (por ejemplo, nombre, dirección, número de teléfono, etc.) e información financiera (por ejemplo, números de tarjeta de débito y crédito y fechas de expiración, números de cuenta de banco, etc.) para completar una transacción. En cierto nivel, el comprador debe confiar en que el comerciante es un agente honesto y que operará de buena fe, utilizando la información únicamente tal como se autoriza. De igual manera, un comerciante debe confiar en que el comprador es quien representa y que la información de pago proporcionada está asociada de manera real con la elaboración de compra del usuario final. No hay una forma segura para que un comerciante valide la identidad del comprador y/o la validez de la información de pago. En un ambiente de red distribuida, los compradores pueden tener que confiar en la reputación del comerciante, lo cual puede limitar las fuentes de las cuales el comprador esta deseando llevar a cabo las transacciones. El comerciante puede tener que operar incluso con menos convicción de que el comprador es un comprador de buena fe y de fiar. En una red no confiable, este modelo puede presentar riesgos indebidos en una o ambas partes. Incluso cuando se ha desarrollado una confianza establecida y ameritada entre un comprador y un comerciante, las bases de datos que almacenan información de clientes mantenidas por el comerciante pueden ser susceptibles a situaciones fraudulentas, robo de información e incluso a actores de mala fe dentro de un negocio de otra manera honesto y confiable. Los proveedores de transacción de tercera parte también son susceptibles a robo electrónico, violaciones de seguridad, etc. Los programas "spy-ware" más sofisticados permiten que personas fraudulentas registren teclazos y obtengan capturas de pantallas de computadoras que han sido comprometidas, haciendo a las transacciones a base de buscador particularmente vulnerables a robo electrónico. Por consiguiente, los compradores que llevan a cabo transacciones comerciales en línea de acuerdo con los métodos y modelos convencionales pueden ser vulnerables a diseminación y uso no autorizado de su información personal y financiera confidencial. Los modelos de transacción comercial convencionales normalmente requieren un comprador para establecer una cuenta con cada comerciante con el cual el comprador desea llevar a cabo una transacción comercial. Generalmente, la cuenta está protegida y es accesada por un nombre y contraseña de registro, requiriendo que un comprador maneje múltiples registros y contraseñas y mantenga la combinación de registro/contraseña que corresponda a cada cuenta. Algunos clientes pueden recurrir a almacenar sus combinaciones de registro/contraseña localmente en su computadora o utilizar la misma combinación de registro/contraseña para todas las cuentas. Ambos intentos de manejar múltiples cuentas son vulnerables a robo, fraude y/o otras violaciones de seguridad. Por ejemplo, un cliente está en riesgo de tener todas sus cuentas violadas si la combinación simple de registro/contraseña es obtenida por un robo electrónico. Además de los riesgos de seguridad inherentes asociados con los paradigmas de registro/contraseña convencionales, los compradores pueden encontrar que el procedimiento de registro de la cuenta es una experiencia de transacción molesta. En particular, el tener que registrar una cuenta cuando se desea realizar una compra, hace a la transacción menos conveniente, ya que un comprador debe, de una forma u otra, producir esta información antes de que se pueda completar la transacción. Además, con los proveedores de transacción de tercera parte, el comprador es redirigido desde un sitio web del comerciante hasta el sitio web del proveedor de transacción de tercera parte. Este paso no es intuitivo, y además, es inconveniente y confuso para el comprador. El solicitante ha identificado y apreciado que el delegar al menos parte de las responsabilidades de transacción manejadas por el comprador y buscador en los modelos convencionales a sistemas de nivel inferior (y fuera de buscador y usuario final) puede facilitar una estructura de transacciones comerciales en línea más simple y más segura. En una modalidad, una o más tareas de transacción son manejadas por el sistema de operación (o algún otro subsistema confiable) en uno o ambos del usuario final y el comerciante, en donde la información puede ser guardada de manera más segura. Al incrustar una o más tareas en el sistema de operación, los usuarios pueden ser liberados de parte de la carga de transferir la información de transacción, haciendo más intuitiva la experiencia y aumentando la seguridad. Además, el comerciante puede ser liberado de mantener la información del comprador, manejar la información de pago y/o procesar la transacción. El solicitante ha apreciado además que los problemas asociados con la validación de la identidad del usuario pueden ser eliminados explotando tecnologías más seguras y convenientes que el modelo de registro/contraseña. En una modalidad, la información de identidad con respecto al comprador es proporcionada por una tarjeta de módulo de identidad de suscriptor (SIM) que almacena la información de identidad con respecto al usuario final que puede ser emitida en forma programada. En otra modalidad, la información de identificación es proporcionada por una tarjeta inteligente incrustada o acoplada de otra forma a un aparato del cual un comprador lleva a cabo una transacción comercial en línea.- El uso de cualesquiera de los diversos medios de identidad a base de chip o tarjeta permite a un comprador enlazar su identidad con un aparato en particular, tal como un teléfono celular o una computadora en red. El término "en forma programada" y/o "en forma automática" se refiere a acciones llevadas a cabo substancialmente sin una implicación manual o de un operador. En particular, programada o automática se refiere a acciones iniciadas y/o llevadas a cabo por uno o más programas de computadora. Por ejemplo, el proporcionar información de identificación solicitando a un usuario (por ejemplo comprador) proporciona la información de registro y/o contraseña puede no considerarse programada, ya que la substancia de la acción es llevada a cabo por el usuario. Sin embargo, una acción en donde un programa emite información de identificación (por ejemplo un número SIM, ID del hardware de dirección de red, etc.) sin requerir que el usuario ingrese la información, puede considerarse programada. Se debe observar que dichas operaciones automáticas pueden implementarse ya sea mediante componentes de software o hardware. El solicitante ha apreciado además que la distribución de varios elementos de transacción en transacciones comerciales en línea a través de diferentes aparatos de red, facilita las transacciones comerciales más seguras a través de una red confiable. En una modalidad, un proveedor de identidad de un proveedor de pago, ambas entidades de red separadas y distintas del usuario final, comerciante y entre sí, proporciona soporte de verificación durante una transacción comercial. El término "entidad de red" se refiere en la presente invención a una presencia de red y puede ser una o una combinación de usuario final/comprador, proveedor de identidad, proveedor de pago, comerciante, etc. Una entidad de red puede tener una presencia en una red a través de uno o múltiples nodos de red. Por ejemplo, los aparato en red múltiples pueden operar bajo el auspicio de una sola entidad de red, tal como un proveedor de identidad que utiliza múltiples servidores para llevar a cabo negocios en línea, o un usuario final conectado a una red a través de un teléfono celular y una computadora personal. Una entidad de red puede ser un negocio tal como un banco o vendedor al menudeo, o un individuo, tal como un usuario final. En una modalidad, varios elementos de una transacción en línea son distribuidos en entidades de red separadas e independientes. Por ejemplo, el proveedor de identidad puede proporcionar validación de identidad en la forma de una señal de identidad, la cual puede utilizar el comerciante para verificar la identidad del comprador. La señal de identidad puede ser emitida con base en la información de identidad proporcionada por el usuario final/comprador, por ejemplo, el número de suscriptor de la tarjeta SIM, dirección de red (por ejemplo, una identificación de Tarjeta de Interfase de Red (NIC), Nombre a Nivel Mundial (WWN), etc.) información de registro, etc. En forma similar, el proveedor de pago puede proporcionar verificación de la capacidad del usuario final para pagar en la forma de una señal de pago. Además, el proveedor de pago puede manejar transacciones de pago a nombre del comprador en satisfacción del comprador de los bienes y/o servicios del comerciante. La estructura antes mencionada permite, entre otras cosas, a un comprador y comerciante que son extraños llevar a cabo una transacción comercial en línea en un ambiente de red confiable con una confiabilidad relativa, tal como se describe con mayor detalle en las diversas modalidades de ejemplo que se proporcionan más adelante. Por ejemplo, una modalidad proporciona una comunicación segura de tres vías entre un comerciante, consumidor y proveedor de pago durante una transacción comercial para comprar servicios y/o bienes ya sea en un ambiente en línea o de venta al menudeo. Tal como se describirá con mayor detalle más adelante, las fichas de pago son pasadas del proveedor de pago al comerciante a través del consumidor. Dichas fichas de pago ofrecen una prueba de la capacidad del consumidor para pagar el servicio y/o bienes, permitiendo al comerciante validar la autenticidad de la señal directamente con el proveedor de pago. Aunque dichas fichas de pago identifican únicamente la autorización del pago de los servicios y/o bienes, la información sensible con respecto a la cuenta de facturación del consumidor ya sea no está incluida dentro de la señal o está encriptada de otra forma para ser invisible para el comerciante. Por consiguiente, la información sensible del consumidor no es visible para el comerciante, permitiendo de esta forma el consumidor comprar artículos del comerciante de manera confidencial, incluso cuando no exista una relación de confianza entre ellos. Además, debido a que el comerciante puede validar la señal de pago directamente con el proveedor de pago, el comerciante puede suministrar los artículos con la confianza de la capacidad que tiene el consumidor para pagar dichos servicios y/o bienes sin mantener información financiera con respecto al consumidor (por ejemplo, números de tarjeta'de crédito, información de cuenta, etc.). Además, debido a que el proveedor de pago puede validar la autenticidad de la señal de pago tal como viene del consumidor, el proveedor de pago puede transferir de manera confidencial los fondos al comerciante; completando de esta forma la transacción comercial segura de tres vías. Tal como se mencionó anteriormente, otras modalidades de la estructura proporcionadas en la presente invención mueve partes de la transacción a subsistemas más seguros de un aparato de cómputo (por ejemplo el sistema de operación). Esto permite convenientemente numerosas capacidades incluyendo: un modelo de abstracción para permitir aplicaciones de legalidad proporcionadas en la experiencia de transacción comercial en línea, en banda; tipos adicionales de protección contra fraudes; captura y presentación de facturas para auditoria, la federación de pagos y otros propósitos de pago o autentificación; ejecución de códigos del proveedor de servicios para seguridad adicional y funcionalidad específica al comerciante; autentificación de nivel múltiple y otras características. Por ejemplo, dicha modelo de abstracción permite que la legalidad y otras aplicaciones abastezcan a un usuario con capacidades de compra y pago en línea como si dicha transacción ocurriera directamente dentro de la aplicación, aunque partes de la transacción comercial se llevan a cabo fuera de banda. Los ejemplos incluyen compra por catálogo (por ejemplo Amazon, Sears, etc.) compra directa de contenido multimedia desde dentro de la aplicación multimedia, descarga de software, juegos en un modo de prueba y la eliminación del seguro automática de ellos a través de un modelo de pago en banda, permitir el pago por servicios a base de suscripción, tal como servicios de mensajes simples a través de correo electrónico, etc. Además, en otra modalidad, la estructura captura y presenta facturas electrónicas en las transacciones comerciales seguras de tres vías anteriores (y otras) como un mecanismo para autentificación, auditoria, federación de pago y otros propósitos adicionales que serán descritos con mayor detalle más adelante. Además, al mover la transacción comercial a partes más seguras de subsistema, otras modalidades permiten a un comerciante correr un código específico en una máquina (por ejemplo autentificación del usuario adicional, reglas/mecanismos de pago, experiencia del usuario, etc.) con confianza de que el código no será un asunto de fraude o se vea comprometido de otra forma. Por supuesto, tal como se describe con mayor detalle más adelante, el solicitante ha considerado además otras características convenientes a través del uso del modelo de abstracción aquí proporcionado. En otra modalidad, el solicitante también proporciona un sistema y protocolo general que utiliza un módulo móvil para comunicación y autentificación segura de las capacidades de identidad y pago para una variedad de diferentes servicios. Por ejemplo, se puede utilizar un módulo de identidad de suscriptor (SIM) (u otro módulo móvil similar) para autentificar a un usuario y/o aparato para un servicio o servidor en un ambiente de validación de nivel múltiple. En dicha modalidad, el módulo móvil (y posiblemente, incluso el usuario) es autentificado en una red independiente de la infraestructura móvil de la red del módulo móvil. Por lo tanto, el sistema valida la posesión de un módulo móvil a través de la autentificación de una cuenta de facturación activa con la infraestructura móvil. Esto establece una comunicación segura con un aparato de cómputo conectado a un módulo móvil y un servicio (por ejemplo un Web Services (WS)) utilizando los protocolos seguros existentes (por ejemplo autentificación-WS, seguridad-WS, y otros protocolos similares). Dicha comunicación segura también puede ser utilizada para autentificar al usuario a través de otros protocolos e intercambios de datos entre el módulo móvil y la infraestructura móvil-tal como se describe con mayor detalle más adelante. Además, otras modalidades proporcionan un protocolo y máquinas de estado que abstraen el aparato de cómputo (utilizado en la comunicación a través de la red independiente) de la infraestructura móvil. Por consiguiente, el propio módulo móvil se vuelve una terminal móvil y el aparato de cómputo se vuelve un aparato periférico, cumpliendo de esta forma con los estándares inalámbricos corrientes, tal como 3 GPP (Proyecto de Partes de Tercera Generación). La figura, ilustra un diagrama de bloque de un sistema de transacción comercial 100 que comprende una pluralidad de nodos de red que incluyen una computadora de usuario final (comprador) 110, un computadora de comerciante 140, una computadora de proveedor de identidad 120 y una computadora del proveedor de pago 130. Cada uno de los nodos anteriores puede incluir uno o más aparatos de cómputo interconectados a través de la red 105. Se deberá apreciar que la computadora del usuario final, el comerciante 140, el proveedor de identidad 120 y el proveedor de pago 130 pueden estar asociadas con una entidad de red, tal como un individuo, compañía o negocio. Por ejemplo, la computadora de un usuario final 110 normalmente está asociada con un individuo que emplea la computadora para accesar a recursos en la red y una computadora de comerciante 140 puede estar asociada con una corporación o negocio que ofrece bienes y/o servicios para venta. El uno o más aparatos de cómputo que forman cada componente mencionado en un sistema de transacción comercial 100, puede operar como el punto de entrada, plataforma y/o vehículo de cómputo mediante el cual las entidades de red asociadas se comunica a través de la red. Se debe observar que aunque las modalidades aquí proporcionadas se pueden describir en un ambiente de compra en línea, las modalidades también se pueden utilizar en una transacción de venta al menudeo directa. Por ejemplo, la descripción anterior y la que se encuentra más adelante de una transacción comercial, pueden aplicar a consumidores que compran productos en una tienda al menudeo, en donde se utilizan las modalidades de pago, identidad, autorización y otras. Por consiguiente, el uso de una experiencia en línea para describir modalidades en la presente invención, es únicamente con propósitos de ilustración y no pretende limitar o disminuir de otra forma el alcance de la modalidad a menos que se reivindique explícitamente de otra manera. Asimismo, se debe observar que la red 105 puede ser cualquier tipo de red en cualquier tipo de configuración que interconecte y permita que los nodos conectados a la red se comuniquen. Los nodos o aparatos pueden ser conectados a una red a través de un cable de cobre (por ejemplo categoría 5) conexiones ópticas, inalámbricas o cualquier combinación de las mismas. La información puede ser transferida utilizando cualquier protocolo de bajo nivel tal como Ethernet y/o cualquier protocolo de información tal como TCP/IP. La red 105 puede tener cualquier número de aparatos conectados a éste y puede ser confiable (por ejemplo intranet) o una red no confiable (por ejemplo LAN/WAN, Internet, etc.) o una combinación de ambas. Las computadoras conectadas a la red pueden ser cualquier tipo de aparato incluyendo, pero sin limitarse a, una o cualquier combinación de un teléfono móvil, una computadora de escritorio, una computadora personal de tableta, un servidor, una estación de trabajo, etc. La figura 2, ilustra un diagrama de un sistema y método para iniciar y llevar a cabo verificación de identidad en una transacción en línea, de acuerdo con una modalidad de la presente invención, y la figura 3 ¡lustra un diagrama de un sistema y método para llevar a cabo negociación, verificación y/o certificación de pago en una transacción en línea, de acuerdo con una modalidad de la presente invención. Los métodos se pueden utilizar por separado o en combinación para llevar a cabo una transacción en línea entre un usuario final/comprador y un comerciante. En la siguiente descripción, a menos que se señale específicamente lo contrario, no existe distinción entre la entidad de red y sus aparato en red asociados. Por ejemplo, el "proveedor de identidad" se utiliza en forma genérica para describir el proveedor de identidad como una entidad (por ejemplo un banco, organización de gobierno, agencia, etc.) y tal como los aparatos de cómputo que la entidad utiliza para llevar a cabo varias funciones de red, tal como proporcionar verificación de identidad de un usuario final, u otra operación a nombre de la entidad. Una computadora del usuario final 110, puede colocar una orden 242 con un comerciante 140. La orden 242 puede ser cualquier indicación de que el usuario final puede desear comprar uno o más bienes y/o servicios del comerciante 140. Por ejemplo, la orden 242 puede resultar de que el usuario final seleccione un bien o servicio a través de un buscador web que despliega páginas residentes en el sitio web de un comerciante, o puede resultar de la elección de una opción de una aplicación que corre localmente, tal como se describe con mayor detalle más adelante. Como un ejemplo del primer caso, el comerciante 140 puede proporcionar un sitio web para desplegar u ofrecer de otra forma bienes y/o servicios de venta que proporciona, o puede proporcionar un catálogo en línea de la mercancía. La orden 242 puede ser cualquier tipo de indicación de que el usuario final puede comprar uno o más bienes y/o servicios del comerciante 140. Como un ejemplo del segundo caso y una alternativa para seleccionar uno o más bienes y servicios del sitio web del comerciante, la orden 242 puede originarse de una aplicación u otro programa local de la computadora del usuario final 110. Por ejemplo, un usuario final puede crear, producir o editar un documento a través de una aplicación de procesamiento de palabras, diseñar una muestra de diapositivas utilizando una aplicación de presentación y/o manipular imágenes o gráficas un póster o folleto utilizando una aplicación de generación de imagen. La aplicación puede incluir una opción bajo el menú de impresión que permita que el documento sea impreso a través de una tercera parte, por ejemplo, para tener la ventaja de imprimir las características que pueden no estar disponibles localmente, o explotar de otra forma los servicios de impresión profesionales. Cuando la opción es seleccionada, la aplicación puede enviar, a través de la red, la orden 242 al comerciante 140. Se deberá apreciar que la orden 242 puede ser cualquier indicación para comprar cualquier bien y/o servicio, ya que los aspectos de la presente invención no se limitan a este respecto.
En respuesta a la orden 242, el comerciante 140 puéde requerir que el usuario final 110 proporcione una indicación de la identidad y/o verificación del usuario final, de que el usuario final es de hecho quien dice ser (paso 205). Por ejemplo, el comerciante 140 puede no conocer nada con respecto a la fuente de la orden 242 y puede desear información con respecto a la identidad del usuario final y/o asegurarse que el usuario final no esté falsificando su identidad. Como alternativa, el comerciante 140 puede enviar una noticia o indicación de que se requiere el pago para el servicio y demandar que se proporcione una señal de pago. Para obtener una señal de pago, puede ser necesario establecer primero una identidad a través de una señal de identidad, tal como se describe con mayo detalle más adelante. En cualquier caso, el usuario final 110 puede responder a la solicitud a través del comerciante 140, enlistando los servicios del proveedor de identidad 120 (paso 215). Para obtener una señal de identidad, el usuario final 140 proporciona información de identidad al proveedor de identidad 120. La información de identidad puede incluir cualquier información que permita al proveedor de identidad 120 distinguir entre el usuario final que utiliza la computadora del usuario final 110 y los otros diversos usuarios finales a los cuales pueden proporcionar servicios el proveedor de identidad. Por ejemplo, la información de identidad puede incluir un identif icador único asociado con el hardware de la computadora del usuario final 110. En una modalidad, la información de identidad se proporciona a través de una tarjeta SIM que emite un identif icador único para el suscriptor. La información de identidad puede incluir proporcionar un número de hardware único de la tarjeta de interfase de red (NIC) de la computadora del usuario final 110, un nombre a nivel mundial (WWN) u otra dirección de red de la computadora del usuario final 110 o cualquier otro medio a través del cual se puede identificar la computadora del usuario final 110, incluyendo (en algunas modalidades), una combinación de nombre/contraseña de registro establecida. El proveedor de identidad 120 utiliza la información · de "identidad para localizar las credenciales de identidad asociadas con el usuario final. Por ejemplo, el proveedor de identidad 120 puede incluir una base de datos que almacena la información de identidad y credenciales en una pluralidad de usuarios finales. La información de identidad se puede utilizar para ¡ndexarse en la base de datos para obtener las credenciales de identidad correctas. El proveedor de identidad 120 puede ser cualquier tipo de entidad. Por ejemplo, el proveedor de identidad 120 puede ser una compañía de teléfono móvil que utiliza el número del suscriptor proporcionado por la tarjeta SIM del usuario final para localizar la información de identificación adecuada. En una modalidad el número de suscriptor es utilizado para localizar y obtener información proporcionada por el usuario final al momento de la suscripción al teléfono celular u otro aparato que explote tecnología SIM. El proveedor de identidad 120 puede ser un banco, una agencia gubernamental (tal como el registro de vehículos motorizados (RMV)), o cualquier otra instalación que mantenga información o credenciales de identificación asociadas con usuarios finales. En respuesta a la información de identidad proporcionada por el usuario final, el proveedor de identidad 120 proporciona una señal de identidad a la computadora del usuario final 110 que proporciona autentificación y/o credenciales de identidad con respecto al usuario final (paso 225). La señal de identidad puede ser cualquier tipo de mensaje electrónico que otro aparato de red pueda utilizar para autentificar, verificar y/o determinar la identidad de un usuario final. Por ejemplo, la señal de identidad puede incluir credenciales de identidad del usuario final. Las credenciales de identidad pueden incluir, pero no se limitan a cualquiera de una combinación de nombre, fecha de nacimiento, dirección, número de teléfono, dirección de correo electrónico, etc. La señal de identidad puede incluir una asignatura electrónica del proveedor de identidad 120 que certifica que las credenciales de identidad son correctas. En esta forma, un comerciante y/o proveedor de pago puede depender de una tercera parte desinteresada (por ejemplo un proveedor de identidad) en lugar de las representaciones de un usuario final arbitrario. La señal de identidad puede ser encriptada antes de ser transmitida a través de la red, y desencriptada cuando sea recibida por el aparato de red deseado (por ejemplo comerciante, proveedor de pago, etc., tal como se describe con mayor detalle más adelante) para proteger contra alguien que escuche a escondidas en la red. En otras modalidades, la señal de pago es meramente una certificación de la identidad del usuario final que no acompaña la información de identidad.
El proveedor de identidad 120 puede transmitir la señal de identidad a una computadora de usuario final 110 para dirigir al comerciante 140 (paso 234) y/o proveedor de identidad 120 pueda transmitir la señal de identidad directamente al comerciante 140. El comerciante 140 posteriormente procesa la señal de identidad para identificar el usuario final y/o verificar que el usuario final es quien dice ser. La señal de identidad puede ser utilizada para autentificar cierta información con respecto al usuario final que pueda afectar la transacción. Por ejemplo, el comerciante 140 puede proporcionar un servicio que requiera que el usuario final tenga cierta edad. Las credenciales de identidad transmitidas con la señal de identidad pueden ser utilizadas para asegurar que el usuario final tenga la edad adecuada y cumpla con este requerimiento. El comerciante 140 puede tener descuentos de usuarios finales particulares que son compradores frecuentes, o que han recibido un cupón, oferta promocional, etc. El comerciante 140 puede indexar una base de datos de usuarios finales para determinar si el usuario final califica, o debe ser manejado de manera especial con base en las credenciales de identidad proporcionadas. Opcionalmente, el comerciante 140 puede requerir la validación de la señal de identidad, enviando una solicitud al proveedor de identidad 120 (paso 245). La solicitud de validación de la señal de identidad puede incluir enviar la señal de identidad del comerciante 120 al proveedor de identidad 120. Al momento de recibir la solicitud de validación de la señal de identidad, el proveedor de identidad 120 puede validar la señal de identidad, y determinar de esta forma si es auténtica la señal de identidad. El proveedor de identidad 120 posteriormente puede enviar una indicación de la validez de la señal de identidad al comerciante 140 (paso 255). Como alternativa, el comerciante 140 puede simplemente validar la propia señal de identidad (paso 265) (por ejemplo asumiendo que la señal de identidad es válida o procesar de otra manera la señal). Opcionalmente, se puede regresar una respuesta del comerciante 140 a la computadora del usuario final 110, en donde la respuesta puede incluir un mensaje de si la señal de identidad es válida, de cualquier descuento u ofertas promocionales aplicables, y/o cualquier otro tipo de mensaje, ya que la presente invención no se limita a este aspecto (paso 265). Después de que el comerciante 140 ha procesado la señal de identidad y/o ha recibido una validación para la señal de identidad del proveedor de identidad 120, el comerciante 140 puede solicitar que el usuario final proporcione verificación o validación de la capacidad de pago y/o proporcionar una indicación de cómo el usuario final podría pagar por los bienes o servicios. El comerciante 140 puede hacer la solicitud a través de una solicitud de señal de pago (paso 305 de la figura 3). En respuesta a la solicitud de señal de pago, la computadora del usuario final 110 puede hacer una lista de los servicios de un proveedor de pago 130. El proveedor de pago, 130 puede estar asociado con una tercera parte que mantiene información financiera y de pago con respecto a varios usuarios finales, tal como una institución financiera, o un agente de tercera parte que maneja transacciones financieras y procedimientos de pago. La computadora del usuario final 110 puede solicitar una señal de pago de un proveedor de pago 130 (paso 315) transmitiendo la señal de identidad al proveedor de pago 130. Como alternativa, el usuario final puede solicitar una señal de pago, registrándose en el proveedor de pago 130 en una forma similar a la descrita en relación con el proveedor de identidad 120 (por ejemplo proporcionando un identificador tal como un número de suscriptor SIM, dirección NIC y/o utilizando una combinación de registro/contraseña). Se debe apreciar que el usuario final puede solicitar una señal de pago en otras formas, ya que la presente invención no se limita a este aspecto. Además, el usuario final puede enviar información con respecto a la compra, tal como el precio y naturaleza de la compra, de modo que el proveedor de pago pueda verificar que el usuario final tiene la capacidad de pagar. Sin embargo, no se requiere proporcionar información de compra, ya que puede no ser necesario o puede ser manejada en pasos subsecuentes de la transacción. El proveedor de pago 130 procesa la señal de identidad (u otro identificador proporcionado) para localizar información con respecto al usuario final. Por ejemplo, el proveedor de pago 130 puede accesar una base de datos de información de pago con base en las credenciales de identidad transmitidas con la señal de identidad. El proveedor de pago 130 puede determinar que capacidades y opciones tiene disponibles el usuario final identificado. El proveedor de pago 130 posteriormente puede verificar que el usuario final tiene la capacidad de pagar, y en respuesta, generar y transmitir una señal de pago a la computadora del usuario final 110 (paso 325). La señal de pago puede indicar la capacidad que tiene el usuario final para pagar y/o una certificación de que el proveedor de pago 130 está dispuesto a manejar la transacción a nombre del usuario final. La computadora del usuario final 110 posteriormente puede enviar la señal de pago al comerciante 140 (paso 335). El comerciante 140 procesa la señal de pago de modo que el comerciante 140 quede satisfecho de que el usuario final tiene la capacidad de pagar por los bienes o servicios (paso 365). Por ejemplo, el comerciante 140 puede solicitar al proveedor de pago 130 validar la señal de pago (pasos 345, 355) o puede validarlas simplemente por sí mismo (paso 365) (por ejemplo, asumiendo que la señal de pago es válida o procesar de otra forma la señal). El comerciante 140 posteriormente puede comenzar el proceso de proporcionar los bienes y/o servicios al usuario final. Debido a que el proveedor de pago 130 puede ser una tercera parte desinteresada, el comerciante 140 puede tratar la señal de pago esencialmente como un pago y puede no tener que esperar hasta que la transacción sea completamente procesada. Cuando un comerciante trata directamente con el usuario final en modelos de transacción convencionales, el comerciante puede tener que asegurar que la información de pago proporcionada por el usuario final es correcta y suficiente. Por ejemplo, un comerciante puede tener que correr un número de tarjeta de crédito proporcionada a través del sistema de tarjeta de crédito para verificar si el número es válido, la tarjeta es válida, y existen suficientes fondos y/o la tarjeta está asociada en forma correcta con la identidad proporcionada por el usuario final. Si algo de esto no coincide, la transacción puede tener que ser cancelada, terminada o abandonada. Además, la terminación de la transacción puede ocurrir después de que el usuario final perciba que la transacción está completa y ya no accesar a la red y/o ya no accesar al sitio web del comerciante, etc. El comerciante posteriormente puede tener que notificar al usuario final que hubo un problema con la transacción, y el usuario final tendrá que pasar nuevamente por la transacción para corregir el problema (por ejemplo, ingresando correctamente la información de pago, especificando una tarjeta diferente con suficientes fondos, etc.). En algunos casos, el usuario final puede no ser notificado y la transacción comercial puede no completarse nunca. En varias modalidades aquí descritas, debido a que la señal de pago no será emitida a menos que la información de pago del usuario final sea correcta, están disponibles suficientes fondos, y/o el proveedor de pago certifica de otra forma que pagará a nombre del usuario final, el comerciante puede proceder inmediatamente con la transacción. Cualesquiera deficiencias en la transacción pueden ser identificadas en tiempo real y atenderse de modo que todas las partes puedan tener una relativa seguridad de que existen expectativas para ser cumplidas con respecto al término de la transacción. Además, debido a que el proveedor de pago puede manejar la transacción financiera (por ejemplo manejar la tarjeta de crédito, transferencia de fondos, etc.) el comerciante puede ser liberado del establecimiento y mantenimiento de la infraestructura necesaria, por ejemplo, para procesar números de tarjeta de crédito o manejar de otra forma procedimientos' de pago y transferencia de fondos. La señal de pago, en algunos casos, opera como un seguro de que el proveedor de pago transmitirá los fondos designados, por ejemplo, cableando el dinero o estableciendo una transferencia electrónica de los fondos al comerciante. La señal de pago también puede ser una seguridad de que el pago será realizado mediante medios no electrónicos, tal como una promesa de emisión al comerciante de un cheque u otro instrumento negociable. Desde la perspectiva del comerciante, la transacción comercial es sustancialmente libre de riesgo, ya que la identidad del usuario final y la verificación de pagos son manejadas por terceras partes y por consiguiente es menos susceptible a fraude, falsificación e incluso errores inocentes al proporcionar la información personal y financiera. Por consiguiente, los comerciantes pueden estar más dispuestos a llevar a cabo transacciones comerciales en línea con usuarios finales no conocidos a través de una red no confiable. Desde la perspectiva del usuario final, la información personal y financiera reside con entidades ya sea, que ya tiene la información y/o que el usuario final tiene una relación establecida con ellos. No se necesita proporcionar al comerciante la información del usuario final personal y financiera confidencial, mitigando las vulnerabilidades que tiene la información confidencial mal utilizada o no adecuada. Como resultado, los usuarios finales pueden estar más dispuestos a llevar a cabo transacciones comerciales con comerciantes no conocidos sin tener que preocuparse de si el comerciante es confiable o no. En algunos modelos de transacción convencionales, la información de identidad e información de pagos son ingresados por el usuario y procesados ya sea por una tercera parte o el comerciante. Tal como se describió anteriormente, estos modelos son molestos, ineficientes y tardados para el usuario. Además, los modelos convencionales presentan numerosos aspectos con respecto a seguridad de la información confidencial de un usuario final, así como hacen vulnerable a fraude al comerciante y/o susceptible a fallas en el pago por parte del usuario final. El solicitante ha apreciado que el software de transacción comercial instalado en cada una de las computadoras empleado en varias transacciones comerciales, puede mitigar o eliminar aspectos con respecto a seguridad y fraude. Además, muchas de las acciones manejadas por el usuario fina y el comerciante en modelos convencionales pueden llevarse a cabo a través del software de transacciones comerciales, haciendo más simple y más intuitiva la transacción para el usuario final. La figura 8 ilustra un ejemplo del uso de alguna de las características descritas anteriormente para una comunicación segura de tres vías y varios límites de confianza que pueden ser establecidos durante una transacción comercial. Tal como se describirá con mayor detalle más adelante, este modelo permite pagos simples o de suscripción, así como a la federación de pagos de modo que un servicio o comerciante puede agregar pagos para compañías menores; habilitando de esta forma que el cliente pague una factura simple. Tal como se muestra, el sistema distribuido 800 está configurado para facilitar una transacción comercial entre un consumidor 810, comerciante 830 y un proveedor de pago 805. Un límite de confianza de pago 815 divide al comerciante 830 del consumidor 810/proveedor de pago 805, de modo que exista una relación confiable entre el proveedor de pago 805 y el consumidor 810 o el aparato de cómputo del cliente (por ejemplo, el consumidor tiene identificado o autentificado adecuadamente por sí mismo al proveedor de pago utilizando cualesquiera de los mecanismos disponibles aquí descritos. Por consiguiente, el consumidor 810 puede utilizar esta relación confiable para autorizar el pago al comerciante 830 para varios tipos de pagos y varios tipos de servicios. Por ejemplo, se supone que el comerciante 830 requiere un pago de reserva para un producto (por ejemplo, un artículo que requiere un pago previo tipo un coche, una computadora etc.), el cual desea comprar el consumidor 810. Sin embargo, antes de requerir la autorización de pago, el usuario del aparato de cómputo 810 del consumidor puede requerir una autentificación adecuada tal como aquí se describe. Una vez que el usuario se autentifica, el aparato de cómputo del consumidor 810 puede requerir en forma adecuada el pago del proveedor del pago 805 a través de cualesquiera de los diversos mecanismos también aquí descritos. Por ejemplo, el consumidor 810 puede proporcionar al proveedor de pago facturación u otra información requerida que está firmada o encriptada de otra forma a través del sistema de cómputo del consumidor 810. Esto autentifica la solicitud de validación de la capacidad de quien mantiene la cuenta (por ejemplo, el consumidor) de pagar en forma adecuada (por ejemplo, el usuario tiene una cuenta de prepago, cuenta de crédito u otra cuenta de facturación tal como una subscripción móvil tal como se describe más adelante). Si tiene éxito, la ficha de pago se emite y los fondos se reservan posteriormente para garantizar el pago. Dicha ficha de pago normalmente es firmada y/o encriptada de otra forma por el proveedor de pago (por ejemplo, un servidor web móvil tal como aquí se describe) y es pasada al cliente consumidor 810. El consumidor 810 pasa la ficha de pago nuevamente al comerciante 830, el cual verifica la señal contra el proveedor de pago, y si tiene éxito, completa la orden.
Una vez que el artículo está listo para su envío (por ejemplo, ha sido construido), el comerciante 830 puede utilizar la ficha de pago de reserva para solicitar el pago del proveedor de pago 805. Se debe observar que la cantidad de solicitud de pago puede ser diferente a la cantidad reservada. Sin embargo, el proveedor de pago 805 verifica y regresa una respuesta de pago al comerciante 830 y/o consumidor 810. Si aprueba, el comerciante 830 puede enviar (o proporcionar de otra manera) la orden al consumidor 810, y obtener el pago del mismo. Si por otra parte, el pago es rechazado o si se requiere una interacción adicional del usuario, el comerciante 830, el proveedor de pago 805, y/o consumidor 810 pueden elegir que acción tomar. Por ejemplo, si la cantidad solicitada por' el comerciante 830 no coincide con los fondos en reserva, el proveedor de pago 805 y/o comerciante 830 puede solicitar autorización del consumidor 810 para la nueva cuenta. Como alternativa, el proveedor de pago 805 puede requerir la entrada del usuario que autorice la transferencia de fondos si importar cualquier cambio en las cantidades de pago reservadas o solicitadas. Por supuesto, también se contemplan en la presente invención otras acciones y procedimientos para completar la transacción comercial. Se debe observar que aunque el mecanismo de pago seguro de tres vías anterior fue utilizado para comprar un artículo en reserva, el pago simple también puede aplicar a otros servicios y/o bienes. Por ejemplo, el mecanismo de pago simple puede aplicar a un programa de software y está listo para descarga inmediata. Como alternativa, o en conjunto, el pago simple puede abrir varios niveles de programa que fue descargado (por ejemplo, versión de estudiante, versión profesional, u otra funcionalidad separada). De hecho, tal como se apreciará el pago simple anterior puede ser utilizada para una variedad de diferentes tipos de compras, algunas en una forma de pago ligeramente modificada.
Por ejemplo, suponiendo que el consumidor 810 desea establecer una subscripción con un comerciante 830 para un servicio continuo (por ejemplo, una subscripción a un periódico o revista, subscripción a películas, aplicación de juegos u otros vienes y/o servicios de pago conforme se utiliza). Por consiguiente, el comerciante 830 pedirá al consumidor 810 una ficha de pago, y por lo tanto el cliente consumidor 810 puede interactuar con el usuario que solicita la autorización para proceder tal como se describió anteriormente. En forma similar a lo anterior, el consumidor 810 firma o encripta de otra forma la solicitud de pago (por ejemplo, utilizando información de facturación electrónica tal como se describe más adelante) y enviar dicha solicitud al proveedor de pago 805 (por ejemplo, un operador móvil, compañía de tarjeta de crédito, servicio de pre-pago u otro tipo de servicio de tercera parte, etc.). Esto autentifica la solicitud y verifica que quien mantiene la cuenta (por ejemplo, el consumidor o cliente) tiene suficientes fondos de inicio. Si tiene éxito, se emite una ficha de pago, se firma y/o encripta de otra manera, y se regresa al cliente consumidor 810, el cual pasa la ficha de pago de regreso al comerciante de subscripción 830. El comerciante 830 verifica la autentificación de la ficha y completa el establecimiento de la subscripción. Se debe observar que normalmente la ficha de pago se almacena en el comerciante 830 y se utiliza periódicamente cuando se solicita el pago de subscripción procedente del proveedor del pago 805. Por consiguiente cuando se procesa el pago de subscripción, el comerciante 830 recupera la ficha de pago y la envía al proveedor del pago 805 para un contrato de pago. El proveedor del pago 805 verifica y regresa una respuesta de pago al comerciante 830 y/o consumidor 810. Si se regresa una respuesta aprobada, el comerciante de la subscripción 830 recibirá el pago durante la siguiente corrida de pago de la cuenta del proveedor del pago 805. Sin embargo si se rechaza la solicitud de pago, el proveedor del pago 805 y/o comerciante 830 puede responder en forma adecuada. Por ejemplo, el comerciante 830 (o proveedor de pago 805) puede contactar (por ejemplo, vía correo electrónico) al usuario o consumidor 810 que les informa del pago por pagar. El consumidor 810 posteriormente puede llevar a cabo realizar un solo pago tal como se describió anteriormente, o establecer otro pago de subscripción a través ya sea del mismo o un diferente proveedor de pago 805. Por supuesto, el comerciante 830, el proveedor de pago 805, y/o el consumidor 810 puede tener otras reglas o requerimientos para procesar estas, y otras autorizaciones de pago, tal como se describe con mayor detalle más adelante. Tal como se mencionó anteriormente, otras modalidades permiten la federación de un solo pago del consumidor 810 a una pluralidad de socios del negocio o subsidiarios con un acuerdo transaccional. Con frecuencia las relaciones de negocio son complejas y requieren distribuciones por diversos servicios y/o bienes proporcionados dentro de un modelo de negocio particular. Por ejemplo, cuando se compra un viaje a través de un agente de viajes 830, un consumidor 810 puede ser abastecido con un contrato de paquete que incluye primeros arreglos, alojamientos en hotel, servicios de transporte, etc. El comerciante 830, quien normalmente contrata muchos de dichos bienes y/o servicios, posteriormente debe mantener una cuenta detallada de dicha transacción comercial con el objeto de realizar los pagos adecuados a sus socios de negocios. Con el objeto de aliviar la complejidad de dicha cuenta y otras tareas, las modalidades de la presente invención proporcionan úna federación de pago automática a socios de negocio dentro de un tipo particular de relación en una base por transacción. Por ejemplo, un servicio de renta de autos (por ejemplo, socio de negocio "A" 820) puede requerir el pago del comerciante 830 como parte de una venta de paquetes de día festivo). Una compañía de seguros (por ejemplo, socio de negocio "B" 825) puede cargar al comerciante 830 en una base de pago por transacción. Con base en el límite de confianza del socio de negocio 835, los pagos son federados a cada socio de negocio (por ejemplo, "A" 820 y "B" 825) cuando se realiza un solo pago al comerciante 830. En otras palabras, el consumidor 810 o proveedor de pago 805 realiza un solo pago al comerciante 830; sin embargo, todas las subsidiarias con una relación de negocio de acuerdo con un límite de confianza para el modelo de negocio 835 pueden ser pagadas en forma adecuada. Se debe observar que dicho pago normalmente estará sujeto a la orden de facturación electrónica tal como se describe con mayor detalle más adelante. En forma más específica, varias partes de una factura electrónica para captura, presentación y otros propósitos, pueden corresponder a la parte de pago que debe ser federada a cada socio de negocio. Además, a cada una de estas partes puede ser firmada y/o encriptada de modo que la información particular con respecto al pago sea oscura para el consumidor 810, proveedor de pago 805, o entre los diversos socios de negocio 820, 825 tal como se define a través de los diversos límites de crédito 815, 825. Se debe observar que aunque el modelo de federación de pago anterior se describió con respecto a una experiencia con agencias de viaje, también existen otras relaciones de negocio que pueden utilizar esta modalidad. Por ejemplo, las compañías que construyen artículos con múltiples componentes comprados a través de diversos vendedores, proveedores de producto quienes compran materiales para el producto y realizan pagos con bases por artículo, pagos para productos multimedia quienes pagan comisiones a base de cada venta, o cualquier otro tipo de modelo de negocio que reúna o pueda calcular de otra forma realizar pagos a los socios de negocio en una base por artículo, también puede utilizar las modalidades aquí descritas. Por lo tanto, el uso anterior de la agencia de viajes para describir diversas modalidades de la presente invención, es únicamente con propósitos ilustrativos y no significa un límite o restricción de las modalidades aquí descritas. La figura 4, ilustra un sistema de cómputo en red, para manejar transacciones comerciales, de acuerdo con una modalidad de la presente invención. El sistema de cómputo en red 400 puede ser similar a un sistema de computadora 100 ilustrado en la figura 1. Sin embargo, en la figura 4, cada computadora del sistema 400, incluye instalaciones locales del software de transacciones comerciales 485. En particular, la computadora del usuario final del consumidor 410, proveedor de identidad 420, proveedor de pago 430 y comerciante 440 incluyen un software de transacciones comerciales 485a-485d, respectivamente. El software de transacciones comerciales instalado localmente en cada una de las computadoras en el sistema puede ser el mismo, o puede ser diseñado a la medida de una computadora particular en virtud del papel(s) que desempeña la computadora en la transacción (es decir, si la computadora opera como un nodo de usuario final, un nodo de comerciante, un nodo de proveedor de identidad, un nodo de proveedor de pago, etc., o alguna combinación de los anteriores). En cualquier caso, cada instalación está configurado para comunicarse en otra computadoras de red para llevar a cabo transacciones en línea. Por ejemplo, cada instalación puede estar configurada para comunicarse con instalaciones en computadoras en red, para realizar de esta forma los métodos que se ilustran en la figura 2 y/o figura 3. En una modalidad, la instalación local del software de transacción comercial 485a o proveedor de identidad 420 puede crear una ficha de identidad que identifica el usuario final que utiliza la computadora de usuario final 410. Además, el software de transacción comercial 485a en el proveedor de identidad 420 puede dirigir la ficha de identidad a la computadora del usuario final 410, el proveedor de pago 430, el comerciante 440, y/o cualquier otra computadora, ya que la presente invención no.se limita a este aspecto. La instalación local del software de transacción comercial 485b en la computadora 410 del usuario final puede emitir información de identidad (para identificar al usuario final) en respuesta a una indicación para llevar a cabo la transacción en línea entre el usuario final y un comerciante. La instalación local del software de transacción comercial 485c instalada en el proveedor de pago 430 puede recibir la ficha de identidad y generar una ficha de pago que verifique la capacidad del usuario final para pagar (por ejemplo, la ficha de pago) la transacción en línea. La instalación local del software de transacción comercial 485d instalada en el comerciante 440 puede recibir la verificación de la capacidad que tiene el usuario final para pagar antes de proceder con la transacción en línea. En una modalidad, cada una de las computadoras en el sistema 400 opera utilizando una instalación local del mismo sistema de operación o uno similar 495. Por ejemplo, cada una de las computadoras en el sistema 400 puede operar utilizando el sistema de operación Microsoft Windows®. El software de transacciones comerciales 485 puede ser un sub-sistema del sistema de operación. En esta forma, las diversas computadoras empleadas en una transacción comercial se comunican en un modo consistente y conocido. Ya que el software de transacciones comerciales se comunica directamente a través de la red y maneja la validación, verificación y seguridad, el comerciante y el usuario final no necesitan conocer nada con respecto al otro, y de manera más importante, pueden no necesitar establecer alguna relación de confianza. Además, debido a que ciertas partes de .las transacciones son manejadas por el sistema de operación, gran parte de la transacción puede llevarse a cabo en forma substancialmente invisible para el usuario, sin requerir confusión y con frecuencia incomodidad por parte del usuario final . Al tener el software de transacciones comerciales en la computadora, se pueden utilizar varias técnicas de encriptación durante la transmisión de información de una computadora a otra. Además, se pueden incluir características de seguridad adicionales tales como fichas de identidad y/o fichas de pago que son válidas durante un período de tiempo limitado. Por ejemplo, una ficha de identidad puede incluir un componente de tiempo que específica un tiempo después del cual cualquier componente que recibe y procesa la ficha debe considerarse inválido, y no tomar en cuenta la ficha como la verificación de identidad y/o pago. Los componentes del software de transacciones comerciales pueden procesar en forma programada cualesquiera límites de tiempo asociados con una ficha. Esto puede evitar que las fichas se obtengan mediante "la pesca" que se puede utilizar en forma inadecuada en una fecha posterior. Se deberá apreciar que el software de transacción comercial necesita ser parte del sistema de operación, sino que puede ser cualquier programa o grupos de programas local en las computadoras implicadas en una transacción comercial que puede comunicarse con otras a través de la red. Por ejemplo, el software de transacciones comerciales puede ser una aplicación desarrollada por una tercera parte que puede ser instalada en las computadoras en, o en forma independiente del sistema de operación instalado en la computadora. La aplicación puede configurarse para operar con cualquiera o una combinación de sistemas de operación, que están disponibles para computadoras o aparatos en un amplio rango de capacidades y configuraciones, y no limitarse a un sistema de operación, procesador, y conjunto de instrucciones en particular, etc.
La figura 5 ilustra una transacción comercial iniciada un usuario final que selecciona uno o más bienes y/o servicios deseados, en donde los componentes de transacción de la compra, sean manejados al menos en parte, por un sub-sistema de software de transacción distribuido como parte del sistema de operación de las diversas computadoras implicadas en una o más transacción. Un usuario final conectado a una red 505 a través de la computadora de usuario final 510 puede estar corriendo en una aplicación 555. La aplicación 555 puede ser un buscador que despliega el sitio web de un negocio que ofrece mercancía o servicios para venta. La aplicación 555 puede ser una aplicación que proporciona una opción para encajar en una transacción en línea, tal como un programa de edición de imágenes que permite a los usuarios manipular imágenes. El usuario final puede seleccionar uno o más bienes o servicios para comprar a través de la aplicación 555. Por ejemplo, el usuario final puede desear tener una imagen editada impresa profesionalmente en un papel con calidad de fotografía. La aplicación 555 puede incluir dicha opción bajo el menú de impresión. La opción de impresión, cuando se selecciona, puede generar una ventana o cuadro de diálogo que describe todas las opciones de impresión disponible, incluyendo los servicios disponibles a través de la red. Por ejemplo, la opción de impresión puede describir proveedores de servicio 540a, 540b, y 540c como opciones para proporcionar el servicio de impresión. Cuando el usuario selecciona uno de los proveedores de servicio, la transacción comercial en línea, tal como se describió anteriormente puede ser iniciada. En particular, el proveedor de servicio puede requerir que el usuario final proporcione una ficha de identidad. En respuesta, la aplicación 555 (o una aplicación incrustada en un software de transacciones comerciales 585), puede generar un cuadro de diálogo o interfase que describa los proveedores de identidad disponibles. Por ejemplo, tal como se describió con mayor detalle más adelante, el cuadro de diálogo puede describir proveedores de identidad 520a, 520b, y 520c como posibles proveedores de identidad que el usuario puede seleccionar para manejar la verificación de identificación. La figura 9, ilustra el uso en un sub-sistema comercial confiable y otras características en un sistema distribuido y de acuerdo con modalidades de ejemplo. Tal como se muestra, un aparato de cómputo local 920 dentro del sistema distribuido 900 está configurado para proporcionar una transacción de venta al menudeo en línea o local de acuerdo con las modalidades aquí descritas. Se debe observar que aunque el sub-sistema de transacción comercial confiable 965 se muestra únicamente como parte del aparato de cómputo local 920, también pueden residir sub-sistemas similares en otras entidades de la red. Además, se debe observar que aunque se pueden describir en la presente invención varios componentes o módulos como residiendo en cualquier entidad de red en particular, dichos componentes o módulos pueden ser distribuidos a través del sistema de cómputo y residir en cualquier número de entidades de red (por ejemplo, las partes pueden existir en una o más entidades de red). Por consiguiente, la distribución estética específica y uso de un módulo particular a través de un aparato o entidad de red que se utiliza en la presente invención únicamente con propósitos ilustrativos, y no pretende limitar o restringir de otra forma el alcance de las modalidades de la presente invención. Sin importar la distribución o el acomodo estético del sistema de cómputo 900, tal como se describió anteriormente existe un límite de crédito 906 que separa la relación de confianza entre los diversos componentes. Aunque la relación puede ser dividida en forma diferente, en este ejemplo existe una relación de confianza entre el proveedor de pago 990 y el sub-sistema de transacción comercial confiable 965. Esto permite de manera conveniente muchas características que los sistemas comerciales normales no pueden proporcionar. Por ejemplo, el límite de crédito 906 abstrae aplicaciones 925 de la transacción comercial con el comerciante. Por consiguiente, la legalidad y otras aplicaciones 925 pueden proporcionar una experiencia en banda para el usuario final 940, aunque gran parte de la funcionalidad parece fuera de banda. Por ejemplo, en el ejemplo anterior para permitir la impresión de una imagen profesional en un papel con calidad de foto, la selección dentro del menú de desplazamiento, la validación de identidad, las opciones de pago y otros componentes para ayudar al usuario en dicha compra de servicio, parecen como parte de la aplicación 925. Por consiguiente, la aplicación 925 cuando recibe la entrada a los bienes y/o servicios de compra puede realizar una llamada de compra 930 en el sub-sistema de transacción comercial confiable 965, la cual posteriormente se utiliza para generar cuadros de diálogo, recibir la entrada 935 del usuario 940, y comunicarse automáticamente de otra forma con el comerciante 905 y/o proveedor de pago 990 tal como se describe en la presente invención. En otras palabras, el usuario 940 no necesita confiar necesariamente en la aplicación 925 o el comerciante 905 en la transacción comercial. De hecho, la confianza está limitada al sub-sistema 965 de la estructura presente, que reduce el grado o niveles de confianza necesaria para llevar a cabo en forma confidencial y segura una transacción comercial. Esto es, los detalles de la cuenta 950 para el usuario 940, que incluyen información sensible 955 que el usuario 950 no está dispuesto o se siente incómodo de compartir públicamente (por ejemplo, información de tarjeta de crédito, información personal, nombres de usuario/contraseñas, etc.), son accesadas a través de la entrada directa del usuario 935 al sub-sistema 965 o del almacén de información 945 de cuenta segura 960. Por lo tanto, las aplicaciones 925, el comerciante 905, y otros componentes son abstraídos de los detalles financieros o de la cuenta de facturación 955 controladas por el sub-sistema 965 tal como se describe en la presente invención. Esto es muy diferente a los modelos de transacción comerciales normales descritos anteriormente, en donde las aplicaciones 925 o los comerciantes 905 mantienen y controlan la información de la cuenta. Por consiguiente, estas y otras modalidades aquí descritas proporcionan de manera conveniente capas adicionales de seguridad durante dichas transacciones comerciales. Esto es una relación de confianza mucho más dirigida, con el objeto de minimizar el número de componentes u organizaciones que tienen acceso a, o tiene contacto con datos financieros muy sensibles. Tal como se muestra en la figura 9, y similar a la transacción comercial segura de tres vías descrita anteriormente, el límite de confianza 906 también indica una comunicación segura entre el proveedor de pago y el sub-sistema de transacción confiable 965. Por consiguiente, el subsistema 965 autentifica al proveedor(s) de pago 990 en cualquiera de una variedad de formas aquí descritas, permitiendo una comunicación segura entre ellos. En forma similar a lo anterior, el aparato de cómputo local (el cual puede ser un aparato portátil tal como se describe más adelante en una transacción de venta al menudeo local, una computadora personal en una transacción en línea, u otro aparato similar tal como aquí se describe) desea varios bienes y/o servicios ofrecidos por el comerciante(s) 905. En este ejemplo, , la información de facturación 910 se presenta al aparato de cómputo local 920 para autentificación , auditoria y otros propósitos tal como se utiliza en las modalidades de ejemplo aquí descritas. Dicha información de facturación puede incluir, pero no se limita a, costo de la mercancía y/o servicios, descripción detallada de la transacción comercial, información específica del comerciante 905, información de pago de federación, tipo de transacción (por ejemplo, pago simple, subscripción, etc.), u otros tipos de información de facturación. La información de facturación 910 también puede incluir otra información tal como restricciones del comerciante y opciones de pago tal como se describe con mayor detalle más adelante. En una modalidad, la información de facturación 910 es una factura electrónica configurada para hacer legible la máquina, se proporciona muchas capacidades convenientes del sistema de transacción comercial actual. Por ejemplo, una modalidad proporciona que la información de facturación 910 pueda ser parte de la solicitud de ficha de pago 980 (o suministrada de otra forma en otra comunicación al proveedor de pago 990) tal como se describió previamente. Por lo tanto, la información de facturación puede ser utilizada por el proveedor de pago 990 para la validación de la ficha de pago 940. Más específicamente, la información de facturación 910 proporcionada del consumidor o aparato de cómputo local 920 puede ser comparada con la información de la ficha de pago 985 proporcionada por el comerciante 905 en la validación de ficha de pago 904. Por consiguiente, si la información de facturación 910 de la validación de ficha de pago 904 coincide con la información de facturación 910 de la solicitud de ficha 980, el proveedor de pago 990 puede asegurarse en forma adicional de la autenticidad de la ficha de pago 985 y la validez del comerciante. Se debe observar como puede variar la información . de facturación 910 del comerciante que es relevada al proveedor de pago 990 (así como otros componentes aquí mencionados). Por ejemplo, la información de facturación 910 enviada del comerciante 905 al proveedor de pago 990 puede ser una copia de una información de factura 910 enviada al sub-sistema de transacción comercial confiable 965 o cliente 920. Como alternativa, o en conjunto, la información de la factura 910 puede ser una versión firmada y/o encriptada del proveedor de pago 990, enrutada a través del aparato de cómputo del consumidor 920 o local. En cualquier caso, el proveedor de pago puede realizar la comparación descrita previamente para autentificacíón de la ficha de pago 985. Se debe observar además que la información de facturación 910 tal como es utilizada por el proveedor de pago 990 también puede ser utilizada para proporcionar la descripción más detallada de cargos asociados con una factura que subsecuentemente será presentada por el usuario 940 para cargos en la cuenta del usuario. Debido a que esta también puede ser una factura legible en máquina 910, el aparato'de cómputo local 920 puede cotejar la información de la factura 910 con la recibida previamente por parte del comerciante 905 para la autorización adicional del pago al comerciante 905. En otras palabras, si la información de la factura 910 dentro de la factura procedente del proveedor de pago 990 no coincide con lo recibido del comerciante 905, entonces los cargos se pueden considerar como fraudulentos. En otra modalidad, el comerciante 905 puede utilizar la información de la factura 910, con propósitos de auditoria, usuario y otros propósitos de autentificación, federación de pago, etc. Por ejemplo, el comerciante puede firmar o encriptar de otra forma partes de la información de la factura 910. Esto permite múltiples características convenientes en las modalidades aquí descritas. Por ejemplo, la información de la factura 910 puede ser parte de la ficha de pago 985 recibida por el proveedor de pago a través del aparato de cómputo local 920. El comerciante 905 puede revisar la validez de ' la información de la factura 910 para autentificar que la ficha de pago 985 puede venir del cliente 920 o un sub-sistema de transacción comercial deseable 965. En forma similar, durante la validación de la ficha de pago 904, el comerciante 905 puede utilizar la información de la factura 910 recibida del proveedor de pago 990 para validar o autentificar al proveedor de pago y/o aparato de cómputo local 920. En otras palabras, debido a que la información de la factura 910 es enrutada al proveedor de pago a través del sub-sistema 965 o el consumidor 920, la información de facturación recibida del proveedor de pago que coincide con la enviada al cliente 920 puede autentificar tanto al cliente 920 como a la ficha de pago 985 procedente del proveedor de pago 990. Se debe observar que en otra modalidad, tal como ' se describió brevemente anteriormente, la información de la factura 910 puede ser utilizada por el comerciante para la federación del pago. En esta modalidad, varias partes de la información de la factura 910, pueden ser legibles en máquina para determinar partes de los fondos del proveedor de pago 990 (en la autentificación exitosa del pago) deben ser distribuidos a los socios del negocio tal como se describió previamente. Se debe observar que en esta modalidad, normalmente las partes de la información de la factura 910 pueden ser encriptadas u oscurecerse de otra forma para el usuario 940 (o cliente consumidor 920), el proveedor de pago 990, u otros componentes que no son parte de de la relación de negocios con el comerciante 905. Esto también identifica de manera única el socio de negocio en la federación de facturación, y puede ser utilizada con propósitos de autentificación . En forma más específica, las diversas partes de la información de la factura 910 específica de un socio del negocio pueden encriptarse utilizando una clave específica de dicho socio del negocio, de esta forma la información de la facturación puede ser vista únicamente por el comerciante 905 y el socio del negocio específico. Sin embargo, en otras modalidades, las partes de la factura para la distribución o federación del pago, son firmadas únicamente por el comerciante 905 para hacerlas oscuras posteriormente para los otros componentes que están dentro del sistema 900. Por supuesto, tal como se podrá reconocer, se pueden utilizar otros usos de la información de facturación 910 con diversos propósitos. Por ejemplo, la información de facturación 910 también se puede utilizar con propósitos de auditoria, reconciliación de distribución de productos, cualquier otro propósito de negocios etc. Por consiguiente, el uso anterior de la información de la factura 910 para autorización, identificación, federación de pago o cualquier otro propósito se utiliza únicamente con propósitos ilustrativos y no significa el límite o restricción de otra manera del alcance de las modalidades a menos que se reivindique de manera explícita lo contrario. Se debe observar que el límite de confianza 906 y el sub- sistema 965 también pueden tener otras características convenientes en otras modalidades aquí descritas. Por ejemplo, tal como se muestra en la figura 9, el código del proveedor de pago 970 dentro del sub-sistema 965 permite que corra en forma segura un código específico para uno o más proveedores de pago 990. Dicho código puede ser utilizado para una autorización adicional específica para el proveedor de pago, por ejemplo, técnicas de autentificación biométricas, identificación de radiofrecuencia (RFID), nombre de usuario/contraseña, o cualesquiera otras numerosas técnicas de autentificación adicionales. En otras palabras, debido a la relación confiable que el proveedor de pago 990 tiene con el sub-sistema 965, el corredor de pago puede correr el código confiable para su propósito de negocio específico. El uso de dicho código 970 también permite una experiencia del usuario en banda más integrada, que puede ser controlada por el proveedor de pago 990 o cualquier otro componente que tiene una relación confiable con el sub-sistema 970. Por ejemplo, aunque no se muestra, puede existir una relación confiable entre algunos comerciantes 905 y el subsistema 965 para permitir que el código confiable del mismo sea corrido por el sub-sistema 965. Por lo tanto, el comerciante 905, el proveedor de pago 990, o cualquier otro componente implicado en la transacción comercial, puede proporcionar una experiencia del usuario integrada que parece como si hubiera corrido desde dentro de la aplicación 925 (legalidad o de otra forma); sin embargo, muchos de los eventos ocurren fuera.de banda. Por ejemplo, en el ejemplo anterior de una impresión con calidad de fotografía de una imagen por parte de un servicio profesional, los cuadros de diálogo, opciones de pago o cualquier otro número de características presentadas a la funcionalidad del usuario o aplicación (por ejemplo, en respuesta a una entrada del usuario) pueden ser controladas por el código 970 proporcionado en forma específica por las diversas entidades de la red confiable (por ejemplo, el proveedor de pago 990, el comerciante 905, etc.). Por consiguiente, tal como se describirá con mayor detalle más adelante, este código también puede ser utilizado cuando se evalúan opciones de pago y otras restricciones del comerciante 905 y/o proveedor de pago 990. Tal como se mencionó anteriormente, en una modalidad, el proveedor de servicio seleccionado o el comerciante transmite cualesquiera requerimientos al proveedor de identidad con la solicitud de verificación de identidad. Por ejemplo, el proveedor de servicio puede vender bienes y servicios que requieren una edad mínima o se restringen a una cierta ubicación geográfica. Por consiguiente, las listas de proveedores de identidad pueden estar limitadas a las que pueden proporcionar credenciales de identidad que satisfacen los requerimientos del proveedor de servicio. Por ejemplo, la lista de proveedores de identidad puede ser restringida a las que puede proporcionar verificación de edad o información de dirección actual, tal como el RMV. De igual manera, se puede generar un cuadro de diálogo que describa opciones de proveedores de pago. Por ejemplo, el cuadro de diálogo puede describir los proveedores de pago 530a, 530b y 530c, los cuales pueden incluir una compañía de tarjeta de crédito, banco que ofrece servicios de debito electrónicos, o una tercera parte privada que ofrece servicios financieros, respectivamente. Como con la solicitud de identidad, el proveedor de servicios seleccionado puede incluir cualesquiera requerimientos de pago asociados con la compra. Por ejemplo, el proveedor de servicios puede aceptar únicamente cierto tipo de tarjeta de crédito. Posteriormente los requerimientos de pago pueden verse reflejados en los proveedores de pago disponibles descritos o habilitados en el cuadro de diálogo de selección de proveedor de pago. Después de que se seleccionó un proveedor de pago, la certificación de pago puede proceder y la transacción puede completarse. Se debe observar que otras modalidades también proporcionan comparación de restricciones del comerciante (por ejemplo, opciones de pago disponibles, restricciones de edad, etc.) con reglas del consumidor para determinar varias acciones que pueden ser tomadas. La figura 10, ilustra una modalidad en donde el sistema distribuido 1000 está configurado para determinar en forma programada acciones con base en cosas tales como restricciones del comerciante 1010 y/o reglas del consumidor 1035. Por ejemplo, el comerciante 1020 puede definir dentro de las restricciones del comerciante 1010 los proveedores de pago 1005 o tipos de pago aceptable para, la compra de vienes y/o servicios de los mismos. El módulo de decisión posteriormente puede presentar dichas restricciones al usuario, por ejemplo, en una interfase del usuario que requiere una entrada del usuario 1040 para elegir una o más opciones de pago disponibles. Con base en la entrada del usuario 1040, el proveedor de pago adecuado 1005 puede ser contactado para la generación de fondos adecuada de los vienes y/o servicios. En otra modalidad, las reglas del consumidor 1035 también pueden ser utilizadas además de, o en lugar de, las restricciones del comerciante 1010. Por ejemplo, las reglas del consumidor 1035 pueden indicar que únicamente ciertos tipos de pagos pueden ser realizados para ciertos tipos de comerciantes 1020. En forma más específica, las reglas del consumidor 1035 pueden indicar que si el comerciante 1020 no está registrado o no es confiable, que únicamente los pagos que puedan ser invertidos puedan ser utilizados para elaborar la compra del comerciante 1020. Por supuesto, tal como se describió anteriormente, se pueden utilizar otras reglas del comerciante 1010, y restricciones del consumidor 1035 por parte del módulo de decisión 1030 cuando se determinen acciones a tomar en una transacción comercial. De hecho, las restricciones del comerciante 1010 y las reglas del consumidor 1035 pueden compararse para compatibilidad y otros propósitos. Por ejemplo, las opciones de pago disponibles del comerciante 1020 pueden compararse con los proveedores de pago 1005 o permisibles por el consumidor, cuando se presenta al usuario una selección de proveedores de pago 1005. Por supuesto, la selección de pago también puede ocurrir en forma automática con base en cosas tales como ajuste de omisión, rangos o preferencias del proveedor, o cualquier otro número de ajustes de opciones. De hecho, cualquier número de acciones pueden ocurrir con base en la implementación de varias reglas del comerciante 1010 y/o consumidor 1035. Por ejemplo, si las reglas (comerciante 1010 o consumidor 1035) fallan o son violadas de otra forma, se puede necesitar la entrada adicional del comerciante 1020 o usuario 1040 (ya sea en forma automática con base en reglas o configuraciones adicionales), para resolver los conflictos u otras discrepancias. Por consiguiente, cualquier acción particular tomada cuando se implementan las restricciones y/o reglas definidas, es utilizada en la presente invención o únicamente con propósitos de ilustración y no pretenden limitar o restringir de otra manera las modalidades aquí proporcionadas. Además se observó que, tal como se describió anteriormente, las restricciones 1010 del comerciante pueden ser incluidas dentro de la información de facturación o ser proporcionadas en forma separada al consumidor. También se observó que la comparación de varias reglas y acciones tomadas en la misma todas pueden ocurrir bajo lo siguiente, por ejemplo, sin el conocimiento del usuario y/o otros componentes del sistema. Además, se observó que el presente sistema no está limitado a las restricciones o reglas definidas entre el consumidor o el comerciante. Por ejemplo, el proveedor de pago puede también definir varias restricciones que también serán consideradas en conjunto o adjuntas de las reglas del consumidor y/o comerciante. Por consiguiente, el uso anterior de las restricciones del consumidor y el comerciante para determinar varias acciones (tales como opciones de proveedor de pago) es utilizado en la misma para propósitos ilustrativos únicamente y no de limitación o de otra forma las modalidades tal como se describe a menos que se reivindique explícitamente de otra forma. En convenio las transacciones en línea son difíciles tanto para el usuario final y/o para el proveedor de servicio con seguridad cuando se completó una transacción y si los bienes o servicios han sido suministrados en forma exitosa. Por ejemplo, un usuario final puede seleccionar un paquete de software para descargar a través de la red, y un usuario final puede comprar canciones, películas u otros medios electrónicos. Algunas veces una conexión de red puede ser interrumpida antes de que se completen la descarga. Bajo tales circunstancias, el usuario final puede intentar solucionar nuevamente la mercancía, aunque puede ser difícil, debido a que el usuario final no conoce si se le duplicará el cargo por dicha compra. De igual manera, el proveedor de servicio puede no saber si una descarga fue completada con éxito, y puede duplicar el cargo cuando un usuario intenta mediar la interrupción, seleccionando nuevamente la mercancía. El solicitante ha apreciado que al proporcionar capacidades de registro y auditoria en el software de transacciones comerciales, se pueden eliminar algunas de las i ncertid u m bres con respecto a las descargas electrónicas. Por ejemplo, la ejecución final de la opción de pago puede depender de la señal por parte de la característica de auditoria, de que la descarga se ha completado. De esa forma, si se interrumpe una descarga, el usuario final puede tener la seguridad de que la opción de pago seleccionada no está procediendo. Por ejemplo, el software de transacciones comerciales 585 de la figura 5 (u otros subsistemas o componentes de entidad de red, tal como se describe en la presente invención) pueden incluir una característica de registro que grabe todos los diferentes pasos de las transacciones comerciales llevadas a cabo por la máquina. La información de registro puede utilizarse como una prueba de la compra o para la memoria de transacciones. Además, el software de transacciones comerciales 585 puede incluir el monitoreo de capacidades para descargas electrónicas, que envía una verificación de una descarga exitosa, únicamente después de lo cual se puede realizar el pago final. Al realizar un pago contingente en una señal de que la transferencia de los bienes y servicios se completó en forma exitosa, se pueden atender y eliminar substancialmente los aspectos de la doble facturación. El software ha sido desarrollado por compañías que manejan una amplia variedad de tareas que incluyen palabras familiares y procesamientos de documento, hojas de cálculo, edición de imágenes, para tareas más especializadas tales como edición de video, software de gráficos de computadora, aplicaciones de desarrollo de contenido web, software de administración de portafolio, etc. Sin embargo, dicho software que maneja cada tarea que un usuario final puede desear llevar a cabo, puede ser prohibitivamente costoso. Los paquetes de software pueden costar desde cientos hasta miles hasta e incluso hasta cientos de miles de dólares para obtener una sola licencia. Además, un usuario final puede necesitar los servicios de una aplicación particular únicamente en forma ocasional o esporádica, de modo que el costo de la compra de la aplicación pueda no ser justificada. El solicitante ha apreciado los beneficios de permitir a un usuario final utilizar un software en un ambiente de pago conforme se obtiene. En particular, a un usuario final, se le puede cargar únicamente la cantidad de tiempo utilizado en la aplicación, en lugar de pagar el precio al menudeo por el software (en donde mucho de las características y/o aplicación pueden no ser utilizadas en su totalidad). La figura 6, un sistema- de cómputo en red que tiene una estructura de transacción comercial que permite a un usuario final pagar por la cantidad de tiempo transcurrido utilizando la aplicación. El sistema de cómputo en red 600 incluye una red 605 que interconecta el nodo del usuario final 610 a una pluralidad de proveedores de identidad 620, una pluralidad de proveedores de pago 630, y una pluralidad de proveedores de servicio 640. El nodo del usuario final 610 puede ser en una computadora que corre en un sistema de operación 695. Instalada en la computadora del usuario final puede haber una pluralidad de aplicaciones de software 655. Las aplicaciones.de software pueden venir en manojo con la computadora al momento de la compra, pueden haber sido descargadas gratuitamente a través de una red, o distribuidas de otra forma (con frecuencia en forma gratuita o por un cargo nominal, o por un registro con el vendedor) a través del vendedor de la aplicación. La aplicación 655 puede ser cualquier tipo de aplicación y cualquier número de aplicaciones pueden instalarse en la computadora. Los proveedores de servicio 640 pueden estar asociados con una o más aplicaciones instaladas en una computadora del usuario final 610. Por ejemplo, el proveedor de servicio 640a puede ser una o más computadoras propiedad del desarrollador y vendedor de la aplicación 655a. En forma similar, los proveedores de servicio 640b y 640c pueden estar asociados con aplicaciones 655b y 655c, respectivamente. En el modelo de pago por lo que se obtiene, el servicio proporcionado por los proveedores de servicios es una licencia para utilizar las aplicaciones asociadas e instaladas en la computadora. Por ejemplo, cuando el software (por ejemplo, aplicaciones 655) se distribuyen de manera gratuita, puede ser deshabilitada inicialmente de modo que los usuarios ni puedan correr la aplicación sin obtener primero una licencia por parte del vendedor de la aplicación. La licencia puede ser obtenida iniciando una transacción comercial con uno o más proveedores de servicio 640. Por ejemplo, la aplicación 655a puede ser una aplicación de publicación de escritorio de que el usuario final puede desear utilizar un par de horas para el diseño de una tarjeta o folleto. Cuando el usuario final abre la aplicación 655a, el usuario final es notificado de que necesita comprar una licencia para utilizar la aplicación. Por ejemplo, puede aparecer un cuadro de diálogo que describe las características y precios de las diversas facilidades de licencia para uso. Una licencia puede ser por una cantidad de tiempo específica, por ejemplo, una hora o un día. La licencia puede expirar una vez que la aplicación ha sido cerrada, o la licencia puede permanecer activa hasta la expiración del término. La licencia puede basarse en operaciones o tareas que permiten a un usuario final completar uno o más trabajos o emplear una o más características deseadas. Las características adicionales que serán utilizadas pueden incrementar el costo de la licencia. Se deberá apreciar que una licencia que tiene cualesquiera términos deseados puede ser negociada, ya que los aspectos de la presente invención no se limitan a este respecto. Una vez que el usuario final ha seleccionado la opción de licencia, el usuario final puede ser instruido de seleccionar un proveedor de identidad y/o proveedor de pago, o el uno o el otro puede ser seleccionado por default, para iniciar una transacción en línea. La transacción puede ser manejada por un software de transacción comercial 685 substancialmente como se describe en cualesquiera de las modalidades anteriores o que se encuentran más adelante. Cuando el proveedor de servicios recibe una ficha de pago de uno de los proveedores de pago 620, el proveedor de servicio puede transmitir una licencia de acuerdo con los términos convenidos al momento del inicio de la transacción. La licencia recibida puede ser procesada por un servicio de licencia genérica 690, de modo que la accesibilidad adecuada para la aplicación pueda ser invocada. El servicio de licencia genérica puede posteriormente presentar una clave de habilitación para las aplicaciones 655, de modo que usuario pueda correr el software y utilizar su funcionalidad de acuerdo con la licencia. La clave de habilitación puede incluir cualquier información que la aplicación pueda necesitar para proporcionar los servicios necesarios para el término indicado en la licencia. La clave de habilitación puede incluir una contraseña proporcionada por el proveedor de servicios, de modo que la aplicación conoce que la licencia es válida y/o simplemente puede depender de la representación del servicio de licencia genérica 690 de que se ha obtenido una licencia válida. Una ves que la aplicación está operando, el procesador de medición 694, puede ser notificado para mantener el seguimiento del tiempo e indicar a la aplicación cuando a expirado la licencia. Como alternativa, la aplicación puede ser programada para solicitar en forma periódica al procesador de medición, y posteriormente deshabilitarlo cuando la licencia haya expirado. Además, al solicitar al procesador de medición, la aplicación puede proporcionar alertas o actualizaciones periódicas al usuario con respecto a la cantidad de tiempo que le resta en la licencia comprada, si la licencia incluye un término. Cuando el usuario final termina puede elegir tener el producto completado e impreso en forma profesional y seleccionar una opción de impresión que inicie otra transaccjon en línea, tal como la transacción descrita con relación a la figura 5. La licencia de pago según lo que se obtiene puede proporcionar a los usuarios mucha mayor flexibilidad y darles acceso al software al que ellos podrían no haber tenido acceso previo debido al costo de comprar el paquete de software con una licencia de tiempo de vida. Además, los vendedores de software pueden capitalizar una ganancia del usuario, quienes no desean pagar todo el precio de la venta, sino desean pagar el uso limitado y/o funcionalidad limitada. La piratería de software, impacta las ganancias en toda la industria del software. Los usuarios de los softwares sin licencia, costean cantidades relativamente substanciales cada año. Una vez que el producto de software ha sido comprado, el vendedor tiene poco control con respecto a en donde y cómo se instala el software en muchas computadoras. La descarga ilegal de un software a través de Internet, proporciona un método aún más penetrante para distribuir y obtener software por los que no ha pagado el usuario final. El solicitante ha apreciado que el proporcionar una estructura de transacciones comerciales relativamente segura y simple, con un esquema de licencia de pagar según la obtención, por ejemplo, la estructura descrita en la modalidad ilustrada en la figura 6," se puede mitigar o eliminar los problemas de piratería. Ya que el software es distribuido en forma gratuita por el vendedor, los usuarios finales pueden adecuar el software tal como ellos lo deseen. Ya que el software es habilitado únicamente a través del pago por una licencia de término o licencia de tarea, los usuarios finales están substancialmente limitados en su capacidad de dar mal uso al software.
Tal como se describió anteriormente, las modalidades de la presente invención permiten la autentificación con propósitos de identidad y/o pago, utilizando un módulo móvil (por ejemplo, un módulo de identidad de subscriptor (SIM)) atado a una cuenta de facturación en particular de una infraestructura móvil o sistema de operación. A diferencia de los estándares típicos para comunicaciones móviles (por ejemplo, Sistemas Globales para comunicaciones Móviles (GSM), el Proyecto de Partes de 3ra. Generación y otros protocolos similares), lo cual ocurrirá a través de una red de radio confiable, la autentificación de acuerdo con las modalidades de la presente invención tiene lugar a través de una red de datos no confiable independiente (por ejemplo, la Internet). Como resultado, las modalidades de la presente invención se dirigen a muchos de los aspectos de seguridad adicionales impuestos por el uso de dichos módulos móviles (SIMs) en un Servicio Web y otros ambientes de protocolo de red independientes. Dichos aspectos de seguridad incluyen entre otras cosas: determinar un punto de extremo de red confiable para la autentificación de un servidor, autentificación de un cliente para un módulo móvil o aparato SIM, la autentificación de un usuario al aparato SIM, la autentificación del SIM y un servidor de autentificación, el establecimiento de una conexión de red segura entre el módulo móvil y el servidor de autentificación de red, y la autentificación del usuario para el servidor de la autentificación de la red.
Además, con el objeto de cumplir con GSM, 3GPP, y otros estándares, se imponen requerimientos adicionales en el equipo terminal, lo cual interactuará con el módulo móvil o aparato SIM. Más específicamente, el GSM, 3GPP, y otros estándares similares requieren que el SIM restrinja el acceso a ciertos tipos de información, incluyendo claves de encriptación, para la terminal móvil. Con el objeto de satisfacer estos requerimientos, las modalidades de la presente invención proporcionan un perfil de seguridad de abstracción que delega el procesamiento y descodificación de ciertos mensajes y seguridad para el propio aparato SIM. Por ejemplo, tal como se muestra en la figura 11, un Sistema Firewall (sistema diseñado para prevenir el acceso ilegal a/o desde una red privada conectada a Internet) 1090 define una máquina de estado y mensajes de protocolo para abstraer un SIM 1085 del aparato huésped 1075 cuando se comunica a través de una red independiente 1060. En forma específica, Sistema Firewall (sistema diseñado para prevenir el acceso ¡legal a/o desde una red privada conectada a Internet) 1090 utiliza una máquina de estados formal que limita o restringe el número y/o secuencia de comandos enviado desde una unidad de lectura dentro del ordenador 1075 para la propia SIM 1085. Por consiguiente, el aparato SIM 1080 (por ejemplo, teléfono celular, interfase SIM, etc., - se debe observar que el "módulo móvil" representa un término genérico para una "SIM", aunque se utiliza en la presente invención de manera intercambiable a menos que se reivindique específicamente lo contrario) se convierte en la terminal móvil y el aparato de ordenador 1075 se convierte en un periférico que cumple con el protocolo de comunicación 1055 de la red móvil 1050. A continuación se describe con mayor detalle algunas de las máquinas de estado y protoco.los utilizados para dirigirse a ciertos de los requerimientos de seguridad adicionales y aspectos señalados anteriormente. Las modalidades de la presente invención definen un perfil de seguridad para autentificacion a través de la red independiente no confiable (por ejemplo, una red independiente de una red de radio que corresponde a la infraestructura de módulo móvil o sistema de operador) en términos de varios niveles de seguridad que puede representar una ficha de seguridad determinada. Estos incluyen, pero no se limitan a, nivel de seguridad del aparato, nivel de seguridad de la red, nivel de seguridad del usuario y nivel de seguridad del servicio. En cada nivel hay diferentes requerimientos y procedimientos para obtener una ficha de seguridad. Por consiguiente, tal como se describió con mayor detalle más adelante, cada nivel de seguridad representa un diferente nivel de autentificacion en el modelo de seguridad y cada uno tiene ciertos requerimientos y/o seguridades. Además, se debe observar que cada nivel.de seguridad puede o no ser independiente de otros. Por ejemplo, puede no ser necesario establecer un nivel de seguridad del aparato antes de que se pueda lograr un nivel de seguridad de la red o usuario; sin embargo, con propósitos de seguridad, puede ser deseable dicho procedimiento jerárquico. Un nivel de seguridad del aparato indica la posición física de un módulo móvil, por ejemplo, un aparato SIM tal como teléfono celular. Una ficha del aparato (por ejemplo, una señal de seguridad SIM con un nivel de seguridad del aparato) normalmente se emite localmente a través del módulo móvil o el aparato SIM al momento de la autentificación adecuada a través de un usuario del mismo. Dichos requerimientos para autentificar a un usuario con el módulo móvil normalmente son establecidos por la infraestructura móvil u operador móvil. Además, la autentificación del aparato normalmente es promovida por el aparato SIM, sin embargo, otras modalidades pueden proporcionar el uso de otros componentes en el proceso de autentificación. Por ejemplo, el SIM u otro aparato pueden requerir una contraseña antes de que el módulo móvil u otro aparato emita una ficha del aparato. Por supuesto, otras formas de credenciales para autentificación en el nivel del aparato están contempladas en la presente invención. En una modalidad, el aparato SIM requiere que la computadora cliente o del ordenador autentifique o identifique por si misma al módulo móvil antes de que se emita una ficha de seguridad del aparato. Además, el tiempo de vida de una ficha del aparato normalmente se controla a través del módulo móvil o aparato SIM utilizando un ajuste de política por parte de la infraestructura móvil. En una modalidad, el tiempo de vida u otros requerimientos ajustados por el operador móvil pueden ser configurados en forma dinámica a través de la red independiente y/o de radio. Si la ficha del aparato no tiene tiempo de vida u otras restricciones, normalmente el SIM no requiere que el usuario vuelva a autentificar el módulo móvil más de una ves. El nivel de seguridad de la red indica una conexión autentificada entre el módulo móvil o SIM y la infraestructura móvil o red a través de una red independiente no confiable. El nivel de seguridad de la red puede establecerse sin ' la presencia del usuario o interacción del usuario asumiendo un aparato SIM es accesible para la computadora cliente o del ordenador. Normalmente, el nivel de seguridad de la red es una sola autentificación de factor que evalúa la prueba de posesión del aparato SIM de la infraestructura u operador móvil. Normalmente, la infraestructura móvil permitirá una ficha de seguridad de la red a través de un servidor de autentificación y a través de un mecanismo de tipo de respuesta de estímulo antes de emitir una ficha de seguridad de la red a un aparato de cómputo cliente o de ordenador. Esta ficha de nivel de seguridad de la red puede ser utilizada posteriormente en fases de autentificación subsecuentes y proporciona una seguridad de nivel de transporte para encriptar y/o firmar interacciones adicionales entre un cliente y un servidor de autentificación y/o infraestructura móvil. La figura 7A ilustra una red independiente 700 configurada para emitir una ficha de seguridad de nivel de red para establecer una comunicación segura de nivel de transporte entre el cliente y un servidor de autentificación. Normalmente, el aparato de cómputo cliente o del ordenador 710 (el cual puede ser una computadora personal, teléfono móvil, u otro aparato de cómputo portátil o no móvil) inicia la solicitud de autentificación enviando una solicitud de ficha de seguridad de red 725 a la infraestructura móvil 720 a través del servidor de autentificación/confiable 715 (sin embargo, se debe observar que la solicitud también puede ser iniciada por otro aparato tal como el propio SIM 705). Normalmente, la solicitud 725 estará no firmada cuando sea recibida por el servidor de autentificación 715, el cual posteriormente puede firmar y/o encriptar la solicitud antes de venderla a la infraestructura móvil 720 para validar que la solicitud viene del servidor de autentificación 715. El servidor confiable 715 posteriormente puede solicitar a la infraestructura móvil 720 u operador móvil un cuestionamiento 730, el cual posteriormente será enviado al módulo móvil 705. El módulo móvil 705 utiliza un secreto 740 compartido entre él y la infraestructura móvil 720 para generar una respuesta del cuestionamiento 735, la cual posteriormente es enviada al cliente 710 - se debe observar que normalmente el secreto será específico del SIM 705 y ajustado por el operador móvil 720. El cliente 710, utilizará la respuesta del cuestionamiento 735 para generar una respuesta de ficha de seguridad de la solicitud, la cual puede también incluir una identidad SIM y un cuestionamiento 730 con propósitos de autentificación. Normalmente, el cliente requerirá que el módulo móvil 705 firme y/o encripte la respuesta de la ficha de la seguridad de- la solicitud con el secreto 740 compartido del aparato 705 u otra clave tal como la ficha del aparato SIM - aunque esto puede o no ser necesario. La respuesta de la ficha de seguridad de la solicitud y la respuesta del cuestionamiento 735 en la presente invención, pueden ser validadas utilizando, por ejemplo, el secreto compartido 740. Se debe observar, tal como se mencionó anteriormente, que la respuesta de la ficha de seguridad de la solicitud puede o no estar firmada y/o encriptada a través de la misma clave utilizada para generar la respuesta del cuestionamiento 735. En cualquier caso, si la infraestructura móvil 720 válida la respuesta del cuestionamiento 735 (por ejemplo, la respuesta del cuestionamiento es válida y el módulo móvil tiene una cuenta de facturación activa), la infraestructura móvil 720 y/o servidor de autentificación 715 puede responder generando un mensaje que contiene una ficha de seguridad de la red 745 con una clave(s) de sesión encriptada, las cuales son firmadas y/o encriptadas utilizando el secreto compartido 740. El mensaje puede ser firmado en forma adicional utilizando ya sea la ficha de seguridad propiedad del servidor de autentificación 715 (por ejemplo, el cert X.509, cert Kerberos, etc.) o utilizando la ficha de seguridad de la infraestructura 720. El cliente 710 posteriormente puede verificar el mensaje firmado y pasar la clave(s) de la sesión de red encriptada al SIM 705 para desencriptación . Utilizando el secreto compartido 740, el módulo móvil 705 posteriormente puede regresar la clave(s) de sesión encriptada 750 al cliente 710. Se debe observar que en la emisión anterior de la ficha de seguridad de la red 745, el módulo móvil 705 normalmente necesita una cuenta de facturación activa en buen estado en la infraestructura móvil 720. Por consiguiente, al momento de la verificación de la respuesta del cuestionamiento 735 y la información de la cuenta de facturación activa, se puede establecer una confianza entre SIM 705 y la infraestructura móvil 720 creando un canal de seguridad virtual. La clave(s) de la sesión 750 posteriormente son delegadas o pasadas del módulo móvil 705 a la plataforma de software o pila del aparato de cómputo del ordenador 710 y del operador móvil 720 al servidor de autentificación 715 (si es necesario). Se debe observar que la proximidad física del módulo móvil 705 con el aparato de cómputo del ordenador 710 (el cual puede ser conectado al mismo a través de un puerto USB, Bluetooth, u otra conexión inalámbrica o cableada) y la relación confiable entre la infraestructura móvil 720 y el servidor de autentificación 715. Estas clave(s) de sesión 750 posteriormente son utilizadas por el cliente 710 y el servidor confiable 715 para establecer una comunicación segura 755. Se debe observar que puede haber un segundo módulo de operación para autentificar el módulo móvil 705, el cual puede ser utilizado por la infraestructura móvil 720. En este caso, el ordenador cliente 710 puede requerir que el SIM 705 genere y firme su propio cuestionamiento (normalmente en la forma de un Nonce (Número o cadena de bits utilizado únicamente una ves en la ingeniería de seguridad)). El cliente 710 posteriormente puede agregar la información como parte de la ficha del aparato cuando se solicita la ficha de seguridad de la red 725 del servidor confiable 715 o la infraestructura móvil 720. Si el operador móvil 720 pueda verificar que la ficha del aparato contenga una respuesta-cuestionamiento válido 735, puede emitir directamente una ficha de la red 745 de regreso al cliente 710 para la desencriptación de la clave(s) de sesión, tal como se describió anteriormente. Tal como se describirá con mayor detalle más adelante, normalmente esta ficha de seguridad de nivel de red 745 es requerida para permitir el acceso a un cliente a una ficha de servicio autentificado, que se puede utilizar para solicitar bienes y/o servicios de tercera parte. Se debe observar también que con el objeto de obtener una ficha de red, lo anterior indica que el aparato de computadora cliente o del ordenador 710 ha determinado en forma exitosa el punto de extremo de la red para el servidor de autentificación 715 y/o infraestructura móvil 720. Además indica que el cliente 710 y el usuario (no mostrado) han sido autentificados con el aparato SIM 705. Tal como se describió anteriormente, la ficha de nivel de seguridad de la red 745 se utiliza en fases de autentificación subsecuentes y proporciona una seguridad de nivel de transporte para encriptar y firmar interacciones adicionales entre el cliente 710 y el servidor confiable 715. El tiempo de vida de la ficha de la red 745 (y otras fichas) es controlado por el servidor de autentificación 715 o el operador móvil 720. Debido a que la ficha de la red 745 sirve como un contexto de sesión entre el aparato SIM 705 y la infraestructura móvil 720, el tiempo de vida puede estar limitado a horas o días, número de bytes pasados y/o puede únicamente ser válido si el módulo móvil 705 se conecta en forma adecuada al cliente 710. Tal como se mencionó anteriormente, un nivel de seguridad del usuario indica que un usuario ha sido autentificado con la red (el servidor confiable 715, infraestructura móvil 720, u otro servicio) proporcionando normalmente información almacenada fuera del SIM 705 o aparato de cómputo central 710. Por consiguiente, el nivel de seguridad del usuario junto con el nivel de seguridad de la red establecen una autenticación de factor múltiple con base en una prueba de posición del SIM 705 y algún conocimiento exterior (por ejemplo, nombre de usuario/contraseña). Normalmente, el servidor confiable 715 o la infraestructura móvil 720 son los únicos componentes para emitir una seguridad de nivel de usuario, sin embargo, en algunos casos un servicio de tercera parte también puede emitir dichas fichas del usuario. Por consiguiente, la infraestructura móvil 720 (u otro servicio según sea el caso) verificarán a un usuarió a través de un mecanismo de respuesta de cuestionamiento antes de emitir una ficha de nivel de seguridad del usuario de regreso al cliente 710. Se debe observar que la ficha de seguridad del usuario es utilizada por el cliente para firmar y/o encriptar solicitudes de fichas de servicio, tal como se describe más adelante. Puede no ser recomendado que el cliente envíe una ficha de seguridad del usuario a cualquier servicio además del servidor confiable (ya que normalmente no estará disponible otro servicio para verificarse/utilizarse). Como con la ficha de red anterior 745, la ficha del usuario puede tener un tiempo de vida limitado controlado por el operador móvil 720, y puede limitarse por la duración de tiempo, el número de bytes pasados y/o por la existencia de la conexión entre el módulo móvil 705 y el cliente 710. La figura 7B, ilustra una red independiente 700 configurada para emitir una ficha de seguridad de nivel del usuario para establecer una comunicación segura entre el cliente 710 y un servidor de autentif icación 715. La fase de autentificación de la red del usuario permite al operador móvil 720 (u otro servidor) verificar que una persona conocida está en posición de un aparato conocido 705. El hecho de que el usuario ponga en fase la red en forma efectiva, es una fase de autentificación de dos factores y evita que la red niegue los ataques de servicio distribuidos. Además, protege al usuario, evitando que un aparato SIM 705 robado se utilice en forma inadecuada. El aparato de computadora del ordenador 710 puede emitir una solicitud de una ficha del usuario 765, la cual es enviada a la infraestructura móvil 720 a través del servidor confiable 715. Normalmente, la solicitud 765 estará no firmada cuando sea recibida por el servidor de autentificación/confiable 715, el cual posteriormente firmará y/o encriptará la solicitud antes de enviarla a la infraestructura móvil 720 para validar que la solicitud viene del servidor de autentificación 715. El servidor confiable 715 posteriormente puede solicitar a la infraestructura móvil 720 u operador móvil un cuestionamiento 770, el cual posteriormente se envía al módulo móvil 705. Se debe observar que el cuestionamiento 770 puede generarse utilizando un algoritmo diferente que el cuestionamiento 730 utilizado para autentificar el aparato 705 a la red. El cliente 710 extraerá el cuestionamiento 770 del menaje de la ficha y lo pasará al módulo móvil 705, indicando que esta es una autentificación del usuario. Por consiguiente, el SIM 705 requerirá la credencial(s) del usuario 775 del cliente 710. La computadora del ordenador 710 posteriormente solicitará al usuario 760 una entrada del usuario 780, y la regresará al módulo móvil 705. El SIM 705 o cliente 710 pueden decidir opcionalmente que la entrada del usuario 780 o credencial(s) debe ser encriptada con la clave de seguridad de la red (por ejemplo, la clave(s) de sesión 750 obtenida anteriormente). Utilizando la entrada del usuario 780, el módulo móvil 705 generará una respuesta de cuestionamiento 785 y la regresará al cliente 710, el cual generará y enviará una respuesta de ficha de seguridad de la solicitud, que incluye, por ejemplo, un identif icador SIM, el cuestionamiento 770 y la respuesta del cuestionamiento 785. Normalmente, el cliente 710 requerirá que el módulo móvil 705 firme y/o encripte la respuesta de señal de seguridad de la solicitud con la ficha de seguridad de la red 745, la clave secreta compartida 740 o una clave específica de SIM 705. En forma similar a lo anterior, la respuesta de la ficha de seguridad de la solicitud y la respuesta del cuestionamiento 785 que ahí se encuentra, pueden ser validados utilizando, por ejemplo, el secreto compartido 740, u otra clave específica del módulo móvil 705. Se debe observar, tal como se mencionó anteriormente, que la respuesta de la ficha de seguridad de la solicitud puede o no estar firmada y/o encriptada por la misma clave utilizada para generar la respuesta del cuestionamiento 785. En cualquier caso, si la infraestructura móvil 720 valida la respuesta del cuestionamiento 785 (es decir, las credenciales del usuario proporcionadas en forma adecuada), la infraestructura móvil 720 y/o servidor de autentificación 715 pueden responder generando un mensaje que contienen una ficha de seguridad del usuario 795 con una clave(s) del usuario encriptada, las cuales se firman y/o encriptan utilizando el secreto compartido 740 u otra clave específica del aparato 705. Posteriormente el mensaje puede ser firmado utilizando ya sea la propia ficha de seguridad del servidor de autentificación 715 (por ejemplo, Cert X.509, Cert Kerberos, etc.) o utilizando la ficha de seguridad de la infraestructura móvil 720. El cliente 710 posteriormente puede verificar el mensaje firmado y pasar la clave(s) de sesión del usuario encriptada al SIM 705 para desencriptación. Utilizando el secreto compartido 740 (u otra clave como pueda ser el caso), el módulo móvil 705 puede regresar posteriormente una clave(s) del usuario no encriptada 790 al cliente 710; autentificando de esta forma el usuario para la red 792. El usuario que sirve la fase de autentificación proporciona un mecanismo para el operador de la red móvil 720 para proporcionar autentificación a nombre de los servicios de tercera parte. En forma similar al usuario que conecta un nivel de seguridad, el usuario en la fase de servicio es una fase de autentificación de facto múltiple y evita que la red emita fichas de servicio sin que un usuario 760 haya estado presente durante al menos una fase de la autentificación. Existen normalmente dos modos de operación del servidor de autentificación 715 con respecto a como se emiten las fichas de servicio. Primero, si el usuario 760 ha adquirido previamente una ficha del usuario, el servidor confiable 715 puede considerar al usuario 760 como autentificado y emitir automáticamente una ficha de servicio (siempre que la solicitud de la ficha de servicio sea firmada en forma adecuada ???· la ficha del usuario 790, 795). Por otra parte, si la infraestructura móvil 720 no ha emitido una ficha del usuario 790, 795, el usuario 760 requerirá la autentificación en una forma similar a la señalada anteriormente para solicitar una ficha del usuario 795, 790. La figura 7C, ilustra como las diversas entidades de red se comunican a través de la red independiente 700 cuando se establece una comunicación segura entre un cliente 710 y un servidor de tercera parte 728. Tal como se mencionó anteriormente, el aparato móvil 705 y el usuario 760 pueden autentificar al sistema de operador móvil 720 tal como se describió anteriormente. Por consiguiente, existe una comunicación segura entre el servidor de autentificación 715 y el cliente 710 al momento de la validación adecuada de una cuenta de facturación del aparato móvil 705 y una autentificación de la posición del mismo por parte del usuario 760. El servidor confiable 715 (o infraestructura móvil 720 según sea el caso) puede emitir posteriormente fichas de servicio 724 para varios servicios cuando, por ejemplo,' el cliente 710 desee comprar servicios y/o bienes de un servicio de tercera parte 728. Por consiguiente, el cliente 710 puede emitir una ficha de servicio 726 al servidor de tercera parte, el cual posteriormente valida la ficha 722 a través del servidor de autentificación 715. Se debe observar que el servidor de tercera parte 728 puede o no requerir autentificación adicional y puede utilizar varios mecanismos tal como se describió anteriormente para llevar a cabo dicha validación. También se debe observar que el uso de la ficha de servicio 726 no únicamente establece una comunicación segura entre el cliente 710 y un servidor de tercera parte 728, sino también indica la capacidad que tiene el usuario 760 de pagar por uno o más de los bienes y/o servicios en una forma similar a la descrita anteriormente. Se debe observar que normalmente hasta que se emite la ficha de servicio del cliente 710, las fichas de seguridad emitidas no tienen valor para cualquier otro servicio que no sea el servidor de autentificación 715. La razón es que la jerarquía de seguridad puede evitar que cualquier parte externa descodifique en forma adecuada una ficha del aparato, una ficha de la red o incluso una ficha del usuario, ya que todas se derivan de la clave raíz o compartida 740 conocida únicamente para el aparato SIM 705 y la infraestructura móvil 720. Normalmente después de que el servidor de autentificacion 715 emite una ficha de servicio 724 es que el servicio web de una tercera parte arbitraria 728 puede hacer uso de la ficha de seguridad 724. También se debe observar que las fichas y menajes de seguridad anteriores (por ejemplo, cuestionamientos, respuestas de cuestionamiento, etc.) pueden tomarse en varios formatos o esquemas. Por ejemplo, las fichas y/o mensajes pueden estar en un formato XML, binario u otro formato de codificación similar, el cual será emitido por el operador móvil 720 quien puede o no desear exponer ciertos elementos de la red para comunicaciones SIM con partes intermediarias. El uso anterior de un aparato de hardware portátil 705 para validación de autentificacion, identidad y/o pago se puede utilizar para comprar bienes y/o servicios al menudeo en línea o locales (por ejemplo, periódicos en línea, música, aplicación de software u otros bienes y servicios) o para permitir acceso a una aplicación que corre en la PC local o cliente 710 (por ejemplo, Word®, Adobe Photoshop, Print program, el software de se paga por lo que se obtiene, etc.). Por consiguiente, las modalidades anteriores son especialmente convenientes para abrir un software o contenido protegido distribuido en forma gratuita (por ejemplo, música, videos, juegos, etc.) en una pluralidad de aparatos de ordenador 710. En otras palabras,' la licencia ahora queda sujeta al aparato móvil portátil 705, el cual puede ser autentificado tal como se describió anteriormente permitiendo que una identidad digital portátil no este sujeta a un grupo limitado de aparatos de cómputo. Por lo tanto un usuario 760 puede ir a casa de un amigo y no llevar todos sus programas u otro contenido protegido; todo está accesible y autentificado a través del aparato portátil 705. Se deberá apreciar a partir de lo anterior, que existen numerosos aspectos de la presente invención aquí descritos que pueden ser utilizados en forma independiente entre .si, incluyendo los aspectos que se relacionan con fichas de identidad, fichas de pago, selección de uno de un número de proveedores de identidad, selección de uno de un número de proveedores de pago y la presencia de un software de transacción comercial en el sistema del usuario final, un sistema de proveedor de servicio, un sistema de proveedor de identidad y un sistema de proveedor de pago. También se debe apreciar que en algunas modalidades, todas las características antes descritas se pueden utilizar juntas, o cualquier combinación o subgrupo de las características descritas anteriormente pueden ser empleadas juntas en una implementación particular, ya que los aspectos de la presente invención no se limitan a este respecto. Las modalidades antes descritas de la presente invención pueden ser implementadas en cualquier número de formas. Por ejemplo, las modalidades pueden ser implementadas utilizando un hardware, software o una combinación de los mismos. Cuando se implementan en un software, el código de software puede ser ejecutado en cualquier procesador o recolección de procesadores adecuado, ya sea que se proporcione en una computadora simple o se distribuya entre múltiples computadoras. Se deberá apreciar que cualquier componente o recolección de componentes que lleve a cabo las funciones descritas anteriormente, puede ser considerada en forma genérica como uno o más controladores que controlan las funciones antes descritas. El uno o más controladores pueden ser implementados en numerosas formas, tal como con un hardware dedicado, o con un hardware de propósitos generales (por ejemplo, uno o más procesadores) que son programados utilizando micro-códigos o un software para llevar a cabo las funciones mencionadas anteriormente. Se deberá apreciar que varios métodos aquí señalados pueden ser codificados como un software que se puede ejecutar en uno o más procesadores que emplean cualquiera de una variedad de sistemas o plataformas de operación. Además, dicho software puede ser escrito utilizando cualquiera de un número de lenguajes de programación adecuados y/o herramientas de programación o escritura convencionales, y también pueden ser compilados como un código de lenguaje de máquina ejecutable. A este respecto, se deberá apreciar que una modalidad de la presente invención se dirige a un medio legible en computadora o a múltiples medios legibles en computadora (por ejemplo, una memoria de computadora, uno o más discos flexibles, discos compactos, discos ópticos, cintas magnéticas, etc.) codificados con uno o más programas que, cuando se ejecutan, una o más computadoras u otros procesadores, llevan a cabo métodos que implementan las diversas modalidades de la presente invención descrita anteriormente. El medio o medios legibles en computadora pueden ser portátiles, de modo que el programa o programas almacenados en el aparato puedan ser cargados en una o más diferentes computadoras u otros procesadores para implementar varios aspectos de la presente invención, tal como se describió anteriormente. Deberá quedar entendido que el término "programa" se utiliza en la presente invención en un sentido genérico para referirse a cualquier tipo de código de computadora o conjunto de instrucciones que pueden ser empleadas para programar una computadora u otro procesador para implementar varios aspectos de la presente invención, tal como se describió anteriormente. Además, se deberá apreciar que de acuerdo con el aspecto de esta modalidad, uno o más programas de computadora, los cuales cuando son ejecutados, llevan a cabo métodos de la presente invención, no necesitan residir en una computadora o procesador simple, sino pueden ser distribuidos en una forma modular entre un número de diferentes computadoras o procesadores para implementar varios aspectos de la presente invención. Varios aspectos de la presente invención se pueden utilizar solos, en combinación o en una variedad de arreglos no descritos de manera específica en las modalidades descritas anteriormente, y los aspectos de la presente invención aquí descritos no se limitan en su aplicación a los detalles y ajustes de los componentes establecidos en la descripción anterior o ilustrados en los dibujos. Los aspectos de la presente invención tienen la capacidad de otras modalidades y de ser practicados o llevados a cabo en varias formas. Varios aspectos de la presente invención pueden ser implementados en relación con cualquier tipo de red, agrupación o configuración. No se imponen limitaciones en la implementación de la red. Por consiguiente, la descripción y los dibujos anteriores son únicamente a manera de ejemplo. El uso de términos ordinales tales como "primero", "segundo", "tercero", etc., en las reivindicaciones que modifican un elemento de reivindicación, no connotan propiamente cualquier prioridad, precedencia u orden de un elemento de reivindicación con respecto a otro o el orden temporal en el cual se llevan a cabo las acciones de un método, sino se utilizan meramente como etiquetas para distinguir un elemento de reivindicación que tiene cierto nombre de otro elemento que tiene el mismo nombre (pero para el uso del término ordinal) para distinguir los elementos de las reivindicaciones. Así mismo, la fraseología y terminología utilizada en la presente invención es con el propósito de descripción y no debe considerarse como una limitación. El uso de los términos "que incluye", "que comprende" o "que tiene", "que contiene" "que implica" y variaciones de las mismas en la presente invención, se entiende que comprende objetos descritos posteriormente y equivalentes de los mismos, así como objetos adicionales.

Claims (1)

  1. REIVINDICACIONES 1. Un método para autorizar una transacción en línea entre un comprador y un comerciante, en donde el método comprende las acciones de: proporcionar, a través de un proveedor de identidad, la verificación de una identidad del comprador; y proporcionar, a través del proveedor de pago, la verificación de una habilidad del comprador para pagar por la transacción, en donde el proveedor de identidad y el proveedor de pago son diferentes entidades de red. 2. El método tal como se describe en la reivindicación 1, caracterizado porque comprende además la acción de proporcionar, a través del comprador, información de identificación para facilitar al proveedor de identidad , la verificación de la identidad del comprador. 3. El método tal como se describe en la reivindicación 2, caracterizado porque la acción de proporcionar la información de identificación incluye la acción de proporcionar un número de módulo de identidad del subscriptor (SIM), una dirección de red o una identificación de hardware única (ID). 4. El método tal como se describe en la reivindicación 2, caracterizado porque la acción de proporcionar la información de identificación incluye proporcionar información de identificación en forma programada, a través de una computadora del usuario final asociada con el comprador, la información de identificación es proporcionada en una indicación a través de al menos una aplicación que opera en la computadora del usuario final de que el comprador pretende realizar una compra. 5. El método tal como se describe en la reivindicación 1, caracterizado porque la acción de proporcionar la verificación de la capacidad de pago del comprador se lleva a cabo a través del proveedor de pago únicamente después de que se ha verificado la identidad del comprador. 6. El método tal como se describe en la reivindicación 5, caracterizado porque el proveedor de pago emplea la verificación de identidad para llevar a cabo la verificación del pago. 7. El método tal como se describe en la reivindicación 1, caracterizado porque el proveedor de identidad es un banco o una agencia de gobierno. 8. El método tal como se describe en la reivindicación' 1, caracterizado porque el proveedor de identificación, proporciona verificación de identificación a través de una ficha de identidad que será recibida por el proveedor de pago, y en donde el proveedor de pago proporciona verificación de pago a través de una ficha de pago que será recibida por el comerciante. 9. El método tal como se describe en la reivindicación 8, caracterizado porque la ficha de identidad incluye un intervalo de tiempo predeterminado durante el cual se puede procesar la ficha de identidad, en donde, cuando el intervalo de tiempo predeterminado expira, se considera inválida la ficha de identidad . 10. El método tal como se describe en la reivindicación. 8, caracterizado porque la ficha de pago incluye un intervalo predeterminado del tiempo durante el cual se puede procesar la ficha de pago, en donde, cuando el intervalo de tiempo predeterminado expira, la ficha de pago se considera inválida. 11. Un sistema de cómputo que tiene una pluralidad de nodos interconectados a través de una red, en donde el sistema de cómputo está adaptado para llevar a cabo una transacción en línea entre un comprador y un comerciante, en donde el sistema de cómputo comprende: un primer nodo configurado para proporcionar verificación de una identidad del comprador; y un segundo nodo configurado para proporcionar verificación de la capacidad que tiene el comprador para pagar por la transacción, en donde el primer nodo y el segundo nodo están asociados con diferentes entidades de red. 12. El sistema de computadora tal como se describe en la reivindicación 11, caracterizado porque comprende además. un nodo de comprador asociado con el comprador, estando adaptado el nodo del comprador para proporcionar información de identificación para facilitar al primer nodo la verificación de la identidad del comprador. 13. El sistema de computadora tal como se describe en la reivindicación 12, caracterizado porque el nodo del comprador proporciona un número de módulo de identidad del subscriptor (SIM), una dirección de red, o una identificación de hardware única como la información de identificación. 14. El sistema de computadora tal como se describe en la reivindicación 12, caracterizado porque el nodo del comprador incluye una computadora de usuario final que proporciona la información de identificación en forma programada, cuando se emite una señal para iniciar la transacción a través de al menos una aplicación que opera en la computadora del usuario final. 15. El sistema de computadora tal como se describe en la reivindicación 11, caracterizado porque el segundo nodo proporciona verificación de la capacidad que tiene el comprador para pagar únicamente después de que el primer nodo verifica la identidad del comprador. 16. El sistema de computadora tal como se describe en la reivindicación 15, caracterizado porque el segundo nodo emplea la verificación de identidad para llevar a cabo la verificación del pago. 17. El sistema de computadora tal como se describe en la reivindicación 11, caracterizado porque el primer nodo está asociado con una entidad de red que es un banco o una agencia de gobierno. 18. El sistema de computadora tal como se describe en la reivindicación 11, caracterizado porque el primer nodo proporciona verificación de identificación a través de una ficha de identidad que será recibida por el segundo nodo, y en donde el segundo nodo proporciona verificación de pago a través de una ficha de pagó que será recibida por el comerciante. 19. El sistema de computadora tal como se describe en la reivindicación 18, caracterizado porque la ficha de identidad incluye un intervalo de tiempo predeterminado durante el cual se puede procesar la ficha de identidad, en donde cuando expira el intervalo de tiempo predeterminado, la ficha ,de identidad se considera inválida. 20. El sistema de computadora tal como se describe en la reivindicación 18, caracterizado porque la ficha de pago incluye un intervalo de tiempo predeterminado durante el cual se puede procesar la ficha de pago, en donde cuando expira el intervalo de tiempo predeterminado, la ficha de pago se considera inválida. 21. Un programa distribuido para llevar a cabo transacciones en línea, en donde el programa tiene una pluralidad de componentes de software distribuidos a través de un sistema de cómputo que tiene una pluralidad de nodos interconectados a través de una red, en donde cada pluralidad de componentes está configurada para comunicarse a través de la red con al menos otra de la pluralidad de componentes de software, en donde el programa distribuido comprende: un primer componente instalado en un primer nodo del cual el usuario final accesa a la red, en donde el primer componente está adaptado para proporcionar un identificador a través de la red en respuesta a una indicación para llevar a cabo una transacción entre el usuario final y un comerciante, en donde el identificador está asociado con el usuario final y/o primer nodo; al menos un segundo componente del programa distribuido instalado en al menos un segundo nodo, estando configurado el al menos un segundo componente para recibir el identificador y proporcionar la verificación de la capacidad que tiene un usuario final para pagar por la transacción; y un tercer componente del programa distribuido instalado en un tercer nodo asociado con el comerciante, estando configurado el tercer componente para recibir la verificación de la capacidad que tiene el usuario final para pagar antes de proceder con la transacción en línea. 22. El programa distribuido tal como se describe en la reivindicación 21, caracterizado porque el al menos un segundo componente comprende: un componente de identificación del programa distribuido instalado en un nodo identificador asociado con al menos un proveedor de identidad, estando configurado el componente de identificación para recibir el identificador y proporcionar una ficha de identidad que verifica la identidad del usuario final con base en el identificador; y un componente de pago del programa distribuido instalado en un nodo de pago asociado con al menos un proveedor de pago, estando configurado el componente de pago para recibir la ficha de identidad y proporcionar una ficha de pago con base en la ficha de identidad, en donde la ficha de pago incluye la verificación de la capacidad que tiene para pagar el usuario final . 23. Un sistema de computadora que tiene una pluralidad de nodos interconectados a través de una red, en donde' el sistema de cómputo está adaptado para facilitar una transacción en línea entre un comprador y un comerciante que proporciona uno o más bienes, servicios o ambos, en donde el sistema de cómputo comprende: un primer aparato de red asociado con el comprador, estando adaptado el primer aparato de red para emitir en forma programada información de identificación indicativa del comprador al momento de una indicación de que el comprador inicia la transacción, en donde la información de identificación no es una contraseña establecida por el comprador; y un segundo aparato de red asociado con un proveedor de identidad, estando adaptado el segundo aparato de red para recibir la información de identificación y emitir una ficha de identidad que verifica la identidad del comprador para la transacción . 24. Un método para autorizar una transacción en línea entre un comprador y un comerciante, en donde el método comprende las acciones de: generar una ficha de identidad que proporciona verificación de una identidad del comprador, con base en la información de identificación además de una contraseña establecida por el comprador; y generar una ficha de pago que proporciona la verificación de la capacidad que tiene el comprador de pagar por la transacción. 25. En un aparato de cómputo en un ambiente de red distribuido, un método para autentificar un módulo móvil de. un aparato portátil que está sujeto a una cuenta de facturación de una infraestructura móvil con el objeto de permitir al usuario accesar a bienes, servicios o ambos, validando el módulo móvil a través de una red independiente de la red de radio de la infraestructura móvil, en donde el método comprende los pasos de: recibir una solicitud de autentificación de un módulo móvil, cuando se intenta obtener acceso a bienes, servicios o ambos; recibir una o más credenciales del módulo móvil utilizado por una infraestructura móvil en la validación de la información de la fuente de facturación del mismo; enviar la una o más credenciales a la infraestructura móvil a través de una red independiente separada de la red de radio de infraestructura móvil; y recibir a través de la red independiente, información de autentificación que corresponde a un estado de activación de la cuenta de facturación del módulo móvil que se encuentra en la infraestructura móvil, permitiendo de esta forma que una identidad digital portátil controle el acceso a los bienes, servicios o ambos. 26. El método tal como se describe en la reivindicación 25, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM) de la infraestructura móvil, y en donde la una o más credenciales incluyen información con base en un cuestionamiento de la infraestructura móvil y una clave compartida entre el SIM y la infraestructura móvil. 27. El método tal como se describe en la reivindicación 26, caracterizado porque el SIM está incluido dentro de una pieza del hardware además de un aparato de transmisión de radio, y está unido al aparato de cómputo a través de uno o más puertos cableados o inalámbricos. 28. El método tal como se describe en la reivindicación 26, caracterizado porque el SIM está unido directamente al aparato de cómputo a través de una conexión de hardware especial diseñada específicamente para el SIM. 29. El método tal como se describe en la reivindicación 25, caracterizado porque los bienes, servicios o ambos, son requeridos de un servicio remoto conectado a la red independiente. 30. El método tal como se describe en la reivindicación 29, caracterizado porque la red independiente incluye la Internet. 31. El método tal como se describe en la reivindicación 30, caracterizado porque los bienes, servicios o ambos, se distribuyen gratuitamente a través de la Internet y residen en un aparato de cómputo local, y en donde la autentificación del módulo móvil permite que los contenidos de los bienes, servicios o ambos , sean abiertos en el aparato de cómputo local . 32. El método tal como se describe en la reivindicación 25, caracterizado porque los bienes, servicios o ambos son uno o más de: un programa de software en el aparato de cómputo; una pieza de hardware unida al aparato de cómputo; contenido de multimedia para el consumo por parte del aparato de cómputo; o acceso al propio aparato de cómputo. 33. El método tal como se describe en la reivindicación 32, caracterizado porque los bienes, servicios o ambos, tienen múltiples niveles de acceso disponible, y en donde, con base en la autentificación del aparato móvil, se activan uno o más de los niveles disponibles. 34. El método tal como se describe en la reivindicación 25, caracterizado porque el método comprende además: con base en el estado de activación del módulo móvil, determinar si un convenido de contrato elaborado entre un comerciante por los bienes, servicios, o ambos, y la infraestructura móvil requiere que el usuario ingrese una o más credenciales de entrada del usuario para autentificar al mismo, en donde si esto es real, el método incluye además: enviar una solicitud al usuario para que ingrese la una o más credenciales de entrada del usuario; y con base en la entrada del usuario, determinar si el usuario está autorizado para accesar el servicio protegido. 35. El método tal como se describe en la reivindicación 34, caracterizado porque las credencias de entrada del usuario se almacenan en uno o más del módulo móvil, la infraestructura móvil, o un servidor que corresponde al comerciante. 36. El método tal como se describe en la reivindicación 25, caracterizado porque si el módulo móvil no es autentificado por la infraestructura móvil, el método comprende además: recibir a través de la red independiente un mensaje de desactivación para desactivar el módulo móvil. 37. En una infraestructura móvil en un ambiente de red distribuido, un método para autentificar un módulo móvil de un aparato portátil que está sujeto a una cuenta de facturación de la infraestructura móvil, con el objeto de permitir el acceso de un usuario a bienes, servicios, o ambos, validando el módulo móvil a través de una red independiente de la red de radio de la infraestructura móvil, el método comprende: recibir una solicitud para autentificar un módulo móvil cuando un usuario esté intentando tener acceso a los bienes, servicios, o ambos, en donde el módulo móvil corresponde a una cuenta de facturación de una infraestructura móvil, y en donde la solicitud es recibida a través de una red independiente separada de la red de radio de la infraestructura móvil; recibir a través de la red independiente una o más credenciales del módulo móvil; y con base en la validación de la una o más credenciales, enviar a través de la red independiente, información de autentificación que corresponde a un estado de activación de la cuenta de facturación del módulo móvil, permitiendo de esta forma una identidad digital portátil para controlar el acceso a los bienes, servicios, o ambos, a través de dos redes independientes. 38. El método tal como se describe en la reivindicación 37, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM) para la infraestructura móvil, y en donde el método incluye además: enviar un cuestionamiento al aparato SIM a través de la red independiente; recibir una respuesta que incluye la una o más credenciales, que corresponden a la información dentro del cuestionamiento y una clave compartida entre el SIM y la infraestructura móvil; y con base en la respuesta del cuestionamiento, autentificar el estado de activación del SIM de acuerdo con la información de la cuenta de facturación. 39. El método tal como se describe en la reivindicación 38, caracterizado porque la solicitud, la una o más credenciales, y la información de autentificación es enrrutada a la infraestructura móvil a través de un servidor confiable y en donde la autentificación establece una comunicación confiable entre el SIM y el servidor confiable. 40. El método tal como se describe en la reivindicación 38, caracterizado porque el SIM es parte del aparato que ??· se puede comunicar a través de la red de radio de la infraestructura móvil. 41. El método tal como se describe en la reivindicación 37, caracterizado porque los servicios, bienes, o ambos, son requeridos de un servicio remoto conectado a la red independiente. 42. El método tal como se describe en la reivindicación 37, caracterizado porque la red independiente incluye la Internet. 43. El método tal como se describe en la reivindicación 42, caracterizado porque los bienes, servicios, o ambos son distribuidos libremente a través de la Internet y residen en un aparato de cómputo local, y en donde la autentificación del módulo móvil permite que los contenidos de los bienes, servicios, o ambos, sean abiertos en un aparato de cómputo local. 44. El método tal como se describe en la reivindicación 37, caracterizado porque los bienes, servicios, o ambos, son uno o más de: un programa de software en un aparato de cómputo; una pieza de hardware unida al aparato de cómputo; contenido multimedia para el consumo a través del aparato de cómputo; o acceso al propio sistema de cómputo. 45. El método tal como se describe en la reivindicación 37, caracterizado porque el método comprende además: con base en el estado de activación del módulo móvil, determinar si un convenido de contrato elaborado entre un comerciante por los bienes, servicios, o ambos, y la infraestructura móvil requiere que un usuario ingrese una o más credenciales de entrada del usuario para autentificarse, en donde si esto es real el método incluye además: enviar una solicitud al módulo móvil para solicitar al usuario la entrada de la una o más credenciales de entrada del mismo; y con base en la entrada del usuario, determinar si el usuario está autorizado para tener acceso al servicio protegido. 46. El método tal como se describe en la reivindicación 34, caracterizado porque las credenciales de entrada del usuario se almacenan en uno o más del módulo móvil, la infraestructura móvil o un servidor que corresponde al comerciante. 47. El método tal como se describe en la reivindicación 37, caracterizado porque si el módulo móvil no es autentificado por la infraestructura móvil, el método comprende además: enviar un mensaje de desactivación a través de la red de radio de la infraestructura móvil, la red independiente o ambas, para desactivar el módulo móvil. 48. Un aparato portátil utilizado para hacer interfase con un módulo móvil con una máquina de cómputo local utilizada para autentificar el módulo móvil como teniendo una cuenta de facturación válida para una infraestructura móvil con el objeto de permitir a un usuario el acceso a bienes, servicios o ambos, el aparato portátil comprende: un portador del caso para asegurar que se mantenga un módulo móvil que tiene una cuenta de facturación con una infraestructura móvil utilizada para validar el módulo móvil cuando se intenta obtener acceso a bienes, servicios o ambos, en una máquina de cómputo local; una interfase que permite al aparato portátil: enviar una o más credenciales del módulo móvil al aparato de cómputo local para autentificar el módulo móvil con la infraestructura móvil; y recibir información de autentificación del aparato de cómputo local que valida un estado para la cuenta de facturación, en donde la interfase permite enviar y recibir información a través de una red independiente separada de la red de radio de infraestructura móvil, permitiendo de esta forma que una identidad digital portátil controle el acceso a los bienes, servicios o ambos, a través de dos redes independientes. 49. El aparato portátil tal como se describe en la reivindicación 48, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM) de la infraestructura móvil, y en donde la una o más credenciales incluyen información con base en un cuestionamiento de ' la infraestructura móvil y una clave compartida entre el SIM y la infraestructura móvil. 50. El aparato portátil tal como se describe en la reivindicación 49, caracterizado porque el portador del caso es una pieza del hardware además de un aparato de transmisión de radio, y está unido al aparato de cómputo a través de uno o más puertos cableados o inalámbricos. 51. El aparato portátil tal como se describe en la reivindicación 49, caracterizado porque la red independiente incluye la I nternet. 52. El aparato portátil tal como se describe en la reivindicación 49, caracterizado porque los bienes, servicios o ambos, se distribuyen gratuitamente a través de la Internet y residen en un aparato de cómputo local, y en donde la autentificación del módulo móvil permite que los contenidos de los bienes, servicios o ambos, sean abiertos en el aparato de cómputo local. 53. El aparato portátil tal como se describe en la reivindicación 49, caracterizado porque los bienes, servicios o ambos son uno o más de: un programa de software en el aparato de cómputo; una pieza de hardware unida al aparato de cómputo; contenido de multimedia para el consumo por parte del aparato de cómputo; o acceso al propio aparato de cómputo. 54. El aparato portátil tal como se describe en la reivindicación 53, caracterizado porque los bienes, servicios o ambos, tienen múltiples niveles de acceso disponible, y en donde, con base en la autentificación del aparato móvil, se activan uno o más de los niveles disponibles. 55. El aparato portátil tal como se describe en la reivindicación 49, caracterizado porque la interfase se utiliza además para recibir credenciales del usuario para validar al usuario. 56. El aparato portátil tal como se describe en la reivindicación 55, caracterizado porque las credenciales de entrada del usuario se almacenan en uno o más del módulo móvil, la infraestructura móvil o un servidor que corresponde al comerciante. 57. En un aparato de cómputo en un ambiente de red distribuido, un método para permitir el acceso a bienes, servicios o ambos, distribuidos gratuitamente, en un aparato de cómputo configurado para autentificar un aparato portátil como estando sujeto a una cuenta de facturación de una infraestructura móvil a través de una red independiente de la red de radio de la infraestructura móvil, en donde el método comprende: recibir en un aparato de cómputo local uno o más bienes, servicios o ambos distribuidos gratuitamente, que incluye contenido protegido que únicamente los aparatos de cómputo autorizados se les permite el acceso; recibir una o más credenciales de un módulo móvil utilizado por una infraestructura móvil para validar la información de la cuenta de facturación del mismo; enviar la una o más credenciales a la infraestructura móvil a través de una red independiente separada de la red de radio de infraestructura móvil; recibir a través de la red independiente, información de autentificación que corresponde a un estado de activación de la cuenta de facturación del módulo móvil en la infraestructura móvil; y con base en la información de autentificación, recibir una licencia que permita al aparato de cómputo local tener acceso al menos a una parte del contenido protegido, permitiendo de esta forma que una identidad digital portátil tenga acceso a Jos bienes, servicios o ambos, en una pluralidad de diferentes aparatos de cómputo sin restringir un número de aparatos-de cómputo con licencia para tener acceso al contenido protegido. 58. El método tal como se describe en la reivindicación 57, caracterizado porque los bienes, servicios o ambos distribuidos gratuitamente, son recibidos a través de la red independiente o comprados en una tienda e instalados directamente en el aparato de cómputo local. 59. El método tal como se describe en la reivindicación 57, caracterizado porque la licencia está limitada en tiempo de vida, si el aparato móvil está conectado al mecanismo de cómputo local, o ambos. 60. El método tal como se describe en la reivindicación 57, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM) para la infraestructura móvil, y en donde la una o más credenciales incluyen información con base en un cuestionamiento de la infraestructura móvil y una clave compartida entre el SIM y la infraestructura móvil. 61. El método tal como se describe en la reivindicación 57, caracterizado porque el SIM está incluido dentro de una pieza del hardware además de un aparato de transmisión de radio y está unido al aparato de cómputo a través de uno o más puertos cableados o inalámbricos. 62. El método tal como se describe en la reivindicación 57, caracterizado porque el SIM está unido directamente al aparato de cómputo local a través de una conexión de hardware especial diseñada específicamente para el SIM. 63. El método tal como se describe en la reivindicación 57, caracterizado porque los bienes, servicios o ambos, son requeridos de un servicio remoto conectado a la red independiente. 64. El método tal como se describe en la reivindicación 57, caracterizado porque la red independiente incluye la Internet. 65. El método tal como se describe en la reivindicación 57, caracterizado porque los bienes, servicios o ambos son uno o más de: un programa de software en el aparato de cómputo local; una pieza de hardware adherido al aparato de cómputo local; o contenido multimedia para el consumo por parte del aparato de cómputo local. 66. El método tal como se describe en la reivindicación 57, caracterizado porque los bienes, servicios o ambos, tienen múltiples niveles de acceso disponible, y en donde con base en la licencia se activan uno o más de los niveles disponibles. 67. En un sistema de cómputo sujeto a una red distribuida, un método para utilizar un aparato de hardware portátil simple para permitir acceso a bienes, servicios o ambos protegidos, que requieren ya sea un autentif icador de factor simple o de factor múltiple, en donde el método comprende. enviar una o más credenciales de un módulo móvil a un aparato de cómputo local que requiere acceso a los bienes, servicios o ambos protegidos, con el objeto de permitir que el aparato de cómputo local tenga acceso a los mismos, si el módulo móvil tiene una cuenta de facturación activa con una infraestructura móvil, la cual está configurada también para autentificar a un usuario en un proceso de factor múltiple, y en donde la una o más credenciales del módulo móvil son enviadas a través de una red independiente separada de la red de radio de la infraestructura móvil; recibir, del aparato de cómputo local, información de autentificación que corresponde a un estado de activación de la cuenta de facturación del módulo móvil; y con base en la información de autentificación, determinar si los bienes, servicios o ambos protegidos, requieren además autentificación del usuario, en donde si esto es real el método comprende además: enviar una solicitud de una o más credenciales de entrada del usuario para comparación con una versión almacenada en forma segura de las mismas; y con base en la información con respecto a la comparación, determinar si el usuario está autorizado para tener acceso a los bienes, servicios o ambos protegidos. 68. El método tal como se describe en la reivindicación 67, caracterizado porque la una o más credenciales de entrada del usuario son encriptadas utilizando una clave compartida entre el módulo móvil y la infraestructura móvil, en donde el método comprende además: enviar las una o más credenciales de entrada del usuario encriptadas al aparato de cómputo local para transferir a la infraestructura móvil a través de la red independiente para la comparación de las mismas; recibir la información con respecto a la comparación que indica que el usuario está autentificado en forma adecuada con la infraestructura móvil; y enviar una licencia al aparato de cómputo local que permite al usuario tener acceso a bienes, servicios o ambos protegidos. 69. El método tal como se describe en la reivindicación 68, caracterizado porque la licencia está limitada con base en: tiempo de vida, la proximidad del módulo móvil al aparato de cómputo local, o ambos, y en donde al momento de la expiración de la licencia el usuario y el módulo móvil son requeridos de volverse a autentificar con la infraestructura móvil con el objeto de tener acceso adicional a los bienes, servicios o ambos protegidos. 70. El método tal como se describe en la reivindicación 68, caracterizado porque la una o más credenciales de entrada del usuario son específicas del comerciante, de los bienes, servicios o ambos, y en donde el comerciante tiene una relación transaccional confiable con la infraestructura móvil que indica que la una o más credenciales del usuario son necesarias con propósitos de autentificación . 71. El método tal como se describe en la reivindicación 68, caracterizado porque los bienes, servicios o ambos protegidos, corresponden a una aplicación que corre en el aparato de cómputo local conectado al módulo móvil. 72. El método tal como se describe en la reivindicación 67, caracterizado porque los bienes, servicios o ambos protegidos, corresponden a una aplicación que corre en el aparato de cómputo local conectado al módulo móvil, y en donde la una o más credenciales de entrada del usuario se almacenan en el aparato de cómputo local. 73. El método tal como se describe en la reivindicación 67, caracterizado porque los bienes, servicios o ambos protegidos, se controlan en forma remota a través de un servicio en el sistema distribuido, y en donde la una o más credenciales de entrada del usuario se almacenan en un servidor remoto. 74. El método tal como se describe en la reivindicación 67, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM), y en donde la una o más credenciales son determinadas con base en un cuestionamiento de la infraestructura móvil y una clave compartida entre el aparato SIM y la infraestructura móvil. 75. El método tal como se describe en la reivindicación 74, caracterizado porque el SIM está incluido dentro de una pieza del hardware además del aparato de transmisión de radio, y está unido al aparato de cómputo a través de uno o más puertos cableados o inalámbricos. 76. El método tal como se describe en la reivindicación 74, caracterizado porque el SIM está unido directamente' al aparato de cómputo local a través de una conexión de hardware especial diseñada específicamente para el SIM. 77. El método tal como se describe en la reivindicación 67, caracterizado porque los bienes, servicios o ambos son uno o más de: un programa de software en el aparato de cómputo local; una pieza de hardware unida al aparato de cómputo local; o un contenido multimedia para el consumo por parte del aparato de cómputo local. 78. En una infraestructura móvil unida a una red distribuida, un método para utilizar un aparato de hardware portátil simple para permitir el acceso a bienes, servicios o ambos protegidos, que requieren una autentificación ya sea de factor simple o factor múltiple, en donde el método comprende: recibir una o más credenciales de un módulo móvil que indica una solicitud para tener acceso a bienes, servicios o ambos protegidos, con el objeto de permitir a un aparato de cómputo local el acceso a los mismos, en donde la una o más credenciales del módulo móvil son recibidas a través de una red independiente separada de la red de radio de la infraestructura móvil; utilizar la una o más credenciales para autentificar el módulo móvil como teniendo una cuenta de facturación activa con la infraestructura móvil, la cual está configurada también para autentificar a un usuario en un proceso de factor múltiple; y determinar si los bienes, servicios o ambos protegidos, requieren además autentificación del usuario, en donde si esto es real el método comprende además: enviar a través de la red independiente, una solicitud de una o más credenciales de entrada del usuario para comparación con la versión almacenada en forma segura de las mismas; recibir la una o más credenciales de entrada del usuario a través de la red independiente, en donde la una o más credenciales de entrada del usuario recibidas son encriptadas utilizando una clave compartida entre el módulo móvil y' la infraestructura móvil, con base en la comparación de las una o más credenciales de entrada del usuario encriptadas con la versión almacenada en forma segura de las mismas, enviar información que indica la autentificación del usuario a la infraestructura móvil que permite la emisión de una licencia para proporcionar al aparato de cómputo local acceso a los bienes, servicios o ambos protegidos. 79. El método tal como se describe en la reivindicación 78, caracterizado porque la licencia está limitada con base en: tiempo de vida, la proximidad del módulo móvil al aparato de cómputo local, o ambos, y en donde al momento de la expiración de la licencia el usuario y el módulo móvil son requeridos de volverse a autentificar con la infraestructura móvil con el objeto de obtener acceso adicional a los bienes, servicios o ambos protegidos. 80. El método tal como se describe en la reivindicación 78, caracterizado porque la una o más credenciales de entrada del usuario son específicas de un comerciante de los bienes, servicios o ambos, y en donde el comerciante tiene una relación transaccional confiable con la infraestructura móvil que indica que la una o más credenciales del usuario son necesarias con propósitos de autentificación. 81. El método tal como se describe en la reivindicación 78, caracterizado porque los bienes, servicios o ambos protegidos, corresponden a una aplicación que corre en el aparato de cómputo local conectado al módulo móvil. 82. El método tal como se describe en la reivindicación 78, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM), y en donde la una o más credenciales son determinadas con base en un cuestionamiento de la infraestructura móvil y una clave compartida entre el aparato SIM y la infraestructura móvil. 83. El método tal como se describe en la reivindicación 82, caracterizado porque la clave compartida para encriptar la una o más credenciales del usuario es diferente a la clave compartida utilizada para las una o más credenciales del módulo móvil. 84. En un sistema distribuido, una infraestructura de cómputo utilizada para abstraer a una computadora central de un sistema de operador móvil cuando se conecta un módulo móvil del mismo con el objeto de etiquetar la computadora del ordenador como un equipo periférico en lugar de como una terminal móvil sujeta a requerimientos estrictos del sistema operador móvil, en donde la estructura de cómputo comprende: un módulo de identidad de subscriptor (SIM) que incluye información asociada con una cuenta de facturación de un sistema de operador móvil; una computadora central que conecta el SIM con el sistema de operador móvil a través de una red independiente de la red de radio del sistema de operador móvil con el objeto de autentificar la información de la cuenta de facturación del SIM; una unidad SIM unida a la computadora central para leer información del SIM para utilizarse en al menos la autentificación del SIM con el sistema de operador móvil a través de la red independiente; y una interfase que actúa como un Sistema Firewall (sistema diseñado para prevenir el acceso ilegal a/o desde una red privada conectada a Internet) entre el SIM y la unidad de SIM que define un protocolo utilizado para proteger el SIM de ataque, restringiendo uno o más de un número, secuencia o longitud de comandos enviados entre la unidad SIM y el SIM. 85. La estructura de cómputo tal como se describe en la reivindicación 84, caracterizada porque el SIM está conectado a la computadora central a través de un puerto de hardware, un puerto inalámbrico o ambos. 86. La estructura de cómputo tal como se describe en la reivindicación 84, caracterizada porque la interfase es parte de un aparato portátil utilizado en la conexión del SIM a la computadora del ordenador. 87. La estructura de cómputo tal como se describe en la reivindicación 86, caracterizada porque el aparato portátil no está configurado para comunicaciones de radio a través de la red del sistema de operador móvil. 88. La estructura de cómputo tal como se describe en la reivindicación 84, caracterizada porque la autentificación del SIM a través de la red independiente se utiliza para obtener acceso al aparato de cómputo del ordenador. 89. La estructura de cómputo tal como se describe en la reivindicación 84, caracterizada porque la autentificación del SIM se utiliza para obtener acceso a bienes, servicios o ambos, ofrecidos a través de la red independiente. 90. La estructura de cómputo tal como se describe en la reivindicación 84, caracterizada porque la autentificación del aparato SIM es para bienes, servicios o ambos, ofrecidos a través de la red independiente y asociados con una aplicación de software que corre en la computadora del ordenador separada de la aplicación de búsqueda en la Web. 91. La estructura de cómputo tal como se describe en la reivindicación 84, caracterizada porque el protocolo incluye una máquina de estados formal que se utiliza para mantener el seguimiento del uno o más del número, secuencia o longitud de comunicaciones entre la unidad SIM y el SIM. 92. En un sistema de cómputo unido a una red distribuida, un método para establecer comunicaciones seguras de nivel de transporte entre un cliente y un servidor a través de una red no segura de otra forma, estableciendo un túnel seguro entre un módulo móvil conectado al cliente y una infraestructura móvil asociada con el mismo con el objeto de delegar las claves de sesión al menos a una pila de software en el cliente para uno o más propósitos de encriptación o firma, en donde el método comprende: identificar una o más credenciales de un módulo móvil conectado a una computadora central; enviar la una o más credenciales a una infraestructura móvil para autentificación de la cuenta de facturación válida del módulo móvil, en donde la solicitud es enviada a través de una red independiente separada de una red de radio que corresponde a la infraestructura móvil; y con base en la autentificación, recibir del módulo móvil una clave de sesión para utilizarse en una comunicación segura de nivel de transporte a través de la red independiente entre la computadora central y un servidor. 93. El método tal como se describe en la reivindicación 92, caracterizado porque el módulo móvil es un módulo de identidad de subscriptor (SIM) para la infraestructura móvil, y en donde la una o más credenciales incluyen información ??? base en un cuestionamiento de la infraestructura móvil y una clave compartida entre el SIM y la infraestructura móvil. 94. El método tal como se describe en la reivindicación 93, caracterizado porque el SIM está incluido dentro de una pieza del hardware además de un aparato de transmisión de radio y está unida al aparato de cómputo a través de uno o más puertos cableados o inalámbricos. 95. El método tal como se describe en la reivindicación 93, caracterizado porque la red independiente incluye la Internet. 96. El método tal como se describe en la reivindicación 93, caracterizado porque el servidor es parte de una estructura que tiene una relación confiable con la infraestructura móvil de modo que las claves de sesión también pasen de la infraestructura móvil al servidor para la comunicación segura de nivel de transporte con la computadora central. 97. El método tal como se describe en la reivindicación 96, caracterizado porque comprende además: solicitar una conexión con el servidor de tercera parte que no es parte de la estructura; recibir otra clave de sesión para la comunicación segura entre la computadora central y el servidor de tercera parte; y utilizar la otra clave de sesión para una comunicación segura de nivel de transporte con el servidor de tercera parte. 98. El método tal como se describe en la reivindicación 97, caracterizado porque antes de utilizar otra clave de sesión para comunicarse con la tercera parte, el método comprende además: enviar la otra clave de sesión y ficha al servidor de tercera parte, en donde el servidor de tercera parte valida la otra clave de sesión, autentificando la ficha a través del servidor confiable que es parte de la infraestructura; y con base en la autentificación de la ficha, utilizar la otra clave de sesión para asegurar la comunicación con el servidor de tercera parte. 99. El método tal como se describe en la reivindicación 98, caracterizado porque el servidor de tercera parte es un comerciante de bienes, servicios o ambos, y en donde el usuario también debe autentificar al servidor de tercera parte proporcionado credenciales de entrada de usuario. 100. El método tal como se describe en la reivindicación 99, caracterizado porque la autentificación del SIM con la infraestructura móvil, a través de la validación de la cuenta de facturación de la misma, se utiliza como una verificación de los fondos de pago de los bienes, servicios o ambos, cuando se realiza una compra del comerciante. 101. El método tal como se describe en la reivindicación 93, caracterizado porque la clave de sesión expira con base en una o más de tiempo de vida de la clave de sesión o un número de mensajes encriptados, firmados o ambos, con la clave de sesión, mediante lo cual se requiere la expiración del SIM para volver a autorizar a través de la infraestructura móvil la comunicación segura adicional entre la computadora central y el servidor. 102. El método tal como se describe en la reivindicación 93, caracterizado porque el SIM se conecta en forma externa a la computadora central, que está mantenido aún dentro de una proximidad cercana física a la misma. 103. El método tal como se describe en la reivindicación 102, caracterizado porque la proximidad cercana física es en 9.14 m (10 yardas). 104. El método tal como se describe en la reivindicación 103, caracterizado porque la conexión externa es una conexión inalámbrica. 105. El método tal como se describe en la reivindicación 93, caracterizado porque la clave de sesión se deriva del SIM y la infraestructura móvil con base en el secreto compartido entre el SIM y la infraestructura móvil. 106. El método tal como se describe en la reivindicación 93, caracterizado porque la clave de sesión se recibe de la infraestructura móvil encriptada por una clave compartida entre el SIM y la infraestructura móvil, en donde antes de recibir la clave de sesión del SIM, el método comprende además: enviar la clave encriptada al SIM para la desencriptación de la misma utilizando la clave compartida con el objeto de proporcionar la clave de sesión a la computadora central sin comprometer la clave compartida. 107. En una infraestructura móvil sujeta a una red distribuida a través de una red insegura de otra forma independiente de la red de radio de la infraestructura móvil, un método para establecer comunicaciones seguras de nivel de transporte entre un cliente y un servidor a través de una red insegura, estableciendo un túnel seguro entre un módulo móvil conectado al cliente y la infraestructura móvil con el objeto de delegar claves de sesión a un servidor confiable para uno o más propósitos de encriptación o firma, en donde el método comprende: recibir una o más credenciales de un módulo móvil conectado a una computadora central, en donde la una o más credenciales son recibidas a través de una red independiente separada de la red de radio que corresponde a la infraestructura móvil; autentificar la una o más credenciales como parte de una cuenta de facturación válida para el módulo móvil; y con base en la autentificación , enviar una clave de sesión a un servidor para utilizarse en una comunicación segura de nivel de transporte a través de la red independiente entre la computadora central y el servidor. 108. El método tal como se describe en la reivindicación 107, caracterizado porque el módulo móvil es un módulo de identidad del subscriptor (SIM) para la infraestructura móvil, y en donde la una o más credenciales incluyen información con base en un cuestionamiento de la infraestructura móvil y una clave compartida entre el SIM y la infraestructura móvil. 109. El método tal como se describe en la reivindicación 108, caracterizado porque la red independiente incluye la Internet. 110. El método tal como se describe en la reivindicación 108, caracterizado porque el servidor es parte de una estructura que tiene una relación confiable con la infraestructura móvil de modo que las claves de sesión también se pasan de la infraestructura móvil al servidor para la comunicación segura de nivel de transporte con la computadora central. 111. El método tal como se describe en la reivindicación 108, caracterizado porque la autentificación del SIM para la infraestructura móvil, a través de la validación de la cuenta de facturación del mismo, se emite como una verificación de los fondos de pago disponibles para los bienes, servicios o ambos, cuando se realiza una compra del comerciante. 112. El método tal como se describe en la reivindicación 108, caracterizado porque la clave de sesión expira con base en una o más de tiempo de vida en una clave de sesión o un número de mensajes encriptados, firmados o ambos, con la clave de sesión, en donde en la expiración del SIM se vuelve a autorizar con la infraestructura móvil para una comunicación segura adicional entre la computadora central y el servidor. 113. El método tal como se describe en la reivindicación 108, caracterizado porque la clave de sesión se deriva del SIM y la infraestructura móvil con base en un secreto compartido entre el SIM y la infraestructura móvil. 114. En una computadora central en un sistema de cómputo distribuido, un método para establecer comunicación segura entre la computadora central y un servidor utilizando un protocolo que autentifica un módulo de identidad del subscriptor (SIM) con una infraestructura móvil a través de una conexión de red independiente de una red de radio asociada con el mismo, en donde el método comprende: crear una solicitud de una clave de sesión que incluye una respuesta de cuestionamiento computarizado de un módulo de identidad de suscripción (SIM) unido a una computadora central que intenta establecer una comunicación segura con un servidor, en donde la respuesta del cuestionamiento se utiliza para autentificar el SIM con una infraestructura móvil que mantiene la información de estado de facturación del mismo; enviar la solicitud de una clave de sesión al servidor, la cual tiene una relación confiable con la infraestructura móvil, la solicitud de la clave de sesión se envía a través de una red independiente de la red de radio relacionada con la infraestructura móvil; recibir una respuesta a la solicitud de una clave de sesión, que incluye la clave de sesión y se firma, encripta o ambas, a través de la infraestructura móvil utilizando una clave compartida, la cual indica que el SIM está autentificado · en forma adecuada con la infraestructura móvil utilizando la respuesta de cuestionamiento; enviar la clave de sesión al SIM para validación utilizando la clave compartida, la cual establece una comunicación en túnel entre el SIM y la infraestructura móvil; y al momento de la validación de la clave de sesión, permitir que la computadora central utilice la clave de sesión desencriptada para asegurar la comunicación con el servidor. 115. El método tal como se describe en la reivindicación 114, caracterizado porque la respuesta a la solicitud de la clave de sesión es firmada por el servidor, la infraestructura móvil, o ambas. 116. El método tal como se describe en la reivindicación 114, caracterizado porque la respuesta del cuestionamiento incluye un Nonce firmado por SIM utilizando la clave compartida, de modo que la respuesta de cuestionamiento sea generada propiamente por el SIM. 117. El método tal como se describe en la reivindicación 114, caracterizado porque la clave compartida es específica de SIM. 118. El método tal como se describe en la reivindicación 114, caracterizado porque la solicitud de la clave de sesión es firmada, encriptada o ambas, utilizando una ficha especificada por el servidor. 119. El método tal como se describe en la reivindicación 114, caracterizado porque la solicitud de la clave de sesión es firmada, encriptada o ambas, utilizando una ficha específica' de la computadora central. 120. El método tal como se describe en la reivindicación 114, caracterizado porque antes de enviar la respuesta del cuestionamiento, se recibe un cuestionamiento que es utilizado por el SIM para generar la respuesta del cuestionamiento. 121. El método tal como se describe en la reivindicación 114, caracterizado porque al momento de la autentificación del SIM con la infraestructura móvil, el método comprende además lo siguiente, para autentificar a un usuario con la infraestructura móvil a través de la red independiente: crear una solicitud de una ficha de usuario utilizada en la autentificación de un usuario con una o más de la infraestructura móvil, el servidor u otros servicios de tercera parte; enviar la solicitud para la ficha del usuario al servidor a través de la red independiente de la red de radio relacionada con la infraestructura móvil; recibir una respuesta de la solicitud de una ficha del usuario, que incluye un cuestionamiento generado de la infraestructura móvil; enviar el cuestionamiento al SIM que indica que el cuestionamiento corresponde a la autentificación de un usuario con el objeto de pedir al SIM que solicite una o más credenciales al usuario; recibir una entrada del usuario que especifica la una o más credenciales del mismo, las cuales posteriormente se envían al SIM para determinar una respuesta al cuestionamiento adecuada; enviar la respuesta al cuestionamiento que incluye la una o más credenciales del usuario al servidor; recibir la ficha del usuario que está firmada, encriptada o ambas, utilizando una clave compartida a través de la infraestructura móvil que indica que el usuario sea autentificado en forma adecuada; y enviar la ficha del usuario al SIM para validación utilizando la clave compartida; y al momento de la validación de la clave de sesión, permitir que la computadora central utilice la ficha del usuario en la comunicación subsecuente con el servidor o un servicio de tercera parte para comunicaciones seguras entre ellos. 122. El método tal como se describe en la reivindicación 121, caracterizado porque la ficha del usuario se utiliza para solicitar una clave de sesión de servicio que se envía a un servicio de tercera parte, y en donde el servicio de tercera parte valida la clave de sesión de servicio a través del servidor. 123. El método tal como se describe en la reivindicación 122, caracterizado porque la clave de sesión de servicio es proporcionada por el servidor en una ficha separada de la ficha del usuario al momento de solicitar a la computadora central, y la autentificación del usuario al servidor. 124. Un sistema de operador móvil en un ambiente de cómputo distribuido, un método para establecer comunicación segura entre una computadora central y un servidor utilizando un protocolo que autentifica un módulo de identidad del subscriptor (SIM) al sistema del operador móvil a través de una conexión de red independiente de una red de radio asociada con la misma, en donde el método comprende: recibir una solicitud de una clave de sesión que incluye una respuesta de estimulo computarizada de un módulo de identidad de suscripción (SIM) unido a una computadora central que intenta establecer una comunicación segura con un servidor, que tiene una relación confiable con una infraestructura móvil que corresponde al SIM, en donde la solicitud de la clave de sesión enviada a través de una red independiente de una red de radio relacionada con ' la infraestructura móvil; utilizando la respuesta del cuestionamiento para autentificar el SIM que tiene una cuenta de facturación válida con la infraestructura móvil; 131. El método tal como se describe en la reivindicación 124, caracterizado porque al momento de autentificar el SIM con la infraestructura móvil, el método comprende además lo siguiente, para autentificar a un usuario con la infraestructura móvil a través de la red independiente: récibir una solicitud de una ficha de usuario utilizada para autentificar a un usuario con la infraestructura móvil, la solicitud de la ficha del usuario recibida a través de la red independiente de la red de radio; enviar un cuestionamiento generado de la infraestructura móvil para solicitar que el SIM obtenga una o más credenciales del usuario; recibir una respuesta al cuestionamiento que incluye' la una o más credenciales del usuario; con base en la validación de la una o más credenciales del usuario, asegurar una ficha del usuario firmando, encriptando o ambas, utilizando la clave compartida que indica que el usuario sea autentificado en forma adecuada con la infraestructura móvil ; y enviar la ficha del usuario al SIM para la validación utilizando la clave compartida con el objeto de permitir que la computadora central utilice la ficha del usuario en una comunicación subsecuente con el servidor o servicios de tercera parte para comunicaciones seguras entre ellas. 132. En un aparato de cómputo del consumidor en un sistema distribuido, un método para proporcionar una transacción comercial segura para la compra en línea de bienes, servicios o ambos, estableciendo un intercambio de datos de tres vías entre los aparatos de cómputo de un consumidor, un comerciante y un proveedor de pago, en donde el método comprende: enviar una solicitud en línea para comprar uno o más bienes, servicio o ambos, ofrecidos por un comerciante; recibir información de facturación del comerciante, que incluya un costo asociado con la compra del uno o más bienes, servicios o ambos; enviar una solicitud para autorización de pago por el costo de un aparato de cómputo del consumidor a al menos un proveedor de pago, en donde el consumidor tiene una cuenta de facturación con el al menos un proveedor de pago; recibir del al menos un proveedor de pago una ficha de pago como prueba de la capacidad que tiene el consumidor de pagar por al menos una parte del uno o más bienes, servicios o ambos, en donde la ficha de pago identifica únicamente la autorización de pago para al menos una parte del costo sin proporcionar información sensible con respecto a la cuenta de facturación del consumidor; enviar la ficha de pago del aparato de cómputo del consumidor al comerciante, en donde el comerciante utiliza la ficha de pago para validar el pago con el proveedor del pago, lo cual hace que la información sensible con respecto a la cuenta de facturación sea obscura para el comerciante, proporcionando aún una validación de pago segura; y recibir el reconocimiento de la validez de la ficha de pago que indica la transferencia adecuada del uno o más bienes, servicios o ambos, del comerciante al consumidor. 133. El método tal como se describe en la reivindicación 132, caracterizado porque la información de facturación incluye además una o más de la desencriptacion de bienes, servicio o ambos, opciones de pago disponibles del comerciante o información específica del comerciante. 134. El método tal como se describe en la reivindicación 133, caracterizado porque la información de facturación es presentada al menos a un proveedor de pago cuando solicita la autorización del pago por los bienes, servicios o ambos. 135. El método tal como se describe en la reivindicación 134, caracterizado porque la ficha de pago incluye . la información de facturación, la cual posteriormente es firmada, encriptada o ambas, a través de al menos un proveedor de pago para validar la ficha de pago y para cotejar la ficha de pago con la solicitud de autorización de pago del consumidor. 136. El método tal como se describe en la reivindicación 135, caracterizado porque la solicitud de autorización de pago, la presentación de la información de facturación al menos a un proveedor de pago y el envío de la ficha de pago al comerciante ocurren en forma automática sin la interacción del consumidor. 137. El método tal como se describe en la reivindicación 133, caracterizado porque con base en las opciones de pago disponibles proporcionadas por el comerciante, el método incluye además: presentar al consumidor una interfase del usuario que muestra una o más de las opciones de pago disponibles; recibir una entrada del usuario del consumidor que selecciona al menos a un proveedor de pago; y con base en la entrada del usuario, establecer un canal de comunicación entre el aparato de cómputo del consumidor y el al menos un proveedor de pago para solicitar la autorización del pago. 138. El método tal como se describe en la reivindicación 132, caracterizado porque el al menos un proveedor de pago es elegido con base en el proveedor de pago por omisión establecido previamente por el consumidor. 139. El método tal como se describe en la reivindicación 132, caracterizado porque el al menos un proveedor de pago es uno de una infraestructura móvil que tiene información de cuenta de facturación de un aparato SIM que es propiedad del consumidor, una compañía de tarjeta de crédito del consumidor, un servicio de prepago del consumidor o una cuenta de banco del consumidor. 140. El método tal como se describe en la reivindicación 132, caracterizado porque la transacción comercial es una experiencia en banda transparente en cuanto a que el pago y la selección de los bienes, servicios o ambos, están integrados en una sola aplicación que no es parte de un buscador web. 141. El método tal como se describe en la reivindicación 132, caracterizado porque la ficha de pago expira después de cierto período de tiempo, frecuencia de uso o ambos predeterminados, establecidos por al menos un proveedor de pago. 142. El método tal como se describe en la reivindicación 132, caracterizado porque el costo es variable y se presenta la información de facturación como un rango de valores. 143. El método tal como se describe en la reivindicación 132, caracterizado porque la ficha de pago es revocable por el consumidor, el al menos un proveedor de pago, o ambos. 144. El método tal como se describe en la reivindicación 132, caracterizado porque el costo es a través de una cantidad predeterminada permitida por el al menos un proveedor de pago, y en donde la interacción adicional del usuario es necesaria para la autorización de la ficha de pago. 145. El método tal como se describe en la reivindicación 132, caracterizado porque la ficha de pago es firmada, encriptada o ambas, a través de al menos un proveedor de pago, y en donde la validación de la ficha de pago para' al menos un proveedor de pago incluye validar la signatura, la encriptación o ambas. 146. El método tal como se describe en la reivindicación 132, caracterizado porque el uno o más bienes, servicios o ambos, requieren pagos de suscripción o pagos múltiples, y en donde la ficha de pago puede ser utilizada varias veces para dicho pago. 147. El método tal como se describe en la reivindicación 132, caracterizado porque el uno o más bienes, servicios o ambos, requieren pagos de suscripción o pagos múltiples, y en donde la ficha de pago es válida únicamente para un solo pago de los pagos de suscripción o múltiples, y en donde las fichas adicionales son necesarias para pagos subsecuentes. 148. En un aparato de cómputo de un comerciante en un sistema distribuido, un método para llevar a cabo una transacción comercial segura cuando se permite la compra de bienes, servicios o ambos, estableciendo un intercambio ' de datos de tres vías entre los aparatos de cómputo de un consumidor, comerciante y proveedor de pago, en donde, el método comprende: recibir una solicitud en línea de la compra de uno o más bienes, servicios o ambos, ofrecidos por un comerciante; enviar información de facturación a un consumidor, que incluye un costo asociado con la compra del uno o más bienes, servicios o ambos; recibir una ficha de pago del consumidor como el ofrecimiento de una prueba de la capacidad que tiene el consumidor de pagar por al menos una parte del uno o más bienes, servicios o ambos, en donde la ficha de pago identifica únicamente una autorización de pago a través de un proveedor de pago por al menos una parte del costo sin proporcionar información sensible con respecto a una cuenta de facturación del consumidor con el proveedor de pago; enviar una solicitud para validación de la ficha de pago al proveedor de pago, permitiendo de esta forma que el comerciante valide en forma segura el pago de al menos una parte del costo, mientras deja en la oscuridad para el comerciante la información sensible con respecto a la cuenta de facturación; y con base en la validación de la ficha de pago, enviar un reconocimiento de la validez de la ficha de pago que indica la transferencia adecuada del uno o más bienes, servicios o ambos, del comerciante al consumidor. 149. El método tal como se describe en la reivindicación 148, caracterizado porque la información de facturación incluye además uno o más de una descripción de los uno o más bienes, servicios o ambos, opciones de pago disponibles del comerciante o información específica del comerciante. 150. El método tal como se describe en la reivindicación 149, caracterizado porque la ficha de pago incluye información de facturación, la cual es firmada, encriptada o ambas, por al menos un proveedor de pago para validar la ficha de pago y para cotejar la ficha de pago con una solicitud de autorización de pago del consumidor. 151. El método tal como se describe en la reivindicación 148, caracterizado porque la ficha de pago expira después de cierto período de tiempo, frecuencia de uso o ambos predeterminados, establecidos por el proveedor de pago. 152. El método tal como se describe en la reivindicación 148, caracterizado porque al menos una parte del costo es variable y presentado en la información de facturación como un rango de valores. 153. El método tal como se describe en la reivindicación 148, caracterizado porque la ficha de pago es revocable por el consumidor, el proveedor de pago o ambos. 154. El método tal como se describe en la reivindicación 148, caracterizado porque el costo es en una cantidad predeterminada permitida por el proveedor de pago, y en donde es necesaria la interacción adicional del usuario para la autorización de la ficha de pago. 155. El método tal como se describe en la reivindicación 148, caracterizado porque el uno o más bienes, servicios o ambos, requieren pagos de suscripción o pagos múltiples, y en donde la ficha de pago puede ser utilizada varias veces para dicho pago. 156. En un aparato de cómputo de proveedor de pago en un sistema distribuido, un método para autorizar el pago en una transacción comercial para la compra de uno o más bienes, servicios o ambos, estableciendo un intercambio de datos de tres vías entre los aparatos de cómputo de un consumidor, comerciante y un proveedor de pago, en donde el método comprende: recibir una solicitud de autorización de pago de un consumidor que compra uno o más bienes, servicios o ambos de un comerciante, en donde la solicitud de autorización de pago incluye información de facturación de un costo asociado con la compra; con base en el estado de cuenta de facturación del consumidor, enviar una ficha de pago al consumidor como una prueba de la capacidad que tiene el consumidor de pagar el uno o más bienes, servicios o ambos, en donde la ficha de pago identifica únicamente la autorización del pago del uno o más bienes, servicios o ambos, sin proporcionar información sensible con respecto a la cuenta de facturación del consumidor; recibir del comerciante una solicitud para validar la ficha de pago; y con base en la comparación de la ficha de pago con la información de facturación de la solicitud de autorización de pago, enviar un reconocimiento de la validez de la ficha de pago que indica que el pago será proporcionado al comerciante al momento de la transferencia adecuada de uno o más bienes, servicios o ambos al consumidor. 157. El método tal como se describe en la reivindicación 156, caracterizado porque la información de facturación incluye además uno o más de una descripción de los bienes, servicios o ambos, opciones de pago disponibles del comerciante o información específica del comerciante. 158. El método tal como se describe en la reivindicación 156, caracterizado porque al menos un proveedor de pago es uno de una infraestructura móvil que tiene información de la cuenta de facturación de un aparato SIM que es propiedad del consumidor, una compañía de tarjeta del crédito del consumidor, un servicio de prepago del consumidor o una cuenta de banco del consumidor. 159. El método tal como se describe en la reivindicación 156, caracterizado porque la ficha de pago expira después de cierto período de tiempo, frecuencia de uso o ambos predeterminados, establecidos por el proveedor de pago. 160. El método tal como se describe en la reivindicación 156, caracterizado porque al menos una parte del costo es variable y presentado en la información de facturación como un rango de valores. 161. El método tal como se describe en la reivindicación 156, caracterizado porque la ficha de pago es revocable por el consumidor, el proveedor de pago o ambos. 162. El método tal como se describe en la reivindicación 156, caracterizado porque el costo es en una cantidad predeterminada permitida por el proveedor de pago, y en donde es necesaria la interacción adicional del usuario para la autorización de la ficha de pago. 163. El método tal como se describe en la reivindicación 156, caracterizado porque la ficha de pago está firmada, encriptada o ambas, por el proveedor de pago, y en donde la validación de la ficha de pago para el proveedor de pago incluye validar la signatura, la encriptación o ambas. 164. El método tal como se describe en la reivindicación 156, caracterizado porque el uno o más bienes, servicios o ambos, requieren pagos de suscripción o pagos múltiples, y en donde la ficha de pago puede ser utilizada múltiples veces para dicho pago. 165. El método tal como se describe en la reivindicación 156, caracterizado porque el uno o más bienes, servicios o ambos, requieren pagos de suscripción o pagos múltiples, y en donde la ficha de pago es válida únicamente para un solo pago de los pagos de suscripción o pagos múltiples, y en donde las fichas adicionales son necesarias para los pagos subsecuentes. 166. En un sistema de cómputo distribuido para ejecutar una transacción comercial en línea, un método para elaborar una autorización de pago con base en una presentación de factura electrónica para mantener un registro de la transacción en línea con propósitos de auditoria, protección contra fraudes y otros, en donde el método comprende: recibir en un aparato de cómputo del consumidor una factura electrónica que incluye una descripción y costo de la compra de uno o más bienes, servicios o ambos de un comerciante durante una transacción comercial en línea del mismo; y enviar una copia de la factura electrónica a un proveedor de pago para autorizar el pago del uno o más bienes, servicios o ambos. 167. El método tal como se describe en la reivindicación 166, caracterizado porque la una o más partes de la factura electrónica son encriptadas el comerciante con el objeto de dejar oscuras para el consumidor, el proveedor de pago o ambos la una o más partes. 168. El método tal como se describe en la reivindicación 167, caracterizado porque la una o más partes de la factura electrónica que están encriptadas son utilizadas para la federación de pago automática a uno o más socios del negocio del comerciante. 169. El método tal como se describe en la reivindicación 166, caracterizado porque comprende además: almacenar una copia de la factura electrónica en el aparato de cómputo del consumidor; recibir una solicitud de pago de proveedor de pago por cargos que corresponden al pago al comerciante, en donde la solicitud de pago incluye una copia de la factura electrónica del comerciante; y comparar la copia almacenada de la factura electrónica con la copia recibida del proveedor de pago para auditar el pago realizado por el comerciante. 170. El método tal como se describe en la reivindicación 166, caracterizado porque una copia de la factura electrónica está firmada por el comerciante, en donde el método comprende además: recibir del proveedor de pago una ficha de pago para autorizar el pago del uno o más bienes, servicios o ambos, en donde la ficha incluye la copia firmada de la factura electrónica; y enviar la ficha de pago al comerciante para autorización del pago, en donde el comerciante puede validar la ficha de pago conforme viene del consumidor con base en la copia firmada de la factura electrónica. 171. En un sistema de cómputo distribuido para ejecutar una transacción comercial en línea, un método para autorizar el pago de bienes, servicios o ambos, de un comerciante con base en una presentación de factura electrónica para mantener un registro de una transacción en línea con propósitos de auditoria, protección contra fraudes y otros propósitos, el método comprende: recibir en un proveedor de pago una factura electrónica que incluye una descripción y costo de la compra del uno o más bienes, servicios o ambos, a través de un aparato de cómputo del consumidor durante una transacción comercial en línea; y enviar una ficha de pago al consumidor que incluye una copia de al menos una parte de la factura electrónica para autorizar el pago del uno o más bienes, servicios o ambos, de un comerciante. 172. El método tal como se describe en la reivindicación 171, caracterizado porque la una o más partes de la factura electrónica están encriptadas por el comerciante con el objeto de dejar oscuras para el consumidor, proveedor de pago o ambos la una o más partes. 173. El método tal como se describe en la reivindicación 172, caracterizado porque la una o más partes de la factura electrónica que son encriptadas se utilizan para la federación de pago automático a uno o más socios del negocio del comerciante. 174. El método tal como se describe en la reivindicación 171, caracterizado porque comprende además: almacenar una copia de la factura electrónica en- el aparato de cómputo del proveedor; recibir una solicitud de pago del comerciante para el pago de cargos correspondientes a uno o más bienes, servicios o ambos, en donde la solicitud de pago incluye una copia de al menos una parte de la factura electrónica del comerciante; y comparar la copia almacenada de la factura electrónica con la copia de al menos una parte de la factura electrónica recibida del comerciante para la autorización del pago adecuado de la misma. 175. El método tal como se describe en la reivindicación 171, caracterizado porque una copia de la factura electrónica es firmada por el comerciante, en donde el método comprende además: enviar una ficha de pago al consumidor que incluye la copia firmada de la factura electrónica, la cual puede utilizar el comerciante para validar que la ficha de pago es parte de una transacción comercial que se origina entre el comerciante y un consumidor; recibir del comerciante una solicitud para autorizar la ficha de pago por el uno o más bienes, servicios o ambos; y enviar el reconocimiento de validez de la ficha de pago al comerciante para permitir que el comerciante transfiera el uno o más bienes, servicios o ambos al consumidor. 176. En un sistema de cómputo distribuido para ejecutar una transacción comercial en línea, un método para validar autorización de pago con base en una presentación de factura electrónica para mantener un registro de la transacción en línea con propósitos de auditoria, protección contra fraudes y otros, el método comprende: enviar a un aparato de cómputo del consumidor una factura electrónica que incluye una descripción y costo de compra de uno o más bienes, servicios o ambos, de un comerciante durante una transacción comercial en línea de los mismos; y recibir una ficha de pago que incluye al menos una parte de la factura electrónica para validar que la ficha de pago es parte de una transacción comercial que se origina entre el comerciante y el consumidor. 177. El método tal como se describe en la reivindicación 176, caracterizado porque la una o más partes de la factura electrónica están encriptadas por el comerciante con el objeto de dejar en la oscuridad para el consumidor, el proveedor de pago o ambos la una o más partes. 178. El método tal como se describe en la reivindicación 177, caracterizado porque la una o más partes de la factura electrónica que están encriptadas son utilizadas para la federación de pago automático a uno o más socios del negocio del comerciante. 179. El método tal como se describe en la reivindicación 176, caracterizado porque comprende además: enviar la ficha de pago a un proveedor de pago para autorizar el pago del uno ó más bienes, servicios o ambos, en donde la ficha incluye la copia firmada de la factura electrónica; recibir la validación de la ficha de pago del proveedor de servicios que indica la capacidad que tiene el consumidor para pagar por el uno o más bienes, servicios o ambos; y con base en la autorización, enviar el uno o más bienes, servicios o ambos, al consumidor para completar la transacción comercial. 180. En un sistema distribuido, un método para distribución de pago automático a una serie de socios de negocio con una relación de socios definida previamente con base en un pago simple de un consumidor por una transacción comercial en línea, el método comprende: recibir un solo pago en línea por bienes, servicios o ambos, ofrecidos por un comerciante que tiene una relación de negocios transaccional con al menos otro socio del negocio que ayuda a proporcionar al menos una parte de los bienes, servicios o ambos; con base en la relación transaccional definida, identificar una parte del pago en línea simple como perteneciendo al menos a un socio del negocio; y transferir en forma automática la parte del pago a una cuenta para el al menos un socio del negocio con el objeto de federar el pago al comerciante y al menos un socio de negocio con base en una relación y política de confianza asociada entre ellos. 181. El método tal como se describe en la reivindicación 180, caracterizado porque la parte es identificada en forma adicional con base en partes designadas dentro de la información de facturación generadas por el comerciante, que se presenta a un consumidor al el que se le autoriza el pago simple. 182. El método tal como se describe en la reivindicación 181, caracterizado porque la parte está firmada por el comerciante con el objeto de hacer transparente para el consumidor la federación del pago. 183. Un sistema en línea distribuido para llevar a cabo una transacción comercial, un método para presentar a un consumidor opciones de pago con base en el análisis de una factura electrónica y políticas o reglas definidas por un comerciante, consumidor o ambos, el método comprende: recibir en un aparato del consumidor una factura electrónica que incluye información con respecto a la solicitud de compra de bienes, servicios o ambos, de un comerciante; comparar la información que proviene de la factura electrónica con una o más reglas predefinidas del consumidor, comerciante o ambos; y con base en la comparación, determinar una acción adecuada que cumpla con los requerimientos de la una o más reglas definidas previamente. 184. El método tal como se describe en la reivindicación 183, caracterizado porque la una o más reglas definidas previamente son una lista de un tipo disponible de opciones de pago para el comerciante, consumidor o ambos, y en donde las acciones elegidas de la lista de una o más opciones de pago se presentan a un usuario. 185. El método tal como se describe en la reivindicación 184, caracterizado porque la una o más reglas predefinidas limitan el tipo de pago con base en una relación de confianza con el comerciante y la información dentro de la factura electrónica identifica la relación de confianza con base en una signatura, encriptación o ambas del comerciante. 186. El método tal como se describe en la reivindicación 184, caracterizado porque la una o más reglas predefinidas limitan el tipo de pago con base en los tipos de pago disponibles del consumidor en comparación con el tipo de pagos aceptados por el comerciante. 187. El método tal como se describe en la reivindicación 184, caracterizado porque la una o más reglas predefinidas limitan el tipo de pago con base en el costo total del uno o más bienes, servicios o ambos. 188. El método tal como se describe en la reivindicación 184, caracterizado porque la información dentro de la factura electrónica incluye además reglas para el comerciante, de modo que las reglas para el comerciante se comparen con las reglas para el consumidor. 189. El método tal como se describe en la reivindicación 188, caracterizado porque cualquier conflicto entre las reglas para el comerciante y las reglas para el consumidor, son resueltas a favor del comerciante, o la transacción comercial es cancelada. 190. El método tal como se describe en la reivindicación 184, caracterizado porque la transacción comercial es una suscripción de pago conforme se obtiene, y en donde la una o más reglas limitan la duración de la suscripción con base en una cantidad de pago, período de tiempo o ambos.
MX2008013116A 2006-04-18 2007-02-27 Autentificacion para una transaccion comercial utilizando un modulo movil. MX2008013116A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/379,143 US8996423B2 (en) 2005-04-19 2006-04-18 Authentication for a commercial transaction using a mobile module
PCT/US2007/005150 WO2007123596A1 (en) 2006-04-18 2007-02-27 Authentication for a commercial transaction using a mobile module

Publications (1)

Publication Number Publication Date
MX2008013116A true MX2008013116A (es) 2008-12-16

Family

ID=38625335

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2008013116A MX2008013116A (es) 2006-04-18 2007-02-27 Autentificacion para una transaccion comercial utilizando un modulo movil.

Country Status (11)

Country Link
US (2) US8996423B2 (es)
EP (1) EP2016543B1 (es)
JP (1) JP2009534739A (es)
KR (1) KR20090006831A (es)
CN (1) CN101427268A (es)
AU (1) AU2007241160A1 (es)
BR (1) BRPI0710283A2 (es)
CA (1) CA2645949A1 (es)
MX (1) MX2008013116A (es)
RU (1) RU2008141288A (es)
WO (1) WO2007123596A1 (es)

Families Citing this family (280)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6711554B1 (en) * 1999-12-30 2004-03-23 Lee Salzmann Method and system for managing and preparing documentation for real estate transactions
WO2004034645A1 (ja) 2002-10-11 2004-04-22 Matsushita Electric Industrial Co., Ltd. Ｗｌａｎ相互接続における識別情報の保護方法
US7693752B2 (en) 2004-05-26 2010-04-06 Hothand, Inc. Mobile commerce framework
US7272728B2 (en) 2004-06-14 2007-09-18 Iovation, Inc. Network security and fraud detection system and method
US7873911B2 (en) * 2004-08-31 2011-01-18 Gopalakrishnan Kumar C Methods for providing information services related to visual imagery
US8566726B2 (en) * 2005-05-03 2013-10-22 Mcafee, Inc. Indicating website reputations based on website handling of personal information
US7562304B2 (en) 2005-05-03 2009-07-14 Mcafee, Inc. Indicating website reputations during website manipulation of user information
US7765481B2 (en) * 2005-05-03 2010-07-27 Mcafee, Inc. Indicating website reputations during an electronic commerce transaction
US7822620B2 (en) * 2005-05-03 2010-10-26 Mcafee, Inc. Determining website reputations using automatic testing
US8438499B2 (en) 2005-05-03 2013-05-07 Mcafee, Inc. Indicating website reputations during user interactions
US9384345B2 (en) 2005-05-03 2016-07-05 Mcafee, Inc. Providing alternative web content based on website reputation assessment
WO2006133141A2 (en) * 2005-06-06 2006-12-14 Sms.Ac, Inc. Billing system and method for micro-transactions
US20070260556A1 (en) * 2005-06-06 2007-11-08 Michael Pousti System and method for verification of identity for transactions
US8239544B2 (en) * 2005-06-17 2012-08-07 Microsoft Corporation Removable storage content transfer
US8621201B2 (en) * 2005-06-29 2013-12-31 Telecom Italia S.P.A. Short authentication procedure in wireless data communications networks
CA2621108A1 (en) * 2005-09-07 2007-03-15 Sms.Ac, Inc. Automated billing and distribution platform for application providers
JP2009512018A (ja) 2005-10-06 2009-03-19 シー・サム，インコーポレイテッド トランザクションサービス
US20130332343A1 (en) 2005-10-06 2013-12-12 C-Sam, Inc. Multi-tiered, secure mobile transactions ecosystem enabling platform comprising a personalization tier, a service tier, and an enabling tier
US7657489B2 (en) 2006-01-18 2010-02-02 Mocapay, Inc. Systems and method for secure wireless payment transactions
US8090699B2 (en) * 2006-03-08 2012-01-03 Sms.Ac, Inc. Automatic generation of application pod
US20080287095A1 (en) * 2006-03-20 2008-11-20 Sms.Ac Systems and methods for generation, registration and mobile phone billing of a network-enabled application with one-time opt-in
US8701196B2 (en) 2006-03-31 2014-04-15 Mcafee, Inc. System, method and computer program product for obtaining a reputation associated with a file
US20070255687A1 (en) * 2006-04-27 2007-11-01 Al-Yousuf Ahmed K Research report search system
US20080052373A1 (en) * 2006-05-01 2008-02-28 Sms.Ac Systems and methods for a community-based user interface
US8732789B2 (en) * 2006-05-30 2014-05-20 Iyuko Services L.L.C. Portable security policy and environment
EP1871065A1 (en) * 2006-06-19 2007-12-26 Nederlandse Organisatie voor Toegepast-Natuuurwetenschappelijk Onderzoek TNO Methods, arrangement and systems for controlling access to a network
US8353048B1 (en) 2006-07-31 2013-01-08 Sprint Communications Company L.P. Application digital rights management (DRM) and portability using a mobile device for authentication
US10019708B2 (en) * 2006-08-25 2018-07-10 Amazon Technologies, Inc. Utilizing phrase tokens in transactions
US20090024614A1 (en) * 2006-09-06 2009-01-22 Sms.Ac Systems and methods for online content searching
US8751815B2 (en) * 2006-10-25 2014-06-10 Iovation Inc. Creating and verifying globally unique device-specific identifiers
GB0621189D0 (en) * 2006-10-25 2006-12-06 Payfont Ltd Secure authentication and payment system
US8104084B2 (en) * 2006-11-07 2012-01-24 Ricoh Company, Ltd. Authorizing a user to a device
US8387148B2 (en) * 2006-11-17 2013-02-26 Intel Corporation Secure rights protection for broadcast mobile content
EA010039B1 (ru) * 2006-12-08 2008-06-30 Некоммерческая Организация «Фонд Сопровождения Инвестиционных Проектов "Генкей"» Способ организации торговли товарами и/или предоставления услуг с применением телекоммуникационной сети
US7996818B1 (en) * 2006-12-29 2011-08-09 Amazon Technologies, Inc. Method for testing using client specified references
US8655786B2 (en) * 2006-12-29 2014-02-18 Amazon Technologies, Inc. Aggregate constraints for payment transactions
US20080189209A1 (en) * 2007-02-05 2008-08-07 First Data Corporation Real-Time Funds Transfer
US9418501B2 (en) * 2007-02-05 2016-08-16 First Data Corporation Method for digital signature authentication of pin-less debit card account transactions
US20090249430A1 (en) * 2008-03-25 2009-10-01 Novell, Inc. Claim category handling
US8074257B2 (en) 2007-03-16 2011-12-06 Felsted Patrick R Framework and technology to enable the portability of information cards
US8151324B2 (en) 2007-03-16 2012-04-03 Lloyd Leon Burch Remotable information cards
US20090228885A1 (en) * 2008-03-07 2009-09-10 Novell, Inc. System and method for using workflows with information cards
US8078515B2 (en) * 2007-05-04 2011-12-13 Michael Sasha John Systems and methods for facilitating electronic transactions and deterring fraud
US11257080B2 (en) 2007-05-04 2022-02-22 Michael Sasha John Fraud deterrence for secure transactions
US20080313075A1 (en) * 2007-06-13 2008-12-18 Motorola, Inc. Payments-driven dynamic firewalls and methods of providing payments-driven dynamic access to network services
US20090063312A1 (en) * 2007-08-28 2009-03-05 Hurst Douglas J Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions
JP5034821B2 (ja) * 2007-09-21 2012-09-26 ソニー株式会社 生体情報記憶装置
US7831611B2 (en) 2007-09-28 2010-11-09 Mcafee, Inc. Automatically verifying that anti-phishing URL signatures do not fire on legitimate web sites
US7793340B2 (en) * 2007-11-21 2010-09-07 Novell, Inc. Cryptographic binding of authentication schemes
US9137018B2 (en) * 2007-12-19 2015-09-15 The Directv Group, Inc. Method and system for providing a generic program guide data from a primary content provider to a user network device through a partner service provider
US8621646B2 (en) * 2007-12-19 2013-12-31 The Directv Group, Inc. Method and system for authenticating a user receiving device into a primary service provider system to communicate with a partner service provider
US8533852B2 (en) * 2007-12-19 2013-09-10 The Directv Group, Inc. Method and system for securely communicating between a primary service provider and a partner service provider
US8453251B2 (en) * 2007-12-19 2013-05-28 The Directv Group, Inc. Method and system for securely communicating between a user network device, a primary service provider and a partner service provider
US8744940B2 (en) 2008-01-03 2014-06-03 William O. White System and method for distributing mobile compensation and incentives
US8589267B2 (en) 2008-01-03 2013-11-19 Mocapay, Inc. System and method for re-distributing and transferring mobile gift cards
US20090205035A1 (en) * 2008-02-11 2009-08-13 Novell, Inc. Info card selector reception of identity provider based data pertaining to info cards
US20090217368A1 (en) * 2008-02-27 2009-08-27 Novell, Inc. System and method for secure account reset utilizing information cards
US8079069B2 (en) 2008-03-24 2011-12-13 Oracle International Corporation Cardspace history validator
US8301500B2 (en) * 2008-04-02 2012-10-30 Global 1 Enterprises Ghosting payment account data in a mobile telephone payment transaction system
US20090271856A1 (en) * 2008-04-24 2009-10-29 Novell, Inc. A Delaware Corporation Restricted use information cards
US8374588B2 (en) 2008-06-02 2013-02-12 Mocapay, Inc. Method and system for sending marketing messages to mobile-device users from a mobile-commerce platform
US20100078472A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
US20100082485A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Portable point of purchase devices and methods
US20100082445A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Smart menu options
US10380573B2 (en) * 2008-09-30 2019-08-13 Apple Inc. Peer-to-peer financial transaction devices and methods
US20100078471A1 (en) * 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
US9026462B2 (en) * 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
KR101435845B1 (ko) * 2008-10-13 2014-08-29 엘지전자 주식회사 이동단말기 및 그 제어 방법
US20100145861A1 (en) * 2008-12-08 2010-06-10 Palm, Inc. Payment transaction processing for mobile computing devices
US9219956B2 (en) * 2008-12-23 2015-12-22 Keyssa, Inc. Contactless audio adapter, and methods
US8083135B2 (en) 2009-01-12 2011-12-27 Novell, Inc. Information card overlay
US8632003B2 (en) 2009-01-27 2014-01-21 Novell, Inc. Multiple persona information cards
US20100262506A1 (en) * 2009-04-08 2010-10-14 Microsoft Corporation Mobile content delivery on a mobile network
WO2010142748A1 (en) * 2009-06-09 2010-12-16 Gilbarco, S.R.L. Fuel dispenser user interface
US9294918B2 (en) * 2009-07-23 2016-03-22 Mohammed Naser S. Shaikh Method and system for secure remote login of a mobile device
US20110055076A1 (en) * 2009-08-25 2011-03-03 Greg Trifiletti Response to alert message
AU2015203305B2 (en) * 2009-08-25 2017-02-02 Visa International Service Association Response to alert message
US8375432B2 (en) 2009-08-31 2013-02-12 At&T Mobility Ii Llc Methods, apparatus, and computer program products for subscriber authentication and temporary code generation
WO2011032596A1 (en) * 2009-09-18 2011-03-24 Bankgirocentralen Bgc Ab Electronic transfer of money
US8170528B2 (en) * 2009-10-09 2012-05-01 Hewlett-Packard Development Company, L.P. Network access control
US9027093B2 (en) 2009-12-30 2015-05-05 International Business Machines Corporation Business process enablement for identity management
US20110184840A1 (en) * 2010-01-27 2011-07-28 Ebay Inc. Systems and methods for facilitating account verification over a network
US9654829B1 (en) 2010-03-04 2017-05-16 The Directv Group, Inc. Method and system for retrieving data from multiple sources
US8806198B1 (en) * 2010-03-04 2014-08-12 The Directv Group, Inc. Method and system for authenticating a request
US8521131B1 (en) * 2010-03-23 2013-08-27 Amazon Technologies, Inc. Mobile device security
US20110238476A1 (en) * 2010-03-23 2011-09-29 Michael Carr Location-based Coupons and Mobile Devices
US8676684B2 (en) 2010-04-12 2014-03-18 Iovation Inc. System and method for evaluating risk in fraud prevention
US20110270925A1 (en) * 2010-04-28 2011-11-03 Magid Joseph Mina System to share credit information
US9183374B2 (en) * 2010-07-15 2015-11-10 Novell, Inc. Techniques for identity-enabled interface deployment
JP5665437B2 (ja) * 2010-09-02 2015-02-04 キヤノン株式会社 ネットワーク機器管理システム、ネットワーク機器管理装置、クライアント装置およびその方法
CN102385730A (zh) * 2010-09-06 2012-03-21 航天信息股份有限公司 一种售货方法和系统
US20120116918A1 (en) * 2010-11-10 2012-05-10 Precise Biometrics Ab Secure payment mechanism
US9489669B2 (en) 2010-12-27 2016-11-08 The Western Union Company Secure contactless payment systems and methods
US20120173431A1 (en) * 2010-12-30 2012-07-05 First Data Corporation Systems and methods for using a token as a payment in a transaction
US9253178B2 (en) * 2011-01-17 2016-02-02 Telefonaktiebolaget L M Ericsson Method and apparatus for authenticating a communication device
US20120226611A1 (en) * 2011-03-01 2012-09-06 Nimish Radia Method and system for conducting a monetary transaction using a mobile communication device
WO2012123727A1 (en) * 2011-03-11 2012-09-20 Callsign, Inc Personal identity control
AU2012257312A1 (en) 2011-05-17 2014-01-16 Ping Identity Corporation System and method for performing a secure transaction
US8346672B1 (en) 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device
US9098850B2 (en) * 2011-05-17 2015-08-04 Ping Identity Corporation System and method for transaction security responsive to a signed authentication
US9965768B1 (en) 2011-05-19 2018-05-08 Amazon Technologies, Inc. Location-based mobile advertising
US10325265B2 (en) * 2011-05-26 2019-06-18 Facebook, Inc. Methods and systems for facilitating E-commerce payments
KR101831404B1 (ko) * 2011-08-11 2018-02-22 엘지전자 주식회사 이동 단말기 및 이동 단말기의 결제 방법
US8752154B2 (en) * 2011-08-11 2014-06-10 Bank Of America Corporation System and method for authenticating a user
JP2014529964A (ja) 2011-08-31 2014-11-13 ピング アイデンティティ コーポレーション モバイル機器経由の安全なトランザクション処理のシステムおよび方法
CN107730240B (zh) * 2011-09-09 2021-03-26 成都天钥科技有限公司 多因子多信道id认证和交易控制及多选项支付系统及方法
US9002322B2 (en) 2011-09-29 2015-04-07 Apple Inc. Authentication with secondary approver
US20130104197A1 (en) 2011-10-23 2013-04-25 Gopal Nandakumar Authentication system
US8738540B2 (en) * 2011-10-31 2014-05-27 Ncr Corporation Techniques for mobile transaction processing
US9830596B2 (en) * 2011-11-01 2017-11-28 Stripe, Inc. Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site
US20130144755A1 (en) * 2011-12-01 2013-06-06 Microsoft Corporation Application licensing authentication
US9330245B2 (en) * 2011-12-01 2016-05-03 Dashlane SAS Cloud-based data backup and sync with secure local storage of access keys
US20130159195A1 (en) * 2011-12-16 2013-06-20 Rawllin International Inc. Authentication of devices
US20130159463A1 (en) * 2011-12-20 2013-06-20 Frisco Smartapps, LLC Method and system for targeted transmission of content
US20130171928A1 (en) * 2011-12-28 2013-07-04 Broadcom Corporation Multi-Party Transactions with Static and/or Dynamic Rules Management Mediated by One or More NFC-Enabled Devices
US8689310B2 (en) 2011-12-29 2014-04-01 Ebay Inc. Applications login using a mechanism relating sub-tokens to the quality of a master token
US20130218779A1 (en) * 2012-02-21 2013-08-22 Rawllin International Inc. Dual factor digital certificate security algorithms
US9043878B2 (en) * 2012-03-06 2015-05-26 International Business Machines Corporation Method and system for multi-tiered distributed security authentication and filtering
US20130254083A1 (en) * 2012-03-22 2013-09-26 International Business Machines Corporation Payment device policy management
US9094774B2 (en) 2012-05-14 2015-07-28 At&T Intellectual Property I, Lp Apparatus and methods for maintaining service continuity when transitioning between mobile network operators
US9148785B2 (en) 2012-05-16 2015-09-29 At&T Intellectual Property I, Lp Apparatus and methods for provisioning devices to utilize services of mobile network operators
US9576279B2 (en) 2012-06-05 2017-02-21 Autoscribe Corporation System and method for registering financial accounts
US8800015B2 (en) 2012-06-19 2014-08-05 At&T Mobility Ii, Llc Apparatus and methods for selecting services of mobile network operators
US9473929B2 (en) 2012-06-19 2016-10-18 At&T Mobility Ii Llc Apparatus and methods for distributing credentials of mobile network operators
US8639619B1 (en) 2012-07-13 2014-01-28 Scvngr, Inc. Secure payment method and system
US20140025581A1 (en) * 2012-07-19 2014-01-23 Bank Of America Corporation Mobile transactions using authorized tokens
US9043609B2 (en) * 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
US8881245B2 (en) * 2012-09-28 2014-11-04 Avaya Inc. System and method for enhancing self-service security applications
US11210648B2 (en) 2012-10-17 2021-12-28 Royal Bank Of Canada Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments
US11961075B2 (en) 2014-10-10 2024-04-16 Royal Bank Of Canada Systems for processing electronic transactions
US9082119B2 (en) 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data
US11080701B2 (en) 2015-07-02 2021-08-03 Royal Bank Of Canada Secure processing of electronic payments
CN103905401B (zh) * 2012-12-27 2018-06-12 中国移动通信集团公司 一种身份认证方法和设备
US9930187B2 (en) * 2013-01-31 2018-03-27 Nokia Technologies Oy Billing related information reporting
US8694438B1 (en) 2013-03-12 2014-04-08 Scvngr Distributed authenticity verification for consumer payment transactions
US9521032B1 (en) * 2013-03-14 2016-12-13 Amazon Technologies, Inc. Server for authentication, authorization, and accounting
CN103607371B (zh) * 2013-07-02 2016-12-28 燕山大学 一种通过第三方平台保护互联网用户隐私的方法
US10489852B2 (en) * 2013-07-02 2019-11-26 Yodlee, Inc. Financial account authentication
US8770478B2 (en) 2013-07-11 2014-07-08 Scvngr, Inc. Payment processing with automatic no-touch mode selection
CN113469670B (zh) 2013-07-24 2024-04-05 维萨国际服务协会 使用令牌确保数据传送风险的系统和方法
EP2838060A1 (en) * 2013-08-14 2015-02-18 Facebook, Inc. Methods and systems for facilitating e-commerce payments
US9123072B2 (en) * 2013-08-16 2015-09-01 Mdsave Inc. Network-based marketplace service for facilitating purchases of services and products
ES2531386B1 (es) * 2013-09-13 2015-12-22 Pomo Posibilidades, S.A. Sistema y método de pago mediante dispositivo móvil
CN106464492B (zh) 2013-10-11 2020-02-07 维萨国际服务协会 网络令牌系统
AU2014334713A1 (en) * 2013-10-14 2016-05-19 Equifax Inc. Providing identification information to mobile commerce applications
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US10700856B2 (en) * 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9264899B2 (en) * 2013-12-19 2016-02-16 Nxp, B.V. Binding mobile device secure software components to the SIM
WO2015094265A1 (en) * 2013-12-19 2015-06-25 Hewlett-Packard Development Company, L.P. Payment transaction
US10268995B1 (en) * 2014-01-28 2019-04-23 Six Trees Capital LLC System and method for automated optimization of financial assets
US9208301B2 (en) 2014-02-07 2015-12-08 Bank Of America Corporation Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location
US9286450B2 (en) 2014-02-07 2016-03-15 Bank Of America Corporation Self-selected user access based on specific authentication types
US9223951B2 (en) 2014-02-07 2015-12-29 Bank Of America Corporation User authentication based on other applications
US9965606B2 (en) 2014-02-07 2018-05-08 Bank Of America Corporation Determining user authentication based on user/device interaction
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US9830597B2 (en) 2014-03-04 2017-11-28 Bank Of America Corporation Formation and funding of a shared token
US9600817B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign exchange token
US9424572B2 (en) 2014-03-04 2016-08-23 Bank Of America Corporation Online banking digital wallet management
US9406065B2 (en) 2014-03-04 2016-08-02 Bank Of America Corporation Customer token preferences interface
US9600844B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign cross-issued token
US10002352B2 (en) 2014-03-04 2018-06-19 Bank Of America Corporation Digital wallet exposure reduction
US9721268B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation Providing offers associated with payment credentials authenticated in a specific digital wallet
CN104917738B (zh) * 2014-03-14 2018-03-16 陈衡 金融平台数据处理方法和系统
US20150302404A1 (en) * 2014-04-17 2015-10-22 James F. Ruffer Secure electronic payment system
US10614445B1 (en) 2014-06-04 2020-04-07 Square, Inc. Proximity-based payments
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
CN109889473B (zh) 2014-08-08 2021-11-19 创新先进技术有限公司 实现信息推送的方法及第三方客户端
DE102014114432B4 (de) 2014-09-08 2019-10-02 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Verfahren, Vorrichtung und Computerprogramm zum Kontrollieren eines Zugriffsauf einen Service innerhalb eines Netzwerkes
US10963868B1 (en) 2014-09-09 2021-03-30 Square, Inc. Anonymous payment transactions
US9953323B2 (en) 2014-09-23 2018-04-24 Sony Corporation Limiting e-card transactions based on lack of proximity to associated CE device
US9367845B2 (en) 2014-09-23 2016-06-14 Sony Corporation Messaging customer mobile device when electronic bank card used
US9355424B2 (en) 2014-09-23 2016-05-31 Sony Corporation Analyzing hack attempts of E-cards
US9202212B1 (en) 2014-09-23 2015-12-01 Sony Corporation Using mobile device to monitor for electronic bank card communication
US9292875B1 (en) 2014-09-23 2016-03-22 Sony Corporation Using CE device record of E-card transactions to reconcile bank record
US10262316B2 (en) 2014-09-23 2019-04-16 Sony Corporation Automatic notification of transaction by bank card to customer device
US9378502B2 (en) 2014-09-23 2016-06-28 Sony Corporation Using biometrics to recover password in customer mobile device
US9317847B2 (en) 2014-09-23 2016-04-19 Sony Corporation E-card transaction authorization based on geographic location
US9558488B2 (en) 2014-09-23 2017-01-31 Sony Corporation Customer's CE device interrogating customer's e-card for transaction information
US9646307B2 (en) 2014-09-23 2017-05-09 Sony Corporation Receiving fingerprints through touch screen of CE device
US9363267B2 (en) * 2014-09-25 2016-06-07 Ebay, Inc. Transaction verification through enhanced authentication
CA2961916C (en) * 2014-09-29 2023-10-24 Royal Bank Of Canada Secure processing of data
US9697517B1 (en) 2014-10-03 2017-07-04 State Farm Mutual Automobile Insurance Company Token generation in providing a secure credit card payment service without storing credit card data on merchant servers
WO2016061077A1 (en) * 2014-10-13 2016-04-21 Mastercard International Incorporated Method and system for direct carrier billing
EP3012996A1 (fr) * 2014-10-22 2016-04-27 Atos Worldline NV/SA Évaluation d'un niveau de confiance dans la récolte d'informations par un terminal de communication par rapport des empreintes
KR20160048600A (ko) * 2014-10-25 2016-05-04 홍승은 모바일 교차 인증 시스템 및 방법
US11966907B2 (en) 2014-10-25 2024-04-23 Yoongnet Inc. System and method for mobile cross-authentication
US9426650B2 (en) * 2014-10-31 2016-08-23 Gogo Llc Autonomous-mode content delivery and key management
US20160125371A1 (en) 2014-10-31 2016-05-05 Square, Inc. Money transfer using canonical url
EP3018876B1 (en) * 2014-11-05 2020-01-01 Vodafone IP Licensing limited Monitoring of signalling traffic
US20160342996A1 (en) * 2014-11-06 2016-11-24 Toc S.A. Two-factor authentication method
US9275389B1 (en) * 2014-11-26 2016-03-01 Paypal, Inc. Modular device payment system
US9503437B2 (en) * 2014-12-12 2016-11-22 Gn Resound A/S Apparatus for secure hearing device communication and related method
CN104519057B (zh) * 2014-12-12 2018-06-19 小米科技有限责任公司 资格授予方法、资格获取方法及装置
US9608807B2 (en) * 2014-12-12 2017-03-28 Gn Hearing A/S Hearing device with communication protection and related method
SG10201500276VA (en) * 2015-01-14 2016-08-30 Mastercard Asia Pacific Pte Ltd Method and system for making a secure payment transaction
US11354651B2 (en) 2015-01-19 2022-06-07 Royal Bank Of Canada System and method for location-based token transaction processing
EP3248159A4 (en) 2015-01-19 2018-08-01 Royal Bank Of Canada Secure processing of electronic payments
US9853977B1 (en) * 2015-01-26 2017-12-26 Winklevoss Ip, Llc System, method, and program product for processing secure transactions within a cloud computing system
EP3065366B1 (en) * 2015-03-02 2020-09-09 Bjoern Pirrwitz Identification and/or authentication system and method
US10185949B2 (en) * 2015-03-05 2019-01-22 American Express Travel Related Services Company, Inc. System and method for authentication of a mobile device configured with payment capabilities
EP3281164B1 (en) 2015-04-10 2019-06-05 Visa International Service Association Browser integration with cryptogram
US9781105B2 (en) 2015-05-04 2017-10-03 Ping Identity Corporation Fallback identity authentication techniques
US11599879B2 (en) 2015-07-02 2023-03-07 Royal Bank Of Canada Processing of electronic transactions
KR102441758B1 (ko) * 2015-07-14 2022-09-13 삼성전자주식회사 전자 장치, 인증 대행 서버 및 결제 시스템
JP2018533144A (ja) * 2015-08-10 2018-11-08 アイピーシディー，インコーポレイテッド 並列自律チャネルマルチユーザ・マルチファクタ認証に基づく取引承認の方法およびシステム
US10607215B2 (en) 2015-09-30 2020-03-31 Bank Of America Corporation Account tokenization for virtual currency resources
US10453059B2 (en) 2015-09-30 2019-10-22 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
US10291719B2 (en) * 2015-10-29 2019-05-14 Google Llc Enabling communication while limiting access to user information
US9729536B2 (en) 2015-10-30 2017-08-08 Bank Of America Corporation Tiered identification federated authentication network system
US11120443B2 (en) * 2015-11-11 2021-09-14 Visa International Service Association Browser extension with additional capabilities
US10129252B1 (en) * 2015-12-17 2018-11-13 Wells Fargo Bank, N.A. Identity management system
WO2017130292A1 (ja) * 2016-01-26 2017-08-03 株式会社ソラコム サーバ、モバイル端末及びプログラム
US20170250986A1 (en) * 2016-02-29 2017-08-31 Nextnav, Llc Systems and methods for controlling access to position information
US10579999B2 (en) * 2016-03-14 2020-03-03 Facebook, Inc. Network payment tokenization for processing payment transactions
USD798344S1 (en) 2016-03-15 2017-09-26 Samsung Electronics Co., Ltd. Refrigerator
USD798343S1 (en) 2016-03-28 2017-09-26 Samsung Electronics Co., Ltd. Refrigerator
US11017394B2 (en) * 2016-04-25 2021-05-25 Visa International Service Association System for vision impaired users to execute electronic transactions
US10460367B2 (en) 2016-04-29 2019-10-29 Bank Of America Corporation System for user authentication based on linking a randomly generated number to the user and a physical item
CN114693289A (zh) 2016-06-11 2022-07-01 苹果公司 用于交易的用户界面
US10621581B2 (en) 2016-06-11 2020-04-14 Apple Inc. User interface for transactions
DK201670622A1 (en) 2016-06-12 2018-02-12 Apple Inc User interfaces for transactions
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
SG10201605157RA (en) * 2016-06-22 2018-01-30 Mastercard Asia Pacific Pte Ltd Apparatus And Method For Controlling A Switch
US10783518B1 (en) 2016-06-29 2020-09-22 Wells Fargo Bank, N.A Systems and methods for third party token based authentication
KR102604520B1 (ko) * 2016-08-17 2023-11-22 삼성전자주식회사 온라인으로 상품을 구매하는 방법 및 장치
US20180053189A1 (en) * 2016-08-18 2018-02-22 Justin T. Monk Systems and methods for enhanced authorization response
RU2634174C1 (ru) * 2016-10-10 2017-10-24 Акционерное общество "Лаборатория Касперского" Система и способ выполнения банковской транзакции
EP3334115B1 (en) 2016-12-07 2019-10-09 Swisscom AG User authentication based on token
US20180174137A1 (en) * 2016-12-21 2018-06-21 Facebook, Inc. Providing device and system agnostic electronic payment tokens
US10574648B2 (en) 2016-12-22 2020-02-25 Dashlane SAS Methods and systems for user authentication
CN106779644B (zh) * 2017-01-21 2024-02-27 上海量明科技发展有限公司 共享单车获得支付的方法及系统
US20180232728A1 (en) * 2017-02-14 2018-08-16 Its, Inc. Payment tokenization using encryption
WO2018167570A2 (en) * 2017-03-16 2018-09-20 Age Checked Limited Secure age verification system
US10755339B2 (en) 2017-03-17 2020-08-25 Team Labs, Inc. System and method of purchase request management using plain text messages
WO2018187634A1 (en) * 2017-04-05 2018-10-11 Tbcasoft, Inc. Digital property remittance via telephone numbers through telecom carriers
WO2018191638A1 (en) 2017-04-13 2018-10-18 Equifax, Inc. Location-based detection of unauthorized use of interactive computing environment functions
US10432397B2 (en) 2017-05-03 2019-10-01 Dashlane SAS Master password reset in a zero-knowledge architecture
CN114363278B (zh) 2017-05-16 2023-06-23 苹果公司 用于消息传送的方法、电子设备以及计算机可读存储介质
US11221744B2 (en) 2017-05-16 2022-01-11 Apple Inc. User interfaces for peer-to-peer transfers
US10524165B2 (en) 2017-06-22 2019-12-31 Bank Of America Corporation Dynamic utilization of alternative resources based on token association
US10511692B2 (en) 2017-06-22 2019-12-17 Bank Of America Corporation Data transmission to a networked resource based on contextual information
US10313480B2 (en) 2017-06-22 2019-06-04 Bank Of America Corporation Data transmission between networked resources
CA3067821C (en) 2017-06-29 2021-04-27 Equifax, Inc. Third-party authorization support for interactive computing environment functions
EP3649598A1 (en) * 2017-07-05 2020-05-13 Mastercard International Incorporated System and methods for accepting dual function payment credential
US10979423B1 (en) 2017-10-31 2021-04-13 Wells Fargo Bank, N.A. Bi-directional voice authentication
US10848312B2 (en) 2017-11-14 2020-11-24 Dashlane SAS Zero-knowledge architecture between multiple systems
LT3490191T (lt) * 2017-11-22 2020-04-10 Siemens Aktiengesellschaft Paslaugų teikėjo mazgo atliekamo paslaugų užklausų apdorojimo būdas
CN107995180A (zh) * 2017-11-27 2018-05-04 深圳市千讯数据股份有限公司 避免隐私泄露的个人信息验证方法
CN107948160A (zh) * 2017-11-27 2018-04-20 深圳市千讯数据股份有限公司 避免隐私泄露的个人信息验证方法
US11449630B2 (en) 2017-12-14 2022-09-20 Equifax Inc. Embedded third-party application programming interface to prevent transmission of sensitive data
US10904004B2 (en) 2018-02-27 2021-01-26 Dashlane SAS User-session management in a zero-knowledge environment
US11687929B2 (en) * 2018-03-23 2023-06-27 American Express Travel Related Services Co., Inc. Authenticated secure online and offline transactions
CN116346461B (zh) * 2018-04-24 2025-11-25 维萨国际服务协会 高效和安全的认证系统
US11144892B2 (en) * 2018-05-18 2021-10-12 Jpmorgan Chase Bank, N.A. Methods for facilitating funds disbursements and devices thereof
US11361284B1 (en) 2018-05-31 2022-06-14 Stripe, Inc. Payment processing method and apparatus using an intermediary platform
EP3579595B1 (en) * 2018-06-05 2021-08-04 R2J Limited Improved system and method for internet access age-verification
US11240220B2 (en) * 2018-06-13 2022-02-01 Paypal, Inc. Systems and methods for user authentication based on multiple devices
CN109167802B (zh) * 2018-11-08 2021-07-13 金蝶软件（中国）有限公司 防止会话劫持的方法、服务器以及终端
CN109242488B (zh) * 2018-11-22 2022-02-18 腾讯科技（深圳）有限公司 一种安全支付控制方法、装置及服务器
US12067637B1 (en) 2019-03-29 2024-08-20 Block, Inc. Gradated service access based on identity verification (IDV)
US11250429B1 (en) * 2019-03-29 2022-02-15 Square, Inc. Identity verification (IDV) using a payment processing platform
CN110071915B (zh) * 2019-04-10 2021-08-06 创新先进技术有限公司 一种身份核实产品推送方法、装置、设备及系统架构
EP3959628B1 (en) * 2019-04-25 2024-07-03 Shazzle LLC Trusted customer identity systems and methods
US11783332B2 (en) 2020-02-14 2023-10-10 Mastercard International Incorporated Method and system for facilitating secure card-based transactions
US20210304156A1 (en) * 2020-03-24 2021-09-30 Jpmorgan Chase Bank, N.A. Systems and methods for customer identity protection from service or product providers
CN111539833B (zh) * 2020-04-10 2023-01-10 支付宝(杭州)信息技术有限公司 医疗费用支付方法、装置和系统
US11816194B2 (en) * 2020-06-21 2023-11-14 Apple Inc. User interfaces for managing secure operations
EP3933730A1 (en) * 2020-06-30 2022-01-05 Mastercard International Incorporated Realtime selection of payment account
KR102341315B1 (ko) * 2020-12-29 2021-12-22 쿠팡 주식회사 판매 관련 정보 제공 방법 및 이를 이용하는 전자 장치
US20220207630A1 (en) * 2020-12-29 2022-06-30 Toby Michael Cohen System and method for authorizing transfer requests of physical locations
US11706306B2 (en) * 2021-02-22 2023-07-18 Stripe, Inc. Location-based determinations
US11790353B2 (en) * 2021-06-16 2023-10-17 Song Hwan KIM System and method for online/offline payment with virtual currency for nodes included in mobile-based blockchain distributed network
EP4359971B1 (en) 2021-06-22 2025-10-15 Visa International Service Association Method and system for integrating identity provider
US11784956B2 (en) 2021-09-20 2023-10-10 Apple Inc. Requests to add assets to an asset account
US12450385B2 (en) 2022-07-06 2025-10-21 Dashlane SAS Integration of identity access management infrastructure with zero-knowledge services
CN117252232B (zh) * 2023-11-17 2024-06-11 金邦达有限公司 智能卡及卡体鉴别保护方法
US20250365572A1 (en) * 2024-03-20 2025-11-27 SLC Corporation System and Method for Secure-Core Silicon Mobile End-Points to Detrimne KYC and KYT
US20250365150A1 (en) * 2024-05-24 2025-11-27 Lenovo (Singapore) Pte Ltd Attribute-based credentials for resource access
IL315935A (en) * 2024-09-25 2026-04-01 Knock Nlock Ltd Devices, methods and computer code products for controlling a physical safe lock

Family Cites Families (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4405829A (en) * 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
US4906826A (en) 1988-09-19 1990-03-06 Visa International Service Association Usage promotion method for payment card transaction system
US5812686A (en) * 1992-03-24 1998-09-22 Hobelsberger; Maximilian Hans Device for active simultation of an acoustical impedance
JP3367675B2 (ja) 1993-12-16 2003-01-14 オープン マーケット インコーポレイテッド オープンネットワーク販売システム及び取引トランザクションのリアルタイムでの承認を行う方法
US5434919A (en) 1994-01-11 1995-07-18 Chaum; David Compact endorsement signature systems
US7152045B2 (en) 1994-11-28 2006-12-19 Indivos Corporation Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5892900A (en) 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5671279A (en) 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US5812668A (en) 1996-06-17 1998-09-22 Verifone, Inc. System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture
DE19630920C1 (de) 1996-07-31 1997-10-16 Siemens Ag Verfahren und System zur Teilnehmerauthentifikation und/oder Verschlüsselung von Informationen
US6557104B2 (en) * 1997-05-02 2003-04-29 Phoenix Technologies Ltd. Method and apparatus for secure processing of cryptographic keys
US6108644A (en) 1998-02-19 2000-08-22 At&T Corp. System and method for electronic transactions
JP2000036000A (ja) 1998-06-30 2000-02-02 Sun Microsyst Inc 電子商取引における中立的立会人
JP2967271B1 (ja) * 1998-07-14 1999-10-25 セイコーインスツルメンツ株式会社 撮影後に直ちにプリント可能なデジタルカメラ
US6799155B1 (en) * 1998-12-11 2004-09-28 Allied Signal Inc. Replacement of externally mounted user interface modules with software emulation of user interface module functions in embedded processor applications
US6327578B1 (en) 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
FR2790162B1 (fr) * 1999-02-19 2001-04-13 France Telecom Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
US20010051902A1 (en) 1999-06-28 2001-12-13 Messner Marc A. Method for performing secure internet transactions
AU6053700A (en) 1999-06-28 2001-01-31 Starpay.Com, Inc. Apparatus and method for performing secure network transactions
US7171694B1 (en) 1999-07-21 2007-01-30 E-Payments Method for performing a transaction over a network
JP3312335B2 (ja) * 1999-07-30 2002-08-05 株式会社コムスクエア 利用者認証方法、利用者認証システムおよび記録媒体
US6792536B1 (en) 1999-10-20 2004-09-14 Timecertain Llc Smart card system and methods for proving dates in digital files
US7003789B1 (en) 1999-12-21 2006-02-21 International Business Machines Corporation Television commerce payments
AU3086101A (en) 2000-01-05 2001-07-16 American Express Travel Related Services Company, Inc. Smartcard internet authorization system
FI112286B (fi) 2000-01-24 2003-11-14 Smarttrust Systems Oy Maksupalvelulaitteisto ja menetelmä turvalliseksi maksamiseksi
FI20000760A0 (fi) 2000-03-31 2000-03-31 Nokia Corp Autentikointi pakettidataverkossa
US20020026374A1 (en) * 2000-05-02 2002-02-28 Moneymaker Vincent B. Comprehensive third-party transactional processing and payment in an online environment
KR100912613B1 (ko) 2000-05-25 2009-08-17 이촤지 코포레이션 보안 트랜잭션 프로토콜
CA2320514A1 (en) 2000-09-19 2002-03-19 Payplease.Com System for and method of effecting payments online and offline
JP2002141900A (ja) * 2000-11-01 2002-05-17 Nec Corp モバイルコンピューティングサービスシステム
US7203158B2 (en) * 2000-12-06 2007-04-10 Matsushita Electric Industrial Co., Ltd. OFDM signal transmission system, portable terminal, and e-commerce system
JP2002207929A (ja) 2001-01-12 2002-07-26 Nippon Telegr & Teleph Corp <Ntt> 顧客認証方法、その装置、プロバイダ装置及びその処理方法、販売サービス提供装置及びその処理方法
US6931382B2 (en) 2001-01-24 2005-08-16 Cdck Corporation Payment instrument authorization technique
US20020123972A1 (en) 2001-02-02 2002-09-05 Hodgson Robert B. Apparatus for and method of secure ATM debit card and credit card payment transactions via the internet
WO2002067545A2 (en) 2001-02-17 2002-08-29 Inktomi Corporation Content based billing
RU2182725C1 (ru) 2001-02-20 2002-05-20 Общество с ограниченной ответственностью "КИБЕРПЛАТ.КОМ" Система для управления совершением сделок
US20020147820A1 (en) 2001-04-06 2002-10-10 Docomo Communications Laboratories Usa, Inc. Method for implementing IP security in mobile IP networks
WO2002086829A1 (en) 2001-04-16 2002-10-31 Mobile Solutions And Payment Services Pte Ltd Method and system for performing a transaction utilising a thin payment network (mvent)
US7243370B2 (en) * 2001-06-14 2007-07-10 Microsoft Corporation Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication
US7047560B2 (en) 2001-06-28 2006-05-16 Microsoft Corporation Credential authentication for mobile users
US7269737B2 (en) 2001-09-21 2007-09-11 Pay By Touch Checking Resources, Inc. System and method for biometric authorization for financial transactions
DE10149298A1 (de) 2001-10-05 2003-04-17 Siemens Ag Verfahren zum elektronischen Zustellen und Begleichen von Rechnungen
JP3899890B2 (ja) 2001-10-18 2007-03-28 日本電信電話株式会社 課金方法及びシステム及び購入制御端末及び認証課金サーバ及び販売サーバ及び課金プログラム及び課金プログラムを格納した記憶媒体
JP2003168035A (ja) 2001-12-04 2003-06-13 Senshukai General Service Co Ltd クライアントの詳細情報取得方法
US7996888B2 (en) 2002-01-11 2011-08-09 Nokia Corporation Virtual identity apparatus and method for using same
AU2003207870B2 (en) 2002-02-27 2007-03-22 Teleglobal International Ltd. Method and apparatus for secure electronic payment
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US6880079B2 (en) * 2002-04-25 2005-04-12 Vasco Data Security, Inc. Methods and systems for secure transmission of information using a mobile device
US8060139B2 (en) * 2002-06-24 2011-11-15 Toshiba American Research Inc. (Tari) Authenticating multiple devices simultaneously over a wireless link using a single subscriber identity module
GB2396707B (en) 2002-10-17 2004-11-24 Vodafone Plc Facilitating and authenticating transactions
JP5078257B2 (ja) 2003-08-28 2012-11-21 インターナショナル・ビジネス・マシーンズ・コーポレーション 属性情報提供サーバ、属性情報提供方法、およびプログラム
EP1517475A1 (en) * 2003-09-16 2005-03-23 Axalto S.A. Smart card based encryption in Wi-Fi communication
GB2406925B (en) 2003-10-09 2007-01-03 Vodafone Plc Facilitating and authenticating transactions
US20050114261A1 (en) 2003-11-21 2005-05-26 Chuang Guan Technology Co., Ltd. Payment system for using a wireless network system and its method
WO2005064881A1 (en) * 2003-12-30 2005-07-14 Telecom Italia S.P.A. Method and system for protecting data, related communication network and computer program product
TWI249316B (en) * 2004-02-10 2006-02-11 Ind Tech Res Inst SIM-based authentication method for supporting inter-AP fast handover
JP5032842B2 (ja) * 2004-03-26 2012-09-26 パナソニック株式会社 表示処理装置及び表示処理方法
US8522039B2 (en) 2004-06-09 2013-08-27 Apple Inc. Method and apparatus for establishing a federated identity using a personal wireless device
CA2512975A1 (en) * 2004-07-22 2006-01-22 Tvidia Corporation System and method for secure data distribution and retrieval using encrypted media
US20060048236A1 (en) * 2004-09-01 2006-03-02 Microsoft Corporation Licensing the use of software to a particular user
EP1807966B1 (en) * 2004-10-20 2020-05-27 Salt Group Pty Ltd. Authentication method
US8543814B2 (en) * 2005-01-12 2013-09-24 Rpx Corporation Method and apparatus for using generic authentication architecture procedures in personal computers
US7849020B2 (en) 2005-04-19 2010-12-07 Microsoft Corporation Method and apparatus for network transactions
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions

Also Published As

Publication number Publication date
JP2009534739A (ja) 2009-09-24
EP2016543A4 (en) 2011-04-27
EP2016543A1 (en) 2009-01-21
CA2645949A1 (en) 2007-11-01
US20060235796A1 (en) 2006-10-19
US20140351146A1 (en) 2014-11-27
BRPI0710283A2 (pt) 2011-08-09
KR20090006831A (ko) 2009-01-15
US8996423B2 (en) 2015-03-31
CN101427268A (zh) 2009-05-06
RU2008141288A (ru) 2010-04-27
AU2007241160A1 (en) 2007-11-01
EP2016543B1 (en) 2021-05-26
WO2007123596A1 (en) 2007-11-01

Similar Documents

Publication Publication Date Title
AU2006236243B2 (en) Network commercial transactions
US8996423B2 (en) Authentication for a commercial transaction using a mobile module
US20060235795A1 (en) Secure network commercial transactions
US7849020B2 (en) Method and apparatus for network transactions
US5850442A (en) Secure world wide electronic commerce over an open network
CN100422988C (zh) 以用户为中心的上下文知晓转换模型
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
US20070299739A1 (en) Electronic Commerce System and Electronic Commerce Method
JP2008257721A (ja) バリューベースの取引において使用可能なトークン
JP2004511028A (ja) 情報を安全に収集、格納、及び送信する方法及びシステム
RU2402814C2 (ru) Сетевые коммерческие транзакции
CN112970234A (zh) 账户断言
CN102592239A (zh) 网络商业交易
JP2005512225A (ja) 埋込コンテンツの自動化された権利管理及び支払いシステム
KR20230033552A (ko) 블록체인 기반 자산 관리 시스템 및 방법
KR20240001416A (ko) 블록체인 기반의 nft를 이용한 음원 플랫폼의 서버에서 수행되는 서비스 제공 방법
AU2011202945B2 (en) Network commercial transactions
KR20020003084A (ko) 클라이언트 결제 애플리케이션을 이용한 인터넷 기반 전자 상거래의 결제 서비스 제공 방법
JP2002352172A (ja) 電子商取引方法及び電子商取引装置

Legal Events

Date Code Title Description
FA Abandonment or withdrawal