• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1324502
審判番号 不服2016-3914  
総通号数 207 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-03-31 
種別 拒絶査定不服の審決 
審判請求日 2016-03-15 
確定日 2017-02-01 
事件の表示 特願2012-531797「受信装置、受信方法、送信装置、送信方法、プログラム、及び放送システム」拒絶査定不服審判事件〔平成24年 3月 8日国際公開、WO2012/029566〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1 手続の経緯と本願発明
本願は,2011年8月22日(優先権主張2010年8月30日,2010年9月15日,2011年4月6日 米国)を国際出願日とする出願であって,平成27年5月11日付け拒絶理由通知に対して同年6月26日に意見書及び手続補正書が提出されたが同年12月7日付けで拒絶査定がなされ,これを不服として平成28年3月15日付けで審判請求がなされたものであって,その請求項12に係る発明(以下,「本願発明」という。)は,平成27年6月26日に提出された手続補正書の特許請求の範囲の請求項12に記載された以下のとおりのものと認める。

「データを受信する受信装置の受信方法において,
前記受信装置による,
前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から,予め決められた順序に従って,前記ファイルを取得する取得先を決定する決定ステップと,
前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって,前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報に基づいて,前記取得先から前記ファイルを取得する取得ステップと,
取得された前記ファイルを実行する実行ステップと
を含む受信方法。」

2 引用発明
原査定の拒絶の理由に引用された特開平11-249951号公報(以下,「引用例」という。)には,「情報管理システム,ローカルコンピュータ,サーバコンピュータ,情報取得プログラムを記録したコンピュータ読み取り可能な記録媒体及びサーバ用プログラムを記録したコンピュータ読み取り可能な記録媒体」(発明の名称)に関し,図面とともに以下の事項が記載されている。

ア 「【0004】
【発明が解決しようとする課題】しかし,コンテンツをキャッシュする方式では,最初のアクセスでは常にサーバから転送しなければならないという問題がある。また,キャッシュデータの保存には期限が設けられているのが普通であり,その期限以後のアクセスでは,やはり伝送路の伝送容量の影響を受けることとなる。
【0005】ところで,インターネットのコンテンツには,毎日のように更新されるものもあるが,一定期間更新する必要のないものもある。例えば,ある会合の参加者名簿のようなコンテンツは,その会合の開催と参加者が決定してから会合が終了するまで,内容の更新の必要はあまりない。しかも,特定の会員のみが参加する会合であれば,その会合に関するコンテンツは会員のみが閲覧できれば十分である。
【0006】そこで,特定の内容のコンテンツをCD-ROM(Compact Disk Read Only Memory)に記録し,必要としている者に配布しておくことが考えられる。ただし,この場合には,コンテンツを媒体に記録する際に,コンテンツ間のリンク関係を書き直さなければならない。すなわち,HTMLファイルがサーバに存在するときには,リンク先の指定や,インライン表示すべき画像ファイルの指定などは,指定先のファイルのサーバ上でのURL(Uniform Resource Locator)が割り当てられている。そのため,リンク先のファイルやインライン表示する画像ファイルなどを含めてCD-ROMに格納する場合,指定するファイルの場所は,ローカルの媒体となる。リンク先に対してローカルの媒体としてアクセスするには,URLの指定をローカルの名前に書き直す必要がある。この作業を全てのHTMLファイルに対して行うのは,非常に大変な作業である。
【0007】本発明はこのような点に鑑みてなされたものであり,一定期間更新する必要のないサーバ上のコンテンツをそのまま媒体に記録し,そのコンテンツを格納しているサーバへのアクセスと同じ操作で,ローカル装置内の所望のコンテンツにアクセスすることのできる情報管理システムを提供することを目的とする。」

イ 「【0013】このような情報管理システムにおいて,情報閲覧手段1aから要求中継手段1cに配信情報2bbの取得要求が出されると,その要求を要求中継手段1cが受け取り,内容を解析する。そして,要求相手のサーバ2aが管理しているサーバ側制御ファイル2baと,複製情報格納手段1b内のローカル側制御ファイル1baとを取得する。ここで,要求された情報が複製情報格納装置1b内に格納されているかを確認し,格納されている場合には,さらに,複製情報格納装置1b内の複製情報1bbの版数が最新のものかどうかを判断する。複製情報格納装置1b内に該当する情報が存在し,しかも,最新の版数である場合には,複製情報格納装置1bから情報を取り出す。そうでなければサーバコンピュータ2から配信情報2bbを取り出す。」

