【事件の表示】
　平成１０年特許願第５０４４７４号「ファイルの設定状態の復元」拒絶査定不服審判事件〔平成１０年　１月　８日国際公開、ＷＯ９８／００７９５、平成１１年１２月１４日国内公表、特表平１１−５１４７６８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１９９７年７月１日（パリ条約に基づく優先権主張外国庁受理１９９６年７月２日、アメリカ合衆国）を国際出願日とする出願であって、原審において平成１５年１月２９日付で拒絶の理由が通知され、これに対して、平成１５年８月４日に意見書及び手続補正書が提出されたものの、平成１６年２月９日付で拒絶査定されたので、平成１６年５月１７日に審判請求がなされ、平成１６年６月１６日付で特許請求の範囲の補正を目的とする手続補正書並びに請求の理由を記載した手続補正書（方式）が提出されたものである。
　
第２．平成１６年６月１６日付提出の手続補正の適否
　
１．手続補正の内容
　平成１６年６月１６日付提出の手続補正は、明細書の特許請求の範囲の変更を目的とするものであって、請求項１乃至１４を、
　「１．ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットヘのトランザクションセマンティクスの追加を、このようなネイティブファイルシステムにコミットおよびロールバック機能性を追加することにより行う、コンピュータ読取り可能媒体上にあるコンピュータプログラムライブラリであって、前記ライブラリが１つ以上のルーチンファミリのセットを有し、このようなルーチンファミリの各々が最低１つのネイティブファイルまたはディレクトリ動作と関連し、且つ、関連ネイティブファイルまたはディレクトリ動作の代わりに呼出されるように構成され、このようなルーチンファミリの各々が、
（ａ）ファミリの関連ネイティブファイルまたはディレクトリ動作の１つと同等な機能結果をコンピュータに提供させて、一方でこのようなネイティブファイルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命令を含む実行ルーチンと、
（ｂ）コンピュータに、関連実行ルーチンの機能結果をコミットさせるコンピュータ命令を含む終了ルーチンと、
（ｃ）コンピュータに、関連実行ルーチンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチンと、
を有することを特徴とするコンピュータプログラムライブラリ。
２．ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットヘのトランザクションセマンティクスの追加を、このようなネイティブファイルシステムにコミットおよびロールバック機能性を追加することにより行う、コンピュータ読取り可能媒体上にあるコンピュータプログラムライブラリであって、前記ライブラリが、
（ａ）さらに多くのルーチンファミリのセットを有し、各ルーチンファミリが実行ルーチン、終了ルーチン、アンドゥルーチンを有し、各ルーチンファミリが最低１つのネイティブファイルまたはディレクトリ動作と関連し、そして、関連ネイティブファイルまたはディレクトリ動作の代わりに呼出されるように構成されており、
（ｂ）ネイティブファイルシステム動作のトランザクションをオープンするためのオープニングルーチンを含むトランザクションマスタと、このようなトランザクションをコミットするためのコミットルーチンと、このようなトランザクションをロールバックするためのロールバックルーチンとを有し、
ここで、
（ｃ）各ファミリの前記実行ルーチンが、コンピュータに、ファミリの内の１つの関連ネイティブファイルまたはディレクトリ動作を実行させ、そしてそれと同等の機能を提供させるコンピュータ命令を含み、
（ｄ）各ファミリの前記終了ルーチンが、コンピュータに、ファミリの内の１つの関連ネイティブファイルまたはディレクトリ動作と同等の機能の１つをコミットさせるコンピュータ命令を含み、
（ｅ）各ファミリの前記アンドゥルーチンが、コンピュータに、ファミリの内の１つの関連ネイティブファイルまたはディレクトリ動作と同等の機能の１つをロールバックさせるコンピュータ命令を含み、
（ｆ）前記コミットルーチンが、コンピュータに、トランザクションログを読取らせるためのコンピュータ命令を含み、
（ｇ）前記ロールバックルーチンが、コンピュータに、前記トランザクションログを読取らせるためのコンピュータ命含を含み、
（ｈ）前記ルーチンファミリのセットの前記実行ルーチンが、コンピュータに、終了およびアンドゥルーチンを同定するようなトランザクション情報を、前記トランザクションログにアペンドさせるコンピュータ命令を総合的に含み、
（ｉ）前記コミットルーチンが、前記トランザクションログ内で同定された終了ルーチンをコンピュータに呼出させるコンピュータ命令を含み、
（ｊ）前記ロールバックルーチンが、前記トランザクションログ内で同定されたアンドゥルーチンをコンピュータに呼出させるコンピュータ命令を含む、
ことを特徴とするコンピュータプログラムライブラリ。
３．前記ファミリのセットが、書込みのためにファイルオープンのネイティブファイル又はディレクトリ動作のためのファミリを１つ有することを特徴とする請求の範囲２に記載のライブラリ。
４．前記ファミリのセットが、アペンドのためにファイルをオープンするネイティブファイルまたはディレクトリ動作のためのファミリを１つ有することを特徴とする請求の範囲２に記載のライブラリ。
５．前記ファミリのセットが、空ファイルを作成するネイティブファイルまたはディレクトリ動作のためのファミリを１つ有することを特徴とする請求あ（「あ」は「の」の誤記と認める。）範囲２に記載のライブラリ。
６．前記ファミリのセットが、ファイルを削除するネイティブファイルまたはディレクトリ動作のためのファミリを１つ有することを特徴とする請求の範囲２に記載のライブラリ。
７．前記ファミリのセットが、ディレクトリを削除、ディレクトリを作成、ディレクトリを名前変更、ファイルを名前変更するネイティブファイルまたはディレクトリ動作の各々にファミリを１つ有することを特徴とする請求の範囲２に記載のライブラリ。
８．ネイティブファイルシステムがＵＮＩＸファイルシステムであり、前記ネイティブファイルおよびディレクトリ動作のセットが、ＵＮＩＸファイルシステムアプリケーションプログラマのインタフェースで使用可能の実質的に全てのファイルシステム動作を有することを特徴とする請求の範囲２に記載のライブラリ。
９．ファイルまたはファイルシステムの状態を修正するネイティブ修正動作を有するネイティブコンピュータファイルシステム内のファイルのセットの状態を記憶するために、トランザクションファイル動作を提供する方法であって、前記方法が、
（ａ）前記修正動作の各セットに実行ルーチン、終了ルーチン、アンドゥルーチンを提供するステップを有し、その際、これらルーチンの各々は、コンピュータシステム上で実行可能な関連修正動作を有し、ここで、実行および終了ルーチンは関連修正動作をコンピュータに作用させるコンピュータ命令を総合的に有し、そして、終了およびアンドゥルーチンは、関連修正動作のロールバックをコンピュータに作用させるコンピュタ命令を総合的に有し、
（ｂ）修正動作を含むトランザクションをオープンするためのトランザクションオープンルーチンと、このようなトランザクションをコミットするためのコミットルーチンと、このようなトランザクションをロールバックするためのロールバックルーチンとを含むトランザクションマスタを提供するステップを有し、
　ここで、前記コミットルーチンは、コンピュータに、終了ルーチンを呼出させるコンピュータ命令を有し、前記ロールバックルーチンは、コンピュータに、アンドゥルーチンを呼出させるコンピュータ命令を有し、
ここで、
（ｃ）前記呼出しのコミットルーチンが全てのオープントランザクションをコミットし、
（ｄ）前記呼出しのロールバックルーチンが全てのオープントランザクションをロールバックする、ことを特徴とする方法。
１０．前記ネイティブファイルシステムがＵＮＩＸファイルシステムであることを特徴とする請求の範囲９に記載のライブラリ。
１１．ルーチンが提供された前記修正動作のセットが、実質的にファイルまたはファイルシステムの状態を修正することが可能な全てのネイティブファイルシステム動作から成ることを特徴とする請求の範囲９に記載の方法。
１２．前記ファイルのセット内の前記ファイルが２つ以上のホストコンピュータに分散されていることを特徴とする請求の範囲９に記載の方法。
１３．ディレクトリ除去のネイティブ修正動作のためにディレクトリ削除ルーチンファミリを提供するステップをさらに有し、
（ａ）前記ディレクトリ削除ファミリの実行ルーチンが、コパスの名前を生成し、前記ディレクトリを前記コパスの名前に名前変更するステップをコンピュータに実行させるコンピュータ命令を有し、
（ｂ）前記ディレクトリ削除ファミリの終了ルーチンが、コパス名を削除するステップをコンピュータに実行させるコンピュータ命令を有し、
（ｃ）前記ディレクトリ削除ファミリのアンドゥルーチンが、前記コパス名を前記オリジナルディレクトリ名に名前変更するステップをコンピュータに実行させるコンピュータ命令を有する、
ことを特徴とする請求の範囲９に記載の方法。
１４．アップデートのための前記ファイルオープンのネイティブ修正動作のためにアップデートルーチンファミリを提供するステップをさらに有し、
（ａ）前記アップデートファミリの実行ルーチンが、コパスの名前を生成し、前記コパスにファイルとしてコピーするステップをコンピュータに実行させるコンピュータ命令を有し、
（ｂ）前記アップデートファミリの終了ルーチンが、前記コパスを削除するステップをコンピュータに実行させるコンピュータ命令を有し、
（ｃ）前記アップデートファミリのアンドゥルーチンが、前記コパスをオリジナルファイルにコピーし、次に前記コパスを削除するステップをコンピュータに実行させるコンピュータ命令を有する、
ことを特徴とする請求の範囲９に記載の方法。」
から、
　「【請求項１】　ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットヘトランザクションセマンティクスを追加するためのコンピュータプログラムライブラリを記録したコンピュータ読取り可能な記録媒体であって、前記ライブラリが１つ以上のルーチンファミリのセットを有し、このようなルーチンファミリの各々が最低１つのネイティブファイルまたはディレクトリ動作と関連し、そして、最低１つのネイティブファイルまたはディレクトリ動作の代わりに呼出されるように構成され、このようなルーチンファミリの各々が、
（ａ）ファミリの関連ネイティブファイルまたはディレクトリ動作の１つと機能的に同等である結果をコンピュータに提供させて、一方でこのようなネイティブファイルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命令を含む実行ルーチンと、
（ｂ）コンピュータに、関連実行ルーチンの結果をコミットさせるコンピュータ命令を含む終了ルーチンと、
（ｃ）コンピュータに、関連実行ルーチンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチンと、
を有することを特徴とするコンピュータ読取り可能な記録媒体。
　　【請求項２】　ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットヘトランザクションセマンティクスを追加するためのコンピュータプログラムライブラリを記録したコンピュータ読取り可能な記録媒体であって、前記ライブラリが、
（ａ）コンピュータ命令の形の最低１つのルーチンファミリのセットを有し、各ルーチンファミリが実行ルーチン、終了ルーチン、およびアンドゥルーチンを有し、各ルーチンファミリが最低１つのネイティブファイルまたはディレクトリ動作と関連し、そして、最低１つのネイティブファイルまたはディレクトリ動作の代わりに呼出されるように構成されており、
（ｂ）コンピュータ命令の形のトランザクションマスタを有し、該トランザクションマスタは、ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のトランザクションをオープンするためのオープニングルーチン、このようなトランザクションをコミットするためのコミットルーチン、および、このようなトランザクションをロールバックするためのロールバックルーチンとを有し、
ここで、
（ｃ）各ファミリの前記実行ルーチンが、コンピュータに、ファミリの関連ネイティブファイルまたはディレクトリ動作の１つを実行させるコンピュータ命令を含み、
（ｄ）各ファミリの前記終了ルーチンが、コンピュータに、ファミリの関連ネイティブファイルまたはディレクトリ動作の１つをコミットさせるコンピュータ命令を含み、
（ｅ）各ファミリの前記アンドゥルーチンが、コンピュータに、ファミリの関連ネイティブファイルまたはディレクトリ動作の１つをロールバックさせるコンピュータ命令を含み、
（ｆ）前記コミットルーチンが、コンピュータに、トランザクションログを読取らせるためのコンピュータ命令を含み、
（ｇ）前記ロールバックルーチンが、コンピュータに、前記トランザクションログを読取らせるためのコンピュータ命含を含み、
（ｈ）前記ルーチンファミリのセットの前記実行ルーチンが、コンピュータに、トランザクション情報を、前記トランザクションログにアペンドさせるコンピュータ命令を総合的に含み、
（ｉ）前記コミットルーチンが、前記トランザクションログ内で同定された終了ルーチンをコンピュータに呼出させるコンピュータ命令を含み、
（ｊ）前記ロールバックルーチンが、前記トランザクションログ内で同定されたアンドゥルーチンをコンピュータに呼出させるコンピュータ命令を含む、
ことを特徴とするコンピュータ読取り可能な記録媒体。
　　【請求項３】　前記ファミリのセットが、書込みのためにファイルをオープンするネイティブファイル動作のためのファミリを１つ有することを特徴とする請求項２に記載のコンピュータ読取り可能な記録媒体。
　　【請求項４】　前記ファミリのセットが、ファイルにアペンドするためにファイルをオープンするネイティブファイル動作のためのファミリを１つ有することを特徴とする請求項２に記載のコンピュータ読取り可能な記録媒体。
　　【請求項５】　前記ファミリのセットが、空ファイルを作成するネイティブファイル動作のためのファミリを１つ有することを特徴とする請求項２に記載のコンピュータ読取り可能な記録媒体。
　　【請求項６】　前記ファミリのセットが、ファイルを削除するネイティブファイル動作のためのファミリを１つ有することを特徴とする請求項２に記載のコンピュータ読取り可能な記録媒体。
　　【請求項７】　前記ファミリのセットが、ディレクトリを削除、ディレクトリを作成、ディレクトリを名前変更、およびファイルを名前変更するネイティブディレクトリおよびファイル動作の各々にファミリを１つ有することを特徴とする請求項２に記載のコンピュータ読取り可能な記録媒体。
　　【請求項８】　ネイティブファイルシステムがＵＮＩＸファイルシステムであり、前記ネイティブファイルおよびディレクトリ動作のセットが、ＵＮＩＸファイルシステムアプリケーションプログラマのインタフェースで使用可能の実質的に全てのファイルシステムのファイルおよびディレクトリ動作を有することを特徴とする請求項２に記載のコンピュータ読取り可能な記録媒体。
　　【請求項９】　ファイルまたはファイルシステムの状態を修正するネイティブファイルおよびディレクトリ修正動作を有するネイティブファイルシステム内のファイルのセットの状態を復元するために、トランザクションファイルおよびディレクトリ動作を提供する方法であって、前記方法が、
（ａ）前記修正動作の各セットに実行ルーチン、終了ルーチン、およびアンドゥルーチンを提供するステップを有し、ここで、実行および終了ルーチンは関連ファイルまたはディレクトリ修正動作を総合的に実行し、そして、終了およびアンドゥルーチンは、関連ファイルまたはディレクトリ修正動作のロールバックを総合的に実行し、
（ｂ）ファイルまたはディレクトリ修正動作を含むトランザクションをオープンするためのトランザクションオープンルーチンと、このようなトランザクションをコミットするためのコミットルーチンと、このようなトランザクションをロールバックするためのロールバックルーチンとを含むトランザクションマスタを提供するステップを有し、
　ここで、前記コミットルーチンは終了ルーチンを呼出し、前記ロールバックルーチンはアンドゥルーチンを呼出し、
ここで、
（ｃ）呼出された前記コミットルーチンが全てのオープントランザクションをコミットし、
（ｄ）呼出された前記ロールバックルーチンが全てのオープントランザクションをロールバックする、ことを特徴とする方法。
　　【請求項１０】　前記ネイティブファイルシステムがＵＮＩＸファイルシステムであることを特徴とする請求項９に記載の方法。
　　【請求項１１】　ルーチンが提供された前記ファイルおよびディレクトリ修正動作のセットが、実質的にファイルまたはファイルシステムの状態を修正することが可能な全てのネイティブファイルシステムのファイルおよびディレクトリ動作から成ることを特徴とする請求項９に記載の方法。
　　【請求項１２】　前記ファイルのセット内の前記ファイルが2つ以上のホストコンピュータに分散されていることを特徴とする請求項９に記載の方法。
　　【請求項１３】　ディレクトリを除去するネイティブディレクトリ修正動作のためにディレクトリ削除ファミリのルーチンを提供するステップをさらに有し、
（ａ）前記ディレクトリ削除ファミリの実行ルーチンが、（１）関連トランザクションがコミットされるまで別のファイルシステムの内容を保存するために使用されるファイルシステムの対象を指示するコパスの名前を生成し、（２）前記ディレクトリを前記コパスの名前に名前変更するステップを有し、
（ｂ）前記ディレクトリ削除ファミリの終了ルーチンが、前記コパスを削除するステップを有し、
（ｃ）前記ディレクトリ削除ファミリのアンドゥルーチンが、前記コパスを前記オリジナルディレクトリ名に名前変更するステップを有する、
ことを特徴とする請求項９に記載の方法。
　　【請求項１４】　アップデートのためにファイルをオープンする前記ネイティブファイル修正動作のためにアップデートファミリのルーチンを提供するステップをさらに有し、
（ａ）前記アップデートファミリの実行ルーチンが、（１）関連トランザクションがコミットされるまで別のファイルシステムの内容を保存するために使用されるファイルシステムの対象を指示するコパスの名前を生成し、（２）前記ファイルを前記コパスにコピーするステップを有し、
（ｂ）前記アップデートファミリの終了ルーチンが、前記コパスを削除するステップを有し、
（ｃ）前記アップデートファミリのアンドゥルーチンが、前記コパスをオリジナルファイルの上にコピーし、次に前記コパスを削除するステップを有する、
ことを特徴とする請求項9に記載の方法。」
に補正するものである。
　
　すなわち、本件請求項の補正は、例えば、請求項１においては、
　「トランザクションセマンティクスの追加を、このようなネイティブファイルシステムにコミットおよびロールバック機能性を追加することにより行う、コンピュータ読取り可能媒体上にあるコンピュータプログラムライブラリであって、」を「トランザクションセマンティクスを追加するためのコンピュータプログラムライブラリを記録したコンピュータ読取り可能な記録媒体であって、」に、
　「且つ、関連ネイティブファイル」を「そして、最低１つのネイティブファイル」に、
　「同等な機能結果を」を「機能的に同等である結果を」に、
　「関連実行ルーチンの機能結果を」を「関連実行ルーチンの結果を」に、
　「コンピュータプログラムライブラリ」を「コンピュータ読取り可能な記録媒体」に補正するものである。
　なお、他の請求項についての補正も同じような内容である。
　
２．そこで本件請求項の補正が特許法第１７条の２に規定する要件を満たしているか否かを以下検討する。
　これらの手続補正は、拒絶査定時に指摘された不明瞭点である、「『・・・コンピュータプログラムを記録したコンピュータ読取り可能な記録媒体』を特定した記載となっておらず、カテゴリー不明あるいは意味不明である」を解消し、本願発明が「記録媒体」に関する発明である点を明瞭にするための手続補正であるものと認められる。したがって、本件手続補正は、特許法第１７条の２第４項第４号の趣旨に合致するものであるので、本件手続補正を認める。
　
第３．本願発明
　したがって本願請求項１に係る発明は、平成１６年６月１６日付手続補正て補正されたところの、
　「【請求項１】　ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットヘトランザクションセマンティクスを追加するためのコンピュータプログラムライブラリを記録したコンピュータ読取り可能な記録媒体であって、前記ライブラリが１つ以上のルーチンファミリのセットを有し、このようなルーチンファミリの各々が最低１つのネイティブファイルまたはディレクトリ動作と関連し、そして、最低１つのネイティブファイルまたはディレクトリ動作の代わりに呼出されるように構成され、このようなルーチンファミリの各々が、
（ａ）ファミリの関連ネイティブファイルまたはディレクトリ動作の１つと機能的に同等である結果をコンピュータに提供させて、一方でこのようなネイティブファイルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命令を含む実行ルーチンと、
（ｂ）コンピュータに、関連実行ルーチンの結果をコミットさせるコンピュータ命令を含む終了ルーチンと、
（ｃ）コンピュータに、関連実行ルーチンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチンと、
を有することを特徴とするコンピュータ読取り可能な記録媒体。」
にあるものと認める（以下、「本願発明」という。）
　
第４．引用文献に記載の発明
　原審において引用された刊行物である、「Seltzer M. et al.，LIBTP:Portable Modular Transactions for UNIX，Proceedings of the 1992 Winter Usenix，米国，１９９２年　１月，p.9-25」（以下、「引用文献」という。）には、以下のように記載されている。
　
Ａ．「Although these properties are most frequently discussed in the context of databases, they are useful programming paradigms for more general purpose applications. There are several different situations where transactions can be used to replace current ad-hoc mechanisms.
　　　0ne situation is when mlultip1e files or parts of files need to be updated in an atomic fashion. For examp1e, the traditional UNIX file system uses ordering constraints to achieve recoverability in the face of crashes. When a new file is created, its inode is written to disk before the new file is added to the directory structure. This guarantees that, if the system crashes between the two I/O's, the directory does not contain are reference to an invalid inode. In actuality, the desired effect is that these two updates have the transactional property of atomicity (either both writes are visible or neither is). Rather than bui1ding special purpose recovery mechanisms into the file system or related tools (e.g. fsck(8)), one could use general purpose transaction recovery protocols after system failure. Any application that needs to keep multip1e, related files (or directories) consistent should do so using transactions. Source code control systems, such as RCS and SCCS, should use transaction semantics to allow the “checking in” of groups of related files. In this way, if the“check-in” fails, the transaction may be aborted, backing out the partial “check-in” leaving the source repository in a consistent state.
　　　A second situation where transactions can be used to replace current ad-hoc mechanisms is in applications where concurrent updates to a shared file are desired, but there is logical consistency of the data which needs to be preserved. For example, when the password file is updated, file locking is used to disallow concurrent access. Transaction semantics on the password files would allow concurrent updates, while preserving the logical consistency of the password database. Similarly, UNIX utilities which rewrite files face a potential race condition between their rewriting a file and another process reading the file. For example, the compiler (more precisely, the assembler) may have to rewrite a file to which it has write permission in a directory to which it does not have write permission. While the “.o” file is being written, another utility such as nm(1) or ar(1) may read the file and produce invalid results since the file has not been completely written. Currently, some utilities use special purpose code to handle such cases while others ignore the problem and force users to live with the consequences.」（第９乃至１０頁「1.Introduction の第２乃至４段落（第９頁第２３行〜第１０頁第４行目）」）
（仮訳）
　「これらの性質はデータベースに関する文脈でしばしば議論されるが、より一般的な目的のアプリケーションのためにも有用なプログラミングパラダイムである。現に用いられているアドホックなメカニズムに換えてトランザクションを用いることが可能であるいくつかの状況がある。
　そうした状況の一つは、複数のファイル又は複数のファイルの複数の部分が原子的に(in atmic fashion)更新される必要がある時に生ずる。例えば、伝統的なUNIXファイルシステムはクラッシュに直面した場合の回復可能性を達成するために順番どおりに（書き込みを）行うという制約を用いている。新しいファイルが生成される時、その新しいファイルがディレクトリ構造に追加される前にそのｉノードがディスクに書き込まれる。このことによって、そのシステムがその二つのI/Oの間でクラッシュした場合においても、そのディレクトリが無効なiノードの参照を含まないことを保証する。実際には、望まれていた効果は、これらの二つの更新がトランザクションとしての原子性(atmicity)（双方の書き込みが見える(visible)、あるいは、いずれもが見えない(invisible)、のいずれか）を備えていることである。・・・・・・・・（中略）・・・・・・・・・・・・
　現に用いられているアドホックなメカニズムに換えてトランザクションを用いることが可能であるような二つ目の状況は、共有ファイルに対する同時的な(concurrent)更新が望まれるが、論理的なデータの一貫性は維持されていなければならないようなアプリケーションにおいて生ずる。例えばパスワードファイルを更新するとき、同時的なアクセスを不許可にするためにファイルロッキングが用いられる。パスワードファイルにおいてトランザクションセマンティックスにより、パスワードデータベースの論理的な一貫性を維持しながら、パスワードファイルを同時に更新することが許容される。同様に、ファイルをリライトするUNIXユーティリティは、それらのファイルのリライトと他のプロセスからの読出しとの間の潜在的な競合状態に直面している。例えば、コンパイラ（正確にはアセンブラ）は書き込み許可を有しないディレクトリ中の書き込み許可を有するファイルをリライトしなければならないかもしれない。その“.o”ファイルが書き込まれている間にnm(1)やar(1)のような他のユーティリティがファイルを読み、ファイルが完全に書き込まれていないために無価値な結果を生成するかもしれない。現状では、いくつかのユーティリティではこうした状況を取り扱うための特別なコードを用いるが、他のユーティリティではこの問題は無視されてその帰結を受け入れる(live with the consequences)ことをユーザは強いられている。」
　
Ｂ．「In this paper, we present a simple library which provides transaction semantics (atomicity, consistency, isolation, and durability. The 4.4BSD database access methods have been modified to use this library optionally providing shared buffer management between applications, locking, and transaction semantics. Any UNIX program may transaction protect its data by requesting transaction protection with the db(3) library or by adding appropriate calls to the transaction manager, buffer manager, lock manager, and log manager. The library routines may be linked into the host app1ication and called by subroutine interface, or they may reside in a separate server process. The server architecture provides for network access and better protection mechanisms.」（第１０頁「1.Introduction の第５段落（第５〜１１行目）」）
（仮訳）
　「この論文では、トランザクションセマンティクス（原子性、同時性、分離性、永続性）を提供する簡単なライブラリについて解説する。4.4BSDのデータベースアクセスメソッドは、選択的にアプリケーション間での共有バッファ管理、ロッキング及びトランザクションセマンティクスを提供するように、このライブラリを用いて改変された。どのようなUNIXプログラムもこのdb(3)ライブラリを用いたトランザクション保護を要求するか、又は、トランザクションマネージャ、バッファマネージャ、ロックマネージャ及びログマネージャに対する適切な呼出(call)を追加することによって、そのデータに対するトランザクション保護を行う(transaction protect)ことができる。これらのライブラリルーチンはホストとなるアプリケーションにリンクされてサブルーチンインターフェースにより呼び出されることができる、又は、分離したサーバープロセスとして存在することができる。このサーバーアーキテクチャによりネットワークアクセスとより良い保護メカニズムが提供される。」
　
Ｃ．「3.2. Module Architecture
　　　The preceding sections described modules for managing the transaction log, locks, and a cache of shared buffers. In addition, we need to provide functionality for transaction begin, commit, and abort processing, necessitating a transaction manager. In order to arbitrate concurrent access to locks and buffers, we include a process management module which manages a collection of semaphores used to block and release processes. Finally, in order to provide a simple, standard interface we have modified the database access routines (db(3)). For the purposes of this paper we call the modified package the Record Manager. Figure one shows the main interfaces and architecture of LIBTP.
　
3.2.1. The Log Manager
　　　The Log Manager enforces the write‐ahead logging protocol. Its primitive operations are log, log_commit, log_read, log_roll and log_unroll. The log call performs a buffered write of the specified log record and returns a unique log sequence number (LSN). This LSN may then be used to retrieve a record from the log using the log_read call. The log interface knows very little about the internal format of the log records it receives. Rather, all log records are referenced by a header structure, a log record type, and a character buffer containing the data to be logged. The log record type is used to call the appropriate redo and undo routines during abort and commit processing. While we have used the Log Manager to provide before and after image logging, it may also be used for any of the logging algorithms discussed.
　　　The log_commit operation behaves exactly like the log operation but guarantees that the log has been forced to disk before retuning. A discussion of our commit strategy appears in the implementation section (section 4.2). Log_unroll reads log records from the log, following backward transaction pointers and calling the appropriate undo routines to implement transaction abort. In a similar manner, log_roll reads log records sequentially forward, calling the appropriate redo routines to recover committed transactions after a system crash.
　
3.2.2. The Buffer Manager
　　　The Buffer Manager uses a Pool of shared memory to provide a least-recently-used (LRU) block cache. Although the current library provides an LRU cache, it would be simple to add alternate replacement policies as suggested by [CHOU85] or to provide multiple buffer pools with different policies. Transactions request pages from the buffer manager and keep them pinned to ensure that they are not written to disk while they are in a logically inconsistent state. When page replacement is necessary, the Buffer Manager finds an unpinned page and then checks with the Log Manager to ensure that the write-ahead protocol is enforced.
　
3.2.3. The Lock Manager
　　　The Lock Manager supports general purpose locking (single writer, multiple readers) which is currently used to provide two-phase locking and high concurrency B-tree locking, However, the general purpose nature of the lock manager provides the ability to support a variety of locking protocols. Currently, all locks are issued at the granularity of a page (the size of a buffer in the buffer pool) which is identified by two 4-byte integers (a file id and page number). This provides the necessary information to extend the Lock Manager to perform hierarchical locking [GLAY76]. The current implementation does not support locks at other granularities and does not promote locks; these are obvious future additions to the system.
　　　If an incoming lock request cannot be granted, the requesting process is queued for the lock and descheduled. When a lock is released, the wait queue is traversed and any newly compatible locks are granted. Locks are located via a file and page hash table and are chained both by object and by transaction, facilitating rapid traversal of the lock table during transaction commit and abort.
　　　The primary interfaces to the lock manager are lock, unlock, and lock_unlock_all. Lock obtains a new lock for a specific object. There are also two variants of the lock request, lock_upgrade and lock_downgrade, which allow the caller to atomically trade a lock of one type for a lock of another. Unlock releases a specific mode of lock on a specific object. Lock_unlock_all releases all the locks associated with a specific transaction.
　
3.2.4. The Process Manager
　　　The Process Manager acts as a user-level scheduler to make processes wait on unavailable locks and pending buffer cache I/O. For each process, a semaphore is maintained upon which that process waits when it needs to be descheduled. When a process needs to be run, its semaphore is cleared, and the operating system reschedules it. No sophisticated scheduling algorithm is applied; if the lock for which a process was waiting becomes available, the process is made runnable. It would have been possible to change the kernel's process scheduler to interact more efficiently with the lock manager, but doing so would have compromised our commitment to a user‐level package.
　
3.2.5. The Transaction Manager
　　　The Transaction Manager provides the standard interface of txn_begin, txn_commit, and txn-abort, It keeps track of all active transactions, assigns unique transaction identifiers, and directs the abort and commit processing. When a txn_begin is issued, the Transaction Manager assigns the next available transaction identifier, allocates a per‐process transaction structure in shared memory, increments the count of active transactions, and returns the new transaction identifier to the calling process. The in‐memory transaction structure contains a pointer into the lock table for locks held by this transaction, the last log sequence number, a transaction state (idle, running, aborting, or committing), an error code, and a semaphore identifier.
　　　At commit, the Transaction Manager calls log_commit to record the end of transaction and to flush the log. Then it directs the Lock Manager to release all locks associated with the given transaction. If a transaction aborts, the Transaction Manager calls on log_unroll to read the transaction's log records and undo any modifications to the database. As in the commit case, it then calls lock_unlock_all to release the transaction's locks.
　
3.2.6.The Record Manager
　　　The Record Manager supports the abstraction of reading and writing records to a database. We have modified the database access routines db(3) [BSD91] to call the log, lock, and buffer managers. In order to provide functionality to perform undo and redo, the Record Manager defines a collection of log record types and the associated undo and redo routines. The Log Manager performs a table lookup on the record type to call the appropriate routines. For example, the B‐tree access method requires two log record types: insert and delete. A replace operation is implemented as a delete followed by an insert and is logged accordingly.」（第１２頁第４１行〜第１４頁第３９行目）
（仮訳）
　「３．２．モジュールアーキテクチャ
　前のセクションにおいて、トランザクションログ、ロック、共有バッファキャッシュの管理を行うためのモジュールが記述された。それに加えて、トランザクションの開始処理、コミット処理及びアボート処理の機能が提供されなければならず、トランザクションマネージャが不可欠である。ロックとバッファに対する競合する同時的なアクセスを調停するために、プロセスのブロックとリリースに用いられるセマフォの集合を管理するプロセス管理モジュールを含めることとする。最後に簡単で標準化されたインターフェースを提供するために、データベースアクセスルーチン(db(3))を変更した。この論文においては、この変更されたパッケージをレコードマネージャと呼ぶこととする。図１にLIBTPの主なインターフェースとアーキテクチャが示されている。
　
３．２．１．ログマネージャ
　ログマネージャはライトアヘッドロギングプロトコルを強制する。そのプリミティブ操作はlog、log_commit、log_roll、log_unrollである。log呼出は、特別なログレコードに対するバッファされた書き込みを実行して、唯一のログ順序番号(LSN)を返す。このLSNはlog_read呼出を用いてログからレコードを獲得するために用いられる。このlogインターフェースは、それが受け取るログレコードの内部形式についてはほとんど知らない。むしろ全てのログレコードは、ヘッダの構造、ログレコードの種類とログとして書き込まれるべきデータを含むキャラクタバッファによって参照される。このログレコードの種別は、アボート処理とコミット処理の間に適切なredoとundoのルーチンを呼び出すために用いられる。ここではログマネージャを用いて事前及び事後のログを提供しているが、議論されたロギングアルゴリズムのいずれを用いることも可能であろう。
　log_commt操作は、確かにlog操作と同じように振舞うが、戻る前にディスクへの書き込みが強制される。私たちが採用するコミット戦略についての議論は実装に関する節（section4.2）において行う。Log_unroll　はログからログレコードを読み、後ろ向きのトランザクションポインタを伴って、トランザクションのアボートを実装した適切なundoルーチンを呼び出す。同様なやり方で、Log_rollはログレコードを前向きに連続して読み、システムのクラッシュ後に既にコミット済みトランザクションの回復を行うための適切はredoルーチンを呼び出す。
　
３．２．２．バッファマネージャ
　バッファマネージャは、共有メモリのプールを使ってleast-recently-used(LRU)のブロックキャッシュを提供する。現在のライブラリはＬＲＵキャッシュを提供しているが、［CHOU85］に示唆されるように代替の置換戦略を加えたり、異なる戦略による複数のバッファプールを提供することは簡単であろう。トランザクションはバッファマネージャにページを要求し、これらを常駐化して論理的に非定常状態にある間はディスクへの書き込みが行われないことを保証する。ページの置換が必要なときは、バッファマネージャは常駐化されていないページを探してそしてログマネージャにおいてライトアヘッドプロトコルが確実に強制されるようにチェックする。
　
３．２．３．ロックマネージャ
　ロックマネージャは、２相ロッキングと高い並列度を有するB-treeロッキングを提供するために用いられる一般的な目的のロッキング（単一書き込み者と複数の読出し者）をサポートする。しかしながら、ロックマネージャが一般的な目的のものであるという性質によって、さまざまなロッキングプロトコルをサポートする能力が提供される。現状では、全てのロックは２つの４バイト整数（ファイルidとページ番号）によって識別されるページの粒度（バッファプールのバッファの大きさ）で発行される。これは、ロックマネージャを階層的ロッキングを実行するように拡張するための必要な情報を提供する。現在の実装では他の粒度のロックをサポートしていないし、ロックのプロモートを行わない。・・・・・（中略）・・・・
　
３．２．５トランザクションマネージャ
　トランザクションマネージャは、txn_begin、txn_commit、txn_abortの標準インターフェースを提供する。それは、全てのアクティブなトランザクションの進路を追い、唯一のトランザクション識別子を割当て、そしてアボート処理とコミット処理を指揮する。txn_bigenが発行されるとき、トランザクションマネージャは次に利用可能なトランザクション識別子を割当て、共有メモリ上にプロセス毎のトランザクション構造をアロケートし、アクティブトランザクション数をインクリメントし、呼出元プロセスに対して新しいトランザクション識別子を返す。メモリ内のトランザクション構造は、そのトランザクションによって保持されているロックのためのロックテーブルへのポインタ、過去最近のログ順序番号、トランザクションの状態（アイドル、実行中、アボート処理中、コミット処理中）エラーコード及びセマフォアの識別子を含む。
　コミットの際、トランザクションマネージャはlog_commitを呼び出してトランザクションの終了を記録し、ログをディスクへ書き出す(flush)。そして、ロックマネージャにそのトランザクションに関連して保持された全てのロックを開放するように指示する。もしトランザクションがアボートしたら、トランザクションマネージャはlog_unrollをコールしてトランザクションのログレコードを読み、データベースになされた変更についてundoする。それから、コミットの場合と同様に、トランザクションのロックを開放するためにlock_unlock_allを呼び出す。
　
３．２．６．レコードマネージャ
　レコードマネージャは抽象化されたデータベースへのレコードの読出しと書き込みをサポートする。データベースアクセスルーチンのdb(3)がログ、ロック及びバッファの各マネージャを呼び出すように変更された。ｕｎｄｏとｒｅｄｏを実行する機能を提供するために、レコードマネージャはログレコードの種別と関係するｕｎｄｏとｒｅｄｏのルーチンを定義する。ログマネージャがそのレコード種別をテーブルから探し、適切なルーチンを呼び出す。例えばＢ−ｔｒｅｅアクセスメソッドは２つのログレコード種別、挿入と削除、を必要とする。置き換え操作は挿入が引き続くような削除として実装され、そのようにログに記録される。」
　
Ｄ．「3.3. Application Architectures
　　　The structure of LIBTP allows application designers to trade off performance and protection. Since a large portion of LIBTP's functionality is provided by managing structures in shared memory, its structures are subject to corruption by applications when the library is linked directly with the application. For this reason, LIBTP is designed to allow compilation into a separate server process which may be accessed via a socket interface. In this way LIBTP's data structures are protected from application code, but communication overhead is increased. When applications are trusted, LIBTP may be compiled directly into the application providing improved performance. Figures two and three show the to alternate application architectures.
　
　　　There are potentially two modes in which one might use LIBTP in a server based architecture. In the first, the server would provide the capability to respond to requests to each of the low level modules (lock, log, buffer, and transaction managers). Unfortunately, the performance of such a system is likely to be blindingly slow since modifying piece of data would require three or possibly four separate communications: one to lock the data, one to obtain the data, one to log the modification, and possibly one to transmit the modified data. Figure four shows the relative performance for retrieving a single record using the record level call versus using the lower level buffer management and locking calls. The 2:1 ratio observed in the single process case reflects the additional overhead of parsing eight commands rather than one while the 3:1 ratio observed in the client/server architecture reflects both the parsing and the communication overheard. Although there may be applications which could tolerate such performance, it seems far more feasible to support a higher level interface, such as that provided by a query language (e.g. SQL [SQL86]).
　　　Although LIBTP does not have an SQL parser, we have built a server application using the toolkit command language (TCL) [OUST90]. The server supports a command line interface similar to the subroutine interface defined in db(3). Since it is based on TCL, it provides control structures as well.」（第１４頁第４０行〜第１５頁第１１行目）
（仮訳）
　「３．３アプリケーションアーキテクチャ
　LIBTPの構造によって、アプリケーションプログラム設計者が性能と保護のトレードオフを行えるようになる。LIBTPの機能の大部分は共有メモリの構造を管理することによって与えられるものであり、そうした構造はこのライブラリがアプリケーションにリンクされたときには、そのアプリケーションにおける「なまり」(corruption)に支配される。このため、LIBTPはソケットインターフェースを通じてアクセスできるような分離したサーバプロセスとしてのコンパイレーションを許容するように設計されている。このようにすると、LIBTPのデータ構造はアプリケーションコードから保護されるが、通信のオーバーヘッドは増加する。アプリケーションが信頼できるときには、性能を向上させるためにLIBTPをアプリケーション中に直接組み込むようにコンパイルすることができる。図２と図３にはその二つの代替的なアプリケーションアーキテクチャが示されている。
・・・・・・（中略）・・・・・・・・
そのような性能を許容できるようなアプリケーションがあるのか否かはともかく、あたかも質問言語において提供されているかのような高いレベルのインターフェースをサポートすることはとても実現性が高い。LIBTPはSQLパーザを備えていないが、私たちはツールキットコマンド言語(TCL)を用いてサーバアプリケーションを作成した。そのサーバはdb(3)において定義されたサブルーチンインターフェースに類似したコマンドラインのインターフェースをサポートする。
・・・・・・・・・・（以下略）・・・・・・・」
　
Ｅ．「4.4. Transaction Protected Access Methods
　　　The B‐tree and length recno (record number) access methods have been modified to provide transaction protection. Whereas the previously published interface to the access routines had separate open calls for each of the access methods, we now have an integrated open call with the following calling conventions:
　
　DB *dbopen (const char *fie, int flags, int mode, DBTYPE type,
              int dbflags, const void *openinfo)
　
where file is the name of the file being opened, flags and mode are the standard arguments to open(2), type is one of the access method types, dbflags indicates the mode of the buffer pool and transaction protection, and openinfo is the access method specific information. Currently, the possible values for dbflags are DB_SHARED and DB_TP indicating that buffers should be kept in a shared buffer pool and that the file should be transaction protected.
　　　The modifications required to add transaction protection to an access method are quite simple and localized.
　　1. Replace file open with buf_open.
　　2. Replace file read and write calls with buffer manager calls (buf_get, buf_unpin).
　　3. Precede buffer manager calls with an appropriate (read or write) lock call.
　　4. Before updates, issue a logging operation.
　　5. After data have been accessed, release the buffer manager pin.
　　6. Provide undo/redo code for each type of log record defined.
　
The following code fragments show how to transaction protect several updates to a B‐tree. In the unprotected case, an open call is followed by a read call to obtain the meta‐data for the B‐tree. Instead, we issue an open to the buffer manager to obtain a file id and a buffer request to obtain the meta-date as shown below.
　
　char *path;
　int fid, flags, len, mode;
　
　/* Obtain a file id with which to access the buffer pool */
　fid = buf_open(path, flags, mode);
　
　/* Read the meta data (page 0) for the B-tree */
　if (tp_lock(fid, 0, READ_LOCK))
　　　　return error;
　meta_data_ptr = buf_get(fid, 0, BF_PIN, len);
　
The BF_PIN argument to buf_get indicates that we wish to leave this page pinned in memory so that it is not swapped out while we are accessing it. The last argument to buf_get returns the number of bytes on the page that were valid so that the access method may initialize the page if necessary.
　　　Next, consider inserting a record on a particular page of a B‐tree. In the unprotected case, we read the page, call_bt_insertat, and write the page. Instead, we lock the page, request the buffer, log the change, modify the page, and release the buffer.
　
　int fid, len, pageno;    /* Identifies the buffer */
　int index;               /* Location at which to insert the new pair */
　DBT *keyp, *datap;       /* Key/Data pair to be insert */
　DATUM *d;                /* Key/data structure to insert */
　
　/* Lock and request the buffer */
　if (tp_lock(fid, pageno, WRITE_LOCK))
　　　　return error;
　buffer_ptr = buf_get(fid, pageno, BF_PIN, len);
　
　/* Log and perform the update */
　log_insdel(BTREE_INSERT, fid, pageno, keyp, datap);
　_bt_insertat(buffer_ptr, d, index);
　buf_unpin(uffer_ptr);
　
Succinctly, the algorithm for turning unprotected code into protected code is to replace read operations with lock and buf-get operations and write operations with log and buf_unpin operations.」（第１７頁第２６行〜第１８頁末行）
（仮訳）
　「４．４トランザクションによる保護を受けるアクセスメソッド
　B-Treeと固定長レコードナンバーへのアクセスメソッドがトランザクションによる保護を提供するように変更された。これらのルーチンに対する以前に公開されたインターフェースにおいて、それぞれのアクセスメソッドに対する分離したオープン呼出しを備えていたが、その代替となる以下の呼出しによる統合したオープンコールを用いることとした。
　
　DB *dbopen（以下、省略）
　
ここで、fileはこれからオープンされようとしているファイル名、flagsとmodeはopen(2)における標準の引数、typeはアクセスメソッドのタイプの一つ、dbflagsはバッファプールとトランザクション保護のモードを指示、openinfoはそのアクセスメソッドに特有の情報である、現時点では、dbflagsの値として可能な値はDB_SHAREDとDB_TPであり、これらの値はそれぞれバッファを共有バッファプールに保持すべきであることと、そのファイルに対してトランザクション保護がされるべきであるということを指示するものである。
　
　アクセスメソッドに対してトランザクション保護を追加するために要求される変更は、たいへん簡単で局所的である。
１．ファイルのopenコールをbuf_openで置き換える
２．ファイルのreadとwriteコールをそれぞれ対応するバッファマネージャに対する呼出(buf_get,buf_unpin)で置き換える。
３．バッファマネージャに対する呼出の前に適当な（読出しあるいは書き込み用の）ロック呼出を置く
４．更新処理の前にログ処理を発行する。
５．データがアクセスされた後に、バッファマネージャによる常駐をリリースする。
６．ログレコードによって定義される各々の種類に応じてundo/redoを提供する。
　
　次のコードの断片はB-treeに対する複数の更新についてどのようにしてトランザクションによる保護を行うかを示すものである。保護がない場合であればopen呼出に続いてB-treeのメタデータを獲得するためのread呼出がなされるが、ここではそうせずに、次に示すように、ファイルidを獲得するためにバッファマネージャに対するオープン呼出と、そのメタデータを獲得するためのバッファリクエストを発行する。
　
　char *path;（以下、省略）
　
　buf_get呼出の引数であるBUF_PINは、アクセスを行っている間にこのページをスワップアウトしないように、このページをメモリに常駐化したままとすることを望んでいることを指示する。buf_getの最後の引数は、必要に応じてアクセスメソッドにおいて初期化することができるように有効とされたページのバイト数を返す。
　
　次にB-treeの特定のページにレコードを挿入してみよう。保護がない場合であれば、ページを読み、_bt_insertedを呼出し、ページを書き出すが、ここではそうせずに、ページをロックし、バッファを要求し、ログに変更を記録し、ページを変更し、そしてバッファをリリースする。
　int fid, len, pageno;（以下、省略）
簡単にいえば、保護されていないコードを保護されたコードに改良する手順は、read操作をlockとbuf_get操作に置き換え、write操作をlogとbuf_unpin操作で置き換えることである。」と、記載されている。
　
　すなわち、引用文献には、
　
　「伝統的なUNIXファイルシステムにおける新しいファイルの生成等のように複数のファイルの複数の部分が原子的に更新される必要がある場合や共有ファイルに対する同時的な更新が望まれる一方で論理的なデータの一貫性を維持する必要が生ずる場合に、ライブラリに属するルーチンに対する適切な呼出を追加することによって、トランザクションセマンティクスを提供するための該ライブラリ（LIBTP）であって、
　前記ライブラリがログマネージャ、バッファマネージャ、ロックマネージャ、トランザクションマネージャの各々を実現するルーチンを含むものであって、これらのルーチンにおいては、ログマネージャの実行によりコミット処理及びアボート処理の際参照される事前及び事後のログ取得処理を行い、トランザクションマネージャ等を実現する各ルーチンの実行によりtxn_commitプリミティブによって起動されるコミット処理を行い、トランザクションマネージャ等を実現する各ルーチンの実行によりtxn_abortプリミティブによって起動されるアボート処理を行うライブラリを含むことを特徴とするファイルの更新処理方法」に関する発明が開示されている（以下、これを「引用発明」という）。
　
第５．対比・判断
１．対比
本願発明と、引用発明とを対比すると、
両者は共に、コンピュータプログラムのトランザクション処理に関するものであって、
　引用発明の「伝統的なUNIXファイルシステム」が本願発明の「ネイティブファイルシステム」に相当し、
　引用発明における「新しいファイルの生成等のように複数のファイルの複数の部分が原子的に更新される必要がある場合や共有ファイルに対する同時的な更新が望まれる一方で論理的なデータの一貫性を維持する必要が生ずる場合」に実行されているファイル生成等の具体的なファイル操作は、トランザクションの保護の対象となるファイル操作を含む実行ルーチンであるので、これは、本願発明の「ネイティブファイルシステムにおけるファイル及びディレクトリの操作」を含むルーチンに対応するとともに「関連実行ルーチン」に相当し、
　引用発明における「ライブラリ（LIBTP）」は、ネイティブファイルシステムに必要に応じてトランザクションセマンティクスを追加あるいは提供するためのコンピュータプログラムルーチンの集合であるので、これは本願発明の「ライブラリ」に相当し、
　引用発明におけるライブラリを構成するルーチン（あるいはルーチンファミリ）である「ログマネージャ、バッファマネージャ、ロックマネージャ、トランザクションマネージャの各々を実現するルーチン」の各々は、本願発明の「ルーチン」あるいは「ルーチンファミリ」に相当し、又、引用発明においてもこれらのルーチンが複数あり、本願発明と同様に、「セット」を構成していると言うことができる。
　引用発明の「コミット処理及びアボート処理の際参照される事前及び事後のログを取得する処理」は、トランザクション処理におけるログ取得の処理であるので、本願発明の  「ファイル又はディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命令を含む実行ルーチン」に相当し、
　引用発明の「txn_commitプリミティブによって起動されるコミット処理」は、トランザクション処理におけるコミット処理であるので、本願発明の「関連実行ルーチンの結果をコミットさせるコンピュータ命令を含む終了ルーチン」に相当し、
　引用発明の「txn_abortプリミティブによって起動されるアボート処理」は、トランザクション処理におけるロールバック処理であるので、本願発明の「関連実行ルーチンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチン」に相当している。
　
　したがって、両者は共に、
　
　ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットへトランザクションセマンティクスを追加するためのコンピュータプログラムライブラリであって、前記ライブラリが１つ以上のルーチンファミリのセットを有し、このようなルーチンファミリの各々が、
(a)このようなネイティブファイルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命令を含む実行ルーチンと、
(b)コンピュータに、関連実行ルーチンの結果をコミットさせるコンピュータ命令を含む終了ルーチンと、
(c)コンピュータに、関連実行ルーチンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチンと、
を有することを特徴とするコンピュータプログラムライブラリ
である点で一致する。
　
　ただ、
相違点（１）
　本願発明においては、「ルーチンファミリの各々が最低１つのネイティブファイルまたはディレクトリ動作と関連し、そして最低１つのネイティブファイルまたはディレクトリ動作の代わりに呼び出されるように構成され」、(a)の実行ルーチンにおいて「ファミリの関連ネイティブファイルまたはディレクトリ動作の１つと機能的に同等である結果をコンピュータに提供させる」とともに、このようなルーチンファミリ「の各々」が上記の(a)から(c)の処理を実現するルーチンを有する、すなわち、ネイティブファイルまたはディレクトリ動作についてのトランザクションを実現するために必要な処理を呼び出す際ネイティブファイルシステム上でネイティブファイル又はディレクトリ操作の呼出のためのAPIをそのまま用いて、かつ、ライブラリに属するルーチンの実行によってネイティブファイル又はディレクトリ動作の機能を実現するように構成されているのに対し、引用発明においては、ネイティブファイル又はディレクトリ操作の呼出のためのAPIとは異なった追加されたAPI(txn_commitプリミティブ等)を用いるように構成され、ライブラリに属するルーチンの実行ではなくネイティブファイルシステムの実行によってネイティブファイル又はディレクトリ動作の機能を実現するように構成されている点、
　
及び、
　
相違点（２）
　本願発明は「コンピュータ読取り可能な記録媒体」に関する発明であるのに対して、引用発明はコンピュータプログラムライブラリに関する発明である点、
で両者は相違している。
　
２．判断
相違点（１）について
　例えば、特開平６−１４９６３３号公報や特開平６−３５７８２号公報に見られるように、一般にシステムコールを用いて実現されている機能の拡張や機能の追加を行うにあたって、システムコールのAPIと同じAPIによって呼び出されそのシステムコールの機能と拡張機能とを実現するように構成されたルーチンを用いることによって、システムコールの呼び出し側であるアプリケーションの修正の手間を軽減あるいは不要にする技術は周知技術である。
　また、引用発明においてもトランザクションセマンティクスの導入という機能追加を行うにあたってアプリケーション修正の手間を軽減することは当業者にとって自明の事項である。
　又、一般に、複数のルーチンにより実現されている機能を１つのルーチンで実現することは当業者が通常行うことであって、このことはシステムコールを実現するルーチンについても同様であると言うことができる。
　してみると、引用発明においても、こうした周知技術を採用して、ネイティブファイルシステム上でネイティブファイル又はディレクトリ操作の呼出のためのAPIをそのまま用いることを可能とするために、ライブラリに属するルーチンの実行によってネイティブファイル又はディレクトリ動作の機能を実現するように構成して本願発明のようにすることは、当業者が適宜選択設計すべきことであり、その効果も当業者が通常予測すべき範囲のもの似すぎないものである。
　したがって、相違点（１）は格別の相違点であるものと言うことはできない。
　
相違点（２）について
　一般に、コンピュータ上でコンピュータプログラムライブラリを実行するためには、該プログラムライブラリをコンピュータ読取り可能な記録媒体に記憶させて実行させなければならないものである。したがって、相違点（２）も格別の相違点であるものとは言えない。
　
　したがって、本願発明は、引用発明から当業者が容易に発明することができたものである。
　
第６．むすび
　以上の通りであるので、本願本願請求項１に係る発明は、引用発明から当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。