JP2002056360A - Ｉｃカードシステム及びｉｃカード - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】ＩＣカード上へのアプリケーション搭載を行う
サービス提供者が、搭載を希望するカード発行者と直接
契約や通信を行わなくても、安全でかつカードの発行後
に、アプリケーションの動的搭載が可能なＩＣカード、
及び運用方法を提供する。 【解決手段】ＩＣカードの発行者は、ＩＣカードの発行
者以外の第３者に、あらかじめ暗号鍵を渡しておき、搭
載するアプリケーションへの認証業務の代理を委託す
る。また、代理認証を検証する機能を有するプログラム
もしくはデータをカード上に搭載しておき、搭載要求の
あったアプリケーションの正当性を確認する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本願発明は、ＩＣカードの発
行者以外の第三者による動的認証及びＩＣカードへのア
プリケーション搭載方法及びその利用に関する諸技術に
関するものである。

【０００２】

【従来の技術】ＩＣカードは、大量の情報が記録可能で
あり、かつ高度なセキュリティを有するため、磁気カー
ドに代わる新しい情報記録媒体として近年普及しつつあ
る。また、最近ではＩＣカードに複数のアプリケーショ
ンを搭載できるマルチアプリケーション機能や、カード
発行後にアプリケーションを搭載可能なダイナミックロ
ーディング機能を備えたＩＣカード及びカードＯＳが主
流となってきている。

【０００３】従来、これらのＩＣカードへのアプリケー
ション搭載方式では、該カードを発行した発行者による
何らかの署名が付与されたアプリケーションのみを搭載
可能としていた。カード発行後に当該カードにアプリケ
ーションを搭載するいわゆる動的搭載も前提としている
ため、誰にでもアプリケーションが搭載可能であるシス
テムはセキュリティ上問題があるからである。

【０００４】図１にＩＣカード（１１）内に搭載されて
いるＩＣ内部の基本的な領域の論理的な構成を示す。当
該ＩＣは、ハードウェア層（１０１）とＯＳが搭載され
る領域、即ちＯＳ層（１０２）とアプリケーションが搭
載される領域、即ちアプリケーション層（１０７）とを
有する。ここで、マルチアプリケーションの搭載が可能
とは、アプリケーション層（１０７）に複数のアプリケ
ーション（１０６）が搭載できることである。又、ダイ
ナミックローディングが可能であるとは、このアプリケ
ーション（１０６）をカード発行後にアプリケーション
が搭載あるいは削除が可能であることを示す。ＯＳ層
（１０２）は通信処理部（１０３）、インタープリタ
（１０４）、セキュリティ機構（１０５）などを有し、
外部端末からのコマンドの受信やアプリケーションのコ
マンドの転送などを行っている。当然、アプリケーショ
ン層（１０７）とＯＳ層（１０２）との間にはアプリケ
ーション・インターフェイス、ＯＳ層（１０２）とハー
ドウェア層（１０１）との間にはハードウエア・インタ
ーフェイスが設けられる。

【０００５】図２はＩＣカードの発行やサービスの提供
に関する従来のシステム構成図である。カード発行者
（３０２）とは、ＩＣカードの発行と管理の業務を行う
事業主体者であり、カードの責任を負う主体者である。
また、サービス提供者（３０３）はＩＣカード上に搭載
するアプリケーションの発行と管理の業務を行う事業主
体者である。カード発行後に、アプリケーションをダイ
ナミックに搭載する場合は、サービス提供者の端末から
ＩＣカードへ搭載することが多い。クライアント側（３
０１）にはＩＣカードとコマンドのやり取りを行う外部
端末（３０４）がある。カード発行者は発行者データベ
ース（３０５）に発行管理データを保持しており、その
データに従いカードを発行し利用者に配布する。発行管
理データには、利用者からの申請情報や、カードの発行
に必要な基本情報が記載されている。ＩＣカード搭載用
アプリケーションは、サービス提供者が作成もしくは取
得し、ＩＣカードへのアプリケーション搭載を行う。

【０００６】サービス提供者データベース（３０６）に
はアプリケーション関連（以下、ＡＰ関連と称する）デ
ータが格納されている。前記のように、ＩＣカード上の
全ての責任はカード発行者に帰属するため、アプリケー
ションの正当性をカード発行者が確認する手順が必要で
ある。サービス提供者はカード発行者のＡＰの搭載を許
可する処理部にＡＰ搭載の許可の要求を行う。カード発
行者のデータベースには事前に登録されているＡＰに関
するデータが格納されている。そして、要求のあったア
プリケーションが不正なものではないか、要求をしてい
るサービス提供者が不正ではないかなどをチェックした
上で、ＡＰの搭載許可を発行する。サービス提供者はこ
のＡＰ搭載許可とアプリケーションを合わせてカードに
送信し設定するのである。そのため、サービス提供者は
あらかじめカード発行者と契約し、自身が正当な事業主
であることや、搭載予定のアプリケーションが不正なも
のではないことを登録する必要がある。

【０００７】カード発行者とサービス提供者のサーバ間
は、ネットワークでつながれている場合が多いと想定さ
れるが、書類形式でやり取りすることも可能である。

【０００８】またこれに加え、アプリケーション搭載の
際に、カード内でアプリケーション搭載を専用に行うア
プリケーションもしくはデータを用いる場合がある。こ
の方式は“セキュリティドメイン”というアプリケーシ
ョンをサービス提供者毎に用意し、アプリケーション搭
載・削除・管理の役割を担わせている。図３にセキュリ
ティドメイン機構を持つＩＣカードのＩＣ内部の基本的
な領域の論理的な構成を示す。セキュリティドメイン
（１０８）はアプリケーション層に存在し自らが責任を
持つアプリケーション（１０６）を管理する。アプリケ
ーションはカードに搭載や削除される場合、このセキュ
リティドメインを通じて行われる。また鍵データなどの
セキュリティ情報やＩＤ番号などのデータ管理をセキュ
リティドメインに委託する場合もある。

【０００９】

【発明が解決しようとする課題】上記のようなこれまで
のＩＣカードへのアプリケーション搭載方式は、高セキ
ュリティを保ちながらアプリケーションの動的な搭載や
削除を可能としている。しかし、複数カード発行者やそ
のサービス提供者間での運用に際してはいくつかの難点
がある。

【００１０】前述のように、サービス提供者は、アプリ
ケーションの搭載を希望するカードのカード発行者に対
して、あらかじめ契約を結ぶ必要がある。つまり、カー
ド発行者は、発行するカードにアプリケーションの搭載
を希望する全てのサービス提供者と契約関係にあり、そ
のサービス提供者からの要求を受け、アプリケーション
搭載や削除を行う場合は上記アプリケーション搭載方法
で良い。図５のように発行者（３０２）と契約関係にあ
るサービス提供者（３０３）がカードＡ（１１）にアプ
リケーションを搭載する場合は従来方法でいい。しか
し、サービス提供者（８０３）のように、カード発行者
とあらかじめ複雑な事前契約やアプリケーションの登録
をいちいち行わずにアプリケーションを搭載する要求が
でてくるだろう。そもそも、ＩＣカードは複数アプリケ
ーションを搭載可能なことが大きな利点であり、多数の
サービスが提供可能であることはカード運用側のカード
発行者にとっても利用側のユーザにとっても多大なメリ
ットであるため、このような要求は年々増加するものと
予想される。しかし、現在のアプリケーション搭載方式
に従い、事前契約などせずにサービスを供給することは
不可能である。図５に示すように、サービス提供者（８
０３）と発行者（３０２）の間には何らかの情報交換が
必要である。つまり、従来のアプリケーション搭載方式
に従うならば、サービス提供者はアプリケーション搭載
を希望するカードの発行者全てと事前に契約を結ぶ必要
があり、アプリケーション搭載時には全てのカード発行
者にアプリケーション搭載許可証を発行してもらわなけ
ればならない。この実現方法には以下のような難点があ
る。

【００１１】（１）カード発行者―サービス提供者間の
契約関係及び運用時の通信の増大と複雑化 Ｎ個のカード発行者とＭ個のサービス提供者の間で相互
にサービスを運用する場合、Ｎ＊Ｍの契約関係が結ばれ
ることになり膨大な量の契約と運用時の通信が発生する
ことになる。それに伴うコストや時間が増大し最終的に
はＩＣカード単価の増加の原因となる。

【００１２】（２）現実的に契約関係を結べない事業者
同士の問題 例えば、インターナショナルカードに国内企業のアプリ
ケーションを搭載する場合、この国内企業がカード発行
者と直接コンタクトをとることは現実的にはあまりな
く、国内向け窓口業務を行う事業者が間に入ることが考
えられる。このようにカード発行者やサービス提供者が
属する事業主体により直接契約を結んだり通信を確立す
ることが難しい。

【００１３】

【課題を解決するための手段】本願発明の次の主な二つ
の形態を有する。これら形態の基本思想を、その要点を
ごく簡潔に要約すると次ぎの通りである。

【００１４】本願発明の第１の形態は、ＩＣカードの発
行者以外の第三者による認証書を用いることである。
尚、以下ＩＣカードの発行者以外の第三者による認証書
を簡便に代理署名と称する。

【００１５】本願発明の第２の形態は、ＩＣカードが限
定機能付きのセキュリティドメインを有することであ
る。この第２の形態は、前記第１の形態の機能を補足
し、より有用なＩＣカード・システムを提供することを
可能ならしめるものである。

【００１６】そして、本願発明の第３の形態は、前記第
１と第２の発明思想を合わせて使用することである。こ
うして、カード発行者が認めた代理者が、カード発行者
が認めた条件でアプリケーション搭載を代行することが
可能である。

【００１７】以下に、これらの本願発明の基本思想を軸
に、本願発明を説明する。

【００１８】先ず、本願発明の第１の形態についてであ
る。

【００１９】第１の形態は、例えば、第２の機関が、少
なくとも、ＩＣカード発行に係わる第１の機関を特徴づ
け且つサービス提供の為に持ちいる第１の特徴情報、及
び当該第２の機関の第２の特殊情報とを、サービス情報
提供に係わる第３の機関に提供が可能であり、前記サー
ビス情報提供に係わる第３の機関は、少なくとも、所望
のアプリケーション用プログラムと、前記ＩＣカード発
行に係わる第１の機関を特徴づけ且つサービス提供の為
に持ちいる第１の特徴情報と、当該第２の機関を特徴づ
けるところの第２の特殊情報と、をＩＣカードに提供が
可能なＩＣカード・システムであると言うことが出来
る。

【００２０】この観点は、第１に、わけても、カード発
行者―サービス提供者間の契約関係及び運用時の通信の
増大と言う前述の難点を解決するためのものである。

【００２１】このためには、発行者とサービス提供者の
間に代理者という概念を作り、カード発行者とサービス
提供者が直接通信を確立せずともアプリケーション搭載
可能な方式が必要となってくる。具体的には、カード発
行者が代理者と事前提携をすることで代理者業務を行う
ことを認証することで、サービス提供者が直接カード発
行者と通信をすることなくアプリケーション搭載が実現
可能であり、かつ通常のアプリケーション搭載方式と同
程度のセキュリティを保つことが可能な方式が必要であ
る。

【００２２】本願発明は、以上の要求を満たすＩＣカー
ドのアプリケーションの搭載方式を提供する。

【００２３】図６は本願発明の方式の骨子を説明する図
である。ＩＣカード（１１）はカード発行者（３０２）
により発行されている。サービス提供者Ａ（３０３）は
カード発行者（３０２）と契約を結んでおり通常のアプ
リケーション搭載方法によりカードにアプリケーション
８０１を発行する。

【００２４】サービス提供者Ｂ（８０３）は代理者（９
０１）と契約を結んでいる。

