【事件の表示】
　特願２００１−５５５３５４「起点サーバとクライアントとの間のメディアリソースリクエストおよび／または応答を書き換えるシステムおよび方法」拒絶査定不服審判事件〔平成１３年　８月　２日国際公開、ＷＯ０１／５５８７８、平成１５年　７月　８日国内公表、特表２００３−５２１０６７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯 
 　本願は、２００１年１月２９日（パリ条約による優先権主張外国庁受理２０００年１月２８日、米国）を国際出願日とする出願であって、平成２３年３月２２日付けでした拒絶査定に対し、同年７月２５日に審判請求がなされるとともに、手続補正がなされたものである。
 　　　　　 
第２．本願発明について
　本願発明は、前記平成２３年７月２５日付け手続補正により補正された明細書及び図面の記載からみて、その特許請求の範囲に記載されたとおりのものと認められるところ、請求項６に記載された発明（以下、「本願発明」という。）は、以下のとおりのものである
　
〈本願発明〉
　分散型データ送達ネットワークからデータをリクエストするユーザからのデータリクエストに対する応答を処理するシステムであって、
　該システムは、
　データ応答変更器と、
　データ送達デバイスと
　を備えており、
　該データ応答変更器は、該ネットワーク内のデータサーバによって発せられたデータ応答を傍受および変更するように適合されており、該データサーバは、該ユーザーからの該データリクエストに応答し、該データ応答変更器は、変更されたデータ応答を、該リクエストされたデータが該ユーザに届く前に生成し、該変更されたデータ応答は、該ネットワーク内の代替データサーバからの該リクエストされたデータの送達をアクティベートし、該リクエストされたデータは、該代替データサーバから該ユーザへの送達を介して変更されないままであり、
　該データ送達デバイスは、該変更されたデータ応答に基づいて、該分散型データ送達ネットワーク内の該代替データサーバから該ユーザへの該リクエストされたデータのルーティングを制御するように適合されている、システム。
  　
第３．引用例
　原査定の拒絶の理由に引用された、本願の優先日前の他の出願であって、その出願後に公開された外国語でなされた国際出願（ＰＣＴ／ＵＳ９９／２７３２５号、国際公開第００／２９９９０号）の願書に最初に添付された明細書及び図面（以下「先願明細書」という。）には、次の事項が記載されている（ここでの翻訳文は、この国際出願の日本国を指定官庁として、その翻訳文が公表された特表２００２−５３０７４９号公報の記載を参照した。）。
　
　ａ．「DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
 Turning attention now to the drawings more particularly, Fig. 1 is a system level diagram of a computer network in which media file requests are served according to the invention. As is typical in computer networks such as the Internet, a home or origin location 10 contains a number of computers. At certain points of presence (POPs) 30 in the network, additional computing and communications equipment permit the establishment of connections over the Internet 20 to other computers (known as clients) at a user site 40. The computers at the origin location 10 are typically referred to as servers. In the context of the Web, for example, one type of computer may be a Web server 12 that serves documents in the well known Hypertext Markup Language (HTML), or other formats. In this environment, the clients 40 run software that is enabled to interpret and display HTML files such as Web browsers like Netscape Navigator, or Microsoft Internet Explorer.
　In the illustrated scenario, a media server 14 contains multimedia documents such as streaming audio or streaming video files that are associated with the Web server 12. The media server 14 is typically implemented with an architecture especially optimized for supporting the high speed presentation of such video and audio files . Both the Web server 12 and media server 14 make connections through a router 16 to provide such media files to client computers 40 connected to the Internet 20. Although the Web server 12 and media server 14 are shown as being co-located at the same site, it should be understood that they may be physically located at different sites.
　At the point of presence 30, computing and communications equipment include a router 32, a link 34, a cache redirector 36, a media cache 38, and a local area network 39. The point of presence 30 may, for example, be an intranet gateway or an Internet service provider (ISP) . In the former case, the end nodes 42 may be directly connected to the local area network 39. In the latter case, a Remote Access Server (RAS) device 45 provides communication connections through another network 50 such as the Public Switch Telephone Network (PSTN) to subscribers units 52 located, for example, within homes or businesses that make connections through a dial up network. 
　The remote access server 45 preferably makes use of high speed subscriber interconnection equipment such as Digital Subscriber Line (xDSL) , cable modems, or other high speed interconnectivity devices. The remote access server 45 may, for example, be a xDSL  multiplexer, cable modem head end, Tl converter, or other such equipment which concentrates Internet protocol (IP) type traffic and forwards it over connections such as the public switch telephone network or cable distribution network. 
　In accordance with the invention, also located at the point of presence 30 is a media cache 38. Media cache 38 is populated with media files that are most popularly requested by the users of the client computers 42 and 52. In general, the idea behind the present invention is that when a streaming media file request is made by one of the clients 42 or 52, steps are taken to ensure that the request is served from the media cache 38 located at the point of presence 30, as opposed to having to retrieve the requested streaming media file from the media server 14 on the other side of the Internet 20.」（明細書８頁１５行〜１０頁１７行の記載）
　訳：「【発明の実施の形態】
  本発明の前記およびその他の目的、特徴および利点は、添付の図に示された本発明の好ましい実施形態の詳細な説明から明らかであり、図を通じ同じ部品については同じ表示記号が用いられ、また図面は必ずしも縮尺を使用せず、本発明の原理を示すために誇張が施される。
      【００２２】
  特に図面の中で図１は、
