MX2011000653A - Sistemas y metodos para transferir valor. - Google Patents

Abstract

Se proveen sistemas y métodos para transferir un valor de un primer usuario a un segundo usuario utilizando códigos sustancialmente aleatorios que están asociados con los valores a ser transferidos. Una autoridad confiable les permite a los usuarios crear cuentas de usuario utilizadas para almacenar un valor. Un primer usuario puede solicitar un código de pago, que está asociado con un valor especificado, y puede ser comunicado con un segundo usuario, que puede presentar el código de pago a la autoridad confiable. Si el código de pago es válido, la autoridad confiable debita el valor especificado de la cuenta del primer usuario y acredita el valor especificado en la cuenta del segundo usuario. En forma alternativa, un segundo usuario puede solicitar un código de facturación, que está asociado con un valor especificado, y puede ser comunicado con el primer usuario, que puede presentar el código de facturación a la autoridad confiable. Si el código de facturación es válido, la autoridad confiable debita el valor especificado de la cuenta del primer usuario y acredita el valor especificado en la cuenta del segundo usuario.

Description

SISTEMAS Y MÉTODOS PARA TRANSFERIR VALOR ANTECEDENTES Existen varias técnicas que les permiten a las personas transferir divisas y abonar productos y servicios. En las transacciones de persona a persona, una parte puede transferir divisas a otra parte en forma directa, como ser un regalo, n pago de un préstamo, un salario, o un pago de productos comprados a la otra parte o de servicios prestados por ella. En forma adicional, se han desarrollado varias técnicas de pago para facilitar los pagos sin la necesidad de efectuar transferencias monetarias directas, como ser cheques, giros postales, cheques de viajero, tarjetas de débito, tarjetas regalo, tarjetas de crédito, vales, depósito directo y transferencias bancarias electrónicas. Además, en lo últimos años, se han desarrollado sistemas de pago adicionales, como ser Paypal y varios sistemas monetarios electrónicos, como sistemas monetarios alternativos. Aunque todas esas técnicas proveen, en forma ventajosa, alternativas para intercambios directos de divisas, cada técnica presenta diversas limitaciones.

En particular, la mayoría de los sistemas monetarios alternativos ya conocidos presentan varias cuestiones respecto de privacidad y fraudes. Por ejemplo, cuando un consumidor compra bienes a un comerciante utilizando una tarjeta de crédito o débito, el comerciante puede requerir una cantidad significativa de información respecto del consumidor como parte de la transacción, incluso el nombre y apellido del consumidor y el número de su tarjeta de crédito/débito, la fecha de vencimiento, el número de valor de verificación de tarjeta ("CW"), su domicilio u otros datos financieros. Varios comerciantes almacenan dichos datos personales en grandes bases de datos que pueden estar sujetas a un acceso no autorizado. En realidad, se han presentado varios casos en los últimos años donde los comerciantes no lograron proteger de manera adecuada la seguridad de los datos de la tarjeta de crédito del consumidor, y varios consumidores fueron víctimas de fraudes y robos de identidad como resultado de dichas fallas. Asimismo, es comprensible que varios consumidores se muestren reacios a comunicar información de identificación personal que pueda relacionarse con adquisiciones de productos y servicios, como ser material de lectura, vídeos, servicios de compañía, y otros productos y servicios similares, que luego pueda ser verificada por funcionarios a cargo del cumplimiento de la ley u otros funcionarios del gobierno, o que pueda ser, de otro modo, información que un consumidor no pretenda divulgar.

En forma adicional, algunos métodos de pago ya conocidos presentan cargas significativas para comerciantes. Con el fin de evitar una potencial responsabilidad a víctimas de robo de identidad, la mayoría de los comerciantes incurre en un gasto general significativo para desarrollar técnicas para proteger la seguridad de información financiera personal recibida con relación a transacciones de tarjetas de crédito y tarjetas de débito. Asimismo, varias empresas de tarjetas de crédito imponen penalidades por rechazo de débito si un consumidor cuestiona una compra efectuada con una tarjeta de crédito. Además, varios comerciantes continúan sufriendo pérdidas que son resultado de cheques rechazados por fondos insuficientes.

Así, se considera conveniente proveer sistemas y métodos que permitan transferencias de valores, como ser transferencias monetarias, y que provean anonimato y eviten varios de los problemas de privacidad y fraudes asociados con los sistemas de pago ya conocidos.

SÍNTESIS Pueden utilizarse sistemas y métodos de acuerdo con esta invención para transferir un valor entre usuarios utilizando códigos sustancialmente aleatorios que están asociados con los valores a ser transferidos. En particular, una autoridad confiable les permite a los usuarios crear cuentas de usuario que pueden utilizarse para almacenar un valor. Los usuarios pueden solicitar códigos a la autoridad confiable para transferir un valor a otros usuarios, y los códigos pueden incluir códigos de pago y/o códigos de facturación.

Por ejemplo, un primer usuario puede solicitar un código de pago para transferir un valor especificado a un segundo usuario. Si la cuenta del primer usuario incluye el valor especificado, la autoridad confiable genera un código de pago sustancialmente aleatorio asociado con el valor especificado. Luego, el primer usuario puede comunicar el código de pago al segundo usuario, que luego puede presentar el código de pago a la autoridad confiable. Si el código de pago es válido (por ejemplo, un usuario lo solicitó pero aún no ha sido presentado para el pago) , la autoridad confiable debita el valor especificado de la cuenta del primer usuario y acredita el valor especificado en la cuenta del segundo usuario.

En forma alternativa, un primer usuario puede solicitar un código de facturación para recibir un valor especificado de un segundo usuario. La autoridad confiable genera un código de facturación sustancialmente aleatorio asociado con el valor especificado. Luego, el primer usuario puede comunicar el código de facturación al segundo usuario, que luego puede presentar el código de facturación a la autoridad confiable. Si el código de facturación es válido (por ejemplo, un usuario lo solicitó pero aún no ha sido presentado para el pago) y si la cuenta del segundo usuario incluye el valor especificado, la autoridad confiable debita el valor especificado de la cuenta del segundo usuario y acredita el valor especificado en la cuenta del primer usuario.

Para mayor seguridad, pueden utilizarse códigos de retorno. En particular, un primer usuario puede solicitar un código de pago para transferir un valor especificado a un segundo usuario y puede solicitar un código de retorno. Si la cuenta del primer usuario incluye el valor especificado, la autoridad confiable genera un primer código de pago y un segundo código de pago sustancialmente aleatorios asociados con el valor especificado, y comunica el primer código de pago al primer usuario. Luego, el primer usuario puede comunicar el primer código de pago al segundo usuario, que luego puede presentar él primer código de pago a la autoridad confiable. Si el primer código de pago es válido (por ejemplo, un usuario lo solicitó pero aún no ha sido presentado para el pago) , la autoridad confiable, comunica el segundo código de pago al segundo usuario. Luego, el segundo usuario puede comunicar el segundo código de pago al primer usuario, que luego puede presentar el segundo código de pago a la autoridad confiable. Si el segundo código de pago es válido (por ejemplo, un usuario lo solicitó pero aún no ha sido presentado para el pago) , la autoridad confiable debita el valor especificado de la cuenta del primer usuario y acredita el valor especificado en la cuenta del segundo usuario.

En forma alternativa, un primer usuario puede solicitar un código de facturación para recibir un valor especificado de un segundo usuario y puede solicitar un código de retorno. La autoridad confiable genera un primer código de facturación y un segundo código de facturación sustancialmente aleatorios asociados con el valor especificado y comunica el primer código de facturación al primer usuario. Luego, el primer usuario puede comunicar el primer código de facturación al segundo usuario, que luego puede presentar el primer código de facturación a la autoridad confiable. Si el primer código de facturación es válido (por ejemplo, un usuario lo solicitó pero aún no ha sido presentado para el pago) , la autoridad confiable comunica el segundo código de facturación al segundo usuario. Luego, el segundo usuario puede comunicar el segundo código de facturación al primer usuario, que luego puede presentar el segundo código de facturación a la autoridad confiable. Si el segundo código de facturación es válido (por ejemplo, un usuario lo solicitó pero aún no ha sido presentado para el pago) y si la cuenta del segundo usuario incluye el valor especificado, la autoridad confiable debita el valor especificado de la cuenta del segundo usuario y acredita el valor especificado en la cuenta del primer usuario.

Los sistemas y métodos ilustrativos de acuerdo con esta invención incluyen o proveen una autoridad confiable que incluye un almacenamiento de valores utilizado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que incluye cuentas de usuarios, cada cuenta de usuario que está asociada con un usuario correspondiente y que cuenta con una lista del valor almacenado que pertenece al usuario correspondiente, donde la autoridad confiable está adaptada para recibir una solicitud de un primer usuario para asociar un código con un valor especificado, generar un código sustancialmente aleatorio, asociar el código generado con el valor especificado, comunicar el código generado al primer" usuario, recibir el código generado de un segundo usuario, determinar si el código recibido es válido, y, si el código recibido es válido, debitar el valor especificado de la cuenta del primer usuario y acreditar el valor especificado en la cuenta del segundo usuario para transferir la titularidad del valor especificado del primer usuario al segundo usuario.

Los sistemas y métodos ilustrativos de acuerdo con esta invención incluyen o proveen, además, una autoridad confiable que incluye un almacenamiento de valores utilizado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que incluye cuentas de usuarios, cada cuenta de usuario que está asociada con un usuario correspondiente y que cuenta con una lista del valor almacenado que pertenece al usuario correspondiente, donde la autoridad confiable está adaptada para recibir una solicitud de un primer usuario, para asociar un código con un valor especificado, generar un código sustancialmente aleatorio, asociar el código generado con el valor especificado, comunicar el código generado al primer usuario, recibir el código generado de un segundo usuario, determinar si el código recibido es válido, y, si el código recibido es válido, debitar el valor especificado de la cuenta del segundo usuario y acreditar el valor especificado en la cuenta del primer usuario para transferir la titularidad del valor especificado del segundo usuario al primer usuario.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Las prestaciones de la presente invención pueden comprenderse con mayor claridad a partir de la siguiente descripción detallada, considerada junto con los siguientes dibujos, donde los mismos números de referencia indican los mismos elementos en las diversas vistas, y donde la Figura 1 es un diagrama de bloque de un sistema ilustrativo de acuerdo con esta invención; la Figura 2 es un diagrama de bloque de una autoridad confiable ilustrativa de acuerdo con esta invención; la Figura . 3 es un diagrama de bloque de un generador de códigos ilustrativo de acuerdo con esta invención; la Figura 4 es un diagrama de una base de datos de cuentas ilustrativa de acuerdo con esta invención; la Figura 5 es un diagrama de una base de datos de códigos ilustrativa de acuerdo con esta invención; la Figura 6 es un diagrama de una página de registro de interfaz de usuario ilustrativa de acuerdo con esta invención; - la Figura 7 es un diagrama de una página de inicio de interfaz de usuario ilustrativa de acuerdo con esta invención; la Figura 8 es un diagrama de una página de cuentas externas vinculadas de interfaz de usuario ilustrativa de acuerdo con esta invención; las Figuras 9A a 9D son diagramas de páginas de cuentas externas de enlace de interfaz de usuario ilustrativas de acuerdo con esta invención; las Figuras 10A a 10E son diagramas de páginas de transferencia de cuentas externas de interfaz de usuario ilustrativas de acuerdo con esta invención; la Figura 11 es un diagrama de transferencias ilustrativas de valor entre cuentas externas, una autoridad confiable y usuarios de acuerdo con esta invención; las Figura 12A a 12D son otros diagramas de una base de datos de cuentas ilustrativa de acuerdo con esta invención; la Figura 13 es otro diagrama de una página de inicio de interfaz.de usuario ilustrativa de acuerdo con esta invención; la Figura 14 es un diagrama de una página de saldo de cuenta de interfaz de usuario ilustrativa de acuerdo con esta invención; - las Figuras 15A a 15C son diagramas de paginas de interfaz de usuario ilustrativas para solicitar un código de pago asociado con un valor monetario de acuerdo con esta invención; la Figura 16 es un diagrama de una base de datos de ¦ cuentas ilustrativa de acuerdo con esta invención luego de las transacciones ilustradas en las Figuras 15A a 15C; las Figuras 17A a 17C son diagramas de paginas de interfaz de usuario ilustrativas para solicitar un código de facturación asociado con un valor monetario de acuerdo con . esta invención; la Figura 18 es un diagrama de una base de datos de cuentas ilustrativa de acuerdo con esta invención luego de las transacciones ilustradas en las Figuras 17A a 17C; - las Figuras 19A a 19C son diagramas de paginas de interfaz de usuario ilustrativas para solicitar un código de pago de retorno asociado con un valor de servicio de acuerdo con esta invención; la Figura 20 es un diagrama de una base de datos de cuentas ilustrativa de acuerdo con esta invención luego de las transacciones ilustradas en las Figuras 19A a 19C; las Figuras 21A a 21C son diagramas de paginas de interfaz de usuario ilustrativas para solicitar un código de facturación de retorno asociado con un valor de producto de acuerdo con esta invención; la Figura 22 es un diagrama de una base de datos de cuentas ilustrativa de acuerdo con esta invención luego de las transacciones ilustradas en las Figuras 21A a 21C; la Figura 23 es un diagrama de una base de datos de códigos ilustrativa luego de las transacciones de las Figuras 15A a 15C, 17A a 17C, 19A a 19C y 21A a 21C; la Figura 24 es otro diagrama de una página de inicio de interfaz de usuario ilustrativa de acuerdo con esta invención; las Figuras 25A y 25B son diagramas de páginas de interfaz de usuario ilustrativas para presentar un código de pago de acuerdo con esta invención; la Figura 26 es un diagrama de una base de datos de cuentas ilustrativa luego de las transacciones de las Figuras 25A y 25B; las Figuras 27A a 27C son diagramas de páginas de interfaz de usuario ilustrativas para presentar un código de facturación de acuerdo con esta invención; - la Figura 28 es un diagrama de una base de datos de cuentas ilustrativa luego de las transacciones de las Figuras 27A a 27C; las Figuras 29A y 29B son diagramas de páginas de interfaz de usuario ilustrativas para presentar un primer código de pago de retorno de. acuerdo con esta invención; la Figura 30 es un diagrama de una base de datos de cuentas ilustrativa luego de las transacciones de las Figuras 29A y 29B; la Figura 31 es un diagrama de una página de interfaz de usuario ilustrativa para presentar un segundo código de pago de retorno de acuerdo con esta invención; la Figura 32 es un diagrama de una base de datos de cuentas ilustrativa luego de la transacción de la Figura 31; las Figuras 33A y 33B son diagramas de páginas de interfaz de usuario ilustrativas para presentar un primer código de facturación de retorno de acuerdo con esta invención; la Figura 34 es un diagrama de una base de datos de cuentas ilustrativa luego de las transacciones de las Figuras 33A y 33B; la Figura 35 es un diagrama de una página de interfaz de usuario ilustrativa para presentar un segundo código de facturación de retorno de acuerdo con esta invención; la Figura 36 es un diagrama de una base de datos de cuentas ilustrativa luego de la transacción de la Figura 35; la Figura 37 es un diagrama de una transferencia de código de pago ilustrativa de acuerdo con esta invención; - la Figura 38 es un diagrama de una transferencia de código de facturación ilustrativa de acuerdo con esta invención; la Figura 39 es un diagrama de una transferencia de código de pago de retorno ilustrativa de acuerdo con esta invención; la Figura 40 es un diagrama de una transferencia de código de facturación de retorno ilustrativa de acuerdo con esta invención; la Figura 41 es un diagrama de un procedimiento ilustrativo implementado por una autoridad confiable para una transferencia de código de pago de acuerdo con esta invención; la Figura 42 es un diagrama de un procedimiento ilustrativo implementado por una autoridad confiable para una transferencia de código de facturación de acuerdo con esta invención; las Figuras 43A y 43B son diagramas de un procedimiento ilustrativo implementado por una autoridad confiable para una transferencia de código de pago de retorno de acuerdo con esta invención; y las Figuras 44A y 44B son diagramas de un procedimiento ilustrativo implementado por una autoridad confiable para una transferencia de código de facturación de retorno de acuerdo con esta invención.

