• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1363781
審判番号 不服2018-9966  
総通号数 248 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-08-28 
種別 拒絶査定不服の審決 
審判請求日 2018-07-20 
確定日 2020-07-21 
事件の表示 特願2016-518818「パケットを処理するための方法およびフォワーダ」拒絶査定不服審判事件〔平成26年12月18日国際公開、WO2014/198064、平成28年 8月12日国内公表、特表2016-524412、請求項の数(28)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2013年(平成25年)6月14日を国際出願日とする出願であって、平成28年4月5日に手続補正がなされ、平成29年3月30日付けで拒絶理由通知がされ、平成29年10月11日に意見書が提出されるとともに手続補正がされたが、平成30年3月14日付けで拒絶査定がなされ、これに対して、平成30年7月20日に拒絶査定不服審判の請求がされると同時に手続補正がされ、令和元年9月10日付けで拒絶理由通知(以下、「当審拒絶理由通知」という。)がされ、令和2年2月17日付けで意見書が提出されるとともに手続補正がされたものである。

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

本願請求項1-30に係る発明は、以下の引用文献A-Dに基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
A.前田繁章、“OpenFlow ver1.1およびver1.2の追加機能と活用例”、2012年2月23日、https://thinkit.co.jp/story/2012/02/23/3388
B.特表2013-519250号公報
C.国際公開第2011/043312号
D.国際公開第2012/049960号

第3 当審拒絶理由の概要
当審拒絶理由の概要は次のとおりである。

本願請求項1-28に係る発明は、以下の引用文献1に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.Open Networking Foundation、"OpenFlow Switch Specification Version 1.3.2"、2013年4月25日、p.1-131

第4 本願発明
本願請求項1-28に係る発明(以下、それぞれ「本願発明1」-「本願発明28」という。)は、令和2年2月17日付けの手続補正で補正された特許請求の範囲の請求項1-28に記載された事項により特定される発明であり、本願発明1は以下のとおりの発明である。

「【請求項1】
フォワーダにより実行される、ソフトウェア・デファインド・ネットワーク(Software Defined Network)においてパケットを処理するための方法であって、
入力パケットを受信するステップと、
前記入力パケットに従って、前記入力パケットが属するフローを決定するステップと、 フローとコンテキスト識別子セットとの間の第1の対応に従って、前記入力パケットが属するフローに対応するコンテキスト識別子セットを決定するステップであって、前記第1の対応における各フローに対応するコンテキスト識別子セットは少なくとも1つのコンテキスト識別子を含む、決定するステップと、
コンテキスト識別子とコンテキストとの間の第2の対応に従って、前記コンテキスト識別子セットに対応するコンテキストを決定するステップと、
前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップと
を含み、
当該方法はさらに、
コントローラにより送信されたフロー削除メッセージを受信するステップであって、前記フロー削除メッセージは削除対象のフローに関する情報を含む、受信するステップと、
前記削除対象のフローに関する情報および前記削除対象のフローに対応するコンテキスト識別子セットを前記第1の対応から削除するステップと、
を含み、
前記コンテキスト識別子セットが複数のコンテキスト識別子を含むときに、前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップは、予め設定されたコンテキストシーケンスで実行され、
当該方法はさらに、
前記コントローラに能力交渉リクエストメッセージを送信するステップであって、前記能力交渉リクエストメッセージは前記フォワーダによってサポートされるコンテキスト能力リストを含み、これにより、前記コントローラは前記フォワーダがサポート可能ないくつかの又は全てのコンテキストを前記フォワーダに送信する、送信するステップを含む方法。」

なお、本願発明2-28の概要は以下のとおりである。
本願発明2-16は、本願発明1を減縮した発明である。
本願発明17は、「フォワーダにより実行される、ソフトウェア・デファインド・ネットワーク(Software Defined Network)においてパケットを処理するための方法」の発明である本願発明1に対応する、「ソフトウェア・デファインド・ネットワーク(Software Defined Network)で使用されるフォワーダ」の発明である。
本願発明18-28は、本願発明17を減縮した発明である。

第5 引用文献1及び引用発明
1 引用文献1
当審拒絶理由に引用した引用文献1(Open Networking Foundation、"OpenFlow Switch Specification Version 1.3.2"、2013年4月25日、p.1-131)には、図面とともに、以下の記載がある(下線は、特に着目した箇所を示す。以下同様。)。

