【事件の表示】
　特願２００７−５４１５１４「マルチホップ無線ネットワークシステム」拒絶査定不服審判事件〔平成１９年　９月１３日国際公開、ＷＯ２００７／１０２２０８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１８年３月８日を国際出願日とする出願であって、平成２２年９月３日付けで拒絶査定がなされ、これに対し、平成２２年１２月１０日に拒絶査定不服審判が請求されると同時に手続補正がなされたものである。
　
　
２．平成２２年１２月１０日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２２年１２月１０日付けの手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
（１）補正後の本願発明
　本件補正により、特許請求の範囲の請求項１は、次のように補正された（下線は変更部分）。
　
「　　【請求項１】
　送信元である第１の無線装置と、
　送信先である第２の無線装置と、
　前記第１および第２の無線装置間で無線通信を中継する第３の無線装置とを備え、
　前記第２の無線装置は、前記第３の無線装置を介して前記第１の無線装置から前記自己へ至る無線通信経路の特性に基づいて、前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求を許可または拒否し、前記品質保持要求の許可または前記品質保持要求の拒否を前記第３の無線装置へ送信し、
　前記第１および第３の無線装置は、前記無線通信経路の特性を測定し、その測定した無線通信経路の特性を前記第２の無線装置へ送信し、
　前記第３の無線装置は、前記品質保持要求の許可または前記品質保持要求の拒否を前記第１の無線装置へ送信し、
　前記第１の無線装置は、前記第２の無線装置が前記品質保持要求を許可すると、前記第３の無線装置を介して前記第２の無線装置へ前記トラフィックの送信を開始
し、前記第２の無線装置が前記品質保持要求を拒否した場合、前記品質保持要求が拒否された経路を用いてベストエフォートクラスで前記トラフィックの送信を開始
　
　本件補正は、請求項１に記載した発明を特定するために必要な事項である「第１の無線装置」について「前記第２の無線装置が前記品質保持要求を拒否した場合、前記品質保持要求が拒否された経路を用いてベストエフォートクラスで前記トラフィックの送信を開始する」との限定を付加するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　
　そこで、本件補正後の前記請求項１に係る発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（２）刊行物
刊行物１．Namhi Kang, Younghan Kim, Quality of Service Extension to Dynamic MANET OnDemand Routing Protocol draft-kang-dymoqos-01.txt, INTERNET DRAFT, [onlinle], 2 March 2006, [2011年11月22日検索], インターネット URL: http://www.watersprings.org/pub/id/draft-kang-dymoqos-01.txt
　
（２−１）刊行物１の記載
　原査定の拒絶の理由に引用された刊行物１には、図面と共に、以下の事項が記載されている。
　
（ア）第３頁第１行から第１４行
1. Introduction
　
The DYMO routing protocol specifies a reactive means to discover a route to the destination for MANET nodes.  A source node disseminates RREQ message toward the destination node to discover a route to the node.  Once the RREQ message arrives at the destination node, it
responds RREP message back to the source node over the discovered path by unicasting.  During such a route discovery process, intermediate nodes (i.e. nodes that relay the RREQ and RREP message) update its routing table based on the routing information that is present in those two messages for each direction.  DYMO also offers adaptation to changing network topology, which can be occurred by the mobility of nodes as the main cause, by means of the route maintenance mechanisms [1].
　
〈当審訳〉
１．導入
　
ＤＹＭＯルーティングプロトコルは、ＭＡＮＥＴノードで宛先へのルートを発見する反応的な手段を規定している。発信元ノードは、ＲＲＥＱメッセージを宛先ノードに向けて流し、それによって該ノードへのルートを発見する。一旦ＲＲＥＱメッセージが宛先ノードに到着すると、それは、発見されたパスを通してユニキャストによってＲＲＥＰメッセージを発信元ノードへと返送する。このようなルート発見プロセスの間、中間ノード（すなわち、ＲＲＥＱ及びＲＲＥＰメッセージを中継するノード）は、それら２つの各方向のメッセージに存在するルーティング情報に基づいて、自身のルーティングテーブルを更新する。ＤＹＭＯは、ルート維持機構によってネットワークトポロジーの変更に適応することも提供しており、ネットワークトポロジーの変更は、主な原因としてノードの移動の移動によって引き起こされる［１］。
　
（イ）第１２頁第３行から第１３行
4.1 QoS Route Discovery
　
Like DYMO routing procedures, a QoS route is also discovered by means of two way handshaking consisting of a route request and route reply cycle.  Instead of DYMO RREQ, the source (QoS requestor) disseminates QRREQ (RREQ with a QoS extension) to the destination.  QRREQ message elements therefore should contain required QoS parameters as well as the QoS reporting information on the path that the message has been experienced.  Thereafter, the destination node decides a correct route that can meet the QoS requirements and then sends QRREP (RREP with a QoS extension) to the source.
　
〈当審訳〉
４．１　ＱｏＳルート発見
　
ＤＹＭＯルーティング手続のように、ＱｏＳルートも、ルート要求とルート応答サイクルからなる双方向ハンドシェークを用いて発見される。ＤＹＭＯのＲＲＥＱの代わりに、発信元（ＱｏＳ要求者）は、ＱＲＲＥＱ（ＱｏＳ拡張をしたＲＲＥＱ）を宛先に流す。したがって、ＱＲＲＥＱメッセージエレメントは、必要とされるＱｏＳパラメータの他に、そのメッセージが経験したパスに関するＱｏＳ報告情報を含むべきである。その後、該宛先ノードは、ＱｏＳ要求を満足できる正しいルートを決定し、それから、ＱＲＲＥＰ（ＱｏＳ拡張をしたＲＲＥＰ）を発信元に送る。
　
（ウ）第１２頁第１５行から第２１行
Ahead of re-broadcasting a QRREQ message by an intermediate node, the node must check its resources whether it is available for the QoS requirements contained within the QRREQ message during the route discovery process.  Thereafter, if resources are enough to meet service requirements, the intermediate node updates QoS information that is present in the QRREQ message to inform the destination about the current QoS states related to the path.
　
〈当審訳〉
中間ノードがＱＲＲＥＱメッセージを再放送するに先んじて、該ノードは、ルート発見プロセスの間、ＱＲＲＥＱメッセージの中に含まれているＱｏＳ要求のためにリソースが利用可能かどうかをチェックしなければならない。その後、リソースがサービス要求を満たすに十分であれば、中間ノードは、そのパスに関する現在のＱｏＳ状態を宛先に伝えるために、ＱＲＲＥＱメッセージにあるＱｏＳ情報を更新する。
　
（エ）第１２頁第２３行から第２８行
That is, QRREQ should contain two different fields.  One is used to specify the QoS requirements of the source (i.e. QoS requestor) that must be met at nodes through the path.  The other field is used to inform both the QoS requestor and the destination that selects a proper QoS route the current network conditions such as delay, jitter, and/or bandwidth.
　
〈当審訳〉
つまり、ＱＲＲＥＱは、２つの異なるフィールドを含むべきである。一つは、発信元（すなわちＱｏＳ要求者）のＱｏＳ要求を特定するために用いられ、該ＱｏＳ要求は、そのパスの中のノードにおいて満たされなければならない。別のフィールドは、ＱｏＳ要求者と、適切なＱｏＳルートを選択する宛先とに、遅延、ジッター又は帯域幅のような現在のネットワーク状況を知らせるために用いられる。
　
（オ）第１２頁第３０行から第３２行
In case of delay and jitter, intermediate nodes accumulate each of their measured delay and jitter value to the corresponding value of the received QRREQ message.
　
〈当審訳〉
遅延及びジッターの場合、中間ノードは、測定した遅延及びジッタの値を、受信したＱＲＲＥＱメッセージの対応する値に、累積する。
　
（カ）第１２頁第３５行から第１３頁第３行
In case of bandwidth (i.e. capacity to transmit), the node compares its measured value with the value of QSIB field in the received QRREQ message.  If the measured value is smaller than the value of the message, the field is updated to the measured one.  This field allows the destination to be aware of the actual minimum bandwidth over a route from the source to the destination since the value of QSIB is always bigger than the minimum value that the QoS requestor requires.  If it is not the case, a node MUST drop the QRREQ message since there is not enough bandwidth to guarantee the required one.  Such a way allows the QoS requestor to be able to increase the minimum bandwidth requirement according to the network condition dynamically.
　
〈当審訳〉
帯域幅（すなわち伝送容量）の場合、該ノードは、測定値と、受信したＱＲＲＥＱメッセージのＱＳＩＢフィールドの値とを比較する。測定値がメッセージの値よりも小さいならば、該フィールドは測定値へと更新される。このフィールドは、宛先に、発信元から宛先へのルートに渡る実際の最小帯域幅を意識させることができる。なぜなら、ＱＳＩＢの値は常にＱｏＳ要求者が必要とする最小値よりも大きいからである。そうでなければ、要求された帯域幅を補償するに十分な帯域幅がないので、ノードは該ＱＲＲＥＱメッセージをドロップしなければならない。こうすれば、ＱｏＳ要求者は、ネットワーク状況にしたがって最小帯域幅要求を動的に増加させることができる。
　
（キ）第１３頁第３７行から第３９行
Once the requestor receives the QRERR, it re-builds a QoS route process based on the unavailable QoS parameters if it still has packets to deliver.
　
〈当審訳〉
一旦、要求者がＱＲＥＲＲを受信し、配送すべきパケットがまだあるならば、利用不可能なＱｏＳパラメータに基づいてＱｏＳルートプロセスを再構築する。
　
　以上の刊行物１の記載によれば、刊行物１には、次の発明（以下、「刊行物１記載発明」という。）が記載されていると認められる。
　
　「ＱｏＳルート発見方法であって、
　ＤＹＭＯルーティング手続のように、ルート要求とルート応答サイクルからなる双方向ハンドシェークを用いてＱｏＳルートが発見され、
　ＤＹＭＯのＲＲＥＱの代わりに、発信元（ＱｏＳ要求者）は、ＱＲＲＥＱ（ＱｏＳ拡張をしたＲＲＥＱ）を宛先に流し、
　ＱＲＲＥＱメッセージエレメントは、必要とされるＱｏＳパラメータの他に、そのメッセージが経験したパスに関するＱｏＳ報告情報を含み、
　その後、該宛先ノードは、ＱｏＳ要求を満足できる正しいルートを決定し、それから、ＱＲＲＥＰ（ＱｏＳ拡張をしたＲＲＥＰ）を発信元に送り、
　中間ノードがＱＲＲＥＱメッセージを再放送するに先んじて、該ノードは、ルート発見プロセスの間、ＱＲＲＥＱメッセージの中に含まれているＱｏＳ要求のためにリソースが利用可能かどうかをチェックし、
　その後、リソースがサービス要求を満たすに十分であれば、中間ノードは、そのパスに関する現在のＱｏＳ状態を宛先に伝えるために、ＱＲＲＥＱメッセージにあるＱｏＳ情報を更新し、
　ＱＲＲＥＱは、２つの異なるフィールドを含み、
　　一つは、発信元（すなわちＱｏＳ要求者）のＱｏＳ要求を特定するために用いられ、該ＱｏＳ要求は、そのパスの中のノードにおいて満たされなければならず、
　　別のフィールドは、ＱｏＳ要求者と、適切なＱｏＳルートを選択する宛先とに、遅延、ジッター又は帯域幅のような現在のネットワーク状況を知らせるために用いられ、
　遅延及びジッターの場合、中間ノードは、測定した遅延及びジッタの値を、受信したＱＲＲＥＱメッセージの対応する値に、累積し、
　帯域幅（すなわち伝送容量）の場合、該ノードは、測定値と、受信したＱＲＲＥＱメッセージのＱＳＩＢフィールドの値とを比較し、測定値がメッセージの値よりも小さいならば、該フィールドは測定値へと更新される、ＱｏＳルート発見方法。」
　
（３）対比
　本願補正発明と刊行物１記載発明とを以下で対比する。
　
　刊行物１記載発明は「ＤＹＭＯルーティング手続のように、ルート要求とルート応答サイクルからなる双方向ハンドシェークを用いてＱｏＳルートが発見され」るものである。ここで、「ＤＹＭＯルーティングプロトコルは、ＭＡＮＥＴノードで宛先へのルートを発見する反応的な手段を規定している」（上記摘記事項（ア）を参照）ものである。
　そして、ＭＡＮＥＴがモバイル・アドホック・ネットワークのことであり、モバイル・アドホック・ネットワークがマルチホップ無線ネットワークの一種であることは技術常識である。
　以上から、本願補正発明と刊行物１記載発明とは、「マルチホップ無線ネットワークシステム」である点で一致する。
　
　刊行物１記載発明の「発信元ノード」及び「宛先ノード」は、それぞれ本願補正発明の「送信元である第１の無線装置」及び「送信先である第２の無線装置」に相当する。
　また、刊行物１発明において、「発信元ノード」及び「宛先ノード」は、それぞれ「発信元」及び「宛先」と略されることもあるので、刊行物１記載発明の「発信元」及び「宛先」も、それぞれ本願補正発明の「送信元である第１の無線装置」及び「送信先である第２の無線装置」に相当する。
　加えて、刊行物１記載発明の「ＱｏＳ要求者」は、「発信元」と同一のノードを指しているので、本願補正発明の「第１の無線装置」に相当する。
　
　刊行物１記載発明における「中間ノード」は、ＱＲＲＥＱメッセージ及びＱＲＲＥＰメッセージをやり取りしており、該ＱＲＲＥＱ及びＱＲＲＥＰは、それぞれ「ＱｏＳ拡張をしたＲＲＥＱ」及び「ＱｏＳ拡張をしたＲＲＥＰ」である。
　ＲＲＥＱ及びＲＲＥＰは、ＤＹＭＯルーティングプロトコルで用いられるメッセージであり、ＤＹＭＯにおいて「中間ノード」は「ＲＲＥＱ及びＲＲＥＰメッセージを中継するノード」である（上記摘記事項（ア）を参照）。
　してみると、刊行物１記載発明の「中間ノード」は、本願補正発明の「前記第１および第２の無線装置間で無線通信を中継する第３の無線装置」に相当する。
　
　刊行物１記載発明におけるＱＲＲＥＱは、「ルート要求」をするためのメッセージである。通信のルートを要求するということは、そのルートで通信を行おうとすることに他ならない。
　そして、該ＱＲＲＥＱに含まれる「ＱｏＳ要求」は、「そのパスの中のノードにおいて満たされなければなら」ないものである。
　してみると、刊行物１記載発明の「ＱＲＲＥＱ」は、発信元から宛先へ送信されるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求するものである。
　また、刊行物１記載発明がパケット通信を行っていることは、上記摘記事項（キ）の記載から明らかである。
　以上から、刊行物１記載発明の「ＱＲＲＥＱ」は、本願補正発明の「前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求」に相当する。
　
　刊行物１記載発明の「宛先」は、「ＱｏＳ要求を満足できる正しいルートを決定し、それから、ＱＲＲＥＰ（ＱｏＳ拡張をしたＲＲＥＰ）を発信元に送」るものである。
　よって、「宛先」は、当該ルートがＱｏＳ要求を満足しているか否かの判断をしている。
　また、「ＲＲＥＰ」は、ＤＹＭＯにおいて発見されたパスを通して発信元ノードへ返送されるものであるから（上記摘記事項（ア）を参照）、ＲＲＥＰは宛先から中間ノードを介して発信元へと返送されるものであり、ＱＲＲＥＰも同様であると認められる。
　してみると、本願補正発明と刊行物１記載発明とは、「前記第２の無線装置は、前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求を満たすか否かを判断し、応答を前記第３の無線装置へ送信」する点及び「前記第３の無線装置は、前記応答を前記第１の無線装置へ送信」する点で一致する。
　
　刊行物１記載発明の「中間ノード」は、「中間ノードがＱＲＲＥＱメッセージを再放送するに先んじて、該ノードは、ルート発見プロセスの間、ＱＲＲＥＱメッセージの中に含まれているＱｏＳ要求のためにリソースが利用可能かどうかをチェックし、その後、リソースがサービス要求を満たすに十分であれば、中間ノードは、そのパスに関する現在のＱｏＳ状態を宛先に伝えるために、ＱＲＲＥＱメッセージにあるＱｏＳ情報を更新」するものである。
　このとき更新される「ＱＲＲＥＱにあるＱｏＳ情報」は、「ＱｏＳ要求者と、適切なＱｏＳルートを選択する宛先とに、遅延、ジッター又は帯域幅のような現在のネットワーク状況を知らせるために用いられ」る「別のフィールド」である。
　そして、この「別のフィールド」を中間ノードが更新する際は、「測定値」が用いられる。
　してみると、本願補正発明と刊行物１記載発明とは、「前記第３の無線装置は、前記無線通信経路の特性を測定し、その測定した無線通信経路の特性を前記第２の無線装置へ送信」する点で一致する。
　
　すると、本願補正発明と刊行物１記載発明との一致点及び相違点は、以下のとおりである。
　
〈一致点〉
　「送信元である第１の無線装置と、
　送信先である第２の無線装置と、
　前記第１および第２の無線装置間で無線通信を中継する第３の無線装置とを備え、
　前記第２の無線装置は、前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求を満たすか否かを判断し、応答を前記第３の無線装置へ送信し、
　前記第３の無線装置は、前記無線通信経路の特性を測定し、その測定した無線通信経路の特性を前記第２の無線装置へ送信し、
　前記第３の無線装置は、前記応答を前記第１の無線装置へ送信する、マルチホップ無線ネットワークシステム。」である点。
　
〈相違点１〉
　本願補正発明は、品質保持要求を満たすか否かを判断する際に、「前記第３の無線装置を介して前記第１の無線装置から前記自己へ至る無線通信経路の特性に基づいて」判断しているのに対し、刊行物１記載発明は、そのような無線通信経路の特性に基づいて判断しているとは明示されていない点。
　
〈相違点２〉
　本願補正発明における品質保持要求を満たすか否かを判断する動作は、「品質保持要求を許可または拒否」する動作であるのに対し、刊行物１記載発明における品質保持要求を満たすか否かを判断する動作は、「ＱｏＳ要求を満足できる正しいルートを決定する」動作である点。
　
〈相違点３〉
　本願補正発明における品質保持要求を満たすか否かを判断した後の応答は、「前記品質保持要求の許可または前記品質保持要求の拒否」であるのに対し、刊行物１記載発明における品質保持要求を満たすか否かを判断した後の応答は、「ＱＲＲＥＰ」であって、「前記品質保持要求の許可または前記品質保持要求の拒否」であるとは明示されていない点。
　
〈相違点４〉
　本願補正発明は、無線通信経路の特性の測定を「第１及び第３の無線装置」で行うのに対し、刊行物１記載発明は、中間ノード（「第３の無線装置」に相当）で行うことは明示されているものの、発信元（「第１の無線装置」に相当）で行うことは明示されていない点。
　
〈相違点５〉
　本願補正発明の第１の無線装置は、「前記第２の無線装置が前記品質保持要求を許可すると、前記第３の無線装置を介して前記第２の無線装置へ前記トラフィックの送信を開始」するという動作をするのに対し、刊行物１記載発明では、そのような動作をすることは明示されていない点。
　
〈相違点６〉
　本願補正発明の第１の無線装置は、「前記第２の無線装置が前記品質保持要求を拒否した場合、前記品質保持要求が拒否された経路を用いてベストエフォートクラスで前記トラフィックの送信を開始する」するという動作をするのに対し、刊行物１記載発明では、そのような動作をすることは明示されていない点。
　
（４）判断
　
（４−１）相違点１について
　無線通信経路が品質保持要求を満たすか否かを判断するためには、品質保持要求と、実際の無線通信経路の品質とがわからなければならない。
　刊行物１記載発明において、品質保持要求はＱＲＲＥＱに含まれる「ＱｏＳ要求」であり、実際の無線通信経路の品質はＱＲＲＥＱに含まれる「別のフィールド」である。この「別のフィールド」は、「ＱｏＳ要求者と、適切なＱｏＳルートを選択する宛先とに、遅延、ジッター又は帯域幅のような現在のネットワーク状況を知らせるために用いられ」るものである。
　そして、「ＱＲＲＥＱメッセージエレメントは、必要とされるＱｏＳパラメータの他に、そのメッセージが経験したパスに関するＱｏＳ報告情報を含」んでいるのであるから、前記「別のフィールド」は、ＱＲＲＥＱが流れた無線通信経路（当然、中間ノードを経由している）の品質を表している。
　してみれば、刊行物１記載発明において、品質保持要求を満たすか否かを判断するために必要な実際の無線通信経路の品質はＱＲＲＥＱに含まれる「別のフィールド」にて宛先ノードに伝達されているのであるから、刊行物１記載発明が品質保持要求を満たすか否かの判断を「前記第３の無線装置を介して前記第１の無線装置から前記自己へ至る無線通信経路の特性に基づいて」判断するよう構成することは、当業者が当然に行うべきことである。
　
（４−２）相違点２について
　前述のとおり、刊行物１記載発明の「ＱＲＲＥＱ」は、「前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求」である。
　ＱＲＲＥＱの要求に対し、「ＱｏＳ要求を満足できる正しいルートを決定」するということは、要求されたＱｏＳを満足する通信ルートが存在するから、当該ＱｏＳにて通信を行っても良い、ということに他ならない。
　してみれば、刊行物１記載発明の宛先ノードの動作は「品質保持要求を許可」するものであるのだから、本願補正発明の第２の無線装置の「品質保持要求を許可または拒否」するという択一動作の一方に相当する。
　したがって、この相違点は実質的な相違点ではない。
　
（４−３）相違点３について
　刊行物１記載発明は「ルート要求とルート応答サイクルからなる双方向ハンドシェークを用いてＱｏＳルートが発見され」るものであり、ルート要求はＱＲＲＥＱ、ルート応答はＱＲＲＥＰのことを指していると解される。
　してみれば、刊行物１記載発明のＱＲＲＥＰは、ＱｏＳ付きのルート要求に対して、該ＱｏＳを満たすルートが発見されたことを知らせているといえる。
　そして、上記（４−２）で述べたとおり、「ＱｏＳ要求を満足できる正しいルートを決定する」という判断は、「品質保持要求を許可」する判断に他ならないから、その判断の後に送信されるＱＲＲＥＰは、実質的に「品質保持要求を許可」することを知らせるメッセージである。
　してみれば、刊行物１記載発明の応答であるＱＲＲＥＰは「前記品質保持要求の許可」であるのだから、本願補正発明の応答である「前記品質保持要求の許可または前記品質保持要求の拒否」という択一事項の一方に相当する。
　したがって、この相違点は実質的な相違点ではない。
 