ウ 「【0017】図2は,本発明の第1の実施の形態の構成図である。図のように,ローカルコンピュータ10とサーバコンピュータ20とは,インターネット30を介して接続されている。
【0018】ローカルコンピュータ10には,WWWブラウザ11,ストリーミング再生プレーヤ12,ローカルプロキシーサーバ13,及び補助記憶装置14が設けられている。
【0019】WWWブラウザ11は,ローカルプロキシーサーバ13を介してサーバコンピュータ20への要求を出力する。そのために,一般的なWWWブラウザに設けられている,外部のプロキシィサーバの設定機能を用いる。すなわち,WWWブラウザ11において,プロキシィサーバの設定を「localhost(IPアドレス=127.0.0.1)」とする。これにより,WWWブラウザ11が動作しているローカルコンピュータ10内のプロキシィサーバ(ここでは,ローカルプロキシィサーバ13)が指定され,WWWブラウザ11からの要求をローカルプロキシィサーバ13で中継することができる。
【0020】ストリーミング再生プレイヤー12は,WWWブラウザ11からの要求に応じてストリーミングサーバ22へ要求を出し,返されたストリーミングコンテンツを再生する。
【0021】ローカルプロキシィサーバ13は,WWWブラウザ11がサーバコンピュータ20に対して出力する要求を中継する。そして,サーバコンピュータ20と補助記憶装置14との双方から,要求されたコンテンツの制御ファイル14a,24aを取得する。取得した制御ファイル14a,24aに基づいて,補助記憶装置14内のストリーミングコンテンツ14cが最新のものであるか否かを判断し,最新のコンテンツであればそのストリーミングコンテンツを補助記憶装置14から読み出し,そうでなければサーバコンピュータ20に格納されているストリーミングコンテンツ24bをインターネット30経由で取得する。
【0022】補助記憶装置14は,CD-ROMのような可搬型の記録媒体と,その媒体のデータの読み取り装置である。記録媒体には,制御ファイル14a,HTTPコンテンツ14b及びストリーミングコンテンツ14cとが格納されている。制御ファイル14aは,HTTPコンテンツ14bとストリーミングコンテンツ14cとの版数や,元のコンテンツの格納先などの情報を有するファイルである。HTTPコンテンツ14bとストリーミングコンテンツ14cとは,サーバコンピュータ20に格納されているHTTPコンテンツ23b,ストリーミングコンテンツ24bを,過去にそのまま複写したものである。
【0023】サーバコンピュータ20には,WWWサーバ21とストリーミングサーバ22とが設けられており,それぞれデータべース23,24を有している。データベース23には,制御ファイル23aとHTTPコンテンツ23bとが格納されており,データベース24には,制御ファイル24aとストリーミングコンテンツ24bが格納されている。」

エ 「【0027】ここで,WWWブラウザ11とストリーミング再生プレイヤー12とは,それぞれ対応するサーバとの間でデータの送受信を行う。その基本的な手順を以下に示す。
【0028】図4は,クライアントとサーバとの間のデータの流れを示す図である。まず,WWWブラウザ11からWWWサーバ21に対してTCPによりHTTP要求(GET,PUT等)が発行される。
【0029】一般例として「URL=http://fujisan.gmsnet.ro.jp/hylintk/kanda.html」を利用者がWWWブラウザ11に指定して起動をかけた場合を想定すると,WWWサーバ21に対する要求は,「GET http://fujisan.gmsnet.ro.jp/hylintk/kanda.html」となる。
【0030】すると,WWWサーバ21は,HTTPコンテンツ23bの中から要求されたHTMLファイルを取り出し,そのファイルにヘッダ情報を付加して応答データ41とする。WWWサーバ21は,この応答データ41をWWWブラウザ11へ返す。応答データ41には,以下のような内容が記述される。
【0031】図5は,応答データの内容を示す図である。応答データ41の先頭にヘッダ情報が付加されており,このヘッダ情報に続いてコンテンツの中身がHTMLで記述されている。ヘッダ情報には,「content-type」によりMIME(Multipurpose Internet Mail Extension)情報が示されている。
【0032】WWWブラウザ11内には,MIMEテーブル11aが用意してある。MIMEテーブル11aには,自分自身で処理できるMIME(HTML,JPEG,GIFなど)と,ヘルパーアプリケーション若しくはプラグインアプリケーションで処理できるMIMEが登録されている。そして,応答データ41を受け取ったWWWブラウザ11は,MIMEテーブル11aにより,自分自身で処置できるか若しくは他のアプリケーションで処理するものであるかの判別を行う。自分自身で処理できるコンテンツであればWWWブラウザ11自身が処理するが,他のアプリケーションで処理するコンテンツの場合には,対応するプログラムを起動する。起動の際には,プログラムに対してコンテンツの中身をパラメータとして渡す。」

