【事件の表示】
　特願２０１３−５１７４７５「複数基準の選択を有するトポロジサーバを用いて通信アーキテクチャにわたって分散されたノードのネットワークへのアクセス」拒絶査定不服審判事件〔平成２４年　１月１２日国際公開、ＷＯ２０１２／００４５１３、平成２５年１０月１０日国内公表、特表２０１３−５３８３８３、請求項の数（９）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯　
　本願は、平成２３年７月５日（パリ条約による優先権主張、平成２２年７月８日、フランス）を国際出願日とする出願であって、平成２６年２月２８日付けで拒絶理由が通知され、平成２６年６月１１日付けで手続補正がされ、平成２６年１０月２２日付けで拒絶査定がされ、これに対し、平成２７年２月２０日に拒絶査定不服審判が請求されたものである。
　
第２　本願発明
　本願の請求項１−９に係る発明は、平成２６年６月１１日付けの手続補正で補正された特許請求の範囲の請求項１−９に記載された事項により特定されるものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は以下のとおりである。
　
「通信アーキテクチャ（Ａ）上に展開されたノード（Ｎ１、Ｎ２、Ｎ３．．．Ｎ５０）のネットワークにわたって分散されたアプリケーションに、前記通信アーキテクチャに接続されたアプリケーションクライアント（Ｃ）によってアクセスするためのシステム（ＣＡＮＴＯ、Ｍ）であって、ＡＬＴＯ標準に準拠して前記通信アーキテクチャ内の前記ネットワークのトポロジのビューを有するサーバ（Ｓ）と、前記クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードのセットについての情報を提供するための手段とを備え、前記サーバが、ノードの前記セットと関係する複数の特性についての情報を一度に提供することができる、システム（ＣＡＮＴＯ、Ｍ）。」　
第３　原査定の理由の概要
１．平成２６年２月２８日付け拒絶理由通知（理由Ｂ）
『この出願の以下の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
１．請求項１〜９（引用文献１〜３）
　引用文献１（特に第１４頁等）には、ＡＬＴＯはＩＳＰのトラフィック要求を反映した回線利用ポリシ情報をエンドノードに提供することで、アプリケーション側（同「通信アーキテクチャ（Ａ）上に展開されたノード（Ｎ１、Ｎ２、Ｎ３．．．Ｎ５０）のネットワークにわたって分散されたアプリケーション」）もトラフィック制御を補助するという枠組みであり、各ＩＳＰはＡＬＴＯサーバ（請求項１の「ＡＬＴＯ標準に準拠して前記通信アーキテクチャ内の前記ネットワークのトポロジのビューを有するサーバ（Ｓ）」）と呼ばれる情報管理サーバを設置し、様々なトラフィック要求を種類別に管理し、各アプリケーション（同「アプリケーションクライアント」）では、ＡＬＴＯサーバに対して所望のメトリック情報の問い合わせを行い、ＡＬＴＯサーバはアプリケーションが指定した種別の情報を応答として返却し（同「前記クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードのセットについての情報を提供するための手段」）、アプリケーションは応答から、所望のＩＰアドレス間の情報を抽出し、自身のトラフィック制御に利用することが記載されている。
　また、引用文献１には、各アプリケーションでは、ＡＬＴＯサーバに対して所望のメトリック情報の問い合わせを行う際に、複数の所望のメトリック情報の問い合わせを行うこと（請求項１の「前記サーバが、ノードの前記セットと関係する複数の特性についての情報を提供することができる」）は明記されていないものの、例えば、引用文献２（特に【００１９】、【００２２】等）にも記載されているように、メトリック情報の取得を行う際に、複数のメトリック情報を取得することは、本願の公開基準日においては周知であり、してみれば、前記引用文献１に記載の発明に、前記周知技術を用いることを試みることは、当業者においては、通常の創作活動の範囲内の事項である。
　また、引用文献３（特に第２１６頁等）には、ＡＬＴＯにおいてネットワークトポロジーを基にノードにランク付け（請求項２の「ノードの順序」）をし、Ｐ２Ｐアプリケーションに提供することが記載されている。
　以上より、本願発明１〜９は、前記引用文献１〜３に記載の発明に基いて、当業者が容易に発明をすることできたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　引　用　文　献　等　一　覧
１．大溝  拓也，ＩＳＰ主導のアプリケーションネットワーク制御を実現するオーバレイルータの設計，電子情報通信学会技術研究報告  Ｖｏｌ．１１０  Ｎｏ．３９，日本，社団法人電子情報通信学会，２０１０年　５月１３日，第110巻，第13頁-第18頁
２．特表２０１０−５１４２８３号公報
３．東條  琢也，電子情報通信学会２０１０年総合大会講演論文集  通信２，日本，社団法人電子情報通信学会，２０１０年　３月　２日，第216頁』
　
２．平成２６年１０月２２日付け拒絶査定
『この出願については、平成２６年　２月２８日付け拒絶理由通知書に記載した理由によって、拒絶をすべきものです。
　なお、意見書及び手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
　
備考
　出願人は、平成２６年　６月１１日付け意見書及び手続補正書において、補正後の請求項１について、補正前の請求項１の「サーバが、ノードの前記セットと関係する複数の特性についての情報を提供することができる」との記載を、「サーバが、ノードの前記セットと関係する複数の特性についての情報を一度に提供することができる」として、　「拒絶理由通知書では、例えば、引用文献２（特に【００１９】、【００２２】等）にも記載されているように、メトリック情報の取得を行う際に、複数のメトリック情報を取得することは、本願の公開基準日においては周知であり、とされている。
　しかしながら、引用文献２の引用箇所は、ノード１００ｅがポータル１１２ａ〜ｂへの各接続の動作パフォーマンスに関する情報を収集することを開示している。これは、この情報が、ノードのセット、すなわち、サーバがトポロジのビューを有するネットワークのノードのセットに関係するのではなく、ポータル、すなわち、サーバそれ自体に関係することを意味している。
　さらに、引用文献２の引用箇所は、ノード１００ｅがポータル１１２ａ〜ｂの各々から、これらのポータルと接続が確立されたときに、情報を収集することを開示している。これは、この情報が一度に提供されるのではなく、このような接続が確立されたときにその都度収集されることを意味している。」と主張している。
　しかしながら、前記平成２６年　３月１８日付け拒絶理由通知書の＜理由Ｂ＞にて、「ＡＬＴＯサーバに対して所望のメトリック情報の問い合わせを行い、ＡＬＴＯサーバはアプリケーションが指定した種別の情報を応答として返却し（同「前記クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードのセットについての特性の情報を提供するための手段」）」と認定したが、これは、例えば、本願明細書（段落【００１１】〜【００１７】）において先行技術としても記載され、ｄｒａｆｔ−ｉｅｔｆ−ａｌｔｏ−ｐｒｏｔｏｃｏｌ−０４．ｔｘｔにも記載されているように、ＡＬＴＯサーバにおいて、クライアントによる要求が行われたとき、トポロジのビューに基づいて、ネットワークのノードのセットについての特性の情報を提供することは、周知であるためであった。
　また、例えば、文献１（国際公開第２００５／０６２５４９号、段落[0023]-[0025]等）や文献２（特表２００５−５２４３５７号公報、段落【００５９】−【００６５】等）にも記載されているように、ノードと関係する複数の特性についての情報を一度に提供することは、本願の公開基準日においては、周知であり、してみれば、前記引用文献１に記載の発明の、ＡＬＴＯサーバにおいて、クライアントによる要求が行われたとき、トポロジのビューに基づいて、ネットワークのノードのセットについての情報を提供する構成において、前記周知技術を適用して、ＡＬＴＯサーバにおいて、クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードのセットと関係する複数の特性についての情報を一度に提供する構成を想到することは、当業者においては、格別の困難性を有さない。
　
　したがって、本願発明１−９は、依然として、引用文献１−３に記載の発明、及び前記周知技術に対して進歩性はなく、進歩性に関する出願人の上記主張は採用できない。』
　
第４　刊行物の記載事項
１．刊行物１
　原査定の拒絶の理由で引用された「大溝  拓也，ＩＳＰ主導のアプリケーションネットワーク制御を実現するオーバレイルータの設計，電子情報通信学会技術研究報告  Ｖｏｌ．１１０  Ｎｏ．３９，日本，社団法人電子情報通信学会，２０１０年　５月１３日，第110巻，第13頁-第18頁」（以下、「刊行物１」という）には、次の事項が記載されている（なお、下線は当審により付与した）。
　
「１．はじめに
現在、様々なアプリケーションがインターネット上で動作しており、それぞれが異なるトラフィック要求を持っている。たとえば、Skype［1]に代表されるVolP（Voice over IP）通信では通話品質に関わる遅延の短縮、BitTorrent［2］に代表されるファイル通信では転送速度の向上のような通信品質に関するトラフィック要求がある。一方、ネットワーク管理者側であるISP（Internet Service Provider）にも特定の回線別のトラフィックエンジニアリングに関するトラフィック要求がある。ISPのトラフィック要求には、ある特定の回線には多量のトラフィックを流さない、などISP間の関係に基づいた要求がある。本稿では、このアプリケーションの通信品質の要求、トラフィック要求の双方を総称してトラフィック要求と呼ぶ。
　現在のインターネットにおける重大な問題として、これら2つのトラフィック要求との間で競合がある。
エンドノード間で構成される論理ネットワークを利用するオーバレイネットワークアプリケーションを事例に取り、その競合を説明する（図1）。本例の上図に示したオーバレイネットワークにおけるA ，B 間の通信を考える。
現在、このようなアプリケーションでは、エンドノード問でオーバレイネットワークを構成する際、物理トポロジ構成などの情報を利用することができない。このようなISPのみが利用可能な情報を本稿では、アンダーレイネットワーク情報と呼ぶ。
　この問題を解決する手段として、アプリケーション制御にISPが介在する方式が検討されている。ISPはネットワークを管理する立場であり、物理トポロジ構成、ルーティング情報、自身の考えるトラフィック要求など様々な情報をアプリケーションへの制御に利用できる。特にエンドノード間で直接通信を行うP2P（peer?to?peer）技術においては、それらの情報を使えることで効果的な通信を実現でき、またISP側では自身のトラフィック要求をアプリケーション別の通信へ反映できる。そのため、ユーザ、ISP双方が利益を得ることが期待される。
　
アプリケーション制御にISPが介在する方式の一つとして、ALTO（Application-Layer Traffic Optimization）［4]の 標準化が進んでいる。ALTOは、ISP側が意図してアンダーレイネットワーク情報をエンドノードに提供することで、ISPのトラフィック要求をエンドノード側で反映させる方式である。
　我々はこれらの課題に対処可能であるアプローチとして、ISPから提供されるノードを利用して、そのノード間でアプリケーション別の仮想バックボーンを構成するという手段を検討している。そこで本稿では、ISPの管理下にあるオーバレイルータと呼ばれるノードを用いた通信方式を提案し、そのオーバレイルータの設計を行う。ISPが制御するオーバレイルータは、アプリケーションに対してその品質要求に応じた独自のオーバレイネットワークをそれぞれ仮想バックボーンとして構成し、その上でのデータ転送をサービスとして提供する。オーバレイルータがISPにより制御されることで、ISPのみが利用可能なアンダーレイネットワーク情報、トラフィック要求を利用した網構成をエンドノードに提供することなく行うことが可能である。オーバレイルータは特定のアプリケーションを動作させる配下のエンドノードを集中的に管理し、配下のエンドノードの通信制御を行う。また、種々のアプリケーションをオーバレイルータで管理することで、他のアプリケーションの挙動を認識でき、アプリケーション間の調停が可能となる。これにより、各アプリケーションの品質要求に応じた網上の通信を、ISPのトラフィック要求を満足した上で実現する。
　前回の発表［5]では、特にAS（Autonomous System）間トラフィックの削減に焦点を当て、このようなISP側がアプリケーション制御に介在する手法として、ルーティング情報を所持するBGP（Border Gateway Protocol）ルータ間でオーバレイネットワークを構成する手法の提案を行った。その結果、ルーティング情報を反映させるごとで、ネットワークを効果的に利用することが可能であることを示した。本稿では、単純な評価に留まっていた前回の発表を発展させ、システム設計としての提案を行う。
２．関連研究
　２．１　ALTO（Application-Layer Traffic Optimization）
　
現在IETFにおいて、ALTO［4］と呼ばれる技術の標準化が進んでいる。ALTOはISPのトラフィック要求を反映した回線利用ポリシ情報をエンドノードに提供することで、アプリケーション側もトラフィック制御を補助するという枠組みである。各ISPはALTOサーバと呼ばれる情報管理サーバを設置し、様々なトラフィック要求を種類別に管理する。各アプリケーションでは、ALTOサーバに対して所望のメトリック情報の問い合わせを行う。問い合わせには情報の種別が含まれ、ALTOサーバはアプリケーションが指定した種別の情報を応答として返却する。アプリケーションは応答から、所望のIPアドレス間の情報を抽出し、自身のトラフィック制御に利用するという形態を取る。
　
「次に、ISPのみが利用可能なアンダーレイネットワーク情報の利用方法とシステムの動作に関して、既存手法と提案手法の違いを図を用いて説明する。まず、既存手法であるALTOによるオーバレイネットワークの構成の例を図2 に示す。
ALTOではISP側がALTOサーバをISP内部に設置し、ALTOサーバからエンドノードがアンダーレイネットワーク情報を取得し、利用する。本稿では、このようなISPからの惰報提供による方式 を、NC（Network　Characteristics）提供方式と呼ぶ。アンダーレイネットワーク情報を利用した上で、エンドノード間の接続構成を決定し、その上で独自に通信を行っている。
　
　以上の記載、特に、下線部を参照すると、刊行物１には、次の発明（以下、「刊行物１発明」という）が記載されていると認められる。
　
［刊行物１発明］
　エンドノード間で構成される論理ネットワークを利用するオーバレイネットワークアプリケーションにより、エンドノード間で通信するシステムであって、ＡＬＴＯでは、ＩＳＰ側がＡＬＴＯサーバをＩＳＰ内部に設置し、ＡＬＴＯサーバからエンドノードがアンダーレイネットワーク情報（物理トポロジ構成などのＩＳＰのみが利用可能な情報）を取得して利用し、エンドノード間の接続構成を決定し、独自に通信を行うものであって、各アプリケーションでは、ＡＬＴＯサーバに対して所望のメトリック情報の問い合わせを行い、問い合わせには情報の種別が含まれ、ＡＬＴＯサーバはアプリケーションが指定した種別の情報を返却し、アプリケーションは応答から、所望のＩＰアドレス間の情報を抽出し、自身のトラフィック制御に利用する、システム。
　
２．刊行物２
　原査定の拒絶の理由で引用された特表２０１０−５１４２８３号公報（以下、「刊行物２」という）には、次の事項が記載されている（なお、下線は当審により付与した）。
　
「【００１５】
  図１は、いくつかの実施形態に沿った例示的なメッシュネットワーク１３０のブロック図である。特に、メッシュネットワーク１３０は、メッシュノード１００ａ〜ｆおよびメッシュポータル１１２ａと１１２ｂとによる相互接続によって形成される。メッシュポータル１１２ａ〜ｂは様々なメッシュノード（例えば１００ａ〜ｆ）およびルータ１１４を介して外部のネットワーク１２０に接続されている。様々な実施形態では、これらの接続は、ネットワークおよび外部または外付けネットワーク１２０内のデバイス間の、全ての使用可能なワイヤレスパスの自動ディスカバリと使用を可能にする。
