【事件の表示】
　平成１１年特許願第　　９１７３号「クライアント要求をディスパッチする装置及び方法」拒絶査定に対する審判事件［平成１１年１０月　８日出願公開、特開平１１−２７２４８４］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯、本願発明
　本願は、平成１１年１月１８日の出願（パリ条約による優先権主張１９９８年２月４日、英国）であって、その請求項１に係る発明は、平成１２年１月２８日付け手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。
    
「異種オブジェクト指向クライアント／サーバ・コンピューティング環境でサーバ・オブジェクトによって実行されるクライアント要求をディスパッチする装置であって、
　クライアント要求を前記装置に伝える通信チャネルへ接続された入力及び出力を有する要求保持バッファと、
　前記要求保持バッファの出力に接続された複数の並列実行スレッドと、
　前記要求保持バッファ内の要求の意味及び前記複数の並列実行スレッドの任意のもので現在実行されている各要求の意味を検査し、要求の検査された意味が、要求のディスパッチによってサーバ・オブジェクト資源への衝突アクセスを生じることを示す場合、前記要求保持バッファから実行スレッドへの要求のディスパッチを遅延させる意味並行制御手段とを備えた、
　クライアント要求をディスパッチする装置。」
　
２．引用例
　これに対し、原査定の拒絶の理由に引用された特表平９−５１１８５８号公報（以下、引用例１という。）には、以下の事項が図面と共に記載されている。
　
（１）「【特許請求の範囲】
1.少なくとも1つのOSIマネージャと、
前記いずれかのOSIマネージヤから発行されるCMIP(共通管理情報プロトコル)要求を実行する、管理対象オブジェクトと、
それぞれ複数の管理対象オブジェクトへのアクセスを提供するOSIエージェントと
　を含むOSI(開放型システム間相互接続)システムにおいて、
　CMIP要求の実行を編成する方法であって、
　CMIP要求の実行を順次開始するため、各OSIエージェントに主スレッドを提供するステップと、
　OSIエージェントが受け取ったCMIP要求について、前記CMIP要求によってアドレスされる管理対象オブジェクトがロックされているかどうか前記主スレッドによって検査し、その管理対象オブジェクトがロックされていない場合は、
前記管理対象オブジェクトをロックするステップと、
前記CMIP要求を処理するためにサブスレッドを開始するステップとを含み、
前記サブスレッド開始ステップが、
前記サブスレッドと前記管理対象オブジェクトを登録するステップと、
前記CMIP要求を処理するステップと、
前記CMIP要求の処理が完了したとき、前記オブジェクトをロック解除するステップとを含み、
複数のCMIP要求が同時サブスレッドによって並列に実行できることを特徴とする方法。
　（中略）
3.各OSIエージェント内に主スレッドのための要求待ち行列を設けるステップと、
それぞれのOSIエージェントが受け取った任意のCMIP要求が直ちに処理できないとき、その要求を前記要求待ち行列に格納するステップと
を含むことを特徴とする、請求項1に記載の方法。
4.主スレッドがCMIP要求を処理するとき、前記CMIP要求によってアドレスされる管理対象オブジェクトがロックされていることを検出した場合に、当該CMIP要求を前記要求待ち行列中に戻すステップをさらに含むことを特徴とする、請求項3に記載の方法。」（特許請求の範囲）
　
（２）「【発明の詳細な説明】
OSIエージェントにおける要求の並列実行
本発明は、開放型システム間相互接続(OSI)環境における共通管理情報プロトコル(CMIP)要求の処理に関し、詳細には、複数の要求が同時に受け取られたまたは保留中のときに、いわゆるOSIエージェントにおいて前記CMIP要求を実行することに関する。」（公報４頁１行〜６行）
　
（３）「発明の目的
したがって、本発明の一目的は、不当な遅延なしにエージェントによって多数のCMIP要求が処理できる、CMIP要求の実行方法を考案することである。
　もう一つの目的は、スレッドを使用し、かつオブジェクトをロックすると相互排除のために長い遅延が生じるときに引き起こされる欠点を回避する、CMIP要求の実行方法を提供することである。」（公報７頁７行〜１３行）
　
（４）「発明の基礎
次に第2図及び第3図に関して本発明の詳細を説明する。第2図は、CMIP要求を処理する際にOSIエージェントで実施される動作を示す流れ図であり、第3図はCMIP要求を処理するためのOSIエージェントの様々な部分の相互作用を示す図である。
本発明の要点は次の通りである。各エージェントは「主スレッド」を有し、これは常に活動状態でメッセージ・ディスパッチ機能を実行する。主スレッドは、ネットワークからメッセージを読み取り、その主スレッド用に提供された内部要求待ち行列からメッセージ(があれば)を取り出す。エージェント内で実行される各CMIP要求ごとに別々のサブスレッドが開始される。複数のサブスレッドからある管理対象オブジェクト・インスタンスへのアクセスを防止するため、各管理対象オブジェクト・インスタンスはそれぞれロックを有する。オブジェクト・インスタンスは、当該のCMIP要求が実行されている限り、1つのサブスレッドもこついてロックされ、処理が完了するとロック解除される。
（中略）
A.主スレッド用基本手順
B.主スレッド用要求処理手順
注:最後のステップで、以前に内部要求待ち行列から取り出されたメッセージが待ち行列に戻され、あるいはネットワークから新たに受け取ったメッセージが新たにその待ち行列に入れられる。
　2.オブジェクトをロックする。
　3.サブスレッドを開始する。
C.サブスレッド用手順
　1.サプスレッドと、それが働きかけているオブジェクトをスレッド・マネージャに登録する。
　2.要求を処理する。
　3.要求がCMIP要求でない場合、主スレッドにオブジェクトをロックする。
　4.サブスレッドを終了し、それをスレッド・マネージャから登録解除する。」（公報８頁３行〜９頁１５行）
　
　以上の記載より、引用例１には以下の発明が記載されている。
　
　開放型システム間相互接続（ＯＳＩ）環境におけるクライアント／サーバシステムにおいて、ＣＭＩＰ要求を処理するためにＣＭＩＰ要求をデイスパッチする主スレッドを有するＯＳＩエージェントであって、
　前記ＣＭＩＰ要求を前記主スレッドに伝えるネットワークに接続された入力及び出力を有する要求待ち行列と、
要求待ち行列の出力であるＣＭＩＰ要求をエージェント内で実行するためのサブスレッドと、
　主スレッドがＣＭＩＰ要求を処理するとき、管理対象オブジェクトをロックし、サブスレッドを開始するもので、次に、主スレッドが要求待ち行列から取り出したＣＭＩＰ要求を処理するときに管理対象オブジェクトがロックされていることを検出した場合、前記ＣＭＩＰ要求を前記要求待ち行列に戻す制御手段を備えた、
　複数のＣＭＩＰ要求を同時サブスレッドによって並列実行する主スレッドを有するＯＳＩエージェント
　
　また、原査定に参考文献として提示された特開平２−２９１０２８号公報（以下、周知例という。）には、以下の事項が図面と共に記載されている。
　
「〔従来の技術〕
　第３図は一般的なロック管理の説明図、第４図は従来の排他マトリックスの例を示す。
　計算機システムでは、データベースなどの計算機資源（リソース）を使用するときに、アクセス競合による矛盾発生を防止し、データのインテグリティを保証するために、排他制御が必要となる。排他制御を実現するためには、一般にロックが使用される。
（中略）
このような資源に対するロックの保持が、前に処理しているロックのモードとの関係で、可能であるかどうかを決定する場合に、排他マトリックスが用いられる。この排他マトリックスは、計算機のメモリテーブル化して用意されることもあり、また、処理ロジックとして組み込まれることもある。
　第４図は、その従来の排他マトリックスの例を示している。ここで、
　Ｘ　：排他モード（または更新モード）
　Ｓ　：共用モード（または参照モード）
（中略）
　例えば、現在のモードが排他モードＸであるとき、新たな要求モードは、ロック不可となる。現在のモードが共用モードＳであるとき、新たな共用モードＳ（中略）は、ロック可となり、他の要求モードに対してはロック不可となる。」（公報２頁左上欄１５行〜右下欄１７行）
　
 ３．対比
   本願発明（以下、前者という）と引用例１に記載された発明（以下、後者という）とを比較すると、
