JP2006239470A - サーバ装置、ネットワークゲームシステム、対局者選定プログラムを記録したコンピュータ読み取り可能な記録媒体及び対局者選定方法 - Google Patents

Abstract

【課題】自動的に最適な対局相手を確実に選定する。
【解決手段】対局者選定部５４０は、対局要求を受けた場合、その要求を発行した利用者を対局待ちに設定すると共に、その利用者のステージ情報を読み取る。次に、自動選定処理部５４１が、ステージ情報が同じで、かつ対局待ちである利用者を読み取り、選定処理を行う。ステージ管理部５７０は、対局が終了した場合にクライアント装置６００から送られてくる終了の通知を受け取る。その通知に基づいて、対局者のステージ情報を利用者ＤＢ５３０から読み取り、各対局者のステージ情報を更新する。上記トーナメント戦の例では、勝った対局者のステージ情報に１を加え、負けた方はこのトーナメント戦から削除する。
【選択図】図３０

Description

本発明は、将棋、囲碁、チェス、オセロ、麻雀、テレビゲームなどの室内ゲームを遂行するためのネットワークゲームシステム、ネットワークゲームサーバ装置、対局者選定プログラムを記録したコンピュータ読み取り可能な記録媒体及び対局者選定方法に関し、特に不特定多数の参加者の中から対局相手を選択するためのネットワークゲームシステム、ネットワークゲームサーバ装置、対局者選定プログラムを記録したコンピュータ読み取り可能な記録媒体及び対局者選定方法に関する。

将棋、囲碁、チェス、オセロ、対戦型テレビゲームなどの室内ゲームは、対局者が同時刻に、かつ同じ場所にて対局するのが一般的であった。ところが、近年の情報通信技術の進歩により、コンピュータを通信回線で接続し、遠く離れた場所でも対局できるようなツールが開発された。これにより、自宅に居ながらにしてゲームの対局が可能となっている。ただし、この場合、対局を希望する者が個別の場所にいるため、対局相手を選ぶのが困難となっている。

そこで、これをさらに使いやすくするため、対局可能な個人情報を登録し、その内容を対局希望者の端末装置の画面に表示する対局者表示システムが考えられている（特開平７−９５３２１号公報）。このシステムを用いれば、対局希望者は、画面上の任意の対局者を選択することにより対局相手を特定し、特定した対局相手と対局できる。上記公報に開示された発明は電話網を利用したものであるが、インターネット上においてもホームページを利用して、利用者をリストアップすることによって上記のシステムと同様な機能が実現されている。

ところが、このような対局者表示システムでは、利用者自身が、自分に見合った相手を自分で探し自分で連絡を取り合わなければならない。これは、下記の点で困難である。
１）対局したい相手が、対局を希望していない場合がある。
２）対局したい相手が、対局中で、すぐに対局できない場合がある。
３）対局したい相手の対局が終了するまで、モニタする必要がある。
４）対局相手が選択できるまで、本来の目的である対局以外の作業をしなくてはならず、また時間もかかる。

そこで、電話網を利用した仕組みで、ホストコンピュータによって対局相手を自動的に選択し、見つかったら、要求を出した利用者に通知する対局者選択システムも考えられている。このシステムでは、対局を希望する利用者が対局要求をホストへ送信する。このとき特定の相手を指定しない対局を希望する際には、対局相手の強さを指定する。

ホスト側では、希望条件に合致する者を対局相手として選択する。すなわち、指定された強さの者を対局相手として選択する。そして、対局者の双方に、相手方の情報を通知する。ここで、対局相手が対局ＯＫの信号を返さなければ、別の対局相手を探す。（たとえば、特許文献１参照）
これにより、対局が可能な者の中から、指定された強さの者が自動的に選択される。その結果、利用者にとっては対局相手を選ぶ手間が省けることとなり、便利である。
特公平７−６３５４６号公報

しかし、特公平７−６３５４６号公報に記載された対局者選択システムでは、利用者が対局相手の強さ指定するため、指定した強さの者がいなければ待機状態となってしまうという問題点が依然として残っている。

しかも、各利用者が対局相手の強さを指定するため、双方の指定が一致しない限り対局相手が選定されない。例えば、強さ「５」の者が対局相手として、強さ「６」の者を指定したとする。このとき、強さ「６」の者が待機状態にあっても、その者が強さ「７」の者との対局を希望していた場合には、これらの者が対局相手として選定されることはない。このように、自身より少しだけレベルの高い相手との対局を望むのは自然の心理である。そのため、いつまでも対局相手が選定されない場合もありうる。

本発明はこのような点に鑑みなされたものであり、利用者が対局相手を自ら選択する手間を省き、かつ、自動的に最適な対局相手を確実に選定するサーバ装置、ネットワークゲームシステム、対局者選定プログラムを記録したコンピュータ読み取り可能な記録媒体及び対局者選定方法を提供することを目的とする。

本発明では上記課題を解決するために、通信ネットワーク上の複数の参加者にゲームの対局を行わせるサーバ装置において、上下関係を有する複数のステージのいずれかに属する複数の利用者の情報を、各利用者が属するステージを示すステージ情報に対応づけて格納する利用者情報記憶手段と、対局要求を受け取ると、前記対局要求を発信した利用者を登録する対局要求応答手段と、登録された利用者のうち同一のステージに属する複数の利用者を前記利用者情報記憶手段から選択し、選択された利用者による対局をステージ毎に決定する対局者選定手段と、対局結果を受け取ると、前記利用者情報記憶手段内の勝利した利用者のステージ情報を、上位のステージに変更するステージ管理手段と、を有することを特徴とするサーバ装置が提供される。

このゲーム装置によれば、対局要求を受け取ると、対局要求応答手段により、対局要求を発信した利用者が登録される。次に、対局者選定手段により、登録された利用者のうち同一のステージに属する利用者から選定対象となる組み合わせが利用者情報記憶手段から選択され、選択された利用者による対局がステージ毎に決定される。そして、対局結果を受け取ると、ステージ管理手段により、利用者情報記憶手段内の勝利した利用者のステージ情報が、上位のステージに変更される。

このように、サーバ装置内であらかじめ指定された条件にしたがって、対局の組み合わせが最適になるように決定されるため、利用者が対局相手を自ら選択することなく、自動的に最適な対局相手を確実に選定することができる。

本発明のネットワークゲームシステムでは、サーバ装置において、より適した組み合わせとなるようにあらかじめ指定された条件に基づいて選定を行うことで、いつまでも対局相手が選定されないといったことがなくなる。また、最適の相手を見つけられる可能性が高くなる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、本発明の関連技術の原理構成図である。ネットワークゲームシステムは、サーバ装置１０とクライアント装置２０とで構成される。サーバ装置１０とクライアント装置２０とは、ネットワーク３１を介して接続されている。

サーバ装置１０は、利用者情報記憶手段１１、対局者選定手段１２、対局相手通知手段１３、及び対局管理手段１４を有している。
利用者情報記憶手段１１は、複数の利用者の情報を格納する。

対局者選定手段１２は、クライアント装置２０より対局要求を受け取ると、対局要求を発信した利用者を対局待ちとして区別する。そして、あらかじめ指定された対局者選定処理の開始条件が満たされると、より適した組み合わせとなるようにあらかじめ指定された条件にしたがって、対局待ちとして区別された利用者同士の対局の組み合わせを決定する。

対局相手通知手段１３は、対局者選定手段１２により、対局相手が決定された利用者の情報を利用者情報記憶手段１１から抽出し、抽出した情報と対局識別子とを、対局相手のクライアント装置２０に対して通知する。

対局管理手段１４は、対局者選定手段１２が選定した対局者同士のゲームの進行を中継する。具体的には、一方の対局者のクライアント装置２０から送られた指し手を、対局相手のクライアント装置へ通知する。ここで、各対局は、対局識別子により区別する。

クライアント装置２０は、対局要求手段２１と対局手段２２とで構成される。対局要求手段２１は、対局要求をサーバ装置１０へ出力し、サーバ装置１０からの対局相手に関する対局者情報を受け取る。対局手段２２は、対局識別子を用いて、対局者情報で指定された対局相手と、通信ネットワークを介してゲームの対局を行う。

このようなネットワークゲームシステムにおいて、クライアント装置２０を使用する利用者は、まず対局をしたい旨の指令を入力する。すると、対局要求手段２１が対局要求をサーバ装置１０に対して送信する。対局要求を受け取ったサーバ装置１０では、対局者選定手段１２が、対局要求を発信した利用者を対局待ちとする。そして、あらかじめ指定された対局者選定処理の開始条件が満たされると、予め定められた選定条件にしたがって、対局者選定手段１２が、対局待ちとされている利用者同士の対局の組み合わせを決定する。組み合わせが決定されると、対局相手通知手段１３により、各当事者のクライアント装置２０に対して、対局相手の対局者情報（対局識別子を含む）を応答する。応答された対局者情報は、クライアント装置２０の対局要求手段２１で受け取られる。クライアント装置２０の利用者は、対局要求手段２１が受け取った対局識別子と共に指し手を送信することで、対局手段２３によりネットワークゲームの対局を行う。

ところで、対局者選定処理手段にあらかじめ定められた選定条件とは、以下の条件のひとつまたは複数の組み合わせをいう。
１）対局希望要求を受信する毎に、その対局希望要求者についての対局者選定処理を行う。この時、待ち時間の長い対局待ち利用者を優先して選定対象としてもよい。
２）あらかじめ指定された時間がきたら、対局者選定処理を行う。
３）対局待ち利用者数があらかじめ指定された数を超えたら、対局者選定処理を行う。
４）対局希望要求の受信数があらかじめ指定された数を超えたら、対局者選定処理を行う。
５）あらかじめ決められた時間内に、対局者が決まらなかった利用者に対して、別の対局者ＤＢより対局者を選定する。
６）対局者の強さを示す点数の増減の微分値により、対局相手の選定範囲を決定する。
７）対局待ちの利用者の対局待ちの時間に応じて、対局相手の選定範囲を変化させる。