【００１６】
  ある実施形態では、メッシュノード１００ａは相互接続１４０によりメッシュノード１００Ｃと接続する。メッシュノード１００ｃは相互接続１４１および１４３によりメッシュノード１００ｂおよびメッシュポータル１１２ａにそれぞれ接続する。様々な実施形態では、接続の失敗、あるいはウォール１２２が示すような障害により直接接続が不可能な場合でも、メッシュノード１００ａは、マルチホップを用いてメッシュポータル１１２ａまたはメッシュノード１００ｂに接続してよい。
【００１７】
  様々な実施形態では、メッシュノード１００ａ〜ｆは、メッシュポータル１１２ａ〜ｂへの接続１４０〜１４８のパフォーマンスを定期的に計測してよい。定期的な計測は、手動あるいは自動的に開始される。現在使用中のポータルよりも別のポータルがより効率的になると、ノードはより効率の良いポータルへの接続を確立してよい。また、別の実施形態では、ノードはより効率の良いポータルの存在をユーザに通知して、ポータルを切り替える判断を求めてよい。
【００１８】
  例示を目的として、典型的なメッシュネットワーク１３０は、図のように利用可能な２つのメッシュポータル１１２ａ〜ｂに接続するネットワークノード１００ａ〜ｆを有してよい。さらに、メッシュノード１００ａ〜ｆは、ネットワークのある特定のポータルとの