　前者の「クライアント要求」「ディスパッチする装置」「並列実行スレッド」「サーバ・オブジェクト資源」は、それぞれ、後者の「ＣＭＩＰ要求」「ディスパッチする主スレッド」「サブスレッド」「管理対象オブジェクト」に相当し、前者の「要求のディスパッチによってサーバ・オブジェクト資源への衝突アクセスを生じることを示す場合」と後者の「ＣＭＩＰ要求を処理するときに管理対象オブジェクトがロックされていることを検出した場合」は同等のものである。
　前者の「要求保持バッファ」と後者の「要求待ち行列」とは共にスレッドに割り当てられるまで要求を一時的に記憶しておくものであるから、前者の「要求保持バッファ」は後者の「要求待ち行列」に対応する。また、前者のものには「要求保持バッファの出力に接続された複数の並列実行スレッド」と記載されているが、スレッドとはコンピュータにおけるソフトウエアの実行単位であるから、”出力に接続されたスレッド”という表現は不適切なものであり、”要求保持バッファからの出力である要求を割り当てる複数の並列実行スレッド”という意味と解される。してみると、これは後者の「要求待ち行列の出力であるＣＭＩＰ要求をエージェント内で実行するためのサブスレッド」と実質的に同等のものである。
　
　してみると、両者は次の点で一致している。　
　
　クライアント要求をディスパッチする装置であって、
　クライアント要求を前記装置に伝える通信チャネルへ接続された入力及び出力を有する要求保持バッファと、
　前記要求保持バッファの出力に接続された複数の並列実行スレッドと、
　要求のディスパッチによってサーバ・オブジェクト資源への衝突アクセスを生じることを示す場合における制御手段とを備えた、
　クライアント要求をディスパッチする装置
　
　一方、両者は以下の点で相違している。
　
相違点１
  前者が、異種オブジェクト指向クライアント／サーバ・コンピューティング環境でサーバ・オブジェクトによってサービスの実行がなされるシステムを前提とするものであるのに対し、後者は開放型システム相互接続（ＯＳＩ）環境におけるクライアント／サーバシステムによってサービスの実行がなされるシステムを前提とする点
　