(1)「An OpenFlow Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and an OpenFlow channel to an external controller (Figure 1). The switch communicates with the controller and the controller manages the switch via the OpenFlow protocol.
Using the OpenFlow protocol, the controller can add, update, and delete flow entries in flow tables, both reactively (in response to packets) and proactively. Each flow table in the switch contains a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching packets (see 5.2).
・・・(中略)・・・
Instructions associated with each flow entry either contain actions or modify pipeline processing (see 5.9). Actions included in instructions describe packet forwarding, packet modification and group table processing.
・・・(中略)・・・
The group table contains group entries; each group entry contains a list of action buckets with specific semantics dependent on group type (see 5.6.1). The actions in one or more action buckets are applied to packets sent to the group.」(8-9ページ)

(当審訳:
OpenFlowスイッチは、1つ又はそれ以上のフローテーブルと、グループテーブル(パケットの参照と転送を実行する)と、外部コントローラへのOpenFlowチャネルから成る(図1)。スイッチはコントローラと通信し、コントローラはOpenFlowプロトコルを通じてスイッチを管理する。
OpenFlowプロトコルを使用することで、コントローラは、フローテーブル内のフローエントリを、リアクティブ(パケットに応答して)と、プロアクティブどちらでも、追加、更新、削除することができる。スイッチ内の各フローテーブルは、フローエントリのセットを含んでおり、各フローエントリは、マッチフィールド、カウンタ、及び、マッチしたパケットに適用されるインストラクションから成る(5.2参照)。
・・・(中略)・・・
各フローエントリに関連付けられたインストラクションは、アクションを含むか、パイプライン処理を修正する(5.9参照)。インストラクションに含まれるアクションは、パケットの転送、パケットの修正、及び、グループテーブルの処理を記述する。
・・・(中略)・・・
グループテーブルは、グループエントリを含んでおり、各グループエントリは、グループタイプに応じた特定のセマンティクスとともに、アクションバケットのリストを含む(5.6.1参照)。1つ又はそれ以上のアクションバケット内におけるアクションは、そのグループに送られたパケットに適用される。)

(2)「4.1 OpenFlow Ports
OpenFlow ports are the network interfaces for passing packets between OpenFlow processing and the rest of the network. OpenFlow switches connect logically to each other via their OpenFlow ports.」(10ページ)

(当審訳:
4.1 OpenFlowポート
OpenFlowポートは、OpenFlow処理とネットワークの残りの部分との間で、パケットを通過させるためのネットワークインタフェースである。OpenFlowスイッチは、それらのOpenFlowポートによって論理的に互いに接続している。)

(3)「5.2 Flow Table
A flow table consists of flow entries.
(Table 1:略)
Each flow table entry (see Table 1) contains:
・match fields: to match against packets. These consist of the ingress port and packet headers, and optionally metadata specified by a previous table.
・priority: matching precedence of the flow entry.
・counters: updated when packets are matched.
・instructions: to modify the action set or pipeline processing.
・timeouts: maximum amount of time or idle time before flow is expired by the switch.
・cookie: opaque data value chosen by the controller. May be used by the controller to filter flow statistics, flow modification and flow deletion. Not used when processing packets.」(14ページ)

(当審訳:
5.2 フローテーブル
フローテーブルは、フローエントリから成る。
(表1:略)
各フローテーブルエントリ(表1参照)は、以下を含む。
・マッチフィールド:パケットに対してマッチするため。これは、入力ポート、パケットヘッダ、及び、任意で、先行するテーブルで特定されたメタデータとから成る。
・優先度:フローエントリをマッチする順序。
・カウンタ:パケットがマッチしたときに更新される。
・インストラクション:アクションセット又はパイプライン処理を修正するため。
・タイムアウト:フローがスイッチによって満了されるまでの最大時間又はアイドル時間。
・クッキー:コントローラによって選択される不明瞭なデータ値。コントローラによって、フロー統計、フロー修正、フロー削除をフィルタするために用いられてよい。パケットを処理するときには用いられない。)

(4)「5.3 Matching
(Figure3:略)
On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3. The switch starts by performing a table lookup in the first flow table, and based on pipeline processing, may perform table lookups in other flow tables (see 5.1).
Packet match fields are extracted from the packet. Packet match fields used for table lookups depend on the packet type, and typically include various packet header fields, such as Ethernet source address or IPv4 destination address (see 7.2.3).」(15ページ)

(当審訳:
5.3 マッチング
(図3:略)
パケットを受信すると、OpenFlowスイッチは、図3で示された機能を実行する。スイッチは、最初のフローテーブルにおいてテーブル参照を実行することによって開始し、パイプライン処理に基づいて、他のフローテーブルにおいてテーブル参照を実行してもよい(5.1参照)。
パケットマッチフィールドは、パケットから抽出される。テーブル参照に使用されるパケットマッチフィールドは、パケットタイプに従い、典型的には、イーサネット送信元アドレスやIPv4宛先アドレスといった、様々なパケットヘッダフィールドを含む(7.2.3参照)。)

