• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1354469
審判番号 不服2018-9853  
総通号数 238 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-10-25 
種別 拒絶査定不服の審決 
審判請求日 2018-07-19 
確定日 2019-09-03 
事件の表示 特願2016-206949「集中式コントロールプレーンに基づくパス状態の報告演算方法」拒絶査定不服審判事件〔平成29年 5月25日出願公開、特開2017- 92957、請求項の数(6)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は, 平成28年10月21日(パリ条約による優先権主張2015年11月5日,台湾)の出願であって,その手続の経緯は以下のとおりである。
平成29年 8月14日付け 拒絶理由通知書
平成29年11月21日 意見書,手続補正書の提出
平成30年 3月13日付け 拒絶査定
平成30年 7月19日 審判請求書,手続補正書の提出

第2 原査定の概要
原査定(平成30年3月13日付け拒絶査定)の概要は以下のとおりである。

この出願の請求項1ないし7に係る発明は,その優先権主張日前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その優先権主張日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

＜引用文献等一覧＞
1.国際公開第2015/119611号
2.Mukesh Hira, et. al.,Improving Network Monitoring and Management with Programmable Data Planes,[online],The P4 Language Consortium,2015年 9月25日,[retrived on 2017-08-14]. Retrived from the Internet:

第3 審判請求時の補正について
審判請求時の補正は,特許法第17条の2第3項から第6項までの要件に違反しているものとはいえない。
審判請求時の補正によって請求項1に「実際のパケットをシミュレーションしたテストパケットを生成することについて、主にテストパケットのpayloadに専用のキーワードを記入することで、テストパケットが同じheaderを有する他のパケットと区別できるものである」という事項を追加する補正は,補正前の請求項1の「実際のパケットをシミュレーションしたテストパケットを生成」することについて,「主にテストパケットのpayloadに専用のキーワードを記入することで、テストパケットが同じheaderを有する他のパケットと区別できるものである」との限定を加えるものであるから,特許請求の範囲の減縮を目的とするものであり,当初明細書の【請求項4】や段落【0022】に記載されているから,当該補正は新規事項を追加するものではない。
そして,「第4 本願発明」から「第6 対比・判断」までに示すように,補正後の請求項1ないし6に係る発明は,独立特許要件を満たすものである。

第4 本願発明
本願請求項1ないし6に係る発明(以下,それぞれ「本願発明1」ないし「本願発明6」という。)は,平成30年7月19日付けの手続補正書で補正された特許請求の範囲の請求項1ないし6に記載された事項により特定される発明であり,以下のとおりの発明である。
「【請求項1】
ネットワーク管理者のネットワーク管理ツールによって実行され、
生成段階として、テストを行いたいデータフロー情報に従い実際のパケットをシミュレーションしたテストパケットを生成し、
テスト段階として、テストパケットをテストを行いたいパスが通過する交換機に送信し、パステストを行い、
報告段階として、データフローが通過する実際のパスとパス状態を報告する、ことを主に含み、
テスト段階が、テストパケットをテストを行いたいパス始点に位置する交換機に送信し、交換機が直ちに行う報告、テストを行いたいパス終点に位置する交換機による報告済かの判断と時間制限に到達済かの判断を待機後に受信し、終点交換機による報告済かの判断が主に終点交換機による報告済か否かの判断であり、報告済ならば報告段階に入り、未報告ならば時間制限に到達済の判断に入る手順であり、時間制限に到達済かの判断の手順が主にテストの時間制限が到達済か否かの判断であり、到達済ならば報告段階に入り、未到達ならば交換機が直ちに報告するのを待機後に受信するに戻る手順を含み、
実際のパケットをシミュレーションしたテストパケットを生成することについて、主にテストパケットのpayloadに専用のキーワードを記入することで、テストパケットが同じheaderを有する他のパケットと区別できるものである、
集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項2】
テストを行いたいデータフロー情報に従い実際のパケットをシミュレーションしたテストパケットを生成することについて、テストを行いたいデータフロー情報に従い、テストパケットのheaderを生成することで、テストパケットがテストを行いたいデータフローのパケットと同様のルーティングアクションを備える状態を確保するものである、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項3】
テストを行いたいデータフロー情報が送信元MAC、宛先MAC、送信元IP又は宛先IPのパケットの識別用に使える情報を含む、
請求項1又は2に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項4】
テストパケットをテストを行いたいパス始点に位置する交換機に送信することについて、主に始点の交換機に準備段階で生成したテストパケットを送信する、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項5】
交換機が直ちに報告するのを待機後に受信することについて、主に終点の交換機が報告するテストパケットを待機後に受信するものである、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項6】
報告段階が、ネットワーク管理者にテスト段階時にネットワークエレメントが報告した状況に従い集合させたデータフローの実際のパスとパス状態を報告するものである、請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。」

第5 引用文献,引用発明等
1 引用文献1について
原査定の拒絶の理由された引用文献1には,図面とともに次の事項が記載されている。

「 Background
[0001] In a software defined network (SDN), applications can control the way that packets traverse a network. An SDN is a network where the data plane (the underlying systems that forward traffic) is separated from the control plane (the system that makes decisions about how traffic traverses the network). These applications can control packet flows by programming flow tables on network devices such as switches, routers, bridges, etc. Examples of such applications can include load balancers, network address translation (NAT), security applications, and routing applications such as open shortest path first (OSPF), etc. 」
(当審訳:背景技術
[0001] ソフトウェア定義ネットワーク(SDN)では,アプリケーションは,パケットがネットワークを通過する方法を制御することができる。SDNは,データプレーン(トラフィックを転送する基盤となるシステム)がコントロールプレーン(トラフィックがネットワークをどのように通過するかを決定するシステム)から分離されたネットワークである。これらのアプリケーションは,スイッチ,ルータ,ブリッジ等のネットワークデバイス上の経路テーブルをプログラミングすることによって,パケット経路を制御する。そのようなアプリケーションの例には,ロードバランサー,ネットワークアドレス変換(NAT),セキュリティアプリケーション,およびｏｐen ｓhｏｒｔeｓｔ ｐaｔh fiｒｓｔ(OSPF)などのルーティングアプリケーションが含まれる。)

