(57)【要約】【課題】アプリ提供側の負担を軽減し、且つオンラインで対戦通信を行なうようなアプリでの端末間のスペックの相違による不公平な環境の発生を防止すること。【解決手段】クライアント機が動作するオペレーティングシステム（ＯＳ）にかかわらず同一の環境で前記クライアント機と通信することで対戦ゲームを実現する情報処理装置に、クライアント機から、クライアント機が動作するＯＳのバージョン情報と、クライアント機のスペック情報とを取得するステップと、１つのソースコードから、クライアント機が動作するＯＳのバージョン情報と、クライアント機のスペック情報とに応じて生成された、対戦ゲームに係る画像表示処理を行うアプリケーションプログラムをクライアント機に配信するステップとを実行させ、画像表示処理の少なくとも一部を相違させて、クライアント機間で対戦ゲームの進行に必要な画像の表示に関する時間の差を減少させるプログラム。【選択図】図３
2018043035.tif 000002
【特許請求の範囲】
【請求項１】
クライアント機が動作するオペレーティングシステムにかかわらず同一の環境で前記クライアント機と通信することで対戦ゲームを実現する情報処理装置に、
前記クライアント機から、前記クライアント機が動作するオペレーティングシステムのバージョン情報と、前記クライアント機のスペック情報とを取得するステップと、
１つのソースコードから、前記クライアント機が動作するオペレーティングシステムのバージョン情報と、前記クライアント機のスペック情報とに応じて生成された、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
前記画像表示処理の少なくとも一部を相違させて、前記クライアント機間で前記対戦ゲームの進行に必要な画像の表示に関する時間の差を減少させる
プログラム。
【請求項２】
前記情報処理装置に、複数の前記クライアント機それぞれのスペック情報に応じて生成されたアプリケーションプログラムを前記情報処理装置に格納するステップをさらに実行させ、
前記クライアント機に配信するステップにおいて、前記情報処理装置に格納されているアプリケーションプログラムから、前記クライアント機から取得したスペック情報に応じたアプリケーションプログラムを前記クライアント機に配信する、請求項１に記載のプログラム。
【請求項３】
前記情報処理装置は、前記クライアント機とリアルタイムでデータを送受信することで前記対戦ゲームを実現する、請求項１又は２に記載のプログラム。
【請求項４】
クライアント機が動作するオペレーティングシステムにかかわらず同一の環境で前記クライアント機と通信することで対戦ゲームを実現する情報処理装置に実行させるプログラム配信方法であって、
前記クライアント機から、前記クライアント機が動作するオペレーティングシステムのバージョン情報と、前記クライアント機のスペック情報とを取得するステップと、
１つのソースコードから、前記クライアント機が動作するオペレーティングシステムのバージョン情報と、前記クライアント機のスペック情報とに応じて生成された、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムを前記クライアント機に配信するステップと
を有し、
前記画像表示処理の少なくとも一部を相違させて、前記クライアント機間で前記対戦ゲームの進行に必要な画像の表示に関する時間の差を減少させる
プログラム配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数種類の携帯端末に対してアプリケーションプログラム等を配信するプログラム及びプログラム配信方法に関する。
【背景技術】
【０００２】
従来からソーシャルゲーム市場は急激に成長している。ソーシャルゲームとは、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）のウェブブラウザ上で動作するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）と動作環境（アプリケーション・プラットフォーム）とが提供され、これらを基盤として制作されたゲームソフトウェアである。このソーシャルゲームを含む各種アプリケーションソフトを、一般にソーシャルアプリケーション（Ｓｏｃｉａｌ  Ａｐｐｌｉｃｔｉｏｎ）と総称している。
【０００３】
特に、ソーシャルアプリケーションは、専用のクライアントソフトウェアを必要とせず、ウェブブラウザとＳＮＳのアカウントのみで利用可能で、ＳＮＳが本来持つコミュニケーション機能を組み合わせたことが最大の特徴である。
【０００４】
ここでソーシャルアプリケーションは、スマートフォンのｉＰｈｏｎｅ（登録商標）端末専用のアプリケーションソフトやＡｎｄｒｏｉｄ（登録商標）端末専用のアプリケーションソフトなどの端末のＯＳに依存した「ネイティブアプリ」と呼称されるものと、ウェブブラウザ上で動作可能な「ウェブアプリケーション」と呼称されるものとに大別できる。
【０００５】
上記「ネイティブアプリ」は、使用する端末専用に特化されているためにパフォーマンス面で有利で、かつ、マーケットプレイスという課金処理のための枠組みも、かなり整えられている。
【０００６】
しかし、上記ｉＰｈｏｎｅ（登録商標）が採用するＯＳである「ｉＯＳ」で動作するアプリケーションソフトが、プログラミング言語「Ｏｂｊｅｃｔｉｖｅ−Ｃ」で開発される一方で、上記Ａｎｄｒｏｉｄ（登録商標）で動作するアプリケーションソフトはプログラミング言語「Ｊａｖａ（登録商標）」で開発されている。
【０００７】
そのため、上記「ネイティブアプリ」を開発するためには、端末のプラットフォーム特有の言語を使ったコーディング処理を介した後に、公式のマーケットプレイスを通す必要がある。
【０００８】
一方、上記「Ｗｅｂアプリケーション」は、両プラットフォームに向けてＨＴＭＬ５（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ  ５）、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳ３（Ｃａｓｃａｄｉｎｇ  Ｓｔｙｌｅ  Ｓｈｅｅｔｓ  ３）等の言語をベースにしたクロス開発が可能であり、公開に当たって公式のマーケットプレイスを通す必要がない。
【０００９】
上記「ネイティブアプリ」は、マーケットプレイスから端末に対してダウンロードし、インストールして利用するタイプのアプリケーションである。端末の機能や処理性能を余さず利用することが可能である反面、機能や動作が端末に依存しており、端末によっては正常に動作しない場合がある。
【００１０】
一方、「ウェブアプリケーション」は、ウェブサーバ上で動作し、ウェブブラウザを用いて利用するアプリケーションである。「ウェブアプリケーション」は、ウェブブラウザをクライアントとし、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を通じてウェブサーバにアクセスして利用される。
【００１１】
「ウェブアプリケーション」は、利用者側にとっては、ウェブページを閲覧する感覚でアプリケーションが利用できる、アプリケーションソフトをローカル環境にインストールしなくてもウェブブラウザがあればアプリケーションの機能を利用できる、というメリットがある。他方、「ウェブアプリケーション」では、ウェブブラウザの種類やバージョンによっては、「ウェブアプリケーション」が提供する機能を充分にサポートしていない場合もあり得る。
【００１２】
特に「ウェブアプリケーション」において、Ｆｌａｓｈ（登録商標）やＡｊａｘ（ＡｓｙｎｃｈｒｏｎｏｕｓＪａｖａＳｃｒｉｐｔ＋ＸＭＬ）、Ｓｉｌｖｅｒｌｉｇｈｔ（登録商標）、ＲｏＲ（Ｒｕｂｙ  ｏｎ  Ｒａｉｌｓ）といった技術を利用して高機能、かつ、ダイナミックな機能を実現するものは、リッチインターネットアプリケーション（ＲＩＡ）と呼ばれている。
【００１３】
近年では、Ｇｏｏｇｌｅ（登録商標）のＣｈｒｏｍｅＯＳ（オペレーティングシステム）をウェブアプリケーション化する試みも進んでいる。
【００１４】
さらに、ソフトウェア開発者は、特定のソフトウェアパッケージやソフトウェアフレームワーク、ハードウェアプラットホーム、コンピュータシステム、ゲーム機、またはＯＳなどのためのアプリケーションプログラムを作成する際に、ソフトウェア開発キット（Ｓｏｆｔｗａｒｅ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｋｉｔ）（以下「ＳＤＫ」と称する）と呼ばれる開発ツールのセットを使用する。
【００１５】
このＳＤＫは、情報機器やＯＳなどのメーカが、自社製品向けのソフトウェアの開発を促すべく用意するツールキットであり、開発者向けに無料で配布されることが多い。（例えば、非特許文献１）
【先行技術文献】
【非特許文献】
【００１６】
【非特許文献１】“http://microsoft.com/en-us/download/details.aspx?id=8442”（平成２４年  ６月  ７日確認)
【発明の概要】
【発明が解決しようとする課題】
【００１７】
そして、ウェブサーバ装置からネットワークを介してスマートフォンなどの携帯端末に配信する各種アプリケーションプログラム、すなわち上記「ネイティブアプリ」を考えた場合、ウェブサーバ装置から配信する当該プログラムは、送信先の携帯端末のスペック、例えばＯＳのバージョンやディスプレイのサイズ、解像度などのスペックに合わせる必要がある。
【００１８】
通常、１つのソースコードを変換して１つのアプリケーションプログラムを生成するため、複数のスペック毎のアプリケーションプログラムを提供するためには、当然ながらスペックの数に応じた複数のソースコードを用意しなければならず、その分、プログラムを提供する側の負担が大きくなる。
【００１９】
加えて、特に対戦型のオンラインゲーム等では、端末側のスペックの相違により、例えば戦闘中のエフェクト画面の表示に要する時間も異なることがあり、それがためにゲーム進行上でスペックの相違に基づいた有利／不利が生じる、という不具合があった。
【００２０】
そこで、本発明は、上記のような実情に鑑みてなされたもので、その目的とするところは、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による不公平が発生するのを防止することが可能なプログラム及びプログラム配信方法を提供することにある。
【課題を解決するための手段】
【００２１】
本発明の一態様におけるプログラムは、クライアント機が動作するオペレーティングシステムにかかわらず同一の環境で前記クライアント機と通信することで対戦ゲームを実現する情報処理装置に、前記クライアント機から、前記クライアント機が動作するオペレーティングシステムのバージョン情報と、前記クライアント機のスペック情報とを取得するステップと、１つのソースコードから、前記クライアント機が動作するオペレーティングシステムのバージョン情報と、前記クライアント機のスペック情報とに応じて生成された、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムを前記クライアント機に配信するステップとを実行させ、前記画像表示処理の少なくとも一部を相違させて、前記クライアント機間で前記対戦ゲームの進行に必要な画像の表示に関する時間の差を減少させる。
【発明の効果】
【００２２】
本発明によれば、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による適不適が発生するのを防止することが可能となる。
【図面の簡単な説明】
【００２３】
【図１】本発明の第１の実施形態に係る情報提供システムが使用される環境を説明する図。
【図２】同実施形態に係るサーバとクライアント間の接続アーキテクチャの概念を示す図。
【図３】同実施形態に係るサーバとクライアントでのログイン時の処理内容を中心として示すフローチャート。
【図４】同実施形態に係るシングルソースコードからプログラムを作成する概念を説明する図。
【図５】同実施形態に係る端末デバイス毎のプログラムの概念を示す図。
【図６】同実施形態に係るウェブサーバ装置が備えるデータベース（ＤＢ）の構成を示す図。
【図７】同実施形態に係るスペック情報としてのバージョン情報の先頭側の一部を例示する図。
【図８】同実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図。
【図９】同実施形態に係るゲームプログラム上でのスペック情報に基づく処理の相違を表示画面の具体例を用いて説明する図。
【図１０】本発明の第２の実施形態に係るサーバとクライアントでのログイン時の処理内容を中心として示すフローチャート。
【図１１】同実施形態に係る端末デバイス毎のプログラムの概念を示す図。
【図１２】同実施形態に係るウェブサーバ装置が備えるデータベース（ＤＢ）の構成を示す図。
【発明を実施するための形態】
【００２４】
以下、本発明をオンラインゲームシステムに適用した場合の実施形態について図面を参照して説明する。
（第１の実施形態）
図１は、本発明の第１の実施形態に係るオンラインゲームシステムが使用される環境の一例を説明する図である。同図で、インターネットなどのネットワーク１に対して、ウェブサーバ装置２，３が接続されると共に、本システムでユーザが使用するクライアント装置となる携帯端末４，５が、アクセスポイント（ＡＰ）６あるいは基地局７を介して接続される。
【００２５】
ウェブサーバ装置２，３は、本実施形態に係るオンラインゲームシステムを実現するためのコンピュータであり、オンラインゲームのサービスを提供するべくネットワーク１に対して並列に複数台設置している。
【００２６】
一方、クライアント側の携帯端末４，５は、スマートフォン、フィーチャー・フォン（ｆｅａｔｕｒｅ  ｐｈｏｎｅ）などを含み、例えば、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）などのＯＳ上で動作する携帯電話であっても良いし、さらにはノートブック型のパーソナルコンピュータ、モバイルコンピュータ、タブレット型コンピュータなどであってもよい。いずれにしても携帯端末４，５には、予めオンラインゲームのためのゲームプログラムがインストールされているものとする。
【００２７】
携帯端末４，５としては、その機種固有のハードウェア構成、採用しているＯＳ、インストールされているアプリケーション等が多様に渡るものとし、ウェブサーバ装置２，３はそれぞれそれら多様な携帯端末４，５に対応してネイティブアプリケーションを配信可能であるものとする。
【００２８】
上記ウェブサーバ装置２，３と携帯端末４，５それぞれの電子回路のハードウェア構成自体は、きわめて一般的で周知であるものとして、その記載及び説明を省略する。
【００２９】
図２は、本実施形態に係るサーバとクライアント間の接続アーキテクチャの概念を示す図である。同図に示すように、Ａ社が提供するオンラインのゲームプログラムまたはアプリケーションプログラムを実行するに当たり、携帯端末４，５には、例えばＡＩＲ（登録商標）などで記述された、当該ゲームまたはアプリプログラムのためのアプリケーション実行環境Ｃ１が実装されると共に、当該Ａ社のデータベースに接続して課金処理等を行なうためのＡ社データベース接続キットＣ２が組込まれる。
【００３０】
これと共に、携帯端末４，５がウェブサーバ装置２，３との通信を行なう部分に関しては、Ａ社が開発した（ソフトウェア）クライアントサイドのフレームワークＣ３がインストールされる。
【００３１】
一方のＡ社が運営するウェブサーバ装置２，３では、オンラインゲーム及びアプリケーションを実行するための、例えばＮｏｄｅ．ｊｓ（登録商標）で記述されたサーバ側ジャバ・スクリプト（登録商標）（ＪＳ）実行環境Ｓ１が設けられると共に、直接携帯端末４，５とデータの送受を行なう部分に、上記フレームワークＣ３と対応するＡ社（ソフトウェア）サーバサイドのフレームワークＳ２が設けられる。
【００３２】
携帯端末４，５のフレームワークＣ３と、ウェブサーバ装置２，３のフレームワークＳ２との間では、ＨＴＭＬ５（登録商標）で実装された規格である、ウェブソケット（ＷｅｂＳｏｋｅｃｔ）を基盤としてゲームのイベント情報等が送受される。
【００３３】
このウェブソケットでは、サーバクライアント間で一度でも接続が確立すると、明示的に切断しない限り、通信手順を意識することなくデータのやりとりをソケット通信で実施できる。
【００３４】
また、ウェブソケットで接続が確立しているサーバとすべてのクライアントは、同じデータを共有し、リアルタイムで送受信できる。
よって、上記ウェブソケットの規格を利用することで、Ａｊａｘ（Ａｓｙｎｃｈｒｏｎｏｕｓ  ＪａｖａＳｃｒｉｐｔ（登録商標）  ＋ＸＭＬ）やＣｏｍｅｔの通信におけるデメリット部分を補い、より効率的にサーバとクライアント間の双方向通信が実現できる。
【００３５】
上記フレームワークＣ３，Ｓ２は、ＯＳに依存しないスクリプト言語として、例えばジャバ・スクリプト（登録商標）を用いて記述されている。そのため、携帯端末４，５のＯＳがＡｎｄｒｏｉｄ（登録商標）及びｉＯＳ（登録商標）などのいずれかであってもそれらに依存せずに同一接続環境を構築できる。
【００３６】
次に上記実施形態の動作について説明する。
図３は、サーバであるウェブサーバ装置２，３と、クライアントである携帯端末４，５との間で実行される、オンラインゲーム開始当初のスペック認証設定に関する処理内容を示す。
【００３７】
ウェブサーバ装置２，３では、既に作成されている１つ（シングル）のソースコードを読込む（ステップＳ１０１）。次にウェブサーバ装置２，３は、予め複数のＯＳ毎に用意された、それぞれ複数のスペック情報を参照し（ステップＳ１０２）、読込んだソースコードを、上記スペック情報毎に機械語にコンパイルしてプログラム化する（ステップＳ１０３）。ウェブサーバ装置２，３は、こうして得たプログラムを、自装置内の所定位置に格納する（ステップＳ１０４）。
【００３８】
ウェブサーバ装置２，３は、上記のようにしてスペック情報毎に作成したプログラムを格納した状態で、ネットワーク１を介して携帯端末４，５側から、スペック情報と共に当該プログラムのダウンロードの要求がなされるのを待機する（ステップＳ１０５）。
【００３９】
一方で、携帯端末４，５の少なくとも一方、例えば携帯端末４がネットワーク１を介してウェブサーバ装置２に接続し、オンラインゲームのサイトにログインした場合、その当初に携帯端末４は自機に既にインストールされているゲームプログラムのバージョン情報をスペック情報としてウェブサーバ装置２へ送信する（ステップＣ１０１）。
【００４０】
図４は、このときウェブサーバ装置２で実行される、シングルソースコードからプログラムを作成する概念を説明する図である。多様な機種を含む携帯端末４，５からネイティブアプリのダウンロードを要求されるウェブサーバ装置２（３）では、ウェブサーバ装置２，３のＯＳのバージョンに基づき、データベース（ＤＢ）２Ａ（３Ａ）に予め格納してあるスペック情報を参照することで、１つ（シングル）のソースコードをコンパイルし、ＯＳのバージョンに適合した機械語によるプログラム２Ｂ（３Ｂ）を生成して、これを再度データベース２Ａ（３Ａ）に格納する一方で、ダウンロードを要求してきた当該携帯端末４，５に対して配信する。
【００４１】
図５は、各携帯端末４，５にインストールされているプログラムの構成概念を示す図である。ＯＳとしてプログラムＡ（ｅｘ．ｉＰｓＯＳ４．０）を採用するある機種では、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。
【００４２】
一方で、ＯＳとして、上記プログラムＡよりもバージョンが上位であるプログラムＢ（ｅｘ．ｉＰｓＯＳ４．３）を採用するある機種では、やはり同様にＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。
【００４３】
この場合、プログラムＡをインストールしている携帯端末では、複数のレイヤー画像を重ねてディスプレイに表示させるにあたって、演算処理能力が低く、時間を要するものとした場合、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像をあえて不透明とする画像表示処理を採用するものとする。
【００４４】
一方で、同一のアプリケーションプログラムを実行するにあたって、プログラムＢをインストールしている他方の携帯端末では、複数のレイヤー画像を重ねてディスプレイに表示させる際、演算処理能力が高く、処理負荷が小さいものとして、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像を半透明化する画像表示処理を採用するものとする。
【００４５】
図６は、ウェブサーバ装置２（３）側がデータベース２Ａ（３Ａ）に予め備える、各携帯端末の機種毎のスペック情報を例示する図である。ここでは機種名「デバイスｘ．ｘ．ｘ」毎にＯＳのバージョン情報、１画素のアスペクト比、スクリーンＤＰＩ（Ｄｏｔ  Ｐｅｒ  Ｉｎｃｈ）、スクリーン画素数Ｘ、スクリーン画素数Ｙ、及び、（アプリケーション対応の）オーディオ（音声発音処理）の有無、等の各種情報が予め格納されている。
【００４６】
上記スクリーンＤＰＩは、本来は画面の解像度を示す指標であるが、本実施形態ではスペック情報全体を代表する指標として用いるものとする。
【００４７】
因みに、デンシティＤＰＩと呼称される指標では、ｌｄｐｉ（ｌｏｗ  ｄｐｉ）が１２０（ｄｐｉ）で低解像度、ｍｄｐｉ（ｍｅｄｉｕｍ  ｄｐｉ）が１６０（ｄｐｉ）で中解像度、ｈｄｐｉ（ｈｉｇｈ  ｄｐｉ）が２４０（ｄｐｉ）で高解像度、ｘｈｄｐｉ（ｅｘｔｒａ  ｈｉｇｈ  ｄｐｉ）が３２０（ｄｐｉ）で極高解像度となっており、その携帯端末の機種のディスプレイの解像度のみならず、ハードウェア回路全体の演算処理能力の基準とされている。
【００４８】
図７は、上記図３のステップＣ１０１で携帯端末４が送信する、スペック情報としてのバージョン情報ＶＩの先頭側の一部を例示する図である。なお、本実施形態では、スペック情報をバージョン情報として説明しているが、スペック情報（携帯端末のデバイス情報、ＯＳバージョン情報、スクリーン比率、音声発音処理の有無、等）であってもよい。
【００４９】
図示する如く、このバージョン情報ＶＩ中には、携帯端末４のディスプレイ解像度情報ＤＲを含んでいる。このディスプレイ解像度情報ＤＲが、例えば「１６３［ｄｐｉ］」であることにより、携帯端末４側のＣＰＵやグラフィックに用いているチップとそれらのクロック周波数、メインメモリの容量など、トータルでの携帯端末４としてのゲーム実行時の演算処理速度が容易に類推可能となる。
【００５０】
そして、携帯端末４からのスペック情報を受けたウェブサーバ装置２では、上記ステップＳ１０５でプログラムのダウンロードの要求がなされたことを判断すると、受けたバージョン情報ＶＩからディスプレイ解像度情報ＤＲを抽出し（ステップＳ１０６）、そのスペックに基づき、格納している最新バージョンのプログラム中から対応するプログラムを選択する。
【００５１】
次いでウェブサーバ装置２は、携帯端末４から最新バージョンのプログラムのダウンロードが要求されると、これに応答するべく、携帯端末４のスペックに応じた、選択した最新バージョンのプログラムを例えばＪａｖａＳｃｒｉｐｔ（登録商標）で記述した形式で携帯端末４に対して送信する（ステップＳ１０７）。
【００５２】
ここで、例えばＪａｖａＳｃｒｉｐｔ（登録商標）で記述された上記新バージョンのプログラムは、２つの部分からなっている。１つは、すでにインストールしているアプリケーション（古いバーションのプログラム）のどのモジュール（部分）を変更するかを指示する指示部であり、もう１つは、上記変更するモジュールそのものである。
【００５３】
携帯端末４では、ウェブサーバ装置２から送られてきた、自機のスペックに応じた最新バージョンのプログラムをダウンロードすると（ステップＣ１０２）、当該プログラム中のマスタデータを端末内のデータベース領域に保存すると共に、このダウンロードしたプログラムにしたがって既にインストールしていた古いバージョンのプログラムを書き換えて更新設定する（ステップＣ１０３）。
【００５４】
なお、ここで、古いバージョンのプログラムを書き換えるとは、その全てを書き換えるか、または入れ替える処理だけではなく、その一部分のみを書き換えるか、または入れ替える処理でもよい。
【００５５】
その場合、古いバージョンのプログラムには、上記ダウンロードした、例えばＪａｖａｓｃｒｉｐｔ（登録商標）で記述されたプログラムの指示部での指示を受け入れる機能を備えており、且つ、入れ替えや書き換え可能な単位の複数の部分からなっており、上記受け入れる機能が、上記ダウンロードしたプログラムに含まれる上記指示部にしたがって、変更するモジュールを入れ替え、あるいは書き換える。
【００５６】
このようにすることで、上記古いバージョンのプログラムに該当する、最初にインストールするアプリケーションを複数のスペック毎に予め準備することなく、部分的にスペックに合わせたプログラムを用いて調整することができる。
【００５７】
携帯端末４は、この更新設定により、同時に書き換えたチェックサムの情報を再度ウェブサーバ装置２に対して送信する（ステップＣ１０４）。
【００５８】
これに対してウェブサーバ装置２では、携帯端末４からのチェックサムの情報を受けて、プログラムが正常に最新のバージョンのものに書き換えられたことを確認し、確認作業として携帯端末４に対して応答信号を送信し（ステップＳ１０８）、以上で一旦処理を終了し、次に他の携帯端末に対しての処理を待機するべく、上記ステップＳ１０５からの処理に戻る。
【００５９】
一方の携帯端末４では、上記ステップＣ１０４で最新バージョンでのチェックサムの情報をウェブサーバ装置２に対して送信した後、その応答信号を当該ウェブサーバ装置２から受信することでプログラムのバージョンアップの完了を確認し（ステップＣ１０５）、以上でウェブサーバ装置２への一連のログイン処理を完了し、バージョンアップされたゲームの実行に移行する。
【００６０】
以下、ゲームプログラム上でのスペック情報に基づく処理の相違を具体例を用いて説明する。
図８は、ある対戦ゲームで携帯端末４のディスプレイに表示される一シーンを例示している。このようなゲームの進行中、あるゲームキャラクタが攻撃のターン中に繰出した技を視覚効果を交えて表示する場合を考える。
【００６１】
図９（Ａ）は、携帯端末４のスペック情報、すなわちバージョン情報ＶＩ中のディスプレイ解像度情報ＤＲが、予めウェブサーバ装置２側で設定されたしきい値より低く、グラフィックス表示性能が低いと判断された場合に用意されている、当該ゲームのプログラムにしたがった、技を視覚効果を交えて表示した例を示す。
【００６２】
ここでは、それまで表示していた、上記図８に示したゲーム進行上の画面（下層レイヤーの画像）を一切表示することなく（不透明処理）、技の視覚効果のみを画面に表示している例を示す。
【００６３】
これに対して、図９（Ｂ）は、携帯端末４のスペック情報、すなわちバージョン情報ＶＩ中のディスプレイ解像度情報ＤＲが、予めウェブサーバ装置２側で設定されたしきい値より高く、グラフィックス表示性能が高いと判断された場合に用意されている、当該ゲームのプログラムにしたがった、技を視覚効果を交えて表示した例を示す。
【００６４】
ここでは、それまで表示していた、上記図８に示したゲーム進行上の画面（下層レイヤーの画像）が見えるように、上記図９（Ａ）で示した技の視覚効果を半透明化した状態で重ね合わせて画面に表示している例を示す。
【００６５】
このように、携帯端末４のスペックに応じて表示させる画像の内容を変更させることで、必要な画像の表示に関する時間を携帯端末４，５の機種に拘わらず平均化させることができ、オンラインゲームにおける同時性を確保できる。
【００６６】
したがって、対戦ゲームによっては、あるターンで技を出した後に直ぐ次のターンへの準備に移行できるために、スペックが高い機種の方が有利になる場合や、あるいは反対に、あるターンで技を受けている途中であればヒットポイントの回復を準備できるために、スペックが低い機種の方が有利になる場合など、スペックの相違によりゲーム進行上の有利／不利が生じてしまうような事態の発生をできうる限り回避し、公平性を確保できる。
【００６７】
（第２の実施形態）
上記第１の実施形態では、ウェブサーバ装置２側で、予めソースコードからスペックに応じた複数のプログラムを作成した上で格納しておく場合について説明したが、本発明はこれに限らず、クライアント側からスペック情報を取得する毎に、そのスペック情報に基づいてソースコードからプログラムを生成し、生成したプログラムを配信するようにしても良い。
【００６８】
以下、そのような第２の実施形態についても図面を参照して説明する。
なお、本発明の第２の実施形態に係る、オンラインゲームシステムが使用される環境については上記図１と、サーバとクライアント間の接続アーキテクチャの概念については上記図２と、それぞれほぼ同様であるため、同一部分には同一符号を用いるものとして、その図示と説明とを省略する。
【００６９】
次に上記実施形態の動作について説明する。
図１０は、サーバであるウェブサーバ装置２，３と、クライアントである携帯端末４，５との間で実行される、オンラインゲーム開始当初のスペック認証設定に関する処理内容を示す。
【００７０】
ウェブサーバ装置２，３は、ネットワーク１を介して携帯端末４，５側から、スペック情報と共に当該プログラムのダウンロードの要求がなされるのを待機している（ステップＳ２０１）。
【００７１】
一方で、携帯端末４，５の少なくとも一方、例えば携帯端末４がネットワーク１を介してウェブサーバ装置２に接続し、オンラインゲームのサイトにログインした場合、その当初に携帯端末４は自機に既にインストールされているゲームプログラムのバージョン情報をスペック情報としてウェブサーバ装置２へ送信する（ステップＣ２０１）。
【００７２】
ウェブサーバ装置２では、携帯端末４からのスペック情報を受けると、上記ステップＳ２０１でプログラムのダウンロードの要求がなされたことを判断し、続いて受けたバージョン情報からディスプレイ解像度の情報を抽出する（ステップＳ２０２）。
【００７３】
次いでウェブサーバ装置２，３は、既に作成されている１つ（シングル）のソースコードを読込む（ステップＳ２０３）。次にウェブサーバ装置２は、予め複数のＯＳ毎に用意された、それぞれ複数のスペック情報を参照し（ステップＳ２０４）、上記ステップＳ２０１で受信したスペック情報に対応して上記ソースコードを機械語にコンパイルしてプログラム化する（ステップＳ２０５）。ウェブサーバ装置２は、こうして得たプログラムを、自装置内のデータベース２Ａに格納した後（ステップＳ２０６）、ダウンロードを要求してきた携帯端末４，５に対して送信する（ステップＳ２０７）。
【００７４】
携帯端末４では、ウェブサーバ装置２から送られてきた、自機のスペックに応じた最新バージョンのプログラムをダウンロードすると（ステップＣ２０２）、当該プログラム中のマスタデータを端末内のデータベース領域に保存すると共に、このダウンロードしたプログラムにしたがって既にインストールしていた古いバージョンのプログラムを書き換えて更新設定する（ステップＣ２０３）。
【００７５】
携帯端末４は、この更新設定により、同時に書き換えたチェックサムの情報を再度ウェブサーバ装置２に対して送信する（ステップＣ２０４）。
【００７６】
これに対してウェブサーバ装置２では、携帯端末４からのチェックサムの情報を受けて、プログラムが正常に最新のバージョンのものに書き換えられたことを確認し、確認作業として携帯端末４に対して応答信号を送信し（ステップＳ２０９）、以上で一旦処理を終了し、次に他の携帯端末に対して同様の処理を待機するべく、上記ステップＳ２０１からの処理に戻る。
【００７７】
一方の携帯端末４では、上記ステップＣ２０４で最新バージョンでのチェックサムの情報をウェブサーバ装置２に対して送信した後、その応答信号を当該ウェブサーバ装置２から受信することでプログラムのバージョンアップの完了を確認し（ステップＣ２０５）、以上でウェブサーバ装置２への一連のログイン処理を完了し、バージョンアップされたゲームの実行に移行する。
【００７８】
図１１は、各携帯端末４，５にそれぞれインストールされたプログラムの構成概念を示す図である。ここでは、携帯端末４がＯＳとしてプログラムＡ（ｅｘ．ｉＰｓＯＳ４．０）を採用した機種であるものとし、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。
【００７９】
一方で携帯端末５は、ＯＳとして上記プログラムＡよりもバージョンが上位であるプログラムＢ（ｅｘ．ｉＰｓＯＳ４．３）を採用した機種であるものとし、やはり同様にＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳを含む各種プログラミング言語で記述されたアプリケーションプログラム群を構築しているものとする。
【００８０】
この場合、プログラムＡをインストールしている携帯端末４では、複数のレイヤー画像を重ねてディスプレイに表示させるにあたって、演算処理能力が低く、時間を要するものとした場合、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像をあえて不透明とする画像表示処理を採用するものとする。
【００８１】
一方で、同一のアプリケーションプログラムを実行するにあたって、プログラムＢをインストールしている他方の携帯端末５では、複数のレイヤー画像を重ねてディスプレイに表示させる際、演算処理能力が高く、処理負荷が小さいものとして、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって、より上層のレイヤーの画像を半透明化する画像表示処理を採用するものとする。
【００８２】
図１２は、ウェブサーバ装置２（３）側がデータベース２Ａ（３Ａ）に予め備える、各携帯端末の機種毎のスペック情報を例示する図である。ここでは機種名「デバイスｘ．ｘ．ｘ」毎にＯＳのバージョン情報、１画素のアスペクト比、スクリーンＤＰＩ（Ｄｏｔ  Ｐｅｒ  Ｉｎｃｈ）、スクリーン画素数Ｘ、スクリーン画素数Ｙ、及び、（アプリケーション対応の）オーディオ（音声発音処理）の有無、等の各種情報が予め格納されている。
【００８３】
上記スクリーンＤＰＩは、本来は画面の解像度を示す指標であるが、本実施形態ではスペック情報全体を代表する指標として用いるものとする。
【００８４】
以上詳述した如く上記第１及び第２の実施形態によれば、アプリケーションプログラムを提供する側の負担を軽減すると共に、オンラインで対戦通信を行なうようなアプリケーションプログラムで端末間のスペックの相違による不公平が発生するのを確実に防止することが可能となる。
【００８５】
また上記実施形態では、スペック情報として、バージョン情報ＶＩ中のディスプレイ解像度情報ＤＲに基づいてクライアント機の機種のスペックの行程を判断するものとしたが、このようにゲームプログラムでスペックに応じた処理時間の相違が露呈し易いグラフィックス演算に関する部分を、ディスプレイ解像度情報ＤＲを基準として判断するものとしたので、判断のための基準が明解であり、ウェブサーバ装置２側での処理を簡易化できる。
【００８６】
なお上記第１及び第２の実施形態はいずれも、対戦型のオンラインゲームのプログラムに適用した場合の例について説明したが、本発明は配信するアプリケーションプログラムの種類等を限定するものではなく、他の各種アプリケーションプログラムにも同様に適用可能である。
【００８７】
その他、本発明は上述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、上述した実施形態で実行される機能は可能な限り適宜組み合わせて実施しても良い。上述した実施形態には種々の段階が含まれており、開示される複数の構成要件による適宜の組み合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、効果が得られるのであれば、この構成要件が削除された構成が発明として抽出され得る。以下に、本願の原出願の分割直前の特許請求の範囲に記載された発明を付記する。
［１］
クライアント機と通信可能であり、対戦ゲームを実現する情報処理装置に、
前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
前記クライアント機は、所定のスペックを有する第１クライアント機と、前記所定のスペックより高いスペックを有する第２クライアント機とを含み、
前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる
プログラム。
［２］
前記クライアント機に配信するステップにおいて、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を配信する、上記［１］に記載のプログラム。
［３］
前記アプリケーションプログラムは、前記指示を受け入れる機能を備え、
前記受け入れる機能が、前記指示に従って、前記アプリケーションプログラムの一部分を入れ替える又は書き換える、上記［２］に記載のプログラム。
［４］
クライアント機と通信可能であり、対戦ゲームを実現する情報処理装置に実行させるプログラム配信方法であって、
前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を有し、
前記クライアント機は、所定のスペックを有する第１クライアント機と、前記所定のスペックより高いスペックを有する第２クライアント機とを含み、
前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる
プログラム配信方法。
【符号の説明】
【００８８】
１…ネットワーク、２，３…ウェブサーバ装置、４，５…携帯端末、６…アクセスポイント（ＡＰ）、７…基地局、ＤＲ…ディスプレイ解像度情報、ＶＩ…バージョン情報。
【図１】
2018043035.tif 000003
【図２】
2018043035.tif 000004
【図３】
2018043035.tif 000005
【図４】
2018043035.tif 000006
【図５】
2018043035.tif 000007
【図６】
2018043035.tif 000008
【図７】
2018043035.tif 000009
【図８】
2018043035.tif 000010
【図９】
2018043035.tif 000011
【図１０】
2018043035.tif 000012
【図１１】
2018043035.tif 000013
【図１２】
2018043035.tif 000014