【事件の表示】
　特願２００７−１０１７５６「ウェッブページのＨＴＭＬデータを移動局におけるディスプレイに好適なフォーマットに変換する装置及び方法」拒絶査定不服審判事件〔平成１９年１０月　４日出願公開、特開２００７−２５７６４７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成１４年１２月２５日（パリ条約による優先権主張２００１年１２月２７日、米国）に出願した特願２００２−３７５５９６号の一部を平成１９年４月９日に新たな特許出願としたものであって、平成２１年６月３０日付けの拒絶の理由の通知に対して、同年１０月６日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年１０月２６日付けで拒絶をすべき旨の査定がされ、これに対し平成２２年３月４日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　
第２　平成２２年３月４日付けの手続補正についての却下の決定
［結論］
　平成２２年３月４日付けの手続補正を却下する。
［理由］
１　補正後の本願発明
　平成２２年３月４日付けの手続補正（以下「本件補正」という。）により、平成２１年１０月６日付けの手続補正書の特許請求の範囲の請求項８（以下「補正前の請求項８」という。）は、平成２２年３月４日付けの手続補正書の特許請求の範囲の請求項８（以下「補正後の請求項８」という。）に補正された。
　補正前の請求項８及び補正後の請求項８は、以下のとおりである。
　
補正前の請求項８
「ディスプレイを含む予め決定された性能を有する移動局で表示するためにＨＴＭＬデータを新たなフォーマットに変形するネットワークサーバーにおいて、
　ウェッブページのＨＴＭＬデータ、ＨＴＭＬフィルター及び各種のＨＴＭＬ変形スクリプトと共に、予め決定された複数の移動局の性能を貯蔵するメモリと、
　前記メモリに連結され、前記移動局から前記移動局の予め決定された性能を決定するための識別情報が受信されると、前記受信された識別情報を用いて前記移動局の予め決定された性能を検索し、ＨＴＭＬ変形スクリプトと前記検索された予め決定された性能を用いて前記ウェッブページのＨＴＭＬデータから前記移動局の予め決定された性能に応じて変更される新たなフォーマットのＨＴＭＬデータを生成するようにＨＴＭＬフィルターを実行させ、前記移動局のディスプレイ上で表示するために新たなフォーマットのＨＴＭＬデータを前記移動局へ伝送できるデータプロセッサとを備えることを特徴とするネットワークサーバー。」
　
補正後の請求項８
「ディスプレイを含む予め決定された性能を有する移動局で表示するためにＨＴＭＬデータを新たなフォーマットに変形するネットワークサーバーにおいて、
　ウェッブページのＨＴＭＬデータ、ＨＴＭＬフィルター及び各種のＨＴＭＬ変形スクリプトと共に、予め決定された複数の移動局の性能を貯蔵するメモリと、
　前記メモリに連結され、前記移動局から前記移動局の予め決定された性能を決定するための識別情報が受信されると、前記受信された識別情報を用いて
前記メモリから
前記識別情報を伝送した
前記識別情報を伝送した
　
　本件補正は、補正前の請求項８に記載した発明を特定するために必要な事項である「前記移動局の予め決定された性能を検索し」及び「前記移動局」に、それぞれ「
前記メモリから
前記識別情報を伝送した
　そこで、補正後の請求項８に記載された発明（以下「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法１７条の２第５項において準用する同法１２６条５項の規定に適合するか）について以下に検討する。
　
２　引用例の記載
（１）引用例１
　原査定の拒絶の理由に引用されたJ.C. Mogul、Server-directed transcoding、Computer Communications、Elsevier Science Publishers BV、２００１年２月１日、Vol.24、No.2、pp.155〜162（以下「引用例１」という。）には、次の事項が図面とともに記載されている。
　
ア　「1. Introduction
  Web site designers love to provide complex, detailed content, rich with multimedia experiences. Alas, this content often encounters technical limitations between the origin server and the ultimate user: networks might be too slow or expensive, screens might be too small, clients might be underpowered, or the necessary rendering software might be unavailable.
  One can cope with this mismatch between content and capabilities by transcoding the original representation to a more appropriate representation. Images can be reduced in size or converted to monochrome; text files can be abstracted; video formats can be converted. When used correctly, transcoding (sometimes called distillation) can provide the user with the most essential information of the original content, without straining the limits of feasibility.」（１５５頁左欄１〜１６行。仮訳（当審作成。以下同様。）：「１．導入
