拒絶査定不服の審決｜不服2012-15818 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 4号2号請求項の限定的減縮特許、登録しない。 G06F 審判査定不服 2項進歩性特許、登録しない。 G06F
管理番号	1277538
審判番号	不服2012-15818
総通号数	165
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2013-09-27
種別	拒絶査定不服の審決
審判請求日	2012-08-14
確定日	2013-08-09
事件の表示	特願2007- 56055「双方向コンテンツ表示システム及び方法」拒絶査定不服審判事件〔平成20年 9月18日出願公開、特開2008-217587〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は、平成19年3月6日を出願日とするものであって、平成24年5月14日付けで拒絶査定がなされ、それに対して同年8月14日に拒絶査定不服の審判請求がなされるとともに手続補正書が提出されたものである。第2 平成24年8月14日付けの手続補正の補正却下の決定 [補正却下の決定の結論] 平成24年8月14日付けの手続補正(以下、「本件補正」という。)を却下する。 [理由] (1)補正後の本願発明本件補正により、少なくとも特許請求の範囲の請求項4は次のように補正された。「XMLサーバーと、第1のXMLコンテンツ表示部を備えた第1のSIP(Session Initiate Protocol)端末と、第2のXMLコンテンツ表示部を備え、前記第1のSIP端末に通信ネットワークを介して接続された第2のSIP端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、前記双方向コンテンツ表示制御処理ステップは、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記第2のSIP端末に問い合わせを送信するステップと、前記問い合わせに応じて、前記XMLサーバーに保存されたXMLコンテンツのアドレス情報を前記第2のSIP端末から前記第1のSIP端末に通知するステップと、通知された前記XMLコンテンツのアドレス情報に基づいて前記第1のSIP端末が前記XMLサーバーから前記XMLコンテンツを取得し、取得した前記XMLコンテンツの一部情報を画面表示するステップとを有することを特徴とする双方向コンテンツ表示方法。」 (2)補正の可否の検討本件補正前の請求項4は、「XMLサーバーと、第1のXMLコンテンツ表示部を備えた第1のSIP(Session Initiate Protocol)端末と、第2のXMLコンテンツ表示部を備え、前記第1のSIP端末に通信ネットワークを介して接続された第2のSIP端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、前記双方向コンテンツ表示制御処理ステップは、前記第1のSIP端末側にて、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記XMLサーバーに保存されたXMLコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第2のSIP端末に送信するステップと、前記第2のSIP端末側にて、前記XMLコンテンツのアドレス情報を受け前記XMLサーバーから前記XMLコンテンツを取得し、取得した前記XMLコンテンツの一部情報を画面表示させるステップを有することを特徴とする双方向コンテンツ表示方法。」である。そうすると、本件補正後の請求項4は、補正前の請求項4に存在した「前記第1のSIP端末側にて、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記XMLサーバーに保存されたXMLコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第2のSIP端末に送信するステップ」と「前記第2のSIP端末側にて、前記XMLコンテンツのアドレス情報を受け前記XMLサーバーから前記XMLコンテンツを取得し、取得した前記XMLコンテンツの一部情報を画面表示させるステップ」を有してなく、補正前の請求項4にはなかった「前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記第2のSIP端末に問い合わせを送信するステップ」と「前記問い合わせに応じて、前記XMLサーバーに保存されたXMLコンテンツのアドレス情報を前記第2のSIP端末から前記第1のSIP端末に通知するステップ」を有するものとなっている。このような補正を含む本件補正は、特許法第17条の2第4項第2号に規定する特許請求の範囲の減縮には該当しない。また、この補正は、同条同項1号、3号、4号のいずれに規定する補正目的にも該当しない。 (3)むすびしたがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。第3 本願発明本件補正は、上記のとおり却下されたので、本願の請求項4に係る発明(以下、「本願発明」という。)は、平成23年11月16日付けの手続補正書により補正された特許請求の範囲の請求項4に記載された事項により特定される、以下のものである。「XMLサーバーと、第1のXMLコンテンツ表示部を備えた第1のSIP(Session Initiate Protocol)端末と、第2のXMLコンテンツ表示部を備え、前記第1のSIP端末に通信ネットワークを介して接続された第2のSIP端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、前記双方向コンテンツ表示制御処理ステップは、前記第1のSIP端末側にて、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記XMLサーバーに保存されたXMLコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第2のSIP端末に送信するステップと、前記第2のSIP端末側にて、前記XMLコンテンツのアドレス情報を受け前記XMLサーバーから前記XMLコンテンツを取得し、取得した前記XMLコンテンツの一部情報を画面表示させるステップを有することを特徴とする双方向コンテンツ表示方法。」第4 引用文献 (1)原査定の拒絶の理由に引用された特開2005-20647号公報(以下、「引用文献1」という。)には、図面と共に次の事項が記載されている。 (ア)「【0024】図1は本発明を採用したIP電話機能およびWEBブラウザ機能を有する通信端末の構成を示している。図1において、符号100は、情報端末200が接続されるIP網(いわゆるインターネットの他に、イントラネットのように閉じた網も考えられるが、以下では特に区別する必要がある場合を除きインターネット網という)で、有線回線101を介して接続される。本実施形態では、有線回線101としてはADSLであるものとし、図1の情報端末の回線はスプリッタ102によりPSTN網用の帯域104と、ADSL網用の帯域103を分割して使用する。【0025】情報端末200は、PSTN接続による音声通信(たとえば通話およびファクシミリ)が可能であるとともに、インターネット接続(PPPｏEなどのADSL接続方式が用いられる)、およびインターネット上の資源の利用(本実施形態の場合、少なくともIP電話の他にWEBページ閲覧、Eメール送受信など)が可能である。【0026】なお、IP網100への接続は、ADSLである必要はなく光ファイバー回線や、CATV回線、無線回線など任意の回線メディアを用いることができる。・・・中略・・・また、操作部215には、特にリソース転送ボタン215aおよびスクロールキー215bが設けられている。リソース転送ボタン215aは、本端末どうしでIP電話中にインターネットリソースを共有利用することを指定するためユーザが押下する。スクロールキー215bは、後述のWEBページの表示画面をスクロールさせるために用いられる他、メニューユーザーインターフェースなどにおいてはアイテム選択などに用いられる。・・・中略・・・すなわち、CPU201はROM202に格納されたプログラムにしたがって全体を制御し、網への接続や、各種プロトコルを制御し処理を実行する。もちろんCPU201の制御には操作、表示、読み取り、記録に使用する制御も含まれる。【0032】さらに、ブロードバンド接続に関する制御や、IP電話を実現するための制御、WEBアクセスを行なうための制御、WEBページを表示するためのブラウザ制御、また、IPアドレスの検知、抽出制御、そして、URL等のデータを送信するためのファイル作成や、送受信制御を実行する。」(段落【0024】?【0032】) (イ)「【0067】本実施形態のIP電話通信では、SIP方式を用いる。ここで発呼側が通信端末200、着呼側が通信端末220であるものとすると、SIPでは、まず発呼側の通信端末200がSIPサーバ110に発呼メッセージを送り、相手端末220との接続を要求する。SIPサーバ110は、ロケーションサーバ111に相手端末220のIPアドレスを問い合わせ、判明したIPアドレスを用いて通信端末200と220の間のIPコネクションが形成される。【0068】次に上記構成において、IP電話により通話中の通信端末間で、インターネットリソースを共有するための通信制御につき、異なる形態を説明する。ここでは、通話中の通信端末間で共有するインターネットリソースとしてWEBブラウザで表示可能なネットコンテンツ(典型的なものとしてはWEBページ)を考える。【0069】図5?図9は本実施形態1のIP電話通信のシーケンスを示している。図5?図9のIP電話通信では、図1および図2のように構成された通信端末Aから通信端末Bへ呼接続し、通話を行なう。また、本実施形態では、端末AでWEBブラウジングを行なうとともに、IP電話通信中に通信端末Aから通信端末BにそのURLデータを転送し、通信端末(以下単に「端末」とも記す)AおよびBとの間で同一のWEB情報を共有できるようにする。【0070】なお、図5?図9のSIPサーバ110、ロケーションサーバ111、DNSサーバ112、およびWEBサーバ113は、図3または図4に示したものと同じである。【0071】図5?図9の通信シーケンスは、図1のCPU201が通信制御プログラムを実行することにより実現される。このCPU201の通信制御プログラムはたとえばROM202に格納される(後述の他の実施形態においても同様)。図5?図9の通信シーケンスの各ステップは符号S501以降により示されている。なお、図5?図9の通信では、既にADSLコネクションが成立し、端末AおよびBがIP網と接続されているものとする。【0072】ここでは、端末Aから端末Bへ呼接続し、端末AでWEBブラウザによりWEB情報閲覧を行ない、さらに端末Aから端末Bに向けURLデータの転送を行なう。そして、端末Bでは、受信したURLデータをもとにWEB接続する動作につき説明する。【0073】まず、端末Aにおいて、ユーザが操作部215でダイヤル操作を行なう(図5のS501)。これにより、INVITEメッセージにより、SIPサーバ110に接続される(S502)。【0074】 SIPサーバ110はロケーションサーバ111に対してIPアドレスを要求し(S503)、ロケーションサーバ111は指定された電話番号に対応したIPアドレスを検索し、SIPサーバ110に得られたIPアドレスを送信する(S504)。この間RBT(リングバックトーン)の鳴動が端末Aで行なわれる(S505)。【0075】ここで、SIPサーバは、受信した相手端末IPアドレスを元に、INVITE要求を端末Bへ送出し、接続要求する(S506)。この時、端末Bが発信側端末AのIPアドレスを入手することになる。【0076】端末Bは、SIPサーバからのINVITE要求により着信動作に入る(S507)。そして、呼出中を示すRingingをSIPサーバに返し(S508)、SIPサーバは端末Aに対してRinging信号を送信する(S509)。【0077】端末Bが応答すると(S510)、接続完了を示すOK情報がSIPサーバ110に送信され(S511)、SIPサーバ110は、端末Aに向けてOK情報を送信し、端末Aも相手端末BのIPアドレスを入手する(S512)。【0078】その後、端末A?端末B間に生成されたIPコネクションを用いて音声パケットの送受信が可能となり(S513)、端末Aおよび端末Bは通話状態となる(S514)。通常、VｏIPによる通信は、リアルタイム性を重視し、メッセージを含めてUDPベースで行なわれるが、TCPベースの接続を選択することもできる。【0079】端末Aは、IP網と接続されているため、WEBページやメール送受信など、インターネット上の資源を利用することができる。【0080】端末A、B間の通話の進行に応じ、両者の間で特定のWEBページのようなインターネットリソースが話題にのぼることは充分考えられる。前述のように従来では、WEBページのURLはIP電話中は音声でやりとりしていたが、本実施形態では端末AからBにあるWEBページのURLを伝送し、端末Bで閲覧できるようにする例を示す。【0081】端末Aで、WEBブラウザを起動し(S515)、操作部215からURLを入力すると、端末AはURLで指定されたWEBサーバ113のアドレスをDNSサーバ112に問い合わせる(S516)。問合せを受けたDNSサーバ112は、URLからWEBサーバ113のアドレスを検索し(S517)、検索結果を端末Aに返す(S518)。【0082】端末AはDNSサーバ112から得たIPアドレスを元にWEBサーバ113にアクセスする。端末AからSYNパケットを出し(S519)、WEBサーバ113からSYN・ACKパケットを受信し(S520)、相手のSYNに対してACKパケットを送信する(S521)。【0083】このようにして同期が取れると、端末AはWEBサーバ113にWEBページのリクエストを行い(図6のS522)、WEBサーバ113からWEBページのデータを得る(S523)。WEBページのデータを受信した端末AはブラウザにWEBページを表示させる(S524)。【0084】端末Aは表示させたWEBページを通話相手の端末Bにも表示させるため、URLの転送を行なう。このWEBページの内容を端末Bのユーザにも見てもらいたい場合には、端末Aのユーザは操作部215のリソース転送ボタン215aを押下する。【0085】リソース共有利用を起動する操作として、上記のリソース転送ボタン215aの操作の他、たとえば、表示部214のツールバーや、WEBブラウザのウィンドウの1つとして用意したコンソール上の「URL転送」など適当な名前のボタンの操作(ポインティングデバイスなどによる操作も含む)などが考えられ、これらの所定操作のいずれか、あるいはいずれも許容するような仕様も考えられる。【0086】本実施形態では、端末Aから端末BにURL情報をFTP(ファイル転送プロトコル)で転送するため、URLを記述したファイルを作成する(S525)。このURLを含むファイルは受信側でブラウザを立ち上げられるようにFTPの上位プロトコルであるSOAP(Simｐle Objecｔ Acceｓｓ Pｒｏｔｏcｏl:RFC3288)で記述する。」(段落【0067】?【0086】) (ウ)「【0099】次に上記のIP電話通信の概略を図10?図12にフローチャートとして示す。図10?図12の手順は上記の図5?図9の通信シーケンスに対応するもので、上記同様、図1のCPU201が通信制御プログラムを実行することにより実現される。このCPU201の通信制御プログラムはROM202に格納される。図10?図12の各ステップは符号S601以降により示されている。【0100】まず、通知を行なう端末Aは相手先端末に電話をかける。端末Aはダイヤル操作を行いSIPサーバに接続する(図10S601)。SIPサーバは相手先端末の呼び出しを行なうとともに、端末Aに相手先端末の電話番号に対応するIPアドレスを返す(S602)。端末Aは呼び出し中状態になり、相手先端末が応答するのを待つ(S603)。相手先端末が応答すると通話状態になる(S604)。【0101】端末AはWEBページを表示させるためにブラウザを起動する(S605)。端末AのブラウザにURLを入力すると、端末AはURLで指定されたWEBサーバのアドレスをDNSサーバに問い合わせ、検索結果を受ける(S606)。端末AはDNSサーバから得たIPアドレスを元にWEBサーバにアクセスしてWEBページのデータを受け(S607)、ブラウザにWEBページを表示させる(S608)。【0102】端末Aは表示させたWEBページを相手先端末にも表示させるため、URLの転送を行なう。端末AはURLをFTPで転送するため、URLを記述したファイルを作成する(S609)。ファイルは受信側でブラウザを立ち上げられるようにFTPの上位プロトコルであるSOAPで記述する。【0103】端末Aはロケーションサーバから得た相手先端末のIPアドレスを元に制御用ポートの相手先端末との同期を取る(S610)。相手先端末との同期が取れると、続いて相手先端末にログインを行なう(S611)。【0104】端末Aは制御用のポートの他にURLデータ転送用のポートを用意し、データ転送用のポートと相手先端末との同期を取る(図11S614)。端末AはURLを記述したファイルをデータ転送用のポートを使用して相手先端末に送信する(S615)。URLデータの転送が完了すると、端末AはURLデータ転送用のポートを開放する(S616)。端末Aは相手先端末にFTPの終了を通知し転送終了処理を行なう(S617)。【0105】ブラウザによる閲覧を終えた端末Aはブラウザを終了させる(S618)。相手先端末との通話が終了すると通話を切断する(図12S626)。【0106】次に、IP電話で通話中、相手先端末が表示しているWEBページのURLを受信し表示させる際のフローを説明する。【0107】通知を受ける端末Bはスタンバイ状態では着信があるかどうか監視している(S612)。着信を検出すると端末Bは着信に応答し(S613)、通話状態になる(S604)。【0108】相手先端末から同期を要求されると、端末Bはそれにしたがって同期を取る(S610)。相手先端末からログインを要求されると、ログインを許可しデータ転送待ち状態になる(S611)。端末Bは相手先端末のデータ転送用のポートと同期を取り(S614)、相手先端末のデータ転送用のポートからURLを記述したファイルを受信する(S615)。【0109】 URLデータの転送が完了すると、相手先端末のデータ転送用のポートを開放し(S616)、相手先端末からFTPの終了を受け転送終了処理を行なう(S617)。【0110】ファイルを受信した端末Bは、受信したファイルの解析を行なう(S619)。ファイルがSOAPで記述されていて、URLが指定されブラウザを起動させる指示があるなら(S620)、WEBページを表示させるためにブラウザを起動する(S621)。ブラウザに相手先端末から受けたURLを入力すると、端末BはURLで指定されたWEBサーバのアドレスをDNSサーバに問い合わせ、検索結果を受ける(S622)。端末BはDNSサーバから得たIPアドレスを元にWEBサーバにアクセスしてWEBページのデータを受け(S623)、ブラウザにWEBページを表示させる(S624)。【0111】ブラウザを閲覧し終えた端末Bはブラウザを終了させる(S625)。また相手先との通信状態を監視していて(図12S627)、相手先に切断されたことを検出すると通話を終了する(S628)。【0112】以上では、発呼した端末A側から端末B側にURLデータを送信する例を示したが、URLの送信はいずれが発呼側かに関係するものではなく、当然ながら上記と同様にして端末Bから端末AにURLデータを送信し、端末A側で閲覧させることができる。また、以上では、端末A側から端末B側にURLデータを送信する場合、端末A側が端末B側にFTPログインする、つまり端末B側をFTPサーバとして機能させ、端末AがURLデータを送信(図7のS536:この際STOR、ないしSTOUなどのFTPコマンドが用いられる)する例を示した。しかしながら、URLデータ送信の際のFTPのログイン方向、送受信方向(送信コマンドであるSTOR、ないしSTOUを用いるか、受信コマンドであるRETRを用いるか、など)は任意であり、適宜変更してよい。【0113】さて、以上のようにして、通信端末200、220(A、B)間で、WEBブラウザを用いて同一のインターネットリソースを閲覧させることができる。【0114】さらに本実施形態では、同一のインターネットリソースの閲覧をより確実に同期させる。すなわち、通話者が確実に同一の情報を取得できるように保証する制御を行なう。本実施形態では、このために同一のインターネットリソースを閲覧しているWEBブラウザのスクロール状態を通信端末200、220(A、B)間で同期させる。」(段落【0099】?【0114】) (エ)「【0121】 WWWブラウザ(WEBブラウザ)4102は、HTTP(Hｙｐeｒ Teｘｔ Tｒanｓfeｒ Pｒｏｔｏcｏl)のプロトコルに基づき、指示されたサーバとの間でデータのやり取りを行ったり、HTML(Hｙｐeｒ Teｘｔ Maｒkｕｐ Langｕage)あるいはXML(eXｔenｓible Maｒkｕｐ Langｕage)の解析を行い、解析したサーバコンテンツの表示を行なう機能を有している。また、WEBページからアプレットを端末にダウンロードする機能も有している。【0122】ウインドウコントロールブロック4105は、端末において表示を行なう最上位アプリケーション(たとえば通話中表示画面、WEBブラウズ表示画面、FAX操作表示画面など)を端末のLCD表示上にそれぞれ別のウインドウとして表示するための制御を行なうソフトウェアブロックである。本実施形態では、このウインドウコントロールを用いて、VｏIP通話の画面表示アプリケーションとWEBブラウズ表示画面をそれぞれ独立したアプリケーションとして動作させ、それぞれ独立したウインドウとして同時に表示することを可能にする。」(段落【0121】?【0122】) これら記載事項から、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。「IP網で接続され、SIP方式を用いるIP電話通信で、端末Aから端末Bへ呼接続し、通話を行ない、端末AでWEBブラウジングを行なうとともに、IP電話通信中に端末Aから端末BにそのURLデータを転送し、端末AおよびBとの間でWEBブラウザで表示可能な同一のインターネットリソース(ネットコンテンツ(典型的なものとしてはWEBページ))を共有できるようにするものにおいて、端末Aはダイヤル操作を行いSIPサーバに接続し、SIPサーバは相手先端末Bの呼び出しを行なうとともに、端末Aに相手先端末Bの電話番号に対応するIPアドレスを返し、端末Aは呼び出し中状態になり、相手先端末Bが応答するのを待ち、相手先端末Bが応答すると通話状態になり、端末AはWEBページを表示させるためにブラウザを起動し、端末AのブラウザにURLを入力すると、端末AはDNSサーバから得たIPアドレスを元にWEBサーバにアクセスしてWEBページのデータを受け、ブラウザにWEBページを表示し、端末Aは表示させたWEBページを相手先端末Bにも表示させるため、URLをFTPで転送するため、URLを記述したファイルを作成し、ファイルは受信側でブラウザを立ち上げられるようにFTPの上位プロトコルであるSOAPで記述し、端末AはURLを記述したファイルを相手先端末Bに送信し、URLデータの転送が完了すると、端末Aは相手先端末にFTPの終了を通知し転送終了処理を行ない、ブラウザによる閲覧を終えた端末Aはブラウザを終了させ、相手先端末Bとの通話が終了すると通話を切断し、端末Bは、相手先端末AからURLを記述したファイルを受信し、URLデータの転送が完了すると、相手先端末AからFTPの終了を受け転送終了処理を行い、受信したファイルの解析を行ない、ファイルがSOAPで記述されていて、URLが指定されブラウザを起動させる指示があるなら、WEBページを表示させるためにブラウザを起動し、ブラウザに相手先端末Aから受けたURLを入力すると、端末BはURLで指定されたWEBサーバのアドレスをDNSサーバに問い合わせ、検索結果を受け、端末BはDNSサーバから得たIPアドレスを元にWEBサーバにアクセスしてWEBページのデータを受け、ブラウザにWEBページを表示させ、ブラウザを閲覧し終えた端末Bはブラウザを終了させ、また相手先との通信状態を監視していて、相手先に切断されたことを検出すると通話を終了し、さらに、同一のインターネットリソースを閲覧しているWEBブラウザのスクロール状態を通信端末A、B間で同期させることを特徴とするIP電話通信端末の制御方法。」 (2)原査定の拒絶の理由に引用された国際公開2006/077734号(以下、「引用文献2」という。)には、図面と共に次の事項が記載されている。 (ア)「本発明に係る情報処理装置100は、別の情報処理装置100との間でテレビ電話を行なう際に、テレビ電話を実際に行なう「コミュニケーション」と通信相手同士の状態(プレゼンス)を交換し合う「プレゼンス交換」との2つの通信シーケンスによって実現している。ここで、テレビ電話を実際に行なう「コミュニケーション」は、一般的な実現手段を用いることが可能であり、「コミュニケーション」に関する更に詳細な説明は省略するが、SIP(Seｓｓiｏn Iniｔiaｔiｏn Pｒｏｔｏcｏl)を用いた呼制御と、該呼制御により確立された呼に基づいて、RTP(Real-ｔime Tｒanｓｐｏｒｔ Pｒｏｔｏcｏl)を用いたストリームデータ通信とを用いて実現することができる。また、通信相手同士の状態を交換し合う「プレゼンス交換」は、SIP(Seｓｓiｏn Iniｔiaｔiｏn Pｒｏｔｏcｏl)を用いて実現する。図8は、本発明に係る情報処理装置においてSIPプロトコルによるプレゼンス交換の実現手順の一例を説明するためのデータフローチャートであり、情報処理装置100Aと情報処理装置100Bとの間でプレゼンス交換を行なうデータのシーケンスを示している。図8では、情報処理装置100Aにおいて、当該情報処理装置100Aの利用者から情報処理装置100Bの利用者のプレゼンス情報を知りたい旨の指示があった場合、当該情報処理装置100Aは、指定された情報処理装置100Bのプレゼンス情報の取得を要求する旨の情報を、図4に示す相手情報DB60の購読要求リスト62に登録し、情報処理装置100Aから情報処理装置100Bに対して、プレゼンス情報の取得要求を示す状態通知登録要求信号M1として「SUBSCRIBE」信号を送信する。状態通知登録要求信号M1を受信した情報処理装置100Bの利用者が当該情報処理装置100Bの利用者のプレゼンス情報を情報処理装置100Aに対して通知しても良いと判断した場合には、情報処理装置100Aをプレゼンス配布先として追加するように、図4に示す相手情報DB60のプレゼンス配布リスト63に登録し、状態通知登録要求信号M1の「SUBSCRIBE」信号に対する受信確認として、「OK」信号M2を要求元の情報処理装置100Aに対して返送する。一方、情報処理装置100Bの利用者が、自己のプレゼンス情報を通信相手に対して通知したい状況が発生した場合には、自情報DB50から自プレゼンス情報51を読み出して、自己のプレゼンス情報を通知するための状態通知信号M3として「NOTIFY」信号を生成し、プレゼンス配布リスト63に登録されている情報処理装置100Aに対して送信する。状態通知信号M3を受信した情報処理装置100Aは、状態通知信号M3の「NOTIFY」信号に対する受信確認として、「OK」信号M4を送信元の情報処理装置100Bに対して返送する。更に、情報処理装置100Aは、受信した状態通知信号M3に含まれている情報処理装置100Bのプレゼンス情報を、相手情報DB60の相手プレゼンス情報61として登録すると共に、利用者からの表示要求に応じて、モニタ出力処理部48を介してモニタ31に画面表示する。なお、自己のプレゼンス情報を送信する情報処理装置100Bが、状態通知信号M3として「NOTIFY」信号を送信する送信タイミングとしては、 1)当該情報処理装置100Bの利用者の状態(プレゼンス)が変化した時点、 2)情報処理装置100Aからの状態通知登録要求信号M1の「SUBSCRIBE」信号に対する「OK」信号M2を返送した時点、及び、 3)それ以外の任意の時点、の3つの時点を設定することができる。ここで、3)の任意の時点としては、当該情報処理装置100Bの利用者の状態(プレゼンス)が変化していなくても、利用者が送信を指示した時点であっても良いし、あるいは、予め定めた周期で定期的に送信するようにしても構わない。また、SIPプロトコルでは、プレゼンス取得要求元の情報処理装置100Aは、既に、状態通知登録をしている通信相手、即ち、相手情報DB60の相手プレゼンス情報61として登録している通信相手、に対しても、利用者が要求する任意の時点で、状態通知登録要求信号M1の「SUBSCRIBE」信号を送信することができる。また、状態通知登録要求信号M1の「SUBSCRIBE」信号を受信した情報処理装置100Bは、送信元の情報処理装置100Aに対して、必ず、状態通知信号M3としての「NOTIFY」信号を返送することが必要である。従って、情報処理装置100Aの利用者は、状態通知登録要求信号M1の「SUBSCRIBE」信号を所望する任意の時点で送信することを指示することにより、オンデマンドで情報処理装置100Bの利用者のプレゼンスを示す状態通知信号M3の「NOTIFY」信号を受信することができ、所望の時点で通信相手のプレゼンスをリアルタイムに取得して画面表示することが可能である。」(段落【0074】?【0079】) (イ)「次に、利用者がリモコン操作部21を操作して画像登録画面に表示されている自画像を自プレゼンス情報として登録するように指示した場合、登録指示された自画像を含む画像ファイルを、自情報DB50の自画像データ52として登録する(ステップS44)。ここで、自画像データ52の所在場所を自プレゼンス情報51に設定することにより、自プレゼンス情報51を読み出す際に、自画像データ52を読み出すことを可能としている。なお、前述のように、自プレゼンス情報51に自画像データ52とその所在場所とを設定しても良いし、当該情報処理装置100Bとは別の画像蓄積装置(サーバ装置)に保存するようにしても良い。しかる後、プレゼンス配布先として登録されている情報処理装置100Aに対して、登録した自画像データ52に関する情報を含む自プレゼンス情報51を状態通知信号M3の「NOTIFY」信号として配信する(ステップS45)。ここで、状態通知信号M3に含まれる自画像データに関する情報としては、前述のように、自画像データ52の所在場所を示すアドレス情報のみを送信するようにしている。従って、プレゼンス取得要求元の情報処理装置100Aが、相手プレゼンス情報61として相手情報DB60に登録する際に、あるいは、場合によっては、相手プレゼンス情報を画面表示する際に、受信した状態通知信号M3に含まれているアドレス情報から相手の自画像データ52を画像データ110として取得して、取得した画像データ110を相手画像として相手プレゼンス情報61にアドレス情報と共に登録したり、あるいは、場合によっては、取得した画像データ110を相手画像31cとして画面表示する。なお、自情報DB50に登録した自画像データ52にアクセスする参照形式を、HTTP(Hｙｐeｒ Teｘｔ Tｒanｓfeｒ Pｒｏｔｏcｏl)又はFTP(File Tｒanｓfeｒ Pｒｏｔｏcｏl)に準拠する形式として、当該情報処理装置100B内のWebサーバ装置に蓄積するようにしても良い。この場合は、自画像データ52の所在場所は、URL形式で表現されることになる。更には、自情報DB50を蓄積するWebサーバ装置の設置場所としては、前述のように、当該情報処理装置100B内に内蔵する形態のみに限るものではなく、場合によっては、当該情報処理装置100Bの外部に設置したWebサーバ装置であっても良く、図2に示したネットワーク105を介してアクセスすることができるものであれば、如何なる設置形態であっても構わない。当該情報処理装置100Bの外部のWebサーバを用いる場合は、撮影した自画像データ52の画像ファイルを、ネットワーク105を介してWebサーバ装置上にアップロードし、通信相手の情報処理装置100Aが当該自画像データを相手画像として参照する場合は、ネットワーク105を介して該Webサーバ装置の画像ファイルにアクセスすることになる。」(段落【0119】?【0121】) 第5 対比本願発明と引用発明とを対比する。 (ア)引用発明の「WEBページ」は、本願発明の「XMLコンテンツ」と「コンテンツ」である点で共通する。そして、引用発明の「WEBサーバ」は、本願発明の「XMLサーバー」と「コンテンツ」を保存する「サーバー」である点で共通する。 (イ)引用発明の「端末A」は、「SIP方式を用いるIP電話通信で、端末Aから端末Bへ呼接続し、通話を行ない」、「WEBサーバにアクセスしてWEBページのデータを受け、ブラウザにWEBページを表示」するから、本願発明の「第1のXMLコンテンツ表示部を備えたSIP(Session Initiate Protocol)端末」と「第1のコンテンツ表示部を備えたSIP(Session Initiate Protocol)端末」である点で共通するといえる。 (ウ)引用発明の「端末B」は、「SIP方式」を用いており、「IP網で接続され」「WEBサーバにアクセスしてWEBページのデータを受け、ブラウザにWEBページを表示」するから、本願発明の「第2のXMLコンテンツ表示部を備え、前記第1のSIP端末に通信ネットワークを介して接続された第2のSIP端末」と「第2のコンテンツ表示部を備え、前記第1のSIP端末に通信ネットワークを介して接続された第2のSIP端末」である点で共通するといえる。 (エ)引用発明の「端末AはWEBページを表示させるためにブラウザを起動し、端末AのブラウザにURLを入力すると、端末AはDNSサーバから得たIPアドレスを元にWEBサーバにアクセスしてWEBページのデータを受け、ブラウザにWEBページを表示し、端末Aは表示させたWEBページを相手先端末Bにも表示させるため、URLをFTPで転送するため、URLを記述したファイルを作成し、ファイルは受信側でブラウザを立ち上げられるようにFTPの上位プロトコルであるSOAPで記述し、端末AはURLを記述したファイルを相手先端末Bに送信」する構成は、本願発明の「前記第1のSIP端末側にて、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記XMLサーバーに保存されたXMLコンテンツのアドレス情報が記述されたNOTIFYリクエストを前記第2のSIP端末に送信するステップ」と「前記第1のSIP端末側にて、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記サーバーに保存されたコンテンツのアドレス情報が記述された情報を前記第2のSIP端末に送信するステップ」である点で共通するといえる。 (オ)引用発明の「端末Bは、相手先端末AからURLを記述したファイルを受信し、URLデータの転送が完了すると、相手先端末AからFTPの終了を受け転送終了処理を行い、受信したファイルの解析を行ない、ファイルがSOAPで記述されていて、URLが指定されブラウザを起動させる指示があるなら、WEBページを表示させるためにブラウザを起動し、ブラウザに相手先端末Aから受けたURLを入力すると、端末BはURLで指定されたWEBサーバのアドレスをDNSサーバに問い合わせ、検索結果を受け、端末BはDNSサーバから得たIPアドレスを元にWEBサーバにアクセスしてWEBページのデータを受け、ブラウザにWEBページを表示」する構成は、本願発明の「前記第2のSIP端末側にて、前記XMLコンテンツのアドレス情報を受け前記XMLサーバーから前記XMLコンテンツを取得し、取得した前記XMLコンテンツの一部情報を画面表示させるステップ」と「前記第2のSIP端末側にて、前記コンテンツのアドレス情報を受け前記サーバーから前記コンテンツを取得し、取得した前記コンテンツの情報を画面表示させるステップ」である点で共通するといえる。 (カ)引用発明の「IP電話通信端末の制御方法」は、「端末AおよびBとの間でWEBブラウザで表示可能な同一のインターネットリソース(ネットコンテンツ(典型的なものとしてはWEBページ))を共有できるようにする」から、本願発明の「双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法」に相当するといえる。そうすると、本願発明の用語を用いると両者は次の点で一致する。「サーバーと、第1のコンテンツ表示部を備えた第1のSIP(Session Initiate Protocol)端末と、第2のコンテンツ表示部を備え、前記第1のSIP端末に通信ネットワークを介して接続された第2のSIP端末における双方向コンテンツ表示の制御処理ステップを有する双方向コンテンツ表示方法において、前記双方向コンテンツ表示制御処理ステップは、前記第1のSIP端末側にて、前記第1および前記第2のSIP端末同士の通話中、前記第1のSIP端末から前記サーバーに保存されたコンテンツのアドレス情報が記述された情報を前記第2のSIP端末に送信するステップと、前記第2のSIP端末側にて、前記コンテンツのアドレス情報を受け前記サーバーから前記コンテンツを取得し、取得した前記コンテンツの情報を画面表示させるステップを有することを特徴とする双方向コンテンツ表示方法。」そして、両者は次の(1)?(3)の点で相違する。 (1)本願発明は、「コンテンツ」が、「XMLコンテンツ」であって、「サーバー」、「コンテンツ表示部」及び「サーバーに保存されたコンテンツのアドレス」がそれぞれ「XMLサーバー」、「XMLコンテンツ表示部」及び「XMLサーバーに保存されたXMLコンテンツのアドレス」であるのに対し、引用発明は、「コンテンツ」が、「WEBぺージ」であって、「サーバー」、「コンテンツ表示部」及び「サーバーに保存されたコンテンツのアドレス」が、それぞれ「WEBサーバ」、「WEBブラウザ」及び「WEBページ」の「URL」である点。 (2)本願発明は、「コンテンツのアドレス情報が記述されたNOTIFYリクエストを」「送信する」のに対し、引用発明は、コンテンツの「URLを記述したファイルを」「FTPで送信する」点。 (3)本願発明は、「前記第2のSIP端末側にて、」「コンテンツの一部情報を画面表示させる」のに対し、引用発明は、端末Bにて、「ブラウザにWEBページ」の一部情報を表示させるような記載はない点。第6 当審の判断・相違点(1)について引用文献1には、「WWWブラウザ(WEBブラウザ)4102は、HTTP(Hｙｐeｒ Teｘｔ Tｒanｓfeｒ Pｒｏｔｏcｏl)のプロトコルに基づき、指示されたサーバとの間でデータのやり取りを行ったり、HTML(Hｙｐeｒ Teｘｔ Maｒkｕｐ Langｕage)あるいはXML(eXｔenｓible Maｒkｕｐ Langｕage)の解析を行い、解析したサーバコンテンツの表示を行なう機能を有している。」(記載事項(エ)、段落【0121】)と記載されており、サーバに保存されているコンテンツがXMLコンテンツであり、ブラウザがXMLコンテンツを表示することが示されている。そうすると、引用発明において、「WEBぺージ」を「XMLコンテンツ」とし、「WEBサーバ」、「WEBブラウザ」及び「WEBページ」の「URL」を、それぞれ、「XMLサーバー」、「XMLコンテンツ表示部」及び「XMLサーバーに保存されたXMLコンテンツのアドレス」とすることは、当業者が容易になし得ることである。・相違点(2)について引用文献2には、情報処理装置100Bは、自画像データ52を外部の画像蓄積装置(サーバ装置)に保存し、プレゼンス配布先として登録されている情報処理装置100Aに対して、自画像データ52の所在場所を示すアドレス情報をSIPの「NOTIFY」信号として送信することが記載されている。したがって、上記引用文献2に記載された技術を採用し、引用発明において、「コンテンツのアドレス情報が記述されたNOTIFYリクエストを」「送信する」ようにすることは、当業者が容易になし得ることである。・相違点(3)について本願発明の「前記第2のSIP端末側にて、前記XMLコンテンツのアドレス情報を受け前記XMLサーバーから前記XMLコンテンツを取得し、取得した前記XMLコンテンツの一部情報を画面表示させるステップ」の画面表示させる「取得した前記XMLコンテンツの一部情報」とは、どのような情報であるのか明確ではなく、本願明細書の発明の詳細な説明を参照すると、「指定されたアドレスのXMLコンテンツ情報を受信すると、XMLコンテンツ解析部50に当該XMLコンテンツ情報を送信し、そのXMLコンテンツ情報の解析を要求する。XMLコンテンツ表示アプリケーション20はXMLコンテンツ解析部50が解析したXMLコンテンツ情報を受信し、当該XMLコンテンツ情報をGUI表示部(大画面LCD)に表示させるようにXMLコンテンツ情報表示コマンドをGUI表示部60に送信する。当該表示要求を受信したGUI表示部60は前記XMLコンテンツ情報を表示する。」(段落【0019】)及び「XMLコンテンツ表示アプリケーション20は受け取ったアドレスへのアクセスをHTTPメッセージ送受信部40に要求し、XMLコンテンツ解析部50によるXMLサーバー101から受信したレスポンス解析結果をGUI表示部に表示する。これにより、SIP端末A200とSIP端末B201の間で通話をしながら同じ画像情報確認することができる。」(段落【0025】)と記載されているが、画面表示させる「取得した前記XMLコンテンツの一部情報」が、具体的にどのような情報であるのかの記載はない。そうすると、引用発明は、「同一のインターネットリソースを閲覧しているWEBブラウザのスクロール状態を通信端末A、B間で同期させる」ものであるから、端末B側にて取得したコンテンツの一部情報を順次スクロール表示していることは明らかであり、この点は実質的な差異ではない。そして、本願発明による効果も、引用発明及び引用文献2に記載の技術から当業者が予測し得る範囲のものである。第7 むすび以上のとおり、本願発明は、引用発明及び引用文献2に記載の技術に基づいて、当業者が容易に発明することができたものであるから、特許法第29条第2項の規定により特許を受けることができない。したがって、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。よって、結論のとおり審決する。なお、請求人は前置審尋の回等書において、補正案を提示し、「審判請求人において検討の結果、本ご認定に応答して、また、必要に応じて、特許請求の範囲を補正する用意があることをお伝え致します。出願時明細書第0022段落には、XMLコンテンツ表示アプリケーション20が、XMLサーバー101のデフォルトコンテンツアドレスへのアクセス要求をHTTPメッセージ送受信部40に送信することが記載されています。また、同第0023段落には、SIP端末A200の電話機機能アプリケーション10が、現在アクセス中のXMLコンテンツアドレス情報をSIPメッセージ送受信部30に送信することが記載されています。これらの記載から、デフォルトコンテンツアドレスに対応するデフォルトコンテンツが存在し、その一部としてXMLコンテンツのアドレス情報が含まれていることがお分かりいただけるものと思量致します。このように、本発明では、デフォルトコンテンツアドレスが示すデフォルトコンテンツの全体ではなく、デフォルトコンテンツからその一部として含まれるXMLコンテンツのアドレス情報を取得します。そして、そのアドレス情報に対応するXMLコンテンツをXMLサーバから取得して、SIP端末の画面に表示します。このようにすることにより、SIP端末における情報の表示を、比較的処理負荷が軽いXMLコンテンツ表示アプリケーションにて行なうことができるようになります。このことは出願時明細書第0014段落に記載されています。このような特徴をより明瞭なものとするため、独立項である請求項1、4を下記のように補正する用意があります。仮に審判官殿が前置報告書を支持される場合であっても、補正後の請求項に係る発明によれば、引用文献記載発明との相違がより明瞭なものとなると思量致します。」と述べている。しかしながら、上記明細書第0022、0023段落、0014段落には、補正案の請求項1、4における「前記XMLサーバーに保存され、第1のアドレス情報によって指定される第1のコンテンツの一部を構成するXMLコンテンツのアドレス情報」について記載されておらず、自明であるとも認められない。したがって、補正案は採用できない。
審理終結日	2013-06-07
結審通知日	2013-06-12
審決日	2013-06-26
出願番号	特願2007-56055(P2007-56055)
審決分類	P 1 8・ 572- Z (G06F) P 1 8・ 121- Z (G06F)
最終処分	不成立
前審関与審査官	▲はま▼中信行、鈴村理絵子
特許庁審判長	和田志郎
特許庁審判官	稲葉和生衣川裕史
発明の名称	双方向コンテンツ表示システム及び方法
代理人	佐々木敬
代理人	池田憲保
代理人	福田修一

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