• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
管理番号 1250394
審判番号 不服2010-4831  
総通号数 147 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-03-30 
種別 拒絶査定不服の審決 
審判請求日 2010-03-04 
確定日 2012-01-11 
事件の表示 特願2007-101756「ウェッブページのHTMLデータを移動局におけるディスプレイに好適なフォーマットに変換する装置及び方法」拒絶査定不服審判事件〔平成19年10月 4日出願公開、特開2007-257647〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、平成14年12月25日(パリ条約による優先権主張2001年12月27日、米国)に出願した特願2002-375596号の一部を平成19年4月9日に新たな特許出願としたものであって、平成21年6月30日付けの拒絶の理由の通知に対して、同年10月6日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年10月26日付けで拒絶をすべき旨の査定がされ、これに対し平成22年3月4日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。

第2 平成22年3月4日付けの手続補正についての却下の決定
[結論]
平成22年3月4日付けの手続補正を却下する。
[理由]
1 補正後の本願発明
平成22年3月4日付けの手続補正(以下「本件補正」という。)により、平成21年10月6日付けの手続補正書の特許請求の範囲の請求項8(以下「補正前の請求項8」という。)は、平成22年3月4日付けの手続補正書の特許請求の範囲の請求項8(以下「補正後の請求項8」という。)に補正された。
補正前の請求項8及び補正後の請求項8は、以下のとおりである。

補正前の請求項8
「ディスプレイを含む予め決定された性能を有する移動局で表示するためにHTMLデータを新たなフォーマットに変形するネットワークサーバーにおいて、
ウェッブページのHTMLデータ、HTMLフィルター及び各種のHTML変形スクリプトと共に、予め決定された複数の移動局の性能を貯蔵するメモリと、
前記メモリに連結され、前記移動局から前記移動局の予め決定された性能を決定するための識別情報が受信されると、前記受信された識別情報を用いて前記移動局の予め決定された性能を検索し、HTML変形スクリプトと前記検索された予め決定された性能を用いて前記ウェッブページのHTMLデータから前記移動局の予め決定された性能に応じて変更される新たなフォーマットのHTMLデータを生成するようにHTMLフィルターを実行させ、前記移動局のディスプレイ上で表示するために新たなフォーマットのHTMLデータを前記移動局へ伝送できるデータプロセッサとを備えることを特徴とするネットワークサーバー。」

補正後の請求項8
「ディスプレイを含む予め決定された性能を有する移動局で表示するためにHTMLデータを新たなフォーマットに変形するネットワークサーバーにおいて、
ウェッブページのHTMLデータ、HTMLフィルター及び各種のHTML変形スクリプトと共に、予め決定された複数の移動局の性能を貯蔵するメモリと、
前記メモリに連結され、前記移動局から前記移動局の予め決定された性能を決定するための識別情報が受信されると、前記受信された識別情報を用いて前記メモリから前記移動局の予め決定された性能を検索し、HTML変形スクリプトと前記検索された予め決定された性能を用いて前記ウェッブページのHTMLデータから前記移動局の予め決定された性能に応じて変更される新たなフォーマットのHTMLデータを生成するようにHTMLフィルターを実行させ、前記識別情報を伝送した前記移動局のディスプレイ上で表示するために新たなフォーマットのHTMLデータを前記識別情報を伝送した前記移動局へ伝送できるデータプロセッサとを備えることを特徴とするネットワークサーバー。」(下線は、当審が付与。)

