JP2005021590A - 複数ユーザを同期させるシステムおよび同期方法 - Google Patents

Abstract

【課題】 通信トラヒックを増大させることなく、かつ、サーバおよびクライアントマシンの負荷も増大させることなく、クライアントマシン間の同期をとる。
【解決手段】 ネットワークを介して接続された複数のクライアント１４を同期させて、一定のシーケンスに沿った処理を実行するサーバ１２は、シーケンスに沿って次に実行すべき処理を特定して、必要な処理を実行するゲーム処理部１６と、クライアント１４からの状態取得要求に対して、把握されたシーケンスに基づく特定のクライアントからの状態変化通知の受理があるまで、当該クライアントからの状態取得要求を保留し、状態変化通知の受理の後、必要に応じて実行される処理があってから、状態取得要求に対する応答をクライアントに返す同期制御部１８とを備えている。
【選択図】 図１

Description

本発明は、複数の端末装置を同期させるシステムおよび方法に関する。

インターネットの普及により、複数のクライアントマシンを同期させて、コンテンツやデータを共有する状況が数多く見られるようになった。たとえば、多ユーザ参加型のリアルタイム対戦ゲームにおいては、クライアントマシンの同期が必要となる。

従来、リアルタイム対戦ゲームにおいては、たとえば、各クライアントマシンから、所定の間隔（１秒間隔など）で定期的に、サーバに状況を問い合わせ、その応答内容によって、クライアントマシンの側で、状況変化を把握していた。このような方法を採用すると、状況変化があったという応答をサーバからもらうまで、クライアントマシンは無意味な問い合わせを繰り返すことになり、通信トラヒックを増大させるとともに、サーバおよびクライアントマシンの負荷も増大させるという問題がある。また、問い合わせの間隔に応じてのみ、状態変化を把握することとなり即応性にも欠ける。

特開２００２−２７１３０７号公報

たとえば、特許文献１には、ホストとなるゲーム機（クライアントマシン）から同期信号を出力して、他のゲーム機(クライアントマシン)との同期をとること（特許文献１の図１０参照）や、それぞれのゲーム機（クライアントマシン）がテレビジョン信号を受信して、その信号に基づいて、同期をとることが提案されている。しかしながら、前者においては、通信トラヒックの増大および各マシンの負荷を解決することはできず、後者においては、新たにテレビジョン信号を受理できるような構成を追加する必要も生じる。

特に、携帯電話のような携帯端末においては、インターネットを通じて行なう通信について、通信プロトコルとしてＨＴＴＰ（HyperText Transfer Protocol）を利用することが前提となり、かつ、携帯端末に与えられるＩＰはキャリアゲートウェイを通じて通信を行なうことを前提として、ローカルなＩＰが与えられる。また、ローカルＩＰを持つ端末に対しては、外部（たとえばサーバ）から、直接データをプッシュ(push)して通信することができないという制約も課されている。

本発明は、通信トラヒックを増大させることなく、かつ、サーバおよびクライアントマシンの負荷も増大させることなく、クライアントマシン間の同期をとることができるシステムおよび方法を提供することを目的とする。また、本発明は、携帯電話のような端末でも、適切に複数の端末を同期させることができるシステムおよび方法を提供することを目的とする。

本発明の目的は、ネットワークを介して接続された複数のクライアントを同期させて、一定のシーケンスに沿った処理を実行するシステムであって、シーケンスに沿って次に実行すべき処理を特定して、必要な処理を実行する処理手段と、クライアントからの状態取得要求に対して、処理手段において把握されるシーケンスに基づく特定のクライアントからの状態変化通知の受理があるまで、当該クライアントからの状態取得要求を保留し、前記状態変化通知の受理の後、必要に応じて実行される処理手段による処理があってから、前記状態取得要求に対する応答を前記クライアントに返す同期制御手段とを備えたことを特徴とするシステムにより達成される。

本発明によれば、クライアントからの状態取得要求を、特定クライアントからの状態変化通知があるまで保留することで、クライアントの同期をはかる。これにより、クライアントが所定の時間間隔で問い合わせをする必要がなくなる。これにより、トラヒックの増大、サーバおよびクライアントの負荷の増大を防止することが可能となる。