みリンクを確立するよう静的にプログラムされてよい。そのような場合には、ノードの移動によって、ネットワークのポータルと通信するために必要な距離が遠くなる場合がある。具体的には、ノード１００ｅが矢印１１８が示すように第２の位置へ移動する。ノード１００ｅは、静的にプログラムされているので、同じポータル１１２ａとマルチホップ、あるいは単純に接続１４６が示すようなより長い距離で直接ポータル１１２ａと通信する必要がある。
【００１９】
  
ある実施形態では、図２および図３で詳細に説明するプラットフォームを含むノードを、より効率の良い接続を動的に選択するように設定してよい。図のように、矢印１１８に沿って第２の位置へ移動したノード１００ｅが、ネットワーク１３０の各ポータル、具体的にはポータル１１２ａ〜ｂへの接続を接続１４６および１４７で動的に確立してよい。様々な実施形態では、その後ノードが各接続の動作パフォーマンスに関する情報を収集してよい。このような情報は、例えば各接続に関連したメトリック値を返すＡＯＤＶのような当該技術分野で知られているプロトコルによる結果であってよい。また、別の実施形態では、メッシュノードと特定のメッシュポータルとの距離、あるいは特定のメッシュポータルと通信中の他のメッシュノードの数などの、動作パフォーマンスの質に関する情報をその他のプロトコルを用いて取得し、返してよい。
【００２０】
  図２および図３は、様々な実施形態におけるホストプラットフォーム１００ａ〜ｆのブロック図である。システムは、コントロールブロック２０２に接続した記憶媒体２００を含む。様々な実施形態では、アンテナ構造４０２に接続し、ネットワーク１３０のその他のデバイスへのアクセスを提供するネットワークモジュール３００として、コントロールブロック２０２と記憶媒体２００とを集積してよい。様々な実施形態では、アンテナ構造４０２は全指向性アンテナを含んでよい。
