• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 H04L
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
管理番号 1314257
審判番号 不服2015-15587  
総通号数 198 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-06-24 
種別 拒絶査定不服の審決 
審判請求日 2015-08-21 
確定日 2016-05-24 
事件の表示 特願2012-513343「レイヤー2ドメインにわたる負荷分散」拒絶査定不服審判事件〔平成22年12月 2日国際公開,WO2010/138936,平成24年11月12日国内公表,特表2012-528551,請求項の数(10)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1 手続の経緯
本願は,2010年5月28日(パリ条約による優先権主張外国庁受理 2009年5月28日 米国,2009年10月26日 米国)を国際出願日とする出願であって,平成26年8月28日付けで最後の拒絶理由が通知され,平成26年11月28日付けで手続補正がなされたが,平成27年4月10日付けで補正の却下の決定がされるとともに同日付けで拒絶査定がされ,これに対し,同年8月21日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。


第2 平成27年8月21日付けの手続補正(以下,「本件補正」という。)の適否
1 補正の内容
(補正事項1)
本件補正は,平成26年6月3日付け手続補正書により補正された特許請求の範囲の請求項1に記載された
「処理デバイスによって実行されると,該処理デバイスに負荷分散方法を実行させるプログラムであって,前記方法が,
一連のモジュール間にネットワークパケットを拡散するステップと,
前記一連のモジュールの個々のモジュールにおいて,受信した個々のネットワークパケットのソースアドレスと宛先アドレスとを保存するように,前記個々のネットワークパケットをカプセル化するステップと,
前記一連のモジュール間で共有されるハッシュを使用して,カプセル化されたパケットを提供するターゲットデバイスを選択するステップであって,前記カプセル化されたパケットは,前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットを含み,前記カプセル化されたパケットのソースアドレスは,前記個々のモジュールに関連し,前記カプセル化されたパケットの宛先アドレスは,前記ターゲットデバイスに関連する,ステップと,
前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップと
を含む,プログラム。」
という発明(以下,「補正前の発明」という。)を
「処理デバイスによって実行されると,該処理デバイスに負荷分散方法を実行させるプログラムであって,前記方法が,
一連のモジュール間にネットワークパケットを拡散するステップと,
前記一連のモジュールの個々のモジュールにおいて,受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップであって,前記一連のモジュールは同じハッシュ関数を使用するように構成され,前記個々のモジュールは,前記ハッシュ関数を使用して,ネットワークパケットを転送すべきターゲットデバイスを選択する,ステップと,
前記個々のモジュールにおいて,前記個々のネットワークパケットのソースアドレスと宛先アドレスとを保存するように,前記個々のネットワークパケットをカプセル化するステップであって,カプセル化されたパケットは,前記個々のモジュールに関連するソースアドレスと,前記ターゲットデバイスに関連する宛先アドレスとによって,前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットをカプセル化することによって生成される,ステップと,
前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップと
を含む,プログラム。」
という発明(以下,「補正後の発明」という。)に変更するものであり,また,独立請求項である本件補正前の請求項8,12(本件補正後の請求項7,9)についても同様に補正をするものである。
([当審注]:上記の下線部は補正箇所を示す)

(補正事項2)
本件補正前の請求項4の「前記ハッシュ」を「前記ハッシュ関数」(本件補正後の請求項4)とするものである。

(補正事項3)
本件補正前の請求項14の「前記個々のターゲットデバイス」を「前記ターゲットデバイス」(本件補正後の請求項10)とするものである。

(補正事項4)
本件補正前の請求項6,10,11,13,15を削除し,それに伴い請求項の項番を繰り上げるものである。

2 補正の適否
まず補正事項2?4について検討した後,補正事項1について検討する。

(補正事項2,4について)
補正事項2,4は,いずれも,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内において,引用する請求項に「前記」されたものと記載ぶりを統一するものであるから,誤記の訂正を目的とするものといえ,また,特許法第17条の2第4項に違反するところはない。

(補正事項3について)
補正事項3は請求項の削除を目的とするものであり,また,特許法第17条の2第4項に違反するところはない。

(補正事項1について)
補正事項1は,「選択するステップ」に記載されていた「カプセル化されたパケット」の内容を「カプセル化するステップ」にて記載するようにしたため,補正前後で表現ぶりは異なるものの,その技術的内容については,実質的に,補正前の発明のターゲットデバイスの選択に使用される「共有されるハッシュ」を「同じハッシュ関数」に限定するものである。そして,補正前の請求項1に記載された発明と補正後の請求項1に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから,補正事項1は,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。
また,特許法第17条の2第3項,第4項に違反するところはない。
そこで,補正後の発明が特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について以下に検討する。