好ましい実施態様においては、前記同期制御手段が、全てのクライアントからの状態取得要求を受理した上で、当該要求に対する応答を、前記全てのクライアントに返す。

また、好ましい実施態様においては、前記同期制御手段が、全てのクライアントからの状態取得要求を受理した上で、前記シーケンスに基づき特定のクライアントに対して、特定の応答を返し、さらに、当該特定のクライアントからのさらなる要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返す。

別の好ましい実施態様においては、前記同期制御手段が、特定のクライアントからの要求を受理した上で、これを保留し、他のクライアントからの他の要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返す。
上述したような保留、および、受理した後の応答の送信を組み合わせることにより、種々のシーケンスにしたがって、クライアントを同期させつつ処理を進めることが可能となる。

前記一定のシーケンスは、ゲームであっても良い。ゲームには、麻雀ゲーム、カードゲームなどが含まれる。
また、前記クライアントとサーバとの間の通信が、ＨＴＴＰに従っていても、適切に同期を図りつつ処理を進めることが可能である。

また、本発明の目的は、ネットワークを介して接続された複数のクライアントを同期させて、一定のシーケンスに沿った処理を実行する方法であって、シーケンスに沿って次に実行すべき処理を特定して、必要な処理を実行する処理ステップと、クライアントからの状態取得要求に対して、処理ステップにおいて把握されるシーケンスに基づく特定のクライアントからの状態変化通知の受理があるまで、当該クライアントからの状態取得要求を保留し、前記状態変化通知の受理の後、必要に応じて実行される処理があってから、前記状態取得要求に対する応答を前記クライアントに返す同期制御ステップとを備えたことを特徴とするシステムによっても達成される。

好ましい実施態様においては、前記同期制御ステップが、全てのクライアントからの状態取得要求を受理した上で、当該要求に対する応答を、前記全てのクライアントに返すステップを含む。

また、好ましい実施態様においては、前記同期制御ステップが、全てのクライアントからの状態取得要求を受理した上で、前記シーケンスに基づき特定のクライアントに対して、特定の応答を返し、さらに、当該特定のクライアントからのさらなる要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返すステップを含む。
別の好ましい実施態様においては、同期制御ステップが、特定のクライアントからの要求を受理した上で、これを保留し、他のクライアントからの他の要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返すステップを含む。

本発明によれば、通信トラヒックを増大させることなく、かつ、サーバおよびクライアントマシンの負荷も増大させることなく、クライアントマシン間の同期をとることができるシステムおよび方法を提供することが可能となる。また、本発明によれば、携帯電話のような端末でも、適切に複数の端末を同期させることができるシステムおよび方法を提供することが可能となる。

以下、添付図面を参照して、本発明の実施の形態について説明する。図１に示すように、本発明の実施の形態においては、インターネット１０に、サーバ１２および複数のクライアント１４−１、１４−２、１４−３、１４−４が接続されている。本実施の形態においては、クライアント１４−１〜１４−４として、キャリアゲートウェイ（図示せず）を介してインターネットに接続可能な携帯電話が利用される。また、図１においては、４つのクライアントのみを図示したが、無論、それより多く、或いは少ない数のクライアントが接続され、サーバ１２とのデータ授受をなす場合があることはいうまでもない。また、クライアントは、携帯電話に限定されず、通常のパーソナルコンピュータなどであっても良い。

クライアント１４−１〜１４−４と、サーバ１２との間の通信プロトコルはＨＴＴＰであり、基本的に、クライアント１４からリクエストがサーバ１２に伝達され、サーバ１２からレスポンスがクライアント１４に返されることによりデータ通信が実現される。

