【事件の表示】
　平成１０年特許願第１３９５３２号「複数ホストコンピュータ間における入出力バッファシステムおよび入出力バッファ制御方法」拒絶査定不服審判事件〔平成１１年１２月１０日出願公開、特開平１１−３３８７４７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯、本願発明
　　本願は、平成１０年５月２１日の出願であって、その請求項１に係る発明は、平成１７年１月１８日付け手続補正書で補正された明細書および図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。
　   
「【請求項１】　ホスト間通信手段で互いに接続された複数のホストコンピュータと前記複数のホストコンピュータ間で共有ファイルとして使用される外部記憶装置とを有し、前記ホストコンピュータは、
バッファ領域と前記バッファ領域を管理するバッファ存在フラグを有するバッファ制御テーブルとを含むバッファシステムと、
ＯＳを介してアプリケーションから前記バッファ領域内に更新データを受け取るデータ受取手段と、
前記データ受取手段が更新データを受け取ったときに前記ホスト間通信手段を介して他の前記ホストコンピュータに対して更新対象となっているデータのバッファ領域無効要求を発信するホスト間通信発信手段と、
前記ホスト間通信手段を介して他の前記ホストコンピュータからの処理要求あるいは前記バッファ領域無効要求の結果を受信するホスト間通信受信手段と、
ファイル読込手段が前記バッファ領域にデータを読み込んだときに前記バッファ存在フラグをオンに操作し他の前記ホストコンピュータからバッファ領域無効要求を受信したときにバッファ存在フラグがオンであればオフに操作するフラグ操作手段と、
前記バッファ領域無効要求の結果が成功通知であったときに前記バッファ領域内の更新データを前記共有ファイルに書き込むファイル書込手段と、を備えることを特徴とする複数ホストコンピュータ間における入出力バッファシステム。」
 
