【事件の表示】
　平成１０年特許願第　４５２６８号「ファイルアクセスシステムおよび記録媒体」拒絶査定に対する審判事件［平成１０年１１月１３日出願公開、特開平１０−３０１８５６］について、次のとおり審決する。
【結　論】
　
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯　
　本願は、平成１０年２月２６日（優先権主張平成９年２月２８日）の出願であって、平成１４年３月６日付で拒絶の理由が通知され、平成１４年５月２０日付で手続補正（以下、手続補正１という。）がなされたものの、平成１４年６月２４日付けで拒絶の査定がなされた。　
　その後、平成１４年７月２５日に拒絶査定不服審判請求がなされ、平成１４年８月２６日付で手続補正（以下、手続補正２という。）がなされたものである。　
　
２．手続補正２についての補正却下の決定　
　
［補正却下の決定の結論］　
　平成１４年８月２６日付の手続補正を却下する。　
　
［理由］
（ア）本件手続補正　
　上記手続補正２による補正事項は、　
「【特許請求の範囲】　
　【請求項１】　
　オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたリード命令に対して、実際のファイル内の指定されたデータをリード命令の発行元に返す、ファイルアクセスシステムにおいて、　
　ＯＳからのリードイベントを受信する手段と、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化する手段と、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段と　
を備えることを特徴とするファイルアクセスシステム。　
　【請求項２】　
　オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたライト命令に対して、実際のファイル内に指定されたデータを格納するファイルアクセスシステムおいて、　
　ＯＳからのライトイベントを受信する手段と、　
　前記ライトイベントの受信に基づき、該ライトイベントによって特定される処理対象のデータを暗号化する手段と、　
　前記暗号化された処理対象のデータを、ファイルに格納する手段と　
を備えることを特徴とするファイルアクセスシステム。
　【請求項３】　
　前記格納する手段は、暗号化されているファイルのうち、ライト命令の処理対象ファイルの少なくとも一部のデータを含み、かつ、暗号化の単位の長さのデータを読み出して復号化し、ライト命令で指定されたデータを該復号化したデータに上書きし、暗号化して、処理対象のファイルのデータ領域に格納することを特徴とする請求項２記載のファイルアクセスシステム。　
　【請求項４】　
　請求項１のファイルアクセスシステムにおいて、　
　リード命令の処理対象ファイルが暗号化対象か判定し、暗号化対象である場合にはリード命令の処理対象のデータを復号化して、リード命令の発行元に返し、暗号化対象でない場合には復号化処理を行わないことを特徴とするファイルアクセスシステム。　
　【請求項５】　
　請求項２のファイルアクセスシステムにおいて、　
　ライト命令の処理対象ファイルが暗号化対象か判定し、暗号化対象である場合にはライト命令の処理対象のデータを暗号化し、ファイルに格納し、暗号化対象でない場合には、暗号化処理を行わないことを特徴とするファイルアクセスシステム。　
　【請求項６】　
　請求項４あるいは請求項５のファイルアクセスシステムおよびドライバおよびハードウェアにおいて、　
　リードあるいはライト命令の処理対象ファイルが暗号化対象かの判定を、ファイル名またはフォルダ名の条件により、行うことを特徴とするファイルアクセスシステム。
　【請求項７】　
　請求項４あるいは請求項５のファイルアクセスシステムにおいて、　
　リードあるいはライト命令の処理対象ファイルが暗号化対象かの判定を、設定されるユーザ毎の権限情報に基づいて行う手段を備えたことを特徴とするファイルアクセスシステム。　
　【請求項８】　
　請求項４あるいは請求項５のファイルアクセスシステムにおいて、　
　リードあるいはライト命令の処理対象ファイルが暗号化対象かの判定を、ファイル属性にもとづいて行うことを特徴とするファイルアクセスシステム。　
　【請求項９】　
　コンピュータに、　
　ＯＳからのリードイベントを受信するステップと、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化するステップと、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返すステップとを動作させることを特徴とするファイルアクセスプログラムを記録したコンピュータ読取可能な記録媒体。
　【請求項１０】　
　コンピュータに、　
　ＯＳからのライトイベントを受信するステップと、　
　前記ライトイベントの受信に基づき、該ライトイベントによって特定される処理対象のデータを暗号化するステップと、　
　前記暗号化された処理対象のデータを、ファイルに格納するステップと、
を動作させることを特徴とするファイルアクセスプログラムを記録したコンピュータ読取可能な記録媒体。　
　【請求項１１】　
　前記ファイルから読み出した暗号化されていたデータを復号化して同一サイズのデータにし、あるいは暗号化されていないデータを暗号化して同一サイズのデータにしてファイルに書き込むことを特徴とする請求項１または２記載のファイルアクセスシステム。　
　【請求項１２】　
　前記リードイベントは、イベントのフックを要求したことによってＯＳから通知されることを特徴とする請求項１記載のファイルアクセスシステム。
　【請求項１３】　
　前記ライトイベントは、イベントのフックを要求したことによってＯＳから通知されることを特徴とする請求項２記載のファイルアクセスシステム。」 を、　
「【特許請求の範囲】　
　【請求項１】　
　オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたリード命令に対して、実際のファイル内の指定されたデータをリード命令の発行元に返す、ファイルアクセスシステムにおいて、　
　ファイルシステムからのリードイベントを受信する手段と、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化する手段と、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段と　
を備えることを特徴とするファイルアクセスシステム。　
　【請求項２】　
　オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたライト命令に対して、実際のファイル内に指定されたデータを格納するファイルアクセスシステムおいて、　
　ファイルシステムからのライトイベントを受信する手段と、　
　前記ライトイベントの受信に基づき、該ライトイベントによって特定される処理対象のデータを暗号化する手段と、　
　前記暗号化された処理対象のデータを、ファイルに格納する手段と　
を備えることを特徴とするファイルアクセスシステム。　
　【請求項３】　
　前記格納する手段は、暗号化されているファイルのうち、ライト命令の処理対象ファイルの少なくとも一部のデータを含み、かつ、暗号化の単位の長さのデータを読み出して復号化し、ライト命令で指定されたデータを該復号化したデータに上書きし、暗号化して、処理対象のファイルのデータ領域に格納することを特徴とする請求項２記載のファイルアクセスシステム。　
　【請求項４】　
　請求項１のファイルアクセスシステムにおいて、　
　リード命令の処理対象ファイルが暗号化対象か判定し、暗号化対象である場合にはリード命令の処理対象のデータを復号化して、リード命令の発行元に返し、暗号化対象でない場合には復号化処理を行わないことを特徴とするファイルアクセスシステム。　
　【請求項５】　
　請求項２のファイルアクセスシステムにおいて、
　ライト命令の処理対象ファイルが暗号化対象か判定し、暗号化対象である場合にはライト命令の処理対象のデータを暗号化し、ファイルに格納し、暗号化対象でない場合には、暗号化処理を行わないことを特徴とするファイルアクセスシステム。　
　【請求項６】　
　請求項４あるいは請求項５のファイルアクセスシステムおよびドライバおよびハードウェアにおいて、　
　リードあるいはライト命令の処理対象ファイルが暗号化対象かの判定を、ファイル名またはフォルダ名の条件により、行うことを特徴とするファイルアクセスシステム。　
　【請求項７】　
　請求項４あるいは請求項５のファイルアクセスシステムにおいて、　
　リードあるいはライト命令の処理対象ファイルが暗号化対象かの判定を、設定されるユーザ毎の権限情報に基づいて行う手段を備えたことを特徴とするファイルアクセスシステム。　
　【請求項８】　
　請求項４あるいは請求項５のファイルアクセスシステムにおいて、　
　リードあるいはライト命令の処理対象ファイルが暗号化対象かの判定を、ファイル属性にもとづいて行うことを特徴とするファイルアクセスシステム。　
　【請求項９】　
　コンピュータに、　
　ファイルシステムからのリードイベントを受信するステップと、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化するステップと、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返すステップと　
を動作させることを特徴とするファイルアクセスプログラムを記録したコンピュータ読取可能な記録媒体。　
　【請求項１０】　
　コンピュータに、　
　ファイルシステムからのライトイベントを受信するステップと、　
　前記ライトイベントの受信に基づき、該ライトイベントによって特定される処理対象のデータを暗号化するステップと、　
　前記暗号化された処理対象のデータを、ファイルに格納するステップと　
を動作させることを特徴とするファイルアクセスプログラムを記録したコンピュータ読取可能な記録媒体。　
　【請求項１１】　
　前記ファイルから読み出した暗号化されていたデータを復号化して同一サイズのデータにし、あるいは暗号化されていないデータを暗号化して同一サイズのデータにしてファイルに書き込むことを特徴とする請求項１または２記載のファイルアクセスシステム。　
　【請求項１２】　
　前記リードイベントは、イベントのフックを要求したことによって通知されることを特徴とする請求項１記載のファイルアクセスシステム。　
　【請求項１３】　
　前記ライトイベントは、イベントのフックを要求したことによって通知されることを特徴とする請求項２記載のファイルアクセスシステム。」とするものである。　
　
（イ）手続補正についての判断　
　上記手続補正２により、請求項１、２、９、及び１０に記載した発明の「ＯＳ」が「ファイルシステム」に補正されている。　
　一方、本願の発明の詳細な説明の欄には、ＯＳに関するものとして、　
「【００１８】　
　図２は、本発明の初期処理フローチャートを示す。　
　図２において、Ｓ１は、ＯＳ（オペレーティングシステム）がドライバ確認コマンドを送信する。　
【００１９】　
　Ｓ２は、Ｓ１で送信されたドライバ確認コマンドを受信したドライバ（＃１）４が処理処理ＯＫか判別する。ＯＫのときはＯＫ応答をＯＳに返してＳ４でＯＳにドライバ（＃１）として登録する。一方、ＮＧの場合には、ＮＧ応答をＯＳに返してＳ３でエラー処理（ドライバ（＃１）がエラーとして登録などの処理）する。　
【００２０】　
　Ｓ５は、Ｓ４でドライバ（＃１）としてＯＳに登録されたので、ＯＳが初期処理の指示をドライバ（＃１）に通知する。　
　Ｓ６は、Ｓ５の初期処理の通知に対応して、ドライバ（＃１）がファイルシステムのイベントをフックする要求を発行する。具体的には、フック時にコールされるプログラムのアドレス（例えば“ＦＳＨｏｏｋ　（）；”など）をＯＳに指定する。　
【００２１】　
　Ｓ７は、Ｓ６の要求に対応して、ＯＳがフックアドレスなどを登録した後、その応答を返す。これは、例えば後述する図８のマネージャテーブルにドライバ（＃１）に対応づけフックアドレスＦＳＨｏｏｋ（）；を登録する。
【００２２】　
　Ｓ８は、Ｓ７に応答を受信したドライバ（＃１）がＳ６の要求についてＯＫか判別する。ＹＥＳの場合には、初期処理を完了したので終了する。ＮＯの場合には、要求失敗と判断し、再試行あるいはエラーとして中止などする。　
【００２３】　
　以上によって、ドライバ４の初期処理が完了し、動作状態に設定されたこととなる。」、及び、　
「【００３０】　
　図４のフローチャートに示す順序に従い、図１のオープン処理を詳細に説明する。　
　図４は、本発明のオープン処理フローチャートを示す。　
【００３１】　
　図４において、Ｓ２１は、アプリケーション１がオープン関数を発行する。　
　Ｓ２２は、ファイルシステム３がオープン処理を行う。　
　Ｓ２３は、ドライバ（＃１）４が図示の下記のオープンイベントをＯＳより受信する（これは、ドライバの登録時に、ＯＳに通知してもらうイベント、通知時にコールされる暗号化／復号化プログラムのアドレスを登録することで実現されている）。　
【００３２】　
　　・ファイル名（パス名を含む）：　
　　・ファイル属性：　
　　・ファイルハンドル：　
　　・オープン関数のパラメタ：　
　　・ファイルシステムへの復帰アドレス：　
　　・その他　
　Ｓ２４は、フォルダが暗号化／復号化対象かのチェックがＯＫか判別する。フォルダ名はパス名（ファイル名）より抽出する。ＹＥＳの場合（対象のファイルが存在するなどの場合）には、Ｓ２７に進む。ＮＯの場合には、暗号化／復号化対象外ファイルとしてＳ２５で復帰アドレスへ復帰し、オープン処理に戻る。　
【００３３】　
　Ｓ２７は、ファイル属性から処理しないファイルを振り分ける。これは、図示の下記のファイル属性から処理する必要のないファイルを除外する。　
　　・システムファイル：　
　　・隠しファイル：　
　　・ドライバファイル：　
　　・その他
　ＹＥＳの場合には、暗号化／復号化の対象外のファイルと判明したので、Ｓ２８で属性テーブルにファイルハンドルを保存し、Ｓ２９に進む。一方、Ｓ２７のＮＯの場合には、Ｓ２９に進む。　
【００３４】　
　Ｓ２９は、復帰アドレスへ復帰する。　
　Ｓ３０は、オープン処理を完了する。　
　Ｓ３１は、オープン関数に復帰する。　
【００３５】　
　以上の手順によって、アプリケーション１がオープン関数を発行し、ファイルのオープン処理を完了したこととなる。そして、後述する図５のリード処理あるいは図６のライト処理に進む。　
【００３６】　
　図５のフローチャートに示す順序に従い、図１のリード処理を詳細に説明する。　
　図５は、本発明のリード処理フローチャートを示す。　
【００３７】　
　図５において、Ｓ４１は、アプリケーション１がリード関数を発行する。
　Ｓ４２は、ファイルシステム３がリード処理を行う。　
　Ｓ４３は、ドライバ（＃１）４が図示の下記のリードイベントを受信する。　
【００３８】　
　　・ファイル名（パス名を含む）：　
　　・ファイルハンドル：　
　　・リードポイント：　
　　・リードバッファ：　
　　・リードサイズ：　
　　・ファイルシステムへの復帰アドレス：　
　　・その他　
　Ｓ４４は、フォルダが暗号化／復号化対象かチェックがＯＫか判別する。ＹＥＳの場合（暗号化／復号化対象の場合）には、Ｓ４６に進む。ＮＯの場合には、通常の処理としてＳ４５で復帰アドレス（ＯＳ）へ復帰し、通常のリード処理を行う。　
【００３９】　
　Ｓ４６は、オープン処理時に更新した属性テーブルに当該要求のファイルハンドルがあるか否かをチェックする。これは、ファイルハンドルから暗号化／復号化の対象外のファイルか判別する。ＮＯの場合には、Ｓ４８に進む。ＹＥＳの場合には、Ｓ４７で復帰アドレスへ復帰し、通常のリード処理をする。　
【００４０】　
　Ｓ４８は、リード処理を呼び出す。これは、外部記憶装置１０である例えばＨＤＤ（ハードディスク装置）のドライバを呼び出し、バウンダリ処理を行ってデータをリードする。　
【００４１】　
　Ｓ４９は、Ｓ４８で呼び出された例えばＨＤＤドライバがＨＤＤからバウンダリを考慮してデータを読み出す。　
　Ｓ５０は、Ｓ４９で読み出したデータについて、同一サイズで復号化処理を行う。ここで、８バイト単位での暗号化処理、および端数処理を行う。これにより、８バイト単位に復号化処理を行い、読み出したデータの８バイトと、復号化した後のデータが８バイトとなるようにしており、復号化前と復号化後のデータが共に８バイトで同一とし、データの長さから両者が区別つかないようにし、セキュリティレベルを高めている。　
【００４２】　
　Ｓ５１は、リードサイズ分をリードバッファに設定する。　
　Ｓ５２は、復帰アドレスへ復帰する。　
　Ｓ５３は、リード処理を完了する。　
【００４３】　
　Ｓ５４は、リード関数に復帰する。　
　以上によって、アプリケーション１がリード関数を発行すると、発行されたリード関数で指定されたデータがここでは、８バイト単位にファイルから読みだされて暗号化されているときは復号化し、暗号化されていないときは図示しないがそのままでリードバッファに設定することをリード分のデータ分だけ繰り返し、アプリケーション１はリードバッファから読み出して一連のリード処理を行うことが可能となる。」　
と記載されているのみで、ＯＳとファイルシステムの関係が明記されておらず、してみれば、「ＯＳ」を「ファイルシステム」とする補正が、特許請求の範囲の減縮を目的とするものとは認められない。　
　又、上記補正は、請求項の削除、誤記の訂正のいずれを目的とするものとは認められず、かつ、拒絶の理由として上記の記載を明りょうでないとする指摘はなく、上記補正は明りょうでない記載の釈明を目的とするものとは認められない。　
　以上のとおり、上記補正は、特許法第１７条の２第４項に規定する要件を満たしていない。　
　
　ここで、仮に、ファイルシステムがＯＳの一部であって、それをもって請求項１、２、９、及び１０に記載した発明の「ＯＳ」を「ファイルシステム」とする上記補正が特許請求の範囲の減縮を目的とするものだとする。　
（１）補正後の本願発明　
　その場合、上記補正により、特許請求の範囲の請求項１は、　
「【請求項１】　
　オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたリード命令に対して、実際のファイル内の指定されたデータをリード命令の発行元に返す、ファイルアクセスシステムにおいて、　
　ファイルシステムからのリードイベントを受信する手段と、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化する手段と、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段と　
を備えることを特徴とするファイルアクセスシステム。」　
と補正された。　
　そこで、上記補正後の上記請求項１に記載された発明（以下、本願補正発明という。）が特許出願の際独立して特許を受けることができるものかどうか（特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するか）について以下に検討する。　
（２）引用例　
［引用例１］原査定の拒絶の理由に引用されたMatt Blaze, A Cryptographic File System for Unix, Proceedings of the 1st ACM Conf. on Computer and Comm. Security, ACM, 1993, p.9-16 （以下、引用例１という。）には、図面とともに、　
Ａ．「3.File Encryption　
CFS uses DES to encrypt file data.・・・In the simplest DES mode，ECB (electronic code book), each 8 byte block of a file is independently encrypted with the given key.・・・For example,a write to the middle of a file could require reading the data that preceded it and reenciphering and rewriting the data that follow it. Unix file system semantics, however, require approximately uniform access time for random blocks of file.・・・File block boundaries are preserved as long as the cipher block size is a multiple of the block size, as it is in most system.  Applications that optimize their file I/O to fall on file system block boundaries (including programs using the Unix stdio library) therefore maintain their expected performance characteristics without modification.・・・However, because CFS sits above the file system used for actual storage and uses system calls its I/O, it has no direct access to inode fields and cannot therefore add new file attributes.・・・」（・・・は引用箇所の省略を意味し、以下、同様とする。）　
（訳：３．ファイル暗号化　
ＣＦＳはファイルデータを暗号化するためにＤＥＳを使う。・・・最も単純なＤＥＳモードであるＥＣＢ（電子コードブック）で、ファイルのそれぞれの８バイトのブロックが所定のキーで独立して暗号化される。 ・・・例えば、ファイルの中央への書き込みがそれより前のデータを読むことと、後に続くデータを復号化することを必要とする。しかしながら、ＵＮＩＸファイルシステムは、ファイルの任意のブロックのほぼ同一のアクセス時間を要求される。・・・暗号化ブロックの大きさがそのブロックの倍数である限り、ファイルブロックの境界は維持される。したがって、（ＵＮＩＸ ｓｔｄｉｏライブラリを使っているプログラムを含めて）ファイルシステムブロックの境界に当てるためにファイルＩ／Ｏを最適化するアプリケーションは、修正することなく期待する性能を維持する。・・・しかしながら、ＣＦＳがシステムが実記憶装置を使用するためのファイルシステム上にあり、そのＩ／Ｏシステムコールを用いるので、ｉｎｏｄｅフィールドに直接アクセスすることはなく、新しいファイル属性を加えることはできない。・・・）（１３頁左欄３３行〜１４頁左欄１５行）、及び、　
Ｂ．「4.Prototype Implementation・・・4.1. Architecture　
The CFS prototype is implemented entirely at user level, communicating with the Unix kernel via the NFS interface.  Each client machine runs a special NFS server, cfsd (CFS Daemon), on its localhost interface, that interprets CFS file system requests.  At boot time, the system invokes cfsd snd issues an NFS mount of its localhost interface on the CFS directory (/crypt) to start CFS. ・・・　
The NFS protocol is designed for remote file servers, and so assumes that the file system is very loosely coupled to the client ・・・. The client kernel communicates with the file system through 17 remote procedure calls (RPCs) that implement various file system-related primitives (read, write, etc.). ・・・All communication is initiated by the client, and the server can simply process each RPC ・・・　
cfsd is implemented as an RPC server for an extended version of the NFS protocol.・・・Initially, the root of the CFS file system appears as an empty directory. The cattach command sends an RPC to cfsd with arguments containing the full path name of a directory (mounted elsewhere), the name of the attach point, and the key. If the key is correct・・・, cfsd computes the cryptographic mask (described in the previous section) and creates an entry in its root directory under the specified attach point name. The attach point entry appears as a directory owned by the user who issued the attach request with a protection mode of 700 to prevent others from seeing its contents.・・・ File system operations in the attached directory are sent as  regular NFS RPCs to cfsd via the standard NFS client interface.　
For each encrypted file accessed through an attach point, cfsd generates a unique file handle that is used by the client NFS interface to refer to the file. For each attach point, the CFS daemon maintains a table of handles and their corresponding underlying encrypted names. When a read or write operation occurs, the handle is used as an index into this table to find the underlying file name. cfsd uses regular Unix system calls to read and write the file contents, which are encrypted before writing and decrypted after reading, as appropriate. To avoid repeated open and close calls, ・・・ Directory and symbolic link opereations, such as readdir, readlink and lookup are similarly translated into appropriate system calls and encrypted and decrypted as needed.　
・・・ Figure 1 shows the architecture of the interfaces between an application program and the ordinary Sun vnode-based Unix file system[2]. Each arrow between boxes represents data crossing a kernel, hardware, or network boundary, the diagram shows that data written from an application are first copied to the kernel and then to the (local or remote) file system. Figure2 shows the architecture of the user-level CFS prototype. Data are copied several extra times; from the application, to the kernel, to the CFS daemon, back to the kernel, and finally to the underlying file system. Since CFS users user-level system calls to communicate with the underlying file system, each file is cached twice, once by CFS in clear form and once by the underlying system in encrypted form.・・・」　
（訳：４．プロトタイプの実装・・・４．１．アーキテクチャ　
 ＣＦＳプロトタイプは、ＮＦＳインタフェースによってＵＮＩＸカーネルと通信することにより、ユーザーレベルにおいて全て実装される。 それぞれのクライアントマシンが、ＣＦＳファイルシステムの要求を解釈するローカルホストインタフェースの上で、ＮＦＳサーバ、ｃｆｓｄ（ＣＦＳデーモン）を動かす。ブート時に、システムはＣＦＳを開始するために、ｃｆｓｄを起動し、ＣＦＳディレクトリ（／ｃｒｙｐｔ）にローカルホストインタフェースのＮＦＳマウントを実行する。・・・　
