【事件の表示】
　特願２００９−５２６５７７「マルチフォーマット・データ交換のための方法及び装置」拒絶査定不服審判事件〔平成２０年　３月　６日国際公開、ＷＯ２００８／０２７０３５、平成２２年　１月２８日国内公表、特表２０１０−５０３０６３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯 
　本願は、平成１８年８月２８日を国際出願日とする出願であって、平成２４年３月２９日付けで拒絶査定がなされ、同年８月３日付けで拒絶査定不服審判の請求がなされ、当審において、平成２５年７月４日付けで拒絶理由通知がなされ、同年８月２３日付けで手続補正がなされたものである。 
　
　
第２　本願発明
　本願の請求項１及び請求項５に係る発明（以下、それぞれ「本願第１発明」、「本願第５発明」と呼ぶ。）は、それぞれ、平成２５年８月２３日付けの手続補正書の【請求項１】、【請求項５】の欄に記載されたとおりのものであり、次のとおりのものである。
　
「　　【請求項１】
　マルチフォーマット・ファイル・アクセスを可能にする方法であって、
　ベース・フォーマットをそれぞれが有するメディア含有第１ファイルを、異なるフォーマットの対応する非メディア含有第２ファイルにファイル・サーバ内でリンクする工程と、
　特定のメディア含有第１ファイルの非メディア含有第２ファイルとのリンクを前記ファイル・サーバ内で選択的にディセーブルする工程と、
　前記第１ファイルと前記第２ファイルとの間のリンクが選択的にディセーブルされていない限り、選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする工程と、
　配信するために、前記第１ファイルに含まれる前記メディアを前記ベース・フォーマットから、前記要求された非メディア含有第２ファイルのフォーマットに、前記ファイル・サーバ内のファイル変換器によって変換する工程とを含む方法。」
　
「　　【請求項５】
　ファイル転送プロトコル・サーバであって、
　ルート・ノードと、
　前記ルート・ノードにリンクされた第１の複数のメディア含有第１ファイル・フォルダであって、第１ファイル・フォルダがそれぞれ、ベース・フォーマットにおいて少なくとも１つのメディア含有ファイルを記憶する第１ファイル・フォルダと、
　メディア含有ファイルを記憶しない複数の第２ファイル・フォルダであって、各第２ファイル・フォルダは、異なるフォーマットを有し、各第２ファイル・フォルダは少なくとも１つの第１ファイル・フォルダにリンクされて、異なるフォーマットの前記第２ファイル・フォルダのうちの１つに、前記少なくとも１つの第１ファイル・フォルダに記憶されたベース・フォーマットのメディア含有第１ファイルにアクセスする旨の要求をルーティングすることを可能にする第２ファイル・フォルダであって、非メディア含有第２ファイルへの特定のメディア含有第1ファイルのリンクが選択的にディセーブルされる第２ファイル・フォルダと、
　配信するために、前記第１ファイル・フォルダに含まれる前記メディアを前記ベース・フォーマットから、前記異なるフォーマットに変換するファイル変換器とを備えるファイル転送プロトコル・サーバ。」
　
　
第３　当審が平成２５年７月４日付けの拒絶理由通知で通知した拒絶の理由
　当審が平成２５年７月４日付けの拒絶理由通知で通知した拒絶の理由のうち、本願第１発明についての理由であって特許法第２９条第２項の規定に関する理由と、本願第５発明についての理由であって特許法第３６条第６項第１号違反に関する理由は、それぞれ、以下のとおりである。
　
１．本願第１発明についての理由であって特許法第２９条第２項の規定に関する理由
「この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　
　　　　　　　記　　　（引用文献等については引用文献等一覧参照） 
　
・請求項：１
・引用文献等：１ 
・備考　　　　 
（請求項１について） 
　引用文献１（図４、第７欄第５４〜５９行、第８欄第１０〜２９行、第１６欄第４５〜６０行の記載を特に参照）には、 
「マルチフォーマット・ファイル・アクセスを可能にする方法であって、 
　第１フォーマットをそれぞれが有するメディア含有第１ファイルを、第２フォーマットの対応する非メディア含有第２ファイルにファイル・サーバ内でリンクする工程と、 
　前記第１ファイルと前記第２ファイルとの間のリンクが選択的にディセーブルされていない限り、選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする工程と、 
　配信するために、前記第１ファイルに含まれる前記メディアを前記第１フォーマットから、前記要求された非メディア含有第２ファイルのフォーマットに、前記ファイル・サーバ内のファイル変換器によって変換する工程とを含む方法。」 
の点で本願請求項１に係る発明と一致する発明が実質的に記載されているといえる。 
　本願請求項１に係る発明は、「特定のメディア含有第１ファイルの非メディア含有第２ファイルとのリンクを前記ファイル・サーバ内で選択的にディセーブルする工程」（以下、「工程Ａ」と呼ぶ。）を有する点で引用文献１に記載された発明と相違するが、何らかの設定をした場合に、その設定を必要に応じて解除可能なようにすることは、情報処理の技術分野において普通に行われていることであるし、引用文献１に記載された発明におけるリンクの設定についてもそれを解除可能とすることが望ましい場合があることは当業者に自明のことであるから、引用文献１に記載された発明に上記工程Ａを付加することは、当業者が適宜なし得たことである。 
　なお、仮に、上記工程Ａが、上記Ｂ．で言及した「ＦＴＰクライアントがアセットを取り出すことができないフォーマットのフォルダに当該アセットを載せないようにすることで、当該フォーマットでの当該アセットの転送をディセーブルする」といった程度の技術的事項を表していたとしても、必要のないものを設けないことは当業者が普通に考えることであるから、本願請求項１に係る発明の進歩性は肯定されない。
　　　　　　　　　　　引　用　文　献　等　一　覧 
１．米国特許第５９１１７７６号明細書 」
　
２．本願第５発明についての理由であって特許法第３６条第６項第１号違反に関する理由
「この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。 
　
 　　　　　　　　　　　　　　　　　記 
　