本実施の形態においては、４つのクライアント１４−１〜１４−４を同期させることにより、所定のゲーム（麻雀）をすることができる。無論、カードゲームを含む他のゲームを実現可能であることも言うまでもない。
図１に示すように、サーバ１２は、ゲームプログラムやゲーム結果等を記憶した記憶装置１５と、記憶装置からゲームプログラムを読み出して、ゲームを進行させるゲーム処理部１６と、ゲーム処理部１６によるゲーム進行情報に基づいて、ゲームに参加しているプレーヤを同期させるために必要な処理を実行するプレーヤ同期部１８と、インターネット１０を介して、プレーヤのクライアントとの通信を制御する通信インタフェース（Ｉ／Ｆ）２０とを備えている。ゲーム処理部１６およびプレーヤ同期部１８は、実際には、サーバにて動作するサーブレットにより実現される。

本実施の形態においては、基本的に、サーバ１２とクライアント１４−１〜１４−４の間では、ＨＴＴＰプロトコル上で、クライアントからの要求（リクエスト）に対する応答（レスポンス）を同期制御する。サーバに対するリクエストには、ゲーム進行において順番（たとえば、牌を場に捨てる順番）のプレーヤのクライアント（順番対象クライアント）からの状態変化通知や、他のクライアント（順番待ちクライアント）からの状態取得要求が含まれる。また、サーバからのレスポンスには、状態変化通知が含まれる。サーバ１２は、たとえば、クライアントからの状態取得要求に対して、特定のクライアントからの状態変化通知があるまで、クライアントへの応答を保留し、状態変化通知を受理した時点で応答を返すようになっている。

また、クライアント１４−１〜１４−４には、麻雀ゲームを実行するための所定の機能を備えたプログラムがダウンロードされる。このプログラムは、サーバから送られた牌の情報に基づく牌の表示、プレーヤからの入力の受付、入力による捨て牌のサーバへの通知、ポン、チー、槓、ロン、ツモなどのサーバへの通知が可能である。また、このプログラムにより、他のプレーヤがポン、チー、槓などをした場合に、その旨や牌を表示することもできる。また、プログラムにより、クライアント１４は、状態変化通知を受理すると、状態取得要求をサーバ１２に送信できるようになっている。

このように構成されたサーバ１２を利用して、４つのクライアント１４−１〜１４−４が麻雀ゲームをする場合について、以下に説明する。図２は、種々のタイミングにおけるサーブレットの構成を示す図である。それぞれのサーブレットについて、以下に説明する。

[EntryMajang]
対戦相手を募集するサーブレットである。ここでは、４つのクライアントからの要求が揃うまで、ＨＴＴＰ応答を行なわない。４つのクライアントからの要求があると、サーブレット「EntryMajang」は、アクセスしてきたクライアントのそれぞれに、セッションＩＤを返す。セッションＩＤは、サーブレットＡＰＩの「getSession(true)」というメソッドを利用して得る。また、セッションには、現状のプレーヤの情報を記録する「MjPlayer」と、４人のプレーヤをメンバーに持つ「Party」クラスのインスタンスを割り当てる。

[BaState]
現在の場の状態を得るとともに、配牌を行なって、クライアントに配牌状況を返す。

[KyokuState]
現在の局の状態を取得する。ツモの番にあるプレーヤにはツモの番であることおよびツモ牌を通知する（符号２１１参照）。ツモ番以外のプレーヤは、ツモ番のプレーヤが牌を捨てるのを待って捨て牌を通知する（符号２１２〜２１４参照）。ただし、ツモ番のプレーヤが暗槓、追加槓、ツモ和了した場合も、ツモ番以外のプレーヤに通知される。

[DropHai]
クライアントからの捨て牌を受理する。このときに、ツモ番以外のプレーヤが、サーブレット「KyokuState」にアクセスしたまま待ち(wait)状態となっているため、「notifyAll」を実行する。また、牌を捨てた結果を通知する。この通知は、ツモ番以外のプレーヤ全てが、後述するサーブレット「CallNaki」を呼び出すまで待機する。

[CallNaki]
ツモ番以外のプレーヤがツモ番の捨て牌に対するアクション（ポン、チー、ロン、槓）を受理する。アクションを起こさないプレーヤも必ず、サーブレット「CallNaki」にアクセスして、アクションを起こさない旨を通知する必要がある。このサーブレットは、プレーヤ全員からの通知を受理するまで待機し、アクションの調停を行なった後、アクションの実行可能なプレーヤに実行可能である旨を通知する。アクションの実行が許可されなかったプレーヤには、アクション実行不可である旨を通知する。