「[0017] According to a number of examples of the present disclosure, a network administrator can use the network controller 102 to generate a trace packet including a source address matching a source address of the existing flow 108 (e.g., the address 10.0.0.6 of the computing device 104-2), a destination address matching the destination address of the existing flow 108 (e.g., the address 10.0.0.5 of the computing device 104-1 ), and a unique identifier (UID) for the trace packet. The network controller 102 can encipher the trace packet to generate the UID so that the network controller 102 can identify it uniquely for efficient and proper analysis (e.g., as opposed to reflecting other traffic associated with the existing flow 108 to the network controller 102). Enciphering the trace packet can include converting the trace packet to a coded form (e.g., by operation of an algorithm such as a hashing algorithm, where operating the algorithm using the trace packet as an input generates the UID). The UID can be registered on the network controller 102. Registering the UID on the network controller 102 and/or embedding the UID in the trace packet that may reach the observation post 107 can facilitate unique identification of the trace packet by the observation post 107 and/or the network controller 102. The observation post 107 is described in more detail below. Registering the UID can allow the network controller 102 to encipher a received packet to generate a UID, compare it to the registered UID, and in response to the UIDs matching, identify that the received packet matches the trace packet. In some examples, the UID can be added to the trace packet (e.g., during generation of the trace packet and enciphering thereof). Trace packets can be generated for protocols that carry a data payload in some form such as protocols in the network layer or above in the Open Systems Interconnection (OSI) model. Examples of such protocols can include the transmission control protocol (TCP), user datagram protocol (UDP), dynamic host configuration protocol (DHCP), and ICMP, among others.
[0018] The network controller 102 can be used to assign an observation post 107 (e.g., network device 106-1 ). The observation post 107 can be assigned to any of the network devices 106 on the programmed path 108. The network controller 102 can instruct the observation post 107 to send any packet that includes the matching criteria specified by the trace packet to the network controller 102 for path analysis. Once the observation post 107 has been assigned, a trace packet can be generated with the UID to test the programmed path 108. If the observation post 107 receives a packet with the specified matching criteria, it can send a copy of the packet to the network controller 102. The network controller 102 can decode the packet to get a fingerprint of the packet (e.g., the path history of the packet, including addresses and/or ports of network devices 106 through which it has traversed) and/or the UID. In response to the received fingerprint matching the matching criteria of the trace packet (e.g., matching the programmed path 108), the network controller 102 can update its record (e.g., memory structure) that it received the trace packet from the observation post 107. The network controller 102 can set a success status for the observation post 107 in response to the trace packet being received from the observation post 107. The network administrator can use the network controller 102 to query whether the trace packet was received from the observation post 107. If the status is set to success, it means that the programmed path is correct with respect to the network device 106 assigned as the observation post 107. If the status is not set to success, it means that either the trace packet is being dropped or that it is not yet received by the observation post.
[0019] The network administrator can use the network controller 102 to reassign the observation post 107 to a different network device (e.g., network device 106-2) along the programmed path 108 of the trace packet (e.g., in response to the success status being set for the previous observation post). Moving the observation post 107 can facilitate a determination of the point of failure along the programmed path 108.
[0020] Figure 2 is a diagram illustrating an example of a network 200 according to the present disclosure. The network 200 can be analogous to the network 100 illustrated in Figure 1 . The network 200 can be an SDN and include an SDN controller 202. The network 200 is illustrated including a number of computing devices 204-1 , 204-2 (referred to generally herein as computing devices 204) and a number of network devices 206-1 , 206-2, 206-3 (referred to generally herein as network devices 206). A first computing device 204-1 is connected to a second computing device 204-2 via a number of physical links 210 through a first network device 206-1 , a second network device 206-2, and a third network device 206-3. In the example illustrated in Figure 2, the physical links 210 (e.g., expected path) are the same as the programmed path 208 (e.g., existing flow). Figure 2 also includes a number of path injector and path analysis actions 214 as described herein (e.g., implemented in the control plane of the network 200).
[0021] Figure 2 includes a flow table for each network device (e.g., flow table 215 for network device 206-2). The flow tables can include flow rules for existing flows (e.g., existing flow 225 defined in flow table 215). By way of example, the network controller 202 can assign an observation post to the second network device 206-2 to test the programmed path 208 between the first computing device 204-1 and the second computing device 204-2. In some examples, a network administrator can assign the observation post via the network controller 202. The network controller 202 can generate a trace packet 213 and register the trace packet 213 (as used herein, registering the trace packet can include registering the trace packet itself, registering a fingerprint of the trace packet, and/or registering a UID of the trace packet) to an existing flow 225 based on a source address 216-2, a destination address 218-2, and a protocol of the trace packet 213. In some examples, a network administrator can define the trace packet via the network controller 202. As illustrated, an existing flow 225 defined on the second network device 206-2 includes a source address 216-1 and a destination address 218-1 that match the source address 216-2 and the destination address 218-2 of the trace packet 213. In some examples, the incoming port 220-2 of a particular network device of the trace packet 213 can match an incoming port 220-1 of the existing flow 225. Accordingly, a flow rule 226 can be added to the existing flow 225 on the second network device 206-2, where the flow rule 226 includes the source address 216-2, the destination address 218-2, an incoming port 220-2, a priority 222-2, and an outgoing port / action 224-2 for the trace packet 213.
[0022] The flow rule 226 can be added for the trace packet 213 with a higher priority 222-2 (e.g., 1001 ) than a priority 222-1 (e.g., 1000) of the existing flow 225 corresponding to the trace packet 213 on the second network device 206-2. The higher priority for the flow rule 226 for the trace packet 213 can cause the second network device 206-2 to take the defined action 224-2 for the flow rule 226 before and/or instead of taking the defined action for the existing flow 225. In the example illustrated in Figure 2, this means that the corresponding packet (trace packet 213) would be sent out of the "controller port" (e.g., be sent to the network controller 202).
[0023] Although not specifically illustrated in the flow rule 226 in Figure 2, the flow rule 226 can specify a more specific flow based on flow table capability in order to send only one class of traffic consisting of the trace packet to the network controller 202 (e.g., to reduce the volume of traffic being sent to the controller 202).
[0024] Although not specifically illustrated in the flow rule 226 in Figure 2, the flow rule 226 can also specify a protocol for the trace packet 213. Thus, the trace packet 213 can be application specific. Specifying a protocol can prevent the second network device 206-2 from sending any packet (e.g., other traffic that is associated with a flow that is not experiencing an error because the flow for that protocol is working properly) that matched the source address 216-2 and destination address 218-2 of the trace packet 213 to the network controller 202.
[0025] The network controller 202 can inject the trace packet 213 into the network 200 on behalf of a source of the existing path (e.g., computing device 204-1 ) via a specified port of a network device (e.g., port 2 of network device 206-1 ) along a programmed path 208 of the existing flow. As illustrated, the network controller 202 can inject the trace packet 213 via a port of a network device 206-1 that is upstream, with respect to the programmed path 208, of the network device 206-2 that is assigned an observation post and downstream of the computing device 204-1 that is the source of the flow.
[0026] If the programmed path 208 is programmed correctly on the first network device 206-1 where the trace packet 213 is injected, then the first network device 206-1 should correctly forward the trace packet 213 to the second network device 206-2 (e.g., out of port 3 of the first network device 206- 1 and into port 4 of the second network device 2026-2). Because the second network device 206-2 has been assigned the observation post with the accompanying flow rule 226, the second network device 206-2 will send the trace packet 213 to the network controller 202. In some examples, the network controller 202 can set a success status for the second network device 206-2 (observation post) merely because the trace packet 213 was received therefrom. In some examples, the network controller 202 can first examine a fingerprint of the trace packet received from the second network device 206-2 and compare it to expected matching criteria for the trace packet 213 based on the programmed path 208. In this example, the fingerprint and/or matching criteria could include information such as one or more of the following: the source address of the computing device 204-1 (00:1 E:0B:AE:D3:BE), the outgoing port (1 ) of the computing device 204-1 , the incoming port (2) of the first network device 206-1 , the outgoing port (3) of the first network device 206-1 , the incoming port (4) of the second network device 206-2, and/or the destination address (00:0c:29:03:7f:48) of the second computing device 204-2. If the fingerprint of the trace packet received from the second network device 206-2 matches the expected matching criteria for the trace packet 213, then the network controller 202 can set the success status for the second network device 206-2.
[0027] After the network controller 202 sets the success status for the second network device 206-2, a network administrator can query a status for the second network device 206-2 (e.g., via the network controller 202). If the status is set to success, then the network administrator may wish to continue testing the programmed path 208. The network controller 202 can inject the trace packet 213 back into the network 200 via a defined network device (e.g., via the second network device 206-2) and instruct a different observation post (e.g., a different network device 206-3 downstream of the previous observation post with respect to the existing flow) to send any packet that includes the UID to the network controller 202. This testing process can continue until the test packet 213 is not returned to the network controller 202, which would indicate that the observation post that is assigned when the test packet 213 is not returned to the network controller 202 can be a point of failure. 」
(当審訳:[0017] 本開示のいくつかの例によれば,ネットワーク管理者は,ネットワークコントローラ102を使用して,既存の経路108のソースアドレスと一致するソースアドレス(例えば,コンピューティングデバイス104-2のアドレス10.0.0.6)と,既存の経路108の宛先アドレスに一致する宛先アドレス(例えば,コンピューティングデバイス104-1のアドレス10.0.0.5)と,トレースパケットのための一意の識別子(UID)を含むトレースパケットを生成することができる。ネットワークコントローラ102は,(例えば,既存の経路108に関連する他のトラフィックをネットワークコントローラ102に反映することとは対照的に)効率的且つ適切な分析のために,一意に識別できるようにトレースパケットを暗号化して,UIDを生成することができる。トレースパケットを暗号化することは,トレースパケットを符号化形式に変換することを含むことができる(例えば,ハッシングアルゴリズムなどのアルゴリズムの動作により,トレースパケットを入力としてアルゴリズムを動作させることより,UIDを生成する。)。UIDは,ネットワークコントローラ102に登録することができる。ネットワークコントローラ102上のUIDの登録,および/又は,観測点107に到達する可能性のあるトレースパケットのUIDを埋め込むことは,観測点107および/又はネットワークコントローラ102によるトレースパケットの一意の識別を容易にする。観測点107は,以下でより詳細に説明される。UIDを登録することにより,ネットワークコントローラ102は,受信したパケットを暗号化してUIDを生成し,それを登録されたUIDと比較し,UIDの一致に応答して,受信したパケットを一致したトレースパケットと認識する。いくつかの例では,UIDをトレースパケットに追加することができる(例えば,トレースパケットの生成中および暗号化中に)。トレースパケットは,ネットワークレイヤ内のプロトコル,または開放型システム間相互接続(OSI)モデル内のプロトコルなど,何らかの形式でデータペイロードを搬送するプロトコルに対して生成することができる。そのようなプロトコルの例は,伝送制御プロトコル(TCP),ユーザデータグラムプロトコル(UDP),ダイナミックホストコンフィギュレーションプロトコル(DHCP)およびICMPなどを含むことができる。
[0018] ネットワークコントローラ102は,観測点107(例えば,ネットワークデバイス106-1)を割り当てるために使用される。観測点107は,プログラムされた経路108上の任意のネットワークデバイス106に割り当てる。ネットワークコントローラ102は,トレースパケットによって指定されたマッチング基準を含む任意のパケットを,経路解析のために,ネットワークコントローラ102に送信するように観測点107に指示する。観測点107が割り当てられると,プログラムされた経路108をテストするために,UIDを有するトレースパケットを生成する。観測点107が指定された一致基準を有するパケットを受信すると,パケットのコピーをネットワークコントローラ102に送信する。ネットワークコントローラ102は,パケット及び/又はUIDの指紋(例えば,通過したネットワークデバイス106のアドレス及び/もしくはポートを含む,パケットの経路履歴)を得るために,パケットを復号する。トレースパケットの受信した指紋がマッチング基準と一致する(例えば,プログラムされた経路と一致する)ことに応答して,ネットワークコントローラ102は,観測点107からのトレースパケットを受信したという記録(例えば,メモリ構造)を更新する。ネットワークコントローラ102は,観測点107のトレースパケットを受信したことに応じて,観測点107に成功のステータスを設定する。ネットワーク管理者は,ネットワークコントローラ102を使用して,観測点107がトレースパケットを受信したどうかを問い合わせることができる。ステータスが成功に設定されていれば,観測点107として割り当てられたネットワークデバイス106に関してプログラムされた経路が正しいことを意味する。ステータスが成功に設定されていない場合,トレースパケットがドロップされているか,観測点で未だ受信されていないことを意味する。
[0019] ネットワーク管理者は,ネットワークコントローラ102を使用して,トレースパケットのプログラムされた経路108に沿って(例えば,以前の観測点に設定された成功状態に応じて),別のネットワークデバイス(例えば,ネットワークデバイス106-2)を観測点107として再割り当てを行う。観測点107を変更することは,プログラムされた経路108に沿って,障害発生箇所の判断を容易にすることができる。
[0020] 図2は,本開示におけるネットワーク200の一例を示す図である。ネットワーク200は,図1に示したネットワーク100に類似する。ネットワーク200はSDNであり,SDNコントローラ202を含む。ネットワーク200は,コンピューティングデバイス204-1,204-2(本明細書では,一般にコンピューティングデバイス204と呼ぶ。)と,いくつかのネットワークデバイス206-1,206-2,206-3(本明細書では,一般にネットワークデバイス206と呼ぶ。)を含んでいる。第1のコンピューティングデバイス204-1は,第1のネットワークデバイス206-1,第2のネットワークデバイス206-2および第3のネットワークデバイス206-3を介し,いくつかの物理的リンクを通じて,第2のコンピューティングデバイス204-2に接続する。図2に示す例では,物理リンク210(例えば,予測経路)は,プログラムされた経路208(例えば,既存の経路)と同じである。図2はまた,本明細書に記載されているように,いくつかの経路挿入及び分析動作214を含む(例えば,ネットワーク200には,コントロールプレーンが実装される)。
[0021] 図2は,各ネットワークデバイスの経路テーブルを含む(例えば,ネットワークデバイス206-2のための経路テーブル215)。経路テーブルは,既存の経路(例えば,経路テーブル215に定義されている既存の経路225)に対する経路ルールを含んでいる。一例として,ネットワークコントローラ202は,第1のコンピューティングデバイス204-1と第2のコンピューティングデバイス204-2との間のプログラム経路208を試験するために,第2のネットワークデバイス206-2に観測点を割り当てることができる。いくつかの例では,ネットワーク管理者は,ネットワークコントローラ202を介して観測点を割り当てることができる。ネットワークコントローラ202は,トレースパケット213を生成し,トレースパケット213を登録し(本明細書で使用されるように,トレースパケットを登録することは,トレースパケットを登録すること自体,トレースパケットの指紋を登録する,及び/又は,トレースパケットのUIDを登録することを含む。),既存の経路225にソースアドレス216-2,宛先アドレス218-2,トレースパケット213のプロトコルで送信することができる。いくつかの例において,ネットワーク管理者は,ネットワークコントローラ202を介して,トレースパケットを定義することができる。図示のように,第2のネットワークデバイス206-2に定義されている既存の経路225は,トレースパケット213のソースアドレス216-2と宛先アドレス218-2と一致するソースアドレス216-1と宛先アドレス218-1を含む。いくつかの例において,トレースパケット213の特定のネットワークデバイスの入力ポート220-2は,既存の経路225の入力ポート220-1と対応する。したがって,経路ルール226は,第2のネットワークデバイス206-2上の既存の経路225に加えることができ,ここで,経路ルール226がトレースパケット213のソースアドレス216-2,宛先アドレス218-2,着信ポート220-2,優先度222-2,出力ポート/動作224-2を含む。
[0022] 経路ルール226は,第2のネットワークデバイス206-2に,トレースパケット213に対応する既存の経路225の優先度222-1(例えば,1000)よりも高い優先度(例えば,1001)を有するトレースパケット213を追加することができる。トレースパケット213のためのより優先度の高い経路ルール226は,第2のネットワークデバイス206-2の既存の経路ルール226に対して,既存の経路のための定義された動作を行う前もしくは代わりに,定義された動作224-2を起こさせることができる。図2に示された例は,これを意味し,対応するパケット(トレースパケット213)は,「コントローラポート」から送信される(例えば,ネットワークコントローラ202に送信される)。
[0023] 図2の経路ルール226には具体的に示されていないが,経路ルール226は,トレースパケットからなるトラフィックの1つのクラスのみをネットワークコントローラ202に送信するために経路テーブルの機能に基づいて,具体的な経路を指定することができる(例えば,コントローラ202に送信されるトラフィックをの量を減らすため。)。
[0024] 図2の経路ルール226には具体的に示されていないが,経路ルール226はまた,トレースパケット213のためのプロトコルを指定することができる。これにより,トレースパケット213は,アプリケーション固有とすることができる。プロトコルを指定することは,第2のネットワークデバイス206-2が,ソースアドレス216-2及び宛先アドレス218-2に一致したパケット(例えば,そのプロトコルの経路が適切に機能しているためにエラーを経験していない経路と関連している他のトラフィック)を送信することを防ぐ。
[0025] ネットワークコントローラ202は,既存の経路のプログラムされた経路208に沿って,ネットワークデバイスの指定されたポート(例えば,ネットワークデバイス206-1のポート2)を介して既存の経路のソース(例えば,コンピュータティングデバイス204-1)の代わりに,トレースパケット13をネットワーク200に注入することができる。
[0026] トレースパケット213が注入された,プログラムされた経路208は,第1のネットワークデバイス206-1に正しくプログラムされている場合,第1のネットワークデバイス206-1はトレースパケット213を第2のネットワークデバイス206-2に正しく転送しなければならない(例えば,第1のネットワークデバイス206-1のポート3から出て,第2のネットワークデバイス206-2のポート4に入る。)。第2のネットワークデバイス206-2には,経路ルール226により観測点が割り当てられているので,第2のネットワークデバイス206-2はトレースパケット213をネットワークコントローラ202に送る。いくつかの例において,トレースパケット213が受信されたという理由だけで,ネットワークコントローラ202は,第2のネットワークデバイス206-2(観測点)について成功のステータスを設定する。いくつかの例において,ネットワークコントローラ202は,第2のネットワークデバイス206-2から受信したトレースパケットの指紋を最初に調べ,それをプログラムされた経路208に基づいてトレースパケット213の予想一致基準と比較することができる。この例では,指紋及び/又は一致基準が以下の1つまたは複数の情報を含むことができる。:コンピューティングデバイス204-1のソースアドレス(00:1E:08:AE:D3:BE),コンピューティングデバイス204-1の出力ポート(1),第1のネットワークデバイス206-1の入力ポート(2),第1のネットワークデバイス206-1の出力ポート(3),第2のネットワークデバイス206-2の入力ポート(4),そして/もしくは,第2のコンピューティングデバイス204-2の宛先アドレス(00:0c:29:03:7f:48)。第2のネットワークデバイス206-2から受信したトレースパケットの指紋がトレースパケット213の予想一致基準と一致する場合,ネットワークコントローラ202は第2のネットワークデバイス206-2に成功のステータスを設定する。
[0027] ネットワークコントローラ202が第2のネットワークデバイス206-2の成功のステータスに設定した後,ネットワーク管理者は(例えば,ネットワークコントローラ202を介して),第2のネットワークデバイス206-2のステータスを問い合わせることができる。ステータスが成功に設定されている場合,ネットワーク管理者はプログラムされた経路208のテストの継続を行いたい場合がある。ネットワークコントローラ202は,定義されたネットワークデバイスを介して(例えば,第2のネットワークデバイス206-2を介して),トレースパケットをネットワーク200に戻し,異なる観測点(例えば,既存の経路において,前の観測点の下流に存在する異なるネットワークデバイス)に,UIDを含むパケットをネットワークコントローラ202に送信することを指示する。このテストプロセスは,テストパケット213がネットワークコントローラ202に戻されなくなるまで続けることができ,これは,テストパケット213がネットワークコントローラ202に戻されないときに,割り当てられた観測点が故障となっているこを示す。)

