2017-010913

特願２０１６－５２４８４８「ＰＯＳＩＸ互換なファイル・システム、ファイル・リストを生成する方法および記憶デバイス」拒絶査定不服審判事件〔平成２７年　６月２５日国際公開、ＷＯ２０１５／０９０６６８、平成２８年　９月　５日国内公表、特表２０１６－５２６７３７、請求項の数（１４）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本願は，２０１４年１０月１３日（パリ条約による優先権主張外国庁受理２０１３年１２月１７日，ドイツ）を国際出願日とする出願であって，平成２８年１月８日付けで手続補正がされ，平成２９年２月８日付けで拒絶理由通知がされ，平成２９年４月１１日付けで手続補正がされ，平成２９年４月１８日付けで拒絶査定（原査定）がされ，これに対し，平成２９年７月２１日に拒絶査定不服審判の請求がされると同時に手続補正がされ，平成２９年９月１９日付けで上申書が提出され，平成３０年６月６日付けで当審より拒絶理由通知がされ，平成３０年７月２０日付けで手続補正がされたものである。 第２　本願発明 本願請求項１－１４に係る発明（以下，それぞれ「本願発明１」－「本願発明１４」という。）は，平成３０年７月２０日付けの手続補正で補正された特許請求の範囲の請求項１－１４に記載された事項により特定される発明であり，本願発明１－１４は以下のとおりの発明である。 「　【請求項１】 少なくとも一つのディレクトリーおよび該ディレクトリーに記憶される複数のファイルを有するPOSIX互換なファイル・システムであって， ・それぞれのファイルに関係するメタデータをもつinodeが各ファイルに割り当てられ， ・前記ディレクトリーのディレクトリー・オブジェクトは前記複数のファイルのファイルにそれぞれ割り当てられるファイル名と前記inodeの数値アドレスとを含み， ・前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶され， ・それぞれのファイルに関係する前記メタデータは，少なくとも，割り当てられたファイルの前記ファイル名および前記少なくとも一つのディレクトリーに関係する情報を含み，前記少なくとも一つのディレクトリーに関係する前記情報は，該ディレクトリーに割り当てられたinodeへの参照，または，あらかじめ定義された基準点からの，前記割り当てられたファイルのパス指定を含み，それにより当該ファイル・システムにおけるファイル名および／またはパス指定は，前記inodeに記憶されている前記メタデータのみに基づいて，前記第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定できる， POSIX互換なファイル・システム。 【請求項２】 当該ファイル・システムは，WORMファイル・システムとして設計される，請求項１記載のPOSIX互換なファイル・システム。 【請求項３】 前記それぞれのファイルに関係するメタデータは，そのファイルが記憶されているディレクトリーへのパス指定（１３）および前記ファイル名（１４）自身をもつフル・パス指定（１２）を含む，請求項２記載のPOSIX互換なファイル・システム。 【請求項４】 前記ファイルに関係するメタデータは，さらに，当該ファイル・システムのあらかじめ定義された基準点，特にマウント点に割り当てられたinode（７ｒ）への参照（１９）を含む，請求項１記載のPOSIX互換なファイル・システム。 【請求項５】 前記ファイル名および前記少なくとも一つのディレクトリーに関係する情報が，当該ファイル・システムの拡張された属性に記憶される，請求項１記載のPOSIX互換なファイル・システム。 【請求項６】 POSIX互換なファイル・システムのファイルのファイル・リストを生成する方法であって： ・inodeに割り当てられる複数のファイルのメタデータを取得するために，inodeのあらかじめ定義されたリストをスキャンする段階であって，前記inodeの一つに記憶されている各ファイルについての前記メタデータは少なくとも，それぞれ割り当てられたファイルのファイル名およびそれぞれのファイルが記憶されているディレクトリーに関係する情報を含み，前記少なくとも一つのディレクトリーに関係する前記情報は，該ディレクトリーに割り当てられたinodeへの参照，または，あらかじめ定義された基準点からの，前記割り当てられたファイルのパス指定を含む，段階と； ・データ媒体の第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに，前記inodeに記憶されているメタデータに基づいて，ファイルのファイル名およびパス指定を決定する段階と； ・決定されたファイル名およびパス指定に基づいてファイル・リストを生成する段階とを含み， ・前記inodeは前記データ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶される， 方法。 【請求項７】 前記メタデータは少なくとも一つのさらなる属性（１６），特にそれぞれ割り当てられたファイルの最後のバックアップの日付を含み，前記少なくとも一つのさらなる属性は前記ファイル・リスト中に転記されるおよび／または前記ファイル・リスト中へのファイルの転記が前記少なくとも一つのさらなる属性に基づいて決定される，請求項６記載の方法。 【請求項８】 ・inodeのあらかじめ定義されたリストをスキャンする前記段階において，inodeのメタデータが少なくとも一つのあらかじめ定義された条件を満たすかどうかを判定する検査が実行され， ・ファイル・リストを生成する前記段階において，inodeに割り当てられるファイルについて，該それぞれのinodeのメタデータについて前記あらかじめ定義された条件が満たされる場合にのみ，エントリーが生成される， 請求項７記載の方法。 【請求項９】 POSIX互換なファイル・システムを提供するための必要な情報を記憶する記憶デバイスであって， ・当該記憶デバイスによって記憶されているファイルにアクセスするための少なくとも一つのインターフェースと， ・ファイルの不揮発性記憶のための少なくとも一つの大容量記憶システムとを有しており， 当該記憶デバイスは，前記少なくとも一つのインターフェースを介してファイルを書き込む書き込みコマンドを受領すると，前記少なくとも一つのファイルに関係するメタデータを前記大容量記憶システムの前記ファイルに関連付けられたinodeに記憶するよう構成されており，前記ファイルに関係する記憶されているメタデータは，少なくとも，そのファイルのファイル名およびそのファイルが記憶されているディレクトリーに関係する情報を含み，前記少なくとも一つのディレクトリーに関係する前記情報は，該ディレクトリーに割り当てられたinodeへの参照，または，あらかじめ定義された基準点からの，前記割り当てられたファイルのパス指定を含み，それにより当該ファイル・システムにおけるファイル名および／またはフル・パス指定は，前記inodeに記憶されている前記メタデータのみに基づいて，データ媒体の第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定でき， 前記inodeは前記データ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶される， 記憶デバイス。 【請求項１０】 当該記憶デバイスによって実行される少なくとも一つのソフトウェア・コンポーネントをさらに有しており，前記少なくとも一つのソフトウェア・コンポーネントは，データ媒体の第一の記憶領域に記憶されているメタデータに基づいて，特に請求項６ないし８のうちいずれか一項記載の方法に従って，ファイル・リストを生成するよう構成されている， 請求項９記載の記憶デバイス。 【請求項１１】 前記ソフトウェア・コンポーネントがファイル管理のために構成されており，データ媒体の第一の記憶領域に記憶されているメタデータに基づいてさらなる処理のためにファイルを選択する，請求項１０記載の記憶デバイス。 【請求項１２】 前記ソフトウェア・コンポーネントが，前記メタデータに記憶されている少なくとも一つの時間指定，特に前記メタデータに割り当てられたファイルの修正，生成および／またはバックアップ日に基づいてファイルをバックアップするよう構成されている，請求項１１記載の記憶デバイス。 【請求項１３】 前記少なくとも一つの大容量記憶システムのPOSIX互換なファイル・システムのファイルに割り当てられたinodeに前記メタデータを記憶するよう構成されている，請求項９記載の記憶デバイス。 【請求項１４】 選択されたファイルの，そのファイルのファイル名およびそのファイルが記憶されているディレクトリーに関係する情報を含む記憶されているメタデータの少なくとも一部を，前記少なくとも一つのインターフェース（５４）を介して拡張された属性として提供するよう構成されている，請求項１３記載の記憶デバイス。」 第３　引用文献，引用発明等 １．引用文献１について 原査定の拒絶の理由に引用された引用文献１（米国特許第７７５２２２６号明細書）には，図面とともに次の事項が記載されている。 Ａ　「SUMMARY Various embodiments of systems and methods for storing information identifying the parent directory of a file in that file's inode are disclosed. In one embodiment, a method may involve: reading the inode identifier of a parent directory of a file from an inode associated with the file; and using the parent directory's inode identifier to generate a pathname for the file. Generating the pathname may involve identifying the filename of the file by searching the parent directory, as identified by the parent directory's inode identifier, of the file for the file's inode identifier in order to retrieve the file's filename. In some embodiments, such a method may involve reading several parent directories' inode identifiers from the inode associated with the file and generating several pathnames for the file.」（第１欄４２－５７行） （当審仮訳：概要 ファイルのiノード内のファイルの親ディレクトリを特定する情報を記憶するためのシステムおよび方法の様々な実施形態が開示される。一実施形態において，方法は，以下を含む:ファイルに関連するiノードからファイルの親ディレクトリのiノード識別子を読み取ること，及び，ファイルのパス名を生成するために親ディレクトリのiノード識別子を使用すること。パス名を生成することは，ファイルの親ディレクトリ（親ディレクトリのiノード識別子によって識別される）において，ファイルのファイル名を検索するためにファイルのiノードの識別子を検索することによってファイルのファイル名を識別することを含み得る。いくつかの実施形態では，このような方法は，ファイルに関連するiノードからいくつかの親ディレクトリのiノードの識別子を読み取ること，及び，ファイルのためのいくつかのパス名を生成することを含み得る。） Ｂ　「FIGS. 3A-3B illustrate how an inode may include inode identifiers of more than one parent directory. In this example, there are two pathnames to the same file, as shown in FIG. 3A . The file inode is identified as inode 45 . In the first pathname, the file is named “hockey” and is included in the directory named “sports”. The inode for the “sports” directory is inode 32 . The “sports” directory is a subdirectory of the “joe” directory (inode 20 ), which is in turn a subdirectory of the “a” directory (inode 8 ). The “usr” directory is a subdirectory of the root directory. In the second pathname, the file is named “icehockey” and is included in directory “bob” (inode 24 ), which is a subdirectory of the “b” directory (inode 9 ). FIG. 3B illustrates how inode 45 may store parent directory inode identifiers 205 for both the “sports” directory and the “bob” directory, in addition to storing other metadata for the file. FIG. 4 illustrates one embodiment of a method of performing a reverse pathname lookup from a file's inode identifier. The file's inode identifier is used to access the file's inode within an inode table. At 401 , the inode identifier of the file's parent directory is retrieved from the file's inode. Given the identifier of the file's parent directory's inode, the parent directory may be opened at 403 and the filename of the file may be determined by searching the directory for the filename associated with the file's inode. The filename may be stored in a temporary buffer in some embodiments. If the parent directory is the root directory, as determined at 405 , and if there is only one parent directory inode identifier in the file's inode, as determined at 407 , the pathname for that file may be output (e.g., from a temporary buffer in which the filename was stored at 403 ) at 409 .」（第５欄３０－５９行） （当審仮訳：図3A－3Bは，iノードが，複数の親ディレクトリのiノード識別子をどのように含むかを示している。図3Aに示すように，この例では，同一のファイルに２つのパス名がある。ファイルのiノードは，iノード45として識別される。第1のパス名において，ファイルは“hockey”と名付けられ，“sports”と名付けられたディレクトリに含まれている。“sports”ディレクトリのiノードは，iノード32である。“sports”ディレクトリは“joe”ディレクトリ(iノード20)のサブディレクトリであり，“joe”ディレクトリは，今度は，“a”ディレクトリ(iノード8)のサブディレクトリである。“usr”ディレクトリは，ルートディレクトリのサブディレクトリである。第2のパス名において，ファイルは“icehockey”と名付けられ，“b”ディレクトリ(iノード9)のサブディレクトリであるディレクトリ“bob”(iノード24)に含まれている。図3Bは，iノード45が，ファイルの他のメタデータを記憶することに加えて，“sports”ディレクトリおよび“bob”ディレクトリの両方の親ディレクトリのiノード識別子205をどのように記憶するかを示している。 図４は，ファイルの iノード識別子から逆のパス名ルックアップを実行する方法の１つの実施形態を示す。ファイルの iノード識別子は iノードテーブルの中でファイルの iノードにアクセスするために使われる。４０１で，ファイルの親ディレクトリの iノード識別子はファイルの iノードから検索される。ファイルの親ディレクトリの iノード識別子が与えられると，親ディレクトリは４０３で開かれ，そしてファイルのファイル名は，ディレクトリでファイルの iノードと関連するファイル名を検索することによって，決定されるかもしれない。ファイル名はある実施形態では，一時バッファにストアされるかもしれない。４０５で決定されたとき，もし親ディレクトリがルートディレクトリであるなら，そして，４０７で決定されたとき，もしファイルの iノードにたった１つの親ディレクトリ iノード識別子しかないなら，そのファイルのパス名は４０９で（例えば，ファイル名が４０３でストアされた一時バッファから）出力されるかもしれない。） したがって，上記引用文献１には次の発明（以下，「引用発明１」という。）が記載されていると認められる。 「ファイルのiノード内のファイルの親ディレクトリを特定する情報を記憶するためのシステムであって， ファイルのiノード45は，ファイルの他のメタデータと親ディレクトリのiノード識別子205を記憶しており， ファイルのパス名を生成するために，ファイルに関連するiノードからファイルの親ディレクトリのiノード識別子を読み取り， ファイルの親ディレクトリの iノード識別子が与えられると，親ディレクトリが開かれ， ファイルのファイル名は，ディレクトリでファイルの iノードの識別子を検索することによって，ファイルの iノードと関連するファイル名が決定され， ファイル名は一時バッファにストアされ， もし親ディレクトリがルートディレクトリであり，もしファイルの iノードにたった１つの親ディレクトリ iノード識別子しかないなら， そのファイルのパス名が出力される， システム。」 ２．引用文献２について また，原査定の拒絶の理由に引用された引用文献２（国際公開第２０１３／１２１４５６号）には，図面とともに次の事項が記載されている。 Ｃ　「[0065]　Fig. 4 is an illustration showing the relationship between a file system and an inode management table T10 in simplified form. As shown at the top of Fig. 4, the file system, for example, comprises a superblock, an inode management table T10, and a data block. [0066]　The superblock, for example, is an area for collectively storing file system management information, such as the size of the file system and the file system free capacity. The inode management table T10 is management information for managing an inode, which is configured in each file. [0067]　One inode each is correspondingly managed for each directory or file in the file system. Of the respective entries in the inode management table T10, an entry comprising only directory information is called a directory entry. The inode in which a target file is stored can be accessed by using the directory entry to follow a file path. For example, when following "/home/user-01/a.txt" as shown in Fig. 4, the data block of the target file can be accessed by following inode #2 -> inode #10 -> inode #15 -> inode #100, in that order. [0068]　The inode in which the file entity is stored ("a.txt" in the example of Fig. 4), for example, comprises information such as the file owner, access privileges, the file size, and the data storage location. At the bottom of Fig. 4, the reference relationship between the inode and the data block is shown. The numerals 100, 200, 250 assigned to the data block in Fig. 4 denote a block address. The "u" displayed in the access privileges items is an abbreviation for user, the "g" is the abbreviation for group, and the "o" is the abbreviation for a person other than the user. Also, the "r" shown in the access privileges items is the abbreviation for read, the "x" is the abbreviation for execute, and the "w" is the abbreviation for write. The last access date/time is recorded as a combination of the year (four digits), month, day, hour, minute, and second. [0069]　Fig. 5 shows a state in which an inode is stored in the inode management table. In Fig. 5, inode numbers "2" and "100" are given as examples.」 （訳：（引用文献２の対応する日本語文献である特表２０１５－５０３７８０号公報の記載を引用した。以下，同じ。） 【００６５】 図４は，ファイルシステムとｉノード管理テーブルＴ１０との関係を簡略化して示す説明図である。図４の上側に示すように，ファイルシステムは，例えば，スーパーブロックと，ｉノード管理テーブルＴ１０と，データブロックなどから構成される。 【００６６】 スーパーブロックとは，例えば，ファイルシステムのサイズ及びファイルシステムの空き容量のような，ファイルシステムの管理情報を一括して保持するための領域である。ｉノード管理テーブルＴ１０は，各ファイルに設定されたｉノードを管理するための管理情報である。 【００６７】 ファイルシステムでは，各ディレクトリまたはファイルのそれぞれについて，１つずつのｉノードを対応させて管理する。ｉノード管理テーブルＴ１０の各エントリのうち，ディレクトリ情報のみ含むエントリを，ディレクトリエントリと呼ぶ。ディレクトリエントリを用いてファイルパスを辿ることで，目的のファイルが格納されているｉノードにアクセスすることができる。例えば，図４に示すように，「/home/user-01/a.txt」を辿る場合，ｉノード＃２→ｉノード＃１０→ｉノード＃１５→ｉノード＃１００の順に辿っていくことで，目的のファイルのデータブロックにアクセスすることができる。 【００６８】 ファイルの実体が格納されているｉノード（図４の例では「a.txt」）は，例えば，ファイルの所有権，アクセス権，ファイルサイズ，データ格納位置などの情報を有する。図４の下側には，ｉノードとデータブロックの参照関係が示されている。図４中のデータブロックに添えられた数字１００，２００，２５０は，ブロックアドレスを示す。アクセス権の項目に表示されている「ｕ」はユーザ，「ｇ」はグループ，「ｏ」はユーザ以外の者，のそれぞれの略である。また，アクセス権の項目に示されている「ｒ」はｒｅａｄ，「ｘ」はｅｘｅｃｕｔｅ，「ｗ」はｗｒｉｔｅ，のそれぞれの略である。最終アクセス日時は，西暦（４桁）と月日と時分秒の組合せとして記録される。 【００６９】 図５は，ｉノードがｉノード管理テーブルに格納された状態を示す。図５では，ｉノード番号「２」と「１００」を例に挙げて示している。） Ｄ　「［Fig.4］ ［Fig.5] 」 上記Ｃの記載と，上記Ｄの図４，図５の記載から，ｉノード＃１００のｉノードは，ファイル名を含むことが記載されている。 したがって，上記引用文献２には次の発明（以下，「引用発明２」という。）が記載されていると認められる。 「スーパーブロックと，ｉノード管理テーブルＴ１０と，データブロックなどから構成されるファイルシステムであって， ｉノード管理テーブルＴ１０は，各ファイルに設定されたｉノードを管理するための管理情報であり， ファイルシステムでは，各ディレクトリまたはファイルのそれぞれについて，１つずつのｉノードを対応させて管理し， ｉノード管理テーブルＴ１０の各エントリのうち，ディレクトリ情報のみ含むエントリを，ディレクトリエントリと呼び， ディレクトリエントリを用いてファイルパスを辿ることで，目的のファイルが格納されているｉノードにアクセスすることができ， 例えば，「/home/user-01/a.txt」を辿る場合，ｉノード＃２→ｉノード＃１０→ｉノード＃１５→ｉノード＃１００の順に辿っていくことで，目的のファイルのデータブロックにアクセスすることができ， ファイルの実体が格納されているｉノード＃１００のｉノードは，ファイル名を含む， ファイルシステム。」 ３．引用文献３について また，原査定の拒絶の理由に引用された引用文献３（特開２０１１－１３３９７１号公報）には，図面とともに次の事項が記載されている。 Ｅ　「【００５４】 図５は，メタデータの分散管理内容を示す図である。メタデータ管理部１４１は，図５に示したようなメタデータの分散管理を行う。すなわち，メタデータ管理部１４１は，ファイルシステムのメタデータの格納に使用する記憶装置１１０，１２１，１２２，１２３，・・・，１３１，１３２，１３３，・・・の記憶領域を，固定長領域２０と可変長領域３０とに分ける。そしてメタデータ管理部１４１は，固定長領域２０には固定長のinode配列および各inodeの使用状態の管理用の管理データを格納する。またメタデータ管理部１４１は，可変長領域３０にはinode以外のメタデータを格納し，そのメタデータをinodeと対応付けて管理する。 【００５５】 具体的には固定長領域２０は，inode管理領域２１とinode領域２２とに分かれている。inode管理領域２１には，inodeの使用の有無をビットマップ形式で示した管理データが格納されている。図５の例では，一列に示されている各ビットが，それぞれ対応するinodeの使用の有無を示している。各ビットの左端から順に，昇順のinode番号が割り振られている。そして各ビットの値が，そのビットに割り振られたinode番号で示されるinodeの使用の有無を示している。図５の例ではビットの値が「０」であれば未使用，「１」であれば使用中を示す。 【００５６】 inode領域２２には，inode配列が格納されている。inode配列は，複数のinodeをinode番号の順に一列に並べたものである。inodeの内容としては，ファイルの長さ（サイズ），ファイルを格納している装置のＩＤ，ファイル所有者のユーザＩＤ，ファイルのグループＩＤ，inode番号などが含まれる。 【００５７】 可変長領域３０は，inode以外のメタデータを管理する領域である。可変長領域３０には，inode以外のメタデータが書き込まれたメタデータファイルが格納される。各メタデータファイルは，inode番号に対応付けられている。例えば，メタデータファイルのファイル名の一部にinode番号が含まれる。ディレクトリに対応するメタデータファイルには，例えばディレクトリエントリファイルや拡張属性ファイルがある。ディレクトリエントリファイルには，ディレクトリに含まれるファイルのファイル名が格納される。拡張属性ファイルには，ディレクトリの拡張属性情報が格納される。ファイルに対応するメタデータファイルには，例えば，ＡＣＬエントリファイルや拡張属性ファイルがある。ＡＣＬエントリファイルには，ファイルへのアクセス制限に関する情報が格納される。拡張属性ファイルには，ファイルの拡張属性情報が格納される。 【００５８】 ここで，ディレクトリエントリファイルには，ディレクトリ内のファイルのファイル名とinode番号とが設定される。またディレクトリ内に下位構造のディレクトリがある場合，ディレクトリエントリファイルには，ディレクトリのディレクトリ名とinode番号とが設定される。ファイルにアクセスする場合，そのファイルのパスに沿ってディレクトリエントリファイルを辿って行くことで，アクセス対象のファイルのメタデータを取得できる。 【００５９】 さらにメタデータ管理部１４１は，inode領域と可変長領域とをグループ分けし，複数の記憶装置に分散格納する。 図６は，inode領域と可変長領域とのグループ分けを示す図である。メタデータ管理部１４１は，固定長領域２０のうちのinode領域２２内のinodeを複数のinodeグループ２２ａ，２２ｂ，・・・，２２ｎに分ける。各inodeグループ２２ａ，２２ｂ，・・・，２２ｎに，そのグループに属するinodeが含まれる。各inodeグループ２２ａ，２２ｂ，・・・，２２ｎは，個別の記憶装置に格納される。１つのinodeグループに属するinodeは，１または複数の記憶装置に格納される。 【００６０】 また可変長領域３０内のメタデータファイルも複数のメタデータファイルグループ３０ａ，３０ｂ，・・・，３０ｎに分けられる。メタデータファイルグループ３０ａ，３０ｂ，・・・，３０ｎは，inodeグループ２２ａ，２２ｂ，・・・，２２ｎに１対１で対応付けられている。メタデータファイルグループ３０ａ，３０ｂ，・・・，３０ｎ内には，対応するinodeグループ２２ａ，２２ｂ，・・・，２２ｎ内のinodeと同じinode番号に対応付けられたメタデータファイルが格納される。そのメタデータファイルには，inode番号で示されるファイルまたはディレクトリに対するinode以外のメタデータが書き込まれている。各メタデータファイルグループ３０ａ，３０ｂ，・・・，３０ｎは，個別の記憶装置に格納される。１つのメタデータファイルグループに属するメタデータファイルは，１または複数の記憶装置に格納される。 【００６１】 次に，メタデータファイルのパス名の生成方法について説明する。第２の実施の形態では，メタデータファイルのinode番号に基づいて，そのメタデータファイルのパス名を生成する。 【００６２】 図７は，inode番号に基づいて生成するメタデータファイルのパス名を示す図である。メタデータ管理部１４１は，inode以外のメタデータを格納するメタデータファイルを，inode番号４０に対応させたディレクトリ名およびファイル名を使って階層化したディレクトリ構造で管理する。そのためメタデータ管理部１４１は，inode番号４０に基づいて，そのinode番号４０に対応するメタデータファイルのパス名を決定する。 【００６３】 具体的には，inode番号４０を示すデータをｎ個（ｎは正の整数）に分割する。分割して得られた値（分割値）を，inode番号を示すデータのＭＳＢ（Most Significant Bit）側から順に，分割値Ｖｎ，Ｖｎ－１，・・・，Ｖ２，Ｖ１とする。なお各分割値Ｖｎ，Ｖｎ－１，・・・，Ｖ２，Ｖ１のビット長は，同じでなくてもよい。例えばＶｎのビット長を４ビット，その他の分割値Ｖｎ－１，・・・，Ｖ２，Ｖ１のビット長を１６ビットとすることができる。 【００６４】 メタデータ管理部１４１は，分割値Ｖｎ～Ｖ２をディレクトリの階層構造における各階層のディレクトリ名とする。またメタデータ管理部１４１は，分割値Ｖ１と種別符号の組み合わせをファイル名として付与する。ここで種別符号とは，メタデータファイルの内容の種別を示す符号である。例えばメタデータファイルがＡＣＬエントリファイルであれば，種別符号「Ａ」が付与される。またメタデータファイルが拡張属性ファイルであれば，種別符号「Ｅ」が付与される。」 Ｆ　「図７には，inode番号に基づいて生成するメタデータファイルのパス名がファイル名を含むことが記載されている。 したがって，上記引用文献３には，以下の引用文献３記載事項ア及び引用文献３記載事項イが記載されていると認められる。 （引用文献３記載事項ア） 「メタデータ管理部１４１は，ファイルシステムのメタデータの格納に使用する記憶装置１１０，１２１，１２２，１２３，・・・，１３１，１３２，１３３，・・・の記憶領域を，固定長領域２０と可変長領域３０とに分け， 固定長領域２０には固定長のinode配列および各inodeの使用状態の管理用の管理データを格納し， 可変長領域３０にはinode以外のメタデータを格納し，そのメタデータをinodeと対応付けて管理し， inode領域２２には，inode配列が格納されており， inodeの内容としては，ファイルの長さ（サイズ），ファイルを格納している装置のＩＤ，ファイル所有者のユーザＩＤ，ファイルのグループＩＤ，inode番号などが含まれ， 可変長領域３０は，inode以外のメタデータを管理する領域であり， 可変長領域３０には，inode以外のメタデータが書き込まれたメタデータファイルが格納され，各メタデータファイルは，inode番号に対応付けられており， ディレクトリに対応するメタデータファイルには，例えばディレクトリエントリファイルがあり， ディレクトリエントリファイルには，ディレクトリに含まれるファイルのファイル名が格納される。」 （引用文献３記載事項イ） 「inode番号に基づいて生成するメタデータファイルのパス名がファイル名を含むこと」 第４　対比・判断 １．本願発明１について （１）対比 原査定の内容からは，原査定時の主引用文献を明確に把握できないところ，引用文献１が，本願発明１と対比・判断する上で最も適切と考えられるので，引用文献１を主引用文献として選択する。 本願発明１と引用発明１とを対比すると，次のことがいえる。 （ア）引用発明１の「ファイル」，「ディレクトリ」が本願発明１の「ファイル」，「ディレクトリー」にそれぞれ相当し，引用発明１は，「ファイルの親ディレクトリの iノード識別子が与えられると，親ディレクトリが開かれ，ファイルのファイル名は，ディレクトリでファイルの iノードの識別子を検索することによって，ファイルの iノードと関連するファイル名が決定され」る「システム」であるから，本願発明１とは，後記する点で相違するものの，「少なくとも一つのディレクトリーおよび該ディレクトリーに記憶される複数のファイルを有するファイル・システム」である点で一致する。 （イ）引用発明１の「ファイルのiノード45」は，「ファイルの他のメタデータと親ディレクトリのiノード識別子205」を記憶しているところ，引用発明１の「ファイルの他のメタデータと親ディレクトリのiノード識別子205」は本願発明１の「それぞれのファイルに関係するメタデータ」に相当するものであるから，引用発明１の「ファイルの他のメタデータと親ディレクトリのiノード識別子205」を「記憶」する「ファイルのiノード45」が本願発明１の「それぞれのファイルに関係するメタデータをもつinode」に相当し，当該「inode 」は，「各ファイルに割り当てられ」ているといえる。 （ウ）引用発明１において，「ファイルの親ディレクトリの iノード識別子が与えられると，親ディレクトリが開かれ，ファイルのファイル名は，ディレクトリでファイルの iノードの識別子を検索することによって，ファイルの iノードと関連するファイル名が決定され」るものであるから，「ファイルの親ディレクトリ」には，「ファイルのファイル名」と当該ファイルの「 iノードの識別子」が記憶されていることは明らかである。また，引用発明１の「親ディレクトリ」は，本願発明１の「ディレクトリーのディレクトリー・オブジェクト」に実質的に相当するものであり，引用発明１の「ファイル名」，「ファイルの iノードの識別子」が本願発明１の「ファイル名」，「inodeの数値アドレス」に相当するから，引用発明１と本願発明１とは，「ディレクトリーのディレクトリー・オブジェクトは複数のファイルのファイルにそれぞれ割り当てられるファイル名とinodeの数値アドレスとを含」む点で一致する。 （エ）上記（イ）より，引用発明１の「ファイルの他のメタデータと親ディレクトリのiノード識別子205」は本願発明１の「それぞれのファイルに関係するメタデータ」に相当するものであるところ，前記「親ディレクトリのiノード識別子205」は，「少なくとも一つのディレクトリーに関係する情報」ともいえることから，引用発明１と本願発明１とは，後記する点で相違するものの，「それぞれのファイルに関係するメタデータは，少なくとも一つのディレクトリーに関係する情報を含」む点で一致する。 （オ）上記（エ）より，引用発明１の「親ディレクトリのiノード識別子205」は，本願発明１の「少なくとも一つのディレクトリーに関係する情報」ともいえるものであるところ，前記「親ディレクトリのiノード識別子205」は，「ディレクトリーに割り当てられたinodeへの参照」に他ならないから，引用発明１と本願発明１とは，「少なくとも一つのディレクトリーに関係する情報は，該ディレクトリーに割り当てられたinodeへの参照を含」む点で一致する。 したがって，本願発明１と引用発明１との間には，次の一致点，相違点があるといえる。 （一致点） 「少なくとも一つのディレクトリーおよび該ディレクトリーに記憶される複数のファイルを有するファイル・システムであって， ・それぞれのファイルに関係するメタデータをもつinodeが各ファイルに割り当てられ， ・前記ディレクトリーのディレクトリー・オブジェクトは前記複数のファイルのファイルにそれぞれ割り当てられるファイル名と前記inodeの数値アドレスとを含み， ・それぞれのファイルに関係する前記メタデータは，前記少なくとも一つのディレクトリーに関係する情報を含み，前記少なくとも一つのディレクトリーに関係する前記情報は，該ディレクトリーに割り当てられたinodeへの参照を含む， ファイル・システム。」 （相違点） （相違点１）本願発明１は「POSIX互換なファイル・システム」であるのに対し，引用発明１はそのような特定はなされていない点。 （相違点２）本願発明１は「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶され」ているのに対して，引用発明１はそのような構成を備えていない点。 （相違点３）本願発明１の「それぞれのファイルに関係するメタデータ」は，「少なくとも，割り当てられたファイルのファイル名」を含むのに対して，引用発明１の「ファイルの他のメタデータと親ディレクトリのiノード識別子205」には，「ファイルのファイル名」は含まれていない点。 （相違点４）本願発明１では，「ファイル・システムにおけるファイル名および／またはパス指定は，inodeに記憶されているメタデータのみに基づいて，第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定できる」のに対して，引用発明１は，そのように構成されていない点。 （２）相違点についての判断 事案に鑑み，上記相違点２－４についてまとめて検討すると，本願発明１は，「特に図２Ａに基づく表現に示されるように，図２Ｂに基づく方法は，第一の記憶領域５と第二の記憶領域６との間の行ったり来たりの規則的なジャンプを引き起こし，その理由は，特に，関連付けられたディレクトリー・オブジェクト８およびファイル・オブジェクト９は，第一の記憶領域５からのinode ７の情報を読むことなくしては，第二の記憶領域６内で位置特定されることができないということであり，逆に，たとえば個々のファイルの名前およびパス指定を定義するためまたはディレクトリー木１の階層構造を決定するために，第一の記憶領域５のinode ７においてすべての情報が利用可能ではないために，実際上，この手順は，ファイル・リスト１０を生成するために，書き込み／読み出しヘッドまたは物理的なデータ媒体４の他の読み出しデバイスの頻繁な再位置決めが必要とされるという欠点をもち，特に，アーカイブ・システムにおいて見られるような非常に大きなファイル集合の場合，これは，実際上，長いトランジット遅延につながり，よって頻繁に走るプロセスの場合には問題になる」（本願明細書の段落【００４３】）ことを課題としてなされた発明であり，この課題を解決するために，「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶され」（相違点１）るという前提構成のもとにおいて，「それぞれのファイルに関係する前記メタデータ」が，少なくとも一つのディレクトリーに関係する情報に加えて，「少なくとも，割り当てられたファイルのファイル名」を含む（相違点２）ように構成することにより，当該ファイル・システムにおけるファイル名および／またはパス指定は，前記inodeに記憶されている前記メタデータのみに基づいて，前記第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定できる」（相違点３）ようにしたものである。 これに対して，引用文献１には，「An inode does not include the filename of the file to which the inode corresponds. Because of this, it is relatively difficult to determine the filename of a file, given only information identifying that file's inode. For example, in UNIX, programs such as ff(7) and ncheck(1M) provide mechanisms for determining the pathname of a file from an inode identifier (also referred to as a performing a reverse pathname lookup) by scanning each directory in the file system for the inode identifier. Scanning each directory may take an undesirable amount of time.」（第１欄３１－４０行）（当審仮訳： iノードは，iノードに対応するファイルのファイル名を含んでいない。このため，そのファイルのiノードを識別する情報のみを与えられて，ファイルのファイル名を決定することは比較的困難である。例えば，UNIXでは，ff(7)およびncheck(1M)のようなプログラムは，ファイルシステム内の各ディレクトリのiノード識別子を走査することによって，inode識別子からファイルのパス名を決定するための機構(パス名ルックアップを実行するとも称される)を提供する。各ディレクトリを走査することは，望ましくない時間量を取り得る。）と記載されていて，ファイル名或いはパス名を特定するために，ディレクトリを走査することの問題点を挙げている点で，本願発明１と同様の課題を有するものではあるものの，本願発明１では，ファイル名が，ファイルに割り当てられたinode内に直接記憶されているのに対して，引用発明１では，ファイルの親ディレクトリ内に記憶されていて，当該親ディレクトリ内に記憶されているファイル名を，ファイルのinode内に直接記憶させる構成は記載も示唆もされていない。 この点について，引用発明２は，「スーパーブロックと，ｉノード管理テーブルＴ１０と，データブロックなどから構成されるファイルシステム」において，「ファイルの実体が格納されているｉノード＃１００のｉノードは，ファイル名を含む」ことが特定されるものの，引用文献２の課題は，「[0004] In the case of the prior art, since a file that the user uses infrequently is moved to the data center-side file server, when the user tries to access this file, access takes a long time. This is because the user-side file server must acquire the access-target file from the data center-side file server by way of a communication network such as a WAN (Wide Area Network). Therefore, in comparison to a file stored in the user-side file server, response performance drops greatly and user usability also declines when a file is stored on the data center-side file server.」（訳：［０００４］従来技術の場合，ユーザの使用頻度の低いファイルはデータセンタ側のファイルサーバに移動されるため，ユーザがそのファイルにアクセスしようとする場合に，アクセス時間が長くなる。ユーザ側のファイルサーバは，ＷＡＮ（Wide Area Network）などの通信ネットワークを介してデータセンタ側のファイルサーバから，アクセス対象のファイルを取得する必要があるためである。従って，ユーザ側のファイルサーバにファイルが格納されている場合に比べて，データセンタ側のファイルサーバにファイルが格納されている場合は，大幅に応答性能が低下し，ユーザの使い勝手も低下する。）というものであり，引用発明１とは課題の設定が異なっており，引用発明２に，「ファイルの実体が格納されているｉノード＃１００のｉノードは，ファイル名を含む」ことが特定されているからといって，直ちに，この技術を引用発明１に適用できるというものではなく，また，引用発明１に，そのような技術を採用する動機付けがあるとも認められない。 また，引用文献３記載事項アには，inode以外のメタデータが書き込まれたメタデータファイルが格納される可変長領域３０の，ディレクトリに対応するメタデータファイルであるディレクトリエントリファイルに，ディレクトリに含まれるファイルのファイル名が格納されることは記載されているものの，ファイルのinodeにファイル名を格納することは記載されていない。さらに，引用文献３記載事項イは，単に「inode番号に基づいて生成するメタデータファイルのパス名がファイル名を含むこと」を記載するだけであり，ファイルのinodeにファイル名を格納することを記載するものではない。 そうすると，当業者であっても，引用発明１に引用発明２及び引用文献３記載事項ア，イを適用して，上記相違点２－４に係る構成を容易に想到することができたとはいえない。 したがって，上記相違点１について判断するまでもなく，本願発明１は，当業者であっても引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明できたものであるとはいえない。 ２．本願発明２－５について 本願発明２－５は，本願発明１を直接・間接に引用するものであり，上記相違点２－４に係る構成と同一の構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明できたものとはいえない。 ３．本願発明６について 本願発明６は，本願発明１に対応する方法の発明であり，上記相違点２－４に係る構成に対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明できたものとはいえない。 ４．本願発明７－８について 本願発明７－８は，本願発明６を直接・間接に引用するものであり，上記相違点２－４に係る構成に対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明できたものとはいえない。 ５．本願発明９について 本願発明９は，本願発明１に対応する記憶デバイスの発明であり，上記相違点２－４に係る構成に対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明できたものとはいえない。 ６．本願発明１０－１４について 本願発明１０－１４は，本願発明９を直接・間接に引用するものであり，上記相違点２－４に係る構成に対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明できたものとはいえない。 第５　原査定の概要及び原査定についての判断 原査定は，請求項１－１５について上記引用文献１－３に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができないというものである。しかしながら，平成２９年７月２１日付け手続補正により補正された請求項１，６，９は，それぞれ，上記相違点２－４に係る構成に対応する構成を有するものとなっており，上記のとおり，本願発明１－１４は，引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて，当業者が容易に発明できたものではない。したがって，原査定を維持することはできない。 第６　当審拒絶理由について １．特許法第３６条第６項第２号について （１）当審では，請求項１の「前記ディレクトリーは前記複数のファイルのファイル名とファイルにそれぞれ割り当てられる前記inodeとの間の割り当てを含み」との記載における，「ファイルにそれぞれ割り当てられる前記inodeとの間の割り当て」とは，如何なる事項を特定しようとしているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付けの手続補正において，「前記ディレクトリーのディレクトリー・オブジェクトは前記複数のファイルのファイルにそれぞれ割り当てられるファイル名と前記inodeの数値アドレスとを含み」と補正された結果，この拒絶の理由は解消した。 （２）当審では，請求項１の「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の領域に記憶され」との記載における「データ媒体の第一の記憶領域」と，「前記データ媒体の第二の領域」とは，用語が整合しておらず，不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付けの手続補正において，「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶され」と補正された結果，この拒絶の理由は解消した。 （３）当審では，請求項１の「それにより当該ファイル・システムにおけるファイル名および／またはパス名は，前記inodeに記憶されている前記メタデータのみに基づいて，当該ファイル・システムの他のデータ・ブロックにアクセスする必要なしに決定できる」との記載における「パス名」の用語は，本願明細書の発明の詳細な説明には使用されていない用語であるため，当該用語によって，本願明細書に記載されているどの事項を特定しようとしているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付けの手続補正において，「それにより当該ファイル・システムにおけるファイル名および／またはパス指定は，前記inodeに記憶されている前記メタデータのみに基づいて，前記第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定できる」と補正された結果，この拒絶の理由は解消した。 （４）当審では，請求項１の「当該ファイル・システムの他のデータ・ブロックにアクセスする必要なしに決定できる」との記載における「他のデータ・ブロック」とは，如何なる「データ・ブロック」のことを指しているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付けの手続補正において，「前記第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定できる」と補正された結果，この拒絶の理由は解消した。 （５）当審では，請求項７の「それぞれの場合においてinodeに割り当てられる複数のファイルのメタデータを取得するために，inodeのあらかじめ定義された群をスキャンする段階であって」との記載における「それぞれの場合」とは，如何なる「場合」のことを意味しているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項７に対応する請求項６において，「それぞれの場合において」との記載が削除された結果，この拒絶の理由は解消した。 （６）当審では，請求項７の「inodeに割り当てられる複数のファイルのメタデータを取得するために，inodeのあらかじめ定義された群をスキャンする段階であって」との記載における「群」と，請求項７を間接的に引用する請求項９の「inodeのあらかじめ定義されたリストをスキャンする前記段階において」との記載における「リスト」との関係が不明確である旨の拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項７に対応する請求項６において，「inodeに割り当てられる複数のファイルのメタデータを取得するために，inodeのあらかじめ定義されたリストをスキャンする段階であって」と補正された結果，この拒絶の理由は解消した。 （７）当審では，請求項７の「純粋に前記inodeに記憶されているメタデータに基づいて，ファイルのファイル名およびパス指定を定義する段階」との記載における「純粋に」とは，如何なる構成を意味しているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項７に対応する請求項６において，「前記inodeに記憶されているメタデータに基づいて，ファイルのファイル名およびパス指定を決定する段階」と補正された結果，この拒絶の理由は解消した。 （８）当審では，請求項７の「純粋に前記inodeに記憶されているメタデータに基づいて，ファイルのファイル名およびパス指定を定義する段階」との記載における「ファイル名およびパス指定を定義する」とはどのような処理のことを意味しているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項７に対応する請求項６において，「前記inodeに記憶されているメタデータに基づいて，ファイルのファイル名およびパス指定を決定する段階」と補正された結果，この拒絶の理由は解消した。 （９）当審では，請求項７の「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の領域に記憶される」との記載における「データ媒体の第一の記憶領域」と「前記データ媒体の第二の領域」とは，用語が整合しておらず，不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項７に対応する請求項６において，「前記inodeは前記データ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶される」と補正された結果，この拒絶の理由は解消した。 （１０）当審では，請求項１０には，「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の領域に記憶される」構成は特定されるものの，その構成を有することが，結果として，どのような作用効果につながるものであるのかについては，明確な特定がなされていないため，請求項１０に記載された発明が，全体としてどのような内容の発明であるのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項１０に対応する請求項９において，「それにより当該ファイル・システムにおけるファイル名および／またはフル・パス指定は，前記inodeに記憶されている前記メタデータのみに基づいて，データ媒体の第二の記憶領域に記憶されるデータ・ブロックにアクセスする必要なしに決定でき」との構成を追加する補正がなされた結果，この拒絶の理由は解消した。 （１１）当審では，請求項１０の「前記inodeはデータ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の領域に記憶される」との記載における「データ媒体の第一の記憶領域」と「前記データ媒体の第二の領域」とは用語が整合しておらず不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項１０に対応する請求項９において，「前記inodeは前記データ媒体の第一の記憶領域に記憶され，ディレクトリー・オブジェクトおよびファイル・オブジェクトは前記データ媒体の第二の記憶領域に記憶される」と補正された結果，この拒絶の理由は解消した。 （１２）当審では，請求項１１の「純粋に記憶されているメタデータに基づいて」との記載における「純粋に記憶されている」とはどのような技術的事項を意味しているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項１１に対応する請求項１０において，「データ媒体の第一の記憶領域に記憶されているメタデータに基づいて」と補正された結果，この拒絶の理由は解消した。 （１３）当審では，請求項１２の「純粋に記憶されているメタデータに基づいて」との記載における「純粋に記憶されている」とはどのような技術的事項を意味しているのかが不明確であるとの拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項１２に対応する請求項１１において，「データ媒体の第一の記憶領域に記憶されているメタデータに基づいて」と補正された結果，この拒絶の理由は解消した。 ２．特許法第３６条第６項第１号について （１）当審では，請求項１の「前記ディレクトリーは前記複数のファイルのファイル名とファイルにそれぞれ割り当てられる前記inodeとの間の割り当てを含み」との記載は本願明細書の発明の詳細な説明に記載されたものではないとの拒絶の理由を通知しているが，平成３０年７月２０日付けの手続補正において，「前記ディレクトリーのディレクトリー・オブジェクトは前記複数のファイルのファイルにそれぞれ割り当てられるファイル名と前記inodeの数値アドレスとを含み」と補正された結果，この拒絶の理由は解消した。 （２）当審では，請求項９の「・inodeのあらかじめ定義されたリストをスキャンする前記段階において，inodeのメタデータが少なくとも一つのあらかじめ定義された条件を満たすかどうかを判定する検査が実行され， ・ファイル・リストを生成する前記段階において，inodeに割り当てられるファイルについて，該それぞれのinodeのメタデータについて前記あらかじめ定義された条件が満たされる場合にのみ，エントリーが生成される，」との記載は本願明細書の発明の詳細な説明に記載されたものではないとの拒絶の理由を通知しているが，平成３０年７月２０日付けの意見書において，「請求項９に関し，００１６は「ファイルのバックアップが，メタデータに記憶されている少なくとも一つの時間指定……に基づいて実行されることができる。」と記載しています。さらに，００５６は「たとえば最後のバックアップ時刻以降に修正されたファイルのファイル名のみを記録するアーカイブ・システムにおいて，多数のinode　７が事前フィルタリングに基づいてこの処理からすでに除外されることができる場合」を記載しています。これらの例「メタデータに記憶されている少なくとも一つの時間指定」，「最後のバックアップ時刻以降に修正されたファイル」が「条件」の例を定義しており，請求項９記載の発明は発明の詳細な説明に記載されたものであると思料します。」との釈明により，この拒絶の理由は解消した。 （３）当審では，請求項１０は「記憶デバイス」の発明であると把握されるところ，「記憶デバイス」が，「POSIX互換なファイル・システムを提供するための必要な情報を記憶する」ものを前提としない発明は，発明の詳細な説明に記載されていない旨の拒絶の理由を通知しているが，平成３０年７月２０日付け手続補正で補正された，補正前の請求項１０に対応する請求項９において，「POSIX互換なファイル・システムを提供するための必要な情報を記憶する記憶デバイスであって」と補正された結果，この拒絶の理由は解消した。 第７　むすび 以上のとおり，本願発明１－１４は，当業者が引用発明１，引用発明２，及び引用文献３記載事項ア，イに基づいて容易に発明をすることができたものではない。 したがって，原査定の理由によっては，本願を拒絶することはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。