[CallAnkan]
暗槓を行なうときに呼び出されるサーブレットである。暗槓が行なわれたことを登録して、サーブレット「KyokuState」で待機しているスレッドを全て起動する。起動されたスレッドは、通常と異なり、暗槓をクライアントに通知する。

[EndKyoku]
和了および流局が起きた際に、全てのクライアントから呼ばれる。全てのクライアントにおいて、描画のタイミング合わせのため、全てのクライアントがアクセスするまで待機する。局の初期化およびスコアのやり取りもこのサーブレットが実行する。

図２では、クライアント１４−１のプレーヤが捨て牌をして、その捨て牌に対して、あるプレーヤがロンをした状態を示している。この例では、対戦相手の募集からある局の終了までに、５回の同期ポイントが存在する。

以下、ゲーム進行の際の種々の場面での同期を、フローチャートを参照してより詳細に説明する。まず、ゲームが開始される前に、麻雀ゲームへの参加者を募集する場合について、図３を参照して説明する。ここでは、サーバ１２は、参加者を確定させるために、各クライアントからのゲーム参加要求（ステップ３０１〜３０４参照）がサーバ１２に伝達されるまで、各クライアント１４にレスポンスを返さない。クライアント１４−１〜１４−４からのゲーム参加要求を受理し、ゲームプログラムを参照して、ゲームを開始できると判断した場合、サーバ１２は、それぞれのクライアント１４に、ほぼ同時に参加許可応答をレスポンスとして返す（ステップ３０５〜３０８参照）。これにより、各クライアント１４を同期させることができる。これはサーブレット「EntryMajang」により実現される。

次いで、各クライアント１４は、場の状態取得要求をサーバ１２に伝達する（ステップ３１１〜３１４）。サーバ１２においては、各クライアント１４からの場の状態取得要求が伝達されるまで待機し、全ての要求を受理すると、場の状態応答を、各クライアント１４に返す（ステップ３１５〜３１８）。場の状態応答においては、各プレーヤの場所、風、配牌および持ち点なども通知される。

図４は、クライアント１４−１のプレーヤがツモ牌を取得してから、次のプレーヤがツモ牌を取得する直前までの一連の処理を示すタイミングチャートである。各クライアント１４からサーバ１２に状態取得要求が伝達されると（ステップ４０１〜４０４）、ツモ牌を取得すべきプレーヤが操作するクライアント１４−１に対しては、ツモ順およびツモ牌の情報を応答として返す（ステップ４０５）。この段階では、他のクライアント１４−２〜１４−４に対しては、なんら応答を返さずに待機させる。

クライアント１４−１から、捨て牌の情報を含む捨て要求がサーバ１２に伝達されると（ステップ４１１）、サーバ１２は、他のクライアント１４−２〜１４−４に、捨て牌を通知する（ステップ４１２〜４１４）。この通知が、先の状態取得要求に対する応答となる。すなわち、このタイミングで各クライアントの同期をとることができる。なお、クライアント１４−１からの捨て要求に対する応答は、後述するように、引き続き実行される捨て牌に対するアクション要求に対する応答と同期される。

他のクライアント１４−２〜１４−４からは、捨て牌に対するアクション要求がサーバ１２に伝達される（ステップ４２１〜ステップ４２３）。捨て牌に対してなんらアクションを起こさない場合には、何もしないことを意味する要求が伝達される。他のクライアント全てから、捨て牌に対するアクション要求を受理すると、サーバ１２は、捨て牌をしたプレーヤのクライアント１４−１に、応答として、捨て牌結果を通知するとともに（ステップ４２４）、他のクライアント１４−２〜１４−４に、アクション要求の応答を通知する（ステップ４２５〜４２７）。つまり、全ての他のクライアントから捨て牌に対するアクション要求を受理することにより、他のクライアントの同期をとり、捨て牌結果およびアクション要求の応答を通知することで、全てのクライアントの同期を取ることができる。

このように、あるプレーヤのツモ番において、状態取得要求に即座に応答するのは、ツモ番にあたっているプレーヤのクライアントに対してのみであり、それ以外のクライアントに対しては、ツモ番のプレーヤの捨て牌を待って応答が返されることになる。

