【事件の表示】
　特願２０１０−　３５３２２「コンピュータシステム、コントローラ、サービス提供サーバ、及び負荷分散方法」拒絶査定不服審判事件〔平成２３年　９月　１日出願公開、特開２０１１−１７０７１８、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯　
 　本件審判請求に係る出願（以下，「本願」という。）は，平成２２年２月１９日の出願であって，その手続の経緯は以下のとおりである。 
 拒絶理由の通知　　　　（起案日）平成２５年１１月１９日 
 意見書の提出　　　　　（提出日）平成２６年　１月　８日 
 拒絶理由の通知　　　　（起案日）平成２６年　１月３１日 
 意見書の提出　　　　　（提出日）平成２６年　３月２８日 
 拒絶査定　　　　　　　（起案日）平成２６年　４月２５日 
 同　謄本送達　　　　　（送達日）平成２６年　５月　２日 
 審判請求　　　　　　　（提出日）平成２６年　７月２８日 
　
第２　本願発明　
　
　本願の特許請求の範囲の請求項１−１０に係る発明（以下，請求項１に係る発明を「本願発明」という。）は，上記平成２２年２月１９日付け願書に最初に添付した明細書，特許請求の範囲及び図面の記載からみて，その特許請求の範囲の請求項１−１０に記載された以下のとおりのものと認める。
「【請求項１】
　通信経路上のスイッチに対して，フローエントリを設定するコントローラと，
　前記コントローラによって設定されたフローエントリに従って，受信パケットの中継処理を行うスイッチと，
　前記スイッチを介して自身に接続された複数のクライアント端末のそれぞれに対して，サービスを提供する複数のサービス提供サーバと，
　ラウンドロビン機能によって，前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバと
　を具備し，
　前記複数のサービス提供サーバのそれぞれは，それぞれの負荷状況を監視し，自身に対する負荷が閾値以上であると判定すると，負荷分散要求を前記コントローラに発行し，
　前記コントローラは，前記負荷分散要求に応じて，前記スイッチに設定したフローエントリを変更する
　コンピュータシステム。
【請求項２】
　請求項１に記載のコンピュータシステムにおいて，
　前記コントローラは，前記負荷分散要求の要求元サーバへの負荷を軽減させるためのフローエントリを前記スイッチに設定する
　コンピュータシステム。
【請求項３】
　請求項２に記載のコンピュータシステムにおいて，
　前記要求元サーバは，自身に接続中のクライアント端末のアドレスを前記コントローラに通知し，
　前記コントローラは，前記通知されたアドレス以外のアドレスを送信元アドレスとしたパケットデータが，前記要求元サーバ以外のサービス提供サーバに到達するように，前記スイッチに設定したフローエントリを変更する
　コンピュータシステム。
【請求項４】
　請求項３に記載のコンピュータシステムにおいて，
　前記コントローラは，前記通知されたアドレスを送信元アドレスとしたパケットデータが，前記要求元サーバに到達するように，前記スイッチに設定したフローエントリを変更する
　コンピュータシステム。
【請求項５】
　請求項１から４のいずれか１項に記載のコンピュータシステムにおいて，
　前記複数のサービス提供サーバのそれぞれは，自身への同時接続数を監視し，前記同時接続数が閾値以上であると判定した場合，前記負荷分散要求を前記コントローラに発行する
　コンピュータシステム。
【請求項６】
　請求項１から５のいずれか１項に記載のコンピュータシステムにおいて，
　前記負荷分散要求を発行した要求元サーバは，前記負荷が前記閾値を下回った場合，設定復帰要求を前記コントローラに発行し，
　前記コントローラは，前記負荷分散要求に応じて，変更した前記スイッチのフローエントリを元のフローエントリに戻す
　コンピュータシステム。
【請求項７】
　請求項１から６のいずれか１項に記載のコンピュータシステムにおいて，
　前記複数のサービス提供サーバは，１つのホスト名が割り当てられた仮想サーバを形成し，
　前記複数のサービス提供サーバのそれぞれには，複数のＩＰアドレスが割り当てられる
　コンピュータシステム。
【請求項８】
　請求項１から７のいずれか１項に記載のコンピュータシステムで利用されるコントローラ。
【請求項９】
　請求項１から７のいずれか１項に記載のコンピュータシステムで利用されるサービス提供サーバ。
【請求項１０】
　コントローラが，通信経路上のスイッチに対して，フローエントリを設定するステップと，
　スイッチが，前記コントローラによって設定されたフローエントリに従って，受信パケットの中継処理を行うステップと，
　複数のサービス提供サーバのそれぞれが，前記スイッチを介して自身に接続された複数のクライアント端末のそれぞれに対して，サービスを提供するステップと，
　ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバが，ラウンドロビン機能によって，前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うステップと，
　前記複数のサービス提供サーバのそれぞれが，それぞれの負荷状況を監視するステップと，
　前記複数のサービス提供サーバのそれぞれが，自身に対する負荷が閾値以上であると判定すると，負荷分散要求を前記コントローラに発行するステップと，
　前記コントローラが，前記負荷分散要求に応じて，前記スイッチに設定したフローエントリを変更するステップと
　を具備する
　負荷分散方法。」
第３　原査定の理由の概要
　
１．平成２６年１月３１日付け拒絶理由通知 
　
　平成２６年１月３１日付けで拒絶理由が通知されたが，その内容は下記のとおりである。
「この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　　　　記
≪引用文献等一覧≫
１．山名  早人，サーチエンジンＧｏｏｇｌｅ，情報処理，日本，社団法人情報 処理学会，２００１年　８月１５日，第４２巻 第８号 通巻４３８号，ｐ．７７５−７８０
２．上野  洋史，データセンターネットワークにおけるネットワークアプライアンス機能配備の一検討，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２００９年１１月１３日，Ｖｏｌ．１０９  Ｎｏ．２９６，ｐ．７−１２
３．特開２００４−３５００７８号公報
［請 求 項］１−１０
［引用文献］１−３
　引用文献１（第７７６頁右欄第６行−第７７７頁左欄第２８行等参照）には，
　複数のデータセンターを有するシステムであって，
　クライアントからのアクセスを，ラウンドロビンDNSを用いて各データセンターに分散し，
　更に，何らかの方法により，各データセンター内のＰＣを用いて，各データセンタ内での負荷分散処理をする，
　システムの発明が記載されている。
　請求項１に係る発明と引用文献１に記載の発明を対比すると以下の点で相違する。
（１）請求項１に係る発明は，オープンフローによって制御され，各サービス提供サーバは，自身の負荷状況を監視し，当該負荷状況が閾値以上であると判定すると負荷分散要求をコントローラに要求することで，負荷状況に応じてフローエントリを変更するものであるのに対し，引用文献１に記載の発明は，そのようなものではなく，また，ラウンドロビンＤＮＳで負荷を分散した後の，各データセンター内での負荷分散処理方法が不明である点。
　次に，上記相違点について検討する。
（１）フローエントリを有するスイッチやコントローラによるオープンフローによってデータセンターを制御して負荷分散を行うことは，例えば引用文献２（「３．３．スケールアウト処理」，図１−４等参照）に記載されているように周知技術である。また，自身の負荷が閾値以上になったときに負荷分散を要求することで，処理があまり割り振られないようにすることは，例えば引用文献３（【００１２】−【００１４】，【００３１】−【００３６】等参照）に記載されているように周知技術である。
　したがって，引用文献１に記載の発明にこれらの周知技術を適用し，各データセンターを，フローエントリを有するスイッチやコントローラによるオープンフローによって制御するようにし，各ＰＣが自身の負荷が閾値以上になったときに負荷分散を要求して当該ＰＣに処理があまり割り振られないようすることで，各データセンター内での負荷分散処理を行うようにすることは，当業者が容易になし得たことである。（これにより，ラウンドロビン機能による負荷分散を実行しながら，負荷集中の検出に応じてオープンフローによる負荷分散を実行することができるといえる。）
　よって，請求項１に係る発明は，引用文献１に記載の発明および引用文献２−３に記載の周知技術に基づいて，当業者が容易に想到し得たものである。
　また，請求項２−１０についても同様である。
　拒絶の理由が新たに発見された場合には拒絶の理由が通知される。」
２．平成２６年４月２５日付け拒絶査定 
　
　平成２６年４月２５日付けで拒絶査定がなされたが，その内容は下記のとおりである。
「この出願については，平成２６年　１月３１日付け拒絶理由通知書に記載した理由によって，拒絶をすべきものです。
　なお，意見書の内容を検討しましたが，拒絶理由を覆すに足りる根拠が見いだせません。
備考
　請求項１−１０について
　出願人は，平成２６年３月２８日付け意見書において以下の点を主張している。
「引用文献２の負荷分散方法に引用文献３の方法を適用すると，「負荷が閾値以上となったＰＣの負荷分散要求に応じて，オープンフローによる負荷分散が行われるシステム」が想到され得ます。しかし，引用文献３において，負荷分散要求前には，他の方法による負荷分散が実施されていることは記載されていないため，引用文献２，３を組み合わせても「負荷分散Ａを行いながら，閾値以上の負荷の検出をトリガとして，実行中の負荷分散と異なる負荷分散Ｂを実行すること」
は実現できません。
　引用文献１には，データセンタ単位で負荷分散Ａ（ラウンドロビンＤＮＳ）が行われ，次にクラスタへと負荷分散Ｂ（何等かの方法）が行われることが記載されています。これは時系列的に負荷分散方法が追加されることを示しているわけではなく，負荷分散Ａと負荷分散Ｂが併用されていることを示しているものと思料します。すなわち，引用文献１にも，「負荷分散Ａを行いながら，閾値以上の負荷の検出をトリガとして，実行中の負荷分散Ａとは異なる負荷分散Ｂを実行する」構成は，その示唆も含めて記載されていないものと思料します。
　引用文献１から３を組み合わせた場合，「負荷が閾値以上となったＰＣからの負荷分散要求に応じて，ラウンドロビンＤＮＳによる負荷分散とオープンフローによる負荷分散が開始される」構成となり，本願発明の構成「ＤＮＳサーバによる負荷分散中，サーバの負荷状況に応じてオープンフローコントローラによる負荷分散を実行する」とは相違するものと思料します。又，引用文献１に記載のシステムでは，複数の負荷分散方法を併用していますが，その一方にオープンフローを利用した負荷分散（引用文献２）を採用した場合，オープンフローコントローラにおける通信経路の変更処理に係る処理負荷が増大する恐れがあります。一方，本願発明では，複数の負荷分散方法を併用するタイミングをサーバへの負荷集中に応じておこなっているため，オープンフローコントローラにおけるフロー制御に係る処理負荷の増大を軽減することもできます。このような効果は，引用文献１，２にはその示唆も含めて記載されていません。更に，引用文献３には，「自身の負荷が閾値以上になったときに負荷分散を要求することで，処理があまり割り振られないようにすること」が記載されていますが，本願発明のように，「フロー制御に係る処理負荷の増大を軽減すること」は，その示唆も含めて記載されていません。
　以上のように，引用文献１から３のいずれにも，「負荷分散中の負荷状況に応じて，当該負荷分散の方法と異なるオープンフローによる負荷分散を実行する」という技術的思想や，「フロー制御の処理負荷量を軽減しながら，ＤＮＳサーバによる負荷分散の強化を行う」とした効果は，その示唆も含めて開示されていないものと思料します（又，周知技術でもありません）。従いまして，当業者が，引用文献１〜３のいずれか又は周知技術を組み合わせて，本願発明を想到することは困難であるものと思料します。」
　上記主張について検討する。
　引用文献１に記載の発明は，データセンタ単位で負荷分散Ａ（ラウンドロビンＤＮＳ）が行われ，次に各データセンタ内で負荷分散Ｂ（何等かの方法）が行われるものである。そして，引用文献２には，データセンタにおけるオープンフローを利用した負荷分散方法の周知技術，引用文献３には，負荷が閾値以上となったときに負荷分散を要求することで，あまり処理が割り振られないようにする周知技術が記載されているものである。
　してみると，引用文献１に記載の発明の各データセンタ内での負荷分散Ｂ（何等かの方法）として，上記周知技術を採用して，データセンタ単位で負荷分散Ａ（ラウンドロビンＤＮＳ）を行い，各データセンタ内では，各々，フローエントリを有するスイッチやコントローラによるオープンフローによって制御するようにし，各ＰＣが自身の負荷が閾値以上になったときに負荷分散を要求して当該ＰＣに処理があまり割り振られないようすることで，各データセンタ内での負荷分散処理を行うようにすることは当業者が容易になし得たことである。
　出願人は，引用文献１から３を組み合わせた場合，「負荷が閾値以上となったＰＣからの負荷分散要求に応じて，ラウンドロビンＤＮＳによる負荷分散とオープンフローによる負荷分散が開始される」構成となる旨を主張しているが，上述のように，引用文献１に記載の発明において具体的な負荷分散方法が不明だった負荷分散Ｂとして，引用文献２−３に記載されているような周知技術を採用すれば，出願人の主張するような構成ではなく，本願発明に相当する構成になるといえる。（このように構成すれば，ラウンドロビンＤＮＳによる負荷分散が行われているときに，ＰＣの負荷状況に応じて各データセンタ内での負荷分散が行われるので，時系列的に負荷分散方法が追加されているといえるし，ＰＣの負荷状況に応じてオープンフローによる負荷分散を行うことで過度な処理負荷が発生しないことは，当然に予想される効果であって顕著な効果であるともいえない。）
　したがって，請求項１−１０に係る発明は，引用文献１に記載の発明および引用文献２−３に記載の周知技術に基づいて，依然として当業者が容易に想到し得たものである。
≪引用文献等一覧≫
１．山名  早人，サーチエンジンＧｏｏｇｌｅ，情報処理，日本，社団法人情報処理学会，２００１年　８月１５日，第４２巻 第８号 通巻４３８号，ｐ．７７５−７８０
２．上野  洋史，データセンターネットワークにおけるネットワークアプライアンス機能配備の一検討，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２００９年１１月１３日，Ｖｏｌ．１０９  Ｎｏ．２９６，ｐ．７−１２
３．特開２００４−３５００７８号公報」
第４　当審の判断
　
１．引用文献　
　
（１−１）引用文献１に記載されている技術的事項及び引用発明
　
　本願の出願日前に頒布され，原審の平成２６年１月３１日付けの拒絶理由通知において引用された，「山名  早人，サーチエンジンＧｏｏｇｌｅ，情報処理，日本，社団法人情報処理学会，２００１年　８月１５日，第４２巻 第８号 通巻４３８号，ｐ．７７５−７８０」（以下，「引用文献１」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「2001年3月末現在，シリコンバレーに2カ所，シカゴ，アトランタ，ニューヨークにそれぞれ1カ所の
合計5カ所にデータセンターを設置し，各データセンターが1,000〜3,000台規模のPCを備える。世界中からのアクセスは，これらのデータセンター単位で分散され
14
，次に各データセンター内のクラスタへと負荷分散がなされる
15
14
 ラウンドロビンDNSを用いる。