２．引用例
　これに対し、当審において平成１６年１１月１９日付で通知した拒絶の理由で引用された特開昭６２−２７８６６０号公報（以下、引用例１という。）には、以下の事項が図面と共に記載されている。
　
（Ａ）「本発明は、複数の処理装置がデータを共用する共用ファイルへのアクセス制御に係り、特に共用ファイルへの排他制御を行なってのデータ更新にともなう共用ファイルのデータと各処理装置が保有するメモリ内のデータの不一致防止を図り、入出力処理の高速化に好適なアクセス制御方式に関する。」（公報１頁右下欄７行〜１３行） 
 　 　
（Ｂ）「本発明の目的は、更新されたデータを識別する情報を他の処理装置に提供し、この情報をもとに更新されていないデータは、メモリ上に存在するならば、そのまま使用し、メモリ上に存在しなければ、共用ファイルにアクセスして必要なデータを取り出し、また、更新されているデータは、共用ファイルにアクセスして必要なデータを取り出して使うことにより、情報処理システムの信頼性を確保し、同時にＩ／Ｏ処理速度の低減を図り、コンピュータ処理の高速化を図るアクセス制御方式を提供することにある。」（公報２頁左下欄１９行〜右下欄９行） 
 　　 
（Ｃ）「第１図は、本発明が適用される一構成例を示す図である。複数の処理装置（プロセサ）、例えばプロセサＡ，プロセサＢ，プロセサｉは、それぞれレコード常駐バッファ２ａ，２ｂ，２ｉを有し、データ（レコード）の入出力等のアクセス制御を行うレコード入出力サービスプログラム４ａ，４ｂ，４ｉを備えている。また、外部記憶装置の共用ファイル１には、各種レコードがＲ２からＲｎ＋１まで納められており、これらとは別に共用ファイル用更新レコード登録簿５のＲ１レコードも納められている。共用ファイル用更新レコード登録簿５とは、共用ファイル１中の固定位置レコードＲ１に更新レコードの番号を記録しておく登録簿である。さらに、各プロセスにも、同様の登録簿を備えることとする。これをプロセス用更新レコード登録簿３ａ，３ｂ，３ｉという。 
　次に、本システムでの動作を説明する。プロセサの１つプロセサＡのレコ−ド入出力サービスプログラム４ａは、レコ−ド常駐バッファ２ａに共用ファイル１のレコードを蓄積し、レコード入力要求がある場合に、レコード常駐バッファ２ａ内を検索して、必要なレコードがあれば、これを使うし、必要なレコードが存在しなければ、共用ファイル１にアクセスし、レコードを取り出して処理を行わせることにより、レコード入力Ｉ／Ｏ回数の削減を行なう。すべてのプロセサのレコード常駐用バッファ２には必ずプロセサ用更新レコード登録簿（以下Ｒ１レコードと記す）３を保存しておく。次にプロセサＡを中心に説明する。レコード入出力サービスプログラム４ａは共用ファイル１へのアクセス開始要求により、共用ファイル１の排他制御（第２図(1)）を行ない、共用ファイル１のＲ１レコード５を入力する（第２図(2)）。レコード常駐用バッファ２ａに保存してあるＲ１レコード３ａと共用ファイル１より入力したＲ１レコードを比較し、更新されているレコード番号（他プロセサによって更新されたレコード）を知る（第２図(3)）。更新されているレコード番号のレコードがレコード常駐用バッファ２に存在すればそのレコードを切り捨てる（第２図(4)）。Ｒ１レコード３ａについては、共用ファイル１から入力した最も新しいＲ１レコードと比較切捨てを行ったプロセサ用更新レコード登録簿３ａのＲ１レコードとの間の更新時点の時差は生じないことになる。従って、レコード常駐用バッファ２ａ中のレコードで、ファイル１のレコードと等しくないレコードは排除されることになる。レコード常駐用バッファ２ａ内のプロセサ用更新レコード登録簿３ａが新しく更新された後に、要求された番号のレコードが、レコード常駐用バッファ２ａに存在すれば、そのレコードを要求元にわたす。存在しなければ、共用ファイル１からレコードを入力する。入力したレコードはレコード常駐用バッファ２ａに蓄積する（第２図(5)(6)）。」（公報３頁右上欄６行〜右下欄１９行） 
 　 
（Ｄ）「レコードの出力要求を受付けたときは、出力するレコードをファイル１に書出し、レコード常駐用バッファ２ａにレコードを蓄積する（第２図(7)(8)）。 
　アクセス終了要求では、更新したレコード番号をプロセサ用更新レコード登録簿３ａと共用ファイル用更新レコード登録簿５のＲ１レコードに登録してファイル１に書出し、ファイルの排他制御をはずす（第２図(9)(10)）。」（公報４頁左上欄３行〜１１行） 
 　 
（Ｅ）「上記実施例では、更新されたレコードを知る手段として、更新レコード登録簿をプロセス側と共用ファイル側の相方に保有させ、比較することで行っていたが、本発明は、更新レコードを他のプロセサに知らせる手段を有すればよく、例えば、共用ファイルにレコード番号に対応する更新回数を記憶しておくテーブルを設け、各プロセスは、そのテーブルを検索することで、必要とするレコードが更新されたか否かを判定する手段を設けることも可能である。」（公報４頁右上欄４行〜１３行） 
 　 
　以上より、引用例１には以下の発明が記載されている。
　
　複数の処理装置と前記複数の処理装置間で共用ファイルとして使用される外部記憶装置とを有し、 
　前記処理装置のレコード常駐バッファには各種レコードと共用ファイル用更新レコード登録簿とを含み、 
　データ（レコード）の入出力等のアクセス制御を行うレコード入出力サービスプログラムと、 
　データ（レコード）の更新要求を受け付けたときは、更新したレコード番号と更新レコードを共用ファイルに書き出す手段と、 
　前記共用ファイル用更新レコード登録簿を読み出す手段と、 
　要求された番号のレコードがレコード常駐バッファに存在すれば、要求されたレコードを要求元に渡し、存在しなければ共有ファイルから該レコードを入力しレコード常駐バッファに格納し、要求元に渡す手段と、 
　前記レコード常駐バッファに保存してあるＲ１レコードと共用ファイルより入力したＲ１レコードを比較し、他プロセッサによって更新されたレコードを知り、該レコードが前記レコード常駐バッファに存在すれば削除する手段と、 
　を備える複数処理装置間における入出力バッファシステム 
　
　また、当審において平成１６年１１月１９日付で通知した拒絶の理由で引用された特開平４−９５１５２号公報（以下、引用例２という。）には、以下の事項が図面と共に記載されている。
　
（Ｆ）「丸１（丸数字をこのように表記し、以下、同様とする。）自キャッシュメモリに対応するＣＰＵからの読み出し（リード）指示により１ブロックを読み出して（Ｖ＝１→０）、状態Ｉから状態ＥＵに遷移する。」（公報２頁左下欄１０行〜１３行）
　
（Ｇ）「丸４　自ＣＰＵからの書き込みを行い（Ｍ＝０→１）、他のキャッシュメモリに対するバッファ無効化要求を行って（Ｓ＝１→０）、状態ＳＵから状態ＥＭに遷移する。」（公報２頁右下欄２行〜５行）
　
（Ｈ）「第２図には本発明のキャッシュメモリ一致制御方式が適用される密結合マルチプロセッサシステムの構成が示される。
　本システムでは、複数のコピー・バック方式のキャッシュメモリ1A,1B（本実施例では図示の簡単化のため２個のみ図示）が、システムバス４を介して少なくとも１つの共有メモリ３（同様に簡単化のため１個のみ図示）に接続されている。また、各キャッシュメモリ1A,1Bには、それぞれ対応するキャッシュメモリへのアドレス情報の供給やデータ読み出しおよび書き込み等の制御を行う中央処理装置（ＣＰＵ）2A,2Bが接続されている。
　第３図にはキャッシュメモリ1A,1Bの内部構成が示される。図中、破線で囲まれた部分は本発明の特徴をなす部分である。
　同図において、３１はタグ部（タグメモリ）であって、アクセスデータの物理アドレスを記憶するアドレス部と、３つの状態フラグ、すなわちアクセスアドレスで指示される領域が自己のキャッシュメモリ内に存在するか否かを指示する有効指示フラグ（Ｖ）とデータが書き換えられたか否かを指示する変更済指示フラグ（Ｍ）と他のキャッシュメモリとの間で同じデータを共有しているか否かを指示する共有状態指示フラグ（Ｓ）、を有している。」（公報４頁右上欄４行〜左下欄９行）
　
（Ｉ）「一方、共有通知信号ＳＳに対する応答信号ＳＲがアサートされない場合（ＳＲ＝”０”レベル）には、アンドゲート４０が開くため、Ｖビット・クリア制御回路４１が機能して有効指示フラグＶをオフ（Ｖ＝０）にし、さらにアンドゲート３８を通して共有状態指示フラグＳもオフ（Ｓ＝０）にする。」（公報５頁右上欄８行〜１３行）
　
　上記（Ｆ）（Ｇ）の記載は、従来例における状態遷移の説明であるが、引用例２における実施例はこの従来例を元に説明されているので、上記（Ｆ）（Ｇ）の記載は、引用例２における実施例の一部を成すものである。すると、上記（Ｆ）から（Ｉ）には、共有メモリにおけるデータの整合性を維持する手法として、
　複数のキャッシュメモリと１つの共有メモリがシステムバスを介して接続されているマルチプロセッサシステムのデータの整合性を維持する手段として、 
　キャッシュメモリには、データ部とデータを管理する３つの状態フラグ（有効指示フラグ、変更済指示フラグ、共有状態指示フラグ）を有し、 
　共有メモリからデータが読み出された時には有効指示フラグを１にセットし、 
　共有状態において自プロセッサがキャッシュに書き込みを行ったときには他のキャッシュメモリに対して無効化要求を行い、 
　無効化要求を受けたときはキャッシュメモリの有効指示フラグを０にセットする、 
　データの整合性を維持する手段 
 が記載されている。 
