JP2009048627A

JP2009048627A - 委任されたトランザクションを実行するための方法及び装置

Info

Publication number: JP2009048627A
Application number: JP2008193288A
Authority: JP
Inventors: Christopher Soghoian; クリストファー・ソグホイアン; Imad Aad; イマード・アード
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2007-07-27
Filing date: 2008-07-28
Publication date: 2009-03-05
Also published as: US20090198617A1; CN101388095A; EP2026266B1; DE602007012538D1; EP2026266A1

Abstract

【課題】第三者が委任された支払いを行うか又は委任されたトランザクションの安全な実行を可能とする仕組みを提供する。
【解決手段】ユーザのために第三者がトランザクションを実行することを該ユーザにより可能とするコンピュータ実行可能な方法は、トークンを生成するステップと、
ある暗号化方法を用いてトークンを暗号化して、暗号化されたトークンを生成するステップと、
暗号化されたトークンをユーザから第三者へ転送して、第三者に対し、トークンにより指定されたユーザの口座のために、トランザクション定義において定められているようにトランザクションを定めることを許可するステップ（１００）と
を含む。
【選択図】図１

Description

本発明は、委任されたトランザクションを実行するための方法及び装置に関する。

従来の決済システムは、ユーザがタスクを委任するものに対してそのユーザが大きな信頼を置くことを必要とする。両親は、彼らの大学生の年代の子供が酒席の飲食物に金を使っているかどうかは確信できない。従業員及びコックは、週の予算で低品質の食品を購入して、その金を自分達のために節約することを選ぶことがある。会社は、移動中の従業員がどのように日当の予算を使っているか確信できない。近くに銀行サービスがない途上国の遠隔地域の人々は、時間にして数時間離れたＡＴＭへ移動する友人や家族に自分のＡＴＭカードやＰＩＮ番号を預ける必要があり、適度の額が引き出されるのを希望する一方で、口座から許される最大限の現金をその友人が引き出さないことを信用する必要がある。ＰＩＮ及びパスワードを共有することは、夫婦間や地方の人々にとって一般的であるが、銀行のポリシーはこの実態を反映していない。銀行詐欺に関する多くの規則は、顧客が自己のログイン情報を他人と共有していない場合にのみ、銀行が詐欺に対して責任があるとしている。このため、ユーザが自己の口座認証情報を、信頼している友人と共有する場合には、詐欺が後で全く見知らぬ人によって行われた場合でも、ユーザは詐欺に対する全ての法的責任による保護を失うことになる。

従って、「委任された支払い」を可能とする場合、すなわち第１の人が何らかの許可手順により完全な制御をその人に行わせることなく、その人に代わって支払又はトランザクションの実行を許可する場合には、セキュリティについての困難な問題がある。

以下に、この「委任された支払い」、すなわち委任されたトランザクションを実行するための従来の仕組みを説明する。

現金：
最も簡単な従来のスキームであり、このスキームには誰かに現金を与えて、買える物と買えない物について教えることが含まれる。このシステムのセキュリティは、完全に信頼に依存する。支払う人は、委任された者が現金を持って逃げ出すか、又は質の悪い商品を購入して本物の商品として渡すことを企てるかどうかを知る方法がない。

クレジットカード：
多くの会社において、従業員に会社のクレジットカードを与える習慣は、極めて一般的である。このシステムは、かなり大きな割合で信用も含んでいる。購入された個々のアイテムに関する情報は、販売者（merchant）によりクレジットカード会社へ送られることはないため、会社にはどのアイテムを従業員が購入したかを知るための信頼できる方法がない。彼らは紙のレシートを信用しなければならず、そのレシートは事後的に偽造することができる。不正な従業員がカードを好き勝手に使用する危険も存在する。

返済：
会社における一般的な別の方法によれば、従業員が全ての出費を自分の資金で支払い、レシートを集め、そして後で経費報告書を提出することを要求している。このシステムには、多くの弱点がある。従業員は、雇用者に対して本質的に作っているローンについて不満を持つことが多い。長引く出張又は正当な大口の買い物は、雇用者に金銭的な問題を生じさせる可能性がある。従業員がレシートを偽造する可能性もある。

これらの従来の解決策とは別に、電子的なアプローチ、例えば電子的な支払い、安全な支払い又は無記名の支払いを扱う解決策がある。しかしながら、これらの全ての解決策では、第２の人が委任された支払い又はトランザクションを実行することを第１の人が許可する「委任された支払い」に対して、安全で効率的な仕組みを提供できない。

従って、本発明の目的は、第三者が（口座からの引き出しなどの）委任された支払いを行うか又は委任されたトランザクションの安全な実行を可能とする仕組みを提供することである。

一実施形態によれば、あるユーザの口座を特定する口座識別子と、該ユーザ及び銀行だけが知っている秘密許可識別子であって、該ユーザの口座に対応する秘密許可識別子と、実行されるトランザクションの種類を定めるトランザクション定義とに少なくとも基づいてトークンを生成するステップと、
ある暗号化方法を用いて前記トークンを暗号化して、暗号化されたトークンを生成するステップであって、前記暗号化方法は予め定められており、前記銀行が知っていて、該銀行により逆に実行されるか又は繰り返して行われるものである、ステップと、
暗号化されたトークンを前記ユーザから前記第三者へ転送して、前記トークンにより指定された前記ユーザの口座のために、前記トランザクション定義において定められているようにトランザクションを定めることを前記第三者に許可するステップであって、ここで、前記トランザクションを実行するために、前記トークンにより指定された口座が属する銀行へ前記トークンが転送され、前記口座に対応する前記秘密許可識別子の正当性が検証できるか否かに応じて、前記ユーザの口座に対し前記トランザクションを許可又は拒否するために、前記銀行が前記トークンの逆暗号化を実行するか又は前記銀行が再アセンブルする暗号化されていないトークンの暗号化を繰り返して行うことにより前記トークンの信頼性を検証する、ステップと
を含む、ユーザのために第三者がトランザクションを実行することを該ユーザにより可能とするコンピュータ実行可能な方法が提供される。

これにより、簡単で効率的かつ安全な委任支払いの実行が可能となる。

１つの実施形態によれば、前記トークンの暗号化は、
前記トークンで指定された口座が属する銀行の公開鍵を用いて前記トークンを暗号化するステップと、
ハッシュアルゴリズムを前記トークンに適用して、前記トークンに基づくハッシュ値を得るステップと
のうちの１つを含む。

銀行の公開鍵を用いることにより、安全な暗号化が保証される。ハッシュアルゴリズムを用いることにより、トークンを暗号化したバージョンの複雑度が低減するため、たとえ手作業でも、それを例えば管理人、又はそれを銀行に送信する装置（ＡＴＭ装置など）へ転送することができる。

１つの実施形態によれば、この方法は、
販売者に支払うために、暗号化されたトークンを前記第三者から販売者へ転送するステップと、
検証結果に応じて前記トランザクションを許可又は拒否するために、暗号化されたトークンを前記販売者から検証を行う前記銀行へ転送するステップと
をさらに含む。

この方法においては、第三者（代理人）と販売者との間のトランザクションが、トークンを発行したユーザによって適切に許可されているかどうかを確認することができる。

１つの実施形態によれば、この方法は、
ユーザのために第三者が購入するアイテムの識別子のリストを含めるステップと、
購入するアイテムの識別子を販売者から銀行へ送信するステップと、
販売者が送信したアイテムの識別子が暗号化されたトークン内に含まれる場合にのみ、トランザクションが銀行によって許可されるステップと
をさらに含む。

これにより、どの種類のトランザクション（どのアイテム）にトークンを使用すべきかをユーザが更に指定できるようになる。

１つの実施形態によれば、この方法は、
第三者がユーザのために購入するアイテムを特定する識別子のリストを含めるステップであって、識別子はそれぞれ乱数に関連付けられ、ハッシュされるものである、ステップと、
購入される１つ以上のアイテムのハッシュ値を第三者から販売者へ送信するとともに販売者から銀行へ送信するステップと、
販売者が送信した１つ以上のハッシュ値が暗号化されたトークン内に含まれる場合にのみ、銀行がトランザクションを許可するステップと
をさらに含む。

これにより、購入されたアイテムを銀行にはわからない状態にすることができる。さらに、この方法におけるトランザクションは分割することができる。

１つの実施形態によれば、この方法は、
ユーザのために第三者が購入するアイテムを特定する識別子のリストを含めるステップであって、識別子はそれぞれ乱数に関連付けられ、ハッシュされるものである、ステップと、
使用される１つ以上のハッシュ関数及び購入する１つ以上のアイテムの（ハッシュされる）識別子及び識別子に対応する乱数を第三者から販売者へ送信するステップと、
購入される１つ以上のアイテムの識別子及び対応する乱数に基づいてハッシュ値を計算して、このハッシュ値を販売者から銀行へ送信するステップと、
販売者が送信した１つ以上のハッシュ値が暗号化されたトークン内に含まれる場合にのみ、銀行がトランザクションを許可するステップと
をさらに含む。