図５は、次のツモ番に相当するクライアント１４−２のプレーヤがツモ牌を取得してから、次のプレーヤがツモ牌を取得する直前までの一連の処理を示すタイミングチャートである。ツモ番に対応するクライアントが、クライアント１４−１から１４−２に変更された以外は、同様の処理が実行され、各クライアントの同期が取られていることが理解できるであろう。

次に、ある捨て牌に対して、他のプレーヤがポンをする場合の処理および各クライアントマシンの同期について、図６および図７を参照して説明する。この例では、クライアント１４−１のプレーヤによる捨て牌に対して、クライアント１４−３のプレーヤがポンをする。図６におけるステップ６０１〜ステップ６１４は、それぞれ、図４のステップ４０１〜ステップ４１４に相当する。

捨て牌通知を受理した他のクライアント１４−２〜１４−３は、サーバ１２に、捨て牌に対するアクション要求を送信する（ステップ６２１〜６２３）。クライアント１４−３からのアクション要求には、捨て牌に対するポンの要求が含まれる。

他のクライアント１４−２〜１４−４からのアクション要求を受理した状態で、サーバ１２は、他のクライアント１４−２〜１４−４からのアクション要求を参照して、各アクションの調停を図る。より具体的には、ポン、チー、槓、ロンなどがアクション要求に含まれている場合には、サーバ１２は、アクションの優先順にしたがってどのアクションが成立するかを判断する。

次いで、捨て牌をしたプレーヤのクライアント１４−１に対して、捨て牌結果が通知されるとともに（ステップ６２４）、他のクライアント１４−２〜１４−３に対して、アクション要求に対する応答が通知される（ステップ６２５〜ステップ６２７）。ここでは、捨て牌結果として、クライアント１４−３のプレーヤがポンをした旨が通知され、また、クライアント１４−２、１４−４に対しては、クライアント１４−３のプレーヤがポンをしたこと、クライアント１４−３には、アクション要求が成立したこと、つまりポンができたことが通知される。このタイミングで、クライアントの同期をはかることができる。

次いで、クライアント１４−１、１４−２および１４−４からは、状態取得要求がサーバ１２に伝達される（ステップ７０１〜７０３）。ポン、チーなどいわゆる鳴いた場合には、そのクライアントからは、状態取得要求は出力されない。クライアント１４−１、１４−２および１４−４からの状態取得要求に対する応答は、クライアント１４−３からの牌の捨て要求があるまで待機させられる。クライアント１４−３から、牌の捨て要求がサーバ１２に伝達されると（ステップ７０４）、サーバ１２から、クライアント１４−１、１４−２および１４−４に、応答として、捨て牌通知が伝達される（ステップ７０５〜７０７）。このタイミングで、クライアント１４−１、１４−２および１４−４を同期させることができる。また、クライアント１４−３からの捨て要求は、他のクライアント１４−１、１４−２および１４−４からサーバに対して要求があるまで待機させられる。

サーバ１２からの捨て牌通知を受理したクライアントにおける処理は、図４および図６を参照して説明したものとほぼ同様である。他のクライアント１４−１、１４−２および１４−４は、捨て牌に対するアクション要求をサーバ１２に伝達する（ステップ７１１〜７１３）。捨て牌に対して、さらに、ポン、チーなどのアクションも可能である。この例では、何もしないことを意味する要求が伝達されると考える。

クライアント１４−１、１４−２および１４−４からのアクション要求を受理すると、サーバ１２は、捨て牌にかかるクライアント１４−３に、捨て要求に対する応答として、捨て牌結果を通知する（ステップ７１４）とともに、クライアント１４−１、１４−２および１４−３に、アクション要求に対する応答を通知する（ステップ７１５〜７１７）。図示しないが、その後、クライアント１４−１〜１４−４が、サーバ１２に場の状態取得要求を伝達することで、さらにゲームが進行する。

