スマートカードに基づくバリュー移転
バリュー移転スキームにおいて、ユーザは、プログラム可能な装置、例えば少なくとも１つの利用可能な財貨バリューを表すデータをもつことができるスマートカードを提供される。ユーザのアカウントを表すデータは、遠隔処理ステーションで保持される。ユーザ間の取引は、ユーザのそれぞれのスマートカード間のオフラインでのデータ交換によって実行され、交換されるデータは、開始された各取引の記録を含む。遠隔処理ステーションで保持される各ユーザのアカウントのユーザ・アカウント・データは、ユーザのスマートカードが遠隔処理ステーションにオンライン接続され、スマートカードのデータが遠隔処理ステーションにアップロードされるときだけ、更新される。本発明のスキームは、好都合なことに、セキュリティ保護されたデータ移転を管理するのに使用されるＩＴＳＯスキームに基づくものであってもよい。このスキームは、セキュリティ保護された複数財貨のバリュー移転システムを提供することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カード対カードの取引を含む、スマートカードを使用した複数の単位を用いた財貨（ｃｏｍｍｏｄｉｔｙ）のバリュー移転を可能にするスキームに関する。この文脈において、「財貨」という言葉は、例えば通貨を含む、価値を有すると受け取られている全てのものを表すのに使用されるものとする。
【背景技術】
【０００２】
カード対カードの取引とスマートカードに基づく「電子財布」スキームとは、過去２０年間に渡って、研究と設計活動との対象となってきた。それぞれ異なる規格と技術とを使用した、数多くの異なるスキームが定められてきた。例えば、「Ｍｏｎｄｅｘ」スキームは、カード対カードにおける「無損失」のバリュー移転を提供する。いかなる新規スキームも、理想的には、少なくとも一部の既存スキームで動作できるべきである。従って、ここで提案されるアプローチは、可能な限り「オープン・スタンダード」を活用するものである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
いかなる新規スキームも、その全体的な目標は、銀行カードによって提供される支払システムの実行可能な代案を作り出すことにある。バリューの流通は、オフライン取引能力のユビキタスな利便性を通して刺激されるべきであるが、同時に、この流通は、不正行為を防止し、このスキームの提供による収益が回収できるように、強力なガバナンスを提供するために制御され監視される必要がある。即ち、カード所有者は、かなり頻繁に、ただし不便と感じられるほどには頻繁ではなく、オンライン接続してサービスの使用を続けるよう、義務付けられるべきである。
【０００４】
また、以前に特定の仲介業者と特定の財貨の取引をしたことがないカードにも、バリュー移転ができるようにすべきである。これは、仲介業者から見た場合、新たなアカウント所有者をもたらすという追加のメリットがある。なぜなら、新たに獲得したそのバリューを登録するためには、新規のアカウントを開設する必要があるからである。
【０００５】
このようなスキームが実行可能、即ち実行できるほどセキュリティ保護されているためには、そのような一切のスキームは、以下の機能を含むべきである。
カード対ホストのログオンは、一般にはカードを所持していることと別個のＰＩＮ（個人識別番号）を知っていることという、２つの異なるファクタを活用して、アカウント所有者の認識をセキュリティ保護されているものとする遠隔認証を提供すべきである。
【０００６】
財貨取引機能は、カード対ホストとカード対カード、即ち対面取引と遠隔取引との両方を許可すべきである。
好ましくは、同一カード上に、複数の仲介業者からの複数の財貨が存在しているべきである。これが達成された場合、この要件はオープン・システムを示唆する。
【０００７】
スキーム中に、既存または新規の仲介業者から、また既に流通中のカードに対して、例えば銀、パラジウム等の新たな財貨が導入できるべきである。
異なる仲介業者の財貨間のやり取りが実現できるようにすべきである。言い換えれば、使用される技術は、スキームが、財貨の仲介業者とその競合相手とが同一カード・ベース内で相互運用できるようなオープン・システムになることができるようにする必要がある。
【０００８】
スキームは、異なる保証金体系が適用できるように、「店舗」が使用するカードを「消費者」ではないものと認識する能力を有するべきである。
消費者対店舗という状況において、消費者のカードの「資金不足」による取引の失敗を防ぐための対策を講じるべきである。この場合、システムは、カードがオンラインでホストに接続し、利用可能な資金をカード所有者へ更にダウンロードして、取引の再試行ができるようにするというオプションを支援すべきである。
【０００９】
上に要点をまとめたようなスキームを導入するに当たって、利用可能なオープン・スタンダード技術を選択して採用することができる。表面的には、このようなスキームの要件は、ＥＭＶ（Ｅｕｒｏｐａｙ，ＭａｓｔｅｒＣａｒｄ＆Ｖｉｓａ）２０００（「EMV2000 Integrated Circuit Card Specifications for Payment Systems, Book 1: Application Independent ICC to Terminal Interface Requirements」Version 4、２０００年１２月EMVCo, LLC ("EMVCo")発行と、「M/Chip 4 Card Application Specifications for Debit and Credit」Version 1.0、２００２年１０月発行と、「Visa Integrated Circuit Card: Card (ICC) Specification」Version 1.4、２００１年１０月Visa International発行とを参照のこと）に見られる事前承認されたオフライン型デビット・プロファイルに極めて似ている。しかし、これらのスキームは、オープンな形で複数の財貨に対応しておらず、特に、そのような財貨の追加、削除または改変の動的管理を提供しない。より根本的には、ＥＭＶは、カード対カードの取引を取り扱うことができない。
【課題を解決するための手段】
【００１０】
本発明によれば、バリュー移転スキームが提供され、そこでは、少なくとも１つの利用可能な財貨価値を表すデータを保持できるプログラム可能な装置がユーザに提供され、ユーザ・アカウントを表すデータが遠隔処理ステーションで保持され、そこでは、ユーザ間の取引がユーザの各々のプログラム可能な装置間でのオフラインのデータ交換によって成立し、交換されるデータが開始された１つのまたはそれぞれの取引の記録を含み、そこでは、遠隔処理ステーションで保持される各ユーザ・アカウントのユーザ・アカウント・データは、そのユーザのプログラム可能な装置がオンラインで遠隔処理ステーションに接続され、そのプログラム可能な装置から遠隔処理ステーションへデータがアップロードされた後にのみ、更新される。
【００１１】
本発明は、更に、スキームで使用するインターフェース装置、及び、利用可能な財貨価値を表す少なくとも１つのデータ・ファイルとインターフェース装置を使って他のユーザのプログラム可能な装置に対してオフラインでインターフェースするための手段とをもつプログラム可能な装置の双方を提供する。
【発明を実施するための最良の形態】
【００１２】
以下に、本発明によるスキームを、本発明によるスキームのハイレベル・アーキテクチャを示すブロック図である図面を参照しながら詳述する。
本発明のスキームは、先に提案したように、オープン・スタンダードであるＩＴＳＯスキームに由来する技術に基づいている。本明細書では、「ＩＴＳＯ」は、イギリス政府によって開発され、欧州規格ＥＮ １５４５に組み入れられたスマートカードのためのＩｎｔｅｒｏｐｅｒａｂｌｅ Ｔｉｃｋｅｔｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ Ｓｃｈｅｍｅ（相互運用可能なチケット発行取引スキーム）の現在利用可能なまたは将来利用可能となる全てのバージョンを表すものとする。
【００１３】
ＩＴＳＯは、仕様と、組織と、オープンなスキームと、技術的アーキテクチャと、からなる標準的な組を提供する。ＩＴＳＯにより、接触型と非接触型の両方で、チケット発行に基づくスマートカード・アプリケーションの作成が可能になった。
【００１４】
先に述べたＥＭＶスキームは、１つの銀行のカードを所有する顧客に対しては、クレジットまたはデビットに基づく支払方法を提供すると同時に、他の銀行の店舗である顧客に対しては、支払いの引受けと集金とを可能にする。
【００１５】
ＩＴＳＯも、ある程度類似した原理で動くが、ただしスキームのセキュリティを実施することで当事者間の信用を保証する。
どんなマルチ・ユーザ・スキームでも、参加する当事者、即ち店舗が生じた収入または移転されたバリューの正当な分け前を確実に受け取れることが、絶対不可欠である。正確な収益の割り当てを実現するためには、完全性と完璧さが保証されるように１つ１つの取引を捕捉し、その後清算できるような、全てを考慮したスキームを作る必要がある。更に、取引記録のどのログも、その完全性が保証され、清算と割当てのためのその後の移転が保証されなければならない。
【００１６】
ＩＴＳＯは、これらの様々な要件を、オフラインにおいてセキュリティを可能にし、実施することで達成する。これは、輸送スキームにおいては、全ての発券機と改札口とに存在し、ＩＴＳＯのセキュリティ・マネージャー・モジュールで管理される、不正使用ができないセキュア・アクセス・モジュール（「ＩＴＳＯ ＳＡＭ」または「ＩＳＡＭ」）を提供することで達成される。ＩＳＡＭは、スキームの「警察官」またはセキュリティ執行者のように行動し、全てのチケット取引に参加する。ＩＳＡＭは、提示された全てのチケットの完全性をチェックし、全ての取引を保証する。本発明のスキームでは、カードとインターフェースする１つ１つの端末には、オンラインかオフラインかにかかわらず、ＩＳＡＭが組み込まれているものと期待される。
【００１７】
ＩＴＳＯスキームは更に、ＩＳＡＭの暗号機能によってセキュリティ保護された様々なソフト・チケット・テンプレートを指定する。これらのチケット・テンプレート内で、任意のスキーム運営者が「所有」するチケット商品は、１つ１つのチケット商品が同様にＩＳＡＭに保管され、ＩＴＳＯセキュリティ・マネージャーによって管理される自らの鍵をもつことができるおかげで、作成し処理することができる。これらのソフト・チケットは、カード・プラットホーム技術からは独立している。これで、ＩＳＯ １４４４３に適合するいかなるカードも、それがメモリのみかＣＰＵに基づくものであるかにかかわらず、単一アプリケーション用カード上に単独で、あるいはマルチ・アプリケーション・カード上で他のアプリケーションと共にＩＴＳＯチケット・ウォレットをもつことができる。
【００１８】
ＩＴＳＯスキームの中心には、ＩＴＳＯセキュア・アプリケーション・モジュール即ち「ＩＳＡＭ」が位置し、その下にあるプラットホームは、ＩＳＯ ７８１６準拠のＨｉｇｈ Ｃａｐａｃｉｔｙ Ｃａｒｄ（大容量カード）である。このカードは、４メガバイトを超えるセキュアメモリをもち、ＩＳＡＭは、６００Ｋｂ／ｓ以上で通信可能である（ＩＳＯ ７８１６ Ｔ＝１）。ＩＳＡＭは、ＲＳＡとトリプルＤＥＳ等の、ハードウェアによって加速された暗号機能のフル・セットを含む。一般に、これらは全て、例えば携帯電話に使用されている種類のＧＳＭ ＳＩＭ等のソケットに収まるように標準的なＩＳＯ ７８１０及びＩＤ−０００フォーム・ファクタで提供することができる。ＩＳＡＭは、国際的に認知されたセキュリティ保証方法であるＣｏｍｍｏｎ ＣｒｉｔｅｒｉａのＡＥＬ ４を満たすように開発された。
【００１９】
ＩＴＳＯスキームでは、各カードは、１つまたは複数の「ｅチケット」をもつことができる。これらは、スキームに参加する店舗から、代金と引き換えに入手される。カード所有者が店舗からｅチケットを購入するとき、ｅチケットを形成するデータ・ファイルは、ＩＳＡＭを含むインターフェース装置からスマートカードにロードされる。カード所有者が旅行をするために購入したチケットを使用したいと考える場合、ｅチケット・ファイルは、スマートカードからＩＳＡＭを含むインターフェース装置にダウンロードされる。従来のＩＴＳＯスキームでは、双方向の流れもカード対カードの取引も提供されないことが理解されよう。従って、一見したところでは、ＩＴＳＯスキームは、複数財貨のバリュー移転スキームの基盤として、先に述べたＥＭＶスキームと同じ不都合を幾つかもっている。
【００２０】
しかし、ＩＴＳＯスキームは、先に述べた機能を有する実行可能なバリュー移転スキームを提供するように適合させることができることを本発明者らは認識している。
本発明のスキームは、各カードに常駐している各財貨アカウント毎に１つ提供される、複数の「ｅ小切手帳」を提供することに依拠している。これらのｅ小切手帳の構造は、ＩＴＳＯチケット・テンプレート（参照により本明細書に組み込まれる「ITSO Specification Part 2: Card and Basic Data structure」Version 2、２０００年１１月発行と、「ITSO Specification Part 5: Card format and Data Records」 Version 2、２０００年１１月発行とを参照のこと）に基づいている。各ｅ小切手帳は、事実上、暗号の使用によってその完全性が実施されるデジタル証明書、即ち１組のデータである。カード発行者が許可を与えると仮定した場合、複数の財貨仲介業者からの複数のアカウントを表す複数のｅ小切手帳が、外出先でもカードにロードしまたはカードから削除することができる。従って、このスキームは、同一カード上での複数の仲介業者からの複数の財貨の存在を可能にする。
【００２１】
各ｅ小切手帳の内容を検証し改変するのに使用される鍵も、各カードに記録されている。各ｅ小切手帳はそれ自体の鍵をもつことができるため、スキーム全体に渡ってアカウントのプライバシーとセキュリティとが保証される。このスキームは、全ての鍵の生成と使用の責任をもつセキュリティ管理システム（ＳＳＭＳ）を備える。更に、ｅ小切手帳のセキュリティ保護されたローディングと削除の責任をもつアプリケーション管理システム（ＡＭＳ）があり、これはＳＳＭＳによって管理された鍵を利用する。
【００２２】
カード所有者間の取引は、オフラインで電子小切手（「ｅ小切手」）を移転することで実行される。
ｅ小切手帳は、ＩＴＳＯ ＩＰＥ（Ｉｎｔｅｒｏｐｅｒａｂｌｅ Ｐｒｏｄｕｃｔ Ｅｎｔｉｔｙ：ｅチケットを意味するＩＴＳＯ用語）と似ており、小切手は、ＩＴＳＯチケット取引記録と似ている。小切手のセキュリティ保護されたローディング及び削除と、各小切手帳の残高のホスト対カードの増減（参照により本明細書に組み込まれる「ITSO Specification Part 4: Back Office Systems」Version 2、２０００年１１月発行を参照のこと）とは、ＩＴＳＯセキュア・フレーム・メッセージング（参照により本明細書に組み込まれる「ITSO Specification Part 7: Security Access Module Version 2、２０００年１１月発行を参照のこと」によって管理される。
【００２３】
ＥＭＶスキームとは異なり、ｅ小切手自体は、何らかの形の電子財布またはアカウントに貯えられた財貨価値を変更するのではなく、むしろ、将来起こるであろう取引の記録として働く。これは、従来型の銀行口座の小切手に全く類似している。即ち、資金の移転を実行するのは小切手を切って受取人に手渡すことではなく、むしろ受取人の銀行口座を介して小切手を換金することである。
【００２４】
カード対カードの取引は、新たな「小切手」を記憶するのに利用可能なメモリがなくなるか、あるいは「小切手カウンタ」がトリップするまで、オフラインで繰り返すことができる。この時点で、カードをオンラインでスキーム・ホストに接続して「小切手を現金化」する必要がある。即ち、中央交換処理センターで手続きを済ますために、取引は、カードからアップロードされる。
【００２５】
カードがホストにオンライン接続する際、まずその一意のＩＤが、ＳＳＭＳに渡される。ＳＳＭＳは、スキーム鍵でセキュリティ保護されたメッセージの形でカードに固有のチャレンジを送る。ただ１枚の有効なカードのみが、正しく応答することができる。この応答は、ＰＩＮなどのカード所有者確認方法の正しい入力にも依存する。従って、この動作は、先に提示した必須要件のリストに提案したような２つのファクタによる遠隔認証を使用したセキュリティ保護された遠隔ログインの働きをする。この一意のＩＤは、ホストが「店舗」カードを認識し、消費者のカードと区別できるようにする。
【００２６】
従って、本発明のスキームでは、ユーザが「バック・オフィス」、即ちスキームの中央処理拠点にオンライン接続するまで、カード間でのｅ小切手の交換が、オフラインで行われる。接続した時点で、ｅ小切手はダウンロードされ、電子財布とアカウントがオンラインで更新される。
【００２７】
先に述べたように、ＩＴＳＯ輸送関連スキーム自体は、カード対カードを提供する必要がないため、本発明者は、本発明のバリュー移転スキームでこれを可能にするように、ＩＴＳＯ構造を改変しなければならなかった。
【００２８】
２つのカードがインターフェースする際、互換性のあるｅ小切手帳の存在が検証され、認証後、カード所有者検証方法の形で２つのｅ小切手が作成され交換される。これらのうちの一方のｅ小切手は、紙の小切手に類似しており、一方のカードのｅ小切手帳の残高を増加させるように働き、他方のｅ小切手は、他方のカードのｅ小切手帳の残高をそれに対応する額だけ減少させるが、これは紙システムでは小切手控えにつけた記録に類似している。
【００２９】
カード所有者の検証は、既存のシステムでは、ＰＩＮの提供を伴う可能性が高いが、これは、将来的にはバイオメトリクス等の他のカード所有者検証方法に改変することができる。
【００３０】
２つ目のカードが、必要なｅ小切手帳をもたない場合、カードのアクセス権がそれを可能にすることを前提として、新たなｅ小切手帳が作られてその中にバリューが追加される。従って、提案するスキームの機能は、必要に応じて新たな財貨の容易な導入を可能にする。
【００３１】
消費者対店舗という状況において、消費者のカードの資金不足により取引が失敗した場合、消費者のカードがオンラインでホストに接続し、利用可能な資金をカード所有者へ更にダウンロードして、取引の再試行ができるようにする。この操作は、店舗と消費者の双方から完全にトランスペアレントなものでよい。言うまでもなく、これは、店舗の端末がいつものように中央処理拠点に接続しているときのみ可能である。
【００３２】
本発明によるスキームのハイレベル・アーキテクチャを図１に示す。参照番号１０では、カード対カードの取引が実行されたときに起こる状況を示す。各カード所有者のカードは、中央処理拠点１４即ち「バック・ルーム」に接続されていないローカルな端子とインターフェースする。
【００３３】
カード所有者がオンライン接続する必要がある場合、カードは、例えばインターネットまたは他のコンピュータ・ネットワークを用いてバック・ルーム１４に接続された端末１２とインターフェースして、既存のｅ小切手が換金でき、アカウントまたは電子財布のバリューがアップロードまたはダウンロードできるようにする。バック・ルームの操作１６の一部は、新たなカードの発行とパーソナル化も扱う。
【００３４】
表１の参照番号１０におけるように、カード対カードの取引が行われる場合、本発明のスキームは、以下のように動作する。
下記の表１で、ＩＴＳＯ規格に基づくカード対カードのバリュー移転を実施するために、端末とカードとの間に示されたコマンドのシーケンスが提案される。
【００３５】
【表１】
まず、２つのカードの相互認証が、端末によって実施される。何れの場合も、カード所有者は、ＰＩＮまたはカードの真正性を検証するための他の手段を提供するよう求められる。ＰＩＮまたは他の検証が提供されない場合、取引は停止する。
【００３６】
次いで、端末アプリケーション（ＩＳＡＭ）が、各カードからバイナリＤＩＲを読み取って検証し、第１のカードであるカード１からｅ小切手帳バリュー（ＩＰＥ１）を読み取って検証し、他方のカードであるカード２にそれを書き込む。ＩＳＡＭは次いで、第２のカードであるカード２から対応するｅ小切手帳バリュー（ＩＰＥ２）を読み取って検証し、カード１にそれを書き込む。これで、それぞれのカードが、他方のカードのｅ小切手帳バリューの検証済コピーを有するようになる。
【００３７】
第２のカードであるカード２は、次いで、ＭＯＤＩＦＹ ＶＡＬＵＥ ＩＰＥコマンドを内部で作成して、ｅ小切手帳のバリューであるＩＰＥ１から所望の数量を減算し、それによってＩＰＥ１の修正版を作り出す。カード２は同時に、内部のＩＭＡＣコマンドを作成して、その数量がカード１から差し引かれた事実を記録する。
【００３８】
端末は次いで、カード２から改変されたバリューＩＰＥ１を読み出し、他方のカードであるカード１にこれを渡す。カード１は次いで、自らのＩＰＥからどれだけ差し引かれたのかを計算することができ、その数量をＩＰＥ２に加算するためにＭＯＤＩＦＹ ＶＡＬＵＥ ＩＰＥコマンドを内部的に作成する。カード１は、ＩＭＡＣコマンドを作成して、カード２のＩＰＥにその数量が加算された事実を記録する。
【００３９】
端末は次いで、カード１から改変されたＩＰＥ２を読み出し、カード２に書き戻す。好ましくは、端末は更に、取引の詳細を記録するＩＭＡＣログを生成する。
端末は、カードとインターフェースして、カード上に保持されたｅ小切手帳の現在高を更新するが、この情報は、カード所有者がホストにオンライン接続するまではカード所有者のアカウントにおいて更新されない。更に、端末は、ＩＭＡＣログの形をとる「ｅ小切手」を用いて、ｅ小切手帳に影響を及ぼすそれぞれの取引の記録を作成する。
【００４０】
このように、本発明のスキームは、先に列挙した望ましい機能、とりわけ中央処理拠点からオフラインでのカード対カード取引を可能にする複数財貨のバリュー移転スキームを提供することができる。
【図面の簡単な説明】
【００４１】
【図１】本発明によるスキームのハイレベル・アーキテクチャを示す。
【技術分野】
【０００１】
本発明は、カード対カードの取引を含む、スマートカードを使用した複数の単位を用いた財貨（ｃｏｍｍｏｄｉｔｙ）のバリュー移転を可能にするスキームに関する。この文脈において、「財貨」という言葉は、例えば通貨を含む、価値を有すると受け取られている全てのものを表すのに使用されるものとする。
【背景技術】
【０００２】
カード対カードの取引とスマートカードに基づく「電子財布」スキームとは、過去２０年間に渡って、研究と設計活動との対象となってきた。それぞれ異なる規格と技術とを使用した、数多くの異なるスキームが定められてきた。例えば、「Ｍｏｎｄｅｘ」スキームは、カード対カードにおける「無損失」のバリュー移転を提供する。いかなる新規スキームも、理想的には、少なくとも一部の既存スキームで動作できるべきである。従って、ここで提案されるアプローチは、可能な限り「オープン・スタンダード」を活用するものである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
いかなる新規スキームも、その全体的な目標は、銀行カードによって提供される支払システムの実行可能な代案を作り出すことにある。バリューの流通は、オフライン取引能力のユビキタスな利便性を通して刺激されるべきであるが、同時に、この流通は、不正行為を防止し、このスキームの提供による収益が回収できるように、強力なガバナンスを提供するために制御され監視される必要がある。即ち、カード所有者は、かなり頻繁に、ただし不便と感じられるほどには頻繁ではなく、オンライン接続してサービスの使用を続けるよう、義務付けられるべきである。
【０００４】
また、以前に特定の仲介業者と特定の財貨の取引をしたことがないカードにも、バリュー移転ができるようにすべきである。これは、仲介業者から見た場合、新たなアカウント所有者をもたらすという追加のメリットがある。なぜなら、新たに獲得したそのバリューを登録するためには、新規のアカウントを開設する必要があるからである。
【０００５】
このようなスキームが実行可能、即ち実行できるほどセキュリティ保護されているためには、そのような一切のスキームは、以下の機能を含むべきである。
カード対ホストのログオンは、一般にはカードを所持していることと別個のＰＩＮ（個人識別番号）を知っていることという、２つの異なるファクタを活用して、アカウント所有者の認識をセキュリティ保護されているものとする遠隔認証を提供すべきである。
【０００６】
財貨取引機能は、カード対ホストとカード対カード、即ち対面取引と遠隔取引との両方を許可すべきである。
好ましくは、同一カード上に、複数の仲介業者からの複数の財貨が存在しているべきである。これが達成された場合、この要件はオープン・システムを示唆する。
【０００７】
スキーム中に、既存または新規の仲介業者から、また既に流通中のカードに対して、例えば銀、パラジウム等の新たな財貨が導入できるべきである。
異なる仲介業者の財貨間のやり取りが実現できるようにすべきである。言い換えれば、使用される技術は、スキームが、財貨の仲介業者とその競合相手とが同一カード・ベース内で相互運用できるようなオープン・システムになることができるようにする必要がある。
【０００８】
スキームは、異なる保証金体系が適用できるように、「店舗」が使用するカードを「消費者」ではないものと認識する能力を有するべきである。
消費者対店舗という状況において、消費者のカードの「資金不足」による取引の失敗を防ぐための対策を講じるべきである。この場合、システムは、カードがオンラインでホストに接続し、利用可能な資金をカード所有者へ更にダウンロードして、取引の再試行ができるようにするというオプションを支援すべきである。
【０００９】
上に要点をまとめたようなスキームを導入するに当たって、利用可能なオープン・スタンダード技術を選択して採用することができる。表面的には、このようなスキームの要件は、ＥＭＶ（Ｅｕｒｏｐａｙ，ＭａｓｔｅｒＣａｒｄ＆Ｖｉｓａ）２０００（「EMV2000 Integrated Circuit Card Specifications for Payment Systems, Book 1: Application Independent ICC to Terminal Interface Requirements」Version 4、２０００年１２月EMVCo, LLC ("EMVCo")発行と、「M/Chip 4 Card Application Specifications for Debit and Credit」Version 1.0、２００２年１０月発行と、「Visa Integrated Circuit Card: Card (ICC) Specification」Version 1.4、２００１年１０月Visa International発行とを参照のこと）に見られる事前承認されたオフライン型デビット・プロファイルに極めて似ている。しかし、これらのスキームは、オープンな形で複数の財貨に対応しておらず、特に、そのような財貨の追加、削除または改変の動的管理を提供しない。より根本的には、ＥＭＶは、カード対カードの取引を取り扱うことができない。
【課題を解決するための手段】
【００１０】
本発明によれば、バリュー移転スキームが提供され、そこでは、少なくとも１つの利用可能な財貨価値を表すデータを保持できるプログラム可能な装置がユーザに提供され、ユーザ・アカウントを表すデータが遠隔処理ステーションで保持され、そこでは、ユーザ間の取引がユーザの各々のプログラム可能な装置間でのオフラインのデータ交換によって成立し、交換されるデータが開始された１つのまたはそれぞれの取引の記録を含み、そこでは、遠隔処理ステーションで保持される各ユーザ・アカウントのユーザ・アカウント・データは、そのユーザのプログラム可能な装置がオンラインで遠隔処理ステーションに接続され、そのプログラム可能な装置から遠隔処理ステーションへデータがアップロードされた後にのみ、更新される。
【００１１】
本発明は、更に、スキームで使用するインターフェース装置、及び、利用可能な財貨価値を表す少なくとも１つのデータ・ファイルとインターフェース装置を使って他のユーザのプログラム可能な装置に対してオフラインでインターフェースするための手段とをもつプログラム可能な装置の双方を提供する。
【発明を実施するための最良の形態】
【００１２】
以下に、本発明によるスキームを、本発明によるスキームのハイレベル・アーキテクチャを示すブロック図である図面を参照しながら詳述する。
本発明のスキームは、先に提案したように、オープン・スタンダードであるＩＴＳＯスキームに由来する技術に基づいている。本明細書では、「ＩＴＳＯ」は、イギリス政府によって開発され、欧州規格ＥＮ １５４５に組み入れられたスマートカードのためのＩｎｔｅｒｏｐｅｒａｂｌｅ Ｔｉｃｋｅｔｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ Ｓｃｈｅｍｅ（相互運用可能なチケット発行取引スキーム）の現在利用可能なまたは将来利用可能となる全てのバージョンを表すものとする。
【００１３】
ＩＴＳＯは、仕様と、組織と、オープンなスキームと、技術的アーキテクチャと、からなる標準的な組を提供する。ＩＴＳＯにより、接触型と非接触型の両方で、チケット発行に基づくスマートカード・アプリケーションの作成が可能になった。
【００１４】
先に述べたＥＭＶスキームは、１つの銀行のカードを所有する顧客に対しては、クレジットまたはデビットに基づく支払方法を提供すると同時に、他の銀行の店舗である顧客に対しては、支払いの引受けと集金とを可能にする。
【００１５】
ＩＴＳＯも、ある程度類似した原理で動くが、ただしスキームのセキュリティを実施することで当事者間の信用を保証する。
どんなマルチ・ユーザ・スキームでも、参加する当事者、即ち店舗が生じた収入または移転されたバリューの正当な分け前を確実に受け取れることが、絶対不可欠である。正確な収益の割り当てを実現するためには、完全性と完璧さが保証されるように１つ１つの取引を捕捉し、その後清算できるような、全てを考慮したスキームを作る必要がある。更に、取引記録のどのログも、その完全性が保証され、清算と割当てのためのその後の移転が保証されなければならない。
【００１６】
ＩＴＳＯは、これらの様々な要件を、オフラインにおいてセキュリティを可能にし、実施することで達成する。これは、輸送スキームにおいては、全ての発券機と改札口とに存在し、ＩＴＳＯのセキュリティ・マネージャー・モジュールで管理される、不正使用ができないセキュア・アクセス・モジュール（「ＩＴＳＯ ＳＡＭ」または「ＩＳＡＭ」）を提供することで達成される。ＩＳＡＭは、スキームの「警察官」またはセキュリティ執行者のように行動し、全てのチケット取引に参加する。ＩＳＡＭは、提示された全てのチケットの完全性をチェックし、全ての取引を保証する。本発明のスキームでは、カードとインターフェースする１つ１つの端末には、オンラインかオフラインかにかかわらず、ＩＳＡＭが組み込まれているものと期待される。
【００１７】
ＩＴＳＯスキームは更に、ＩＳＡＭの暗号機能によってセキュリティ保護された様々なソフト・チケット・テンプレートを指定する。これらのチケット・テンプレート内で、任意のスキーム運営者が「所有」するチケット商品は、１つ１つのチケット商品が同様にＩＳＡＭに保管され、ＩＴＳＯセキュリティ・マネージャーによって管理される自らの鍵をもつことができるおかげで、作成し処理することができる。これらのソフト・チケットは、カード・プラットホーム技術からは独立している。これで、ＩＳＯ １４４４３に適合するいかなるカードも、それがメモリのみかＣＰＵに基づくものであるかにかかわらず、単一アプリケーション用カード上に単独で、あるいはマルチ・アプリケーション・カード上で他のアプリケーションと共にＩＴＳＯチケット・ウォレットをもつことができる。
【００１８】
ＩＴＳＯスキームの中心には、ＩＴＳＯセキュア・アプリケーション・モジュール即ち「ＩＳＡＭ」が位置し、その下にあるプラットホームは、ＩＳＯ ７８１６準拠のＨｉｇｈ Ｃａｐａｃｉｔｙ Ｃａｒｄ（大容量カード）である。このカードは、４メガバイトを超えるセキュアメモリをもち、ＩＳＡＭは、６００Ｋｂ／ｓ以上で通信可能である（ＩＳＯ ７８１６ Ｔ＝１）。ＩＳＡＭは、ＲＳＡとトリプルＤＥＳ等の、ハードウェアによって加速された暗号機能のフル・セットを含む。一般に、これらは全て、例えば携帯電話に使用されている種類のＧＳＭ ＳＩＭ等のソケットに収まるように標準的なＩＳＯ ７８１０及びＩＤ−０００フォーム・ファクタで提供することができる。ＩＳＡＭは、国際的に認知されたセキュリティ保証方法であるＣｏｍｍｏｎ ＣｒｉｔｅｒｉａのＡＥＬ ４を満たすように開発された。
【００１９】
ＩＴＳＯスキームでは、各カードは、１つまたは複数の「ｅチケット」をもつことができる。これらは、スキームに参加する店舗から、代金と引き換えに入手される。カード所有者が店舗からｅチケットを購入するとき、ｅチケットを形成するデータ・ファイルは、ＩＳＡＭを含むインターフェース装置からスマートカードにロードされる。カード所有者が旅行をするために購入したチケットを使用したいと考える場合、ｅチケット・ファイルは、スマートカードからＩＳＡＭを含むインターフェース装置にダウンロードされる。従来のＩＴＳＯスキームでは、双方向の流れもカード対カードの取引も提供されないことが理解されよう。従って、一見したところでは、ＩＴＳＯスキームは、複数財貨のバリュー移転スキームの基盤として、先に述べたＥＭＶスキームと同じ不都合を幾つかもっている。
【００２０】
しかし、ＩＴＳＯスキームは、先に述べた機能を有する実行可能なバリュー移転スキームを提供するように適合させることができることを本発明者らは認識している。
本発明のスキームは、各カードに常駐している各財貨アカウント毎に１つ提供される、複数の「ｅ小切手帳」を提供することに依拠している。これらのｅ小切手帳の構造は、ＩＴＳＯチケット・テンプレート（参照により本明細書に組み込まれる「ITSO Specification Part 2: Card and Basic Data structure」Version 2、２０００年１１月発行と、「ITSO Specification Part 5: Card format and Data Records」 Version 2、２０００年１１月発行とを参照のこと）に基づいている。各ｅ小切手帳は、事実上、暗号の使用によってその完全性が実施されるデジタル証明書、即ち１組のデータである。カード発行者が許可を与えると仮定した場合、複数の財貨仲介業者からの複数のアカウントを表す複数のｅ小切手帳が、外出先でもカードにロードしまたはカードから削除することができる。従って、このスキームは、同一カード上での複数の仲介業者からの複数の財貨の存在を可能にする。
【００２１】
各ｅ小切手帳の内容を検証し改変するのに使用される鍵も、各カードに記録されている。各ｅ小切手帳はそれ自体の鍵をもつことができるため、スキーム全体に渡ってアカウントのプライバシーとセキュリティとが保証される。このスキームは、全ての鍵の生成と使用の責任をもつセキュリティ管理システム（ＳＳＭＳ）を備える。更に、ｅ小切手帳のセキュリティ保護されたローディングと削除の責任をもつアプリケーション管理システム（ＡＭＳ）があり、これはＳＳＭＳによって管理された鍵を利用する。
【００２２】
カード所有者間の取引は、オフラインで電子小切手（「ｅ小切手」）を移転することで実行される。
ｅ小切手帳は、ＩＴＳＯ ＩＰＥ（Ｉｎｔｅｒｏｐｅｒａｂｌｅ Ｐｒｏｄｕｃｔ Ｅｎｔｉｔｙ：ｅチケットを意味するＩＴＳＯ用語）と似ており、小切手は、ＩＴＳＯチケット取引記録と似ている。小切手のセキュリティ保護されたローディング及び削除と、各小切手帳の残高のホスト対カードの増減（参照により本明細書に組み込まれる「ITSO Specification Part 4: Back Office Systems」Version 2、２０００年１１月発行を参照のこと）とは、ＩＴＳＯセキュア・フレーム・メッセージング（参照により本明細書に組み込まれる「ITSO Specification Part 7: Security Access Module Version 2、２０００年１１月発行を参照のこと」によって管理される。
【００２３】
ＥＭＶスキームとは異なり、ｅ小切手自体は、何らかの形の電子財布またはアカウントに貯えられた財貨価値を変更するのではなく、むしろ、将来起こるであろう取引の記録として働く。これは、従来型の銀行口座の小切手に全く類似している。即ち、資金の移転を実行するのは小切手を切って受取人に手渡すことではなく、むしろ受取人の銀行口座を介して小切手を換金することである。
【００２４】
カード対カードの取引は、新たな「小切手」を記憶するのに利用可能なメモリがなくなるか、あるいは「小切手カウンタ」がトリップするまで、オフラインで繰り返すことができる。この時点で、カードをオンラインでスキーム・ホストに接続して「小切手を現金化」する必要がある。即ち、中央交換処理センターで手続きを済ますために、取引は、カードからアップロードされる。
【００２５】
カードがホストにオンライン接続する際、まずその一意のＩＤが、ＳＳＭＳに渡される。ＳＳＭＳは、スキーム鍵でセキュリティ保護されたメッセージの形でカードに固有のチャレンジを送る。ただ１枚の有効なカードのみが、正しく応答することができる。この応答は、ＰＩＮなどのカード所有者確認方法の正しい入力にも依存する。従って、この動作は、先に提示した必須要件のリストに提案したような２つのファクタによる遠隔認証を使用したセキュリティ保護された遠隔ログインの働きをする。この一意のＩＤは、ホストが「店舗」カードを認識し、消費者のカードと区別できるようにする。
【００２６】
従って、本発明のスキームでは、ユーザが「バック・オフィス」、即ちスキームの中央処理拠点にオンライン接続するまで、カード間でのｅ小切手の交換が、オフラインで行われる。接続した時点で、ｅ小切手はダウンロードされ、電子財布とアカウントがオンラインで更新される。
【００２７】
先に述べたように、ＩＴＳＯ輸送関連スキーム自体は、カード対カードを提供する必要がないため、本発明者は、本発明のバリュー移転スキームでこれを可能にするように、ＩＴＳＯ構造を改変しなければならなかった。
【００２８】
２つのカードがインターフェースする際、互換性のあるｅ小切手帳の存在が検証され、認証後、カード所有者検証方法の形で２つのｅ小切手が作成され交換される。これらのうちの一方のｅ小切手は、紙の小切手に類似しており、一方のカードのｅ小切手帳の残高を増加させるように働き、他方のｅ小切手は、他方のカードのｅ小切手帳の残高をそれに対応する額だけ減少させるが、これは紙システムでは小切手控えにつけた記録に類似している。
【００２９】
カード所有者の検証は、既存のシステムでは、ＰＩＮの提供を伴う可能性が高いが、これは、将来的にはバイオメトリクス等の他のカード所有者検証方法に改変することができる。
【００３０】
２つ目のカードが、必要なｅ小切手帳をもたない場合、カードのアクセス権がそれを可能にすることを前提として、新たなｅ小切手帳が作られてその中にバリューが追加される。従って、提案するスキームの機能は、必要に応じて新たな財貨の容易な導入を可能にする。
【００３１】
消費者対店舗という状況において、消費者のカードの資金不足により取引が失敗した場合、消費者のカードがオンラインでホストに接続し、利用可能な資金をカード所有者へ更にダウンロードして、取引の再試行ができるようにする。この操作は、店舗と消費者の双方から完全にトランスペアレントなものでよい。言うまでもなく、これは、店舗の端末がいつものように中央処理拠点に接続しているときのみ可能である。
【００３２】
本発明によるスキームのハイレベル・アーキテクチャを図１に示す。参照番号１０では、カード対カードの取引が実行されたときに起こる状況を示す。各カード所有者のカードは、中央処理拠点１４即ち「バック・ルーム」に接続されていないローカルな端子とインターフェースする。
【００３３】
カード所有者がオンライン接続する必要がある場合、カードは、例えばインターネットまたは他のコンピュータ・ネットワークを用いてバック・ルーム１４に接続された端末１２とインターフェースして、既存のｅ小切手が換金でき、アカウントまたは電子財布のバリューがアップロードまたはダウンロードできるようにする。バック・ルームの操作１６の一部は、新たなカードの発行とパーソナル化も扱う。
【００３４】
表１の参照番号１０におけるように、カード対カードの取引が行われる場合、本発明のスキームは、以下のように動作する。
下記の表１で、ＩＴＳＯ規格に基づくカード対カードのバリュー移転を実施するために、端末とカードとの間に示されたコマンドのシーケンスが提案される。
【００３５】
【表１】
まず、２つのカードの相互認証が、端末によって実施される。何れの場合も、カード所有者は、ＰＩＮまたはカードの真正性を検証するための他の手段を提供するよう求められる。ＰＩＮまたは他の検証が提供されない場合、取引は停止する。
【００３６】
次いで、端末アプリケーション（ＩＳＡＭ）が、各カードからバイナリＤＩＲを読み取って検証し、第１のカードであるカード１からｅ小切手帳バリュー（ＩＰＥ１）を読み取って検証し、他方のカードであるカード２にそれを書き込む。ＩＳＡＭは次いで、第２のカードであるカード２から対応するｅ小切手帳バリュー（ＩＰＥ２）を読み取って検証し、カード１にそれを書き込む。これで、それぞれのカードが、他方のカードのｅ小切手帳バリューの検証済コピーを有するようになる。
【００３７】
第２のカードであるカード２は、次いで、ＭＯＤＩＦＹ ＶＡＬＵＥ ＩＰＥコマンドを内部で作成して、ｅ小切手帳のバリューであるＩＰＥ１から所望の数量を減算し、それによってＩＰＥ１の修正版を作り出す。カード２は同時に、内部のＩＭＡＣコマンドを作成して、その数量がカード１から差し引かれた事実を記録する。
【００３８】
端末は次いで、カード２から改変されたバリューＩＰＥ１を読み出し、他方のカードであるカード１にこれを渡す。カード１は次いで、自らのＩＰＥからどれだけ差し引かれたのかを計算することができ、その数量をＩＰＥ２に加算するためにＭＯＤＩＦＹ ＶＡＬＵＥ ＩＰＥコマンドを内部的に作成する。カード１は、ＩＭＡＣコマンドを作成して、カード２のＩＰＥにその数量が加算された事実を記録する。
【００３９】
端末は次いで、カード１から改変されたＩＰＥ２を読み出し、カード２に書き戻す。好ましくは、端末は更に、取引の詳細を記録するＩＭＡＣログを生成する。
端末は、カードとインターフェースして、カード上に保持されたｅ小切手帳の現在高を更新するが、この情報は、カード所有者がホストにオンライン接続するまではカード所有者のアカウントにおいて更新されない。更に、端末は、ＩＭＡＣログの形をとる「ｅ小切手」を用いて、ｅ小切手帳に影響を及ぼすそれぞれの取引の記録を作成する。
【００４０】
このように、本発明のスキームは、先に列挙した望ましい機能、とりわけ中央処理拠点からオフラインでのカード対カード取引を可能にする複数財貨のバリュー移転スキームを提供することができる。
【図面の簡単な説明】
【００４１】
【図１】本発明によるスキームのハイレベル・アーキテクチャを示す。
【特許請求の範囲】
【請求項１】
バリュー移転スキームであって、
少なくとも１つの利用可能な財貨価値を表すデータを格納できるプログラム可能な装置は、ユーザに提供され、ユーザ・アカウントを表すデータは、遠隔処理ステーションで保持され、
ユーザ間の取引は、ユーザの各々のプログラム可能な装置間でのオフラインのデータ交換によって成立し、交換されるデータは、開始された１つのまたはそれぞれの取引の記録を含み、
遠隔処理ステーションで保持される各ユーザ・アカウントのユーザ・アカウント・データは、そのユーザのプログラム可能な装置がオンラインで遠隔処理ステーションに接続され、そのプログラム可能な装置から遠隔処理ステーションへデータがアップロードされた後にのみ、更新される、バリュー移転スキーム。
【請求項２】
請求項１に記載のスキームであって、取引の当事者であるユーザの識別は、ユーザのプログラム可能な装置間でのデータ交換に先立って、検証される、スキーム。
【請求項３】
請求項１または請求項２に記載のスキームであって、前記または各プログラム可能な装置は、スマートカードである、スキーム。
【請求項４】
請求項１から請求項３の何れか１項に記載のスキームであって、データの交換は、
取引の当事者である２つのプログラム可能な装置のそれぞれから、データ・ファイルが、もう一方の装置へコピーされ、
第２のプログラム可能な装置が、第１のプログラム可能な装置から受け取ったデータ・ファイルを改変し、改変したファイルを第１の装置にコピーし、
第１の装置が次いで、第２の装置から戻された改変ファイルに応答して第２の装置からコピーしたデータ・ファイルを改変し、改変したファイルを第１の装置にコピーするように、行われる、スキーム。
【請求項５】
請求項１から請求項４の何れか１項に記載のスキームであって、異なる財貨の利用可能なバリューを表す複数のデータ・ファイルの１つは、取引に使用するために選択される、スキーム。
【請求項６】
請求項１から請求項５の何れか１項に記載のスキームであって、ＩＴＳＯスキーム・セキュリティ・マネジメント・システム（Ｓｃｈｅｍｅ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に基づくソフトウェアは、取引に関係する前記または各データ・ファイルの内容を検証または改変するのに使用される鍵を生成する、スキーム。
【請求項７】
請求項１から請求項６の何れか１項に記載のスキームであって、ＩＴＳＯアプリケーション・マネジメント・システム（Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に基づくソフトウェアは、１つまたは複数のプログラム可能な装置に新たなデータ・ファイルをロードし、そこからデータ・ファイルを削除することを管理する、スキーム。
【請求項８】
請求項１から請求項７の何れか１項に記載のスキームによるバリュー移転スキームに使用されるインターフェース装置であって、
取引の当事者である少なくとも２人のユーザのプログラム可能な装置とインターフェースし、前記ユーザのそれぞれのプログラム可能な装置間のオフラインでのデータ交換を実行する手段を、
含むインターフェース装置。
【請求項９】
請求項１から請求項７の何れか１項に記載のスキームに使用するプログラム可能な装置であって、
少なくとも１つの利用可能な財貨バリューを表すデータと、
請求項８に記載のインターフェース装置によって他のユーザのプログラム可能な装置とオフラインでインターフェースする手段と、
を備えるプログラム可能な装置。
【請求項１】
バリュー移転スキームであって、
少なくとも１つの利用可能な財貨価値を表すデータを格納できるプログラム可能な装置は、ユーザに提供され、ユーザ・アカウントを表すデータは、遠隔処理ステーションで保持され、
ユーザ間の取引は、ユーザの各々のプログラム可能な装置間でのオフラインのデータ交換によって成立し、交換されるデータは、開始された１つのまたはそれぞれの取引の記録を含み、
遠隔処理ステーションで保持される各ユーザ・アカウントのユーザ・アカウント・データは、そのユーザのプログラム可能な装置がオンラインで遠隔処理ステーションに接続され、そのプログラム可能な装置から遠隔処理ステーションへデータがアップロードされた後にのみ、更新される、バリュー移転スキーム。
【請求項２】
請求項１に記載のスキームであって、取引の当事者であるユーザの識別は、ユーザのプログラム可能な装置間でのデータ交換に先立って、検証される、スキーム。
【請求項３】
請求項１または請求項２に記載のスキームであって、前記または各プログラム可能な装置は、スマートカードである、スキーム。
【請求項４】
請求項１から請求項３の何れか１項に記載のスキームであって、データの交換は、
取引の当事者である２つのプログラム可能な装置のそれぞれから、データ・ファイルが、もう一方の装置へコピーされ、
第２のプログラム可能な装置が、第１のプログラム可能な装置から受け取ったデータ・ファイルを改変し、改変したファイルを第１の装置にコピーし、
第１の装置が次いで、第２の装置から戻された改変ファイルに応答して第２の装置からコピーしたデータ・ファイルを改変し、改変したファイルを第１の装置にコピーするように、行われる、スキーム。
【請求項５】
請求項１から請求項４の何れか１項に記載のスキームであって、異なる財貨の利用可能なバリューを表す複数のデータ・ファイルの１つは、取引に使用するために選択される、スキーム。
【請求項６】
請求項１から請求項５の何れか１項に記載のスキームであって、ＩＴＳＯスキーム・セキュリティ・マネジメント・システム（Ｓｃｈｅｍｅ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に基づくソフトウェアは、取引に関係する前記または各データ・ファイルの内容を検証または改変するのに使用される鍵を生成する、スキーム。
【請求項７】
請求項１から請求項６の何れか１項に記載のスキームであって、ＩＴＳＯアプリケーション・マネジメント・システム（Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に基づくソフトウェアは、１つまたは複数のプログラム可能な装置に新たなデータ・ファイルをロードし、そこからデータ・ファイルを削除することを管理する、スキーム。
【請求項８】
請求項１から請求項７の何れか１項に記載のスキームによるバリュー移転スキームに使用されるインターフェース装置であって、
取引の当事者である少なくとも２人のユーザのプログラム可能な装置とインターフェースし、前記ユーザのそれぞれのプログラム可能な装置間のオフラインでのデータ交換を実行する手段を、
含むインターフェース装置。
【請求項９】
請求項１から請求項７の何れか１項に記載のスキームに使用するプログラム可能な装置であって、
少なくとも１つの利用可能な財貨バリューを表すデータと、
請求項８に記載のインターフェース装置によって他のユーザのプログラム可能な装置とオフラインでインターフェースする手段と、
を備えるプログラム可能な装置。
【図１】
【公表番号】特表２００６−５２０４９９（Ｐ２００６−５２０４９９Ａ）
【公表日】平成１８年９月７日（２００６．９．７）
【国際特許分類】
【出願番号】特願２００６−５０５９６２（Ｐ２００６−５０５９６２）
【出願日】平成１６年３月１５日（２００４．３．１５）
【国際出願番号】ＰＣＴ／ＧＢ２００４／００１０９４
【国際公開番号】ＷＯ２００４／０８１８８９
【国際公開日】平成１６年９月２３日（２００４．９．２３）
【出願人】（５０４２１８３６９）エセブス・リミテッド (6)
【Ｆターム（参考）】
【公表日】平成１８年９月７日（２００６．９．７）
【国際特許分類】
【出願日】平成１６年３月１５日（２００４．３．１５）
【国際出願番号】ＰＣＴ／ＧＢ２００４／００１０９４
【国際公開番号】ＷＯ２００４／０８１８８９
【国際公開日】平成１６年９月２３日（２００４．９．２３）
【出願人】（５０４２１８３６９）エセブス・リミテッド (6)
【Ｆターム（参考）】
[ Back to top ]