（４−４）相違点４について
　通信路の状態は、中継ノードだけでわかるものもあるが、例えばパケットの損失率のように、発信元でないとわからないものも存在する。
　ＱｏＳの指標として、パケット損失率は周知であるから、そのような指標を採用することは設計的事項であり、その際、無線通信経路の特性の測定は、発信元も行わなければならないことは明らかである。
　したがって、刊行物１記載発明において、無線通信経路の特性の測定を「第１及び第３の無線装置」で行うようにすることは、当業者が容易になし得ることである。
　
（４−５）相違点５について
　前述のとおり、刊行物１記載発明の「ＱＲＲＥＱ」は、「前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求」である。
　してみれば、その要求が許可されたならば、「前記第３の無線装置を介して前記第２の無線装置へ前記トラフィックの送信を開始」することは当然である。
　
（４−５）相違点６について
　前述のとおり、刊行物１記載発明の「ＱＲＲＥＱ」は、「前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求」である。
　その要求が許可されなかった場合、ＱｏＳの要求レベルを下げれば許可されるだろうことは、経験的に知られている。
　してみれば、要求が許可されなかった場合、ＱｏＳの要求レベルを下げたベストエフォートクラスで通信を試みることは、当業者が容易になし得ることである。
　
（４−７）効果について
　また、本願補正発明の構成によって生じる効果も、上記刊行物１記載発明、刊行物１発明及び周知技術から当業者が予測し得る範囲内のもので格別顕著であるとはいえない。
　
（４−８）
　上記（４−１）から（４−７）のとおり、本願補正発明は、刊行物１記載発明及び周知技術に基いて容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
３．本願発明について
　平成２２年１２月１０日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年５月７日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「　　【請求項１】
　送信元である第１の無線装置と、
　送信先である第２の無線装置と、
　前記第１および第２の無線装置間で無線通信を中継する第３の無線装置とを備え、
　前記第２の無線装置は、前記第３の無線装置を介して前記第１の無線装置から前記自己へ至る無線通信経路の特性に基づいて、前記第１の無線装置から自己へ送信されるパケットの流れであるトラフィックの品質を所定の品質に保持して前記トラフィックを送信することを要求する品質保持要求を許可または拒否し、前記品質保持要求の許可または前記品質保持要求の拒否を前記第３の無線装置へ送信し、
　前記第１および第３の無線装置は、前記無線通信経路の特性を測定し、その測定した無線通信経路の特性を前記第２の無線装置へ送信し、
　前記第３の無線装置は、前記品質保持要求の許可または前記品質保持要求の拒否を前記第１の無線装置へ送信し、
　前記第１の無線装置は、前記第２の無線装置が前記品質保持要求を許可すると、前記第３の無線装置を介して前記第２の無線装置へ前記トラフィックの送信を開始する、マルチホップ無線ネットワークシステム。」
　
（１）刊行物
　原査定の拒絶の理由に引用された刊行物、及びその記載事項は、前記「２．（２）」に記載したとおりである。　
　
（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明から「第１の無線装置」の限定事項である「前記第２の無線装置が前記品質保持要求を拒否した場合、前記品質保持要求が拒否された経路を用いてベストエフォートクラスで前記トラフィックの送信を開始する」との構成を省いたものである。
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記２．（４）に記載したとおり、上記刊行物に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、刊行物１記載発明及び周知技術に基いて、当業者が容易に発明をすることができたものである。　
　
（３）むすび
　以上のとおり、本願発明は、刊行物１記載発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。