【００２５】本願発明の前提は、前述の難点からして、
サービス提供者Ｂ（８０３）とカード発行者（３０２）
との間の通信を行わないことである。従って、本願発明
は、代理者を通して間接的に発行者と通信を確立する手
法である。つまり、カード発行者が行っているアプリケ
ーションの許可を代理者に代行させ、サービス提供者Ｂ
がカードにアプリケーションを搭載するためには代理者
とのみ通信を行えば良いという方法である。しかし、代
理者によるアプリケーションへの署名（以降、代理署名
と呼ぶ）のみでは、次ぎのような難点を有する。即ち、
その第１はカードＡが正当性を検証できない点である。
第２は、カード発行者の意志に関わらず不特定者がアプ
リケーションの搭載が可能であるとの難点である。尚、
ここで、署名とは、暗号理論における署名であることは
言うまでもない。その代表例はデジタル署名である。例
えば、こうしたディジタル署名は、署名アルゴリズム
と、確認アルゴリズムの２つの要素から成っている。例
えば、秘密の署名アルゴリズムを利用して、文書に署名
をすることが出来る。その結果の署名は、その後公開さ
れている確認アルゴリズムを用いて確認できる。確認ア
ルゴリズムは、文書と署名とによって、確認アルゴリズ
ムは署名が本物かどうかを判断し、真もしくは偽という
答えを返すことが出来る。こうした署名に関する一般的
な理論は、例えば、ダグラス・スチンソン著、桜井幸一
訳の「暗号理論の基礎」（共立出版、１９９６）の第６
章、わけても第２１７頁より第２２０頁、あるいは「ハ
ンドブック オブ アプライド クリスタルグラフィ
（Ｈａｎｄｂｏｏｋ ｏｆ Ａｐｐｌｉｅｄ Ｃｒｙｓ
ｔａｌｇｒａｐｈｙ）」（ＣＲＣ Ｐｒｅｓｓ、１９９
６）、第４３３頁より第４３４頁に見られる。

【００２６】こうした難点を回避する為の本願発明の第
１の形態の骨子は、次の諸点に要約される。第１は、カ
ード発行者と代理者との間で提携契約を結ぶ際に、カー
ド発行者が代理者に対して代理業務を行うことを認める
代理者認定証を渡しておくことである。第２は、代理者
がアプリケーション認証する際に、代理署名と代理者認
証書を合わせてサービス提供者に渡すことである。こう
して本願発明によれば、カードＡ内で代理者認証書がカ
ード発行者による正当なものかを検証することで、不特
定者によるアプリケーションの搭載を防ぐことができ
る。

【００２７】本願発明の主な第２の形態は、前記第１の
形態の機能を補足し、より有用なＩＣカード・システム
を提供することを可能ならしめるものである。その形態
を要約すると、ＩＣカードが、いわゆる限定機能付きの
セキュリティドメインを有することである。

【００２８】本願発明の第２の形態は、例えば、第２の
機関が、少なくとも、ＩＣカード発行に係わる第１の機
関を特徴づけ且つサービス提供の為に持ちいる第１の特
徴情報、及び当該第２の機関の第２の特殊情報と、アプ
リケーション用プログラムのＩＣカードへの格納に関す
る条件を有するプログラムとを、サービス情報提供に係
わる第３の機関に提供が可能であり、前記サービス情報
提供に係わる第３の機関は、少なくとも、アプリケーシ
ョン用プログラムと、前記第１の特徴情報と、前記第２
の機関を特徴づけるところの第２の特徴情報と、前記ア
プリケーション用プログラムのＩＣカードへの格納に関
する条件を有するプログラムと、前記格納条件を有する
プログラムに係わる第３の特徴情報と、をＩＣカードに
提供が可能なＩＣカード・システムであると言うことが
出来る。

【００２９】本願発明に係る第１の形態のみでは一度代
理者認証書を発行したら、代理者は、それ以降無制限に
アプリケーションを搭載できる権限を有する。勿論、提
携の契約条件にもよるのだが、カード発行者にとって
は、「アプリケーション1個分の搭載許可権限を与えた
い」あるいは「有効期限を設定した上での搭載許可権限
を与えたい」などの要求は当然発生する。本願発明の第
２の形態は、この要求を満たすものである。

【００３０】セキュリティドメインは、前述のようにカ
ード内でアプリケーションの搭載、削除あるいは管理機
能などを実現するアプリケーションもしくはデータを有
する領域である。従って、本来、セキュリティドメイン
は、サービス提供者によって作成される。しかし、本願
発明では、カード発行者がこのセキュリティドメインを
作成し、これを代理者を通してサービス提供者に渡し、
サービス提供者のセキュリティドメインとして機能させ
る。カード発行者は作成の際、アプリケーション搭載回
数や有効期限など提携契約に対応する諸条件をセキュリ
ティドメイン内部に設定し、提携先に送信する。もちろ
ん、このセキュリティドメインは改竄防止策を取ってい
る必要がある。

【００３１】図６を参酌すれば、限定機能付きセキュリ
ティドメイン（８０５）は、カード発行者（３０２）に
より作成され、サービス提供者Ｂ（８０３）のセキュリ
ティドメインとしてカードＡ１１内に格納される。サー
ビス提供者Ｂ（８０３）がアプリケーション（８０２）
を搭載する場合、サービス提供者Ｂ（８０３）は代理者
（９０１）にアプリケーションの搭載の許可を依頼す
る。代理者（９０１）は、サービス提供者Ｂ（８０３）
に代理者認証書と代理署名を合わせて送信する。サービ
ス提供者Ｂ（８０３）はアプリケーション（３７）と代
理者認証書と代理署名を合わせてカードＡ（１１）内に
送る。カードＡは、限定機能付きセキュリティドメイン
内に設定された限定条件に照らし合わせながら、代理者
認証書が正しくカード発行者によることを検証する。そ
の結果、カードＡが、代理署名によりアプリケーション
の正当性を確認した場合、当該カードＡはアプリケーシ
ョンを搭載を可能とする。

【００３２】

【発明の実施の形態】図７は、本発明のＩＣカード（１
１）及びＩＣカードアプリケーションの発行システムの
構成図である。図７で、符号３０２はカード発行者のサ
ーバであり、符号３０５はカード発行者のデータベース
でカード発行者が運用する全てのＩＣカードに関する運
用情報である発行管理データを管理する為のものであ
る。同様に符号９０１は代理者のサーバであり、符号９
０２は代理者のデータベースで、代理者の搭載の許可を
出すＡＰに関する運用管理情報であるＡＰ関連データを
管理する。符号３０３はサービス提供者のサーバであ
り、符号３０６はサービス提供者で自身のアプリケーシ
ョンの運用情報であるＡＰ関連データを管理する。ＩＣ
カード（１１）はカード発行者システム内のカード発行
処理部（３０８）により発行され、クライアントである
利用者（３０１）のもとに配布される。尚、ここでのカ
ードの発行及び配布は、オンライン動作ではなく、通例
の意味における発行及び配布である。

【００３３】また、カード発行処理部（３０８）は代理
者システムのＡＰ搭載許可処理部（３１０）と事前提携
（３１５）を行い、代理者であることを認める代理認定
証のやり取りなどを行う。サービス提供者（３０３）が
アプリケーションをカードに搭載する場合、サービス提
供者システム内のＡＰ搭載処理部（３１２）が代理者の
ＡＰ搭載許可処理部（３１０）にＡＰ搭載要求（３１
９）を行う。代理者は事業者ポリシーに従い、ＡＰの正
当性を確認の上ＡＰ搭載許可を発行する（３１６）。サ
ービス提供者は、受け取ったＡＰ搭載許可とアプリケー
ションを合わせて外部端末（３０４）を通してＩＣカー
ドへ送信する（３１４）。カード発行者サーバ（３０
２）と代理者サーバ（９０１）、代理者サーバ（９０
１）とサービス提供者サーバ（３０３）は、各々基本的
にネットワーク（３１８、３１９）を通して接続されて
いる。しかし、運用事業者のポリシーによりフロッピー
（登録商標）ディスクなど情報記録媒体の郵送や、書面
の郵送などにより情報のやり取りを実現することもあ
る。このように、本願発明のシステムは、カード発行者
と代理者は提携契約を結び、代理者がサービス提供者へ
のサービス提供許可を代行し、サービス提供者サーバか
らユーザのＩＣカードへアプリケーションが搭載される
仕組みとなっている。

【００３４】ここで、以下の説明の理解を容易にする
為、本願明細書での特徴的な主要用語について説明す
る。

【００３５】「代理署名」は、カードの発行者を代理し
て署名を行うことである。その具体例は署名の対象とな
る情報に、当該情報を代理者の秘密鍵で暗号化した情報
を付与した情報のことである。尚、ここで、前記署名の
対象となる情報に代えて、この情報を特徴付ける情報、
例えば、そのハッシュ値を用いることも出来る。従っ
て、前記「代理署名」の用語は、この意味をも含むもの
である。

【００３６】「署名付＊＊」は、「＊＊」に、「＊＊」
を署名者の鍵、例えば秘密鍵で暗号化した情報を付与し
た情報のことである。尚、ここで、前記署名者の鍵に代
えて、この鍵情報を特徴付ける情報、例えば、そのハッ
シュ値を用いることも出来る。従って、前記「署名付＊
＊」の用語は、この意味をも含むものである。

【００３７】「代理認定書」は、代理者が発行者によっ
て、その代理であることを認定されたことを示す情報で
ある。その具体例は、代理者の公開鍵に、代理者の公開
鍵を発行者の秘密鍵で暗号化した情報を付与した情報で
ある。

【００３８】「アプリケーション認定書」は、アプリケ
ーションをＩＣカードに搭載することを許可する情報で
ある。その具体例は、アプリケーションを特徴付ける特
徴情報に、その特徴情報を代理者の秘密鍵で暗号化した
情報を付与した情報である。

【００３９】「セキュリティドメイン」はアプリケーシ
ョンの搭載、削除、あるいはその他の諸管理を行うプロ
グラムのことである。

【００４０】「限定機能付きセキュリティドメイン」
は、前記のアプリケーションの搭載、削除、あるいはそ
の他の諸管理にある制限を与える条件を付与したプログ
ラムのことである。

【００４１】尚、本願発明は非対称暗号化機能を有する
データ・システムに関する。

【００４２】非対称暗号化機能とは、例えば、暗号鍵と
して公開鍵、秘密鍵を使用し、且つこうした非対称暗号
鍵により暗号化されたデータの復号化が可能である機能
のことである。

【００４３】次に、本願発明の係わる代理署名及びアプ
リケーションの搭載の具体的方法を説明する。

【００４４】ＩＣカードに対する端末機などは、通例の
もので良い。本願発明に係わる各機関は、サーバ、リー
ダライタなど端末機を有する。本願に係わる各種情報
は、このサーバに一旦保持される場合、リーダライタを
通してＩＣカードに情報が搭載される場合など各種形態
が考えられる。本願発明はこうした動作形態に直接関係
するものではない。本願発明はこれらのいずれの場合も
適用可能である。

【００４５】図２９は簡単にカード・システム例の概要
を示す図である。ＩＣカード５２の中にはチップ５１が
あって、リーダライタ５３とデータのやりとりを行う例
を示している。リーダライタの中にはコントロールプロ
ッセサ５４やデータベースとなる磁気ディスク５５など
が存在する。ＩＣカード５２には、例えば、Ｖｃｃ（供
給電源）、ＧＮＤ（グランド）、ＲＳＴ（リセット）、
Ｉ／Ｏ（入出力）、及びＣＬＫ（クロック）などの諸端
子が示されている。又、図中、（１）はリーダライタ５
３からＩＣカード５２に対しての、例えば、ＩＤ（ＩＤ
ＥＮＴＩＦＩＣＡＴＩＯＮ）などの各種問い合わせを示
す。（２）はＩＣカードが前述の問い合わせに対する返
答を示す。こうした、諸情報の伝達は通例のシステムで
十分である。従って、その詳細の説明は省略する。

【００４６】尚、ＩＣカード内のＩＣチップにおいて、
具体的には、前述のアプリケーション、セキュリティド
メインなどは、ＯＳ部、メモリ領域に搭載される。一般
に、メモリとしては、ＲＡＭ（Ｒａｎｄｕｍ Ａｃｃｅ
ｓｓ Ｍｅｍｏｒｙ）、フラッシュ・メモリ（Ｆｌａｓ
ｈ Ｍｅｍｏｒｙ）、ＦＲＡＭ（Ｔｅｒｒｏｍａｇｎｅ
ｔｉｃ Ｒａｎｄｕｍ Ａｃｃｅｓｓ Ｍｅｍｏｒ
ｙ）、ＥＥＰＲＯＮ（Ｅｌｅｃｔｒｉｃａｌ Ｅｒａｓ
ａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲｅａｄＯｎｌ
ｙ Ｍｅｍｏｒｙ）あるいはＲＯＭ（Ｒｅａｄ Ｏｎｌ
ｙ Ｍｅｍｏｒｙ）などが用いられる。従って、本願明
細書において、「セキュリティドメインを用いて」ある
いは「セキュリティドメインを経由して」とは、ＯＳ部
が、そのセキュリティドメインなるプログラムを取り出
し、このプログラムによって、所定の情報たるデ−タの
諸管理状態を確認し、必要があれば、所定の処理を行う
ことを意味している。ここで、デ−タの諸管理の項目と
は、例えば、サービス情報の搭載容量、搭載回数、搭載
するサービス情報の個数、サービス情報の搭載可能な有
効期間などである。