　また、引用例２には、 
　通信障害に対処する手法として、共有通知信号を送出したキャッシュメモリにおいて、応答信号を監視し、応答信号がアサートされない場合は自キャッシュメモリの有効指示フラグを０にクリアする手法が記載されている。 
　
 ３．対比・判断
 
　本願の請求項１に係る発明（以下、前者という）と引用例１に記載された発明（以下、後者という）とを比較すると、
　前者の「ホストコンピュータ」「共有ファイル」「バッファ領域とバッファ制御テーブルとを含むバッファシステム」「データ」は、それぞれ、後者の「処理装置」「共用ファイル」「レコード常駐バッファ」「レコード」に相当する。
　また、後者の「レコード入出力サービスプログラム」はデータ（レコード）の入出力等のアクセス制御を行うものであり、データの入出力先はＯＳを介したアプリケーションであることは技術常識であるから、「データ（レコード）の入出力等のアクセス制御を行うレコード入出力サービスプログラム」は、前者の「ＯＳを介してアプリケーションから前記バッファ領域内に更新データを受け取るデータ受取手段」に相当する。 
　更に、後者の「更新レコードを共用ファイルに書き出す手段」は、前者の「バッファ領域内の更新データを前記共有ファイルに書き込むファイル書込手段」に相当する。
　
　してみると、両者は次の点で一致している。
　
　複数のホストコンピュータ間で共有ファイルとして使用される外部記憶装置を有するシステムにおいて、 
 バッファ領域とバッファ制御テーブルとを含むバッファシステムと、
