ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 A63F 審判 査定不服 2項進歩性 取り消して特許、登録 A63F |
---|---|
管理番号 | 1345435 |
審判番号 | 不服2017-11714 |
総通号数 | 228 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2018-12-28 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2017-08-04 |
確定日 | 2018-11-13 |
事件の表示 | 特願2015-130310「プログラム、サーバ装置、及びゲーム制御方法」拒絶査定不服審判事件〔平成27年12月17日出願公開、特開2015-226792、請求項の数(12)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は、平成25年12月20日(優先権主張平成24年12月21日)に出願した特願2014-531024号の一部を平成27年6月29日に新たな特許出願としたものであって、平成28年10月20日付けで手続補正がされ、同年12月7日付けで拒絶理由通知がされ、平成29年2月14日付けで手続補正がなされ、同年5月8日付けで拒絶査定(原査定)がされ、これに対し、同年8月4日付けで拒絶査定不服審判の請求がなされると同時に手続補正書がされ、同年8月24日付けで前置報告がされ、平成30年4月17日付けで拒絶理由通知(以下、「第1回当審拒絶理由通知」という。)がされ、同年6月20日付けで手続補正がされ、同年7月31日付けで拒絶理由通知(以下、「第2回当審拒絶理由通知」という。)がされ、同年8月10日付けで手続補正がされたものである。 第2 原査定の概要 原査定(平成29年5月8日付け拒絶査定)の拒絶理由の概要は次のとおりである。 この出願の下記の請求項に係る発明は、その原出願出願日前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その原出願出願日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 ・請求項 :1-12 ・引用文献等:1、2 <引用文献等一覧> 1.特開2011-5306号公報 2.特開2011-182818号公報 第3 当審拒絶理由の概要 当審拒絶理由の概要は次のとおりである。 1.第1回当審拒絶理由通知 (1)この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 (2)この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。 記 (1)について ・請求項 :1-12 ・引用文献等:1-4 <引用文献等一覧> 1.特開2011-5306号公報 2.特開2012-182744号公報(周知の技術手段) 3.特表2012-525659号公報(周知の技術手段) 4.特表2012-528411号公報(周知の技術手段) (2)について 請求項1?12に係る発明は、“通信規格は、ウェブソケットの通信規格”であることが特定されていないから、発明の課題を解決する手段が不明である。 2.第2回当審拒絶理由通知 この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。 記 (1)請求項1、12の「第2の携帯端末から受け付けるステップ」、及び請求項11の「第2の携帯端末から受け付ける手段」の技術的内容が不明である。 (2)請求項1、12の各「ステップ」と、前記各「ステップ」を引用する「ステップ」との関係、及び請求項11の各「手段」と、前記各「手段」を引用する「手段」との関係の技術的内容が不明である。 第4 本願発明 本願の請求項1乃至12に係る発明は、平成30年8月10日付けの手続補正によって補正された特許請求の範囲の記載からみて、その特許請求の範囲の請求項1乃至12に記載された次のとおりのものと認められる。(以下、それぞれ「本願発明1」乃至「本願発明12」という。) 「【請求項1】 複数の携帯端末にゲームを提供するサーバ装置に、 前記ゲームにおける対戦に参加するための第1の要求を前記サーバ装置に対して送信した複数の第1の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第1の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第1ステップと、 前記対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2ステップと、 前記第1ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第1の携帯端末の各ユーザを、前記対戦が行われる間の一時的な1つのグループとして前記対戦に参加させる第3ステップと、 前記対戦に参加しているいずれかのユーザの第1の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第1の携帯端末に送信する第4ステップと を実行させるプログラム。 【請求項2】 前記イベント情報は、前記ユーザの操作を示すアクション情報と、所定の期間を示す期間情報とを含み、 前記第4ステップは、前記イベント情報を当該イベント情報に含まれる期間情報が示す期間内に、前記他のユーザの第1の携帯端末に送信するステップを含む、請求項1に記載のプログラム。 【請求項3】 前記複数の第1の携帯端末のうちの少なくとも2つの第1の携帯端末それぞれから前記ユーザの操作に応じたイベント情報を受信した場合に、当該イベント情報それぞれを受け付けたイベント情報受付時間が所定の期間内にあるか否かを判定するステップと、 前記判定の結果、前記イベント情報受付時間が前記所定の期間内にある場合、連続攻撃を前記対戦における敵に加えるステップとをさらに含む、請求項1記載のプログラム。 【請求項4】 前記対戦における敵に関連付けられた、前記対戦を行うときの優劣関係が巡回的に定められた複数の属性のうちのいずれかの属性を示す属性情報を含む敵属性データと、前記対戦に参加しているいずれかのユーザの第1の携帯端末に関連付けられた、前記複数のうちのいずれかの属性を示す属性情報を含む端末属性データとに基づいて、前記対戦を制御するステップをさらに含む、請求項1記載のプログラム。 【請求項5】 前記第2の要求を受付けた数に関連付けられた第1のインセンティブを当該対戦に参加したユーザに付与するステップ をさらに含む、請求項1記載のプログラム。 【請求項6】 接続を確立した前記第2の携帯端末が送信したイベント情報を受付けるステップと、 前記イベント情報を受け付けた数に基づくパラメータが所定の条件を満たしている場合、当該対戦に参加したユーザに対して第2のインセンティブを付与するステップをさらに含む、請求項5に記載のプログラム。 【請求項7】 前記対戦の実行期間中、当該対戦の制限時間から所定時間前になっても前記パラメータが目標値より少ない場合に、前記イベント情報の送信を促すメッセージを前記第2の携帯端末に送信するステップをさらに含む、請求項6記載のプログラム。 【請求項8】 前記対戦の終了時に、当該対戦に参加したユーザに対して、当該対戦に参加したユーザの数に応じた第3のインセンティブを付与するステップをさらに含む、請求項1乃至7のいずれか一項に記載のプログラム。 【請求項9】 前記第1ステップは、 前記対戦の参加募集期間中、前記複数の携帯端末それぞれから前記第1の要求を受信するステップと、 当該第1の要求の送信元の携帯端末のユーザのレベルが、前記対戦に参加しているユーザ数に応じたレベルよりも高い場合には、前記送信元の携帯端末との接続を確立するステップとを含む、請求項8記載のプログラム。 【請求項10】 前記複数の第1の携帯端末のうちのいずれかの第1の携帯端末から前記ユーザの操作に応じたイベント情報を受信したことを示すログ情報に基づいて、前記第3のインセンティブを当該第1の携帯端末に送信するステップをさらに含む、請求項9記載のプログラム。 【請求項11】 複数の携帯端末にゲームを提供するサーバ装置であって、 前記ゲームにおける対戦に参加するための第1の要求を前記サーバ装置に対して送信した複数の第1の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第1の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第1手段と、 前記対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2手段と、 前記第1手段において前記対戦の開始までの所定期間内に接続を確立した全ての第1の携帯端末の各ユーザを、前記対戦が行われる間の一時的な1つのグループとして前記対戦に参加させる第3手段と、 前記対戦に参加しているいずれかのユーザの第1の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第1の携帯端末に送信する第4手段と を備える、サーバ装置。 【請求項12】 複数の携帯端末にゲームを提供するサーバ装置に実行させるゲーム制御方法であって、 前記ゲームにおける対戦に参加するための第1の要求を前記サーバ装置に対して送信した複数の第1の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第1の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第1ステップと、 前記対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2ステップと、 前記第1ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第1の携帯端末の各ユーザを、前記対戦が行われる間の一時的な1つのグループとして前記対戦に参加させる第3ステップと、 前記対戦に参加しているいずれかのユーザの第1の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第1の携帯端末に送信する第4ステップと を含む、ゲーム制御方法。」 第5 引用文献、引用発明等 1.引用文献1について 原査定の拒絶の理由及び第1回当審拒絶理由に引用され、本願の優先日前である平成23年1月13日に頒布された刊行物である引用文献1(特開2011-5306号公報)には、図面と共に次の事項が記載されている。(なお、下線は当審で付した。以下同じ。) (1)「【特許請求の範囲】 【請求項1】 複数のゲーム装置がゲームサーバシステムを介して通信可能に接続され、前記ゲーム装置間で対戦ゲームを実行するゲームシステムであって、 前記ゲームサーバシステムは、 前記複数のゲーム装置のうちの一のゲーム装置からの要求に応じて、前記対戦ゲームに関するルールの情報を含んでなるグループ情報に基づき前記対戦ゲームを行うための対戦グループを作成する対戦グループ作成手段と、 他のゲーム装置から前記対戦グループへの参加の要求があった場合に、当該他のゲーム装置の前記対戦グループへの参加を許可する対戦グループ参加許可手段と、 前記対戦グループ参加許可手段によって前記対戦グループへの参加が許可されたゲーム装置のうち、所定の条件を充たすゲーム装置を戦闘モードに移行させるとともに、前記所定の条件を充たさないゲーム装置を観戦モードに移行させる戦闘/観戦割付手段と、 前記戦闘モードに移行したゲーム装置から操作入力情報を受信するとともに、当該受信した操作入力情報を、前記参加が許可されたゲーム装置のうち前記操作入力情報を送信したゲーム装置以外のゲーム装置に送信する操作入力情報送受信手段と、 前記観戦モードに移行したゲーム装置から送信されたチャット情報を受信するとともに、当該チャット情報を、前記参加が許可されたゲーム装置のうち前記チャット情報を送信したゲーム装置以外のゲーム装置に送信する第1のチャット情報送受信手段と、 前記ルールの情報に基づいて前記戦闘モードに移行したゲーム装置の対戦が終了したかどうかを判断する対戦終了判断手段と、 を備え、 前記参加が許可されたゲーム装置のそれぞれは、 前記戦闘モードに移行した場合は、入力された操作入力情報及び前記ゲームサーバシステムから送信される他の前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新する一方、前記観戦モードに移行した場合は、前記ゲームサーバシステムから送信される前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新するゲーム画像更新手段と、 前記対戦が開始されてから前記対戦終了判断手段が当該対戦の終了を判断するまで、前記第1のチャット情報送受信手段により送信されるチャット情報を受信するとともに、前記第1のチャット情報送受信手段にチャット情報を送信する第2のチャット情報送受信手段と、 前記第2のチャット情報送信手段が前記第1のチャット情報送受信手段から受信した前記チャット情報をプレイヤに認識可能な状態で出力するチャット情報出力手段と、 を備える、 ゲームシステム。」 (2)「【0059】 次に本発明の好適な実施の形態を、図面を参照して説明する。 (実施形態1) 本発明の実施形態1は、クライアントシステム間で同一対戦グループを結成し、それに属するクライアントシステムの中から対戦の組み合わせを決定し、勝った方、負けた方、固定した双方またはいずれか一方の固定されたクライアントシステムが継続して他のクライアントシステムと対戦するように構成された通信ゲームシステムに関する。 【0060】 図1に本発明の通信ゲームシステムのシステム図を示す。 【0061】 本通信ゲームシステムは、図1に示すように、複数のクライアントシステム1が回線網4を介して、ゲームサーバシステム2およびWWWサーバシステム3に接続されて構成されている。 【0062】 各クライアントシステム1は、いわゆる通信機能を有するゲーム装置としての構成を備え、ゲーム機本体10、コントロールパッド11およびモニタ12を相互に接続して構成される。 【0063】 コントロールパッド11は、各遊技者の操作に伴って出力される操作信号をゲーム機本体10に供給するようになっている。ゲーム機本体10は、通信可能なコンピュータ装置としての構成(CPU、メモリ、CD-ROMドライブ、モデム、画像生成回路、音声生成回路等)を備えている。当該ゲーム機本体10は、CD-ROMなどの記録媒体からデータを読み取り可能になっており、記録媒体から読み取ったゲームプログラムを実行することで当該通信ゲームシステムのクライアントシステムとして動作するようになっている。ゲーム機本体10は、コントロールパッド11からの操作信号に基づきゲーム処理を進め、通信ゲームが遊技者から指定された場合には、内蔵するモデム経由で、回線網4を介してゲームサーバシステム2に接続するようになっている。記録媒体に記録されるゲームプログラムは、通信ゲーム機能を実行可能なものであれば、そのゲームの内容に制限は無い。ただし、他の遊技者と対戦して勝敗が決定するような対戦型のゲームとしてプログラムされていることが好ましい。またゲーム機本体10は、ゲーム処理に伴う画像信号と音声信号を出力するようになっている。モニタ12は、ゲーム機本体10からの画像信号や音声信号に対応して画像や音声を遊技者に提供するように構成されている。 【0064】 ゲームサーバシステム2は、ゲームサーバ20と記憶領域21とを備える。 【0065】 ゲームサーバ20は、汎用の高性能コンピュータ装置としての構成(CPU、メモリ、HD、通信装置等)を備えている。当該ゲームサーバ20は、本発明のゲーム処理方法に対応したプログラムを実行することにより、通信ゲームシステムを管理するゲームサーバシステムとして動作するようになっている。すなわちゲームネットワーク40のアクセスポイントに接続されたクライアントシステム1を管理するようになっている。記憶領域21は、ゲームサーバ20そのものまたは当該サーバからアクセス可能な領域であって、当該通信ゲームシステムを実行するために必要なデータベースをファイルなどの形式で格納可能な領域になっている。 【0066】 回線網4は、通常の公衆回線または専用線であってゲームネットワーク40やインターネット41などのWANを形成している。 【0067】 ゲームネットワーク40は、当該通信ゲームシステムの実行のために提供されているネットワークである。例えばゲームサーバシステム2が管理する特定のアクセスポイントにクライアントシステム1から接続することによって、ゲームサーバシステム2と各クライアントシステム1とにより構成される専用ネットワークである。ただし、このようなPPP接続ではなく、任意の接続窓口からクライアントシステムがゲームサーバにアクセスするようなインターネット経由の接続構成を備えていてもよい。そのプロトコルなどに限定はないが、クライアントシステム1においてインターネットにおけるWWW機能を利用する場合や汎用性を持たせる点などを考慮してTCP/IPなどの汎用の規格にしてもよい。」 (3)「【0071】 図2に、本通信ゲームシステムの詳しい機能ブロック図を示す。クライアントシステム1(A,B)において、処理装置100と通信装置101とはゲーム機本体10に属する。出力データ生成装置102とコントロールパッド11とは、コントロールパッド11に属する。 【0072】 処理装置100は、CPUを中心としてゲームプログラムを実施するコンピュータ部分である。処理装置100は、操作装置110からの操作信号の認識、振動発生手段111への振動信号の出力、通信装置101の通信制御、出力データ生成装置102の制御などを行う。通信装置101は、例えばモデムやターミナルアダプタであり、ゲームネットワーク40やインターネット41と処理装置100とのデータ送受信を仲介するものである。操作装置110は、操作ボタンや十字キーなどゲームの操作に必要な操作機能を備えている。振動発生手段111は、例えばピエゾ素子など逆圧電効果により、所定周波数の振動信号に対応させてコントロールパッド11を操作する遊技者に振動を認識させることが可能になっている。 【0073】 ゲームサーバシステム2において、処理装置200と通信装置201とはゲームサーバ20に属する。記憶領域21には、ユーザデータベース(以下DBと略する。)210、イージーロビーDB211、エキスパートロビーDB212、ノーマルDB213、チーム戦DB214、総当たり戦DB215およびトーナメント戦DB216などが格納されている。」 (4)「【0080】 各クライアントシステム1は、プログラムと遊技者による操作信号とに基づいてゲーム処理を進める独立モードと、通信によって提供されたコマンドを中心にゲーム処理を進める通信モードとを使い分けるようになっている。 【0081】 いずれの動作モードでも、ゲーム機本体10は、コントロールパッド11からの操作信号を解釈してゲーム画面におけるキャラクタ(操作可能なセグメントやモデルのこと)を移動させる。ただし、ゲームにおける敵のキャラクタの動きは、独立モードでは、プログラムによって規定されるのに対し、通信モードでは、ゲームネットワーク40経由で対戦相手となったクライアントシステム1から送信されるコマンドによって規定される点で異なっている。また通信モードの場合には、ゲーム機本体10は、操作信号をコマンド化してゲームネットワーク40に送出する。 【0082】 具体的には、図8に示すように、ゲーム機本体10は、操作信号を読取り(S501)、通信開始を示す操作内容であるか否かを検査する(S502)。通信開始でない場合には(S502:NO)、独立モードであり、通常のゲーム装置としての処理を続行する(S503)。 【0083】 一方、通信開始を示している場合には(S502:YES)、ゲーム機本体10は、通信モードであるため接続を確立するための一般的手順を実行する。すなわち、ゲーム機本体10は、予め登録されているサーバを選択し呼び出し、接続後にハンドルネーム、ID、パスワードなどの必要情報を送信する(S504)。接続できない場合には、処理装置は通常のエラー処理としてその旨表示して復帰する。 【0084】 接続確立後、ゲーム機本体10はメインメニューを表示させる(S505)。ゲーム開始が遊技者から指示されたら、ゲーム機本体10は、その後はエスケープ等の特別の操作をしない限り復帰しない永久ループ処理を実行する。つまり操作信号が供給された場合に(S506:YES)、ゲーム機本体10はその操作信号を読み取り(S508)、予め定められたコマンド規約にしたがってコマンド化してゲームネットワーク40に送出する(S509)。またゲームネットワーク40からコマンドが送信された場合には(S510:YES)、ゲーム機本体10はこれを読み取り(S511)、解釈ルーチンに移行する。」 (5)「【0087】 クライアントシステム1が戦闘モードに割り付けられている場合には、ゲーム機本体10は、自分のキャラクタを操作信号に基づいて移動させ、ゲームネットワーク40から提供される操作コマンドに基づいて敵のキャラクタの位置や態様を変化させる。操作コマンドの割付は、ゲームごとに任意に定めうる。これらの処理により、遊技者は、あたかも一つのゲーム機に二つのコントロールパッド11を接続して他人と対戦しているかのようにゲーム対戦を実行可能になる。 【0088】 クライアントシステム1が観戦モードに割り付けられている場合には、ゲーム機本体10は、ゲームネットワーク40から提供される操作コマンドに基づいて双方のキャラクタを移動させその表示態様を変化させる。この処理により、遊技者は、あたかもアミューズメントセンターで友人がゲーム対戦をしているのを応援しているかのようなゲーム観戦を実行可能になる。」 (6)「【0100】 クライアントシステム1において、遊技者がコントロールパッド11のスタートボタンを操作すると、その時のモードに対応したスタートメニューM1が表示されるようになっている(S11:図11)。 【0101】 このスタートメニューM1において「会議室を作る」が選択されると、ゲームサーバ20は、対戦モードの選択するメニューM2を更に表示させる(S12:図12)。このメニューからいずれかの対戦モードを選択すると、それに対応する対戦グループが新規に作成され、その「作戦会議室」が表示されるようになる(S13)。 【0102】 選択された対戦モードで作成される「作戦会議室」に新規登録後に1以上のクライアントシステム1が参加してくることによって(S30、S40、S50、S60)、一つの対戦グループが形成される。メニューM2において、「ノーマル」が選択されると本実施形態の対戦モード、「チーム戦」が選択されると実施形態2、「総当たり」が選択されると実施形態3、「トーナメント」が選択されると実施形態4の各実施形態で説明する作戦会議室、すなわち対戦グループが作成できるようになる。」 (6)「【0113】 さて、戦況報告ウィンドウW5(S20:図14)において、遊技者により所定の操作(例えば「A」ボタン押下)がされると、当該操作を行ったクライアントシステム1がこの対戦グループに新たに参加したものとして登録される。すなわち、ゲームサーバ20は、当該クライアントシステム1から選択中の対戦グループへの参加要求があったものと判断し、この対戦グループに当該クライアントシステム1を新たな参加者として登録する(S30)。ゲームサーバ20は、当該対戦グループのグループ情報に参加を希望したクライアントシステム1の個人情報を新たに関係付ける。 【0114】 新たに参加する場合に(S30)、対戦グループごとにパスワードを設定し、パスワードを入力しなければ参加できないように認証処理を行ってもよい。すなわち新たな対戦グループに参加依頼があった場合に、この参加を希望するクライアントシステム1にパスワード入力を要求し、このパスワードが正しく入力された場合にのみゲームサーバ20が当該対戦グループへの参加を許可するのである。 (ノーマル作戦会議室) 以下では、特に対戦モードとして「ノーマル」が設定されている対戦グループへの対戦管理を説明する。「ノーマル」対戦モードとは、一つの対戦が終了した場合に、勝った方、負けた方、固定した双方またはいずれか一方の固定されたクライアントシステムが継続して他のクライアントシステムと対戦するような試合ルールによる対戦をいう。」 (7)「【0128】 このコマンドにより戦闘モードに入るクライアントシステム1では、ゲーム機本体10がゲーム対戦画像を表示させ、コントロールパッド11からの操作信号に対応させて自分のキャラクタを移動させ、その対戦用のデータ(操作コマンド)をゲームネットワーク40に送信する。ゲームネットワーク40から敵キャラクタの操作コマンドが送信されたきた場合には、その操作コマンドに対応させて敵キャラクタを移動させるように処理する。ゲームサーバ20はこの操作コマンドの送受信を仲介する。」 (6)「【0272】 加えて、この観戦モードに割り付けられているクライアントシステム1同士で、チャットができるため、遊技者は、あたかもアミューズメントセンターで友人がゲーム対戦をしているのを応援しているかのような感覚でゲーム観戦を行うことができる。」 (7)上記【0062】より、「クライアントシステム1」は、請求項1の「ゲーム装置」に対応する。 (8)上記【0063】より、「ゲーム機本体10」は、請求項1の「ゲーム装置」に対応する。 (9)上記【0065】より、プログラムは、ゲームシステムを管理するゲームサーバシステムとして、ゲームサーバを、動作させるものといえる。 (10)上記【0113】及び図14より、戦闘中に対戦グループへの参加要求があった場合、この対戦グループにクライアントシステム1を新たな参加者として登録するものといえる。 したがって、上記引用文献1には次の発明(以下、「引用発明1」という。)が記載されていると認められる。 「複数のゲーム装置がゲームサーバシステムを介して通信可能に接続され、前記ゲーム装置間で対戦ゲームを実行するゲームシステムを管理するゲームサーバシステムとして、ゲームサーバを、動作させるプログラムであって、 ゲームサーバシステムが管理する特定のアクセスポイントにゲーム装置から接続することによって、ゲームサーバシステムと各ゲーム装置とにより構成される専用ネットワークがゲームシステムの実行のために提供され、 ゲーム装置は、CD-ROMなどの記録媒体からデータを読み取り可能になっており、記録媒体から読み取ったゲームプログラムを実行することで当該通信ゲームシステムのゲーム装置として動作するようになっており、 前記ゲームサーバシステムは、 前記複数のゲーム装置のうちの一のゲーム装置からの要求に応じて、前記対戦ゲームに関するルールの情報を含んでなるグループ情報に基づき前記対戦ゲームを行うための対戦グループを作成する対戦グループ作成手段と、 他のゲーム装置から前記対戦グループへの参加の要求があった場合に、当該他のゲーム装置の前記対戦グループへの参加を許可する対戦グループ参加許可手段と、 前記対戦グループ参加許可手段によって前記対戦グループへの参加が許可されたゲーム装置のうち、所定の条件を充たすゲーム装置を戦闘モードに移行させるとともに、前記所定の条件を充たさないゲーム装置を観戦モードに移行させる戦闘/観戦割付手段と、 前記戦闘モードに移行したゲーム装置から操作入力情報を受信するとともに、当該受信した操作入力情報を、前記参加が許可されたゲーム装置のうち前記操作入力情報を送信したゲーム装置以外のゲーム装置に送信する操作入力情報送受信手段と、 前記観戦モードに移行したゲーム装置から送信されたチャット情報を受信するとともに、当該チャット情報を、前記参加が許可されたゲーム装置のうち前記チャット情報を送信したゲーム装置以外のゲーム装置に送信する第1のチャット情報送受信手段と、 前記ルールの情報に基づいて前記戦闘モードに移行したゲーム装置の対戦が終了したかどうかを判断する対戦終了判断手段と、 を備え、 前記参加が許可されたゲーム装置のそれぞれは、 前記戦闘モードに移行した場合は、入力された操作入力情報及び前記ゲームサーバシステムから送信される他の前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新する一方、前記観戦モードに移行した場合は、前記ゲームサーバシステムから送信される前記戦闘モードに移行しているゲーム装置の操作入力情報に基づき前記対戦ゲームのゲームキャラクタに対応するゲーム画像を更新するゲーム画像更新手段と、 前記対戦が開始されてから前記対戦終了判断手段が当該対戦の終了を判断するまで、前記第1のチャット情報送受信手段により送信されるチャット情報を受信するとともに、前記第1のチャット情報送受信手段にチャット情報を送信する第2のチャット情報送受信手段と、 前記第2のチャット情報送信手段が前記第1のチャット情報送受信手段から受信した前記チャット情報をプレイヤに認識可能な状態で出力するチャット情報出力手段と、 を備え、 戦闘中に対戦グループへの参加要求があった場合、この対戦グループにゲーム装置を新たな参加者として登録し、 観戦モードは、ゲーム対戦をしているのを応援しているかのようなゲーム観戦を実行可能とする、 ゲームシステムを管理するゲームサーバシステムとして、ゲームサーバを動作させるプログラム。」 2.引用文献2について 原査定の拒絶の理由に引用され、本願の優先日前である平成23年9月22日に頒布された刊行物である引用文献2(特開2011-182818号公報)には、図面と共に次の事項が記載されている。 (1)「【特許請求の範囲】 【請求項1】 互いに情報の送受信可能に接続された複数のゲーム機を含み、 前記各ゲーム機は、 ユーザの操作を受け付ける操作入力部と、所定の画像を出力する画像出力部と、所定の情報を記憶する記憶部と、自機を、自機のユーザがプレイヤとしてゲームをプレイできる状態にするプレイヤ機能部と、自機を、自機のユーザが見学者として前記ゲームの進行を見学できる状態にする見学者機能部と、前記プレイヤ機能部の機能が有効である状態と無効である状態とを切り替える切替部と、 を備えるゲームシステムであって、 前記各ゲーム機の記憶部には、前記複数のゲーム機のそれぞれに関する情報であって、前記各ゲーム機を識別するゲーム機識別情報と、前記プレイヤ機能部が有効に機能しているプレイヤ機、又は前記プレイヤ機能部が有効に機能していない見学者機のいずれであるかを示す機能識別情報とを含むゲーム機情報で構成されるゲーム機リストが記憶され、 前記プレイヤ機能部は、 前記プレイヤによる前記操作入力部への操作に基づいて前記ゲームを進行し、前記ゲームの進行に応じたゲーム画面を生成して前記画像出力部に出力させるゲーム進行部と、 前記見学者機において表示されるゲーム画面を更新するための画面更新情報を生成して、前記ゲーム機リストにある前記各見学者機へ送信する画面更新情報処理部と、を備え、 前記見学者機能部は、 前記プレイヤ機から前記画面更新情報を取得すると、前記画面更新情報に基づいて、前記画像出力部に出力されているゲーム画面を更新する画面出力処理部を備え、 前記切替部は、 他のゲーム機をプレイヤ機として設定するための処理を行う切替処理部と、自機をプレイヤ機として設定するための処理を行う切替対応部と、プレイヤ機の切替に応じて前記ゲーム機リストを更新するリスト更新部とを有し、 前記切替処理部は、 前記ゲームの進行中に、所定の切替条件が満たされると、前記ゲーム機リストにある1つの見学者機を新プレイヤ機として決定し、プレイヤ機の切替を通知する切替通知を前記新プレイヤ機へ送信する切替通知部と、 前記切替通知が送信されると前記プレイヤ機能部の機能を無効にする機能無効化部とを備え、 前記切替対応部は、 前記切替通知が受信されると前記プレイヤ機能部の機能を有効にする機能有効化部と、 前記切替通知の発信元のゲーム機に代わって自機がプレイヤ機として機能することを示すべく、前記ゲーム機リストを更新するとともに、その更新内容を示す新プレイヤ機通知を生成して、全ての他のゲーム機へ送信する新プレイヤ機通知部とを備え、 前記リスト更新部は、前記新プレイヤ機から新プレイヤ機通知を受信すると、前記新プレイヤ機通知に基づいて、自機の前記ゲーム機リストにおける前記プレイヤ機及び前記見学者機を更新する、ことを特徴とするゲームシステム。 … 【請求項6】 前記複数のゲーム機と情報の送受信可能なサーバを更に含み、 前記サーバは、 前記複数のゲーム機のそれぞれから、システム参加要求を受け付ける参加要求受付部と、 前記システム参加要求を受け付けた複数のゲーム機を1つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定した前記ゲーム機リストを生成するゲーム機リスト生成部と、 前記ゲーム機リストを含む開始情報を生成して、前記各ゲーム機へ送信する開始情報送信部とを備え、 前記各ゲーム機は、 前記システム参加要求を前記サーバへ送信する参加要求送信部と、 前記システム参加要求を送信後、前記開始情報に含まれるゲーム機リストを前記サーバから取得すると、自機の前記記憶部に記憶すると共に、前記ゲーム機リストに応じて、自 機の前記プレイヤ機能部又は前記見学者機能部の少なくとも一方を有効な状態にする開始処理部を備え、 前記ゲーム進行部は前記開始処理部による処理がされた後、前記ゲームを開始する、ことを特徴とする請求項1に記載のゲームシステム。」 (2)「【0044】 図3に戻って、サーバ制御部54について説明する。サーバ制御部54は、CPU及びその動作に必要な記憶域を備えたコンピュータとして構成されている。サーバ記憶部52に記憶されたコンピュータプログラムによって、主に、参加要求受付部54a、ゲーム機リスト生成部54b、及びサーバ更新部54cと、開始情報送信部54eして機能する。参加要求受付部54aはゲーム機MからのゲームシステムGS1への参加要求を受け付ける。ゲーム機リスト生成部54bは、所定時間内に参加要求を受け付けたゲーム機Mをグループ化し、当該グループの中から実行されるゲームに応じた数のプレイヤ機Mpを決定し、当該決定と参加要求に基づいてゲーム機リストMLを生成する。サーバ更新部54cはゲーム機Mからの情報に基づいて、ゲーム機リストMLを更新する。開始情報送信部54eはゲームシステムGS1のゲーム機として必要な情報が含まれた開始情報を各ゲーム機Mへ送信する。」 (3)「【0055】 ゲーム機MがゲームシステムGS1に参加する際に、サーバSv及びゲーム機Mのそれぞれにおいて行われる処理について、図13のシーケンス図を用いて説明する。サーバSvにおける処理はサーバ制御部54によって制御され、ゲーム機Mにおける処理はゲーム機制御部80によって制御される。まず、各ゲーム機M1?M3からサーバSvへ、各ユーザU1?U3の操作によって参加要求が送信される(ステップS10)。これにより、ゲーム機制御部80は参加要求送信部88として機能する。参加要求にはゲーム機識別情報61やユーザ情報63が含まれている。 【0056】 ゲーム機Mからの参加要求は、サーバSvにて受け付けられ、所定時間内に受け付けられた参加要求に対応するゲーム機Mはグループ化される(ステップS11)。これにより、サーバ制御部54は参加要求受付部54aとして機能する。本形態では、ゲーム機M1?M3がグループ化される。続いて、サーバSvでは、グループ化されたゲーム機M1?M3において、対戦ゲームに応じた数のゲーム機Mがプレイヤ機Mpとして決定される(ステップS12)。本形態では、2つのゲーム機M1、M2がプレイヤ機Mpとして決定される。当該決定方法はいずれの方法でもよく、例えば、参加要求の受付の早い順に最初の2つのゲーム機Mをプレイヤ機Mpとして決定すればよい。」 (4)「【0058】 開始処理では、開始情報に含まれるゲーム機リストMLを参照して、自機がプレイヤ機Mpである時は、自機をプレイヤ機Mpとして機能させる処理、自機が見学者機Mvである時は、自機を見学者機Mvとして機能させる処理が行われる。具体的には、プレイヤ機Mpに設定されているゲーム機M1、M2では、ゲーム機リストML及び操作認識ソフトRSをゲーム機記憶部72に記憶し、操作認識ソフトRSを稼動する。そして、ゲーム進行部82aにゲーム開始画面を表示させる。これにより、プレイヤ機Mpでは、ゲームにおいて、プレイヤUpの操作に応じたゲームが実行可能となり、プレイヤ機能部82が有効に機能する、即ち、プレイヤ機として機能するようになる。見学者機Mvに設定されているゲーム機M3では、ゲーム機リストMLがゲーム機記憶部72が記憶され、画面出力処理部84aによって見学者用ゲーム開始画面が出力され、画面更新情報の待ち状態になる。」 したがって、上記引用文献2には次の発明(以下、「引用発明2」という。)が記載されていると認められる。 「互いに情報の送受信可能に接続された複数のゲーム機を含み、 前記各ゲーム機は、 ユーザの操作を受け付ける操作入力部と、所定の画像を出力する画像出力部と、所定の情報を記憶する記憶部と、自機を、自機のユーザがプレイヤとしてゲームをプレイできる状態にするプレイヤ機能部と、自機を、自機のユーザが見学者として前記ゲームの進行を見学できる状態にする見学者機能部と、前記プレイヤ機能部の機能が有効である状態と無効である状態とを切り替える切替部と、 を備えるゲームシステムであって、 前記各ゲーム機の記憶部には、前記複数のゲーム機のそれぞれに関する情報であって、前記各ゲーム機を識別するゲーム機識別情報と、前記プレイヤ機能部が有効に機能しているプレイヤ機、又は前記プレイヤ機能部が有効に機能していない見学者機のいずれであるかを示す機能識別情報とを含むゲーム機情報で構成されるゲーム機リストが記憶され、 前記プレイヤ機能部は、 前記プレイヤによる前記操作入力部への操作に基づいて前記ゲームを進行し、前記ゲームの進行に応じたゲーム画面を生成して前記画像出力部に出力させるゲーム進行部と、 前記見学者機において表示されるゲーム画面を更新するための画面更新情報を生成して、前記ゲーム機リストにある前記各見学者機へ送信する画面更新情報処理部と、を備え、 前記見学者機能部は、 前記プレイヤ機から前記画面更新情報を取得すると、前記画面更新情報に基づいて、前記画像出力部に出力されているゲーム画面を更新する画面出力処理部を備え、 前記切替部は、 他のゲーム機をプレイヤ機として設定するための処理を行う切替処理部と、自機をプレイヤ機として設定するための処理を行う切替対応部と、プレイヤ機の切替に応じて前記ゲーム機リストを更新するリスト更新部とを有し、 前記切替処理部は、 前記ゲームの進行中に、所定の切替条件が満たされると、前記ゲーム機リストにある1つの見学者機を新プレイヤ機として決定し、プレイヤ機の切替を通知する切替通知を前記新プレイヤ機へ送信する切替通知部と、 前記切替通知が送信されると前記プレイヤ機能部の機能を無効にする機能無効化部とを備え、 前記切替対応部は、 前記切替通知が受信されると前記プレイヤ機能部の機能を有効にする機能有効化部と、 前記切替通知の発信元のゲーム機に代わって自機がプレイヤ機として機能することを示すべく、前記ゲーム機リストを更新するとともに、その更新内容を示す新プレイヤ機通知を生成して、全ての他のゲーム機へ送信する新プレイヤ機通知部とを備え、 前記リスト更新部は、前記新プレイヤ機から新プレイヤ機通知を受信すると、前記新プレイヤ機通知に基づいて、自機の前記ゲーム機リストにおける前記プレイヤ機及び前記見学者機を更新し、 前記複数のゲーム機と情報の送受信可能なサーバを更に含み、 前記サーバは、 前記複数のゲーム機のそれぞれから、システム参加要求を受け付ける参加要求受付部と、 前記システム参加要求を所定時間内に受け付けられた複数のゲーム機を1つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、参加要求の受付の早い順に前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定した前記ゲーム機リストを生成するゲーム機リスト生成部と、 前記ゲーム機リストを含む開始情報を生成して、前記各ゲーム機へ送信する開始情報送信部とを備え、 前記各ゲーム機は、 前記システム参加要求を前記サーバへ送信する参加要求送信部と、 前記システム参加要求を送信後、前記開始情報に含まれるゲーム機リストを前記サーバから取得すると、自機の前記記憶部に記憶すると共に、前記ゲーム機リストに応じて、自機の前記プレイヤ機能部又は前記見学者機能部の少なくとも一方を有効な状態にする開始処理部を備え、 前記ゲーム進行部は前記開始処理部による処理がされた後、前記ゲームを開始する、ゲームシステム。」 3.引用文献3について 第1回当審拒絶理由通知に引用され、本願の優先日前である平成24年9月20日に頒布された刊行物である引用文献3(特開2012-182744号公報)には、図面と共に次の事項が記載されている。 (1)「【特許請求の範囲】 … 【請求項2】 原稿を光学的に読み取って読取画像からなるスキャンデータを生成する光学読取部と、上記スキャンデータを保持するサーバ記憶部とを有するサーバ装置に通信ネットワークを介して接続されたクライアント端末装置において、 ハイパーテキスト転送プロトコルから双方向プロトコルへ通信プロトコルを変更させるためのプロトコル変更要求を生成するプロトコル変更要求生成部と、 上記プロトコル変更要求を上記サーバ装置へ送信し、上記サーバ装置が上記プロトコル変更要求に対する応答として送信するプロトコル変更応答に基づいて、通信プロトコルを上記双方向プロトコルへ変更する端末通信部と、 上記双方向プロトコルへ移行した後、新たに上記スキャンデータが上記サーバ記憶部内に格納されるごとに上記サーバ装置が送信するスキャンデータを保持する端末記憶部とを備えたことを特徴とするクライアント端末装置。 … 【請求項5】 上記双方向プロトコルが、上記サーバ装置及び上記クライアント端末装置のいずれも、状態確認のための状態確認要求を送信することができるウェブソケットプロトコルであることを特徴とする請求項2?4のいずれかに記載のクライアント端末装置。」 (2)「【技術分野】 【0001】 本発明は、原稿読取システム、クライアント端末装置及びコンピュータプログラムに係り、さらに詳しくは、画像データの入出力を行うサーバ装置と、通信ネットワークを介してサーバ装置に接続されたクライアント端末装置とからなる原稿読取システムに関する。 【背景技術】 【0002】 スキャナとPC(パーソナルコンピュータ)とがネットワーク接続され、HTTP(HyperText Transfer Protocol:ハイパーテキスト転送プロトコル)に基づいて通信を行うシステムでは、スキャナ及びPCがそれぞれサーバ装置及びクライアント端末装置として機能する。例えば、スキャナが原稿から読み取ったスキャンデータをPCが取得する場合、まず、PCからスキャナへ画像送信要求が送信される。スキャンデータは、この画像送信要求に対する応答として、スキャナからPCへ送信される(例えば、特許文献1?3)。 【0003】 この様な従来の原稿読取システムにおいて、PCがスキャナからスキャンデータを取得する具体的な方法には、スキャンボックスを利用するスキャンボックス方式と、PCからの指示によって読取処理を開始させるリアルタイムスキャン方式がある。スキャンボックスは、読取画像からなるスキャンデータを格納するための記憶領域からなり、任意に作成することができる。スキャンボックス方式の場合、原稿を収容部内に配置し、スキャンデータの格納先を指定して読取開始を指示すれば、読取処理が開始され、スキャンデータが対応するスキャンボックス内に格納される。PCでは、スキャンボックスを指定した読込指示を入力することにより、スキャナドライバにスキャンボックス内のスキャンデータを取得させることができる。 【0004】 リアルタイムスキャン方式の場合には、スキャンモードへ切り替え、原稿を収容部内に配置する。PCでは、スキャンボックスを指定した読込指示により、スキャナドライバが、スキャンデータを取得するための画像送信要求をスキャナへ送信する。スキャナは、この画像送信要求に基づいて、読取処理を開始し、スキャンデータをPCへ送信する。上述したいずれの方式であっても、PCからスキャナ内のスキャンデータを取得することができるが、使い勝手が良くないという課題があった。すなわち、スキャンボックス方式では、PCにおける読込指示に先立って取得対象のスキャンデータをスキャンボックス内に格納しておく必要がある。このため、例えば、読込指示後に新たに原稿を読み取らせる場合、当該原稿を読み取らせた後、再度PC上において読込指示を入力しなければならず、操作手順が複雑であった。 【0005】 一方、リアルタイムスキャン方式では、PCにおける読込指示に先立って読取対象の原稿を収容部内に配置しておく必要がある。このため、連続読取が不可能な原稿群、例えば、複数のページからなる冊子を読み取らせる場合に、原稿の配置と読込指示とを繰り返さなければならず、操作手順が複雑であった。 【先行技術文献】 【特許文献】 【0006】 【特許文献1】特開2000-112594号公報 【特許文献2】特開2008-172288号公報 【特許文献3】特開2005-275613号公報 【発明の概要】 【発明が解決しようとする課題】 【0007】 本発明は、上記事情に鑑みてなされたものであり、クライアント端末装置からサーバ装置内のスキャンデータを取得する際の使い勝手を向上させた原稿読取システムを提供することを目的としている。 【0008】 特に、新たに格納されたスキャンデータをサーバ装置から自動的に取得することができるクライアント端末装置を提供することを目的としている。また、連続読取が不可能な原稿群を読み取らせる場合の操作性を向上させることができるクライアント端末装置を提供することを目的としている。 【0009】 また、本発明は、その様なクライアント端末装置において実行されるコンピュータプログラムを提供することを目的とする。」 4.引用文献4について 第1回当審拒絶理由通知に引用され、本願の優先日前である平成24年10月22日に頒布された刊行物である引用文献4(特表2012-525659号公報)には、図面と共に次の事項が記載されている。 (1)「【特許請求の範囲】 … 【請求項8】 分散ウェブアプリケーションの実行をサポートするサーバーシステムであって、 a)ネットワークに結合されたソース起点サーバーシステムであって、これは、クライアント側ウェブアプリケーションを含み、そしてソース起点の範囲内で前記ネットワークを通してアクセスできるソース起点サーバーシステムと、 b)前記ネットワークに結合されたゲートウェイサーバーシステムであって、これは、通信ブリッジプログラムを含み、ターゲット起点の範囲内で前記ネットワークを通してアクセスでき、そしてウェブアプリケーションサービスへネットワーク接続を与えるように動作するゲートウェイサーバーシステムと、 c)前記ネットワークに結合されたクライアントシステムであって、これは、ウェブブラウザクライアントを実行するように動作でき、前記ウェブブラウザクライアントは、クロス起点メッセージを除外するpre-HTML5適合ウェブブラウザクライアントであり、前記ウェブブラウザクライアントは、前記クライアント側ウェブアプリケーションを前記ソース起点サーバーシステムダウンロードするように働き、更に、前記ウェブブラウザクライアントは、前記ソース起点の範囲内で前記クライアントシステム上の前記クライアント側ウェブアプリケーションを実行するように動作し、前記ウェブブラウザクライアントは、前記通信ブリッジプログラムを前記ゲートウェイサーバーシステムダウンロードするように動作し、前記ウェブブラウザクライアントは、更に、前記ターゲット起点の範囲内で前記クライアントシステム上の前記通信ブリッジプログラムを実行するように動作し、前記クライアント側ウェブアプリケーション及び前記通信ブリッジプログラムは、クロス起点通信チャンネルを具現化し、前記クライアント側ウェブアプリケーションは、更に、前記通信ブリッジプログラム及び前記ゲートウェイサーバーシステムを通して前記ウェブアプリケーションサービスクロス起点の要求を発行するように動作するようなクライアントシステムと、 を備えたサーバーシステム。 … 【請求項11】 前記クロス起点通信チャンネルは、シルバーライトランタイムライブラリを使用し、前記通信ブリッジプログラムは、前記ゲートウェイサーバーシステムによるクロス起点通信チャンネルの確認を可能にするソース起点を識別するエンコードされたヘッダデータでウェブソケット要求をエンコードするよう動作する、請求項8に記載のサーバーシステム。」 (2)「【技術分野】 【0001】 本発明は、一般に、ネットワーク通信システムに係り、より詳細には、HTTPベースのネットワークを経てリアルタイム両方向性通信をサポートすることのできる企業クラスのクライアント/サーバーシステムに係る。 【0002】 本発明は、2009年5月1日に出願された米国仮特許出願第61/174,923号の利益を請求する。 【背景技術】 【0003】 ウェブアプリケーションの開発及び使用は、成長を続けているが、広く使用されているHTTPプロトコルが半二重通信しかサポートしないという点で著しい制約が存在する。従来のクライアント/サーバーアプリケーション使用モデルの場合のように、クライアントが種々のバックエンドシステムと対話できることが要求されない場合には、連続的なティア・ツー・ティア両方向又は全二重通信接続が強く望まれる。リアルタイム株フィードを表示し、アドホック情報更新を許し、特に、入札、チャット、ゲーム、及び他のアプリケーションで遭遇するリアルタイムオペレーションにおいて複数のユーザ間に能動的に参加できるようにする、等のウェブ上でのリアルタイムサービスの需要が重要になり増加している。 【0004】 所有権クライアント及びサーバーアプリケーションによってサポートされる他のプロトコルを利用することはできるは、ウェブブラウザクライアントが偏在するという事実は、実際上、基本的HTTPプロトコルの使用を要求する。本来的に、従来のウェブブラウザベースのクライアントアプリケーションは、データ要求及び応答が一度に一方向にしか流れない通信に基本的に制約されている。両方向通信をエミュレートする従来の試みは、典型的に、コメット・アンド・リバース・アジャック(Comet and Reverse Ajax)において具現化されるようなポーリング技術の使用を含む。本質的に、サーバーは、選択環境のもとで、クライアントへ情報をプッシュすることができる。しかしながら、これらの技術は、標準化の欠如、不充分な性能、及び限定された拡張性のような多数の制限で悩まされている。 【0005】 例えば、直接的なポーリング技術は、HTTP要求を規則的なインターバルでターゲットウェブサーバーへ繰り返し送信するためにウェブブラウザに関連して典型的に具現化されるクライアントアプリケーションを要求する。各要求は、サーバーが更新情報を有するかどうかに基づいて更新されたリアルタイム情報を潜在的に返送するサーバー発生応答を即座に受け取る。ポーリングインターバルに基づいて、受け取られる情報は、実際には、リアルタイムで受け取られず、逆に、応答情報がない場合にサーバー要求の高いオーバーヘッドを頻繁に受けて、得ることしかできない。このオーバーヘッドは、クライアント及びサーバーの両性能に影響を及ぼし、ネットワーク帯域巾を消費する。 【0006】 直接的ポーリングのオーバーヘッドを回避するために、ロングポーリングとして知られたバリアントが開発された。非同期ポーリングとしても知られているロングポーリングでは、この場合も典型的にウェブブラウザであるクライアントアプリケーションは、ターゲットウェブサーバーシステムに要求を発行する。即座の応答を与えるのではなく、ターゲットサーバーは、ある定義されたインターバルまで遅延し、ある新たな情報が応答として与えられるのを待機する。ある新たな、即ちリアルタイムのデータが遅延インターバル中にサーバーにより得られる場合には、リアルタイム情報を含むサーバー応答がクライアントへ送られる。新たな情報が受け取られない場合には、空き応答がクライアントアプリケーションに返送され、未決要求を終了させる。従って、ロングポーリングは、リアルタイムデータの配布の待ち時間を短縮する潜在性があり、要求/応答サイクルの数をある程度減少することができる。しかしながら、ロングポーリングは、依然として著しい数の要求/応答サイクルが必要とされ、且つ同様の数のHTTPヘッダがロングポーリング及びポーリングの両方に存在してクライアントとサーバーとの間で交換しなければならないために、慣習的なポーリングに勝る実質的な性能改善を与えない。 【0007】 ストリーミングは、別の従来の変形例である。ストリーミングが使用される場合には、クライアントウェブブラウザが完全な要求を送信するが、ターゲットサーバーは、少なくともある定義されたインターバル中に接続をオープンに維持できるように応答する。実際に、ターゲットサーバーは、応答が完了したという確認を延期する。これは、ターゲットサーバーが、そのターゲットサーバーによって受け取られる付加的なリアルタイム情報で応答を続けられるようにする。ストリーミング接続を確立する利益は、クライアント及びサーバーシステムの一部分においてオーバーヘッドを減少することである。ネットワークトラフィックも減少される。というのは、クライアント及びサーバーシステムは、ストリーミング接続を確立するのにHTTPヘッダパケットを一度しか送信しないからである。応答継続ネットワークパケットは、必要に応じて送信されるだけであり、従って、データしか含まず、ひいては、最小のオーバーヘッドしか課さない。不都合にも、ストリーミングは、HTTPでカプセル化され、従って、低レベルHTTP転送がネットワーク全般を通してどのようにルーティングされるかに完全に依存する。それ故、ストリーミングは、所与の接続がルーティングされる無数のシステムによって全体的に決定される予想不能な接続/切断及び実質的なバッファリング待ち時間を受ける。それ故、従来のストリーミングは、信頼できない。 【0008】 或いは又、提案されているHTML5ドラフト仕様は、ウェブソケット、サーバー送信イベント(Server-Sent Event)、及びそれに関連したアクセスセキュリティ要求を含む新たなプロトコル特徴を、HTTPプロトコルを使用して信頼性ある両方向性通信を可能にする手段として定義している。HTML5仕様は、他の中でも全二重直接TCP通信を標準化するよう意図されているが、最終的な仕様は、公式に採用されるのに、数年でなくても、おそらく、1年はかかる。次世代のウェブブラウザへの機能的合体及び動作的に均一の採用は、おそらく、数年は行われないであろう。更に、実用性、ビジネス及び他の制約のために既存のインプレースウェブブラウザの更新に対する抵抗もあり、おそらく、大規模な採用が数年以上阻止されるであろう。」 5.引用文献5について 第1回当審拒絶理由通知に引用され、本願の優先日前である平成24年11月12日に頒布された刊行物である引用文献5(特表2012-528411号公報)には、図面と共に次の事項が記載されている。 (1)「【特許請求の範囲】 【請求項1】 非HTTP通信プロトコルを用いるウエブアプリケーションのために状態に依存しない安全性管理を提供するコンピュータで実行される方法であって、 a)クライアントシステム上でウエブブラウザクライアント内において実行されるクライアントアプリケーションから、通信プロトコル識別子により特定され、リモートウエブサービスへ向けられるウエブソケット接続を開始する第1の開始ステップを含み、前記第1の開始ステップは、 i)前記通信プロトコル識別子に対応する安全なトークンが前記クライアントアプリケーションに対応するローカル記憶部内に存在していない場合、前記ウエブブラウザクライアントのユーザへ向けて認証チャレンジを実行するステップであって、第1のユーザ信用証明を取得し、前記第1のユーザ信用証明をゲートウェイサーバーへ送信し、前記安全なトークンを前記ゲートウェイサーバーから受信し、前記安全なトークンを前記ローカルストアインスタンス内に記憶する前記認証チャレンジを実行するステップと、 ii)前記安全なトークンを前記ローカル記憶部から取得するステップと、 iii)前記通信プロトコルの識別子専用プロトコルであり、且つ、前記安全なトークンを含む第1の接続メッセージを前記ゲートウェイサーバーへ送信する送信ステップと、を含み、 b)前記第1の接続メッセージの受信に応答して、前記リモートウエブサービスへ向けられるウエブソケット接続を前記ゲートウェイサーバーから開始する第2の開始ステップをさらに含み、前記第2の開始ステップは、 i)前記安全なトークンを特定するために前記第1の接続メッセージを検査するステップと、 ii)第2のユーザ信用証明を取得するために前記安全なトークンを評価するステップと、 iii)前記安全なトークンを置き換える時に、前記第1の接続メッセージに対応する第2の接続メッセージ内へ前記第2のユーザ信用証明を挿入するステップと、 iv)前記第2の接続メッセージを前記リモートウエブサービスへ送信するステップと、 を含むことを特徴とするコンピュータで実行される方法。」 (2)「【技術分野】 【0001】 〔関連出願との相互参照〕 本出願は、2009年5月28日出願の米国仮出願第61/181,924号の利益を主張するものである。 【0002】 本発明は一般に、非HTTPプロトコルを用いて通信を行うウエブアプリケーションクライアントとサーバーとの間で安全性の保証された接続を確立することに関し、特に、非HTTP通信プロトコルを用いるリモートサーバーベースのウエブサービスと接続するウエブブラウザベースのウエブアプリケーションクライアントに対してサポートを行う、ゲートウェイサーバー介在安全性認証及び信用証明管理システムに関する。 【背景技術】 【0003】 ウエブベース技術の現在進行中の開発の実質的な態様は、分散化され、ネットワーク化されたアプリケーションに対するサポートを増加させることに向けられている。この努力が、ウエブブラウザベースのクライアントアプリケーションと、このウエブブラウザベースのクライアントアプリケーションに対して遠隔地に配置されているサーバーシステム上で提供されるウエブサービスとの間で双方向データ送信を行うための、接続用のベースとして、WebSockets(ウエブソケット)の開発をもたらした。 【0004】 分散化されたネットワークアプリケーションは、通常、対応するサービスアプリケーションを実行するサーバーシステムとの永続的な双方向接続を通じて理想的に通信を行う専用アプリケーションを、クライアントが実行するようになった、クライアントサーバーモデルを用いるものとして構成される。接続の初期化中に認証のための信用証明がクライアントから供給される。この認証は、クライアントアプリケーションが、接続を解除するか又は他の方法で遮断するまで持続する。接続が作動可能な状態にある間は、クライアントとサーバーは、提供するサービス及び交換されるデータの性質にとって最も適切なプロトコルを用いて通信を行う。 【0005】 しかし、従来のウエブブラウザクライアントは、ページ及びHTTPプロトコル向けのものである。設計上、従来のウエブブラウザは、クライアントが1つのページから別のページへ移行するときは常に、既存のローカル状態を破棄する。何らかの関連を有する認証データを含む接続が、文書又はページ向けのローカル状態として保持される。したがって、ページ移行の自然の結果として、現行の接続が終了することになる。従来のウエブブラウザのクライアントにより、非ページ状態データをクッキーとして記憶することもできる。これらのクッキーは、サーバーシステムにより割り当てられ、これらのクッキーを操作して、サーバー定義セッションの持続のために必要となる認証済み接続の自律的復元を可能にする情報を記憶することが可能である。このようにしてセッションクッキーにアクセスし、操作することは、従来のウエブブラウザクライアントによって本来的にサポートされているHTTPプロトコルの使用に、事実上限定される。ウエブソケットのプロトコルは、ウエブソケット接続が確立される最初の接続段階中に通常のHTTPクッキーの送信を可能にするものではあるが、ウエブソケットの接続上でホストされるさらに高レベルのプロトコルは、これらのクッキーにアクセスしたり、該クッキーを使用したりすることはできない。 【0006】 したがって、ウエブブラウザクライアントの通常の動作上の性質に適応する状態を安全確実な形で機能的に維持しながら、ウエブブラウザクライアントとサーバーアプリケーションの間でウエブソケット接続及び他の非HTTPプロトコル接続を利用できるようにするシステム及び方法に対する必要性が存在する。 【発明の概要】 【発明が解決しようとする課題】 【0007】 従って、本発明の一般的目的は、ウエブブラウザクライアントが、ウエブソケット接続及びその他の非HTTPプロトコル接続に関係する状態情報を安全確実に確立し、管理することを可能にするシステム及び方法を提供することである。 【0008】 本発明においては、上記目的は、クライアントシステム及びリモートサーバーシステムと相互に動作して、分散化されたウエブアプリケーションに対する状態非依存型安全性管理を行うゲートウェイサーバーを提供することによって達成される。クライアントシステム上のウエブクライアントアプリケーションは、該クライアントアプリケーションに対応するローカル記憶個所内に安全管理されたトークンが存在しないウエブブラウザクライアントのユーザに向けて、認証問合せを行って、安全管理されたトークンを取得し、次いで、ゲートウエイサーバーとの間でユーザ信用証明を交換する。次いで、この安全管理されたトークンは、プロトコル専用接続メッセージの中に含めてゲートウェイサーバーへ送信される。該ゲートウェイサーバーは、この接続メッセージの受信に応答して、該接続メッセージを検査することにより、リモートウエブサービスに向けられたウエブソケット接続を開始して、安全管理されたトークンを回復し、この安全管理されたトークンを評価して、ユーザ信用証明を取得し、このユーザ信用証明を安全管理されたトークンに導入し、該接続メッセージをリモートウエブサービスへ送信する。」 (3)「【0039】 本発明の好ましい実施形態においては、安全なトークンがゲートウェイアプリケーション126に送信されるように、接続メッセージ134が修正される。この接続メッセージは、典型的にはプロトコル専用データパケットとして実現され、本来的にはクリアテキスト内にユーザ信用証明を記憶するものとされている、定義済みユーザ名フィールドとパスワードフィールドとを含む。接続メッセージは、ユーザ信用証明の代わりに、トークンマーカー及び安全なトークンを記憶するように、修正することが好ましい。STOMP接続メッセージの場合には、このトークンマーカー及び安全なトークンは、接続データパケットのパスワードフィールド内に記憶される。トークンマーカーは、認証制御プロセッサ90に知られており、修正されたプロトコルパケットの特定に用いられる「マジックナンバー」であることが好ましい。トークンの記憶とセッションの記憶のための安全なトークンの種類を区別するためには、異なるトークンマーカーが利用される。 【0040】 セッションを記憶する実施形態では、接続134は、HTTP接続として開始され、これによって、適用可能なセッションクッキーの、ゲートウェイサーバー38への自動転送がもたらされる。次いで、HTTP接続は、ウエブソケット接続へグレードアップされる。接続メッセージは、ウエブソケット接続が確立されたときに転送される。従って、トークンを記憶する実施形態の場合には、安全なトークン内に埋め込まれ、次いで暗号化されることになるユーザ信用証明が、接続メッセージに直接含まれることになる。セッションを記憶する実施形態では、接続メッセージ内に埋め込まれた安全なトークンは、認証制御プロセッサ90が、HTTPプロトコルから配信されたセッションクッキーをウエブソケット接続メッセージに一意に関連付けることを可能にする、セッションクッキーへの安全な参照を含む。」 6.引用文献6について 前置報告書で引用され、本願の優先日前である平成21年9月10日に頒布された刊行物である引用文献6(特開2009-201854号公報)には、図面と共に次の事項が記載されている。 (1)「【0116】 本実施形態に適用されるオンラインゲームにおいては、図14に示すように、「ランド」と呼称される複数の大グループが設けられている。プレイヤは、複数の「ランド」の中から任意の「ランド」を選択することにより、オンラインゲームに参加することができる。 【0117】 各「ランド」は、「エリア」と呼称される複数の区域が設けられており、各「エリア」は、プレイヤのゲームレベルに応じて選択可能か否かが予め決められている。各「エリア」には、「グループ」と呼称される複数の仮想的な部屋が設けられており、プレイヤがその分身となるプレイヤキャラクタをいずれかの「グループ」に入室させることにより、同一の「グループ」に入室している、他のゲーム装置で操作される他のプレイヤキャラクタとともに、モンスター等を討伐することができるようになっている。 【0118】 上述したプレイヤキャラクタを描画させるための2つのベーステクスチャを特定する情報と混合率αとは、同一の「グループ」に入室したプレイヤが操作する各ゲーム装置に相互に送られ、各ゲーム装置において同一の「グループ」に入室しているプレイヤが操作するそれぞれのプレイヤキャラクタが表示される。」 したがって、上記引用文献6には次の発明(以下、「引用発明6」という。)が記載されていると認められる。 「プレイヤは、複数の「ランド」と呼称される複数の大グループの中から任意の「ランド」を選択することにより、参加することができる、オンラインゲーム。」 第6 対比・判断 1.本願発明1について (1)対比(その1) 本願発明1と引用発明1とを対比すると、 後者の「複数のゲーム装置」と、前者の「複数の携帯端末」とは、「複数の端末」との概念で共通する。 後者の「ゲーム」、「ゲームサーバ」、「対戦」、「対戦グループへの参加の要求」及び「プログラム」は、それぞれ、前者の「ゲーム」、「サーバ装置」、「対戦」、「ゲームにおける対戦に参加するための第1の要求」及び「プログラム」に相当する。 後者の「ゲームサーバシステムが管理する特定のアクセスポイントにゲーム装置から接続すること」は、前者の「サーバ装置に対して送信した携帯端末との接続を確立する第1ステップ」に相当する。そして、前記携帯端末には、「第1の携帯端末」及び「第2の携帯端末」が包含される。 後者の「観戦モード」は、「ゲーム対戦をしているのを応援しているかのようなゲーム観戦を実行可能とする」ものであるから、後者の「ゲーム装置を観戦モードに移行させる観戦割付手段」を備える「ゲームサーバシステムとして、ゲームサーバを、動作させるプログラム」は、前者の「対戦の応援に参加する端末との接続を確立する第2ステップ」を有しているといえる。 後者の「ゲームサーバシステム」は、「他のゲーム装置から前記対戦グループへの参加の要求があった場合に、当該他のゲーム装置の前記対戦グループへの参加を許可する対戦グループ参加許可手段」を備え、「戦闘中に対戦グループへの参加要求があった場合、この対戦グループにゲーム装置を新たな参加者として登録」するものであるから、前記「ゲームサーバシステム」を動作させる後者の「プログラム」は、前者の「所定期間内に接続を確立した全ての第1の携帯端末の各ユーザを、対戦が行われる間の1つのグループとして前記対戦に参加させる第3ステップ」を有しているといえる。 後者の「戦闘モードに移行したゲーム装置から操作入力情報を受信するとともに、当該受信した操作入力情報を、前記参加が許可されたゲーム装置のうち前記操作入力情報を送信したゲーム装置以外のゲーム装置に送信する」ことは、前者の「対戦に参加しているいずれかのユーザの第1の携帯端末からイベント情報を受信した場合に、当該イベント情報を、前記対戦に参加している他のユーザの第1の携帯端末に送信する」第4ステップに相当する。 したがって、両者は、 「複数の端末と、 サーバ装置に、 ゲームにおける対戦に参加するための第1の要求を前記サーバ装置に対して送信した複数の第1の携帯端末との接続をそれぞれ確立する第1ステップと、 前記対戦の応援に参加する端末との接続を確立する第2ステップと、 所定期間内に接続を確立した全ての第1の携帯端末の各ユーザを、前記対戦が行われる間の1つのグループとして前記対戦に参加させる第3ステップと、 前記対戦に参加しているいずれかのユーザの第1の携帯端末からイベント情報を受信した場合に、当該イベント情報を、前記対戦に参加している他のユーザの第1の携帯端末に送信する第4ステップと を実行させるプログラム。」 の点で一致し、以下の点で相違する。 [相違点1] 本願発明1が、複数の「携帯」端末に「ゲームを提供する」サーバ装置であるのに対し、引用発明1のゲームサーバは、そのようなものでない点。 [相違点2] 本願発明1が、サーバ装置と携帯端末との接続を「ウェブソケットの通信規格」に従ってそれぞれ確立するのに対し、引用発明1は、そのような通信規格でない点。 [相違点3] 本願発明1が、「第1の要求を対戦の開始後にサーバ装置に対して送信した携帯端末との接続を確立しない」第1ステップを有しているのに対し、引用発明1は、そのようなステップを有していない点。 [相違点4] 本願発明1が「前記対戦を指定した」応援に参加する「ための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯」端末とも接続を確立する第2ステップを有しているのに対し、引用発明1は、所定の条件を充たさないゲーム装置を観戦モードに移行させる観戦割付手段を備え、観戦モードに移行したゲーム装置からチャット情報を受信するものである点 [相違点5] 本願発明1が「前記第1ステップにおいて前記対戦の開始までの」所定期間内に接続を確立した全ての第1の携帯端末の各ユーザを、前記対戦が行われる間の「一時的な」1つのグループとして前記対戦に参加させる第3ステップを有しているのに対し、引用発明1は、戦闘中に対戦グループへの参加要求があった場合、この対戦グループにゲーム装置を新たな参加者として登録するものである点。 (2)相違点についての判断 上記相違点4について、以下、検討する。 引用発明2は、「複数のゲーム機のそれぞれから、システム参加要求を受け付け」、「システム参加要求を受け付けた複数のゲーム機を1つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、参加要求の受付の早い順に前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定」するものであって、「見学者機」は、「ゲームの進行を見学できる状態」であるから、本願発明1の「応援」と、引用発明2の「ゲームの進行を見学できる状態」とは、ゲームに参加しているものの、対戦には参加していないとの概念で共通する。 しかし、引用発明2は、「システム参加要求を受け付けた複数のゲーム機を1つのグループとしてグループ化し、前記グループ化された複数のゲーム機のうち、参加要求の受付の早い順に前記ゲームに応じた数のゲーム機をプレイヤ機として設定し、他のゲーム機を見学者機として設定」するものであって、参加要求の受付が早ければプレイヤ機として設定され、プレイヤ機として設定されなかったゲーム機が、結果として、見学者機として設定されるものであるから、引用発明2の「システム参加要求」は、プレイヤ機として設定されることを目的とするものであって、上記相違点4に係る本願発明1の「対戦を指定した応援に参加するための第2の要求」とは相違するものである。 また、上記引用文献3乃至引用文献5より、ウェッブソケットの通信規格が周知の技術手段とはいえるものの、上記相違点4に係る本願発明1の「対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信」することは、引用文献3乃至引用文献6のいずれにも示されていないし、設計的事項といえる理由もない。 そして、本願発明1は、上記相違点4に係る本願発明1の発明特定事項により、「バトルに参加するユーザに限らず、バトルに参加するユーザを応援したいユーザにとっても、同様の理由により、多数のユーザが応援に参加可能なレイドバトルゲームの実現が困難となっている。 本発明の第4の実施形態では、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、多数のユーザがバトル及び応援に参加可能なバトルゲームを実現し得るゲーム制御方法を提供する。」(【0167】?【0168】参照。)という作用効果を奏するものである。 したがって、本願発明1は、引用文献1乃至引用文献6に基づいて、当業者が容易に発明をすることができたものとすることはできない。 2.本願発明2乃至12について 本願発明2乃至10は、本願発明1の発明特定事項にさらなる発明特定事項を追加して限定を付したものであるから、本願発明2乃至10は、上記1.(2)と同様の理由により、引用文献1乃至引用文献6に基づいて、当業者が容易に発明をすることができたものとすることはできない。 また、本願発明11は、本願発明1に対応するサーバ装置の発明であり、本願発明12は、本願発明1に対応するゲーム制御方法の発明であるから、本願発明11及び12は、上記1.(2)と同様の理由により、引用文献1乃至引用文献6に基づいて、当業者が容易に発明をすることができたものとすることはできない。 第7 原査定についての判断 平成30年8月10日付けの補正により、補正後の請求項1乃至請求項10、12は「対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2ステップ」という技術的事項を有し、また、請求項11は「対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2手段」という技術的事項を有するものとなった。 当該「対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2ステップ」または「対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2手段」は、原査定における引用文献1及び2には記載されておらず、本願の優先日前における周知技術でもないので、本願発明1乃至12は、当業者であっても、原査定における引用文献1及び2に基づいて容易に発明できたものとすることはできない 。 したがって、原査定を維持することはできない。 第8 当審拒絶理由について 1.特許法第36条第6項第1号について 当審では、請求項1?12に係る発明は、“通信規格は、ウェブソケットの通信規格”であることが特定されていないから、発明の課題を解決する手段が不明であるとの拒絶の理由を通知しているが、平成30年6月20日付けの補正において、請求項1、11及び12に「ウェブソケットの通信規格に従って」と補正された結果、この拒絶の理由は解消した。 2.特許法第36条第6項第2号について (1)当審では、請求項1、12の「第2の携帯端末から受け付けるステップ」、及び請求項11の「第2の携帯端末から受け付ける手段」の技術的内容が不明であるとの拒絶の理由を通知しているが、平成30年8月10日付けの補正において、請求項1及び12に「前記対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2ステップ」と、請求項11に「前記対戦を指定した応援に参加するための第2の要求を前記サーバ装置に対して送信した複数の第2の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第2の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第2手段」と補正された結果、この拒絶の理由は解消した。 (2)当審では、請求項1、12の各「ステップ」と、前記各「ステップ」を引用する「ステップ」との関係、及び請求項11の各「手段」と、前記各「手段」を引用する「手段」との関係の技術的内容が不明であるとの拒絶の理由を通知しているが、平成30年8月10日付けの補正において、請求項1及び12に「第1ステップ」、「第2ステップ」及び「第3ステップ」と、請求項11に「第1手段」、「第2手段」及び「第3手段」と補正された結果、この拒絶の理由は解消した。 第9 むすび 以上のとおり、原査定の理由によって、本願を拒絶することはできない。 他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
審決日 | 2018-10-29 |
出願番号 | 特願2015-130310(P2015-130310) |
審決分類 |
P
1
8・
121-
WY
(A63F)
P 1 8・ 537- WY (A63F) |
最終処分 | 成立 |
前審関与審査官 | 彦田 克文 |
特許庁審判長 |
尾崎 淳史 |
特許庁審判官 |
吉村 尚 藤本 義仁 |
発明の名称 | プログラム、サーバ装置、及びゲーム制御方法 |
代理人 | 内海 一成 |
代理人 | 杉村 憲司 |
代理人 | 岡野 大和 |