上記記載から,引用文献1には,以下の発明(以下,「引用発明」という。)が記載されていると認められる。

「ネットワークコントローラを使用して,既存の経路のソースアドレスと一致するソースアドレスと,既存の経路の宛先アドレスに一致する宛先アドレスと,トレースパケットのための一意の識別子(UID)を含むトレースパケットを生成し,
ネットワークコントローラは,既存の経路のプログラムされた経路に沿って,第1のネットワークデバイスの指定されたポートを介して既存の経路のソースの代わりに,トレースパケットをネットワークに注入し,
プログラムされた経路は,第1のネットワークデバイスに正しくプログラムされている場合,第1のネットワークデバイスはトレースパケットを第2のネットワークデバイスに正しく転送し,
経路ルールにより観測点が割り当てられている第2のネットワークデバイスは,トレースパケットをネットワークコントローラに送り,
ネットワークコントローラは,第2のネットワークデバイスから受信したトレースパケットの,第1のコンピューティングデバイスのソースアドレス,第1のコンピューティングデバイスの出力ポート,第1のネットワークデバイスの入力ポート,第1のネットワークデバイスの出力ポート,第2のネットワークデバイスの入力ポート,そして/もしくは,第2のコンピューティングデバイスの宛先アドレスからなる指紋を最初に調べ,予想一致基準と一致する場合,第2のネットワークデバイスに成功のステータスに設定し,
ネットワークコントローラが第2のネットワークデバイスに成功のステータスに設定した後,ネットワーク管理者はネットワークコントローラを介して第2のネットワークデバイスのステータスを問い合わせることができ,
ステータスが成功に設定され,プログラムされた経路のテストの継続を行いたい場合,ネットワークコントローラは,第2のネットワークデバイスを介して,トレースパケットをネットワークに戻すとともに,既存の経路において,前の観測点の下流に存在する異なるネットワークデバイスに,UIDを含むパケットをネットワークコントローラに送信することを指示する,
コントロールプレーンが実装されたネットワークの方法。」

