戻る

平成１９年（行ケ）第１０１９６号審決取消請求事件
平成２０年８月６日判決言渡，平成２０年７月９日口頭弁論終結
判決
原告エービーイニティオソフトウェアコーポレーション
訴訟代理人弁理士平木祐輔，関谷三男，渡辺敏章，大塩剛
被告特許庁長官鈴木隆史
指定代理人山崎達也，吉岡浩，山本章裕，森山啓
主文
原告の請求を棄却する。
訴訟費用は原告の負担とする。
この判決に対する上告及び上告受理の申立てのための付加期間を３０日と定める。
事実及び理由
第１原告の求めた裁判
「特許庁が不服２００４−１０３１８号事件について平成１９年１月２３日にし
た審決を取り消す。」との判決
第２事案の概要
本件は，特許出願の拒絶査定に対する不服審判請求を不成立とした審決の取消し
を求める事案である。
１特許庁における手続の経緯
(1)原告は，平成９年７月１日（パリ条約による優先権主張・１９９６年（平
成８年）７月２日，アメリカ合衆国），名称を「ファイルの設定状態の復元」とす
る発明につき，特許出願（国際出願。以下「本件出願」という。）をした（特願平
１０−５０４４７４号）。
(2)原告は，平成１６年２月９日付けで，本件出願につき拒絶査定を受けたの
で，同年５月１７日，拒絶査定不服審判を請求した（不服２００４−１０３１８号
事件として係属）。
(3)特許庁は，平成１９年１月２３日，「本件審判の請求は，成り立たない。」
との審決をし，同年２月６日，その謄本を原告に送達した。
２本願発明の要旨
審決が対象としたのは，平成１６年６月１６日付け手続補正（甲６）により補正
された請求項１に記載された発明（以下「本願発明」という。）であり，その要旨
は次のとおりである。
「【請求項１】ネイティブファイルシステムのネイティブファイルおよびディ
レクトリ動作のセットヘトランザクションセマンティクスを追加するためのコンピ
ュータプログラムライブラリを記録したコンピュータ読取り可能な記録媒体であっ
て，前記ライブラリが１つ以上のルーチンファミリのセットを有し，このようなル
ーチンファミリの各々が最低１つのネイティブファイルまたはディレクトリ動作と
関連し，そして，最低１つのネイティブファイルまたはディレクトリ動作の代わり
に呼出されるように構成され，このようなルーチンファミリの各々が，
(a)ファミリの関連ネイティブファイルまたはディレクトリ動作の１つと機能的に
同等である結果をコンピュータに提供させて，一方でこのようなネイティブファイ
ルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピ
ュータ命令を含む実行ルーチンと，
(b)コンピュータに，関連実行ルーチンの結果をコミットさせるコンピュータ命令
を含む終了ルーチンと，
(c)コンピュータに，関連実行ルーチンの結果をロールバックさせるコンピュータ
命令を含むアンドゥルーチンと，
を有することを特徴とするコンピュータ読取り可能な記録媒体。」
３審決の理由の要旨
審決は，本願発明は下記引用例に記載された発明（以下「引用発明」という。）
に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条
２項の規定により特許を受けることができないとした。
引用例１９９２年（平成４年）１月にサンフランシスコで開催された「１９９
２年冬季Ｕｓｅｎｉｘ」の予稿集９頁ないし２５頁に収載されたMargoSeltzerら
による「LIBTP:Portable,ModularTransactionsforUNIX」と題する論文（甲１）
審決の理由中，引用例の記載事項及び引用発明の認定，本願発明と引用発明との
一致点及び相違点の認定並びに相違点についての判断に係る部分は，以下のとおり
である（符号及び明らかな誤記を改めた部分，略称を本判決が指定したものに改め
た部分並びに本訴における証拠番号を付記した部分がある。）。
(1)引用例の記載事項及び引用発明の認定
引用例には，以下のように記載されている。
ア「Althoughthesepropertiesaremostfrequentlydiscussedinthecontextofdatabases,
theyareusefulprogrammingparadigmsformoregeneralpurposeapplications.Thereare
severaldifferentsituationswheretransactionscanbeusedtoreplacecurrentad-hoc
mechanisms.
0nesituationiswhenmultip1efilesorpartsoffilesneedtobeupdatedinanatomic
fashion.Forexamp1e,thetraditionalUNIXfilesystemusesorderingconstraintsto
achieverecoverabilityinthefaceofcrashes.Whenanewfileiscreated,itsinodeis
writtentodiskbeforethenewfileisaddedtothedirectorystructure.Thisguarantees
that,ifthesystemcrashesbetweenthetwoI/O's,thedirectorydoesnotcontainare
referencetoaninvalidinode.Inactuality,thedesiredeffectisthatthesetwoupdates
havethetransactionalpropertyofatomicity(eitherbothwritesarevisibleorneither
is).Ratherthanbui1dingspecialpurposerecoverymechanismsintothefilesystemor
relatedtools(e.g.fsck(8)),onecouldusegeneralpurposetransactionrecoveryprotocols
aftersystemfailure.Anyapplicationthatneedstokeepmultip1e,relatedfiles(or
directories)consistentshoulddosousingtransactions.Sourcecodecontrolsystems,such
asRCSandSCCS,shouldusetransactionsemanticstoallowthe“checkingin”ofgroupsof
relatedfiles.Inthisway,ifthe“check-in”fails,thetransactionmaybeaborted,
backingoutthepartial“check-in”leavingthesourcerepositoryinaconsistentstate.
Asecondsituationwheretransactionscanbeusedtoreplacecurrentad-hocmechanisms
isinapplicationswhereconcurrentupdatestoasharedfilearedesired,butthereis
logicalconsistencyofthedatawhichneedstobepreserved.Forexample,whenthepassword
fileisupdated,filelockingisusedtodisallowconcurrentaccess.Transactionsemantics
onthepasswordfileswouldallowconcurrentupdates,whilepreservingthelogical
consistencyofthepassworddatabase.Similarly,UNIXutilitieswhichrewritefilesfacea
potentialraceconditionbetweentheirrewritingafileandanotherprocessreadingthe
file.Forexample,thecompiler(moreprecisely,theassembler)mayhavetorewriteafile
towhichithaswritepermissioninadirectorytowhichitdoesnothavewritepermission.
Whilethe“.o”fileisbeingwritten,anotherutilitysuchasnm(1)orar(1)mayreadthe
fileandproduceinvalidresultssincethefilehasnotbeencompletelywritten.Currently,
someutilitiesusespecialpurposecodetohandlesuchcaseswhileothersignorethe
problemandforceuserstolivewiththeconsequences.」（９∼１０頁「1.Introduction」
の第２ないし第４段落（９頁２３行∼１０頁４行））
（仮訳）
「これらの性質はデータベースに関する文脈でしばしば議論されるが，より一般的な目的の
アプリケーションのためにも有用なプログラミングパラダイムである。現に用いられているア
ドホックなメカニズムに換えてトランザクションを用いることが可能であるいくつかの状況が
ある。
そうした状況の一つは，複数のファイル又は複数のファイルの複数の部分が原子的に(in
atomicfashion)更新される必要がある時に生ずる。例えば，伝統的なUNIXファイルシステム
はクラッシュに直面した場合の回復可能性を達成するために順番どおりに（書き込みを）行う
という制約を用いている。新しいファイルが生成される時，その新しいファイルがディレクト
リ構造に追加される前にそのｉノードがディスクに書き込まれる。このことによって，そのシ
ステムがその二つのI/Oの間でクラッシュした場合においても，そのディレクトリが無効なi
ノードの参照を含まないことを保証する。実際には，望まれていた効果は，これらの二つの更
新がトランザクションとしての原子性(atomicity)（双方の書き込みが見える(visible)，ある
いは，いずれもが見えない(invisible)，のいずれか）を備えていることである。・・・・・
・・・（中略）・・・・・・・・・・・・
現に用いられているアドホックなメカニズムに換えてトランザクションを用いることが可能
であるような二つ目の状況は，共有ファイルに対する同時的な(concurrent)更新が望まれるが，
論理的なデータの一貫性は維持されていなければならないようなアプリケーションにおいて生
ずる。例えばパスワードファイルを更新するとき，同時的なアクセスを不許可にするためにフ
ァイルロッキングが用いられる。パスワードファイルにおいてトランザクションセマンティッ
クスにより，パスワードデータベースの論理的な一貫性を維持しながら，パスワードファイル
を同時に更新することが許容される。同様に，ファイルをリライトするUNIXユーティリティ
は，それらのファイルのリライトと他のプロセスからの読出しとの間の潜在的な競合状態に直
面している。例えば，コンパイラ（正確にはアセンブラ）は書き込み許可を有しないディレク
トリ中の書き込み許可を有するファイルをリライトしなければならないかもしれない。その
“.o”ファイルが書き込まれている間にnm(1)やar(1)のような他のユーティリティがファイ
ルを読み，ファイルが完全に書き込まれていないために無価値な結果を生成するかもしれない。
現状では，いくつかのユーティリティではこうした状況を取り扱うための特別なコードを用い
るが，他のユーティリティではこの問題は無視されてその帰結を受け入れる(livewiththe
consequences)ことをユーザは強いられている。」
イ「Inthispaper,wepresentasimplelibrarywhichprovidestransactionsemantics
(atomicity,consistency,isolation,anddurability.The4.4BSDdatabaseaccessmethods
havebeenmodifiedtousethislibraryoptionallyprovidingsharedbuffermanagement
betweenapplications,locking,andtransactionsemantics.AnyUNIXprogrammay
transactionprotectitsdatabyrequestingtransactionprotectionwiththedb(3)library
orbyaddingappropriatecallstothetransactionmanager,buffermanager,lockmanager,
andlogmanager.Thelibraryroutinesmaybelinkedintothehostapp1icationandcalledby
subroutineinterface,ortheymayresideinaseparateserverprocess.Theserver
architectureprovidesfornetworkaccessandbetterprotectionmechanisms.」（１０頁「1.
Introduction」の第５段落（５∼１１行））
（仮訳）
「この論文では，トランザクションセマンティクス（原子性，同時性，分離性，永続性）を
提供する簡単なライブラリについて解説する。4.4BSDのデータベースアクセスメソッドは，選
択的にアプリケーション間での共有バッファ管理，ロッキング及びトランザクションセマンテ
ィクスを提供するように，このライブラリを用いて改変された。どのようなUNIXプログラム
もこのdb(3)ライブラリを用いたトランザクション保護を要求するか，又は，トランザクショ
ンマネージャ，バッファマネージャ，ロックマネージャ及びログマネージャに対する適切な呼
出(call)を追加することによって，そのデータに対するトランザクション保護を行う
(transactionprotect)ことができる。これらのライブラリルーチンはホストとなるアプリケー
ションにリンクされてサブルーチンインターフェースにより呼び出されることができる，又は，
分離したサーバープロセスとして存在することができる。このサーバーアーキテクチャにより
ネットワークアクセスとより良い保護メカニズムが提供される。」
ウ「3.2.ModuleArchitecture
Theprecedingsectionsdescribedmodulesformanagingthetransactionlog,locks,anda
cacheofsharedbuffers.Inaddition,weneedtoprovidefunctionalityfortransaction
begin,commit,andabortprocessing,necessitatingatransactionmanager.Inorderto
arbitrateconcurrentaccesstolocksandbuffers,weincludeaprocessmanagementmodule
whichmanagesacollectionofsemaphoresusedtoblockandreleaseprocesses.Finally,in
ordertoprovideasimple,standardinterfacewehavemodifiedthedatabaseaccess
routines(db(3)).ForthepurposesofthispaperwecallthemodifiedpackagetheRecord
Manager.FigureoneshowsthemaininterfacesandarchitectureofLIBTP.
3.2.1.TheLogManager
TheLogManagerenforcesthewrite-aheadloggingprotocol.Itsprimitiveoperationsare
log,log_commit,log_read,log_rollandlog_unroll.Thelogcallperformsabufferedwrite
ofthespecifiedlogrecordandreturnsauniquelogsequencenumber(LSN).ThisLSNmay
thenbeusedtoretrievearecordfromthelogusingthelog_readcall.Theloginterface
knowsverylittleabouttheinternalformatofthelogrecordsitreceives.Rather,alllog
recordsarereferencedbyaheaderstructure,alogrecordtype,andacharacterbuffer
containingthedatatobelogged.Thelogrecordtypeisusedtocalltheappropriateredo
andundoroutinesduringabortandcommitprocessing.WhilewehaveusedtheLogManagerto
providebeforeandafterimagelogging,itmayalsobeusedforanyofthelogging
algorithmsdiscussed.
Thelog_commitoperationbehavesexactlylikethelogoperationbutguaranteesthatthe
loghasbeenforcedtodiskbeforereturning.Adiscussionofourcommitstrategyappears
intheimplementationsection(section4.2).Log_unrollreadslogrecordsfromthelog,
followingbackwardtransactionpointersandcallingtheappropriateundoroutinesto
implementtransactionabort.Inasimilarmanner,log_rollreadslogrecordssequentially
forward,callingtheappropriateredoroutinestorecovercommittedtransactionsaftera
systemcrash.
3.2.2.TheBufferManager
TheBufferManagerusesaPoolofsharedmemorytoprovidealeast-recently-used(LRU)
blockcache.AlthoughthecurrentlibraryprovidesanLRUcache,itwouldbesimpletoadd
alternatereplacementpoliciesassuggestedby[CHOU85]ortoprovidemultiplebuffer
poolswithdifferentpolicies.Transactionsrequestpagesfromthebuffermanagerandkeep
thempinnedtoensurethattheyarenotwrittentodiskwhiletheyareinalogically
inconsistentstate.Whenpagereplacementisnecessary,theBufferManagerfindsan
unpinnedpageandthencheckswiththeLogManagertoensurethatthewrite-aheadprotocol
isenforced.
3.2.3.TheLockManager
TheLockManagersupportsgeneralpurposelocking(singlewriter,multiplereaders)
whichiscurrentlyusedtoprovidetwo-phaselockingandhighconcurrencyB-treelocking,
However,thegeneralpurposenatureofthelockmanagerprovidestheabilitytosupporta
varietyoflockingprotocols.Currently,alllocksareissuedatthegranularityofapage
(thesizeofabufferinthebufferpool)whichisidentifiedbytwo4-byteintegers(afile
idandpagenumber).ThisprovidesthenecessaryinformationtoextendtheLockManagerto
performhierarchicallocking[GRAY76].Thecurrentimplementationdoesnotsupportlocks
atothergranularitiesanddoesnotpromotelocks;theseareobviousfutureadditionsto
thesystem.
Ifanincominglockrequestcannotbegranted,therequestingprocessisqueuedforthe
lockanddescheduled.Whenalockisreleased,thewaitqueueistraversedandanynewly
compatiblelocksaregranted.Locksarelocatedviaafileandpagehashtableandare
chainedbothbyobjectandbytransaction,facilitatingrapidtraversalofthelocktable
duringtransactioncommitandabort.
Theprimaryinterfacestothelockmanagerarelock,unlock,andlock_unlock_all.Lock
obtainsanewlockforaspecificobject.Therearealsotwovariantsofthelockrequest,
lock_upgradeandlock_downgrade,whichallowthecallertoatomicallytradealockofone
typeforalockofanother.Unlockreleasesaspecificmodeoflockonaspecificobject.
Lock_unlock_allreleasesallthelocksassociatedwithaspecifictransaction.
3.2.4.TheProcessManager
TheProcessManageractsasauser-levelschedulertomakeprocesseswaitonunavailable
locksandpendingbuffercacheI/O.Foreachprocess,asemaphoreismaintaineduponwhich
thatprocesswaitswhenitneedstobedescheduled.Whenaprocessneedstoberun,its
semaphoreiscleared,andtheoperatingsystemreschedulesit.Nosophisticatedscheduling
algorithmisapplied;ifthelockforwhichaprocesswaswaitingbecomesavailable,the
processismaderunnable.Itwouldhavebeenpossibletochangethekernel'sprocess
schedulertointeractmoreefficientlywiththelockmanager,butdoingsowouldhave
compromisedourcommitmenttoauser-levelpackage.
3.2.5.TheTransactionManager
TheTransactionManagerprovidesthestandardinterfaceoftxn_begin,txn_commit,and
txn-abort,Itkeepstrackofallactivetransactions,assignsuniquetransaction
identifiers,anddirectstheabortandcommitprocessing.Whenatxn_beginisissued,the
TransactionManagerassignsthenextavailabletransactionidentifier,allocatesa
per-processtransactionstructureinsharedmemory,incrementsthecountofactive
transactions,andreturnsthenewtransactionidentifiertothecallingprocess.The
in-memorytransactionstructurecontainsapointerintothelocktableforlocksheldby
thistransaction,thelastlogsequencenumber,atransactionstate(idle,running,
aborting,orcommitting),anerrorcode,andasemaphoreidentifier.
Atcommit,theTransactionManagercallslog_committorecordtheendoftransactionand
toflushthelog.ThenitdirectstheLockManagertoreleasealllocksassociatedwiththe
giventransaction.Ifatransactionaborts,theTransactionManagercallsonlog_unrollto
readthetransaction'slogrecordsandundoanymodificationstothedatabase.Asinthe
commitcase,itthencallslock_unlock_alltoreleasethetransaction'slocks.
3.2.6.TheRecordManager
TheRecordManagersupportstheabstractionofreadingandwritingrecordstoadatabase.
Wehavemodifiedthedatabaseaccessroutinesdb(3)[BSD91]tocallthelog,lock,and
buffermanagers.Inordertoprovidefunctionalitytoperformundoandredo,theRecord
Managerdefinesacollectionoflogrecordtypesandtheassociatedundoandredoroutines.
TheLogManagerperformsatablelookupontherecordtypetocalltheappropriateroutines.
Forexample,theB-treeaccessmethodrequirestwologrecordtypes:insertanddelete.A
replaceoperationisimplementedasadeletefollowedbyaninsertandislogged
accordingly.」（１２頁４１行∼１４頁３９行）
（仮訳）
「３．２．モジュールアーキテクチャ
前のセクションにおいて，トランザクションログ，ロック，共有バッファキャッシュの管理
を行うためのモジュールが記述された。それに加えて，トランザクションの開始処理，コミッ
ト処理及びアボート処理の機能が提供されなければならず，トランザクションマネージャが不
可欠である。ロックとバッファに対する競合する同時的なアクセスを調停するために，プロセ
スのブロックとリリースに用いられるセマフォの集合を管理するプロセス管理モジュールを含
めることとする。最後に簡単で標準化されたインターフェースを提供するために，データベー
スアクセスルーチン(db(3))を変更した。この論文においては，この変更されたパッケージを
レコードマネージャと呼ぶこととする。図１にLIBTPの主なインターフェースとアーキテクチ
ャが示されている。
３．２．１．ログマネージャ
ログマネージャはライトアヘッドロギングプロトコルを強制する。そのプリミティブ操作は
log，log_commit，log_roll，log_unrollである。log呼出は，特別なログレコードに対するバ
ッファされた書き込みを実行して，唯一のログ順序番号(LSN)を返す。このLSNはlog_read呼
出を用いてログからレコードを獲得するために用いられる。このlogインターフェースは，そ
れが受け取るログレコードの内部形式についてはほとんど知らない。むしろ全てのログレコー
ドは，ヘッダの構造，ログレコードの種類とログとして書き込まれるべきデータを含むキャラ
クタバッファによって参照される。このログレコードの種別は，アボート処理とコミット処理
の間に適切なredoとundoのルーチンを呼び出すために用いられる。ここではログマネージャ
を用いて事前及び事後のログを提供しているが，議論されたロギングアルゴリズムのいずれを
用いることも可能であろう。
log_commit操作は，確かにlog操作と同じように振舞うが，戻る前にディスクへの書き込み
が強制される。私たちが採用するコミット戦略についての議論は実装に関する節（section
4.2）において行う。Log_unrollはログからログレコードを読み，後ろ向きのトランザクショ
ンポインタを伴って，トランザクションのアボートを実装した適切なundoルーチンを呼び出
す。同様なやり方で，Log_rollはログレコードを前向きに連続して読み，システムのクラッシ
ュ後に既にコミット済みトランザクションの回復を行うための適切なredoルーチンを呼び出
す。
３．２．２．バッファマネージャ
バッファマネージャは，共有メモリのプールを使ってleast-recently-used(LRU)のブロック
キャッシュを提供する。現在のライブラリはＬＲＵキャッシュを提供しているが，［CHOU85］
に示唆されるように代替の置換戦略を加えたり，異なる戦略による複数のバッファプールを提
供することは簡単であろう。トランザクションはバッファマネージャにページを要求し，これ
らを常駐化して論理的に非定常状態にある間はディスクへの書き込みが行われないことを保証
する。ページの置換が必要なときは，バッファマネージャは常駐化されていないページを探し
てそしてログマネージャにおいてライトアヘッドプロトコルが確実に強制されるようにチェッ
クする。
３．２．３．ロックマネージャ
ロックマネージャは，２相ロッキングと高い並列度を有するB-treeロッキングを提供する
ために用いられる一般的な目的のロッキング（単一書き込み者と複数の読出し者）をサポート
する。しかしながら，ロックマネージャが一般的な目的のものであるという性質によって，さ
まざまなロッキングプロトコルをサポートする能力が提供される。現状では，全てのロックは
２つの４バイト整数（ファイルidとページ番号）によって識別されるページの粒度（バッフ
ァプールのバッファの大きさ）で発行される。これは，ロックマネージャを階層的ロッキング
を実行するように拡張するための必要な情報を提供する。現在の実装では他の粒度のロックを
サポートしていないし，ロックのプロモートを行わない。・・・・・（中略）・・・・
３．２．５．トランザクションマネージャ
トランザクションマネージャは，txn_begin，txn_commit，txn_abortの標準インターフェー
スを提供する。それは，全てのアクティブなトランザクションの進路を追い，唯一のトランザ
クション識別子を割当て，そしてアボート処理とコミット処理を指揮する。txn_beginが発行
されるとき，トランザクションマネージャは次に利用可能なトランザクション識別子を割当て，
共有メモリ上にプロセス毎のトランザクション構造をアロケートし，アクティブトランザクシ
ョン数をインクリメントし，呼出元プロセスに対して新しいトランザクション識別子を返す。
メモリ内のトランザクション構造は，そのトランザクションによって保持されているロックの
ためのロックテーブルへのポインタ，過去最近のログ順序番号，トランザクションの状態（ア
イドル，実行中，アボート処理中，コミット処理中），エラーコード及びセマフォアの識別子
を含む。
コミットの際，トランザクションマネージャはlog_commitを呼び出してトランザクション
の終了を記録し，ログをディスクへ書き出す(flush)。そして，ロックマネージャにそのトラ
ンザクションに関連して保持された全てのロックを開放するように指示する。もしトランザク
ションがアボートしたら，トランザクションマネージャはlog_unrollをコールしてトランザ
クションのログレコードを読み，データベースになされた変更についてundoする。それから，
コミットの場合と同様に，トランザクションのロックを開放するためにlock_unlock_allを呼
び出す。
３．２．６．レコードマネージャ
レコードマネージャは抽象化されたデータベースへのレコードの読出しと書き込みをサポー
トする。データベースアクセスルーチンのdb(3)がログ，ロック及びバッファの各マネージャ
を呼び出すように変更された。undoとredoを実行する機能を提供するために，レコードマネ
ージャはログレコードの種別と関係するundoとredoのルーチンを定義する。ログマネージャ
がそのレコード種別をテーブルから探し，適切なルーチンを呼び出す。例えばB-treeアクセ
スメソッドは２つのログレコード種別，挿入と削除，を必要とする。置き換え操作は挿入が引
き続くような削除として実装され，そのようにログに記録される。」
エ「3.3.ApplicationArchitectures
ThestructureofLIBTPallowsapplicationdesignerstotradeoffperformanceand
protection.SincealargeportionofLIBTP'sfunctionalityisprovidedbymanaging
structuresinsharedmemory,itsstructuresaresubjecttocorruptionbyapplicationswhen
thelibraryislinkeddirectlywiththeapplication.Forthisreason,LIBTPisdesignedto
allowcompilationintoaseparateserverprocesswhichmaybeaccessedviaasocket
interface.InthiswayLIBTP'sdatastructuresareprotectedfromapplicationcode,but
communicationoverheadisincreased.Whenapplicationsaretrusted,LIBTPmaybecompiled
directlyintotheapplicationprovidingimprovedperformance.Figurestwoandthreeshow
thetwoalternateapplicationarchitectures.
TherearepotentiallytwomodesinwhichonemightuseLIBTPinaserverbased
architecture.Inthefirst,theserverwouldprovidethecapabilitytorespondtorequests
toeachofthelowlevelmodules(lock,log,buffer,andtransactionmanagers).
Unfortunately,theperformanceofsuchasystemislikelytobeblindinglyslowsince
modifyingpieceofdatawouldrequirethreeorpossiblyfourseparatecommunications:one
tolockthedata,onetoobtainthedata,onetologthemodification,andpossiblyoneto
transmitthemodifieddata.Figurefourshowstherelativeperformanceforretrievinga
singlerecordusingtherecordlevelcallversususingthelowerlevelbuffermanagement
andlockingcalls.The2:1ratioobservedinthesingleprocesscasereflectsthe
additionaloverheadofparsingeightcommandsratherthanonewhilethe3:1ratioobserved
intheclient/serverarchitecturereflectsboththeparsingandthecommunication
overheard.Althoughtheremaybeapplicationswhichcouldtoleratesuchperformance,it
seemsfarmorefeasibletosupportahigherlevelinterface,suchasthatprovidedbya
querylanguage(e.g.SQL[SQL86]).
AlthoughLIBTPdoesnothaveanSQLparser,wehavebuiltaserverapplicationusingthe
toolkitcommandlanguage(TCL)[OUST90].Theserversupportsacommandlineinterface
similartothesubroutineinterfacedefinedindb(3).SinceitisbasedonTCL,itprovides
controlstructuresaswell.」（１４頁４０行∼１５頁１１行）
（仮訳）
「３．３．アプリケーションアーキテクチャ
LIBTPの構造によって，アプリケーションプログラム設計者が性能と保護のトレードオフを
行えるようになる。LIBTPの機能の大部分は共有メモリの構造を管理することによって与えら
れるものであり，そうした構造はこのライブラリがアプリケーションにリンクされたときには，
そのアプリケーションにおける『なまり』(corruption)に支配される。このため，LIBTPはソ
ケットインターフェースを通じてアクセスできるような分離したサーバプロセスとしてのコン
パイレーションを許容するように設計されている。このようにすると，LIBTPのデータ構造は
アプリケーションコードから保護されるが，通信のオーバーヘッドは増加する。アプリケーシ
ョンが信頼できるときには，性能を向上させるためにLIBTPをアプリケーション中に直接組み
込むようにコンパイルすることができる。図２と図３にはその二つの代替的なアプリケーショ
ンアーキテクチャが示されている。
・・・・・・（中略）・・・・・・・・
そのような性能を許容できるようなアプリケーションがあるのか否かはともかく，あたかも質
問言語において提供されているかのような高いレベルのインターフェースをサポートすること
はとても実現性が高い。LIBTPはSQLパーザを備えていないが，私たちはツールキットコマン
ド言語(TCL)を用いてサーバアプリケーションを作成した。そのサーバはdb(3)において定義さ
れたサブルーチンインターフェースに類似したコマンドラインのインターフェースをサポート
する。
・・・・・・・・・・（以下略）・・・・・・・」
オ「4.4.TransactionProtectedAccessMethods
TheB-treeandlengthrecno(recordnumber)accessmethodshavebeenmodifiedtoprovide
transactionprotection.Whereasthepreviouslypublishedinterfacetotheaccessroutines
hadseparateopencallsforeachoftheaccessmethods,wenowhaveanintegratedopencall
withthefollowingcallingconventions:
DB*dbopen(constchar*file,intflags,intmode,DBTYPEtype,
intdbflags,constvoid*openinfo)
wherefileisthenameofthefilebeingopened,flagsandmodearethestandardarguments
toopen(2),typeisoneoftheaccessmethodtypes,dbflagsindicatesthemodeofthe
bufferpoolandtransactionprotection,andopeninfoistheaccessmethodspecific
information.Currently,thepossiblevaluesfordbflagsareDB_SHAREDandDB_TPindicating
thatbuffersshouldbekeptinasharedbufferpoolandthatthefileshouldbetransaction
protected.
Themodificationsrequiredtoaddtransactionprotectiontoanaccessmethodarequite
simpleandlocalized.
1.Replacefileopenwithbuf_open.
2.Replacefilereadandwritecallswithbuffermanagercalls(buf_get,buf_unpin).
3.Precedebuffermanagercallswithanappropriate(readorwrite)lockcall.
4.Beforeupdates,issuealoggingoperation.
5.Afterdatahavebeenaccessed,releasethebuffermanagerpin.
6.Provideundo/redocodeforeachtypeoflogrecorddefined.
ThefollowingcodefragmentsshowhowtotransactionprotectseveralupdatestoaB-tree.
Intheunprotectedcase,anopencallisfollowedbyareadcalltoobtainthemeta-datafor
theB-tree.Instead,weissueanopentothebuffermanagertoobtainafileidandabuffer
requesttoobtainthemeta-dateasshownbelow.
char*path;
intfid,flags,len,mode;
/*Obtainafileidwithwhichtoaccessthebufferpool*/
fid=buf_open(path,flags,mode);
/*Readthemetadata(page0)fortheB-tree*/
if(tp_lock(fid,0,READ_LOCK))
returnerror;
meta_data_ptr=buf_get(fid,0,BF_PIN,&len);
TheBF_PINargumenttobuf_getindicatesthatwewishtoleavethispagepinnedinmemory
sothatitisnotswappedoutwhileweareaccessingit.Thelastargumenttobuf_get
returnsthenumberofbytesonthepagethatwerevalidsothattheaccessmethodmay
initializethepageifnecessary.
Next,considerinsertingarecordonaparticularpageofaB-tree.Intheunprotected
case,wereadthepage,call_bt_insertat,andwritethepage.Instead,welockthepage,
requestthebuffer,logthechange,modifythepage,andreleasethebuffer.
intfid,len,pageno;/*Identifiesthebuffer*/
intindex;/*Locationatwhichtoinsertthenewpair*/
DBT*keyp,*datap;/*Key/Datapairtobeinserted*/
DATUM*d;/*Key/datastructuretoinsert*/
/*Lockandrequestthebuffer*/
if(tp_lock(fid,pageno,WRITE_LOCK))
returnerror;
buffer_ptr=buf_get(fid,pageno,BF_PIN,&len);
/*Logandperformtheupdate*/
log_insdel(BTREE_INSERT,fid,pageno,keyp,datap);
_bt_insertat(buffer_ptr,d,index);
buf_unpin(buffer_ptr);
Succinctly,thealgorithmforturningunprotectedcodeintoprotectedcodeistoreplace
readoperationswithlockandbuf-getoperationsandwriteoperationswithlogand
buf_unpinoperations.」（１７頁２６行∼１８頁末行）
（仮訳）
「４．４．トランザクションによる保護を受けるアクセスメソッド
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呼出の引数であるBF_PINは，アクセスを行っている間にこのページをスワップアウ
トしないように，このページをメモリに常駐化したままとすることを望んでいることを指示す
る。buf_getの最後の引数は，必要に応じてアクセスメソッドにおいて初期化することができ
るように有効とされたページのバイト数を返す。
次にB-treeの特定のページにレコードを挿入してみよう。保護がない場合であれば，ペー
ジを読み，_bt_insertatを呼出し，ページを書き出すが，ここではそうせずに，ページをロッ
クし，バッファを要求し，ログに変更を記録し，ページを変更し，そしてバッファをリリース
する。
intfid,len,pageno;（以下，省略）
簡単にいえば，保護されていないコードを保護されたコードに改良する手順は，read操作を
lockとbuf_get操作に置き換え，write操作をlogとbuf_unpin操作で置き換えることであ
る。」と，記載されている。
すなわち，引用例には，
「伝統的なUNIXファイルシステムにおける新しいファイルの生成等のように複数のファイ
ルの複数の部分が原子的に更新される必要がある場合や共有ファイルに対する同時的な更新が
望まれる一方で論理的なデータの一貫性を維持する必要が生ずる場合に，ライブラリに属する
ルーチンに対する適切な呼出を追加することによって，トランザクションセマンティクスを提
供するための該ライブラリ（LIBTP）であって，
前記ライブラリがログマネージャ，バッファマネージャ，ロックマネージャ，トランザクシ
ョンマネージャの各々を実現するルーチンを含むものであって，これらのルーチンにおいては，
ログマネージャの実行によりコミット処理及びアボート処理の際参照される事前及び事後のロ
グ取得処理を行い，トランザクションマネージャ等を実現する各ルーチンの実行により
txn_commitプリミティブによって起動されるコミット処理を行い，トランザクションマネージ
ャ等を実現する各ルーチンの実行によりtxn_abortプリミティブによって起動されるアボート
処理を行うライブラリを含むことを特徴とするファイルの更新処理方法」に関する発明が開示
されている（引用発明）。
(2)本願発明と引用発明との一致点及び相違点の認定
本願発明と，引用発明とを対比すると，
両者は共に，コンピュータプログラムのトランザクション処理に関するものであって，
引用発明の「伝統的なUNIXファイルシステム」が本願発明の「ネイティブファイルシステ
ム」に相当し，
引用発明における「新しいファイルの生成等のように複数のファイルの複数の部分が原子的
に更新される必要がある場合や共有ファイルに対する同時的な更新が望まれる一方で論理的な
データの一貫性を維持する必要が生ずる場合」に実行されているファイル生成等の具体的なフ
ァイル操作は，トランザクションの保護の対象となるファイル操作を含む実行ルーチンである
ので，これは，本願発明の「ネイティブファイルシステムにおけるファイル及びディレクトリ
の操作」を含むルーチンに対応するとともに「関連実行ルーチン」に相当し，
引用発明における「ライブラリ（LIBTP）」は，ネイティブファイルシステムに必要に応じ
てトランザクションセマンティクスを追加あるいは提供するためのコンピュータプログラムル
ーチンの集合であるので，これは本願発明の「ライブラリ」に相当し，
引用発明におけるライブラリを構成するルーチン（あるいはルーチンファミリ）である「ロ
グマネージャ，バッファマネージャ，ロックマネージャ，トランザクションマネージャの各々
を実現するルーチン」の各々は，本願発明の「ルーチン」あるいは「ルーチンファミリ」に相
当し，又，引用発明においてもこれらのルーチンが複数あり，本願発明と同様に，「セット」
を構成していると言うことができる。
引用発明の「コミット処理及びアボート処理の際参照される事前及び事後のログを取得する
処理」は，トランザクション処理におけるログ取得の処理であるので，本願発明の「ファイル
又はディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命令を含
む実行ルーチン」に相当し，
引用発明の「txn_commitプリミティブによって起動されるコミット処理」は，トランザクシ
ョン処理におけるコミット処理であるので，本願発明の「関連実行ルーチンの結果をコミット
させるコンピュータ命令を含む終了ルーチン」に相当し，
引用発明の「txn_abortプリミティブによって起動されるアボート処理」は，トランザクシ
ョン処理におけるロールバック処理であるので，本願発明の「関連実行ルーチンの結果をロー
ルバックさせるコンピュータ命令を含むアンドゥルーチン」に相当している。
したがって，両者は共に，
ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作のセットへトラ
ンザクションセマンティクスを追加するためのコンピュータプログラムライブラリであって，
前記ライブラリが１つ以上のルーチンファミリのセットを有し，このようなルーチンファミリ
の各々が，
(a)このようなネイティブファイルまたはディレクトリ動作をロールバックするために必要な
情報を記憶するコンピュータ命令を含む実行ルーチンと，
(b)コンピュータに，関連実行ルーチンの結果をコミットさせるコンピュータ命令を含む終了
ルーチンと，
(c)コンピュータに，関連実行ルーチンの結果をロールバックさせるコンピュータ命令を含む
アンドゥルーチンと，
を有することを特徴とするコンピュータプログラムライブラリ
である点で一致する。
ただ，
相違点(1)
本願発明においては，「ルーチンファミリの各々が最低１つのネイティブファイルまたはデ
ィレクトリ動作と関連し，そして最低１つのネイティブファイルまたはディレクトリ動作の代
わりに呼び出されるように構成され」，(a)の実行ルーチンにおいて「ファミリの関連ネイテ
ィブファイルまたはディレクトリ動作の１つと機能的に同等である結果をコンピュータに提供
させる」とともに，このようなルーチンファミリ「の各々」が上記の(a)から(c)の処理を実現
するルーチンを有する，すなわち，ネイティブファイルまたはディレクトリ動作についてのト
ランザクションを実現するために必要な処理を呼び出す際ネイティブファイルシステム上でネ
イティブファイル又はディレクトリ操作の呼出のためのAPIをそのまま用いて，かつ，ライブ
ラリに属するルーチンの実行によってネイティブファイル又はディレクトリ動作の機能を実現
するように構成されているのに対し，引用発明においては，ネイティブファイル又はディレク
トリ操作の呼出のためのAPIとは異なった追加されたAPI(txn_commitプリミティブ等)を用い
るように構成され，ライブラリに属するルーチンの実行ではなくネイティブファイルシステム
の実行によってネイティブファイル又はディレクトリ動作の機能を実現するように構成されて
いる点，
及び，
相違点(2)
本願発明は「コンピュータ読取り可能な記録媒体」に関する発明であるのに対して，引用発
明はコンピュータプログラムライブラリに関する発明である点，
で両者は相違している。
(3)相違点についての判断
ア相違点(1)について
例えば，特開平６−１４９６３３号公報（甲３）や特開平６−３５７８２号公報（甲４）に
見られるように，一般にシステムコールを用いて実現されている機能の拡張や機能の追加を行
うにあたって，システムコールのAPIと同じAPIによって呼び出されそのシステムコールの機
能と拡張機能とを実現するように構成されたルーチンを用いることによって，システムコール
の呼び出し側であるアプリケーションの修正の手間を軽減あるいは不要にする技術は周知技術
である。
また，引用発明においてもトランザクションセマンティクスの導入という機能追加を行うに
あたってアプリケーション修正の手間を軽減することは当業者にとって自明の事項である。
又，一般に，複数のルーチンにより実現されている機能を１つのルーチンで実現することは
当業者が通常行うことであって，このことはシステムコールを実現するルーチンについても同
様であると言うことができる。
してみると，引用発明においても，こうした周知技術を採用して，ネイティブファイルシス
テム上でネイティブファイル又はディレクトリ操作の呼出のためのAPIをそのまま用いること
を可能とするために，ライブラリに属するルーチンの実行によってネイティブファイル又はデ
ィレクトリ動作の機能を実現するように構成して本願発明のようにすることは，当業者が適宜
選択設計すべきことであり，その効果も当業者が通常予測すべき範囲のものにすぎないもので
ある。
したがって，相違点(1)は格別の相違点であるものと言うことはできない。
イ相違点(2)について
一般に，コンピュータ上でコンピュータプログラムライブラリを実行するためには，該プロ
グラムライブラリをコンピュータ読取り可能な記録媒体に記憶させて実行させなければならな
いものである。したがって，相違点(2)も格別の相違点であるものとは言えない。
したがって，本願発明は，引用発明から当業者が容易に発明することができたものである。
(4)審決の「むすび」
以上の通りであるので，本願発明は，引用発明から当業者が容易に発明をすることができた
ものであり，特許法２９条２項の規定により特許を受けることができない。
第３当事者の主張の要点
１原告主張の審決取消事由の要点
審決は，以下のとおり，引用発明の認定及び本願発明と引用発明の一致点の認定
をそれぞれ誤り，また，両発明の相違点を看過した結果，本願発明が特許法２９条
２項の規定により特許を受けることができないと判断したものであるから，取り消
されるべきである。
(1)前提となる技術内容（データベースシステムとファイルシステム）等につ
いて
ア(ｱ)一般に，コンピュータシステムは，データベースシステムとファイルシ
ステムに分類され，前者においては，データはデータベースに保管され，後者にお
いては，データはファイルに保管される。また，前者におけるトランザクションは，
データ動作（データの読み出し及び書き込み。引用例に記載されているものはこれ
に相当する。）に関するものであり，後者におけるトランザクションは，ファイル
動作（ファイルの作成，削除，名前変更等。本願発明の「ネイティブファイルシス
テムのネイティブファイルおよびディレクトリ動作」はこれに相当する。）に関す
るものである。
(ｲ)ａこの点を敷衍すると，本件出願に係る平成１６年６月１６日付け手続補
正書（甲６）による補正後の明細書（特許請求の範囲につき甲６，その余につき甲
５。以下「本願明細書」という。なお，これを引用する場合に掲記する引用箇所は，
甲５に係るものである。）の記載（６頁２１∼２４行）によれば，複合データ処理
アプリケーションの操作動作には，「ファイル（操作）動作」と「データ（操作）
動作」の２つが存在し，技術的に異なるものとして区別されていることが明らかで
あるところ，本願明細書及び本件出願に係る図面（甲５）においては，本願発明の
実施例として，「ファイルおよびディレクトリ動作」（なお，「ディレクトリ」と
は，ファイルの集合を表す単位である。）が，「データ動作」と明確に区別して記
載されている。したがって，本願発明の「ネイティブファイルおよびディレクトリ
動作」は，「データ動作」を包含するものではない。
ｂこれに対し，引用例においては，「ファイルおよびディレクトリ動作」にト
ランザクションセマンティクスを追加することについての記載や，そのためのルー
チンファミリについての記載はない。
イ従来，トランザクションは，データベースシステムにおいて利用されており，
ファイルシステムにおいては利用されていなかった（多くのオペレーティングシス
テムは，本来的に，ファイル及びディレクトリ動作のためのトランザクション処理
を提供することができなかった。）。
ウ本願発明の目的は，データベースシステムにおいて発展してきたトランザク
ション処理技術をファイルシステムに適用することにあり，本願発明は，ファイル
及びディレクトリ動作にトランザクションセマンティクスを付与するものであると
ころ，引用例には，トランザクション処理技術をファイルシステムに適用すること
についての記載がない。
(2)取消事由１（引用発明の認定の誤り）
審決は，「伝統的なUNIXファイルシステムにおける新しいファイルの生成等の
ように複数のファイルの複数の部分が原子的に更新される必要がある場合や共有フ
ァイルに対する同時的な更新が望まれる一方で論理的なデータの一貫性を維持する
必要が生ずる場合に，ライブラリに属するルーチンに対する適切な呼出を追加する
ことによって，トランザクションセマンティクスを提供するための該ライブラリ
（LIBTP）であって，前記ライブラリがログマネージャ，バッファマネージャ，ロ
ックマネージャ，トランザクションマネージャの各々を実現するルーチンを含むも
のであって，これらのルーチンにおいては，ログマネージャの実行によりコミット
処理及びアボート処理の際参照される事前及び事後のログ取得処理を行い，トラン
ザクションマネージャ等を実現する各ルーチンの実行によりtxn_commitプリミテ
ィブによって起動されるコミット処理を行い，トランザクションマネージャ等を実
現する各ルーチンの実行によりtxn_abortプリミティブによって起動されるアボー
ト処理を行うライブラリを含むことを特徴とするファイルの更新処理方法」に関す
る発明を，引用発明と認定したが，以下のとおり，この認定は誤りである。
ア審決は，引用発明を，「伝統的なUNIXファイルシステムにおける新しいフ
ァイルの生成等のように複数のファイルの複数の部分が原子的に更新される必要が
ある場合」（以下「審決が認定した第１の場合」という。）と「共有ファイルに対
する同時的な更新が望まれる一方で論理的なデータの一貫性を維持する必要が生ず
る場合」（以下「審決が認定した第２の場合」という。）に，トランザクションセ
マンティクスを提供するためのライブラリ（ＬＩＢＴＰ）の各ルーチンを実行する
ものと認定した。
しかしながら，審決が認定した第１の場合及び第２の場合は，トランザクション
が必要な一般的な場合とそれに対する従来の解決方法についての記載である引用例
の「１．序論」（なお，以下，外国語で作成された書証中の記載の引用及びその箇
所の特定は，翻訳文による。）に記載され，他方，引用例の「３．アーキテクチ
ャ」，「４．実装」等には，引用例の主要なテーマである，データベースシステム
に対するデータ動作にトランザクションセマンティクスを付与する技術であるライ
ブラリ（ＬＩＢＴＰ）が記載されているにとどまり（したがって，ファイル及びデ
ィレクトリ動作にトランザクションセマンティクスを付与するものではない。），
「１．序論」に記載された内容と，「３．アーキテクチャ」，「４．実装」等に記
載された内容とを結合した１つの発明は，引用例のどこにも記載されていない
（「１．序論」には，従来技術の問題点や引用発明（ライブラリ（ＬＩＢＴＰ））
の目的は記載されているが，審決が認定した引用発明（ライブラリ（ＬＩＢＴ
Ｐ））の必須の構成は記載されていないし，「１．序論」に記載された構成と「３．
アーキテクチャ」，「４．実装」等に記載された構成とが技術的に関連して所定の
機能を提供するものとも考えられない。）のであるから，両者を結合した１つの発
明を引用発明と認定することは不当である。
なお，被告は，「引用例の『３．アーキテクチャ』，『４．実装』等の記載は，
『１．序論』の記載を受け，『従来のＵＮＩＸファイルシステム』にトランザクシ
ョンセマンテイクスを付与する技術について論じたものである」と主張するが，引
用例には，「従来のＵＮＩＸファイルシステム」にトランザクションセマンティク
スを付与する技術は記載されていない。
また，被告の主張するとおり，引用例の「３．アーキテクチャ」，「４．実装」
等の記載が「１．序論」の記載を受けたものであるならば，被告は，引用例に１つ
の発明が記載されていないことを自認していることになる。
イ引用例の「１．序論」に記載された内容と，「３．アーキテクチャ」，「４．
実装」等に記載されたライブラリ（ＬＩＢＴＰ）とは，以下のとおり，技術的な整
合性を有しないから，両者を結合しても，１つの発明を構成することはできない。
(ｱ)審決が認定した第１の場合は，引用例の「１．序論」の第３段落の記載に
相当するものであるが，同段落には，審決が認定した第１の場合に，「（書き込み
についての）順序制約（orderingconstraints）を使用して，クラッシュに直面し
た場合の回復可能性を達成する」と記載されており，トランザクションセマンティ
クスを提供するためのライブラリ（ＬＩＢＴＰ）の各ルーチンを実行するとは記載
されていない。
(ｲ)審決が認定した第２の場合は，引用例の「１．序論」の第４段落の記載に
相当するものであるが，同段落には，審決が認定した第２の場合の例として，「パ
スワードファイルが更新される場合」及び「ファイル書き換えとファイルを読み取
る別のプロセス間の潜在的競合条件に直面」したとき（これらは，いずれも，デー
タベースにおける処理を問題とするものである。）が挙げられ，トランザクション
セマンティクスを提供するためのライブラリ（ＬＩＢＴＰ）の各ルーチンを実行す
るとは記載されていない。
ウ審決は，引用発明を，「伝統的なＵＮＩＸファイルシステムにおける新しい
ファイルの生成等のように複数のファイルの複数の部分が原子的に更新される必要
がある場合・・・に，・・・トランザクションセマンティクスを提供するための該
ライブラリ（ＬＩＢＴＰ）であって，・・・を行うライブラリを含むことを特徴と
するファイルの更新処理方法」に関する発明と認定した。
しかしながら，引用例には，新しいファイルの生成に対してトランザクションセ
マンティクスを提供するためのライブラリ（ＬＩＢＴＰ）についての記載はないし，
また，引用例の「１．序論」の第５段落の記載によれば，引用例に開示されている
ＬＩＢＴＰは，４．４ＢＳＤ(BerkeleySoftwareDistribution)データベースにお
けるデータ動作に対してトランザクションセマンティクスを提供するものであり
（これは，ＬＩＢＴＰについて説明する甲７の論文（１９９９年（平成１１年）６
月にモントレーで開催された「１９９９年ＵＳＥＮＩＸ年次技術会議」の予稿集に
収載されたMargoSeltzerらによる「BerkeleyDB」と題するもの。以下「甲７論
文」という。）の記載（２頁３０行∼３頁３行）からも明らかである。），ファイ
ルシステム，すなわち，ファイル及びディレクトリ動作に対してトランザクション
セマンティクスを提供するものではないから，引用例に「ファイルの更新処理方
法」が記載されているとはいえない。
なお，被告は，「引用例の記載によれば，当該ライブラリ（ＬＩＢＴＰ）は，Ｕ
ＮＩＸプログラムにトランザクション保護を提供するために適切なコールを追加す
るものであるから，これを当該データベースアクセス法に限定する必要はない」と
主張するが，引用例には，ライブラリ（ＬＩＢＴＰ）をデータベースアクセス法に
限定する必要はないとの記載はないし，そのような事実を認めることもできない。
したがって，審決の上記認定が誤りであることは明らかである。
(3)取消事由２（本願発明と引用発明の一致点の認定の誤り）
ア審決は，本願発明と引用発明とを対比するに当たって，「引用発明における
『新しいファイルの生成等のように複数のファイルの複数の部分が原子的に更新さ
れる必要がある場合や共有ファイルに対する同時的な更新が望まれる一方で論理的
なデータの一貫性を維持する必要が生ずる場合』に実行されているファイル生成等
の具体的なファイル操作は，トランザクションの保護の対象となるファイル操作を
含む実行ルーチンであるので，これは，本願発明の『ネイティブファイルシステム
におけるファイル及びディレクトリの操作』を含むルーチンに対応するとともに
『関連実行ルーチン』に相当し，」と認定したが，以下のとおり，この認定は誤り
である。
(ｱ)審決の上記認定中，「実行されているファイル生成等の具体的なファイル
操作」に関し，審決が認定した第１の場合及び第２の場合は，引用例の「１．序
論」に記載されているところ，同箇所には，トランザクションが必要な場合及び従
来の解決方法が記載されているのみであるから，これだけでは，審決が認定した第
１の場合及び第２の場合における「実行されているファイル生成等の具体的なファ
イル操作」が何を意味するのか不明である。また，仮に，「実行されているファイ
ル生成等の具体的なファイル操作」が引用例に記載されたＬＩＢＴＰを意味するの
であるとしても，これは，データベースに対するデータ動作にトランザクションセ
マンティクスを提供するものであり，ファイル及びディレクトリ動作（ファイル生
成等の具体的なファイル操作）にトランザクションセマンティクスを提供するもの
ではない。したがって，引用例に，このような「ファイル生成等の具体的なファイ
ル操作」が記載されているとはいえない。
(ｲ)審決の上記認定中，「ファイル生成等の具体的なファイル操作は，トラン
ザクションの保護の対象となるファイル操作を含む実行ルーチンであるので，」に
関しても，上記(ｱ)のとおり，「ファイル生成等の具体的なファイル操作」が何を
意味するのか不明であるし，仮に，引用例に記載されたＬＩＢＴＰを意味するので
あるとしても，これは，ファイル操作にトランザクション保護を与えるものではな
い。
(ｳ)審決の上記認定中，「ファイル生成等の具体的なファイル操作は，・・・
本願発明の『ネイティブファイルシステムにおけるファイル及びディレクトリの操
作』を含むルーチンに対応するとともに『関連実行ルーチン』に相当し，」に関し
ても，上記(ｱ)のとおり，「ファイル生成等の具体的なファイル操作」が何を意味
するのか不明であるし，引用例に記載されたＬＩＢＴＰとも異なるものであるから，
このようなファイル操作が，本願発明の「ネイティブファイルシステムにおけるフ
ァイル及びディレクトリの操作」に対応すると認定することはできない。
イ審決は，本願発明と引用発明とを対比するに当たって，「引用発明における
『ライブラリ（LIBTP）』は，ネイティブファイルシステムに必要に応じてトラン
ザクションセマンティクスを追加あるいは提供するためのコンピュータプログラム
ルーチンの集合であるので，これは本願発明の『ライブラリ』に相当し，」と認定
した。
しかしながら，引用発明のライブラリ（ＬＩＢＴＰ）は，引用例の「１．序論」
の第５段落において説明されているところ，それによれば，データベース処理に対
してトランザクションセマンティクスを提供するものであり，ネイティブファイル
又はディレクトリ動作に対してトランザクションセマンティクスを提供するもので
はないから，同ライブラリ（ＬＩＢＴＰ）は，本願発明の「ライブラリ」に相当す
るものではない。
したがって，審決の上記認定は誤りである。
ウ審決は，本願発明と引用発明とを対比するに当たって，「引用発明における
ライブラリを構成するルーチン（あるいはルーチンファミリ）である『ログマネー
ジャ，バッファマネージャ，ロックマネージャ，トランザクションマネージャの各
々を実現するルーチン』の各々は，本願発明の『ルーチン』あるいは『ルーチンフ
ァミリ』に相当し，又，引用発明においてもこれらのルーチンが複数あり，本願発
明と同様に，『セット』を構成していると言うことができる。」と認定したが，以
下のとおり，この認定は誤りである。
(ｱ)引用例の「３．２．モジュールアーキテクチャ」には，ログマネージャ，
バッファマネージャ，ロックマネージャ，トランザクションマネージャ等について
記載されているところ，そのうち，「３．２．２．バッファマネージャ」の記載に
よれば，引用発明のバッファマネージャは，ディスクへのデータの書き込みを管理
するものであり，データベース処理を管理するものであって，ファイル及びディレ
クトリ動作に関する処理を行うものではない。したがって，引用発明のバッファマ
ネージャは，本願発明の「ルーチン」あるいは「ルーチンファミリ」に相当するも
のではない。
(ｲ)引用例の「３．２．３．ロックマネージャ」の記載によれば，引用発明の
ロックマネージャは，データの書き込み及び読み出しの競合を管理するものであり，
データベース処理を管理するものであって，ファイル及びディレクトリ動作に関す
る処理を行うものではない。したがって，引用発明のロックマネージャは，本願発
明の「ルーチン」あるいは「ルーチンファミリ」に相当するものではない。
(ｳ)引用例の「３．２．５．トランザクションマネージャ」の記載によれば，
引用発明のトランザクションマネージャは，データベースにおけるデータの更新を
管理するものであり，ファイル及びディレクトリ動作に関する処理を行うものでは
ない。したがって，引用発明のトランザクションマネージャは，本願発明の「ルー
チン」あるいは「ルーチンファミリ」に相当するものではない。
エ審決は，本願発明と引用発明とを対比するに当たって，「引用発明の『コミ
ット処理及びアボート処理の際参照される事前及び事後のログを取得する処理』は，
トランザクション処理におけるログ取得の処理であるので，本願発明の『ファイル
又はディレクトリ動作をロールバックするために必要な情報を記憶するコンピュー
タ命令を含む実行ルーチン』に相当し，」と認定した。
しかしながら，上記認定における引用発明の「コミット処理及びアボート処理の
際参照される事前及び事後のログを取得する処理」は，引用例の「３．２．２．バ
ッファマネージャ」に記載された内容を指すものであり，データベース処理に関す
るものであって，ファイル又はディレクトリ動作に関するものではないから，本願
発明の「ファイル又はディレクトリ動作をロールバックするために必要な情報を記
憶するコンピュータ命令を含む実行ルーチン」に相当するものではない。
したがって，審決の上記認定は誤りである。
オ審決は，本願発明と引用発明とを対比するに当たり，「引用発明の『txn_commit
プリミティブによって起動されるコミット処理』は，トランザクション処理におけ
るコミット処理であるので，本願発明の『関連実行ルーチンの結果をコミットさせ
るコンピュータ命令を含む終了ルーチン』に相当し，」と認定した。
しかしながら，上記認定における引用発明の「txn_commitプリミティブによっ
て起動されるコミット処理」は，引用例の「３．２．５．トランザクションマネー
ジャ」に記載された内容を指すものであり，データベースシステムにおけるデータ
動作に関するものであって，ファイル又はディレクトリ動作に関するものではない
から，本願発明の「関連実行ルーチンの結果をコミットさせるコンピュータ命令を
含む終了ルーチン」に相当するものではない。
したがって，審決の上記認定は誤りである。
カ審決は，本願発明と引用発明とを対比するに当たり，「引用発明の『txn_abort
プリミティブによって起動されるアボート処理』は，トランザクション処理におけ
るロールバック処理であるので，本願発明の『関連実行ルーチンの結果をロールバ
ックさせるコンピュータ命令を含むアンドゥルーチン』に相当している。」と認定
した。
しかしながら，上記認定における引用発明の「txn_abortプリミティブによって
起動されるアボート処理」は，引用例の「３．２．５．トランザクションマネージ
ャ」に記載された内容を指すものであるところ，同処理は，データベースにされた
変更についてｕｎｄｏする処理であり，データ動作に関するものであって，ファイ
ル又はディレクトリ動作に関するものではないから，本願発明の「関連実行ルーチ
ンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチン」に相当
するものではない。
したがって，審決の上記認定は誤りである。
キ審決は，本願発明と引用発明とが，「ネイティブファイルシステムのネイテ
ィブファイルおよびディレクトリ動作のセットへトランザクションセマンティクス
を追加するためのコンピュータプログラムライブラリであって，前記ライブラリが
１つ以上のルーチンファミリのセットを有し，このようなルーチンファミリの各々
が，(a)このようなネイティブファイルまたはディレクトリ動作をロールバックす
るために必要な情報を記憶するコンピュータ命令を含む実行ルーチンと，(b)コン
ピュータに，関連実行ルーチンの結果をコミットさせるコンピュータ命令を含む終
了ルーチンと，(c)コンピュータに，関連実行ルーチンの結果をロールバックさせ
るコンピュータ命令を含むアンドゥルーチンと，を有することを特徴とするコンピ
ュータプログラムライブラリ」である点で一致すると認定したが，以下のとおり，
この認定は誤りである。
(ｱ)審決が認定した引用発明は，引用例の「１．序論」に記載された内容とそ
の後の部分に記載されたＬＩＢＴＰを組み合わせたものであるところ，ＬＩＢＴＰ
は，データベース処理に関するものであるから，同発明における処理は，データベ
ース処理であるデータ動作に関するものである。
なお，引用例には，ライブラリ（ＬＩＢＴＰ）が，本願発明（ネイティブファイ
ルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピ
ュータ命令を含む。）の実行ルーチン，終了ルーチン及びアンドゥルーチンを含む
との記載はないし，そのような事実を認めることもできない。
(ｲ)したがって，引用発明は，「ネイティブファイルシステムのネイティブフ
ァイルおよびディレクトリ動作のセットへトランザクションセマンティクスを追加
するためのコンピュータプログラムライブラリ」ではないし，「(a)このようなネ
イティブファイルまたはディレクトリ動作をロールバックするために必要な情報を
記憶するコンピュータ命令を含む実行ルーチン」を含むものでもないから，審決の
上記一致点の認定は誤りである。
(4)取消事由３（本願発明と引用発明の相違点の看過）
本願発明と引用発明は，「本願発明は，『ネイティブファイルシステムのネイテ
ィブファイルおよびディレクトリ動作のセットへトランザクションセマンティクス
を追加するもの』であるのに対し，引用発明は，『データの読み出し，書き込み等
のデータ動作に対してトランザクションセマンティクスを追加するもの』である
点」（以下「原告主張相違点」という。）において相違するのであり，審決は，か
かる相違点の存在を看過したものである。
なお，被告は，「引用例においては，『１．序論』に記載された『従来のＵＮＩ
Ｘファイルシステム』にトランザクションセマンティクスを提供するための具体的
な実装の例として，『３．アーキテクチャ』，『４．実装』等に記載されたライブ
ラリ（ＬＩＢＴＰ）についての説明がされている」と主張するが，「１．序論」に
は，審決が認定した引用発明の必須の構成が記載されているわけではなく，また，
「１．序論」に記載された内容と「３．アーキテクチャ」，「４．実装」等に記載
された内容とが，技術的に関連して所定の機能を提供するものでもないから，被告
の上記主張は失当である。
２被告の反論の要点
(1)原告の主張(1)（前提となる技術内容等について）に対し
ア原告は，コンピュータシステムがデータベースシステムとファイルシステム
に分類され，引用発明は前者に関するものであり，本願発明は後者に関するもので
ある旨主張する。
(ｱ)しかしながら，両者は別のものではなく，ともに，コンピュータが大量の
データを記憶装置に格納・保管し，必要に応じてこれを取り出したり，更新・削除
を行ったりするシステムである。両者は，データを記憶装置に記憶する処理をハー
ドウェア的側面に重点を置いて見たときには，「ファイルシステム」と捉えられ，
記憶装置に記憶されるデータに対する処理というソフトウェア的側面に重点を置い
て見たときには，「データベースシステム」と捉えられる。
(ｲ)そして，平成５年４月２５日発行の坂下善彦ら著「分散システム入門（初
版）」（乙１。以下「乙１文献」という。）に記載されている（１５７頁８行∼１
５８頁９行）とおり，データベースシステムといえども，データは，最終的には，
記憶装置（主にハードディスク）に記憶（二次記憶）される（データベースシステ
ムによって処理されたデータは，ファイルシステムに引き渡され，ファイルシステ
ムの機能によって記憶装置（ハードディスク）に記憶される）ことは周知の事項で
ある。すなわち，データベースシステムは，通常，ファイルシステムを利用して構
築されているものであり，データベースのデータも，ハードディスクに保管される
際には，ファイルシステムの操作により，ファイルとして保管されるのであるから，
原告の上記主張は失当である。
イ原告は，本願発明がファイルシステムにトランザクションセマンティクスを
付与するものであるのに対し，引用例にはその点についての記載がない旨主張する。
(ｱ)しかしながら，引用例の「１．序論」の記載（１頁２９行∼３頁５行）に
よれば，引用例は，汎用的なプログラムが用いるファイルシステムにトランザクシ
ョンセマンティクスを提供するライブラリについて論じているものであり，「３．
アーキテクチャ」及び「４．実装」で説明されているライブラリ（ＬＩＢＴＰ）が
それに当たる。
(ｲ)そして，上記アのとおり，データベースシステムは，ファイルシステムを
利用して構築されるシステムであり，従来は，データベースシステムがファイルシ
ステムを利用するため，ファイルシステムに属するルーチン（open，read,write
等）が用いられていたところ，引用例の「４．実装」の記載（１６頁２２行∼１７
頁１行）によれば，これらのルーチンを，トランザクションセマンティクスを付与
するための新たなルーチン（buf_open，buf_get,buf_unpin等）に置き換えればよ
く（すなわち，buf_open，buf_get，buf_unpin等は，既存のファイルシステムに属
するルーチンであるopen，read，write等の機能を含んだ上でトランザクション保
護を追加するための機能を持ったルーチンであるとともに，引用例に記載されたラ
イブラリ（ＬＩＢＴＰ）の一部である。），これらの置き換えにより，データベー
スシステムとしても利用されるファイルシステムに，トランザクションセマンティ
クスが付与されるものである。
なお，このためには，４．４ＢＳＤデータベースアクセスルーチンの対応するル
ーチンの呼出しを置き換えるとともに，ファイルシステム側に，置き換えられたル
ーチンに対応するルーチンを加える必要があるが，当該置き換えられるルーチンが
４．４ＢＳＤデータベースアクセスルーチンに特化したものでないことは，引用例
の「１．序論」の記載からも明らかである。
(ｳ)また，平成５年１月２０日発行の塩谷修ら著「実用ＵＮＩＸシステムプロ
グラミング（第２版）」（乙２。以下「乙２文献」という。）に記載されている
（１５６頁２１行∼１６０頁３６行）とおり，既存のファイルシステムに属する
openシステムコールは，モード指定する際，Ｏ＿ＣＲＥＡＴを指定すると，file
で指定したpath名のファイルを作成する動作を行うことが周知であり，これは，
本願明細書にいう「ファイル動作」を行うことと同じであるから，引用例に記載さ
れたルーチンopenも，本願明細書にいう「ファイル動作」を行っていることにな
る。
そうすると，既存のファイルシステムに属するルーチンopenの機能を含んだ上
でトランザクション保護を追加するための機能を持ったルーチンbuf_openは，本
願明細書にいう「ファイル動作」に対しトランザクションセマンティクスを追加す
るルーチンであるということができ，したがって，buf_openを含むライブラリで
あるＬＩＢＴＰが，本願明細書にいう「ファイル動作」のセットに対しトランザク
ションセマンティクスを追加する構成であることは明らかである。
そして，引用例に記載されたルーチン（「コミット処理及びアボート処理の際参
照される事前及び事後のログを取得する処理」等）も，ネイティブファイルシステ
ムのネイティブファイル及びディレクトリ動作のセットに対しトランザクションセ
マンティクスを追加するルーチン（buf_open等）の「ログを取得する処理」等を
行うものであるから，本願発明の「ネイティブファイルシステムのネイティブファ
イルおよびディレクトリ動作のセットへトランザクションセマンティクスを追加す
る」との構成と，引用例に記載されたライブラリ（ＬＩＢＴＰ）とが，技術的に異
なるものであるということはできない。
(ｴ)このように，引用発明は，ファイルシステムにトランザクションセマンテ
ィクスを付与するものであるから，原告の上記主張は根拠がなく失当である。
(2)取消事由１（引用発明の認定の誤り）に対し
ア原告は，引用例の「１．序論」に記載された内容と，「３．アーキテクチ
ャ」，「４．実装」等に記載された内容とを結合した１つの発明を引用発明とした
審決の認定に誤りがある旨主張する。
しかしながら，引用例の「３．アーキテクチャ」，「４．実装」等の記載は，
「１．序論」の記載を受け，「従来のＵＮＩＸファイルシステム」にトランザクシ
ョンセマンティクスを付与する技術であるライブラリ（ＬＩＢＴＰ）について論じ
たものであるから，引用発明は，従来のＵＮＩＸのファイルシステムにトランザク
ションセマンティクスを付与するものである。
また，一般に，「序論」は，本論の前置きとして，本論の手がかりとなる事項を
記述したものであるところ，引用例においても，本論に相当する「３．アーキテク
チャ」，「４．実装」等は，「１．序論」を受けて論じられている。
したがって，原告の上記主張は失当である。
イ原告は，引用例の「１．序論」に記載された内容と，「３．アーキテクチ
ャ」，「４．実装」等に記載されたライブラリ（ＬＩＢＴＰ）とは，技術的な整合
性を有しないから，両者を結合しても，１つの発明を構成することはできない旨主
張する。
しかしながら，原告が主張する審決が認定した第１の場合及び第２の場合は，い
ずれも，引用例に記載された従来技術に関するものであるところ，上記アのとおり，
引用例の「３．アーキテクチャ」，「４．実装」等の記載は，「１．序論」の記載
を受け，「従来のＵＮＩＸファイルシステム」にトランザクションセマンテイクス
を付与する技術について論じたものであるから，「１．序論」に記載された内容と，
「３．アーキテクチャ」，「４．実装」等に記載されたライブラリ（ＬＩＢＴＰ）
は，１つの発明についてのものであり，したがって，原告の上記主張は根拠がなく
失当である。
ウ原告は，引用例に開示されているＬＩＢＴＰは，４．４ＢＳＤデータベース
におけるデータ動作に対してトランザクションセマンティクスを提供するものであ
り，ファイル及びディレクトリ動作に対してトランザクションセマンティクスを提
供するものではないから，引用例に「ファイルの更新処理方法」が記載されている
とはいえない旨主張する。
(ｱ)しかしながら，引用例の記載（３頁４∼８行）によれば，４．４ＢＳＤデ
ータベースアクセス法は，「３．アーキテクチャ」，「４．実装」等に記載された
「従来のＵＮＩＸファイルシステム」にトランザクションセマンティクスを付与す
るライブラリ（ＬＩＢＴＰ）を使用するように修正された上，トランザクションセ
マンティクスを付与されている。このことからすると，４．４ＢＳＤデータベース
アクセス法とライブラリ（ＬＩＢＴＰ）とは，別のものであるといえる。
そして，引用例の記載（３頁８∼１１行）によれば，当該ライブラリ（ＬＩＢＴ
Ｐ）は，ＵＮＩＸプログラムにトランザクション保護を提供するために適切なコー
ルを追加するものであるから，これを当該データベースアクセス法に限定する必要
はない。
(ｲ)また，上記(1)のとおり，データベースシステムは，ファイルシステムを利
用したものであり，他のＵＮＩＸプログラムも，二次記憶を利用する際にはファイ
ルシステムを利用するものであることからすると，引用例に記載されたライブラリ
（ＬＩＢＴＰ）は，ファイルシステムについてのライブラリであるといえる。
(ｳ)なお，原告は，引用例に開示されているＬＩＢＴＰがデータ動作に対して
トランザクションセマンティクスを提供するものであることは，甲７論文の記載か
らも明らかである旨主張するが，甲７論文には，ＬＩＢＴＰがデータベースシステ
ムそのものであるとの記載はないし，上記(ｱ)のとおり，４．４ＢＳＤ（バークレ
イＤＢ）とＬＩＢＴＰは別のものであり，他のＵＮＩＸプログラムにおいても，Ｌ
ＩＢＴＰを利用することが可能であるから，原告の上記主張は根拠がなく失当であ
る。
エ以上のとおりであるから，審決の引用発明の認定には，何らの誤りもない。
(3)取消事由２（本願発明と引用発明の一致点の認定の誤り）に対し
ア原告は，審決がした本願発明と引用発明との対比に関し，引用発明における
「実行されているファイル生成等の具体的なファイル操作」が何を意味するのか不
明であるし，仮にＬＩＢＴＰを意味するとしても，これはファイル生成等の具体的
なファイル操作にトランザクションセマンティクスを提供するものではないから，
審決の「引用発明における・・・ファイル生成等の具体的なファイル操作は，トラ
ンザクションの保護の対象となるファイル操作を含む実行ルーチンであるので，こ
れは，本願発明の『ネイティブファイルシステムにおけるファイル及びディレクト
リの操作』を含むルーチンに対応するとともに『関連実行ルーチン』に相当」する
との認定は誤りであると主張する。
しかしながら，引用例の「１．序論」に「新たなファイルが作成される場合」と
例示されているように，引用例に従来技術として示されているファイル操作は，フ
ァイル生成等の具体的なファイル操作である。
また，引用例の「１．序論」には，従来技術として，審決が認定した第１の場合
及び第２の場合における「伝統的なＵＮＩＸファイルシステム」での解決方法が記
載されているところ，これを，トランザクションセマンティクスを提供することに
より解決する方法が，「３．アーキテクチャ」，「４．実装」等に記載されたライ
ブラリ（ＬＩＢＴＰ）であるから，「引用発明における・・・ファイル生成等の具
体的なファイル操作は，トランザクションの保護の対象となるファイル操作を含む
実行ルーチンである」こと，これが「本願発明の『ネイティブファイルシステムに
おけるファイル及びディレクトリの操作』を含むルーチンに対応するとともに『関
連実行ルーチン』に相当」することは明らかである。
したがって，原告の上記主張は失当である。
イ原告は，審決がした本願発明と引用発明との対比に関し，引用発明のライブ
ラリ（ＬＩＢＴＰ）は，データベース処理に対してトランザクションセマンティク
スを提供するものであり，ネイティブファイル又はディレクトリ動作に対してトラ
ンザクションセマンティクスを提供するものではないから，審決の「引用発明にお
ける『ライブラリ（LIBTP）』は，ネイティブファイルシステムに必要に応じてト
ランザクションセマンティクスを追加あるいは提供するためのコンピュータプログ
ラムルーチンの集合であるので，これは本願発明の『ライブラリ』に相当」すると
の認定は誤りであると主張する。
しかしながら，上記(2)ウのとおり，引用例に記載されたライブラリ（ＬＩＢＴ
Ｐ）は，ファイルシステムについてのライブラリであるから，本願発明のライブラ
リに相当する。したがって，原告の上記主張は根拠がなく失当である。
ウ原告は，審決がした本願発明と引用発明との対比に関し，引用発明のバッフ
ァマネージャ，ロックマネージャ及びトランザクションマネージャは，ファイル及
びディレクトリ処理動作に関する処理を行うものではないから，審決の「引用発明
における・・・『・・・バッファマネージャ，ロックマネージャ，トランザクショ
ンマネージャの各々を実現するルーチン』の各々は，本願発明の『ルーチン』ある
いは『ルーチンファミリ』に相当し，又，引用発明においてもこれらのルーチンが
複数あり，本願発明と同様に，『セット』を構成していると言うことができる。」
との認定は誤りであると主張する。
しかしながら，上記(1)のとおり，データベースは，ディスクに対応する二次記
憶へのデータの書き込みにファイルシステムを利用しており，ディスクへのデータ
の書き込みを管理するものも，ファイルシステムに属するのであるから，引用発明
のバッファマネージャ，ロックマネージャ及びトランザクションマネージャは，い
ずれも，ファイルシステムのルーチンであるといえる。
そうすると，審決の上記認定には何らの誤りもなく，したがって，原告の上記主
張は失当である。
エ原告は，審決がした本願発明と引用発明との対比に関し，引用発明の「コミ
ット処理及びアボート処理の際参照される事前及び事後のログを取得する処理」は
引用例の「３．２．２．バッファマネージャ」に，「txn_commitプリミティブに
よって起動されるコミット処理」及び「txn_abortプリミティブによって起動され
るアボート処理」はいずれも引用例の「３．２．５．トランザクションマネージ
ャ」に，それぞれ記載された内容を指すものであり，データベース処理に関するも
のであって，ファイル又はディレクトリ動作に関するものではないから，審決がし
た「引用発明の『コミット処理及びアボート処理の際参照される事前及び事後のロ
グを取得する処理』は，トランザクション処理におけるログ取得の処理であるので，
本願発明の『ファイル又はディレクトリ動作をロールバックするために必要な情報
を記憶するコンピュータ命令を含む実行ルーチン』に相当し」との認定，「引用発
明の『txn_commitプリミティブによって起動されるコミット処理』は，トランザ
クション処理におけるコミット処理であるので，本願発明の『関連実行ルーチンの
結果をコミットさせるコンピュータ命令を含む終了ルーチン』に相当し」との認定，
及び「引用発明の『txn_abortプリミティブによって起動されるアボート処理』は，
トランザクション処理におけるロールバック処理であるので，本願発明の『関連実
行ルーチンの結果をロールバックさせるコンピュータ命令を含むアンドゥルーチ
ン』に相当している」との認定は，いずれも誤りであると主張する。（取消事由２
のエないしカ）
しかしながら，上記(1)のとおり，データベースシステムは，ファイルシステム
を利用して構築されるシステムであること，上記(2)アのとおり，引用発明は，
「従来のＵＮＩＸファイルシステム」にトランザクションセマンティクスを付与す
るものであること，引用例においては，「１．序論」に記載された「従来のＵＮＩ
Ｘファイルシステム」にトランザクションセマンティクスを提供するための具体的
な実装の例として，「３．アーキテクチャ」，「４．実装」等に記載されたライブ
ラリ（ＬＩＢＴＰ）についての説明がされていることに照らすと，引用発明の「コ
ミット処理及びアボート処理の際参照される事前及び事後のログを取得する処理」，
「txn_commitプリミティブによって起動されるコミット処理」及び「txn_abortプ
リミティブによって起動されるアボート処理」は，それぞれ，本願発明の「ファイ
ル又はディレクトリ動作をロールバックするために必要な情報を記憶するコンピュ
ータ命令を含む実行ルーチン」，「関連実行ルーチンの結果をコミットさせるコン
ピュータ命令を含む終了ルーチン」及び「関連実行ルーチンの結果をコミットさせ
るコンピュータ命令を含むアンドゥルーチン」に相当するといえるから，原告の上
記各主張はいずれも理由がなく，審決の上記各認定に誤りはない。
オ原告は，引用発明のＬＩＢＴＰは，データベース処理に関するものであって，
同発明における処理は，データベース処理であるデータ動作に関するものであるか
ら，引用発明は，「ネイティブファイルシステムのネイティブファイルおよびディ
レクトリ動作のセットへトランザクションセマンティクスを追加するためのコンピ
ュータプログラムライブラリ」ではないし，「(a)このようなネイティブファイル
またはディレクトリ動作をロールバックするために必要な情報を記憶するコンピュ
ータ命令を含む実行ルーチン」を含むものではないとして，本願発明と引用発明と
が，「ネイティブファイルシステムのネイティブファイルおよびディレクトリ動作
のセットへトランザクションセマンティクスを追加するためのコンピュータプログ
ラムライブラリであって，前記ライブラリが１つ以上のルーチンファミリのセット
を有し，このようなルーチンファミリの各々が，(a)このようなネイティブファイ
ルまたはディレクトリ動作をロールバックするために必要な情報を記憶するコンピ
ュータ命令を含む実行ルーチンと，・・・を有することを特徴とするコンピュータ
プログラムライブラリ」である点で一致するとした審決の認定が誤りであると主張
する。
しかしながら，上記エのとおり，データベースシステムは，ファイルシステムを
利用して構築されるシステムであること，引用発明は，「従来のＵＮＩＸファイル
システム」にトランザクションセマンティクスを付与するものであること，引用例
においては，「１．序論」に記載された「従来のＵＮＩＸファイルシステム」にト
ランザクションセマンティクスを提供するための具体的な実装の例として，「３．
アーキテクチャ」，「４．実装」等に記載されたライブラリ（ＬＩＢＴＰ）につい
ての説明がされていることにかんがみれば，引用発明の「ライブラリ（ＬＩＢＴ
Ｐ）」は，「ネイティブファイルシステムのネイティブファイルおよびディレクト
リ動作のセットヘトランザクションセマンテイクスを追加するためのコンピュータ
プログラムライブラリ」であるとともに，「このようなネイティブファイルまたは
ディレクトリ動作をロールバックするために必要な情報を記憶するコンピュータ命
令を含む実行ルーチン」を含んでいるといえるから，審決のした一致点の認定に誤
りはなく，原告の上記主張は失当である。
カ以上のとおり，審決がした本願発明と引用発明との対比・一致点の認定に誤
りはない。
(4)取消事由３（本願発明と引用発明の相違点の看過）に対し
原告は，本願発明と引用発明は，原告主張相違点において相違するものであり，
審決は，かかる相違点の存在を看過したものであると主張する。
しかしながら，上記(3)エのとおり，引用例においては，「１．序論」に記載さ
れた「従来のＵＮＩＸファイルシステム」にトランザクションセマンティクスを提
供するための具体的な実装の例として，「３．アーキテクチャ」，「４．実装」等
に記載されたライブラリ（ＬＩＢＴＰ）についての説明がされていることに照らす
と，引用発明は，「ネイティブファイルシステムのネイティブファイルおよびディ
レクトリ動作のセットへトランザクションセマンティクスを追加するもの」である
ということができるから，原告主張相違点は存在せず，審決に相違点看過の誤りは
ない。
第４当裁判所の判断
１前提となる技術内容（引用例に記載された技術が本願明細書にいう「ファイ
ルおよびディレクトリ動作」に対しトランザクションセマンティクスを付与するも
のといえるか）について
(1)引用例には，次の各記載がある。
ア「概要
・・・。従来のＵＮＩＸシステムにおいては，トランザクションを使用するための唯一容易
な方法は，データベースシステムを購入することである。このようなシステムは処理速度が遅
くコストがかかることが多く，所望されている通りの機能性を提供しないこともある。本論文
は，４．４ＢＳＤ（BerkeleySoftwareDistribution）データベースアクセスルーチン（ｄｂ
（３））を使用する簡易型非プロプライエタリ・トランザクションライブラリーであるＬＩＢ
ＴＰの設計，実装および性能について提示している。」（１頁５∼１３行）
イ「１．序論
トランザクションはデータベースシステムで使用されて，同時アクセスするユーザーがデー
タベースのインテグリティを破壊することなくマルチオペレーション更新を適用できるように
する。これは，原子性，一貫性，分離性および耐久性という特性を提供する。原子性とは，ト
ランザクションを構成する更新一式が単一のユニットとして適用されるべきである，つまりす
べてがデータベースに適用されるか，すべてが欠けているかのいずれかでなければならないこ
とを意味する。一貫性とは，トランザクションがデータベースをある論理的一貫性の状態から
別の論理的一貫性の状態に移すことを要求するものである。分離特性は，同時トランザクショ
ンが，トランザクションを順次実行することによって得られる結果と区別できない結果を生成
することを要求するものである。最後に，耐久性とは，トランザクションがコミットされると，
その結果がシステム障害を越えて保存されることを要求するものである・・・。
これらの特性についてはデータベースと関連してしばしば議論されるところであるが，これ
らは，より汎用なアプリケーションにとって有用なプログラミングパラダイムである。現在の
アドホック機構に取って代り，トランザクションを使用できる複数の様々な状況がある。
そうした状況の１つは，複数のファイルまたは複数のファイルの一部が原子的に更新される
必要がある場合である。例えば，従来のＵＮＩＸファイルシステムは順序制約を使用して，ク
ラッシュに直面した場合の回復可能性を達成する。新たなファイルが作成される場合，その新
たなファイルがディレクトリ構造に追加される前にそれのｉノードがディスクに書き込まれ
る。」（１頁１７行∼２頁８行）
ウ「現行のアドホック機構に取って代り，トランザクションが使用できる第２の状況は，共
有ファイルの同時更新が所望されるが，データの論理的一貫性を維持する必要があるというア
プリケーションにおいてである。例えば，パスワードファイルが更新される場合，ファイルロ
ックを使用して同時アクセスを許可しない。パスワードファイルに対するトランザクションセ
マンティクスでは，パスワードデータベースの論理的一貫性を維持しつつ同時更新を可能にす
る。」（２頁２０∼２５行）
エ「本論文において，トランザクションセマンティクス（原子性，一貫性，分離性および耐
久性）を提供する簡易型ライブラリーを提示する。４．４ＢＳＤデータベースアクセス法は，
このライブラリーを使用するために修正されており，任意に，アプリケーション間の共有バッ
ファ管理，ロッキングおよびトランザクションセマンティクスを提供する。ｄｂ（３）ライブ
ラリーによるトランザクション保護をリクエストすることによって，・・・ＵＮＩＸプログラ
ムはそのデータをトランザクション保護することができる。」（３頁４∼１１行）
オ「３．アーキテクチャ
ライブラリーは，トランザクション処理に必要なサービスに洗練されたインタフェースを提
供するように設計されている。これらのサービスは回復，同時実行制御および共有データ管理
である。まず，回復，同時実行制御およびバッファ管理実装における設計トレードオフについ
て論じてから，ライブラリーアーキテクチャおよびモジュール全体について説明することにす
る。」（４頁２８行∼５頁３行）
カ「４．実装」（１３頁８行）
キ「４．４トランザクション保護アクセス法
・・・
アクセス法にトランザクション保護を追加するのに必要な修正は極めて単純であり局所的で
ある。
１．ファイルｏｐｅｎをｂｕｆ＿ｏｐｅｎで置換する。
２．ファイルｒｅａｄおよびｗｒｉｔｅのコールをバッファマネージャコール（ｂｕｆ＿ｇｅ
ｔ，ｂｕｆ＿ｕｎｐｉｎ）で置換する。
３．バッファマネージャコールの前に適切な（ｒｅａｄまたはｗｒｉｔｅ）ロックコールを置
く。
４．更新前にロギング命令を発行する。
５．データにアクセスされた後に，バッファマネージャピンを解除する。
６．定義されたログレコードのタイプごとに取り消し／やり直しコードを提供する。」（１６
頁８行∼１７頁１行）
(2)また，ＵＮＩＸシステムに関する乙２文献には，次の各記載がある。
ア「６．１．３ファイルの作成とオープン
・・・
ここでは，creat，openシステムコールを紹介します。
【creat】
・・・
ファイルを作り，書き込みの準備を行います。
すでに存在するファイルに上書きの準備を行います。
・・・
・存在するファイルに対してcreatコールを行った場合，ファイルのサイズは０にリセットさ
れます。モードとオーナは変わりません。
・ファイルが存在していない場合，ファイルのオーナおよびグループＩＤは・・・設定された
ファイルが作られます。」（１５６頁２１行∼１５７頁「説明」５行）
イ「【open】
・・・
ファイルをオープンします。」（１５９頁５∼７行）
ウ「O_CREAT
ファイルが存在している場合，意味はありません。存在していない場合，creatコールと同
じ機能が得られます。」（１６０頁１４∼１６行）
(3)上記(1)の各記載によれば，引用例は，既存のファイルシステムであるＵＮ
ＩＸシステムのような汎用的なプログラムが用いるファイルシステムに対し，トラ
ンザクションセマンティクスを提供するライブラリについて論じているものであり，
引用例の「３．アーキテクチャ」及び「４．実装」において，そのライブラリにつ
き，具体的に説明しているものと認められる。
また，上記(1)キのとおり，引用例に記載されたライブラリ（ＬＩＢＴＰ）にお
いては，ファイル処理にトランザクション保護機能を追加するために，プログラム
中のopen，read及びwriteを，それぞれbuf_open，buf_get及びbuf_unpinに置
き換えることが行われているのであるから，buf_open，buf_get及びbuf_unpinは，
それぞれ既存のファイルシステムに属するルーチンであるopen，read及びwrite
の機能を含んだ上で，トランザクション保護機能を追加するための機能を有するル
ーチンであると理解することができる。
さらに，上記(2)の各記載によれば，既存のファイルシステムであるＵＮＩＸシ
ステムに属するシステムコールopenは，「ファイルを作り，書き込みの準備を行
う」システムコールと同じ機能を有していることが認められる（なお，乙２文献が，
平成５年１月２０日発行のＵＮＩＸシステムプログラミングに関する一般的な概説
書であることにかんがみれば，このことは，本件特許出願当時は，当業者に周知の
事項であったものと認められる。）。
加えて，そもそも，ファイルシステムは，オペレーティングシステムが有する機
能の１つであって，アプリケーションプログラムに応答し，外部の記憶媒体（ハー
ドディスク等）に対してデータの書き込み，変更（更新，消去），読み出し等の動
作を行うものであるところ，新しいファイルの生成，ファイル名の変更，ファイル
の削除等の処理も，オペレーティングシステムからみれば，データの処理に他なら
ないことは，経験則上明らかである（例えば，ファイルの生成は，新しいファイル
についてのデータを生成することであり，ファイル名の変更は，ファイル名のデー
タを更新することであり，ファイルの削除は，ファイルについてのデータを削除す
ることである。）。
以上からすると，引用例には，本願明細書にいう「ファイルおよびディレクトリ
動作」に対しトランザクションセマンティクスを付与する技術についての記載があ
ると認めるのが相当であり，引用例（特に，「３．アーキテクチャ」及び「４．実
装」の各欄）に当該記載がない旨をいう原告の主張は，これを採用することができ
ない。
(4)そこで，以上を前提に，以下，各取消事由について検討する（したがって，
以下，引用例（「３．アーキテクチャ」及び「４．実装」の各欄を含む。）に記載
された技術が，本願明細書にいう「ファイルおよびディレクトリ動作」に対しトラ
ンザクションセマンティクスを付与するものではないことを前提とする原告の主張
は，いずれも，その前提を欠くものとして失当である。）。
２取消事由１（引用発明の認定の誤り）について
(1)上記１のとおり，引用例（「３．アーキテクチャ」及び「４．実装」の各
欄を含む。）には，本願明細書にいう「ファイルおよびディレクトリ動作」に対し
トランザクションセマンティクスを付与する技術についての記載があると認められ
るから，審決が引用する引用例の記載事項（前記第２の３(1)）によれば，引用発
明は，審決が認定したとおりのもの（同）であると認めるのが相当である。
(2)ア原告は，引用例の「１．序論」に記載された内容と，「３．アーキテク
チャ」，「４．実装」等に記載された内容とを結合した１つの発明は，引用例のど
こにも記載されていないと主張する。
しかしながら，原告の上記主張は，その前後の主張の内容から明らかなとおり，
「引用例の『３．アーキテクチャ』，『４．実装』等には，引用例の主要なテーマ
である，データベースシステムに対するデータ動作にトランザクションセマンティ
クスを付与する技術であるライブラリ（ＬＩＢＴＰ）が記載されているにとどま
（る）（したがって，ファイル及びディレクトリ動作にトランザクションセマンテ
ィクスを付与するものではない。）」ことを前提とするものである。
そうすると，上記１のとおり，原告の上記主張は，その前提を欠くものとして失
当である。
イ原告は，審決が認定した第１の場合及び第２の場合が記載された引用例の
「１．序論」には，いずれも，トランザクションセマンティクスを提供するための
ライブラリ（ＬＩＢＴＰ）の各ルーチンを実行するとは記載されていないから，引
用例の「１．序論」に記載された内容と，「３．アーキテクチャ」，「４．実装」
等に記載された内容とは，技術的な整合性を有しておらず，両者を結合しても，１
つの発明を構成することができないと主張する。
しかしながら，審決（前記第２の３(1)）が引用するとおり，引用例の「３．ア
ーキテクチャ」及び「４．実装」の欄には，トランザクションセマンティクスを提
供するためのライブラリ（ＬＩＢＴＰ）の各ルーチンを実行することについての記
載があるのであるから，原告の上記主張は，要するに，引用例の「３．アーキテク
チャ」及び「４．実装」に記載された技術が，本願明細書にいう「ファイルおよび
ディレクトリ動作」に対しトランザクションセマンティクスを付与するものではな
いことを前提とするものと理解せざるを得ない。
そうすると，上記１のとおり，原告の上記主張は，その前提を欠くものとして失
当である。
(3)以上のとおり，審決の引用発明の認定に原告主張の誤りはないから，取消
事由１は，理由がない。
３取消事由２（本願発明と引用発明の一致点の認定の誤り）について
(1)前記１のとおり，引用例（「３．アーキテクチャ」及び「４．実装」の各
欄を含む。）には，本願明細書にいう「ファイルおよびディレクトリ動作」に対し
トランザクションセマンティクスを付与する技術についての記載があると認められ
るから，本願発明と引用発明とは，審決が両発明を対比した上で認定したとおりの
点（前記第２の３(2)）で一致すると認めるのが相当である。
(2)原告は，審決が，本願発明と引用発明との対比において，「引用発明にお
ける『新しいファイルの生成等のように複数のファイルの複数の部分が原子的に更
新される必要がある場合や共有ファイルに対する同時的な更新が望まれる一方で論
理的なデータの一貫性を維持する必要が生ずる場合』に実行されているファイル生
成等の具体的なファイル操作は，トランザクションの保護の対象となるファイル操
作を含む実行ルーチンであるので，これは，本願発明の『ネイティブファイルシス
テムにおけるファイル及びディレクトリの操作』を含むルーチンに対応するととも
に『関連実行ルーチン』に相当する」と認定したことに関し，当該「実行されてい
るファイル生成等の具体的なファイル操作」が何を指すのか不明であるなどと主張
する。
しかしながら，原告の上記主張は，その前後の主張の内容から明らかなとおり，
「審決が認定した第１の場合及び第２の場合は，引用例の『１．序論』に記載され
ているところ，同箇所には，トランザクションが必要な場合及び従来の解決方法が
記載されているのみである」ことを前提とするものである。
そして，前記１において説示したところに照らし，審決（前記第２の３(1)）が
摘記した引用例の「３．アーキテクチャ」及び「４．実装」の各欄には，審決の上
記認定における「実行されているファイル生成等の具体的なファイル操作」につい
ての具体的記載があることは明らかであるから，原告の上記主張は，要するに，引
用例の「３．アーキテクチャ」及び「４．実装」に記載された技術が，本願明細書
にいう「ファイルおよびディレクトリ動作」に対しトランザクションセマンティク
スを付与するものではないことを前提とするものと理解せざるを得ない。
そうすると，前記１のとおり，原告の上記主張は，その前提を欠くものとして失
当である。
(3)以上のとおり，本願発明と引用発明の一致点についての審決の認定に原告
主張の誤りはないから，取消事由２は，理由がない。
４取消事由３（本願発明と引用発明の相違点の看過）について
前記１において説示したところに照らせば，本願発明は，原告主張相違点に係る
引用発明の構成を備えるものであり，そうすると原告主張相違点は存在しないから，
審決に本願発明と引用発明の相違点を看過した誤りはなく，取消事由３は，理由が
ない。
５結論
よって，原告の主張する審決取消事由はいずれも理由がないから，原告の請求は
棄却されるべきである。
知的財産高等裁判所第４部
裁判長裁判官
石原直樹
裁判官
榎戸道也
裁判官
浅井憲

戻る