【事件の表示】
　特願２００７−　５６０５５「双方向コンテンツ表示システム及び方法」拒絶査定不服審判事件〔平成２０年　９月１８日出願公開、特開２００８−２１７５８７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成１９年３月６日を出願日とするものであって、平成２４年５月１４日付けで拒絶査定がなされ、それに対して同年８月１４日に拒絶査定不服の審判請求がなされるとともに手続補正書が提出されたものである。
　　
第２　平成２４年８月１４日付けの手続補正の補正却下の決定
［補正却下の決定の結論］
　平成２４年８月１４日付けの手続補正（以下、「本件補正」という。）を却下する。
　　
［理由］
（１）補正後の本願発明
　本件補正により、少なくとも特許請求の範囲の請求項４は次のように補正された。
「ＸＭＬサーバーと、第１のＸＭＬコンテンツ表示部を備えた第１のＳＩＰ（Session Initiate Protocol）端末と、第２のＸＭＬコンテンツ表示部を備え、前記第１のＳＩＰ端末に通信ネットワークを介して接続された第２のＳＩＰ端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、
　前記双方向コンテンツ表示制御処理ステップは、
　前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記第２のＳＩＰ端末に問い合わせを送信するステップと、
　前記問い合わせに応じて、前記ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス情報を前記第２のＳＩＰ端末から前記第１のＳＩＰ端末に通知するステップと、
　通知された前記ＸＭＬコンテンツのアドレス情報に基づいて前記第１のＳＩＰ端末が前記ＸＭＬサーバーから前記ＸＭＬコンテンツを取得し、取得した前記ＸＭＬコンテンツの一部情報を画面表示するステップと
　を有することを特徴とする双方向コンテンツ表示方法。」
　　
（２）補正の可否の検討
　本件補正前の請求項４は、
「ＸＭＬサーバーと、第１のＸＭＬコンテンツ表示部を備えた第１のＳＩＰ（Session Initiate Protocol）端末と、第２のＸＭＬコンテンツ表示部を備え、前記第１のＳＩＰ端末に通信ネットワークを介して接続された第２のＳＩＰ端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、
　前記双方向コンテンツ表示制御処理ステップは、
　前記第１のＳＩＰ端末側にて、前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第２のＳＩＰ端末に送信するステップと、
　前記第２のＳＩＰ端末側にて、前記ＸＭＬコンテンツのアドレス情報を受け前記ＸＭＬサーバーから前記ＸＭＬコンテンツを取得し、取得した前記ＸＭＬコンテンツの一部情報を画面表示させるステップ
　を有することを特徴とする双方向コンテンツ表示方法。」である。
　そうすると、本件補正後の請求項４は、補正前の請求項４に存在した「前記第１のＳＩＰ端末側にて、前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第２のＳＩＰ端末に送信するステップ」と「前記第２のＳＩＰ端末側にて、前記ＸＭＬコンテンツのアドレス情報を受け前記ＸＭＬサーバーから前記ＸＭＬコンテンツを取得し、取得した前記ＸＭＬコンテンツの一部情報を画面表示させるステップ」を有してなく、補正前の請求項４にはなかった「前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記第２のＳＩＰ端末に問い合わせを送信するステップ」と「前記問い合わせに応じて、前記ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス情報を前記第２のＳＩＰ端末から前記第１のＳＩＰ端末に通知するステップ」を有するものとなっている。
　このような補正を含む本件補正は、特許法第１７条の２第４項第２号に規定する特許請求の範囲の減縮には該当しない。
　また、この補正は、同条同項１号、３号、４号のいずれに規定する補正目的にも該当しない。
　　
（３）むすび
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明
　本件補正は、上記のとおり却下されたので、本願の請求項４に係る発明（以下、「本願発明」という。）は、平成２３年１１月１６日付けの手続補正書により補正された特許請求の範囲の請求項４に記載された事項により特定される、以下のものである。
「ＸＭＬサーバーと、第１のＸＭＬコンテンツ表示部を備えた第１のＳＩＰ（Session Initiate Protocol）端末と、第２のＸＭＬコンテンツ表示部を備え、前記第１のＳＩＰ端末に通信ネットワークを介して接続された第２のＳＩＰ端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、
　前記双方向コンテンツ表示制御処理ステップは、
　前記第１のＳＩＰ端末側にて、前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第２のＳＩＰ端末に送信するステップと、
　前記第２のＳＩＰ端末側にて、前記ＸＭＬコンテンツのアドレス情報を受け前記ＸＭＬサーバーから前記ＸＭＬコンテンツを取得し、取得した前記ＸＭＬコンテンツの一部情報を画面表示させるステップ
を有することを特徴とする双方向コンテンツ表示方法。」
　
第４　引用文献
（１）原査定の拒絶の理由に引用された特開２００５−２０６４７号公報（以下、「引用文献１」という。）には、図面と共に次の事項が記載されている。
（ア）「【００２４】
図１は本発明を採用したＩＰ電話機能およびＷＥＢブラウザ機能を有する通信端末の構成を示している。図１において、符号１００は、情報端末２００が接続されるＩＰ網（いわゆるインターネットの他に、イントラネットのように閉じた網も考えられるが、以下では特に区別する必要がある場合を除きインターネット網という）で、有線回線１０１を介して接続される。本実施形態では、有線回線１０１としてはＡＤＳＬであるものとし、図１の情報端末の回線はスプリッタ１０２によりＰＳＴＮ網用の帯域１０４と、ＡＤＳＬ網用の帯域１０３を分割して使用する。
【００２５】
情報端末２００は、ＰＳＴＮ接続による音声通信（たとえば通話およびファクシミリ）が可能であるとともに、インターネット接続（ＰＰＰｏＥなどのＡＤＳＬ接続方式が用いられる）、およびインターネット上の資源の利用（本実施形態の場合、少なくともＩＰ電話の他にＷＥＢページ閲覧、Ｅメール送受信など）が可能である。
【００２６】
なお、ＩＰ網１００への接続は、ＡＤＳＬである必要はなく光ファイバー回線や、ＣＡＴＶ回線、無線回線など任意の回線メディアを用いることができる。
・・・中略・・・
また、操作部２１５には、特にリソース転送ボタン２１５ａおよびスクロールキー２１５ｂが設けられている。リソース転送ボタン２１５ａは、本端末どうしでＩＰ電話中にインターネットリソースを共有利用することを指定するためユーザが押下する。スクロールキー２１５ｂは、後述のＷＥＢページの表示画面をスクロールさせるために用いられる他、メニューユーザーインターフェースなどにおいてはアイテム選択などに用いられる。
・・・中略・・・
すなわち、ＣＰＵ２０１はＲＯＭ２０２に格納されたプログラムにしたがって全体を制御し、網への接続や、各種プロトコルを制御し処理を実行する。もちろんＣＰＵ２０１の制御には操作、表示、読み取り、記録に使用する制御も含まれる。
【００３２】
さらに、ブロードバンド接続に関する制御や、ＩＰ電話を実現するための制御、ＷＥＢアクセスを行なうための制御、ＷＥＢページを表示するためのブラウザ制御、また、ＩＰアドレスの検知、抽出制御、そして、ＵＲＬ等のデータを送信するためのファイル作成や、送受信制御を実行する。」（段落【００２４】〜【００３２】）
　　　
（イ）「【００６７】
本実施形態のＩＰ電話通信では、ＳＩＰ方式を用いる。ここで発呼側が通信端末２００、着呼側が通信端末２２０であるものとすると、ＳＩＰでは、まず発呼側の通信端末２００がＳＩＰサーバ１１０に発呼メッセージを送り、相手端末２２０との接続を要求する。ＳＩＰサーバ１１０は、ロケーションサーバ１１１に相手端末２２０のＩＰアドレスを問い合わせ、判明したＩＰアドレスを用いて通信端末２００と２２０の間のＩＰコネクションが形成される。
【００６８】
次に上記構成において、ＩＰ電話により通話中の通信端末間で、インターネットリソースを共有するための通信制御につき、異なる形態を説明する。ここでは、通話中の通信端末間で共有するインターネットリソースとしてＷＥＢブラウザで表示可能なネットコンテンツ（典型的なものとしてはＷＥＢページ）を考える。
【００６９】
図５〜図９は本実施形態１のＩＰ電話通信のシーケンスを示している。図５〜図９のＩＰ電話通信では、図１および図２のように構成された通信端末Ａから通信端末Ｂへ呼接続し、通話を行なう。また、本実施形態では、端末ＡでＷＥＢブラウジングを行なうとともに、ＩＰ電話通信中に通信端末Ａから通信端末ＢにそのＵＲＬデータを転送し、通信端末（以下単に「端末」とも記す）ＡおよびＢとの間で同一のＷＥＢ情報を共有できるようにする。
【００７０】
なお、図５〜図９のＳＩＰサーバ１１０、ロケーションサーバ１１１、ＤＮＳサーバ１１２、およびＷＥＢサーバ１１３は、図３または図４に示したものと同じである。
【００７１】
図５〜図９の通信シーケンスは、図１のＣＰＵ２０１が通信制御プログラムを実行することにより実現される。このＣＰＵ２０１の通信制御プログラムはたとえばＲＯＭ２０２に格納される（後述の他の実施形態においても同様）。図５〜図９の通信シーケンスの各ステップは符号Ｓ５０１以降により示されている。なお、図５〜図９の通信では、既にＡＤＳＬコネクションが成立し、端末ＡおよびＢがＩＰ網と接続されているものとする。
【００７２】
ここでは、端末Ａから端末Ｂへ呼接続し、端末ＡでＷＥＢブラウザによりＷＥＢ情報閲覧を行ない、さらに端末Ａから端末Ｂに向けＵＲＬデータの転送を行なう。そして、端末Ｂでは、受信したＵＲＬデータをもとにＷＥＢ接続する動作につき説明する。
【００７３】
まず、端末Ａにおいて、ユーザが操作部２１５でダイヤル操作を行なう（図５のＳ５０１）。これにより、ＩＮＶＩＴＥメッセージにより、ＳＩＰサーバ１１０に接続される（Ｓ５０２）。　　　　　　　　　　　　　　　　　【００７４】
ＳＩＰサーバ１１０はロケーションサーバ１１１に対してＩＰアドレスを要求し（Ｓ５０３）、ロケーションサーバ１１１は指定された電話番号に対応したＩＰアドレスを検索し、ＳＩＰサーバ１１０に得られたＩＰアドレスを送信する（Ｓ５０４）。この間ＲＢＴ（リングバックトーン）の鳴動が端末Ａで行なわれる（Ｓ５０５）。
【００７５】
ここで、ＳＩＰサーバは、受信した相手端末ＩＰアドレスを元に、ＩＮＶＩＴＥ要求を端末Ｂへ送出し、接続要求する（Ｓ５０６）。この時、端末Ｂが発信側端末ＡのＩＰアドレスを入手することになる。
【００７６】
端末Ｂは、ＳＩＰサーバからのＩＮＶＩＴＥ要求により着信動作に入る（Ｓ５０７）。そして、呼出中を示すＲｉｎｇｉｎｇをＳＩＰサーバに返し（Ｓ５０８）、ＳＩＰサーバは端末Ａに対してＲｉｎｇｉｎｇ信号を送信する（Ｓ５０９）。
【００７７】
端末Ｂが応答すると（Ｓ５１０）、接続完了を示すＯＫ情報がＳＩＰサーバ１１０に送信され（Ｓ５１１）、ＳＩＰサーバ１１０は、端末Ａに向けてＯＫ情報を送信し、端末Ａも相手端末ＢのＩＰアドレスを入手する（Ｓ５１２）。
【００７８】
その後、端末Ａ〜端末Ｂ間に生成されたＩＰコネクションを用いて音声パケットの送受信が可能となり（Ｓ５１３）、端末Ａおよび端末Ｂは通話状態となる（Ｓ５１４）。通常、ＶｏＩＰによる通信は、リアルタイム性を重視し、メッセージを含めてＵＤＰベースで行なわれるが、ＴＣＰベースの接続を選択することもできる。
【００７９】
端末Ａは、ＩＰ網と接続されているため、ＷＥＢページやメール送受信など、インターネット上の資源を利用することができる。
【００８０】
端末Ａ、Ｂ間の通話の進行に応じ、両者の間で特定のＷＥＢページのようなインターネットリソースが話題にのぼることは充分考えられる。前述のように従来では、ＷＥＢページのＵＲＬはＩＰ電話中は音声でやりとりしていたが、本実施形態では端末ＡからＢにあるＷＥＢページのＵＲＬを伝送し、端末Ｂで閲覧できるようにする例を示す。
【００８１】
端末Ａで、ＷＥＢブラウザを起動し（Ｓ５１５）、操作部２１５からＵＲＬを入力すると、端末ＡはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせる（Ｓ５１６）。問合せを受けたＤＮＳサーバ１１２は、ＵＲＬからＷＥＢサーバ１１３のアドレスを検索し（Ｓ５１７）、検索結果を端末Ａに返す（Ｓ５１８）。
【００８２】
端末ＡはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスする。端末ＡからＳＹＮパケットを出し（Ｓ５１９）、ＷＥＢサーバ１１３からＳＹＮ・ＡＣＫパケットを受信し（Ｓ５２０）、相手のＳＹＮに対してＡＣＫパケットを送信する（Ｓ５２１）。
【００８３】
このようにして同期が取れると、端末ＡはＷＥＢサーバ１１３にＷＥＢページのリクエストを行い（図６のＳ５２２）、ＷＥＢサーバ１１３からＷＥＢページのデータを得る（Ｓ５２３）。ＷＥＢページのデータを受信した端末ＡはブラウザにＷＥＢページを表示させる（Ｓ５２４）。
【００８４】
端末Ａは表示させたＷＥＢページを通話相手の端末Ｂにも表示させるため、ＵＲＬの転送を行なう。このＷＥＢページの内容を端末Ｂのユーザにも見てもらいたい場合には、端末Ａのユーザは操作部２１５のリソース転送ボタン２１５ａを押下する。
【００８５】
リソース共有利用を起動する操作として、上記のリソース転送ボタン２１５ａの操作の他、たとえば、表示部２１４のツールバーや、ＷＥＢブラウザのウィンドウの１つとして用意したコンソール上の「ＵＲＬ転送」など適当な名前のボタンの操作（ポインティングデバイスなどによる操作も含む）などが考えられ、これらの所定操作のいずれか、あるいはいずれも許容するような仕様も考えられる。
【００８６】
本実施形態では、端末Ａから端末ＢにＵＲＬ情報をＦＴＰ（ファイル転送プロトコル）で転送するため、ＵＲＬを記述したファイルを作成する（Ｓ５２５）。このＵＲＬを含むファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰ（Ｓｉｍｐｌｅ　Ｏｂｊｅｃｔ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ：ＲＦＣ３２８８）で記述する。
」（段落【００６７】〜【００８６】）
　　
（ウ）「【００９９】
次に上記のＩＰ電話通信の概略を図１０〜図１２にフローチャートとして示す。図１０〜図１２の手順は上記の図５〜図９の通信シーケンスに対応するもので、上記同様、図１のＣＰＵ２０１が通信制御プログラムを実行することにより実現される。このＣＰＵ２０１の通信制御プログラムはＲＯＭ２０２に格納される。図１０〜図１２の各ステップは符号Ｓ６０１以降により示されている。
【０１００】
まず、通知を行なう端末Ａは相手先端末に電話をかける。端末Ａはダイヤル操作を行いＳＩＰサーバに接続する（図１０Ｓ６０１）。ＳＩＰサーバは相手先端末の呼び出しを行なうとともに、端末Ａに相手先端末の電話番号に対応するＩＰアドレスを返す（Ｓ６０２）。端末Ａは呼び出し中状態になり、相手先端末が応答するのを待つ（Ｓ６０３）。相手先端末が応答すると通話状態になる（Ｓ６０４）。
【０１０１】
端末ＡはＷＥＢページを表示させるためにブラウザを起動する（Ｓ６０５）。端末ＡのブラウザにＵＲＬを入力すると、端末ＡはＵＲＬで指定されたＷＥＢサーバのアドレスをＤＮＳサーバに問い合わせ、検索結果を受ける（Ｓ６０６）。端末ＡはＤＮＳサーバから得たＩＰアドレスを元にＷＥＢサーバにアクセスしてＷＥＢページのデータを受け（Ｓ６０７）、ブラウザにＷＥＢページを表示させる（Ｓ６０８）。
【０１０２】
端末Ａは表示させたＷＥＢページを相手先端末にも表示させるため、ＵＲＬの転送を行なう。端末ＡはＵＲＬをＦＴＰで転送するため、ＵＲＬを記述したファイルを作成する（Ｓ６０９）。ファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰで記述する。
【０１０３】
端末Ａはロケーションサーバから得た相手先端末のＩＰアドレスを元に制御用ポートの相手先端末との同期を取る（Ｓ６１０）。相手先端末との同期が取れると、続いて相手先端末にログインを行なう（Ｓ６１１）。
【０１０４】
端末Ａは制御用のポートの他にＵＲＬデータ転送用のポートを用意し、データ転送用のポートと相手先端末との同期を取る（図１１Ｓ６１４）。端末ＡはＵＲＬを記述したファイルをデータ転送用のポートを使用して相手先端末に送信する（Ｓ６１５）。ＵＲＬデータの転送が完了すると、端末ＡはＵＲＬデータ転送用のポートを開放する（Ｓ６１６）。端末Ａは相手先端末にＦＴＰの終了を通知し転送終了処理を行なう（Ｓ６１７）。
【０１０５】
ブラウザによる閲覧を終えた端末Ａはブラウザを終了させる（Ｓ６１８）。相手先端末との通話が終了すると通話を切断する（図１２Ｓ６２６）。
【０１０６】
次に、ＩＰ電話で通話中、相手先端末が表示しているＷＥＢページのＵＲＬを受信し表示させる際のフローを説明する。
【０１０７】
通知を受ける端末Ｂはスタンバイ状態では着信があるかどうか監視している（Ｓ６１２）。着信を検出すると端末Ｂは着信に応答し（Ｓ６１３）、通話状態になる（Ｓ６０４）。
【０１０８】
相手先端末から同期を要求されると、端末Ｂはそれにしたがって同期を取る（Ｓ６１０）。相手先端末からログインを要求されると、ログインを許可しデータ転送待ち状態になる（Ｓ６１１）。端末Ｂは相手先端末のデータ転送用のポートと同期を取り（Ｓ６１４）、相手先端末のデータ転送用のポートからＵＲＬを記述したファイルを受信する（Ｓ６１５）。【０１０９】
ＵＲＬデータの転送が完了すると、相手先端末のデータ転送用のポートを開放し（Ｓ６１６）、相手先端末からＦＴＰの終了を受け転送終了処理を行なう（Ｓ６１７）。
【０１１０】
ファイルを受信した端末Ｂは、受信したファイルの解析を行なう（Ｓ６１９）。ファイルがＳＯＡＰで記述されていて、ＵＲＬが指定されブラウザを起動させる指示があるなら（Ｓ６２０）、ＷＥＢページを表示させるためにブラウザを起動する（Ｓ６２１）。ブラウザに相手先端末から受けたＵＲＬを入力すると、端末ＢはＵＲＬで指定されたＷＥＢサーバのアドレスをＤＮＳサーバに問い合わせ、検索結果を受ける（Ｓ６２２）。端末ＢはＤＮＳサーバから得たＩＰアドレスを元にＷＥＢサーバにアクセスしてＷＥＢページのデータを受け（Ｓ６２３）、ブラウザにＷＥＢページを表示させる（Ｓ６２４）。
【０１１１】
ブラウザを閲覧し終えた端末Ｂはブラウザを終了させる（Ｓ６２５）。また相手先との通信状態を監視していて（図１２Ｓ６２７）、相手先に切断されたことを検出すると通話を終了する（Ｓ６２８）。
【０１１２】
以上では、発呼した端末Ａ側から端末Ｂ側にＵＲＬデータを送信する例を示したが、ＵＲＬの送信はいずれが発呼側かに関係するものではなく、当然ながら上記と同様にして端末Ｂから端末ＡにＵＲＬデータを送信し、端末Ａ側で閲覧させることができる。また、以上では、端末Ａ側から端末Ｂ側にＵＲＬデータを送信する場合、端末Ａ側が端末Ｂ側にＦＴＰログインする、つまり端末Ｂ側をＦＴＰサーバとして機能させ、端末ＡがＵＲＬデータを送信（図７のＳ５３６：この際ＳＴＯＲ、ないしＳＴＯＵなどのＦＴＰコマンドが用いられる）する例を示した。しかしながら、ＵＲＬデータ送信の際のＦＴＰのログイン方向、送受信方向（送信コマンドであるＳＴＯＲ、ないしＳＴＯＵを用いるか、受信コマンドであるＲＥＴＲを用いるか、など）は任意であり、適宜変更してよい。
【０１１３】
さて、以上のようにして、通信端末２００、２２０（Ａ、Ｂ）間で、ＷＥＢブラウザを用いて同一のインターネットリソースを閲覧させることができる。
【０１１４】
さらに本実施形態では、同一のインターネットリソースの閲覧をより確実に同期させる。すなわち、通話者が確実に同一の情報を取得できるように保証する制御を行なう。本実施形態では、このために同一のインターネットリソースを閲覧しているＷＥＢブラウザのスクロール状態を通信端末２００、２２０（Ａ、Ｂ）間で同期させる。」（段落【００９９】〜【０１１４】）
　　
（エ）「【０１２１】
ＷＷＷブラウザ（ＷＥＢブラウザ）４１０２は、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）のプロトコルに基づき、指示されたサーバとの間でデータのやり取りを行ったり、ＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）あるいはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）の解析を行い、解析したサーバコンテンツの表示を行なう機能を有している。また、ＷＥＢページからアプレットを端末にダウンロードする機能も有している。
【０１２２】
ウインドウコントロールブロック４１０５は、端末において表示を行なう最上位アプリケーション（たとえば通話中表示画面、ＷＥＢブラウズ表示画面、ＦＡＸ操作表示画面など）を端末のＬＣＤ表示上にそれぞれ別のウインドウとして表示するための制御を行なうソフトウェアブロックである。本実施形態では、このウインドウコントロールを用いて、ＶｏＩＰ通話の画面表示アプリケーションとＷＥＢブラウズ表示画面をそれぞれ独立したアプリケーションとして動作させ、それぞれ独立したウインドウとして同時に表示することを可能にする。」（段落【０１２１】〜【０１２２】）
　　
　これら記載事項から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
「ＩＰ網で接続され、ＳＩＰ方式を用いるＩＰ電話通信で、端末Ａから端末Ｂへ呼接続し、通話を行ない、端末ＡでＷＥＢブラウジングを行なうとともに、ＩＰ電話通信中に端末Ａから端末ＢにそのＵＲＬデータを転送し、端末ＡおよびＢとの間でＷＥＢブラウザで表示可能な同一のインターネットリソース（ネットコンテンツ（典型的なものとしてはＷＥＢページ））を共有できるようにするものにおいて、
　端末Ａはダイヤル操作を行いＳＩＰサーバに接続し、ＳＩＰサーバは相手先端末Ｂの呼び出しを行なうとともに、端末Ａに相手先端末Ｂの電話番号に対応するＩＰアドレスを返し、端末Ａは呼び出し中状態になり、相手先端末Ｂが応答するのを待ち、相手先端末Ｂが応答すると通話状態になり、
端末ＡはＷＥＢページを表示させるためにブラウザを起動し、端末ＡのブラウザにＵＲＬを入力すると、端末ＡはＤＮＳサーバから得たＩＰアドレスを元にＷＥＢサーバにアクセスしてＷＥＢページのデータを受け、ブラウザにＷＥＢページを表示し、
　端末Ａは表示させたＷＥＢページを相手先端末Ｂにも表示させるため、ＵＲＬをＦＴＰで転送するため、ＵＲＬを記述したファイルを作成し、ファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰで記述し、
　端末ＡはＵＲＬを記述したファイルを相手先端末Ｂに送信し、ＵＲＬデータの転送が完了すると、端末Ａは相手先端末にＦＴＰの終了を通知し転送終了処理を行ない、ブラウザによる閲覧を終えた端末Ａはブラウザを終了させ、相手先端末Ｂとの通話が終了すると通話を切断し、
　端末Ｂは、相手先端末ＡからＵＲＬを記述したファイルを受信し、ＵＲＬデータの転送が完了すると、相手先端末ＡからＦＴＰの終了を受け転送終了処理を行い、受信したファイルの解析を行ない、ファイルがＳＯＡＰで記述されていて、ＵＲＬが指定されブラウザを起動させる指示があるなら、ＷＥＢページを表示させるためにブラウザを起動し、ブラウザに相手先端末Ａから受けたＵＲＬを入力すると、端末ＢはＵＲＬで指定されたＷＥＢサーバのアドレスをＤＮＳサーバに問い合わせ、検索結果を受け、端末ＢはＤＮＳサーバから得たＩＰアドレスを元にＷＥＢサーバにアクセスしてＷＥＢページのデータを受け、ブラウザにＷＥＢページを表示させ、ブラウザを閲覧し終えた端末Ｂはブラウザを終了させ、また相手先との通信状態を監視していて、相手先に切断されたことを検出すると通話を終了し、
　さらに、同一のインターネットリソースを閲覧しているＷＥＢブラウザのスクロール状態を通信端末Ａ、Ｂ間で同期させることを特徴とするＩＰ電話通信端末の制御方法。」
　　　　
（２）原査定の拒絶の理由に引用された国際公開２００６／０７７７３４号（以下、「引用文献２」という。）には、図面と共に次の事項が記載されている。
（ア）「本発明に係る情報処理装置１００は、別の情報処理装置１００との間でテレビ電話を行なう際に、テレビ電話を実際に行なう「コミュニケーション」と通信相手同士の状態（プレゼンス）を交換し合う「プレゼンス交換」との２つの通信シーケンスによって実現している。ここで、テレビ電話を実際に行なう「コミュニケーション」は、一般的な実現手段を用いることが可能であり、「コミュニケーション」に関する更に詳細な説明は省略するが、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）を用いた呼制御と、該呼制御により確立された呼に基づいて、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）を用いたストリームデータ通信とを用いて実現することができる。
　また、通信相手同士の状態を交換し合う「プレゼンス交換」は、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）を用いて実現する。図８は、本発明に係る情報処理装置においてＳＩＰプロトコルによるプレゼンス交換の実現手順の一例を説明するためのデータフローチャートであり、情報処理装置１００Ａと情報処理装置１００Ｂとの間でプレゼンス交換を行なうデータのシーケンスを示している。図８では、情報処理装置１００Ａにおいて、当該情報処理装置１００Ａの利用者から情報処理装置１００Ｂの利用者のプレゼンス情報を知りたい旨の指示があった場合、当該情報処理装置１００Ａは、指定された情報処理装置１００Ｂのプレゼンス情報の取得を要求する旨の情報を、図４に示す相手情報ＤＢ６０の購読要求リスト６２に登録し、情報処理装置１００Ａから情報処理装置１００Ｂに対して、プレゼンス情報の取得要求を示す状態通知登録要求信号Ｍ１として「ＳＵＢＳＣＲＩＢＥ」信号を送信する。
　状態通知登録要求信号Ｍ１を受信した情報処理装置１００Ｂの利用者が当該情報処理装置１００Ｂの利用者のプレゼンス情報を情報処理装置１００Ａに対して通知しても良いと判断した場合には、情報処理装置１００Ａをプレゼンス配布先として追加するように、図４に示す相手情報ＤＢ６０のプレゼンス配布リスト６３に登録し、状態通知登録要求信号Ｍ１の「ＳＵＢＳＣＲＩＢＥ」信号に対する受信確認として、「ＯＫ」信号Ｍ２を要求元の情報処理装置１００Ａに対して返送する。
　一方、情報処理装置１００Ｂの利用者が、自己のプレゼンス情報を通信相手に対して通知したい状況が発生した場合には、自情報ＤＢ５０から自プレゼンス情報５１を読み出して、自己のプレゼンス情報を通知するための状態通知信号Ｍ３として「ＮＯＴＩＦＹ」信号を生成し、プレゼンス配布リスト６３に登録されている情報処理装置１００Ａに対して送信する。状態通知信号Ｍ３を受信した情報処理装置１００Ａは、状態通知信号Ｍ３の「ＮＯＴＩＦＹ」信号に対する受信確認として、「ＯＫ」信号Ｍ４を送信元の情報処理装置１００Ｂに対して返送する。更に、情報処理装置１００Ａは、受信した状態通知信号Ｍ３に含まれている情報処理装置１００Ｂのプレゼンス情報を、相手情報ＤＢ６０の相手プレゼンス情報６１として登録すると共に、利用者からの表示要求に応じて、モニタ出力処理部４８を介してモニタ３１に画面表示する。
　なお、自己のプレゼンス情報を送信する情報処理装置１００Ｂが、状態通知信号Ｍ３として「ＮＯＴＩＦＹ」信号を送信する送信タイミングとしては、
１）当該情報処理装置１００Ｂの利用者の状態（プレゼンス）が変化した時点、
２）情報処理装置１００Ａからの状態通知登録要求信号Ｍ１の「ＳＵＢＳＣＲＩＢＥ」信号に対する「ＯＫ」信号Ｍ２を返送した時点、及び、
３）それ以外の任意の時点、
の３つの時点を設定することができる。ここで、３）の任意の時点としては、当該情報処理装置１００Ｂの利用者の状態（プレゼンス）が変化していなくても、利用者が送信を指示した時点であっても良いし、あるいは、予め定めた周期で定期的に送信するようにしても構わない。
　また、ＳＩＰプロトコルでは、プレゼンス取得要求元の情報処理装置１００Ａは、既に、状態通知登録をしている通信相手、即ち、相手情報ＤＢ６０の相手プレゼンス情報６１として登録している通信相手、に対しても、利用者が要求する任意の時点で、状態通知登録要求信号Ｍ１の「ＳＵＢＳＣＲＩＢＥ」信号を送信することができる。また、状態通知登録要求信号Ｍ１の「ＳＵＢＳＣＲＩＢＥ」信号を受信した情報処理装置１００Ｂは、送信元の情報処理装置１００Ａに対して、必ず、状態通知信号Ｍ３としての「ＮＯＴＩＦＹ」信号を返送することが必要である。従って、情報処理装置１００Ａの利用者は、状態通知登録要求信号Ｍ１の「ＳＵＢＳＣＲＩＢＥ」信号を所望する任意の時点で送信することを指示することにより、オンデマンドで情報処理装置１００Ｂの利用者のプレゼンスを示す状態通知信号Ｍ３の「ＮＯＴＩＦＹ」信号を受信することができ、所望の時点で通信相手のプレゼンスをリアルタイムに取得して画面表示することが可能である。」（段落【００７４】〜【００７９】）
　　　
（イ）「次に、利用者がリモコン操作部２１を操作して画像登録画面に表示されている自画像を自プレゼンス情報として登録するように指示した場合、登録指示された自画像を含む画像ファイルを、自情報ＤＢ５０の自画像データ５２として登録する（ステップＳ４４）。ここで、自画像データ５２の所在場所を自プレゼンス情報５１に設定することにより、自プレゼンス情報５１を読み出す際に、自画像データ５２を読み出すことを可能としている。なお、前述のように、自プレゼンス情報５１に自画像データ５２とその所在場所とを設定しても良いし、当該情報処理装置１００Ｂとは別の画像蓄積装置（サーバ装置）に保存するようにしても良い。しかる後、プレゼンス配布先として登録されている情報処理装置１００Ａに対して、登録した自画像データ５２に関する情報を含む自プレゼンス情報５１を状態通知信号Ｍ３の「ＮＯＴＩＦＹ」信号として配信する（ステップＳ４５）。ここで、状態通知信号Ｍ３に含まれる自画像データに関する情報としては、前述のように、自画像データ５２の所在場所を示すアドレス情報のみを送信するようにしている。
　従って、プレゼンス取得要求元の情報処理装置１００Ａが、相手プレゼンス情報６１として相手情報ＤＢ６０に登録する際に、あるいは、場合によっては、相手プレゼンス情報を画面表示する際に、受信した状態通知信号Ｍ３に含まれているアドレス情報から相手の自画像データ５２を画像データ１１０として取得して、取得した画像データ１１０を相手画像として相手プレゼンス情報６１にアドレス情報と共に登録したり、あるいは、場合によっては、取得した画像データ１１０を相手画像３１ｃとして画面表示する。
　なお、自情報ＤＢ５０に登録した自画像データ５２にアクセスする参照形式を、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）又はＦＴＰ（Ｆｉｌｅ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）に準拠する形式として、当該情報処理装置１００Ｂ内のＷｅｂサーバ装置に蓄積するようにしても良い。この場合は、自画像データ５２の所在場所は、ＵＲＬ形式で表現されることになる。更には、自情報ＤＢ５０を蓄積するＷｅｂサーバ装置の設置場所としては、前述のように、当該情報処理装置１００Ｂ内に内蔵する形態のみに限るものではなく、場合によっては、当該情報処理装置１００Ｂの外部に設置したＷｅｂサーバ装置であっても良く、図２に示したネットワーク１０５を介してアクセスすることができるものであれば、如何なる設置形態であっても構わない。当該情報処理装置１００Ｂの外部のＷｅｂサーバを用いる場合は、撮影した自画像データ５２の画像ファイルを、ネットワーク１０５を介してＷｅｂサーバ装置上にアップロードし、通信相手の情報処理装置１００Ａが当該自画像データを相手画像として参照する場合は、ネットワーク１０５を介して該Ｗｅｂサーバ装置の画像ファイルにアクセスすることになる。」（段落【０１１９】〜【０１２１】）
　
第５　対比
　本願発明と引用発明とを対比する。
（ア）引用発明の「ＷＥＢページ」は、本願発明の「ＸＭＬコンテンツ」と「コンテンツ」である点で共通する。
　そして、引用発明の「ＷＥＢサーバ」は、本願発明の「ＸＭＬサーバー」と「コンテンツ」を保存する「サーバー」である点で共通する。
　　
（イ）引用発明の「端末Ａ」は、「ＳＩＰ方式を用いるＩＰ電話通信で、端末Ａから端末Ｂへ呼接続し、通話を行ない」、「ＷＥＢサーバにアクセスしてＷＥＢページのデータを受け、ブラウザにＷＥＢページを表示」するから、本願発明の「第１のＸＭＬコンテンツ表示部を備えたＳＩＰ（Session Initiate Protocol）端末」と「第１のコンテンツ表示部を備えたＳＩＰ（Session Initiate Protocol）端末」である点で共通するといえる。
　　
（ウ）引用発明の「端末Ｂ」は、「ＳＩＰ方式」を用いており、「ＩＰ網で接続され」「ＷＥＢサーバにアクセスしてＷＥＢページのデータを受け、ブラウザにＷＥＢページを表示」するから、本願発明の「第２のＸＭＬコンテンツ表示部を備え、前記第１のＳＩＰ端末に通信ネットワークを介して接続された第２のＳＩＰ端末」と「第２のコンテンツ表示部を備え、前記第１のＳＩＰ端末に通信ネットワークを介して接続された第２のＳＩＰ端末」である点で共通するといえる。
　　
（エ）引用発明の「端末ＡはＷＥＢページを表示させるためにブラウザを起動し、端末ＡのブラウザにＵＲＬを入力すると、端末ＡはＤＮＳサーバから得たＩＰアドレスを元にＷＥＢサーバにアクセスしてＷＥＢページのデータを受け、ブラウザにＷＥＢページを表示し、端末Ａは表示させたＷＥＢページを相手先端末Ｂにも表示させるため、ＵＲＬをＦＴＰで転送するため、ＵＲＬを記述したファイルを作成し、ファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰで記述し、端末ＡはＵＲＬを記述したファイルを相手先端末Ｂに送信」する構成は、本願発明の「前記第１のＳＩＰ端末側にて、前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第２のＳＩＰ端末に送信するステップ」と「前記第１のＳＩＰ端末側にて、前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記サーバーに保存されたコンテンツのアドレス情報が記述された情報を前記第２のＳＩＰ端末に送信するステップ」である点で共通するといえる。
　　
（オ）引用発明の「端末Ｂは、相手先端末ＡからＵＲＬを記述したファイルを受信し、ＵＲＬデータの転送が完了すると、相手先端末ＡからＦＴＰの終了を受け転送終了処理を行い、受信したファイルの解析を行ない、ファイルがＳＯＡＰで記述されていて、ＵＲＬが指定されブラウザを起動させる指示があるなら、ＷＥＢページを表示させるためにブラウザを起動し、ブラウザに相手先端末Ａから受けたＵＲＬを入力すると、端末ＢはＵＲＬで指定されたＷＥＢサーバのアドレスをＤＮＳサーバに問い合わせ、検索結果を受け、端末ＢはＤＮＳサーバから得たＩＰアドレスを元にＷＥＢサーバにアクセスしてＷＥＢページのデータを受け、ブラウザにＷＥＢページを表示」する構成は、本願発明の「前記第２のＳＩＰ端末側にて、前記ＸＭＬコンテンツのアドレス情報を受け前記ＸＭＬサーバーから前記ＸＭＬコンテンツを取得し、取得した前記ＸＭＬコンテンツの一部情報を画面表示させるステップ」と「前記第２のＳＩＰ端末側にて、前記コンテンツのアドレス情報を受け前記サーバーから前記コンテンツを取得し、取得した前記コンテンツの情報を画面表示させるステップ」である点で共通するといえる。
　　
（カ）引用発明の「ＩＰ電話通信端末の制御方法」は、「端末ＡおよびＢとの間でＷＥＢブラウザで表示可能な同一のインターネットリソース（ネットコンテンツ（典型的なものとしてはＷＥＢページ））を共有できるようにする」から、本願発明の「双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法」に相当するといえる。
　　
　そうすると、本願発明の用語を用いると両者は次の点で一致する。
「サーバーと、第１のコンテンツ表示部を備えた第１のＳＩＰ（Session Initiate Protocol）端末と、第２のコンテンツ表示部を備え、前記第１のＳＩＰ端末に通信ネットワークを介して接続された第２のＳＩＰ端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、
　前記双方向コンテンツ表示制御処理ステップは、
　前記第１のＳＩＰ端末側にて、前記第１および前記第２のＳＩＰ端末同士の通話中、前記第１のＳＩＰ端末から前記サーバーに保存されたコンテンツのアドレス情報が記述された情報を前記第２のＳＩＰ端末に送信するステップと、
　前記第２のＳＩＰ端末側にて、前記コンテンツのアドレス情報を受け前記サーバーから前記コンテンツを取得し、取得した前記コンテンツの情報を画面表示させるステップ
を有することを特徴とする双方向コンテンツ表示方法。」
　　
　そして、両者は次の（１）〜（３）の点で相違する。
（１）本願発明は、「コンテンツ」が、「ＸＭＬコンテンツ」であって、「サーバー」、「コンテンツ表示部」及び「サーバーに保存されたコンテンツのアドレス」がそれぞれ「ＸＭＬサーバー」、「ＸＭＬコンテンツ表示部」及び「ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス」であるのに対し、引用発明は、「コンテンツ」が、「ＷＥＢぺージ」であって、「サーバー」、「コンテンツ表示部」及び「サーバーに保存されたコンテンツのアドレス」が、それぞれ「ＷＥＢサーバ」、「ＷＥＢブラウザ」及び「ＷＥＢページ」の「ＵＲＬ」である点。　
　　
（２）本願発明は、「コンテンツのアドレス情報が記述されたNOTIFYリクエストを」「送信する」のに対し、引用発明は、コンテンツの「ＵＲＬを記述したファイルを」「ＦＴＰで送信する」点。
　　
（３）本願発明は、「前記第２のＳＩＰ端末側にて、」「コンテンツの一部情報を画面表示させる」のに対し、引用発明は、端末Ｂにて、「ブラウザにＷＥＢページ」の一部情報を表示させるような記載はない点。
　　
第６　当審の判断
・相違点（１）について
　引用文献１には、「ＷＷＷブラウザ（ＷＥＢブラウザ）４１０２は、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）のプロトコルに基づき、指示されたサーバとの間でデータのやり取りを行ったり、ＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）あるいはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）の解析を行い、解析したサーバコンテンツの表示を行なう機能を有している。」（記載事項（エ）、段落【０１２１】）と記載されており、サーバに保存されているコンテンツがＸＭＬコンテンツであり、ブラウザがＸＭＬコンテンツを表示することが示されている。
　そうすると、引用発明において、「ＷＥＢぺージ」を「ＸＭＬコンテンツ」とし、「ＷＥＢサーバ」、「ＷＥＢブラウザ」及び「ＷＥＢページ」の「ＵＲＬ」を、それぞれ、「ＸＭＬサーバー」、「ＸＭＬコンテンツ表示部」及び「ＸＭＬサーバーに保存されたＸＭＬコンテンツのアドレス」とすることは、当業者が容易になし得ることである。
　
・相違点（２）について
　引用文献２には、情報処理装置１００Ｂは、自画像データ５２を外部の画像蓄積装置（サーバ装置）に保存し、プレゼンス配布先として登録されている情報処理装置１００Ａに対して、自画像データ５２の所在場所を示すアドレス情報をＳＩＰの「ＮＯＴＩＦＹ」信号として送信することが記載されている。
　したがって、上記引用文献２に記載された技術を採用し、引用発明において、「コンテンツのアドレス情報が記述されたNOTIFYリクエストを」「送信する」ようにすることは、当業者が容易になし得ることである。
　　　
・相違点（３）について
　本願発明の「前記第２のＳＩＰ端末側にて、前記ＸＭＬコンテンツのアドレス情報を受け前記ＸＭＬサーバーから前記ＸＭＬコンテンツを取得し、取得した前記ＸＭＬコンテンツの一部情報を画面表示させるステップ」の画面表示させる「取得した前記ＸＭＬコンテンツの一部情報」とは、どのような情報であるのか明確ではなく、本願明細書の発明の詳細な説明を参照すると、「指定されたアドレスのＸＭＬコンテンツ情報を受信すると、ＸＭＬコンテンツ解析部５０に当該ＸＭＬコンテンツ情報を送信し、そのＸＭＬコンテンツ情報の解析を要求する。ＸＭＬコンテンツ表示アプリケーション２０はＸＭＬコンテンツ解析部５０が解析したＸＭＬコンテンツ情報を受信し、当該ＸＭＬコンテンツ情報をＧＵＩ表示部（大画面ＬＣＤ）に表示させるようにＸＭＬコンテンツ情報表示コマンドをＧＵＩ表示部６０に送信する。当該表示要求を受信したＧＵＩ表示部６０は前記ＸＭＬコンテンツ情報を表示する。」（段落【００１９】）及び「ＸＭＬコンテンツ表示アプリケーション２０は受け取ったアドレスへのアクセスをＨＴＴＰメッセージ送受信部４０に要求し、ＸＭＬコンテンツ解析部５０によるＸＭＬサーバー１０１から受信したレスポンス解析結果をＧＵＩ表示部に表示する。これにより、ＳＩＰ端末Ａ２００とＳＩＰ端末Ｂ２０１の間で通話をしながら同じ画像情報確認することができる。」（段落【００２５】）と記載されているが、画面表示させる「取得した前記ＸＭＬコンテンツの一部情報」が、具体的にどのような情報であるのかの記載はない。
　そうすると、引用発明は、「同一のインターネットリソースを閲覧しているＷＥＢブラウザのスクロール状態を通信端末Ａ、Ｂ間で同期させる」ものであるから、端末Ｂ側にて取得したコンテンツの一部情報を順次スクロール表示していることは明らかであり、この点は実質的な差異ではない。
　　
　そして、本願発明による効果も、引用発明及び引用文献２に記載の技術から当業者が予測し得る範囲のものである。　
　
第７　むすび
　以上のとおり、本願発明は、引用発明及び引用文献２に記載の技術に基づいて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。
よって、結論のとおり審決する。
　　
　なお、請求人は前置審尋の回等書において、補正案を提示し、 
「審判請求人において検討の結果、本ご認定に応答して、また、必要に応じて、特許請求の範囲を補正する用意があることをお伝え致します。 
出願時明細書第００２２段落には、ＸＭＬコンテンツ表示アプリケーション２０が、ＸＭＬサーバー１０１のデフォルトコンテンツアドレスへのアクセス要求をＨＴＴＰメッセージ送受信部４０に送信することが記載されています。また、同第００２３段落には、ＳＩＰ端末Ａ２００の電話機機能アプリケーション１０が、現在アクセス中のＸＭＬコンテンツアドレス情報をＳＩＰメッセージ送受信部３０に送信することが記載されています。 
　これらの記載から、デフォルトコンテンツアドレスに対応するデフォルトコンテンツが存在し、その一部としてXMLコンテンツのアドレス情報が含まれていることがお分かりいただけるものと思量致します。このように、本発明では、デフォルトコンテンツアドレスが示すデフォルトコンテンツの全体ではなく、デフォルトコンテンツからその一部として含まれるXMLコンテンツのアドレス情報を取得します。そして、そのアドレス情報に対応するXMLコンテンツをXMLサーバから取得して、SIP端末の画面に表示します。このようにすることにより、SIP端末における情報の表示を、比較的処理負荷が軽いXMLコンテンツ表示アプリケーションにて行なうことができるようになります。このことは出願時明細書第００１４段落に記載されています。 
　このような特徴をより明瞭なものとするため、独立項である請求項１、４を下記のように補正する用意があります。仮に審判官殿が前置報告書を支持される場合であっても、補正後の請求項に係る発明によれば、引用文献記載発明との相違がより明瞭なものとなると思量致します。」と述べている。
　しかしながら、上記明細書第００２２、００２３段落、００１４段落には、補正案の請求項１、４における「前記ＸＭＬサーバーに保存され、第１のアドレス情報によって指定される第１のコンテンツの一部を構成するＸＭＬコンテンツのアドレス情報」について記載されておらず、自明であるとも認められない。したがって、補正案は採用できない。