　ウェブサイトのデザイナーは、複雑で詳細でマルチメディア経験に富んだコンテンツを提供することを好む。悲しいことに、このコンテンツは、オリジナルのサーバと最終的なユーザとの間の技術的な制限にしばしば遭遇する：ネットワークが遅すぎたり、又は高価であること、スクリーンが小さすぎること、クライアントが力不足であること、並びに必要なレンダリングソフトウェアが利用不可能なこと。
　オリジナルの表現からもっと適切な表現へトランスコードすることにより、コンテンツと能力のミスマッチに対応することができる。イメージは、サイズを縮小し、又はモノクロに変換でき；テキストファイルは、要約化することができ；ビデオフォーマットは、変更することができる。正しく使用した場合、トランスコーディング（ときどき、蒸留という。）は、実行可能性の制限をすることなく、オリジナルのコンテンツの不可欠な情報をユーザに提供できる。」）
　
イ　「In the Web, transcoding may be done at an intermediate proxy server, or at the ultimate client application.」（１５５頁左欄下から２〜１行。仮訳：「ウェブでは、トランスコーディングは、中間のプロキシサーバ又は最終的なクライアントアプリケーションで行われる。」）
　
ウ　「This paper proposes a new approach to transcoding, called server-directed transcoding. In this approach, the origin server provides explicit guidance to the transcoding system (proxy or client) about whether and how to convert between representations.」（１５５頁右欄１１〜１５行。仮訳：「この論文は、サーバ指示トランスコーディングと呼ぶトランスコーディングの新しいアプローチを提案する。このアプローチにおいて、オリジナルのサーバは、トランスコーディングシステム（プロキシ又はクライアント）へ、表現間の変換を行うのか、及びどのような変換を行うのかについての明白なガイダンスを提供する。」）
　
エ　「The use of applets to dynamically customize the operation of a proxy or client is similar in concept to active networks.」（１５６頁右欄２０〜２２行。仮訳：「プロキシ又はクライアントの動作を直接カスタマイズするアプレットの使用は、「アクティブネットワーク」の概念に類似する。」）
　
オ　「5. Transcoding applets
  A far more powerful approach would be to use transcoding applets: set-specific transcoding programs that are downloaded by the transcoding system. In this approach, the transcoding system provides a virtual machine (such as Java or Tcl) for executing a transcoding applet (mobile code) specified by the origin server; this makes the transcoding system fully extensible.」（１５９頁左欄２５〜３２行。仮訳：「５．トランスコーディングアプレット
　さらなる力強いアプローチは、トランスコーディングアプレットを使用することである：トランスコーディングアプレットは、トランスコーディングシステムによってダウンロードされるセット仕様のトランスコーディングプログラムである。このアプローチでは、トランスコーディングシステムは、オリジナルのサーバによって特定されるトランスコーディングアプレット（「モバイルコード」）を実行するための（Java又はTclのような）仮想マシンを提供する；これは、トランスコーディングシステムを完全に拡張可能にする。」）
　
カ　「The origin server cannot know, in advance, the capabilities of every client that might receive a cached response from a transcoding proxy, so the proxy must combine some information (from the origin server) about the range of possible transformations with information (for each specific client request) about the capabilities and preferences of that client and the intervening network path. The proxy may also use information about the availability of resources (CPU, RAM, etc.) to the transcoding system. With all this information, the proxy can then decide what transformations to apply, if any.
  More concretely, the server might supply a set of algorithms rather than a specific conversion. For example, if the server generates a GIF response, it could provide an applet that knows how to convert GIF responses to any one of a set of formats (JPEG, PNG, smaller GIFs). The proxy can select the best transformation, depending on the capabilities of the client and the availability of resources.」（１５９頁右欄下から２７〜１０行。仮訳：「オリジナルのサーバは、前もって、トランスコードするプロキシからのキャッシュされたレスポンスを受け取るすべてのクライアントの能力を知ることができないから、プロキシは、（オリジナルのサーバからの）可能な変換の範囲に関するいくらかの情報と特定のクライアントとその間のネットワークパスの能力と嗜好に関する（特定のクライアントの要求それぞれのための）情報を組み合わさなければならない。また、プロキシは、トランスコーディングシステムの（CPU又はRAMなどの）資源の利用可能性に関する情報を使用するかもしれない。それから、この情報すべてを用いて、プロキシは、何の変換を適用すべきか、必要があれば、決定することができる。
　さらに具体的には、サーバは、特定の変換よりもむしろ、アルゴリズムのセットを供給するかもしれない。例えば、サーバがＧＩＦのレスポンスを発生した場合、サーバは、ＧＩＦのレスポンスをフォーマットのセット（ＪＰＥＧ、ＰＮＧ、もっと小さいＧＩＦ）のいずれかに変換する方法を知っているアプレットを提供することができる。プロキシは、クライアントの能力と資源の利用可能性に基づいて、最善の変換を選択することができる。」）
　
キ　「5.2. Transcoding applets by reference
  The server can specify the transcoding applet specific to a response by reference; for example,   Transcode-Info: app=
  http://applets.compaq.com/app37.cls
  If the transcoding system wants to use this applet, it downloads the specified URL. This potentially adds an extra round-trip to the server. Of course, if the applets are sufficiently general, they can be profitably cached by the transcoding system.」（１６０頁左欄３〜１２行。仮訳：「５．２．参照によるトランスコーディングアプレット
　サーバは、参照によって、レスポンスについての特定のトランスコーディングアプレットを特定することができる；例えば、
  Transcode-Info: app=
  http://applets.compaq.com/app37.cls
　トランスコーディングシステムがこのアプレットを使用したい場合、トランスコーディングシステムは、その特定のＵＲＬをダウンロードする。これは、潜在的に、サーバへの更なる１往復を加える。もちろん、アプレットが十分に一般的な場合、アプレットはトランスコーディングシステムにより有益にキャッシュされることができる。」）
　
ク　「All of the applet's methods could take as input not only the content itself, but also attributes of the recipient, such as the available bandwidth and the capabilities of the client. (These capabilities could be expressed using feature sets [12], or derived from the HTTP User-agent and/or Accept headers.)」（１６０頁左欄下から９〜４行。仮訳：「アプレットの手法のすべては、コンテンツそれ自身だけでなく、利用可能な帯域幅とクライアントの能力などの受信者の属性も入力として受け取る。（これらの能力は、［１２］の文献の「特徴セット」を用いて表現されることができ、また、ＨＴＴＰのUser-agentヘッダ及び／又はAcceptヘッダから抽出されることができる。）」）
　
ケ　「5.6. Other benefits of transcoding applets
  Although transcoding is normally thought of as a lossy mechanism, whose goal is to reduce bandwidth requirements, display requirements, etc., it can also be used as an extensibility mechanism. Server-directed transcoding allows a server to introduce a new media format without requiring any further revisions to clients or proxies. For example, if the clients only implement MP3 format for audio clips, but the server has content in AIFF format, it could (in theory) let transcoding proxies do the conversion on demand, by specifying an applet that can do this conversion. If the client's Accept request header specifies several potential target content-types, the transcoding applet can choose the most appropriate format from that list.」（１６０頁右欄下から２３〜１０行。仮訳：「５．６．トランスコーディングアプレットのその他の利点