次に、あるプレーヤがツモ牌を暗槓および追加槓する場合について、図８および図９を参照して説明する。この例では、クライアント１４−１のプレーヤがツモ牌で槓をする。図８におけるステップ８０１〜８０５は、図４のステップ４０１〜４０５に相当する。

ツモ牌を取得したクライアント１４−１は、槓要求を、サーバ１２に伝達する（ステップ８０６）。サーバ１２は、これに応答して、槓があったことを示す槓通知を、他のクライアント１４−２〜１４−４に伝達する（ステップ８０７〜８０９）。ここでも、他のクライアント１４−２〜１４−４に対して、クライアント１４−１からの何らかの要求（この場合には槓要求）があるまで応答を返さない。槓通知には、槓により新たに増えたドラの情報も含まれる。これにより、ステップ８０１〜８０３の状態取得要求に対する応答を同期させることできる。

次いで、サーバ１４は、クライアント１４−１の槓要求に対する応答（槓応答）を返す（ステップ８１０）。この槓応答においても、新たに増えたドラの情報が含まれる。続いて、他のクライアント１４−２〜１４−４は、サーバ１２に、状態取得要求を伝達するが（ステップ９０１〜ステップ９０３参照）、サーバ１２は、クライアント１４−１からの捨て牌を示す捨て要求があるまで（ステップ９０４）、上記状態取得要求には応答しない。

クライアント１４−１からの捨て要求を受理すると、サーバ１２は、他のクライアント１４−２〜１４−４に対して、捨て牌情報を含む捨て牌通知を返す（ステップ９０５〜ステップ９０８）。これは、状態取得要求に対する応答であり、このタイミングで、他のクライアント１４−２〜１４−４の同期がはかられる。なお、クライアント１４−１からの捨て要求に対する応答は、他のクライアント１４−１〜１４−４からの、捨て牌に対するアクション要求が揃うまで返されない。

次いで、他のクライアント１４−２〜１４−４からの捨て牌に対するアクション要求が、サーバ１２に伝達されると（ステップ９１１〜９１３）、サーバ１２は、捨て牌要求に対して、必要な場合には、各アクションの調停を図り、どのアクションが成立するかを判断する。この例では、他のクライアント１４−２〜１４−４からは、何もしないことを意味する要求が伝達されると考える。

クライアント１４−２〜１４−４からのアクション要求を受理すると、サーバ１２は、捨て牌にかかるクライアント１４−１に、捨て要求に対する応答として、捨て牌結果を通知する（ステップ９１４）とともに、クライアント１４−２〜１４−４に、アクション要求に対する応答を通知する（ステップ９１５〜ステップ９１７）。図示しないが、その後、クライアント１４−１〜１４−４が、サーバ１２に場の状態取得要求を伝達することで、さらにゲームが進行する。

次に、あるプレーヤが他人の捨て牌でロンする場合について、図１０および図１１を参照して説明する。この例では、クライアント１４−１のプレーヤの捨て牌で、クライアント１４−３のプレーヤがロンをすることにより、この局のゲームが終了する。図１０におけるステップ１００１〜ステップ１０１４は、図４のステップ４０１〜４１４にそれぞれ対応する。クライアント１４−１からの捨て要求に対する応答は、他のクライアント１４−２〜１４−４からの捨て牌に対するアクション要求があるまで待機させられる。

捨て牌通知を受理した他のクライアント１４−２〜１４−３は、サーバ１２に、捨て牌に対するアクション要求を送信する（ステップ１０２１〜１０２３）。なお、クライアント１４−３からのアクション要求には、捨て牌に対するロンの要求が含まれる。

他のクライアント１４−２〜１４−４からのアクション要求を受理した状態で、サーバ１２は、他のクライアント１４−２〜１４−４からのアクション要求を参照して、各アクションの調停を図る。より具体的には、ポン、チー、槓などがアクション要求に含まれている場合には、サーバ１２は、アクションの優先順にしたがってどのアクションが成立するかを判断する。この例では、クライアント１４−１のプレーヤの捨て牌により、クライアント１４−３のプレーヤがロンするというアクションが成立する。