１つの実施形態では、ユーザ（アリス）がハッシュを計算し、別の実施形態では、販売者がそれを行う。最初の問題は、管理人がトマトを買ったとき、同じ金額のジャガイモのハッシュされたアイテムを送ることである。第２の問題は、各銀行によって使用されるハッシュ関数が何であるかを販売者は知らないことである。このため、１つの実施形態では、管理人はアイテムと乱数を販売者へ送り、販売者は次に標準化された関数（暗号化の場合と同様）を用いてハッシュを計算する。標準化されたハッシュ関数は幾つかあるため、管理人はアイテム、それらのｒ＿ｉ及び全てのアイテムに対して使用されるハッシュ関数を送る。

この実施形態によれば、購入するアイテムを銀行には知られない状態にすることができる。さらに、この方法のトランザクションは、分割することができる。その上、管理人が購入したアイテムの正しい識別子及びランダム値を販売者へ実際に送信し、購入されないアイテムについては送信しないようにすることができる。

１つの実施形態によれば、前記トークンは、
第三者の識別子と、
トークンの識別子と、
タイムスタンプと、
１つ以上のトランザクション選択肢と、
トークンを用いて使われる最高の金額と、
買い物リストにおける個々のアイテムに対するそれぞれの最高価格と
のうちの１つ以上をさらに含む。

１つの実施形態によれば、この方法は、
銀行があるトークンを用いて実行したトランザクションを記録するステップと、
使用された額をトークンから差し引いて、トークンの残りのクレジットを得るステップと、
実行する新たなトランザクションのそれぞれについて、トークンがこのトランザクションを実行するための十分なクレジットをなお有しているかどうかを確認するステップと
をさらに含む。

これにより、二重の出費を防ぐことができ、さらにトークンで指定された合計金額よりも多くの金が使われることを回避できる。

１つの実施形態によれば、この方法は、
前記トークンには、第三者の識別子に代えて、ユーザの識別子又はユーザにしか知られていないユニークなコード又はパスワードが含まれ、これによりユーザがトラベラーズチェックを自己に対して生成するステップをさらに含む。

この方法では、ユーザは簡単な方法で自己に対してトラベラーズチェックを発行することができる。

１つの実施形態によれば、あるユーザの口座を特定する口座識別子と、該ユーザ及び銀行だけが知っている秘密許可識別子であって、該ユーザの口座に対応する秘密許可識別子と、実行されるトランザクションの種類を定めるトランザクション定義とに少なくとも基づいてトークンを生成するモジュールと、
ある暗号化方法を用いて前記トークンを暗号化して、暗号化されたトークンを生成するモジュールであって、前記暗号化方法は予め定められており、前記銀行が知っていて、該銀行により逆に実行されるか又は繰り返して行われるものである、モジュールと、
暗号化されたトークンを前記ユーザから前記第三者へ転送するモジュールであって、これにより前記第三者が前記トークンにより指定された前記ユーザの口座のために、前記トランザクション定義で定められているようにトランザクションを定めることが許可され、ここで、前記トランザクションを実行するために、前記トークンにより指定された口座が属する銀行へ前記トークンが転送され、前記口座に対応する前記秘密許可識別子の正当性が検証できるか否かに応じて、前記ユーザの口座に対し前記トランザクションを許可又は拒否するために、前記銀行が前記トークンの逆暗号化を実行するか又は前記銀行により再アセンブルされる暗号化されていないトークンの暗号化を繰り返すことにより前記トークンの信頼性を検証する、モジュールと
を備える、ユーザにより、該ユーザのために第三者がトランザクションを実行することを可能とする装置が提供される。

１つの実施形態によれば、この装置は、本発明の一実施形態に基づく方法を実行するモジュールをさらに備える。

１つの実施形態によれば、本発明の一実施形態に基づく方法をコンピュータに実行させることができるコンピュータプログラムコードを含むコンピュータプログラムが提供される。

本発明の実施形態を説明する前に、下記の説明の中で使用する幾つかの用語について最初に説明する。
ＡＴＭ：現金自動預け払い機（Automated Teller Machine）又は自動トランザクション装置（Automatic Transaction Machine）
ＩＲ：赤外線
ＰＩＮ：個人識別番号
ＱＲコード：「クイックレスポンス」コード

安全な委任支払いを考える場合、このようなタスクを扱うセキュリティ技術の専門家は、暗号化や署名などの暗号作成の伝統的なツールを考える。例えば、セキュリティ技術の専門家が使おうとする１つの方法は、文書に署名することであろう。例えば、第三者に例えば買い物リストを含む文書を手渡して、この文書を作成したユーザの秘密鍵を用いてこの文書に署名することを考える。これにより、文書が署名したユーザによって許可された（及び作成された）ことが確実となり、またユーザの公開鍵を用いて販売者又は銀行はこの文書の信頼性を証明できる。しかしながら、このことは、銀行及びユーザにとって付加的な要件又はオーバーヘッドをもたらし、後で詳細に説明するように、例えば銀行又は販売者は文書の作成者の公開鍵を利用可能とする必要があり、潜在的な購入者の数（単に通り過ぎる全ての人）を考えると、これは実現可能ではなく、少なくとも実用的でないと思われる。

このため、本発明の実施形態によれば、第三者に対して支払いすなわち口座から引き出すタスクを委任する安全な方法が提供される。１つの実施形態によれば、この第三者を特定することができ、あるいは必ずしも特定されない場合もある。１つの実施形態によれば、購入することができるアイテムを限定する手段が提供される。１つの実施形態によれば、システムは口座の所有者が自己の買い物リストを銀行と共有しなくても良いようにプライバシー保護を行っているが、許可されないアイテムが購入されるのを制限するために、銀行や販売者が通信する手段を提供する。さらに、１つの実施形態によれば、このスキームは、二重支払いの問題により損害を受けることはない。その上、１つの実施形態では、販売者は、顧客の名前又は銀行口座の詳細を知ることはない。１つの実施形態によれば、消費者が前もって指定することなく、オーダーが複数の販売者によって部分的に満たされることを許可する。しかしながら、１つの実施形態によれば、消費者は委任されたパーティーがアイテムを受け取ることを制限すること、また希望する場合には、販売者がこれらのアイテムの販売を許可されることを制限することが可能である。

１つの実施形態では、この方法による銀行、販売者及びユーザに対する要件は最小である。ユーザ（アリス）は、銀行の公開鍵を用いて、全て暗号化された銀行の口座番号、ＰＩＮ、買い物リスト及び第三者のＩＤ（管理人（concierge））から成るトランザクショントークンを作る。買うアイテムをハッシュして、買い物リストを銀行に対して秘密にしておくことができる。この解決策は、アリスの身元を販売者及び管理人に対して秘密にしておくこともできる。これはまた、管理人が委託された購入についてアリスの制御を強化する。ＡＴＭ装置からの現金の引き出し又は出張に対する会社の従業員への支払いを委託する場合にも、同じ仕組みを使用することができる。この仕組みは、詐欺、二重支払い又は窃盗に対して、従来の支払い方式よりも高いレベルのセキュリティレベルを備えている。

技術的には、この解決策は、従来の支払いシステムのインフラに対してほとんど変更を要求せずに、委任された支払い又は現金の引き出しに対して極めて高いレベルのセキュリティを提供する。実際に、この解決策は、ソフトウェアの変更が必要となるだけで、従来のハードウェアと共に使用することができる。

以下に、本発明の幾つかの実施形態を説明する。これに関して、ユーザと、ユーザの管理人（ユーザのために委任されたトランザクションを実行する第三者）と、１つ又は幾つかの販売者（ここでトランザクション又は支払いが実行される）と、ユーザの銀行とを含む実施例について最初に説明する。

全体の手順には、トークンの発生及びトランザクションを実行するためのトークンの使用が含まれる。このことは、以下詳細に説明する。

全体のプロセスが図１に概略的に示されている。

トークンがユーザによって生成され、管理人に送信される（ステップ１００）。次に、管理人は販売者のところに出向き、トークンで指定された１つ以上のアイテムを購入し、対応する情報を販売者へ送信する（ステップ１１０）。

トークンと、アイテムの識別子及びこれに対応するランダム値に基づいたハッシュ値とが、販売者から銀行へ送信され（ステップ１２０）、チェックされて、その結果に応じて、照合（verification）又は拒否が銀行から返されて、トランザクションが実行又は拒否される（ステップ１３０）。