(1)補正後の発明
本正後の発明は,上記「1 補正の内容(補正事項1)」の項の「補正後の発明」のとおりのものと認める。

(2)刊行物の記載事項
(引用発明)
原査定の拒絶の理由に引用された特開2005-25756号公報(以下,「引用例1」という。)には,「ホスト状態情報を用いるネットワーク負荷分散」として,図面とともに以下の事項が記載されている。

ア 「【0001】
この開示は,一般にネットワーク負荷分散(neｔｗｏｒk lｏad balancing)に関し,詳細には,制限ではなく例として,ホスト状態情報を用いるネットワーク負荷分散に関する。
(中略)
【0007】
負荷分散動作を実施するために,ハードウェアは,通常,到着する接続リクエストのラウンドロビン分散を実行する。言い換えると,到着する接続リクエストは,単一の接続リクエストを各サーバに分散する方法を繰り返して,一連のサーバの中のサーバに線形的に分散される。この接続のラウンドロビン負荷分散分配は,通常は,パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく利用される。負荷分散動作が,ラウンドロビン分散を超えて拡大される場合,これらの他の要因は,ネットワークトラフィックおよび/またはパーソナルネットワークの輻輳レベルから推論できる範囲で考慮されるに過ぎない。」(17?18ページ)

イ 「【0031】
図2は,複数の負荷分散ユニット106および複数のホスト108を示す例示的なネットワーク負荷分散パラダイム200を示す図である。具体的に言うと,負荷分散インフラストラクチャ106は,例示的なネットワーク負荷分散パラダイム200内では複数の負荷分散ユニット106(1),106(2)...106(ｕ)として図示されている。さらに,2つのルータおよび/またはスイッチ202(1)および202(2)が図示されている。
【0032】
ルータ/スイッチ202は,存在する場合に,負荷分散インフラストラクチャ106(図1の)の一部またはこれと分離していると考えることができる。ルータ/スイッチ202は,ネットワーク104から受信される全部のリクエストおよび個々のパケットを負荷分散ユニット106の共有仮想IP(VIP)アドレスに向ける責任を負う。第1のルータ/スイッチ202に障害が発生する場合に,第2のルータ/スイッチ202は,第1のルータ/スイッチの引継ぎをすることができる。2つのルータ/スイッチ202が示されているが,その代わりに1つまたは3つ以上のルータ/スイッチ202を使用することができる。
(中略)
【0034】
その一方で,ルータ/スイッチ202が,負荷分散対応である場合には,ルータ/スイッチ202を,入力ネットワークトラフィックを複数の負荷分散ユニット106の間で分配(たとえばラウンドロビン式で)するようにすることができる。そのような負荷分散対応ルータ/スイッチ202が,基本レベル(たとえばハードウェア)で負荷分散機能を実行できることを理解されたい。たとえば,負荷分散対応ルータ/スイッチ202によって,単純なIPアドレスベースのセッションアフィニティ(ｓeｓｓiｏn affiniｔｙ)を実行し,その結果,特定の発信元IPアドレスからのすべてのパケットを,同一の負荷分散ユニット106に向けることができるようになる。」(21ページ)