このように、利用者からの指定条件（例えば、対局相手の強さの指定）に基づかずに、サーバ装置において、より適した組み合わせとなるようにあらかじめ指定された条件に基づいて選定を行うことで、いつまでも対局相手が選定されないといったことがなくなる。また、最適の相手を見つけられる可能性が高くなる。

以下に本発明を具体化した実施の形態を説明する。
図２は、本発明の第１の関連技術に係るネットワークゲームシステムの全体の概略構成図である。

本発明のネットワークゲームシステムは、サーバ装置１００とクライアント装置２００，２００ａ〜２００ｆに分けることができる。これらの間は、通常の公衆網あるいは構内網などのネットワーク４０で接続されている。ネットワーク４０の種類は、特に規定しないが、その普及度と利用のしやすさから考えて、以下の説明では、インターネットをベースとして記述する。

サーバ装置１００は通常１台でもよいが、処理能力を考慮し、サブシステム装置ごとあるいは分割された利用者データベース（ＤＢ）ごとに複数台設置してもよい。クライアント装置２００，２００ａ〜２００ｆは、接続している利用者の数だけ存在する。クライアント装置２００，２００ａ〜２００ｆのユーザインタフェースは、ｗｅｂブラウザで実現できる。サーバ装置１００への種々のアクセスは、ｗｅｂブラウザでサーバ装置１００内のホームページを閲覧し、そのホームページ上の操作により可能となる。

サーバ−クライアント間の通信は、ベースのプロトコルとしてＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)上で走るＨＴＴＰ(Hyper Text Transfer Protocol)を使用し、本システムで規定するアプリケーションプロトコルを上位にかぶせることによって実現できる。もちろん、ＴＣＰ／ＩＰ以外のプロトコル、例えばＯＳＩ(Open System Interconnection) を使用することも可能である。

また、クライアント装置間で対局を行う方法には、２つ考えられる。１つは、対局するクライアント装置間で直接通信して対局する方法であり、もう１つは、サーバ装置を経由して対局する方法である。いずれも方法でも対局は可能であるが、本実施の形態では、後者の方法を採用し、サーバ装置を経由して対局を行うものとする。

本システムで規定するアプリケーションプロトコルを表１に示す。

この表には、本実施の形態を実現するために必要な構成（基本構成）で使用するプロトコルが示されており、それは「対局要求」、「対局者選択通知」、「指し手発信」、「指し手通知」の４つである。「対局要求」と「対局者選択通知」とは、必要なパラメタ情報を含めて、クライアント装置２００，２００ａ〜２００ｆからサーバ装置１００に送られ、その要求にサーバ装置１００が応答する。

対局要求は、利用者が対局を希望した時、ホームページ上の所定のボタンをクリックすることによって起動され、サーバ装置１００へ発行される。パラメタ情報として、利用者の識別子ＮとパスワードＰおよびＩＰアドレスＡが、サーバ側に送られる。もちろん、パスワードＰは、あらかじめ決められた暗号方式にて暗号化されていてもよい。対局要求を受け取ったサーバ装置１００は、それを認証し、正当な識別子とパスワードの対であれば、登録されている正当な利用者として判定する。正当な利用者であれば、対局待ちとしてその利用者を登録し、あらかじめ決められた条件で対局者自動選定処理を行う。

対局者選択通知は、サーバ装置１００が、クライアント装置２００，２００ａ〜２００ｆへ発行する。パラメタ情報として、対局者自動選定処理を行って選定した対局相手の情報Ｚｍ、対局相手の強さＲｍ、及びサーバ装置１００で対局を管理するための対局識別子Ｂ若しくは対局相手のＩＰアドレスＡｍを通知する。ここで、通知パラメタとしてのＩＰアドレスＡｍは、サーバ装置１００が対局の仲介を行うときは、利用者に通知する必要がない。逆にサーバが対局仲介を行わないときは、対局識別子Ｂは不要である。

指し手発信は、クライアント装置２００、２００ａ〜２００ｆがサーバ装置１００へ発行するものである。パラメタ情報として、利用者識別子Ｎ、利用者が指定した対局の指し手Ｃ、及び対局識別子Ｂが含まれる。

指し手通知は、サーバ装置１００がクライアント装置２００、２００ａ〜２００ｆへ発行するものである。指し手通知のパラメタ情報は、指し手発信と同じである。
図３は、サーバ装置内の構成を示す図である。ネットワークＯＳ(Operating System)１１０は、ＴＣＰ／ＩＰおよび、表１に示したプロトコルが動作する装置である。これにより、クライアント装置２００，２００ａ〜２００ｆとの通信が実現できる。ネットワークＯＳ１１０の機能は、通常ファームウェアあるいはソフトウェアで実装される。もちろん、物理的な信号の送受信を行うネットワークインタフェース（Ｉ／Ｆ）カードは、サーバ装置にすでに組み込まれているものとする（クライアント装置２００，２００ａ〜２００ｆにおいても同様） 。

認証部１２０は、アクセスしてきた利用者が本システムに登録されている利用者かどうか判定する。これは、クライアント装置２００，２００ａ〜２００ｆからの要求プロトコルのパラメタとして送られてきた利用者識別子ＮｉおよびパスワードＰｉを、利用者ＤＢ１３０のデータと比較（ＣＰ）することで、実現できる。ただし、この機能は、他の認証サービス、例えばＸ．５００（ＩＴＵ−Ｔ(International Telecommunication Union-Telecommunication Sector)が定めたディレクトリに関する国際勧告）を使用した認証サービスを利用してもよい。もし、正当な利用者でなければ、認証部１２０は、エラーメッセージ(Error) をクライアント装置２００，２００ａ〜２００に送り返す。正当な利用者であれば、送られてきた要求プロトコルによって、適切な処理機能部にその要求が伝達される。

利用者ＤＢ１３０は、あらかじめ登録された利用者のデータを格納している。データの内容を、表２に示す。

識別子Ｎは、利用者を唯一識別する符号である。これは、利用者登録時にシステムが自動的に割り振るようにしてもよいし、利用者が決めるようなしくみにしてもよい。名前Ｚ１は、利用者の本名である。住所Ｚ２は、利用者が実際に住んでいる場所を示す。ただし、Ｚ２はオプションであるので、なくてもよい。パスワードＰは、認証の時に必要なデータであり、利用者が付与する。もちろんパスワード変更は後からでも可能である。顔写真Ｚ３は、利用者の写真イメージである。このＺ３もオプションであるので、なくてもよい。アドレスＡは、利用者が使用しているクライアント装置のＩＰアドレスである。通常、インターネットでは、ＩＰアドレスはインターネットアクセスの毎に変わる場合が多い。そのため、このフィールドは利用者が本システムにアクセスするたびに、書き換わる可能性がある。強さＲは、利用者のそのゲームの強さを示す点数である。利用者登録時の申請がベースになっている。状態Ｓは、システムで使用する状態変数であり、０あるいは１の値をとる。それぞれ、０は「対局待ちでない」ことを、１は「対局待ちである」ことを意味している。対局要求時刻Ｗは、利用者が、対局要求をサーバ装置に送った時刻である。これにより、その利用者がどのくらい待っているかの時間がわかる。対局識別子Ｂは、利用者が対局する、あるいは、現在対局している対局の識別子であり、サーバが対局を中継する場合に用いる。この識別子を使用することで、一人の利用者が同時に複数の相手と対局することも可能であり、かつ他の利用者が所望の対局を観戦することも可能となる。対局者Ｍは、利用者が、現在対局している、あるいは、次に対局予定の相手の識別子である。対局者履歴Ｌは、ある過去の一定期間あるいは一定対局数の間に、対局した相手の識別子が入る。

対局者選定部１４０は、利用者Ｎｉから対局要求があった場合、利用者ＤＢ１３０のＮｉの項目にアドレスＡｉおよび状態Ｓ＝１を記録する。利用者から対局要求が送られてくるごとにこの動作をくりかえす。あらかじめ決められた条件でもって自動選定処理部１４１が起動されたら、利用者ＤＢを参照し、対局待ちＳ＝１の全利用者の情報を読み出し、あらかじめ決められたアルゴリズムで対局者を選定する。その結果として、利用者ＤＢ１３０の対局者を選定したすべての利用者Ｎの項目の対局者Ｍと対局者履歴Ｌとに対局相手の識別子を登録し、状態Ｓを０とする。さらに、決定した対局に対する対局識別番号を設定し、各対局者の対局識別子Ｂに登録する。

同時に、対局要求を出力した利用者に対局者選定結果を通知する。この通知は、対局相手の情報Ｚｍとその強さＲｍ、およびこれから行う対局の識別子Ｂをそれぞれのクライアント装置に送ることを意味する。

選定条件保持部１５０には、自動選定処理部１４１を起動させるための選定開始条件があらかじめ設定されている。この関連技術では、以下の４つの選定開始条件が設定可能であるものとする。

第１の条件：対局希望要求を受信する毎に、その対局希望要求者についての対局者選定処理を行う。
第２の条件：あらかじめ指定された時間がきたら、対局者選定処理を行う。

第３の条件：対局待ち利用者数があらかじめ指定された数を超えたら、対局者選定処理を行う。
第４の条件：対局希望要求の受信数があらかじめ指定された数を超えたら、対局者選定処理を行う。

選定条件保持部１５０では、このような選定開始条件の中の少なくとも１つの条件が設定されている。
対局管理部１６０は、一方の対局者の指し手を、その対局相手に中継する処理を行う。この場合、どの対局の指し手かを識別するため、対局の指し手Ｃと共に対局識別子Ｂも同時にやりとりする。どのクライアント装置に送信するかは、利用者ＤＢ１３０から対局識別子で対局者を検索し、その利用者のＩＰアドレスを求めれば特定することができる。

図４は、クライアント装置の構成を示す図である。
ユーザインタフェース２１０は、利用者からの情報入力と利用者への情報表示を受け持つ。ここで、将棋の対局に適用した場合を例にとり、ユーザインタフェースの詳細を説明する。

