【事件の表示】
　特願２００７−５２６４７６「フロー処理」拒絶査定不服審判事件〔平成１８年　１月　５日国際公開、ＷＯ２００６／０００６２９、平成２０年　１月２４日国内公表、特表２００８−５０２２４４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明 
　本願は、２００５年　６月２８日（パリ条約による優先権主張外国庁受理２００４年　６月２８日、（ＵＳ）米国）を国際出願日とする出願であって、平成２２年　５月２６日付けで拒絶査定がなされ、これに対し、平成２２年　７月２２日付けで審判請求がなされたものである。
　特許請求の範囲の請求項３３に係る発明（以下、「本願発明」という。）は、明細書、特許請求の範囲及び図面の記載からみて、平成２１年１２月　３日付け手続補正書の特許請求の範囲の請求項３３に記載された以下のとおりのものと認める。 
　
「　【請求項３３】
　データパケットを受信する手段と，
　前記パケットデータフローに適用すべき規則を決定する手段と，
　前記パケットデータフローに対して以前に決定した少なくとも１つの出力時データ処理操作に関係する将来操作識別子を指定する手段と，
を備える装置。」 
　 
２．引用発明 
　これに対して、原査定の拒絶理由に引用された特開２００２−２４７０８６号公報（以下、「引用例」という。）には、「ルータとそのパケット交換方法、及びパケット交換プログラム」として、図面とともに以下の事項が記載されている。
 　
イ．「【請求項１】  パケットを中継するルータにおいて、
パケットを送受する複数のパケット処理部と、
パケットを受信した前記パケット処理部から、当該パケットを送信する前記パケット処理部へ、当該パケットを転送するスイッチ処理部を備え、
前記パケット処理部は、
外部から受信したパケットがＩＰパケット及びＭＰＬＳパケットのいずれの場合においても、当該パケットに対し装置内ヘッダを付加して、ＩＰパケットの装置内転送時の形式に当該パケットを変換し、前記変換されたパケットを前記スイッチ処理部に送ることにより、
ＩＰパケット及びＭＰＬＳパケットを中継することを特徴とするルータ。
【請求項２】  前記パケット処理部は、
外部からパケットを受信する側の受信側処理部と、
外部へパケットを送信する側の送信側処理部を備え、
前記受信側処理部は、
外部から受信したパケットの情報を解析して、当該パケットの転送先経路及び当該パケットに対し実行すべき処理方法を識別し、前記装置内ヘッダを前記転送経路及び前記処理方法の情報を含めて生成し、当該パケットに前記生成した装置内ヘッダを付加して前記スイッチ処理部に送り、
前記スイッチ処理部は、
各前記パケット処理部の受信側処理部から送られるパケットを、当該パケットの前記装置内ヘッダにおいて指定された、当該パケットの転送先経路である前記パケット処理部の送信側処理部へ転送し、
前記送信側処理部は、
前記スイッチ処理部から転送されるパケットを、前記装置内ヘッダを取り外し、当該装置内ヘッダにおいて指定された当該パケットの処理方法に基づいて処理することを特徴とする請求項１に記載のルータ。」（２頁１欄）
　
ロ．「【００３１】
【課題を解決するための手段】上記目的を達成するため本発明のルータは、パケットを中継するルータにおいて、パケットを送受する複数のパケット処理部と、パケットを受信した前記パケット処理部から、当該パケットを送信する前記パケット処理部へ、当該パケットを転送するスイッチ処理部を備え、前記パケット処理部は、外部から受信したパケットがＩＰパケット及びＭＰＬＳパケットのいずれの場合においても、当該パケットに対し装置内ヘッダを付加して、ＩＰパケットの装置内転送時の形式に当該パケットを変換し、前記変換されたパケットを前記スイッチ処理部に送ることにより、ＩＰパケット及びＭＰＬＳパケットを中継することを特徴とする。
【００３２】請求項２の本発明のルータは、前記パケット処理部は、外部からパケットを受信する側の受信側処理部と、外部へパケットを送信する側の送信側処理部を備え、前記受信側処理部は、外部から受信したパケットの情報を解析して、当該パケットの転送先経路及び当該パケットに対し実行すべき処理方法を識別し、前記装置内ヘッダを前記転送経路及び前記処理方法の情報を含めて生成し、当該パケットに前記生成した装置内ヘッダを付加して前記スイッチ処理部に送り、前記スイッチ処理部は、各前記パケット処理部の受信側処理部から送られるパケットを、当該パケットの前記装置内ヘッダにおいて指定された、当該パケットの転送先経路である前記パケット処理部の送信側処理部へ転送し、前記送信側処理部は、前記スイッチ処理部から転送されるパケットを、前記装置内ヘッダを取り外し、当該装置内ヘッダにおいて指定された当該パケットの処理方法に基づいて処理することを特徴とする。」（５頁８欄〜６頁９欄）
　
ハ．「【００６３】図１は、本実施の形態のパケット処理部１０の構成を示すブロック図である。この図１を参照して、パケット処理部１０の構成とその処理について説明する。
【００６４】図１では、パケット処理部１０を、外部からパケットを受信する側のパケット受信側（受信側処理部）と、外部へパケットを送信する側のパケット送信側（送信側処理部）に分けて示している。
【００６５】パケット処理部１０のパケット受信側は、プロトコル識別部２１、フロー識別及び経路解決部３０、装置内ヘッダ付与部２２、パケット属性生成部２３、ＶＯＱ（Virtual Output Queue）アクセス制御部４０、メモリ（３１、４１）を備えている。
【００６６】プロトコル識別部２１は、受信した主信号パケットのプロトコルを識別し、ＰＰＰ（Point to Point Protocol）のリンクフェーズとプロトコルタイプに対応したパケット転送、あるいは廃棄処理を決定する。
【００６７】フロー識別及び経路解決部３０は、プロトコル識別部２１より転送されたパケットヘッダより、該パケットのフロー（あるいはラベル）を識別し、転送経路と該識別フロー（あるいは、ラベル）に応じた処理方法（宛先タグ情報）をテーブル参照により解決し、装置内ヘッダ付与部２２、及びパケット属性生成部２３に対して指示する。
【００６８】装置内ヘッダ付与部２２は、フロー識別及び経路解決部３０の指示により、図１１に示す（固定長の）装置内ヘッダをパケットの先頭ページに付与すると共に、フロー識別及び経路解決部３０の指示内容によっては、受信パケットのラベル（シムヘッダ）を抜去した後、ＶＯＱアクセス制御を行なう。
【００６９】パケット属性生成部２３は、フロー識別及び経路解決部３０の指示により、該パケットの属性情報を生成してＶＯＱアクセス制御部４０へ出力する。
【００７０】パケット処理部１０のパケット送信側は、ＶＩＱ（Virtual Input Queue）アクセス制御部５０、スケジューリング部６０、送信パケット処理判定部７１、送信パケット組立部７２、メモリ（５１、６１、７３）を備えている。
【００７１】スケジューリング部６０は、ＶＩＱアクセス制御部５０より受信したパケット属性情報内に収容された“宛先タグ情報”を元に、該パケットの装置内フロー識別子（Flow_ID）を解決する。そして、そのフロー識別子毎にパケット属性情報をキューイング（メモリに格納）すると共に、ピークレートと平均レートに基づくDual Token Bucket方式によるシェーピング（Shaping）及び優先スケジューリング（によるメモリ読出）を行なう。
【００７２】送信パケット処理判定部７１は、スケジューリング部６０より受信したパケット属性内に収容されるフロー識別子より、送信パケットに対するラベル化処理方法を決定づける。
【００７３】送信パケット組立部７２は、送信パケット処理判定部７１が決定したラベル化処理方法に従い、ＶＩＱアクセス制御部５０からの読み出し制御を行ない、更に読み出した主信号パケットに対してラベル（シムヘッダ）の挿抜又は、ラベル変換処理を行った後、ＰＰＰフレームへの組み立て（カプセル化）を行なう。」（８頁１４欄〜９頁１５欄）
　
ニ．「【００８２】図２は、本実施の形態のパケット処理部のパケット受信側の処理を説明するための図であり、図３は、本実施の形態のパケット処理部のパケット送信側の処理を説明するための図である。この図２、図３に示されるように、本実施の形態のパケット処理部１０の動作は、図２に示されるパケット受信側で３つのステップ（ステップ１〜ステップ３）、図３に示されるパケット送信側で３つのステップ（ステップ４〜ステップ６）の６ステップにより説明される。
【００８３】以下、この個々の各ステップにおける処理動作を説明する。
【００８４】まず、図２に示されるパケット受信側の処理（ステップ１〜ステップ３）を説明する。
【００８５】［ステップ１］パケットを受信すると、まず、プロトコル識別部２１は、受信したＰＰＰパケットヘッダのプロトコルＩＤを参照して、制御パケットであるか、主信号パケットであるかを識別する。
【００８６】この識別処理において、主信号パケットの場合には、そのパケットヘッダをフロー識別及び経路解決部３０に送出し、制御パケットの場合には、ボード上に実装されるＣＰＵによりＰＰＰにおけるリンク確立等の処理を実施する。
【００８７】ここで、主信号パケットとは、ＩＰパケット及びＭＰＬＳパケット（ラベル化パケット）が該当する。
【００８８】［ステップ２］次に、フロー識別及び経路解決部３０が、プロトコル識別部２１から前述したパケットのパケットヘッダを受信する。そして、受信したパケットヘッダ内から複数フィールド（ＭＦ：Multi-Field、マルチフィールド）の予め定められた組み合わせのデータを取り出して、これを検索キーとして、Flow Classifier Table３１の検索処理を行なう。
【００８９】フロー識別及び経路解決部３０は、Flow Classifier Table３１のマルチフィールド検索において、下記５つの要素を解決対象とし、これらを解決する。
・Forwarding Equivalent Class Identification（ＦＥＣ＿ＩＤ）：転送先経路を決定する識別子
・Policing Identification（ＰＬＣ＿ＩＤ）：ポリシング対象となるフローを決定する識別子
・Class Identification（ＣＬＳ＿ＩＤ）：転送ＱｏＳクラスを決定する識別子
・Statistic Information Counter Identification（ＳＴＡＴ＿ＩＤ）：統計情報のカウント単位を規定する識別子
・Pre-defined Color（ＰＣＯＬＯＲ）：ポリシング処理を行なう以前に、パケットに設定されている優先度
【００９０】［ステップ３］フロー識別及び経路解決部３０にて解決された上記の各識別子の情報は、装置内ヘッダ付与部２２とパケット属性生成部２３に配布される。そして、このそれぞれの処理ブロックにおいて、ページ（Page）及び当該パケットの必要最小限の情報を示すオブジェクト（Object）の所定位置にマッピングされた後、スイッチ処理部８０を経由して、当該パケットを送信する側のパケット処理部１０まで持ち回る。
【００９１】次に、図３に示されるパケット受信側の処理（ステップ４〜ステップ６）を説明する。以下の処理は、スイッチ処理部８０からパケットを転送され当該パケットを送信する側のパケット処理部１０における、パケット送信側の処理である。
【００９２】［ステップ４］スイッチ処理部８０を経由して受信したオブジェクトには、パケット受信側で解決した、転送経路と識別フロー（又ラベル）に応じた処理方法を示す“宛先タグ情報”が搭載されている。
【００９３】パケットスケジューリング部６０では、この宛先タグ情報を元に、フロー毎のシェーピング（出力規制）処理あるいは、スケジューリング（出力順序決定）処理等のＱｏＳ（Quality of Service）制御を行なう。
【００９４】ここで、ルータに要求されるサービスモデルや運用形態に応じて、具備するＱｏＳ機構が異なることが想定されるが、この宛先タグ毎にポリシング及びシェーピングのパラメータを予め設定することで、シェーピング及びスケジューリングをラベル単位もしくはＩＰフロー単位で実施することができる。
（９頁１６欄〜１０頁１７欄）
　
　上記引用例の記載及び図面を参照すると、上記イ．【請求項２】の「・・・外部からパケットを受信する側の受信側処理部と・・・備え、・・・」、同ロ．【００３１】の「・・・パケットを送受する複数のパケット処理部と、パケットを受信した前記パケット処理部から、・・・」等の記載から、引用例の「ルータ」はパケットを受信する手段を備える「装置」である。
　そして、上記イ．【請求項２】及び同ロ．【００３２】の「・・・外部から受信したパケットの情報を解析して、当該パケットの転送先経路及び当該パケットに対し実行すべき処理方法を識別し、・・・」、同ハ．【００６６】の「プロトコル識別部２１は、受信した主信号パケットのプロトコルを識別し、・・・」及び同【００６７】の「フロー識別及び経路解決部３０は、プロトコル識別部２１より転送されたパケットヘッダより、該パケットのフロー（あるいはラベル）を識別し、転送経路と該識別フロー（あるいは、ラベル）に応じた処理方法（宛先タグ情報）をテーブル参照により解決し、・・・」という記載から、引用例はパケットフローに対する「転送経路」と「処理方法」を解決（決定）するものである。
　また、上記ハ．【００６８】の「装置内ヘッダ付与部２２は、フロー識別及び経路解決部３０の指示により、図１１に示す（固定長の）装置内ヘッダをパケットの先頭ページに付与する・・・」という記載及び図１１から、「装置内ヘッダ」は「宛先タグ」情報を含むものであって、上記イ．【請求項２】及び同ロ．【００３２】の「前記送信側処理部は、・・・当該装置内ヘッダにおいて指定された当該パケットの処理方法に基づいて処理する・・・」、同ハ．【００７１】の「スケジューリング部６０は、・・・パケット属性情報内に収容された“宛先タグ情報”を元に、該パケットの装置内フロー識別子（Flow_ID）を解決する。そして、・・・ピークレートと平均レートに基づくDual Token Bucket方式によるシェーピング（Shaping）及び優先スケジューリング（によるメモリ読出）を行なう。」、同ニ．【００９３】の「パケットスケジューリング部６０では、この宛先タグ情報を元に、フロー毎のシェーピング（出力規制）処理あるいは、スケジューリング（出力順序決定）処理等のＱｏＳ（Quality of Service）制御を行なう。」という記載及び図１から、引用例の「処理方法」は送信側におけるパケットデータの「処理方法」であり、「装置内ヘッダ」をもとにデータの処理が行われることから、「装置内ヘッダ」は送信側におけるデータの「処理方法」に関係するものといえる。
　さらに、上記イ．【請求項２】及び同ロ．【００３２】の「・・・前記受信側処理部は、・・・前記装置内ヘッダを前記転送経路及び前記処理方法の情報を含めて生成し、当該パケットに前記生成した装置内ヘッダを付加して前記スイッチ処理部に送り・・・」、同ハ．【００６８】の「装置内ヘッダ付与部２２は、フロー識別及び経路解決部３０の指示により、図１１に示す（固定長の）装置内ヘッダをパケットの先頭ページに付与する・・・」という記載から、引用例はパケットフローに対して「装置内ヘッダ」を指定する手段を備えるものである。
　したがって、上記引用例には、以下の発明（以下、「引用発明」という。）が記載されている。 
「パケットを受信する手段と、
　前記パケットフローに対する転送経路及び送信側におけるデータの処理方法を決定する手段と、
　前記パケットフローに対して送信側におけるデータの処理方法に関係する装置内ヘッダを指定する手段と、
を備える装置。」
　　
３．対比 
　本願発明と引用発明を比較すると、引用発明の「パケット」、「パケットフロー」はパケット形式のデータ、パケット形式のデータのフローのことであるから、引用発明の「パケット」、「パケットフロー」と本願発明の「データパケット」、「パケットデータフロー」との間には実質的な差違はない。
　そして、引用発明の「パケットフローに対する転送経路及び出力時の処理方法を決定する」ことはパケットデータフローを処理するための一種の規則を決定することといえるので、本願発明の「パケットデータフローに適用すべき規則を決定する」ことに相当する。
　また、引用発明の「送信側におけるデータの処理方法」の「送信側」はデータを出力する段階であり、引用発明の「送信側におけるデータの処理方法」と本願発明の「少なくとも１つの出力時データ処理操作」との間に実質的な差違はない。
　さらに、引用発明の「装置内ヘッダ」と本願発明の「将来操作識別子」は、いずれも「出力時データ処理操作（送信側におけるデータの処理方法）」に関係する識別子という点で一致し、引用発明の「パケットフローに対して送信側におけるデータの処理方法に関係する装置内ヘッダを指定する手段」と本願発明の「パケットデータフローに対して以前に決定した少なくとも１つの出力時データ処理操作に関係する将来操作識別子を指定する手段」とは、いずれも「パケットデータフローに対して少なくとも１つの出力時データ処理操作に関係する識別子を指定する手段」である点で一致する。
　したがって、本願発明と引用発明は、以下の点で一致ないし相違する。
　
＜一致点＞ 
「データパケットを受信する手段と、
　前記パケットデータフローに適用すべき規則を決定する手段と、
　前記パケットデータフローに対して少なくとも１つの出力時データ処理操作に関係する識別子を指定する手段と、
を備える装置。」 
　
＜相違点＞ 
「少なくとも１つの出力時データ処理操作に関係する識別子」について、本願発明は（１）「以前に決定した」と限定し、（２）「識別子」について「将来操作」と限定しているのに対し、引用発明は当該限定をしていない点。
　
４．検討 
　上記相違点（１）について検討する。
　出願人は平成２１年１２月　３日付け意見書（２頁）において、請求項３３（本願発明）は請求項２３の「観察ネットワーク要素」に対応する装置の発明であると主張しているが、当該請求項２３には当該「観察ネットワーク要素」として、
「パケットデータフローを受信し，前記パケットデータフローに適用すべき規則を決定し，前記の決定した規則に基づいて前記パケットデータフローに対して少なくとも１つの操作ネットワーク要素において実行すべき少なくとも１つの出力時データ処理操作を決定し，前記パケットデータフローに対して前記少なくとも１つの出力時データ処理操作に関係する将来操作識別子を指定し，処理のために前記パケットデータフローに属するデータパケットを外部ネットワーク要素へ送信するように構成した観察ネットワーク要素」
と記載され、本願発明の「前記パケットデータフローに対して以前に決定した少なくとも一つの出力時データ処理操作に関係する将来操作識別子」の「以前に決定した」に係る記載はなく、「少なくとも１つの出力時データ処理操作を決定」することに関しては、「前記の決定した規則に基づいて前記パケットデータフローに対して少なくとも１つの操作ネットワーク要素において実行すべき少なくとも１つの出力時データ処理操作を決定し」と記載されている。
　また、本願明細書【００１３】、【００１４】、【００２０】、【００２１】、【００２３】、【００２９】、【００３１】、【００３４】、【００４０】、【００５１】、【００５７】、【００６５】等の「観察ネットワーク要素」に関連する箇所を参照しても、「出力時操作（出力時データ処理操
作）」を決定することに関しては、「パケットデータフローに適用される規則を決定」し、「決定された規則に基づいて」、「少なくとも１つの出力時操作（出力時データ処理操作）を決定」することが記載されているに過ぎない。
　したがって、本願発明の「以前に決定した」は「パケットデータフローに適用すべき規則を決定した」ときに「決定された規則に基づいて」決定したことを意味する程度のものと認められる。
　すると、引用発明においても「パケットフローに対する転送経路及び送信側におけるデータの処理方法（パケットデータフローに適用すべき規則）を決定する」ときに当該決定により「送信側におけるデータの処理方法（少なくとも１つの出力時データ処理操作）」が決定することから、上記相違点（１）は格別なものではない。
　なお、本願発明の「以前に決定した」が、パケットデータフローが開始したときに決定したことを意味するとしても、パケットデータフローの中継を開始する際に中継のルールあるいはパケットデータフローの処理方法を決定し、後に続く各パケットデータに対して当該決定した処理方法を適用することは周知技術（例えば、特開２０００−２８６８９６号公報【要約】、【０００５】、【００２０】、特開２００１−１８９７５３号公報【０００８】、特開２００２−３５９６３７号公報【００１２】、【０１６６】、国際公開第２００３／１０３２３３　第５頁第１３〜１８行参照。）であって、引用発明において、パケットデータフローが開始したときに決定した「送信側のデータの処理方法」に関係する装置内ヘッダを指定するようにすることは、当業者が適宜なし得ることであり、上記相違点（１）は格別なものではない。
　次に、上記相違点（２）について検討する。
　出願人の平成２１年１２月　３日付け意見書（２頁）の「出力時データ処理操作を示す将来操作識別子」という記載、本願明細書【００５２】、【００５４】及び図２、【００６１】、【００７６】、【００８０】等の関連箇所を参照すると、本願発明の「将来操作識別子」の「将来操作」は、「観察点」において「出力操作」を決定した後に「操作点」において実行される「出力操作」を意味するものと認めらる。
　すると、引用発明が事前に指定された「装置内ヘッダ（識別子）」にもとづいて「送信側におけるデータの処理（出力時データ処理）」を行う以上、引用発明の「装置内ヘッダ（識別子）」も後の出力時の処理操作を特定するものといえるので、引用発明の「装置内ヘッダ（識別子）」と本願発明の「将来操作識別子」とは呼称の差違に過ぎず、上記相違点（２）は格別なものではない。
　そして、本願発明の作用効果も引用発明及び周知技術から当業者が予測できる範囲のものである。 
　
５．むすび 
　以上のとおり、本願発明は、上記引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。 
　
　よって、結論のとおり審決する。