ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 5項独立特許用件 取り消して特許、登録 G06F 審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
---|---|
管理番号 | 1307076 |
審判番号 | 不服2014-25735 |
総通号数 | 192 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2015-12-25 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2014-12-16 |
確定日 | 2015-11-10 |
事件の表示 | 特願2013-182935「情報処理システム、システム、情報処理システム制御方法、およびそのプログラム」拒絶査定不服審判事件〔平成25年12月12日出願公開、特開2013-251006、請求項の数(7)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は、平成21年10月27日に出願された特願2009-246669号の一部を、平成25年9月4日に新たな特許出願としたものであって、平成26年9月9日付けで拒絶査定がされ、これに対し、平成26年12月16日に拒絶査定不服審判が請求され、同時に手続補正がされたものである。 第2 平成26年12月16日付けの手続補正(以下、「本件補正」という。)の適否 1.補正の内容 本件補正は、特許請求の範囲の請求項1を、 「 少なくとも1台以上の情報処理装置を含む情報処理システムであって、 ネットワークを介して外部装置から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理手段と、 前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューに格納されている前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行うバックエンド処理手段と、 前記キューに格納されているキューメッセージの数を確認し、前記キューに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する制御手段と、 前記キューメッセージに基づく処理を行っている前記バックエンド処理手段においてエラーが発生した場合に、新たなバックエンド処理手段が前記キューメッセージに基づく処理を行うことが可能になるよう、複数の前記バックエンド処理手段を管理する管理手段と、を有し、 前記要求処理手段および前記バックエンド処理手段は夫々異なる仮想サーバにて実現される機能であることを特徴とする情報処理システム。」 とする補正(以下、「補正事項1」という。)を含んでいる。 2.補正の適否 本件補正の補正事項1は、請求項1に記載した発明を特定するために必要な事項である「前記要求処理手段および前記バックエンド処理手段」について、「夫々異なる仮想サーバにて実現される機能である」との限定を付加するものであって、補正前の請求項1に記載された発明と補正後の請求項1に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。 また、特許法第17条の2第3項、第4項に違反するところはない。 そこで、本件補正後の前記請求項1に記載された発明(以下、「補正発明」という。)が特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について以下に検討する。 (1)刊行物の記載事項 原査定の拒絶の理由に引用された特開平8-44576号公報(以下、「刊行物1」という。)には、次の記載がある。 「【請求項1】着信サービス要求を受け取って待ち行列化する待ち行列57と、サービス要求を実行する複数のサーバ60?68とを含み、サービス要求を処理する少なくとも1つのサービス単位55と、 サーバ60?68を監視し、サーバ60?68の数を動的に制御する待ち行列化モニタ85と、 を含むことを特徴とする、トランザクション・システム。 【請求項2】サービス単位55当たりのサーバの最小数および最大数と、サービス単位55当たりのサーバの最小数および最大数とを組み合わせることにより、サービス単位55内のサービス要求の数に応じて、サービス単位55が使用するサーバ60?68の数の動的制御を可能にするしきい値とを含むセットアップ・データを待ち行列化モニタ85に提供するセットアップ手段をさらに含む ことを特徴とする、請求項1に記載のトランザクション・システム。」 「【0002】 【従来の技術】メッセージ主導トランザクション環境では、ユーザ・インタフェースまたはその他のアプリケーション・プロセスあるいはその両方との通信が、待ち行列に入れられたメッセージに基づいて行われる。メッセージとは、あるクライアント・プロセスからサーバ・プロセスにまたはその逆に送信されるサービス要求または応答(たとえば、資金移動要求、照会要求)であると見なすことができる。 【0003】図1は、典型的なクライアント/サーバ概念を示している。サーバ10は、ネットワーク15内に設置され、少なくとも1台のクライアント20にサービスを提供する。このようなサービスとしては、たとえば、顧客に関する情報の照会が考えられる。ネットワーク15は、複数のサーバ10と複数のクライアント20とを含むことができ、それにより、各種サービスがクライアントによって要求され、サーバによって提供される。クライアントはサーバからのサービスを要求でき、そのサーバはクライアントとしてさらにサービスを要求できるので、「クライアント」と「サーバ」という用語は置き換えることができる。また、サーバまたはクライアントは、どのようなタイプのプロセス、コンピュータ・プログラムなどでもよいことに留意されたい。サーバ10は、クライアント20からサービス要求を受け取るために要求待ち行列25を含んでいる。サーバ10は、この要求待ち行列25からの要求を処理し、それぞれのクライアント20に適切な応答を送信し、この応答はまずクライアント20の応答待ち行列30に入る。最終的にクライアント20はこの応答待ち行列30から応答を受け取る。並列処理または直列処理あるいはその両方により、クライアントとサーバとの間の複数の対話を同時に処理できることは明らかである。また、それぞれのサーバまたはクライアントが複数の待ち行列を含むことができることも明らかである。 ・・・(中略)・・・ 【0008】考えられる問題の1つは、作業負荷が低いために事前始動したサーバ10の処理ユニットが遊んでしまう点である。記憶装置、ディスク空間、またはディスパッチ・リストなどのシステム資源が占有されるので、他のシステム・ユーザのパフォーマンスに影響する場合がある。 【0009】考えられるもう1つの問題は、事前始動したサーバ10の処理ユニットの数が少なすぎて、満足できる応答時間内に待ち行列25の多数の要求メッセージを処理できない点である。サーバ10が入出力処理が完了するまで待ってから次の要求が処理されるので、このシナリオでは中央演算処理装置(CPU)が十分活用されない可能性がある。サーバ10が使用した処理ユニットが1台だけの場合には、すべての着信要求が完全に順次処理される。 【0010】考えられるもう1つの問題は、要求メッセージの到着後に追加サーバを始動すると、プロセスの始動と停止のためにシステム・オーバヘッドが高くなる点である。 【0011】 【発明が解決しようとする課題】したがって、本発明の目的は、システム資源のパフォーマンスおよび使用効率が高く、システム・オーバヘッドが低い、トランザクション・システムを提供することにある。」 「【0014】 【実施例】 図2は、本発明によるメッセージ駆動型トランザクション・システムの実施例を示している。このシステムは少なくとも1つのサービス・ポイント50を含み、さらにこのサービス・ポイントは少なくとも1つのサービス単位55を含んでいる。明確にするため、本発明の原理を説明するために図2には1つのサービス単位55を備えたサービス・ポイントを1つだけ示す。サービス単位55は、サービス・ポイント50に接続されたクライアント20のいずれかからサービス要求を受け取るサービス単位待ち行列57を含んでいる。このサービス単位待ち行列57は複数のサーバ60?68とリンクされ、それにより、サーバ60?68はサービス単位待ち行列57に待ち行列化されているサービス要求を実行する。サーバ60?68のそれぞれは、要求されたサービスを実行するためにさらに複数のサービス・ルーチン70?74とリンクされており、それにより、サービス・ルーチン70?74のそれぞれが要求されたサービスのモジュラ・ステップを実行する。サーバ60?68のそれぞれは、他のサーバまたは資源管理プログラムにもサービス要求を出すことができることに留意されたい。 【0015】 図2では、サーバ60?68の処理の例をサーバ60についてのみ示すが、この例は他のどのサーバについても同様である。サーバ60はサービス単位待ち行列57からサービス要求の1つを受け取る。サービス要求は、サービスの処理に必要な情報(たとえば、要求されたサービスのタイプ、サービスに必要なデータ)を提供する。次に、サーバは対応するサービス・ルーチン(この例では、サービス・ルーチン70および72)をリンクし、サービス・ルーチン70および72を使用することにより要求されたサービスを実行する。 ・・・(中略)・・・ 【0021】待ち行列化モニタ85は、以下の顧客定義のサービス単位パラメータを含む指定のセットアップ・プロファイル90?94から、監視対象の各サービス単位55に関する制御情報を受け取る。 1.監視対象のサービス単位待ち行列57(複数も可)の名前。これにより、1つの待ち行列化モニタ85によって1つのサービス・ポイント50内の複数のサービス単位待ち行列を監視することができる。 2.着信サービス要求の処理のためのそれぞれのサービス単位55の関連サーバ(複数も可)60?68の名前。 3.各サービス単位55のサーバの最小数。この最小数は、処理すべきメッセージがない場合でも永続的に動作する必要があるサービス単位55内のサーバ・プロセスの数に相当する。この最小数の値は、各サービス単位待ち行列57ごとに指定することができる。 4.各サービス単位55のサーバの最大数。この最大数は、待ち行列に多くの業務要求が入っている高作業負荷状況で動作する必要があるサービス単位55内のサーバ・プロセスの数に相当する。この最大数の値は、各サービス単位待ち行列57ごとに指定することができる。 5.それぞれのサービス単位待ち行列内の業務要求を迅速に処理するためにリンクする必要があるサーバの数を定義するしきい値。リンクする必要があるサーバの数は、待ち行列内の業務要求の数(待ち行列内項目数)をしきい値で割った数によって決まる。サーバの最大数と、リンクする必要があるサーバの数とを組み合わせると、最終的に、各サービス単位55によってリンクされるサーバ60?68の数が決まる。 6.待ち行列化モニタ85がサービス単位(複数も可)55の現在の状態の監視を繰り返す時間間隔を定義するモニタ時間間隔。 7.サービス単位55をただちに始動するか、トリガ・メッセージ87の到着後に始動するかを決定する自動始動指示。 ・・・(中略)・・・ 【0026】最小数のサーバとしてリンクされているサーバは永続サーバとして示されるので、サービス単位当たりの永続サーバの数は、通常の条件下でサービス単位パラメータによって示されるサーバの指定の最小数によって決まる。しかし、サービス単位当たりの一時サーバの数は、指定のサービス単位パラメータと、それぞれのサービス単位待ち行列57内のサービス要求の数とによって決まる。 【0027】指定のモニタ時間間隔が経過すると、待ち行列化モニタ85は、次のステップ240でサービス単位55(104および120)のそれぞれから以下の情報を問い合わせる。 1.それぞれのサービス単位待ち行列内の現在のサービス要求の数。これは待ち行列内項目数ともいう。 2.このサービス単位待ち行列にリンクされている現在のサーバの数。 【0028】それぞれのサービス単位55内の現在のサービス要求(SR)の数が指定のしきい値以下であるときは、待ち行列化モニタ85は追加のサーバを始動する必要がない。保全性を維持するため、待ち行列化モニタ85は、ステップ250で最小数のサーバが動作していることを検査する。動作しているサーバが指定の最小数のサーバより少ない場合は、待ち行列化モニタ85は、このサーバの最小数に達するために必要な数のサーバのみ再始動する。 【0029】 サービス単位待ち行列57内のサービス要求の数が指定のしきい値を上回る場合は、待ち行列化モニタ85は、以下の式に基づいてステップ260で追加のサーバをリンクまたは始動する。 ・・・(中略)・・・ 【0046】オブジェクト指向アプリケーションでは、本明細書で使用する「サーバ」という用語が「サーバ・インスタンス」("Object-oriented Software Construction"、Bertrand Meyer著、1988年、Prentice Hall International Ltd(英国)発行、ISBN 0-13-629049-3、71ページ、5.2.1章を参照)という用語で置換え可能であることに留意されたい。」 そして、刊行物1の上記記載事項を刊行物1の関連図面と技術常識に照らし、下線を施した部分の記載に着目すれば、刊行物1には、以下の発明(以下、「引用発明」という。)が記載されているといえる。 〈引用発明〉 「トランザクション・システムであって、 クライアント20のいずれかからサービス要求を受け取るサービス単位待ち行列57と、 前記サービス単位待ち行列57に待ち行列化されているサービス要求を実行するサーバ60?68と、 サービス単位待ち行列57内のサービス要求の数が指定のしきい値を上回る場合は、追加のサーバをリンクまたは始動する待ち行列化モニタ85と、を有する、 トランザクション・システム。」 (2)対比 補正発明と引用発明とを対比すると、次のことがいえる。 ア.引用発明の「トランザクション・システム」は、「情報処理システム」の一種であり、当然に少なくとも1台以上の情報処理装置を含むものと考えられるから、本願発明の「情報処理システム」と、「少なくとも1台以上の情報処理装置を含む情報処理システム」である点で一致する。 イ.引用発明の「クライアント20」、「サービス要求」、「サービス単位待ち行列57」は、それぞれ、補正発明の「外部装置」、「処理要求」、「キュー」に相当し、引用発明が「クライアント20のいずれかからサービス要求を受け取るサービス単位待ち行列57」を有していることと、補正発明が「ネットワークを介して外部装置から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理手段」を有することとは、「外部装置から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納する手段」といい得る手段を有する点で共通する。 ウ.引用発明の「サーバ60?68」は、補正発明の「バックエンド処理手段」に相当し、引用発明が「前記サービス単位待ち行列57に待ち行列化されているサービス要求を実行するサーバ60?68」を有していることと、補正発明が「前記キューサービスに対前記しキューメッセージの取得要求を定期的に行い、前記キューに格納されている前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行うバックエンド処理手段」を有することとは、「前記キューメッセージに基づく処理を行うバックエンド処理手段」を有する点で共通する。 エ.引用発明の「サービス単位待ち行列57内のサービス要求の数」、「指定のしきい値」は、それぞれ、補正発明の「キューに格納されているキューメッセージの数」、「規定値」に相当し、引用発明の「待ち行列化モニタ85」が「サービス単位待ち行列57内のサービス要求の数が指定のしきい値を上回る場合は、追加のサーバをリンクまたは始動する」ことは、補正発明の「制御手段」が「キューに格納されているキューメッセージの数を確認し、前記キューに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する」ことに相当する。したがって、引用発明の「待ち行列化モニタ85」は補正発明の「制御手段」に相当する。 よって、補正発明と引用発明は、以下の点で一致、ないし相違している。 (一致点) 「少なくとも1台以上の情報処理装置を含む情報処理システムであって、 外部装置から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納する手段と、 前記キューメッセージに基づく処理を行うバックエンド処理手段と、 前記キューに格納されているキューメッセージの数を確認し、前記キューに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する制御手段と、 を有する情報処理システム。」 (相違点1) 補正発明の「キューメッセージをキューに格納する手段」は、外部装置からの処理要求を「ネットワークを介して」受信するものであるのに対し、引用発明の「キューメッセージをキューに格納する手段」(サービス単位待ち行列57)は、外部装置(クライアント20)からの処理要求(サービス要求)を「ネットワークを介して」受信するものとはされていない点。 (相違点2) 補正発明の「キューメッセージをキューに格納する手段」は、「受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理手段」であるのに対し、引用発明の「キューメッセージをキューに格納する手段」(サービス単位待ち行列57)は、そのようなものとはされていない点。 (相違点3) 補正発明の「バックエンド処理手段」は、「前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューに格納されている前記キューメッセージを取得したことに応じて」、取得した前記キューメッセージに基づく処理を行うものであるのに対し、引用発明の「バックエンド処理手段」(サーバ60?68)は、そのようなものとはされていない点。 (相違点4) 補正発明は、「前記キューメッセージに基づく処理を行っている前記バックエンド処理手段においてエラーが発生した場合に、新たなバックエンド処理手段が前記キューメッセージに基づく処理を行うことが可能になるよう、複数の前記バックエンド処理手段を管理する管理手段」を有するのに対し、引用発明は、それに対応する手段を有するものとはされていない点。 (相違点5) 補正発明の「キューメッセージをキューに格納する手段」(要求処理手段)と「バックエンド処理手段」は、「夫々異なる仮想サーバにて実現される機能」であるのに対し、引用発明の「キューメッセージをキューに格納する手段」(サービス単位待ち行列57)と「バックエンド処理手段」(サーバ60?68)は、そのようなものとはされていない点。 (3)判断 当審は次のとおり判断する。 下のア.?ウ.に示す理由で、引用発明において上記相違点2と5に係る本願発明の構成を採用することは、当業者といえども容易に推考し得たこととはいえない。 したがって、その他の点について判断するまでもなく、補正発明は引用発明に基づいて当業者が容易に発明することができたものとはいえない。 ア.引用発明を開示する刊行物1には、引用発明において上記相違点2と5に係る本願発明の構成を採用することについての記載も、それを示唆する記載もない。 イ.前置報告書で提示された特開2008-282297号公報(以下、「刊行物2」という。)の段落【0062】?【0070】には、サーバ11の中に仮想化技術を用いて子サーバを設けること、サーバ11は、ジョブの実行要求を受信すると子サーバ部112にジョブキューの状態の問い合わせを行うこと、子サーバ部112は、サーバ11からの上記問い合わせに応じてジョブキューの管理とジョブの実行あるいは制御部101に対する実行指示を行うことが記載されており、そのような刊行物2に記載される技術を引用発明において採用すること自体は当業者が容易なし得たこととも考えられる。 しかしながら、上記刊行物2に記載される技術において補正発明の「要求処理手段」に相当する役割を果たすのは、仮想化されるものとはされていない「サーバ11」であり、仮に引用発明において上記刊行物2に記載される技術を採用したとしても、上記相違点2と5に係る本願発明の構成は導出されない。 したがって、上記刊行物2に記載される技術の存在をもっては、引用発明において上記相違点2と5に係る本願発明の構成を採用することが当業者にとって容易であったとはいえない。 ウ.ほかに引用発明において上記相違点2と5に係る本願発明の構成を採用することが当業者にとって容易であったといえる根拠は見当たらない。 よって、本件補正の補正事項1は、特許法第17条の2第6項において準用する同法第126条第7項の規定に適合する。 本件補正のその余の補正事項についても、特許法第17条の2第3項ないし第6項に違反するところはない。 3.むすび 本件補正は、特許法第17条の2第3項ないし第6項の規定に適合する。 第3 本願発明 本件補正は上記のとおり、特許法第17条の2第3項ないし第6項の規定に適合するから、本願の請求項1-7に係る発明は、本件補正により補正された特許請求の範囲の請求項1?7に記載された事項により特定されるとおりのものである。 そして、本願については、原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
審決日 | 2015-10-23 |
出願番号 | 特願2013-182935(P2013-182935) |
審決分類 |
P
1
8・
121-
WY
(G06F)
P 1 8・ 575- WY (G06F) |
最終処分 | 成立 |
前審関与審査官 | 片岡 利延 |
特許庁審判長 |
和田 志郎 |
特許庁審判官 |
山澤 宏 小曳 満昭 |
発明の名称 | 情報処理システム、システム、情報処理システム制御方法、およびそのプログラム |
代理人 | 黒岩 創吾 |
代理人 | 阿部 琢磨 |