特許 5698205 プログラム及びプログラム配信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5698205

(24)【登録日】2015年2月20日

(45)【発行日】2015年4月8日

(54)【発明の名称】プログラム及びプログラム配信方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20150319BHJP

   G06F 9/445 20060101ALI20150319BHJP

【ＦＩ】

   G06F13/00 530A

   G06F9/06 610Q

   G06F13/00 550L

【請求項の数】4

【全頁数】16

(21)【出願番号】特願2012-237191(P2012-237191)

(22)【出願日】2012年10月26日

(65)【公開番号】特開2014-86047(P2014-86047A)

(43)【公開日】2014年5月12日

【審査請求日】2014年6月30日

【早期審査対象出願】

(73)【特許権者】

【識別番号】504437801

【氏名又は名称】グリー株式会社

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】100164471

【弁理士】

【氏名又は名称】岡野 大和

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100088683

【弁理士】

【氏名又は名称】中村 誠

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100095441

【弁理士】

【氏名又は名称】白根 俊郎

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100119976

【弁理士】

【氏名又は名称】幸長 保次郎

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100172580

【弁理士】

【氏名又は名称】赤穂 隆雄

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100124394

【弁理士】

【氏名又は名称】佐藤 立志

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(74)【代理人】

【識別番号】100111073

【弁理士】

【氏名又は名称】堀内 美保子

(74)【代理人】

【識別番号】100134290

【弁理士】

【氏名又は名称】竹内 将訓

(72)【発明者】

【氏名】ゴールド・ロバート・ジェイ

(72)【発明者】

【氏名】久富木 隆一

【審査官】 小林 義晴

(56)【参考文献】

【文献】 特開２００４−３６２０９０（ＪＰ，Ａ）

【文献】 特開平０７−２２５７２４（ＪＰ，Ａ）

【文献】 特開２００５−３４６５１９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ ９／４４５

(57)【特許請求の範囲】

【請求項1】

クライアント機と通信可能な情報処理装置に、
前記クライアント機から当該クライアント機のスクリーンＤＰＩを示す情報を取得するステップと、
アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
前記情報に応じた前記画像表示処理は、前記スクリーンＤＰＩが所定値未満である場合、上層レイヤーを不透明表示するプログラム。

【請求項2】

前記情報に応じた前記画像表示処理は、前記スクリーンＤＰＩが前記所定値以上である場合、前記上層レイヤーを半透明表示する、請求項１に記載のプログラム。

【請求項3】

前記クライアント機に配信するステップは、前記アプリケーションプログラムの一部分を入れ替える指示を配信するステップを含む、請求項１又は２に記載のプログラム。

【請求項4】

クライアント機と通信可能な情報処理装置に実行させるプログラム配信方法であって、
前記クライアント機から当該クライアント機のスクリーンＤＰＩを示す情報を取得するステップと、
アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を有し、
前記情報に応じた前記画像表示処理は、前記スクリーンＤＰＩが所定値未満である場合、上層レイヤーを不透明表示することを特徴とするプログラム配信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数種類の携帯端末に対してアプリケーションプログラム等を配信するためのプログラム及びプログラム配信方法に関する。

【背景技術】

【0002】

従来からソーシャルゲーム市場は急激に成長している。ソーシャルゲームとは、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）のウェブブラウザ上で動作するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）と動作環境（アプリケーション・プラットフォーム）とが提供され、これらを基盤として制作されたゲームソフトウェアである。このソーシャルゲームを含む各種アプリケーションソフトを、一般にソーシャルアプリケーション（Ｓｏｃｉａｌ Ａｐｐｌｉｃｔｉｏｎ）と総称している。

【0003】

特に、ソーシャルアプリケーションは、専用のクライアントソフトウェアを必要とせず、ウェブブラウザとＳＮＳのアカウントのみで利用可能で、ＳＮＳが本来持つコミュニケーション機能を組み合わせたことが最大の特徴である。

【0004】

ここでソーシャルアプリケーションは、スマートフォンのｉＰｈｏｎｅ（登録商標）端末専用のアプリケーションソフトやＡｎｄｒｏｉｄ（登録商標）端末専用のアプリケーションソフトなどの端末のＯＳに依存した「ネイティブアプリ」と呼称されるものと、ウェブブラウザ上で動作可能な「ウェブアプリケーション」と呼称されるものとに大別できる。