オ 「【0045】ここで,WWWブラウザ11から要求が出力された場合の処理手順を説明する。なお,WWWブラウザからの要求は,「(コマンド) (プロトコル)://(ホスト名)/(ベースパス名)/[(パス名/)]ファイル名」という内容である。コンテンツを取得する際のコマンドは「GET」である。また,WWWサーバ21へアクセスする際は,プロトコルは「hｔｔｐ」と指定され,ストリーミングサーバへアクセスする際は,プロトコルは「ｐnm」と指定される。
【0046】図9は,ローカルプロキシィサーバの処理手順を示すフローチャートの前半である。なお,以下の処理は全てローカルプロキシィサーバ13が行う。
[S1]以前の処理において保持されていた情報を初期化する。
[S2]WWWブラウザ11から通信要求があるか否かを判断する。要求があればステップS3に進み,要求がなければこの処理を繰り返す。
[S3]記録媒体が読み取り可能状態(ready )になっているか否かを判断する。読み取り可能であればステップS4に進み,読み取り可能でなければステップS22に進む。
[S4]記録媒体から制御ファイル14aを取得する。図7の例では,統括ファイル14aaと,管理ファイル名一覧ファイル14abとを取得する。
[S5]正常に取得できたか否かを判断する。正常に取得できたらステップS6に進み,ファイルが発見できないか若しくは読み取りエラーが発生した場合にはステップS22に進む。
[S6]取得した制御ファイル14aから,ホスト名とドキュメントベースディレクトリ名との組を全て取得する。
[S7]ローカル側ファイルリストを作成する。具体的には,全ての管理ファイル名一覧ファイル14abからパス名とファイル名との組を抽出し,それらをリストアップする。
[S8]WWWブラウザ11からの要求に含まれるホスト名が,制御ファイル14aに登録されているか否かを判断する。登録されていればステップS9に進み,登録されていなければステップS22に進む。
[S9]WWWブラウザ11からの要求に含まれるベースパス名が,ステップS8で検出されたホスト名に対応して登録されているドキュメントベースディレクトリ名と一致するか否かを判断する。ベースパス名が一致すればステップS10に進み,一致しなければステップS22に進む。
[S10]ローカル側ファイルリストに基づいて,ステップS8,S9で検出されたホスト名とドキュメントベースディレクトリ名との組の下に登録されている全ての管理ファイル名一覧ファイル内のパス名とファイル名とを抽出し,WWWブラウザ11からの要求に含まれるパス名とファイル名との組に対応するものが有るか否かを判断する。対応するファイルがあればステップS11に進み,対応するファイルがなければステップS22に進む。
[S11]ステップS8,S9で検出されたホスト名とベースパス名との組に対応するサーバ側制御ファイル名を制御ファイル14aから抽出し,該当するサーバから制御ファイルを取得する。
【0047】図10は,ローカルプロキシィサーバの処理手順を示すフローチャートの後半である。
[S12]サーバ側の制御ファイルが正常に取得できたか否かを判断する。正常に取得できた場合にはステップS13に進み,回線の未接続等によりファイルを取得できなかった場合にはステップS16に進む。
[S13]サーバ側の制御ファイルに基づいて,サーバ側ファイルリストを作成する。サーバ側ファイルリストの内容は,そのサーバの管理するコンテンツのパス名とファイル名との組の集合である。
[S14]サーバ側ファイルリストに基づいて,WWWブラウザ11からの要求に含まれるパス名とファイル名との組に対応するものが有るか否かを判断する。対応するファイルがあればステップS15に進み,対応するファイルがなければステップS22に進む。
[S15]ステップS10で検出されたファイルの版数と,ステップS14で検出されたファイルの版数とを比較し,サーバ側ファイルの方が新しいか否かを判断する。サーバ側のファイルの方が新しければステップS16に進み,そうでなければステップS22に進む。
[S16]補助記憶装置14より,該当するファイルを取得する。
[S17]正常に取得できたか否かを判断する。正常に取得できた場合にはステップS18に進み,正常に取得できなかった場合にはステップS22に進む。
[S18]取得したファイルがメタファイルであるか否かを判断する。メタファイルであればステップS19に進み,メタファイルでなければステップS23に進む。
[S19]メタファイル内のホスト名が,制御ファイル14aに登録されているか否かを判断する。登録されていればステップS20に進み,登録されていなければステップS23に進む。
[S20]メタファイル内のベースパス名が,ステップS19で検出されたホスト名に対応して登録されているベースパス名と一致するか否かを判断する。ベースパス名が一致すればステップS21に進み,一致しなければステップS23に進む。
[S21]メタファイルの内容を変換する。具体的には,プロトコルを「file」に変更し,ホスト名とベースパス名とを,補助記憶装置14を示す名称に変更する。例えば,「pnm://fujisan.gmsnet.or.jp/hylintk/01audio/hylintkla.ra」というメタファイルの場合,「file:d:/hylintk/01audio/hylintkla.ra」という内容に変更する。この例では,補助記憶装置はローカルコンピュータ10においてドライブ名「d」として認識されている。この処理が終了後,ステップS23に進む。
【0048】なお,ステップS21における変換処理は,アプリケーション層のローカルプロキシィサーバによって要求を中継したために必要となった処理である。従って,アプリケーション層よりも下のレイヤで要求の中継を行えば,ステップS21に示したような変換処理の必要はない。
[S22]サーバからコンテンツを取得する。
[S23]取得したデータにヘッダ情報を付加してWWWブラウザ11に返す。」

