2019-016713

特願２０１７－５６２０３５「分散ファイルシステムの複数のクラスタの管理」拒絶査定不服審判事件〔平成３０年　５月２４日国際公開，ＷＯ２０１８／０９０６７４，平成３０年１２月２０日国内公表，特表２０１８－５３７７３６〕について，次のとおり審決する。

【結　論】 本件審判の請求は，成り立たない。

【理　由】 第１　手続の経緯 本願は，２０１７年８月７日（パリ条約による優先権主張外国庁受理２０１６年１１月１６日（以下，「優先日」という。），アメリカ合衆国）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。 平成２９年１１月２９日　　：出願審査請求書，補正書の提出 平成３０年１２月　６日付け：拒絶理由通知 平成３１年　３月１５日　　：意見書，手続補正書の提出 令和　１年　８月１４日付け：拒絶査定 令和　１年１２月１０日　　：審判請求書，手続補正書の提出 令和　２年　２月１０日　　：前置報告書 令和　２年　５月２１日　　：上申書の提出 第２　令和１年１２月１０日にされた手続補正についての補正の却下の決定 ［補正の却下の決定の結論］ 令和１年１２月１０日にされた手続補正（以下，「本件補正」という。）を却下する。 ［理由］ １　本件補正について（補正の内容） （１）本件補正後の特許請求の範囲の記載 本件補正により，特許請求の範囲の請求項１～２４の記載は，次のとおり補正された。（下線部は，補正箇所である。以下，この特許請求の範囲に記載された請求項を「補正後の請求項」という。） 「　　【請求項１】 分散ファイルシステムの複数のクラスタを管理するためのシステムであって、前記複数のクラスタはクラスタファイルを有し、前記システムは、 少なくとも1つの処理ユニットと、 前記少なくとも1つの処理ユニットに通信可能に結合された非一時的メモリとを含み、前記非一時的メモリは、前記少なくとも1つの処理ユニットによって実行可能な、 ユーザデバイス上のアプリケーションから、新しいクラスタファイルを作成するための要求を受信し、 前記新しいクラスタファイルに対応するクラスタ管理ファイルを作成し、 前記クラスタ管理ファイルに論理ファイル名を割り当て、且つ、前記新しいクラスタファイルに物理ファイル名を割り当て、 前記複数のクラスタにおいて、前記新しいクラスタファイルのための物理ファイル位置を割り当て、前記新しいクラスタファイルのための物理ファイル位置を割り当てることは、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つを選択することを含み、 前記クラスタ管理ファイルを前記新しいクラスタファイルにマッピングするメタデータを、前記クラスタ管理ファイルに記憶し、前記メタデータは、前記物理ファイル名および前記物理ファイル位置を含み、 前記物理ファイル名を使用して、前記新しいクラスタファイルを作成するための前記要求を、前記物理ファイル位置に対応する前記クラスタの1つに送信し、 前記論理ファイル名を使用して、前記新しいクラスタファイルの作成を前記アプリケーションに確認応答するためのコンピュータ可読プログラム命令を含む、システム。 【請求項２】 前記分散ファイルシステムは、Hadoop分散ファイルシステムまたはHadoop互換ファイルシステムである、請求項1に記載のシステム。 【請求項３】 前記プログラム命令は、前記アプリケーションおよび前記クラスタと通信するための少なくとも1つのクライアントコンポーネント、および、前記メタデータを生成および記憶するための少なくとも1つのマネージャコンポーネントを実施するために実行可能である、請求項1または2に記載のシステム。 【請求項４】 前記少なくとも1つのクライアントコンポーネントは、各々が異なるユーザアプリケーションとインタフェースするように構成される、複数のクライアントコンポーネントを含む、請求項3に記載のシステム。 【請求項５】 前記少なくとも1つのマネージャコンポーネントは、各々が前記複数のクラスタの異なるグループとインタフェースするように構成される、複数のマネージャコンポーネントを含む、請求項3に記載のシステム。 【請求項６】 前記プログラム命令は、前記システムを仮想マシンとして実施するために実行可能である、請求項1乃至5のいずれか1項に記載のシステム。 【請求項７】 分散ファイルシステムの複数のクラスタを管理するための方法であって、前記複数のクラスタはクラスタファイルを有し、前記方法は、 ユーザデバイス上のアプリケーションから、新しいクラスタファイルを作成するための要求を受信するステップと、 前記新しいクラスタファイルに対応するクラスタ管理ファイルを作成するステップと、 前記クラスタ管理ファイルに論理ファイル名を割り当て、且つ、前記新しいクラスタファイルに物理ファイル名を割り当てるステップと、 前記複数のクラスタから、前記新しいクラスタファイルのための物理ファイル位置を割り当てるステップであって、前記新しいクラスタファイルのための物理ファイル位置を割り当てるステップは、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する最も近い1つを選択するステップを含む、ステップと、 前記クラスタ管理ファイルを前記新しいクラスタファイルにマッピングするメタデータを、前記クラスタ管理ファイルに記憶するステップであって、前記メタデータは、前記物理ファイル名および前記物理ファイル位置を含む、ステップと、 前記物理ファイル名を使用して、前記新しいクラスタファイルを作成するための前記要求を、前記物理ファイル位置に対応する前記クラスタの1つに送信するステップと、 前記論理ファイル名を使用して、前記新しいクラスタファイルの作成を前記アプリケーションに確認応答するステップとを含む方法。 【請求項８】 前記新しいクラスタファイルを作成するための前記要求を、第1のフォーマットから第2のフォーマットへ変換するステップをさらに含み、前記アプリケーションは前記第1のフォーマットをサポートし、且つ、前記クラスタは前記第2のフォーマットをサポートする、請求項7に記載の方法。 【請求項９】 前記新しいクラスタファイルにアクセスするための要求を受信するステップであって、前記要求は、前記論理ファイル名を含む、ステップと、 前記論理ファイル名を使用して、前記新しいクラスタファイルに対応する前記メタデータを検索するステップと、 前記メタデータから、前記物理ファイル名および前記物理ファイル位置を決定するステップと、 前記物理ファイル名を使用して、前記新しいクラスタファイルにアクセスするための前記要求を、前記クラスタのうちの少なくとも1つに送信するステップとをさらに含む、請求項7または8に記載の方法。 【請求項１０】 前記新しいクラスタファイルにアクセスするための前記要求を送信するステップは、システム性能、システム一貫性、ローカルデータ利用可能性および前記クラスタにわたるロードバランシングのうちの少なくとも1つを考慮することによって、前記少なくとも1つのクラスタを選択するステップを含む、請求項9に記載の方法。 【請求項１１】 分散ファイルシステムの複数のクラスタを管理するための、プロセッサによって実行可能なプログラム命令がその上に記憶されるコンピュータ可読媒体であって、前記複数のクラスタはクラスタファイルを有し、前記プログラム命令は、 ユーザデバイス上のアプリケーションから、新しいクラスタファイルを作成するための要求を受信し、 前記新しいクラスタファイルに対応するクラスタ管理ファイルを作成し、 前記クラスタ管理ファイルに論理ファイル名を割り当て、且つ、前記新しいクラスタファイルに物理ファイル名を割り当て、 前記複数のクラスタにおいて、前記新しいクラスタファイルのための物理ファイル位置を割り当て、前記新しいクラスタファイルのための物理ファイル位置を割り当てることは、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つを選択することを含み、 前記クラスタ管理ファイルを前記新しいクラスタファイルにマッピングするメタデータを、前記クラスタ管理ファイルに記憶し、前記メタデータは、前記物理ファイル名および前記物理ファイル位置を含み、 前記物理ファイル名を使用して、前記新しいクラスタファイルを作成するための前記要求を、前記物理ファイル位置に対応する前記クラスタの1つに送信し、 前記論理ファイル名を使用して、前記新しいクラスタファイルの作成を前記アプリケーションに確認応答するように構成される、コンピュータ可読媒体。 【請求項１２】 分散ファイルシステムの複数のクラスタを管理するためのシステムであって、前記複数のクラスタはクラスタファイルを有し、前記システムは、 少なくとも1つの処理ユニットと、 前記少なくとも1つの処理ユニットに通信可能に結合された非一時的メモリとを含み、 前記非一時的メモリは、前記少なくとも1つの処理ユニットによって実行可能な、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信し、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信され、 前記論理ファイル名を使用して、メタデータを検索し、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルであり、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定し、前記物理ファイル位置は、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つであり、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの1つに送信するためのコンピュータ可読プログラム命令を含む、システム。 【請求項１３】 前記分散ファイルシステムは、Hadoop分散ファイルシステムまたはHadoop互換ファイルシステムである、請求項12に記載のシステム。 【請求項１４】 前記プログラム命令は、前記アプリケーションおよび前記クラスタと通信するための少なくとも1つのクライアントコンポーネント、および、前記メタデータを生成および記憶するための少なくとも1つのマネージャコンポーネントを実施するために実行可能である、請求項12または13に記載のシステム。 【請求項１５】 前記少なくとも1つのクライアントコンポーネントは、各々が異なるユーザアプリケーションとインタフェースするように構成される、複数のクライアントコンポーネントを含む、請求項14に記載のシステム。 【請求項１６】 前記少なくとも1つのマネージャコンポーネントは、各々が前記複数のクラスタの異なるグループとインタフェースするように構成される、複数のマネージャコンポーネントを含む、請求項14に記載のシステム。 【請求項１７】 前記プログラム命令は、前記システムを仮想マシンとして実施するために実行可能である、請求項12乃至16のいずれか1項に記載のシステム。 【請求項１８】 分散ファイルシステムの複数のクラスタを管理するための方法であって、前記複数のクラスタはクラスタファイルを有し、前記方法は、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信するステップであって、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信される、ステップと、 前記論理ファイル名を使用して、メタデータを検索するステップであって、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルである、ステップと、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップであって、前記物理ファイル位置は、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つである、ステップと、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記クラスタのうちの少なくとも1つに送信するステップとを含む方法。 【請求項１９】 前記クラスタファイルにアクセスするための前記要求を、第1のフォーマットから第2のフォーマットへ変換するステップをさらに含み、前記アプリケーションは前記第1のフォーマットをサポートし、且つ、前記クラスタは前記第2のフォーマットをサポートする、請求項18に記載の方法。 【請求項２０】 前記クラスタファイルにアクセスするための前記要求を送信するステップは、前記メタデータから、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの前記少なくとも1つに、前記要求を送信するステップを含む、請求項18または19に記載の方法。 【請求項２１】 前記クラスタファイルにアクセスするための前記要求を送信するステップは、システム性能、システム一貫性、ローカルデータ利用可能性および前記クラスタにわたるロードバランシングのうちの少なくとも1つを考慮することによって、前記クラスタのうちの前記少なくとも1つを選択するステップを含む、請求項18または19に記載の方法。 【請求項２２】 前記クラスタファイルを修正するための要求を受信するステップであって、前記要求は前記論理ファイル名を含む、ステップと、 前記論理ファイル名を使用して、前記クラスタファイルに対応する前記メタデータを検索するステップと、 前記クラスタファイルを修正するための前記要求に従って、新しいメタデータを生成するステップと、 前記メタデータから、前記物理ファイルの前記物理ファイル位置および前記物理ファイルの前記物理ファイル名を決定するステップと、 前記クラスタファイルを修正するための前記要求を、前記物理ファイルの前記物理ファイル名を使用して、前記クラスタのうちの少なくとも1つに送信するステップと、 前記クラスタファイルに関連して、前記新しいメタデータを記憶するステップとをさらに含む、請求項18乃至21のいずれか1項に記載の方法。 【請求項２３】 前記クラスタファイルを修正するための前記要求を送信するステップは、前記メタデータから、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの前記少なくとも1つに、前記要求を送信するステップを含む、請求項22に記載の方法。 【請求項２４】 分散ファイルシステムの複数のクラスタを管理するための、プロセッサによって実行可能なプログラム命令がその上に記憶されるコンピュータ可読媒体であって、前記複数のクラスタはクラスタファイルを有し、前記プログラム命令は、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信し、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信され、 前記論理ファイル名を使用して、メタデータを検索し、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルであり、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定し、前記物理ファイル位置は、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つであり、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの少なくとも1つに送信するように構成される、コンピュータ可読媒体。」 （２）本件補正前の特許請求の範囲 本件補正前の，平成３１年３月１５日にされた手続補正により補正された特許請求の範囲の請求項１～２６の記載は次のとおりである。（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。） 「　　【請求項１】 分散ファイルシステムの複数のクラスタを管理するためのシステムであって、前記複数のクラスタはクラスタファイルを有し、前記システムは、 少なくとも1つの処理ユニットと、 前記少なくとも1つの処理ユニットに通信可能に結合された非一時的メモリとを含み、前記非一時的メモリは、前記少なくとも1つの処理ユニットによって実行可能な、 ユーザデバイス上のアプリケーションから、新しいクラスタファイルを作成するための要求を受信し、 前記新しいクラスタファイルに対応するクラスタ管理ファイルを作成し、 前記クラスタ管理ファイルに論理ファイル名を割り当て、且つ、前記新しいクラスタファイルに物理ファイル名を割り当て、 前記複数のクラスタにおいて、前記新しいクラスタファイルのための物理ファイル位を割り当て、 前記クラスタ管理ファイルを前記新しいクラスタファイルにマッピングするメタデータを、前記クラスタ管理ファイルに記憶し、前記メタデータは、前記物理ファイル名および前記物理ファイル位置を含み、 前記物理ファイル名を使用して、前記新しいクラスタファイルを作成するための前記要求を、前記物理ファイル位置に対応する前記クラスタの1つに送信し、 前記論理ファイル名を使用して、前記新しいクラスタファイルの作成を前記アプリケーションに確認応答するためのコンピュータ可読プログラム命令を含む、システム。 【請求項２】 前記分散ファイルシステムは、Hadoop分散ファイルシステムまたはHadoop互換ファイルシステムである、請求項1に記載のシステム。 【請求項３】 前記プログラム命令は、前記アプリケーションおよび前記クラスタと通信するための少なくとも1つのクライアントコンポーネント、および、前記メタデータを生成および記憶するための少なくとも1つのマネージャコンポーネントを実施するために実行可能である、請求項1または2に記載のシステム。 【請求項４】 前記少なくとも1つのクライアントコンポーネントは、各々が異なるユーザアプリケーションとインタフェースするように構成される、複数のクライアントコンポーネントを含む、請求項3に記載のシステム。 【請求項５】 前記少なくとも1つのマネージャコンポーネントは、各々が前記複数のクラスタの異なるグループとインタフェースするように構成される、複数のマネージャコンポーネントを含む、請求項3に記載のシステム。 【請求項６】 前記プログラム命令は、前記システムを仮想マシンとして実施するために実行可能である、請求項1乃至5のいずれか1項に記載のシステム。 【請求項７】 分散ファイルシステムの複数のクラスタを管理するための方法であって、前記複数のクラスタはクラスタファイルを有し、前記方法は、 ユーザデバイス上のアプリケーションから、新しいクラスタファイルを作成するための要求を受信するステップと、 前記新しいクラスタファイルに対応するクラスタ管理ファイルを作成するステップと、 前記クラスタ管理ファイルに論理ファイル名を割り当て、且つ、前記新しいクラスタファイルに物理ファイル名を割り当てるステップと、 前記複数のクラスタから、前記新しいクラスタファイルのための物理ファイル位置を割り当てるステップと、 前記クラスタ管理ファイルを前記新しいクラスタファイルにマッピングするメタデータを、前記クラスタ管理ファイルに記憶するステップであって、前記メタデータは、前記物理ファイル名および前記物理ファイル位置を含む、ステップと、 前記物理ファイル名を使用して、前記新しいクラスタファイルを作成するための前記要求を、前記物理ファイル位置に対応する前記クラスタの1つに送信するステップと、 前記論理ファイル名を使用して、前記新しいクラスタファイルの作成を前記アプリケーションに確認応答するステップとを含む方法。 【請求項８】 前記新しいクラスタファイルを作成するための前記要求を、第1のフォーマットから第2のフォーマットへ変換するステップをさらに含み、前記アプリケーションは前記第1のフォーマットをサポートし、且つ、前記クラスタは前記第2のフォーマットをサポートする、請求項7に記載の方法。 【請求項９】 前記新しいクラスタファイルのための前記物理ファイル位置を割り当てるステップは、前記新しいクラスタファイルを要求する前記アプリケーションに関して、前記クラスタのうちの最も近い1つを選択するステップを含む、請求項7または8に記載の方法。 【請求項１０】 前記新しいクラスタファイルのための前記物理ファイル位置を割り当てるステップは、他のクラスタと比較して、利用可能な空間の最大量を有するクラスタを、前記クラスタから選択するステップを含む、請求項7または8に記載の方法。 【請求項１１】 前記新しいクラスタファイルにアクセスするための要求を受信するステップであって、前記要求は、前記論理ファイル名を含む、ステップと、 前記論理ファイル名を使用して、前記新しいクラスタファイルに対応する前記メタデータを検索するステップと、 前記メタデータから、前記物理ファイル名および前記物理ファイル位置を決定するステップと、 前記物理ファイル名を使用して、前記新しいクラスタファイルにアクセスするための前記要求を、前記クラスタのうちの少なくとも1つに送信するステップとをさらに含む、請求項7乃至10のいずれか1項に記載の方法。 【請求項１２】 前記新しいクラスタファイルにアクセスするための前記要求を送信するステップは、システム性能、システム一貫性、ローカルデータ利用可能性および前記クラスタにわたるロードバランシングのうちの少なくとも1つを考慮することによって、前記少なくとも1つのクラスタを選択するステップを含む、請求項11に記載の方法。 【請求項１３】 分散ファイルシステムの複数のクラスタを管理するための、プロセッサによって実行可能なプログラム命令がその上に記憶されるコンピュータ可読媒体であって、前記複数のクラスタはクラスタファイルを有し、前記プログラム命令は、 ユーザデバイス上のアプリケーションから、新しいクラスタファイルを作成するための要求を受信し、 前記新しいクラスタファイルに対応するクラスタ管理ファイルを作成し、 前記クラスタ管理ファイルに論理ファイル名を割り当て、且つ、前記新しいクラスタファイルに物理ファイル名を割り当て、 前記複数のクラスタにおいて、前記新しいクラスタファイルのための物理ファイル位置を割り当て、 前記クラスタ管理ファイルを前記新しいクラスタファイルにマッピングするメタデータを、前記クラスタ管理ファイルに記憶し、前記メタデータは、前記物理ファイル名および前記物理ファイル位置を含み、 前記物理ファイル名を使用して、前記新しいクラスタファイルを作成するための前記要求を、前記物理ファイル位置に対応する前記クラスタの1つに送信し、 前記論理ファイル名を使用して、前記新しいクラスタファイルの作成を前記アプリケーションに確認応答するように構成される、コンピュータ可読媒体。 【請求項１４】 分散ファイルシステムの複数のクラスタを管理するためのシステムであって、前記複数のクラスタはクラスタファイルを有し、前記システムは、 少なくとも1つの処理ユニットと、 前記少なくとも1つの処理ユニットに通信可能に結合された非一時的メモリとを含み、前記非一時的メモリは、前記少なくとも1つの処理ユニットによって実行可能な、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信し、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信され、 前記論理ファイル名を使用して、メタデータを検索し、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルであり、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定し、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの1つに送信するためのコンピュータ可読プログラム命令を含む、システム。 【請求項１５】 前記分散ファイルシステムは、Hadoop分散ファイルシステムまたはHadoop互換ファイルシステムである、請求項14に記載のシステム。 【請求項１６】 前記プログラム命令は、前記アプリケーションおよび前記クラスタと通信するための少なくとも1つのクライアントコンポーネント、および、前記メタデータを生成および記憶するための少なくとも1つのマネージャコンポーネントを実施するために実行可能である、請求項14または15に記載のシステム。 【請求項１７】 前記少なくとも1つのクライアントコンポーネントは、各々が異なるユーザアプリケーションとインタフェースするように構成される、複数のクライアントコンポーネントを含む、請求項16に記載のシステム。 【請求項１８】 前記少なくとも1つのマネージャコンポーネントは、各々が前記複数のクラスタの異なるグループとインタフェースするように構成される、複数のマネージャコンポーネントを含む、請求項16に記載のシステム。 【請求項１９】 前記プログラム命令は、前記システムを仮想マシンとして実施するために実行可能である、請求項14乃至18のいずれか1項に記載のシステム。 【請求項２０】 分散ファイルシステムの複数のクラスタを管理するための方法であって、前記複数のクラスタはクラスタファイルを有し、前記方法は、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信するステップであって、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信される、ステップと、 前記論理ファイル名を使用して、メタデータを検索するステップであって、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルである、ステップと、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップと、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記クラスタのうちの少なくとも1つに送信するステップとを含む方法。 【請求項２１】 前記クラスタファイルにアクセスするための前記要求を、第1のフォーマットから第2のフォーマットへ変換するステップをさらに含み、前記アプリケーションは前記第1のフォーマットをサポートし、且つ、前記クラスタは前記第2のフォーマットをサポートする、請求項20に記載の方法。 【請求項２２】 前記クラスタファイルにアクセスするための前記要求を送信するステップは、前記メタデータから、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの前記少なくとも1つに、前記要求を送信するステップを含む、請求項20または21に記載の方法。 【請求項２３】 前記クラスタファイルにアクセスするための前記要求を送信するステップは、システム性能、システム一貫性、ローカルデータ利用可能性および前記クラスタにわたるロードバランシングのうちの少なくとも1つを考慮することによって、前記クラスタのうちの前記少なくとも1つを選択するステップを含む、請求項20または21に記載の方法。 【請求項２４】 前記クラスタファイルを修正するための要求を受信するステップであって、前記要求は前記論理ファイル名を含む、ステップと、 前記論理ファイル名を使用して、前記クラスタファイルに対応する前記メタデータを検索するステップと、 前記クラスタファイルを修正するための前記要求に従って、新しいメタデータを生成するステップと、 前記メタデータから、前記物理ファイルの前記物理ファイル位置および前記物理ファイルの前記物理ファイル名を決定するステップと、 前記クラスタファイルを修正するための前記要求を、前記物理ファイルの前記物理ファイル名を使用して、前記クラスタのうちの少なくとも1つに送信するステップと、 前記クラスタファイルに関連して、前記新しいメタデータを記憶するステップとをさらに含む、請求項20乃至23のいずれか1項に記載の方法。 【請求項２５】 前記クラスタファイルを修正するための前記要求を送信するステップは、前記メタデータから、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの前記少なくとも1つに、前記要求を送信するステップを含む、請求項24に記載の方法。 【請求項２６】 分散ファイルシステムの複数のクラスタを管理するための、プロセッサによって実行可能なプログラム命令がその上に記憶されるコンピュータ可読媒体であって、前記複数のクラスタはクラスタファイルを有し、前記プログラム命令は、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信し、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信され、 前記論理ファイル名を使用して、メタデータを検索し、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルであり、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定し、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記物理ファイルの前記物理ファイル位置に対応する前記クラスタのうちの少なくとも1つに送信するように構成される、コンピュータ可読媒体。」 ２　補正の適否 ２－１　新規事項について （１）本件補正は，補正前の請求項１に記載された発明を特定するために必要な事項について，「前記新しいクラスタファイルのための物理ファイル位置を割り当てることは、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つを選択することを含み」との限定を付加する補正を含むものである。 そこで，本件補正が，本願の願書に最初に添付された明細書，特許請求の範囲又は図面（以下，これを「当初明細書等」という）に記載した事項の範囲内でなされたものであるかについて，以下に検討する。 （２）当初明細書等に記載された事項 当初明細書等には，「新しいクラスタファイルのための物理ファイル位置を割り当てること」について，以下のように記載されている。 ア　「【００１６】 先の実施形態のいずれか1つにおいて、新しいクラスタファイルのための物理ファイル位置を割り当てることは、新しいクラスタファイルを要求するアプリケーションに関して、クラスタのうちの最も近い1つを選択することを含む。」 イ　「【００６９】 実際、クラスタ管理システム106は、クラスタにわたってデータを作成、アクセスおよび複製するために構成可能な柔軟なポリシーをサポートする。図10Aは、様々なデータ作成シナリオのための例を示す。クラスタ管理システム106は、性能を最適化するために、最も近いクラスタ上にファイルを作成するように構成されてよい。この例は、パス1002によって示され、ここで、アプリケーション1142は、クラスタ1041上にファイルを作成する。」 当初明細書等における上記ア及びイの記載を参照すると，「新しいクラスタファイルのための物理ファイル位置を割り当てること」について，「新しいクラスタファイルを要求するアプリケーションに関して、クラスタのうちの最も近い1つを選択する」こと，「クラスタ管理システム106は、性能を最適化するために、最も近いクラスタ上にファイルを作成する」ことは記載されていると認められるが，「アプリケーションに対して最も短いパスを有する1つを選択する」ことは記載されていない。 また，当初明細書等の記載全体，及び本願出願時の技術常識を参酌しても，上記ア及びイの記載により，「新しいクラスタファイルのための物理ファイル位置を割り当てることは、クラスタのうちの、アプリケーションに対して最も短いパスを有する1つを選択する」ことが自明であるとも認められない。 （３）よって，本件補正により付加された「前記新しいクラスタファイルのための物理ファイル位置を割り当てることは、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つを選択することを含」むことは，当初明細書等には記載がなく，当初明細書等から自明なものでもないから，当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において，新たな技術的事項を導入するものである。 したがって，本件補正は，当初明細書等に記載された事項の範囲内においてするものとはいえず，特許法第１７条の２第３項の規定する要件を満たしていないため，同法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。 ２－２　独立特許要件について 上記「２－１」における検討のとおり，本件補正は，特許法第１７条の２第３項の規定に違反するものであり却下されるべきものであるが，仮に，本件補正が特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものであるとして，補正後の請求項１８に記載される発明（以下「本件補正発明」という。）が同条第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。 （１）本件補正発明 本件補正発明は，上記「１（１）」の請求項１８に記載されたとおりのものである（再掲）。 「　分散ファイルシステムの複数のクラスタを管理するための方法であって、前記複数のクラスタはクラスタファイルを有し、前記方法は、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信するステップであって、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信される、ステップと、 前記論理ファイル名を使用して、メタデータを検索するステップであって、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルである、ステップと、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップであって、前記物理ファイル位置は、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つである、ステップと、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記クラスタのうちの少なくとも1つに送信するステップとを含 む方法。」 （２）引用文献等の記載事項 （２－１）引用文献１に記載されている技術的事項及び引用発明 ア　原査定の拒絶の理由で引用された，本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，米国特許出願公開２０１５／０２４２４５４号明細書（２０１５年８月２７日出願公開。以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。以下同様。） Ａ　「[0020] A particular technique for facilitating the namespace translation at the gateway includes the use of a database of Key-Value (KV) pairs. At its most basic, querying a database using a key returns a corresponding value. In an example of a database used for namespace translation (i.e., namespace resolution), the keys includes the data identifier used by the client in its request. The values associated with the keys each include an identification of the appropriate storage system (e.g., in the case of a read request, the storage system that stores the data), an identifier of the namespace of the storage system, and another data identifier that is understood by the storage system to refer to the data identified by the key. This tatter data identifier conforms to the namespace of the storage system. Thus, upon receipt of a data transaction from a client, the gateway uses the data identifier in the transaction to traverse the KV pairs, finding the corresponding key. The gateway accesses the data in the value to determine which storage system owns the data and what data identifier to use. The gateway then sends a modified transaction to the identified storage system using the translated data identifier from the value.」 （当審訳；　「［００２０］　ゲートウェイの名前変換を容易にするための特定の技術は，キーバリュー（ＫＶ）のデータベースの使用を含む。最も基本的には，キーを使用してデータベースに問い合わせを行って，対応する値を返す。名前変換（すなわち，名前空間解決）のために使用されるデータベースの例では，キーは，その要求中にクライアントによって使用されたデータ識別子を含む。キーに関連付けられた値は，それぞれの適切なストレージシステム（例えば，読み出し要求の場合には，データを格納するストレージシステム）の識別，ストレージシステムの名前空間の識別子と，キーによって識別されたデータを参照するために記憶システムによって理解される別のデータ識別子を含む。この後者のデータ識別子は，ストレージシステムの名前空間に準拠している。これにより，クライアントからのデータトランザクションを受信すると，ゲートウェイは，トランザクション内のデータ識別子を使用して，ＫＶの対を横断するように，対応するキーを検出する。ゲートウェイは，値内のデータにアクセスして，データを所有しているストレージシステムと，使用するデータ識別子を決定する。次に，ゲートウェイは，値から変換されたデータ識別子を使用して，変更されたトランザクションを識別されたストレージシステムに送信する。」） Ｂ　「[0022] FIG. 1 is an illustration of exemplary storage architecture 100, adapted according to one embodiment. The storage architecture 100 includes clients 110-112, gateways 120 and 121, and storage systems 130-133. Clients 110-112 in this example include clients that use the storage systems 130-133 for storage. For instance, each of clients 110-112 may run one or more applications (e.g., word processing or database programs) that utilize the storage architecture. Each client 110-112 includes a computer system that interacts with gateways 120 and 121 for submitting read/write access requests and for receiving or transmitting data from storage systems 130-133 via gateways 120 and 121.」 （当審訳；　「［００２２］　図１は，一実施形態に従って適合された例示的なストレージアーキテクチャ１００の図である。ストレージアーキテクチャ１００は，クライアント１１０－１１２，ゲートウェイ１２０および１２１，ならびにストレージシステム１３０－１３３を含む。この例のクライアント１１０－１１２は，ストレージにストレージシステム１３０－１３３を使用するクライアントを含む。例えば，クライアント１１０－１１２のそれぞれは，ストレージアーキテクチャを利用する１つまたは複数のアプリケーション（例えば，ワードプロセッシングまたはデータベースプログラム）を実行することができる。各クライアント１１０－１１２は，読み取り／書き込みアクセス要求を送信するため，およびゲートウェイ１２０および１２１を介してストレージシステム１３０－１３３からデータを受信または送信するためにゲートウェイ１２０および１２１と相互作用するコンピュータシステムを含む。」） Ｃ　「[0026] Each of the clients 110-112 can send a request to create a file, read a file, write a file, change a directory, look up a file, or any other suitable data transaction to a gateway with which it is in communication. The gateways 120 and 121 translates an identifier of the file or directory into a namespace of an underlying storage device and thereby provides a unified namespace technique so that complexity of the storage architecture is hidden from clients 110-112, as described in detail below. The following example use case illustrates a read request from client 111 to gateway 120, and it is understood that similar action may be performed by any of the clients 110-112 with any of the gateways 120 and 121, assuming a network connection therebetween.」 （当審訳；　「［００２６］　クライアント１１０－１１２のそれぞれは，ファイルの作成，ファイルの読み取り，ファイルの書き込み，ディレクトリの変更，ファイルの検索，または他の適切なデータトランザクションを，通信しているゲートウェイに要求を送信することができる。ゲートウェイ１２０および１２１は，ファイルまたはディレクトリの識別子を基礎となるストレージデバイスの名前空間に変換し，それによって，以下で詳細に説明するように，ストレージアーキテクチャの複雑さがクライアント１１０－１１２から隠されるように，統一された名前空間技術を提供する。次の使用例の例は，クライアント１１１からゲートウェイ１２０への読み取り要求を示しており，同様のアクションが，ゲートウェイ１２０および１２１のいずれかを備えたクライアント１１０－１１２のいずれかによって，それらの間のネットワーク接続を想定して実行され得ることが理解される。」） Ｄ　「[0028] The read request from client 111 includes a first data identifier in the unified namespace. The first data identifier in this example uniquely identifies the object (e.g., an object, file, or block), although it does not comply with a namespace used by any of the storage systems 130-133 and would not properly identify data if sent directly to any of the storage systems 130-133. [0029] Gateway 120 receives the read request and determines a particular storage system 130-133 to which to send the read request. Gateway 120 also determines a second data identifier to use when sending the read request to the particular storage system. Various embodiments may use any appropriate technique to resolve a particular storage system or data identifier upon receipt of a request from a client. In the present example, gateways 120 and 121 use a database of KV pairs to resolve storage systems and data identifiers. The gateway 120 creates a second read request that references data using the second data identifier and forwards the second request to the identified storage system of systems 130-133. [0030] Moving to FIG. 2A, an illustration of an exemplary KV database 200 according to one embodiment is provided. On the left side, the keys include the unified namespace identifiers that are provided from and to clients 110-112. In various embodiments, the unified namespace identifiers include block-level identifiers, file-level identifiers, and/or object identifiers. Block-level data identifiers refer to data using an address that corresponds to a sector of a storage device and may include a physical address (i.e., an address that directly map to a storage device) and/or a logical address (i.e., an address that is translated into a physical address of a storage device). Exemplary block-level protocols include iSCSI, Fibre Channel, and Fibre Channel over Ethernet (FCoE). In contrast, file-level protocols specify data locations by a file name. A file name is an identifier within a file system that can be used to uniquely identify corresponding memory addresses. File-level protocols rely on a system such as one of the unified namespace gateways 120 and 121 and/or a storage system to translate the file name into respective storage device addresses. Exemplary file-level protocols include CIFS/SMB, SAMBA, and NFS. Object-level protocols are similar to file-level protocols in that data is specified via an object identifier that is eventually translated by another system into a storage device address. However, objects are more flexible groupings of data and may specify a cluster of data within a file or spread across multiple files. Object-level protocols include CDMI, HTTP, and S3. [0031] In the embodiments of FIG. 2A, the unified namespace identifiers are file-level identifiers. Commonly, a file-level namespace identifier includes a filename suffix and a path prefix that indicates a directory structure in which the data corresponding to the filename is said to reside. In a conventional system, the path determines the storage system on which the data resides, with each directory being assigned to a particular system. This does not allow data residing within a given directory to be split across more than one storage system. However, by using the KV database 200 discussed below, many embodiments of the present disclosure allow each individual file to reside on any storage system (e.g., systems 130-133) regardless of the path prefix. [0032] Upon receiving a unified namespace identifier, a computing system such as one of gateways 120 and 121 can query the KV database 200 using the identifier. On the right side of the illustrated KV database 200, the associated values include an identifier of a storage system, an identifier of a namespace, and an identifier corresponding to the object in the namespace of the particular storage system. In this way, a query using the unified namespace identifier will return a value that specifies which storage system the data resides on, a namespace used by the storage system, and/or an identifier specifying the data at the storage system. As can be seen, the database 200 may be divided into database portions 202, which in some embodiments are distributed among multiple computing systems such as gateways 120 and 121. As discussed in further detail below, a distributed database 200 has many advantages such as redundancy and load balancing that become particularly important as database size increases.」 （当審訳；　「［００２８］　クライアント１１１からの読み出し要求は，統一された名前空間内の第１のデータの識別子が含まれる。この例の最初のデータ識別子は，オブジェクト（オブジェクト，ファイル，ブロックなど）を一意に識別するが，ストレージシステム１３０－１３３で使用される名前空間に準拠しておらず，ストレージシステム１３０－１３３に直接送信するとデータを適切に識別しない。 ［００２９］　ゲートウェイ１２０は，読み取り要求を受信し，読み取り要求を送信する特定のストレージシステム１３０－１３３を決定する。ゲートウェイ１２０はまた，読み取り要求を特定のストレージシステムに送信するときに使用する第２のデータ識別子を決定する。様々な実施形態は，クライアントからの要求の受信時に特定のストレージシステムまたはデータ識別子を解決するために任意の適切な技術を使用することができる。この例では，ゲートウェイ１２０および１２１は，ＫＶペアのデータベースを使用して，ストレージシステムおよびデータ識別子を解決する。ゲートウェイ１２０は，第２のデータ識別子を使用してデータを参照する第２の読み取り要求を作成し，システム１３０－１３３の識別されたストレージシステムに第２の要求を転送する。 ［００３０］　図２Ａを参照すると，一実施形態による例示的なＫＶデータベース２００の図が提供されている。左側のキーには，クライアント１１０－１１２との間で提供される統一された名前空間識別子が含まれている。様々な実施形態では，統一された名前空間識別子は，ブロックレベルの識別子，ファイルレベルの識別子，および／またはオブジェクト識別子を含む。ブロックレベルのデータ識別子は，ストレージデバイスのセクターに対応するアドレスを使用するデータを参照するものであり，物理アドレス（例えば，ストレージデバイスに直接マップされるアドレス）および／または論理アドレス（例えば，ストレージデバイスの物理アドレスに変換されるアドレス）を含む。例示的なブロックレベルプロトコルには，ｉＳＣＳＩ，ファイバチャネル，およびファイバチャネルオーバーイーサネット（ＦＣｏＥ）が含まれる。対照的に，ファイルレベルのプロトコルはファイル名でデータの場所を指定する。ファイル名は，対応するメモリアドレスを一意に識別するために使用できるファイルシステム内の識別子である。ファイルレベルのプロトコルは，統一された名前空間ゲートウェイ１２０および１２１の１つなどのシステムおよび／またはストレージシステムに依存して，ファイル名をそれぞれのストレージデバイスアドレスに変換する。例示的なファイルレベルのプロトコルには，ＣＩＦＳ／ＳＭＢ，ＳＡＭＢＡ，およびＮＦＳが含まれる。オブジェクトレベルのプロトコルは，データがオブジェクト識別子を介して指定され，最終的に別のシステムによってストレージデバイスアドレスに変換されるという点で，ファイルレベルのプロトコルに似ている。ただし，オブジェクトはより柔軟なデータのグループであり，ファイル内のデータのクラスタを指定したり，複数のファイルに分散したりする場合がある。オブジェクトレベルのプロトコルには，ＣＤＭＩ，ＨＴＴＰ，およびＳ３が含まれる。 ［００３１］　図２Ａの実施形態では，統一された名前空間識別子はファイルレベルの識別子である。通常，ファイルレベルの名前空間識別子には，ファイル名のサフィックスと，ファイル名に対応するデータが存在するディレクトリ構造を示すパスプレフィックスが含まれる。従来のシステムでは，パスによってデータが存在するストレージシステムが決まり，各ディレクトリが特定のシステムに割り当てられる。これにより，特定のディレクトリ内にあるデータを複数のストレージシステムに分割することはできない。しかしながら，以下で論じられるＫＶデータベース２００を使用することにより，本開示の多くの実施形態は，パスプレフィックスに関係なく，個々のファイルが任意のストレージシステム（例えば，システム１３０－１３３）上に存在することを可能にする。 ［００３２］　統一された名前空間識別子を受信すると，ゲートウェイ１２０および１２１のうちの１つなどのコンピューティングシステムは，識別子を使用してＫＶデータベース２００を照会することができる。図示のＫＶデータベース２００の右側には，関連する値は，ストレージシステムの識別子，名前空間の識別子，および特定のストレージシステムの名前空間内のオブジェクトに対応する識別子を含む。このように，統一された名前空間識別子を使用するクエリは，どのストレージシステムにデータが存在するのかを示す値，ストレージシステムによって使用される名前空間，および／またはストレージシステムのデータを特定する識別子を返す。理解されるように，データベース２００は，データベース部分２０２に分割することができ，いくつかの実施形態では，ゲートウェイ１２０および１２１などの複数のコンピューティングシステム間で分散されてもよい。以下にさらに詳細に説明するように，分散型データベース２００は，データベースのサイズが大きくなるにつれて特に重要となるが，冗長性および負荷分散など多くの利点を有する。」） Ｅ　「[0053] FIG. 7 is an illustration of example process 700 adapted according to one embodiment. Process 700 may be performed by one or more computer processors executing code to provide the functionality described above with respect to gateways 120 and 121 and gateway module 602. [0054] At action 710, the gateway receives from a client a first data transaction request including a first data identifier. The data transaction request may include, for example, a read request or a write request. Furthermore, in this example, the first data identifier conforms to a first namespace protocol (e.g., a universal namespace protocol) that is not directly actionable by various underlying storage systems. This is due in part to the storage systems using one or more namespace protocols that are different from the first namespace protocol. [0055] At action 720, the gateway determines a storage system associated with the first identifier. In one example, the gateway traverses a database of KV pairs to find an entry that corresponds to the first identifier. The value associated with the first identifier provides an indication of the storage system that should receive the data transaction request. [0056] At action 730, the gateway determines a second data identifier associated with the first data identifier, wherein the second data identifier conforms to a namespace protocol associated with the storage system. In one example, the gateway determines the second data identifier by examining the same KV database entry that indicates the storage system in action 720. [0057] Whereas the first data identifier conforms to the first namespace protocol, the second data identifier conforms to a namespace protocol of the storage system. For instance, the storage system uses a different namespace protocol than does the client, and the storage system's namespace protocol may also be different from namespaces used by other storage systems in the architecture. It is not necessary that any of the namespace protocols be compatible. In other words, the first data identifier conforms to a protocol that is not compatible with that of the storage system; similarly, the second data identifier conforms to a protocol that is not compatible with that of the client. Instead, the gateway translates between the namespace protocols to allow the client to perform data transactions on any storage system in the architecture while at the same time hiding the underlying storage architecture complexity from the clients. Thus, in some embodiments, the clients may only know and use the unified namespace protocol (of the first data identifier) and be unaware of the namespace protocols used by the storage systems. [0058] At action 740, the gateway forwards a second data transaction request referencing the second data identifier to the storage system. A storage controller of the storage system maps the second data identifier to one or more physical storage addresses in its own data store and returns results to the gateway.」 （当審訳；　「［００５３］　図７は，一実施形態に従って適合された例示的なプロセス７００の図である。プロセス７００は，ゲートウェイ１２０および１２１およびゲートウェイモジュール６０２に関して上記の機能を提供するためにコードを実行する１つまたは複数のコンピュータプロセッサによって実行され得る。 ［００５４］　動作７１０で，ゲートウェイは，クライアントから，第１のデータ識別子を含む第１のデータトランザクション要求を受信する。データトランザクション要求は，例えば，読み取り要求または書き込み要求を含み得る。さらに，この例では，第１のデータ識別子は，様々な基礎となるストレージシステムによって直接実行可能ではない第１の名前空間プロトコル（例えば，ユニバーサル名前空間プロトコル）に準拠している。これは，第１の名前空間プロトコルとは異なる１つ以上の名前空間プロトコルを使用しているストレージシステムに一部起因している。 ［００５５］　動作７２０で，ゲートウェイは，第１の識別子に対応付けられているストレージシステムを決定する。一例では，ゲートウェイは，ＫＶの対のデータベースを横断して，第１の識別子に対応するエントリを見つける。第１の識別子に関連付けられた値は，データ・トランザクションの要求を受信すべきであることの指示を提供する。 ［００５６］　動作７３０で，ゲートウェイは，第１のデータの識別子に関連付けられた第２のデータ識別子を決定するものであり，第２のデータ識別子は，ストレージシステムに関連する名前空間プロトコルに準拠している。一例では，ゲートウェイは動作７２０においてストレージシステムを表す同じＫＶデータベースエントリを調べることによって第２のデータ識別子を決定する。 ［００５７］　第１のデータ識別子は第１の名前空間プロトコルに準拠しているが，第２のデータ識別子はストレージシステムの名前空間プロトコルに準拠している。例えば，ストレージシステムは，クライアントとは異なる名前空間プロトコルを使用する。また，ストレージシステムの名前空間プロトコルは，アーキテクチャ内の他のストレージシステムで使用される名前空間とは異なる場合がある。名前空間プロトコルのいずれかに互換性がある必要はない。言い換えると，第１のデータ識別子は，ストレージシステムのプロトコルと互換性のないプロトコルに準拠している。同様に，第２のデータ識別子は，クライアントのプロトコルと互換性のないプロトコルに準拠している。代わりに，ゲートウェイは名前空間プロトコル間を変換して，クライアントがアーキテクチャ内の任意のストレージシステムでデータトランザクションを実行できるようにすると同時に，基盤となるストレージアーキテクチャの複雑さをクライアントから隠す。したがって，いくつかの実施形態では，クライアントは，（第１のデータ識別子の）統一された名前空間プロトコルのみを知って使用し，ストレージシステムによって使用される名前空間プロトコルを知らない場合がある。 ［００５８］　動作７４０で，ゲートウェイは，第２のデータ識別子を参照する第２のデータトランザクション要求をストレージシステムに転送する。ストレージシステムのストレージコントローラーは，第２のデータ識別子を独自のデータストア内の1つ以上の物理ストレージアドレスにマッピングし，結果をゲートウェイに返信する。」） Ｆ　「図１ 」 Ｇ　「図２Ａ 」 Ｈ　「図７ 」 イ　引用文献１に記載の上記技術的事項について検討する。 （ア）上記Ｂにおける「ストレージアーキテクチャ１００は，クライアント１１０－１１２，ゲートウェイ１２０および１２１，ならびにストレージシステム１３０－１３３を含む。この例のクライアント１１０－１１２は，ストレージにストレージシステム１３０－１３３を使用するクライアントを含む。例えば，クライアント１１０－１１２のそれぞれは，ストレージアーキテクチャを利用する１つまたは複数のアプリケーション（例えば，ワードプロセッシングまたはデータベースプログラム）を実行することができる。」との記載から，引用文献１には， 「ストレージアーキテクチャは，クライアント，ゲートウェイ，ならびにストレージシステムを含むものであり， クライアントは，ストレージアーキテクチャを利用するアプリケーションを実行することができる」 ことが記載されているといえる。 （イ）上記Ｃにおける「クライアント１１０－１１２のそれぞれは，ファイルの作成，ファイルの読み取り，ファイルの書き込み，ディレクトリの変更，ファイルの検索，または他の適切なデータトランザクションを，通信しているゲートウェイに要求を送信することができる。」との記載から，引用文献１には， 「クライアントは，ファイルの読み取り，ファイルの書き込みを，通信しているゲートウェイに要求を送信することができる」 ことが記載されているといえる。 （ウ）上記Ｄにおける「クライアント１１１からの読み出し要求は，統一された名前空間内の第１のデータの識別子が含まれる。」，「ゲートウェイ１２０は，読み取り要求を受信し，読み取り要求を送信する特定のストレージシステム１３０－１３３を決定する。ゲートウェイ１２０はまた，読み取り要求を特定のストレージシステムに送信するときに使用する第２のデータ識別子を決定する。」との記載から，引用文献１には， 「クライアントからの読み出し要求は，統一された名前空間内の第１のデータの識別子が含まれており， ゲートウェイは，読み取り要求を受信し，読み取り要求を送信する特定のストレージシステムを決定し，ゲートウェイは，読み取り要求を特定のストレージシステムに送信するときに使用する第２のデータ識別子を決定する」 ことが記載されているといえる。 （エ）上記Ａにおける「ゲートウェイの名前変換を容易にするための特定の技術は，キーバリュー（ＫＶ）のデータベースの使用を含む。」との記載，上記Ｄにおける「この例では，ゲートウェイ１２０および１２１は，ＫＶペアのデータベースを使用して，ストレージシステムおよびデータ識別子を解決する。」，「図２Ａを参照すると，一実施形態による例示的なＫＶデータベース２００の図が提供されている。左側のキーには，クライアント１１０－１１２との間で提供される統一された名前空間識別子が含まれている。」，「図２Ａの実施形態では，統一された名前空間識別子はファイルレベルの識別子である。」との記載，及び上記Ｇに示される図２Ａの記載から，引用文献１には， 「ゲートウェイは，キーバリュー（ＫＶ）ペアのデータベースを使用して，ストレージシステムおよびデータ識別子を解決するものであり，ＫＶデータベースの左側のキーには，クライアントとの間で提供される統一された名前空間識別子が含まれており， 統一された名前空間識別子はファイルレベルの識別子である」 ことが記載されているといえる。 （オ）上記Ｄにおける「統一された名前空間識別子を受信すると，ゲートウェイ１２０および１２１のうちの１つなどのコンピューティングシステムは，識別子を使用してＫＶデータベース２００を照会することができる。図示のＫＶデータベース２００の右側には，関連する値は，ストレージシステムの識別子，名前空間の識別子，および特定のストレージシステムの名前空間内のオブジェクトに対応する識別子を含む。」との記載から，引用文献１には， 「統一された名前空間識別子を受信すると，ゲートウェイは，識別子を使用してＫＶデータベースを照会するものであり， ＫＶデータベースの右側には，ストレージシステムの識別子，および特定のストレージシステムの名前空間内のオブジェクトに対応する識別子を含む」 ことが記載されているといえる。 （カ）上記Ｅにおける「図７は，一実施形態に従って適合された例示的なプロセス７００の図である。プロセス７００は，ゲートウェイ１２０および１２１およびゲートウェイモジュール６０２に関して上記の機能を提供するためにコードを実行する１つまたは複数のコンピュータプロセッサによって実行され得る。」，「動作７１０で，ゲートウェイは，クライアントから，第１のデータ識別子を含む第１のデータトランザクション要求を受信する。データトランザクション要求は，例えば，読み取り要求または書き込み要求を含み得る。」，及び上記Ｈに示される図７の記載から，引用文献１には， 「ゲートウェイによって実行されるプロセスは， ゲートウェイは，クライアントから，第１のデータ識別子を含む第１のデータトランザクション要求を受信するものであって，データトランザクション要求は，読み取り要求または書き込み要求を含み得る」 ことが記載されているといえる。 （キ）上記Ｅにおける「動作７２０で，ゲートウェイは，第１の識別子に対応付けられているストレージシステムを決定する。一例では，ゲートウェイは，ＫＶの対のデータベースを横断して，第１の識別子に対応するエントリを見つける。」，及び上記Ｈに示される図７の記載から，引用文献１には， 「ゲートウェイは，第１の識別子に対応付けられているストレージシステムを決定するものであり，ゲートウェイは，ＫＶの対のデータベースを横断して，第１の識別子に対応するエントリを見つける」 ことが記載されているといえる。 （ク）上記Ｅにおける「動作７３０で，ゲートウェイは，第１のデータの識別子に関連付けられた第２のデータ識別子を決定するものであり，第２のデータ識別子は，ストレージシステムに関連する名前空間プロトコルに準拠している。」，及び，「動作７４０で，ゲートウェイは，第２のデータ識別子を参照する第２のデータトランザクション要求をストレージシステムに転送する。」，及び上記Ｈに示される図７の記載から，引用文献１には， 「ゲートウェイは，第１のデータの識別子に関連付けられた第２のデータ識別子を決定し， ゲートウェイは，第２のデータ識別子を参照する第２のデータトランザクション要求をストレージシステムに転送する」 ことが記載されているといえる。 ウ　上記イの検討により，引用文献１には次の発明（以下，「引用発明」という。）が記載されているといえる。 「ストレージアーキテクチャは，クライアント，ゲートウェイ，ならびにストレージシステムを含むものであり， クライアントは，ストレージアーキテクチャを利用するアプリケーションを実行することができるものであり， クライアントは，ファイルの読み取り，ファイルの書き込みを，通信しているゲートウェイに要求を送信することができるものであり， クライアントからの読み出し要求は，統一された名前空間内の第１のデータの識別子が含まれており， ゲートウェイは，読み取り要求を受信し，読み取り要求を送信する特定のストレージシステムを決定し，ゲートウェイは，読み取り要求を特定のストレージシステムに送信するときに使用する第２のデータ識別子を決定するものであり， ゲートウェイは，キーバリュー（ＫＶ）ペアのデータベースを使用して，ストレージシステムおよびデータ識別子を解決するものであり， ＫＶデータベースの左側のキーには，クライアントとの間で提供される統一された名前空間識別子が含まれており， 統一された名前空間識別子はファイルレベルの識別子であり， 統一された名前空間識別子を受信すると，ゲートウェイは，識別子を使用してＫＶデータベースを照会するものであり， ＫＶデータベースの右側には，ストレージシステムの識別子，および特定のストレージシステムの名前空間内のオブジェクトに対応する識別子を含むものであり， ゲートウェイによって実行されるプロセスは， ゲートウェイは，クライアントから，第１のデータ識別子を含む第１のデータトランザクション要求を受信するものであって，データトランザクション要求は，読み取り要求または書き込み要求を含み得るものであり， ゲートウェイは，第１の識別子に対応付けられているストレージシステムを決定するものであり，ゲートウェイは，ＫＶの対のデータベースを横断して，第１の識別子に対応するエントリを見つけるものであり， ゲートウェイは，第１のデータの識別子に関連付けられた第２のデータ識別子を決定し， ゲートウェイは，第２のデータ識別子を参照する第２のデータトランザクション要求をストレージシステムに転送する， プロセス。」 （２－２）参考文献１に記載されている技術的事項 ア　前置報告で提示された，本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である，特開２０１０－７４６０４号公報（平成２２年４月２日出願公開。以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。 Ｉ　「【０００７】 データアクセスクライアント１２０は、データ管理サーバ１１１と同様にアドレスを用いて近傍性を推定し、アクセスすべきデータ管理サーバを決定する。 【０００８】 データアクセスクライアント１２０がデータ名「／ｆｏｏ」に対して書き込みを行う場合、まずデータアクセスクライアント１２０は、マスタ１３０に「／ｆｏｏ」に対応するデータ管理サーバのアドレスを問い合わせ、マスタ１３０は（１０．１．１．１）、（１０．１．８５．９）、（１０．６０．１．５４）を取り出し、データアクセスクライアント１２０に返す。データアクセスクライアント１２０は、自ノードのアドレス１０．１．１．６４に最も近いアドレスとして、１０．１．１．１を選択し、このアドレスのデータ管理サーバ１１１にデータの書き込みを行う。次に、データ管理サーバ１１１は、次に近いデータ管理サーバ１１４に対してデータの書き込みを行い、データ管理サーバ１１４は次に近いデータ管理サーバ１１７にデータを書き込む。一方、データアクセスクライアント１２０がデータ名「／ｆｏｏ」に対して読み込みを行う場合、書き込み時と同様にマスタ１３０からアドレスを取り出し、最も近傍なアドレスを持つデータ管理サーバ１１１に対して、データ名「／ｆｏｏ」を要求し、データ管理サーバ１１１は、データ１５０を返す。」 J　「図１５ 」 イ　上記Ｉ～Ｊの記載から，参考文献１には次の技術が記載されているといえる。 「データアクセスクライアントは，データ管理サーバと同様にアドレスを用いて近傍性を推定し，アクセスすべきデータ管理サーバを決定するものであって， データアクセスクライアントがデータ名「／ｆｏｏ」に対して書き込みを行う場合，まずデータアクセスクライアントは，マスタに「／ｆｏｏ」に対応するデータ管理サーバのアドレスを問い合わせ，マスタは（１０．１．１．１），（１０．１．８５．９），（１０．６０．１．５４）を取り出し，データアクセスクライアントに返し，データアクセスクライアントは，自ノードのアドレスに最も近いアドレスとして，１０．１．１．１を選択し，このアドレスのデータ管理サーバにデータの書き込みを行う。」 （２－３）参考文献２に記載されている技術的事項 本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である，特表２０１６－５０９２９４号公報（平成２８年３月２４日出願公表。以下，「参考文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。 Ｋ　「【００３５】 ファイルおよびデータは、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ）においてＨａｄｏｏｐクラスタ１００の複数のノードを通じて分散して記憶される。クライアント１３０Ａおよび１３０Ｂを含むクラスタ１００のクライアントに対し、ＨＤＦＳは従来の階層的ファイルシステムの機能を提供する。ファイルおよびファイルのデータ・ブロックが、ＨＤＦＳにおいて作成、削除、または移動されることが可能である。ＨＤＦＳ内にメタデータ・サービス（ファイルシステムの名前空間を維持し外部クライアントによるアクセスを制御することを含む）を提供するべくメタデータ・ノード１１０Ａ上で動作中のネーム・ノード（ＮａｍｅＮｏｄｅ）サービス１５０が存在する。ＮａｍｅＮｏｄｅサービスは、メタデータ・ノードにおいてＦｓイメージ（ＦｓＩｍａｇｅ）と呼ばれるファイル１６０にファイルシステム・インデックス（ファイルおよびファイルシステム・プロパティに対するブロックのマッピングを含む）を記憶することが可能である。幾つかの実施形態では、第２のＮａｍｅＮｏｄｅサービスを動作させている第２のメタデータ・ノードが存在してもよい。この第２のメタデータ・ノードは、メタデータ・ノードが故障する場合、バックアップとして働く。」 （３）対比 ア　本件補正発明と引用発明とを対比する。 （ア）引用発明は，「ストレージアーキテクチャは，クライアント，ゲートウェイ，ならびにストレージシステムを含むものであり」，「ゲートウェイによって実行されるプロセス」において，「ゲートウェイは，クライアントから，第１のデータ識別子を含む第１のデータトランザクション要求を受信するものであって，データトランザクション要求は，読み取り要求または書き込み要求を含み得るもの」である。 してみると，引用発明の「ゲートウェイによって実行されるプロセス」は，ストレージシステムに対してファイルの読み取り，ファイルの書き込みを行うプロセスであることは明らかであり，ファイルシステムを管理する方法であるといえる。 よって，本件補正発明と引用発明とは，後記の点で相違するものの，“ファイルシステムを管理するための方法”である点で一致している。 （イ）引用発明は，「クライアントのそれぞれは，ストレージアーキテクチャを利用するアプリケーションを実行することができるものであり」，「クライアントからの読み出し要求は，統一された名前空間内の第１のデータの識別子が含まれており」，「クライアントとの間で提供される」「統一された名前空間識別子はファイルレベルの識別子」である。 ここで，「クライアント」は，ユーザが使用するコンピュータであってユーザデバイスといえるから，「クライアント」で実行される「アプリケーション」は，“ユーザデバイス上のアプリケーション”であるといえ，「クライアントからの読み出し要求」は，“ファイルにアクセスするための要求”に他ならないところ，「クライアント」で実行される「アプリケーション」から受信されるものであることは明らかである。 そして，「統一された名前空間内の第１のデータの識別子」は，「ファイルレベルの識別子」であるからファイルを識別する識別子であるといえ，「クライアントとの間で提供される」「統一された名前空間」とは，クライアントが利用する論理的な名前空間であることは明らかであるから，前記「ファイルレベルの識別子」は，ファイルを識別するために論理的な名前空間で付与された“論理ファイル名”であるといえる。してみると，引用発明では，アプリケーションから受信された読み出し要求に，ファイルレベルの識別子である論理ファイル名が含まれているといえる。 よって，本件補正発明と引用発明とは，後記の点で相違するものの，“ファイルにアクセスするための要求を受信するステップであって，前記要求は論理ファイル名を含み，前記要求は，ユーザデバイス上のアプリケーションから受信される，ステップ”を含む点で一致している。 （ウ）引用発明は，「ゲートウェイは，キーバリュー（ＫＶ）ペアのデータベースを使用して，ストレージシステムおよびデータ識別子を解決するものであり，ＫＶデータベースの左側のキーには，クライアントとの間で提供される統一された名前空間識別子が含まれおり」，「ＫＶデータベースの右側には，ストレージシステムの識別子，および特定のストレージシステムの名前空間内のオブジェクトに対応する識別子が含まれて」いるものである。 ここで，「キーバリュー（ＫＶ）ペアのデータベース」とは，キーとバリュー（値）とをペアにして，すなわち，対応づけて格納するデータベースであって，「クライアントとの間で提供される統一された名前空間識別子」とは，上記（イ）で検討したように“論理ファイル名”であるといえ，「特定のストレージシステムの名前空間内のオブジェクトに対応する識別子」とは，ストレージシステムの名前空間でオブジェクトを特定するための識別子であるから，ストレージシステムという物理システムにおいて当該オブジェクトを識別するために付与された“物理ファイル名”であるといえる。 してみると，引用発明の「キーバリュー（ＫＶ）ペアのデータベース」は，論理ファイル名と物理ファイル名を対応づけて格納していることから，“論理ファイル名と共に記憶”し，“論理ファイルを物理ファイルにマッピングする”データであることは明らかであり，また，ファイルに関する付加的なデータであるから，ファイルの“メタデータ”であるといえる。そして，「識別子を使用してＫＶデータベースを照会する」ことは，キーである論理ファイル名を使用してＫＶデータベース，すなわち“メタデータ”を検索することに他ならない。 以上の検討を踏まえると，本件補正発明と引用発明とは，後記の点で相違するものの，“論理ファイル名を使用して，メタデータを検索するステップであって，前記メタデータは，前記論理ファイル名と共に記憶され，前記メタデータは，前記論理ファイルを物理ファイルにマッピングする，ステップ”を含む点で一致している。 （エ）引用発明は，「クライアントからの読み出し要求は，統一された名前空間内の第１のデータの識別子が含まれて」いるところ，「ゲートウェイは，第１の識別子に対応付けられているストレージシステムを決定するものであり，ゲートウェイは，ＫＶペアのデータベースを横断して，第１の識別子に対応するエントリを見つけるもの」である。 ここで，「第１の識別子に対応付けられているストレージシステムを決定するものであり，ゲートウェイは，ＫＶペアのデータベースを横断して，第１の識別子に対応するエントリを見つける」ことは，上記（ウ）の検討を踏まえると，読み取り要求に含まれる第１のデータの識別子，すなわち論理ファイル名を用いてＫＶデータベースを検索し，当該論理ファイルに対応する物理ファイルが存在するストレージシステムを決定することに他ならず，物理ファイルが存在する位置，すなわち，“物理ファイル位置”を決定しているといえる。 また，引用発明は，「ゲートウェイは，読み取り要求を特定のストレージシステムに送信するときに使用する第２のデータ識別子を決定する」ところ，「第２のデータ識別子」とは，ＫＶデータベースの右側に格納されている「特定のストレージシステムの名前空間内のオブジェクトに対応する識別子」であり，上記（ウ）で検討したとおり，“物理ファイル名”といえるものである。 よって，引用発明は，ＫＶデータベースから物理ファイルの位置及び物理ファイル名を決定しているといえ，物理ファイル名を使用して読み取り要求を特定のストレージに送信しているので，本件補正発明と引用発明とは，後記の点で相違するものの，“メタデータから，前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップ”，及び，“物理ファイルの前記物理ファイル名を使用して，ファイルにアクセスするための前記要求を送信するステップ”を含む点で一致している。 イ　上記（ア）～（エ）の検討から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。 ＜一致点＞ 「ファイルシステムを管理するための方法であって，前記方法は， ファイルにアクセスするための要求を受信するステップであって，前記要求は論理ファイル名を含み，前記要求は，ユーザデバイス上のアプリケーションから受信される，ステップと， 前記論理ファイル名を使用して，メタデータを検索するステップであって，前記メタデータは，前記論理ファイル名と共に記憶され，前記メタデータは，前記論理ファイルを物理ファイルにマッピングする，ステップと， 前記メタデータから，前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップと， 前記物理ファイルの前記物理ファイル名を使用して，前記ファイルにアクセスするための前記要求を送信するステップとを含む方法。」 ＜相違点１＞ 本件補正発明は，「分散」ファイルシステムの「複数のクラスタ」を管理するための方法であって，「前記複数のクラスタはクラスタファイルを有し」，前記方法は，「前記クラスタファイルのうちの少なくとも1つにおいてクラスタ」ファイルにアクセスするための要求を受信するものであって，「物理ファイルはクラスタファイル」であり，アクセスするための要求を「クラスタのうちの少なくとも1つに」送信するのに対して，引用発明では，ファイルが「分散」ファイルシステムの「複数のクラスタ」であることが特定されていない点。 ＜相違点２＞ 本件補正発明は，メタデータは論理ファイル名と共に「論理ファイルに記憶され」るのに対して，引用発明では，そのような特定がなされていない点。 ＜相違点３＞ 本件補正発明は，「物理ファイル位置は，前記クラスタのうちの，前記アプリケーションに対して最も短いパスを有する1つである」のに対して，引用発明では，そのような特定がなされていない点。 （４）当審の判断 上記相違点について検討する。 ア　相違点１について 上記「（２）（２－１）Ｄ」に示したとおり，引用文献１の段落[００３０]には，以下のように記載されている。 「［００３０］　図２Ａを参照すると，・・・（中略）・・・。オブジェクトレベルのプロトコルは，データがオブジェクト識別子を介して指定され，最終的に別のシステムによってストレージデバイスアドレスに変換されるという点で，ファイルレベルのプロトコルに似ている。ただし，オブジェクトはより柔軟なデータのグループであり，ファイル内のデータのクラスタを指定したり，複数のファイルに分散したりする場合がある。オブジェクトレベルのプロトコルには，ＣＤＭＩ，ＨＴＴＰ，およびＳ３が含まれる。」 引用文献１の前記記載は，オブジェクトレベルのプロトコルは，データが識別子を介して指定され，ストレージデバイスアドレスに変換されるという点において，ファイルレベルのプロトコルに似ているところ，オブジェクトはより柔軟なデータのグループであり，ファイル内のデータのクラスタを指定したり，複数のファイルに分散したりすることを示すものである。 してみると，引用文献１には，ファイル内のデータのクラスタを指定したり，複数のファイルに分散したりすること，すなわち，ファイルをクラスタとして分散ファイルシステムに格納することが示唆されているといえる。 また，上記「（２）（２－３）」の参考文献２に示されるように，本願優先日において，ファイルをクラスタに分散して記憶する分散ファイルシステムは，ストレージシステムという技術分野における周知技術である。 してみると，引用発明のファイルを「複数のクラスタ」ファイルとし，引用発明のファイルシステムを「分散」ファイルシステムとすること，すなわち，引用発明を，「分散」ファイルシステムの「複数のクラスタ」を管理するための方法とすることは，引用文献１に記載の上記示唆，並びに，上記周知技術に基づいて，当業者であれば容易になし得たことである。 そして，上記相違点１における，「前記複数のクラスタはクラスタファイルを有し」，前記方法は，「前記クラスタファイルのうちの少なくとも1つにおいてクラスタ」ファイルにアクセスするための要求を受信するものであって，「物理ファイルはクラスタファイル」であり，アクセスするための要求を「クラスタのうちの少なくとも1つに」送信することは，引用発明を，「分散」ファイルシステムの「複数のクラスタ」の管理に適用した結果として，当然になされる程度の事項に過ぎない。 イ　相違点２について 引用発明は，メタデータである「キーバリュー（ＫＶ）ペアのデータベース」に，論理ファイル名である「統一された名前空間内の第１のデータの識別子」を記憶するところ，かかる論理ファイル名を記憶したメタデータを，「論理ファイルに記憶され」るとすることは，論理データを論理ファイルに格納することが通常行われていることを鑑みれば，当業者であれば任意になし得る事項に過ぎない。 ウ　相違点３について 上記参考文献１には，上記「（２）（２－２）イ」に示したとおり，次の技術が記載されている（再掲）。 「データアクセスクライアントは，データ管理サーバと同様にアドレスを用いて近傍性を推定し，アクセスすべきデータ管理サーバを決定するものであって， データアクセスクライアントがデータ名「／ｆｏｏ」に対して書き込みを行う場合，まずデータアクセスクライアントは，マスタに「／ｆｏｏ」に対応するデータ管理サーバのアドレスを問い合わせ，マスタは（１０．１．１．１），（１０．１．８５．９），（１０．６０．１．５４）を取り出し，データアクセスクライアントに返し，データアクセスクライアントは，自ノードのアドレスに最も近いアドレスとして，１０．１．１．１を選択し，このアドレスのデータ管理サーバにデータの書き込みを行う。」 参考文献１に記載の上記技術は，クライアントがデータ名「／ｆｏｏ」に対して書き込みを行う場合，前記データ名「／ｆｏｏ」に対応するデータ管理サーバのうち，自ノードに最も近い管理サーバを選択して書き込む技術を示すものであって，最も近い物理ファイルを選択する技術が開示されているといえる。 上記「ア　相違点１について」で検討したように，引用発明のファイルシステムを「分散」ファイルシステムとすることは，当業者であれば容易になし得たことであるところ，引用発明と参考文献１に記載の上記技術とは，クライアントがアクセスするストレージシステムという共通の技術分野に属するものであって，ストレージシステムにおいて応答速度を向上させることは自明な共通の課題であるから，引用発明を「分散」ファイルシステムに適用した際に，分散ファイルを構成する複数のクラスタから最も近い物理ファイルを選択することによって，「物理ファイル位置は，前記クラスタのうちの，前記アプリケーションに対して最も短いパスを有する1つである」とすることは，参考文献１に記載の技術に基づいて，当業者であれば容易に想到し得たことである。 エ　小括 上記ア～ウで検討したとおり，相違点１～相違点３に係る構成は，引用発明，参考文献１に記載された技術，及び周知技術に基づいて，当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，引用発明，参考文献１に記載された技術，及び周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。 したがって，本件補正発明は，引用発明，参考文献１に記載された技術，及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。 ３　本件補正についてのむすび よって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 よって，上記補正の却下の決定の結論のとおり決定する。 第３　本願発明について １　本願発明の認定 令和１年１２月１０日にされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成３１年３月１５日にされた手続補正により補正された特許請求の範囲の請求項１～２６に記載された事項により特定されるものであるところ，その請求項２０に係る発明（以下，「本願発明」という。）は，その請求項２０に記載された事項により特定される，上記「第２[理由]１（２）」の請求項２０に記載された下記のとおりのものである（再掲）。 「　分散ファイルシステムの複数のクラスタを管理するための方法であって、前記複数のクラスタはクラスタファイルを有し、前記方法は、 前記クラスタのうちの少なくとも1つにおいてクラスタファイルにアクセスするための要求を受信するステップであって、前記要求は論理ファイル名を含み、前記要求は、ユーザデバイス上のアプリケーションから受信される、ステップと、 前記論理ファイル名を使用して、メタデータを検索するステップであって、前記メタデータは、前記論理ファイル名と共に論理ファイルに記憶され、前記メタデータは、前記論理ファイルを物理ファイルにマッピングし、前記物理ファイルは前記クラスタファイルである、ステップと、 前記メタデータから、前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップと、 前記物理ファイルの前記物理ファイル名を使用して、前記クラスタファイルにアクセスするための前記要求を、前記クラスタのうちの少なくとも1つに送信するステップとを含む方法。」 ２　原査定の拒絶の理由 原査定の拒絶の理由は，この出願の請求項１に係る発明は，本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１に記載された発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。 １．米国特許出願公開第２０１５／０２４２４５４号明細書 ３　引用文献 原査定の拒絶の理由に引用された，引用文献１，及びその記載事項は，上記「第２[理由]２　２－２（２）（２－１）」に記載したとおりである。 ４　対比・判断 ア　本願発明は，上記「第２[理由]２」で検討した本件補正発明の「物理ファイル位置」に関して，「物理ファイル位置は、前記クラスタのうちの、前記アプリケーションに対して最も短いパスを有する1つである」との限定を削除したものである。 イ　そうすると，上記「第２[理由]２　２－２（３）」における検討内容を踏まえると，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。 ＜一致点＞ 「ファイルシステムを管理するための方法であって，前記方法は， ファイルにアクセスするための要求を受信するステップであって，前記要求は論理ファイル名を含み，前記要求は，ユーザデバイス上のアプリケーションから受信される，ステップと， 前記論理ファイル名を使用して，メタデータを検索するステップであって，前記メタデータは，前記論理ファイル名と共に記憶され，前記メタデータは，前記論理ファイルを物理ファイルにマッピングする，ステップと， 前記メタデータから，前記物理ファイルの物理ファイル位置および前記物理ファイルの物理ファイル名を決定するステップと， 前記物理ファイルの前記物理ファイル名を使用して，ファイルにアクセスするための前記要求を送信するステップとを含む方法。」 ＜相違点ａ＞ 本件補正発明は，「分散」ファイルシステムの「複数のクラスタ」を管理するための方法であって，「前記複数のクラスタはクラスタファイルを有し」，前記方法は，「前記クラスタファイルのうちの少なくとも１つにおいてクラスタ」ファイルにアクセスするための要求を受信するものであって，「物理ファイルはクラスタファイル」であり，アクセスするための要求を「クラスタのうちの少なくとも１つに」送信するのに対して，引用発明では，ファイルが「分散」ファイルシステムの「複数のクラスタ」であることが特定されていない点。 ＜相違点ｂ＞ 本件補正発明は，メタデータは論理ファイル名と共に「論理ファイルに記憶され」るのに対して，引用発明では，そのような特定がなされていない点。 ウ　そして，上記相違点ａ及び相違点ｂは，それぞれ，上記「第２[理由]２　２－２（３）」における，相違点１及び相違点２と同じであることから，上記「第２[理由]２　２－２（４）」で検討したように，相違点ａ及び相違点ｂは，いずれも格別のものではなく，本願発明は，上記引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。 第４　むすび 以上のとおり，本願の請求項２０に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 よって，結論のとおり審決する。