【0005】

上記「ネイティブアプリ」は、使用する端末専用に特化されているためにパフォーマンス面で有利で、かつ、マーケットプレイスという課金処理のための枠組みも、かなり整えられている。

【0006】

しかし、上記ｉＰｈｏｎｅ（登録商標）が採用するＯＳである「ｉＯＳ」で動作するアプリケーションソフトが、プログラミング言語「Ｏｂｊｅｃｔｉｖｅ−Ｃ」で開発される一方で、上記Ａｎｄｒｏｉｄ（登録商標）で動作するアプリケーションソフトはプログラミング言語「Ｊａｖａ（登録商標）」で開発されている。

【0007】

そのため、上記「ネイティブアプリ」を開発するためには、端末のプラットフォーム特有の言語を使ったコーディング処理を介した後に、公式のマーケットプレイスを通す必要がある。

【0008】

一方、上記「Ｗｅｂアプリケーション」は、両プラットフォームに向けてＨＴＭＬ５（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ５）、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳ３（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ ３）等の言語をベースにしたクロス開発が可能であり、公開に当たって公式のマーケットプレイスを通す必要がない。

【0009】

上記「ネイティブアプリ」は、マーケットプレイスから端末に対してダウンロードし、インストールして利用するタイプのアプリケーションである。端末の機能や処理性能を余さず利用することが可能である反面、機能や動作が端末に依存しており、端末によっては正常に動作しない場合がある。

【0010】

一方、「ウェブアプリケーション」は、ウェブサーバ上で動作し、ウェブブラウザを用いて利用するアプリケーションである。「ウェブアプリケーション」は、ウェブブラウザをクライアントとし、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じてウェブサーバにアクセスして利用される。

【0011】

「ウェブアプリケーション」は、利用者側にとっては、ウェブページを閲覧する感覚でアプリケーションが利用できる、アプリケーションソフトをローカル環境にインストールしなくてもウェブブラウザがあればアプリケーションの機能を利用できる、というメリットがある。他方、「ウェブアプリケーション」では、ウェブブラウザの種類やバージョンによっては、「ウェブアプリケーション」が提供する機能を充分にサポートしていない場合もあり得る。

【0012】

特に「ウェブアプリケーション」において、Ｆｌａｓｈ（登録商標）やＡｊａｘ（ＡｓｙｎｃｈｒｏｎｏｕｓＪａｖａＳｃｒｉｐｔ＋ＸＭＬ）、Ｓｉｌｖｅｒｌｉｇｈｔ（登録商標）、ＲｏＲ（Ｒｕｂｙ ｏｎ Ｒａｉｌｓ）といった技術を利用して高機能、かつ、ダイナミックな機能を実現するものは、リッチインターネットアプリケーション（ＲＩＡ）と呼ばれている。

【0013】

近年では、Ｇｏｏｇｌｅ（登録商標）のＣｈｒｏｍｅＯＳ（オペレーティングシステム）をウェブアプリケーション化する試みも進んでいる。

【0014】

さらに、ソフトウェア開発者は、特定のソフトウェアパッケージやソフトウェアフレームワーク、ハードウェアプラットホーム、コンピュータシステム、ゲーム機、またはＯＳなどのためのアプリケーションプログラムを作成する際に、ソフトウェア開発キット（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）（以下「ＳＤＫ」と称する）と呼ばれる開発ツールのセットを使用する。

【0015】

このＳＤＫは、情報機器やＯＳなどのメーカが、自社製品向けのソフトウェアの開発を促すべく用意するツールキットであり、開発者向けに無料で配布されることが多い。（例えば、非特許文献１）

【先行技術文献】

【非特許文献】

【0016】

【非特許文献1】“http://microsoft.com/en-us/download/details.aspx?id=8442”（平成２４年 ６月 ７日確認)

【発明の概要】

【発明が解決しようとする課題】

【0017】

そして、ウェブサーバ装置からネットワークを介してスマートフォンなどの携帯端末に配信する各種アプリケーションプログラム、すなわち上記「ネイティブアプリ」を考えた場合、ウェブサーバ装置から配信する当該プログラムは、送信先の携帯端末のスペック、例えばＯＳのバージョンやディスプレイのサイズ、解像度などのスペックに合わせる必要がある。

【0018】

