• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06F
管理番号 1331792
審判番号 不服2016-9867  
総通号数 214 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-10-27 
種別 拒絶査定不服の審決 
審判請求日 2016-07-01 
確定日 2017-08-23 
事件の表示 特願2013-504304「高解像度およびあらゆる画面に適合するインターネットコンテンツ用HD-WEB方法」拒絶査定不服審判事件〔平成23年10月20日国際公開、WO2011/128528、平成25年 6月17日国内公表、特表2013-524375〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2011年4月12日を国際出願日とする出願(パリ条約による優先権主張2010年4月27日、フランス、2010年4月12日、フランス)であって、平成24年10月12日付けで、特許法第184条の4第1項の規定による国際出願日における国際特許出願の明細書、請求の範囲、図面(図面の中の説明に限る。)及び要約の日本語による翻訳文、及び同法第184条の4第2項の規定による特許協力条約第19条(1)の規定に基づく補正後の請求の範囲の翻訳文が提出され、平成27年2月18日付けで拒絶理由が通知され、平成27年7月24日付けで手続補正がされ、平成28年2月24日付けで拒絶査定がされ、これに対し、同年7月1日に拒絶査定不服審判が請求され、同時に手続補正がされたものである。


第2 平成28年7月1日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]

平成28年7月1日付けの手続補正を却下する。

[理由]
1.補正内容
平成28年7月1日付けの手続補正(以下、「本件補正」という。)は、補正前の請求項1を、補正後の請求項1に変更する補正事項を含むものである。

そして、補正前の請求項1に係る発明及び補正後の請求項1に係る発明は、それぞれ、以下のとおりである。(<補正後の請求項1>における下線は補正箇所を表す。)

<補正前の請求項1>
「 【請求項1】
インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示するクライアントとの間の対話の方法であって、
前記クライアントの前記表示画面における変動するサイズ又は変動する解像度を前記サーバに通知し、その通知に基づいて前記サーバにおいて、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法。」

<補正後の請求項1>
「 【請求項1】
インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示するクライアントとの間の対話の方法であって、
前記クライアントの前記表示画面におけるサイズ又は変動する解像度を予め前記サーバに格納しておき、前記クライアント上で表示される画面のサイズ又は解像度に対応して、事前に前記サーバ上で生成された前記コンテンツを用い、コンテンツがサーバから出力される前に、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法。」

2.補正の目的の適否について(主位的理由)
上記補正事項は、「前記クライアントの前記表示画面におけるサイズ又は変動する解像度を予め前記サーバに格納しておき」、との処理に係る補正事項(以下、「補正事項A」という。)を含んでいる。
上記補正事項Aは、要するに、クライアントの表示画面のサイズや解像度を、サーバに、予め「格納」しておく処理である。
一方、補正前の請求項1に記載されていた処理は、「前記クライアントの前記表示画面における変動するサイズ又は変動する解像度を前記サーバに通知し、その通知に基づいて」コンテンツを、動的に展開及び変更する処理、要するに、クライアントの表示画面の変動するサイズや解像度を、クライアントからサーバに「通知」する処理である。
ここで、クライアント、サーバ間の情報の「通知」と、サーバでの情報の「格納」とは異なる処理であるから、補正事項Aにおける、クライアントの表示画面のサイズや解像度を、サーバに予め「格納」しておくことが、補正前のクライアントの表示画面の変動するサイズや解像度を、クライアントがサーバに「通知」するという発明特定事項を、概念的により下位のものとするものとは認められない。
よって、補正事項Aは、特許法第17条の2第5項でいう「特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。)」を目的とするもの(第2号)に該当しない。
また、補正事項Aが、特許法第17条の2第5項でいう「請求項の削除」を目的とするもの(第1号)、「誤記の訂正」を目的とするもの(第3号)、「明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)」を目的とするもの(第4号)、のいずれにも該当しないことは明らかである。
したがって、本件補正は、特許法第17条の2第5項の規定に適合しない。

3.新規事項について(予備的理由その1)
上記補正事項のうち、補正事項Aについて、新規事項の有無を検討する。
補正事項Aの処理は、要するに、クライアントの表示画面のサイズや解像度を、サーバに、予め「格納」しておく処理である。この処理に関連する事項として、国際出願日における国際特許出願の明細書若しくは図面(図面の中の説明に限る。)の翻訳文、国際特許出願の請求の範囲の翻訳文(特許協力条約第19条(1)の規定に基づく補正後の請求の範囲の翻訳文が提出された場合にあっては当該翻訳文)又は国際特許出願の図面(図面の中の説明は除く。)(以下、「翻訳文等」という。)には、以下の事項が記載されている(下線は特に着目した箇所に対して当審が付与した。以下、同様。)。

(1) 特許請求の範囲
ア 【請求項1】-【請求項2】
「【請求項1】
インターネット、特にサービスまたはウェブサイト[2]からのコンテンツを配信するサーバーと、これらのコンテンツをナビゲーションインタフェースにて、画面、特に大型画面すなわち高解像度HD画面[3]上に表示するクライアントの間の対話方法であって、前記サーバー上に存在する方法が、コンテンツが表示される画面のサイズおよび解像度に比例してこれらのコンテンツを動的に展開および変更することを特徴とする方法。
【請求項2】
前記クライアントが使用した画面の解像度を前記サーバー[A/B]に返すこと、および、前記コンテンツの展開および変更が、リアルタイムかつ動的に、これらのコンテンツの寸法とコンテンツが表示される画面との比を維持する操作を実行することによって返される解像度に比例して行われることを特徴とする、請求項1に記載の方法。」

イ 【請求項3】
「【請求項3】
属性とはある要素の特性であり、要素とはあるウェブページ内のコンテンツの種類を定義する特性であるが、計算されこれらのコンテンツが表示される画面のサイズおよび解像度専用に再定義される新しい属性を生成することにより、前記コンテンツ、特にこれらのコンテンツの要素の属性を変更することから成るステップを含むことを特徴とする、請求項1に記載の方法。」

ウ 【請求項8】
「【請求項8】
これらのコンテンツの変更および置き換えが、同コンテンツが配信されるネットの伝送速度とは無関係に、その配信時にリアルタイムに行われるよう、これらのコンテンツの前記サーバー上および前記クライアントにおいて、前記コンテンツ、特に、変更および置き換えるべき前記コンテンツの要素の属性を収集し、保存し、メモリーおよびキャッシュにおいて生成することを特徴とする、請求項1から7のいずれか一項に記載の方法。」

(2) 詳細な説明
ア 段落【0003】の「注1」
「【0003】

・・・

