ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F 審判 査定不服 1項3号刊行物記載 取り消して特許、登録 G06F 審判 査定不服 特37 条出願の単一性( 平成16 年1 月1 日から) 取り消して特許、登録 G06F |
---|---|
管理番号 | 1361270 |
審判番号 | 不服2019-1219 |
総通号数 | 245 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2020-05-29 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2019-01-30 |
確定日 | 2020-04-21 |
事件の表示 | 特願2017- 54564「クラスタシステム、クラスタシステムのアップデート管理装置、アップデート振分装置、アップデート管理方法、アップデート振分方法及びプログラム」拒絶査定不服審判事件〔平成30年10月 4日出願公開、特開2018-156555、請求項の数(3)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は,平成29年3月21日の出願であって,平成30年2月28日付けで拒絶の理由が通知され,同年5月9日に意見書が提出され,同年10月19日付けで拒絶査定(謄本送達日同年10月30日)がなされ,これに対して平成31年1月30日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ,同年4月8日付けで審査官により特許法164条3項の規定に基づく報告がなされ,令和1年12月24日付けで当審により拒絶の理由が通知され,令和2年3月6日に意見書とともに手続補正書が提出されたものである。 第2 原査定の概要 原査定(平成30年10月19日付け拒絶査定)の概要は次のとおりである。 1.(新規性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。 2.(進歩性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 記 (引用文献等については引用文献等一覧参照) ●理由1 ・請求項 1,5,8 ・引用文献等 1 ●理由2 ・請求項 1-3,5-8 ・引用文献等 1-3 <拒絶の理由を発見しない請求項> 請求項4に係る発明については、現時点では、拒絶の理由を発見しない。 <引用文献等一覧> 1.特開2004-164236号公報 2.特開2015-55916号公報(周知技術を示す文献) 3.特開2012-194892号公報(周知技術を示す文献) 第3 本願発明 本願請求項1乃至3に係る発明(以下「本願発明1」乃至「本願発明3」という。)は,令和2年3月6日付け手続補正書の特許請求の範囲の請求項1乃至3に記載された,次のとおりのものと認める。 「 【請求項1】 サーバ間でセッション維持に必要なデータを共有しているN-Active構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムであって、 前記アップデート管理装置は、 前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理部、 を備え、 前記アップデート振分装置は、 前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、又は、ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し、いずれかのサーバに振り分ける振分部、 を備え、 前記振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分けるクラスタシステム。 【請求項2】 サーバ間でセッション維持に必要なデータを共有しているN-Active構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と、前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムが行うアップデート方法であって、 前記アップデート管理装置が、前記ソフトウェアのアップデートの指示がなされた場合に、前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて、前記サーバが用いているソフトウェアをアップデートするサーバ管理ステップ、 前記アップデート振分装置が、前記ソフトウェアのアップデート中のサーバに対する処理要求を、前記処理要求に基づいて、ソフトウェアのアップデートがなされた新サーバ、判定し、いずれかのサーバに振り分ける振分ステップを有し、 前記振分ステップにおいて、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分けるアップデート管理方法。 【請求項3】 請求項1に記載の装置としてコンピュータを機能させるためのプログラム。」 第4 引用例 1 引用例1に記載された事項及び引用発明 当審より,令和1年12月24日付けで通知された拒絶理由通知において引用した,本願の出願前に既に公知である,金子 雅志 他,「高可用サーバクラスタにおけるシステム更新方式の検討」,電子情報通信学会技術研究報告,社団法人電子情報通信学会,2009年11月13日,第109巻 第276号,pp.5-10(以下,これを「引用例1」という。)には,関連する図面と共に,次の事項が記載されている。(下線は当審で付加。以下同様。) A 「近年、アプリケーションサーバ分野を中心に、高スケーラビリティや冗長化の実現を目的として、スケールアウト型サーバアーキテクチャであるN重化サーバクラスタが適用されつつある。」(5ページ右欄7-11行) B 「2.2.N重化サーバクラスタの構成 N重化サーバクラスタでは、N台のサーバに対して処理を分散させるためにDNSラウンドロビンを利用する方式と、ロードバランサを利用する方式が利用されてきた。DNSラウンドロビンによる方式では、システムを構成する上でロードバランサのようなサーバ以外の装置が必要にならないため安価にシステムを構築出来るが、SIP Servlet等の実装においてはサーバにおける障害発生時のサービス継続を目的とした分散制御等がきめ細かく実現出来るロードバランサを前提とする方式が広く採用されている。そのため、本稿で対象とするサーバクラスタもロードバランサを前提とした実装とする。」(6ページ右欄下から8行-7ページ左欄上から6行) C 「2.3.N重化サーバクラスタにおけるセッションデータ管理 Web通販におけるショッピングカートやVoIPの接続状態など、HTTPやSIPのアプリケーションにおいては複数メッセージにまたいで共有するデータであるセッションデータを利用する場合が多い。N重化サーバクラスタにおいて、セッションデータを単純に単一サーバのローカルなメモリやディスク上に置いてしまうと、ロードバランサが後続の信号を他のサーバに振り分けてしまった際に処理の継続が不可能になってしまう。このような状況を防ぐために、N重化サーバクラスタでは、クラスタワイドでのデータアクセス手段をセッションデータ管理機能として提供する。セッションデータ管理機能の実装方式としては主に以下に示す4種類が存在する(図2.4)。 …(中略)… B)全データ共有型 全てのアプリケーションサーバで同じデータを持つ方式。1台のデータ更新が発生した場合、他のサーバのデータも同期更新される。」(7ページ右欄1-24行) D 「 図2.4」(8ページ左欄) E 「3.システム更新方式 3.1.高可用システムにおけるシステム更新について 99.999%以上の高い稼働率が求められる通信事業者のサーバシステムを実現するためには、前節で示したような装置故障からの迅速な復旧だけでなく、システム更新時(アプリケーションの追加・変更、システムの修正モジュール導入)においても、サービスが稼働し続ける必要がある。また、単にサービス無停止でシステム更新が可能というだけでなく、システム更新時に接続中のセッションを切断せずに継続させることが可能でなければならない。 …(中略)… サーバクラスタにおけるアプリケーション更新する場合のもう一つの方式として、アプリケーション更新時に旧アプリケーションのサーバをそのまま維持し(新旧アプリケーションを同時に動作させる)、旧アプリケーションで生成されたセッションは旧アプリケーションで処理し、新アプリケーションで生成されたセッションと新規メッセージは新アプリケーションで処理を行う方式がある(オーバーラップ更新方式)。」(9ページ左欄下から10行-右欄下から9行) F 「上記をふまえて、ロードバランサを含むN重化サーバクラスタにおける、ソフトウェア更新の実現手順を図3.1に示す。まず、保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し、新サーバクラスタを起動する。次に、ロードバランサに対して、新規セッションを順次新サーバクラスタで処理するよう、振り分けルールを更新する。その後、旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し、エラーが発生していれば、ロードバランサの振り分けルールを元に戻し、旧ファイル動作状態に切り戻す。エラーが発生していない場合、旧サーバクラスタで処理しているセッション数がなくなった時点で、旧サーバクラスタを停止し、システム更新は終了する。 …(中略)… 上記方式により、N重化サーバクラスタにおいてもサービス無停止でのシステム更新が可能となり、方式的には通信事業者の高い可用性への要求をクリアできると思われる。」(10ページ左欄5行-右欄9行) G 「 図3.1」(10ページ右欄) 以上A乃至Gの記載から,引用例1には,次の発明(以下,「引用発明」という。)が記載されているといえる。 「近年,アプリケーションサーバ分野を中心に,高スケーラビリティや冗長化の実現を目的として,スケールアウト型サーバアーキテクチャであるN重化サーバクラスタが適用されつつあり, N重化サーバクラスタでは,SIP Servlet等の実装においてはサーバにおける障害発生時のサービス継続を目的とした分散制御等がきめ細かく実現出来るロードバランサを前提とする方式が広く採用されていて, SIPのアプリケーションにおいては複数メッセージにまたいで共有するデータであるセッションデータを利用する場合が多く, N重化サーバクラスタでは,クラスタワイドでのデータアクセス手段をセッションデータ管理機能として提供し,前記セッションデータ管理機能の実装方式としては,全てのアプリケーションサーバで同じデータを持つ方式であって,1台のデータ更新が発生した場合,他のサーバのデータも同期更新される全データ共有型があり, システム更新時(アプリケーションの追加・変更,システムの修正モジュール導入)においても,サービスが稼働し続ける必要があるため,システム更新時に接続中のセッションを切断せずに継続させることが可能でなければならず, サーバクラスタにおけるアプリケーション更新する場合,アプリケーション更新時に旧アプリケーションのサーバをそのまま維持し(新旧アプリケーションを同時に動作させる),旧アプリケーションで生成されたセッションは旧アプリケーションで処理し,新アプリケーションで生成されたセッションと新規メッセージは新アプリケーションで処理を行う方式があり, ロードバランサを含むN重化サーバクラスタにおける,ソフトウェア更新の実現手順では,まず,保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し,新サーバクラスタを起動し,次に,ロードバランサに対して,新規セッションを順次新サーバクラスタで処理するよう,振り分けルールを更新し,旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し,エラーが発生していない場合,旧サーバクラスタで処理しているセッション数がなくなった時点で,旧サーバクラスタを停止し,システム更新が終了することによって, サービス無停止でのシステム更新が可能となる N重化サーバクラスタ。」 2 引用例2に記載された事項 原査定の拒絶の理由において引用した,本願の出願前に既に公知である,特開2004-164236号公報(平成16年6月10日公開。以下,これを「引用例2」という。)には,関連する図面と共に,次の事項が記載されている。 H 「【0013】 図2は、センターサーバー102における制御及び情報の流れの概要を説明するための構成図である。 センターサーバー102は、負荷分散管理装置201と、Webサービス管理装置202(1)、202(2)、…、202(N)と、センターサーバー管理装置203と、Webサービスデータ管理装置204とが接続して構成される。」 I 「【0034】 図6に示した更新処理手段601は、センターサーバー102のセンターサーバー管理装置203内で動作する処理手段であり、更新Webサービスファイル格納装置602に格納される更新処理手順に従い、サーバー情報格納装置604に格納されるセンターサーバー102を構成するコンピュータの情報を基に、負荷分散管理装置201の負荷分散処理設定手段607を操作してクライアントコンピュータ101(X)からの新規のアクセスをWebサービス管理装置202(2)に振り分ける処理を行い、セッション情報監視手段606を通してセッション情報格納装置605の情報を監視してから、更新Webサービスファイル格納装置602に格納される更新WebサービスファイルをWebサービス管理装置202(1)のWebサービスファイル格納装置206に格納する。更新処理手段601は、上記一連の作業をWebサービス管理装置202(1)、202(2)、…、202(N)へ順に行う。」 J 「【0048】 ステップS1にてセンターサーバー102内のセンターサーバー管理装置203内の更新処理手段601は、タイマーなどの設定により更新Webサービスファイル格納装置602内の更新処理手順記憶部713の更新処理手順テーブル800の更新処理開始日時804に指定された時間に自動的に起動され、更新処理手順テーブル800の更新処理ステータス803に処理中のステータスを設定することにより一連のデータ更新処理が開始される。」 K 「【0053】 ステップS5にて更新処理手段601のセッション情報取得処理部703より指示を受けたセッション情報監視手段606のセッション情報取得処理部709はステップS6にて、セッション情報格納装置605内のセッション情報記憶部708のWebサービス管理装置202(1)に関する全セッションのセッション情報テーブル1100のセッション処理ステータス1103を監視し、該ステータスが全て処理終了になったら更新処理手段601のセッション情報取得処理部703に通知する。 【0054】 ステップS7にて更新Webサービス情報取得処理部704は、更新Webサービスファイル格納装置602中のCGIプログラム記憶部711より更新対象のCGIプログラムファイルを、更新Webサービスファイル格納装置602中のHTMLテンプレート記憶部712より更新対象のHTMLテンプレートファイルを取得する。 【0055】 ステップS8にてWebサービスファイル更新処理部705は、ステップS7にて更新Webサービス情報取得処理部704が取得した更新対象ファイルのうちCGIプログラムファイルをWebサービス管理装置202(1)のWebサービスファイル格納装置206内のCGIプログラム記憶部608に格納し、HTMLテンプレートファイルをWebサービス管理装置202(1)のWebサービスファイル格納装置206内のHTMLテンプレート記憶部609に格納する。ステップS8までの処理でWebサービス管理装置202(1)で提供するWebサービスの更新処理は完了し、Webサービス管理装置202(1)では更新後のWebサービスが提供可能な状態になる。 【0056】 ステップS2にて取得した更新処理手順に従い負荷分散装置操作処理部702はステップS9にて、ステップS3にて取得した負荷分散装置情報を基に、クライアントコンピュータ101(X)からのアクセスにより実行されるCGIプログラムの引数にWebサービス管理装置情報記憶部707のWebサービス管理装置情報テーブル1000のサーバー番号1003が付加している場合は、指定されたサーバー番号に該当するWebサービス管理装置でWebサービスのセッションをそのまま実行するようにCGIプログラムを割り振り、CGIプログラムの引数にサーバー番号が付加していない新規セッションの場合はWebサービス管理装置202(1)にて実行されるようにCGIプログラムを割り振るように負荷分散管理装置201の負荷分散処理設定手段607を用いて設定する。」 L 「【0081】 【発明の効果】 以上説明したように、本発明によれば、サーバー管理者が予め更新処理実施の設定をしておけば、インターネット上のサーバーにおいて提供されるWebサービスを停止させることなく、サーバー管理者が直接更新作業をしなくとも自動的に更新することができる。その際、ユーザーが連続する一連のWebサービスを利用している途中である場合には該セッションが終了するまでは更新前のWebサービスを提供し、新規のユーザーには更新後のWebサービスを提供することにより、ユーザーに違和感を与えないで更新処理を実行することができる。」 3 引用例3に記載された事項 原査定の拒絶の理由において引用した,本願の出願前に既に公知である,特開2015-55916号公報(平成27年3月23日公開。以下,これを「引用例3」という。)には,関連する図面と共に,次の事項が記載されている。 M 「【0026】 図2を参照すると、ファームウェア更新手段14は、情報処理装置10が各種のアプリケーションプログラムを実行中に、利用者から入力装置(図示せず)を介してファームウェアの更新の指示を受け取ると、まず、CPUの負荷状況を示すCPU負荷値の計測を実行する(ステップS10)。CPU負荷値は、例えば、CPUの使用率、一定時間毎のCPU使用率の平均値または実行中のプログラムの数等である。 【0027】 次に、ファームウェア更新手段14は、ステップS10で計測したCPU負荷値が所定のCPU負荷閾値以上であるか否かを判断する(ステップS11)。 【0028】 ステップS11において、CPU負荷値が所定のCPU負荷閾値以上である場合は(ステップS11で「YES」の場合)、ファームウェア更新手段14は、新たに、CPU負荷値の計測を実行した後、ステップS11の処理を再度実行する。 【0029】 一方、ステップS11において、CPU負荷値が所定のCPU負荷閾値未満である場合(ステップS11で「NO」の場合)、ファームウェア更新手段14は、OSおよびアプリケーションプログラムの実行を一時的に停止させる(ステップS12)。 【0030】 次に、ファームウェア更新手段14は、外部記憶装置20から更新用ファームウェア21を取得し、ファームウェア記憶手段12に格納されているファームウェア16を、更新用ファームウェア21で書き換える(ステップS13)。 」 4 引用例4に記載された事項 原査定の拒絶の理由において引用した,本願の出願前に既に公知である,特開2012-194892号公報(平成24年10月11日公開。以下,これを「引用例4」という。)には,関連する図面と共に,次の事項が記載されている。 N 「【0026】 アップデート見積もり手段13は、パッチ記憶部12から所要時間を読み出す。アップデート見積もり手段13は、読み出した所要時間以上継続して、負荷の合計の予測値が所定の閾値を下回る時間帯を、負荷記憶部11が記憶する負荷推移データから抽出する。アップデート見積もり手段13は、抽出した時間帯に、読み出した所要時間に対応する、ソフトウェアの更新の実行予定を割り当てる。 【0027】 アップデート実行手段14は、アップデート見積もり手段13が割り当てた実行予定におけるソフトウェアの更新の実行開始時刻になると、ソフトウェアの更新の対象となるモジュールによるサービスの提供を停止させる。アップデート実行手段14は、モジュールにサービスの提供を停止させた後、そのモジュールのソフトウェアに対して更新を実行する。 【0028】 各モジュールは、各モジュールに接続されている、例えば計算装置や端末装置などに対して、何らかのサービスを提供する。各モジュールは、ソフトウェアにより制御される。各モジュールは、例えば、RAIDに代表されるディスクアレイ装置の、ソフトウェアにより制御されるコントローラ部である。各モジュールは、コンピュータクラスタにおけるコンピュータや、コンピュータのネットワークインターフェースのコントローラであってもよい。本発明の各実施形態では、モジュールがディスクアレイ装置のI/Oを制御するコントローラ部である場合の説明を行う。 」 O 「【0083】 図8は、本実施形態のソフトウェア更新装置1の、更新の実行予定を割り当てる動作を表すフローチャートである。ソフトウェア更新装置1は、例えば、アップデート指示部41から適用すべき更新データを特定する情報を受け取り、以下の動作を開始する。 【0084】 図8を参照すると、まず、アップデート見積もり部13が、各コントローラ部のソフトウェアに適用する更新データに対応付けられた更新の所要時間を、パッチ記憶部12から読み出す(ステップS21)。 …中略… 【0092】 アップデート見積もり部13は、次に、更新データを適用する際のパスの切替要否を判定する(ステップS22)。 【0093】 単体の更新データを適用する場合、アップデート見積もり部13は、パッチ記憶部12から読み出した、適用する更新データの切替要否のデータに基づき、パスの切替要否を判定すればよい。ソフトウェアに対してパッチセットを適用する場合、パッチ記憶部12がそのパッチセットのパス切替要否のデータを記憶していれば、アップデート見積もり部13は、そのデータに基づきパスの切替要否を判定すればよい。パッチ記憶部12がそのパッチセットのパス切替要否のデータを記憶していない場合、アップデート見積もり部13は、そのパッチセットが、パス切替が必要な更新データを含んでいれば、パス切替が必要と判定すればよい。 【0094】 パス切替が不要である場合(ステップS23、N)、アップデート実行部14はすぐに更新を実行すればよい(ステップS27)。更新の実行については後述する。 【0095】 パス切替が必要である場合(ステップS23、Y)、アップデート見積もり部13は、更新の所要時間以上継続して、負荷の合計値が閾値を下回る時間帯を、負荷記憶部11が記憶する負荷推移データから抽出する(ステップS24)。 【0096】 アップデート見積もり部13は、更新の所要時間を、パッチ記憶部12から読み出せばよい。 【0097】 図10は、負荷記憶部11が記憶する負荷推移データの例を表す図である。負荷推移データは、少なくとも負荷の合計値の推移を含んでいればよい。負荷記憶部11が記憶する負荷の値は、例えばIOPSである。 【0098】 また、アップデート見積もり部13は、負荷の合計値に対する閾値を、閾値記憶部15から読み出せばよい。前述のように、閾値記憶部15が記憶する閾値は、時刻によって変動してもよい。この場合、例えばディスクアレイ装置2の管理者が、時刻に応じて適宜定めた閾値を、予め閾値記憶部15に記憶させておけばよい。閾値記憶部15が記憶する閾値は、過去の同時刻において、例えば負荷監視部16が観測した、負荷の値のばらつきの大きさに応じた値であってもよい。閾値記憶部15が記憶する閾値は、例えば、計算上提供するサービスに遅延などの影響が及ばないような負荷の合計値から、各時刻における負荷の観測値のばらつきの大きさに応じた値を引いた値であってもよい。この場合、負荷の観測値のばらつきが大きい時刻の閾値は小さく、負荷の観測値のばらつきが小さい時刻の閾値は大きくなる。 【0099】 図11は、アップデート見積もり部13が抽出した時間帯を表す図である。アップデート見積もり部13は、図11のようなテーブルを生成して、時間帯の抽出を行うことができる。図11の「負荷の閾値」は、閾値記憶部15が記憶する閾値である。「負荷の予測値」は、負荷記憶部11が記憶する負荷の合計値である。アップデート見積もり部13は、「負荷の閾値」より「負荷の予測値」が小さく、「差分」が正である時間帯を抽出する。図11でアップデート見積もり部13が抽出した時間帯は、実行可否が「OK」である時間帯である。 【0100】 条件に適合する時間帯が存在しない場合(ステップS25、N)、ソフトウェア更新装置1は、更新の実行や更新の実行予定の割り当てを行わずに、処理を終了する。この場合は、例えばディスクアレイ装置2の管理者が手動で更新を実行するなどすればよい。 【0101】 条件に適合する時間帯が存在する場合(ステップS25、Y)、その時間帯が現在であり即時更新を実行することが可能であれば(ステップS26、Y)、アップデート実行部14は更新を実行する(ステップS27)。 【0102】 条件に適合する時間帯が現在ではなく、即時更新を実行できない場合(ステップS26、N)、アップデート見積もり部13は、更新の実行予定を割り当てる(ステップS28)。この場合、更新の実行予定時刻に、アップデート実行部14が、以下で述べるように更新を実行すればよい。」 第5 対比・判断 1 本願発明1について (1) 対比 本願発明1と引用発明とを対比する。 (あ)引用発明の「N重化サーバクラスタ」は,本願発明1の「クラスタシステム」に相当する。 (い)引用発明の「N重化サーバクラスタ」は,「クラスタワイドでのデータアクセス手段をセッションデータ管理機能として提供」するものであって,「セッションデータ管理機能の実装方式」として,「全てのアプリケーションサーバで同じデータを持つ方式」の「1台のデータ更新が発生した場合,他のサーバのデータも同期更新される全データ共有型」である。そして,当該「アプリケーションサーバ」は,本願発明1の「サーバ」に対応し,上記(あ)の認定を踏まえると,引用発明と本願発明1とは,“サーバ間でセッション維持に必要なデータを共有しているN-Active構成のサーバ”の点で一致する。 (う)引用発明は,「保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し」た上で,「システム更新が可能となる」ものであるから,当該「保守システム」は,本願発明1の「サーバのソフトウェアのアップデートを行うアップデート管理装置」に対応し,引用発明と本願発明1とは,“サーバのソフトウェアのアップデートを行うアップデート管理装置”を有する点で一致する。 (え)引用発明の「N重化サーバクラスタ」は「ロードバランサ」を含み,「ソフトウェア更新の実現手順」において,当該「ロードバランサに対して,新規セッションを順次新サーバクラスタで処理するよう,振り分けルールを更新し,旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し,エラーが発生していない場合,旧サーバクラスタで処理しているセッション数がなくなった時点で,旧サーバクラスタを停止し,システム更新が終了」することによって,「システム更新が可能となる」ものであるから,引用発明の「ロードバランサ」が本願発明1の「アップデート振分装置」に対応し,引用発明と本願発明1とは,“前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置”を有する点で一致する。 以上(あ)乃至(う)の認定も考慮すると,引用発明と本願発明1とは,“サーバ間でセッション維持に必要なデータを共有しているN-Active構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と,前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステム”である点で一致するといえる。 (お)引用発明は,「ロードバランサを含むN重化サーバクラスタにおける,ソフトウェア更新の実現手順」において,「保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し,新サーバクラスタを起動し,…(中略)…旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し,エラーが発生していない場合,旧サーバクラスタで処理しているセッション数がなくなった時点で,旧サーバクラスタを停止し,システム更新が終了することによって,サービス無停止でのシステム更新が可能となる」ものであるから,引用発明と本願発明1とは,“アップデート管理装置は,前記ソフトウェアのアップデートの指示がなされた場合に,前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて,前記サーバが用いているソフトウェアをアップデートするサーバ管理部を備え”る点で一致する。 (か)引用発明は,「ソフトウェア更新の実現手順」において,「ロードバランサに対して,新規セッションを順次新サーバクラスタで処理するよう,振り分けルールを更新し,旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し,エラーが発生していない場合,旧サーバクラスタで処理しているセッション数がなくなった時点で,旧サーバクラスタを停止し,システム更新が終了することによって,サービス無停止でのシステム更新が可能となる」ものであるから,引用発明と本願発明1とは,“アップデート振分装置は,前記ソフトウェアのアップデート中のサーバに対する処理要求を,前記処理要求に基づいて,ソフトウェアのアップデートがなされた新サーバ,又は,ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し,いずれかのサーバに振り分ける振分部を備える”点で一致する。 (き)以上,(あ)乃至(か)の検討から,引用発明と本願発明1とは,次の一致点及び相違点を有する。 〈一致点〉 サーバ間でセッション維持に必要なデータを共有しているN-Active構成のサーバのソフトウェアのアップデートを行うアップデート管理装置と,前記サーバに対する処理要求をいずれかのサーバへ振り分けるアップデート振分装置とを備えるクラスタシステムであって, 前記アップデート管理装置は, 前記ソフトウェアのアップデートの指示がなされた場合に,前記ソフトウェアのアップデートの対象となるサーバが提供しているサービスの終了に応じて,前記サーバが用いているソフトウェアをアップデートするサーバ管理部, を備え, 前記アップデート振分装置は, 前記ソフトウェアのアップデート中のサーバに対する処理要求を,前記処理要求に基づいて,ソフトウェアのアップデートがなされた新サーバ,又は,ソフトウェアのアップデートがなされていない旧サーバのいずれで処理すべきかを判定し,いずれかのサーバに振り分ける振分部, を備えるクラスタシステム。 〈相違点〉 本願発明1の「振分部」は,「前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分ける」ものであるのに対し,引用発明は,「ロードバランサに対して,新規セッションを順次新サーバクラスタで処理するよう,振り分けルールを更新し,旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し,エラーが発生していない場合,旧サーバクラスタで処理しているセッション数がなくなった時点で,旧サーバクラスタを停止し,システム更新が終了する」ものであって,処理要求の内容及び当該要求を処理したサーバの存在如何によって処理要求を振り分けるものではない点。 (2) 相違点についての判断 上記相違点について検討する。 本願発明1は,ソフトウェアのアップデートの技術に関し(本件明細書段落0001),従来,Webサーバホスティング等の分野では,データセンタのようなサーバ管理事業者が一括して複数のサーバを管理し,サービス提供事業者をホスティングするIaaS(Infrastructure as a Service)等と呼ばれる形態が知られている一方,電話のようなライフラインサービスでは,二重化により高可用性を実現しており,電話サービスをIaaS上で実現するために,サーバをN台クラスタリングしたN-Active構成により可用性及び設備利用効率を高める技術が利用されていることを背景とし(同段落0002),サービス無停止でソフトウェアのアップデートを行う場合,通常はアップデート先へのデータ引き継ぎ処理が必要となり,データ引継処理を行うためには,アップデート先へデータの同期に加えて,アップデート前のデータ形式をアップデート後のデータ形式に変換をする必要があることを解決しようとする課題とし(同段落0005),クラスタシステムにおいて,ソフトウェアのアップデートを行う際に要する開発コストを削減することができる技術の提供を目的としたものであって(同段落0006),とりわけ,上記相違点に係る構成を採用することにより,アップデート振分装置がアップデート中のサーバに対する処理要求を新サーバ又は旧サーバのいずれで処理すべきかを判断し,該当するサーバに当該処理要求を振り分け,データ引継処理に要するコストを削減することができるため,クラスタシステムにおいて,ソフトウェアのアップデートを行う際に要する開発コストを削減することが可能となるという効果を奏するものである(同段落0046)。 一方引用発明は,「N重化サーバクラスタ」において,「サーバクラスタにおけるアプリケーション更新する場合,アプリケーション更新時に旧アプリケーションのサーバをそのまま維持し(新旧アプリケーションを同時に動作させる),旧アプリケーションで生成されたセッションは旧アプリケーションで処理し,新アプリケーションで生成されたセッションと新規メッセージは新アプリケーションで処理を行う方式」が採用され,「ソフトウェア更新の実現手順」では,「まず,保守者が保守システムを通してサーバクラスタに対して新しいファイルを転送し,新サーバクラスタを起動し,次に,ロードバランサに対して,新規セッションを順次新サーバクラスタで処理するよう,振り分けルールを更新し,旧サーバクラスタで処理しているセッション数とエラーの発生状況を監視し,エラーが発生していない場合,旧サーバクラスタで処理しているセッション数がなくなった時点で,旧サーバクラスタを停止し,システム更新が終了する」ものである。 そうすると,「ロードバランサ」に対して,「振り分けルールを更新」する引用発明においては,上記相違点に係る構成を採用する動機付けを見いだすことはできず,このことは,その他上記第4に示した引用例2乃至4にも記載されていない。 したがって,「ロードバランサ」に対して「振り分けルールを更新」するに過ぎない引用発明からは,当業者といえども相違点に係る構成を導き出すことは容易とはいえず,また,相違点に係る構成は,本願の出願前に周知な構成ともいえないから,本願発明1は,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 2 本願発明2について 本願発明2は,本願発明1とカテゴリー表現のみ異なるものであって,本願発明1と同じ理由により,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 3 本願発明3について 本願発明3は,請求項1を引用するものであって,本願発明1と同じ理由により,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 第6 当審拒絶理由の概要 <特許法37条について> 当審より,請求項2乃至4に係る発明は,請求項1に係る発明と共通の技術的特徴を有しているが,当該技術的特徴は,上記引用例1の開示内容に照らして,先行技術に対する貢献をもたらすものではないから,特別な技術的特徴であるとはいえず,請求項1に係る発明と,請求項2乃至4に係る発明との間に,他に同一の又は対応する特別な技術的特徴は存在せず,また請求項6及び7に係る発明についても同様であり,特許法37条に規定する要件を満たしていない旨の拒絶理由を通知したが,上記第3に示すとおり補正され,本拒絶理由は解消した。 <特許法29条1項3号について> 当審より,請求項1及び5に係る発明は,その出願前日本国内において頒布された上記引用例1に記載された発明であるから,特許法29条1項3号に該当し,特許を受けることができない旨の拒絶理由を通知したが,上記第3に示すとおり補正され,上記第5 1(1)に示す相違点を有することとなり,本拒絶理由は解消した。 <特許法29条2項について> 当審より,請求項1及び5に係る発明は,その出願前日本国内において頒布された上記引用例1に記載された発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない旨の拒絶理由を通知したが,上記第3に示すとおり補正され,上記第5で判断を示したとおり,当業者であっても,引用発明及び引用例2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえず,本拒絶理由は解消した。 第7 原査定についての判断 上記第3に示すとおり,補正後の請求項1乃至3は,「振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分ける」という技術的事項を有するものとなった。当該「振分部は、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがある場合には、前記処理要求を処理したサーバに前記処理要求を振り分け、前記処理要求が破棄してはならない要求であり、前記処理要求を処理したサーバがない場合には、前記処理要求を旧サーバに振り分ける」ことは,原査定における引用文献1乃至3(上記第3に示す引用例2乃至4)には記載されておらず,本件出願前における周知技術でもないので,本願発明1乃至3は,当業者であっても,原査定における引用文献1乃至3に基づいて容易に発明できたものではない。したがって,原査定を維持することはできない。 第8 むすび 以上のとおり,原査定の理由によっては,本願を拒絶することはできない。 また,他に本願を拒絶すべき理由を発見しない。 よって,結論のとおり審決する。 |
審決日 | 2020-04-06 |
出願番号 | 特願2017-54564(P2017-54564) |
審決分類 |
P
1
8・
65-
WY
(G06F)
P 1 8・ 113- WY (G06F) P 1 8・ 121- WY (G06F) |
最終処分 | 成立 |
前審関与審査官 | 三坂 敏夫 |
特許庁審判長 |
仲間 晃 |
特許庁審判官 |
松平 英 山崎 慎一 |
発明の名称 | クラスタシステム、クラスタシステムのアップデート管理装置、アップデート振分装置、アップデート管理方法、アップデート振分方法及びプログラム |
代理人 | 特許業務法人 志賀国際特許事務所 |