DESCRIPCIÓN DETALLADA Pueden utilizarse sistemas y métodos de acuerdo con esta invención para transferir un valor entre usuarios utilizando códigos sustancialmente aleatorios que están asociados con los valores a ser transferidos.

Con referencia ahora a la Figura 1, se describe un sistema de transferencia de valor 10 ilustrativo de acuerdo con esta invención. El sistema de transferencia de valor 10 incluye una autoridad confiable 12 acoplada a entidades externas 14 y usuarios 16. La autoridad confiable 12 les permite a los usuarios 16 ' crear cuentas de usuario individuales ("cuentas de AC" ) que pueden utilizarse para almacenar un valor. Los usuarios 16 pueden vincular sus cuentas de AC a las cuentas de usuario en entidades externas 14 ("cuentas externas"), transferir un valor entre sus cuentas externas y cuentas de AC y transferir un valor a otros usuarios 16 utilizando códigos transíeribles ("Códigos") que son generados por la autoridad confiable 12 y que están asociados con el valor a ser transferido.

En particular, los usuarios 16 pueden solicitar Códigos de pago ("Códigos P" ) y/o Códigos de facturación ("Código F" ) a la autoridad confiable 12 para transferir un valor entre cuentas de AC de usuarios. Específicamente, los Códigos pueden utilizarse para transferir un valor de la cuenta de AC de un primer usuario 16 (mencionado en la presente como "Pagador") a la cuenta de AC de un segundo usuario 16 (mencionado en la presente como "Beneficiario"). Por ejemplo, un Pagador puede solicitar un Código P a la autoridad confiable 12 para transferir un valor especificado a un Beneficiario. El Pagador le comunica el Código P al Beneficiario, que presenta el Código P a la autoridad confiable 12. Si el Código P es válido (por ejemplo, no ha sido previamente presentado para el pago) , una autoridad confiable 12 debita el valor especificado de la cuenta de AC del Pagador y acredita el valor especificado en la cuenta de AC del Beneficiario.

En forma alternativa, el Beneficiario puede solicitar un Código F para recibir un valor especificado del Pagador. El Beneficiario le comunica el Código F al Pagador, que presenta el Código F a la autoridad confiable 12. Si el Código F es válido (por ejemplo, no ha sido previamente presentado para el pago) , la autoridad confiable 12 debita el valor especificado de la cuenta de AC del Pagador y acredita el valor especificado en la cuenta de AC del Beneficiario. Para mayor seguridad, los Pagadores pueden solicitar Códigos de pago de retorno ("Códigos PR" ) y los Beneficiarios pueden solicitar Códigos de facturación de retorno ("Códigos FR" ) . A continuación se describirán detalles adicionales respecto del uso de los diversos tipos de Código.

Una autoridad confiable 12 puede ser implementada por una entidad financiera, como ser un banco tradicional, una entidad de ahorro y préstamo, una cooperativa de crédito u otra entidad financiera tradicional similar, o puede ser implementada por una persona física, una sociedad, una entidad sin fines de lucro, una asociación, una agencia gubernamental, u otra entidad o persona similar. Las entidades externas 14 pueden ser entidades financieras, depositarios, proveedores de servicios, u otras entidades similares o combinaciones de dichas entidades. Los usuarios 16 pueden ser personas físicas, grupos, organizaciones, comerciantes, vendedores, proveedores, u otros usuarios similares o combinaciones de dichos usuarios.

Las entidades externas 14 y los usuarios 16 pueden comunicarse con una autoridad confiable 12 a través de una red de área local, una red de área extensa, una red pública de telefonía conmutada, una red celular, una red de televisión por cable, una red satelital, una red inalámbrica, Internet, o combinaciones de dichas redes. Las entidades externas 14 pueden comunicarse con una autoridad confiable 12 a través de una primera red, y los usuarios 16 pueden comunicarse con la autoridad confiable a través de una segunda red que sea igual que la primera red o se diferencie de ella. Para mayor simplicidad, la descripción restante se refiere a las comunicaciones entre una autoridad confiable 12 y entidades externas 14 y usuarios 16 por Internet. Con preferencia, dichas comunicaciones se establecen a través de conexiones seguras, como ser una conexión de red segura encriptada de SSL u otra conexión segura similar.

Autoridad confiable Con referencia ahora a la Figura 2, se describe una forma de realización ilustrativa de una autoridad confiable 12. La autoridad confiable 12 incluye un controlador 20, una interfaz de usuario 22, una interfaz de entidad externa 24, una base de datos de cuentas 26, una base de datos de códigos 28 y un almacenamiento de valores 30. El controlador 20 puede ser una computadora personal, una laptop, una unidad principal, un servidor de computación, una computadora manual, u otro dispositivo de computación similar. El controlador 20 puede incluir un medio que puede leerse vía una computadora (que no se muestra) con instrucciones ejecutables de computación para llevar a cabo métodos de acuerdo con la invención. El controlador 20 puede incluir un generador de códigos 32 para generar Códigos que son solicitados por los usuarios 16 y que están asociados con un valor que puede transferirse entre cuentas de AC de usuario de acuerdo con esta invención.

De acuerdo con lo descrito en forma más detallada a continuación, una interfaz de usuario 22 les permite a los usuarios 16 crear cuentas de AC, vincular cuentas de AC a cuentas externas en entidades externas 14, transferir un valor entre cuentas de AC y cuentas externas, y transferir un valor a otros usuarios 16 utilizando Códigos asociados con el valor especificado. Una interfaz de entidad externa 24 le permite a una autoridad confiable 12 transferir un valor entre cuentas de AC y cuentas externas en entidades externas 14.

Una base de datos de cuentas 26 almacena datos asociados con cuentas de AC, y una base de datos de códigos 28 almacena datos referidos a los Códigos que son generados por un generador de códigos 32 y que están asociados con un valor que puede transferirse entre cuentas de AC de usuarios. La base de datos de cuentas 26 y la base de datos de códigos 28 pueden almacenarse en una memoria de computadora (no mostrada), como ser un disco rígido, un disquete, un disco óptico, una memoria magnética, una memoria de acceso aleatorio, una memoria flash, u otro dispositivo de memoria similar. La base de datos de cuentas 26 y la base de datos de códigos 28 pueden almacenarse en un único dispositivo de memoria, o en múltiples dispositivos de memoria, y pueden incluir una única base de datos o múltiples bases de datos. De acuerdo con lo descrito en forma más detallada a continuación, un almacenamiento de valores 30 almacena un valor, indicaciones de valor o indicaciones de titularidad de un valor transferido a cuentas de AC o desde ellas. Un almacenamiento de valores 30 puede ser una bóveda, una cuenta financiera, una base de datos electrónica, un depósito, u otro lugar de almacenamiento de valores similar o una combinación de dichos lugares de almacenamiento.

Pueden combinarse diversos componentes de una autoridad confiable 12. Por ejemplo, un controlador 22 puede incluir hardware y/o software para implementación de una interfaz de usuario 22 y/o una interfaz de entidad externa 24. En forma adicional, uno o más componentes de una autoridad confiable 12 pueden posicionarse en una única ubicación, o pueden distribuirse a través de múltiples ubicaciones. Por ejemplo, un controlador 20 puede implementarse en múltiples servidores de computación distribuidos en una primera región geográfica, y un almacenamiento de valores 30 puede implementarse en múltiples lugares de almacenamiento de valores distribuidos en una segunda región geográfica. La primera región geográfica y la segunda región geográfica pueden ser las mismas o diferentes.

Con referencia ahora a la Figura 3, se describe un generador de códigos 32 ilustrativo. El generador de códigos 32 incluye un' generador de caracteres aleatorios 34, y puede incluir, en forma opcional, un modificador de nivel de seguridad 36 y un combinador de códigos 38. El generador de caracteres aleatorios 34 puede incluir un generador convencional de números aleatorios de hardware y/o software tal como se conoce en el arte. Bajo la supervisión del controlador 20, el generador de caracteres aleatorios 34 genera un código de sistema aleatorio CS que puede incluir una cantidad predeterminada de caracteres, como ser números, letras, caracteres especiales (por ejemplo, *, %, #, +, etc.) u otros caracteres similares. No es necesario que el código de sistema CS incluya información alguna que pueda utilizarse para identificar al usuario 16 que solicitó el Código, o el valor asociado con el código de sistema CS . Los expertos en el arte comprenderán que, en forma adicional o alternativa a la generación de caracteres, el generador de códigos 32 puede generar códigos de sistema CS que incluyen códigos de barras, códigos de audio, códigos binarios, códigos de Braille, códigos de indicadores de semáforos, u otros códigos similares .

El controlador 20 puede utilizar un modificador de nivel de sistema opcional 36 para controlar la cantidad de caracteres u otro parámetro similar de código de sistema CS para controlar la seguridad del código de sistema CS creado. Por ejemplo, la longitud de código de sistema CS puede ser aumentada para reducir la probabilidad de que un usuario no autorizado pueda adivinar los códigos. Puede darse salida al código de sistema CS en forma directa como un Código, o, en forma opcional, puede combinarse con un código especificado por un usuario CU utilizando un combinador de códigos opcional 38. El combinador de códigos 38 puede concatenar los caracteres de CS y CU, puede intercalar los caracteres de CS y CU, o puede llevar a cabo combinaciones y/o manipulaciones más complejas de los caracteres de CS y CU.

Una vez más con referencia a la Figura 2, una interfaz de usuario 22 puede incluir hardware y/o software que les permita a los usuarios 16 crear Cuentas de AC, vincular cuentas de AC a cuentas en entidades externas 14, transferir un valor entre cuentas de AC y cuentas externas, y transferir un valor a otros usuarios 16 utilizando Códigos asociados con el valor especificado. Por ejemplo, una interfaz de usuario 22 puede incluir un servidor web que aloja páginas web a las que los usuarios 16 pueden acceder por medio de navegadores web ejecutados en computadoras personales, laptops, computadoras manuales, teléfonos celulares habilitados para navegación web, y otros dispositivos de computación similares. En forma adicional o alternativa, una interfaz de usuario 22 puede incluir una interfaz de teléfono, una interfaz de correo electrónico, una interfaz de mensajes de texto, una interfaz humana u otra interfaz similar que les permita a los usuarios 16 acceder a Cuentas de AC de acuerdo con lo descrito anteriormente. Para mayor simplicidad, una interfaz de usuario 22 será descrita en la descripción restante como una interfaz web.

Una interfaz de entidad externa 24 puede incluir hardware y/o software que le permita a una autoridad confiable 12 transferir un valor entre cuentas de AC y cuentas externas. Por ejemplo, una interfaz de entidad externa 24 puede incluir hardware y/o software para implementacion de protocolos de transferencia electrónica de fondos, protocolos de transferencia bancaria electrónica, u otros protocolos de transferencia de fondos similares. En forma adicional o alternativa, una interfaz de entidad externa 24 puede incluir hardware y/o software que puede utilizarse para transferir un valor no monetario entre cuentas de AC y cuentas externas. Por ejemplo, una interfaz de entidad externa 24 puede incluir hardware y/o software para iniciar envíos de productos por correo, servicio de mensajería (por ejemplo, UPS, FEDEX, DHL) , u otro servicio de entrega de productos similar. En forma adicional o alternativa, una interfaz de usuario 24 puede incluir una interfaz de teléfono, una interfaz de correo electrónico, una interfaz de mensajes de texto, una interfaz humana u otra interfaz similar que permita la transferencia de un valor entre cuentas de AC y cuentas externas .

Con referencia ahora a la Figura 4, se describe una base de datos de cuentas 26 ilustrativa. La base de datos de cuentas 26 incluye datos asociados con cuentas de AC de usuarios. Por ejemplo, una base de datos de cuentas 26 incluye un campo de nombre de usuario 40 que almacena nombres de usuarios asociados con cada cuenta de AC, un campo de número de identificación personal ("PIN") 42 que almacena un PIN u otro código de seguridad similar asociado con cada cuenta de AC que es seleccionado por el usuario 16 durante el procedimiento de configuración de cuenta de AC, un campo de valor 44 que almacena información referida al valor en cada cuenta de AC, un campo de Código abierto 46 que almacena Códigos abiertos solicitados para cada cuenta de AC, y un campo de cuentas externas vinculadas 48 que almacena información referida a cuentas externas vinculadas a cada cuenta de AC. Los expertos en el arte comprenderán que las bases de datos de cuentas 26 de acuerdo con esta invención pueden incluir, por ejemplo, una mayor cantidad de campos, una menor cantidad de campos y/o campos que se diferencien de los campos ilustrativos mostrados en la Figura 4.

El valor almacenado en cuentas de AC puede incluir cualquier divisa, producto y/o servicio y/u otro valor similar. De acuerdo con ello, una base de datos de cuentas 26 puede incluir subcampos de valor para divisas 50, productos 52 y servicios 54. Cada subcampo de valor incluye una denominación y una cantidad. En la forma de realización ilustrada, las denominaciones de valor para divisas, productos y servicios son "unidades", "nombre", y "descripción", respectivamente. Así, las divisas 50 pueden incluir subcampos para unidades 56 y cantidad 58, los productos 52 pueden incluir subcampos para nombre 60 y cantidad 62, y los servicios 54 pueden incluir subcampos para descripción 64 y cantidad 66. En forma similar, las cuentas externas 48 pueden incluir subcampos para el nombre 68 y número de cuenta y número de seguimiento/seguridad 70 asociado con la cuenta externa.

La base de datos de cuentas 26 ilustrativa mostrada en la Figura 4 incluye datos asociados con cuatro cuentas de AC separadas con nombres de usuario correspondientes : carrie@hbo.net, hobbes@gmail.com, sj@sjones.com, y mgr@holefds.com. El nombre de usuario carrie@hbo.net cuenta con: (1) un PIN asociado "sHOe$;" (2) un valor asociado: (a) 80.000 euros, (b) una laptop MacBook Air, (c) dos pares de zapatos de taco aguja Manolo Blahnik, y (d) crédito para tres tratamientos de spa; y (3) cuentas externas vinculadas a (a) Bank of Amerigo, (b) Citibanquet, (c) casa de subastas Sotheboo's Auctions, (d) Jefferson' s Dry Cleaners, y (e) Bliss Spa. A diferencia de ello, el nombre de usuario mgr@holefds.com cuenta con (1) un PIN asociado "monee;" (2) un valor asociado de USD 1.000 (un mil dólares estadounidenses); y (3) una cuenta externa vinculada a Walls Fergo bank.