(注1)1920×1080の解像度を意味する「fullHD(商標)」または「1080p」という用語および1366×720以上の解像度を意味する「HD」または「720p」という用語は商業用語であるので、我々は以下の文中においてはこれを区別しないこととする。本発明の第一の原則は、画面解像度の如何に関わらず、すなわち市場に存在する全ての画面サイズについて、ウェブサイトの適合性を確保することである。」

イ 段落【0009】
「【0009】
図2に原理を略図で示してある、本発明の独自性を有する方法は、HD-Web(商標)がブラウザーを介して、サービスおよび/またはウェブサイトが閲覧されるモニターの解像度に応じてどんなコンテンツを送信するかをサーバーにリアルタイムに知らせることを示している。」

ウ 段落【0022】-【0023】
「【0022】
このようにして本発明のために開発された技術的方法は、より解りやすくするために3つのカテゴリーに分類された:
1) 当該サービスまたはウェブサイトのページ内に存在する要素をクライアント側で選択的に回収し(ステップ1)、ある要素を形成する特性を属性とする時、要素の属性をメモリーに保存し(ステップ2)、その後、図4の表の増倍係数のいずれかを属性に適用し(ステップ3)、要素が表示される画面のサイズに従って要素のサイズをリサイズし(ステップ4)、最後にこれらの要素を、同一の要素であるが属性がこの新規サイズについて決められた要素に置き換える(ステップ5)ことを内容とする全ての技術的方法をまとめた第一カテゴリー。
2) パラメーター化可能な方法をクライアントが使用してあらかじめ決めた(ステップ0)画面サイズに従って行うリサイズに参加し(ステップ1)、次に、要素およびこのようにして生成された属性を、要素のカテゴリーおよび当該要素向けの画像サイズに応じて専用のファイルおよび/またはディレクトリー内にまとめる(ステップ2)ことを内容とするサーバー側の技術的方法をまとめた第二カテゴリー。
3) サーバー側にあるアプリケーションが、初期化というユニーク関数内にまとめられた(ステップ3)ユニーク変数内に各画面サイズをまとめる(ステップ2)ブール値を用いる関数を介してクライアント側にあるウェブブラウザーと通信できる(ステップ1)ようにする技術的方法をまとめた第三カテゴリー。
【0023】
次にこの関数は、ファイルが表示される画面のサイズに応じてどのファイルをブラウザーに送るべきかをリアルタイムで通信するために、いつでも呼び出すことができ、その結果、ウェブサーバーは、当該サービスまたはウェブサイトのページのロード時間を最適化するために、このサイズに対応するファイルだけを送信する。
同じカテゴリーに属するページの要素の全ての属性に対しこれらの方法がいったん適用されれば、当該サービスまたはウェブサイトのページのコンテンツにおいて定義されたその他のカテゴリーの要素の全ての属性についても、同一の方法を行うことができる。」

エ 段落【0024】-【0027】
「【0024】
用いられる技術的方法は要素が適用されるカテゴリーにより若干異なるため、我々は、前述したように各カテゴリーのそれぞれについて再度詳細に説明することはしないで、当該サービスまたはウェブサイトのページのコンテンツ外で定義された全てのカテゴリーの要素の属性全体を変更するのに用いられる包括的方法について説明することにする。
【0025】
これは、1024×768ピクセルの解像度に対して属性が定義された全てのファイルを見て(ステップ1)、図4の表で決められた増倍係数をこれらのファイルに適用する(ステップ2)が、サイズがcadratin(em)で定義されている時には市販のブラウザー間の精度の違いを考慮することを内容とする、第四カテゴリーおよび最後のカテゴリーに分類される技術的方法である。
- emとは、ピクセルとは異なり、ある書体を使用するブラウザーの書体および精度に依存する相対的単位である(図5)。
【0026】
次に、上で行ったように、こうして新規に定義された要素の属性が、対応するユニークディレクトリー、またはリネームされた後の同じディレクトリー内にまとめられ、生成され(ステップ3)、次に、第三カテゴリーに属する技術的方法により、我々のアプリケーションにより検出された画面解像度に従ってウェブサーバーから送信される(ステップ4)。
【0027】
最後に本方法の最終ステップ(ステップ5)により、動的に、すなわち元のファイルに何ら手を加えることなく、幅1024ピクセルの画面解像度について定義された要素の全ての属性、ならびに基準となる全ての要素が削除され、我々のアプリケーションによりサーバーに保存され、サービスまたはウェブサイトが現在表示されている画面解像度について定義された専用のファイルを呼び出す命令に置き換えられる(ステップ6)。」

(3) 特許請求の範囲について
前記(1)ア(【請求項1】-【請求項2】)には、「サーバー上に存在する方法」(【請求項1】)として、「クライアントが使用した画面の解像度」がサーバーに返されることによって、サーバーで「返される解像度に比例して」コンテンツが変更されることが記載されている。

前記(1)イ(【請求項3】)には、用語の定義として、「属性とはある要素の特性であり」、「要素とはあるウェブページ内のコンテンツの種類を定義する特性である」ことが記載されている。

前記(1)ウ(【請求項8】)には、変更するべきコンテンツの要素の属性を保存することが記載されている。

したがって、前記(1)ア-ウの記載から、「クライアントの解像度」を、クライアントからサーバーに通知することや、解像度が通知されると、サーバー側に保存された「要素の属性」を使用して、リアルタイムにコンテンツを変更することは記載されているが、「クライアントの解像度」をサーバー側に予め保存することについては、記載されていない。

(4) 詳細な説明について
前記(2)ア(段落【0003】の「注1」)から、本願明細書においては、「解像度」と「サイズ」とが、(当審注:より正確には、技術的に異なるが)、実質的に同じであると理解できる。

前記(2)イ(段落【0009】)には、解像度を、サーバーにリアルタイムに知らせることが記載されている。

前記(2)ウ(段落【0022】-【0023】)には、本発明の技術的手法は、以下の、3つのカテゴリーに分類されることが記載されている:
クライアント側での、リサイズ処理に関する「第一カテゴリー」、
サーバー側での、あらかじめ決めた「画面サイズに従って行う」リサイズのために、「要素および」「生成された属性を」、「画像サイズに応じて」ファイルか、ディレクトリーにまとめることに関する「第二カテゴリー」、
サーバー側アプリケーションが、画面のサイズを、クライアント側のウェブブラウザーとリアルタイムで通信する「第三カテゴリー」。

前記(2)エ(段落【0024】-【0027】)には、「第四カテゴリー」として、ブラウザー間の違いを考慮して増倍係数を適用すること、及び、包括的方法として、「新規に定義された要素の属性が、対応するユニークディレクトリー、またはリネームされた後の同じディレクトリー内にまとめられ」ること、その後、「第三カテゴリーに属する技術的方法により」「検出された画面解像度に従って」ウェブサーバーから送信されることが記載されている。