トークンは、ユーザによって生成されるドキュメントであり、第三者（管理人）に引き渡されて、第三者がユーザのためにトランザクションを実行することが可能となる。これは、任意の方法、又はブルートゥース、ＭＭＳ、ＩＲなどの任意の適切な通信リンクを用いて行うことができる。「ユーザのためのトランザクション（Transaction on behalf of the user）」とは、トランザクションが金銭的にはユーザの利益又は不利益であることを意味し、そのためトークンは口座番号、ＩＢＡＮなどのユーザの口座を特定するための識別子を含んでいる。これはさらに、発行者及び銀行のみに知られていて、かつ、ユーザが自己の口座から引き落とすことを許可したことを証明する秘密の「許可識別子」をさらに含んでいる。そうでない場合は、ユーザの口座番号を知っているどのような第三者もトークンを発行することができることになる。このような許可識別子は、例えばユーザのＰＩＮ又はキーワード、又は口座識別子により銀行の口座識別子に対する許可を証明する任意の他のコードとすることができる。

その上、トークンは、実行されるトランザクションの種類を特定又は定義するトランザクション定義を含む必要がある。これは例えば、（第三者がここで金を使うこと又はユーザの口座から引き出すことが許される）金額とするか、又は後で詳細に説明するように、買い物リストなどのより複雑なトランザクション定義とすることができる。

口座識別子、許可識別子及びトランザクション定義に基づいて、例えばこの情報を単に連結することによって構成される。この方法では、トークンは、使用するユーザのために発行されるか又は第三者がユーザのために「使用する」一種の「バウチャー」又は「チェック」である。しかしながら、許可識別子などのトークンを作るための秘密情報が詐欺グループによって不正に使用されるのを避けるために、トークンは保護されない状態で配信されることはない。このため、トークンは、ユーザの口座が属する銀行に特有な所定の暗号化方式を用いて暗号化される。例えば、銀行の公開鍵を用いてトークンを暗号化することができる。別の方法では、銀行と事前に合意したハッシュアルゴリズムを用いてトークンをハッシュすることができる。

その結果、このように暗号化されたトークンを受け取る銀行が、トランザクションが行われる口座を特定可能となり（これにより、発行者も特定する）、またさらに（トークンに含まれたＰＩＮ又は許可識別子を介して）発行者が許可したことを銀行が検証できることとなる。銀行の公開鍵によって暗号化が行われた場合は、銀行は直ぐにトークンを復号化し、保護なしの状態の情報を得る。暗号化がハッシュアルゴリズムによって行われた場合は、銀行は（暗号化されていない）トークンを再アセンブルし、またそれをハッシュして、受け取っているハッシュされたバージョンと結果が一致するかどうかを調べる。一致している場合、許可が検証され、トランザクションを実行することができる。この場合、十分な情報をクリアな状態で銀行に送信する必要があることは明らかであり、銀行はそれがトークンを暗号化される前に生成されるように再アセンブルできるようにする。すなわち、口座番号（又はトークンの発行者を特定する何らかの他の識別子）及びトランザクション定義を銀行へクリアな状態で送る必要があり、銀行はその後トークンを再アセンブル及びハッシュして、トランザクションを検証又は拒否することができる。

上記によれば、委任された支払いには、
（暗号化されていない）トークンをアセンブルするステップと、
トークンを暗号化するステップと、
トークンを第三者（管理人）に転送するステップと、
トランザクションを実行するステップとが含まれる。

トランザクションの実行には、管理人から直接銀行へのトークンの転送、又は管理人から販売者へ、次に販売者から銀行へのトークンの転送のいずれかが含まれる。次に、銀行はトークンの信頼性を検証し、そしてトランザクションを許可する。このトランザクションには、ユーザの口座から現金を管理人又は販売者のいずれかへ送るステップが含まれる。

実施形態によるトークンの作成及びその暗号化は、ＰＣ又は携帯電話又はトークンのアセンブル及び暗号化を実行できる十分な機能を有する任意の他の装置上で、コンピュータ実行による形式で行われる。装置がトークンを作成できるようにするために、トークンの作成を支援し、またユーザが必要な情報、例えば口座の選択や許可識別子及びトランザクション定義の入力を行うことができるグラフィックインターフェースを装置が提供することが好ましい。

トークンは任意の適当な方法で（例えば、ブルートゥース又はインターネットなどの任意の通信リンクを介して、又はＵＳＢスティックなどのメモリ装置又は任意の通信手段を介して）管理人（又は、図１でステップ１００として示されているように、そのコンピュータ又は記憶装置又はモバイルデバイス）へ転送され、この管理人は次にトークンを銀行又は販売者へ送信する（図１でステップ１１０として示されている）。この送信に関してはまた、図１でステップ１１０として示されているように、任意の適当な通信手段を使用することができる。

販売者から銀行への送信について、典型的な送信方法は従来のＡＴＭネットワーク又はインターネットであるが、任意の他の通信手段（ダイアルアップ接続など）も使用できる（図１でステップ１２０として示されている）。

発行人はトークンを印刷して、管理人に物理的に手渡すこともできる。次に、管理人はトークンを販売者に手渡す。販売者においては、銀行へ送信するために、トークンが販売者の装置に手作業でタイプされる（又はＯＣＲで読み取られる）。

しかしながら、トークンを電子的形態で送信することが好ましい。

