JP2011528473A - 価値を移転するためのシステムおよび方法 - Google Patents

Abstract

移転されるべき価値と関連付けられた実質的にランダムなコードを用いることによって価値を第１のユーザから第２のユーザに移転するためのシステムおよび方法が提供される。信頼できる機関は、価値を蓄えるために使用されるユーザ口座をユーザが作ることを可能にする。第１のユーザは支払いコードを請求することができ、それを指定された価値と関連付けて第２のユーザに伝えることができ、第２のユーザは支払いコードを信頼できる機関に提示することができる。支払いコードが有効ならば、信頼できる機関は、指定された価値を第１のユーザの口座から引き落として、指定された価値を第２のユーザの口座に振り込む。あるいは、第２のユーザはインボイスコードを請求することができ、それを指定された価値と関連付けて第１のユーザに伝えることができ、第１のユーザはインボイスコードを信頼できる機関に提示することができる。インボイスコードが有効であるならば、信頼できる機関は指定された価値を第１のユーザの口座から引き落として指定された価値を第２のユーザの口座に振り込む。

Description

本発明は、移転されるべき価値と関連付けられた実質的にランダムなコードを用いることによって価値を第１のユーザから第２のユーザに移転するためのシステムおよび方法に関する。

商品およびサービスに対して人が通貨を移転して支払いをすることを可能にする種々の手法が存在する。個人対個人の取引では、第１の当事者は、第２の当事者から受け取った商品またはサービスに対して贈り物、ローン返済金、賃金、あるいは支払い金として通貨を第２の当事者に直接移転することができる。さらに、通貨を直接引き渡さずに支払いを容易にするために、小切手、送金為替、旅行者小切手、デビットカード、ギフトカード、クレジットカード、クーポン券、口座振込および電信送金など、多くの支払い手法が開発されている。さらに、近年、代替の通貨システムとしてペイパルおよび種々の電子通貨システムなどのさらなる支払いシステムが開発されている。このような手法は全て直接的通貨交換に代わる手段を有利に提供するけれども、各々の手法は幾つかの限界を有する。

特に、大抵の従前知られている代替の通貨システムには種々のプライバシーおよび詐欺問題がある。例えば、消費者がクレジットカードあるいはデビットカードを使って小売業者から商品を購入するとき、小売業者は、その消費者の名前およびクレジットカード／デビットカード番号、有効期限、カード確認価値（「ＣＶＶ」：card verification value ）番号、住所あるいは他の金融データを含む、その消費者に関する相当の量の情報を取引の一部として要求することがある。多くの小売業者は、無許可のアクセスを被ることのある膨大なデータベースにそのような個人情報を格納する。実際、小売業者が消費者クレジットカードのデータのセキュリティを充分に守れず、その結果として多くの消費者が詐欺および個人情報搾取の被害者になった多数の事例が近年発生している。さらに、多くの消費者は、読み物、ビデオ、エスコートサービス、および後で法執行官または他の官吏によって徹底的に調べられるかもしれない他の類似の商品およびサービスなどの商品およびサービスの購入とリンクされ得るかあるいは消費者が開示することを望まない情報であるかもしれない個人識別情報を伝えることに当然ながら反対することがある。

さらに、従前知られていたある支払い方法は小売業者にとっては相当の重荷を有する。個人情報搾取の被害者に対する潜在的責任を回避するために、大抵の小売業者は、クレジットカードおよびデビットカードの取引と関連して受け取られた個人金融情報のセキュリティを守るための手法を開発するために相当の経費を負担する。その上、多くのクレジットカード会社は、クレジットカードで行われた購入に対して消費者が異議を唱えたならばチャージバックペナルティを課す。また、多くの小売業者は、資金不足のために不渡りにされた小切手から生じる損失を被り続けている。
従って、通貨引き渡しなどの価値の移転を可能にすると共に匿名性を提供し、従前知られていた支払いシステムに関連するプライバシーおよび詐欺問題の多くを回避するシステムおよび方法を提供することが望ましい。

本発明に従うシステムおよび方法は、移転されるべき価値と関連付けられた実質的にランダムなコードを用いてユーザ間で価値を移転するために使用され得る。特に、信頼できる機関は、価値を蓄えるために使用され得るユーザ口座をユーザが作ることを可能にする。ユーザは価値を他のユーザに移転するために信頼できる機関からコードを請求することができ、コードは支払いコードおよび／またはインボイスコードを含むことができる。

例えば、第１のユーザは、指定された価値を第２のユーザに移転するために支払いコードを請求することができる。第１のユーザの口座がその指定された価値を含んでいるならば、信頼できる機関は、指定された価値と関連付けられた実質的にランダムな支払いコードを生成する。第１のユーザは、その後、支払いコードを第２のユーザに伝えることができ、第２のユーザは、その後、支払いコードを信頼できる機関に提示することができる。その支払いコードが有効ならば（例えば、それがユーザにより請求されたけれども支払いのためにまだ提示されていない）、信頼できる機関は指定された価値を第１のユーザの口座から引き落とし、指定された価値を第２のユーザの口座に振り込む。

あるいは、第１のユーザは、第２のユーザから指定された価値を受け取るためにインボイスコードを請求することができる。信頼できる機関は、指定された価値と関連付けられた実質的にランダムなインボイスコードを生成する。第１のユーザは、その後、インボイスコードを第２のユーザに伝えることができ、第２のユーザは、その後、インボイスコードを信頼できる機関に提示することができる。インボイスコードが有効であり（例えば、それがユーザによって請求されたけれども、まだ支払いのために提示されていない）、かつ第２のユーザの口座が指定された価値を含んでいるならば、信頼できる機関は指定された価値を第２のユーザの口座から引き落とし、指定された価値を第１のユーザの口座に振り込む。

セキュリティをさらに加えるために、リターンコードが使用され得る。特に、第１のユーザは、指定された価値を第２のユーザに移転するために支払いコードを請求することができ、リターンコードを請求することができる。第１のユーザの口座が指定された価値を含んでいれば、信頼できる機関は、指定された価値と関連付けられた第１および第２の実質的にランダムな支払いコードを生成し、第１の支払いコードを第１のユーザに伝える。第１のユーザは、その後、第１の支払いコードを第２のユーザに伝えることができ、第２のユーザは、その後、第１の支払いコードを信頼できる機関に提示することができる。第１の支払いコードが有効ならば（例えば、それがユーザによって請求されたけれども、支払いのためにまだ提示されていない）、信頼できる機関は第２の支払いコードを第２のユーザに伝える。第２のユーザは、その後、第２の支払いコードを第１のユーザに伝えることができ、第１のユーザは、その後、第２の支払いコードを信頼できる機関に提示することができる。第２の支払いコードが有効ならば（例えば、それがユーザによって請求されたけれども、まだ支払いのために提示されていない）、信頼できる機関は、指定された価値を第１のユーザの口座から引き落とし、指定された価値を第２のユーザの口座に振り込む。

あるいは、第１のユーザは、第２のユーザから指定された価値を受け取るためにインボイスコードを請求することができ、リターンコードを請求することができる。信頼できる機関は、指定された価値に関連付けられた第１および第２の実質的にランダムなインボイスコードを生成し、第１のインボイスコードを第１のユーザに伝える。第１のユーザは、その後、第１のインボイスコードを第２のユーザに伝えることができ、第２のユーザは、その後、第１のインボイスコードを信頼できる機関に提示することができる。第１のインボイスコードが有効ならば（例えば、それはユーザにより請求されたけれども、まだ支払いのために提示されていない）、信頼できる機関は第２のインボイスコードを第２のユーザに伝える。第２のユーザは、その後、第２のインボイスコードを第１のユーザに伝えることができ、第１のユーザは、その後、第２のインボイスコードを信頼できる機関に提示することができる。第２のインボイスコードが有効であり（例えば、それはユーザによって請求されたけれども、まだ支払いのために提示されていない）、かつ第２のユーザの口座が指定された価値を含んでいるならば、信頼できる機関は、指定された価値を第２のユーザの口座から引き落とし、指定された価値を第１のユーザの口座に振り込む。

本発明に従う代表的なシステムおよび方法は、ユーザにより所有されている価値を蓄えるために使用される価値ストアと、対応するユーザにそれぞれ関連付けられていて、対応するユーザにより所有されている蓄えられている価値のリストをそれぞれ有するユーザ口座を含む口座データベースとを含む信頼できる機関を含むかあるいは設け、信頼できる機関は、指定された価値に関連付けられるべきコードに対する請求を第１のユーザから受け取り、実質的にランダムなコードを生成し、生成されたコードを指定された価値に関連付け、生成されたコードを第１のユーザに伝え、生成されたコードを第２のユーザから受け取り、受け取られたコードが有効か否かを判定し、受け取られたコードが有効ならば、指定された価値の所有権を第１のユーザから第２のユーザに移転するために指定された価値を第１のユーザの口座から引き落として指定された価値を第２のユーザの口座に振り込むように適合されている。

本発明に従うシステムおよび方法は、さらに、ユーザにより所有されている価値を蓄えるために使用される価値ストアと、対応するユーザにそれぞれ関連付けられていて、対応するユーザにより所有されている蓄えられている価値のリストをそれぞれ有するユーザ口座を含む口座データベースとを含む信頼できる機関を含むかあるいは設け、信頼できる機関は、指定された価値に関連付けられるべきコードに対する請求を第１のユーザから受け取り、実質的にランダムなコードを生成し、生成されたコードを指定された価値に関連付け、生成されたコードを第１のユーザに伝え、生成されたコードを第２のユーザから受け取り、受け取られたコードが有効か否かを判定し、受け取られたコードが有効ならば、指定された価値の所有権を第２のユーザから第１のユーザに移転するために指定された価値を第２のユーザの口座から引き落として指定された価値を第１のユーザの口座に振り込むように適合されている。

本発明の特徴は、添付の図面と関連して考察される以下の詳細な説明からより明瞭に理解することができ、添付の図面において同じ参照数字は全体において同じ要素を示す。

本発明に従う代表的なシステムのブロック図である。 本発明に従う代表的な信頼できる機関のブロック図である。 本発明に従う代表的なコードジェネレータのブロック図である。 本発明に従う代表的な口座データベースの図である。 本発明に従う代表的なコードデータベースの図である。 本発明に従う代表的なユーザインターフェイスのサインオンページの図である。 本発明に従う代表的なユーザインターフェイスのホームページの図である。 本発明に従う代表的なユーザインターフェイスのリンク外部口座ページの図である。 本発明に従う代表的なユーザインターフェイスのリンク外部口座ページの図である。 本発明に従う代表的なユーザインターフェイスのリンク外部口座ページの図である。 本発明に従う代表的なユーザインターフェイスのリンク外部口座ページの図である。 本発明に従う代表的なユーザインターフェイスのリンク外部口座ページの図である。 本発明に従う代表的なユーザインターフェイスの外部口座移転ページの図である。 本発明に従う代表的なユーザインターフェイスの外部口座移転ページの図である。 本発明に従う代表的なユーザインターフェイスの外部口座移転ページの図である。 本発明に従う代表的なユーザインターフェイスの外部口座移転ページの図である。 本発明に従う代表的なユーザインターフェイスの外部口座移転ページの図である。 本発明に従う外部口座、信頼できる機関およびユーザの間での代表的な価値の移転の図である。 本発明に従う代表的な口座データベースの他の図である。 本発明に従う代表的な口座データベースの他の図である。 本発明に従う代表的な口座データベースの他の図である。 本発明に従う代表的な口座データベースの他の図である。 本発明に従う代表的なユーザインターフェイスのホームページの他の図である。 本発明に従う代表的なユーザインターフェイス口座残高ページの図である。 本発明に従う通貨価値と関連付けられた支払いコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従う通貨価値と関連付けられた支払いコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従う通貨価値と関連付けられた支払いコードを請求するための代表的なユーザインターフェイスのページの図である。 図１５Ａ〜１５Ｃに示されている取引の結果として生じる本発明に従う代表的な口座データベースの図である。 本発明に従う通貨価値と関連付けられたインボイスコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従う通貨価値と関連付けられたインボイスコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従う通貨価値と関連付けられたインボイスコードを請求するための代表的なユーザインターフェイスのページの図である。 図１７Ａ〜１７Ｃに示されている取引の結果として生じる本発明に従う代表的な口座データベースの図である。 本発明に従うサービス価値と関連付けられたリターン支払いコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従うサービス価値と関連付けられたリターン支払いコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従うサービス価値と関連付けられたリターン支払いコードを請求するための代表的なユーザインターフェイスのページの図である。 図１９Ａ〜１９Ｃに示されている取引の結果として生じる本発明に従う代表的な口座データベースの図である。 本発明に従う商品価値と関連付けられたリターンインボイスコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従う商品価値と関連付けられたリターンインボイスコードを請求するための代表的なユーザインターフェイスのページの図である。 本発明に従う商品価値と関連付けられたリターンインボイスコードを請求するための代表的なユーザインターフェイスのページの図である。 図２１Ａ〜２１Ｃに示されている取引の結果として生じる本発明に従う代表的な口座データベースの図である。 図１５Ａ〜１５Ｃ、１７Ａ〜１７Ｃ、１９Ａ〜１９Ｃおよび２１Ａ〜２１Ｃの取引の結果として生じる代表的なコードデータベースの図である。 本発明に従う代表的なユーザインターフェイスのホームページの他の図である。 本発明に従う支払いコードを提示するための代表的なユーザインターフェイスのページの図である。 本発明に従う支払いコードを提示するための代表的なユーザインターフェイスのページの図である。 図２５Ａ〜２５Ｂの取引の結果として生じる代表的な口座データベースの図である。 本発明に従うインボイスコードを提示するための代表的なユーザインターフェイスのページの図である。 本発明に従うインボイスコードを提示するための代表的なユーザインターフェイスのページの図である。 本発明に従うインボイスコードを提示するための代表的なユーザインターフェイスのページの図である。 図２７Ａ〜２７Ｃの取引の結果として生じる代表的な口座データベースの図である。 本発明に従う第１のリターン支払いコードを提示するための代表的なユーザインターフェイスのページの図である。 本発明に従う第１のリターン支払いコードを提示するための代表的なユーザインターフェイスのページの図である。 図２９Ａ〜２９Ｂの取引の結果として生じる代表的な口座データベースの図である。 本発明に従う第２のリターン支払いコードを提示するための代表的なユーザインターフェイスのページの図である。 図３１の取引の結果として生じる代表的な口座データベースの図である。 本発明に従う第１のリターンインボイスコードを提示するための代表的なユーザインターフェイスのページの図である。 本発明に従う第１のリターンインボイスコードを提示するための代表的なユーザインターフェイスのページの図である。 図３３Ａ〜３３Ｂの取引の結果として生じる代表的な口座データベースの図である。 本発明に従う第２のリターンインボイスコードを提示するための代表的なユーザインターフェイスのページの図である。 図３５の取引の結果として生じる代表的な口座データベースの図である。 本発明に従う代表的な支払いコード転送の図である。 本発明に従う代表的なインボイスコード転送の図である。 本発明に従う代表的なリターン支払いコード転送の図である。 本発明に従う代表的なリターンインボイスコード転送の図である。 本発明に従う支払いコード転送のために信頼できる機関によって実行される代表的なプロセスの図である。 本発明に従うインボイスコード転送のために信頼できる機関によって実行される代表的なプロセスの図である。 本発明に従うリターン支払いコード転送のために信頼できる機関によって実行される代表的なプロセスの図である。 本発明に従うリターン支払いコード転送のために信頼できる機関によって実行される代表的なプロセスの図である。 本発明に従うリターンインボイスコード転送のために信頼できる機関によって実行される代表的なプロセスの図である。 本発明に従うリターンインボイスコード転送のために信頼できる機関によって実行される代表的なプロセスの図である。