2 引用文献2について
原査定の拒絶の理由された引用文献2には,図面とともに次の事項が記載されている。

「An illustrative example of INT is described here. Source vSwitch (vSwitch 1)embeds instructions for each network element to report the latency that the packet encounters at the network element (delta between local egress timestamp and local ingress timestamp).
The receiving vSwitch(vSwitch2) can computer the end-to-end latency as a sum of the per-hop latencies (Under the assumption that switching and queueing latencies dominate and propagation delays are minimal, which is typically true in today's networks).Per-hop latencies in the packet received at the destination vSwitch can also be used to determine which network element(s) contributed most to the end-to-end latency.」
(当審訳:INTの実施例をここで説明する。ソースｖSｗiｔch(ｖSｗiｔch1)は,パケットがネットワーク要素で遭遇する遅延(ローカル出力タイムスタンプとローカル入力タイムスタンプとの間の差)を報告するために,各ネットワーク要素に対する命令を埋め込む。受信側のｖSｗiｔch(ｖSｗiｔch2)は,ホップ毎の遅延の合計としてエンドツーエンドの遅延を計算できる(今日のネットワークは,スイッチング及びキューイングの遅延が支配的であり,伝搬遅延は最小であるとしている)。宛先ｖSｗiｔchで受信されたパケットのホップ毎の遅延も,どのネットワーク要素がエンドツーエンドの待ち時間に最も寄与したかを判断するために使用する。)

上記記載から,引用文献2には,以下の事項(以下,「引用文献2記載事項」という。)

「受信側のｖSｗiｔch(ｖSｗiｔch2)は,ホップ毎の遅延の合計としてエンドツーエンドの遅延を計算でき,また,宛先ｖSｗiｔchで受信されたパケットのホップ毎の遅延も,どのネットワーク要素がエンドツーエンドの待ち時間に最も寄与したかを判断するために使用すること。」

3 引用文献3について
本願の優先権主張日前に頒布された又は電気通信回線を通じて公衆に利用可能となった刊行物である,Kanak Agaｒｗl 他3名,SDN ｔｒaceｒｏｕｔe: Tｒacing SDN Fｏｒｗaｒding ｗiｔhｏｕｔ Changing Neｔｗｏｒk Behaｖiｏｒ,ACM SIGCOMM’14,2014年8月22日,P.145-150(以下,「引用文献3」という。)には,図面とともに以下の事項が記載されている。

「3.4 Conducting the Trace Route
Once the network is configured in the manner discussed above, it is ready to accept Ethernet probe frames for route tracing. The process is best explained via an example, shown in Figure 2.
SDN traceroute begins by identifying the injection point. This is either identified in the API call or it is assumed to be the attachment point of the source host, which is looked up by source MAC or IP address. Once SDN traceroute has the injection switch identifier and port, it looks up the color of the ingress switch and inserts the color into the header tag bits of the probe frame.
SDN traceroute then sends the probe to the ingress switch as a PACKET_OUT message with the input port set to the injection point. The action for the PACKET_OUT is set to TABLE, indicating that the switch should treat the packet as though it had been received on the input port (step 1).
On receiving the PACKET_OUT, the ingress switch processes the packet in its flow table. Since the header tag bits in the packet are set to the color of the switch itself, the packet does not encounter a match on any of the high-priority rules SDN traceroute has installed. Consequently, the packet is forwarded to the next hop as though it were a regular, default-tagged packet (step 2). This ensures that the actual forwarding rules in the switch are used to route the packet even though it is a probe and not production traffic.
The packet arrives at the second switch while still carrying the header tag bits set to the color of the first switch. Since each switch is configured with high-priority rules that trap all packets matching the neighboring switches' colors, the packet at the second switch results in a match and is sent to the controller as a PACKET_IN (step 3). SDN traceroute receives the packet at the controller and logs the switch-id and port information of the switch that forwarded the packet to the controller as the next hop in the path.
Once SDN traceroute records the current hop, it modifies the received probe frame by rewriting the reserved tag field to the bits corresponding to the color of the current switch. It then sends the modified probe back as a PACKET_ OUT to the same switch that had sent the PACKET_IN message. The input port in the PACKET_OUT is set to the input port where the packet was received at the switch. The action field is once again set to TABLE (step 4). The switch receives the modified probe from the controller and applies its flow-table action on the probe. Since the reserved tag bits in the modified probe are set to the color of the switch, the tag based rules do not match and the packet is forwarded along the next hop as a regular frame (step 5).
This process (steps 3-5)repeats for each hop in the path. The process terminates when a time-out occurs between consecutive PACKET_IN events, indicating that the packet has left the network or been consumed by a host, or when a given is repeated in the route, indicating the presence of a loop.
Lastly, notice that in step 3 the trace route application only handles probe PACKET_IN messages that do not match the color of the switch sending the PACKET_IN.This allows PACKET_IN messages matching the input switch color to be forwarded to other modules in the controller for processing. This allows for scenarios where regular packet processing at a switch may itself initiate a PACKET_IN to the controller, such as in reactive rule installation.」
(当審訳:3.4 トレースルートの実行
ネットワークが上述のように構成されると,ルートトレース用のイーサネットプローブフレームを受け入れる準備が整う。このプロセスは,図2に示す例によって最もよく説明される。
SDN traceruteは,注入ポイントを特定することから開始される。これはAPI呼び出しで識別されるか,又は送信元MACまたはIPアドレスによって検索される送信元ホストの接続点にあるとみなされる。SDN traceruteは,注入スイッチ識別子とポートを取得すると,入力スイッチのカラーを調べ,そのカラーをプローブフレームのヘッダータグビットに挿入する。
SDN traceruteは,入力ポートを注入ポイントに設定し,PACKET_OUTをメッセージとしてプローブを入力スイッチに送信する。PACKET_OUTの動作は,TABLEに設定され,スイッチがあたかも入力ポートで受信したかのように扱う必要があることを示す(step1)。
PACKET_OUTを受信すると,入力スイッチはその経路テーブル内のパケットを処理する。パケット内のヘッダータグビットは,スイッチ自体のカラーに設定されているので,パケットはSDN traceruteがインストールした優先順位の高いルールのいずれにも一致しない。その結果,パケットは,通常のデフォルトタグ付きパケットであるかのように,次のホップに転送される(step2)。これにより,本当のトラフィックでないプローブであっても,スイッチ内の実際の転送ルールがパケットのルーティングに使用される。
パケットは,2番目のスイッチに到着する一方で,第1のスイッチのカラーに設定されたヘッダータグビットを依然として保持する。各スイッチは,隣接するスイッチのカラーと一致する全てのパケットをトラップする優先度の高いルールが設定されているため,2番目のスイッチのパケットは一致し,PACKET_INとしてコントローラに送信する(step3)。SDN traceruteは,コントローラでパケットを受信し,経路内の次のホップとしてパケットをコントローラに転送したスイッチの,スイッチIDとポート情報を記録する。
SDN traceruteは,現在のホップを記録すると,予約タグフィールドを現在のスイッチのカラーに対応するビットに書き換えることで,受信したプローブフレームを修正する。次に,PACKET_INメッセージを送った同じスイッチに,PACKET_OUTとして,修正されたプローブを戻す。PACKET_OUTの入力ポートは,パケットがスイッチで受信した入力ポートに設定される。アクションフィールドは,再びTABLEに設定される(step4)。スイッチは,コントローラにより修正されたプローブを受信し,その経路テーブルの動作をプローブに適用する。修正されたプローブの予約済みタグビットは,スイッチのカラーに設定されているため,タグベースのルールは一致せず,パケットは次のホップに沿って,通常のフレームとして転送される(step5)。
このプロセス(step3?5)は,経路内の各ホップに対して繰り返される。連続するPACKET_INイベントの間に,パケットがネットワークを離れたか,ホストによって消費された,あるいは,経路内で所定の が反復されるループの存在を示す,タイムアウトが発生しとき,プロセスは終了する。
最後に,step3で,トレースルートアプリケーションは,PACKET_INを送信するスイッチのカラーと一致しないプローブPACKET_INメッセージのみを処理することに注意されたい。これにより,入力スイッチのカラーと一致するPACKET_INメッセージをコントローラ内のモジュールに転送して処理させることができる。これにより,リアクティブルールのインストールなど,スイッチでの通常のパケット処理自体がコントローラに対してPACKET_INを開始する可能性があるシナリオが可能となる。)

4 引用文献4について
本願の優先権主張日前に頒布された又は電気通信回線を通じて公衆に利用可能となった刊行物である,特開2006-319973号公報(以下,「引用文献4」という。)には,図面とともに以下の事項が記載されている。

「【技術分野】
【0001】
本発明は、プロトコル汎用のネットワーク傍受に関する。」

「【課題を解決するための手段】
【0008】
本発明の実施形態は、通信網上で通信されるトラフィックをモニタリングし、該トラフィック内で、傍受装置が目的とするパケットを識別することができる、プロトコル汎用(すなわち「プロトコルを意識しない」)の傍受装置を提供する。さらに、本明細書に説明するように、パケット識別およびパケット認証を可能にする手法も提供される。さらに、本明細書に説明するように、所定の実施形態では、このような「パケット認証」は、パケット全体を認証するのではなく、傍受装置のためのIDおよび内容(コンテンツ)だけを認証する。こうして、傍受装置は、目的とする(of interest)パケットを識別して、識別情報および該傍受装置が目的とする情報を認証することができる。本発明の実施形態は、プロトコル汎用であり、傍受装置が目的とするパケットを識別して認証するために、傍受装置は、使用されている通信プロトコルに関して事前の知識を有する必要がない。したがって、傍受装置を変更することなく、プロトコル汎用の該傍受装置を使用して、該傍受装置を、通信網上で使用されている任意の通信プロトコルに対して動的に適応させることができる。
【0009】
さらに詳述するように、パケットを、傍受装置が目的とするパケットとして識別するために、プロトコルに固有の方式でパケット内に情報(たとえばパケットのヘッダ)を含めるのではなく、本発明の実施形態は、プロトコル汎用の方式で、識別子を含める。たとえば、識別子は、パケットのペイロード(payload)に含めることができる。一部の実施形態では、傍受装置は、捕捉したパケットのペイロードを識別子に関してスキャンし、該識別子を認識する際に、該パケットを認証するための技術を使用することができる。
【0010】
一実施形態では、本方法は、通信網上で通信されたパケットを傍受装置が捕捉することを含む。傍受装置は、パケットのペイロードをスキャンし、傍受装置が目的とする内容をパケットが含むことを識別する識別子を、該パケットのペイロードが含むかどうかを判断する。少なくとも一部の手法では、パケットのペイロードがこのような識別子を含むとの判断に基づいて、傍受装置は、該パケットのペイロード内に含まれる内容を使用する。
【0011】
一実施形態では、本方法は、傍受装置のための内容(コンテンツ)を含むパケットを形成することを含む。ここで、パケットは、ヘッダ部分およびペイロード部分を含む。ペイロード部分は、a)傍受装置のための内容(コンテンツ)をパケットが含むことを識別する所定の識別子と、b)該傍受装置のための該内容と、c)該所定の識別子および該傍受装置のための該内容を認証する認証トークンと、を含む。本方法はさらに、通信網を介してパケットを宛先に転送することを含む。一部の実施形態では、パケットを転送する宛先は、傍受装置以外の宛先である。ここで、傍受装置は、このパケットを傍受し、このパケットが該傍受装置のための内容を含むことを認識する。
【0012】
上記は、次の本発明の詳細な説明をよりよく理解するために、本発明の特徴の概要を示したものである。次に、本発明の請求項の主題を形成する、本発明の別の特徴および利点を記述する。開示された概念および特定の実施形態は、本発明と同じ目的を実行するように他の構成を修正または設計する基礎としても容易に使用できることが理解されるであろう。また、このような等価の構成も、請求項に示す本発明から離れるものではないことを理解されたい。本発明の構成と方法の両方について、本発明に特徴的と考えられる新規な特徴、および、別の目的と利点は、図面と共に次の説明を読めばよりよく理解されるであろう。各図は図示と説明のために提供されたものに過ぎず、本発明の限定を定義することを目的としているわけではなことを理解されたい。」