ウ 「【0037】
図3は,分離された機能を有する例示的な負荷分散ユニット106および例示的なホスト108を示す。負荷分散ユニット106は,7つの機能ブロック302?314を含む。負荷分散ユニット106のこれらの機能ブロックは,少なくとも部分的にソフトウェアを使用して実現される。ホスト108には,1つまたは複数のアプリケーション316が含まれる。実施形態では,負荷分散ユニット106には,フォワーダ(fｏｒｗaｒdeｒ)302,クラシファイヤ(claｓｓifieｒ)304,リクエストルータ306,セッショントラッカ(ｓeｓｓiｏn ｔｒackeｒ)308,接続マイグレータ(cｏnnecｔiｏn migｒaｔｏｒ)310,トンネラ(ｔｕnneleｒ)312,ならびにヘルスおよび負荷ハンドラ314が含まれる。
(中略)
【0049】
図4に,分離された分類機能および転送機能を有するネットワーク負荷分散インフラストラクチャの例を示す。分離された分類機能および転送機能は,それぞれクラシファイヤ304およびフォワーダ302によって表される。分類機能および転送機能は,以下で,特に「分類,転送,およびリクエストルーティングの例」という題名の節でさらに説明するが,ネットワーク負荷分散インフラストラクチャ機能とホスト108の間の相互作用の例として,最初の説明をここで提示する。
【0050】
説明される実施形態で,フォワーダ302は,仮想IP(VIP)アドレス(1つまたは複数)に対応し,それに関するネットワークエンドポイントである。フォワーダ302は,パケットをさらなる宛先または最終的な宛先にルーティングする場合に,単純化されたおよび/または基本的なポリシ決定をする比較的低レベルの構成要素である。フォワーダ302は,ルーティングテーブルを調べてこの宛先を決定する。クラシファイヤ304は,1つまたは複数の要因(たとえば,ホスト状態情報)に基づいてルーティングテーブルに投入(ｐｏｐｕlaｔe)するが,これは本明細書の他の節でさらに説明する。
【0051】
クライアント102およびホスト108は,示されたネットワークアドレスにも対応す
る。具体的に言うと,クライアント102(1)は,アドレスC1に対応し,クライアント102(2)は,アドレスC2に対応し...クライアント102(m)は,アドレスCmに対応する。また,ホスト108(1)は,アドレスH1に対応し,ホスト108(2)は,アドレスH2に対応し...ホスト108(n)は,アドレスHnに対応する。」(22,24?25ページ)

エ 「【0058】
多くのプロトコル環境の通信パス(5)について,フォワーダ302は,ネットワークアドレスH1のホスト108(1)にクライアント102(1)からのパケットを単純にそのままで送ることはできない。というのは,これらのパケットは,VIPアドレス宛であり,これがフォワーダ302自体によってホストされるからである。その代わりに,フォワーダ302は,下記の例示的オプションの1つまたは複数を使用することができる。
【0059】
1.フォワーダ302は,(i)発信元(クライアント102(1))IPアドレス(C1)およびポート番号をフォワーダ302のIPアドレスおよびネットワークアドレス変換(NAT)によって生成されたポート番号によって上書きし,(ii)宛先IPアドレス(VIP)をホスト(108(1))のIPアドレス(H1)によって上書きすることによって,NATを実行する。
【0060】
2.フォワーダ302は,宛先IPアドレス(VIP)をホスト(108(1))のIPアドレス(H1)によって上書きし,その結果,発信元(クライアント102(1))IPアドレス(C1)およびポート番号が保存されるようにすることによって,「半NAT」(Half-NAT)を実行する。
【0061】
3.フォワーダ302は,クライアント102(1)から受信されたパケットを,フォワーダ302からホスト108(1)に「トンネリング」する。具体的には,この例では,各パケットを,ホスト108(1)にアドレッシングされた新しいIPパケット内にカプセル化することによって,トンネリングを実現することができる。ホスト108(1)上のネットワーク負荷分散対応ソフトウェアは,クライアント102(1)からフォワーダ302によって受信された元々のパケットを再構成する。この元々のパケットは,ホスト108(1)の仮想インターフェースに示される(たとえば,フォワーダ302に対応するVIPアドレスは,ホスト108(1)のこの仮想インターフェースに束縛される。)。そのようなトンネリングの例示的実施形態を,以下で,特に接続移行シナリオに関して,特に「任意のトンネリングおよび/またはアプリケーションレベルロードバランシングを伴う接続移行の例」という題名の節で,トンネラ312に関してさらに説明する。」(26ページ)