【００４７】ＯＳ部などは通例のもので十分である。Ｉ
Ｃチップ内の信号処理は、通例のＩＣカードのそれをも
ちいて十分である。

【００４８】又、ＩＣカードには、接触型ＩＣカード、
非接触型ＩＣカードなどがあるが、本願発明はこうした
ＩＣカードの構成自体によらず適用することが出来る。

【００４９】図８を参酌して、代理署名について説明す
る。カードＡ（１１）はマルチアプリケーションのダイ
ナミックローディングに対応するＯＳが搭載されたＩＣ
カードであり、カード発行者（３０２）により発行済み
である。また、サービス提供者Ｂ（８０３）はＩＣカー
ドにアプリケーションを搭載しサービスを運用する事業
主体者であり、代理者（９０１）とサービス提供に関す
る契約を結んでいる。通常であれば、サービス提供者Ｂ
（８０３）がカードＡ（１１）にアプリケーションを搭
載するためには、カード発行者（３０２）とサービス提
供に関する契約を直接結び、通信を確立した上で許可を
受けなければならない。しかし、本願発明のシステム
は、カード発行者（３０２）と代理者（９０１）の間で
提携契約を結び、代理者（９０１）がカード発行者（３
０２）の代理としてアプリケーション搭載許可を行う方
法である。提携契約時に、カード発行者（３０２）は代
理者（９０１）に代行業務を行うことを認める代理認定
証を渡し、以降アプリケーション搭載許可は代理者（９
０１）が行う。サービス提供者Ｂ（８０３）はアプリケ
ーション搭載時に、代理者からアプリケーション搭載許
可を受け、カードＡにアプリケーションを搭載する。

【００５０】上述した本願発明の第１の形態のシステム
が、具体的にどのように行われるか、図９を参酌して説
明する。即ち、代理署名を行う際の処理シーケンスを説
明する。

【００５１】＜代理署名を行う際の代表的な基本処理シ
ーケンスの例＞カード発行者（３０２）と代理者（９０
１）の間では、お互いの運用ポリシーに基づき提携契約
を結ばれている。提携契約に合意した場合、代理者はカ
ード発行者に自らの非対称鍵公開鍵を送付し、代理者認
証書を要求する（ステップ１２００１）。

【００５２】カード発行者は受け取った公開鍵に対し
て、自らの非対称鍵秘密鍵で署名を行った代理認定証を
代理者に送付する（ステップ１２００２）。

【００５３】次に、カードＡ（１１）へのサービス提供
者Ｂ（８０３）によるアプリケーション搭載する際は、
まず、サービス提供者Ｂが代理者にカードＡに対するア
プリケーション搭載許可要求を行う（ステップ１２００
３）。尚、アプリケーション搭載許可要求の具体例は、
例えば、搭載するアプリケーションのハッシュ値を送付
することである。ハッシュ値とは、当該アプリケーショ
ンに対応した固有のデータ値である。アプリケーション
搭載許可要求を行う場合、必ずしもハッシュ値でなくと
も良いが、ハッシュ値が最も便利であり、多く用いられ
る。

【００５４】代理者は、サービス提供者Ｂから事前に申
請されているアプリケーションの内容を照会し、その正
当性を確認する。前述のハッシュ値を用いる場合、この
正当性の確認は、例えば、サービス提供者Ｂより送付さ
れたハッシュ値と、当該ＩＣカードの内部で発生させた
当該アプリケーションに対応したハッシュ値とを比較す
ることによって行われる。こうしたステップの詳細は後
述される。また、カード発行者よりホットリスト（不正
カード情報あるいはブラックリスト）などカードに関す
る情報が提供されていれば、それをも合わせて確認され
る。

【００５５】代理者は受け取ったアプリケーションのハ
ッシュ値に非対称鍵秘密鍵で代理署名し、代理認定証と
合わせてサービス提供者Ｂに送付する（ステップ１２０
０４）。なお、この秘密鍵は提携契約時にカード発行者
に送付した非対称公開鍵に対応するものである。

【００５６】サービス提供者は受け取った代理署名付き
アプリケーションハッシュ値、代理認定証、アプリケー
ション本体を合わせてカードに送信する（ステップ１２
００５）。

【００５７】カード内には、カード発行時に、カード発
行者の公開鍵が格納されているので、それを用いて代理
認定証の署名検証を行い正当性を確認する。

【００５８】これは、代理者の公開鍵に署名を付与した
ものなので、署名が正しいことを確認した上で、この公
開鍵を用いてアプリケーションのハッシュ値を復号化す
る。それと受け取ったアプリケーションから作成したハ
ッシュ値を比較し同一であれば、アプリケーションをロ
ード・インストールし、アプリケーション搭載完了とな
る。

【００５９】このように本願発明の第１の形態の手順
は、アプリケーションの正当性を代理者が保証し、代理
者の正当性をカード発行者が保証することで、間接的に
カード発行者の保証のもとにアプリケーションを搭載す
る仕組みとなっている。図６に例示したように、カード
発行者とその他プレーヤの間は、提携契約時、代理認定
証の送付のステップがあるが、以降オフラインとなって
おり、通信を確立する必要がない。ただし、提携契約内
容によっては、不正カード情報であるホットリストや各
種運用に必要な情報をカード発行者間でやり取りする場
合もあるが、その場合でも、カード発行者とサービス提
供者との間に通信を直接確立する必要はない。

【００６０】以上説明した代理署名を行う際の基本処理
シーケンスに基づく動作の更なる動作例の詳細を、図１
０から図１４を用いて説明する。即ち、各図は、各々カ
ード、カード発行者、代理者、サービス提供者の各プレ
ーヤ毎の動作フローチャートである。

【００６１】＜ＩＣカード：ＩＣカードでのアプリケー
ション搭載処理の例＞図１０は、代理署名を用いたアプ
リケーション搭載処理を行うＩＣカード側での動作のフ
ローチャートである。

【００６２】カードがアプリケーション搭載処理を開始
する（ステップ１３００１）。

【００６３】ＩＣカードは、サービス提供者より、代理
認定証と代理者が署名したアプリケーション認証書とア
プリケーションを受信する（ステップ１３００２）。こ
のステップは図９のステップ１２００５に対応する。

【００６４】代理認定証はカード発行者により署名され
ている。一方、この代理認定証に対応する鍵がＩＣカー
ド内に格納されており、ＩＣカードは、それを使用して
前記の代理認定証を検証し、代理者の鍵を復号化する
（ステップ１３００３）。

【００６５】復号化した代理者の鍵を用いて、代理者が
署名したアプリケーション認証書の検証を行い、アプリ
ケーションのハッシュ値を取り出す（ステップ１３００
４）。

【００６６】また、ＩＣカードは、送信されたアプリケ
ーションのハッシュ値をカード内で計算し、さきほど復
号化したハッシュ値と同一かどうかを確認する(ステッ
プ１３００５)。

【００６７】これらが同一であれば、ＩＣカードは、カ
ード発行者が認証した正当なアプリケーションだと認
め、これをインストールする（ステップ１３００６）。

【００６８】一方、これらが同一でない場合は、不正な
アプリケーションである可能性があるのでインストール
処理を中止し、その旨をカード外にエラーメッセージで
伝える（ステップ１３００７）。

【００６９】＜カード発行者：カード発行者が代理署名
を用いた事前提携処理を行う処理例＞図１１は、カード
発行者が代理署名を用いた事前提携処理を行う場合のフ
ローチャートである。このステップは図９における、ス
テップ１２００１及び１２００２に対応する。

【００７０】カード発行者は、代理者を認める事前提携
処理をはじめる。

【００７１】カード発行者は、代理認定証を作成するた
め、代理者から公開鍵を受け取る（ステップ１４００
２）。

【００７２】カード発行者は、ＩＣカード内に格納して
ある鍵と、これに対応する鍵でこの公開鍵に署名を行
い、代理者に戻す（ステップ１４００３）。 以上が、
カード発行者―代理者間の事前提携フローである。

【００７３】図１２は代理署名を用いた、代理者の事前
提携処理手順を示すフローチャートである。代理者はカ
ード発行者の代行業務を行うために事前提携処理を行
う。まずカード発行者に代理者の公開鍵を送信し（ステ
ップ１５００２）、カード発行者の署名が付与された代
理認定証を受け取る（ステップ１５００３）。

【００７４】＜代理者：代理署名を用いた、アプリケー
ション搭載処理の例＞図１３は代理署名を用いた、アプ
リケーション搭載処理手順を示すフローチャートであ
る。

【００７５】代理者は、サービス提供者からのアプリケ
ーション搭載要求を受領する（ステップ１６００２）。

【００７６】代理者は、事前に登録されていたアプリケ
ーションの内容やサービス提供者の正当性を確認し、ア
プリケーション搭載を許可できるかどうかを判断する
（ステップ１６００３）。

【００７７】搭載を許可する場合、代理者は、アプリケ
ーション認証書をサービス提供者に送り返す（ステップ
１６００４）。このアプリケーション認証書は、サービ
ス提供者から送られてきたアプリケーションの特徴を示
すデータを、代理者が鍵で暗号化したデータとカード発
行者から事前提携時に受け取っている代理認定証を合わ
せたものである。尚、前記アプリケーションの特徴を示
すデータは、例えば、前述のアプリケーションのハッシ
ュ値などである。

【００７８】搭載不可の場合は、代理者は、その旨をサ
ービス提供者に伝える（ステップ１６００５）。

【００７９】＜サービス提供者：サービス提供者のアプ
リケーション搭載処理の例＞図１４は代理署名を用い
た、サービス提供者のアプリケーション搭載処理手順を
示すフローチャートである。

【００８０】サービス提供者は、代理者に対して、アプ
リケーションの特徴を示すデータ、例えばハッシュ値な
どを送付して搭載許可を要求する（ステップ１７００
２）。

【００８１】サービス提供者は、代理者からアプリケー
ション認証書を受け取り（ステップ１７００３）、アプ
リケーションと合わせてＩＣカードに送信する（ステッ
プ１７００４）。

【００８２】以上が、代理署名方式を利用してＩＣカー
ドにアプリケーションを搭載する場合の処理手順の例で
ある。

【００８３】次に、前記本願発明の第１の形態の機能を
補足する第２の形態の具体例を説明する。前述したよう
に、その形態を要約すると、ＩＣカードが、いわゆる限
定機能付きのセキュリティドメインを有することであ
る。

【００８４】上述のように、代理認定証を渡すことで問
題点は解決したが新たに起こる問題として、一度代理認
定証を発行したら、代理者はそれ以降無制限にアプリケ
ーションを搭載できる権限を持つということがある。Ｉ
Ｃカード上のアプリケーション搭載領域は無限にあるわ
けではなく、また提携契約などは期限を設定して結ばれ
ることが通常であるため、カード発行者にとって「アプ
リケーション1個分の搭載許可権限を与えたい」あるい
は「有効期限を設定した上での搭載許可権限を与えた
い」などの要求を満たす仕組みが望まれる。

【００８５】そこで、本願の第２の形態が提案された。
図１５は「限定機能付きセキュリティドメイン」を用い
る場合の全体構成図である。

【００８６】図１５において、ＩＣカード（１１）、カ
ード発行者（３０２）、代理者（９０１）、サービス提
供者Ｂ（８０３）のプレーヤの役割と関係は図１１と同
様である。カード発行者（３０２）と代理者（９０１）
の間で提携契約を結び、代理者（９０１）がカード発行
者（３０２）の代理としてアプリケーション搭載許可を
行う方式であることは図１１と同じであるが、異なる点
としてアプリケーションを搭載する前に、セキュリティ
ドメインを搭載する必要がある点である。以下の説明で
は、図９の例と異なる点を主に説明し、同じ諸点は説明
を省略する。