したがって、前記(2)ウの「第二カテゴリー」として、「画面サイズ」に対応したディレクトリーに、要素と属性を予め保存することが記載され、また、前記(2)ウの「第三カテゴリー」として、「クライアントの解像度」をリアルタイムで通知すること、(2)エの「第四カテゴリー」として、ブラウザー間の違いを考慮して増倍係数を適用することは記載されているが、「クライアントの表示画面のサイズや解像度」をサーバー側に予め保存することについては、記載されていない。
むしろ、記載上は一貫して、クライアントの表示画面の解像度は、サーバーにリアルタイムで通知されるから(段落【0009】等の記載参照。)、クライアントの表示画面のサイズや解像度をサーバー側に予め保存する処理は、このような明細書の記載とは整合しないと認められる。

(5) 以上から、前記(1)アーウ、(2)アーエのいずれも、補正事項Aに係る、「クライアントの表示画面のサイズや解像度」を、サーバーに、予め格納しておく処理を開示したものではないことは明らかである。

そして、翻訳文等の他の記載を参照しても、上記の点が自明な事項であるとも認められない。

したがって、補正事項1を含む本件補正は、翻訳文等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであり、翻訳文等に記載した事項の範囲内においてしたものではない。

したがって、本件補正は、特許法第184条の12第2項により読み替える同法第17条の2第3項に規定する要件を満たしていない。


4.独立特許要件について(予備的理由その2)
仮に、補正事項Aを含む本件補正が、限定的減縮を目的とするものであり、新規事項を含まないとしても、補正後の請求項1に係る発明は、特許出願の際独立して特許を受けることができるものとはいえない。

(1)本願補正発明
本件補正による補正後の請求項1に係る発明(以下、「本願補正発明」と呼ぶ。)は、上記1.の<補正後の請求項1>に記載されたとおりのものである。

(2)引用例、引用発明
原査定の拒絶の理由に引用された特開2006-331142号公報(以下、「引用例」と呼ぶ。)には、次の記載がある。

ア 段落【0006】-【0009】
「【0006】
ところで、現在、上述のようなコンテンツを表示することができる端末装置は、PC(Personal Computer)等に限られず、PDA(Personal Digital Assistant)や携帯電話機、STB(Set Top Box)に接続されたテレビ等、多種多様になってきている。これらの端末は、種類が異なれば画面解像度も異なる場合が多い。また、同一種類の端末であっても(例えば、PC等)、接続するディスプレイによって画面解像度が異なる場合がある。
【0007】
これに対し、従来、Webサーバにより提供されるコンテンツは、端末の種類や画面解像度の違いにかかわらず、表示形式が同一のコンテンツが提供されていたため、端末装置の画面解像度によっては必ずしも提供されたコンテンツを適切に表示することができないという問題があった。
【0008】
例えば、Webサーバで用意されるコンテンツが、800×600ピクセル(横方向の画素数が800、縦方向の画素数が600であることを示す。以下同様)の解像度を想定して作成されている場合、画面の解像度が640×480ピクセルの端末ではコンテンツ全体を一度に表示することができない。他方、画面の解像度が1280×1024ピクセルの端末ではコンテンツ全体を一度に表示することはできるのものの、コンテンツが小さく表示されるため、視覚的バランス、視認性等が悪くなる場合がある。
【0009】
このような問題を解決するための従来の方法としては、例えば、サーバ装置において画面解像度毎にコンテンツを用意し、端末装置の画面解像度に応じてコンテンツを提供する方法がある。」

イ 段落【0028】-【0032】
「【0028】
[1]第1実施形態
[1.1]第1実施形態の構成及び機能概要
先ず、本実施形態におけるWWWシステムSの構成及び機能について説明する。
【0029】
なお、図1は、第1実施形態に係るWWWシステムSの概要構成の一例を示す図である。
【0030】
図1に示すように、WWWシステムは、複数の端末装置T1、T2及びT3と、情報提供装置としてのWebサーバSAと、が、ネットワークNWに接続されている。
【0031】
各端末装置とWebサーバSAは、ネットワークNWを介して、例えば、通信プロトコルにTCP/IP(Transmission Control Protocol/Internet Protocol)を用いて、相互にデータの送受信が可能である。また、WebサーバSAは、各端末装置からの要求に応じてコンテンツデータを送信し、当該端末装置に表示させるようになっている。コンテンツデータの要求及び送信は、例えば、通信プロトコルにHTTP(Hypertext Transfer Protocol)を用いることにより実現される。
【0032】
なお、ネットワークNWは、例えば、インターネット、公衆回線網、移動体通信回線網、専用回線(例えば、CATV(Community Antenna Television))等を含んで構成されても良いし、ローカルエリアネットワーク等の単一のネットワークで構成されても良い。」

ウ 段落【0033】-【0040】
「【0033】
[1.1.1]WebサーバSAの構成及び機能等
次に、本実施形態におけるWebサーバSAの構成を説明する。
【0034】
なお、図2は、WebサーバSAの概要構成を示すブロック図である。
【0035】
図2に示すように、WebサーバSAは、CPU(Central Processing Unit)、RAM(Random Access Memory)、ROM(Read Only Memory)等を備える制御部11と、各種プログラム及びコンテンツデータ等の各種データを記憶する記憶部12(例えば、ハードディスク等)と、ネットワークNWと接続し、端末装置T1(T2及びT3についても同様)との通信状態を制御する通信部13と、を備え、バス14を介して相互に接続されている。
【0036】
制御部11は、CPUが、ROMまたは記憶部12に記憶された各種プログラム(例えば、情報提供プログラム等)を読み出し実行することにより、WebサーバSAを統括制御するとともに、本実施形態に係る解像度受信手段、コンテンツ生成手段、コンテンツ送信手段等として機能するようになっている。
【0037】
なお、情報提供プログラム等は、例えば、ネットワークNWを介して他のサーバからダウンロードされるようにしても良いし、CD-ROM等の記録媒体に記録されてドライブを介して読み込まれるようにしても良い。
【0038】
また、制御部11は、情報提供プログラムの実行により、端末装置T1からのコンテンツ要求を受信し、要求されたコンテンツデータの生成に先立ち、端末装置T1に対して解像度情報要求を送信する。これは、端末装置T1のCPUにより解釈実行されて解像度情報の取得と送信を行うための解像度取得プログラムを送信することにより行われるが、当該プログラムの詳細については後述する。
【0039】
そして、制御部11は、解像度情報を通信部13を介して受信し、当該解像度情報を引き継ぎづつ、後述するコンテンツ生成プログラムを実行することにより、コンテンツを生成、送信する。
【0040】
本実施形態において、制御部11が生成するコンテンツデータは、HTMLで記述され、記憶部12に記憶されている他のコンテンツデータ(例えば、文書、画像、動画、音声等)への参照(例えば、??等)を含むファイル(以下、HTMLファイルと称する。)である。なお、当該ファイルはHTMLで記述されたものに限らず、SGML(Standard Generalized Markup Language)、XML(eXtensible Markup Language)、XHTML(eXtensible Hypertext Markup Language)等のマークアップ言語で記述されたものであっても良い。」