オ 「【0095】
(1)での動作で,ホスト状態情報デターミナ1002は,それぞれのホスト108および/またはアプリケーション316についてホスト状態情報1006を判定する。(1)および(2)で,ホスト状態情報ディセミネータ1004は,ホスト状態情報1006をホスト108から負荷分散インフラストラクチャ106に配布する。たとえば,ホスト状態情報1006を,個々の負荷分散ユニット106に配布できる。(3)で,ロジック1008は,負荷分散判断が,ホスト状態情報1006に反応するようにする。(4)で,ネットワーク負荷分散判断に基づいて,接続がターゲットのホスト108に転送される。
【0096】
図11は,ホスト状態情報を含むネットワーク負荷分散の例示的な方法を示すフローチャート1100である。フローチャート1100には,3つのブロック1102?1106が含まれる。フローチャート1100の動作は,他の環境でおよびさまざまなソフトウェア方式と共に実行することができるが,図1?3および10を特に使用して,この方法の一部の態様および例を示す。
【0097】
ブロック1102において,ホスト状態情報は,ホストから負荷分散ユニットに送信される。たとえば,ホスト状態情報1006は,ホスト108から負荷分散ユニット106に送信される。ブロック1104において,ホスト状態情報は,負荷分散ユニットでホストから受信される。たとえば,負荷分散ユニット106は,ホスト108からのホスト状態情報1006を受信できる。ブロック1106において,負荷分散判断は,受信されたホスト状態情報に応答するようにされる。たとえば,負荷分散ユニット106のロジック1008は,ネットワーク負荷分散に関する判断を,ホスト状態情報1006に応答するようにすることができる。
【0098】
したがって,図10では,負荷分散インフラストラクチャ106は,ホスト108(および/またはそのアプリケーション316)からホスト状態情報1006を収集し,ホスト108に向けられた入力リクエストが,ホスト状態情報1006に応答して負荷分散される。以下で図12?18を参照してさらに説明するように,このホスト状態情報1006は,アプリケーション固有とすることができる。やはり以下でさらに説明するように,ホスト状態情報1006の例には,ヘルスおよび/または負荷情報を含めることができる。
(中略)
【0101】
ヘルス情報は,所与のホストおよび/またはアプリケーションがクライアントリクエストを処理できるかどうかを反映する。負荷情報は,所与のホストおよび/またはアプリケーションが特定の瞬間に処理できるクライアントリクエストの数,量,および/またはレベルを反映する。言い換えると,負荷は,所与のホストおよび/またはアプリケーションの総容量の使用可能な数,量,および/またはレベルを直接におよび/または逆に反映することができる。上記で注記したように,図12?18を参照して説明する実施形態は,ヘルスおよび/または負荷情報に焦点を合わせたものであるが,この実施形態は,(そのアプリケーションを含む)ホストの一般的な状態情報にも適用可能である。
(中略)
【0104】
各負荷分散ユニット106(1),106(2)...106(ｕ)には,それぞれの統合ヘルスおよび負荷(H＆L)キャッシュ1208(1),1208(2)...1208(ｕ)が含まれる。各統合ヘルスおよび負荷キャッシュ1208に,各ヘルスおよび負荷テーブル1204(1),1204(2)...1204(n)からの情報が含まれる。その結果,各負荷分散ユニット106に,負荷分散ユニット106がそのネットワークトラフィックを負荷分散するホスト108のそれぞれのヘルスおよび負荷情報1206へのすばやい(たとえばキャッシュに格納された)アクセスが与えられる。」(32?33ページ)

カ 「【0355】
図38に,フォワーダ302およびホスト108の間のパケットトンネリングに対する例示的な手法を示す。カプセル化されたパケット3808を,送信されるパケットごとのオーバーヘッドをこうむらずに,フォワーダ302からホスト108にトンネリングすることができる。以下でさらに説明するように,トンネリングは,フロー識別子3814ならびにそれぞれフォワーダ302およびホスト108のトンネラ312(F)および312(H)のカプセル化マッピングテーブル3806および3810を使用して実現される。フロー識別子3814は,カプセル化されたパケット3808に挿入される。
【0356】
上記で図32を参照して注記したように,接続移行の後に来る接続のパケットを,トンネラ312によるトンネリングを使用して,フォワーダ302によってホスト108(1)にルーティングすることができる。(8)(図32)で,フォワーダ302によって,そのような後続パケットが,ネットワークアドレス「F」を有するフォワーダ302から,ネットワークアドレス「H1」を有するホスト108(1)に転送される。上記で図4を参照して説明したように,フォワーダ302は,入力パケットをホスト108(1)にルーティングするために,NAT,半NAT,トンネリングなどを実行することができる。
【0357】
そのような入力パケットに,クライアント102(1)から到着するパケットの,仮想IP(「VIP」)アドレスの宛先IPアドレスおよび「C1」の発信元IPアドレスが含まれる。ホスト108(1)にルーティングされるパケットは,H1の宛先IPアドレスと,C1(半NATの場合)または「F」(フルNATの場合)の発信元アドレスを有する。このアドレスの再書込は,クライアント102(1)およびホスト108(1)の両方が発信元アドレスおよび宛先アドレスの同一のビューを有することを期待するプロトコルと干渉する可能性がある。
(中略)
【0369】
カプセル化されたパケット3808を作成するために,トンネラ312(F)によって,TCP/IP4タプルヘッダの発信元部分および宛先部分に,フロー識別子3814が挿入される。インターネットIPｖ4実施形態に関して,この2つのTCPポート部分によって,合計32ビットのスペースが提供される。また,TCP/IP4タプルヘッダの発信元IPアドレス部分に関して,トンネラ312(F)によって,フォワーダ302のIPアドレス「F」が挿入される。TCP/IP4タプルヘッダの宛先IPアドレス部分に関して,トンネラ312(F)によって,ホスト108のIPアドレス「H」が挿入される。
【0370】
フォワーダ302によって,カプセル化されたパケット3808がホスト108にルーティング/送信され,ホスト108によって,フォワーダ302からのカプセル化されたパケット3808が受け取られる。ホスト108のトンネラ312(H)コンポーネントによって,カプセル化されたパケット3808が,非カプセル化されなければならないトンネリングされたパケットであることが検出される。
【0371】
フロー識別子3814が,カプセル化されたパケット3808から抽出され,カプセル化マッピングテーブル3810のカプセル化マッピングエントリ3810(1)内でリンクされた対応するTCP/IP4タプル3804をルックアップするのに使用される。TCP/IP4タプル3804は,トンネラ312(H)によって,フォワーダ302で入力パケット3802で最初に受け取られたTCP/IP4タプル3804ヘッダを再作成するのに使用される。
【0372】
具体的に言うと,フォワーダ302のIPアドレスFが,発信元IPアドレスと置換され,ホスト108のIPアドレスHが,宛先IPアドレスと置換される。さらに,フロー識別子3814が,発信元TCPポートおよび宛先TCPポートと置換される。非カプセル化されたパケットが,ホスト108のネットワークスタックでターゲットアプリケーション316まで示される。」(77?78,79?80ページ)


