2018-002601

特願２０１４－５３２１１１「トラフィックディレクタ環境におけるトラフィックのアクティブ－パッシブルーティングおよび制御のためのシステムおよび方法」拒絶査定不服審判事件〔平成２５年　４月　４日国際公開，ＷＯ２０１３／０４９２３３，平成２６年１１月１７日国内公表，特表２０１４－５３０４３４，請求項の数（１０）〕について，次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は，特許すべきものとする。

【理　由】 第１　手続の経緯 本願は，２０１２年（平成２４年）９月２６日（パリ条約による優先権主張外国庁受理２０１１年９月２７日（以下，「優先日」という。），アメリカ合衆国，２０１２年８月３１日，アメリカ合衆国，２０１２年９月２４日，アメリカ合衆国）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。 平成２６年　３月２０日　　：国内書面の提出 平成２７年　８月１８日　　：手続補正書の提出 平成２８年　６月２０日付け：拒絶理由通知書 平成２８年　９月２８日　　：意見書，手続補正書の提出 平成２９年　１月３０日付け：拒絶理由通知書 平成２９年　５月　１日　　：意見書，手続補正書の提出 平成２９年１０月１６日付け：拒絶査定（原査定） 平成３０年　２月２３日　　：審判請求書，手続補正書の提出 平成３０年１０月２５日付け：拒絶理由通知書（当審） 平成３０年１１月１９日　　：意見書，手続補正書の提出 第２　本願発明 本願請求項１－１０に係る発明（以下，それぞれ「本願発明１」－「本願発明１０」という。）は，平成３０年１１月１９日付けの手続補正で補正された特許請求の範囲の請求項１－１０に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。 「【請求項１】 トラフィックディレクタコンポーネントを含むコンピューティング環境における使用のためのシステムであって、 マイクロプロセッサとコンピュータメモリとを備え、 前記マイクロプロセッサとコンピュータメモリにおいて動作する１つ以上のトラフィックディレクタインスタンスを有し、クライアントから発信元サーバに要求を受け取って通信するよう構成されるトラフィックディレクタと、 発信元サーバの第１のプールと、を含み、前記発信元サーバの第１のプールは、プライマリサーバとしての１つ以上のサーバと少なくとも１つ以上のバックアップサーバとを備えて構成されており、 前記トラフィックディレクタは、前記第１のプールにおける前記１つ以上のプライマリサーバの可用性を判断し、前記第１のプールにおいて少なくとも１つ以上のプライマリサーバが利用可能である間は、当該トラフィックディレクタは、受け取った前記第１のプールに対する全ての要求を、前記第１のプールの前記１つ以上のプライマリサーバにのみ方向付けるように構成され、 前記トラフィックディレクタは、前記第１のプールにおいて利用可能なプライマリサーバが無い場合は、前記第１のプールにおいて少なくとも１つのプライマリサーバが再び利用可能となるまで、受け取った前記第１のプールに対する全ての要求を、当該第１のプールの前記１つ以上のバックアップサーバに方向付けるように構成され、 前記トラフィックディレクタは、利用可能なプライマリサーバが無くなった後に、少なくとも１つのプライマリサーバが再び利用可能となったならば、少なくとも１つのプライマリサーバが再び利用可能となった後のある期間は、当該トラフィックディレクタが受け取った全ての要求を、前記第１のプールにおける前記１つ以上のバックアップサーバに方向付けし続けるよう構成される、システム。」 なお，本願発明２－１０の概要は以下のとおりである。 本願発明２－６は，本願発明１を減縮した発明である。 本願発明７は，本願発明１に対応する方法の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。 そして，本願発明８は，本願発明７を減縮した発明である。 また，本願発明９は，本願発明１に対応するプログラムの発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。 そして，本願発明１０は，本願発明９を減縮した発明である。 第３　引用文献，引用発明等 １　引用文献１について （１）原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開２０１０－１１３４９５号公報（平成２２年５月２０日出願公開。以下，「引用文献１」という。）には，図面とともに，次の記載がある（当審注：下線は当審が付与した。）。 「【０００１】 本発明は、コンピュータシステムの高可用性を実現するクラスタシステムの制御技術に関し、特に、複数の正系サーバに対して複数の副系サーバを有するＮ：Ｍ型のクラスタシステムおよびその制御方法に適用して有効な技術に関するものである。」 「【０００７】 負荷分散を行うＮ：Ｍ型のクラスタシステムにおいて、クライアントからのサービス要求に対する処理能力を維持しつつ、多重障害に対しての可用性を確保するには、クラスタシステムの自動的な再構成により、正系サーバと副系サーバの稼働台数を所定の範囲内に維持するように制御する必要がある。しかし、特許文献２などに記載されているようなクラスタシステムでは、正系サーバの追加・削除等、動的にクラスタの再構成を行う技術については開示されているが、それにより正系サーバ、副系サーバの稼働台数を所定の範囲内に維持する手段については開示されていない。 ・・・（中略）・・・ 【００１０】 そこで本発明の目的は、負荷分散を行うＮ：Ｍ型のクラスタシステムにおいて、正系サーバ、副系サーバの稼働台数を所定の範囲内に維持し、また、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えるクラスタシステムおよびその制御方法を提供することにある。」 「【００１８】 ＜実施の形態＞ ［システム構成］ 図１は、本発明の一実施の形態であるクラスタシステムの構成例の概要を示した図である。クラスタシステムは、外側ファイアウォール（ＦＷ）５００と内側ＦＷ６００に囲まれたＤＭＺのセグメントに配置された複数の正系サーバ１００、複数の副系サーバ２００およびロードバランサー（以下では「ＬＢ」と記載する場合がある）４００と、ＤＭＺの内側のセグメントに配置された監視サーバ３００とから構成される。外側ＦＷ５００の外部からは、インターネット等のネットワーク７００を介してクライアント端末８００がＬＢ４００に接続している。」 「【００２０】 正系サーバ１００は、クライアント端末８００からの要求に対してサービスを提供する現用系サーバとして稼働しているアプリケーションサーバ（以下では単に「サーバ」と記載する場合がある）であり、副系サーバ２００は、クライアント端末８００に対してサービスを提供せず、正系サーバ１００に対する待機系サーバとして稼働しているサーバである。なお、本実施の形態のクラスタシステムでは、副系サーバ２００が起動された状態で待機しているホットスタンバイもしくはウォームスタンバイの構成としているが、副系サーバ２００が電源ＯＦＦの状態で待機しているコールドスタンバイの構成であっても適用することが可能である。 【００２１】 正系サーバ１００、副系サーバ２００は、いずれもアプリケーションプログラム（以下では単に「アプリ」と記載する場合がある）１１０、サーバ定義１２０、定義入替部１３０、アプリ定義確認部１４０、アプリ再起動部１５０、サーバ状態応答部１６０を有する構成となっている。」 「【００２３】 正系サーバ１００では、サーバ定義１２０は正系定義が選択されており、アプリ１１０は正系定義を適用して起動している。また、副系サーバ２００では、サーバ定義は副系定義が選択されており、アプリ１１０は副系定義を適用して起動している。言い換えると、アプリ１１０がサーバ定義１２０の正系定義を適用して起動したサーバは正系サーバ１００として稼働し、アプリ１１０がサーバ定義１２０の副系定義を適用して起動したサーバは副系サーバ２００として稼働することになる。すなわち、アプリケーションサーバは、起動時に適用する定義により正系サーバ１００にも副系サーバ２００にもなることが可能である。 ・・・（中略）・・・ 【００２６】 アプリ定義確認部１４０は、監視サーバ３００に対して自サーバが正系サーバ１００もしくは副系サーバ２００のいずれとして稼働すべきかのアプリ定義の情報を定期的に問い合わせ、その内容に従って、定義入替部１３０やアプリ再起動部１５０に指示を行う。アプリ定義確認部１４０からの指示により、定義入替部１３０は、サーバ定義１２０で選択されている定義情報の入れ替えを行う。また、アプリ再起動部１５０は、アプリ１１０を再起動してサーバ定義１２０で選択されている定義情報をアプリ１１０に反映させる。これらにより、当該サーバの正副を変更することができる。」 「【００２９】 ＬＢ４００は、定期的に正系、副系全てのサーバのポート１１１（port_A）およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したか（もしくはいずれも応答を受信できなかったか）により、各サーバが正系サーバ１００として稼働しているか副系サーバ２００として稼働しているか、もしくは障害中であるかを把握する。 【００３０】 ＬＢ４００は、この情報をサーバリスト４１０に保持しておき、この情報に基づいて、クライアント端末８００からサービス要求を受けた際に、副系サーバ２００や停止中のサーバには処理を振り分けず、稼働中の正系サーバ１００にのみ処理を振り分ける。このとき、一般的なラウンドロビンやその他の方法で負荷分散を行って処理を振り分ける。また、各正系サーバ１００の間ではセッション情報を始めとするデータの授受を行わないため、ＬＢ４００は、正系サーバ１００に処理を振り分ける際に、同一のセッションについては同一の正系サーバ１００に処理を振り分け、異なる正系サーバ１００に処理を振り分けることはしないものとする。」 「【００３１】 監視サーバ３００は、ＤＭＺに配置された正系サーバ１００および副系サーバ２００の稼働状況を監視し、各サーバのアプリ定義の設定情報を保持するサーバである。監視サーバ３００は、アプリ定義応答部３１０、アプリ状態監視部３２０、サーバ状態監視部３３０、稼働台数確認部３４０、通知部３５０、サーバ状態リスト３６０、稼働台数定義３７０を有する構成となっている。 ・・・（中略）・・・ 【００３７】 稼働台数確認部３４０は、サーバ状態リスト３６０に保持されている各サーバの稼働状況や、稼働台数定義３７０に保持されている、正系サーバ１００、副系サーバ２００の稼働台数の範囲についての定義情報などに基づいて、定期的に正系サーバ１００、副系サーバ２００の稼働台数を確認し、定義されている稼働台数範囲を満たしていない場合はこれを調整する。 【００３８】 詳細については後述するが、ここでは正系サーバ１００の正常稼働台数について、稼働台数範囲に対して余剰分がある場合は、余剰分に相当する正系サーバ１００が副系サーバ２００として稼働するようにサーバ状態リスト３６０のアプリ定義を切り替える。また、稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバ２００が正系サーバ１００として稼働するようにサーバ状態リスト３６０のアプリ定義を切り替えることにより稼働台数を調整する。」 「【００５９】 正系サーバ最大稼働台数および正系サーバ最低稼働台数（３７１～３７６）には、アプリ１１０が提供するサービスの種別毎に、正系サーバ１００として正常に稼働しているべきサーバの最大台数と最低台数、すなわち稼働台数範囲を定義する。副系サーバ最低稼働台数３７７には、副系サーバ２００として正常に稼働しているべきサーバの最低台数を定義する。障害サーバ最大台数３７８には、障害中となっているサーバの台数として許容される最大台数を定義する。アプリ障害最大回数３７９には、各サーバについてアプリ１１０が障害となった回数として許容される最大回数を定義する。稼働台数定義３７０の定義内容は、監視サーバ３００のユーザインタフェース等を利用して変更可能としてもよい。」 （２）上記記載から，引用文献１には，次の技術事項が記載されているものと認められる。 ア　引用文献１は，コンピュータシステムの高可用性を実現するクラスタシステムの制御技術に関するものである（【０００１】）。 また，引用文献１の目的は，負荷分散を行うクラスタシステムにおいて，クライアントからのサービス要求に対する処理能力を維持しつつ多重障害に対しての可用性を確保するために，正系サーバ，副系サーバの稼働台数を所定の範囲内に維持することである（【０００７】，【００１０】）。 イ　クラスタシステムは，複数の正系サーバ，複数の副系サーバ，ロードバランサー（以下，「ＬＢ」という。），及び監視サーバとから構成されるものであり，インターネット等のネットワークを介してクライアント端末がＬＢに接続している（【００１８】）。 ウ　正系サーバは，クライアント端末からの要求に対してサービスを提供する現用系サーバとして稼働しているアプリケーションサーバであり，また，副系サーバは，クライアント端末に対してサービスを提供せず，正系サーバに対する待機系サーバとして稼働しているアプリケーションサーバである（【００２０】）。 また，正系サーバと副系サーバは，アプリケーションサーバが起動時に適用する定義によっていずれかに構成されるものであり（【００２３】），さらに，監視サーバに対して問い合わせた，自サーバが正系サーバ，副系サーバのいずれとして稼働すべきかのアプリ定義の情報の内容に従って，当該サーバの正副を変更するものである（【００２１】，【００２６】）。 エ　ＬＢは，定期的に全てのサーバに対して参照を行い、各サーバが正系サーバ，副系サーバのいずれとして稼働しているか又は障害中であるかを把握し，当該情報に基づいて、クライアント端末からサービス要求を受けた際に、副系サーバや停止中のサーバには当該サービス要求に係る処理を振り分けず、稼働中の正系サーバにのみ処理を振り分けるものである（【００２９】，【００３０】）。 オ　監視サーバは、サーバ状態リストに保持されている各サーバの稼働状況や、稼働台数定義に保持されている、正系サーバ、副系サーバの稼働台数の範囲についての定義情報などに基づいて，定期的に正系サーバ，副系サーバの稼働台数を確認し，アプリが提供するサービスの種別毎に定義されている稼働台数範囲を満たしていない場合はこれを調整し（【００３１】，【００３７】，【００５９】），正系サーバの稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバが正系サーバとして稼働するようにサーバ状態リストのアプリ定義を切り替えることにより稼働台数を調整するものである（【００３８】）。 （３）上記（１），（２）から，引用文献１には，次の発明（以下、「引用発明」という。）が記載されていると認められる。 「　監視サーバと， ネットワークを介してクライアント端末からのサービス要求を受け付けるＬＢと， アプリケーションサーバと，から構成され，前記アプリケーションサーバは，クライアント端末からの要求に対してサービスを提供する現用系サーバとして稼働している複数の正系サーバと正系サーバに対する待機系サーバとして稼働している複数の副系サーバとして構成されており， 前記ＬＢは，各サーバが正系サーバ，副系サーバのいずれとして稼働しているか又は障害中であるかの情報に基づき，クライアント端末から受けたサービス要求に係る処理を，稼働中の前記正系サーバにのみ振り分けるクラスタシステムにおいて， 前記監視サーバは，サービスの種別毎に定義されている正系サーバの稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバが正系サーバとして稼働するようにサーバ状態リストのアプリ定義を切り替えることにより稼働台数を調整する， クラスタシステム。」 ２　引用文献２について （１）原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開平９－２５９０９５号公報（平成９年１０月３日出願公開。以下，「引用文献２」という。）には，図面とともに，次の記載がある（当審注：下線は当審が付与した。）。 「【００１４】 【発明の実施の形態】次に本発明の好適な実施の形態を図面を用いて説明する。図１は、本実施の形態の２重冗長構成の中央処理システムの構成図である。この図１において、中央処理システムは、主に、一方の中央処理装置（ＣＰＵ）Ａと、他方の中央処理装置（ＣＰＵ）Ｂとから構成されている。それぞれの中央処理装置には、０系バスラインと１系バスラインとに接続するためのバス接続端子が備えられていて、中央処理装置Ａには、０系バス接続端子５ａ０と１系バス接続端子５ａ１とが備えられ、中央処理装置Ｂには、０系バス接続端子５ｂ０と１系バス接続端子５ｂ１とが備えられ、０系バスラインと１系バスラインとにクロスバス接続されている。」 「【００２６】（動作）：次に図１の２重冗長構成された中央処理システムの動作を説明する。この図１において、中央処理装置Ａをアクト系とし、中央処理装置Ｂをスタンバイ系として動作を説明する。 ・・・（中略）・・・ 【００３２】以上のような動作は、アクト系が中央処理装置Ａから中央処理装置Ｂに切り替えられても同じように行われる。」 「【００４１】（４）更にまた、アクト系とスタンバイ系との切り替えは、例えば、障害復旧後に再びアクト系又はスタンバイ系に復帰する復帰モード、非復帰モードのいずれで切り替えられる場合にも本発明を適用することができる。」 （２）上記記載から，引用文献２には，次の技術事項が記載されているものと認められる。 ア　中央処理システムは，２重冗長構成とされており，中央処理装置Ａと中央処理装置Ｂとから構成されている（【００１４】）。 イ　中央処理システムでは，中央処理装置Ａがアクト系として，中央処理装置Ｂがスタンバイ系として動作し（【００２６】），また，アクト系は，中央処理装置Ａから中央処理装置Ｂに切り換えられ得るものである（【００３２】）。 ウ　アクト系とスタンバイ系との切り替えは，障害復旧後に再びアクト系又はスタンバイ系に復帰する復帰モードで行われ得るものである（【００４１】）。 （３）上記（１），（２）から，引用文献２には，次の技術事項が記載されていると認められる。 「　中央処理装置Ａ及び中央処理装置Ｂがそれぞれアクト系及びスタンバイ系として動作する中央処理システムにおいて，中央処理装置Ｂが中央処理装置Ａに代わってアクト系に切り換えられ，また，当該切り換えが復帰モードで行われる場合には，（アクト系又はスタンバイ系は）障害復旧後に再びアクト系又はスタンバイ系に復帰すること。」 ３　引用文献３について （１）原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開昭６２－１３９０４９号公報（昭和６２年６月２２日出願公開。以下，「引用文献３」という。）には，図面とともに，次の記載がある（当審注：下線は当審が付与した。）。 「〔概要〕 本発明は，それぞれメモリとプロセッサＣＰＵを具備した主系のデータ処理システムと従系のデータ処理システムを設け，制御対象であるＩ／Ｏ装置からの送出データは主系，従系の各データ処理システムの両方に入力するとともに処理システムのＩ／Ｏ装置への出力は主系の処理システムから送出され，主系のデータ処理システムと従系のデータ処理システムをシステム間通信手段で接続し，また主系のデータ処理システムと従系のデータ処理システムを監視装置で監視するようにしたデータ連続性を保証するデータ処理二重化方式である。」（第１頁右下欄第１４行－第２頁左上欄第６行）（以下，「【引用１】」という。） 「〔作用〕 入出力装置４からの出力は主系システムＩおよび従系システムＩＩに入力され，それぞれ演算処理されて共用ダスド６，７に同一のデータが記入される。また入出力装置４に対する出力データは，主系システムＩから出力される。もし監視装置５が主系システムＩに異常を検知したとき，従系システムＩＩが今度は主系システムとなり測定データ収集および処理の連続性を保つことができる。主系システムＩと従系システムＩＩ間にはシステム間通信機構８が接続され，データの送受信を行うことができる。」（第２頁左下欄第１１行－同頁右下欄第２行）（以下，「【引用２】」という。） 「　なお，ユーザによっては第１システムを主系に，第２システムを従系に運用し，第１システムがダウンしたとき第２システムを主系に運用し，第１システムの障害が回復したとき再び第１システムを主系に，第２システムを従系に運用することを要求するケースもある。このような場合では，前記の如く第１システムの障害が回復して従系として立上げたあとで，システム状態遷移処理を行なって，第１システムを主系に，第２システムを従系に切換えればよい。」（第６頁右下欄第１６行－第７頁左上欄第５行）（以下，「【引用３】」という。） （２）上記記載から，引用文献３には，次の技術事項が記載されているものと認められる。 ア　データ処理二重化方式は，システム間通信手段で接続された主系システムＩ及び従系システムＩＩを監視装置で監視し，主系システムＩに異常を検知したとき従系システムＩＩが今度は主系システムとなるものである（【引用１】，【引用２】）。 イ　第１システムは，主系として運用されダウンした場合，障害が回復して立ち上げたあと再び主系に切換えられるものである。 また，第２システムは，従系として運用され，第１システムがダウンした場合主系に運用されるが，第１システムが障害から回復し主系に運用されると，従系に切換えられるものである（【引用３】）。 （３）上記（１），（２）から，引用文献３には，次の技術事項が記載されていると認められる。 「　主系システムと従系システムが接続されたデータ処理二重化方式において，主系システムに異常が検知されると，従系システムが主系に切換えられ，元の主系システムが障害から回復すると，元の主系システムを主系に切換え，元の従系システムを従系に切換えること。」 ４　引用文献４について （１）原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開平９－３３０２４５号公報（平成９年１２月２２日出願公開。以下，「引用文献４」という。）には，図面とともに，次の記載がある（当審注：下線は当審が付与した。）。 「【０００１】 【発明の属する技術分野】本発明は情報処理装置のマイクロ診断方式に関し、特に現用系情報処理装置と予備系情報処理装置から成る二重化システムにおいて待機中の予備系情報処理装置で診断テストを実行するときの情報処理装置のマイクロ診断方式に関する。」 「【０００９】図１に示す本発明の実施の一形態を示した情報処理装置は、稼働中の現用系装置１１１と、稼働中の現用系装置１１１に障害が発生したときに現用系装置１１１に代って稼働する予備系装置１１０とから構成されている。」 「【００１８】上記説明では、予備系装置１１０の診断テストについての動作のみを説明したが、現用系装置１１１が障害になり予備系装置１１０へ切り替わると、今度はこれまで待機状態にあった予備系装置１１０が稼働状態に入る。二重化システムの運用状態いかんでは図１に示す現用系装置１１１の障害が修復された後も、しばらくは予備系装置１１０を稼働状態におき現用系装置１１１を待機状態におくことがある。この場合には、上位制御装置から待機状態にある現用系装置１１１に対して、これまでの予備系装置１１０の場合と同様に定期的に診断テストの指示が行われる。図１に示すように、予備系装置１１０と現用系装置１１１とは同じ構成になっているので、予備系装置１１０が稼働状態に入り現用系装置１１１が待機状態にあるときに、上位制御装置からのマイクロ診断起動が現用系装置１１１にかけられれば、現用系装置１１１の診断テストの動作が予備系装置１１０の診断テストの場合と同様に行われるが説明は省略する。」 （２）上記記載から，引用文献４には，次の技術事項が記載されているものと認められる。 ア　二重化システムは，稼働中の現用系装置と，稼働中の現用系装置に障害が発生したときに現用系装置に代わって稼働する予備系装置とから構成されている（【０００１】，【０００９】）。 また，現用系装置の障害が修復された後も、しばらくは予備系装置を稼働状態におき現用系装置を待機状態におくものである（【００１８】）。 （３）上記（１），（２）から，引用文献４には，次の技術事項が記載されていると認められる。 「　稼働中の現用系装置と，稼働中の現用系装置に障害が発生したときに現用系装置に代わって稼働する予備系装置とから構成される二重化システムにおいて，現用系装置の障害が修復された後も、しばらくは予備系装置を稼働状態におき現用系装置を待機状態におくこと。」 ５　引用文献５について （１）原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開２０００－９９４３５号公報（平成１２年４月７日出願公開。以下，「引用文献５」という。）には，図面とともに，次の記載がある（当審注：下線は当審が付与した。）。 「【０００１】 【発明の属する技術分野】本発明は、クライアントおよび同一のサービスを提供する複数の情報配信サーバがネットワークに接続されたシステムにおいてクライアントと情報配信サーバの接続中に情報配信サーバを含むネットワーク側に障害が発生した時に情報配信サーバを切り替えるサーバ切り替え装置および方法とサーバ切り替えプログラムを記録した記録媒体に関する。」 「【０１０２】障害判定部４１における障害判定の基準について説明する。通信中にインターネット１９が配信サーバからデータを受信できない障害の要因としては、（１）配信サーバ側のプロセスダウン、インタフェースのリンクダウン、配信サーバ近隣のルータの障害等の通信切断の障害、および（２）ネットワークの輻輳、配信サーバの過負荷によるパケットの遅れやパケットロス等のトラフィック増大による障害等が考えられる。 【０１０３】上述した（１）の通信切断の障害では、インターネット１９は以後それまで接続していた配信サーバと通信を継続することは不可能である。従って、配信サーバを変更する以外にデータを受信する方法はない。また、（２）のトラフィック増大による障害では、クライアントと配信サーバ間のコネクションは切断されていない。しかしながら、クライアント側のアプリケーションで、データを受信できない要因が（１）であるかまたは（２）であるかを判断することは困難である。また、ストリームデータ通信では、データがスムーズに連続して送られてくることが重要であるので、（２）の場合も配信サーバを変更することが必要である。（１），（２）の両方の場合を障害として扱うこととし、配信サーバを変更する。」 （２）上記記載から，引用文献５には，次の技術事項が記載されているものと認められる。 ア　引用文献５は，クライアントおよび同一のサービスを提供する複数の情報配信サーバがネットワークに接続されたシステムにおいて，クライアントと情報配信サーバの接続中に情報配信サーバを含むネットワーク側に障害が発生した時に情報配信サーバを切り替える技術に関するものである（【０００１】）。 イ　障害判定部は，トラフィック増大による障害を障害として判定するものである（【０１０２】，【０１０３】）。 （３）上記（１），（２）から，引用文献５には，次の技術事項が記載されていると認められる。 「　クライアントと情報配信サーバの接続中に情報配信サーバを含むネットワーク側に障害が発生した時に情報配信サーバを切り替える技術において，障害判定の手法として，トラフィック増大による障害を障害として判定すること。」 ６　周知技術 前記２（３）及び前記３（３）での認定事項から，「主系システムに異常が検知されると従系システムが主系に切り換えられるシステムにおいて，元の主系システムが障害から回復すると，元の主系システムを主系に切換え，元の従系システムを従系に切換える手法」は，本願の優先日前において，当該技術分野における周知技術であったと認められる。 第４　対比・判断 １　本願発明１について （１）対比 ア　本願発明１と引用発明とを対比する。 （ア）引用発明の「アプリケーションサーバ」，「正系サーバ」，「副系サーバ」，「クライアント端末」，及び「サービス要求」は，それぞれ本願発明１の「発信元サーバ」，「プライマリサーバ」，「バックアップサーバ」，「クライアント」，及び「要求」に相当する。 （イ）引用発明の「ＬＢ」は，クライアント端末から受けたサービス要求に係る処理を，稼働中の正系サーバにのみ振り分けるものであり，当該正系サーバはアプリケーションサーバであるから，引用発明の「ＬＢ」と本願発明１の「トラフィックディレクタ」とは，「クライアントから発信元サーバに要求を受け取って通信するよう構成される」点において一致する。 （ウ）また，上記のサービス要求に係る処理を振り分ける処理は，各サーバが正系サーバ，副系サーバのいずれとして稼働しているか又は障害中であるかの情報に基づいて行われるものであるところ，引用発明の「ＬＢ」は，当然に正系サーバの可用性を判断していると解され，また，上記サービス要求に係る処理は，稼働中の正系サーバにのみ振り分けられるものであり，さらに，上記の「サービス要求に係る処理を振り分ける」ことは，結局「サービス要求を振り分ける」と表現することと技術的に同義であることから，引用発明の「ＬＢ」は，少なくとも１つ以上の正系サーバが利用可能である間は，クライアント端末から受けたサービス要求の全てを当該１つ以上の正系サーバに振り分けているといえるから，引用発明の「ＬＢ」と本願発明１の「トラフィックディレクタ」とは，「前記１つ以上のプライマリサーバの可用性を判断し，少なくとも１つ以上のプライマリサーバが利用可能である間は，」「受け取った前記第１のプールに対する全ての要求を，前記第１のプールの前記１つ以上のプライマリサーバにのみ方向付けるように構成される」点においても一致する。 （エ）さらに，いわゆる負荷分散機能をもったロードバランサーは，コンピュータあるいはルータにより構成されるのが一般的であり，また，当該コンピュータ及びルータは通常マイクロプロセッサやコンピュータメモリを備えているものであることが本願の優先日前における当該技術分野の技術常識であるところ，当該技術常識に照らせば，引用発明の「ＬＢ」も，マイクロプロセッサとコンピュータメモリとを当然に備えているものと解される。 （オ）引用発明の「クラスタシステム」は，ＬＢ，正系サーバあるいは副系サーバであるアプリケーションサーバとから構成されるものであるから，引用発明の「クラスタシステム」と本願発明１の「システム」とは，「トラフィックディレクタと、」「発信元サーバ」「と、を含」むものである点において一致する。 また，引用発明の「クラスタシステム」は，ＬＢを含むコンピューティング環境において使用されるものであることが明らかであり，当該コンピューティング環境は，ＬＢを構成するハードウェア及びソフトウェア・コンポーネントを当然に含むものであるから，引用発明の「クラスタシステム」と本願発明１の「システム」とは，「トラフィックディレクタコンポーネントを含むコンピューティング環境における使用のための」ものである点において一致する。 イ　以上のことから、本願発明１と引用発明との一致点及び相違点は、次のとおりである。 （一致点） 「　トラフィックディレクタコンポーネントを含むコンピューティング環境における使用のためのシステムであって， マイクロプロセッサとコンピュータメモリとを備え， クライアントから発信元サーバに要求を受け取って通信するよう構成されるトラフィックディレクタと， 発信元サーバと，を含み，前記発信元サーバは，プライマリサーバとしての１つ以上のサーバと少なくとも１つ以上のバックアップサーバとを備え， 前記トラフィックディレクタは，前記１つ以上のプライマリサーバの可用性を判断し，少なくとも１つ以上のプライマリサーバが利用可能である間は，当該トラフィックディレクタは，受け取った前記第１のプールに対する全ての要求を，前記第１のプールの前記１つ以上のプライマリサーバにのみ方向付けるように構成される， システム。」 （相違点） （相違点１） 本願発明１の「トラフィックディレクタ」は，１つ以上のトラフィックディレクタインスタンスを有するものであるのに対し，引用発明の「ＬＢ」については，そのような特定がなされていない点。 （相違点２） 本願発明１の「発信元サーバ」は，「第１のプール」として構成されているのに対し，引用発明の「アプリケーションサーバ」については，そのような特定がなされていない点。 （相違点３） 本願発明１の「トラフィックディレクタ」は，「利用可能なプライマリサーバが無い場合は，」「少なくとも１つのプライマリサーバが再び利用可能となるまで，受け取った」「全ての要求を」「前記１つ以上のバックアップサーバに方向付ける」のに対し，引用発明の「ＬＢ」は，クライアント端末から受けたサービス要求を稼働中の正系サーバにのみ振り分け，正系サーバの稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバが正系サーバとして稼働するように稼働台数を調整する点。 （相違点４） 本願発明１の「トラフィックディレクタ」は，「利用可能なプライマリサーバが無くなった後に，少なくとも１つのプライマリサーバが再び利用可能となったならば，少なくとも１つのプライマリサーバが再び利用可能となった後のある期間は，当該トラフィックディレクタが受け取った全ての要求を，」「前記１つ以上のバックアップサーバに方向付けし続ける」のに対し，引用発明の「ＬＢ」については，そのような特定がなされていない点。 （２）相違点についての判断 ア　事案に鑑みて，上記相違点３について先に検討すると，前記「第３　６」で検討したとおり，主系システムに異常が検知されると従系システムが主系に切り換えられるシステムにおいて，元の主系システムが障害から回復すると，元の主系システムを主系に切換え，元の従系システムを従系に切換える手法は，本願の優先日前に当該技術分野における周知技術であったが，当該周知技術における「主系システム」及び「従系システム」は，それぞれ本願発明１の「プライマリサーバ」及び「バックアップサーバ」に相当する。そして，当該周知技術を採用したシステムにおいては，「利用可能な主系システム（プライマリサーバ）が無い場合は，少なくとも１つの主系システム（プライマリサーバ）が再び利用可能となるまで，受け取った全ての要求を前記１つ以上の従系システム（バックアップサーバ）に方向付ける」ことになることは，当業者には明らかな技術事項である。 即ち，仮に，引用発明に当該周知技術を適用することができるとすると，引用発明のＬＢは，「利用可能な正系サーバが無い場合は，少なくとも１つの正系サーバが再び利用可能となるまで，受け取った全てのサービス要求を前記１つ以上の副系サーバに方向付ける」ように構成されることになる，と一応いうことができるところ，引用発明への当該周知技術の適用容易性について，以下に検討する。 前記「第３　１（２）ア」で検討したとおり，引用発明は，負荷分散を行うクラスタシステムにおいて，処理能力を維持しつつ多重障害に対しての可用性を確保するために，正系サーバ，副系サーバの稼働台数を所定の範囲内に維持することをその目的としており，その実現のために，「（前記監視サーバは，）サービスの種別毎に定義されている正系サーバの稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバが正系サーバとして稼働するようにサーバ状態リストのアプリ定義を切り替えることにより稼働台数を調整する」構成を採用するものである。即ち，引用発明は，稼働している正系サーバの台数が稼働台数範囲内であれば，むしろそのまま正系サーバを稼働させておくものであると解されるところ，仮に，正系サーバに異常が検知され，稼働中の正系サーバの台数が稼働台数範囲に対して不足があるとされたために副系サーバが主系サーバに切り換えられた後，元の正系サーバが障害から回復し再び正系サーバとして稼働したとしても，主系サーバに切り換えられた副系サーバを敢えて再び副系サーバに切り換えることは，稼働中の正系サーバの台数が稼働台数範囲内である限りは，これを行う必要がないものであるし，これを敢えて行おうとすることは，処理能力を維持しつつ多重障害に対しての可用性を確保するため，との引用発明の上記目的に照らせば，不自然な行為と評されるべきものである。 してみれば，上記の引用発明の目的及びこれを実現するための引用発明の構成に鑑みれば，上記周知技術を引用発明に適用する動機は見当たらないといえるものである。 よって，引用発明に上記周知技術を適用することは，当業者が容易になし得たものではない。 イ　そして，上記相違点３に係る本願発明１の「利用可能なプライマリサーバが無い場合は，」「少なくとも１つのプライマリサーバが再び利用可能となるまで，受け取った」「全ての要求を」「前記１つ以上のバックアップサーバに方向付ける」という構成（以下，「相違構成」という。）は，上記引用文献４－５のいずれにも記載されておらず，また，当業者にとって自明な事項でもない。 ウ　したがって，他の相違点について判断するまでもなく，本願発明１は，当業者であっても引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものであるとはいえない。 ２　本願発明２－６について 本願発明２－６も，本願発明１の上記相違構成と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものであるとはいえない。 ３　本願発明７について 本願発明７は，本願発明１に対応する方法の発明であり，本願発明１の上記相違構成と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものであるとはいえない。 ４　本願発明８について 本願発明８は，本願発明７を減縮した発明であり，よって，本願発明１の上記相違構成と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものであるとはいえない。 ５　本願発明９について 本願発明９は，本願発明１に対応するプログラムの発明であり，本願発明１の上記相違構成と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものであるとはいえない。 ６　本願発明１０について 本願発明１０は，本願発明９を減縮した発明であり，よって，本願発明１の上記相違構成と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものであるとはいえない。 第５　原査定の概要及び原査定についての判断 （特許法第２９条２項について） 原査定は，平成２９年５月１日付け手続補正により補正された請求項１－１１について上記引用文献１－５に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができないとしたものである。 しかしながら，平成３０年２月２３日付け手続補正により補正された請求項１－１０に係る発明は，前記「第４」で検討した相違点３に係る上記相違構成と同一の構成を備えるものであるから，上記のとおり，本願発明１と同じ理由により，上記引用発明及び上記引用文献２－５に記載された技術事項に基づいて，当業者が容易に発明をすることができたものではない。したがって，原査定を維持することはできない。 第６　当審拒絶理由について （特許法第３６条第６項第１号について） 当審では，請求項１に係る発明の「ウォームアッププロセスの期間」について，発明の詳細な説明に記載の実施例との対応関係を明確に把握することができず，請求項２－１０についても同様であるから，請求項１－１０に係る発明は，発明の詳細な説明に記載されたものであるとは認められず，特許法第３６条第６項第１号の規定により特許を受けることができないとの拒絶の理由を通知しているが，平成３０年１１月１９日付け手続補正により，「ある期間」と補正された結果，この拒絶の理由は解消した。 第７　むすび 以上のとおり，本願発明１－１０は，当業者が引用発明及び引用文献２－５に記載された技術事項に基づいて容易に発明をすることができたものではない。 したがって，原査定の理由によっては，本願を拒絶することはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。