図５は、ユーザインタフェース２１０の例を示す図である。ユーザインタフェース２１０には、対局希望ボタン２１１が設けられており、この対局希望ボタン２１１がマウスでクリックされると、対局要求部２２０に対局要求指示を伝達する。対局希望ボタン２１１の下には、メッセージ表示部２１２がある。このメッセージ表示部２１２には、ユーザに通知すべき各種メッセージが表示される。例えば、サーバ装置１００からの応答によりエラーメッセージが返ってきた場合には、そのエラーメッセージが表示される。正当な利用者であれば、その旨を表示してもよい。画面中央には、将棋盤表示部２１３があり、対局の様子が表示される。将棋盤表示部２１３の上下には、対局者表示部２１４，２１５がある。上側の対局者表示部２１４には、対局相手の名前と強さが表示される。逆に、下側の対局者表示部２１５には、ユーザ自身の名前と強さが表示される。なお、対局者表示部２１４には、相手のＩＰアドレスを表示することもできる。この場合、表示されたアドレスを基に対局相手との通信状態を確立し、対局を行うことも可能である。将棋盤表示部２１３の右側には、持ち駒表示部２１６，２１７があり、対局相手の持ち駒と自分の持ち駒とがそれぞれ表示される。

図４に戻り、対局要求部２２０は、ユーザインタフェース２１０から対局要求を受け取ると、対局要求プロトコルとして、利用者識別子ＮｉとパスワードＰｉおよびアドレスＡｉを付加し、サーバ装置１００に送る。その応答として、エラー（Error ）メッセージが返ってきたら、それをユーザインタフェース２１０に表示する。また、サーバ装置１００にて対局者選定が完了し、対局相手の情報が通知されたら、それをユーザインタフェース２１０に表示する。対局選定通知で同時に送られてきた対局識別子Ｂは、対局部２３０に伝達され、サーバ装置１００に送る時の対局識別情報となる。

対局部２３０は、ユーザインタフェース２１０から伝達された指し手を、対局要求部２２０から伝達された対局識別子と共にサーバ装置１００に送る。また、対局相手からの指し手情報を待ち、サーバ経由で送られてきた対局識別子Ｂと、送られてきた指し手をユーザインタフェース２１０に表示する。

ネットワークＯＳ２４０は、サーバ装置１００のネットワークＯＳ１１０と同様に、ＴＣＰ／ＩＰ、ＨＴＴＰ及び本システムの各プロトコルが動作する装置である。
以上のような構成のネットワークゲームシステムにおいて、以下のような処理が行われる。本システムの動作を説明するため、サーバ装置１００およびクライアント装置２００でのフローチャートを図６〜図１５に示す。なお、フローチャートを用いた説明においては、図中のステップ番号に沿って説明する。

まず、サーバ装置１００が行う処理について説明する。クライアント装置２００から対局者要求を受け取ったサーバ装置１００では、ネットワークＯＳ１１０および認証部１２０が、受信処理を実施する。

図６は、サーバ装置の受信処理を示すフローチャートである。
［Ｓ１］ネットワークＯＳ１１０は、なんらかの信号の受信がある否かを絶えず判断している。信号の受信が発生したらステップＳ２に進み、信号の受信が発生していない場合は、このステップＳ１の処理を繰り返す。
［Ｓ２］認証部１２０は、信号の発信者が正当な利用者かどうかを認証する。これは利用者ＤＢ１３０での利用者識別子とパスワードの対を照合すれば実現できる。不正な利用者であればステップＳ３に進み、正当な利用者であればステップＳ４に進む。
［Ｓ３］認証部１２０は、受信した信号が不正な利用者からのものであれば、Ｅｒｒｏｒである旨をクライアント装置２００に通知する。その後、ステップＳ１に進み次の受信に備える。
［Ｓ４］認証部１２０は、受信した信号が正当な利用者からのものであれば、受信した要求の種類を判別する。対局者の要求が対局要求であればステップＳ５に進み、要求が指し手であればステップＳ６に進む。
［Ｓ５］対局者選定部１４０が、対局者選定処理を行う。その後、ステップＳ１に進み、次の受信に備える。この処理の詳細は後述する。
［Ｓ６］対局管理部１６０が、対局管理処理を行う。その後、ステップＳ１に進み次の受信に備える。この処理の詳細は後述する。

ここで、対局の指し手を中継する場合、単発の情報通信でなく、複数の情報のやり取りとなるため、通常ＴＣＰ／ＩＰでは、クライアント装置２００とサーバ装置１００間で、例えば電報ではなく、電話のような論理的なコネクションを確立し、そのコネクション上で情報のやり取りを行う。これを利用すれば、対局の情報交換の時には認証の処理は省いてもよい。

ここで、選定処理の詳細を説明する。なお、以下の選定サブルーチン、選定処理、選定ルーチンは、いずれも対局者選定部１４０が実施する処理である。
まず、対局要求を受け取った対局者選定部１４０は、選定条件保持部１５０の内容に応じて以下のような処理を行う。

図７は、選定サブルーチンのフローチャートである。これは対局要求が発生したとき行われる処理である。
［Ｓ１１］選定開始条件に第１の条件が含まれているか否かを判断する。第１の条件が含まれている場合にはステップＳ１２に進み、含まれていない場合にはステップＳ１３に進む。
［Ｓ１２］第１の条件が設定されている場合（第１の条件のみが設定されている場合と、条件の組み合わせで第１の条件が含まれている場合とがある）、処理内容を「第１の選定処理」として自動選定処理部１４１を起動する。第１の選定処理の詳細は、図８に示す。
［Ｓ１３］第１の条件が設定されていない場合、要求してきた利用者Ｎｉに待機の応答を行う。
［Ｓ１４］利用者ＤＢ１３０の利用者Ｎｉの状態を対局待ちにセットし（Ｓ←１）、対局要求時刻Ｗに現在の時刻をセットする。

なお、応答を行うときのパケット化は、ネットワークＯＳ１１０が行う機能である( 以下パケット化は全てネットワークＯＳ１１０で実施) 。
図８は、第１の選定処理のフローチャートである。これは、第１の選定条件で対局要求が発生したときに行われる。
［Ｓ２１］利用者ＤＢ１３０から対局待ちの利用者情報を読み出す。
［Ｓ２２］「選定ルーチンａ」を呼び出し、対局要求した利用者の対局相手を探す。選定ルーチンａからは、相手が見つかったか否かの情報が変数ｐによって返される。相手が見つかった場合には変数ｐの値がtrueであり、相手が見つからなかった場合には変数ｐの値はfalse である。
［Ｓ２３］変数ｐの値に基づいて、対局相手が見つかったか否かを判断する。対局相手が見つかった場合にはステップＳ２４に進み、見つからなかった場合にはステップＳ２６に進む。
［Ｓ２４］対局相手が見つかった場合は( 選定ルーチンａでの変数ｐがtrueの場合) 、対局する双方のクライアント装置に対局識別子Ｂと対局相手の情報を応答および通知する( ここで応答とは要求に対しての返事であり、通知は待機している利用者へイベントとして連絡することである) 。
［Ｓ２５］対局する両者の利用者ＤＢ１３０を更新する。つまり状態Ｓを０にセットする。
［Ｓ２６］一方、相手が見つからなかった場合、対局要求を出力したクライアント装置２００に待機の応答をする。
［Ｓ２７］同時に、この利用者の利用者ＤＢ１３０内の状態Ｓを１にセットする。

以上が、クライアント装置２００からの対局要求の入力を契機として行われる処理である。
一方、選定条件保持部１５０に、前述の第２の選定開始条件から第４の選定開始条件のいずれかが設定された時点から、対局者選定部１４０は以下の第２の選定処理を継続的に行う。

図９は、第２の選定処理のフローチャートである。これは、第２〜第４の選定開始条件のどれか１つでも設定されていれば、常に動いている処理である。
［Ｓ３１］第２〜第４の選定開始条件中の設定されている条件のいずれか１つが満たされているか否かを判断する。選定開始条件の１つが満たされていればステップＳ３２に進み、満たされていなければこのステップを繰り返す。
［Ｓ３２］選定開始条件の中のすくなくとも１つの条件が満たされたら、利用者ＤＢ１３０から対局待ちの利用者情報を読み出す。
［Ｓ３３］「選定ルーチンｂ」を呼び出し対局の組み合わせを行う。この処理の詳細は、図１２に示す。
［Ｓ３４］対局相手の選定が完了した利用者のクライアント装置２００に、対局識別子Ｂ、対局相手情報Ｚｍを通知する。
［Ｓ３５］利用者ＤＢ１３０内のこれらの利用者の状態Ｓを１にセットする。

以上の処理が繰り返し行われる。
このように、選定開始条件のいずれか１つが満たされた時点で対局者選定処理が開始され、対局相手が決定した利用者に対して、対局識別子Ｂと対局相手情報Ｚｍとが通知される。

また、サーバ装置１００に対して、クライアント装置２００から指し手情報が送られてきたら、以下の対局管理処理を行う。
図１０は、対局管理処理のフローチャートである。これは指し手Ｃがクライアント装置２００から送られてきたときに、対局管理部１６０が行う処理である。
［Ｓ４１］指し手Ｃと同時に送られてきた対局識別子Ｂをキーとして、対応する対局相手のアドレスを利用者ＤＢ１３０から検索する。
［Ｓ４２］アドレスに該当するクライアント装置に、クライアント装置２００から送られてきた指し手Ｃを対局識別子Ｂと共に送信する。

以上が、サーバ装置１００の全体的な処理である。以下に、選定ルーチンの詳細を説明する。
選定ルーチンはいくつか方法が考えられる。ここでは、もっとも簡単な比較による選定方法による例を示す。なお、選定ルーチンは、全て自動選定処理部１４１が行う処理である。