相違点２
　要求のディスパッチによってサーバ・オブジェクト資源への衝突アクセスを生じることを示す場合を、後者ではサーバ・オブジェクト資源のロックによって検出しているのに対し、
前者では前記要求保持バッファ内の要求の意味及び前記複数の並列実行スレッドの任意のもので現在実行されている各要求の意味を検査することによって検出している点
　
相違点３
　衝突アクセスを生じていることを示す場合における制御手段が、後者ではクライアント要求を要求保持バッファに戻しているのに対し、前者では要求保持バッファから実行スレッドへの要求のディスパッチを遅延させている点
　
４．相違点についての検討
 （１）相違点１について
　共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ）によって、分散オブジェクト環境のクライアントサーバシステムを構築することは本願出願当時周知のことであるから（必要ならば、平成１１年１１月１日付拒絶理由通知で引用した「情報処理」第３５巻、第９号（１９９４年９月、社団法人情報処理学会発行）ｐｐ．853-858を参照）、後者のような開放型システム相互接続（ＯＳＩ）環境におけるクライアント／サーバシステムをＣＯＲＢＡに基づいて構築することは格別のことではない。
　
 （２） 相違点２について
　２．引用例の項の周知例に示されるように、計算機資源のアクセス競合を回避する手法として排他制御が用いられ、排他制御を実現するためにロックが使用される。ロックによる排他制御では、資源に対する現在のモードと新たな要求のモードの関係でロックの可否を決定している。
　前者における「要求の意味」というのは、読み取りアクセス、または、書込みアクセスのどちらを含むかということであり、一方、後者の「ロック」において検出するのは書込みアクセス、または、読み取りアクセスのことであるから、ロックを用いてアクセスの衝突を検出することと、スレッドで実行中の要求の意味と新たな要求の意味を検査してアクセスの衝突を検出することは同等のことである。従って、後者におけるロックによる衝突アクセスの検出手法は、前者の検出手法と変わるところがないから、相違点２は表現上の相違にすぎない。
　
（３）相違点３について
　前者において「要求保持バッファから実行スレッドへの要求のディスパッチを遅延させる」点について、発明の詳細な説明には、その００３９段落に
「【００３９】　
　さらに、並行制御ユニット３４は、次にディスパッチする候補としてバッファ内のトップの要求のみを常に考慮する必要はない。並行制御ユニット３４はバッファ内のすべての要求を検査し、順序に関係なくディスパッチのために取り出すことができる。」と記載されている。
　これは、要求保持バッファ内のすべての要求を検査し、衝突アクセスが生じない要求については要求保持バッファから取り出し並列実行スレッドに割り当てるが衝突アクセスを生じるものについては要求保持バッファに保持したままにしておくということである。後者では、衝突アクセスを生じるときには要求保持バッファに戻すとされており、これは要求保持バッファに格納されている要求についてディスパッチできるかどうか検査を行うが、ディスパッチできないときには要求保持バッファに戻して要求を保持するのであるから、結局のところ両者ともディスパッチを遅延させることに変わりはなく、この相違点を格別のものということはできない。
　
５．むすび
　したがって、本願発明は引用例１に記載された発明及び周知例に基いて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。