【事件の表示】
　平成　５年特許願第２２３５０８号「ファイル管理システム」拒絶査定不服審判事件〔平成　７年　３月２０日出願公開、特開平　７−　７８０９８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成５年９月８日の出願であって、その請求項１に係る発明（以下、「本願発明」という。）は、平成１６年２月５日付けの手続補正書により補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１に記載されたとおりの次のものと認める。
　
「　ソフトリンクおよびファイルの創成を行うファイル管理システムにおいて、
　エントリ識別子とエントリに関する情報と、ソフトリンク情報または割り当てブロック参照域を有するファイル管理部エントリが複数あるファイル管理部と、データ記憶部とを有するファイルシステムと、
　前記ファイル管理部にファイル管理部エントリとエントリ識別子を割り当てるエントリ操作手段と、
　ファイルの創成を行う場合、前記データ記憶部を割り当てる通常ファイルアクセス手段と、
　ソフトリンクの創成を行う場合、前記ファイル管理部エントリにエントリに関する情報とソフトリンク情報を設定し、ファイルの創成を行う場合、前記ファイル管理部エントリにエントリに関する情報と割り当てブロック参照域を設定するエントリアクセス手段と、
　親ディレクトリに、前記エントリ識別子とファイル名から構成されるディレクトリエントリを追加するディレクトリアクセス手段と、
　ソフトリンクのパス名解決を行う場合、前記ソフトリンク情報からパス名を取り出すパス名解決手段と、
　を備えることを特徴とするファイル管理システム。」
　
　
２． 引用例
　これに対して、原査定の拒絶の理由に引用された、Andrew S. Tanenbaum著、「MINIXオペレーティング・システム」、第１版、株式会社アスキー、１９９０年９月１日、ｐ．２９７−３２１（以下、「引用例」という。）には、次の事項が図面とともに記載されている。
　
（Ａ）「５．１．２　ディレクトリ
　ファイルを記録しておくために、ファイルシステムでは通常ディレクトリ(directory)を提供しており、大半のシステムではこのディレクトリ自身もファイルの一種となっている。・・・（中略）・・・
　ここで必要となるのは、階層化（すなわちディレクトリ・ツリー）である。このアプローチにより、ユーザはファイルが自然な方法でグループ分けできるように、必要なだけディレクトリを持つことができるようになる。これを示したのが図５．３（ｃ）である。
　ファイルシステムがディレクトリのツリーとして構成されると、ファイル名を指定する方法を決めておかなければならない。一般的には次の２つの方法が使用されている。最初の方法では、各ファイルに、ルートディレクトリからそのファイルまでのパスを表す絶対パス名(absolute path name)を付ける。例えばパス/usr/ast/mailboxは、ルートディレクトリにサブディレクトリusrが存在し、その中にさらにastというサブディレクトリが存在し、そこにファイルmailboxが含まれていることを示すものとなる。絶対パス名は、必ずルートディレクトリから始まり、一意な名前となる。
　もう１つの方法は相対パス名(relative path name)である。これはワーキングディレクトリ(working directory)の概念と共に使用する。ワーキングディレクトリはカレントディレクトリ(current directory)とも呼ばれている。ユーザは１つのディレクトリをカレント・ワーキングディレクトリとして定義する。ルートディレクトリから始まらないパス名は、ワーキングディレクトリから相対的に解釈される。ＵＮＩＸではスラッシュで始まるパス名はすべて絶対パス名であり、その他はすべてユーザのカレント・ワーキングディレクトリからの相対パス名となる。ワーキングディレクトリが/usr/astであれば、絶対パス名が/usr/ast/mailboxのファイルは、単にmailboxと指定するだけでよい。」
（第３０１頁第１２行から第３０３頁第８行）
　
（Ｂ）「５．２．２　ファイルの保存
　ファイルが連続するブロックから構成されている場合、ファイルシステムは各ファイルを構成するブロックを何らかの方法で管理しなくてはならない。・・・（中略）・・・
よりよい方法として、それぞれのファイルのためのブロックリストを別々の場所に保存しておく方法がある。ＵＮＩＸではこの様な方法を採っている。
　ＵＮＩＸでは各ファイルに対応して、ｉノード(i-node)と呼ぶ小さなテーブルが用意されている。図５．７はこれを示したものである。このテーブルにはアカウント情報と、保護情報が含まれている。これらに関しては後述する。ここでは１０個のディスクブロック番号と、３つの間接ブロック番号に焦点をあてる。最長１０ブロック分のファイルでは、すべてのディスクアドレスがｉノードに保存されているため、ブロックの検出は簡単である。」
（第３０５頁第１６行から第３０８頁第３行）
　
（Ｃ）「５．２．３　ディレクトリ構造
　ファイルの読み出しを行うためには、それをオープンしなければならない。ファイルをオープンすると、オペレーティング・システムはユーザが提供したパス名を用い、ディスクブロックの位置を検出、ファイルの読み書きに備える。パス名をｉノードに対応付ける時（あるいはそれに相当するような操作）、ディレクトリ・システムがどの様な構造となっているか考えねばならない。ディレクトリ構造は簡単なものから、かなり高度なものまで様々である。
　・・・（中略）・・・
　ＵＮＩＸやＭＩＮＩＸにおけるディレクトリ構造は、図５．１０の様に非常に簡単である。各エントリはファイル名とそのｉノード番号だけを持っている。型、サイズ、時刻、所有者、およびディスクブロックに関する情報はすべてｉノード内に格納されている（図５．７参照）。ＵＮＩＸ内のすべてのディレクトリはファイルであり、１６バイトのエントリを任意の数だけ持たせることができる。
　ファイルをオープンすると、ファイルシステムは与えられたファイル名を用い、ディスクブロックを検出する。パス名/usr/ast/mboxの検出がどの様に行われるかを見てみることにしよう。これはＵＮＩＸにおける例であるが、階層化ディレクトリ・システムでは同様のアルゴリズムが用いられる。最初にファイルシステムがルートディレクトリを検索する。ＵＮＩＸではルートのｉノードはディスクの決まった場所に置かれている。
　次にパスの最初の部分であるusrを検出するため、ルートディレクトリを検索し、ファイル/usrに対するｉノードを得る。このｉノードから、システムは/usrのディレクトリを検出し、パス名の次の部分であるastを見つける。astのエントリを検出すると、ディレクトリ/usr/astのｉノードが得られたことになる。このｉノードからディレクトリ内容を取り出し、mboxを検索する。このファイルのｉノードはメモリに読み込まれ、ファイルがクローズされるまでメモリ内に置かれる。この検索の過程を図５．１１に示している。」
（第３０８頁第２８行から第３１０頁第１８行）
　
（Ｄ）「５．２．４　共有ファイル
　何人かのユーザが同じプロジェクトに携わっている時、ファイルの共有が必要になる。例えばそれぞれのユーザが所有しているそれぞれのディレクトリから、共有するファイルを同時に扱えると便利である。図５．１２には、図５．３（ｃ）のファイルシステムを再度示している。ただし今回は、ユーザＣのファイルが、ユーザＢのディレクトリにも現れている。ユーザＢのディレクトリと共有ファイルの関係をリンク(link)と呼んでいる。・・・（中略）・・・
　もう１つの方法では、システムに新しくＬＩＮＫ型のファイルを作成させることにより、ユーザＢがユーザＣのファイルの１つにリンクし、そのファイルをユーザＢのディレクトリに加える。新しいファイルにはリンクされたファイルのパス名だけが含まれている。Ｂがリンクされたファイルを読み取ると、オペレーティング・システムは読み取られているファイルがＬＩＮＫ型であると判断し、連結されたファイル名を検索し、そのファイルを読み取る。この様な方法はシンボリックリンク(symbolic linking)と呼ばれている。
・・・（中略）・・・
　シンボリックリンクでは、本当の所有者だけがｉノードを指すポインタを持つことになるため、前述した問題は発生しない。このファイルにリンクしたユーザは、ｉノードへのポインタではなく、パス名だけを与えられる。本当の所有者がファイルを削除すると、ファイルは破壊されてしまう。シンボリックリンクによるそのファイルへのアクセスは、システムがそのファイルを検出できなければ失敗に終わる。シンボリックリンクを削除してもファイルには何の影響もない。
　シンボリックリンクの問題点は、余分なオーバーヘッドの発生である。そのパスを含んでいるファイルを読み出し、次にそのパスを解析し、ｉノードにたどり着くまで、１つ１つ追跡していかなくてはならない。これらの作業においては多くの余分なディスクアクセスが必要である。さらに各シンボリックリンクに対してｉノードが１つ余分に必要になり、加えてパスを保存するための追加ディスクブロックも必要になる。ただしパス名が短い場合は、最適化のためにシステムはパス名をｉノード内部に保存する。シンボリックリンクにはマシンのネットワーク・アドレスと、そのマシン上のパス名を提供するだけで、世界中のどのマシンのファイルにもリンクできるという利点がある。」
（第３１１頁第９行から第３１３頁第１８行）
　
　上記（Ａ）には、ＵＮＩＸでは、ファイルシステムがディレクトリのツリーとして構成され、前記ディレクトリはファイルの一種である点が記載されている。
　上記（Ｂ）及び図５．７には、ＵＮＩＸでは、各ファイルに対応してｉノードと呼ばれるテーブルが用意され、ｉノードは、対応するファイルに関する情報と当該ファイルを構成するディスクブロックの番号のリストを含む点が記載されている。
　上記（Ｃ）及び図５．１１には、ＵＮＩＸでは、親ディレクトリにｉノード番号とファイル名を持つエントリすなわちディレクトリエントリが存在する点、及びファイルをオープンする際には、与えられたファイルのパス名に基づき、ディスクに保存されたディレクトリエントリとｉノードを検索して、前記ファイルに対応するディスクブロックの検出、すなわちパス名解決を行う点が記載されている。
　上記（Ｄ）には、ＵＮＩＸにおいて、リンク元のディレクトリにリンク先のファイルのパス名だけを含むＬＩＮＫ型のファイルすなわちシンボリックリンクを作成し、オペレーティング・システムは、該シンボリックリンクを読み取ると前記リンク先のファイルのパス名を検索する、シンボリックリンクによるファイルのリンク方法を用いる点、及び前記シンボリックリンクの問題点として、各シンボリックリンクに対して１つのｉノードとパスを保存するための追加ディスクブロックが必要になること及び余分なディスクアクセスが必要になることが挙げられるが、パス名をｉノード内部に保存することにより最適化、すなわち前記問題点の改善ができる点が記載されている。
　上記（Ｂ）、（Ｄ）の記載によれば、シンボリックリンクに対応するｉノードの内部にパス名を保存した場合、ｉノードには、シンボリックリンク以外のファイル用の、ディスクブロックの番号のリストを含むものと、シンボリックリンク用の、リンク先のファイルのパス名を含むものの２種類が存在することとなる。
　上記（Ｃ）、（Ｄ）の記載によれば、シンボリックリンクのパス名解決は、オペレーティングシステムが当該シンボリックリンクに対応するｉノードに保存されたリンク先のファイルのパス名を取り出し、前記パス名を検索することによって行われることは明らかである。
　引用例で言及されているＵＮＩＸが、ディスクなどの各種ファイルシステム上で、ファイルや、その管理情報であるｉノード及びディレクトリエントリの創成、削除、参照、更新などの管理を行う機能を有するオペレーティングシステムであること、及びファイル、ｉノード及びディレクトリエントリを創成する際に、前記ファイルへのディスクブロックの割り当て、前記ｉノード及びディレクトリエントリへの保存領域の割り当てを行っていることは当業者にとって自明である。
　
　したがって、引用例には、下記の発明（以下、「引用例に記載された発明」という。）が記載されている。
　
　ファイルシステム上でシンボリックリンク及びファイルの生成を行うオペレーティングシステムにおいて、
　iノード番号と、対応するファイルに関する情報と、前記対応するファイルをリンク元とするシンボリックリンクのリンク先のパス名または前記対応するファイルを構成するディスクブロックの番号のリストとを有するiノードが複数保存される領域と、iノード番号とファイル名から構成されるディレクトリエントリが保存される領域と、各ファイルを構成するディスクブロックとを有する前記ファイルシステムを有し、
　各ファイルに対応してiノードを用意し、
　各ファイルに対してディスクブロックを割り当て、
　シンボリックリンクの創成を行う場合、前記シンボリックリンクに対応するiノードを作成し、前記iノードにリンクするファイルのパス名を保存し、
　ファイルの創成を行う場合、前記ファイルに対応するiノードを作成し、前記ｉノードに前記ファイルを構成するディスクブロックの番号のリストを保存し、
　シンボリックリンク及びファイルの創成を行う場合に前記シンボリックリンク及びファイルの親ディレクトリに前記シンボリックリンク及びファイルに対応するディレクトリエントリを追加し、
　シンボリックリンクのパス名解決を行う場合、前記シンボリックリンクのiノードに保存されたリンク先のファイルのパス名を取り出す
各機能を有するオペレーティングシステム。
　
　
３． 対比
　本願発明と引用例に記載された発明とを対比する。
　引用例に記載された発明における、「シンボリックリンク」、「オペレーティングシステム」、「iノード番号」、「対応するファイルに関する情報」、「前記対応するファイルをリンク元とするシンボリックリンクのリンク先のパス名」、「前記対応するファイルを構成するディスクブロックの番号のリスト」、「iノード」、「ディスクブロック」は、それぞれ本願発明における「ソフトリンク」、「ファイル管理システム」、「エントリ識別子」、「エントリに関する情報」、「ソフトリンク情報」、「割り当てブロック参照域」、「ファイル管理部エントリ」、「データ記憶部」に相当する。
　引用例に記載された発明における、「各ファイルに対応してiノードを用意し」、「各ファイルに対してディスクブロックを割り当て」、「シンボリックリンクの創成を行う場合、前記シンボリックリンクに対応するiノードを作成し、前記iノードにリンクするファイルのパス名を保存し、ファイルの創成を行う場合、前記ファイルに対応するiノードを作成し、前記ｉノードに前記ファイルを構成するディスクブロックの番号のリストを保存し」、「シンボリックリンク及びファイルの創成を行う場合に前記シンボリックリンク及びファイルの親ディレクトリに前記シンボリックリンク及びファイルに対応するディレクトリエントリを追加し」、「シンボリックリンクのパス名解決を行う場合、前記シンボリックリンクのiノードに保存されたリンク先のファイルのパス名を取り出す」機能は、それぞれ、本願発明における「前記ファイル管理部にファイル管理部エントリとエントリ識別子を割り当てるエントリ操作手段」、「ファイルの創成を行う場合、前記データ記憶部を割り当てる通常ファイルアクセス手段」、「ソフトリンクの創成を行う場合、前記ファイル管理部エントリにエントリに関する情報とソフトリンク情報を設定し、ファイルの創成を行う場合、前記ファイル管理部エントリにエントリに関する情報と割り当てブロック参照域を設定するエントリアクセス手段」、「親ディレクトリに、前記エントリ識別子とファイル名から構成されるディレクトリエントリを追加するディレクトリアクセス手段」、「ソフトリンクのパス名解決を行う場合、前記ソフトリンク情報からパス名を取り出すパス名解決手段」の有する機能に対応する。
　　
　したがって、本願発明と引用例に記載された発明とは、
　
　ソフトリンクおよびファイルの創成を行うファイル管理システムにおいて、
　エントリ識別子とエントリに関する情報と、ソフトリンク情報または割り当てブロック参照域を有するファイル管理部エントリが複数あるファイル管理部と、データ記憶部とを有するファイルシステムを有し、
　前記ファイル管理部にファイル管理部エントリとエントリ識別子を割り当て、
　ファイルの創成を行う場合、前記データ記憶部を割り当て、
　ソフトリンクの創成を行う場合、前記ファイル管理部エントリにエントリに関する情報とソフトリンク情報を設定し、ファイルの創成を行う場合、前記ファイル管理部エントリにエントリに関する情報と割り当てブロック参照域を設定し、
　親ディレクトリに、前記エントリ識別子とファイル名から構成されるディレクトリエントリを追加し、
　ソフトリンクのパス名解決を行う場合、前記ソフトリンク情報からパス名を取り出す
各機能を備えるファイル管理システム。　
　
である点で一致し、次の点で相違する。
　
［相違点］
　本願発明においては、上記各機能が「エントリ操作手段」、「通常ファイルアクセス手段」、「エントリアクセス手段」、「ディレクトリアクセス手段」、「パス名解決手段」に割り当てられているのに対し、引用例に記載された発明は、上記各機能が複数の手段に割り当てられていない点。
　
　
４． 当審の判断
　上記相違点について検討する。
　引用例に記載された発明におけるオペレーティングシステムがコンピュータによって実行されるプログラムであることは明らかである。そして、コンピュータによって実行されるプログラムにおいて、前記プログラムが複数の機能からなる場合に、一つの機能毎に一つの処理ルーチンとし、前記複数の処理ルーチンを結合して前記プログラムを構成することは周知技術であり、前記各処理ルーチンは、コンピュータを前記各機能を実現する手段として動作させるものに他ならない。したがって、引用例に記載された発明を、複数の処理ルーチンとそれを実行するコンピュータによって実現される、それぞれ一つの機能が割り当てられた複数の手段により構成することは、前記周知技術に基いて当業者が容易になし得たことである。また、その際、前記複数の機能をどのように分割し各処理ルーチンに割り当てるかは、当業者が適宜なすべき設計的事項に過ぎない。
　
　
５．むすび
　したがって、本願発明は、引用例に記載された発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論の通り審決する。