エ 段落【0047】
「【0047】
図4は、計算情報ファイルの一例を示す図である。図4に示すように、計算情報ファイルは、例えば、?間に、プロパティを示すタグ名(例えば、fSはフォントサイズ。図3を参照)のタグに囲まれて、解像度情報からプロパティ値を計算するための計算方法が設定されている。例えば、「resV*1/80」は、画面解像度に1/80を乗算することによりフォントサイズが求められることを示している。ここで、resVは端末装置T1の横方向の画素数であり、resHは縦方向の画素数である。」

オ 段落【0053】
「【0053】
図5は、HTMLファイルの元となるHTMLオリジナルファイルの一例を示す図である。図5に示すように、HTMLオリジナルファイルは、JSP(Java(登録商標) Server Pages)と呼ばれるHTMLのデータを動的に生成するためのプログラミング言語で記述されたファイルであり、HTMLを直接記述することが可能であるとともに、Java(登録商標) コードを記述することも可能である。そして、コンテンツの要求に応じて、HTMLオリジナルファイルからサーブレットと呼ばれるコンテンツ生成プログラムが生成され、当該プログラムが実行されることによりHTMLファイルが生成されて、端末装置T1に送信される。このように、JSPに基づいて記述されたHTMLオリジナルファイルは端末装置T1に提供するHTMLファイルの元データとしての側面と、プログラムをコンパイルするソースとしての側面を有している。このようなプログラミング言語としてはJSPの他に、PHP(Hypertext Preprocessor)やASP(Active Server Pages)等がある。HTMLオリジナルファイルのパラメータ設定部において、制御部11は、受信した解像度情報を取得して、横の画素数をresVに、縦の画素数をresHに設定する。その後、例えば、DOM(Document Object Model)、SAX(Simple API for XML)等のAPI(Application Programming Interface)を用いて、計算情報ファイルをツリー構造として解析し、当該ファイルにおいて設定されている計算方法を取得する。そして、取得した計算方法により、プロパティを示すタグに対応したパラメータの値を計算する(なお、図5においては詳細なコードは省略している)。」

カ 段落【0059】-【0061】
「【0059】
[1.1.2]端末装置T1乃至T3の構成及び機能
次に、本実施形態における端末装置T1乃至T3の構成及び機能を説明する。
【0060】
端末装置T1乃至T3は、PC、PDA、携帯電話機、STBに接続されたテレビ等を適用することができる。
【0061】
端末装置T1の画面解像度は800×600ピクセル、端末装置T2の画面解像度は1280×1024ピクセル、端末装置T3の画面解像度は640×480ピクセルとなっている。なお、端末装置T1乃至T3は、画面解像度が異なるのみで、他の構成及び機能については同様であるので、以下、端末装置T1について説明する。」

キ 段落【0070】-【0083】
「【0070】
[1.1.2]情報提供システムSの動作
次に、本実施形態における情報提供システムSの動作を説明する。
【0071】
なお、図9は、第1実施形態に係る情報提供システムSにおける処理の流れの一例を示すシーケンス図である。
【0072】
図9に示すように、端末装置T1は、ブラウザプログラムを実行し、操作部25を介して指定されたURL(Uniform Resource Locator)が示すコンテンツの要求をWebサーバSAに送信する(ステップS1)。
【0073】
WebサーバSAは、コンテンツ要求を受信すると、解像度情報要求を端末装置T1に送信する(ステップS2)。これは、解像度取得プログラム(スクリプトを含むHTMLファイル)を送信することにより行われる。
【0074】
端末装置T1は、解像度取得プログラムを受信すると、解像度取得プログラムが解釈実行され、端末装置T1の画面の解像度(800×600ピクセル)を取得して(ステップS3)、WebサーバSAに送信する(ステップS4)。
【0075】
WebサーバSAは、解像度情報を受信すると、ステップS1において受信したURLが示すコンテンツを提供するため、HTMLオリジナルファイル(図5)を読込んでコンテンツ生成プログラムを生成する(ステップS5)。なお、一度、コンテンツ生成プログラムが生成された後は、同一URLに関して、このステップは省略される。
【0076】
そして、WebサーバSAは、コンテンツ生成プログラムを実行することにより、計算情報ファイル(図4)を読込み計算方法を取得する(ステップS6)。
【0077】
次いで、取得した解像度情報と計算方法により、プロパティを示すタグに対応したパラメータの値を計算して設定する(ステップS7)。その結果、フォントサイズは10ピクセル、ボックス外部の余白は13.3クセル、行間幅は40ピクセル、ボックスの横幅は400ピクセル、ボックスの縦幅は300ピクセルとなる。
【0078】
なお、端末装置がT2の場合は、夫々16ピクセル、21.3ピクセル、32ピクセル、640ピクセル、512ピクセルとなり、T3の場合は、夫々8ピクセル、10.6ピクセル、16ピクセル、320ピクセル、240ピクセルとなる。
【0079】
その後、WebサーバSAは、各タグのプロパティを設定して(ステップS8)、図6に示すHTMLファイルを生成する(ステップS9)。なお、端末装置がT2の場合は図10(a)に示すプロパティ定義部分が生成され、T3の場合は図10(b)に示すプロパティ定義部分が生成される。
【0080】
そして、WebサーバSAは、生成されたHTMLファイルを端末装置T1に送信する(ステップS10)。
【0081】
端末装置T1は、受信したHTMLファイルを解釈して表示部24に表示する(ステップS11)。なお、ここで、HTMLファイルに文書、画像データ等への参照が含まれている場合には、更に、これらのデータの要求をWebサーバSAに送信する。そして、サーバSAからデータが送信され、端末装置T1はこのデータを受信して、HTMLファイルとともに表示部24に表示する。
【0082】
図11は、端末装置T1乃至T3によるコンテンツデータの表示例を示す図であり、(a)は端末装置T1(画面解像度800×600ピクセル)による表示であり、(b)は端末装置T2(画面解像度1280×1024ピクセル)による表示であり、(c)は端末装置T3(画面解像度640×480ピクセル)による表示である。
【0083】
図11に示すように、端末装置の画面解像度が異なる場合であっても、コンテンツデータが適切に表示されるようになる。」

したがって、関連図面と技術常識に照らし、引用例には、次の発明(以下、「引用発明」という。)が記載されていると認められる。