本発明に従うシステムおよび方法は、移転されるべき価値に関連付けられた実質的にランダムなコードを用いてユーザ間で価値を移転するために使用され得る。
ここで図１を参照すると、本発明に従う代表的な価値移転システム１０が記述されている。価値移転システム１０は、外部機関１４およびユーザ１６に接続された信頼できる機関１２を含む。信頼できる機関１２は、ユーザ１６が価値を蓄えるために使える個人用のユーザ口座（「ＴＡ口座」）を作ることを可能にする。ユーザ１６は、自分のＴＡ口座を外部機関１４に存するユーザの口座（「外部口座」）とリンクさせ、自分の外部口座とＴＡ口座との間で価値を移転し、信頼できる機関１２によって生成された、移転されるべき価値に関連付けられている転送可能なコード（「コード」）を用いて、他のユーザ１６に価値を移転することができる。

特に、ユーザ１６は、ユーザのＴＡ口座間で価値を移転するために信頼できる機関１２から支払いコード（「Ｐコード」：Payment Code）および／またはインボイスコード（「Ｉコード」：Invoice Code）を請求することができる。具体的には、コードは、第１のユーザ１６（本願明細書において「支払人」と称される）のＴＡ口座から第２のユーザ１６（本願明細書において「受取人」と称される）のＴＡ口座に価値を移転するために使用され得る。例えば、支払人は、指定された価値を受取人に移転するために信頼できる機関からＰコードを請求することができる。支払人はＰコードを受取人に伝え、受取人はＰコードを信頼できる機関１２に提示する。Ｐコードが有効ならば（例えば、それが前に支払いのために提示されていなかった）、信頼できる機関１２は、指定された価値を支払人のＴＡ口座から引き落とし、指定された価値を受取人のＴＡ口座に振り込む。

あるいは、受取人は、支払人から指定された価値を受け取るためにＩコードを請求することができる。受取人はＩコードを支払人に伝え、支払人はＩコードを信頼できる機関１２に提示する。Ｉコードが有効ならば（例えば、それが前に支払いのために提示されていなかった）、信頼できる機関１２は指定された価値を支払人のＴＡ口座から引き落とし、指定された価値を受取人のＴＡ口座に振り込む。セキュリティをさらに加えるために、支払人はリターン支払いコード（「ＲＰコード」：Return Payment Code ）を請求することができ、受取人はリターンインボイスコード（「ＲＩコード」：Return Invoice Code ）を請求することができる。種々のコードタイプの使用に関するさらなる詳細事項を以下に記述する。

信頼できる機関１２を、伝統的銀行、貯蓄貸付、信用金庫、あるいは他の類似の伝統的金融機関などの金融機関によって実現することもできるし、あるいは個人、法人、非営利エンティティ、団体、政府機関、または他の類似の人もしくは機関によって実現することもできる。外部機関１４は、金融機関、エスクロウエージェント、サービスプロバイダ、あるいは他の類似の機関またはそのような機関の組み合わせであり得る。ユーザ１６は、個人、グループ、団体、小売業者、売主、供給業者、あるいは他の類似のユーザまたはそのようなユーザの組み合わせであり得る。

外部機関１４およびユーザ１６は、ローカルエリアネットワーク、ワイドエリアネットワーク、一般加入電話網、セルラーネットワーク、ケーブルテレビジョンネットワーク、衛星ネットワーク、無線ネットワーク、インターネット、またはそのようなネットワークの組み合わせを介して信頼できる機関１２と通信することができる。外部機関１４は第１のネットワークを介して信頼できる機関１２と通信することができ、ユーザ１６は、第１のネットワークと同じであるかあるいは異なる第２のネットワークを介して信頼できる機関と通信することができる。簡略化のために、残りの記述は、インターネットを介しての信頼できる機関１２と外部機関１４およびユーザ１６との間の通信に言及する。そのような通信は、好ましくは、ＳＳＬ暗号化セキュアネットワーク接続または他の類似のセキュア接続などのセキュア接続を介する。

信頼できる機関
ここで図２を参照すると、信頼できる機関１２の代表的な実施形態が記述されている。信頼できる機関１２は、コントローラ２０と、ユーザインターフェイス２２と、外部機関インターフェイス２４と、口座データベース２６と、コードデータベース２８と、価値ストア３０とを含む。コントローラ２０は、パーソナルコンピュータ、ラップトップコンピュータ、メインフレームコンピュータ、コンピュータサーバ、ハンドヘルドコンピュータ、または他の類似のコンピュータであり得る。コントローラ２０は、本発明に従う方法を実行するためのコンピュータにより実行できる命令を有するコンピュータ可読媒体（図示せず）を含むことができる。コントローラ２０は、ユーザ１６により請求される、本発明に従ってユーザのＴＡ口座間で移転され得る価値と関連付けられるコードを生成するためのコードジェネレータ３２を含むことができる。

以下でより詳しく記述するように、ユーザインターフェイス２２は、ユーザ１６がＴＡ口座を作り、ＴＡ口座を外部機関１４に存する外部口座にリンクさせ、ＴＡ口座と外部口座との間で価値を移転し、指定された価値と関連付けられたコードを用いて他のユーザ１６に価値を移転することを可能にする。外部機関インターフェイス２４は、信頼できる機関１２がＴＡ口座と外部機関１４に存する外部口座との間で価値を移転することを可能にする。

口座データベース２６はＴＡ口座と関連付けられたデータを記憶し、コードデータベース２８は、コードジェネレータ３２により生成された、ユーザのＴＡ口座間で移転され得る価値と関連付けられたコードに関連するデータを記憶する。口座データベース２６およびコードデータベース２８は、ハードドライブ、フロッピードライブ、光ディスク、磁気メモリ、ランダムアクセスメモリ、フラッシュメモリ、あるいは他の類似の記憶装置などのコンピュータメモリ（図示せず）に格納され得る。口座データベース２６およびコードデータベース２８を、単一の記憶装置あるいは複数の記憶装置に格納することができ、単一のデータベースあるいは複数のデータベースを含むことができる。以下でより詳しく記述するように、価値ストア３０は、価値、価値の証拠、あるいはＴＡ口座へまたはＴＡ口座から移転される価値の所有権の証拠を蓄える。価値ストア３０は、金庫室、金融口座、電子データベース、倉庫、あるいは価値の他の類似の貯蔵所またはそのような貯蔵所の組み合わせであり得る。

信頼できる機関１２の種々のコンポーネントは結合され得る。例えば、コントローラ２０は、ユーザインターフェイス２２および／または外部機関インターフェイス２４を実現するためのハードウェアおよび／またはソフトウェアを含むことができる。さらに、信頼できる機関１２の１つ以上のコンポーネントを、単一の位置に置くこともできるし、あるいは複数の位置に分散することもできる。例えば、コントローラ２０を第１の地理的領域に分散された複数のサーバコンピュータにおいて実現することができ、価値ストア３０を第２の地理的領域に分散された複数の価値貯蔵所において実現することができる。第１および第２の地理的領域は同じであることもできるし、あるいは互いに異なることもできる。

ここで図３を参照すると、代表的なコードジェネレータ３２が記述されている。コードジェネレータ３２は、ランダムキャラクタジェネレータ３４を含み、任意にセキュリティレベルモディファイヤ３６とコードコンバイナ３８とを含むことができる。ランダムキャラクタジェネレータ３４は、当該技術分野において知られている在来のハードウェアおよび／またはソフトウェア乱数発生器を含むことができる。コントローラ２０の指令で、ランダムキャラクタジェネレータ３４は、数字、文字、特殊キャラクタ（例えば、＊、％、＃、＋、など）あるいは他の類似のキャラクタなどの、所定数のキャラクタを含むことのできるランダムシステムコードＣ_S を生成する。システムコードＣ_S は、コードを請求したユーザ１６、あるいはシステムコードＣ_S と関連付けられた価値を特定するために使用され得るいかなる情報も含んでいなくてよい。キャラクタを生成するほかに、あるいはその代わりに、コードジェネレータ３２はバーコード、オーディオコード、バイナリコード、点字コード、セマフォーフラグコード、あるいは他の類似のコードを含むシステムコードＣ_S を生成することができることが当業者であれば理解できるはずである。

コントローラ２０は、生成されるシステムコードＣ_S のセキュリティを制御するべくシステムコードＣ_S のキャラクタの数または他の類似のパラメータを制御するために任意のセキュリティレベルモディファイヤ３６を使用することができる。例えば、悪いユーザがコードを推測し得る確率を小さくするためにシステムコードＣ_S の長さを大きくすることができる。システムコードＣ_S を、コードとして直接出力することもできるし、あるいは任意のコードコンバイナ３８を用いてユーザ指定されたコードＣ_U と結合することもできる。コードコンバイナ３８は、Ｃ_S およびＣ_U キャラクタを連結することができ、Ｃ_S およびＣ_U キャラクタを散在させることができ、あるいはＣ_S およびＣ_U キャラクタのもっと複雑な結合および／または操作を行うことができる。

図２を再び参照すると、ユーザインターフェイス２２は、ユーザ１６がＴＡ口座を作り、ＴＡ口座を外部機関１４に存する口座とリンクさせ、ＴＡ口座と外部口座との間で価値を移転し、指定された価値と関連付けられたコードを用いて価値を他のユーザ１６に移転することを可能にするハードウェアおよび／またはソフトウェアを含むことができる。例えば、ユーザインターフェイス２２は、パーソナルコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ウェブ対応携帯電話、および他の類似のコンピュータ装置上で動作するウェブブラウザを介してユーザ１６によりアクセスされ得るウェブページをホストするウェブサーバを含むことができる。さらに、あるいは代わりに、ユーザインターフェイス２２は、前述したように、ユーザ１６がＴＡ口座にアクセスすることを可能にする電話インターフェイス、電子メールインターフェイス、テキストメッセージインターフェイス、ヒューマンインターフェイスまたは他の類似インターフェイスを含むことができる。簡略化のために、ユーザインターフェイス２２は、残りの記述においてウェブインターフェイスとして記述される。

外部機関インターフェイス２４は、信頼できる機関１２がＴＡ口座と外部口座との間で価値を移転することを可能にするハードウェアおよび／またはソフトウェアを含むことができる。例えば、外部機関インターフェイス２４は、電子資金移転プロトコル、電信送金プロトコルあるいは他の類似の資金移転プロトコルを実行するためのハードウェアおよび／またはソフトウェアを含むことができる。さらに、あるいは代わりに、外部機関インターフェイス２４はＴＡ口座と外部口座との間で非通貨価値を移転するために使用され得るハードウェアおよび／またはソフトウェアを含むことができる。例えば、外部機関インターフェイス２４は、郵便サービス、クーリエサービス（例えば、ＵＰＳ、ＦＥＤＥＸ、ＤＨＬ）、あるいは他の類似の商品配送サービスを介して商品出荷を開始するためのハードウェアおよび／またはソフトウェアを含むことができる。さらに、あるいは代わりに、外部機関インターフェイス２４はＴＡ口座と外部口座との間での価値の移転を可能にする電話インターフェイス、電子メールインターフェイス、テキストメッセージインターフェイス、ヒューマンインターフェイスあるいは他の類似のインターフェイスを含むことができる。

ここで図４を参照すると、代表的な口座データベース２６が記述されている。口座データベース２６は、ユーザのＴＡ口座と関連付けられているデータを含む。例えば、口座データベース２６は、各ＴＡ口座と関連付けられているユーザ名を記憶するユーザ名フィールド４０と、ＴＡ口座セットアッププロセス中にユーザ１６により選択された各ＴＡ口座と関連付けられたＰＩＮまたは他の類似セキュリティコードを記憶する個人識別番号（「ＰＩＮ」:Personal Identification Number ）フィールド４２と、各ＴＡ口座内の価値に関する情報を記憶する価値フィールド４４と、各ＴＡ口座のために請求されているオープンコードを記憶するオープンコードフィールド４６と、各ＴＡ口座とリンクされた外部口座に関する情報を記憶するリンク外部口座フィールド４８とを含む。当業者であれば、本発明に従う口座データベース２６が、図４に示されている代表的なフィールドより多い、より少ない、および／またはそれらと異なるフィールドを含み得るということが理解できるはずである。

ＴＡ口座に蓄えられている価値は、通貨、商品、および／またはサービスのどれでも、および／または他の類似の価値を含むことができる。従って、口座データベース２６は、通貨５０、商品５２およびサービス５４のための価値サブフィールドを含むことができる。各価値サブフィールドは指示子および量を含む。図に示されている実施形態では、通貨、商品およびサービスのための価値指示子は、それぞれ、「単位」、「名前」、および「説明」である。通貨５０は単位５６および量５８のためのサブフィールドを含むことができ、商品５２は名前６０および量６２のためのサブフィールドを含むことができ、サービス５４は説明６４および量６６のためのサブフィールドを含むことができる。同様に、外部口座４８は、外部口座と関連付けられている名前６８ならびに口座番号およびルーティング／セキュリティ番号７０のためのサブフィールドを含むことができる。

図４に示されている代表的な口座データベース２６は、対応するユーザ名ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔ、ｈｏｂｂｅｓ＠ｇｍａｉｌ．ｃｏｍ、ｓｊ＠ｓｊｏｎｅｓ．ｃｏｍ、およびｍｇｒ＠ｈｏｌｅｆｄｓ．ｃｏｍを有する４つの別々のＴＡ口座と関連付けられたデータを含む。ユーザ名ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔは、（１）関連付けられたＰＩＮ「ｓＨ０ｅ＄」、（２）関連付けられた価値、（ａ）８０，０００ユーロ、（ｂ）１つのマックブックエアーラップトップコンピュータ、（ｃ）２足のマノロブラーニクスリングバックシューズ、および（ｄ）３回の温泉浴のためのクレジット、ならびに（３）（ａ）アメリゴ銀行、（ｂ）シティバンクエット、（ｃ）サザブーズ競売、（ｄ）ジェファーソンズドライクリーニング、および（ｅ）ブリススパに存するリンク外部口座を有する。対照的に、ユーザ名ｍｇｒ＠ｈｏｌｅｆｄｓ．ｃｏｍは、（１）関連付けられたＰＩＮ「ｍｏｎｅｅ」、（２）１，０００米ドルの関連付けられた価値、および（３）ウォールズファーゴ銀行に存するリンク外部口座を有する。