本件補正は、補正前の請求項8に記載した発明を特定するために必要な事項である「前記移動局の予め決定された性能を検索し」及び「前記移動局」に、それぞれ「前記メモリから」及び「前記識別情報を伝送した」との限定を付加したものであって、特許法17条の2第4項2号に規定する特許請求の範囲の減縮を目的とするものに該当する。
そこで、補正後の請求項8に記載された発明(以下「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(特許法17条の2第5項において準用する同法126条5項の規定に適合するか)について以下に検討する。

2 引用例の記載
(1)引用例1
原査定の拒絶の理由に引用されたJ.C. Mogul、"Server-directed transcoding"、Computer Communications、Elsevier Science Publishers BV、2001年2月1日、Vol.24、No.2、pp.155?162(以下「引用例1」という。)には、次の事項が図面とともに記載されている。

ア 「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.」(155頁左欄1?16行。仮訳(当審作成。以下同様。):「1.導入
ウェブサイトのデザイナーは、複雑で詳細でマルチメディア経験に富んだコンテンツを提供することを好む。悲しいことに、このコンテンツは、オリジナルのサーバと最終的なユーザとの間の技術的な制限にしばしば遭遇する:ネットワークが遅すぎたり、又は高価であること、スクリーンが小さすぎること、クライアントが力不足であること、並びに必要なレンダリングソフトウェアが利用不可能なこと。
オリジナルの表現からもっと適切な表現へトランスコードすることにより、コンテンツと能力のミスマッチに対応することができる。イメージは、サイズを縮小し、又はモノクロに変換でき;テキストファイルは、要約化することができ;ビデオフォーマットは、変更することができる。正しく使用した場合、トランスコーディング(ときどき、蒸留という。)は、実行可能性の制限をすることなく、オリジナルのコンテンツの不可欠な情報をユーザに提供できる。」)

イ 「In the Web, transcoding may be done at an intermediate proxy server, or at the ultimate client application.」(155頁左欄下から2?1行。仮訳:「ウェブでは、トランスコーディングは、中間のプロキシサーバ又は最終的なクライアントアプリケーションで行われる。」)

ウ 「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.」(155頁右欄11?15行。仮訳:「この論文は、サーバ指示トランスコーディングと呼ぶトランスコーディングの新しいアプローチを提案する。このアプローチにおいて、オリジナルのサーバは、トランスコーディングシステム(プロキシ又はクライアント)へ、表現間の変換を行うのか、及びどのような変換を行うのかについての明白なガイダンスを提供する。」)

エ 「The use of applets to dynamically customize the operation of a proxy or client is similar in concept to "active networks."」(156頁右欄20?22行。仮訳:「プロキシ又はクライアントの動作を直接カスタマイズするアプレットの使用は、「アクティブネットワーク」の概念に類似する。」)

オ 「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.」(159頁左欄25?32行。仮訳:「5.トランスコーディングアプレット
さらなる力強いアプローチは、トランスコーディングアプレットを使用することである:トランスコーディングアプレットは、トランスコーディングシステムによってダウンロードされるセット仕様のトランスコーディングプログラムである。このアプローチでは、トランスコーディングシステムは、オリジナルのサーバによって特定されるトランスコーディングアプレット(「モバイルコード」)を実行するための(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.」(159頁右欄下から27?10行。仮訳:「オリジナルのサーバは、前もって、トランスコードするプロキシからのキャッシュされたレスポンスを受け取るすべてのクライアントの能力を知ることができないから、プロキシは、(オリジナルのサーバからの)可能な変換の範囲に関するいくらかの情報と特定のクライアントとその間のネットワークパスの能力と嗜好に関する(特定のクライアントの要求それぞれのための)情報を組み合わさなければならない。また、プロキシは、トランスコーディングシステムの(CPU又はRAMなどの)資源の利用可能性に関する情報を使用するかもしれない。それから、この情報すべてを用いて、プロキシは、何の変換を適用すべきか、必要があれば、決定することができる。
さらに具体的には、サーバは、特定の変換よりもむしろ、アルゴリズムのセットを供給するかもしれない。例えば、サーバがGIFのレスポンスを発生した場合、サーバは、GIFのレスポンスをフォーマットのセット(JPEG、PNG、もっと小さいGIF)のいずれかに変換する方法を知っているアプレットを提供することができる。プロキシは、クライアントの能力と資源の利用可能性に基づいて、最善の変換を選択することができる。」)

キ 「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.」(160頁左欄3?12行。仮訳:「5.2.参照によるトランスコーディングアプレット
サーバは、参照によって、レスポンスについての特定のトランスコーディングアプレットを特定することができる;例えば、
Transcode-Info: app=
"http://applets.compaq.com/app37.cls"
トランスコーディングシステムがこのアプレットを使用したい場合、トランスコーディングシステムは、その特定のURLをダウンロードする。これは、潜在的に、サーバへの更なる1往復を加える。もちろん、アプレットが十分に一般的な場合、アプレットはトランスコーディングシステムにより有益にキャッシュされることができる。」)

ク 「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.)」(160頁左欄下から9?4行。仮訳:「アプレットの手法のすべては、コンテンツそれ自身だけでなく、利用可能な帯域幅とクライアントの能力などの受信者の属性も入力として受け取る。(これらの能力は、[12]の文献の「特徴セット」を用いて表現されることができ、また、HTTPの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.」(160頁右欄下から23?10行。仮訳:「5.6.トランスコーディングアプレットのその他の利点
トランスコーディングは、通常、帯域幅の要件やディスプレイの要件などを減少させる目的を持つ、データの劣化を伴うメカニズムの考え方であるが、拡張可能なメカニズムとして使用することもできる。サーバ指示のトランスコーディングは、サーバに、クライアントやプロキシへの更なる修正を要求することなく、新しいメディアフォーマットを導入させる。例えば、クライアントが、オーディオクリップに対するMP3フォーマットのみ実行するのに対し、サーバはAIFFフォーマットのコンテンツを持っている場合、(理論的に)それは、この変換をすることができるアプレットを特定することにより、トランスコードするプロキシにオンデマンドでその変換をさせることができる。クライアントの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」(161頁左欄1?4行。仮訳:「5.7.トランスコードされた結果のキャッシュを行うこと
トランスコードされた結果のキャッシュを行うことは、変換されていないレスポンスに対するキャッシュを行う限りにおいて、有益である。」)

サ 「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.」(162頁左欄24?30行。仮訳:「サーバ指示のトランスコーディングアプレットは、標準化プロセスの障害からトランスコーディングの使用をフリーにする、プロキシベース又はクライアントベースのトランスコーディングに対する完全に拡張可能なメカニズムを提供する。アプレット手法のいくつかの初期の標準化が要求される一方、トランスコーディングの標準に対する要件は、とても簡単なものである。そのメカニズムは、HTTPと互換可能な拡張であり、その他のレイヤーは変更を必要としない。」)

以上の記載によれば、引用例1には、次の発明(以下「引用発明」という。)が記載されている。

「複雑で詳細でマルチメディア経験に富んだウェブサイトのコンテンツは、スクリーンが小さすぎることなど、オリジナルのサーバと最終的なユーザとの間の技術的な制限にしばしば遭遇し、
イメージはサイズを縮小することなど、オリジナルの表現からもっと適切な表現へトランスコードすることにより、コンテンツと能力のミスマッチに対応することができ、
ウェブでは、トランスコーディングは、中間のプロキシサーバで行われ、
オリジナルのサーバは、トランスコーディングシステム(プロキシサーバ)へ明白なガイダンスを提供し、
トランスコーディングシステムは、オリジナルのサーバによって特定されるトランスコーディングアプレットを実行するための仮想マシンを提供し、
トランスコーディングアプレットは、トランスコーディングシステムによってダウンロードされるセット仕様のトランスコーディングプログラムであり、
オリジナルのサーバがGIFのレスポンスを発生した場合、オリジナルのサーバは、GIFのレスポンスをフォーマットのセット(JPEG、PNG、もっと小さいGIF)のいずれかに変換する方法を知っているトランスコーディングアプレットを提供し、プロキシサーバは、クライアントの能力に基づいて、最善の変換を選択し、
トランスコーディングアプレットは、トランスコーディングシステムによりキャッシュされ、
クライアントの能力は、HTTPのUser-agentヘッダ及び/又はAcceptヘッダから抽出され、
プロキシサーバは、変換されていないレスポンスに対するキャッシュを行う
プロキシサーバ。」

(2)引用例2
原査定の拒絶の理由に引用された特開2000-66868号公報(平成12年3月3日出願公開。以下「引用例2」という。)には、次の事項が図面とともに記載されている。

シ 「【0001】
【発明の属する技術分野】本発明は、表示データを編成するためのシステムおよび方法に関し、より具体的には、その上およびその中で表示データ、たとえば、ホーム・ページまたはウェブ・ページが表示されるディスプレイ画面およびウィンドウ上でウェブ・サイトに関連する表示データを編成するためのシステムおよび方法に関する。」(段落【0001】)

ス 「【0005】
【発明が解決しようとする課題】本発明の目的は、その上およびその中でウェブ・ページが表示されるディスプレイおよびウィンドウ向けにウェブ・サイトに関連する表示データを編成することである。たとえば、標準的なPCモニタ、ラップトップ画面、パームトップから、ウェブフォンおよびディジタル・カメラのディスプレイや、ウェブ・ブラウズが可能なディスプレイを備えた装置まで、また、大きいウィンドウから小さいウィンドウに至る、このような視覚装置のために異なる表示アクセス戦略を提供する。しかし、本発明の教示が前述のタイプのディスプレイを備えた実施態様に限定されず、当業者が他の形式のディスプレイでの使用を企図していることを理解されたい。」(段落【0005】)

セ 「【0011】
【発明の実施の形態】まず、図1を参照すると、本発明によるディスプレイ画面およびウィンドウ・サイズ関連ウェブ・ページ適応システムの構成要素を示す図が示されている。図1では、このディスプレイ画面およびウィンドウ・サイズ関連ウェブ・ページ適応システムの基本構成要素をワールド・ワイド・ウェブ(WWW)の他の構成要素に関して示す。WWWに関連して本発明を図示し説明するが、本発明は、インターネットを含む他の同様のネットワークまたは関連ネットワーク(たとえば、ftp)あるいはその両方で実施することができる。ブロック100は、後述するようにウェブ・ブラウザ・プログラム101とクライアント・ウェブ・ページ・アダプタ・モジュール112とを実行するクライアント・マシン(コンピュータ)を表し、ディスプレイ装置113を含む。クライアント・マシン100はサーバ104に機能的に結合されている。サーバ104はウェブ・サイト105、106およびウェブ・ページ・アダプタ・サーバ107に機能的に結合されている。ウェブ・ページ・アダプタ・サーバ107はサーバ114に機能的に結合されている。
【0012】クライアント・マシン100は、ウェブ・サイト関連データを表示できるディスプレイを有する様々な既存のタイプの装置、たとえば、パーソナル・コンピュータ(PC)、マルチスクリーンPC、ラップトップ・コンピュータ、ウェブフォンがある場合に、多くの形を取ることができることが分かるだろう。しかし、本発明は、このようなマシンのみに限定されず、通信およびブラウズ能力を有するように適合させた他の多様なクライアント・マシン、たとえば、パームトップ、計算機、ウェブTV、リモート・コントロール装置、時計、ディジタル・カメラ、車両ベースのコンピュータ、工業施設ベースのコンピュータでも実施することができる。当然のことながら、上記のリストはすべてを網羅しているわけではない。また、各ディスプレイ・タイプは、様々なサイズのウィンドウ(シェル)を表示することもできる可能性がある。このようなウィンドウの例は、図1ではディスプレイ・タイプの一部(113a?113e)に示され、ウィンドウ115として示されている。
【0013】図2は、バス12を介してRAM14、ROM16、大容量記憶装置18、入力装置20、出力装置22に機能的に結合されたCPU10を含む、クライアント・マシン100の例示的な構成を示している。関連図により本明細書で詳述する本発明の構成要素はROM16または大容量記憶装置22あるいはその両方に格納され、必要に応じてバス12によりRAM14にロードされ、中央演算処理装置10によって実行(動作)されるソフトウェア・モジュールとして実施されることが分かるだろう。ソフトウェア・モジュールを実行するCPU10は、入力装置20、たとえば、キーボード、キーパッド、マウス、タッチ画面によって提供されるユーザ入力に応答することができる。さらに、ソフトウェア・モジュールを実行するCPU10は、それからの結果を出力装置22、たとえば、ディスプレイ、プリンタ、スピーカに出力することができる。また、モデム装置24はバス12に機能的に結合され、クライアント・コンピュータとサーバのネットワークとの間の通信インタフェースを提供する。したがって、図1、図3、図4、図6、図8、図9は本発明を実行するための装置のブロック図と見なすことができるが、このような図は流れ図と見なすこともできる。これに関して、本発明は、たとえば、図2に示すような、1つまたは複数の適当にプログラミングされた汎用ディジタル・コンピュータを使用して実行されるので、これらの図に示す機能要素は、このようなプログラミングによってコンピュータ内に確立されると思われる機能要素を例示するものであることが分かるはずである。したがって、前記の図は、汎用プロセッサ、たとえば、CPU10のプログラミングによって達成可能な本発明を実施するための適当かつ好ましいプロセッサ・アーキテクチャを示すものと見なすことができる。当然のことながら、前記の図に示すように構成された専用プロセッサを使用することもできる。
【0014】さらに、図1に示すように、ウェブ・ページ・アダプタ・サーバ107とサーバ104および114は図2に示すように同様のアーキテクチャを有することができ、その結果、それに関連してこれらの図に示す機能要素は前述のように1つまたは複数の汎用または専用プロセッサ上で実行されるソフトウェア・モジュールにすることができることが分かるだろう。
【0015】前述のように、本発明の重要な原動力として、クライアント・マシン100のディスプレイ113は、ブロック113内に示すいくつかの例に示すように様々なサイズ、形状、構成のモニタ(ディスプレイ)、たとえば、標準的なPCモニタ(113a)、マルチスクリーンPCシステム(113b)、ラップトップ・ディスプレイ(113c)、ウェブフォン(113d)、腕時計のディスプレイ(113e)を含むことができる。当然のことながら、ブロック113に示すディスプレイのタイプは、例示的なものであり、本発明により使用可能なディスプレイのタイプを網羅的に示すためのものではない。また、各ディスプレイは、アイコンおよび情報を表示するための様々なサイズのウィンドウ(シェル)を含むことができる。このようなウィンドウの例は、図1に示すディスプレイ・タイプの一部(113a?113d)に示され、ウィンドウ115として示されている。
【0016】本発明の好ましいディスプレイ画面およびウィンドウ・サイズ関連ウェブ・ページ適応システムが前述の相互接続性を有するものとして、その動作について次に説明する。クライアント100は、標準のTCP-IPインターネット接続108を使用する何らかのポートでURL(ユニフォーム・リソース・ロケータ)規格に適合する要求メッセージ102を(モデム24を介して)サーバ・マシン104に送信する。クライアント・マシン100とサーバ104との間のポート・プロトコルは好ましいことにHTTP(ハイパーテキスト・トランスポート・プロトコル)である。既知の通り、URLは、ワールド・ワイド・ウェブ上のサーバ・コンピュータまたはその他のインターネット施設上のファイルへの経路を定義するアドレスとして機能する。したがって、URL規格に適合する要求メッセージ102は、他のページへのハイパーテキスト・リンクを提供するために、それ自体がそれに埋め込まれたURLを有するウェブ・ページへのアクセス権をクライアントに提供する。
【0017】要求メッセージ102と同時に、クライアントは、ディスプレイ・モード・メッセージ103を送信する。このディスプレイ・モード・メッセージ103は、クライアント・ディスプレイ113のいくつかの特性またはパラメータを含む。パラメータの1つは、高さおよび幅(たとえば、360×400ピクセル)として表されるディスプレイ・サイズである。その他の特性としては、たとえば、文字のフォーマットとサイズ、たとえば、メモリ・アドレスなどのメモリ関連情報、ウィンドウ・サイズなどを含むことができる。
【0018】メモリ・アドレス情報は、クライアントのマシン100上で動作するオペレーティング・システム、すなわち、Windows 95、OS2などに固有のものである。たとえば、Windows 95では、最高4GバイトのRAMにアクセス可能なリニア・アドレス指定モデルを使用している。4Gバイトの潜在的なアドレスは4kバイトのセクションに分割され、そのそれぞれはページと呼ばれる。ページ・テーブルは、仮想アドレスを物理メモリ位置にマッピングするために使用する。最初の1Mバイト分のメモリは、MS-DOSの仮想計算機動作に使用する。4Mバイトから2Gバイトまでのアドレスは、それぞれの基本動作として32ビット・プログラムが使用する。動作中の各32ビット・アプリケーションは、この2Gバイト分のアドレスの専用のローカル・マップを取得する。プログラムがアドレスを呼び出すと、それは内部でWindows 95の仮想メモリ・マネージャによって、プログラムがアクセスを必要としている情報を含む物理メモリ・アドレスに変換される。DOSおよびWindowsの旧バージョンでは、コンベンショナル・メモリ、EMSメモリ、拡張メモリの仕様にメモリを分割していた。このメモリ関連情報により、格納済み情報を表示するためにどの程度のメモリが使用可能であるかを計算することができる。この情報は、表示用のデータを編成するため、データに高速アクセスするためなどに使用する。様々な種類のデータのアドレスが与えられると、何らかのデータ割振り用の記憶域はこれらのアドレスの差として見つけることができる。
【0019】ディスプレイ・モード・メッセージは、ディスプレイ・パラメータを固有に定義するモード番号として表すことができる。たとえば、本発明では、所与のディスプレイ端末に関連するディスプレイ特性またはパラメータを含むテーブルを作成することができ、各テーブルは固有のモード番号によって識別できることを企図している。最終的に、アダプタ・サーバ107がディスプレイ画面に関連する最も一般的なディスプレイ・パラメータのテーブルを含んでいる(その大容量記憶装置18に格納している)場合、ユーザのマシン100はモード番号を伝送するだけでよく、応答としてアダプタ・サーバ107は適切なテーブルを突き止めて、それに応じて情報を使用することができるだろう」(段落【0011】?【0019】)

ソ 「【0021】要求メッセージ102はサーバ104によるウェブ・サイト106への接続(経路)109を定義し、ウェブ・サイト106からのウェブ・ページは接続110によりサーバ104に返送される。図1のサーバ104を通って描かれている想像線は、サーバ104が実行する経路指示機能を示す働きをする。他の従来の機能はサーバ104によって実行することができる。それにもかかわらず、サーバ104では、ディスプレイ・モード・メッセージ103と、接続110により受信したウェブ・ページの内容は、接続110aによりウェブ・ページ・アダプタ・サーバ107に送信される。サーバ104は、ディスプレイ・モード・メッセージがウェブ・サイトに経路指定され、次にウェブ・サイトからのウェブ・ページ・データとともにアダプタ・サーバ107に経路指定されることを示しているが、これは必ずしも必要なことではなく、したがって、ディスプレイ・モード・メッセージはサーバ104からアダプタ・サーバ107に直接送信できることが分かるだろう。有利なことに、ウェブ・ページ・アダプタ・サーバ107は、ウェブ・ページの内容をディスプレイ113のサイズに適応させ、ディスプレイ・モード・メッセージ103に指定されたユーザの要件を満たすためにも、サーバ104を介してウェブ・サイト106から受信したウェブ・ページを変換する。ウェブ・ページ・アダプタ・サーバ107が実行する動作の例は以下の通りである。すなわち、ディスプレイ113のディスプレイ・サイズが小さい場合にウェブ・ページからオブジェクトを除去すること、またはディスプレイ113のディスプレイ・サイズが大きい場合にウェブ・ページにリンクの内容を追加することである。ウェブ・ページ・アダプタ・サーバ107のウェブ・ページ適応動作の詳細説明については、図3、図8、図9に関連して以下に示す。また、ウェブ・ページ・アダプタ・サーバ107は、サーバ104の場合と同じように、図1にサーバ114として示す他のサーバ・マシンから得られたウェブ・ページの変換も提供することができる。すなわち、単一サーバ107は、ネットワーク上の複数の他のサーバに対応することができる。
【0022】サーバ107からのページの変換済みセットは、接続111aによりサーバ104に送信され、次に接続111によりサーバ104からクライアント・マシン100上に送信される。ウェブ・ページの適応セットは、ディスプレイ装置113上に表示するかまたはクライアント・ウェブ・ページ・アダプタ・モジュール112に送信することができる。アダプタ・モジュール112は好ましいことにクライアント・マシン100にインストールされている。アダプタ・モジュール112は、ウェブ・ディスプレイ・アダプタ・サーバ107で使用可能ではない追加の固有動作を実行する。最も重要なこのようなローカル動作の1つは、ウィンドウまたはシェルにウェブ・ページを適応させることである。ウィンドウまたはシェルは、ディスプレイ装置113の画面の一部を占めることができ、通常はサイズがより小さいことを特徴とする。クライアントベースのウェブ・ページ・アダプタ・モジュール112の動作の詳細説明については、図4に関連して以下に示す。」(段落【0021】?【0022】)

3 対比
本願補正発明と引用発明を対比する。
引用発明において、複雑で詳細でマルチメディア経験に富んだコンテンツは、スクリーンが小さすぎることなど、オリジナルのサーバと最終的なユーザとの間の技術的な制限にしばしば遭遇し、イメージはサイズを縮小することなど、オリジナルの表現からもっと適切な表現へトランスコードすることにより、コンテンツと能力のミスマッチに対応することができることから、引用発明のクライアントの能力には、スクリーンの能力が含まれていることは明らかである。また、引用発明において、クライアントの能力は、予め決定された能力であることも明らかである。さらに、引用発明の「スクリーン」及び「能力」は、それぞれ本願補正発明の「ディスプレイ」及び「性能」に相当する。加えて、本願補正発明の移動局は、サーバ/クライアント方式のクライアントであることは明らかであるから、引用発明の「クライアント」と本願補正発明の「移動局」は、「クライアント」である点で一致する。そうすると、引用発明のスクリーンを含む予め決定された能力を有する「クライアント」と本願補正発明の「ディスプレイを含む予め決定された性能を有する移動局」は、「ディスプレイを含む予め決定された性能を有するクライアント」である点で一致する。
引用発明において、GIFはイメージデータであるから、引用発明の「GIF」と本願補正発明の「HTMLデータ」は、「データ」である点で一致する。
引用発明の「トランスコード」及び「トランスコーディング」は、オリジナルの表現からもっと適切な表現へコードを変換することであるといえるから、本願補正発明の「変形」に相当する。また、引用発明の「変換」も、本願補正発明の「変形」に相当する。
引用発明の「プロキシサーバ」は、本願補正発明の「ネットワークサーバー」に相当する。
引用発明において、トランスコーディングは、中間のプロキシサーバで行われ、また、オリジナルのサーバがGIFのレスポンスを発生した場合、オリジナルのサーバは、GIFのレスポンスをフォーマットのセット(JPEG、PNG、もっと小さいGIF)のいずれかに変換する方法を知っているトランスコーディングアプレットを提供し、プロキシサーバは、クライアントの能力に基づいて、最善の変換を選択することから、プロキシサーバは、クライアントで表示するために、GIFのレスポンスをJPEGなどの新たなフォーマットに変換していることは、明らかである。
したがって、引用発明の上記構成の「プロキシサーバ」と本願補正発明の「ディスプレイを含む予め決定された性能を有する移動局で表示するためにHTMLデータを新たなフォーマットに変形するネットワークサーバー」は、「ディスプレイを含む予め決定された性能を有するクライアントで表示するためにデータを新たなフォーマットに変形するネットワークサーバー」である点で一致する。
引用発明において、オリジナルのサーバからのGIFのレスポンスは、ウェブサイトのコンテンツであるGIFのデータであることは明らかであるから、引用発明の「GIFのレスポンス」と本願補正発明の「ウェッブページのHTMLデータ」は、「ウェッブのデータ」である点で一致する。また、引用発明において、変換されていないレスポンスに対するキャッシュを行うことから、プロキシサーバが、オリジナルのサーバからのGIFのレスポンスを貯蔵するキャッシュメモリを備えることは明らかである。ここで、キャッシュメモリは、本願補正発明の「メモリ」に相当する。
引用発明において、トランスコーディングシステムは、オリジナルのサーバによって特定されるトランスコーディングアプレットを実行するための仮想マシンを提供しているから、この仮想マシンが、トランスコーディングアプレットを実行することにより、オリジナルのサーバのデータを、クライアントの能力に合わせてフィルタリングしているといえる。よって、引用発明の「仮想マシン」と本願補正発明の「HTMLフィルター」は、「フィルター」である点で一致する。また、引用発明において、仮想マシンは、プロキシサーバで実行されていることから、プロキシサーバが、仮想マシンを貯蔵する何らかのメモリを備えることは明らかである。
引用発明において、トランスコーディングアプレットは、トランスコーディングプログラムであるから、引用発明の「トランスコーディングアプレット」と本願補正発明の「HTML変形スクリプト」は、「変形プログラム」である点で一致する。また、引用発明において、トランスコーディングアプレットは、セット仕様であるから、各種のトランスコーディングアプレットがあることは明らかである。さらに、引用発明において、トランスコーディングアプレットは、トランスコーディングシステムによりキャッシュされることから、トランスコーディングシステムであるプロキシサーバが、トランスコーディングアプレットを貯蔵するキャッシュメモリを備えることは明らかである。ここで、キャッシュメモリは、本願補正発明の「メモリ」に相当する。
引用発明において、トランスコーディングは、中間のプロキシサーバで行われ、また、オリジナルのサーバがGIFのレスポンスを発生した場合、オリジナルのサーバは、GIFのレスポンスをフォーマットのセット(JPEG、PNG、もっと小さいGIF)のいずれかに変換する方法を知っているトランスコーディングアプレットを提供し、プロキシサーバは、クライアントの能力に基づいて、最善の変換を選択することから、トランスコーディングアプレットとクライアントの能力を用いて、GIFのレスポンスからクライアントの能力に応じて選択されたJPEGなどの新たなフォーマットに変換するように、仮想マシンを実行させていることは明らかである。したがって、引用発明の当該構成と本願補正発明の「HTML変形スクリプトと予め決定された性能を用いて前記ウェッブページのHTMLデータから前記移動局の予め決定された性能に応じて変更される新たなフォーマットのHTMLデータを生成するようにHTMLフィルターを実行させ」る構成は、「変形スクリプトと予め決定された性能を用いて前記ウェッブのデータから前記クライアントの予め決定された性能に応じて変更される新たなフォーマットのデータを生成するようにフィルターを実行させ」る構成である点で一致する。
引用発明において、トランスコーディングは、中間のプロキシサーバで行われることから、トランスコードしたデータをクライアントへ伝送することは明らかである。そうすると、引用発明において、クライアントのスクリーン上で表示するために、JPEGなどの新たなフォーマットに変換したデータをクライアントへ伝送できることは明らかである。したがって、引用発明の当該構成と本願補正発明の「前記移動局のディスプレイ上で表示するために新たなフォーマットのHTMLデータを前記移動局へ伝送できる」構成は、「前記クライアントのディスプレイ上で表示するために新たなフォーマットのデータを前記クライアントへ伝送できる」構成である点で一致する。

すると、本願補正発明と引用発明とは、次の点で一致する。
<一致点>
「ディスプレイを含む予め決定された性能を有するクライアントで表示するためにデータを新たなフォーマットに変形するネットワークサーバーにおいて、
変形プログラムと予め決定された性能を用いて前記ウェッブのデータから前記クライアントの予め決定された性能に応じて変更される新たなフォーマットのデータを生成するようにフィルターを実行させ、前記クライアントのディスプレイ上で表示するために新たなフォーマットのデータを前記クライアントへ伝送できることを特徴とするネットワークサーバー。」

一方、両者は次の点で相違する。
<相違点1>
本願補正発明では、データが、ウェッブページのHTMLデータであるのに対し、引用発明では、データが、ウェッブのGIFのレスポンスであり、また、本願補正発明では、フィルターが、HTMLフィルターであるのに対し、引用発明では、フィルターが、仮想マシンであり、さらに、本願補正発明では、変形プログラムが、HTML変形スクリプトであるのに対し、引用発明では、変形プログラムが、トランスコーディングアプレットである点。
<相違点2>
本願補正発明では、ウェッブページのHTMLデータ、HTMLフィルター及び各種のHTML変形スクリプトと共に、予め決定された複数の移動局の性能を貯蔵するメモリを備えるのに対し、引用発明では、ウェッブのGIFのレスポンスを貯蔵するキャッシュメモリを備え、また、仮想マシンを貯蔵する何らかのメモリを備え、さらに、トランスコーディングアプレットを貯蔵するキャッシュメモリを備え、加えて、クライアントの能力は、HTTPのUser-agentヘッダ及び/又はAcceptヘッダから抽出される点。
<相違点3>
本願補正発明では、メモリに連結され、移動局から移動局の予め決定された性能を決定するための識別情報が受信されると、受信された識別情報を用いてメモリから移動局の予め決定された性能を検索し、HTML変形スクリプトと検索された予め決定された性能を用いてウェッブページのHTMLデータから移動局の予め決定された性能に応じて変更される新たなフォーマットのHTMLデータを生成するようにHTMLフィルターを実行させ、識別情報を伝送した移動局のディスプレイ上で表示するために新たなフォーマットのHTMLデータを識別情報を伝送した移動局へ伝送できるデータプロセッサとを備えるのに対し、引用発明では、クライアントが識別情報を伝送した移動局であること、移動局から移動局の予め決定された性能を決定するための識別情報が受信されると、受信された識別情報を用いてメモリから移動局の予め決定された性能を検索すること、検索された予め決定された性能を用いること、メモリに連結され、上記の動作を行うデータプロセッサについては明確な記載がない点。

4 当審の判断
上記相違点について検討する。
<相違点1についての検討>
プロキシサーバにおいて、携帯電話で適切に表示できるように、ウェッブページであるHTML文書を変換する技術は、例えば、特開2000-90001号公報(特に、段落【0038】?【0040】、【0072】及び表5参照。)及び特開2001-195391号公報(特に、段落【0003】?【0005】及び【0029】?【0032】参照。)に記載されているように、本願優先日前周知である。
また、アプレットとスクリプトは、ウェッブ技術において用いられるプログラムとして、両者とも本願優先日前周知であるから、アプレット又はスクリプトのどちらを用いるかは、当業者が必要に応じて適宜選択し得る設計的事項にすぎない。
したがって、引用発明において、上記周知技術を適用して、ウェッブのGIFのレスポンスをウェッブページのHTMLデータとし、また、仮想マシンをHTMLフィルターとし、さらに、トランスコーディングアプレットをHTML変形スクリプトとすることは、当業者が容易に想到し得ることである。

<相違点2及び3についての検討>
引用例2には、クライアント・マシンであるウェブフォンは、要求メッセージと同時にモード番号のみのディスプレイ・モード・メッセージを送信し、アダプタ・サーバは、モード番号で識別可能なディスプレイ・パラメータのテーブルを大容量記憶装置に格納しており、受信したモード番号から適切なテーブルを突き止めて、それに応じてディスプレイ・パラメータの情報を使用し、要求メッセージに係るウェブ・サイトから受信したウェブ・ページを変換し、ウェブ・ページの変換済みセットは、要求メッセージと同時にモード番号のみのディスプレイ・モード・メッセージを送信したウェブフォンに送信され、ウェブフォンのディスプレイ装置に表示される技術が記載されている。ここで、引用例2に記載された技術の「ウェブフォン」、「ディスプレイ・パラメータ」、「モード番号」、「大容量記憶装置」及び「送信」は、本願補正発明の「移動局」、「予め決定された性能」、「識別情報」、「メモリ」及び「伝送」に相当する。また、引用例2に記載された技術において、受信したモード番号から適切なテーブルを突き止めて、それに応じてディスプレイ・パラメータの情報を使用していることから、受信されたモード番号を用いて大容量記憶装置からウェブフォンのディスプレイ・パラメータを検索し、検索されたディスプレイ・パラメータを用いていることは、明らかである。さらに、サーバなどのコンピュータにおいて、メモリと連結し、メモリに記憶されたプログラム及びデータを用いて動作を行うデータプロセッサを備える技術は、文献を示すまでもなく、本願優先日前周知である。
また、引用例2に記載された技術において、大容量記憶装置に格納されたディスプレイ・パラメータのテーブルには、複数のウェブフォンのディスプレイ・パラメータが記憶されていることは明らかである。そして、GIFのレスポンス、仮想マシン、トランスコーディングアプレット、ディスプレイ・パラメータなどの複数のデータを複数のメモリに記憶するか、まとめて1つのメモリに記憶するかは、当業者が必要に応じて適宜選択し得る設計的事項である。
さらに、HTMLデータ、HTMLフィルター及びHTML変形スクリプトについては、上記<相違点1についての検討>で述べたとおりである。
そして、引用発明及び引用例2に記載された技術の属する技術分野は、ウェブ・サイトから送信されたデータの変換技術である点で共通する。
したがって、引用発明において、引用例2に記載された技術及び周知技術を適用して、相違点2及び3の構成とすることは、当業者が容易に想到し得ることである。

また、本願補正発明の構成によって生じる効果も、引用発明、引用例2に記載された技術及び周知技術から当業者が予測できる程度のものである。

したがって、本願補正発明は、引用発明、引用例2に記載された技術及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許出願の際独立して特許を受けることができないものである。

5 むすび
以上のとおり、本件補正は、平成18年法律55号改正附則3条1項によりなお従前の例によるとされる同法による改正前の特許法17条の2第5項において準用する同法126条5項の規定に違反するので、同法159条1項において読み替えて準用する同法53条1項の規定により却下すべきものである。

第3 本願発明について
平成22年3月4日付けの手続補正は上記のとおり却下されたので、本願の請求項8に係る発明(以下「本願発明」という。)は、補正前の請求項8に記載された事項により特定される、前記「第2 1」に記載したとおりのものであると認める。

1 引用例
原査定の拒絶の理由に引用された引用例1、引用例2及びそれらの記載事項は、前記「第2 2」に記載したとおりである。

2 当審の判断
本願発明は、前記「第2」で検討した本願補正発明から、「前記メモリから」及び「前記識別情報を伝送した」との構成を省いたものである。そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「第2 4」に記載したとおり、引用発明、引用例2に記載された技術及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明、引用例2に記載された技術及び周知技術に基づいて、当業者が容易に発明をすることができたものである。

3 むすび
以上のとおり、本願発明は、引用発明、引用例2に記載された技術及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない。
したがって、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
よって、結論のとおり審決する。
 
審理終結日 2011-08-11 
結審通知日 2011-08-16 
審決日 2011-08-29 
出願番号 特願2007-101756(P2007-101756)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
最終処分 不成立  
前審関与審査官 ▲はま▼中 信行  
特許庁審判長 水野 恵雄
特許庁審判官 安久 司郎
中野 裕二
発明の名称 ウェッブページのHTMLデータを移動局におけるディスプレイに好適なフォーマットに変換する装置及び方法  
代理人 志賀 正武  
代理人 実広 信哉  
代理人 渡邊 隆  

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