第6 対比・判断
1 本願発明1について
(1)対比
本願発明1と引用発明とを対比すると,次のことがいえる。
ア 引用発明の方法は,「ネットワーク管理者はネットワークコントローラを介して第2のネットワークデバイスのステータスを問い合わせることができ,」又,「ステータスが成功に設定され,プログラムされた経路のテストの継続を行いたい場合,ネットワークコントローラは,第2のネットワークデバイスを介して,トレースパケットをネットワークに戻すとともに,既存の経路において,前の観測点の下流に存在する異なるネットワークデバイスに,UIDを含むパケットをネットワークコントローラに送信することを指示」しているから,このことは,ネットワークコントローラを介した問い合せ等に答えるツールであるといえる。
そうすると,引用発明のツールは,本願発明1の「ネットワーク管理者によるネットワークの管理ツール」に相当する。

イ また,引用発明は,上記アで検討したように,ネットワークコントローラを介した問合せ等に答えるツールであって,ネットワーク管理者のネットワークの経路に関する問い合せに対して回答を行っており,この回答のために,何らかの演算を行っていることは明らかであり,さらに,対象とするネットワークはコントロールプレーンが実装されたものである。
してみると,引用発明と,本願発明1の「集中式コントロールプレーンに基づくパス状態の報告演算方法」は,「コントロールプレーンに基づくパス状態の報告演算方法」である点で共通する。