メディアファイル要求が
なされるコンピュータネットワーク
オリジン位置１０は多数のコンピュータを含む。ネットワークの中のある存在位置（ＰＯＰｓ）においては、追加のコンピューティングおよびコミュニケーション機器により、ユーザーサイト４０において他のコンピュータ（クライアントとして知られている）へのインターネット２０を介しての接続が可能となる。オリジン位置１０でのコンピュータは、通常サーバーと呼ばれる
      【００２３】
  図示されたシナリオでは、
メディアサーバー１４は、Ｗｅｂサーバー１２に付随するストリーミングオーディオまたはストリーミングビデオファイルのようなマルチメディアドキュメントを含む
Ｗｅｂサーバー１２およびメディアサーバー１４は、同じサイトにともに存在するように示され
      【００２４】
  
存在点３０において、コンピューティングおよびコミュニケーション機器は、ルータ３２、リンク３４、キャッシュ転送器３６、メディアキャッシュ３８およびローカルエリアネットワーク３９を含む
      【００２５】
  リモートアクセスサーバー４５には、好ましくは、Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ（ｘＤＳＬ）、ケーブルモデム、または他の高速の内部接続装置のような、高速サブスクライバ相互接続機器を用いる。リモートアクセスサーバー４５には、例えばｘＤＳＬマルチプレクサ、ケーブルモデムヘッドエンド、Ｔｌコンバータ、または、Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｃｏｌ（ＩＰ）タイプトラフィックを集中してこれをパブリックスイッチテレフォンネットワークまたはケーブルディストリビューションネットワークのような接続を通して送るような他の機器を用いることができる。
      【００２６】
  本発明によれば、
存在点３０にはメディアキャッシュ３８も存在する。メディアキャッシュ３８は、クライアントコンピュータ４２および５２のユーザーにより最も一般に要求されるメディアファイルを存在させる
　
　ｂ．「In accordance with a preferred embodiment of the invention, a different sequence of events occurs in order to maximize the speed at which the media file is made available to the clients 42, 52. As shown in Fig. 3, from an initial idle state 100, the first three steps occur as with the prior art. In particular, in state 102, the user makes a request for the streaming media file such as by specifying it at the browser 54 either by clicking on a hypertext link within a Web page, or by presenting the URL for the corresponding MRF file directly to the browser 54. In the next state 104, the browser program requests the MRF file from the Web server 12. In state 106, the Web server 12 then returns the MRF file through the Internet 20 in the direction of the client 42, 52. 
　However, in state 108, the link 34 and cache redirector 36 recognize and intercept the MRF file on its way through the Internet 20 towards the clients 42, 52. In a state 110, the cache redirector 36 thus determines whether or not a streaming file referenced by the MRF file is available in the local media cache 38. If it is, then processing continues to state 114. If it is not, however, then processing continues to a state 112 in which the redirector 36 sends a modified MRF request to the media server 14, requesting that the media file be instead sent to the media cache 38. 
　In any event, processing continues to a state 114 in which the redirector 36 changes the href reference within the MRF file before forwarding the MRF file to the users 52, 42. This modification by the redirector 36 inserts the URL of the media cache 38 into the MRF file so that the request will be serviced by the media cache 38 instead of the media server 14. 
　In state 116, the browser opens the media player program 56 and in state 118 the media player 56 obtains the information stream from the media cache 38. 
　The cache redirector 36 must know or have access to information indicating what is stored in the media cache 38. The cache redirector 36 may therefore actually be responsible for controlling what is stored in the media cache 38 and so must manage storage availability in the media cache 38 so that old or unused files are overwritten or deleted. 
　The cache redirector 36 can be implemented as a small server that watches traffic and intercepts MRF files, and the reroutes them as necessary to the media cache 38. The media cache may be, for example, a type of computing system known as a Media Server available from Microsoft or a Real Video Server available from RealNetworks .」（明細書１２頁６行〜１３頁２２行）
　訳「【００３１】
  本発明の好ましい実施形態によれば、