ここで図５を参照すると、代表的なコードデータベース２８が記述されている。コードデータベース２８は「オープン」コード、すなわち、ユーザ１６によって請求されているけれども、支払人のＴＡ口座から受取人のＴＡ口座に価値を移転するために信頼できる機関１２にまだ首尾よく提示されていないコードと関連付けられたデータを含む。例えば、コードデータベース２８はオープンコードを記憶するコードフィールド７２を含み、リターンコードフィールド７４は対応するリターンコードを記憶する。以下でより詳しく記述するように、コードを請求するとき、ユーザ１６は、意図された受取人および／またはそのコードについての有効期限を指定することができる。従って、意図された受取人フィールド７６は、そのコードと関連付けられている指定された意図された受取人を特定する情報を記憶し、有効期限フィールド７８は、そのコードと関連付けられている指定された有効期限に関する情報を記憶する。タイプフィールド８０は、コードのタイプを特定するための記述子を記憶する（例えば、Ｐコードのための「Ｐ」、Ｉコードのための「Ｉ」、ＲＰコードのための「ＲＰ」、およびＲＩコードのための「ＲＩ」）。当業者であれば、コードのタイプを特定するために他の類似の記述子が使用され得ることが理解できるはずである。

コードデータベース２８は価値フィールド８２も含み、そのコードと関連付けられている価値を記述する情報を記憶するために使用され得る。価値フィールド８２は、通貨８４、商品８６およびサービス８８のための価値サブフィールドを含むことができる。さらに、通貨フィールド８４は単位９０および量９２のためのサブフィールドを含むことができ、商品サブフィールド８６は名前９４および量９６のためのサブフィールドを含むことができ、サービスサブフィールド８８は説明９８および量１００のためのサブフィールドを含むことができる。

図５に示されている代表的なコードデータベース２８は、６個のコード、すなわち（１）２００９年１月１５日の有効期限と、１０９，７８０円の関連する値とを有するＰコードであるＣＶ５４Ｈ９と、（２）ａｉｄａｎ＠ｍｓｎ．ｎｅｔという意図された受取人と、１個の４８”ウルフレンジという関連する価値とを有するＩコードであるＢ６ＥＲ５Ｇと、１０回の芝生管理処理という関連する価値を有する第１および第２のＲＰコードである（３）ＴＴ６４３Ｎおよび（４）Ｆ４ＷＱ９９と、５０米ドルおよび１個のアイポッドナノという関連する価値を有する第１および第２のＲＩコードである（５）ＲＹ２２６Ｂおよび（６）７ＺＸＬＧ８とを含む。従って、当業者であれば、コードが価値の１つ以上のカテゴリーと、あるいは１つのカテゴリーの中の価値の１つ以上のタイプと関連付けられ得るということが理解できるはずである。

ユーザインターフェイス
図２に関して前に記述したように、ユーザインターフェイス２２は、ユーザ１６がＴＡ口座を作り、ＴＡ口座を外部機関１４に存する口座とリンクさせ、ＴＡ口座と外部口座との間で価値を移転し、信頼できる機関１２により生成されたコードを用いて価値を他のユーザ１６に移転するためにコードを請求し提示することを可能にするウェブインターフェイスであり得る。ここで、価値の種々の代表的な形の各々についてこれらのアクティビティーの各々を具体的に説明する代表的なウェブインターフェイスを記述する。

ユーザ１６は、インターネットエクスプローラ、ファイアフォックス、サファリ、オペラ、あるいは他の類似ウェブブラウザなどの在来のウェブブラウザを介してウェブインターフェイス２２にアクセスすることができる。ここで図６を参照すると、代表的なユーザサインオンページが記述されている。代表的なサインオンページ１１０はユーザログインセクション１１２を含み、これは、ユーザ識別情報（例えば、ユーザ名、口座番号など）および検証情報（例えば、パスワード）を入力するためのデータ入力フィールドを含む。さらに、サインオンページ１１０は、ユーザ１６がＴＡ口座を作ることを可能にするサインアップセクション１１４を含むことができる。口座セットアッププロセスの一部として、ユーザ１６はＰＩＮまたは他の類似セキュリティコードを選択するように要求され得る。当業者であれば、サインオンページ１１０が、図６に示されているものよりも多くのあるいは少ない情報を含み得ること、ならびに、追加の識別情報（例えば、トークン生成されたパスワード、あるいは他の類似セキュリティ情報）を提供するようにユーザ１６に要求し得ることが理解できるはずである。

ユーザ１６がシステムに首尾よくサインインした後、ウェブインターフェイス２２は、ユーザ「ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔ」のための図７に示されている代表的なユーザホームページ１２０などのユーザホームページを表示することができる。代表的なホームページ１２０は、ナビゲーションペイン１２２と、「最近の取引」テーブル１２４と、「オープンコード」テーブル１２６とを含む。ナビゲーションペイン１２２は、ＴＡ口座管理アクティビティ１２８、外部口座管理アクティビティ１３０、およびユーザ情報管理アクティビティ１３２に関連付けられたウェブページへのハイパーリンクを含む。外部口座管理アクティビティ１３０に関係するハイパーリンクは、リンク外部口座をリストし、ＴＡ口座を外部口座にリンクし、ＴＡ口座と外部口座との間で価値を移転するために使用され得る。ナビゲーションペイン１２２が、図７に示されている代表的なハイパーリンクより多い、より少ない、かつ／または異なるハイパーリンクを含み得るということが当業者であれば理解できるはずである。

通貨価値について、ユーザ１６は、現金支払い、為替、小切手、クレジットカード支払い、銀行間為替、または類似の方法、あるいはそのような方法の組み合わせを通して彼女のＴＡ口座に資金を供給することができる。当業者であれば、各資金供給方法が、その方法に特有の付加的なセキュリティ処置を必要とし得ることが理解できるはずである。例えば、ユーザ１６は、銀行口座をリンクすること、彼女がその口座を管理していることを証明するためにマイクロデポジットを確認すること、および／または任意の数の付加的な形の身元確認を提供するように要求され得る。そのようなセキュリティ処置は、当業者であれば理解できるはずであるように、信頼できる機関１２の枠組みの中で実行され得る。

ここで図８を参照すると、ナビゲーションペイン１２２の中の「外部口座をリストする」を選択することにより、ユーザのリンク外部口座のリスト１４２を含む「リンク外部口座」ウェブページ１４０が表示される。図に示されている例では、ユーザｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔは彼女のＴＡ口座を２つの銀行（アメリゴ銀行およびシティバンクエット）、競売場（サザブーズ）および２つのサービスプロバイダ（ブリススパおよびジェファーソンズドライクリーニング）に存する外部口座とリンクしている。

ナビゲーションペイン１２２の中の「外部口座をリンクする」ハイパーリンクは、ユーザのＴＡ口座を彼女の外部口座にリンクするために使用され得る。例えば、図９は、ＴＡ口座を外部口座にリンクするために使用され得る代表的なウェブページを示す。図９Ａでは、代表的な「外部口座をリンクする」ウェブページ１５０は、金融機関、エスクロウエージェント、およびサービスプロバイダなどの外部口座タイプのドロップダウンリスト１５２を含む。本発明に従うシステムが３つより多いかあるいは少ない異なる口座タイプを使用し得ること、および図９Ａに示されている代表的な口座タイプと異なる口座タイプを使用し得るということが当業者であれば理解できるはずである。

図９Ｂに示されているように、ユーザ１６がドロップダウンリスト１５２から金融機関口座タイプを選択すると、ウェブページ１５０ａは、その口座がＴＡ口座にリンクされ得る種々の金融機関の名前を含む金融機関名ドロップダウンリスト１５４を表示することができる。代表的な金融機関は、銀行、信用組合、投資信託、割引仲買、退職年金制度および他の類似の金融機関あるいはそのような機関の組み合わせを含み得る。ウェブページ１５０ａは、指定された金融機関に存するユーザの口座と関連付けられた口座番号１５６およびルーティング番号１５８を提供するためのデータ入力フィールドをも表示することができる。当業者であれば、口座番号１５６およびルーティング番号１５８とは異なる情報および／またはその他の情報のためのデータ入力フィールドが設けられ得るということが理解できるはずである。さらに、その代わりに、ウェブページ１５０ａは金融機関名ドロップダウンリスト１５２を使わずに、ユーザ１６が彼女のＴＡ口座にリンクする金融機関を指定できる他の何らかの形のデータ入力フィールドを提供することができるということが当業者であれば理解できるはずである。

図９Ｃに示されているように、ユーザ１６がドロップダウンリスト１５２からエスクロウエージェント口座タイプを選択すると、ウェブページ１５０ｂは、その口座がＴＡ口座とリンクされ得る種々のエスクロウエージェントの名前を含むエスクロウエージェント名ドロップダウンリスト１５４を表示することができる。代表的なエスクロウエージェントは、競売場、公認エスクロウエージェント、名義会社および他の類似のエスクロウエージェントあるいはそのようなエージェントの組み合わせを含むことができる。ウェブページ１５０ｂは、指定されたエスクロウエージェントに存するユーザの口座と関連付けられた口座番号１５６およびセキュリティコード１５８を提供するためのデータ入力フィールドも表示することができる。当業者であれば、口座番号１５６およびセキュリティコード１５８とは異なる情報および／またはその他の情報のためにデータ入力フィールドが設けられ得るということが理解できるはずである。さらに、ウェブページ１５０ｂは代わりにエスクロウエージェント名ドロップダウンリスト１５４を使わずに、ユーザ１６がエスクロウエージェント機関を自分のＴＡ口座にリンクするように指定できる他の何らかの形のデータ入力フィールドを提供し得るということが当業者であれば理解できるはずである。

図９Ｄに示されているように、ユーザ１６がドロップダウンリスト１５２からサービスプロバイダ口座タイプを選択すると、ウェブページ１５０ｃは、その口座がＴＡ口座にリンクされ得る種々のサービスプロバイダの名前を含むサービスプロバイダ名ドロップダウンリスト１５４を表示することができる。代表的なサービスプロバイダは、ドライクリーニング店、家政婦、庭師、自動車整備工、スパ、水道業者および他の類似のサービスプロバイダあるいはそのようなプロバイダの組み合わせを含み得る。ウェブページ１５０ｃは、指定されたサービスプロバイダに存するユーザの口座と関連付けられた口座番号１５６を提供するためのデータ入力フィールドを表示することもできる。当業者であれば、口座番号１５６とは異なる情報および／またはその他の情報のためにデータ入力フィールドが設けられ得るということが理解できるはずである。さらに、ウェブページ１５０ｃは代わりにサービスプロバイダ名ドロップダウンリスト１５４を使わずに、ユーザ１６がサービスプロバイダを彼女のＴＡ口座にリンクするように指定できる他の何らかの形のデータ入力フィールドを提供し得るということが当業者であれば理解できるはずである。

１つ以上の外部口座をＴＡ口座にリンクした後、ユーザ１６はユーザの外部口座と彼女のＴＡ口座との間で価値を移転するためにナビゲーションペイン１２２の中の「移転する」ハイパーリンクを使用することができる。例えば、図１０Ａ〜１０Ｅは、ユーザｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔが彼女の外部口座と彼女のＴＡ口座との間で価値を移転するために使用し得る代表的なウェブページを示す。図１０Ａは、価値がそこから移転されるところの口座を指定するための「から（Ｆｒｏｍ）」ドロップダウンメニュー１６２と、価値がそこへ移転されるところの口座を指定するための「へ（Ｔｏ）」ドロップダウンメニュー１６４とを含む代表的な「外部口座移転」ウェブページ１６０を示す。ウェブページ１６０は、移転されるべき価値を指定するための説明データ入力フィールド１６６および量データ入力フィールド１６８も含む。さらに、ウェブページ１６０は、その移転についてのテキスト説明を入力するための任意のメモデータ入力フィールド１７０と、ユーザ１６がＴＡ口座セットアッププロセス中に作ったＰＩＮまたは他のセキュリティコードを明示するためのＰＩＮデータ入力フィールド１７２とを含むことができる。

図１０Ｂは、通貨価値がユーザのリンク銀行口座から彼女のＴＡ口座へ移転される代表的な外部口座移転ウェブページ１６０ａを示す。特に、ドロップダウンメニュー１６２は指定された価値がユーザのアメリゴ銀行口座から移転されることを示し、ドロップダウンメニュー１６４はその指定された価値がユーザのＴＡ口座へ移転されることを示す。この代表的な実施形態では、ドロップダウンメニュー１６２または１６４で指定される外部機関が価値が通貨で指定される金融機関であるならば、外部口座移転ウェブページ１６０ａは、通貨単位を指定するための単位データ入力フィールド１６６と、その指定された通貨の量を指定するための量データ入力フィールド１６８とを含む。図に示されている例では、ユーザｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔは、彼女のアメリゴ銀行口座から彼女のＴＡ口座への１，２４７米ドルの移転を指定している。ユーザ１６が提示ボタンをクリックすると、指定された価値はユーザの選択された外部口座から価値ストア３０へ移転される。

特に、図２および４を再び参照すると、外部機関インターフェイス２４は、口座データベース２６から（コントローラ２０を介して）ユーザのＴＡ口座および指定された外部口座と関連付けられた口座情報を得る。図１０Ｂに示されている例では、外部機関インターフェイス２４は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔのアメリゴ銀行口座の口座番号（２０３７７８２）およびルーティング番号（１２２０００６６１）を口座データベース２６から得る。電子資金移転プロトコルあるいは他の類似プロトコルを用いて、外部機関インターフェイス２４は、その後、ユーザのアメリゴ銀行口座から価値ストア３０への指定された価値（すなわち、１，２４７米ドル）の移転を開始することができる。これは、外部機関１４₁ （アメリゴ銀行）から信頼できる機関１２への移転１８０として図１１に概略的に示されている。

指定された価値が価値ストア３０に受け取られていると信頼できる機関１２が判定すると、口座データベース２６はユーザのＴＡ口座の中の高められた価値を反映するように更新される。任意に、信頼できる機関１２は、その価値が首尾良く移転されるであろうと期待して、ユーザのＴＡ口座に外部口座から移転された価値を「フロート(float)」することができる。図１２Ａに示されているように、口座データベース２６は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔの通貨価値の１，２４７米ドルの増加を反映するように更新されている。

図１０Ｃは、通貨価値がユーザのＴＡ口座から彼女のリンク外部口座のうちの１つへ移転される代表的な外部口座移転ウェブページ１６０ｂを示す。特に、ドロップダウンメニュー１６２は、指定された価値がユーザのＴＡ口座から移転されることを示し、ドロップダウンメニュー１６４は、その指定された価値がユーザのリンク外部口座のうちの１つへ移転されることを示す。図に示されている例では、ユーザｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔは、彼女のＴＡ口座から彼女のリンクされているシティバンクエット口座への５５．７５米ドルの移転を指定している。ユーザ１６が提示ボタンをクリックすると、指定された価値は価値ストア３０から選択されたリンク外部口座へ移転される。さらに、口座データベース２６は、ユーザのＴＡ口座の中の減少した価値を反映するように更新される。

特に、図２および４を再び参照すると、外部機関インターフェイス２４は、口座データベース２６から（コントローラ２０を介して）ユーザの選択された外部口座と関連付けられている口座情報を得る。図１０Ｃに示されている例では、外部機関インターフェイス２４は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔのシティバンクエット口座の口座番号（０１８８６０５２２７８）およびルーティング番号（０２１００００８９）を口座データベース２６から得る。電子資金移転プロトコルまたは他の類似プロトコルを用いて、外部機関インターフェイス２４は、その後、指定された価値（すなわち、５５．７５米ドル）の価値ストア３０からユーザのシティバンクエット口座への移転を開始することができる。これは、信頼できる機関１２から外部機関１４₂ （シティバンクエット）への移転１８２として図１１に概略的に示されている。さらに、図１２Ｂに示されているように、口座データベース２６は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔの通貨価値の５５．７５米ドルの減少を反映するように更新されている。