上記ア?カの記載及び図面並びに当該分野の技術常識を参酌すると,
上記アの記載によれば,引用例にはネットワーク負荷分散方法について記載されていると認められる。
上記イの【0034】の記載によれば,引用例には「ルータ/スイッチが複数の負荷分散ユニットの間で入力ネットワークトラフィックに係るパケットを分配する」ことが記載されていると認められる。
上記アの【0001】,上記ウの【0050】,上記オの記載及び図1?4によれば,負荷分散ユニットはホスト状態情報を収集し,ホスト状態情報に基づいて負荷分散判断され,ネットワーク負荷分散判断に基づいて,接続がターゲットホストに転送されるものである。したがって,引用例には「負荷分散ユニットの個々の負荷分散ユニットにおいて,受信した個々のパケットを転送すべきターゲットホストを,収集したホスト状態情報に基づいて選択する」ことが記載されていると認められる。
上記エの【0061】,上記カの記載及び図38によれば,パケットは,負荷分散ユニットにて,TCP/IP4タプルヘッダの発信元IPアドレス部分に関してフォワーダのIPアドレス「F」が挿入され,宛先IPアドレス部分に関して選択されたターゲットホストのIPアドレス「H」が挿入されてカプセル化される。したがって,引用例には「前記個々の負荷分散ユニットにおいて,個々のパケットをカプセル化し,カプセル化されたパケットは,TCP/IP4タプルヘッダの発信元IPアドレス部分に関してフォワーダのIPアドレス「F」が挿入され,宛先IPアドレス部分に関してターゲットホストのIPアドレス「H」が挿入される」ことが記載されていると認められる。
上記カの【0356】によれば,カプセル化されたパケットを個々の負荷分散ユニットからターゲットホストに対して転送していることは明らかである。

以上を総合すると,引用例には,
「ネットワーク負荷分散方法であって,
ルータ/スイッチが複数の負荷分散ユニットの間で入力ネットワークトラフィックに係るパケットを分配し,
前記複数の負荷分散ユニットの個々の負荷分散ユニットにおいて,受信した個々のパケットを転送すべきターゲットホストを,収集したホスト状態情報に基づいて選択し,
前記個々の負荷分散ユニットにおいて,個々のパケットをカプセル化し,カプセル化されたパケットは,TCP/IP4タプルヘッダの発信元IPアドレス部分に関してフォワーダのIPアドレス「F」が挿入され,宛先IPアドレス部分に関してターゲットホストのIPアドレス「H」が挿入され,
前記カプセル化されたパケットを前記個々の負荷分散ユニットから前記ターゲットホストに対して転送する,方法。」
という発明(以下,「引用発明」という。)が記載されていると認められる。

(公知技術)
原査定の拒絶の理由に引用されたTowards a Next Generation Data Center Achitecture: Scalability and Commoditization,SIGCOMM '08,2008年8月17日,p.57-62,URL,http://research.microsoft.com/pubs/79348/presto27-greenberg.pdf(以下,「公知例1」という。)には,図面とともに以下の事項が記載されている。