「WWWシステムは、複数の端末装置T1、T2及びT3と、情報提供装置としてのWebサーバSAと、が、ネットワークNWに接続され、
WebサーバSAは、各端末装置からの要求に応じてコンテンツデータを送信し、当該端末装置に表示させるようになっており、
ネットワークNWは、インターネット等を含んで構成され、
WebサーバSAは、制御部11と、各種プログラム及びコンテンツデータ等の各種データを記憶する記憶部12と、通信部13と、を備え、
制御部11は、解像度情報を通信部13を介して受信し、当該解像度情報を引き継ぎ、後述するコンテンツ生成プログラムを実行することにより、コンテンツを生成、送信し、
制御部11が生成するコンテンツデータは、HTMLで記述され、記憶部12に記憶されている他のコンテンツデータ(例えば、文書、画像、動画、音声等)への参照(例えば、??等)を含むHTMLファイルであり、
計算情報ファイルは、解像度情報からプロパティ値を計算するための計算方法が設定されており、例えば、「resV*1/80」は、画面解像度に1/80を乗算することによりフォントサイズが求められることを示しており、ここで、resVは端末装置T1の横方向の画素数であり、
HTMLオリジナルファイルは、JSPと呼ばれるHTMLのデータを動的に生成するためのプログラミング言語で記述されたファイルであり、HTMLを直接記述することが可能であるとともに、Java コードを記述することも可能であり、
端末装置T1乃至T3は、PC、PDA、携帯電話機、STBに接続されたテレビ等を適用することができ、端末装置T1乃至T3は、画面解像度が、端末装置T1は、画面解像度800×600ピクセル、端末装置T2は、画面解像度1280×1024ピクセル、端末装置T3は、画面解像度640×480ピクセルと異なるのみで、他の構成及び機能については同様であり、

端末装置T1の場合、
端末装置T1は、ブラウザプログラムを実行し、操作部25を介して指定されたURLが示すコンテンツの要求をWebサーバSAに送信し(ステップS1)、
WebサーバSAは、コンテンツ要求を受信すると、解像度情報要求を端末装置T1に送信し(ステップS2)、これは、解像度取得プログラム(スクリプトを含むHTMLファイル)を送信することにより行われ、
端末装置T1は、解像度取得プログラムを受信すると、解像度取得プログラムが解釈実行され、端末装置T1の画面の解像度(800×600ピクセル)を取得して(ステップS3)、WebサーバSAに送信し(ステップS4)、
WebサーバSAは、解像度情報を受信すると、ステップS1において受信したURLが示すコンテンツを提供するため、HTMLオリジナルファイルを読込んでコンテンツ生成プログラムを生成し(ステップS5)、
そして、WebサーバSAは、コンテンツ生成プログラムを実行することにより、計算情報ファイルを読込み計算方法を取得し(ステップS6)、
次いで、取得した解像度情報と計算方法により、プロパティを示すタグに対応したパラメータの値を計算して設定し(ステップS7)、
その後、WebサーバSAは、各タグのプロパティを設定して(ステップS8)、HTMLファイルを生成し(ステップS9)、
そして、WebサーバSAは、生成されたHTMLファイルを端末装置T1に送信し(ステップS10)、
端末装置T1は、受信したHTMLファイルを解釈して表示部24に表示し(ステップS11)、なお、ここで、HTMLファイルに文書、画像データ等への参照が含まれている場合には、更に、これらのデータの要求をWebサーバSAに送信し、そして、サーバSAからデータが送信され、端末装置T1はこのデータを受信して、HTMLファイルとともに表示部24に表示する、
方法。」

(3)[周知文献A] 特開2010-61542号公報
ア [周知文献A]には、以下の記載がある。
(ア) 段落【0036】
「解像度検出部33は、通信端末2で設定される解像度(例えば、1024×768ピクセル)を検出する。通信端末2の解像度は、入力部23を介して変更することができる。この解像度の変更は、例えば、パーソナルコンピュータ装置等を操作するユーザによって行うことも可能である。・・・」

(イ) 段落【0038】
「・・・(1)ウェブサイトにアクセスしている途中で、ユーザがブラウザのサイズを変更する場合。・・・(中略)・・・(3)画面の解像度が変更になった場合。この場合は、情報処理速度も変化する可能性がある。なお、ユーザが意図的に画面の解像度を変更する場合も、通信速度や情報処理速度が変わる可能性がある。」

イ また、[周知文献A]には、以下の記載がある。
(ア) 段落【0007】-【0011】
「また、特許文献2には、端末が表示できる表示領域や通信速度によって、画像サイズや圧縮率を変換する技術について開示されている。この技術では、送信する広告データを保持する端末データベースの情報から、画像サイズ、データ形式を変更し、通信速度に基づいて、画像サイズや圧縮率を変更している。・・・(中略)・・・【特許文献2】特開2003-167817号公報・・・」

(イ) 段落【0097】
「第2の実施の形態例において、サーバ4は、圧縮を行ったり、画像サイズを変更したりする処理を施した画像をメモリに一旦蓄える。その後、通信端末2から類似した条件の送信要求があった際に、その都度、圧縮などの処理を行わずにメモリにアクセスして、送信することが可能である。そして、画像サイズを変換する際に、画面の解像度だけではなく表示領域情報を使用して変換するサイズを決定する。」

(ウ) 段落【0114】
「以上説明した第2の実施の形態例によれば、HTMLなどを変更した場合と画像を圧縮した場合は、通信端末2の通信速度などの情報、時刻と共に、メモリ42に保存する。そして、類似した条件でウェブサイトにアクセスされた場合、メモリ42に保存した画像やHTMLを読み出して用いることにより、サーバ4の処理を減らすことができるという効果がある。」

(4)[周知文献B] 特開2006-236323号公報
ア [周知文献B]には、以下の記載がある。
(ア) 【図8】
図8には、機器名「E」は、解像度「720×480」と「1920×1080」であり、機器名「F」は、解像度「340×340」と「340×480」であることが記載されている。

(イ) 段落【0026】
「ここで、AV機器20の表示モニタ装置にGUIを実現するために必要なデータは、GUI画面に表示するために用いられる画像データからなるイメージデータ(イメージA)と、メニューやボタンなどのGUIコンポーネントの配置情報などを含む、AV機器20の表示モニタ装置に対する表示や入力に関連するデータ、すなわち、GUIに関するリソースデータ(リソースA)である。また、イメージデータとリソースデータは、クライアント17で実行されるアプリケーションプログラムにより、GUIを実現するために参照されるデータである。」