ウ 引用発明の「ネットワークコントローラを使用して,既存の経路のソースアドレスと一致するソースアドレスと,既存の経路の宛先アドレスに一致する宛先アドレスと,トレースパケットのための一意の識別子(UID)を含むトレースパケットを生成」することは,本願発明1の「生成段階として、テストを行いたいデータフロー情報に従い実際のパケットをシミュレーションしたテストパケットを生成」することに相当する。

エ 引用発明の「ネットワークコントローラは,既存の経路のプログラムされた経路に沿って,第1のネットワークデバイスの指定されたポートを介して既存の経路のソースの代わりに,トレースパケットをネットワークに注入」することは,本願発明1の「テスト段階として、テストパケットをテストを行いたいパスが通過する交換機に送信」することに相当し,また,上記アで検討したように,引用発明は,トレースパケットの経路の状態をネットワークデバイスのステータスで管理しているから,本願発明1の「パステスト」に相当するテストを行っていると認められる。
さらに,該「ネットワークコントローラは,既存の経路のプログラムされた経路に沿って,第1のネットワークデバイスの指定されたポートを介して既存の経路のソースの代わりに,トレースパケットをネットワークに注入」することは,本願発明1の「テスト段階が、テストパケットをテストを行いたいパス始点に位置する交換機に送信」することに相当する。

