2015-020919

特願２０１４－２５６４６３「通信システム」拒絶査定不服審判事件〔平成２８年　６月３０日出願公開，特開２０１６－１１９５１２〕について，次のとおり審決する。

【結　論】 本件審判の請求は，成り立たない。

【理　由】 第１．手続の経緯 本願は，平成２６年１２月１８日の出願であって， 平成２７年３月３１日付けで審査請求がなされ，平成２７年６月４日付けで審査官により拒絶理由が通知され，これに対して平成２７年８月５日付けで意見書が提出されると共に手続補正がなされたが，平成２７年８月２０日付けで審査官により拒絶査定がなされ（謄本送達：平成２７年８月２５日），これに対して平成２７年１１月２５日付けで審判請求がなされ，平成２８年９月８日付けで当審により拒絶理由が通知され，これに対して平成２８年１０月２８日付けで意見書が提出されると共に手続補正がなされたものである。 第２．本願発明について 本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２８年１０月２８日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，次のとおりのものである。 「複数の情報端末間においてデータを複数のパケットに分割して送受信する通信システムであって， 前記複数の情報端末間において送受信されるパケットのパケットサイズを共有する第１のステップと， 前記複数の情報端末の一方において，送信対象となる情報を前記パケットサイズのパケットとして生成する第２のステップと， 前記第２のステップで生成されたパケットを前記一方の情報端末から他方の情報端末へ送信する第３のステップと， 前記他方の情報端末においてパケットを受信した際に，前記パケットサイズと異なるパケットであった場合に当該パケットは改竄されたものであると判定する第４のステップと， を行うことを特徴とする通信システム。」 第３．引用刊行物に記載の事項 １．当審による平成２８年９月８日付けの拒絶理由（以下，これを「当審拒絶理由」という」）に引用された，本願の出願前に既に公知である，特開２０１３－２５０９７８号公報（平成２５年１２月１２日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている Ａ．「【００２７】 ユーザがオンラインゲームをプレーする場合，ゲームクライアント１３０は，ネットワーク１２０によってゲームサーバ１１０とゲームパケット１４０を送受信してもよい。具体的に，ゲームパケット１４０の送受信によってオンラインゲームに必要な情報をゲームクライアント１３０とゲームサーバ１１０が交換してもよく，これによってオンラインゲームを行うことができる。ゲームクライアント１３０とゲームサーバ１１０が送受信するゲームパケット１４０の構造はオンラインゲームごとに互いに異なってもよいが，一般的にゲームパケット１４０は，プロトコルＩＤフィールド１４１，パケットサイズフィールド１４２及び少なくとも１つのプロトコルフィールド１４３～１４５を含んでもよい。ここで，プロトコルＩＤフィールド１４１は，当該パケットがいずれの情報を含むかを示すプロトコルＩＤ情報を含んでもよい。例えば，プロトコルＩＤフィールド１４１を分析すれば，当該パケットがｍｏｖｅパケットであるか，ａｔｔａｃｋパケットであるか，またはｌｏｇｉｎパケットであるかを把握する。そして，パケットサイズ１４２は各ゲームパケットのサイズに関する情報を含んでもよく，少なくとも１つのプロトコルフィールド１４３～１４５は，ゲームパケットが送信しようとする具体的な情報（例えば，ゲームクライアントのキャラクター状態情報）を含んでもよい。」 Ｂ．「図２を参照すると，一実施形態に係る不正ユーザを検出するためのオンラインゲームパケット生成方法（以下，オンラインゲームパケット生成方法）は，プロトコルＩＤ情報，パケットサイズ情報，及びゲームクライアントのキャラクター状態情報を含むオンラインゲームパケットの生成情報を取得する（Ｓ２１０）。ここで，プロトコルＩＤ情報は，当該パケットがどのような種類のパケットであるかを示す情報である。そして，パケットサイズ情報は，ゲームサーバとゲームクライアントが送受信するパケットの大きさに関する情報を含んでもよい。」（段落【００３０】より引用） Ｃ．「【００３５】 オンラインゲームパケットが第１タイプである場合，オンラインゲームパケットの生成情報は，プロトコルＩＤ情報，パケットサイズ情報及びゲームクライアントのキャラクター状態情報を含んでもよい。そして，オンラインゲームパケット生成方法は，予め決定されたプロトコルインデックステーブルを取得してもよい。ここで，プロトコルインデックステーブルは，少なくとも１つのプロトコルインデックス番号及び少なくとも１つのプロトコルインデックス番号それぞれに対応するプロトコルフィールド構造に関する情報を含んでもよい。そして，ゲームサーバ及びゲームクライアントは，プロトコルインデックステーブルを予め取得してもよい。したがって，ゲームサーバ及びゲームクライアントは，オンラインゲームパケットを受信した場合にプロトコルインデックステーブルを用いてオンラインゲームパケットを解釈する。そして，実施形態に係るプロトコルインデックステーブルは，セキュリティのために予め決定された規則によって生成または変更されてもよく，この場合，ゲームサーバ及びゲームクライアントは同じ内容のプロトコルインデックステーブルを取得してもよい。 【００３６】 そして，オンラインゲームパケット生成方法は，プロトコルインデックステーブルに基づいてキャラクター状態情報を用いてプロトコルインデックスフィールド及び少なくとも１つのプロトコルフィールドのデータ値を生成する。具体的に，オンラインゲームパケット生成方法は，生成情報を用いてプロトコルＩＤフィールド及びパケットサイズフィールドのデータ値を生成してもよい。そして，予め決定されたプロトコルインデックステーブルに基づいてゲームクライアントのキャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報を抽出してもよい。・・・・（以下省略）・・・」 Ｄ．「実施形態に係るオンラインゲームパケットの場合，プロトコルＩＤが同じ場合でも様々なパケット構造を有し得るため，不正ユーザはパケット構造を分析することができない。したがって，オンラインゲームパケット生成方法は，実施形態に係るオンラインゲームパケットを用いて不正ユーザの不正行為を防止することができ，オンラインゲームパケットが変形された不正ユーザを検出することができる。」（段落【００３８】より引用） Ｅ．「オンラインゲームパケットを受信したゲームサーバまたはゲームクライアントは，予め決定されたプロトコルインデックステーブル３２０を用いてオンラインゲームパケットを解釈する。」（段落【００４８】より引用） ２．当審拒絶理由に引用された，本願の出願前に既に公知である，特開２００６－３３８１４５号公報（平成１８年１２月１４日公開，以下，これを「引用刊行物２」という）には，関連する図面と共に，次の事項が記載されている。 Ｆ．「【００３９】 正当性判定部２０６は，クエリ送信処理部２０５で各サーバ１００に送信したクエリに対する応答を受信して当該応答の正当性を判定する。この正当性判定は，一台以上のサーバ１００間でのクエリ処理の正当性を判定するものである。具体的には，サーバ１００が３台以上ある場合には多数決で決める方法や，受信した応答を所定のルールに基づいて判断する方法がある。例えば，クライアント５００からの「参照」要求に対して「更新成功」という応答が返ってきた場合，正常であればそのような応答はあり得ないので（参照成功など参照に関する応答のはず），この応答は正しくないと判断する。また，当該応答に係るパケット中にデータ長フィールドがある場合，このデータ長フィールドの値と実際に受信したパケット長を比較し，異なる場合は正しくないと判断する。また，複数のサーバ１００の中からＭａｓｔｅｒサーバを予め１台決めておき，このサーバ１００からの応答を常に正しいと判断する。また，上記複数の方法を併用する方法もある。例えば，３台で多数決を行った結果，応答の中身が全てバラバラであり，多数派の応答を決められない場合はＭａｓｔｅｒサーバの応答を正しいと判断する。正常稼働しているサーバ１００が１つだけの場合は，そのサーバ１００からの応答を正常と判断する。なお，正常稼働しているサーバ１００の台数はサーバ管理表２０１を参照することにより認識できる。正当性判定部２０６は，正当性判定の結果，正当でない応答を返したサーバ１００を検出すると，サーバ管理表２０１及び送信キュー２０３から当該サーバ１００についてのエントリを削除する。これにより，当該サーバ１００にはクエリが送信されなくなるので，該サーバ１００はシステムから切り離されたことになる。」 第４．引用刊行物に記載の発明 １．上記Ａの「ユーザがオンラインゲームをプレーする場合，ゲームクライアント１３０は，ネットワーク１２０によってゲームサーバ１１０とゲームパケット１４０を送受信してもよい」という記載から，引用刊行物１には， “ゲームクライアントと，ゲームサーバとの間で，ゲームパケットを送受信する，オンラインゲームシステム”が記載されていることが読み取れる。 ２．上記Ａの「ゲームクライアント１３０とゲームサーバ１１０が送受信するゲームパケット１４０の構造はオンラインゲームごとに互いに異なってもよいが，一般的にゲームパケット１４０は，プロトコルＩＤフィールド１４１，パケットサイズフィールド１４２及び少なくとも１つのプロトコルフィールド１４３～１４５を含んでもよい」という記載，同じく，上記Ａの「パケットサイズ１４２は各ゲームパケットのサイズに関する情報を含んでもよく」という記載から，引用刊行物１においては， “ゲームパケットのパケットサイズフィールドに，ゲームパケットのサイズに関する情報が含まれる”ものであることが読み取れる。 ３．上記Ｂの「オンラインゲームパケット生成方法（以下，オンラインゲームパケット生成方法）は，プロトコルＩＤ情報，パケットサイズ情報，及びゲームクライアントのキャラクター状態情報を含むオンラインゲームパケットの生成情報を取得する」という記載，同じく，上記Ｂの「パケットサイズ情報は，ゲームサーバとゲームクライアントが送受信するパケットの大きさに関する情報を含んでもよい」という記載，上記Ｃの「オンラインゲームパケットの生成情報は，プロトコルＩＤ情報，パケットサイズ情報及びゲームクライアントのキャラクター状態情報を含んでもよい」という記載，及び，同じく，上記Ｃの「生成情報を用いてプロトコルＩＤフィールド及びパケットサイズフィールドのデータ値を生成してもよい」という記載から，引用刊行物１においては， “生成情報にゲームパケットの大きさに関する情報及びゲームクライアントのキャラクター状態情報が含まれ，前記生成情報を用いて，プロトコルＩＤフィールド及びパケットサイズフィールドの情報が生成される”ものであることが読み取れる。 ４．上記Ｃの「ゲームサーバ及びゲームクライアントは，プロトコルインデックステーブルを予め取得してもよい」という記載，及び，同じく，上記Ｃの「ゲームサーバ及びゲームクライアントは同じ内容のプロトコルインデックステーブルを取得してもよい」という記載から，引用刊行物１においては， “ゲームサーバ及びゲームクライアントは，同じ内容のプロトコルインデックステーブルを予め取得する”ことが読み取れる。 ５．上記Ｃの「予め決定されたプロトコルインデックステーブルに基づいてゲームクライアントのキャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報を抽出してもよい」という記載，及び，上記Ｅの「オンラインゲームパケットを受信したゲームサーバまたはゲームクライアントは，予め決定されたプロトコルインデックステーブル３２０を用いてオンラインゲームパケットを解釈する」という記載から，引用刊行物１においては， “ゲームパケットを受信したゲームサーバまたはゲームクライアントは，予め決定されたプロトコルインデックステーブルに基づいてゲームクライアントのキャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報を抽出して，ゲームパケットを解釈する”ものであることが読み取れる。 ６．上記Ｄの「オンラインゲームパケット生成方法は，実施形態に係るオンラインゲームパケットを用いて不正ユーザの不正行為を防止することができ，オンラインゲームパケットが変形された不正ユーザを検出することができる」という記載と，上記５．において検討した事項から，引用刊行物１においては， “ゲームパケットを受信したゲームサーバまたはゲームクライアントは，予め決定されたプロトコルインデックステーブルに基づいてゲームクライアントのキャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報を抽出して，ゲームパケットを解釈することで，ゲームパケットが変形された不正ユーザを検出することができる”ことが読み取れる。 ７．以上，１．～６．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。 “ゲームクライアントと，ゲームサーバとの間で，ゲームパケットを送受信する，オンラインゲームシステムであって， 前記ゲームパケットのパケットサイズフィールドに，前記ゲームパケットのサイズに関する情報が含まれ， 生成情報に前記ゲームパケットの大きさに関する情報及び前記ゲームクライアントのキャラクター状態情報が含まれ，前記生成情報を用いて，プロトコルＩＤフィールド及びパケットサイズフィールドの情報が生成され” 前記ゲームサーバ及び前記ゲームクライアントは，同じ内容のプロトコルインデックステーブルを予め取得し，” 前記ゲームパケットを受信した前記ゲームサーバまたは前記ゲームクライアントは，予め決定された前記プロトコルインデックステーブルに基づいて前記ゲームクライアントのキャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報を抽出して，前記ゲームパケットを解釈することで，前記ゲームパケットが変形された不正ユーザを検出することができる，ゲームシステム。” 第５．本願発明と引用発明との対比 １．引用発明における「ゲームクライアント」と「ゲームサーバ」とは，「オンライン」で，「ゲームパケット」を送受信しているのであるから，本願発明の「複数の情報端末」に相当し，引用発明における「オンラインゲームシステム」が，本願発明における「通信システム」に相当する。 ２．引用発明においても，「ゲームクライアント」と「ゲームサーバ」との間で送受信される「データ」は，「パケット」として送受信されていることは明らかであるから， 上記１．において検討した事項と併せると， 引用発明における「ゲームクライアントと，ゲームサーバとの間で，ゲームパケットを送受信する，オンラインゲームシステム」と， 本願発明における「複数の情報端末間においてデータを複数のパケットに分割して送受信する通信システム」とは， “複数の情報端末間においてデータをパケットにして送受信する通信システム” である点で共通する。 ３．引用発明において，「ゲームサーバ及び前記ゲームクライアントは，同じ内容のプロトコルインデックステーブルを予め取得」することは，「ゲームサーバ」と，「ゲームクライアント」との間で，送受信する「パケット」を「解釈する」ために必要な情報を共有することに他ならないので， 本願発明における「前記複数の情報端末間において送受信されるパケットのパケットサイズを共有する第１のステップ」と， “複数の情報端末間において送受信されるパケットに関する情報を共有する第１のステップ”である点で共通する。 ４．引用発明において，「生成情報を用いて，プロトコルＩＤフィールド及びパケットサイズフィールドの情報が生成され」ることは，「ゲームパケット」を生成する工程の一部であることは明らかであり，「パケットサイズフィールドの情報」とは，「ゲームパケットの大きさ」に他ならないから，引用発明においても，「ゲームパケットの大きさ」に示されたサイズのパケットが生成されることは明らかである。 従って，上記において検討した，引用発明において，“ゲームパケットの大きさに示されたサイズのパケットを生成すること”と， 本願発明における「複数の情報端末の一方において，送信対象となる情報を前記パケットサイズのパケットとして生成する第２のステップ」とは， “複数の情報端末の一方において，送信対象となる情報を予め定められたパケットサイズのパケットとして生成する第２のステップ”である点で共通する。 ５．引用発明においては，上記４．において検討した「パケット」を，「ゲームパケットを受信した前記ゲームサーバまたは前記ゲームクライアント」，即ち，“ゲームサーバまたは前記ゲームクライアント”の何れかで「受信」するのであるから，該「パケット」を，該「パケット」を生成した側から送信していることは明らかである。 よって，引用発明における当該“送信する”ことが， 本願発明における「第２のステップで生成されたパケットを前記一方の情報端末から他方の情報端末へ送信する第３のステップ」に相当する。 ６．引用発明において，「予め決定された前記プロトコルインデックステーブルに基づいて前記ゲームクライアントのキャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報を抽出して，前記ゲームパケットを解釈することで，前記ゲームパケットが変形された不正ユーザを検出する」ことは， “ゲームクライアントと，ゲームサーバの間で，予め共有したプロトコルインデックステーブルに基づいて，受信したパケットに含まれる情報が，前記テーブルの情報と一致しない場合に，受信したパケットが変形されていることを検出する”ものであるから， 本願発明における「他方の情報端末においてパケットを受信した際に，前記パケットサイズと異なるパケットであった場合に当該パケットは改竄されたものであると判定する第４のステップ」とは， “他方の情報端末においてパケットを受信した際に，前記パケットに含まれる情報が，予め共有した情報と異なるパケットであった場合に当該パケットは改竄されたものであると判断する第４のステップ”である点で共通する。 ７．以上１．～６．において検討した事項から，本願発明と，引用発明との一致点，及び，相違点は，次のとおりである。 ［一致点］ 複数の情報端末間においてデータをパケットにして送受信する通信システムであって， 前記複数の情報端末間において送受信されるパケットに関する情報を共有する第１のステップと， 複数の情報端末の一方において，送信対象となる情報を予め定められたパケットサイズのパケットとして生成する第２のステップと， 第２のステップで生成されたパケットを前記一方の情報端末から他方の情報端末へ送信する第３のステップと， 前記他方の情報端末においてパケットを受信した際に，前記パケットに含まれる情報が，予め共有した情報と異なるパケットであった場合に当該パケットは改竄されたものであると判断する第４のステップと， を行うことを特徴とする通信システム。 ［相違点１］ “データをパケットにして送受信する”に関して， 本願発明においては，「データを複数のパケットに分割して送受信する」のに対して， 引用発明においては，「ゲームクライアント」と，「ゲームサーバ」との間で送受信されるデータを，「複数のパケットに分割」するかについて，特に言及されていない点。 ［相違点２］ “パケットに関する情報を共有する”に関して， 本願発明においては，共有する情報は，「パケットサイズ」であるのに対して， 引用発明においては，「プロトコルインデックステーブル」であって，「パケットサイズ」を共有するかについて，明確には示されていない点。 ［相違点３］ “予め定められたパケットサイズ”に関して， 本願発明においては，“複数の情報端末間において，共有されたパケットサイズ”であるのに対して， 引用発明においては，“共有されたパケットサイズ”であるか不明である点。 ［相違点４］ “パケットに含まれる情報”に関して， 本願発明においては，「パケットサイズ」であるのに対して， 引用発明においては，「キャラクター状態情報に対応するプロトコルインデックス番号及びプロトコルフィールド構造に関する情報」であって，「パケットサイズ」を用いる点について，特に言及されていない点。 第６．相違点についての当審の判断 １．［相違点１］について 複数の情報端末間において，送信すべきデータを，所定のサイズのパケットに分割して送信することは，引例を示すまでもなく，当業者には，本願の出願前に周知の技術事項である。引用発明においても，パケットを用いている以上，送信すべきデータのサイズに応じて，複数のパケットの分割して送信するよう構成することは，当業者が適宜なし得る事項に過ぎない。 よって，［相違点１］は，格別のものではない。 ２．［相違点２］～［相違点４］について 送信したパケットのサイズが，該パケットのサイズを示す情報と一致しない場合に，該パケットが正しくないと判断するようなことは，上記Ｆに引用した，引用刊行物２の記載内容にもあるとおり，当業者には周知の技術事項である。 引用発明においても，「ゲームクライアント」と，「ゲームサーバ」との間で，「同じ内容のプロトコルインデックステーブル」を共有し，当該情報を，送受信する「パケット」の改竄を判定するために用いており，また，「パケット」の「サイズ」に関する情報も生成していることから，引用発明において，共有する情報として，“パケットサイズ情報”を加え，該“サイズ情報”を用いて，「パケット」の改竄を判断するよう構成することは，当業者が適宜なし得る事項である。 よって，［相違点２］～［相違点４］は，格別のものではない。 ３．上記１．，及び，２．において検討したとおりであるから，上記で検討したごとく，［相違点１］～［相違点４］はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。 なお，審判請求人は，平成２８年１０月２８日付けの意見書（以下，これを「意見書」という）において， 「引用刊行物１では，プロトコルインデックスフィールドの他に各パケットのサイズを示す情報が各パケットに添付されている（引用刊行物の図３，図５等参照）。すなわち，引用刊行物１では，サーバとクライアントとの間でパケットサイズを共有するような構成とされておらず，パケットサイズはパケット毎に載せられて通信されることが前提されている。言い換えると，引用刊行物１では，サーバとクライアントとの間でパケットサイズを共有するような構成はまったく想定されていなかったことを示している。 さらには，引用刊行物１に係る技術では，パケット毎にパケットサイズを示す情報が含まれており，サーバとクライアントとの間でパケットサイズを共有する構成を排除するようなパケットの構成が採用されている。 また，引用刊行物２では，データ長の情報をパケットに含めて送信し，そのデータ長とパケット長とを比較して改竄を検出する技術が開示されている，しかしながら，当該刊行物においても，サーバとクライアントとの間でパケットサイズを共有しておくような構成は示唆されていない。 すなわち，引用刊行物１では，パケットサイズを共有し，それによってパケットの改竄を検出しようという技術的思想はなく，パケットサイズを含むパケットの構成を採用している点からもそのような技術的思想は積極的に排除されている。さらに，引用刊行物２及び３にも，パケットサイズを共有するという技術的思想は示唆されていない。 そうすると，本願請求項１に係る発明及びそれらのいずれかに従属する発明は，引用刊行物１及び２に基づいていわゆる当業者が想到できたものではなく，これらの発明はいずれも特許法第２９条第２項の規定に該当するものではない。」 旨主張しているが，引用発明において，「ゲームサーバ」と，「ゲームクライアント」間で，改竄の検出するために共有する情報として，パケットのサイズを用いることの容易性については，上記において検討したとおりであり，引用発明において，「パケットサイズを含むパケットを採用」しているのは，通常のパケットのプロトコルに準拠したためであり，改竄を検出するための情報として，パケットのサイズを排除する目的ではないことは明らかである。 以上において指摘したとおりであるから，意見書における審判請求人の主張は採用できない。 第７．むすび したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。 よって，結論のとおり審決する。