【００８７】セキュリティドメインとはカード内で、ア
プリケーション搭載、削除、あるいは管理を行うもので
ある。こうした管理を可能ならしめる前提条件として
は、（１）セキュリティドメイン内部に非対称鍵暗号鍵
を格納することが可能であることと、（２）アプリケー
ションはセキュリティドメインを通してカードに格納さ
れることが挙げられる。セキュリティドメインの具体的
な形態はアプリケーションの場合もあり、ライブラリの
場合もあり、データの場合もある。また、従来はアプリ
ケーション搭載を行う事業者が、セキュリティドメイン
を作成していた。しかし、本願発明では、カード発行者
が作成する。提携契約時にカード発行者（３０２）は代
理者（９０１）に代理者として認める代理者認証書の他
に限定機能付きセキュリティドメインを渡す。カードＡ
にアプリケーションを搭載希望するサービス提供者Ｂは
まずカードＡにセキュリティドメインを搭載するため代
理者のもとにある限定機能付きセキュリティドメインを
受け取りカード内に設定する。その後アプリケーション
搭載許可を代理者から受け取りアプリケーションを前記
セキュリティドメインを通してカード内に格納する。

【００８８】図１６は、代理署名と限定付きセキュリテ
ィドメインの機能を合わせて用い、提携を実現する際の
処理シーケンスを示す図である。

【００８９】カード発行者（３０２）と代理者（９０
１）の間でお互いの運用ポリシーに基づき提携契約を結
ばれている。提携契約に合意した場合、代理者はカード
発行者に自らの非対称鍵公開鍵を送付し代理者認証書を
要求する（ステップ１９００１）。

【００９０】カード発行者（３０２）は受け取った公開
鍵に対して、自らの非対称鍵秘密鍵で署名を行い、代理
者認証書を代理者（９０１）に送付する（ステップ１９
００２）。

【００９１】次にセキュリティドメインに格納する鍵に
関連するやり取りを行う。セキュリティドメインには、
運用時にはカード発行者の鍵と代理者の鍵が格納され
る。まず、代理者（９０１）はセキュリティドメイン用
の非対称鍵のペアを作成し、その秘密鍵をカード発行者
（３０２）に送付する（ステップ１９００３）。

【００９２】但し、秘密鍵の内容はカード発行者を含め
他者には知られてはセキュリティ上問題があるので、秘
密鍵をブラインド化し送付する。カード発行者も同様に
セキュリティドメイン用の非対称鍵のペアを作成し、こ
の秘密鍵を用いて、受け取った代理者のブラインド化し
た秘密鍵に署名を行い、代理者に戻す（ステップ１９０
０４）。

【００９３】これを受け取った代理者はブラインドを解
除する。非対称鍵におけるブラインド署名の方式は既に
知られている技術である。この方式自体は、例えばＲＳ
Ａブラインド署名などが知られている。それは、例え
ば、岡本龍明、山本博資著『シリーズ／情報科学の数学
現代暗号』（産業図書株式会社発行、１９９７）に見
られる。

【００９４】その後、カード発行者（３０２）は、提携
契約に応じた内容の限定条件を設定したセキュリティド
メインを作成し、自らのセキュリティドメイン用公開鍵
をその内部に格納する。もしくは、あらかじめ提携契約
の内容に応じて作成してあったセキュリティドメインに
セキュリティドメイン用公開鍵をセットする。このセキ
ュリティドメインにカード発行者の秘密鍵で署名を行
い、代理者に限定機能付きセキュリティドメインとして
送付する（ステップ１９００５）。こうして、事前提携
時のやり取りは完了する。

【００９５】ここで一つ注意すべき点としては、「カー
ド発行者の鍵」と「代理者の鍵」というそれぞれの非対
称鍵の他に、「カード発行者のセキュリティドメイン用
の鍵」と「代理者のセキュリティドメイン用の鍵」が存
在することが挙げられる。

【００９６】次にアプリケーション搭載時のやり取りに
関して説明する。アプリケーションはセキュリティドメ
インがカード内に設定されていることが前提なので、最
初にセキュリティドメインの搭載方法を説明する。

【００９７】＜セキュリティドメインの搭載方法の例＞
カードＡ（１１）へサービス提供者Ｂ（８０３）のセキ
ュリティドメインを搭載する場合、サービス提供者Ｂの
セキュリティドメインとは、事前提携時にカード発行者
（３０２）から代理者（９０１）へと送付された限定機
能付きセキュリティドメインのことである。代理者（９
０１）は、サービス提供者からのセキュリティドメイン
搭載許可要求を受ける（ステップ１９００６）。

【００９８】限定機能付きセキュリティドメインをサー
ビス提供者Ｂに送付する（ステップ１９００７）。ただ
し、あらかじめセキュリティドメインを配布しておくこ
とも可能なので、ステップ１９００６とステップ１９０
０７に関しては、順序が逆の場合もあり得る。代理者は
ステップ１９００４において受け取りブラインド解除し
てあった署名付き秘密鍵とそれに対応する公開鍵をセキ
ュリティドメイン用鍵ペアとしてサービス提供者Ｂに送
付する（ステップ１９００８）。

【００９９】このセキュリティドメイン用公開鍵は暗号
化や署名はされておらず、サービス提供者Ｂが該セキュ
リティドメインと通信する上での署名検証や、セキュア
な通信確保などに使用する。次にサービス提供者Ｂは限
定機能付きセキュリティドメインをカードに格納する
（ステップ１９００９）。こうして、ＩＣカードは、こ
のセキュリティドメインの正当性を検証する。限定付き
セキュリティドメインは、ステップ１９００５について
の記述にもあるように、カード発行者の鍵の署名が付与
されており、カード内にはカード発行時にカード発行者
の公開鍵が搭載されている。従って、ＩＣカードは、こ
の鍵を用いて当該セキュリティドメインの正当性検証が
可能である。

【０１００】正当性が確認できた場合、サービス提供者
Ｂよりセキュリティドメイン用秘密鍵を受け取り（ステ
ップ１９０１０）、この鍵の正当性を検証する。ステッ
プ１９００４についての記述にもあるように、このセキ
ュリティドメイン用鍵とは、代理者のセキュリティドメ
イン用秘密鍵にカード発行者のセキュリティドメイン用
秘密鍵で署名を行っているものである。カード内に設定
された限定機能付きセキュリティドメインにはカード発
行者のセキュリティドメイン用公開鍵が設定されている
ので、内部で署名の正当性を検証可能である。セキュリ
ティドメイン用鍵の正当性が確認できた場合、鍵は復号
化され代理者のセキュリティドメイン用秘密鍵が限定機
能付きセキュリティドメイン内部に設定される。

【０１０１】ここまでで、限定付きセキュリティドメイ
ンは、ＩＣカードに格納され、鍵も設定されたので機能
し始める。当該セキュリティドメイン内部には （ａ）カード発行者が該セキュリティドメイン用に作成
した公開鍵と （ｂ）代理者が該セキュリティドメイン用に作成した秘
密鍵 とが格納されている。前記（ａ）の項目に対応する秘密
鍵はカード発行者が保持している。また、前記（ｂ）の
項目に対応する公開鍵はサービス提供者Ｂに送付されて
いる。つまり、カード発行者によって作成された限定機
能付きセキュリティドメインは２つの主体者の鍵を保持
し、カードＡ内で機能するのである。

【０１０２】次にカードＡ（１１）へサービス提供者Ｂ
（８０３）によるアプリケーション搭載時の説明を行
う。

【０１０３】まず、サービス提供者Ｂが代理者にカード
Ａに対するアプリケーション搭載許可要求を行う（ステ
ップ１９０１１）。アプリケーション搭載許可要求は、
具体的には、搭載するアプリケーションのハッシュ値を
送付することである。

【０１０４】代理者（９０１）は、サービス提供者（８
０３）と事前に申請されているアプリケーションの内容
を照会しその正当性を確認する。また、カード発行者よ
りホットリスト（不正カード情報・ブラックリスト）な
どカードＡに関する情報が提供されていればそれを確認
する。代理者は受け取ったアプリケーションのハッシュ
値に自らの秘密鍵で代理署名し、ステップ１９００２で
受け取った代理者認証書と合わせてサービス提供者Ｂに
送付する（ステップ１９０１２）。なお、この秘密鍵は
提携契約時にカード発行者に送付した非対称公開鍵に対
応するものである。

【０１０５】サービス提供者Ｂはステップ１９００８で
取得しているセキュリティドメイン用公開鍵でアプリケ
ーションを暗号化しておき、アプリケーション搭載許可
要求の回答として送付されてくる代理署名付きアプリケ
ーションハッシュ値、代理者認証書を、この暗号化した
アプリケーション本体を合わせてカードに送信する（ス
テップ１９０１２）。

【０１０６】カードＡは、以上の情報を限定機能付きセ
キュリティドメインが受け取り、まず代理者認証書の署
名検証を行う。代理者認証書は代理者の公開鍵に対し
て、カード発行者のセキュリティドメイン用秘密鍵で署
名されたもので、限定機能付きセキュリティドメイン内
部には対応する公開鍵が保持されているので、これを用
いて署名検証し、即ち、復号化する。

【０１０７】ここで、復合化が可能ということは、署名
が正しいことを示している。アプリケーションのハッシ
ュ値に代理署名した鍵は、代理者の秘密鍵なので、復号
化した代理者の公開鍵を用いてハッシュ値を復号化して
取り出す。また一方アプリケーションには代理者のセキ
ュリティドメイン用公開鍵で暗号化されているが、限定
機能付きセキュリティドメイン内部にはこれに対応する
秘密鍵が格納されているため、これを用いてアプリケー
ションを復号化し、ハッシュ値をとる。これが先程のハ
ッシュ値と同一であるかを照会し、同一であれば正当な
アプリケーションとしてカードＡ内にロード・インスト
ールし、アプリケーション搭載完了となる（１９０１
３）。

【０１０８】以上の手順は、アプリケーションの正当性
を代理者（９０１）が保証し、代理者の正当性をカード
発行者（３０２）が保証することで、間接的にカード発
行者（３０２）の保証のもとにアプリケーションを搭載
する仕組みとなっている。先に、セキュリティドメイン
に格納されている２つの鍵を、（ａ）カード発行者作成
鍵、（ｂ）代理者作成鍵と記した。

【０１０９】（ａ）の鍵は代理者認証書の検証を行い、
一方（ｂ）の鍵はアプリケーションの検証を行ってい
る。

【０１１０】代理署名のみを使用した仕組みとの違いと
しては、次ぎの事項が挙げられる。 （１）第１は、カード内で正当性を検証する鍵はセキュ
リティドメイン内部に保持されていることである。

【０１１１】（２）第２は、上記の鍵はあらかじめ該セ
キュリティドメイン用にカード発行者と代理者がそれぞ
れ作成したものであることである。

【０１１２】（３）第３は、アプリケーション搭載・削
除・管理や上記鍵の使用は該セキュリティドメイン、も
しくはセキュリティドメイン情報を用いたカードＯＳが
行うことである。

【０１１３】前述したように、アプリケーション搭載、
削除及び管理は、本願発明における限定機能付きセキュ
リティドメインによりコントロールされている。そし
て、それをカード発行者が、提携契約条件に従って作成
していることから、無制限なアプリケーション搭載は避
けることが可能である。代理者が不正に代理署名を行っ
たとしても、本願発明によれば、次ぎの方策が可能であ
る。即ち、提携契約時に、「アプリケーション１つのみ
搭載可能」、「ある日時にまで搭載期限」、「ある容量
を超えて搭載不可能」などの適当な条件を付け、その限
定機能を付けてセキュリティドメインを、作成すれば良
い。カード発行者とその他プレーヤとの間は、提携契約
時以降オフラインとなっていて、カード発行者の意志に
反してカードにアプリケーションが送信されてきても、
カード内の当該セキュリティドメインが搭載を拒否する
ことになる。