ア 「As shown in Figure 2, all servers connect to the layer 2 network that is designed to have full reachability with no oversubscribed links, meaning that any server can communicate with any other server at the full 1 Gbps rate of the servers’ network interfaces. The layer 3 portion of the Monsoon network connects the data center to the Internet, and it uses Equal Cost MultiPath (ECMP) to spread the requests received from the Internet equally over all access routers. As the requests enter the layer 2 domain, the access routers use consistent hashing to spread the requests going to each application’s public VIP equally over the set of servers acting as load balancers for that application. Finally, the load balancers spread the requests using an application-specific load distribution function over the pool of servers, identified by their DIPs, that implement the application functionality.」(59ページ左欄下から11行?同ページ右欄3行)
([当審仮訳]:
図2に示されるように,すべてのサーバーは,必要以上に要求されるリンク無しに完全な到達可能性を持つように設計されているレイヤ2ネットワークに接続しており,これはどのサーバも他のサーバーとサーバのネットワークインターフェイスの完全な1Gbｐｓの速度で通信できることを意味している。モンスーン・ネットワークのレイヤ3部分は,データセンターをインターネットへ接続し,インターネットから受信したリクエストをすべてのアクセスルータにわたって拡散するために等コストマルチパス(ECMP)を使用している。リクエストがレイヤ2ドメインを入ると,アクセスルータは,各アプリケーションのパブリックVIPに行くリクエストを,そのアプリケーションのロードバランサとして動作するサーバーのセットにわたって均等に拡散するために,コンシステント・ハッシュイングを使用する。最後に,ロードバランサは,アプリケーション固有の負荷分散機能を使用して,リクエストを,DIPで識別されアプリケーションの機能を実装するサーバーのプールにわたって拡散する。)


本件の最先の優先日前に公開された特開2007-180963号公報(以下,「公知例2」という。)には,「クラスタノード制御プログラム,クラスタノード,クラスタシステム」として,図面とともに以下の事項が記載されている。

イ 「【0032】
インターネット10上のクライアントは,ディスパッチャ16,FW14a,14bを介して,Webサーバ11a,11b,11c,11dへのアクセスを行う。ディスパッチャ16は,インターネット10に接続され,FW14a,14bに対して負荷分散を行う。FW14a,14bは,ディスパッチャ16側からWebサーバ11a,11b,11c,11d側への不正アクセスを防止すると共に,Webサーバ11a,11b,11c,11dに対して負荷分散を行う。Webサーバ11a,11b,11c,11dは,FW14c,14d,14eのいずれかを介して,APサーバ12a,12b,12cへのアクセスを行う。FW14c,14d,14eは,Webサーバ11a,11b,11c,11d側からAPサーバ12a,12b,12c側への不正アクセスを防止すると共に,APサーバ12a,12b,12cに対して負荷分散を行う。APサーバ12a,12b,12cは,DB13へのアクセスを行う。なお,図1においては,各ノード間を結ぶ矢印でリクエストの方向のみを示したが,矢印の逆方向にレスポンスも発生する。
(中略)
【0035】
Webシステムで最も前段にあるディスパッチャ16は,インターネット10上のクライアントからのリクエストパケットのソースアドレスにハッシュ関数を適用することにより,後段のFW14a,14bに対する負荷分散を行う。ディスパッチャ16は,ハードウェアとソフトウェアのどちらで構成しても良い。
(中略)
【0038】
従来のパケット転送方式として,NAT方式,IPトンネリング方式,ダイレクトルーティング方式が用いられている。NAT方式は,パケット内のデスティネーションアドレスやポート番号を変換し,レスポンスパケットにも同様のアドレス変換を行う方式である。IPトンネリング方式は,IPデータグラムの中に他のIPアドレス宛のパケットをカプセル化し,レスポンスパケットはリクエストパケットの送信元に直接返すことができる方式である。ダイレクトルーティング方式は,パケット内の宛先MACアドレスを書き換えることによって転送先を変更し,レスポンスパケットは送信元に直接返すことができる方式である。但し,すべてのノードが同一セグメント内に存在しなければならない。
(中略)
【0050】
図3は,本実施の形態に係るIP変換テーブルの一例を示す表である。ここで示したIP変換テーブルの例は,WebサーバとAPサーバの間の通信に必要な情報だけを示す。Webサーバ11a内のIP変換テーブルには,APサーバのVIPとRIPの候補の対応関係,FWのVIPとRIPの候補の対応関係が登録されている。APサーバのRIPの候補としてAPサーバ12a,12b,12cのRIPが登録されており,FWのRIPの候補としてFW14c,14d,14eのRIPが登録されている。APサーバ12a内のIP変換テーブルには,WebサーバのVIPとRIPの候補の対応関係,FWのVIPとRIPの候補の対応関係が登録されている。WebサーバのRIPの候補としてWebサーバ11a,11b,11c,11dのRIPが登録されており,FWのRIPの候補としてFW14c,14d,14eのRIPが登録されている。
【0051】
また,ハッシュ関数は,Webサーバ11a,11b,11c,11d,APサーバ12a,12b,12cに同一の関数が与えられる。」(7,8,9ページ)

