【事件の表示】
　特願２０１２−５２２８９２「ベスト・エフォート型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムおよび方法」拒絶査定不服審判事件〔平成２３年　２月　３日国際公開、ＷＯ２０１１／０１４３８２、平成２５年　１月１０日国内公表、特表２０１３−５０１４０１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２０１０年７月２０日（パリ条約による優先権主張外国庁受理２００９年７月３１日、米国）を国際出願日とする出願であって、平成２５年５月１６日付けで拒絶理由が通知され、平成２５年８月１３日付けで手続補正がなされ、平成２６年１月２０日付けで拒絶査定がされ、平成２６年５月２３日に拒絶査定不服審判が請求され、平成２７年４月２０日付けで当審が最後の拒絶理由を通知し、平成２７年１０月２１日付けで手続補正がなされたものである。
２．平成２７年１０月２１日付けの手続補正について
　平成２７年１０月２１日付けの手続補正（以下「本件補正」という。）は、平成２７年４月２０日付けの当審の拒絶理由における
「２．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
請求項１について
　「（ｉ）アプリケーション識別子及び（ｉｉ）前記データ・パケットについてのインターネット層よりも上位にあるインターネット・プロトコル・スイートの少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを取得」について、「少なくとも１つ」の対象が、（ｉ）及び（ｉｉ）から「少なくとも１つ」であるのか（ｉｉ）から「少なくとも１つ」であるのかが不明である。
　前者であれば（ｉ）又は（ｉｉ）のいずれかを取得すれば良い。
　後者であれば(ｉ）は必ず取得し、（ｉｉ）を構成する「インターネット層よりも上位にある層に関連付けられるプロトコルのタイプ」の内の「少なくとも１つ」を取得する必要がある。
　なお、前者を意味する場合、「前記パラメータは、前記少なくとも１つの層に関連付けられるプロトコルのタイプに関連する」ので、（ｉｉ）は必ず取得する必要があるから、記載を検討されたい。」
　に対して
「（２）理由２について
　手続補正書に示されましたように、請求項１を補正しました。これにより、本願は特許法第３６条第６項第２号に規定する要件を充足するに至ったものと思料致します。」（平成２７年１０月２１日付けの意見書）
　及び
「審判官殿は、本願の請求項１に関し、「『（ｉ）アプリケーション識別子及び（ｉｉ）前記データ・パケットについてのインターネット層よりも上位にあるインターネット・プロトコル・スイートの少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを取得』について、『少なくとも１つ』の対象が、（ｉ）及び（ｉｉ）から『少なくとも１つ』であるのか（ｉｉ）から『少なくとも１つ』であるのかが不明である・・・前者であれば（ｉ）又は（ｉｉ）のいずれかを取得すれば良い・・・」とご指摘なさいました。
　請求項１の上記記載はここで言う「前者」に相当します。」（平成２７年１０月２７日付けの上申書）
　と記載しているように、拒絶理由通知に係る拒絶の理由に示す事項についてする不明瞭な記載の釈明に該当するものであるから、特許法第１７条の２第５項第４号に該当する。
　また、特許法第１７条の２第３項及び第４項の規定を満たしているから、本件補正を認める。
３．本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は、平成２７年１０月２１日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものと認める。
「ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムであって、
　前記システムは、コア・ネットワークとモバイル機器との間に接続されたプロトコル専用プロセッサを含み、
　前記プロトコル専用プロセッサは、
　　前記ＢＥ型通信リンクを介してデータ・パケットを受信し、
　　前記データ・パケットの分析を実行することにより、（ｉ）アプリケーション識別子、及び（ｉｉ）前記データ・パケットについてのインターネット層よりも上位にあるインターネット・プロトコル・スイートの少なくとも１つの層に関連付けられるプロトコルのタイプ、のうちの少なくとも１つを取得し、そして、
　　前記データ・パケットが無線アクセス・ネットワークでサービス品質（ＱｏＳ）処理を受けると識別されるように、（ｉ）アプリケーション識別子、及び（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプ、のうちの前記取得した少なくとも１つに応じて前記データ・パケット用のパラメータを決定するように構成され、
　前記パラメータは、前記プロトコルのタイプに関連するものであり、
　前記プロトコル専用プロセッサは、前記データ・パケットが前記ＢＥ型通信リンク上で前記コア・ネットワークから前記モバイル機器へ向けて送信される順方向リンク・パケットである場合に、前記データ・パケットが前記コア・ネットワークを出た後に、前記分析を実行するように構成され、そして、
　前記プロトコル専用プロセッサは、前記データ・パケットが前記ＢＥ型通信リンク上で前記モバイル機器から前記コア・ネットワークへ向けて送信される逆方向リンク・パケットである場合に、前記データ・パケットが前記コア・ネットワークに到着する前に、前記分析を実行するように構成されていることを特徴とする、システム。」
４．当審の拒絶理由
　一方、当審において平成２７年４月２０日付けで通知した拒絶理由の概要は、本願発明は、本願の優先権主張の日前の２００７年２月１日に頒布された米国特許出願公開第２００７／００２５３５９号明細書（以下「引用例１」という。下線は当審が付与。）に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない、というものを含むものである。
５．引用例
　引用例１には、
「[0014] 
FIG.1 is a block diagram of one embodiment of a system for providing a quality of service for an endpoint.
[0015] According to the illustrated embodiment, network system 10 operates to provide services such as communication sessions to endpoints such as mobile node 20. A communication session may refer to an active communication between endpoints, measured from endpoint to endpoint. Information is communicated during a communication session. Information may refer to voice, data, text, audio, video, multimedia, control, signaling, other information, or any combination of the preceding. System 10 may communicate information in packets. A packet may comprise a bundle of data organized in a specific way for transmission, and a frame may comprise the payload of one or more packets organized in a specific way for transmission. 
A packet-based communication protocol such as Internet Protocol (IP) may be used to communicate the packets.
（当審訳：
[0014]
図１は、エンドポイントのサービス品質を提供するためのシステムの一実施形態のブロック図である。
[0015]図示した実施形態によれば、ネットワークシステム10は、移動ノード20のようなエンドポイントへの通信セッションのようなサービスを提供するように動作する。通信セッションはエンドポイント間のアクティブな通信を参照し、エンドポイントからエンドポイントまで測定する。情報は、通信セッション中に通信される。情報は、音声、データ、テキスト、オーディオ、ビデオ、マルチメディア、制御、シグナリング、他の情報、またはこれらの任意の組合せを参照することができる。システム10は、情報をパケットで通信してもよい。パケットは、送信のための特定の方法で編成されたデータの束を含んでもよく、フレームは送信のために特定の方法で編成された１つまたは複数のパケットのペイロードを含むことができる。
インターネットプロトコル（IP）のようなパケットベースの通信プロトコルは、パケットを通信するために使用することができる。
「[0027] According to one embodiment, 
GGSN 34 is operable to recognize a QoS decision factor of a context 60 and identify a quality of service associated with the factor.
Example QoS decision factors include content communicated during a context 60, a software application requested for a context 60, a service requested for a context 60, or any suitable combination of the preceding.
（当審訳：
[0027]一実施形態によれば、
GGSN34は、コンテキスト60のQoS決定係数を認識し係数に関連するサービス品質を認定するように動作可能である。
QoS決定係数の例は、コンテキスト60の間に送信されたコンテンツ、コンテキスト60のために要求されたソフトウェアアプリケーション、またはコンテキスト60のために要求されたサービス、又はこれらの任意の適切な組合せを含む。
「[0029] According to another embodiment, 
a QoS decision factor may refer to a software application requested for a context 60. Example software applications may include electronic mail, voice, video, web access, other software application, or any combination of the preceding.
（当審訳：
[0029]別の実施形態によれば、
QoSの決定係数は、コンテキスト60のために要求されたソフトウェアアプリケーションを参照することができる。ソフトウェアアプリケーションは、電子メール、音声、ビデオ、ウェブアクセス、その他のソフトウェアアプリケーション、またはこれらの任意の組合せを例として含む。
「[0034] 
Inspector 50 may represent a network device that inspects packets to identify applications initiated by mobile node 20.
inspector 50 may be a part of GGSN 34.
[0035] 
GGSN 34 or inspector 50 may identify a QoS decision factor from signaling messages. The QoS decision factor may be identified from the messages in any suitable manner.
（当審訳：
[0034]
インスペクタ50は、移動ノード20によって開始されたアプリケーションを認定するためにパケットを検査するネットワークデバイスを表す。
インスペクタ50は、GGSN34の一部であってもよい。
[0035]
GGSN34またはインスペクタ50は、シグナリングメッセージによりQoS決定係数を認定することができる。QoS決定係数は、任意の適切な方法でメッセージにより認定することもできる。
　の記載があるから、
「エンドポイントのサービス品質を提供するためのシステムであって、
　IPのようなパケットベースの通信プロトコルは、パケットを通信するために使用することができ
　GGSN34は、コンテキスト60のQoS決定係数を認定し係数に関連するサービス品質を認定するように動作可能であり、
　QoS決定係数の例は、コンテキスト60の間に送信されたコンテンツ、コンテキスト60のために要求されたソフトウェアアプリケーション、またはコンテキスト60のために要求されたサービス、又はこれらの任意の適切な組合せを含み、
　QoSの決定係数は、コンテキスト60のために要求されたソフトウェアアプリケーションを参照することができ、ソフトウェアアプリケーションは、電子メール、音声、ビデオ、ウェブアクセス、その他のソフトウェアアプリケーション、またはこれらの任意の組合せを例として含み、
　インスペクタ50は、移動ノード20によって開始されたアプリケーションを認定するためにパケットを検査するネットワークデバイスであり、
　インスペクタ50は、GGSN34の一部であってもよく、GGSN34またはインスペクタ50は、QoS決定係数は、任意の適切な方法でメッセージにより認定することができる
　システム」
　の発明が引用例１に記載されている。（以下「引用発明」という。）
６．本願発明と引用発明の対比
　引用発明の「QoS決定係数」は、コンテキストの間に送信されたコンテンツや、電子メール、音声、ビデオ、ウェブアクセスなどのソフトウェアアプリケーションを参照することができるものであって、「コンテンツ」が「データパケット」により送信されることは技術常識であるから、本願発明の「データ・パケット用のパラメータ」に相当するとともに、「アプリケーション用のパラメータ」にも相当する。
　また、上記によれば、引用発明の「パラメータ」は、電子メール、音声、ビデオなどの「プロトコルのタイプ」に関連しているといえる。
　「IPのようなパケットベースの通信プロトコル」は、ベストエフォート型の通信プロトコルであるから、引用発明の「電子メール、音声、ビデオ、ウェブアクセス」を例とする「ソフトウェアアプリケーション」は請求項１記載の発明の「ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション」に相当する。
　また、引用発明のインスペクタ50は、アプリケーションを認定するためにパケットを検査し、QoS決定係数をメッセージにより認定するネットワークデバイスであって、「パケットの検査」や「認定」にプロセッサを用いることは当然であるから、「プロトコル専用プロセッサ」といえる。
　そして、インスペクタ50は、「IPのようなパケットベースの通信プロトコル」により動作しているから、QoS決定係数を認定する「メッセージ」は、「データ・パケット」としてインスペクタ50が受信し、分析を実行することは当然である。
　したがって、本願発明と引用発明とは、
「ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムであって、
　前記システムは、プロトコル専用プロセッサを含み、
　前記プロトコル専用プロセッサは、
　　前記ＢＥ型通信リンクを介してデータ・パケットを受信し、
　　前記データ・パケットの分析を実行し、そして、
　　前記データ・パケット用のパラメータを決定するように構成され、
　前記パラメータは、前記プロトコルのタイプに関連するものであり、
　前記プロトコル専用プロセッサは、前記データ・パケットが前記ＢＥ型通信リンク上のパケットである場合に、前記分析を実行するように構成されていることを特徴とする、システム。」
　で一致し、下記の点で相違する。
　相違点１
　プロセッサが接続されている場所に関し、引用発明では、GGSNであるのに対し、本願発明では、「コア・ネットワークとモバイル機器との間に接続され」ており、そのため、「前記コア・ネットワークから前記モバイル機器へ向けて送信される順方向リンク・パケットである場合に、前記データ・パケットが前記コア・ネットワークを出た後に、前記分析を実行」し、「前記モバイル機器から前記コア・ネットワークへ向けて送信される逆方向リンク・パケットである場合に、前記データ・パケットが前記コア・ネットワークに到着する前に、前記分析を実行」する点。
　相違点２
　アプリケーションに対応したQoS決定係数を求めるにあたり、引用発明では、シグナリングメッセージや任意の適切な方法でメッセージにより識別するのに対し、本願発明では、「（ｉ）アプリケーション識別子及び（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの前記取得した少なくとも１つ」により識別を取得し、該「（ｉ）アプリケーション識別子及び（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの前記取得した少なくとも１つ」に応じてデータ・パケット用のパラメータを決定する点。
７．当審の判断
　上記相違点について検討する。
　相違点１について
　特開２０００−３４９７６９号公報（以下「引用例２」という。下線は当審が付与。）には、
「【００６９】実施の形態１．図１は、
本発明の実施の形態１にかかるパラメータ決定装置の分類を示す図表である。実施の形態１にかかるパラメータ決定装置は、
ネッワーク機器として、またはネットワーク機器内に配置されるかに分類される。さらに、
アプリケーションからのＱｏＳに関する要求に基いてＱｏＳに関するパラメータを決定するか、
に分類される。
「【００８５】実施の形態２．実施の形態２では、図１に示すアプローチ２に対応するパラメータ決定装置、すなわち、
ネットワーク機器としてまたはネットワーク機器内に配置され、独立動作を行うパラメータ決定装置を例に挙げる。
　【００８６】実施の形態２にかかる通信システムは、
図８の（ａ）に示すように、パラメータ決定装置２２が、複数の端末２１ａ〜２１ｃ、および交換機またはルータ等のネットワーク機器２３と接続され、ネットワーク内に専用装置として設置される場合と、図８の（ｂ）に示すように、パラメータ決定装置２４が、既存の交換機またはルータ等のネットワーク機器２５に内蔵される場合とがある。
　の記載と共に、下記図８（ａ）には、端末とルータの間にパラメータ決定装置が接続されていること、下記図８（ｂ）には、端末が接続されているルータにパラメータ決定装置が内蔵されていること、が記載されている。
　上記引用例２によれば、「アプリケーションからのＱｏＳ要求に基づいてＱｏＳパラメータを決定する装置は、端末とルータ間の専用装置、端末が接続されているルータ等のネットワーク機器に内蔵される場合がある」ことが周知である。
　そうすると、引用発明においても、ＱｏＳパラメータを決定する装置を端末とルータ間や端末が接続されているネットワーク機器、すなわち「コア・ネットワークとモバイル機器との間に接続」することで、「前記コア・ネットワークから前記モバイル機器へ向けて送信される順方向リンク・パケットである場合に、前記データ・パケットが前記コア・ネットワークを出た後に、前記分析を実行」し、「前記モバイル機器から前記コア・ネットワークへ向けて送信される逆方向リンク・パケットである場合に、前記データ・パケットが前記コア・ネットワークに到着する前に、前記分析を実行」するようにすることは、当業者が容易に想到しうることである。
　相違点２について
　特開平９−３３１３６０号公報（以下「引用例３」という。下線は当審が付与。）には、
「【解決手段】ＬＡＮとＡＴＭ網を相互に接続し、データフレームの中継転送処理を行うネットワーク間中継装置を、
データフレームを前記ＬＡＮから前記ＡＴＭ網へ中継する際に
アプリケーション識別子により、データを判別する手段と、
上記のデータ判別要素個別
によりＱＯＳクラスを設定する手段とを有する
「【００１４】（５）
アプリケーション識別子別にＱＯＳクラスを設定する場合
データフレーム中のデータ部がＩＰパケットであればＩＰパケット
を調べて、ＱＯＳ管理テーブル２０８を参照する。
　の記載があるから、「ＬＡＮから受信したデータフレーム内のＩＰパケットを調べることによって得られるアプリケーション識別子により、データを判別し、ＱＯＳクラスを設定する」ことは周知である。
　ＱｏＳクラスはデータ・パケットを処理するパラメータであるから、引用発明において、同じくデータ・パケットを処理するパラメータであるＱｏＳ決定係数を、アプリケーション識別子を抽出して設定するようになすことは容易である。
　一般に、本願発明における択一的に選択する部分についていずれかを選択したものが、引用発明に基づいて当業者が容易に発明をすることができたものであるといえる場合、本願発明全体についても、引用発明に基づいて当業者が容易に発明をすることができたものであるといえるから、本願発明と引用発明との対比を行うに当たっては、本願発明において択一的に選択する部分についていずれかを選択したものをその対象とすれば足りる。
　そうすると、「（ｉ）アプリケーション識別子」を取得し、該取得した「（ｉ）アプリケーション識別子」に応じてデータ・パケット用のパラメータを決定することが、引用発明に基づいて当業者が容易に発明をすることができたものであるから、相違点２についても、引用発明から当業者が容易に発明をすることができたものといえる。
８．請求人の主張について
　相違点２に関して、「引用例３」である「引用文献５」に関して、請求人は、平成２７年１０月２１日付けの意見書において、
「しかしながら、本願発明は、「ベストエフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステム」に関するものであって、ＱｏＳ処理を必ずしも必要としません。このため、請求項１に係る発明は、「ＢＥ型通信リンクを介してデータ・パケットを受信し」、「（ｉ）アプリケーション識別子、及び（ｉｉ）前記データ・パケットについてのインターネット層よりも上位にあるインターネット・プロトコル・スイートの少なくとも１つの層に関連付けられるプロトコルのタイプ、のうちの少なくとも１つを取得し」ています。」
「また、引用文献５には、ＬＡＮとＡＴＭ網を相互に接続し、ＱｏＳクラスを設定することが記載されています（段落［００１２］等）。しかしながら、引用文献５もＢＥ型通信リンクを介して受信したデータ・パケットに基づき処理をするものではございません。」
　と主張し、平成２７年１０月２７日付けの上申書において、
「本願発明は、ベスト・エフォート（ＢＥ）型通信リンクにおいてサービスされるアプリケーション用のパラメータを制御するためのシステムと関連します。ベスト・エフォート型の通信リンクは技術的に通信品質を保証することができない通信ネットワークに関連するものです。たとえば、ＮＴＴＰＣコミュニケーションズ社がｗｅｂにて公開する用語解説辞典（http://www.nttpc.co.jp/yougo/）によれば、ＢＥ型通信とは、「技術的な都合で、『必ず○Ｍｂｐｓの速度を保証します』ということができない」通信であると説明しています。通信速度を保証できない以上、ＱｏＳを保証することはできません。したがって、本願明細書にも記載される通り、ＢＥ型通信は「ＱｏＳ処理を必要とするものとして特に識別されていないアプリケーションをサービスする」ために使用されます（段落［００１２］参照）。
　補正後の請求項１には「前記ＢＥ型通信リンクを介してデータ・パケットを受信し」、「前記データ・パケットの分析を実行する」ことが記載されております。したがって、本願発明は（ｉ）アプリケーション識別子及び（ｉｉ）前記少なくとも１つの層に関連付けられるプロトコルのタイプのうちの少なくとも１つを、ＢＥ型通信リンクを介して受け取るデータ・パケットに基づいて決定しております（上記請求項１の第４段落および第５段落参照）。」
「引用文献５はＬＡＮとＡＴＭネットワークとの間で中継されるデータ・フレームを開示しています。ＡＴＭネットワークは、ＢＥ型の通信ではなくギャランティ型の通信です。したがって、引用文献５の発明は通信品質を保証するネットワークであるギャランティ型の通信と関連し、ます。このように、引用文献５の発明は本願発明とは全く異なるものです。したがって、引用文献１の発明に引用文献５の技術や発明を組み合わせることは、当業者であっても容易ではないものと思料します。」
　と主張している。
　しかし、引用例３は、「データフレームを前記ＬＡＮから前記ＡＴＭ網へ中継する際」に行う処理であるから、ＬＡＮからデータフレームを受信していることは明らかであり、ＬＡＮはベスト・エフォート型通信リンクである。
　また、引用例３のデータフレームはＩＰパケットを転送するフレームであるから、「データ・パケットを受信」しているといえる。
　上記によれば、引用例３は「ＢＥ型通信リンクを介してデータ・パケットを受信」して、該受信したパケットの「アプリケーション識別子」によりＱｏＳクラスを設定しているから、「前記データ・パケットの分析を実行」しているといえる。
　したがって、請求人の主張は採用することができない。
９．むすび
　以上のとおりであるから、本願発明は、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、他の請求項について論及するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。