【０１１４】以上説明した限定機能付きセキュリティド
メインを用いる際の基本処理シーケンスに基づく動作の
更なる動作例の詳細を、図１７から図２４を用いて説明
する。即ち、各図は、各々ＩＣカード、カード発行者、
代理者、サービス提供者の各プレーヤ毎の動作フローチ
ャートである。本図面で“ＳＤ”記載されているのは本
願発明で提案する限定機能付きセキュリティドメインの
ことであり図面の説明においてもＳＤと表す。

【０１１５】＜ＩＣカード：ＳＤ搭載処理の例＞図１７
は、本発明方式を利用したＳＤ搭載処理を行うカードの
フローチャートである。この処理は、図１９の１９００
９及び１９０１０の両ステップに対応する。

【０１１６】ＩＣカードはサービス提供者からＳＤを受
信する（ステップ２０００２）。

【０１１７】ＳＤは発行者の鍵により署名されているの
で、カード内の対応する鍵を用いて復号化する（ステッ
プ２０００３）。

【０１１８】このＳＤの署名が正しければ、ＳＤをカー
ド内にインストールし（ステップ２００５）、正しくな
い場合はＳＤのインストールを中止しカード外にその旨
を伝える（ステップ２００１０）。

【０１１９】ＳＤをインストールした後は、ＳＤ内に設
定する鍵を受信する（ステップ２０００６）。これはカ
ード発行者のＳＤ用鍵で署名されているが、対応する鍵
がＳＤ作成時に内部に設定されているので、これを用い
て署名を復号化する（ステップ２０００７）。

【０１２０】正しい鍵かどうかを検証し(ステップ２０
００８)、正しければＳＤ内に鍵を設定し(ステップ２０
００９)、不正であれば、ＳＤへの設定を中止しカード
外にその旨を伝える（ステップ２００１１）。

【０１２１】＜ＩＣカード：アプリケーション搭載処理
の例＞図１８は、本願発明方式を利用したアプリケーシ
ョン搭載処理を行うカードのフローチャートである。こ
の処理は、図１６の１９０１３のステップに対応する。

【０１２２】カードはアプリケーション搭載処理を開始
すると（ステップ２１００１）、代理認定証と代理者が
署名したアプリケーション認証書とサービス提供者が持
つＳＤ用鍵で暗号化したアプリケーションをサービス提
供者より受信する（ステップ２１００２）。

【０１２３】代理認定証はカード発行者により署名され
ており対応する鍵がＳＤ内に格納されているので、それ
を使用して代理認定証を検証し、代理者の鍵を復号化す
る（ステップ２１００３）。

【０１２４】復号化した代理者の鍵を用いて、代理者が
署名したアプリケーション認証書の検証を行い、アプリ
ケーションのハッシュ値を取り出す（ステップ２１００
４）。

【０１２５】アプリケーションはサービス提供者により
暗号化されているが、対応する鍵がＳＤ内にあるのでそ
れを用いてアプリケーションを復号化し取り出し（ステ
ップ２１００５）、そのハッシュ値をカード内で計算
し、さきほど復号化したハッシュ値と同一かどうかを確
認する(ステップ２１００６)。

【０１２６】もし、同一であればカード発行者が認証し
た正当なアプリケーションだと認めインストールする
（ステップ２１００７）。

【０１２７】同一でない場合は、不正なアプリケーショ
ンである可能性があるのでインストール処理を中止し、
その旨をカード外にエラーメッセージで伝える（ステッ
プ２１００８）。

【０１２８】＜カード発行者：事前提携処理の例＞図１
９は、カード発行者が、本発明を利用した事前提携処理
を行う場合のフローチャートである。この処理は、図１
６のステップ１９００１より１９００５にかけてのステ
ップである。

【０１２９】カード発行者は、代理者を認める事前提携
処理をはじめると、代理認定証を作成するため代理者か
ら公開鍵を受け取る（ステップ２２００２）。

【０１３０】発行者は、カード内に格納してある鍵と対
応する鍵で、この公開鍵に署名を行い、代理者に戻す
（ステップ２２００３）。

【０１３１】また、ＳＤ格納用の鍵を代理者から受け取
り（ステップ２２００４）、ＳＤ作成時に内部に設定し
てある鍵と対応する鍵で暗号化し代理者に送信する（ス
テップ２２００５）。ＳＤを発行者の鍵で署名し代理者
に送信する（ステップ２２００６）。

【０１３２】＜代理者：事前提携処理の例＞図２０は本
発明を利用した代理者の事前提携処理手順を示すフロー
チャートである。

【０１３３】まずカード発行者に代理者の公開鍵を送信
し（ステップ２３００２）、カード発行者の署名が付与
された代理認定証を受け取る（ステップ２３００３）。

【０１３４】ＳＤ搭載用の鍵を生成し、秘密鍵にブライ
ンド化処理を行いカード発行者に送信する（ステップ２
３００４）。

【０１３５】発行者の署名が付与された上記鍵を受け取
りブラインド化解除処理を行う（ステップ２３００
５）。

【０１３６】発行者の鍵を内部に含むＳＤを発行者より
受け取る（ステップ２３００６）。このＳＤはカード発
行者の鍵により署名が付与されている。

【０１３７】＜代理者：ＳＤ搭載要求受付け処理の例＞
図２１は本発明を利用した代理者のＳＤ搭載要求受付け
処理手順を示すフローチャートである。この処理は、図
１９のステップ１９００６より１９００８のステップに
対応する。

【０１３８】サービス提供者からのＳＤ搭載要求を受信
すると（ステップ２４００２）、発行者から受け取って
ある署名付きＳＤをそのままサービス提供者に送信する
（ステップ２４００３）。

【０１３９】また次に、あらかじめ作成してあったＳＤ
用鍵ペアをサービス提供者に送信する（ステップ２４０
０４）。このＳＤ用秘密鍵は事前提携処理において発行
者に署名を付与されているものである。

【０１４０】＜代理者：アプリケーション搭載要求受付
け処理の例＞図２２は本発明を利用した代理者のアプリ
ケーション搭載要求受付け処理手順を示すフローチャー
トである。

【０１４１】サービス提供者からのアプリケーション搭
載要求を受領すると（ステップ２５００２）、事前に登
録されていたアプリケーションの内容やサービス提供者
の正当性を確認し、アプリケーション搭載を許可できる
かどうかを判断する（ステップ２５００３）。

【０１４２】搭載を許可する場合、サービス提供者から
送られてきたアプリケーションのハッシュ値などアプリ
ケーションの特徴を示すデータを代理者が鍵で暗号化し
たデータとカード発行者から事前提携時に受け取ってい
る代理認定証を合わせてアプリケーション認証書とし
て、サービス提供者に送り返す（ステップ２５００
４）。搭載不可の場合は、その旨をサービス提供者に伝
える（ステップ２５００５）。

【０１４３】＜サービス提供者：ＳＤ搭載処理の例＞図
２３は本発明を利用したサービス提供者のＳＤ搭載処理
手順を示すフローチャートである。

【０１４４】サービス提供者は、ＳＤ搭載を代理者に要
求し（ステップ２６００２）、発行者の署名が付与され
ているＳＤを受け取り（ステップ２６００３）、カード
に送信する（ステップ２６００４）。

【０１４５】カードへのＳＤ設定ができたら、代理者か
らＳＤ用鍵ペアを受け取る（ステップ２６００５）。

【０１４６】カード発行者の署名が付与されているＳＤ
用秘密鍵をカード内のＳＤに送信し設定する（ステップ
２６００６）。

【０１４７】＜サービス提供者：アプリケーション搭載
処理の例＞図２４は、本発明を利用したサービス提供者
のアプリケーション搭載処理手順を示すフローチャート
である。

【０１４８】サービス提供者は、代理者に対してアプリ
ケーションのハッシュ値などを送付して搭載許可を要求
し（ステップ２７００２）、代理者からアプリケーショ
ン認証書を受け取る（ステップ２７００３）。

【０１４９】アプリケーションをＳＤに設定した鍵と対
応する鍵で暗号化し、アプリケーション認証書と合わせ
てカードに送信する（ステップ２７００４）。

【０１５０】以上が、本願発明のアプリケーション搭載
方式に従いＩＣカードにアプリケーションを搭載する場
合の処理手順である。

【０１５１】次に、本願発明を用いて実現可能なＩＣカ
ードの各種利用形態や運用の諸形態について説明する。

【０１５２】図９において、本発明における提案方式で
は９０１の代理者が発行者（３０２）の代行業務を行う
が、この代行業務を３０２とは別の発行者が行えば、カ
ードＡ（１１）には発行者Ａ（３０２）が契約したサー
ビス提供者だけでなく、発行者（９０１）が契約したサ
ービス提供者のアプリケーションをも搭載することが可
能となる。つまり既存の発行者―サービス提供者の仕組
みを組み合わせることで本願発明を利用することが可能
である。

【０１５３】また、発行者間でお互いがお互いの代理者
であれば、双方のカードにどちらのサービス提供者のア
プリケーションが搭載可能となる。本発明方式を利用す
ることで、既存カード運用管理システム間の相互運用が
可能となる。

【０１５４】次に本願発明のカードシステムのいくつか
の具体的な応用例について説明する。

【０１５５】第１の例はテナント業務である。図２５を
用いて、このテナント業務と言う本願発明の応用につい
て説明する。本願明細書におけるテナント業務とは、Ｉ
Ｃカード上の部分領域を、カード発行者以外のテナント
ビジネス事業者に貸与する、即ち、テナント運用する業
務のことを言う。

【０１５６】図２５は、ＩＣカード上の部分領域を運用
する概念を示した図である。

【０１５７】この例では、本願発明に係る代理署名及び
限定機能付セキュリティドメインとを用いて、ＩＣカー
ドに提携業務の関するアプリケーション搭載を行う。

【０１５８】図２５を参酌して本例を説明する。カード
発行者（２８０１）は、ＩＣカード（１１）を発行し、
ＩＣカードに係わる責任を全て負う事業者である。カー
ド発行者（２８０１）は、サービス提供者（２８０２）
やサービス提供者（２８０３）と契約を結び、ＩＣカー
ド（１１）上へ、各々のアプリケーション搭載を許可す
る。更に、本例では、テナントビジネス事業者（２８０
４）がテナントを希望する事業者（２８０５）に、その
アプリケーションの搭載について認証を与える。こうし
て、テナントを希望する事業者（２８０５）は、前記Ｉ
Ｃカード（１１）の提携に係わるアプリケーション領域
にアプリケーションを搭載する。ここで、テナントを希
望する事業者は、これまでの説明におけるサービス提供
者である。又、テナントをビジネスとして行おうとする
事業者は、これまでの説明における代理者である。

【０１５９】ＩＣカード（１１）には、マルチアプリケ
ーション搭載を可能とし、且つ、ダイナミックローディ
ング可能であるカードＯＳ（２８１０）が搭載されてお
り、カード上の機能を実行する。セキュリティドメイン
はカードＯＳ上に設定されており、２８１１はサービス
提供者（２８０２）の、２８１２はサービス提供者（２
８０３）のそれぞれセキュリティドメインである。

【０１６０】サービス提供者（２８０２）はセキュリテ
ィドメイン（２８１１）を通して自らのアプリケーショ
ン（２８１４、２８１５）を搭載する。同様にサービス
提供者（２８０３）はセキュリティドメイン（２８１
２）を通して自らのアプリケーション（２８１６、２８
１７）を搭載する。ここで、代理者（２８０４）と提携
契約を結んでいるサービス提供者（２８０５）がアプリ
ケーションをＩＣカード（１１）に搭載する場合は、限
定機能付きセキュリティドメイン（２８１３）を通して
アプリケーション（２８１８、２８１９）を搭載する構
成となっている。このセキュリティドメイン（２８１
３）はある限定機能を付与されており、自らが搭載した
アプリケーションを管理しているので、図中斜線部分の
領域を考えると、セキュリティドメインにより管理され
ている領域であるといえる。

【０１６１】搭載許可は代理者（２８０４）が行うの
で、この搭載領域は、カード発行者（２８０１）より借
りうけて、サービス提供者（２８０５）などにサービス
提供の場を貸し出している構図となっている。これをビ
ルの所有者からフロアを借り受けて店子を募集するテナ
ントビジネス事業者に対応させると、新しくＩＣカード
上の領域を、テナントして運用するＩＣカードの運用形
態が考えられる。その場合、代理者（２８０４）は、Ｉ
Ｃカードを所有するカード発行者（２８０１）からＩＣ
カード上のある領域を借り受け、その領域上に、サービ
スを提供するサービス提供者（２８０５）と契約する業
務を行う仲介事業者としての機能があれば良い。