(5)「5.5 Flow Removal
Flow entries are removed from flow tables in two ways, either at the request of the controller or via the switch flow expiry mechanism.
・・・(中略)・・・
The controller may actively remove flow entries from flow tables by sending delete flow table modification messages (OFPFC_DELETE or OFPFC_DELETE_STRICT - see 6.4).」(16-17ページ)

(当審訳:
5.5 フロー削除
フローエントリは、コントローラからの要求、又は、スイッチのフロー期限切れ機構という2つの方法のいずれかによって、フローテーブルから削除される。
・・・(中略)・・・
コントローラは、deleteフローテーブル修正メッセージ(OFPFC_DELETE 又は OFPFC_DELETE_STRICT - 6.4参照)を送信することによって、フローテーブルからフローエントリをアクティブに削除してもよい。)

(6)「5.6 Group Table
A group table consists of group entries. The ability for a flow entry to point to a group enables OpenFlow to represent additional methods of forwarding (e.g. select and all).
(Table 2:略)

Each group entry (see Table 2) is identified by its group identifier and contains:
・group identifier: a 32 bit unsigned integer uniquely identifying the group
・group type: to determine group semantics (see Section 5.6.1)
・counters: updated when packets are processed by a group
・action buckets: an ordered list of action buckets, where each action bucket contains a set of actions to execute and associated parameters」(17ページ)

(当審訳:
5.6 グループテーブル
グループテーブルは、グループエントリから成る。フローエントリが、グループを指定可能であることによって、OpenFlowが追加の転送の方法(例えば、select又はall)を表すことを可能にする。
(表2:略)

各グループエントリ(表2参照)は、そのグループ識別子によって識別され、以下を含む。
・グループ識別子:グループを一意に識別する32ビットの符号なし整数。
・グループタイプ:グループのセマンティクスを決定するため(5.6.1参照)。
・カウンタ:パケットをグループが処理する際に更新される。
・アクションバケット:アクションバケットの順序付けられたリストであり、各アクションバケットは、実行されるアクションのセットと関連するパラメータを含む。)

(7)「5.6.1 Group Types
A switch is not required to support all group types, just those marked "Required" below. The controller can also query the switch about which of the "Optional" group types it supports.
・・・(中略)・・・
・Required: indirect: Execute the one defined bucket in this group. This group supports only a single bucket. Allows multiple flow entries or groups to point to a common group identifier, supporting faster, more efficient convergence (e.g. next hops for IP forwarding). This group type is effectively identical to an all group with one bucket.」(17-18ページ)

(当審訳:
5.6.1 グループタイプ
スイッチは、全てのグループタイプをサポートすることを要求されず、以下で「要求される(Required)」と記されたものだけでよい。コントローラは、どの「任意の(Optional)」グループタイプをサポートするかをスイッチに問うこともできる。
・・・(中略)・・・
・要求される(Required):indirect:このグループの中で1つの定義されたバケットを実行する。このグループはただ1つのバケットのみをサポートする。複数のフローエントリやグループが共通のグループ識別子を指し示すことを許可し、より速く効率的な一致(例えば、IP転送のためのネクストホップ)をサポートする。このグループタイプは、実質的に1つのバケットを持つallグループと同じである。)

(8)「5.9 Instructions
Each flow entry contains a set of instructions that are executed when a packet matches the entry. These instructions result in changes to the packet, action set and/or pipeline processing.
A switch is not required to support all instruction types, just those marked "Required Instruction" below. The controller can also query the switch about which of the "Optional Instruction" types it supports.
・・・(中略)・・・
・Optional Instruction: Apply-Actions action(s): Applies the specific action(s) immediately, without any change to the Action Set. This instruction may be used to modify the packet between two tables or to execute multiple actions of the same type. The actions are specified as an action list (see 5.11).」(21ページ)

(当審訳:
5.9 インストラクション
各フローエントリは、パケットがエントリにマッチしたときに実行されるインストラクションのセットを含む。これらのインストラクションは結果として、パケット、アクションセット、パイプライン処理に変化をもたらす。
スイッチは、全てのインストラクションタイプをサポートすることを要求されず、以下で"要求されるインストラクション"と記されたものだけでよい。コントローラは、どの「任意のインストラクション」タイプをサポートするかをスイッチに問うこともできる。
・・・(中略)・・・
・任意のインストラクション:Apply-Actions action(s):アクションセットの変更を伴うことなく、特定のアクションを即やかに適用する。このインストラクションは、2つのテーブル間でパケットを修正するために、又は、同じタイプの複数アクションを実行するために用いられてもよい。アクションは、アクションリストとして特定される(5.11参照)。)