カ 「【0053】さらに,コンテンツのアクセス順番(優先順位)を指定することもできる。このアクセス順番は,ローカル側の制御ファイル内に指定しておく。そして,ローカルプロキシィサーバがWWWブラウザから要求を受け取った際には,指定された順番でコンテンツの存在に有無を確認する。そして,先に検出されたコンテンツをアクセスの対象とする(この場合,版数の比較は行わない)。例えば,「拡張ローカル(書き込み可能な記録媒体にキャッシングされたコンテンツ)→基準ローカル(予めCD-ROMに格納されているコンテンツ)→サーバ(ネットワーク経由で取得するコンテンツ)」のようなアクセス順番を指定しておけば,サーバコンピュータ側の最新の情報を一括してダウンロードすることで,以後のサーバコンピュータへのアクセスが,制御ファイルの取得も含めて不要となる。」

キ 「【0056】また,異なるサーバ内で同一のベースディレクトリ名を持つことがよくある。この場合,そのまま双方のコンテンツをローカルコンピュータの補助記憶装置に格納しようとすると,格納すべき場所が重複してしまう。そこで,一方のコンテンツは別な場所に格納する。このとき,もともと格納すべきであった場所の位置情報(パス)と実際に格納した場所の位置情報(パス)との対応関係を示す変換情報をローカルコンピュータ側の制御ファイルに格納しておく。ローカルプロキシィサーバは,変換情報に基づいて,補助記憶装置内の別の場所に格納されているコンテンツに対して正しくアクセスできる。
【0057】例えば,「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"
という記載を含める。ここで,「HOST」はホスト名を示し,「BASE」はドキュメントベースディレクトリを示し,「RENAME」は変換先の位置情報を示している。これより,ローカルプロキシィサーバは,WWWブラウザから「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」にアクセスできる。」