原査定の補正の却下の決定において引用された特開2007-312434号公報(以下,「公知例3」という。)には,「移動機通信システムおよび通信方法」として,図面とともに以下の事項が記載されている。

ウ 「【0100】
コネクションの開設時には,分散ポリシー情報テーブル66の内容に基づいて,パケットの振り分け先としてのパケットゲートウェイ装置を決定する。この分散ポリシー情報テーブル66の内容は,図2の複数の負荷分散装置(L.B.)25a,25b,・・・のいずれにおいても同じである。」(15ページ)

上記ア,上記イの【0035】の記載によれば,
「複数の負荷分散装置において,ハッシュ関数を使用してパケットの転送先のターゲットを選択すること。」は公知であると認められる(以下,「公知事項1」という。)。

上記イの【0051】,上記ウの記載によれば,
「負荷分散に際し,複数の負荷分散装置で,共通のハッシュ関数を使用したり,同じ負荷分散ポリシーを用いること。」は公知であると認められる(以下,「公知事項2」という。)。

(2)対比
補正後の発明と引用発明とを対比すると,
ア 引用発明の「ネットワーク負荷分散方法」は,処理デバイスによってプログラムが実行されることにより当該方法が実行されると解するのが自然であるから,これを「処理デバイスによって実行されると,該処理デバイスに負荷分散方法を実行させるプログラム」と称することは任意である。

イ 引用発明の「複数の負荷分散ユニット」は,「一連のモジュール」といえる。また,引用発明の「入力ネットワークトラフィックに係るパケット」は,補正後の発明の「ネットワークパケット」に相当する。
したがって,引用発明の「ルータ/スイッチが複数の負荷分散ユニットの間で入力ネットワークトラフィックに係るパケットを分配し」は,補正後の発明の「一連のモジュール間にネットワークパケットを拡散するステップ」に相当する。

ウ 引用発明の「ターゲットホスト」は,補正後の発明の「ターゲットデバイス」に相当する。
したがって,補正後の発明の「前記一連のモジュールの個々のモジュールにおいて,受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップであって,前記一連のモジュールは同じハッシュ関数を使用するように構成され,前記個々のモジュールは,前記ハッシュ関数を使用して,ネットワークパケットを転送すべきターゲットデバイスを選択する,ステップ」と,引用発明の「前記複数の負荷分散ユニットの個々の負荷分散ユニットにおいて,受信した個々のパケットを転送すべきターゲットホストを,収集したホスト状態情報に基づいて選択し」とは,以下の相違点1は別として,「前記一連のモジュールの個々のモジュールにおいて,受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップ」の点で共通している。
また,引用発明の「前記カプセル化されたパケットを前記個々の負荷分散ユニットから前記ターゲットホストに対して転送する」は,補正後の発明の「前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップ」に相当する。

エ 引用発明の「フォワーダのIPアドレス「F」」,「ターゲットホストのIPアドレス「H」」は,それぞれ補正後の発明の「個々のモジュールに関連するソースアドレス」,「ターゲットデバイスに関連する宛先アドレス」に相当する。
したがって,補正後の発明の「前記個々のモジュールにおいて,前記個々のネットワークパケットのソースアドレスと宛先アドレスとを保存するように,前記個々のネットワークパケットをカプセル化するステップであって,カプセル化されたパケットは,前記個々のモジュールに関連するソースアドレスと,前記ターゲットデバイスに関連する宛先アドレスとによって,前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットをカプセル化することによって生成される,ステップ」と,引用発明の「前記個々の負荷分散ユニットにおいて,個々のパケットをカプセル化し,カプセル化されたパケットは,TCP/IP4タプルヘッダの発信元IPアドレス部分に関してフォワーダのIPアドレス「F」が挿入され,宛先IPアドレス部分に関してターゲットホストのIPアドレス「H」が挿入され」とは,以下の相違点2は別として,「前記個々のモジュールにおいて,前記個々のネットワークパケットをカプセル化するステップであって,カプセル化されたパケットは,前記個々のモジュールに関連するソースアドレスと,前記ターゲットデバイスに関連する宛先アドレスを有する,ステップ」の点で共通している。

