WO2014065405A1 - ウェブサーバ装置及びプログラム配信方法 - Google Patents

Abstract

　本発明の目的は、アプリケーション提供側の負担を軽減し、且つオンラインで対戦通信を行なうようなアプリでの端末間のスペックの相違による不公平な環境の発生を防止することである。　本発明のウェブサーバ装置により実行されるプログラム配信方法は、クライアント機から配信要求と共に上記クライアント機のスペック情報を受信するスペック情報受信工程と、アプリケーションプログラムを生成するための１つのソースコードをもとに、上記スペック情報に応じたアプリケーションプログラムを生成する生成工程と、上記生成工程で生成したアプリケーションプログラムを上記クライアント機に配信する配信工程とを有する。

Description

ウェブサーバ装置及びプログラム配信方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"http://microsoft.com/en-us/download/details.aspx?id=8442"（平成２４年　６月　７日確認)

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

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

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

　本発明の目的は、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による不公平が発生するのを防止することが可能なウェブサーバ装置及びプログラム配信方法を提供することにある。

　本発明の一態様は、ウェブサーバ装置により実行されるプログラム配信方法であって、クライアント機から配信要求と共に上記クライアント機のスペック情報を受信するスペック情報受信工程と、アプリケーションプログラムを生成するための１つのソースコードをもとに、上記スペック情報に応じたアプリケーションプログラムを生成する生成工程と、上記生成工程で生成したアプリケーションプログラムを上記クライアント機に配信する配信工程とを有したことを特徴とする。

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

図１は、本発明の第１の実施形態に係るオンラインゲームシステムが使用される環境を説明する図である。 図２は、第１の実施形態に係るサーバとクライアント間の接続アーキテクチャの概念を示す図である。 図３は、第１の実施形態に係るサーバとクライアントでのログイン時の処理内容を示すフローチャートである。 図４は、第１の実施形態に係るシングルソースコードからプログラムを作成する概念を説明する図である。 図５は、第１の実施形態に係る端末デバイス毎のプログラムの概念を示す図である。 図６は、第１の実施形態に係るウェブサーバ装置が備えるデータベース（ＤＢ）の構成を示す図である。 図７は、第１の実施形態に係るスペック情報としてのバージョン情報の先頭側の一部を例示する図である。 図８は、第１の実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図である。 図９Ａは、第１の実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図である。 図９Ｂは、第１の実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図である。 図１０は、本発明の第２の実施形態に係るサーバとクライアントでのログイン時の処理内容を示すフローチャートである。 図１１は、第２の実施形態に係る端末デバイス毎のプログラムの概念を示す図である。 図１２は、第２の実施形態に係るウェブサーバ装置が備えるデータベース（ＤＢ）の構成を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (7)

1. 　ウェブサーバ装置により実行されるプログラム配信方法であって、
   　クライアント機から配信要求と共に上記クライアント機のスペック情報を受信するスペック情報受信工程と、
   　アプリケーションプログラムを生成するための１つのソースコードをもとに、上記スペック情報に応じたアプリケーションプログラムを生成する生成工程と、
   　上記生成工程で生成したアプリケーションプログラムを上記クライアント機に配信する配信工程と
   を有するプログラム配信方法。
2. 　上記クライアント機にインストールされたプログラムの変更する部分を指示する情報を、上記アプリケーションプログラムと共に配信する請求項１記載のプログラム配信方法。
3. 　上記スペック情報は、上記クライアント機のディスプレイ解像度の情報を含む請求項１記載のプログラム配信方法。
4. 　上記ディスプレイ解像度が予め設定されたしきい値より低い場合に、複数のレイヤー画像のうち特定のレイヤー画像を表示しないアプリケーションプログラムを生成し、
   　上記ディスプレイ解像度が上記しきい値より高い場合に、上記特定のレイヤー画像を表示するアプリケーションプログラムを生成する請求項３記載のプログラム配信方法。
5. 　上記スペック情報が予め設定されたしきい値より低い場合に、上記クライアント機の処理の負荷が軽い第１のアプリケーションプログラムを生成し、
   　上記スペック情報が上記しきい値より高い場合に、前記第１のアプリケーションプログラムより上記クライアント機の処理の負荷が重い第２のアプリケーションプログラムを生成する請求項１記載のプログラム配信方法。
6. 　アプリケーションプログラムを生成するための１つのソースコードを格納する格納ユニットと、
   　クライアント機から配信要求と共に上記クライアント機のスペック情報を取得するスペック取得ユニットと、
   　上記ソースコードを、上記スペック情報に応じたアプリケーションプログラムに変換する変換ユニットと、
   　上記アプリケーションプログラムを上記クライアント機に配信する配信ユニットと
   を具備するウェブサーバ装置。
7. 　上記スペック情報は、上記クライアント機のディスプレイ解像度の情報を含む請求項６記載のウェブサーバ装置。

Images