メディアファイルがクライアント４２、５２に入手される時の速度を最高にするために、
最初のアイドルステート（待機状態）１００から、公知技術の場合と同様に最初の３つのステップが起きる。特にステート１０２においては、ユーザーはＷｅｂページの中でｈｙｐｅｒｔｅｘｔリンクをクリックし、または該当のＭＲＦファイルのためのＵＲＬを直接ブラウザ５４に送ることにより、ブラウザ５４において特定してストリーミングメディアファイルに対する（を求める）要求を行う。次のステート１０４において、ブラウザプログラムは、Ｗｅｂサーバー１２にＭＲＦファイルを送るよう要求する。次に、ステート１０６において、Ｗｅｂサーバー１２は、インターネット２０を通してＭＲＦファイルをクライアント４２、５２の方向に返送する
      【００３２】
  しかし、
ステート１０８において、リンク３４およびキャッシュ転送器３６は、クライアント４２、５２にインターネット２０を通して向かう途上のＭＲＦファイルを認識し、捕らえる。ステート１１０においては、ＭＲＦファイルにより参照されるストリーミングファイルが端末メディアキャッシュ３８で入手できるか否かを、キャッシュ転送器３６が確かめる。入手できる場合には、処理はステート１１４に進む。入手できない場合には、処理はステート１１２に進み、転送器３６は、変更されたＭＲＦ要求をメディアサーバー１４に送り、メディアファイルが代わりにメディアキャッシュ３８に送られるように要求する
      【００３３】
 
 いずれにしろ処理はステート１１４にまで続き、ここで転送器３６は、ＭＲＦファイルをユーザー５２、４２に送る前に、ＭＲＦファイルの中の＜ｈｒｅｆ＞リファレンスを変更する。転送器３６によるこの変更では、メディアキャッシュ３８のＵＲＬをＭＲＦファイルに挿入し、それによって要求はメディアサーバー１４の代わりにメディアキャッシュ３８によりサービスされる
      【００３４】
  
ステート１１６においては、ブラウザはメディアプレーヤープログラム５６を開き、ステート１１８においては、メディアプレーヤー５６は情報ストリームをメディアキャッシュ３８から入手する
      【００３５】
  キャッシュ転送器３６は、メディアキャッシュ３８の中に蓄積されているものを示す情報を知り、またはアクセスすることができねばならない。したがって、
キャッシュ転送器３６は、メディアキャッシュ３８の中に蓄積されているものをコントロールするための責任を実際に負うことができ、
      【００３６】
  
キャッシュ転送器３６は、トラフィックを監視し、ＭＲＦファイルを捕らえ、必要に応じてメディアキャッシュ３８へＭＲＦファイルのルートを変更する小型のサーバーとして用いられる。メディアキャッシュには、例えばＭｉｃｒｏｓｏｆｔから入手できるＭｅｄｉａ  Ｓｅｒｖｅｒ、またはＲｅａｌＮｅｔｗｏｒｋｓから入手できるＲｅａｌ  Ｖｉｄｅｏ  Ｓｅｒｖｅｒとして知られている一種のコンピューティングシステムを用いることができる
　
　 
 　これらの記載事項によると、先願明細書には、以下の発明（以下、「先願発明」という。）が記載されている。 
　