図１１は、第１の選定処理で呼び出される選定ルーチンａのフローチャートである。
［Ｓ５１］基準値Ｒｘと変数ｐを初期化（設定）する。ここで、基準値Ｒｘは、対局者として選択可能な強さの差の基準を示す値であり、両利用者の強さの差がこの範囲内に入れば、対局者として選定することにする。変数ｐは、対局相手が見つかったか否かを示す論理変数であり、対局相手が見つかった場合には「true」、見つからなければ「false 」となる。

この処理で使用している変数を、表３のテーブルを用いて説明する。

表３のテーブルにおいて、項目番号は「１」から振られた番号であり、対局待ちの利用者数Ｕまで存在する。以下この項目番号をサフィックスとして使用する。つまり項目番号「２」の利用者識別子は「Ｎ２」である。識別子Ｎ、強さＲ、対局者Ｍ、対局者履歴Ｌは利用者ＤＢ１３０で使用しているものと同じ意味である。なお、処理ルーチンａを実行している段階では、対局要求を出力した利用者の状態Ｓは０のままである。また、Ｎｉ、Ｒｉ、Ｍｉ、Ｌｉは、対局要求を出力した利用者であり、ここでは固定である。
［Ｓ５２］項目番号「ｋ」に０をセットする。
［Ｓ５３］項目番号「ｋ」の値に１を加算する。
［Ｓ５４］識別子「Ｎｋ」が、対局要求を出力した利用者の対局者履歴「Ｌｉ」に含まれていないことを確認する。含まれていればステップＳ５３に進み、含まれていなければステップＳ５５に進む。
［Ｓ５５］対局要求を出力した利用者の強さ「Ｒｉ」と、識別子「Ｎｋ」の利用者の強さ「Ｒｋ」との差が、基準値「Ｒｘ」より小さいか否かを判断する。基準値「Ｒｘ」より小さければステップＳ５６に進み、そうでなければステップＳ５７に進む。
［Ｓ５６］識別子「Ｎｋ」の利用者を、対局要求を出力した利用者の対局相手として決定し、利用者ＤＢ１３０の内容を更新する。具体的には、対局要求を出力した利用者（識別子「Ｎｉ」）の対局者「Ｍｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者「Ｍｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。さらに、項目番号「ｉ」の対局者履歴「Ｌｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者履歴「Ｌｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。また、対局者が見つかったため、論理変数「ｐ」を「true」に設定する。これらの設定が完了したら、処理を終了する。
［Ｓ５７］項目番号「ｋ」が、対局待ちの利用者数Ｕ以上になったか否かを判断する。Ｕ以上であればステップＳ５８に進み、そうでなければステップＳ５３に進む。
［Ｓ５８］対局相手が見つからなかったため、論理変数「ｐ」を「false 」に設定し、処理を終了する。

このような処理の結果、強さの差がＲｘ以内であり、かつあらかじめ定められた期間あるいは対局数内において対局していない利用者が、対局相手として選定される。
図１２は、第２の選定処理で呼び出される選定ルーチンｂのフローチャートである。なお、この処理においても、前述の表３に示したような変数を用いる。
［Ｓ６１］集合Ｓと集合Ｐを初期化（空集合）し、基準値Ｒｘを初期化（設定）する。集合Ｓは処理が終了した項目番号の集合であり、集合Ｐは処理したが相手が見つからなかった項目番号の集合である。
［Ｓ６２］選択される項目番号の値「ｉ」を０に初期化する。
［Ｓ６３］「ｉ」の値に１を加算する。
［Ｓ６４］「ｉ」が、集合Ｓに含まれているか否かを判断する。集合Ｓに含まれていれば、その項目番号に対応する利用者の対局相手は既に決定しているため、ステップＳ６３に戻る。集合Ｓに含まれていなければステップＳ６５に進む。
［Ｓ６５］比較対照となる項目番号の値「ｋ」を０に初期化する。
［Ｓ６６］「ｋ」の値に１を加算する。
［Ｓ６７］項目番号「ｋ」の利用者が、対局相手としての基本的条件を満たしているかどうかを判断する。基本的条件としては、まず、自分自身を除く（ｉ≠ｋ）。そして、すでに処理した項目番号（集合Ｓにあるもの）、及び予め定められた期間あるいは対局数内ですでに対局したことのある利用者（集合Ｌｉにあるもの）は選定の対象外とする。これらの条件を満たしていればステップＳ６８に進む。条件を満たしていない場合にはステップＳ６６に進む。
［Ｓ６８］項目番号「ｉ」の利用者と項目番号「ｋ」の利用者との強さの差がＲｘより大きいか否かを判断する（｜Ｒｉ−Ｒｋ｜＞Ｒｘ）。強さの差がＲｘ以下であればステップＳ６９に進み、強さの差がＲｘより大きければステップＳ７０に進む。
［Ｓ６９］項目番号「ｉ」と項目番号「ｋ」とを、処理済を示す集合Ｓに含める。また、項目番号「ｉ」の対局者「Ｍｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者「Ｍｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。さらに、項目番号「ｉ」の対局者履歴「Ｌｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者履歴「Ｌｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。これらの設定が終了したらステップＳ７２に進む。
［Ｓ７０］比較されている項目番号「ｋ」が、対局待ちの利用者を示す項目番号の最大値「Ｕ」以上であるか否かを判断する。「ｋ」が「Ｕ」以上であればステップＳ７１に進み、そうでなければステップＳ６６に戻る。
［Ｓ７１］集合Ｐに項目番号「ｉ」を含める。すなわち、項目番号「ｉ」の利用者の適当な対局者が見つからなかったことになる。
［Ｓ７２］選択されている項目番号「ｉ」が、項目番号の最大値「Ｕ」以上であるか否かを判断する。「ｉ」が「Ｕ」以上であれば処理を終了し、そうでなければステップＳ６３に戻る。

これにより、項目番号「１」から「Ｕ」まで各利用者ごとに、強さの差がＲｘ以内の利用者が選定される。なお、以上のことを利用者のならび順序を入れ替え、｜Ｒｉ−Ｒｋ｜の平均が最小の組み合わせを選んでもよい。また、集合Ｐが空となるように、Ｒｘを大きくしていってもよい。

以上が、サーバ装置１００で行われる処理である。次にクライアント装置での動作を説明する。
まず、ユーザインタフェースの処理機能を説明する。

図１３は、ユーザインタフェースが行う処理のフローチャートである。この処理はすべてユーザインタフェース２１０によって行われる。
［Ｓ１０１］ユーザインタフェース２１０が、マウスなどの入力装置からの入力の有無を監視する。図５に示したように、利用者が入力できる項目として、対局希望ボタン２１１がひとつと、指し手の操作盤（将棋盤表示部２１３と持ち駒表示部２１６、２１７との領域を指す）とがあり、これらを監視すると共に、対局要求部２２０と対局部２３０からの要求を監視することになる。
［Ｓ１０２］入力装置からの入力か否かを判断する。入力装置からの入力であればステップＳ１０３に進み、そうでなければステップＳ１０６に進む。
［Ｓ１０３］入力が対局要求か否かを判断する。対局希望ボタン２１１がマウスによってクリックされ、対局要求が入力されたのであればステップＳ１０４に進み、指し手操作盤が操作され、差し手が入力されたのであればステップＳ１０５に進む。
［Ｓ１０４］対局要求部２２０に対し、対局要求を発行するように指示をする。これにより、対局要求部２２０では、対局要求処理が起動される。この処理の後、ステップＳ１０１に進む。
［Ｓ１０５］指し手を対局部２３０に伝達し、ステップＳ１０１に進む。
［Ｓ１０６］対局要求部２２０からの入力か否かを判断する。対局要求部２２０からの入力であればステップＳ１０７に進み、そうでなければ対局部２３０からの入力であると判断し、ステップＳ１０８に進む。
［Ｓ１０７］対局要求部２２０から入力された対局相手などの情報を表示する。対局相手の場合には、対局相手の情報Ｚｎと対局相手の強さＲｎとを、対局者表示部２１４（図５に示す）に表示する。また、待機すべき旨の表示要求、もしくはエラーが発生した旨の表示要求の場合には、その内容をメッセージ表示部２１２（図５に示す）に表示する。その後、ステップＳ１０１に進む。
［Ｓ１０８］対局部２３０から入力された指し手に従って、指し手の操作盤上の駒の配置を更新し、ステップＳ１０１に進む。

次に、対局要求部が実行する処理を説明する。
図１４は、対局要求処理のフローチャートである。この処理は、ユーザインタフェース２１０から対局要求部２２０へ対局要求が出力された際に、対局要求部２２０が実行する処理である。
［Ｓ１１１］対局要求プロトコルを使って、利用者識別子Ｎｉに、パスワードＰｉ、アドレスＡｉを含めてサーバ装置１００に送信する。ここでアドレスは、クライアント装置２００にあらかじめ設定されているので、ユーザが入力しなくても自動的に検出し、プロトコル上にのせることが可能である。
［Ｓ１１２］対局要求の応答の有無を判断する。対局要求に対するサーバ装置１００からの応答があればステップＳ１１３に進み、応答がなければこのステップＳ１１２の処理を繰り返す。
［Ｓ１１３］応答がエラーなしで正常に返されたか否かを判断する。エラーがあったらステップＳ１１７に進み、エラーがなければステップＳ１１４に進む。
［Ｓ１１４］選定結果を受信したか否かを判断する。選定結果を受信したのであればステップＳ１１５に進み、そうでなければステップＳ１１６に進む。
［Ｓ１１５］選定結果（対局相手の情報Ｚｎと対局相手の強さＲｎ）をユーザインタフェース２１０に伝達し表示させると共に、対局部２３０に対局識別子Ｂを伝達し、処理を終了する。
［Ｓ１１６］待機すべき旨の情報をユーザインタフェース２１０に伝達して表示させ、ステップＳ１１４に進む。
［Ｓ１１７］エラーが発生した旨の情報をユーザインタフェース２１０に伝達して表示させ、処理を終了する。

