(57)【要約】【課題】プラットフォーム型ＯＳのＡＰＩの仕様が変更されても，アプリケーションを変更することなくアプリケーションを動作させることのできるＩＣカード提供する。【解決手段】プラットフォームＯＳ３１が提供するＯＳＡＰＩ３１０をアプリケーション３２に対して公開するためのラッパーＡＰＩ３３０を有し，アプリケーション３２によってラッパーＡＰＩ３３０の一つが呼び出されると，アプリケーション３２から引き渡された引数の形式を，呼び出されたラッパーＡＰＩ３３０に対応するＯＳＡＰＩ３１０の形式に変換してＯＳＡＰＩ３１０を呼び出し，プラットフォームＯＳ３１から受信した戻り値を，呼び出されたラッパーＡＰＩ３３０のデータ形式に変換してアプリケーション３２へ引き渡す処理を実行するラッパーモジュール３３が，ＩＣカード１のソフトウェア階層３に含まれる。【選択図】図３
2011198298.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォームオペレーティングシステム（OS: Operating System）が実装されたＩＣカードであって，プラットフォーム型ＯＳが提供するＯＳ＿ＡＰＩをアプリケーションに対して公開するためのラッパーＡＰＩを有し，アプリケーションによって前記ラッパーＡＰＩの一つが呼び出されると，アプリケーションから引き渡された引数の形式を，呼び出された前記ラッパーＡＰＩに対応する前記ＯＳ＿ＡＰＩの形式に変換して，この前記ＯＳ＿ＡＰＩを呼び出し，前記プラットフォーム型ＯＳから受信した戻り値を，呼び出された前記ラッパーＡＰＩのデータ形式に変換してアプリケーションへ引き渡す処理を実行するラッパーモジュールと，前記ラッパーＡＰＩに対応する前記ＯＳ＿ＡＰＩを利用する際，前記ラッパーＡＰＩを呼び出して動作するアプリケーションが実装されていることを特徴とするＩＣカード。
【請求項２】
前記ラッパーＡＰＩが対応している前記ＯＳ＿ＡＰＩには，前記プラットフォーム型ＯＳのバーチャルマシン上に構築されたカードマネージャが提供しているＡＰＩが含まれることを特徴とする，請求項１に記載のＩＣカード。
【請求項３】
請求項１から請求項２のいずれか一つに記載のラッパーモジュールとして，ＩＣカードを機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，オペレーティングシステム（OS: Operating System）が実装されたＩＣカードに関する発明で，詳しくは，オペレーティングシステムに多少の差異が合った場合でも，同一のアプリケーションを利用できるようにするための発明である。
【背景技術】
【０００２】
ＩＣカードに実装されるオペレーティングシステムの種類は，ある特定のシステム向けに開発されたネイティブＯＳと，特許文献１の「発明の背景」に記載のあるように，電気的に書き換え可能なメモリ（例えば，ＥＥＰＲＯＭ）に複数のアプリケーションをロードできるプラットフォーム型ＯＳに大きく分けられる。
【０００３】
プラットフォーム型ＯＳの多くは，ＩＣカードの基本的な機能を提供するカードＯＳ上に，Ｊａｖａ（登録商標）やＭＵＬＴＯＳ（登録商標）などのバーチャルマシンを実装することで実現され，プラットフォーム型ＯＳ上で動作するアプリケーションは，アプリケーションが動作するプラットフォーム型ＯＳのバーチャルマシンに対応した中間言語の形式で，ＥＥＰＲＯＭなどの書き換え可能なメモリに実装される。
【０００４】
プラットフォーム型ＯＳ上で動作するアプリケーションは，プラットフォーム型ＯＳのバーチャルマシン提供される機能を呼び出すためのＡＰＩ（API: Application Program Interface）を利用して動作するが，同じ種類のプラットフォーム型ＯＳであっても，プラットフォーム型ＯＳのバージョンが異なると，バーチャルマシンで提供されるＡＰＩの仕様が異なる場合がある。
【０００５】
また，金融機関系のＩＣカードには，Ｊａｖａ（登録商標）などのバーチャルマシン上で動作するカードマネージャがインストールされ，このカードマネージャによって，カードマネージャが管理するアプリケーションのロック，カードのロック及びカードの無効処理が行われるが，プラットフォーム型ＯＳのバージョンが同じであっても，カードマネージャが異なると，カードマネージャで提供されるＡＰＩの仕様には差が生じてしまう。
【０００６】
このように，プラットフォーム型ＯＳのバーチャルマシンが同じであっても，アプリケーションが呼び出すＡＰＩの仕様が異なる場合，ＡＰＩの仕様に合わせたアプリケーションを作成し，特許文献１で開示されている発明のように，ＩＣカードを発行する側でアプリケーションを管理し，発行対象となるＩＣカードに合わせてアプリケーションを発行していた。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００１-５２７６７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
確かに，特許文献１で開示されている発明のような発行システムを用いれば，プラットフォーム型ＯＳのＡＰＩの仕様毎にアプリケーションを管理できるようになるが，アプリケーションを作成する側では，プラットフォーム型ＯＳのＡＰＩの仕様が変更される毎にアプリケーションを作り直さなければならず大変面倒であった。
【０００９】
そこで，本発明は，プラットフォーム型ＯＳのＡＰＩの仕様が変更されても，アプリケーションを変更することなくプラットフォーム型ＯＳ上でアプリケーションを動作させることのできるＩＣカード及びこのＩＣカードに実装するコンピュータプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決する第１の発明は，プラットフォーム型ＯＳ（OS: Operating System）が実装されたＩＣカードであって，プラットフォーム型ＯＳが提供するＯＳ＿ＡＰＩをアプリケーションに対して公開するためのラッパーＡＰＩを有し，アプリケーションによって前記ラッパーＡＰＩの一つが呼び出されると，アプリケーションから引き渡された引数の形式を，呼び出された前記ラッパーＡＰＩに対応する前記ＯＳ＿ＡＰＩの形式に変換して，この前記ＯＳ＿ＡＰＩを呼び出し，前記プラットフォーム型ＯＳから受信した戻り値を，呼び出された前記ラッパーＡＰＩのデータ形式に変換してアプリケーションへ引き渡す処理を実行するラッパーモジュールと，前記ラッパーＡＰＩに対応する前記ＯＳ＿ＡＰＩを利用する際，前記ラッパーＡＰＩを呼び出して動作するアプリケーションが実装されていることを特徴とするＩＣカードである。
【００１１】
更に，第２の発明は，前記ラッパーＡＰＩが対応している前記ＯＳ＿ＡＰＩには，前記プラットフォーム型ＯＳのバーチャルマシン上に構築されたカードマネージャが提供しているＡＰＩが含まれることを特徴とする，請求項１に記載のＩＣカードである。
【００１２】
更に，第１の発明から第２の発明いずれか一つに記載のラッパーモジュールとして，ＩＣカードを機能させるためのコンピュータプログラムである。
【発明の効果】
【００１３】
上述した本発明によれば，プラットフォーム型ＯＳのＡＰＩの仕様が変更されても，アプリケーションを変更することなくプラットフォーム型ＯＳ上でアプリケーションを動作させることのできるＩＣカード及びこのＩＣカードに実装するコンピュータプログラムを提供できる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態に係るＩＣカードの外観を示した図。
【図２】ＩＣカードに実装されるＩＣチップのブロック図。
【図３】ＩＣカードのソフトウェア階層を説明する図。
【図４】ラッパーモジュールの動作を説明するフロー図。
【図５】実施例１におけるソフトウェア階層を説明する図。
【図６】Open Platform及びGlobal Platformに準拠したＩＣカードのソフトウェア階層を説明する図。
【図７】ラッパーＡＰＩの一例を説明する図。
【発明を実施するための形態】
【００１５】
ここから，本願発明の実施形態について，本願発明の技術分野に係わる当業者が，本願発明の内容を理解し実施できる程度に説明する。
【００１６】
図１は、本実施形態に係るＩＣカード１の外観を示した図で、図１に示したＩＣカード１は、キャッシュカードやクレジットカードと同じ大きさのプラスチック製カードで、ＩＣカード１に実装されたＩＣモジュール２ａには、プラットフォーム型オペレーティングシステム（OS: Operating System）やアプリケーションが実装されたＩＣチップ２がモールドされている。
【００１７】
図１において、本実施形態に係るＩＣカード１を，ターミナル（図示していない）と接触型でデータ通信する接触ＩＣ型カードとしているが、本発明は，ＩＣカードタイプに依存せず，無線でデータ通信する非接触ＩＣカード、または、接触データ通信と非接触データ通信の２つの通信機能を備えたデュアルインターフェースＩＣカードであってもよい。
【００１８】
加えて、ＩＣカード１の形状は問わず、ＩＣカード１はキャッシュカードと同じ形状でなく、ＩＣモジュール２ａの近辺を矩形状に切り取った形状をし，携帯電話やスマートフォンなどに組み込まれるＳＩＭ（Subscriber Identity Module）であってもよい。
【００１９】
図２は、ＩＣカード１に実装されるＩＣチップ２のブロック図である。図２に図示したように、ＩＣチップ２には、演算機能を備えたＣＰＵ２０（CPU：Central Processing Unit）、揮発性メモリとしてランダムアクセスメモリ２１（RAM：Random Access Memory）、読み出し専用の不揮発性メモリ２３（ROＭ：Read Only Memory、）、電気的に書換え可能な不揮発性メモリとしてＥＥＰＲＯＭ２２（EEPROM：Electrically Erasable Programmable Read-Only Memoryの略）およびターミナルとデータ通信するためのＵＡＲＴ２４に加え、ターミナルから受け取るクロックを利用して時間を計測する機能を備えたタイマー２５などが、ＢＵＳ２６に接続されている。
【００２０】
図３は，本実施形態におけるＩＣカード１のソフトウェア階層３を説明する図である。図２に図示したように，ＩＣカード１のソフトウェア階層３は３階層で，最下位の層から順にハードウェア３０（ここでは，ＩＣチップ２），プラットフォーム型ＯＳ３１，アプリケーション３２になる。
【００２１】
図３のプラットフォーム型ＯＳ３１とは，例えば，データ通信やメモリへのリード／ライトなど，ＩＣカード１の基本的な機能を提供し，アプリケーションの追加・削除が可能なように作成されたオペレーティングシステムで，ＩＣカード１の基本的な機能を提供する命令や関数の集合であるＯＳ＿ＡＰＩ３１０を有し，プラットフォーム型ＯＳ３１のプログラムコードはＩＣチップ２のＲＯＭ２３に実装される。
【００２２】
アプリケーション３２は，プラットフォーム型ＯＳ３１上で動作し，ＩＣカード１が利用されるシステムに対応した処理を実行するためのソフトウェアで，アプリケーション３２のプログラムコードはＩＣチップ２のＥＥＰＲＯＭ２２に実装される。
【００２３】
プラットフォーム型ＯＳ３１が提供するＯＳ＿ＡＰＩ３１０は，プラットフォーム型ＯＳ３１の種類で固定であるが，プラットフォーム型ＯＳ３１のバージョンアップに伴い，ＯＳ＿ＡＰＩ３１０の仕様も変更される場合があり，このようなケースでは，古いＯＳ＿ＡＰＩ３１０の仕様に基づき作成されたアプリケーション３２は，新しいバージョンのプラットフォーム型ＯＳ３１上では動作しなくなってしまうため，何らかの対応が必要となる。
【００２４】
ＯＳ＿ＡＰＩ３１０の仕様が変更された場合の対処として，アプリケーション３２を作り直すことも考えられるが，アプリケーション３２を作り直すと，アプリケーション３２に係わるテストを全て再テストしなければならなくなるため，本実施形態では，図２で図示しているように，プラットフォーム型ＯＳ３１上に，ラッパーモジュール３３（Wrapper Module）を実装し，アプリケーション３２がラッパーモジュール３３を介してＯＳ＿ＡＰＩ３１０を呼び出すようにすることで，ＯＳ＿ＡＰＩ３１０の差分をラッパーモジュール３３で吸収できるようにしている。
【００２５】
ラッパーモジュール３３は，ラッパーモジュール３３で共通化されているＡＰＩであるラッパーＡＰＩ３３０を有し，ラッパーモジュール３３がアプリケーション３２から呼び出されると，アプリケーション３２から引き渡された引数の形式を，このラッパーＡＰＩ３３０に対応しているＯＳ＿ＡＰＩ３１０の形式に変換してこのＯＳ＿ＡＰＩ３１０に引き渡し，ＯＳ＿ＡＰＩ３１０からの戻り値の形式を，ラッパーＡＰＩ３３０のデータ形式に変換してアプリケーション３２に引き渡す処理を実行するモジュールで，ラッパーモジュール３３のプログラムコードは，ＩＣチップ２のＥＥＰＲＯＭ２２に実装されている。なお，仕様変更される可能性のあるＯＳ＿ＡＰＩ３１０に対してのみラッパーモジュール３３を対応させればよく，ＯＳ＿ＡＰＩ３１０すべてにラッパーモジュール３３を対応させなくともよい。
【００２６】
図４は，ラッパーモジュール３３の動作を説明するフロー図である。ラッパーモジュール３３のラッパーＡＰＩ３３０の一つがアプリケーション３２から呼び出されると（Ｓ１），ラッパーモジュール３３は，アプリケーション３２から引き渡された引数を，呼び出されたラッパーＡＰＩ３３０に対応するＯＳ＿ＡＰＩ３１０の形式に変換した後（Ｓ２），変換後の引数を用いてＯＳ＿ＡＰＩ３１０を呼び出す（Ｓ３）。
【００２７】
ラッパーモジュール３３が呼び出したＯＳ＿ＡＰＩ３１０に係わる処理が終了し（Ｓ４），プラットフォーム型ＯＳ３１から戻り値がラッパーモジュール３３に引き渡されると（Ｓ５），ラッパーモジュール３３は，プラットフォーム型ＯＳ３１から引き渡された戻り値の形式を，アプリケーション３２から呼び出されたラッパーＡＰＩ３３０の形式に変換し（Ｓ６），ラッパーＡＰＩ３３０の形式に変換した戻り値をアプリケーション３２に引き渡して（Ｓ７），図３の手順は終了する。
【実施例１】
【００２８】
ここから，ＩＣカード１をＪａｖａ（登録商標）Ｃａｒｄ（以下，「ＪＣ」と略す。）としたときの実施例について説明する。図５は，実施例１におけるソフトウェア階層４を説明する図である。
【００２９】
図５に図示したように，ＪＣにおけるソフトウェア階層４は，ハードウェア４０，カードＯＳ４１，ＪＣバーチャルマシン４２，カードマネージャ４３，そして，ＪＣバーチャルマシン４２上で動作するアプリケーション４４が含まれる。
【００３０】
図５で図示したソフトウェア階層４のハードウェア４０はＩＣチップ２に該当し，カードＯＳ４１は，ハードウェア４０に備えられた回路（例えば，ＵＡＲＴ２４）やメモリ（例えば，ＥＥＰＲＯＭ２２）を制御するためのソフトウェアである。
【００３１】
ＪＣの場合，カードＯＳ４１上にＪＣバーチャルマシン４２が実装され，ＪＣバーチャルマシン４２は，ＪＣバーチャルマシン４２の機能（例えば，データオブジェクトのリード／ライト）をアプリケーション４４に提供するためのバーチャルマシンＡＰＩ４２０を有している。
【００３２】
また，カードマネージャ４３は，ＪＣバーチャルマシン４２上で動作するアプリケーション４４のロード・インストールなどに加え，ＩＣカード１をロックする関数やＩＣカード１を無効化する関数をアプリケーション４４に提供するカードマネージャＡＰＩ４３０を少なくとも有している。
【００３３】
ＪＣの場合，ＪＣバーチャルマシン４２が同一であっても，カードマネージャ４３の種類は幾つか存在し，ＪＣのカードマネージャ４３の仕様としては，Open PlatformとGlobal Platformが有名で，Open PlatformとGlobal Platformのカードマネージャ４３にはカードマネージャＡＰＩ４３０には仕様差があるため，これまで説明したラッパーモジュール４５を，カードマネージャＡＰＩ４３０の仕様の差分を吸収するように利用することができる。
【００３４】
図６は，Open Platform及びGlobal Platformに準拠したＩＣカードのソフトウェア階層を説明する図で，図６では，Open Platformに準拠したＩＣカードとソフトウェア階層４ａ，Global Platformに準拠したＩＣカードのソフトウェア階層４ｂを図示している。
【００３５】
Open Platformに準拠したＩＣカードのソフトウェア階層４ａには，Open Platformの仕様に適合したカードマネージャ４３ａと，Open Platformの仕様に合わせたラッパーモジュール４５ａが実装され，カードマネージャ４３ａはカードマネージャＡＰＩ４３０ａを有し，ラッパーモジュール４５ａはラッパーＡＰＩ４５０ａを有している。
【００３６】
また，Global Platformに準拠したＩＣカードのソフトウェア階層４ｂには，Global Platformの仕様に準じたカードマネージャ４３ｂと，Global Platformの仕様に合わせたラッパーモジュール４５ｂが実装され, カードマネージャ４３ｂはカードマネージャＡＰＩ４３０ｂを有し，ラッパーモジュール４５ｂはラッパーＡＰＩ４５０ｂを有している。
【００３７】
なお，上述した以外の内容は，Open Platformに準拠したＩＣカードのソフトウェア階層４ａと，Global Platformに準拠したＩＣカードのソフトウェア階層４ｂにおいて，図４で図示したソフトウェア階層４と差異はない。
【００３８】
Open Platformに準拠したＩＣカードのソフトウェア階層４ａに含まれるラッパーモジュール４５ａは，ラッパーＡＰＩ４５０ａの一つがアプリケーション４４から呼ばれると，アプリケーション４４から引き渡された引数を，このラッパーＡＰＩ４５０ａに対応するカードマネージャＡＰＩ４３０ａの形式に変換して，カードマネージャＡＰＩ４３０ａを呼び出し，カードマネージャ４３ａから引き渡された戻り値を，このラッパーＡＰＩ４５０ａの形式に変換して，アプリケーション４４に引き渡す動作を行う。
【００３９】
Global Platformに準拠したＩＣカードのソフトウェア階層４bに含まれるラッパーモジュール４５bは，ラッパーＡＰＩ４５０bの一つがアプリケーション４４から呼ばれると，アプリケーション４４から引き渡された引数を，このラッパーＡＰＩ４５０bに対応するカードマネージャＡＰＩ４３０bの形式に変換して，カードマネージャＡＰＩ４３０bを呼び出し，カードマネージャ４３bから引き渡された戻り値を，このラッパーＡＰＩ４５０bの形式に変換して，アプリケーション４４に引き渡す動作を行う。
【００４０】
それぞれのラッパーＡＰＩ４５０a，ｂの呼び出し名称は共通化しておき，アプリケーション４４がこの呼び出し名称を利用するように作成しておけば，アプリケーション４４を変更することなく，Open Platformに準拠したＩＣカードでも， Global Platformに準拠したＩＣカードでもアプリケーション４４を動作させることができるようになる。
【００４１】
図７は，ラッパーＡＰＩの一例を説明する図である。図７では，カードマネージャ４３の機能を無効にするラッパーＡＰＩ４３０の呼び出し名称をboolean lockCardManager()とし，ＩＣカード１を無効化するラッパーＡＰＩ４３０の呼び出し名称をboolean terminateCard ()とし，それぞれのラッパーＡＰＩ４３０の呼び出し名称はラッパーＡＰＩ４５０ａ，ｂで共通である。
【００４２】
図７に従えば，Open Platformに対応したＩＣカードのラッパーモジュール４５ａは，呼び出し名称がboolean lockCardManager()であるラッパーＡＰＩ４５０ａが呼ばれると，カードマネージャＡＰＩ４３０ａの一つで，カードマネージャ４３ａの機能を無効にするstatic boolean openplatform.OPSystem.lockCardManager()を呼び出し，このカードマネージャ４３ａからの戻り値をリターンする動作を行い，呼び出し名称がboolean terminateCard ()であるラッパーＡＰＩ４５０ａが呼ばれると，カードマネージャＡＰＩ４３０ａの一つで，ＩＣカード１を無効化するstatic boolean openplatform.OPSystem. terminateCard()を呼び出し，このカードマネージャ４３ａからの戻り値をリターンする動作を行う。
【００４３】
また，Global Platformに対応したＩＣカードのラッパーモジュール４５ｂは，呼び出し名称がboolean lockCardManager()であるラッパーＡＰＩ４５０ｂが呼ばれると，カードマネージャＡＰＩ４３０ｂの一つで，カードマネージャ４３ｂの機能を無効にするstatic boolean openplatform.OPSystem.lockCardManager()を呼び出し，このカードマネージャ４３ｂからの戻り値をリターンする動作を行い，呼び出し名称がboolean terminateCard ()であるラッパーＡＰＩ４５０ｂが呼ばれると，カードマネージャＡＰＩ４３０ｂの一つで，ＩＣカード１を無効化するstatic boolean openplatform.OPSystem. terminateCard()を呼び出し，このカードマネージャ４３ｂからの戻り値をリターンする動作を行う。
【００４４】
なお，これまでは，図５のカードマネージャＡＰＩ４３０の仕様差がある場合について説明したが，図５のバーチャルマシンＡＰＩ４２０の仕様差がある場合でも同様である。また，カードマネージャＡＰＩ４３０及びバーチャルマシンＡＰＩ４２０の両方に仕様差がある場合，それぞれの仕様差に対応するラッパーＡＰＩ４３がＩＣカード１に実装される。
【符号の説明】
【００４５】
１    ＩＣカード
２    ＩＣチップ
３    ソフトウェア階層
３０  ハードウェア
３１  プラットフォーム型ＯＳ
３２  アプリケーション
３３  ラッパーモジュール
３３０  ラッパーＡＰＩ
【図１】
2011198298.tif 000003
【図２】
2011198298.tif 000004
【図３】
2011198298.tif 000005
【図４】
2011198298.tif 000006
【図５】
2011198298.tif 000007
【図６】
2011198298.tif 000008
【図７】
2011198298.tif 000009