JP2004136081A - Ｉｃカード、端末、サーバ - Google Patents
Ｉｃカード、端末、サーバ Download PDFInfo
- Publication number
- JP2004136081A JP2004136081A JP2003207962A JP2003207962A JP2004136081A JP 2004136081 A JP2004136081 A JP 2004136081A JP 2003207962 A JP2003207962 A JP 2003207962A JP 2003207962 A JP2003207962 A JP 2003207962A JP 2004136081 A JP2004136081 A JP 2004136081A
- Authority
- JP
- Japan
- Prior art keywords
- game
- card
- terminal
- pattern
- data
- 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 (33)
- ＩＣカードであって、
端末と接続してデータのやりとりを行う入出力インターフェースと、
複数のアプリケーションプログラムやデータを蓄積するメモリと、
上記アプリケーションプログラムを実行するプロセッサとを有し、
上記メモリは、上記アプリケーションプログラムの一つとして、ゲームアプリケーションプログラムを蓄積し、該ゲームアプリケーションプログラムは、
ゲームパターンを上記メモリに格納し、
上記入出力インターフェースを介して接続された端末のディスプレイに上記ゲームパターンに対応するゲーム実行画面を表示し、
表示されたゲーム実行画面に対してユーザが上記端末に入力したデータを上記入出力インターフェースを介して受けとり、上記ゲームパターン参照して、上記ゲームの実行結果を判定する、
処理を規定することを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
さらに、上記ゲームアプリケーションプログラムは、ユーザがゲームを実行した後、該ゲームに対応する上記ゲームパターンを使用不可能にする処理を規定することを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
上記ゲームパターンは、上記入出力インターフェースに接続された端末から入力されることを特徴とするＩＣカード。 - 請求項３に記載のＩＣカードにおいて、
上記ゲームパターンは暗号化され、
上記ゲームアプリケーションプログラムは、上記ゲームパターンを復号化した後、上記メモリに格納する処理を規定することを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
さらに、上記ゲームアプリケーションプログラムは、上記入出力インターフェースを通じて入力されたゲームの実行回数を定義したデータに応じて上記ゲームパターンを生成する処理を規定することを特徴とするＩＣカード。 - 請求項５に記載のＩＣカードにおいて、
上記ゲームパターンの生成は、上記ＩＣカード内部で生成される乱数に基づいて行われることを特徴とするＩＣカード。 - 請求項５に記載のＩＣカードにおいて、
上記メモリには、ゲームの当たりやすさ、または、ゲームのポイント等を定義したゲームのパラメータデータが格納され、上記ゲームパターンは、該ゲームパラメータに基いて生成されることを特徴とするＩＣカード。 - ＩＣカードであって、
外部とのデータのやりとりを行う入出力インターフェースと、
複数のアプリケーションプログラムやデータを蓄積するメモリと、
上記アプリケーションプログラムを実行するプロセッサとを有し、
上記メモリは、上記アプリケーションプログラムの一つとして、ゲームアプリケーションプログラムを蓄積し、該ゲームアプリケーションプログラムは、
上記入出力インターフェースを介して入力されたゲーム実行回数を定めるデータを上記メモリに格納し、
ゲーム実行回数が残っている場合は、上記入出力インターフェースを介して接続された端末のディスプレイに該ゲームアプリケーションプログラムに対応するゲーム実行画面を表示し、
上記ゲーム実行画面に対応して、ユーザが上記端末に入力したタイミングを上記入出力インターフェースを介して受け取り、
上記タイミングを元に数値を生成してゲームの実行結果を決定し、
上記ゲームの実行後に、上記ゲーム実行回数を減じる、
処理を規定すること特徴とするＩＣカード。 - 請求項８に記載のＩＣカードにおいて、
上記入力のタイミングを元に生成される数値は、該ＩＣカード内で発生される乱数であることを特徴とするＩＣカード。 - 請求項８に記載のＩＣカードにおいて、
上記入力のタイミングを元に生成される数値は、該ＩＣカード内で動作する時計の値であることを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
上記パターンデータは、ユーザに解答を要求する問題と、該問題に対する解答の組のデータから成ることを特徴とするＩＣカード。 - 請求項３に記載のＩＣカードにおいて、
上記ゲームアプリケーションプログラムは、さらに、該ＩＣカードで実行されたゲームに関する履歴情報を上記メモリに保持する処理を規定し、
上記ゲームパターンを上記メモリに格納する処理において、上記履歴情報の内容を参照して上記ゲームパターンの格納するか否かを決定することを特徴とするＩＣカード。 - 請求項５に記載のＩＣカードにおいて、
上記ゲームアプリケーションプログラムは、さらに、該ＩＣカードで実行されたゲームに関する履歴情報を上記メモリに保持する処理を規定し、
上記ゲームパターンを生成する処理において、上記履歴情報の内容を参照して、既に実行されたゲームとは異なるゲームパターンを生成することを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
上記パターンデータを暗号化し、上記入出力インターフェースを通じて該ＩＣカード外部に退避させ、ユーザの指定により、退避させたパターンデータを受け取り、これを復号化した後、上記パターンデータ格納部へ再格納することを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
上記ゲームアプリケーションプログラムにおいて、上記入出力インターフェースを介して接続された端末のディスプレイに上記ゲームパターンに対応するゲームを表示する処理を行う際に、上記パターンデータの一部を選択的に取り出して、上記端末のディスプレイに表示することを特徴とするＩＣカード。 - 請求項１５に記載のＩＣカードにおいて、
上記パターンデータの一部を選択的に取り出す際に、
上記端末から、上記ゲームパターンのどの部分を表示データとして応答すべきかを指定するデータを受け、応答すべき上記パターンデータの部分を取りだすことを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
さらに、上記ゲームアプリケーションプログラムは、上記ゲームの実行結果に応じたポイントを上記メモリに蓄積する処理を規定することを特徴とするＩＣカード。 - 請求項１７に記載のＩＣカードにおいて、
上記入出力インターフェースと接続された店舗端末から、上記入出力インターフェースを介し、ユーザが上記ポイントとの交換を指定したサービスに該当するポイント値の値を受け、これに該当するポイントの値を蓄積されたポイントからを減ずる処理を規定することを特徴とするＩＣカード。 - 請求項２に記載のＩＣカードにおいて、
上記メモリは、ポイントデータの管理を行うポイント管理アプリケーションプログラムを蓄積し、
上記ゲームアプリケーションプログラムは、さらに、上記ポイント管理アプリケーションに対して上記ゲームの実行結果の判定に応じたポイントの値の変更を依頼する処理を規定することを特徴とするＩＣカード。 - 請求項１に記載のＩＣカードにおいて、
上記メモリは、電子マネーの管理を行う電子マネーアプリケーションプログラムを蓄積し、
上記ゲームアプリケーションプログラムは、さらに、上記電子マネーアプリケーションプログラムに対して、上記ゲームの実行結果に応じたポイントの値分の電子マネーの値の変更を依頼することを特徴とするＩＣカード。 - ＩＣカードと接続とのデータのやりとりを行う入出力インターフェースと、
ユーザの入力を受けるユーザ用インタフェースと、
ディスプレイと、
アプリケーションプログラムやデータを格納するメモリと、
上記アプリケーションプログラムを実行するプロセッサとを有し、
上記メモリには、上記アプリケーションプログラムとして、接続するＩＣカードに格納されたゲームアプリケーションプログラムに対応した端末用プログラムが格納され、該端末用プログラムは、
上記ＩＣカードに格納されたゲームアプリケーションプログラムに対応したゲームの実行画面を上記ディスプレイに表示し、
上記ゲームに対してユーザが上記ユーザ用インターフェース端末に入力したデータをＩＣカードに送信し、
接続されたＩＣカードで判定されたゲーム実行の結果を受信して上記ディスプレイに表示する、
処理を規定することを特徴とする端末。 - 請求項２１に記載の端末において、
上記メモリは、あらかじめ暗号化されたパターンデータを格納する暗号化パターンデータ格納部を有し、
接続されたＩＣカードから送信された暗号化済みのゲームパターンを、上記暗号化パターンデータ格納部へ格納し、ユーザの指定により、上記ゲームパターンを接続されたＩＣカードに送信することを特徴とする端末。 - ＩＣカードとのデータのやりとりを行う入出力インターフェースと、
ユーザの入力を受けるユーザ用インタフェースと、
ディスプレイと、
複数のアプリケーションプログラムやデータを格納するメモリと、
上記アプリケーションプログラムを実行するプロセッサとを有し、
上記メモリには、上記アプリケーションの一つとして、ゲームアプリケーションプログラムが格納され、該ゲームアプリケーションプログラムは、
ＩＣカード上で実行されるゲームのゲームパターンを生成し、
該ゲームパターンを上記入出力インタフェースを通じてＩＣカードに送信する処理を規定することを特徴とする端末。 - 請求項２３に記載の端末において、
上記インタフェースを通じてＩＣカードにゲームパターンを送信する際に、該送信データを暗号化してから送信することを特徴とする端末。 - 請求項２３に記載の端末において、
上記ゲームパターンの生成は、上記端末カード内部で生成される乱数に基づいて行われることを特徴とする端末。 - 請求項２３に記載の端末において、
上記メモリに格納されたＩＣカード上で実行可能なゲームの実行回数を定義するデータと、ゲームの当たりやすさやゲームにかかるポイントの値などを定義するゲームパラメータを用いて上記ゲームパターンの生成を行うことを特徴とする端末。 - 請求項２６に記載の端末において、
上記ゲームパラメータは可変であることを特徴とする端末。 - 請求項２３に記載の端末において、
上記インタフェースを通じてＩＣカードから履歴情報を収集して上記メモリに蓄積し、
上記履歴情報の内容に応じて、上記ゲームパターンデータを生成することを特徴とする端末。 - 請求項２３に記載の端末において、
上記インタフェースを通じてＩＣカードから履歴情報を収集して上記メモリに蓄積し、
上記履歴情報の内容に応じて、上記ゲームパラメータの内容を変更することを特徴とする端末。 - ＩＣカードとのデータのやりとりを行う入出力インターフェースと、
複数のアプリケーションプログラムやデータを格納するメモリと、
上記アプリケーションプログラムを実行するプロセッサとを有し、
上記メモリには、上記アプリケーションの一つとして、ゲームアプリケーションプログラムが格納され、該ゲームアプリケーションプログラムは、
ＩＣカード上で実行可能なゲームの実行回数を定義するデータと、ゲームの当たりやすさやゲームにかかるポイントの値などを定義するゲームパラメータとを上記入出力インタフェースを通じてＩＣカードに送信することを規定することを特徴とする端末。 - 請求項２３に記載の端末であって、
さらに上記ゲームアプリケーションプログラムは、
上記入出力インターフェースを介して接続されたＩＣカードに蓄積されたポイントの値を受けとり、
上記ディスプレイに該ポイント値とこれと交換可能なサービスの一覧を表示し、
ユーザが上記ポイントと交換を希望するサービスの指定を上記ユーザ用インターフェースから受け、該サービスに該当するポイントの値を上記ＩＣカードに送信する処理を規定することを特徴とする端末。 - ゲームシステムの運用を管理するサーバであって、
ゲームパターンまたはゲーム実行権をＩＣカードに発行する端末と通信する手段と、上記端末から受け取った、発行されたゲームパターンまたはゲーム実行権に関する履歴情報、ＩＣカードでのゲームの実行結果、ユーザのポイント交換に関する情報を蓄積するデータベースを有し、
上記データベースの内容を解析して、ゲームの当たりやすさやゲームのポイント等を定義したゲームパラメータを生成して上記端末に送信すること特徴とするゲーム管理用サーバ。 - 請求項３２に記載のサーバにおいて、
さらに、現在の日付、ユーザの消費動向等のデータの入力を加味してゲームパラメータの生成を制御することを特徴とするサーバ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003207962A JP2004136081A (ja) | 1998-08-26 | 2003-08-20 | Ｉｃカード、端末、サーバ |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23981298 | 1998-08-26 | ||
| JP32168498 | 1998-11-12 | ||
| JP2003207962A JP2004136081A (ja) | 1998-08-26 | 2003-08-20 | Ｉｃカード、端末、サーバ |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20132099A Division JP2000207470A (ja) | 1998-08-26 | 1999-07-15 | Ｉｃカ―ド、端末、サ―バ |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004136081A true JP2004136081A (ja) | 2004-05-13 |
Family
ID=32475078
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003207962A Withdrawn JP2004136081A (ja) | 1998-08-26 | 2003-08-20 | Ｉｃカード、端末、サーバ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004136081A (ja) |
-
2003
- 2003-08-20 JP JP2003207962A patent/JP2004136081A/ja not_active Withdrawn
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6719634B2 (en) | IC card, terminal device and service management server | |
| US6916246B1 (en) | Voucher-based player terminals for use in a gaming system | |
| US5179517A (en) | Game machine data transfer system utilizing portable data units | |
| AU773340B2 (en) | Electronic prize fulfillment for a gaming system | |
| CN101467183B (zh) | 游戏机上的远程内容管理及资源共享及其实施方法 | |
| KR20150129098A (ko) | 가상화폐 채굴장치가 구비된 게임시스템 | |
| CN109872468A (zh) | 游戏控制装置 | |
| CN105453517A (zh) | 游戏方法和系统 | |
| WO2002005229A2 (en) | Communication of data in a game system | |
| JP4442981B2 (ja) | ゲームパラメータ管理装置および情報記憶媒体 | |
| US20020050683A1 (en) | Network pachinko system, method for playing network pachinko, recording medium recorded program for executing network pachinko, and apparatus used in implementing network pachinko | |
| US20020103030A1 (en) | Game playing system having site connectibility using URL allocated by management server over network | |
| JP2000207470A (ja) | Ｉｃカ―ド、端末、サ―バ | |
| JP2020075156A (ja) | ゲームシステム、及びそれに用いられるコンピュータプログラム | |
| JP2004136081A (ja) | Ｉｃカード、端末、サーバ | |
| JP2003225453A (ja) | 遊技用システム | |
| JP4845260B2 (ja) | ゲーム景品支払いシステム及びゲーム景品支払い方法 | |
| JP3413405B2 (ja) | 業務用処理システムおよび情報記憶媒体 | |
| JP2001300124A (ja) | ネットワークによるゲーム管理システム及び方法並びに記録媒体 | |
| AU758628B2 (en) | Game-type prize drawing system using open network and method thereof | |
| JP7269502B2 (ja) | コンピュータプログラム、およびサーバ装置 | |
| JP2003006721A (ja) | 自動販売機運営システム | |
| JP2001198343A (ja) | 遊技場の景品交換システム | |
| JP4518308B2 (ja) | 遊技用システム | |
| JP2014213046A (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 |