Con referencia ahora a la Figura 5, se describe una base de datos de códigos 28 ilustrativa. Una base de datos de códigos 28 incluye datos asociados con Códigos "abiertos" , es decir, Códigos que han sido solicitados por los usuarios 16, pero que aún no fueron presentados con éxito a la autoridad confiable 12 para transferir un valor de una cuenta de AC de un Pagador a una cuenta de AC de un Beneficiario. Por ejemplo, la base de datos de códigos 28 incluye un campo de código 72 que almacena Códigos abiertos, y un campo de código de retorno 74 que almacena cualquier Código de retorno correspondiente. De acuerdo con lo descrito en forma más detallada a continuación, al solicitar un Código, los usuarios 16 pueden especificar un destinatario pretendido y/o una fecha de vencimiento del Código. Así, el campo de destinatario pretendido 76 almacena información que identifica cualquier destinatario pretendido especificado asociado con el Código, y el campo de fecha de vencimiento 78 almacena información referida a cualquier fecha de vencimiento especificada asociada con el Código. El campo de tipo 80 almacena descritores para identificación del tipo de Código (por ejemplo, "P" para Códigos P, "I" para Códigos F, "RP" para Códigos PR y "RI" para Códigos FR. Los expertos en el arte comprenderán que pueden utilizarse otros descritores similares para identificar tipos de Código.

Una base de datos de códigos 28 incluye, además, un campo de. valor 82, que puede utilizarse para almacenar información que describa el valor asociado con el Código. El campo de valor 82 puede incluir subcampos de valor para divisas 84, productos 86 y servicios 88. Asimismo, el campo de divisas 84 puede incluir subcampos para unidades 90 y cantidad 92, el subcampo de productos 86 puede incluir subcampos para nombre 94 y cantidad 96, y el subcampo de servicios 88 puede incluir subcampos para descripción 98 y cantidad 100.

La base de datos de códigos 28 ilustrativa mostrada en la Figura 5 incluye seis Códigos: (1) CV54H9, que es un Código P con fecha de vencimiento 15 de enero de 2009, y un valor asociado de JPY 109,780; (2) B6ER5G, que es un Código F con un destinatario pretendido de aidan@msn.net, y un valor asociado de una cocina Wolf de 48"; (3) TT643N y (4) F4WQ99, que son un primer Código PR y un segundo Código PR con un valor asociado de 10 servicios de jardinería; y (5) RY226B y (6) 7ZXLG8, que son un primer Código FR y un segundo Código FR con un valor asociado de USD 50 y un iPod nano. Así, los expertos en el arte comprenderán que los Códigos pueden estar asociados con una o más categorías de un valor, o uno o más tipos de valor dentro de una categoría.

Interfaz de usuario De acuerdo con lo descrito anteriormente con relación a la Figura 2, una interfaz de usuario 22 puede ser una interfaz web que le permite a los usuarios 16 crear cuentas de AC, vincular cuentas de AC a cuentas en entidades externas 14, transferir un valor entre cuentas de AC y cuentas externas, y solicitar y presentar Códigos para transferir un valor a otros usuarios 16 utilizando Códigos generados por una autoridad confiable 12. Ahora se describirá una interfaz web ilustrativa que muestra cada una de estas actividades para cada una de las diversas formas ilustrativas de un valor.

Los usuarios 16 pueden acceder a una interfaz web 22 a través de un navegador web convencional, como ser Internet Explorer, Firefox, Safari, Opera, u otro navegador web similar. Con referencia ahora a la Figura 6, se describe una página de registro de usuario ilustrativa. La página de registro de usuario 110 ilustrativa incluye una sección de inicio de sesión de usuario 112, que incluye campos de ingreso de datos para ingresar información de identificación de usuario (por ejemplo, un nombre de usuario, un número de cuenta, etc.), e información de verificación (por ejemplo, una contraseña) . En forma adicional, una página de registro 110 puede incluir una sesión de registro 114 para permitir que los usuarios 16 creen una cuenta de AC. Como parte del procedimiento de configuración de cuenta, puede requerirse que los usuarios 16 seleccionen un PIN u otro código de seguridad similar. Los expertos en el arte comprenderán que la página de registro 110 puede incluir una mayor o menor cantidad de información que la ilustrada en la Figura 6, y puede requerir que los usuarios 16 provean información de identificación adicional (por ejemplo, una contraseña generada por ficha virtual, u otra información de seguridad similar .

Luego de que un usuario 16 se haya registrado con éxito al sistema, la interfaz web 22 puede visualizar una página de inicio del usuario, como ser la página de inicio del usuario 120 ilustrativa mostrada en la Figura 7 para el usuario "carrie@hbo.net." La página de inicio 120 ilustrativa incluye un panel de navegación 122, una tabla de "últimas transacciones" 124 y una tabla de "Códigos abiertos" 126. El panel de navegación 122 incluye hiperenlaces a páginas web referidas a las actividades de gestión de cuentas de AC 128, actividades de gestión de cuentas externas 130, y actividades de gestión de información de usuario 132. Los hiperenlaces referidos a actividades de gestión de cuentas externas 130 pueden utilizarse para crear una lista de cuentas externas vinculadas, vincular cuentas de AC a cuentas externas y transferir un valor entre cuentas de AC y cuentas externas. Los expertos en el arte comprenderán que el panel de navegación 122 pueden incluir, por ejemplo, una mayor cantidad de hiperenlaces , una menor cantidad de hiperenlaces y/o hiperenlaces que se diferencien de los hiperenlaces ilustrativos mostrados en la Figura 7.

Para un valor monetario, un usuario 16 puede generar fondos en su cuenta de AC por medio de un pago en efectivo, un giro postal, un cheque, un pago de tarjeta de crédito, una transferencia bancaria, o método similar, o una combinación de dichos métodos. Los expertos en el arte comprenderán que cada método de generación de fondos puede requerir medidas de seguridad adicionales específicas para ese método. Por ejemplo, puede requerirse que un usuario 16 vincule una cuenta bancaria, confirme microdepósitos para demostrar que controla la cuenta, y/o proveer cualquier cantidad de formas adicionales de identificación. Dichas medidas de seguridad pueden implementarse dentro de la estructura de la autoridad confiable 12, tal como comprenderán los expertos en el arte.

Con referencia ahora a la Figura 8, por medio de la selección del hiperenlace "lista de cuentas externas" en el panel de navegación 122, se visualiza una página web 140 de "cuentas externas vinculadas" que incluye una lista 142 de las cuentas externas vinculadas del usuario. En el ejemplo ilustrado, un usuario carrie@hbo.net vinculó su cuenta de AC a cuentas externas en dos bancos (Bank of Amerigo y Citibanquet) , una casa de subastas (Sotheboo's) y dos proveedores de servicios (Bliss Spa y Jefferson's Dry Cleaners) .

Un hiperenlace "vincular cuentas externas" en un panel de navegación 122 puede utilizarse para vincular las cuentas de AC del usuario a cuentas externas. Por ejemplo, la Figura 9 muestra páginas web ilustrativas que pueden utilizarse para vincular una cuenta de AC a una cuenta externa. En la Figura 9A, una página web "vincular cuentas externas" 150 ilustrativa incluye una lista desplegable 152 de tipos de cuentas externas, como ser entidades financieras, depositarios, y proveedores de servicios. Los expertos en el arte comprenderán que los sistemas de acuerdo con esta invención pueden utilizar más o menos de tres tipos diferentes de cuenta, y pueden utilizar tipos de cuenta que se diferencien de los tipos de cuenta ilustrativos mostrados en la Figura 9A.

De acuerdo con lo mostrado en la Figura 9B, si un usuario 16 selecciona un tipo de cuenta de entidad financiera de una lista desplegable 152, una página web 150a puede visualizar una lista desplegable de nombres de entidades financieras 154 que incluye nombres de varias entidades financiera cuyas cuentas pueden estar vinculadas a cuentas de AC. Las entidades financieras ilustrativas pueden incluir bancos, cooperadoras de crédito, fondos comunes de inversión, casas de corretaje de descuento, planes de jubilación y otras entidades financieras similares o combinaciones de dichas entidades. Una página web 150a puede visualizar, además, campos de ingreso de datos para proveer un número de cuenta 156 y un número de seguimiento 158 asociado con la cuenta de un usuario en la entidad financiera especificada. Los expertos en el arte comprenderán que pueden proveerse campos de ingreso de datos para información que se diferencie del número de cuenta 156 y el número de seguimiento 158 y/o información adicional a ellos. En forma adicional, los expertos en el arte comprenderán que, en forma alternativa, la página web 150a puede no utilizar una lista desplegable de nombres de entidades financieras 152 pero proveer alguna otra forma de campo de ingreso de datos por medio de la cual un usuario 16 pueda especificar una entidad financiera para vincular a su cuenta de AC.

De acuerdo con lo mostrado en la Figura 9C, si un usuario 16 selecciona un tipo de cuenta de depositario de una lista desplegable 152, una página web 150b puede visualizar una lista desplegable de nombres de depositarios 154 que incluye nombres de varios depositarios cuyas cuentas pueden estar vinculadas a cuentas de AC. Los depositarios ilustrativos pueden incluir casas de subastas, depositarios certificados, compañías de títulos y otros depositarios similares o combinaciones de dichos agentes. Una página web 150b puede visualizar, además, campos de ingreso de datos para proveer un número de cuenta 156 y un código de seguridad 158 asociado con la cuenta de un usuario en el depositaros especificado. Los expertos en el arte comprenderán que pueden proveerse campos de ingreso de datos para información que se diferencie del número de cuenta 156 y el código de seguridad 158 y/o información adicional a ellos. En forma adicional, los expertos en el arte comprenderán que, en forma alternativa, la página web 150b puede no utilizar una lista desplegable de nombres de depositarios 154 pero proveer alguna otra forma de campo de ingreso de datos por medio de la cual un usuario 16 pueda especificar un depositario para vincular a su cuenta de AC.

De acuerdo con lo mostrado en la Figura 9D, si un usuario 16 selecciona un tipo de cuenta de proveedor de servicios de una lista desplegable 152, una página web 150c puede visualizar una lista desplegable de nombres de proveedores de servicios 154 que incluye nombres de varios proveedores de servicios cuyas cuentas pueden estar vinculadas a cuentas de AC. Los proveedores de servicios ilustrativos pueden incluir tintorerías, amas de llave, jardineros, mecánicos de automóviles, spas, plomeros y otros proveedores de servicios similares o combinaciones de dichos proveedores. Una página web 150c puede visualizar, además, campos de ingreso de datos para proveer un número de cuenta 156 asociado con la cuenta de un usuario en el proveedor de servicios especificado. Los expertos en el arte comprenderán que pueden proveerse campos de ingreso de datos para información que se diferencie del número de cuenta 156 y/o información adicional a él. En forma adicional, los expertos en el arte comprenderán que, en forma alternativa, la página web 150c puede no utilizar una lista desplegable de nombres de proveedores de servicios 154 pero proveer alguna otra forma de campo de ingreso de datos por medio de la cual un usuario 16 pueda especificar un proveedor de servicios para vincular a su cuenta de AC.

Luego de vincular una o más cuentas externas a cuentas de AC, un usuario 16 puede utilizar el hiperenlace "transferencia" en un panel de navegación 122 para transferir un valor entre las cuentas externas de un usuario y sus cuentas de AC. Por ejemplo, las Figuras 10A a 10E muestran páginas web ilustrativas que pueden ser utilizadas por el usuario carrie@hbo.net para transferir un valor entre sus cuentas externas y su cuenta de AC. La Figura 10A muestra una página web de "transferencia a cuentas externas" 160 que incluye un menú desplegable "desde" 162 para especificar una cuenta desde la cual se transferirá un valor, y un menú desplegable "hasta" 164 para especificar una cuenta a la cual se transferirá un valor. Una página web 160 incluye, además, un campo de ingreso de datos de descripción 166 y un campo de ingreso de datos de cantidad 168 para especificar el valor a ser transferido. Asimismo, la página web 160 puede incluir un campo de ingreso de datos de memorando opcional 170 para ingresar una descripción de texto de la transferencia, y un campo de ingreso de datos de PIN 172 para especificar el PIN u otro código de seguridad creado por el usuario 16 durante el procedimiento de configuración de cuenta de AC.

La Figura 10B muestra una página web de transferencia a cuentas externas 160a ilustrativa donde se transfiere un valor monetario de una cuenta bancaria vinculada de un usuario a su cuenta de AC. En particular, el menú desplegable 162 indica que se transferirá un valor especificado de la cuenta de Bank of Amerigo del usuario, y un menú desplegable 164 indica que se transferirá el valor especificado a la cuenta de AC del usuario. De acuerdo con esta forma de realización ilustrativa, si la entidad externa especificada en cualquiera de los menús desplegables 162 o 164 es una entidad financiera donde un valor se especifica en una divisa, la página web 160a de transferencia a cuentas externas incluirá un campo de ingreso de datos de unidades 166 para especificar unidades de divisas y un campo de ingreso de datos de cantidad 168 para especificar un monto de la divisa especificada. En el ejemplo ilustrado, un usuario carrie@hbo.net especificó una transferencia de USD 1.247,00 de su cuenta en Bank of Amerigo a su cuenta de AC. Cuando el usuario 16 hace clic en el botón presentar, el valor especificado será transferido de la cuenta externa seleccionada del usuario a un almacenamiento de valores 30.

En particular, una vez más con referencia a las Figuras 2 y 4 , la interfaz de entidad externa 24 obtiene de la base de datos de cuentas 26 (a través del controlador 22) la información de cuenta asociada con la cuenta de AC del usuario y la cuenta externa especificada. En el ejemplo ilustrado en la Figura 10B, la interfaz de entidad externa 24 obtiene el número de cuenta (2037782) y el número de seguimiento (122000661) de la cuenta de Bank of Amerigo de carrie@hbo.nefs desde la base de datos de cuentas 26. Utilizando un protocolo de transferencia electrónica de fondos, u otro protocolo similar, la interfaz de entidad externa 24 puede iniciar luego una transferencia del valor especificado (es decir, USD 1.247,00) de la cuenta de Bank of Amerigo del usuario a un almacenamiento de valores 30. Esto se ilustra esquemáticamente en la Figura 11 como una transferencia 180 de una entidad externa 141 (Bank of Amerigo) a una autoridad confiable 12.

Cuando una autoridad confiable 12 determina que el valor especificado se recibió en el almacenamiento de valores 30, la base de datos de cuentas 26 será actualizada para reflejar el valor aumentado en la cuenta de AC del usuario. En forma opcional, la autoridad confiable 12 puede "girar" a la cuenta de AC del usuario el valor transferido desde una cuenta externa, con la confianza de que el valor será transferido con éxito. De acuerdo con lo mostrado en la Figura 12A, la base de datos de cuentas 26 se actualizó para reflejar un aumento del valor monetario de carrie@hbo . net ' s de USD 1.247, 00.

La Figura 10C muestra una página web de transferencia a cuentas externas 160b ilustrativa donde se transfiere un valor monetario de una cuenta de AC del usuario a una de sus cuentas externas vinculadas. En particular, el menú desplegable 162 indica que se transferirá un valor especificado de la cuenta de AC del usuario, y un menú desplegable 164 indica que se transferirá el valor especificado a una de las cuentas externas vinculadas del usuario. En el ejemplo ilustrado, un usuario carrie@hbo.net especificó una transferencia de USD 55,75 de su cuenta de AC a su cuenta de Citibanquet vinculada. Cuando el usuario 16 hace clic en el botón presentar, el valor especificado será transferido del almacenamiento de valores 30 a la cuenta externa vinculada seleccionada. En forma adicional, la base de datos de cuentas 26 se actualizará para reflejar el valor reducido en la cuenta de AC del usuario.

En particular, una vez más con referencia a las Figuras 2 y 4, la interfaz de entidad externa 24 obtiene de la base de datos de cuentas 26 (a través del cbntrolador 22) la información de cuenta asociada con la cuenta externa seleccionada del usuario. En el ejemplo ilustrado en la Figura 10C, la interfaz de entidad externa 24 obtiene el número de cuenta (01886052278) y el número de seguimiento (021000089) de la cuenta de Citibanquet de carrie@hbo . net ' s desde la base de datos de cuentas 26. Utilizando un protocolo de transferencia electrónica de fondos, u otro protocolo similar, la interfaz de entidad externa 24 puede iniciar luego una transferencia del valor especificado (es decir, USD 55,75) del almacenamiento de valores 30 a la cuenta de Citibanquet del usuario. Esto se ilustra esquemáticamente en la Figura 11 como una transferencia 182 de una autoridad confiable 12 a una entidad externa 142 (Citibanquet) . En forma adicional, de acuerdo con lo mostrado en la Figura 12B, la base de datos' de cuentas 26 se actualizó para reflejar una reducción del valor monetario de carrie@hbo . net ' s de USD 55, 75.

La Figura 10D muestra una página web de transferencia a cuentas externas 160c ilustrativa donde se transfiere un valor de producto de una cuenta externa vinculada del usuario a su cuenta de AC. En particular, el menú desplegable 162 indica que se transferirá un valor especificado de una de las cuentas externas del usuario, y un menú desplegable 164 indica que se transferirá el valor especificado a la cuenta de AC del usuario. En el ejemplo ilustrado, un usuario carrie@hbo.net especificó una transferencia- de un reloj Rolex Oyster Perpetual de su cuenta vinculada de Sotheboo's a su cuenta de AC. Cuando el usuario 16 hace clic en el botón presentar, el valor especificado será transferido de la cuenta externa vinculada del usuario a un almacenamiento de valores 30.

En particular, una vez más con referencia a las Figuras 2 y 4, la interfaz de entidad externa 24 obtiene de la base de datos de cuentas 26 (a través del controlador 22) la información de cuenta asociada con la cuenta externa seleccionada del usuario. En el ejemplo ilustrado en la Figura 10D, la interfaz de entidad externa 24 obtiene el número de cuenta (5AyF98) y el número de seguridad (sotheOOl) de la cuenta de Sotheboo's de carrie@hbo . net ' s desde la base de datos de cuentas 26. Utilizando un protocolo de transferencia electrónica de fondos, u otro protocolo similar, la interfaz de entidad externa 24 puede iniciar luego una transferencia del valor especificado (es decir, un reloj Rolex Oyster Perpetual) de la cuenta de Sotheboo's del usuario a un almacenamiento de valores 30. Esto se ilustra esquemáticamente en la Figura 11 como una transferencia 184 de una entidad externa 143 (Sotheboo's) a una autoridad confiable 12.

Cuando una autoridad confiable 12 determina que el valor especificado se recibió en el almacenamiento de valores 30, la base de datos de cuentas 26 será actualizada para reflejar el valor aumentado en la cuenta de AC del usuario. Así, de acuerdo con lo mostrado en la Figura 12C, la base de datos de cuentas 26 se actualizó para reflejar un aumento en el valor de productos de carrie@hbo . net ' s de un reloj Rolex Oyster Perpetual.

Los expertos en el arte comprenderán que las transferencias de valor de producto no requieren una transferencia física de productos entre una entidad externa 14 y un almacenamiento de valores 30. En lugar de ello, un producto puede permanecer en una entidad externa 14, y pueden transferirse indicaciones de titularidad de un valor de la entidad externa 14 a la autoridad confiable 12. Con relación a dichas transferencias, pueden transferirse indicaciones de titularidad de un valor (por ejemplo, una escritura, un 4 título, un certificado de dominio, u otras indicaciones de titularidad similares) de una entidad externa a un almacenamiento de valores 30.

La Figura 10E muestra una página web de transferencia a cuentas externas 160d ilustrativa donde se transfiere un valor de servicio de una cuenta externa vinculada del usuario a su cuenta de AC. En particular, el menú desplegable 162 indica que se transferirá un valor especificado de una de las cuentas externas del usuario, y un menú desplegable 164 indica que se transferirá el valor especificado a la cuenta de AC del usuario. En el ejemplo ilustrado, un usuario carrie@hbo.net especificó una transferencia de doce limpiezas de suéteres de su cuenta vinculada de Jefferson' s Dry Cleaners a su cuenta de AC. Cuando el usuario 16 hace clic en el botón presentar, se transferirán indicaciones del valor especificado de la cuenta externa vinculada del usuario a un almacenamiento de valores 30.

En particular, una vez más con referencia a las Figuras 2 y 4, la interfaz de entidad externa 24 obtiene de la base de datos de cuentas 26 (a través del controlador 22) la información de cuenta asociada con la cuenta externa seleccionada del usuario. En el ejemplo ilustrado en la Figura 10E, la interfaz de entidad externa 24 obtiene el número de cuenta (cbradshaw) de la cuenta de Jefferson' s Dry Cleaners de carrie@hbo.nefs desde la base de datos de cuentas 26. Utilizando un protocolo de comunicación, como ser una llamada telefónica, mensaje de correo electrónico, mensaje de fax, u otro protocolo de comunicación similar, una interfaz de entidad externa 24 puede iniciar luego una transferencia de indicaciones del valor especificado (por ejemplo, cupones o fichas virtuales para doce limpiezas de suéteres) de la cuenta de Jefferson's Dry Cleaners del usuario a un almacenamiento de valores 30. Esto se ilustra esquemáticamente en la Figura 11 como una transferencia 186 de una entidad externa 144 (Jefferson's Dry Cleaners) a una autoridad confiable 12.

Cuando una autoridad confiable 12 determina que se recibieron indicaciones del valor especificado en el almacenamiento de valores 30, la base de datos de cuentas 26 será actualizada para reflejar el valor aumentado en la cuenta de AC del usuario. Así, de acuerdo con lo mostrado en la Figura 12D, la base de datos de cuentas 26 se actualizó para reflejar un aumento en el valor de servicios de carrie@hbo.net's de doce limpiezas de suéteres.

Los expertos en el arte comprenderán que los métodos y sistemas de acuerdo con esta invención pueden permitirle al usuario 16, en forma adicional o alternativa, transferir un valor entre una cuenta externa del usuario y su cuenta de AC incluso cuando la cuenta externa no se haya vinculado previamente a la cuenta de AC. Por ejemplo, puede permitirse que un usuario 16 especifique el tipo de cuenta, nombre de cuenta, número de cuenta, etc., al solicitar la transferencia. Dicha operación puede considerarse conveniente para transferencias "únicas" entre una cuenta de AC del usuario y una cuenta externa.

De acuerdo con lo mostrado en la Figura 13, si el usuario 16 selecciona el hiperenlace "inicio de cuenta" en el panel de navegación 122, la página de inicio del usuario 120 visualiza un resumen de las transferencias anteriores en la tabla de "últimas transacciones" 124. Asimismo, de acuerdo con lo mostrado en la Figura 14, si el usuario 16 selecciona el hiperenlace "saldo de cuenta" en el panel de navegación 122, la página de saldo de cuenta 190 visualiza un resumen del valor en la cuenta de AC del usuario en la tabla de saldo de cuenta 192.

De acuerdo con lo mencionado anteriormente, los usuarios 16 pueden utilizar una interfaz web 22 para transferir un valor a otros usuarios 16 utilizando Códigos asociados con el valor especificado. En particular, un Pagador puede utilizar una interfaz web 22 para solicitar un Código P a una autoridad confiable 12 que esté asociado con un valor especificado. El Pagador puede comunicar el Código P al Beneficiario, que luego puede presentar el Código P a la autoridad confiable 12. Si la autoridad confiable 12 determina que el Código P presentado es válido, y que la cuenta de AC del Pagador cuenta con fondos suficientes, la autoridad confiable 12 debita el valor especificado de la cuenta de AC del Pagador y acredita el valor especificado en la cuenta de AC del Beneficiario.

En forma alternativa, puede lograrse la misma transferencia de valor utilizando Códigos F. En particular, un Beneficiario puede utilizar una interfaz web 22 para solicitar un Código F a una autoridad confiable 12 que esté asociado con un valor especificado. El Beneficiario puede comunicar el Código F al Pagador, que luego puede presentar el Código F a la autoridad confiable 12. Si la autoridad confiable 12 determina que el Código F presentado es válido, y que la cuenta de AC del Pagador cuenta con fondos suficientes, la autoridad confiable 12 debita el valor especificado de la cuenta de AC del Pagador y acredita el valor especificado en la cuenta de AC del Beneficiario. Para facilitar dichas transacciones, una interfaz web 22 provee hiperenlaces "solicitar un Código" y "presentar un Código" en un panel de navegación 122. Ahora se describirán los ejemplos de uso de dichos hiperenlaces.

Código de pago solicitado por un Pagador Si un usuario Carrie (carrie@hbo.net) compra cuatro litros (un galón) de leche de soja a un usuario Hole Foods (mgr@holefds.com), Carrie debe abonar la leche utilizando un Código P. Las Figuras 15A a 15C muestran páginas web ilustrativas que representan la solicitud de Código P de Carrie a una autoridad confiable 12.

En particular, la Figura 15A muestra una página web "solicitar un Código" 200a ilustrativa que incluye una tabla de saldo de cuenta actual 202 que incluye el saldo de cuenta actual del usuario. En forma adicional,, la página web 200a incluye un campo de ingreso de datos de descripción 204 y un campo de ingreso de datos de cantidad 206 para especificar una descripción y cantidad, respectivamente, del valor a ser asociado con el Código solicitado. Asimismo, la página web 200a incluye un campo de ingreso de datos de memorando opcional 208 para ingresar una descripción de texto del Código, y un campo de ingreso de datos de PIN 210 para especificar el PIN u otro código de seguridad creado por el usuario 16 durante el procedimiento de configuración de cuenta de AC. Además, la página web 200a incluye botones de radio 212 para especificar el Código solicitado como un Código P o un Código F, y una casilla de verificación 214 para solicitar un Código de retorno. Asimismo, puede visualizarse un mensaje de confirmación de términos y condiciones de servicio 216 y puede requerirse que el usuario 16 manifieste su aceptación de los términos y condiciones de servicio, como ser seleccionando un botón "acepto" 218, u otro método similar de acuerdo afirmativo. En este ejemplo, Carrie solicitó que un Código P se asociara con USD 13,27.

Luego de que el usuario 16 hace clic en el botón "presentar", un generador de códigos 32 (Figura 3) genera un código de sistema sustancialmente aleatorio CS . De acuerdo con lo ilustrado en la Figura 15B, una interfaz web 22 visualiza una página web "personalizar Código" 220a que muestra el código de sistema CS en el área de visualización de códigos de sistema 222a ("A83TZ" en este ejemplo) , e incluye una sección de "opciones de seguridad mejoradas" que incluye un campo de ingreso de datos de "caracteres de código adicionales" 224a donde un usuario 16 puede proveer un código especificado por usuario CU, un campo de ingreso de datos "fecha de vencimiento" 226a donde un usuario 16 puede especificar una fecha de vencimiento del Código, y un campo de ingreso de datos de "destinatario pretendido" 228a donde el usuario 16 puede especificar una dirección de correo electrónico, número telefónico u otra información que pueda utilizarse para identificar al destinatario pretendido del Código. El usuario 16 puede ingresar datos en uno o más campos de ingreso de datos 224a, 226a y 228a o puede dejar todos lo campos en blanco. Luego ' de que el usuario 16 hace clic en el botón "presentar" , un combinador de códigos 36 (Figura 3) combina un código de sistema CS con cualquier código especificado por usuario CU para generar el Código que está asociado con el valor especificado. En el ejemplo ilustrado, Carrie no indicó un código especificado por usuario CU y no especificó una fecha de vencimiento o destinatario pretendido. Los expertos en el arte comprenderán que, en forma opcional, los sistemas de acuerdo con esta invención pueden no visualizar un . código de sistema CS al usuario 16 en la página web personalizar Código 220a.

Luego, de acuerdo con lo mostrado en la Figura 15C, una interfaz web 22 visualiza una página web de "Código emitido" 230a que incluye un campo de visualización de código 232a que visualiza el Código asociado con el valor especificado. En. este ejemplo, Carrie no indicó un código especificado por usuario CU, por lo tanto, el Código visualizado es el mismo que el código de sistema CS ("A83TZ" en este ejemplo). La página web de Código emitido 230a puede incluir, además, un mensaje 234 que resume el tipo y el valor asociado con el Código,- y que comunica términos y condiciones de servicio adicionales referidos al uso del Código.

Con referencia una vez más a la Figura 11, esta solicitud de Código P ilustrativa es mostrada esquemáticamente como una solicitud 240 de Código P "A83TZ" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 16, se actualizó una base de datos de cuenta 26 para indicar que Carrie cuenta con un Código abierto "A83TZ" . En este ejemplo, dado que el valor especificado asociado con el Código aún no se transfirió desde la cuenta de AC del usuario, la base de datos de cuentas 26 no refleja cambio alguno en el valor de cuenta de AC de Carrie. No obstante, los expertos en el arte comprenderán que la base de datos de cuentas 26 puede actualizarse, en forma alternativa, para reflejar una reducción en el monto del valor monetario (USD 13,27) asociado con el Código generado.

Una vez recibido el Código P, Carrie puede comunicarle el Código P a Hole Foods para abonar los cuatro, litros (un galón) de leche de soja. Esta transacción se ilustra esquemáticamente en la Figura 11 como un pago 242 de Código P "A83TZ" efectuado por Carrie a Hole Foods. Luego, Hole Foods puede presentar el Código P recibido a una autoridad confiable 12, lo cual se describirá en forma más detallada a continuación .

Código de facturación solicitado por un Beneficiario Si Carrie trabaja como niñera para un usuario Miranda (hobbes@gmail.com), Carrie puede facturarle a Miranda sus servicios de niñera utilizando un Código F. Las Figuras 17A a 17C muestran páginas web ilustrativas que representan la solicitud de Código F de Carrie a una autoridad confiable 12.

En particular, la Figura 17A muestra una página web "solicitar un Código" 200b ilustrativa donde Carrie solicitó que un Código F se asocie con AUD 50 (cincuenta dólares australianos) . Luego de que el usuario 16 hace clic en el botón "presentar", un generador de códigos 32 (Figura 3) genera un código de sistema sustancialmente aleatorio CS (" 95691" en este ejemplo), que se visualiza en el campo de visualización de código 222b en la página web "personalizar Código" 220b ilustrada en la Figura 17B. En este ejemplo, Carrie indicó un código especificado por usuario CU de "co$mo" en el campo de ingreso de datos de "caracteres de código adicionales" 224b, pero no especificó una fecha de vencimiento o destinatario pretendido del Código.

Luego de que el usuario 16 hace clic en el botón "presentar", un combinador de códigos 36 (Figura 3) combina un código de sistema CS con cualquier código especificado por usuario CU para generar el Código que está asociado con el valor especificado. Luego, de acuerdo con lo mostrado en la Figura 17C, una interfaz web 22 visualiza una página web de "Código emitido" 230b que incluye un campo de visualización de código 232b .que visualiza el Código asociado con el valor especificado. En esta ilustración, el Código visualizado es la combinación del código de sistema CS y el código especificado por usuario CU ( "W95691co$mo" en este ejemplo) . En este ejemplo, el Código es simplemente la concatenación de un código de sistema CS y un código especificado por usuario CU. Los expertos en el arte comprenderán que, en forma alternativa, un combinador de códigos 36 (Figura 3) puede utilizar otras técnicas para combinar un código de sistema CS y un código especificado por usuario CU, como ser intercalado de los códigos, concatenación inversa de los códigos, u otras técnicas de combinación similares.

Con referencia una vez más a la Figura 11, esta solicitud de Código F ilustrativa es mostrada esquemáticamente como una solicitud 244 de Código F "W95691co$mo" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 18, se actualizó una base de datos de cuenta 26 para indicar que carrie@hbo.net cuenta con un Código abierto " 95691co$mo" . En este ejemplo, dado que el valor especificado asociado con el Código aún no se transfirió desde la cuenta de AC del Carrie, la base de datos de cuentas 26 no refleja cambio alguno en el valor de cuenta de AC de Carrie.

Una vez recibido el Código F, Carrie puede comunicarle el Código F a Miranda en concepto de facturación de servicios de niñera. Esta transacción se ilustra esquemáticamente en la Figura 11 como una facturación 246 de Código F "W95691co$mo" de Carrie a Miranda. Luego, Miranda puede presentar el Código F recibido a una autoridad confiable 12, lo cual se describirá en forma más detallada a continuación.

Código de pago de retorno solicitado por un Pagador Si Carrie conserva al usuario Samantha (sj@sjones.com) para¦ prestación de servicios de relaciones públicas a los efectos de promover el último libro publicado por Carrie, Carrie puede abonar los servicios de Samantha utilizando un Código P. Para mayor seguridad, Carrie puede solicitar un código de retornó como parte de esta transacción. Las Figuras 19A a 19C muestran páginas web ilustrativas que representan la solicitud de Código PR de Carrie a una autoridad confiable 12.

En particular, la Figura 19A muestra una página web "solicitar un Código" 200c ilustrativa donde Carrie solicitó que un Código P se asocie con cuatro limpiezas de suéteres y solicitó un Código de retorno. Luego de que el usuario 16 hace clic en el botón "presentar" , un generador de códigos 32 (Figura 3) genera un primer código de sistema y un segundo código de sistema sustancialmente aleatorios CS1 y CS2 ( "F2EF1D" y "8*5%RT," respectivamente, en este ejemplo). El primer código de sistema CS1 se visualiza en la página web "personalizar código" 220c ilustrada en la Figura 19B. En este ejemplo, Carrie no indicó un código especificado por usuario CU, pero especificó la fecha de vencimiento 25/12/2008, y el destinatario pretendido sj@sjones.com del Código. Los expertos en el arte comprenderán que un generador de códigos 32 puede generar, en forma alternativa, el segundo código de sistema CS2 en un momento posterior.

Luego de que el usuario 16 hace clic en el botón "presentar", un combinador de códigos 36 (Figura 3) combina el primer código de sistema CS con cualquier código especificado por usuario CU para generar el Código que está asociado con el valor especificado. Luego, de acuerdo con lo mostrado en la Figura 19C, una interfaz web 22 visualiza una página web de "Código emitido" 230c que incluye un campo de visualización de código 232c que visualiza el Código asociado con el valor especificado. En esta ilustración, el Código visualizado es el primer código de sistema CS1 ( "F2EF1D" en este ejemplo) .

Con referencia una vez más a la Figura 11, esta solicitud de Código PR ilustrativa es mostrada esquemáticamente como una solicitud 248 de Código PR "F2EF1D" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 20, se actualizó una base de datos de cuenta 26 para indicar que carrie@hbo.net cuenta con un Código abierto "F2EF1D" . En este ejemplo, dado que el valor especificado asociado con el Código aún no se transfirió desde la cuenta de AC del usuario, la base de datos de cuentas 26 no refleja cambio alguno en el valor de cuenta de AC de Carrie .

Una vez recibido el Código PR, Carrie puede comunicarle el Código PR a Samantha para abonar los servicios de relaciones públicas. Esta transacción se ilustra esquemáticamente en la Figura 11 como un pago 250 de Código PR "F2EF1D" efectuado por Carrie a Samantha. Luego, Samantha puede presentar el Código PR recibido a una autoridad confiable 12, lo cual se describirá en forma más detallada a continuación.

Código de facturación de retorno solicitado por un Beneficiario Si Carrie asesora a Samantha en la compra de nuevas colecciones de moda de otoño, Carrie puede facturarle a Samantha sus servicios de asesoramiento en compras utilizando un Código F. Para mayor seguridad, Carrie puede solicitar un código de retorno como parte de esta transacción. Las Figuras 21A a 21C muestran páginas web ilustrativas que representan la solicitud de Código FR de Carrie a una autoridad confiable 12.

En particular, la Figura 21A muestra una página web "solicitar un Código" 200d ilustrativa donde Carrie solicitó que un Código F se asocie con un masajeador de espalda y solicitó un Código de retorno. Luego de que el usuario 16 hace clic en el botón "presentar" , un generador de códigos 32 (Figura 3) genera un primer código de sistema y un segundo código de sistema sustancialmente aleatorios CS1 y CS2 ("JJ7VX#" y "5778T®," respectivamente, en este ejemplo). El primer código de sistema CS1 se visualiza en la página web "personalizar código" 220d ilustrada en la Figura 21B. En este ejemplo, Carrie no indicó un código especificado por usuario CU, una fecha de vencimiento o un destinatario pretendido del Código. Los expertos en el arte comprenderán que un generador de códigos 32 puede generar, en forma alternativa, el segundo código de sistema CS2 en un momento posterior.

Luego de que el usuario 16 hace clic en el botón "presentar", un combinador de códigos 36 (Figura 3) combina el primer código de sistema CSI con cualquier código especificado por usuario CU para generar el Código que está asociado con el valor especificado. Luego, de acuerdo con lo mostrado en la Figura 21C, una interfaz web 22 visualiza una página web de "Código emitido" 230d que incluye un campo de visualización de código 232d que visualiza el Código asociado con el valor especificado. En esta ilustración, el Código visualizado es el primer código de sistema CS1 ("JJ7VX#" en este ejemplo) .

Con referencia una vez más a la Figura 11, esta solicitud de Código FR ilustrativa es mostrada esquemáticamente como una solicitud 252 de Código FR "JJ7VX#" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 22, se actualizó una base de datos de cuenta 26 para indicar que Carrie cuenta con un Código abierto "JJ7VX#" . En este ejemplo, dado que el valor especificado asociado con el Código aún no se transfirió desde la cuenta de AC del usuario, la base de datos de cuentas 26 no refleja cambio alguno en el valor de cuenta de AC de Carrie.

Una vez recibido el Código FR, Carrie puede comunicarle el Código FR a Samantha en concepto de facturación de servicios de asesoramiento en compras. Esta transacción se ilustra esquemáticamente en la Figura 11 como una facturación 254 de Código FR "JJ7VX#" de Carrie a Samantha. Luego, Samantha puede presentar el Código FR recibido a una autoridad confiable 12, lo cual se describirá en forma más detallada a continuación.

Así, de acuerdo con lo mostrado en la Figura 23, luego de completadas estas cuatro solicitudes de Código, una base de datos de códigos 28 indica que: (1) el Código "A83TZ" es un Código P asociado con un valor monetario de USD 13,27; (2) el Código "W95691co$mo" es un Código F asociado con un valor monetario de AUD 50; (3) los Códigos "F2EF1D" y "8*5%RT" son Códigos PR correspondientes asociados con un valor de servicio de cuatro limpiezas de suéteres; y (4) los Códigos "JJ7VX#" y "5778T®" son Códigos FR correspondientes asociados con un valor de producto de un masajeador de espalda.

De acuerdo con lo mostrado en la Figura 24, si Carrie 16 selecciona el hiperenlace "inicio de cuenta" en el panel de navegación 122, la página de inicio del usuario 120 visualiza un resumen de las solicitudes de Código anteriores en la tabla de últimas transacciones 124. En forma adicional, la tabla de Códigos Abiertos 126 visualiza un resumen de los Códigos abiertos de Carrie, incluso el tipo de código, fecha de creación y fecha de vencimiento. Los expertos en el arte comprenderán que puede visualizarse una mayor o menor cantidad de información referida a los Códigos abiertos. Por ejemplo, pude visualizarse, además, el valor asociado con cada Código.

De acuerdo con lo descrito anteriormente, Carrie proporcionó un Código P a Hole Foods, un Código F a Miranda, un Código PR a Samantha y un Código FR a Samantha. Cada uno de estos destinatarios puede presentar luego sus Códigos recibidos a una autoridad confiable 12 utilizando el hiperenlace "presentar un Código" en el panel de navegación 122 para transferir el valor asociado con cada Código del Pagador al Beneficiario. Ahora se describirán los ejemplos de uso de dichos hiperenlaces .

Código P presentado por un Beneficiario Al recibir el Código P "A83TZ" de Carrie, Hole Foods puede presentar el Código P a una autoridad confiable 12 utilizando el hiperenlace "presentar un Código" en el panel de navegación 122 a los efectos de presentar un Código a la autoridad confiable 12. Por ejemplo, las Figuras 25A y 25B muestran páginas web ilustrativas que representan una presentación de un Código P a una autoridad confiable 12.

En particular, la Figura 25A ilustra una página web "presentar un Código" 260a ilustrativa que incluye una tabla de saldo de cuenta 262 que visualiza el saldo de cuenta actual del usuario, un campo de ingreso de datos de Código 264 que puede utilizarse para ingresar un Código a ser presentado, y campos de ingreso de datos de descripción de valor y cantidad 266 y 268, respectivamente, que pueden utilizarse para especificar el valor asociado con el Código ingresado en el campo de ingreso de datos de Código 264. Los expertos en el arte comprenderán que los métodos y sistemas de acuerdo con esta invención pueden requerir solamente, en forma alternativa, que el usuario 16 provea el Código, sin requerir que el usuario 16 provea, además, información adicional, como ser la descripción del valor, cantidad, u otra información.

En este ejemplo Hole Foods ingresó el Código "A83TZ" en un campo de ingreso de datos de Código 264, especificó "USD" en un campo de ingreso de datos de descripción 266 y "13,27" en un campo de ingreso de datos de cantidad 268. Un campo de ingreso de datos de memorando opcional 270 puede utilizarse para ingresar un memorando de texto referido a la presentación, y un campo de ingreso de datos de PIN 272 puede utilizarse para ingresar el PIN de usuario. Puede visualizarse un mensaje de confirmación de términos y condiciones de servicio 274 y puede requerirse que el usuario 16 manifieste su aceptación de los términos y condiciones de servicio, como ser seleccionando un botón "acepto" 276, u otro método similar de acuerdo afirmativo.

Luego de que el usuario 16 hace clic en el botón "presentar", un controlador 20 (Figura 2) accede a una base de datos de códigos 28 para determinar si el Código presentado es válido. Por ejemplo, un Código puede considerarse válido si el Código es abierto y si se cumplen otros requerimientos de datos de Código. Por ejemplo, si el usuario solicitante especificó una fecha de vencimiento o un destinatario pretendido, un Código presentado puede ser válido solamente si el Código se presenta con anterioridad a la fecha de vencimiento especificada y si el Código es presentado por el destinatario pretendido.

En algunas formas de realización de acuerdo con esta invención, una autoridad confiable 12 puede aumentar la seguridad del sistema al requerir que la descripción de un valor presentado se corresponda con la descripción del valor asociada con el Código en una base de datos de códigos 28. Respecto de ello, si se pierde un Código, un usuario no autorizado 16 que encuentra el Código puede simplemente no presentar el Código a una autoridad confiable 12 sin tener conocimiento, además,, de la descripción exacta del valor asociada con el Código. Respecto de ello, la determinación de validez de Código puede incluir la recuperación de la descripción del valor asociada con el Código desde una base de datos de códigos 28, y la comparación de la descripción del valor recuperada con la descripción del valor y la cantidad provistas por el usuario 16 que las presenta en los campos de ingreso de datos 266 y 268.

Si una base de datos de códigos 28 no incluye una entrada para el Código provisto por el usuario receptor 16 en el campo de datos 264, o si cualquiera de las condiciones de validación de Código no se cumple, un controlador 20 puede hacer que la interfaz de usuario 22 provea un mensaje de error que indique que el Código especificado y/o el valor especificado son incorrectos. La interfaz de usuario 22 puede permitirle al usuario 16 recuperar la presentación, o puede cerrar la sesión de inmediato. Por razones de seguridad, el controlador 20 puede bloquear una cuenta de usuario luego de una cantidad predeterminada de intentos fallidos de presentación.

Si el controlador 20 determina que el Código P presentado es válido, el controlador 20 invalida el Código (por ejemplo, borra el Código P de la base de datos de cuentas 26 y la base de datos de códigos 28) , debita el valor asociado con el Código P de la cuenta de AC del Pagador y acredita el valor asociado en la cuenta de AC del Beneficiario. En forma adicional, una interfaz de usuario 22 visualiza una página web de "confirmación de presentación" 278a, ejemplo de la cual se ilustra en la Figura 25B. En particular, una página web 278a incluye una tabla de saldo de cuenta 280a que visualiza el saldo de cuenta actual del usuario, incluso el monto acreditado en la cuenta de AC del usuario .

Con referencia una vez más a la Figura 11, esta transacción se ilustra esquemáticamente en la Figura 11 como una presentación de Hole Foods 302 de código "A83TZ" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 26, se actualizó una base de datos de cuentas 26 para reflejar un aumento en el valor monetario de Hole Foods del monto asociado con el Código P presentado (USD 13,27) y una reducción en el valor monetario de Carrie del mismo monto. Además, se actualizó la base de datos de cuentas 28 para borrar el Código "A83TZ" de los Códigos abiertos de Carrie. De acuerdo con lo ilustrado por este ejemplo, dado que los Códigos no necesitan incluir información alguna que identifique al usuario 16 que retiró el valor, los usuarios 16 pueden utilizar los Códigos para transferir el valor asociado con el Código en forma anónima.

Código F presentado por un Beneficiario Al recibir el Código F " 95691co$mo" de Carrie, Miranda puede presentar el Código F a una autoridad confiable 12. Por ejemplo, las Figuras 27A a 27C muestran páginas web ilustrativas que representan una presentación de un Código F a una autoridad confiable 12. En particular, la Figura 27A muestra una página web "presentar un Código" 260b ilustrativa donde Miranda ingresó el Código "W95691co$mo" en un campo de ingreso de datos de Código 264, especificó "AUD" en un campo de ingreso de datos de descripción 266 y "50" en un campo de ingreso de datos de cantidad 268.

Luego de que el usuario 16 hace clic en el botón "presentar", un controlador 20 (Figura 2) accede a una base de datos de códigos 28 para determinar si el Código provisto en un campo de ingreso de datos de Código 264 es válido. Si un controlador 20 determina que el Código F presentado es válido, el controlador 20 determina si el valor asociado con el Código F está disponible en la cuenta de AC del usuario. En el ejemplo ilustrado en la Figura 27A, el valor asociado (AUD 50) no es una divisa actualmente disponible en la cuenta de AC de Miranda. No obstante, la cuenta de Miranda no incluye divisas suficientes (GBP 312 (trescientas doce libras esterlinas)) que puedan convertirse al monto del valor asociado. Así, una interfaz de usuario 22 puede visualizar una página web de "valor insuficiente" 282 que provee botones de radio 284 y 286 para permitirle al usuario 16 autorizar una conversión de divisas o conservar la presentación de Código para permitirle al usuario 16 transferir un valor suficiente a su cuenta de AC para cubrir el valor asociado con el Código F. En el ejemplo ilustrado, Miranda opta por autorizar una conversión de divisas (y un recargo por el servicio especificado) .

Luego de que un controlador 20 determina que el valor especificado está disponible en la cuenta de AC del usuario, el controlador 20 invalida el Código (por ejemplo, borra el Código F de la base de datos de cuentas 26 y base de datos de códigos 28) , debita el valor asociado con el Código F de la cuenta de AC de Miranda y acredita el valor asociado en la cuenta de AC de Carrie . En forma adicional, de acuerdo con lo mostrado en la Figura 27C, una interfaz de usuario 22 visualiza una página web de "confirmación de presentación" 278b que visualiza el saldo de cuenta actual de usuario, incluso el monto debitado en la cuenta de AC del usuario.

Con referencia una vez más a la Figura 11, esta transacción se ilustra esquemáticamente en la Figura 11 como una presentación de Miranda 306 de código " 959691co$mo" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 28, se actualizó una base de datos de cuentas 26 para reflejar un aumento en el valor monetario de Carrie del monto asociado con el Código F presentado (AIJD 50) y una reducción en el valor monetario de Miranda del monto convertido asociado con el Código F presentado (GBP 25) . Además, se actualizó la base de datos de cuentas 26 para borrar el Código "W959691co$mo" de los Códigos abiertos de Carrie .

Código PR presentado por un Beneficiario Al recibir el Código PR "F2EF1D" de Carrie, Samantha puede presentar el Código PR a una autoridad confiable 12. Por ejemplo, las Figuras 29A y 29B muestran páginas web ilustrativas que representan una presentación de un Código PR a una autoridad confiable 12. En particular, la Figura 29A muestra una página web "presentar un Código" 260c ilustrativa donde Samantha ingresó el Código "F2EF1D" en un campo de ingreso de datos de Código 264, especificó, "limpieza de suéteres" en un campo de ingreso de datos de descripción 266 y "4" en un campo de ingreso de datos de cantidad 268.

Luego de que el usuario hace clic en el botón "presentar", un controlador 20 (Figura 2) accede a una base de datos de códigos 28 para determinar si el Código presentado es válido. En este ejemplo, un controlador 20 determina desde una base de datos de códigos 28 que el Código "F2EF1D" es un código de retorno abierto con fecha de vencimiento 12/25/2008 y el destinatario pretendido sj@sjones.com. Dado que el Código presentado es abierto y el Código fue presentado por el destinatario pretendido con anterioridad a la fecha de vencimiento, el controlador 20 determina que el Código presentado es válido. Luego, el controlador recupera la descripción del valor asociada con el Código desde la base de datos de códigos 28 y compara la descripción de valor recuperada con la descripción del valor y cantidad provistas por Samantha en los campos de ingreso de datos 266 y 268.

Si un controlador 20 determina que el Código PR presentado es válido, el controlador 20 hace que la interfaz web 22 comunique el Código de retorno al usuario 16. Por ejemplo, de acuerdo con lo ilustrado en la Figura 29B, una interfaz web 22 visualiza una página web de "presentación pendiente" 288 que incluye instrucciones 290a que comunican el Código de retorno al Beneficiario e informan al Beneficiario que debe comunicar el Código de retorno al Pagador. En forma adicional, la página web 288 puede incluir una tabla 292 que visualiza el saldo de cuenta del usuario si se completó la presentación del Código PR. De acuerdo con lo mostrado en la Figura 30, se actualizó una base de datos de cuentas 26 para agregar el Código PR "8*5%RT" a los Códigos abiertos de Samantha.

Con referencia una vez más a la Figura 11, estas transacciones se ilustran esquemáticamente en la Figura 11 como una presentación de Samantha 310 de código "F2EF1D" a una autoridad confiable 12, la comunicación 312 del Código de retorno "8*5%RT" de una autoridad confiable 12 a Samantha, y la comunicación de Samantha 314 del Código de retorno "8*5%RT" a Carrie.

Luego de que Samantha provee el Código de retorno a Carrie, Carrie debe presentar el Código de retorno a una autoridad confiable 12. En particular, de acuerdo con lo mostrado en la Figura 31, una interfaz web 22 puede visualizar una página web "presentar un código" 260d que le informa al usuario que algunos Códigos abiertos requieren Códigos de Retorno y permite que el usuario 16 especifique con facilidad los Códigos de retorno. Por ejemplo, una página web 260d puede incluir botones de radio 294 que le permiten al usuario 16 seleccionar uno de los Códigos PR abiertos para el cual debe especificarse un Código de retorno en un campo de ingreso de datos de código retorno 296 o seleccionar una opción para presentar otro Código. En el ejemplo ilustrado, Carrie presenta el Código de retorno "8*5%RT" correspondiente al Código PR "F2EF1D" Luego de que Carrie hace clic en el botón "presentar", un controlador 20 (Figura 2) accede a una base de datos de códigos 28 para determinar si el Código de retorno presentado es válido. En este ejemplo, un controlador 20 determina desde la base de datos de códigos 28 que el Código presentado "8*5%RT" se corresponde con el Código PR "F2EF1D" . El controlador 20 invalida luego ambos Códigos PR (por ejemplo, borra los Códigos PR de la base de datos de cuentas 26 y la base de datos de códigos 28) , debita el valor asociado con los Códigos PR de la cuenta de AC del Pagador y acredita el valor asociado en la cuenta de AC del Beneficiario.

Con referencia una vez más a la Figura 11, esta transacción se ilustra esquemáticamente en la Figura 11 como una presentación de Carrie 316 de código "8*5%RT" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 32, se actualizó una base de datos de cuentas 26 para reflejar un aumento en el valor de servicio de Samantha del monto asociado con el Código PR presentado (limpieza de 4 suéteres) y una reducción en el valor de servicio de Carrie del mismo monto. Además, se actualizó una base de datos de cuentas 26 para borrar los Códigos PR "F2EF1D" y "8*5%RT" de los Códigos abiertos de Carrie y Samantha, respectivamente.

Código FR presentado por un Beneficiario Al recibir el Código FR "JJ7VX#" de Carrie, Samantha puede presentar el Código FR a una autoridad confiable 12. Por ejemplo, las Figuras 33A y 33B muestran páginas web ilustrativas que representan una presentación de un Código FR a una autoridad confiable 12. En particular, la Figura 33A muestra una página web "presentar un Código" 260c ilustrativa donde Samantha ingresó el Código "JJ7VX#" en un campo de ingreso de datos de Código 264, especificó "masajeador de espalda" en un campo de ingreso de datos de descripción 266 y "1" en un campo de ingreso de datos de cantidad 268.

Luego de que el usuario hace clic en el botón "presentar", un controlador 20 (Figura 2) accede a una base de datos de códigos 28 para determinar si el Código presentado es válido. En este ejemplo, un controlador 20 determina desde la base de datos de códigos 28 que el Código "JJ7VX#" es un código de retorno abierto. Dado que el Código presentado es abierto, un controlador 20 determina que el Código presentado es válido. Luego, el controlador recupera la descripción del valor asociada con el Código desde la base de datos de códigos 28 y compara la descripción de valor recuperada con la descripción del valor y cantidad provistas por Samantha en los campos de ingreso de datos 266 y 268.

Si un controlador 20 determina que el Código FR presentado es válido, el controlador 20 hace que la interfaz web 22 comunique el Código de retorno al usuario 16. Por ejemplo, de acuerdo con lo ilustrado en la Figura 33B, una interfaz web 22 visualiza una página web de "presentación pendiente" 288 que incluye instrucciones 290b que comunican el Código de retorno al Pagador e informan al Pagador que debe comunicar el Código de retorno al Beneficiario. En forma adicional, la página web 288 puede incluir una tabla 292 que visualiza el saldo de cuenta del usuario si se completó la presentación del Código FR. De acuerdo con lo mostrado en la Figura 34, se actualizó una base de datos de cuentas 26 para agregar el Código FR "5778T®" a los Códigos abiertos de Samanth .

Con referencia una vez más a la Figura 11, estas transacciones se ilustran esquemáticamente en la Figura 11 como una presentación de Samantha 318 de código "JJ7VX#" a una autoridad confiable 12, la comunicación 320 del Código de retorno "5778T®" de una autoridad confiable 12 a Samantha, y la comunicación de Samantha 322 del Código de retorno "5778T®" a Carrie.

Luego de que Samantha provee el Código de retorno a Carrie, Carrie debe presentar el Código de retorno a una autoridad confiable 12. En particular, de acuerdo con lo mostrado en la Figura 35, una interfaz web 22 puede visualizar una página web "presentar un código" 260f que le informa al usuario que algunos Códigos abiertos requieren Códigos de Retorno y permite que el usuario 16 especifique con facilidad los Códigos de retorno. Por ejemplo, una página web 260f puede incluir botones de radio 294 que le permiten al usuario 16 seleccionar uno de los Códigos FR abiertos para el cual debe especificarse un Código de retorno en un campo de ingreso de datos de código retorno 296 o seleccionar una opción para presentar otro Código. En el ejemplo ilustrado, Carrie presenta el Código de retorno "5778T®" correspondiente al Código FR J7VX#" .

Luego de que Carrie hace clic en el botón "presentar", un controlador 20 (Figura 2) accede a una base de datos de códigos 28 para determinar si el Código de retorno presentado es válido. En este ejemplo, un controlador 20 determina desde la base de datos de códigos 28 que el Código presentado "5778T®" se corresponde con el Código FR "JJ7VX#" . El controlador 20 invalida luego ambos Códigos FR (por ejemplo, borra los Códigos FR de la base de datos de cuentas 26 y la base de datos de códigos 28) , debita el valor asociado con los Códigos FR de la cuenta de AC de Samantha y acredita el valor asociado en la cuenta de AC de Carrie.

Con referencia una vez más a la Figura 11, esta transacción se ilustra esquemáticamente en la Figura 11 como una presentación de Carrie 324 de código "5778T®" a una autoridad confiable 12. En forma adicional, de acuerdo con lo mostrado en la Figura 36, se actualizó una base de datos de cuentas 26 para reflejar una reducción en el valor de producto de Samantha del monto asociado con el Código FR presentado (1 masajeador de espalda) y un aumento en el valor de producto de Carrie del mismo monto. Además, se actualizó una base de datos de cuentas 26 para borrar los Códigos FR "JJ7VX#" y "5778T®" de los Códigos abiertos de Carrie y Samantha, respectivamente.

Flujo de procesamiento de códigos Para representar aún más la operación de procesamiento de un sistema de transferencia de valor 10, las Figuras 37 a 40 ilustran con diagramas los procedimientos de solicitud y presentación de Código para cada uno de los cuatro tipos diferentes de Códigos descritos anteriormente.

Con referencia ahora a la Figura 37, se describe una transacción de Código P 350 ilustrativa. En particular, en el paso 352, un Pagador solicita un Código P para un valor especificado a un autoridad confiable 12. En el paso 354, una autoridad confiable 12 determina si el valor especificado está disponible en la cuenta de AC del Pagador, y, en ese caso, genera un Código P, asocia el valor especificado con el Código P, actualiza la base de datos de cuentas 26 y la base de datos de códigos 28 y comunica el Código P al Pagador. Luego, en el paso 356, el Pagador recibe el Código P de una autoridad confiable 12. En el paso 358, el Pagador comunica el Código P al Beneficiario. En el paso 360, el Beneficiario recibe el Código P del Pagador y presenta el Código P a una autoridad confiable 12. En el paso 362, una autoridad confiable 12 recibe el Código P del Beneficiario. En el paso 364, la autoridad confiable 12 determina si el Código P recibido es válido, y, en ese caso, determina el valor asociado con el Código P, invalida el Código P (por ejemplo, lo borra de la base de datos de códigos 28) , debita el valor asociado en la cuenta de AC del Pagador y acredita el valor asociado de la cuenta de AC del Beneficiario. Finalmente, en el paso 366, el Beneficiario recibe el valor en su cuenta de AC.

Con referencia ahora a la Figura 38, se describe una transacción de Código F 370 ilustrativa. En particular, en el paso 372, un Beneficiario solicita un Código F para un valor especificado a una autoridad confiable 12. En el paso 374, la autoridad confiable 12 recibe la solicitud del Beneficiario, genera un Código F, asocia el valor especificado con el Código F, actualiza la base de datos de cuentas 26 y la base de datos de códigos 28 y comunica el Código F al Beneficiario. Luego, en el paso 376, el Beneficiario recibe el Código F de una autoridad confiable 12. En el paso 378, el Beneficiario comunica el Código P al Pagador. En el paso 380, el Pagador recibe el Código F del Beneficiario y presenta el Código F a una autoridad confiable 12. En el paso 382, una autoridad confiable 12 recibe el Código F del Pagador. En el paso 384, la autoridad confiable 12 determina si el Código F recibido es válido, y, en ese caso, determina el valor asociado con el Código F, determina si el valor asociado está disponible en la cuenta de AC del Pagador, y, en ese caso, invalida el Código F (por ejemplo, lo borra de la base de datos de códigos 28) , debita el valor asociado de la cuenta de AC del Pagador y acredita el valor asociado en la cuenta de AC del Beneficiario. Finalmente, en el paso 386, el Beneficiario recibe el valor en su cuenta de AC.

Con referencia ahora a la Figura 39, se describe una transacción de Código PR 390 ilustrativa. En particular, en el paso 392, un Pagador solicita un Código PR para un valor especificado a una autoridad confiable 12. En el paso 394, una autoridad confiable 12 determina si el valor especificado está disponible en la cuenta de AC del Pagador, y, en ese caso, genera un par de Códigos PR (por ejemplo, Cl, C2), asocia el valor especificado con los Códigos PR, actualiza la base de datos de cuentas 26 y la base de datos de códigos 28 y comunica el Cl al Pagador. Luego, en el paso 396, el Pagador recibe el Cl de una autoridad confiable 12. En el paso 398, el Pagador comunica el Cl al Beneficiario. En el paso 400, el Beneficiario recibe el Cl del Pagador y presenta el Cl a una autoridad confiable 12. En el paso 402, una autoridad confiable 12 recibe el Cl del Beneficiario. En el paso 404, una autoridad confiable 12 determina si el Cl recibido es válido, y, en ese caso, comunica el C2 al Beneficiario.

Luego, en el paso 406, el Beneficiario recibe el C2 de una autoridad confiable 12. En el paso 408, el Beneficiario comunica el C2 al Pagador. En el paso 410, el Pagador recibe el C2 del Beneficiario y presenta el C2 a una autoridad confiable 12. En el paso 412, una autoridad confiable 12 recibe el C2 del Pagador. En el paso 414, la autoridad confiable 12 determina si el C2 recibido es válido, y, en ese caso, determina el valor asociado con el C2 , invalida el Cl y el C2 (por ejemplo, los borra de la base de datos de códigos 28), debita el valor asociado en la cuenta de AC del Pagador y acredita el valor asociado de la cuenta de AC del Beneficiario. Finalmente, en el paso 416, el Beneficiario recibe el valor en su cuenta de AC.

Con referencia ahora a la Figura 40, se describe una transacción de Código FR 420 ilustrativa. En particular, en el paso 422, un Beneficiario solicita un Código FR para un valor especificado a una autoridad confiable 12. En el paso 424, la autoridad confiable 12 recibe la solicitud del Beneficiario, genera un par de Códigos FR (por ejemplo, CI1, CI2), asocia el valor especificado con CI1 y CI2, actualiza la base de datos de cuentas 26 y la base de datos de códigos 28 y comunica el CI1 al Beneficiario. Luego, en el paso 426, el Beneficiario recibe el CI1 de una autoridad confiable 12. En el paso 428, el Beneficiario comunica el CI1 al Pagador. En el paso 430, el Pagador recibe el CI1 del Beneficiario y presenta el CI1 a una autoridad confiable 12. En el paso 432, una autoridad confiable 12 recibe el CI1 del Pagador. En el paso 434, una autoridad confiable 12 determina si el valor especificado está disponible en la cuenta de AC del Pagador y, en ese caso, determina si el CI1 recibido es válido y, en ese caso, comunica el CI2 al Pagador.

Luego, en el paso 436, el Pagador recibe el CI2. de una autoridad confiable 12. En el paso 438, el Pagador comunica el CI2 al Beneficiario. En el paso 440, el Beneficiario recibe el CI2 del Pagador y presenta el CI2 a una autoridad confiable 12. En el paso 442, una autoridad confiable 12 recibe el CI2 del Beneficiario. En el paso 444, la autoridad confiable 12 determina si el CI2 recibido es válido, y, en ese caso, determina el valor asociado con el CI2, invalida el CI1 y el CI2 (por ejemplo, los borra de la base de datos de códigos 28), debita el valor asociado en la cuenta de AC del Pagador y acredita el valor asociado de la cuenta de AC del Beneficiario. Finalmente, en el paso 446, el Beneficiario recibe el valor en su cuenta de AC.

Operación de manejo de códigos llevada a cabo por una autoridad confiable Tal como se describe anteriormente, los sistemas de acuerdo con esta invención pueden utilizar Códigos P, Códigos F, Códigos PR y/o Códigos FR. Ahora se describirá en forma más detallada la operación llevada a cabo por una autoridad confiable 12 respecto de las solicitudes y presentaciones de cada uno de estos tipos de código ilustrativos.

En particular, la Figura 41 ilustra un procedimiento 500 ilustrativo implementado por una autoridad confiable 12 para el procesamiento de Códigos P. Comenzando por el paso 502, una autoridad confiable 12 recibe una solicitud de un Pagador de un Código P para un valor especificado. Luego, en el paso 504, la autoridad 12 determina si el valor especificado está disponible para ser retirado de la cuenta de AC del Pagador. En caso contrario, en el paso 506, puede visualizarse un mensaje de error para el Pagador y puede finalizar el procedimiento. De otro modo, el procedimiento continúa con el paso 508, por medio del cual la autoridad confiable 12 genera un Código P. Luego, en el paso 510, la autoridad confiable 12 asocia el valor especificado con el Código P generado en el paso 508. En el paso 512, la autoridad confiable 12 registra el Código P generado y su valor asociado como un código abierto en una base de datos de códigos 28. Luego, en el paso 514, la autoridad confiable 12 comunica el Código P generado al Pagador, que puede comunicar luego el Código P al Beneficiario .

En el paso 516, la autoridad confiable 12 determina si se recibió una presentación de Código P del Beneficiario. En caso contrario, la autoridad confiable continúa esperando. No obstante, si la autoridad confiable recibe una presentación de Código P, en el paso 518, la autoridad confiable 12 determina si el Código P presentado es válido. Por ejemplo, la autoridad confiable 12 puede llevar a cabo una búsqueda en la base de datos de códigos 28 para determinar si el Código P presentado aún es abierto, si los datos adicionales provistos por el Pagador son correctos (por ejemplo, la descripción y cantidad del valor, el destinatario pretendido, etc.). Si el Código P presentado no es válido, en el paso 520, la autoridad confiable 12 puede visualizar un mensaje de error e inducir al Pagador a volver a presentar el Código P. La autoridad confiable 12 puede permitir una cantidad ilimitada de reintentos o puede evitar que el Beneficiario vuelva a presentar el Código P luego de una cantidad predeterminada de intentos fallidos.

Si la autoridad confiable 12 determina que el Código P presentado es válido, en el paso 522, la autoridad confiable 12 determina el valor asociado con el Código P desde la base de datos de códigos 28. Luego, en el paso 524, la autoridad confiable debita el valor asociado de la cuenta de AC del Pagador. En el paso 526, la autoridad confiable 12 invalida el Código P. Por ejemplo, la autoridad confiable 12 puede marcar el Código P como "cerrado" en la base de datos de códigos 28 y eliminar el Código P de la cuenta de AC del Pagador en la base de datos de cuentas 26. Finalmente, en el paso 528, la autoridad confiable 12 acredita el valor asociado en la cuenta de AC del Beneficiario en la basé de datos de cuentas 26.

Con referencia ahora a la Figura 42, se describe un procedimiento 530 ilustrativo implementado por una autoridad confiable 12 para el procesamiento de Códigos F. Comenzando por el paso 532, una autoridad confiable 12 recibe una solicitud de un Beneficiario de un Código F para un valor especificado. Luego, en el paso 534, la autoridad confiable 12 genera un Código F. En el paso 536, la autoridad confiable 12 registra el Código F generado y su valor asociado como un código abierto en una base de datos de códigos 28. Luego, en el paso 538, la autoridad confiable 12 comunica el Código F generado al Beneficiario, que puede comunicar luego el Código F al Pagador.

En el paso 540, la autoridad confiable 12 determina si se recibió una presentación de Código F del Pagador. En caso contrario, la autoridad confiable continúa esperando. No obstante, si la autoridad confiable recibe una presentación de Código F, en el paso 542, la autoridad confiable 12 determina si el Código F presentado es válido. Por ejemplo, la autoridad confiable 12 puede llevar a cabo una búsqueda en la base de datos de códigos 28 para determinar si el Código F presentado aún es abierto, si los datos adicionales provistos por el Pagador son correctos (por ejemplo, la descripción y cantidad del valor, el destinatario pretendido, etc.). Si el Código F presentado no es válido, en el paso 544, la autoridad confiable 12 puede visualizar un mensaje de error e inducir al Pagador a volver a presentar el Código F. La autoridad confiable 12 puede permitir una cantidad ilimitada de reintentos o puede evitar que el Pagador vuelva a presentar el Código F luego de una cantidad predeterminada de intentos fallidos.

Si la autoridad confiable 12 determina que el Código F presentado es válido, en el paso 546, la autoridad confiable 12 determina el valor asociado con el Código F desde la base de datos de códigos 28. Luego, en el paso 548, la autoridad 12 determina si el valor especificado está disponible para ser retirado de la cuenta de AC del Pagador. En caso contrario, en el paso 550, puede visualizarse un mensaje de error para el Pagador y puede finalizar el procedimiento. De otro modo, el procedimiento continúa con en el paso 552 y la autoridad confiable debita el valor asociado de la cuenta de AC del Pagador. En el paso 554, la autoridad confiable 12 invalida el Código F. Por ejemplo, la autoridad confiable 12 puede marcar el Código F como "cerrado" en la base de datos de códigos 28 y eliminar el Código F de la cuenta de AC del Beneficiario en la base de datos de cuentas 26. Finalmente, en el paso 556, la autoridad confiable 12 acredita el valor asociado en la cuenta de AC del Beneficiario en la base de datos de cuentas 26.

Con referencia ahora a las Figuras 43A y 43B, se describe un procedimiento 560 ilustrativo implementado por una autoridad confiable 12 para el procesamiento de Códigos PR. Comenzando por el paso 562, una autoridad confiable 12 recibe una solicitud de un Pagador de un Código PR para un valor especificado. Luego, en el paso 564, la autoridad 12 determina si el valor especificado está disponible para ser retirado de la cuenta de AC del Pagador. En caso contrario, en el paso 566, puede visualizarse un mensaje de error para el Pagador y puede finalizar el procedimiento. De otro modo, el procedimiento continúa con el paso 568, por medio del cual la autoridad confiable 12 genera un par de Códigos PR (por ejemplo, Cl y C2) . Luego, en el paso 570, la autoridad confiable 12 asocia el valor especificado con Cl y C2 generados en el paso 568. En el paso 572, la autoridad confiable 12 registra el Cl y el C2 y su valor asociado como códigos abiertos en una base de datos de códigos 28. Luego, en el paso 574, la autoridad confiable 12 comunica el Cl al Pagador, que puede comunicar luego el Cl al Beneficiario.

En el paso 576, la autoridad confiable 12 determina si se recibió una presentación de Cl de un Beneficiario. En caso contrario, la autoridad confiable continúa esperando. No obstante, si la autoridad confiable recibe una presentación de Cl, en el paso 578, la autoridad confiable 12 determina si el Cl presentado es válido. Por ejemplo, la autoridad confiable 12 puede llevar a cabo Una búsqueda en la base de datos de códigos 28 para determinar si el Cl presentado aún es abierto, si los datos adicionales provistos por el Beneficiario son correctos (por ejemplo, la descripción y cantidad del valor, el destinatario pretendido, etc.). Si el Cl presentado no es válido, en el paso 580, la autoridad confiable 12 puede visualizar un mensaje de error e inducir al Beneficiario volver a presentar el Cl . La autoridad confiable 12 puede permitir una cantidad ilimitada de reinténtos o puede evitar que el Beneficiario vuelva a presentar el Cl luego de una cantidad predeterminada de intentos fallidos. Luego, en el paso 582, la autoridad confiable 12 comunica el C2 al Beneficiario, que puede comunicar luego el C2 al Pagador.

En el paso 584, la autoridad confiable 12 determina si se recibió una presentación de C2 de un Pagador. En caso contrario, la autoridad confiable continúa esperando. No obstante, si la autoridad confiable recibe una presentación de C2, en el paso 586, la autoridad confiable 12 determina si el C2 presentado es válido. Por ejemplo, la autoridad confiable 12 puede llevar a cabo una búsqueda en la base de datos de códigos 28 para determinar si el C2 presentado aún es abierto, si los datos adicionales provistos por el Pagador son correctos (por ejemplo, la descripción y cantidad del valor, el destinatario pretendido, etc.). Si el C2 presentado no es válido, en el paso 588, la autoridad confiable 12 puede visualizar un mensaje de error e inducir al Pagador volver a presentar el C2. La autoridad confiable 12 puede permitir una cantidad ilimitada de reintentos o puede evitar que el Pagador vuelva a presentar el C2 luego de una cantidad predeterminada de intentos fallidos.

Si la autoridad confiable 12 determina que el C2 presentado es válido, en el paso 590, la autoridad confiable 12 determina el valor asociado con el C2 desde la base de datos de códigos 28. Luego, en el paso 592, la autoridad confiable debita el valor asociado de la cuenta de AC del Pagador. En el paso 594, la autoridad confiable 12 invalida el Cl y el C2. Por ejemplo, la autoridad confiable 12 puede marcar el Cl y el C2 como "cerrados" en la base de datos de códigos 28 y eliminar el Cl de la cuenta de AC del Pagador en la base de datos de cuentas 26. Finalmente, en el paso 596, la autoridad confiable 12 acredita el valor asociado en la cuenta de AC del Beneficiario en la base de datos de cuentas 26.

Con referencia ahora a las Figuras 44A y 44B, se describe un procedimiento 600 ilustrativo implementado por una autoridad confiable 12 para el procesamiento de Códigos FR. Comenzando por el paso 602, una autoridad confiable 12 recibe una solicitud de un Beneficiario de un Código FR para un valor especificado. Luego, en el paso 604, la autoridad confiable 12 genera un par de Códigos FR (por ejemplo, CIl y CI2) . Luego, en el paso 606, la autoridad confiable 12 asocia el valor especificado con CIl y CI2 generados en el paso 604. En el paso 608, la autoridad confiable 12 registra el CIl y el CI2 y su valor asociado como códigos abiertos en una base de datos de códigos 28. Luego, en el paso 610, la autoridad confiable 12 comunica el CU al Beneficiario, que puede comunicar luego el CIl al Pagador.

En el paso 612, la autoridad confiable 12 determina si se recibió una presentación de CIl de un Pagador. En caso contrario, la autoridad confiable continúa esperando. No obstante, si la autoridad confiable recibe una presentación de CIl, en el paso 614, la autoridad confiable 12 determina si el CIl presentado es válido. Por ejemplo, la autoridad confiable 12 puede llevar a cabo una búsqueda en la base de datos de códigos 28 para determinar si el CI1 presentado aún es abierto, si los datos adicionales provistos por el Pagador son correctos (por ejemplo, la descripción y cantidad del valor, el destinatario pretendido, etc.). Si el CI1 presentado no es válido, en el paso 616, la autoridad confiable 12 puede visualizar un mensaje de error e inducir al Pagador volver a presentar el CI1. La autoridad confiable 12 puede permitir una cantidad ilimitada de reintentos o puede evitar que el Pagador vuelva a presentar el CI1 luego de una cantidad predeterminada de intentos fallidos.

Luego, en el paso 618, la autoridad confiable 12 determina el valor asociado con el CI1 desde la base de datos de códigos 28. En el paso 620, la autoridad 12 determina si el valor especificado está disponible para ser retirado de la cuenta de AC del Pagador. En caso contrario, en el paso 622, puede visualizarse un mensaje de error para el Pagador y puede finalizar el procedimiento. De otro modo, el procedimiento continúa con el paso 624 y la autoridad confiable 12 comunica el CI2 al Pagador, que puede comunicar luego el CI2 al Beneficiario.

En el paso 626, la autoridad confiable 12 determina si se recibió una presentación de CI2 de un Beneficiario. En caso contrario, la autoridad confiable continúa esperando. No obstante, si la autoridad confiable recibe una presentación de CI2, en el paso 628, la autoridad confiable 12 determina si el CI2 presentado es válido. Por ejemplo, la autoridad confiable 12 puede llevar a cabo una búsqueda en la base de datos de códigos 28 para determinar si el CI2 presentado aún es abierto, si los datos adicionales provistos por el Beneficiario son correctos (por ejemplo, la descripción y cantidad del valor, el destinatario pretendido, etc.). Si el CI2 presentado no es válido, en el paso 630, la autoridad confiable 12 puede visualizar un mensaje de error e inducir al Beneficiario volver a presentar el CI2. La autoridad confiable 12 puede permitir una cantidad ilimitada de reintentos o puede evitar que el Beneficiario vuelva a presentar el CI2 luego de una cantidad predeterminada de intentos fallidos.

Si la autoridad confiable 12 determina que el CI2 presentado es válido, en el paso 632, la autoridad confiable 12 determina el valor asociado con el CI2 desde la base de datos 'de códigos 28. Luego, en el paso 634, la autoridad confiable debita el valor asociado de la cuenta de AC del Pagador. En el paso 636, la autoridad confiable 12 invalida el CI1 y el CI2. Por ejemplo, la autoridad confiable 12 puede marcar el CI1 y el CI2 como "cerrados" en la base de datos de códigos 28 y eliminar el CI1 de la cuenta de AC del Beneficiario y el CI2 de la cuenta de AC del Pagador en la 8 base de datos de cuentas 26. Finalmente, en el paso 638, la autoridad confiable 12 acredita el valor asociado en la cuenta de AC del Beneficiario en la base de datos de cuentas 26.

Los expertos en el arte comprenderán que la autoridad confiable 12 puede utilizar otros procedimientos para manejo de Código de retorno, incluso procedimientos donde tanto el Pagador como el Beneficiario soliciten en forma prácticamente simultánea Códigos de retorno para el mismo valor y la autoridad confiable establezca una correspondencia entre las solicitudes de Códigos de retorno prácticamente simultáneas.

Los expertos en el arte comprenderán, además, que la autoridad confiable 12 puede cobrar a los usuarios 16 cargos en concepto de uno o más de los servicios prestado por la autoridad confiable. Por ejemplo, la autoridad confiable 12 puede cobrar a los usuarios 16 cargos en concepto de uno o más de los siguientes: transferencia de valor entre cuentas de AC y cuentas externas, solicitud de un Código y presentación de un Código. La autoridad confiable 12 puede cobrar a los usuarios 16 cargos variables sobre la base del monto y/o tipo de valor almacenado en un almacenamiento de valores 30 y/o puede cobrar a los usuarios 16 cargos en concepto de solicitudes y/o presentaciones de Código sobre la base del monto y/o tipo del valor asociado con el Código.

Lo que antecede ilustra simplemente los principios de esta invención y los expertos en el arte pueden efectuar diversas modificaciones sin alejarse del alcance y el espíritu de esta invención.

Claims (64)

NOVEDAD DE LA INVENCIÓN Habiéndose descrito la invención como antecede, se considera como una novedad y, por lo tanto, se reclama como propiedad lo contenido en las siguientes: REIVINDICACIONES

1. Un sistema caracterizado porque comprende: una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente, donde la autoridad confiable está adaptada para: recibir uña solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un código sustancialmente aleatorio; asociar el código generado con el primer valor especificado ; comunicar el código generado al primer usuario; recibir el código generado de un segundo usuario; determinar si el código recibido es válido; y - si el código recibido es válido, debitar el primer valor especificado de la cuenta del primer usuario y acreditar el primer valor especificado én la cuenta del segundo usuario para transferir la titularidad del primer valor especificado del primer usuario al segundo usuario.

2. El sistema de acuerdo con la reivindicación 1, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

3. El sistema de acuerdo con la reivindicación 1, caracterizado porque comprende, además, una base de datos de códigos que comprende una lista de códigos generados.

4. El sistema de acuerdo con la reivindicación 3, caracterizado porque si el código recibido es válido, la autoridad confiable está adaptada, además, para invalidar el código recibido.

5. El sistema de acuerdo con la reivindicación 3, caracterizado porque determinar la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos .

6. El sistema de acuerdo con la reivindicación 1, caracterizado porque recibir comprende, además, recibir un código asociado y un segundo valor especificado del segundo usuario, y donde determinar la validez del código recibido comprende determinar si el segundo valor es igual que el primer valor.

7. El sistema de acuerdo con la reivindicación 1, caracterizado porque la autoridad confiable está adaptada, además, para determinar si la cuenta del primer usuario incluye el primer valor especificado.

8. El sistema de acuerdo con la reivindicación 7, caracterizado porque la autoridad confiable lleva a cabo el paso de débito y el paso de acreditación solamente si la cuenta del primer usuario incluye el primer valor especificado .

9. Un sistema caracterizado porque comprende: una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente, donde la autoridad confiable está adaptada par : recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un código sustancialmente aleatorio; asociar el código generado con el primer valor especificado; comunicar el código asociado al primer usuario; recibir el código asociado de un segundo usuario; determinar si el código recibido es válido; y si el código recibido es válido, debitar el primer valor especificado de la cuenta del segundo usuario y acreditar el primer valor especificado en la cuenta del primer usuario para transferir la titularidad del primer valor especificado del segundo usuario al primer usuario.

10. El sistema de acuerdo con la reivindicación 9, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

11. El sistema de acuerdo con la reivindicación 9, caracterizado porque comprende, además, una base de datos de códigos que comprende una lista de códigos generados.

12. El sistema de acuerdo con la reivindicación 11, caracterizado porque si el código recibido es válido, la autoridad confiable está adaptada, además, para invalidar el código recibido.

13. El sistema de acuerdo con la reivindicación 11, caracterizado porque determinar la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos .

14. El sistema de acuerdo con la reivindicación 9, caracterizado porque recibir comprende, además, recibir un código asociado y un segundo valor especificado del segundo usuario, y donde determinar la validez del código recibido comprende determinar si el segundo valor es igual que el primer valor.

15. El sistema de acuerdo con la reivindicación 9, caracterizado porque la autoridad confiable está adaptada, además, para determinar si la cuenta del segundo usuario incluye el primer valor especificado.

16. El sistema de acuerdo con la reivindicación 15, caracterizado porque la autoridad confiable lleva a cabo el paso de débito y el paso de acreditación solamente si la cuenta del segundo usuario incluye el primer valor especificado.

17. Un sistema caracterizado porque comprende: una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente, donde la autoridad confiable está adaptada para: recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un primer código y un segundo código sustancialmente aleatorios; asociar los códigos generados con el primer valor especificado ; comunicar el primer código al primer usuario; recibir el primer código de un segundo usuario; determinar si el primer código recibido es válido; comunicar el segundo código asociado al segundo usuario ; recibir el segundo código del primer usuario; determinar si el segundo código recibido es válido; y si el segundo código recibido es válido, debitar el primer valor especificado de la cuenta del primer usuario y acreditar el primer valor especificado en la cuenta del segundo usuario para transferir la titularidad del primer valor especificado del primer usuario al segundo usuario.

18. El sistema de acuerdo con la reivindicación 17, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

19. El sistema de acuerdo con la reivindicación 17, caracterizado porque comprende, además, una base de datos de códigos que comprende una lista de códigos generados.

20. El sistema de acuerdo con la reivindicación 19, caracterizado porque si el primer código y el segundo código recibidos son válidos, la autoridad confiable está adaptada, además, para invalidar los códigos recibidos.

21. El sistema de acuerdo con la reivindicación 19, caracterizado porque determinar la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos.

22. El sistema de acuerdo con la reivindicación 17, caracterizado porque recibir el primer código comprende, además, recibir el primer código y un segundo valor especificado del segundo usuario, y donde determinar la validez del primer código comprende determinar si el segundo valor es igual que el primer valor.

23. El sistema de acuerdo con la reivindicación 17, caracterizado porque la autoridad confiable está adaptada, además, para determinar si la cuenta del primer usuario incluye el primer valor especificado.

24. El sistema de acuerdo con la reivindicación 23, caracterizado porque la autoridad confiable lleva a cabo el paso de débito y el paso de acreditación solamente si la cuenta del primer usuario incluye el primer valor especificado.

25. Un sistema caracterizado porque comprende: una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente, donde la autoridad confiable está adaptada para : recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un primer código y un segundo código sustancialmente aleatorios asociar los códigos generados con el primer valor especificado; comunicar el primer código al primer usuario; recibir el primer código de un segundo usuario; determinar si el primer código recibido es válido; comunicar el segundo código asociado al segundo usuario; recibir el segundo código del primer usuario; determinar si el segundo código recibido es válido; y si el segundo código recibido es válido, debitar el primer valor especificado de la cuenta del segundo usuario y acreditar el primer valor especificado en la cuenta del primer usuario para transferir la titularidad del primer valor especificado del segundo usuario al primer usuario.

26. El sistema de acuerdo con la reivindicación 25, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

27. El sistema de acuerdo con la reivindicación 25, caracterizado porque comprende, además, una base de datos de códigos que comprende una lista de códigos generados.

28. El sistema de acuerdo con la reivindicación 27, caracterizado porque si el primer código y el segundo código recibidos son válidos, la autoridad confiable está adaptada, además, para invalidar los códigos recibidos.

29. El sistema de acuerdo con la reivindicación 27, caracterizado porque determinar la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos .

30. El sistema de acuerdo con la reivindicación 25, caracterizado porque recibir el primer código comprende, además, recibir el primer código y un segundo valor especificado del segundo usuario, y donde determinar la validez del primer código comprende determinar si el segundo · valor es igual que el primer valor.

31. El sistema de acuerdo con la reivindicación 25, caracterizado porque la autoridad confiable está adaptada, además, para determinar si la cuenta del segundo usuario incluye el primer valor especificado.

32. El sistema de acuerdo con la reivindicación 31, caracterizado porque la autoridad confiable lleva a cabo el paso de débito y el paso de acreditación solamente si la cuenta del segundo usuario incluye el primer valor especificado.

33. Un método caracterizado porque . comprende : proveer un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente; recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; - generar un código sustancialmente aleatorio; asociar el código generado con el primer valor especificado; comunicar el código generado al primer usuario; recibir el código generado de un segundo usuario; - determinar si el código recibido es válido; y si el código recibido es válido, debitar el primer valor especificado de la cuenta del primer usuario y acreditar el primer valor especificado en la cuenta del segundo usuario para transferir la titularidad del primer valor especificado del primer usuario al segundo usuario.

34. El método de acuerdo con la reivindicación 33, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

35. El método de acuerdo con la reivindicación 33, caracterizado porque comprende, además, proveer una base de datos de códigos que comprende una lista de códigos generados .

36. El método de acuerdo con la reivindicación 35, caracterizado porque si el código recibido es válido, se invalida el código recibido.

37. El método de acuerdo con la reivindicación 35, caracterizado porque determinar de la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos.

38. El método de acuerdo con la reivindicación 33, caracterizado porque recibir comprende, además, recibir el código asociado y un segundo valor especificado del segundo usuario, y donde determinar la validez del código recibido comprende determinar si el segundo valor es igual que el primer valor.

39. El método de acuerdo con la reivindicación 33, caracterizado porque comprende, además, determinar si la cuenta del primer usuario incluye el primer valor especificado .

40. El método de acuerdo con la reivindicación 39, caracterizado porque comprende, además, llevar a cabo el paso de débito y el paso de acreditación solamente si la cuenta del primer usuario incluye el primer valor especificado.

41. Un método caracterizado porque comprende: proveer una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente; recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un código sustancialmente aleatorio; asociar el código generado con el primer valor especificado ; comunicar el código asociado al primer usuario; - recibir el código asociado de un segundo usuario; determinar si el código recibido es válido; y si el código recibido es válido, debitar el primer valor especificado de la cuenta del segundo usuario y acreditar el primer valor especificado en la cuenta del primer usuario para transferir la titularidad del primer valor especificado del segundo usuario al primer usuario.

42. El método de acuerdo con la reivindicación 41, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

43. El método de acuerdo con la reivindicación 41, caracterizado porque comprende, además, proveer una base de datos de códigos que comprende una lista de códigos generados .

44. El método de acuerdo con la reivindicación 43, caracterizado porque si el código recibido es válido, se invalida el código recibido.

45. El método de acuerdo con la reivindicación 43, caracterizado porque determinar de la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos .

46. El método de acuerdo con la reivindicación 41, caracterizado porque recibir comprende, además, recibir el código asociado y un segundo valor especificado del segundo usuario, y donde determinar la validez del código recibido comprende determinar si el segundo valor es igual que el primer valor.

47. El método de acuerdo con la reivindicación 41, caracterizado porque comprende, además, determinar si la cuenta del segundo usuario incluye el primer valor especificado.

48. El método de acuerdo con la reivindicación 47, caracterizado porque comprende, además, llevar a cabo el paso de débito y el paso de acreditación solamente si la cuenta del segundo usuario incluye el primer valor especificado.

49. Un método caracterizado porque comprende: proveer una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente; - recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un primer código y un segundo código sustancialmente aleatorios; asociar los códigos generados con el primer valor especificado; comunicar el primer código al primer usuario; recibir el primer código de un segundo usuario; determinar si el primer código recibido es válido; comunicar el segundo código asociado al segundo usuario; recibir el segundo código del primer usuario; determinar si el segundo código recibido es válido; Y si el segundo código recibido es válido, debitar el primer valor especificado de la cuenta del primer usuario y acreditar el primer valor especificado en la cuenta del segundo usuario para transferir la titularidad del primer valor especificado del primer usuario al segundo usuario.

50. El método de acuerdo con la reivindicación 49, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

51. El método de acuerdo con la reivindicación 49, caracterizado porque comprende, además, proveer una base de datos de códigos que comprende una lista de códigos generados .

52. El método de acuerdo con la reivindicación 51, caracterizado porque si el primer código y el segundo código recibidos son válidos, se invalidan los códigos recibidos.

53. El método de acuerdo con la reivindicación 51, caracterizado porque determinar de la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos .

54. El método de acuerdo con la reivindicación 49, caracterizado porque recibir el primer código comprende, además, recibir el primer código y un segundo valor especificado del. segundo usuario, y donde determinar la validez del primer código comprende determinar si el segundo valor es igual que el primer valor.

55. El método de acuerdo con la reivindicación 49, caracterizado porque comprende, además, determinar si la cuenta del primer usuario incluye el primer valor especificado .

56. El método de acuerdo con la reivindicación 55, caracterizado porque comprende, además, llevar a cabo el paso de débito y el paso de acreditación solamente si la cuenta del primer usuario incluye el primer valor especificado.

57. Un método caracterizado porque comprende: - proveer una autoridad confiable que comprende un almacenamiento de valores adaptado para almacenar un valor que pertenece a usuarios, y una base de datos de cuentas que comprende cuentas de usuario, cada cuenta de usuario que está asociada con un usuario correspondiente y que comprende una lista de los valores almacenados que pertenecen al usuario correspondiente; recibir una solicitud de un primer usuario para que un código se asocie con un primer valor especificado; generar un primer código y un segundo código sustancialmente aleatorios; asociar los códigos generados con el primer valor especificado; comunicar el primer código al primer usuario; recibir el primer código de un segundo usuario; determinar si el primer código recibido es válido; comunicar el segundo código asociado al segundo usuario; recibir el segundo código del primer usuario; determinar si el segundo código recibido es válido; y si el segundo código recibido es válido, debitar el primer valor especificado de la cuenta del segundo usuario y acreditar el primer valor especificado en la cuenta del primer usuario para transferir la titularidad del primer valor especificado del segundo usuario al primer usuario.

58. El método de acuerdo con la reivindicación 57, caracterizado porque el valor almacenado comprende cualquiera de los siguientes: divisas, un producto y/o un servicio.

59. El método de acuerdo con la reivindicación 57, caracterizado porque comprende, además, proveer una base de datos de códigos que comprende una lista de códigos generados .

60. El método de acuerdo con la reivindicación 59, caracterizado porque si el primer código y el segundo código recibidos son válidos, se invalidan los códigos recibidos.

61. El método de acuerdo con la reivindicación 59, caracterizado porque determinar de la validez del código recibido comprende determinar si el código recibido está en la base de datos de códigos .

62. El método de acuerdo con la reivindicación 57, caracterizado porque recibir el primer código comprende, además, recibir 'el primer código y un segundo valor especificado del segundo usuario, y donde determinar la validez del primer código comprende determinar si el segundo valor es igual que el primer valor.

63. El método de acuerdo con la reivindicación 57, caracterizado porque comprende, además, determinar si la cuenta del segundo usuario incluye el primer valor especificado .

64. El método de acuerdo con la reivindicación 63, caracterizado porque comprende,, además, llevar a cabo el paso de débito y el paso de acreditación solamente si la cuenta del segundo usuario incluye el primer valor especificado.