次に、対局部２３０が実行する処理を説明する。
図１５は、対局処理のフローチャートを示す図である。これは、対局が開始されたら、対局部２３０にて常時実行されている処理である。
［Ｓ１２１］ユーザインタフェース２１０あるいはサーバ装置１００からの入力の有無を判断する。入力があればステップＳ１２２に進み、入力がなければこの処理を繰り返すことで、入力があるまで待機する。
［Ｓ１２２］入力がユーザインタフェース２１０からのものであるか、サーバ装置１００からのものであるかを判断する。ユーザインタフェース２１０からの入力であればステップＳ１２３に進み、サーバ装置１００からの入力であればステップＳ１２４に進む。
［Ｓ１２３］ユーザインタフェース２１０からの入力であれば、対局識別子Ｂ、指し手Ｃ、及び利用者識別子Ｎｉをサーバ装置１００へ送信する。
［Ｓ１２４］サーバ装置１００からの入力であれば、受信した指し手Ｃを対局識別子Ｂと共にユーザインタフェース２１０へ伝達する。

以上がクライアント装置２００での処理である。
このようにして、対局を希望する利用者の対局相手をサーバ装置１００が自動的に決定し、利用者の使用しているクライアント装置へ対局相手に関する情報を通知することができる。その結果、利用者自身が、対局相手を見つけるという作業が不要になる。

また、サーバ装置１００は、選定開始条件を満たした時点で対局者選定処理を行うため、適当な選定開始条件をあらかじめ設定しておけば、対局相手の選択範囲が広がると共に、利用者が絶えず選定結果がでたかどうかモニタする必要がなくなる。

さらに、サーバ装置１００が対局の指し手を中継するため、対局者間で通信回線を接続する必要がない。
次に第２の関連技術について説明する。第２の関連技術は、第１の関連技術で示した基本構成に種々の応用技術を付加したものである。

応用として、入退場、強さ評価、各種情報表示があり、さらに、自動選定を強化した、以下の拡張機能を持つ。
１）第５の選定開始条件であり、あらかじめ決められた時間内に対局者が決まらなかった利用者に対して、別の対局者ＤＢより対局者を選定する（以後、第１の拡張機能という）。
２）待ち時間の長い対局待ち利用者を優先して選定対象とする（以後、第２の拡張機能という）。
３）対局者の強さを示す点数の増減の微分値により、対局相手の選定範囲を決定する（以後、第３の拡張機能という）。
４）対局待ちの利用者の対局待ちの時間に応じて、対局相手の選定範囲を変化させる（以後、第４の拡張機能という）。

ここで、第２の関連技術で使用するサーバ−クライアント間のプロトコルを表４に示す。

この関連技術ではプロトコルを、「基本」と「応用」とに分類している。第１の関連技術でも使用したプロトコルが「基本」であり、本関連技術を実現するために新たに規定したプロトコルが「応用」である。応用のプロトコルは、基本以外に４種類のプロトコルがある。

「入場」は、利用者が、本システムに入るために最初にサーバ装置へ発行するプロトコルである。サーバ装置は、結果として本システムで提供しているサービスメニューを返す。これにより、正当な利用者のみが本システムのサービスにアクセスできる。

「退場」は、利用者が本システムから抜けるためのプロトコルである。入場プロトコルと組み合わせ、入場から退場までの間の時間帯においてのみ利用者がアクセスできるようにすることで、システムのセキュリティを高めることが可能である。

「終了」は、対局が終わったことを示すプロトコルである。これによって、サーバ側で、この対局の結果をすぐに対局者の強さ計算に使用することが可能となる。
「表示」は、利用者ＤＢの情報を表示要求できるプロトコルである。

なお、パラメタの意味は、表１に示したものと同じである。
図１６は、本発明の第２の関連技術のサーバ装置の構成を示す図である。このサーバ装置３００は、クライアント装置４００とネットワークを介して接続されている。

ネットワークＯＳ３１０は、上記表４のすべてのプロトコルを認識できるものである。また、認証部３２０は、すでに基本構成（図３に示した構成) で説明したものと同じである。

入場者受付部３３０は、クライアント装置４００からの入場プロトコルを受け、要求された利用者Ｎｉの状態を初期化（Ｓ＝０）し、そのクライアント装置４００に本システムのサービスメニューを返す。第１の関連技術に示した基本構成では、不正な利用者でもアクセスだけは可能であったが、この機能を使うことにより、正当な利用者だけがアクセスすることを許される。その結果、サーバ側の負荷を減らすことが可能となる。

退場者受付部３４０は、上記入場者受付部３３０と対で利用される。退場要求がきたら、その利用者の状態を初期化（Ｓ＝０）し、サービスメニューを閉じるようにする。
対局者選定部３５０は、基本構成の機能のほかに、利用者ＤＢ３６１の中からでは対局相手が見つからなかった利用者に対して、予備対局者ＤＢ３６２を使用し対局者を見つける機能が含まれる。

利用者ＤＢ３６１は、第１の関連技術と同様に、あらかじめ登録された利用者のデータを格納している。データの内容は、表２に示す通りである。
予備対局者ＤＢ３６２は、あらかじめ登録され、対局者再要求にそなえて待機している利用者のＤＢである。予備対局者ＤＢ３６２に格納されているデータの内容は、利用者ＤＢ３６１と同様である。

強さ評価部３７０は、対局が終了したとき、対局の結果および対局者同士の強さから、あらかじめ決められたルールにより、各対局者の強さを計算し、利用者ＤＢ３６１の対局した各利用者の強さを書き換える。まず、終了を発行した利用者Ｎｉの対局者Ｍｉを利用者ＤＢ３６１から求め、利用者と対局者のそれぞれの強さを利用者ＤＢ３６１から読み込んでくる。これらを元に、強さを再計算し、利用者ＤＢ３６１にそれぞれ書き込む。

強さを計算するルールの一例として、次のような将棋での強さ判定方法として用いられているレーティング方式がある。このレーティング方式では、次の式で得失点を求めそれを勝った方、負けた方の元の点数に加算、減算する。
（１）点数が高い方が勝った場合、
得失点＝１６−（持点差×４％）
（２）点数が低い方が勝った場合、
得失点＝１６＋（持点差×４％）
なお、点数が高い方が勝った場合において、持点差が４００点を超えていると得失点が負の数になってしまうが、その場合、強さは変動させない。ただし、対局者の自動選定処理において、強さの差が一定の閾値以上の場合には対局相手として選ばれないため、その閾値を４００以下に設定しておけば、持点差が４００点を超えることはない。

表示情報提供部３８０は、利用者ＤＢ３６１の情報をクライアント装置４００に応答する機能を有している。すなわちクライアント装置４００からの表示要求項目をうけ、それに対応するものを応答する。ただし、パスワードは、応答できない。

選定条件保持部３９０は、第１の関連技術で示した選定開始条件（第１の条件〜第４の条件）に加え、本関連技術の第１の拡張機能である第５の選定開始条件が設定可能である。

対局管理部３００ａは、基本構成（図３の対局管理部１６０）と同様の機能を有する。
次に上記サーバ装置３００に対応するクライアント装置の構成を示す。
図１７は、第２の関連技術のクライアント装置の構成を示す図である。

ネットワークＯＳ４１０は、前述の表４のすべてのプロトコルを送受信できるものである。
ユーザインタフェース４２０は、利用者からの情報入力と利用者への情報表示を行う。このユーザインタフェース４２０は、第１の関連技術におけるユーザインタフェースに対して、機能を拡張したものである。

図１８は、拡張されたユーザインタフェース４２０の例を示す図である。なお、図中の対局希望ボタン４２１、メッセージ表示部４２２、将棋盤表示部４２３、対局者表示部４２４，４２５、及び持ち駒表示部４２６，４２７に関しては、図５に示した第１の関連技術のユーザインタフェース２１０の同名の構成要素と同じものである。

本関連技術で追加された入力スイッチとして、投了ボタン４２０ａ、退場ボタン４２０ｂがある。投了ボタン４２０ａは、負けを認めた際にクリックすべきボタンであり、このボタンがクリックされることにより終了指令が出力される。退場ボタン４２０ｂは、サーバ装置３００のサービスの利用を終了する際にクリックすべきボタンであり、このボタンがクリックされることにより退場指令が出力される。

表示機能としては、残り時間表示部４２０ｃ，４２０ｄが追加されている。この残り時間表示部４２０ｃ，４２０ｄは、制限時間が設けられた対局における、それぞれの対局者の持ち時間の残量を表示している。

なお、図１８のユーザインタフェースは、ユーザがすでに入場を行った後の画面を示している。入場する前は、図示していない入場ボタンが設けられている。その入場ボタンがクリックされると、入場要求が出力される。

図１７に戻り、入場要求部４３０は、ユーザインタフェース４２０からの入場要求を、サーバ装置３００に送信し、その応答をユーザインタフェース４２０に表示する。サーバ装置３００に送信する入場要求には、利用者識別子ＮｉおよびパスワードＰｉを含める。

対局要求部４４０は、基本的に第１の関連技術の対局要求部２２０（図４に示す）と同じ機能を有している。
終了要求部４５０は、ユーザインタフェース４２０から投了情報（負けの意思表示）が伝達されたら、終了プロトコルでもってサーバ装置３００に、それを伝達する。そして、サーバ装置３００からの応答を待ち、正常に処理されたら、ユーザインタフェース４２０に対局終了のメッセージを表示する。

上記投了情報は、もちろん対局部４８０にも伝えられるので、対局相手のそれを認識できる。
退場要求部４６０は、本システムから利用者が抜けるための処理を行う。退場のプロトコルをサーバ装置３００に送信し、応答がきたら処理完了のメッセージをユーザインタフェース４２０に表示する。

表示要求部４７０は、利用者が知りたい情報項目を選択し、その情報をサーバ装置から読み出し表示する。
対局部４８０は、第１の関連技術に示した対局部２３０（図４に示す）と同様の機能を有する。