【０１６２】以上、本例はＩＣカードの一部の所定領域
を、テナントビジネス事業者にその利用を貸与する利用
形態である。その具体的なアプリケーションの搭載に関
する代理者、サービス提供者の動作については、これま
で説明してきた本願発明の一般的な運用と同様である。

【０１６３】また、図２６ではカード発行者（２９０
１）が契約関係にあるサービス提供者に限定機能付きセ
キュリティドメインを対応させた場合の利用形態につい
て説明する。図２５の例との違いは、カード発行者とサ
ービス提供者（２９０５）との間に代理者（２８０４）
をおかず、カード発行者（２９０１）が、直接契約して
いるサービス提供者（２９０５）であることである。そ
の他の点は前述の例と同様である。

【０１６４】この利用形態の利点は、アプリケーション
搭載のオフライン認証におけるセキュリティを高くする
点である。サービス提供者がアプリケーションを搭載す
る際に、カード発行者へ認証を要求するのが従来一般的
であることは、既に述べた。この場合、要求方法とし
て、ネットワークなどを使用して通信を確立しオンライ
ンで認証してもらう場合と、あらかじめ許可証を大量に
発行してもらうオフライン認証がある。オフライン認証
の場合、カード発行者のＩＣカードへのコントロールが
弱くなる点が問題となっている。しかし、カード上の限
定機能付きセキュリティドメインに制限を設定しておく
ことで、この問題は、コントロール可能となる。また、
契約しているサービス提供者間で差異をつけることが可
能となり、事業者の信頼度に応じた契約締結ができる。

【０１６５】次に、ＩＣカードにおけるバーチャルカー
ドという本願発明のＩＣカードの応用を提案する。

【０１６６】図２７は、バーチャルカードの概念を説明
する図である。バーチャルカ−ドとは、このカードを統
括する第３者の認証の下に、複数のカード発行者による
カードの機能に応ずる各々のアプリケションを、一つの
カードの所定のアプリケーション領域に搭載したカード
の用い方である。従って、一つのカードによって、あた
かも複数のカードを持っているかのようにカードを運用
することが出来る。

【０１６７】図２７において、カードＡ（３００５）、
カードＢ（３００６）、カードＣ（３００７）は、個別
のＩＣカードであり、それぞれのカード発行者は、第３
者（３００１）と提携契約を結んでいる。以下、この第
３者（３００１）を、便宜上バーチャルカード発行者と
呼ぶ。バーチャルカード発行者（３００１）は、カード
Ａ上にアプリケーション搭載領域を借り受けているた
め、バーチャルカード発行者（３００１）と契約の有る
サービス提供者（３００２、３００３、３００４）は搭
載条件さえクリアすれば、カードＡ上にアプリケーショ
ン搭載可能である。バーチャルカード発行者（３００
１）は契約さえ有れば、同様に、カードＢにもカードＣ
にもアプリケーション搭載可能である。つまり、バーチ
ャルカード発行者（３００１）は、実際のカード発行業
務を行っていないにも関わらず、バーチャルカード（３
００８）のような概念上のカードを発行しており、バー
チャルカード発行者（３００１）と契約すればアプリケ
ーション搭載可能なカードと見なすことができる。サー
ビス提供者側から見ると、複数のカードにアプリケーシ
ョンを搭載するために、１つのカード発行者のみと契約
を結び通信を確立すれば良いので大幅手間が省けコスト
削減につながる。

【０１６８】以上、本願諸発明を説明したが、その要点
をまとめると次ぎの通りである。

【０１６９】本願発明は、ＩＣカードのカード発行者の
許可を直接得ることなく、しかしながら同程度の高セキ
ュリティを保持しながらアプリケーションを搭載するこ
とを可能とする。将来、ＩＣカードが普及し、利用数が
増加することに伴い発生するであろう下記の諸難点に関
しては、カード発行者同士の提携契約とそれに伴う情報
のやり取りにより、提携先サービス提供者とカード発行
者が直接通信を確立する必要がなくなったため解決され
る。こうして、本願発明によって、ＩＣカードへの柔軟
なサービス提供が可能となった。尚、上記難点とは、第
１がカード発行者―サービス提供者間に起こる膨大な量
の契約と通信の問題であり、第２が現実的に契約関係を
結べない事業者同士の問題である。

【０１７０】また、解決方法の一つである代理署名を用
いることにより付随して起こる難点として、第１に一度
代理者認証書を発行してしまうと無制限に使用される危
険性、第２に搭載回数、搭載領域など条件を付けた提携
契約を結ぶ必要性を挙げることが出来る。この難点は、
限定機能付きのセキュリティドメインを用いることで回
避することが出来る。

【０１７１】さらに、本願発明のアプリケーションの搭
載方式を利用することで、各種の新しいＩＣカードの利
用形態を可能とした。

【０１７２】こうした新しいＩＣカードの利用形態の例
を列挙すれ、下記の通りである。（１）既存システムへ
の応用方式、（２）発行者間で相互に代行業務を行うこ
とによる相互運用方式、（３）ＩＣカード上の領域を借
り受け運用するテナント事業、（４）カード発行者によ
るサービス提供者間のアプリケーション搭載における差
異の設定、（５）バーチャルカード発行事業。

【０１７３】本願は、その形態が多岐に渡るので、以下
に主な形態、あるいは概念を整理し、列挙する。

【０１７４】その第１は、非対称暗号化機能を有するＩ
Ｃカードを利用した署名生成及び検証方式において、Ｉ
Ｃカード発行者がＩＣカードにみずからの公開鍵を格納
し利用者に配布するステップと、ＩＣカード発行者が第
３者（以降代理者と呼ぶ）の公開鍵を受け取り、カード
発行者の秘密鍵で署名を付与し代理者に戻すステップ
と、代理者が自らの秘密鍵でデータに署名を付与するス
テップと、代理者が前記カード発行者より受け取ったカ
ード発行者署名付き代理者公開鍵とそのデータを合わせ
てカードに送信するステップと、カード内のカード発行
者公開鍵で前記付与したカード発行者署名付き代理者公
開鍵を検証するステップと、この代理者公開鍵でデータ
の署名を検証し正当性を確認するステップを有すること
を特徴とする署名生成及び検証方式である。

【０１７５】第２は、ＩＣカード発行者がＩＣカードに
自らの公開鍵を格納し利用者に配布するステップと、発
行者が代理者の公開鍵を受け取り、自らの秘密鍵で署名
し代理認定証として渡すというステップと、アプリケー
ションをカードに発行する業務を行う事業主体者（以降
サービス提供者と呼ぶ）がアプリケーションのハッシュ
値などアプリケーションの特徴を示すデータを代理者に
渡すというステップと、代理者は渡されたアプリケーシ
ョンのハッシュ値などに代理者の秘密鍵で署名を行うス
テップと、上記署名付きハッシュ値と発行者より渡され
ている代理認定証を合わせてアプリケーション認証書と
してサービス提供者に戻すというステップと、サービス
提供者がアプリケーションとアプリケーション認証書を
合わせてカードに搭載するというステップと、カード内
の発行者公開鍵により代理認定証を検証するステップ
と、上記検証された代理者の公開鍵によりカード内でア
プリケーションのハッシュ値を検証するステップと、カ
ード内でアプリケーションのハッシュ値を計算するステ
ップと、検証されたハッシュ値と計算されたハッシュ値
を比較することでアプリケーションの正当性を確認する
ステップを有することを特徴とするアプリケーション搭
載方式である。

【０１７６】第３は、ＩＣカード内でアプリケーション
の搭載・削除・管理機能を行うアプリケーションもしく
はデータ（以降セキュリティドメインと呼ぶ）であっ
て、カード発行者により作成され、アプリケーション搭
載に関する所定の制限がカード発行者により設定可能で
あり、内部に発行者の公開鍵が格納されている状態で代
理者に渡され、代理者によりサービス提供者に渡され、
サービス提供者によりカード内に搭載され、その後サー
ビス提供者により当該セキュリティドメイン内に代理者
の秘密鍵を設定され、アプリケーション搭載時に当該セ
キュリティドメイン内のカード発行者の公開鍵により代
理者の公開鍵の署名を検証し、上記代理者の公開鍵を用
いてアプリケーションのハッシュ値の署名を検証しアプ
リケーションの正当性を確認することを特徴とするＩＣ
カード内でアプリケーションの搭載・削除・管理機能を
行うセキュリティドメインである。

【０１７７】第４は、前記署名生成及び検証方式と、前
記セキュリティドメインを利用したＩＣカードへのアプ
リケーション搭載方式である。即ち、発行者が代理者に
代理認定証と所定の制限を設定したセキュリティドメイ
ンを代理者に渡すステップと、代理者がサービス提供者
に、上記セキュリティドメインとセキュリティドメイン
用の鍵を渡すステップと、サービス提供者が、該セキュ
リティドメインをカードに格納し、鍵を設定するステッ
プと、サービス提供者が、代理者にアプリケーション認
証書を要求し受け取るステップと、サービス提供者が上
記アプリケーション認証書をアプリケーションを合わせ
てカードに搭載するステップと、カード内でアプリケー
ション認証書を検証しアプリケーションの正当性を確認
するステップを有することを特徴とするアプリケーショ
ン搭載方式である。

【０１７８】第５は、セキュリティドメインをサービス
提供者から受け取り格納する手段と、サービス提供者に
より該セキュリティドメイン内に鍵を設定する手段と、
アプリケーション搭載時にアプリケーションに付与され
たアプリケーション認証書を検証する手段と、アプリケ
ーションをインストールする手段を有することを特徴と
するアプリケーション搭載可能のＩＣカードである。

【０１７９】第６は、自ら以外の第３者である代理者か
ら渡された公開鍵を受け取り、自らの秘密鍵で署名を付
与し代理認定証として代理者に戻し、セキュリティドメ
インを作成・条件設定した上で代理者に渡すことを特徴
とするＩＣカード発行者である。

【０１８０】第７は、ＩＣカードの発行管理業務の一部
を代行する事業者（代理者）であり、自らの公開鍵を発
行者に渡し、発行者の秘密鍵により署名をされた代理認
定証を受け取り、発行者からセキュリティドメインを受
け取り、サービス提供者に該セキュリティドメインとセ
キュリティドメイン用鍵を渡し、サービス提供者からア
プリケーションのハッシュ値などアプリケーションの特
徴を示すデータを受け取り、それに自らの秘密鍵で署名
を付与しそれと代理認定証を合わせてアプリケーション
認証書としてサービス提供者に戻すことを特徴とする事
業主体者である。

【０１８１】第８は、代理者からセキュリティドメイン
とセキュリティドメイン用鍵を受け取り、カード内にセ
キュリティドメインを格納し、鍵を設定し、カードに搭
載するアプリケーションのハッシュ値などアプリケーシ
ョンの特徴を示すデータを、該カードの発行者の代行業
務を行う代理者に送信し、代理者からの代理認定証と代
理者の秘密鍵で署名を付与されたアプリケーションのハ
ッシュ値などをアプリケーション認証書として受け取
り、アプリケーション認証書とアプリケーションを合わ
せてカードに送信することを特徴とするサービス提供者
である。

【０１８２】第９は、前記事業主体者が同時にカード発
行管理業務も行い、自らが発行するカードへのアプリケ
ーション認証書の他に、代理認定証を渡されている発行
者の発行したカードへのアプリケーション認証書を発行
することが可能であることを特徴とするカード発行者間
のカード相互運用方式である。

【０１８３】第１０は、カードを発行管理する発行者同
士が双方とも前記代理者であることにより、発行者は双
方の発行するカードに搭載するアプリケーションの認証
書を発行することが可能であることを特徴とするカード
発行者間のカード相互運用方式である。

【０１８４】第１１は、ＩＣカード上の部分領域の運用
を行い、カード発行者に対してはＩＣカード上の部分領
域を借り受けていることへの対価を支払い、サービス提
供者に対してはアプリケーション搭載に対する課金や問
い合わせなどへのサポート業務を行うことの対価を要求
することを特徴とする業務である。

