(57)【特許請求の範囲】
【請求項１】
通信手段を介して接続された複数の利用者端末に対戦ゲームを行わせるゲームシステムに用いられるゲームサーバ装置であって、
前記利用者端末から取得した対戦ゲームを進行させるための情報に従って対戦ゲームを進行させる通常モード処理手段と、
予め編集構成された対戦ゲームを進行させるための情報が順に登録された第１格納手段と、
前記利用者端末から取得した対戦ゲームを進行させるための情報が前記第１格納手段に登録された情報の順に従う場合に、前記第１格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第１情報生成手段と、
前記第1情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、
前記利用者端末からの設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段とを具備したことを特徴とするゲームサーバ装置。
【請求項２】
通信手段を介して接続された複数の利用者端末に対戦ゲームを行わせるゲームシステムに用いられるゲームサーバ装置であって、
前記利用者端末から取得した対戦ゲームを進行させるための情報に従って対戦ゲームを進行させる通常モード処理手段と、
過去に行われた対戦ゲームにおける各利用者端末から取得した情報が順に登録された第２格納手段と、
前記利用者端末から取得した対戦ゲームを進行させるための情報が前記第２格納手段に登録された情報の順に従う場合に、前記第２格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第２情報生成手段と、
前記第２情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、
前記利用者端末からの設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段とを具備したことを特徴とするゲームサーバ装置。
【請求項３】
利用者のゲーム進行に要する時間を計時する計時手段と、
前記計時手段によって計時された時間をもとに、対戦ゲームを進行させるために利用者が要する消費時間傾向を登録する時間登録手段を具備し、
前記エージェントモード処理手段は、対戦ゲームを進行させるための情報の生成に際して、前記時間登録手段によって登録された消費時間時間傾向に応じた時間を消費することを特徴とする請求項１又２に記載のゲームサーバ装置。
【請求項４】
通信手段を介して接続された他のゲーム端末装置との間で対戦ゲームを行うゲーム端末装置であって、
ユーザからの情報入力に基づき対戦ゲームを進行させる通常モード処理手段と、
予め編集構成された対戦ゲームを進行させるための情報が順に登録された第１格納手段と、
前記他のゲーム端末装置から取得した対戦ゲームを進行させるための情報が前記第１格納手段に登録された情報の順に従う場合に、前記第１格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第１情報生成手段と、
前記第1情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、
前記ゲーム端末装置における設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段と、
前記振り分け手段によって選択されたゲームを進行させるための情報を前記通信手段により送信する送信手段とを具備したことを特徴とするゲーム端末装置。
【請求項５】
通信手段を介して接続された他のゲーム端末装置との間で対戦ゲームを行うゲーム端末装置であって、
ユーザからの情報入力に基づき対戦ゲームを進行させる通常モード処理手段と、
過去に行われた対戦ゲームにおけるゲームを進行させる情報が順に登録された第２格納手段と、
前記他のゲーム端末装置から取得した対戦ゲームを進行させるための情報が前記第２格納手段に登録された情報の順に従う場合に、前記第２格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第２情報生成手段と、
前記第２情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、
前記ゲーム端末装置における設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段と、
前記振り分け手段によって選択されたゲームを進行させるための情報を前記通信手段により送信する送信手段とを具備したことを特徴とするゲーム端末装置。
【請求項６】
利用者のゲーム進行に要する時間を計時する計時手段と、
前記計時手段によって計時された時間をもとに、対戦ゲームを進行させるために利用者が要する消費時間傾向を登録する時間登録手段を具備し、
前記エージェントモード処理手段は、対戦ゲームを進行させるための情報の生成に際して、前記時間登録手段によって登録された消費時間時間傾向に応じた時間を消費することを特徴とする請求項４又５に記載のゲーム端末装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して将棋、囲碁、チェス等の対戦ゲームを行うサービスを提供するためのゲームサーバ装置及びゲーム端末装置に関する。
【０００２】
【従来の技術】
近年では、離れた場所にいる人間同士で将棋、囲碁、チェス等のゲームを、電話回線、インターネットなどの通信手段を介して遠隔対戦（対局）するシステムとして、対戦者が使用する端末がそれぞれネットワークサーバに接続し、このサーバを仲介して対戦を行う形態、または対戦者が利用する端末同士で直接接続して対戦を行うピア・ツー・ピアの形態でのネットワーク対戦システムがあり、商用・非商用で様々なサービスが実用段階にある。
【０００３】
また、人間とコンピュータとの間で対戦を行うため対戦プログラムも実用段階にあり、ゲームの種類によっては人間以上にうまく対戦するプログラムが数多く存在する。対戦プログラムの構成要素として、Ｍｉｎ−Ｍａｘ法、枝刈り、評価関数などの技術が用いられている。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来のネットワーク対戦システムは、対戦者が対戦の最初から最後まで互いに対戦相手につきあうことが対戦を成立させる前提であり、対戦者にとっての利便性、使用感の上で以下に述べる問題点があった。
【０００５】
第１の問題点は、対戦中に急用ができたとしても、端末の前を離れると時間切れで負けになったり、相手に不満を持たれたりすることがある。
第２の問題点は、対戦の経過により勝敗が決しているのにもかかわらず、敗者となる対戦相手が投了せずに着手を続ける場合には、その着手に対応し続けなければならず、時間の無駄になることである。
【０００６】
第３の問題点（第２の問題点の特殊な場合とも捉えられる）は、ゲームの実質上の終了局面が、ルール上必ずしも次以下の着手が不可能ではない局面である時、持ち時間の残りの多い側が、相手の持ち時間切れを期待して着手を続け、盤面状態で負けている側が勝ってしまうことが可能であることである。具体例としては、将棋において必死をかけられた後の無意味な王手連続、チェスにおいて勝つための最低駒数に不足していても指し続ける、囲碁において相手の確定地の中に自殺手を打つなどの行為が相当する。端末を操作するために一定の時間を必要とする対戦ゲームでは生じやすい問題であるが、潔さを尊ぶモラルの問題も関係して利用者間のトラブルになりやすい。
【０００７】
また、第４の点として（問題点とはいえないまでも）、ネットワーク対戦システムで、特定の決まりきった戦形に進行する場合、一手一手決まりきった序盤手順を入力する必要があり、手順入力の自動化は考慮されておらず、計算機システムの特性を最大限には利用していなかった。
【０００８】
このように従来のシステムでは、対戦を開始してから対戦の最後まで対戦相手に対応しなければならず、前述した第１〜第４の問題点にあるように、対戦の本質的な部分以外での負担が非常に大きく、ネットワーク対戦の利用の障害となるおそれがあった。
【０００９】
本発明は、前記のような問題に鑑みてなされたもので、通信手段を介した相手と対戦ゲームをする利用者による操作を代行する機能を設けて利用者の負担を軽減することが可能なゲームサーバ装置及びゲーム端末装置を提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明は、通信手段を介して接続された複数の利用者端末に対戦ゲームを行わせるゲームシステムに用いられるゲームサーバ装置であって、前記利用者端末から取得した対戦ゲームを進行させるための情報に従って対戦ゲームを進行させる通常モード処理手段と、予め編集構成された対戦ゲームを進行させるための情報が順に登録された第１格納手段と、前記利用者端末から取得した対戦ゲームを進行させるための情報が前記第１格納手段に登録された情報の順に従う場合に、前記第１格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第１情報生成手段と、前記第1情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、前記利用者端末からの設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段とを具備したことを特徴とする。
また本発明は、通信手段を介して接続された複数の利用者端末に対戦ゲームを行わせるゲームシステムに用いられるゲームサーバ装置であって、前記利用者端末から取得した対戦ゲームを進行させるための情報に従って対戦ゲームを進行させる通常モード処理手段と、過去に行われた対戦ゲームにおける各利用者端末から取得した情報が順に登録された第２格納手段と、前記利用者端末から取得した対戦ゲームを進行させるための情報が前記第２格納手段に登録された情報の順に従う場合に、前記第２格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第２情報生成手段と、前記第２情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、前記利用者端末からの設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段とを具備したことを特徴とする。
また本発明は、通信手段を介して接続された他のゲーム端末装置との間で対戦ゲームを行うゲーム端末装置であって、ユーザからの情報入力に基づき対戦ゲームを進行させる通常モード処理手段と、予め編集構成された対戦ゲームを進行させるための情報が順に登録された第１格納手段と、前記他のゲーム端末装置から取得した対戦ゲームを進行させるための情報が前記第１格納手段に登録された情報の順に従う場合に、前記第１格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第１情報生成手段と、前記第1情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、前記ゲーム端末装置における設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段と、前記振り分け手段によって選択されたゲームを進行させるための情報を前記通信手段により送信する送信手段とを具備したことを特徴とする。
また本発明は、通信手段を介して接続された他のゲーム端末装置との間で対戦ゲームを行うゲーム端末装置であって、ユーザからの情報入力に基づき対戦ゲームを進行させる通常モード処理手段と、過去に行われた対戦ゲームにおけるゲームを進行させる情報が順に登録された第２格納手段と、前記他のゲーム端末装置から取得した対戦ゲームを進行させるための情報が前記第２格納手段に登録された情報の順に従う場合に、前記第２格納手段に登録された情報から次の対戦ゲームを進行させるための情報を生成する第２情報生成手段と、前記第２情報生成手段によって生成されたゲームを進行させるための情報に従って対戦ゲームを進行させるエージェントモード処理手段と、前記ゲーム端末装置における設定に応じて前記通常モード処理手段と前記エージェントモード処理手段の何れによって対戦ゲームを進行させるかを振り分ける振り分け手段と、前記振り分け手段によって選択されたゲームを進行させるための情報を前記通信手段により送信する送信手段とを具備したことを特徴とする。
【００１１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。
図１は本発明の実施の形態に係わるネットワーク対戦システムの構成を示すブロック図である。図１に示すように、利用者端末１０（利用者端末１０−１，１０−２）は、公衆網１４を介してホスト装置１６と接続され、ホスト装置１６が提供する将棋、囲碁、チェスなどの対戦（対局）を通信回線を介した相手と行うことができる対戦サービスの他、各種サービスの提供を受けることができる。利用者端末１０は、例えば通信回線を介した相手と将棋ゲームの対局を行うための専用端末（対戦ゲーム装置）として構成され、ホスト装置１６を介して将棋ゲームなどの対局を行うことができる。なお、パーソナルコンピュータやＰＤＡ（personal digital assistant）などによって対局プログラム（対戦プログラム）を実行することで、ゲーム専用端末の利用者端末１０と同様の機能を実現することも勿論可能である。以下、将棋ゲームを行う場合を例にして説明する。また、公衆網１４は、パケット交換網であり、例えばＩＳＤＮ（Integrated Services Digital Network）が使用されるものとする。
【００１２】
図１に示すように、利用者端末１０は、メモリ２０、ＣＰＵ２１、ＬＣＤ（Liquid Crystal Display）２２、タッチパネル２３、モデム２４が、それぞれＩ／Ｆ回路を介して相互にバスに接続される。
【００１３】
メモリ２０は、ＣＰＵ２１によって実行される各種制御プログラムやデータ等が格納されるものであり、将棋ゲームを実現するための対局プログラムや通信制御用プログラムの他、各種データなどを含んでいる。なお、利用者端末１０は、メモリ２０以外にもプログラム、データ等が記録される磁気的、光学的記録媒体、もしくは半導体メモリで構成される記録媒体を設けることもできる。記録媒体は、記録装置に固定的に設けたもの、もしくは着脱自在に装着するものである。また、記録媒体に記録されるプログラム、データ等は、通信回線等を介して接続された他の機器から受信して記録する構成にしても良く、さらに、通信回線等を介して接続された他の機器側に記録媒体を備えた記録装置を設け、この記録媒体に記録されているプログラム、データを通信回線を介して使用する構成にしても良い。
【００１４】
ＣＰＵ２１は、メモリ２０に格納された各種制御プログラムやデータに従って各種機能を実現するもので、将棋ゲームなど対局ゲームや通信を実行するための機能などを実現する。本実施形態における利用者端末１０では、対局を行う場合に利用者からの情報入力によって対局ゲームを進行する通常モードの他に、利用者からの要求あるいは対局が特定の状態となった場合に実行される、予め用意された着手選択アルゴリズムによって利用者からの情報入力なしに対局を進行させるエージェントモード（思考エージェントモード、定跡エージェントモード、トレースエージェントモード）が用意されている。
【００１５】
ＬＣＤ２２は、将棋ゲームを行う上で必要な各種の情報を表示するもので、将棋盤面と接続ボタン、対局要求ボタン、終了ボタンなどの基本的な機能ボタンと対局ゲームの動作モード（通常モード、エージェントモード）を切り替えるための切り替えボタン、手番・時間経過などの情報を表示する。
【００１６】
タッチパネル２３は、端末に対する動作を規定するためのボタンや将棋ゲーム実行中の駒を置くべき位置を指定するために使用される。
タッチパネル２３とＬＣＤ２２とは、積層一体型に構成されて表示入力部を構成しており、ＬＣＤ２２によって表示された対象物をペンなどによって直接的に指示することで、該当する座標データを入力することができる。
モデム２４は、公衆網１４を介して通信を行うためのもので、対戦を行うために接続要求があった場合に、ホスト装置１６に対してダイアルアップする。
利用者端末１０のメモリ２０に格納される対局プログラムは、タッチパネル２３に対する操作及びモデム２４からの対局相手の着手情報コマンド受信によりイベント駆動する。接続ボタンがタッチされたというイベントを検知すると、モデム２４からホスト装置１６にダイアルアップし、データリンクを確立する。将棋盤面の領域内がタッチされたというイベントを検知すると、そのタッチされたポイントから着手座標を算出し、その座標データをもとに自分の着手をＬＣＤ２２の該当ポイントに表示すると共にに、着手座標データを着手情報コマンドとしてモデム２４に送出し、モデム２４を通じてホスト装置１６に送信する。また、モデム２４が対局相手の利用者端末１０からの着手情報コマンドを受信したイベントが発生すると、着手情報から着手座標データ（駒コード）を取得し、相手の着手をＬＣＤ２２の該当ポイントに表示する。その他の機能ボタンがタッチされると、該当するコマンド文字列をホスト装置１６に対して送出する。
【００１７】
また、図１に示すように、ホスト装置１６は、サーバ装置３０（通信ゲーム装置）、アクセスルータ３４を有して構成されている。サーバ装置３０は、公衆網１４を介して接続された利用者端末１０に対して各種のサービスを提供するもので、例えば端末間での将棋ゲームの対局の制御や対局に関する各種情報（勝敗記録、段級、棋譜）の提供などを行う。アクセスルータ３４は、サーバ装置３０と公衆網１４を介した利用者端末１０とを接続するためのもので、ＴＣＰ（transmission control protocol）／ＩＰ（internet protocol）及びイーサネット（登録商標）によって接続する。
【００１８】
サーバ装置３０は、各種の記録媒体に記録されたプログラムを読み込み、この読み込んだプログラムによって動作が制御されるコンピュータによって構成されるもので、ＣＰＵ４０、メモリ４１、記録装置４２、イーサネット（登録商標）インタフェース（Ｉ／Ｆ）４３がバスを介して相互に接続されている。
【００１９】
ＣＰＵ４０は、メモリ４１に格納された各種制御プログラムやデータに従って各種機能を実現するもので、対局プログラム（対戦プログラム）を実行することで将棋ゲームなどの対戦サービスを実現する。本実施形態では、利用者端末１０から受信した利用者からの要求に応じた動作モード、すなわち利用者からの情報入力によって対局ゲームを進行する通常モードと、着手自動選択アルゴリズムを利用して着手情報を演算によって生成して対局ゲームを進行させるエージェントモード（思考エージェントモード、定跡エージェントモード、トレースエージェントモードを含む）による処理を実行する。思考エージェントモードは、事実上終局と判定した時、それ以降、勝者側の持ち時間（制限までの残り時間）が所定値以下（対局相手による持ち時間切れを期待した無意味な着手が続けられた場合に待ち時間切れとなる可能性のある僅かな時間）になった場合に、対局を代行し着手自動選択モジュールにより瞬時に着手を決定して持ち時間を消費しないで進行し、持ち時間切れとならないように正常な終局ができるようにするためのモードである。定跡エージェントモードは、予め定跡手順を編集して用意しておけば、対局相手がその定跡手順に従う着手をする間は自動的に定跡手順に従って対局を進行させ、指定の定跡手順が完了するか、相手が定跡手順外の着手を選択した時に通常モードに復帰するモードである。トレースエージェントモードは、初手ないし指定時点から有効となり、以前の記録手順と同じ手順で進行している間（特に同一の相手と連続して対局する時）、前回の勝者側（先手後手は入れ替わっていても良く形が同じ側）を前回と同じ着手により自動的に対局を進行させ、敗者側が前回と異なる着手を選択した時に通常モードに復帰するモードである。
【００２０】
イーサネット（登録商標）Ｉ／Ｆ４３は、アクセスルータ３４と接続するためのインタフェースである。
【００２１】
メモリ４１は、ＣＰＵ４０によって実行される各種制御プログラムやデータ等が格納されるものであり、対戦サービスを提供するための対局プログラム（通常モード、エージェントモードのそれぞれに対応する）や通信制御プログラムの他、対局を行う利用者端末１０間で送受信される着手情報コマンド（ゲーム情報）や対局状況を表す局面状態データなど各種データなどが格納される。着手情報コマンドと局面状態データの詳細については後述する（図２、図３）。
【００２２】
記録装置４２は、ＣＰＵ４０により実行される各種プログラム４２ａの他、対戦サービスのために利用される利用者データベース４２ｂ、定跡データベース４２ｃが格納される。利用者データベース４２ｂと定跡データベース４２ｃの詳細については後述する（図４、図５）。なお、記録装置４２は、磁気的、光学的記録媒体、もしくは半導体メモリなどで構成される記録媒体が設けられている。記録媒体は、記録装置に固定的に設けたもの、もしくは着脱自在に装着するものである。また、記録媒体に記録されるプログラム、データ等は、通信回線等を介して接続された他の機器から受信して記録する構成にしても良く、さらに、通信回線等を介して接続された他の機器側に記録媒体を備えた記録装置を設け、この記録媒体に記録されているプログラム、データを通信回線を介して使用する構成にしても良い。
【００２３】
図２には、対局をする利用者端末１０間で送受信される着手情報コマンドの構造体の一例を示している。図２に示すように、着手情報コマンドには、盤面上の着手位置を示す水平座標、垂直座標の各データ、何れの駒についての着手であるかを示す駒コード、その他の付加情報が含まれている。
【００２４】
例えば、将棋ゲームで「７六歩」（歩の駒コード＝１とする）は（７，６，１，０）によって表される。付加情報には、着手座標と駒コードだけでは表せない情報がある時に、それらをビットフィールドに書くものとする。例えば、最上位ビット＝１の時は「投了」を示したり（この時、座標データと駒コードは無意味であるのでなんでも良い）、それ以外のビットを用いて将棋で複数の同一コードの駒が同一座標に動ける場合に区別するために右・左など表したりするものとする。
【００２５】
図３には、サーバ装置３０において対局状況を管理するための局面（盤面）状態データの構造体の一例を示している。図３に示すように、局面状態データには、現在の手番が何れの利用者端末１０側であるかを示す手番（先手番／後手番）、盤面（９×９）の格子による各枠に着手された駒についての格子情報（駒の種類を示す駒コード、駒が先手と後手の何れ側に所属しているかを示す所属コード）（［０］［０］〜［８］［８］）、持ち駒についての持ち駒情報（持駒の種類を示す駒コード、持駒が先手と後手の何れ側に所属しているかを示す所属コード）（［０］〜［３８］）が含まれている。
【００２６】
例えば、格子情報［７］［７］の値が（１，０）である場合、盤面７七の地点に駒コード１（「歩」）、所属０（先手番の駒）の駒があることを表す。ここで、先手番として「７六歩」、（７，６，１，０）の着手があった場合、７七から７六に「歩」が動いたことになるので、格子情報［７］［７］の値を（０，０）、格子情報［７］［６］の値を（１，０）に更新する（駒コード０は空を表す）。
【００２７】
図４は、記録装置４２に格納される利用者データベース４２ｂ（ＤＢ）のレコード構造の一例を示している。利用者データベース４２ｂは、対戦サービスを利用する利用者に関する情報を利用者ごとに登録するためのもので、利用者を識別するための利用者ＩＤ（整数）、利用者（利用者端末）のゲームに対する強さを表すレーティング値（整数）（第３格納手段）、定跡エージェントモードを有効とするか否かを示す定跡データベース使用フラグ（真偽２値）、トレースエージェントモードを有効とするか否かを示す前回対局トレースフラグ（真偽２値）、前回勝敗（先手勝ち、後手勝ち、引き分けの３値）、前回行われた対局（ここでは３０手まで）の着手情報からなる前回対局棋譜（［０］〜［２９］）（第２格納手段）、平均着手所要時間（着手時間総和、サンプル総数）（［０］〜［３］）の各フィールドからなる。利用者データベース４２ｂのフィールドのうち前回対局棋譜の構造は、初手から順に着手情報を連結したものである。また、平均着手所要時間（配列［０］〜［３］）は、対戦ゲームを進行するために利用者（利用者端末１０）が要する消費時間傾向を表すための情報であり、残り時間が１０分以上ある場合、残り時間が５〜１０分の場合、残り時間が３〜５分の場合、残り時間が３分未満の場合の４段階にわけて、利用者の過去に対局した際の、残り時間と一手ごとの平均消費時間の関係をテーブル化したものである。平均着手所要時間は、着手時間総和／サンプル総数で算出できる。前回対局棋譜［０］〜［２９］は、０，２，４…番目が先手番の着手、１，３，５…が後手番の着手を示している。初手から３０手のみ記録するようになっている。
【００２８】
図５は、記録装置４２に格納される定跡データベース４２ｃ（ＤＢ）のレコード構造の一例を示している。定跡データベース４２ｃ（第１格納手段）は、予め編集して構成された対戦ゲームを進行させる情報が順に登録されたもの、すなわち定跡の着手が順に登録されたものであって、各レコードには、図５に示すように、通し番号（整数）、自着手情報（着手座標データや駒コードから成る構造体）、相手着手情報ａ〜ｃ（各々着手情報の構造体）、後続通し番号フィールドａ〜ｃ（各々整数）が含まれている。定跡データベース４２ｃは、自着手と同じ自着手情報が登録されたレコードが選択され、対局相手からの着手情報が相手着手情報ａ〜ｃにある三種類の中の何れかであれば、その相手着手に対応する後続通し番号フィールドが示す通し番号のレコードを検索していくことにより、自着手が自動的に選択できるように構成されている。例えば、定跡データベース４２ｃに登録される定跡を表す情報は、利用者の操作によって編集された情報、または典型的な既存の情報であるものとする。後続通し番号が０に到達した場合は、以後の手順が定跡データベース４２ｃには収録されていない、すなわち定跡終了を示す。
【００２９】
定跡データベース４２ｃに格納される各レコードには通し番号（Ｊ）を設定し、先手番初手の通し番号を１、後手番初手（２手目）を２、終了を０、その他を３以上の数から重複しないように適当に設定する。なお、後手番初手のレコードの自着手情報は参照しない（参照しても無意味である）。また、後続通し番号０に対応する相手着手情報への設定もしなくても良い（相手着手ａ〜ｃにない手の時も定跡終了とするため）。
【００３０】
例えば、先手番初手「７六歩」に対して定跡「３四歩」「８四歩」がある場合、対応するレコード値は（１，（７，６，１，０），（３，４，１，０），１０，（８，４，１，０，），２０，（０，０，０，０），０，）となる。通し番号１０のレコードには「３四歩」に対する自着手などが、通し番号２０のレコードには「８四歩」に対する自着手などが同様に登録されている。
【００３１】
次に、本実施形態におけるネットワーク対戦システムの動作について説明する。
はじめに、利用者端末１０（利用者端末１０−１，１０−２）における動作の概略について、図６（ａ）に示すフローチャートを参照しながら説明する。
利用者は、タッチパネル２３をタッチすることにより利用者端末１０を操作する。利用者端末１０のＣＰＵ２１は、タッチパネル２３に対する操作、及びモデム２４からの対局相手の着手情報コマンドの受信に応じて、メモリ２０に記録されたプログラムに従ってイベント駆動する。
【００３２】
接続ボタンがタッチされたというイベントを検知すると、モデム２４からホスト装置１６にダイアルアップし、公衆網１４を介したホスト装置１６とのデータリンクを確立する（ステップＡ２）。さらに、対局要求ボタンがタッチされたことを検出すると、ホスト装置１６により対局相手がアサインされて対局が始まる（ステップＡ３）。ＣＰＵ２１は、ＬＣＤ２２においてゲームの盤面を表示させる。先手後手が決まり、先手番となった方から、端末の盤面をタッチして着手を送信する。
【００３３】
将棋盤面の領域内がタッチされたというイベントを検知すると、ＣＰＵ２１は、そのタッチされたポイントから着手座標を算出し、自分の着手（駒）をＬＣＤ２２の該当ポイントに表示するとともに、着手座標を着手情報コマンドによりモデム２４を通じてホスト装置１６に送信する。また、その他のボタンがタッチされると、ＣＰＵ２１は、該当するコマンドをホスト装置１６に対して送信する。一方、モデム２４により着手情報コマンドを受信するイベントが発生すると、ＣＰＵ２１は、着手情報コマンドから相手の着手座標と駒コードを取得し、これをもとに相手の着手（駒）をＬＣＤ２２の該当ポイントに表示する。
【００３４】
本実施形態における利用者端末１０では、ホスト装置１６を通じて対局を行う場合に、利用者からのモード設定ボタンに対する操作により定跡エージェントモードあるいはトレースエージェントモードを設定することができる（ステップＡ１）。この場合、利用者端末１０は、ホスト装置１６との接続時に設定モードの登録を実行し、この設定モードによって利用者による着手を必要とせずに対戦が進められるようにする。また、利用者は、対戦の内容が実質的に勝ちが決まっているような場合（終局状態）に、思考エージェントモード切替ボタンへの操作によって思考エージェントモードを設定することにより（ステップＡ４）、残り持ち時間を消費することなく対局を進行させることができる。利用者端末１０は、思考エージェントモードが設定されたことをホスト装置１６に通知し（ステップＡ５）、この設定モードによって対戦が進められるようにする。なお、思考エージェントモードは、再び思考エージェントモード切替ボタンが操作されることにより、利用者が希望する任意のタイミングで解除することもできる。また、思考エージェントモードは、終局状態で残り持ち時間が予め決められた所定値以下、例えば持ち時間の残りが１０秒を切った場合には自動的に設定されるものとする。
【００３５】
次に、サーバ装置３０における動作の概略について、図６（ｂ）に示すフローチャートを参照しながら説明する。ここでは、利用者端末１０−１と利用者端末１０−２との間で行われる対局をサーバ装置３０が仲介するものとして説明する。
【００３６】
サーバ装置３０は、ＴＣＰ／ＩＰの特定のＴＣＰポート番号の接続要求パケットの受信を待ち、接続要求がある毎にサーバメイン処理を子プロセスとして起動してそのコネクションを処理する（ステップＢ１，Ｂ２）。従って、サーバ装置３０は、複数のコネクションを並行して処理することができる。コネクションは利用者端末１０が切断するまで維持され、各子プロセスもその間存続する。以下の説明では、利用者端末１０−１に対する処理を主にして説明する。
【００３７】
コネクションを処理する子プロセスの処理内容は、以下のように構成することができる。
子プロセスは、繰り返し、コネクションが確立された利用者端末１０−１についてＴＣＰ／ＩＰソケットから受信したコマンドを読み出して解釈し、またプロセス間通信チャネルから受信した対局相手（利用者端末１０−２）側からのコマンドを読み出して解釈する。また、子プロセスは、共有メモリ空間によって実現した、１対１で双方向のストリームとして入出力できるプロセス間通信チャネルを、プロセス間通信チャネルＩＤ番号で指定して使用することができる。
【００３８】
ＴＣＰ／ＩＰソケットから受信した対局要求コマンドには利用者ＩＤが含まれる。対局要求コマンドを受け取ると、利用者ＩＤをキーとして利用者データベース４２ｂを検索し、該当する利用者のレコード（以下、利用者レコードＵＲ）の対局ステータスフィールドを１（対局参加問い合わせ中）に更新する。続いて、対局ステータスが２（対局相手待ち）の利用者レコードＵＲを検索し、最初に見つかった利用者レコードＵＲに該当する利用者を対局相手として選び、空きのプロセス間通信チャネルＩＤを取得し、前記の利用者レコードＵＲと対局相手の利用者レコードＵＲをともに対局ステータスフィールドを３（対局中）、プロセス間通信チャネルＩＤを取得したプロセス間通信チャネルＩＤに更新する。この際、乱数によって先手・後手番を決定する。対局相手のレコードが見つからなかった場合は、前記の利用者レコードＵＲの対局ステータスフィールドを２（対局相手待ち）に更新する。なお、前述した何れの状態にもない場合（対局終了後など）には、対局ステータスが４に設定されているものとする。
【００３９】
利用者データベース４２ｂから得た利用者レコードＵＲの内容は、ローカル作業メモリ中にコピーしておき、以下に説明する各処理の参照に用いる。また、対局を開始する前に実行される対局前処理によって設定モードの登録を行う（ステップＢ３）。すなわち、利用者端末１０−１におけるエージェントモードの設定に応じて、定跡エージェントモードあるいはトレースエージェントモードを有効化する。なお、トレースエージェントモードについては、利用者データベース４２ｂから得られる利用者レコードＵＲの前回対局トレースフラグ（エージェントモードの設定）が真であり、かつ、自分が先手番であり前回勝者が先手番であったか、または自分が後手番であり前回勝者が後手番であった場合にトレースエージェントモードを有効化するもまとする。また、思考エージェントモードは初期段階では無効化されている。各モードについては子プロセス毎にローカル作業メモリ中にフラグが設けられて管理される。
【００４０】
以下、利用者端末１０−１から受信したコマンドを識別し、その識別結果に応じたイベントを実行する。自着手ではない（利用者端末１０−２側における着手）場合に実行する相手着手受信処理（ステップＢ４，Ｂ５）では、相手着手確定処理（図８）、自着手処理振り分け処理（図９）、定跡エージェント処理（図１０）、トレースエージェント処理（図１１）、思考エージェント処理（図１２）、終局後処理（図１４）などの各種処理が実行される。また、自着手の場合に実行する自着手受信処理（ステップＢ４，Ｂ６）では、自側着手確定処理（図１１）、終局後処理（図１４）、着手自動選択処理（図１５、図１
７）などの各種処理が実行される。各処理の詳細については後述する。
【００４１】
まず、相手着手受信処理について、図７に示すフローチャートを参照しながら説明する。
サーバ装置３０は、対局相手からの着手情報コマンドについて、利用者レコードＵＲの対局ステータスフィールドが３（対局中）であるときに限って処理を行う（ステップＣ１）。サーバ装置３０は、プロセス間通信チャネルから対局相手から着手情報コマンドを受信すると、相手着手確定処理を実行して（ステップＣ２）、同じ内容をＴＣＰ／ＩＰソケットに（利用者端末１０−２に）送出する（ステップＣ３）。これにより、利用者端末１０−２において対局相手の着手を表示できるようにする。そして、対局相手の着手に対応する着手を決定するために自着手処理振り分け処理を実行する（ステップＣ４）。
【００４２】
ここで、相手着手確定処理（ステップＣ２）の詳細について、図８に示すフローチャートを参照しながら説明する。
サーバ装置３０は、対局相手から受信した着手情報コマンドが投了を示していない場合には（ステップＥ１）、着手情報の内容に従って局面状態データを更新し（ステップＥ４）、さらに今回の相手着手によって終局状態となるかを判別するために終局判定処理を実行する（ステップＥ５）。なお、終局判定処理では、局面状態データに登録されたデータをもとに、終局状態判定モジュールによって、実質的に終局状態（通常の着手がされることで勝敗が決定される状態）となっているか否かを判定する。
【００４３】
なお、終局状態判定モジュールは、ゲームの種類により、それぞれのルールにしたがって構成され、どの程度の判定ができるかは様々である。ここでは、最も単純な構成例として、チェスの場合に有効な一つの例を述べると、片方の対局車の盤面に残っている駒がＫｉｎｇのみであり、もう片方の対局者が盤面にＫｉｎｇ以外にＱｕｅｅｎ，Ｒｏｏｋの何れかが残っている場合（Ｋｉｎｇが直ちにＲｏｏｋを取れる場合を除く）、これを判別する手段は自明に構成でき、この時、「事実上終局状態」であり、Ｋｉｎｇのみの対局者を「事実上敗者」、もう片方を「事実上勝者」と判定する。ルール上はさらに手を進めることは可能であるが、Ｋｉｎｇのみの対局者はいくら指し続けても勝つことはできず、熟練した対局者間では事実上引き分けの可能性もないと見なしてよいことが知られているからである（さらに判定範囲の広い方法も構築できるが、ここでは説明を単純化している）。
【００４４】
終局判定処理の結果、終局状態にあると判定された場合には、終局状態であることを設定すると共に（事実上終局を示すフラグＥ＝１に設定する。それ以外の場合にはＥ＝０）（ステップＥ６）、現在手数を表す変数Ｎを更新（＋１）する（ステップＥ７）。そして、利用者端末１０−１において相手着手を表示させる（ステップＥ８）
一方、対局相手からの着手情報コマンドが投了を示している場合（ステップＥ１）、サーバ装置３０は、勝局時処理を実行する。
【００４５】
勝局時処理では、利用者データベース４２ｂの該当利用者レコードＵＲのレーティング値を対局に勝ったことに応じて更新するためにレーティング増加分（ｒ：レーティング値差分）を算出する（ステップＥ２）。レーティング値は、利用者の操作によらずエージェントモードにより着手を自動的に決定する場合に参照されるもので、ゲームに対する利用者の強さのレベルを表している。すなわち、対局の勝ちに応じてレーティング値を上げることで、利用者のゲームに対する強さに連動するようにエージェントのレベル（棋力）を上げることができる。従って、利用者にとっては、エージェントが自分とともに強くなっていくことに達成感を得ることができるようになる。
【００４６】
例えば、レーティング増加分は、１６＋０．０４×（対局相手のレーティング値−利用者のレーティング値）により算出するものとする。なお、レーティング値の算出方法については、対局の勝敗に応じて強さのレベルを表すことができれば他の方法を用いることも可能である。
【００４７】
また、サーバ装置３０は、レーティング値の増加分を算出した後、終局後処理を実行する（ステップＥ３）。
【００４８】
図１４には、終局後処理の動作についてのフローチャートを示している。終局後処理では、まず該当利用者レコードＵＲのレーティング値フィールドに格納されている現在のレーティング値に、ステップＥ２において算出したレーティング増加分（ｒ）を加算する（ステップＬ１）。
【００４９】
また、利用者レコードＵＲの前回勝敗フィールドと前回対局棋譜フィールドの内容を今回の対局のものに置換すると共に（ステップＬ２）、対局が終了した状態にあることを示すように対局ステータスを４に更新する（ステップＬ３）。サーバ装置３０は、こうして更新した利用者レコードＵＲによって利用者データベース４２ｂを更新する。なお、思考エージェントモードによる着手を使用しなかった時は、後述する自側着手受信処理において、利用者レコードＵＲの平均着手所要時間についても更新される。
【００５０】
一方、自着手処理振り分け処理（ステップＣ４）は、図９に示すフローチャートに示すようにして実行する。サーバ装置３０は、自着手処理振り分け処理によって、相手着手に対して、エージェントモードにより次の着手を決定するか、利用者によって着手を入力させるかを振り分ける。
すなわち、定跡エージェントモード、トレースエージェントモード、あるいは思考エージェントモードの何れかが有効化されている場合には（ステップＤ１，Ｄ３，Ｄ５）、その有効化されたモードのエージェント処理を実行して利用者に代わって着手を決定する（ステップＤ２，Ｄ４，Ｄ６）。
【００５１】
一方、何れのエージェントモードも有効化されていない場合には、サーバ装置３０は、利用者端末１０−１において利用者に着手操作を促すために「着手入力してください」のメッセージを表示させると共に（ステップＤ７）、着手に要する時間を計測するために着手時間タイマ計時を開始する（ステップＤ８）。こうして、着手毎に着手の所要時間を計時し、予め定めた持ち時間から漸次減算して残り時間を制限する。
【００５２】
次に、各エージェントモードにおける処理について、図１０〜図１２に示すフローチャートを参照しながら説明する。
まず、図１０に示すフローチャートを参照しながら、定跡エージェント処理について説明する。
【００５３】
まず、サーバ装置３０は、定跡データベース４２ｃに登録された通し番号Ｊのレコード（以下、定跡レコードＪＲ）を取得してメモリ４１に格納する。なお、通し番号Ｊの初期値としては、対局開始前の前処理において先手番の場合には１、後手番の場合には２が設定されている。
【００５４】
ここで、通し番号Ｊが１の場合、すなわち先手番初手に対応する通し番号である場合には、自着手を定跡レコードＪＲの自着手情報が示す着手に決定し（ステップＦ１３）、自側着手確定処理を実行する（ステップＦ１４）。なお、自側着手確定処理の詳細については後述する（図１１）。
【００５５】
一方、通し番号Ｊが１でない場合、すなわち先手番初手に対応する通し番号でない場合には、自着手に対する相手着手が定跡レコードＪＲの相手着手情報ａ〜ｃの何れかに該当するかを判別する（ステップＦ３）。ここで、相手着手が定跡レコードＪＲの相手着手情報ａに該当する場合、通し番号Ｊに相手着手情報ａと対応づけられた後続通し番号ａを設定する（ステップＦ４）。一方、相手着手が定跡レコードＪＲの相手着手情報ｂに該当する場合、通し番号Ｊに相手着手情報ｂと対応づけられた後続通し番号ｂを設定し（ステップＦ５）、相手着手情報ｃに該当する場合、通し番号Ｊに相手着手情報ｃと対応づけられた後続通し番号ｃを設定する（ステップＦ６）。なお、相手着手が相手着手情報ａ〜ｃの何れにも該当しなかった場合には、対局相手が定跡と外れた着手をしたものとして、定跡エージェントモードを無効化するために通し番号Ｊに０を設定する（ステップＦ７）。
【００５６】
ここで、通し番号Ｊの値が０の場合には（ステップＦ８）、定跡エージェントを無効化する（ステップＦ９）。そして、利用者端末１０−１において定跡エージェントモードが終了したことを利用者に通知するために「定跡終了」のメッセージを表示させると共に（ステップＦ１０）、利用者に次の着手の入力操作を促すために「着手入力してください」のメッセージを表示させて（ステップＦ１１）、着手に要する時間を計測するために着手時間タイマ計時を開始する（ステップＦ１２）。
【００５７】
なお、通し番号Ｊの値が０でない場合には、自着手を定跡レコードＪＲの自着手情報が示す着手に決定し（ステップＦ１３）、自側着手確定処理を実行する（ステップＦ１４）。すなわち、対局相手が定跡レコードＪＲに登録された相手着手情報により示される着手をした場合には、同定跡レコードＪＲに登録された対応する自着手情報により示される着手を自着手とする。
【００５８】
次の自着手処理振り分け処理で定跡エージェント処理を実行する際には、ステップＦ４〜Ｆ７において設定された後続通し番号の定跡レコードが取得されて前述と同様の処理が実行される。従って、エージェント処理では、定跡レコードに登録された相手着手情報が示す着手を対局相手がする場合には、その着手に対応する定跡による着手を自着手として対局に対応することができる。
【００５９】
このようにして、定跡エージェントモードを利用することにより、対局の序盤などにおいて定跡通りに着手を進める場合には、定跡エージェントによって対局を代行させて、利用者による着手のための操作を不要とすることができる。
【００６０】
ここで、自側着手確定処理について、図１１に示すフローチャートを参照しながら説明する。
【００６１】
サーバ装置３０は、利用者レコードＵＲの対局ステータスフィールドが３（対局中）でであり（ステップＫ１）、着手が投了を示していない場合には（ステップＫ２）、着手情報の内容に従って局面状態データを更新し（ステップＫ５）、現在手数を表す変数Ｎを更新（＋１）する（ステップＫ６）。そして、ＴＣＰ／ＩＰソケット（利用者端末１０−１）から受信した着手情報コマンドを、そのままプロセス間チャネル（利用者端末１０−２）に転送すると共に（ステップＫ６）、利用者端末１０−１において利用者が着手の更新を容易に確認できるようにするために着手更新確認表示をさせる（ステップＫ８）。
【００６２】
一方、着手が投了を示している場合（ステップＫ２）、サーバ装置３０は、敗局時処理を実行する。
【００６３】
敗局時処理では、利用者データベース４２ｂの該当利用者レコードＵＲのレーティング値を対局に負けたことに応じて更新するためにレーティング減少分（ｒ：レーティング値差分）を算出する（ステップＫ３）。レーティング値は、ゲームに対する利用者の強さのレベルを表すため、対局の負けに応じてレーティング値を上げることで、利用者のゲームに対する強さに連動するようにエージェントのレベル（棋力）を下げることができる。
【００６４】
例えば、レーティング増加分は、１６＋０．０４×（利用者のレーティング値−対局相手のレーティング値）により算出するものとする。なお、レーティング値の算出方法については、勝局時処理と同様にして、対局の勝敗に応じて強さのレベルを表すことができれば他の方法を用いることも可能である。
【００６５】
また、サーバ装置３０は、レーティング値の減少分を算出した後、終局後処理を実行する（ステップＫ４）。なお、終局後処理については、前述したように、図１４示すフローチャートに従って実行されるものとして説明を省略する。
【００６６】
次に、図１２に示すフローチャートを参照しながら、トレースエージェント処理について説明する。
【００６７】
まず、サーバ装置３０は、現在手数Ｎが０である場合（ステップＧ１）、すなわち初手番の場合には、利用者データベース４２ｂの利用者レコードＵＲに登録された前回対局棋譜［０］を自着手として設定し（ステップＧ２）、自側着手確定処理を実行する（ステップＧ３）。
【００６８】
また、サーバ装置３０は、現在手数Ｎが利用者レコードＵＲに前回対局棋譜が登録されている３０未満であって、かつ直前の対局相手の着手が前回対局棋譜［Ｎ−１］の場合（ステップＧ４）、すなわち利用者レコードＵＲに登録された前回対局棋譜に従って着手がされている場合には、利用者データベース４２ｂの利用者レコードＵＲに登録された前回対局棋譜［Ｎ］を自着手として設定し（ステップＧ５）、自側着手確定処理を実行する（ステップＧ６）。
【００６９】
一方、ステップＧ１，Ｇ４の何れの条件にも該当しない場合には、サーバ装置３０は、トレースエージェントを無効化し（ステップＧ７）、利用者端末１０−１においてトレースエージェントモードが終了したことを利用者に通知するために「トレース終了」のメッセージを表示させると共に（ステップＧ８）、利用者に次の着手の入力操作を促すために「着手入力してください」のメッセージを表示させて（ステップＧ９）、着手に要する時間を計測するために着手時間タイマ計時を開始する（ステップＧ１０）。
【００７０】
このようにして、トレースエージェントモードを利用することにより、前回の対局で勝った時と同じように着手を進める場合には、トレースエージェントによって前回対局棋譜をもとにして着手を代行させることができるので、利用者による着手のための操作を不要とすることができる。
【００７１】
次に、図１３に示すフローチャートを参照しながら、思考エージェント処理について説明する。
【００７２】
まず、サーバ装置３０は、利用者レコードＵＲのレーティング値を参照して、このレーティング値が予め設定されているレベル判定に用いる基準値より大きいかを判別する（ステップＨ１）。ここでは、例えば基準値を１６００としてレーティング値が示すレベルを判別し、基準値１６００を越えていればレベル３と設定し（ステップＨ２）、基準値１６００以下であればレベル２と設定する（ステップＨ３）。ここで設定されたレベルは、後述する着手自動選択処理において用いられる。また、現時点における利用者の残り持ち時間ｔ（秒）を算出する（ステップＨ４）。
【００７３】
ここで、サーバ装置３０は、着手自動選択モジュールによる着手自動選択処理を起動し、現在の局面状態データを入力として次の自着手を決定する（ステップＨ５）。
【００７４】
図１５には、着手自動選択処理のフローチャートを示している。着手自動選択処理では、まず現在の局面状態データが示す局面から次に着手がされた場合の次局面を、可能性のある着手（全部の着手でも良いが、有力な着手に限定して処理効率を図るものとする）のそれぞれについて求め、これら複数の次局面からなる次局面集合を生成する（ステップＭ１）。
【００７５】
さらに、次局面集合に含まれる各次局面について、次局面から次に着手がされた場合の次々局面を、可能性のある着手のそれぞれについて求め、これら複数の次々局面からなる次々局面集合を生成する（ステップＭ２）。
【００７６】
ここで、思考エージェント処理において利用者のレーティング値をもとにして求めたレベルがレベル２を越えているか、つまり利用者のゲームに対する強さが所定レベルより高いかを判別する（ステップＭ３）。
【００７７】
レベル２を越えている場合には、さらに次々局面集合に含まれる各次々局面について、次々局面から次に着手がされた場合の次々々局面を、可能性のある着手のそれぞれについて求め、これら複数の次々々局面からなる次々々局面集合を生成する（ステップＭ４）。
【００７８】
図１６には、前述のように局面集合が生成される様子を概念的に示すツリー構造である。図１６は、レベル２に対応するツリー構造であり、現在の局面に対して次局面１〜Ｎが生成され、次局面１〜Ｎのそれぞれについて次々局面が生成されている（次局面１に対して次々局面１，１〜１，Ｎが生成されている）。このように、利用者のレーティング値の高低（利用者のゲームに対する強さの実績レベル）に合わせて、思考エージェントの読みの深さ（すなわち強さ）を変えることにより、思考エージェント処理により決定される着手を利用者が実際に着手した場合と同様の強さにすることができる。
【００７９】
サーバ装置３０は、利用者のレーティング値に応じて生成した局面集合から、予め決めた局面の評価関数によって枝刈りしながら一定の深さまで木構造に探索し、同じく評価関数によってＭｉｎ−Ｍａｘ法を適用して最前手順（ツリーの１個の経路）を選択し（ステップＭ５）、その最前手順の初手を戻り値（思考エージェントが決定する着手）として設定し（ステップＭ６）、思考エージェント処理に戻る。
【００８０】
なお、図１５のフローチャートに示す着手自動選択処理では、利用者のレベルに応じた深さまでの局面集合を生成するものとしているが、必要な深さまでの局面集合を生成するために長い処理時間が必要となるなど処理負担が大きい場合には、局面集合を生成する時間を制限するようにしても良い。
【００８１】
図１７には、局面集合を生成する時間ｗを制限した着手自動選択処理のフローチャートを示している。この場合、着手自動選択処理では、予め決められた時間ｗが経過するまでの間、利用者のレーティング値をもとにして求められる深さレベル以内で、順次、次局面集合、次々局面集合…を生成していく（ステップＮ１，Ｎ２）。
【００８２】
そして、予め決められた時間ｗ（秒）が経過すると、利用者のレーティング値をもとにして求められる深さレベルまでの局面集合が生成されていなくても、その時点で局面集合の生成を終了し、図１５のフローチャートに示す着手自動選択処理のステップＭ５，Ｍ６と同様にして、Ｍｉｎ−Ｍａｘ法を適用して最前手順を選択し（ステップＮ３）、その最前手順の初手を戻り値（思考エージェントが決定する着手）として設定する（ステップＮ４）。
【００８３】
ここで、思考エージェント処理では、残り持ち時間ｔと利用者レコードＵＲの平均着手所要時間［０］〜［３］に応じて、着手情報コマンドを対局相手に送出するまでの待ち時間（ｗ秒）を算出する。すなわち、平均着手所要時間［０］〜［３］には、それぞれ残り時間が１０分以上ある場合、残り時間が５〜１０分の場合、残り時間が３〜５分の場合、残り時間が３分未満の場合の利用者の平均着手時間が登録されているので、残り持ち時間ｔに応じた平均所要時間を自側着手に要する時間とすることで、実際に利用者が対局している場合と同様に持ち時間を経過させることができる。
【００８４】
ただし、残り持ち時間ｔが１０秒未満であり、かつ事実上終局を示すフラグがセット（Ｅ＝１）されている場合には、待ち時間ｗを０（待ち時間無し）として設定する（ステップＨ７）。これにより、事実上負けが決まっている対局相手が、時間切れによる勝ちを狙った対応をしたとしても、残り持ち時間を消費することなく着手が進められるので、事実上勝っている対局を時間切れによって負けることを回避できる。
【００８５】
また、残り持ち時間ｔが１８０秒未満である場合には、待ち時間ｗを利用者レコードＵＲの平均着手所要時間［３］に登録された時間（残り時間が３分未満の場合の利用者の平均着手時間）として設定する（ステップＨ８）。
【００８６】
また、残り持ち時間ｔが３００秒未満である場合には、待ち時間ｗを利用者レコードＵＲの平均着手所要時間［２］に登録された時間（残り時間が３〜５分未満の場合の利用者の平均着手時間）として設定する（ステップＨ９）。
【００８７】
また、残り持ち時間ｔが６００秒未満である場合には、待ち時間ｗを利用者レコードＵＲの平均着手所要時間［１］に登録された時間（残り時間が５〜１０分未満の場合の利用者の平均着手時間）として設定する（ステップＨ１０）。
【００８８】
また、残り持ち時間ｔが６００秒以上である場合には、待ち時間ｗを利用者レコードＵＲの平均着手所要時間［０］に登録された時間（残り時間が１０分以上の場合の利用者の平均着手時間）として設定する（ステップＨ１１）。
【００８９】
サーバ装置３０は、ステップＨ７〜Ｈ１１の何れかの処理において設定された待ち時間ｗに応じてｗ秒待った後（ステップＨ１２）、自側着手確定処理を実行することにより、着手自動選択処理によって決定した着手の着手情報コマンドをプロセス間チャネル（対局相手）に送信する（ステップＨ１３）。
【００９０】
このようにして、思考エージェントモードを利用することにより、対局中の任意のタイミングで着手自動選択処理（モジュール）により決定される着手により対局を代行させて、利用者による着手のための操作を不要とすることができる。利用者の利用者端末１０−１では、着手自動選択処理により決定された着手がホスト装置１６から送信されて、局面状態が表示されるのみとなる。着手自動選択処理では、利用者のゲームに対する強弱を表すレーティング値に応じて読みの深さを変え、また利用者の実際に対局をした場合の平均着手所要時間に応じた時間を持ち時間から消費して着手するため、思考エージェントモードの利用により対局相手に不公平感を持たせることがない。
【００９１】
次に、図１８に示すフローチャートを参照しながら、自側着手受信処理について説明する。
【００９２】
サーバ装置３０は、利用者端末１０−１（利用者）からの着手情報コマンドについて、利用者レコードＵＲの対局ステータスフィールドが３（対局中）であるときに限って処理を行う（ステップＪ１）。
【００９３】
着手時間タイマ計時を開始してから着手（着手情報コマンドを受信した時点）までの着手にかかった時間ｕ（秒）を設定し（ステップＪ２）、この時間ｕをもとに利用者の残り待ち時間ｔ（秒）を更新する（ステップＪ３）。
【００９４】
ここで、残り待ち時間ｔに応じて、利用者レコードＵＲの平均着手所要時間［０］〜［３］の更新を行う。
例えば、残り待ち時間ｔが１８０秒未満である場合には、利用者レコードＵＲの平均着手所要時間［３］の着手時間総和に着手にかかった時間ｕを加算し、サンプル総数に１を加算する（ステップＪ５）。
【００９５】
また、残り待ち時間ｔが３００秒未満である場合には、利用者レコードＵＲの平均着手所要時間［２］の着手時間総和に着手にかかった時間ｕを加算し、サンプル総数に１を加算する（ステップＪ６）。
【００９６】
また、残り待ち時間ｔが６００秒未満である場合には、利用者レコードＵＲの平均着手所要時間［１］の着手時間総和に着手にかかった時間ｕを加算し、サンプル総数に１を加算する（ステップＪ７）。
【００９７】
また、残り待ち時間ｔが６００秒未満である場合には、利用者レコードＵＲの平均着手所要時間［０］の着手時間総和に着手にかかった時間ｕを加算し、サンプル総数に１を加算する（ステップＪ８）。
【００９８】
そして、受信した着手情報コマンドを自着手に設定し（ステップＪ９）、前述した自側着手確定処理（図１１）を実行する（ステップＪ１０）。
【００９９】
こうして、自側着手受信処理において、利用者の実際の着手の際に要した時間をもとに平均着手所要時間を更新することで、思考エージェントモードにより対局を代行させる場合に、利用者が実際に対局するときと同様に持ち時間を消費するように制御することができる。
【０１００】
このようにして、エージェントモードを利用して対局をすることで、利用者は、対局中に利用者端末１０から離れても（情報入力をしなくても）対局が継続されるため、中座しても負けにならなず、また対局相手に不快感を与えることもない。また、対局中に利用者端末１０から離れない場合であっても以前に行った対局と同様の着手をする場合や定跡に従った着手をする場合など、決まりきった着手をするのであれば、トレースエージェント、定跡エージェントに着手を代行させて単純作業的な情報入力の手間を省いて楽をすることができる。
【０１０１】
また、思考エージェントモードを利用した場合では、利用者の強さのレベルに応じた着手を決定するので、思考エージェントの使用に公正・公平感を持たせることができ、また対局に勝ったという実績を残すことで思考エージェントが強くなっていくので達成感を提供することができる。さらに、思考エージェントモードによる着手では、持ち時間についても、実際に利用者が対局を行った場合に消費する時間（平均着手使用時間）に応じて消費するので、思考エージェントの使用に公正・公平感を持たせ、またエージェントが対局を代行することによる不自然な早指し、後指しを防ぐこともできる。さらに、思考エージェントモードを利用することで、端末操作（着手情報の入力操作）に要する時間を利用して相手を持ち時間切れに持ち込み、終了盤面では事実上負けであるのに勝負に勝つという不自然な現象が起きる頻度を減少させることができる。特に持ち時間が切れ負け（対局を通しての使用時間が総和で制限されており一手あたりの最低時間が確保されない）制である場合に効果がある。
【０１０２】
なお、前述した説明では、思考エージェントモード時には、全て思考エージェントにより着手を決定させて対局を進行させるものとして説明しているが、全ての着手について自動的に進行させるのではなく、各着手あるいは所定の条件に一致する着手について利用者に確認を求めるようにし、承認の応答があった場合にこの着手によって対局を進めるようにしてもよい。この時、利用者に確認を求めた際に、予め決められた時間内に応答がなかった場合（タイムアウト時）は承認されたものと判断するようにしても良い。
【０１０３】
また、前述した説明では、定跡エージェントモードにおいて、定跡手順を初手からとして説明しているが、対局途中からの着手について定跡エージェントを利用できるようにしても良い。例えば囲碁の場合、対局途中で盤面の一部分のパターンが定跡（定石）のパターンと一致した時に、定跡エージェントを起動するようにしても良い。
【０１０４】
また、定跡データベース４２ｃや、終局状態判定モジュール、着手自動選択モジュールをホスト装置１６に設けるのではなく、利用者端末１０内に設けるようにしても良い。これによれ、各エージェント処理の一部または全部を利用者端末１０で処理することができる。
【０１０５】
また、前述した説明では、利用者データベース４２ｂの利用者レコードＵＲに登録される前回対局棋譜は１回の対局分だけとしているが、過去に行われた複数回分の棋譜を登録するようにしても良く、例えば過去に行われた全ての対局の棋譜を登録してトレースエージェント処理に利用するようにしても良い。その場合、定跡データベース４２ｃと同様に木構造（グラフ構造）に構成してもよい。
【０１０６】
また、終局状態判定は、先読みによって行なってもよいし、対局が囲碁の場合は地の判定を用いて行なってもよい。
【０１０７】
また、単一のサーバ装置３０によって対戦サービスを提供するのではなく、複数のサーバ装置３０を設けて対戦サービスを提供する機能を分散して実行させるようにしてもよい。
また、図１に示すシステム構成では、利用者端末１０と公衆網１４とは有線接続されるものとしているが、ＰＨＳ（personal handyphone system）網、携帯電話網など無線電話網を使用してパケット通信を行う構成であっても良い。
また、前述した実施形態において記載した手法は、コンピュータに実行させることのできるプログラムとして、例えば磁気ディスク（フレキシブルディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリなどの記録媒体に書き込んで各種装置に提供することができる。また、通信媒体により伝送して各種装置に提供することも可能である。本装置を実現するコンピュータは、記録媒体に記録されたプログラムを読み込み、または通信媒体を介してプログラムを受信し、このプログラムによって動作が制御されることにより、上述した処理を実行する。
【０１０８】
また、本発明は、前述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、前述した実施形態の各機能は可能な限り適宜組み合わせて実施しても良い。前述した実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜の組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、効果が得られるので有れば、この構成要件が削除された構成が発明として抽出され得る。
【０１０９】
【発明の効果】
以上のように本発明によれば、通信手段を介した相手と対戦ゲームをする利用者による操作を代行する機能を設けることによって、対戦ゲームに参加する利用者が対戦の最初から最後まで互いに対戦相手につきあう必要がなくなるので、利用者の負担を軽減することができ、利用者にとっての利便性、使用感の上で向上を図ることが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係わるネットワーク対戦システムの構成を示すブロック図。
【図２】着手情報コマンドの構造体の一例を示す図。
【図３】局面（盤面）状態データの構造体の一例を示す図。
【図４】利用者データベース４２ｂのレコード構造の一例を示す図。
【図５】定跡データベース４２ｃのレコード構造の一例を示す図。
【図６】本実施形態における利用者端末１０とサーバ装置３０における動作の概略について説明するためのフローチャート。
【図７】相手着手受信処理について説明するためのフローチャート。
【図８】相手着手確定処理（ステップＣ２）の詳細について説明するためのフローチャート。
【図９】自着手処理振り分け処理について説明するためのフローチャート。
【図１０】定跡エージェント処理について説明するためのフローチャート。
【図１１】自側着手確定処理について説明するためのフローチャート。
【図１２】トレースエージェント処理について説明するためのフローチャート。
【図１３】思考エージェント処理について説明するためのフローチャート。
【図１４】終局後処理の動作について説明するためのフローチャート。
【図１５】着手自動選択処理の動作について説明するためのフローチャート。
【図１６】局面集合が生成される様子を概念的に示すツリー構造の図。
【図１７】局面集合を生成する時間ｗを制限した着手自動選択処理の動作について説明するためのフローチャート。
【図１８】自側着手受信処理について説明するためのフローチャート。
【符号の説明】
１０−１，１０−２…利用者端末
１４…公衆網
１６…ホスト装置
２０…メモリ
２１…ＣＰＵ
２２…ＬＣＤ
２３…タッチパネル
２４…モデム
３０…サーバ装置
３４…ルータ
４０…ＣＰＵ
４１…メモリ
４２…記録装置
４３…イーサネット（登録商標）Ｉ／Ｆ
４４…回線制御部
４４ａ…回線Ｉ／Ｆ
４４ｂ…スイッチ部
４４ｃ…音声応答部
【図１】
0004211234.tif 000002
【図２】
0004211234.tif 000003
【図３】
0004211234.tif 000004
【図４】
0004211234.tif 000005
【図５】
0004211234.tif 000006
【図６】
0004211234.tif 000007
【図７】
0004211234.tif 000008
【図８】
0004211234.tif 000009
【図９】
0004211234.tif 000010
【図１０】
0004211234.tif 000011
【図１１】
0004211234.tif 000012
【図１２】
0004211234.tif 000013
【図１３】
0004211234.tif 000014
【図１４】
0004211234.tif 000015
【図１５】
0004211234.tif 000016
【図１６】
0004211234.tif 000017
【図１７】
0004211234.tif 000018
【図１８】
0004211234.tif 000019