ＮＦＳプロトコルはリモートファイルサーバとして設計されており、ファイルシステムがゆるやかにクライアントに結びつけられると想定している・・・。 読み出しあるいは書き込みなどの様々なファイルシステムに関係する基本機能を実装する１７のリモートプロシジャコール（ＲＰＣ）を通して、クライアントカーネルはファイルシステムと通信する。・・・すべての通信はクライアントによって開始され、サーバは単純にそれぞれのＲＰＣを処理できる。・・・　
ｃｆｓｄがＮＦＳプロトコルの拡張されたバージョンのために、ｃｆｓｄはＲＰＣサーバとして実装される。・・・初めに、ＣＦＳファイルシステムのルートは、空のディレクトリとして現われる。ｃａｔｔａｃｈコマンドは、（他のところにマウントされた）ディレクトリのフルパス名、「接続ポイント」名と、キーを含んで、ＲＰＣをｃｆｓｄに送る。・・・もしキーが正しければ、ｃｆｓｄは（前のセクションで述べた）暗号化マスクを計算して、指定された接続ポイント名の下にルートディレクトリの中にエントリを作成する。接続ポイントエントリは、その内容を他人が見ることを妨げるために、７００の保護モードを持って、接続要求を発行するユーザーにより所有されるディレクトリとして現われる。・・・付加されたディレクトリの中のファイルシステム操作は、通常のＮＦＳ　ＲＰＣとして、標準ＮＦＳクライアントインタフェースによって、ｃｆｓｄに送られる。　
接続ポイントを通じてアクセスされたそれぞれの暗号化されたファイルに、ｃｆｓｄはそのファイルを参照するためにクライアントＮＦＳインタフェースによって使用される固有のファイルハンドル名を生成する。それぞれの接続ポイントに、ＣＦＳデーモンはハンドル名のテーブルと対応するもとの暗号化された名前を保持する。読み取りあるいは書き込み操作が発生すると、ハンドル名は、もとのファイル名を見付けるためのテーブルのインデックスとして用いられる。ｃｆｓｄは、書き込み前に暗号化され読み出し後に復号化されるファイルの内容の読み出し又は書き込みのために、通常のＵＮＩＸシステムコールを使用する。オープンとクローズを繰り返すことを避けるために、・・・。ｒｅａｄｄｉｒ、ｒｅａｄｌｉｎｋ、ｌｏｏｋｕｐのようなディレクトリとシンボリックリンク操作は、同様に適切なシステムコールに変換され、必要な時に暗号化又は復号化される。　
・・・図１は、アプリケーションプログラムと通常のＳＵＮ「ｖｎｏｄｅ−ｂａｓｅｄ」ＵＮＩＸファイルシステム［２］の間のインタフェースのアーキテクチャを示す。ボックスの間のそれぞれの矢印は、カーネル、ハードウェア、あるいはネットワークの境界を通るデータを示しており、アプリケーションから書き込まれるデータが初めにカーネルへ転記され、次に（ローカルあるいはリモートの）ファイルシステムへ転記されることを示している。図２は、ユーザレベルのＣＦＳプロトタイプのアーキテクチャを示している。データは、アプリケーションからカーネルへ、そしてＣＦＳデーモンへ、さらにカーネルへ戻され、最終的に基礎となるファイルシステムへ転記される。ＣＦＳは、基礎となるファイルシステムと通信するためのユーザーレベルのシステムコールを使用するので、それぞれのファイルは、暗号化されていない形で２度あるいは１度ＣＦＳによってキャッシュされる。かつてＣＦＳによってそして暗号化されたフォームでかつて基礎をなしているシステムによってキャッシュされ、暗号化された形で基礎となるシステムによって１度キャッシュされる。・・・）（１４頁左欄１６行〜右欄３４行）との記載されている。　
Ｃ．さらに、上記Ｂ．の「オープン」は、ファイルの読み込みあるいは書き込みのために事前に行われるものであることは周知の技術である。　
Ｄ．上記Ｂ．及び図２には、アプリケーション、カーネル、ＣＦＳデーモン、カーネル、ファイルシステムの順に、あるいは逆にファイルシステム、カーネル、ＣＦＳデーモン、カーネル、アプリケーションの順に、データがシステムコールを用いて転記されていくことが記載されており、したがって、ファイルの読み込みの際にも、ファイルを読み込むための所定の要求をカーネルを介してＣＦＳデーモンが受け取るものと認められる。　
　上記Ａ．〜Ｄ．を勘案すれば、引用例１には、　
　オープンされたファイルのデータに対してアプリケーションから発行されたファイルを読み込むためのシステムコールに対して、ファイルのデータをアプリケーションに返すファイルシステムにおいて、　
　アプリケーションからのシステムコールによるファイルを読み込むための要求を、カーネルを介して受け取り、処理対象のデータを復号化し、復号化された処理対象のデータを、カーネルを介してアプリケーションに返すＣＦＳデーモン、を備えたファイルシステム（以下、引用発明という。）　
が開示されていると認められる。　
［引用例２］同じく、原査定の拒絶の理由に引用された特開平７−１４０８９６号公報（平成７年６月２日出願公開、以下、引用例２という。）には、図面とともに、　
「【００５８】図７は、端末２００において、ユーザがアプリケーションプログラム３０８を使用して既に記憶装置２１０に書き込まれている暗号文ファイルを読み取る場合の処理手順を示す流れ図である。　
【００５９】本処理は、ユーザが自己の個人用記憶媒体２２０を読み取り装置２３０に挿入し、アプリケーションプログラム３０８によって、記憶装置２１０に書き込まれている暗号文ファイルを読み取る操作をすることによって開始される（ステップ７００）。　
【００６０】端末２００は、まず、・・・。そして、本来、アプリケーションプログラム３０８によって指定されたメモリ上のデータ領域に読み込まれるべき暗号文ファイルを、記憶装置２１０から、ディスクバッファを介して、新たに確保したデータ領域に読み取る（ステップ７０３）。・・・　
【００６１】次に、読み込まれた暗号文ファイルをｎ個の暗号文ブロックに分割する（ステップ７０４）。上述したように、本実施例で使用する暗号アルゴリズムは平文ブロックと暗号文ブロックとが同じ大きさになるような方式であるから、この暗号文ブロックのデータサイズは、図１および図５で説明したｎ個に分割した平文ブロックのデータサイズと同じということになる。　
【００６２】そして、個人用記憶媒体２２０よりユーザ鍵を読み取り（ステップ７０５）、そのユーザ鍵で暗号文ブロックをそれぞれ別々に復号する（ステップ７０６）。本処理でも、あらかじめ個人用記憶媒体が挿入された時点で、ユーザ鍵をメモリ上の決められた領域に読み取っておいてもよい。　
・・・　
【００６６】また、全ての平文ブロックをそれぞれ別々に暗号化しているので、各暗号文ブロックの間に相関はない。したがって、既に記憶装置に記憶されている暗号文ファイル、すなわち連結された暗号文ブロックの一部に対し、新たに作成した暗号文ブロックを上書きした場合においても、他の暗号文ブロックが破壊されることはなく、元の平文ファイルに正しく復元することができる。」と記載されている。　
［引用例３］同じく、原査定の拒絶の理由に引用された特開平６−２７４８８０号公報（平成６年、９月３０日出願公開、以下、引用例３という。）には、図面とともに、　
「【００２６】上記実施例の情報記録媒体では、ユーザの選択に従い、各データが暗号化された上で記録される・・・。また、この暗号化／暗号解読プログラムは、デバイスドライバ・ソフトウエアとして記録されており、コンピュータの起動時には自動的に立上がる・・・」と記載されている。　
（３）対比　
　そこで、本願補正発明と引用発明を対比する。　
　まず、本願補正発明の「オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたリード命令」、「実際のファイル内の指定されたデータをリード命令の発行元に返す、」、「該リードイベントによって特定される処理対象のデータを復号化する手段と、」という記載では、リード命令が発行される対象であり、かつリード命令の発行元に返されるファイル内の指定されたデータであって、リードイベントによって特定されて復号化される処理対象のデータが、ファイルの一部だけなのか、少なくとも一部のデータを含むファイル全体も対象として含まれているものなのか若干不明確であるが、一部だけであると仮定すると、引用発明においても、所定のファイルを読み出すためにシステムコールを発行しているのであるから、引用発明の「オープンされたファイルのデータに対してアプリケーションから発行されたファイルを読み込むためのシステムコールに対して、ファイルのデータをアプリケーションに返す」は、本願補正発明の「オープン命令が発行されたファイルのデータに対して発行されたリード命令に対して、実際のファイルのデータをリード命令の発行元に返す」に対応する。　
　又、引用発明の「ファイルを読み込むための要求を、カーネルを介して受け取り、処理対象のデータを復号化し、復号化された処理対象のデータを、カーネルを介してアプリケーションに返すＣＦＳデーモン」は、本願補正発明の「リードイベントを受信する」、「前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化する」、及び「前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段」に対応する。　
　又、本願発明の詳細な説明の欄には、「【０００１】　
【発明の属する技術分野】　
　本発明は、ファイルにアクセスするファイルアクセスシステムおよび記録媒体に関するものである。」とあるだけで、他に「ファイルアクセスシステム」なる語句は用いられておらず、その定義も記載されていないが、本願補正発明の記載を勘案すると、発明の詳細な説明の欄の「ドライバ」が上記ファイルアクセスシステムに対応するものと認められる。　
　したがって、本願補正発明と引用発明は、
　オープン命令が発行されたファイルのデータに対して発行されたリード命令に対して、実際のファイルのデータをリード命令の発行元に返す、システムにおいて、　
　リードイベントを受信する手段と、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化する手段と、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段と　
を備えたシステム　
である点で一致し、以下の点で相違している。　
［相違点１］本願補正発明は、リード命令が発行される対象であり、かつリード命令の発行元に返されるファイル内の指定されたデータであって、リードイベントによって特定されて復号化される処理対象のデータが、ファイルの一部だけであるのに対して、引用発明は、ファイルである点。　
［相違点２］本願補正発明は、リードイベントを受信する手段が受信するリードイベントの発行元が、ファイルシステムであるのに対して、引用発明は、アプリケーションである点。　
（４）相違点についての判断　
［相違点１について］　例えば、引用例２に記載されているように、暗号化されたファイルをリードする、あるいは暗号化してライトする場合に、ファイルをブロックに分割して暗号化あるいは復号化することは周知の技術である。　
　一方、引用例１においても、ブロック単位で独立して暗号化すること、及び、上記ブロックとファイルシステムブロックのサイズを倍数関係にすることでファイルの境界を維持できることが記載されており、したがって、上記周知の技術を参酌して、引用発明において、リード命令が発行される対象であり、リード命令の発行元に返されるファイル内の指定されたデータであって、リードイベントによって特定されて復号化される処理対象のデータを、ファイルの一部だけとするようにすることは、当業者が容易になし得るものである。　
［相違点２について］相違点２は、本願補正発明が、リードイベントを受信し、前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化し、前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段を、ファイルシステムの記憶装置側に近い下位の層に位置するファイルアクセスシステムであるところのドライバが備えているので、上記ドライバがリードイベントをファイルシステムから受信しているのに対して、引用発明が、リードイベントを受信し、前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化し、前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段を、ファイルシステムの同位の層に位置するＣＦＳデーモンによって実現しているから、上記ＣＦＳデーモンがカーネルを介してアプリケーションからリードイベントを受信していることによるものである。　
　しかしながら、例えば、引用例３に記載されているように、暗号化あるいは復号化する手段を記憶装置側に近い下位の層のデバイスドライバに実装することは周知の技術である。　
　したがって、上記周知の技術を参酌して、引用発明において、リードイベントを受信し、前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化し、前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段を、ファイルシステムの下位の層に位置するドライバが備えるようにし、上記ドライバがリードイベントをファイルシステムから受信するようにすること、すなわち、ファイルシステムからのリードイベントを受信するようにすることは、当業者が容易になし得るものである。　
　したがって、本願補正発明は、引用例１、２、３に記載された発明及び周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。　
（５）むすび　
　以上のとおり、仮に、ファイルシステムがＯＳの一部であって、それをもって請求項１、２、９、及び１０に記載した発明の「ＯＳ」を「ファイルシステム」とする上記補正が特許請求の範囲の減縮を目的とするものだとしても、上記補正は、特許法第１７条の２第５項で準用する同第１２６条第４項の規定に違反するものである。　
（エ）むすび　
　以上のとおり、いずれにしても上記手続補正２は、特許法第１７条の２第４項又は第５項に規定する要件を満たしておらず、同第１５９条第１項で準用する同第５３条第１項の規定により却下すべきものである。　
　
３．特許法第２９条第２項について　
（１）本願発明　
　上記手続補正２は、上記のとおり却下されたので、本願の請求項１に係る発明（以下、本願発明という。）は、上記手続補正１により補正された特許請求の範囲請求項１に記載された次のとおりのものと認める。　
「【請求項１】　
　オープン命令が発行されたファイルの少なくとも一部のデータに対して発行されたリード命令に対して、実際のファイル内の指定されたデータをリード命令の発行元に返す、ファイルアクセスシステムにおいて、　
　ＯＳからのリードイベントを受信する手段と、　
　前記リードイベントの受信に基づき、該リードイベントによって特定される処理対象のデータを復号化する手段と、　
　前記復号化された処理対象のデータを、前記リードイベントによって特定されるリード命令の発行元に返す手段と　
を備えることを特徴とするファイルアクセスシステム。」　
（２）引用例　
　原査定の拒絶の理由に引用された引用例、及び、その記載事項は、上記「２．［理由］（イ）（２）引用例」に記載したとおりである。　
（３）対比・判断　
　本願発明は、上記「２．」で検討した本願補正発明から「ファイルシステム」を「ＯＳ」としたものであり、上述したとおり、ファイルシステムがＯＳの一部であって、それをもって請求項１、２、９、及び１０に記載した発明の「ＯＳ」を「ファイルシステム」とする上記補正が特許請求の範囲の減縮を目的とするものだとすれば、本願発明の構成要件を全て含む本願補正発明が、上記「２．［理由］（イ）（４）」に記載したとおり、引用例１、２、３に記載された発明及び周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１、２、３に記載された発明及び周知の技術に基づいて、当業者が容易に発明をすることができたものである。　
　又、本願発明におけるＯＳがファイルシステムを包含しないものだとしても、引用発明のＣＦＳデーモンは、ファイルの読み込みのための要求を、ＯＳであるところのカーネルを介してアプリケーションから受け取り、復号化したデータをカーネルを介してアプリケーションに返すものであるから、いずれにしても、本願発明は、引用例１、２、３に記載された発明及び周知の技術に基づいて、当業者が容易に発明をすることができたものである。　
（４）むすび　
　以上のとおり、本願発明は、引用例１、２、３に記載された発明及び周知の技術に基づき、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。　
　
　よって、結論のとおり審決する。