次いで、捨て牌をしたプレーヤのクライアント１４−１に対して、捨て牌結果が通知されるとともに（ステップ１０２４）、他のクライアント１４−２〜１４−３に対して、アクション要求に対する応答が通知される（ステップ１０２５〜ステップ１０２７）。ここでは、捨て牌結果として、クライアント１４−３のプレーヤがロンをした旨が通知される。また、クライアント１４−２、１４−４に対しては、クライアント１４−３のプレーヤがロンをしたこと、クライアント１４−３には、アクション要求が成立したこと、つまりロンをしてあがったことが通知される。このタイミングで、クライアントの同期をはかることができる。

クライアント１４−１〜１４−４は、ゲームの局が終了したことから、終了状態要求を、サーバ１２に伝達する（ステップ１１０１〜１１０４）。サーバ１２は、全てのクライアントからの終了状態要求を受理することに応答して、終了状態通知を、クライアント１４−１〜１４−４に送信する（ステップ１１０５〜１１０６）。これにより、ゲームの局が終了する。

次に、あるプレーヤが自己のツモ牌でロンする場合について、図１２および図１３を参照して説明する。この例では、クライアント１４−１のプレーヤが自己のツモ牌でロンする。図１２におけるステップ１２０１〜ステップ１２０５は、図４のステップ４０１〜ステップ４０５にそれぞれ対応する。他のクライアント１４−２〜１４−４の状態取得要求に対する応答は、クライアント１４−１からの要求がサーバに１２に受理されるまで待機させられる。

クライアント１４−１が、ツモ牌に対してツモによるあがりを要求すると（ステップ１２０６）、サーバ１２は、他のクライアント１４−２〜１４−４に対して、状態取得要求の応答として、クライアント１４−１のユーザがツモあがりをしたことを示すツモ通知を伝達する（ステップ１２０７〜１２０９）。また、サーバ１２は、ツモ要求に対する応答（ツモ応答）を、クライアント１４−１に送信する（ステップ１２１０）。

クライアント１４−１〜１４−４は、ゲームの局が終了したことから、終了状態要求を、サーバ１２に伝達する（ステップ１３０１〜１３０４）。サーバ１２は、全てのクライアントからの終了状態要求を受理することに応答して、終了状態通知を、クライアント１４−１〜１４−４に送信する（ステップ１３０５〜１３０６）。これにより、ゲームの局が終了する。

このように、本実施の形態においては、ゲーム進行に際して、特定のクライアントからの状態変化通知があるまで、クライアントからの状態取得要求を保留し、当が特定のクライアントからの通知を受理した段階で、応答を返すようになっている。ここでは、全てのクライアントからの要求が揃った場合に、全てのクライアントに応答を返す場合、あるクライアントの要求に対する応答を、特定のクライアントの要求や通知があってから返す場合などがある。これを組み合わせることにより、ゲーム中の必要な種々の時点で各クライアントを同期させることが可能となる。

本実施の形態によれば、サーバが、ユーザのクライアントからの要求に対して、特定のクライアントの要求や通知を受理したことを前提に応答を返すことで、クライアントの同期を実現している。したがって、クライアントが定期的にサーバに状況を問い合わせる必要がなく、トラヒックの増大や、問い合わせの際のサーバおよびクライアントの負荷の増大を防止することができる。また、クライアントが同期信号を別途取得する必要もなく、比較的簡単な構成でクライアントの同期を実現することが可能となる。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
たとえば、前記実施の形態においては、麻雀ゲームを複数のクライアントで進行させるために本発明を適用したがこれに限定されるものではなく、カードゲーム、ボードゲームなど複数のユーザが参加してリアルタイムに進行させる他のゲームにも本発明を適用可能であることは言うまでもない。特に、一定の順番が決められていれば、プレーヤの割り込み、スキップ、逆周りも実現することができる。したがって、汎用的な使用が可能である。

また、前記実施の形態においては、クライアントとしてインターネットに接続可能な携帯電話が利用されている。携帯電話の通信がＨＴＴＰに限定され、かつ、携帯電話には、キャリアゲートウェイを通じて通信を行なうことを前提としてローカルＩＰが与えられているため、サーバから直接データをプッシュすることができないため、本発明は特に有用である。しかしながら、携帯電話に限定されず、クライアントとして通常のパーソナルコンピュータを使う場合にも本発明を適用することができる。たとえば、ブロードバンドルータ等によりＩＰアドレス変換がされた環境においても特別な設定が不要という利点がある。