〈先願発明〉
　メディアファイル要求がなされるコンピュータネットワークであって、
　オリジン位置１０は多数のコンピュータを含み、ネットワークの中のある存在位置（ＰＯＰｓ）においては、追加のコンピューティングおよびコミュニケーション機器により、ユーザーサイト４０において他のコンピュータ（クライアントとして知られている）へのインターネット２０を介しての接続が可能となり、オリジン位置１０でのコンピュータは、通常サーバーと呼ばれ、
　メディアサーバー１４は、Ｗｅｂサーバー１２に付随するストリーミングオーディオまたはストリーミングビデオファイルのようなマルチメディアドキュメントを含み、Ｗｅｂサーバー１２およびメディアサーバー１４は、同じサイトにともに存在するように示され、  存在点３０において、コンピューティングおよびコミュニケーション機器は、ルータ３２、リンク３４、キャッシュ転送器３６、メディアキャッシュ３８およびローカルエリアネットワーク３９を含み、
　存在点３０にはメディアキャッシュ３８も存在し、メディアキャッシュ３８は、クライアントコンピュータ４２および５２のユーザーにより最も一般に要求されるメディアファイルを存在させ、
　メディアファイルがクライアント４２、５２に入手される時の速度を最高にするために、最初のアイドルステート（待機状態）１００から、最初の３つのステップが起き、
　特にステート１０２においては、ユーザーはＷｅｂページの中でｈｙｐｅｒｔｅｘｔリンクをクリックし、または該当のＭＲＦファイルのためのＵＲＬを直接ブラウザ５４に送ることにより、ブラウザ５４において特定してストリーミングメディアファイルに対する（を求める）要求を行い、
　次のステート１０４において、ブラウザプログラムは、Ｗｅｂサーバー１２にＭＲＦファイルを送るよう要求し、次に、ステート１０６において、Ｗｅｂサーバー１２は、インターネット２０を通してＭＲＦファイルをクライアント４２、５２の方向に返送し、
　ステート１０８において、リンク３４およびキャッシュ転送器３６は、クライアント４２、５２にインターネット２０を通して向かう途上のＭＲＦファイルを認識し、捕らえ、ステート１１０においては、ＭＲＦファイルにより参照されるストリーミングファイルが端末メディアキャッシュ３８で入手できるか否かを、キャッシュ転送器３６が確かめ、
　入手できる場合には、処理はステート１１４に進み、入手できない場合には、処理はステート１１２に進み、転送器３６は、変更されたＭＲＦ要求をメディアサーバー１４に送り、メディアファイルが代わりにメディアキャッシュ３８に送られるように要求し、
　いずれにしろ処理はステート１１４にまで続き、ここで転送器３６は、ＭＲＦファイルをユーザー５２、４２に送る前に、ＭＲＦファイルの中の＜ｈｒｅｆ＞リファレンスを変更し、転送器３６によるこの変更では、メディアキャッシュ３８のＵＲＬをＭＲＦファイルに挿入し、それによって要求はメディアサーバー１４の代わりにメディアキャッシュ３８によりサービスされ、
  ステート１１６においては、ブラウザはメディアプレーヤープログラム５６を開き、ステート１１８においては、メディアプレーヤー５６は情報ストリームをメディアキャッシュ３８から入手し、
　キャッシュ転送器３６は、メディアキャッシュ３８の中に蓄積されているものをコントロールするための責任を実際に負うことができ、
  キャッシュ転送器３６は、トラフィックを監視し、ＭＲＦファイルを捕らえ、必要に応じてメディアキャッシュ３８へＭＲＦファイルのルートを変更する小型のサーバーとして用いられ、メディアキャッシュには、例えばＭｉｃｒｏｓｏｆｔから入手できるＭｅｄｉａ  Ｓｅｒｖｅｒ、またはＲｅａｌＮｅｔｗｏｒｋｓから入手できるＲｅａｌ  Ｖｉｄｅｏ  Ｓｅｒｖｅｒとして知られている一種のコンピューティングシステムを用いることができる、
　コンピュータネットワーク。
　
第４．対比・判断 
 　そこで、本願発明と先願発明とを対比する。
　