通常、１つのソースコードを変換して１つのアプリケーションプログラムを生成するため、複数のスペック毎のアプリケーションプログラムを提供するためには、当然ながらスペックの数に応じた複数のソースコードを用意しなければならず、その分、プログラムを提供する側の負担が大きくなる。

【0019】

加えて、特に対戦型のオンラインゲーム等では、端末側のスペックの相違により、例えば戦闘中のエフェクト画面の表示に要する時間も異なることがあり、それがためにゲーム進行上でスペックの相違に基づいた有利／不利が生じる、という不具合があった。

【0020】

そこで、本発明は、上記のような実情に鑑みてなされたもので、その目的とするところは、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による不公平が発生するのを防止することが可能なプログラム及びプログラム配信方法を提供することにある。

【課題を解決するための手段】

【0021】

本発明の一態様におけるプログラムは、クライアント機と通信可能な情報処理装置に、
前記クライアント機から当該クライアント機のスクリーンＤＰＩを示す情報を取得するス
テップと、アプリケーションプログラムを生成するための１つのソースコードを、前記取
得するステップで取得した前記情報に応じた画像表示処理を行うアプリケーションプログ
ラムに変換するステップと、前記変換するステップで得たアプリケーションプログラムを
前記クライアント機に配信するステップとを実行させ、前記情報に応じた前記画像表示処理は、前記スクリーンＤＰＩが所定値未満である場合、上層レイヤーを不透明表示する。

【発明の効果】

【0022】

本発明によれば、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による適不適が発生するのを防止することが可能となる。

【図面の簡単な説明】

【0023】

【図1】本発明の第１の実施形態に係る情報提供システムが使用される環境を説明する図。

【図2】同実施形態に係るサーバとクライアント間の接続アーキテクチャの概念を示す図。

【図3】同実施形態に係るサーバとクライアントでのログイン時の処理内容を中心として示すフローチャート。

【図4】同実施形態に係るシングルソースコードからプログラムを作成する概念を説明する図。

【図5】同実施形態に係る端末デバイス毎のプログラムの概念を示す図。

【図6】同実施形態に係るウェブサーバ装置が備えるデータベース（ＤＢ）の構成を示す図。

【図7】同実施形態に係るスペック情報としてのバージョン情報の先頭側の一部を例示する図。

【図8】同実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図。

【図9】同実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図。

【図10】本発明の第２の実施形態に係るサーバとクライアントでのログイン時の処理内容を中心として示すフローチャート。

【図11】同実施形態に係る端末デバイス毎のプログラムの概念を示す図。

【図12】同実施形態に係るウェブサーバ装置が備えるデータベース（ＤＢ）の構成を示す図。

【発明を実施するための形態】

【0024】

以下、本発明をオンラインゲームシステムに適用した場合の実施形態について図面を参照して説明する。
（第１の実施形態）
図１は、本発明の第１の実施形態に係るオンラインゲームシステムが使用される環境の一例を説明する図である。同図で、インターネットなどのネットワーク１に対して、ウェブサーバ装置２，３が接続されると共に、本システムでユーザが使用するクライアント装置となる携帯端末４，５が、アクセスポイント（ＡＰ）６あるいは基地局７を介して接続される。

【0025】

ウェブサーバ装置２，３は、本実施形態に係るオンラインゲームシステムを実現するためのコンピュータであり、オンラインゲームのサービスを提供するべくネットワーク１に対して並列に複数台設置している。

【0026】

一方、クライアント側の携帯端末４，５は、スマートフォン、フィーチャー・フォン（ｆｅａｔｕｒｅ ｐｈｏｎｅ）などを含み、例えば、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）などのＯＳ上で動作する携帯電話であっても良いし、さらにはノートブック型のパーソナルコンピュータ、モバイルコンピュータ、タブレット型コンピュータなどであってもよい。いずれにしても携帯端末４，５には、予めオンラインゲームのためのゲームプログラムがインストールされているものとする。

【0027】

携帯端末４，５としては、その機種固有のハードウェア構成、採用しているＯＳ、インストールされているアプリケーション等が多様に渡るものとし、ウェブサーバ装置２，３はそれぞれそれら多様な携帯端末４，５に対応してネイティブアプリケーションを配信可能であるものとする。

【0028】

