【事件の表示】
　特願２００１−５７１６２４「パケットデータの送信」拒絶査定不服審判事件〔平成１３年１０月　４日国際公開、ＷＯ０１／７４０２７、平成１５年　９月３０日国内公表、特表２００３−５２９２９１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明
　本願は、平成１３年１月１６日（パリ条約による優先権主張２０００年３月２７日、英国）を国際出願日とする出願であって、特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年１月２３日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
（本願発明）
　「通信システムのノードにおいて複数のデータユニットを取り扱う方法であって、上記複数のデータユニットは、上記ノードにおいてそれらデータユニットのプライオリティに基づき複数の送信待ち行列に分散されるような方法において、
　上記複数の送信待ち行列の待ち行列に重みを指定し、待ち行列の重みは、その待ち行列に対して割り当てられるべきリソースの占有率を定義し、
　上記待ち行列に関連する論理的接続の量の情報に基づいて上記複数の送信待ち行列の待ち行列に指定された重みを調整し、
　上記調整された重みに基づいて上記待ち行列からデータユニットを転送する、
という段階を含む方法。」
　
２．引用発明
（１）これに対して、原審の拒絶理由に引用された「南　勝也（外２名）“インターネットルータにおけるクラス優先制御を考慮したフロー別バッファ管理方式”２０００年３月９日発行、電子情報通信学会技術研究報告　Ｖｏｌ．９９、Ｎｏ．６７６、Ｐ８５−９０、ＩＮ９９−１３８」（以下、「引用例」という。）には、図面とともに以下のイ〜ホの事項が記載されている。
　
　イ．「１　はじめに
　近年，高性能コンピュータが，研究機関や企業のみならず，一般家庭まで普及しはじめ，新たな情報機器としての機能を発揮しはじめることにより，ＷＷＷなどのネットワークアプリケーションの利用が飛躍的に増大し，インターネット・イントラネットでのトラヒックが指数関数的に急増している．
　また，最近，音声のトラヒックをインターネットに統合する動き，すなわちＶｏＩＰ（Ｖｏｉｃｅ　ｏｖｅｒ　ＩＰ）が本格的に始動しつつある．さらに今後，ビデオのような一定の転送レートをもつストリーム型トラヒックや高速なデータ転送など異なる通信品質を要求する様々な形態のトラヒックの混在が予想される［１］．
　さらにＤｉｆｆ−Ｓｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ　Ｓｅｒｖｉｃｅ）［２］やＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ）［３］などのサービスクラス化及びパケット転送の高速化技術が注目を浴びてきた．Ｄｉｆｆ−Ｓｅｒｖは，異なる属性をもつトラヒックに異なるサービスクラスを定義し，それに見合ったサービスの提供をインターネットルータに要求している．またＭＰＬＳは基本的にはパケット転送を高速化する技術であるが，そのＭＰＬＳパケットのヘッダにはＣｏＳ（Ｃｌａｓｓ　ｏｆ　Ｓｅｒｖｉｃｅ）フィールドが用意されており，差別化サービスの実現が志向されている．
　上記のようなＱｏＳ保証機構，クラス別優先制御を備えるために考えられる技術の１つとして，バッファ読出しスケジューリングの研究が盛んに行われている．例えば，バッファを入出力ポートそれぞれに配置する入出力バッファ型スイッチは，Ｗｅｉｇｈｔｅｄ　Ｆａｉｒ　Ｑｕｅｕｉｎｇ（ＷＦＱ）やＷｅｉｇｈｔｅｄ　Ｒｏｕｎｄ　Ｒｏｂｉｎ（ＷＲＲ）［４］等のバッファ読出しスケジューリング規律によって，特定コネクションによる出力回線の恒常的な占有という問題点は改善される．しかし，これらのスケジューリングだけでは，バッファ高負荷時における高優先トラヒックのパケット到着に対して確実に収容することができず，十分なＱｏＳ制御を提供するのは困難である．また，ルータのインタフェースカードには複数本のポートが接続されることが十分に考えられ，この場合，バッファ空間も複数ポートで共有されることとなる．しかし，複数ポートを考慮したバッファ管理に関しては十分な検討が行われていない．
　そこで本稿では，フロー毎のＱｏＳ制御機能をもつ高性能ルータを実現するために，Ｐｕｓｈｏｕｔ機構［５］を導入し，それをポート及びクラス毎に階層的に管理することによってクラス別優先制御を行うバッファ管理法を提案する．本稿の具体的な目的は，クラスに見合ったサービスの提供，並びに特定フローによるバッファ占有の解消である．また，計算機シミュレーションを用いて提案手法の性能を定量的に評価する．」（８６頁左欄１〜４７行）
　
　ロ．「２　バッファ管理法
２．１　概要
　以下に本稿の提案方式であるバッファ管理法について述べる．まず，フロー毎に最低限使用可能なバッファサイズ（以下，“基本量”と呼ぶ）を論理的に確保する．バッファの使用率が低い環境下では，この基本量に関わらず，実バッファの使用が許される．高負荷環境に遷移しバッファがＦｕｌｌの状態になった場合，Ｐｕｓｈｏｕｔ機構を適用し特定のパケットを破棄する．さらに，本稿では１つのバッファを複数のポートで共有する環境を想定している．それに伴い，基本量の管理を，ポート，クラス，フローの順に階層的に行う手法を提案する．また，スケジューリング規律として階層的にＷＲＲを行う．さらに，クラス別優先制御を実現するためその帯域配分法の提案を行う．」（８６頁右欄１〜１４行）
　
　ハ．「２．２　基本量配分法
　ルータがフローを検知すると，そのフローに対してバッファ基本量を割当てる．その割当て方式を以下に述べる．
　まず全バッファサイズを複数ポート間で回線速度比に応じて配分する．次に，帯域保証型クラスフローに対し，そのポートに配分された基本量に関わらず保証帯域から算出される必要バッファ量を固定的に配分する．その他のクラスフローに対しては，ポートに対する基本量から帯域保証型クラスの配分量を引いた分を，予め決定された重みに従って配分する．配分される基本量はフロー検知，フロー消滅に伴い変化する．つまり，実際にバッファを使用しているフローだけで基本量を配分することになり，効率的なバッファ管理の実現が期待される．
　具体的に，図１を用いて説明する．まず各ポートに対して，全体のバッファ量を出力回線速度の比に従って配分する．図１の場合，まずＰｏｒｔ１に対して基本量ｐ１を配分する．次にそのポートに属するクラス間での配分を行う．このクラス間の配分の割合は，動的に変化する．帯域保証型クラスに対して，その予約量に見合った基本量を配分するためである．それ以外のクラスに対しては，予め決められたクラスの重みに従って配分を行う．図１の場合，まず帯域保証型であるＣｌａｓｓ２に対して，予約される帯域から算出される必要バッファ量α１を配分する．この必要バッファ量は，単位時間間隔に契約分のトラヒックがバースト的に到着した場合に，それらのパケットを全て収容できる量である．その後，残りのバッファ量（ｐ１−α１）を他のクラスに対して配分する．その手順は，まず各クラスの優先度と検知されているフロー数を用い，クラスの重みとしてそれらの積を適用する．図１におけるＰｏｒｔ１の場合，Ｃｌａｓｓ１の重みＷｃ１はＷｃ１＝ｆ１１・ｗ１１，Ｃｌａｓｓ０の重みＷｃ０はＷｃ０＝ｆ１０・ｗ１０となる．その重みの比を適用しＣｌａｓｓ０，１の基本量とする．つまり、β１，γ１は以下の式で表される．
β１＝（ｐ１−α１）・Ｗｃ１／（Ｗｃ１＋Ｗｃ０），　γ１＝（ｐ１−α１）・Ｗｃ０／（Ｗｃ１＋Ｗｃ０）」（８６頁右欄１５〜４７行）
　
　ニ．「２．４　帯域配分法
　本稿では，バッファに格納されたパケットの読出しスケジューリング規律として，ポート，クラス，フローの順に階層的にＷＲＲを行う．（図４）
　ＷＲＲにおいて，各クラスに対するＷｅｉｇｈｔを決める必要がある．そのＷｅｉｇｈｔの決定法を以下に述べる．まず，第１階層である，ポートに対するＷＲＲでは，そのポートの出力回線速度の比をＷｅｉｇｈｔとする．第２階層である，クラスに対するＷＲＲでは，始めに全リンク容量に対し帯域予約型フローに対して保証帯域を割り当てる．残りのリンク容量を帯域予約型クラス以外のクラスで配分する．その配分比は基本量配分時に使用したクラス比を使用する．それによって算出された帯域配分量を簡単な整数比に換算することでＷｅｉｇｈｔとする．第３階層である，フローに対するＷＲＲでは，帯域保証型クラス内フローに関しては契約帯域の比をそのままＷｅｉｇｈｔとして使用する．他のクラスに関してはフロー毎の公平性を考慮に入れ，全てのフローに対して重み“１”を与える．つまり，帯域保証型クラス以外の低優先クラス内フローに対するスケジューリング規律にはＲＲ（Ｒｏｕｎｄ　Ｒｏｂｉｎ）を使用する．」（８８頁左欄９〜２８行）
　
　ホ．「２．５　実装容易性を考慮したフローの定義
　本稿では，管理方式の実装容易性から，フローを「バッファ内に存在する同種のパケット群」とする．つまり，バッファ内にその種類のパケットが一時的にでも０になると，フローが消滅したと認識する．以上のことより，管理フロー数は多くともバッファ領域の大きさに等しくなり，実装が容易となる．また，タイマを用いる必要もなくなる点から有利であると言える．」（８８頁左欄２９〜３６行）
　
　上記引用例の記載及び関連する図面ならびにこの分野における技術常識を考慮すると、引用例は、インターネットルータにおけるクラス別優先制御に関するものであって、上記イに「ＭＰＬＳパケットのヘッダにはＣｏＳ（Ｃｌａｓｓ　ｏｆ　Ｓｅｒｖｉｃｅ）フィールドが用意されており」とあるように、各パケットのヘッダにはクラス情報が記載され、上記ホに「フローを「バッファ内に存在する同種のパケット群」とする」とあり、ここで同種とは、主要なヘッダ情報であるクラス、送信元、発信先などが同じであると解することができるから、フローは、同じクラスに属するパケットの流れであるといえる。また、上記ニに「本稿では，バッファに格納されたパケットの読出しスケジューリング規律として，ポート，クラス，フローの順に階層的にＷＲＲを行う．」とあるように、クラス毎のパケットの読出しを制御しており、クラス毎に待ち行列を有していることは自明である。
　さらに、上記ハに「残りのバッファ量（ｐ１−α１）を他のクラスに対して配分する．その手順は，まず各クラスの優先度と検知されているフロー数を用い，クラスの重みとしてそれらの積を適用する」とあるから、クラス毎にバッファが配分され、各パケットのクラスの優先度に基づいて、配分されたバッファに分散されるものであるといえ、また、クラスの優先度とフロー数の積をクラスの重みとし、クラスの重みの比によりクラス毎のバッファの配分を行い、待ち行列を構成するから、クラスの重みを決定することは、待ち行列に重みを指定することであり、重みの比によりバッファの配分を行うことは、重みによりバッファの配分比率を定義することであり、また、パケットのヘッダに記載されたクラスの優先度は、パケットの優先度である。
　また、上記ニによれば、バッファに格納されたパケットの読出しスケジューリング規律として、「クラスに対するＷＲＲでは，始めに全リンク容量に対し帯域予約型フローに対して保証帯域を割り当てる．残りのリンク容量を帯域予約型クラス以外のクラスで配分する．その配分比は基本量配分時に使用したクラス比を使用する．それによって算出された帯域配分量を簡単な整数比に換算することでＷｅｉｇｈｔとする．」とあり、基本量配分時に使用したクラス比を重みとして読出しを行うことが記載され、ここで、基本量配分時に使用したクラス比とは、上記ハによれば、クラスの優先度とフロー数の積によるものであるから、読出しは、フローの数に基づいて重みを調整しているといえる。また、バッファから読出しされたデータが次の装置に転送されることは自明である。
　
　したがって、上記引用例には、以下の発明（以下、「引用発明」という。）が開示されている。
　
（引用発明）
　「インターネットルータにおいて複数のパケットを取り扱う方法であって、上記複数のパケットは、上記ルータにおいてそれらのパケットの優先度に基づきクラス毎の待ち行列に分散されるような方法において、
　帯域保証型クラスに対して予約量に見合ったバッファ量を配分した残りのバッファの帯域保証型以外の各クラスの待ち行列への配分について、
　上記クラス毎の送信待ち行列の待ち行列に重みを指定し、待ち行列の重みは、その待ち行列に対して割り当てられるべきバッファの配分比率を定義し、
　上記待ち行列に関連するフローの数の情報に基づいて上記複数の送信待ち行列の待ち行列に指定された重みを調整し、
　上記調整された重みに基づいて上記待ち行列からパケットを転送する、
という段階を含む方法」
　
３．対比・判断
　本願発明と引用発明とを対比するに、引用発明のインターネットは通信システムであり、ルータは、中継などを行うものであるからノードということができ、パケットは、ひとかたまりのデータからなるものであるからデータユニットということができ、優先度とプライオリティは同義である。
　また、引用発明の「クラス毎の待ち行列」は、クラス毎に設けられており、送信されるデータを格納するものであるから複数の送信待ち行列であり、引用発明のバッファはリソースであり、配分比率に基づいて配分するから、当該バッファの配分比率は、リソースの占有率といえる。
　さらに、フローの数と論理的接続の量は、いずれも、数量である。
　
　したがって、本願発明と引用発明は、以下の点で一致し、また、相違している。
　
（一致点）
「通信システムのノードにおいて複数のデータユニットを取り扱う方法であって、上記複数のデータユニットは、上記ノードにおいてそれらデータユニットのプライオリティに基づき複数の送信待ち行列に分散されるような方法において、
　上記複数の送信待ち行列の待ち行列に重みを指定し、待ち行列の重みは、その待ち行列に対して割り当てられるべきリソースの占有率を定義し、
　上記待ち行列に関連する数量の情報に基づいて上記複数の送信待ち行列の待ち行列に指定された重みを調整し、
　上記調整された重みに基づいて上記待ち行列からデータユニットを転送する、
という段階を含む方法」
　
（相違点１）
　リソースの占有について、本願発明は、帯域保証型について何ら言及が無いのに対し、引用発明は、帯域保証型クラスに対して予約量に見合ったバッファ量を配分し、その残りを帯域保証型以外の各クラスの待ち行列へ配分するリソースとしている点。
　
（相違点２）
　待ち行列に関連する数量が、本願発明は、論理的接続の量であるのに対し、引用発明は、フローの数である点。
　
　そこで、上記相違点について検討する
　まず、相違点１について検討するに、データ通信技術において、帯域保証を実現するために帯域保証を要求するデータを特別に処理する構成を設けることは慣用技術であるところ、帯域保証のための特別な構成を設けるか否かは、データ通信を利用する応用システムの特性や通信されるデータの特性に応じて当業者が適宜決定できた設計的事項であるから、引用発明において、帯域保証型クラスの扱いを考慮することなく、バッファ全体を帯域保証型以外のクラスの待ち行列の重みにより配分するリソースとすることは、当業者であれば容易になし得たことである。
　次に、相違点２について検討するに、引用発明において、フローとは、バッファ内に存在する同種のパケット群をいうから、フローの数とは、発信元、送信先、クラス等を同一にするパケット群の数といえる。そして、それらは、発信元、送信先を同一にし、当該ルータを経由する論理的接続を流れることは自明であり、発信元、送信先の何れが異なっても別の論理的接続ということができるから、フローの数と論理的接続の量は、表現は異なるものの両者に格別の相違はなく、フローの数に基づいて重みを調整するか、論理的接続の量に基づいて重みを調整するかは、当業者であれば適宜選択できた事項にすぎない。
　
４．結語
　以上のとおり、本願発明は引用例に記載された発明及び技術常識に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許を受けることができないものである。
　
　よって、結論のとおり審決する。