【００２１】
  ある実施形態では、記憶媒体２００は、半導体ファームウェアメモリ、プログラム可能型メモリ、不揮発性メモリ、ＲＯＭ（読み出し専用メモリ）、ＥＰＭ（電気的プログラム可能型メモリ）、ＲＡＭ（ランダムアクセスメモリ）、フラッシュメモリ（例えばＮＡＮＤ型またはＮＯＲ型メモリ構造を含んでよい）、磁気ディスクメモリ、および／または光ディスクメモリを含んでよい。さらに、あるいは択一的に、メモリ２００は、その他および／または後発型のコンピュータ読み取り可能なメモリから成ってよい。機械読み取り可能なファームウェアプログラム命令をメモリ２００に格納してよい。ある実施形態では、例えばこれに限られないがネットワークの各ポータルのアドレスを含む識別情報を記憶媒体２００に格納してよい。アドレスとは、ノードにポータルを検索させることが可能なあらゆる情報であり、ある実施形態では、ＩＰアドレスである。
【００２２】
  様々な実施形態では、コントロールブロック２０２は、デバイスを複数のポータルへ対応してリンクする、複数のリンクに関するパフォーマンス情報を収集するように設計されている。様々な実施形態では、パフォーマンス情報は、メッシュポータルからメッシュノードへの距離または各ポータルのトラフィック量に関連した情報を含んでよく、あるいはそれらに基づいた情報であってよい。この情報は、例えばＡＯＤＶなど、当該技術分野で知られているプロトコルを用いて収集してよい。ある実施形態では、メッシュノードがルートリクエストパケット（「ＲＲＥＱ」）をネットワーク１３０の各ポータルへブロードキャストすることにより情報を収集してよい。」
　