上記ウェブサーバ装置２，３と携帯端末４，５それぞれの電子回路のハードウェア構成自体は、きわめて一般的で周知であるものとして、その記載及び説明を省略する。

【0029】

図２は、本実施形態に係るサーバとクライアント間の接続アーキテクチャの概念を示す図である。同図に示すように、Ａ社が提供するオンラインのゲームプログラムまたはアプリケーションプログラムを実行するに当たり、携帯端末４，５には、例えばＡＩＲ（登録商標）などで記述された、当該ゲームまたはアプリプログラムのためのアプリケーション実行環境Ｃ１が実装されると共に、当該Ａ社のデータベースに接続して課金処理等を行なうためのＡ社データベース接続キットＣ２が組込まれる。

【0030】

これと共に、携帯端末４，５がウェブサーバ装置２，３との通信を行なう部分に関しては、Ａ社が開発した（ソフトウェア）クライアントサイドのフレームワークＣ３がインストールされる。

【0031】

一方のＡ社が運営するウェブサーバ装置２，３では、オンラインゲーム及びアプリケーションを実行するための、例えばＮｏｄｅ．ｊｓ（登録商標）で記述されたサーバ側ジャバ・スクリプト（登録商標）（ＪＳ）実行環境Ｓ１が設けられると共に、直接携帯端末４，５とデータの送受を行なう部分に、上記フレームワークＣ３と対応するＡ社（ソフトウェア）サーバサイドのフレームワークＳ２が設けられる。

【0032】

携帯端末４，５のフレームワークＣ３と、ウェブサーバ装置２，３のフレームワークＳ２との間では、ＨＴＭＬ５（登録商標）で実装された規格である、ウェブソケット（ＷｅｂＳｏｋｅｃｔ）を基盤としてゲームのイベント情報等が送受される。

【0033】

このウェブソケットでは、サーバクライアント間で一度でも接続が確立すると、明示的に切断しない限り、通信手順を意識することなくデータのやりとりをソケット通信で実施できる。

【0034】

また、ウェブソケットで接続が確立しているサーバとすべてのクライアントは、同じデータを共有し、リアルタイムで送受信できる。
よって、上記ウェブソケットの規格を利用することで、Ａｊａｘ（Ａｓｙｎｃｈｒｏｎｏｕｓ ＪａｖａＳｃｒｉｐｔ（登録商標） ＋ＸＭＬ）やＣｏｍｅｔの通信におけるデメリット部分を補い、より効率的にサーバとクライアント間の双方向通信が実現できる。

【0035】

上記フレームワークＣ３，Ｓ２は、ＯＳに依存しないスクリプト言語として、例えばジャバ・スクリプト（登録商標）を用いて記述されている。そのため、携帯端末４，５のＯＳがＡｎｄｒｏｉｄ（登録商標）及びｉＯＳ（登録商標）などのいずれかであってもそれらに依存せずに同一接続環境を構築できる。

【0036】

次に上記実施形態の動作について説明する。
図３は、サーバであるウェブサーバ装置２，３と、クライアントである携帯端末４，５との間で実行される、オンラインゲーム開始当初のスペック認証設定に関する処理内容を示す。

【0037】

ウェブサーバ装置２，３では、既に作成されている１つ（シングル）のソースコードを読込む（ステップＳ１０１）。次にウェブサーバ装置２，３は、予め複数のＯＳ毎に用意された、それぞれ複数のスペック情報を参照し（ステップＳ１０２）、読込んだソースコードを、上記スペック情報毎に機械語にコンパイルしてプログラム化する（ステップＳ１０３）。ウェブサーバ装置２，３は、こうして得たプログラムを、自装置内の所定位置に格納する（ステップＳ１０４）。

【0038】

ウェブサーバ装置２，３は、上記のようにしてスペック情報毎に作成したプログラムを格納した状態で、ネットワーク１を介して携帯端末４，５側から、スペック情報と共に当該プログラムのダウンロードの要求がなされるのを待機する（ステップＳ１０５）。

【0039】

一方で、携帯端末４，５の少なくとも一方、例えば携帯端末４がネットワーク１を介してウェブサーバ装置２に接続し、オンラインゲームのサイトにログインした場合、その当初に携帯端末４は自機に既にインストールされているゲームプログラムのバージョン情報をスペック情報としてウェブサーバ装置２へ送信する（ステップＣ１０１）。

