【事件の表示】
　平成３年特許願第１１６６９７号「コミット手順を最適化する方法およびコンピュータ・システム」拒絶査定に対する審判事件［平成４年８月１８日出願公開、特開平４−２２９３３５］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続きの経緯及び本願発明
　
　本願は、西暦1990年（平成２年）５月16日にアメリカ合衆国にした特許出願に基づいてパリ条約第４条の規定による優先権を主張した平成３年４月22日の特許出願であって、請求項１に係る発明（以下、「本願第１発明」という。）は、願書に添付した明細書及び図面の記載からみて、該明細書の特許請求の範囲の【請求項１】に記載されたとおりの次の事項により構成されるものである。
「資源の読み取り又は更新を行う複数の作業要求、及び前記更新をコミットする１つのコミット要求を出すアプリケーション・プログラムと、該アプリケーション・プログラムを制御するオペレーティング・システムとを含む実行環境において、
　前記オペレーティング・システムが、　
　前記作業要求に応答して、要求された各資源の識別子と、作業要求が読み取り専用か更新かを示す情報と、要求された資源が１段階コミット手順をサポートしているかどうかを示す情報とを記憶することにより資源を登録し、
　要求された各資源の資源マネジャに前記作業要求を送って処理させ、
　前記コミット要求に応答して、登録された資源のうち更新が要求された資源の数を決定し、
　前記資源の数が２以上であれば、それらの資源に対して２段階コミット手順を実行し、
　前記資源の数が１で、且つその資源が１段階コミット手順をサポートしていれば、該資源に対して１段階コミット手順を実行し、該資源が１段階コミット手順をサポートしていなければ２段階コミット手順を実行することを特徴とする、
　コミット手順の最適化方法。」
　
第２　刊行物に記載された発明
　
１　刊行物１
（１）これに対して、原審において引用された「情報処理学会研究報告」情処研報VOL.89，NO．70（1989年９月８日、社団法人情報処理学会発行。以下、「刊行物１」という。）には、分散データベースシステムＤＲＥＡＭシステムの機能及び処理構成に関して、次の事項が図面と共に記載されている。
　ア　分散トランザクション機能について
「複数サイトにまたがるトランザクションの一貫性を保証するために、複数サイトの更新の同期を制御する機能が必要である。ＤＲＥＡＭでは２相コミットメカニズムを用いてトランザクションの更新における原子性を保証する。」（５頁左欄17行ないし21行）
　イ　コミットメントの最適化機能について
「トランザクションは、実際には各サイトで代理実行されるサブトランザクションの集まりによって実現される。各サブトランザクションはデータの検索、更新を行う。また、トランザクション発生サイトにはトランザクションのコミット時にこれらサブトランザクションを２相コミットで制御するためのコーディネータがある。コーディネータは、実際に更新を行ったサブトランザクションを管理している。コミット時には、サブトランザクションの更新の状態に応じて以下のようなコミットメントプロトコルの選択を行う（表５）。
　（ａ）更新サブトランザクションなしの場合
　どのサブトランザクションも更新を行っていなければトランザクションはread only transactionであるので２相コミットの必要はない。この場合には全サブトランザクションをただちに終了させてよい。
　（ｂ）更新サブトランザクションが１個の場合
　１サイトだけが更新されている場合も他サイトとの矛盾は発生しないので２相コミットの必要はない。全サブトランザクションを終了させ、更新サブトランザクションのコミットの正否がトランザクションのコミットの正否となる。
　（ｃ）自サイトと１他サイトが更新されている場合
　２サイト以上が更新されているので両者に矛盾が生じないように２相コミットが必要となる。ただし、次のようにしてネットワーク上の通信回数を減らすことができる。まず、自サイト２相コミットの第１相の終わった状態、いわゆるセキュアな状態にする。これが成功したら他サイトをコミットする。他サイトのコミットが成功したら自サイトをコミットし、失敗したら自サイトをアボートする。他サイトのコミットの正否がトランザクションのコミットの正否となる。
　（ｄ）２他サイト以上が更新されている場合
　この場合には通常の２相コミットプロトコルに従う。
　…（略）…。
　　表５　ＤＲＥＡＭのコミットメントプロトコル
　　更新サブトランザクション　コミットメントプロトコル
　　なし　　　　　　　　　　　１相
　　１サイト　　　　　　　　　１相
　　自サイト　　　　　　　　　２相＊
　　２他サイト以上　　　　　　２相
　　　　　　＊通信は１相（本文参照）」（５頁左欄32行ないし右欄末行）
　ウ　処理構成の概要について
「ＤＲＥＡＭは図７に示すように構成される。大きく分けると、ＳＱＬプロセッサ（実行時ルーチン）、クライアント、クライアントから起動される複数のサーバ、およびネットワークシステムからなる。」（６頁右欄２行ないし５行）
　エ　ＳＱＬプロセッサについて
「ＳＱＬプロセッサは、アプリケーションプログラムとリンクされ、ＳＱＬの機能の一部を実現する。」（６頁右欄13行ないし15行）
　オ　クライアントについて
「クライアントは、分散したデータへのアクセスに関する制御を行なう。問い合わせの分解、最適化、問い合わせの実行などを行い、コミットメント時のサブトランザクションに対するコーディネータとしても働く。クライアントは利用者のデータベースセッションに対応して各利用者毎に起動される。
　…（略）…。
　クライアントは以下の機能モジュールから構成される。
　（１）問い合わせ処理部
　　オプティマイザ、データディレクトリマネージャ、問い合わせ実行部の各モジュールで構成される。
　　・オプティマイザ
　ＳＱＬのカーソル宣言に対応して問い合わせの分解と最適化を行い、問い合わせ実行部の入力となる実行用のプランを生成する。…（略）…。
　　・データディレクトリマネージャ
　データディレクトリを検索して表名の解釈を行い格納サイトを決定する。…（略）…。
　　・問い合わせ実行部
　クライアント側のオプティマイザの出力である、実行用のプランに従って各サイトのカーソルからの行のフェッチ、パラメータの転送を制御する。またＯＲの条件の評価もここで行う。さらに、ＳＱＬのUPDATE文など更新操作のある文を処理する場合にトランザクションマネージャを呼び出し、更新の行われたサイトを記録しておく。
　（２）トランザクションマネージャ
　トランザクションの管理を行う。クライアント側のトランザクションマネージャはstart_transaction，commit_transaction，abort_transactionの利用者トランザクションを制御する制御プリミティブを提供する。また実際に更新の行われたサイトを記録するためのプリミティブを持つ。利用者からのcommit_transactionが発行されると、コミットメントプロトコルの選択を行いコミットメント制御を行う。
　（３）サイトマネージャ
　各マネージャは他のサイトへアクセスする必要が起きると、このマネージャを呼び出す。ここでは要求に従ってサーバの起動／停止を行う。…（略）…。
　（４）データベースアクセスプロトコルモジュール
　クライアントは分散データベースアクセスプロトコルに従ってサーバに要求を送り、またサーバからの結果を受け取る。ここでは、このためのＰＤＵの生成と解釈を行う。」（７頁左欄２行ないし右欄18行）
　カ　サーバについて
「サーバはローカルなデータベース管理システムとしてＲＥＡＭを持ち、各サイトでの実際のデータベースアクセスを行う。またコミット時にはコーディネータであるクライアントに対してサブトランザクションとしての制御を行なう。サーバはクライアント毎に各サイトで起動される。
　（１）データベースアクセスプロトコルモジュール
　クライアントとの通信のためのＰＤＵ解釈と生成を行う。…（略）…。
　（２）問い合わせ処理部
　…（略）…。
　（３）トランザクションマネージャ
　サーバ側のトランザクションマネージャはサブトランザクションに関する制御を行う。start，commit，abortのプリミティブに加えて、２相コミットに対応するsecureプリミティブを持つ。これらの機能はＲＥＡＭの機能として予め実現されており、実際の処理はＲＥＡＭ内で行われる。ただし２相コミットのためのロギングはここで行う。」（７頁右欄25行ないし８頁左欄７行）
　そして、前記記載について、この分野の技術常識を加味しつつ総合判断すると、更に、次の技術事項を読み取ることができる。
　キ　ＤＲＥＡＭは、少なくとも、アプリケーションプログラム、ＳＱＬプロセッサ、クライアント、ネットワークシステム及びサーバを含む実行環境において動作されるものであり、且つ、前記ＳＱＬプロセッサ、クライアント、ネットワークシステム及びサーバの部分は、所謂’オペレーティングシステムを構成するものであること
　ク　「実際に更新を行ったサブトランザクションを管理する」（５頁左欄39行ないし40行、前記イ参照。）或いは「更新の行われたサイトを記録しておく」（７頁左欄37行ないし38行、前記オ参照。）ことを実現するためには、前記サイトを識別する情報と該サイトについて更新が行われたことを示す情報を記憶することにより前記サイトを登録することが必要であること
（２）そこで、前記（１）アないしクの事項を、本願第１発明の構成に準じて整理すると、刊行物１には、次の事項により構成される発明（以下、「刊行物１に記載された発明」という。）が記載されているということができる。
　各サイトで代理実行されるデータベースの読み取り又は更新を行う複数のサブトランザクションの集まりによって実現されるトランザクション要求、及び前記更新をコミットする“commit_transaction”要求を出すアプリケーションプログラムと、該アプリケーションプログラムを制御するオペレーティングシステムとを含む実行環境において、
　前記オペレーティングシステムが、
　前記サブトランザクションに応じて、該サブトランザクションに係る各サイトを識別する情報と、該サイトにおいて更新が行われたことを示す情報とを記憶することによりサイトを登録し、
　サブトランザクションに係るサイトのトランザクションマネージャに前記サブトランザクションを送って処理させ、
　前記コミット要求に応答して、登録されたサイトのうち更新が行われたサイトの数を決定し、
　前記サイトの数が２以上であれば、それらのサイトに対して２相コミットメントプロトコルを実行し、
　前記サイトの数が１であれば、該サイトに対して１相コミットメントプロトコルを実行することを特徴とする、
　コミットメントプロトコルの最適化方法
　
２　刊行物２
　同じく特開昭６３−２５９７４２号公報（昭和63年10月26日、特許庁発行。以下、「刊行物２」という。）には、資源同期制御方式に関して、次の各事項が記載されている。
（１）「本発明の目的は、トランザクションの終了時のデータベース処理システムの資源に対して、その資源の整合性の保証を損うことなく、各データベースの処理システム間の交信回数を削減する資源同期制御方式を提供することにある。」（２頁右上欄16行ないし末行）
（２）「上記目的は、各データベースの処理システムのそれぞれの資源でのトランザクション処理において、各資源への更新処理が行われているか否かを管理する資源群処理状態ビット列と、更新処理のなされている資源群の名称を保持する資源群リストとから成る資源群処理状態管理テーブルを設け、トランザクション終了処理にあたり、当該資源（群）処理状態管理テーブルを参照し、資源群処理状態ビット列と資源群リストから更新処理の為された資源群を知り、更新処理の態様により、更新処理が全く為されなかった場合及び更新処理が一の資源のみで為された場合に、第１フェーズ（更新保証処理）と第２フェーズ（終了処理）から成る同期処理のうち、第１フェーズを省略することで達成される。」（２頁左下欄２行ないし16行）
　
第３　対比
　
１　本願第１発明と刊行物１に記載された発明とを対比する。
（１）刊行物１に記載された発明の「データベース」は、本願第１発明の「資源」についての典型的例の１つであり、また、刊行物１に記載された発明において、「トランザクション」は、前記「データベース」の読み取り又は更新を行う複数のサブトランザクションの集まりによって実現されるものであるところ、本願第１発明において、「作業要求」は、アプリケーション・プログラムからどのようにして出されるものであるのか特定されていず、また、該「作業要求」は、「資源」の読み取り又は更新を行うものであるから、結局のところ、本願第１発明の「資源の読み取り又は更新を行う複数の作業要求」は、刊行物１に記載された発明の「各サイトで代理実行されるデータベースの読み取り又は更新を行う複数のサブトランザクションの集まりによって実現されるトランザクション要求」と実質的に変わるところはない。
（２）また、本願第１発明の「更新をコミットする１つのコミット要求」は、刊行物１に記載された発明の「更新をコミットする“commit_transaction”要求」と一致するものである。
（これについて、請求人は、審判請求書において、「引用発明ではアプリケーションプログラムからの１つの問い合わせを複数の問い合わせに分解して各サイトへ送り（引用例の第４頁右欄第２行〜５行）、それに対してコミットメントの最適化が行われるようになっている。これは、明らかに、複数の作業要求に対して１つのコミット要求を出すという思想とは異なるものである。」（５頁４行ないし８行）と主張するが、前記（１）に認定したとおり、本願第１発明の「資源の読み取り又は更新を行う複数の作業要求」は、刊行物１に記載された発明の「各サイトで代理実行されるデータベースの読み取り又は更新を行う複数のサブトランザクションの集まりによって実現されるトランザクション要求」と実質的に変わるものではなく、また、この分野において、トランザクションは、通常、“原子性、一貫性、独立性、耐久性により特徴づけられる仕事の単位”と捉えられるものであって、該トランザクションの実現要素である複数のサブトランザクションによる更新をコミットする“commit_transaction”要求は、１つのコミット要求でなければ、少なくとも、トランザクションの“原子性”を保つことができないことは明らかであるから、請求人の前記主張は採用できない。）
（３）本願第１発明の「要求或いは登録された資源」と刊行物１に記載された「サブトランザクションに係る或いは登録されたサイト」とは、“要求或いは登録された対象”である点で一致する。
（４）刊行物１に記載された発明の「サブトランザクションに係るサイトのトランザクションマネージャ」は、該サイトのデータベースの読み取り又は更新を行うサブトランザクションを処理するものであるから、本願第１発明の「資源マネジャ」に相当する機能を有するものであることは明らかである。
（５）本願第１発明の「１段階コミット手順」及び「２段階コミット手順」は、それぞれ、刊行物１に記載された発明の「１相コミットメントプロトコル」及び「２相コミットメントプロトコル」と一致する概念である。
　
２　したがって、本願第１発明と刊行物１に記載された発明とは、
　資源の読み取り又は更新を行う複数の作業要求、及び前記更新をコミットする１つのコミット要求を出すアプリケーション・プログラムと、該アプリケーション・プログラムを制御するオペレーティング・システムとを含む実行環境において、
　前記オペレーティング・システムが、　
　前記作業要求に応答して、要求された各対象の識別子と、作業要求が読み取り専用か更新かを示す情報とを記憶することにより前記対象を登録し、
　要求された各対象の資源マネジャに前記作業要求を送って処理させ、
　前記コミット要求に応答して、登録された対象のうち更新が要求された対象の数を決定し、
　前記対象の数が２以上であれば、それらの対象に対して２段階コミット手順を実行することを特徴とする、
　コミット手順の最適化方法
である点で一致し、次の２点で相違する。
（１）要求或いは登録された対象、言い換えれば、コミットの管理対象が、本願第１発明では、資源であるのに対して、刊行物１に記載された発明では、サイトである点
（２）本願第１発明では、要求された対象を登録する際に、更に、該対象が１段階コミット手順をサポートしているかどうかを示す情報を記憶すると共に、更新が要求された対象の数が１で、且つその対象が１段階コミット手順をサポートしていれば、該対象に対して１段階コミット手順を実行し、該対象が１段階コミット手順をサポートしていなければ２段階コミット手順を実行するのに対して、刊行物１に記載された発明では、前記情報を記憶せず、また、更新が要求された対象の数が１であれば、該対象に対して１段階コミット手順を実行するというに留まる点
　
第４　相違点についての判断
　
１　相違点（１）について
　刊行物１に記載された発明において、トランザクションの実現手段である複数のサブトランザクションの各々は、サイトではなく、該サイトに配置されたデータベースの読み取り又は更新を行うものであり、また、刊行物１の２頁或いは４頁には、各サイトに、１個のデータベースが配置されているものが図示されており、更には、サイトを示す情報は、データベースの格納位置を示すものであって、該データベースを特定する情報でもあるから、刊行物１に記載された発明においては、コミットの管理対象は、実質的には、前記データベースという資源であると推量されるところ、刊行物２に、コミット手順の最適化方法において、前記対象を、読み取り又は更新が行われるデータベース、即ち、資源とすることが記載されているから、刊行物１に記載された発明において、コミットの管理対象をサイトに代えてデータベースという資源とすることは、当業者が容易に為し得た構成変更に相当する。
　
２　相違点（２）について
　計算機システムの技術分野においては、２つの手段間で、何らかの交信手順にしたがって交信を行う場合、相手手段がサポートする交信手順を事前に取得ないし登録しておくことにより、実際の交信時に、相手手段のサポートする交信手順にしたがって交信するようにすることは、当業者における周知・慣用手段であるから、刊行物１に記載された発明において、前記周知・慣用手段を適用して、要求された対象を登録する際に、更に、該対象が１段階コミット手順をサポートしているかどうかを示す情報を記憶すると共に、更新が要求された対象の数が１で、且つその対象が１段階コミット手順をサポートしていれば、該対象に対して１段階コミット手順を実行し、該対象が１段階コミット手順をサポートしていなければ２段階コミット手順を実行するようにすることは、当業者が適宜に為し得た設計事項の範疇に属する事柄に過ぎない。
　
第５　結び
　
　以上第１ないし第４を総合判断すると、本願第１発明は、刊行物１に記載された発明に基づき同２に記載された発明を適用して当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、【請求項２】ないし【請求項１０】の各発明について言及するまでもなく、本願は、拒絶されるべきものである。
　よって、結論のとおり審決する。