【事件の表示】
　特願２０１２−５３１７９７「受信装置、受信方法、送信装置、送信方法、プログラム、及び放送システム」拒絶査定不服審判事件〔平成２４年　３月　８日国際公開、ＷＯ２０１２／０２９５６６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯と本願発明
　本願は，２０１１年８月２２日（優先権主張２０１０年８月３０日，２０１０年９月１５日，２０１１年４月６日　米国）を国際出願日とする出願であって，平成２７年５月１１日付け拒絶理由通知に対して同年６月２６日に意見書及び手続補正書が提出されたが同年１２月７日付けで拒絶査定がなされ，これを不服として平成２８年３月１５日付けで審判請求がなされたものであって，その請求項１２に係る発明（以下，「本願発明」という。）は，平成２７年６月２６日に提出された手続補正書の特許請求の範囲の請求項１２に記載された以下のとおりのものと認める。
　
「データを受信する受信装置の受信方法において，
　前記受信装置による，
　　前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から，予め決められた順序に従って，前記ファイルを取得する取得先を決定する決定ステップと，
　　前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって，前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報に基づいて，前記取得先から前記ファイルを取得する取得ステップと，
　　取得された前記ファイルを実行する実行ステップと
　を含む受信方法。」
　
２　引用発明
　原査定の拒絶の理由に引用された特開平１１−２４９９５１号公報（以下，「引用例」という。）には，「情報管理システム，ローカルコンピュータ，サーバコンピュータ，情報取得プログラムを記録したコンピュータ読み取り可能な記録媒体及びサーバ用プログラムを記録したコンピュータ読み取り可能な記録媒体」（発明の名称）に関し，図面とともに以下の事項が記載されている。
　
ア　「【０００４】
【発明が解決しようとする課題】しかし，コンテンツをキャッシュする方式では，最初のアクセスでは常にサーバから転送しなければならないという問題がある。また，キャッシュデータの保存には期限が設けられているのが普通であり，その期限以後のアクセスでは，やはり伝送路の伝送容量の影響を受けることとなる。
【０００５】ところで，インターネットのコンテンツには，毎日のように更新されるものもあるが，一定期間更新する必要のないものもある。例えば，ある会合の参加者名簿のようなコンテンツは，その会合の開催と参加者が決定してから会合が終了するまで，内容の更新の必要はあまりない。しかも，特定の会員のみが参加する会合であれば，その会合に関するコンテンツは会員のみが閲覧できれば十分である。
【０００６】そこで，特定の内容のコンテンツをCD−ROM(Compact Disk Read Only Memory)に記録し，必要としている者に配布しておくことが考えられる。ただし，この場合には，コンテンツを媒体に記録する際に，コンテンツ間のリンク関係を書き直さなければならない。すなわち，ＨＴＭＬファイルがサーバに存在するときには，リンク先の指定や，インライン表示すべき画像ファイルの指定などは，指定先のファイルのサーバ上でのＵＲＬ(Uniform Resource Locator)が割り当てられている。そのため，リンク先のファイルやインライン表示する画像ファイルなどを含めてＣＤ−ＲＯＭに格納する場合，指定するファイルの場所は，ローカルの媒体となる。リンク先に対してローカルの媒体としてアクセスするには，ＵＲＬの指定をローカルの名前に書き直す必要がある。この作業を全てのＨＴＭＬファイルに対して行うのは，非常に大変な作業である。
【０００７】本発明はこのような点に鑑みてなされたものであり，一定期間更新する必要のないサーバ上のコンテンツをそのまま媒体に記録し，そのコンテンツを格納しているサーバへのアクセスと同じ操作で，ローカル装置内の所望のコンテンツにアクセスすることのできる情報管理システムを提供することを目的とする。」
　
イ　「【００１３】このような情報管理システムにおいて，情報閲覧手段１ａから要求中継手段１ｃに配信情報２ｂｂの取得要求が出されると，その要求を要求中継手段１ｃが受け取り，内容を解析する。そして，要求相手のサーバ２ａが管理しているサーバ側制御ファイル２ｂａと，複製情報格納手段１ｂ内のローカル側制御ファイル１ｂａとを取得する。ここで，要求された情報が複製情報格納装置１ｂ内に格納されているかを確認し，格納されている場合には，さらに，複製情報格納装置１ｂ内の複製情報１ｂｂの版数が最新のものかどうかを判断する。複製情報格納装置１ｂ内に該当する情報が存在し，しかも，最新の版数である場合には，複製情報格納装置１ｂから情報を取り出す。そうでなければサーバコンピュータ２から配信情報２ｂｂを取り出す。」
　
ウ　「【００１７】図２は，本発明の第１の実施の形態の構成図である。図のように，ローカルコンピュータ１０とサーバコンピュータ２０とは，インターネット３０を介して接続されている。
【００１８】ローカルコンピュータ１０には，ＷＷＷブラウザ１１，ストリーミング再生プレーヤ１２，ローカルプロキシーサーバ１３，及び補助記憶装置１４が設けられている。
【００１９】ＷＷＷブラウザ１１は，ローカルプロキシーサーバ１３を介してサーバコンピュータ２０への要求を出力する。そのために，一般的なＷＷＷブラウザに設けられている，外部のプロキシィサーバの設定機能を用いる。すなわち，ＷＷＷブラウザ１１において，プロキシィサーバの設定を「localhost(IPアドレス＝127.0.0.1)」とする。これにより，ＷＷＷブラウザ１１が動作しているローカルコンピュータ１０内のプロキシィサーバ（ここでは，ローカルプロキシィサーバ１３）が指定され，ＷＷＷブラウザ１１からの要求をローカルプロキシィサーバ１３で中継することができる。
【００２０】ストリーミング再生プレイヤー１２は，ＷＷＷブラウザ１１からの要求に応じてストリーミングサーバ２２へ要求を出し，返されたストリーミングコンテンツを再生する。
【００２１】ローカルプロキシィサーバ１３は，ＷＷＷブラウザ１１がサーバコンピュータ２０に対して出力する要求を中継する。そして，サーバコンピュータ２０と補助記憶装置１４との双方から，要求されたコンテンツの制御ファイル１４ａ，２４ａを取得する。取得した制御ファイル１４ａ，２４ａに基づいて，補助記憶装置１４内のストリーミングコンテンツ１４ｃが最新のものであるか否かを判断し，最新のコンテンツであればそのストリーミングコンテンツを補助記憶装置１４から読み出し，そうでなければサーバコンピュータ２０に格納されているストリーミングコンテンツ２４ｂをインターネット３０経由で取得する。
【００２２】補助記憶装置１４は，CD-ROMのような可搬型の記録媒体と，その媒体のデータの読み取り装置である。記録媒体には，制御ファイル１４ａ，ＨＴＴＰコンテンツ１４ｂ及びストリーミングコンテンツ１４ｃとが格納されている。制御ファイル１４ａは，ＨＴＴＰコンテンツ１４ｂとストリーミングコンテンツ１４ｃとの版数や，元のコンテンツの格納先などの情報を有するファイルである。ＨＴＴＰコンテンツ１４ｂとストリーミングコンテンツ１４ｃとは，サーバコンピュータ２０に格納されているＨＴＴＰコンテンツ２３ｂ，ストリーミングコンテンツ２４ｂを，過去にそのまま複写したものである。
【００２３】サーバコンピュータ２０には，ＷＷＷサーバ２１とストリーミングサーバ２２とが設けられており，それぞれデータべース２３，２４を有している。データベース２３には，制御ファイル２３ａとＨＴＴＰコンテンツ２３ｂとが格納されており，データベース２４には，制御ファイル２４ａとストリーミングコンテンツ２４ｂが格納されている。」
　
エ　「【００２７】ここで，ＷＷＷブラウザ１１とストリーミング再生プレイヤー１２とは，それぞれ対応するサーバとの間でデータの送受信を行う。その基本的な手順を以下に示す。
【００２８】図４は，クライアントとサーバとの間のデータの流れを示す図である。まず，ＷＷＷブラウザ１１からＷＷＷサーバ２１に対してＴＣＰによりＨＴＴＰ要求（ＧＥＴ，ＰＵＴ等）が発行される。
【００２９】一般例として「URL=http://fujisan.gmsnet.ro.jp/hylintk/kanda.html」を利用者がＷＷＷブラウザ１１に指定して起動をかけた場合を想定すると，ＷＷＷサーバ２１に対する要求は，「GET http://fujisan.gmsnet.ro.jp/hylintk/kanda.html」となる。
【００３０】すると，ＷＷＷサーバ２１は，ＨＴＴＰコンテンツ２３ｂの中から要求されたＨＴＭＬファイルを取り出し，そのファイルにヘッダ情報を付加して応答データ４１とする。ＷＷＷサーバ２１は，この応答データ４１をＷＷＷブラウザ１１へ返す。応答データ４１には，以下のような内容が記述される。
【００３１】図５は，応答データの内容を示す図である。応答データ４１の先頭にヘッダ情報が付加されており，このヘッダ情報に続いてコンテンツの中身がＨＴＭＬで記述されている。ヘッダ情報には，「content-type」によりＭＩＭＥ(Multipurpose Internet Mail Extension)情報が示されている。
【００３２】ＷＷＷブラウザ１１内には，ＭＩＭＥテーブル１１ａが用意してある。ＭＩＭＥテーブル１１ａには，自分自身で処理できるＭＩＭＥ（ＨＴＭＬ，ＪＰＥＧ，ＧＩＦなど）と，ヘルパーアプリケーション若しくはプラグインアプリケーションで処理できるＭＩＭＥが登録されている。そして，応答データ４１を受け取ったＷＷＷブラウザ１１は，ＭＩＭＥテーブル１１ａにより，自分自身で処置できるか若しくは他のアプリケーションで処理するものであるかの判別を行う。自分自身で処理できるコンテンツであればＷＷＷブラウザ１１自身が処理するが，他のアプリケーションで処理するコンテンツの場合には，対応するプログラムを起動する。起動の際には，プログラムに対してコンテンツの中身をパラメータとして渡す。」
　
オ　「【００４５】ここで，ＷＷＷブラウザ１１から要求が出力された場合の処理手順を説明する。なお，ＷＷＷブラウザからの要求は，「（コマンド）  （プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」という内容である。コンテンツを取得する際のコマンドは「ＧＥＴ」である。また，ＷＷＷサーバ２１へアクセスする際は，プロトコルは「ｈｔｔｐ」と指定され，ストリーミングサーバへアクセスする際は，プロトコルは「ｐｎｍ」と指定される。
【００４６】図９は，ローカルプロキシィサーバの処理手順を示すフローチャートの前半である。なお，以下の処理は全てローカルプロキシィサーバ１３が行う。
［Ｓ１］以前の処理において保持されていた情報を初期化する。
［Ｓ２］ＷＷＷブラウザ１１から通信要求があるか否かを判断する。要求があればステップＳ３に進み，要求がなければこの処理を繰り返す。
［Ｓ３］記録媒体が読み取り可能状態（ready ）になっているか否かを判断する。読み取り可能であればステップＳ４に進み，読み取り可能でなければステップＳ２２に進む。
［Ｓ４］記録媒体から制御ファイル１４ａを取得する。図７の例では，統括ファイル１４ａａと，管理ファイル名一覧ファイル１４ａｂとを取得する。
［Ｓ５］正常に取得できたか否かを判断する。正常に取得できたらステップＳ６に進み，ファイルが発見できないか若しくは読み取りエラーが発生した場合にはステップＳ２２に進む。
［Ｓ６］取得した制御ファイル１４ａから，ホスト名とドキュメントベースディレクトリ名との組を全て取得する。
［Ｓ７］ローカル側ファイルリストを作成する。具体的には，全ての管理ファイル名一覧ファイル１４ａｂからパス名とファイル名との組を抽出し，それらをリストアップする。
［Ｓ８］ＷＷＷブラウザ１１からの要求に含まれるホスト名が，制御ファイル１４ａに登録されているか否かを判断する。登録されていればステップＳ９に進み，登録されていなければステップＳ２２に進む。
［Ｓ９］ＷＷＷブラウザ１１からの要求に含まれるベースパス名が，ステップＳ８で検出されたホスト名に対応して登録されているドキュメントベースディレクトリ名と一致するか否かを判断する。ベースパス名が一致すればステップＳ１０に進み，一致しなければステップＳ２２に進む。
［Ｓ１０］ローカル側ファイルリストに基づいて，ステップＳ８，Ｓ９で検出されたホスト名とドキュメントベースディレクトリ名との組の下に登録されている全ての管理ファイル名一覧ファイル内のパス名とファイル名とを抽出し，ＷＷＷブラウザ１１からの要求に含まれるパス名とファイル名との組に対応するものが有るか否かを判断する。対応するファイルがあればステップＳ１１に進み，対応するファイルがなければステップＳ２２に進む。
［Ｓ１１］ステップＳ８，Ｓ９で検出されたホスト名とベースパス名との組に対応するサーバ側制御ファイル名を制御ファイル１４ａから抽出し，該当するサーバから制御ファイルを取得する。
【００４７】図１０は，ローカルプロキシィサーバの処理手順を示すフローチャートの後半である。
［Ｓ１２］サーバ側の制御ファイルが正常に取得できたか否かを判断する。正常に取得できた場合にはステップＳ１３に進み，回線の未接続等によりファイルを取得できなかった場合にはステップＳ１６に進む。
［Ｓ１３］サーバ側の制御ファイルに基づいて，サーバ側ファイルリストを作成する。サーバ側ファイルリストの内容は，そのサーバの管理するコンテンツのパス名とファイル名との組の集合である。
［Ｓ１４］サーバ側ファイルリストに基づいて，ＷＷＷブラウザ１１からの要求に含まれるパス名とファイル名との組に対応するものが有るか否かを判断する。対応するファイルがあればステップＳ１５に進み，対応するファイルがなければステップＳ２２に進む。
［Ｓ１５］ステップＳ１０で検出されたファイルの版数と，ステップＳ１４で検出されたファイルの版数とを比較し，サーバ側ファイルの方が新しいか否かを判断する。サーバ側のファイルの方が新しければステップＳ１６に進み，そうでなければステップＳ２２に進む。
［Ｓ１６］補助記憶装置１４より，該当するファイルを取得する。
［Ｓ１７］正常に取得できたか否かを判断する。正常に取得できた場合にはステップＳ１８に進み，正常に取得できなかった場合にはステップＳ２２に進む。
［Ｓ１８］取得したファイルがメタファイルであるか否かを判断する。メタファイルであればステップS1９に進み，メタファイルでなければステップＳ２３に進む。
［Ｓ１９］メタファイル内のホスト名が，制御ファイル１４ａに登録されているか否かを判断する。登録されていればステップＳ２０に進み，登録されていなければステップＳ２３に進む。
［Ｓ２０］メタファイル内のベースパス名が，ステップＳ１９で検出されたホスト名に対応して登録されているベースパス名と一致するか否かを判断する。ベースパス名が一致すればステップＳ２１に進み，一致しなければステップＳ２３に進む。
［Ｓ２１］メタファイルの内容を変換する。具体的には，プロトコルを「file」に変更し，ホスト名とベースパス名とを，補助記憶装置１４を示す名称に変更する。例えば，「pnm://fujisan.gmsnet.or.jp/hylintk/01audio/hylintkla.ra」というメタファイルの場合，「file:d:/hylintk/01audio/hylintkla.ra」という内容に変更する。この例では，補助記憶装置はローカルコンピュータ１０においてドライブ名「ｄ」として認識されている。この処理が終了後，ステップＳ２３に進む。
【００４８】なお，ステップＳ２１における変換処理は，アプリケーション層のローカルプロキシィサーバによって要求を中継したために必要となった処理である。従って，アプリケーション層よりも下のレイヤで要求の中継を行えば，ステップＳ２１に示したような変換処理の必要はない。
［Ｓ２２］サーバからコンテンツを取得する。
［Ｓ２３］取得したデータにヘッダ情報を付加してＷＷＷブラウザ１１に返す。」
　
カ　「【００５３】さらに，コンテンツのアクセス順番（優先順位）を指定することもできる。このアクセス順番は，ローカル側の制御ファイル内に指定しておく。そして，ローカルプロキシィサーバがＷＷＷブラウザから要求を受け取った際には，指定された順番でコンテンツの存在に有無を確認する。そして，先に検出されたコンテンツをアクセスの対象とする（この場合，版数の比較は行わない）。例えば，「拡張ローカル（書き込み可能な記録媒体にキャッシングされたコンテンツ）→基準ローカル（予めＣＤ−ＲＯＭに格納されているコンテンツ）→サーバ（ネットワーク経由で取得するコンテンツ）」のようなアクセス順番を指定しておけば，サーバコンピュータ側の最新の情報を一括してダウンロードすることで，以後のサーバコンピュータへのアクセスが，制御ファイルの取得も含めて不要となる。」
　
キ　「【００５６】また，異なるサーバ内で同一のベースディレクトリ名を持つことがよくある。この場合，そのまま双方のコンテンツをローカルコンピュータの補助記憶装置に格納しようとすると，格納すべき場所が重複してしまう。そこで，一方のコンテンツは別な場所に格納する。このとき，もともと格納すべきであった場所の位置情報（パス）と実際に格納した場所の位置情報（パス）との対応関係を示す変換情報をローカルコンピュータ側の制御ファイルに格納しておく。ローカルプロキシィサーバは，変換情報に基づいて，補助記憶装置内の別の場所に格納されているコンテンツに対して正しくアクセスできる。
【００５７】例えば，「http://ashitaka.gmsnet.or.jp/r-pro/index.html」と「http://fujisan.gmsnet.or.jp/r-pro/index.html」とを補助記憶装置に格納する場合，それぞれのコンテンツを，「r-pro index.html」，「r-pro1 index.html」として格納する。そして，ローカルコンピュータの統括ファイルには，
HOST=ashitaka.gmsnet.or.jp
BASE(01)=r-pro
という記載と，
HOST=fujisan.gmsnet.or.jp
BASE(01)=r-pro
RENAME=r-pro1
という記載を含める。ここで，「ＨＯＳＴ」はホスト名を示し，「ＢＡＳＥ」はドキュメントベースディレクトリを示し，「ＲＥＮＡＭＥ」は変換先の位置情報を示している。これより，ローカルプロキシィサーバは，ＷＷＷブラウザから「http://ashitaka.gmsnet.or.jp/r-pro/index.html」が要求された際には，「r-pro index.html」にアクセスし，「http://fujisan.gmsnet.or.jp/r-pro/index.html」が要求された際には，「r-pro1 index.html」にアクセスできる。」
　
ク　「【００９４】
【発明の効果】以上説明したように本発明では，配信情報の複製情報をローカルコンピュータ内に格納しておき，サーバコンピュータ内の配信情報の取得要求をローカルプロキシィサーバが受け取り，適当な情報を決定するようにしたため，サーバコンピュータとの間で伝送される情報量を削減できる。また，ローカルコンピュータに格納するのは，配信情報の複製でよいため，複製情報を作成する際の手間も少ない。さらに，利用者は，サーバコンピュータから情報を取得する場合と同様の操作を行えばよいため，利用者に負担を強いることもない。」
　
　上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると，特に，ローカルコンピュータ１０のＷＷＷブラウザ１１からの要求に基づきＨＴＴＰコンテンツ（ファイル）を取得する手順に関する以下の技術事項が読み取れる。
　
ａ　ローカルコンピュータ１０のローカルプロキシィサーバ１３が，サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４のそれぞれに記憶された該当するファイルの版数を比較して，サーバ側ファイルの方が新しければサーバコンピュータ２０のデータベース２３から該当するファイルを取得し，そうでなければローカルコンピュータ１０の補助記憶装置１４から該当するファイルを取得している（【図１０】，段落【００４７】）
（当審注：段落【００１３】の「複製情報格納装置１ｂ内に該当する情報が存在し，しかも，最新の版数である場合には，複製情報格納装置１ｂから情報を取り出す。そうでなければサーバコンピュータ２から配信情報２ｂｂを取り出す。」等の記載及び技術常識に鑑みて，引用例の【図１０】のステップ１５に関する記載（段落【００４７】の[Ｓ１５]）は，正しくは「サーバ側ファイルの方が新しいか否かを判断する。サーバ側のファイルの方が新しければ
ステップＳ２２
ステップＳ１６
　
ｂ　ファイルの取得は，ローカルコンピュータ１０のＷＷＷブラウザ１１からの，「（コマンド）（プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」という共通の要求に基づいて実行される（段落【００４５】，【図１０】）。
　
ｃ　ファイルを取得したＷＷＷブラウザ１１は，該ファイルを自分自身で処理するか，もしくは，対応するアプリケーションプログラムを起動する（段落【００３２】）。
　
　以上を総合すると，上記引用例には，以下の発明（以下，「引用発明」という。）が開示されていると認める。
　
『ローカルコンピュータ１０のファイル取得方法において，
　ローカルコンピュータ１０のローカルプロキシィサーバ１３が，サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４のそれぞれに記憶された該当するファイルの版数を比較して，サーバ側ファイルの方が新しければサーバコンピュータ２０のデータベース２３から該当するファイルを取得し，そうでなければローカルコンピュータ１０の補助記憶装置１４から該当するファイルを取得すること，
　上記ファイルの取得は，ローカルコンピュータ１０のＷＷＷブラウザ１１からの，「（コマンド）（プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」という共通の要求に基づいて実行されること，
　ファイルを取得したＷＷＷブラウザ１１は，該ファイルを自分自身で処理するか，もしくは，対応するアプリケーションプログラムを起動すること，
　を含むファイル取得方法。』
　
３　対比
　本願発明と引用発明とを対比するに，
　
ａ　引用発明の「ファイル」は本願発明の「データ」に含まれ，また，その「取得」が「受信」によって行われることは明らかであるから，引用発明の「ローカルコンピュータ１０」は本願発明の「受信装置」に相当し，また，引用発明の「ローカルコンピュータ１０のファイル取得方法」は本願発明の「データを受信する受信装置の受信方法」に相当する。
　
ｂ　引用発明の「ローカルコンピュータ１０のローカルプロキシィサーバ１３が，サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４のそれぞれに記憶された該当するファイルの版数を比較して，サーバ側ファイルの方が新しければサーバコンピュータ２０のデータベース２３から該当するファイルを取得し，そうでなければローカルコンピュータ１０の補助記憶装置１４から該当するファイルを取得すること」と，
　本願発明の「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から，予め決められた順序に従って，前記ファイルを取得する取得先を決定する決定ステップ」とを対比するに，
　ｂ１　引用発明の「ローカルプロキシィサーバ１３」は「ローカルコンピュータ１０」に含まれるものであるから（段落【００１８】），引用発明の「ローカルコンピュータ１０のローカルプロキシィサーバ１３」は本願発明の「受信装置」に含まれる。
　ｂ２　引用発明の「サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４」は本願発明の「複数の格納媒体」に含まれる。
　ｂ３　引用発明の「それぞれに記憶された該当するファイルの版数を比較して，サーバ側ファイルの方が新しければサーバコンピュータ２０のデータベース２３から該当するファイルを取得し，そうでなければローカルコンピュータ１０の補助記憶装置１４から該当するファイルを取得すること」と，本願発明の「予め決められた順序に従って，前記ファイルを取得する取得先を決定するステップ」とは，「前記ファイルを取得する取得先を決定するステップ」である点で共通する。
　ｂ４　そうすると，両者は「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から，前記ファイルを取得する取得先を決定する決定ステップ」である点で共通するが，
　本願発明が「予め決められた順序に従って」取得先を決定するのに対し，引用発明は「ローカルコンピュータ１０のローカルプロキシィサーバ１３が，サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４のそれぞれに記憶された該当するファイルの版数を比較して，サーバ側ファイルの方が新しければサーバコンピュータ２０のデータベース２３から該当するファイルを取得し，そうでなければローカルコンピュータ１０の補助記憶装置１４から該当するファイルを取得する」，即ち，ファイルの版数の比較に基づいて取得先を決定する，点で相違する。
　
ｃ　引用発明の『上記ファイルの取得は，ローカルコンピュータ１０のＷＷＷブラウザ１１からの，「（コマンド）（プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」という共通の要求に基づいて実行されること』に関し，
　引用発明の，ファイル取得の「要求」である「（コマンド）（プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」のうち，「（ベースパス名）／［（パス名／）］ファイル名」が，（ホスト名）で指定された「ホスト」すなわち「サーバコンピュータ２０」における「ファイル」の格納場所を示すことは技術常識である。
　一方，ローカルコンピュータ１０の補助記憶装置１４からファイルを取得する場合も「共通の要求」に基づきファイル取得が実行されるが，引用例の
『【００５７】
例えば，「http://ashitaka.gmsnet.or.jp/r-pro/index.html」
を補助記憶装置に格納する場合，
コンテンツを，「r-pro index.html」
として格納する。
HOST=ashitaka.gmsnet.or.jp
BASE(01)=r-pro
という記載と，
HOST=fujisan.gmsnet.or.jp
BASE(01)=r-pro
RENAME=r-pro1
という記載を含める。ここで，「ＨＯＳＴ」はホスト名を示し，
「ＢＡＳＥ」はドキュメントベースディレクトリを示し，
これより，ローカルプロキシィサーバは，ＷＷＷブラウザから「http://ashitaka.gmsnet.or.jp/r-pro/index.html」が要求された際には，「r-pro index.html」にアクセスし
　に記載された例示によれば，引用発明の「補助記憶装置１４」において，「http://ashitaka.gmsnet.or.jp/r-pro/index.html」という要求に基づき取得されるコンテンツ（ファイル）の格納場所は「r-pro index.html」，即ち，「（ベースパス名）／［（パス名／）］ファイル名」であって，「サーバコンピュータ２０」における「ファイル」の格納場所と「共通する同一の」ものであることが分かる。
　そうすると，引用発明の「（ベースパス名）／［（パス名／）］ファイル名」は本願発明の「前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって，前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報」に含まれるものであって，引用発明の『上記ファイルの取得は，ローカルコンピュータ１０のＷＷＷブラウザ１１からの，「（コマンド）（プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」という共通の要求に基づいて実行されること』は，本願発明の「前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって，前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報に基づいて，前記取得先から前記ファイルを取得する取得ステップ」に相当する。
　
ｄ　引用発明の「該ファイルを自分自身で処理するか，もしくは，対応するアプリケーションプログラムを起動すること」は「ファイルを実行すること」と言えるから，引用発明の「ファイルを取得したＷＷＷブラウザ１１は，該ファイルを自分自身で処理するか，もしくは，対応するアプリケーションプログラムを起動すること」は，本願発明の「取得された前記ファイルを実行する実行ステップ」に相当する。
　
　以上をまとめると，両者は以下の点で一致ないし相違している。
　
（一致点）
「データを受信する受信装置の受信方法において，
　前記受信装置による，
　　前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から，前記ファイルを取得する取得先を決定する決定ステップと，
　　前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって，前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報に基づいて，前記取得先から前記ファイルを取得する取得ステップと，
　　取得された前記ファイルを実行する実行ステップと
　を含む受信方法。」
　
（相違点）
一致点の「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から，前記ファイルを取得する取得先を決定する決定ステップ」に関し，
　本願発明では，「予め決められた順序に従って」取得先を決定するのに対し，
　引用発明では，ファイルの版数の比較に基づいて取得先を決定する点。
　
４　検討
　上記相違点につき検討する。
　
　引用例に「【０００７】本発明はこのような点に鑑みてなされたものであり，一定期間更新する必要のないサーバ上のコンテンツをそのまま媒体に記録し，
そのコンテンツを格納しているサーバへのアクセスと同じ操作で，ローカル装置内の所望のコンテンツにアクセスすることのできる情報管理システムを提供することを目的とする
配信情報の複製情報をローカルコンピュータ内に格納しておき，サーバコンピュータ内の配信情報の取得要求をローカルプロキシィサーバが受け取り，適当な情報を決定するようにしたため，サーバコンピュータとの間で伝送される情報量を削減できる。
　加えて，引用例に「【００５３】さらに，
コンテンツのアクセス順番（優先順位）を指定することもできる。このアクセス順番は，ローカル側の制御ファイル内に指定しておく。そして，ローカルプロキシィサーバがＷＷＷブラウザから要求を受け取った際には，指定された順番でコンテンツの存在に有無を確認する。そして，先に検出されたコンテンツをアクセスの対象とする（この場合，版数の比較は行わない）。例えば，「拡張ローカル（書き込み可能な記録媒体にキャッシングされたコンテンツ）→基準ローカル（予めＣＤ−ＲＯＭに格納されているコンテンツ）→サーバ（ネットワーク経由で取得するコンテンツ）」のようなアクセス順番を指定しておけば
　そうすると，引用発明の「ローカルコンピュータ１０のローカルプロキシィサーバ１３が，サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４のそれぞれに記憶された該当するファイルの版数を比較して，サーバ側ファイルの方が新しければサーバコンピュータ２０のデータベース２３から該当するファイルを取得し，そうでなければローカルコンピュータ１０の補助記憶装置１４から該当するファイルを取得する」ことに替えて，
「ローカルコンピュータ１０のローカルプロキシィサーバ１３が，サーバコンピュータ２０のデータベース２３とローカルコンピュータ１０の補助記憶装置１４の中から，予め決められたアクセス順番としてローカルコンピュータ１０の補助記憶装置１４の方を優先して該当ファイルを取得する」ようにすること，即ち，
本願発明のように「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から，予め決められた順序に従って，前記ファイルを取得する取得先を決定する決定ステップ」を採用すること，
　は上記引用例の記載に基づいて当業者が容易に想到し得たものである。
　
　そして，本願発明が奏する効果も引用例から容易に予測出来る範囲内のものである。
　
５　むすび
　以上のとおり，本願発明は，上記引用例に記載された発明に基づいて，当業者が容易に発明をすることができたものと認められるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，他の請求項に係る発明について審理するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。