【0040】

図４は、このときウェブサーバ装置２で実行される、シングルソースコードからプログラムを作成する概念を説明する図である。多様な機種を含む携帯端末４，５からネイティブアプリのダウンロードを要求されるウェブサーバ装置２（３）では、ウェブサーバ装置２，３のＯＳのバージョンに基づき、データベース（ＤＢ）２Ａ（３Ａ）に予め格納してあるスペック情報を参照することで、１つ（シングル）のソースコードをコンパイルし、ＯＳのバージョンに適合した機械語によるプログラム２Ｂ（３Ｂ）を生成して、これを再度データベース２Ａ（３Ａ）に格納する一方で、ダウンロードを要求してきた当該携帯端末４，５に対して配信する。

【0041】

図５は、各携帯端末４，５にインストールされているプログラムの構成概念を示す図である。ＯＳとしてプログラムＡ（ｅｘ．ｉＰｓＯＳ４．０）を採用するある機種では、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。

【0042】

一方で、ＯＳとして、上記プログラムＡよりもバージョンが上位であるプログラムＢ（ｅｘ．ｉＰｓＯＳ４．３）を採用するある機種では、やはり同様にＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。

【0043】

この場合、プログラムＡをインストールしている携帯端末では、複数のレイヤー画像を重ねてディスプレイに表示させるにあたって、演算処理能力が低く、時間を要するものとした場合、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像をあえて不透明とする画像表示処理を採用するものとする。

【0044】

一方で、同一のアプリケーションプログラムを実行するにあたって、プログラムＢをインストールしている他方の携帯端末では、複数のレイヤー画像を重ねてディスプレイに表示させる際、演算処理能力が高く、処理負荷が小さいものとして、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像を半透明化する画像表示処理を採用するものとする。

【0045】

図６は、ウェブサーバ装置２（３）側がデータベース２Ａ（３Ａ）に予め備える、各携帯端末の機種毎のスペック情報を例示する図である。ここでは機種名「デバイスｘ．ｘ．ｘ」毎にＯＳのバージョン情報、１画素のアスペクト比、スクリーンＤＰＩ（Ｄｏｔ Ｐｅｒ Ｉｎｃｈ）、スクリーン画素数Ｘ、スクリーン画素数Ｙ、及び、（アプリケーション対応の）オーディオ（音声発音処理）の有無、等の各種情報が予め格納されている。

【0046】

上記スクリーンＤＰＩは、本来は画面の解像度を示す指標であるが、本実施形態ではスペック情報全体を代表する指標として用いるものとする。

【0047】

因みに、デンシティＤＰＩと呼称される指標では、ｌｄｐｉ（ｌｏｗ ｄｐｉ）が１２０（ｄｐｉ）で低解像度、ｍｄｐｉ（ｍｅｄｉｕｍ ｄｐｉ）が１６０（ｄｐｉ）で中解像度、ｈｄｐｉ（ｈｉｇｈ ｄｐｉ）が２４０（ｄｐｉ）で高解像度、ｘｈｄｐｉ（ｅｘｔｒａ ｈｉｇｈ ｄｐｉ）が３２０（ｄｐｉ）で極高解像度となっており、その携帯端末の機種のディスプレイの解像度のみならず、ハードウェア回路全体の演算処理能力の基準とされている。

【0048】

図７は、上記図３のステップＣ１０１で携帯端末４が送信する、スペック情報としてのバージョン情報ＶＩの先頭側の一部を例示する図である。なお、本実施形態では、スペック情報をバージョン情報として説明しているが、スペック情報（携帯端末のデバイス情報、ＯＳバージョン情報、スクリーン比率、音声発音処理の有無、等）であってもよい。

【0049】

図示する如く、このバージョン情報ＶＩ中には、携帯端末４のディスプレイ解像度情報ＤＲを含んでいる。このディスプレイ解像度情報ＤＲが、例えば「１６３［ｄｐｉ］」であることにより、携帯端末４側のＣＰＵやグラフィックに用いているチップとそれらのクロック周波数、メインメモリの容量など、トータルでの携帯端末４としてのゲーム実行時の演算処理速度が容易に類推可能となる。

【0050】