図１０Ｄは、商品価値がユーザのリンク外部口座から彼女のＴＡ口座へ移転される代表的な外部口座移転ウェブページ１６０ｃを示す。特に、ドロップダウンメニュー１６２は指定された価値がユーザの外部口座のうちの１つから移転されることを示し、ドロップダウンメニュー１６４は、その指定された価値がユーザのＴＡ口座へ移転されることを示す。図に示されている例では、ユーザｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔは彼女のリンクされているサザブーズの口座から彼女のＴＡ口座への１個のローレックスオイスターパーペチュアル時計の移転を指定している。ユーザ１６が提示ボタンをクリックすると、その指定された価値はユーザのリンク外部口座から価値ストア３０へ移転される。

特に、図２および４を再び参照すると、外部機関インターフェイス２４は、口座データベース２６から（コントローラ２０を介して）ユーザの選択された外部口座と関連付けられている口座情報を得る。図１０Ｄに示されている例では、外部機関インターフェイス２４は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔのサザブーズの口座の口座番号（５ＡｙＦ９８）およびセキュリティ番号（ｓｏｔｈｅ００１）を口座データベース２６から得る。商品出荷プロトコルまたは他の類似プロトコルを用いて、外部機関インターフェイス２４は、その後、指定された価値（すなわち、１個のローレックスオイスターパーペチュアル時計）のユーザのサザブーズの口座から価値ストア３０への移転を開始することができる。これは、外部機関１４₃ （サザブーズ）から信頼できる機関１２への移転１８４として図１１に概略的に示されている。

指定された価値が価値ストア３０に受け取られたと信頼できる機関１２が判定すると、口座データベース２６は、ユーザのＴＡ口座に存する高められた価値を反映するように更新される。従って、図１２Ｃに示されているように、口座データベース２６は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔの商品価値の、１個のローレックスオイスターパーペチュアル時計だけの増大を反映するように更新される。

当業者であれば、商品価値移転が外部機関１４と価値ストア３０との間で商品を物理的に移転することを必要としないことが理解できるはずである。その代わりに、商品は外部機関１４に留まることができ、価値の所有権の証拠が外部機関１４から信頼できる機関１２へ移転されることができる。そのような移転に関連して、価値の所有権の証拠（例えば、証書、権利証書、所有権の証明書、または他の類似の所有権の証拠）を外部機関から価値ストア３０へ移転することができる。

図１０Ｅは、サービス価値がユーザのリンク外部口座から彼女のＴＡ口座へ移転される代表的な外部口座移転ウェブページ１６０ｄを示す。特に、ドロップダウンメニュー１６２は指定された価値がユーザの外部口座のうちの１つから移転されることを示し、ドロップダウンメニュー１６４はその指定された価値がユーザのＴＡ口座へ移転されることを示す。図に示されている例では、ユーザｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔは、彼女のリンクされているジェファーソンズドライクリーニング口座から彼女のＴＡ口座への１２枚のセーターの洗濯の移転を指定している。ユーザ１６が提示ボタンをクリックすると、指定された価値の証拠がユーザのリンク外部口座から価値ストア３０へ移転される。

特に、図２および４を再び参照すると、外部機関インターフェイス２４は、口座データベース２６から（コントローラ２０を介して）ユーザの選択された外部口座と関連付けられている口座情報を得る。図１０Ｅに示されている例では、外部機関インターフェイス２４は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔのジェファーソンズドライクリーニング口座の口座番号（ｃｂｒａｄｓｈａｗ）を口座データベース２６から得る。電話、電子メールメッセージ、携帯メール、ファックスメッセージ、または他の類似の通信プロトコルなどの通信プロトコルを用いて、外部機関インターフェイス２４は、その後、指定された価値の証拠（例えば、１２枚のセーターの洗濯のためのクーポンまたはトークン）の、ユーザのジェファーソンズドライクリーニング口座から価値ストア３０への移転を開始することができる。これは、外部機関１４₄ （ジェファーソンズドライクリーニング）から信頼できる機関１２への移転１８６として図１１に概略的に示されている。

指定された価値の証拠が価値ストア３０に受け取られていると信頼できる機関１２が判定すると、口座データベース２６は、ユーザのＴＡ口座の増大した価値を反映するように更新される。従って、図１２Ｄに示されているように、口座データベース２６は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔのサービス価値の１２枚のセーターの洗濯だけの増大を反映するように更新されている。

本発明に従う方法およびシステムは、たとえその外部口座が前もってＴＡ口座にリンクされていない場合にも、付加的にあるいは代わりに、ユーザ１６がユーザの外部口座と彼女のＴＡ口座との間で価値を移転することを可能にし得るということが当業者であれば理解できるはずである。例えば、ユーザ１６は、移転請求時に口座タイプ、口座名、口座番号などを指定することを許可され得る。そのような操作は、ユーザのＴＡ口座と外部口座との間での「１回限りの」移転のために望ましいかもしれない。

図１３に示されているように、ユーザ１６がナビゲーションペイン１２２の中の「口座ホーム」ハイパーリンクを選択すると、ユーザホームページ１２０は「最近の取引」テーブル１２４の中の前の移転の要約を表示する。さらに、図１４に示されているように、ユーザ１６がナビゲーションペイン１２２の中の「口座残高」ハイパーリンクを選択すると、口座残高ページ１９０は、口座残高テーブル１９２の中のユーザのＴＡ口座の中の価値の要約を表示する。

前述したように、ウェブインターフェイス２２は、ユーザ１６により、指定された価値と関連付けられたコードを用いて他のユーザ１６へ価値を移転するために、使用され得る。特に、支払人は、指定された価値と関連付けられているＰコードを信頼できる機関１２から請求するためにウェブインターフェイス２２を使用することができる。支払人はそのＰコードを受取人に伝えることができ、受取人は、その後、そのＰコードを信頼できる機関１２に提示することができる。信頼できる機関１２が、その提示されたＰコードが有効であり、かつ支払人のＴＡ口座が充分な資金を有すると判定すると、信頼できる機関１２は、その指定された価値を支払人のＴＡ口座から引き落とし、その指定された価値を受取人のＴＡ口座に振り込む。

代わりに、同じ価値移転が、Ｉコードを用いて成し遂げられ得る。具体的には、受取人は、指定された価値と関連付けられているＩコードを信頼できる機関１２から請求するためにウェブインターフェイス２２を使用することができる。その受取人はＩコードを支払人に伝えることができ、その支払人は、その後、Ｉコードを信頼できる機関１２に提示することができる。信頼できる機関１２が、その提示されたＩコードが有効であり、かつ支払人のＴＡ口座が充分な資金を有すると判定すると、信頼できる機関１２はその指定された価値を支払人のＴＡ口座から引き落とし、その指定された価値を受取人のＴＡ口座に振り込む。そのような取引を容易にするために、ウェブインターフェイス２２は、ナビゲーションペイン１２２において「コードを請求する」および「コードを提示する」ハイパーリンクを提供する。次に、そのようなハイパーリンクの使用の例を記述する。

支払いコードの支払人請求
ユーザであるキャリー（ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔ）がユーザであるホールフーズ（ｍｇｒ＠ｈｏｌｅｆｄｓ．ｃｏｍ）から１ガロンの豆乳を購入する場合には、キャリーはＰコードを用いて豆乳のための支払いをすることができる。図１５Ａ〜１５Ｃは、キャリーの信頼できる機関１２からのＰコード請求を示す代表的なウェブページを示す。
特に、図１５Ａは、ユーザの現在の口座残高をリストする現在の口座残高テーブル２０２を含む代表的な「コードを請求する」ウェブページ２００ａを示す。さらに、ウェブページ２００ａは、請求されたコードに関連付けられるべき価値の説明および量をそれぞれ指定するための説明データ入力フィールド２０４および量データ入力フィールド２０６を含む。さらに、ウェブページ２００ａは、コードのテキスト説明を入力するための任意のメモデータ入力フィールド２０８と、ユーザ１６がＴＡ口座セットアッププロセス中に生成したＰＩＮまたは他のセキュリティコードを明示するためのＰＩＮデータ入力フィールド２１０とを含む。さらに、ウェブページ２００ａは、請求されたコードをＰコードまたはＩコードとして指定するためのラジオボタン２１２と、リターンコードを請求するためのチェックボックス２１４とを含む。さらに、サービス条件確認メッセージ２１６を表示することができ、ユーザ１６は、「私は同意する」ボタン２１８を選択するか、あるいは他の類似の同意確認方法などによってサービス条件に肯定的に同意するように要求され得る。この例では、キャリーは、１３．２７米ドルと関連付けられるべきＰコードを請求している。

ユーザ１６が「提示する」ボタンをクリックした後、コードジェネレータ３２（図３）は、実質的にランダムなシステムコードＣ_S を生成する。図１５Ｂに示されているように、ウェブインターフェイス２２は、システムコードＣ_S をシステムコード表示エリア２２２ａの中に表示する（この例では「Ａ８３ＴＺ」）と共に「強化セキュリティオプション」セクションを含む「コードをカスタマイズする」ウェブページ２２０ａを表示し、この「強化セキュリティオプション」セクションは、ユーザ１６がユーザ指定されたコードＣ_U を提供することのできる「追加のコードキャラクタ」データ入力フィールド２２４ａと、ユーザ１６がコードについての有効期限を指定することのできる「有効期限」データ入力フィールド２２６ａと、コードの意図された受取人を特定するために使用され得る電子メールアドレス、電話番号または他の情報をユーザ１６が指定することのできる「意図された受取」データ入力フィールド２２８ａとを含む。ユーザ１６はデータ入力フィールド２２４ａ、２２６ａおよび２２８ａの１つ以上にデータを入力することもできるし、あるいは全てのフィールドを空白のままにしておくこともできる。ユーザ１６が「提示する」ボタンをクリックした後、コードコンバイナ３６（図３）は、指定された価値と関連付けられたコードを生成するためにシステムコードＣ_S をユーザ指定されたコードＣ_U と結合させる。図に示されている例では、キャリーは、ユーザ指定されたコードＣ_U を提供しておらず、有効期限も意図された受取人も指定していない。本発明に従うシステムがコードをカスタマイズするウェブページ２２０ａで任意にシステムコードＣ_S をユーザ１６に対して表示しないかもしれないということを当業者であれば理解できるはずである。

次に、図１５Ｃに示されているように、ウェブインターフェイス２２は、指定された価値と関連付けられたコードを表示するコード表示フィールド２３２ａを含む「発行されたコード」ウェブページ２３０ａを表示する。この例では、キャリーはユーザ指定されたコードＣ_U を提供しなかったので、表示されるコードはシステムコードＣ_S と同じである（この例では「Ａ８３ＴＺ」）。発行されたコードのウェブページ２３０ａは、コードと関連付けられたタイプおよび価値を約説するのと、コードの使用に関連するサービスについての追加条件を伝える、メッセージ２３４を含むこともできる。

図１１を再び参照すると、この代表的なＰコード請求は、信頼できる機関１２からのＰコード「Ａ８３ＴＺ」の請求２４０として概略的に示されている。さらに、図１６に示されているように、口座データベース２６は、キャリーがオープンコード「Ａ８３ＴＺ」を有することを示すように更新されている。この例では、コードと関連付けられた指定されている価値はユーザのＴＡ口座からまだ移転されていないので、口座データベース２６はキャリーのＴＡ口座価値の変化を反映していない。しかし、当業者であれば、口座データベース２６が、代わりに、生成されたコードと関連付けられた通貨価値の量の減少（１３．２７米ドル）を反映するように更新され得るということが理解できるはずである。

彼女はＰコードを受け取っているので、キャリーはもうＰコードを１ガロンの豆乳について支払いをするためにホールフーズに伝えることができる。この取引は、キャリーからホールフーズへのＰコード「Ａ８３ＴＺ」の支払い２４２として図１１に概略的に示されている。ホールフーズは、その後、受け取ったＰコードを信頼できる機関１２に提示することができ、このことを以下でより詳しく記述する。

インボイスコードの受取人請求
キャリーがユーザであるミランダ（ｈｏｂｂｅｓ＠ｇｍａｉｌ．ｃｏｍ）のためにベビーシッターをする場合には、キャリーは彼女のベビーシッターサービスについてＩコードを用いてミランダに代金を請求することができる。図１７Ａ〜１７Ｃは、信頼できる機関１２からのキャリーのＩコード請求を示す代表的なウェブページを示す。
特に、図１７Ａは、５０豪ドルと関連付けられるべきＩコードをキャリーが請求している代表的な「コードを請求する」ウェブページ２００ｂを示す。ユーザ１６が「提示する」ボタンをクリックした後、コードジェネレータ３２（図３）は実質的にランダムなシステムコードＣ_S （この例では「Ｗ９５６９１」）を生成し、図１７Ｂに示されている「コードをカスタマイズする」ウェブページ２２０ｂ上のコード表示フィールド２２２ｂで表示される。この例では、キャリーは、「追加のコードキャラクタ」データ入力フィールド２２４ｂに「ｃｏ＄ｍｏ」というユーザ指定されたコードＣ_U を提供しているけれども、コードについての有効期限も意図された受取人も指定していない。

ユーザ１６が「提示する」ボタンをクリックした後、コードコンバイナ３６（図３）は、指定された価値と関連付けられたコードを生成するためにシステムコードＣ_S をユーザ指定されたコードＣ_U と結合させる。従って、図１７Ｃに示されているように、ウェブインターフェイス２２は、指定された価値と関連付けられたコードを表示するコード表示フィールド２３２ｂを含む「発行されたコード」ウェブページ２３０ｂを表示する。この説明図では、表示されたコードはシステムコードＣ_S とユーザ指定されたコードＣ_U との組み合わせである（この例では「Ｗ９５６９１ｃｏ＄ｍｏ」）。この例では、コードは単にシステムコードＣ_S とユーザ指定されたコードＣ_U との連結である。コードコンバイナ３６（図３）が、代わりに、コードをインターリーブする手法、コードを逆連結する手法、あるいは他の類似の組み合わせ手法などの他の手法を用いてシステムコードＣ_S とユーザ指定されたコードＣ_U とを組み合わせることができることを当業者であれば理解できるはずである。

図１１を再び参照すると、この代表的なＩコード請求は、信頼できる機関１２からのＩコード「Ｗ９５６９１ｃｏ＄ｍｏ」の請求２４４として概略的に示されている。さらに、図１８に示されているように、口座データベース２６は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔがオープンコード「Ｗ９５６９１ｃｏ＄ｍｏ」を有することを示すように更新されている。この例では、コードと関連付けられた指定された価値がまだキャリーのＴＡ口座から移転されていないので、口座データベース２６はキャリーのＴＡ口座価値の変化を反映していない。

彼女はＩコードを受け取っているので、キャリーは今ではＩコードをベビーシッターサービスについてのインボイスとしてミランダに伝えることができる。この取引は、キャリーからミランダへのＩコード「Ｗ９５６９１ｃｏ＄ｍｏ」のインボイス２４６として図１１に概略的に示されている。ミランダは、その後、受け取ったＩコードを信頼できる機関１２に提示することができ、それは以下でより詳しく記述される。

