【事件の表示】
　特願２０１２−５１３３４３「レイヤー２ドメインにわたる負荷分散」拒絶査定不服審判事件〔平成２２年１２月　２日国際公開，ＷＯ２０１０／１３８９３６，平成２４年１１月１２日国内公表，特表２０１２−５２８５５１，請求項の数（１０）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は，２０１０年５月２８日（パリ条約による優先権主張外国庁受理　２００９年５月２８日　米国，２００９年１０月２６日　米国）を国際出願日とする出願であって，平成２６年８月２８日付けで最後の拒絶理由が通知され，平成２６年１１月２８日付けで手続補正がなされたが，平成２７年４月１０日付けで補正の却下の決定がされるとともに同日付けで拒絶査定がされ，これに対し，同年８月２１日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
　
第２　平成２７年８月２１日付けの手続補正（以下，「本件補正」という。）の適否
１　補正の内容
（補正事項１）
　本件補正は，平成２６年６月３日付け手続補正書により補正された特許請求の範囲の請求項１に記載された
「処理デバイスによって実行されると，該処理デバイスに負荷分散方法を実行させるプログラムであって，前記方法が，
　一連のモジュール間にネットワークパケットを拡散するステップと，
　前記一連のモジュールの個々のモジュールにおいて，受信した個々のネットワークパケットのソースアドレスと宛先アドレスとを保存するように，前記個々のネットワークパケットをカプセル化するステップと，
　前記一連のモジュール間で共有されるハッシュを使用して，カプセル化されたパケットを提供するターゲットデバイスを選択するステップであって，前記カプセル化されたパケットは，前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットを含み，前記カプセル化されたパケットのソースアドレスは，前記個々のモジュールに関連し，前記カプセル化されたパケットの宛先アドレスは，前記ターゲットデバイスに関連する，ステップと，
　前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップと
　を含む，プログラム。」
という発明（以下，「補正前の発明」という。）を
「処理デバイスによって実行されると，該処理デバイスに負荷分散方法を実行させるプログラムであって，前記方法が，
　一連のモジュール間にネットワークパケットを拡散するステップと，
　前記一連のモジュールの個々のモジュールにおいて，受信した個々のネットワークパケット
を転送すべきターゲットデバイスを選択するステップであって，前記一連のモジュールは同じハッシュ関数を使用するように構成され，前記個々のモジュールは，前記ハッシュ関数を使用して，ネットワークパケットを転送すべきターゲットデバイスを選択する，ステップと，
　前記個々のモジュールにおいて，前記個々のネットワークパケット
であって，
前記個々のモジュールに関連するソースアドレスと，前記ターゲットデバイスに関連する宛先アドレスとによって，
カプセル化することによって生成される
　前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップと
　を含む，プログラム。」
という発明（以下，「補正後の発明」という。）に変更するものであり，また，独立請求項である本件補正前の請求項８，１２（本件補正後の請求項７，９）についても同様に補正をするものである。
（［当審注］：上記の下線部は補正箇所を示す）
（補正事項２）
　本件補正前の請求項４の「前記ハッシュ」を「前記ハッシュ関数」（本件補正後の請求項４）とするものである。
（補正事項３）
　本件補正前の請求項１４の「前記個々のターゲットデバイス」を「前記ターゲットデバイス」（本件補正後の請求項１０）とするものである。
（補正事項４）
　本件補正前の請求項６，１０，１１，１３，１５を削除し，それに伴い請求項の項番を繰り上げるものである。
２　補正の適否
　まず補正事項２〜４について検討した後，補正事項１について検討する。
（補正事項２，４について）
　補正事項２，４は，いずれも，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内において，引用する請求項に「前記」されたものと記載ぶりを統一するものであるから，誤記の訂正を目的とするものといえ，また，特許法第１７条の２第４項に違反するところはない。
（補正事項３について）
　補正事項３は請求項の削除を目的とするものであり，また，特許法第１７条の２第４項に違反するところはない。
（補正事項１について）
　補正事項１は，「選択するステップ」に記載されていた「カプセル化されたパケット」の内容を「カプセル化するステップ」にて記載するようにしたため，補正前後で表現ぶりは異なるものの，その技術的内容については，実質的に，補正前の発明のターゲットデバイスの選択に使用される「共有されるハッシュ」を「同じハッシュ関数」に限定するものである。そして，補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから，補正事項１は，特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　また，特許法第１７条の２第３項，第４項に違反するところはない。
　そこで，補正後の発明が特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について以下に検討する。
（１）補正後の発明
　本正後の発明は，上記「１　補正の内容（補正事項１）」の項の「補正後の発明」のとおりのものと認める。
（２）刊行物の記載事項
（引用発明）
　原査定の拒絶の理由に引用された特開２００５−２５７５６号公報（以下，「引用例１」という。）には，「ホスト状態情報を用いるネットワーク負荷分散」として，図面とともに以下の事項が記載されている。
ア　「【０００１】
　この開示は，一般にネットワーク負荷分散（ｎｅｔｗｏｒｋ  ｌｏａｄ  ｂａｌａｎｃｉｎｇ）に関し，詳細には，制限ではなく例として，ホスト状態情報を用いるネットワーク負荷分散に関する。
（中略）
【０００７】
　負荷分散動作を実施するために，ハードウェアは，通常，到着する接続リクエストのラウンドロビン分散を実行する。言い換えると，到着する接続リクエストは，単一の接続リクエストを各サーバに分散する方法を繰り返して，一連のサーバの中のサーバに線形的に分散される。この接続のラウンドロビン負荷分散分配は，通常は，パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく利用される。負荷分散動作が，ラウンドロビン分散を超えて拡大される場合，これらの他の要因は，ネットワークトラフィックおよび／またはパーソナルネットワークの輻輳レベルから推論できる範囲で考慮されるに過ぎない。」（１７〜１８ページ）
　
イ　「【００３１】
　図２は，複数の負荷分散ユニット１０６および複数のホスト１０８を示す例示的なネットワーク負荷分散パラダイム２００を示す図である。具体的に言うと，負荷分散インフラストラクチャ１０６は，例示的なネットワーク負荷分散パラダイム２００内では複数の負荷分散ユニット１０６（１），１０６（２）．．．１０６（ｕ）として図示されている。さらに，２つのルータおよび／またはスイッチ２０２（１）および２０２（２）が図示されている。
【００３２】
　ルータ／スイッチ２０２は，存在する場合に，負荷分散インフラストラクチャ１０６（図１の）の一部またはこれと分離していると考えることができる。ルータ／スイッチ２０２は，ネットワーク１０４から受信される全部のリクエストおよび個々のパケットを負荷分散ユニット１０６の共有仮想ＩＰ（ＶＩＰ）アドレスに向ける責任を負う。第１のルータ／スイッチ２０２に障害が発生する場合に，第２のルータ／スイッチ２０２は，第１のルータ／スイッチの引継ぎをすることができる。２つのルータ／スイッチ２０２が示されているが，その代わりに１つまたは３つ以上のルータ／スイッチ２０２を使用することができる。
（中略）
【００３４】
　その一方で，ルータ／スイッチ２０２が，負荷分散対応である場合には，ルータ／スイッチ２０２を，入力ネットワークトラフィックを複数の負荷分散ユニット１０６の間で分配（たとえばラウンドロビン式で）するようにすることができる。そのような負荷分散対応ルータ／スイッチ２０２が，基本レベル（たとえばハードウェア）で負荷分散機能を実行できることを理解されたい。たとえば，負荷分散対応ルータ／スイッチ２０２によって，単純なＩＰアドレスベースのセッションアフィニティ（ｓｅｓｓｉｏｎ  ａｆｆｉｎｉｔｙ）を実行し，その結果，特定の発信元ＩＰアドレスからのすべてのパケットを，同一の負荷分散ユニット１０６に向けることができるようになる。」（２１ページ）
ウ　「【００３７】
　図３は，分離された機能を有する例示的な負荷分散ユニット１０６および例示的なホスト１０８を示す。負荷分散ユニット１０６は，７つの機能ブロック３０２〜３１４を含む。負荷分散ユニット１０６のこれらの機能ブロックは，少なくとも部分的にソフトウェアを使用して実現される。ホスト１０８には，１つまたは複数のアプリケーション３１６が含まれる。実施形態では，負荷分散ユニット１０６には，フォワーダ（ｆｏｒｗａｒｄｅｒ）３０２，クラシファイヤ（ｃｌａｓｓｉｆｉｅｒ）３０４，リクエストルータ３０６，セッショントラッカ（ｓｅｓｓｉｏｎ  ｔｒａｃｋｅｒ）３０８，接続マイグレータ（ｃｏｎｎｅｃｔｉｏｎ  ｍｉｇｒａｔｏｒ）３１０，トンネラ（ｔｕｎｎｅｌｅｒ）３１２，ならびにヘルスおよび負荷ハンドラ３１４が含まれる。
（中略）
【００４９】
　図４に，分離された分類機能および転送機能を有するネットワーク負荷分散インフラストラクチャの例を示す。分離された分類機能および転送機能は，それぞれクラシファイヤ３０４およびフォワーダ３０２によって表される。分類機能および転送機能は，以下で，特に「分類，転送，およびリクエストルーティングの例」という題名の節でさらに説明するが，ネットワーク負荷分散インフラストラクチャ機能とホスト１０８の間の相互作用の例として，最初の説明をここで提示する。
【００５０】
　説明される実施形態で，フォワーダ３０２は，仮想ＩＰ（ＶＩＰ）アドレス（１つまたは複数）に対応し，それに関するネットワークエンドポイントである。フォワーダ３０２は，パケットをさらなる宛先または最終的な宛先にルーティングする場合に，単純化されたおよび／または基本的なポリシ決定をする比較的低レベルの構成要素である。フォワーダ３０２は，ルーティングテーブルを調べてこの宛先を決定する。クラシファイヤ３０４は，１つまたは複数の要因（たとえば，ホスト状態情報）に基づいてルーティングテーブルに投入（ｐｏｐｕｌａｔｅ）するが，これは本明細書の他の節でさらに説明する。
【００５１】
　クライアント１０２およびホスト１０８は，示されたネットワークアドレスにも対応す
る。具体的に言うと，クライアント１０２（１）は，アドレスＣ１に対応し，クライアント１０２（２）は，アドレスＣ２に対応し．．．クライアント１０２（ｍ）は，アドレスＣｍに対応する。また，ホスト１０８（１）は，アドレスＨ１に対応し，ホスト１０８（２）は，アドレスＨ２に対応し．．．ホスト１０８（ｎ）は，アドレスＨｎに対応する。」（２２，２４〜２５ページ）
エ　「【００５８】
　多くのプロトコル環境の通信パス（５）について，フォワーダ３０２は，ネットワークアドレスＨ１のホスト１０８（１）にクライアント１０２（１）からのパケットを単純にそのままで送ることはできない。というのは，これらのパケットは，ＶＩＰアドレス宛であり，これがフォワーダ３０２自体によってホストされるからである。その代わりに，フォワーダ３０２は，下記の例示的オプションの１つまたは複数を使用することができる。
【００５９】
　１．フォワーダ３０２は，（ｉ）発信元（クライアント１０２（１））ＩＰアドレス（Ｃ１）およびポート番号をフォワーダ３０２のＩＰアドレスおよびネットワークアドレス変換（ＮＡＴ）によって生成されたポート番号によって上書きし，（ｉｉ）宛先ＩＰアドレス（ＶＩＰ）をホスト（１０８（１））のＩＰアドレス（Ｈ１）によって上書きすることによって，ＮＡＴを実行する。
【００６０】
　２．フォワーダ３０２は，宛先ＩＰアドレス（ＶＩＰ）をホスト（１０８（１））のＩＰアドレス（Ｈ１）によって上書きし，その結果，発信元（クライアント１０２（１））ＩＰアドレス（Ｃ１）およびポート番号が保存されるようにすることによって，「半ＮＡＴ」（Ｈａｌｆ−ＮＡＴ）を実行する。
【００６１】
　３．フォワーダ３０２は，クライアント１０２（１）から受信されたパケットを，フォワーダ３０２からホスト１０８（１）に「トンネリング」する。具体的には，この例では，各パケットを，ホスト１０８（１）にアドレッシングされた新しいＩＰパケット内にカプセル化することによって，トンネリングを実現することができる。ホスト１０８（１）上のネットワーク負荷分散対応ソフトウェアは，クライアント１０２（１）からフォワーダ３０２によって受信された元々のパケットを再構成する。この元々のパケットは，ホスト１０８（１）の仮想インターフェースに示される（たとえば，フォワーダ３０２に対応するＶＩＰアドレスは，ホスト１０８（１）のこの仮想インターフェースに束縛される。）。そのようなトンネリングの例示的実施形態を，以下で，特に接続移行シナリオに関して，特に「任意のトンネリングおよび／またはアプリケーションレベルロードバランシングを伴う接続移行の例」という題名の節で，トンネラ３１２に関してさらに説明する。」（２６ページ）
オ　「【００９５】
　（１）での動作で，ホスト状態情報デターミナ１００２は，それぞれのホスト１０８および／またはアプリケーション３１６についてホスト状態情報１００６を判定する。（１）および（２）で，ホスト状態情報ディセミネータ１００４は，ホスト状態情報１００６をホスト１０８から負荷分散インフラストラクチャ１０６に配布する。たとえば，ホスト状態情報１００６を，個々の負荷分散ユニット１０６に配布できる。（３）で，ロジック１００８は，負荷分散判断が，ホスト状態情報１００６に反応するようにする。（４）で，ネットワーク負荷分散判断に基づいて，接続がターゲットのホスト１０８に転送される。
【００９６】
　図１１は，ホスト状態情報を含むネットワーク負荷分散の例示的な方法を示すフローチャート１１００である。フローチャート１１００には，３つのブロック１１０２〜１１０６が含まれる。フローチャート１１００の動作は，他の環境でおよびさまざまなソフトウェア方式と共に実行することができるが，図１〜３および１０を特に使用して，この方法の一部の態様および例を示す。
【００９７】
　ブロック１１０２において，ホスト状態情報は，ホストから負荷分散ユニットに送信される。たとえば，ホスト状態情報１００６は，ホスト１０８から負荷分散ユニット１０６に送信される。ブロック１１０４において，ホスト状態情報は，負荷分散ユニットでホストから受信される。たとえば，負荷分散ユニット１０６は，ホスト１０８からのホスト状態情報１００６を受信できる。ブロック１１０６において，負荷分散判断は，受信されたホスト状態情報に応答するようにされる。たとえば，負荷分散ユニット１０６のロジック１００８は，ネットワーク負荷分散に関する判断を，ホスト状態情報１００６に応答するようにすることができる。
【００９８】
　したがって，図１０では，負荷分散インフラストラクチャ１０６は，ホスト１０８（および／またはそのアプリケーション３１６）からホスト状態情報１００６を収集し，ホスト１０８に向けられた入力リクエストが，ホスト状態情報１００６に応答して負荷分散される。以下で図１２〜１８を参照してさらに説明するように，このホスト状態情報１００６は，アプリケーション固有とすることができる。やはり以下でさらに説明するように，ホスト状態情報１００６の例には，ヘルスおよび／または負荷情報を含めることができる。
（中略）
【０１０１】
　ヘルス情報は，所与のホストおよび／またはアプリケーションがクライアントリクエストを処理できるかどうかを反映する。負荷情報は，所与のホストおよび／またはアプリケーションが特定の瞬間に処理できるクライアントリクエストの数，量，および／またはレベルを反映する。言い換えると，負荷は，所与のホストおよび／またはアプリケーションの総容量の使用可能な数，量，および／またはレベルを直接におよび／または逆に反映することができる。上記で注記したように，図１２〜１８を参照して説明する実施形態は，ヘルスおよび／または負荷情報に焦点を合わせたものであるが，この実施形態は，（そのアプリケーションを含む）ホストの一般的な状態情報にも適用可能である。
（中略）
【０１０４】
　各負荷分散ユニット１０６（１），１０６（２）．．．１０６（ｕ）には，それぞれの統合ヘルスおよび負荷（Ｈ＆Ｌ）キャッシュ１２０８（１），１２０８（２）．．．１２０８（ｕ）が含まれる。各統合ヘルスおよび負荷キャッシュ１２０８に，各ヘルスおよび負荷テーブル１２０４（１），１２０４（２）．．．１２０４（ｎ）からの情報が含まれる。その結果，各負荷分散ユニット１０６に，負荷分散ユニット１０６がそのネットワークトラフィックを負荷分散するホスト１０８のそれぞれのヘルスおよび負荷情報１２０６へのすばやい（たとえばキャッシュに格納された）アクセスが与えられる。」（３２〜３３ページ）
カ　「【０３５５】
　図３８に，フォワーダ３０２およびホスト１０８の間のパケットトンネリングに対する例示的な手法を示す。カプセル化されたパケット３８０８を，送信されるパケットごとのオーバーヘッドをこうむらずに，フォワーダ３０２からホスト１０８にトンネリングすることができる。以下でさらに説明するように，トンネリングは，フロー識別子３８１４ならびにそれぞれフォワーダ３０２およびホスト１０８のトンネラ３１２（Ｆ）および３１２（Ｈ）のカプセル化マッピングテーブル３８０６および３８１０を使用して実現される。フロー識別子３８１４は，カプセル化されたパケット３８０８に挿入される。
【０３５６】
　上記で図３２を参照して注記したように，接続移行の後に来る接続のパケットを，トンネラ３１２によるトンネリングを使用して，フォワーダ３０２によってホスト１０８（１）にルーティングすることができる。（８）（図３２）で，フォワーダ３０２によって，そのような後続パケットが，ネットワークアドレス「Ｆ」を有するフォワーダ３０２から，ネットワークアドレス「Ｈ１」を有するホスト１０８（１）に転送される。上記で図４を参照して説明したように，フォワーダ３０２は，入力パケットをホスト１０８（１）にルーティングするために，ＮＡＴ，半ＮＡＴ，トンネリングなどを実行することができる。
【０３５７】
　そのような入力パケットに，クライアント１０２（１）から到着するパケットの，仮想ＩＰ（「ＶＩＰ」）アドレスの宛先ＩＰアドレスおよび「Ｃ１」の発信元ＩＰアドレスが含まれる。ホスト１０８（１）にルーティングされるパケットは，Ｈ１の宛先ＩＰアドレスと，Ｃ１（半ＮＡＴの場合）または「Ｆ」（フルＮＡＴの場合）の発信元アドレスを有する。このアドレスの再書込は，クライアント１０２（１）およびホスト１０８（１）の両方が発信元アドレスおよび宛先アドレスの同一のビューを有することを期待するプロトコルと干渉する可能性がある。
（中略）
【０３６９】
　カプセル化されたパケット３８０８を作成するために，トンネラ３１２（Ｆ）によって，ＴＣＰ／ＩＰ４タプルヘッダの発信元部分および宛先部分に，フロー識別子３８１４が挿入される。インターネットＩＰｖ４実施形態に関して，この２つのＴＣＰポート部分によって，合計３２ビットのスペースが提供される。また，ＴＣＰ／ＩＰ４タプルヘッダの発信元ＩＰアドレス部分に関して，トンネラ３１２（Ｆ）によって，フォワーダ３０２のＩＰアドレス「Ｆ」が挿入される。ＴＣＰ／ＩＰ４タプルヘッダの宛先ＩＰアドレス部分に関して，トンネラ３１２（Ｆ）によって，ホスト１０８のＩＰアドレス「Ｈ」が挿入される。
【０３７０】
　フォワーダ３０２によって，カプセル化されたパケット３８０８がホスト１０８にルーティング／送信され，ホスト１０８によって，フォワーダ３０２からのカプセル化されたパケット３８０８が受け取られる。ホスト１０８のトンネラ３１２（Ｈ）コンポーネントによって，カプセル化されたパケット３８０８が，非カプセル化されなければならないトンネリングされたパケットであることが検出される。
【０３７１】
　フロー識別子３８１４が，カプセル化されたパケット３８０８から抽出され，カプセル化マッピングテーブル３８１０のカプセル化マッピングエントリ３８１０（１）内でリンクされた対応するＴＣＰ／ＩＰ４タプル３８０４をルックアップするのに使用される。ＴＣＰ／ＩＰ４タプル３８０４は，トンネラ３１２（Ｈ）によって，フォワーダ３０２で入力パケット３８０２で最初に受け取られたＴＣＰ／ＩＰ４タプル３８０４ヘッダを再作成するのに使用される。
【０３７２】
　具体的に言うと，フォワーダ３０２のＩＰアドレスＦが，発信元ＩＰアドレスと置換され，ホスト１０８のＩＰアドレスＨが，宛先ＩＰアドレスと置換される。さらに，フロー識別子３８１４が，発信元ＴＣＰポートおよび宛先ＴＣＰポートと置換される。非カプセル化されたパケットが，ホスト１０８のネットワークスタックでターゲットアプリケーション３１６まで示される。」（７７〜７８，７９〜８０ページ）
　上記ア〜カの記載及び図面並びに当該分野の技術常識を参酌すると，
　上記アの記載によれば，引用例にはネットワーク負荷分散方法について記載されていると認められる。
　上記イの【００３４】の記載によれば，引用例には「ルータ／スイッチが複数の負荷分散ユニットの間で入力ネットワークトラフィックに係るパケットを分配する」ことが記載されていると認められる。
　上記アの【０００１】，上記ウの【００５０】，上記オの記載及び図１〜４によれば，負荷分散ユニットはホスト状態情報を収集し，ホスト状態情報に基づいて負荷分散判断され，ネットワーク負荷分散判断に基づいて，接続がターゲットホストに転送されるものである。したがって，引用例には「負荷分散ユニットの個々の負荷分散ユニットにおいて，受信した個々のパケットを転送すべきターゲットホストを，収集したホスト状態情報に基づいて選択する」ことが記載されていると認められる。
　上記エの【００６１】，上記カの記載及び図３８によれば，パケットは，負荷分散ユニットにて，ＴＣＰ／ＩＰ４タプルヘッダの発信元ＩＰアドレス部分に関してフォワーダのＩＰアドレス「Ｆ」が挿入され，宛先ＩＰアドレス部分に関して選択されたターゲットホストのＩＰアドレス「Ｈ」が挿入されてカプセル化される。したがって，引用例には「前記個々の負荷分散ユニットにおいて，個々のパケットをカプセル化し，カプセル化されたパケットは，ＴＣＰ／ＩＰ４タプルヘッダの発信元ＩＰアドレス部分に関してフォワーダのＩＰアドレス「Ｆ」が挿入され，宛先ＩＰアドレス部分に関してターゲットホストのＩＰアドレス「Ｈ」が挿入される」ことが記載されていると認められる。
　上記カの【０３５６】によれば，カプセル化されたパケットを個々の負荷分散ユニットからターゲットホストに対して転送していることは明らかである。
　以上を総合すると，引用例には，
「ネットワーク負荷分散方法であって，
　ルータ／スイッチが複数の負荷分散ユニットの間で入力ネットワークトラフィックに係るパケットを分配し，
　前記複数の負荷分散ユニットの個々の負荷分散ユニットにおいて，受信した個々のパケットを転送すべきターゲットホストを，収集したホスト状態情報に基づいて選択し，
　前記個々の負荷分散ユニットにおいて，個々のパケットをカプセル化し，カプセル化されたパケットは，ＴＣＰ／ＩＰ４タプルヘッダの発信元ＩＰアドレス部分に関してフォワーダのＩＰアドレス「Ｆ」が挿入され，宛先ＩＰアドレス部分に関してターゲットホストのＩＰアドレス「Ｈ」が挿入され，
　前記カプセル化されたパケットを前記個々の負荷分散ユニットから前記ターゲットホストに対して転送する，方法。」
という発明（以下，「引用発明」という。）が記載されていると認められる。
（公知技術）
　原査定の拒絶の理由に引用されたTowards a Next Generation Data Center Achitecture: Scalability and Commoditization，SIGCOMM '08，２００８年８月１７日，p.57-62，ＵＲＬ，http://research.microsoft.com/pubs/79348/presto27-greenberg.pdf（以下，「公知例１」という。）には，図面とともに以下の事項が記載されている。
ア　「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.」（５９ページ左欄下から１１行〜同ページ右欄３行）
（［当審仮訳］：
　図２に示されるように，すべてのサーバーは，必要以上に要求されるリンク無しに完全な到達可能性を持つように設計されているレイヤ２ネットワークに接続しており，これはどのサーバも他のサーバーとサーバのネットワークインターフェイスの完全な１Ｇｂｐｓの速度で通信できることを意味している。モンスーン・ネットワークのレイヤ３部分は，データセンターをインターネットへ接続し，インターネットから受信したリクエストをすべてのアクセスルータにわたって拡散するために等コストマルチパス（ＥＣＭＰ）を使用している。リクエストがレイヤ２ドメインを入ると，アクセスルータは，各アプリケーションのパブリックＶＩＰに行くリクエストを，そのアプリケーションのロードバランサとして動作するサーバーのセットにわたって均等に拡散するために，コンシステント・ハッシュイングを使用する。最後に，ロードバランサは，アプリケーション固有の負荷分散機能を使用して，リクエストを，ＤＩＰで識別されアプリケーションの機能を実装するサーバーのプールにわたって拡散する。）
　本件の最先の優先日前に公開された特開２００７−１８０９６３号公報（以下，「公知例２」という。）には，「クラスタノード制御プログラム，クラスタノード，クラスタシステム」として，図面とともに以下の事項が記載されている。
イ　「【００３２】
　インターネット１０上のクライアントは，ディスパッチャ１６，ＦＷ１４ａ，１４ｂを介して，Ｗｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄへのアクセスを行う。ディスパッチャ１６は，インターネット１０に接続され，ＦＷ１４ａ，１４ｂに対して負荷分散を行う。ＦＷ１４ａ，１４ｂは，ディスパッチャ１６側からＷｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄ側への不正アクセスを防止すると共に，Ｗｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄに対して負荷分散を行う。Ｗｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄは，ＦＷ１４ｃ，１４ｄ，１４ｅのいずれかを介して，ＡＰサーバ１２ａ，１２ｂ，１２ｃへのアクセスを行う。ＦＷ１４ｃ，１４ｄ，１４ｅは，Ｗｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄ側からＡＰサーバ１２ａ，１２ｂ，１２ｃ側への不正アクセスを防止すると共に，ＡＰサーバ１２ａ，１２ｂ，１２ｃに対して負荷分散を行う。ＡＰサーバ１２ａ，１２ｂ，１２ｃは，ＤＢ１３へのアクセスを行う。なお，図１においては，各ノード間を結ぶ矢印でリクエストの方向のみを示したが，矢印の逆方向にレスポンスも発生する。
（中略）
【００３５】
　Ｗｅｂシステムで最も前段にあるディスパッチャ１６は，
インターネット１０上のクライアントからのリクエストパケットのソースアドレスにハッシュ関数を適用することにより，後段のＦＷ１４ａ，１４ｂに対する負荷分散を行う。
（中略）
【００３８】
　従来のパケット転送方式として，ＮＡＴ方式，ＩＰトンネリング方式，ダイレクトルーティング方式が用いられている。ＮＡＴ方式は，パケット内のデスティネーションアドレスやポート番号を変換し，レスポンスパケットにも同様のアドレス変換を行う方式である。ＩＰトンネリング方式は，ＩＰデータグラムの中に他のＩＰアドレス宛のパケットをカプセル化し，レスポンスパケットはリクエストパケットの送信元に直接返すことができる方式である。ダイレクトルーティング方式は，パケット内の宛先ＭＡＣアドレスを書き換えることによって転送先を変更し，レスポンスパケットは送信元に直接返すことができる方式である。但し，すべてのノードが同一セグメント内に存在しなければならない。
（中略）
【００５０】
　図３は，本実施の形態に係るＩＰ変換テーブルの一例を示す表である。ここで示したＩＰ変換テーブルの例は，ＷｅｂサーバとＡＰサーバの間の通信に必要な情報だけを示す。Ｗｅｂサーバ１１ａ内のＩＰ変換テーブルには，ＡＰサーバのＶＩＰとＲＩＰの候補の対応関係，ＦＷのＶＩＰとＲＩＰの候補の対応関係が登録されている。ＡＰサーバのＲＩＰの候補としてＡＰサーバ１２ａ，１２ｂ，１２ｃのＲＩＰが登録されており，ＦＷのＲＩＰの候補としてＦＷ１４ｃ，１４ｄ，１４ｅのＲＩＰが登録されている。ＡＰサーバ１２ａ内のＩＰ変換テーブルには，ＷｅｂサーバのＶＩＰとＲＩＰの候補の対応関係，ＦＷのＶＩＰとＲＩＰの候補の対応関係が登録されている。ＷｅｂサーバのＲＩＰの候補としてＷｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄのＲＩＰが登録されており，ＦＷのＲＩＰの候補としてＦＷ１４ｃ，１４ｄ，１４ｅのＲＩＰが登録されている。
【００５１】
　また，
ハッシュ関数は，Ｗｅｂサーバ１１ａ，１１ｂ，１１ｃ，１１ｄ，ＡＰサーバ１２ａ，１２ｂ，１２ｃに同一の関数が与えられる
　原査定の補正の却下の決定において引用された特開２００７−３１２４３４号公報（以下，「公知例３」という。）には，「移動機通信システムおよび通信方法」として，図面とともに以下の事項が記載されている。
ウ　「【０１００】
　コネクションの開設時には，分散ポリシー情報テーブル６６の内容に基づいて，パケットの振り分け先としてのパケットゲートウェイ装置を決定する。この
分散ポリシー情報テーブル６６の内容は，図２の複数の負荷分散装置（Ｌ．Ｂ．）２５ａ，２５ｂ，・・・のいずれにおいても同じである。
　上記ア，上記イの【００３５】の記載によれば，
「複数の負荷分散装置において，ハッシュ関数を使用してパケットの転送先のターゲットを選択すること。」は公知であると認められる（以下，「公知事項１」という。）。
　上記イの【００５１】，上記ウの記載によれば，
「負荷分散に際し，複数の負荷分散装置で，共通のハッシュ関数を使用したり，同じ負荷分散ポリシーを用いること。」は公知であると認められる（以下，「公知事項２」という。）。
（２）対比
　補正後の発明と引用発明とを対比すると，
ア　引用発明の「ネットワーク負荷分散方法」は，処理デバイスによってプログラムが実行されることにより当該方法が実行されると解するのが自然であるから，これを「処理デバイスによって実行されると，該処理デバイスに負荷分散方法を実行させるプログラム」と称することは任意である。
イ　引用発明の「複数の負荷分散ユニット」は，「一連のモジュール」といえる。また，引用発明の「入力ネットワークトラフィックに係るパケット」は，補正後の発明の「ネットワークパケット」に相当する。
　したがって，引用発明の「ルータ／スイッチが複数の負荷分散ユニットの間で入力ネットワークトラフィックに係るパケットを分配し」は，補正後の発明の「一連のモジュール間にネットワークパケットを拡散するステップ」に相当する。
ウ　引用発明の「ターゲットホスト」は，補正後の発明の「ターゲットデバイス」に相当する。
　したがって，補正後の発明の「前記一連のモジュールの個々のモジュールにおいて，受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップであって，前記一連のモジュールは同じハッシュ関数を使用するように構成され，前記個々のモジュールは，前記ハッシュ関数を使用して，ネットワークパケットを転送すべきターゲットデバイスを選択する，ステップ」と，引用発明の「前記複数の負荷分散ユニットの個々の負荷分散ユニットにおいて，受信した個々のパケットを転送すべきターゲットホストを，収集したホスト状態情報に基づいて選択し」とは，以下の相違点１は別として，「前記一連のモジュールの個々のモジュールにおいて，受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップ」の点で共通している。
　また，引用発明の「前記カプセル化されたパケットを前記個々の負荷分散ユニットから前記ターゲットホストに対して転送する」は，補正後の発明の「前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップ」に相当する。
エ　引用発明の「フォワーダのＩＰアドレス「Ｆ」」，「ターゲットホストのＩＰアドレス「Ｈ」」は，それぞれ補正後の発明の「個々のモジュールに関連するソースアドレス」，「ターゲットデバイスに関連する宛先アドレス」に相当する。
　したがって，補正後の発明の「前記個々のモジュールにおいて，前記個々のネットワークパケットのソースアドレスと宛先アドレスとを保存するように，前記個々のネットワークパケットをカプセル化するステップであって，カプセル化されたパケットは，前記個々のモジュールに関連するソースアドレスと，前記ターゲットデバイスに関連する宛先アドレスとによって，前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットをカプセル化することによって生成される，ステップ」と，引用発明の「前記個々の負荷分散ユニットにおいて，個々のパケットをカプセル化し，カプセル化されたパケットは，ＴＣＰ／ＩＰ４タプルヘッダの発信元ＩＰアドレス部分に関してフォワーダのＩＰアドレス「Ｆ」が挿入され，宛先ＩＰアドレス部分に関してターゲットホストのＩＰアドレス「Ｈ」が挿入され」とは，以下の相違点２は別として，「前記個々のモジュールにおいて，前記個々のネットワークパケットをカプセル化するステップであって，カプセル化されたパケットは，前記個々のモジュールに関連するソースアドレスと，前記ターゲットデバイスに関連する宛先アドレスを有する，ステップ」の点で共通している。
　以上を総合すると，本願発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「処理デバイスによって実行されると，該処理デバイスに負荷分散方法を実行させるプログラムであって，前記方法が，
　一連のモジュール間にネットワークパケットを拡散するステップと，
　前記一連のモジュールの個々のモジュールにおいて，受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップと，
　前記個々のモジュールにおいて，前記個々のネットワークパケットをカプセル化するステップであって，カプセル化されたパケットは，前記個々のモジュールに関連するソースアドレスと，前記ターゲットデバイスに関連する宛先アドレスを有する，ステップと，
　前記カプセル化されたパケットを前記個々のモジュールから前記ターゲットデバイスに対して転送するステップと
　を含む，プログラム。」
（相違点１）
　一致点の「前記一連のモジュールの個々のモジュールにおいて，受信した個々のネットワークパケットを転送すべきターゲットデバイスを選択するステップ」に関し，補正後の発明は，「前記一連のモジュールは同じハッシュ関数を使用するように構成され，前記個々のモジュールは，前記ハッシュ関数を使用して，ネットワークパケットを転送すべきターゲットデバイスを選択する」であるのに対し，引用発明は収集したホスト状態情報に基づいてターゲットホストを選択するものであって，補正後の発明の上記構成を有していない点。
（相違点２）
　一致点の「前記個々のモジュールにおいて，前記個々のネットワークパケットをカプセル化するステップであって，・・・，ステップ」に関し，補正後の発明は，「カプセル化されたパケットは，前記個々のモジュールに関連するソースアドレスと，前記ターゲットデバイスに関連する宛先アドレスとによって，前記保存されたソースアドレスと保存された宛先アドレスを有する前記個々のネットワークパケットをカプセル化することによって生成される」のに対し，引用発明は，当該事項が明らかでない点。
（３）判断
　上記相違点について検討する。
（相違点１について）
　公知技術１のとおり，「複数の負荷分散装置において，ハッシュ関数を使用してパケットの転送先のターゲットを選択すること。」は公知であり，また，公知事項２のとおり，「負荷分散に際し，複数の負荷分散装置で，共通のハッシュ関数を使用したり，同じ負荷分散ポリシーを用いること。」も公知である。
　しかしながら，引用発明は，従来の「ラウンドロビン負荷分散分配は，通常は，パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく利用される」という課題を解決することを目的として，ホスト状態情報を用いてネットワーク負荷分散を行うものである。
　そして，ハッシュ関数を使用してパケットの転送先のターゲットを選択することは，パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく分散することとなることから，引用発明の「前記複数の負荷分散ユニットの個々の負荷分散ユニットにおいて，受信した個々のパケットを転送すべきターゲットホストを，収集したホスト状態情報に基づいて選択」することに替えて，当該公知技術を採用することは，引用発明の課題が達成されないこととなるから，組み合わせの動機付けを欠くものである。すなわち，引用発明を出発点として，補正後の発明をすることはできない。
　なお，引用例の【０２２１】，【０２２５】〜【０２５７】，【０２３１】には，ＤＡＭに関して位置選択のためのハッシュ化をすることが記載されているが，当該開示内容はハッシュ関数を使用してパケットの転送先のターゲットを選択するものではない。
　したがって，相違点２について検討するまでもなく，補正後の発明は，引用発明及び公知技術に基いて当業者が容易に発明をすることができたものとはいえない。
　また，補正後の発明を異なるカテゴリーとして表現した請求項７，９に係る発明についても，同様に，引用発明及び公知技術に基いて当業者が容易に発明をすることができたものとはいえない。
３　むすび
　本件補正は，特許法第１７条の２第３項〜第６項の規定に適合する。
第３　本願発明
　本件補正は上記のとおり，特許法第１７条の２第３項〜第６項の規定に適合するから，本願の請求項１〜１０に係る発明は，本件補正により補正された特許請求の範囲の請求項１〜１０に記載された事項により特定されるとおりのものである。
　そして，本願については，原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。