そして、携帯端末４からのスペック情報を受けたウェブサーバ装置２では、上記ステップＳ１０５でプログラムのダウンロードの要求がなされたことを判断すると、受けたバージョン情報ＶＩからディスプレイ解像度情報ＤＲを抽出し（ステップＳ１０６）、そのスペックに基づき、格納している最新バージョンのプログラム中から対応するプログラムを選択する。

【0051】

次いでウェブサーバ装置２は、携帯端末４から最新バージョンのプログラムのダウンロードが要求されると、これに応答するべく、携帯端末４のスペックに応じた、選択した最新バージョンのプログラムを例えばＪａｖａＳｃｒｉｐｔ（登録商標）で記述した形式で携帯端末４に対して送信する（ステップＳ１０７）。

【0052】

ここで、例えばＪａｖａＳｃｒｉｐｔ（登録商標）で記述された上記新バージョンのプログラムは、２つの部分からなっている。１つは、すでにインストールしているアプリケーション（古いバーションのプログラム）のどのモジュール（部分）を変更するかを指示する指示部であり、もう１つは、上記変更するモジュールそのものである。

【0053】

携帯端末４では、ウェブサーバ装置２から送られてきた、自機のスペックに応じた最新バージョンのプログラムをダウンロードすると（ステップＣ１０２）、当該プログラム中のマスタデータを端末内のデータベース領域に保存すると共に、このダウンロードしたプログラムにしたがって既にインストールしていた古いバージョンのプログラムを書き換えて更新設定する（ステップＣ１０３）。

【0054】

なお、ここで、古いバージョンのプログラムを書き換えるとは、その全てを書き換えるか、または入れ替える処理だけではなく、その一部分のみを書き換えるか、または入れ替える処理でもよい。

【0055】

その場合、古いバージョンのプログラムには、上記ダウンロードした、例えばＪａｖａｓｃｒｉｐｔ（登録商標）で記述されたプログラムの指示部での指示を受け入れる機能を備えており、且つ、入れ替えや書き換え可能な単位の複数の部分からなっており、上記受け入れる機能が、上記ダウンロードしたプログラムに含まれる上記指示部にしたがって、変更するモジュールを入れ替え、あるいは書き換える。

【0056】

このようにすることで、上記古いバージョンのプログラムに該当する、最初にインストールするアプリケーションを複数のスペック毎に予め準備することなく、部分的にスペックに合わせたプログラムを用いて調整することができる。

【0057】

携帯端末４は、この更新設定により、同時に書き換えたチェックサムの情報を再度ウェブサーバ装置２に対して送信する（ステップＣ１０４）。

【0058】

これに対してウェブサーバ装置２では、携帯端末４からのチェックサムの情報を受けて、プログラムが正常に最新のバージョンのものに書き換えられたことを確認し、確認作業として携帯端末４に対して応答信号を送信し（ステップＳ１０８）、以上で一旦処理を終了し、次に他の携帯端末に対しての処理を待機するべく、上記ステップＳ１０５からの処理に戻る。

【0059】

一方の携帯端末４では、上記ステップＣ１０４で最新バージョンでのチェックサムの情報をウェブサーバ装置２に対して送信した後、その応答信号を当該ウェブサーバ装置２から受信することでプログラムのバージョンアップの完了を確認し（ステップＣ１０５）、以上でウェブサーバ装置２への一連のログイン処理を完了し、バージョンアップされたゲームの実行に移行する。

【0060】

以下、ゲームプログラム上でのスペック情報に基づく処理の相違を具体例を用いて説明する。
図８は、ある対戦ゲームで携帯端末４のディスプレイに表示される一シーンを例示している。このようなゲームの進行中、あるゲームキャラクタが攻撃のターン中に繰出した技を視覚効果を交えて表示する場合を考える。

【0061】

図９（Ａ）は、携帯端末４のスペック情報、すなわちバージョン情報ＶＩ中のディスプレイ解像度情報ＤＲが、予めウェブサーバ装置２側で設定されたしきい値より低く、グラフィックス表示性能が低いと判断された場合に用意されている、当該ゲームのプログラムにしたがった、技を視覚効果を交えて表示した例を示す。

【0062】

ここでは、それまで表示していた、上記図８に示したゲーム進行上の画面（下層レイヤーの画像）を一切表示することなく（不透明処理）、技の視覚効果のみを画面に表示している例を示す。

【0063】

