(57)【特許請求の範囲】
【請求項１】
スマートカードに格納されている第１のスマートカード情報およびカードオブジェクトデータベースシステムに格納されている第２のスマートカード情報が同期したスマートカード情報に等しくなるように、該第１のスマートカード情報を該第２のスマートカード情報に同期させるシステムであって、
該システムは、
第１の企業に関連付けられた第１の企業データ収集ユニットと第２の企業に関連付けられた第２の企業データ収集ユニットとを含む複数の企業に関連付けられた複数の企業データ収集ユニットと、
該スマートカードと、該第１および該第２の企業データ収集ユニットのそれぞれとに結合されたアクセスポイントデバイスと、
該第１および第２の企業データ収集ユニットに結合され、該第２のスマートカード情報を格納するように構成されたカードオブジェクトデータベースシステムと、
少なくとも１つの企業データ同期インターフェースと、該複数の企業データ収集ユニットとに結合された更新ロジックシステムと
を備え、
該第１および第２の企業データ収集ユニットのうちの少なくとも１つは、アクセスポイントデバイスと更新ロジックシステムとに結合され、ｉ）該アクセスポイントデバイスからの更新情報、およびｉｉ）該更新ロジックシステムからの保留情報のうちの少なくとも１つを受信し、格納するように構成されており、該更新情報は、該第２のスマートカード情報との組み合わせの結果として該第１のスマートカード情報になるスマートカード情報を記述し、該保留情報は、該第１のスマートカード情報および該第２のスマートカード情報のいずれかとの組み合わせの結果として該同期したスマートカード情報になるスマートカード情報を記述し、該保留情報は、該スマートカードを含まない手段を介して行われる取引の情報であり、該保留情報は、保留データベースに格納されており、
該アクセスポイントデバイスは、ｉ）該第１および第２の企業データ収集ユニットのうちの少なくとも１つからの該保留情報、およびｉｉ）該スマートカードからの該更新情報のうちの少なくとも１つを受信するように構成されており、
該カードオブジェクトデータベースシステムは、該第１および第２の企業データ収集ユニットのうちの少なくとも１つからの該更新情報および該保留情報のうちの少なくとも１つを受信し、該受信された更新情報および該受信された保留情報のうちの少なくとも１つを用いて、該格納されている第２のスマートカード情報を更新するように構成されており、
該更新ロジックシステムは、該複数の企業データ収集ユニットのうちの１つの企業データ収集ユニットから該更新情報を受信し、該複数の企業データ収集ユニットのうちの第２の企業データ収集ユニットに該更新情報を送信するように構成されており、
該スマートカードが該アクセスポイントデバイスに挿入された際、該アクセスポイントデバイスは、該保留データベースに問い合わせることにより、該第１および第２の企業データ収集ユニットのうちの少なくとも１つに該保留情報が格納されているかどうかを判定するように構成されており、該保留情報が存在する場合には、該アクセスポイントデバイスは、該第１および第２の企業データ収集ユニットのうちの少なくとも１つから該保留情報を受信し、
該スマートカードは、該アクセスポイントデバイスから該保留情報を受信し、該受信された保留情報を用いて、該格納されている第１のスマートカード情報を更新するように構成されており、
該企業データ同期インターフェースは、複数の企業ネットワークのうちの１つに結合されており、
該複数の企業ネットワークのそれぞれは、企業ネットワークデバイスを含み、
該企業ネットワークデバイスは、該保留情報を生成し、該保留情報を該少なくとも１つの企業データ同期インターフェースのうちの少なくとも１つに送信するように構成されており、その後、該少なくとも１つの企業データ同期インターフェースのうちの該少なくとも１つは、該保留情報を該更新ロジックシステムに送信し、その後、該更新ロジックシステムは、該保留情報を該複数の企業データ収集ユニットのうちの少なくとも１つに送信し、その後、該複数の企業データ収集ユニットのうちの該少なくとも１つは、該保留情報を該アクセスポイントデバイスに送信する、システム。
【請求項２】
前記アクセスポイントデバイスと通信するように構成され、該アクセスポイントデバイスと前記複数の企業データ収集ユニットと該企業データ同期インターフェースとに結合されたセキュアサポートクライアントサーバをさらに備え、
該セキュアサポートクライアントサーバは、該アクセスポイントデバイスに情報を送信し、該アクセスポイントデバイスから情報を受信するようにさらに構成されており、
該アクセスポイントデバイスは、第１の関数のセットを用いて、該スマートカードから受信された該更新情報を処理し、該処理に基づいて第１のスマートカード処理情報を生成し、該第１のスマートカード処理情報を該スマートカードに送信するように構成されており、
該セキュアサポートクライアントサーバは、該アクセスポイントデバイスから該更新情報を受信し、該第１の関数のセットに等しくない第２の関数のセットを用いて、該アクセスポイントデバイスから受信された該更新情報を処理し、該処理に基づいて、第２のスマートカード処理情報を生成し、該第２のスマートカード処理情報を該アクセスポイントデバイスを介して該スマートカードに送信するようにさらに構成されている、請求項１に記載のシステム。
【請求項３】
前記カードオブジェクトデータベースシステムに結合された個人化するシステムをさらに備え、
該個人化するシステムは、
前記複数の企業のうちの少なくとも１つに関連している情報を記述するスマートカードリクエスト情報を受信するように構成されているカード管理デバイスと、
該カード管理デバイスと該複数の企業ネットワークデバイスとに結合された収集アプリケーションデバイスであって、該カード管理デバイスから該スマートカードリクエスト情報を受信し、かつ、該スマートカードリクエスト情報に記述されている該少なくとも１つの企業に関連付けられている該複数の企業ネットワークデバイスのうちの少なくとも１つの企業ネットワークデバイスから少なくとも１つの個人企業情報を受信するように構成されている、収集アプリケーションデバイスと、
該スマートカードオブジェクトデータベースシステムと該収集アプリケーションデバイスとに結合された個人化ユーティリティデバイスであって、該スマートカードオブジェクトデータベースシステムから該スマートカードリクエスト情報および少なくとも１つの個人企業情報を受信し、該受信されたスマートカードリクエスト情報と該受信された少なくとも１つの個人企業情報とに基づいて、該スマートカードにダウンロードされるべき情報を記述するアプリケーションオブジェクト情報を生成するように構成されている、個人化ユーティリティデバイスと、
該個人化ユーティリティデバイスとセキュリティサーバとに結合された個人化サービスデバイスであって、該個人化ユーティリティデバイスから該アプリケーションオブジェクト情報を受信し、該複数の企業ネットワークデバイスのうちの少なくとも１つの企業ネットワークデバイスに対応するキー情報をリクエストするために、該セキュリティサーバにキーリクエスト情報を送信し、該セキュリティサーバから該キー情報を受信し、該アプリケーションオブジェクト情報および該キー情報に基づいて該スマートカードを生成する構成されている、個人化サービスデバイスと
を備え、
該セキュリティサーバは、該個人化ユーティリティデバイスと複数のキーシステムデバイスのうちの少なくとも１つに結合されており、該複数のキーシステムデバイスのそれぞれは、該複数の企業のうちの少なくとも１つの企業に関連付けられており、該複数のキーシステムのそれぞれの上に格納されている該少なくとも１つの企業に関連付けられている少なくとも１つのキー情報を有し、該個人化サービスデバイスから該キーリクエスト情報と該個人化ユーティリティデバイスから該スマートカードリクエストに関連する情報を記述する個人情報とを受信し、該少なくとも１つの企業ネットワークデバイスに対応する該キー情報を該個人化サービスデバイスに送信するように構成されている、請求項１に記載のシステム。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、一般に商業取引用の集積回路カード（「スマートカード」）の使用に関し、さらに詳細には、分散された取引システムにおけるスマートカード情報を動的に同期および個人化するための技術に関する。
【０００２】
（背景技術および技術的課題）
インターネット取引、電子データ処理、および半導体デバイス技術における近年の進歩により、スマートカード技術に対する関心が高まってきた。概して、スマートカードは、財布程度の大きさ（または、それよりも小さい）カードであり、カード内にデータを格納および管理するためのマイクロプロセッサまたはマイクロコントローラを組み込んでいる。スマートカードは、磁気ストライプカードおよび金額記憶カードよりも複雑であり、高度な記憶管理特性および安全特性を特徴とする。マルチ機能カードは、例えば、クレジット、デビット、記憶した値、ロイヤルティ、および他の多くのアプリケーションの全てを１枚のカード内でサポートするように、しばしば構成される。一般的なマルチ機能のスマートカードは、カードのプラスチック内に埋め込まれたマイクロコントローラを含み、このマイクロコントローラは、カード外部に備えた外部接触アレイに電気的に接続される。スマートカードマイクロコントローラは一般に、ユーザデータを格納するための電気的に消去可能およびプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、作業格納のためのランダムアクセスメモリ（ＲＡＭ）、およびカードオペレーティングシステムを格納するための読み取り専用メモリ（ＲＯＭ）を含む。これらの機能を制御するには、比較的単純なマイクロコントローラで十分である。よって、約８ＫのＥＥＰＲＯＭメモリを備えた８ビット５ＭＨｚのマイクロコントローラ（例えば、Ｍｏｔｏｒｏｌａ６８０５、またはＩｎｔｅｌ８０５１等のマイクロコントローラ）を用いるスマートカードも珍しくない。
【０００３】
多くの規格が集積回路カードのさまざまな局面に対応して開発されてきた。例えば、ＩＳＯ  ７８１６−１、Ｐａｒｔ  １：Ｐｈｙｓｉｃａｌ  ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ（１９８７年）；ＩＳＯ  ７８１６−２、Ｐａｒｔ  ２：Ｄｉｍｅｎｓｉｏｎｓ  ａｎｄ  ｌｏｃａｔｉｏｎ  ｏｆ  ｔｈｅ  ｃｏｎｔａｃｔｓ（１９８８年）；ＩＳＯ  ７８１６−３，Ｐａｒｔ  ３：Ｅｌｅｃｔｒｏｎｉｃ  ｓｉｇｎａｌｓ  ａｎｄ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｐｒｏｔｏｃｏｌｓ（１９８９年、Ａｍｄ．１  １９９２年、Ａｍｄ．２  １９９４年）；ＩＳＯ  ７８１６−４、Ｐａｒｔ  ４：Ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ  ｃｏｍｍａｎｄｓ  ｆｏｒ  ｉｎｔｅｒｃｈａｎｇｅ（１９９５年）；ＩＳＯ  ７８１６−５、Ｐａｒｔ  ５：Ｎｕｍｂｅｒｉｎｇ  ｓｙｓｔｅｍ  ａｎｄ  ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅ  ｆｏｒ  ａｐｐｌｉｃａｔｉｏｎ  ｉｄｅｎｔｉｆｉｅｒｓ（１９９４年、Ａｍｄ．１  １９９５年）；ＩＳＯ／ＩＥＣ  ＤＩＳ  ７８１６−６、Ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ  ｄａｔａ  ｅｌｅｍｅｎｔｓ（１９９５年）；ＩＳＯ／ＩＥＣ  ＷＤ  ７８１６−７、Ｐａｒｔ  ７：Ｅｎｈａｎｃｅｄ  ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ  ｃｏｍｍａｎｄｓ（１９９５年）；およびＩＳＯ／ＩＥＣ  ＷＤ  ７８１６−８、  Ｐａｒｔ  ８：Ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ  ｓｅｃｕｒｉｔｙ  ａｒｃｈｉｔｅｃｔｕｒｅ（１９９５年）。これらの規格は、本明細書中で参考として援用される。さらに、磁気ストライプカードおよびチップカードに関する一般的な情報は、多くの規格テキスト、例えば、Ｚｏｒｅｄａ  ＆  Ｏｔｏｎ、  ＳＭＡＲＴ  ＣＡＲＤＳ（１９９４）、およびＲａｎｋｌ  ＆  Ｅｆｆｉｎｇ、  ＳＭＡＲＴ  ＣＡＲＤ  ＨＡＮＤＢＯＯＫ（１９９７年）において見出すことが可能であり、その内容は、本明細書中で参考として援用される。
【０００４】
スマートカードに関連する取引情報およびアプリケーションの実質的に正確な履歴を、顧客が所有する各スマートカードごとに保持することが望ましい。現在公知のシステムは、スマートカードに格納された情報と、１以上の外部データベースに格納された対応する情報との間の同期を確実にするための、効率的および信頼できる方法を提供しないという点で、一般に不十分である。結果として、現在のシステムでは、紛失したか、または盗難にあったカードが、確実には再発行または最新の情報に更新され得ない。
【０００５】
さらに、現在のシステムは、そのシステムがスマートカードの合同提携者（例えば、Ｈｅｒｔｚ、Ｈｉｌｔｏｎ、その他）等の企業が、スマートカードアプリケーション構造自体を動的に追加、もしくは変更できないという点で、不十分である。すなわち、マルチ機能カードのコンテクストにおいて、カードのファイル構造を、時間および費用がかかるカード再発行のプロセスを行わずに、変更または拡張することがしばしば不可能である。
【０００６】
さらに、マルチアプリケーションで、多数の企業が関係する環境下でのスマートカードの発行および再発行のための公知の方法は、一般には不十分である。さらに詳細には、スマートカードは、しばしば広範囲にわたる企業組織と関連づけられた多数の異なるアプリケーションを含む。セキュリティの目的のために、これらのファイルの書き込み、更新、および読み出しは、一連のアクセス条件規則にもとづいて、特定の当事者に有利に制限される。これらのアクセス条件は、企業等の適切な当事者のみに知られた暗号キーを用いて適切に実行される。よって、Ａｍｅｒｉｃａｎ  Ｅｘｐｒｅｓｓ等のカード発行者は、その機能を実施するために必要なキーへのアクセスを一般的には有さない。公知のシステムは、発行プロセスで用いられる中央格納庫（ｃｅｎｔｒａｌ  ｒｅｐｏｓｉｔｏｒｙ）にキーデータを蓄積することにより、この問題を解決しようと試みた。この方法は、多くの点において不十分であった。最も顕著であるのは、キー情報の中央格納庫内でのセキュリティ侵害が、結果的に多大な損害をもたらすことである。
【０００７】
よって、これらおよび他の従来技術の限界を克服するための技術が必要とされている。さらに詳細には、マルチ機能のスマートカードの安全および効率的個人化、および動的な同期を提供するためのシステムが必要とされている。
【０００８】
（発明の要旨）
本発明は、分散された取引システムのコンテクストにおけるスマートカードデータの個人化および同期のための方法および装置を提供することにより、従来技術の限界を克服する。
【０００９】
本発明の１つの局面に従って、ダイナミックスマートカード同期システムは、スマートカード、企業データ収集ユニット、およびカードオブジェクトデータベース更新システムとともに、取引を始めるように構成されるアクセスポイントを含む。例示的ダイナミック同期システム（ＤＳＳ）は、さまざまなスマートカードアクセスポイント、セキュアサポートクライアントサーバ、カードオブジェクトデータベース更新システム（ＣＯＤＵＳ）、１以上の企業データ同期インターフェース（ＥＤＳＩ）、更新ロジックシステム、１以上の企業データ収集ユニット（ＥＤＣＵ）、およびスマートカードを共通して受け付け、且つインターフェースするように構成された１以上のスマートカードアクセスポイントを好適に含む。１つの例示的実施形態において、ＤＳＳは、ＣＯＤＵＳと通信するように構成された、個人化システムおよびアカウント維持システムを含む。
【００１０】
本発明のさらなる局面に従って、マルチ機能スマートカードの個人化は、スマートカード発行プロセスの最終段階の間に、暗号キー情報を発生し、且つ／または複数の企業キーシステムから取り出すように構成されたセキュリティサーバを用いて達成される。
【００１１】
（好適な例示的実施形態の詳細な説明）
以下に、本発明を添付の図面とともに説明する。なお同様の要素は同様の参照符号で示される。
【００１２】
本発明のさまざまな局面にもとづいたシステムは、分散された取引システムのコンテクストにおけるスマートカード、および関連データベースの個人化および動的な同期のための方法および装置を含む。さらに詳細には、次に図１を参照して、例示的ダイナミック同期システム（ＤＳＳ）が、セキュアサポートクライアントサーバ１０４、カードオブジェクトデータベース更新システム１０６（ＣＯＤＵＳ）、１以上の企業データ同期インターフェース１０８（ＥＤＳＩ）、更新ロジックシステム（１１０）、１以上の企業データ収集ユニット１１２（ＥＤＣＵ）、およびスマートカード１２０を共通して受け付け、且つインターフェースするように構成された１以上のスマートカードアクセスポイント１０２を好適に含む。１つの例示的実施形態において、ＤＳＳはまた、ＣＯＤＵＳ１０６と通信するように構成された個人化システム１４０、およびアカウント維持システム１４２を適切に含む。
【００１３】
さらに詳細には、好適な実施形態において、セキュアサポートクライアントサーバ１０４は、企業ネットワーク１１４を介して、ＥＤＳＩ１０８と適切なネットワーク上で接続される。ＥＤＳＩ１０８は、それ自体が企業データ収集ユニット１１２とリンクしている更新ロジックシステム１１０にリンクする。企業データ収集ユニット１１２は、ＣＯＤＵＳ１０６およびセキュアサポートクライアントサーバ１０４とリンクする。一般に、より詳細に後述するように、各企業（例えば、提携航空会社、提携ホテル、提携旅行代理店等）は、対応するＥＤＳＩ１０８、企業ネットワーク１１４、およびＥＤＣＵ１１２と好適に関連づけられる。すなわち、ＥＤＣＵ１１２（ａ）は、ＥＤＳＩ１０８（ａ）および企業ネットワーク１１４（ａ）に対応し、ＥＤＣＵ１１２（ｂ）は、ＥＤＳＩ１０８（ｂ）および企業ネットワーク１１４（ｂ）と対応するなどである。ＤＳＳは、対応する企業の数に応じて、このような機能ブロックを任意の数だけ含む。
【００１４】
個人化システム１４０は、スマートカード１２０の発行元として適切に機能する。すなわち、個人化システム１４０は、初期設定データ（例えば、口座番号、シリアルナンバー、デフォルトの選好、その他）で占められる所定のファイル構造を提供することにより、顧客が使用するためのスマートカードを作成および発行する。これに関して、ＣＯＤＵＳ１０６は、カードの破損、紛失、および盗難時に、最新のデータを提供することによりカードの再発行を容易にするために、個人化システム１４０とインターフェースする。個人化システム１４０は、図９とともに詳細に後述される。
【００１５】
アカウント維持システム１４２は、顧客サービスの目的のために提供され、この範囲において、カード所有者の苦情、質問、および顧客による他の入力のための入り口として機能する。ＣＯＤＵＳ１０６は、顧客サービスの代理者および／または自動システムが、カード所有者の問題を処理することを支援するために、アカウント維持システム１４２と適切に通信する。
【００１６】
（スマートカードアクセスポイント）
スマートカードアクセスポイント１０２により、カード所有者が各種の手段を介して、分散された取引システムへのアクセスを獲得することが可能になる。このようなアクセスポイントは、例えば、標準的な家庭用電話器、各種のＰＣＳ無線システム、公衆電話、パームトップ型コンピュータ、ノート型コンピュータ、インターネットワークステーション、自動窓口機（ＡＴＭ）、販売時点情報管理端末（ＰＯＳ）、独立型キオスク、ネットワークコンピュータ（ＮＣ）、携帯情報端末（ＰＤＡ）、または他のいずれの適切に構成された通信装置を含む。アクセスポイント１０２は、（ＰＤＡおよび携帯電話と同様に）持ち運び可能か、または、例えば、航空会社の発券および搭乗場所、レンタカー施設、ホテルロビー、旅行代理店、およびモールの中心に位置し得る。また、企業は、従業員の出張を合理化するために、アクセスポイント１０２を主催しようと考えるかもしれない。好適な実施形態において、各種のアクセスポイント１０２は、ＩＳＯ―７８１６規格の関連部分に従って、接触型の（ｃｏｎｔａｃｔ−ｂａｓｅｄ）スマートカード１２０とインターフェースするように構成される。
【００１７】
（セキュアサポートクライアントサーバ）
セキュアサポートクライアントサーバ１０４は、取引中に用いられる個々のアクセスポイント１０２からなくなったいずれの機能も、適切であればどこにでも提供する。サーバ１０４はまた、アクセスポイント１０２から適切なＥＤＳＩ１０８および／またはＥＤＣＵ１１２へのメッセージのルーティングを適切に処理する。
【００１８】
次に図１および２を参照して、例示的セキュアサポートクライアントサーバ１０４は、セキュリティエンジン２０２、補足アプリケーションサポート２０４、およびルータ２０６を含む。セキュリティエンジン２０２は、サーバ１０４、ＥＤＳＵ１１２、および企業ネットワーク１１４間の安全な通信を提供するための適切なハードウェアおよび／またはソフトウェアを含む。さらに詳細には、セキュリティエンジン２０２は、着信および発信メッセージパケットとともに、認証、データ暗号化、およびデジタル署名技術を利用する。各種の従来のセキュリティアルゴリズムは、本発明のコンテクストにおいて適切であり、例えば、ＤＥＳの暗号化、ＲＳＡ認証、および各種の他の対称的および非対称的暗号技術を含む。
【００１９】
補足アプリケーションサポート２０４は、特定のアクセスポイント１０２機能に関連した適切なハードウェアおよび／またはソフトウェアコンポーネントを好適に含む。さらに詳細には、サーバ１０４は、取引中に利用されるアクセスポイント１０２の性質を適切に見極める。アクセスポイント１０２が、リクエストされた取引を実行するための適切なソフトウェアを含まなければ、サーバ１０４は、個々のＥＤＳＩ１０８および／またはＥＤＣＵ１１２との取引を完成する機能（すなわち、ソフトウェアモジュール）を供給する。この補足的な機能は、ＤＳＳを含む各種ネットワーク上に送信されたメッセージパケット（さらに詳細に後述される）を適切にフォーマットするためのソフトウェアモジュールを特に含む。例えば、それ自体が独立型のスマートカードリーダーであるアクセスポイント１０２を介して、取引が行われる場合に、スマートカードリーダーは、それ自体では、データ取引能力を持たない方式でのみ、スマートカード１０２とのメッセージの送受信が可能であるので、ほとんど全ての機能がサーバ１０４により供給される。しかしながら、適切に構成されたＰＣが、アクセスポイント１０２に含まれる場合、大半の必要な機能は、ＰＣ内に常駐する各種のソフトウェアモジュールにより供給される。このような場合、サーバ１０４は、さらなるソフトウェアを供給することなくアクセスポイント１０２と各種のメッセージパケットを送受信するだけでよい。追加された機能は、任意の適切な方法、例えば、ポータブルソフトウェアコード（Ｊａｖａ、ＡｃｔｉｖｅＸ、その他）、またはアクセスポイント１０２、カード１２０および／またはサーバ１０４内に常駐する配信されたソフトウェアの使用により供給され得る。
【００２０】
ルータ２０６は、適切なＥＤＣＵ１１２、企業ネットワーク１１４、およびアクセスポイント１０２へのメッセージのルーティングを取り扱う。すなわち、ルータ２０６は、所与のメッセージパケットが送信されるＤＳＳ内の適切な機能ブロックを識別するように構成される。適切な機能ブロックの識別は、多数の方法により行われ得る。好適な実施形態において、この識別は、アクセスポイント１０２から受け取ったリクエストから抽出された情報にキーによって割りつけられた、適切なあて先のリストを含む参照用テーブルの使用により達成される。
【００２１】
本発明の別の実施形態において、セキュアサポートクライアントサーバ１０４は用いられず、アクセスポイント１０２の機能は、サーバ１０４の必要性をなくすために適切に特定される。また、サーバ１０４の機能は、任意の便利な方法で、ＤＳＳコンポーネント全体に割り当てられ、且つ分散され得る。
【００２２】
「取引」という用語が、一般に特定の目的、例えば、デビット／チャージ認証、選好の変更、予約のリクエスト、チケットのリクエスト、その他を実行するためのシステム上で通信される任意のメッセージに言及することは、当業者であれば理解するであろう。図１１は、例えば、提携旅行社とのオンライン取引を実施するコンテクストにおいて有用な例示的取引データ構造を示し、ここで、フィールド名１１０２、データタイプ１１０４（‘Ｃ’はｃｈａｒａｃｔｅｒ（文字）を意味する）、最大バイト長１１０６、および説明１１０８が表形式でリストされている。この例において、他のデータ構造が用いられ得るが、取引メッセージは、コンマで区切られたデータパケットを適切に含む。
【００２３】
（カードオブジェクトデータベース更新システム（ＣＯＤＵＳ））
ＣＯＤＵＳ１０６は、各種の発行済みのスマートカード１２０の状態に関した情報を、適切且つ安全に格納する。次に図１および６を参照して、好適な実施形態において、ＣＯＤＵＳ１０６は、セキュリティエンジン６０２、データ管理モジュール６０４、カードオブジェクトデータベース１１６、カードオブジェクト管理モジュール６０６、および監査ファイル６０８を含む。
【００２４】
セキュリティエンジン６０２は、特に、カードオブジェクトデータベース１１６内に格納された情報に対して適切なセキュリティを提供する。これに関して、セキュリティエンジン６０２は、着信および発信メッセージパケットとともに、各種の認証、データ暗号化、およびデジタル署名技術を利用する。本発明のコンテクストにおいて適切なアルゴリズムは、例えば、ＤＥＳの暗号化、ＲＳＡ認証、および各種の他の対称的および非対称的暗号技術を含む。
【００２５】
データ管理モジュール６０４は、ＣＯＤＵＳ１０６と各種のＥＤＣＵ１１２間と同様に、ＣＯＤＵＳ１０６とアカウント維持１４２間のデータインターフェースとして適切に機能する。さらに詳細には、モジュール６０４は、これらのシステムで用いられるデータフォーマット間の変換および翻訳を行う。例えば、オブジェクトデータベース１０６内に格納されたデータは、ＥＤＣＵ１１２またはアカウント維持１４２により容易に用いられ得るフォーマットでは格納され得ない。従って、データ管理モジュール６０４は、着信および発信データ両方の変換およびフォーマットの実施のための適切なルーチンを含む。
【００２６】
カードオブジェクト管理モジュール６０６は、オブジェクトデータベース１０６内に格納されたデータを編集、更新、削除、同期し、且つそのデータが不正でないことを保証するための適切なデータベースソフトウェアを提供する。各種のデータベースパッケージは、このようなタスクに適しており、例えば、各種の従来の第４世代のリレーショナルデータベース管理システム（４ＧＬ  ＲＤＢＭＳ）を含む。
【００２７】
監査ファイル６０８は、オブジェクトデータベース１１６への変更を適切に探知するので、ＣＯＤＵＳ１０６内に格納されたカードデータの保全性を保証するために役立つ。さらに詳細には、選好の更新、取引、アプリケーション構造の変更、その他の結果として、オブジェクトデータベース１１６への変更が生じたときに、監査ファイル６０８は、例えば、時間、日付、および変更の性質と内容等の変更に関する適切な情報を探知する。
【００２８】
カードオブジェクトデータベース１１６は、単一のデータベース、または分散したデータベースの集合を含み、各種のスマートカード１２０の既知の状態を格納するために用いられる。一般に、スマートカードの状態は、カードの証印（ｉｎｄｉｃｉａ）の適切な集合により特徴づけられる。好適な実施形態において、ＩＳＯ７８１６にもとづいたデータ構造が用いられ、カードオブジェクトデータベース１１６が、個々のフィールド、ディレクトリ、およびアプリケーションを含むデータと同様に、各種のスマートカード１２０に存在する個々のアプリケーションに関する情報（すなわち、ファイル構造全体）を格納する。カードオブジェクトデータベース１１６に対するファイル構造は、所与のスマートカード１２０に対するデータフィールドの適切な集合を含むように選択される。
【００２９】
（企業データ同期インターフェース）
好適な実施形態において、各種のＥＤＳＩ１０８は、個々の企業に対応するスマートカードデータおよび／またはアプリケーションへの変更を探知する。図１および３を参照して、好適な実施形態において、ＥＤＳＩ１０８は、通信サーバ３０２、セキュリティエンジン３０４、および顧客データベース３０６を含む。
【００３０】
通信サーバ３０２は適切に、企業ネットワーク１１４および更新ロジックシステム１１０との通信を容易にする。これに関して、サーバ３０２は、用いられるコンポーネントの特定の選択の必要に応じて、各種フォーマット、媒体、および通信プロトコル間の翻訳を行うように構成される。
【００３１】
セキュリティエンジン３０４は、顧客データベース３０６との情報のアクセスおよび格納に関して、適切なセキュリティ手段を提供する。セキュリティエンジン３０４は、着信および発信メッセージパケットとともに、各種の認証、データ暗号化、およびデジタル署名技術を利用し得る。本発明のコンテクストにおいて適切なアルゴリズムは、例えば、ＤＥＳの暗号化、ＲＳＡ認証、および各種の他の対称的および非対称的暗号技術を含む。
【００３２】
顧客データベース３０６は、個々の提携先または企業に関するスマートカード情報を格納するための手段を適切に提供する。すなわち、特定の企業（例えば、企業ネットワーク１１４（ａ）を主催している）は、その企業にのみ関連するスマートカード情報を編纂するか、または他者に編纂させるかもしれない。例えば、ホテルチェーンは、ロイヤルティ、選好、およびそのホテルチェーンに特に関連する他のデータを格納するかもしれない。同期の間（より詳細に後述する）、データベース３０６に対するいずれの変更も、システムを介して伝播し、（またはその逆もある）、システム内のいずれかへの変更は、データベース３０６に伝達される。この通信は、好適には、通信サーバ３０２とともに、（セキュリティエンジン３０４を用いて）安全に行われる。
【００３３】
別の実施形態において、ＥＤＳＩ１０８により提供される機能は、対応するＥＤＣＵ１１２にフォールディングされる。すなわち、図示した実施形態が、１以上の物理的に離れたＥＤＳＩ１０８を用いる一方で、対応するＥＤＣＵ１１２機能ブロックにこの機能を組み込むことにより、ＤＳＳをさらに合理化することは有利であり得る。
【００３４】
（更新ロジックシステム）
好適な実施形態において、更新ロジックシステム１１０は、ＥＤＣＵ１１２およびＥＤＳＩ１０８と送受信するカードデータをフォーマットし、且つ安全にルーティングする。次に、図４を参照して、好適な実施形態において、更新ロジックシステム１１０は、ロジックエンジン４０２、データ管理モジュール４０４、セキュリティエンジン４０６、企業更新アドミニストレータ４０８、および企業更新監査モジュール４１０を含む。
【００３５】
ロジックエンジン４０２は、システム全体にわたって、情報の変更を指揮し、且つ分散させるように適切に機能する。よって、ロジックエンジン４０２は、どのモジュール（すなわち、どのＥＤＣＵ１１２、およびどのＥＤＳＩ１０８）が変更を反映させるか決定することができる。
【００３６】
データ管理モジュール４０４は、ＥＤＳＩ１０８と、ＥＤＣＵ１１２間のデータインターフェースとして適切に機能する。さらに詳細には、モジュール４０４は、これらのシステムで用いられるデータフォーマット間の変換および翻訳が可能である。したがって、データ管理モジュール６０４は、着信および発信データ両方の変換およびフォーマットの実施のための適切なルーチンを含む。
【００３７】
セキュリティエンジン４０６は、更新ロジックシステム１１０を介して流れるデータに関して、適切なセキュリティ手段を提供するために用いられる。セキュリティエンジン４０６は、着信および発信メッセージパケットとともに、各種の承認、データ暗号化、およびデジタル署名技術を利用し得る。本発明のコンテクストにおいて適切なアルゴリズムは、例えば、ＤＥＳ暗号、ＲＳＡ認証、および各種の他の対称的および非対称的暗号技術を含む。
【００３８】
企業更新アドミニストレータ４０８は、ＥＤＳＩ１０８と、ＥＤＣＵ１１２間のデータ伝送を維持するために必要な間接的なソフトウェアを適切に含む。
【００３９】
企業更新監査モジュール４１０は、更新ロジックシステム１１０を介して流れる更新情報を適切に探知する。さらに詳細には、（選好の更新、取引、アプリケーション構造の変更、その他の結果として）情報が更新ロジックシステム１１０全体にわたって通信されるときに、監査モジュール４１０は、例えば、時間、日付、および通信の性質と内容等の情報の適切な証印を探知する。
【００４０】
（企業データ収集ユニット）
ＥＤＣＵ１１２は、特定の企業に対応する同期データの伝送を好適に格納し、且つ調整する。図５を参照して、好適な実施形態において、企業データ収集ユニット１１２は、セキュリティエンジン５０８、顧客更新取引データベース５０４、顧客ロイヤルティ取引データベース５１０、顧客保留取引データベース５１４、更新データベース５０２、ＥＤＣＵ監査ファイル５０６、ＥＤＣＵ管理ファイル５１２、およびＥＤＣＵデータ管理モジュール５１６を含む。
【００４１】
セキュリティエンジン５０８は、ＥＤＣＵ１１２を介して流れるデータに関して、適切なセキュリティ手段を提供するために用いられる。この目的のために、セキュリティエンジン４０６は、着信および発信メッセージパケットとともに、各種の認証、データ暗号化、およびデジタル署名技術を活用し得る。本発明のコンテクストにおいて適切なアルゴリズムは、例えば、ＤＥＳの暗号化、ＲＳＡ認証、および各種の他の対称的および非対称的暗号技術を含む。
【００４２】
顧客更新取引データベース５０４は、スマートカード１２０上では更新されたが、更新を必要とする各種のデータベースおよびネットワークにはまだ伝播されていない情報を格納するために用いられる。例えば、スマートカード１２０は、特定の企業との取引の間に、カード所有者の選好を変更するために用いられ得る。この情報は、短期においては、ＣＯＤＵＳ１０６、および適切なＥＤＣＵ１１２およびＥＤＳＩ１０８にファンアウト（ｆａｎｎｅｄ−ｏｕｔ）されるまで、（特定の企業に対する）データベース５０４に格納される。このタイプの取引は、詳細に後述される。
【００４３】
顧客ロイヤルティ取引データベース５１０は、特定の企業または提携者と関連づけられたロイヤルティ情報（例えば、頻繁に飛行機を利用する人、頻繁にホテルに宿泊する人等）を格納するために適切に用いられる。別の実施形態においては、ロイヤルティ取引データベース５１０は、用いられず、それどころか、データベース５１０の機能は、ロイヤルティ取引が、ＥＤＣＵ１１２により探知される単なる別の取引方式となるように、データベース５０２、５１０、および５１４に組み込まれる。
【００４４】
顧客保留取引データベース５１４は、スマートカード１２０を直接用いずに生じた取引に関連する情報を格納するために適切に用いられる。さらに詳細には、選好の変化、およびその他のいくつかの取引は、例えば、標準的な電話機での口頭でのリクエストにより、カードの使用を必要としないチャネルを介して、カード所有者により開始され得る。このような場合、下記においてさらに説明するが、このデータは保留取引データベース５１４に適切に格納される。取引データは、対応するスマートカード１２０がアクセスポイント１２０とともに用いられるまで、データベース５１４内に留まり、スマートカード１２０自体が（ＣＯＤＵＳ１０６と同様に）、この新しい情報に更新される。
【００４５】
更新データベース５０２は、他のタイプの取引、すなわち、更新、ロイヤルティ、または保留として分類され得ない取引を格納するために適切に用いられる。例えば、更新データベース５０２は、詳細に後述するように、ファイル構造更新情報を格納するために用いられ得る。
【００４６】
監査ファイル５０６は、更新データベース５０４、保留データベース５１４、データベース５０２、および、図示した実施形態においては、ロイヤルティデータベース５１０への変更を探知するために用いられる。別の実施形態においては、分離されたロイヤルティデータベース５１０は用いられておらず、監査ファイル５０６は、データベース５０４、５１４、および５０２への変更を探知する。監査ファイル５０６は、それゆえ、個々のファイル内のデータの保全性を保証するために役立つ。
【００４７】
管理ファイル５１２は、ＥＤＣＵ１１２を含む各種データベース、すなわち、データベース５０２、５０４、５１０および５１４内に格納されたデータを編集、更新、削除、同期し、且つそのデータが不正でないことを保証するために必要である適切なデータベースソフトウェアを提供する。
【００４８】
データ管理モジュール５１６は、スマートカード１２０と、データベース５０４、５１４、５０２および５１０との間のデータ伝送を、これらのデータベースと、他のシステム、すなわち、更新ロジックシステム１１０およびＣＯＤＵＳ１０６との間と同様に、容易にするためのデータ管理能力を提供する。よって、データ管理モジュール５１６は、各種システム間の継ぎ目のないデータ伝送を保証するためのインターフェースとして機能する。
【００４９】
（ネットワーク）
好適な実施形態とともに上述された各種コンポーネント、データベース、モジュール、および装置は、適切なデータ通信ネットワークを介して接続される。このようなネットワークは、各種の従来のデータプロトコル、例えば、ＴＣＰ／ＩＰプロトコル、を用いて各種物理的な接続で構成され得る。本発明のシステムのコンポーネント間の個々の接続が異なることがあり得ることは理解されよう。例えば、無線のＰＣＳネットワークは、アクセスポイント１０２からセキュアサポートクライアントサーバ１０４までに用いられ得る一方で、インターネットＴＣＰ／ＩＰ接続は、ＣＯＤＵＳ１０６から各種のＥＤＣＵ１１２までに用いられ得る。
【００５０】
各種のハードウェアシステムが、本発明を実行するために適切であることは、当業者であれば理解するであろう。各種モデム、ルータ、ＣＰＵ、モニタ、バックアップシステム、電源、および周辺機器が、本発明のシステムの利益を実現するために用いられ得る。１つの実施形態において、例えば、ＩＢＭ  ＭＱ  Ｓｅｒｖｅｒ  ｓｏｆｔｗａｒｅを用いたＯＳ／２環境で動作しているＣｏｍｐａｑ  Ｐｒｏｌｉｎｅａ  ｃｏｍｐｕｔｅｒが、セキュアサポートクライアントサーバ１０４を実行するために用いられ、ここで、各種アクセスポイントは、独立したスマートカードキオスクを含み、ＥＤＣＵ１１２およびＣＯＤＵＳ１１６が、適切なデータベースソフトウェアパッケージを実行しているＷｉｄｏｗｓ／ＮＴ環境で動作しているＣｏｍｐａｑ  Ｐｒｏｌｉｎｅａ  ｃｏｍｐｕｔｅｒ上にインプリメンテーションされる。
【００５１】
（個人化システム）
次に図９を参照して、好適な実施形態において、個人化システム１４０は、カード管理システム９０２、レガシー管理システム９０４、収集アプリケーションモジュール９０６、１以上のデータベース９１０、アクティベーションブロック９０８、共通カード個人化ユーティリティ９１２（ＣＣＰ）、サービスビューロー９１４、共通カードセキュリティサーバ９１６、キー管理システム９１８、および１以上のキーシステム９２０を適切に含む。キー管理システム９１８は、データベースモジュール９２２、ＣＩＤ交換モジュール９２４、キーシステム９２６、およびキーシステム９２８を適切に含む。
【００５２】
ＣＣＰ９１２は、ＣＯＤＵＳ１０６（図１に示す）と適切に通信し、レガシー管理システム９０４は、これもＣＯＤＵＳ１０６と通信するように構成されているアカウント維持１４２と適切に通信する。
【００５３】
カード管理システム９０２は、カードリクエスト９０１を適切に受信し、且つ各種ソースから情報収集を始める。概して、カードリクエスト９０１は、カードの特徴の所望のグループを特定するように意図された各種のリクエスト情報からなる。このような特徴は、例えば、所望の用途（飛行機、ホテル、レンタカー、その他）のリスト、カードが新しいか、更新されたものか、または取替されたものであるかの明示、所望の用途に対応するデフォルトのカードメンバーの選好のリスト、カードメンバーに関連する個人情報（名前、住所、その他）、および必要なセキュリティレベルを含むかもしれない。
【００５４】
カード管理システム９０２は、カードリクエストを適切に解読し、且つ発行者によりすでに格納された情報に対して、レガシーカード管理システム９０４にリクエストを送信する。レガシーデータとして利用できない情報に対しては、カード管理システム９０２は、カードリクエスト９０１の関連コンポーネントを収集アプリケーションモジュール９０６へと転送する。例示的実施形態において、カード管理システム９０２は、特定のカードリクエスト９０１に対する最適なスマートカード物理特徴を選択する。すなわち、カード管理システム９０２は、多数の要因、例えば、所望のセキュリティ機能のメモリ必要条件および計算の複雑性にもとづいて用いられる適切なタイプのスマートカードチップを適切に決定する。同様に、最適なスマートカード動作システム（ＳＣＯＳ）が選択され得る。別の実施形態において、スマートカードチップ、オペレーティングシステム、およびその他が、カードリクエスト９０１で特定される。
【００５５】
レガシーカード管理システム９０４は、もし、あるならば、カード所有者のカード発行元との過去の関係に関連する情報の適切な格納庫として機能する。例えば、カード所有者は、（標準的なエンボスされた磁気ストライプカードにもとづいた）発行元との長期にわたるクレジットまたは引き落とし口座を有するかもしれないし、この情報は、発行されたカードに便利に組み込まれるかもしれない。
【００５６】
収集アプリケーションモジュール９０６は、カード管理システム９０２およびレガシー管理システム９０４から情報を受け取り、次にカードリクエスト９０１内で特定された残りの全ての情報を収集するために各種データベース９１０とインターフェースするように適切に構成される。好適には、データベース９１０は、スマートカード１２０で用いるスマートカードアプリケーションをオファーする、個々の提携企業に対応し、且つ関連づけられる（例えば、図１の企業ネットワーク１１４）。よって、例えば、ホテルアプリケーションに対するリクエストを含んだカードリクエスト９０１は、適切なホテルデータベース９１０とデータ通信を始めるために、収集アプリケーション９０６をトリガーする。ホテルデータベース９１０は、次に、正確なファイル構造、アクセス条件（セキュリティ）、デフォルト値、およびスマートカード１２０を構成するために必要な他のデータを特定する情報をリクエストされたアプリケーションとともに返送する。各種データベース９１０との通信が、いずれの適切な手段、例えば、インターネット、ＰＳＴＮ、その他でのデータ通信を介してか、または単なる電話によるリクエストなどの他のチャネルを介して行われる。
【００５７】
アクティベーションブロック９０８は、１度発行されたカードを、カードメンバーがアクティベートするための手段を提供するために適切に用いられる。例えば、クレジットカード、その他が、アクティベートされていないまま、カードメンバーに送られることはよくあり、カードをアクティベートするために、カードメンバーは、カードの発行元の自動システムに電話をかける（またはコンタクトをとる）ことが必要である。これは、典型的には、プッシュフォンを用いてカード番号、および他の適切なＩＤの入力により達成される。これに関して、アクティベーションブロック９０８は、リクエストされたスマートカードに対するこの機能を容易にするために、すなわち、このようなアクティベーションが特定のカードに対して必要であるかを特定するために用いられる。
【００５８】
ＣＣＰ９１２は、正確にフォーマットされたカード「オブジェクト」、すなわち、オペレーティングシステム、ファイル構造、およびカード１２０にダウンロードされるその他の全ての利用可能なカードデータを生成し、次にこの情報を（スマートカードの作成のために）サービスビューロー９１４、および（発行時のカードの状態を記録するために）ＣＯＤＵＳ１０６に転送するために用いられる。ＣＣＰ９１２は、（後述する）用いられる特定のカード発行システムにカードオブジェクトのフォーマットを適合させるように好適には構成される。よって、収集アプリケーションシステム９０６は、比較的にハイレベルの機能リクエストを送信し得、ＣＣＰ９１２は、インプリメンテーションに用いられる特定の「オブジェクト」を生成し得る。
【００５９】
個人化サービスビューロー９１４は、個々のカードメンバーに発行するスマートカードの製造を完成するために適切なハードウェアおよびソフトウェアを含む。これに関して、サービスビューロー９１４は、いずれの従来のエンボシング、または磁気ストライプライティングと同様に、スマートカードチップへの起こり得る情報の転送を扱うための適切なスマートカード「プリンタ」を含む。適切には、スマートカードプリンタは、例えば、Ｄａｔａｃａｒｄ  Ｃｏｒｐｏｒａｔｉｏｎ  ｏｆ  Ｍｉｎｎｅｔｏｎｋａ，  ＭＮにより製造されたスマートカード発行システム９０００シリーズおよび１５０ｉシリーズのいずれかを含む。
【００６０】
共通カードセキュリティサーバ９１６（ＣＣＳＳ）は、さまざまな企業キーシステム９２０から暗号キー情報を検索するために必要な、ソフトウェアおよびハードウェアコンポーネントを適切に含む。例示的実施形態において、この情報は、個人化プロセスを完了するために、サービスビューロー９１４によりアクセスされる。さらに詳細には、典型的に、スマートカード１２０が、広範囲の企業組織と関連づけられた多数の異なるアプリケーションを含む場合である。これらのファイルの書込み、更新、および読出しが、一連のアクセス条件規則にもとづいて、特定の当事者に有利に制限されることは、当業者であれば理解するであろう。これらのアクセス条件は、適切な当事者により知られている暗号キーを用いて適切に実行される。よって、サービスビューロー９１４のタスクは、カードファイル構造を生成、且つ設置することであるが、サービスビューロー９１４は、最初において、この機能を実行するために必要なキーへのアクセスを有さない。上記で簡潔に述べたように、公知のシステムは、発行プロセスで用いられる中央格納庫にキーデータを蓄積することにより、この問題を解決しようと試みたために、承認できないセキュリティリスクを生成する。本発明にもとづいた方法は、しかしながら、カードの発行時に、スマートカードと個々のキーシステム９２０間の通信を考慮しない。よって、キー情報が第３者の干渉なしで、キー情報が安全にスマートカードにダウンロードすることが可能である。さまざまなカードで生成されるさまざまなアプリケーションの識別に関して、ＣＣＰ９１２から情報を受け取ることにより、ＣＣＳＳ９１６は、このプロセスを容易にするために適切に用いられ、サービスビューロー９１４によりプロンプトされたとき（または、サービスビューロー９１４による発行以前）に、個人化の処理中にサービスビューロー９１４に転送されるキーを要求するために、適切なキーシステム９２０にコンタクトする。
【００６１】
キーシステム９２０は、特定の企業と関連づけられた暗号キーを格納、生成、および安全に伝送することが可能な適切なデータベースシステムを含む。キー管理システム９１８は、このコンテクストにおいて、キーシステム９２０と類似するシステムであるが、個人化システムをインプリメンテーションする当事者により「所有」される。キー生成機能は、ＣＣＳＳと、キーシステム９２０との間に分散され得る。すなわち、このキーは、キーシステム９２０では生成されずに、（特定の企業から受け取ったアルゴリズムおよびキー情報に従って）ＣＣＳＳ９１６でリアルタイムに生成され得る。
【００６２】
図９に図示される機能ブロックが、ともに規格品および／または特別に開発されたものを含む、各種のハードウェアおよびソフトウェアコンポーネントを用いて実行され得ることは、当業者であれば理解するであろう。例えば、カード管理システム９０２により実施されたデータベース集約的な機能が、いずれの適切なデータベースパッケージ、例えば、Ｃｏｄｅｂａｓｅ、ｄＢａｓｅ、またはその他を用いて実行され得る。
【００６３】
（個人化プロセス）
図９とともに上記で説明した個人化システムは、広範な機能レベルを有する多数のスマートカードを効率的に発行するために適切に用いられる。このタスクは、システムによりサポートされる各種の提携企業全体における個々のカードメンバーごとの正確なデータを、適時に、獲得し、且つ調整することを必要とする。これに関しては、ある提携企業が所有データの伝播を制限したい場合であってもよい。このデータは、例えば、ファイル構造およびカードメンバー個人データと同様に、スマートカードアクセス条件とともに用いられる個人キーを含む。
【００６４】
次に図９および１０を参照して、例示的スマートカードの個人化を次に説明する。第１に、ステップ１００２において、システムはスマートカードリクエストを受け取る。上述のとおり、カード管理システム９０２は、カードリクエストを受け取り、且つ各種のソースからの情報収集を開始するために適切に用いられる。カードリクエスト９０１は、あるカード特性の所望のグループを特定することを意図するリクエスト情報により適切に構成される。このような特徴は、例えば、所望のアプリケーション（飛行機、ホテル、レンタカー、その他）のリスト、カードが新しいか、更新されたものか、または取替されたものであるかの明示、所望のアプリケーションに対応するデフォルトのカードメンバーの選好のリスト、カードメンバーに関連する個人情報（名前、住所、その他）、および必要なセキュリティレベルを含むかもしれない。
【００６５】
次に、ステップ１００４において、システムは、所与のカードリクエスト９０１に適切なスマートカードのタイプおよびコンフィギュレーションを選択する。このステップは、カード管理システム９０２により適切に実施される。よって、カード管理システム９０２は、カードリクエスト９０１内で、受け取った情報（例えば、メモリ必要条件、所望のセキュリティ機能、その他）を考慮して多数のファクタを調査し、次に、利用可能なチップのライブラリから適切なスマートカードチップを選択する。同様に、最適なスマートカードオペレーティングシステム（ＳＣＯＳ）も選択され得る。
【００６６】
ステップ１００６において、カードメンバー情報が獲得される。このステップは、データベース９１０およびレガシー管理システム９０４とともに動作している、収集アプリケーションモジュール９０６により、適切に実施される。さらに詳細には、カードメンバー特有の情報が、２つのグループ、すなわち、個人化システムには既知の情報、および個人化システムには未知の情報に好適に分類される。既知の情報は、概して個人化システムを主催している組織との過去の関係を通して得られたデータから構成される。このような場合、カード所有者の名前、希望の請求先、肩書き、勤務先、その他のある種のデータは、ある種のアプリケーションデータと同様に、すでに知られているようである。このような情報は、レガシー管理システム９０４からなる１以上のデータベースに適切に格納され、且つそこから検索され得る。ステップ１００６の一部として、システム（特に、モジュール９０８）は、カードがアクティベーションを必要とするかどうかを好適に決定する。すなわち、上記で簡潔に述べたように、使用前にカードのアクティベーションが必要であることを、カードメンバーに知らせるステッカーまたはその他のものがカードに貼られていることがよくある。アクティベーションは、一般的に、自動電話システムの使用を伴う。特定のカードがアクティベーションを必要とするかどうかの選択は、例えば、人口統計、犯罪率、またはカードメンバーの郵便番号に関連する郵便物に対する不正の統計等の多数のファクタにもとづき得る。
【００６７】
レガシー管理システム９０４に含まれないデータに対して、収集アプリケーションモジュール９０６は、カードリクエスト９０１を満たすために必要な情報を検索するために、データベース９１０と適切に通信する。この情報は、一般的に、例えば、ＤＦおよびＥＦ階層、データのタイプおよび長さ、およびアクセス条件特性等の特定の企業が提供するアプリケーションのファイル構造情報から成る。例えば、カードリクエスト９０１が、飛行機に関するアプリケーションのリクエストを含んでいる場合に、収集アプリケーションモジュール９０６は、飛行機に関するアプリケーションを主催している企業に対応するデータベースにコンタクトをとり、次に全ての必要なファイル構造情報をダウンロードする。このプロセスは、スマートカードに組み込まれる新しいか、または変更された各アプリケーションに対して順次続くであろう。
【００６８】
ステップ１００８において、ＣＣＰ９１２を適切に用いて、完全なカードメンバーデータ集合が生成される。このデータ集合、または「カードオブジェクト」は、物理的スマートカードを生成するために、サービスビューロー９１４により最終的に用いられる。カードオブジェクトの形式は変更され得る。１つの実施形態において、カードオブジェクトは、バイナリラージオブジェクト（「ＢＬＯＢ」）と名づけられたものを含む。カードオブジェクトは、選択されたスマートカードコンフィギュレーション（例えば、ステップ１００４で特定されたようなチップタイプおよびオペレーティングシステム）、（ステップ１００６で収集された）カードメンバー情報データの内容、および所期のスマートカード「プリンタ」（すなわち、サービスビューロー９１４内に完成したカードを生成するために用いられる装置）に好適に適合される。これにより、システムが、先行するステップにおいて、この構造がスマートカードにどのようにしてコード化されるのか、またはデータがどのようにしてアクセスされるのかということに関与せずに、ファイル構造、データタイプ、およびその他を特定することが可能になる。ステップ１００８までに、システムは比較的にハイレベルなモデルの所期のスマートカードデータ構造を開発する必要があるだけである。その特性は、ＣＣＰ９１２以外の全てには実質的に見えない。
【００６９】
別の実施形態において、スマートカードデータオブジェクトの各種詳細は、システムにおけるその前の時点において、決定され得る。すなわち、ＣＣＰ９１２の機能は、システムの各種コンポーネント中に分散され得る。
【００７０】
カードメンバーデータ集合、またはカードオブジェクトを生成した後に、ステップ１００８において、このデータは、次にＣＯＤＵＳ１０６（ステップ１０１０）に送信される。これにより、ＤＳＳ（特に、ＣＯＤＵＳ１０６）が、個人化処理中のスマートカードの状態の記録を有する。この情報は、その後すぐに、アカウント維持システム１４２で利用可能となる。
【００７１】
カードオブジェクトは、サービスビューロー９１４および（もし必要であれば）ＣＣＳＳ９１６（ステップ１０１２）に送信される。ステップ１０１４において、サービスビューロー９１４が完成したスマートカードを生成することができるようにするために必要なキーが得られる。上述のとおり、ステップ１０１４は、発行プロセスと同時に、または連続してＣＣＳＳ９１６により適切に実施される。１つの実施形態において、個々のカードのそれぞれが、サービスビューロー９１４に適切に位置する発行システムを用いて生成されると、サービスビューロー９１４は、適切な暗号キーを求めてＣＣＳＳ９１６に応答信号を送る。これらのキーは、事前に（すなわち、ステップ１０１２の後に）キーシステム９２０および９１８から検索されたか、またはサービスビューロー９１４からのリクエストに応答して、リアルタイムで検索されるかのいずれかである。また、このキーは、ＣＣＳＳ９１６により検索され得、且つサービスビューロー９１２へのカードオブジェクトの伝送より前に、ＣＣＰ９１２に伝送され得る。どちらの場合においても、１つのキー、または複数のキーが、ステップ１００８で生成されたカードオブジェクトに含まれるように検索される。
【００７２】
ステップ１０１６において、カードが実際に発行される。サービスビューロー９１４は、カードオブジェクトを正確な暗号キーを用いる正確なスマートカードハードウェアに適切にダウンロードする。この初期化されたスマートカードは、従来の方法に従って、次にパッケージングされ、且つ適切なカードメンバーへと送られる。
【００７３】
（同期プロセス）
さまざまな実施形態において上述された動的な同期システムが、顧客のスマートカードの「状態」を探知するために用いられる。スマートカードの状態は、スマートカードで用いられるアプリケーションの構造、およびこれらのアプリケーション内に格納されたデータのさまざまな断片により、適切に特徴づけられる。
【００７４】
アプリケーションおよびデータがスマートカード内で管理される方法は、変更され得る。例えば、データファイルおよびディレクトリは、スマートカード１２０内の「ツリー」構造で格納され得る。すなわち、スマートカードファイル構造は、周知のＭＳ−ＤＯＳ（Ｍｉｃｒｏｓｏｆｔ  Ｄｉｓｋ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）ファイル構造に適切に類似しており、ファイルがディレクトリの階層内で論理的に組織されている。詳細には、ＩＳＯ７８１６−４において、３種類のファイルが定義されている。すなわち、専用ファイル（ＤＦ）、基本ファイル（ＥＦ）、およびマスターファイル（ＭＦ）である。マスターファイルは、ＭＳ−ＤＯＳの「ルート」ディレクトリに類似し、他の全てのファイルおよびディレクトリを含む。専用ファイルは、実際には、他のＤＦまたはＥＦを収納するディレクトリまたは「フォルダ」である。よって、ＭＦは、任意の数のＤＦを含んでもよく、これらのＤＦは、他のＤＦを含み得るか否かのいずれかである。基本ファイルは、ユーザデータを格納するために用いられ、且つ専用ファイル内、またはマスターファイル内に存在し得る。より高次のＤＦ（すなわち、特定のアプリケーションを収納するＤＦ）は、しばしばアプリケーション専用ファイル（ＡＤＦ）と呼ばれる。本発明の範囲は、しかしながら、このタイプのマルチ機能カードに限定されない。例えば、他の実施例には、Ｍｕｌｔｏ(s)、Ｊａｖａベースのカードがあり、これらもまた、本発明のコンテクストにおいて相応しい。
【００７５】
多数の同期に関する問題が、マルチ機能スマートカードにおいて生じ得る。実際、３つの典型的なケースがある程度の頻度で再発し、それは、１）更新取引、２）保留取引、および３）ファイル構造の変更に関する。これらのケースのそれぞれを、本発明に関して次に順番に説明する。
【００７６】
（実施例１：更新取引）
カード所有者が、スマートカード１２０に局部的な変更を加えるのは非常によくあり、この変更は、この情報を便利に利用することが可能であり得るデータべース全体にはすぐには反映されない。例えば、初期化において（すなわち、元々カードが個人化システム１４０を介して発行されるとき）、カード所有者のスマートカード１２０が、喫煙に対する一般的な選好を反映するように構成された（例えば、１つのファイルが、喫煙／禁煙とキーを割りつけられたブーリアンフィールドを含む）が、カード所有者は、次にこの一般的な選好ファイルを禁煙の選好を反映するように変更したいと思うことを前提とする。
【００７７】
この場合、本発明の好適な実施形態に関して、図１および７を参照して、カード所有者は、カード１２０を便利な場所に位置したアクセスポイント１０２に適切に挿入し、カードおよび／またはカードリーダの認証が行われる（ステップ８０２）。好適な実施形態において、ＩＳＯ  ７８１６規格の関連するセクションに従って、認証が行われる。
【００７８】
次に、カード所有者は、取引を実施するために、すなわち、選好ファイルへの変更をリクエストするために、（サーバ１０４とともに機能しているアクセスポイント１０２により提供された）適切なユーザインターフェースを用いる（ステップ８０４）。この変更は、スマートカード１２０で、一般的に、すぐに反映される。すなわち、アクセスポイント１０２および／またはサーバ１０４は、スマートカード１２０内の適切なファイルにアクセスし、且つそのファイルを更新するために必要な機能を含む。
【００７９】
サーバ１０４内の通信ルータ２０６は、次にその取引を、ブランチ８０７および８１２のそれぞれに対応する適切な当事者、すなわち、ＥＤＳＩ  １０８、またはＥＤＣＵ１１２にルーティングする。すなわち、システムコンフィギュレーションに依存して、変更されるファイルは、特定の企業と関連づけられるか、またはＤＳＳを主催している組織と関連づけられるかもしれない。これらの２つの場合に関して、順番に説明する。
【００８０】
図８のブランチ８０７に続いて、変更データが、適切なＥＤＳＩ  １０８に送信され、且つそこに格納される（ステップ８０８）。更新ロジックシステム１１０は、次にこの変更リクエストを適切なＥＤＣＵ１１２、すなわち、特定のＥＤＳＩに対応するＥＤＣＵ１１２に伝送する（ステップ８１０）。この情報は、対応する更新データベース５０４に適切に格納される。この情報はまた、他のＥＤＳＩに分散される。本発明の実施例において、更新ロジックシステム１１０は、カード所有者の喫煙状況を認識することが有益であるこれらのシステムを識別する。このようなシステムは、例えば、各種のホテル、レンタカー代理店、およびその他を含むかもしれない。
【００８１】
また、図８のブランチ８０５に続いて、データが、まず適切なＥＤＣＵで格納され得（ステップ８１２）、上述のとおり、次に他のＥＤＣＵ１１２およびＥＤＳＩ１０８へと分散される。
【００８２】
カードデータの変更は、ＣＯＤＵＳ１０６へ伝送される。特に、スマートカード１２０と関連づけられた各種のフィールドおよびファイルが、更新データベース５０４内に格納された変更を反映するために更新される。よって、ＣＯＤＵＳ１０６内の情報が、スマートカード１２０、および各種のＥＤＣＵ１１２およびＥＤＳＩ１０８内に含まれた情報と一致する。この伝送の後、更新データベース５０４内の対応する変更データが、クリアされる（ステップ８１８）。
【００８３】
（実施例２：保留取引）
カード所有者は、スマートカード１２０を直接伴わないチャネルを介して、変更を行うか、または取引を実施するかもしれない。これにより、スマートカード１２０内のデータと、ＤＳＳ全体の各種データベース内のデータ間に不整合が生じる。このような問題が生じるのは、例えば、カード所有者が、予約をするためにホテルに電話をかけ（スマートカード１２０を用いて、オンラインで取引を実施しないで）、選好を喫煙から禁煙に変更する旨を口頭でリクエストするときである。
【００８４】
次に図１および７を参照して、この場合、本発明の実施形態に関して、カード所有者はまず、スマートカード１２０を含まない手段を介して、ある企業にコンタクトを取る（ステップ７０２）。すなわち、「スマートカードなし」の取引である。適切なインターフェース（声、キーパッド、その他）を用いて、変更または取引が選択される（ステップ７０４）。この変更は、次に特定の企業ネットワーク１１４内に局部的に格納され、且つ／またはＥＤＳＩ１０８内に格納される（ステップ７０６）。
【００８５】
次に、ステップ７０８において、更新ロジックシステム１１０は、この情報を対応するＥＤＣＵ１１２にルーティングし、その情報は保留データベース５１４に常駐する。この時点で、スマートカード１２０自体は、更新には気づかない。結果として、カード所有者がスマートカードがある取引を開始すれば、対応する企業はまず、スマートカード１２０内のデータ構造に選好を求め、先に述べたとおり、誤った結論に大半は到達する（例えば、喫煙可能な部屋が、カード所有者が示した選好に関わらず、割り当てられるかもしれない）。
【００８６】
この状況を救うために、本発明は、ステップ７１０〜７１２において、スマートカードが、それにより次回使用時に更新されるような方法を提供する。すなわち、スマートカードがアクセスポイント１０２に挿入された後、適切に認証され（ステップ７１０）、システムが保留データベース５１４に応答信号を発信し、なんらかの変更がなされたかどうかを判定する。もし、変更があれば、適切な情報がスマートカード１２０にダウンロードされる（ステップ７１２）。
【００８７】
上記の情報の伝送が首尾よく完了した後、その変更データはＣＯＤＵＳ１０６へ伝送され、そこで、カードオブジェクトデータベース１１６内に格納される。最後に、保留データベース５１４内の個々の情報がクリアされる（ステップ７１６）。
【００８８】
（実施例３：ファイル構造／アプリケーションの変更）
上述したデータ関連の修正に加えて、スマートカード１２０内に格納されたデータの構造の変更はまた、ある場合においては望ましいかもしれない。すなわち、スマートカードの有効期限中に、カード発行者、提携企業、またはカード所有者自身が、カード内に収納された一連のアプリケーションを増やすことによりカードの機能を拡張したいと望むかもしれない。例えば、レンタカーおよび飛行機の予約のためにスマートカードを用いるカード所有者はまた、ホテルの予約および支払いのためにカードを使用したいと思うかもしれない。このような場合、適切な提携ホテルは、カード所有者のリクエストを処理し、且つスマートカードファイル構造に追加されるホテルアプリケーションを追加する手配をするかもしれない。別の例において、スマートカード発行者は、新しいアプリケーション、例えば、クレジットおよび／またはデビットアプリケーションの追加をそれ自体で認証するかもしれない。反対に、カードからアプリケーションを削除することが適切な場合もあり得る。
【００８９】
好適な実施形態において、上述のファイル構造の変更のタイプは、図７に示される手順集合に類似の方式で、ある程度、どの当事者がそのファイル構造の変更をするかに依存して扱われ得る。すなわち、ステップ７１２において、適切なファイル構造変更情報は、カードがオンライン取引で用いられたときに、ＥＤＣＵ１１２内（例えば、データベース５０２内）に格納され得、且つスマートカード１２０へと伝送され得る（ステップ７１０および７１２）。スマートカード１２０上のファイル構造は、増大されるか、または修正され、ＣＯＤＵＳ１０６（特に、データベース１１６）は、変更を反映するために同様に修正される。この変更情報は、データベース５０２からクリアされる（ステップ７１６）。
【００９０】
本発明は、添付の図面とともに本明細書中において説明されてきたが、本発明の請求の範囲が、限定されないことは、当業者であれば理解するであろう。本明細書中に記載の各種コンポーネントおよびステップの選択、設計、および配置の修正は、添付の請求の範囲で規定された本発明の範囲を逸脱しない程度に実施され得る。
【図面の簡単な説明】
【図１】  図１は、本発明のさまざまな局面にもとづく例示的ダイナミック同期システムの概略図である。
【図２】  図２は、例示的セキュアサポートクライアントサーバの概略図である。
【図３】  図３は、例示的企業データ同期インターフェースの概略図である。
【図４】  図４は、例示的更新ロジックシステムの概略図である。
【図５】  図５は、例示的企業データ収集ユニットの概略図である。
【図６】  図６は、例示的カードオブジェクトデータベース更新システム（ＣＯＤＵＳ）の概略図である。
【図７】  図７は、保留取引情報を同期させるための例示的方法を示すフローチャートである。
【図８】  図８は、更新取引情報を同期させるための例示的方法を示すフローチャートである。
【図９】  図９は、例示的個人化システムの概略図である。
【図１０】  図１０は、スマートカード個人化の例示的方法を示すフローチャートである。
【図１１】  図１１は、旅行コンテクストでの使用に適した例示的取引データ構造である。
【図１１Ａ】  図１１Ａは、旅行コンテクストでの使用に適した例示的取引データ構造である。
【図１】
0004170590.tif 000002
【図２】
0004170590.tif 000003
【図３】
0004170590.tif 000004
【図４】
0004170590.tif 000005
【図５】
0004170590.tif 000006
【図６】
0004170590.tif 000007
【図７】
0004170590.tif 000008
【図８】
0004170590.tif 000009
【図９】
0004170590.tif 000010
【図１０】
0004170590.tif 000011
【図１１】
0004170590.tif 000012
【図１１Ａ】
0004170590.tif 000013