　トランスコーディングは、通常、帯域幅の要件やディスプレイの要件などを減少させる目的を持つ、データの劣化を伴うメカニズムの考え方であるが、拡張可能なメカニズムとして使用することもできる。サーバ指示のトランスコーディングは、サーバに、クライアントやプロキシへの更なる修正を要求することなく、新しいメディアフォーマットを導入させる。例えば、クライアントが、オーディオクリップに対するＭＰ３フォーマットのみ実行するのに対し、サーバはＡＩＦＦフォーマットのコンテンツを持っている場合、（理論的に）それは、この変換をすることができるアプレットを特定することにより、トランスコードするプロキシにオンデマンドでその変換をさせることができる。クライアントのAcceptヘッダがいくつかの潜在的なターゲットのコンテンツタイプを特定した場合、トランスコーディングアプレットは、そのリストから最も適切なフォーマットを選択することができる。」）
　
コ　「5.7. Caching of transcoded results
  It would clearly be beneficial to allow caching of transcoding results, to the extent that caching is allowed for the untransformed response」（１６１頁左欄１〜４行。仮訳：「５．７．トランスコードされた結果のキャッシュを行うこと
　トランスコードされた結果のキャッシュを行うことは、変換されていないレスポンスに対するキャッシュを行う限りにおいて、有益である。」）
　
サ　「Server-directed transcoding applets provide a completely extensible mechanism for proxy-based or client-based transcoding, freeing the use of transcoding from the drag of standardization processes. While some initial standardization of applet methods would be required, the requirements for a transcoding standard are fairly simple. The mechanism is a compatible extension to HTTP, and no other layers need modification.」（１６２頁左欄２４〜３０行。仮訳：「サーバ指示のトランスコーディングアプレットは、標準化プロセスの障害からトランスコーディングの使用をフリーにする、プロキシベース又はクライアントベースのトランスコーディングに対する完全に拡張可能なメカニズムを提供する。アプレット手法のいくつかの初期の標準化が要求される一方、トランスコーディングの標準に対する要件は、とても簡単なものである。そのメカニズムは、ＨＴＴＰと互換可能な拡張であり、その他のレイヤーは変更を必要としない。」）
　
　以上の記載によれば、引用例１には、次の発明（以下「引用発明」という。）が記載されている。
　
「複雑で詳細でマルチメディア経験に富んだウェブサイトのコンテンツは、スクリーンが小さすぎることなど、オリジナルのサーバと最終的なユーザとの間の技術的な制限にしばしば遭遇し、
　イメージはサイズを縮小することなど、オリジナルの表現からもっと適切な表現へトランスコードすることにより、コンテンツと能力のミスマッチに対応することができ、
　ウェブでは、トランスコーディングは、中間のプロキシサーバで行われ、
　オリジナルのサーバは、トランスコーディングシステム（プロキシサーバ）へ明白なガイダンスを提供し、
　トランスコーディングシステムは、オリジナルのサーバによって特定されるトランスコーディングアプレットを実行するための仮想マシンを提供し、
　トランスコーディングアプレットは、トランスコーディングシステムによってダウンロードされるセット仕様のトランスコーディングプログラムであり、
　オリジナルのサーバがＧＩＦのレスポンスを発生した場合、オリジナルのサーバは、ＧＩＦのレスポンスをフォーマットのセット（ＪＰＥＧ、ＰＮＧ、もっと小さいＧＩＦ）のいずれかに変換する方法を知っているトランスコーディングアプレットを提供し、プロキシサーバは、クライアントの能力に基づいて、最善の変換を選択し、
　トランスコーディングアプレットは、トランスコーディングシステムによりキャッシュされ、
　クライアントの能力は、ＨＴＴＰのUser-agentヘッダ及び／又はAcceptヘッダから抽出され、
　プロキシサーバは、変換されていないレスポンスに対するキャッシュを行う
　プロキシサーバ。」
　
（２）引用例２
　原査定の拒絶の理由に引用された特開２０００−６６８６８号公報（平成１２年３月３日出願公開。以下「引用例２」という。）には、次の事項が図面とともに記載されている。
　
シ　「【０００１】
【発明の属する技術分野】本発明は、表示データを編成するためのシステムおよび方法に関し、より具体的には、その上およびその中で表示データ、たとえば、ホーム・ページまたはウェブ・ページが表示されるディスプレイ画面およびウィンドウ上でウェブ・サイトに関連する表示データを編成するためのシステムおよび方法に関する。」（段落【０００１】）
　
ス　「【０００５】
【発明が解決しようとする課題】本発明の目的は、その上およびその中でウェブ・ページが表示されるディスプレイおよびウィンドウ向けにウェブ・サイトに関連する表示データを編成することである。たとえば、標準的なＰＣモニタ、ラップトップ画面、パームトップから、ウェブフォンおよびディジタル・カメラのディスプレイや、ウェブ・ブラウズが可能なディスプレイを備えた装置まで、また、大きいウィンドウから小さいウィンドウに至る、このような視覚装置のために異なる表示アクセス戦略を提供する。しかし、本発明の教示が前述のタイプのディスプレイを備えた実施態様に限定されず、当業者が他の形式のディスプレイでの使用を企図していることを理解されたい。」（段落【０００５】）
　
セ　「【００１１】
【発明の実施の形態】まず、図１を参照すると、本発明によるディスプレイ画面およびウィンドウ・サイズ関連ウェブ・ページ適応システムの構成要素を示す図が示されている。図１では、このディスプレイ画面およびウィンドウ・サイズ関連ウェブ・ページ適応システムの基本構成要素をワールド・ワイド・ウェブ（ＷＷＷ）の他の構成要素に関して示す。ＷＷＷに関連して本発明を図示し説明するが、本発明は、インターネットを含む他の同様のネットワークまたは関連ネットワーク（たとえば、ｆｔｐ）あるいはその両方で実施することができる。ブロック１００は、後述するようにウェブ・ブラウザ・プログラム１０１とクライアント・ウェブ・ページ・アダプタ・モジュール１１２とを実行するクライアント・マシン（コンピュータ）を表し、ディスプレイ装置１１３を含む。クライアント・マシン１００はサーバ１０４に機能的に結合されている。サーバ１０４はウェブ・サイト１０５、１０６およびウェブ・ページ・アダプタ・サーバ１０７に機能的に結合されている。ウェブ・ページ・アダプタ・サーバ１０７はサーバ１１４に機能的に結合されている。
【００１２】クライアント・マシン１００は、ウェブ・サイト関連データを表示できるディスプレイを有する様々な既存のタイプの装置、たとえば、パーソナル・コンピュータ（ＰＣ）、マルチスクリーンＰＣ、ラップトップ・コンピュータ、ウェブフォンがある場合に、多くの形を取ることができることが分かるだろう。しかし、本発明は、このようなマシンのみに限定されず、通信およびブラウズ能力を有するように適合させた他の多様なクライアント・マシン、たとえば、パームトップ、計算機、ウェブＴＶ、リモート・コントロール装置、時計、ディジタル・カメラ、車両ベースのコンピュータ、工業施設ベースのコンピュータでも実施することができる。当然のことながら、上記のリストはすべてを網羅しているわけではない。また、各ディスプレイ・タイプは、様々なサイズのウィンドウ（シェル）を表示することもできる可能性がある。このようなウィンドウの例は、図１ではディスプレイ・タイプの一部（１１３ａ〜１１３ｅ）に示され、ウィンドウ１１５として示されている。
【００１３】図２は、バス１２を介してＲＡＭ１４、ＲＯＭ１６、大容量記憶装置１８、入力装置２０、出力装置２２に機能的に結合されたＣＰＵ１０を含む、クライアント・マシン１００の例示的な構成を示している。関連図により本明細書で詳述する本発明の構成要素はＲＯＭ１６または大容量記憶装置２２あるいはその両方に格納され、必要に応じてバス１２によりＲＡＭ１４にロードされ、中央演算処理装置１０によって実行（動作）されるソフトウェア・モジュールとして実施されることが分かるだろう。ソフトウェア・モジュールを実行するＣＰＵ１０は、入力装置２０、たとえば、キーボード、キーパッド、マウス、タッチ画面によって提供されるユーザ入力に応答することができる。さらに、ソフトウェア・モジュールを実行するＣＰＵ１０は、それからの結果を出力装置２２、たとえば、ディスプレイ、プリンタ、スピーカに出力することができる。また、モデム装置２４はバス１２に機能的に結合され、クライアント・コンピュータとサーバのネットワークとの間の通信インタフェースを提供する。したがって、図１、図３、図４、図６、図８、図９は本発明を実行するための装置のブロック図と見なすことができるが、このような図は流れ図と見なすこともできる。これに関して、本発明は、たとえば、図２に示すような、１つまたは複数の適当にプログラミングされた汎用ディジタル・コンピュータを使用して実行されるので、これらの図に示す機能要素は、このようなプログラミングによってコンピュータ内に確立されると思われる機能要素を例示するものであることが分かるはずである。したがって、前記の図は、汎用プロセッサ、たとえば、ＣＰＵ１０のプログラミングによって達成可能な本発明を実施するための適当かつ好ましいプロセッサ・アーキテクチャを示すものと見なすことができる。当然のことながら、前記の図に示すように構成された専用プロセッサを使用することもできる。
【００１４】さらに、図１に示すように、ウェブ・ページ・アダプタ・サーバ１０７とサーバ１０４および１１４は図２に示すように同様のアーキテクチャを有することができ、その結果、それに関連してこれらの図に示す機能要素は前述のように１つまたは複数の汎用または専用プロセッサ上で実行されるソフトウェア・モジュールにすることができることが分かるだろう。
【００１５】前述のように、本発明の重要な原動力として、クライアント・マシン１００のディスプレイ１１３は、ブロック１１３内に示すいくつかの例に示すように様々なサイズ、形状、構成のモニタ（ディスプレイ）、たとえば、標準的なＰＣモニタ（１１３ａ）、マルチスクリーンＰＣシステム（１１３ｂ）、ラップトップ・ディスプレイ（１１３ｃ）、ウェブフォン（１１３ｄ）、腕時計のディスプレイ（１１３ｅ）を含むことができる。当然のことながら、ブロック１１３に示すディスプレイのタイプは、例示的なものであり、本発明により使用可能なディスプレイのタイプを網羅的に示すためのものではない。また、各ディスプレイは、アイコンおよび情報を表示するための様々なサイズのウィンドウ（シェル）を含むことができる。このようなウィンドウの例は、図１に示すディスプレイ・タイプの一部（１１３ａ〜１１３ｄ）に示され、ウィンドウ１１５として示されている。
【００１６】本発明の好ましいディスプレイ画面およびウィンドウ・サイズ関連ウェブ・ページ適応システムが前述の相互接続性を有するものとして、その動作について次に説明する。クライアント１００は、標準のＴＣＰ−ＩＰインターネット接続１０８を使用する何らかのポートでＵＲＬ（ユニフォーム・リソース・ロケータ）規格に適合する要求メッセージ１０２を（モデム２４を介して）サーバ・マシン１０４に送信する。クライアント・マシン１００とサーバ１０４との間のポート・プロトコルは好ましいことにＨＴＴＰ（ハイパーテキスト・トランスポート・プロトコル）である。既知の通り、ＵＲＬは、ワールド・ワイド・ウェブ上のサーバ・コンピュータまたはその他のインターネット施設上のファイルへの経路を定義するアドレスとして機能する。したがって、ＵＲＬ規格に適合する要求メッセージ１０２は、他のページへのハイパーテキスト・リンクを提供するために、それ自体がそれに埋め込まれたＵＲＬを有するウェブ・ページへのアクセス権をクライアントに提供する。
【００１７】要求メッセージ１０２と同時に、クライアントは、ディスプレイ・モード・メッセージ１０３を送信する。このディスプレイ・モード・メッセージ１０３は、クライアント・ディスプレイ１１３のいくつかの特性またはパラメータを含む。パラメータの１つは、高さおよび幅（たとえば、３６０×４００ピクセル）として表されるディスプレイ・サイズである。その他の特性としては、たとえば、文字のフォーマットとサイズ、たとえば、メモリ・アドレスなどのメモリ関連情報、ウィンドウ・サイズなどを含むことができる。
【００１８】メモリ・アドレス情報は、クライアントのマシン１００上で動作するオペレーティング・システム、すなわち、Windows 95、ＯＳ２などに固有のものである。たとえば、Windows 95では、最高４ＧバイトのＲＡＭにアクセス可能なリニア・アドレス指定モデルを使用している。４Ｇバイトの潜在的なアドレスは４ｋバイトのセクションに分割され、そのそれぞれはページと呼ばれる。ページ・テーブルは、仮想アドレスを物理メモリ位置にマッピングするために使用する。最初の１Ｍバイト分のメモリは、ＭＳ−ＤＯＳの仮想計算機動作に使用する。４Ｍバイトから２Ｇバイトまでのアドレスは、それぞれの基本動作として３２ビット・プログラムが使用する。動作中の各３２ビット・アプリケーションは、この２Ｇバイト分のアドレスの専用のローカル・マップを取得する。プログラムがアドレスを呼び出すと、それは内部でWindows 95の仮想メモリ・マネージャによって、プログラムがアクセスを必要としている情報を含む物理メモリ・アドレスに変換される。ＤＯＳおよびWindowsの旧バージョンでは、コンベンショナル・メモリ、ＥＭＳメモリ、拡張メモリの仕様にメモリを分割していた。このメモリ関連情報により、格納済み情報を表示するためにどの程度のメモリが使用可能であるかを計算することができる。この情報は、表示用のデータを編成するため、データに高速アクセスするためなどに使用する。様々な種類のデータのアドレスが与えられると、何らかのデータ割振り用の記憶域はこれらのアドレスの差として見つけることができる。
【００１９】ディスプレイ・モード・メッセージは、ディスプレイ・パラメータを固有に定義するモード番号として表すことができる。たとえば、本発明では、所与のディスプレイ端末に関連するディスプレイ特性またはパラメータを含むテーブルを作成することができ、各テーブルは固有のモード番号によって識別できることを企図している。最終的に、アダプタ・サーバ１０７がディスプレイ画面に関連する最も一般的なディスプレイ・パラメータのテーブルを含んでいる（その大容量記憶装置１８に格納している）場合、ユーザのマシン１００はモード番号を伝送するだけでよく、応答としてアダプタ・サーバ１０７は適切なテーブルを突き止めて、それに応じて情報を使用することができるだろう」（段落【００１１】〜【００１９】）
　
ソ　「【００２１】要求メッセージ１０２はサーバ１０４によるウェブ・サイト１０６への接続（経路）１０９を定義し、ウェブ・サイト１０６からのウェブ・ページは接続１１０によりサーバ１０４に返送される。図１のサーバ１０４を通って描かれている想像線は、サーバ１０４が実行する経路指示機能を示す働きをする。他の従来の機能はサーバ１０４によって実行することができる。それにもかかわらず、サーバ１０４では、ディスプレイ・モード・メッセージ１０３と、接続１１０により受信したウェブ・ページの内容は、接続１１０ａによりウェブ・ページ・アダプタ・サーバ１０７に送信される。サーバ１０４は、ディスプレイ・モード・メッセージがウェブ・サイトに経路指定され、次にウェブ・サイトからのウェブ・ページ・データとともにアダプタ・サーバ１０７に経路指定されることを示しているが、これは必ずしも必要なことではなく、したがって、ディスプレイ・モード・メッセージはサーバ１０４からアダプタ・サーバ１０７に直接送信できることが分かるだろう。有利なことに、ウェブ・ページ・アダプタ・サーバ１０７は、ウェブ・ページの内容をディスプレイ１１３のサイズに適応させ、ディスプレイ・モード・メッセージ１０３に指定されたユーザの要件を満たすためにも、サーバ１０４を介してウェブ・サイト１０６から受信したウェブ・ページを変換する。ウェブ・ページ・アダプタ・サーバ１０７が実行する動作の例は以下の通りである。すなわち、ディスプレイ１１３のディスプレイ・サイズが小さい場合にウェブ・ページからオブジェクトを除去すること、またはディスプレイ１１３のディスプレイ・サイズが大きい場合にウェブ・ページにリンクの内容を追加することである。ウェブ・ページ・アダプタ・サーバ１０７のウェブ・ページ適応動作の詳細説明については、図３、図８、図９に関連して以下に示す。また、ウェブ・ページ・アダプタ・サーバ１０７は、サーバ１０４の場合と同じように、図１にサーバ１１４として示す他のサーバ・マシンから得られたウェブ・ページの変換も提供することができる。すなわち、単一サーバ１０７は、ネットワーク上の複数の他のサーバに対応することができる。
【００２２】サーバ１０７からのページの変換済みセットは、接続１１１ａによりサーバ１０４に送信され、次に接続１１１によりサーバ１０４からクライアント・マシン１００上に送信される。ウェブ・ページの適応セットは、ディスプレイ装置１１３上に表示するかまたはクライアント・ウェブ・ページ・アダプタ・モジュール１１２に送信することができる。アダプタ・モジュール１１２は好ましいことにクライアント・マシン１００にインストールされている。アダプタ・モジュール１１２は、ウェブ・ディスプレイ・アダプタ・サーバ１０７で使用可能ではない追加の固有動作を実行する。最も重要なこのようなローカル動作の１つは、ウィンドウまたはシェルにウェブ・ページを適応させることである。ウィンドウまたはシェルは、ディスプレイ装置１１３の画面の一部を占めることができ、通常はサイズがより小さいことを特徴とする。クライアントベースのウェブ・ページ・アダプタ・モジュール１１２の動作の詳細説明については、図４に関連して以下に示す。」（段落【００２１】〜【００２２】）
　
３　対比
　本願補正発明と引用発明を対比する。
　引用発明において、複雑で詳細でマルチメディア経験に富んだコンテンツは、スクリーンが小さすぎることなど、オリジナルのサーバと最終的なユーザとの間の技術的な制限にしばしば遭遇し、イメージはサイズを縮小することなど、オリジナルの表現からもっと適切な表現へトランスコードすることにより、コンテンツと能力のミスマッチに対応することができることから、引用発明のクライアントの能力には、スクリーンの能力が含まれていることは明らかである。また、引用発明において、クライアントの能力は、予め決定された能力であることも明らかである。さらに、引用発明の「スクリーン」及び「能力」は、それぞれ本願補正発明の「ディスプレイ」及び「性能」に相当する。加えて、本願補正発明の移動局は、サーバ／クライアント方式のクライアントであることは明らかであるから、引用発明の「クライアント」と本願補正発明の「移動局」は、「クライアント」である点で一致する。そうすると、引用発明のスクリーンを含む予め決定された能力を有する「クライアント」と本願補正発明の「ディスプレイを含む予め決定された性能を有する移動局」は、「ディスプレイを含む予め決定された性能を有するクライアント」である点で一致する。
　引用発明において、ＧＩＦはイメージデータであるから、引用発明の「ＧＩＦ」と本願補正発明の「ＨＴＭＬデータ」は、「データ」である点で一致する。
　引用発明の「トランスコード」及び「トランスコーディング」は、オリジナルの表現からもっと適切な表現へコードを変換することであるといえるから、本願補正発明の「変形」に相当する。また、引用発明の「変換」も、本願補正発明の「変形」に相当する。
　引用発明の「プロキシサーバ」は、本願補正発明の「ネットワークサーバー」に相当する。
　引用発明において、トランスコーディングは、中間のプロキシサーバで行われ、また、オリジナルのサーバがＧＩＦのレスポンスを発生した場合、オリジナルのサーバは、ＧＩＦのレスポンスをフォーマットのセット（ＪＰＥＧ、ＰＮＧ、もっと小さいＧＩＦ）のいずれかに変換する方法を知っているトランスコーディングアプレットを提供し、プロキシサーバは、クライアントの能力に基づいて、最善の変換を選択することから、プロキシサーバは、クライアントで表示するために、ＧＩＦのレスポンスをＪＰＥＧなどの新たなフォーマットに変換していることは、明らかである。
　したがって、引用発明の上記構成の「プロキシサーバ」と本願補正発明の「ディスプレイを含む予め決定された性能を有する移動局で表示するためにＨＴＭＬデータを新たなフォーマットに変形するネットワークサーバー」は、「ディスプレイを含む予め決定された性能を有するクライアントで表示するためにデータを新たなフォーマットに変形するネットワークサーバー」である点で一致する。
　引用発明において、オリジナルのサーバからのＧＩＦのレスポンスは、ウェブサイトのコンテンツであるＧＩＦのデータであることは明らかであるから、引用発明の「ＧＩＦのレスポンス」と本願補正発明の「ウェッブページのＨＴＭＬデータ」は、「ウェッブのデータ」である点で一致する。また、引用発明において、変換されていないレスポンスに対するキャッシュを行うことから、プロキシサーバが、オリジナルのサーバからのＧＩＦのレスポンスを貯蔵するキャッシュメモリを備えることは明らかである。ここで、キャッシュメモリは、本願補正発明の「メモリ」に相当する。
　引用発明において、トランスコーディングシステムは、オリジナルのサーバによって特定されるトランスコーディングアプレットを実行するための仮想マシンを提供しているから、この仮想マシンが、トランスコーディングアプレットを実行することにより、オリジナルのサーバのデータを、クライアントの能力に合わせてフィルタリングしているといえる。よって、引用発明の「仮想マシン」と本願補正発明の「ＨＴＭＬフィルター」は、「フィルター」である点で一致する。また、引用発明において、仮想マシンは、プロキシサーバで実行されていることから、プロキシサーバが、仮想マシンを貯蔵する何らかのメモリを備えることは明らかである。
　引用発明において、トランスコーディングアプレットは、トランスコーディングプログラムであるから、引用発明の「トランスコーディングアプレット」と本願補正発明の「ＨＴＭＬ変形スクリプト」は、「変形プログラム」である点で一致する。また、引用発明において、トランスコーディングアプレットは、セット仕様であるから、各種のトランスコーディングアプレットがあることは明らかである。さらに、引用発明において、トランスコーディングアプレットは、トランスコーディングシステムによりキャッシュされることから、トランスコーディングシステムであるプロキシサーバが、トランスコーディングアプレットを貯蔵するキャッシュメモリを備えることは明らかである。ここで、キャッシュメモリは、本願補正発明の「メモリ」に相当する。
　引用発明において、トランスコーディングは、中間のプロキシサーバで行われ、また、オリジナルのサーバがＧＩＦのレスポンスを発生した場合、オリジナルのサーバは、ＧＩＦのレスポンスをフォーマットのセット（ＪＰＥＧ、ＰＮＧ、もっと小さいＧＩＦ）のいずれかに変換する方法を知っているトランスコーディングアプレットを提供し、プロキシサーバは、クライアントの能力に基づいて、最善の変換を選択することから、トランスコーディングアプレットとクライアントの能力を用いて、ＧＩＦのレスポンスからクライアントの能力に応じて選択されたＪＰＥＧなどの新たなフォーマットに変換するように、仮想マシンを実行させていることは明らかである。したがって、引用発明の当該構成と本願補正発明の「ＨＴＭＬ変形スクリプトと予め決定された性能を用いて前記ウェッブページのＨＴＭＬデータから前記移動局の予め決定された性能に応じて変更される新たなフォーマットのＨＴＭＬデータを生成するようにＨＴＭＬフィルターを実行させ」る構成は、「変形スクリプトと予め決定された性能を用いて前記ウェッブのデータから前記クライアントの予め決定された性能に応じて変更される新たなフォーマットのデータを生成するようにフィルターを実行させ」る構成である点で一致する。
　引用発明において、トランスコーディングは、中間のプロキシサーバで行われることから、トランスコードしたデータをクライアントへ伝送することは明らかである。そうすると、引用発明において、クライアントのスクリーン上で表示するために、ＪＰＥＧなどの新たなフォーマットに変換したデータをクライアントへ伝送できることは明らかである。したがって、引用発明の当該構成と本願補正発明の「前記移動局のディスプレイ上で表示するために新たなフォーマットのＨＴＭＬデータを前記移動局へ伝送できる」構成は、「前記クライアントのディスプレイ上で表示するために新たなフォーマットのデータを前記クライアントへ伝送できる」構成である点で一致する。
　
　すると、本願補正発明と引用発明とは、次の点で一致する。
＜一致点＞
「ディスプレイを含む予め決定された性能を有するクライアントで表示するためにデータを新たなフォーマットに変形するネットワークサーバーにおいて、
　変形プログラムと予め決定された性能を用いて前記ウェッブのデータから前記クライアントの予め決定された性能に応じて変更される新たなフォーマットのデータを生成するようにフィルターを実行させ、前記クライアントのディスプレイ上で表示するために新たなフォーマットのデータを前記クライアントへ伝送できることを特徴とするネットワークサーバー。」
　
　一方、両者は次の点で相違する。
＜相違点１＞
　本願補正発明では、データが、ウェッブページのＨＴＭＬデータであるのに対し、引用発明では、データが、ウェッブのＧＩＦのレスポンスであり、また、本願補正発明では、フィルターが、ＨＴＭＬフィルターであるのに対し、引用発明では、フィルターが、仮想マシンであり、さらに、本願補正発明では、変形プログラムが、ＨＴＭＬ変形スクリプトであるのに対し、引用発明では、変形プログラムが、トランスコーディングアプレットである点。
＜相違点２＞
　本願補正発明では、ウェッブページのＨＴＭＬデータ、ＨＴＭＬフィルター及び各種のＨＴＭＬ変形スクリプトと共に、予め決定された複数の移動局の性能を貯蔵するメモリを備えるのに対し、引用発明では、ウェッブのＧＩＦのレスポンスを貯蔵するキャッシュメモリを備え、また、仮想マシンを貯蔵する何らかのメモリを備え、さらに、トランスコーディングアプレットを貯蔵するキャッシュメモリを備え、加えて、クライアントの能力は、ＨＴＴＰのUser-agentヘッダ及び／又はAcceptヘッダから抽出される点。
＜相違点３＞
　本願補正発明では、メモリに連結され、移動局から移動局の予め決定された性能を決定するための識別情報が受信されると、受信された識別情報を用いてメモリから移動局の予め決定された性能を検索し、ＨＴＭＬ変形スクリプトと検索された予め決定された性能を用いてウェッブページのＨＴＭＬデータから移動局の予め決定された性能に応じて変更される新たなフォーマットのＨＴＭＬデータを生成するようにＨＴＭＬフィルターを実行させ、識別情報を伝送した移動局のディスプレイ上で表示するために新たなフォーマットのＨＴＭＬデータを識別情報を伝送した移動局へ伝送できるデータプロセッサとを備えるのに対し、引用発明では、クライアントが識別情報を伝送した移動局であること、移動局から移動局の予め決定された性能を決定するための識別情報が受信されると、受信された識別情報を用いてメモリから移動局の予め決定された性能を検索すること、検索された予め決定された性能を用いること、メモリに連結され、上記の動作を行うデータプロセッサについては明確な記載がない点。
　
４　当審の判断
　上記相違点について検討する。
＜相違点１についての検討＞
　プロキシサーバにおいて、携帯電話で適切に表示できるように、ウェッブページであるＨＴＭＬ文書を変換する技術は、例えば、特開２０００−９０００１号公報（特に、段落【００３８】〜【００４０】、【００７２】及び表５参照。）及び特開２００１−１９５３９１号公報（特に、段落【０００３】〜【０００５】及び【００２９】〜【００３２】参照。）に記載されているように、本願優先日前周知である。
　また、アプレットとスクリプトは、ウェッブ技術において用いられるプログラムとして、両者とも本願優先日前周知であるから、アプレット又はスクリプトのどちらを用いるかは、当業者が必要に応じて適宜選択し得る設計的事項にすぎない。
　したがって、引用発明において、上記周知技術を適用して、ウェッブのＧＩＦのレスポンスをウェッブページのＨＴＭＬデータとし、また、仮想マシンをＨＴＭＬフィルターとし、さらに、トランスコーディングアプレットをＨＴＭＬ変形スクリプトとすることは、当業者が容易に想到し得ることである。
　
＜相違点２及び３についての検討＞
　引用例２には、クライアント・マシンであるウェブフォンは、要求メッセージと同時にモード番号のみのディスプレイ・モード・メッセージを送信し、アダプタ・サーバは、モード番号で識別可能なディスプレイ・パラメータのテーブルを大容量記憶装置に格納しており、受信したモード番号から適切なテーブルを突き止めて、それに応じてディスプレイ・パラメータの情報を使用し、要求メッセージに係るウェブ・サイトから受信したウェブ・ページを変換し、ウェブ・ページの変換済みセットは、要求メッセージと同時にモード番号のみのディスプレイ・モード・メッセージを送信したウェブフォンに送信され、ウェブフォンのディスプレイ装置に表示される技術が記載されている。ここで、引用例２に記載された技術の「ウェブフォン」、「ディスプレイ・パラメータ」、「モード番号」、「大容量記憶装置」及び「送信」は、本願補正発明の「移動局」、「予め決定された性能」、「識別情報」、「メモリ」及び「伝送」に相当する。また、引用例２に記載された技術において、受信したモード番号から適切なテーブルを突き止めて、それに応じてディスプレイ・パラメータの情報を使用していることから、受信されたモード番号を用いて大容量記憶装置からウェブフォンのディスプレイ・パラメータを検索し、検索されたディスプレイ・パラメータを用いていることは、明らかである。さらに、サーバなどのコンピュータにおいて、メモリと連結し、メモリに記憶されたプログラム及びデータを用いて動作を行うデータプロセッサを備える技術は、文献を示すまでもなく、本願優先日前周知である。
　また、引用例２に記載された技術において、大容量記憶装置に格納されたディスプレイ・パラメータのテーブルには、複数のウェブフォンのディスプレイ・パラメータが記憶されていることは明らかである。そして、ＧＩＦのレスポンス、仮想マシン、トランスコーディングアプレット、ディスプレイ・パラメータなどの複数のデータを複数のメモリに記憶するか、まとめて１つのメモリに記憶するかは、当業者が必要に応じて適宜選択し得る設計的事項である。
　さらに、ＨＴＭＬデータ、ＨＴＭＬフィルター及びＨＴＭＬ変形スクリプトについては、上記＜相違点１についての検討＞で述べたとおりである。
　そして、引用発明及び引用例２に記載された技術の属する技術分野は、ウェブ・サイトから送信されたデータの変換技術である点で共通する。
　したがって、引用発明において、引用例２に記載された技術及び周知技術を適用して、相違点２及び３の構成とすることは、当業者が容易に想到し得ることである。
　
　また、本願補正発明の構成によって生じる効果も、引用発明、引用例２に記載された技術及び周知技術から当業者が予測できる程度のものである。
　
　したがって、本願補正発明は、引用発明、引用例２に記載された技術及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許出願の際独立して特許を受けることができないものである。
　
５　むすび
　以上のとおり、本件補正は、平成１８年法律５５号改正附則３条１項によりなお従前の例によるとされる同法による改正前の特許法１７条の２第５項において準用する同法１２６条５項の規定に違反するので、同法１５９条１項において読み替えて準用する同法５３条１項の規定により却下すべきものである。
　
第３　本願発明について
　平成２２年３月４日付けの手続補正は上記のとおり却下されたので、本願の請求項８に係る発明（以下「本願発明」という。）は、補正前の請求項８に記載された事項により特定される、前記「第２　１」に記載したとおりのものであると認める。
　
１　引用例
　原査定の拒絶の理由に引用された引用例１、引用例２及びそれらの記載事項は、前記「第２　２」に記載したとおりである。
　
２　当審の判断
　本願発明は、前記「第２」で検討した本願補正発明から、「
前記メモリから
前記識別情報を伝送した
　
３　むすび
　以上のとおり、本願発明は、引用発明、引用例２に記載された技術及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　したがって、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　よって、結論のとおり審決する。