【事件の表示】
　特願２００５−３１７８８６「ＳｏｆｔＲｏｕｔｅｒの分離制御ネットワーク」拒絶査定不服審判事件〔平成１８年　５月２５日出願公開、特開２００６−１３５９７２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は，平成１７年１１月１日（パリ条約による優先権主張　２００４年１１月１日　米国，２００５年６月８日　米国）の出願であって，平成２３年８月５日付けで拒絶査定がなされ，これに対し，同年１２月１２日に拒絶査定に対する審判請求がなされ，平成２４年１０月１１日付けで当審から拒絶理由が通知され，平成２５年４月１６日付けで手続補正がなされたものである。
　その請求項１に係る発明は，明細書，特許請求の範囲及び図面の記載からみて，平成２５年４月１６日付け手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次のものと認める（以下，「本願発明」という。）。
「【請求項１】
　ネットワーク・アーキテクチャであって，
　データ・トラフィックを伝送するためのネットワークであり，複数の相互接続された転送要素（ＦＥ）を含む，データ・プレーンと，
　該データ・プレーンから隔てられている制御トラフィック用の他のネットワークであり，複数の相互接続された制御要素（ＣＥ）を含み，それぞれのＣＥは該複数のＦＥのうちの少なくとも２つを制御し，それぞれのＣＥは制御されるＦＥに動的にバインドされる，制御プレーンと，
　プロトコルを使用する該データ・プレーンと制御プレーンとの間のインターフェイスとを備え，
　該データ・プレーンから物理的に隔てられている該制御プレーンは，該複数のＣＥ間の複数のプライベート・リンクを含み，それによって該複数のＣＥの間のアウトバウンド制御通信を可能にするネットワーク・アーキテクチャ。」
　
　
２．引用発明
　当審の拒絶理由に引用されたYANG L ET AL，RFC 3746: Forwarding and Control Element Separation(ForCES) Framework(April 2004)，FORCES WORKING GROUP,(2004.4)，検索日：平成２４年１０月５日，インターネットURL: http://www.ietf.org/rfc/rfc3746.txt（以下，「引用例」という。）には，「Forwarding and Control Element Separation (ForCES) Framework」（［当審仮訳］：「転送及び制御要素の分離（ForCES）フレームワーク」）として，図面とともに以下の事項が記載されている。
　
（１）「1.2. Terminologies
（中略）
　　Addressable Entity (AE) - An entity that is directly addressable given some interconnect technology.  For example, on IP networks, it is a device to which we can communicate using an IP address; on a switch fabric, it is a device to which we can communicate using a switch fabric port number.
　　Physical Forwarding Element (PFE) - An AE that includes hardware used to provide per-packet processing and handling.  This hardware may consist of (but is not limited to) network processors, ASICs (Application-Specific Integrated Circuits), or general purpose processors, installed on line cards, daughter boards, mezzanine cards, or in stand-alone boxes.
（中略）
　　Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality.  This hardware typically includes a general purpose processor.
（中略）
　　Forwarding Element (FE) - A logical entity that implements the ForCES Protocol.  FEs use the underlying hardware to provide per-packet processing and handling as directed by a CE via the ForCES Protocol. FEs may happen to be a single blade (or PFE), a partition of a PFE, or multiple PFEs.
　　Control Element (CE) - A logical entity that implements the ForCES Protocol and uses it to instruct one or more FEs on how to process packets.  CEs handle functionality such as the execution of control and signaling protocols.  CEs may consist of PCE partitions or whole PCEs.
　　ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs.  An NE usually hides its internal organization from external entities and represents a single point of management to entities outside the NE.
　　Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining whether an FE and a CE should be part of the same network element. 
（中略）
　　FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) an FE should communicate.  This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs.
（中略）
　　CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate.  This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. 」（３頁１行〜４頁下から６行）
（［当審仮訳］：
１．２．　用語
　アドレス可能なエンティティ（ＡＥ）：いくつかの相互接続技術が与えられた，直接アドレス可能なエンティティ。例えば，ＩＰネットワークではＩＰアドレスを用いて通信できるデバイスであり，スイッチ・ファブリックではスイッチ・ファブリック・ポート番号を用いて通信できるデバイスである。
　物理転送要素（ＰＦＥ）：パケット毎に処理し扱うためのハードウェアを含むＡＥ。このハードウェアは，（これに制限されないが）ネットワーク・プロセッサ，ＡＳＩＣ，又はラインカード，ドーターボード，メザニンカードがインストールされた汎用目的のプロセッサからなり，又はスタンド・アローン・ボックスにある。
（中略）
　物理制御要素（ＰＣＥ）：制御機能を与えるために使用されるハードウェアを含むＡＥ。このハードウェアは，典型的に汎用目的のプロセッサを含む。
（中略）
　転送要素（ＦＥ）：ＦｏｒＣＥＳプロトコルを実行する論理エンティティ。ＦＥｓは，ＦｏｒＣＥＳプロトコルを介してＣＥにより指示されたとおりパケット毎に処理し扱うために，基礎をなすハードウェアを使用する。
　制御要素（ＣＥ）：ＦｏｒＣＥＳプロトコルを実行する論理エンティティであり，１又はそれ以上のＦＥｓにどのようにパケットを処理するかを指示するために使用される。ＣＥｓは，制御の実行及びシグナリング・プロトコルのような機能を扱う。
　ＦｏｒＣＥＳネットワーク要素（ＮＥ）：１又はそれ以上のＣＥｓ及び１又はそれ以上のＦＥｓからなるエンティティ。ＮＥは通常その内部組織を外部エンティティから隠しており，ＮＥの外のエンティティに対して管理の単一ポイントを代表する。
　プレ・アソシエーション・フェーズ：ＦＥマネージャーとＣＥマネージャーがあるＦＥとあるＣＥが同じネットワーク要素の部分となるべきかどうかを決定する期間である。
（中略）
　ＦＥマネージャー：プレ・アソシエーション・フェーズにおいて操作する論理エンティティであり，ＦＥがどのＣＥ（ｓ）に対して通信すべきかを決定することに責任を負う。この処理はＣＥディスカバリーと呼ばれ，ＦＥマネージャーが利用可能なＣＥｓの能力を知っておくことを含む。
（中略）
　ＣＥマネージャー：プレ・アソシエーション・フェーズにおいて操作する論理エンティティであり，ＣＥがどのＦＥ（ｓ）に対して通信すべきかを決定することに責任を負う。この処理はＦＥディスカバリーと呼ばれ，ＣＥマネージャーが利用可能なＦＥｓの能力を知っておくことを含む。）
　
（２）「2. Introduction to Forwarding and Control Element Separation (ForCES)
　　An IP network element (NE) appears to external entities as a monolithic piece of network equipment, e.g., a router, NAT, firewall, or load balancer.  Internally, however, an IP network element (NE) (such as a router) is composed of numerous logically separated entities that cooperate to provide a given functionality (such as routing).  Two types of network element components exist: control element (CE) in control plane and forwarding element (FE) in forwarding plane (or data plane).  Forwarding elements are typically ASIC, network-processor, or general-purpose processor-based devices that handle data path operations for each packet.  Control elements are typically based on general-purpose processors that provide control functionality, like routing and signaling protocols.
　　ForCES aims to define a framework and associated protocol(s) to standardize information exchange between the control and forwarding plane.  Having standard mechanisms allows CEs and FEs to become physically separated standard components.  This physical separation accrues several benefits to the ForCES architecture.  Separate components would allow component vendors to specialize in one component without having to become experts in all components. Standard protocol also allows the CEs and FEs from different component vendors to interoperate with each other and hence it becomes possible for system vendors to integrate together the CEs and FEs from different component suppliers.  This interoperability translates into increased design choices and flexibility for the system vendors.  Overall, ForCES will enable rapid innovation in both the control and forwarding planes while maintaining interoperability. Scalability is also easily provided by this architecture in that additional forwarding or control capacity can be added to existing network elements without the need for forklift upgrades.」（５頁１８行〜６頁７行）
（［当審仮訳］：
２．　転送及び制御要素の分離（ＦｏｒＣＥＳ）フレームワークの導入
　ＩＰネットワーク要素は，例えば，ルータ，ＮＡＴ，ファイアウォール又はロードバランサーのように，外部エンティティにとってネットワーク要素のモノリシック部品として見える。しかし，内部的には（ルータのような）ＩＰネットワーク要素（ＮＥ）は，与えられた（ルーティングのような）機能を共同して提供する，多数の論理的に分離されたエンティティからなっている。２つのタイプのネットワーク要素の構成要素：制御プレーンの制御要素（ＣＥ）及び転送プレーン（又はデータ・プレーン）の転送要素（ＦＥ）が存在する。転送要素は，典型的にＡＳＩＣ，ネットワーク・プロセッサ，又は汎用目的のプロセッサに基づくデバイスであり，各パケットに対してデータパス操作を扱う。制御要素は，典型的に汎用目的のプロセッサに基づくデバイスであり，ルーティングやシグナリング・プロトコルのような制御機能を提供する。
　ＦｏｒＣＥＳは，フレームワーク，及び制御プレーンと転送プレーンとの間の情報交換を標準化する関連したプロトコルを定義することを目的とする。標準化メカニズムにより，ＣＥｓとＦＥｓは物理的に分離した標準的な構成要素となることを可能とする。この物理的な分離がＦｏｒＣＥＳアーキテクチャに様々な利益をもたらす。分離された構成要素は，構成要素ベンダーが，全ての構成要素におけるエキスパートになることなしに，１つの構成要素に特化することを可能とする。標準化されたプロトコルは，異なるベンダーからのＣＥｓとＦＥｓが，互いに相互操作することを可能とし，そのため，システムベンダーが異なる構成要素サプライヤーからのＣＥｓとＦＥｓとを一緒に統合することを可能とする。この相互操作性は，システムベンダーに対して設計の選択やフレキシビリティーを増加することになる。概していえば，ＦｏｒＣＥＳは，相互操作性を維持しつつ，制御プレーン及び転送プレーンの双方における迅速な革新を可能とする。このアーキテクチャにより拡張性も容易に与えられ，フォークリフト・アップグレードを要することなく，既存のネットワーク要素に追加的な転送又は制御能力が追加されることができる。）
　
（３）「One example of such physical separation is at the blade level. Figure 1 shows such an example configuration of a router, with two control blades and multiple forwarding blades, all interconnected into a switch fabric backplane.  In such a chassis configuration, the control blades are the CEs while the router blades are the FEs, and the switch fabric backplane provides the physical interconnect for all the blades.  Control blade A may be the primary CE while control blade B may be the backup CE providing redundancy.  It is also possible to have a redundant switch fabric for high availability support.  Routers today with this kind of configuration use proprietary interfaces for messaging between CEs and FEs.  The goal of ForCES is to replace such proprietary interfaces with a standard protocol.  With a standard protocol like ForCES implemented on all blades, it becomes possible for control blades from vendor X and forwarding blades from vendor Y to work seamlessly together in one chassis.
　　Another level of physical separation between the CEs and FEs can be at the box level.  In such a configuration, all the CEs and FEs are physically separated boxes, interconnected with some kind of high speed LAN connection (like Gigabit Ethernet).  These separated CEs and FEs are only one hop away from each other within a local area network.  The CEs and FEs communicate to each other by running ForCES, and the collection of these CEs and FEs together become one routing unit to the external world.  Figure 2 shows such an example.
　　In both examples shown here, the same physical interconnect is used for both CE-to-FE and FE-to-FE communication.  However, that does not have to be the case.  One reason to use different interconnects is that the CE-to-FE interconnect does not have to be as fast as the FE-to-FE interconnect, so the more faster and more expensive connections can be saved for FE-to-FE.  The separate interconnects may also provide reliability and redundancy benefits for the NE.」（６頁８行〜７頁１５行）
（［当審仮訳］：
　物理的な分離の一例はブレード・レベルにおけるものである。図１は，２つの制御ブレードと多数の転送ブレードが，スイッチ・ファブリック・バックプレーンに全て相互接続されている，ルータの設定例を示している。このようなシャシ設定では，制御ブレードはＣＥｓであり，ルータ・ブレードはＦＥｓであり，スイッチ・ファブリック・バックプレーンは全てのブレードに物理的な接続を与える。制御ブレードＡは主ＣＥであり，一方，制御ブレードＢは冗長性を与えるバックアップＣＥであるかもしれない。高い有用性をサポートために，冗長のスイッチ・ファブリック・バックプレーンを持つことも可能である。今日のこの種の設定のルータは，ＣＥｓとＦＥｓとの間のメッセージングに専用インターフェースを用いている。ＦｏｒＣＥＳの目標は，このような専用インターフェースを標準プロトコルに置き換えることである。ＦｏｒＣＥＳのような標準プロトコルが全てのブレードに実行されることにより，ベンダーＸの制御ブレードとベンダーＹの転送ブレードが１つのシャシに一緒になってシームレスに作動することが可能になる。
　ＣＥｓとＦＥｓとの間の他のレベルの物理的な分離はボックス・レベルにおけるものである。このような設定では，全てのＣＥｓとＦＥｓは物理的に分離されたボックスであり，（ギガビット・イーサネットのような）ある種の高速ＬＡＮ接続により相互接続される。これらの分離されたＣＥｓ及びＦＥｓは，ローカル・エリア・ネットワーク内でお互いに１ホップだれ離れている。ＣＥｓとＦＥｓはＦｏｒＣＥＳを実行することによりお互いに通信し，これらＣＥｓとＦＥｓの集合は外部世界にとって１つのルーティング・ユニットになる。図２はその例を示している。
　ここに示す例の双方において，ＣＥ−ＦＥ及びＦＥ−ＦＥ通信の双方に同じ物理的相互接続が使用される。しかし，それは必須ではない。異なる相互接続を用いる理由の１つは，ＣＥ−ＦＥの相互接続はＦＥ−ＦＥの相互接続ほど高速でなければならないわけではなく，より高速でより高価な接続をＦＥ−ＦＥのためにとっておける。分離した相互接続はまた，信頼性及び冗長性の利益をＮＥに与えるかも知れない。）
　
（４）「3. Architecture
　　This section defines the ForCES architectural framework and the associated logical components.  This ForCES framework defines components of ForCES NEs, including several ancillary components. These components may be connected in different kinds of topologies for flexible packet processing.
　　　Fp: CE-FE interface
　　　Fi: FE-FE interface
　　　Fr: CE-CE interface
　　　Fc: Interface between the CE Manager and a CE
　　　Ff: Interface between the FE Manager and an FE
　　　Fl: Interface between the CE Manager and the FE Manager
　　　Fi/f: FE external interface
　　The diagram in Figure 4 shows the logical components of the ForCES architecture and their relationships.  There are two kinds of components inside a ForCES network element: control element (CE) and forwarding element (FE).  The framework allows multiple instances of CE and FE inside one NE.  Each FE contains one or more physical media interfaces for receiving and transmitting packets from/to the external world.  The aggregation of these FE interfaces becomes the NE's external interfaces.  In addition to the external interfaces, there must also exist some kind of interconnect within the NE so that the CE and FE can communicate with each other, and one FE can forward packets to another FE.  The diagram also shows two entities outside of the ForCES NE: CE Manager and FE Manager.  These two ancillary entities provide configuration to the corresponding CE or FE in the pre-association phase (see Section 4.1).
　　For convenience, the logical interactions between these components are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown in Figure 4.  The FE external interfaces are labeled as Fi/f.  More detail is provided in Section 3 and 4 for each of these reference points.  All these reference points are important in understanding the ForCES architecture, however, the ForCES Protocol is only defined over one reference point -- Fp.
　　The interface between two ForCES NEs is identical to the interface between two conventional routers and these two NEs exchange the protocol packets through the external interfaces at Fi/f.  ForCES NEs connect to existing routers transparently.」（８頁１４行〜１０頁１１行）
（［当審仮訳］：
３．　アーキテクチャ
　本セクションは，ＦｏｒＣＥＳのアーキテクチャ的なフレームワーク及び関連する論理構成要素を定義する。ＦｏｒＣＥＳアーキテクチャは，いくつかの補助的な構成要素を含むＦｏｒＣＥＳ　ＮＥｓの構成要素を定義する。これらの構成要素は，フレキシブルなパケット処理のために，異なった種類のトポロジーで接続されるかもしれない。
　　Ｆｐ：ＣＥ−ＦＥインターフェース
　　Ｆｉ：ＦＥ−ＦＥインターフェース
　　Ｆｒ：ＣＥ−ＣＥインターフェース
　　Ｆｃ：ＣＥマネージャーと１つのＣＥの間のインターフェース
　　Ｆｆ：ＦＥマネージャーと１つのＦＥの間のインターフェース
　　Ｆｌ：ＣＥマネージャーとＦＥマネージャーとの間のインターフェース
　　Ｆｉ／ｆ：ＦＥの外部インターフェース
　図４は，ＦｏｒＣＥＳアーキテクチャの論理構成要素とそれらの関係を示している。ＦｏｒＣＥＳネットワーク要素の内部には２種類の構成要素：制御要素（ＣＥ）及び転送要素（ＦＥ）がある。フレームワークは，１つのＮＥの中のＣＥ及びＦＥの多数の例を許容している。各ＦＥは，外界から／への受信又は送信パケットのための１又はそれ以上の物理的なメディア・インターフェースを含んでいる。これらのＦＥインターフェースの集合体がＮＥの外部インターフェースとなっている。外部インターフェースに加えて，ＣＥとＦＥとが互いに通信したり，あるＦＥが他のＦＥにパケットを転送したりすることができるために，ＮＥ内にいくつかの種類の相互接続も存在しなければならない。図はＦｏｒＣＥＳ　ＮＥの外側の２つのエンティティ：ＣＥマネージャー及びＦＥマネージャーも示している。これらの２つの補助的なエンティティーは，プレ・アソシエーション・フェーズ（セクション４．１参照）における，対応するＣＥ又はＦＥの設定を与える。
　便宜上，これらの構成要素間の論理的な相互動作は，図４に示すとおり，参照ポイントＦｐ，Ｆｃ，Ｆｆ，Ｆｒ，Ｆｌ及びＦｉとラベル付けされる。ＦＥの外部インターフェースはＦｉ／ｆとラベル付けされる。各参照ポイントの詳細はセクション３，４で与えられる。これらの全ての参照ポイントは，ＦｏｒＣＥＳアーキテクチャを理解する上で重要であるが，ＦｏｒＣＥＳプロトコルは一参照ポイントＦｐについてのみ定義されている。
　ＦｏｒＣＥＳ　ＮＥ間のインターフェースは２つの従来のルータ間のインターフェースと全く同じであり，これら２つのＮＥｓはＦｉ／ｆの外部インターフェースを介してプロトコル・パケットを交換する。）
　
（５）「3.1. Control Elements and Fr Reference Point
　　It is not necessary to define any protocols across the Fr reference point to enable control and forwarding separation for simple configurations like single CE and multiple FEs.  However, this architecture permits multiple CEs to be present in a network element. In cases where an implementation uses multiple CEs, the invariant that the CEs and FEs together appear as a single NE must be maintained.
　　Multiple CEs may be used for redundancy, load sharing, distributed control, or other purposes.  Redundancy is the case where one or more CEs are prepared to take over should an active CE fail.  Load sharing is the case where two or more CEs are concurrently active and any request that can be serviced by one of the CEs can also be serviced by any of the other CEs.  For both redundancy and load sharing, the CEs involved are equivalently capable.  The only difference between these two cases is in terms of how many active CEs there are simultaneously.  Distributed control is the case where two or more CEs are concurrently active but certain requests can only be serviced by certain CEs.
　　When multiple CEs are employed in a ForCES NE, their internal organization is considered an implementation issue that is beyond the scope of ForCES.  CEs are wholly responsible for coordinating amongst themselves via the Fr reference point to provide consistency and synchronization.  However, ForCES does not define the implementation or protocols used between CEs, nor does it define how to distribute functionality among CEs.  Nevertheless, ForCES will support mechanisms for CE redundancy or fail over, and it is expected that vendors will provide redundancy or fail over solutions within this framework.」（１０頁１２〜末行）
（［当審仮訳］：
３．１．　制御要素及びＦｒ制御ポイント
　単一のＣＥと多数のＦＥｓのような単純な設定に対する制御と転送の分離を可能とするために，Ｆｒ参照ポイントを横切るいかなるプロトコルを定義する必要はない。しかし，本アーキテクチャは１つのネットワーク要素に多数のＣＥｓが存在することを許容している。多数のＣＥｓが使用される例では，ＣＥｓとＦＥｓがともに１つの単一ＮＥとしてみえるという不変性が維持される必要がある。
　多数のＣＥｓは，冗長性，ロード・シェアリング，分散制御又はその他の目的のために用いられるかも知れない。冗長性は，１又はそれ以上のＣＥｓがある現用ＣＥの故障を引き継ぐために準備している場合である。ロード・シェアリングは，２又はそれ以上のＣＥｓが同時に現用となっており，ＣＥｓの１つによりサービスされ得るいかなる要求も，他のいずれのＣＥｓによってもサービスされ得る場合である。冗長性及びロード・シェアリングの双方にとって，関与したＣＥｓは等しく能力を持っている。これら２つの場合の間の違いは，同時に現用となるＣＥｓの数がどれだけあるかだけである。分散制御は，２つ又はそれ以上のＣＥｓが同時に現用となるが，ある要求はあるＣＥｓによってのみサービスされ得る場合である。
　多数のＣＥがＦｏｒＣＥＳ　ＮＥ内で使用される場合に，それらＣＥの内部的な組織化は，ＦｏｒＣＥＳの範囲を超える実装の問題として考慮される。複数のＣＥは，整合性及び同期を提供するために，Ｆｒ参照ポイントを介してそれらＣＥ自身の間での調整に全責任を負う。しかしながら，ＦｏｒＣＥＳは，複数のＣＥ間で使用されるプロトコル又は実装を定義せず，複数のＣＥの間で機能性を如何に分散するかも定義しない。それでも，ＦｏｒＣＥＳはＣＥの冗長性や故障に対するメカニズムをサポートし，ベンダーがこのフレームワーク内で冗長性や故障に対する解決を提供することが期待されている。）
　
（６）「3.2. Forwarding Elements and Fi reference point
　　An FE is a logical entity that implements the ForCES Protocol and uses the underlying hardware to provide per-packet processing and handling as directed by a CE.  It is possible to partition one physical FE into multiple logical FEs.  It is also possible for one FE to use multiple physical FEs.  The mapping between physical FE(s) and logical FE(s) is beyond the scope of ForCES.  
（中略）
　　FEs perform all packet processing functions as directed by CEs.  FEs have no initiative of their own.  Instead, FEs are slaves and only do as they are told.  FEs may communicate with one or more CEs concurrently across reference point Fp.  FEs have no notion of CE redundancy, load sharing, or distributed control.  Instead, FEs accept commands from any CE authorized to control them, and it is up to the CEs to coordinate among themselves to achieve redundancy, load sharing, or distributed control.  The idea is to keep FEs as simple and dumb as possible so that FEs can focus their resources on the packet processing functions. 
（中略）
　　For example, in Figure 5, FE1 and FE2 can be configured to accept commands from both the primary CE (CE1) and the backup CE (CE2). Upon detection of CE1 failure, perhaps across the Fr or Fp reference point, CE2 is configured to take over activities of CE1.  This is beyond the scope of ForCES and is not discussed further.
（中略）
　　When multiple FEs are present, ForCES requires that packets must be able to arrive at the NE by one FE and leave the NE via a different FE (See [4], Section 5, Requirement #3).  Packets that enter the NE via one FE and leave the NE via a different FE are transferred between FEs across the Fi reference point.  The Fi reference point could be used by FEs to discover their (inter-FE) topology, perhaps during the pre-association phase.  The Fi reference point is a separate protocol from the Fp reference point and is not currently defined by the ForCES Protocol.
（中略）
　　Figure 6 provides some topology examples.  When it is necessary to forward packets between FEs, the CE needs to understand the FE topology.  The FE topology may be queried from the FEs by the CEs via the ForCES Protocol, but the FEs are not required to provide that information to the CEs.  So, the FE topology information may also be gathered by other means outside of the ForCES Protocol (like inter-FE topology discovery protocol).」（１１頁１行〜１２頁末行）
（［当審仮訳］：
３．２．　転送要素及びＦｉ参照ポイント
　ＦＥはＦｏｒＣＥＳプロトコルを実行する論理エンティティであり，基礎をなすハードウェアを用いて，ＣＥにより指示されたとおりにパケット毎に処理し扱う。１つの物理的ＦＥを複数の論理ＦＥｓに分割することが可能である。１つのＦＥが多数の物理ＦＥｓを用いることも可能である。物理ＦＥ（ｓ）と論理ＦＥ（ｓ）のマッピングはＦｏｒＣＥＳの範囲外である。
（中略）
　ＦＥｓは，ＣＥｓから指示されたとおりに，全てのパケットの処理機能を実行する。ＦＥｓはイニシアチブは持たない。その代わり，ＦＥｓはスレーブであり，言われたとおりに動作する。ＦＥｓはＦｐ参照ポイントを横切って１つ又はそれ以上のＣＥｓと同時に通信する。ＦＥｓは，ＣＥｓの冗長性，ロード・シェアリング又は分散制御は考えていない。その代わり，ＦＥｓは，彼らを制御することが認可されたいずれのＣＥからの命令を受け付け，そして冗長性，ロード・シェアリング又は分散制御を達成するために彼らの間で調整することはＣＥｓの責任である。アイデアは，できる限りＦＥｓをシンプル且つ無口にし，ＦＥｓがその資源をパケット処理機能に集中できるようにすることである。
（中略）
　例として，図５に，ＦＥ１及びＦＥ２が主ＣＥ（ＣＥ１）及びバックアップＣＥ（ＣＥ２）の双方からの命令を受け付けることが示されている。おそらくＦｒ又はＦｐ参照ポイントを横切ってＣＥ１の故障を検知すると，ＣＥ２はＣＥ１の動作を引き継ぐように設定される。
（中略）
　多数のＦＥｓが存在する場合は，ＦｏｒＣＥＳは，パケットが１つのＦＥによってＮＥに到着し，他の１つのＦＥを介してＮＥから離れることが可能となるようにしなければならないことを要求する。１つのＦＥを介してＮＥに到着し他の１つのＦＥを介してＮＥから離れるパケットは，Ｆｉ参照ポイントを横切る。Ｆｉ参照ポイントは，おそらくプリ・アソシエーション・フェーズの間に，（ＦＥ間）トポロジーを発見するために，ＦＥによって使用されることができる。Ｆｉ参照ポイントはＦｐ参照ポイントとは分離されたプロトコルであり，今のところＦｏｒＣＥＳプロトコルでは定義されていない。
（中略）
　図６は，いくつかのトポロジーの例を示している。ＦＥｓ間でパケットを転送する必要があるときは，ＣＥはＦＥトポロジーを理解する必要がある。ＦＥトポロジーは，ＦｏｒＣＥＳプロトコルを介してＣＥｓによってＦＥから照会されるかもしれないが，ＦＥｓはその情報をＣＥｓに与えることを必要とされていない。それで，ＦＥトポロジー情報は，（ＦＥ内トポロジー発見プロトコルのような）ＦｏｒＣＥＳプロトコルの外側の他の手段によって収集されるかもしれない。）
　
（７）「3.3. CE Managers
　　CE managers are responsible for determining which FEs a CE should control.  It is legitimate for CE managers to be hard-coded with the knowledge of with which FEs its CEs should communicate with.  A CE manager may also be physically embedded into a CE and be implemented as a simple keypad or other direct configuration mechanism on the CE. Finally, CE managers may be physically and logically separate entities that configure the CE with FE information via such mechanisms as COPS-PR [7] or SNMP [5].
　
3.4. FE Managers
　　FE managers are responsible for determining with which CE any particular FE should initially communicate.  Like CE managers, no restrictions are placed on how an FE manager decides with which CE its FEs should communicate, nor are restrictions placed on how FE managers are implemented.  Each FE should have one and only one FE manager, while different FEs may have the same or different FE manager(s).  Each manager can choose to exist and operate independently of other manager.
　
4. Operational Phases
　　Both FEs and CEs require some configuration to be in place before they can start information exchange and function as a coherent network element.  Two operational phases are identified in this framework: pre-association and post-association.
　
4.1. Pre-association Phase
　　The Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining whether an FE and a CE should be part of the same network element.  The protocols used during this phase may include all or some of the message exchange over Fl, Ff, and Fc reference points.  However, all these may be optional and none of this is within the scope of the ForCES Protocol.
　
4.1.1. Fl Reference Point
　　CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine whether an individual CE and FE, or a set of CEs and FEs should be associated. Communication across the Fl reference point is optional in this architecture.  No requirements are placed on this reference point.
　　CE managers and FE managers may be operated by different entities. The operator of the CE manager may not want to divulge, except to specified FE managers, any characteristics of the CEs it manages. Similarly, the operator of the FE manager may not want to divulge FE characteristics, except to authorized entities.  As such, CE managers and FE managers may need to authenticate one another.  Subsequent communication between CE managers and FE managers may require other security functions such as privacy, non-repudiation, freshness, and integrity.
　　Once the necessary security functions have been performed, the CE and FE managers communicate to determine which CEs and FEs should communicate with each other.  At the very minimum, the CE and FE managers need to learn of the existence of available FEs and CEs respectively.  This discovery process may entail one or both managers learning the capabilities of the discovered ForCES protocol elements. Figure 7 shows an example of a possible message exchange between the CE manager and FE manager over the Fl reference point.」（１４頁１行〜１６頁８行）
（［当審仮訳］：
３．３．　ＣＥマネージャー
　ＣＥマネージャーは，どのＦＥｓをあるＣＥが制御すべきかを決定することに責任を負う。ＣＥマネージャーにとって，ＣＥｓがどのＦＥｓと通信すべきかの知識がハード・コード化されることは正当である。ＣＥマネージャーは，あるＣＥ内の物理的に埋め込まれ，単純なキーパッド又はＣＥ上の他の直接設定メカニズムとして実行されるかも知れない。最後に，ＣＥマネージャーは，ＣＯＰＳ−ＰＲやＳＮＭＰのようなメカニズムを介してＣＥにＦＥ情報を設定する，物理的にも論理的にも分離したエンティティであるかもしれない。
　
３．４．　ＦＥマネージャー
　ＦＥマネージャーは，いずれの特定のＦＥが初期的に通信すべきＣＥを決定することに責任を負う。ＣＥマネージャーと同様に，ＦＥマネージャーがどのようにＦＥｓが通信すべきＣＥを決定するかや，ＦＥマネージャーがどのように実行されるかについて，いかなる制限もない。各ＦＥは唯一のＦＥマネージャーを有するべきであり，一方，異なるＦＥｓは同じＦＥマネージャーを持つかもしれないし，異なるＦＥマネージャーを持つかもしれない。各マネージャーは，他のマネージャーとは独立して，存在を選択し，操作することができる。
　
４．　操作フェーズ
　ＦＥｓもＣＥｓも，それらが情報交換を開始しコヒーレント・ネットワーク要素として機能する前に，いくつかの設定がきちんとなされることを要する。本フレームワークでは２つの操作フェーズ：プリ・アソシエーション及びポスト・アソシエーションが知られている。
　
４．１．　プリ・アソシエーション・フェーズ
　プリ・アソシエーション・フェーズは，ＦＥマネージャーとＣＥマネージャーが，あるＦＥとあるＣＥが同じネットワーク要素の部分となるべきかどうかを決定する期間である。この期間に使用されるプロトコルは，Ｆｌ，Ｆｆ及びＦｃ参照ポイント上で交換される全て又はいくつかのメッセージを含むかも知れない。しかし，これらは全てオプショナルであり，いずれもＦｏｒＣＥＳプロトコルの範囲内のものではない。
　
４．１．１．　Ｆｌ参照ポイント
　ＣＥマネージャーとＦＥマネージャーは，プリ・アソシエーション・フェーズにおいて，個々のＣＥ及びＦＥ又はＣＥｓの集合及びＦＥｓの集合が関連付けられるべきかどうかを決定するために，Ｆｌ参照ポイントを横切って通信するかも知れない。本アーキテクチャでは，Ｆｌ参照ポイントを横切る通信はオプショナルである。この参照ポイントには何の要求も置かれていない。
　ＣＥマネージャーとＦＥマネージーは異なるエンティティーにより操作されるかもしれない。ＣＥマネージャーの操作者は，特定のＦＥマネージャーに対しては別として，管理するＣＥｓのいかなる特徴も漏らしたくないかもしれない。同様に，ＦＥマネージャーの操作者は，特定の認可されたエンティティに対しては別として，ＦＥの特徴を漏らしたくないかもしれない。このように，ＣＥマネージャー及びＦＥマネージャーはお互いに認証することをを必要とするかもしれない。ＣＥマネージャーとＦＥマネージャーとの間の引き続く通信は，プライバシー，非拒絶，新鮮，誠実のような他のセキュリティー機能を要するかもしれない。
　一旦必要なセキュリティー機能が実行されると，ＣＥマネージャー及びＦＥマネージャーは，どのＣＥｓとＦＥｓとが互いに通信すべきかを決定するために通信する。最低限，ＣＥマネージャー及びＦＥマネージャーは，各々利用可能なＦＥｓ及びＣＥｓの存在を知っておく必要がある。この発見的プロセスは，一方又は双方のマネージャーに，発見されたＦｏｒＣＥＳプロトコル要素の能力を知っておくことを必要とする。図７は，Ｆｌ参照ポイント上でＣＥマネージャーとＦＥマネージャーとの間で交換されるメッセージの例を示している。）
　
　上記記載及び当該技術分野の技術常識を考慮すると，
ア．上記（２），上記（４）及び図４の記載によれば，引用例にはネットワーク・アーキテクチャに関する事項が記載されていると認められる。
　
イ．上記（２）の第１段落の記載によれば，転送プレーン（データ・プレーン）は転送要素（ＦＥ）含むプレーンであり，転送要素は各パケットに対してデータパス操作を扱うものであるといえる。そして，上記（４），上記（６）の第４段落及び図４，図６の記載によれば，各転送要素（ＦＥ）はＦｉ参照ポイントによって相互に接続されており，また，Ｆｉ／ｆ参照ポイントにより外部と接続されるから，パケットを転送するためのネットワークが存在することは明らかである。したがって，データ・プレーンは，パケットを転送するためのネットワークであるということができる。
　したがって，引用例には「パケットを伝送するためのネットワークであり，複数の相互接続された転送要素（ＦＥ）を含む，データ・プレーン」が記載されていると認められる。
　
ウ．上記（２）の第１段落の記載によれば，制御プレーンは制御要素（ＣＥ）含むプレーンであり，制御用のプレーンといえ，上記（２）の第２段落，上記（３）の記載によれば，制御要素（ＣＥ）を含む制御プレーンと転送要素（ＦＥ）を含む転送プレーン（データ・プレーン）とは物理的に隔てられていることは明らかである。
　また，上記（４），（５）及び図４，５の記載によれば，複数の制御要素（ＣＥ）はＦｒ参照ポイントにより相互接続されているといえる。
　また，図６の記載によれば，それぞれのＣＥは複数のＦＥのうちの少なくとも２つを制御しているといえ，上記（１）の第７〜９段落，上記（７）の記載によれば，ＣＥとＦＥの対応関係は利用可能なＣＥｓとＦＥｓに基づいて発見的に決定されるから，それぞれのＣＥは制御されるＦＥに動的にバインドされるといえる。
　したがって，引用例には「該データ・プレーンから隔てられている制御用のプレーンであり，Ｆｒ参照ポイントにより相互接続された複数の制御要素（ＣＥ）を含み，それぞれのＣＥは該複数のＦＥのうちの少なくとも２つを制御し，それぞれのＣＥは制御されるＦＥに動的にバインドされる，制御プレーン」が記載されていると認められる。
　
エ．上記（４）及び図４の記載によれば，制御プレーンの制御要素（ＣＥ）と転送プレーンの転送要素（ＦＥ）との間にはＦｐ参照ポイントなるインターフェースが存在し，上記（２）の第２段落，上記（３）の記載によれば，ＣＥｓ−ＦＥｓの通信に標準プロトコルであるＦｏｒＣＥＳプロトコルが使用されるのであるから，引用例には「プロトコルを使用する該データ・プレーンと制御プレーンとの間のインターフェイスとを備え」ることが記載されていると認められる。
　
　以上を総合すると，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認める。
「ネットワーク・アーキテクチャであって，
　パケットを伝送するためのネットワークであり，複数の相互接続された転送要素（ＦＥ）を含む，データ・プレーンと，
　該データ・プレーンから隔てられている制御用のプレーンであり，Ｆｒ参照ポイントにより相互接続された複数の制御要素（ＣＥ）を含み，それぞれのＣＥは該複数のＦＥのうちの少なくとも２つを制御し，それぞれのＣＥは制御されるＦＥに動的にバインドされる，制御プレーンと，
　プロトコルを使用する該データ・プレーンと制御プレーンとの間のインターフェイスとを備える，
　ネットワーク・アーキテクチャ。」
　
　
３．対比・判断
（１）本願明細書の【００２６】の記載に照らせば，本願発明の「転送要素（ＦＥ）」，「制御要素（ＣＥ）」は，両方とも物理ネットワーク要素であることに加えて論理エンティティであり，物理パケット・スイッチ全体が複数の論理ＦＥで構成されたり，論理ＦＥが複数の物理スイッチにまたがることもあり，また，物理ＣＥサーバ・マシン（ＰＣＥ）は，それぞれ複数のＦＥからなる異なる集合体にサービスを提供する複数のＣＥプロセスをホスティングすることもあるところ，引用例の用語の説明等（上記２．（１），同（６）の第１段落参照。）の記載に照らせば，引用発明の「転送要素（ＦＥ）」，「制御要素（ＣＥ）」も表現のみならず実質的にも同様のものであることは明らかである。
　
（２）引用発明の「パケット」はデータを伝送するものであるから，「パケットを伝送するためのネットワーク」を「データ・トラフィックを伝送するためのネットワーク」と称することは任意である。
　
（３）本願発明の「制御プレーン」と引用発明の「制御プレーン」とは，以下の相違点１は別として，「該データ・プレーンから隔てられており，複数の相互接続された制御要素（ＣＥ）を含み，それぞれのＣＥは該複数のＦＥのうちの少なくとも２つを制御し，それぞれのＣＥは制御されるＦＥに動的にバインドされる，制御プレーン」の点で一致している。
　
　したがって，本願発明と引用発明とを対比すると，両者は，以下の点で一致し，また，相違している。
（一致点）
「ネットワーク・アーキテクチャであって，
　データ・トラフィックを伝送するためのネットワークであり，複数の相互接続された転送要素（ＦＥ）を含む，データ・プレーンと，
　該データ・プレーンから隔てられており，複数の相互接続された制御要素（ＣＥ）を含み，それぞれのＣＥは該複数のＦＥのうちの少なくとも２つを制御し，それぞれのＣＥは制御されるＦＥに動的にバインドされる，制御プレーンと，
　プロトコルを使用する該データ・プレーンと制御プレーンとの間のインターフェイスとを備える
　ネットワーク・アーキテクチャ。」
　
（相違点１）
　「制御プレーン」に関し，本願発明は「制御トラフィック用の他のネットワーク」であるのに対し，引用発明は制御要素（ＣＥ）間のインターフェースであるＦｒ参照ポイントにより制御要素（ＣＥ１，ＣＥ２）が相互接続され，Ｆｒ参照ポイントを介してＣＥ自身の間で調整を行ったり，Ｆｒ参照ポイントを介してＣＥ２はＣＥ１の欠陥を検出しＣＥ１の動作の引き継ぎができるものの，「制御トラフィック用の他のネットワーク」について明らかにしていない点。
　
（相違点２）
　「制御プレーン」に関し，本願発明は更に，「該データ・プレーンから物理的に隔てられている該制御プレーンは，該複数のＣＥ間の複数のプライベート・リンクを含み，それによって該複数のＣＥの間のアウトバウンド制御通信を可能にする」との構成を有するのに対し，引用発明は当該構成を明らかにしていない点。
　
　以下，上記各相違点について検討する。
（相違点１について）
　制御プレーンを制御要素間の制御データを伝送するための制御用ネットワークとすることは周知（例えば，原査定及び当審の拒絶理由に引用された特開２００３−３１８８９９号公報の【０００９】，図１，同じく引用された特開２００２−２６９９０号公報の【００２８】，図３参照。）であるから，引用発明において「制御プレーン」を「該データ・プレーンから隔てられている制御トラフィック用の他のネットワーク」とすることは容易になし得ることである。
　
（相違点２について）
　制御要素（ＣＥ）間でやり取りされる情報は，ＣＥ間の調整や機能の引き継ぎに係る情報等であるから，制御要素（ＣＥ）以外に伝送する必要性がないことは明らかである。したがって，制御要素（ＣＥ）間の相互接続（制御用ネットワーク）をプライベート・リンクとすること，すなわち，「該データ・プレーンから物理的に隔てられている該制御プレーンは，該複数のＣＥ間の複数のプライベート・リンクを含」むようにすることは，当業者が適宜になし得ることに過ぎない。
　また，本願明細書の【００４２】に照らせば，本願発明の「アウトバウンド制御通信」とは制御パケットがデータ経路をトラバースしない物理的に分離されたネットワークを経由して互いに通信することと解されるから，上記特開２００３−３１８８９９号公報，特開２００２−２６９９０号公報に示された制御用ネットワークを介した通信も「アウトバウンド制御通信」に他ならない。したがって，「それによって該複数のＣＥの間のアウトバウンド制御通信を可能にする」点は，制御プレーンを制御用ネットワークとすることにより自ずと導出されることであって，格別でない。
　よって，相違点２は格別でない。
　
　そして，本願発明の作用効果も，引用発明及び周知技術に基づいて当業者が予測し得る範囲のものであり，格別なものではない。
　
　
４．むすび
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　
　よって，結論のとおり審決する。