ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F 審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1240679 |
| 審判番号 | 不服2008-14441 |
| 総通号数 | 141 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2011-09-30 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2008-06-09 |
| 確定日 | 2011-07-27 |
| 事件の表示 | 特願2004-167646「ソフトウェア環境において統合トランザクション・マネージャなしでリソース保全性を維持するための装置及び方法」拒絶査定不服審判事件〔平成17年 1月 6日出願公開、特開2005- 4754〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、平成16年6月4日(パリ条約による優先権主張2003年6月10日、米国)の出願であって、平成19年11月8日付けで拒絶理由通知がなされ、平成20年2月13日付けで手続補正がなされたが、同年3月4日付けで拒絶査定がなされ、これに対し、同年6月9日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。 2.平成20年6月9日付けの手続補正についての補正却下の決定 [補正却下の決定の結論] 平成20年6月9日付けの手続補正を却下する。 [理由] (1)新規事項の追加の有無について 平成20年6月9日付けの手続補正(以下、「本件手続補正」という。)の内容は、補正前の特許請求の範囲の記載中の「リソース」との記載を「アプリケーション・リソース」に補正することを含むものである。 これに対し、出願当初の明細書、特許請求の範囲又は図面には、「ソフトウェア・リソース」との記載、あるいは、その例示として、段落【0035】に「メッセージング・ミドルウェア・リソース」、「データベース・ソフトウェア・リソース」との記載はあるものの、それらの「リソース」側で動作する「ソフトウェア」が「アプリケーション」であるとの記載はなされていない。 そして、「リソース」を「アプリケーション・リソース」とすることは、出願当初の明細書、特許請求の範囲又は図面のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであると認められる。 (2)むすび したがって、上記補正内容を含む本件手続補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものであるとは認められず、特許法第17条の2第3項の規定に違反するものであるから、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下されるべきものである。 3.補正却下の決定を踏まえた検討 (1)本願発明 平成20年6月9日付けの手続補正は、上記のとおり却下されたので、本願の請求項1に係る発明は、次のものと認める。 「ソフトウェア環境においてトランザクション処理をコンピュータに行わせるためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、コンピュータに クライアント・アプリケーションからのトランザクションを受け取り、個々のリソースを識別し、更新メッセージをインバウンドキューに配置し、個々のリソースに対して、リソースを処理し、アウトバンドキューに更新完了メッセージを配置する第一命令と、 前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための第2命令と、 前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、更新メッセージをインバウンドキューに再配置する際に、インバウンドキューに重複する更新メッセージを配置することおよびデータベースの更新をスキップし、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための第3命令と を実行させる、コンピュータ・プログラム。」 なお、平成20年2月13日付けの手続補正書の特許請求の範囲の請求項1には、「・・・リソースの処理し・・・」、「・・・配置するをする第一命令・・・」、「・・・を実行させる含む、コンピュータ・プログラム。」と記載されているが、これらの記載は、それぞれ、「・・・リソースを処理し・・・」、「・・・配置する第一命令・・・」、「・・・を実行させる、コンピュータ・プログラム。」の誤記と認め、本願の請求項1に係る発明(以下、「本願発明」という。)を上記のように認定した。 (2)引用例 これに対して、原査定の拒絶の理由に引用された特開平4-64146号公報(以下、「引用例」という。)には、図面とともに次の事項が記載されている。 A.「〔産業上の利用分野〕 本発明は、データ更新要求を発行するクライアント側とデータ更新要求を受けるサーバ側の資源の一時的な不整合が許される場合の分散システムにおけるコミットメント処理の最適化方式に関する。」(第1頁右下欄第4?9行) B.「〔実施例〕 以下、本発明の一実施例を図面により詳細に説明する。 第1図は、本発明を実施するに当り使用する分散データベースシステムの構成例を示す図であり、通信ネットワーク11によって複数のノードA,B,Cが連絡可能な状態を示している。ノードAをクライアント、ノードB、ノードC、をサーバとする。通常、ノードAのシステム1において、アプリケーションプログラム4からのデータアクセス要求が自ノード(即ちノードA自身)にあるデータに対するものであれば、トランザクション管理部5はこのデータアクセス要求が自ノード(ノードA)に対するアクセスであることを認識し、データ管理処理部6を通して自ノード(ノートA)のデータベース7をアクセスする。 一方、アプリケーションプログラム4からのデータアクセス要求が他ノード(すなわちノードB、ノードC)にあるデータに対するものであれば、このデータアクセス要求はノードAの通信制御処理部8によって通信ネットワーク11を介してノードB、ノードCのシステム2,3に送信される。ノードB、ノードCではこのデータアクセス要求を認識し、自ノードのデータベース9,10ヘアクセスし、ノードAへ応答を返す。」(第2頁右下欄第13行?第3頁左上欄第17行) C.「第3図に、本発明の一実施例における処理の流れを示す。トランザクションの開始(100)から、クライアント(ノードA)におけるデータ処理実行(111)までは第2図において同一符号で示された処理と同じである。クライアント(ノードA)においてアプリケーションプログラム4から、トランザクション終了処理開始(200)をトランザクション管理部5が受け取ると、コミット要求を生成して、サーバ(ノードB、ノードC)のシステム2,3に送信する(201,206)。サーバ(ノードB、ノードC)ではこのコミット要求を認識して(202,207)、各ノードのデータベース9,10においてコミット保証処理を実行し、これに成功すれば続けてコミット処理を行い(203,208)、その後、クライアント(ノードA)に対してコミット完了応答を返信する(204,209)。サーバ(ノードB、ノードC)においてコミット保証処理に失敗した場合は、ロールバック処理を行い(203,208)、コミット失敗応答を返信する(204,209)。サーバ(ノードB、ノードC)からの応答を受け取ったクライアント(ノードA)は(205,210)、その応答が全てコミット完了応答であるか否かを判断する(220)。全サーバがコミット完了状態であれば、クライアント(ノードA)もコミット処理を行い(230)、トランザクションを終了させる(231)。 一方、ステップ220でロールバックされたサーバが1つでも存在すると判断されれば、クライアント(ノードA)は自ノードのロールバック処理を行い(240)、この後リトライ処理を実行する。 第3図からわかるように、1相コミット方式のトランザクション終了処理に要する通信回数は、(相手ノード数)×2回である。 ここで、サーバ,クライアント間の処理の整合性についてみてみると、複数サーバにおける上述のような1相コミット方式では、サーバにコミット処理が成功したノードと失敗したノードが混在することがあり、また、全サーバがコミットされてもクライアントにおける障害により、クライアントだけがロールバックとなることもある。これらの場合は、クライアント側からリトライさせることによって最終的な資源の整合性を得ることができる。このためのリトライ処理を第4図を用いて説明する。 1つのトランザクション終了後、クライアント(ノードA)がロールバックされていた時、クライアント(ノードA)はこのトランザクションをリトライし(300)、データ処理要求を生成してサーバ(ノードB,ノードC)に送信する(301,306)。サーバ(ノードB,ノードC)では、このデータ処理要求を認識する(302,307)。 ここで、ノードBではコミットされ、ノードCではロールバックされていたとする。この場合、ノードBでは送られてきたトランザクションがすでにコミットされたものであることを判断し(303)、コミット済応答を返信する(304)。ノードCでは送られてきたトランザクションがロールバックされたものであることを判断し、クライアント(ノードA)からのデータ処理要求を実行し(308)、応答する(309)。 クライアント(ノードA)ではこれらのサーバ(ノードB,ノードC)からの応答を受信して(305,310)、自ノードのデータ処理を行い(311)、各サーバからの返信が全てコミット済応答であるか否かを判断する(312)。この判断(312)の結果、ノードBからはコミット済応答が返ってきているため、次の処理からはノードBにデータ処理要求を送る必要はなく、ノードCにのみ次のデータ処理要求を成生し送信する(313)。このクライアント(ノードA)からのデータ処理要求の認識(314)、実行(315)、応答(316)、クライアントにおけるノードCからの応答の受信(317)の処理の流れは通常のデータ処理と同様である。 トランザクション終了処理開始(200)から全サーバがコミット完了状態となったか否かの判断(220)及び、これ以降の処理は第3図に示すトランザクション終了処理と同様である。また、ステップ220でロールバックされたサーバが1つでも存在すると判断され、再びクライアント(ノードA)でロールバックされリトライとなったときは、第4図に示すリトライ処理を繰り返す。」(第3頁右下欄第17行?第4頁右下欄第18行) D.「〔発明の効果〕 本発明によれば、一時的な資源の不整合が許される業務において、1相コミット方式を用い、セキュア状態を考えないため、通信回数を削減でき、複雑なリカバリ処理が必要なくなるという効果がある。 また、2相コミット方式を用いた場合にはロールバックされるべきサーバが、本発明においてはコミットされることがあることによって、サーバ側への処理の反映が早く、そしてこのコミットされたサーバにおいては、一度成功したデータベースの更新処理をリトライ時に改めて行う必要がないという効果がある。」(第5頁左下欄第13行?右下欄第5行) 上記引用例のものにおいて、「トランザクション管理部5」は、「コンピュータ・プログラム」によって動作すると解され、「ソフトウェア環境においてトランザクション処理」を行っているということができる。 また、引用例の上記Cには、「ここで、ノードBではコミットされ、ノードCではロールバックされていたとする。この場合、ノードBでは送られてきたトランザクションがすでにコミットされたものであることを判断し(303)、コミット済応答を返信する(304)。ノードCでは送られてきたトランザクションがロールバックされたものであることを判断し、クライアント(ノードA)からのデータ処理要求を実行し(308)、応答する(309)。」と記載されており、この記載によれば、この段階の動作において、コミットされている「ノードB」では「コミット済応答」を返信するのみであり、コミットされていない「ノードC」とは異なり、「データ処理要求」の実行は行っていない。すなわち、この段階の動作において、「ノードB」では「データ処理」をスキップしているということができる。 さらに、引用例の上記Dの記載によれば、スキップされる「データ処理」は、「データベースの更新処理」であるということができる。 よって、上記A?Dの記載及び関連する図面を参照すると、引用例には、実質的に、次の発明が記載されているものと認められる。(以下、「引用例記載の発明」という。) 「ソフトウェア環境においてトランザクション処理をトランザクション管理部に行わせるためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、トランザクション管理部に アプリケーションプログラムからのトランザクションを受け取り、個々のサーバ側の資源(ノードB、ノードC)を識別し、個々のサーバ側の資源(ノードB、ノードC)に対して、サーバ側の資源(ノードB、ノードC)を処理する第一命令と、 前記サーバ側の資源(ノードB、ノードC)からのコミット完了応答又はコミット失敗応答を前記個々のサーバ側の資源(ノードB、ノードC)から受け取るための第2命令と、 前記コミット失敗応答が前記サーバ側の資源(ノードC)から受け取られた場合、前記コミット完了応答を送出した前記サーバ側の資源(ノードB)のデータベースの更新処理をスキップし、前記コミット失敗応答を送出した前記サーバ側の資源(ノードC)に対して前記トランザクションの一部をリトライ処理依頼するための第3命令と を実行させる、コンピュータ・プログラム。」 (3)対比 本願発明と引用例記載の発明とを対比すると、次のことがいえる。 (あ)引用例記載の発明における「トランザクション管理部」、「アプリケーションプログラム」、「サーバ側の資源」は、それぞれ、本願発明における「コンピュータ」、「クライアント・アプリケーション」、「リソース」に相当する。 (い)引用例記載の発明における「コミット完了応答」、「コミット失敗応答」は、それぞれ、本願発明における「リソースがコミットし得た」ことを表す応答、「コミットし得なかった」ことを表す応答に相当する。 (う)引用例記載の発明において、「サーバ側の資源(ノードB)のデータベースの更新処理をスキップ」することは、本願発明において、「データベースの更新をスキップ」することに相当する。 (え)引用例記載の発明における「リトライ処理依頼」は、本願発明における「再処理依頼」に相当する。 よって、上記(あ)?(え)の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。 (一致点) 本願発明と引用例記載の発明とは、ともに、 「ソフトウェア環境においてトランザクション処理をコンピュータに行わせるためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、コンピュータに クライアント・アプリケーションからのトランザクションを受け取り、個々のリソースを識別し、個々のリソースに対して、リソースを処理する第一命令と、 前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための第2命令と、 前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、データベースの更新をスキップし、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための第3命令と を実行させる、コンピュータ・プログラム。」 である点。 (相違点) 相違点1:本願発明における「第一命令」では、「更新メッセージをインバウンドキューに配置」する動作、及び「アウトバンドキューに更新完了メッセージを配置」する動作を行わせているのに対し、引用例記載の発明においては、そのような動作を行わせていない点。 相違点2:本願発明における「第3命令」では、「更新メッセージをインバウンドキューに再配置する際に、インバウンドキューに重複する更新メッセージを配置すること」をスキップする動作をも行わせているのに対し、引用例記載の発明においては、そのような動作を行わせていない点。 (4)判断 そこで、上記相違点1,2について検討する。 (相違点1について) 一般に、データ処理要求やデータ処理結果をキューに格納して管理することは、例えば、特開2000-187605号公報、特開平7-306821号公報、特開平10-320251号公報、「ジム・グレイほか,トランザクション処理[上]-概念と技法-,日本,日経BP社,2001年10月29日,第1版,第401-408頁」等に見られるように、周知技術にすぎない。 してみれば、引用例記載の発明のような、データベースの更新という処理を行うものに対して上記周知技術を適用することにより、その「第一命令」において、「更新メッセージをインバウンドキューに配置」する動作、及び「アウトバンドキューに更新完了メッセージを配置」する動作を行わせるようにすることは、当業者が容易に想到し得ることである。 (相違点2について) 引用例の上記Cには、「クライアント(ノードA)ではこれらのサーバ(ノードB,ノードC)からの応答を受信して(305,310)、自ノードのデータ処理を行い(311)、各サーバからの返信が全てコミット済応答であるか否かを判断する(312)。この判断(312)の結果、ノードBからはコミット済応答が返ってきているため、次の処理からはノードBにデータ処理要求を送る必要はなく、ノードCにのみ次のデータ処理要求を成生し送信する(313)。」と記載されている。 上記記載における「ノードBにデータ処理要求を送る必要はな」い場合に、上記「データ処理要求をキューに格納して管理する」周知技術を適用することを参酌すると、「ノードB」に対する「データ処理要求」が、「インバウンドキュー」に配置する「重複する更新メッセージ」となり、不必要なものとなることは、当業者にとって明らかである。 よって、引用例記載の発明に対して、上記周知技術を参酌して、その「第3命令」において、「更新メッセージをインバウンドキューに再配置する際に、インバウンドキューに重複する更新メッセージを配置すること」をスキップする動作をも行わせるようにすることは、当業者が容易に想到し得ることである。 (本願発明の作用効果について) そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知技術から当業者が容易に予測することができる程度のものであって、格別のものとはいえない。 (5)むすび 以上のとおり、本願発明は、引用例記載の発明及び上記周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2011-02-22 |
| 結審通知日 | 2011-03-01 |
| 審決日 | 2011-03-15 |
| 出願番号 | 特願2004-167646(P2004-167646) |
| 審決分類 |
P
1
8・
561-
Z
(G06F)
P 1 8・ 121- Z (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 上嶋 裕樹 |
| 特許庁審判長 |
長島 孝志 |
| 特許庁審判官 |
池田 聡史 飯田 清司 |
| 発明の名称 | ソフトウェア環境において統合トランザクション・マネージャなしでリソース保全性を維持するための装置及び方法 |
| 代理人 | 上野 剛史 |
| 代理人 | 市位 嘉宏 |
| 代理人 | 太佐 種一 |
| 代理人 | 坂口 博 |