(9)「5.10 Action Set
・・・(中略)・・・The actions in an action set are applied in the order specified below, regardless of the order that they were added to the set. If an acion set contaions a group action, the actions in the appropriate action bucket of the group are also applied in the order specified below. The switch may support arbitrary action execution order through the action list of the Apply-Actions instruction.
1. copy TTL inwards:...
2. pop:
・・・(中略)・・・
11. output:...」(21-22ページ)

(当審訳:
5.10 アクションセット
・・・(中略)・・・ アクションセット内のアクションは、セットに追加された順にかかわらず、以下に特定される順で適用される。アクションセットがGroupアクションを含む場合には、そのGroupの適切なアクションバケット内のアクションも、以下に特定される順で適用される。スイッチは、Apply-Actionsインストラクションのアクションリストを介して任意のアクションの実行順序をサポートしてもよい。
1.内側へのTTL値コピー:…、
2.pop処理:
・・・(中略)・・・、
11.出力:…)

(10)「5.11 Action List
The Apply-Actions instruction and the Packet-out message include an action list. The semantics of the action list is identical to the OpenFlow 1.0 specification. The actions of an action list are executed in the order specified by the list, and are applied immediately to the packet.」(22ページ)

(当審訳:
5.11 アクションリスト
Apply-ActionsインストラクションとPacket-outメッセージは、アクションリストを含む。アクションリストのセマンティクスは、OpenFlow 1.0 仕様と同じである。アクションリスト内の複数のアクションは、リストによって特定される順で実行され、即座にパケットに適用される。)

(11)「5.12 Actions
A switch is not required to support all action types, just those marked "Required Action" below. The controller can also query the switch about which of the "Optional Action" it supports.
・・・(中略)・・・
Required Action: Group. Process the packet through the specified group. The exact interpretation depends on group type.」(23ページ)

(当審訳:
5.12 アクション
スイッチは、全てのアクションタイプをサポートすることを要求されず、以下で「要求されるアクション」と記されたものだけでよい。コントローラは、どの「任意のアクション」をサポートするかをスイッチに問うこともできる。
・・・(中略)・・・
要求されるアクション:Group. 特定のグループを通じてパケットを処理する。正確な解釈は、グループタイプに従う。)

(12)「6.4 Flow Table Modification Massage
Flow table modification messages can have the following types:
enum ofp_flow_mod_command {
OFPFC_ADD = 0, /* New flow. */
OFPFC_MODIFY = 1, /* Modify all matching flows. */
OFPFC_MODIFY_STRICT = 2, /* Modify entry strictly matching wildcards and priority. */
OFPFC_DELETE = 3, /* Delete all matching flows. */
OFPFC_DELETE_STRICT = 4, /* Delete entry strictly matching wildcards and priority. */
};
・・・(中略)・・・
For delete requests (OFPFC_DELETE or OFPFC_DELETE_STRICT), if a matching entry exists in the table, it must be deleted, and if the entry has the OFPFF_SEND_FLOW_REM flag set, it should generate a flow removed message. For delete requests, if no flow entry currently residing in the requested table matches the request, no error is recorded, and no flow table modification occurs.」(34-35ページ)

(当審訳:
6.4 フローテーブル修正メッセージ
フローテーブル修正メッセージは、以下のタイプを持つ。
enum ofp_flow_mod_command {
OFPFC_ADD = 0, /* New flow. */
OFPFC_MODIFY = 1, /* Modify all matching flows. */
OFPFC_MODIFY_STRICT = 2, /* Modify entry strictly matching
wildcards and priority. */
OFPFC_DELETE = 3, /* Delete all matching flows. */
OFPFC_DELETE_STRICT = 4, /* Delete entry strictly matching
wildcards and priority. */
};
・・・(中略)・・・
削除要求(OFPFC_DELETE 又は OFPFC_DELETE_STRICT)に関しては、テーブル内にマッチするエントリが存在すると、そのエントリは削除されなければならない。もしエントリにOFPFF_SEND_FLOW_REMフラグがセットされていると、フロー削除完了メッセージを生成しなければならない。削除要求に関しては、もし要求されたテーブル内に現在存在するフローエントリが要求にマッチしないと、エラーは記録されず、フローテーブル修正は発生しない。)

(13)「7.2.5 Action Structure
・・・(中略)・・・
A Group action uses the following structure and fields:

/* Action structure for OFPAT_GROUP. */
struct ofp_action_group {
uint16_t type; /* OFPAT_GROUP. */
uint16_t len; /* Length is 8. */
uint32_t group_id; /* Group identifier. */
};
OFP_ASSERT(sizeof(struct ofp_action_group) == 8);

The group_id indicates the group used to process this packet. The set of buckets to apply depends on the group type.」(57-59ページ)

(当審訳:
7.2.5 アクション構造
・・・(中略)・・・
グループアクションは、以下の構造とフィールドを用いる。

/* Action structure for OFPAT_GROUP. */
struct ofp_action_group {
uint16_t type; /* OFPAT_GROUP. */
uint16_t len; /* Length is 8. */
uint32_t group_id; /* グループ識別子. */
};
OFP_ASSERT(sizeof(struct ofp_action_group) == 8);

group_idは、このパケットを処理するために用いられるグループを示す。適用するバケットのセットは、グループタイプに従う。)

(14)「7.3.4.1 Modify Flow Entry Message
Modifications to a flow table from the controller are done with the OFPT_FLOW_MOD message:

/* Flow setup and teardown (controller -> datapath). */
struct ofp_flow_mod {
・・・(中略)・・・
uint8_t command; /* One of OFPFC_*. */
・・・(中略)・・・
struct ofp_match match; /* Fields to match. Variable size. */
・・・(中略)・・・
};
OFP_ASSERT(sizeof(struct ofp_flow_mod) == 56);」(65-66ページ)

(当審訳:
7.3.4.1 フローエントリ修正メッセージ
コントローラからフローテーブルへの修正は、OFPT_FLOW_MODメッセージを用いて行われる。

/* Flow setup and teardown (controller -> datapath). */
struct ofp_flow_mod {
・・・(中略)・・・
uint8_t command; /* OFPFC_*の一つ */
・・・(中略)・・・
struct ofp_match match; /* マッチするためのフィールド。 可変サイズ。 */
・・・(中略)・・・
};
OFP_ASSERT(sizeof(struct ofp_flow_mod) == 56);)


2 引用発明
よって、上記各記載事項を関連図面に照らし、下線部に着目すれば、引用文献1には、次の発明(以下、「引用発明」という。)が開示されているといえる。

「OpenFlowスイッチは、1つ又はそれ以上のフローテーブルと、グループテーブル(パケットの参照と転送を実行する)から成り、
OpenFlowプロトコルを使用することで、コントローラは、フローテーブル内のフローエントリを、追加、更新、削除し、
OpenFlowスイッチは、それらのOpenFlowポートによって論理的に互いに接続し、
フローテーブルは、フローエントリから成り、
各フローテーブルエントリは、パケットに対してマッチするためのマッチフィールドとインストラクションを含み、
パケットを受信すると、OpenFlowスイッチは、最初のフローテーブルにおいてテーブル参照を実行することによって開始し、
パケットマッチフィールドは、パケットから抽出され、テーブル参照に使用されるパケットマッチフィールドは、パケットタイプに従い、
コントローラは、deleteフローテーブル修正メッセージ(OFPFC_DELETE 又は OFPFC_DELETE_STRICT)を送信することによって、フローテーブルからフローエントリを削除し、
グループテーブルは、グループエントリから成り、
各グループエントリは、そのグループ識別子によって識別され、グループ識別子とアクションバケットを含み、
各アクションバケットは、実行されるアクションのセットを含み、
スイッチは、indirectのグループタイプをサポートし、indirectのグループの中で1つの定義されたバケットを実行し、
各フローエントリは、パケットがエントリにマッチしたときに実行されるインストラクションのセットを含み、
Apply-Actionsインストラクションは、アクションリストを含み、アクションリスト内の複数のアクションは、リストによって特定される順で実行され、
スイッチは、Groupのアクションタイプをサポートし、Groupアクションは、特定のグループを通じてパケットを処理し、
削除要求(OFPFC_DELETE 又は OFPFC_DELETE_STRICT)に関しては、テーブル内にマッチするエントリが存在すると、そのエントリは削除され、
グループアクションは、グループ識別子を含み、
コントローラからフローテーブルへの修正に用いられるOFPT_FLOW_MODメッセージは、OFPFC_*の1つを示すコマンドと、マッチするためのフィールドを含む、
方法。」

第6 対比・判断
1 本願発明1について
(1)対比
本願発明1と、引用発明とを対比すると以下のことがいえる。

ア.引用発明の「OpenFlowスイッチ」は、「パケット」を「転送」するものであるから、本願発明の「フォワーダ」に相当する。

