(57)【特許請求の範囲】
【請求項１】
移動通信網を介して通信を行うもので、任意の画面を表示可能な表示器および任意の情報を記憶可能な記憶手段を備えた携帯通信端末を制御するコンピュータを、
前記移動通信網を介して広告データを取得する取得手段と、
前記広告データを前記記憶手段に記憶させる記憶制御手段と、
所定のアプリケーション処理における所定の事象に関連して定まる所定の広告期間に、前記記憶手段に記憶された広告データに基づく広告画面を前記表示器に表示させる広告表示手段と、
前記広告期間に前記アプリケーション処理による前記表示器での画面表示を抑止する表示抑止手段と、
前記取得手段により広告データを取得できない状態が所定期間を越えて継続している場合には前記アプリケーション処理の実行を禁止する禁止手段として機能させるアプリケーションプログラム。
【請求項２】
移動通信網を介して通信を行うもので、任意の画面を表示可能な表示器および任意の情報を記憶可能な記憶手段を備えた携帯通信端末を制御するコンピュータを、
前記移動通信網を介して広告データを取得する取得手段と、
前記広告データを前記記憶手段に記憶させる記憶制御手段と、
所定のアプリケーション処理における所定の事象に関連して定まる所定の広告期間に、前記記憶手段に記憶された広告データに基づく広告画面を前記表示器に表示させる広告表示手段と、
前記広告期間に前記アプリケーション処理による前記表示器での画面表示を抑止する表示抑止手段と、
前記取得手段により前記広告データを取得するための所定の相手との通信が成功しない状態が所定期間を越えて継続している場合には前記アプリケーション処理の実行を禁止する禁止手段として機能させるアプリケーションプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、携帯通信端末にて広告画面を表示させるためのアプリケーションプログラムに関する。
【０００２】
【従来の技術】
携帯通信端末は、移動通信網を介してダウンロードしたアプリケーションプログラムを実行することが可能なものが知られている。
【０００３】
この種の携帯通信端末用のアプリケーションプログラムでは、その開発に関わる対価を回収するために広告が広く利用されている。そして広告を表示するための代表的な方法としてバナー広告が知られている。
【０００４】
【発明が解決しようとする課題】
ところがバナー広告では、アプリケーションでの本来の表示画面中に広告画像を組み込む。このため、表示画面中でアプリケーションのために使用できる領域が小さくなってしまい、画面構成の設計が困難になってしまう。また、バナー広告のために確保できる領域も限られるため、広告効果を有効に発揮することができなかった。特に携帯通信端末の場合、表示器の画面サイズ自体が非常に小さいために、上記の不具合は極めて大きい。
【０００５】
本発明はこのような事情を考慮してなされたものであり、その目的とするところは、携帯通信端末におけるアプリケーションの利用者に対して有効に広告を行うことが可能なアプリケーションプログラムを提供することにある。
【０００６】
【課題を解決するための手段】
以上の目的を達成するために本発明は、移動通信網を介して通信を行うもので、任意の画面を表示可能な表示器および任意の情報を記憶可能な記憶手段を備えた携帯通信端末を制御するコンピュータに、前記移動通信網を介して広告データを取得させ、前記広告データを前記記憶手段に記憶させる。また前記コンピュータに、所定のアプリケーション処理における所定の事象に関連して定まる所定の広告期間に前記記憶手段に記憶された広告データに基づく広告画面を表示するよう前記表示器を制御させるとともに、前記広告期間に前記アプリケーション処理による前記表示器での画面表示を抑止させるようにした。さらに本発明は、広告データを取得できない状態、あるいは前記広告データを取得するための所定の相手との通信が成功しない状態が所定期間を越えて継続している場合には前記アプリケーション処理の実行を禁止するようにした。
【０００７】
このような手段を講じたことにより、アプリケーション処理による表示器での画面表示が一時的に中断され、移動通信網を介して取得された広告データに基づく広告画面の表示が表示器にて行われる。そして広告画面の表示が終わった後に、アプリケーション処理による表示器での画面表示が再開される。従って、アプリケーション処理と関連して広告画面の表示を行っていながら、アプリケーション処理のための表示画面とは全く別個の広告画面を表示できる。そして、広告データを取得できない状態が継続している場合には、アプリケーション処理の実行を制限することができる。
【０００８】
【発明の実施の形態】
以下、図面を参照して本発明の一実施形態につき説明する。
【０００９】
図１は本実施形態に係るシステムの全体構成を示すブロック図である。
【００１０】
この図１に示すようにこのシステムは、携帯通信端末１、アプリケーションは配信サーバ２、広告配信サーバ３、移動通信網４およびインターネット５から構成される。
【００１１】
このシステムは、携帯通信端末１にて任意のアプリケーションプログラムをダウンロードして使用可能とする環境を提供するものである。具体的には、携帯通信端末１からのリクエストに応じて、アプリケーション配信サーバ２からアプリケーションプログラムがダウンロードされるようになっている。この実施形態では、アプリケーションプログラムとして特にＪａｖａ（登録商標）プログラミング言語で記述された「アプレット」と呼ばれるコンピュータプログラムを例に挙げて説明するが、これに限定されることはなく、ネットワーク上でやり取り可能なデータであればこのアプリケーションプログラムの概念に含まれる。
【００１２】
携帯通信端末１は、移動通信網４に無線回線を介して接続される。そして携帯通信端末１は、移動通信網４を介して任意の相手先と通信を行うことが可能である。移動通信網４はパケット通信をサポートしていて、携帯通信端末１はインターネット５を介して任意のサイトにパケット通信を利用してアクセスすることが可能である。
【００１３】
アプリケーション配信サーバ２は、様々なアプリケーションを実現するためのアプレットをインターネット５および移動通信網４を介して携帯通信端末１へと配信する。アプリケーション配信サーバ２はまた、広告データをインターネット５および移動通信網４を介して携帯通信端末１へと配信する。アプリケーション配信サーバ２は上記広告データは、広告配信サーバ３からインターネット５を介して取得する。
【００１４】
広告配信サーバ３は、様々な広告画面を示す広告データを有している。広告配信サーバ３はアプリケーション配信サーバ２を介して携帯通信端末１へと広告データを配信する。
【００１５】
ところで携帯通信端末１は、Ｊａｖａのアプレットをダウンロードおよび実行する機能を有したものである。この種の携帯通信端末としては、例えば株式会社ＮＴＴドコモが提供するｉアプリに対応するＰＤＣ（Personal Digital Cellular）端末などが知られている。
【００１６】
図２は携帯通信端末１のハードウェア構成のブロック図である。
【００１７】
この図２に示すように携帯通信端末１は、ＣＰＵ１０、ＲＯＭ１１、ＲＡＭ１２、ＳＲＡＭ（Static RAM）１３、データ入出力部１４、無線処理部１５、アンテナ１６、音声処理部１７、スピーカ１８、マイクロホン１９、キーパッド２０およびＬＣＤ２１が接続されてなる。
【００１８】
ＲＯＭ１１には種々の制御プログラム等が格納されており、ＣＰＵ１０は、この制御プログラムに基づいて各種制御処理を実行する。その際、ＲＡＭ１２はＣＰＵ１０のワークエリア等として用いられる。ＲＯＭ１１内の制御プログラムには、携帯通信端末１の基本動作をサポートするファームウェアの他、ブラウザや後述する各種アプリケーションが含まれる。ＳＲＡＭ１３は、インターネット５を介して取得したウェブページをキャッシュする。またＳＲＡＭ１３は、インターネット５を介してダウンロードしたアプリケーションを記憶する。
【００１９】
無線処理部１５は、図示しない周波数シンセサイザ、増幅器、変復調回路等を含み、アンテナ１６を介して送受信される信号に対して、フレーム同期・分離および誤り検出・訂正処理等の周知の無線処理を実行する。これにより無線処理部１５は、移動通信網４に含まれる基地局（図示せず）との無線通信を実現する。なお無線処理部１５は、回線交換によって伝送される信号と、パケット交換によって伝送される信号とにそれぞれ対応した処理を行うことが可能である。無線処理部１５によって処理されるデータは、データ入出力部１４を介してＣＰＵ１０に入出力される。
【００２０】
音声処理部１７は、スピーカ１８およびマイクロホン１９に接続されている。音声処理部１７は、音声信号に対して所定の処理を施す。キーパッド２０は、利用者が各種操作を行うための入力インタフェイスである。ＬＣＤ２１は、各種情報を表示するための表示インタフェイスである。
【００２１】
次に、図３を参照しながら携帯通信端末１のプロセス構成について説明する。図３に示すように、プロセス構成の最下層は、携帯通信端末１のハードウェア制御に関するキーインタフェイス部１０１、画面インタフェイス部１０２、データ通信ドライバ１０３、スピーカ・マイク制御部１０４、メモリインタフェイス部１０５によって構成される。
【００２２】
その上層は、ファームウェア１１１によって構成される。このファームウェア１１１により携帯通信端末１の基本的な処理がサポートされる。
【００２３】
さらにその上層は、Ｊａｖａバーチャルマシン１２１、ブラウザ１２２、電話機能部１２３、設定部１２４によって構成されている。
【００２４】
Ｊａｖａバーチャルマシン１２１の上層には、Ｊａｖａアプレット１３１が構成される。Ｊａｖａアプレットは、Ｊａｖａによって記述されたアプリケーションプログラムである。Ｊａｖａアプレットは、アプリケーション配信サーバ２などから携帯通信端末１にダウンロードされ、Ｊａｖａバーチャルマシン１２１上で実行される。
【００２５】
さて、図１に示すシステムでは、アプリケーション配信サーバ２からはゲームなどのような様々なアプリケーションが携帯通信端末１へと配信される。しかし、アプリケーション配信サーバ２が実際に配信するＪａｖａアプレットは、上記のアプリケーションを実現するための主プログラムと広告プログラムとを結合して構成されるものとする。
【００２６】
広告プログラムは、主プログラムに基づいて実現されるアプリケーションの利用者に対して広告を行うための処理を携帯通信端末１のＣＰＵ１０に行わせるものである。この広告プログラムは、ＣＰＵ１０を取得部、記憶制御部、広告表示部、表示抑止部、終了抑止部、要求部、通知部および禁止部として機能させる。
【００２７】
取得部は、広告配信サーバ３から配信されている広告データをアプリケーション配信サーバ２を介して取得する。
【００２８】
記憶制御部は、取得部により取得された広告データをＳＲＡＭ１３へと記憶させる。広告データは、広告コード、有効期限、ＵＲＬおよび画面データからなる。記憶制御部は、これらの情報にその広告データを取得した日時の情報を付加して図４に示すような状態でＳＲＡＭ１３へと記憶させる。なお広告コードは、広告データを一意に識別するためのコードである。有効期限は、その広告データを使用することができる期限である。ＵＲＬは、その広告データに関するサイトのアドレスである。画面データは広告画面を示すデータである。画面データは、図５（ａ）〜図５（ｃ）に示す３種類のデータブロックを１つ以上含んで構成される。
【００２９】
広告表示部は、主プログラムによるアプリケーション処理に連動した所定のタイミング（後述する）にてＬＣＤ２１に広告画面を表示させる。
【００３０】
表示抑止部は、広告表示部により広告画面の表示を行っている期間に主プログラムによるアプリケーション処理によりＬＣＤ２１での画面表示が行われることを抑止する。
【００３１】
終了抑止部は、広告表示部により広告画面の表示を行っている期間に主プログラムによるアプリケーション処理の終了処理が行われることを抑止する。
【００３２】
要求部は、広告データに示されたＵＲＬへのアクセスをブラウザ１２２に対して要求する。
【００３３】
通知部は、広告画面の表示およびＵＲＬへのアクセスの要求を行った履歴をアプリケーション配信サーバ２へと通知する。通知部はこの通知を行うために、図６に示すようなイベント履歴を作成する。
【００３４】
そして禁止部は、取得部による広告データの取得がある期間を越えて行えていない場合に、アプリケーション処理の実行を禁止する。
【００３５】
次に動作につき説明する。
【００３６】
携帯通信端末１からアプリケーション配信サーバ２にアクセスし、アプリケーションの配信を要求すると、アプリケーション配信サーバ２は要求されたアプリケーションを実現する主プログラムを持つＪａｖａアプレットを携帯通信端末１へとダウンロードする。携帯通信端末１では、ダウンロードしたＪａｖａアプレットをＳＲＡＭ１３へと格納しておく。このＪａｖａアプレットは、ユーザからの実行指示に応じてＳＲＡＭ１３により読み出され、Ｊａｖａバーチャルマシン１２１上で実行される。
【００３７】
以下、ゲームを実現する主プログラムを持つＪａｖａアプレットが実行される場合を例にとって具体的な動作を説明する。
【００３８】
まずＪａｖａアプレットの実行が指示されたならば、主プログラムに基づく図７に示すようなゲームアプリケーション処理が開始される。
【００３９】
ＣＰＵ１０はまずステップＳＴ１において、初期化を行う。この初期化が完了したならばＣＰＵ１０は、広告プログラムに基づく広告処理を起動する。ＣＰＵ１０は、ゲームアプリケーション処理により広告処理が起動された場合には、ゲームアプリケーション処理に並行して広告プログラムに基づく広告処理を実行する。
【００４０】
一方、ＣＰＵ１０はゲームアプリケーション処理では、ステップＳＴ３において、主プログラムに含まれているゲームデータを読み込んで、初期データを作成する。この初期データの作成を終了したならばＣＰＵ１０はステップＳＴ４において、メイン側終了フラグをセットする。そしてこの上でＣＰＵ１０はステップＳＴ５において、ステップＳＴ２にて起動した広告処理が終了するのを待ち受ける。なおメイン側終了フラグは、例えばＲＡＭ１２に記憶される。このようにして、ゲームアプリケーション処理の起動時には、初期化および初期データの作成はまず行われるが、それ以降の処理は広告処理が終了するまでは行われない。
【００４１】
広告処理が終了したことをステップＳＴ５にて確認したならば、ＣＰＵ１０はステップＳＴ６において、初期のゲーム画面をＬＣＤ２１に表示させる。そしてこの後にＣＰＵ１０はステップＳＴ７において、ゲームをユーザに行わせるためのゲーム処理を開始する。
【００４２】
このゲーム処理を行いながらＣＰＵ１０はステップＳＴ８乃至ステップＳＴ１０において、ゲームの１面がクリアとなるか、ゲームオーバーとなるか、あるいはゲーム終了が指示されるのを待ち受ける。
【００４３】
１面がクリアとなったことをステップＳＴ８にて確認したならば、ＣＰＵ１０はステップＳＴ１１において、面クリア処理を実行する。
【００４４】
図８は面クリア処理の詳細を示すフローチャートである。
【００４５】
ＣＰＵ１０はまずステップＳＴ２１において、広告処理を起動する。続いてＣＰＵ１０はステップＳＴ２２において、ゲームの次面のデータを読み込んでおく。そしてここでデータを読み込み終えたならばＣＰＵ１０はステップＳＴ２３において、メイン側終了フラグをセットする。そしてこの上でＣＰＵ１０はステップＳＴ２４において、ステップＳＴ２１にて起動した広告処理が終了するのを待ち受ける。このように、この実施形態のゲームアプリケーションは、１面がクリアされる毎にゲーム画面の切り替えが行われるのであるが、面クリアに伴って次面データの読み込みはまず行われるが、広告処理が終了するまで次面のゲーム画面の表示は行われない。
【００４６】
広告処理が終了したことをステップＳＴ２４にて確認したならば、ＣＰＵ１０はステップＳＴ２５において、ゲームの次面の画面をＬＣＤ２１に表示させる。そしてこの後にＣＰＵ１０はステップＳＴ７以降の処理を繰り返す。
【００４７】
ところで、ゲームオーバーとなったことをステップＳＴ９にて確認したならば、ＣＰＵ１０はステップＳＴ１２においてゲームオーバー処理を実行する。
【００４８】
図９はゲームオーバー処理の詳細を示すフローチャートである。
【００４９】
ＣＰＵ１０はまずステップＳＴ３１において、広告処理を起動する。続いてＣＰＵ１０はステップＳＴ３２において、ゲームオーバーとなったゲームの結果がハイスコアであったか否かを確認する。ここでハイスコアであったことを確認したならばＣＰＵ１０は、ゲームのスコア等を示すハイスコア情報の送信を開始する。ＣＰＵ１０はこのハイスコア情報の送信が完了するのをステップＳＴ３４において待ち受ける。そしてＣＰＵ１０はハイスコア情報の送信が完了したならばステップＳＴ３５において、メイン側終了フラグをセットする。そしてこの上でＣＰＵ１０はステップＳＴ３６において、ステップＳＴ３１にて起動した広告処理が終了するのを待ち受ける。このように、この実施形態のゲームアプリケーションは、ハイスコアを達成した場合にはハイスコア情報の送信が行われるのであるが、このときには広告処理が並行して実行されるのである。そしてハイスコア情報の送信が完了しても、広告処理が終了するまではゲームアプリケーション処理における次の処理は行われない。
【００５０】
広告処理が終了したことをステップＳＴ３６にて確認したならば、ＣＰＵ１０はステップＳＴ３７において、ハイスコア送信完了画面をＬＣＤ２１に表示させる。ハイスコア送信完了画面は、ハイスコア情報の送信が完了したことをユーザに対して通知するものである。そしてこのハイスコア送信完了画面の表示を確認したユーザは、確認したことを示す所定のキー入力を行うことになっている。そこでＣＰＵ１０はステップＳＴ３８において、上記のキー入力がなされるのを待ち受ける。そして上記のキー入力がなされたことを確認したならば、ＣＰＵ１０はゲームオーバー処理を終了する。
【００５１】
さて、ハイスコアではなかったことをステップＳＴ３２にて確認したならば、ＣＰＵ１０はステップＳＴ３９において、メイン側終了フラグをセットする。そしてこの上でＣＰＵ１０はステップＳＴ４０において、ステップＳＴ３１にて起動した広告処理が終了するのを待ち受ける。このように、ハイスコアが達成されない場合にはハイスコア情報の送信を行わないのであるが、広告処理が終了するまではゲームアプリケーション処理における次の処理は行われない。そして広告処理が終了したことをステップＳＴ４０にて確認したならば、ＣＰＵ１０はゲームオーバー処理を終了する。
【００５２】
ゲームオーバー処理を終了したならば、ＣＰＵ１０はステップＳＴ６以降の処理を繰り返すことにより、最初からゲームをやり直すことを可能とする。
【００５３】
ところで、ゲーム終了が指示されたことをステップＳＴ１０にて確認した場合、ＣＰＵ１０はステップＳＴ１３において、終了処理を実行する。
【００５４】
図１０は終了処理の詳細を示すフローチャートである。
【００５５】
ＣＰＵ１０はまずステップＳＴ４１において、広告処理を起動する。続いてＣＰＵ１０はステップＳＴ４２において、メイン側終了フラグをセットする。そしてこの上でＣＰＵ１０はステップＳＴ４３において、ステップＳＴ４１にて起動した広告処理が終了するのを待ち受ける。このように、ゲームアプリケーション処理を終了する前には広告処理を行い、この広告処理が終了するまではゲームアプリケーション処理における次の処理は行われない。
【００５６】
広告処理が終了したことをステップＳＴ４３にて確認したならば、ＣＰＵ１０はステップＳＴ４４において、ゲームアプリケーションを終了するためのアプリケーション終了処理を行い、これをもって終了処理を終了する。ステップＳＴ１３での終了処理が以上のようにして終了したならば、ＣＰＵ１０はそれをもってゲームアプリケーション処理を終了する。
【００５７】
以上のようにゲームアプリケーション処理を行う最中に広告処理が起動され、広告処理が終了されるまではゲームアプリケーション処理はＬＣＤ２１への画面表示を行わない状態が維持される。
【００５８】
次に広告処理について詳しく説明する。
【００５９】
図１１は広告処理の詳細を示すフローチャートである。
【００６０】
ＣＰＵ１０はまずステップＳＴ５１において、ＳＲＡＭ１３に記憶されている広告データのうちに有効期限が過ぎたものが存在するならば、その広告データをＳＲＡＭ１３から削除する。次にＣＰＵ１０はステップＳＴ５２において、ＳＲＡＭ１３に広告データが記憶されているか否かを確認する。そしてもしＳＲＡＭ１３に広告データが記憶されていることを確認したならば、ＣＰＵ１０はステップＳＴ５３において、そのＳＲＡＭ１３に記憶されている広告データのうちの１つを選択する。ＳＲＡＭ１３に複数の広告データが記憶されている場合、広告データの選択はランダムであっても良いし、所定の順序に従って行っても良い。これに対してＳＲＡＭ１３に広告データが記憶されていないことを確認したならば、ＣＰＵ１０はステップＳＴ５４において、デフォルトの広告データを選択する。
【００６１】
ステップＳＴ５３またはステップＳＴ５４を終了したならば、続いてＣＰＵ１０はステップＳＴ５５において、広告データの取得処理を実行する。
【００６２】
図１２は広告データ取得処理の詳細を示すフローチャートである。
【００６３】
ＣＰＵ１０はまずステップＳＴ７１において、ＳＲＡＭ１３にイベント履歴の情報が記憶されているか否かを確認する。そしてイベント履歴が記憶されていることを確認したならば、ＣＰＵ１０はステップＳＴ７２において、イベント履歴をアプリケーション配信サーバ２に対して送信する。
【００６４】
アプリケーション配信サーバ２は図１３に示すように、携帯通信端末１からイベント履歴が送られてきたならば、それを広告配信サーバ３へと転送する。これに対して広告配信サーバ３は、イベント履歴を正常に受信できたか否かを示した確認通知をアプリケーション配信サーバ２へと返す。アプリケーション配信サーバ２は、この確認通知を携帯通信端末１へと転送する。
【００６５】
さて携帯通信端末１においては、ステップＳＴ７２を終了させた後に、あるいはイベント履歴が記憶されていないことをステップＳＴ７１にて確認した場合に、ＣＰＵ１０はステップＳＴ７３において、イベント履歴の送信が成功であったか否かを、上述のようにアプリケーション配信サーバ２から送られてくる確認通知に基づいて確認する。そしてイベント履歴の送信が成功であったことを確認したならば、ＣＰＵ１０はステップＳＴ７４において、取得条件が成立しているか否かを確認する。取得条件とは、広告データの取得を行うべきタイミングを規定したものである。その内容は、例えば「１日１回」や「最終取得日から２日が経過している」のようなものが事前に任意に設定される。
【００６６】
取得条件が成立していることをステップＳＴ７４にて確認したならば、ＣＰＵ１０はステップＳＴ７５において、広告データの配信の要求と、これに応じて送られてくる広告データの受信を行う。具体的には図１３に示すように、携帯通信端末１からはアプリケーション配信サーバ２に対して広告配信要求を送る。そうするとアプリケーション配信サーバ２は、その広告配信要求を広告配信サーバ３へと転送する。広告配信要求を受けると広告配信サーバ３は、自己に登録されている広告データのうちからいくつかを抽出し、それを含めた広告配信応答をアプリケーション配信サーバ２へと送信する。アプリケーション配信サーバ２は、この広告配信応答を携帯通信端末１へと転送する。
【００６７】
なお、以上のように携帯通信端末１がイベント情報や広告データを授受する相手は最終的には広告配信サーバ３となっているのに、アプリケーション配信サーバ２を介在させているのは、Ｊａｖａアプレットに基づく処理では、そのＪａｖａアプレットを配信したサーバとの通信しか行えないことが規定されているからである。
【００６８】
続いてＣＰＵ１０はステップＳＴ７６において、広告配信応答の受信に成功したか否かを確認する。そして広告配信応答の受信に成功したことを確認したならば、ＣＰＵ１０はその広告配信応答に有効な広告データが正しく含まれているか否かを確認する。有効な広告データが含まれていることを確認したならば、ＣＰＵ１０はステップＳＴ７８において、その広告データをＳＲＡＭ１３へと記憶させる。そして広告データの保存が終了したならば、ＣＰＵ１０はステップＳＴ７９において、ＳＲＡＭ１３に記憶してある最終取得日時の情報を現在日時を示すものに更新し、これをもって広告データ取得処理を終了する。
【００６９】
なお、有効な広告データが含まれていないことをステップＳＴ７７にて確認したならば、ＣＰＵ１０はステップＳＴ７８およびステップＳＴ７９の処理を行うことなしに広告データ取得処理を終了する。また、イベント履歴の送信に失敗したことをステップＳＴ７３にて確認した場合、あるいは取得条件が成立していないことをステップＳＴ７４にて確認した場合、ＣＰＵ１０はステップＳＴ７５乃至ステップＳＴ７９の処理を行うことなしに、すなわち広告データの取得を行うことなしに広告データ取得処理を終了する。
【００７０】
このように広告データ取得処理が終了したならば、ＣＰＵ１０は続いてステップＳＴ５６において、広告データを取得できていない期間（未取得期間）が予め定めた限度値以下であるか否かを確認する。ここで未取得期間が限度値以下であることが確認できたならば、ＣＰＵ１０はステップＳＴ５７において、ＳＲＡＭ１３に記憶されている広告データの１つを読み込む。次にＣＰＵ１０はステップＳＴ５８において、広告処理が未完了であることを示すために、広告側終了フラグをクリアする。広告側終了フラグは、例えばＲＡＭ１２に記憶される。続いてＣＰＵ１０はステップＳＴ５９において、イベント履歴を更新する。具体的には、ステップＳＴ５７にて読み出した広告データの広告コードに対応付けて、イベント日時として現在日時を、またイベント内容として「表示」をそれぞれ設定したレコードをイベント履歴に追加する。
【００７１】
こののちにＣＰＵ１０はステップＳＴ６０において、ステップＳＴ５７にて読み込んだ広告データに含まれる最初の画面データに基づく広告画面を一定時間に渡りＬＣＤ２１に表示させる。この一定時間の広告画面の表示が終了したならば、ＣＰＵ１０はステップＳＴ６１において、ステップＳＴ５７にて読み込んだ広告データに含まれる全ての画面データに基づく広告画面の全ての表示が完了したか否かを確認する。ここでまだ広告表示が完了していないことを確認したならば、ＣＰＵ１０はステップＳＴ６２において、表示した広告画面に示されているリンクをクリックするキー入力が行われたか否かを確認する。そしてそのキー入力が行われていないことを確認したならば、ＣＰＵ１０はステップＳＴ６３において、ステップＳＴ５７にて読み込んだ広告データに含まれる次の画面データに基づく広告画面を一定時間に渡りＬＣＤ２１に表示させる。この一定時間の広告画面の表示が終了したならば、ＣＰＵ１０は処理をステップＳＴ６１に戻し、ステップＳＴ６１以降の処理を繰り返す。
【００７２】
さて、ステップＳＴ５７にて読み込んだ広告データに含まれる最後の画面データに基づく広告画面の表示をステップＳＴ６３にて行ったならば、ＣＰＵ１０は次にステップＳＴ６１にて広告表示が完了したことを確認することになる。この場合にＣＰＵ１０はステップＳＴ６４およびステップＳＴ６５において、メイン側、すなわちここではゲームアプリケーション処理側の処理が終了するか、あるいは表示した広告画面に示されているリンクをクリックするキー入力が行われるのを待ち受ける。
【００７３】
メイン側の処理が終了したか否かの確認は、メイン側終了フラグの状態を確認することで行われる。そして、メイン側終了フラグがセットされたならば、ＣＰＵ１０はメイン側の処理が終了したと判定する。この場合にＣＰＵ１０はステップＳＴ６６において、広告側終了フラグをセットし、これをもって広告処理を終了する。
【００７４】
このように広告側終了フラグをセットしたならば、ＣＰＵ１０はゲームアプリケーション処理におけるステップＳＴ５、ステップＳＴ２４、ステップＳＴ３６、ステップＳＴ４０またはステップＳＴ４３にて広告処理が終了したと確認することが可能となる。従って、ステップＳＴ６６の処理を経て広告処理が終了されたことに応じて、停止されていたゲームアプリケーション処理の処理が再開される。
【００７５】
これに対して、ステップＳＴ６２またはステップＳＴ６５にてキー入力がなされたことを確認した場合には、ＣＰＵ１０はステップＳＴ６７において、イベント履歴を更新する。具体的には、ステップＳＴ５７にて読み出した広告データの広告コードに対応付けて、イベント日時として現在日時を、またイベント内容として「クリック」をそれぞれ設定したレコードをイベント履歴に追加する。そしてこの後にＣＰＵ１０はステップＳＴ６８において、ステップＳＴ６２またはステップＳＴ６５にて確認されたキー入力が指定するリンクのリンク先のＵＲＬへのアクセスをブラウザ１２２に対して要求する。そしてこれをもってＣＰＵ１０は広告処理を終了する。
【００７６】
なお、ステップＳＴ６２における要求に基づいてブラウザ１２２が起動される。このブラウザ１２２の起動に伴って、ゲームアプリケーション処理のようなＪａｖａアプレットに基づくアプリケーション処理は強制終了される。
【００７７】
ところで、未取得期間が長期間に及んでいて、限度値以上となっていることをステップＳＴ５６で確認することとなった場合には、ＣＰＵ１０はステップＳＴ６９にて警告画面をＬＣＤ２１に表示させる。この警告画面は、広告データを取得できていないために、アプリケーションを利用することができない旨をユーザに対して報知するものである。そしてこの警告画面を表示させた状態で、ＣＰＵ１０はステップＳＴ７０において、アプリケーションの強制終了をユーザが指示するのを待ち受ける。そしてアプリケーションの強制終了の指示がなされたことを確認したならば、ＣＰＵ１０はそれをもって広告処理を終了する。この場合には、ゲームアプリケーション処理も強制終了される。
【００７８】
以上のように本実施形態によれば、Ｊａｖａアプリケーションの処理の中で次の４つの事象のいずれかが生じたならば、広告処理が起動される。
(1)  Ｊａｖａアプリケーションの起動。
(2)  Ｊａｖａアプリケーションによる表示画面の切り替え。
(3)  Ｊａｖａアプリケーションによる通信。
(4)  Ｊａｖａアプリケーションの終了。
【００７９】
そして広告処理が終了するまでは、Ｊａｖａアプリケーションの中の画面表示を伴う処理を行わないように、Ｊａｖａアプリケーションの処理を停止させる。
【００８０】
広告処理では、広告配信サーバ３からアプリケーション配信サーバ２を介して取得した広告データに基づく広告画面の表示が行われる。このとき、広告画面はＪａｖａアプリケーションの画面表示とは無関係に行うことが可能であるから、ＬＣＤ２１の表示領域を自由に利用した画面とすることが可能である。このため、広告画面の設計の自由度が高くなり、見易く、かつ広告効果の高い広告画面を容易に設計できるようになる。
【００８１】
Ｊａｖａアプリケーションの処理は、広告処理が正常に終了しなければ再開されない。つまり、広告画面の表示を経なければ、Ｊａｖａアプリケーションを継続的に利用することができない。このため、Ｊａｖａアプリケーションのための表示画面中に広告画像を組み込まなくとも、Ｊａｖａアプリケーションの利用者に広告画面を確実に提示することが可能である。従って、Ｊａｖａアプリケーションのための表示画面は広告とは無関係に設計することが可能であるから、ＬＣＤ２１の表示領域を自由に利用した画面とすることが可能である。この結果、Ｊａｖａアプリケーションのための表示画面の設計の自由度が高くなる。
【００８２】
また本実施形態によれば、携帯通信端末１は、広告画面中に設定されたリンクがクリックされたならば、そのリンクのリンク先のアドレスへのアクセスをブラウザにより行うようにしており、しかも上記のクリックが行われたことを示したイベント履歴をアプリケーション配信サーバ２へと送信している。そして本実施形態ではさらに、アプリケーション配信サーバ２がイベント履歴を広告配信サーバ３へと転送している。このため、アプリケーション配信サーバ２や広告配信サーバ３では、広告に基づくウェブアクセスの実行状況を管理することが可能となり、例えば広告の利用度を調査するなどの応用が可能となる。
【００８３】
また本実施形態によれば、携帯通信端末１は、広告処理によりどの広告データに基づく広告画面の表示を行ったかを示すイベント履歴をアプリケーション配信サーバ２へと送信している。そして本実施形態ではさらに、アプリケーション配信サーバ２がイベント履歴を広告配信サーバ３へと転送している。このため、このため、アプリケーション配信サーバ２や広告配信サーバ３では、広告表示の実際の実行状況を管理することが可能となり、例えば広告の表示回数をカウントするなどの応用が可能となる。
【００８４】
また本実施形態によれば、携帯通信端末１では、広告のクリックや表示に関する情報を履歴情報（イベント履歴）として収集しておき、この履歴情報を送信するようにしている。このため、広告表示や広告内のリンクのクリックが行われる度に通信を行う必要は無く、上記の情報を効率的に送信することが可能である。しかも本実施形態では、携帯通信端末１は、イベント履歴は広告データを取得する際に送信するようにしているので、さらに通信回数を減じることが可能となっている。
【００８５】
また本実施形態によれば、携帯通信端末１では、広告処理を起動する毎に、所定の取得条件が成立しているならば広告データの取得を試みるようにしている。従って、携帯通信端末１はある程度周期的に広告データの取得を試みることとなり、最新の広告データをダウンロードしておくことができる。この結果、最新の広告データに基づく適正な広告表示が行える。
【００８６】
しかも本実施形態では、携帯通信端末１では、広告データの最終取得タイミングから次に広告データの取得を試みるまでにある程度の時間を置くようにしている。このため、必要以上に頻繁に広告データの取得を試みてしまうことがなく、無駄な通信が生じることがない。
【００８７】
また本実施形態によれば、広告データに有効期限を設定してあり、携帯通信端末１では取得して記憶してある広告データが有効期限を過ぎているならば、その広告データは削除して広告表示に用いないようにしている。このため、古くなって有効ではなくなった広告画面の表示が無意味に行われてしまうことがない。
【００８８】
また本実施形態によれば、携帯通信端末１では、ダウンロードしてＳＲＡＭ１３に記憶されている広告データが無い場合には、予め用意されたデフォルトの広告データに基づく広告画面の表示を行うようにしている。このため、インターネット５を介しての広告データの取得が行えていない状況にあっても、広告表示は支障無く行うことが可能である。
【００８９】
また本実施形態によれば、広告表示を行う期間を、１つの広告データが示す全ての広告画面の表示が完了するまでとしている。このため、複数の画面からなる広告効果の高い広告を表示することが可能である。
【００９０】
また本実施形態によれば、広告データを新たに取得できない期間が限度値を越えるほどに継続する場合には、携帯通信端末１では広告処理からアプリケーションのメイン処理へと処理を戻さないようにしている。このため、例えば携帯通信端末１が移動通信網４のサービス圏外に長期間に渡り存在するなどの理由により携帯通信端末１にて広告データを取得できない状態が継続している場合には、アプリケーションの利用を制限することができる。
【００９１】
なお、本発明は上記実施形態に限定されるものではない。例えば本発明に係るアプリケーションプログラムはＪａｖａアプレットとして実現されるものには限定されず、任意の形態のプログラムであって良い。
【００９２】
アプリケーション処理により実現されるアプリケーションは、例えば株価表示などのようにゲーム以外であっても良い。
【００９３】
また、広告処理を実行するタイミングは、上記実施形態に示す４種類のタイミングのうちの少なくとも１つを含んでいれば良い。
【００９４】
１つの広告データにリンク先が異なる複数のリンクが設定されていても良い。またリンク先はＷＷＷ（World Wide Web）のサイトには限らず、他のネットワークであっても良く、従ってリンク先のアドレスもＵＲＬには限らない。
【００９５】
広告内のリンクがクリックされた際におけるそのリンク先へのアクセスおよびリンク先から配信される情報の表示のための処理を本発明のアプリケーションプログラムに基づいて行わせるようにしても良い。
【００９６】
また、広告表示や広告内のリンクのクリックの通知は、それらのイベントが発生する毎に送信するようにしても良い。また履歴情報として送信する場合でも、広告表示に関する履歴情報と広告内のリンクのクリックに関する履歴情報とを別々に作成して、別々に送信するようにしても良い。そして、これらのような、あるいはイベント履歴のような履歴情報として送信する場合、その送信は広告データの取得とは無関係に行っても良い。
【００９７】
また、イベント履歴の送信先は、アプリケーション配信サーバ２には限らず、広告配信サーバ３に直接的に送信するようにしても良いし、あるいは全く別の通知先に対して送信するようにしても良い。また、広告表示の通知と広告内のリンクのクリックの通知とを別々の通知先に対して送信するようにしても良い。
【００９８】
また、アプリケーション配信サーバ２から広告配信応答を受けることに成功したのに、その広告配信応答に広告データが含まれていない場合は、広告データは取得できていなくとも、携帯通信端末１側では正規の動作を行っていると言える。そこで、広告配信応答を受けることができたならば最終取得日時を更新するようにしても良い。このようにすれば、広告配信サーバ３が配信する広告データがない状況にあるときに、携帯通信端末１が不必要に短い周期で繰り返し広告データの取得を試みてしまうことが防止でき、携帯通信端末１のユーザに不要な通信費用を負担させてしまうことが無くなる。また、実際に広告データの取得が限度値を越える期間に渡り行えていないとしても、アプリケーション配信サーバ２との通信が正常に行えている限度値を越えない間隔で行われている限りはアプリケーション処理を実行できる。
【００９９】
また、広告データの取得を試みるタイミングは、例えば携帯通信端末１の電源が投入される毎や、一定時間毎などのように任意に変更が可能である。
【０１００】
また、例えば、広告表示に１回用いた広告データはＳＲＡＭ１３から削除するようにすれば、広告データの有効期限の管理を省略することも可能である。
【０１０１】
また、ダウンロードされた広告データがＳＲＡＭ１３に記憶されていない場合には、広告表示を行わないようにしても良い。
【０１０２】
また、広告表示を行う期間は、例えば一定期間とするなどのように任意に変更が可能である。
【０１０３】
このほか、本発明の要旨を逸脱しない範囲で種々の変形実施が可能である。
【０１０４】
【発明の効果】
本発明によれば、アプリケーション処理による表示器での画面表示を所定のタイミングで一時的に中断し、移動通信網を介して取得された広告データに基づく広告画面の表示を表示器にて行う。そして広告画面の表示が終わった後に、アプリケーション処理による表示器での画面表示を再開することとしたので、アプリケーション処理と関連して広告画面の表示を行っていながら、アプリケーション処理のための表示画面とは全く別個の広告画面を表示できる。さらには、広告データを取得できない状態、あるいは前記広告データを取得するための所定の相手との通信が成功しない状態が所定期間を越えて継続している場合には前記アプリケーション処理の実行を禁止することができる。この結果、携帯通信端末におけるアプリケーションの利用者に対して有効に広告を行うことが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るシステムの全体構成を示すブロック図。
【図２】携帯通信端末１のハードウェア構成のブロック図。
【図３】携帯通信端末１のプロセス構成を示す図。
【図４】広告データのＳＲＡＭ１３での記憶状態を示す図。
【図５】広告データに含まれるデータブロックの具体例を示す図。
【図６】イベント履歴の構成を示す図。
【図７】ゲームアプリケーション処理のフローチャート。
【図８】面クリア処理の詳細を示すフローチャート。
【図９】ゲームオーバー処理の詳細を示すフローチャート。
【図１０】終了処理の詳細を示すフローチャート。
【図１１】広告処理の詳細を示すフローチャート。
【図１２】広告データ取得処理の詳細を示すフローチャート。
【図１３】携帯通信端末１が広告データを取得する際のシーケンスを示す図。
【符号の説明】
１…携帯通信端末
２…アプリケーション配信サーバ
３…広告配信サーバ
４…移動通信網
５…インターネット
１０…ＣＰＵ
１１…ＲＯＭ
１２…ＲＡＭ
１３…ＳＲＡＭ
１１１…ファームウェア
１２１…Ｊａｖａバーチャルマシン
１２２…ブラウザ
１３１…Ｊａｖａアプレット
【図１】
0003732153.tif 000002
【図２】
0003732153.tif 000003
【図３】
0003732153.tif 000004
【図４】
0003732153.tif 000005
【図５】
0003732153.tif 000006
【図６】
0003732153.tif 000007
【図７】
0003732153.tif 000008
【図８】
0003732153.tif 000009
【図９】
0003732153.tif 000010
【図１０】
0003732153.tif 000011
【図１１】
0003732153.tif 000012
【図１２】
0003732153.tif 000013
【図１３】
0003732153.tif 000014