　請求項５の「複数の非メディア含有第２ファイル・フォルダであって、各第２ファイル・フォルダは、第２フォーマットを有し、各第２ファイル・フォルダは少なくとも１つの第１ファイル・フォルダにリンクされて、第２フォーマットの前記第２ファイル・フォルダのうちの１つに、第１フォーマットのメディア含有第１ファイルにアクセスする旨の要求をルーティングすることを可能にする第２ファイル・フォルダ」という発明特定事項は、その文言から以下の技術的事項を含むものと解されるが、以下の技術的事項を具備する発明は詳細な説明からは読み取ることができない。 
１．複数の非メディア含有第２ファイル・フォルダは、共通の第２フォーマットを有している。 
２．非メディア含有第２ファイル・フォルダのそれぞれは、複数の第１ファイル・フォルダにもリンクされ得る。 
３．非メディア含有第２ファイル・フォルダのそれぞれは、当該第２ファイル・フォルダのうちの１つに、第１フォーマットのメディア含有第１ファイルにアクセスする旨の要求をルーティングすることを可能にする。 
　
　よって、請求項５に係る発明は、発明の詳細な説明に記載したものでない。」
　
　
第４　当審の判断
１．本願第１発明についての理由であって特許法第２９条第２項の規定に関する理由について
　当審は、本願第１発明は、依然として、その出願前日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものであると判断する。
　理由は以下のとおりである。
　
（１）引用例記載発明
　平成２５年７月４日付けの拒絶理由通知で引用した「米国特許第５９１１７７６号明細書」（以下、「引用例」と呼ぶ。）には次の記載がある。
　
ア．「A network providing a server using an object-database enables an author to create and store an original document, as a source file with a first format. Software in the data base will provide multiple sets of shadow file-converter groups connected to the source file of the original document. Each shadow file-converter set enables the transformation of the original source file format into a particular other specific type of format. Any client or user of the network can access and receive a copy of the original source document which is automatically reformatted to match the requirements of the receiver's appliance. Thus, one original source document can be created and then published in any specific format to multiple numbers of and type of receiving appliances.」（第１ページABSTRACT欄）
（当審訳）
「オブジェクトデータベースを使用するサーバを提供するネットワークは、著者が、オリジナルドキュメントを第１フォーマットのソースファイルとして作成し格納することを可能にする。データベースのソフトウェアは、オリジナルドキュメントのソースファイルに結合されたシャドウファイル−コンバータの多数のセットのグループを提供するであろう。各シャドウファイル−コンバータのセットは、オリジナルソースファイルフォーマットを個々の他の特定のフォーマットのタイプに変換する。どのクライアントあるいはネットワークのユーザも、受信者の装置の要求にマッチするように自動的に再フォーマットされたオリジナルソースドキュメントのコピーにアクセスし受信することができる。このように、あるオリジナルソースドキュメントは作成され、次に、多数の数及びタイプの受信装置へ、任意の特定のフォーマットで発行され得る。」
　
イ．「　　SUMMARY OF THE INVENTION
　The present system and methodology provides for the origination and storage of a source file which is a designated object in an object-oriented database (OODB). Then the system provides another file designated as a shadow file. This shadow file does not have any content, but is dedicated to a particular output format. The shadow file merely points back to the first source file with certain object-connecting techniques called relationships. The shadow also points to another object in the database, which is called a converter. The converter is another object in the database and is dedicated to a particular output format. The converter will take the content of the source file and convert it into the desired format desired by the requester client.」（第４欄第４０〜５４行）
（当審訳）
「　　発明の概要
　本システム及び方法は、オブジェクト指向データベース（ＯＯＤＢ）で”オブジェクト”と呼ばれる”ソース”ファイルの創始と保管に用いられる。そして、システムは、”シャドウ”と呼ばれるもう一つのファイルを提供する。このシャドウファイルは、どんなコンテンツも有しないが、特定の出力フォーマットに専用される。シャドウファイルは、”リレーションシップ”と呼ばれるある”オブジェクト結合”技術を用いて第１のソースファイルを単に”指し示す”。シャドウはまた、データベース中のもう一つの”オブジェクト”も指し示し、それは”コンバータ”と呼ばれる。コンバータは、データベース中のもう一つの“オブジェクト”であり、特定の出力フォーマットに専用される。コンバータはソースファイルのコンテンツを受け取り、それを要求者のクライアントが希望する望ましいフォーマットに変換する。」
　
ウ．「　The user in many cases, in wanting and desiring to change formats could often do the format change on a manual basis, but this would be excessively time-consuming. In the present system and methodology, the user can originate a document and have to do it only once in the format which is the most appropriate for him. Then, by using the present system, the user indicates the other formats he may want his document to be available in. In the present system, the user can use the system to create a source file and shadow file, and this source file document will then have an actual name such as info.rtf (FIG. 2A) which indicates that its associated shadow file represents a document which originated in the Rich Text Format, such as the Source File, S0, in FIG. 2B.
　Further, the user may decide that he may want his original document which was in rtf to be available in other files, having different formats, and thus the present system allows him to create other shadow files which could be designated as info.tiff which would be intended for FAX machine recipient appliances and further, he could make another shadow file designated info.gif which would be destined for recipients who used the graphics interchange format or GIF.」（第７欄第１４〜３７行）
（当審訳）
「　ユーザは多くの場合、フォーマットを変更することを求め望む際、しばしば手動でフォーマット変更をすることができた。しかし、これは非常に時間を要するものであった。本システム及び方法では、ユーザは、ドキュメントを創始することができ、それを彼にとって最も適切なフォーマットで一度だけ実行する必要がある。それから、本システムを使用することにより、ユーザは、彼が彼のドキュメントを利用可能にしたいと望むであろう他のフォーマットを示す。本システムでは、ユーザは、ソースファイルとシャドウファイルを生成するためにシステムを使用することができ、このソースファイルドキュメントは、それから、”ｉｎｆｏ．ｒｔｆ”（図２Ａ）のような、その関連づけられたシャドウファイルが図２ＢのソースファイルＳ０のようなリッチテキストフォーマットで創始されたドキュメントを代理することを示す実際の名前を持つであろう。
　さらに、ユーザは、彼が、彼の”ｒｔｆ”でのオリジナルドキュメントを、異なるフォーマットをもつ　他のファイルで利用可能とすることを望むかもしれないことを決定してもよく、そして、そのように、本システムは、彼に、ＦＡＸ装置、受領者機器等用を意図された”ｉｎｆｏ．ｔｉｆｆ”のように命名され得る他のシャドウファイルを生成することを許し、彼は、グラフィック交換フォーマットすなわち”ＧＩＦ”を使用する受領者に向けられる”ｉｎｆｏ．ｇｉｆ”と命名された他のシャドウファイルを作ってもよい。
　
エ．「　Basically, it can be considered that various files are stored in the database 58 of FIG. 1, which reflect the various files shown in FIG. 2A, which include a file of the document in the TIFF format, a file of the document in GIF format or multiple numbers of other files in various different formats which might be desired for usability.」（第７欄第５４〜５９行）
（当審訳）
「　基本的に、様々なファイルは、図１のデータベース５８に格納されていると考えられる。そしてそれらは、ＴＩＦＦフォーマットのドキュメントのファイル、ＧＩＦフォーマットのドキュメントのファイル、あるいは有用性のために望ましいであろう様々な異なったフォーマットの他の多数のファイルを含む図２Ａに示される様々なファイルを反映している。」
　
オ．「　Thus, in FIG. 2B, the shadow file S1, represents a formatted document designated image/tiff which is suitable for FAX appliances. The shadow file S2 represents an image format shown as image/gif suitable for graphic image format. Multiple numbers of these shadow files can be made to exist in the database 58, up to a file designated Sn. It will be seen that each of the shadow files S1, S2 . . . Sn, each have a converter unit which is seen designated as C1, C2, . . . Cn, where each of these converters is also an object in the database 58. The shadow file does not have any actual content, but it points back to the database source file, together with object-connecting techniques called relationships. Each shadow file also points to another object in the database which is called a converter. Thus, each shadow file has a dedicated converter C. The Converter is another object that will actually take the source's content and convert it into the particular format that is desired. For example, C1 FIG. 2B will transform the input Text/rtf into an output as Image/tiff suitable for a FAX machine, enabling the shadow file to send the document to the requestor.」（第８欄第１０〜２９行）
（当審訳）
「　このように、図２Ｂにおいて、シャドウファイルＳ１は、ＦＡＸ装置に適した”イメージ／ｔｉｆｆ”と命名されたフォーマットされたドキュメントを表している。シャドウファイルＳ２は、グラフィックイメージフォーマットに適した”イメージ／ｇｉｆ”として示されるイメージフォーマットを表している。多数のこれらのシャドウファイルは、”Ｓｎ”と命名されるファイルまで、データベース５８に存在するように構成され得る。各々のシャドウファイルＳ１、Ｓ２・・・Ｓｎの各々がＣ１、Ｃ２、・・・Ｃｎと命名されて示されるコンバータユニット、ここで、これらのコンバータもデータベース５８のオブジェクトである、を有することがわかるであろう。シャドウファイルは、実際のコンテンツを有しないが、”リレーションシップ”と呼ばれるオブジェクト結合技術が加わって、データベースソースファイルを指し示す。各シャドウファイルはまた、”コンバータ”と呼ばれるもう一つのデータベース中のオブジェクトも指し示す。このように、各シャドウファイルは、専用のコンバータＣを有する。コンバータは、実際にソースのコンテンツを受け取り、それを望まれる特定のフォーマットに変換する。例えば、図２ＢのＣ１は、入力のテキスト／ｒｔｆを、ＦＡＸ装置に適したイメージ／ｔｉｆｆとしての出力に変換し、シャドウファイルがドキュメントを要求者に送ることを可能にするであろう。」
　
カ．「　Every file in the object database 58, whether a source file or a shadow file, has a unique file name, just as is done in the ordinary real file systems. Furthermore, each file has a precise MIME type/subtype designation such as text/plain or application/postscript.」（第１０欄第２２〜２６行）
（当審訳）
「　オブジェクトデータベース５８の全てのファイルは、ソースファイルであろうとシャドウファイルであろうと、通常の”現実の”ファイルシステムと全く同様に、ユニークなファイル名を持つ。さらに各ファイルは、テキスト／プレイン又はアプリケーション／ポストスクリプトのような明確なＭＩＭＥのタイプ／サブタイプの指定を有する。」
　
キ．「　The Access Phase of the software operation is shown in FIG. 4. A User, client or requestor desires to fetch the content of the shadow file. The requestor starts the process by asking give me the content of this shadow file. Step H of FIG. 4 indicates the requestor asking for the content of the file and the source software fetching the shadow file content. In actuality, the shadow file fetches the content of its source file. At step I, the shadow file then fetches the content of its source file and then at step J, calls on the transformation function of its converter, where at step K the converter transforms the input content into an output content and at step L, the converter sends its output back to the shadow file, where at step M, the shadow file returns the transformed output back to the requestor in step H. Thus, the shadow file, which has a copy of the transformed converter object's output, then returns it back to the requestor.」（第１６欄第４５〜６０行）
（当審訳）
「　ソフトウェアオペレーションのアクセス段階が図４に示される。ユーザ、クライアント、あるいは要求者は、シャドウファイルのコンテンツを取ってくることを望む。要求者は、”このシャドウファイルのコンテンツを私に下さい”と依頼することでプロセスを開始する。図４のステップＨは、ファイルのコンテンツを求めている要求者とシャドウファイルコンテンツを取ってくるソースソフトウエアを示している。実際は、シャドウファイルがそのソースファイルのコンテンツを取ってくる。ステップＩでシャドウファイルはそのソースファイルのコンテンツを取ってきて、次にステップＪでそのコンバータの変換機能をコールし、ステップＫでコンバータが入力コンテンツを出力コンテンツに変換し、ステップＬでコンバータはその出力をシャドウファイルへ返送し、ステップＭでシャドウファイルは変換された出力をステップＨの要求者へ返送する。このように、変換されたコンバータオブジェクトの出力のコピーを有するシャドウファイルは、それを要求者へ返送する。」
　
　そして、上記記載事項を総合し、引用例の関連図面と技術常識に照らせば、以下のことがいえる。
（ア）引用例には、「種々のフォーマットに対応したシャドウファイルに対するアクセス要求に基づき、リッチテキストフォーマットのようなオリジナルソースファイルフォーマットのソースファイルのコンテンツを、当該アクセス要求のあったシャドウファイルに対応したフォーマットに変換してユーザに提供可能とする方法」といえる方法が示されているということができ、そのような方法は、「マルチフォーマット・ファイル・アクセスを可能にする方法」ともいい得る。
（イ）上記記載事項イ．、オ．でいう「”リレーションシップ”と呼ばれるオブジェクト結合技術」は、「ソースファイルを異なるフォーマットの対応するシャドウファイルにサーバ内でリンクする工程」といえる工程を含むものである。また、そのソースファイルは当然に複数であり得、そのそれぞれがリッチテキストフォーマットのようなオリジナルソースファイルフォーマットを有するものである。
（ウ）上記記載事項キ．によれば、上記（ア）でいう「マルチフォーマット・ファイル・アクセスを可能にする方法」は、「選択されたシャドウファイルにアクセスする旨の要求に応答して、前記要求されたシャドウファイルにリンクされたソースファイルにアクセスする工程」といえる工程と「配信するために、ソースファイルに含まれるコンテンツをオリジナルソースファイルフォーマットから、要求されたシャドウファイルのフォーマットに、サーバ内のコンバータによって変換する工程」といえる工程を有している。
　
　したがって、引用例には、次の発明（以下、「引用例記載発明」と呼ぶ。）が記載されているといえる。
「マルチフォーマット・ファイル・アクセスを可能にする方法であって、
　オリジナルソースファイルフォーマットをそれぞれが有するソースファイルを、異なるフォーマットの対応するシャドウファイルにサーバ内でリンクする工程と、
　選択されたシャドウファイルにアクセスする旨の要求に応答して、前記要求されたシャドウファイルにリンクされた前記ソースファイルにアクセスする工程と、
　配信するために、前記ソースファイルに含まれるコンテンツを前記オリジナルソースファイルフォーマットから、前記要求されたシャドウファイルのフォーマットに、前記サーバ内のコンバータによって変換する工程とを含む方法。」
　
（２）対比
　本願第１発明と引用例記載発明を対比すると、引用例記載発明の「オリジナルソースファイルフォーマット」、「コンテンツ」、「ソースファイル」、「シャドウファイル」、「サーバ」、「コンバータ」は、それぞれ、本願第１発明の「ベース・フォーマット」、「メディア」、「メディア含有第１ファイル」、「非メディア含有第２ファイル」、「ファイル・サーバ」、「ファイル変換器」に相当するといえるから、両者の間には以下の一致点、相違点があるといえる。
　
（一致点）
「マルチフォーマット・ファイル・アクセスを可能にする方法であって、
　ベース・フォーマットをそれぞれが有するメディア含有第１ファイルを、異なるフォーマットの対応する非メディア含有第２ファイルにファイル・サーバ内でリンクする工程と、
　選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする工程と、
　配信するために、前記第１ファイルに含まれる前記メディアを前記ベース・フォーマットから、前記要求された非メディア含有第２ファイルのフォーマットに、前記ファイル・サーバ内のファイル変換器によって変換する工程とを含む方法。」である点。
　
（相違点）
　本願第１発明は、「特定のメディア含有第１ファイルの非メディア含有第２ファイルとのリンクを前記ファイル・サーバ内で選択的にディセーブルする工程」（以下、「工程Ａ」と呼ぶ。）を有し、本願第１発明の「選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする工程」（以下、「工程Ｂ」と呼ぶ。）は、「前記第１ファイルと前記第２ファイルとの間のリンクが選択的にディセーブルされていない限り」において、「選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする」ものであるのに対し、引用例記載発明は、工程Ａに相当する工程を有しておらず、引用例記載発明の工程Ｂは、「前記第１ファイルと前記第２ファイルとの間のリンクが選択的にディセーブルされていない限り」において、「選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする」ものではない点。
　
（３）判断
ア．上記（相違点）について
　以下の事情を勘案すると、引用例記載発明において上記相違点に係る本願第１発明の構成を採用すること、換言すれば、引用例記載発明を工程Ａに相当する工程を備えるものとし、引用例記載発明の工程Ｂを「前記第１ファイルと前記第２ファイルとの間のリンクが選択的にディセーブルされていない限り」において、「選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする」ものとすることは、当業者が容易に推考し得たことというべきである。
（ア）情報処理の技術分野一般において、何らかの設定をする場合に、作業ミスや後の状況変化等に備えるべく、一旦セットした設定を必要に応じて解除可能なようにしておくことは、ごく普通に行われていることである。
（イ）引用例１記載発明におけるリンクの設定についても、作業ミスや後の状況変化等に起因し、一旦設定したリンクを解除したい場合が発生し得ることは当然のことであり、そのような場合に対処すべく、一旦設定したリンクを選択的に解除可能としておくことが望ましいことは、当業者に明らかである。
（ウ）引用例１記載発明において、リンクの設定を選択的に解除可能とすることを妨げる事情はない。
（エ）以上のことは、引用例記載発明を工程Ａに相当する工程を備えるものとすることが容易であったことを意味している。
（オ）引用例記載発明を工程Ａに相当する工程を備えるものとした場合に、引用例記載発明の工程Ｂが「前記第１ファイルと前記第２ファイルとの間のリンクが選択的にディセーブルされていない限り」において、「選択された第２ファイルにアクセスする旨の要求に応答して、前記要求された第２ファイルにリンクされた前記第１ファイルにアクセスする」ものとされるべきことは、当然のことである。
（カ）以上のことは、引用例記載発明において上記相違点に係る本願第１発明の構成を採用することが、当業者にとって容易であったことを意味している。
　
イ．本願第１発明の効果について
　本願第１発明の構成によってもたらされる効果は、引用例の記載及び技術常識から当業者が予測し得た範囲を超えるものではなく、本願第１発明の進歩性を肯定する根拠となり得るものではない。
　
ウ．まとめ
　以上のとおりであるから、本願第１発明は、引用例記載発明に基づいて当業者が容易に発明をすることができたものである。
　
２．本願第５発明についての理由であって特許法第３６条第６項第１号違反に関する理由について
　当審は、本願第５発明は、依然として発明の詳細な説明に記載したものではなく、本願特許請求の範囲の記載は、依然として特許法第３６条第６項第１号に規定する要件を満たしていないと判断する。
　理由は以下のとおりである。
　すなわち、請求項５の「各第２ファイル・フォルダは少なくとも１つの第１ファイル・フォルダにリンクされて、異なるフォーマットの前記第２ファイル・フォルダのうちの１つに、前記少なくとも１つの第１ファイル・フォルダに記憶されたベース・フォーマットのメディア含有第１ファイルにアクセスする旨の要求をルーティングすることを可能にする第２ファイル・フォルダ」という発明特定事項は、その文言から以下の技術的事項ア、イを含むものと解されるが、当該技術的事項ア、イを具備する発明は詳細な説明からは読み取ることができない。 
＜技術的事項ア＞
　第２ファイル・フォルダ（メディア含有ファイルを記憶しないファイル・フォルダ）のそれぞれは、複数の第１ファイル・フォルダ（少なくとも１つのメディア含有ファイルを記憶するファイル・フォルダ）にもリンクされ得る。 
＜技術的事項イ＞
　第２ファイル・フォルダのそれぞれは、当該第２ファイル・フォルダのうちの１つに、「第１ファイル・フォルダに記憶されたベース・フォーマットのメディア含有第１ファイルにアクセスする旨の要求」をルーティングすることを可能にする。
　上記技術的事項ア、イは、上記平成２５年７月４日付けの拒絶理由通知で通知した上記第３の２．の理由の記の２．、３．に指摘した技術的事項に対応する技術的事項であり、審判請求人は、平成２５年８月２３日付けの意見書において、それらの技術的事項は、それぞれ、明細書の段落【００１４】、【００１６】等に記載されている旨主張するが、以下の（１）（２）に示すように、明細書の段落【００１４】、【００１６】の記載からは、上記技術的事項ア、イを具備する発明を読み取ることはできないし、明細書のその他の箇所の記載を精査しても、上記技術的事項ア、イを具備する発明を読み取ることはできない。
　
（１）先ず明細書の段落【００１４】の記載について見るに、同段落【００１４】の記載は、下に転記するとおりであり、そこからは、請求項５でいう「第１ファイル・フォルダ」に相当するものと解される「アセット含有ファイル・フォルダ」のそれぞれが、複数の「第２ファイル・フォルダ」に相当するものと解される複数の「仮想ファイル・フォルダ」にリンクされ得ることや、複数の「仮想ファイル・フォルダ」（１４１乃至１４ｎ）の全てが、複数の「アセット含有ファイル・フォルダ」（１６１乃至１６ｍ）のうちの特定の一つへリンクすることまでは読み取ることができるものの、上記技術的事項アに相当する技術的事項を読み取ることはできない。
　したがって、明細書の段落【００１４】の記載から、上記技術的事項アを具備する発明を読み取ることはできない。
「　【００１４】
　仮想ファイル・フォルダ１４１乃至１４ｎは、各アセット含有ファイル・フォルダが、少なくとも１つの仮想ファイル・フォルダへのリンクを有するように、アセット含有ファイル・フォルダ１６１乃至１６ｍへのリンクの恩恵を受ける。図１の例証的な実施例では、アセット含有ファイル・フォルダそれぞれはアセットを、通常、ベース・フォーマットにおけるディジタル・メディア・ファイルの形式で含む。これは、通常、ＧＸＦ（ＳＭＰＴＥ　３６０Ｍ）、ＭＸＦ（ＳＭＰＴＥ　３７７Ｍ）、ＱｕｉｃｋＴｉｍｅ、ＡＶＩ，ウィンドウズ（登録商標）ＡＳＦなどの通常のメディア交換フォーマットの１つとは異なる。アセット含有ファイル・フォルダそれぞれは、そのアセットの名を含む対応する仮想ファイル・フォルダにリンクする。よって、例えば、フォーマットＧＸＦ、ＭＸＦ及びＱＴそれぞれにおけるアセットｍｏｖｉｅｌ２３を識別する名であるｍｏｖｉｅｌ２３／ＧＸＦ、ｍｏｖｉｅｌ２３／ＭＸＦ及びｍｏｖｉｅ１２３／ＱＴを有する仮想ファイル・フォルダはそれぞれ、ｍｏｖｉｅｌ２３／ｂａｓｅｆｏｒｍａｔという名を有するアセット含有ファイル・フォルダへのリンクを有する。すなわち、特定のフォーマットにかかわらず、アセットｍｏｖｉｅｌ２３を識別する仮想ファイル・フォルダ１４１乃至１４ｎは全て、ベース・フォーマットにおけるアセットｍｏｖｉｅｌ２３を含む、ファイル・フォルダ１６１乃至１６ｍのうちの特定のものへリンクする。」
　
（２）次に明細書の段落【００１６】の記載について見るに、同段落【００１６】の記載は、下に転記するとおりであり、そこからは、上記技術的事項イに関連すると思われる事項としては、「ＦＴＰサーバ１０がクライアントから特定のファイル・フォーマットに対応する種々のエイリアスを伴う特定のアセットに対するアクセス要求を受けて、当該特定のアセットを当該特定のファイル・フォーマットにフォーマッティングしてクライアントへ送出する」といった程度の技術的事項を読み取ることができるに過ぎない。
　そして、そこでいう「特定のファイル・フォーマットに対応する種々のエイリアスを伴う特定のアセットに対するアクセス要求」を「第１ファイル・フォルダに記憶されたベース・フォーマットのメディア含有第１ファイルにアクセスする旨の要求」と表現することまではできるかもしれないが、そこでいう要求は、「第１ファイル・フォルダに記憶されたベース・フォーマットのメディア含有第１ファイル」にルーティングされるべきものであって、「第２ファイル・フォルダのうちの１つ」にルーティングされるべきものとは解されない。
  したがって、明細書の段落【００１６】の記載から、上記技術的事項イを具備する発明を読み取ることもできない。