イ.引用発明の「OpenFlowスイッチ」同士は、「互いに接続」するものであるから、「ネットワーク」を構成するといえる。
また、引用発明の「OpenFlowスイッチ」で構成される「ネットワーク」が、スイッチ動作がソフトウェア的に設定可能な、いわゆる「ソフトウェア・デファインド・ネットワーク(Software Defined Network)」と呼べることは明らかである。

ウ.引用発明において、「パケット」を「転送」することは、本願発明の「パケットを処理」することに相当する。

以上のことから、引用発明は「フォワーダにより実行される、ソフトウェア・デファインド・ネットワーク(Software Defined Network)においてパケットを処理するための方法」であるといえる。

(2) 引用発明の「パケットを受信する」ことは、本願発明の「入力パケットを受信するステップ」に相当する。

(3) 引用発明の「フローエントリ」に含まれる「マッチフィールド」は、「パケットに対してマッチするため」のものであり、「テーブル参照」における参照用キーとなるものであるから、本願発明の「フロー」に相当する。したがって、引用発明において、「パケットを受信」し、「テーブル参照に使用されるパケットマッチフィールド」を「パケットから抽出」することは、本願発明の「前記入力パケットに従って、前記入力パケットが属するフローを決定するステップ」に相当する。

(4)ア.引用発明における「フローエントリ」は、「マッチフィールドとインストラクション」とを含むことから、「フローエントリ」を含む「フローテーブル」は、「マッチフィールドとインストラクション」を対応付けるものといえる。

イ.引用発明において、「Apply-Actionsインストラクションは、アクションリストを含」むこと、及び、「アクションリスト内」に「複数のアクション」が含まれることから、「Apply-Actionsインストラクション」は「複数のアクション」を含むものといえる。
さらに、「グループアクションは、グループ識別子を含」むことから、「Apply-Actionsインストラクション」が、「複数のアクション」として、特に、複数の「グループアクション」を含むとき、「Apply-Actionsインストラクション」は「複数のグループ識別子」を含むものといえる。

ウ.引用発明の「グループ識別子」は、「実行されるアクションのセットを含」む「アクションバケット」を、「グループテーブル」によって特定するものであるから、本願発明の「コンテキスト識別子」に相当し、「Apply-Actionsインストラクション」に含まれる「複数のグループ識別子」は、本願発明の「コンテキスト識別子セット」に相当する。

エ.引用発明において、「フローエントリ」が、「Apply-Actionsインストラクション」として「複数のグループ識別子」を含むとき、当該「フローエントリ」を含み、「マッチフィールド」と「Apply-Actionsインストラクション」とを対応付ける「フローテーブル」は、「マッチフィールド」と「複数のグループ識別子」とを対応付けるといえるから、本願発明の「フローとコンテキスト識別子セットとの間の第1の対応」に相当する。
また、当該「フローテーブル」に対して「テーブル参照を実行」することは、本願発明の「前記入力パケットが属するフローに対応するコンテキスト識別子セットを決定するステップ」に相当する。

オ.以上のことから、引用発明は「フローとコンテキスト識別子セットとの間の第1の対応に従って、前記入力パケットが属するフローに対応するコンテキスト識別子セットを決定するステップであって、前記第1の対応における各フローに対応するコンテキスト識別子セットは少なくとも1つのコンテキスト識別子を含む、決定するステップ」を含むといえる。

(5)ア.引用発明の「グループエントリ」は、「グループ識別子とアクションバケットを含」むこと、及び、「グループタイプ」が、特に、「indirect」であるとき、「グループの中で1つの定義されたバケットを実行」することから、「グループタイプ」が「indirect」であるとき、「グループエントリ」を含む「グループテーブル」は、「グループ識別子とアクションバケット」とを対応付けるものであるいえる。

イ.引用発明の「アクションバケット」は、「実行されるアクションのセットを含」むものであるから、本願発明の「コンテキスト」に相当する。

ウ.引用発明において、「グループタイプ」が「indirect」であるとき、「グループ識別子とアクションバケット」とを対応付ける「グループテーブル」は、本願発明の「コンテキスト識別子とコンテキストとの間の第2の対応」に相当する。

エ.引用発明において、「Apply-Actionsインストラクション」が「複数のグループ識別子」を含み、さらに、「グループタイプ」が「indirect」であるとき、「複数のグループ識別子」各々に対応付けられた「アクションバケット」を特定することは、本願発明の「前記コンテキスト識別子セットに対応するコンテキストを決定するステップ」に相当する。

オ.引用発明において、特定された「アクションバケット」に含まれる「アクションのセット」を実行することは、本願発明の「前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップ」に相当する。

