【事件の表示】
　特願２０１５−１３０３１０「プログラム、サーバ装置、及びゲーム制御方法」拒絶査定不服審判事件〔平成２７年１２月１７日出願公開、特開２０１５−２２６７９２、請求項の数（１２）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２５年１２月２０日（優先権主張平成２４年１２月２１日）に出願した特願２０１４−５３１０２４号の一部を平成２７年６月２９日に新たな特許出願としたものであって、平成２８年１０月２０日付けで手続補正がされ、同年１２月７日付けで拒絶理由通知がされ、平成２９年２月１４日付けで手続補正がなされ、同年５月８日付けで拒絶査定（原査定）がされ、これに対し、同年８月４日付けで拒絶査定不服審判の請求がなされると同時に手続補正書がされ、同年８月２４日付けで前置報告がされ、平成３０年４月１７日付けで拒絶理由通知（以下、「第１回当審拒絶理由通知」という。）がされ、同年６月２０日付けで手続補正がされ、同年７月３１日付けで拒絶理由通知（以下、「第２回当審拒絶理由通知」という。）がされ、同年８月１０日付けで手続補正がされたものである。
第２　原査定の概要
　原査定（平成２９年５月８日付け拒絶査定）の拒絶理由の概要は次のとおりである。
　この出願の下記の請求項に係る発明は、その原出願出願日前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その原出願出願日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
・請求項　　：１−１２
・引用文献等：１、２
＜引用文献等一覧＞
１．特開２０１１−５３０６号公報
２．特開２０１１−１８２８１８号公報
第３　当審拒絶理由の概要
　当審拒絶理由の概要は次のとおりである。
１．第１回当審拒絶理由通知
（１）この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
（２）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　　　　　　　　　記
（１）について
・請求項　　：１−１２
・引用文献等：１−４
＜引用文献等一覧＞
１．特開２０１１−５３０６号公報
２．特開２０１２−１８２７４４号公報（周知の技術手段）
３．特表２０１２−５２５６５９号公報（周知の技術手段）
４．特表２０１２−５２８４１１号公報（周知の技術手段）
（２）について
　請求項１〜１２に係る発明は、“通信規格は、ウェブソケットの通信規格”であることが特定されていないから、発明の課題を解決する手段が不明である。
２．第２回当審拒絶理由通知
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　記
（１）請求項１、１２の「第２の携帯端末から受け付けるステップ」、及び請求項１１の「第２の携帯端末から受け付ける手段」の技術的内容が不明である。
（２）請求項１、１２の各「ステップ」と、前記各「ステップ」を引用する「ステップ」との関係、及び請求項１１の各「手段」と、前記各「手段」を引用する「手段」との関係の技術的内容が不明である。
第４　本願発明
　本願の請求項１乃至１２に係る発明は、平成３０年８月１０日付けの手続補正によって補正された特許請求の範囲の記載からみて、その特許請求の範囲の請求項１乃至１２に記載された次のとおりのものと認められる。（以下、それぞれ「本願発明１」乃至「本願発明１２」という。）
「【請求項１】
　複数の携帯端末にゲームを提供するサーバ装置に、
　前記ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１ステップと、
　前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップと、
　前記第１ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３ステップと、
　前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４ステップと
を実行させるプログラム。
　　【請求項２】
　前記イベント情報は、前記ユーザの操作を示すアクション情報と、所定の期間を示す期間情報とを含み、
　前記第４ステップは、前記イベント情報を当該イベント情報に含まれる期間情報が示す期間内に、前記他のユーザの第１の携帯端末に送信するステップを含む、請求項１に記載のプログラム。
　　【請求項３】
　前記複数の第１の携帯端末のうちの少なくとも２つの第１の携帯端末それぞれから前記ユーザの操作に応じたイベント情報を受信した場合に、当該イベント情報それぞれを受け付けたイベント情報受付時間が所定の期間内にあるか否かを判定するステップと、
　前記判定の結果、前記イベント情報受付時間が前記所定の期間内にある場合、連続攻撃を前記対戦における敵に加えるステップとをさらに含む、請求項１記載のプログラム。
　　【請求項４】
　前記対戦における敵に関連付けられた、前記対戦を行うときの優劣関係が巡回的に定められた複数の属性のうちのいずれかの属性を示す属性情報を含む敵属性データと、前記対戦に参加しているいずれかのユーザの第１の携帯端末に関連付けられた、前記複数のうちのいずれかの属性を示す属性情報を含む端末属性データとに基づいて、前記対戦を制御するステップをさらに含む、請求項１記載のプログラム。
　　【請求項５】
　前記第２の要求を受付けた数に関連付けられた第１のインセンティブを当該対戦に参加したユーザに付与するステップ
をさらに含む、請求項１記載のプログラム。
　　【請求項６】
　接続を確立した前記第２の携帯端末が送信したイベント情報を受付けるステップと、
　前記イベント情報を受け付けた数に基づくパラメータが所定の条件を満たしている場合、当該対戦に参加したユーザに対して第２のインセンティブを付与するステップをさらに含む、請求項５に記載のプログラム。
　　【請求項７】
　前記対戦の実行期間中、当該対戦の制限時間から所定時間前になっても前記パラメータが目標値より少ない場合に、前記イベント情報の送信を促すメッセージを前記第２の携帯端末に送信するステップをさらに含む、請求項６記載のプログラム。
　　【請求項８】
　前記対戦の終了時に、当該対戦に参加したユーザに対して、当該対戦に参加したユーザの数に応じた第３のインセンティブを付与するステップをさらに含む、請求項１乃至７のいずれか一項に記載のプログラム。
　　【請求項９】
　前記第１ステップは、
　前記対戦の参加募集期間中、前記複数の携帯端末それぞれから前記第１の要求を受信するステップと、
　当該第１の要求の送信元の携帯端末のユーザのレベルが、前記対戦に参加しているユーザ数に応じたレベルよりも高い場合には、前記送信元の携帯端末との接続を確立するステップとを含む、請求項８記載のプログラム。
　　【請求項１０】
　前記複数の第１の携帯端末のうちのいずれかの第１の携帯端末から前記ユーザの操作に応じたイベント情報を受信したことを示すログ情報に基づいて、前記第３のインセンティブを当該第１の携帯端末に送信するステップをさらに含む、請求項９記載のプログラム。
　　【請求項１１】
　複数の携帯端末にゲームを提供するサーバ装置であって、
　前記ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１手段と、
　前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２手段と、
　前記第１手段において前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３手段と、
　前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４手段と
を備える、サーバ装置。
　　【請求項１２】
　複数の携帯端末にゲームを提供するサーバ装置に実行させるゲーム制御方法であって、
　前記ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１ステップと、
　前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップと、
　前記第１ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３ステップと、
　前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４ステップと
を含む、ゲーム制御方法。」
第５　引用文献、引用発明等
１．引用文献１について
　原査定の拒絶の理由及び第１回当審拒絶理由に引用され、本願の優先日前である平成２３年１月１３日に頒布された刊行物である引用文献１（特開２０１１−５３０６号公報）には、図面と共に次の事項が記載されている。（なお、下線は当審で付した。以下同じ。）
（１）「【特許請求の範囲】
【請求項１】
　
複数のゲーム装置がゲームサーバシステムを介して通信可能に接続され、前記ゲーム装置間で対戦ゲームを実行するゲームシステムであって、
　
前記ゲームサーバシステムは、
　
前記複数のゲーム装置のうちの一のゲーム装置からの要求に応じて、前記対戦ゲームに関するルールの情報を含んでなるグループ情報に基づき前記対戦ゲームを行うための対戦グループを作成する対戦グループ作成手段と、
　
他のゲーム装置から前記対戦グループへの参加の要求があった場合に、当該他のゲーム装置の前記対戦グループへの参加を許可する対戦グループ参加許可手段と、
　
前記対戦グループ参加許可手段によって前記対戦グループへの参加が許可されたゲーム装置のうち、所定の条件を充たすゲーム装置を戦闘モードに移行させるとともに、前記所定の条件を充たさないゲーム装置を観戦モードに移行させる戦闘／観戦割付手段と、
　
前記戦闘モードに移行したゲーム装置から操作入力情報を受信するとともに、当該受信した操作入力情報を、前記参加が許可されたゲーム装置のうち前記操作入力情報を送信したゲーム装置以外のゲーム装置に送信する操作入力情報送受信手段と、
　
前記観戦モードに移行したゲーム装置から送信されたチャット情報を受信するとともに、当該チャット情報を、前記参加が許可されたゲーム装置のうち前記チャット情報を送信したゲーム装置以外のゲーム装置に送信する第１のチャット情報送受信手段と、
　
前記ルールの情報に基づいて前記戦闘モードに移行したゲーム装置の対戦が終了したかどうかを判断する対戦終了判断手段と、
　
を備え、
　
前記参加が許可されたゲーム装置のそれぞれは、
　
前記戦闘モードに移行した場合は、入力された操作入力情報及び前記ゲームサーバシステムから送信される他の前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新する一方、前記観戦モードに移行した場合は、前記ゲームサーバシステムから送信される前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新するゲーム画像更新手段と、
　
前記対戦が開始されてから前記対戦終了判断手段が当該対戦の終了を判断するまで、前記第１のチャット情報送受信手段により送信されるチャット情報を受信するとともに、前記第１のチャット情報送受信手段にチャット情報を送信する第２のチャット情報送受信手段と、
　
前記第２のチャット情報送信手段が前記第１のチャット情報送受信手段から受信した前記チャット情報をプレイヤに認識可能な状態で出力するチャット情報出力手段と、
　
を備える、
　
ゲームシステム
（２）「【００５９】
　次に本発明の好適な実施の形態を、図面を参照して説明する。
（実施形態１）
　本発明の実施形態１は、クライアントシステム間で同一対戦グループを結成し、それに属するクライアントシステムの中から対戦の組み合わせを決定し、勝った方、負けた方、固定した双方またはいずれか一方の固定されたクライアントシステムが継続して他のクライアントシステムと対戦するように構成された通信ゲームシステムに関する。
【００６０】
　図１に本発明の通信ゲームシステムのシステム図を示す。
【００６１】
　本通信ゲームシステムは、図１に示すように、複数のクライアントシステム１が回線網４を介して、ゲームサーバシステム２およびＷＷＷサーバシステム３に接続されて構成されている。
【００６２】
　各クライアントシステム１は、いわゆる通信機能を有するゲーム装置としての構成を備え、ゲーム機本体１０、コントロールパッド１１およびモニタ１２を相互に接続して構成される。
【００６３】
　コントロールパッド１１は、各遊技者の操作に伴って出力される操作信号をゲーム機本体１０に供給するようになっている。ゲーム機本体１０は、通信可能なコンピュータ装置としての構成（ＣＰＵ、メモリ、ＣＤ−ＲＯＭドライブ、モデム、画像生成回路、音声生成回路等）を備えている。当該
ゲーム機本体１０は、ＣＤ−ＲＯＭなどの記録媒体からデータを読み取り可能になっており、記録媒体から読み取ったゲームプログラムを実行することで当該通信ゲームシステムのクライアントシステムとして動作するようになっている
【００６４】
　ゲームサーバシステム２は、ゲームサーバ２０と記憶領域２１とを備える。
【００６５】
　ゲームサーバ２０は、汎用の高性能コンピュータ装置としての構成（ＣＰＵ、メモリ、ＨＤ、通信装置等）を備えている。当該
ゲームサーバ２０は、本発明のゲーム処理方法に対応したプログラムを実行することにより、通信ゲームシステムを管理するゲームサーバシステムとして動作する
【００６６】
　回線網４は、通常の公衆回線または専用線であってゲームネットワーク４０やインターネット４１などのＷＡＮを形成している。
【００６７】
　
ゲームネットワーク４０は、当該通信ゲームシステムの実行のために提供されているネットワーク
ゲームサーバシステム２が管理する特定のアクセスポイントにクライアントシステム１から接続することによって、ゲームサーバシステム２と各クライアントシステム１とにより構成される専用ネットワーク
（３）「【００７１】
　図２に、本通信ゲームシステムの詳しい機能ブロック図を示す。クライアントシステム１（Ａ，Ｂ）において、処理装置１００と通信装置１０１とはゲーム機本体１０に属する。出力データ生成装置１０２とコントロールパッド１１とは、コントロールパッド１１に属する。
【００７２】
　処理装置１００は、ＣＰＵを中心としてゲームプログラムを実施するコンピュータ部分である。処理装置１００は、操作装置１１０からの操作信号の認識、振動発生手段１１１への振動信号の出力、通信装置１０１の通信制御、出力データ生成装置１０２の制御などを行う。通信装置１０１は、例えばモデムやターミナルアダプタであり、ゲームネットワーク４０やインターネット４１と処理装置１００とのデータ送受信を仲介するものである。操作装置１１０は、操作ボタンや十字キーなどゲームの操作に必要な操作機能を備えている。振動発生手段１１１は、例えばピエゾ素子など逆圧電効果により、所定周波数の振動信号に対応させてコントロールパッド１１を操作する遊技者に振動を認識させることが可能になっている。
【００７３】
　ゲームサーバシステム２において、処理装置２００と通信装置２０１とはゲームサーバ２０に属する。記憶領域２１には、ユーザデータベース（以下ＤＢと略する。）２１０、イージーロビーＤＢ２１１、エキスパートロビーＤＢ２１２、ノーマルＤＢ２１３、チーム戦ＤＢ２１４、総当たり戦ＤＢ２１５およびトーナメント戦ＤＢ２１６などが格納されている。」
（４）「【００８０】
　各クライアントシステム１は、プログラムと遊技者による操作信号とに基づいてゲーム処理を進める独立モードと、通信によって提供されたコマンドを中心にゲーム処理を進める通信モードとを使い分けるようになっている。
【００８１】
　いずれの動作モードでも、ゲーム機本体１０は、コントロールパッド１１からの操作信号を解釈してゲーム画面におけるキャラクタ（操作可能なセグメントやモデルのこと）を移動させる。ただし、ゲームにおける敵のキャラクタの動きは、独立モードでは、プログラムによって規定されるのに対し、通信モードでは、ゲームネットワーク４０経由で対戦相手となったクライアントシステム１から送信されるコマンドによって規定される点で異なっている。また通信モードの場合には、ゲーム機本体１０は、操作信号をコマンド化してゲームネットワーク４０に送出する。
【００８２】
　具体的には、図８に示すように、ゲーム機本体１０は、操作信号を読取り（Ｓ５０１）、通信開始を示す操作内容であるか否かを検査する（Ｓ５０２）。通信開始でない場合には（Ｓ５０２：ＮＯ）、独立モードであり、通常のゲーム装置としての処理を続行する（Ｓ５０３）。
【００８３】
　一方、通信開始を示している場合には（Ｓ５０２：ＹＥＳ）、ゲーム機本体１０は、通信モードであるため接続を確立するための一般的手順を実行する。すなわち、ゲーム機本体１０は、予め登録されているサーバを選択し呼び出し、接続後にハンドルネーム、ＩＤ、パスワードなどの必要情報を送信する（Ｓ５０４）。接続できない場合には、処理装置は通常のエラー処理としてその旨表示して復帰する。
【００８４】
　接続確立後、ゲーム機本体１０はメインメニューを表示させる（Ｓ５０５）。ゲーム開始が遊技者から指示されたら、ゲーム機本体１０は、その後はエスケープ等の特別の操作をしない限り復帰しない永久ループ処理を実行する。つまり操作信号が供給された場合に（Ｓ５０６：ＹＥＳ）、ゲーム機本体１０はその操作信号を読み取り（Ｓ５０８）、予め定められたコマンド規約にしたがってコマンド化してゲームネットワーク４０に送出する（Ｓ５０９）。またゲームネットワーク４０からコマンドが送信された場合には（Ｓ５１０：ＹＥＳ）、ゲーム機本体１０はこれを読み取り（Ｓ５１１）、解釈ルーチンに移行する。」
（５）「【００８７】
　クライアントシステム１が戦闘モードに割り付けられている場合には、ゲーム機本体１０は、自分のキャラクタを操作信号に基づいて移動させ、ゲームネットワーク４０から提供される操作コマンドに基づいて敵のキャラクタの位置や態様を変化させる。操作コマンドの割付は、ゲームごとに任意に定めうる。これらの処理により、遊技者は、あたかも一つのゲーム機に二つのコントロールパッド１１を接続して他人と対戦しているかのようにゲーム対戦を実行可能になる。
【００８８】
　クライアントシステム１が
観戦モード
ゲーム対戦をしているのを応援しているかのようなゲーム観戦
（６）「【０１００】
　クライアントシステム１において、遊技者がコントロールパッド１１のスタートボタンを操作すると、その時のモードに対応したスタートメニューＭ１が表示されるようになっている（Ｓ１１：図１１）。
【０１０１】
　このスタートメニューＭ１において「会議室を作る」が選択されると、ゲームサーバ２０は、対戦モードの選択するメニューＭ２を更に表示させる（Ｓ１２：図１２）。このメニューからいずれかの対戦モードを選択すると、それに対応する対戦グループが新規に作成され、その「作戦会議室」が表示されるようになる（Ｓ１３）。
【０１０２】
　選択された対戦モードで作成される「作戦会議室」に新規登録後に１以上のクライアントシステム１が参加してくることによって（Ｓ３０、Ｓ４０、Ｓ５０、Ｓ６０）、一つの対戦グループが形成される。メニューＭ２において、「ノーマル」が選択されると本実施形態の対戦モード、「チーム戦」が選択されると実施形態２、「総当たり」が選択されると実施形態３、「トーナメント」が選択されると実施形態４の各実施形態で説明する作戦会議室、すなわち
対戦グループが作成できる
（６）「【０１１３】
　さて、戦況報告ウィンドウＷ５（Ｓ２０：図１４）において、遊技者により所定の操作（例えば「Ａ」ボタン押下）がされると、当該操作を行ったクライアントシステム１がこの対戦グループに新たに参加したものとして登録される。すなわち、ゲームサーバ２０は、当該クライアントシステム１から選択中の
対戦グループへの参加要求があったものと判断し、この対戦グループに当該クライアントシステム１を新たな参加者として登録する
【０１１４】
　新たに参加する場合に（Ｓ３０）、対戦グループごとにパスワードを設定し、パスワードを入力しなければ参加できないように認証処理を行ってもよい。すなわち新たな対戦グループに参加依頼があった場合に、この参加を希望するクライアントシステム１にパスワード入力を要求し、このパスワードが正しく入力された場合にのみゲームサーバ２０が当該
対戦グループへの参加を許可する
（ノーマル作戦会議室）
　以下では、特に対戦モードとして「ノーマル」が設定されている対戦グループへの対戦管理を説明する。「ノーマル」対戦モードとは、一つの対戦が終了した場合に、勝った方、負けた方、固定した双方またはいずれか一方の固定されたクライアントシステムが継続して他のクライアントシステムと対戦するような試合ルールによる対戦をいう。」
（７）「【０１２８】
　このコマンドにより戦闘モードに入るクライアントシステム１では、ゲーム機本体１０がゲーム対戦画像を表示させ、コントロールパッド１１からの操作信号に対応させて自分のキャラクタを移動させ、その対戦用のデータ（操作コマンド）をゲームネットワーク４０に送信する。ゲームネットワーク４０から敵キャラクタの操作コマンドが送信されたきた場合には、その操作コマンドに対応させて敵キャラクタを移動させるように処理する。ゲームサーバ２０はこの操作コマンドの送受信を仲介する。」
（６）「【０２７２】
　加えて、この観戦モードに割り付けられているクライアントシステム１同士で、
チャットができるため、遊技者は、あたかもアミューズメントセンターで友人がゲーム対戦をしているのを応援しているかのような感覚
（７）上記【００６２】より、「クライアントシステム１」は、請求項１の「ゲーム装置」に対応する。
（８）上記【００６３】より、「ゲーム機本体１０」は、請求項１の「ゲーム装置」に対応する。
（９）上記【００６５】より、プログラムは、ゲームシステムを管理するゲームサーバシステムとして、ゲームサーバを、動作させるものといえる。
（１０）上記【０１１３】及び図１４より、戦闘中に対戦グループへの参加要求があった場合、この対戦グループにクライアントシステム１を新たな参加者として登録するものといえる。
　したがって、上記引用文献１には次の発明（以下、「引用発明１」という。）が記載されていると認められる。
「複数のゲーム装置がゲームサーバシステムを介して通信可能に接続され、前記ゲーム装置間で対戦ゲームを実行するゲームシステムを管理するゲームサーバシステムとして、ゲームサーバを、動作させるプログラムであって、
　ゲームサーバシステムが管理する特定のアクセスポイントにゲーム装置から接続することによって、ゲームサーバシステムと各ゲーム装置とにより構成される専用ネットワークがゲームシステムの実行のために提供され、
　ゲーム装置は、ＣＤ−ＲＯＭなどの記録媒体からデータを読み取り可能になっており、記録媒体から読み取ったゲームプログラムを実行することで当該通信ゲームシステムのゲーム装置として動作するようになっており、
　前記ゲームサーバシステムは、
　前記複数のゲーム装置のうちの一のゲーム装置からの要求に応じて、前記対戦ゲームに関するルールの情報を含んでなるグループ情報に基づき前記対戦ゲームを行うための対戦グループを作成する対戦グループ作成手段と、
　他のゲーム装置から前記対戦グループへの参加の要求があった場合に、当該他のゲーム装置の前記対戦グループへの参加を許可する対戦グループ参加許可手段と、
　前記対戦グループ参加許可手段によって前記対戦グループへの参加が許可されたゲーム装置のうち、所定の条件を充たすゲーム装置を戦闘モードに移行させるとともに、前記所定の条件を充たさないゲーム装置を観戦モードに移行させる戦闘／観戦割付手段と、
　前記戦闘モードに移行したゲーム装置から操作入力情報を受信するとともに、当該受信した操作入力情報を、前記参加が許可されたゲーム装置のうち前記操作入力情報を送信したゲーム装置以外のゲーム装置に送信する操作入力情報送受信手段と、
　前記観戦モードに移行したゲーム装置から送信されたチャット情報を受信するとともに、当該チャット情報を、前記参加が許可されたゲーム装置のうち前記チャット情報を送信したゲーム装置以外のゲーム装置に送信する第１のチャット情報送受信手段と、
　前記ルールの情報に基づいて前記戦闘モードに移行したゲーム装置の対戦が終了したかどうかを判断する対戦終了判断手段と、
　を備え、
　前記参加が許可されたゲーム装置のそれぞれは、
　前記戦闘モードに移行した場合は、入力された操作入力情報及び前記ゲームサーバシステムから送信される他の前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新する一方、前記観戦モードに移行した場合は、前記ゲームサーバシステムから送信される前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新するゲーム画像更新手段と、
　前記対戦が開始されてから前記対戦終了判断手段が当該対戦の終了を判断するまで、前記第１のチャット情報送受信手段により送信されるチャット情報を受信するとともに、前記第１のチャット情報送受信手段にチャット情報を送信する第２のチャット情報送受信手段と、
　前記第２のチャット情報送信手段が前記第１のチャット情報送受信手段から受信した前記チャット情報をプレイヤに認識可能な状態で出力するチャット情報出力手段と、
　を備え、
　戦闘中に対戦グループへの参加要求があった場合、この対戦グループにゲーム装置を新たな参加者として登録し、
　観戦モードは、ゲーム対戦をしているのを応援しているかのようなゲーム観戦を実行可能とする、
　ゲームシステムを管理するゲームサーバシステムとして、ゲームサーバを動作させるプログラム。」
２．引用文献２について
　原査定の拒絶の理由に引用され、本願の優先日前である平成２３年９月２２日に頒布された刊行物である引用文献２（特開２０１１−１８２８１８号公報）には、図面と共に次の事項が記載されている。
（１）「【特許請求の範囲】
【請求項１】
　
互いに情報の送受信可能に接続された複数のゲーム機を含み、
　
前記各ゲーム機は、
　
ユーザの操作を受け付ける操作入力部と、所定の画像を出力する画像出力部と、所定の情報を記憶する記憶部と、自機を、自機のユーザがプレイヤとしてゲームをプレイできる状態にするプレイヤ機能部と、自機を、自機のユーザが見学者として前記ゲームの進行を見学できる状態にする見学者機能部と、前記プレイヤ機能部の機能が有効である状態と無効である状態とを切り替える切替部と、
を備えるゲームシステムであって、
　
前記各ゲーム機の記憶部には、前記複数のゲーム機のそれぞれに関する情報であって、前記各ゲーム機を識別するゲーム機識別情報と、前記プレイヤ機能部が有効に機能しているプレイヤ機、又は前記プレイヤ機能部が有効に機能していない見学者機のいずれであるかを示す機能識別情報とを含むゲーム機情報で構成されるゲーム機リストが記憶され、
　
前記プレイヤ機能部は、
　
前記プレイヤによる前記操作入力部への操作に基づいて前記ゲームを進行し、前記ゲームの進行に応じたゲーム画面を生成して前記画像出力部に出力させるゲーム進行部と、
　
前記見学者機において表示されるゲーム画面を更新するための画面更新情報を生成して、前記ゲーム機リストにある前記各見学者機へ送信する画面更新情報処理部と、を備え、
　
前記見学者機能部は、
　
前記プレイヤ機から前記画面更新情報を取得すると、前記画面更新情報に基づいて、前記画像出力部に出力されているゲーム画面を更新する画面出力処理部を備え、
　
前記切替部は、
　
他のゲーム機をプレイヤ機として設定するための処理を行う切替処理部と、自機をプレイヤ機として設定するための処理を行う切替対応部と、プレイヤ機の切替に応じて前記ゲーム機リストを更新するリスト更新部とを有し、
　
前記切替処理部は、
　
前記ゲームの進行中に、所定の切替条件が満たされると、前記ゲーム機リストにある１つの見学者機を新プレイヤ機として決定し、プレイヤ機の切替を通知する切替通知を前記新プレイヤ機へ送信する切替通知部と、
　
前記切替通知が送信されると前記プレイヤ機能部の機能を無効にする機能無効化部とを備え、
　
前記切替対応部は、
　
前記切替通知が受信されると前記プレイヤ機能部の機能を有効にする機能有効化部と、
　
前記切替通知の発信元のゲーム機に代わって自機がプレイヤ機として機能することを示すべく、前記ゲーム機リストを更新するとともに、その更新内容を示す新プレイヤ機通知を生成して、全ての他のゲーム機へ送信する新プレイヤ機通知部とを備え、
　
前記リスト更新部は、前記新プレイヤ機から新プレイヤ機通知を受信すると、前記新プレイヤ機通知に基づいて、自機の前記ゲーム機リストにおける前記プレイヤ機及び前記見学者機を更新する、ことを特徴とするゲームシステム。
…
【請求項６】
　
前記複数のゲーム機と情報の送受信可能なサーバを更に含み、
　
前記サーバは、
　
前記複数のゲーム機のそれぞれから、システム参加要求を受け付ける参加要求受付部と、
　
前記システム参加要求を受け付けた複数のゲーム機を１つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定した前記ゲーム機リストを生成するゲーム機リスト生成部と、
　
前記ゲーム機リストを含む開始情報を生成して、前記各ゲーム機へ送信する開始情報送信部とを備え、
　
前記各ゲーム機は、
　
前記システム参加要求を前記サーバへ送信する参加要求送信部と、
　
前記システム参加要求を送信後、前記開始情報に含まれるゲーム機リストを前記サーバから取得すると、自機の前記記憶部に記憶すると共に、前記ゲーム機リストに応じて、自
機の前記プレイヤ機能部又は前記見学者機能部の少なくとも一方を有効な状態にする開始処理部を備え、
　
前記ゲーム進行部は前記開始処理部による処理がされた後、前記ゲームを開始する、ことを特徴とする請求項１に記載のゲームシステム
（２）「【００４４】
　図３に戻って、サーバ制御部５４について説明する。サーバ制御部５４は、ＣＰＵ及びその動作に必要な記憶域を備えたコンピュータとして構成されている。サーバ記憶部５２に記憶されたコンピュータプログラムによって、主に、参加要求受付部５４ａ、ゲーム機リスト生成部５４ｂ、及びサーバ更新部５４ｃと、開始情報送信部５４ｅして機能する。参加要求受付部５４ａはゲーム機ＭからのゲームシステムＧＳ１への参加要求を受け付ける。ゲーム機リスト生成部５４ｂは、
所定時間内に参加要求を受け付けたゲーム機Ｍをグループ化し
（３）「【００５５】
　ゲーム機ＭがゲームシステムＧＳ１に参加する際に、サーバＳｖ及びゲーム機Ｍのそれぞれにおいて行われる処理について、図１３のシーケンス図を用いて説明する。サーバＳｖにおける処理はサーバ制御部５４によって制御され、ゲーム機Ｍにおける処理はゲーム機制御部８０によって制御される。まず、各ゲーム機Ｍ１〜Ｍ３からサーバＳｖへ、各ユーザＵ１〜Ｕ３の操作によって参加要求が送信される（ステップＳ１０）。これにより、ゲーム機制御部８０は参加要求送信部８８として機能する。参加要求にはゲーム機識別情報６１やユーザ情報６３が含まれている。
【００５６】
　
ゲーム機Ｍからの参加要求は、サーバＳｖにて受け付けられ、所定時間内に受け付けられた参加要求に対応するゲーム機Ｍはグループ化される
参加要求の受付の早い順に
（４）「【００５８】
　開始処理では、開始情報に含まれるゲーム機リストＭＬを参照して、自機がプレイヤ機Ｍｐである時は、自機をプレイヤ機Ｍｐとして機能させる処理、自機が見学者機Ｍｖである時は、自機を見学者機Ｍｖとして機能させる処理が行われる。具体的には、プレイヤ機Ｍｐに設定されているゲーム機Ｍ１、Ｍ２では、ゲーム機リストＭＬ及び操作認識ソフトＲＳをゲーム機記憶部７２に記憶し、操作認識ソフトＲＳを稼動する。そして、ゲーム進行部８２ａにゲーム開始画面を表示させる。これにより、プレイヤ機Ｍｐでは、ゲームにおいて、プレイヤＵｐの操作に応じたゲームが実行可能となり、プレイヤ機能部８２が有効に機能する、即ち、プレイヤ機として機能するようになる。見学者機Ｍｖに設定されているゲーム機Ｍ３では、ゲーム機リストＭＬがゲーム機記憶部７２が記憶され、画面出力処理部８４ａによって見学者用ゲーム開始画面が出力され、画面更新情報の待ち状態になる。」
　したがって、上記引用文献２には次の発明（以下、「引用発明２」という。）が記載されていると認められる。
「互いに情報の送受信可能に接続された複数のゲーム機を含み、
　前記各ゲーム機は、
　ユーザの操作を受け付ける操作入力部と、所定の画像を出力する画像出力部と、所定の情報を記憶する記憶部と、自機を、自機のユーザがプレイヤとしてゲームをプレイできる状態にするプレイヤ機能部と、自機を、自機のユーザが見学者として前記ゲームの進行を見学できる状態にする見学者機能部と、前記プレイヤ機能部の機能が有効である状態と無効である状態とを切り替える切替部と、
を備えるゲームシステムであって、
　前記各ゲーム機の記憶部には、前記複数のゲーム機のそれぞれに関する情報であって、前記各ゲーム機を識別するゲーム機識別情報と、前記プレイヤ機能部が有効に機能しているプレイヤ機、又は前記プレイヤ機能部が有効に機能していない見学者機のいずれであるかを示す機能識別情報とを含むゲーム機情報で構成されるゲーム機リストが記憶され、
　前記プレイヤ機能部は、
　前記プレイヤによる前記操作入力部への操作に基づいて前記ゲームを進行し、前記ゲームの進行に応じたゲーム画面を生成して前記画像出力部に出力させるゲーム進行部と、
　前記見学者機において表示されるゲーム画面を更新するための画面更新情報を生成して、前記ゲーム機リストにある前記各見学者機へ送信する画面更新情報処理部と、を備え、
　前記見学者機能部は、
　前記プレイヤ機から前記画面更新情報を取得すると、前記画面更新情報に基づいて、前記画像出力部に出力されているゲーム画面を更新する画面出力処理部を備え、
　前記切替部は、
　他のゲーム機をプレイヤ機として設定するための処理を行う切替処理部と、自機をプレイヤ機として設定するための処理を行う切替対応部と、プレイヤ機の切替に応じて前記ゲーム機リストを更新するリスト更新部とを有し、
　前記切替処理部は、
　前記ゲームの進行中に、所定の切替条件が満たされると、前記ゲーム機リストにある１つの見学者機を新プレイヤ機として決定し、プレイヤ機の切替を通知する切替通知を前記新プレイヤ機へ送信する切替通知部と、
　前記切替通知が送信されると前記プレイヤ機能部の機能を無効にする機能無効化部とを備え、
　前記切替対応部は、
　前記切替通知が受信されると前記プレイヤ機能部の機能を有効にする機能有効化部と、
　前記切替通知の発信元のゲーム機に代わって自機がプレイヤ機として機能することを示すべく、前記ゲーム機リストを更新するとともに、その更新内容を示す新プレイヤ機通知を生成して、全ての他のゲーム機へ送信する新プレイヤ機通知部とを備え、
　前記リスト更新部は、前記新プレイヤ機から新プレイヤ機通知を受信すると、前記新プレイヤ機通知に基づいて、自機の前記ゲーム機リストにおける前記プレイヤ機及び前記見学者機を更新し、
　前記複数のゲーム機と情報の送受信可能なサーバを更に含み、
　前記サーバは、
　前記複数のゲーム機のそれぞれから、システム参加要求を受け付ける参加要求受付部と、
　前記システム参加要求を所定時間内に受け付けられた複数のゲーム機を１つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、参加要求の受付の早い順に前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定した前記ゲーム機リストを生成するゲーム機リスト生成部と、
　前記ゲーム機リストを含む開始情報を生成して、前記各ゲーム機へ送信する開始情報送信部とを備え、
　前記各ゲーム機は、
　前記システム参加要求を前記サーバへ送信する参加要求送信部と、
　前記システム参加要求を送信後、前記開始情報に含まれるゲーム機リストを前記サーバから取得すると、自機の前記記憶部に記憶すると共に、前記ゲーム機リストに応じて、自機の前記プレイヤ機能部又は前記見学者機能部の少なくとも一方を有効な状態にする開始処理部を備え、
　前記ゲーム進行部は前記開始処理部による処理がされた後、前記ゲームを開始する、ゲームシステム。」
３．引用文献３について
　第１回当審拒絶理由通知に引用され、本願の優先日前である平成２4年９月２０日に頒布された刊行物である引用文献３（特開２０１２−１８２７４４号公報）には、図面と共に次の事項が記載されている。
（１）「【特許請求の範囲】
…
【請求項２】
　原稿を光学的に読み取って読取画像からなるスキャンデータを生成する光学読取部と、上記スキャンデータを保持するサーバ記憶部とを有するサーバ装置に通信ネットワークを介して接続されたクライアント端末装置において、
　ハイパーテキスト転送プロトコルから双方向プロトコルへ通信プロトコルを変更させるためのプロトコル変更要求を生成するプロトコル変更要求生成部と、
　上記プロトコル変更要求を上記サーバ装置へ送信し、上記サーバ装置が上記プロトコル変更要求に対する応答として送信するプロトコル変更応答に基づいて、通信プロトコルを上記双方向プロトコルへ変更する端末通信部と、
　上記双方向プロトコルへ移行した後、新たに上記スキャンデータが上記サーバ記憶部内に格納されるごとに上記サーバ装置が送信するスキャンデータを保持する端末記憶部とを備えたことを特徴とするクライアント端末装置。
…
【請求項５】
　上記双方向プロトコルが、上記サーバ装置及び上記クライアント端末装置のいずれも、状態確認のための状態確認要求を送信することができるウェブソケットプロトコルであることを特徴とする請求項２〜４のいずれかに記載のクライアント端末装置。」
（２）「【技術分野】
【０００１】
　本発明は、原稿読取システム、クライアント端末装置及びコンピュータプログラムに係り、さらに詳しくは、画像データの入出力を行うサーバ装置と、通信ネットワークを介してサーバ装置に接続されたクライアント端末装置とからなる原稿読取システムに関する。
【背景技術】
【０００２】
　スキャナとＰＣ（パーソナルコンピュータ）とがネットワーク接続され、ＨＴＴＰ（HyperText Transfer Protocol：ハイパーテキスト転送プロトコル）に基づいて通信を行うシステムでは、スキャナ及びＰＣがそれぞれサーバ装置及びクライアント端末装置として機能する。例えば、スキャナが原稿から読み取ったスキャンデータをＰＣが取得する場合、まず、ＰＣからスキャナへ画像送信要求が送信される。スキャンデータは、この画像送信要求に対する応答として、スキャナからＰＣへ送信される（例えば、特許文献１〜３）。
【０００３】
　この様な従来の原稿読取システムにおいて、ＰＣがスキャナからスキャンデータを取得する具体的な方法には、スキャンボックスを利用するスキャンボックス方式と、ＰＣからの指示によって読取処理を開始させるリアルタイムスキャン方式がある。スキャンボックスは、読取画像からなるスキャンデータを格納するための記憶領域からなり、任意に作成することができる。スキャンボックス方式の場合、原稿を収容部内に配置し、スキャンデータの格納先を指定して読取開始を指示すれば、読取処理が開始され、スキャンデータが対応するスキャンボックス内に格納される。ＰＣでは、スキャンボックスを指定した読込指示を入力することにより、スキャナドライバにスキャンボックス内のスキャンデータを取得させることができる。
【０００４】
　リアルタイムスキャン方式の場合には、スキャンモードへ切り替え、原稿を収容部内に配置する。ＰＣでは、スキャンボックスを指定した読込指示により、スキャナドライバが、スキャンデータを取得するための画像送信要求をスキャナへ送信する。スキャナは、この画像送信要求に基づいて、読取処理を開始し、スキャンデータをＰＣへ送信する。上述したいずれの方式であっても、ＰＣからスキャナ内のスキャンデータを取得することができるが、使い勝手が良くないという課題があった。すなわち、スキャンボックス方式では、ＰＣにおける読込指示に先立って取得対象のスキャンデータをスキャンボックス内に格納しておく必要がある。このため、例えば、読込指示後に新たに原稿を読み取らせる場合、当該原稿を読み取らせた後、再度ＰＣ上において読込指示を入力しなければならず、操作手順が複雑であった。
【０００５】
　一方、リアルタイムスキャン方式では、ＰＣにおける読込指示に先立って読取対象の原稿を収容部内に配置しておく必要がある。このため、連続読取が不可能な原稿群、例えば、複数のページからなる冊子を読み取らせる場合に、原稿の配置と読込指示とを繰り返さなければならず、操作手順が複雑であった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０００−１１２５９４号公報
【特許文献２】特開２００８−１７２２８８号公報
【特許文献３】特開２００５−２７５６１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
　本発明は、上記事情に鑑みてなされたものであり、クライアント端末装置からサーバ装置内のスキャンデータを取得する際の使い勝手を向上させた原稿読取システムを提供することを目的としている。
【０００８】
　特に、新たに格納されたスキャンデータをサーバ装置から自動的に取得することができるクライアント端末装置を提供することを目的としている。また、連続読取が不可能な原稿群を読み取らせる場合の操作性を向上させることができるクライアント端末装置を提供することを目的としている。
【０００９】
　また、本発明は、その様なクライアント端末装置において実行されるコンピュータプログラムを提供することを目的とする。」
４．引用文献４について
　第１回当審拒絶理由通知に引用され、本願の優先日前である平成２４年１０月２２日に頒布された刊行物である引用文献４（特表２０１２−５２５６５９号公報）には、図面と共に次の事項が記載されている。
（１）「【特許請求の範囲】
…
【請求項８】
　分散ウェブアプリケーションの実行をサポートするサーバーシステムであって、
　ａ）ネットワークに結合されたソース起点サーバーシステムであって、これは、クライアント側ウェブアプリケーションを含み、そしてソース起点の範囲内で前記ネットワークを通してアクセスできるソース起点サーバーシステムと、
　ｂ）前記ネットワークに結合されたゲートウェイサーバーシステムであって、これは、通信ブリッジプログラムを含み、ターゲット起点の範囲内で前記ネットワークを通してアクセスでき、そしてウェブアプリケーションサービスへネットワーク接続を与えるように動作するゲートウェイサーバーシステムと、
　ｃ）前記ネットワークに結合されたクライアントシステムであって、これは、ウェブブラウザクライアントを実行するように動作でき、前記ウェブブラウザクライアントは、クロス起点メッセージを除外するｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントであり、前記ウェブブラウザクライアントは、前記クライアント側ウェブアプリケーションを前記ソース起点サーバーシステムダウンロードするように働き、更に、前記ウェブブラウザクライアントは、前記ソース起点の範囲内で前記クライアントシステム上の前記クライアント側ウェブアプリケーションを実行するように動作し、前記ウェブブラウザクライアントは、前記通信ブリッジプログラムを前記ゲートウェイサーバーシステムダウンロードするように動作し、前記ウェブブラウザクライアントは、更に、前記ターゲット起点の範囲内で前記クライアントシステム上の前記通信ブリッジプログラムを実行するように動作し、前記クライアント側ウェブアプリケーション及び前記通信ブリッジプログラムは、クロス起点通信チャンネルを具現化し、前記クライアント側ウェブアプリケーションは、更に、前記通信ブリッジプログラム及び前記ゲートウェイサーバーシステムを通して前記ウェブアプリケーションサービスクロス起点の要求を発行するように動作するようなクライアントシステムと、
を備えたサーバーシステム。
…
【請求項１１】
　前記クロス起点通信チャンネルは、シルバーライトランタイムライブラリを使用し、前記通信ブリッジプログラムは、前記ゲートウェイサーバーシステムによるクロス起点通信チャンネルの確認を可能にするソース起点を識別するエンコードされたヘッダデータでウェブソケット要求をエンコードするよう動作する、請求項８に記載のサーバーシステム。」
（２）「【技術分野】
【０００１】
　本発明は、一般に、ネットワーク通信システムに係り、より詳細には、ＨＴＴＰベースのネットワークを経てリアルタイム両方向性通信をサポートすることのできる企業クラスのクライアント／サーバーシステムに係る。
【０００２】
　本発明は、２００９年５月１日に出願された米国仮特許出願第６１／１７４，９２３号の利益を請求する。
【背景技術】
【０００３】
　ウェブアプリケーションの開発及び使用は、成長を続けているが、広く使用されているＨＴＴＰプロトコルが半二重通信しかサポートしないという点で著しい制約が存在する。従来のクライアント／サーバーアプリケーション使用モデルの場合のように、クライアントが種々のバックエンドシステムと対話できることが要求されない場合には、連続的なティア・ツー・ティア両方向又は全二重通信接続が強く望まれる。リアルタイム株フィードを表示し、アドホック情報更新を許し、特に、入札、チャット、ゲーム、及び他のアプリケーションで遭遇するリアルタイムオペレーションにおいて複数のユーザ間に能動的に参加できるようにする、等のウェブ上でのリアルタイムサービスの需要が重要になり増加している。
【０００４】
　所有権クライアント及びサーバーアプリケーションによってサポートされる他のプロトコルを利用することはできるは、ウェブブラウザクライアントが偏在するという事実は、実際上、基本的ＨＴＴＰプロトコルの使用を要求する。本来的に、従来のウェブブラウザベースのクライアントアプリケーションは、データ要求及び応答が一度に一方向にしか流れない通信に基本的に制約されている。両方向通信をエミュレートする従来の試みは、典型的に、コメット・アンド・リバース・アジャック(Comet and Reverse Ajax)において具現化されるようなポーリング技術の使用を含む。本質的に、サーバーは、選択環境のもとで、クライアントへ情報をプッシュすることができる。しかしながら、これらの技術は、標準化の欠如、不充分な性能、及び限定された拡張性のような多数の制限で悩まされている。
【０００５】
　例えば、直接的なポーリング技術は、ＨＴＴＰ要求を規則的なインターバルでターゲットウェブサーバーへ繰り返し送信するためにウェブブラウザに関連して典型的に具現化されるクライアントアプリケーションを要求する。各要求は、サーバーが更新情報を有するかどうかに基づいて更新されたリアルタイム情報を潜在的に返送するサーバー発生応答を即座に受け取る。ポーリングインターバルに基づいて、受け取られる情報は、実際には、リアルタイムで受け取られず、逆に、応答情報がない場合にサーバー要求の高いオーバーヘッドを頻繁に受けて、得ることしかできない。このオーバーヘッドは、クライアント及びサーバーの両性能に影響を及ぼし、ネットワーク帯域巾を消費する。
【０００６】
　直接的ポーリングのオーバーヘッドを回避するために、ロングポーリングとして知られたバリアントが開発された。非同期ポーリングとしても知られているロングポーリングでは、この場合も典型的にウェブブラウザであるクライアントアプリケーションは、ターゲットウェブサーバーシステムに要求を発行する。即座の応答を与えるのではなく、ターゲットサーバーは、ある定義されたインターバルまで遅延し、ある新たな情報が応答として与えられるのを待機する。ある新たな、即ちリアルタイムのデータが遅延インターバル中にサーバーにより得られる場合には、リアルタイム情報を含むサーバー応答がクライアントへ送られる。新たな情報が受け取られない場合には、空き応答がクライアントアプリケーションに返送され、未決要求を終了させる。従って、ロングポーリングは、リアルタイムデータの配布の待ち時間を短縮する潜在性があり、要求／応答サイクルの数をある程度減少することができる。しかしながら、ロングポーリングは、依然として著しい数の要求／応答サイクルが必要とされ、且つ同様の数のＨＴＴＰヘッダがロングポーリング及びポーリングの両方に存在してクライアントとサーバーとの間で交換しなければならないために、慣習的なポーリングに勝る実質的な性能改善を与えない。
【０００７】
　ストリーミングは、別の従来の変形例である。ストリーミングが使用される場合には、クライアントウェブブラウザが完全な要求を送信するが、ターゲットサーバーは、少なくともある定義されたインターバル中に接続をオープンに維持できるように応答する。実際に、ターゲットサーバーは、応答が完了したという確認を延期する。これは、ターゲットサーバーが、そのターゲットサーバーによって受け取られる付加的なリアルタイム情報で応答を続けられるようにする。ストリーミング接続を確立する利益は、クライアント及びサーバーシステムの一部分においてオーバーヘッドを減少することである。ネットワークトラフィックも減少される。というのは、クライアント及びサーバーシステムは、ストリーミング接続を確立するのにＨＴＴＰヘッダパケットを一度しか送信しないからである。応答継続ネットワークパケットは、必要に応じて送信されるだけであり、従って、データしか含まず、ひいては、最小のオーバーヘッドしか課さない。不都合にも、ストリーミングは、ＨＴＴＰでカプセル化され、従って、低レベルＨＴＴＰ転送がネットワーク全般を通してどのようにルーティングされるかに完全に依存する。それ故、ストリーミングは、所与の接続がルーティングされる無数のシステムによって全体的に決定される予想不能な接続／切断及び実質的なバッファリング待ち時間を受ける。それ故、従来のストリーミングは、信頼できない。
【０００８】
　或いは又、提案されているＨＴＭＬ５ドラフト仕様は、ウェブソケット、サーバー送信イベント(Server-Sent Event)、及びそれに関連したアクセスセキュリティ要求を含む新たなプロトコル特徴を、ＨＴＴＰプロトコルを使用して信頼性ある両方向性通信を可能にする手段として定義している。ＨＴＭＬ５仕様は、他の中でも全二重直接ＴＣＰ通信を標準化するよう意図されているが、最終的な仕様は、公式に採用されるのに、数年でなくても、おそらく、１年はかかる。次世代のウェブブラウザへの機能的合体及び動作的に均一の採用は、おそらく、数年は行われないであろう。更に、実用性、ビジネス及び他の制約のために既存のインプレースウェブブラウザの更新に対する抵抗もあり、おそらく、大規模な採用が数年以上阻止されるであろう。」
５．引用文献５について
　第１回当審拒絶理由通知に引用され、本願の優先日前である平成24年11月12日に頒布された刊行物である引用文献５（特表２０１２−５２８４１１号公報）には、図面と共に次の事項が記載されている。
（１）「【特許請求の範囲】
【請求項１】
　非ＨＴＴＰ通信プロトコルを用いるウエブアプリケーションのために状態に依存しない安全性管理を提供するコンピュータで実行される方法であって、
　ａ）クライアントシステム上でウエブブラウザクライアント内において実行されるクライアントアプリケーションから、通信プロトコル識別子により特定され、リモートウエブサービスへ向けられるウエブソケット接続を開始する第１の開始ステップを含み、前記第１の開始ステップは、
　　i)前記通信プロトコル識別子に対応する安全なトークンが前記クライアントアプリケーションに対応するローカル記憶部内に存在していない場合、前記ウエブブラウザクライアントのユーザへ向けて認証チャレンジを実行するステップであって、第１のユーザ信用証明を取得し、前記第１のユーザ信用証明をゲートウェイサーバーへ送信し、前記安全なトークンを前記ゲートウェイサーバーから受信し、前記安全なトークンを前記ローカルストアインスタンス内に記憶する前記認証チャレンジを実行するステップと、
　　ii)前記安全なトークンを前記ローカル記憶部から取得するステップと、
　　iii)前記通信プロトコルの識別子専用プロトコルであり、且つ、前記安全なトークンを含む第１の接続メッセージを前記ゲートウェイサーバーへ送信する送信ステップと、を含み、
　ｂ）前記第１の接続メッセージの受信に応答して、前記リモートウエブサービスへ向けられるウエブソケット接続を前記ゲートウェイサーバーから開始する第２の開始ステップをさらに含み、前記第２の開始ステップは、
　　i)前記安全なトークンを特定するために前記第１の接続メッセージを検査するステップと、
　　ii)第２のユーザ信用証明を取得するために前記安全なトークンを評価するステップと、
　　iii)前記安全なトークンを置き換える時に、前記第１の接続メッセージに対応する第２の接続メッセージ内へ前記第２のユーザ信用証明を挿入するステップと、
　　iv)前記第２の接続メッセージを前記リモートウエブサービスへ送信するステップと、
を含むことを特徴とするコンピュータで実行される方法。」
（２）「【技術分野】
【０００１】
〔関連出願との相互参照〕
　本出願は、２００９年５月２８日出願の米国仮出願第６１／１８１，９２４号の利益を主張するものである。
【０００２】
　本発明は一般に、非ＨＴＴＰプロトコルを用いて通信を行うウエブアプリケーションクライアントとサーバーとの間で安全性の保証された接続を確立することに関し、特に、非ＨＴＴＰ通信プロトコルを用いるリモートサーバーベースのウエブサービスと接続するウエブブラウザベースのウエブアプリケーションクライアントに対してサポートを行う、ゲートウェイサーバー介在安全性認証及び信用証明管理システムに関する。
【背景技術】
【０００３】
　ウエブベース技術の現在進行中の開発の実質的な態様は、分散化され、ネットワーク化されたアプリケーションに対するサポートを増加させることに向けられている。この努力が、ウエブブラウザベースのクライアントアプリケーションと、このウエブブラウザベースのクライアントアプリケーションに対して遠隔地に配置されているサーバーシステム上で提供されるウエブサービスとの間で双方向データ送信を行うための、接続用のベースとして、ＷｅｂＳｏｃｋｅｔｓ（ウエブソケット）の開発をもたらした。
【０００４】
　分散化されたネットワークアプリケーションは、通常、対応するサービスアプリケーションを実行するサーバーシステムとの永続的な双方向接続を通じて理想的に通信を行う専用アプリケーションを、クライアントが実行するようになった、クライアントサーバーモデルを用いるものとして構成される。接続の初期化中に認証のための信用証明がクライアントから供給される。この認証は、クライアントアプリケーションが、接続を解除するか又は他の方法で遮断するまで持続する。接続が作動可能な状態にある間は、クライアントとサーバーは、提供するサービス及び交換されるデータの性質にとって最も適切なプロトコルを用いて通信を行う。
【０００５】
　しかし、従来のウエブブラウザクライアントは、ページ及びＨＴＴＰプロトコル向けのものである。設計上、従来のウエブブラウザは、クライアントが１つのページから別のページへ移行するときは常に、既存のローカル状態を破棄する。何らかの関連を有する認証データを含む接続が、文書又はページ向けのローカル状態として保持される。したがって、ページ移行の自然の結果として、現行の接続が終了することになる。従来のウエブブラウザのクライアントにより、非ページ状態データをクッキーとして記憶することもできる。これらのクッキーは、サーバーシステムにより割り当てられ、これらのクッキーを操作して、サーバー定義セッションの持続のために必要となる認証済み接続の自律的復元を可能にする情報を記憶することが可能である。このようにしてセッションクッキーにアクセスし、操作することは、従来のウエブブラウザクライアントによって本来的にサポートされているＨＴＴＰプロトコルの使用に、事実上限定される。ウエブソケットのプロトコルは、ウエブソケット接続が確立される最初の接続段階中に通常のＨＴＴＰクッキーの送信を可能にするものではあるが、ウエブソケットの接続上でホストされるさらに高レベルのプロトコルは、これらのクッキーにアクセスしたり、該クッキーを使用したりすることはできない。
【０００６】
　したがって、ウエブブラウザクライアントの通常の動作上の性質に適応する状態を安全確実な形で機能的に維持しながら、ウエブブラウザクライアントとサーバーアプリケーションの間でウエブソケット接続及び他の非ＨＴＴＰプロトコル接続を利用できるようにするシステム及び方法に対する必要性が存在する。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
　従って、本発明の一般的目的は、ウエブブラウザクライアントが、ウエブソケット接続及びその他の非ＨＴＴＰプロトコル接続に関係する状態情報を安全確実に確立し、管理することを可能にするシステム及び方法を提供することである。
【０００８】
　本発明においては、上記目的は、クライアントシステム及びリモートサーバーシステムと相互に動作して、分散化されたウエブアプリケーションに対する状態非依存型安全性管理を行うゲートウェイサーバーを提供することによって達成される。クライアントシステム上のウエブクライアントアプリケーションは、該クライアントアプリケーションに対応するローカル記憶個所内に安全管理されたトークンが存在しないウエブブラウザクライアントのユーザに向けて、認証問合せを行って、安全管理されたトークンを取得し、次いで、ゲートウエイサーバーとの間でユーザ信用証明を交換する。次いで、この安全管理されたトークンは、プロトコル専用接続メッセージの中に含めてゲートウェイサーバーへ送信される。該ゲートウェイサーバーは、この接続メッセージの受信に応答して、該接続メッセージを検査することにより、リモートウエブサービスに向けられたウエブソケット接続を開始して、安全管理されたトークンを回復し、この安全管理されたトークンを評価して、ユーザ信用証明を取得し、このユーザ信用証明を安全管理されたトークンに導入し、該接続メッセージをリモートウエブサービスへ送信する。」
（３）「【００３９】
　本発明の好ましい実施形態においては、安全なトークンがゲートウェイアプリケーション１２６に送信されるように、接続メッセージ１３４が修正される。この接続メッセージは、典型的にはプロトコル専用データパケットとして実現され、本来的にはクリアテキスト内にユーザ信用証明を記憶するものとされている、定義済みユーザ名フィールドとパスワードフィールドとを含む。接続メッセージは、ユーザ信用証明の代わりに、トークンマーカー及び安全なトークンを記憶するように、修正することが好ましい。ＳＴＯＭＰ接続メッセージの場合には、このトークンマーカー及び安全なトークンは、接続データパケットのパスワードフィールド内に記憶される。トークンマーカーは、認証制御プロセッサ９０に知られており、修正されたプロトコルパケットの特定に用いられる「マジックナンバー」であることが好ましい。トークンの記憶とセッションの記憶のための安全なトークンの種類を区別するためには、異なるトークンマーカーが利用される。
【００４０】
　セッションを記憶する実施形態では、接続１３４は、ＨＴＴＰ接続として開始され、これによって、適用可能なセッションクッキーの、ゲートウェイサーバー３８への自動転送がもたらされる。次いで、ＨＴＴＰ接続は、ウエブソケット接続へグレードアップされる。接続メッセージは、ウエブソケット接続が確立されたときに転送される。従って、トークンを記憶する実施形態の場合には、安全なトークン内に埋め込まれ、次いで暗号化されることになるユーザ信用証明が、接続メッセージに直接含まれることになる。セッションを記憶する実施形態では、接続メッセージ内に埋め込まれた安全なトークンは、認証制御プロセッサ９０が、ＨＴＴＰプロトコルから配信されたセッションクッキーをウエブソケット接続メッセージに一意に関連付けることを可能にする、セッションクッキーへの安全な参照を含む。」
６．引用文献６について
　前置報告書で引用され、本願の優先日前である平成21年9月１０日に頒布された刊行物である引用文献６（特開２００９−２０１８５４号公報）には、図面と共に次の事項が記載されている。
（１）「【０１１６】
　本実施形態に適用されるオンラインゲームにおいては、図１４に示すように、
「ランド」と呼称される複数の大グループが設けられている。プレイヤは、複数の「ランド」の中から任意の「ランド」を選択することにより、オンラインゲームに参加することができる
【０１１７】
　各「ランド」は、「エリア」と呼称される複数の区域が設けられており、各「エリア」は、プレイヤのゲームレベルに応じて選択可能か否かが予め決められている。各「エリア」には、「グループ」と呼称される複数の仮想的な部屋が設けられており、プレイヤがその分身となるプレイヤキャラクタをいずれかの「グループ」に入室させることにより、同一の「グループ」に入室している、他のゲーム装置で操作される他のプレイヤキャラクタとともに、モンスター等を討伐することができるようになっている。
【０１１８】
　上述したプレイヤキャラクタを描画させるための２つのベーステクスチャを特定する情報と混合率αとは、同一の「グループ」に入室したプレイヤが操作する各ゲーム装置に相互に送られ、各ゲーム装置において同一の「グループ」に入室しているプレイヤが操作するそれぞれのプレイヤキャラクタが表示される。」
　したがって、上記引用文献６には次の発明（以下、「引用発明６」という。）が記載されていると認められる。
「プレイヤは、複数の「ランド」と呼称される複数の大グループの中から任意の「ランド」を選択することにより、参加することができる、オンラインゲーム。」
第６　対比・判断
１．本願発明１について
（１）対比（その１）
　本願発明１と引用発明１とを対比すると、
　後者の「複数のゲーム装置」と、前者の「複数の携帯端末」とは、「複数の端末」との概念で共通する。
　後者の「ゲーム」、「ゲームサーバ」、「対戦」、「対戦グループへの参加の要求」及び「プログラム」は、それぞれ、前者の「ゲーム」、「サーバ装置」、「対戦」、「ゲームにおける対戦に参加するための第１の要求」及び「プログラム」に相当する。
　後者の「ゲームサーバシステムが管理する特定のアクセスポイントにゲーム装置から接続すること」は、前者の「サーバ装置に対して送信した携帯端末との接続を確立する第１ステップ」に相当する。そして、前記携帯端末には、「第１の携帯端末」及び「第２の携帯端末」が包含される。
　後者の「観戦モード」は、「ゲーム対戦をしているのを応援しているかのようなゲーム観戦を実行可能とする」ものであるから、後者の「ゲーム装置を観戦モードに移行させる観戦割付手段」を備える「ゲームサーバシステムとして、ゲームサーバを、動作させるプログラム」は、前者の「対戦の応援に参加する端末との接続を確立する第２ステップ」を有しているといえる。
　後者の「ゲームサーバシステム」は、「他のゲーム装置から前記対戦グループへの参加の要求があった場合に、当該他のゲーム装置の前記対戦グループへの参加を許可する対戦グループ参加許可手段」を備え、「戦闘中に対戦グループへの参加要求があった場合、この対戦グループにゲーム装置を新たな参加者として登録」するものであるから、前記「ゲームサーバシステム」を動作させる後者の「プログラム」は、前者の「所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、対戦が行われる間の１つのグループとして前記対戦に参加させる第３ステップ」を有しているといえる。
　後者の「戦闘モードに移行したゲーム装置から操作入力情報を受信するとともに、当該受信した操作入力情報を、前記参加が許可されたゲーム装置のうち前記操作入力情報を送信したゲーム装置以外のゲーム装置に送信する」ことは、前者の「対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、前記対戦に参加している他のユーザの第１の携帯端末に送信する」第４ステップに相当する。
　したがって、両者は、
「複数の端末と、
　サーバ装置に、
　ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をそれぞれ確立する第１ステップと、
　前記対戦の応援に参加する端末との接続を確立する第２ステップと、
　所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の１つのグループとして前記対戦に参加させる第３ステップと、
　前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４ステップと
を実行させるプログラム。」
の点で一致し、以下の点で相違する。
［相違点１］
　本願発明１が、複数の「携帯」端末に「ゲームを提供する」サーバ装置であるのに対し、引用発明１のゲームサーバは、そのようなものでない点。
［相違点２］
　本願発明１が、サーバ装置と携帯端末との接続を「ウェブソケットの通信規格」に従ってそれぞれ確立するのに対し、引用発明１は、そのような通信規格でない点。
［相違点３］
　本願発明１が、「第１の要求を対戦の開始後にサーバ装置に対して送信した携帯端末との接続を確立しない」第１ステップを有しているのに対し、引用発明１は、そのようなステップを有していない点。
［相違点４］
　本願発明１が「前記対戦を指定した」応援に参加する「ための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯」端末とも接続を確立する第２ステップを有しているのに対し、引用発明１は、所定の条件を充たさないゲーム装置を観戦モードに移行させる観戦割付手段を備え、観戦モードに移行したゲーム装置からチャット情報を受信するものである点
［相違点５］
　本願発明１が「前記第１ステップにおいて前記対戦の開始までの」所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の「一時的な」１つのグループとして前記対戦に参加させる第３ステップを有しているのに対し、引用発明１は、戦闘中に対戦グループへの参加要求があった場合、この対戦グループにゲーム装置を新たな参加者として登録するものである点。
（２）相違点についての判断
　上記相違点４について、以下、検討する。
　引用発明２は、「複数のゲーム機のそれぞれから、システム参加要求を受け付け」、「システム参加要求を受け付けた複数のゲーム機を１つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、参加要求の受付の早い順に前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定」するものであって、「見学者機」は、「ゲームの進行を見学できる状態」であるから、本願発明１の「応援」と、引用発明２の「ゲームの進行を見学できる状態」とは、ゲームに参加しているものの、対戦には参加していないとの概念で共通する。
　しかし、引用発明２は、「システム参加要求を受け付けた複数のゲーム機を１つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、参加要求の受付の早い順に前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定」するものであって、参加要求の受付が早ければプレイヤ機として設定され、プレイヤ機として設定されなかったゲーム機が、結果として、見学者機として設定されるものであるから、引用発明２の「システム参加要求」は、プレイヤ機として設定されることを目的とするものであって、上記相違点４に係る本願発明１の「対戦を指定した応援に参加するための第２の要求」とは相違するものである。
　また、上記引用文献３乃至引用文献５より、ウェッブソケットの通信規格が周知の技術手段とはいえるものの、上記相違点４に係る本願発明１の「対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信」することは、引用文献３乃至引用文献６のいずれにも示されていないし、設計的事項といえる理由もない。
　そして、本願発明１は、上記相違点４に係る本願発明１の発明特定事項により、「バトルに参加するユーザに限らず、バトルに参加するユーザを応援したいユーザにとっても、同様の理由により、多数のユーザが応援に参加可能なレイドバトルゲームの実現が困難となっている。
　本発明の第４の実施形態では、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、多数のユーザがバトル及び応援に参加可能なバトルゲームを実現し得るゲーム制御方法を提供する。」（【０１６７】〜【０１６８】参照。）という作用効果を奏するものである。
　したがって、本願発明１は、引用文献１乃至引用文献６に基づいて、当業者が容易に発明をすることができたものとすることはできない。
２．本願発明２乃至１２について
　本願発明２乃至１０は、本願発明１の発明特定事項にさらなる発明特定事項を追加して限定を付したものであるから、本願発明２乃至１０は、上記１．（２）と同様の理由により、引用文献１乃至引用文献６に基づいて、当業者が容易に発明をすることができたものとすることはできない。
　また、本願発明１１は、本願発明１に対応するサーバ装置の発明であり、本願発明１２は、本願発明１に対応するゲーム制御方法の発明であるから、本願発明１１及び１２は、上記１．（２）と同様の理由により、引用文献１乃至引用文献６に基づいて、当業者が容易に発明をすることができたものとすることはできない。
第７　原査定についての判断
　平成３０年８月１０日付けの補正により、補正後の請求項１乃至請求項１０、１２は「対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップ」という技術的事項を有し、また、請求項１１は「対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２手段」という技術的事項を有するものとなった。
　当該「対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップ」または「対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２手段」は、原査定における引用文献１及び２には記載されておらず、本願の優先日前における周知技術でもないので、本願発明１乃至１２は、当業者であっても、原査定における引用文献１及び２に基づいて容易に発明できたものとすることはできない
。
　したがって、原査定を維持することはできない。
第８　当審拒絶理由について
１．特許法第３６条第６項第１号について
　当審では、請求項１〜１２に係る発明は、“通信規格は、ウェブソケットの通信規格”であることが特定されていないから、発明の課題を解決する手段が不明であるとの拒絶の理由を通知しているが、平成３０年６月２０日付けの補正において、請求項１、１１及び１２に「ウェブソケットの通信規格に従って」と補正された結果、この拒絶の理由は解消した。
２．特許法第３６条第６項第２号について
（１）当審では、請求項１、１２の「第２の携帯端末から受け付けるステップ」、及び請求項１１の「第２の携帯端末から受け付ける手段」の技術的内容が不明であるとの拒絶の理由を通知しているが、平成３０年８月１０日付けの補正において、請求項１及び１２に「前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップ」と、請求項１１に「前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２手段」と補正された結果、この拒絶の理由は解消した。
（２）当審では、請求項１、１２の各「ステップ」と、前記各「ステップ」を引用する「ステップ」との関係、及び請求項１１の各「手段」と、前記各「手段」を引用する「手段」との関係の技術的内容が不明であるとの拒絶の理由を通知しているが、平成３０年８月１０日付けの補正において、請求項１及び１２に「第１ステップ」、「第２ステップ」及び「第３ステップ」と、請求項１１に「第１手段」、「第２手段」及び「第３手段」と補正された結果、この拒絶の理由は解消した。
第９　むすび
　以上のとおり、原査定の理由によって、本願を拒絶することはできない。
　他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。