典型的なトークンは、以下のものである。
{. . .Accnt#, PIN, Amount . . .}BankPubK

このようなトークンは、図２に概略的に例示されている。ここでフルストップ（full stop）は、トークンが、後に詳細に説明する付加的な情報を含むことを表す。

この方法には、既知の方法と比較して幾つかの利点がある。
・管理人の携帯電話が盗まれるか、又は印刷されたトークンを紛失した場合、Acct # 及び PINは明らかにならない。
・管理人に悪意がある場合、その管理人はaccount # 及び PINを盗むことはできない。
・販売者が自己のデータを失うか又はハックされた場合、顧客のAcct # 及び PINは安全に保護される。
・販売者は顧客の身元さえも知らない。
・多くの顧客が同じ管理人を使用する場合、若干の匿名性を得ることができる。１人の管理人を使用する顧客の数が多くなるにつれて、アノニミティセット（anonymity set）も大きくなる。この１つの実施例は、幾人かのユーザが使用する配送サービスである。
・顧客が自己のデータをブルートゥース、ＭＭＳ又はインターネットを介して管理人に送信する場合、（後で役立つようにある種のドロップボックス（drop-box）を用いて）管理人からは見えないようにすることも可能である。

トランザクション定義は、前述したように、１つの実施形態によれば比較的単純であり、ユーザのために使用されるか又はユーザの口座から引き出されることが許可された金額だけを含むことができる。

さらに別の実施形態によれば、このトランザクション定義はさらに具体的であり、トランザクションを制限するため、又はトランザクションをより狭く定義するために使用できるさらに別の定義を含んでいる。

１つの実施形態によれば、例えばそれは、買い物リストに含まれるあらかじめ選択されたアイテムのみを購入するために、管理人の「権限」を制限する一種の「買い物リスト」を含むことができる。

このような買い物リストを含むトークンは、下記のように、トークン内にアイテムのリストを含むことができる。
{. . . (item_i) . . .}BankPubK

このようなトークンは、図３に概略的に示されている。

この方法では、トランザクションが、所定のアイテム又は何か別のものを買うために使用されるかどうかを確認することができる。

１つの実施形態によれば、個々のアイテムは乱数と関連付けられ（concatenate）、次にハッシュされる。このようなトークンは、例えば以下のようになる。
{. . . h(item_i, r_i ) . . .}BankPubK

こうしたトークンは、図４に概略的に示されている。

この方法では、購入されたアイテムは、銀行には知られないようにしておくことができる。このために、管理人は最初に買い物リストをクリアな状態で販売者に示し、そして販売者において利用可能なアイテムに対して、管理人は買い物リストの全てのアイテムitem_iに対して値h(item_i, r_i)を含む「ランダムリスト」から対応するハッシュ値h(item_i, r_i)を送信する。次に、これらの値は、販売者から、トークンの内容に対してそれらの値をクロスチェックする銀行へ転送される。

本発明のさらなる利点は、トランザクションをサブトランザクションに分割できることである。

さらに別の実施形態によれば、買い物リストに対応する「ランダムリスト」が作られ、このランダムリストには、買い物アイテムitem_i及び対応する乱数r_iが含まれる。１つの実施形態では、アイテム識別子item_iがこのリスト内で確認でき、かつ乱数から特定できる場合には、「買い物リスト」はこの「ランダムリスト」の単なる一部に過ぎない。

このリストはユーザから第三者（管理人）へ送信され、管理人は次に購入するアイテムについて、item_iとr_iを販売者に送信する。販売者（又は、言い換えると、販売者のコンピュータ装置）は、次に購入されるアイテムに対するハッシュ値h(item_i, r_i)を計算し、そしてh(item_i, r_i)を銀行に送信する。２つ以上のハッシュアルゴリズムを使用する場合は、リスト（又は別のメッセージ）は、使用されるハッシュアルゴリズムを特定するための識別子を含むことができる。

１つの実施形態によれば、管理人のＩＤは、特定の個人に対する管理人の役割を制限するためにトークンの中に含まれる。このようなトークンは、以下のように表される。
{. . .ConciergeID. . .}BankPubK

このようなトークンは、図５に概略的に示されている。

１つの実施形態によれば、トークンは二重支出を避けるために、トークン用識別子、例えばタイムスタンプ又はノンス（nonce）を含んでいる。このようなトークンは、下記のように表される。
{. . . T imestamp . . .}BankPubK

このようなトークンは、図６に概略的に示されている。

１つの実施形態によれば、トークンは、例えば所定の金額まで追加の支払いを許容する公開された選択肢を含んでいる。このようなトークンは、下記のように表される。
{. . . options . . .}BankPubK

このようなトークンは、図７に概略的に示されている。これらの選択肢は、「特定の支出によって最大の金額を超過することが許容できる」というような、トランザクションのさらに別の細目を定めることができる。このような選択肢は、個々のアイテムに対して定めることができる。これらの選択肢は、より正確な方法でトランザクションを定義するために想定できるさらなる仕様、制限又は別の方法を含むことができる。これらは、「１人部屋のみ」及び「２つ星以下のホテル部門」などを含むか、又は「食事にサラダが含まれる場合、食事の費用はある金額以上高くなる」という両親からの指定を含むことができる。

トランザクション及び選択肢のアイテム定義は、自由に指定できるが、１つの実施形態によれば、これらは、電子製品識別子又はバーコードとともに使用される電子製品コードのような、特に購入されるアイテムに対して所定のネーミング規則の方式を利用することもできる。後者のユニークな識別子により、トランザクション定義がより明確となり、かつ例えば発行人が意図したことに関する管理人及び販売者の側の不安が少なくなるが、この方法はこのような厳密なネーミング規則なしで実行することもでき、またユーザは意図した目的に対して十分に正確であると考える定義を自由に含めることができる。またこの定義により、管理人及び販売者は正しいアイテム又はサービスを特定できる。

１つの実施形態によれば、前述した選択肢では、結果として生まれたトークンの形式は以下のようになる。
{Accnt#, PIN, h(item_i, r_i), MaxAmount,ConciergeID, T imestamp, options }BankPubK

アイテムのリストitem_i,r_iと一緒にトークンを（平文の状態で）、以下のような幾つかの手段を用いてユーザから管理人へ送ることができる。
・紙に印刷された状態
・ブルートゥース又はＩＲで送信
・モバイル上に表示
・ＭＭＳを介した送信

販売者の商店において、管理人はトークンとアイテムリストを以下のような幾つかの手段で渡すことができる。
・リーダ（カメラ）（例えば、ＱＲコードの読み取り用）
・手作業によるタイプ（管理人がユーザのために金を引き出すＡＴＭの場合）
・ブルートゥース又はＩＲ
・ＭＭＳ

販売者は、実際に購入される（ハッシュされる）アイテムのリストh(item_i, r_i)と一緒にトークンを銀行へ渡す。銀行は、復号化されたトークン又はデータの比較に基づいて、支払いを承認又は拒否する。このデータは、銀行が販売者から受信し、次にトークンと比較するために銀行が暗号化した（例えば、ハッシュされた）データである。

以下に、種々の能力を有する様々なアタッカーの攻撃を防ぐ場合の、提案された実施形態の性能を説明する。

敵対者がシステムを攻撃する際に行うことができると想定されることを考慮した、多機能の敵対的なモデルを検討する。
１．悪質な管理人は、トランザクショントークン及び買い物リストを保存して後で見ることができる。管理人は、後日、トークン及びリストに対して修正及び再生を試み、これらを関係のない販売者に使用することを試みることができる。
２．悪質な販売者は、トランザクショントークン、買い物リスト、管理人のＩＤ及び前のトランザクションの際に与えられた他のデータを保存して後で見ることができる。この販売者は、後で関係のない銀行との間で換金することができる。
３．悪質な銀行は、トランザクショントークン及び販売者によって与えられた任意のデータを保存して後で見ることができる。
４．結託した管理人及び販売者は、上記敵対者１及び２の組合せである。管理人は、ユーザから搾取しようとするか又は買い物リストによって課せられた制約を免れようとして販売者と共謀する。
５．結託した販売者及び銀行は、上記敵対者２及び３の組合せである。この販売者及び銀行は、顧客の身元及び完全な買い物リストを明らかにしようと共謀する。
６．結託した管理人及び銀行は、上記敵対者１及び３の組合せである。この管理人及び銀行は、顧客の身元及び完全な買い物リストを明らかにしようと共謀する。

悪意の管理人：
このアタッカーには、選択肢はほとんどない。トランザクショントークンを修正、偽造又は再生するどのような試みも銀行によって検出されて拒否される。ユーザがトランザクショントークンを電子的に管理人へ送信した場合でも、管理人は顧客の身元を知ることはできない。管理人は顧客の口座番号及びＰＩＮを知ることはないため、後で不正なトークンを作ることはできない。顧客のアノニミティセットは、１人の管理人（又は配送サービス）を使用する顧客の数が増加するにつれて増加する。かなりユニークなアイテムを購入する顧客は幾つかの情報を明らかにし、例え顧客の本当の身元が依然として不明であっても、複数のトランザクションのリンクが可能となる。

悪意の販売者：
この敵対する状況には、不正を働く販売者と、販売者の従業員が顧客の記録を誤用するか又は盗むといった内部アタックを含む状態との両方が含まれる。販売者は顧客の名前又は口座情報を知らないため、販売者のコンピュータシステムにいかなるシステム侵入又はデータ喪失があっても、顧客の口座番号の喪失が生じることはない。販売者が有する顧客の唯一のリンクは管理人であり、このことは、顧客が管理人と電子的に通信する場合はさらに弱くなる可能性がある。

悪意の銀行：
銀行は、顧客が各販売者において購入する個々のアイテムを知ることが制限されている。銀行は、全アイテムが幾つ買い物リストに載っているか、リストから幾つのアイテムが各販売者において購入されたか、また全トランザクションの金額はいくらだったかを知ることができるだけである。顧客は大きな買い物リストが小さなトランザクションに分割されると、自己の匿名性が減少する。これについての極端な事例は、管理人が１つのアイテムを幾つかの販売者からそれぞれ買う場合である。銀行はどのアイテムが購入されたかは分からないが、各トランザクションは１つのアイテムから構成されるという事実により、銀行は各アイテムの価格を知っている。銀行の代理人は、調べるために販売者の商店に後で出向いて、特別な価格で販売者が販売した全てのアイテムを見つけ出そうとすることができる。販売者は変動する価格設定によるかまたはトランザクションを分割しないことによって、この危険を減らすことができる。

結託した管理人及び販売者：
この、より進んだ敵対者は、買い物リスト上の制約を無効にすることができる。顧客は自己の買い物リストにリンゴを記載することができるが、管理人は代わりにオレンジを購入する。結託している販売者は管理人にオレンジを渡すが、銀行には買い物リストからリンゴのアイテムを購入したという売買報告書を送る。ユーザの買い物リストのプライバシーを銀行から保護することは、同時に、結託している販売者と管理人が買い物リストの制約を無視できない場合には不可能である。トランザクショントークン上に最大合計の上限があるため、少なくともユーザはより大きな不正使用から保護される。

結託した販売者及び銀行：
この進んだ敵対者は、買い物リストに関連するプライバシー保護を無効にすることができる。販売者は完全な買い物リストを銀行に対して明らかにすることができるため、ユーザがその販売者において購入した全てのアイテムの完全な記録を銀行が作ることを許可することができる。銀行は顧客の情報を販売者と共有することもできるため、ユーザのプライバシーを取り除くことができる。この状態では、販売者は顧客が誰であるかを知ることになり、また銀行は結託している販売者から顧客が購入する全てのアイテムを知ることになる。

結託した管理人及び銀行：
これは、上述の敵対者のより極端な実例である。結託した販売者及び銀行は、その特定の販売者に対してユーザのプライバシーを侵害することができるだけであるが、結託した管理人及び銀行は、全てのトランザクションに対してそうすることができる。従って、銀行はユーザが管理人を介して購入した全てのアイテムの完全なリストを作ることができる。ユーザがトランザクショントークンを電子的に送信することによって、自己の身元を管理人から隠そうとする場合には、この結託によりユーザの身元が明らかとなるであろう。銀行はユーザの身元を管理人に明らかにすることができ、一方、管理人は購入したアイテムの完全なリストを銀行に知らせることができる。

以下に、本発明の実施形態を、他の別の方式と比較する。

委任トランザクションを実行する方法を考えると、セキュリティ技術の専門家が考える方法は、ユーザの秘密鍵を用いることによって署名された資料又は買い物リストを使用することである。以下に、この方法と本発明の実施形態との比較について説明する。
・ユーザが販売者及び管理人から匿名性を保つために、ユーザは自己のＩＤ又は口座番号をハッシュして、買い物リストの中の平文に含めて、乱数を用いてＩＤのマッチングを防ぐ必要がある(h (Account #||r_i ), r_i )。銀行の側では、署名を検証する前にユーザを特定するために、銀行は全ての口座番号のハッシュを計算することによって、非常にコストの高い検索を行う必要がある。
・銀行は、全ての顧客に対して公開鍵又は秘密鍵を発行する必要がある。
・本発明の実施形態を用いると、ユーザは任意の装置（必ずしも、ユーザ自身の装置でなくてよい）を用いてトークンを作り出すこともできる。１つの実施形態によれば、これはユーザのＰＩＮを記憶することを含む。他方では、他人の装置を用いてリストに署名するために、ユーザは自己の完全な秘密鍵を記憶する必要がある。

電子マネーの分野では、すでにかなりの数の研究がなされている。なぜ本発明の実施形態が電子マネーシステムでないのか、またこのため、なぜ電子マネーの採用に関する多くの厄介な問題が本発明の実施形態に関係しないのかについて注意されたい。
・この方式は、保存された支払いトークンを含まない。トークンは、何らかの金銭的な損失なく紛失又は破壊されることがある。
・（消費者の電話、管理人の電話、又は印刷されたトークンの）偶発的な損失、窃盗又は事故の場合は、不正行為の危険性はない。
・これは電子財布ではない。
・委任されたトークンを誰かが使用できることを発行したユーザが指定しない限り、（ユーザＩＤがトークンの中に含まれる場合は）トークンは転送されない。
・トークンは約束手形（promiser note）ではない。これらは管理人に支払うためには使用できないが、管理人が顧客のために何かを購入できるようにする。消費者が、銀行が発行した信用限度を超えた場合は、例え他の部分が有効であっても、委任されたトークンは銀行によって拒否される。
・銀行は、トークンを発行する手順に含まれる必要がない。銀行は販売者によってトークンが与えられると、単にトランザクションを処理する。
・この方式は匿名ではない。販売者と銀行が結託している場合、又は政府発行の召喚状（subpoena）の場合は、アイテム及び口座トランザクションの完全なペーパートレールにアクセスすることができる。
・委任トークンを作る消費者、及びアイテムを購入する管理人は、オンラインで行う必要はない。銀行のシステムにアクセスすることなく、トークンを作ることができる。消費者はトークンを作成して、それを紙に印刷するか、又はブルートゥースもしくは電子的手段によって管理人に送ることができる。
・委任トランザクションは、必要な場合、例えば個々の販売者が必要な全てのアイテムを提供できない場合には、複数のトランザクションに分割することができる。トークンを作る消費者は、前もって販売者と連絡する必要はない、またどの販売者に管理人が訪れるかを知る必要もない。

提案された実施形態はさらに、関係する全ての関係者に関するプライバシーを守る。

管理人：
消費者のためにアイテムを購入する第三者（例えば、管理人）は、消費者の身元を知る必要はない。委任トークンが管理人に電子的に送信され、またアイテムをある種のドロップボックス（drop box）を介して配送することができると仮定すると、管理人は消費者と物理的にインタラクトする必要はなく、また会う必要もない。さらに、顧客の口座番号が暗号化されているため、管理人はこの口座番号を知ることはない。その結果、管理人が後でこの番号を特定又は再使用することは不可能である。

販売者：
販売者が物理的に消費者とインタラクトすることはない。販売者は委任トークンを介して消費者の名前を知る手段がないため、消費者が自己の身元を管理人から隠す場合は、（販売者が銀行と結託しない限り）誰が消費者かを知る方法はない。消費者の口座番号は委任トークンの中で暗号化されており、そのため販売者の会社内の内部窃盗犯は消費者の金銭的な詳細を盗むことができない。さらに、消費者が同じ管理人を使用し続けるにつれて、個々のトランザクションを同じ未知の消費者にリンクすることが極めて困難になる。基本的に、顧客のアノニミティセットは、１人の管理人を使用する顧客の数が増加するにつれて増加する。

銀行：
販売者は購入されたアイテムのハッシュのみを銀行に送るため、販売者と銀行とが結託してない限り、どのアイテムを顧客が購入したかを知る方法はない。銀行はどの販売者から顧客がアイテムを購入したか、トランザクションの金額はいくらか、また何個のアイテムが購入されたかを知っているだけである。

提案された実施形態を実行するためのシステムに関する要件は、比較的少なく、従来のインフラに対してかなりの変更を要求されない（実際には、ハードウェアの変更ではなくソフトウェアの変更のみが必要とされる）。このことは、詳細に以下説明する。

顧客：
本発明の実施形態を使用するために、顧客は携帯電話又はコンピュータのいずれかにアクセスする必要がある。顧客はこれらの装置を必ずしも所有する必要はない。多くの場合、顧客はそれらの装置に一時的にアクセスするだけで良い。装置をユーザが所有する場合、ユーザは自己の口座番号をその中に記憶させることができる。ユーザが誰か他の人から装置を借りる場合、ユーザは自己の口座番号を入力する方法を見つける必要がある。これは、例えば手作業（１６＋桁数を入力する）で、又は例えばユーザのカードの背面に印刷されたＱＲコードを読み取ることによって行うことができる。ユーザが管理人と行うことを希望する個人的なインタラクションのレベルに応じて、送信方法及び技術的な要件は異なる。電子メール、インスタントメッセージ、ブルートゥース、ＩＲ又はＭＭＳを用いて、トランザクショントークンを電子的に送信することができる。トークンを例えばＱＲコードとして示すことによって、紙に印刷することもできるため、管理人に対して印刷又はファックスのどちらかを行うことができる。

管理人：
トークンが電子的に管理人に送信された場合、管理人はそれを電子的な形式で（携帯電話又は何らかのコンピュータ装置を用いて）販売者に送るか、又は紙に印刷する必要がある。ユーザの装置の技術的な要件は、販売者が有する受信装置に依存する。

販売者：
販売者は、トランザクショントークンを読み取る手段を必要とする。例えば、最も基本的で相互に動作可能なレベルでは、販売者はＱＲコードを読み取ることができなければならない。電子的なトークンを受け入れるために、販売者は、ＭＭＳ、ブルートゥース又はＩＲ又は他の任意の通信手段のいずれかに対応する必要もある。これら全てのタスクは、例えばカメラが使用可能な基本的な電話を用いて実現できる。販売者の従来の請求書作成又は受領システムのより複雑な集積化により、付加的なハードウェアが必要となる。販売者はトランザクションを有効にするために、購入されたアイテムの暗号化されたトランザクショントークン及びハッシュを銀行に送信する手段も必要である。しかしながら、たいていの販売者はＡＴＭやクレジットカードのトランザクションを処理することができる電子送信システムをすでに所有している。１つの実施形態のトランザクショントークンシステムは、従来の金融トランザクション転送システム（financial transaction transfer system）に極めて容易にピギーバックすることができるか、又は任意の他の適当な送信手段を使用できる。

銀行：
銀行はすでにトランザクションの際、従来の金融ネットワーク上で販売者と通信するため、クレジットカード番号を検証することができる。提案された実施形態による方式は、銀行がトランザクショントークンを復号化し（又は、検証を可能にするために所定のハッシュ方式を用いて受信データをハッシュすることによって、それを再度生成する）、内容を検証し次にメッセージを販売者に送り返すことを付加的に要求している。二重の支出を阻止し、トランザクションを種々の販売者によってサービスされる複数のサブトランザクションに分割できるようにするために、銀行はその後かなりの期間にわたってトランザクショントークンの内容を常に把握し記憶する必要がある。

以下に、提案された実施形態に関する幾つかの典型的な応用例を説明する。

アリスは忙しい女性であるため、メイドに１週間分の食料品の買い物をしてもらっている。アリスは通常メイドに紙のリストを与え、また全てのアイテムの費用をカバーするに十分な金額をメイドに渡している。アリスは合計が正確にいくらになるか事前には分からないため、彼女はメイドに十分過ぎる金額を念のため与える必要がある。メイドの給料はあまり高くなく、アリスは、メイドが自分のためにアイテムに料金を対して支払って事後に払い戻しを求めることができるとは予想できない。この方式は、幾つかの理由により理想的ではない。すなわち、アリスはトランザクションの合計を知らないため、メイドが必要な金額よりも多くの金額をメイドに早めに渡す必要がある。メイドは町から逃げ出して、アリスの金を全て持ち去ることを決心する可能性がある。メイドはより低い品質のアイテムをどこかで買って、アリスに話さずに金を節約しておこうと決心するかも知れない。

アリスは最初に買い物リストを作成する。この買い物リストには、下記が含まれる。
ShoppingList = item₁||r₁, item₂||r₂, item₃||r₃, item₄||r₄
ここで、r_iは、ユーザが生成し、銀行には秘密にされる乱数である。

アリスは次に、下記のトランザクショントークンを作成する。
TransactionToken = {Accnt #, PIN, ts, MaxAmount, ConciergeID, n, h (item₁||r₁) . . . h (item₄||r₄ )}BankPubK
ここで、tsは二重支出を防止するために作られたタイムスタンプであり、nは辞書攻撃（dictionary attack）から守るために使用される無作為に生成された大きなノンスである。

下記のプロトコルは、メイドが１つの買い物リストを与えられたが、１箇所の商店で全てのアイテムを見つけることができない場合の見本のシナリオについて記述している。このため、彼女は２つのアイテムを１つの販売者から、そして別のアイテムを第２の販売者から購入する。
・アリス → メイド :
TransactionToken, ShoppingList
・メイド → 販売者1 :
TransactionToken, item₁ ||r₁, item₂ ||r₂, ConciergeID,
・販売者1 → 銀行 :
TransactionToken, h(item₁ ||r₁), h(item₂ ||r₂), TotalPrice1, ConciergeID
・銀行 → 販売者1 :
OkToPurchase : h(item₁ ||r₁),OkToPurchase : h(item₂ ||r₂), OkForPrice : TotalPrice1
・メイド → 販売者₂ :
TransactionToken, item₃ ||r₃, ConciergeID,
・販売者₂ → 銀行 :
h(item₃||r₃), TotalPrice₂, TransactionToken, ConciergeID
・銀行 → 販売者2 :
OkToPurchase : h(item₃ ||r₃), OkForPrice : TotalPrice₂

アリスが自己の買い物リストが要する金額を過小評価した場合、例えメイドが、有効で今なお未購入の買い物リスト上で利用可能なアイテムを有している場合でも、銀行はその後のチャージを拒否する必要がある。
・メイド → 販売者₃ :
TransactionToken, item₄ ||r₄, ConciergeID,
・販売者₃ → 銀行 :
h(item₄||r₄), TotalPrice₁, TransactionToken, ConciergeID
・銀行 → 販売者₃ :
NotOKToPurchase : h(item₄ ||r₄) : BudgetExceeded

メイドが自分のために買いたいと思う付加的なitem₅||r₅を作ろうとする場合、トランザクションは失敗するだろう。銀行は、許可された各アイテムのハッシュのリストを有している。メイドが偽造しようとしたアイテムは、アリスが入れた暗号化されたトランザクショントークン内に含まれていないため、銀行はそのアイテムが許可されていないことを極めて容易に認識することができる。下記のプロトコルのやり取りは、メイドが拒否されることを示している。
・メイド → 販売者₄ :
TransactionToken, item₅ ||r₅, ConciergeID,
・販売者₄ → 銀行 :
h(item₅||r₅), TotalPrice₃, TransactionToken, ConciergeID
・銀行 → 販売者₄ :
NotOKToPurchase : h(item₅ ||r₅) : BadItem

メイドが２つの異なる販売者から同じアイテムを購入しようとする場合（すなわち、二重支出）は、トランザクションは失敗するだろう。このことは、無論、銀行がどのアイテムのハッシュが過去にうまくアイテムと引き換えられたかを追跡することに依存している。同時に二重支出が生じることを阻止するために、銀行はトランザクションのロック（transaction locking）を使用できる。
・メイド → 販売者₅ :
TransactionToken, item₁ ||r₁, ConciergeID,
・販売者₅ → 銀行 :
h(item₁||r₁), TotalPrice1, TransactionToken, ConciergeID
・銀行 → 販売者₅ :
NotOKToPurchase : h(item₁ ||r₁) : AlreadyPurchasedItem

管理人が詐欺を企てているのではないかと銀行が疑う場合、銀行は必要に応じてＳＭＳメッセージ又は電子メールのいずれかを介して顧客に連絡して、悪用の疑いのある試みが検出されたことを顧客に知らせることができる。このことは、顧客が後で自己の管理人の選択を再検討するときに、顧客に貴重なフィードバックを提供することになる。

メイドへの支払い：アリスはメイドの付加的なサービスに対して支払うために、ＡＴＭ引き出しの委任に関連して、後で概要を説明する技術を使用することができる。

休暇中の子供：
チャーリーは数週間彼の友人と休暇を取ろうとしている。チャーリーの母親はホテルの部屋代と食事代を支払うことによって、休暇の費用を支援しようと提案した。チャーリーの母親には２つの選択肢がある、すなわち、彼女は彼に現金を与えるか、又は彼の買ったものに対してチャージできる彼女のクレジットカードを与えることのどちらかである。チャーリーの母親は、チャーリーが金を節約するために友人のホテルの部屋で寝て、安い食品を食べるのではないかと心配する。彼女は、チャーリーがこれを行って、彼女の全ての金をアルコールに使うのではないかと心配する。これは、チャーリーが買うことを許可されているものを明らかにする適当なトークンを彼に送ることによって、避けることができる。

会社における１日当たりの食事及び支出領収書：
ビジネス旅行者は一般に、３つの方法のうちの１つで費用を支払う。第１は、彼らが自己の現金又はクレジットカードで費用を支払い、後でレシートを提出する。第２は、彼らが全ての費用について会社のクレジットカードを使用して、後でレシートを提出する。第３は、会社が一定の費用に対して「１日当たりの」価格を設定し、従業員にはレシートを提出することなくこの金が与えられる。

第１の方法に対する問題点は、従業員は費用に関して最初に支払い、次に精算されるのを待つ必要があるため、従業員が会社に金を貸すことを要求されることである。出張の機会が多い従業員にとって、これは合計すると極めて大きな金額になる。第２の方法に関する問題点は、会社のクレジットカードが従業員によって悪用されるか又は盗まれる可能性があることである。従業員に会社のクレジットカードを与えることは、彼らを大いに信用することが必要である。第３の方法に関する問題点は、従業員は１日当たり割り当てられた金額を使うことができるが、彼らはアルコールに全ての金を使いたいと思うことがあり、多くの会社はこれに満足しない。１日当たりの方法は、どのように金が使用されるか又はどんなアイテムに金が使用されるかに関して、会社はコントロールできないことになる。

従って、前述した実施例の１つの同様の応用例は、この方式を営業費に使用することである。これには多くの利点がある。個人は費用を支払うために自分の資金を使用する必要はないが、事業に対するリスクは、個人に彼ら自身のクレジットカードを与えることに比較すると著しく低い。個々のトランザクションを特定の上限に制限することができ、また会社は買い物を特定の種類、例えば食料、旅行、ホテルの部屋代などに限定することができる。許可証をなくした場合、その許可証は使用される有効な管理人のＩＤを必要とするため、会社は何も失わない。そして、出張が延びた場合は、追加の許可証の番号を発行して、電子メール又はファックスによって送信することはたいした手間ではない。

許可証の中に販売者に対する特別な命令を組み込んで、購入することができない特定のアイテムを指定することもできる。この１つの実施例には、食品からアルコールをブラックリストに載せることも含まれる。

これに関する１つの別の利点は、雇用者の身元の秘密がこのように保たれることである。たいていの会社では、これは問題ではない。全米政府は、同じ最初の４桁で始まるクレジットカードを発行した。このため、コンピュータシステムにアクセス可能なホテルで働く誰もが、どの客が政府発行のクレジットカードを使用しているかを知ることができる。安全性かつ機密保護のために、この種の情報を利用できない状態にしておくことは良い考えである。暗号化された支払い許可証を用いることによって、販売者は口座の所有者の身元を知ることはない。彼らは単に、トランザクションが成功したかどうかを知らされるだけである。身元を販売者から隠したいと思う人は、直ちに現金で支払うべきである。これらの許可証は、窃盗に対して極めて大きな抵抗力がある１つの別の選択肢を加える。同様に、内部窃盗の場合には危険はない。販売者はクレジットカードの番号を知ることはないので、悪質な従業員が盗むことはできない。

以下に、委任されたＡＴＭの引き出しに使用できる本発明の実施形態を説明する。

世界の遠隔地の人々は、最も近い銀行またはＡＴＭから非常に離れていることが多い。一般に、家族、友人、又は村のメンバの１人は、定期的に大きな町に行って全員の仕事の世話をしている。このため、この人は、それぞれが添付の紙に書かれたＰＩＮ番号を有する多数のＡＴＭカードを携えている。このシステムは、信頼された人が全員の口座を引き出して国を離れることを選択できるという点で、極めて大きな信頼を必要とする。ユーザは自己の意思（「トムに４０ドルを上げてください」）を伝えることはできないが、その信頼された人に対して自己の銀行口座についての完全なコントロールを与えなければならない。携帯電話ベースのイーバンクは、（ユーザが金をオンラインで管理人の口座に移して、管理人が次にそれを引き出すという）この問題に対する解決策を与えるが、これはそれぞれのユーザがオンライン銀行システムにアクセスする必要がある。提案された実施形態は、インターネットにアクセスしなくても動作する。ユーザはトランザクショントークンを作るときは、オフラインとすることができる。この問題に対して２つの解決策を説明する。すなわち１つは、プリンタ又はブルートゥース式携帯電話及びブルートゥース互換のＡＴＭ装置へのアクセスを要することである。そして第２の解決策は、ペン及び紙と一緒に使用できることである。第１の実施形態は、下記のように実行される。

家にいるアリスは友人のボブに、バスで８時間離れた最も近い大きな町のＡＴＭに行くように頼んだ。アリスは、自己の携帯電話を用いて下記のようなトランザクショントークンを作成する。
TransactionToken = {Accnt#, PIN, ts,Amount, ConciergeID, n}BankPubK
ここで、ｎはノンス（大きな乱数）であり、ＰＩＮを得るためのディクショナリ攻撃を避けるために加えられる。別の方法は大きなＰＩＮを使用することであるが、これには幾つかの欠点があることは容易に理解できる。このトークンは次に、ブルートゥース接続を介してボブの携帯電話に送信されるか、又はアリスがトークンを、例えばＱＲコード又はバーコードを用いてコンピュータが読取り可能な形式で印刷する。

プロトコルは下記のようになる。
・アリス → ボブ :
TransactionToken1
・ボブ → 銀行 :
TransactionToken1, ConciergeID ,
・銀行 → ボブ :
OkForWithdraw : Price

ボブがトランザクショントークンを多少なりとも変更しようとする場合、彼はアリスのＰＩＮ番号を持っていないため、有効なトークンを作ることができない。下記のトークンは、偽造のトークンを用いた場合に発生する失敗の概要を記述している。
・アリス → ボブ :
TransactionToken2
・ボブ → 銀行 :
TransactionToken3, ConciergeID
・銀行 → ボブ :
NotOkForWithDraw : BadToken

ボブが同じトークンを２回再使用しようとすると、銀行はそれを拒否する。これにより、銀行は全ての換金されたトークンのリストを保持するように要求される。下記のプロトコルは、そのような失敗の概要を記述している。
・アリス → ボブ :
TransactionToken4
・ボブ → 銀行 :
TransactionToken4, ConciergeID
・銀行 → ボブ :
OkForWithdraw: Price
・ボブ → 銀行 :
TransactionToken4, ConciergeID,
・銀行 → ボブ :
NotOkForWithdraw: TokenAlreadyUsed

ボブが携帯電話を持っていない場合、又は銀行のＡＴＭ装置がブルートゥースに対応していない場合は、前述された方式を使用することができない。その場合は、従来のインフラを使用するよりも限定されたプロトコルにフォールバックする必要がある。この方式は、アリスが携帯電話又はコンピュータ装置を有することをなおも要求する。アリスは前もって、銀行と長く共有された鍵を設定している必要がある。この鍵は、ディクショナリ攻撃に対して抵抗できるように適切に大きくなければならない。次に、アリスは携帯電話を使用して、下記のようにハッシュ関数を用いて、銀行とあらかじめ合意され事前設定された鍵を用いてトランザクショントークンを作成する。
TransactionToken = h(Accnt#||LongPIN||Timestamp||Amount||ConciergeID)

アリスは次に、彼女の口座番号、タイムスタンプ（又は何らかの他のトークン識別子）、及び金額と一緒に、このハッシュを紙に記載することができる。ＭＤ５のハッシュは、３０個のアルファベット又は数字のストリングとして書くことができる。これは、誰かがそれを手作業でＡＴＭにタイプすることを予想できるほど十分に小さい。このため、プロトコルは下記のようになる。
・アリス → ボブ :
TransactionToken1, Accnt#, Timestamp, Amount
・ボブ → 銀行 :
TransactionToken1, Accnt#, Timestamp, Amount, ConciergeID
・銀行 → ボブ :
OkForWithdraw: Amount

１つの実施形態によれば、事前設定された鍵は全てのユーザに対して（少なくとも特定の銀行に関して）同じであるため、この銀行を使用する全てのユーザは実際に同じハッシュアルゴリズムを使用し、銀行は各ユーザに対して異なる鍵を配信及び管理する必要はなく、比較的容易に検証処理を行うことができる。

ボブが、アリスが許可した以上の金を引き出そうとすると、銀行が計算したハッシュはアリスがボブに与えたものと同じではなくなる。このため、トランザクションは失敗する。以下のプロトコルは、このような試みを概説する。
・アリス → ボブ :
TransactionToken2, Accnt#, Timestamp, Amount2
・ボブ → 銀行 :
TransactionToken2, Accnt#, Timestamp, Amount3, ConciergeID
・銀行 → ボブ :
NotOkForWithdraw: BadAmount

ボブが同じトークンを複数回使おうとする場合、繰り返したトランザクションは失敗する。このことは、換金したトランザクショントークンの軌跡を保持している銀行に依存する。この場合、特別なタイムスタンプにつき（同じ引き出し口座に対して）確実に１つのトークンしか存在しないことが必要である。
・アリス → ボブ :
TransactionToken3, Accnt#, Timestamp, Amount
・ボブ → 銀行 :
TransactionToken3, Accnt#, Timestamp, Amount, ConciergeID,
・銀行 → ボブ :
OkForWithdraw : Amount
・ボブ → 銀行 :
TransactionToken3, Accnt#, Timestamp, Amount, ConciergeID,
・銀行 → ボブ :
NotOkForWithdraw: TokenAlreadyUsed

１つの実施形態による上述の委任管理人方式は、機能としてトラベラーズチェックを提供できるようにわずかに変更することができる。ユーザは管理人ＩＤを自己のＩＤに割り当てるか、又は自己の財布と、管理人ＩＤのフィールドに置き換えることができる全ての形式のＩＤ番号、パスワード又はワンタイムＰＩＮ番号とを失った状態から保護することができる。この実施例には、費用が１００ドル未満の１枚の鉄道切符、又は３０ドル未満のホテルの１泊又はレストランの食事に限定されたトラベラーズチェックが含まれる。

盗まれた場合又は財布をなくした場合のために、このようなトラベラーズチェックを写真コピーして、個人が複数のコピーを財布の中に保持することができる。コピーは例えば（それを彼らにイーメールすることによって）オンラインで保持することができ、また同様に、出張者はコピーを事務所の秘書に置いておき、秘書は後で必要に応じて印刷されたトランザクショントークンを出張者にファックスすることができる。

このような方式は、従来のトラベラーズチェックと比較して幾つかの利点がある。

例えば、休暇又は出張時にトラベラーズチェックを紛失した者は、アメリカンエクスプレス（又は他の発行者）と連絡を取る必要がある。次にアメリカンエクスプレス（又は他の発行者）は現在の小切手を解約し、新しい小切手を発行して、待っている顧客にそれらを急送する。紛失した者が大都市にいる場合は、彼は近くのアメリカンエクスプレスの事務所に行くことができるか、そうでなければ、FedExによってそれらが着くのを待つ必要がある。販売者は真正なもののみを認めるように言われているため、トラベラーズチェックを写真コピーすることはできない。トラベラーズチェックは、ファックス、イーメール又は任意の電子媒体によって送信することはできない。顧客の観点からのトラベラーズチェックに関する重要な問題は、彼らはトラベラーズチェックに対して前金で払う必要があることである。６ヶ月間顧客の財布の中にある、緊急の場合に使用される予定のトラベラーズチェックには、この金に対する６ヶ月の利息が付くが、顧客はこれを得ることができない。

顧客がトラベラーズチェックを使用する前に購入することに関する要件のために、これらを買うために借金をすることは不可能となる。トラベラーズチェックは、顧客が緊急時に使用することが多い。このような場合に、事態の状況により予期しない借金をすることは妥当である。トラベラーズチェックは、これを許さない。前もって購入してある場合のみ、トラベラーズチェックを使うことができる。このため、これらは実際に保存された支払い媒体であり、決してクレジットの形式ではない。

このような方式はまた、緊急時に金をワイヤリングすることと比較して幾つかの利点がある。

金を紛失することがあり、盗まれることもある。運の悪いことに、稲妻が同じ場所に２回落ちることがある。どんな理由であれ、旅行中に財布を紛失した人は、銀行又はウェスタンユニオン（western union）などのサービスを介して、資金の緊急ワイヤ（emergency wire of fund）を捜すような知恵がない。不幸が再度彼らを訪れる場合、彼らは再び運が悪いことになる。さらに、ワイヤサービス（wire service）は、かなり大きな手数料がかかる。無論、これは開いている銀行によって決まる。世界中の多くの場所では、金のワイヤリング（wiring of money）は、営業時間の間しか利用できない。金をワイヤリングすることは、トランザクションの相手方、すなわち友人、同僚、恋人の協力も必要である。このことは、無論、各自がこれらの友人に近付く方法を持つ必要がある。コレクト又は受信者払いの呼出しは、世界の全ての場所では利用できない。アジア及び中東の多くの場所では、それが全く存在しない。このため、ワイヤを要求する前に、国際電話に対して支払う方法を見つける必要がある。

オンラインショッピングに関しては、管理人を含めずに、顧客は「ランダムクレジットカード（randomized credit card）」と同じ方法で提案された方式を使用できる。ここで、目標は、悪質な販売者がクレジットカードのデータを再利用することを防止することである。

前述の実施形態は、ハードウェア、ソフトウェア又はハードウェア及びソフトウェアの組合せによって実現できることは、当業者は理解されよう。本発明の実施形態に関連して説明したモジュール及び機能は、本発明の実施形態に関連して説明した方法に基づいて動作するように適切にプログラムされたマイクロプロセッサ又はコンピュータによって全体的又は部分的に実行することができる。本発明の実施形態を実施する装置は、例えば本発明の実施形態で説明したような委任トランザクションを実行できるように適切にプログラムされたコンピュータ装置又は携帯電話又は任意のモバイルデバイスを含むことができる。特に、ユーザのモバイルデバイス（又は携帯電話）は、マイクロプロセッサとこのマイクロプロセッサがトークンを生成できるようにするプログラムを含むメモリとを使用することにより、トークンを生成することができる。このために、モバイルデバイスはさらに、ユーザが自己の口座識別子などのデータを入力可能にするユーザーインターフェースを備えることができる。次に、入力されたデータはメモリに記憶され、そしてトークンを生成するためにマイクロプロセッサによって使用される。また、マイクロプロセッサは次に、復号化プログラムを実行することによって復号化を実行する。第三者へのトークンの転送は（管理人への転送は、ユーザが紙にトークンを書くことによって手作業で実行される）、無線インターフェース（例えば、ＳＭＳ、ＭＭＳ）、ＩｒＤＡやブルートゥースなどの近距離無線通信（ＮＦＣ）インターフェース、又は任意の有線又は無線通信インターフェースなどの任意の通信インターフェースによってより便利に実行できる。次に、第三者においては、銀行へのハッシュ値の送信が、再度任意の有線又は無線インターフェースによって行われる。その結果、このトランザクション方式は、本発明の上記の実施形態の中で説明したトランザクション方式に基づいて動作するような方法で、個々の参加者（ユーザ、管理人、販売者及び銀行）の装置を適切にプログラムすることによって実現することができる。従って、特許請求の範囲に記載された全ての手段又はモジュールは、マイクロプロセッサと、このマイクロプロセッサによって実行されるプログラムを記憶するメモリとによって実現される。このプログラムを実行することにより、特許請求の範囲に記載された機能を実行するモジュールの動作がもたらされる。これには、ユーザーインターフェース又は通信インターフェースの動作も含まれる。これらのインターフェースも、メモリに記憶されたプログラムによって制御されるマイクロプロセッサの制御のもとで動作している。

本発明の実施形態によれば、データ記憶媒体又は、記録媒体又は送信リンクなどの何らかの物理的手段によって具体化された他の手段のいずれかに記憶されたコンピュータプログラムが提供される。このプログラムは、本発明の上記実施形態に基づいてコンピュータを動作させることができる。

本発明の実施形態による方法を概略的に示す図である。本発明の実施形態によるトークンを概略的に示す図である。本発明の実施形態によるトークンを概略的に示す図である。本発明の実施形態によるトークンを概略的に示す図である。本発明の実施形態によるトークンを概略的に示す図である。本発明の実施形態によるトークンを概略的に示す図である。本発明の実施形態によるトークンを概略的に示す図である。

Claims

あるユーザの口座を特定する口座識別子と、該ユーザ及び銀行だけが知っている秘密許可識別子であって、該ユーザの口座に対応する秘密許可識別子と、実行されるトランザクションの種類を定めるトランザクション定義とに少なくとも基づいてトークンを生成するステップと、
ある暗号化方法を用いて前記トークンを暗号化して、暗号化されたトークンを生成するステップであって、前記暗号化方法は予め定められており、前記銀行が知っていて、該銀行により繰り返して行われるものである、ステップと、
暗号化されたトークンを前記ユーザから前記第三者へ転送して、前記トークンにより指定された前記ユーザの口座のために、前記トランザクション定義において定められているようにトランザクションを定めることを前記第三者に許可するステップであって、ここで、前記トランザクションを実行するために、前記トークンにより指定された口座が属する銀行へ前記トークンが転送され、前記口座に対応する前記秘密許可識別子の正当性が検証できるか否かに応じて、前記ユーザの口座に対し前記トランザクションを許可又は拒否するために、前記銀行が前記トークンの逆暗号化を実行することにより前記トークンの信頼性を検証する、ステップと、
ユーザのために第三者が購入すべきアイテムを特定する識別子のリストを前記トークン内に含めるステップであって、前記識別子は、それぞれ乱数に関連付けられてハッシュされるものである、ステップと、
購入される１つ以上のアイテムのハッシュ値を、第三者から販売者へ送信するとともに該販売者から銀行へ送信するステップと、
販売者が送信した１つ以上のハッシュ値が暗号化されたトークン内に含まれる場合のみ、前記銀行がトランザクションを許可するステップと
を含む、ユーザのために第三者がトランザクションを実行することを該ユーザにより可能とするコンピュータ実行可能な方法。
前記トークンの暗号化は、前記トークンにより指定された口座が属する銀行の公開鍵を用いて前記トークンを暗号化するステップを含むものである、請求項１に記載の方法。
販売者に支払いをするために、暗号化されたトークンを前記第三者から前記販売者へ転送するステップと、
検証結果に応じて前記トランザクションを許可又は拒否するために、暗号化されたトークンを前記販売者から検証を行う前記銀行へ転送するステップと
をさらに含む請求項１又は２に記載の方法。
購入される１つ以上のアイテムのハッシュ値を第三者から販売者へ送信することに代えて、使用される１つ以上のハッシュ関数及び購入される１つ以上のアイテムの（ハッシュされる）識別子及び識別子に対応する乱数を第三者から販売者へ送信するステップと、
購入される１つ以上のアイテムの識別子及び対応する乱数に基づいてハッシュ値を計算して、該ハッシュ値を販売者から銀行へ送信するステップと、
販売者が送信した１つ以上のハッシュ値が前記暗号化されたトークン内に含まれる場合にのみ、銀行がトランザクションを許可するステップと
をさらに含む請求項１〜３のいずれか一項に記載の方法。
前記トークンは、
前記第三者の識別子と、
前記トークンの識別子と、
タイムスタンプと、
１つ以上のトランザクション選択肢と、
トークンを用いて使われる最大の金額と、
買い物リストにおける個々のアイテムについてのそれぞれの最高価格と
のうちの１つ以上をさらに含むものである、請求項１〜４のいずれか一項に記載の方法。
前記銀行があるトークンを用いて実行したトランザクションを記録するステップと、
使用された額をトークンから差し引いて、該トークンの残りのクレジットを得るステップと、
実行される新たなトランザクションのそれぞれについて、トークンがこのトランザクションを実行するための十分なクレジットをなお有しているかどうかを確認するステップと
をさらに含む請求項１〜５のいずれか一項に記載の方法。
前記トークン内には、第三者の識別子に代えて、ユーザの識別子又はユーザしか知らないユニークなコード又はパスワードが含まれており、これによりユーザが自己に対してトラベラーズチェックを生成する、請求項１〜６のいずれか一項に記載の方法。
あるユーザの口座を特定する口座識別子と、該ユーザ及び銀行だけが知っている秘密許可識別子であって、該ユーザの口座に対応する秘密許可識別子と、実行されるトランザクションの種類を定めるトランザクション定義とに少なくとも基づいてトークンを生成するモジュールと、
ある暗号化方法を用いて前記トークンを暗号化して、暗号化されたトークンを生成するモジュールであって、前記暗号化方法は予め定められており、前記銀行が知っていて、該銀行により逆に実行されるか又は繰り返して行われるものである、モジュールと、
暗号化されたトークンを前記ユーザから前記第三者へ転送するモジュールであって、これにより前記第三者が前記トークンにより指定された前記ユーザの口座のために、前記トランザクション定義で定められているようにトランザクションを定めることが許可され、ここで、前記トランザクションを実行するために、前記トークンにより指定された口座が属する銀行へ前記トークンが転送され、前記口座に対応する前記秘密許可識別子の正当性が検証できるか否かに応じて、前記ユーザの口座に対し前記トランザクションを許可又は拒否するために、前記銀行が前記トークンの逆暗号化を実行するか又は前記銀行により再アセンブルされる暗号化されていないトークンの暗号化を繰り返すことにより前記トークンの信頼性を検証する、モジュールと、
ユーザのために第三者が購入すべきアイテムを特定する識別子のリストを前記トークン内に含めるモジュールであって、前記識別子はそれぞれ乱数に関連付けられてハッシュされる、モジュールと、
購入される１つ以上のアイテムの前記ハッシュ値を、第三者から販売者へ送信するとともに該販売者から銀行へ送信するモジュールと、
販売者が送信した１つ以上のハッシュ値が暗号化されたトークン内に含まれる場合にのみ、前記銀行がトランザクションを許可するためのモジュールと
を備える、ユーザにより、該ユーザのために第三者がトランザクションを実行することを可能とする装置。
請求項１〜７のいずれか一項に記載の方法を実行するモジュールをさらに備える請求項８に記載の装置。
請求項１〜７のいずれか一項に記載の方法をコンピュータに実行させることができるコンピュータプログラムコードを含むコンピュータプログラム。