３．周知文献
　拒絶査定において、周知技術を示す文献として引用された国際公開第２００５／０６２５４９号、及び、特表２００５−５２４３５７号公報には、次の事項が記載されている。（なお、下線は当審により付与した）
　
・国際公開第２００５／０６２５４９号
「【００２３】
　
ノード間接続情報取得部１１は、ネットワーク内の任意のノード（例えば、ノードＡ）から、当該任意のノードの隣接ノード（例えば、ノードＢ乃至Ｄ）に係るノード間接続情報を取得するものである。なお、ノード間情報には、隣接ノードを識別するための「ノード名（ノードＩＤ）」と、隣接ノードの「ノードアドレス（例えば、ＩＰアドレス）」と、任意のノードと隣接ノードとの間の経路の「メトリック値」と、隣接ノードに隣接する「ノード数」とを含む。また、「メトリック値」は、ホップ数、ネットワーク帯域幅、通信コスト、遅延、負荷、ＭＴＵ、信頼性の少なくとも一つを含む。
【００２４】
　ここで、ホップ数は、物理層におけるホップ数、すなわち、当該ノードとの間で確立されているリンクにおけるルータ等のホップ数を示す。ネットワーク帯域幅は、当該ノードとの間で確立されているリンクにおいて使用可能な通信帯域（例えば、６４ｋｂｐｓ等）を示す。通信コストは、当該ノードとの間で確立されているリンクの通信料金を示す。遅延は、当該ノードとの間で確立されているリンクにおける伝播遅延時間を示す。負荷は、当該ノードとの間で確立されているリンクの使用状況（例えば、５０％等）を示す。ＭＴＵは、当該ノードとの間で確立されているリンクにおいて使用される最小転送ブロックサイズ（Ｍｉｎｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）を示す。信頼性は、当該ノードとの間で確立されているリンクにおける障害発生率をしめす。
【００２５】
　
ノード間接続情報取得部１１は、ネットワーク内の任意のノードからノード間情報を取得する際に、メトリック値指定部１５によって指定されたメトリック値（又は、メトリック値の組み合わせ）の種類を通知するように構成されていてもよい。
　
・特表２００５−５２４３５７号公報
「【００５９】
　
一旦、クラスター・リーダー・ノード２１から３３が他クラスター・リーダー・ノードが隣接するクラスター内に存在することを知ると、そのクラスター・リーダー・ノード（つまり、クラスター・リーダー・ノード間の指定された通信リンク１６）からノードレベル・ルートを取得する。これら２つのクラスター・リーダー・ノードがそれらの間の指定された通信リンク１６とそれらに関連するメトリックとを維持する。当業者によって理解されるように、このメトリックは、指定された通信リンク１６におけるホップ数と、帯域幅、利用可能性等のようなサービス品質（ＱｏＳ）パラメーターとを有している。
【００６０】
　各クラスター・リーダー・ノードがその隣接するクラスター・リーダー・ノードの全てのアドレスを格納し、隣接するクラスター・リーダー・ノードの夫々への指定された通信リンク１６を保持する。一旦、指定された通信リンクが確立すると、送り元ノード１４によって要求されたクラスターレベル・ルートが送り元クラスターへ隣接するクラスターの一つへのルートではない場合、送り元クラスター・リーダー・ノード２１がクラスターレベル・ルート発見処理を開始する。
【００６１】
　処理は、ブロック２２にて、指定された通信リンク１６を介して残っているクラスター・リーダー・ノード２２から３１へと、送り元クラスターのクラスター・リーダー・ノード２１からクラスター・リーダー・ノード・ルート要求（ＣＬＮＲＲ）を送信することによって開始される。更に、特に、クラスター・リーダー・ノード・ルート要求を送り元クラスター・リーダー・ノード２１から、図１に例示される例ではクラスター・ノード２３及び２５である隣接するクラスター・リーダー・ノードの夫々へ送信されることによってなされる。クラスター・リーダー・ノード２３及び２５は、クラスター・リーダー・ノード・ルート要求がクラスター・リーダー・ノード２１から３３の全てによって受信されるまで、順に、そのクラスター・リーダー・ノード・ルート要求をその隣接するクラスター・リーダー・ノードの夫々へ転送する。
【００６２】
　上記手法が、全体的にブロードキャストが使用されないため、オーバーヘッド・トラフィックにおいて著しい節約を提供することが、当業者によって理解されるであろう。つまり、無線ライン１３のサブセットのみがブロードキャストのために要求される。更に通信が要求されるオーバーヘッド転送に制限されるために、この処理において拡張するリングの検索を使用することができる。更に、クラスター・リーダー・ノード・ルート要求を、１つのクラスター、クラスターのリスト、又は全クラスターへのルートを発見するために、目標とすることができる。クラスター・リーダー・ノード要求は、また、発見された各クラスターレベル・ルートの望ましさを示すことができる蓄積されたメトリックを含んでも良い。一例として、蓄積されたメトリックは、目標とされた送り先クラスター３２へのルートに沿ってクラスター・リーダー・ノード２１から３３の間の指定された通信リンク１６のためのリンク・メトリックの蓄積であっても良い。
【００６３】
　クラスター・リーダー・ノード・ルート要求は、ブロック５３で、送り先クラスター・リーダー・ノード１２によって受信された場合、送り先クラスター・リーダー・ノードは、先クラスター・リーダー・ノード・ルート返信（ＣＬＲＲＥＰ）によって返信する。このクラスター・リーダー・ノード・ルート返信は、送り元クラスター・リーダー・ノード２１へクラスターレベル・ルートへ返送するために、送り先クラスター・リーダー・ノード３２によって使用される。このメッセージは、クラスター・リーダー・ノード・ルート要求が移動した配信ルート、つまり、送り元クラスター・リーダー・ノード２１と送り先クラスター・リーダー・ノード３２とに接続している指定された通信リンク１６を介して送り返される。
【００６４】
　以下に更に説明されるように、クラスター・リーダー・ノード・ルートにおける情報は、配信ルート上の一連のクラスターを有するようにしても良く、また、他変形も可能である。また、特定の配信ルートのためのパス・メトリック（又は、パス・メトリックを形成するために組み合わせ可能な構成要素）が返送されても良い。もちろん、送り先クラスター・リーダー・ノード１２は、その隣接するクラスター・リーダー・ノード（すなわち、図１に例示される例におけるクラスター・リーダー・ノード２６、３１、及び３３）の一つ以上から同一のクラスター・リーダー・ノード・ルート要求を受信することは可能である。このような場合、送り元クラスター・リーダー・ノード３２は、また、これら隣接するクラスター・リーダー・ノードの夫々に関連付けられる配信ルート毎に、クラスター・リーダー・ノード・ルート返信を返送すれば良い。
【００６５】
　一旦、送り元クラスター・リーダー・ノード２１は、与えられたクラスター・リーダー・ノード・ルート要求に対応するクラスター・リーダー・ノード・ルート返信の全てを収集すると、ブロック５４にて、クラスターレベル・ルートとして配信ルート間から最良のルートを選択するために、各配信ルートのパス・メトリックを使用する。もちろん、いくつかの実施例において、送り元ノード１５は、それら利用可能なルートから最良の配信ルートを選択し、クラスターレベル・ルートを決定することによって、最良の経路に沿ってクラスター・リーダー・ノード・ルート返信を単に返送する。」
　
第５　対比
　本願発明と刊行物１発明とを対比すると次のことがいえる。
　
・刊行物１発明の「エンドノード間で構成される論理ネットワークを利用するオーバレイネットワークアプリケーション」は、本願発明の「通信アーキテクチャ（Ａ）上に展開されたノード（Ｎ１、Ｎ２、Ｎ３．．．Ｎ５０）のネットワークにわたって分散されたアプリケーション」に相当するものといえる。
　
・刊行物１発明の、オーバレイネットワークアプリケーションにより通信する「エンドノード」は、本願発明の、通信アーキテクチャに接続された、アプリケーションにアクセスする「アプリケーションクライアント（Ｃ）」に相当する。
　
・刊行物１発明の「ＡＬＴＯサーバ」は、「アンダーレイネットワーク情報（物理トポロジ構成などのＩＳＰのみが利用可能な情報）」を有するものであるから、本願発明の「ＡＬＴＯ標準に準拠して前記通信アーキテクチャ内の前記ネットワークのトポロジのビューを有するサーバ（Ｓ）」に相当する。
　
・刊行物１発明のエンドノードは、アプリケーションにより、ＡＬＴＯサーバに対して所望のメトリック情報の問い合わせを行い、問い合わせには情報の種別が含まれ、ＡＬＴＯサーバはアプリケーションが指定した種別の情報を返却し、アプリケーションは応答から、所望のＩＰアドレス間の情報を抽出する。
　この所望のＩＰアドレス間の情報とは、ノードのＩＰアドレス間の情報であるから、「ノードについての情報」といえる。
　また、ＡＬＴＯサーバが返却する情報は、ＡＬＴＯサーバが有するアンダーレイネットワーク情報（本願発明の「ネットワークのトポロジのビュー」に相当）に基づいていることは明らかであるから、本願発明と刊行物１発明とは、「前記クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードについての情報を提供するための手段」を備える点で共通する。
　また、ＡＬＴＯサーバが返却する情報は、ＩＰアドレス間の情報を含むものであるから、「ノードと関係する特性についての情報」ともいえる。
　したがって、刊行物１発明のシステムは、「前記サーバが、ノードと関係する特性についての情報を提供することができる、システム」である点で、本願発明と共通する。
　
　したがって、両者の一致点、相違点は次のとおりである。
　
［一致点］
　通信アーキテクチャ（Ａ）上に展開されたノード（Ｎ１、Ｎ２、Ｎ３．．．Ｎ５０）のネットワークにわたって分散されたアプリケーションに、前記通信アーキテクチャに接続されたアプリケーションクライアント（Ｃ）によってアクセスするためのシステム（ＣＡＮＴＯ、Ｍ）であって、ＡＬＴＯ標準に準拠して前記通信アーキテクチャ内の前記ネットワークのトポロジのビューを有するサーバ（Ｓ）と、前記クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードについての情報を提供するための手段とを備え、前記サーバが、ノードと関係する特性についての情報を提供することができる、システム（ＣＡＮＴＯ、Ｍ）。
　
［相違点］
　本願発明は、「前記クライアントによる要求が行われたとき、前記トポロジのビューに基づいて、前記ネットワークのノードのセットについての情報を提供するための手段」を備え、「前記サーバが、ノードの前記セットと関係する複数の特性についての情報を一度に提供することができる」ものであるのに対し、刊行物１発明は、そのようなものではない点。
　
第６　当審の判断
　相違点について検討する。
　刊行物１発明は、クライアントによる要求が行われたとき、トポロジのビューに基づいて、ネットワークのノードについての情報を提供するための手段を備え、サーバが、ノードと関係する特性についての情報を提供することができるものとはいえるが、ノードのセットについての情報を提供するための手段を備え、ノードの前記セットと関係する複数の特性についての情報を一度に提供することができるようにすることについては想定されていないし、刊行物１には、そのことを示唆するような記載もない。
　刊行物２には、複数のポータルとの接続を確立し、ノードが、各接続に関連したメトリック値などの各接続の動作パフォーマンスに関する情報を収集することが記載されているが、ノードのセットと関係する複数の特性についての情報を一度に提供することができることについては記載されていない。
　拒絶査定で引用された周知文献１には、ノードＡが管理している、隣接ノードＢ乃至Ｄとのノード間接続情報（ノード名、ノードアドレス、メトリック値（またはメトリック値の組み合わせ）、ノード数）をノードＸが取得することが記載されている。周知文献１に記載されたものは、１つのノードＡが管理している上記のような情報をノードＸが取得するものであって、１つのノードと関係する複数の特性についての情報を一度に提供することができるものとはいえるものの、周知文献１には、ノードのセットと関係する複数の特性についての情報を一度に提供することができることについては記載されていない。
　拒絶査定で引用された周知文献２には、２つのクラスター・リーダー・ノードがそれらの間の指定された通信リンク１６とそれらに関連する、指定された通信リンク１６におけるホップ数と、帯域幅、利用可能性等のようなサービス品質（ＱｏＳ）パラメーターとを有しているメトリックとを維持することについて記載されている。周知文献２には、ノードのセットと関係する複数の特性についての情報を一度に提供することができることについては記載されていない。
　したがって、刊行物１発明において、刊行物２、周知文献１、周知文献２に記載された技術を採用したとしても本願発明の構成には至らない。
　さらに、他に、刊行物１発明において、相違点に係る本願発明の構成を採用する根拠は見当たらない。
　よって、本願発明は、当業者が刊行物１発明に基づいて容易に発明をすることができたものとすることはできない。
　本願の請求項２−７に係る発明は、本願発明に発明特定事項を付加してさらに限定したものであり、本願の請求項８、９に係る発明は、物に係る本願発明を、方法、プログラムの発明として捉えて記載したものであるから、本願発明と同様に、請求項２−９に係る発明は、当業者が刊行物１発明に基づいて容易に発明をすることができたものとすることはできない。
　
第７　むすび
　以上のとおりであるから、本願の請求項１−９に係る発明は、いずれも、当業者が刊行物１発明に基づいて容易に発明をすることができたものとすることはできないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。