ＯＳを介してアプリケーションから前記バッファ領域内に更新データを受け取るデータ受取手段と、
　更新データを前記共有ファイルに書き込むファイル書込手段、
を有すると共に、バッファに格納したデータと共有ファイルのデータの同一性を確保するために、他のホストコンピュータにおいてデータの更新を行った時に、データの更新を通知されたホストコンピュータは自バッファに格納されているデータを使用不能とする複数ホストコンピュータ間における入出力バッファシステム 
　
　一方、両者は以下の点で相違している。
　
相違点
（１）データの更新を通知及び通知されたデータを使用不能とする手法として、後者では、データの更新を行うホストコンピュータは更新したレコード番号を共用ファイル用更新レコード登録簿に書き込み、バッファに格納されたデータを使用するホストコンピュータは共用ファイル用更新レコード登録簿を読み出し、自己の共用ファイル用更新レコード登録簿と比較し、更新されたレコードを削除することによりデータの無効化を図るものであるのに対し、前者では、データを更新したホストコンピュータは他のホストコンピュータにバッファ領域無効要求をホスト間通信手段で通知し、該通知を受信したホストコンピュータはバッファ領域を無効化するものである点、
　
（２）バッファ内のデータの管理手法が、後者では更新レコード登録簿（Ｒ１レコード）によって有効、無効とするものであるのに対し、前者では、バッファ存在フラグがオンでデータは有効、オフで無効とするものである点、
　
（３）前者では、バッファ領域無効要求の結果が成功通知であったときに、更新データを共有ファイルに書き込むものであるのに対し、後者はそのような手順を取っていない点
　
４．相違点についての検討
相違点（１）について
　引用例１の実施例では、更新レコードを他のプロセッサに知らせる手段として、更新レコード登録簿をプロセス側と共用ファイル側の相方に保有し、比較する手法をとっているが、２．（Ｅ）に引用したように、「本発明は、更新レコードを他のプロセサに知らせる手段を有すればよく」と記載され、通知の手法はこの実施例にとらわれることないことが示唆されている。原審において拒絶の理由に引用した特開平８−６８３８号公報のものは、リモートファイルのデータを更新したときに他の計算機の保持するコピーを破棄するようにネットワークを介して通知しているし、また、引用例２ではデータの更新を行ったキャッシュから他のキャッシュに無効化通知を行い、受信したキャッシュではデータの無効化を図っており、当該分野においてデータの更新通知を通信手段で行うことは慣用的手法にすぎないから、データの整合性を図るために、共用ファイルの更新レコード登録簿を介して通知する代わりにホスト間通信手段で通知するようにすることは容易に為し得ることである。
　
　なお、請求人は、平成１７年１月１８日付意見書において、
「引例２は、上述の通り、他のＣＰＵのリードアドレスを監視し、そのリードアドレスに対応するデータを既に自らのキャッシュメモリに保持している場合、共有通知信号を発して他のＣＰＵからの返答を待ち、返答があれば共有状態に、なければ自らのキャッシュメモリの当該データを無効にするものであって、データを保持しようとする側（＝データの使用側）が主体的に他のキャッシュメモリの無効化を指示することはありません。」
と主張しているが、引用例２のものは、共有通知信号に対する返答がないときにデータの無効化を図るだけでなく、２．（Ｇ）の引用箇所に記載されているように、データを保持する側から無効化要求をする場合もあるから、前述の請求人の主張は失当である。
　
相違点（２）について
　引用例２のものでは、キャッシュのデータの無効化は、有効指示フラグを「１」から「０」にセットすることにより為されており、フラグでデータの有効、無効の実現することは常套手段にすぎない。従って、バッファ内のデータの有効性を判断する手法として、後者のような更新レコード登録簿の比較によってデータの有効、無効を判断する代わりにバッファ存在フラグを用いるようにすることは格別のことではない。
　
相違点（３）について
　引用例２には、通信障害などにより共有通知信号が正しく通知されないときに対処する技術が示されており、それによれば、共有通知信号を送出したキャッシュメモリにおいて、応答信号を監視し、応答信号がアサートされない場合は自キャッシュメモリの有効指示フラグを０にクリアしている。このように、通知信号に対して応答を確認して次の処理に進むことは慣用的に行われることであるから、この相違点を格別のものということはできない。
　
５．むすび
　したがって、請求項１に係る発明は、引用例１、２に記載された発明及び当該分野の技術常識に基いて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。