これに対して、図９（Ｂ）は、携帯端末４のスペック情報、すなわちバージョン情報ＶＩ中のディスプレイ解像度情報ＤＲが、予めウェブサーバ装置２側で設定されたしきい値より高く、グラフィックス表示性能が高いと判断された場合に用意されている、当該ゲームのプログラムにしたがった、技を視覚効果を交えて表示した例を示す。

【0064】

ここでは、それまで表示していた、上記図８に示したゲーム進行上の画面（下層レイヤーの画像）が見えるように、上記図９（Ａ）で示した技の視覚効果を半透明化した状態で重ね合わせて画面に表示している例を示す。

【0065】

このように、携帯端末４のスペックに応じて表示させる画像の内容を変更させることで、必要な画像の表示に関する時間を携帯端末４，５の機種に拘わらず平均化させることができ、オンラインゲームにおける同時性を確保できる。

【0066】

したがって、対戦ゲームによっては、あるターンで技を出した後に直ぐ次のターンへの準備に移行できるために、スペックが高い機種の方が有利になる場合や、あるいは反対に、あるターンで技を受けている途中であればヒットポイントの回復を準備できるために、スペックが低い機種の方が有利になる場合など、スペックの相違によりゲーム進行上の有利／不利が生じてしまうような事態の発生をできうる限り回避し、公平性を確保できる。

【0067】

（第２の実施形態）
上記第１の実施形態では、ウェブサーバ装置２側で、予めソースコードからスペックに応じた複数のプログラムを作成した上で格納しておく場合について説明したが、本発明はこれに限らず、クライアント側からスペック情報を取得する毎に、そのスペック情報に基づいてソースコードからプログラムを生成し、生成したプログラムを配信するようにしても良い。

【0068】

以下、そのような第２の実施形態についても図面を参照して説明する。
なお、本発明の第２の実施形態に係る、オンラインゲームシステムが使用される環境については上記図１と、サーバとクライアント間の接続アーキテクチャの概念については上記図２と、それぞれほぼ同様であるため、同一部分には同一符号を用いるものとして、その図示と説明とを省略する。

【0069】

次に上記実施形態の動作について説明する。
図１０は、サーバであるウェブサーバ装置２，３と、クライアントである携帯端末４，５との間で実行される、オンラインゲーム開始当初のスペック認証設定に関する処理内容を示す。

【0070】

ウェブサーバ装置２，３は、ネットワーク１を介して携帯端末４，５側から、スペック情報と共に当該プログラムのダウンロードの要求がなされるのを待機している（ステップＳ２０１）。

【0071】

一方で、携帯端末４，５の少なくとも一方、例えば携帯端末４がネットワーク１を介してウェブサーバ装置２に接続し、オンラインゲームのサイトにログインした場合、その当初に携帯端末４は自機に既にインストールされているゲームプログラムのバージョン情報をスペック情報としてウェブサーバ装置２へ送信する（ステップＣ２０１）。

【0072】

ウェブサーバ装置２では、携帯端末４からのスペック情報を受けると、上記ステップＳ２０１でプログラムのダウンロードの要求がなされたことを判断し、続いて受けたバージョン情報からディスプレイ解像度の情報を抽出する（ステップＳ２０２）。

【0073】

次いでウェブサーバ装置２，３は、既に作成されている１つ（シングル）のソースコードを読込む（ステップＳ２０３）。次にウェブサーバ装置２は、予め複数のＯＳ毎に用意された、それぞれ複数のスペック情報を参照し（ステップＳ２０４）、上記ステップＳ２０１で受信したスペック情報に対応して上記ソースコードを機械語にコンパイルしてプログラム化する（ステップＳ２０５）。ウェブサーバ装置２は、こうして得たプログラムを、自装置内のデータベース２Ａに格納した後（ステップＳ２０６）、ダウンロードを要求してきた携帯端末４，５に対して送信する（ステップＳ２０７）。

【0074】

携帯端末４では、ウェブサーバ装置２から送られてきた、自機のスペックに応じた最新バージョンのプログラムをダウンロードすると（ステップＣ２０２）、当該プログラム中のマスタデータを端末内のデータベース領域に保存すると共に、このダウンロードしたプログラムにしたがって既にインストールしていた古いバージョンのプログラムを書き換えて更新設定する（ステップＣ２０３）。

【0075】