ク 「【0094】
【発明の効果】以上説明したように本発明では,配信情報の複製情報をローカルコンピュータ内に格納しておき,サーバコンピュータ内の配信情報の取得要求をローカルプロキシィサーバが受け取り,適当な情報を決定するようにしたため,サーバコンピュータとの間で伝送される情報量を削減できる。また,ローカルコンピュータに格納するのは,配信情報の複製でよいため,複製情報を作成する際の手間も少ない。さらに,利用者は,サーバコンピュータから情報を取得する場合と同様の操作を行えばよいため,利用者に負担を強いることもない。」

上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると,特に,ローカルコンピュータ10のWWWブラウザ11からの要求に基づきHTTPコンテンツ(ファイル)を取得する手順に関する以下の技術事項が読み取れる。

a ローカルコンピュータ10のローカルプロキシィサーバ13が,サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14のそれぞれに記憶された該当するファイルの版数を比較して,サーバ側ファイルの方が新しければサーバコンピュータ20のデータベース23から該当するファイルを取得し,そうでなければローカルコンピュータ10の補助記憶装置14から該当するファイルを取得している(【図10】,段落【0047】)
(当審注:段落【0013】の「複製情報格納装置1b内に該当する情報が存在し,しかも,最新の版数である場合には,複製情報格納装置1bから情報を取り出す。そうでなければサーバコンピュータ2から配信情報2bbを取り出す。」等の記載及び技術常識に鑑みて,引用例の【図10】のステップ15に関する記載(段落【0047】の[S15])は,正しくは「サーバ側ファイルの方が新しいか否かを判断する。サーバ側のファイルの方が新しければステップS22に進み,そうでなければステップS16に進む。」であると判断した。)。

b ファイルの取得は,ローカルコンピュータ10のWWWブラウザ11からの,「(コマンド)(プロトコル)://(ホスト名)/(ベースパス名)/[(パス名/)]ファイル名」という共通の要求に基づいて実行される(段落【0045】,【図10】)。

c ファイルを取得したWWWブラウザ11は,該ファイルを自分自身で処理するか,もしくは,対応するアプリケーションプログラムを起動する(段落【0032】)。

以上を総合すると,上記引用例には,以下の発明(以下,「引用発明」という。)が開示されていると認める。

『ローカルコンピュータ10のファイル取得方法において,
ローカルコンピュータ10のローカルプロキシィサーバ13が,サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14のそれぞれに記憶された該当するファイルの版数を比較して,サーバ側ファイルの方が新しければサーバコンピュータ20のデータベース23から該当するファイルを取得し,そうでなければローカルコンピュータ10の補助記憶装置14から該当するファイルを取得すること,
上記ファイルの取得は,ローカルコンピュータ10のWWWブラウザ11からの,「(コマンド)(プロトコル)://(ホスト名)/(ベースパス名)/[(パス名/)]ファイル名」という共通の要求に基づいて実行されること,
ファイルを取得したWWWブラウザ11は,該ファイルを自分自身で処理するか,もしくは,対応するアプリケーションプログラムを起動すること,
を含むファイル取得方法。』

3 対比
本願発明と引用発明とを対比するに,

a 引用発明の「ファイル」は本願発明の「データ」に含まれ,また,その「取得」が「受信」によって行われることは明らかであるから,引用発明の「ローカルコンピュータ10」は本願発明の「受信装置」に相当し,また,引用発明の「ローカルコンピュータ10のファイル取得方法」は本願発明の「データを受信する受信装置の受信方法」に相当する。