リターン支払いコードの支払人請求
キャリーがキャリーの最新の本を売り込むための広報宣伝サービスを提供するようにユーザであるサマンサ（ｓｊ＠ｓｊｏｎｅｓ．ｃｏｍ）を雇う場合には、キャリーはＰコードを用いてサマンサのサービスについての支払いをすることができる。セキュリティを加えるために、キャリーは、この取引の一部としてリターンコードを請求することができる。図１９Ａ〜１９Ｃは、信頼できる機関１２からのキャリーのＲＰコード請求を示す代表的なウェブページを示す。
特に、図１９Ａは、キャリーが４枚のセーターの洗濯と関連付けられるべきＰコードを請求すると共にリターンコードを請求している代表的な「コードを請求する」ウェブページ２００ｃを示す。ユーザ１６が「提示する」ボタンをクリックした後、コードジェネレータ３２（図３）は第１および第２の実質的にランダムなシステムコードＣ_S1およびＣ_S2（この例では、それぞれ、「Ｆ２ＥＦ１Ｄ」および「８＊５％ＲＴ」）を生成する。第１のシステムコードＣ_S1は、図１９Ｂに示されている「コードをカスタマイズする」ウェブページ２２０ｃに表示される。この例では、キャリーはユーザ指定されたコードＣ_U を提供していないけれども、コードについて２００８年１２月２５日の有効期限と、ｓｊ＠ｓｊｏｎｅｓ．ｃｏｍという意図された受取人とを指定している。当業者であれば、コードジェネレータ３２が、代わりに、第２のシステムコードＣ_S2を後で生成できるということが理解できるはずである。

ユーザ１６が「提示する」ボタンをクリックした後、コードコンバイナ３６（図３）は、指定された価値と関連付けられたコードを生成するために第１のシステムコードＣ_S をユーザ指定されたコードＣ_U と結合させる。従って、図１９Ｃに示されているように、ウェブインターフェイス２２は、指定された価値と関連付けられたコードを表示するコード表示フィールド２３２ｃを含む「発行されたコード」ウェブページ２３０ｃを表示する。この説明図では、表示されたコードは第１のシステムコードＣ_S1（この例では「Ｆ２ＥＦ１Ｄ」）である。

再び図１１を参照すると、この代表的なＲＰコード請求は、信頼できる機関１２からのＲＰコード「Ｆ２ＥＦ１Ｄ」の請求２４８として概略的に示されている。さらに、図２０に示されているように、口座データベース２６は、ｃａｒｒｉｅ＠ｈｂｏ．ｎｅｔがオープンコード「Ｆ２ＥＦ１Ｄ」を有することを示すように更新されている。この例では、コードと関連付けられた指定された価値はまだユーザのＴＡ口座から移転されていないので、口座データベース２６はキャリーのＴＡ口座価値における変化を反映していない。

彼女はＲＰコードを受け取っているので、キャリーはもうＰＲサービスについて支払いをするためにＲＰコードをサマンサに伝えることができる。この取引は、キャリーからサマンサへのＲＰコード「Ｆ２ＥＦ１Ｄ」の支払い２５０として図１１に概略的に示されている。サマンサは、その後、受け取ったＲＰコードを信頼できる機関１２に提示することができ、それについては以下でより詳しく記述する。

リターンインボイスコードの受取人請求
サマンサが新しいつり綱洋服箪笥を買いに行く手伝いをする場合には、キャリーはサマンサに彼女の買いものサービスについてＩコードを用いてサマンサに代金を請求することができる。セキュリティを加えるために、キャリーは、この取引の一部としてリターンコードを請求することができる。図２１Ａ〜２１Ｃは、信頼できる機関１２からのキャリーのＲＩコード請求を示す代表的なウェブページを示す。
特に、図２１Ａは、キャリーが背中のマッサージ１回と関連付けられるべきＩコードを請求すると共にリターンコードを請求している代表的な「コードを請求する」ウェブページ２００ｄを示す。ユーザ１６が「提示する」ボタンをクリックした後、コードジェネレータ３２（図３）は第１および第２の実質的にランダムなシステムコードＣ_S1およびＣ_S2（この例では、それぞれ「ＪＪ７ＶＸ＃」および「５７７８Ｔ＠」）を生成する。第１のシステムコードＣ_S1は、図２１Ｂに示されている「コードをカスタマイズする」ウェブページ２２０ｄで表示される。この例では、キャリーは、ユーザ指定されたコードＣ_U 、有効期限あるいはコードについて意図された受取人を提供していない。当業者であれば、コードジェネレータ３２が代わりに第２のシステムコードＣ_S2を後で生成できるということが理解できるはずである。

ユーザ１６が「提示する」ボタンをクリックした後、コードコンバイナ３６（図３）は、指定された価値と関連付けられたコードを生成するために第１のシステムコードＣ_S1をユーザ指定されたコードＣ_U と結合させる。従って、図２１Ｃに示されているように、ウェブインターフェイス２２は、指定された価値と関連付けられたコードを表示するコード表示フィールド２３２ｄを含む「発行されたコード」ウェブページ２３０ｄを表示する。この説明図では、表示されるコードは第１のシステムコードＣ_S1である（この例では「ＪＪ７ＶＸ＃」）。

図１１を再び参照すると、この代表的なＲＩコード請求は、信頼できる機関１２からのＲＩコード「ＪＪ７ＶＸ＃」の請求２５２として概略的に示されている。さらに、図２２に示されているように、口座データベース２６は、キャリーがオープンコード「ＪＪ７ＶＸ＃」を有することを示すように更新されている。この例では、コードと関連付けられた指定された価値はユーザのＴＡ口座からまだ移転されていないので、口座データベース２６はキャリーのＴＡ口座価値における変化を反映していない。

彼女はＲＩコードを受け取っているので、キャリーはもうＲＩコードを買いものサービスについてのインボイスとしてサマンサに伝えることができる。この取引は、キャリーからサマンサへのＲＩコード「ＪＪ７ＶＸ＃」のインボイス２５４として図１１に概略的に示されている。サマンサは、その後、受け取ったＲＩコードを信頼できる機関１２に提示することができ、これについては以下でより詳しく記述する。

従って、図２３に示されているように、これら４つのコード請求が完了した後、コードデータベース２８は、（１）コード「Ａ８３ＴＺ」は１３．２７米ドルの通貨価値と関連付けられたＰコードであること、（２）コード「Ｗ９５６９１ｃｏ＄ｍｏ」は５０豪ドルの通貨価値と関連付けられたＩコードであること、（３）コード「Ｆ２ＥＦ１Ｄ」および「８＊５％ＲＴ」は４枚のセーターの洗濯のサービス価値と関連付けられた対応するＲＰコードであること、および（４）コード「ＪＪ７ＶＸ＃」および「５７７８Ｔ＠」は背中のマッサージ１回の商品価値と関連付けられた対応するＲＩコードであることを示す。

図２４に示されているように、キャリーがナビゲーションペイン１２２の中の「口座ホーム」ハイパーリンクを選択すると、ユーザホームページ１２０は、最近の取引テーブル１２４で前述したコード請求の約説を表示する。さらに、オープンコードテーブル１２６は、コードタイプ、作成日および有効期限を含む、キャリーのオープンコードの約説を表示する。当業者であれば、オープンコードに関してもっと多くのあるいはもっと少ない情報が表示され得るということが理解できるはずである。例えば、各コードと関連付けられている価値も表示され得る。

前述したように、キャリーは、Ｐコードをホールフーズに、Ｉコードをミランダに、ＲＰコードをサマンサに、ＲＩコードをサマンサに提供した。これらの受取人の各々は、その後、各コードと関連付けられている価値を支払人から受取人に移転するためにナビゲーションパネル１２２の中の「コードを提示する」ハイパーリンクを用いて、自分たちの受け取ったコードを信頼できる機関１２に提示することができる。次に、そのようなハイパーリンクの使用の例を記述する。

Ｐコードの受取人提示
キャリーからＰコード「Ａ８３ＴＺ」を受け取ると、ホールフーズは、コードを信頼できる機関１２に提示するためのナビゲーションペイン１２２の中の「コードを提示する」ハイパーリンクを用いてＰコードを信頼できる機関１２に提示することができる。例えば、図２５Ａ〜２５Ｂは、信頼できる機関１２へのＰコードの提示が描かれた代表的なウェブページを示す。

特に、図２５Ａは、ユーザの現在の口座残高と、提示されるべきコードを入力するために使用され得るコードデータ入力フィールド２６４と、コードデータ入力フィールド２６４に入力されたコードと関連付けられている価値を指定するために使用され得る価値説明データ入力フィールド２６６および量データ入力フィールド２６８とをそれぞれ表示する口座残高テーブル２６２を含む代表的な「コードを提示する」ウェブページ２６０ａを示す。本発明に従う方法およびシステムは、代わりに、ユーザ１６が価値説明、量、または他の情報などの追加情報をも提供することを要求せずにユーザ１６がコードを提供することだけを要求してもよいということを当業者であれば理解できるはずである。

この例では、ホールフーズは、コード「Ａ８３ＴＺ」をコードデータ入力フィールド２６４に入力し、説明データ入力フィールド２６６で「米ドル」を、量データ入力フィールド２６８で「１３．２７」を指定している。提示に関するテキストメモを入力するために任意のメモデータ入力フィールド２７０が使用され、ユーザのＰＩＮを入力するためにＰＩＮデータ入力フィールド２７２が使用され得る。サービス条件確認メッセージ２７４が表示され、ユーザ１６は、「私は同意する」ボタン２７６を選択するかあるいは同意を確認する他の類似方法によるなどして、サービス条件に肯定的に同意するように要求され得る。

ユーザ１６が「提示する」ボタンをクリックした後、コントローラ２０（図２）は、提示されたコードが有効か否かを判定するためにコードデータベース２８にアクセスする。例えば、コードがオープンで、かつ他のコードデータ要求条件が満たされているならば、そのコードは有効であると見なされ得る。例えば、請求側のユーザが有効期限または意図された受取人を指定したならば、提示されたコードは、そのコードが指定された有効期限より前に提示され、かつそのコードがその意図された受取人により提示された場合に限って有効であり得る。

本発明に従うある実施形態では、信頼できる機関１２は、ユーザ供給された価値説明がコードデータベース２８内のコードと関連付けられた価値説明と一致することを要求することによって、システムのセキュリティを高めることができる。それに関して、コードが失われたならば、コードを発見した許可されていないユーザ１６は、コードと関連付けられた正確な価値説明も知っていなければコードを単に信頼できる機関１２に提示することはできない。この点に関して、コード有効性判定は、コードと関連付けられた価値説明をコードデータベース２８から取り出し、その取り出した価値説明を、データ入力フィールド２６６および２６８の中の提示側ユーザ１６により提供された価値説明および量と比較することを含むことができる。

コードデータベース２８がデータフィールド２６４内の受け取り側ユーザ１６により提供されたコードについてのエントリを含んでいなければ、あるいはコード確認条件のいずれかが満たされなければ、コントローラ２０は、ユーザインターフェイス２２に、指定されたコードおよび／または指定された価値が間違っているというエラーメッセージを提供させることができる。ユーザインターフェイス２２は、ユーザ１６が提示を再試行することを許可するか、あるいはセッションを直ちに終了させることができる。セキュリティ上の理由から、コントローラ２０は、提示試行が所定回数だけ失敗した後にユーザの口座を凍結させることができる。

提示されたＰコードが有効であるとコントローラ２０が判定したならば、コントローラ２０はコードを無効にし（例えば、Ｐコードを口座データベース２６およびコードデータベース２８から削除することにより）、Ｐコードと関連付けられた価値を支払人のＴＡ口座から引き落とし、その関連付けられた価値を受取人のＴＡ口座に振り込む。さらに、ユーザインターフェイス２２は「提示確認」ウェブページ２７８ａを表示し、その例が図２５Ｂに示されている。具体的には、ウェブページ２７８ａは、ユーザのＴＡ口座に振り込まれた量を含む、ユーザの現在の口座残高を表示する口座残高テーブル２８０ａを含む。

図１１を再び参照すると、この取引はホールフーズによるコード「Ａ８３ＴＺ」の信頼できる機関１２への提示３０２として図１１に概略的に示されている。さらに、図２６に示されているように、口座データベース２６は、提示されたＰコードと関連付けられた量（１３．２７米ドル）のホールフーズ通貨価値の増加と、キャリーの通貨価値の同量の減少とを反映するように更新されている。さらに、口座データベース２６は、コード「Ａ８３ＴＺ」をキャリーのオープンコードから削除するように更新されている。この例が示すように、コードは価値を引き出すユーザ１６を特定する情報を含んでいなくてもよいので、ユーザ１６は、コードと関連付けられた価値を匿名で移転するためにコードを使用することができる。

Ｉコードの受取人提示
キャリーからＩコード「Ｗ９５６９１ｃｏ＄ｍｏ」を受け取ると、ミランダはＩコードを信頼できる機関１２に提示することができる。例えば、図２７Ａ〜２７Ｃは、信頼できる機関１２へのＩコードの提示が描かれた代表的なウェブページを示す。特に、図２７Ａは、ミランダがコード「Ｗ９５６９１ｃｏ＄ｍｏ」をコードデータ入力フィールド２６４に入力し、説明データ入力フィールド２６６で「豪ドル」を、量データ入力フィールド２６８で「５０」を指定している代表的な「コードを提示する」ウェブページ２６０ｂを示す。

ユーザ１６が「提示する」ボタンをクリックした後、コントローラ２０（図２）は、コードデータ入力フィールド２６４において提供されたコードが有効か否かを判定するためにコードデータベース２８にアクセスする。提示されたＩコードが有効であるとコントローラ２０が判定したならば、コントローラ２０は、Ｉコードと関連付けられている価値がユーザのＴＡ口座において入手可能であるか否かを判定する。図２７Ａに示されている例では、関連付けられた価値（５０豪ドル）は、ミランダのＴＡ口座で現在入手可能な通貨ではない。しかし、ミランダの口座は、関連付けられた価値の額に両替できる充分な通貨（３１２英ポンド）をまさに含んでいる。従って、ユーザインターフェイス２２は、ユーザ１６が通貨両替を許可するか、あるいはＩコードと関連付けられた価値を含むように充分な価値をユーザ１６が彼女のＴＡ口座に移転させるようにコード提示を保管しておくことを可能にするラジオボタン２８４および２８６を提供する「不十分な価値」ウェブページ２８２を表示することができる。図に示されている例では、ミランダは通貨両替（および指定された便利料）を許可することを選択する。

指定された価値がユーザのＴＡ口座で入手可能であるとコントローラ２０が判定した後、コントローラ２０は、コードを無効にし（例えば、Ｉコードを口座データベース２６およびコードデータベース２８から削除することにより）、Ｉコードと関連付けられた価値をミランダのＴＡ口座から引き落とし、関連付けられた価値をキャリーのＴＡ口座に振り込む。さらに、図２７Ｃに示されているように、ユーザインターフェイス２２は「提示確認」ウェブページ２７８ｂを表示し、これはユーザのＴＡ口座に対して借り方に記入された額を含むユーザの現在の口座残高を表示する。

図１１を再び参照すると、この取引は信頼できる機関１２へのミランダによるコード「Ｗ９５９６９１ｃｏ＄ｍｏ」の提示３０６として図１１に示されている。さらに、図２８に示されているように、口座データベース２６は、キャリーの通貨価値の、提示されたＩコードと関連付けられた額の増加（５０豪ドル）と、ミランダの通貨価値の、提示されたＩコードと関連付けられた両替された額の減少（２５英ポンド）とを反映するように更新されている。さらに、口座データベース２６は、コード「Ｗ９５９６９１ｃｏ＄ｍｏ」をキャリーのオープンコードから削除するように更新されている。