携帯端末４は、この更新設定により、同時に書き換えたチェックサムの情報を再度ウェブサーバ装置２に対して送信する（ステップＣ２０４）。

【0076】

これに対してウェブサーバ装置２では、携帯端末４からのチェックサムの情報を受けて、プログラムが正常に最新のバージョンのものに書き換えられたことを確認し、確認作業として携帯端末４に対して応答信号を送信し（ステップＳ２０９）、以上で一旦処理を終了し、次に他の携帯端末に対して同様の処理を待機するべく、上記ステップＳ２０１からの処理に戻る。

【0077】

一方の携帯端末４では、上記ステップＣ２０４で最新バージョンでのチェックサムの情報をウェブサーバ装置２に対して送信した後、その応答信号を当該ウェブサーバ装置２から受信することでプログラムのバージョンアップの完了を確認し（ステップＣ２０５）、以上でウェブサーバ装置２への一連のログイン処理を完了し、バージョンアップされたゲームの実行に移行する。

【0078】

図１１は、各携帯端末４，５にそれぞれインストールされたプログラムの構成概念を示す図である。ここでは、携帯端末４がＯＳとしてプログラムＡ（ｅｘ．ｉＰｓＯＳ４．０）を採用した機種であるものとし、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。

【0079】

一方で携帯端末５は、ＯＳとして上記プログラムＡよりもバージョンが上位であるプログラムＢ（ｅｘ．ｉＰｓＯＳ４．３）を採用した機種であるものとし、やはり同様にＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。

【0080】

この場合、プログラムＡをインストールしている携帯端末４では、複数のレイヤー画像を重ねてディスプレイに表示させるにあたって、演算処理能力が低く、時間を要するものとした場合、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像をあえて不透明とする画像表示処理を採用するものとする。

【0081】

一方で、同一のアプリケーションプログラムを実行するにあたって、プログラムＢをインストールしている他方の携帯端末５では、複数のレイヤー画像を重ねてディスプレイに表示させる際、演算処理能力が高く、処理負荷が小さいものとして、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像を半透明化する画像表示処理を採用するものとする。

【0082】

図１２は、ウェブサーバ装置２（３）側がデータベース２Ａ（３Ａ）に予め備える、各携帯端末の機種毎のスペック情報を例示する図である。ここでは機種名「デバイスｘ．ｘ．ｘ」毎にＯＳのバージョン情報、１画素のアスペクト比、スクリーンＤＰＩ（Ｄｏｔ Ｐｅｒ Ｉｎｃｈ）、スクリーン画素数Ｘ、スクリーン画素数Ｙ、及び、（アプリケーション対応の）オーディオ（音声発音処理）の有無、等の各種情報が予め格納されている。

【0083】

上記スクリーンＤＰＩは、本来は画面の解像度を示す指標であるが、本実施形態ではスペック情報全体を代表する指標として用いるものとする。

【0084】

以上詳述した如く上記第１及び第２の実施形態によれば、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による不公平が発生するのを確実に防止することが可能となる。

【0085】

また上記実施形態では、スペック情報として、バージョン情報ＶＩ中のディスプレイ解像度情報ＤＲに基づいてクライアント機の機種のスペックの行程を判断するものとしたが、このようにゲームプログラムでスペックに応じた処理時間の相違が露呈し易いグラフィックス演算に関する部分を、ディスプレイ解像度情報ＤＲを基準として判断するものとしたので、判断のための基準が明解であり、ウェブサーバ装置２側での処理を簡易化できる。

【0086】

なお上記第１及び第２の実施形態はいずれも、対戦型のオンラインゲームのプログラムに適用した場合の例について説明したが、本発明は配信するアプリケーションプログラムの種類等を限定するものではなく、他の各種アプリケーションプログラムにも同様に適用可能である。

【0087】

その他、本発明は上述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、上述した実施形態で実行される機能は可能な限り適宜組み合わせて実施しても良い。上述した実施形態には種々の段階が含まれており、開示される複数の構成要件による適宜の組み合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、効果が得られるのであれば、この構成要件が削除された構成が発明として抽出され得る。

【符号の説明】

【0088】

１…ネットワーク、２，３…ウェブサーバ装置、４，５…携帯端末、６…アクセスポイント（ＡＰ）、７…基地局、ＤＲ…ディスプレイ解像度情報、ＶＩ…バージョン情報。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】