【事件の表示】
　特願２００４−５５３５６０「トランスコード可能なキャッシングプロキシおよびその方法」拒絶査定不服審判事件〔平成１６年　６月　３日国際公開、ＷＯ２００４／０４６９６８、平成１８年　２月２３日国内公表、特表２００６−５０６７３８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００３年１１月７日（優先日：２００２年１１月１９日（ＵＳ））を国際出願日とする出願であって、平成２２年１月２９日付け拒絶査定に対して、同年５月２５日に拒絶査定不服審判が請求され、当審における平成２３年１２月２日付け拒絶理由通知に対して、平成２４年２月２８日に意見書とともに手続補正書が提出されたものである。
　
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２４年２月２８日に提出された手続補正書の特許請求の範囲の請求項１に記載された次のとおりのものと認める。
「コンテンツを配信する方法（４００）であって、
　キャッシングプロキシにおいて、コンテンツソースからコンテンツオブジェクトの第１のバージョンを受信することと（３４０）、
　前記キャッシングプロキシにおいて前記第１のバージョンをトランスコードし、前記コンテンツオブジェクトの第２のバージョンを作成することと（３５０）、
　複数の前記バージョンへのクライアント装置からのアクセスの局時性が低い場合は、前記第１のバージョンのみをキャッシュする第１のキャッシング方法を選択し、複数の前記バージョンへのクライアント装置からのアクセスの局時性が高い場合は、前記第１のバージョン及び前記第２のバージョンの両方をキャッシュする第２のキャッシング方法を選択することと、
　前記選択された第１のキャッシング方法又は第２のキャッシング方法に従って、前記キャッシングプロキシにおいて前記第１のバージョンおよび前記第２のバージョンの少なくとも一方をキャッシュすることと
　を含む方法。」
　
　
３．引用例
　当審における平成２３年１２月２日付け拒絶理由通知に引用された「Xueyan Tang, Fan Zhang, and Samuel T. Chanson, Streaming Media Caching Algorithms for Transcoding Proxies, 2002 International Conference on Parallel Processing (ICPP'02), pp287-295」（２００２年８月発行（カナダ）。以下、「引用例」という。）には、図面とともに次の記載がある（下線は当審において付与。）。
　
イ．「Providing transcoding service at the proxies has introduced new challenges on proxy caching. The transcoding process is typically computation intensive. With transcoding, considerable amount of CPU resource at the proxy is required to complete a request. Thus, in addition to the objective of reducing network traffic addressed by existing caching schemes [10, 11], the potential bottleneck of proxy CPU needs to be considered as well. An effective caching scheme for transcoding proxies should deal with network and CPU demands in an integrated fashion. So far, to the best of our knowledge, there has been no related study on caching algorithms for transcoding proxies that take multiple resources into account to improve streaming media delivery.」（第１頁右欄第１９−３０行）
（当審訳：プロキシにおいて、トランスコーディングサービスを提供することは、プロキシのキャッシングに関して、新しい挑戦を導入した。トランスコーディング手順は、通常は、かなりの計算量を必要とする。トランスコーディングのために、プロキシにおいて、かなりの量のＣＰＵリソースは、リクエストを完遂するために必要とされる。それ故、従来のキャッシングスキーム［１０，１１］によって取り組まれたネットワークトラフィックの削減の目的に加えて、同様に、プロキシＣＰＵの潜在的なボトルネックが考慮される必要がある。トランスコーディングプロキシのための効率的なキャッシングスキームは、ネットワークとＣＰＵの要求を統合的に扱うべきである。いままでのところ、われわれが知る限りにおいて、ストリーミングメディア配信を改善するために、多数のリソースを考慮に入れているトランスコーディングプロキシのためのキャッシングアルゴリズムに関連する研究は存在しない。）
　
ロ．「Multiple versions of the same object are candidates for caching in transcoding proxies. In this paper, we study and compare the performance of a variety of algorithms that keep different object versions in the cache. The focus of our study is the impact on resource demands. In particular, a new adaptive caching algorithm is proposed. The algorithm determines which object versions to cache based on current network and CPU loadings. Our experimental results show that the adaptive algorithm significantly outperforms those algorithms that cache only untranscoded or only transcoded object versions.」（第１頁右欄第３１−４０行）
（当審訳：同一のオブジェクトの複数のバージョンはトランスコーディングプロキシにおいてキャッシュするための候補である。この論文において、異なるオブジェクトバージョンをキャッシュするさまざまなアルゴリズムのパフォーマンスを研究し比較する。われわれの研究の中心は、リソース要求に対する影響である。とくに、新しい適応キャッシングアルゴリズムが提案される。このアルゴリズムは、現在のネットワーク及びＣＰＵ負荷に基づいてどのオブジェクトバージョンをキャッシュするかを決定する。適応アルゴリズムが、トランスコードされていないオブジェクトだけをキャッシュするアルゴリズムや、トランスコードされているオブジェクトだけをキャッシュするアルゴリズムよりも、はるかに優れていることを、我々の実験結果は示している。）
　
ハ．「2 System Architecture
 As shown in Figure 1, we consider a media streaming architecture consisting of content servers, transcoding proxies and various types of client devices.
 Prerecorded media objects such as audio and video are stored and serviced by the content servers. These objects are referred to as full object versions. If the resources required to play a full object version exceed those available at a client, the full object version will have to be transcoded to a version with lower quality (e.g., in terms of display resolution and color depth) to meet the client's capabilities. The transcoding proxy is generally located close to its clients and connected to the content servers via the Internet. The transmission capacity from the content servers to the proxy is modeled by a logical bottleneck link with bandwidth B. For the purpose of this study, we assume B is fixed and known. A variety of client devices can connect to the proxy through different types of networks such as Ethernet, telephone modem and wireless network. To cater for different client capabilities, a full object version may have multiple transcoded versions, one for each class of clients. However, for simplicity, we shall assume a transcoded version can only be produced from the full version. The transcoding capability of the proxy is characterized by its CPU power C. Note that the transcoding proxy in our architecture is considered a logical entity. It could consist of multiple physical entities responsible for different tasks [12].」（第２頁左欄第１１−３５行）
（当審訳：２　システムアーキテクチャ
　図１で示されるように、
コンテンツサーバと、トランスコーディングプロキシと様々なタイプのクライアントデバイスから構成されるメディアストリーミングアーキテクチャ
　
あらかじめ記録された、音声や映像のようなメディアオブジェクトは、コンテンツサーバによって蓄積され、提供される。これらのオブジェクトはフルオブジェクトバージョンと呼ぶことにする。もし、フルオブジェクトバージョンを享受するのに必要なリソースが、クライアントにおいて利用可能なリソースを超えていたならば、フルオブジェクトバージョンは、より低品質（たとえば、ディスプレイ解像度や色深度に関して）のバージョンにトランスコードされなければならないだろう。トランスコーディングプロキシは一般的には複数のクライアントの近くに配置され、インターネットを経由してコンテンツサーバに接続されている。
　
ニ．「The request handling procedure proceeds as follows. A user's request for a media object is directed to the proxy. The request in our architecture contains two parts: the name of the media object and the capability of the client device (e.g., specified in the form of User Agent Profile recommended by WAP [13]). Upon receiving the request, the proxy searches its cache for the appropriate object version. One of the following situations can occur:
 Version Hit: If the requested object version matching the client's capability is cached, it is sent to the client directly;
 Content Hit: If the proxy does not have the requested object version but has the corresponding full version, transcoding is necessary. The proxy determines the CPU resource (in terms of the proportion of CPU power) required. If there is sufficient CPU power available, the proxy starts transcoding and sends the output stream to the client. The required CPU power is reserved throughout the streaming session. On the other hand, if there is not sufficient CPU power available, the user request is blocked.
 Cache Miss: If neither the requested object version nor the full version is in the cache, the full version has to be retrieved from the content server. The proxy determines the bandwidth requirement to fetch the full object version and compares it with the available bandwidth on the bottleneck link. If the available bandwidth is inadequate, the request is blocked. On the other hand, if bandwidth is available, the proxy checks to see whether transcoding is necessary. If transcoding is not needed, the request is accepted and the required link bandwidth is reserved over the lifetime of the stream. Otherwise, the full version has to be transcoded. The decision to accept the request in this case depends on the CPU resource checking process discussed in the situation of content hit. If the request is accepted, the required link bandwidth and CPU power are both reserved for the entire streaming session.
 To summarize, depending on the requested object version and the cache status, zero, one or two types of resources may be needed to complete a user request. Table 1 lists the resource demands in the different cases, where the network resource refers to that between the content servers and the proxy. The user request is accepted if all required resources are available. Otherwise, the request is blocked.」（第２頁左欄第３６行−同頁右欄第２９行）
（当審訳：リクエスト取扱手順はつぎのように開始される。ユーザのメディアオブジェクトに対するリクエストは、プロキシに向けられる。我々のアーキテクチャにおけるリクエストは、２つのパートを含んでいる。メディアオブジェクトの名前とクライアントの能力である（たとえば、ＷＡＰ［１３］によって推奨されたユーザエージェントプロファイルの形式で特徴付けられている）。リクエストを受け取ると、プロキシは、そのキャッシュから適切なオブジェクトバージョンを探す。つぎの状況の一つが起きる可能性がある。
 ・バージョンヒット：もし、クライアントの能力にマッチしているリクエストされたオブジェクトバージョンがキャッシュされているならば、クライアントに直接送信される。
 ・コンテンツヒット：もしプロキシがリクエストされたオブジェクトバージョンを有しておらず、関連するフルバージョンを有しているならば、トランスコーディングが必要となる。プロキシは、（ＣＰＵパワーの割合に関して）必要とされるＣＰＵリソースを決定する。十分なＣＰＵパワーが利用可能であれば、プロキシはトランスコードを開始し、クライアントに出力ストリームを送信する。必要とされるＣＰＵパワーはストリーミングセッションの間中、予約されることになる。一方で、十分なＣＰＵパワーが利用できない場合は、ユーザのリクエストはブロックされる。
 ・キャッシュミス：リクエストされたオブジェクトバージョンもフルバージョンもキャッシュに存在しない場合は、コンテンツサーバからフルバージョンが取得されなければならない。プロキシは、フルオブジェクトバージョンを取得するのに必要な帯域幅を決定し、それをボトルネックリンクに関して利用可能な帯域幅と比較する。利用可能な帯域幅が不適切であるときは、リクエストはブロックされる。一方で、帯域幅が利用可能である場合、プロキシはトランスコーディングが必要であるか否かをチェックする。もし、トランスコーディングが必要とされなければ、そのリクエストは受け入れられ、必要とされるリンク帯域幅はストリームの寿命の間予約されることになる。さもなければ、フルバージョンはトランスコードされる。このケースにおいて、リクエストを受け付けるか否かの決定は、コンテンツヒットのところで議論された、ＣＰＵリソースをチェックする手順に依存する。もしリクエストが受け入れられるならば、必要とされるリンク帯域幅及びＣＰＵパワーは、いずれもストリーミングセッションの間中予約されることになる。
 　要約すると、リクエストされたオブジェクトバージョン及びキャッシュの状況に応じて、０、１つ又は２つの種類のリソースが、ユーザのリクエストを達成するために必要とされるかもしれない。表１は、異なるケースにおけるリソース要求を示している。ここで、ネットワークリソースは、コンテンツサーバとプロキシの間のネットワークリソースのことをいう。すべての必要とされたリソースが利用可能であるときに、ユーザリクエストは受け入れられる。さもなければ、リクエストはブロックされる。）
　
ホ．「Table 1. Summary of Resource Requirements（表１．リソース要求のまとめ）」（第２頁右欄）には、キャッシュされたバージョンが、フルオブジェクトバージョン及びトランスコードされたオブジェクトバージョンである場合、トランスコードされたオブジェクトバージョンである場合、フルオブジェクトバージョンである場合、いずれでもない場合の４つの場合が示されており、とくに、キャッシュされたバージョンが、フルオブジェクトバージョン及びトランスコードされたオブジェクトバージョンであるときには、いずれのバージョンがリクエストされたとしても、ユーザリクエストの達成のために、なんらリソースを必要としないことが開示されている。
　
へ．「3.3 Adaptive Caching Algorithm
 Both the FVO and TVO algorithms have advantages and drawbacks. FVO tries to reduce network demand by caching full object versions. However, it puts much more CPU demand on the transcoding proxy as a transcoded object version needs to be produced on-the-fly every time it is requested. On the other hand, TVO reduces computation demand by caching the transcoded object versions. The drawback is that multiple versions of the same objects may have to be cached, resulting in possibly higher cache miss ratio.
 To minimize the overall blocking probability, we propose an adaptive caching algorithm that considers network and CPU resources in an integrated fashion. Notice that a user request may result in one of three actions: (1) request is blocked by the bottleneck link (network block); (2) request can be accommodated by the bottleneck link but is blocked by the proxy's CPU (CPU block); and (3) request is accepted. The fractions of requests resulting in network blocks and CPU blocks are referred to as the network blocking probability pn and the CPU blocking probability pc respectively. The overall blocking probability is the sum of these two probabilities. Let p = pc / (pn+pc) be the relative CPU blocking ratio. A value of p close to 1 implies that CPU capacity rather than network bandwidth is the limiting resource. On the other hand, a value of p close to 0 indicates that network bandwidth is the limiting resource. Our design guideline is to cache appropriate object versions to reduce the burden on the potential bottleneck at the time of caching decision, be it network bandwidth or CPU capacity. Our objective is to minimize the overall request blocking probability.」（第３頁右欄第３５行−第４頁左欄第１０行）
 （当審訳：３．３　適応キャッシングアルゴリズム
　ＦＶＯアルゴリズムにもＴＶＯアルゴリズムにも利点や欠点がある。ＦＶＯは、フルバージョンをキャッシュすることによって、ネットワーク要求を削減するよう試みる。しかしながら、トランスコードされたオブジェクトバージョンは、それがリクエストされる度に、その場で生成される必要があるので、トランスコーディングプロキシにおけるＣＰＵ要求はかなりのものになる。一方で、ＴＶＯはトランスコードされたオブジェクトバージョンをキャッシュすることによって、計算要求を削減する。その欠点は、同一のオブジェクトの複数のバージョンがキャッシュされなければならないことであり、場合によっては、より高いキャッシュミス比率が結果として生ずる。ブロッキング確率全体を最小化するため、ネットワークとＣＰＵリソースとを統合的に考慮する適応キャッシングアルゴリズムを提案する。ユーザリクエストは、結果として３つのアクションのうちの１つとなることに注意されたい。（１）リクエストはボトルネックリンクによってブロックされる（ネットワークブロック）。（２）リクエストは、ボトルネックリンクによって許容されるかも知れないが、プロキシのＣＰＵによってブロックされる（ＣＰＵブロック）。（３）リクエストは受け入れられる。結果としてネットワークブロック及びＣＰＵブロックとなるリクエストの一部分を、それぞれ、ネットワークブロッキング確率ｐｎ、ＣＰＵブロッキング確率をｐｃとする。ブロッキング確率の全体は、これら２つの確率の和である。
ｐ＝ｐ
ｃ
／（ｐ
ｎ
＋ｐ
ｃ
）を、相対ＣＰＵブロッキング比率
ｐの値が１に近いことは、ネットワーク帯域幅よりもむしろＣＰＵ能力の方が限界リソースとなっていることを意味している
　
ト．「In our algorithm, the value of p is dynamically estimated based on recent request history. At every accepted request, all accessed object versions are considered for caching. A threshold-based policy is employed to decide which gain density metric should be used for making caching decisions. If p exceeds a given threshold alpha, the CPU gain density is selected. In this way, full object versions are removed from the cache first since they have Dcpu(v) values of 0, and transcoded object versions enter the cache to reduce future CPU demand. On the other hand, if p is below the threshold alpha, the network gain density is selected and full object versions will likely have higher priority to be cached. Having determined the metric, the caching algorithm proceeds similarly to that of TVO or FVO, and is not reproduced here.」（第４頁左欄第１９−３１行）
（当審訳：我々のアルゴリズムにおいて、
ｐの値は最近のリクエスト履歴に基づいて動的に推定される
ｐが与えられたしきい値αを超えるならば
トランスコードされたオブジェクトバーションがキャッシュに入る
ｐがしきい値αを下回るならば
フルオブジェクトバージョンがより高い優先度でキャッシュされるようになる
測定基準を決定すると、キャッシングアルゴリズムは、ＴＶＯまたはＦＶＯのアルゴリズムと同様に開始され
　
　したがって、引用例には、次の発明（以下、「引用発明」という。）が開示されているものと認められる。
「コンテンツサーバと、トランスコーディングプロキシと様々なタイプのクライアントデバイスから構成されるメディアストリーミングアーキテクチャであって、
　あらかじめ記録された、音声や映像のようなメディアオブジェクト（フルオブジェクトバージョン）は、コンテンツサーバによって蓄積され、提供され、
　もし、フルオブジェクトバージョンを享受するのに必要なリソースが、クライアントにおいて利用可能なリソースを超えていたならば、フルオブジェクトバージョンは、より低品質のバージョン（トランスコードされたオブジェクトバージョン）にトランスコードされなければならず、
　トランスコーディングプロキシは一般的には複数のクライアントの近くに配置され、インターネットを経由してコンテンツサーバに接続されており、
　キャッシュされたバージョンは、フルオブジェクトバージョン及びトランスコードされたオブジェクトバージョンである場合、トランスコードされたオブジェクトバージョンである場合、フルオブジェクトバージョンである場合、いずれでもない場合の４つの場合があり、
　最近のリクエスト履歴に基づいて動的に推定される相対ＣＰＵブロッキング比率ｐの値が１に近いことは、ＣＰＵ能力が限界リソースとなっていることを意味しており、
　ｐが与えられたしきい値αを超えるならば、トランスコードされたオブジェクトバーションがキャッシュに入り、
　ｐがしきい値αを下回るならば、フルオブジェクトバージョンがより高い優先度でキャッシュされるようになり、
　測定基準を決定すると、キャッシングアルゴリズムは、ＴＶＯ（トランスコードされたオブジェクトバージョンのみをキャッシュする）またはＦＶＯ（フルオブジェクトバージョンのみをキャッシュする）のアルゴリズムと同様に開始される
　メディアストリーミングアーキテクチャ。」
　
　
４．対比
　本願発明と引用発明とを対比する。
（１）引用発明のメディアストリーミングアーキテクチャにおいて、「コンテンツを配信する方法」が実施されていることは明らかである。
（２）引用発明のトランスコーディングプロキシは、オブジェクトのバージョンをキャッシュしているので、本願発明の「キャッシングプロキシ」に相当する。
（３）引用発明のコンテンツサーバは、メディアオブジェクトを蓄積し、提供しているので、本願発明の「コンテンツソース」に相当する。
（４）引用発明のフルオブジェクトバージョンは、本願発明の「コンテンツオブジェクトの第１のバージョン」に相当する。
（５）引用発明のトランスコードされたオブジェクトバージョンは、本願発明の「コンテンツオブジェクトの第２のバージョン」に相当する。
（６）引用発明のクライアントは、本願発明の「クライアント装置」に相当する。
（７）引用発明では、最近のリクエスト履歴に基づいて動的に推定される相対ＣＰＵブロッキング比率ｐの値が１に近いことは、ＣＰＵ能力が限界リソースとなっていることを意味しており、ｐが与えられたしきい値αを超えるならば、トランスコードされたオブジェクトバーションがキャッシュに入り、ｐがしきい値αを下回るならば、フルオブジェクトバージョンがより高い優先度でキャッシュされるようになっており、測定基準を決定すると、キャッシングアルゴリズムは、ＴＶＯ（トランスコードされたオブジェクトバージョンのみをキャッシュする）またはＦＶＯ（フルオブジェクトバージョンのみをキャッシュする）のアルゴリズムと同様に開始される。
　ここで、リクエストとは、複数のバージョンへのクライアントからのアクセスを意味し、また、相対ＣＰＵブロッキング比率ｐがしきい値αを超えるとは、相対的にトランスコードディングプロキシの処理負荷が高く、相対ＣＰＵブロッキング比率ｐがしきい値αを下回るとは、相対的にトランスコーディングプロキシの処理負荷が低いことを意味することも明らかである。
　一方、本願の発明の詳細な説明の段落【００３９】から、本願発明において、「アクセスの局時性が高い場合」とは、「相対的に短い時間の間に、ある特定のオブジェクトを得るために相対的に多数の要求を受信する場合」を意味し、「アクセスの局時性が低い場合」とは、その逆を意味しているものと考えられる。相対的に短い時間の間に相対的に多数の要求を受信すると、キャッシングプロキシの処理負荷が高くなり、その逆で、キャッシングプロキシの処理負荷が低くなることは明らかである。
　よって、引用発明は、本願発明の「複数の前記バージョンへのクライアント装置からのアクセスの局時性が低い場合は、前記第１のバージョンのみをキャッシュする第１のキャッシング方法を選択し、複数の前記バージョンへのクライアント装置からのアクセスの局時性が高い場合は、前記第１のバージョン及び前記第２のバージョンの両方をキャッシュする第２のキャッシング方法を選択すること」と、複数の前記バージョンへのクライアント装置からのアクセスによる処理負荷が低い場合は、前記第１のバージョンのみをキャッシュする第１のキャッシング方法を選択し、複数の前記バージョンへのクライアント装置からのアクセスによる処理負荷が高い場合は、第２のキャッシング方法を選択することで共通しているといえる。
　さらに、引用発明は、本願発明同様、「前記選択された第１のキャッシング方法又は第２のキャッシング方法に従って、前記キャッシングプロキシにおいて前記第１のバージョンおよび前記第２のバージョンの少なくとも一方をキャッシュすること」という構成を有しているといえる。
　
　したがって、本願発明と引用発明との一致点・相違点は次のとおりである。
＜一致点＞
「コンテンツを配信する方法（４００）であって、
　キャッシングプロキシにおいて、コンテンツソースからコンテンツオブジェクトの第１のバージョンを受信することと（３４０）、
　前記キャッシングプロキシにおいて前記第１のバージョンをトランスコードし、前記コンテンツオブジェクトの第２のバージョンを作成することと（３５０）、
　複数の前記バージョンへのクライアント装置からのアクセスによる処理負荷が低い場合は、前記第１のバージョンのみをキャッシュする第１のキャッシング方法を選択し、複数の前記バージョンへのクライアント装置からのアクセスによる処理負荷が高い場合は、第２のキャッシング方法を選択することと、
　前記選択された第１のキャッシング方法又は第２のキャッシング方法に従って、前記キャッシングプロキシにおいて前記第１のバージョンおよび前記第２のバージョンの少なくとも一方をキャッシュすることと
　を含む方法。」
　
＜相違点１＞
　複数のバージョンへのクライアント装置からのアクセスによる処理負荷が低いか高いかの基準として、本願発明は、アクセスの局時性が低いか高いかを用いているのに対して、引用発明は、最近のリクエスト履歴に基づいて動的に推定される相対ＣＰＵブロッキング比率ｐの値がしきい値を下回るか超えているかを用いている点。
　
＜相違点２＞
　複数の前記バージョンへのクライアント装置からのアクセスによる処理負荷が高い場合に選択される第２のキャッシング方法が、本願発明では、第１のバージョン及び第２のバージョンの両方をキャッシュするのに対して、引用発明は、第２のバージョンのみをキャッシュする点。
　
　
５．当審の判断
・＜相違点１＞について
　処理装置の処理負荷が低いか高いかの基準として、相対的に短い時間の間に相対的にどのくらいの要求を受信するか、すなわちアクセスの局時性を用いることは、コンピュータ分野の当業者にとって周知な技術である。
　したがって、引用発明において、複数のバージョンへのクライアント装置からのアクセスによる処理負荷が低いか高いかの基準として、アクセスの局時性を用いることは、当業者が容易に想到し得ることである。
　
・＜相違点２＞について
　引用例の記載事項ホには、キャッシング方法としては、フルオブジェクトバージョン及びトランスコードされたオブジェクトバージョンをキャッシュする方法、トランスコードされたオブジェクトバージョンのみをキャッシュする方法、フルオブジェクトバージョンのみをキャシュする方法、いずれのバージョンもキャッシュしない方法の４通りが開示されている。また、フルオブジェクトバージョン及びトランスコードされたオブジェクトバージョンの両方をキャッシュすると、いずれのバージョンがリクエストされたとしても、ユーザリクエストの達成のために、なんらリソースを必要としない。このことは、４通りの方法の中で、フルオブジェクトバージョン及びトランスコードされたオブジェクトバージョンの両方をキャッシュする方法が、ユーザリクエストを受理する際、必要となるリソースが不要である点で、最も優れた方法であることを意味している。
　また、クライアント装置からのアクセスの局時性が高い場合において、コンテンツソースとキャッシングプロキシ間のネットワーク負荷が著しく大き
く、かつプロキシに十分な記憶容量が存在する場合に、受信したフルオブジェクトバージョンをキャッシュから排除する必要はなく、むしろトランスコ
ードされたオブジェクトバージョンとともにキャッシュしておいた方が、ユーザリクエストに対するリソースの必要性が低く効率的であることは、当業者が当然認識することである。
　したがって、引用発明において、複数の前記バージョンへのクライアント装置からのアクセスの局時性が高い場合に選択される第２のキャッシング方法として、第１のバージョン及び第２のバージョンの両方をキャッシュするように構成することは、当業者が容易に想到し得ることである。
　
　また、＜相違点１＞及び＜相違点２＞に係る効果も、引用発明から当業者が予測し得る範囲内のものである。
　
　
６．むすび
　以上の検討から、本願発明は、引用発明に基づいて当業者が容易になし得たものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、その余の請求項について論及するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。