ＲＰコードの受取人提示
キャリーからＲＰコード「Ｆ２ＥＦ１Ｄ」を受け取ると、サマンサはＲＰコードを信頼できる機関１２に提示することができる。例えば、図２９Ａ〜２９Ｂは、信頼できる機関１２へのＲＰコードの提示が描かれた代表的なウェブページを示す。特に、図２９Ａは、サマンサがコード「Ｆ２ＥＦ１Ｄ」をコードデータ入力フィールド２６４に入力し、説明データ入力フィールド２６６で「セーターの洗濯」を、量データ入力フィールド２６８で「４」を指定している代表的な「コードを提示する」ウェブページ２６０ｃを示す。

ユーザ１６が「提示する」ボタンをクリックした後、コントローラ２０（図２）は、提示されたコードが有効か否かを判定するためにコードデータベース２８にアクセスする。この例では、コントローラ２０は、コードデータベース２８から、コード「Ｆ２ＥＦ１Ｄ」が２００８年１２月２５日の有効期限と、ｓｊ＠ｓｊｏｎｅｓ．ｃｏｍという意図された受取人とを有するオープンリターンコードであると判定する。提示されたコードがオープンであり、コードが有効期限より前にその意図された受取人により提示されたので、コントローラ２０は、提示されたコードが有効であると判定する。コントローラは、その後、コードと関連付けられている価値説明をコードデータベース２８から取り出し、その取り出した価値説明を、データ入力フィールド２６６および２６８でサマンサにより提供された価値説明および量と比較する。

提示されたＲＰコードが有効であるとコントローラ２０が判定すると、コントローラ２０はウェブインターフェイス２２にリターンコードをユーザ１６に伝えさせる。例えば、図２９Ｂに示されているように、ウェブインターフェイス２２は、リターンコードを受取人に伝える指示２９０ａを含んでいて、リターンコードを支払人に伝えるように受取人に知らせる「提示ペンディング」ウェブページ２８８を表示する。さらに、ウェブページ２８８は、ＲＰコード提示が完了したならばユーザの口座残高を表示するテーブル２９２を含むことができる。図３０に示されているように、口座データベース２６は、ＲＰコード「８＊５％ＲＴ」をサマンサのオープンコードに付け加えるように更新されている。

図１１を再び参照すると、これらの取引は、サマンサによる信頼できる機関１２へのコード「Ｆ２ＥＦ１Ｄ」の提示３１０、信頼できる機関１２からサマンサへのリターンコード「８＊５％ＲＴ」の伝達３１２、およびサマンサによるキャリーへのリターンコード「８＊５％ＲＴ」の伝達３１４として図１１に概略的に示されている。
サマンサがリターンコードをキャリーに提供した後、キャリーはリターンコードを信頼できる機関１２に提示することができる。特に、図３１に示されているように、ウェブインターフェイス２２は、幾つかのオープンコードがリターンコードを必要とすることをユーザに知らせると共に、ユーザ１６がリターンコードを容易に指定できるようにする「コードを提示する」ウェブページ２６０ｄを表示することができる。例えば、ウェブページ２６０ｄは、ユーザ１６が、リターンコードデータ入力フィールド２９６でリターンコードを指定できるオープンＲＰコードの１つを選択すること、または他のコードを提示するためのオプションを選択することを可能にするラジオボタン２９４を含むことができる。図に示されている例では、キャリーは、ＲＰコード「Ｆ２ＥＦ１Ｄ」に対応するリターンコード「８＊５％ＲＴ」を提示する。

キャリーが「提示する」ボタンをクリックした後、コントローラ２０（図２）は、提示されたリターンコードが有効か否かを判定するためにコードデータベース２８にアクセスする。この例では、コントローラ２０は、コードデータベース２８から、提示されたコード「８＊５％ＲＴ」がＲＰコード「Ｆ２ＥＦ１Ｄ」と一致すると判定する。コントローラ２０は、その後、両方のＲＰコードを無効にし（例えば、ＲＰコードを口座データベース２６およびコードデータベース２８から削除することにより）、ＲＰコードと関連付けられた価値を支払人のＴＡ口座から引き落とし、関連付けられた価値を受取人のＴＡ口座に振り込む。

図１１を再び参照すると、この取引は信頼できる機関１２に対するコード「８＊５％ＲＴ」のキャリーによる提示３１６として図１１に概略的に示されている。さらに、図３２に示されているように、口座データベース２６は、サマンサのサービス価値の、提示されたＲＰコードと関連付けられた量（４枚のセーターの洗濯）の増加と、キャリーのサービス価値の同量の減少とを反映するように更新されている。さらに、口座データベース２６は、ＲＰコード「Ｆ２ＥＦ１Ｄ」および「８＊５％ＲＴ」をキャリーおよびサマンサのオープンコードからそれぞれ削除するように更新されている。

ＲＩコードの受取人提示
キャリーからＲＩコード「ＪＪ７ＶＸ＃」を受け取ると、サマンサはＲＩコードを信頼できる機関１２に提示することができる。例えば、図３３Ａ〜３３Ｂは、信頼できる機関１２に対するＲＩコードの提示が描かれた代表的なウェブページを示す。特に、図３３Ａは、サマンサがコード「ＪＪ７ＶＸ＃」をコードデータ入力フィールド２６４に入力し、説明データ入力フィールド２６６で「背中のマッサージ」を、量データ入力フィールド２６８で「１」を指定している代表的な「コードを提示する」ウェブページ２６０ｅを示す。

ユーザ１６が「提示する」ボタンをクリックした後、コントローラ２０（図２）は、提示されたコードが有効か否かを判定するためにコードデータベース２８にアクセスする。この例では、コントローラ２０は、コードデータベース２８から、コード「ＪＪ７ＶＸ＃」がオープンリターンコードであると判定する。提示されたコードはオープンであるので、コントローラ２０は、提示されたコードが有効であると判定する。コントローラは、その後、コードと関連付けられた価値説明をコードデータベース２８から取り出し、その取り出した価値説明を、データ入力フィールド２６６および２６８でサマンサにより提供された価値説明および量と比較する。

提示されたＲＩコードが有効であるとコントローラ２０が判定すると、コントローラ２０は、ウェブインターフェイス２２に、リターンコードをユーザ１６に伝えさせる。例えば、図３３Ｂに示されているように、ウェブインターフェイス２２は、リターンコードを支払人に伝える指示２９０ｂを含むと共に、リターンコードを受取人に伝えるように支払人に知らせる「提示ペンディング」ウェブページ２８８を表示する。さらに、ウェブページ２８８は、ＲＩコード提示が完了したならば、ユーザの口座残高を表示するテーブル２９２を含むことができる。図３４に示されているように、口座データベース２６は、ＲＩコード「５７７８Ｔ＠」をサマンサのオープンコードに付け加えるように更新されている。

図１１を再び参照すると、これらの取引は、信頼できる機関１２へのコード「ＪＪ７ＶＸ＃」のサマンサによる提示３１８、信頼できる機関１２からサマンサへのリターンコード「５７７８Ｔ＠」の伝達３２０、およびキャリーへのサマンサによるリターンコード「５７７８Ｔ＠」の伝達３２２として図１１に概略的に示されている。
サマンサがリターンコードをキャリーに提供した後、キャリーはリターンコードを信頼できる機関１２に提示することができる。特に、図３５に示されているように、ウェブインターフェイス２２は、幾つかのオープンコードがリターンコードを必要とすることをユーザに知らせると共にユーザ１６がリターンコードを容易に指定できるようにする「コードを提示する」ウェブページ２６０ｆを表示することができる。例えば、ウェブページ２６０ｆは、ユーザ１６がリターンコードデータ入力フィールド２９６でリターンコードを指定できるオープンＲＩコードを選択すること、あるいは他のコードを提示するためのオプションを選択することを可能にするラジオボタン２９４を含むことができる。図に示されている例では、キャリーはＲＩコード「ＪＪ７ＶＸ＃」に対応するリターンコード「５７７８Ｔ＠」を提示する。

キャリーが「提示する」ボタンをクリックした後、コントローラ２０（図２）は、提示されたリターンコードが有効であるか否かを判定するためにコードデータベース２８にアクセスする。この例ではコントローラ２０は、コードデータベース２８から、提示されたコード「５７７８Ｔ＠」がＲＩコード「ＪＪ７ＶＸ＃」と一致すると判定する。コントローラ２０は、その後、両方のＲＩコードを無効にし（例えば、ＲＩコードを口座データベース２６およびコードデータベース２８から削除することにより）、ＲＩコードと関連付けられた価値をサマンサのＴＡ口座から引き落とし、関連付けられた価値をキャリーのＴＡ口座に振り込む。

図１１を再び参照すると、この取引は信頼できる機関１２に対するキャリーによるコード「５７７８Ｔ＠」の提示３２４として図１１に概略的に描かれている。さらに、図３６に示されているように、口座データベース２６は、サマンサの商品価値の、提示されたＲＩコードと関連付けられた量（背中のマッサージ１回）の減少と、キャリーの商品価値の同量の増加とを反映するように更新されている。さらに、口座データベース２６は、ＲＩコード「ＪＪ７ＶＸ＃」および「５７７８Ｔ＠」をそれぞれキャリーおよびサマンサのオープンコードから削除するように更新されている。

コードプロセスの流れ
価値移転システム１０のプロセス操作をさらに説明するために、図３７〜４０は、前述した４つの異なるタイプのコードの各々についてコード請求および提示のプロセスを概略的に示す。
ここで図３７を参照すると、代表的なＰコード取引３５０が記述されている。具体的には、ステップ３５２で、支払人は、指定された価値のためのＰコードを信頼できる機関１２から請求する。ステップ３５４で、信頼できる機関１２は、指定された価値が支払人のＴＡ口座で入手可能か否かを判定し、入手可能ならば、Ｐコードを生成し、その指定された価値をＰコードと関連付け、口座データベース２６およびコードデータベース２８を更新し、Ｐコードを支払人に伝える。次に、ステップ３５６で、支払人はＰコードを信頼できる機関１２から受け取る。ステップ３５８で、支払人はＰコードを受取人に伝える。ステップ３６０で、受取人は、Ｐコードを支払人から受け取り、Ｐコードを信頼できる機関１２に提示する。ステップ３６２で、信頼できる機関１２はＰコードを受取人から受け取る。ステップ３６４で、信頼できる機関１２は、受け取ったＰコードが有効であるか否かを判定し、有効ならば、Ｐコードと関連付けられている価値を判定し、Ｐコードを無効にし（例えば、それをコードデータベース２８から削除することにより）、その関連付けられた価値を支払人のＴＡ口座から引き落とし、その関連付けられた価値を受取人のＴＡ口座に振り込む。最後に、ステップ３６６で、受取人は受取人のＴＡ口座で価値を受け取る。

ここで図３８を参照すると、代表的なＩコード取引３７０が記述されている。特に、ステップ３７２で、受取人は、指定された価値について信頼できる機関１２からＩコードを請求する。ステップ３７４で、信頼できる機関１２は、その請求を受取人から受け取り、Ｉコードを生成し、指定された価値をＩコードと関連付け、口座データベース２６およびコードデータベース２８を更新し、Ｉコードを受取人に伝える。次に、ステップ３７６で、受取人はＩコードを信頼できる機関１２から受け取る。ステップ３７８で、受取人はＩコードを支払人に伝える。ステップ３８０で、支払人はＩコードを受取人から受け取り、Ｉコードを信頼できる機関１２に提示する。ステップ３８２で、信頼できる機関１２はＩコードを支払人から受け取る。ステップ３８４で、信頼できる機関１２は、その受け取ったＩコードが有効か否かを判定し、有効ならば、Ｉコードと関連付けられた価値を判定し、その関連付けられた価値が支払人のＴＡ口座で入手可能か否かを判定し、入手可能ならば、Ｉコードを無効にし（例えば、それをコードデータベース２８から削除することにより）、関連付けられた価値を支払人のＴＡ口座から引き落とし、関連付けられた価値を受取人のＴＡ口座に振り込む。最後に、ステップ３８６で、受取人は価値を受取人のＴＡ口座で受け取る。

ここで図３９を参照すると、代表的なＲＰコード取引３９０が記述されている。具体的には、ステップ３９２で、支払人は、指定された価値についてのＲＰコードを信頼できる機関１２から請求する。ステップ３９４で、信頼できる機関１２は、指定された価値が支払人のＴＡ口座で入手可能であるか否かを判定し、入手可能であるならば、１対のＲＰコード（例えば、Ｃ１、Ｃ２）を生成し、指定された価値をＲＰコードと関連付け、口座データベース２６およびコードデータベース２８を更新し、Ｃ１を支払人に伝える。次に、ステップ３９６で、支払人は信頼できる機関１２からＣ１を受け取る。ステップ３９８で、支払人はＣ１を受取人に伝える。ステップ４００で、受取人は支払人からＣ１を受け取り、Ｃ１を信頼できる機関１２に提示する。ステップ４０２で、信頼できる機関１２はＣ１を受取人から受け取る。ステップ４０４で、信頼できる機関１２は、受け取ったＣ１が有効か否かを判定し、有効ならばＣ２を受取人に伝える。

次に、ステップ４０６で、受取人は信頼できる機関１２からＣ２を受け取る。ステップ４０８で、受取人はＣ２を支払人に伝える。ステップ４１０で、支払人は受取人からＣ２を受け取り、Ｃ２を信頼できる機関１２に提示する。ステップ４１２で、信頼できる機関１２は支払人からＣ２を受け取る。ステップ４１４で、信頼できる機関１２は、受け取ったＣ２が有効か否かを判定し、有効ならば、Ｃ２と関連付けられた価値を判定し、Ｃ１およびＣ２を無効にし（例えば、それらをコードデータベース２８から削除することにより）、支払人のＴＡ口座から関連付けられた価値を引き落とし、受取人のＴＡ口座に関連付けられた価値を振り込む。最後に、ステップ４１６で、受取人は価値を受取人のＴＡ口座で受け取る。

ここで図４０を参照すると、代表的なＲＩコード取引４２０が記述されている。具体的には、ステップ４２２で、受取人は、指定された価値についてＲＩコードを信頼できる機関１２から請求する。ステップ４２４で、信頼できる機関１２は、その請求を受取人から受け取り、１対のＲＩコード（例えば、ＣＩ１、ＣＩ２）を生成し、指定された価値をＣＩ１およびＣＩ２と関連付け、口座データベース２６およびコードデータベース２８を更新し、ＣＩ１を受取人に伝える。次に、ステップ４２６で、受取人は信頼できる機関１２からＣＩ１を受け取る。ステップ４２８で、受取人はＣＩ１を支払人に伝える。ステップ４３０で、支払人はＣＩ１を受取人から受け取り、ＣＩ１を信頼できる機関１２に提示する。ステップ４３２で、信頼できる機関１２は支払人からＣＩ１を受け取る。ステップ４３４で、信頼できる機関１２は、指定された価値が支払人のＴＡ口座で入手可能か否かを判定し、入手可能ならば、受け取ったＣＩ１が有効か否かを判定し、有効ならば、ＣＩ２を支払人に伝える。

