【事件の表示】
　特願２０１７−　５４５６４「クラスタシステム、クラスタシステムのアップデート管理装置、アップデート振分装置、アップデート管理方法、アップデート振分方法及びプログラム」拒絶査定不服審判事件〔平成３０年１０月　４日出願公開、特開２０１８−１５６５５５、請求項の数（３）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は，平成２９年３月２１日の出願であって，平成３０年２月２８日付けで拒絶の理由が通知され，同年５月９日に意見書が提出され，同年１０月１９日付けで拒絶査定（謄本送達日同年１０月３０日）がなされ，これに対して平成３１年１月３０日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ，同年４月８日付けで審査官により特許法１６４条３項の規定に基づく報告がなされ，令和１年１２月２４日付けで当審により拒絶の理由が通知され，令和２年３月６日に意見書とともに手続補正書が提出されたものである。
第２　原査定の概要
　原査定（平成３０年１０月１９日付け拒絶査定）の概要は次のとおりである。
１．（新規性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。
２．（進歩性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　記　　　（引用文献等については引用文献等一覧参照）
●理由１
・請求項　　　１，５，８
・引用文献等　１
●理由２
・請求項　　　１−３，５−８
・引用文献等　１−３
＜拒絶の理由を発見しない請求項＞
　請求項４に係る発明については、現時点では、拒絶の理由を発見しない。
　　　　　　　　　　　　＜引用文献等一覧＞
１．特開２００４−１６４２３６号公報
２．特開２０１５−５５９１６号公報（周知技術を示す文献）
３．特開２０１２−１９４８９２号公報（周知技術を示す文献）
第３　本願発明
　本願請求項１乃至３に係る発明（以下「本願発明１」乃至「本願発明３」という。）は，令和２年３月６日付け手続補正書の特許請求の範囲の請求項１乃至３に記載された，次のとおりのものと認める。
「　【請求項１】
　サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムであって、
　前記アップデート管理装置は、
　前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理部、
　を備え、
　前記アップデート振分装置は、
　前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分部、
　を備え、
　前記振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分けるクラスタシステム。
　　【請求項２】
　サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムが行うアップデート方法であって、
　前記アップデート管理装置が、前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理ステップ、
　前記アップデート振分装置が、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、判定し、いずれかのサーバに振り分ける振分ステップを有し、
　前記振分ステップにおいて、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分けるアップデート管理方法。
　　【請求項３】
　請求項１に記載の装置としてコンピュータを機能させるためのプログラム。」
第４　引用例
１　引用例１に記載された事項及び引用発明
　当審より，令和１年１２月２４日付けで通知された拒絶理由通知において引用した，本願の出願前に既に公知である，金子　雅志　他，「高可用サーバクラスタにおけるシステム更新方式の検討」，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２００９年１１月１３日，第１０９巻　第２７６号，ｐｐ．５−１０（以下，これを「引用例１」という。）には，関連する図面と共に，次の事項が記載されている。（下線は当審で付加。以下同様。）
Ａ　「
近年、アプリケーションサーバ分野を中心に、高スケーラビリティや冗長化の実現を目的として、スケールアウト型サーバアーキテクチャであるＮ重化サーバクラスタが適用されつつある
Ｂ　「２．２．Ｎ重化サーバクラスタの構成
　
Ｎ重化サーバクラスタでは、
ロードバランサを利用する方式が利用されてきた
ＳＩＰ　Ｓｅｒｖｌｅｔ等の実装においてはサーバにおける障害発生時のサービス継続を目的とした分散制御等がきめ細かく実現出来るロードバランサを前提とする方式が広く採用されている
Ｃ　「２．３．Ｎ重化サーバクラスタにおけるセッションデータ管理
　Ｗｅｂ通販におけるショッピングカートやＶｏＩＰの接続状態など、ＨＴＴＰや
ＳＩＰのアプリケーションにおいては複数メッセージにまたいで共有するデータであるセッションデータを利用する場合が多い
Ｎ重化サーバクラスタでは、クラスタワイドでのデータアクセス手段をセッションデータ管理機能として提供する
セッションデータ管理機能の実装方式としては
図２．４
…（中略）…
Ｂ）
全データ共有型
　
全てのアプリケーションサーバで同じデータを持つ方式。１台のデータ更新が発生した場合、他のサーバのデータも同期更新される
Ｄ　「
図２．４」（８ページ左欄）
Ｅ　「３．システム更新方式
３．１．高可用システムにおけるシステム更新について
　９９．９９９％以上の高い稼働率が求められる通信事業者のサーバシステムを実現するためには、前節で示したような装置故障からの迅速な復旧だけでなく、
システム更新時（アプリケーションの追加・変更、システムの修正モジュール導入）においても、サービスが稼働し続ける必要がある
システム更新時に接続中のセッションを切断せずに継続させることが可能でなければならない
…（中略）…
　
サーバクラスタにおけるアプリケーション更新する場合のもう一つの方式として、アプリケーション更新時に旧アプリケーションのサーバをそのまま維持し（新旧アプリケーションを同時に動作させる）、旧アプリケーションで生成されたセッションは旧アプリケーションで処理し、新アプリケーションで生成されたセッションと新規メッセージは新アプリケーションで処理を行う方式がある
Ｆ　「上記をふまえて、
ロードバランサを含むＮ重化サーバクラスタにおける、ソフトウェア更新の実現手順を図３．１に示す
まず、保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し、新サーバクラスタを起動する
次に、ロードバランサに対して、新規セッションを順次新サーバクラスタで処理するよう、振り分けルールを更新する
旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し
エラーが発生していない場合、旧サーバクラスタで処理しているセッション数がなくなった時点で、旧サーバクラスタを停止し、システム更新は終了する
…（中略）…
　
上記方式により、Ｎ重化サーバクラスタにおいてもサービス無停止でのシステム更新が可能となり
Ｇ　「
図３．１」（１０ページ右欄）
　以上Ａ乃至Ｇの記載から，引用例１には，次の発明（以下，「引用発明」という。）が記載されているといえる。
「近年，アプリケーションサーバ分野を中心に，高スケーラビリティや冗長化の実現を目的として，スケールアウト型サーバアーキテクチャであるＮ重化サーバクラスタが適用されつつあり，
　Ｎ重化サーバクラスタでは，ＳＩＰ　Ｓｅｒｖｌｅｔ等の実装においてはサーバにおける障害発生時のサービス継続を目的とした分散制御等がきめ細かく実現出来るロードバランサを前提とする方式が広く採用されていて，
　ＳＩＰのアプリケーションにおいては複数メッセージにまたいで共有するデータであるセッションデータを利用する場合が多く，
　Ｎ重化サーバクラスタでは，クラスタワイドでのデータアクセス手段をセッションデータ管理機能として提供し，前記セッションデータ管理機能の実装方式としては，全てのアプリケーションサーバで同じデータを持つ方式であって，１台のデータ更新が発生した場合，他のサーバのデータも同期更新される全データ共有型があり，
　システム更新時（アプリケーションの追加・変更，システムの修正モジュール導入）においても，サービスが稼働し続ける必要があるため，システム更新時に接続中のセッションを切断せずに継続させることが可能でなければならず，
　サーバクラスタにおけるアプリケーション更新する場合，アプリケーション更新時に旧アプリケーションのサーバをそのまま維持し（新旧アプリケーションを同時に動作させる），旧アプリケーションで生成されたセッションは旧アプリケーションで処理し，新アプリケーションで生成されたセッションと新規メッセージは新アプリケーションで処理を行う方式があり，
　ロードバランサを含むＮ重化サーバクラスタにおける，ソフトウェア更新の実現手順では，まず，保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し，新サーバクラスタを起動し，次に，ロードバランサに対して，新規セッションを順次新サーバクラスタで処理するよう，振り分けルールを更新し，旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し，エラーが発生していない場合，旧サーバクラスタで処理しているセッション数がなくなった時点で，旧サーバクラスタを停止し，システム更新が終了することによって，
　サービス無停止でのシステム更新が可能となる
Ｎ重化サーバクラスタ。」
２　引用例２に記載された事項
　原査定の拒絶の理由において引用した，本願の出願前に既に公知である，特開２００４−１６４２３６号公報（平成１６年６月１０日公開。以下，これを「引用例２」という。）には，関連する図面と共に，次の事項が記載されている。
Ｈ　「【００１３】
図２は、センターサーバー１０２における制御及び情報の流れの概要を説明するための構成図である。
センターサーバー１０２は、負荷分散管理装置２０１と、Ｗｅｂサービス管理装置２０２（１）、２０２（２）、…、２０２（Ｎ）と、センターサーバー管理装置２０３と、Ｗｅｂサービスデータ管理装置２０４とが接続して構成される
Ｉ　「【００３４】
図６に示した更新処理手段６０１は、センターサーバー１０２のセンターサーバー管理装置２０３内で動作する処理手段であり、更新Ｗｅｂサービスファイル格納装置６０２に格納される更新処理手順に従い、サーバー情報格納装置６０４に格納されるセンターサーバー１０２を構成するコンピュータの情報を基に、負荷分散管理装置２０１の負荷分散処理設定手段６０７を操作してクライアントコンピュータ１０１（Ｘ）からの新規のアクセスをＷｅｂサービス管理装置２０２（２）に振り分ける処理を行い、セッション情報監視手段６０６を通してセッション情報格納装置６０５の情報を監視してから、更新Ｗｅｂサービスファイル格納装置６０２に格納される更新ＷｅｂサービスファイルをＷｅｂサービス管理装置２０２（１）のＷｅｂサービスファイル格納装置２０６に格納する。
更新処理手段６０１は、上記一連の作業をＷｅｂサービス管理装置２０２（１）、２０２（２）、…、２０２（Ｎ）へ順に行う
Ｊ　「【００４８】
ステップＳ１にて
センターサーバー１０２内のセンターサーバー管理装置２０３内の更新処理手段６０１は、タイマーなどの設定により更新Ｗｅｂサービスファイル格納装置６０２内の更新処理手順記憶部７１３の更新処理手順テーブル８００の更新処理開始日時８０４に指定された時間に自動的に起動され、更新処理手順テーブル８００の更新処理ステータス８０３に処理中のステータスを設定することにより一連のデータ更新処理が開始される
Ｋ　「【００５３】
ステップＳ５にて更新処理手段６０１のセッション情報取得処理部７０３より指示を受けたセッション情報監視手段６０６のセッション情報取得処理部７０９はステップＳ６にて、セッション情報格納装置６０５内のセッション情報記憶部７０８のＷｅｂサービス管理装置２０２（１）に関する全セッションのセッション情報テーブル１１００のセッション処理ステータス１１０３を監視し、該ステータスが全て処理終了になったら更新処理手段６０１のセッション情報取得処理部７０３に通知する。
【００５４】
ステップＳ７にて更新Ｗｅｂサービス情報取得処理部７０４は、更新Ｗｅｂサービスファイル格納装置６０２中のＣＧＩプログラム記憶部７１１より更新対象のＣＧＩプログラムファイルを、更新Ｗｅｂサービスファイル格納装置６０２中のＨＴＭＬテンプレート記憶部７１２より更新対象のＨＴＭＬテンプレートファイルを取得する。
【００５５】
ステップＳ８にてＷｅｂサービスファイル更新処理部７０５は、ステップＳ７にて更新Ｗｅｂサービス情報取得処理部７０４が取得した更新対象ファイルのうちＣＧＩプログラムファイルをＷｅｂサービス管理装置２０２（１）のＷｅｂサービスファイル格納装置２０６内のＣＧＩプログラム記憶部６０８に格納し、ＨＴＭＬテンプレートファイルをＷｅｂサービス管理装置２０２（１）のＷｅｂサービスファイル格納装置２０６内のＨＴＭＬテンプレート記憶部６０９に格納する。ステップＳ８までの処理で
Ｗｅｂサービス管理装置２０２（１）で提供するＷｅｂサービスの更新処理は完了し、Ｗｅｂサービス管理装置２０２（１）では更新後のＷｅｂサービスが提供可能な状態になる
【００５６】
ステップＳ２にて取得した更新処理手順に従い負荷分散装置操作処理部７０２はステップＳ９にて、ステップＳ３にて取得した負荷分散装置情報を基に、クライアントコンピュータ１０１（Ｘ）からのアクセスにより実行されるＣＧＩプログラムの引数にＷｅｂサービス管理装置情報記憶部７０７のＷｅｂサービス管理装置情報テーブル１０００のサーバー番号１００３が付加している場合は、指定されたサーバー番号に該当するＷｅｂサービス管理装置でＷｅｂサービスのセッションをそのまま実行するようにＣＧＩプログラムを割り振り、ＣＧＩプログラムの引数にサーバー番号が付加していない新規セッションの場合はＷｅｂサービス管理装置２０２（１）にて実行されるようにＣＧＩプログラムを割り振るように負荷分散管理装置２０１の負荷分散処理設定手段６０７を用いて設定する。」
Ｌ　「【００８１】
【発明の効果】
以上説明したように、本発明によれば、
サーバー管理者が予め更新処理実施の設定をしておけば、インターネット上のサーバーにおいて提供されるＷｅｂサービスを停止させることなく、サーバー管理者が直接更新作業をしなくとも自動的に更新することができる
３　引用例３に記載された事項
　原査定の拒絶の理由において引用した，本願の出願前に既に公知である，特開２０１５−５５９１６号公報（平成２７年３月２３日公開。以下，これを「引用例３」という。）には，関連する図面と共に，次の事項が記載されている。
Ｍ　「【００２６】
　図２を参照すると、ファームウェア更新手段１４は、情報処理装置１０が各種のアプリケーションプログラムを実行中に、利用者から入力装置（図示せず）を介してファームウェアの更新の指示を受け取ると、まず、ＣＰＵの負荷状況を示すＣＰＵ負荷値の計測を実行する（ステップＳ１０）。ＣＰＵ負荷値は、例えば、ＣＰＵの使用率、一定時間毎のＣＰＵ使用率の平均値または実行中のプログラムの数等である。
【００２７】
　次に、
ファームウェア更新手段１４は、ステップＳ１０で計測したＣＰＵ負荷値が所定のＣＰＵ負荷閾値以上であるか否かを判断する
【００２８】
　ステップＳ１１において、ＣＰＵ負荷値が所定のＣＰＵ負荷閾値以上である場合は（ステップＳ１１で「ＹＥＳ」の場合）、ファームウェア更新手段１４は、新たに、ＣＰＵ負荷値の計測を実行した後、ステップＳ１１の処理を再度実行する。
【００２９】
　一方、ステップＳ１１において、
ＣＰＵ負荷値が所定のＣＰＵ負荷閾値未満である場合
ファームウェア更新手段１４は、ＯＳおよびアプリケーションプログラムの実行を一時的に停止させる
【００３０】
　次に、
ファームウェア更新手段１４は、外部記憶装置２０から更新用ファームウェア２１を取得し、ファームウェア記憶手段１２に格納されているファームウェア１６を、更新用ファームウェア２１で書き換える
４　引用例４に記載された事項
　原査定の拒絶の理由において引用した，本願の出願前に既に公知である，特開２０１２−１９４８９２号公報（平成２４年１０月１１日公開。以下，これを「引用例４」という。）には，関連する図面と共に，次の事項が記載されている。
Ｎ　「【００２６】
　アップデート見積もり手段１３は、パッチ記憶部１２から所要時間を読み出す。アップデート見積もり手段１３は、読み出した所要時間以上継続して、負荷の合計の予測値が所定の閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する。アップデート見積もり手段１３は、抽出した時間帯に、読み出した所要時間に対応する、ソフトウェアの更新の実行予定を割り当てる。
【００２７】
　
アップデート実行手段１４は、アップデート見積もり手段１３が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるモジュールによるサービスの提供を停止させる
アップデート実行手段１４は、モジュールにサービスの提供を停止させた後、そのモジュールのソフトウェアに対して更新を実行する
【００２８】
　各モジュールは、各モジュールに接続されている、例えば計算装置や端末装置などに対して、何らかのサービスを提供する。各モジュールは、ソフトウェアにより制御される。各モジュールは、例えば、ＲＡＩＤに代表されるディスクアレイ装置の、ソフトウェアにより制御されるコントローラ部である。各モジュールは、コンピュータクラスタにおけるコンピュータや、コンピュータのネットワークインターフェースのコントローラであってもよい。本発明の各実施形態では、モジュールがディスクアレイ装置のＩ／Ｏを制御するコントローラ部である場合の説明を行う。 」
Ｏ　「【００８３】
　図８は、本実施形態のソフトウェア更新装置１の、更新の実行予定を割り当てる動作を表すフローチャートである。ソフトウェア更新装置１は、例えば、アップデート指示部４１から適用すべき更新データを特定する情報を受け取り、以下の動作を開始する。
【００８４】
　図８を参照すると、まず、
アップデート見積もり部１３が、各コントローラ部のソフトウェアに適用する更新データに対応付けられた更新の所要時間を、パッチ記憶部１２から読み出す
…中略…
【００９２】
　
アップデート見積もり部１３は、次に、更新データを適用する際のパスの切替要否を判定する
【００９３】
　単体の更新データを適用する場合、アップデート見積もり部１３は、パッチ記憶部１２から読み出した、適用する更新データの切替要否のデータに基づき、パスの切替要否を判定すればよい。ソフトウェアに対してパッチセットを適用する場合、パッチ記憶部１２がそのパッチセットのパス切替要否のデータを記憶していれば、アップデート見積もり部１３は、そのデータに基づきパスの切替要否を判定すればよい。パッチ記憶部１２がそのパッチセットのパス切替要否のデータを記憶していない場合、アップデート見積もり部１３は、そのパッチセットが、パス切替が必要な更新データを含んでいれば、パス切替が必要と判定すればよい。
【００９４】
　パス切替が不要である場合（ステップＳ２３、Ｎ）、アップデート実行部１４はすぐに更新を実行すればよい（ステップＳ２７）。更新の実行については後述する。
【００９５】
　
パス切替が必要である場合
、アップデート見積もり部１３は、更新の所要時間以上継続して、負荷の合計値が閾値を下回る時間帯を、負荷記憶部１１が記憶する負荷推移データから抽出する
【００９６】
　アップデート見積もり部１３は、更新の所要時間を、パッチ記憶部１２から読み出せばよい。
【００９７】
　図１０は、負荷記憶部１１が記憶する負荷推移データの例を表す図である。負荷推移データは、少なくとも負荷の合計値の推移を含んでいればよい。負荷記憶部１１が記憶する負荷の値は、例えばＩＯＰＳである。
【００９８】
　また、アップデート見積もり部１３は、負荷の合計値に対する閾値を、閾値記憶部１５から読み出せばよい。前述のように、閾値記憶部１５が記憶する閾値は、時刻によって変動してもよい。この場合、例えばディスクアレイ装置２の管理者が、時刻に応じて適宜定めた閾値を、予め閾値記憶部１５に記憶させておけばよい。閾値記憶部１５が記憶する閾値は、過去の同時刻において、例えば負荷監視部１６が観測した、負荷の値のばらつきの大きさに応じた値であってもよい。閾値記憶部１５が記憶する閾値は、例えば、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、各時刻における負荷の観測値のばらつきの大きさに応じた値を引いた値であってもよい。この場合、負荷の観測値のばらつきが大きい時刻の閾値は小さく、負荷の観測値のばらつきが小さい時刻の閾値は大きくなる。
【００９９】
　図１１は、アップデート見積もり部１３が抽出した時間帯を表す図である。アップデート見積もり部１３は、図１１のようなテーブルを生成して、時間帯の抽出を行うことができる。図１１の「負荷の閾値」は、閾値記憶部１５が記憶する閾値である。「負荷の予測値」は、負荷記憶部１１が記憶する負荷の合計値である。アップデート見積もり部１３は、「負荷の閾値」より「負荷の予測値」が小さく、「差分」が正である時間帯を抽出する。図１１でアップデート見積もり部１３が抽出した時間帯は、実行可否が「ＯＫ」である時間帯である。
【０１００】
　条件に適合する時間帯が存在しない場合（ステップＳ２５、Ｎ）、ソフトウェア更新装置１は、更新の実行や更新の実行予定の割り当てを行わずに、処理を終了する。この場合は、例えばディスクアレイ装置２の管理者が手動で更新を実行するなどすればよい。
【０１０１】
　
条件に適合する時間帯が存在する場合
、その時間帯が現在であり即時更新を実行することが可能であれば
、アップデート実行部１４は更新を実行する
【０１０２】
　条件に適合する時間帯が現在ではなく、即時更新を実行できない場合（ステップＳ２６、Ｎ）、アップデート見積もり部１３は、更新の実行予定を割り当てる（ステップＳ２８）。この場合、更新の実行予定時刻に、アップデート実行部１４が、以下で述べるように更新を実行すればよい。」
第５　対比・判断
１　本願発明１について
（１）　対比
　本願発明１と引用発明とを対比する。
（あ）引用発明の「Ｎ重化サーバクラスタ」は，本願発明１の「クラスタシステム」に相当する。
（い）引用発明の「Ｎ重化サーバクラスタ」は，「クラスタワイドでのデータアクセス手段をセッションデータ管理機能として提供」するものであって，「セッションデータ管理機能の実装方式」として，「全てのアプリケーションサーバで同じデータを持つ方式」の「１台のデータ更新が発生した場合，他のサーバのデータも同期更新される全データ共有型」である。そして，当該「アプリケーションサーバ」は，本願発明１の「サーバ」に対応し，上記（あ）の認定を踏まえると，引用発明と本願発明１とは，“サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバ”の点で一致する。
（う）引用発明は，「保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し」た上で，「システム更新が可能となる」ものであるから，当該「保守システム」は，本願発明１の「サーバのソフトウェアのアップデートを行うアップデート管理装置」に対応し，引用発明と本願発明１とは，“サーバのソフトウェアのアップデートを行うアップデート管理装置”を有する点で一致する。
（え）引用発明の「Ｎ重化サーバクラスタ」は「ロードバランサ」を含み，「ソフトウェア更新の実現手順」において，当該「ロードバランサに対して，新規セッションを順次新サーバクラスタで処理するよう，振り分けルールを更新し，旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し，エラーが発生していない場合，旧サーバクラスタで処理しているセッション数がなくなった時点で，旧サーバクラスタを停止し，システム更新が終了」することによって，「システム更新が可能となる」ものであるから，引用発明の「ロードバランサ」が本願発明１の「アップデート振分装置」に対応し，引用発明と本願発明１とは，“前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置”を有する点で一致する。
　以上（あ）乃至（う）の認定も考慮すると，引用発明と本願発明１とは，“サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と，前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステム”である点で一致するといえる。
（お）引用発明は，「ロードバランサを含むＮ重化サーバクラスタにおける，ソフトウェア更新の実現手順」において，「保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し，新サーバクラスタを起動し，…（中略）…旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し，エラーが発生していない場合，旧サーバクラスタで処理しているセッション数がなくなった時点で，旧サーバクラスタを停止し，システム更新が終了することによって，サービス無停止でのシステム更新が可能となる」ものであるから，引用発明と本願発明１とは，“アップデート管理装置は，前記ソフトウェアのアップデートの指示がなされた場合に，前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて，前記サーバが用いているソフトウェアをアップデートするサーバ管理部を備え”る点で一致する。
（か）引用発明は，「ソフトウェア更新の実現手順」において，「ロードバランサに対して，新規セッションを順次新サーバクラスタで処理するよう，振り分けルールを更新し，旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し，エラーが発生していない場合，旧サーバクラスタで処理しているセッション数がなくなった時点で，旧サーバクラスタを停止し，システム更新が終了することによって，サービス無停止でのシステム更新が可能となる」ものであるから，引用発明と本願発明１とは，“アップデート振分装置は，前記ソフトウェアのアップデート中のサーバに対する処理要求を，前記処理要求に基づいて，ソフトウェアのアップデートがなされた新サーバ，又は，ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し，いずれかのサーバに振り分ける振分部を備える”点で一致する。
（き）以上，（あ）乃至（か）の検討から，引用発明と本願発明１とは，次の一致点及び相違点を有する。
〈一致点〉
　サーバ間でセッション維持に必要なデータを共有しているＮ−Ａｃｔｉｖｅ構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と，前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムであって，
　前記アップデート管理装置は，
　前記ソフトウェアのアップデートの指示がなされた場合に，前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて，前記サーバが用いているソフトウェアをアップデートするサーバ管理部，
　を備え，
　前記アップデート振分装置は，
　前記ソフトウェアのアップデート中のサーバに対する処理要求を，前記処理要求に基づいて，ソフトウェアのアップデートがなされた新サーバ，又は，ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し，いずれかのサーバに振り分ける振分部，
　を備えるクラスタシステム。
〈相違点〉
　本願発明１の「振分部」は，「前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分ける」ものであるのに対し，引用発明は，「ロードバランサに対して，新規セッションを順次新サーバクラスタで処理するよう，振り分けルールを更新し，旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し，エラーが発生していない場合，旧サーバクラスタで処理しているセッション数がなくなった時点で，旧サーバクラスタを停止し，システム更新が終了する」ものであって，処理要求の内容及び当該要求を処理したサーバの存在如何によって処理要求を振り分けるものではない点。
（２）　相違点についての判断
　上記相違点について検討する。
　本願発明１は，ソフトウェアのアップデートの技術に関し（本件明細書段落０００１），従来，Ｗｅｂサーバホスティング等の分野では，データセンタのようなサーバ管理事業者が一括して複数のサーバを管理し，サービス提供事業者をホスティングするＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ａｓ　ａ　Ｓｅｒｖｉｃｅ）等と呼ばれる形態が知られている一方，電話のようなライフラインサービスでは，二重化により高可用性を実現しており，電話サービスをＩａａＳ上で実現するために，サーバをＮ台クラスタリングしたＮ−Ａｃｔｉｖｅ構成により可用性及び設備利用効率を高める技術が利用されていることを背景とし（同段落０００２），サービス無停止でソフトウェアのアップデートを行う場合，通常はアップデート先へのデータ引き継ぎ処理が必要となり，データ引継処理を行うためには，アップデート先へデータの同期に加えて，アップデート前のデータ形式をアップデート後のデータ形式に変換をする必要があることを解決しようとする課題とし（同段落０００５），クラスタシステムにおいて，ソフトウェアのアップデートを行う際に要する開発コストを削減することができる技術の提供を目的としたものであって（同段落０００６），とりわけ，上記相違点に係る構成を採用することにより，アップデート振分装置がアップデート中のサーバに対する処理要求を新サーバ又は旧サーバのいずれで処理すべきかを判断し，該当するサーバに当該処理要求を振り分け，データ引継処理に要するコストを削減することができるため，クラスタシステムにおいて，ソフトウェアのアップデートを行う際に要する開発コストを削減することが可能となるという効果を奏するものである（同段落００４６）。
　一方引用発明は，「Ｎ重化サーバクラスタ」において，「サーバクラスタにおけるアプリケーション更新する場合，アプリケーション更新時に旧アプリケーションのサーバをそのまま維持し（新旧アプリケーションを同時に動作させる），旧アプリケーションで生成されたセッションは旧アプリケーションで処理し，新アプリケーションで生成されたセッションと新規メッセージは新アプリケーションで処理を行う方式」が採用され，「ソフトウェア更新の実現手順」では，「まず，保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し，新サーバクラスタを起動し，次に，ロードバランサに対して，新規セッションを順次新サーバクラスタで処理するよう，振り分けルールを更新し，旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し，エラーが発生していない場合，旧サーバクラスタで処理しているセッション数がなくなった時点で，旧サーバクラスタを停止し，システム更新が終了する」ものである。
　そうすると，「ロードバランサ」に対して，「振り分けルールを更新」する引用発明においては，上記相違点に係る構成を採用する動機付けを見いだすことはできず，このことは，その他上記第４に示した引用例２乃至４にも記載されていない。
　したがって，「ロードバランサ」に対して「振り分けルールを更新」するに過ぎない引用発明からは，当業者といえども相違点に係る構成を導き出すことは容易とはいえず，また，相違点に係る構成は，本願の出願前に周知な構成ともいえないから，本願発明１は，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
２　本願発明２について
　本願発明２は，本願発明１とカテゴリー表現のみ異なるものであって，本願発明１と同じ理由により，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
３　本願発明３について
　本願発明３は，請求項１を引用するものであって，本願発明１と同じ理由により，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
第６　当審拒絶理由の概要
＜特許法３７条について＞
　当審より，請求項２乃至４に係る発明は，請求項１に係る発明と共通の技術的特徴を有しているが，当該技術的特徴は，上記引用例１の開示内容に照らして，先行技術に対する貢献をもたらすものではないから，特別な技術的特徴であるとはいえず，請求項１に係る発明と，請求項２乃至４に係る発明との間に，他に同一の又は対応する特別な技術的特徴は存在せず，また請求項６及び７に係る発明についても同様であり，特許法３７条に規定する要件を満たしていない旨の拒絶理由を通知したが，上記第３に示すとおり補正され，本拒絶理由は解消した。
＜特許法２９条１項３号について＞
　当審より，請求項１及び５に係る発明は，その出願前日本国内において頒布された上記引用例１に記載された発明であるから，特許法２９条１項３号に該当し，特許を受けることができない旨の拒絶理由を通知したが，上記第３に示すとおり補正され，上記第５　１（１）に示す相違点を有することとなり，本拒絶理由は解消した。
＜特許法２９条２項について＞
　当審より，請求項１及び５に係る発明は，その出願前日本国内において頒布された上記引用例１に記載された発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない旨の拒絶理由を通知したが，上記第３に示すとおり補正され，上記第５で判断を示したとおり，当業者であっても，引用発明及び引用例２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえず，本拒絶理由は解消した。
第７　原査定についての判断
　上記第３に示すとおり，補正後の請求項１乃至３は，「振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分ける」という技術的事項を有するものとなった。当該「振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分ける」ことは，原査定における引用文献１乃至３（上記第３に示す引用例２乃至４）には記載されておらず，本件出願前における周知技術でもないので，本願発明１乃至３は，当業者であっても，原査定における引用文献１乃至３に基づいて容易に発明できたものではない。したがって，原査定を維持することはできない。
第８　むすび
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。