カ.以上のことから、引用発明は、「コンテキスト識別子とコンテキストとの間の第2の対応に従って、前記コンテキスト識別子セットに対応するコンテキストを決定するステップ」、及び、「前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップ」を含むといえる。

(6) 引用発明の「OFPT_FLOW_MODメッセージ」は、「コントローラからフローテーブルへの修正に用いられる」ものであり、「OFPFC_*の1つを示すコマンド」として、特に、「フローテーブルからフローエントリを削除」するために「コントローラ」により送信される「OFPFC_DELETE 又は OFPFC_DELETE_STRICT」を含むとき、本願発明の「フロー削除メッセージ」に相当する。
そして、当該「OFPT_FLOW_MODメッセージ」に含まれる「マッチするためのフィールド」は、「マッチするエントリ」を削除するためのものであるから、本願発明の「削除対象のフローに関する情報」に相当する。
また、「コントローラ」により送信された「OFPT_FLOW_MODメッセージ」は、「フローテーブル」を保持する「OpenFlowスイッチ」が受信するものといえる。

以上のことから、引用発明は「コントローラにより送信されたフロー削除メッセージを受信するステップであって、前記フロー削除メッセージは削除対象のフローに関する情報を含む、受信するステップ」を含むといえる。

(7) 引用発明において、「Apply-Actionsインストラクション」が「複数のグループ識別子」を含むとき、「そのエントリを削除」することは、「そのエントリ」に含まれる「マッチフィールド」と、「Apply-Actionsインストラクション」に含まれる「複数のグループ識別子」を削除することであるといえるから、「Apply-Actionsインストラクション」が「複数のグループ識別子」を含むとき、「そのエントリを削除」することは、本願発明の「前記削除対象のフローに関する情報および前記削除対象のフローに対応するコンテキスト識別子セットを前記第1の対応から削除するステップ」に相当する。

(8) 上記「(4)イ.」記載のとおり、引用発明において、フローエントリの「Apply-Actionsインストラクション」が、「複数のアクション」として、特に、複数の「グループアクション」を含むとき、「Apply-Actionsインストラクション」は「複数のグループ識別子」を含むものといえる。
よって、上記の「Apply-Actionsインストラクション」が「複数のグループ識別子」を含む場合に、「Apply-Actionsインストラクションは、アクションリストを含み、アクションリスト内の複数のアクションは、リストによって特定される順で実行され」ることは、本願発明において、「前記コンテキスト識別子セットが複数のコンテキスト識別子を含むときに、前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップは、予め設定されたコンテキストシーケンスで実行される」ことと、「前記コンテキスト識別子セットが複数のコンテキスト識別子を含むときに、前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップは、実行される」点で共通するといえる。

(9) よって、本願発明1と引用発明との一致点及び相違点は次のとおりであるといえる。

[一致点]
「フォワーダにより実行される、ソフトウェア・デファインド・ネットワーク(Software Defined Network)においてパケットを処理するための方法であって、
入力パケットを受信するステップと、
前記入力パケットに従って、前記入力パケットが属するフローを決定するステップと、
フローとコンテキスト識別子セットとの間の第1の対応に従って、前記入力パケットが属するフローに対応するコンテキスト識別子セットを決定するステップであって、前記第1の対応における各フローに対応するコンテキスト識別子セットは少なくとも1つのコンテキスト識別子を含む、決定するステップと、
コンテキスト識別子とコンテキストとの間の第2の対応に従って、前記コンテキスト識別子セットに対応するコンテキストを決定するステップと、
前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップと
を含み、
当該方法はさらに、
コントローラにより送信されたフロー削除メッセージを受信するステップであって、前記フロー削除メッセージは削除対象のフローに関する情報を含む、受信するステップと、
前記削除対象のフローに関する情報および前記削除対象のフローに対応するコンテキスト識別子セットを前記第1の対応から削除するステップと、
を含み、
前記コンテキスト識別子セットが複数のコンテキスト識別子を含むときに、前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップは、実行される
方法。」

[相違点1]
「前記コンテキスト識別子セットに対応するコンテキストに従って、前記入力パケットを処理するステップ」について、本願発明1では、「予め設定されたコンテキストシーケンスで実行される」のに対し、引用発明では、「予め設定されたコンテキストシーケンスで実行される」ことが特定されていない点。