(ウ) 段落【0059】
「ここで、変換の他のバリエーションについて説明する。リソースデータに関連しては、例えば、表示モニタ部や表示モニタ装置のサイズ(解像度)の違いによって、フォントの大きさを変更する。また、アプリケーションの送信先であるクライアント17においてカラーモデルが異なる場合は、この違いに対応すべく変換がなされる。」

(エ) 段落【0093】
「機器Eと機器Fで示されるクライアント17は、表示モニタ部(表示モニタ装置)が2つの解像度を有し、プロファイルデータは、こうした2つの情報をサーバ10に伝えることができるようにも構成される。また、機器Eで示されるクライアント17は、それぞれの解像度に関して表示色数が異なる。プロファイルデータでは、このような状況もサーバ10に伝えることができる。」

イ また、[周知文献B]には、段落【0084】-【0088】に、以下の記載がある。
「また、この例では、サーバ10が、クライアント17からプロファイルデータを受信するたびにリソースデータおよびイメージデータを変換しているが、これはこの例に限定されない。例えば、サーバ10にアクセスするクライアント17の機器の種類が所定の範囲内であることが、あらかじめ分かっているような場合には、事前にリソースデータとイメージデータを、想定されるプロファイルデータに応じて変換しておくように構成することもできる。このように構成した場合は、サーバ10のハードウエア資源がより多く必要になる反面、クライアント17に対して、より早くリソースデータおよびイメージデータを提供することができる。この場合、サーバ10は、機器ごとに、かつアプリケーションごとに、必要なリソースデータとイメージデータを記録しておくテーブルが必要になる。
・・・(中略)・・・
またさらに、クライアント17の機種によってプロファイルデータがほとんど固定される場合は、サーバ10が、事前に各機器のプロファイルデータを有しておくことにより、それぞれのクライアント17は、ユーザから所定のアプリケーションの選択があった場合に、そのアプリケーションに対応するアプリケーションIDのみをサーバ10に送信すればよいことになる。この場合、サーバ10は、機器ごとに、プロファイルデータを記憶しておくテーブルが必要となる。
図8は、クライアント17がサーバ10に送信するプロファイルデータの例を示したものである。この例では、クライアント17には、機器A?機器Eの6つの機種が存在する。プロファイルデータは、機種ごとに、機器名、解像度、出力デバイス、色、CPU、メモリ、入力手段の各項目を含んでいる。
解像度は、その機器が備える表示モニタ部またはその機器に接続される表示モニタ装置の解像度(画素数)を表しており、この値が大きいほど、大きなGUIの表現が可能となる。この図8の例では、解像度は、「横方向の表示画素数×縦方向の表示画素数」の形式で記述される。横方向の表示画素数および縦方向の表示画素数を、互いの最大公約数で除することで、アスペクト比を求めることができる。」

(5) [周知文献C] 特表2008-535098号公報
[周知文献C]には、段落【0032】-【0033】に、以下の記載がある。
「その後、複数解像度イメージデータは、好ましくはクライアントデバイス230に送信され326、そこで表示される328。この実施形態では、プロキシサーバ150による、ウェブページとすることのできるインターネットサイトへのアクセス322、およびクライアントデバイス230による複数解像度イメージデータのナビゲーションは、実質的に同時に発生することができる。したがって、この実施形態では、ウェブページ(または他のタイプの)イメージデータの変換324は、クライアントデバイス230によって行われるナビゲーション330に応答して、実質的に「オンザフライ」で行われる。ナビゲーション330には、クライアントデバイス230によるパンおよびズームを含めることができるが、これに限定はされない。
もう1つの実施形態で、プロキシサーバは、1つまたは複数のウェブページ全体あるいは他の形のインターネットイメージデータを、複数解像度イメージデータに変換しまたは「事前変換し」、変換されたデータを、クライアントデバイス230による迅速なアクセス可能性およびクライアントデバイス230への送信のためにプロキシサーバ150にアクセス可能なキャッシュ160または他のメモリデバイスに格納することができる。この事前変換は、関係するウェブページデータがクライアントデバイス230のナビゲーション330コマンドに応答して必要になる前に実行することができる。」

(6)対比
ア 引用発明の「WebサーバSA」は、「インターネット等を含んで構成され」る「ネットワークNWに接続され」、「HTMLファイル」すなわち「コンテンツデータ」を生成して、「生成されたHTMLファイルを端末装置T1に送信」するから、本願補正発明の「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバ」に相当する。

引用発明の「端末装置T1、T2及びT3」は、「ブラウザプログラムを実行し、操作部25を介して指定されたURLが示すコンテンツの要求をWebサーバSAに送信し(ステップS1)」、「端末装置T1の画面の解像度(800×600ピクセル)を取得して(ステップS3)、WebサーバSAに送信し(ステップS4)」、「受信したHTMLファイルを解釈して表示部24に表示し(ステップS11)」ているから、本願補正発明の「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示するクライアント」と、「ブラウザインタフェース内のコンテンツを、所定のサイズ又は所定の解像度の表示画面上に表示するクライアント」である点で共通するといえる。

引用発明の「WebサーバSAは、各端末装置からの要求に応じてコンテンツデータを送信」する方法は、「対話の方法」といえる。

よって、引用発明の「WebサーバSAは、各端末装置からの要求に応じてコンテンツデータを送信」する方法は、本願補正発明の「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示するクライアントとの間の対話の方法」と、「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、所定のサイズ又は所定の解像度の表示画面上に表示するクライアントとの間の対話の方法」である点で共通するといえる。

イ 引用発明の端末装置T1、T2及びT3についての、「画面解像度800×600ピクセル」、「画面解像度1280×1024ピクセル」、「画面解像度640×480ピクセル」は、本願補正発明の「クライアント上で表示される画面のサイズ又は解像度」に相当する。
引用発明の「HTMLオリジナルファイル」は、「JSPと呼ばれるHTMLのデータを動的に生成するためのプログラミング言語で記述されたファイル」である。
引用発明の「計算情報ファイル」は、「解像度情報からプロパティ値を計算するための計算方法が設定されており、例えば、「resV*1/80」は、画面解像度に1/80を乗算することによりフォントサイズが求められることを示して」いるファイルである。よって、引用発明の画像解像度とフォントサイズとは、「比例して」いるといえる。
引用発明の「ステップS10」において、「そして、WebサーバSAは、生成されたHTMLファイルを端末装置T1に送信し(ステップS10)」ているから、ステップS10より前の「ステップS9」までが、「HTMLファイル」すなわち「コンテンツがサーバから出力される前に」、実行されるステップであることは、明らかであるといえる。
引用発明の「HTMLファイル」等に対するファイル処理を行う前提として、ファイルを開いている、すなわち、「展開」していることは、明らかであるといえる。
よって、引用発明における「WebサーバSAは、解像度情報を受信すると、ステップS1において受信したURLが示すコンテンツを提供するため、HTMLオリジナルファイルを読込んでコンテンツ生成プログラムを生成し(ステップS5)、
WebサーバSAは、コンテンツ生成プログラムを実行することにより、計算情報ファイルを読込み計算方法を取得し(ステップS6)、
次いで、取得した解像度情報と計算方法により、プロパティを示すタグに対応したパラメータの値を計算して設定し(ステップS7)、
その後、WebサーバSAは、各タグのプロパティを設定して(ステップS8)、HTMLファイルを生成し(ステップS9)」ているステップは、本願補正発明の「前記クライアントの前記表示画面におけるサイズ又は変動する解像度を予め前記サーバに格納しておき、前記クライアント上で表示される画面のサイズ又は解像度に対応して、事前に前記サーバ上で生成された前記コンテンツを用い、コンテンツがサーバから出力される前に、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法」と、「前記クライアント上で表示される画面のサイズ又は解像度に対応して、前記サーバ上で生成された前記コンテンツを用い、コンテンツがサーバから出力される前に、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法」である点で共通するといえる。