以上を総合すると,本願発明と引用発明とは,以下の点で一致し,また,相違している。
(一致点)
「処理デバイスによって実行されると,該処理デバイスに負荷分散方法を実行させるプログラムであって,前記方法が,
一連のモジュール間にネットワークパケットを拡散するステップと,
前記一連のモジュールの個々のモジュールにおいて,受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップと,
前記個々のモジュールにおいて,前記個々のネットワークパケットをカプセル化するステップであって,カプセル化されたパケットは,前記個々のモジュールに関連するソースアドレスと,前記ターゲットデバイスに関連する宛先アドレスを有する,ステップと,
前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップと
を含む,プログラム。」

(相違点1)
一致点の「前記一連のモジュールの個々のモジュールにおいて,受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップ」に関し,補正後の発明は,「前記一連のモジュールは同じハッシュ関数を使用するように構成され,前記個々のモジュールは,前記ハッシュ関数を使用して,ネットワークパケットを転送すべきターゲットデバイスを選択する」であるのに対し,引用発明は収集したホスト状態情報に基づいてターゲットホストを選択するものであって,補正後の発明の上記構成を有していない点。

(相違点2)
一致点の「前記個々のモジュールにおいて,前記個々のネットワークパケットをカプセル化するステップであって,・・・,ステップ」に関し,補正後の発明は,「カプセル化されたパケットは,前記個々のモジュールに関連するソースアドレスと,前記ターゲットデバイスに関連する宛先アドレスとによって,前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットをカプセル化することによって生成される」のに対し,引用発明は,当該事項が明らかでない点。

(3)判断
上記相違点について検討する。
(相違点1について)
公知技術1のとおり,「複数の負荷分散装置において,ハッシュ関数を使用してパケットの転送先のターゲットを選択すること。」は公知であり,また,公知事項2のとおり,「負荷分散に際し,複数の負荷分散装置で,共通のハッシュ関数を使用したり,同じ負荷分散ポリシーを用いること。」も公知である。
しかしながら,引用発明は,従来の「ラウンドロビン負荷分散分配は,通常は,パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく利用される」という課題を解決することを目的として,ホスト状態情報を用いてネットワーク負荷分散を行うものである。
そして,ハッシュ関数を使用してパケットの転送先のターゲットを選択することは,パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく分散することとなることから,引用発明の「前記複数の負荷分散ユニットの個々の負荷分散ユニットにおいて,受信した個々のパケットを転送すべきターゲットホストを,収集したホスト状態情報に基づいて選択」することに替えて,当該公知技術を採用することは,引用発明の課題が達成されないこととなるから,組み合わせの動機付けを欠くものである。すなわち,引用発明を出発点として,補正後の発明をすることはできない。
なお,引用例の【0221】,【0225】?【0257】,【0231】には,DAMに関して位置選択のためのハッシュ化をすることが記載されているが,当該開示内容はハッシュ関数を使用してパケットの転送先のターゲットを選択するものではない。

したがって,相違点2について検討するまでもなく,補正後の発明は,引用発明及び公知技術に基いて当業者が容易に発明をすることができたものとはいえない。
また,補正後の発明を異なるカテゴリーとして表現した請求項7,9に係る発明についても,同様に,引用発明及び公知技術に基いて当業者が容易に発明をすることができたものとはいえない。

3 むすび
本件補正は,特許法第17条の2第3項?第6項の規定に適合する。


第3 本願発明
本件補正は上記のとおり,特許法第17条の2第3項?第6項の規定に適合するから,本願の請求項1?10に係る発明は,本件補正により補正された特許請求の範囲の請求項1?10に記載された事項により特定されるとおりのものである。
そして,本願については,原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2016-05-09 
出願番号 特願2012-513343(P2012-513343)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 536- WY (H04L)
P 1 8・ 537- WY (H04L)
最終処分 成立  
前審関与審査官 上田 翔太  
特許庁審判長 大塚 良平
特許庁審判官 萩原 義則
菅原 道晴
発明の名称 レイヤー2ドメインにわたる負荷分散  
代理人 大貫 進介  
代理人 伊東 忠重  
代理人 伊東 忠彦  

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