ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
---|---|
管理番号 | 1299657 |
審判番号 | 不服2014-14712 |
総通号数 | 186 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2015-06-26 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2014-07-28 |
確定日 | 2015-05-07 |
事件の表示 | 特願2010- 35322「コンピュータシステム、コントローラ、サービス提供サーバ、及び負荷分散方法」拒絶査定不服審判事件〔平成23年 9月 1日出願公開、特開2011-170718、請求項の数(10)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本件審判請求に係る出願(以下,「本願」という。)は,平成22年2月19日の出願であって,その手続の経緯は以下のとおりである。 拒絶理由の通知 (起案日)平成25年11月19日 意見書の提出 (提出日)平成26年 1月 8日 拒絶理由の通知 (起案日)平成26年 1月31日 意見書の提出 (提出日)平成26年 3月28日 拒絶査定 (起案日)平成26年 4月25日 同 謄本送達 (送達日)平成26年 5月 2日 審判請求 (提出日)平成26年 7月28日 第2 本願発明 本願の特許請求の範囲の請求項1-10に係る発明(以下,請求項1に係る発明を「本願発明」という。)は,上記平成22年2月19日付け願書に最初に添付した明細書,特許請求の範囲及び図面の記載からみて,その特許請求の範囲の請求項1-10に記載された以下のとおりのものと認める。 「【請求項1】 通信経路上のスイッチに対して,フローエントリを設定するコントローラと, 前記コントローラによって設定されたフローエントリに従って,受信パケットの中継処理を行うスイッチと, 前記スイッチを介して自身に接続された複数のクライアント端末のそれぞれに対して,サービスを提供する複数のサービス提供サーバと, ラウンドロビン機能によって,前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うDNS(Domain Name System)サーバと を具備し, 前記複数のサービス提供サーバのそれぞれは,それぞれの負荷状況を監視し,自身に対する負荷が閾値以上であると判定すると,負荷分散要求を前記コントローラに発行し, 前記コントローラは,前記負荷分散要求に応じて,前記スイッチに設定したフローエントリを変更する コンピュータシステム。 【請求項2】 請求項1に記載のコンピュータシステムにおいて, 前記コントローラは,前記負荷分散要求の要求元サーバへの負荷を軽減させるためのフローエントリを前記スイッチに設定する コンピュータシステム。 【請求項3】 請求項2に記載のコンピュータシステムにおいて, 前記要求元サーバは,自身に接続中のクライアント端末のアドレスを前記コントローラに通知し, 前記コントローラは,前記通知されたアドレス以外のアドレスを送信元アドレスとしたパケットデータが,前記要求元サーバ以外のサービス提供サーバに到達するように,前記スイッチに設定したフローエントリを変更する コンピュータシステム。 【請求項4】 請求項3に記載のコンピュータシステムにおいて, 前記コントローラは,前記通知されたアドレスを送信元アドレスとしたパケットデータが,前記要求元サーバに到達するように,前記スイッチに設定したフローエントリを変更する コンピュータシステム。 【請求項5】 請求項1から4のいずれか1項に記載のコンピュータシステムにおいて, 前記複数のサービス提供サーバのそれぞれは,自身への同時接続数を監視し,前記同時接続数が閾値以上であると判定した場合,前記負荷分散要求を前記コントローラに発行する コンピュータシステム。 【請求項6】 請求項1から5のいずれか1項に記載のコンピュータシステムにおいて, 前記負荷分散要求を発行した要求元サーバは,前記負荷が前記閾値を下回った場合,設定復帰要求を前記コントローラに発行し, 前記コントローラは,前記負荷分散要求に応じて,変更した前記スイッチのフローエントリを元のフローエントリに戻す コンピュータシステム。 【請求項7】 請求項1から6のいずれか1項に記載のコンピュータシステムにおいて, 前記複数のサービス提供サーバは,1つのホスト名が割り当てられた仮想サーバを形成し, 前記複数のサービス提供サーバのそれぞれには,複数のIPアドレスが割り当てられる コンピュータシステム。 【請求項8】 請求項1から7のいずれか1項に記載のコンピュータシステムで利用されるコントローラ。 【請求項9】 請求項1から7のいずれか1項に記載のコンピュータシステムで利用されるサービス提供サーバ。 【請求項10】 コントローラが,通信経路上のスイッチに対して,フローエントリを設定するステップと, スイッチが,前記コントローラによって設定されたフローエントリに従って,受信パケットの中継処理を行うステップと, 複数のサービス提供サーバのそれぞれが,前記スイッチを介して自身に接続された複数のクライアント端末のそれぞれに対して,サービスを提供するステップと, DNS(Domain Name System)サーバが,ラウンドロビン機能によって,前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うステップと, 前記複数のサービス提供サーバのそれぞれが,それぞれの負荷状況を監視するステップと, 前記複数のサービス提供サーバのそれぞれが,自身に対する負荷が閾値以上であると判定すると,負荷分散要求を前記コントローラに発行するステップと, 前記コントローラが,前記負荷分散要求に応じて,前記スイッチに設定したフローエントリを変更するステップと を具備する 負荷分散方法。」 第3 原査定の理由の概要 1.平成26年1月31日付け拒絶理由通知 平成26年1月31日付けで拒絶理由が通知されたが,その内容は下記のとおりである。 「この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。 記 ≪引用文献等一覧≫ 1.山名 早人,サーチエンジンGoogle,情報処理,日本,社団法人情報 処理学会,2001年 8月15日,第42巻 第8号 通巻438号,p.775-780 2.上野 洋史,データセンターネットワークにおけるネットワークアプライアンス機能配備の一検討,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2009年11月13日,Vol.109 No.296,p.7-12 3.特開2004-350078号公報 [請 求 項]1-10 [引用文献]1-3 引用文献1(第776頁右欄第6行-第777頁左欄第28行等参照)には, 複数のデータセンターを有するシステムであって, クライアントからのアクセスを,ラウンドロビンDNSを用いて各データセンターに分散し, 更に,何らかの方法により,各データセンター内のPCを用いて,各データセンタ内での負荷分散処理をする, システムの発明が記載されている。 請求項1に係る発明と引用文献1に記載の発明を対比すると以下の点で相違する。 (1)請求項1に係る発明は,オープンフローによって制御され,各サービス提供サーバは,自身の負荷状況を監視し,当該負荷状況が閾値以上であると判定すると負荷分散要求をコントローラに要求することで,負荷状況に応じてフローエントリを変更するものであるのに対し,引用文献1に記載の発明は,そのようなものではなく,また,ラウンドロビンDNSで負荷を分散した後の,各データセンター内での負荷分散処理方法が不明である点。 次に,上記相違点について検討する。 (1)フローエントリを有するスイッチやコントローラによるオープンフローによってデータセンターを制御して負荷分散を行うことは,例えば引用文献2(「3.3.スケールアウト処理」,図1-4等参照)に記載されているように周知技術である。また,自身の負荷が閾値以上になったときに負荷分散を要求することで,処理があまり割り振られないようにすることは,例えば引用文献3(【0012】-【0014】,【0031】-【0036】等参照)に記載されているように周知技術である。 したがって,引用文献1に記載の発明にこれらの周知技術を適用し,各データセンターを,フローエントリを有するスイッチやコントローラによるオープンフローによって制御するようにし,各PCが自身の負荷が閾値以上になったときに負荷分散を要求して当該PCに処理があまり割り振られないようすることで,各データセンター内での負荷分散処理を行うようにすることは,当業者が容易になし得たことである。(これにより,ラウンドロビン機能による負荷分散を実行しながら,負荷集中の検出に応じてオープンフローによる負荷分散を実行することができるといえる。) よって,請求項1に係る発明は,引用文献1に記載の発明および引用文献2-3に記載の周知技術に基づいて,当業者が容易に想到し得たものである。 また,請求項2-10についても同様である。 拒絶の理由が新たに発見された場合には拒絶の理由が通知される。」 2.平成26年4月25日付け拒絶査定 平成26年4月25日付けで拒絶査定がなされたが,その内容は下記のとおりである。 「この出願については,平成26年 1月31日付け拒絶理由通知書に記載した理由によって,拒絶をすべきものです。 なお,意見書の内容を検討しましたが,拒絶理由を覆すに足りる根拠が見いだせません。 備考 請求項1-10について 出願人は,平成26年3月28日付け意見書において以下の点を主張している。 「引用文献2の負荷分散方法に引用文献3の方法を適用すると,「負荷が閾値以上となったPCの負荷分散要求に応じて,オープンフローによる負荷分散が行われるシステム」が想到され得ます。しかし,引用文献3において,負荷分散要求前には,他の方法による負荷分散が実施されていることは記載されていないため,引用文献2,3を組み合わせても「負荷分散Aを行いながら,閾値以上の負荷の検出をトリガとして,実行中の負荷分散と異なる負荷分散Bを実行すること」 は実現できません。 引用文献1には,データセンタ単位で負荷分散A(ラウンドロビンDNS)が行われ,次にクラスタへと負荷分散B(何等かの方法)が行われることが記載されています。これは時系列的に負荷分散方法が追加されることを示しているわけではなく,負荷分散Aと負荷分散Bが併用されていることを示しているものと思料します。すなわち,引用文献1にも,「負荷分散Aを行いながら,閾値以上の負荷の検出をトリガとして,実行中の負荷分散Aとは異なる負荷分散Bを実行する」構成は,その示唆も含めて記載されていないものと思料します。 引用文献1から3を組み合わせた場合,「負荷が閾値以上となったPCからの負荷分散要求に応じて,ラウンドロビンDNSによる負荷分散とオープンフローによる負荷分散が開始される」構成となり,本願発明の構成「DNSサーバによる負荷分散中,サーバの負荷状況に応じてオープンフローコントローラによる負荷分散を実行する」とは相違するものと思料します。又,引用文献1に記載のシステムでは,複数の負荷分散方法を併用していますが,その一方にオープンフローを利用した負荷分散(引用文献2)を採用した場合,オープンフローコントローラにおける通信経路の変更処理に係る処理負荷が増大する恐れがあります。一方,本願発明では,複数の負荷分散方法を併用するタイミングをサーバへの負荷集中に応じておこなっているため,オープンフローコントローラにおけるフロー制御に係る処理負荷の増大を軽減することもできます。このような効果は,引用文献1,2にはその示唆も含めて記載されていません。更に,引用文献3には,「自身の負荷が閾値以上になったときに負荷分散を要求することで,処理があまり割り振られないようにすること」が記載されていますが,本願発明のように,「フロー制御に係る処理負荷の増大を軽減すること」は,その示唆も含めて記載されていません。 以上のように,引用文献1から3のいずれにも,「負荷分散中の負荷状況に応じて,当該負荷分散の方法と異なるオープンフローによる負荷分散を実行する」という技術的思想や,「フロー制御の処理負荷量を軽減しながら,DNSサーバによる負荷分散の強化を行う」とした効果は,その示唆も含めて開示されていないものと思料します(又,周知技術でもありません)。従いまして,当業者が,引用文献1?3のいずれか又は周知技術を組み合わせて,本願発明を想到することは困難であるものと思料します。」 上記主張について検討する。 引用文献1に記載の発明は,データセンタ単位で負荷分散A(ラウンドロビンDNS)が行われ,次に各データセンタ内で負荷分散B(何等かの方法)が行われるものである。そして,引用文献2には,データセンタにおけるオープンフローを利用した負荷分散方法の周知技術,引用文献3には,負荷が閾値以上となったときに負荷分散を要求することで,あまり処理が割り振られないようにする周知技術が記載されているものである。 してみると,引用文献1に記載の発明の各データセンタ内での負荷分散B(何等かの方法)として,上記周知技術を採用して,データセンタ単位で負荷分散A(ラウンドロビンDNS)を行い,各データセンタ内では,各々,フローエントリを有するスイッチやコントローラによるオープンフローによって制御するようにし,各PCが自身の負荷が閾値以上になったときに負荷分散を要求して当該PCに処理があまり割り振られないようすることで,各データセンタ内での負荷分散処理を行うようにすることは当業者が容易になし得たことである。 出願人は,引用文献1から3を組み合わせた場合,「負荷が閾値以上となったPCからの負荷分散要求に応じて,ラウンドロビンDNSによる負荷分散とオープンフローによる負荷分散が開始される」構成となる旨を主張しているが,上述のように,引用文献1に記載の発明において具体的な負荷分散方法が不明だった負荷分散Bとして,引用文献2-3に記載されているような周知技術を採用すれば,出願人の主張するような構成ではなく,本願発明に相当する構成になるといえる。(このように構成すれば,ラウンドロビンDNSによる負荷分散が行われているときに,PCの負荷状況に応じて各データセンタ内での負荷分散が行われるので,時系列的に負荷分散方法が追加されているといえるし,PCの負荷状況に応じてオープンフローによる負荷分散を行うことで過度な処理負荷が発生しないことは,当然に予想される効果であって顕著な効果であるともいえない。) したがって,請求項1-10に係る発明は,引用文献1に記載の発明および引用文献2-3に記載の周知技術に基づいて,依然として当業者が容易に想到し得たものである。 ≪引用文献等一覧≫ 1.山名 早人,サーチエンジンGoogle,情報処理,日本,社団法人情報処理学会,2001年 8月15日,第42巻 第8号 通巻438号,p.775-780 2.上野 洋史,データセンターネットワークにおけるネットワークアプライアンス機能配備の一検討,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2009年11月13日,Vol.109 No.296,p.7-12 3.特開2004-350078号公報」 第4 当審の判断 1.引用文献 (1-1)引用文献1に記載されている技術的事項及び引用発明 本願の出願日前に頒布され,原審の平成26年1月31日付けの拒絶理由通知において引用された,「山名 早人,サーチエンジンGoogle,情報処理,日本,社団法人情報処理学会,2001年 8月15日,第42巻 第8号 通巻438号,p.775-780」(以下,「引用文献1」という。)には,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) A 「2001年3月末現在,シリコンバレーに2カ所,シカゴ,アトランタ,ニューヨークにそれぞれ1カ所の合計5カ所にデータセンターを設置し,各データセンターが1,000?3,000台規模のPCを備える。世界中からのアクセスは,これらのデータセンター単位で分散され^(14),次に各データセンター内のクラスタへと負荷分散がなされる^(15)。 ^(14) ラウンドロビンDNSを用いる。現在Border Gateway Protocolの利用へと移行中。 ^(15 )データセンター内での負荷分散は,Custom load-balancing softwareにより行われているが,技術的詳細は公開されておらず不明。」(第777頁左欄第6行目?第13行目及び文中の注釈) ここで,上記引用文献1に記載されている事項を検討する。 上記Aの「合計5カ所にデータセンターを設置し,各データセンターが1,000?3,000台規模のPCを備える。世界中からのアクセスは,これらのデータセンター単位で分散され^(14),次に各データセンター内のクラスタへと負荷分散がなされる^(15)」,「^(14) ラウンドロビンDNSを用いる」及び「^(15) データセンター内での負荷分散は,Custom load-balancing softwareにより行われているが,技術的詳細は公開されておらず不明」との記載からすると,ここでいう「世界中からのアクセス」とは,クライアントからのアクセスであることは自明であり,またデータセンター内の複数のPCにおいても何らかの方法で負荷分散が行われていることから,引用文献1には次の発明(以下,「引用発明」という。)が記載されているものと認められる。 「複数のデータセンターを有するシステムであって, クライアントからのアクセスを,ラウンドロビンDNSを用いて各データセンターに分散し, 更に,何らかの方法により,各データセンター内の複数のPCを用いて,各データセンタ内での負荷分散処理をする,システム。」 (1-2)引用文献2に記載されている技術的事項 本願の出願日前に頒布され,原審の平成26年1月31日付けの拒絶理由通知において引用された,「上野 洋史,データセンターネットワークにおけるネットワークアプライアンス機能配備の一検討,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2009年11月13日,Vol.109 No.296,p.7-12」(以下,「引用文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) B 「2.1.OpenFlowによるネットワーク制御 OpenFlowはパケットスイッチ処理を行うデータプレーン処理と,パケットスイッチ処理の経路制御を行う制御プレーン処理を分割したアーキテクチャをとっており,データプレーン処理と制御プレーン処理の間をオープンなインタフェースで接続する(図1)。ネットワーク上に配備されるスイッチと,そのスイッチを制御するコントローラを分離した構成をとり,ネットワーク転送処理方法はコントローラで決定する。そのため,従来のレイヤ2(スパニングツリープロトコル)やレイヤ3(OSPFなどによる自律分散型のIPルーティング処理)とは異なるネットワーク制御処理をコントローラ上に配備することで,自由なネットワーク経路制御を実現することができる。 OpenFlowでは,パケットスイッチを行うために,パケットのヘッダ(レイヤ2,レイヤ3,レイヤ4)情報を検索キーとしてフローテーブルを検索し,スイッチの宛先,出力アクションを決定する。このためのテーブルをフローテーブルと呼び,このフローテーブルのエントリをコントローラから設定することによって,フロー単位のスイッチングを実現する。ここで,フローとは同じネットワーク転送処理を適用するトラヒック群を識別する単位を指し,MACアドレスで宛先を識別するレイヤ2フロー,IPアドレスでトラヒックを識別するレイヤ3フロー,TCPのポート番号などのレイヤ4情報でトラヒックを識別するレイヤ4フローなどが定義できる。なお,本稿では,L4までを含めて一意に識別した細粒度のフローのことをマイクロフローと呼び,複数のマイクロフローを集約したフローを集約フローと呼ぶことにする。 このようなOpenFlowをベースとしたネットワークでは,OpenFlowを制御するコントローラ上のソフトウェア処理によって,ネットワークの経路,転送方法を制御することができる.」(第8頁右欄第6行目?第9頁左欄第8行目)) C 「3.3.スケールアウト処理 本節では,本システムでスケールアウトを達成できる仕組みを,ロードバランサを例に説明する。 図3の構成では,仮想IPアドレスVIP1で識別される仮想ロードバランサを1つ定義し,これを物理ロードバランサ2台にマッピングして実現している.OpenFlowスイッチに対して,2台の物理ロードバランサヘトラヒックを振り分けるためのフローエントリが設定されている。入力パケットヘッダのソースIPを条件に用いることで,OpenFlowスイッチのハードウェア転送のみで高速な振り分けが可能である。またコントローラにパケットが到達しないので,コントローラがボトルネックになることもない。 次に,仮想フロントエンドの性能が不足したために,物理フロントエンドのリソースを増設する場合について説明する.運用者は仮想フロントエンドと物理フロントエンドのマッピングを変更することで,物理フロントエンドのリソースを増加させる。 新しく追加した物理フロントエンドには既存の物理フロントエンドと同一の設定を行い,新規に割り当てた物理フロントエンドにトラヒックが流れるようにスイッチのフローエントリを書き換える。ただし,単純に書き換えたのでは,セッションが切断されてしまう場合があるため,OpenFlowを利用しマイクロフローによる動的な制御を併用する。 いま,仮想IPアドレスVIP1で識別される1つの仮想ロードバランサを1台の物理ロードバランサLB1にマッピングしているとき,これを2台の物理ロードバランサLB1,LB2に分散させるように変更するスケールアウト処理を考える。最初の状態(図4(a))では,VIP1宛のパケットはすべてLB1に転送するようなフローテーブルが設定されている。これを,ソースIPの範囲によってLBlとLB2に分散するように変更する(図4(d))。このためにまずLB1への集約フローを,コントローラに転送するように変更する(図4(b))。これにより,VIP1宛のすべてのパケットがコントローラに転送されるようになる。コントローラは例えばパケットのSYNフラグをチェックすることにより,入力パケットが新規セッションか,あるいはLB1を利用していた既存セッションかを判断する. 新規セッションであれば,パケットのソースIPを調べ,変更後の振り分けルールに従ってLB1またはLB2に転送するようスイッチに指示を出す。 一方,既存セッションであったなら,LB1へのマイクロフローをスイッチに登録する(図4(c))。このマイクロフローは,集約フローよりも高い優先度としておく。これによりそのクライアントセッションは引き続きLB1で処理されるので,セッションが切断されることなく,かつコントローラにパケットが上がってこなくなる。 スケールアウト処理を開始してから,物理ロードバランサのセッションタイムアウト時間が経過したら,変更後の集約フローをスイッチに登録する。」(第10頁右欄第1行目?第11頁左欄第20行目)) (1-3)引用文献3に記載されている技術的事項 本願の出願日前に頒布され,原審の平成26年1月31日付けの拒絶理由通知において引用された,特開2004-350078号公報(平成16年12月9日出願公開,以下,「引用文献3」という。)には,関連する図面とともに,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) D 「【0012】 【課題を解決するための手段】 本発明の方路分散伝送システムは,図1を参照して説明すると,等コスト・マルチパス方式を適用した方路分散伝送システムであって,出力物理ポート3の出力バッファ10の使用量又はパケットの流量が予め設定した閾値を超えたか否かを検出する回線負荷状態検出部9と,この回線負荷状態情報検出部9により検出した負荷状態情報を記憶し,この負荷状態情報を参照して,過負荷状態の出力物理ポートを回避して方路分散処理を行う方路決定部5とを備えている。 【0013】 又方路決定部5は,出力物理ポート3対応の回線負荷状態情報検出部9からの負荷状態情報を記憶する出力ポート負荷状態情報記憶部7と,この出力ポート負荷状態情報記憶部7を参照し過負荷状態の出力物理ポートを回避するように等コスト・マルチパス・グループ内の出力物理ポートを順次指定するラウンドロビン・テーブルを備えている。 【0014】 又回線負荷状態検出部9は,出力バッファ10の使用量が閾値を超えた時に過負荷状態と判定し,この判定した信号を所定のサンプリング間隔でサンプリングして保持し,この保持した信号を負荷状態情報とする構成を有し,出力物理ポート3対応の負荷状態情報を収集して,方路決定部5の出力ポート負荷状態情報記憶部7に同報転送する同報部8を備えている。」 E 「【0031】 図7は,図3に於ける方路決定部25の説明図であり,ラウンドロビン・テーブル54と出力ポート負荷状態情報記憶部55とを含む構成を示す。この出力ポート負荷状態情報記憶部55は,図1に於ける出力ポート負荷状態情報記憶部7に相当するものである。又ラウンドロビン・テーブル54は,例えば,ECMPグループECMP#1に出力物理ポートの番号port#0,port#1,port#2が属し,ECMPグループECMP#2にport#2,port#6, port#7, port#9が属し,ECMPグループECMP#3にport#1, port#nが属す場合を示している。 【0032】 又出力ポート負荷状態情報記憶部55は,同報部29から同報転送された負荷状態情報を記憶するものであり,出力ポート番号port#0,port#1,port#2,・・・対応に,過負荷状態を例えば”1”,それ以外を”0”として格納し,図示の場合は,出力ポート番号port#1が過負荷状態であり,他の出力ポート番号対応には過負荷状態ではないとを示す”0”が格納されている。 【0033】 又ラウンドロビン・テーブル54は,例えば,図1のECMP経路テーブル6によるECMPグループ番号に従って出力ポート番号を出力し,図1に於いてはルーティング検索部4へ転送し,図3に於いては,フォワーディング・エンジン26に転送する。例えば,パケットのヘッダ情報に従ったECMPグループ番号ECMP#1が入力されると,ラウンドロビン・テーブル54を検索する。この場合,出力ポート負荷状態情報記憶部55に過負荷状態の情報が記憶されていないとすると,ポインタにより矢印で順序を示すように,グループ内の出力ポート番号が順次指定される。即ち,port#0→port#1→port#2→port#1のように,等コストの回線に対応する出力ポート番号が順次選択されて,方路分散処理が行われる。 【0034】 しかし,出力ポート負荷状態情報記憶部55には,ポート番号port#1は過負荷状態として記憶されているから,ラウンドロビン・テーブル54のポインタ制御により,このポート番号port#1を除く,port#0→port#2→port#0→port#2のように,方路分散処理が行われる。又過負荷状態から通常の負荷状態となると,同報部からの負荷状態情報を受信して,最初の方路分散処理が行われる。 【0035】 図8は前述の方路決定処理のフローチャートを示し,方路決定部25は,フォワーディング・エンジン26(FE(I))(図3参照)からECMPグループ番号(ECMP grp No.)を受信すると(C1),ラウンドロビン・テーブル54を検索し(C2),ラウンドロビン・テーブル54のポインタが,ECMPグループ(ECMP grp)の末尾を示しているか否かを判定し(C3),末尾を示している場合は,ポインタをECMPグループの先頭に戻し(C4),末尾を示していない場合は,現在のポインタを一つ進める(C5)。 【0036】 そして,ポインタが示す出力ポート(port)は,過負荷状態か否かを出力ポート負荷状態情報記憶部55を参照して判定し(C6),過負荷状態の場合(負荷状態情報=”1”)は,ステップ(C7)に移行し,過負荷状態でない場合(負荷状態情報=”0”)は,ポインタにより指示された出力ポート番号(port N0.)を,フォワーディング・エンジン26(FE(I))に転送する。このような処理により,過負荷状態でない出力ポート番号に対してパケットを振り分けるもので,負荷分散処理が行われることになる。」 2.対比 本願発明と引用発明とを対比する。 (2-1)引用発明の「クライアント」は,本願発明の「クライアント端末」に相当する。 (2-2)引用発明の「複数のPC」は,クライアントからのアクセスに基づいて処理を行うものであるから,本願発明の「サービス提供サーバ」とは「自身に接続された複数のクライアント端末のそれぞれに対して,サービスを提供する複数のサービス提供サーバ」と言えるものである点で共通する。 (2-3)引用発明は「ラウンドロビンDNS」を用いて負荷分散を行っていることから,本願発明の「ラウンドロビン機能によって,前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うDNS(Domain Name System)サーバ」に相当する構成を有している。 以上から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。 (一致点) 「自身に接続された複数のクライアント端末のそれぞれに対して, サービスを提供する複数のサービス提供サーバと, ラウンドロビン機能によって,前記複数のクライアント端末と前記複数のサービス提供サーバと間の負荷分散を行うDNS(Domain Name System)サーバと を具備したシステム。」 (相違点1) 本願発明の,「通信経路上のスイッチに対して,フローエントリを設定するコントローラ」及び「前記コントローラによって設定されたフローエントリに従って,受信パケットの中継処理を行うスイッチ」の構成について,引用発明では言及されていない点。 (相違点2) 本願発明の,「複数のサービス提供サーバのそれぞれは,それぞれの負荷状況を監視し,自身に対する負荷が閾値以上であると判定すると,負荷分散要求を前記コントローラに発行し, 前記コントローラは,前記負荷分散要求に応じて,前記スイッチに設定したフローエントリを変更する」構成について,引用発明では言及されていない点。 3.判断 上記相違点1及び相違点2について検討する。 (1)相違点1について 引用発明では「スイッチ」及び「コントローラ」について言及されていない点で,本願発明と相違することは上記のとおりである。 これに対して,原審において引用された引用文献2には,上記B乃至Cの記載からすると,「スイッチ」及び「コントローラ」を用いて負荷分散を行うことが記載されていると解せられ,これはOpenFlow技術として周知のものであると解せられ,引用発明においてこの周知技術を適用し,相違点1の構成とすることは,当業者であれば容易になし得たものである。 (2)相違点2について 引用発明では,サーバが負荷状況を監視し,自身に対する負荷が閾値以上であると判定すると負荷分散要求を発行することが言及されていない点で,本願発明と相違することは上記の通りである。 これに対して,原審において引用された引用文献3には,上記D乃至Eの記載からすると,出力バッファの負荷状態情報を参照して過負荷状態の出力ポートを回避する負荷分散方法は記載されているものの,「スイッチ」や「コントローラ」に関しては,記載も示唆もされていない。 よって,引用文献3に記載の負荷分散方法を引用文献2に記載の「スイッチ」及び「コントローラ」に適用し,さらにこれを引用発明に適用することには論理に飛躍があり,当業者が相違点2の構成とすることは容易になし得たものとはいえない。 4.まとめ 以上のとおりであるから,本願の請求項1に係る発明は,引用発明,引用文献2及び引用文献3に記載の技術的事項及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものとすることができないものである。 5.請求項2乃至10に係る発明について 本願の請求項2-9に係る発明は,本願発明をさらに限定したものであり,また請求項10に係る発明は,請求項1に係る発明を方法の発明として記載したものであるので,本願発明と同様に,当業者が容易に発明をすることができたとはいえない。 第5 むすび 以上のとおり,本願の請求項1乃至10に係る発明は,引用発明,引用文献2及び引用文献3に記載の技術的事項及び周知技術に基づいて,当業者が容易に発明をすることができたものとすることができないから,原査定の理由によっては,本願を拒絶することはできない。 また,他に本願を拒絶すべき理由を発見しない。 よって,結論のとおり審決する。 |
審決日 | 2015-04-17 |
出願番号 | 特願2010-35322(P2010-35322) |
審決分類 |
P
1
8・
121-
WY
(G06F)
|
最終処分 | 成立 |
前審関与審査官 | 大塚 俊範 |
特許庁審判長 |
辻本 泰隆 |
特許庁審判官 |
須田 勝巳 浜岸 広明 |
発明の名称 | コンピュータシステム、コントローラ、サービス提供サーバ、及び負荷分散方法 |
代理人 | 工藤 実 |