JP4496771B2 - Ｉｃカードシステム及びアプリケーション搭載方法 - Google Patents

Ｉｃカードシステム及びアプリケーション搭載方法 Download PDF

Info

Publication number
JP4496771B2
JP4496771B2 JP2003421961A JP2003421961A JP4496771B2 JP 4496771 B2 JP4496771 B2 JP 4496771B2 JP 2003421961 A JP2003421961 A JP 2003421961A JP 2003421961 A JP2003421961 A JP 2003421961A JP 4496771 B2 JP4496771 B2 JP 4496771B2
Authority
JP
Japan
Prior art keywords
card
policy
application
management system
attribute information
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
Application number
JP2003421961A
Other languages
English (en)
Other versions
JP2005182435A5 (ja
JP2005182435A (ja
Inventor
暁子 佐藤
雄介 三科
正規 及川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2003421961A priority Critical patent/JP4496771B2/ja
Priority to EP04014247A priority patent/EP1544808A1/en
Priority to US10/869,891 priority patent/US7487920B2/en
Publication of JP2005182435A publication Critical patent/JP2005182435A/ja
Publication of JP2005182435A5 publication Critical patent/JP2005182435A5/ja
Application granted granted Critical
Publication of JP4496771B2 publication Critical patent/JP4496771B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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
    • 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/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G06Q20/35765—Access rights to memory zones

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Stored Programmes (AREA)
  • Credit Cards Or The Like (AREA)

Description

本発明は、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構造例。

Claims (12)

  1. ＩＣカードリーダライタを介しＩＣカードに接続し、
    ネットワークまたは専用線を介し、ＩＣカード発行業務を行い且つ前記ＩＣカードの属性情報を保存するカード発行管理データベースを有するカード発行管理システムに接続し、
    前記ネットワークまたは前記専用線を介し、ＩＣカードのアプリケーションによるサービス提供業務を行い且つ前記アプリケーションの属性情報を保存するサービス提供管理データベースを有するサービス提供管理システムとに接続するコレータシステムであって、
    前記ＩＣカードへの前記アプリケーションの搭載要求を受け、
    前記アプリケーションの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるカードポリシを、前記カード発行管理システムへ要求、取得し、
    前記ＩＣカードの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるアプリケーションポリシを、前記サービス提供管理システムへ要求、取得し、
    前記カードポリシを解析して特定した前記カードポリシの判定に必要な前記アプリケーションの属性情報の項目と、前記カードポリシが指定する標記方法である定義フォーマットとを前記サービス提供管理システムに要求し、
    前記サービス提供管理データベースから、前記定義フォーマットに従い変換された前記カードポリシの判定に必要な前記ＩＣカードのアプリケーションの属性情報の項目を取得し、
    前記アプリケーションポリシを解析して特定した前記アプリケーションポリシの判定に必要な前記ＩＣカードの属性情報の項目と、前記アプリケーションポリシが指定する定義フォーマットとを前記カード発行管理システムへ要求し、
    前記カード発行管理データベースから、前記定義フォーマットに従い変換された前記アプリケーションポリシの判定に必要な前記ＩＣカードの属性情報の項目を取得し、
    前記変換されたＩＣカードのアプリケーションの属性情報により、前記カードポリシを判定し、
    前記変換されたＩＣカードの属性情報により、前記アプリケーションポリシを判定し、
    前記アプリケーションの前記ＩＣカードへの搭載可否を判定することを特徴とするコレータシステム。
  2. ＩＣカードリーダライタを介しＩＣカードに接続し、
    ネットワークまたは専用線を介し、ＩＣカード発行業務を行い且つ前記ＩＣカードの属性情報を保存するカード発行管理データベースを有するカード発行管理システムに接続し、
    前記ネットワークまたは前記専用線を介し、ＩＣカードのアプリケーションによるサービス提供業務を行い且つ前記アプリケーションの属性情報を保存するサービス提供管理データベースを有するサービス提供管理システムとに接続するコレータシステムにおける前記アプリケーションの前記ＩＣカードへの搭載可否の判定方法であって、
    前記ＩＣカードへの前記アプリケーションの搭載要求を受け、
    前記アプリケーションの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるカードポリシを、前記カード発行管理システムへ要求、取得し、
    前記ＩＣカードの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるアプリケーションポリシを、前記サービス提供管理システムへ要求、取得し、
    前記カードポリシを解析して特定した前記カードポリシの判定に必要な前記アプリケーションの属性情報の項目と、前記カードポリシが指定する標記方法である定義フォーマットとをサービス提供管理システムへ要求し、
    前記サービス提供管理データベースから、前記定義フォーマットに従い変換された前記カードポリシの判定に必要な前記ＩＣカードのアプリケーションの属性情報の項目を取得し、
    前記アプリケーションポリシを解析して特定した前記アプリケーションポリシの判定に必要な前記ＩＣカードの属性情報の項目と、前記アプリケーションポリシが指定する定義フォーマットとをカード発行管理システムへ要求し、
    前記カード発行管理データベースから、前記定義フォーマットに従い変換された前記アプリケーションポリシの判定に必要な前記ＩＣカードの属性情報の項目を取得し、
    前記変換されたＩＣカードのアプリケーションの属性情報により、前記カードポリシを判定し、
    前記変換されたＩＣカードの属性情報により、前記アプリケーションポリシを判定し、
    前記アプリケーションの前記ＩＣカードへの搭載可否を判定することを特徴とする判定方法。
  3. ＩＣカード発行業務を行うカード発行管理システムであって、
    ＩＣカードのアプリケーションによるサービス提供業務を行いＩＣカードの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるアプリケーションポリシを記憶するサービス提供管理システムと、前記カードポリシと前記アプリケーションポリシの判定を行うコレータシステムに、ネットワークまたは専用線を介し接続され、
    ＩＣカードのアプリケーションの属性情報に対して要求する前記アプリケーションの搭載の許可条件であるカードポリシと、前記ＩＣカードの属性情報を保存するカード発行管理データベースを有し、
    前記コレータシステムからのカードポリシ取得要求に応じ、前記カードポリシを前記コレータシステムに送信し、
    前記コレータシステムに指定される前記ＩＣカードの属性情報の項目を前記カード発行管理データベースから抽出し、前記アプリケーションポリシにより指定される標記方法である定義フォーマットに従いＩＣカードの属性情報を変換し、前記コレータシステムに送信することを特徴とするカード発行管理システム。
  4. 請求項３に記載のカード発行管理システムであって、
    前記カード発行管理データベースは、定義フォーマットと前記ＩＣカードの属性情報との間のマッピング規則であるマッピング情報を保存し、
    前記カード発行管理システムは、
    前記定義フォーマットに対応する前記マッピング規則を検索し、
    前記指定されたＩＣカードの属性情報の項目を前記検索されたマッピング規則に従って抽出し、
    前記抽出された項目を前記定義フォーマットに従って変換し、前記コレータシステムに送信することを特徴とするカード発行管理システム。
  5. 請求項３または４に記載のカード発行管理システムであって、
    前記定義フォーマットは複数あることを特徴とするカード発行管理システム。
  6. 請求項５に記載のカード発行管理システムであって、
    前記カード発行管理データベースが、
    前記複数の定義フォーマットのそれぞれ対応する複数の前記マッピング規則情報を保存することを特徴とするカード発行管理システム。
  7. 請求項３から６のいずれか一つに記載のカード発行管理システムであって、
    前記定義フォーマットは、Ｗｅｂサーバにて管理され、
    前記カード発行管理システムは前記Ｗｅｂサーバにアクセスすることにより、前記定義フォーマットを利用することを特徴とするカード発行管理システム。
  8. ＩＣカードのアプリケーションによるサービス提供業務を行うサービス提供管理システムであって、ＩＣカードのアプリケーションの属性情報に対して要求される前記アプリケーションの搭載の許可条件であるカードポリシを記録し、ＩＣカード発行業務を行うカード発行管理システムと、前記カードポリシと前記アプリケーションポリシの判定を行うコレータシステムに、ネットワークまたは専用線を介し接続され、
    ＩＣカードの属性情報に対して要求する前記アプリケーションの搭載の許可条件であるアプリケーションポリシと、前記アプリケーションの属性情報を所定のフォーマットで保存するサービス提供管理データベースを有し、
    前記コレータシステムからのアプリケーションポリシ取得要求に応じ、前記アプリケーションポリシを前記コレータシステムに送信し、
    前記コレータシステムに指定される前記アプリケーションの属性情報の項目を前記サービス提供管理データベースから抽出し、前記カードポリシにより指定される標記方法である定義フォーマットに従いＩＣカードのアプリケーションの属性情報を変換し、前記コレータシステムに送信することを特徴とするサービス提供管理システム。
  9. 請求項８に記載のサービス提供管理システムであって、
    前記サービス提供管理データベースは、定義フォーマットと前記ＩＣカードのアプリケーションの属性情報との間のマッピング規則であるマッピング情報を保存し、
    前記サービス提供管理システムは、
    前記定義フォーマットに対応する前記マッピング規則を検索し、
    前記指定されたＩＣカードのアプリケーションの属性情報の項目を前記検索されたマッピング規則に従って抽出し、
    前記抽出された項目を前記定義フォーマットに従って変換し、前記コレータシステムに送信することを特徴とするサービス提供管理システム。
  10. 請求項８または９に記載のサービス提供管理システムであって、
    前記定義フォーマットは複数あることを特徴とするサービス提供管理システム。
  11. 請求項１０に記載のサービス提供管理システムであって、
    前記サービス提供管理データベースが、
    前記複数の定義フォーマットのそれぞれ対応する複数の前記マッピング規則情報を保存することを特徴とするサービス提供管理システム。
  12. 請求項８から１１のいずれか一つに記載のサービス提供管理システムであって、
    前記定義フォーマットは、Ｗｅｂサーバにて管理され、
    前記サービス提供管理システムは前記Ｗｅｂサーバにアクセスすることにより、前記定義フォーマットを利用することを特徴とするサービス提供管理システム。
JP2003421961A 2003-12-19 2003-12-19 Ｉｃカードシステム及びアプリケーション搭載方法 Expired - Fee Related JP4496771B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2003421961A JP4496771B2 (ja) 2003-12-19 2003-12-19 Ｉｃカードシステム及びアプリケーション搭載方法
EP04014247A EP1544808A1 (en) 2003-12-19 2004-06-17 Integrated circuit card system and application loading method
US10/869,891 US7487920B2 (en) 2003-12-19 2004-06-18 Integrated circuit card system and application loading method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003421961A JP4496771B2 (ja) 2003-12-19 2003-12-19 Ｉｃカードシステム及びアプリケーション搭載方法

Publications (3)

Publication Number Publication Date
JP2005182435A JP2005182435A (ja) 2005-07-07
JP2005182435A5 JP2005182435A5 (ja) 2006-09-07
JP4496771B2 true JP4496771B2 (ja) 2010-07-07

Family

ID=34510676

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003421961A Expired - Fee Related JP4496771B2 (ja) 2003-12-19 2003-12-19 Ｉｃカードシステム及びアプリケーション搭載方法

Country Status (3)

Country Link
US (1) US7487920B2 (ja)
EP (1) EP1544808A1 (ja)
JP (1) JP4496771B2 (ja)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101048898B (zh) * 2004-10-29 2012-02-01 麦德托尼克公司 锂离子电池及医疗装置
JP2006134236A (ja) * 2004-11-09 2006-05-25 Canon Inc プロファイル取得方法、装置、プログラム、および、記憶媒体
FR2896323B1 (fr) * 2006-01-16 2008-10-31 Oberthur Card Syst Sa Procede de generation d'un profil pour la personnalisation d'une entite electronique et systeme associe
DE102006042723A1 (de) * 2006-09-12 2008-03-27 Vodafone Holding Gmbh Chipkarte und Verfahren zur softwarebasierten Modifikation einer Chipkarte
US8060620B2 (en) * 2006-10-05 2011-11-15 Microsoft Corporation Profile deployment using a generic format
US20090077118A1 (en) * 2007-03-16 2009-03-19 Novell, Inc. Information card federation point tracking and management
US20090249430A1 (en) * 2008-03-25 2009-10-01 Novell, Inc. Claim category handling
US20090077655A1 (en) * 2007-09-19 2009-03-19 Novell, Inc. Processing html extensions to enable support of information cards by a relying party
US20090077627A1 (en) * 2007-03-16 2009-03-19 Novell, Inc. Information card federation point tracking and management
US8087060B2 (en) * 2007-03-16 2011-12-27 James Mark Norman Chaining information card selectors
US20090204622A1 (en) * 2008-02-11 2009-08-13 Novell, Inc. Visual and non-visual cues for conveying state of information cards, electronic wallets, and keyrings
US20090178112A1 (en) * 2007-03-16 2009-07-09 Novell, Inc. Level of service descriptors
US20090228885A1 (en) * 2008-03-07 2009-09-10 Novell, Inc. System and method for using workflows with information cards
US8151324B2 (en) 2007-03-16 2012-04-03 Lloyd Leon Burch Remotable information cards
US20090199284A1 (en) * 2008-02-06 2009-08-06 Novell, Inc. Methods for setting and changing the user credential in information cards
US20090204542A1 (en) * 2008-02-11 2009-08-13 Novell, Inc. Privately sharing relying party reputation with information card selectors
US20090205035A1 (en) * 2008-02-11 2009-08-13 Novell, Inc. Info card selector reception of identity provider based data pertaining to info cards
US20090217368A1 (en) * 2008-02-27 2009-08-27 Novell, Inc. System and method for secure account reset utilizing information cards
US8079069B2 (en) * 2008-03-24 2011-12-13 Oracle International Corporation Cardspace history validator
US20090272797A1 (en) * 2008-04-30 2009-11-05 Novell, Inc. A Delaware Corporation Dynamic information card rendering
US20100011409A1 (en) * 2008-07-09 2010-01-14 Novell, Inc. Non-interactive information card token generation
US20100031328A1 (en) * 2008-07-31 2010-02-04 Novell, Inc. Site-specific credential generation using information cards
US8561172B2 (en) 2008-08-29 2013-10-15 Novell Intellectual Property Holdings, Inc. System and method for virtual information cards
US20100095372A1 (en) * 2008-10-09 2010-04-15 Novell, Inc. Trusted relying party proxy for information card tokens
US8083135B2 (en) * 2009-01-12 2011-12-27 Novell, Inc. Information card overlay
US8632003B2 (en) * 2009-01-27 2014-01-21 Novell, Inc. Multiple persona information cards
US20100251353A1 (en) * 2009-03-25 2010-09-30 Novell, Inc. User-authorized information card delegation
JP2016207069A (ja) * 2015-04-27 2016-12-08 株式会社東芝 Ｉｃカード発行用のデータ処理装置、ｉｃカードの発行データ生成プログラム、および、ｉｃカードの発行データ生成方法
CN104994494B (zh) * 2015-05-07 2018-11-13 深圳市数智国兴信息科技有限公司 一种一卡通服务的实现方法及系统
JP6372548B2 (ja) * 2016-11-17 2018-08-15 大日本印刷株式会社 発行支援サーバ及び発行支援プログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001236232A (ja) * 2000-02-25 2001-08-31 Ntt Data Corp Ｉｃカードシステム、ｉｃカード、ｉｃカード処理方法及び記録媒体
JP2002133373A (ja) * 2000-10-27 2002-05-10 Nippon Telegr & Teleph Corp <Ntt> Ｉｃカード運用管理システムおよび方法
JP2003186734A (ja) * 2001-12-21 2003-07-04 Dainippon Printing Co Ltd 電子フォームデータコンバートシステム、サーバ、開発クライアント、プログラム、記録媒体
JP2003187190A (ja) * 2001-12-19 2003-07-04 Hitachi Ltd Ｉｃカード管理システム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2624160B2 (ja) * 1993-12-08 1997-06-25 日本電気株式会社 データフォーマット変換装置
US5889941A (en) * 1996-04-15 1999-03-30 Ubiq Inc. System and apparatus for smart card personalization
US6575372B1 (en) * 1997-02-21 2003-06-10 Mondex International Limited Secure multi-application IC card system having selective loading and deleting capability
US5969318A (en) * 1997-11-24 1999-10-19 Mackenthun; Holger Gateway apparatus for designing and issuing multiple application cards
AU770396B2 (en) * 1998-10-27 2004-02-19 Visa International Service Association Delegated management of smart card applications
US6402028B1 (en) * 1999-04-06 2002-06-11 Visa International Service Association Integrated production of smart cards

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001236232A (ja) * 2000-02-25 2001-08-31 Ntt Data Corp Ｉｃカードシステム、ｉｃカード、ｉｃカード処理方法及び記録媒体
JP2002133373A (ja) * 2000-10-27 2002-05-10 Nippon Telegr & Teleph Corp <Ntt> Ｉｃカード運用管理システムおよび方法
JP2003187190A (ja) * 2001-12-19 2003-07-04 Hitachi Ltd Ｉｃカード管理システム
JP2003186734A (ja) * 2001-12-21 2003-07-04 Dainippon Printing Co Ltd 電子フォームデータコンバートシステム、サーバ、開発クライアント、プログラム、記録媒体

Also Published As

Publication number Publication date
EP1544808A1 (en) 2005-06-22
US7487920B2 (en) 2009-02-10
US20050137737A1 (en) 2005-06-23
JP2005182435A (ja) 2005-07-07

Similar Documents

Publication Publication Date Title
JP4496771B2 (ja) Ｉｃカードシステム及びアプリケーション搭載方法
US6658461B1 (en) Method of, system for, and computer program product for providing a user interface for configuring connections between a local workstation file system and a remote host file system
US7650325B2 (en) Dynamic interface adapter for integration of source and target applications
CN101151608B (zh) 开发人员容易地找出或扩展系统上周知位置的能力
KR101219875B1 (ko) 메타데이터 구동 비즈니스 로직 프로세싱을 위한 방법 및장치
US7191288B2 (en) Method and apparatus for providing an application on a smart card
CN1906613B (zh) 产生可扩展的文件系统元数据和文件系统内容处理的系统和方法
EP1039380B1 (en) Method for exchanging data between a Java System Database and a LDAP directory
EP1965333B1 (en) File server for translating user identifier
CN102164050B (zh) 日志解析方法及日志解析节点设备
US20020032775A1 (en) System and method for transmitting and retrieving data via a distributed persistence framework
US20030028614A1 (en) Portable storage media and method of utilizing remote storage unit on network as auxiliary memory of local computer by using the same
EP1852784A2 (en) Method and system of implementing recorded data for automating internet interactions
CN100485685C (zh) 用于数据存储服务器的自动虚拟化的设备、系统和方法
US20050184164A1 (en) Method and apparatus for installing an application onto a smart card
US20070050751A1 (en) Automatic interoperation with legacy POS service and control objects
KR100537058B1 (ko) 마크 데이터를 효율적으로 제공하기 위한 온라인 마크데이터 제공 시스템 및 방법
JP4445941B2 (ja) 顧客データベース管理装置及び顧客データベース管理プログラム
US8145724B1 (en) Method of, system for, and computer program product for providing a data structure for configuring connections between a local workstation file system and a remote host file system
RU2377641C2 (ru) Система регистрационной информации для использования в вычислительной среде
US8595095B2 (en) Framework for integrated storage of banking application data
JP3464881B2 (ja) 辞書構築装置および方法
CN101286167A (zh) 用于访问物理数据存储器中的文件的系统和方法
US7895245B2 (en) Methods and systems for managing data stored on a contactless flash memory device
US20010051899A1 (en) Document managing apparatus for managing transaction slip data in electronic commerce

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20060424

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060721

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060721

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090708

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090714

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090908

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: 20100323

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100405

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130423

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130423

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140423

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees