JP2004086890A - アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 - Google Patents
アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 Download PDFInfo
- Publication number
- JP2004086890A JP2004086890A JP2003207781A JP2003207781A JP2004086890A JP 2004086890 A JP2004086890 A JP 2004086890A JP 2003207781 A JP2003207781 A JP 2003207781A JP 2003207781 A JP2003207781 A JP 2003207781A JP 2004086890 A JP2004086890 A JP 2004086890A
- Authority
- JP
- Japan
- Prior art keywords
- script
- game
- application program
- execution
- smart card
- 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.)
- Withdrawn
Links
Images
Landscapes
- Credit Cards Or The Like (AREA)
Abstract
【課題】高度な情報記憶能力を持ち、高いセキュリティを実現できるＩＣカードシステム上の、ゲームをはじめとするアプリケーションプログラムにおいて、汎用性を増して複数種類のゲームを入れ替え可能にする方式を提供する。
【解決手段】共通化できる処理部分を部品化し、ゲームの定義をスクリプト記述したものを必要に応じて端末から入れ替える。プログラム中には、スクリプトを解釈・実行するインタープリタ、スクリプトの入れ替えを制御する制御部、ポイントデータおよびゲーム実行権の管理を行なう制御部を用意し、これにより動的にゲームの種類を入れ替え可能にするとともに、ひとつのアプリケーションで複数種類のゲームを取り扱い可能にする。
【選択図】 図９
【解決手段】共通化できる処理部分を部品化し、ゲームの定義をスクリプト記述したものを必要に応じて端末から入れ替える。プログラム中には、スクリプトを解釈・実行するインタープリタ、スクリプトの入れ替えを制御する制御部、ポイントデータおよびゲーム実行権の管理を行なう制御部を用意し、これにより動的にゲームの種類を入れ替え可能にするとともに、ひとつのアプリケーションで複数種類のゲームを取り扱い可能にする。
【選択図】 図９
Description
【０００１】
【発明の属する技術分野】
本発明は、アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体に関し、特に、高いセキュリティを持つコンピュータシステム、特に、不揮発性メモリにアプリケーションプログラムを格納し、カード内部でアプリケーションプログラムを実行することが可能なＩＣカードを核としたコンピュータシステムに関するものである。
【０００２】
【従来の技術】
ＩＣチップにＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を内蔵し、カード内部での演算を行なうことができるＩＣカード（あるいはスマートカードと称する）は、高度な情報記憶能力を持ち、高いセキュリティを実現できることから、さまざまな分野での利用が期待され、特に電子マネーなど金融分野において、近年積極的に導入が進められている。
【０００３】
最近では、１枚のカード上に安全に複数のアプリケーションを共存できるようなカードＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が一般化してきた。これらマルチアプリケーション対応カードＯＳとしては、Ｍｏｎｄｅｘ Ｉｎｔｅｒｎａｔｉｏｎａｌ社による“ＭＵＬＴＯＳ”や、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社による“Ｊａｖａ Ｃａｒｄ”（Ｊａｖａは登録商標である）などが知られている。こうしたＯＳによって管理されるマルチアプリケーション対応ＩＣカードでは、アプリケーションプログラム間の独立性が高くなるように制御されており、安全に複数のアプリケーションを共存させられるだけでなく、発行後のカードに新たにアプリケーションプログラムを追加したり、不要なアプリケーションプログラムを削除したりすることも可能となっており、単なる情報格納媒体としてではなく、安全なコンピュータとしてみなすことができる。カードの持つ高いセキュリティを活かし、あるいは従来の磁気カード機能の置き換えという観点から、クレジットカードや電子マネーなどの金融分野での応用、特に複数アプリケーションの連携などが期待されている。
【０００４】
従来から、顧客囲い込みの一手段として、ポイントシステムあるいはロイヤリティプログラム（以下、ポイントシステムと称する）といったシステムが一般化している。これは、「カードの利用に応じてポイントが加算されその点数の蓄積により所定のサービスが受けられるシステム」と定義され、ポイント獲得による特典への期待から、店舗やカードの利用を促すといった効果を狙っている。システムの例として商店街のスタンプカードやデパートなどのポイントシステム、あるいは航空会社のマイレージプログラムのようなものがある。一例としてデパートのポイントシステムを例に挙げると、会員はカードを所持し、該当デパートで買い物をする際にカードを提示すると、購入履歴とともに売り上げに応じてポイントが蓄積され（例えば１０００円の買い物ごとに２０ポイント付加）、ポイントがある一定たまると、そのデパートで利用できる商品券と引き換えることができる（例えば１０００ポイントで１０００円の商品券と交換。つまり、５万円の買い物につき会員は１０００円分の割引が受けられる計算となる）。キャンペーン期間中はポイント付加の割合が倍になったり、１年間の購入額がある一定の金額以上に達すると割引率が高くなったりすることで、消費者の購買意欲を煽るものである。別の例として、航空会社のマイレージプログラムでは、購入額ではなく飛行距離を積算し、ある一定の飛行距離に達すると無料航空券やシートのアップグレードサービスが受けられるというようなシステムもある。この場合も、会員の利用履歴に応じてサービスを与えることにより、会員が同じ航空会社を選択する動機づけを与えるものである。こういったポイントシステムをＩＣカード化することにより、カード利用者のポイントがカード上で正しく管理することが可能となる。マルチアプリケーション対応ＩＣカードにおいては、電子マネーやクレジットカード機能などと組み合わせることで、複数アプリケーションを効果的に連携することも可能となる。
【０００５】
以上述べたようなマルチアプリケーション対応ＩＣカードの特性を活かしたカード上のアプリケーションのひとつとして、ポイントシステムにゲーム機能を付加し、カードに格納されたゲームを実行した結果に応じてポイントの値を連動させる「ゲーム付きポイントシステム搭載ＩＣカードシステム」が提案されてきた。これは、特願平１０−２３９８１２号および特願平１０−３２１６８４号にて出願済みである。これらの発明の中では、ユーザがゲームを実行することのできる回数を「ゲーム実行権」と定義し、このゲーム実行権とゲーム実行の結果であるポイントの値を管理することで、ＩＣカードプログラム中で安全にゲームを実行可能な方法について提案した。
【０００６】
また、これとは別に、ＩＣカード上でポイントシステムの管理を行う方法として、ポイント管理プログラムの中に複数の固有プログラムを有するシステムも提案されている。このシステムは特願平１０−３０７２１６号にて出願されており、この方法によれば、販売店ごとに固有プログラムをポイント管理プログラムの中に埋め込むことにより、ひとつのポイントアプリケーションプログラムで、複数の販売店向けのポイントを管理することが可能となる。
【０００７】
【発明が解決しようとする課題】
“ＭＵＬＴＯＳ”をはじめとするマルチアプリケーション対応ＯＳは、セキュリティの観点から、各々が所定のロード機構を持っている。ロード機構では、アプリケーションをダウンロードする場合に、ダウンロードしたアプリケーションプログラムが改竄されていないか、正当な開発者が開発したものか、カードにそのアプリケーションプログラムをダウンロードする権利があるかといった項目のチェックを行なう。例えば、改竄の有無は、アプリケーションプログラムのハッシュ値を認証局（ＣＡ）の秘密鍵で署名したデータをアプリケーションプログラムに付随させ、カードで再計算したハッシュ値と比較一致するかで検証を行なうことができる。これらのチェックはＩＣカードの安全性を左右するため、各カードごとに厳格な手順が規定されており、また転送されるアプリケーションプログラムも所定のデータ形式を持っていないとダウンロードできない仕組みになっている。この規定をアプリケーション発行スキームと呼ぶ。
【０００８】
このため、マルチアプリケーション対応ＯＳを搭載したＩＣカードにアプリケーションプログラムをロードするためには、上記のアプリケーション発行スキームに従い、所定のアプリケーション認定および登録の手続きを行なわなければならない。そのため、原理的には発行後のカード上でアプリケーションプログラムの入れ替えが可能であるとはいえ、実際にアプリケーションプログラムの入れ替えを行なうためには、かなりの手間と時間が必要になることになる。これはＩＣカードの安全性を保つためであり、通常の金融系アプリケーションであれば、それほど頻繁にプログラムの内容が変更されることもないために大きな問題とはならない。
【０００９】
しかし、ゲームアプリケーションの場合には、ゲームの種類にバリエーションがないとユーザが飽きてしまう可能性が大きく、ゲームの内容をこまめに変更したいという要望が大きい。ゲームの種類をこまめに入れ替えたいという要望に対して、毎回アプリケーション認定・登録の手続きを行っていたのでは、手続きが煩雑でありゲームアプリケーションの特長を活かしきることができない。
【００１０】
また、異なる種類のゲームごとに別々のアプリケーションプログラムを開発・配布していたのでは、古い種類のゲームで得たポイントを新しい種類のゲームに移行する際の手続きが必要となり、このためのポイント管理が煩雑となるという問題点がある。
【００１１】
開発の面でも、類似した機能を持つアプリケーションを毎回別々に開発していたのでは、処理に無駄が多くなるし、たくさんの種類のゲームアプリケーションの開発・配布の間で、発行管理やカードへのロード時の配布管理が必要となる。
【００１２】
さらに、“ＭＵＬＴＯＳ”や“Ｊａｖａ Ｃａｒｄ”といったいくつかの異なるＩＣカード用ＯＳが混在する現状においては、ＩＣカード上のゲームアプリケーションプログラムを、ゲームの種類を変えるたびに複数のプラットフォーム上に別々に構築する必要があり、開発工数が大きくなるという問題点がある。
【００１３】
なお、これらの問題はゲームアプリケーションに限った問題ではなく、処理内容を頻繁に変更したいＩＣカード上のアプリケーションにおいては、同様の問題が生じることが予想される。
【００１４】
本発明の目的は、ＩＣカード上で実行するゲームアプリケーションにおいて、ゲームのバリエーションを増やした場合であっても、煩雑なアプリケーションプログラム入れ替え処理が不要となり、これにより手軽に複数種類のゲームをカードの上で扱うことのできるとともに、ＯＳの違いに依存せずに新しいゲームを開発可能とするような、ゲームアプリケーションプログラムを提供することにある。
【００１５】
またこれをゲームアプリケーションだけでなく、一般のアプリケーションにも拡張するならば、本発明の別の目的は、ＩＣカードのアプリケーションにおいて、処理のバリエーションを増やした場合にも煩雑なアプリケーションプログラム入れ替え処理が不要となり、これにより手軽に複数種類の処理を扱うことのできるともに、ＯＳの違いに依存せずに新しいゲームを開発可能とするような、ＩＣカード上のアプリケーションプログラムを提供することにある。
【００１６】
【課題を解決するための手段】
以上の目的を達成するために、ＩＣカード上の単一のアプリケーションプログラムで複数種類のゲームを扱うための手段を提案する。
【００１７】
まず考えられる方針は、ゲーム実行の結果であるポイントデータおよびゲーム実行権を取り扱うための部分（データ格納部および処理部）を複数ゲーム間で共有することである。ゲームプログラムの処理において、ポイントデータおよびゲーム実行権の管理部分を共通化してしまえば、ゲームによって異なるのは、実際にゲーム結果を判定するアルゴリズムだけと考えて良い。
【００１８】
しかし、それほど複雑な計算を行なえるとは言い難いＩＣカード上で主に実行されるゲームの種類を吟味すると、ゲーム実行部分は、「端末経由でユーザから送られるデータを受信」「乱数の発生」」「簡単な加減算」「データの格納」「データの比較と分岐」程度の処理とその組み合わせを繰り返すものであることがわかる。これらの処理を行なう部分を「コンポーネント」として部品化すると、それぞれのゲームの定義は、これらのコンポーネントの呼出し順序を定義する「スクリプト」のようなもので表現することができる。 つまり、ＩＣカードのひとつのアプリケーションプログラム中に、ゲームを実行するための処理を行なう処理部品「コンポーネント」と、スクリプトを解釈・実行する「インタープリタ」を用意すれば、プログラム外部で生成されたゲーム定義用の「スクリプト」を実行することで異なるゲームの処理を行なうことができる。
【００１９】
また、このスクリプトを必要に応じて端末を通じてアプリケーションプログラム外部から入れ替えられるようにすれば、ＩＣカード上の単一のゲームアプリケーションプログラムによって、異なる複数種類のゲームを実行することが可能となる。
【００２０】
しかし、スクリプトの入れ替え・追加を可能とした場合に、ここでどんなスクリプトでもアプリケーションプログラム内部に格納してしまったとしたら、悪意のあるスクリプトによりゲーム結果のポイントが不正な値にされてしまう可能性もあり、せっかくのＩＣカードＯＳの持つセキュリティが活かされないことになる。そこで、ＯＳの定義したアプリケーションプログラム発行スキームの代わりに、アプリケーション内部で擬似的な発行スキームを規定することで、不正なスクリプトが格納されないように制御しなければならない。具体的には、スクリプトの入れ替えを制御する制御部を用意し、不正なスクリプトが格納されないようにする必要がある。
【００２１】
つまり、ＯＳの持つアプリケーションプログラム発行スキームの代わりに、アプリケーションプログラムが擬似的なゲーム発行スキームを用意し、安全性を確保するとともに、アプリケーションプログラム内部でスクリプトの解釈・実行を行なう処理部を用意することで、限られた機能ではあるが異なる種類のゲームを単一のプログラムで実行することを可能とするものである。
【００２２】
また、ゲームの結果に応じて値が変化し、後で所定のサービス（物品との交換など）が受けられるポイントデータについては、複数のゲーム間で共通に処理できることはもちろんであるが、カード内部に格納するゲーム定義スクリプトにゲーム発行元の情報を付け加えておくことにより、ポイントも発行元ごとに管理することが可能となる。
【００２３】
従って、本発明が課題を解決する手段としては、以下の６つの項目が挙げられる。
【００２４】
まずＩＣカード側の手段としては、
（１）以下の要素からなるアプリケーションプログラム：
（ａ）ゲーム実行コンポーネント：ゲームを実行するために必要な、カードプログラム中の処理を集めた部品
（ｂ）ゲーム定義スクリプト格納部：コンポーネントの実行順序を定めたスクリプトを格納するエリア
（ｃ）スクリプトインタープリタ：ゲーム定義スクリプトを解釈・実行するインタープリタ
（ｄ）ポイントデータ格納部・処理部：ゲームの結果として変化するポイントの値を格納するエリアおよび、ポイントデータを管理する処理部
（ｅ）ゲーム実行権格納部・処理部：ゲームを実行する権利に関する値を格納するエリアおよび、ゲーム実行権を管理する処理部
（ｆ）コマンド処理部：端末からのコマンドを処理し、プログラム内部での各処理を呼び出す処理部
以上が必須であり、これに加えて必要に応じて、
（２）ゲーム定義スクリプト格納処理部：ゲーム定義スクリプトの格納および入れ替えを管理する機能を持つ。アプリケーションプログラムが規定するゲーム発行スキームに基づき処理する。
【００２５】
（３）発行元別ポイント管理機能：発行元別にポイントおよびゲーム実行権を管理する機能を持つ。
【００２６】
が用意される。
【００２７】
次に、このＩＣカードを取り扱うための端末装置としては、
（４）ゲーム発行機能：所定のプロトコルによってＩＣカードとデータ通信を行ない、ゲーム定義スクリプトデータあるいは／およびゲーム実行権データをＩＣカードに対して発行する機能を持つ。ゲーム定義スクリプトとゲーム実行権は、別々に管理される場合も、同一のものとして管理される場合もあり得る。
【００２８】
（５）ゲーム実行機能：所定のプロトコルによってＩＣカードとデータ通信を行ない、ゲームを実行するためのコマンドによってゲームを実行する。ユーザがゲームを実行できるようなユーザインタフェースも必要である。
【００２９】
（６）ポイント演算機能：所定のプロトコルによってＩＣカードとデータ通信を行ない、カードに格納されたポイントデータに対する値の取得および新しい値の設定（主に減算）を行なう。ポイントデータが発行元別に管理されている場合には、発行元別の識別子を付けてポイント演算を行なう。
【００３０】
が必要となる。（４）から（６）までの各機能は、すべて同一の端末にあっても良いし、別々の端末に機能を分担して持たせても良い。
【００３１】
【発明の実施の形態】
図１に、ＩＣカードを用いたゲーム付きポイントシステムのサービスイメージ図を示す。システムは大きく分けて、サービスを提供するサービスプロバイダ側（１０１）とサービスを受けるユーザ側（１０９）に分けられる。サービスプロバイダ側（１０１）は、ゲームアプリケーションをＩＣカードおよび端末に供給するアプリケーション提供者（１０２）、ゲームの運営を管理するサービス管理者（１０３）、各ユーザへのゲームの供給やポイント交換などを行う店舗（１０４）から構成される。ここで、アプリケーション提供者（１０２）とサービス管理者（１０３）は双方の役割を兼ねることもあるし、分担する場合もある。店舗（１０４）は通常の場合、別々の地点に複数存在するが、１箇所だけでアプリケーション提供者（１０２）やサービス管理者（１０３）と同一となる場合もある。ユーザ側（１０９）は、ひとり以上のユーザ（１１３）から構成され、それぞれのユーザ（１１３）はＩＣカード（１１０）を１枚以上所有している。ユーザ（１１３）は、カード内部でゲームを実行するための入出力機能を持った、ユーザ用ゲーム実行端末（１１１）を保有している場合もある（必須ではない）。この、ユーザ用ゲーム実行端末（１１１）は、機能をゲーム実行だけに限定する必要はなく、ＩＣカード（１１０）への入出力機能を備えておりゲーム実行を補助するものであれば、ＩＣカード用リーダライタ（Ｒｅａｄｅｒ／Ｗｒｉｔｅｒ：ＩＣカードに対するアクセスを行う装置）を備えた通常のＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ：パーソナルコンピュータ）であっても、カード内の残高照会などを行う機能を持つＩＣカード取扱専用携帯端末であってもよい。
【００３２】
アプリケーション提供者（１０２）は最初に、各ユーザ（１１３）のＩＣカード（１１０）に対してゲームアプリケーションのロードを行う。ＩＣカード（１１０）がユーザ（１１３）に対して発行された時点で、ゲームアプリケーションがカード内にロードされている場合もあるが、カード発行後にもゲームアプリケーションを自由にカードにロードすることができることが、マルチアプリケーション対応ＯＳ搭載ＩＣカードの特長である。アプリケーションロードに関わる情報は、以下に述べるゲーム管理データ（１０６）に反映される場合もある。
【００３３】
サービス管理者（１０３）は、本ゲーム付きポイントシステムに関する各種情報を集めたゲーム管理用データ（１０６）から必要なデータを受け、ゲーム管理用サーバ（１０７）にてゲーム用の各種パラメータを各店舗（１０４）の店舗用端末（１０８）に対して配信する。
【００３４】
店舗（１０４）では、ユーザ（１１３）の店舗利用（買い物など）に応じて、ＩＣカード（１１０）に対してゲームの実行権あるいはゲームパターンを発行する。ここで、ゲームの実行権とはユーザがゲームを実行する権利であり、ゲーム実行後には消滅する。ゲームパターンは、ＩＣカード内で実行するゲームの各種パラメータのことであり、ゲーム実行権を含む。
【００３５】
ユーザ（１１３）は、ＩＣカード（１１０）にゲーム実行権が与えられた状態で、ユーザ用ゲーム実行端末（１１１）あるいは店舗（１０４）に備え付けられた店舗内ゲーム実行端末（１１２）（店舗側が管理する端末。ユーザ用ゲーム実行端末と同様、ゲーム実行機能だけに限定する必要はなく、ＩＣカードとのインタフェースとゲーム実行機能があれば形状は問わない）を通じて、カード内部のゲームの実行を行う。ゲーム実行の結果に応じて、ＩＣカード（１１０）内のポイントの値が更新される。
【００３６】
このポイントを店舗（１０４）にて商品や賞金と交換する。ゲームの発行状況やユーザの実行履歴、ポイントの交換履歴などのデータは随時ゲーム管理用データ（１０６）に蓄積され、次回のゲームパラメータ生成やゲーム発行にフィードバックされる。このように、ゲームの最新のデータを用いて、サービス管理者がゲームのパラメータを動的に制御することにより、サービスプロバイダ側（１０１）ではシステム全体の状況を管理することが可能となる。
【００３７】
次に、図２を用いて、マルチアプリケーションＩＣカード上のプログラム実行における情報の流れについて簡単に説明する。ＩＣカード（１１０）は、カードＯＳ（２０１）と入出力インタフェース（２０２）を備え、ひとつ以上のアプリケーションプログラム（２０３）が、所定の手順によりロードされている。図中で、アプリケーションプログラム（２０３）とアプリケーションプログラム（２０３’）とは別の独立したプログラムであり、双方が他方のデータに不正にアクセスすることは禁止されている。端末（１２０）には、ＩＣカード用リーダライタ（１６１）および入出力インタフェース（１６４）と端末ＯＳ（１６３）とを備え、ＩＣカード中のアプリケーションプログラムを扱うための端末プログラム（１６２）が、ひとつ以上ロードされている。通常、ＩＣカードのアプリケーションプログラムひとつに対してひとつ以上の端末プログラムが必要である。
【００３８】
ユーザ（あるいは店員など）が、端末（１２０）に対してユーザインタフェースを通じて入力を行なう（１５１）と、端末プログラム（１６２）では、ＩＣカードに送信するためのコマンドを生成する（１５２）。端末プログラム（１６２）は、リーダライタ（１６１）を通じて、このコマンドをＩＣカード（１１０）に送信する（１５３）。ＩＣカード（１１０）はコマンドを受け取ると、カードＯＳ（２０１）がコマンド送信先のアプリケーションプログラム（２０３）を判定し、端末プログラム（１６２）が意図したアプリケーションプログラム（２０３）に対してコマンドを送信する（１５４）。アプリケーションプログラム（２０３）中の実行処理部（２０５）では、このコマンドに従い処理を行ない、アプリケーションデータ（２０４）に対してアクセスし、値の更新などを行ない（１５５）、レスポンスを生成する（１５６）。レスポンスは端末（１２０）に返され（１５７）、端末プログラム（１６２）ではこの結果を提示する（１５８）。これが一連のプログラム実行の流れである。
【００３９】
アプリケーションプログラム（２０３）が複数ロードされている場合でも、端末プログラム（１６２）でコマンドを発行する相手のアプリケーションプログラム（２０３）を切り替えることにより、端末（１２０）を介してＩＣカード（１１０）上のプログラム実行が可能となる。基本的に、ＩＣカード上のアプリケーションプログラム（２０３）はお互いのデータに不正に影響を及ぼさないように制御されているが、例えば“ＭＵＬＴＯＳ”の場合では、デリゲーション（ｄｅｌｅｇａｔｉｏｎ：委任・委譲などの意味を持つ）と呼ばれる所定の方法により、複数のアプリケーションプログラムが連携し合って動作することが可能である。（最新の“ＭＵＬＴＯＳ”にはこの機能が備えられている。デリゲーション機能の詳細は省略する）
次に、図３から図８までを用いて、本発明の実施例により実現されるゲーム付きポイントシステムにおける、具体的なＩＣカードの構成を説明する。ここでは、ゲームの種類を２種類に増やした場合を例にとり説明する。ここで、ゲームの「種類」とは、ゲーム実行の結果をポイントにどのように反映するかを定義するアルゴリズムが異なるもののバリエーションであり、ここで言うアルゴリズムは、基本的にはＩＣカード内のデータの演算と乱数発生などの組み合わせにより定義されるものである、とする。
【００４０】
図３は、ゲームの種類を２種類に増やした場合の、既出願発明（特願平１０−２３９８１２号および特願平１０−３２１６８４号）によるゲームアプリケーションで実現可能なＩＣカードの構成である。ＩＣカード（１１０）は、“ＭＵＬＴＯＳ”や“Ｊａｖａ Ｃａｒｄ”などのマルチアプリケーション対応のカードＯＳ（２０１）のもと動作し、端末（１２０）とのデータのやりとりを行う入出力インタフェース（２０２）を備えている。既出願発明のアプリケーションの構成では、ひとつのアプリケーションに対して結果判定アルゴリズムはひと通りであり、ゲームの種類だけゲームアプリケーションプログラム（２００）が必要になる。ここでひとつめのゲームを（Ａ）、ふたつめのゲームを（Ｂ）とする。
【００４１】
ゲームアプリケーションプログラム（Ａ）（２００）は、ゲームパラメータ（２２１）、ゲーム実行権（２２２）、ポイントデータ（２２３）のそれぞれのデータを格納する部分と、コマンド処理部（２１１）、結果判定アルゴリズム（２１２）、実行権処理部（２１３）、ポイントデータ処理部（２１４）といった実際に処理を実行する部分とから構成される。図中（２１１）、（２１２）、（２１３）、（２１４）の網掛けで表した部分は、それぞれ処理を実行する部分であって、いったんプログラムがカードにロードされたらプログラム中で固定であることを示す。（２２１）、（２２２）、（２２３）のデータ格納部では、格納されたデータの内容はプログラム実行に伴い変化する。端末（１２０）からのコマンドは、大きく分けて店舗からのゲーム発行に関わるコマンドと、ユーザからのゲーム実行に関わるコマンドとがあり、コマンド処理部（２１１）ではコマンドの種類に対してそれぞれの処理実行部に処理を振り分け、これによりポイントデータやゲーム実行権データの増減などを行なう。ユーザからのゲーム実行のコマンドに対しては、ユーザ入力に応じて、結果判定アルゴリズム（２１２）とゲームパラメータ（２２１）の値に基づいてゲーム実行を行ない、この結果に応じてポイントデータ（２２３）の値を変更すると同時に、ゲーム実行権（２２２）を減少させて、店舗から与えられた実行可能回数を超えてゲームの実行を行なわせないように制御する。
【００４２】
ゲームアプリケーションプログラム（Ｂ）（２００’）に対しても（Ａ）と同様の構成となっており、それぞれ独立した処理系としてプログラムが実装される。端末（１２０）からのコマンドはアプリケーション選択後に送られてくるので、それぞれのゲームアプリケーションプログラム（２００）、（２００’）に対しては独立に設定されたコマンド発行により、アプリケーションプログラムが動作する。当然、ゲーム実行の結果生じるポイントデータ（２２３）、（２２３’）についても別々に格納されており、ポイント交換などの際にまとめて処理を行うことは原則としてはできない。ゲーム（Ａ）とゲーム（Ｂ）において決定的に異なるのは、結果判定のアルゴリズム（２１２）（２１２’）であり、それ以外のゲーム実行権やポイントを処理する部分では類似した機能から構成されているのにも関わらず、別々のプログラムとして処理を行うのは、リソースの限られたＩＣカードでは無駄も大きいという問題がある。
【００４３】
また、“ＭＵＬＴＯＳ”においては、基本的にゲームアプリケーション（Ａ）のプログラム（２００）とゲームアプリケーション（Ｂ）のプログラム（２００’）は別のアプリケーションなので、アプリケーションを搭載する際には、それぞれについてＯＳの定めた発行スキームによりアプリケーションの登録・認定の処理が必要となる。カード発行後に動的にアプリケーションの搭載・削除ができることがマルチアプリケーションＩＣカードの大きな特長であるとはいえ、ゲームのように内容をこまめに変更したいアプリケーションにおいて、別のアルゴリズムで動作するゲームを開発するたびにアプリケーションの登録・認定処理を行うのは煩雑であり、負担が大きい。また、ゲームを（Ａ）から（Ｂ）に入れ替えた場合、ゲーム（Ａ）実行の結果蓄積されたポイントは、ゲームの種類が変わっても継続して使えるようにしたいというのがユーザの自然な要求であるが、図３の構成では、異なるゲーム間のポイントの移行、およびそれに伴うポイント情報の管理は簡単ではない。
【００４４】
複数のゲーム間でのポイントの共有に関する問題の解決方法のひとつとして考えられるのは、ポイント管理のアプリケーションをゲームアプリケーションとは別アプリケーションとすることである。この方法は、上記の既出願発明によっても実現可能な手段である。ゲームアプリケーションとは別にポイントアプリケーションプログラムを用意し、この中でポイントデータの管理を行なうものである。ポイントの値の変更処理は、ゲームアプリケーションからの依頼に応じて、カードＯＳ（２０１）の持つデリゲーション処理を用いて行なう。ただし、この方法を用いてポイント一括管理の問題は解決しても、新しいゲームを追加する場合にアプリケーションの登録・認定処理を行う必要があることには変わりがなく、根本的な解決にはならない。
【００４５】
そこで、単一のアプリケーション上で複数種類のゲームを扱う方法を考える。
【００４６】
図４は、まとめて管理したいポイントデータとコマンド処理を共通部分とし、ゲームのパラメータや結果判定アルゴリズムなど固有の処理を行う部分は、ゲームの種類だけ用意する方式をとった場合の、ＩＣカードの構成を示す。ＩＣカード（１１０）には、ゲームアプリケーションプログラム（２００）を搭載するが、この中ではゲーム（Ａ）とゲーム（Ｂ）の２種類のゲームを扱うことができる。もちろん、別の種類のゲーム（Ｃ）を載せることもできるが、この図の例では２種類のゲームを搭載しているものとして説明を続ける。なお、アプリケーションを発行した時点で扱えるゲームの種類は決まっており、ゲームの新規追加は行えない。
【００４７】
ゲームの実行の結果として得られるポイントデータ（２２３）は、複数種類のゲームで共通して扱えるようにする。また、端末からのコマンドを受け取り処理を分岐するコマンド処理部（２１１）も、ゲーム処理とは分けて複数ゲームで共有できるようにする。ゲームパラメータ（２２１）、ゲーム実行権（２２２）、結果判定アルゴリズム（２１２）をゲームによって異なる部分として、ゲームの種類分だけ持たせ、実行権処理部（２１３）およびポイントデータ処理部（２１４）は共通処理部として用意する。
【００４８】
端末（１２０）から送られるコマンドの体系は、ゲームの種類によって識別できるようにしておき、コマンド処理部（２１１）は送られてきたコマンドを解析し、どの種類のゲーム宛のコマンドなのかを判別して処理を切り替える。ゲーム（Ａ）へのコマンドであれば、ゲーム（Ａ）の結果判定アルゴリズム（２１２）に従い処理を行い、その結果に応じてポイントデータ（２２３）を更新する。ゲーム（Ａ）によっても、ゲーム（Ｂ）によっても同様に、ポイントデータ（２２１）の値が更新される。
【００４９】
図４の方法から一歩進めたのが、図５によって示される方法である。ＩＣカード上のゲームは基本的に、ユーザからの入力された値を処理することと、入力タイミングに応じてカードの中で乱数を発生すること、ローカルな変数およびパラメータとして与えられる定数を組み合わせて結果を判定することの繰り返しで表現されるものがほとんどであり、結果判定アルゴリズムが異なっていても、その他の部分で共通化できる部分が大きい。そこで、乱数発生や加減算、繰り返しなど複数ゲーム間で共通化できるものを共通処理コンポーネントとして部品化する。共通処理コンポーネント（２２４）には、似た処理を行う部品をコンポーネントとして用意しておく。
【００５０】
ゲーム（Ａ）については、ゲームパラメータ（２２１）およびゲーム実行権データ（２２２）の格納部を持ち、ゲーム（Ａ）の実行部（２１５）には、コンポーネントの呼出定義（２２５）により、共通処理コンポーネント（２２４）をどのような順序で呼び出してゲームの正解判定を行なうのかという処理手順が定義されている。プログラムの実行については図４の方法とほぼ同じであり、コマンドの種類によってコマンド処理部（２１１）にてゲームの切り替えを行なうことで、あらかじめプログラムに組み込まれている範囲においては、複数のゲームを扱うことができる。図５例では、図４の例に比べて、共通化できる部分を極力コンポーネント化することにより、アプリケーションの効率化が図られている。
【００５１】
図４の方法でも、図５の方法でも、アプリケーション開発時にあらかじめ組み込んでおいたゲームについては複数種類を扱うことができ、端末からのコマンドに応じていくつものゲームを切り替えて実行することができるが、アプリケーション開発・発行後に別の種類のゲームを組み込むことはできない。後から別の種類のゲームを実行できるようにするためには、また新たなアプリケーションを開発し、登録・認定処理を行い、アプリケーションの入れ替えを行う必要がある。
【００５２】
そこで、以下図６および図７では、アプリケーションの登録・認定処理やアプリケーションの入れ替えを行う必要なしに、ゲームの種類を入れ替えたり追加したりできる方法を提案する。
【００５３】
具体的には、図５の方法で用いた、コンポーネント呼出定義（２２５）を一歩進めてスクリプト定義とし、実行部にはゲーム定義スクリプトを解釈・実行するインタープリタを用意する。そして、入れ替え可能なスクリプトによって異なるゲームの定義を行なうとともに、それぞれのスクリプトをインタープリタにより実際に解釈・実行するというものである。
【００５４】
図６は、ゲーム定義をスクリプト化し、インタープリタにて実行する方法のゲームアプリケーションを持つＩＣカードの構成を示す。ここでも、網掛けで示した部分はあらかじめプログラムで定められた固定の部分である。
【００５５】
この例では、ゲーム定義と実行権定義を別のものとして扱う。ゲーム実行権（２２２）、ポイントデータ（２２３）は図５までの例と同様、実行権処理部（２１３）およびポイントデータ処理部（２１４）により全ての種類のゲームに関して共通に扱う。共通処理コンポーネント（２２４）はあらかじめ定義されており、ゲーム定義スクリプト（２２６）は、これらのコンポーネントの呼出し順序を記述することで、ゲームごとに異なる結果判定アルゴリズムを定義する。
【００５６】
このゲーム定義スクリプト（２２６）は入れ替えが可能であり、スクリプトの入れ替えはゲーム定義スクリプト入れ替え処理部（２１６）が制御する。ＩＣカードのセキュリティを守るために厳格なアプリケーション発行スキームが定められているにも関わらず、簡便なゲーム種類入れ替えのためにスクリプト定義によりゲームの種類を入れ替えられるようにすることは、このことにより安全性を犠牲にする可能性があることは否定できない。このため、格納しようとするゲーム定義スクリプトが改竄されていないか、正当な開発者が開発したものか、ゲームにそのスクリプトを格納する権利があるかといった項目のチェックは、アプリケーションプログラム内部で行なわなければならない。つまり、ＯＳのもつアプリケーション発行スキームの代わりに、アプリケーション内部で独自のゲーム発行スキームを用意し、これに基づき安全なゲームスクリプトだけがカード内部格納されるように制御する。この役割をゲーム定義スクリプト入れ替え処理部（２１６）が行なうのである。
【００５７】
ゲーム実行権（２２２）データは、どの種類のゲームを何回実行可能かということを定義するデータであり、ゲーム発行時にカードに格納される。端末（１２０）からゲーム実行に関するコマンドを受信した場合には、ゲーム実行権（２２２）があれば、ゲーム定義スクリプト（２２６）の内容をスクリプトインタープリタ（２１５）で解釈するとともに実行する。ゲームの実行が終われば、ゲーム実行権（２２２）を減らす処理を行なうことはすでに説明した構成のものと同様である。ゲーム定義スクリプト（２２６）を複数種類格納することにより、複数種類のゲームに対応することができ、かつ、ゲーム定義スクリプト入れ替え処理部（２１６）により、アプリケーションをカードにロードした後でも、ゲームの種類を入れ替えることが可能となる。
【００５８】
図７は、図６の例と似ているが、ゲーム定義スクリプトの中にゲームの実行権を含ませたもので、ゲーム定義スクリプト（２２６）がすなわち１回分のゲーム実行権を含むゲームの定義、となっている。従って、ゲーム定義スクリプトで記述された１回分のゲームを実行したら、そのスクリプトは削除し、二度と実行できないように制御する必要がある。また、ゲーム実行権の管理とゲーム定義スクリプトの管理とは同一となり、ゲームデータ格納処理部（２１７）が管理する。ゲーム発行時に端末から送られて来たスクリプトをデータエリアに格納するとともに、スクリプト実行後のスクリプト削除もここで処理を行なう。ゲームデータ格納処理部（２１７）で、図６におけるゲーム定義スクリプト入れ替え処理部（２１６）と同様のスクリプト安全性チェックを行なわなければならないのは言うまでもない。
【００５９】
図８はさらに、図６の方法を複数のポイント系列に対応させたものである。ゲーム実行権（２２２）は、発行元とゲーム種別と実行回数を組にしたデータとして格納されている。ポイントデータ（２２３）も、点数は発行元別に格納される。ゲーム実行のコマンドが端末から送られてくると、発行元別の実行権（２２２）をチェックして、実行権があるゲーム種別について、ゲーム定義スクリプト（２２６）に従い、スクリプトインタープリタ（２１５）がゲームを実行する。ゲーム実行に伴うポイントデータ（２２３）の追加は、発行元別に点数を追加し、実行済みの発行元別実行権（２２２）を減算する。
【００６０】
この方式は、前出の出願済み発明（特願平１０−３０７２１６号）のポイントシステムの考え方を応用したものであり、ポイントデータ（２２３）が一通りではなく、複数のポイント系列に対応するものである。こうすることによって、ゲームの種類を複数にしただけでなく、ポイントサービスの提供者を複数にも対応させられる。これによって、ゲームのサービス運用者がそれぞれの店舗に対して、ゲームアプリケーションの間貸しのようなことをすることも可能となり、ゲームアプリケーションの可能性がさらに広がることになる。
【００６１】
次に、図９および図１０を用いて、図６および図７で説明した構成のＩＣカードを用いたゲーム付きポイントシステムにおけるシステム運用例を説明する。ここで、図９の運用例は図６のＩＣカードに対応したもので、ゲーム定義スクリプトとゲーム実行権が別々になっており、ゲーム種類の入れ替えは適当なタイミングで行なうことを想定したものである。図１０の運用例は図７のＩＣカードに対応したもので、ゲーム定義スクリプトとゲーム実行権が一緒になったものであり、ゲームを実行する毎にスクリプトも無効化（削除）してしまうものである。
【００６２】
図９は、複数ゲームに対応したゲームアプリケーションが搭載されたＩＣカードを用いたゲーム付きポイントシステムの運用例を表す図であり、この例では、ゲーム定義スクリプトとゲーム実行権データとは別のものになっている。
【００６３】
まず、ＩＣカード（１１０）には、ゲームアプリケーションプログラム（２００）がロードされており、このゲームアプリケーション（２００）は、コマンド処理部（２１１）、スクリプトインタープリタ（２１５）、ゲーム定義スクリプト入れ替え処理部（２１６）、実行権処理部（２１３）、ポイントデータ処理部（２１４）などから構成されている。ポイントデータ（２２３）は、発行元の会社ごとに管理されたポイントの点数のデータとして格納されている。ゲーム実行権（２２２）に関しても発行元ごとに管理されており、ゲームの種別と実行可能回数が格納されている。ゲーム定義スクリプト（２２６）は、ゲームの内容を共通処理コンポーネント（２２４）の呼出し順序を記述することで定義したものであり、実際にはスクリプトインタープリタ（２１５）でスクリプトの内容を解釈して実行する。このゲーム定義スクリプト（２２６）は、必要に応じて入れ替えることも可能である。
【００６４】
以下、ゲームの入れ替え・ゲーム発行・ゲーム実行・ポイント交換のそれぞれの段階に分けて、処理手順を説明する。
【００６５】
（ゲームの入れ替え）
店舗（１０４）あるいはその他の場所にある、ゲーム定義発行用端末（１１４）から、ゲーム入れ替えコマンド（１３２）およびゲーム定義データ（１４１）をＩＣカード（１１０）に対して送信する。すると、コマンド処理部（２１１）でコマンドを解釈し、ゲーム入れ替えコマンド（１３２）であることがわかれば、ゲーム定義スクリプト入れ替え処理部（２１６）にて、ゲーム定義の入れ替え処理を行なう。このとき、送られてくるゲーム定義スクリプトというのは、ポイントデータを書き換えることもできるものであることから、正しく発行元から発行されたものであるということが保証されていなければならない。そのために、発行するゲーム定義データ（１４１）には、あらかじめアプリケーションで定義したゲーム発行スキームに従い、発行元が正しいスクリプトであることを認証するような暗号キーをつけ、これによりゲーム定義スクリプト入れ替え処理部（２１６）にて認証処理を行なう必要がある。なお、ゲーム実行の際にはゲーム実行端末（１１１）に対応する端末プログラムが必要であるから、新しいゲームを発行する際には、端末側のプログラムの入れ替えが必要になる場合もある。
【００６６】
（ゲーム発行）
（Ｘ）社の店舗（１０４）での購入に応じて、店舗用端末（１０８）はＩＣカード（１１０）に対して、実行権発行コマンド（１３３）および実行権データ（１４２）を送信する。この実行権データ（１４２）には、ゲーム（Ａ）を１回実行可能で発行元は（Ｘ）社であるという情報が含まれる。このデータについても安全のために暗号化されていることが望ましい。コマンド処理部（２１１）ではコマンドを解釈し、実行権処理部（２１３）にてゲーム実行権データ（２２２）にデータを追加する。
【００６７】
（ゲーム実行）
ユーザ（１１３）がゲームを実行する場合は、ゲーム実行コマンド（１３１）がＩＣカード（１１０）に送信される。ゲーム実行権（２２２）が存在すれば、該当する種別のゲームを実行できる。ゲーム実行に伴い、ポイントデータ（２２３）の値が変化するが、この場合は、実行中の実行権データ（２２２）に含まれる、ゲーム実行権発行元のポイントを更新する。ゲーム実行後は、該当するゲーム実行権（２２２）を減らす処理を行なう。なお、ゲームを実行する場合には、ゲーム実行端末の中（１１１）に、ＩＣカードのゲームの種類に対応した実行用端末プログラムが必要である。
【００６８】
（ポイント交換）
ゲーム実行によって蓄積したポイントデータ（２２３）は、店舗（１０８）において規定のサービスと交換できるが、その際には、店舗用端末（１０８）（ゲーム実行権を発行する端末と同じ物でも違うものでもよい）から、ポイント演算コマンド（１３４）をＩＣカード（１１０）に対して送信する。コマンド処理部（２１１）にてポイントデータ処理部（２１４）に処理を渡し、ポイントデータ処理部（２１４）はポイント減算の処理を行なう。この場合、コマンドを送った店舗（１０４）が（Ｘ）社であれば、ポイント交換は（Ｘ）社発行のポイントだけを交換可能とする。
【００６９】
この方式においては、ゲーム定義スクリプト（２２６）の種類だけ、ユーザはゲームの実行が可能となる（もちろん、ゲーム実行権が存在する場合に限られる）。必要に応じてゲーム定義スクリプト（２２６）の入れ替えを行なうことにより、ゲームアプリケーション（２００）を入れ替えることなしに、常に新しいゲームを実行することができる。
【００７０】
図１０は、複数ゲームに対応したゲームアプリケーションが搭載されたＩＣカードを用いたゲーム付きポイントシステムの、別の運用例を表す図であり、この例では、ゲーム定義スクリプトがゲーム実行権データと一体になっている。図９の運用例と同様に、ＩＣカード（１１０）にはゲームアプリケーションプログラム（２００）がロードされており、このゲームアプリケーション（２００）は、コマンド処理部（２１１）、スクリプトインタープリタ（２１５）、ゲームデータ格納処理部（２１７）、ポイントデータ処理部（２１４）などから構成されている。ポイントデータ（２２３）は、発行元の会社ごとに管理されたポイントの点数のデータとして格納されている。図９の例と異なるところは、ゲームデータ（２２７）として、ゲーム定義スクリプトと発行元情報が対になったものを一組として、データを格納しているところである。ゲーム定義スクリプトをスクリプトインタープリタ（２１５）でスクリプトの内容を解釈して実行するところは同様である。このスクリプトは、１回分のゲーム実行権として見なすことができ、ゲーム実行の際には、対応する発行元のポイントデータ（２２３）のみを書き換えることができ、ゲーム実行が終了したら削除などにより無効化され、二度と同じスクリプトが実行されないようにする。
【００７１】
こちらも以下、ゲームの入れ替え・ゲーム発行・ゲーム実行・ポイント交換のそれぞれの段階に分けて、処理手順を説明する。
【００７２】
（ゲーム発行）
（Ｘ）社の店舗（１０４）での購入に応じて、店舗用端末（１０８）はＩＣカード（１１０）に対して、ゲーム発行コマンド（１３５）および、ゲーム定義スクリプトと発行元を含むゲームデータ（１４３）を送信する。安全のため、発行するゲームデータ（１４３）には、あらかじめ定義した方法により、発行元が正しいスクリプトであることを認証するような暗号キーをつけ、これによりゲームデータ格納処理部（２１７）にて認証処理を行なう必要がある。なお、ゲーム実行の際にはゲーム実行端末（１１１）に対応する端末プログラムが必要であるから、新しいゲームを発行する際には、端末側のプログラムの入れ替えが必要になる場合もある。
【００７３】
（ゲーム実行）
ユーザ（１１３）がゲームを実行する場合は、ゲーム実行コマンド（１３１）がＩＣカード（１１０）に送信される。ゲームデータ（２２７）が存在すれば、ゲーム定義スクリプトにより記述されたゲームを実行できる。ゲーム実行に伴い、ポイントデータ（２２３）が増やされるが、この場合は、実行中のゲームデータ（２２７）に含まれる発行元のポイントを増やす。ゲーム実行後は、該当するゲームデータ（２２７）をスクリプトごと消去し、二度と実行できないようにする。なお、ゲームを実行する場合には、ゲーム実行端末の中（１１１）に、ＩＣカードのゲームの種類に対応した実行用端末プログラムが必要である。
【００７４】
（ポイント交換）
ゲーム実行によってためられたポイントデータ（２２３）は、のちほど店舗（１０８）において規定のサービスと交換できるが、その際には、店舗用端末（１０８）（ゲーム実行権を発行する端末と同じ物でも違うものでもよい）から、ポイント演算コマンド（１３４）をＩＣカード（１１０）に対して送信する。コマンド処理部（２１１）にてポイントデータ処理部（２１４）に処理を渡し、ポイントデータ処理部（２１４）はポイント減算の処理を行なう。この場合、コマンドを送った店舗（１０４）が（Ｘ）社であれば、ポイント交換は（Ｘ）社発行のポイントだけを交換可能とする。
【００７５】
この方式においては、ゲームデータ（２２７）としてゲーム定義スクリプトを含んでいるので、同じ種類のゲームを複数格納する場合にはスクリプトがだぶる場合があり、無駄となる可能性もあるが、必要に応じてゲーム定義スクリプトの入れ替えを行なう図９の例に比べて、ゲーム種類に対する柔軟性は増す。ゲーム実行権の発行がすなわち新しいゲームの発行となるため、ゲームアプリケーション（２００）を入れ替えることなしに、常に新しいゲームを実行することができる。ただし、新しいゲームの種類を開発するたびに端末側のプログラムも変更する必要があるので、ゲーム実行用端末が分散している場合には端末用プログラムの更新の手間がかかる恐れもある。
【００７６】
次に、ゲーム処理実行部の処理の流れについて、図１１により説明する。ゲーム定義データ（２２６）には、パラメータ定義（３０１）、実行権定義（３０２）、スクリプト記述（３０３）が格納されている。これとは別にポイントデータ（３０８）が存在する。
【００７７】
ゲーム処理実行部には、ローカルな変数としてプログラムカウンタ（３０４）および実行用配列（３０５）を持ち、また端末から送られてきたコマンドのパラメータ（３０６）を参照／端末に返すレスポンスのパラメータ（３０７）を書き換えることができる。
【００７８】
端末からのコマンドが送られてくると、ゲーム処理実行部は、端末からのコマンドを受信、解析し（３１１）、指定されたゲーム種類に切り替える（すなわち、指定されたゲーム定義を呼び出す）（３１２）。このときコマンドに付随して送られてきたパラメータをコマンドパラメータ（３０６）に格納する。
【００７９】
プログラムカウンタ（３０４）の値を初期化して（３１３）ゲーム実行を開始する。スクリプト記述部（３０３）に記述されたスクリプトを順番に実行していくわけであるが、基本的にはプログラムカウンタ（３０４）の値をひとつずつ進めていきながら（３１４）、順番にスクリプトを解析し（３１５）、共通処理コンポーネントを呼び出すことでスクリプトを実行する。スクリプトが「コマンド待ち」であれば、いったん端末にレスポンスを返信し、次のコマンド受信を待つ（３１６）。スクリプトが「終了」であれば、レスポンスを返信し、スクリプト処理を終了する（３１７）。スクリプトがジャンプまたは分岐を指定するものであれば、プログラムカウンタをジャンプ先に変更し、次のスクリプト解析に進む（３１８）。それ以外のスクリプトの場合には、スクリプトに関連付けられた対応する共通処理コンポーネントを呼び出して、実際にスクリプトを実行し（３１９）、プログラムカウンタを進める処理（３１４）に戻る。スクリプト実行（３１９）では、コマンドパラメータ（３０６）の値を参照しながら、実行用配列（３０５）の値やレスポンスパラメータ（３０８）の値を更新していく。これを続けていくことで、ゲームの実行が行なわれる。
【００８０】
図１２には、共通コンポーネントを呼び出すためのスクリプト言語定義の例を示す。ここで、ａｒｒａｙ［ ］とは実行用配列（３０５）であり、ｃｍｄ［ ］はコマンドパラメータ（３０６）、ｒｓｐ［ ］はレスポンスパラメータ（３０７）をさす。それぞれのスクリプトは、ひとつの共通コンポーネントを呼び出し、実際にプログラムを実行する役割を果たす。ひとつのスクリプトについてパラメータは３つまで付随する。
【００８１】
この例では、わかりやすいように通常のプログラミング言語に近い言語体系でスクリプトを記述しているが、メモリ容量の少ないＩＣカードで実行することを考えると、ゲームに限定した場合にはもっと特殊な形のスクリプト言語体系（例えば少ない桁数のバイト列で表現するような）のほうが向いているかもしれない。また、スクリプトを発行する端末側に何らかのコンパイル手段を用意し、バイト列に表現し直したスクリプトを発行する方法もある。
【００８２】
以下、図１３から図１９までを用いて、３種類のゲームの実装例を挙げていくが、この中では、図１２で定義したスクリプトを用いてゲーム定義を表現する。
【００８３】
図１３は、ボックス数（＝乱数の数）が３で、ひとつのボックスで表現される数字（乱数）の範囲が０〜２までであるスロットマシンの、ゲーム実行端末におけるゲーム実行画面の例である。各ボックスの値について、「０」をりんご、「１」をみかん、「２」をバナナで表している。
【００８４】
（ａ）は、ゲームを開始した状態の画面である。現在のポイント数（４０１）および残り実行可能ゲーム数（４０２）が表示され、３つのボックス（４０５）はまだ値が確定しておらず、画面上では回転している様子が描かれている。ユーザが３つの「Ｐｕｓｈ」ボタン（４０６）をひとつずつ押すことで、カードに対して乱数発生のコマンドが送られて、ボックスに乱数の値に対応した絵が表示される。
【００８５】
（ｂ）は１回目の「Ｐｕｓｈ」選択後の画面例である。カードの中で発生した乱数が「０」だったので、対応するボックスにはりんごの絵が表示される。これを３回繰り返す。
【００８６】
（ｃ）は３回目の「Ｐｕｓｈ」が選択され、１回分のゲームを終了した状態（あたりの場合）の画面例である。３つのボックスの絵がすべて一致したため、ゲームにかけられた点数「１００」点がユーザのポイントに追加される。ゲームの結果が「あたり」で１００ポイントが追加されたことを示すメッセージ（４０３）が表示され、ポイントが追加されているのがわかる。
【００８７】
（ｄ）は３回目の「Ｐｕｓｈ」が選択され、１回分のゲームを終了した状態（はずれの場合）の画面例である。３つのボックスの絵が一致しなかった場合には、「はずれ」のメッセージ（４０４）が表示され、ポイントの追加はない。
【００８８】
図１４は、図１３に示したスロットマシンを、図１２のスクリプトで記述した例を示す。００行から１１行（バイナリ）まで、１８行のスクリプトで表現される。
【００８９】
００〜０２行：１回目の「Ｐｕｓｈ」が押されたときに呼ばれる。乱数をひとつ発生し、それを実行用配列に格納して、その乱数の値を返す。端末に操作を返させたい場合には、「Ｒｅｔｕｒｎ」スクリプトが定義される。
【００９０】
０３〜０５行：２回目の「Ｐｕｓｈ」が押されたときに呼ばれる。乱数をひとつ発生し、それを実行用配列に格納して、その乱数の値を返す。
【００９１】
０６〜０８行：３回目の「Ｐｕｓｈ」が押されたときに呼ばれる。乱数をひとつ発生し、それを実行用配列に格納する。レスポンスに「今回が最後」を表す値を入れ、結果判定に進む。
【００９２】
０９〜１１行：結果判定。格納した３つの乱数がすべて一致したら、所定の点数をポイントに追加する。最後に結果を返して終了である。
【００９３】
図１５は、当たる確率が３分の１で、勝負数が３回であるルーレットゲームの、ゲーム実行端末におけるゲーム実行画面の例である。３つの数字を、それぞれ「Ａ」「Ｂ」「Ｃ」と表す。図には表れないが、カラーで色分けされていると見やすい。
【００９４】
（ａ）は初期画面である。現在のポイント数（４０１）および残り実行可能ゲーム数（４０２）が表示されている。ゲームを始めるには、ルーレット（４０８）を回転させる前に、賭け場（４０７）から「Ａ」「Ｂ」「Ｃ」いずれかを選ぶ。
【００９５】
（ｂ）はゲーム開始後の画面である。ここでは賭け場（４０７）から「Ｂ」を選ぶと、「Ｂ」のところに黒い丸が置かれる。スコア（４１０）と残り勝負数（４１１）が表示される。このゲームでは勝負数は「３」なので、残り勝負数（４１１）は「３」と表示される。ここで「Ｓｔａｒｔ」ボタン（４０９）を押して回転を始めると、残り勝負数（４１１）が減少する。
【００９６】
（ｃ）はルーレット（４０８）が回転した状態（これは画面上での見え方で、カード側のプログラムでは待ち状態になっている）で、「Ｓｔｏｐ」ボタン（回転を止めるボタン）（４０６）を押すと、ＩＣカードに対してコマンドを発行する。
【００９７】
（ｄ）は１回分の勝負を終えた状態の画面である。カードで発生した乱数の値に応じて、賭けた数字と一致していれば「あたり」（４０３）としてスコアが追加される。
【００９８】
（ｅ）は１回分の勝負を終えてはずれた場合の画面である。「はずれ」（４０４）としてスコアは追加されない。
【００９９】
（ｆ）回転と乱数発生を３回繰り返すと、ゲームは終了である。「ＧＡＭＥ ＯＶＥＲ」とスコアの値が表示される（４１２）。
【０１００】
図１６は、図１５に示したルーレットを、図１２のスクリプトで記述した例を示す。００行から１ａ行（バイナリ）まで、２７行のスクリプトで表現される。
【０１０１】
００〜０５行：１回目の「Ｓｔｏｐ」が押されたときに呼ばれる。コマンドのパラメータとして送られたユーザ入力値を実行用配列と、乱数をひとつ発生させたものを比較し、比較結果を配列に格納する。比較結果とその乱数の値を端末に返す。
【０１０２】
０６〜０ｂ行：２回目の「Ｓｔｏｐ」が押されたときに呼ばれる。コマンドのパラメータとして送られたユーザ入力値を実行用配列と、乱数をひとつ発生させたものを比較し、比較結果を配列に格納する。比較結果とその乱数の値を端末に返す。
【０１０３】
０ｃ〜１０行：３回目の「Ｓｔｏｐ」が押されたときに呼ばれる。コマンドのパラメータとして送られたユーザ入力値を実行用配列と、乱数をひとつ発生させたものを比較し、比較結果を配列に格納する。
【０１０４】
０１〜１ａ行：結果判定。３回分の比較結果に応じて、点数をポイントに追加する。最後に結果を返して終了である。
【０１０５】
図１７は、ボックス数が５で、５回勝負のシューティングゲームの、ゲーム実行画面の画面例である。１秒毎にランダムに移動するターゲットを狙い、ユーザはボックスをクリックして、ターゲットが現れているボックスと一致するかどうかを競うゲームである。このクリックを５回繰り返す。
【０１０６】
（ａ）は初期画面である。現在のポイント数（４０１）および残り実行可能ゲーム数（４０２）が表示されている。「Ｓｔａｒｔ」ボタン（４０９）をクリックするとゲームを開始する。
【０１０７】
（ｂ）はユーザが画面をクリックする前の画面である。５つのボックス（４０５）に、ランダムにターゲットの絵（４１３）が現れる。これは１秒毎に発生する乱数の値に応じて変化する。画面中には、現在のゲームのスコア（４１０）および残り勝負数（４１１）が表示される。
【０１０８】
（ｃ）はユーザが画面をクリックしているところの画面である。この場合は、ユーザが選んだボックスとターゲットが現れているボックスとが一致しているので、「あたり」（４１４）としてスコアが１０点追加される。
【０１０９】
（ｄ）はユーザが画面をクリックしているところの画面である。ユーザが選んだボックスとターゲットが現れているボックスとが一致しない場合は「はずれ」（４１５）である。
【０１１０】
（ｅ）はゲーム終了画面である。５回の勝負が終了すると、「ＧＡＭＥ ＯＶＥＲ」とスコアの値が表示される（４１２）。残りゲーム数（４０２）がまだある場合には、新たな「Ｓｔａｒｔ」ボタン（４０９）が表示される。
【０１１１】
図１８は、図１７に示したシューティングゲームの処理手順を、端末（１２０）側とカード（１１０）側に分けて表した図である。他のＩＣカード上のプログラムと同じく、基本的に端末（１２０）からはコマンドとパラメータをカードに対して送り、カード（１１０）は受け取ったコマンドに応じて処理を実行してレスポンスを返す、という手順になる。現在のＭＵＬＴＯＳなどを搭載したＩＣカードには時計が内蔵されていない（端末からのコマンド受信をきっかけに動作する）ので、１秒毎にカードが乱数を発生して画面を更新するためには、端末側で１秒毎に乱数発生要求をカードに送ってやる必要がある。
【０１１２】
まず、端末（１２０）は乱数発生要求のコマンド（パラメータ＝０）を発行する（３２１）。
【０１１３】
カード（１１０）では、コマンドを受信（３２１）し、ボックス数の範囲で発生した乱数を変数Ｒに代入して（３３２）、パラメータ＝Ｒとしてレスポンスを送信する（３３３）。端末はこれを受けて、Ｒの値に応じて画面を再表示する（３２２）。１秒毎のタイマー（３２３）により、これ（３２１から３２２まで）を１秒間隔で繰り返す。
【０１１４】
ユーザから入力（クリック）があると、ユーザが選択したボックス番号を変数Ｄに代入し（３２４）、パラメータ＝Ｄとしてコマンドを発行する（３２１）。カードはコマンドを受信し（３３１）、パラメータがＤ（０以外）であれば、格納してあった直前の乱数Ｒと受け取ったボックス番号Ｄとを比較し（３２４）、あたりであればポイント数を追加し、比較結果を端末に返す（３３５）。端末は結果を受け取り、画面に結果を表示する（４１２）。これを勝負数（図１７の例では５回）だけ繰り返す。
【０１１５】
図１９は、図１７および図１８で説明したシューティングゲームを、図１２のスクリプトで記述した例を示す。コマンドのパラメータが「０」の場合は乱数を発生し、それ以外の場合は、ユーザ入力を前回の乱数の値と比較する。このスクリプト例では、前のふたつの例とは異なり、ループを実現している。
【０１１６】
００〜０２行：実行用配列の初期化
０３行：ループのトップ
０４行：コマンドパラメータの値に応じて分岐する
０５〜０ｄ行：コマンドパラメータに「０」以外が渡されたときは、ユーザの入力値と乱数の値を比較して、比較結果を格納する。ループカウンタをひとつ増やす。ループカウンタが最終回以外の場合は、比較結果を端末に返す。端末に処理を渡し、次に処理が戻ってきた場合には、ループの先頭（０３行）に戻る。
【０１１７】
０ｅ〜１１行：最終ループの場合。格納された比較結果に基づき、点数をポイントに追加する。
【０１１８】
１２〜１６行：コマンドはダミーの場合。乱数を発生し、その乱数を端末に返す。ループの先頭に戻る。
【０１１９】
これを繰り返すことにより、図１８の処理をスクリプトで実現できる。
【０１２０】
以上説明してきたように、図１２に示したスクリプトを用いることで、例に挙げた３種類のゲームのような、複数種類のゲームを定義することができる。この３種類はあくまでも一例であり、乱数発生およびユーザからの入力との比較との組み合わせにより、他にも何種類ものゲームを定義できる。これらスクリプト記述で定義されたゲームを、図１１に示すようなスクリプトインタープリタ（実行部）によって実行することで、ひとつのアプリケーションプログラムで複数種類のゲームを実行することが可能となる。
【０１２１】
以上、ＩＣカード上で複数種類のゲームを実行可能なアプリケーションプログラムおよびその運用について説明してきたが、この方法をゲーム以外のアプリケーションに応用することも可能である。例えば、次々と更新される画面上で回答していくことでポイントを獲得するアンケートシステムや、特定の広告を閲覧することでポイントを獲得する広告システムなど、ユーザの操作によりポイントなどの価値を生み出し、かつ同一のスクリプトを二度と実行しないように制御するアプリケーションとして、本発明を適用することが可能となる。ただし、その場合は、アンケートの回答履歴や広告の閲覧履歴をカード中に格納しておき、同一のアンケート・広告スクリプトを複数回ロードしないように制御する必要がある。また、ゲームの場合はスクリプト実行後は該当スクリプトを削除するか実行権を減算するだけで良いが、アンケ−トの場合は回答デ−タを店舗側に回収する必要が生じる。
【０１２２】
図２０は、本発明をアンケートシステムに応用した運用例である。基本的には図１０に示したゲームシステムの運用例と類似しているが、アンケート回答を回収する部分が少し異なる。
【０１２３】
ＩＣカード（１１０）にはアンケートアプリケーション（５００）がロードされており、このアンケートアプリケーション（５００）は、コマンド処理部（２１１）、スクリプトインタープリタ（２１５）、アンケートデータ格納処理部（５０３）、ポイントデータ処理部（２１４）などから構成されている。アンケートデータ（５０１）は、アンケートスクリプトと発行元および回答データとの組で格納されている。回答データはユーザがアンケートに回答するまでは中身は空になっており、ユーザがアンケートに回答すると回答データが格納される。この回答データは、アンケートが回答済みであるかどうかを表すフラグの役割も持っており、このデータが入っている場合には二度と同じアンケートを実行することができない。アンケートに対する回答履歴は回答履歴データ（５０２）として格納されており、回答済みのアンケートがロードされないように制御する。また、図９、図１０と同様、ポイントデータ（２２３）は、発行元の会社ごとに管理されたポイントの点数のデータとして格納されている。
【０１２４】
（Ｘ）社の店舗（１０４）において、店舗用端末（１０８）はＩＣカード（１１０）に対して、アンケート発行コマンド（５０６）および、アンケート定義スクリプトと発行元を含むアンケートデータ（５０７）を送信する。このデータは、ゲームのときと同様、正しく発行元から発行されたものであるということを保証するために、あらかじめ定義した方法により、発行元が正しいスクリプトであることを認証するような暗号キーをつけ、これによりアンケートデータ格納処理部（５０３）にて認証処理を行なう必要がある。アンケートデータ格納処理部（５０３）ではまた、送られてきたアンケートデータ（５０７）が回答済みかどうかを回答履歴データ（５０２）と照らし合わせてチェックし、回答済みのアンケートについてはアンケートデータ（５０１）に格納されないように制御を行なう役目も担っている。
【０１２５】
ユーザ（１１３）がユーザ端末（５０９）にてアンケートに回答する場合は、アンケート実行コマンド（５０５）がＩＣカード（１１０）に送信される。アンケートデータ（５０１）が存在すれば、アンケート定義スクリプトにより記述されたゲームを実行できる。アンケートは、単純に質問に答えるだけでなくて、ユーザが回答の詳細度を選択できるようにし、また前回の回答内容によって次回の質問内容が変化するように工夫されている。アンケートを回答したら、回答内容によって重み付けされた点数が、発行元のポイントデータ（２２３）に加算され、アンケートデータ（５０１）には回答データが付加される。回答データの付加されたアンケートデータ（５０１）は二度と回答することができない。つまり、回答済みのアンケートデータ（５０１）に回答データを付加することは、該当するアンケートデータを無効化することに相当する。
【０１２６】
店舗端末（１０８）にて、ポイント交換を行なう際、あるいは同じ発行元の次のアンケートを発行する際に、前回回答したアンケート回答データを回収しなければならない。回答済みのアンケートデータは、回答データが付加されて無効化された状態になっているので、回答データを回収しないでためていくとアンケートデータ（５０１）があふれる恐れがあるので、適当なタイミングで回答データの回収を行なう必要がある。回答データの回収が要求されると、アンケート回答回収処理部（５０４）では、回答データを暗号化して端末（１０８）に返却し、それとともに該当するアンケートデータ（５０１）を消去し、回答履歴データ（５０２）に履歴情報を追加する。
【０１２７】
このような方式により、本発明をゲームだけでなくアンケートシステムに展開することが可能となる。広告閲覧システムも類似の方法により応用可能である。
【０１２８】
以上述べてきたように、本発明の実施例による効果を、「課題を解決する手段」で挙げた６項目に沿って挙げると、
まず本発明の実施例により実現されるＩＣカードによれば、
（１）以下の要素からなるアプリケーションプログラム：
（ａ）ゲーム実行コンポーネント
（ｂ）ゲーム定義スクリプト格納部
（ｃ）スクリプトインタープリタ
（ｄ）ポイントデータ格納部・処理部
（ｅ）ゲーム実行権格納部・処理部
（ｆ）コマンド処理部
により、ＩＣカード上のひとつのアプリケーションプログラムによって、複数種類のゲームを実行することが可能となる。
【０１２９】
これに加えて、
（２）ゲーム定義スクリプト格納処理部
により、ゲームアプリケーションプログラムをＩＣカードにロードしてからでも、アプリケーションプログラムの入れ替えを必要とせずに、随時新しい種類のゲームを導入することができ、より柔軟なゲームシステムを提供することが可能となる。
【０１３０】
アプリケーションプログラムが規定するゲーム発行スキームに基づき格納を制御することにより、安全にアプリケーションプログラムの処理を切り替えることができるとともに、カードＯＳによって規定された面倒なアプリケーション発行スキームから開放される。
【０１３１】
また、同一の処理を行なうゲームアプリケーションプログラムを、“ＭＵＬＴＯＳ”や“Ｊａｖａ Ｃａｒｄ”といった異なるＯＳを搭載したＩＣカードにロードしておけば、新しいゲームを開発する際にはＯＳの違いにとらわれることなく同様のゲームを開発することが可能となる。
【０１３２】
（３）発行元別ポイント管理機能により、複数種類のゲームを複数の発行元で、ひとつのアプリケーションで管理することが可能となり、より広く利用されるゲームシステムを提供することが可能となる。
【０１３３】
次に、このＩＣカードを取り扱うための端末装置としては、
（４）ゲーム発行機能
（６）ポイント演算機能
により、ＩＣカードに対して、ゲームアプリケーションプログラムの入れ替えをすることなしに複数種類のゲームを発行することが可能となるとともに、ポイント管理まで含めた柔軟なゲームシステムを安全に運用することが可能となる。
【０１３４】
また、それぞれのゲームを実行するためのユーザインタフェースを備えた
（５）ゲーム実行機能
により、ユーザは楽しみながらゲームを実行することでポイントを獲得できる。
【０１３５】
従って、本発明の実施例によれば、より柔軟性の高いゲームアプリケーションをＩＣカードシステムに安全に導入することが可能となる。ゲームの結果をポイントと連動することにより、利用者のカード利用意欲が増し、アプリケーション提供者の顧客囲い込みに有効であるとともに、ＩＣカードシステムの普及に大きく役立つ。
【０１３６】
また、スクリプト定義とインタープリタの導入・アプリケーションプログラムが規定するゲーム発行スキームに基づきスクリプトの格納を制御する方法により、ゲームアプリケーションに限らず、プログラムの入れ替えなしにプログラムの処理内容を入れ替える方式は、プラットフォームから開放された、より柔軟で簡便なＩＣカードアプリケーションの開発を可能とする。
【０１３７】
【発明の効果】
本発明によれば、例えば、プログラムの入れ替えなしにゲームの入れ替えが可能である。
【図面の簡単な説明】
【図１】ＩＣカードを用いたゲーム付きポイントシステムのサービスイメージ図。
【図２】マルチアプリケーションＩＣカード上のプログラム実行における情報の流れを示す図。
【図３】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その１）。
【図４】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その２）。
【図５】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その３）。
【図６】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その４）。
【図７】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その５）。
【図８】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その６）。
【図９】ゲーム発行運用例を示す図（その１）。
【図１０】ゲーム発行運用例を示す図（その２）。
【図１１】スクリプトインタープリタ（実行部）の処理を示す図。
【図１２】共通コンポーネント呼出しスクリプト言語定義の例を示す図。
【図１３】スロットマシンの例の例を示す図。
【図１４】スロットマシンにおけるスクリプト記述例を示す図。
【図１５】ルーレットの例を示す図。
【図１６】ルーレットにおけるスクリプト記述例を示す図。
【図１７】シューティングゲームの例を示す図。
【図１８】シューティングゲームの処理手順の例を示す図。
【図１９】シューティングゲームにおけるスクリプト記述例を示す図。
【図２０】アンケートシステムの運用例を示す図。
【符号の説明】
１０１：サービスプロバイダ側
１０２：アプリケーション提供者
１０３：サービス管理者
１０４：店舗（ゲーム供給者）
１０５：アプリケーションロード用端末
１０６：ゲーム管理用データ
１０７：ゲーム管理用サーバ
１０８：店舗用端末
１０９：ユーザ側
１１０：ＩＣカード
１１１：ユーザ用ゲーム実行端末
１１２：店舗内ゲーム実行端末
１１３：ユーザ
１１４：ゲームデータ発行用端末
１２０：端末
１３１：ゲーム実行コマンド
１３２：ゲーム入れ替えコマンド
１３３：実行権発行コマンド
１３４：ポイント演算コマンド
１３５：ゲーム発行コマンド
１４１：発行するゲーム定義データ
１４２：発行する実行権データ
１４３：発行するゲームデータ
１５１〜１５８：データの流れ
１６１：ＩＣカード用Ｒ／Ｗ
１６２：端末プログラム
１６３：端末ＯＳ
１６４：（端末の）入出力インタフェース
２００：ゲームアプリケーションプログラム
２０１：カードＯＳ
２０２：入出力インタフェース
２０３：アプリケーションプログラム
２０４：アプリケーションデータ
２０５：実行処理部
２１１：コマンド処理部
２１２：結果判定アルゴリズム
２１３：実行権処理部
２１４：ポイントデータ処理部
２１５：スクリプトインタープリタ（実行部）
２１６：ゲーム定義スクリプト入れ替え処理部
２１７：ゲームデータ格納処理部
２２１：ゲームパラメータ
２２２：ゲーム実行権データ
２２３：ポイントデータ
２２４：共通処理コンポーネント
２２５：コンポーネント呼出し定義
２２６：ゲーム定義スクリプト
２２７：ゲームデータ（スクリプト＋発行元）
３００：ゲーム定義データ
３０１：パラメータ定義
３０２：実行権定義
３０３：スクリプト記述
３０４：プログラムカウンタ
３０５：実行用配列
３０６：コマンドパラメータ
３０７：レスポンスパラメータ
３０８：ポイントデータ
３１１〜３１９：ゲーム処理実行部の処理ステップ
３２１：コマンド発行処理
３２２：再表示処理
３２３：タイマー
３２４：入力データの代入処理
３３１：コマンド受信処理
３３２：乱数発生と代入処理
３３３：レスポンス送信処理
３３４：データの比較処理
３３５：結果の返却処理
４０１：ポイント数
４０２：残りゲーム数
４０３：あたりのメッセージ
４０４：はずれのメッセージ
４０５：ボックス
４０６：回転を止めるためのボタン
４０７：賭け場
４０８：回転ルーレット
４０９：スタートボタン
４１０：スコア
４１１：残り勝負
４１２：ゲーム結果
４１３：ターゲット
４１４：あたった場合
４１５：はずれた場合
５００：アンケートアプリケーション
５０１：アンケートデータ
５０２：回答履歴データ
５０３：アンケートデータ格納処理部
５０４：アンケート回答回収処理部
５０５：アンケート実行コマンド
５０６：アンケート発行コマンド
５０７：発行するアンケートデータ
５０８：回収する回答データ
５０９：ユーザ端末。
【発明の属する技術分野】
本発明は、アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体に関し、特に、高いセキュリティを持つコンピュータシステム、特に、不揮発性メモリにアプリケーションプログラムを格納し、カード内部でアプリケーションプログラムを実行することが可能なＩＣカードを核としたコンピュータシステムに関するものである。
【０００２】
【従来の技術】
ＩＣチップにＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を内蔵し、カード内部での演算を行なうことができるＩＣカード（あるいはスマートカードと称する）は、高度な情報記憶能力を持ち、高いセキュリティを実現できることから、さまざまな分野での利用が期待され、特に電子マネーなど金融分野において、近年積極的に導入が進められている。
【０００３】
最近では、１枚のカード上に安全に複数のアプリケーションを共存できるようなカードＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が一般化してきた。これらマルチアプリケーション対応カードＯＳとしては、Ｍｏｎｄｅｘ Ｉｎｔｅｒｎａｔｉｏｎａｌ社による“ＭＵＬＴＯＳ”や、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社による“Ｊａｖａ Ｃａｒｄ”（Ｊａｖａは登録商標である）などが知られている。こうしたＯＳによって管理されるマルチアプリケーション対応ＩＣカードでは、アプリケーションプログラム間の独立性が高くなるように制御されており、安全に複数のアプリケーションを共存させられるだけでなく、発行後のカードに新たにアプリケーションプログラムを追加したり、不要なアプリケーションプログラムを削除したりすることも可能となっており、単なる情報格納媒体としてではなく、安全なコンピュータとしてみなすことができる。カードの持つ高いセキュリティを活かし、あるいは従来の磁気カード機能の置き換えという観点から、クレジットカードや電子マネーなどの金融分野での応用、特に複数アプリケーションの連携などが期待されている。
【０００４】
従来から、顧客囲い込みの一手段として、ポイントシステムあるいはロイヤリティプログラム（以下、ポイントシステムと称する）といったシステムが一般化している。これは、「カードの利用に応じてポイントが加算されその点数の蓄積により所定のサービスが受けられるシステム」と定義され、ポイント獲得による特典への期待から、店舗やカードの利用を促すといった効果を狙っている。システムの例として商店街のスタンプカードやデパートなどのポイントシステム、あるいは航空会社のマイレージプログラムのようなものがある。一例としてデパートのポイントシステムを例に挙げると、会員はカードを所持し、該当デパートで買い物をする際にカードを提示すると、購入履歴とともに売り上げに応じてポイントが蓄積され（例えば１０００円の買い物ごとに２０ポイント付加）、ポイントがある一定たまると、そのデパートで利用できる商品券と引き換えることができる（例えば１０００ポイントで１０００円の商品券と交換。つまり、５万円の買い物につき会員は１０００円分の割引が受けられる計算となる）。キャンペーン期間中はポイント付加の割合が倍になったり、１年間の購入額がある一定の金額以上に達すると割引率が高くなったりすることで、消費者の購買意欲を煽るものである。別の例として、航空会社のマイレージプログラムでは、購入額ではなく飛行距離を積算し、ある一定の飛行距離に達すると無料航空券やシートのアップグレードサービスが受けられるというようなシステムもある。この場合も、会員の利用履歴に応じてサービスを与えることにより、会員が同じ航空会社を選択する動機づけを与えるものである。こういったポイントシステムをＩＣカード化することにより、カード利用者のポイントがカード上で正しく管理することが可能となる。マルチアプリケーション対応ＩＣカードにおいては、電子マネーやクレジットカード機能などと組み合わせることで、複数アプリケーションを効果的に連携することも可能となる。
【０００５】
以上述べたようなマルチアプリケーション対応ＩＣカードの特性を活かしたカード上のアプリケーションのひとつとして、ポイントシステムにゲーム機能を付加し、カードに格納されたゲームを実行した結果に応じてポイントの値を連動させる「ゲーム付きポイントシステム搭載ＩＣカードシステム」が提案されてきた。これは、特願平１０−２３９８１２号および特願平１０−３２１６８４号にて出願済みである。これらの発明の中では、ユーザがゲームを実行することのできる回数を「ゲーム実行権」と定義し、このゲーム実行権とゲーム実行の結果であるポイントの値を管理することで、ＩＣカードプログラム中で安全にゲームを実行可能な方法について提案した。
【０００６】
また、これとは別に、ＩＣカード上でポイントシステムの管理を行う方法として、ポイント管理プログラムの中に複数の固有プログラムを有するシステムも提案されている。このシステムは特願平１０−３０７２１６号にて出願されており、この方法によれば、販売店ごとに固有プログラムをポイント管理プログラムの中に埋め込むことにより、ひとつのポイントアプリケーションプログラムで、複数の販売店向けのポイントを管理することが可能となる。
【０００７】
【発明が解決しようとする課題】
“ＭＵＬＴＯＳ”をはじめとするマルチアプリケーション対応ＯＳは、セキュリティの観点から、各々が所定のロード機構を持っている。ロード機構では、アプリケーションをダウンロードする場合に、ダウンロードしたアプリケーションプログラムが改竄されていないか、正当な開発者が開発したものか、カードにそのアプリケーションプログラムをダウンロードする権利があるかといった項目のチェックを行なう。例えば、改竄の有無は、アプリケーションプログラムのハッシュ値を認証局（ＣＡ）の秘密鍵で署名したデータをアプリケーションプログラムに付随させ、カードで再計算したハッシュ値と比較一致するかで検証を行なうことができる。これらのチェックはＩＣカードの安全性を左右するため、各カードごとに厳格な手順が規定されており、また転送されるアプリケーションプログラムも所定のデータ形式を持っていないとダウンロードできない仕組みになっている。この規定をアプリケーション発行スキームと呼ぶ。
【０００８】
このため、マルチアプリケーション対応ＯＳを搭載したＩＣカードにアプリケーションプログラムをロードするためには、上記のアプリケーション発行スキームに従い、所定のアプリケーション認定および登録の手続きを行なわなければならない。そのため、原理的には発行後のカード上でアプリケーションプログラムの入れ替えが可能であるとはいえ、実際にアプリケーションプログラムの入れ替えを行なうためには、かなりの手間と時間が必要になることになる。これはＩＣカードの安全性を保つためであり、通常の金融系アプリケーションであれば、それほど頻繁にプログラムの内容が変更されることもないために大きな問題とはならない。
【０００９】
しかし、ゲームアプリケーションの場合には、ゲームの種類にバリエーションがないとユーザが飽きてしまう可能性が大きく、ゲームの内容をこまめに変更したいという要望が大きい。ゲームの種類をこまめに入れ替えたいという要望に対して、毎回アプリケーション認定・登録の手続きを行っていたのでは、手続きが煩雑でありゲームアプリケーションの特長を活かしきることができない。
【００１０】
また、異なる種類のゲームごとに別々のアプリケーションプログラムを開発・配布していたのでは、古い種類のゲームで得たポイントを新しい種類のゲームに移行する際の手続きが必要となり、このためのポイント管理が煩雑となるという問題点がある。
【００１１】
開発の面でも、類似した機能を持つアプリケーションを毎回別々に開発していたのでは、処理に無駄が多くなるし、たくさんの種類のゲームアプリケーションの開発・配布の間で、発行管理やカードへのロード時の配布管理が必要となる。
【００１２】
さらに、“ＭＵＬＴＯＳ”や“Ｊａｖａ Ｃａｒｄ”といったいくつかの異なるＩＣカード用ＯＳが混在する現状においては、ＩＣカード上のゲームアプリケーションプログラムを、ゲームの種類を変えるたびに複数のプラットフォーム上に別々に構築する必要があり、開発工数が大きくなるという問題点がある。
【００１３】
なお、これらの問題はゲームアプリケーションに限った問題ではなく、処理内容を頻繁に変更したいＩＣカード上のアプリケーションにおいては、同様の問題が生じることが予想される。
【００１４】
本発明の目的は、ＩＣカード上で実行するゲームアプリケーションにおいて、ゲームのバリエーションを増やした場合であっても、煩雑なアプリケーションプログラム入れ替え処理が不要となり、これにより手軽に複数種類のゲームをカードの上で扱うことのできるとともに、ＯＳの違いに依存せずに新しいゲームを開発可能とするような、ゲームアプリケーションプログラムを提供することにある。
【００１５】
またこれをゲームアプリケーションだけでなく、一般のアプリケーションにも拡張するならば、本発明の別の目的は、ＩＣカードのアプリケーションにおいて、処理のバリエーションを増やした場合にも煩雑なアプリケーションプログラム入れ替え処理が不要となり、これにより手軽に複数種類の処理を扱うことのできるともに、ＯＳの違いに依存せずに新しいゲームを開発可能とするような、ＩＣカード上のアプリケーションプログラムを提供することにある。
【００１６】
【課題を解決するための手段】
以上の目的を達成するために、ＩＣカード上の単一のアプリケーションプログラムで複数種類のゲームを扱うための手段を提案する。
【００１７】
まず考えられる方針は、ゲーム実行の結果であるポイントデータおよびゲーム実行権を取り扱うための部分（データ格納部および処理部）を複数ゲーム間で共有することである。ゲームプログラムの処理において、ポイントデータおよびゲーム実行権の管理部分を共通化してしまえば、ゲームによって異なるのは、実際にゲーム結果を判定するアルゴリズムだけと考えて良い。
【００１８】
しかし、それほど複雑な計算を行なえるとは言い難いＩＣカード上で主に実行されるゲームの種類を吟味すると、ゲーム実行部分は、「端末経由でユーザから送られるデータを受信」「乱数の発生」」「簡単な加減算」「データの格納」「データの比較と分岐」程度の処理とその組み合わせを繰り返すものであることがわかる。これらの処理を行なう部分を「コンポーネント」として部品化すると、それぞれのゲームの定義は、これらのコンポーネントの呼出し順序を定義する「スクリプト」のようなもので表現することができる。 つまり、ＩＣカードのひとつのアプリケーションプログラム中に、ゲームを実行するための処理を行なう処理部品「コンポーネント」と、スクリプトを解釈・実行する「インタープリタ」を用意すれば、プログラム外部で生成されたゲーム定義用の「スクリプト」を実行することで異なるゲームの処理を行なうことができる。
【００１９】
また、このスクリプトを必要に応じて端末を通じてアプリケーションプログラム外部から入れ替えられるようにすれば、ＩＣカード上の単一のゲームアプリケーションプログラムによって、異なる複数種類のゲームを実行することが可能となる。
【００２０】
しかし、スクリプトの入れ替え・追加を可能とした場合に、ここでどんなスクリプトでもアプリケーションプログラム内部に格納してしまったとしたら、悪意のあるスクリプトによりゲーム結果のポイントが不正な値にされてしまう可能性もあり、せっかくのＩＣカードＯＳの持つセキュリティが活かされないことになる。そこで、ＯＳの定義したアプリケーションプログラム発行スキームの代わりに、アプリケーション内部で擬似的な発行スキームを規定することで、不正なスクリプトが格納されないように制御しなければならない。具体的には、スクリプトの入れ替えを制御する制御部を用意し、不正なスクリプトが格納されないようにする必要がある。
【００２１】
つまり、ＯＳの持つアプリケーションプログラム発行スキームの代わりに、アプリケーションプログラムが擬似的なゲーム発行スキームを用意し、安全性を確保するとともに、アプリケーションプログラム内部でスクリプトの解釈・実行を行なう処理部を用意することで、限られた機能ではあるが異なる種類のゲームを単一のプログラムで実行することを可能とするものである。
【００２２】
また、ゲームの結果に応じて値が変化し、後で所定のサービス（物品との交換など）が受けられるポイントデータについては、複数のゲーム間で共通に処理できることはもちろんであるが、カード内部に格納するゲーム定義スクリプトにゲーム発行元の情報を付け加えておくことにより、ポイントも発行元ごとに管理することが可能となる。
【００２３】
従って、本発明が課題を解決する手段としては、以下の６つの項目が挙げられる。
【００２４】
まずＩＣカード側の手段としては、
（１）以下の要素からなるアプリケーションプログラム：
（ａ）ゲーム実行コンポーネント：ゲームを実行するために必要な、カードプログラム中の処理を集めた部品
（ｂ）ゲーム定義スクリプト格納部：コンポーネントの実行順序を定めたスクリプトを格納するエリア
（ｃ）スクリプトインタープリタ：ゲーム定義スクリプトを解釈・実行するインタープリタ
（ｄ）ポイントデータ格納部・処理部：ゲームの結果として変化するポイントの値を格納するエリアおよび、ポイントデータを管理する処理部
（ｅ）ゲーム実行権格納部・処理部：ゲームを実行する権利に関する値を格納するエリアおよび、ゲーム実行権を管理する処理部
（ｆ）コマンド処理部：端末からのコマンドを処理し、プログラム内部での各処理を呼び出す処理部
以上が必須であり、これに加えて必要に応じて、
（２）ゲーム定義スクリプト格納処理部：ゲーム定義スクリプトの格納および入れ替えを管理する機能を持つ。アプリケーションプログラムが規定するゲーム発行スキームに基づき処理する。
【００２５】
（３）発行元別ポイント管理機能：発行元別にポイントおよびゲーム実行権を管理する機能を持つ。
【００２６】
が用意される。
【００２７】
次に、このＩＣカードを取り扱うための端末装置としては、
（４）ゲーム発行機能：所定のプロトコルによってＩＣカードとデータ通信を行ない、ゲーム定義スクリプトデータあるいは／およびゲーム実行権データをＩＣカードに対して発行する機能を持つ。ゲーム定義スクリプトとゲーム実行権は、別々に管理される場合も、同一のものとして管理される場合もあり得る。
【００２８】
（５）ゲーム実行機能：所定のプロトコルによってＩＣカードとデータ通信を行ない、ゲームを実行するためのコマンドによってゲームを実行する。ユーザがゲームを実行できるようなユーザインタフェースも必要である。
【００２９】
（６）ポイント演算機能：所定のプロトコルによってＩＣカードとデータ通信を行ない、カードに格納されたポイントデータに対する値の取得および新しい値の設定（主に減算）を行なう。ポイントデータが発行元別に管理されている場合には、発行元別の識別子を付けてポイント演算を行なう。
【００３０】
が必要となる。（４）から（６）までの各機能は、すべて同一の端末にあっても良いし、別々の端末に機能を分担して持たせても良い。
【００３１】
【発明の実施の形態】
図１に、ＩＣカードを用いたゲーム付きポイントシステムのサービスイメージ図を示す。システムは大きく分けて、サービスを提供するサービスプロバイダ側（１０１）とサービスを受けるユーザ側（１０９）に分けられる。サービスプロバイダ側（１０１）は、ゲームアプリケーションをＩＣカードおよび端末に供給するアプリケーション提供者（１０２）、ゲームの運営を管理するサービス管理者（１０３）、各ユーザへのゲームの供給やポイント交換などを行う店舗（１０４）から構成される。ここで、アプリケーション提供者（１０２）とサービス管理者（１０３）は双方の役割を兼ねることもあるし、分担する場合もある。店舗（１０４）は通常の場合、別々の地点に複数存在するが、１箇所だけでアプリケーション提供者（１０２）やサービス管理者（１０３）と同一となる場合もある。ユーザ側（１０９）は、ひとり以上のユーザ（１１３）から構成され、それぞれのユーザ（１１３）はＩＣカード（１１０）を１枚以上所有している。ユーザ（１１３）は、カード内部でゲームを実行するための入出力機能を持った、ユーザ用ゲーム実行端末（１１１）を保有している場合もある（必須ではない）。この、ユーザ用ゲーム実行端末（１１１）は、機能をゲーム実行だけに限定する必要はなく、ＩＣカード（１１０）への入出力機能を備えておりゲーム実行を補助するものであれば、ＩＣカード用リーダライタ（Ｒｅａｄｅｒ／Ｗｒｉｔｅｒ：ＩＣカードに対するアクセスを行う装置）を備えた通常のＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ：パーソナルコンピュータ）であっても、カード内の残高照会などを行う機能を持つＩＣカード取扱専用携帯端末であってもよい。
【００３２】
アプリケーション提供者（１０２）は最初に、各ユーザ（１１３）のＩＣカード（１１０）に対してゲームアプリケーションのロードを行う。ＩＣカード（１１０）がユーザ（１１３）に対して発行された時点で、ゲームアプリケーションがカード内にロードされている場合もあるが、カード発行後にもゲームアプリケーションを自由にカードにロードすることができることが、マルチアプリケーション対応ＯＳ搭載ＩＣカードの特長である。アプリケーションロードに関わる情報は、以下に述べるゲーム管理データ（１０６）に反映される場合もある。
【００３３】
サービス管理者（１０３）は、本ゲーム付きポイントシステムに関する各種情報を集めたゲーム管理用データ（１０６）から必要なデータを受け、ゲーム管理用サーバ（１０７）にてゲーム用の各種パラメータを各店舗（１０４）の店舗用端末（１０８）に対して配信する。
【００３４】
店舗（１０４）では、ユーザ（１１３）の店舗利用（買い物など）に応じて、ＩＣカード（１１０）に対してゲームの実行権あるいはゲームパターンを発行する。ここで、ゲームの実行権とはユーザがゲームを実行する権利であり、ゲーム実行後には消滅する。ゲームパターンは、ＩＣカード内で実行するゲームの各種パラメータのことであり、ゲーム実行権を含む。
【００３５】
ユーザ（１１３）は、ＩＣカード（１１０）にゲーム実行権が与えられた状態で、ユーザ用ゲーム実行端末（１１１）あるいは店舗（１０４）に備え付けられた店舗内ゲーム実行端末（１１２）（店舗側が管理する端末。ユーザ用ゲーム実行端末と同様、ゲーム実行機能だけに限定する必要はなく、ＩＣカードとのインタフェースとゲーム実行機能があれば形状は問わない）を通じて、カード内部のゲームの実行を行う。ゲーム実行の結果に応じて、ＩＣカード（１１０）内のポイントの値が更新される。
【００３６】
このポイントを店舗（１０４）にて商品や賞金と交換する。ゲームの発行状況やユーザの実行履歴、ポイントの交換履歴などのデータは随時ゲーム管理用データ（１０６）に蓄積され、次回のゲームパラメータ生成やゲーム発行にフィードバックされる。このように、ゲームの最新のデータを用いて、サービス管理者がゲームのパラメータを動的に制御することにより、サービスプロバイダ側（１０１）ではシステム全体の状況を管理することが可能となる。
【００３７】
次に、図２を用いて、マルチアプリケーションＩＣカード上のプログラム実行における情報の流れについて簡単に説明する。ＩＣカード（１１０）は、カードＯＳ（２０１）と入出力インタフェース（２０２）を備え、ひとつ以上のアプリケーションプログラム（２０３）が、所定の手順によりロードされている。図中で、アプリケーションプログラム（２０３）とアプリケーションプログラム（２０３’）とは別の独立したプログラムであり、双方が他方のデータに不正にアクセスすることは禁止されている。端末（１２０）には、ＩＣカード用リーダライタ（１６１）および入出力インタフェース（１６４）と端末ＯＳ（１６３）とを備え、ＩＣカード中のアプリケーションプログラムを扱うための端末プログラム（１６２）が、ひとつ以上ロードされている。通常、ＩＣカードのアプリケーションプログラムひとつに対してひとつ以上の端末プログラムが必要である。
【００３８】
ユーザ（あるいは店員など）が、端末（１２０）に対してユーザインタフェースを通じて入力を行なう（１５１）と、端末プログラム（１６２）では、ＩＣカードに送信するためのコマンドを生成する（１５２）。端末プログラム（１６２）は、リーダライタ（１６１）を通じて、このコマンドをＩＣカード（１１０）に送信する（１５３）。ＩＣカード（１１０）はコマンドを受け取ると、カードＯＳ（２０１）がコマンド送信先のアプリケーションプログラム（２０３）を判定し、端末プログラム（１６２）が意図したアプリケーションプログラム（２０３）に対してコマンドを送信する（１５４）。アプリケーションプログラム（２０３）中の実行処理部（２０５）では、このコマンドに従い処理を行ない、アプリケーションデータ（２０４）に対してアクセスし、値の更新などを行ない（１５５）、レスポンスを生成する（１５６）。レスポンスは端末（１２０）に返され（１５７）、端末プログラム（１６２）ではこの結果を提示する（１５８）。これが一連のプログラム実行の流れである。
【００３９】
アプリケーションプログラム（２０３）が複数ロードされている場合でも、端末プログラム（１６２）でコマンドを発行する相手のアプリケーションプログラム（２０３）を切り替えることにより、端末（１２０）を介してＩＣカード（１１０）上のプログラム実行が可能となる。基本的に、ＩＣカード上のアプリケーションプログラム（２０３）はお互いのデータに不正に影響を及ぼさないように制御されているが、例えば“ＭＵＬＴＯＳ”の場合では、デリゲーション（ｄｅｌｅｇａｔｉｏｎ：委任・委譲などの意味を持つ）と呼ばれる所定の方法により、複数のアプリケーションプログラムが連携し合って動作することが可能である。（最新の“ＭＵＬＴＯＳ”にはこの機能が備えられている。デリゲーション機能の詳細は省略する）
次に、図３から図８までを用いて、本発明の実施例により実現されるゲーム付きポイントシステムにおける、具体的なＩＣカードの構成を説明する。ここでは、ゲームの種類を２種類に増やした場合を例にとり説明する。ここで、ゲームの「種類」とは、ゲーム実行の結果をポイントにどのように反映するかを定義するアルゴリズムが異なるもののバリエーションであり、ここで言うアルゴリズムは、基本的にはＩＣカード内のデータの演算と乱数発生などの組み合わせにより定義されるものである、とする。
【００４０】
図３は、ゲームの種類を２種類に増やした場合の、既出願発明（特願平１０−２３９８１２号および特願平１０−３２１６８４号）によるゲームアプリケーションで実現可能なＩＣカードの構成である。ＩＣカード（１１０）は、“ＭＵＬＴＯＳ”や“Ｊａｖａ Ｃａｒｄ”などのマルチアプリケーション対応のカードＯＳ（２０１）のもと動作し、端末（１２０）とのデータのやりとりを行う入出力インタフェース（２０２）を備えている。既出願発明のアプリケーションの構成では、ひとつのアプリケーションに対して結果判定アルゴリズムはひと通りであり、ゲームの種類だけゲームアプリケーションプログラム（２００）が必要になる。ここでひとつめのゲームを（Ａ）、ふたつめのゲームを（Ｂ）とする。
【００４１】
ゲームアプリケーションプログラム（Ａ）（２００）は、ゲームパラメータ（２２１）、ゲーム実行権（２２２）、ポイントデータ（２２３）のそれぞれのデータを格納する部分と、コマンド処理部（２１１）、結果判定アルゴリズム（２１２）、実行権処理部（２１３）、ポイントデータ処理部（２１４）といった実際に処理を実行する部分とから構成される。図中（２１１）、（２１２）、（２１３）、（２１４）の網掛けで表した部分は、それぞれ処理を実行する部分であって、いったんプログラムがカードにロードされたらプログラム中で固定であることを示す。（２２１）、（２２２）、（２２３）のデータ格納部では、格納されたデータの内容はプログラム実行に伴い変化する。端末（１２０）からのコマンドは、大きく分けて店舗からのゲーム発行に関わるコマンドと、ユーザからのゲーム実行に関わるコマンドとがあり、コマンド処理部（２１１）ではコマンドの種類に対してそれぞれの処理実行部に処理を振り分け、これによりポイントデータやゲーム実行権データの増減などを行なう。ユーザからのゲーム実行のコマンドに対しては、ユーザ入力に応じて、結果判定アルゴリズム（２１２）とゲームパラメータ（２２１）の値に基づいてゲーム実行を行ない、この結果に応じてポイントデータ（２２３）の値を変更すると同時に、ゲーム実行権（２２２）を減少させて、店舗から与えられた実行可能回数を超えてゲームの実行を行なわせないように制御する。
【００４２】
ゲームアプリケーションプログラム（Ｂ）（２００’）に対しても（Ａ）と同様の構成となっており、それぞれ独立した処理系としてプログラムが実装される。端末（１２０）からのコマンドはアプリケーション選択後に送られてくるので、それぞれのゲームアプリケーションプログラム（２００）、（２００’）に対しては独立に設定されたコマンド発行により、アプリケーションプログラムが動作する。当然、ゲーム実行の結果生じるポイントデータ（２２３）、（２２３’）についても別々に格納されており、ポイント交換などの際にまとめて処理を行うことは原則としてはできない。ゲーム（Ａ）とゲーム（Ｂ）において決定的に異なるのは、結果判定のアルゴリズム（２１２）（２１２’）であり、それ以外のゲーム実行権やポイントを処理する部分では類似した機能から構成されているのにも関わらず、別々のプログラムとして処理を行うのは、リソースの限られたＩＣカードでは無駄も大きいという問題がある。
【００４３】
また、“ＭＵＬＴＯＳ”においては、基本的にゲームアプリケーション（Ａ）のプログラム（２００）とゲームアプリケーション（Ｂ）のプログラム（２００’）は別のアプリケーションなので、アプリケーションを搭載する際には、それぞれについてＯＳの定めた発行スキームによりアプリケーションの登録・認定の処理が必要となる。カード発行後に動的にアプリケーションの搭載・削除ができることがマルチアプリケーションＩＣカードの大きな特長であるとはいえ、ゲームのように内容をこまめに変更したいアプリケーションにおいて、別のアルゴリズムで動作するゲームを開発するたびにアプリケーションの登録・認定処理を行うのは煩雑であり、負担が大きい。また、ゲームを（Ａ）から（Ｂ）に入れ替えた場合、ゲーム（Ａ）実行の結果蓄積されたポイントは、ゲームの種類が変わっても継続して使えるようにしたいというのがユーザの自然な要求であるが、図３の構成では、異なるゲーム間のポイントの移行、およびそれに伴うポイント情報の管理は簡単ではない。
【００４４】
複数のゲーム間でのポイントの共有に関する問題の解決方法のひとつとして考えられるのは、ポイント管理のアプリケーションをゲームアプリケーションとは別アプリケーションとすることである。この方法は、上記の既出願発明によっても実現可能な手段である。ゲームアプリケーションとは別にポイントアプリケーションプログラムを用意し、この中でポイントデータの管理を行なうものである。ポイントの値の変更処理は、ゲームアプリケーションからの依頼に応じて、カードＯＳ（２０１）の持つデリゲーション処理を用いて行なう。ただし、この方法を用いてポイント一括管理の問題は解決しても、新しいゲームを追加する場合にアプリケーションの登録・認定処理を行う必要があることには変わりがなく、根本的な解決にはならない。
【００４５】
そこで、単一のアプリケーション上で複数種類のゲームを扱う方法を考える。
【００４６】
図４は、まとめて管理したいポイントデータとコマンド処理を共通部分とし、ゲームのパラメータや結果判定アルゴリズムなど固有の処理を行う部分は、ゲームの種類だけ用意する方式をとった場合の、ＩＣカードの構成を示す。ＩＣカード（１１０）には、ゲームアプリケーションプログラム（２００）を搭載するが、この中ではゲーム（Ａ）とゲーム（Ｂ）の２種類のゲームを扱うことができる。もちろん、別の種類のゲーム（Ｃ）を載せることもできるが、この図の例では２種類のゲームを搭載しているものとして説明を続ける。なお、アプリケーションを発行した時点で扱えるゲームの種類は決まっており、ゲームの新規追加は行えない。
【００４７】
ゲームの実行の結果として得られるポイントデータ（２２３）は、複数種類のゲームで共通して扱えるようにする。また、端末からのコマンドを受け取り処理を分岐するコマンド処理部（２１１）も、ゲーム処理とは分けて複数ゲームで共有できるようにする。ゲームパラメータ（２２１）、ゲーム実行権（２２２）、結果判定アルゴリズム（２１２）をゲームによって異なる部分として、ゲームの種類分だけ持たせ、実行権処理部（２１３）およびポイントデータ処理部（２１４）は共通処理部として用意する。
【００４８】
端末（１２０）から送られるコマンドの体系は、ゲームの種類によって識別できるようにしておき、コマンド処理部（２１１）は送られてきたコマンドを解析し、どの種類のゲーム宛のコマンドなのかを判別して処理を切り替える。ゲーム（Ａ）へのコマンドであれば、ゲーム（Ａ）の結果判定アルゴリズム（２１２）に従い処理を行い、その結果に応じてポイントデータ（２２３）を更新する。ゲーム（Ａ）によっても、ゲーム（Ｂ）によっても同様に、ポイントデータ（２２１）の値が更新される。
【００４９】
図４の方法から一歩進めたのが、図５によって示される方法である。ＩＣカード上のゲームは基本的に、ユーザからの入力された値を処理することと、入力タイミングに応じてカードの中で乱数を発生すること、ローカルな変数およびパラメータとして与えられる定数を組み合わせて結果を判定することの繰り返しで表現されるものがほとんどであり、結果判定アルゴリズムが異なっていても、その他の部分で共通化できる部分が大きい。そこで、乱数発生や加減算、繰り返しなど複数ゲーム間で共通化できるものを共通処理コンポーネントとして部品化する。共通処理コンポーネント（２２４）には、似た処理を行う部品をコンポーネントとして用意しておく。
【００５０】
ゲーム（Ａ）については、ゲームパラメータ（２２１）およびゲーム実行権データ（２２２）の格納部を持ち、ゲーム（Ａ）の実行部（２１５）には、コンポーネントの呼出定義（２２５）により、共通処理コンポーネント（２２４）をどのような順序で呼び出してゲームの正解判定を行なうのかという処理手順が定義されている。プログラムの実行については図４の方法とほぼ同じであり、コマンドの種類によってコマンド処理部（２１１）にてゲームの切り替えを行なうことで、あらかじめプログラムに組み込まれている範囲においては、複数のゲームを扱うことができる。図５例では、図４の例に比べて、共通化できる部分を極力コンポーネント化することにより、アプリケーションの効率化が図られている。
【００５１】
図４の方法でも、図５の方法でも、アプリケーション開発時にあらかじめ組み込んでおいたゲームについては複数種類を扱うことができ、端末からのコマンドに応じていくつものゲームを切り替えて実行することができるが、アプリケーション開発・発行後に別の種類のゲームを組み込むことはできない。後から別の種類のゲームを実行できるようにするためには、また新たなアプリケーションを開発し、登録・認定処理を行い、アプリケーションの入れ替えを行う必要がある。
【００５２】
そこで、以下図６および図７では、アプリケーションの登録・認定処理やアプリケーションの入れ替えを行う必要なしに、ゲームの種類を入れ替えたり追加したりできる方法を提案する。
【００５３】
具体的には、図５の方法で用いた、コンポーネント呼出定義（２２５）を一歩進めてスクリプト定義とし、実行部にはゲーム定義スクリプトを解釈・実行するインタープリタを用意する。そして、入れ替え可能なスクリプトによって異なるゲームの定義を行なうとともに、それぞれのスクリプトをインタープリタにより実際に解釈・実行するというものである。
【００５４】
図６は、ゲーム定義をスクリプト化し、インタープリタにて実行する方法のゲームアプリケーションを持つＩＣカードの構成を示す。ここでも、網掛けで示した部分はあらかじめプログラムで定められた固定の部分である。
【００５５】
この例では、ゲーム定義と実行権定義を別のものとして扱う。ゲーム実行権（２２２）、ポイントデータ（２２３）は図５までの例と同様、実行権処理部（２１３）およびポイントデータ処理部（２１４）により全ての種類のゲームに関して共通に扱う。共通処理コンポーネント（２２４）はあらかじめ定義されており、ゲーム定義スクリプト（２２６）は、これらのコンポーネントの呼出し順序を記述することで、ゲームごとに異なる結果判定アルゴリズムを定義する。
【００５６】
このゲーム定義スクリプト（２２６）は入れ替えが可能であり、スクリプトの入れ替えはゲーム定義スクリプト入れ替え処理部（２１６）が制御する。ＩＣカードのセキュリティを守るために厳格なアプリケーション発行スキームが定められているにも関わらず、簡便なゲーム種類入れ替えのためにスクリプト定義によりゲームの種類を入れ替えられるようにすることは、このことにより安全性を犠牲にする可能性があることは否定できない。このため、格納しようとするゲーム定義スクリプトが改竄されていないか、正当な開発者が開発したものか、ゲームにそのスクリプトを格納する権利があるかといった項目のチェックは、アプリケーションプログラム内部で行なわなければならない。つまり、ＯＳのもつアプリケーション発行スキームの代わりに、アプリケーション内部で独自のゲーム発行スキームを用意し、これに基づき安全なゲームスクリプトだけがカード内部格納されるように制御する。この役割をゲーム定義スクリプト入れ替え処理部（２１６）が行なうのである。
【００５７】
ゲーム実行権（２２２）データは、どの種類のゲームを何回実行可能かということを定義するデータであり、ゲーム発行時にカードに格納される。端末（１２０）からゲーム実行に関するコマンドを受信した場合には、ゲーム実行権（２２２）があれば、ゲーム定義スクリプト（２２６）の内容をスクリプトインタープリタ（２１５）で解釈するとともに実行する。ゲームの実行が終われば、ゲーム実行権（２２２）を減らす処理を行なうことはすでに説明した構成のものと同様である。ゲーム定義スクリプト（２２６）を複数種類格納することにより、複数種類のゲームに対応することができ、かつ、ゲーム定義スクリプト入れ替え処理部（２１６）により、アプリケーションをカードにロードした後でも、ゲームの種類を入れ替えることが可能となる。
【００５８】
図７は、図６の例と似ているが、ゲーム定義スクリプトの中にゲームの実行権を含ませたもので、ゲーム定義スクリプト（２２６）がすなわち１回分のゲーム実行権を含むゲームの定義、となっている。従って、ゲーム定義スクリプトで記述された１回分のゲームを実行したら、そのスクリプトは削除し、二度と実行できないように制御する必要がある。また、ゲーム実行権の管理とゲーム定義スクリプトの管理とは同一となり、ゲームデータ格納処理部（２１７）が管理する。ゲーム発行時に端末から送られて来たスクリプトをデータエリアに格納するとともに、スクリプト実行後のスクリプト削除もここで処理を行なう。ゲームデータ格納処理部（２１７）で、図６におけるゲーム定義スクリプト入れ替え処理部（２１６）と同様のスクリプト安全性チェックを行なわなければならないのは言うまでもない。
【００５９】
図８はさらに、図６の方法を複数のポイント系列に対応させたものである。ゲーム実行権（２２２）は、発行元とゲーム種別と実行回数を組にしたデータとして格納されている。ポイントデータ（２２３）も、点数は発行元別に格納される。ゲーム実行のコマンドが端末から送られてくると、発行元別の実行権（２２２）をチェックして、実行権があるゲーム種別について、ゲーム定義スクリプト（２２６）に従い、スクリプトインタープリタ（２１５）がゲームを実行する。ゲーム実行に伴うポイントデータ（２２３）の追加は、発行元別に点数を追加し、実行済みの発行元別実行権（２２２）を減算する。
【００６０】
この方式は、前出の出願済み発明（特願平１０−３０７２１６号）のポイントシステムの考え方を応用したものであり、ポイントデータ（２２３）が一通りではなく、複数のポイント系列に対応するものである。こうすることによって、ゲームの種類を複数にしただけでなく、ポイントサービスの提供者を複数にも対応させられる。これによって、ゲームのサービス運用者がそれぞれの店舗に対して、ゲームアプリケーションの間貸しのようなことをすることも可能となり、ゲームアプリケーションの可能性がさらに広がることになる。
【００６１】
次に、図９および図１０を用いて、図６および図７で説明した構成のＩＣカードを用いたゲーム付きポイントシステムにおけるシステム運用例を説明する。ここで、図９の運用例は図６のＩＣカードに対応したもので、ゲーム定義スクリプトとゲーム実行権が別々になっており、ゲーム種類の入れ替えは適当なタイミングで行なうことを想定したものである。図１０の運用例は図７のＩＣカードに対応したもので、ゲーム定義スクリプトとゲーム実行権が一緒になったものであり、ゲームを実行する毎にスクリプトも無効化（削除）してしまうものである。
【００６２】
図９は、複数ゲームに対応したゲームアプリケーションが搭載されたＩＣカードを用いたゲーム付きポイントシステムの運用例を表す図であり、この例では、ゲーム定義スクリプトとゲーム実行権データとは別のものになっている。
【００６３】
まず、ＩＣカード（１１０）には、ゲームアプリケーションプログラム（２００）がロードされており、このゲームアプリケーション（２００）は、コマンド処理部（２１１）、スクリプトインタープリタ（２１５）、ゲーム定義スクリプト入れ替え処理部（２１６）、実行権処理部（２１３）、ポイントデータ処理部（２１４）などから構成されている。ポイントデータ（２２３）は、発行元の会社ごとに管理されたポイントの点数のデータとして格納されている。ゲーム実行権（２２２）に関しても発行元ごとに管理されており、ゲームの種別と実行可能回数が格納されている。ゲーム定義スクリプト（２２６）は、ゲームの内容を共通処理コンポーネント（２２４）の呼出し順序を記述することで定義したものであり、実際にはスクリプトインタープリタ（２１５）でスクリプトの内容を解釈して実行する。このゲーム定義スクリプト（２２６）は、必要に応じて入れ替えることも可能である。
【００６４】
以下、ゲームの入れ替え・ゲーム発行・ゲーム実行・ポイント交換のそれぞれの段階に分けて、処理手順を説明する。
【００６５】
（ゲームの入れ替え）
店舗（１０４）あるいはその他の場所にある、ゲーム定義発行用端末（１１４）から、ゲーム入れ替えコマンド（１３２）およびゲーム定義データ（１４１）をＩＣカード（１１０）に対して送信する。すると、コマンド処理部（２１１）でコマンドを解釈し、ゲーム入れ替えコマンド（１３２）であることがわかれば、ゲーム定義スクリプト入れ替え処理部（２１６）にて、ゲーム定義の入れ替え処理を行なう。このとき、送られてくるゲーム定義スクリプトというのは、ポイントデータを書き換えることもできるものであることから、正しく発行元から発行されたものであるということが保証されていなければならない。そのために、発行するゲーム定義データ（１４１）には、あらかじめアプリケーションで定義したゲーム発行スキームに従い、発行元が正しいスクリプトであることを認証するような暗号キーをつけ、これによりゲーム定義スクリプト入れ替え処理部（２１６）にて認証処理を行なう必要がある。なお、ゲーム実行の際にはゲーム実行端末（１１１）に対応する端末プログラムが必要であるから、新しいゲームを発行する際には、端末側のプログラムの入れ替えが必要になる場合もある。
【００６６】
（ゲーム発行）
（Ｘ）社の店舗（１０４）での購入に応じて、店舗用端末（１０８）はＩＣカード（１１０）に対して、実行権発行コマンド（１３３）および実行権データ（１４２）を送信する。この実行権データ（１４２）には、ゲーム（Ａ）を１回実行可能で発行元は（Ｘ）社であるという情報が含まれる。このデータについても安全のために暗号化されていることが望ましい。コマンド処理部（２１１）ではコマンドを解釈し、実行権処理部（２１３）にてゲーム実行権データ（２２２）にデータを追加する。
【００６７】
（ゲーム実行）
ユーザ（１１３）がゲームを実行する場合は、ゲーム実行コマンド（１３１）がＩＣカード（１１０）に送信される。ゲーム実行権（２２２）が存在すれば、該当する種別のゲームを実行できる。ゲーム実行に伴い、ポイントデータ（２２３）の値が変化するが、この場合は、実行中の実行権データ（２２２）に含まれる、ゲーム実行権発行元のポイントを更新する。ゲーム実行後は、該当するゲーム実行権（２２２）を減らす処理を行なう。なお、ゲームを実行する場合には、ゲーム実行端末の中（１１１）に、ＩＣカードのゲームの種類に対応した実行用端末プログラムが必要である。
【００６８】
（ポイント交換）
ゲーム実行によって蓄積したポイントデータ（２２３）は、店舗（１０８）において規定のサービスと交換できるが、その際には、店舗用端末（１０８）（ゲーム実行権を発行する端末と同じ物でも違うものでもよい）から、ポイント演算コマンド（１３４）をＩＣカード（１１０）に対して送信する。コマンド処理部（２１１）にてポイントデータ処理部（２１４）に処理を渡し、ポイントデータ処理部（２１４）はポイント減算の処理を行なう。この場合、コマンドを送った店舗（１０４）が（Ｘ）社であれば、ポイント交換は（Ｘ）社発行のポイントだけを交換可能とする。
【００６９】
この方式においては、ゲーム定義スクリプト（２２６）の種類だけ、ユーザはゲームの実行が可能となる（もちろん、ゲーム実行権が存在する場合に限られる）。必要に応じてゲーム定義スクリプト（２２６）の入れ替えを行なうことにより、ゲームアプリケーション（２００）を入れ替えることなしに、常に新しいゲームを実行することができる。
【００７０】
図１０は、複数ゲームに対応したゲームアプリケーションが搭載されたＩＣカードを用いたゲーム付きポイントシステムの、別の運用例を表す図であり、この例では、ゲーム定義スクリプトがゲーム実行権データと一体になっている。図９の運用例と同様に、ＩＣカード（１１０）にはゲームアプリケーションプログラム（２００）がロードされており、このゲームアプリケーション（２００）は、コマンド処理部（２１１）、スクリプトインタープリタ（２１５）、ゲームデータ格納処理部（２１７）、ポイントデータ処理部（２１４）などから構成されている。ポイントデータ（２２３）は、発行元の会社ごとに管理されたポイントの点数のデータとして格納されている。図９の例と異なるところは、ゲームデータ（２２７）として、ゲーム定義スクリプトと発行元情報が対になったものを一組として、データを格納しているところである。ゲーム定義スクリプトをスクリプトインタープリタ（２１５）でスクリプトの内容を解釈して実行するところは同様である。このスクリプトは、１回分のゲーム実行権として見なすことができ、ゲーム実行の際には、対応する発行元のポイントデータ（２２３）のみを書き換えることができ、ゲーム実行が終了したら削除などにより無効化され、二度と同じスクリプトが実行されないようにする。
【００７１】
こちらも以下、ゲームの入れ替え・ゲーム発行・ゲーム実行・ポイント交換のそれぞれの段階に分けて、処理手順を説明する。
【００７２】
（ゲーム発行）
（Ｘ）社の店舗（１０４）での購入に応じて、店舗用端末（１０８）はＩＣカード（１１０）に対して、ゲーム発行コマンド（１３５）および、ゲーム定義スクリプトと発行元を含むゲームデータ（１４３）を送信する。安全のため、発行するゲームデータ（１４３）には、あらかじめ定義した方法により、発行元が正しいスクリプトであることを認証するような暗号キーをつけ、これによりゲームデータ格納処理部（２１７）にて認証処理を行なう必要がある。なお、ゲーム実行の際にはゲーム実行端末（１１１）に対応する端末プログラムが必要であるから、新しいゲームを発行する際には、端末側のプログラムの入れ替えが必要になる場合もある。
【００７３】
（ゲーム実行）
ユーザ（１１３）がゲームを実行する場合は、ゲーム実行コマンド（１３１）がＩＣカード（１１０）に送信される。ゲームデータ（２２７）が存在すれば、ゲーム定義スクリプトにより記述されたゲームを実行できる。ゲーム実行に伴い、ポイントデータ（２２３）が増やされるが、この場合は、実行中のゲームデータ（２２７）に含まれる発行元のポイントを増やす。ゲーム実行後は、該当するゲームデータ（２２７）をスクリプトごと消去し、二度と実行できないようにする。なお、ゲームを実行する場合には、ゲーム実行端末の中（１１１）に、ＩＣカードのゲームの種類に対応した実行用端末プログラムが必要である。
【００７４】
（ポイント交換）
ゲーム実行によってためられたポイントデータ（２２３）は、のちほど店舗（１０８）において規定のサービスと交換できるが、その際には、店舗用端末（１０８）（ゲーム実行権を発行する端末と同じ物でも違うものでもよい）から、ポイント演算コマンド（１３４）をＩＣカード（１１０）に対して送信する。コマンド処理部（２１１）にてポイントデータ処理部（２１４）に処理を渡し、ポイントデータ処理部（２１４）はポイント減算の処理を行なう。この場合、コマンドを送った店舗（１０４）が（Ｘ）社であれば、ポイント交換は（Ｘ）社発行のポイントだけを交換可能とする。
【００７５】
この方式においては、ゲームデータ（２２７）としてゲーム定義スクリプトを含んでいるので、同じ種類のゲームを複数格納する場合にはスクリプトがだぶる場合があり、無駄となる可能性もあるが、必要に応じてゲーム定義スクリプトの入れ替えを行なう図９の例に比べて、ゲーム種類に対する柔軟性は増す。ゲーム実行権の発行がすなわち新しいゲームの発行となるため、ゲームアプリケーション（２００）を入れ替えることなしに、常に新しいゲームを実行することができる。ただし、新しいゲームの種類を開発するたびに端末側のプログラムも変更する必要があるので、ゲーム実行用端末が分散している場合には端末用プログラムの更新の手間がかかる恐れもある。
【００７６】
次に、ゲーム処理実行部の処理の流れについて、図１１により説明する。ゲーム定義データ（２２６）には、パラメータ定義（３０１）、実行権定義（３０２）、スクリプト記述（３０３）が格納されている。これとは別にポイントデータ（３０８）が存在する。
【００７７】
ゲーム処理実行部には、ローカルな変数としてプログラムカウンタ（３０４）および実行用配列（３０５）を持ち、また端末から送られてきたコマンドのパラメータ（３０６）を参照／端末に返すレスポンスのパラメータ（３０７）を書き換えることができる。
【００７８】
端末からのコマンドが送られてくると、ゲーム処理実行部は、端末からのコマンドを受信、解析し（３１１）、指定されたゲーム種類に切り替える（すなわち、指定されたゲーム定義を呼び出す）（３１２）。このときコマンドに付随して送られてきたパラメータをコマンドパラメータ（３０６）に格納する。
【００７９】
プログラムカウンタ（３０４）の値を初期化して（３１３）ゲーム実行を開始する。スクリプト記述部（３０３）に記述されたスクリプトを順番に実行していくわけであるが、基本的にはプログラムカウンタ（３０４）の値をひとつずつ進めていきながら（３１４）、順番にスクリプトを解析し（３１５）、共通処理コンポーネントを呼び出すことでスクリプトを実行する。スクリプトが「コマンド待ち」であれば、いったん端末にレスポンスを返信し、次のコマンド受信を待つ（３１６）。スクリプトが「終了」であれば、レスポンスを返信し、スクリプト処理を終了する（３１７）。スクリプトがジャンプまたは分岐を指定するものであれば、プログラムカウンタをジャンプ先に変更し、次のスクリプト解析に進む（３１８）。それ以外のスクリプトの場合には、スクリプトに関連付けられた対応する共通処理コンポーネントを呼び出して、実際にスクリプトを実行し（３１９）、プログラムカウンタを進める処理（３１４）に戻る。スクリプト実行（３１９）では、コマンドパラメータ（３０６）の値を参照しながら、実行用配列（３０５）の値やレスポンスパラメータ（３０８）の値を更新していく。これを続けていくことで、ゲームの実行が行なわれる。
【００８０】
図１２には、共通コンポーネントを呼び出すためのスクリプト言語定義の例を示す。ここで、ａｒｒａｙ［ ］とは実行用配列（３０５）であり、ｃｍｄ［ ］はコマンドパラメータ（３０６）、ｒｓｐ［ ］はレスポンスパラメータ（３０７）をさす。それぞれのスクリプトは、ひとつの共通コンポーネントを呼び出し、実際にプログラムを実行する役割を果たす。ひとつのスクリプトについてパラメータは３つまで付随する。
【００８１】
この例では、わかりやすいように通常のプログラミング言語に近い言語体系でスクリプトを記述しているが、メモリ容量の少ないＩＣカードで実行することを考えると、ゲームに限定した場合にはもっと特殊な形のスクリプト言語体系（例えば少ない桁数のバイト列で表現するような）のほうが向いているかもしれない。また、スクリプトを発行する端末側に何らかのコンパイル手段を用意し、バイト列に表現し直したスクリプトを発行する方法もある。
【００８２】
以下、図１３から図１９までを用いて、３種類のゲームの実装例を挙げていくが、この中では、図１２で定義したスクリプトを用いてゲーム定義を表現する。
【００８３】
図１３は、ボックス数（＝乱数の数）が３で、ひとつのボックスで表現される数字（乱数）の範囲が０〜２までであるスロットマシンの、ゲーム実行端末におけるゲーム実行画面の例である。各ボックスの値について、「０」をりんご、「１」をみかん、「２」をバナナで表している。
【００８４】
（ａ）は、ゲームを開始した状態の画面である。現在のポイント数（４０１）および残り実行可能ゲーム数（４０２）が表示され、３つのボックス（４０５）はまだ値が確定しておらず、画面上では回転している様子が描かれている。ユーザが３つの「Ｐｕｓｈ」ボタン（４０６）をひとつずつ押すことで、カードに対して乱数発生のコマンドが送られて、ボックスに乱数の値に対応した絵が表示される。
【００８５】
（ｂ）は１回目の「Ｐｕｓｈ」選択後の画面例である。カードの中で発生した乱数が「０」だったので、対応するボックスにはりんごの絵が表示される。これを３回繰り返す。
【００８６】
（ｃ）は３回目の「Ｐｕｓｈ」が選択され、１回分のゲームを終了した状態（あたりの場合）の画面例である。３つのボックスの絵がすべて一致したため、ゲームにかけられた点数「１００」点がユーザのポイントに追加される。ゲームの結果が「あたり」で１００ポイントが追加されたことを示すメッセージ（４０３）が表示され、ポイントが追加されているのがわかる。
【００８７】
（ｄ）は３回目の「Ｐｕｓｈ」が選択され、１回分のゲームを終了した状態（はずれの場合）の画面例である。３つのボックスの絵が一致しなかった場合には、「はずれ」のメッセージ（４０４）が表示され、ポイントの追加はない。
【００８８】
図１４は、図１３に示したスロットマシンを、図１２のスクリプトで記述した例を示す。００行から１１行（バイナリ）まで、１８行のスクリプトで表現される。
【００８９】
００〜０２行：１回目の「Ｐｕｓｈ」が押されたときに呼ばれる。乱数をひとつ発生し、それを実行用配列に格納して、その乱数の値を返す。端末に操作を返させたい場合には、「Ｒｅｔｕｒｎ」スクリプトが定義される。
【００９０】
０３〜０５行：２回目の「Ｐｕｓｈ」が押されたときに呼ばれる。乱数をひとつ発生し、それを実行用配列に格納して、その乱数の値を返す。
【００９１】
０６〜０８行：３回目の「Ｐｕｓｈ」が押されたときに呼ばれる。乱数をひとつ発生し、それを実行用配列に格納する。レスポンスに「今回が最後」を表す値を入れ、結果判定に進む。
【００９２】
０９〜１１行：結果判定。格納した３つの乱数がすべて一致したら、所定の点数をポイントに追加する。最後に結果を返して終了である。
【００９３】
図１５は、当たる確率が３分の１で、勝負数が３回であるルーレットゲームの、ゲーム実行端末におけるゲーム実行画面の例である。３つの数字を、それぞれ「Ａ」「Ｂ」「Ｃ」と表す。図には表れないが、カラーで色分けされていると見やすい。
【００９４】
（ａ）は初期画面である。現在のポイント数（４０１）および残り実行可能ゲーム数（４０２）が表示されている。ゲームを始めるには、ルーレット（４０８）を回転させる前に、賭け場（４０７）から「Ａ」「Ｂ」「Ｃ」いずれかを選ぶ。
【００９５】
（ｂ）はゲーム開始後の画面である。ここでは賭け場（４０７）から「Ｂ」を選ぶと、「Ｂ」のところに黒い丸が置かれる。スコア（４１０）と残り勝負数（４１１）が表示される。このゲームでは勝負数は「３」なので、残り勝負数（４１１）は「３」と表示される。ここで「Ｓｔａｒｔ」ボタン（４０９）を押して回転を始めると、残り勝負数（４１１）が減少する。
【００９６】
（ｃ）はルーレット（４０８）が回転した状態（これは画面上での見え方で、カード側のプログラムでは待ち状態になっている）で、「Ｓｔｏｐ」ボタン（回転を止めるボタン）（４０６）を押すと、ＩＣカードに対してコマンドを発行する。
【００９７】
（ｄ）は１回分の勝負を終えた状態の画面である。カードで発生した乱数の値に応じて、賭けた数字と一致していれば「あたり」（４０３）としてスコアが追加される。
【００９８】
（ｅ）は１回分の勝負を終えてはずれた場合の画面である。「はずれ」（４０４）としてスコアは追加されない。
【００９９】
（ｆ）回転と乱数発生を３回繰り返すと、ゲームは終了である。「ＧＡＭＥ ＯＶＥＲ」とスコアの値が表示される（４１２）。
【０１００】
図１６は、図１５に示したルーレットを、図１２のスクリプトで記述した例を示す。００行から１ａ行（バイナリ）まで、２７行のスクリプトで表現される。
【０１０１】
００〜０５行：１回目の「Ｓｔｏｐ」が押されたときに呼ばれる。コマンドのパラメータとして送られたユーザ入力値を実行用配列と、乱数をひとつ発生させたものを比較し、比較結果を配列に格納する。比較結果とその乱数の値を端末に返す。
【０１０２】
０６〜０ｂ行：２回目の「Ｓｔｏｐ」が押されたときに呼ばれる。コマンドのパラメータとして送られたユーザ入力値を実行用配列と、乱数をひとつ発生させたものを比較し、比較結果を配列に格納する。比較結果とその乱数の値を端末に返す。
【０１０３】
０ｃ〜１０行：３回目の「Ｓｔｏｐ」が押されたときに呼ばれる。コマンドのパラメータとして送られたユーザ入力値を実行用配列と、乱数をひとつ発生させたものを比較し、比較結果を配列に格納する。
【０１０４】
０１〜１ａ行：結果判定。３回分の比較結果に応じて、点数をポイントに追加する。最後に結果を返して終了である。
【０１０５】
図１７は、ボックス数が５で、５回勝負のシューティングゲームの、ゲーム実行画面の画面例である。１秒毎にランダムに移動するターゲットを狙い、ユーザはボックスをクリックして、ターゲットが現れているボックスと一致するかどうかを競うゲームである。このクリックを５回繰り返す。
【０１０６】
（ａ）は初期画面である。現在のポイント数（４０１）および残り実行可能ゲーム数（４０２）が表示されている。「Ｓｔａｒｔ」ボタン（４０９）をクリックするとゲームを開始する。
【０１０７】
（ｂ）はユーザが画面をクリックする前の画面である。５つのボックス（４０５）に、ランダムにターゲットの絵（４１３）が現れる。これは１秒毎に発生する乱数の値に応じて変化する。画面中には、現在のゲームのスコア（４１０）および残り勝負数（４１１）が表示される。
【０１０８】
（ｃ）はユーザが画面をクリックしているところの画面である。この場合は、ユーザが選んだボックスとターゲットが現れているボックスとが一致しているので、「あたり」（４１４）としてスコアが１０点追加される。
【０１０９】
（ｄ）はユーザが画面をクリックしているところの画面である。ユーザが選んだボックスとターゲットが現れているボックスとが一致しない場合は「はずれ」（４１５）である。
【０１１０】
（ｅ）はゲーム終了画面である。５回の勝負が終了すると、「ＧＡＭＥ ＯＶＥＲ」とスコアの値が表示される（４１２）。残りゲーム数（４０２）がまだある場合には、新たな「Ｓｔａｒｔ」ボタン（４０９）が表示される。
【０１１１】
図１８は、図１７に示したシューティングゲームの処理手順を、端末（１２０）側とカード（１１０）側に分けて表した図である。他のＩＣカード上のプログラムと同じく、基本的に端末（１２０）からはコマンドとパラメータをカードに対して送り、カード（１１０）は受け取ったコマンドに応じて処理を実行してレスポンスを返す、という手順になる。現在のＭＵＬＴＯＳなどを搭載したＩＣカードには時計が内蔵されていない（端末からのコマンド受信をきっかけに動作する）ので、１秒毎にカードが乱数を発生して画面を更新するためには、端末側で１秒毎に乱数発生要求をカードに送ってやる必要がある。
【０１１２】
まず、端末（１２０）は乱数発生要求のコマンド（パラメータ＝０）を発行する（３２１）。
【０１１３】
カード（１１０）では、コマンドを受信（３２１）し、ボックス数の範囲で発生した乱数を変数Ｒに代入して（３３２）、パラメータ＝Ｒとしてレスポンスを送信する（３３３）。端末はこれを受けて、Ｒの値に応じて画面を再表示する（３２２）。１秒毎のタイマー（３２３）により、これ（３２１から３２２まで）を１秒間隔で繰り返す。
【０１１４】
ユーザから入力（クリック）があると、ユーザが選択したボックス番号を変数Ｄに代入し（３２４）、パラメータ＝Ｄとしてコマンドを発行する（３２１）。カードはコマンドを受信し（３３１）、パラメータがＤ（０以外）であれば、格納してあった直前の乱数Ｒと受け取ったボックス番号Ｄとを比較し（３２４）、あたりであればポイント数を追加し、比較結果を端末に返す（３３５）。端末は結果を受け取り、画面に結果を表示する（４１２）。これを勝負数（図１７の例では５回）だけ繰り返す。
【０１１５】
図１９は、図１７および図１８で説明したシューティングゲームを、図１２のスクリプトで記述した例を示す。コマンドのパラメータが「０」の場合は乱数を発生し、それ以外の場合は、ユーザ入力を前回の乱数の値と比較する。このスクリプト例では、前のふたつの例とは異なり、ループを実現している。
【０１１６】
００〜０２行：実行用配列の初期化
０３行：ループのトップ
０４行：コマンドパラメータの値に応じて分岐する
０５〜０ｄ行：コマンドパラメータに「０」以外が渡されたときは、ユーザの入力値と乱数の値を比較して、比較結果を格納する。ループカウンタをひとつ増やす。ループカウンタが最終回以外の場合は、比較結果を端末に返す。端末に処理を渡し、次に処理が戻ってきた場合には、ループの先頭（０３行）に戻る。
【０１１７】
０ｅ〜１１行：最終ループの場合。格納された比較結果に基づき、点数をポイントに追加する。
【０１１８】
１２〜１６行：コマンドはダミーの場合。乱数を発生し、その乱数を端末に返す。ループの先頭に戻る。
【０１１９】
これを繰り返すことにより、図１８の処理をスクリプトで実現できる。
【０１２０】
以上説明してきたように、図１２に示したスクリプトを用いることで、例に挙げた３種類のゲームのような、複数種類のゲームを定義することができる。この３種類はあくまでも一例であり、乱数発生およびユーザからの入力との比較との組み合わせにより、他にも何種類ものゲームを定義できる。これらスクリプト記述で定義されたゲームを、図１１に示すようなスクリプトインタープリタ（実行部）によって実行することで、ひとつのアプリケーションプログラムで複数種類のゲームを実行することが可能となる。
【０１２１】
以上、ＩＣカード上で複数種類のゲームを実行可能なアプリケーションプログラムおよびその運用について説明してきたが、この方法をゲーム以外のアプリケーションに応用することも可能である。例えば、次々と更新される画面上で回答していくことでポイントを獲得するアンケートシステムや、特定の広告を閲覧することでポイントを獲得する広告システムなど、ユーザの操作によりポイントなどの価値を生み出し、かつ同一のスクリプトを二度と実行しないように制御するアプリケーションとして、本発明を適用することが可能となる。ただし、その場合は、アンケートの回答履歴や広告の閲覧履歴をカード中に格納しておき、同一のアンケート・広告スクリプトを複数回ロードしないように制御する必要がある。また、ゲームの場合はスクリプト実行後は該当スクリプトを削除するか実行権を減算するだけで良いが、アンケ−トの場合は回答デ−タを店舗側に回収する必要が生じる。
【０１２２】
図２０は、本発明をアンケートシステムに応用した運用例である。基本的には図１０に示したゲームシステムの運用例と類似しているが、アンケート回答を回収する部分が少し異なる。
【０１２３】
ＩＣカード（１１０）にはアンケートアプリケーション（５００）がロードされており、このアンケートアプリケーション（５００）は、コマンド処理部（２１１）、スクリプトインタープリタ（２１５）、アンケートデータ格納処理部（５０３）、ポイントデータ処理部（２１４）などから構成されている。アンケートデータ（５０１）は、アンケートスクリプトと発行元および回答データとの組で格納されている。回答データはユーザがアンケートに回答するまでは中身は空になっており、ユーザがアンケートに回答すると回答データが格納される。この回答データは、アンケートが回答済みであるかどうかを表すフラグの役割も持っており、このデータが入っている場合には二度と同じアンケートを実行することができない。アンケートに対する回答履歴は回答履歴データ（５０２）として格納されており、回答済みのアンケートがロードされないように制御する。また、図９、図１０と同様、ポイントデータ（２２３）は、発行元の会社ごとに管理されたポイントの点数のデータとして格納されている。
【０１２４】
（Ｘ）社の店舗（１０４）において、店舗用端末（１０８）はＩＣカード（１１０）に対して、アンケート発行コマンド（５０６）および、アンケート定義スクリプトと発行元を含むアンケートデータ（５０７）を送信する。このデータは、ゲームのときと同様、正しく発行元から発行されたものであるということを保証するために、あらかじめ定義した方法により、発行元が正しいスクリプトであることを認証するような暗号キーをつけ、これによりアンケートデータ格納処理部（５０３）にて認証処理を行なう必要がある。アンケートデータ格納処理部（５０３）ではまた、送られてきたアンケートデータ（５０７）が回答済みかどうかを回答履歴データ（５０２）と照らし合わせてチェックし、回答済みのアンケートについてはアンケートデータ（５０１）に格納されないように制御を行なう役目も担っている。
【０１２５】
ユーザ（１１３）がユーザ端末（５０９）にてアンケートに回答する場合は、アンケート実行コマンド（５０５）がＩＣカード（１１０）に送信される。アンケートデータ（５０１）が存在すれば、アンケート定義スクリプトにより記述されたゲームを実行できる。アンケートは、単純に質問に答えるだけでなくて、ユーザが回答の詳細度を選択できるようにし、また前回の回答内容によって次回の質問内容が変化するように工夫されている。アンケートを回答したら、回答内容によって重み付けされた点数が、発行元のポイントデータ（２２３）に加算され、アンケートデータ（５０１）には回答データが付加される。回答データの付加されたアンケートデータ（５０１）は二度と回答することができない。つまり、回答済みのアンケートデータ（５０１）に回答データを付加することは、該当するアンケートデータを無効化することに相当する。
【０１２６】
店舗端末（１０８）にて、ポイント交換を行なう際、あるいは同じ発行元の次のアンケートを発行する際に、前回回答したアンケート回答データを回収しなければならない。回答済みのアンケートデータは、回答データが付加されて無効化された状態になっているので、回答データを回収しないでためていくとアンケートデータ（５０１）があふれる恐れがあるので、適当なタイミングで回答データの回収を行なう必要がある。回答データの回収が要求されると、アンケート回答回収処理部（５０４）では、回答データを暗号化して端末（１０８）に返却し、それとともに該当するアンケートデータ（５０１）を消去し、回答履歴データ（５０２）に履歴情報を追加する。
【０１２７】
このような方式により、本発明をゲームだけでなくアンケートシステムに展開することが可能となる。広告閲覧システムも類似の方法により応用可能である。
【０１２８】
以上述べてきたように、本発明の実施例による効果を、「課題を解決する手段」で挙げた６項目に沿って挙げると、
まず本発明の実施例により実現されるＩＣカードによれば、
（１）以下の要素からなるアプリケーションプログラム：
（ａ）ゲーム実行コンポーネント
（ｂ）ゲーム定義スクリプト格納部
（ｃ）スクリプトインタープリタ
（ｄ）ポイントデータ格納部・処理部
（ｅ）ゲーム実行権格納部・処理部
（ｆ）コマンド処理部
により、ＩＣカード上のひとつのアプリケーションプログラムによって、複数種類のゲームを実行することが可能となる。
【０１２９】
これに加えて、
（２）ゲーム定義スクリプト格納処理部
により、ゲームアプリケーションプログラムをＩＣカードにロードしてからでも、アプリケーションプログラムの入れ替えを必要とせずに、随時新しい種類のゲームを導入することができ、より柔軟なゲームシステムを提供することが可能となる。
【０１３０】
アプリケーションプログラムが規定するゲーム発行スキームに基づき格納を制御することにより、安全にアプリケーションプログラムの処理を切り替えることができるとともに、カードＯＳによって規定された面倒なアプリケーション発行スキームから開放される。
【０１３１】
また、同一の処理を行なうゲームアプリケーションプログラムを、“ＭＵＬＴＯＳ”や“Ｊａｖａ Ｃａｒｄ”といった異なるＯＳを搭載したＩＣカードにロードしておけば、新しいゲームを開発する際にはＯＳの違いにとらわれることなく同様のゲームを開発することが可能となる。
【０１３２】
（３）発行元別ポイント管理機能により、複数種類のゲームを複数の発行元で、ひとつのアプリケーションで管理することが可能となり、より広く利用されるゲームシステムを提供することが可能となる。
【０１３３】
次に、このＩＣカードを取り扱うための端末装置としては、
（４）ゲーム発行機能
（６）ポイント演算機能
により、ＩＣカードに対して、ゲームアプリケーションプログラムの入れ替えをすることなしに複数種類のゲームを発行することが可能となるとともに、ポイント管理まで含めた柔軟なゲームシステムを安全に運用することが可能となる。
【０１３４】
また、それぞれのゲームを実行するためのユーザインタフェースを備えた
（５）ゲーム実行機能
により、ユーザは楽しみながらゲームを実行することでポイントを獲得できる。
【０１３５】
従って、本発明の実施例によれば、より柔軟性の高いゲームアプリケーションをＩＣカードシステムに安全に導入することが可能となる。ゲームの結果をポイントと連動することにより、利用者のカード利用意欲が増し、アプリケーション提供者の顧客囲い込みに有効であるとともに、ＩＣカードシステムの普及に大きく役立つ。
【０１３６】
また、スクリプト定義とインタープリタの導入・アプリケーションプログラムが規定するゲーム発行スキームに基づきスクリプトの格納を制御する方法により、ゲームアプリケーションに限らず、プログラムの入れ替えなしにプログラムの処理内容を入れ替える方式は、プラットフォームから開放された、より柔軟で簡便なＩＣカードアプリケーションの開発を可能とする。
【０１３７】
【発明の効果】
本発明によれば、例えば、プログラムの入れ替えなしにゲームの入れ替えが可能である。
【図面の簡単な説明】
【図１】ＩＣカードを用いたゲーム付きポイントシステムのサービスイメージ図。
【図２】マルチアプリケーションＩＣカード上のプログラム実行における情報の流れを示す図。
【図３】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その１）。
【図４】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その２）。
【図５】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その３）。
【図６】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その４）。
【図７】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その５）。
【図８】本発明の実施例に係るゲーム付きポイントシステムにおける具体的なＩＣカードの構成を説明するための図（その６）。
【図９】ゲーム発行運用例を示す図（その１）。
【図１０】ゲーム発行運用例を示す図（その２）。
【図１１】スクリプトインタープリタ（実行部）の処理を示す図。
【図１２】共通コンポーネント呼出しスクリプト言語定義の例を示す図。
【図１３】スロットマシンの例の例を示す図。
【図１４】スロットマシンにおけるスクリプト記述例を示す図。
【図１５】ルーレットの例を示す図。
【図１６】ルーレットにおけるスクリプト記述例を示す図。
【図１７】シューティングゲームの例を示す図。
【図１８】シューティングゲームの処理手順の例を示す図。
【図１９】シューティングゲームにおけるスクリプト記述例を示す図。
【図２０】アンケートシステムの運用例を示す図。
【符号の説明】
１０１：サービスプロバイダ側
１０２：アプリケーション提供者
１０３：サービス管理者
１０４：店舗（ゲーム供給者）
１０５：アプリケーションロード用端末
１０６：ゲーム管理用データ
１０７：ゲーム管理用サーバ
１０８：店舗用端末
１０９：ユーザ側
１１０：ＩＣカード
１１１：ユーザ用ゲーム実行端末
１１２：店舗内ゲーム実行端末
１１３：ユーザ
１１４：ゲームデータ発行用端末
１２０：端末
１３１：ゲーム実行コマンド
１３２：ゲーム入れ替えコマンド
１３３：実行権発行コマンド
１３４：ポイント演算コマンド
１３５：ゲーム発行コマンド
１４１：発行するゲーム定義データ
１４２：発行する実行権データ
１４３：発行するゲームデータ
１５１〜１５８：データの流れ
１６１：ＩＣカード用Ｒ／Ｗ
１６２：端末プログラム
１６３：端末ＯＳ
１６４：（端末の）入出力インタフェース
２００：ゲームアプリケーションプログラム
２０１：カードＯＳ
２０２：入出力インタフェース
２０３：アプリケーションプログラム
２０４：アプリケーションデータ
２０５：実行処理部
２１１：コマンド処理部
２１２：結果判定アルゴリズム
２１３：実行権処理部
２１４：ポイントデータ処理部
２１５：スクリプトインタープリタ（実行部）
２１６：ゲーム定義スクリプト入れ替え処理部
２１７：ゲームデータ格納処理部
２２１：ゲームパラメータ
２２２：ゲーム実行権データ
２２３：ポイントデータ
２２４：共通処理コンポーネント
２２５：コンポーネント呼出し定義
２２６：ゲーム定義スクリプト
２２７：ゲームデータ（スクリプト＋発行元）
３００：ゲーム定義データ
３０１：パラメータ定義
３０２：実行権定義
３０３：スクリプト記述
３０４：プログラムカウンタ
３０５：実行用配列
３０６：コマンドパラメータ
３０７：レスポンスパラメータ
３０８：ポイントデータ
３１１〜３１９：ゲーム処理実行部の処理ステップ
３２１：コマンド発行処理
３２２：再表示処理
３２３：タイマー
３２４：入力データの代入処理
３３１：コマンド受信処理
３３２：乱数発生と代入処理
３３３：レスポンス送信処理
３３４：データの比較処理
３３５：結果の返却処理
４０１：ポイント数
４０２：残りゲーム数
４０３：あたりのメッセージ
４０４：はずれのメッセージ
４０５：ボックス
４０６：回転を止めるためのボタン
４０７：賭け場
４０８：回転ルーレット
４０９：スタートボタン
４１０：スコア
４１１：残り勝負
４１２：ゲーム結果
４１３：ターゲット
４１４：あたった場合
４１５：はずれた場合
５００：アンケートアプリケーション
５０１：アンケートデータ
５０２：回答履歴データ
５０３：アンケートデータ格納処理部
５０４：アンケート回答回収処理部
５０５：アンケート実行コマンド
５０６：アンケート発行コマンド
５０７：発行するアンケートデータ
５０８：回収する回答データ
５０９：ユーザ端末。
Claims (30)
- ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、前記アプリケーションプログラムの動作手順を定義するためのスクリプトの解釈および実行するためのインタープリタ機能を有するアプリケーションプログラムを、前記入出力インタフェースを介して前記スマートカードの外から中へ供給することを特徴とするアプリケーションプログラムの供給方法。
- 前記スマートカードは前記スクリプトで定義された動作手順に従ったプログラムの実行結果に応じて値が更新されるポイントデータを格納するポイントデータ格納部を有することを特徴とする請求項１記載のスマートカード。
- 前記スクリプトによって定義された処理は、スマートカードのユーザの入力および実行のタイミングによって異なる結果を得る可能性を持ち、事前に前記ユーザがその結果を予測不可能である処理であることを特徴とする請求項１記載のスマートカード。
- 前記スクリプトで定義された処理を実行した後、該当するスクリプトを無効として前記処理を実行不可能に設定する手段を有することを特徴とする請求項１のスマートカード。
- 前記スクリプトで定義された処理を実行できる最大回数を定義するスクリプト実行権を格納するための実行権格納部を有し、前記スクリプトで定義された処理を実行した後、該当するスクリプトの実行権データを減算する手段を有することを特徴とする請求項１のスマートカード。
- アプリケーションプログラムの供給後に、前記スクリプトを前記入出力インタフェースを通じて前記記憶手段へ格納することを特徴とする請求項１記載のスクリプト供給方法。
- アプリケーションプログラムの供給後に、前記スクリプトを前記入出力インタフェースを通じて前記記憶手段へ格納する際に、所定の認証処理を行ない、改竄されていない正しいスクリプトが格納されることを保証するための認証処理部を有することを特徴とする請求項１記載のスマートカード。
- 前記ポイントデータを発行元別に集計し、
前記スクリプトあるいは実行権データに発行元を示す識別子を付加し、
前記スクリプトで定義された処理の実行結果に応じて、前記発行元データに対応するポイントデータのみを更新する手段を有することを特徴とする請求項２記載のスマートカード。 - ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、そのアプリケーションプログラムの動作手順を定義するためのスクリプトを解釈および実行するためのインタプリタ機能を有する前記アプリケーションプログラムが前記記憶手段に格納された前記スマートカードの外から中へ前記入出力インタフェースを介して前記スクリプトを供給することを特徴とするスクリプト供給方法。
- ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、前記アプリケーションプログラムの動作手順を定義するためのスクリプトの解釈および実行するためのインタープリタ機能を有するアプリケーションプログラムを、前記入出力インタフェースを介して前記スマートカードの外から中へ供給することを特徴とするアプリケーションプログラムを有するスマートカード。
- 前記スクリプトが前記記憶手段に格納されていることを特徴とする請求項１０記載のスマートカード。
- ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、前記アプリケーションプログラムの動作手順を定義するためのスクリプトの解釈および実行するためのインタープリタ機能を有するアプリケーションプログラムを、前記入出力インタフェースを介して前記スマートカードへ供給する手段を有することを特徴とする端末装置。
- ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、そのアプリケーションプログラムの動作手順を定義するためのスクリプトを解釈および実行するためのインタプリタ機能を有する前記アプリケーションプログラムが、前記記憶手段に格納された前記スマートカードの外から中へ前記入出力インタフェースを介して前記スクリプトを供給する手段を有することを特徴とする端末装置。
- ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、前記アプリケーションプログラムの動作手順を定義するためのスクリプトの解釈および実行するためのインタープリタ機能を有するアプリケーションプログラムを、前記入出力インタフェースを介して前記スマートカードへ供給する手段を有することを特徴とする端末装置。
- ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、前記アプリケーションプログラムの動作手順を定義するためのスクリプトの解釈および実行するためのインタープリタ機能を有するアプリケーションプログラム。
- 前記スマートカードは前記スクリプトで定義された動作手順に従ったプログラムの実行結果に応じて値が更新されるポイントデータを格納するポイントデータ格納部を有することを特徴とする請求項１５記載のアプリケーションプログラム。
- 前記スクリプトによって定義された処理はスマートカードのユーザの入力および実行のタイミングによって異なる結果を得る可能性を持ち、事前に前記ユーザがその結果を予測不可能である処理であることを特徴とする請求項１５記載のアプリケーションプログラム。
- 前記スクリプトで定義された処理を実行した後、該当するスクリプトを無効として前記処理を実行不可能に設定する機能を有することを特徴とする請求項１５のアプリケーションプログラム。
- 前記スクリプトで定義された処理を実行できる最大回数を定義するスクリプト実行権を格納するための実行権格納部を有し、前記スクリプトで定義された処理を実行した後、該当するスクリプトの実行権データを減算する機能を有することを特徴とする請求項１５のアプリケーションプログラム。
- アプリケーションプログラムの供給後に、前記スクリプトを前記入出力インタフェースを通じて前記記憶手段へ格納することが可能に構成されたことを特徴とする請求項１５記載のアプリケーションプログラム。
- アプリケーションプログラムの供給後に、前記スクリプトを前記入出力インタフェースを通じて前記記憶手段へ格納する際に、所定の認証処理を行ない、改竄されていない正しいスクリプトが格納されることを保証するための認証処理部を有することを特徴とする請求項１５記載のアプリケーションプログラム。
- 前記ポイントデータを発行元別に集計し、
前記スクリプトあるいは実行権データに発行元を示す識別子を付加し、
前記スクリプトで定義された処理の実行結果に応じて、前記発行元データに対応するポイントデータのみを更新する機能を有することを特徴とする請求項１６記載のアプリケーションプログラム。 - ＣＰＵ、記憶手段および入出力インタフェースを有するスマートカード（ｓｍａｒｔ ｃａｒｄ）に搭載されたオペレーティングシステム（ＯＳ）上で動作可能なアプリケーションプログラムであり、かつ、前記アプリケーションプログラムの動作手順を定義するためのスクリプトの解釈および実行するためのインタープリタ機能を有するアプリケーションプログラムを有する記憶媒体。
- 前記スマートカードは前記スクリプトで定義された動作手順に従ったプログラムの実行結果に応じて値が更新されるポイントデータを格納するポイントデータ格納部を有することを特徴とする請求項２３記載の記憶媒体。
- 前記スクリプトによって定義された処理はスマートカードのユーザの入力および実行のタイミングによって異なる結果を得る可能性を持ち、事前に前記ユーザがその結果を予測不可能である処理であることを特徴とする請求項２３記載の記憶媒体。
- 前記スクリプトで定義された処理を実行した後、該当するスクリプトを無効として前記処理を実行不可能に設定する機能を有することを特徴とする請求項２３の記憶媒体。
- 前記スクリプトで定義された処理を実行できる最大回数を定義するスクリプト実行権を格納するための実行権格納部を有し、前記スクリプトで定義された処理を実行した後、該当するスクリプトの実行権データを減算する機能を有することを特徴とする請求項２３の記憶媒体。
- アプリケーションプログラムの供給後に、前記スクリプトを前記入出力インタフェースを通じて前記記憶手段へ格納することが可能に構成されたことを特徴とする請求項２３記載の記憶媒体。
- アプリケーションプログラムの供給後に、前記スクリプトを前記入出力インタフェースを通じて前記記憶手段へ格納する際に、所定の認証処理を行ない、改竄されていない正しいスクリプトが格納されることを保証するための認証処理部を有することを特徴とする請求項２３記載の記憶媒体。
- 前記ポイントデータを発行元別に集計し、
前記スクリプトあるいは実行権データに発行元を示す識別子を付加し、
前記スクリプトで定義された処理の実行結果に応じて、前記発行元データに対応するポイントデータのみを更新する機能を有することを特徴とする請求項２４記載の記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003207781A JP2004086890A (ja) | 2003-08-19 | 2003-08-19 | アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003207781A JP2004086890A (ja) | 2003-08-19 | 2003-08-19 | アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP36914299A Division JP2001184472A (ja) | 1999-12-27 | 1999-12-27 | アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004086890A true JP2004086890A (ja) | 2004-03-18 |
Family
ID=32064485
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003207781A Withdrawn JP2004086890A (ja) | 2003-08-19 | 2003-08-19 | アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004086890A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012173355A2 (ko) * | 2011-06-17 | 2012-12-20 | (주)네오위즈게임즈 | 게임 서버의 작업 파일 실행 장치 및 방법 |
| US8484237B2 (en) | 2008-04-30 | 2013-07-09 | Nec Corporation | Terminal, web application operating method and program |
-
2003
- 2003-08-19 JP JP2003207781A patent/JP2004086890A/ja not_active Withdrawn
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8484237B2 (en) | 2008-04-30 | 2013-07-09 | Nec Corporation | Terminal, web application operating method and program |
| WO2012173355A2 (ko) * | 2011-06-17 | 2012-12-20 | (주)네오위즈게임즈 | 게임 서버의 작업 파일 실행 장치 및 방법 |
| WO2012173355A3 (ko) * | 2011-06-17 | 2013-03-28 | (주)네오위즈게임즈 | 게임 서버의 작업 파일 실행 장치 및 방법 |
| KR101264615B1 (ko) | 2011-06-17 | 2013-05-27 | (주)네오위즈게임즈 | 게임 서버의 작업 파일 실행 장치 및 방법 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2001184472A (ja) | アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 | |
| CN101965597B (zh) | 用于安装和取回已链接的mifare应用的方法和设备 | |
| TW460847B (en) | IC card, terminal apparatus and service management server | |
| RU2488888C2 (ru) | Способ доступа к приложениям в защищенной мобильной среде | |
| US6761319B2 (en) | Configuration of IC card | |
| US11798359B2 (en) | Blockchain-based smart contract instant lottery ticket | |
| US20020112236A1 (en) | Smart card, method for loyalty program using smart card, and smart card system | |
| CN109847339B (zh) | 控制方法、终端装置、信息处理系统以及存储介质 | |
| US20020069169A1 (en) | Data processing method of smart card system | |
| CN103268249A (zh) | 在移动装置中模拟多张卡的方法和装置 | |
| KR20130104574A (ko) | 유료 아이템 구매에 따른 보상 방법 및 서버 | |
| US20080197186A1 (en) | Settlement server, settlement request server and settlement execution terminal | |
| CN110302541A (zh) | 不同的平台间的游戏数据的移交 | |
| JP2004086890A (ja) | アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体 | |
| JP4729992B2 (ja) | 携帯端末ゲーム制御方法 | |
| JP4579618B2 (ja) | 決済サーバ及び決済依頼サーバ | |
| JP2000207470A (ja) | Ｉｃカ―ド、端末、サ―バ | |
| US20240202705A1 (en) | Method for providing virtual keyboard service that pays cryptocurrency rewards using user wallet provided by service provider and apparatus using the same | |
| JP5367303B2 (ja) | 電子決済システム、電子決済サーバ、移動体通信端末、並びに電子決済方法 | |
| KR20190135360A (ko) | 인비저블 월렛을 이용한 블록체인 무결성 확보방법 | |
| US20230419354A1 (en) | Method for providing virtual keyboard service that pays cryptocurrency rewards and apparatus using the same | |
| JP2004030239A (ja) | アプリケーションの追加制御システム | |
| JP2004030238A (ja) | Ｉｃカード領域貸与管理システム | |
| KR101013162B1 (ko) | 혼용 카드용 애플리케이션 또는 서비스 코드 중계 시스템 | |
| JP2007249544A (ja) | 電子媒体およびそれを含む情報端末 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060421 |
|
| A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20060511 |