[相違点2]
本願発明1では、「当該方法はさらに、前記コントローラに能力交渉リクエストメッセージを送信するステップであって、前記能力交渉リクエストメッセージは前記フォワーダによってサポートされるコンテキスト能力リストを含み、これにより、前記コントローラは前記フォワーダがサポート可能ないくつかの又は全てのコンテキストを前記フォワーダに送信する、送信するステップを含む」のに対し、引用発明では、「フォワーダによってサポートされるコンテキスト能力リストを含」むような、「コントローラに能力交渉リクエストメッセージを送信するステップ」が特定されていない点。

(2) 当審の判断
事案に鑑みて、上記[相違点2]について先に検討する。

上記「(1)対比 (5)イ」記載のように、本願発明1の「コンテキスト」に対応する引用発明の構成要素は、「アクションバケット」である。

ここで、引用発明には、スイッチ(「フォワーダ」)によってサポートされるアクションバケット(「コンテキスト」)能力リストを含むような、「能力交渉リクエストメッセージ」を、スイッチ(「フォワーダ」)から「コントローラ」に向けて送信し、「前記コントローラは前記フォワーダがサポート可能ないくつかの又は全てのコンテキストを前記フォワーダに送信する」というステップは、記載も示唆もない。
また、引用文献1のOpenFlowプロトコル規格書における他の記載を参照しても、セクション6.1(25-27ページ)に、通常、コントローラとスイッチ間のメッセージのやり取りは、コントローラから開始して、スイッチはメッセージに応答すること(セクション6.1.1参照)、スイッチが開始できるメッセージは、「非対称な(Asynchronous)メッセージ」と呼ばれ、「パケット-イン」メッセージ、「フロー削除」メッセージ、「ポート状態」メッセージ、「エラー」メッセージという主要な4タイプがあること(セクション6.1.2参照)、スイッチとコントローラのいずれも開始できるメッセージは、「対称な(Synchronous)メッセージ」と呼ばれ、「ハロー」メッセージ、「エコー」メッセージ、「実験者の(Experimenter)」メッセージの3タイプがあること(セクション6.1.3参照)は記載があるものの、上記[相違点2]の構成に対応する、スイッチ(「フォワーダ」)によってサポートされるアクションバケット(「コンテキスト」)能力リストを含むような、「能力交渉リクエストメッセージ」を、スイッチ(「フォワーダ」)から「コントローラ」に向けて送信し、「前記コントローラは前記フォワーダがサポート可能ないくつかの又は全てのコンテキストを前記フォワーダに送信する」というステップは、上記引用文献1に記載されておらず、本願出願前において周知技術であるともいえない。
よって、上記[相違点2]に係る構成は、引用発明及び周知技術に基づいて容易に発明できたものであるとはいえない。
したがって、本願発明1は、上記[相違点1]について検討するまでもなく、当業者であっても引用発明及び周知技術に基づいて容易に発明できたものであるとはいえない。

2 本願発明2-28について
本願発明2-16は、本願発明1を減縮した発明であり、また、本願発明17は、本願発明1に対応する「フォワーダ」の発明であり、本願発明18-28は、本願発明17を減縮した発明であり、本願発明1の「当該方法はさらに、前記コントローラに能力交渉リクエストメッセージを送信するステップであって、前記能力交渉リクエストメッセージは前記フォワーダによってサポートされるコンテキスト能力リストを含み、これにより、前記コントローラは前記フォワーダがサポート可能ないくつかの又は全てのコンテキストを前記フォワーダに送信する、送信するステップを含む」構成と、実質的に同一の構成を備えるものであるから、本願発明2-28も、本願発明1と同様の理由により、当業者であっても、引用発明及び周知技術に基づいて容易に発明できたものであるとはいえない。

第7 原査定についての判断
令和2年2月17日付けの補正により補正された請求項1-28は、実質的に「当該方法はさらに、前記コントローラに能力交渉リクエストメッセージを送信するステップであって、前記能力交渉リクエストメッセージは前記フォワーダによってサポートされるコンテキスト能力リストを含み、これにより、前記コントローラは前記フォワーダがサポート可能ないくつかの又は全てのコンテキストを前記フォワーダに送信する、送信するステップを含む」という技術事項を有するものとなり、当該技術的事項は、原査定における引用文献A-引用文献Dには記載されておらず、本願出願前における周知技術でもないので、本願発明1-28は、原査定における引用文献A-D及び周知技術に基づいて容易に発明をすることができたものではない。
したがって、原査定を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2020-07-06 
出願番号 特願2016-518818(P2016-518818)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 速水 雄太西村 純宮田 繁仁  
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 野崎 大進
稲葉 和生
発明の名称 パケットを処理するための方法およびフォワーダ  
代理人 伊東 忠重  
代理人 伊東 忠彦  
代理人 大貫 進介  
  • この表をプリントする

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