したがって、本願補正発明と引用発明の間には、次の一致点、相違点があるといえる。

[一致点]
「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、所定のサイズ又は所定の解像度の表示画面上に表示するクライアントとの間の対話の方法であって、
前記クライアント上で表示される画面のサイズ又は解像度に対応して、前記サーバ上で生成された前記コンテンツを用い、コンテンツがサーバから出力される前に、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法。」である点。

[相違点1]
本願補正発明の「クライアント」は、「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示する」のに対し、引用発明の端末装置T1、T2、T3は、画面解像度800×600ピクセル、1280×1024ピクセル、640×480ピクセルと異なるものであるが、表示画面のサイズ又は解像度が「変動する」ものであることは、特定がなされていない点。

[相違点2]
本願補正発明では、「前記クライアントの前記表示画面におけるサイズ又は変動する解像度を予め前記サーバに格納しておき」、前記クライアント上で表示される画面のサイズ又は解像度に対応して、「事前に」前記サーバ上で生成された前記コンテンツを用い、コンテンツがサーバから出力される前に、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更するのに対して、引用発明では、「前記クライアントの前記表示画面におけるサイズ又は変動する解像度を予め前記サーバに格納しておき」、また、「事前に」前記サーバ上で生成された前記コンテンツを用い、コンテンツを展開及び変更することは、特定がなされていない点。

(7)判断
[相違点1]について
パソコンなどの端末装置において、例えば、ユーザが画面のウインドウの設定サイズを変えたり、接続するディスプレイ装置を交換することによって、表示画面のサイズや解像度を変更可能にすることは、[引用例](上記(2)ア、段落【0006】「これらの端末は、種類が異なれば画面解像度も異なる場合が多い。また、同一種類の端末であっても(例えば、PC等)、接続するディスプレイによって画面解像度が異なる場合がある。」の記載を参照。)、及び、[周知文献A](上記(3)ア)、[周知文献B](上記(4)ア)に記載されるように周知技術である。

よって、引用発明の端末装置T1-T3において、表示の見やすさなどの周知の課題を考慮して、表示画面のサイズや解像度を変更可能にする周知技術を適用することによって、「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示する」、上記[相違点1]に係る構成とすることは、当業者が容易に想到し得ることである。

なお、そもそも、引用発明の端末装置T1-T3は、具体的には、「PC」等であり、通常、「PC」には、様々なサイズ、解像度のディスプレイ装置を接続できる以上、当業者であれば、引用発明の端末装置T1-T3は、「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示する」ものであると理解するのが自然であるともいえる。

[相違点2]について
一般に、サーバ側で、クライアント端末の画面サイズなど各種の端末に関する情報を予め有するように構成することは、[周知文献A](上記(3)イ(ア)「端末データベースの情報から、画像サイズ…を変更し…」)、[周知文献B](上記(4)イ「…この場合、サーバ10は、機器ごとに、プロファイルデータを記憶しておくテーブルが必要となる。図8は、クライアント17がサーバ10に送信するプロファイルデータの例を示したものである。この例では、クライアント17には、機器A?機器Eの6つの機種が存在する。プロファイルデータは、機種ごとに、機器名、解像度、出力デバイス、色、CPU、メモリ、入力手段の各項目を含んでいる。」)に記載されるように、周知技術である。
また、一般に、情報処理の負担軽減や高速化などのために、情報処理に用いるデータを、事前に生成して格納しておくことは、[周知文献A](上記(3)イ)、[周知文献B](上記(4)イ)、及び、[周知文献C](上記(5))に記載されるように、周知技術である。

よって、引用発明のWebサーバSAにおいて、情報処理の負担軽減や高速化などの周知の課題のために、サーバ側で、端末の画面サイズなどの各種の端末に関する情報を予め有するように構成する周知技術、及び、情報処理に用いるデータを、事前に生成して格納しておく周知技術を適用することによって、クライアント上で表示される画面のサイズ又は解像度を通信することに替えて、「前記クライアントの前記表示画面におけるサイズ又は変動する解像度を予め前記サーバに格納しておき」、また、コンテンツ処理において、「事前に」前記サーバ上で生成された前記コンテンツを用いることで、上記[相違点2]に係る構成とすることは、当業者が容易に想到し得ることである。

そして、本願補正発明のように構成したことによる効果も、引用発明及び周知技術に基づいて、当業者が予測し得る範囲内のものである。

(5)まとめ
以上のとおりであるから、本願補正発明は、引用発明に基づいて当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。

5.むすび
上記2.で検討したとおり、本件補正は、特許法第17条の2第5項に違反するものである。
仮にそうでないとしても(本件補正が限定的減縮を目的とするものであったとしても)、上記3.で検討したとおり、本件補正は、特許法第184条の12第2項により読み替える同法第17条の2第3項に違反するものである。
仮にそうでないとしても、本願補正発明は、上記4.で検討したとおり、特許出願の際独立して特許を受けることができないものであるから、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するものである。
したがって、いずれにしても本件補正は、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。


第3 本願について
1.本願発明
本件補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」と呼ぶ。)は、平成27年7月24日付けの手続補正書の請求項1に記載されたとおりのものであり、上記「第2」の「1.」の<補正前の請求項1>に記載されたとおりのものである。

2.引用例 、引用発明
原査定の拒絶の理由に引用された引用例、引用発明は、上記「第2」の「4.」(2)に記載したとおりである。

3.対比・判断
(1) 対比
ア 引用発明の「WebサーバSA」は、「インターネット等を含んで構成され」る「ネットワークNWに接続され」、「HTMLファイル」すなわち「コンテンツデータ」を生成して、「生成されたHTMLファイルを端末装置T1に送信」するから、本願発明の「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバ」に相当する。