【０１８５】第１２は、セキュリティドメインの機能を
使用したＩＣカードへのアプリケーション搭載方式であ
って、サービス提供者は該セキュリティドメインを通し
てのみアプリケーション搭載可能であり、該セキュリテ
ィドメインに設定される条件はカード発行者がサービス
提供者との契約内に応じて設定し、同一カード上で、サ
ービス提供者毎の条件よりアプリケーション搭載条件が
異なることを特徴とするアプリケーション搭載方式であ
る。

【０１８６】第１３は、代理者が複数のＩＣカード発行
者の代理者であり、サービス提供者からのアプリケーシ
ョン搭載要求を代理者が受け取り、上記複数カード発行
者からの代理認定証を複数付与したアプリケーション認
証書を発行し、サービス提供者が該アプリケーション認
証書を受け取ることで複数カードへのアプリケーション
搭載が可能となることを特徴としているＩＣカード発行
管理代行業務である。

【０１８７】第１４は、当該ＩＣカ−ドを発行したＩＣ
カ−ド発行者が署名した代理者の公開鍵と、代理者が署
名したアプリケ−ションとを受け取る手段と、代理者の
公開鍵に付与されたＩＣカ−ド発行者の署名を検証する
手段と、上記代理者の公開鍵によりアプリケ−ションの
署名を検証する手段と、を有するアプリケ−ション搭載
可能なＩＣカ−ドである。

【０１８８】第１５は、ＩＣカ−ドの発行管理業務を行
うＩＣカ−ド発行者であり、自ら以外の第３者である代
理者から渡された公開鍵を受け取り、自らの秘密鍵で署
名を付与し、これを代理認定証として代理者に戻すＩＣ
カ−ド発行者である。

【０１８９】第１６は、ＩＣカ−ドの発行管理業務の一
部を代行する事業者（代理者）であり、自らの公開鍵を
発行者に渡し、発行者の秘密鍵により署名をされた代理
認定証を受け取り、サ−ビス提供者からアプリケ−ショ
ンの、例えば、ハッシュ値などのアプリケ−ションの特
徴を示すデ−タを受け取り、それに自らの秘密鍵で署名
を付与し、それと代理認定証を合わせてアプリケ−ショ
ン認定証としてサ−ビス提供者に戻すことを特徴とする
アプリケ−ション搭載を実施する事業主体者である。

【０１９０】第１７は、アプリケ−ションをカ−ドに発
行する業務を行う事業主体者（サ−ビス提供者）であ
り、ＩＣカ−ドに搭載するアプリケ−ションのハッシュ
値などアプリケ−ションの特徴を示すデ−タを、前記Ｉ
Ｃカ−ドの発行者の代行業務を行う代理者に送付し、代
理者からの代理認定証と代理者の秘密鍵で署名を付与さ
れたアプリケ−ションのハッシュ値などをアプリケ−シ
ョン認定書として受け取り、アプリケ−ション認定書と
アプリケ−ションを合わせてカ−ドに送信するアプリケ
−ション搭載を実施するサ−ビス提供者である。

【０１９１】

【発明の効果】本願発明の第１の形態は、ＩＣカードの
カード発行者の許可を直接得ることなく、カード発行者
の許可を得る場合と同程度の高セキュリティを保持しな
がら、当該ＩＣカードにアプリケーションを搭載するこ
とを可能とする。加えて、本願発明の第１の形態は膨大
なの契約と通信の量の増大に基づく、現実的各種処理の
煩雑さを解消する。

【０１９２】本願発明の第２の形態は、ＩＣカードのカ
ード発行者の許可を直接得ることなく、ＩＣカードにア
プリケーションを搭載する場合に付随して生ずるアプリ
ケーションの搭載の無制限性の難点を回避する。

【図面の簡単な説明】

【図１】図１はＩＣカードの基本構成を示す図である。

【図２】図２はＩＣカードの発行、サービス提供に関す
るこれまでのシステム構成の例である。

【図３】図３はセキュリティドメイン機構を持つＩＣカ
ードの基本構成を示す図である。

【図４】図４は従来のアプリケーション搭載の為のシー
ケンスの例を示す図である。

【図５】図５は従来方式における難点を説明する為の図
である。

【図６】図６は本願発明におけるＩＣカード、発行者、
代理者、及びサービス提供者の関係を示す図である。

【図７】図７は本願発明のシステムの基本的な構成を示
す図である。

【図８】図８は代理署名を行う場合のＩＣカード、発行
者、代理者、及びサービス提供者の関係を示す図であ
る。

【図９】図９は代理署名による提携を実現するシーケン
スを示す図である。

【図１０】図１０は、ＩＣカードにアプリケーションを
搭載する為の本願発明に係わるシーケンスを示す図であ
る。

【図１１】図１１は、カード発行者が事前提携を行う為
の本願発明に係わるシーケンスを示す図である。

【図１２】図１２は代理者が事前提携を行う為の本願発
明に係わるシーケンスを示す図である。

【図１３】図１３は代理者がアプリケーションの搭載を
行う為の本願発明に係わるシーケンスを示す図である。

【図１４】図１４はサービス提供者がアプリケーション
の搭載を行う為の本願発明に係わるシーケンスを示す図
である。

【図１５】図１５はセキュリティドメインを有するＩＣ
カードの基本構成を示す図である。

【図１６】図１６は代理署名及びセキュリティドメイン
を用いた提携を実現する為の本願発明のシーケンスを示
す図である。

【図１７】図１７はＩＣカードにＳＤを搭載する為の本
願発明のシーケンスを示す図である。

【図１８】図１８はＩＣカードにアプリケーションを搭
載する為の本願発明のシーケンスを示す図である。

【図１９】図１９はカード発行者が事前提携を行う為の
本願発明に係わるシーケンスを示す図である。

【図２０】図２０は代理者が事前提携を行う為の本願発
明に係わるシーケンスを示す図である。

【図２１】図２１は代理者がＳＤを搭載する為のシーケ
ンスを示す図である。

【図２２】図２２は代理者がアプリケーションの搭載を
行う為の本願発明に係わるシーケンスを示す図である。

【図２３】図２３はサービス提供者がＳＤの搭載を行う
為の本願発明に係わるシーケンスを示す図である。

【図２４】図２４はサービス提供者がアプリケーション
の搭載を行う為の本願発明に係わるシーケンスを示す図
である。

【図２５】図２５は本願発明を用いたテナント例を示す
図である。

【図２６】図２６は本願発明を用いた制限付きサービス
の提供契約を行う例を説明する図である。

【図２７】図２７は本願発明を用いたバーチャルカード
の例を説明する図である。

【図２８】図２８はカード・システムの概要を示す図で
ある。

【符号の説明】