オ また,上記アで検討したように,引用発明は,トレースパケットの経路の状態をネットワークデバイスのステータスで管理しており,このステータスをネットワーク管理者はネットワークコントローラを介して問い合わせることができるから,この問合せに対する回答と,本願発明1の「報告段階として、データフローが通過する実際のパスとパス状態を報告する」こととは,「報告段階として、データフローが通過する実際のパスを報告する」点で共通する。

カ そうすると,本願発明1と引用発明とは以下の点で一致し,又,相違する。

[一致点]
「ネットワーク管理者のネットワーク管理ツールによって実行され,
生成段階として,テストを行いたいデータフロー情報に従い実際のパケットをシミュレーションしたテストパケットを生成し,
テスト段階として,テストパケットをテストを行いたいパスが通過する交換機に送信し,パステストを行い,
報告段階として,データフローが通過する実際のパスを報告する,ことを主に含み,
テスト段階が,テストパケットをテストを行いたいパス始点に位置する交換機に送信し,
コントロールプレーンに基づくパス状態の報告演算方法。」

[相違点1]
「報告段階」について,本願発明1の「報告段階として、データフローが通過する実際のパスとパス状態を報告」しているのに対して,引用発明は,データフローが通過するパス状態を報告していない点。

[相違点2]
「テスト段階」について,本願発明1は「テスト段階が、テストパケットをテストを行いたいパス始点に位置する交換機に送信し、交換機が直ちに行う報告、テストを行いたいパス終点に位置する交換機による報告済かの判断と時間制限に到達済かの判断を待機後に受信し、終点交換機による報告済かの判断が主に終点交換機による報告済か否かの判断であり、報告済ならば報告段階に入り、未報告ならば時間制限に到達済の判断に入る手順であり、時間制限に到達済かの判断の手順が主にテストの時間制限が到達済か否かの判断であり、到達済ならば報告段階に入り、未到達ならば交換機が直ちに報告するのを待機後に受信するに戻る手順を含」んでいるのに対して,引用発明は「テストパケットをテストを行いたいパス始点に位置する交換機に送信し」ているもの,「交換機が直ちに行う報告、テストを行いたいパス終点に位置する交換機による報告済かの判断と時間制限に到達済かの判断を待機後に受信し、終点交換機による報告済かの判断が主に終点交換機による報告済か否かの判断であり、報告済ならば報告段階に入り、未報告ならば時間制限に到達済の判断に入る手順であり、時間制限に到達済かの判断の手順が主にテストの時間制限が到達済か否かの判断であり、到達済ならば報告段階に入り、未到達ならば交換機が直ちに報告するのを待機後に受信するに戻る手順」は行っていない点。