画像組み込み部４９０は、対局部４８０およびカメラ５０と組み合わせ、指し手を対局相手に送信するときに、指し手を指した瞬間の自分の静止画を同時に送信する。また、同様の画像を受け取った側は、指し手と共にその静止画を画面に表示する。こうすることで、対局の臨場感を増すことができる。

以下、本システムの動作を基本機能のフローチャートと併せて説明する。なお、本システムのサーバ装置３００とクライアント装置４００との特徴的な処理機能のフローチャートを図１９〜図２９に示す。

図１９は、サーバ装置での受信処理を示すフローチャートである。
［Ｓ２０１］ネットワークＯＳ３１０は、受信の有無を判断し、各種要求を受信すればステップＳ２０２に進み、受信しなければこの処理を繰り返す。
［Ｓ２０２］認証部３２０は、なんらかの受信が発生したら、それが正当な利用者かどうかを認証する。正当な利用者であればステップＳ２０４に進み、不正な利用者であればステップＳ２０３に進む。
［Ｓ２０３］受信した要求の認証に失敗した場合には、認証部３２０は、エラーである旨のメッセージをクライアント装置４００に通知する。
［Ｓ２０４］認証部３２０は、正当な利用者であれば、受信した要求の種類を判別し、それぞれの処理を実行させる。
［Ｓ２０５］入場要求の場合には、入場者受付部３３０が入場受付処理を実行する（詳細は図２０に示す）。
［Ｓ２０６］終了要求の場合には、強さ評価部３７０が終了処理を実行する（詳細は図２１に示す）。
［Ｓ２０７］退場要求の場合には、退場者受付部３４０が退場処理を実行する（詳細は図２２に示す）。
［Ｓ２０８］対局要求の場合には、対局者選定部３５０が選定処理を実行する。この処理の詳細は、図７〜図９に示した第１の関連技術の処理と同様である。ただし、図８の第１の選定処理のステップＳ２２で行われる処理の内容が異なる（選定ルーチンａに変えて、選定ルーチンａ' が実行される）。
［Ｓ２０９］指し手要求の場合には、対局管理部３００ａが対局処理を行う。詳細は図１０に示した第１の関連技術の処理と同様である。
［Ｓ２１０］表示要求の場合には、表示情報提供部３８０が要求されたデータを利用者ＤＢ３６１から取得する。

ステップＳ２０３、ステップＳ２０５〜Ｓ２１０の処理が終了したら、それぞれの処理を行った装置が、要求したクライアント装置に処理の結果を応答する。なお、実際のパケット化は、ネットワークＯＳ３１０が行う。その後ステップＳ２０１に戻り、次の受信に備える。

図２０は、入場受付サブルーチンのフローチャートである。これは、入場要求が発生したときに、入場者受付部３３０で行われる処理である。
［Ｓ２２１］要求してきた利用者Ｎｉの状態を初期化する（Ｓ←０）。
［Ｓ２２２］本システムのサービスメニューを利用者Ｎｉに応答する。サービスメニューは、具体的には、対局要求と退場とがある。

図２１は、終了サブルーチンのフローチャートである。これは、終了要求が発生したときに、強さ評価部３７０で行われる処理である。
［Ｓ２３１］終了要求した利用者Ｎｉとその対局者Ｍｉの強さを、勝敗の結果と元の強さをもとに計算する。この計算方法は、前述の通りである。
［Ｓ２３２］計算した結果を利用者ＤＢ３６１へ記録する。そして、利用者Ｎｉへ処理完了を応答し、この処理を終了させる。

図２２は、退場サブルーチンのフローチャートである。これは、退場要求が発生したときに、退場者受付部３４０で行われる。
［Ｓ２４１］退場要求した利用者の状態を変更する（Ｓ←０）。
［Ｓ２４２］利用者Ｎｉへ退場了解を応答し、処理を完了させる。

次に、第１の拡張機能を含む選定処理のフローチャートを説明し、つぎに第２〜第４の拡張機能を含めたフローチャートを説明する。
ここで、第１の拡張機能を実現した選定処理を「第３の選定処理」とする。

図２３は、第３の選定処理のフローチャートである。これは、第５の選定開始条件が設定された場合に、対局者選定部３５０で常に行われている処理である。
［Ｓ２５１］対局待ち利用者の対局待ち時間が、あらかじめ決められた待ち時間以上になったか否かを判断する。待ち時間を超えていなければこのステップを繰り返し、待ち時間を超えていればステップＳ２５２に進む。
［Ｓ２５２］利用者ＤＢ３６１から対局待ち利用者情報を読み出し、予備対局者ＤＢ３６２から予備対局者の情報を読み出す。
［Ｓ２５３］選定ルーチンｃを読み出す。
［Ｓ２５４］待ち時間が超過した利用者に対し対局相手が決まれば、それをそのクライアント装置に通知する。
［Ｓ２５５］最後に利用者ＤＢ３６１の更新を行う。

なお、このフローチャートでは、予備対局者ＤＢ３６２には、必ず十分な予備対局者が登録されていることを前提としている。
図２４は、第３の選定処理で呼び出される選定ルーチンｃのフローチャートである。
［Ｓ２６１］基準値Ｒｘを初期化（設定）する。Ｒｘは強さの差の基準値である。
［Ｓ２６２］項目番号「ｋ」に０をセットする。この処理でしようしている変数ｋは、１から振られた番号であり、予備対局者ＤＢ３６２の登録者数Ｖまで存在する。Ｎ、Ｒ、Ｍ、Ｌは利用者ＤＢ３６１で使用している記号と同一の意味を持つ。Ｎｉ、Ｒｉ、Ｍｉ、Ｌｉは、対局待ち時間が超過した利用者であり、ここでは固定である。
［Ｓ２６３］項目番号「ｋ」の値に１を加算する。
［Ｓ２６４］識別子「Ｎｋ」が、対局要求を出力した利用者の対局者履歴「Ｌｉ」に含まれていないことを確認する。含まれていればステップＳ２６３に進み、含まれていなければステップＳ２６５に進む。
［Ｓ２６５］対局要求を出力した利用者の強さ「Ｒｉ」と、識別子「Ｎｋ」の利用者の強さ「Ｒｋ」との差が、強さの基準値「Ｒｘ」より大きいか否かを判断する。基準値「Ｒｘ」より大きければステップＳ２６７に進み、そうでなければステップＳ２６６に進む。
［Ｓ２６６］識別子「Ｎｋ」の利用者を、対局要求を出力した利用者の対局相手として決定し、利用者ＤＢ３６１と予備対局者ＤＢ３６２との内容を更新する。具体的には、項目番号「ｉ」の対局者「Ｍｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者「Ｍｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。さらに、項目番号「ｉ」の対局者履歴「Ｌｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者履歴「Ｌｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。これらの設定が完了したら、処理を終了する。
［Ｓ２６７］項目番号「ｋ」が、予備対局者ＤＢ３６２の登録者数Ｖ以上になったか否かを判断する。Ｖ以上であればステップＳ２６８に進み、そうでなければステップＳ２６３に進む。
［Ｓ２６８］Ｒｘの値にα（予め設定された、Ｒｘに比べて小さな値）を加え、新たなＲｘの値として、ステップＳ２６２に進む。

このように、予備対局者ＤＢ３６２の中から、利用者Ｎｉと強さの差がＲｘ以内の予備対局者を見つけ出し、もし、見つからなかった場合、選定範囲Ｒｘを徐々に大きくしていくことで、必ず対局相手が見つかるようにしている。

次に、第２の拡張機能から第４の拡張機能を包含する選定処理を説明する。これは、第１の選定処理（図８に示す）を実施したとき、ステップＳ２２において、選定ルーチンａのかわりに、選定ルーチンａ' を呼び出すことで実施される。

図２５は、第１の選定処理で呼び出される選定ルーチンａ' のフローチャートである。
［Ｓ２７１］基準値Ｒｘと変数ｐを初期化（設定）する。ここで、Ｒｘは強さの差の基準値であり、変数ｐは、対局相手が見つかったか否かを示す論理変数である。また、以下のＮｉ、Ｒｉ、Ｍｉ、Ｌｉは、対局要求を出力した利用者であり、ここでは固定である。
［Ｓ２７２］選定対象テーブル（項目番号１からＵ）を待ち時間の長い順にソートする。
［Ｓ２７３］最近の対戦成績によって、選定しようとしている利用者の強さＲｉを補正する。例えばＲｉが増加の傾向であれば、現在のＲｉをΔＲｉ分だけ増加させる。ここでΔＲｉは、Ｒｉの増減率を示す値である。

ただし、実際のＤＢ中のＲは変更せず、この選定ルーチンａ' 内だけ変更させて選定する。
［Ｓ２７４］項目番号「ｋ」に０をセットする。
［Ｓ２７５］項目番号「ｋ」の値に１を加算する。
［Ｓ２７６］識別子「Ｎｋ」が、対局要求を出力した利用者の対局者履歴「Ｌｉ」に含まれていないことを確認する。含まれていればステップＳ２７５に進み、含まれていなければステップＳ２７７に進む。
［Ｓ２７７］最近の対戦成績によって、選定されようとしている利用者の強さＲｋを補正する。その補正方法は、ステップＳ２７３でＲｉに対して行ったのと同じである。
［Ｓ２７８］待ち時間の長さに応じてそれぞれの強さの差の基準値Ｒｘを変化させる。Ｎｉの待ち時間に応じて変化させたものをＲｘｉ、Ｎｋの待ち時間に応じて変化させたものをＲｘｋとすると、選定時にはその小さい方を選択し、それを選定の強さの差の基準値Ｒｘとする。
［Ｓ２７９］対局要求を出力した利用者の強さ「Ｒｉ」と、識別子「Ｎｋ」の利用者の強さ「Ｒｋ」との差が、強さの基準値「Ｒｘ」より小さいか否かを判断する。基準値「Ｒｘ」より小さければステップＳ２８０に進み、そうでなければステップＳ２８１に進む。
［Ｓ２８０］識別子「Ｎｋ」の利用者を、対局要求を出力した利用者の対局相手として決定し、利用者ＤＢ１３０の内容を更新する。具体的には、項目番号「ｉ」の対局者「Ｍｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者「Ｍｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。さらに、項目番号「ｉ」の対局者履歴「Ｌｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者履歴「Ｌｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。また、対局者が見つかったため、論理変数「ｐ」を「true」に設定する。これらの設定が完了したら、処理を終了する。
［Ｓ２８１］項目番号「ｋ」が、対局待ちの利用者数Ｕ以上になったか否かを判断する。Ｕ以上であればステップＳ２８２に進み、そうでなければステップＳ２７５に進む。
［Ｓ２８２］対局相手が見つからなかったため、論理変数「ｐ」を「false 」に設定し、処理を終了する。