（ア）．先願発明の「コンピュータネットワーク」は、「多数のコンピュータ」である「サーバー」を含んだ「オリジン位置１０」を有し、「追加のコンピューティングおよびコミュニケーション機器」が存する「ネットワークの中のある存在位置（ＰＯＰｓ）」において、クライアントの存する「ユーザサイト４０」への「インターネット２０」を介しての接続を行い、マルチメディアドキュメントデータ（ストリーミングメディアファイル）をサーバからクライアントに提供していることから、本願発明の「分散型データ送達ネットワーク」に相当する。
　
（イ）．先願発明の「ストリーミングメディアファイル」、「ＭＲＦファイルを送るように要求」及び「ＭＲＦファイル」は、本願発明の「データ」、「データリクエスト」及び「データ応答」に各々相当する。そして、先願発明の「ステート１０２」において、「ユーザー」は、「ストリーミングメディアファイルに対する（を求める）要求を行い」、「ステート１０４」において、「ブラウザプログラムは、Ｗｅｂサーバー１２にＭＲＦファイルを送るよう要求」することは、本願発明の「ユーザ」が「データ」を「リクエスト」することに相当する。
　　
（ウ）．先願発明の「オリジン位置１０」にともにある「Ｗｅｂサーバー１２およびメディアサーバー１４」は、「ストリーミングオーディオまたはストリーミングビデオファイルのようなマルチメディアドキュメントを含」み、「インターネット２０を通してＭＲＦファイルをクライアント４２、５２の方向に返送」することから、本願発明の「データサーバ」に相当し、先願発明の「メディアキャッシュ３８」は、「要求はメディアサーバー１４の代わりにメディアキャッシュ３８によりサービス」することから、本願発明の「代替データサーバ」に相当する。
　
（エ）．先願発明の「リンク３４およびキャッシュ転送器３６」は、「Ｗｅｂサーバー１２」からの「クライアント４２、５２の方向に返送」された「ＭＲＦファイル」を、「ステート１０８において」「認識し、捕らえ」、次の「ステート１１０」において、「ＭＲＦファイルにより参照されるストリーミングファイルが端末メディアキャッシュ３８で入手できるか否かを、キャッシュ転送器３６が確かめ」、そして、「ステート１１４」で、「転送器３６は、ＭＲＦファイルをユーザー５２、４２に送る前に、ＭＲＦファイルの中の＜ｈｒｅｆ＞リファレンスを変更し、転送器３６によるこの変更では、メディアキャッシュ３８のＵＲＬをＭＲＦファイルに挿入」するものであり、「それによって、要求はメディアサーバー１４の代わりにメディアキャッシュ３８によりサービスされ」ることから、先願発明の「リンク３４およびキャッシュ転送器３６」は、本願発明の「データ応答変更器」に相当し、そして、「データ応答変更器は、該ネットワーク内のデータサーバによって発せられたデータ応答を傍受および変更するように適合されており、該データサーバは、該ユーザーからの該データリクエストに応答し、該データ応答変更器は、変更されたデータ応答を、該リクエストされたデータが該ユーザに届く前に生成し、該変更されたデータ応答は、該ネットワーク内の代替データサーバからの該リクエストされたデータの送達をアクティベートし、該リクエストされたデータは、該代替データサーバから該ユーザへの送達を介して変更されないままであ」るとの構成を備えるものである。
　
（オ）．先願発明では「ユーザー５２、４２に送る前」に、変更された「ＭＲＦファイル」によって、「要求はメディアサーバー１４の代わりにメディアキャッシュ３８によりサービスされ」ており、そして、「メディアキャッシュ３８」からのデータが送られる「存在点３０」における「コンピューティングおよびコミュニケーション機器」としての「ルータ３２」、「リンク３４」、「ローカルエリアネットワーク３９」は、「メディアキャッシュ３８」（本願発明の「代替データサーバ」に相当する。）からユーザへデータをサービスするためにルーティングを制御していることは明らかであることから、先願発明も、本願発明の「該変更されたデータ応答に基づいて、該分散型データ送達ネットワーク内の該代替データサーバから該ユーザへの該リクエストされたデータのルーティングを制御する」データ送達機器（デバイス）を備えているといえる。
 　　　　　　　　　　　 
 　よって、先願発明は、本願発明の構成である以下の構成をすべて含むものである。
 　　　　　　　　　　 
〈一致点〉
分散型データ送達ネットワークからデータをリクエストするユーザからのデータリクエストに対する応答を処理するシステムであって、
　該システムは、
　データ応答変更器と、
　データ送達デバイスと
　を備えており、
　該データ応答変更器は、該ネットワーク内のデータサーバによって発せられたデータ応答を傍受および変更するように適合されており、該データサーバは、該ユーザーからの該データリクエストに応答し、該データ応答変更器は、変更されたデータ応答を、該リクエストされたデータが該ユーザに届く前に生成し、該変更されたデータ応答は、該ネットワーク内の代替データサーバからの該リクエストされたデータの送達をアクティベートし、該リクエストされたデータは、該代替データサーバから該ユーザへの送達を介して変更されないままであり、
　該データ送達デバイスは、該変更されたデータ応答に基づいて、該分散型データ送達ネットワーク内の該代替データサーバから該ユーザへの該リクエストされたデータのルーティングを制御するように適合されている、システム。
  　　　　　　　　　　 
　
　よって、本願発明と先願発明との間に差異はなく、両者は同一の発明である。
　
第５．むすび
　したがって、本願発明は、先願明細書に記載された発明と同一であり、しかも、本願発明の発明者が上記先願明細書に記載された発明の発明者と同一であるとも、また、本願の出願時に、その出願人が上記他の出願の出願人と同一であるとも認められないので、本願発明は、特許法第２９条の２第１項の規定により特許を受けることができない。　
 よって、結論のとおり審決する 。