「　【００１６】
　特定のアセットに対するアクセス要求は、それぞれが特定のファイル・フォーマットに対応する種々のエイリアスを伴ってＦＴＰサーバ１０に現れ得る。よって、ｍｏｖｉｅｌ２３というアセットに対する要求により、ファイル・フォーマット「ＧＸＦ」、「ＭＸＦ」、「ＱＴ」、「ＡＶＩ」、「ＡＳＦ」を有するアセットが、フォーマット識別子とともに現れ得る。図１のＦＴＰサーバ１０のクライアントが、ｍｏｖｉｅｌ２３というアセットを取り出そうとすると、要求を行うためにクライアントが使用したエイリアスがどれであるか（すなわち、ファイル・フォーマットがどれであるか）の知識により、そのクライアントに送出されるアセットのフォーマットが決まってくる。例えば、ＭＸＦにおけるアセットｍｏｖｉｅ１２３を要求するクライアントは、そのアセットをＭＸＦストリーミング・フォーマットで受信する。ＦＴＰサーバ１０が、特定のアセットと関連付けられたビデオ、オーディオ等のデータ属性を、別個のメディア・ファイル（１ビデオ・ファイル、２オーディオ・ファイル、ステレオ・オーディオであるものとする）に記憶するようにしてもよい。次いで、要求しているクライアントにダウンロードする直前に、ＦＴＰサーバ１０はビデオ及びオーディオのデータを所望のフォーマットでフォーマッティングすることが可能である。よって、クライアントが、ＭＸＦフォーマットにおけるアセットを要求した場合、ＦＴＰサーバ１０は、データをＭＸＦフォーマットでラッピングすることが可能である。このフォーマッティング動作は、「オンザフライで」生じ得る。上記ファイル階層を使用すれば、ＦＴＰサーバ１０は効果的には、そのアセットを各フォーマットに記憶する必要なしで、サポートされるフォーマット（ＡＶＩ、ＧＸＦ、ＱｕｉｃｋＴｉｍｅ等）の何れかで特定のアセットをクライアントに送出することが可能である。」
　
　よって、本願第５発明は、発明の詳細な説明に記載したものではない。
　
３．むすび 
　以上のとおりであるから、本願第１発明は、特許法第２９条第２項の規定により特許を受けることができないものであり、本願の特許請求の範囲の記載は、特許法第３６条第６項第１号に規定する要件を満たしていない。
　したがって、その他の拒絶の理由を検討するまでもなく、本願は、拒絶されるべきものである。  
　よって、結論のとおり審決する。