次にクライアント装置４００での動作を説明する。
図２６は、クライアントでのユーザ入力処理のフローチャートである。これは、ユーザインタフェース４２０が行う処理である。
［Ｓ３０１］ユーザからの入力の有無を監視する。入力があった場合には、ステップＳ３０２に進み、入力が無い場合には監視処理を続行する。
［Ｓ３０２］ユーザ入力があった場合、その要求の種類を判別し、それに応じて処理を実行する装置に伝達する。
［Ｓ３０３］入場要求の場合には、入場要求部４３０が入場処理を行う（詳細は図２７に示す）。
［Ｓ３０４］投了要求の場合には、終了要求部４５０が終了処理を行う（詳細は図２８に示す）。
［Ｓ３０５］退場要求の場合には、退場要求部４６０が退場処理を行う（詳細は図２９に示す）。
［Ｓ３０６］対局要求の場合には、対局要求部４４０が対局要求処理を行う（詳細は図１４に示した第１の関連技術の処理と同様である）。
［Ｓ３０７］指し手の場合、対局部４８０へ指し手を伝達する。
［Ｓ３０８］表示要求の場合には、表示要求部４７０がサーバ装置３００から必要なデータを取得し、ユーザインタフェース４２０の画面に表示する。

以上のステップＳ３０３〜Ｓ３０８のいずれかの処理が終了したら、ステップＳ３０１に戻る。
図２７は、入場サブルーチンのフローチャートである。この処理は、入場要求部４３０が行う処理である。
［Ｓ３１１］入場要求プロトコルを使用しパラメタとしてＮｉとＰｉをサーバ装置３００に送信する。
［Ｓ３１２］サーバ装置３００からのその応答を待つ。
［Ｓ３１３］サーバ装置３００からの応答結果を表示する。

図２８は、終了サブルーチンのフローチャートである。これは利用者が投了のボタン４２０ａがクリックされることにより実行される。これは、終了要求部４５０が行う処理である。
［Ｓ３２１］投了を対局部４８０に通知する。
［Ｓ３２２］終了要求プロトコルを使用し、パラメタとしてＮｉとＰｉをサーバ装置３００に送信する。
［Ｓ３２３］サーバ装置３００の応答を待つ。
［Ｓ３２４］サーバ装置３００からの応答結果を表示する。

図２９は、退場サブルーチンのフローチャートである。これは、退場要求部４６０が行う処理である。
［Ｓ３３１］退場処理プロトコルを使用しパラメタとしてＮｉとＰｉをサーバ装置３００に送信する。
［Ｓ３３２］サーバ装置３００の応答を待つ。
［Ｓ３３３］サーバ装置３００からの応答結果を表示する。

以上のようにして、システムが対局する相手を自動的に選定し、それぞれの利用者に示してくれるため、利用者自身が、対局相手を見つけるという作業が必要なくなる。また、利用者が絶えず選定結果が出たかどうかモニタする必要がなくなる。

もちろん、利用者ＤＢには、利用者のネットワークアドレス( 電話番号でも可) が含まれるため、利用者自身が対局相手の連絡先を調べる必要はない。
また、選定する場合、次のような効果がある。
１）いつまでも対局相手が選定されないといったことがなくなる。
２）最適の相手を見つけられる可能性が高くなる。
３）その時点時点でのゲームでの強さが自動的に反映され、対局相手もそれに応じて選択される。
４）システムへの入場と退場のしくみによって、システムのセキュリティが向上すると同時に、対局者選定の待ち時間も、システムへのアクセス状況に応じて変化させられるため、常に最短の待ち時間で対局開始できるようになる。
５）対局する時、対局相手の静止画像を見ることができるため、対局の臨場感が増す。

次に、本発明の実施の形態について説明する。これまで、記述してきた関連技術はひとつの選定範囲（以下ステージと呼ぶ）から利用者を選定し対局するだけであったが、本発明の実施の形態では、複数のステージをもつことを可能としたものである。これを、トーナメント戦へ応用した場合を例にとり説明する。

簡単にするために、トーナメント参加者を８人とする。そして、以下のような状況を想定する。
１）トーナメント戦開始の時点では、第１のステージに８人が登録している。ただ、この８人は、同時にサーバに接続しているわけではない。
２）ある時点、８人のうち、５人だけサーバに接続している場合を考える。この５人は第１ステージにおり、そこで選定が行われる。この選定は、本発明で記述しているように自動選定されてもよいし、利用者が第１ステージに入っている利用者リストの中から自ら選択してもよい。
３）こうして、対局が行われ、勝ち負けが決定する。そこで勝った利用者は、第２のステージに進む。負けた利用者は、そのままこのトーナメント戦から登録削除してもよいし、敗者復活戦として、第１のステージの下位ステージである第０のステージに移るようにしてもよい。
４）こうして、４人までの対局が行われ、第１ステージには１人が残り、第２ステージには２人が入る。
５）第１ステージに残った１人は、他のトーナメント参加者がサーバに接続し第１ステージに参加してくるまで待つか、一旦サーバへの接続を切り次の機会を待つ。
６）第２ステージの２人は、そのまま２人がサーバに接続している場合、さらに対局し、勝ったものは第３のステージに進む。

以上のようにすれば、サーバにトーナメント参加者が全員同時に接続していなくてもトーナメント戦が実施できる。こうすることにより、参加者間での事前の接続時刻などのネゴシエーションが不要となる。

ステージ管理機能を追加したシステム構成を以下に説明する。
図３０は、本発明の実施の形態のサーバ装置の構成を示す図である。このサーバ装置５００は、クライアント装置６００とネットワークを介して接続されている。サーバ装置５００は、ネットワークＯＳ５１０、認証部５２０、利用者ＤＢ５３０、対局者選定部５４０、選定条件保持部５５０、対局管理部５６０、及びステージ管理部５７０で構成されている。ステージ管理部５７０以外の各構成要素は、図３に示した第１の関連技術の同様の構成要素と同じ機能に対する追加機能を有している。以下、追加された機能について説明する。

利用者ＤＢ５３０は、各利用者のステージ状態に関する情報が登録されている。利用者ＤＢ５３０の登録項目を以下の表５に示す。

このように、ステージ情報（ＳＴ）が設けられており、その利用者が属しているステージの番号が登録されている。値が「ｎｕｌｌ」の場合は、どのステージにも属していないことを示している。

対局者選定部５４０は、対局要求を受けた場合、その要求を発行した利用者を対局待ちに設定（Ｓｉ＝１) すると共に、その利用者のステージ情報（ＳＴｎ）を読み取る。次に、自動選定処理部５４１が、ステージ情報が同じで（ＳＴ＝ＳＴｎ）、かつ対局待ちである利用者を読み取り、選定処理を行う。上記の例のトーナメント戦の場合は、通常対局待ちは１人しかおらず、かつ必ず対局する条件のため、対局待ちの利用者がいれば、すぐに割り当てるようにする。

上記では、自動選定処理部５４１で対局者を割り当てたが、対局待ちの利用者リストをクライアント側に表示するようにし、クライアント側で選択して、その対局待ちの利用者に対局要求を発行することも可能である。

ステージ管理部５７０は、対局が終了した場合にクライアント装置６００から送られてくる終了の通知を受け取る。その通知に基づいて、対局者のステージ情報（ＳＴｎ）を利用者ＤＢ５３０から読み取り、各対局者のステージ情報を更新する。上記トーナメント戦の例では、勝った対局者のステージ情報に１を加え（ＳＴｎ＝ＳＴｎ＋１）、負けた方はこのトーナメント戦から削除する（ＳＴｎ＝ｎｕｌｌ）。

図３１は、本発明の実施の形態のクライアント装置の構成を示す図である。本実施の形態のクライアント装置６００は、ユーザインタフェース６１０、対局要求部６２０、ネットワークＯＳ６４０、対局部６３０、及び終了要求部６４０で構成される。この各構成要素は、図１７に示した第２の関連技術の同様の構成要素と同じ機能を有している。

以下に、本実施の形態に特徴的な処理を、図３２〜図３４のフローチャートを用いて説明する。
図３２は、サーバ装置受信処理のフローチャートである。
［Ｓ４０１］ネットワークＯＳ５１０は、なんらかの信号の受信があるか否かを絶えず判断している。信号の受信が発生したらステップＳ４０２に進み、信号の受信が発生していない場合は、このステップＳ４０１の処理を繰り返す。
［Ｓ４０２］認証部５２０は、信号の発信者が正当な利用者かどうかを認証する。不正な利用者であればステップＳ４０３に進み、正当な利用者であればステップＳ４０４に進む。
［Ｓ４０３］認証部５２０は、受信した信号が不正な利用者からのものであれば、Ｅｒｒｏｒである旨をクライアント装置６００に通知する。その後、ステップＳ４０１に進み、次の受信に備える。
［Ｓ４０４］認証部５２０は、受信した信号が正当な利用者からのものであれば、受信した要求の種類を判別する。終了要求であればステップＳ４０５へ、対局要求であればステップＳ４０６へ、指し手であればステップＳ４０７に進む。
［Ｓ４０５］ステージ管理部５７０が、終了処理を行う。その後ステップＳ４０１に進み、次の受信に備える。この処理の詳細は、図３３に示す。
［Ｓ４０６］対局者選定部５４０が、第４の選定処理を行う。その後ステップＳ４０１に進み、次の受信に備える。この処理の詳細は、図３４に示す。
［Ｓ４０７］対局管理部５６０が、対局管理処理を行う。その後ステップＳ４０１に進み次の受信に備える。この処理は、図１５に示した第１の関連技術の処理と同様である。