[相違点3]
本願発明1は「実際のパケットをシミュレーションしたテストパケットを生成することについて、主にテストパケットのpayloadに専用のキーワードを記入することで、テストパケットが同じheaderを有する他のパケットと区別できるものである」のに対して,引用発明の「トレースパケットのための一意の識別子(UID)」がパットのどの部分に含まれているのか不明である点。

[相違点4]
「コントロールプレーン」について,本願発明1は「集中式コントロールプレーン」であるのに対して,引用発明の「コントロールプレーン」は「集中式」であるのか否か不明である点。

(2)相違点についての判断
以下,[相違点1]について検討する。
引用文献1には,本願発明1の「パス状態」に相当する状態を報告することについて記載も示唆もない。
また,引用文献1において「パス状態」を報告することが自明の事項であるともいえない。
さらに,引用文献2記載事項には,本願発明1の「パス状態」に相当する「ホップ毎の遅延」を報告することが記載されているが,引用発明は,

ア 「第1のネットワークデバイスはトレースパケットを第2のネットワークデバイスに正しく転送し」た後,

イ 「経路ルールにより観測点が割り当てられている第2のネットワークデバイスは,トレースパケットをネットワークコントローラに送り」,

ウ 「ネットワークコントローラは,第2のネットワークデバイスから受信したトレースパケットの,第1のコンピューティングデバイスのソースアドレス,第1のコンピューティングデバイスの出力ポート,第1のネットワークデバイスの入力ポート,第1のネットワークデバイスの出力ポート,第2のネットワークデバイスの入力ポート,そして/もしくは,第2のコンピューティングデバイスの宛先アドレスからなる指紋を最初に調べ,予想一致基準と一致する場合,第2のネットワークデバイスに成功のステータスに設定し」,

エ 「ネットワーク管理者」が「ネットワークコントローラを介して第2のネットワークデバイスのステータスを問い合わせ」た後,「ネットワーク管理者」が「プログラムされた経路のテストの継続を行いたい場合」に,「ネットワークコントローラは,第2のネットワークデバイスを介して,トレースパケットをネットワークに戻すとともに,既存の経路において,前の観測点の下流に存在する異なるネットワークデバイスに,UIDを含むパケットをネットワークコントローラに送信することを指示」しており,

第2のネットワークデバイスがトレースパケットを受け取ってから,トレースパケットをネットワークに戻す間に,ネットワークコントローラにトレースパケットを送り,ステータスの設定をした後に,ネットワークコントローラが第2のネットワークデバイスを介して,トレースパケットをネットワークに戻すことを行っている。
そうすると,引用発明では,上記引用文献2記載事項の「ホップ毎の遅延」を測ることができないから,引用発明に,引用発明2記載事項を採用することには,阻害要因があるといえる。
また,引用文献3及び4には,本願発明1の「パス状態」に相当する状態を報告することについて記載も示唆もない。
そうすると,他の相違点について検討するまでもなく,本願発明1は,引用発明及び引用文献2ないし4に記載された事項から,当業者が容易に発明できたものであるとはいえない。

2 本願発明2ないし6について
本願発明2ないし6も,本願発明1の「報告段階として、データフローが通過する実際のパスとパス状態を報告する」ことを行っているから,本願発明1と同じ理由により,本願発明2ないし6は,引用発明及び引用文献2ないし4に記載された事項から,当業者が容易に発明できたものであるとはいえない。

第7 原査定について
本願発明1ないし6は,「報告段階として、データフローが通過する実際のパスとパス状態を報告する」ことを行っているから,当業者であっても,拒絶査定において引用された引用文献1及び2に基づいて,容易に発明できたものとはいえない。したがって,原査定を維持することはできない。

第8 むすび
以上のとおり,原査定の理由によって,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2019-08-19 
出願番号 特願2016-206949(P2016-206949)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 速水 雄太、玉木 宏治、中川 幸洋  
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 小田 浩
梶尾 誠哉
発明の名称 集中式コントロールプレーンに基づくパス状態の報告演算方法  
代理人 村井 康司  
代理人 石川 貴之  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