次に、ステップ４３６で、支払人は信頼できる機関１２からＣＩ２を受け取る。ステップ４３８で、支払人はＣＩ２を受取人に伝える。ステップ４４０で、受取人は支払人からＣＩ２を受け取り、ＣＩ２を信頼できる機関１２に提示する。ステップ４４２で、信頼できる機関１２は受取人からＣＩ２を受け取る。ステップ４４４で、信頼できる機関１２は、受け取ったＣＩ２が有効であるか否かを判定し、有効ならば、ＣＩ２と関連付けられた価値を判定し、ＣＩ１およびＣＩ２を無効にし（例えば、それらをコードデータベース２８から削除することにより）、支払人のＴＡ口座から関連付けられた価値を引き落とし、関連付けられた価値を受取人のＴＡ口座に振り込む。最後に、ステップ４４６で、受取人は価値を受取人のＴＡ口座で受け取る。

信頼できる機関のコード取り扱い操作
前述したように、本発明に従うシステムは、Ｐコード、Ｉコード、ＲＰコードおよび／またはＲＩコードを使用することができる。これらの代表的なコードタイプの各々の請求および提示に関する信頼できる機関１２の操作を、次により詳しく記述する。
具体的には、図４１は、Ｐコードを処理するために信頼できる機関１２により実行される代表的なプロセス５００を示す。ステップ５０２から始まって、信頼できる機関１２は、指定された価値のためのＰコードについての請求を支払人から受け取る。次に、ステップ５０４で、信頼できる機関１２は、指定された価値が支払人のＴＡ口座から引き出しのために入手可能か否かを判定する。入手可能でなければ、ステップ５０６でエラーメッセージが支払人に対して表示され、プロセスを終了することができる。そうでなければ、プロセスはステップ５０８に進み、これにより信頼できる機関１２はＰコードを生成する。次に、ステップ５１０で、信頼できる機関１２は、指定された価値をステップ５０８で生成されたＰコードと関連付ける。ステップ５１２で、信頼できる機関１２は、生成されたＰコードおよびそれに関連付けられた価値をオープンコードとしてコードデータベース２８に記録する。次に、ステップ５１４で、信頼できる機関１２は生成されたＰコードを支払人に伝え、支払人は、その後、Ｐコードを受取人に伝えることができる。

ステップ５１６で、信頼できる機関１２は、自分が受取人からＰコード提示を受け取っているか否かを判定する。受け取っていなければ、信頼できる機関は待ち続ける。しかし、信頼できる機関がＰコード提示を受け取ると、ステップ５１８で、信頼できる機関１２は、その提示されたＰコードが有効か否かを判定する。例えば、信頼できる機関１２は、受取人により提供された追加のデータが正しければ（例えば、価値の説明および量、意図された受取人など）、提示されたＰコードが依然としてオープンであるか否かを判定するためにコードデータベース２８を検索することができる。提示されたＰコードが有効でなければ、ステップ５２０で、信頼できる機関１２は、エラーメッセージを表示し、Ｐコードを再提示するように受取人を促すことができる。信頼できる機関１２は、無制限の回数の再試行を許可することができ、あるいは試行が所定回数失敗した後に受取人がＰコードを再提示することを妨げることができる。

信頼できる機関１２が、提示されたＰコードが有効であると判定したならば、ステップ５２２で信頼できる機関１２は、コードデータベース２８から、Ｐコードと関連付けられた価値を判定する。次に、ステップ５２４で、信頼できる機関は、その関連付けられた価値を支払人のＴＡ口座から引き落とす。ステップ５２６で、信頼できる機関１２はＰコードを無効にする。例えば、信頼できる機関１２は、コードデータベース２８においてＰコードを「閉じられた」とマーク付けすることができ、口座データベース２６においてＰコードを支払人のＴＡ口座から除去することができる。最後に、ステップ５２８で、信頼できる機関１２は、口座データベース２６において関連付けられた価値を受取人のＴＡ口座に振り込む。

ここで図４２を参照すると、Ｉコードを処理するために信頼できる機関１２により実行される代表的なプロセス５３０が記述されている。ステップ５３２から始まって、信頼できる機関１２は、指定された価値のためのＩコードについて受取人から請求を受け取る。次に、ステップ５３４で、信頼できる機関１２はＩコードを生成する。ステップ５３６で、信頼できる機関１２は、その生成されたＩコードとそれに関連付けられた価値とをオープンコードとしてコードデータベース２８に記録する。次に、ステップ５３８で、信頼できる機関１２は生成されたＩコードを受取人に伝え、受取人は、その後、Ｉコードを支払人に伝えることができる。

ステップ５４０で、信頼できる機関１２は、自分が支払人からＩコード提示を受け取っているか否かを判定する。受け取っていなければ、信頼できる機関は待ち続ける。しかし、信頼できる機関がＩコード提示を受け取ったならば、ステップ５４２で、信頼できる機関１２は、提示されたＩコードが有効か否かを判定する。例えば、信頼できる機関１２は、支払人により提供された追加のデータが正しければ（例えば、価値の説明および量、意図された受取人など）、提示されたＩコードが依然としてオープンであるか否かを判定するためにコードデータベース２８を検索することができる。提示されたＩコードが有効でなければ、ステップ５４４で、信頼できる機関１２はエラーメッセージを表示して、Ｉコードを再提示するように支払人を促すことができる。信頼できる機関１２は、無制限の回数の再試行を許可することができ、あるいは試行が所定回数失敗した後に支払人がＩコードを再提示することを妨げることができる。

信頼できる機関１２が、提示されたＩコードが有効であると判定したならば、ステップ５４６で信頼できる機関１２は、コードデータベース２８から、Ｉコードと関連付けられている価値を判定する。次に、ステップ５４８で、信頼できる機関１２は、関連付けられた価値が支払人のＴＡ口座から引き出しのために入手可能か否かを判定する。入手可能でなければ、ステップ５５０で、エラーメッセージが支払人に対して表示され、プロセスを終了することができる。そうでなければ、プロセスはステップ５５２に進み、信頼できる機関は関連付けられた価値を支払人のＴＡ口座から引き落とす。ステップ５５４で、信頼できる機関１２はＩコードを無効にする。例えば、信頼できる機関１２は、コードデータベース２８においてＩコードを「閉じられた」とマーク付けすることができ、口座データベース２６においてＩコードを受取人のＴＡ口座から削除することができる。最後に、ステップ５５６で、信頼できる機関１２は、口座データベース２６において関連付けられた価値を受取人のＴＡ口座に振り込む。

ここで図４３Ａ〜４３Ｂを参照すると、ＲＰコードを処理するために信頼できる機関１２により実行される代表的なプロセス５６０が記述されている。ステップ５６２から始まって、信頼できる機関１２は、指定された価値のためのＲＰコードについて支払人から請求を受け取る。次に、ステップ５６４で、信頼できる機関１２は、その指定された価値が支払人のＴＡ口座から引き出すために入手可能か否か判定する。入手可能でなければ、ステップ５６６でエラーメッセージが支払人に対して表示され、プロセスを終了することができる。そうでなければ、プロセスはステップ５６８に進み、これにより信頼できる機関１２は１対のＲＰコード（例えば、Ｃ１およびＣ２）を生成する。次に、ステップ５７０で、信頼できる機関１２は、指定された価値を、ステップ５６８で生成されたＣ１およびＣ２と関連付ける。ステップ５７２で、信頼できる機関１２は、Ｃ１およびＣ２ならびにこれらと関連付けられた価値をオープンコードとしてコードデータベース２８に記録する。次に、ステップ５７４で、信頼できる機関１２はＣ１を支払人に伝え、支払人は、その後、Ｃ１を受取人に伝えることができる。

ステップ５７６で、信頼できる機関１２は、自分が受取人からＣ１提示を受け取っているか否かを判定する。受け取っていなければ、信頼できる機関は待ち続ける。しかし、信頼できる機関がＣ１提示を受け取ると、ステップ５７８で、信頼できる機関１２は、提示されたＣ１が有効か否かを判定する。例えば、信頼できる機関１２は、受取人により提供された追加のデータが正しければ（例えば、価値の説明および量、意図された受取人など）、提示されたＣ１が依然としてオープンであるか否かを判定するためにコードデータベース２８を検索することができる。提示されたＣ１が有効でなければ、ステップ５８０で、信頼できる機関１２はエラーメッセージを表示し、Ｃ１を再提示するように受取人を促すことができる。信頼できる機関１２は、無制限の回数の再試行を許可することもできるし、あるいは試行が所定回数失敗した後に受取人がＣ１を再提示することを妨げることもできる。次に、ステップ５８２で、信頼できる機関１２はＣ２を受取人に伝え、受取人は、その後、Ｃ２を支払人に伝えることができる。

ステップ５８４で、信頼できる機関１２は、自分が支払人からＣ２提示を受け取っているか否かを判定する。受け取っていなければ、信頼できる機関は待ち続ける。しかし、信頼できる機関がＣ２提示を受け取ると、ステップ５８６で、信頼できる機関１２は、その提示されたＣ２が有効か否かを判定する。例えば、信頼できる機関１２は、支払人により提供された追加のデータが正しければ（例えば、価値の説明および量、意図された受取人など）、提示されたＣ２が依然としてオープンであるか否かを判定するためにコードデータベース２８を検索することができる。提示されたＣ２が有効でなければ、ステップ５８８で、信頼できる機関１２はエラーメッセージを表示し、Ｃ２を再提示するように支払人を促すことができる。信頼できる機関１２は、無制限の回数の再試行を許可することもできるし、あるいは試行が所定回数失敗した後に支払人がＣ２を再提示することを妨げることもできる。

信頼できる機関１２が提示されたＣ２が有効であると判定したならば、ステップ５９０で、信頼できる機関１２は、コードデータベース２８からＣ２と関連付けられた価値を判定する。次に、ステップ５９２で、信頼できる機関は、関連付けられた価値を支払人のＴＡ口座から引き落とす。ステップ５９４で、信頼できる機関１２はＣ１およびＣ２を無効にする。例えば、信頼できる機関１２は、コードデータベース２８においてＣ１およびＣ２を「閉じられた」とマーク付けすることができ、口座データベース２６においてＣ１を支払人のＴＡ口座から、またＣ２を受取人のＴＡ口座から削除することができる。最後に、ステップ５９６で、信頼できる機関１２は、口座データベース２６において、関連付けられた価値を受取人のＴＡ口座に振り込む。

次に、図４４Ａ〜４４Ｂを参照すると、ＲＩコードを処理するために信頼できる機関１２により実行される代表的なプロセス６００が記述されている。ステップ６０２から始まって、信頼できる機関１２は、指定された価値のためのＲＩコードについて受取人から請求を受け取る。次に、ステップ６０４で、信頼できる機関１２は１対のＲＩコード（例えば、ＣＩ１およびＣＩ２）を生成する。次に、ステップ６０６で、信頼できる機関１２は、指定された価値を、ステップ６０４で生成されたＣＩ１およびＣＩ２と関連付ける。ステップ６０８で、信頼できる機関１２は、ＣＩ１およびＣＩ２ならびにこれらと関連付けられた価値をオープンコードとしてコードデータベース２８に記録する。次に、ステップ６１０で、信頼できる機関１２はＣＩ１を受取人に伝え、受取人は、その後、ＣＩ１を支払人に伝えることができる。

ステップ６１２で、信頼できる機関１２は、自分が支払人からＣＩ１提示を受け取っているか否かを判定する。受け取っていなければ、信頼できる機関は待ち続ける。しかし、信頼できる機関がＣＩ１提示を受け取ると、ステップ６１４で、信頼できる機関１２は、提示されたＣＩ１が有効か否かを判定する。例えば、信頼できる機関１２は、支払人により提供された追加データが正しければ（例えば、価値の説明および量、意図された受取人など）、提示されたＣＩ１が依然としてオープンであるか否かを判定するためにコードデータベース２８を検索することができる。提示されたＣＩ１が有効でなければ、ステップ６１６で、信頼できる機関１２は、エラーメッセージを表示し、ＣＩ１を再提示するように支払人を促すことができる。信頼できる機関１２は、無制限の回数の再試行を許可することもできるし、あるいは試行が所定回数失敗した後に支払人がＣＩ１を再提示することを妨げることもできる。

次に、ステップ６１８で、信頼できる機関１２は、コードデータベース２８からＣＩ１と関連付けられた価値を判定する。ステップ６２０で、信頼できる機関１２は、指定された価値を引き出すために支払人のＴＡ口座から入手可能か否かを判定する。入手可能でなければ、ステップ６２２でエラーメッセージが支払人に表示され、プロセスを終了することができる。そうでなければ、プロセスはステップ６２４に進み、信頼できる機関１２はＣＩ２を支払人に伝え、支払人は、その後、ＣＩ２を受取人に伝える。

ステップ６２６で、信頼できる機関１２は、自分が受取人からＣＩ２提示を受け取っているか否かを判定する。受け取っていなければ、信頼できる機関は待ち続ける。しかし、信頼できる機関がＣＩ２提示を受け取ると、ステップ６２８で、信頼できる機関１２は、提示されたＣＩ２が有効か否かを判定する。例えば、信頼できる機関１２は、受取人により提供された追加のデータが正しければ（例えば、価値の説明および量、意図された受取人など）、提示されたＣＩ２が依然としてオープンであるか否かを判定するためにコードデータベース２８を検索することができる。提示されたＣＩ２が有効でなければ、ステップ６３０で、信頼できる機関１２はエラーメッセージを表示し、ＣＩ２を再提示するように受取人を促すことができる。信頼できる機関１２は、無制限の回数の再試行を許可することもできるし、あるいは試行が所定回数失敗した後に受取人がＣＩ２を再提示することを妨げることもできる。

信頼できる機関１２が提示されたＣＩ２が有効であると判定したならば、ステップ６３２で信頼できる機関１２は、コードデータベース２８からＣＩ２と関連付けられた価値を判定する。次に、ステップ６３４で、信頼できる機関は、関連付けられた価値を支払人のＴＡ口座から引き落とす。ステップ６３６で、信頼できる機関１２はＣＩ１およびＣＩ２を無効にする。例えば、信頼できる機関１２は、コードデータベース２８においてＣＩ１およびＣＩ２を「閉じられた」とマーク付けすることができ、口座データベース２６においてＣＩ１を受取人のＴＡ口座から、またＣＩ２を支払人のＴＡ口座から削除することができる。最後に、ステップ６３８で、信頼できる機関１２は、口座データベース２６において、関連付けられた価値を受取人のＴＡ口座に振り込む。

支払人および受取人の両方が同じ価値についてリターンコードを実質的に同時に請求し、信頼できる機関がそれらの実質的に同時のリターンコード請求を付き合わせるというプロセスを含む、リターンコードを処理するための他のプロセスを信頼できる機関１２が使用し得るということが当業者であれば理解できるはずである。
当業者であれば、信頼できる機関により提供されるサービスのうちの１つ以上について信頼できる機関１２がユーザ１６に課金し得るということも理解できるはずである。例えば、信頼できる機関１２は、ＴＡ口座と外部口座との間で価値を移転すること、コードを請求すること、およびコードを提示することのうちの１つ以上についてユーザ１６に課金することができる。信頼できる機関１２は、価値ストア３０に蓄えられている価値の量および／またはタイプに応じて変動する料金をユーザ１６に課すことができ、かつ／または、コード請求および／または提示について、コードと関連付けられた価値の量および／またはタイプに応じて、ユーザ１６に料金を課すことができる。

