以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
1.処理システム、端末装置、サーバシステムの構成
図1に本実施形態の処理システムの構成例を示す。この処理システムは、サーバシステム500と、複数の端末装置TM1〜TMnを含む。
サーバシステム500は、ネットワーク510を介して、端末装置TM1〜TMnと通信接続される。例えばサーバシステム500はホストであり、端末装置TM1〜TMnはクライアントである。サーバシステム500は例えば1又は複数のサーバ(管理サーバ、ゲームサーバ、サービス提供サーバ、コンテンツ配信サーバ、認証サーバ、通信サーバ又は課金サーバ等)により実現できる。ネットワーク510(配信網、通信回線)は、例えばインターネットや無線LAN等を利用した通信路であり、直接接続のための専用線(専用ケーブル)やイーサネット(登録商標)等によるLANの他、電話通信網やケーブル網や無線LAN等の通信網を含むことができる。また通信方法については有線/無線を問わない。
図2に本実施形態の端末装置の構成例を示す。なお、端末装置の構成は図2に限定されず、その構成要素(各部)の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。本実施形態の端末装置としては、ゲーム装置(携帯型ゲーム装置、家庭用ゲーム装置等)、携帯端末(携帯電話機、スマートフォン等)、或いはPC(パーソナルコンピュータ)などの種々の機器を想定できる。
操作部160は、ユーザ(プレーヤ)が種々の情報(操作データ等)を入力するためのものであり、その機能は、操作ボタン、方向指示キー、アナログスティック、レバー、各種センサ(角速度センサ、加速度センサ等)、マイク、或いはタッチパネル型ディスプレイなどにより実現できる。
記憶部170は、処理部100や通信部196などのワーク領域となるもので、その機能はRAM(DRAM、SRAM、VRAM)やHDD(ハードディスクドライブ)などにより実現できる。
情報記憶媒体180(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(DVD、CD等)、HDD、或いはメモリ(ROM等)などにより実現できる。処理部100は、情報記憶媒体180に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体180には、本実施形態の各部としてコンピュータ(操作部、処理部、記憶部、出力部を備える装置)を機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。
表示部190は、本実施形態により生成された画像を出力するものであり、その機能は、LCD、有機ELディスプレイ、CRT、或いはHMDなどにより実現できる。音出力部192は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
I/F(インターフェース)部194は、携帯型情報記憶媒体195とのインターフェース処理を行うものであり、その機能はI/F処理用のASICなどにより実現できる。携帯型情報記憶媒体195は、ユーザがゲームプレイするための各種情報が記憶されるものであり、ICカード(メモリーカード)、USBメモリー、或いは磁気カードなどにより実現できる。
通信部196は、有線や無線のネットワークを介して外部装置(例えば他の端末装置、サーバ等)との間で通信を行うものであり、その機能は、通信用ASIC又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
なお本実施形態の各部としてコンピュータを機能させるためのプログラム(データ)は、サーバシステム(ホスト装置)が有する情報記憶媒体からネットワーク及び通信部196を介して情報記憶媒体180(あるいは記憶部170)に配信してもよい。このようなサーバシステムによる情報記憶媒体の使用も本発明の範囲内に含めることができる。
処理部100(プロセッサ)は、操作部160からの操作データやプログラムなどに基づいて、ゲーム処理、各種サービス提供のための処理、画像生成処理、或いは音生成処理などを行う。処理部100は記憶部170をワーク領域として各種処理を行う。この処理部100の機能は、各種プロセッサ(CPU、GPU等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
処理部100は、入力受け付け部101、ゲーム演算部102、オブジェクト空間設定部104、移動体演算部106、仮想カメラ制御部108、条件判断部110、条件変更部112、処理モード設定部114、発症処理部116、治癒処理部118、表示制御部120、音制御部130を含む。なおこれらの構成要素の一部(例えばゲーム演算部102等)を省略したり、他の構成要素を追加するなどの変形実施が可能である。
入力受け付け部101は、ユーザからの入力情報の受け付け処理を行う。例えば操作部160を介して入力された情報の受け付け処理を行う。
ゲーム演算部102はゲーム演算処理を行う。ここでゲーム演算としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム成績の演算処理、或いはゲーム終了条件が満たされた場合にゲームを終了する処理などがある。
オブジェクト空間設定部104は、複数のオブジェクトが配置されるオブジェクト空間の設定処理を行う。例えば、移動体(車、人、飛行機、船舶、ロボット、動物等)、マップ(地形)、建物、コース(道路)、樹木、壁などの表示物を表す各種オブジェクト(ポリゴン、自由曲面又はサブディビジョンサーフェイスなどのプリミティブ面で構成されるオブジェクト)をオブジェクト空間に配置設定する処理を行う。
移動体演算部106は、移動体を移動させるための演算を行う。また移動体(移動体オブジェクト)を動作させるための演算も行う。即ち操作部160によりユーザが入力した操作データや、プログラム(移動・動作アルゴリズム)や、各種データ(モーションデータ)などに基づいて、移動体(オブジェクト、モデルオブジェクト)をオブジェクト空間内で移動させたり、移動体を動作(モーション、アニメーション)させる処理を行う。
仮想カメラ制御部108は、オブジェクト空間内の所与(任意)の視点から見える画像を生成するための仮想カメラ(視点、基準仮想カメラ)の制御処理を行う。
条件判断部110、条件変更部112、処理モード設定部114、発症処理部116、治癒処理部118の詳細については後述する。
表示制御部120は、表示部190に画像を表示するための制御を行う。例えば端末装置側で画像を生成する場合には、処理部100で行われる種々の処理(ゲーム処理、シミュレーション処理)の結果に基づいて描画処理を行い、これにより画像を生成し、表示部190に出力する。サーバシステム側で画像を生成する場合には、サーバシステムからの画像生成用データに基づく画像を表示部190に表示する制御を行う。音制御部130は、処理部100で行われる種々の処理の結果に基づいて音制御を行う。これにより、BGM、効果音、又は音声などのゲーム音が音出力部192から出力されるようになる。
図3に本実施形態のサーバシステム500(ホスト装置)の構成例を示す。なお、サーバシステム500の構成は図3に限定されず、その構成要素(各部)の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
サーバシステム500は、処理部600、操作部660、記憶部670、通信部696を含む。
処理部600は、通信部696を介して受信したデータや、記憶部670に記憶されるデータ、プログラム等に基づいて、サーバの各種サービス・管理に必要な種々の処理を行う。この処理部600の機能は、各種プロセッサ(CPU、GPU等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
処理部600は、入力受け付け部602、条件設定部604、条件変更部606、発動処理部608、管理部610、画像生成用データ生成部620、音生成用データ生成部630を含む。入力受け付け部602、条件設定部604、条件変更部606、発動処理部608の詳細については後述する。
管理部610は、サーバの各種の管理処理を行う。例えば、サーバが提供する各種サービスの管理処理、ユーザ情報や課金情報などの各種情報の管理処理を行う。画像生成用データ生成部620は、画像を生成するための画像生成用データを生成する。音生成用データ生成部630は、音(音声、ゲーム音、効果音)を生成するための音生成用データを生成する。ここで、画像を生成するための画像生成用データとは、本実施形態の手法により生成された画像を各端末装置TM1〜TMnにおいて生成・表示するためのデータであり、画像データそのものであってもよいし、各端末装置が画像を生成・表示するために使用する各種データ(表示画面の設定データ、オブジェクトデータ等)であってもよい。音生成用データ生成部630が生成する音生成用データについても同様である。
操作部660は、システムの管理者(運営者)が種々の情報を入力するためのものである。記憶部670は、処理部600や通信部696などのワーク領域となるものであり、その機能はRAMなどのメモリやHDDにより実現できる。記憶部670は条件記憶部672、ユーザ情報記憶部674を含む。情報記憶媒体680(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、HDD、或いはメモリ(ROM等)などにより実現できる。この情報記憶媒体680には、サーバシステム500(処理システム)の各部をコンピュータとして機能させるためのプログラムが記憶されている。通信部696は、有線や無線のネットワーク510を介して端末装置TM1〜TMnや外部の他のサーバとの通信を行うものであり、その機能は、通信用ASIC又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
次に、端末装置の構成・動作について詳細に説明する。本実施形態では、図2に示すように端末装置が、条件判断部110と、処理モード設定部114と、表示制御部120を有する。
条件判断部110は、仮想コンピュータウィルスの発症条件が満たされたか否かを判断する。処理モード設定部114は、仮想コンピュータウィルスの発症条件が満たされたと判断された場合に、処理モードを、通常処理モードから発症処理モードに切り替える。そして表示制御部120は、処理モードにしたがった画像を表示部190に表示するための制御を行う。例えば通常処理モードでは、通常処理モード用の画像を表示部190に表示する制御を行い、発症処理モードでは、発症処理モード用の画像を表示部190に表示する制御を行う。
いわゆるコンピュータウィルスは、そのプログラムの実行を予定していない端末装置内に侵入し、端末装置内のファイルやシステム等を破壊することを目的とする悪意のプログラムである。
一方、本実施形態の仮想コンピュータウィルスは、例えば、その処理の実行が端末装置側において予め予定されている。そして、端末装置側において各種のイベントを発生させて、ネットワークへのユーザ参加の動機づけを与えることを目的としている。
具体的には、仮想コンピュータウィルスの発症処理が発動されると、端末装置側の処理モードが通常処理モードから発症処理モードに切り替わる。即ち、端末装置側においては、仮想コンピュータウィルスにより、処理モードが発症処理モードに切り替わることが予定されており、そのような処理モードを切り替えるシステムが端末装置側に組み込まれている。そして、仮想コンピュータウィルスの発症条件が満たされると、当該システムが起動して、端末装置側の処理モードが通常処理モードから発症処理モードに切り替わる。具体的には、後述するように、例えば、サーバから発動情報として送信されて来たIDリストの中に、自身の端末装置のIDが含まれていた場合には、当該端末装置での仮想コンピュータウィルスの発症条件が満たされて、処理モードが発症処理モードに切り替わる。そして、端末装置において仮想コンピュータウィルスの発症時用のイベントが発生する。例えば仮想コンピュータウィルスの発症時用に用意された画像が端末装置の表示部に表示される。このようにすることで、話題作りのイベントを発生させることが可能になり、ネットワークへのユーザの参加の動機づけを創出できる。なお、処理モードの切り替え処理等を行う仮想コンピュータウィルス用のプログラムは、パッチプログラムとして端末装置側にダウンロードされるものであってもよい。
また本実施形態では、条件判断部110は、仮想コンピュータウィルスの治癒条件が満たされたか否かを判断する。そして処理モード設定部114は、仮想コンピュータウィルスの治癒条件が満たされたと判断された場合に、処理モードを、発症処理モードから通常処理モード又は治癒処理モードに切り替える。即ち、処理モードを、発症処理モードから通常処理モードに戻したり、発症処理モードから、治癒時用の専用のモードである治癒処理モードに切り替える。
このようにすれば、仮想コンピュータウィルスの発症条件が満たされて発症処理モードに移行した場合にも、治癒条件が満たされることで、発症処理モードから通常処理モードに戻ったり、治癒時用の治癒処理モードに切り替わるようになる。
また入力受け付け部101は、ユーザからの入力情報を受け付ける。例えば操作部160により入力した情報を受け付ける。そして条件判断部110は、入力受け付け部101により受け付けられたユーザからの入力情報に基づいて、治癒条件が満たされたか否かを判断する。具体的には、ゲーム演算部102は、入力情報に基づいてゲーム演算処理を行う。例えばゲーム演算部102は、ユーザが操作部160を操作して入力した情報に基づいて、ゲーム開始処理、ゲーム進行処理、ゲーム成績演算処理、或いはゲーム終了処理などのゲーム演算処理を行う。そして条件判断部110は、ゲーム演算処理でのゲーム成績情報に基づいて、治癒条件が満たされたか否かを判断する。例えばゲーム成績情報であるゲームの勝敗情報、得点情報、或いはクリアレベル情報等に基づいて、治癒条件が満たされたか否かを判断する。そして、治癒条件が満たされると、処理モードが発症処理モードから通常処理モード又は治癒処理モードに切り替わる。
また処理モード設定部114は、治癒処理モードに切り替わった場合には、ユーザからの入力情報に基づいて、通常処理モードと発症処理モードとの間の切り替え処理を行う。このようにすれば、治癒処理モードでは、ユーザの意思により通常処理モードと発症処理モードとを任意に切り替えることが可能になる。
また条件判断部110は、仮想コンピュータウィルスの伝染条件が満たされた場合に、発症条件が満たされたと判断する。そして処理モード設定部114は、伝染条件が満たされて発症条件が満たされたと判断された場合に、処理モードを、通常処理モードから発症処理モードに切り替える。このようにすれば、仮想コンピュータウィルスが次々と伝染して行く伝染処理を実現できるようになる。
具体的には条件判断部110は、発症処理モードとなった他のユーザの端末装置との間でネットワークを介したデータ通信が行われた場合に、伝染条件が満たされたと判断する。例えば複数のユーザの端末装置がネットワーク接続されて、ネットワーク対戦等が行われたとする。この場合には、これらの複数のユーザの中に仮想コンピュータウィルスに感染されたユーザが存在すると、他のユーザの端末装置に仮想コンピュータウィルスが伝染し、発症処理が実行されるようになる。
或いは条件判断部110は、仮想コンピュータウィルスに感染したと判断されたコンテンツデータを受信した場合に、伝染条件が満たされたと判断する。例えば、仮想コンピュータウィルスに感染したユーザに関連づけられたコンテンツデータを受信した場合に、伝染条件が満たされたと判断する。具体的には、仮想コンピュータウィルスの感染フラグがオンになったコンテンツデータを受信した場合に、伝染条件が満たされたと判断する。このようにすれば、コンテンツデータを介して、仮想コンピュータウィルスが次々と伝染して行く伝染処理を実現できるようになる。
ここで、伝染処理が実現されるコンテンツデータは、ユーザの過去のプレイ履歴に基づき作成されコンピュータ制御移動体を制御するためのゴーストデータを想定できる。ゴーストデータは、分身データやプレイデータと呼ばれるものであり、ネットワークゲームの参加ユーザの過去のプレイ履歴に基づき作成される。このゴーストデータは、例えば、ユーザの過去のプレイにおける操作履歴情報(キー入力情報)を含むことができる。また、この操作履歴情報に加えて、移動体(ゴーストカー)の位置情報や方向情報(トレイルデータ)を含んでもよい。このような位置情報、方向情報を持たせることで、操作履歴情報に基づき制御される移動体(ゴーストカー)のコース上での移動の補正処理などを行うことが可能になる。
なお、伝染処理が実現されるコンテンツデータは、このようなゴーストデータに限定されず、ゴーストデータ以外のゲームデータであってもよい。例えば、特定の条件を満たすことでユーザに付与されるアイテムデータ等のゲームデータであってもよい。或いはコンテンツデータは、映像配信における映像(画像)データや、音楽配信における音楽データなどであってもよい。
また条件判断部110は、仮想コンピュータウィルスに感染したと判断された他のユーザの位置情報に基づいて、伝染条件が満たされたか否かを判断してもよい。例えば第1の端末装置を所持する第1のユーザの位置情報と第2の端末装置を所持する第2のユーザの位置情報に基づいて、第1、第2のユーザが接近したと判断された場合に、伝染条件が満たされたと判断する。この場合に、第1、第2のユーザの位置情報は、例えば第1、第2の端末装置が有するGPSセンサーにより特定したり、端末装置用の位置情報サービスを利用して特定できる。
また条件判断部110は、発症条件及び治癒条件の少なくとも一方の条件が満たされたか否かを、ユーザの課金情報に基づいて判断してもよい。例えばユーザの課金等を条件に、発症条件が満たされたと判断して、そのユーザの端末装置の処理モードを、通常処理モードから発症処理モードに切り替える。或いはユーザの課金等を条件に、治癒条件が満たされたと判断して、そのユーザの端末装置の処理モードを、発症処理モードから通常処理モード又は治癒処理モードに切り替える。
また条件変更部112は、発症条件及び治癒条件の少なくとも一方の条件の変更処理を行う。例えば条件変更部112は、仮想コンピュータウィルスの感染状況情報、ネットワークへのユーザの参加状況情報及びコンテンツの配信状況情報の少なくとも1つに基づいて、発症条件及び治癒条件の少なくとも一方の条件の変更処理を行う。即ち仮想コンピュータウィルスの感染状況や、ネットワークへのユーザの参加状況や、仮想コンピュータウィルスの対象となるコンテンツの配信状況などに応じて、発症条件や治癒条件をリアルタイムに変更する。
発症処理部116は、発症時用の各種の処理を行う。例えば発症時用の各種イベントを発生させるための処理を行う。具体的には、発症時用の画像を表示部190に表示するための処理や、発症時用の各種選択操作を実現するための処理などを行う。治癒処理部118は、治癒時用の各種の処理を行う。例えば治癒時用の各種イベントを発生させるための処理を行う。具体的には、治癒時用の画像を表示部190に表示するための処理や、治癒時用の各種選択操作を実現するための処理を行う。
次に、サーバシステム500の構成・動作について詳細に説明する。本実施形態では、図3に示すようにサーバシステム500が、条件設定部604と、発動処理部608と、記憶部670と、通信部696を有する。
そして条件設定部604は、仮想コンピュータウィルスの発症処理を発動させる条件である発動条件の設定処理を行う。記憶部670(条件記憶部672)は、設定された発動条件を記憶し、通信部696は、端末装置TM1〜TMnとの通信を行う。発動処理部608は、発動条件が満たされたユーザの端末装置において仮想コンピュータウィルスの発症処理を発動させるための発動処理を行う。具体的には、発動処理部608は、発動処理として、ユーザの端末装置の処理モードを、通常処理モードから発症処理モードに移行させるための処理を行う。これは、例えば発動処理部608が、発動処理として、ユーザの端末装置に対して、仮想コンピュータウィルスの発症処理を発動させるための発動情報の送信処理を行うことなどで実現できる。この場合に、例えば発動処理部608は、発動情報として、仮想コンピュータウィルスの発症処理の対象(候補)となるユーザのIDリスト(候補リスト)の送信処理を行う。例えば発動処理部608は、通信部696に対して、IDリスト等の発動情報の送信指示を行う。なお、以下ではサーバシステムを、適宜、サーバと記載する。
入力受け付け部602は、サーバの管理者(運営者)の入力情報を受け付ける。例えば操作部660を介して入力された情報を受け付ける。そして条件設定部604は、入力受け付け部602により受け付けられた管理者からの入力情報に基づいて、発動条件を設定する。例えば管理者により、感染候補となるユーザのIDリストの情報が入力されると、このIDリストの情報により発動条件が設定される。そして、そのIDリストが発動情報として端末装置に送信され、IDリストに含まれるIDのユーザに対応する端末装置において、発症処理が発動されるようになる。
なお条件設定部604は、端末装置からの情報に基づいて、発動条件を設定してもよい。例えば第1のユーザの端末装置から、第2のユーザの端末装置の感染を指示する情報を受信した場合に、その情報に基づいて発動条件を設定して、第2のユーザの端末装置の発症処理を発動するようにしてもよい。また、仮想コンピュータウィルスの発生対象となるソフトウェアと同じメーカのソフトウェアを所持しているか否かを、端末装置からの情報に基づいて判断し、同じメーカのソフトウェアを所持していることを、仮想コンピュータウィルスの発症条件として設定してもよい。
また条件設定部604は、条件が満たされるか否かが、ユーザ情報に基づき判断される条件を、発動条件として設定してもよい。具体的には、条件が満たされるか否かが、ユーザの識別情報、ユーザの位置情報及びユーザの課金情報の少なくとも1つを含むユーザ情報に基づき判断される条件を、発動条件として設定する。
ここで、ユーザの識別情報は、ユーザID、名前等のユーザを識別・特定するための情報である。ユーザの位置情報は、例えばユーザが所持する端末装置等の位置情報である。この位置情報は例えば端末装置のGPSセンサにより取得できる。なおGPSセンサの代わりに携帯端末の位置情報サービスを利用して位置情報を取得してもよい。また、ユーザの位置情報は、仮想世界におけるユーザのアバタ等の位置情報であってもよい。ユーザの課金情報は、当該ソフトウェアのサービスを受けるユーザの課金金額等である。これらのユーザ情報はサーバのユーザ情報記憶部674に記憶される。
また条件設定部604は、条件が満たされるか否かが、収集された環境情報に基づき判断される条件を、発動条件として設定してもよい。例えばサーバシステムやユーザを取り巻く環境に応じて変化する発動条件を設定する。ここで環境情報は、例えば天候、気温、又はネットワーク環境などの情報である。
また条件設定部604は、条件が満たされるか否かが、ユーザのゲーム成績情報に基づき判断される条件を、発動条件として設定してもよい。例えばゲーム成績が高いユーザや所定のクリアレベルに達したユーザが、仮想コンピュータウィルスの感染対象となるような発動条件を設定する。
また条件設定部604は、特定グループに属するユーザの端末装置を発症処理の対象とする発動条件を設定してもよい。例えば、複数のユーザで構成される第1〜第Nのグループが存在する場合に、これらの第1〜第Nのグループの中から選出された特定の1又は複数のグループが発症処理の対象となるような発動条件を設定する。この場合に条件設定部604は、特定グループの設定を、特定グループに属するユーザの課金情報に基づいて行ってもよい。例えば課金金額が多いユーザが属するグループを、発症処理の対象となるグループとして優先的に選択するようにする。
また発動条件の変更処理を行う条件変更部606を設けてもよい。即ち、条件設定部604により設定されて条件記憶部672に記憶して保存された発動条件を変更する処理を、条件変更部606が行う。例えば条件変更部606は、仮想コンピュータウィルスの感染状況情報、ネットワークへのユーザの参加状況情報及びコンテンツの配信状況情報の少なくとも1つに基づいて、発動条件の変更処理を行う。即ち仮想コンピュータウィルスの感染状況や、ネットワークへのユーザの参加状況や、仮想コンピュータウィルスの対象となるコンテンツの配信状況などに応じて、発動条件を例えばリアルタイムに変更する。
なお、本実施形態における仮想コンピュータウィルスの発症処理は、例えば仮想コンピュータウィルスに感染したと判断されたユーザの端末装置において、発症時用の画像を表示するための処理である。例えば、感染前の通常処理モードでは表示されなかった発症時用の画像を、仮想コンピュータウィルスの発症処理において端末装置の表示部に表示するようにする。なお、仮想コンピュータウィルスの発症処理は、これに限定されず、発症時用のイベントを発生するための種々の処理を想定できる。
なお、以上では発症条件、治癒条件などの判断処理や、処理モードの切り替え処理などを端末装置が行う場合について説明したが、本実施形態はこれに限定されない。これらの条件の判断処理や処理モードの切り替え処理をサーバが行ってもよい。
例えば図4では、サーバシステム500に、端末用処理部(端末用処理エンジン)690-1〜690-nが設けられている。これらの端末用処理部690-1〜690-nは、端末装置TM1〜TMn用の各種処理を行う。例えば端末用処理部690-1は端末装置TM1に割り当てられ、TM1用の処理を行い、端末用処理部690-2は端末装置TM2に割り当てられ、TM2用の処理を行う。
ここで端末用処理部690-1〜690-nが行う処理は、例えば図2の条件判断部110、条件変更部112、処理モード設定部114、発症処理部116、或いは治癒処理部118等が行う処理である。即ち、図4では、サーバシステム500が、仮想コンピュータウィルスの発症条件が満たされたか否かを判断する条件判断部と、発症条件が満たされたと判断された場合に、処理モードを、通常処理モードから発症処理モードに切り替える処理モード設定部を有している。またサーバシステム500の条件判断部が、仮想コンピュータウィルスの治癒条件が満たされたか否かを判断する。そしてサーバシステム500の処理モード設定部が、治癒条件が満たされたと判断された場合に、処理モードを、発症処理モードから通常処理モード又は治癒処理モードに切り替える。このように、端末装置が行っていた処理をサーバシステム500が行うことで、端末装置側の処理負荷を軽減できる。なお、これらの処理は、いわゆるクラウドを用いた分散処理により実現してもよい。また、端末用処理部690-1〜690-nで重複する処理は、共通処理として実行することが望ましい。また、図4では、端末装置TM1〜TMnの表示部で表示される画像の生成も、サーバシステム500の端末用処理部690-1〜690-nが行っている。即ち、端末用処理部690-1〜690-nの画像生成部で各種の画像が生成され、生成された画像が端末装置TM1〜TMnの表示部に表示される。
2.本実施形態の手法
次に本実施形態の手法について詳細に説明する。なお、以下では、本実施形態の手法をゲームに適用した場合について主に説明するが、本実施形態の適用例はこれに限定されない。例えば、ソーシャルネットワーク・サービスを実現する処理システムや、コンテンツ配信などを実現する処理システムにも本実施形態の手法を適用できる。
2.1 仮想コンピュータウィルス
ネットワークゲームやソーシャルネットワーク・サービスでは、ネットワークへの参加のユーザの動機づけを如何にして創出するかが課題となる。ネットワークゲームを例にとれば、ゲームソフトの発売後に、ユーザ間の話題作りを行うために、ゲーム内に各種のイベントを発生させることが望ましい。こうすることで、ゲームをインターネットに繋いで遊んで貰うための効果的な動機づけをユーザに与えることができる。
そこで本実施形態では、仮想コンピュータウィルスの概念を導入し、例えばゲームソフトなどのソフトウェアのリリース後(発売後)から一定期間が過ぎてから、運営側の任意のタイミングで、ごく限られた小数のユーザから仮想コンピュータウィルスが徐々に広がって行くような仕組みを実現する。
例えば、一般的なコンピュータウィルスは、その実行を予定していない端末装置内に侵入し、ファイルやシステム等を破壊するという悪意の目的のプログラムである。
これに対して、本実施形態の仮想コンピュータウィルスは、端末装置側に様々なイベントを発生させて、ネットワークへのユーザ参加を促すことを目的とする仮想的なものであり、コンピュータウィルスとは異なる。
具体的には本実施形態では、図5(A)に示すように、TM1〜TMnの各端末装置の条件判断部110は、仮想コンピュータウィルスの発症条件が満たされたか否かを判断する。そして、発症条件が満たされたと判断された場合には、処理モード設定部114は、処理モードを、通常処理モードから発症処理モードに切り替える。そして端末装置の表示部には、処理モードにしたがった画像が表示される。即ち、発症処理モード用の画像が表示される。
例えば本実施形態では、後述するように、サーバシステム500から端末装置に対して、仮想コンピュータウィルスの発症候補となるユーザのIDリストが、発動情報として送信される。そして条件判断部110は、このようにサーバシステム500から送信されて来たIDリスト内に、自身のIDが含まれていた場合には、発症条件が満たされたと判断して、処理モードを発症処理モードに切り替える。或いは後述する伝染条件が満たされた場合に、発症条件が満たされたと判断する。例えば図5(A)では、サーバシステム500からのIDリスト内に端末装置TM1のユーザのIDが含まれていたため、端末装置TM1の処理モードは、通常処理モードから発症処理モードに切り替わっている。一方、IDリスト内には端末装置TM2のIDは含まれていなかったため、端末装置TM2の処理モードは通常処理モードのままとなる。
このように端末装置が発症処理モードになると、表示部に発症時用の画像が表示されたり、発症時用のモードが選択可能になるなどの発症時用の種々のイベントが発生する。その後、図5(B)に示すように、端末装置の条件判断部110は、仮想コンピュータウィルスの治癒条件が満たされたか否かを判断する。そして治癒条件が満たされたと判断された場合に、処理モード設定部114は、処理モードを、発症処理モードから通常処理モードに戻す。或いは発症処理モードから治癒処理モードに切り替える。この治癒処理モードでは、例えばユーザからの入力情報に基づいて、通常処理モードと発症処理モードとの間の切り替えが可能になる。例えば、悪意を目的とする通常のコンピュータウィルスでは、通常状態(正常状態)と発症状態の切り替えはできないが、本実施形態の仮想コンピュータウィルスは、発症処理や治癒処理がシステムに予め組み込まれているため、このような切り替えが可能になる。
また本実施形態では、仮想コンピュータウィルスの発症処理を発動(activate)する発動条件が満たされた場合に、端末装置側に予め用意された仮想コンピュータウィルスの発症処理が発動するようにしてもよい。具体的には、発動条件が満たされて発症処理が発動すると、端末装置側の処理モードが通常処理モードから発症処理モードに切り替わる。この場合に、発動条件の設定により、最初の発症候補数を限定することで、初期段階ではごく限られたユーザだけが感染するようになる。そして、このユーザの端末装置において、発症時用の画像が生成されたり発症時用のモードが選択できるなどの種々のイベントが発生する。その後、後述する伝染処理により、感染ユーザの数が徐々に増えて行き、コンピュータウィルスの伝染のような状況・仕組みを創出できる。
また、発動条件の設定は、例えばサーバ側で行うことができる。従って、サーバの運営者(ソフトウェアのメーカ等)が所望する任意のタイミングで、仮想コンピュータウィルスの発症処理を発動できるようになる。ゲームソフトを例に取れば、その発売後の一定期間が過ぎてから、仮想コンピュータウィルスの発症処理を発動するようにする。このようにすれば、ゲームソフトの発売後、ネットワークゲームへの参加人数が減ってきた場合等に、ユーザの端末装置において仮想コンピュータウィルスによるイベントを徐々に発生させることで、その話題がユーザ間で広まり、ネットワークゲームへのユーザ参加の効果的な動機づけを与えることが可能になる。
そして、本実施形態では発症処理用のシステム等が端末装置側に予め組み込まれているため、仮想コンピュータウィルスにより発生するイベントも任意に制御できる。また、発症処理から通常処理に戻す治癒処理も容易に実現することが可能になる。
図6(A)、図6(B)は、本実施形態の発動処理を説明する図である。図6(A)に示すようにサーバシステム500の条件設定部604は、仮想コンピュータウィルスの発動条件の設定処理を行い、設定された発動条件は条件記憶部672に設定される。例えば、サーバの運営者(管理者)により、「X年Y月Z日にユーザUSi〜USjの端末装置において仮想コンピュータウィルスを発症させる」という発動条件が入力されると、この発動条件が条件記憶部672に記憶される。
そして図6(B)に示すように、この発動条件を条件記憶部672から読み出した発動処理部608は、ユーザの端末装置において仮想コンピュータウィルスの発症処理を発動させるための発動処理を実行する。具体的には、ユーザの端末装置に対して、仮想コンピュータウィルスの発症処理を発動させるための発動情報(IDリスト等)を送信する。上記の「X年Y月Z日にユーザUSi〜USjの端末装置において仮想コンピュータウィルスを発症させる」という発動条件を例にとれば、X年Y月Z日になると、ユーザUSi〜USjを指定するIDリストが、サーバシステム500から端末装置TM1〜TMnに送信される。すると、TM1〜TMnの各端末装置は、送信されて来たIDリスト内に自身のIDが含まれているか否かを判断し、自身のIDが含まれていた場合には、自身が仮想コンピュータウィルスの発症候補であると認識する。そして、端末装置側のシステムに予め組み込まれている発症処理が起動する。これにより、当該端末装置は仮想コンピュータウィルスに発症した状態になる。なお、IDリストに自身のIDが含まれている場合に、100パーセントの確率で発症するのではなく、所定確率で発症するようにしてもよい。治癒処理についても同様である。
2.2 ゲームへの適用
次に本実施形態の手法のゲームへの適用例について説明する。なお本実施形態の手法は、ゲームのみならず、例えばソーシャルネットワークの各種サービスなどにも適用できる。
本実施形態の手法が適用されるゲームでは、発売後に、ユーザ(プレーヤ)間の話題作りを行うために、仮想コンピュータウィルスによりゲーム内に各種イベントを発生させる。このため仮想コンピュータウィルスは、ゲームソフトの発売後、しばらくしてから(例えば1、2ヶ月後)、発生させ、発売直後には発生させない。
本実施形態の仮想コンピュータウィルスは「悪魔のギフト」と呼ばれ、コンピュータウィルスを疑似したものである。この仮想コンピュータウィルスは、通信対戦モードやゴーストデータのやり取りなどを通じてユーザ間を伝染して行く。仮想コンピュータウィルスに感染すると、ユーザがデビル化する。デビル化すると、メニュー画面が「小悪魔化」したり、デビル対決モードでデビルカーとの対戦が楽しめるようになる。また、自らが新たな感染源となる。仮想コンピュータウィルスに感染するためにはユーザはネットワークに繋げる必要があるため、ネットワークに繋ぐ動機づけになる。
次に、ユーザの元で起こる出来事の流れについて説明する。ユーザは、通信対戦(インターネットバトル、フェイス・トゥー・フェイスバトル)を行ったり、ゴーストバトルモードでゴーストデータのダウンロードを行う。そして、通信対戦のルームにデビル化したユーザが居たり、ゴーストデータにデビル化状態のフラグが立っていた場合、ユーザは、仮想コンピュータウィルスである「悪魔のギフト」に感染する。
仮想コンピュータウィルスに感染すると、ユーザはデビル化状態になる。そして、メインメニューに遷移すると、発症処理モードがアンロック(発動)されて、通常処理モードから発症処理モードに移行する。そして、端末装置(ゲーム装置)の表示部には、図7に示すように、「悪魔のギフト」が到着して感染したことを告知する画面が表示され、ユーザがデビル化したことや、デビル化状態の説明が行われる。そして、メインメニューが赤くなって「小悪魔化」し、図8のA1に示すようにデビル対決モード(DUELモード)を選択できるようになる。
デビル化状態になったユーザが、図9のレース選択画面でインターネットバトルを選択して通信対戦を行うと、同じ通信対戦ルームに居た他のユーザに「悪魔のギフト」が届き、仮想コンピュータウィルスが伝染する。同様にデビル化状態になったユーザが、図9のレース選択画面でフェイス・トゥ・フェースバトルを選択して通信対戦を行うと、フェイス・トゥ・フェースで対戦した相手ユーザに「悪魔のギフト」が届き、仮想コンピュータウィルスが伝染する。
またデビル化状態になったユーザがアップロードしたゴーストデータに、デビル化状態のフラグ(仮想コンピュータウィルスの発症フラグ)が立つようになる。そして図9のレース選択画面で、ゴーストバトルを選択し、デビル化状態になったユーザのゴーストデータによるゴーストカーと対戦すると、仮想コンピュータウィルスが伝染するようになる。
デビル対決モードでデビルカーとの対戦を行い、デビルカーを獲得すると、デビル化状態が治癒する。即ち、処理モードが発症モードから治癒処理モード(通常処理モード)に移行する。治癒と同時に、メインメニューが、元の通常状態のメニューに戻る。そして、あたかも免疫ができたかのように、その仮想コンピュータウィルスには二度と感染しなくなる。また図10のB1に示すように、オプション設定画面において、「デビル化」という項目が追加され、ユーザは好きなときにデビル化して、端末装置を発症処理モードに移行させることが可能になる。
次に本実施形態の手法のゲームへの適用例の詳細について説明する。
発動条件を設定する場合には、運営側で「悪魔のギフト」を開始したいタイミングで、サーバの所定記憶領域(条件記憶部)に「デビル化させたいユーザのオンラインIDリスト」を書き込む。
端末装置は、サーバとの間で定期的なやり取りを行う際に、所定記憶領域に記憶された「デビル化させたいユーザのオンラインIDリスト」をチェックする。そして、当該端末装置のユーザのオンラインIDと同じものが、オンラインIDリストに書き込まれていた場合には、仮想コンピュータウィルスの発症フラグを立てる。これにより、図7のようなデビル化の告知画面や図8のようなデビル化状態用のメニュー画面が、端末装置の表示部に表示されるようになる。
仮想コンピュータウィルスの伝染ルートは以下の通りであり、以下の条件を満たした場合に発症フラグ(デビル化フラグ)が立つ。
第1に、図9のインターネットバトルのリザルト表示の時点で、デビル化した他のユーザが存在した場合である。第2に、図9のフェイス・トゥ・フェイスバトルのリザルト表示の時点で、デビル化した他のユーザが存在した場合である。例えばインターネットバトルやフェイス・トゥ・フェイスバトルの開始時にはデビル化した他のユーザが存在したが、通信切断などによりリザルト表示の時点で存在しなかった場合には、仮想コンピュータウィルスは伝染しない。第3に、図9のゴーストバトルのリザルト表示の時点で、一緒に走ったゴースト(ゴーストデータ)に発症フラグが立っていた場合である。デビル化(発症)するタイミングについては、発症フラグが立った状態でメインメニューに遷移するとデビル化する。
デビル化すると、メインメニューでは以下のような変化がある。まずメインメニューの「小悪魔化」が行われる。例えば女性キャラクタのメイクや衣装が変わる。或いは色調が変わったり、サウンドが変化する。また、図8のA1に示すようにデビル対決モードがアンロックされて、消えていたデビル対決モードの選択肢が現れる。また「悪魔のギフト」のトロフィーが獲得され、トロフィー獲得によるニュース速報が表示される。デビル化によって、ユーザはデビル対決モードを遊べるようになる。また、デビル化すると、そのユーザは新たなデビル化の感染源になる。
デビル対決モードで、デビルカー(及びエンジェルカー)を獲得した状態でメインメニューに戻ると、デビル化が終了し、通常の状態に戻る。即ち、感染処理モードから治癒処理モードや通常処理モードに移行する。なお、デビルカーの獲得と同時にゲームを終了した場合には、次回の起動後のメインメニューで治癒する。
デビルカーの獲得によってデビル化状態が治癒すると、メインメニューでは以下のような変化がある。
まず、メインメニューが正常化する。例えば女性キャラクターや色調やサウンドが元に戻る。またデビル対決モードが消滅し、ユーザはデビル対決モードが選択できなくなる。また「悪魔のギフト」のトロフィーを獲得し、トロフィー獲得による、ニュース速報が表示される。また、図10のB1に示すように、オプション設定画面に、デビル化(悪魔を呼び出す)の選択肢があらわれ、ユーザは任意にデビル化状態に変化できるようになる。
以上のように本実施形態の手法をゲームに適用することで、ゲームソフトの発売後にユーザ間に様々な話題作りをすることができ、ネットワークに繋いで遊んで貰うための効果的な動機づけを創出できる。また仮想コンピュータウィルスの発動タイミングや内容については、運営者側で任意に制御できるため、例えばネットワークへのユーザ参加数の減少などの頃合いを見計らって、仮想コンピュータウィルスを発動させるなどの効果的なネットワーク運営を実現できるようになる。
2.3 発症条件、治癒条件、処理モードの切り替え
次に、発症条件、治癒条件、処理モードの切り替え処理の詳細について説明する。
本実施形態では図11(A)に示すように、仮想コンピュータウィルスの発症条件が満たされたか否かを判断する。図6(B)を例にとれば、サーバから送信されて来た発動情報に基づいて発症条件が満たされたか否かを判断する。具体的には、発動情報であるIDリストに、自身のIDが存在するか否かを判断し、存在した場合には仮想コンピュータウィルスの発症条件が満たされたと判断する。
そして、発症条件が満たされたと判断した場合には、処理モードを、通常処理モードから発症処理モードに切り替える。これにより、図7、図8に示すように、端末装置の表示部には発症処理モードにしたがった画像が表示されるようになり、ユーザは、図8のA1に示すような発症処理用のモードの選択等が可能になる。
更に本実施形態では、この発症処理モードにおいて、仮想コンピュータウィルスの治癒条件が満たされたか否かを判断する。そして治癒条件が満たされたと判断した場合には、図11(A)に示すように、処理モードを、発症処理モードから通常処理モードに切り替える。或いは図11(B)に示すように、処理モードを、発症処理モードから治癒処理モードに切り替える。
ここで、治癒処理モードでは、通常処理モードのように仮想コンピュータウィルスは治癒しているが、治癒処理用のモードの選択等が可能になる。具体的には、治癒処理モードに切り替わると、図10のB1に示すようなモードの選択が可能になり、図11(C)に示すように、通常処理モードと発症処理モードの間の切り替えが可能になる。例えばユーザからの入力情報等に基づいて、通常処理モードから発症処理モードに切り替えたり、発症処理モードから通常処理モードに切り替えることが可能になる。
また図12(A)に示すように、操作部160等を介して入力されたユーザからの入力情報は、入力受け付け部101により受け付けられる。条件判断部110は、入力受け付け部101により受け付けられたユーザからの入力情報に基づいて、治癒条件が満たされたか否かを判断する。そして処理モード設定部114は、治癒条件が満たされると、処理モードを、発症処理モードから通常処理モード又は治癒処理モードに切り替える。
具体的には、ゲームを例にとれば、入力受け付け部101により受け付けられた入力情報に基づいて、図12(B)に示すようにゲーム演算部102がゲーム演算処理を行う。図8を例にとれば、ユーザがA1に示すデビル対決モードを選択し、デビルカー等との対戦を行う。即ち、ユーザが操作部160を操作することで、その操作情報が入力情報として受け付けられ、ユーザが操作するユーザ操作カーとデビルカーとの対戦処理が、ゲーム演算処理として行われる。そして、条件判断部110は、このゲーム演算処理でのゲーム成績情報に基づいて、治癒条件が満たされたか否かを判断する。例えば、ユーザがデビルカーに勝利すると、治癒条件が満たされたと判断する。そして、処理モード設定部114が、処理モードを発症処理モードから通常処理モード又は治癒処理モードに切り替える。
なお、治癒条件が満たされたか否かの判断は、このようなゲーム成績情報に基づくものには限定されない。例えば、仮想コンピュータウィルスを治癒する治癒アイテムのダウンロードや購入等が行われたことが、入力情報に基づき判断された場合に、治癒条件が満たされたと判断して、処理モードを切り替えてもよい。或いは、ユーザからの入力情報に基づいて、ソーシャルネットワークのサービス提供のための処理を行い、その処理の結果に基づいて治癒条件が満たされたか否かを判断してもよい。
以上のように本実施形態では、通常処理モードや発症処理モードや治癒処理モードなどの処理モードの切り替えが可能なように、予めシステムとして用意しておく。そして発症条件が満たされた場合には、発症処理モードに切り替え、治癒条件が満たされた場合には、通常処理モードや治癒処理モードに切り替える。このようにすることで、仮想コンピュータウィルスの発症や治癒を表す種々のイベントを端末装置側に発生させることが可能になり、仮想コンピュータウィルスを用いた従来にない処理システムを実現することが可能になる。
即ち、いわゆるコンピュータウィルスでは、端末装置側のシステムには、発症処理モードや治癒処理モードなどの処理モードは用意されておらず、端末装置のファイルやシステムを破壊して、端末装置の動作に不具合をもたらす。
これに対して本実施形態の仮想コンピュータウィルスでは、発症処理モードや治癒処理モードなどの処理モードが予め用意され、発症条件や治癒条件の成立により、これらの処理モードが実行される。そして、コンピュータウィルスを模擬した仮想的な発症、伝染などにより、端末装置側に種々のイベントを発生させる。即ち、コンピュータウィルスのように、発症源から徐々に伝染してネットワーク上で広がって行き、ユーザ間の話題等を盛り上げて、ネットワーク接続への効果的な動機づけを創出する。
また、コンピュータウィルスでは、治癒により発症処理モードから通常処理モード等に戻るような仕組みはシステムとしては用意されておらず、コンピュータウィルスのプログラムを削除して隔離することでウィルスの治癒が実現される。
これに対して本実施形態の仮想コンピュータウィルスでは、発症処理モードから通常処理モードや治癒処理モードに戻る治癒の仕組みがシステムとして予め用意され、治癒条件が満たされると、この仕組みが動作して、仮想コンピュータウィルスの治癒が実現される。従って、ユーザは、仮想コンピュータウィルスに感染した後、システム側で予め用意された治癒条件を成立させる操作や作業を行うことで、仮想コンピュータウィルスを治癒させることができる。これによりネットワークゲームやソーシャルネットワーク・サービスにおいて、これまでには無い遊びの要素を創出することが可能になり、ネットワーク参加への効果的な動機づけを付与できるようになる。
2.4 伝染処理
次に、本実施形態の伝染処理の詳細について説明する。
本実施形態では、仮想コンピュータウィルスの伝染条件が満たされた場合に、発症条件が満たされたと判断し、処理モードを、通常処理モードから発症処理モードに切り替える。これにより、発症源から徐々に伝染して行くという通常のコンピュータウィルスと同様の振る舞いを、仮想的に模擬することが可能になる。
具体的には、本実施形態では、発症処理モードとなった他のユーザの端末装置との間でネットワークを介したデータ通信が行われた場合に、伝染条件が満たされたと判断し、発症条件の成立による処理モードの切り替えを行う。
例えば図13(A)では、端末装置TMi、TMj、TMkのユーザがネットワークを介した通信対戦を行っている。具体的には図9の選択画面でユーザがインターネットバトルを選択すると、このような通信対戦が実現される。この通信対戦では、端末装置TMi、TMj、TMkの間でネットワークを介して種々のデータ通信が行われる。
そして図13(A)では、端末装置TMiが発症中であり、その処理モードが発症処理モードになっている。このような状況で他の端末装置TMj、TMkのユーザが、発症中の端末装置TMiのユーザと通信対戦を行うと、伝染条件が満たされて、端末装置TMj、TMkに対して仮想コンピュータウィルスが伝染し、その処理モードが発症処理モードに切り替わる。これにより、端末装置TMiのみならず、端末装置TMj、TMkも仮想コンピュータウィルスの発症源になり、発症源から仮想コンピュータウィルスが徐々に広がって行く仕組みを実現できるようになる。
また本実施形態では、仮想コンピュータウィルスに感染したと判断されたコンテンツデータを受信した場合に、伝染条件が満たされたと判断して、発症条件の成立による処理モードの切り替えを行ってもよい。
例えば図13(B)では、発症フラグが「1」に設定され、仮想コンピュータウィルスに感染したと判断されたコンテンツデータが、サーバシステム500から端末装置TMにダウンロードされている。端末装置TMが、このようなコンテンツデータを受信すると、伝染条件が満たされて、発症条件の成立による処理モードの切り替えが行われるようになる。即ち、端末装置TMは、コンテンツデータに設定された発症フラグをチェックし、発症フラグが立っている場合には、伝染条件が満たされて、発症条件が成立したと判断する。
ここで、コンテンツデータとしては、例えばゲーム演算に使用されるゲームデータ、コンテンツ配信における映像(画像)データや音楽データ等を想定できる。或いはコンテンツデータはテキストデータなどであってもよい。
ゲームデータとしては、例えば図9の選択画面のゴーストバトルで使用されるゴーストデータなどがある。このゴーストデータは、ユーザの過去のプレイ履歴に基づき作成されコンピュータ制御移動体を制御するためのデータである。ユーザは、自身が操作する移動体と、ゴーストデータにより制御されるコンピュータ制御移動体であるゴーストカーとの間で対戦を行うことで、ゴーストバトルを楽しむ。そして、例えばユーザが選択してダウンロードしたゴーストデータに対して発症フラグが立っていると、そのゴーストカーとの対戦により仮想コンピュータウィルスが伝染するようになる。なお、ゲームデータは、ゴーストデータには限定されず、例えばゲームにより獲得するアイテムデータ等であってもよい。また映像や音楽のコンテンツ配信の場合には、配信された映像データや音楽データに対して発症フラグが立っていた場合に、そのコンテンツ配信により仮想コンピュータウィルスが伝染するようになる。
また、図9の選択画面においてフェイス・トゥ・フェイスバトルを選択した場合には、図14に示すように、無線アドホックネットワークにより端末装置TM1、TM2、TM3間での通信対戦が実現される。そして、図14では、端末装置TM1が発症中であり、発症中の端末装置TM1と、端末装置TM2、TM3との間で、無線アドホックネットワークによるデータ通信が行われている。従って、端末装置TM2、TM3に対して仮想コンピュータウィルスが伝染し、その処理モードが発症処理モードに切り替わるようになる。
この場合に、データ通信が行われたか否かの判断ではなく、位置情報に基づいて伝染条件を判断してもよい。即ち、仮想コンピュータウィルスに感染したと判断された他のユーザの位置情報に基づいて、伝染条件が満たされたか否かを判断して、発症条件の成立による処理モードの切り替えを行ってもよい。
例えば図14では、例えば端末装置TM1、TM2、TM3が内蔵するGPSセンサー等により、端末装置TM1、TM2、TM3のユーザの位置PT1、PT2、PT3を検出できる。そして、この場合に、位置PT1、PT2、PT3が近いと判断された場合(所定距離範囲内と判断された場合)に、伝染条件が満たされたと判断して、仮想コンピュータウィルスを伝染させてもよい。このようにすることで、現実世界のウィルスのように、近づいたら感染するというような仮想コンピュータウィルスの伝染を表現できるようになる。なお、この場合のユーザの位置情報は、例えば仮想空間におけるユーザのアバタの位置情報などであってもよい。
2.5 課金情報に基づく条件判断、条件の変更処理
本実施形態では、発症条件や治癒条件が満たされたか否かをユーザの課金情報に基づいて判断してもよい。
例えば図15(A)の課金情報(課金データベース)では、各ユーザUS1、US2、US3・・・に対してその課金データCH1、CH2、CH3・・・が関連づけられている。この課金情報は、例えば図3のユーザ情報記憶部674に記憶されて管理されている。なお端末装置側で課金情報を管理してもよい。
そして条件判断部110は、この課金情報に基づいて、発症条件や治癒条件が満たされたか否かを判断する。具体的には、例えばゲームやサービスにおけるユーザの課金金額が所定金額以上である場合に、発症条件や治癒条件が満たされたと判断して、そのユーザの端末装置において仮想コンピュータウィルスを発症させたり、発症を治癒させる。また、課金金額が多いユーザほど、発症条件や治癒条件が優先的に成立するような条件判断処理を行ってもよい。また図15(B)に示すように、端末装置TMのユーザが料金を支払い、その課金により治癒アイテムがサーバシステム500からダウンロードされた場合に、治癒条件が満たされたと判断して、端末装置TMの処理モードを切り替えるようにしてもよい。このようにすれば、ユーザによるアイテムやサービスの購入等を効果的に促すことが可能になる。
また本実施形態では、発症条件や治癒条件の変更処理を行うようにしてもよい。例えば図16では、条件変更部112は、仮想コンピュータウィルスの感染状況情報や、ネットワークへのユーザの参加状況情報や、コンテンツの配信状況情報などに基づいて、発症条件や治癒条件の変更処理を行っている。
ここで感染状況情報は、仮想コンピュータウィルスの感染状況に関する情報であり、例えば仮想コンピュータウィルスの感染者数や感染分布などである。参加状況情報は、ネットワークへのユーザの参加状況に関する情報であり、例えばネットワークへのユーザの参加者数、参加者プロファイル(年齢層、性別等)などである。配信状況情報は、コンテンツ配信サービスにおけるコンテンツの配信状況に関する情報であり、例えばコンテンツの配信数、配信人気度などである。
このようにすれば、例えば、仮想コンピュータウィルスの感染者数が多くなるにつれて、発症しにくくなるような発症条件や、治癒し易くなるような治癒条件の設定等が可能になる。また、感染分布により感染者数が少ないと判断される地域において、発症し易くなるような発症条件や、感染分布により感染者数が多いと判断される地域において、治癒し易くなるような治癒条件の設定等が可能になる。また、ネットワークへのユーザの参加者数が多くなるにつれて、発症し易くなるような発症条件や、治癒し易くなるような治癒条件の設定等も可能になる。また、コンテンツの配信数が多くなるほど、発症し易くなるような発症条件や、治癒し易くなるような治癒条件の設定等も可能になる。
2.6 発動条件、発動処理
次に、仮想コンピュータウィルスの発動条件や発動処理の詳細について説明する。
本実施形態では、例えば図17(A)に示すように、サーバの管理者(運営者)等が操作部660を介して入力した情報が、入力受け付け部602により受け付けられる。そして、この入力情報に基づいて、条件設定部604により発動条件が設定される。
このようにすれば、サーバの運営側が所望するタイミングや内容で、仮想コンピュータウィルスの発症処理を発動させることが可能になり、柔軟で効果的なサーバ運営を実現できる。例えば運営側は、ゲームソフト等のソフトウェアの発売後から所定期間経過したタイミングや、ソフトウェアの売上本数が所定本数に達したタイミングや、ソーシャルネットワークのアプリケーションサービスの参加人数が所定人数に達したタイミングや、ソフトウェアやアプリケーションサービスが各地域のユーザに普及したタイミングなどを見計らって、仮想コンピュータウィルスの発症処理を発動させることが可能になる。
そして、発動された仮想コンピュータウィルスは、ネットワーク上の端末装置に一斉に行き渡るのではなく、発症源となる端末装置から伝染処理により徐々に広がって行く。
即ち、いわゆる時限プログラムなどでは、所定年月日に達すると、その時限プログラムがインストールされた全ての端末装置においてその時限プログラムが起動してしまう。
これに対して本実施形態では、サーバの運営側において、発症源となる端末装置の数を限定できる。そして、この限定された所定数の端末装置から仮想コンピュータウィルスが徐々に広がって伝染して行く。これにより、例えば口コミやブログや掲示板などを介して、仮想コンピュータウィルスに関する話題が広がって盛り上がるようになる。
この場合に、サーバは、発動条件を設定して、IDリスト等の発動情報を送信する発動処理を行うだけで済み、その後は、端末装置間の伝染処理等により仮想コンピュータウィルスが広がって行く。従って、サーバの処理負荷を最小限に抑えながら、仮想コンピュータウィルスによる発症処理を実現できるようになる。
なお、発動条件の設定は、図17(A)のようにサーバの管理者の入力情報に基づくものには限定されない。例えば図17(B)に示すように端末装置からの情報に基づいて、発動条件を設定してもよい。図17(B)では、通信部696が端末装置TMからの情報を受信し、条件設定部604が、受信した情報に基づいて発動条件を設定している。これにより端末装置側の情報を反映させた発動条件を設定できるようになり、例えば仮想コンピュータウィルスの感染候補を選ぶ際に、端末装置側の情報を利用できるようになる。具体的には、当該ゲームソフトの過去のバージョンのゲームソフトの所持情報、ユーザからの感染候補ユーザの指示情報、或いはゲームソフトのクリアレベル等のゲーム成績情報などに基づいて、発動条件を設定できるようになる。従って、より柔軟で効果的な発動条件の設定処理が可能になる。
発動条件の条件内容については種々の実施形態を想定できる。例えば図18では、条件が満たされるか否かが、ユーザ情報、環境情報、或いはゲーム成績情報に基づき判断される条件を、発動条件として設定している。
ここで、ユーザ情報としては、ユーザについての識別情報、位置情報、又は課金情報等を想定できる。識別情報は、ユーザ自体の識別情報(ID番号、名前、誕生日、性別等)やユーザが所持する端末装置の識別情報(MACアドレス等)などである。位置情報は、ユーザが位置する場所の情報であり、GPSセンサや携帯端末の位置情報サービスなどにより取得できるものである。この位置情報は、仮想空間におけるユーザのアバタの位置情報などであってもよい。課金情報は、ユーザのサービス利用やアイテム購入に対する課金金額などについての情報である。環境情報としては、天候、気温等の情報を想定できる。環境情報は、ネットワーク環境(参加人数、混雑度等)に関する情報であってもよい。ゲーム成績情報としては、ユーザの勝敗、得点、クリアレベル等の情報を想定できる。
ユーザ情報を利用して発動条件を設定すれば、特定のID番号、名前、年齢層等により特定されたユーザを、仮想コンピュータウィルスの発症源となるユーザとして指定できるようになる。例えばゲームソフトの関係者のユーザや特定の年齢層のユーザを発症源として指定できるようになる。環境情報を利用して発動条件を設定すれば、例えば雪が降った日に仮想コンピュータウィルスを発動させるなどの制御が可能になる。課金情報を利用して発動条件を設定すれば、例えば課金金額が多いユーザほど、より発症候補となるような仮想コンピュータウィルスの発動制御が可能になる。ゲーム成績情報を利用して発動条件を設定すれば、例えばゲーム成績が良いユーザや所定のクリアレベルに達したユーザを、仮想コンピュータウィルスの発症源となるユーザとして指定できるようになる。
また本実施形態では、特定グループに属するユーザの端末装置を発症処理の対象とするような発動条件を設定してもよい。
例えば図19(A)では、各グループに対して複数のユーザが属するグループG1〜Gmが形成されている。例えばグループG1には、ユーザIDがID11、ID12、ID13・・・であるユーザが所属し、グループG2には、ユーザIDがID21、ID22、ID23・・・であるユーザが所属している。これらのグループの形成は、例えばユーザの意思により友達同士で形成してもよいし、運営者側で形成してもよい。
そして図19(A)では、グループG1に属するユーザが発症候補となるように、仮想コンピュータウィルスの発動条件が設定されている。従って、この場合には図6(B)において発症候補のIDリストを送信する際に、グループG1に属するユーザのID11、ID12、ID13・・・により構成されるIDリストが送信される。これにより、グループG1に属するユーザの端末装置において、仮想コンピュータウィルスの発症処理が発動されるようになる。
この場合に、例えばグループG1用の第1の仮想コンピュータウィルス、グループG2用の第2の仮想コンピュータウィルスというように、各グループ毎に別々に仮想コンピュータウィルスを発動させるようにしてもよい。
また、このような発症候補となる特定グループの設定を、特定グループに属するユーザの課金情報に基づいて行ってもよい。即ち、どのグループを発症候補とするかを、そのグループに属するユーザの課金情報に基づいて判断する。例えば図19(B)では、グループG1のID13のユーザの課金金額が多かったため、グループG1が発症候補のグループとして選択される。こうすることで、課金金額が多いユーザのグループが優先的に発症候補として選択されるようになり、選択されたグループのユーザは、仮想コンピュータウィルスによる種々のイベントを楽しめるようになる。従って、ユーザによるアイテムの購入やサービスへの参加等を効果的に促すことが可能になる。なお、発症処理モードを通常処理モード等に戻す治癒アイテム等の提供の可否も、各グループに属するユーザの課金情報に基づいて判断するようにしてもよい。例えば、課金金額が多いユーザのグループに対して、治癒アイテムを優先的に提供(ダウンロード)するようにする。これにより、ユーザによるアイテムの購入やサービスへの参加等を更に効果的に促すことが可能になる。
また、発動条件は、固定的な条件内容であるとは限らず、条件内容をリアルタイムに変化させてもよい。即ち図3の条件変更部606が、発動条件の変更処理を行って、条件内容を変化させる。具体的には、仮想コンピュータウィルスの感染状況情報、ネットワークへのユーザの参加状況情報、或いはコンテンツの配信状況情報などに基づいて、発動条件の変更処理を行う。
例えば、仮想コンピュータウィルスの発動を複数回に分けて実行する場合を想定する。具体的には、発症候補となるユーザのIDリストを複数回に分けて送信する。例えばゲームソフトの発売が10月である場合に、11月1日に第1回目のIDリストの送信を行い、11月10日に第2回目のIDリストの送信を行い、11月20日に第3回目のIDリストの送信を行うというように、送信を複数回に分ける。この場合に、感染状況情報に基づいて各回での発動条件を変更する。具体的には、例えば図20(A)に示すように、感染人数が増加するにつれて、各回において送信される発症候補のIDリストのユーザ人数を減少させる。このようにすれば、仮想コンピュータウィルスの感染の広がりの速度等を適応的に制御できるようになり、より適切な感染制御を実現できる。
また図20(B)では、ネットワークへのユーザの参加状況情報に基づいて、発動条件の変更処理を行っている。具体的には、ネットワークのユーザの参加人数が少ない場合には、IDリストのユーザ人数を少なくし、ネットワークのユーザの参加人数が多い場合には、IDリストのユーザ人数を多くする。このようにすれば、仮想コンピュータウィルスの発症源となる端末装置の数を、ネットワークのユーザの参加人数に応じて適切に制御できるようになる。或いは、コンテンツの配信状況情報に基づいて、発動条件の変更処理を行ってもよい。例えば、コンテンツ配信により仮想コンピュータウィルスの発症処理等を行う場合に、コンテンツの配信数や、コンテンツの配信を受けるユーザの人数などに基づいて、発動条件の変更処理を行う。例えばコンテンツの配信数や配信を受けるユーザの人数が多いほど、仮想コンピュータウィルスの感染の広がりの速度がより速くなるように、発動条件の設定処理を行う。このようにすれば、コンテンツ配信における仮想コンピュータウィルスの発症処理を適応的に制御できるようになる。
なお、発動条件の変更処理に使用する情報は、これらの感染状況情報、参加状況情報、配信状況情報には限定されず、ネットワークゲームやソーシャルネットワーク・サービスやコンテンツ配信サービス等における種々の情報を用いることができる。
3.詳細な処理
次に本実施形態の詳細な処理例について図21、図22のフローチャートを用いて説明する。
図21は、処理モードの切り替え処理や治癒処理に関するフローチャートである。まず、図16で説明したような発症条件の変更処理を行う(ステップS11)。そして、発症条件が満たされたか否かの判断処理を行い、発症条件が満たされたと判断した場合には、図11(A)、図11(B)で説明したように、処理モードを、通常処理モードから発症処理モードに切り替える(ステップS12、S13、S14)。
次に、図16で説明したような治癒条件の変更処理を行う(ステップS15)。そして、治癒条件が満たされたか否かの判断処理を行い、治癒条件が満たされたと判断した場合には、図11(A)、図11(B)で説明したように、処理モードを、発症処理モードから通常処理モード又は治癒処理モードに切り替える(ステップS16、S17、S18)。
図22は発動処理に関するフローチャートである。まず、発動条件の設定処理を行い、設定された発動条件を記憶する(ステップS1、S2)。例えばサーバの管理者の入力情報等に基づいて発動条件を設定して、所定記憶領域に記憶する。
次に、図20(A)、図20(B)で説明したように、感染状況、参加状況、配信状況等に基づいて発動条件を変更するか否かを判断し、変更すると判断された場合には、発動条件の変更処理を行う(ステップS3、S4)。
次に、発動条件が満たされたか否かを判断し、発動条件が満たされたと判断された場合には、端末装置への発動情報の送信処理を行う(ステップS5、S6)。例えば「X年Y月Z日にユーザUSi〜USjの端末装置において仮想コンピュータウィルスを発症させる」という発動条件である場合には、X年Y月Z日に、ユーザUSi〜USjのIDが設定されたIDリストを端末装置に対して送信する。
なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また、発症処理や治癒条件の判断処理、発症処理、治癒処理、発動条件の設定・判断処理、発動処理等も本実施形態で説明したものに限定されず、これらと均等な手法も本発明の範囲に含まれる。