【事件の表示】
　特願２００４−１６７６４６「ソフトウェア環境において統合トランザクション・マネージャなしでリソース保全性を維持するための装置及び方法」拒絶査定不服審判事件〔平成１７年　１月　６日出願公開、特開２００５−　　４７５４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１６年６月４日（パリ条約による優先権主張２００３年６月１０日、米国）の出願であって、平成１９年１１月８日付けで拒絶理由通知がなされ、平成２０年２月１３日付けで手続補正がなされたが、同年３月４日付けで拒絶査定がなされ、これに対し、同年６月９日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　
２．平成２０年６月９日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２０年６月９日付けの手続補正を却下する。
　
［理由］
（１）新規事項の追加の有無について
　平成２０年６月９日付けの手続補正（以下、「本件手続補正」という。）の内容は、補正前の特許請求の範囲の記載中の「リソース」との記載を「アプリケーション・リソース」に補正することを含むものである。
　これに対し、出願当初の明細書、特許請求の範囲又は図面には、「ソフトウェア・リソース」との記載、あるいは、その例示として、段落【００３５】に「メッセージング・ミドルウェア・リソース」、「データベース・ソフトウェア・リソース」との記載はあるものの、それらの「リソース」側で動作する「ソフトウェア」が「アプリケーション」であるとの記載はなされていない。
　そして、「リソース」を「アプリケーション・リソース」とすることは、出願当初の明細書、特許請求の範囲又は図面のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであると認められる。
　
（２）むすび
　したがって、上記補正内容を含む本件手続補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものであるとは認められず、特許法第１７条の２第３項の規定に違反するものであるから、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　
３．補正却下の決定を踏まえた検討
（１）本願発明
　平成２０年６月９日付けの手続補正は、上記のとおり却下されたので、本願の請求項１に係る発明は、次のものと認める。
「ソフトウェア環境においてトランザクション処理をコンピュータに行わせるためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、コンピュータに
　クライアント・アプリケーションからのトランザクションを受け取り、個々のリソースを識別し、更新メッセージをインバウンドキューに配置し、個々のリソースに対して、リソースを処理し、アウトバンドキューに更新完了メッセージを配置する第一命令と、
　前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための第２命令と、
　前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、更新メッセージをインバウンドキューに再配置する際に、インバウンドキューに重複する更新メッセージを配置することおよびデータベースの更新をスキップし、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための第３命令と
　を実行させる、コンピュータ・プログラム。」
　
　なお、平成２０年２月１３日付けの手続補正書の特許請求の範囲の請求項１には、「・・・リソース
の
するをする
実行させる含む
を
する
実行させる
　
（２）引用例
　これに対して、原査定の拒絶の理由に引用された特開平４−６４１４６号公報（以下、「引用例」という。）には、図面とともに次の事項が記載されている。
　
Ａ．「〔産業上の利用分野〕
　本発明は、データ更新要求を発行するクライアント側とデータ更新要求を受けるサーバ側の資源の一時的な不整合が許される場合の分散システムにおけるコミットメント処理の最適化方式に関する。」（第１頁右下欄第４〜９行）
　
Ｂ．「〔実施例〕
　以下、本発明の一実施例を図面により詳細に説明する。
　第１図は、本発明を実施するに当り使用する分散データベースシステムの構成例を示す図であり、通信ネットワーク１１によって複数のノードＡ，Ｂ，Ｃが連絡可能な状態を示している。ノードＡをクライアント、ノードＢ、ノードＣ、をサーバとする。通常、ノードＡのシステム１において、アプリケーションプログラム４からのデータアクセス要求が自ノード（即ちノードＡ自身）にあるデータに対するものであれば、トランザクション管理部５はこのデータアクセス要求が自ノード（ノードＡ）に対するアクセスであることを認識し、データ管理処理部６を通して自ノード（ノートＡ）のデータベース７をアクセスする。
　一方、アプリケーションプログラム４からのデータアクセス要求が他ノード（すなわちノードＢ、ノードＣ）にあるデータに対するものであれば、このデータアクセス要求はノードＡの通信制御処理部８によって通信ネットワーク１１を介してノードＢ、ノードＣのシステム２，３に送信される。ノードＢ、ノードＣではこのデータアクセス要求を認識し、自ノードのデータベース９，１０ヘアクセスし、ノードＡへ応答を返す。」（第２頁右下欄第１３行〜第３頁左上欄第１７行）
　
Ｃ．「第３図に、本発明の一実施例における処理の流れを示す。トランザクションの開始（１００）から、クライアント（ノードＡ）におけるデータ処理実行（１１１）までは第２図において同一符号で示された処理と同じである。クライアント（ノードＡ）においてアプリケーションプログラム４から、トランザクション終了処理開始（２００）をトランザクション管理部５が受け取ると、コミット要求を生成して、サーバ（ノードＢ、ノードＣ）のシステム２，３に送信する（２０１，２０６）。サーバ（ノードＢ、ノードＣ）ではこのコミット要求を認識して（２０２，２０７）、各ノードのデータベース９，１０においてコミット保証処理を実行し、これに成功すれば続けてコミット処理を行い（２０３，２０８）、その後、クライアント（ノードＡ）に対してコミット完了応答を返信する（２０４，２０９）。サーバ（ノードＢ、ノードＣ）においてコミット保証処理に失敗した場合は、ロールバック処理を行い（２０３，２０８）、コミット失敗応答を返信する（２０４，２０９）。サーバ（ノードＢ、ノードＣ）からの応答を受け取ったクライアント（ノードＡ）は（２０５，２１０）、その応答が全てコミット完了応答であるか否かを判断する（２２０）。全サーバがコミット完了状態であれば、クライアント（ノードＡ）もコミット処理を行い（２３０）、トランザクションを終了させる（２３１）。
　一方、ステップ２２０でロールバックされたサーバが１つでも存在すると判断されれば、クライアント（ノードＡ）は自ノードのロールバック処理を行い（２４０）、この後リトライ処理を実行する。
　第３図からわかるように、１相コミット方式のトランザクション終了処理に要する通信回数は、（相手ノード数）×２回である。
　ここで、サーバ，クライアント間の処理の整合性についてみてみると、複数サーバにおける上述のような１相コミット方式では、サーバにコミット処理が成功したノードと失敗したノードが混在することがあり、また、全サーバがコミットされてもクライアントにおける障害により、クライアントだけがロールバックとなることもある。これらの場合は、クライアント側からリトライさせることによって最終的な資源の整合性を得ることができる。このためのリトライ処理を第４図を用いて説明する。
　１つのトランザクション終了後、クライアント（ノードＡ）がロールバックされていた時、クライアント（ノードＡ）はこのトランザクションをリトライし（３００）、データ処理要求を生成してサーバ（ノードＢ，ノードＣ）に送信する（３０１，３０６）。サーバ（ノードＢ，ノードＣ）では、このデータ処理要求を認識する（３０２，３０７）。
　ここで、ノードＢではコミットされ、ノードＣではロールバックされていたとする。この場合、ノードＢでは送られてきたトランザクションがすでにコミットされたものであることを判断し（３０３）、コミット済応答を返信する（３０４）。ノードＣでは送られてきたトランザクションがロールバックされたものであることを判断し、クライアント（ノードＡ）からのデータ処理要求を実行し（３０８）、応答する（３０９）。
　クライアント（ノードＡ）ではこれらのサーバ（ノードＢ，ノードＣ）からの応答を受信して（３０５，３１０）、自ノードのデータ処理を行い（３１１）、各サーバからの返信が全てコミット済応答であるか否かを判断する（３１２）。この判断（３１２）の結果、ノードＢからはコミット済応答が返ってきているため、次の処理からはノードＢにデータ処理要求を送る必要はなく、ノードＣにのみ次のデータ処理要求を成生し送信する（３１３）。このクライアント（ノードＡ）からのデータ処理要求の認識（３１４）、実行（３１５）、応答（３１６）、クライアントにおけるノードＣからの応答の受信（３１７）の処理の流れは通常のデータ処理と同様である。
　トランザクション終了処理開始（２００）から全サーバがコミット完了状態となったか否かの判断（２２０）及び、これ以降の処理は第３図に示すトランザクション終了処理と同様である。また、ステップ２２０でロールバックされたサーバが１つでも存在すると判断され、再びクライアント（ノードＡ）でロールバックされリトライとなったときは、第４図に示すリトライ処理を繰り返す。」（第３頁右下欄第１７行〜第４頁右下欄第１８行）
　
Ｄ．「〔発明の効果〕
　本発明によれば、一時的な資源の不整合が許される業務において、１相コミット方式を用い、セキュア状態を考えないため、通信回数を削減でき、複雑なリカバリ処理が必要なくなるという効果がある。
　また、２相コミット方式を用いた場合にはロールバックされるべきサーバが、本発明においてはコミットされることがあることによって、サーバ側への処理の反映が早く、そしてこのコミットされたサーバにおいては、一度成功したデータベースの更新処理をリトライ時に改めて行う必要がないという効果がある。」（第５頁左下欄第１３行〜右下欄第５行）
　
　上記引用例のものにおいて、「トランザクション管理部５」は、「コンピュータ・プログラム」によって動作すると解され、「ソフトウェア環境においてトランザクション処理」を行っているということができる。
　また、引用例の上記Ｃには、「ここで、ノードＢではコミットされ、ノードＣではロールバックされていたとする。この場合、ノードＢでは送られてきたトランザクションがすでにコミットされたものであることを判断し（３０３）、コミット済応答を返信する（３０４）。ノードＣでは送られてきたトランザクションがロールバックされたものであることを判断し、クライアント（ノードＡ）からのデータ処理要求を実行し（３０８）、応答する（３０９）。」と記載されており、この記載によれば、この段階の動作において、コミットされている「ノードＢ」では「コミット済応答」を返信するのみであり、コミットされていない「ノードＣ」とは異なり、「データ処理要求」の実行は行っていない。すなわち、この段階の動作において、「ノードＢ」では「データ処理」をスキップしているということができる。
　さらに、引用例の上記Ｄの記載によれば、スキップされる「データ処理」は、「データベースの更新処理」であるということができる。
　
　よって、上記Ａ〜Ｄの記載及び関連する図面を参照すると、引用例には、実質的に、次の発明が記載されているものと認められる。（以下、「引用例記載の発明」という。）
「ソフトウェア環境においてトランザクション処理をトランザクション管理部に行わせるためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、トランザクション管理部に
　アプリケーションプログラムからのトランザクションを受け取り、個々のサーバ側の資源（ノードＢ、ノードＣ）を識別し、個々のサーバ側の資源（ノードＢ、ノードＣ）に対して、サーバ側の資源（ノードＢ、ノードＣ）を処理する第一命令と、
　前記サーバ側の資源（ノードＢ、ノードＣ）からのコミット完了応答又はコミット失敗応答を前記個々のサーバ側の資源（ノードＢ、ノードＣ）から受け取るための第２命令と、
　前記コミット失敗応答が前記サーバ側の資源（ノードＣ）から受け取られた場合、前記コミット完了応答を送出した前記サーバ側の資源（ノードＢ）のデータベースの更新処理をスキップし、前記コミット失敗応答を送出した前記サーバ側の資源（ノードＣ）に対して前記トランザクションの一部をリトライ処理依頼するための第３命令と
　を実行させる、コンピュータ・プログラム。」
　
（３）対比
　本願発明と引用例記載の発明とを対比すると、次のことがいえる。
　
（あ）引用例記載の発明における「トランザクション管理部」、「アプリケーションプログラム」、「サーバ側の資源」は、それぞれ、本願発明における「コンピュータ」、「クライアント・アプリケーション」、「リソース」に相当する。
　
（い）引用例記載の発明における「コミット完了応答」、「コミット失敗応答」は、それぞれ、本願発明における「リソースがコミットし得た」ことを表す応答、「コミットし得なかった」ことを表す応答に相当する。
　
（う）引用例記載の発明において、「サーバ側の資源（ノードＢ）のデータベースの更新処理をスキップ」することは、本願発明において、「データベースの更新をスキップ」することに相当する。
　
（え）引用例記載の発明における「リトライ処理依頼」は、本願発明における「再処理依頼」に相当する。
　
　よって、上記（あ）〜（え）の事項を踏まえると、本願発明と引用例記載の発明とは、次の点で一致し、また、相違するものと認められる。
　
（一致点）
　本願発明と引用例記載の発明とは、ともに、
「ソフトウェア環境においてトランザクション処理をコンピュータに行わせるためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、コンピュータに
　クライアント・アプリケーションからのトランザクションを受け取り、個々のリソースを識別し、個々のリソースに対して、リソースを処理する第一命令と、
　前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための第２命令と、
　前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、データベースの更新をスキップし、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための第３命令と
　を実行させる、コンピュータ・プログラム。」
である点。
　
（相違点）
　相違点１：本願発明における「第一命令」では、「更新メッセージをインバウンドキューに配置」する動作、及び「アウトバンドキューに更新完了メッセージを配置」する動作を行わせているのに対し、引用例記載の発明においては、そのような動作を行わせていない点。
　
　相違点２：本願発明における「第３命令」では、「更新メッセージをインバウンドキューに再配置する際に、インバウンドキューに重複する更新メッセージを配置すること」をスキップする動作をも行わせているのに対し、引用例記載の発明においては、そのような動作を行わせていない点。
　
（４）判断
　そこで、上記相違点１，２について検討する。
　
（相違点１について）
　一般に、データ処理要求やデータ処理結果をキューに格納して管理することは、例えば、特開２０００−１８７６０５号公報、特開平７−３０６８２１号公報、特開平１０−３２０２５１号公報、「ジム・グレイほか，トランザクション処理［上］−概念と技法−，日本，日経ＢＰ社，２００１年１０月２９日，第１版，第４０１−４０８頁」等に見られるように、周知技術にすぎない。
　してみれば、引用例記載の発明のような、データベースの更新という処理を行うものに対して上記周知技術を適用することにより、その「第一命令」において、「更新メッセージをインバウンドキューに配置」する動作、及び「アウトバンドキューに更新完了メッセージを配置」する動作を行わせるようにすることは、当業者が容易に想到し得ることである。
　
（相違点２について）
　引用例の上記Ｃには、「クライアント（ノードＡ）ではこれらのサーバ（ノードＢ，ノードＣ）からの応答を受信して（３０５，３１０）、自ノードのデータ処理を行い（３１１）、各サーバからの返信が全てコミット済応答であるか否かを判断する（３１２）。この判断（３１２）の結果、ノードＢからはコミット済応答が返ってきているため、次の処理からはノードＢにデータ処理要求を送る必要はなく、ノードＣにのみ次のデータ処理要求を成生し送信する（３１３）。」と記載されている。
　上記記載における「ノードＢにデータ処理要求を送る必要はな」い場合に、上記「データ処理要求をキューに格納して管理する」周知技術を適用することを参酌すると、「ノードＢ」に対する「データ処理要求」が、「インバウンドキュー」に配置する「重複する更新メッセージ」となり、不必要なものとなることは、当業者にとって明らかである。
　よって、引用例記載の発明に対して、上記周知技術を参酌して、その「第３命令」において、「更新メッセージをインバウンドキューに再配置する際に、インバウンドキューに重複する更新メッセージを配置すること」をスキップする動作をも行わせるようにすることは、当業者が容易に想到し得ることである。
　
（本願発明の作用効果について）
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知技術から当業者が容易に予測することができる程度のものであって、格別のものとはいえない。
　
（５）むすび
　以上のとおり、本願発明は、引用例記載の発明及び上記周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。