(57)【要約】【課題】ICカードへのAP搭載可否判定処理の際、ICカード運用管理システムが、外部システムに提供する情報を必要最小限に抑え、かつ、提供フォーマットを動的に選択可能とする。【解決手段】コレータシステム（１０３）は利用者（１１１）からのAP搭載可否判定要求を受付け、カードポリシをカード発行管理システム（１０１）から、APポリシをサービス提供管理システム（１０２）から取得する。次に判定に必要なカード関連情報を１０１に、AP関連情報を１０２に要求する。また提供フォーマットとして定義フォーマット（１０４）もしくはその参照情報を指定する。１０１及び１０２は、既存情報（２２２、２３２）から要求情報を抽出し、マッピング規則情報（２２３、２３３）を用いて指定された１０４に変換し１０３に送信する。１０３は取得したポリシとプロファイルを用いてAP搭載可否判定し、結果を利用者に提示する。【選択図】図２
2005182435.tif 000002
【特許請求の範囲】
【請求項１】
ＩＣカードリーダライタを介しＩＣカードに接続し、
ネットワークまたは専用線を介し、ＩＣカード発行業務を行い且つ前記ＩＣカードの属性情報を所定のフォーマットで保存するカード発行管理データベースを有するカード発行管理システムに接続し、
前記ネットワークまたは前記専用線を介し、ＩＣカードのアプリケーションによるサービス提供業務を行い且つ前記アプリケーションの属性情報を所定のフォーマットで保存するサービス提供管理データベースを有するサービス提供管理システムとに接続するコレータシステムであって、
前記ＩＣカードへの前記アプリケーションの搭載要求を受け、
前記カード発行管理システムが前記アプリケーションの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるカードポリシを、前記カード発行管理システムへ要求、取得し、
前記サービス提供管理システムが前記ＩＣカードの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるアプリケーションポリシを、前記サービス提供管理システムへ要求、取得し、
前記サービス提供管理システムへ、前記カードポリシの判定に必要な前記アプリケーションの属性情報の項目と、前記カードポリシが指定する標記方法である定義フォーマットとを指定、要求し、
前記サービス提供管理データベースから前記アプリケーションの属性情報の項目を抽出し、前記定義フォーマットに従い変換されたＩＣカードのアプリケーションの属情報を取得し、
前記カード発行管理システムへ、前記アプリケーションポリシの判定に必要な前記ＩＣカードの属性情報の項目と、前記アプリケーションポリシが指定する定義フォーマットとを指定、要求し、
前記カード発行管理データベースから前記ＩＣカードの属性情報の項目を抽出し、前記定義フォーマットに従い変換されたＩＣカードの属性情報を取得し、
前記変換されたＩＣカードの属性情報により、前記カードポリシを判定し、
前記変換されたＩＣカードのアプリケーションの属性情報により、前記アプリケーションポリシを判定し、
前記アプリケーションの前記ＩＣカードへの搭載可否を判定することを特徴とするコレータシステム。
【請求項２】
ＩＣカードリーダライタを介しＩＣカードに接続し、
ネットワークまたは専用線を介し、ＩＣカード発行業務を行い且つ前記ＩＣカードの属性情報を所定のフォーマットで保存するカード発行管理データベースを有するカード発行管理システムに接続し、
前記ネットワークまたは前記専用線を介し、ＩＣカードのアプリケーションによるサービス提供業務を行い且つ前記アプリケーションの属性情報を所定のフォーマットで保存するサービス提供管理データベースを有するサービス提供管理システムとに接続するコレータシステムにおける前記アプリケーションの前記ＩＣカードへの搭載可否の判定方法であって、
前記ＩＣカードへの前記アプリケーションの搭載要求を受け、
前記カード発行管理システムが前記アプリケーションの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるカードポリシを、前記カード発行管理システムへ要求、取得し、
前記サービス提供管理システムが前記ＩＣカードの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるアプリケーションポリシを、前記サービス提供管理システムへ要求、取得し、
前記サービス提供管理システムへ、前記カードポリシの判定に必要な前記アプリケーションの属性情報の項目と、前記カードポリシが指定する標記方法である定義フォーマットとを指定、要求し、
前記サービス提供管理データベースから前記アプリケーションの属性情報の項目を抽出し、前記定義フォーマットに従い変換されたＩＣカードのアプリケーションの属性情報を取得し、
前記カード発行管理システムへ、前記アプリケーションポリシの判定に必要な前記ＩＣカードの属性情報の項目と、前記アプリケーションポリシが指定する定義フォーマットとを指定、要求し、
前記カード発行管理データベースから前記ＩＣカードの属性情報の項目を抽出し、前記定義フォーマットに従い変換されたＩＣカードの属性情報を取得し、
前記変換されたＩＣカードの属性情報により、前記カードポリシを判定し、
前記変換されたＩＣカードのアプリケーションの属性情報により、前記アプリケーションポリシを判定し、
前記アプリケーションの前記ＩＣカードへの搭載可否を判定することを特徴とする判定方法。
【請求項３】
ＩＣカード発行業務を行うカード発行管理システムがＩＣカードのアプリケーションの属性情報に対して要求する前記アプリケーションの搭載の許可条件であるカードポリシと、
ＩＣカードのアプリケーションによるサービス提供業務を行うサービス提供管理システムがＩＣカードの属性情報に対して要求する前記アプリケーションの搭載の許可条件であるアプリケーションポリシとを収集し、前記カードポリシと前記アプリケーションポリシの判定を行うコレータシステムに、ネットワークまたは専用線を介し接続し、
前記ＩＣカードの属性情報を所定のフォーマットで保存するカード発行管理データベースを有し、
前記コレータシステムからのカードポリシ取得要求に応じ、前記カードポリシを前記コレータシステムに送信し、
前記コレータシステムに指定される前記ＩＣカードの属性情報の項目を前記カード発行管理データベースから抽出し、前記所定のフォーマットから前記アプリケーション属性情報により指定される標記方法である定義フォーマットに従いＩＣカードの属性情報を変換し、前記コレータシステムに送信することを特徴とするカード発行管理システム。
【請求項４】
請求項３に記載のカード発行管理システムであって、
前記カード発行管理データベースは、定義フォーマットと前記ＩＣカードの属性情報との間のマッピング規則であるマッピング情報を保存し、
前記カード発行管理システムは、
前記定義フォーマットに対応する前記マッピング規則を検索し、
前記指定されたＩＣカードの属性情報の項目を前記検索されたマッピング規則に従って抽出し、
前記抽出された項目を前記定義フォーマットに従って変換し、前記コレータシステムに送信することを特徴とするカード発行管理システム。
【請求項５】
請求項３または４に記載のカード発行管理システムであって、
前記定義フォーマットは複数あることを特徴とするカード発行管理システム。
【請求項６】
請求項５に記載のカード発行管理システムであって、
前記カード発行管理データベースが、
前記複数の定義フォーマットのそれぞれ対応する複数の前記マッピング規則情報を保存することを特徴とするカード発行管理システム。
【請求項７】
請求項３から６のいずれかに記載のカード発行管理システムであって、
前記定義フォーマットは、Ｗｅｂサーバにて管理され、
前記カード発行管理システムは前記Ｗｅｂサーバにアクセスすることにより、前記定義フォーマットを利用することを特徴とするカード発行管理システム。
【請求項８】
ＩＣカード発行業務を行うカード発行管理システムがＩＣカードのアプリケーションの属性情報に対して要求する前記アプリケーションの搭載の許可条件であるカードポリシと、
ＩＣカードのアプリケーションによるサービス提供業務を行うサービス提供管理システムがＩＣカードの属性情報に対して要求する前記アプリケーションの搭載の許可条件であるアプリケーションポリシとを収集し、前記カードポリシと前記アプリケーションポリシの判定を行うコレータシステムに、ネットワークまたは専用線を介し接続し、
前記アプリケーションの属性情報を所定のフォーマットで保存するサービス提供管理データベースを有し、
前記コレータシステムからのアプリケーションポリシ取得要求に応じ、前記アプリケーションポリシを前記コレータシステムに送信し、
前記コレータシステムに指定される前記アプリケーションの属性情報の項目を前記カード発行管理データベースから抽出し、前記所定のフォーマットから前記ＩＣカードの属性情報により指定される標記方法である定義フォーマットに従いＩＣカードの属性情報を変換し、前記コレータシステムに送信することを特徴とするサービス提供管理システム。
【請求項９】
請求項８に記載のカード発行管理システムであって、
前記サービス提供管理データベースは、定義フォーマットと前記ＩＣカードの属性情報との間のマッピング規則であるマッピング情報を保存し、
前記サービス提供管理システムは、
前記定義フォーマットに対応する前記マッピング規則を検索し、
前記指定されたＩＣカードの属性情報の項目を前記検索されたマッピング規則に従って抽出し、
前記抽出された項目を前記定義フォーマットに従って変換し、前記コレータシステムに送信することを特徴とするサービス提供管理システム。
【請求項１０】
請求項３または４に記載のカード発行管理システムであって、
前記定義フォーマットは複数あることを特徴とするサービス提供管理システム。
【請求項１１】
請求項５に記載のカード発行管理システムであって、
前記サービス提供管理データベースが、
前記複数の定義フォーマットのそれぞれ対応する複数の前記マッピング規則情報を保存することを特徴とするサービス提供管理システム。
【請求項１２】
請求項３から６のいずれかに記載のカード発行管理システムであって、
前記定義フォーマットは、Ｗｅｂサーバにて管理され、
前記サービス提供管理システムは前記Ｗｅｂサーバにアクセスすることにより、前記定義フォーマットを利用することを特徴とするサービス提供管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ICカードを用いたICカードシステムに関わり、ICカードへのカードアプリケーションプログラム搭載方法及び実行方法に関わる。
【背景技術】
【０００２】
従来、磁気カードに代わり、1枚のカードに複数のサービスが搭載可能な多機能ICカードが普及しつつある。現状、多機能ICカードの発行管理はカード発行者が主となり運用しているため、カードへ搭載するアプリケーション（以下、AP）も予めカード発行者により決められた固定の組み合わせであることが多い。
【０００３】
非特許文献１に多様なカードとAPの組み合わせを評価する方法としてはGlobalPlatform（以下GP）というICカードに関する仕様策定団体により解決方法が提示されている。
【０００４】
図1はGPが提案するICカード運用管理業務におけるICカードとAPの正しい組み合わせを自動判別するシステム構成を表している。まず、システムの構成要素について概要を説明する。
【０００５】
符号１０１はカード発行管理システムであり、ICカードに関係する情報やカード利用者の情報を管理し、カード発行業務を行う。該システムは、カード発行管理データベース（１２１）を管理しており、当該DB内ではカードプロファイル情報（１２２）が管理されている。カードプロファイル情報とは、カードに関わる属性情報、すなわち、カード発行管理システムがカードの管理に使用する情報をまとめた呼び方であり、カードID、カード容量などの基本データから、カードに現在搭載されているAP一覧情報などの動的に変化するデータも含まれる。特に、ここではカードポリシ（１２３）というデータが含まれていることが特徴的である。ポリシとは、カードがAPなど他のエンティティに対して要求する要件であり、具体的には「APの容量は4KB以下であること」「APの種類はJavaCard（Javaは登録商標）対応APであること」などである。カードポリシはカードプロファイル情報の一部として含まれている。カードプロファイル取得処理部（１２４）は外部システムからの要求に応じて対応するカードプロファイルを返すロジックを有する。
【０００６】
符号１０２はサービス提供管理システムであり、APに関係する情報やサービス利用者の情報を管理し、サービス提供業務を行う。該システムは、サービス提供管理データベース（１３１）を管理しており、当該DB内ではAPプロファイル情報（１３２）が管理されている。APプロファイル情報は、APに関わる属性情報、すなわち、サービス提供管理システムがAPの管理に使用する情報をまとめた呼び方であり、AID、AP名称などの基本データから、APが運用中かロック中かなどの動的に変化するデータも含まれる。カードプロファイルと同様、APプロファイルにはAPポリシ（１３３）が含まれている。APポリシとは、APがカードなど他のエンティティに対して要求する要件であり、具体的には「カードのEEPROM容量は１６KB以上であること」「カードのプラットフォームはJavaCardであること」などである。APプロファイル取得処理部（１３４）は外部システムからの要求に応じて対応するAPプロファイルを返すロジックを有する。
【０００７】
符号１０３はコレータシステムであり、利用者（１１１）の要求に応じて、上記プロファイルを収集し、中に含まれるポリシが満たされているかどうかの判定を行うシステムである。コレータシステムは、プロファイル収集ロジック（１４１）とポリシ判定処理部（１４２）を有する。プロファイル収集ロジック（１４１）は、カード発行管理システムにカードプロファイル情報を、サービス提供管理システムにAPプロファイル情報を、それぞれ要求し取得するロジックを有する。ポリシ判定処理部（１４５）は、上記取得したプロファイルを解析し、それぞれのポリシが満たされているかどうかを判定し、結果を利用者に提示するロジックを有する。
【０００８】
カード発行管理システムとサービス提供管理システムとコレータシステム間は公衆網などのネットワークあるいは専用線によるネットワークあるいは、書面や情報記録媒体の郵送・手渡しにより情報のやり取りを実現する。また、各システムの端末／サーバ間は、公衆網もしくは専用線のネットワークにより情報のやり取りを実現する。
【０００９】
また、上述の各システムはそれぞれ処理部を有するが、これらはコンピュータ・プログラムとして実現され、動作する。
【００１０】
次に、上記システムにおけるICカードへのAP搭載可否判定処理の動作手順を例にとり、従来システムの課題を説明する。
【００１１】
利用者（１１１）が所有するカード（１１０）と搭載を希望するAPの搭載可否判定を行う場合、コレータシステムにAP搭載可否判定を依頼する（ステップ１５１）。具体的な依頼方法としては、自宅PCからのWebアクセスや、店頭に設置された端末からのアクセスの場合もあり、また、電話によるオペレータへの問い合わせの場合もある。コレータシステムは利用者の所有するカードのカードIDをキーとしてカード発行管理システムから対応するカードプロファイル情報を取得する（ステップ１５２、ステップ１５３）。同様にコレータシステムは利用者が搭載を希望するAPのAIDをキーとしてサービス提供管理システムから対応するAPプロファイル情報を取得する（ステップ１５４，ステップ１５５）。取得したカードプロファイル内のカードポリシが満たされているかをAPプロファイル内の情報を用いて検証する。例えばカードポリシが「APの容量は4KB以下であること」の場合、APプロファイル内のAP容量項目をチェックし４KB以下であるかどうかを判定する。同様に、APプロファイル内のAPポリシが満たされているかをカードプロファイル内の情報を用いて検証する。例えばAPポリシが「カードのEEPROM容量は１６KB以上であること」の場合、カードプロファイル内のEEPROM容量項目をチェックし16KB以上であるかどうかを判定する。そして全てのポリシについて判定を終了し、利用者に対して結果を提示する（ステップ１５６）。また、プロファイル情報はポリシも含めてXML（eXtensible Markup Language）によって表記されている。
【００１２】
【非特許文献１】GlobalPlatform Systems Profiles 1.1.0  published September 2003
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ICカードの種類が増え、それに応じてAPも多種多様に開発され提供可能となった場合、また、バージョンアップなどの原因により、カードとAPの組み合わせによっては搭載が不可能な場合が生じる。そのため、カードを運用する事業者にとって、搭載可能なカードとAPの組み合わせを管理することが複雑になる。
【００１４】
また、多機能ICカードは、利用者へのカード発行後にAPを搭載・削除することが可能であり、利用者が自由にAPを選択し搭載・削除を繰り返すことが想定される。そのため利用者に対して、どのAPが搭載可能であるかをリアルタイムに動的に提示することがカード発行管理事業者の必須サービスになると予想される。
【００１５】
ここで上記ＧＰが提案するシステムにおける第1の問題点は、プロファイル情報の全ての項目を取得する必要があることである。
コレータシステムはカードプロファイルに含まれるカードポリシ、及びAPプロファイルに含まれるAPポリシを受け取るまでポリシの内容を分からないため、プロファイルとして定義されている全ての項目の情報を取得する。これにより、セキュリティ上の問題が生じる。つまり、ポリシ判定を行うたびに、判定に必要のない情報も全て外部システムに提供することとなる。また、送受信するデータ容量の差による効率上の問題も生じる。利用者からの要求に応じて1枚のICカードごとのポリシ判定を行う場合は、大きな差は生じないが、バッチ処理を行う場合など、ポリシ判定する対象のICカードが大量であり、それに対応してコレータが取得すべきプロファイルが大量にある場合、一つ一つのプロファイル情報のデータ容量は効率上の大きい問題となる。
【００１６】
上記ＧＰが提案するシステムにおける第2の問題点は、プロファイル情報のフォーマットが固定である点である。
プロファイル情報とは既に記載の通り、カードプロファイルであればカードIDやカード容量など、APプロファイルであればAIDやAP名称など、既存のシステムにて管理されていると考えられる情報である。しかし、従来方式ではコレータシステムにて収集する各プロファイルは同一のフォーマットに統一せねばならず、カード発行管理システムやサービス提供管理システムは新たにDBを作成し直すか、予めフォーマットに従ったプロファイル情報を作成しておく必要がある。前者は工数の問題が大きく、後者はDB情報の変更に対応してリアルタイムにプロファイル情報を作成する必要があり困難である。
以上で、従来システムにおける２つの問題点についての説明を終える。
【００１７】
本願においては、上記２つの問題点を解決することにより、カード発行管理事業者がどのAPが搭載可能であるかをリアルタイムに動的に提示することを可能とし、プロファイル情報の全ての項目をコレータが取得せずとも、ポリシ判定を可能にし、システム間でやりとりされるデータ量も必要最小限とし、コレータシステムにて収集する各プロファイルは同一のフォーマットに統一せずとも、各プロファイルの収集を可能とすることを課題とする。
【課題を解決するための手段】
【００１８】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記のとおりである。
【００１９】
ＩＣカードへのアプリケーションの搭載要求を受け、カード発行管理システムがアプリケーションプロファイル情報に対して要求されるアプリケーションの搭載の許可条件であるカードポリシを、カード発行管理システムへ要求、取得し、サービス提供管理システムがＩＣカードのカードプロファイル情報に対して要求されるアプリケーションの搭載の許可条件であるアプリケーションポリシを、サービス提供管理システムへ要求、取得し、サービス提供管理システムへ、カードポリシの判定に必要なアプリケーションのプロファイル情報の項目と、カードポリシが指定する定義フォーマットとを指定、要求し、サービス提供管理データベースからアプリケーションプロファイル情報の項目を抽出し、定義フォーマットに従い変換されたＩＣカードのアプリケーションプロファイル情報を取得し、カード発行管理システムへ、アプリケーションポリシの判定に必要なＩＣカードプロファイル情報の項目と、アプリケーションポリシが指定する定義フォーマットとを指定、要求し、カード発行管理データベースからＩＣカードプロファイル情報の項目を抽出し、定義フォーマットに従い変換されたＩＣカードプロファイル情報を取得し、変換されたＩＣカードプロファイル情報により、カードポリシを判定し、変換されたＩＣカードのアプリケーションプロファイル情報により、アプリケーションポリシを判定し、アプリケーションのＩＣカードへの搭載可否判定を行う。
これにより、カード発行管理システム、サービス提供管理システムが外部システムに提供するプロファイル情報を動的且つ必要最小限とすることが可能となる。
【発明の効果】
【００２０】
本発明が提供するポリシ判定方法により、ポリシ判定に必要なプロファイル情報のみをシステム間でやり取りすることが可能になるため、必要のないプロファイル情報の開示を防ぎセキュリティ上の効果がある。また、必要最小限のデータ容量を送受信となるためコストや時間など効率の面での効果もある。
また、プロファイルを提供する場合、ポリシが指定するフォーマットに合わせてマッピング規則を抽出し、当該規則に従って既存DBから動的にプロファイルを作成するため、プロファイルフォーマットが唯一の固定フォーマットである必要がない。また、既存DBをそのまま利用することが可能であり、新たにテーブルを作成するなどの新規に必要な工数を削減できる。
【発明を実施するための最良の形態】
【００２１】
以下、具体的に本発明の実施の形態を説明する。本願発明の解決手段を用いてカード発行管理システム、サービス提供管理システム及びコレータシステムが連携して行う、AP搭載可否判定処理について説明する。まず前処理としてカード発行管理システムとサービス提供管理システムは、公開されている定義フォーマットと、自身が所有するDB内で管理している既存情報との間のマッピング規則を用意しておく。
【００２２】
ここで定義フォーマットとは、プロファイル情報の標記方法のフォーマット定義である。もしプロファイル情報をXMLで記述する場合は、DTDやXMLSchema定義が、この定義フォーマットにあたる。本発明においては、カード発行管理システムとサービス提供管理システムという異なるシステムが各々の所有するプロファイル情報を提供するため、共通のフォーマットに従い表記する必要がある。定義フォーマットは単一とは限らないため指定する必要があるが、本発明では各システムが提供するポリシー内にて指定する。そのため定義フォーマットは複数システムが動的にアクセス可能である必要があり、Webサーバ上などにて公開されていると想定している。
【００２３】
マッピング規則情報とは、公開されている定義フォーマットとカード属性既存情報とのマッピング規則を記載した情報である。定義フォーマットは複数公開されていると想定されるため、それに応じてマッピング規則情報も複数用意されている。マッピング規則は定義フォーマットの数だけ必要となる。１つの定義フォーマットにのみ対応する場合はファイルとして管理する場合もあるが、複数の定義フォーマットに対応する場合、定義フォーマットIDや、定義フォーマットが公開されているURLなど、唯一に特定できるデータをキーとしてDBに格納される場合もある。
【００２４】
次にコレータシステムのポリシ取得処理に移る。利用者はコレータシステムに対してAP搭載可否判定を要求する。コレータシステムは利用者が所有するICカードからカードIDなどカードを識別する情報を取得し、利用者が搭載を希望するAPのAIDなどAPを識別する情報を取得する。カード発行管理システムに対して上記カードIDを指定して対応するカードポリシを要求する。また、サービス提供管理システムに対して上記AIDを指定して対応するAPポリシを要求する。
【００２５】
次にカード発行管理システムによるカードポリシ送信処理に移る。カード発行管理システムは、指定されたカードIDをキーとして対応するカードポリシをDBに格納している。従来はカードプロファイル情報の一部としてDBに管理されているが、本発明では独立した情報としてDBに格納する。カード発行管理システムはカードIDに対応するカードポリシを抽出しコレータシステムに送信する。
【００２６】
サービス提供管理システムによるAPポリシ送信処理も同様で、APポリシをアプリケーションプロファイル情報とは独立してDBに管理しており、コレータシステムに指定されたAIDに対応するAPポリシをDBより抽出しコレータシステムに送信する。
【００２７】
次にコレータシステムによるプロファイル取得処理に移る。コレータシステムは取得したカードポリシ及びAPポリシの内容を解析し、ポリシ判定に必要なプロファイル情報の項目を抽出する。そして、必要とされるカードプロファイル項目と、ポリシが指定している定義フォーマットを指定して、カード発行管理システムにカードプロファイルを要求する。また、サービス提供管理システムに対しても同様に、必要とされるAPプロファイル項目とポリシが指定している定義フォーマットを指定して、サービス提供管理システムにAPプロファイルを要求する。ここで、カードプロファイルの定義フォーマットとAPプロファイルの定義フォーマットは同一である必要はない。
【００２８】
次にカード発行管理システムによるカードプロファイル送信処理に移る。カード発行管理システムはまず指定された定義フォーマットを参照する。そして自身が所有するカード属性既存情報DBとのマッピング規則を選択し、規則に従い必要とされるプロファイル情報の項目がDB内のどの項目にあたるかを確認し値を抽出する。次にカード発行管理システムは、抽出した値を指定された定義フォーマットに従ってカードプロファイル情報を作成し、コレータシステムに送信する。
【００２９】
サービス提供管理システムによるAPプロファイル送信処理も同様である。サービス提供管理システムはまず指定された定義フォーマットを参照する。そして自身が所有するAP属性既存情報DBとのマッピング規則を選択し、規則に従い必要とされるプロファイル情報の項目がDB内のどの項目にあたるかを確認し値を抽出する。次にサービス提供管理システムは、抽出した値を指定された定義フォーマットに従ってAPプロファイル情報を作成し、コレータシステムに送信する。
【００３０】
次にコレータシステムによるポリシ判定処理に移る。コレータシステムは取得したカードポリシと判定に必要なプロファイル情報を用いてカードポリシが満たされているかどうかを判定する。同様に取得したAPポリシと判定に必要なプロファイル情報を用いてAPポリシが満たされているかどうかを判定する。そして全てのポリシ判定が終了した後、その結果を利用者に提示する。
【００３１】
次に図面を用いて本発明の実施の形態を説明する。本発明に係わるシステムの基本構成は、図2に示される。
図2における、符号１０１はカード発行管理システムであり、ICカードに関係する情報やカード利用者の情報を管理し、カード発行業務を行う。尚、ICカードに関係する情報とは、カードID、カードの容量（ROM、EEPROM、RAM）、カードOSの種別やバージョン、搭載AP一覧情報を含むカードのステータス情報等のものを意味し、カード利用者の情報は、利用者氏名、年齢、性別、住所、電話番号、利用履歴情報等のものを表す。
【００３２】
該システムは、カード発行管理データベース（１２１）を管理しており、当該DB内ではカードポリシ情報（２２１）とカード属性既存情報（２２２）とマッピング規則情報（２２３）とが管理されている。
カードポリシ情報は、カードがAPなど他のエンティティに対して要求する要件であり、具体的には「APの容量は4KB以下であること」「APの種類はJavaCard対応APであること」「利用者の年収が一定条件以上であること」「利用者の年齢が一定条件以上であること」などである。
【００３３】
カード属性既存情報は、従来からカード発行管理システムが管理しているカードに関わるプロファイル情報のことであり、カードID、カード容量、カードOSの種別やバージョンなどの基本データから、カードに現在搭載されているAP一覧情報を含むカードステータス情報などの動的に変化するデータも含まれる。
【００３４】
マッピング規則情報とは、公開されている定義フォーマット（１０４）とカード属性既存情報（２２２）とのマッピング規則を記載した情報である。定義フォーマット（１０４）は複数公開されていると想定されるため、それに応じてマッピング規則情報も複数用意されている。
カードポリシ取得処理部（２２４）は外部システムからの要求に応じて対応するカードポリシを返すロジックを有する。
【００３５】
既存情報変換処理部（２２５）は以下のロジックを有する。まず外部システムからのカードプロファイル情報を要求するカードプロファイル要求に応じて、指定された定義フォーマットに対応するマッピング規則情報を検索する。次に要求されたプロファイル項目に対応するカード属性既存情報をマッピング規則に従って抽出する。尚、カードプロファイル情報とは、カードに関わる属性情報をまとめた呼び方であり、カードID、カード容量カードOSの種別やバージョンなどの基本データから、カードに現在搭載されているAP一覧情報を含むカードステータス情報などの動的に変化するデータも含まれる。最後に抽出した情報を定義フォーマットに従って変換することでカードプロファイルを作成し、コレータシステムに送信する。
【００３６】
カード発行管理システム事業者はICカードの発行業務の責務を持つ事業者であり、上記カード発行管理システム（１０１）を用いてICカードの発行業務を実行する。カード発行管理システム事業者とは、例えばクレジットカード会社、銀行、地方公共団体、デパート、交通機関などであり、カード発行管理システムは各企業のサービスセンタに設置される場合や、各企業に委託された任意のサービス運用企業のセンタに設置される場合がある。
またカード発行管理システム（１０１）はサーバにより実現され、カード発行管理データベース（１２１）はHDD内のDBにより実現され、各処理部（２２４、２２５）の機能はHDD内のアプリケーションサーバ内に設定されたコンピュータ・プログラムにしたがって動作させられるものである。
【００３７】
符号１０２はサービス提供管理システムであり、APに関係する情報やサービス利用者の情報を管理し、サービス提供業務を行う。該システムは、サービス提供管理データベース（１３１）を管理しており、当該DB内ではAPポリシ情報（２３１）とAP属性既存情報（２３２）及びマッピング規則情報（２３３）が管理されている。
【００３８】
APポリシ情報は、APがカードなど他のエンティティに対して要求する要件であり、具体的には「カードのEEPROM容量は１６KB以上であること」「カードのプラットフォームはJavaCardであること」「カード種別がゴールドカードであること」「利用者の年齢が一定条件以上であること」などである。
AP属性既存情報は、従来からサービス提供管理システムが管理しているAPに関わる属性情報のことであり、AID、AP名称、バージョン、AP容量、AP種別などの基本データから、APが運用中かロック中かなどを含むAPステータス情報などの動的に変化するデータも含まれる。
【００３９】
マッピング規則情報とは、公開されている定義フォーマット（１０４）とAP属性既存情報（２３２）とのマッピング規則を記載した情報である。定義フォーマット（１０４）は複数公開されていると想定されるため、それに応じてマッピング規則情報も複数用意されている。
APポリシ取得処理部（２３４）は外部システムからの要求に応じて対応するAPポリシを返すロジックを有する。
【００４０】
既存情報変換処理部（２３５）は以下のロジックを有する。まず外部システムからのAPプロファイル要求に応じて、指定された定義フォーマットに対応するマッピング規則情報を検索する。次に要求されたプロファイル項目に対応するAP属性既存情報をマッピング規則に従って抽出する。最後に抽出した情報を定義フォーマットに従って変換しAPプロファイルを作成し、コレータシステムに送信する。
【００４１】
サービス提供管理システム事業者はAP搭載・削除やサービス運用などの業務の責務を持つ事業者であり、上記サービス提供管理システム（１０２）を用いてAP搭載・削除業務を実行する。サービス提供管理システム事業者とは、例えばポイントAPの運用事業者、電子マネー運用事業者、ゲームなどのエンターテイメントAPの運用事業者などであり、サービス提供管理システムは各企業のサービスセンタに設置される場合や、各企業に委託された任意のサービス運用企業のセンタに設置される場合がある。
【００４２】
またサービス提供管理システム（１０２）はサーバにより実現され、サービス提供管理データベース（１３１）はHDD内のDBにより実現され、各処理部（２３４、２３５）の機能はHDD内のアプリケーションサーバ内に設定されたコンピュータ・プログラムにしたがって動作させられるものである。
符号１０３はコレータシステムであり、利用者（１１１）の要求に応じて、上記ポリシとポリシ判定に必要なプロファイルを収集し、ポリシが満たされているかどうかの判定を行うシステムである。コレータシステムは、ポリシ収集処理部（２４１）と必要プロファイル収集処理部（２４２）及びポリシ判定処理部（２４３）を有する。
【００４３】
ポリシ収集処理部（２４１）は、カード発行管理システムにカードポリシを、サービス提供管理システムにAPポリシを、それぞれ要求し取得するロジックを有する。
【００４４】
必要プロファイル収集処理部（２４２）は、上記取得したポリシの内容を解析しポリシ判定に必要なプロファイル情報の項目を抽出し、当該プロファイル情報を要求し取得するロジックを有する。カード発行管理システムには、必要なカードプロファイル情報項目と、ポリシが指定する定義フォーマットを送信し、対応するカードプロファイルを受信する。サービス提供管理システムには、必要なAPプロファイル情報項目と、ポリシが判定する定義フォーマットを送信し、対応するAPプロファイルを受信する。ポリシ判定処理部（２４３）は、上記取得したプロファイルを解析し、カードポリシ及びAPポリシが満たされているかどうかを判定し、結果を利用者に提示するロジックを有する。
【００４５】
コレータシステム事業者は上記ポリシとプロファイルを用いた判定業務の責務を持つ事業者であり、上記コレータシステム（１０３）を用いて判定業務を実行する。コレータシステム事業者は、新たに想定されるコレーション業務を専門に行う事業者である場合もあるが、カード発行時の判定業務はカード発行管理システム事業者が、AP搭載時の判定業務はサービス提供管理事業者が兼任して実行する場合もありうる。そのためコレータシステムはコレータシステム事業者のサービスセンタに設置される場合もあるが、カード発行管理システムの一部、もしくはサービス提供管理システムの一部として設置される場合もある。
【００４６】
またカード発行管理システム（１０３）はサーバにより実現され、各処理部（２４１、２４２、２４３）の機能はHDD内のアプリケーションサーバ内に設定されたコンピュータ・プログラムにしたがって動作させられるものである。また、コレータシステムはICカードからカードIDなどのカードプロファイル情報を取得するため、ICカードリーダ／ライタ部が必要となる。ただし、利用者の利用形態によってリーダ／ライタの接続機器が異なると考えられる。例えば利用者が家庭の個人PCからインターネットを通してコレータシステムに接続する場合は個人PCにリーダ／ライタ部が実装されており、また、コレータシステム事業者の店舗を利用者が訪れサービスを利用する場合は、店頭に設置された端末にリーダ／ライタ部が実装されることとなる。
【００４７】
符号１０４は定義フォーマットであり、カードプロファイルやAPプロファイルが従うべきフォーマットである。これは唯一ではなく、複数存在し、ポリシを作成する際に自由に選択することができる。ポリシ作成事業者が作成することも可能である。ただし、これらの定義フォーマットは公開されていて、カード発行管理事業者やサービス提供管理事業者などプロファイルを提供する事業者など複数の外部事業者から自由に参照可能である必要がある。
【００４８】
定義フォーマットは、通常はWebサーバ上に設置されURLによりアクセスされることが多いと想定される。また管理事業者としては、当該定義フォーマットの管理業務のみを専用に行う事業者であることもありうるが、カード発行管理事業者やサービス提供管理事業者、またコレータ事業者などが作成・公開し管理することが多いと想定される。
【００４９】
カード発行管理システムとサービス提供管理システムとコレータシステム間は公衆網などのネットワークあるいは専用線によるネットワークあるいは、書面や情報記録媒体の郵送・手渡しにより情報のやり取りを実現する。また、各システムの端末／サーバ間は、公衆網もしくは専用線のネットワークにより情報のやり取りを実現する。
【００５０】
次に本発明の実施例の提案方式によるAP搭載可否判定を行う場合の大まかな手順を説明する。
AP搭載可否判定処理は、利用者（１１１）からのAP搭載可否判定要求により処理は始まるが、その前処理として行うべき処理がある。それはマッピング規則情報（２２３、２３３）を用意する処理であり、これらマッピング規則情報とは、公開されている定義フォーマット（１０４）と自身が所有する属性既存情報（２２２、２３２）との間の関連を示す情報である。
【００５１】
以上の前処理が正常に終了した場合、AP搭載可否判定処理を行うことが可能となる。ICカードへのAP搭載を希望する利用者（１１１）は、コレータシステムにアクセスし所有するICカード（１１０）に搭載希望するAPが搭載可能であるかどうかの判定を要求する（ステップ２５１）。具体的な依頼方法としては、自宅PCからのWebアクセスや、店頭に設置された端末からのアクセスの場合もあり、また、電話によるオペレータへの問い合わせの場合もある。
コレータシステムはまずポリシ取得処理を行う。コレータシステムは利用者の所有するカードのカードID、もしくはカードIDに関連づけられたカード種別などをキーとしてカード発行管理システムから対応するカードポリシを取得する（ステップ２５２）。
【００５２】
同様にコレータシステムは利用者が搭載を希望するAPのAID、もしくはAIDに関連づけられたAP種別などをキーとしてサービス提供管理システムから対応するAPポリシを取得する（ステップ２５３）。
【００５３】
次にプロファイル取得処理に移る。コレータシステムは取得したポリシを解析し、ポリシ判定に必要なカードプロファイル情報の項目、及び必要なAPプロファイル情報の項目を抽出する。例えば、カードポリシが「APの容量は4KB以下であること」の場合、必要なAPプロファイル情報の項目は「APの容量」である。同様に、例えばAPポリシが「カードのEEPROM容量は１６KB以上であること」の場合、必要なカードプロファイル情報の項目は「カードのEEPROM容量」である。
【００５４】
コレータシステムはこれらの必要なプロファイル情報項目と、ポリシが指定する定義フォーマット（１０４）を指定してカード発行管理システムにカードプロファイルを、サービス提供管理システムにAPプロファイルをそれぞれ要求する。カード発行管理システムはまず指定された定義フォーマットを参照し（ステップ２５４）、対応するマッピング規則情報（２２３）を検索し、それに従ってカード属性既存情報（２２２）から要求されている情報を抽出し既存情報変換処理部に送信する（ステップ２５６）。最後に既存情報変換処理部で抽出した情報を定義フォーマットに従い変換しコレータシステムに送信する（ステップ２５８）。サービス提供管理システムも同様に、まず指定された定義フォーマットを参照し（ステップ２５５）、対応するマッピング規則情報（２３３）を検索し、それに従ってAP属性既存情報（２３２）から要求されている情報を抽出し既存情報変換処理部に送信する（ステップ２５７）。最後に既存情報変換処理部で抽出した情報を定義フォーマットに従い変換しコレータシステムに送信する（ステップ２５９）。
【００５５】
次にポリシ判定処理に移る。コレータシステムは取得したポリシと判定に必要なプロファイルを用いてカードポリシ、APポリシそれぞれについて判定する。全てのポリシの判定を終了し、その結果を利用者に提示して（ステップ２６０）、AP搭載可否判定処理を終了する。利用者は判定結果に基づき自身が搭載を希望するAPを再考し選択し、実際のAP搭載処理に進む。ただし、判定の結果AP搭載が拒否となったAPに対しては利用者が再度希望しても搭載することはもちろん不可能である。
【００５６】
以上が本発明に係わるシステムの基本構成と処理である。ポリシの例を示したのが図11である。ここではカードポリシをXMLにより表記している。ポリシの内容は「APが必要とする不揮発性容量が4000バイト以下であること」と「APの種類はアプリケーションであること」である。また、APプロファイルの例を示したのが図12であり、ポリシと同様にXMLによる表記している。ここでは「APの種類」「APが必要とする揮発性容量」「APが必要とする不揮発性容量」「APのインストール時のパラメータ」が項目として記載されている。
【００５７】
上記プロファイルを生成する際、マッピング規則情報（図２の２２３、２３３）を用いて既存DB（図２の２２２，２３２）から動的に生成可能な点が本願発明の特徴の一つである。図１２のプロファイル例の場合、マッピング規則情報（図２の２２３、２３３）の例としては、図12のXMLデータ各要素を示すXPATH文字列と、既存DBのテーブルカラム名の対応表などが考えられる。
【００５８】
ポリシを管理するDBのデータ構造は図13に例示してある。カードポリシの場合はカードIDをキーとして、ポリシのID及びカードポリシを具体的に示す情報を管理している（１３０１）。図2内のカードポリシ情報（２２１）にあたる。
APポリシの場合はAIDをキーとしてポリシのID及びAPポリシを具体的に示す情報を管理している（１３０２）。図2内のAPポリシ情報（２３１）にあたる。
ここでポリシIDはポリシを識別するためのIDである。カードがユニークに限定されれば、対応するカードポリシも１つに限定されるが、カード毎にカードポリシが全て異なるわけではなく、複数のカードが同一のカードポリシを参照することはよくあると想定される。APポリシとAIDに関しても同様である。
【００５９】
以上が、システム構成を含めた全体の流れとなる。次にシステムの各構成要素について説明を行う。
図3はICカード・システムの例の概要を示す図である。ICカード１１０の中にはチップ３０２があって、リーダライタ（もしくはリーダライタを有する端末）３０３とデータのやりとりを行う例を示している。リーダライタの中にはコントロール・プロセッサ３０４やデータベースとなる磁気ディスク３０５などが存在する。ICカード１１０には、通例通り、例えば、Vcc（供給電源）、GND（グランド）、RST（リセット）、I/O（入出力）、及びCLK（クロック）などの諸端子が示されている。また、図中、符号３０６はリーダライタ３０３からICカード１１０に対しての、例えばカードIDなどの各種問合せを示す。符号３０７はICカードが前述の問合せに対して行った返答を示す。こうした、諸情報の伝達は通例のシステムで十分である。
【００６０】
なお、ICカード内のICチップにおいて、具体的には前述のアプリケーションはメモリ領域に搭載される。一般に、メモリとしては、RAM（Random Access Memory）、EEPROM（Electrical Erasable Programmable Read Only Memory）あるいはROM（Read Only Memory）などが用いられる。
【００６１】
次に図4にこのようなICカード（１１０）内に搭載されているIC内部の基本的な領域の論理的な構成を示す。当該ICは、通例のマイクロ・コンピュータと同様に、ハードウェア層（４０３）とOSが搭載される領域、即ちOS層（４０２）とアプリケーションが搭載される領域、即ちアプリケーション層（４０１）とを有する。ここで、マルチアプリケーション搭載可能とは、アプリケーション層（４０１）に複数のアプリケーション（４０４−４０６）が搭載できるということである。また、アプリケーションの初期搭載とはこのアプリケーション（４０４−４０６）をICカード発行時に既に搭載された状態で利用申請者のもとに配布することであり、ダイナミックローディング可能とはこのアプリケーション（４０４−４０６）をカード発行後に、搭載あるいは削除が可能であることを示す。これらアプリケーション（４０４−４０６）は図2のサービス提供管理システム（１０２）で管理されているものであり、アプリケーション本体だけでなく、AIDやAPサイズなど関連する情報は、DB（１３１）内のAP属性既存情報（２３２）に格納されている。OS層（４０２）は通信処理部（４０７）、インタープリタ（４０８）、セキュリティ機構（４０９）などを有し、外部端末からのコマンド受信やアプリケーションのコマンド転送などを行っている。当然、アプリケーション層（４０１）とOS層（４０２）との間にはアプリケーション・インターフェイス、OS層（４０２）とハードウェア層（４０３）との間にはハードウェア・インターフェイスが設置されている。
【００６２】
次に本発明の実施例に関わる、AP搭載可否判定処理の具体的方法を説明する。まず図5のシーケンスを用いて説明する。まず利用者（５０１）はコレータシステム（５０２）に所有するICカードへ搭載を希望するAPの搭載可否判定を要求する（ステップ５１１）。コレータシステム（５０２）はICカードのカードIDを取得し、対応するカードポリシをカード発行管理システム（５０４）に要求し取得する（ステップ５１２）。また、利用者が搭載を希望するAPのAIDをキーとして対応するAPポリシをサービス提供管理システム（５０３）に要求し取得する（ステップ５１３）。次にコレータシステム（５０２）は、取得したポリシを解析し必要なカードプロファイル情報の項目を抽出し、カード発行管理システム（５０４）にカードプロファイルを要求し取得する（ステップ５１４）。同様に、コレータシステム（５０２）は、必要なAPプロファイル情報の項目を抽出し、サービス提供管理システム（５０３）にAPプロファイルを要求し取得する（ステップ５１５）。コレータシステム（５０２）はこれら取得したポリシとプロファイルを用いて全てのポリシを判定し、その結果を利用者（５０１）に提示する（ステップ５１６）。
【００６３】
図５と図２の各構成要素との関係を示すと、利用者（５０１）は図２の利用者（１１１）に、コレータシステム（５０２）は図２のコレータシステム（１０３）に、サービス提供管理システム（５０３）は図２のサービス提供管理システム（１０２）に、カード発行管理システム（５０４）は図２のカード発行管理システム（１０１）に、それぞれ対応する。
【００６４】
以上で説明した本発明の実施例におけるAP搭載可否判定方法の詳細について、カード発行管理システムとサービス提供管理システム及びコレータシステムの各システムの動作フローチャート（図6〜図10）と用いて説明する。これらは図5のシーケンスを詳細化したものである。
図6は本発明の実施例におけるコレータシステムの動作フローチャートである。
【００６５】
コレータシステムは利用者からのAP搭載可否判定依頼を受信する（ステップ６０１）。前述したように具体的な依頼方法としては、自宅PCからのWebアクセスや、店頭に設置された端末からのアクセスの場合もあり、また、電話によるオペレータへの問い合わせの場合もある。コレータシステムは、ICカードのカードIDを取得し対応するカードポリシをカード発行管理システムに要求し、利用者が搭載希望するAPのAIDに対応するAPポリシをサービス提供管理システムに要求する（ステップ６０２）。それぞれのポリシを取得するが（ステップ６０３）、取得できなかった場合ポリシ判定を続行することができないため処理を中止する（ステップ６１０）。取得できた場合は、これらのポリシを解析しポリシ判定に必要なプロファイル項目を決定する（ステップ６０４）。次に決定したカードプロファイル項目とポリシが指定する定義フォーマットを合わせてカード発行管理システムに要求し、同様にAPプロファイル項目とポリシが指定する定義フォーマットを合わせてサービス提供管理システムに要求する（ステップ６０５）。それぞれのプロファイルを取得するが（ステップ６０６）、取得できなかった場合ポリシ判定を続行することができないため処理を中止する（ステップ６１１）。取得できた場合は、これらのポリシとプロファイルを用いてポリシ判定を行う（ステップ６０７）。全てのポリシを判定した結果（ステップ６０８）、AP搭載可否が不可だった場合AP搭載不可であることを利用者に示す（ステップ６１２）。AP搭載可だった場合は、その旨を利用者に示して処理を終了する（ステップ６０９）。
【００６６】
図7、図8は本発明の実施例におけるカード発行管理システムの動作フローチャートである。
【００６７】
まず図7においてカード発行管理システムのカードポリシ送信時処理について説明する。カード発行管理システムはコレータシステムからの要求に応じて指定されたカードに対応するカードポリシをDBより取得する（ステップ７０１）。DBへの取得処理の結果（ステップ７０２）、対応するカードポリシを取得できなかった場合は、コレータシステムにその旨を伝え処理を中止する（ステップ７０４）。取得できた場合は、コレータシステムにカードポリシを送信し処理を終了する（ステップ７０３）。
【００６８】
次に図8においてカード発行管理システムのカードプロファイル送信時処理について説明する。カード発行管理システムはコレータシステムからの要求に応じて指定された定義フォーマットを参照し自身のDBと対応するためのマッピング規則を検索する（ステップ８０１）。検索処理の結果（ステップ８０２）、マッピング規則が用意されていない場合、指定された定義フォーマットに従ったカードプロファイルを送信することができないため、コレータシステムにその旨を伝え処理を中止する（ステップ８０５）。マッピング規則が用意されている場合、指定されたプロファイル必要項目に対応する値をDBから抽出し、定義フォーマットに従ったカードプロファイルの形に変換する（ステップ８０３）。変換したカードプロファイルをコレータシステムに送信し処理を終了する（ステップ８０４）。
【００６９】
図9、図10は本発明の実施例におけるサービス提供管理システムの動作フローチャートである。
まず図9においてサービス提供管理システムのAPポリシ送信時処理について説明する。サービス提供管理システムはコレータシステムからの要求に応じて指定されたAPに対応するAPポリシをDBより取得する（ステップ９０１）。DBへの取得処理の結果（ステップ９０２）、対応するAPポリシを取得できなかった場合は、コレータシステムにその旨を伝え処理を中止する（ステップ９０４）。取得できた場合は、コレータシステムにAPポリシを送信し処理を終了する（ステップ９０３）。
【００７０】
次に図10においてサービス提供管理システムのAPプロファイル送信時処理について説明する。サービス提供管理システムはコレータシステムからの要求に応じて指定された定義フォーマットを参照し自身のDBと対応するためのマッピング規則を検索する（ステップ１００１）。検索処理の結果（ステップ１００２）、マッピング規則が用意されていない場合、指定された定義フォーマットに従ったAPプロファイルを送信することができないため、コレータシステムにその旨を伝え処理を中止する（ステップ１００５）。マッピング規則が用意されている場合、指定されたプロファイル必要項目に対応する値をDBから抽出し、定義フォーマットに従ったAPプロファイルの形に変換する（ステップ１００３）。変換したAPプロファイルをコレータシステムに送信し処理を終了する（ステップ１００４）。
【００７１】
以上が本発明の実施の形態である。ICカードには接触型ICカード、非接触型ICカードなどがあるが、本発明の実施例ではこうしたICカードの構成自体によらず適用することが可能である。
【００７２】
また、カード発行管理システム及びサービス提供管理システムでは既存のDBで管理されている情報を動的にプロファイルに変換可能である。そのためこれらのマッピング規則による既存情報変換機能とポリシ管理機能のみを追加することにより、既存のICカード運用管理システムを本発明が提供するAP搭載可否判定機能を実行することが可能となる。このような必要機能のみを追加しAP搭載可否判定機能を実行可能とするサービス事業もある。
【００７３】
以上説明したように、本発明の実施例によれば、ポリシとプロファイルを分離して独立に管理し、また、プロファイルは既存DBから動的に作成するシステムを提供し、次のようなことが可能とする。
（１）第1の課題であるプロファイル情報の全ての項目をコレータが取得する必要があるという問題に対して、ポリシをプロファイルから独立して管理することにより解決する。コレータシステムは、AP搭載可否判定要求があった場合、まずカード発行管理システムからカードポリシのみを、サービス提供管理システムからAPポリシのみを取得する。取得したポリシの内容を解析し、判定に必要なプロファイル項目のみをそれぞれカード発行管理システムとサービス提供管理システムに要求する。従って、要求されたシステムは、指定されたプロファイル項目のみを抽出しコレータシステムに返すことで、ポリシ判定に必要ない情報をシステム外部に開示することがなく、またシステム間でやりとりされるデータ量も必要最小限とすることが可能となる。
【００７４】
（２）また、第2の課題である、プロファイル情報のフォーマットが固定であるという問題に対して、「定義フォーマット」というプロファイルフォーマットを用意し、これらを動的に選択することと、上記定義フォーマットと既存DBの間のマッピング規則を用意することで解決する。ここで定義フォーマットは世の中で唯一の固定フォーマットではなく、ポリシを作成する事業者が選択し指定するフォーマットであり、自由に作成することも可能である。ただし、当該フォーマットは公開されていて、ポリシを判定しようとするシステムが参照可能であることが条件となる。まず、コレータシステムはポリシを取得した後に、必要なプロファイル項目をそれら項目を管理するシステムに要求するが、その際、ポリシに記載されている定義フォーマット（もしくは、定義フォーマットを参照するために必要な情報）を指定する。要求されたシステムは、指定された定義フォーマットを参照し、自身の既存DBとのマッピング規則を参照する。このマッピング規則はDBテーブル設計者などにより予め用意されている。従って、このマッピング規則を参照することで、要求されているプロファイル項目が自身のDB内のどの項目に対応するのかを認識し値を返すことが可能となり、カード発行管理システムやサービス提供管理システムがポリシ判定のために外部システムに提供するプロファイル情報を唯一の固定フォーマットとせず、動的に指定された定義フォーマットに応じて作成することが可能となる。
【００７５】
（３）また、上記（２）で外部システムに提供するプロファイル情報は、既に運用されているICカード運用管理システムの既存DBをそのまま利用し、動的に作成することが可能である。
【図面の簡単な説明】
【００７６】
【図１】従来のAP搭載可否判定を実施するシステム構成を示す図。
【図２】本発明の実施形態に係るポリシとプロファイルを独立管理し、かつプロファイルを既存DBから動的に作成するAP搭載可否判定方法を実施するシステム構成を示す図。
【図３】カードシステムの概要を示す図。
【図４】ICカードの基本構成を示す図。
【図５】利用者の要求に応じてAP搭載可否判定を行うための本発明に係るシーケンスを示す図。
【図６】コレータシステムが、AP搭載可否判定を行うための本発明に係るシーケンスを示す図。
【図７】カード発行管理システムが、コレータシステムからの要求に応じてカードポリシを送信するための本発明に係るシーケンスを示す図。
【図８】カード発行管理システムが、コレータシステムからの要求に応じてカードプロファイルを送信するための本発明に係るシーケンスを示す図。
【図９】サービス提供管理システムが、コレータシステムからの要求に応じてAPポリシを送信するための本発明に係るシーケンスを示す図。
【図１０】サービス提供管理システムが、コレータシステムからの要求に応じてAPプロファイルを送信するための本発明に係るシーケンスを示す図。
【図１１】本発明で使用されるポリシの表記例。
【図１２】本発明で使用されるプロファイルの表記例。
【図１３】本発明で使用されるポリシを管理するDB構造例。
【符号の説明】
【００７７】
１０１：  カード発行管理システム
１０２：  サービス提供管理システム
１０３：  コレータシステム
１１０：  ICカード
１１１：  利用者
１２１：  カード発行管理データベース
１２２：  カードプロファイル情報
１２３：  カードポリシ
１２４：  カードプロファイル取得処理部
１３１：  サービス提供管理データベース
１３２：  APプロファイル情報
１３３：  APポリシ
１３４：  APプロファイル取得処理部
１４１：  プロファイル収集処理部
１４２：  ポリシ判定処理部
１５１：  AP搭載可否判定依頼処理
１５２：  カードプロファイル取得処理
１５３：  カードプロファイル送信処理
１５４：  APプロファイル取得処理
１５５：  APプロファイル送信処理
１５６：  AP搭載可否判定結果提示処理
２２１：  カードポリシ情報
２２２：  カード属性既存情報
２２３：  マッピング規則情報
２２４：  カードポリシ取得処理部
２２５：  既存情報変換処理部
２３１：  APポリシ情報
２３２：  AP属性既存情報
２３３：  マッピング規則情報
２３４：  APポリシ取得処理部
２３５：  既存情報変換処理部
２４１：  ポリシ収集処理部
２４２：  必要プロファイル収集処理部
２４３：  ポリシ判定処理部
２５１：  AP搭載可否判定依頼処理
２５２：  カードポリシ送信処理
２５３：  APポリシ送信処理
２５４：  定義フォーマット参照処理
２５５：  定義フォーマット参照処理
２５６：  カード既存情報抽出処理
２５７：  AP既存情報抽出処理
２５８：  カードプロファイル送信処理
２５９：  APプロファイル送信処理
２６０：  AP搭載可否判定結果提示処理
３０２：  ICチップ
３０３：  ICカード処理端末
３０４：  ICカードシステム処理部
３０５：  ICカードシステムデータベース
３０６：  ICカードコマンド要求
３０７：  ICカードコマンド応答
４０１：  アプリケーション層
４０２：  OS層
４０３：  ハードウェア層
４０４、４０５、４０６：  ICカードアプリケーション
４０７：  通信処理部
４０８：  インタープリタ
４０９：  セキュリティ機構
５０１：  利用者
５０２：  コレータシステム
５０３：  サービス提供管理システム
５０４：  カード発行管理システム
１３０１：  カードポリシを管理するDB構造例
１３０２：  APポリシを管理するDB構造例。
【図１】
2005182435.tif 000003
【図２】
2005182435.tif 000004
【図３】
2005182435.tif 000005
【図４】
2005182435.tif 000006
【図５】
2005182435.tif 000007
【図６】
2005182435.tif 000008
【図７】
2005182435.tif 000009
【図８】
2005182435.tif 000010
【図９】
2005182435.tif 000011
【図１０】
2005182435.tif 000012
【図１１】
2005182435.tif 000013
【図１２】
2005182435.tif 000014
【図１３】
2005182435.tif 000015