b 引用発明の「ローカルコンピュータ10のローカルプロキシィサーバ13が,サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14のそれぞれに記憶された該当するファイルの版数を比較して,サーバ側ファイルの方が新しければサーバコンピュータ20のデータベース23から該当するファイルを取得し,そうでなければローカルコンピュータ10の補助記憶装置14から該当するファイルを取得すること」と,
本願発明の「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から,予め決められた順序に従って,前記ファイルを取得する取得先を決定する決定ステップ」とを対比するに,
b1 引用発明の「ローカルプロキシィサーバ13」は「ローカルコンピュータ10」に含まれるものであるから(段落【0018】),引用発明の「ローカルコンピュータ10のローカルプロキシィサーバ13」は本願発明の「受信装置」に含まれる。
b2 引用発明の「サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14」は本願発明の「複数の格納媒体」に含まれる。
b3 引用発明の「それぞれに記憶された該当するファイルの版数を比較して,サーバ側ファイルの方が新しければサーバコンピュータ20のデータベース23から該当するファイルを取得し,そうでなければローカルコンピュータ10の補助記憶装置14から該当するファイルを取得すること」と,本願発明の「予め決められた順序に従って,前記ファイルを取得する取得先を決定するステップ」とは,「前記ファイルを取得する取得先を決定するステップ」である点で共通する。
b4 そうすると,両者は「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から,前記ファイルを取得する取得先を決定する決定ステップ」である点で共通するが,
本願発明が「予め決められた順序に従って」取得先を決定するのに対し,引用発明は「ローカルコンピュータ10のローカルプロキシィサーバ13が,サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14のそれぞれに記憶された該当するファイルの版数を比較して,サーバ側ファイルの方が新しければサーバコンピュータ20のデータベース23から該当するファイルを取得し,そうでなければローカルコンピュータ10の補助記憶装置14から該当するファイルを取得する」,即ち,ファイルの版数の比較に基づいて取得先を決定する,点で相違する。

c 引用発明の『上記ファイルの取得は,ローカルコンピュータ10のWWWブラウザ11からの,「(コマンド)(プロトコル)://(ホスト名)/(ベースパス名)/[(パス名/)]ファイル名」という共通の要求に基づいて実行されること』に関し,
引用発明の,ファイル取得の「要求」である「(コマンド)(プロトコル)://(ホスト名)/(ベースパス名)/[(パス名/)]ファイル名」のうち,「(ベースパス名)/[(パス名/)]ファイル名」が,(ホスト名)で指定された「ホスト」すなわち「サーバコンピュータ20」における「ファイル」の格納場所を示すことは技術常識である。
一方,ローカルコンピュータ10の補助記憶装置14からファイルを取得する場合も「共通の要求」に基づきファイル取得が実行されるが,引用例の
『【0057】例えば,「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"
という記載を含める。ここで,「HOST」はホスト名を示し,「BASE」はドキュメントベースディレクトリを示し,「RENAME」は変換先の位置情報を示している。これより,ローカルプロキシィサーバは,WWWブラウザから「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」にアクセスできる。』
に記載された例示によれば,引用発明の「補助記憶装置14」において,「http://ashitaka.gmsnet.or.jp/r-pro/index.html」という要求に基づき取得されるコンテンツ(ファイル)の格納場所は「r-pro index.html」,即ち,「(ベースパス名)/[(パス名/)]ファイル名」であって,「サーバコンピュータ20」における「ファイル」の格納場所と「共通する同一の」ものであることが分かる。
そうすると,引用発明の「(ベースパス名)/[(パス名/)]ファイル名」は本願発明の「前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって,前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報」に含まれるものであって,引用発明の『上記ファイルの取得は,ローカルコンピュータ10のWWWブラウザ11からの,「(コマンド)(プロトコル)://(ホスト名)/(ベースパス名)/[(パス名/)]ファイル名」という共通の要求に基づいて実行されること』は,本願発明の「前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって,前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報に基づいて,前記取得先から前記ファイルを取得する取得ステップ」に相当する。

d 引用発明の「該ファイルを自分自身で処理するか,もしくは,対応するアプリケーションプログラムを起動すること」は「ファイルを実行すること」と言えるから,引用発明の「ファイルを取得したWWWブラウザ11は,該ファイルを自分自身で処理するか,もしくは,対応するアプリケーションプログラムを起動すること」は,本願発明の「取得された前記ファイルを実行する実行ステップ」に相当する。

以上をまとめると,両者は以下の点で一致ないし相違している。

(一致点)
「データを受信する受信装置の受信方法において,
前記受信装置による,
前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から,前記ファイルを取得する取得先を決定する決定ステップと,
前記格納媒体における前記ファイルの格納場所を表すファイル取得情報であって,前記複数の格納媒体それぞれに共通する同一の前記ファイル取得情報に基づいて,前記取得先から前記ファイルを取得する取得ステップと,
取得された前記ファイルを実行する実行ステップと
を含む受信方法。」

