JP3808297B2 - Ｉｃカードシステム及びｉｃカード - Google Patents
Ｉｃカードシステム及びｉｃカード Download PDFInfo
- Publication number
- JP3808297B2 JP3808297B2 JP2000249182A JP2000249182A JP3808297B2 JP 3808297 B2 JP3808297 B2 JP 3808297B2 JP 2000249182 A JP2000249182 A JP 2000249182A JP 2000249182 A JP2000249182 A JP 2000249182A JP 3808297 B2 JP3808297 B2 JP 3808297B2
- Authority
- JP
- Japan
- Prior art keywords
- card
- application
- agent
- service provider
- security domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
- G06Q20/3552—Downloading or loading of personalisation data
Description
【０００１】
【発明の属する技術分野】
本願発明は、ＩＣカードの発行者以外の第三者による動的認証及びＩＣカードへのアプリケーション搭載方法及びその利用に関する諸技術に関するものである。
【０００２】
【従来の技術】
ＩＣカードは、大量の情報が記録可能であり、かつ高度なセキュリティを有するため、磁気カードに代わる新しい情報記録媒体として近年普及しつつある。また、最近ではＩＣカードに複数のアプリケーションを搭載できるマルチアプリケーション機能や、カード発行後にアプリケーションを搭載可能なダイナミックローディング機能を備えたＩＣカード及びカードＯＳが主流となってきている。
【０００３】
従来、これらのＩＣカードへのアプリケーション搭載方式では、該カードを発行した発行者による何らかの署名が付与されたアプリケーションのみを搭載可能としていた。カード発行後に当該カードにアプリケーションを搭載するいわゆる動的搭載も前提としているため、誰にでもアプリケーションが搭載可能であるシステムはセキュリティ上問題があるからである。
【０００４】
図１にＩＣカード（１１）内に搭載されているＩＣ内部の基本的な領域の論理的な構成を示す。当該ＩＣは、ハードウェア層（１０１）とＯＳが搭載される領域、即ちＯＳ層（１０２）とアプリケーションが搭載される領域、即ちアプリケーション層（１０７）とを有する。ここで、マルチアプリケーションの搭載が可能とは、アプリケーション層（１０７）に複数のアプリケーション（１０６）が搭載できることである。又、ダイナミックローディングが可能であるとは、このアプリケーション（１０６）をカード発行後にアプリケーションが搭載あるいは削除が可能であることを示す。ＯＳ層（１０２）は通信処理部（１０３）、インタープリタ（１０４）、セキュリティ機構（１０５）などを有し、外部端末からのコマンドの受信やアプリケーションのコマンドの転送などを行っている。当然、アプリケーション層（１０７）とＯＳ層（１０２）との間にはアプリケーション・インターフェイス、ＯＳ層（１０２）とハードウェア層（１０１）との間にはハードウエア・インターフェイスが設けられる。
【０００５】
図２はＩＣカードの発行やサービスの提供に関する従来のシステム構成図である。カード発行者（３０２）とは、ＩＣカードの発行と管理の業務を行う事業主体者であり、カードの責任を負う主体者である。また、サービス提供者（３０３）はＩＣカード上に搭載するアプリケーションの発行と管理の業務を行う事業主体者である。カード発行後に、アプリケーションをダイナミックに搭載する場合は、サービス提供者の端末からＩＣカードへ搭載することが多い。クライアント側（３０１）にはＩＣカードとコマンドのやり取りを行う外部端末（３０４）がある。カード発行者は発行者データベース（３０５）に発行管理データを保持しており、そのデータに従いカードを発行し利用者に配布する。発行管理データには、利用者からの申請情報や、カードの発行に必要な基本情報が記載されている。ＩＣカード搭載用アプリケーションは、サービス提供者が作成もしくは取得し、ＩＣカードへのアプリケーション搭載を行う。
【０００６】
サービス提供者データベース（３０６）にはアプリケーション関連（以下、ＡＰ関連と称する）データが格納されている。前記のように、ＩＣカード上の全ての責任はカード発行者に帰属するため、アプリケーションの正当性をカード発行者が確認する手順が必要である。サービス提供者はカード発行者のＡＰの搭載を許可する処理部にＡＰ搭載の許可の要求を行う。カード発行者のデータベースには事前に登録されているＡＰに関するデータが格納されている。そして、要求のあったアプリケーションが不正なものではないか、要求をしているサービス提供者が不正ではないかなどをチェックした上で、ＡＰの搭載許可を発行する。サービス提供者はこのＡＰ搭載許可とアプリケーションを合わせてカードに送信し設定するのである。そのため、サービス提供者はあらかじめカード発行者と契約し、自身が正当な事業主であることや、搭載予定のアプリケーションが不正なものではないことを登録する必要がある。
【０００７】
カード発行者とサービス提供者のサーバ間は、ネットワークでつながれている場合が多いと想定されるが、書類形式でやり取りすることも可能である。
【０００８】
またこれに加え、アプリケーション搭載の際に、カード内でアプリケーション搭載を専用に行うアプリケーションもしくはデータを用いる場合がある。この方式は“セキュリティドメイン”というアプリケーションをサービス提供者毎に用意し、アプリケーション搭載・削除・管理の役割を担わせている。図３にセキュリティドメイン機構を持つＩＣカードのＩＣ内部の基本的な領域の論理的な構成を示す。セキュリティドメイン（１０８）はアプリケーション層に存在し自らが責任を持つアプリケーション（１０６）を管理する。アプリケーションはカードに搭載や削除される場合、このセキュリティドメインを通じて行われる。また鍵データなどのセキュリティ情報やＩＤ番号などのデータ管理をセキュリティドメインに委託する場合もある。
【０００９】
【発明が解決しようとする課題】
上記のようなこれまでのＩＣカードへのアプリケーション搭載方式は、高セキュリティを保ちながらアプリケーションの動的な搭載や削除を可能としている。しかし、複数カード発行者やそのサービス提供者間での運用に際してはいくつかの難点がある。
【００１０】
前述のように、サービス提供者は、アプリケーションの搭載を希望するカードのカード発行者に対して、あらかじめ契約を結ぶ必要がある。つまり、カード発行者は、発行するカードにアプリケーションの搭載を希望する全てのサービス提供者と契約関係にあり、そのサービス提供者からの要求を受け、アプリケーション搭載や削除を行う場合は上記アプリケーション搭載方法で良い。図５のように発行者（３０２）と契約関係にあるサービス提供者（３０３）がカードＡ（１１）にアプリケーションを搭載する場合は従来方法でいい。しかし、サービス提供者（８０３）のように、カード発行者とあらかじめ複雑な事前契約やアプリケーションの登録をいちいち行わずにアプリケーションを搭載する要求がでてくるだろう。そもそも、ＩＣカードは複数アプリケーションを搭載可能なことが大きな利点であり、多数のサービスが提供可能であることはカード運用側のカード発行者にとっても利用側のユーザにとっても多大なメリットであるため、このような要求は年々増加するものと予想される。しかし、現在のアプリケーション搭載方式に従い、事前契約などせずにサービスを供給することは不可能である。図５に示すように、サービス提供者（８０３）と発行者（３０２）の間には何らかの情報交換が必要である。つまり、従来のアプリケーション搭載方式に従うならば、サービス提供者はアプリケーション搭載を希望するカードの発行者全てと事前に契約を結ぶ必要があり、アプリケーション搭載時には全てのカード発行者にアプリケーション搭載許可証を発行してもらわなければならない。この実現方法には以下のような難点がある。
【００１１】
（１）カード発行者―サービス提供者間の契約関係及び運用時の通信の増大と複雑化
Ｎ個のカード発行者とＭ個のサービス提供者の間で相互にサービスを運用する場合、Ｎ＊Ｍの契約関係が結ばれることになり膨大な量の契約と運用時の通信が発生することになる。それに伴うコストや時間が増大し最終的にはＩＣカード単価の増加の原因となる。
【００１２】
（２）現実的に契約関係を結べない事業者同士の問題
例えば、インターナショナルカードに国内企業のアプリケーションを搭載する場合、この国内企業がカード発行者と直接コンタクトをとることは現実的にはあまりなく、国内向け窓口業務を行う事業者が間に入ることが考えられる。このようにカード発行者やサービス提供者が属する事業主体により直接契約を結んだり通信を確立することが難しい。
【００１３】
【課題を解決するための手段】
本願発明の次の主な二つの形態を有する。これら形態の基本思想を、その要点をごく簡潔に要約すると次ぎの通りである。
【００１４】
本願発明の第１の形態は、ＩＣカードの発行者以外の第三者による認証書を用いることである。尚、以下ＩＣカードの発行者以外の第三者による認証書を簡便に代理署名と称する。
【００１５】
本願発明の第２の形態は、ＩＣカードが限定機能付きのセキュリティドメインを有することである。この第２の形態は、前記第１の形態の機能を補足し、より有用なＩＣカード・システムを提供することを可能ならしめるものである。
【００１６】
そして、本願発明の第３の形態は、前記第１と第２の発明思想を合わせて使用することである。こうして、カード発行者が認めた代理者が、カード発行者が認めた条件でアプリケーション搭載を代行することが可能である。
【００１７】
以下に、これらの本願発明の基本思想を軸に、本願発明を説明する。
【００１８】
先ず、本願発明の第１の形態についてである。
【００１９】
第１の形態は、例えば、第２の機関が、少なくとも、ＩＣカード発行に係わる第１の機関を特徴づけ且つサービス提供の為に持ちいる第１の特徴情報、及び当該第２の機関の第２の特殊情報とを、サービス情報提供に係わる第３の機関に提供が可能であり、前記サービス情報提供に係わる第３の機関は、少なくとも、所望のアプリケーション用プログラムと、前記ＩＣカード発行に係わる第１の機関を特徴づけ且つサービス提供の為に持ちいる第１の特徴情報と、当該第２の機関を特徴づけるところの第２の特殊情報と、をＩＣカードに提供が可能なＩＣカード・システムであると言うことが出来る。
【００２０】
この観点は、第１に、わけても、カード発行者―サービス提供者間の契約関係及び運用時の通信の増大と言う前述の難点を解決するためのものである。
【００２１】
このためには、発行者とサービス提供者の間に代理者という概念を作り、カード発行者とサービス提供者が直接通信を確立せずともアプリケーション搭載可能な方式が必要となってくる。具体的には、カード発行者が代理者と事前提携をすることで代理者業務を行うことを認証することで、サービス提供者が直接カード発行者と通信をすることなくアプリケーション搭載が実現可能であり、かつ通常のアプリケーション搭載方式と同程度のセキュリティを保つことが可能な方式が必要である。
【００２２】
本願発明は、以上の要求を満たすＩＣカードのアプリケーションの搭載方式を提供する。
【００２３】
図６は本願発明の方式の骨子を説明する図である。ＩＣカード（１１）はカード発行者（３０２）により発行されている。サービス提供者Ａ（３０３）はカード発行者（３０２）と契約を結んでおり通常のアプリケーション搭載方法によりカードにアプリケーション８０１を発行する。
【００２４】
サービス提供者Ｂ（８０３）は代理者（９０１）と契約を結んでいる。
【００２５】
本願発明の前提は、前述の難点からして、サービス提供者Ｂ（８０３）とカード発行者（３０２）との間の通信を行わないことである。従って、本願発明は、代理者を通して間接的に発行者と通信を確立する手法である。つまり、カード発行者が行っているアプリケーションの許可を代理者に代行させ、サービス提供者Ｂがカードにアプリケーションを搭載するためには代理者とのみ通信を行えば良いという方法である。しかし、代理者によるアプリケーションへの署名（以降、代理署名と呼ぶ）のみでは、次ぎのような難点を有する。即ち、その第１はカードＡが正当性を検証できない点である。第２は、カード発行者の意志に関わらず不特定者がアプリケーションの搭載が可能であるとの難点である。尚、ここで、署名とは、暗号理論における署名であることは言うまでもない。その代表例はデジタル署名である。例えば、こうしたディジタル署名は、署名アルゴリズムと、確認アルゴリズムの２つの要素から成っている。例えば、秘密の署名アルゴリズムを利用して、文書に署名をすることが出来る。その結果の署名は、その後公開されている確認アルゴリズムを用いて確認できる。確認アルゴリズムは、文書と署名とによって、確認アルゴリズムは署名が本物かどうかを判断し、真もしくは偽という答えを返すことが出来る。こうした署名に関する一般的な理論は、例えば、ダグラス・スチンソン著、桜井幸一訳の「暗号理論の基礎」（共立出版、１９９６）の第６章、わけても第２１７頁より第２２０頁、あるいは「ハンドブック オブ アプライド クリスタルグラフィ（Ｈａｎｄｂｏｏｋ ｏｆ Ａｐｐｌｉｅｄ Ｃｒｙｓｔａｌｇｒａｐｈｙ）」（ＣＲＣ Ｐｒｅｓｓ、１９９６）、第４３３頁より第４３４頁に見られる。
【００２６】
こうした難点を回避する為の本願発明の第１の形態の骨子は、次の諸点に要約される。第１は、カード発行者と代理者との間で提携契約を結ぶ際に、カード発行者が代理者に対して代理業務を行うことを認める代理者認定証を渡しておくことである。第２は、代理者がアプリケーション認証する際に、代理署名と代理者認証書を合わせてサービス提供者に渡すことである。こうして本願発明によれば、カードＡ内で代理者認証書がカード発行者による正当なものかを検証することで、不特定者によるアプリケーションの搭載を防ぐことができる。
【００２７】
本願発明の主な第２の形態は、前記第１の形態の機能を補足し、より有用なＩＣカード・システムを提供することを可能ならしめるものである。その形態を要約すると、ＩＣカードが、いわゆる限定機能付きのセキュリティドメインを有することである。
【００２８】
本願発明の第２の形態は、例えば、第２の機関が、少なくとも、ＩＣカード発行に係わる第１の機関を特徴づけ且つサービス提供の為に持ちいる第１の特徴情報、及び当該第２の機関の第２の特殊情報と、アプリケーション用プログラムのＩＣカードへの格納に関する条件を有するプログラムとを、サービス情報提供に係わる第３の機関に提供が可能であり、前記サービス情報提供に係わる第３の機関は、少なくとも、アプリケーション用プログラムと、前記第１の特徴情報と、前記第２の機関を特徴づけるところの第２の特徴情報と、前記アプリケーション用プログラムのＩＣカードへの格納に関する条件を有するプログラムと、前記格納条件を有するプログラムに係わる第３の特徴情報と、をＩＣカードに提供が可能なＩＣカード・システムであると言うことが出来る。
【００２９】
本願発明に係る第１の形態のみでは一度代理者認証書を発行したら、代理者は、それ以降無制限にアプリケーションを搭載できる権限を有する。勿論、提携の契約条件にもよるのだが、カード発行者にとっては、「アプリケーション1個分の搭載許可権限を与えたい」あるいは「有効期限を設定した上での搭載許可権限を与えたい」などの要求は当然発生する。本願発明の第２の形態は、この要求を満たすものである。
【００３０】
セキュリティドメインは、前述のようにカード内でアプリケーションの搭載、削除あるいは管理機能などを実現するアプリケーションもしくはデータを有する領域である。従って、本来、セキュリティドメインは、サービス提供者によって作成される。しかし、本願発明では、カード発行者がこのセキュリティドメインを作成し、これを代理者を通してサービス提供者に渡し、サービス提供者のセキュリティドメインとして機能させる。カード発行者は作成の際、アプリケーション搭載回数や有効期限など提携契約に対応する諸条件をセキュリティドメイン内部に設定し、提携先に送信する。もちろん、このセキュリティドメインは改竄防止策を取っている必要がある。
【００３１】
図６を参酌すれば、限定機能付きセキュリティドメイン（８０５）は、カード発行者（３０２）により作成され、サービス提供者Ｂ（８０３）のセキュリティドメインとしてカードＡ１１内に格納される。サービス提供者Ｂ（８０３）がアプリケーション（８０２）を搭載する場合、サービス提供者Ｂ（８０３）は代理者（９０１）にアプリケーションの搭載の許可を依頼する。代理者（９０１）は、サービス提供者Ｂ（８０３）に代理者認証書と代理署名を合わせて送信する。サービス提供者Ｂ（８０３）はアプリケーション（３７）と代理者認証書と代理署名を合わせてカードＡ（１１）内に送る。カードＡは、限定機能付きセキュリティドメイン内に設定された限定条件に照らし合わせながら、代理者認証書が正しくカード発行者によることを検証する。その結果、カードＡが、代理署名によりアプリケーションの正当性を確認した場合、当該カードＡはアプリケーションを搭載を可能とする。
【００３２】
【発明の実施の形態】
図７は、本発明のＩＣカード（１１）及びＩＣカードアプリケーションの発行システムの構成図である。図７で、符号３０２はカード発行者のサーバであり、符号３０５はカード発行者のデータベースでカード発行者が運用する全てのＩＣカードに関する運用情報である発行管理データを管理する為のものである。同様に符号９０１は代理者のサーバであり、符号９０２は代理者のデータベースで、代理者の搭載の許可を出すＡＰに関する運用管理情報であるＡＰ関連データを管理する。符号３０３はサービス提供者のサーバであり、符号３０６はサービス提供者で自身のアプリケーションの運用情報であるＡＰ関連データを管理する。ＩＣカード（１１）はカード発行者システム内のカード発行処理部（３０８）により発行され、クライアントである利用者（３０１）のもとに配布される。尚、ここでのカードの発行及び配布は、オンライン動作ではなく、通例の意味における発行及び配布である。
【００３３】
また、カード発行処理部（３０８）は代理者システムのＡＰ搭載許可処理部（３１０）と事前提携（３１５）を行い、代理者であることを認める代理認定証のやり取りなどを行う。サービス提供者（３０３）がアプリケーションをカードに搭載する場合、サービス提供者システム内のＡＰ搭載処理部（３１２）が代理者のＡＰ搭載許可処理部（３１０）にＡＰ搭載要求（３１９）を行う。代理者は事業者ポリシーに従い、ＡＰの正当性を確認の上ＡＰ搭載許可を発行する（３１６）。サービス提供者は、受け取ったＡＰ搭載許可とアプリケーションを合わせて外部端末（３０４）を通してＩＣカードへ送信する（３１４）。カード発行者サーバ（３０２）と代理者サーバ（９０１）、代理者サーバ（９０１）とサービス提供者サーバ（３０３）は、各々基本的にネットワーク（３１８、３１９）を通して接続されている。しかし、運用事業者のポリシーによりフロッピーディスクなど情報記録媒体の郵送や、書面の郵送などにより情報のやり取りを実現することもある。このように、本願発明のシステムは、カード発行者と代理者は提携契約を結び、代理者がサービス提供者へのサービス提供許可を代行し、サービス提供者サーバからユーザのＩＣカードへアプリケーションが搭載される仕組みとなっている。
【００３４】
ここで、以下の説明の理解を容易にする為、本願明細書での特徴的な主要用語について説明する。
【００３５】
「代理署名」は、カードの発行者を代理して署名を行うことである。その具体例は署名の対象となる情報に、当該情報を代理者の秘密鍵で暗号化した情報を付与した情報のことである。尚、ここで、前記署名の対象となる情報に代えて、この情報を特徴付ける情報、例えば、そのハッシュ値を用いることも出来る。従って、前記「代理署名」の用語は、この意味をも含むものである。
【００３６】
「署名付＊＊」は、「＊＊」に、「＊＊」を署名者の鍵、例えば秘密鍵で暗号化した情報を付与した情報のことである。尚、ここで、前記署名者の鍵に代えて、この鍵情報を特徴付ける情報、例えば、そのハッシュ値を用いることも出来る。従って、前記「署名付＊＊」の用語は、この意味をも含むものである。
【００３７】
「代理認定書」は、代理者が発行者によって、その代理であることを認定されたことを示す情報である。その具体例は、代理者の公開鍵に、代理者の公開鍵を発行者の秘密鍵で暗号化した情報を付与した情報である。
【００３８】
「アプリケーション認定書」は、アプリケーションをＩＣカードに搭載することを許可する情報である。その具体例は、アプリケーションを特徴付ける特徴情報に、その特徴情報を代理者の秘密鍵で暗号化した情報を付与した情報である。
【００３９】
「セキュリティドメイン」はアプリケーションの搭載、削除、あるいはその他の諸管理を行うプログラムのことである。
【００４０】
「限定機能付きセキュリティドメイン」は、前記のアプリケーションの搭載、削除、あるいはその他の諸管理にある制限を与える条件を付与したプログラムのことである。
【００４１】
尚、本願発明は非対称暗号化機能を有するデータ・システムに関する。
【００４２】
非対称暗号化機能とは、例えば、暗号鍵として公開鍵、秘密鍵を使用し、且つこうした非対称暗号鍵により暗号化されたデータの復号化が可能である機能のことである。
【００４３】
次に、本願発明の係わる代理署名及びアプリケーションの搭載の具体的方法を説明する。
【００４４】
ＩＣカードに対する端末機などは、通例のもので良い。本願発明に係わる各機関は、サーバ、リーダライタなど端末機を有する。本願に係わる各種情報は、このサーバに一旦保持される場合、リーダライタを通してＩＣカードに情報が搭載される場合など各種形態が考えられる。本願発明はこうした動作形態に直接関係するものではない。本願発明はこれらのいずれの場合も適用可能である。
【００４５】
図２９は簡単にカード・システム例の概要を示す図である。ＩＣカード５２の中にはチップ５１があって、リーダライタ５３とデータのやりとりを行う例を示している。リーダライタの中にはコントロールプロッセサ５４やデータベースとなる磁気ディスク５５などが存在する。ＩＣカード５２には、例えば、Ｖｃｃ（供給電源）、ＧＮＤ（グランド）、ＲＳＴ（リセット）、Ｉ／Ｏ（入出力）、及びＣＬＫ（クロック）などの諸端子が示されている。又、図中、（１）はリーダライタ５３からＩＣカード５２に対しての、例えば、ＩＤ（ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ）などの各種問い合わせを示す。（２）はＩＣカードが前述の問い合わせに対する返答を示す。こうした、諸情報の伝達は通例のシステムで十分である。従って、その詳細の説明は省略する。
【００４６】
尚、ＩＣカード内のＩＣチップにおいて、具体的には、前述のアプリケーション、セキュリティドメインなどは、ＯＳ部、メモリ領域に搭載される。一般に、メモリとしては、ＲＡＭ（Ｒａｎｄｕｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュ・メモリ（Ｆｌａｓｈ Ｍｅｍｏｒｙ）、ＦＲＡＭ（Ｔｅｒｒｏｍａｇｎｅｔｉｃ Ｒａｎｄｕｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＮ（Ｅｌｅｃｔｒｉｃａｌ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）あるいはＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などが用いられる。従って、本願明細書において、「セキュリティドメインを用いて」あるいは「セキュリティドメインを経由して」とは、ＯＳ部が、そのセキュリティドメインなるプログラムを取り出し、このプログラムによって、所定の情報たるデ−タの諸管理状態を確認し、必要があれば、所定の処理を行うことを意味している。ここで、デ−タの諸管理の項目とは、例えば、サービス情報の搭載容量、搭載回数、搭載するサービス情報の個数、サービス情報の搭載可能な有効期間などである。
【００４７】
ＯＳ部などは通例のもので十分である。ＩＣチップ内の信号処理は、通例のＩＣカードのそれをもちいて十分である。
【００４８】
又、ＩＣカードには、接触型ＩＣカード、非接触型ＩＣカードなどがあるが、本願発明はこうしたＩＣカードの構成自体によらず適用することが出来る。
【００４９】
図８を参酌して、代理署名について説明する。カードＡ（１１）はマルチアプリケーションのダイナミックローディングに対応するＯＳが搭載されたＩＣカードであり、カード発行者（３０２）により発行済みである。また、サービス提供者Ｂ（８０３）はＩＣカードにアプリケーションを搭載しサービスを運用する事業主体者であり、代理者（９０１）とサービス提供に関する契約を結んでいる。通常であれば、サービス提供者Ｂ（８０３）がカードＡ（１１）にアプリケーションを搭載するためには、カード発行者（３０２）とサービス提供に関する契約を直接結び、通信を確立した上で許可を受けなければならない。しかし、本願発明のシステムは、カード発行者（３０２）と代理者（９０１）の間で提携契約を結び、代理者（９０１）がカード発行者（３０２）の代理としてアプリケーション搭載許可を行う方法である。提携契約時に、カード発行者（３０２）は代理者（９０１）に代行業務を行うことを認める代理認定証を渡し、以降アプリケーション搭載許可は代理者（９０１）が行う。サービス提供者Ｂ（８０３）はアプリケーション搭載時に、代理者からアプリケーション搭載許可を受け、カードＡにアプリケーションを搭載する。
【００５０】
上述した本願発明の第１の形態のシステムが、具体的にどのように行われるか、図９を参酌して説明する。即ち、代理署名を行う際の処理シーケンスを説明する。
【００５１】
＜代理署名を行う際の代表的な基本処理シーケンスの例＞
カード発行者（３０２）と代理者（９０１）の間では、お互いの運用ポリシーに基づき提携契約を結ばれている。提携契約に合意した場合、代理者はカード発行者に自らの非対称鍵公開鍵を送付し、代理者認証書を要求する（ステップ１２００１）。
【００５２】
カード発行者は受け取った公開鍵に対して、自らの非対称鍵秘密鍵で署名を行った代理認定証を代理者に送付する（ステップ１２００２）。
【００５３】
次に、カードＡ（１１）へのサービス提供者Ｂ（８０３）によるアプリケーション搭載する際は、まず、サービス提供者Ｂが代理者にカードＡに対するアプリケーション搭載許可要求を行う（ステップ１２００３）。尚、アプリケーション搭載許可要求の具体例は、例えば、搭載するアプリケーションのハッシュ値を送付することである。ハッシュ値とは、当該アプリケーションに対応した固有のデータ値である。アプリケーション搭載許可要求を行う場合、必ずしもハッシュ値でなくとも良いが、ハッシュ値が最も便利であり、多く用いられる。
【００５４】
代理者は、サービス提供者Ｂから事前に申請されているアプリケーションの内容を照会し、その正当性を確認する。前述のハッシュ値を用いる場合、この正当性の確認は、例えば、サービス提供者Ｂより送付されたハッシュ値と、当該ＩＣカードの内部で発生させた当該アプリケーションに対応したハッシュ値とを比較することによって行われる。こうしたステップの詳細は後述される。また、カード発行者よりホットリスト（不正カード情報あるいはブラックリスト）などカードに関する情報が提供されていれば、それをも合わせて確認される。
【００５５】
代理者は受け取ったアプリケーションのハッシュ値に非対称鍵秘密鍵で代理署名し、代理認定証と合わせてサービス提供者Ｂに送付する（ステップ１２００４）。なお、この秘密鍵は提携契約時にカード発行者に送付した非対称公開鍵に対応するものである。
【００５６】
サービス提供者は受け取った代理署名付きアプリケーションハッシュ値、代理認定証、アプリケーション本体を合わせてカードに送信する（ステップ１２００５）。
【００５７】
カード内には、カード発行時に、カード発行者の公開鍵が格納されているので、それを用いて代理認定証の署名検証を行い正当性を確認する。
【００５８】
これは、代理者の公開鍵に署名を付与したものなので、署名が正しいことを確認した上で、この公開鍵を用いてアプリケーションのハッシュ値を復号化する。それと受け取ったアプリケーションから作成したハッシュ値を比較し同一であれば、アプリケーションをロード・インストールし、アプリケーション搭載完了となる。
【００５９】
このように本願発明の第１の形態の手順は、アプリケーションの正当性を代理者が保証し、代理者の正当性をカード発行者が保証することで、間接的にカード発行者の保証のもとにアプリケーションを搭載する仕組みとなっている。図６に例示したように、カード発行者とその他プレーヤの間は、提携契約時、代理認定証の送付のステップがあるが、以降オフラインとなっており、通信を確立する必要がない。ただし、提携契約内容によっては、不正カード情報であるホットリストや各種運用に必要な情報をカード発行者間でやり取りする場合もあるが、その場合でも、カード発行者とサービス提供者との間に通信を直接確立する必要はない。
【００６０】
以上説明した代理署名を行う際の基本処理シーケンスに基づく動作の更なる動作例の詳細を、図１０から図１４を用いて説明する。即ち、各図は、各々カード、カード発行者、代理者、サービス提供者の各プレーヤ毎の動作フローチャートである。
【００６１】
＜ＩＣカード：ＩＣカードでのアプリケーション搭載処理の例＞
図１０は、代理署名を用いたアプリケーション搭載処理を行うＩＣカード側での動作のフローチャートである。
【００６２】
カードがアプリケーション搭載処理を開始する（ステップ１３００１）。
【００６３】
ＩＣカードは、サービス提供者より、代理認定証と代理者が署名したアプリケーション認証書とアプリケーションを受信する（ステップ１３００２）。このステップは図９のステップ１２００５に対応する。
【００６４】
代理認定証はカード発行者により署名されている。一方、この代理認定証に対応する鍵がＩＣカード内に格納されており、ＩＣカードは、それを使用して前記の代理認定証を検証し、代理者の鍵を復号化する（ステップ１３００３）。
【００６５】
復号化した代理者の鍵を用いて、代理者が署名したアプリケーション認証書の検証を行い、アプリケーションのハッシュ値を取り出す（ステップ１３００４）。
【００６６】
また、ＩＣカードは、送信されたアプリケーションのハッシュ値をカード内で計算し、さきほど復号化したハッシュ値と同一かどうかを確認する(ステップ１３００５)。
【００６７】
これらが同一であれば、ＩＣカードは、カード発行者が認証した正当なアプリケーションだと認め、これをインストールする（ステップ１３００６）。
【００６８】
一方、これらが同一でない場合は、不正なアプリケーションである可能性があるのでインストール処理を中止し、その旨をカード外にエラーメッセージで伝える（ステップ１３００７）。
【００６９】
＜カード発行者：カード発行者が代理署名を用いた事前提携処理を行う処理例＞図１１は、カード発行者が代理署名を用いた事前提携処理を行う場合のフローチャートである。このステップは図９における、ステップ１２００１及び１２００２に対応する。
【００７０】
カード発行者は、代理者を認める事前提携処理をはじめる。
【００７１】
カード発行者は、代理認定証を作成するため、代理者から公開鍵を受け取る（ステップ１４００２）。
【００７２】
カード発行者は、ＩＣカード内に格納してある鍵と、これに対応する鍵でこの公開鍵に署名を行い、代理者に戻す（ステップ１４００３）。 以上が、カード発行者―代理者間の事前提携フローである。
【００７３】
図１２は代理署名を用いた、代理者の事前提携処理手順を示すフローチャートである。代理者はカード発行者の代行業務を行うために事前提携処理を行う。まずカード発行者に代理者の公開鍵を送信し（ステップ１５００２）、カード発行者の署名が付与された代理認定証を受け取る（ステップ１５００３）。
【００７４】
＜代理者：代理署名を用いた、アプリケーション搭載処理の例＞
図１３は代理署名を用いた、アプリケーション搭載処理手順を示すフローチャートである。
【００７５】
代理者は、サービス提供者からのアプリケーション搭載要求を受領する（ステップ１６００２）。
【００７６】
代理者は、事前に登録されていたアプリケーションの内容やサービス提供者の正当性を確認し、アプリケーション搭載を許可できるかどうかを判断する（ステップ１６００３）。
【００７７】
搭載を許可する場合、代理者は、アプリケーション認証書をサービス提供者に送り返す（ステップ１６００４）。このアプリケーション認証書は、サービス提供者から送られてきたアプリケーションの特徴を示すデータを、代理者が鍵で暗号化したデータとカード発行者から事前提携時に受け取っている代理認定証を合わせたものである。尚、前記アプリケーションの特徴を示すデータは、例えば、前述のアプリケーションのハッシュ値などである。
【００７８】
搭載不可の場合は、代理者は、その旨をサービス提供者に伝える（ステップ１６００５）。
【００７９】
＜サービス提供者：サービス提供者のアプリケーション搭載処理の例＞
図１４は代理署名を用いた、サービス提供者のアプリケーション搭載処理手順を示すフローチャートである。
【００８０】
サービス提供者は、代理者に対して、アプリケーションの特徴を示すデータ、例えばハッシュ値などを送付して搭載許可を要求する（ステップ１７００２）。
【００８１】
サービス提供者は、代理者からアプリケーション認証書を受け取り（ステップ１７００３）、アプリケーションと合わせてＩＣカードに送信する（ステップ１７００４）。
【００８２】
以上が、代理署名方式を利用してＩＣカードにアプリケーションを搭載する場合の処理手順の例である。
【００８３】
次に、前記本願発明の第１の形態の機能を補足する第２の形態の具体例を説明する。前述したように、その形態を要約すると、ＩＣカードが、いわゆる限定機能付きのセキュリティドメインを有することである。
【００８４】
上述のように、代理認定証を渡すことで問題点は解決したが新たに起こる問題として、一度代理認定証を発行したら、代理者はそれ以降無制限にアプリケーションを搭載できる権限を持つということがある。ＩＣカード上のアプリケーション搭載領域は無限にあるわけではなく、また提携契約などは期限を設定して結ばれることが通常であるため、カード発行者にとって「アプリケーション1個分の搭載許可権限を与えたい」あるいは「有効期限を設定した上での搭載許可権限を与えたい」などの要求を満たす仕組みが望まれる。
【００８５】
そこで、本願の第２の形態が提案された。図１５は「限定機能付きセキュリティドメイン」を用いる場合の全体構成図である。
【００８６】
図１５において、ＩＣカード（１１）、カード発行者（３０２）、代理者（９０１）、サービス提供者Ｂ（８０３）のプレーヤの役割と関係は図１１と同様である。カード発行者（３０２）と代理者（９０１）の間で提携契約を結び、代理者（９０１）がカード発行者（３０２）の代理としてアプリケーション搭載許可を行う方式であることは図１１と同じであるが、異なる点としてアプリケーションを搭載する前に、セキュリティドメインを搭載する必要がある点である。以下の説明では、図９の例と異なる点を主に説明し、同じ諸点は説明を省略する。
【００８７】
セキュリティドメインとはカード内で、アプリケーション搭載、削除、あるいは管理を行うものである。こうした管理を可能ならしめる前提条件としては、（１）セキュリティドメイン内部に非対称鍵暗号鍵を格納することが可能であることと、（２）アプリケーションはセキュリティドメインを通してカードに格納されることが挙げられる。セキュリティドメインの具体的な形態はアプリケーションの場合もあり、ライブラリの場合もあり、データの場合もある。また、従来はアプリケーション搭載を行う事業者が、セキュリティドメインを作成していた。しかし、本願発明では、カード発行者が作成する。提携契約時にカード発行者（３０２）は代理者（９０１）に代理者として認める代理者認証書の他に限定機能付きセキュリティドメインを渡す。カードＡにアプリケーションを搭載希望するサービス提供者ＢはまずカードＡにセキュリティドメインを搭載するため代理者のもとにある限定機能付きセキュリティドメインを受け取りカード内に設定する。その後アプリケーション搭載許可を代理者から受け取りアプリケーションを前記セキュリティドメインを通してカード内に格納する。
【００８８】
図１６は、代理署名と限定付きセキュリティドメインの機能を合わせて用い、提携を実現する際の処理シーケンスを示す図である。
【００８９】
カード発行者（３０２）と代理者（９０１）の間でお互いの運用ポリシーに基づき提携契約を結ばれている。提携契約に合意した場合、代理者はカード発行者に自らの非対称鍵公開鍵を送付し代理者認証書を要求する（ステップ１９００１）。
【００９０】
カード発行者（３０２）は受け取った公開鍵に対して、自らの非対称鍵秘密鍵で署名を行い、代理者認証書を代理者（９０１）に送付する（ステップ１９００２）。
【００９１】
次にセキュリティドメインに格納する鍵に関連するやり取りを行う。セキュリティドメインには、運用時にはカード発行者の鍵と代理者の鍵が格納される。まず、代理者（９０１）はセキュリティドメイン用の非対称鍵のペアを作成し、その秘密鍵をカード発行者（３０２）に送付する（ステップ１９００３）。
【００９２】
但し、秘密鍵の内容はカード発行者を含め他者には知られてはセキュリティ上問題があるので、秘密鍵をブラインド化し送付する。カード発行者も同様にセキュリティドメイン用の非対称鍵のペアを作成し、この秘密鍵を用いて、受け取った代理者のブラインド化した秘密鍵に署名を行い、代理者に戻す（ステップ１９００４）。
【００９３】
これを受け取った代理者はブラインドを解除する。非対称鍵におけるブラインド署名の方式は既に知られている技術である。この方式自体は、例えばＲＳＡブラインド署名などが知られている。それは、例えば、岡本龍明、山本博資著『シリーズ／情報科学の数学 現代暗号』（産業図書株式会社発行、１９９７）に見られる。
【００９４】
その後、カード発行者（３０２）は、提携契約に応じた内容の限定条件を設定したセキュリティドメインを作成し、自らのセキュリティドメイン用公開鍵をその内部に格納する。もしくは、あらかじめ提携契約の内容に応じて作成してあったセキュリティドメインにセキュリティドメイン用公開鍵をセットする。このセキュリティドメインにカード発行者の秘密鍵で署名を行い、代理者に限定機能付きセキュリティドメインとして送付する（ステップ１９００５）。こうして、事前提携時のやり取りは完了する。
【００９５】
ここで一つ注意すべき点としては、「カード発行者の鍵」と「代理者の鍵」というそれぞれの非対称鍵の他に、「カード発行者のセキュリティドメイン用の鍵」と「代理者のセキュリティドメイン用の鍵」が存在することが挙げられる。
【００９６】
次にアプリケーション搭載時のやり取りに関して説明する。アプリケーションはセキュリティドメインがカード内に設定されていることが前提なので、最初にセキュリティドメインの搭載方法を説明する。
【００９７】
＜セキュリティドメインの搭載方法の例＞
カードＡ（１１）へサービス提供者Ｂ（８０３）のセキュリティドメインを搭載する場合、サービス提供者Ｂのセキュリティドメインとは、事前提携時にカード発行者（３０２）から代理者（９０１）へと送付された限定機能付きセキュリティドメインのことである。代理者（９０１）は、サービス提供者からのセキュリティドメイン搭載許可要求を受ける（ステップ１９００６）。
【００９８】
限定機能付きセキュリティドメインをサービス提供者Ｂに送付する（ステップ１９００７）。ただし、あらかじめセキュリティドメインを配布しておくことも可能なので、ステップ１９００６とステップ１９００７に関しては、順序が逆の場合もあり得る。代理者はステップ１９００４において受け取りブラインド解除してあった署名付き秘密鍵とそれに対応する公開鍵をセキュリティドメイン用鍵ペアとしてサービス提供者Ｂに送付する（ステップ１９００８）。
【００９９】
このセキュリティドメイン用公開鍵は暗号化や署名はされておらず、サービス提供者Ｂが該セキュリティドメインと通信する上での署名検証や、セキュアな通信確保などに使用する。次にサービス提供者Ｂは限定機能付きセキュリティドメインをカードに格納する（ステップ１９００９）。こうして、ＩＣカードは、このセキュリティドメインの正当性を検証する。限定付きセキュリティドメインは、ステップ１９００５についての記述にもあるように、カード発行者の鍵の署名が付与されており、カード内にはカード発行時にカード発行者の公開鍵が搭載されている。従って、ＩＣカードは、この鍵を用いて当該セキュリティドメインの正当性検証が可能である。
【０１００】
正当性が確認できた場合、サービス提供者Ｂよりセキュリティドメイン用秘密鍵を受け取り（ステップ１９０１０）、この鍵の正当性を検証する。ステップ１９００４についての記述にもあるように、このセキュリティドメイン用鍵とは、代理者のセキュリティドメイン用秘密鍵にカード発行者のセキュリティドメイン用秘密鍵で署名を行っているものである。カード内に設定された限定機能付きセキュリティドメインにはカード発行者のセキュリティドメイン用公開鍵が設定されているので、内部で署名の正当性を検証可能である。セキュリティドメイン用鍵の正当性が確認できた場合、鍵は復号化され代理者のセキュリティドメイン用秘密鍵が限定機能付きセキュリティドメイン内部に設定される。
【０１０１】
ここまでで、限定付きセキュリティドメインは、ＩＣカードに格納され、鍵も設定されたので機能し始める。当該セキュリティドメイン内部には
（ａ）カード発行者が該セキュリティドメイン用に作成した公開鍵と
（ｂ）代理者が該セキュリティドメイン用に作成した秘密鍵
とが格納されている。前記（ａ）の項目に対応する秘密鍵はカード発行者が保持している。また、前記（ｂ）の項目に対応する公開鍵はサービス提供者Ｂに送付されている。つまり、カード発行者によって作成された限定機能付きセキュリティドメインは２つの主体者の鍵を保持し、カードＡ内で機能するのである。
【０１０２】
次にカードＡ（１１）へサービス提供者Ｂ（８０３）によるアプリケーション搭載時の説明を行う。
【０１０３】
まず、サービス提供者Ｂが代理者にカードＡに対するアプリケーション搭載許可要求を行う（ステップ１９０１１）。アプリケーション搭載許可要求は、具体的には、搭載するアプリケーションのハッシュ値を送付することである。
【０１０４】
代理者（９０１）は、サービス提供者（８０３）と事前に申請されているアプリケーションの内容を照会しその正当性を確認する。また、カード発行者よりホットリスト（不正カード情報・ブラックリスト）などカードＡに関する情報が提供されていればそれを確認する。代理者は受け取ったアプリケーションのハッシュ値に自らの秘密鍵で代理署名し、ステップ１９００２で受け取った代理者認証書と合わせてサービス提供者Ｂに送付する（ステップ１９０１２）。なお、この秘密鍵は提携契約時にカード発行者に送付した非対称公開鍵に対応するものである。
【０１０５】
サービス提供者Ｂはステップ１９００８で取得しているセキュリティドメイン用公開鍵でアプリケーションを暗号化しておき、アプリケーション搭載許可要求の回答として送付されてくる代理署名付きアプリケーションハッシュ値、代理者認証書を、この暗号化したアプリケーション本体を合わせてカードに送信する（ステップ１９０１２）。
【０１０６】
カードＡは、以上の情報を限定機能付きセキュリティドメインが受け取り、まず代理者認証書の署名検証を行う。代理者認証書は代理者の公開鍵に対して、カード発行者のセキュリティドメイン用秘密鍵で署名されたもので、限定機能付きセキュリティドメイン内部には対応する公開鍵が保持されているので、これを用いて署名検証し、即ち、復号化する。
【０１０７】
ここで、復合化が可能ということは、署名が正しいことを示している。アプリケーションのハッシュ値に代理署名した鍵は、代理者の秘密鍵なので、復号化した代理者の公開鍵を用いてハッシュ値を復号化して取り出す。また一方アプリケーションには代理者のセキュリティドメイン用公開鍵で暗号化されているが、限定機能付きセキュリティドメイン内部にはこれに対応する秘密鍵が格納されているため、これを用いてアプリケーションを復号化し、ハッシュ値をとる。これが先程のハッシュ値と同一であるかを照会し、同一であれば正当なアプリケーションとしてカードＡ内にロード・インストールし、アプリケーション搭載完了となる（１９０１３）。
【０１０８】
以上の手順は、アプリケーションの正当性を代理者（９０１）が保証し、代理者の正当性をカード発行者（３０２）が保証することで、間接的にカード発行者（３０２）の保証のもとにアプリケーションを搭載する仕組みとなっている。先に、セキュリティドメインに格納されている２つの鍵を、（ａ）カード発行者作成鍵、（ｂ）代理者作成鍵と記した。
【０１０９】
（ａ）の鍵は代理者認証書の検証を行い、一方（ｂ）の鍵はアプリケーションの検証を行っている。
【０１１０】
代理署名のみを使用した仕組みとの違いとしては、次ぎの事項が挙げられる。（１）第１は、カード内で正当性を検証する鍵はセキュリティドメイン内部に保持されていることである。
【０１１１】
（２）第２は、上記の鍵はあらかじめ該セキュリティドメイン用にカード発行者と代理者がそれぞれ作成したものであることである。
【０１１２】
（３）第３は、アプリケーション搭載・削除・管理や上記鍵の使用は該セキュリティドメイン、もしくはセキュリティドメイン情報を用いたカードＯＳが行うことである。
【０１１３】
前述したように、アプリケーション搭載、削除及び管理は、本願発明における限定機能付きセキュリティドメインによりコントロールされている。そして、それをカード発行者が、提携契約条件に従って作成していることから、無制限なアプリケーション搭載は避けることが可能である。代理者が不正に代理署名を行ったとしても、本願発明によれば、次ぎの方策が可能である。即ち、提携契約時に、「アプリケーション１つのみ搭載可能」、「ある日時にまで搭載期限」、「ある容量を超えて搭載不可能」などの適当な条件を付け、その限定機能を付けてセキュリティドメインを、作成すれば良い。カード発行者とその他プレーヤとの間は、提携契約時以降オフラインとなっていて、カード発行者の意志に反してカードにアプリケーションが送信されてきても、カード内の当該セキュリティドメインが搭載を拒否することになる。
【０１１４】
以上説明した限定機能付きセキュリティドメインを用いる際の基本処理シーケンスに基づく動作の更なる動作例の詳細を、図１７から図２４を用いて説明する。即ち、各図は、各々ＩＣカード、カード発行者、代理者、サービス提供者の各プレーヤ毎の動作フローチャートである。本図面で“ＳＤ”記載されているのは本願発明で提案する限定機能付きセキュリティドメインのことであり図面の説明においてもＳＤと表す。
【０１１５】
＜ＩＣカード：ＳＤ搭載処理の例＞
図１７は、本発明方式を利用したＳＤ搭載処理を行うカードのフローチャートである。この処理は、図１９の１９００９及び１９０１０の両ステップに対応する。
【０１１６】
ＩＣカードはサービス提供者からＳＤを受信する（ステップ２０００２）。
【０１１７】
ＳＤは発行者の鍵により署名されているので、カード内の対応する鍵を用いて復号化する（ステップ２０００３）。
【０１１８】
このＳＤの署名が正しければ、ＳＤをカード内にインストールし（ステップ２００５）、正しくない場合はＳＤのインストールを中止しカード外にその旨を伝える（ステップ２００１０）。
【０１１９】
ＳＤをインストールした後は、ＳＤ内に設定する鍵を受信する（ステップ２０００６）。これはカード発行者のＳＤ用鍵で署名されているが、対応する鍵がＳＤ作成時に内部に設定されているので、これを用いて署名を復号化する（ステップ２０００７）。
【０１２０】
正しい鍵かどうかを検証し(ステップ２０００８)、正しければＳＤ内に鍵を設定し(ステップ２０００９)、不正であれば、ＳＤへの設定を中止しカード外にその旨を伝える（ステップ２００１１）。
【０１２１】
＜ＩＣカード：アプリケーション搭載処理の例＞
図１８は、本願発明方式を利用したアプリケーション搭載処理を行うカードのフローチャートである。この処理は、図１６の１９０１３のステップに対応する。
【０１２２】
カードはアプリケーション搭載処理を開始すると（ステップ２１００１）、代理認定証と代理者が署名したアプリケーション認証書とサービス提供者が持つＳＤ用鍵で暗号化したアプリケーションをサービス提供者より受信する（ステップ２１００２）。
【０１２３】
代理認定証はカード発行者により署名されており対応する鍵がＳＤ内に格納されているので、それを使用して代理認定証を検証し、代理者の鍵を復号化する（ステップ２１００３）。
【０１２４】
復号化した代理者の鍵を用いて、代理者が署名したアプリケーション認証書の検証を行い、アプリケーションのハッシュ値を取り出す（ステップ２１００４）。
【０１２５】
アプリケーションはサービス提供者により暗号化されているが、対応する鍵がＳＤ内にあるのでそれを用いてアプリケーションを復号化し取り出し（ステップ２１００５）、そのハッシュ値をカード内で計算し、さきほど復号化したハッシュ値と同一かどうかを確認する(ステップ２１００６)。
【０１２６】
もし、同一であればカード発行者が認証した正当なアプリケーションだと認めインストールする（ステップ２１００７）。
【０１２７】
同一でない場合は、不正なアプリケーションである可能性があるのでインストール処理を中止し、その旨をカード外にエラーメッセージで伝える（ステップ２１００８）。
【０１２８】
＜カード発行者：事前提携処理の例＞
図１９は、カード発行者が、本発明を利用した事前提携処理を行う場合のフローチャートである。この処理は、図１６のステップ１９００１より１９００５にかけてのステップである。
【０１２９】
カード発行者は、代理者を認める事前提携処理をはじめると、代理認定証を作成するため代理者から公開鍵を受け取る（ステップ２２００２）。
【０１３０】
発行者は、カード内に格納してある鍵と対応する鍵で、この公開鍵に署名を行い、代理者に戻す（ステップ２２００３）。
【０１３１】
また、ＳＤ格納用の鍵を代理者から受け取り（ステップ２２００４）、ＳＤ作成時に内部に設定してある鍵と対応する鍵で暗号化し代理者に送信する（ステップ２２００５）。ＳＤを発行者の鍵で署名し代理者に送信する（ステップ２２００６）。
【０１３２】
＜代理者：事前提携処理の例＞
図２０は本発明を利用した代理者の事前提携処理手順を示すフローチャートである。
【０１３３】
まずカード発行者に代理者の公開鍵を送信し（ステップ２３００２）、カード発行者の署名が付与された代理認定証を受け取る（ステップ２３００３）。
【０１３４】
ＳＤ搭載用の鍵を生成し、秘密鍵にブラインド化処理を行いカード発行者に送信する（ステップ２３００４）。
【０１３５】
発行者の署名が付与された上記鍵を受け取りブラインド化解除処理を行う（ステップ２３００５）。
【０１３６】
発行者の鍵を内部に含むＳＤを発行者より受け取る（ステップ２３００６）。このＳＤはカード発行者の鍵により署名が付与されている。
【０１３７】
＜代理者：ＳＤ搭載要求受付け処理の例＞
図２１は本発明を利用した代理者のＳＤ搭載要求受付け処理手順を示すフローチャートである。この処理は、図１９のステップ１９００６より１９００８のステップに対応する。
【０１３８】
サービス提供者からのＳＤ搭載要求を受信すると（ステップ２４００２）、発行者から受け取ってある署名付きＳＤをそのままサービス提供者に送信する（ステップ２４００３）。
【０１３９】
また次に、あらかじめ作成してあったＳＤ用鍵ペアをサービス提供者に送信する（ステップ２４００４）。このＳＤ用秘密鍵は事前提携処理において発行者に署名を付与されているものである。
【０１４０】
＜代理者：アプリケーション搭載要求受付け処理の例＞
図２２は本発明を利用した代理者のアプリケーション搭載要求受付け処理手順を示すフローチャートである。
【０１４１】
サービス提供者からのアプリケーション搭載要求を受領すると（ステップ２５００２）、事前に登録されていたアプリケーションの内容やサービス提供者の正当性を確認し、アプリケーション搭載を許可できるかどうかを判断する（ステップ２５００３）。
【０１４２】
搭載を許可する場合、サービス提供者から送られてきたアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを代理者が鍵で暗号化したデータとカード発行者から事前提携時に受け取っている代理認定証を合わせてアプリケーション認証書として、サービス提供者に送り返す（ステップ２５００４）。搭載不可の場合は、その旨をサービス提供者に伝える（ステップ２５００５）。
【０１４３】
＜サービス提供者：ＳＤ搭載処理の例＞
図２３は本発明を利用したサービス提供者のＳＤ搭載処理手順を示すフローチャートである。
【０１４４】
サービス提供者は、ＳＤ搭載を代理者に要求し（ステップ２６００２）、発行者の署名が付与されているＳＤを受け取り（ステップ２６００３）、カードに送信する（ステップ２６００４）。
【０１４５】
カードへのＳＤ設定ができたら、代理者からＳＤ用鍵ペアを受け取る（ステップ２６００５）。
【０１４６】
カード発行者の署名が付与されているＳＤ用秘密鍵をカード内のＳＤに送信し設定する（ステップ２６００６）。
【０１４７】
＜サービス提供者：アプリケーション搭載処理の例＞
図２４は、本発明を利用したサービス提供者のアプリケーション搭載処理手順を示すフローチャートである。
【０１４８】
サービス提供者は、代理者に対してアプリケーションのハッシュ値などを送付して搭載許可を要求し（ステップ２７００２）、代理者からアプリケーション認証書を受け取る（ステップ２７００３）。
【０１４９】
アプリケーションをＳＤに設定した鍵と対応する鍵で暗号化し、アプリケーション認証書と合わせてカードに送信する（ステップ２７００４）。
【０１５０】
以上が、本願発明のアプリケーション搭載方式に従いＩＣカードにアプリケーションを搭載する場合の処理手順である。
【０１５１】
次に、本願発明を用いて実現可能なＩＣカードの各種利用形態や運用の諸形態について説明する。
【０１５２】
図９において、本発明における提案方式では９０１の代理者が発行者（３０２）の代行業務を行うが、この代行業務を３０２とは別の発行者が行えば、カードＡ（１１）には発行者Ａ（３０２）が契約したサービス提供者だけでなく、発行者（９０１）が契約したサービス提供者のアプリケーションをも搭載することが可能となる。つまり既存の発行者―サービス提供者の仕組みを組み合わせることで本願発明を利用することが可能である。
【０１５３】
また、発行者間でお互いがお互いの代理者であれば、双方のカードにどちらのサービス提供者のアプリケーションが搭載可能となる。本発明方式を利用することで、既存カード運用管理システム間の相互運用が可能となる。
【０１５４】
次に本願発明のカードシステムのいくつかの具体的な応用例について説明する。
【０１５５】
第１の例はテナント業務である。図２５を用いて、このテナント業務と言う本願発明の応用について説明する。本願明細書におけるテナント業務とは、ＩＣカード上の部分領域を、カード発行者以外のテナントビジネス事業者に貸与する、即ち、テナント運用する業務のことを言う。
【０１５６】
図２５は、ＩＣカード上の部分領域を運用する概念を示した図である。
【０１５７】
この例では、本願発明に係る代理署名及び限定機能付セキュリティドメインとを用いて、ＩＣカードに提携業務の関するアプリケーション搭載を行う。
【０１５８】
図２５を参酌して本例を説明する。カード発行者（２８０１）は、ＩＣカード（１１）を発行し、ＩＣカードに係わる責任を全て負う事業者である。カード発行者（２８０１）は、サービス提供者（２８０２）やサービス提供者（２８０３）と契約を結び、ＩＣカード（１１）上へ、各々のアプリケーション搭載を許可する。更に、本例では、テナントビジネス事業者（２８０４）がテナントを希望する事業者（２８０５）に、
そのアプリケーションの搭載について認証を与える。こうして、テナントを希望する事業者（２８０５）は、前記ＩＣカード（１１）の提携に係わるアプリケーション領域にアプリケーションを搭載する。ここで、テナントを希望する事業者は、これまでの説明におけるサービス提供者である。又、テナントをビジネスとして行おうとする事業者は、これまでの説明における代理者である。
【０１５９】
ＩＣカード（１１）には、マルチアプリケーション搭載を可能とし、且つ、ダイナミックローディング可能であるカードＯＳ（２８１０）が搭載されており、カード上の機能を実行する。セキュリティドメインはカードＯＳ上に設定されており、２８１１はサービス提供者（２８０２）の、２８１２はサービス提供者（２８０３）のそれぞれセキュリティドメインである。
【０１６０】
サービス提供者（２８０２）はセキュリティドメイン（２８１１）を通して自らのアプリケーション（２８１４、２８１５）を搭載する。同様にサービス提供者（２８０３）はセキュリティドメイン（２８１２）を通して自らのアプリケーション（２８１６、２８１７）を搭載する。ここで、代理者（２８０４）と提携契約を結んでいるサービス提供者（２８０５）がアプリケーションをＩＣカード（１１）に搭載する場合は、限定機能付きセキュリティドメイン（２８１３）を通してアプリケーション（２８１８、２８１９）を搭載する構成となっている。このセキュリティドメイン（２８１３）はある限定機能を付与されており、自らが搭載したアプリケーションを管理しているので、図中斜線部分の領域を考えると、セキュリティドメインにより管理されている領域であるといえる。
【０１６１】
搭載許可は代理者（２８０４）が行うので、この搭載領域は、カード発行者（２８０１）より借りうけて、サービス提供者（２８０５）などにサービス提供の場を貸し出している構図となっている。これをビルの所有者からフロアを借り受けて店子を募集するテナントビジネス事業者に対応させると、新しくＩＣカード上の領域を、テナントして運用するＩＣカードの運用形態が考えられる。その場合、代理者（２８０４）は、
ＩＣカードを所有するカード発行者（２８０１）からＩＣカード上のある領域を借り受け、その領域上に、サービスを提供するサービス提供者（２８０５）と契約する業務を行う仲介事業者としての機能があれば良い。
【０１６２】
以上、本例はＩＣカードの一部の所定領域を、テナントビジネス事業者にその利用を貸与する利用形態である。その具体的なアプリケーションの搭載に関する代理者、サービス提供者の動作については、これまで説明してきた本願発明の一般的な運用と同様である。
【０１６３】
また、図２６ではカード発行者（２９０１）が契約関係にあるサービス提供者に限定機能付きセキュリティドメインを対応させた場合の利用形態について説明する。図２５の例との違いは、カード発行者とサービス提供者（２９０５）との間に代理者（２８０４）をおかず、カード発行者（２９０１）が、直接契約しているサービス提供者（２９０５）であることである。その他の点は前述の例と同様である。
【０１６４】
この利用形態の利点は、アプリケーション搭載のオフライン認証におけるセキュリティを高くする点である。サービス提供者がアプリケーションを搭載する際に、カード発行者へ認証を要求するのが従来一般的であることは、既に述べた。この場合、要求方法として、ネットワークなどを使用して通信を確立しオンラインで認証してもらう場合と、あらかじめ許可証を大量に発行してもらうオフライン認証がある。オフライン認証の場合、カード発行者のＩＣカードへのコントロールが弱くなる点が問題となっている。しかし、カード上の限定機能付きセキュリティドメインに制限を設定しておくことで、この問題は、コントロール可能となる。また、契約しているサービス提供者間で差異をつけることが可能となり、事業者の信頼度に応じた契約締結ができる。
【０１６５】
次に、ＩＣカードにおけるバーチャルカードという本願発明のＩＣカードの応用を提案する。
【０１６６】
図２７は、バーチャルカードの概念を説明する図である。バーチャルカ−ドとは、このカードを統括する第３者の認証の下に、複数のカード発行者によるカードの機能に応ずる各々のアプリケションを、一つのカードの所定のアプリケーション領域に搭載したカードの用い方である。従って、一つのカードによって、あたかも複数のカードを持っているかのようにカードを運用することが出来る。
【０１６７】
図２７において、カードＡ（３００５）、カードＢ（３００６）、カードＣ（３００７）は、個別のＩＣカードであり、それぞれのカード発行者は、第３者（３００１）と提携契約を結んでいる。以下、この第３者（３００１）を、便宜上バーチャルカード発行者と呼ぶ。バーチャルカード発行者（３００１）は、カードＡ上にアプリケーション搭載領域を借り受けているため、バーチャルカード発行者（３００１）と契約の有るサービス提供者（３００２、３００３、３００４）は搭載条件さえクリアすれば、カードＡ上にアプリケーション搭載可能である。バーチャルカード発行者（３００１）は契約さえ有れば、同様に、カードＢにもカードＣにもアプリケーション搭載可能である。つまり、バーチャルカード発行者（３００１）は、実際のカード発行業務を行っていないにも関わらず、バーチャルカード（３００８）のような概念上のカードを発行しており、バーチャルカード発行者（３００１）と契約すればアプリケーション搭載可能なカードと見なすことができる。サービス提供者側から見ると、複数のカードにアプリケーションを搭載するために、１つのカード発行者のみと契約を結び通信を確立すれば良いので大幅手間が省けコスト削減につながる。
【０１６８】
以上、本願諸発明を説明したが、その要点をまとめると次ぎの通りである。
【０１６９】
本願発明は、ＩＣカードのカード発行者の許可を直接得ることなく、しかしながら同程度の高セキュリティを保持しながらアプリケーションを搭載することを可能とする。将来、ＩＣカードが普及し、利用数が増加することに伴い発生するであろう下記の諸難点に関しては、カード発行者同士の提携契約とそれに伴う情報のやり取りにより、提携先サービス提供者とカード発行者が直接通信を確立する必要がなくなったため解決される。こうして、本願発明によって、ＩＣカードへの柔軟なサービス提供が可能となった。尚、上記難点とは、第１がカード発行者―サービス提供者間に起こる膨大な量の契約と通信の問題であり、第２が現実的に契約関係を結べない事業者同士の問題である。
【０１７０】
また、解決方法の一つである代理署名を用いることにより付随して起こる難点として、第１に一度代理者認証書を発行してしまうと無制限に使用される危険性、第２に搭載回数、搭載領域など条件を付けた提携契約を結ぶ必要性を挙げることが出来る。この難点は、限定機能付きのセキュリティドメインを用いることで回避することが出来る。
【０１７１】
さらに、本願発明のアプリケーションの搭載方式を利用することで、
各種の新しいＩＣカードの利用形態を可能とした。
【０１７２】
こうした新しいＩＣカードの利用形態の例を列挙すれ、下記の通りである。（１）既存システムへの応用方式、（２）発行者間で相互に代行業務を行うことによる相互運用方式、（３）ＩＣカード上の領域を借り受け運用するテナント事業、（４）カード発行者によるサービス提供者間のアプリケーション搭載における差異の設定、（５）バーチャルカード発行事業。
【０１７３】
本願は、その形態が多岐に渡るので、以下に主な形態、あるいは概念を整理し、列挙する。
【０１７４】
その第１は、非対称暗号化機能を有するＩＣカードを利用した署名生成及び検証方式において、
ＩＣカード発行者がＩＣカードにみずからの公開鍵を格納し利用者に配布するステップと、
ＩＣカード発行者が第３者（以降代理者と呼ぶ）の公開鍵を受け取り、
カード発行者の秘密鍵で署名を付与し代理者に戻すステップと、
代理者が自らの秘密鍵でデータに署名を付与するステップと、
代理者が前記カード発行者より受け取ったカード発行者署名付き代理者公開鍵とそのデータを合わせてカードに送信するステップと、
カード内のカード発行者公開鍵で前記付与したカード発行者署名付き代理者公開鍵を検証するステップと、
この代理者公開鍵でデータの署名を検証し正当性を確認するステップを
有することを特徴とする署名生成及び検証方式である。
【０１７５】
第２は、ＩＣカード発行者がＩＣカードに自らの公開鍵を格納し利用者に配布するステップと、
発行者が代理者の公開鍵を受け取り、自らの秘密鍵で署名し代理認定証として渡すというステップと、
アプリケーションをカードに発行する業務を行う事業主体者（以降サービス提供者と呼ぶ）がアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを代理者に渡すというステップと、
代理者は渡されたアプリケーションのハッシュ値などに代理者の秘密鍵で署名を行うステップと、
上記署名付きハッシュ値と発行者より渡されている代理認定証を合わせてアプリケーション認証書としてサービス提供者に戻すというステップと、
サービス提供者がアプリケーションとアプリケーション認証書を合わせてカードに搭載するというステップと、
カード内の発行者公開鍵により代理認定証を検証するステップと、
上記検証された代理者の公開鍵によりカード内でアプリケーションのハッシュ値を検証するステップと、
カード内でアプリケーションのハッシュ値を計算するステップと、
検証されたハッシュ値と計算されたハッシュ値を比較することでアプリケーションの正当性を確認するステップを
有することを特徴とするアプリケーション搭載方式である。
【０１７６】
第３は、ＩＣカード内でアプリケーションの搭載・削除・管理機能を行うアプリケーションもしくはデータ（以降セキュリティドメインと呼ぶ）であって、
カード発行者により作成され、
アプリケーション搭載に関する所定の制限がカード発行者により設定可能であり、
内部に発行者の公開鍵が格納されている状態で代理者に渡され、
代理者によりサービス提供者に渡され、
サービス提供者によりカード内に搭載され、
その後サービス提供者により当該セキュリティドメイン内に代理者の秘密鍵を設定され、
アプリケーション搭載時に当該セキュリティドメイン内のカード発行者の公開鍵により代理者の公開鍵の署名を検証し、
上記代理者の公開鍵を用いてアプリケーションのハッシュ値の署名を検証しアプリケーションの正当性を確認する
ことを特徴とするＩＣカード内でアプリケーションの搭載・削除・管理機能を行うセキュリティドメインである。
【０１７７】
第４は、前記署名生成及び検証方式と、前記セキュリティドメインを利用したＩＣカードへのアプリケーション搭載方式である。即ち、
発行者が代理者に代理認定証と所定の制限を設定したセキュリティドメインを代理者に渡すステップと、
代理者がサービス提供者に、上記セキュリティドメインとセキュリティドメイン用の鍵を渡すステップと、
サービス提供者が、該セキュリティドメインをカードに格納し、鍵を設定するステップと、
サービス提供者が、代理者にアプリケーション認証書を要求し受け取るステップと、
サービス提供者が上記アプリケーション認証書をアプリケーションを合わせてカードに搭載するステップと、
カード内でアプリケーション認証書を検証しアプリケーションの正当性を確認するステップを
有することを特徴とするアプリケーション搭載方式である。
【０１７８】
第５は、セキュリティドメインをサービス提供者から受け取り格納する手段と、
サービス提供者により該セキュリティドメイン内に鍵を設定する手段と、
アプリケーション搭載時にアプリケーションに付与されたアプリケーション認証書を検証する手段と、
アプリケーションをインストールする手段を
有することを特徴とするアプリケーション搭載可能のＩＣカードである。
【０１７９】
第６は、自ら以外の第３者である代理者から渡された公開鍵を受け取り、
自らの秘密鍵で署名を付与し代理認定証として代理者に戻し、
セキュリティドメインを作成・条件設定した上で代理者に渡すことを特徴とするＩＣカード発行者である。
【０１８０】
第７は、ＩＣカードの発行管理業務の一部を代行する事業者（代理者）であり、
自らの公開鍵を発行者に渡し、
発行者の秘密鍵により署名をされた代理認定証を受け取り、
発行者からセキュリティドメインを受け取り、
サービス提供者に該セキュリティドメインとセキュリティドメイン用鍵を渡し、
サービス提供者からアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを受け取り、
それに自らの秘密鍵で署名を付与しそれと代理認定証を合わせてアプリケーション認証書としてサービス提供者に戻すことを特徴とする事業主体者である。
【０１８１】
第８は、代理者からセキュリティドメインとセキュリティドメイン用鍵を受け取り、
カード内にセキュリティドメインを格納し、鍵を設定し、
カードに搭載するアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを、該カードの発行者の代行業務を行う代理者に送信し、
代理者からの代理認定証と代理者の秘密鍵で署名を付与されたアプリケーションのハッシュ値などをアプリケーション認証書として受け取り、
アプリケーション認証書とアプリケーションを合わせてカードに送信することを特徴とするサービス提供者である。
【０１８２】
第９は、前記事業主体者が同時にカード発行管理業務も行い、
自らが発行するカードへのアプリケーション認証書の他に、代理認定証を渡されている発行者の発行したカードへのアプリケーション認証書を発行することが可能であることを特徴とするカード発行者間のカード相互運用方式である。
【０１８３】
第１０は、カードを発行管理する発行者同士が双方とも前記代理者であることにより、
発行者は双方の発行するカードに搭載するアプリケーションの認証書を発行することが可能であることを特徴とするカード発行者間のカード相互運用方式である。
【０１８４】
第１１は、ＩＣカード上の部分領域の運用を行い、
カード発行者に対してはＩＣカード上の部分領域を借り受けていることへの対価を支払い、
サービス提供者に対してはアプリケーション搭載に対する課金や問い合わせなどへのサポート業務を行うことの対価を要求することを特徴とする業務である。
【０１８５】
第１２は、セキュリティドメインの機能を使用したＩＣカードへのアプリケーション搭載方式であって、
サービス提供者は該セキュリティドメインを通してのみアプリケーション搭載可能であり、
該セキュリティドメインに設定される条件はカード発行者がサービス提供者との契約内に応じて設定し、
同一カード上で、サービス提供者毎の条件よりアプリケーション搭載条件が異なることを特徴とするアプリケーション搭載方式である。
【０１８６】
第１３は、代理者が複数のＩＣカード発行者の代理者であり、
サービス提供者からのアプリケーション搭載要求を代理者が受け取り、
上記複数カード発行者からの代理認定証を複数付与したアプリケーション認証書を発行し、
サービス提供者が該アプリケーション認証書を受け取ることで複数カードへのアプリケーション搭載が可能となることを特徴としているＩＣカード発行管理代行業務である。
【０１８７】
第１４は、当該ＩＣカ−ドを発行したＩＣカ−ド発行者が署名した代理者の公開鍵と、代理者が署名したアプリケ−ションとを受け取る手段と、代理者の公開鍵に付与されたＩＣカ−ド発行者の署名を検証する手段と、上記代理者の公開鍵によりアプリケ−ションの署名を検証する手段と、を有するアプリケ−ション搭載可能なＩＣカ−ドである。
【０１８８】
第１５は、ＩＣカ−ドの発行管理業務を行うＩＣカ−ド発行者であり、
自ら以外の第３者である代理者から渡された公開鍵を受け取り、自らの秘密鍵で署名を付与し、これを代理認定証として代理者に戻すＩＣカ−ド発行者である。
【０１８９】
第１６は、ＩＣカ−ドの発行管理業務の一部を代行する事業者（代理者）であり、自らの公開鍵を発行者に渡し、
発行者の秘密鍵により署名をされた代理認定証を受け取り、
サ−ビス提供者からアプリケ−ションの、例えば、ハッシュ値などのアプリケ−ションの特徴を示すデ−タを受け取り、
それに自らの秘密鍵で署名を付与し、それと代理認定証を合わせてアプリケ−ション認定証としてサ−ビス提供者に戻すことを特徴とするアプリケ−ション搭載を実施する事業主体者である。
【０１９０】
第１７は、アプリケ−ションをカ−ドに発行する業務を行う事業主体者（サ−ビス提供者）であり、
ＩＣカ−ドに搭載するアプリケ−ションのハッシュ値などアプリケ−ションの特徴を示すデ−タを、前記ＩＣカ−ドの発行者の代行業務を行う代理者に送付し、代理者からの代理認定証と代理者の秘密鍵で署名を付与されたアプリケ−ションのハッシュ値などをアプリケ−ション認定書として受け取り、
アプリケ−ション認定書とアプリケ−ションを合わせてカ−ドに送信するアプリケ−ション搭載を実施するサ−ビス提供者である。
【０１９１】
【発明の効果】
本願発明の第１の形態は、ＩＣカードのカード発行者の許可を直接得ることなく、カード発行者の許可を得る場合と同程度の高セキュリティを保持しながら、当該ＩＣカードにアプリケーションを搭載することを可能とする。加えて、本願発明の第１の形態は膨大なの契約と通信の量の増大に基づく、現実的各種処理の煩雑さを解消する。
【０１９２】
本願発明の第２の形態は、ＩＣカードのカード発行者の許可を直接得ることなく、ＩＣカードにアプリケーションを搭載する場合に付随して生ずるアプリケーションの搭載の無制限性の難点を回避する。
【図面の簡単な説明】
【図１】図１はＩＣカードの基本構成を示す図である。
【図２】図２はＩＣカードの発行、サービス提供に関するこれまでのシステム構成の例である。
【図３】図３はセキュリティドメイン機構を持つＩＣカードの基本構成を示す図である。
【図４】図４は従来のアプリケーション搭載の為のシーケンスの例を示す図である。
【図５】図５は従来方式における難点を説明する為の図である。
【図６】図６は本願発明におけるＩＣカード、発行者、代理者、及びサービス提供者の関係を示す図である。
【図７】図７は本願発明のシステムの基本的な構成を示す図である。
【図８】図８は代理署名を行う場合のＩＣカード、発行者、代理者、及びサービス提供者の関係を示す図である。
【図９】図９は代理署名による提携を実現するシーケンスを示す図である。
【図１０】図１０は、ＩＣカードにアプリケーションを搭載する為の本願発明に係わるシーケンスを示す図である。
【図１１】図１１は、カード発行者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図１２】図１２は代理者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図１３】図１３は代理者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図１４】図１４はサービス提供者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図１５】図１５はセキュリティドメインを有するＩＣカードの基本構成を示す図である。
【図１６】図１６は代理署名及びセキュリティドメインを用いた提携を実現する為の本願発明のシーケンスを示す図である。
【図１７】図１７はＩＣカードにＳＤを搭載する為の本願発明のシーケンスを示す図である。
【図１８】図１８はＩＣカードにアプリケーションを搭載する為の本願発明のシーケンスを示す図である。
【図１９】図１９はカード発行者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図２０】図２０は代理者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図２１】図２１は代理者がＳＤを搭載する為のシーケンスを示す図である。
【図２２】図２２は代理者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図２３】図２３はサービス提供者がＳＤの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図２４】図２４はサービス提供者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図２５】図２５は本願発明を用いたテナント例を示す図である。
【図２６】図２６は本願発明を用いた制限付きサービスの提供契約を行う例を説明する図である。
【図２７】図２７は本願発明を用いたバーチャルカードの例を説明する図である。
【図２８】図２８はカード・システムの概要を示す図である。
【符号の説明】
１１：ＩＣカード、１０１：ＩＣカード内ハードウェア層
１０２：ＩＣカード内ＯＳ層、１０６：ＩＣカード内アプリケーション
１０７：ＩＣカード内アプリケーション層、１０８：セキュリティドメイン、３０２：カード発行者サーバ、３０３：サービス提供者サーバ
３０４：クライアント側用外部端末、３０５：カード発行者データベース、３０６：サービス提供者データベース、８０１、８０２：アプリケーション、８０４、８０５：セキュリティドメイン、８０３：サービス提供者、９０１：代理者、９０２：代理者のデータベース、２８０１：カード発行者、２８０２、２８０３：サービス提供者、２８０４：代理者＝テナントビジネス事業者、２８０５：サービス提供者＝テナント希望事業者、２８１０：カードＯＳ、２８１１、２８１２：セキュリティドメイン、２８１３：限定機能付きセキュリティドメイン
２８１４〜２８１９：アプリケーション、２９０１：カード発行者
２９０２、２９０３、２９０５：サービス提供者
２９０４、２９１０：カードＯＳ
２９１１、２９１２：セキュリティドメイン
２９１３：限定機能付きセキュリティドメイン
２９１４〜２９１９：アプリケーション
３００１：バーチャルカード発行者
３００２〜３００４：サービス提供者、３００５〜３００７：ＩＣカード、３００９〜３０１１：提携先の搭載領域。
【発明の属する技術分野】
本願発明は、ＩＣカードの発行者以外の第三者による動的認証及びＩＣカードへのアプリケーション搭載方法及びその利用に関する諸技術に関するものである。
【０００２】
【従来の技術】
ＩＣカードは、大量の情報が記録可能であり、かつ高度なセキュリティを有するため、磁気カードに代わる新しい情報記録媒体として近年普及しつつある。また、最近ではＩＣカードに複数のアプリケーションを搭載できるマルチアプリケーション機能や、カード発行後にアプリケーションを搭載可能なダイナミックローディング機能を備えたＩＣカード及びカードＯＳが主流となってきている。
【０００３】
従来、これらのＩＣカードへのアプリケーション搭載方式では、該カードを発行した発行者による何らかの署名が付与されたアプリケーションのみを搭載可能としていた。カード発行後に当該カードにアプリケーションを搭載するいわゆる動的搭載も前提としているため、誰にでもアプリケーションが搭載可能であるシステムはセキュリティ上問題があるからである。
【０００４】
図１にＩＣカード（１１）内に搭載されているＩＣ内部の基本的な領域の論理的な構成を示す。当該ＩＣは、ハードウェア層（１０１）とＯＳが搭載される領域、即ちＯＳ層（１０２）とアプリケーションが搭載される領域、即ちアプリケーション層（１０７）とを有する。ここで、マルチアプリケーションの搭載が可能とは、アプリケーション層（１０７）に複数のアプリケーション（１０６）が搭載できることである。又、ダイナミックローディングが可能であるとは、このアプリケーション（１０６）をカード発行後にアプリケーションが搭載あるいは削除が可能であることを示す。ＯＳ層（１０２）は通信処理部（１０３）、インタープリタ（１０４）、セキュリティ機構（１０５）などを有し、外部端末からのコマンドの受信やアプリケーションのコマンドの転送などを行っている。当然、アプリケーション層（１０７）とＯＳ層（１０２）との間にはアプリケーション・インターフェイス、ＯＳ層（１０２）とハードウェア層（１０１）との間にはハードウエア・インターフェイスが設けられる。
【０００５】
図２はＩＣカードの発行やサービスの提供に関する従来のシステム構成図である。カード発行者（３０２）とは、ＩＣカードの発行と管理の業務を行う事業主体者であり、カードの責任を負う主体者である。また、サービス提供者（３０３）はＩＣカード上に搭載するアプリケーションの発行と管理の業務を行う事業主体者である。カード発行後に、アプリケーションをダイナミックに搭載する場合は、サービス提供者の端末からＩＣカードへ搭載することが多い。クライアント側（３０１）にはＩＣカードとコマンドのやり取りを行う外部端末（３０４）がある。カード発行者は発行者データベース（３０５）に発行管理データを保持しており、そのデータに従いカードを発行し利用者に配布する。発行管理データには、利用者からの申請情報や、カードの発行に必要な基本情報が記載されている。ＩＣカード搭載用アプリケーションは、サービス提供者が作成もしくは取得し、ＩＣカードへのアプリケーション搭載を行う。
【０００６】
サービス提供者データベース（３０６）にはアプリケーション関連（以下、ＡＰ関連と称する）データが格納されている。前記のように、ＩＣカード上の全ての責任はカード発行者に帰属するため、アプリケーションの正当性をカード発行者が確認する手順が必要である。サービス提供者はカード発行者のＡＰの搭載を許可する処理部にＡＰ搭載の許可の要求を行う。カード発行者のデータベースには事前に登録されているＡＰに関するデータが格納されている。そして、要求のあったアプリケーションが不正なものではないか、要求をしているサービス提供者が不正ではないかなどをチェックした上で、ＡＰの搭載許可を発行する。サービス提供者はこのＡＰ搭載許可とアプリケーションを合わせてカードに送信し設定するのである。そのため、サービス提供者はあらかじめカード発行者と契約し、自身が正当な事業主であることや、搭載予定のアプリケーションが不正なものではないことを登録する必要がある。
【０００７】
カード発行者とサービス提供者のサーバ間は、ネットワークでつながれている場合が多いと想定されるが、書類形式でやり取りすることも可能である。
【０００８】
またこれに加え、アプリケーション搭載の際に、カード内でアプリケーション搭載を専用に行うアプリケーションもしくはデータを用いる場合がある。この方式は“セキュリティドメイン”というアプリケーションをサービス提供者毎に用意し、アプリケーション搭載・削除・管理の役割を担わせている。図３にセキュリティドメイン機構を持つＩＣカードのＩＣ内部の基本的な領域の論理的な構成を示す。セキュリティドメイン（１０８）はアプリケーション層に存在し自らが責任を持つアプリケーション（１０６）を管理する。アプリケーションはカードに搭載や削除される場合、このセキュリティドメインを通じて行われる。また鍵データなどのセキュリティ情報やＩＤ番号などのデータ管理をセキュリティドメインに委託する場合もある。
【０００９】
【発明が解決しようとする課題】
上記のようなこれまでのＩＣカードへのアプリケーション搭載方式は、高セキュリティを保ちながらアプリケーションの動的な搭載や削除を可能としている。しかし、複数カード発行者やそのサービス提供者間での運用に際してはいくつかの難点がある。
【００１０】
前述のように、サービス提供者は、アプリケーションの搭載を希望するカードのカード発行者に対して、あらかじめ契約を結ぶ必要がある。つまり、カード発行者は、発行するカードにアプリケーションの搭載を希望する全てのサービス提供者と契約関係にあり、そのサービス提供者からの要求を受け、アプリケーション搭載や削除を行う場合は上記アプリケーション搭載方法で良い。図５のように発行者（３０２）と契約関係にあるサービス提供者（３０３）がカードＡ（１１）にアプリケーションを搭載する場合は従来方法でいい。しかし、サービス提供者（８０３）のように、カード発行者とあらかじめ複雑な事前契約やアプリケーションの登録をいちいち行わずにアプリケーションを搭載する要求がでてくるだろう。そもそも、ＩＣカードは複数アプリケーションを搭載可能なことが大きな利点であり、多数のサービスが提供可能であることはカード運用側のカード発行者にとっても利用側のユーザにとっても多大なメリットであるため、このような要求は年々増加するものと予想される。しかし、現在のアプリケーション搭載方式に従い、事前契約などせずにサービスを供給することは不可能である。図５に示すように、サービス提供者（８０３）と発行者（３０２）の間には何らかの情報交換が必要である。つまり、従来のアプリケーション搭載方式に従うならば、サービス提供者はアプリケーション搭載を希望するカードの発行者全てと事前に契約を結ぶ必要があり、アプリケーション搭載時には全てのカード発行者にアプリケーション搭載許可証を発行してもらわなければならない。この実現方法には以下のような難点がある。
【００１１】
（１）カード発行者―サービス提供者間の契約関係及び運用時の通信の増大と複雑化
Ｎ個のカード発行者とＭ個のサービス提供者の間で相互にサービスを運用する場合、Ｎ＊Ｍの契約関係が結ばれることになり膨大な量の契約と運用時の通信が発生することになる。それに伴うコストや時間が増大し最終的にはＩＣカード単価の増加の原因となる。
【００１２】
（２）現実的に契約関係を結べない事業者同士の問題
例えば、インターナショナルカードに国内企業のアプリケーションを搭載する場合、この国内企業がカード発行者と直接コンタクトをとることは現実的にはあまりなく、国内向け窓口業務を行う事業者が間に入ることが考えられる。このようにカード発行者やサービス提供者が属する事業主体により直接契約を結んだり通信を確立することが難しい。
【００１３】
【課題を解決するための手段】
本願発明の次の主な二つの形態を有する。これら形態の基本思想を、その要点をごく簡潔に要約すると次ぎの通りである。
【００１４】
本願発明の第１の形態は、ＩＣカードの発行者以外の第三者による認証書を用いることである。尚、以下ＩＣカードの発行者以外の第三者による認証書を簡便に代理署名と称する。
【００１５】
本願発明の第２の形態は、ＩＣカードが限定機能付きのセキュリティドメインを有することである。この第２の形態は、前記第１の形態の機能を補足し、より有用なＩＣカード・システムを提供することを可能ならしめるものである。
【００１６】
そして、本願発明の第３の形態は、前記第１と第２の発明思想を合わせて使用することである。こうして、カード発行者が認めた代理者が、カード発行者が認めた条件でアプリケーション搭載を代行することが可能である。
【００１７】
以下に、これらの本願発明の基本思想を軸に、本願発明を説明する。
【００１８】
先ず、本願発明の第１の形態についてである。
【００１９】
第１の形態は、例えば、第２の機関が、少なくとも、ＩＣカード発行に係わる第１の機関を特徴づけ且つサービス提供の為に持ちいる第１の特徴情報、及び当該第２の機関の第２の特殊情報とを、サービス情報提供に係わる第３の機関に提供が可能であり、前記サービス情報提供に係わる第３の機関は、少なくとも、所望のアプリケーション用プログラムと、前記ＩＣカード発行に係わる第１の機関を特徴づけ且つサービス提供の為に持ちいる第１の特徴情報と、当該第２の機関を特徴づけるところの第２の特殊情報と、をＩＣカードに提供が可能なＩＣカード・システムであると言うことが出来る。
【００２０】
この観点は、第１に、わけても、カード発行者―サービス提供者間の契約関係及び運用時の通信の増大と言う前述の難点を解決するためのものである。
【００２１】
このためには、発行者とサービス提供者の間に代理者という概念を作り、カード発行者とサービス提供者が直接通信を確立せずともアプリケーション搭載可能な方式が必要となってくる。具体的には、カード発行者が代理者と事前提携をすることで代理者業務を行うことを認証することで、サービス提供者が直接カード発行者と通信をすることなくアプリケーション搭載が実現可能であり、かつ通常のアプリケーション搭載方式と同程度のセキュリティを保つことが可能な方式が必要である。
【００２２】
本願発明は、以上の要求を満たすＩＣカードのアプリケーションの搭載方式を提供する。
【００２３】
図６は本願発明の方式の骨子を説明する図である。ＩＣカード（１１）はカード発行者（３０２）により発行されている。サービス提供者Ａ（３０３）はカード発行者（３０２）と契約を結んでおり通常のアプリケーション搭載方法によりカードにアプリケーション８０１を発行する。
【００２４】
サービス提供者Ｂ（８０３）は代理者（９０１）と契約を結んでいる。
【００２５】
本願発明の前提は、前述の難点からして、サービス提供者Ｂ（８０３）とカード発行者（３０２）との間の通信を行わないことである。従って、本願発明は、代理者を通して間接的に発行者と通信を確立する手法である。つまり、カード発行者が行っているアプリケーションの許可を代理者に代行させ、サービス提供者Ｂがカードにアプリケーションを搭載するためには代理者とのみ通信を行えば良いという方法である。しかし、代理者によるアプリケーションへの署名（以降、代理署名と呼ぶ）のみでは、次ぎのような難点を有する。即ち、その第１はカードＡが正当性を検証できない点である。第２は、カード発行者の意志に関わらず不特定者がアプリケーションの搭載が可能であるとの難点である。尚、ここで、署名とは、暗号理論における署名であることは言うまでもない。その代表例はデジタル署名である。例えば、こうしたディジタル署名は、署名アルゴリズムと、確認アルゴリズムの２つの要素から成っている。例えば、秘密の署名アルゴリズムを利用して、文書に署名をすることが出来る。その結果の署名は、その後公開されている確認アルゴリズムを用いて確認できる。確認アルゴリズムは、文書と署名とによって、確認アルゴリズムは署名が本物かどうかを判断し、真もしくは偽という答えを返すことが出来る。こうした署名に関する一般的な理論は、例えば、ダグラス・スチンソン著、桜井幸一訳の「暗号理論の基礎」（共立出版、１９９６）の第６章、わけても第２１７頁より第２２０頁、あるいは「ハンドブック オブ アプライド クリスタルグラフィ（Ｈａｎｄｂｏｏｋ ｏｆ Ａｐｐｌｉｅｄ Ｃｒｙｓｔａｌｇｒａｐｈｙ）」（ＣＲＣ Ｐｒｅｓｓ、１９９６）、第４３３頁より第４３４頁に見られる。
【００２６】
こうした難点を回避する為の本願発明の第１の形態の骨子は、次の諸点に要約される。第１は、カード発行者と代理者との間で提携契約を結ぶ際に、カード発行者が代理者に対して代理業務を行うことを認める代理者認定証を渡しておくことである。第２は、代理者がアプリケーション認証する際に、代理署名と代理者認証書を合わせてサービス提供者に渡すことである。こうして本願発明によれば、カードＡ内で代理者認証書がカード発行者による正当なものかを検証することで、不特定者によるアプリケーションの搭載を防ぐことができる。
【００２７】
本願発明の主な第２の形態は、前記第１の形態の機能を補足し、より有用なＩＣカード・システムを提供することを可能ならしめるものである。その形態を要約すると、ＩＣカードが、いわゆる限定機能付きのセキュリティドメインを有することである。
【００２８】
本願発明の第２の形態は、例えば、第２の機関が、少なくとも、ＩＣカード発行に係わる第１の機関を特徴づけ且つサービス提供の為に持ちいる第１の特徴情報、及び当該第２の機関の第２の特殊情報と、アプリケーション用プログラムのＩＣカードへの格納に関する条件を有するプログラムとを、サービス情報提供に係わる第３の機関に提供が可能であり、前記サービス情報提供に係わる第３の機関は、少なくとも、アプリケーション用プログラムと、前記第１の特徴情報と、前記第２の機関を特徴づけるところの第２の特徴情報と、前記アプリケーション用プログラムのＩＣカードへの格納に関する条件を有するプログラムと、前記格納条件を有するプログラムに係わる第３の特徴情報と、をＩＣカードに提供が可能なＩＣカード・システムであると言うことが出来る。
【００２９】
本願発明に係る第１の形態のみでは一度代理者認証書を発行したら、代理者は、それ以降無制限にアプリケーションを搭載できる権限を有する。勿論、提携の契約条件にもよるのだが、カード発行者にとっては、「アプリケーション1個分の搭載許可権限を与えたい」あるいは「有効期限を設定した上での搭載許可権限を与えたい」などの要求は当然発生する。本願発明の第２の形態は、この要求を満たすものである。
【００３０】
セキュリティドメインは、前述のようにカード内でアプリケーションの搭載、削除あるいは管理機能などを実現するアプリケーションもしくはデータを有する領域である。従って、本来、セキュリティドメインは、サービス提供者によって作成される。しかし、本願発明では、カード発行者がこのセキュリティドメインを作成し、これを代理者を通してサービス提供者に渡し、サービス提供者のセキュリティドメインとして機能させる。カード発行者は作成の際、アプリケーション搭載回数や有効期限など提携契約に対応する諸条件をセキュリティドメイン内部に設定し、提携先に送信する。もちろん、このセキュリティドメインは改竄防止策を取っている必要がある。
【００３１】
図６を参酌すれば、限定機能付きセキュリティドメイン（８０５）は、カード発行者（３０２）により作成され、サービス提供者Ｂ（８０３）のセキュリティドメインとしてカードＡ１１内に格納される。サービス提供者Ｂ（８０３）がアプリケーション（８０２）を搭載する場合、サービス提供者Ｂ（８０３）は代理者（９０１）にアプリケーションの搭載の許可を依頼する。代理者（９０１）は、サービス提供者Ｂ（８０３）に代理者認証書と代理署名を合わせて送信する。サービス提供者Ｂ（８０３）はアプリケーション（３７）と代理者認証書と代理署名を合わせてカードＡ（１１）内に送る。カードＡは、限定機能付きセキュリティドメイン内に設定された限定条件に照らし合わせながら、代理者認証書が正しくカード発行者によることを検証する。その結果、カードＡが、代理署名によりアプリケーションの正当性を確認した場合、当該カードＡはアプリケーションを搭載を可能とする。
【００３２】
【発明の実施の形態】
図７は、本発明のＩＣカード（１１）及びＩＣカードアプリケーションの発行システムの構成図である。図７で、符号３０２はカード発行者のサーバであり、符号３０５はカード発行者のデータベースでカード発行者が運用する全てのＩＣカードに関する運用情報である発行管理データを管理する為のものである。同様に符号９０１は代理者のサーバであり、符号９０２は代理者のデータベースで、代理者の搭載の許可を出すＡＰに関する運用管理情報であるＡＰ関連データを管理する。符号３０３はサービス提供者のサーバであり、符号３０６はサービス提供者で自身のアプリケーションの運用情報であるＡＰ関連データを管理する。ＩＣカード（１１）はカード発行者システム内のカード発行処理部（３０８）により発行され、クライアントである利用者（３０１）のもとに配布される。尚、ここでのカードの発行及び配布は、オンライン動作ではなく、通例の意味における発行及び配布である。
【００３３】
また、カード発行処理部（３０８）は代理者システムのＡＰ搭載許可処理部（３１０）と事前提携（３１５）を行い、代理者であることを認める代理認定証のやり取りなどを行う。サービス提供者（３０３）がアプリケーションをカードに搭載する場合、サービス提供者システム内のＡＰ搭載処理部（３１２）が代理者のＡＰ搭載許可処理部（３１０）にＡＰ搭載要求（３１９）を行う。代理者は事業者ポリシーに従い、ＡＰの正当性を確認の上ＡＰ搭載許可を発行する（３１６）。サービス提供者は、受け取ったＡＰ搭載許可とアプリケーションを合わせて外部端末（３０４）を通してＩＣカードへ送信する（３１４）。カード発行者サーバ（３０２）と代理者サーバ（９０１）、代理者サーバ（９０１）とサービス提供者サーバ（３０３）は、各々基本的にネットワーク（３１８、３１９）を通して接続されている。しかし、運用事業者のポリシーによりフロッピーディスクなど情報記録媒体の郵送や、書面の郵送などにより情報のやり取りを実現することもある。このように、本願発明のシステムは、カード発行者と代理者は提携契約を結び、代理者がサービス提供者へのサービス提供許可を代行し、サービス提供者サーバからユーザのＩＣカードへアプリケーションが搭載される仕組みとなっている。
【００３４】
ここで、以下の説明の理解を容易にする為、本願明細書での特徴的な主要用語について説明する。
【００３５】
「代理署名」は、カードの発行者を代理して署名を行うことである。その具体例は署名の対象となる情報に、当該情報を代理者の秘密鍵で暗号化した情報を付与した情報のことである。尚、ここで、前記署名の対象となる情報に代えて、この情報を特徴付ける情報、例えば、そのハッシュ値を用いることも出来る。従って、前記「代理署名」の用語は、この意味をも含むものである。
【００３６】
「署名付＊＊」は、「＊＊」に、「＊＊」を署名者の鍵、例えば秘密鍵で暗号化した情報を付与した情報のことである。尚、ここで、前記署名者の鍵に代えて、この鍵情報を特徴付ける情報、例えば、そのハッシュ値を用いることも出来る。従って、前記「署名付＊＊」の用語は、この意味をも含むものである。
【００３７】
「代理認定書」は、代理者が発行者によって、その代理であることを認定されたことを示す情報である。その具体例は、代理者の公開鍵に、代理者の公開鍵を発行者の秘密鍵で暗号化した情報を付与した情報である。
【００３８】
「アプリケーション認定書」は、アプリケーションをＩＣカードに搭載することを許可する情報である。その具体例は、アプリケーションを特徴付ける特徴情報に、その特徴情報を代理者の秘密鍵で暗号化した情報を付与した情報である。
【００３９】
「セキュリティドメイン」はアプリケーションの搭載、削除、あるいはその他の諸管理を行うプログラムのことである。
【００４０】
「限定機能付きセキュリティドメイン」は、前記のアプリケーションの搭載、削除、あるいはその他の諸管理にある制限を与える条件を付与したプログラムのことである。
【００４１】
尚、本願発明は非対称暗号化機能を有するデータ・システムに関する。
【００４２】
非対称暗号化機能とは、例えば、暗号鍵として公開鍵、秘密鍵を使用し、且つこうした非対称暗号鍵により暗号化されたデータの復号化が可能である機能のことである。
【００４３】
次に、本願発明の係わる代理署名及びアプリケーションの搭載の具体的方法を説明する。
【００４４】
ＩＣカードに対する端末機などは、通例のもので良い。本願発明に係わる各機関は、サーバ、リーダライタなど端末機を有する。本願に係わる各種情報は、このサーバに一旦保持される場合、リーダライタを通してＩＣカードに情報が搭載される場合など各種形態が考えられる。本願発明はこうした動作形態に直接関係するものではない。本願発明はこれらのいずれの場合も適用可能である。
【００４５】
図２９は簡単にカード・システム例の概要を示す図である。ＩＣカード５２の中にはチップ５１があって、リーダライタ５３とデータのやりとりを行う例を示している。リーダライタの中にはコントロールプロッセサ５４やデータベースとなる磁気ディスク５５などが存在する。ＩＣカード５２には、例えば、Ｖｃｃ（供給電源）、ＧＮＤ（グランド）、ＲＳＴ（リセット）、Ｉ／Ｏ（入出力）、及びＣＬＫ（クロック）などの諸端子が示されている。又、図中、（１）はリーダライタ５３からＩＣカード５２に対しての、例えば、ＩＤ（ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ）などの各種問い合わせを示す。（２）はＩＣカードが前述の問い合わせに対する返答を示す。こうした、諸情報の伝達は通例のシステムで十分である。従って、その詳細の説明は省略する。
【００４６】
尚、ＩＣカード内のＩＣチップにおいて、具体的には、前述のアプリケーション、セキュリティドメインなどは、ＯＳ部、メモリ領域に搭載される。一般に、メモリとしては、ＲＡＭ（Ｒａｎｄｕｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュ・メモリ（Ｆｌａｓｈ Ｍｅｍｏｒｙ）、ＦＲＡＭ（Ｔｅｒｒｏｍａｇｎｅｔｉｃ Ｒａｎｄｕｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＮ（Ｅｌｅｃｔｒｉｃａｌ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）あるいはＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などが用いられる。従って、本願明細書において、「セキュリティドメインを用いて」あるいは「セキュリティドメインを経由して」とは、ＯＳ部が、そのセキュリティドメインなるプログラムを取り出し、このプログラムによって、所定の情報たるデ−タの諸管理状態を確認し、必要があれば、所定の処理を行うことを意味している。ここで、デ−タの諸管理の項目とは、例えば、サービス情報の搭載容量、搭載回数、搭載するサービス情報の個数、サービス情報の搭載可能な有効期間などである。
【００４７】
ＯＳ部などは通例のもので十分である。ＩＣチップ内の信号処理は、通例のＩＣカードのそれをもちいて十分である。
【００４８】
又、ＩＣカードには、接触型ＩＣカード、非接触型ＩＣカードなどがあるが、本願発明はこうしたＩＣカードの構成自体によらず適用することが出来る。
【００４９】
図８を参酌して、代理署名について説明する。カードＡ（１１）はマルチアプリケーションのダイナミックローディングに対応するＯＳが搭載されたＩＣカードであり、カード発行者（３０２）により発行済みである。また、サービス提供者Ｂ（８０３）はＩＣカードにアプリケーションを搭載しサービスを運用する事業主体者であり、代理者（９０１）とサービス提供に関する契約を結んでいる。通常であれば、サービス提供者Ｂ（８０３）がカードＡ（１１）にアプリケーションを搭載するためには、カード発行者（３０２）とサービス提供に関する契約を直接結び、通信を確立した上で許可を受けなければならない。しかし、本願発明のシステムは、カード発行者（３０２）と代理者（９０１）の間で提携契約を結び、代理者（９０１）がカード発行者（３０２）の代理としてアプリケーション搭載許可を行う方法である。提携契約時に、カード発行者（３０２）は代理者（９０１）に代行業務を行うことを認める代理認定証を渡し、以降アプリケーション搭載許可は代理者（９０１）が行う。サービス提供者Ｂ（８０３）はアプリケーション搭載時に、代理者からアプリケーション搭載許可を受け、カードＡにアプリケーションを搭載する。
【００５０】
上述した本願発明の第１の形態のシステムが、具体的にどのように行われるか、図９を参酌して説明する。即ち、代理署名を行う際の処理シーケンスを説明する。
【００５１】
＜代理署名を行う際の代表的な基本処理シーケンスの例＞
カード発行者（３０２）と代理者（９０１）の間では、お互いの運用ポリシーに基づき提携契約を結ばれている。提携契約に合意した場合、代理者はカード発行者に自らの非対称鍵公開鍵を送付し、代理者認証書を要求する（ステップ１２００１）。
【００５２】
カード発行者は受け取った公開鍵に対して、自らの非対称鍵秘密鍵で署名を行った代理認定証を代理者に送付する（ステップ１２００２）。
【００５３】
次に、カードＡ（１１）へのサービス提供者Ｂ（８０３）によるアプリケーション搭載する際は、まず、サービス提供者Ｂが代理者にカードＡに対するアプリケーション搭載許可要求を行う（ステップ１２００３）。尚、アプリケーション搭載許可要求の具体例は、例えば、搭載するアプリケーションのハッシュ値を送付することである。ハッシュ値とは、当該アプリケーションに対応した固有のデータ値である。アプリケーション搭載許可要求を行う場合、必ずしもハッシュ値でなくとも良いが、ハッシュ値が最も便利であり、多く用いられる。
【００５４】
代理者は、サービス提供者Ｂから事前に申請されているアプリケーションの内容を照会し、その正当性を確認する。前述のハッシュ値を用いる場合、この正当性の確認は、例えば、サービス提供者Ｂより送付されたハッシュ値と、当該ＩＣカードの内部で発生させた当該アプリケーションに対応したハッシュ値とを比較することによって行われる。こうしたステップの詳細は後述される。また、カード発行者よりホットリスト（不正カード情報あるいはブラックリスト）などカードに関する情報が提供されていれば、それをも合わせて確認される。
【００５５】
代理者は受け取ったアプリケーションのハッシュ値に非対称鍵秘密鍵で代理署名し、代理認定証と合わせてサービス提供者Ｂに送付する（ステップ１２００４）。なお、この秘密鍵は提携契約時にカード発行者に送付した非対称公開鍵に対応するものである。
【００５６】
サービス提供者は受け取った代理署名付きアプリケーションハッシュ値、代理認定証、アプリケーション本体を合わせてカードに送信する（ステップ１２００５）。
【００５７】
カード内には、カード発行時に、カード発行者の公開鍵が格納されているので、それを用いて代理認定証の署名検証を行い正当性を確認する。
【００５８】
これは、代理者の公開鍵に署名を付与したものなので、署名が正しいことを確認した上で、この公開鍵を用いてアプリケーションのハッシュ値を復号化する。それと受け取ったアプリケーションから作成したハッシュ値を比較し同一であれば、アプリケーションをロード・インストールし、アプリケーション搭載完了となる。
【００５９】
このように本願発明の第１の形態の手順は、アプリケーションの正当性を代理者が保証し、代理者の正当性をカード発行者が保証することで、間接的にカード発行者の保証のもとにアプリケーションを搭載する仕組みとなっている。図６に例示したように、カード発行者とその他プレーヤの間は、提携契約時、代理認定証の送付のステップがあるが、以降オフラインとなっており、通信を確立する必要がない。ただし、提携契約内容によっては、不正カード情報であるホットリストや各種運用に必要な情報をカード発行者間でやり取りする場合もあるが、その場合でも、カード発行者とサービス提供者との間に通信を直接確立する必要はない。
【００６０】
以上説明した代理署名を行う際の基本処理シーケンスに基づく動作の更なる動作例の詳細を、図１０から図１４を用いて説明する。即ち、各図は、各々カード、カード発行者、代理者、サービス提供者の各プレーヤ毎の動作フローチャートである。
【００６１】
＜ＩＣカード：ＩＣカードでのアプリケーション搭載処理の例＞
図１０は、代理署名を用いたアプリケーション搭載処理を行うＩＣカード側での動作のフローチャートである。
【００６２】
カードがアプリケーション搭載処理を開始する（ステップ１３００１）。
【００６３】
ＩＣカードは、サービス提供者より、代理認定証と代理者が署名したアプリケーション認証書とアプリケーションを受信する（ステップ１３００２）。このステップは図９のステップ１２００５に対応する。
【００６４】
代理認定証はカード発行者により署名されている。一方、この代理認定証に対応する鍵がＩＣカード内に格納されており、ＩＣカードは、それを使用して前記の代理認定証を検証し、代理者の鍵を復号化する（ステップ１３００３）。
【００６５】
復号化した代理者の鍵を用いて、代理者が署名したアプリケーション認証書の検証を行い、アプリケーションのハッシュ値を取り出す（ステップ１３００４）。
【００６６】
また、ＩＣカードは、送信されたアプリケーションのハッシュ値をカード内で計算し、さきほど復号化したハッシュ値と同一かどうかを確認する(ステップ１３００５)。
【００６７】
これらが同一であれば、ＩＣカードは、カード発行者が認証した正当なアプリケーションだと認め、これをインストールする（ステップ１３００６）。
【００６８】
一方、これらが同一でない場合は、不正なアプリケーションである可能性があるのでインストール処理を中止し、その旨をカード外にエラーメッセージで伝える（ステップ１３００７）。
【００６９】
＜カード発行者：カード発行者が代理署名を用いた事前提携処理を行う処理例＞図１１は、カード発行者が代理署名を用いた事前提携処理を行う場合のフローチャートである。このステップは図９における、ステップ１２００１及び１２００２に対応する。
【００７０】
カード発行者は、代理者を認める事前提携処理をはじめる。
【００７１】
カード発行者は、代理認定証を作成するため、代理者から公開鍵を受け取る（ステップ１４００２）。
【００７２】
カード発行者は、ＩＣカード内に格納してある鍵と、これに対応する鍵でこの公開鍵に署名を行い、代理者に戻す（ステップ１４００３）。 以上が、カード発行者―代理者間の事前提携フローである。
【００７３】
図１２は代理署名を用いた、代理者の事前提携処理手順を示すフローチャートである。代理者はカード発行者の代行業務を行うために事前提携処理を行う。まずカード発行者に代理者の公開鍵を送信し（ステップ１５００２）、カード発行者の署名が付与された代理認定証を受け取る（ステップ１５００３）。
【００７４】
＜代理者：代理署名を用いた、アプリケーション搭載処理の例＞
図１３は代理署名を用いた、アプリケーション搭載処理手順を示すフローチャートである。
【００７５】
代理者は、サービス提供者からのアプリケーション搭載要求を受領する（ステップ１６００２）。
【００７６】
代理者は、事前に登録されていたアプリケーションの内容やサービス提供者の正当性を確認し、アプリケーション搭載を許可できるかどうかを判断する（ステップ１６００３）。
【００７７】
搭載を許可する場合、代理者は、アプリケーション認証書をサービス提供者に送り返す（ステップ１６００４）。このアプリケーション認証書は、サービス提供者から送られてきたアプリケーションの特徴を示すデータを、代理者が鍵で暗号化したデータとカード発行者から事前提携時に受け取っている代理認定証を合わせたものである。尚、前記アプリケーションの特徴を示すデータは、例えば、前述のアプリケーションのハッシュ値などである。
【００７８】
搭載不可の場合は、代理者は、その旨をサービス提供者に伝える（ステップ１６００５）。
【００７９】
＜サービス提供者：サービス提供者のアプリケーション搭載処理の例＞
図１４は代理署名を用いた、サービス提供者のアプリケーション搭載処理手順を示すフローチャートである。
【００８０】
サービス提供者は、代理者に対して、アプリケーションの特徴を示すデータ、例えばハッシュ値などを送付して搭載許可を要求する（ステップ１７００２）。
【００８１】
サービス提供者は、代理者からアプリケーション認証書を受け取り（ステップ１７００３）、アプリケーションと合わせてＩＣカードに送信する（ステップ１７００４）。
【００８２】
以上が、代理署名方式を利用してＩＣカードにアプリケーションを搭載する場合の処理手順の例である。
【００８３】
次に、前記本願発明の第１の形態の機能を補足する第２の形態の具体例を説明する。前述したように、その形態を要約すると、ＩＣカードが、いわゆる限定機能付きのセキュリティドメインを有することである。
【００８４】
上述のように、代理認定証を渡すことで問題点は解決したが新たに起こる問題として、一度代理認定証を発行したら、代理者はそれ以降無制限にアプリケーションを搭載できる権限を持つということがある。ＩＣカード上のアプリケーション搭載領域は無限にあるわけではなく、また提携契約などは期限を設定して結ばれることが通常であるため、カード発行者にとって「アプリケーション1個分の搭載許可権限を与えたい」あるいは「有効期限を設定した上での搭載許可権限を与えたい」などの要求を満たす仕組みが望まれる。
【００８５】
そこで、本願の第２の形態が提案された。図１５は「限定機能付きセキュリティドメイン」を用いる場合の全体構成図である。
【００８６】
図１５において、ＩＣカード（１１）、カード発行者（３０２）、代理者（９０１）、サービス提供者Ｂ（８０３）のプレーヤの役割と関係は図１１と同様である。カード発行者（３０２）と代理者（９０１）の間で提携契約を結び、代理者（９０１）がカード発行者（３０２）の代理としてアプリケーション搭載許可を行う方式であることは図１１と同じであるが、異なる点としてアプリケーションを搭載する前に、セキュリティドメインを搭載する必要がある点である。以下の説明では、図９の例と異なる点を主に説明し、同じ諸点は説明を省略する。
【００８７】
セキュリティドメインとはカード内で、アプリケーション搭載、削除、あるいは管理を行うものである。こうした管理を可能ならしめる前提条件としては、（１）セキュリティドメイン内部に非対称鍵暗号鍵を格納することが可能であることと、（２）アプリケーションはセキュリティドメインを通してカードに格納されることが挙げられる。セキュリティドメインの具体的な形態はアプリケーションの場合もあり、ライブラリの場合もあり、データの場合もある。また、従来はアプリケーション搭載を行う事業者が、セキュリティドメインを作成していた。しかし、本願発明では、カード発行者が作成する。提携契約時にカード発行者（３０２）は代理者（９０１）に代理者として認める代理者認証書の他に限定機能付きセキュリティドメインを渡す。カードＡにアプリケーションを搭載希望するサービス提供者ＢはまずカードＡにセキュリティドメインを搭載するため代理者のもとにある限定機能付きセキュリティドメインを受け取りカード内に設定する。その後アプリケーション搭載許可を代理者から受け取りアプリケーションを前記セキュリティドメインを通してカード内に格納する。
【００８８】
図１６は、代理署名と限定付きセキュリティドメインの機能を合わせて用い、提携を実現する際の処理シーケンスを示す図である。
【００８９】
カード発行者（３０２）と代理者（９０１）の間でお互いの運用ポリシーに基づき提携契約を結ばれている。提携契約に合意した場合、代理者はカード発行者に自らの非対称鍵公開鍵を送付し代理者認証書を要求する（ステップ１９００１）。
【００９０】
カード発行者（３０２）は受け取った公開鍵に対して、自らの非対称鍵秘密鍵で署名を行い、代理者認証書を代理者（９０１）に送付する（ステップ１９００２）。
【００９１】
次にセキュリティドメインに格納する鍵に関連するやり取りを行う。セキュリティドメインには、運用時にはカード発行者の鍵と代理者の鍵が格納される。まず、代理者（９０１）はセキュリティドメイン用の非対称鍵のペアを作成し、その秘密鍵をカード発行者（３０２）に送付する（ステップ１９００３）。
【００９２】
但し、秘密鍵の内容はカード発行者を含め他者には知られてはセキュリティ上問題があるので、秘密鍵をブラインド化し送付する。カード発行者も同様にセキュリティドメイン用の非対称鍵のペアを作成し、この秘密鍵を用いて、受け取った代理者のブラインド化した秘密鍵に署名を行い、代理者に戻す（ステップ１９００４）。
【００９３】
これを受け取った代理者はブラインドを解除する。非対称鍵におけるブラインド署名の方式は既に知られている技術である。この方式自体は、例えばＲＳＡブラインド署名などが知られている。それは、例えば、岡本龍明、山本博資著『シリーズ／情報科学の数学 現代暗号』（産業図書株式会社発行、１９９７）に見られる。
【００９４】
その後、カード発行者（３０２）は、提携契約に応じた内容の限定条件を設定したセキュリティドメインを作成し、自らのセキュリティドメイン用公開鍵をその内部に格納する。もしくは、あらかじめ提携契約の内容に応じて作成してあったセキュリティドメインにセキュリティドメイン用公開鍵をセットする。このセキュリティドメインにカード発行者の秘密鍵で署名を行い、代理者に限定機能付きセキュリティドメインとして送付する（ステップ１９００５）。こうして、事前提携時のやり取りは完了する。
【００９５】
ここで一つ注意すべき点としては、「カード発行者の鍵」と「代理者の鍵」というそれぞれの非対称鍵の他に、「カード発行者のセキュリティドメイン用の鍵」と「代理者のセキュリティドメイン用の鍵」が存在することが挙げられる。
【００９６】
次にアプリケーション搭載時のやり取りに関して説明する。アプリケーションはセキュリティドメインがカード内に設定されていることが前提なので、最初にセキュリティドメインの搭載方法を説明する。
【００９７】
＜セキュリティドメインの搭載方法の例＞
カードＡ（１１）へサービス提供者Ｂ（８０３）のセキュリティドメインを搭載する場合、サービス提供者Ｂのセキュリティドメインとは、事前提携時にカード発行者（３０２）から代理者（９０１）へと送付された限定機能付きセキュリティドメインのことである。代理者（９０１）は、サービス提供者からのセキュリティドメイン搭載許可要求を受ける（ステップ１９００６）。
【００９８】
限定機能付きセキュリティドメインをサービス提供者Ｂに送付する（ステップ１９００７）。ただし、あらかじめセキュリティドメインを配布しておくことも可能なので、ステップ１９００６とステップ１９００７に関しては、順序が逆の場合もあり得る。代理者はステップ１９００４において受け取りブラインド解除してあった署名付き秘密鍵とそれに対応する公開鍵をセキュリティドメイン用鍵ペアとしてサービス提供者Ｂに送付する（ステップ１９００８）。
【００９９】
このセキュリティドメイン用公開鍵は暗号化や署名はされておらず、サービス提供者Ｂが該セキュリティドメインと通信する上での署名検証や、セキュアな通信確保などに使用する。次にサービス提供者Ｂは限定機能付きセキュリティドメインをカードに格納する（ステップ１９００９）。こうして、ＩＣカードは、このセキュリティドメインの正当性を検証する。限定付きセキュリティドメインは、ステップ１９００５についての記述にもあるように、カード発行者の鍵の署名が付与されており、カード内にはカード発行時にカード発行者の公開鍵が搭載されている。従って、ＩＣカードは、この鍵を用いて当該セキュリティドメインの正当性検証が可能である。
【０１００】
正当性が確認できた場合、サービス提供者Ｂよりセキュリティドメイン用秘密鍵を受け取り（ステップ１９０１０）、この鍵の正当性を検証する。ステップ１９００４についての記述にもあるように、このセキュリティドメイン用鍵とは、代理者のセキュリティドメイン用秘密鍵にカード発行者のセキュリティドメイン用秘密鍵で署名を行っているものである。カード内に設定された限定機能付きセキュリティドメインにはカード発行者のセキュリティドメイン用公開鍵が設定されているので、内部で署名の正当性を検証可能である。セキュリティドメイン用鍵の正当性が確認できた場合、鍵は復号化され代理者のセキュリティドメイン用秘密鍵が限定機能付きセキュリティドメイン内部に設定される。
【０１０１】
ここまでで、限定付きセキュリティドメインは、ＩＣカードに格納され、鍵も設定されたので機能し始める。当該セキュリティドメイン内部には
（ａ）カード発行者が該セキュリティドメイン用に作成した公開鍵と
（ｂ）代理者が該セキュリティドメイン用に作成した秘密鍵
とが格納されている。前記（ａ）の項目に対応する秘密鍵はカード発行者が保持している。また、前記（ｂ）の項目に対応する公開鍵はサービス提供者Ｂに送付されている。つまり、カード発行者によって作成された限定機能付きセキュリティドメインは２つの主体者の鍵を保持し、カードＡ内で機能するのである。
【０１０２】
次にカードＡ（１１）へサービス提供者Ｂ（８０３）によるアプリケーション搭載時の説明を行う。
【０１０３】
まず、サービス提供者Ｂが代理者にカードＡに対するアプリケーション搭載許可要求を行う（ステップ１９０１１）。アプリケーション搭載許可要求は、具体的には、搭載するアプリケーションのハッシュ値を送付することである。
【０１０４】
代理者（９０１）は、サービス提供者（８０３）と事前に申請されているアプリケーションの内容を照会しその正当性を確認する。また、カード発行者よりホットリスト（不正カード情報・ブラックリスト）などカードＡに関する情報が提供されていればそれを確認する。代理者は受け取ったアプリケーションのハッシュ値に自らの秘密鍵で代理署名し、ステップ１９００２で受け取った代理者認証書と合わせてサービス提供者Ｂに送付する（ステップ１９０１２）。なお、この秘密鍵は提携契約時にカード発行者に送付した非対称公開鍵に対応するものである。
【０１０５】
サービス提供者Ｂはステップ１９００８で取得しているセキュリティドメイン用公開鍵でアプリケーションを暗号化しておき、アプリケーション搭載許可要求の回答として送付されてくる代理署名付きアプリケーションハッシュ値、代理者認証書を、この暗号化したアプリケーション本体を合わせてカードに送信する（ステップ１９０１２）。
【０１０６】
カードＡは、以上の情報を限定機能付きセキュリティドメインが受け取り、まず代理者認証書の署名検証を行う。代理者認証書は代理者の公開鍵に対して、カード発行者のセキュリティドメイン用秘密鍵で署名されたもので、限定機能付きセキュリティドメイン内部には対応する公開鍵が保持されているので、これを用いて署名検証し、即ち、復号化する。
【０１０７】
ここで、復合化が可能ということは、署名が正しいことを示している。アプリケーションのハッシュ値に代理署名した鍵は、代理者の秘密鍵なので、復号化した代理者の公開鍵を用いてハッシュ値を復号化して取り出す。また一方アプリケーションには代理者のセキュリティドメイン用公開鍵で暗号化されているが、限定機能付きセキュリティドメイン内部にはこれに対応する秘密鍵が格納されているため、これを用いてアプリケーションを復号化し、ハッシュ値をとる。これが先程のハッシュ値と同一であるかを照会し、同一であれば正当なアプリケーションとしてカードＡ内にロード・インストールし、アプリケーション搭載完了となる（１９０１３）。
【０１０８】
以上の手順は、アプリケーションの正当性を代理者（９０１）が保証し、代理者の正当性をカード発行者（３０２）が保証することで、間接的にカード発行者（３０２）の保証のもとにアプリケーションを搭載する仕組みとなっている。先に、セキュリティドメインに格納されている２つの鍵を、（ａ）カード発行者作成鍵、（ｂ）代理者作成鍵と記した。
【０１０９】
（ａ）の鍵は代理者認証書の検証を行い、一方（ｂ）の鍵はアプリケーションの検証を行っている。
【０１１０】
代理署名のみを使用した仕組みとの違いとしては、次ぎの事項が挙げられる。（１）第１は、カード内で正当性を検証する鍵はセキュリティドメイン内部に保持されていることである。
【０１１１】
（２）第２は、上記の鍵はあらかじめ該セキュリティドメイン用にカード発行者と代理者がそれぞれ作成したものであることである。
【０１１２】
（３）第３は、アプリケーション搭載・削除・管理や上記鍵の使用は該セキュリティドメイン、もしくはセキュリティドメイン情報を用いたカードＯＳが行うことである。
【０１１３】
前述したように、アプリケーション搭載、削除及び管理は、本願発明における限定機能付きセキュリティドメインによりコントロールされている。そして、それをカード発行者が、提携契約条件に従って作成していることから、無制限なアプリケーション搭載は避けることが可能である。代理者が不正に代理署名を行ったとしても、本願発明によれば、次ぎの方策が可能である。即ち、提携契約時に、「アプリケーション１つのみ搭載可能」、「ある日時にまで搭載期限」、「ある容量を超えて搭載不可能」などの適当な条件を付け、その限定機能を付けてセキュリティドメインを、作成すれば良い。カード発行者とその他プレーヤとの間は、提携契約時以降オフラインとなっていて、カード発行者の意志に反してカードにアプリケーションが送信されてきても、カード内の当該セキュリティドメインが搭載を拒否することになる。
【０１１４】
以上説明した限定機能付きセキュリティドメインを用いる際の基本処理シーケンスに基づく動作の更なる動作例の詳細を、図１７から図２４を用いて説明する。即ち、各図は、各々ＩＣカード、カード発行者、代理者、サービス提供者の各プレーヤ毎の動作フローチャートである。本図面で“ＳＤ”記載されているのは本願発明で提案する限定機能付きセキュリティドメインのことであり図面の説明においてもＳＤと表す。
【０１１５】
＜ＩＣカード：ＳＤ搭載処理の例＞
図１７は、本発明方式を利用したＳＤ搭載処理を行うカードのフローチャートである。この処理は、図１９の１９００９及び１９０１０の両ステップに対応する。
【０１１６】
ＩＣカードはサービス提供者からＳＤを受信する（ステップ２０００２）。
【０１１７】
ＳＤは発行者の鍵により署名されているので、カード内の対応する鍵を用いて復号化する（ステップ２０００３）。
【０１１８】
このＳＤの署名が正しければ、ＳＤをカード内にインストールし（ステップ２００５）、正しくない場合はＳＤのインストールを中止しカード外にその旨を伝える（ステップ２００１０）。
【０１１９】
ＳＤをインストールした後は、ＳＤ内に設定する鍵を受信する（ステップ２０００６）。これはカード発行者のＳＤ用鍵で署名されているが、対応する鍵がＳＤ作成時に内部に設定されているので、これを用いて署名を復号化する（ステップ２０００７）。
【０１２０】
正しい鍵かどうかを検証し(ステップ２０００８)、正しければＳＤ内に鍵を設定し(ステップ２０００９)、不正であれば、ＳＤへの設定を中止しカード外にその旨を伝える（ステップ２００１１）。
【０１２１】
＜ＩＣカード：アプリケーション搭載処理の例＞
図１８は、本願発明方式を利用したアプリケーション搭載処理を行うカードのフローチャートである。この処理は、図１６の１９０１３のステップに対応する。
【０１２２】
カードはアプリケーション搭載処理を開始すると（ステップ２１００１）、代理認定証と代理者が署名したアプリケーション認証書とサービス提供者が持つＳＤ用鍵で暗号化したアプリケーションをサービス提供者より受信する（ステップ２１００２）。
【０１２３】
代理認定証はカード発行者により署名されており対応する鍵がＳＤ内に格納されているので、それを使用して代理認定証を検証し、代理者の鍵を復号化する（ステップ２１００３）。
【０１２４】
復号化した代理者の鍵を用いて、代理者が署名したアプリケーション認証書の検証を行い、アプリケーションのハッシュ値を取り出す（ステップ２１００４）。
【０１２５】
アプリケーションはサービス提供者により暗号化されているが、対応する鍵がＳＤ内にあるのでそれを用いてアプリケーションを復号化し取り出し（ステップ２１００５）、そのハッシュ値をカード内で計算し、さきほど復号化したハッシュ値と同一かどうかを確認する(ステップ２１００６)。
【０１２６】
もし、同一であればカード発行者が認証した正当なアプリケーションだと認めインストールする（ステップ２１００７）。
【０１２７】
同一でない場合は、不正なアプリケーションである可能性があるのでインストール処理を中止し、その旨をカード外にエラーメッセージで伝える（ステップ２１００８）。
【０１２８】
＜カード発行者：事前提携処理の例＞
図１９は、カード発行者が、本発明を利用した事前提携処理を行う場合のフローチャートである。この処理は、図１６のステップ１９００１より１９００５にかけてのステップである。
【０１２９】
カード発行者は、代理者を認める事前提携処理をはじめると、代理認定証を作成するため代理者から公開鍵を受け取る（ステップ２２００２）。
【０１３０】
発行者は、カード内に格納してある鍵と対応する鍵で、この公開鍵に署名を行い、代理者に戻す（ステップ２２００３）。
【０１３１】
また、ＳＤ格納用の鍵を代理者から受け取り（ステップ２２００４）、ＳＤ作成時に内部に設定してある鍵と対応する鍵で暗号化し代理者に送信する（ステップ２２００５）。ＳＤを発行者の鍵で署名し代理者に送信する（ステップ２２００６）。
【０１３２】
＜代理者：事前提携処理の例＞
図２０は本発明を利用した代理者の事前提携処理手順を示すフローチャートである。
【０１３３】
まずカード発行者に代理者の公開鍵を送信し（ステップ２３００２）、カード発行者の署名が付与された代理認定証を受け取る（ステップ２３００３）。
【０１３４】
ＳＤ搭載用の鍵を生成し、秘密鍵にブラインド化処理を行いカード発行者に送信する（ステップ２３００４）。
【０１３５】
発行者の署名が付与された上記鍵を受け取りブラインド化解除処理を行う（ステップ２３００５）。
【０１３６】
発行者の鍵を内部に含むＳＤを発行者より受け取る（ステップ２３００６）。このＳＤはカード発行者の鍵により署名が付与されている。
【０１３７】
＜代理者：ＳＤ搭載要求受付け処理の例＞
図２１は本発明を利用した代理者のＳＤ搭載要求受付け処理手順を示すフローチャートである。この処理は、図１９のステップ１９００６より１９００８のステップに対応する。
【０１３８】
サービス提供者からのＳＤ搭載要求を受信すると（ステップ２４００２）、発行者から受け取ってある署名付きＳＤをそのままサービス提供者に送信する（ステップ２４００３）。
【０１３９】
また次に、あらかじめ作成してあったＳＤ用鍵ペアをサービス提供者に送信する（ステップ２４００４）。このＳＤ用秘密鍵は事前提携処理において発行者に署名を付与されているものである。
【０１４０】
＜代理者：アプリケーション搭載要求受付け処理の例＞
図２２は本発明を利用した代理者のアプリケーション搭載要求受付け処理手順を示すフローチャートである。
【０１４１】
サービス提供者からのアプリケーション搭載要求を受領すると（ステップ２５００２）、事前に登録されていたアプリケーションの内容やサービス提供者の正当性を確認し、アプリケーション搭載を許可できるかどうかを判断する（ステップ２５００３）。
【０１４２】
搭載を許可する場合、サービス提供者から送られてきたアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを代理者が鍵で暗号化したデータとカード発行者から事前提携時に受け取っている代理認定証を合わせてアプリケーション認証書として、サービス提供者に送り返す（ステップ２５００４）。搭載不可の場合は、その旨をサービス提供者に伝える（ステップ２５００５）。
【０１４３】
＜サービス提供者：ＳＤ搭載処理の例＞
図２３は本発明を利用したサービス提供者のＳＤ搭載処理手順を示すフローチャートである。
【０１４４】
サービス提供者は、ＳＤ搭載を代理者に要求し（ステップ２６００２）、発行者の署名が付与されているＳＤを受け取り（ステップ２６００３）、カードに送信する（ステップ２６００４）。
【０１４５】
カードへのＳＤ設定ができたら、代理者からＳＤ用鍵ペアを受け取る（ステップ２６００５）。
【０１４６】
カード発行者の署名が付与されているＳＤ用秘密鍵をカード内のＳＤに送信し設定する（ステップ２６００６）。
【０１４７】
＜サービス提供者：アプリケーション搭載処理の例＞
図２４は、本発明を利用したサービス提供者のアプリケーション搭載処理手順を示すフローチャートである。
【０１４８】
サービス提供者は、代理者に対してアプリケーションのハッシュ値などを送付して搭載許可を要求し（ステップ２７００２）、代理者からアプリケーション認証書を受け取る（ステップ２７００３）。
【０１４９】
アプリケーションをＳＤに設定した鍵と対応する鍵で暗号化し、アプリケーション認証書と合わせてカードに送信する（ステップ２７００４）。
【０１５０】
以上が、本願発明のアプリケーション搭載方式に従いＩＣカードにアプリケーションを搭載する場合の処理手順である。
【０１５１】
次に、本願発明を用いて実現可能なＩＣカードの各種利用形態や運用の諸形態について説明する。
【０１５２】
図９において、本発明における提案方式では９０１の代理者が発行者（３０２）の代行業務を行うが、この代行業務を３０２とは別の発行者が行えば、カードＡ（１１）には発行者Ａ（３０２）が契約したサービス提供者だけでなく、発行者（９０１）が契約したサービス提供者のアプリケーションをも搭載することが可能となる。つまり既存の発行者―サービス提供者の仕組みを組み合わせることで本願発明を利用することが可能である。
【０１５３】
また、発行者間でお互いがお互いの代理者であれば、双方のカードにどちらのサービス提供者のアプリケーションが搭載可能となる。本発明方式を利用することで、既存カード運用管理システム間の相互運用が可能となる。
【０１５４】
次に本願発明のカードシステムのいくつかの具体的な応用例について説明する。
【０１５５】
第１の例はテナント業務である。図２５を用いて、このテナント業務と言う本願発明の応用について説明する。本願明細書におけるテナント業務とは、ＩＣカード上の部分領域を、カード発行者以外のテナントビジネス事業者に貸与する、即ち、テナント運用する業務のことを言う。
【０１５６】
図２５は、ＩＣカード上の部分領域を運用する概念を示した図である。
【０１５７】
この例では、本願発明に係る代理署名及び限定機能付セキュリティドメインとを用いて、ＩＣカードに提携業務の関するアプリケーション搭載を行う。
【０１５８】
図２５を参酌して本例を説明する。カード発行者（２８０１）は、ＩＣカード（１１）を発行し、ＩＣカードに係わる責任を全て負う事業者である。カード発行者（２８０１）は、サービス提供者（２８０２）やサービス提供者（２８０３）と契約を結び、ＩＣカード（１１）上へ、各々のアプリケーション搭載を許可する。更に、本例では、テナントビジネス事業者（２８０４）がテナントを希望する事業者（２８０５）に、
そのアプリケーションの搭載について認証を与える。こうして、テナントを希望する事業者（２８０５）は、前記ＩＣカード（１１）の提携に係わるアプリケーション領域にアプリケーションを搭載する。ここで、テナントを希望する事業者は、これまでの説明におけるサービス提供者である。又、テナントをビジネスとして行おうとする事業者は、これまでの説明における代理者である。
【０１５９】
ＩＣカード（１１）には、マルチアプリケーション搭載を可能とし、且つ、ダイナミックローディング可能であるカードＯＳ（２８１０）が搭載されており、カード上の機能を実行する。セキュリティドメインはカードＯＳ上に設定されており、２８１１はサービス提供者（２８０２）の、２８１２はサービス提供者（２８０３）のそれぞれセキュリティドメインである。
【０１６０】
サービス提供者（２８０２）はセキュリティドメイン（２８１１）を通して自らのアプリケーション（２８１４、２８１５）を搭載する。同様にサービス提供者（２８０３）はセキュリティドメイン（２８１２）を通して自らのアプリケーション（２８１６、２８１７）を搭載する。ここで、代理者（２８０４）と提携契約を結んでいるサービス提供者（２８０５）がアプリケーションをＩＣカード（１１）に搭載する場合は、限定機能付きセキュリティドメイン（２８１３）を通してアプリケーション（２８１８、２８１９）を搭載する構成となっている。このセキュリティドメイン（２８１３）はある限定機能を付与されており、自らが搭載したアプリケーションを管理しているので、図中斜線部分の領域を考えると、セキュリティドメインにより管理されている領域であるといえる。
【０１６１】
搭載許可は代理者（２８０４）が行うので、この搭載領域は、カード発行者（２８０１）より借りうけて、サービス提供者（２８０５）などにサービス提供の場を貸し出している構図となっている。これをビルの所有者からフロアを借り受けて店子を募集するテナントビジネス事業者に対応させると、新しくＩＣカード上の領域を、テナントして運用するＩＣカードの運用形態が考えられる。その場合、代理者（２８０４）は、
ＩＣカードを所有するカード発行者（２８０１）からＩＣカード上のある領域を借り受け、その領域上に、サービスを提供するサービス提供者（２８０５）と契約する業務を行う仲介事業者としての機能があれば良い。
【０１６２】
以上、本例はＩＣカードの一部の所定領域を、テナントビジネス事業者にその利用を貸与する利用形態である。その具体的なアプリケーションの搭載に関する代理者、サービス提供者の動作については、これまで説明してきた本願発明の一般的な運用と同様である。
【０１６３】
また、図２６ではカード発行者（２９０１）が契約関係にあるサービス提供者に限定機能付きセキュリティドメインを対応させた場合の利用形態について説明する。図２５の例との違いは、カード発行者とサービス提供者（２９０５）との間に代理者（２８０４）をおかず、カード発行者（２９０１）が、直接契約しているサービス提供者（２９０５）であることである。その他の点は前述の例と同様である。
【０１６４】
この利用形態の利点は、アプリケーション搭載のオフライン認証におけるセキュリティを高くする点である。サービス提供者がアプリケーションを搭載する際に、カード発行者へ認証を要求するのが従来一般的であることは、既に述べた。この場合、要求方法として、ネットワークなどを使用して通信を確立しオンラインで認証してもらう場合と、あらかじめ許可証を大量に発行してもらうオフライン認証がある。オフライン認証の場合、カード発行者のＩＣカードへのコントロールが弱くなる点が問題となっている。しかし、カード上の限定機能付きセキュリティドメインに制限を設定しておくことで、この問題は、コントロール可能となる。また、契約しているサービス提供者間で差異をつけることが可能となり、事業者の信頼度に応じた契約締結ができる。
【０１６５】
次に、ＩＣカードにおけるバーチャルカードという本願発明のＩＣカードの応用を提案する。
【０１６６】
図２７は、バーチャルカードの概念を説明する図である。バーチャルカ−ドとは、このカードを統括する第３者の認証の下に、複数のカード発行者によるカードの機能に応ずる各々のアプリケションを、一つのカードの所定のアプリケーション領域に搭載したカードの用い方である。従って、一つのカードによって、あたかも複数のカードを持っているかのようにカードを運用することが出来る。
【０１６７】
図２７において、カードＡ（３００５）、カードＢ（３００６）、カードＣ（３００７）は、個別のＩＣカードであり、それぞれのカード発行者は、第３者（３００１）と提携契約を結んでいる。以下、この第３者（３００１）を、便宜上バーチャルカード発行者と呼ぶ。バーチャルカード発行者（３００１）は、カードＡ上にアプリケーション搭載領域を借り受けているため、バーチャルカード発行者（３００１）と契約の有るサービス提供者（３００２、３００３、３００４）は搭載条件さえクリアすれば、カードＡ上にアプリケーション搭載可能である。バーチャルカード発行者（３００１）は契約さえ有れば、同様に、カードＢにもカードＣにもアプリケーション搭載可能である。つまり、バーチャルカード発行者（３００１）は、実際のカード発行業務を行っていないにも関わらず、バーチャルカード（３００８）のような概念上のカードを発行しており、バーチャルカード発行者（３００１）と契約すればアプリケーション搭載可能なカードと見なすことができる。サービス提供者側から見ると、複数のカードにアプリケーションを搭載するために、１つのカード発行者のみと契約を結び通信を確立すれば良いので大幅手間が省けコスト削減につながる。
【０１６８】
以上、本願諸発明を説明したが、その要点をまとめると次ぎの通りである。
【０１６９】
本願発明は、ＩＣカードのカード発行者の許可を直接得ることなく、しかしながら同程度の高セキュリティを保持しながらアプリケーションを搭載することを可能とする。将来、ＩＣカードが普及し、利用数が増加することに伴い発生するであろう下記の諸難点に関しては、カード発行者同士の提携契約とそれに伴う情報のやり取りにより、提携先サービス提供者とカード発行者が直接通信を確立する必要がなくなったため解決される。こうして、本願発明によって、ＩＣカードへの柔軟なサービス提供が可能となった。尚、上記難点とは、第１がカード発行者―サービス提供者間に起こる膨大な量の契約と通信の問題であり、第２が現実的に契約関係を結べない事業者同士の問題である。
【０１７０】
また、解決方法の一つである代理署名を用いることにより付随して起こる難点として、第１に一度代理者認証書を発行してしまうと無制限に使用される危険性、第２に搭載回数、搭載領域など条件を付けた提携契約を結ぶ必要性を挙げることが出来る。この難点は、限定機能付きのセキュリティドメインを用いることで回避することが出来る。
【０１７１】
さらに、本願発明のアプリケーションの搭載方式を利用することで、
各種の新しいＩＣカードの利用形態を可能とした。
【０１７２】
こうした新しいＩＣカードの利用形態の例を列挙すれ、下記の通りである。（１）既存システムへの応用方式、（２）発行者間で相互に代行業務を行うことによる相互運用方式、（３）ＩＣカード上の領域を借り受け運用するテナント事業、（４）カード発行者によるサービス提供者間のアプリケーション搭載における差異の設定、（５）バーチャルカード発行事業。
【０１７３】
本願は、その形態が多岐に渡るので、以下に主な形態、あるいは概念を整理し、列挙する。
【０１７４】
その第１は、非対称暗号化機能を有するＩＣカードを利用した署名生成及び検証方式において、
ＩＣカード発行者がＩＣカードにみずからの公開鍵を格納し利用者に配布するステップと、
ＩＣカード発行者が第３者（以降代理者と呼ぶ）の公開鍵を受け取り、
カード発行者の秘密鍵で署名を付与し代理者に戻すステップと、
代理者が自らの秘密鍵でデータに署名を付与するステップと、
代理者が前記カード発行者より受け取ったカード発行者署名付き代理者公開鍵とそのデータを合わせてカードに送信するステップと、
カード内のカード発行者公開鍵で前記付与したカード発行者署名付き代理者公開鍵を検証するステップと、
この代理者公開鍵でデータの署名を検証し正当性を確認するステップを
有することを特徴とする署名生成及び検証方式である。
【０１７５】
第２は、ＩＣカード発行者がＩＣカードに自らの公開鍵を格納し利用者に配布するステップと、
発行者が代理者の公開鍵を受け取り、自らの秘密鍵で署名し代理認定証として渡すというステップと、
アプリケーションをカードに発行する業務を行う事業主体者（以降サービス提供者と呼ぶ）がアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを代理者に渡すというステップと、
代理者は渡されたアプリケーションのハッシュ値などに代理者の秘密鍵で署名を行うステップと、
上記署名付きハッシュ値と発行者より渡されている代理認定証を合わせてアプリケーション認証書としてサービス提供者に戻すというステップと、
サービス提供者がアプリケーションとアプリケーション認証書を合わせてカードに搭載するというステップと、
カード内の発行者公開鍵により代理認定証を検証するステップと、
上記検証された代理者の公開鍵によりカード内でアプリケーションのハッシュ値を検証するステップと、
カード内でアプリケーションのハッシュ値を計算するステップと、
検証されたハッシュ値と計算されたハッシュ値を比較することでアプリケーションの正当性を確認するステップを
有することを特徴とするアプリケーション搭載方式である。
【０１７６】
第３は、ＩＣカード内でアプリケーションの搭載・削除・管理機能を行うアプリケーションもしくはデータ（以降セキュリティドメインと呼ぶ）であって、
カード発行者により作成され、
アプリケーション搭載に関する所定の制限がカード発行者により設定可能であり、
内部に発行者の公開鍵が格納されている状態で代理者に渡され、
代理者によりサービス提供者に渡され、
サービス提供者によりカード内に搭載され、
その後サービス提供者により当該セキュリティドメイン内に代理者の秘密鍵を設定され、
アプリケーション搭載時に当該セキュリティドメイン内のカード発行者の公開鍵により代理者の公開鍵の署名を検証し、
上記代理者の公開鍵を用いてアプリケーションのハッシュ値の署名を検証しアプリケーションの正当性を確認する
ことを特徴とするＩＣカード内でアプリケーションの搭載・削除・管理機能を行うセキュリティドメインである。
【０１７７】
第４は、前記署名生成及び検証方式と、前記セキュリティドメインを利用したＩＣカードへのアプリケーション搭載方式である。即ち、
発行者が代理者に代理認定証と所定の制限を設定したセキュリティドメインを代理者に渡すステップと、
代理者がサービス提供者に、上記セキュリティドメインとセキュリティドメイン用の鍵を渡すステップと、
サービス提供者が、該セキュリティドメインをカードに格納し、鍵を設定するステップと、
サービス提供者が、代理者にアプリケーション認証書を要求し受け取るステップと、
サービス提供者が上記アプリケーション認証書をアプリケーションを合わせてカードに搭載するステップと、
カード内でアプリケーション認証書を検証しアプリケーションの正当性を確認するステップを
有することを特徴とするアプリケーション搭載方式である。
【０１７８】
第５は、セキュリティドメインをサービス提供者から受け取り格納する手段と、
サービス提供者により該セキュリティドメイン内に鍵を設定する手段と、
アプリケーション搭載時にアプリケーションに付与されたアプリケーション認証書を検証する手段と、
アプリケーションをインストールする手段を
有することを特徴とするアプリケーション搭載可能のＩＣカードである。
【０１７９】
第６は、自ら以外の第３者である代理者から渡された公開鍵を受け取り、
自らの秘密鍵で署名を付与し代理認定証として代理者に戻し、
セキュリティドメインを作成・条件設定した上で代理者に渡すことを特徴とするＩＣカード発行者である。
【０１８０】
第７は、ＩＣカードの発行管理業務の一部を代行する事業者（代理者）であり、
自らの公開鍵を発行者に渡し、
発行者の秘密鍵により署名をされた代理認定証を受け取り、
発行者からセキュリティドメインを受け取り、
サービス提供者に該セキュリティドメインとセキュリティドメイン用鍵を渡し、
サービス提供者からアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを受け取り、
それに自らの秘密鍵で署名を付与しそれと代理認定証を合わせてアプリケーション認証書としてサービス提供者に戻すことを特徴とする事業主体者である。
【０１８１】
第８は、代理者からセキュリティドメインとセキュリティドメイン用鍵を受け取り、
カード内にセキュリティドメインを格納し、鍵を設定し、
カードに搭載するアプリケーションのハッシュ値などアプリケーションの特徴を示すデータを、該カードの発行者の代行業務を行う代理者に送信し、
代理者からの代理認定証と代理者の秘密鍵で署名を付与されたアプリケーションのハッシュ値などをアプリケーション認証書として受け取り、
アプリケーション認証書とアプリケーションを合わせてカードに送信することを特徴とするサービス提供者である。
【０１８２】
第９は、前記事業主体者が同時にカード発行管理業務も行い、
自らが発行するカードへのアプリケーション認証書の他に、代理認定証を渡されている発行者の発行したカードへのアプリケーション認証書を発行することが可能であることを特徴とするカード発行者間のカード相互運用方式である。
【０１８３】
第１０は、カードを発行管理する発行者同士が双方とも前記代理者であることにより、
発行者は双方の発行するカードに搭載するアプリケーションの認証書を発行することが可能であることを特徴とするカード発行者間のカード相互運用方式である。
【０１８４】
第１１は、ＩＣカード上の部分領域の運用を行い、
カード発行者に対してはＩＣカード上の部分領域を借り受けていることへの対価を支払い、
サービス提供者に対してはアプリケーション搭載に対する課金や問い合わせなどへのサポート業務を行うことの対価を要求することを特徴とする業務である。
【０１８５】
第１２は、セキュリティドメインの機能を使用したＩＣカードへのアプリケーション搭載方式であって、
サービス提供者は該セキュリティドメインを通してのみアプリケーション搭載可能であり、
該セキュリティドメインに設定される条件はカード発行者がサービス提供者との契約内に応じて設定し、
同一カード上で、サービス提供者毎の条件よりアプリケーション搭載条件が異なることを特徴とするアプリケーション搭載方式である。
【０１８６】
第１３は、代理者が複数のＩＣカード発行者の代理者であり、
サービス提供者からのアプリケーション搭載要求を代理者が受け取り、
上記複数カード発行者からの代理認定証を複数付与したアプリケーション認証書を発行し、
サービス提供者が該アプリケーション認証書を受け取ることで複数カードへのアプリケーション搭載が可能となることを特徴としているＩＣカード発行管理代行業務である。
【０１８７】
第１４は、当該ＩＣカ−ドを発行したＩＣカ−ド発行者が署名した代理者の公開鍵と、代理者が署名したアプリケ−ションとを受け取る手段と、代理者の公開鍵に付与されたＩＣカ−ド発行者の署名を検証する手段と、上記代理者の公開鍵によりアプリケ−ションの署名を検証する手段と、を有するアプリケ−ション搭載可能なＩＣカ−ドである。
【０１８８】
第１５は、ＩＣカ−ドの発行管理業務を行うＩＣカ−ド発行者であり、
自ら以外の第３者である代理者から渡された公開鍵を受け取り、自らの秘密鍵で署名を付与し、これを代理認定証として代理者に戻すＩＣカ−ド発行者である。
【０１８９】
第１６は、ＩＣカ−ドの発行管理業務の一部を代行する事業者（代理者）であり、自らの公開鍵を発行者に渡し、
発行者の秘密鍵により署名をされた代理認定証を受け取り、
サ−ビス提供者からアプリケ−ションの、例えば、ハッシュ値などのアプリケ−ションの特徴を示すデ−タを受け取り、
それに自らの秘密鍵で署名を付与し、それと代理認定証を合わせてアプリケ−ション認定証としてサ−ビス提供者に戻すことを特徴とするアプリケ−ション搭載を実施する事業主体者である。
【０１９０】
第１７は、アプリケ−ションをカ−ドに発行する業務を行う事業主体者（サ−ビス提供者）であり、
ＩＣカ−ドに搭載するアプリケ−ションのハッシュ値などアプリケ−ションの特徴を示すデ−タを、前記ＩＣカ−ドの発行者の代行業務を行う代理者に送付し、代理者からの代理認定証と代理者の秘密鍵で署名を付与されたアプリケ−ションのハッシュ値などをアプリケ−ション認定書として受け取り、
アプリケ−ション認定書とアプリケ−ションを合わせてカ−ドに送信するアプリケ−ション搭載を実施するサ−ビス提供者である。
【０１９１】
【発明の効果】
本願発明の第１の形態は、ＩＣカードのカード発行者の許可を直接得ることなく、カード発行者の許可を得る場合と同程度の高セキュリティを保持しながら、当該ＩＣカードにアプリケーションを搭載することを可能とする。加えて、本願発明の第１の形態は膨大なの契約と通信の量の増大に基づく、現実的各種処理の煩雑さを解消する。
【０１９２】
本願発明の第２の形態は、ＩＣカードのカード発行者の許可を直接得ることなく、ＩＣカードにアプリケーションを搭載する場合に付随して生ずるアプリケーションの搭載の無制限性の難点を回避する。
【図面の簡単な説明】
【図１】図１はＩＣカードの基本構成を示す図である。
【図２】図２はＩＣカードの発行、サービス提供に関するこれまでのシステム構成の例である。
【図３】図３はセキュリティドメイン機構を持つＩＣカードの基本構成を示す図である。
【図４】図４は従来のアプリケーション搭載の為のシーケンスの例を示す図である。
【図５】図５は従来方式における難点を説明する為の図である。
【図６】図６は本願発明におけるＩＣカード、発行者、代理者、及びサービス提供者の関係を示す図である。
【図７】図７は本願発明のシステムの基本的な構成を示す図である。
【図８】図８は代理署名を行う場合のＩＣカード、発行者、代理者、及びサービス提供者の関係を示す図である。
【図９】図９は代理署名による提携を実現するシーケンスを示す図である。
【図１０】図１０は、ＩＣカードにアプリケーションを搭載する為の本願発明に係わるシーケンスを示す図である。
【図１１】図１１は、カード発行者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図１２】図１２は代理者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図１３】図１３は代理者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図１４】図１４はサービス提供者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図１５】図１５はセキュリティドメインを有するＩＣカードの基本構成を示す図である。
【図１６】図１６は代理署名及びセキュリティドメインを用いた提携を実現する為の本願発明のシーケンスを示す図である。
【図１７】図１７はＩＣカードにＳＤを搭載する為の本願発明のシーケンスを示す図である。
【図１８】図１８はＩＣカードにアプリケーションを搭載する為の本願発明のシーケンスを示す図である。
【図１９】図１９はカード発行者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図２０】図２０は代理者が事前提携を行う為の本願発明に係わるシーケンスを示す図である。
【図２１】図２１は代理者がＳＤを搭載する為のシーケンスを示す図である。
【図２２】図２２は代理者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図２３】図２３はサービス提供者がＳＤの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図２４】図２４はサービス提供者がアプリケーションの搭載を行う為の本願発明に係わるシーケンスを示す図である。
【図２５】図２５は本願発明を用いたテナント例を示す図である。
【図２６】図２６は本願発明を用いた制限付きサービスの提供契約を行う例を説明する図である。
【図２７】図２７は本願発明を用いたバーチャルカードの例を説明する図である。
【図２８】図２８はカード・システムの概要を示す図である。
【符号の説明】
１１：ＩＣカード、１０１：ＩＣカード内ハードウェア層
１０２：ＩＣカード内ＯＳ層、１０６：ＩＣカード内アプリケーション
１０７：ＩＣカード内アプリケーション層、１０８：セキュリティドメイン、３０２：カード発行者サーバ、３０３：サービス提供者サーバ
３０４：クライアント側用外部端末、３０５：カード発行者データベース、３０６：サービス提供者データベース、８０１、８０２：アプリケーション、８０４、８０５：セキュリティドメイン、８０３：サービス提供者、９０１：代理者、９０２：代理者のデータベース、２８０１：カード発行者、２８０２、２８０３：サービス提供者、２８０４：代理者＝テナントビジネス事業者、２８０５：サービス提供者＝テナント希望事業者、２８１０：カードＯＳ、２８１１、２８１２：セキュリティドメイン、２８１３：限定機能付きセキュリティドメイン
２８１４〜２８１９：アプリケーション、２９０１：カード発行者
２９０２、２９０３、２９０５：サービス提供者
２９０４、２９１０：カードＯＳ
２９１１、２９１２：セキュリティドメイン
２９１３：限定機能付きセキュリティドメイン
２９１４〜２９１９：アプリケーション
３００１：バーチャルカード発行者
３００２〜３００４：サービス提供者、３００５〜３００７：ＩＣカード、３００９〜３０１１：提携先の搭載領域。
Claims (6)
- ＩＣカードの発行に必要なデータを管理するカード発行者サーバであって、
前記カード発行者サーバは、秘密鍵を有し、前記秘密鍵による署名をしたセキュリティドメインをネットワークを介し代理者サーバに送付するものであって、
前記セキュリティドメインは、前記代理者サーバに続き前記サービス提供者に送付された後、前記ＩＣカードに格納されるものであり、
前記ＩＣカードは、前記秘密鍵に対応する公開鍵を有し、前記セキュリティドメインの署名を前記公開鍵により復号し正当性を確認した後、前記セキュリティドメインを格納するものであって、
前記セキュリティドメインは、ＩＣカードに格納された後、前記発行者が定める条件に従いサービス提供者サーバから送付される前記アプリケーションを管理することを特徴とするカード発行者サーバ。 - 請求項１に記載のカード発行者サーバにおいて、
前記カード発行者サーバからの前記代理者サーバへのセキュリティドメインの送付後は、前記カード発行者サーバと前記代理者サーバとはオフラインとなることを特徴とするカード発行者サーバ。 - 請求項１から２のいずれかに記載のカード発行者サーバにおいて、
前記署名は、前記秘密鍵で暗号化した情報の付与であることを特徴とするカード発行者サーバ。 - 請求項１から３のいずれかに記載のカード発行者サーバにおいて、
前記条件は、少なくとも前記アプリケーションの容量、搭載回数、個数、搭載可能な有効期間のいずれか一つであることを特徴とするカード発行者サーバ。 - ＩＣカードの発行に必要なデータを管理するカード発行者サーバから、代理認定証と前記カード発行者サーバの秘密鍵による署名をしたセキュリティドメインをネットワークを介し受信する代理者サーバであって、
前記代理者サーバは前記セキュリティドメインを前記サービス提供者に送付後、前記代理認定証を前記サービス提供者サーバに送付することにより前記ＩＣカードにアプリケーションの搭載を許可するものであって、
前記代理認定証と前記セキュリティドメインが前記サービス提供者に送付された後は、前記カード発行者サーバと前記代理者サーバとはオフラインとなることを特徴とする代理者サーバ。 - 請求項５に記載のカード発行者サーバにおいて
前記代理認定証は、代理者の公開鍵を前記カード発行者サーバの第２の秘密鍵で暗号化した情報であることを特徴とする代理者サーバ。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000249182A JP3808297B2 (ja) | 2000-08-11 | 2000-08-11 | Ｉｃカードシステム及びｉｃカード |
| US09/639,751 US6931379B1 (en) | 2000-08-11 | 2000-08-15 | IC card system and IC card |
| EP00117662A EP1189157A3 (en) | 2000-08-11 | 2000-08-16 | IC card system and IC card |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000249182A JP3808297B2 (ja) | 2000-08-11 | 2000-08-11 | Ｉｃカードシステム及びｉｃカード |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002056360A JP2002056360A (ja) | 2002-02-20 |
| JP2002056360A5 JP2002056360A5 (ja) | 2005-02-24 |
| JP3808297B2 true JP3808297B2 (ja) | 2006-08-09 |
Family
ID=18738961
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000249182A Expired - Fee Related JP3808297B2 (ja) | 2000-08-11 | 2000-08-11 | Ｉｃカードシステム及びｉｃカード |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6931379B1 (ja) |
| EP (1) | EP1189157A3 (ja) |
| JP (1) | JP3808297B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8752159B2 (en) | 2010-07-12 | 2014-06-10 | Ricoh Company, Ltd. | Information processing apparatus, verification system, control method of verification system, program of control method of verification system, and storage medium |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2816731B1 (fr) * | 2000-11-14 | 2003-01-03 | Gemplus Card Int | Procede de chargement et de personnalisation des informations et programmes charges dans une carte a puce |
| US7783568B1 (en) * | 2001-05-01 | 2010-08-24 | Visa International Service Association | Payment services for multi-national corporations |
| JP4743374B2 (ja) * | 2001-08-23 | 2011-08-10 | 大日本印刷株式会社 | インターネットを利用したｉｃカードへのアプリケーションプログラム追加システム |
| JP2003168093A (ja) * | 2001-11-30 | 2003-06-13 | Hitachi Ltd | カードシステム、カードへのアプリケーション搭載方法及びアプリケーション実行確認方法 |
| US7793355B2 (en) | 2002-12-12 | 2010-09-07 | Reasearch In Motion Limited | System and method of owner control of electronic devices |
| AU2004213886A1 (en) | 2003-02-21 | 2004-09-02 | Research In Motion Limited | System and method of multiple-level control of electronic devices |
| JP4067985B2 (ja) | 2003-02-28 | 2008-03-26 | 松下電器産業株式会社 | アプリケーション認証システムと装置 |
| JP2004334542A (ja) * | 2003-05-08 | 2004-11-25 | Dainippon Printing Co Ltd | Ｉｃカード、ｉｃカードプログラム及びｉｃカードのメモリ領域の割当方法 |
| EP1492061A1 (fr) * | 2003-06-25 | 2004-12-29 | Nagracard S.A. | Méthode d'allocation de ressources sécurisées dans un module de sécurité |
| EP3023899B1 (en) * | 2003-09-30 | 2020-09-16 | Nxp B.V. | Proximity authentication system |
| US7557433B2 (en) | 2004-10-25 | 2009-07-07 | Mccain Joseph H | Microelectronic device with integrated energy source |
| EP1763744B1 (en) * | 2004-04-30 | 2017-07-19 | BlackBerry Limited | System and method of owner application control of electronic devices |
| FR2872309A1 (fr) * | 2004-06-23 | 2005-12-30 | Gemplus Sa | Procede de gestion d'une carte a puce multi-applicative |
| JP4484617B2 (ja) * | 2004-07-29 | 2010-06-16 | 富士通株式会社 | 記録媒体の保証方法およびその保証管理プログラムならびに保証処理プログラム |
| JP2006119901A (ja) * | 2004-10-21 | 2006-05-11 | Toshiba Corp | 携帯可能電子装置および携帯可能電子装置のアプリケーション更新方法 |
| US20060136717A1 (en) | 2004-12-20 | 2006-06-22 | Mark Buer | System and method for authentication via a proximate device |
| WO2006107777A2 (en) * | 2005-04-01 | 2006-10-12 | Mastercard International Incorporated | Dynamic encryption of payment card numbers in electronic payment transactions |
| US20070039041A1 (en) * | 2005-08-15 | 2007-02-15 | Davis Michael L | Unified reference id mechanism in a multi-application machine readable credential |
| US7865737B2 (en) * | 2005-09-05 | 2011-01-04 | Yamaha Corporation | Digital mixer |
| US8045958B2 (en) | 2005-11-21 | 2011-10-25 | Research In Motion Limited | System and method for application program operation on a wireless device |
| EP1826944B1 (en) | 2006-02-27 | 2009-05-13 | Research In Motion Limited | Method of customizing a standardized IT policy |
| EP1873963A1 (en) * | 2006-06-29 | 2008-01-02 | Incard SA | Authentication method for IC cards |
| JP4702628B2 (ja) | 2006-07-27 | 2011-06-15 | ソニー株式会社 | 電子機器、情報処理方法、およびプログラム |
| JP4948271B2 (ja) * | 2007-06-04 | 2012-06-06 | 日本電信電話株式会社 | Ｉｃカードアプリケーション格納方法及びシステム及びｉｃカード発行者サーバ及びプログラム |
| EP2043016A1 (en) * | 2007-09-27 | 2009-04-01 | Nxp B.V. | Method, system, trusted service manager, service provider and memory element for managing access rights for trusted applications |
| HU230695B1 (hu) * | 2007-10-20 | 2017-09-28 | Andrá Vilmos | Eljárás egyedi hozzáférésű információtartalom kommunikációs eszköz biztonságos tároló részegységében történő elhelyezésének előkészítésére, valamint elhelyezésére |
| ITMI20080536A1 (it) * | 2008-03-28 | 2009-09-29 | Incard Sa | Metodo per proteggere un file cap per una carta a circuito integrato. |
| EP2128830A1 (en) * | 2008-05-30 | 2009-12-02 | Gemplus | A method and an electronic device for transferring application data from a source electronic device to a destination electronic device |
| JP5476086B2 (ja) * | 2009-10-16 | 2014-04-23 | フェリカネットワークス株式会社 | Ｉｃチップ、情報処理装置およびプログラム |
| JP6119856B2 (ja) * | 2013-07-01 | 2017-04-26 | 日本電気株式会社 | 有効性制御システム、端末装置、サーバ装置、記録媒体、方法、および、プログラム |
| CN105659270B (zh) * | 2013-09-13 | 2020-02-21 | 日本电气株式会社 | 用于有效性控制的终端设备和服务器设备 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5825880A (en) * | 1994-01-13 | 1998-10-20 | Sudia; Frank W. | Multi-step digital signature method and system |
| JPH10133869A (ja) * | 1996-10-30 | 1998-05-22 | Shinichiro Ogawa | ソフトウエア製品の流通方法 |
| US6317832B1 (en) | 1997-02-21 | 2001-11-13 | Mondex International Limited | Secure multiple application card system and process |
| AU7484898A (en) | 1997-05-09 | 1998-11-27 | Gte Government Systems Corporation | Biometric certificates |
| US6422459B1 (en) * | 1997-10-15 | 2002-07-23 | Citicorp Development Center, Inc. | Method and system for off-line loading of stored value cards using a batch-load terminal |
| US6402028B1 (en) * | 1999-04-06 | 2002-06-11 | Visa International Service Association | Integrated production of smart cards |
-
2000
- 2000-08-11 JP JP2000249182A patent/JP3808297B2/ja not_active Expired - Fee Related
- 2000-08-15 US US09/639,751 patent/US6931379B1/en not_active Expired - Fee Related
- 2000-08-16 EP EP00117662A patent/EP1189157A3/en not_active Withdrawn
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8752159B2 (en) | 2010-07-12 | 2014-06-10 | Ricoh Company, Ltd. | Information processing apparatus, verification system, control method of verification system, program of control method of verification system, and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002056360A (ja) | 2002-02-20 |
| EP1189157A3 (en) | 2003-09-17 |
| US6931379B1 (en) | 2005-08-16 |
| EP1189157A2 (en) | 2002-03-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3808297B2 (ja) | Ｉｃカードシステム及びｉｃカード | |
| US7539861B2 (en) | Creating and storing one or more digital certificates assigned to subscriber for efficient access using a chip card | |
| US7925878B2 (en) | System and method for creating a trusted network capable of facilitating secure open network transactions using batch credentials | |
| US7904722B2 (en) | Method for securely using digital signatures in a commercial cryptographic system | |
| Neuman | Proxy-based authorization and accounting for distributed systems | |
| AU698454B2 (en) | Method for securely using digital signatures in a commercial cryptographic system | |
| US8302171B2 (en) | System and method for privilege delegation and control | |
| US6490367B1 (en) | Arrangement and method for a system for administering certificates | |
| US7526649B2 (en) | Session key exchange | |
| KR100411448B1 (ko) | 공개키 기반구조의 개인키와 인증서를 저장하는 광학기록매체의 발급방법 및 발급시스템 | |
| US20030105965A1 (en) | Business method for secure installation of a credit authorization key on a remote tcpa compliant system | |
| US20070179906A1 (en) | Methods for operating infrastructure and applications for cryptographically-supported services | |
| US20030035548A1 (en) | Client controlled data recovery management | |
| US20100088236A1 (en) | Secure software service systems and methods | |
| WO1996002993A9 (en) | Method for securely using digital signatures in a commercial cryptographic system | |
| JP2003234736A (ja) | 公開鍵インフラストラクチャ・トークン発行及びバインディング処理 | |
| JP2008533547A (ja) | 多機能スマートカード上のアプリケーションを管理するシステムおよび方法 | |
| Wang et al. | Achieving secure and flexible m-services through tickets | |
| Deng et al. | Integrating security in CORBA based object architectures | |
| JP3996022B2 (ja) | 複数サービス利用者に対するｉｃカードサービス利用許可方法及びシステム | |
| Low et al. | Self authenticating proxies | |
| JP4201107B2 (ja) | 埋め込み型権限委譲方法 | |
| Van Herreweghen et al. | Risks and Potentials of Using EMV for Internet Payments. | |
| Navarro et al. | Role-based access control for e-commerce sea-of-data applications | |
| JP4201106B2 (ja) | コマンド実行権限譲渡方法及びシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040325 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040325 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060127 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060207 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060329 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060329 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060509 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060517 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100526 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110526 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110526 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120526 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120526 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130526 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130526 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |