(57)【要約】本発明は、少なくとも１つのブローカー１、少なくとも１つのクライアント２並びに製品及び／又はサービスに関する少なくとも１つの小売商３を備える、少額決済処理を管理するためのシステム及び方法に関する。該少額決済処理は、トークンの交換を実現する。本発明によれば、該クライアント２のそれぞれは、少なくとも１つの第１の財布と少なくとも１つの第２の財布に対応する、トークンを記憶するための少なくとも２つの個別の領域を利用可能である。該第１の財布は、該ブローカー１により該クライアント２に供給されたトークンを備えることが可能であり、該第２の財布は、該少なくとも１つの小売商３により該クライアント２に供給されたトークンを備えることが可能である。
2004503018.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのブローカー、少なくとも１つのクライアント、並びに商品及び／又はサービスに関する少なくとも１つの小売商を備え、トークンの交換を実現する少額決済処理を管理するためのシステムであって、
前記クライアントのそれぞれは、少なくとも１つの第１の領域が少なくとも１つの第１の財布に対応するトークンを記憶し、少なくとも１つの第２の領域が第２の財布に対応するトークンを記憶する、前記トークンを記憶するための少なくとも２つの個別の領域を利用可能であり、
前記第１の財布は、前記ブローカーにより前記クライアントに供給されたトークンを備えることが可能であり、前記第２の財布は、前記少なくとも１つの小売商により前記クライアントに供給されたトークンを備えることが可能である、
ことを特徴とするシステム。
【請求項２】
前記小売商のそれぞれは、トークンを記憶するための少なくとも２つの異なる領域を利用可能である、
ことを特徴とする請求項１記載のシステム。
【請求項３】
前記小売商のトークンを記憶するための少なくとも１つの第１の領域は、前記小売商の財布に対応し、前記小売商のトークンを記憶するための少なくとも１つの第２の領域は、前記小売商の保存ファイルに対応し、
前記小売商の前記財布は、前記ブローカーにより前記小売商に供給されたトークンを備えることが可能であり、前記保存ファイルは、前記少なくとも１つのクライアントにより前記小売商に供給されたトークンを備えることが可能である、ことを特徴とする請求項２記載のシステム。
【請求項４】
前記クライアントにより前記小売商から調達された製品及び／又はサービスの支払いの過程で、前記クライアントは、前記製品及び／又はサービスの価格に対応する第１の数Ｐのトークンを前記小売商に送出し、
前記クライアントの第１の財布が前記第１の数Ｐよりも大きいか、又は前記第１の数に等しい数のトークンを含む場合に、前記第１の数Ｐのトークンは、前記クライアントの第１の財布に対応しかつ前記ブローカーにより供給されたトークンを含むことが可能な前記クライアントのトークンを記憶する第１の領域から発生され、
前記第１の財布が前記第１の数Ｐよりも少ない数Ｘのトークンを含む場合、
Ｘ個のトークンは、前記第１の財布から発生され、
Ｐ−Ｘ個のトークンは、前記クライアントの第２の財布に対応しかつ前記小売商により供給されるトークンを含むことが可能な前記クライアントのトークンを記憶するための第２の領域から発生され、
前記小売商は、前記保存ファイルに対応する、トークンを記憶するための前記クライアントの第２の領域に送出される前記第１の数Ｐのトークンを記憶する、ことを特徴とする請求項３記載のシステムにおける少額決済処理を管理するための方法。
【請求項５】
前記小売商は、総額を前記クライアントに払い戻しすることを望むとき、前記方法は、
前記小売商の財布に対応する前記小売商の第１の記憶領域から、前記総額に対応する第２の数のトークンを引き出し、
前記クライアントの前記第２の財布のトークンに追加される前記第２の数が所定の最大値を超えないことを検証し、
前記最大値を超えていないとき、前記クライアントの前記第２の財布に前記第２の数を記憶し、
前記最大値を超えているとき、前記処理を中断して、少額決済処理を実行することにより前記クライアントに払い戻しを行うか、或いは、
払い戻しを行うことが可能なように、前記クライアントの第２の財布を空にすることを前記クライアントに要求するメッセージを前記クライアントに送る、
ことを特徴とする請求項４記載の方法。
【請求項６】
前記第２の財布から前記第１の財布にトークンを送るステップをさらに備え、
前記クライアントが前記ブローカーに前記第２の財布に含まれている前記トークンを前記第１の財布に送出することを要求するサブステップと、
前記ブローカーが前記クライアントの正当性を検証する一方で、他方では、前記第２の財布に含まれている前記トークンの正当性を検証するサブステップと、
前記正当性が検証されたとき、前記ブローカーは、前記トークンを前記第２の財布から前記第１の財布に送るサブステップとを備える、
ことを特徴とする請求項４又は５記載の方法。
【請求項７】
前記クライアントは、前記ブローカーからトークンを購入することを望むとき、前記方法は、
前記ブローカーが前記購入されたトークンを前記第１の財布に送出し、
前記第２の財布はトークンを含み、前記ブローカーは前記トークンの正当性を検証し、前記トークンが有効であるとき、前記第２の財布から前記第１の財布に前記トークンを送出する、
ことを特徴とする請求項４乃至６のいずれか記載の方法。
【請求項８】
前記小売商は、前記小売商の銀行口座の貸し方に記入されるように、前記小売商の財布の借り方に所定の整数であるＮ個のトークンの値が記入されることを望むとき、前記方法は、
前記ブローカーが前記小売商の前記財布が少なくともＮ個のトークンを含むことを検証し、
検証が実行されたときに、前記保存ファイルは、所定の整数であるＭ個のトークンを含み、前記ブローカーは、前記小売商の銀行口座の貸し方に（Ｎ＋Ｍ）個のトークンの値を記入し、前記保存ファイルを空にし、前記小売商の前記財布からＮ個のトークンを除く、
ことを特徴とする請求項４乃至７のいずれか記載の方法。
【請求項９】
前記クライアントが、前記クライアントの銀行口座の貸し方に前記第１の財布に含まれる少なくとも１つのトークンの値が記入されることを望むとき、前記第２の財布は少なくとも１つの財布を含み、
前記ブローカーが前記第２の財布に含まれる少なくとも１つのトークンの正当性を検証するステップを実行し、正当性が検証されたとき、前記少なくとも１つのトークンを前記第２の財布から前記第１の財布に送出する、
ことを特徴とする請求項４乃至８のいずれか記載の方法。
【請求項１０】
前記ブローカー、前記小売商及び前記クライアントのそれぞれは、非対称鍵の対を所有し、前記非対称鍵は、前記クライアント及び／又は前記小売商の銀行口座を実現する前記処理に署名することを可能にする、
ことを特徴とする請求項４乃至９のいずれか記載の方法。
【請求項１１】
２者間の前記処理のうちの１つの過程で交換されるメッセージは、マスターキー及び前記２者のうちの少なくとも一方の識別から決定され、導出される対称鍵を使用して証明される、
ことを特徴とする請求項４乃至１０のいずれか記載の方法。
【請求項１２】
前記処理のそれぞれは、固有の対称鍵を実現し、前記固有な対称鍵は、
前記ブローカーが、少なくとも１つのトークンを前記クライアントの前記第１の財布に送出すること、
前記ブローカーが、少なくとも１つのトークンを前記小売商の前記財布に送出すること、
前記小売商が、前記クライアントからの製品及び／又はサービスについての支払いを要求すること、
前記クライアントが、製品及び／又はサービスについて前記小売商に支払うこと、
前記クライアントが、購入の証明を前記小売商に提供すること、
前記小売商が、前記クライアントに払い戻しすること、
前記ブローカーが、前記クライアントの少なくとも幾つかのトークンを買い戻しすること、
前記ブローカーが、前記小売商の少なくとも幾つかのトークンを買い戻しすること、
を備えるグループに属する処理のうちの１つについてのみ使用可能である、
ことを特徴とする請求項４乃至１１のいずれか記載の方法。
【請求項１３】
前記クライアント及び／又は前記小売商により所有される前記対称鍵は、前記データを否認できないことを補償するように、
前記処理のうちの１つの過程で交換されるメッセージの発生元及び保全を認証することを可能にするデータの生成、
前記データの検証、
の動作のうちの一方についてのみ使用することができる、
ことを特徴とする請求項１１又は１２記載の方法。
【請求項１４】
少額決済処理を管理するためのシステムにおけるクライアント端末であって、前記処理は、少なくとも１つのブローカー、及び／又は製品及び／又はサービスに関する少なくとも１つの小売商、及び／又はクライアントの間でトークンの交換を実現し、
少なくとも１つの第１の財布と少なくとも１つの第２の財布に対応する、トークンを記憶するための少なくとも２つの異なる領域を備え、
前記第１の財布は、前記少なくとも１つのブローカーにより前記クライアントに供給されたトークンを備えることが可能であり、前記第２の財布は、前記少なくとも１つの小売商により前記クライアントに供給されるトークンを備えることが可能である、
ことを特徴とするクライアント端末。
【請求項１５】
前記２つの記憶領域は、前記端末に含まれるセキュアプロセッサに位置されるか、又は前記端末により読み取ることができるデータサポートに位置される、
ことを特徴とする請求項１４記載のクライアント端末。
【請求項１６】
少額決済処理を管理するためのシステムにおける小売商装置であって、前記処理は、少なくとも１つのブローカー及び／又は少なくとも１つのクライアント及び／又は前記小売商の間でトークンの交換を実現し、
トークンを記憶するための少なくとも２つの個別の領域を備える、
ことを特徴とする小売商装置。
【請求項１７】
前記２つの記憶領域は、前記小売商の財布と前記小売商の保存ファイルであり、
前記小売商の前記財布は、前記ブローカーにより前記小売商に供給されたトークンを備えることが可能であり、前記保存ファイルは、前記少なくとも１つのクライアントにより前記小売商に供給されたトークンを備えることが可能である、ことを特徴とする請求項１６記載の小売商装置。
【発明の詳細な説明】
【０００１】
［発明の分野］
本発明は、少額決済処理の管理に関する。
より詳細には、本発明は、少なくとも１つのブローカー、少なくとも１つのクライアント、並びに商品及び／又はサービスに関する少なくとも１つの小売商を実現する少額決済処理を管理するためのシステム及び方法に関する。
【０００２】
本明細書において少額決済とは、たとえば、数分の１のサンチームから数十又は数百のフランまで（或いは、制限された額の他の為替通貨）といった、制限された額の支払いを意味することが理解される。特に、この少額決済は、電子商取引の通貨をなすトークンの交換を実現する。
【０００３】
［従来の技術］
たとえば、世界的なインターネットネットワークのような、通信ネットワークを介して実現される少額決済及び／又は少額決済処理のためのシステムの出現は、クライアントと小売商との間の処理の過程で交換される情報のセキュリティと同様に、クライアントと小売商との間の処理のセキュリティの問題を生じている。
【０００４】
特に、処理のセキュリティの主要な問題のうちの１つは、小売商及び／又はシステムのクライアントがトークン（或いは、他の為替通貨単位）を複製する可能性、及び該複製されたトークンを２つの個別の処理のために不正に使用する可能性である。
【０００５】
このセキュリティの問題を解決するために、電子商取引の処理を管理するため、或いは処理のセキュリティをせめて拡張するための多くのシステムが提案されてきている。これらのシステムは、たとえば、共著者であるＤｏｎａｌ Ｏ’Ｍａｈｏｎｙ， Ｍｉｃｈａｅｌ Ｐｅｉｒｃｅ及びＨｉｔｅｓｈ Ｔｅｗａｒｉにより１９９７年にＡｒｔｅｃｈ Ｈｏｕｓｅ社により出版された“Ｅｌｅｃｔｒｉｃ Ｐａｙｍｅｎｔ Ｓｙｓｔｅｍｓ”と題された研究に記載されている。
【０００６】
この研究は、一方で、ＤｉｇｉＣａｓｈ（登録商標）社により開発されたＥｃａｓｈシステムのような現金による電子支払いのためのシステム、ＣＡＦＥ（Ｃｏｎｄｉｔｉｏｎａｌ Ａｃｃｅｓｓ ｆｏｒ Ｅｕｒｏｐｅ）プロジェクト、又はＮｅｔＣａｓｈ ＣｙｂｅｒＣｏｉｎ、或いはＭｏｎｄｅｘ（登録商標）システムを区別している。
【０００７】
この研究は、他方で、Ｍｉｌｌｉｃｅｎｔ ＳｕｂＳｃｒｉｐ， ＰａｙＷｏｒｄ， Ｍｉｃｒｏｍｉｎｔ又はｉＫＰ（登録商標）少額決済プロトコルのような、特定の少額決済システムを言及している。
【０００８】
全ての既存のキャッシュベースの電子支払いシステムでは、処理のセキュリティは、対称鍵及び非対称鍵の両者である暗号方式を積極的に使用することにより保証されている。このように、Ｅｃａｓｈシステムでは、たとえば、銀行及び／又はブローカーの各種暗号化された署名は、各種暗号方式による計算と関連されており、システムを流通するトークンのそれぞれが１度のみ使用されたことを証明するように実現される。
【０００９】
さらに、銀行及び／又はブローカーは、それぞれの処理の過程で、トークンのシリアル番号をシステムにより発行された全てのトークンの全てのシリアル番号を包含する大容量のデータベースと比較することにより、トークンの正当性に関するシステマティックな確認を実行する。
【００１０】
この従来技術の技法の問題点は、処理のセキュリティが非常の大量の計算及び暗号化を実現するという犠牲を払って保証されている点であり、これにより、システムは過負荷となり、システムが高価になり、少額決算処理向けには適さない。
【００１１】
この従来の技法の別の問題点は、システムにより発行されるトークンの全てのシリアル番号を包含する大容量のデータベースを管理することが必要である点であり、これによりシステムが高価かつ複雑になる。
【００１２】
ＣＡＦＥ（Ｃｏｎｄｉｔｉｏｎａｌ Ａｃｃｅｓｓ ｆｏｒ Ｅｕｒｏｐｅ）プロジェクトでは、たとえば、処理のセキュリティは、任意の偽造に対する抵抗体である端末の実現、及び複雑な暗号化の実現により保証される。オブザーバは、銀行及び／又はブローカーの利益を保護するものであり、それぞれのクライアントの財布に統合される。その役割は、オブザーバの同意を得ることなしに処理を実現しないように、クライアントにより行われる全ての処理の正当性を保証することである。
【００１３】
ＮｅｔＣａｓｈ， ＣｙｂｅｒＣｏｉｎ又はＭｏｎｄｅｘ（登録商標）のようにキャッシュによる電子支払いのための他のシステムと同様に、この従来技術の問題点は、使用される端末の複雑さと同様に、実現される暗号化の重みである。
【００１４】
研究“Ｅｌｅｃｔｒｏｎｉｃ Ｐａｙｍｅｎｔ Ｓｙｓｔｅｍ”は、さらに、少額決済処理を管理するためのシステムを提供している。
【００１５】
Ｍｉｌｌｉｃｅｎｔ（登録商標）と呼ばれるシステムは、クライアント、小売商及びブローカーという３つの参加者を実現している。トークンは、所与の小売商に固有であり、少額決済処理の過程で拡張される。クライアントは、所与のタイプのトークンを取得することができ、少額決済のための交換において、ブローカーを介して特定の小売商に支払いを行うことができる。これらのトークンは、クライアントの財布に記憶されている。
【００１６】
ＳｕｂＳｃｒｉｐ（登録商標）と呼ばれる少額決済処理を管理するためのシステムは、一方で、任意の銀行又はブローカーを含まない。クライアントは、少額決済処理を使用して、所与の小売商に一時的に前払いされた口座を開設する。
【００１７】
この２つの従来技術の技法の問題点は、１人のクライアントと複数の小売商との間で実現される処理に適していない点である。特に、Ｍｉｌｌｉｃｅｎｔ（登録商標）システムでは、クライアントは、クライアントが製品及び／又はサービスを購入することを望む小売商の数と同数の異なるトークンを取得しなければならない。同様に、ＳｕｂＳｃｒｉｐ（登録商標）システムでは、クライアントは、クライアントが少額決済処理を行うことを望む小売商のそれぞれに前払いされた口座を開設しなければならない。
【００１８】
ＰａｙＷｏｒｄ（登録商標）システムは、ブローカー及び／又は銀行とのクレジット認証をクライアントに与えることによりこの問題点を緩和しており、小売商への支払いが保証される。
【００１９】
この従来技術の技法の問題点は、特に、ブローカー及び／又は銀行に関して、処理のセキュリティがない点であることは明らかである。その銀行口座に必要な資金を有するものなしに、クライアントにより非常に多くの購入が利用可能である。
【００２０】
ｉＫＰ少額決済管理プロトコルでは、処理のセキュリティは、特に、任意の処理の前に、小売商とのクライアントの決済のために、ＰａｙＷｏｒｄ（登録商標）システムに関して拡張される。
【００２１】
この技術の問題点は、かかる決済がプロトコルに重荷を負わせ、かつ速度を落とす膨大なメッセージの交換を必要とすることであり、処理を高価にする点である。
【００２２】
ＭｉｃｒｏＭｉｎｔシステムの少額決済処理の効率は、ｉＫＰ（登録商標）プロトコルの効率よりも高いが、この効率は、少額決済処理のセキュリティという犠牲を払って達成される。ブローカー及び／又は銀行は、クライアントにトークンを供給し、該トークンは、全ての小売商で使用することができる。トークンの正当性に関する検証は、同じトークンを繰返し使用することを許可して、処理の過程で行われない。
【００２３】
この従来技術の問題点は、クライアント、或いは支払いとして先に使用されて無効なトークンを受け取る場合がある小売商について、処理が安全ではない点である。
【００２４】
以上から、様々なレベルのセキュリティ及び複雑さを示す、少額決済処理を管理するための様々なシステム及び方法が存在する。ここでは、クライアントには、電子財布、クレジット決済或いは小売商との前払い口座のいずれかが提供される。しかし、実現に容易であって、処理における様々な参加者（ブローカー、クライアント、小売商）に関して満足されるセキュリティを示すシステム及びプロトコルは、現在のところ知られていない。
【００２５】
本発明の目的は、特に、これらの従来技術の問題点を緩和することである。
より詳細には、本発明の目的は、利用が簡単であって、実現するのに安価な少額決済処理を管理するためのシステム及び方法を提供することにある。
【００２６】
［発明の概念］
上記目的を達成するために、本発明は、少なくとも１つのブローカー、少なくとも１つのクライアント、並びに製品及び／又はサービスに関する少なくとも１つの小売商を備え、トークンの交換を実現する少額決済処理を管理するためのシステムに関する。
【００２７】
本発明によれば、かかるシステムでは、それぞれのクライアントは、少なくとも２つの個別の領域を利用可能である。これらの領域は、２つのクライアントの財布に対応して、一方が第１の財布、他方が第２の財布を記憶するためのものである。第１の財布は、ブローカーによりクライアントに供給されたトークンを備えることができ、第２の財布は、小売商によりクライアントに供給されたトークンを備えることができる。
【００２８】
このように、本発明は、少額決済処理の管理に対して、全体として斬新かつ発明性のあるアプローチに基づいている。特に、クライアントには、その正当性が検証されたトークンを含むトークンを記憶するための信頼性のある領域、及びトークンを記憶するためのクレジットのような領域を提供することができる。このクレジットは、１つ以上の小売商によりクライアントに与えられ、１つ以上の小売商により実行された処理に関する情報をさらに含むことができる。
【００２９】
このように、処理のセキュリティは、クライアントについて強化される。たとえば、これらのトークンが小売商により不正に複製され、２度使用されるということを心配することなしに、該クライアントには、いわば彼の第１の財布である有効なトークンのリソースが提供されることが保証される。また、クライアントには、１つ以上の小売商で使用することができるクレジットに対応する、いわば彼の第２の財布である相補的なトークンのリソースが有効にも提供される。
【００３０】
本発明の好適な特徴によれば、それぞれの小売商は、トークンを記憶するための少なくとも２つの異なる領域を利用することができる。
【００３１】
好ましくは、小売商のトークンを記憶するための少なくとも１つの第１の領域は、小売商の財布に対応し、小売商のトークンを記憶するための少なくとも１つの第２の領域は、小売商の保存ファイルに対応する。小売商の財布は、ブローカーにより小売商に供給されるトークンを備えており、保存ファイルは、クライアントにより小売商に供給されるトークンを備えることができる。
【００３２】
したがって、小売商では、ブローカーから発生されたトークンは、１つ以上のクライアントにより供給されたトークンから分離される。これにより、小売商の財布の内容の正当性が検証され、処理のセキュリティが強化される。
【００３３】
また、本発明は、上述されたシステムにおける小額決済処理を管理するための方法に関する。
【００３４】
本発明の１態様によれば、クライアントにより小売商から調達された製品及び／又はサービスのための支払いの過程では、クライアントは、小売商に第１の数Ｐのトークンを送出する。第１の数Ｐは、製品及び／又はサービスの価格に対応する。
クライアントの第１の財布が前記第１の数Ｐよりも大きいか、又は第１の数に等しい数のトークンを含む場合に、第１の数Ｐのトークンは、クライアントの第１の財布に対応しかつブローカーにより供給されたトークンを含むことが可能なクライアントのトークンを記憶する第１の領域から発生される。
第１の財布が第１の数Ｐよりも少ない数Ｘのトークンを含む場合、
Ｘ個のトークンは、第１の財布から発生され、
Ｐ−Ｘ個のトークンは、クライアントの第２の財布に対応しかつ小売商により供給されるトークンを含むことが可能なクライアントのトークンを記憶するための第２の領域から発生される。
小売商は、保存ファイルに対応する、トークンを記憶するためのクライアントの第２の領域に送出される第１の数Ｐのトークンを記憶する。
【００３５】
このように、クライアントは、クライアントがブローカーから取得して小売商に支払うトークンの使用に対する優先度を与えるが、また、クライアントは、クライアントが小売商で使用することができるクレジットを表す第２の財布に含まれるトークンにより一部又は全部の支払いを行うことができる。クライアントにより小売商に供給されるトークンの正当性は、保証可能なものではなく、クライアントの財布に受けたトークンを記憶するのではなく、保存ファイルに記憶する。
【００３６】
本発明の好適な実施の形態では、小売商が総額をクライアントに払い戻しすることを望むとき、本方法は、以下のステップを備える。
小売商の財布に対応する小売商の第１の記憶領域から、総額に対応する第２の数のトークンを引き出す。
クライアントの第２の財布のトークンに追加される第２の数が所定の最大値を超えないことを検証する。
最大値を超えていないとき、クライアントの第２の財布に第２の数を記憶する。
最大値を超えているとき、処理を中断して、少額決済処理を実行することにより前記クライアントに払い戻しを行うか、或いは、払い戻しを行うことが可能なように、クライアントの第２の財布を空にすることをクライアントに要求するメッセージをクライアントに送る。
【００３７】
このように、払い戻し処理は、一方で、小売商の財布から抽出されたトークンの使用を通して（したがって、クライアントは、小売商から受けたトークンの正当性が保証される）、また、他方で、クライアントの第２の財布で受けたトークンの記憶を通して（第１の財布は、ブローカーによりその正当性が直接保証されたトークンについて確保されたままである）。
【００３８】
さらに、本発明は、クライアントの第２の財布に記憶することができる制限される最大数のトークンのための対策を有効に行う。これにより、１つ以上の小売商により所与のクライアントに与えられるクレジットに関する上限を設けることができる。かかる手順により、小売商により受けたリスク、特に、不正の支払いに関するリスクを低減することが可能である。
【００３９】
好適には、かかる方法は、クライアントの第２の財布から彼の第１の財布にトークンを送出するステップをさらに備えており、該ステップは、以下のサブステップを備える。
クライアントがブローカーに第２の財布に含まれているトークンを第１の財布に送出することを要求するサブステップ。
ブローカーがクライアントの正当性を検証する一方で、他方では、第２の財布に含まれているトークンの正当性を検証するサブステップ。
正当性が検証されたとき、ブローカーは、トークンを第２の財布から第１の財布に送るサブステップ。
【００４０】
このように、本発明によれば、第２の財布から第１の財布にトークンを送出するかかるステップは、ブローカーによるトークンの確認により常に達成される。本発明の好適な実施の形態によれば、かかる送出ステップは、クライアントとブローカーの間のそれぞれの処理の過程で実現される。これにより、１つ以上の小売商により供給されるトークンの正当性に関する正規の検証を保証することができる。
【００４１】
好適には、クライアントがブローカーからトークンを購入することを望むとき、本方法は、以下のステップを備える。
ブローカーが購入されたトークンを第１の財布に送出する。
第２の財布はトークンを含み、ブローカーはトークンの正当性を検証し、トークンが有効であるとき、第２の財布から第１の財布にトークンを送出する。
【００４２】
好適には、小売商３がその銀行口座の貸し方に記入されるように、小売商の財布が所定の整数であるＮ個のトークンの値により借り方に記入されることを望むとき、本方法は、以下のステップを備える。
ブローカーが小売商の財布が少なくともＮ個のトークンを含むことを検証する。
検証が実行されたときに、保存ファイルは、所定の整数であるＭ個のトークンを含み、ブローカーは、小売商の銀行口座の貸し方に（Ｎ＋Ｍ）のトークンを記入し、保存ファイルを空にし、小売商の財布からＮ個のトークンを除く。
【００４３】
このように、小売商により要求された処理に加えて、ブローカーは、確認をシステマティックに実行し、保存ファイルを空にする。これは、特に小売商にとって有効である。
【００４４】
好適には、クライアントが、該クライアントの銀行口座が第１の財布に含まれる少なくとも１つのトークンの値で貸し方に記入されることを望むとき、第２の財布は少なくとも１つの財布を含み、ブローカーが第２の財布に含まれる少なくとも１つのトークンの正当性を検証するステップを実行し、正当性があると検証されたとき、少なくとも１つのトークンを第２の財布から第１の財布に送出する。
【００４５】
このように、クライアントにより要求された処理に加えて、ブローカーは、第２の財布の内容を自動的に確認する。これにより、第２の財布の内容が第１の財布に転送される。これは、クライアントにとって有効である。
【００４６】
本発明の好適な実施の形態では、ブローカー、小売商及びクライアントのそれぞれは、非対称鍵の対を所有し、非対称鍵は、クライアント及び／又は小売商の銀行口座を実現する処理に署名することを可能にする。
【００４７】
特に、上記３者のいずれか１者の銀行口座を実現する処理は、「現実」の金銭を扱い、トークンのような電子通貨を扱かわなない。上記３者は、否認することができないという強い特性を要求し、ブローカーと他の２者のうちの一方との間で議論が存在する筈であり、これは、非対称暗号方式の使用により保証される。
【００４８】
好適には、２者間の処理のうちの１つの過程で交換されるメッセージは、マスターキー及び２者のうちの少なくとも一方の識別から決定され、導出される対称鍵を使用して証明される。
【００４９】
このように、クライアントが参加する処理の場合、鍵はクライアントの認証から導出される。処理がブローカー及び小売商を含む場合、鍵は小売商の認証から導出される。このようにして、クライアント端末にマスターキーを記憶する必要がなく、小売商の機器に幾つかのマスターキーが記憶される必要がある。
【００５０】
好適には、該処理のそれぞれは、固有の対称鍵を実現し、該固有な対称鍵は、以下の処理を備えるグループに属する処理のうちの１つについてのみ使用可能である。
ブローカーが、少なくとも１つのトークンをクライアントの第１の財布に送出すること。
ブローカーが、少なくとも１つのトークンを小売商の財布に送出すること。
小売商が、クライアントからの製品及び／又はサービスについての支払いを要求すること。
クライアントが、製品及び／又はサービスについて小売商に支払うこと。
クライアントが、購入の証明を小売商に提供すること。
小売商が、クライアントに払い戻しすること。
ブローカーが、クライアントの少なくとも幾つかのトークンを買い戻しすること。
ブローカーが、小売商の少なくとも幾つかのトークンを買い戻しすること、
このようにして、異なる鍵を使用したそれぞれの少額決済処理、該処理の手順が非常に強化される。特に、唯一の鍵に関する妥協は、全体の手順を妥協するものではなく、妥協された鍵に対応する処理のみである。
【００５１】
本発明の好適な技法によれば、クライアント及び／又は小売商により所有されるかかる対称鍵は、以下の処理のうちの一方についてのみ使用することができる。これにより、かかるデータを否認することができないことを保証する。
該処理のうちの１つの過程で交換されるメッセージの発生元及び保全を認証することを可能にするデータの生成。
該データの検証。
【００５２】
認証データ（ＭＡＣ： Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の生成及び検証のための鍵の選択的な使用は、データを否認することができないことを保証することを可能にするものであって、（小売商に関係のある）クライアントのスマートカードに（小売商とは無関係な）クライアントの鍵を記憶することにより、本発明の好適な実施の形態に従い可能となる。スマートカードの実行可能なコードを変更することが不可能であることは、鍵を認証データの生成及び検証に選択的に委任する。
【００５３】
このように、鍵が妥協されない限り、ＭＡＣは、１つのスマートカードによる以外に生成することができず、これにより、たとえば、クライアントは支払いを否認することができない。仮に、本発明に従い実現される技法とは対照的に、対称鍵をＭＡＣの生成及び確認の両者のために使用することができる場合、少なくとも２つのスマートカード（それぞれ一方がクライアント、他方が小売商）が所与のＭＡＣに生成することができ、クライアントは、支払いを否認することができる。
【００５４】
本発明は、先に説明された少額決済処理を管理するためのシステムにおけるクライアント端末に関し、該処理は、少なくとも１つのブローカー、及び／又は製品及び／又はサービスに関する少なくとも１つの小売商、及び／又はクライアントの間でトークンの交換を実現する。クライアント端末は、少なくとも１つの第１の財布と少なくとも１つの第２の財布に対応する、トークンを記憶するための少なくとも２つの異なる領域を備える。
【００５５】
この第２の財布は、ブローカーによりクライアントに供給されたトークンを備えることができ、第２の財布は、小売商によりクライアントに供給されたトークンを備えることができる。
【００５６】
好適には、かかる２つの記憶領域は、該端末に含まれるセキュアプロセッサに位置されるか、或いは、該端末により読取ることができるデータサポートに位置される。
【００５７】
特に、かかるデータサポートは、スマートカード、或いは任意の他のセキュアデータサポートとすることができる。
【００５８】
また、本発明は、先に説明された少額決済処理を管理するためのシステムにおける、小売商の機器に関する。該処理は、少なくとも１つのブローカー、及び／又は少なくとも１つのクライアント、及び／又は小売商の間でのトークンの交換を実現する。該機器は、トークンを記憶するための少なくとも２つの個別の領域を備えている。
【００５９】
好適には、かかる２つの記憶領域は、小売商の財布及び小売商の保存ファイルである。小売商の財布は、ブローカーにより小売商に供給されたトークンを備えることができ、保存ファイルは、クライアントにより小売商に供給されたトークンを備えることができる。
【００６０】
［発明の実施の形態］
本発明の他の特徴及び効果は、簡単で例示的かつ限定するものではない実施例及び添付図面を通して、好適な実施の形態の以下の記載を読むことにより、さらに明らかとなるであろう。
【００６１】
本発明の一般的な概念は、少額決済処理を管理するためのシステムのクライアントのそれぞれについて、トークンを記憶するための２つの個別の領域の存在に基づいている。これらの２つの記憶領域は、たとえば、小売商の利用不可能な項目についての払い戻しのために、或いはクライアントが参加したゲームの当りとして、ブローカーにより供給されるトークンを含むクライアントの第１の財布、及びクライアントが１つ以上の小売商から受けたトークンを記憶する第２の財布に対応している。
【００６２】
これら２つの財布のそれぞれは、それぞれの財布が含むことができるトークンの最大の数に対応する所定の最大の総額に関連している。
【００６３】
図１に提供されているのは、たとえば、世界的なインターネットネットワークの中継を通して実現される、クライアント２から小売商３への少額決済処理に関する実施の形態である。
【００６４】
少額決済処理に参加するために、クライアント２は、たとえば、以下に示される２つのエンティティからなる場合がある端末を使用する。
スマートカードは、データストレージの安全を確保する手段、また、クライアント２を認証する手段として使用される。テレビチャネルの支払いの管理のような、他の機能を有するこのスマートカードを適用することもできる。
マルチメディアデジタルデコーダは、スマートカードリーダを備えており、小売商３及びブローカー１と通信することができる。
【００６５】
また、クライアント２は、（たとえば、スマートカードの手段を統合する）任意の他のタイプの適切な端末から本発明に従う少額決済処理を実現する。
【００６６】
なお、図１における参照符号４は、説明の便宜上、クライアント２及び／又は小売商３の銀行を表している。勿論、小売商３及びクライアント２が同じ銀行４又は異なる銀行４の顧客とすることが可能である。
【００６７】
任意の購入の前に、クライアントの第１の財布及び第２の財布が空である場合、クライアント２は、ブローカー１からトークンを取得しなければならない。これを考慮に入れて、クライアント２は、参照符号１２のステップの過程で、クライアントが調達することを望むトークンの値に等しい量だけ、銀行４におけるクライアント２に属する銀行口座の借り方に記入する許可をブローカー１に送る。
【００６８】
たとえば、クライアント２は、ブローカー１に対して電子チェックに署名する。クライアント２により送出される支払い許可は、クライアント２の銀行から支払いを得るための全ての必要な情報をブローカー１に与える。
【００６９】
銀行４により支払いが行われた後、ブローカー１は、参照符号１３のステップの過程で所望のトークンをクライアント２に送る。
【００７０】
図１に示されていないステップの過程で、クライアント２は、小売商３から調達することを望む製品及び／又はサービスを選択し、注文用紙に記入し、小売商３に送出する。たとえば、クライアント２は、小売商３のウェブサイトからアクセス可能な注文用紙に記入する。次いで、小売商３は、クライアント２からの商品及び／又はサービスのための支払いを要求する。
【００７１】
本発明による少額決済処理に参加するために、幾つかのエンティティのタイプを備える機器を小売商３に設けることが可能である。
１つ以上のスマートカード及び／又はセキュアプロセッサは、セキュアデータストレージ領域、及び／又は小売商３の認証手段、及び／又はデータ暗号化手段として使用される。
サーバは、幾つかのクライアント２と同時に実現される処理に対応することが可能である。
【００７２】
次いで、クライアント２は、参照符号１４のステップの過程で注文された製品及び／又はサービスのための少額決済を実行する。
【００７３】
これを考慮して、クライアント２は、調達された製品及び／又はサービスの値に対応する多数のトークンを小売商３に送出する。このトークンは、第１の財布が十分なトークンを含む場合に、クライアント２の第１の財布から引き出される。
【００７４】
逆のケースでは、クライアント２は、第１の財布が空になるまで、第１の財布からトークンを引き出す。必要であれば、クライアント２は、少額決済を実行するために、第２の財布から足りない数のトークンを引き出す。
【００７５】
少額決済を受けた後、小売商３は、参照符号１５のステップの過程で注文された製品及び／又はサービスを送る。小売商３がクライアント２から受けたトークンは、保存ファイルに記憶される。
【００７６】
次いで、小売商３は、銀行４に有する銀行口座について、クライアント２から受けたトークンの値に対応する金額だけ、貸し方に記入することを望む場合がある。また、小売商３が彼の銀行口座の貸し方に対応する値を記入する前に、小売商３が、所定数のトークンを有するまで、クライアント２から受けたトークンを保持することも可能である。
【００７７】
次いで、参照符号１６のステップの過程で、小売商３は、保存ファイルに含まれるトークン、又はこれらトークンのうちの幾つかをブローカー１に与える。また、小売商３は、財布に含まれるトークンをさらに与えることもできる。ブローカー１は、受けたトークンの正当性を検証する。この検証の後、参照符号１１のステップの過程で、ブローカー１は、受けた有効なトークンの値に対応する総額を、小売商３の口座に転送ための命令を銀行４に送出する。
【００７８】
また、ブローカー１は、参照符号１７のステップの過程で、小売商の銀行口座が確かに貸し方に記入されたことを保証するために、銀行４に宛てられた転送命令のコピーを小売商３に送出する。
【００７９】
図２において以下に記載されるのは、小売商３がクライアント２に払い戻しすることを望むとき、或いは、たとえば、クライアントが小売商３で参加したゲーム及び／又は宝くじに関してクライアント２の勝利に対応する多数のトークンをクライアントに送出するとき、本発明に従い実現される処理である。
【００８０】
小売商３は、ブローカー１から調達したトークンで彼の財布を満たすことにより開始する。特に、小売商３がブローカー１から購入したトークンのみが、クライアント２に払い戻しするために使用することができる。小売商３は、クライアント２に払い戻すための保存ファイルに記憶されている任意のトークンを使用することができない。これは、クライアント２のために追加のセキュリティを与える。
【００８１】
これを考慮に入れて、参照符号１２のステップの過程で、小売商３は、支払いのための認証をブローカー１に対して送る。参照符号１１のステップの過程で、この認証は、小売商３の銀行４に小売商の銀行口座から金銭を引き出すことを要求するための全ての必要な情報をブローカー１に供給する。
【００８２】
次いで、参照符号１３の過程で、ブローカー１は、支払いとして銀行から受けた総額に対応する多数のトークンを小売商３に送出する。これらのトークンは、小売商により彼の財布に記憶される。たとえば、小売商の財布は、スマートカードに含まれている。
【００８３】
参照符号２１のステップの過程で、クライアントが確かに払い戻しされるべきであることを主張するために、或いは、たとえば、クライアントが所持している当りの宝くじのチケットを与えるために、クライアント２は、購入の証明を小売商３に供給する。
【００８４】
次いで、参照符号１４のステップの過程で、小売商３は、クライアント２の少額決済を実行する。小売商３は、支払われるべき総額に対応する多数のトークン、又はクライアント２の当りの値に対応する多数のトークンをクライアント２に送出する。
【００８５】
この送出の前に、クライアント２に送出することを望むトークンの数がクライアントの第２の財布に記憶することができる最大のトークン数以下であることを小売商３が検証することも可能である。又は、このトークンの数とクライアントの第２の財布に既に含まれる任意のトークンの総和が許可された最大のトークン数を超えないことを小売商３が検証することも可能である。
【００８６】
逆のケースでは、たとえば、本発明の主題ではない多額決済処理を実現することにより、小売商３がクライアント２に払い戻しすることは可能である。また、小売商３が、払い戻しされることが可能であるように、又は彼の当りを得るように、クライアントの第２の財布を空にすることを要求するメッセージをクライアント２に送出することも可能である。
【００８７】
これらのトークンは、たとえば、スマートカードに含まれる場合があるクライアント２の第２の財布に記憶される。これらのトークンの正当性は、クライアント２とブローカー１の間で連続して実現される最初の処理の過程で検証される。次いで、参照符号１６のステップの過程で、クライアント２は、クライアント２の第２の財布に含まれるトークンをブローカー１に与える。
【００８８】
トークンの正当性の検証の後、参照符号２２のステップの過程で、ブローカー１は、正当性のあるトークンの数をクライアント２に送出する。ついで、これら検証されたトークンは、クライアント２により彼の第１の財布に記憶される。
【００８９】
変形例となる実施の形態によれば、クライアント２が銀行４に有する銀行口座が正当なトークンの値に対応する額で貸し方に記入されることを、クライアント２が好む場合がある。次いで、参照符号１１のステップの過程で、ブローカー１は、転送命令をクライアント２の銀行に送出する。次いで、ブローカー１が、彼の銀行口座が確かに貸し方に記入されることを確認するために、この転送命令のコピーをクライアント１に送出することも可能である。
【００９０】
クライアント２の第２の財布に含まれるトークの正当性は、クライアント２とブローカー１に関わる処理のそれぞれの過程で、ブローカー１によりさらに検証することができる。
【００９１】
図３に示されるのは、クライアント２又は小売商３が、ブローカー１の財布に含まれる全て又は一部のトークンから払い戻しすることをブローカー１に望むときに実現される処理である。
【００９２】
参照符号３１のステップの過程で、クライアント２又は小売商３は、Ｎ個のトークンを買い戻しするための注文をブローカー１に送出する。
【００９３】
参照符号３２のステップの過程で、ブローカー１は、クライアント２及び／又は小売商３にＮ個のトークンの買戻しに関する確認を送出する。
【００９４】
参照符号１１のステップの過程で、クライアント２及び／又は小売商３の銀行口座が貸し方にＮ個の買戻しされたトークンの値に対応する総額が記入されるように、ブローカー１は、転送命令をクライアント２及び／又は小売商３の銀行４にさらに送出する。
【００９５】
これらＮ個のトークンは、小売商３の財布及び／又は保存ファイルから生じる場合があるのと同様に、クライアント２の第１の財布及び／又は第２の財布から生じる場合がある。クライアント２の第２の財布、及び小売商３の保存ファイルから生じるトークンは、ブローカー１により検証される。ブローカー１は、クライアント２及び／又は小売商３の銀行口座の貸し方にそれらの値に対応する総額を記入する前に、その正当性を判定する。
【００９６】
なお、本発明は、所与のトークンについて４つの可能な経路の存在のために、トークンを追跡可能にする。かかる追跡可能なことにより、様々な参加者の間、いわばブローカー１、及び／又はクライアント２、及び／又は小売商３の間で行われる処理のセキュリティを強化することが可能となる。
【００９７】
特に、それぞれのトークンは、ブローカー１により作成され、以下のメカニズムに従い、その使用の最後でブローカー１に戻される。
少額決済処理の過程で、トークンは、ブローカー１により発行され、クライアント２に送出され、次いで小売商３に送出される。小売商３は、該トークンをブローカー１に送出し返す。
払い戻しの過程で、トークンはブローカー１により発行され、小売商３に送出され、次いでクライアント２に送出される。クライアント２は、該トークンをブローカー１に送出し返す。
クライアント２の財布の中身を買い戻す場合、ブローカー１により作成され、次いでクライアント２に第１の財布に記憶されるトークンは、ブローカー１に送出し返される。
最後に、ブローカー１により作成され、小売商３の財布に記憶されるトークンは、ブローカー１により買い戻すことができる。
【００９８】
本発明の好適な実施の形態では、トークンの監査は、以下のやり方で実現される。
ブローカー１が所与の参加者（クライアント２及び／又は小売商３）にトークンを送出するとき、ブローカー１は、この参加者に委託されたトークンの全体数を記録し、ブローカー１が所与の参加者からトークンを買い戻すとき、この数を更新する。
ブローカー１がトークンの正当性を検証するとき、ブローカー１は、ブローカー１がこれらのトークンを最初に委託した参加者に同一性を知る。ブローカー１は、この参加者に関して検証したトークンの全体数を記録する。
ブローカー１は、検証されたトークンの全体数を委託されたトークンの全体数と比較する。関連する参加者が小売商３である場合、検証されたトークンの全体数は、委託されたトークンの全体数以下でなければならない。関連する参加者がクライアント２である場合、検証されたトークンの全体数は、検証されたトークンの全体数と、クライアント２の第２の財布に記憶することができるトークンの最大数との合計以下でなければならない。逆のケースでは、本発明により、トークンが関連する参加者（クライアント２及び／又は小売商３）により作成されていることを判定することが可能である。
【００９９】
本発明によれば、ブローカー１及び又は小売商３及び／又はクライアント２の間の交換のうちの少なくとも幾つかを保障するために、暗号化処理をさらに実現することができる。
【０１００】
たとえば、クライアント２及び小売商３の銀行口座に関わる全ての処理は、非対称な暗号化の助けにより保護される。特に、かかる処理は、（多数のトークンとは対照的に）金銭の「真」の総額を実現し、したがって、否認することができないという強い特性を示さなければならない。
【０１０１】
本発明の好適な実施の形態によれば、全ての処理は、対称暗号方式により保護される。
【０１０２】
図１〜図３により例示される銀行口座を実現する全ての処理について、ブローカー１及び／又は小売商３及び／又はクライアント２は、彼等が所持している非対称鍵の対を使用する。
【０１０３】
２者（ブローカー１及び／又はクライアント２及び／又は小売商３）の間の（銀行口座を実現しない）処理の過程で交換されるメッセージを認証するために、２人の参加者のうちの一方の同一性から導出された対称鍵、及びマスター鍵を使用することが好ましい。たとえば、クライアント２に関わる処理の過程で、鍵はクライアントの同一性から導出される。小売商３とブローカー１に関わる処理の過程で、鍵は、小売商３の同一性から導出される。
【０１０４】
本発明の好適な実施の形態によれば、それぞれの対称鍵は、以下のような予め決定されたタイプの処理及び／又は検証のために特に使用される。
ブローカー１により、クライアント２の第１の財布にトークンを記憶する。
ブローカー１により小売商３の財布にトークンを記憶する。
クライアント２から支払いのために小売商３に要求する。
クライアント２の第１の財布及び／又は第２の財布から購入のために小売商３に少額決済する。
クライアント２の購入の証拠を検証する。
小売商３によるクライアント２が払い戻しする。
ブローカー１によりクライアント２のトークンを買戻しする。
ブローカー１により小売商３のトークンを買戻しする。
【０１０５】
本発明の好適な実施の形態によれば、エラーメッセージを管理するためのシステムは、図１〜図３により例示される全ての処理の過程で実現される。
【０１０６】
たとえば、以下のような処理の過程でエラーが生じた場合、クライアント２及び／又はブローカー１及び／又は小売商３にエラーメッセージを発行することも可能である。
データ認証エラー。
少額決済の過程で、クライアント２は、小売商３に支払うための十分な数のトークンを有さない。
払い戻し処理の過程で、クライアント２により与えられた購入の証明が無効である。
ブローカー１によるトークンの検証の過程で、幾つかのトークンは無効である。
【図面の簡単な説明】
【図１】
クライアントが小売商から製品及び／又はサービスを購入することを望むとき、本発明に従い実現される処理の概念を与える図である。
【図２】
小売商がクライアントに払い戻しを望むとき、図１の各参加者の間で実現される処理の概念を与える図である。
【図３】
クライアント及び／又は小売商が彼の財布の内容を彼の銀行の口座に転送することを望むとき、図１の各参加者の間で実現される処理を例示する図である。
【国際公開パンフレット】
2004503018.tif 000003
2004503018.tif 000004
2004503018.tif 000005
2004503018.tif 000006
2004503018.tif 000007
2004503018.tif 000008
2004503018.tif 000009
2004503018.tif 000010
2004503018.tif 000011
2004503018.tif 000012
2004503018.tif 000013
2004503018.tif 000014
2004503018.tif 000015
2004503018.tif 000016
2004503018.tif 000017
2004503018.tif 000018
2004503018.tif 000019
2004503018.tif 000020
2004503018.tif 000021
2004503018.tif 000022
2004503018.tif 000023
2004503018.tif 000024
2004503018.tif 000025
2004503018.tif 000026
2004503018.tif 000027
2004503018.tif 000028
2004503018.tif 000029
2004503018.tif 000030
2004503018.tif 000031
【国際調査報告】
2004503018.tif 000032
2004503018.tif 000033
2004503018.tif 000034
2004503018.tif 000035
2004503018.tif 000036
2004503018.tif 000037