(相違点)
一致点の「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から,前記ファイルを取得する取得先を決定する決定ステップ」に関し,
本願発明では,「予め決められた順序に従って」取得先を決定するのに対し,
引用発明では,ファイルの版数の比較に基づいて取得先を決定する点。

4 検討
上記相違点につき検討する。

引用例に「【0007】本発明はこのような点に鑑みてなされたものであり,一定期間更新する必要のないサーバ上のコンテンツをそのまま媒体に記録し,そのコンテンツを格納しているサーバへのアクセスと同じ操作で,ローカル装置内の所望のコンテンツにアクセスすることのできる情報管理システムを提供することを目的とする。」,「【0094】【発明の効果】以上説明したように本発明では,配信情報の複製情報をローカルコンピュータ内に格納しておき,サーバコンピュータ内の配信情報の取得要求をローカルプロキシィサーバが受け取り,適当な情報を決定するようにしたため,サーバコンピュータとの間で伝送される情報量を削減できる。また,ローカルコンピュータに格納するのは,配信情報の複製でよいため,複製情報を作成する際の手間も少ない。さらに,利用者は,サーバコンピュータから情報を取得する場合と同様の操作を行えばよいため,利用者に負担を強いることもない。」とあるように,引用発明におけるファイルの取得先としては,伝送量が削減できる「ローカルコンピュータ10の補助記憶装置14」を優先すべきであることが明記されている。
加えて,引用例に「【0053】さらに,コンテンツのアクセス順番(優先順位)を指定することもできる。このアクセス順番は,ローカル側の制御ファイル内に指定しておく。そして,ローカルプロキシィサーバがWWWブラウザから要求を受け取った際には,指定された順番でコンテンツの存在に有無を確認する。そして,先に検出されたコンテンツをアクセスの対象とする(この場合,版数の比較は行わない)。例えば,「拡張ローカル(書き込み可能な記録媒体にキャッシングされたコンテンツ)→基準ローカル(予めCD-ROMに格納されているコンテンツ)→サーバ(ネットワーク経由で取得するコンテンツ)」のようなアクセス順番を指定しておけば,サーバコンピュータ側の最新の情報を一括してダウンロードすることで,以後のサーバコンピュータへのアクセスが,制御ファイルの取得も含めて不要となる。」とあるように,ファイルの版数の比較を行うこと無く,予め指定されたアクセス順番(優先順位)に基づいて,サーバよりもローカルのCD-ROM(補助記憶装置)の方を優先的な取得先とすることも記載されている。
そうすると,引用発明の「ローカルコンピュータ10のローカルプロキシィサーバ13が,サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14のそれぞれに記憶された該当するファイルの版数を比較して,サーバ側ファイルの方が新しければサーバコンピュータ20のデータベース23から該当するファイルを取得し,そうでなければローカルコンピュータ10の補助記憶装置14から該当するファイルを取得する」ことに替えて,
「ローカルコンピュータ10のローカルプロキシィサーバ13が,サーバコンピュータ20のデータベース23とローカルコンピュータ10の補助記憶装置14の中から,予め決められたアクセス順番としてローカルコンピュータ10の補助記憶装置14の方を優先して該当ファイルを取得する」ようにすること,即ち,
本願発明のように「前記受信装置が取得すべきファイルを格納している複数の格納媒体の中から,予め決められた順序に従って,前記ファイルを取得する取得先を決定する決定ステップ」を採用すること,
は上記引用例の記載に基づいて当業者が容易に想到し得たものである。

そして,本願発明が奏する効果も引用例から容易に予測出来る範囲内のものである。

5 むすび
以上のとおり,本願発明は,上記引用例に記載された発明に基づいて,当業者が容易に発明をすることができたものと認められるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,他の請求項に係る発明について審理するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2016-08-30 
結審通知日 2016-09-01 
審決日 2016-09-20 
出願番号 特願2012-531797(P2012-531797)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 小林 秀和、田中 啓介  
特許庁審判長 高瀬 勤
特許庁審判官 新川 圭二
山澤 宏
発明の名称 受信装置、受信方法、送信装置、送信方法、プログラム、及び放送システム  
代理人 西川 孝  
代理人 稲本 義雄  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