15 
データセンター内での負荷分散は，Custom load-balancing softwareにより行われているが，技術的詳細は公開されておらず不明
　ここで，上記引用文献１に記載されている事項を検討する。
　上記Ａの「合計5カ所にデータセンターを設置し，各データセンターが1,000〜3,000台規模のPCを備える。世界中からのアクセスは，これらのデータセンター単位で分散され14，次に各データセンター内のクラスタへと負荷分散がなされる15」，「14 ラウンドロビンDNSを用いる」及び「15 データセンター内での負荷分散は，Custom load-balancing softwareにより行われているが，技術的詳細は公開されておらず不明」との記載からすると，ここでいう「世界中からのアクセス」とは，クライアントからのアクセスであることは自明であり，またデータセンター内の複数のＰＣにおいても何らかの方法で負荷分散が行われていることから，引用文献１には次の発明（以下，「引用発明」という。）が記載されているものと認められる。
「複数のデータセンターを有するシステムであって，
　クライアントからのアクセスを，ラウンドロビンDNSを用いて各データセンターに分散し，
　更に，何らかの方法により，各データセンター内の複数のＰＣを用いて，各データセンタ内での負荷分散処理をする，システム。」
（１−２）引用文献２に記載されている技術的事項
　本願の出願日前に頒布され，原審の平成２６年１月３１日付けの拒絶理由通知において引用された，「上野  洋史，データセンターネットワークにおけるネットワークアプライアンス機能配備の一検討，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２００９年１１月１３日，Ｖｏｌ．１０９  Ｎｏ．２９６，ｐ．７−１２」（以下，「引用文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｂ　「２．１．ＯｐｅｎＦｌｏｗによるネットワーク制御
　ＯｐｅｎＦｌｏｗはパケットスイッチ処理を行うデータプレーン処理と，パケットスイッチ処理の経路制御を行う制御プレーン処理を分割したアーキテクチャをとっており，データプレーン処理と制御プレーン処理の間をオープンなインタフェースで接続する（図１）。
ネットワーク上に配備されるスイッチと，そのスイッチを制御するコントローラを分離した構成をとり，ネットワーク転送処理方法はコントローラで決定する。
　
ＯｐｅｎＦｌｏｗでは，パケットスイッチを行うために，パケットのヘッダ（レイヤ２，レイヤ３，レイヤ４）情報を検索キーとしてフローテーブルを検索し，スイッチの宛先，出力アクションを決定する。
　このようなＯｐｅｎＦｌｏｗをベースとしたネットワークでは，ＯｐｅｎＦｌｏｗを制御するコントローラ上のソフトウェア処理によって，ネットワークの経路，転送方法を制御することができる．」（第８頁右欄第６行目〜第９頁左欄第８行目））
Ｃ　「３．３．スケールアウト処理
　本節では，本システムでスケールアウトを達成できる仕組みを，ロードバランサを例に説明する。
　図３の構成では，仮想ＩＰアドレスＶＩＰ１で識別される仮想ロードバランサを１つ定義し，これを物理ロードバランサ２台にマッピングして実現している．ＯｐｅｎＦｌｏｗスイッチに対して，２台の物理ロードバランサヘトラヒックを振り分けるためのフローエントリが設定されている。入力パケットヘッダのソースＩＰを条件に用いることで，ＯｐｅｎＦｌｏｗスイッチのハードウェア転送のみで高速な振り分けが可能である。またコントローラにパケットが到達しないので，コントローラがボトルネックになることもない。
　次に，仮想フロントエンドの性能が不足したために，物理フロントエンドのリソースを増設する場合について説明する．運用者は仮想フロントエンドと物理フロントエンドのマッピングを変更することで，物理フロントエンドのリソースを増加させる。
　新しく追加した物理フロントエンドには既存の物理フロントエンドと同一の設定を行い，新規に割り当てた物理フロントエンドにトラヒックが流れるようにスイッチのフローエントリを書き換える。ただし，単純に書き換えたのでは，セッションが切断されてしまう場合があるため，ＯｐｅｎＦｌｏｗを利用しマイクロフローによる動的な制御を併用する。
いま，仮想ＩＰアドレスＶＩＰ１で識別される
１つの仮想ロードバランサを１台の物理ロードバランサＬＢ１にマッピングしているとき，これを２台の物理ロードバランサＬＢ１，ＬＢ２に分散させるように変更するスケールアウト処理を考える。
　新規セッションであれば，パケットのソースＩＰを調べ，変更後の振り分けルールに従ってＬＢ１またはＬＢ２に転送するようスイッチに指示を出す。
　一方，既存セッションであったなら，ＬＢ１へのマイクロフローをスイッチに登録する（図４（ｃ））。このマイクロフローは，集約フローよりも高い優先度としておく。これによりそのクライアントセッションは引き続きＬＢ１で処理されるので，セッションが切断されることなく，かつコントローラにパケットが上がってこなくなる。
　スケールアウト処理を開始してから，物理ロードバランサのセッションタイムアウト時間が経過したら，変更後の集約フローをスイッチに登録する。」（第１０頁右欄第１行目〜第１１頁左欄第２０行目））
（１−３）引用文献３に記載されている技術的事項
　
　本願の出願日前に頒布され，原審の平成２６年１月３１日付けの拒絶理由通知において引用された，特開２００４−３５００７８号公報（平成１６年１２月９日出願公開，以下，「引用文献３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。　
　（当審注：下線は，参考のために当審で付与したものである。）
Ｄ　「【００１２】
【課題を解決するための手段】
本発明の方路分散伝送システムは，図１を参照して説明すると，等コスト・マルチパス方式を適用した方路分散伝送システムであって，
出力物理ポート３の出力バッファ１０の使用量又はパケットの流量が予め設定した閾値を超えたか否かを検出する回線負荷状態検出部９と，この回線負荷状態情報検出部９により検出した負荷状態情報を記憶し，この負荷状態情報を参照して，過負荷状態の出力物理ポートを回避して方路分散処理を行う方路決定部５
【００１３】
又方路決定部５は，出力物理ポート３対応の回線負荷状態情報検出部９からの負荷状態情報を記憶する出力ポート負荷状態情報記憶部７と，この出力ポート負荷状態情報記憶部７を参照し過負荷状態の出力物理ポートを回避するように等コスト・マルチパス・グループ内の出力物理ポートを順次指定するラウンドロビン・テーブルを備えている。
【００１４】
又回線負荷状態検出部９は，出力バッファ１０の使用量が閾値を超えた時に過負荷状態と判定し，この判定した信号を所定のサンプリング間隔でサンプリングして保持し，この保持した信号を負荷状態情報とする構成を有し，出力物理ポート３対応の負荷状態情報を収集して，方路決定部５の出力ポート負荷状態情報記憶部７に同報転送する同報部８を備えている。」
Ｅ　「【００３１】
図７は，図３に於ける方路決定部２５の説明図であり，ラウンドロビン・テーブル５４と出力ポート負荷状態情報記憶部５５とを含む構成を示す。この出力ポート負荷状態情報記憶部５５は，図１に於ける出力ポート負荷状態情報記憶部７に相当するものである。又ラウンドロビン・テーブル５４は，例えば，ＥＣＭＰグループＥＣＭＰ＃１に出力物理ポートの番号ｐｏｒｔ＃０，ｐｏｒｔ＃１，ｐｏｒｔ＃２が属し，ＥＣＭＰグループＥＣＭＰ＃２にｐｏｒｔ＃２，ｐｏｒｔ＃６，  ｐｏｒｔ＃７，  ｐｏｒｔ＃９が属し，ＥＣＭＰグループＥＣＭＰ＃３にｐｏｒｔ＃１，  ｐｏｒｔ＃ｎが属す場合を示している。
【００３２】
又出力ポート負荷状態情報記憶部５５は，同報部２９から同報転送された負荷状態情報を記憶するものであり，出力ポート番号ｐｏｒｔ＃０，ｐｏｒｔ＃１，ｐｏｒｔ＃２，・・・対応に，過負荷状態を例えば”１”，それ以外を”０”として格納し，図示の場合は，出力ポート番号ｐｏｒｔ＃１が過負荷状態であり，他の出力ポート番号対応には過負荷状態ではないとを示す”０”が格納されている。
【００３３】
又ラウンドロビン・テーブル５４は，例えば，図１のＥＣＭＰ経路テーブル６によるＥＣＭＰグループ番号に従って出力ポート番号を出力し，図１に於いてはルーティング検索部４へ転送し，図３に於いては，フォワーディング・エンジン２６に転送する。例えば，
パケットのヘッダ情報に従ったＥＣＭＰグループ番号ＥＣＭＰ＃１が入力されると，ラウンドロビン・テーブル５４を検索する。この場合，出力ポート負荷状態情報記憶部５５に過負荷状態の情報が記憶されていないとすると，ポインタにより矢印で順序を示すように，グループ内の出力ポート番号が順次指定される。即ち，ｐｏｒｔ＃０→ｐｏｒｔ＃１→ｐｏｒｔ＃２→ｐｏｒｔ＃１のように，等コストの回線に対応する出力ポート番号が順次選択されて，方路分散処理が行われる。
【００３４】
しかし，出力ポート負荷状態情報記憶部５５には，ポート番号ｐｏｒｔ＃１は過負荷状態として記憶されているから，ラウンドロビン・テーブル５４のポインタ制御により，このポート番号ｐｏｒｔ＃１を除く，ｐｏｒｔ＃０→ｐｏｒｔ＃２→ｐｏｒｔ＃０→ｐｏｒｔ＃２のように，方路分散処理が行われる。又過負荷状態から通常の負荷状態となると，同報部からの負荷状態情報を受信して，最初の方路分散処理が行われる。
【００３５】
図８は前述の方路決定処理のフローチャートを示し，方路決定部２５は，フォワーディング・エンジン２６（ＦＥ（Ｉ））（図３参照）からＥＣＭＰグループ番号（ＥＣＭＰ  ｇｒｐ  Ｎｏ．）を受信すると（Ｃ１），ラウンドロビン・テーブル５４を検索し（Ｃ２），ラウンドロビン・テーブル５４のポインタが，ＥＣＭＰグループ（ＥＣＭＰ  ｇｒｐ）の末尾を示しているか否かを判定し（Ｃ３），末尾を示している場合は，ポインタをＥＣＭＰグループの先頭に戻し（Ｃ４），末尾を示していない場合は，現在のポインタを一つ進める（Ｃ５）。
【００３６】
そして，ポインタが示す出力ポート（ｐｏｒｔ）は，過負荷状態か否かを出力ポート負荷状態情報記憶部５５を参照して判定し（Ｃ６），過負荷状態の場合（負荷状態情報＝”１”）は，ステップ（Ｃ７）に移行し，過負荷状態でない場合（負荷状態情報＝”０”）は，ポインタにより指示された出力ポート番号（ｐｏｒｔ  Ｎ０．）を，フォワーディング・エンジン２６（ＦＥ（Ｉ））に転送する。このような処理により，過負荷状態でない出力ポート番号に対してパケットを振り分けるもので，負荷分散処理が行われることになる。」
２．対比
　
　本願発明と引用発明とを対比する。　
　
（２−１）引用発明の「クライアント」は，本願発明の「クライアント端末」に相当する。
（２−２）引用発明の「複数のＰＣ」は，クライアントからのアクセスに基づいて処理を行うものであるから，本願発明の「サービス提供サーバ」とは「自身に接続された複数のクライアント端末のそれぞれに対して，サービスを提供する複数のサービス提供サーバ」と言えるものである点で共通する。
（２−３）引用発明は「ラウンドロビンDNS」を用いて負荷分散を行っていることから，本願発明の「ラウンドロビン機能によって，前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバ」に相当する構成を有している。
　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
（一致点） 
「自身に接続された複数のクライアント端末のそれぞれに対して，
サービスを提供する複数のサービス提供サーバと，
　ラウンドロビン機能によって，前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバと
　を具備したシステム。」
（相違点１）
　本願発明の，「通信経路上のスイッチに対して，フローエントリを設定するコントローラ」及び「前記コントローラによって設定されたフローエントリに従って，受信パケットの中継処理を行うスイッチ」の構成について，引用発明では言及されていない点。
（相違点２）
　本願発明の，「複数のサービス提供サーバのそれぞれは，それぞれの負荷状況を監視し，自身に対する負荷が閾値以上であると判定すると，負荷分散要求を前記コントローラに発行し，
　前記コントローラは，前記負荷分散要求に応じて，前記スイッチに設定したフローエントリを変更する」構成について，引用発明では言及されていない点。
３．判断
　
　上記相違点１及び相違点２について検討する。
　
（１）相違点１について
　引用発明では「スイッチ」及び「コントローラ」について言及されていない点で，本願発明と相違することは上記のとおりである。
　これに対して，原審において引用された引用文献２には，上記Ｂ乃至Ｃの記載からすると，「スイッチ」及び「コントローラ」を用いて負荷分散を行うことが記載されていると解せられ，これはＯｐｅｎＦｌｏｗ技術として周知のものであると解せられ，引用発明においてこの周知技術を適用し，相違点１の構成とすることは，当業者であれば容易になし得たものである。
（２）相違点２について
　引用発明では，サーバが負荷状況を監視し，自身に対する負荷が閾値以上であると判定すると負荷分散要求を発行することが言及されていない点で，本願発明と相違することは上記の通りである。
　これに対して，原審において引用された引用文献３には，上記Ｄ乃至Ｅの記載からすると，出力バッファの負荷状態情報を参照して過負荷状態の出力ポートを回避する負荷分散方法は記載されているものの，「スイッチ」や「コントローラ」に関しては，記載も示唆もされていない。
　よって，引用文献３に記載の負荷分散方法を引用文献２に記載の「スイッチ」及び「コントローラ」に適用し，さらにこれを引用発明に適用することには論理に飛躍があり，当業者が相違点２の構成とすることは容易になし得たものとはいえない。
４．まとめ
　
　以上のとおりであるから，本願の請求項１に係る発明は，引用発明，引用文献２及び引用文献３に記載の技術的事項及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものとすることができないものである。
５．請求項２乃至１０に係る発明について
　本願の請求項２−９に係る発明は，本願発明をさらに限定したものであり，また請求項１０に係る発明は，請求項１に係る発明を方法の発明として記載したものであるので，本願発明と同様に，当業者が容易に発明をすることができたとはいえない。
第５　むすび
　
　以上のとおり，本願の請求項１乃至１０に係る発明は，引用発明，引用文献２及び引用文献３に記載の技術的事項及び周知技術に基づいて，当業者が容易に発明をすることができたものとすることができないから，原査定の理由によっては，本願を拒絶することはできない。
　
　また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。