１１：ＩＣカード、１０１：ＩＣカード内ハードウェア
層 １０２：ＩＣカード内ＯＳ層、１０６：ＩＣカード内ア
プリケーション １０７：ＩＣカード内アプリケーション層、１０８：セ
キュリティドメイン、３０２：カード発行者サーバ、３
０３：サービス提供者サーバ ３０４：クライアント側用外部端末、３０５：カード発
行者データベース、３０６：サービス提供者データベー
ス、８０１、８０２：アプリケーション、８０４、８０
５：セキュリティドメイン、８０３：サービス提供者、
９０１：代理者、９０２：代理者のデータベース、２８
０１：カード発行者、２８０２、２８０３：サービス提
供者、２８０４：代理者＝テナントビジネス事業者、２
８０５：サービス提供者＝テナント希望事業者、２８１
０：カードＯＳ、２８１１、２８１２：セキュリティド
メイン、２８１３：限定機能付きセキュリティドメイン ２８１４〜２８１９：アプリケーション、２９０１：カ
ード発行者 ２９０２、２９０３、２９０５：サービス提供者 ２９０４、２９１０：カードＯＳ ２９１１、２９１２：セキュリティドメイン ２９１３：限定機能付きセキュリティドメイン ２９１４〜２９１９：アプリケーション ３００１：バーチャルカード発行者 ３００２〜３００４：サービス提供者、３００５〜３０
０７：ＩＣカード、３０ ０９〜３０１１：提携先の搭載領域。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０９Ｃ 1/00 ６４０ Ｇ０６Ｆ 9/06 ６６０Ａ ６６０ Ｇ０６Ｋ 19/00 Ｎ (72)発明者 大木 優 東京都国分寺市東恋ヶ窪一丁目280番地 株式会社日立製作所中央研究所内 (72)発明者 馬場 里美 東京都国分寺市東恋ヶ窪一丁目280番地 株式会社日立製作所中央研究所内 (72)発明者 松井 隆 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所内ビジネスソリューション 開発本部内 Ｆターム(参考） 2C005 NA02 NA06 SA02 SA05 SA08 SA23 5B035 AA13 BB09 CA11 CA38 5B058 CA25 KA11 KA33 5B076 FA13 FB02 5J104 AA09 LA03 LA06 NA02 NA12 NA35 NA37 NA40

Claims (21)

【特許請求の範囲】
1. 【請求項１】 第２の機関が、少なくとも、ＩＣカード
   発行に係わる第１の機関を特徴づけ且つサービス提供の
   為に持ちいる第１の特徴情報、及び当該第２の機関の第
   ２の特殊情報とを、サービス情報提供に係わる第３の機
   関に提供が可能であり、 前記サービス情報提供に係わる第３の機関は、少なくと
   も、所望のアプリケーションと、前記ＩＣカード発行に
   係わる第１の機関を特徴づけ且つサービス提供の為に持
   ちいる第１の特徴情報と、当該第２の機関を特徴づける
   ところの第２の特殊情報と、をＩＣカードに提供が可能
   なことを特徴とするＩＣカードシステム。
2. 【請求項２】 第２の機関が、少なくとも、ＩＣカード
   発行に係わる第１の機関を特徴づけ且つサービス提供の
   為に持ちいる第１の特徴情報、及び当該第２の機関の第
   ２の特殊情報と、サービス情報のＩＣカードへの格納に
   関する条件を、サービス情報提供に係わる第３の機関に
   提供が可能であり、 前記サービス情報提供に係わる第３の機関は、少なくと
   も、アプリケーションと、前記第１の特徴情報と、前記
   第２の機関を特徴づけるところの第２の特徴情報と、前
   記アプリケーションのＩＣカードへの格納に関する条件
   と、前記格納条件に係わる第３の特徴情報と、をＩＣカ
   ードに提供が可能なことを特徴とするＩＣカードシステ
   ム。
3. 【請求項３】 第３者機関が、当該第３者機関がＩＣカ
   ードの発行機関によってその代理であることを認定され
   たことを示す情報と、 当該ＩＣカードに搭載する所定の搭載情報を特徴づける
   第１の固有情報に当該第３者機関が代理の署名を行った
   情報と、をサービス提供に係わる第３の機関に提供し、 前記サービス提供に係わる第３の機関が、 少なくとも、 当該搭載情報と、 前記所定の搭載情報を特徴づける第１の固有情報に、当
   該第３者機関が代理の署名を行った情報と、 当該第３者機関がＩＣカードの発行機関によってその代
   理であることを認定されたことを示す情報と、をＩＣカ
   ードに送信することが可能なことを特徴とするＩＣカー
   ドシステム。
4. 【請求項４】 少なくとも、所望のアプリケーションを
   搭載することが出来る領域と、オペレーション・システ
   ム領域とを有し、 第３者機関がＩＣカードの発行機関によってその代理で
   あることを認定されたことを示す情報と、 アプリケーションと、 前記アプリケーションを特徴づける固有情報に、前記第
   ３者機関が代理の署名を行った情報と、を受け取る手段
   と、 且つ前記第３者機関を特徴づける固有情報に付与された
   前記ＩＣカードの発行機関の署名を検証することが可能
   な手段と、 前記アプリケーションを特徴づける固有情報に付与され
   た第３者機関が代理の署名を検証することが可能な手段
   とを有すること、を特徴とするＩＣカード。
5. 【請求項５】ＩＣカ−ドの発行機関によって、第３者機
   関がその代理であることを認定されたことを示す情報
   を、前記第３者機関が受信するステップと、 前記第３者機関が、当該第３者機関を特徴付ける固有情
   報をブラインド化した情報を、ＩＣカードの発行機関に
   送信するステップと、 前記第３者機関が、ＩＣカードの発行機関から受領した
   をサービス情報の提供機関に送付するステップと、 前記サービス情報の提供機関が、サービス情報を、前記
   第１の固有情報と、当該第３者機関の秘密鍵と、前記第
   ３者機関の公開鍵及び当該ＩＣカードの発行機関の秘密
   鍵と共に、格納されるサービス情報に所定の制限を与え
   る固有情報が格納されたＩＣカードに、格納されるサー
   ビス情報に所定の制限を与えるこの固有情報が格納され
   た領域を経由して、入力するステップと、 前記格納されるサービス情報に所定の制限を与えるこの
   固有情報に基づいて、前記サービス情報が格納されるべ
   きもであることを確認するステップと、を有することを
   特徴とするＩＣカードシステム。
6. 【請求項６】 第３者機関が、第３者機関の公開鍵に、
   当該第３者機関の公開鍵をＩＣカードの発行機関の秘密
   鍵を用いて暗号化した情報を付与した情報と、 当該ＩＣカードに搭載する所定の搭載情報を特徴づける
   第１の固有情報に、前記所定の搭載情報を特徴づける第
   １の固有情報を当該第３者機関の秘密鍵を用いて暗号化
   した情報を付与した情報と、 をサービス提供に係わる第３の機関に提供し、 前記サービス提供に係わる第３の機関が、 少なくとも、 当該搭載情報と、 前記所定の搭載情報を特徴づける第１の固有情報に、当
   該所定の搭載情報を特徴づける第１の固有情報を当該第
   ３者機関の秘密鍵を用いて暗号化した情報を付与した前
   記情報と、 第３者機関の公開鍵に、当該第３者機関の公開鍵をＩＣ
   カードの発行機関の秘密鍵を用いて暗号化した情報を付
   与した情報を付与した情報と、をＩＣカードに送信する
   ことが可能なことを特徴とするＩＣカードシステム。
7. 【請求項７】 前記第１の固有情報が、サービス情報の
   ハッシュ関数であることを特徴とする請求項６に記載の
   ＩＣカードシステム。
8. 【請求項８】 少なくとも、所望のアプリケーションを
   搭載することが出来る領域と、オペレーション・システ
   ム領域とを有し、 第３者機関の公開鍵に、第３者機関の公開鍵を前記カー
   ドの発行機関の秘密鍵を用いて暗号化した情報を付与し
   た情報と、 アプリケーションと、 当該アプリケーションを特徴づける固有情報に、当該ア
   プリケーションの固有情報を前記第３者機関の秘密鍵を
   用いて暗号化した情報を付与した情報と、を受け取る手
   段と、 前記カードの発行機関の秘密鍵を検証する手段と、且つ
   前記第３者機関の公開鍵に基づいて前記アプリケーショ
   ンの固有情報を検証する手段を有することを特徴とする
   ＩＣカード。
9. 【請求項９】 第３者機関の公開鍵を受信し、 この第３者機関の公開鍵に、この第３者機関の公開鍵を
   ＩＣカードの発行機関の秘密鍵を用いて暗号化した情報
   を付与した情報を、前記第３者機関に送信することが可
   能なことを特徴とするＩＣカード発行システム。
10. 【請求項１０】 ＩＣカードへのサービス情報の提供機
    関よりの所定のサービス情報を特徴づける第１の固有情
    報を受領し、 前記第１の固有情報に、前記第１の固有情報を当該カー
    ドシステムの秘密鍵を用いて暗号化した情報を付与した
    情報と、 当該カードシステムの公開鍵に、当該カードシステムの
    公開鍵を当該ＩＣカードの発行機関の秘密鍵を用いて暗
    号化した情報を付与した情報とを、前記ＩＣカードへの
    サービス情報の提供機関に送信することが可能なカード
    システム。
11. 【請求項１１】 所定のサービス情報を特徴づける第１
    の固有情報を第３者機関に送信が可能であり、 且つ前記第１の固有情報に、前記第１の固有情報を当該
    第３者機関の秘密鍵を用いて暗号化した情報を付与した
    情報と、 前記第３者機関の公開鍵と、前記第３者機関の公開鍵を
    ＩＣカードの発行機関の秘密鍵を用いて暗号化した情報
    を付与した情報とを受信し、 少なくとも、 当該搭載情報と、 前記所定の搭載情報を特徴づける第１の固有情報に、当
    該所定の搭載情報を特徴づける第１の固有情報を当該第
    ３者機関の秘密鍵を用いて暗号化した情報を付与した前
    記情報と、 第３者機関の公開鍵に、当該第３者機関の公開鍵をＩＣ
    カードの発行機関の秘密鍵を用いて暗号化した情報を付
    与した情報を付与した情報と、をＩＣカードに送信が可
    能なことを特徴とするサービス提供システム。
12. 【請求項１２】 第３者機関が、ＩＣカ−ドの発行機関
    の代理が可能なことを認定する情報を受信するステップ
    と、 前記第３者機関が、前記第３者機関に対応するブライン
    ド化した固有情報を、ＩＣカードの発行機関に送信する
    ステップと、 前記第３者機関が、ＩＣカードの発行機関から受領した
    ところの、格納されるサービス情報に所定の制限を与え
    る固有情報を機能せしめるところの情報をサービス情報
    の提供機関に送付するステップと、 前記サービス情報の提供機関が、少なくとも、サービス
    情報を、前記第１の固有情報に前記第１の固有情報を、
    第３者機関の秘密鍵を用いて暗号化した情報を付与した
    情報と、前記第３者の公開鍵の公開鍵と、前記第３者機
    関の公開鍵をＩＣカ−ドの発行機関の秘密鍵で暗号化し
    た情報を付与した情報と共に、格納されるサービス情報
    に所定の制限を与える固有情報が格納されたＩＣカード
    に、格納されるサービス情報に所定の制限を与えるこの
    固有情報を機能せしめつつ、入力するステップと、 前記格納されるサービス情報に所定の制限を与えるこの
    固有情報に基づいて、前記サービス情報が格納されるべ
    きもであることを確認するステップと、を有することを
    特徴とするＩＣカードシステム。
13. 【請求項１３】 前記格納されるサービス情報に所定の
    制限を与えるこの固有情報が、搭載容量、搭載回数、搭
    載するサービス情報の個数、サービス情報の搭載可能な
    有効期間の群から選ばれた少なくとも１者であることを
    特徴とする請求項１２に記載のＩＣカードシステム。
14. 【請求項１４】 アプリケションと、このアプリケショ
    ンの格納に関する条件との格納が可能であり、前記アプ
    リケションの格納に所定の条件に基づき、前記アプリケ
    ションの格納に関する条件に対する鍵情報を設定し、且
    つ前記アプリケションに付与された特徴情報を確認する
    ことが可能なことを特徴とするＩＣカード。
15. 【請求項１５】 第３者機関の公開鍵を受信し、この第
    ３者機関の公開鍵に、この第３者機関の公開鍵をＩＣカ
    ードの発行機関の秘密鍵を用いて暗号化した情報を付与
    した情報を前記第３者機関に送信が可能であり、 且つ前記第３者機関の要請に応じて、前記第３者機関の
    ブラインド化した秘密鍵を受信し、この第３者機関のブ
    ラインド化した秘密鍵に、当該ＩＣカードの発行機関の
    秘密鍵を用いて暗号化した情報を付与した情報と、所望
    のアプリケーションの格納に関する条件とを前記第３者
    機関に送信が可能であることを特徴とするＩＣカードの
    発行システム。
16. 【請求項１６】 サービス情報の格納に関する条件を受
    信し、 且つサービス情報の格納に関する条件と、前記第３者機
    関の秘密鍵と、前記第３者機関の秘密鍵にＩＣカードの
    発行機関の秘密鍵を用いて暗化した情報を付与した情報
    とを、前記サ−ビス情報を提供する機関に送信が可能で
    あり、 且つサービス情報に対する固有情報に、前記サービス情
    報に対する固有情報を当該カードシステムの秘密鍵によ
    って暗号化した情報を付与した情報と、 当該カードシステムの公開鍵に、当該カード・システム
    の公開鍵を当該ＩＣカードの発行機関の秘密鍵を用いて
    暗号化した情報を付与した情報と、を前記サービス情報
    を提供する機関に送信することが可能なことを特徴とす
    るカードシステム。
17. 【請求項１７】 所定のサービス情報に固有に定められ
    た第１の固有情報を第３者機関に送信が可能であり、且
    つ少なくとも前記第１の固有情報と、前記第３者機関の
    秘密鍵に、前記第３者機関の秘密鍵を当該ＩＣカ−ドの
    発行システムの秘密鍵を用いて暗号化した情報を付与し
    た情報と、前記第３者機関の公開鍵に前記第３者機関の
    公開鍵を当該ＩＣカードの発行システムの秘密鍵を用い
    て暗号化した情報を付与した情報とを受信し、 少なくとも前記第１の固有情報と、少なくとも当該第３
    者機関の秘密鍵に、前記第３者機関の秘密鍵を当該ＩＣ
    カ−ドの発行システムの秘密鍵を用いて暗号化した情報
    を付与した情報と、前記第３者機関の公開鍵に、前記第
    ３者機関の公開鍵を前記ＩＣカードの発行機関の秘密鍵
    を用いて暗号化した情報を付与した情報と、を前記ＩＣ
    カードに送信が可能なことを特徴とするサービス提供シ
    ステム。
18. 【請求項１８】 第１の機関が、当該第１の機関が発行
    するＩＣカードに対するアプリケーションの搭載を許可
    する情報の発信が可能であり、且つ少なくとも、前記第
    １の機関とは別異の第２の機関の代行が可能であること
    を示す情報と、前記第２の機関が発行したＩＣカードに
    対するアプリケーションの搭載を許可する情報との発信
    をも可能であることを特徴とするＩＣカードシステム。
19. 【請求項１９】 少なくとも、第１の機関が、前記第１
    の機関とは別異の第２の機関に、当該第１の機関の代行
    が可能であることを示す情報の提供が可能であり、前記
    第２の機関が、前記第１の機関に、当該第２の機関の代
    行が可能であることを示す情報の提供が可能であり、 前記第１の機関が、当該第１の機関が発行するＩＣカー
    ドに対するアプリケーションの搭載を許可する情報の発
    信が可能であり、且つ少なくとも、前記第２の機関の代
    行が可能であることを示す情報と、前記第２の機関が発
    行したＩＣカードに対するアプリケーションの搭載を許
    可する情報との提供が可能であり、且つ前記第２の機関
    が、当該第２の機関が発行するＩＣカードに対するアプ
    リケーションの搭載を許可する情報の提供が可能であ
    り、且つ少なくとも、前記第１の機関の代行が可能であ
    ることを示す情報と、前記第１の機関が発行したＩＣカ
    ードに対するアプリケーションの搭載を許可する情報と
    の提供が可能であることを特徴とするＩＣカードシステ
    ム。
20. 【請求項２０】 ＩＣカードへのアプリケーション提供
    機関は、ＩＣカードが有するアプリケーションの格納に
    関する条件に規制されて当該アプリケーションのＩＣカ
    ードへの格納が可能であり、且つ当該ＩＣカードは複数
    の当該アプリケーションの格納に関する条件及びこれに
    対する複数のアプリケーションとを格納することが可能
    であり、且つ前記アプリケーションの格納に関する条件
    は前記ＩＣカードへのアプリケーションの提供システム
    とは別異の機関により提供された条件であることを特徴
    とするアプリケーションの搭載方法。
21. 【請求項２１】 第３者機関が複数のＩＣカードの発行
    機関よりその代行が可能なことを示す情報の提出が可能
    であり、前記第３者機関は、複数サービス提供者の少な
    くとも１者からのアプリケーションの搭載の要求を前記
    第３者機関が受領し、前記ＩＣカードの発行機関の代行
    が可能なことを示す情報と要求を受けたアプリケーショ
    ンの搭載を許可する情報とを前記要求を提出したサービ
    ス提供者に提供し、当該サービス提供者は前記ＩＣカー
    ドの発行機関の代行が可能なことを示す情報と要求を受
    けたアプリケーションの搭載を許可する情報とを受領
    し、所望のアプリケーションの提供が可能なことを特徴
    とするＩＣカードシステム。