引用発明の「端末装置T1、T2及びT3」は、「ブラウザプログラムを実行し、操作部25を介して指定されたURLが示すコンテンツの要求をWebサーバSAに送信し(ステップS1)」、「端末装置T1の画面の解像度(800×600ピクセル)を取得して(ステップS3)、WebサーバSAに送信し(ステップS4)」、「受信したHTMLファイルを解釈して表示部24に表示し(ステップS11)」ているから、本願発明の「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示するクライアント」と、「ブラウザインタフェース内のコンテンツを、所定のサイズ又は所定の解像度の表示画面上に表示するクライアント」である点で共通するといえる。

引用発明の「WebサーバSAは、各端末装置からの要求に応じてコンテンツデータを送信」する方法は、「対話の方法」といえる。

よって、引用発明の「WebサーバSAは、各端末装置からの要求に応じてコンテンツデータを送信」する方法は、本願発明の「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示するクライアントとの間の対話の方法」と、「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、所定のサイズ又は所定の解像度の表示画面上に表示するクライアントとの間の対話の方法」である点で共通するといえる。

イ 引用発明の端末装置T1、T2及びT3についての、「画面解像度800×600ピクセル」、「画面解像度1280×1024ピクセル」、「画面解像度640×480ピクセル」は、本願発明の「クライアント上で表示される画面のサイズ又は解像度」に相当する。
よって、引用発明における「端末装置T1の画面の解像度(800×600ピクセル)を取得して(ステップS3)、WebサーバSAに送信し(ステップS4)」ているステップは、本願発明において、「前記クライアントの前記表示画面における変動するサイズ又は変動する解像度を前記サーバに通知し」ていることと、「前記クライアントの前記表示画面における所定のサイズ又は所定の解像度を前記サーバに通知し」ている点で共通するといえる。

ウ 引用発明の「HTMLオリジナルファイル」は、「JSPと呼ばれるHTMLのデータを動的に生成するためのプログラミング言語で記述されたファイル」である。
引用発明の「計算情報ファイル」は、「解像度情報からプロパティ値を計算するための計算方法が設定されており、例えば、「resV*1/80」は、画面解像度に1/80を乗算することによりフォントサイズが求められることを示して」いるファイルである。よって、引用発明の画像解像度とフォントサイズとは、「比例して」いるといえる。
引用発明の「HTMLファイル」等に対するファイル処理を行う前提として、ファイルを開いている、すなわち、「展開」していることは、明らかであるといえる。
よって、引用発明における「WebサーバSAは、解像度情報を受信すると、ステップS1において受信したURLが示すコンテンツを提供するため、HTMLオリジナルファイルを読込んでコンテンツ生成プログラムを生成し(ステップS5)、
WebサーバSAは、コンテンツ生成プログラムを実行することにより、計算情報ファイルを読込み計算方法を取得し(ステップS6)、
次いで、取得した解像度情報と計算方法により、プロパティを示すタグに対応したパラメータの値を計算して設定し(ステップS7)、
その後、WebサーバSAは、各タグのプロパティを設定して(ステップS8)、HTMLファイルを生成し(ステップS9)」ているステップは、本願発明の「その通知に基づいて前記サーバにおいて、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法」に相当する。

したがって、本願発明と引用発明の間には、次の一致点、相違点があるとえいる。

[一致点]
「インターネット上でサービスまたはウェブサイトなどのコンテンツを送信するサーバと、ブラウザインタフェース内のコンテンツを、所定のサイズ又は所定の解像度の表示画面上に表示するクライアントとの間の対話の方法であって、
前記クライアントの前記表示画面における所定のサイズ又は所定の解像度を前記サーバに通知し、その通知に基づいて前記サーバにおいて、前記コンテンツを前記クライアント上で表示される画面のサイズ又は解像度に比例して、動的に展開及び変更する方法。」である点。

[相違点A]
本願発明の「クライアント」は、「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示する」ものであって、「前記クライアントの前記表示画面における変動するサイズ又は変動する解像度を前記サーバに通知し」ているのに対して、引用発明の端末装置T1、T2、T3は、画面解像度800×600ピクセル、1280×1024ピクセル、640×480ピクセルと異なるものであるが、表示画面のサイズ又は解像度が「変動する」ものであることについては、特定がなされていない点。

(2)判断
[相違点A]について
パソコンなどの端末装置において、例えば、ユーザが画面のウインドウの設定サイズを変えたり、接続するディスプレイ装置を交換することによって、表示画面のサイズや解像度を変更可能にすることは、[引用例](上記(2)ア、段落【0006】「これらの端末は、種類が異なれば画面解像度も異なる場合が多い。また、同一種類の端末であっても(例えば、PC等)、接続するディスプレイによって画面解像度が異なる場合がある。」の記載を参照。)、及び、[周知文献A](上記(3)ア)、[周知文献B](上記(4)ア)に記載されるように周知技術である。

よって、引用発明の端末装置T1-T3において、表示の見やすさなどの周知の課題を考慮して、表示画面のサイズや解像度を変更可能にする周知技術を適用することによって、「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示する」ものであって、「前記クライアントの前記表示画面における変動するサイズ又は変動する解像度を前記サーバに通知し」ている、上記[相違点A]に係る構成とすることは、当業者が容易に想到し得ることである。

なお、そもそも、引用発明の端末装置T1-T3は、具体的には、「PC」等であり、通常、「PC」には、様々なサイズ、解像度のディスプレイ装置を接続できる以上、当業者であれば、引用発明の端末装置T1-T3は、「ブラウザインタフェース内のコンテンツを、変動するサイズ又は変動する解像度の表示画面上に表示する」ものであって、「前記クライアントの前記表示画面における変動するサイズ又は変動する解像度を前記サーバに通知し」ていると理解するのが自然であるともいえる。

そして、本願発明のように構成したことによる効果も、引用発明及び周知技術に基づいて、当業者が予測できる範囲内のものである。


5.むすび
以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第29条第2項の規定により特許を受けることができない。したがって、本願は、他の請求項について論及するまでもなく、拒絶されるべきものである。
よって、結論のとおり審決する。
 
審理終結日 2017-03-23 
結審通知日 2017-03-28 
審決日 2017-04-10 
出願番号 特願2013-504304(P2013-504304)
審決分類 P 1 8・ 572- Z (G06F)
P 1 8・ 575- Z (G06F)
P 1 8・ 561- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 小林 義晴  
特許庁審判長 高瀬 勤
特許庁審判官 稲葉 和生
山田 正文
発明の名称 高解像度およびあらゆる画面に適合するインターネットコンテンツ用HD-WEB方法  
代理人 新保 斉  

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