図１は、本実施の形態にかかるサーバおよびクライアントの接続およびサーバの構成を示すブロックダイヤグラムである。 図２は、本実施の形態において、種々のタイミングにおけるサーブレットの構成を示す図である。 図３は、本実施の形態において、ゲームが開始される前の参加者募集の際およびゲーム開始直後に実行される処理タイミングの例を示すタイミングチャートである。 図４は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図５は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図６は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図７は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図８は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図９は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図１０は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図１１は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図１２は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。 図１３は、本実施の形態において、ゲーム進行中に実行される処理タイミングの例を示すタイミングチャートである。

符号の説明

１２ サーバ
１４ クライアント
１５ 記憶装置
１６ ゲーム処理部
１８ 同期制御部
２０ 通信インタフェース

Claims (11)

1. ネットワークを介して接続された複数のクライアントを同期させて、一定のシーケンスに沿った処理を実行するシステムであって、
   シーケンスに沿って次に実行すべき処理を特定して、必要な処理を実行する処理手段と、
   クライアントからの状態取得要求に対して、処理手段において把握されるシーケンスに基づく特定のクライアントからの状態変化通知の受理があるまで、当該クライアントからの状態取得要求を保留し、前記状態変化通知の受理の後、必要に応じて実行される処理手段による処理があってから、前記状態取得要求に対する応答を前記クライアントに返す同期制御手段とを備えたことを特徴とするシステム。
2. 前記同期制御手段が、全てのクライアントからの状態取得要求を受理した上で、当該要求に対する応答を、前記全てのクライアントに返すことを特徴とする請求項１に記載のシステム。
3. 前記同期制御手段が、全てのクライアントからの状態取得要求を受理した上で、前記シーケンスに基づき特定のクライアントに対して、特定の応答を返し、さらに、当該特定のクライアントからのさらなる要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返すことを特徴とする請求項１または２に記載のシステム。
4. 前記同期制御手段が、特定のクライアントからの要求を受理した上で、これを保留し、他のクライアントからの他の要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返すことを特徴とする請求項１ないし３の何れか一項に記載のシステム。
5. 前記一定のシーケンスが、ゲームに対応することを特徴とする請求項１ないし４の何れか一項に記載のシステム。
6. 前記ゲームが麻雀ゲームであることを特徴とする請求項５に記載のシステム。
7. 前記クライアントとサーバとの間の通信が、ＨＴＴＰに従うことを特徴とする請求項１ないし６の何れか一項に記載のシステム。
8. ネットワークを介して接続された複数のクライアントを同期させて、一定のシーケンスに沿った処理を実行する方法であって、
   シーケンスに沿って次に実行すべき処理を特定して、必要な処理を実行する処理ステップと、
   クライアントからの状態取得要求に対して、処理ステップにおいて把握されるシーケンスに基づく特定のクライアントからの状態変化通知の受理があるまで、当該クライアントからの状態取得要求を保留し、前記状態変化通知の受理の後、必要に応じて実行される処理があってから、前記状態取得要求に対する応答を前記クライアントに返す同期制御ステップとを備えたことを特徴とするシステム。
9. 前記同期制御ステップが、全てのクライアントからの状態取得要求を受理した上で、当該要求に対する応答を、前記全てのクライアントに返すステップを含むことを特徴とする請求項８に記載の方法。
10. 前記同期制御ステップが、全てのクライアントからの状態取得要求を受理した上で、前記シーケンスに基づき特定のクライアントに対して、特定の応答を返し、さらに、当該特定のクライアントからのさらなる要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返すステップを含むことを特徴とする請求項８または９に記載の方法。
11. 前記同期制御ステップが、特定のクライアントからの要求を受理した上で、これを保留し、他のクライアントからの他の要求を受理した後、前記特定のクライアントおよび他のクライアントに応答を返すステップを含むことを特徴とする請求項８ないし１０の何れか一項に記載の方法。

Images