前述した説明は、単に本発明の原理を説明しているのであって、本発明の範囲および趣旨から逸脱することなく種々の改変が当業者によってなされ得る。

Claims (64)

1. ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、ユーザ口座を含む口座データベースとを含む信頼できる機関を含むシステムであって、
   各ユーザ口座は、対応するユーザと関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを含み、
   前記信頼できる機関は、
   第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取り、
   実質的にランダムなコードを生成し、
   前記生成されたコードを前記第１の指定された価値と関連付け、
   前記生成されたコードを前記第１のユーザに伝え、
   前記生成されたコードを第２のユーザから受け取り、
   前記受け取られたコードが有効であるか否かを判定し、かつ
   前記受け取られたコードが有効であるならば、前記第１の指定された価値の所有権を前記第１のユーザから前記第２のユーザに移転するために前記第１の指定された価値を前記第１のユーザの口座から引き落として前記第１の指定された価値を前記第２のユーザの口座に振り込むように適合されるシステム。
2. 請求項１記載のシステムにおいて、
   前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含むシステム。
3. 請求項１記載のシステムにおいて、
   前記生成されたコードのリストを含むコードデータベースをさらに含むシステム。
4. 請求項３記載のシステムにおいて、
   前記受け取られたコードが有効であるならば、前記信頼できる機関は前記受け取られたコードを無効にするようにさらに適合されるシステム。
5. 請求項３記載のシステムにおいて、
   前記受け取られたコードの有効性を判定することは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含むシステム。
6. 請求項１記載のシステムにおいて、
   受け取ることは、前記関連付けられたコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記受け取られたコードの有効性を判定することは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含むシステム。
7. 請求項１記載のシステムにおいて、
   前記信頼できる機関は、前記第１のユーザの口座が前記第１の指定された価値を含むか否かを判定するようにさらに適合されるシステム。
8. 請求項７記載のシステムにおいて、
   前記信頼できる機関は、前記第１のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するシステム。
9. ユーザにより所有されている価値を蓄えるように適合される価値ストアと、ユーザ口座を含む口座データベースとを含む信頼できる機関を含むシステムであって、
   各ユーザ口座は、対応するユーザと関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを含み、
   前記信頼できる機関は、
   第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取り、
   実質的にランダムなコードを生成し、
   前記生成されたコードを前記第１の指定された価値と関連付け、
   前記関連付けられたコードを前記第１のユーザに伝え、
   前記関連付けられたコードを第２のユーザから受け取り、
   前記受け取られたコードが有効であるか否かを判定し、かつ
   前記受け取られたコードが有効であるならば、前記第１の指定された価値の所有権を前記第２のユーザから前記第１のユーザに移転するために前記第１の指定された価値を前記第２のユーザの口座から引き落として前記第１の指定された価値を前記第１のユーザの口座に振り込むように適合されるシステム。
10. 請求項９記載のシステムにおいて、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含むシステム。
11. 請求項９記載のシステムにおいて、
    前記生成されたコードのリストを含むコードデータベースをさらに含むシステム。
12. 請求項１１記載のシステムにおいて、
    前記受け取られたコードが有効であるならば、前記信頼できる機関は前記受け取られたコードを無効にするようにさらに適合されるシステム。
13. 請求項１１記載のシステムにおいて、
    前記受け取られたコードの有効性を判定することは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含むシステム。
14. 請求項９記載のシステムにおいて、
    受け取ることは、前記関連付けられたコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記受け取られたコードの有効性を判定することは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含むシステム。
15. 請求項９記載のシステムにおいて、
    前記信頼できる機関は、前記第２のユーザの口座が前記第１の指定された価値を含むか否かを判定するようにさらに適合されるシステム。
16. 請求項１５記載のシステムにおいて、
    前記信頼できる機関は、前記第２のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するシステム。
17. ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、ユーザ口座を含む口座データベースとを含む信頼できる機関を含むシステムであって、
    各ユーザ口座は、対応するユーザと関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを含み、
    前記信頼できる機関は、
    第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取り、
    第１および第２の実質的にランダムなコードを生成し、
    前記生成されたコードを前記第１の指定された価値と関連付け、
    前記第１のコードを前記第１のユーザに伝え、
    前記第１のコードを第２のユーザから受け取り、
    前記受け取られた第１のコードが有効であるか否かを判定し、
    前記第２のコードを前記第２のユーザに伝え、
    前記第２のコードを前記第１のユーザから受け取り、
    前記受け取られた第２のコードが有効であるか否かを判定し、かつ
    前記受け取られた第２のコードが有効であるならば、前記第１の指定された価値の所有権を前記第１のユーザから前記第２のユーザに移転するために前記第１の指定された価値を前記第１のユーザの口座から引き落として前記第１の指定された価値を前記第２のユーザの口座に振り込むように適合されるシステム。
18. 請求項１７記載のシステムにおいて、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含むシステム。
19. 請求項１７記載のシステムにおいて、
    前記生成されたコードのリストを含むコードデータベースをさらに含むシステム。
20. 請求項１９記載のシステムにおいて、
    前記受け取られた第１および第２のコードが有効であるならば、前記信頼できる機関は前記受け取られたコードを無効にするようにさらに適合されるシステム。
21. 請求項１９記載のシステムにおいて、
    前記受け取られたコードの有効性を判定することは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含むシステム。
22. 請求項１７記載のシステムにおいて、
    前記第１のコードを受け取ることは、前記第１のコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記第１のコードの有効性を判定することは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含むシステム。
23. 請求項１７記載のシステムにおいて、
    前記信頼できる機関は、前記第１のユーザの口座が前記第１の指定された価値を含むか否かを判定するようにさらに適合されるシステム。
24. 請求項２３記載のシステムにおいて、
    前記信頼できる機関は、前記第１のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するシステム。
25. ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、ユーザ口座を含む口座データベースとを含む信頼できる機関を含むシステムであって、
    各ユーザ口座は、対応するユーザと関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを含み、
    前記信頼できる機関は、
    第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取り、
    第１および第２の実質的にランダムなコードを生成し、
    前記生成されたコードを前記第１の指定された価値と関連付け、
    前記第１のコードを前記第１のユーザに伝え、
    前記第１のコードを第２のユーザから受け取り、
    前記受け取られた第１のコードが有効であるか否かを判定し、
    前記第２のコードを前記第２のユーザに伝え、
    前記第２のコードを前記第１のユーザから受け取り、
    前記受け取られた第２のコードが有効であるか否かを判定し、かつ
    前記受け取られた第２のコードが有効であるならば、前記第１の指定された価値の所有権を前記第２のユーザから前記第１のユーザに移転するために前記第１の指定された価値を前記第２のユーザの口座から引き落として前記第１の指定された価値を前記第１のユーザの口座に振り込むように適合されるシステム。
26. 請求項２５記載のシステムにおいて、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含むシステム。
27. 請求項２５記載のシステムにおいて、
    前記生成されたコードのリストを含むコードデータベースをさらに含むシステム。
28. 請求項２７記載のシステムにおいて、
    前記受け取られた第１および第２のコードが有効であるならば、前記信頼できる機関は前記受け取られたコードを無効にするようにさらに適合されるシステム。
29. 請求項２７記載のシステムにおいて、
    前記受け取られたコードの有効性を判定することは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含むシステム。
30. 請求項２５記載のシステムにおいて、
    前記第１のコードを受け取ることは、前記第１のコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記第１のコードの有効性を判定することは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含むシステム。
31. 請求項２５記載のシステムにおいて、
    前記信頼できる機関は、前記第２のユーザの口座が前記第１の指定された価値を含むか否かを判定するようにさらに適合されるシステム。
32. 請求項３１記載のシステムにおいて、
    前記信頼できる機関は、前記第２のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するシステム。
33. 方法であって、
    ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、対応するユーザと各々関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを各々含むユーザ口座を含む口座データベースとを設けるステップと、
    第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取るステップと、
    実質的にランダムなコードを生成するステップと、
    前記生成されたコードを前記第１の指定された価値と関連付けるステップと、
    前記生成されたコードを前記第１のユーザに伝えるステップと、
    前記生成されたコードを第２のユーザから受け取るステップと、
    前記受け取られたコードが有効であるか否かを判定するステップと、
    前記受け取られたコードが有効であるならば、前記第１の指定された価値の所有権を前記第１のユーザから前記第２のユーザに移転するために前記第１の指定された価値を前記第１のユーザの口座から引き落として前記第１の指定された価値を前記第２のユーザの口座に振り込むステップと、
    を含む方法。
34. 請求項３３記載の方法において、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含む方法。
35. 請求項３３記載の方法において、
    前記生成されたコードのリストを含むコードデータベースを設けるステップをさらに含む方法。
36. 請求項３５記載の方法において、
    前記受け取られたコードが有効であるならば、前記受け取られたコードを無効にする方法。
37. 請求項３５記載の方法において、
    前記受け取られたコードの有効性を判定するステップは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含む方法。
38. 請求項３３記載の方法において、
    前記受け取るステップは、前記関連付けられたコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記受け取られたコードの有効性を判定するステップは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含む方法。
39. 請求項３３記載の方法において、
    前記第１のユーザの口座が前記第１の指定された価値を含むか否かを判定するステップをさらに含む方法。
40. 請求項３９記載の方法において、
    前記第１のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するステップをさらに含む方法。
41. 方法であって、
    ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、対応するユーザと各々関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを各々含むユーザ口座を含む口座データベースとを含む信頼できる機関を設けるステップと、
    第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取るステップと、
    実質的にランダムなコードを生成するステップと、
    前記生成されたコードを前記第１の指定された価値と関連付けるステップと、
    前記関連付けられたコードを前記第１のユーザに伝えるステップと、
    前記関連付けられたコードを第２のユーザから受け取るステップと、
    前記受け取られたコードが有効であるか否かを判定するステップと、
    前記受け取られたコードが有効であるならば、前記第１の指定された価値の所有権を前記第２のユーザから前記第１のユーザに移転するために前記第１の指定された価値を前記第２のユーザの口座から引き落として前記第１の指定された価値を前記第１のユーザの口座に振り込むステップと、
    を含む方法。
42. 請求項４１記載の方法において、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含む方法。
43. 請求項４１記載の方法において、
    前記生成されたコードのリストを含むコードデータベースを設けるステップをさらに含む方法。
44. 請求項４３記載の方法において、
    前記受け取られたコードが有効であるならば、前記受け取られたコードを無効にする方法。
45. 請求項４３記載の方法において、
    前記受け取られたコードの有効性を判定するステップは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含む方法。
46. 請求項４１記載の方法において、
    前記受け取るステップは、前記関連付けられたコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記受け取られたコードの有効性を判定するステップは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含む方法。
47. 請求項４１記載の方法において、
    前記第２のユーザの口座が前記第１の指定された価値を含むか否かを判定するステップをさらに含む方法。
48. 請求項４７記載の方法において、
    前記第２のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するステップをさらに含む方法。
49. 方法であって、
    ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、対応するユーザと各々関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを各々含むユーザ口座を含む口座データベースとを含む信頼できる機関を設けるステップと、
    第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取るステップと、
    第１および第２の実質的にランダムなコードを生成するステップと、
    前記生成されたコードを前記第１の指定された価値と関連付けるステップと、
    前記第１のコードを前記第１のユーザに伝えるステップと、
    前記第１のコードを第２のユーザから受け取るステップと、
    前記受け取られた第１のコードが有効であるか否かを判定するステップと、
    前記第２のコードを前記第２のユーザに伝えるステップと、
    前記第２のコードを前記第１のユーザから受け取るステップと、
    前記受け取られた第２のコードが有効であるか否かを判定するステップと、
    前記受け取られた第２のコードが有効であるならば、前記第１の指定された価値の所有権を前記第１のユーザから前記第２のユーザに移転するために前記第１の指定された価値を前記第１のユーザの口座から引き落として前記第１の指定された価値を前記第２のユーザの口座に振り込むステップと、
    を含む方法。
50. 請求項４９記載の方法において、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含む方法。
51. 請求項４９記載の方法において、
    前記生成されたコードのリストを含むコードデータベースを設けるステップをさらに含む方法。
52. 請求項５１記載の方法において、
    前記受け取られた第１および第２のコードが有効であるならば、前記受け取られたコードを無効にする方法。
53. 請求項５１記載の方法において、
    前記受け取られたコードの有効性を判定するステップは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含む方法。
54. 請求項４９記載の方法において、
    前記第１のコードを受け取るステップは、前記第１のコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記第１のコードの有効性を判定するステップは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含む方法。
55. 請求項４９記載の方法において、
    前記第１のユーザの口座が前記第１の指定された価値を含むか否かを判定するステップをさらに含む方法。
56. 請求項５５記載の方法において、
    前記第１のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するステップをさらに含む方法。
57. 方法であって、
    ユーザにより所有されている価値を蓄えるように適合されている価値ストアと、対応するユーザと各々関連付けられていると共に前記対応するユーザにより所有されている前記蓄えられている価値のリストを各々含むユーザ口座を含む口座データベースとを含む信頼できる機関を設けるステップと、
    第１の指定された価値と関連付けられるべきコードについての請求を第１のユーザから受け取るステップと、
    第１および第２の実質的にランダムなコードを生成するステップと、
    前記生成されたコードを前記第１の指定された価値と関連付けるステップと、
    前記第１のコードを前記第１のユーザに伝えるステップと、
    前記第１のコードを第２のユーザから受け取るステップと、
    前記受け取られた第１のコードが有効であるか否かを判定するステップと、
    前記第２のコードを前記第２のユーザに伝えるステップと、
    前記第２のコードを前記第１のユーザから受け取るステップと、
    前記受け取られた第２のコードが有効であるか否かを判定するステップと、
    前記受け取られた第２のコードが有効であるならば、前記第１の指定された価値の所有権を前記第２のユーザから前記第１のユーザに移転するために前記第１の指定された価値を前記第２のユーザの口座から引き落として前記第１の指定された価値を前記第１のユーザの口座に振り込むステップと、
    を含む方法。
58. 請求項５７記載の方法において、
    前記蓄えられている価値は、通貨、商品および／またはサービスのうちのいずれかを含む方法。
59. 請求項５７記載の方法において、
    前記生成されたコードのリストを含むコードデータベースを設けるステップをさらに含む方法。
60. 請求項５９記載の方法において、
    前記受け取られた第１および第２のコードが有効であるならば、前記受け取られたコードを無効にする方法。
61. 請求項５９記載の方法において、
    前記受け取られたコードの有効性を判定するステップは、前記受け取られたコードが前記コードデータベースの中にあるか否かを判定することを含む方法。
62. 請求項５７記載の方法において、
    前記第１のコードを受け取るステップは、前記第１のコードと第２の指定された価値とを前記第２のユーザから受け取ることをさらに含み、前記第１のコードの有効性を判定するステップは、前記第２の価値が前記第１の価値と等しいか否かを判定することを含む方法。
63. 請求項５７記載の方法において、
    前記第２のユーザの口座が前記第１の指定された価値を含むか否かを判定するステップをさらに含む方法。
64. 請求項６３記載の方法において、
    前記第２のユーザの口座が前記第１の指定された価値を含む場合に限って引き落としおよび振り込みを実行するステップをさらに含む方法。

Images