図３３は、終了サブルーチンのフローチャートである。これは、ステージ管理部５７０が行う処理である。
［Ｓ４１１］利用者Ｎｉ，Ｍｉ（対局両者）のステージ情報を更新する。具体的には、勝った利用者ステージ情報は、１を加え、負けた方は、空(null)を入れる。
［Ｓ４１２］ステップＳ４１１で更新された利用者ステージ情報を、利用者ＤＢ５３０に記録する。

図３４は、第４の選定処理のフローチャートである。これは、対局者選定部５４０が行う処理である。
［Ｓ４２１］対局要求を発行した利用者のステージと同じステージにいる対局待ちの利用者情報を利用者ＤＢ５３０から読み出す。
［Ｓ４２２］相手が見つかったか否かを判断する。見つかった場合はステップＳ４２３に進み、見つからなかった場合はステップＳ４２５に進む。
［Ｓ４２３］対局相手が見つかった場合は、それぞれの利用者のクライアント装置に、対局者を紹介する（対局情報の応答と通知）。
［Ｓ４２４］両者の利用者ＤＢ５３０の利用者状態を対局待ちから対局中に更新（Ｓ＝０）し、この処理を終了する。
［Ｓ４２５］対局相手が見つからなかった場合は、対局要求を発行した利用者のクライアント装置に待機の応答を行う。
［Ｓ４２６］対局要求を出力した利用者ＤＢ５３０の利用者状態を対局待ちに設定（Ｓ＝１）し、処理を終了する。

このように、対局が終了するごとに、各利用者のステージを変更することで、ネットワークを介したトーナメント戦を行うことが可能となる。
図３５は、トーナメント戦のステージの説明図である。８人のトーナメント参加者が第１ステージ５１にエントリしており、現在５人がサーバ装置５００接続している。そのうち２組４人が対局を行い、２人が勝ち進み第２ステージ５２にあがる。第２ステージでもすぐに対局を行い、１人が第３ステージ５３に進んでいる。あとは、もうひとりが勝ち上がってくるのを待つことになる。

従来、トーナメント戦は、「２２時から開始する」などのように利用者間の事前のネゴシエーションが必要であったが、上記のようなステージ管理を行うことで、事前の時間合せが必要なくなり、各利用者が好きな時間にサーバに接続してトーナメント戦を実行することができるようになる。

さて、以上、説明したように各実施の形態は、サーバ経由のサーバ−クライアント形態で対局を行うものであった。これをクライアント−クライアント間で行うことも可能である。こうすることにより、サーバでの負荷が軽くなり通信速度も向上する。

また、ここでは、利用者の情報検索蓄積の手段にデータベース（ＤＢ）を使用したが、これは、通常のファイルシステムを使用しても実現可能である。
もちろん、ここで利用するネットワークは無線でも有線でもどちらでも可能である。

また、上記の実施の形態では、２人用のゲームについて説明したが、本発明は２人用に限定されるものではない。３人以上のゲーム、例えば麻雀などの対局相手を選定するためには、自動選定処理の選定ルーチンを、１人の利用者に対して３回繰り返して行い、３人の対局相手を選定することで、麻雀の４人のメンバをそろえることが可能である。

また、本発明では、選定処理はサーバ装置で実施するよう記述したが、サーバ装置は利用者ＤＢの管理だけにして、当該選定処理は各クライアント装置にて行うようにすることも可能である。この場合、選定処理に必要な情報は、選定処理実施前にサーバ装置からクライアント装置に、送られる。こうすることにより、特に多人数がサーバに接続し、ネットワークゲームを行う場合には、処理が各クライアント装置に分散され、サーバでの負荷が軽くなる。

また、本発明では、利用者からの指定条件を考慮していないが、もちろん、利用者からの指定条件を第１の希望として選定条件の中に含めることも可能であり、こうすることにより、さらに最適化が可能となる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、サーバ装置とクライアント装置とが有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述されており、このプログラムをコンピュータで実行することにより、上記処理がコンピュータで実現される。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリ等がある。市場を流通させる場合には、ＣＤ−ＲＯＭ(Compact Disk Read Only Memory) やフレキシブルディスク等の可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置等にプログラムを格納しておき、メインメモリにロードして実行する。

本発明の関連技術の原理構成図である。 本発明の第１の関連技術に係るネットワークゲームシステムの全体の概略構成図である。 サーバ装置内の構成を示す図である。 クライアント装置の構成を示す図である。 ユーザインタフェースの例を示す図である。 サーバ装置の受信処理を示すフローチャートである。 選定サブルーチンのフローチャートである。 第１の選定処理のフローチャートである。 第２の選定処理のフローチャートである。 対局管理処理のフローチャートである。 第１の選定処理で呼び出される選定ルーチンａのフローチャートである。 第２の選定処理で呼び出される選定ルーチンｂのフローチャートである。 ユーザインタフェースが行う処理のフローチャートである。 対局要求処理のフローチャートである。 対局処理のフローチャートを示す図である。 本発明の第２の関連技術のサーバ装置の構成を示す図である。 第２の関連技術のクライアント装置の構成を示す図である。 拡張されたユーザインタフェースの例を示す図である。 サーバ装置での受信処理を示すフローチャートである。 入場受付サブルーチンのフローチャートである。 終了サブルーチンのフローチャートである。 退場サブルーチンのフローチャートである。 第３の選定処理のフローチャートである。 第３の選定処理で呼び出される選定ルーチンｃのフローチャートである。 第１の選定処理で呼び出される選定ルーチンａ'のフローチャートである。 クライアントでのユーザ入力処理のフローチャートである。 入場サブルーチンのフローチャートである。 終了サブルーチンのフローチャートである。 退場サブルーチンのフローチャートである。 本発明の実施の形態のサーバ装置の構成を示す図である。 本発明の実施の形態のクライアント装置の構成を示す図である。 サーバ装置受信処理のフローチャートである。 終了サブルーチンのフローチャートである。 第４の選定処理のフローチャートである。 トーナメント戦のステージの説明図である。

符号の説明

１０ サーバ装置
１１ 利用者情報記憶手段
１２ 対局者選定手段
１３ 対局相手通知手段
１４ 対局管理手段
２０ クライアント装置
２１ 対局要求手段
２２ 対局手段
３１ ネットワーク

Claims (5)

1. 通信ネットワーク上の複数の参加者にゲームの対局を行わせるサーバ装置において、
   上下関係を有する複数のステージのいずれかに属する複数の利用者の情報を、各利用者が属するステージを示すステージ情報に対応づけて格納する利用者情報記憶手段と、
   対局要求を受け取ると、前記対局要求を発信した利用者を登録する対局要求応答手段と、
   登録された利用者のうち同一のステージに属する複数の利用者を前記利用者情報記憶手段から選択し、選択された利用者による対局をステージ毎に決定する対局者選定手段と、
   対局結果を受け取ると、前記利用者情報記憶手段内の勝利した利用者のステージ情報を、上位のステージに変更するステージ管理手段と、
   を有することを特徴とするサーバ装置。
2. 前記ステージ管理手段は、前記利用者情報記憶手段内の負けた利用者のステージ情報を削除することを特徴とする請求項１記載のサーバ装置。
3. 通信ネットワーク上の複数の参加者にゲームの対局を行わせるネットワークゲームシステムにおいて、
   上下関係を有する複数のステージのいずれかに属する複数の利用者の情報を、各利用者が属するステージを示すステージ情報に対応づけて格納する利用者情報記憶手段と、
   対局要求を受け取ると、前記対局要求を発信した利用者を登録する対局要求応答手段と、
   登録された利用者のうち同一のステージに属する複数の利用者を前記利用者情報記憶手段から選択し、選択された利用者による対局をステージ毎に決定する対局者選定手段と、
   対局結果を受け取ると、前記利用者情報記憶手段内の勝利した利用者のステージ情報を、上位のステージに変更するステージ管理手段と、
   を具備するサーバ装置と、
   前記対局要求を前記サーバ装置へ出力する対局要求手段を具備するクライアント装置と、
   を有することを特徴とするネットワークゲームシステム。
4. 通信ネットワーク上の複数の参加者にゲームの対局を行わせるための対局者選定プログラムを記録したコンピュータ読み取り可能な記録媒体において、
   コンピュータを、
   上下関係を有する複数のステージのいずれかに属する複数の利用者の情報を、各利用者が属するステージを示すステージ情報に対応づけて格納する利用者情報記憶手段、
   対局要求を受け取ると、前記対局要求を発信した利用者を登録する対局要求応答手段、
   登録された利用者のうち同一のステージに属する複数の利用者を前記利用者情報記憶手段から選択し、選択された利用者による対局をステージ毎に決定する対局者選定手段、
   対局結果を受け取ると、前記利用者情報記憶手段内の勝利した利用者のステージ情報を、上位のステージに変更するステージ管理手段、
   として機能させるための対局者選定プログラムを記録したコンピュータ読み取り可能な記録媒体。
5. 通信ネットワーク上の複数の参加者にゲームの対局を行わせるための対局者選定方法において、
   対局要求応答手段が、対局要求を受け取ると、前記対局要求を発信した利用者を登録し、
   対局者選定手段が、上下関係を有する複数のステージのいずれかに属する複数の利用者の情報を、各利用者が属するステージを示すステージ情報に対応づけて格納する利用者情報記憶手段から、登録された利用者のうち同一のステージに属する複数の利用者を選択し、選択された利用者による対局をステージ毎に決定し、
   ステージ管理手段が、対局結果を受け取ると、前記利用者情報記憶手段内の勝利した利用者のステージ情報を、上位のステージに変更する、
   ことを特徴とする対局者選定方法。
   
   

Images