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

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

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

PDF	PDFをダウンロード

審決分類	審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない(前置又は当審拒絶理由) G06F 審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) G06F
管理番号	1279239
審判番号	不服2011-19577
総通号数	167
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2013-11-29
種別	拒絶査定不服の審決
審判請求日	2011-09-09
確定日	2013-09-11
事件の表示	特願2002-518693「トピック的サービスによるホームネットワーク用のコンテキスト情報の提供」拒絶査定不服審判事件〔平成14年 2月14日国際公開、WO02/13463、平成16年 2月26日国内公表、特表2004-506281〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は、2001年7月30日(パリ条約による優先権主張、2000年8月10日、米国)を国際出願日とする出願であって、平成23年4月21日付けで拒絶査定がされ(発送日:同年5月10日)、これに対して同年9月9日に拒絶査定不服審判の請求がなされるとともに、手続補正がされたものであり、さらに、平成24年12月11日付けで、当審において拒絶理由(以下「当審拒絶理由」という。)が通知され、これに対して、平成25年3月14日に意見書及び補正書が提出されたものである。第2 当審拒絶理由平成24年12月11日付け当審拒絶理由の概要は、以下のとおりである。＜理由1 進歩性の拒絶理由＞本願の請求項1-15に係る発明は、その優先日前日本国内又は外国において頒布された下記の刊行物に記載された発明に基づいて、その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。記 1.特開平11-259491号公報 2.Micｒｏｓｏfｔ Cｏｒｐｏｒaｔiｏn、Undeｒｓｔanding Uniｖeｒｓal Plｕg and Plaｙ、ｗhiｔe ｐaｐeｒ、[online]、2000年6月、ｐ.1-39、[平成24年12月5日検索]、インターネット＜URL:http://www.upnp.org/download/UPNP_understandingUPNP.doc＞ 3.本田雅一、「海外リポート WinHEC ＆ Windｏｗｓ 2000 Reｖieｗeｒ’ｓ Wｏｒkｓhｏｐ」、ASCII、株式会社アスキー、1999年6月1日、第23巻、第6号、ｐ.214-223 ＜理由2 記載不備の拒絶理由＞この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。記 (1) 請求項1で、「HTTPマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のURLを得る」とあるが、本願明細書には、段落【0032】に「DVDプレーヤ102はUPnP規格に従いHTTPマルチキャストメカニズムを用いてインターネットゲートウェイ118を見付ける。」ことは記載があるものの、装置が、「インターネットゲートウェイから」、「前記所定のURLを得る」ことすなわち「該装置の型式に固有の所定のURL」を得ることは、記載がないと認められる。請求項2-15も同様である。以下、上記各理由が解消したか否かについて、まず＜理由2＞について検討し、次いで＜理由1＞について検討する。第3 特許法第36条第6項第1号について 1.本願発明本願の請求項1に係る発明(以下、「本願発明」という。)は、平成25年3月14日付け手続補正書の特許請求の範囲に記載された次のとおりのものである。「ホームネットワーク上の装置を表すプロキシデバイスにおいて、前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置の型式に固有の所定のURLによる制御の下でネットワークを経由してサーバからのデータの取り込みをゲートウェイ及び前記入力装置を介して開始するプロキシデバイスであって、当該プロキシデバイスは前記装置に貼付され、前記データは、前記装置の使用のコンテキストに関するコンテンツ情報を表しており、前記装置においてネットワークが構成化されていない場合には、UPnPに従うHTTPマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のURLを得ることを特徴とするプロキシデバイス。」 2.当審拒絶理由の＜理由2 記載不備の拒絶理由＞について当審拒絶理由の＜理由2 記載不備の拒絶理由＞は、上記「第2 当審拒絶理由」に記載のとおりである。本願の請求項1には、「前記装置においてネットワークが構成化されていない場合には、UPnPに従うHTTPマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のURLを得る」との記載がある。一方、本願明細書の段落【0032】には、次の記載がある。「ユーザがリモコン108上のサービスアクセス釦124を押下した場合、もし、以前の機会にネットワーク106が構成化されていなかった場合には、DVDプレーヤ102はUPnP規格に従いHTTPマルチキャストメカニズムを用いてインターネットゲートウェイ118を見付ける。DVDプレーヤ102はインターネットゲートウェイ118のUPnP記述ドキュメントを得ると共に、インターネットアドレスをマップするために要するUPnPサービスのアドレスを得る。次いで、DVDプレーヤ102はインターネットゲートウェイサービスを用いて、外部サーバ120のアドレスを得る。その後、DVDプレーヤ102はHTTPプロトコルを用いて外部サーバ120のウェブページを要求し、取り込む。当該データを受信すると、DVDプレーヤ102は、例えばHTML文書の該データをビデオ信号に変換し、該信号をSビデオケーブルを介してTV104に送出する。」これらの記載から、本願明細書の段落【0032】は、そもそも「DVDプレーヤ102」すなわち本願発明の「装置」自体に係る記載であって、本願発明の「プロキシデバイス」に係る記載はない。そして、「DVDプレーヤ102」が、「UPnP規格に従いHTTPマルチキャストメカニズムを用いてインターネットゲートウェイ118を見付ける。」こと、すなわち、UPnP規格におけるHTTP上のマルチキャスト通信による、所定のデバイス(インターネットゲートウエイ118)の発見(ディスカバリ)に関する記載はあるが、「前記装置においてネットワークが構成化されていない場合には」、「HTTPマルチキャストメカニズムを用いて」、「インターネットゲートウェイから」、「前記所定のURL」すなわち「装置の型式に固有の所定のURL」を得ることについては、記載も示唆もないと認められる。請求人は、「明細書の段落0032には、以下のように記載されております。『もし、以前の機会にネットワーク106が構成化されていなかった場合には、DVDプレーヤ102はUPnP規格に従いHTTPマルチキャストメカニズムを用いてインターネットゲートウェイ118を見付ける。DVDプレーヤ102はインターネットゲートウェイ118のUPnP記述ドキュメントを得ると共に、インターネットアドレスをマップするために要するUPnPサービスのアドレスを得る。次いで、DVDプレーヤ102はインターネットゲートウェイサービスを用いて、外部サーバ120のアドレスを得る。』(下線は強調のために引いております)上記の下線部分に記載されているように「インターネットアドレスをマップするために要するUPnPサービスのアドレス」は、請求項1に記載されている「前記所定のURL」であります。したがって、請求項1の記載は、明細書の記載によってサポートされており、本拒絶の理由は存在しないと思量いたします。」旨主張する。しかし、上記のとおり、段落【0032】は、そもそも本願発明の「プロキシデバイス」に係る記載ではない。そして、明細書段落【0032】の上記請求人がサポート要件に関して引用する下線部は、「インターネットアドレスをマップするために要する「UPnPサービスのアドレス」をインターネットゲートウェイから得ることに関する記載であって、アドレスのマッピング機能、すなわち、アドレス変換機能を提供する「UPnPサービスのアドレス」は、本願の請求項1における「前記所定のURL」すなわち「装置の型式に固有の所定のURL」とは異なると認められるから、この主張は採用できない。したがって、当審拒絶理由における、特許法第36条第6項第1号についての＜理由2 記載不備の拒絶理由＞は解消していない。 3.小括したがって、請求項1に係る発明は、発明の詳細な説明に記載したものであるとはいえないので、本件出願は、特許法第36条第6項第1号に規定する要件を満たしておらず、特許を受けることができない。第4 特許法第29条第2項について 1.本願発明本願発明は、上記「第3 特許法第36条第6項第1号について、1.本願発明」に記載されたとおりのものである。 2.引用文献当審拒絶理由で引用された、本願の優先日前である平成11年9月24日に公開された、特開平11-259491号公報(以下、「引用文献」という。)には、以下の記載がある(下線は当審付与。)。 (1) 段落【0001】-【0007】「【0001】【発明の属する技術分野】本発明は、設備に付帯するURLなどの識別情報を自動的に取得してその設備に関するホームページの情報を閲覧することができる関連ホームページ自動閲覧システムに関する。【0002】【従来の技術】携帯端末でブラウザを使って、特定の情報がファイルされているホームページの情報を得ようとする場合、従来技術では、予め調べてあるそのホームページのURL(Uniform Resource Locator)をインプットして、そのページを呼び出していた。【0003】すなわち、ある設備Aの前に行った時に、その設備Aの各種制御ができるホームページを見るためには、設備Aに関連するホームページのURLを携帯端末にインプットする。また、他の設備Bの前に行ってその設備Bに関連するホームページを見る場合でも、設備Bに関連するホームページのURLを携帯端末にインプットするようにしている。【0004】【発明が解決しようとする課題】このように、その都度、設備A,B,…に関連するホームページのURLを携帯端末にインプットするのは、入力操作に手間がかかるばかりか、URLを知らない場合や、忘れた場合には、それらの設備A,B,…にアクセスすることができない。【0005】また、検索エンジンを使ってそのページを探すことも可能であるが、時間がかかるし、そのページを発見できない場合もある。【0006】さらに、携帯端末内にそれぞれの設備A,B等のホームページのURLを予め記憶させておくことも可能であるが、記憶させたURLの数が多い場合は、その中から必要なURLを選ばなければならず、それだけ余分な時間がかかることにもなる。【0007】本発明は、上記の問題点を解決するためになされたもので、URLを知らなくても即時にその設備に関連するホームページにアクセスして、必要な情報を入手したり、関連する設備の制御ができるようにすることを課題とする。」 (2) 段落【0020】-【0026】「【0020】【発明の実施の形態】図1は、この関連ホームページ自動閲覧システムの全体を示す構成図である。【0021】この関連ホームページ自動閲覧システムは、たとえば工場などの各種の設備X_(1),X_(2),X_(3),…に対して個別に発信装置2が配置される一方、各設備X_(1),X_(2),X_(3),…に関するホームページを格納するとともにそれらの設備X_(1),X_(2),X_(3),…を制御するサーバー(本例ではパソコン)4と、発信装置2から発信される情報を受信してサーバー4が格納するホームページにアクセスする携帯端末6とを含む。【0022】上記の発信装置2は、各設備X_(1),X_(2),X_(3),…に関するホームページを開くために必要となるURLを発信するものであって、図2に示すように、マイコン2a、URLや各種のデータ等を記憶するメモリ2b、URLを赤外線で発信するための発光素子2c、携帯端末6からのURL発信要求の赤外線信号を受けるための受光素子2d、両素子2c,2dを駆動する光素子ドライバ2e、電源2f、およびパイロットランプ2gなどから構成されている。【0023】この発信装置2のメモリ2bに対して予め各設備X_(1),X_(2),X_(3)…に関して固有のURL情報をインプットするには、携帯端末6側から赤外線で受光素子2d経由で行ったり、あるいは、サーバー4から有線で各発信装置2のマイコン2aに対してI/O経由で行うことができる。【0024】なお、発信装置2が常時、発光素子2cからURLを発信する構成とする場合には、受光素子2dを省略することが可能である。【0025】サーバー4は、本体部4aに無線機4bが接続されて構成されており、この無線機4bによって、携帯端末6との間で携帯電話回線やPHS回線等によってホームページを開くためのブラウザデータの通信等が行えるようになっている。【0026】一方、上記の携帯端末6は、サーバー4との間で無線通信を行うための機能と、発信装置2との間でIｒDA規格などの赤外線通信を行うための機能を有するとともに、LCD等の表示部6aを備えており、この表示部6aには、URL発信要求の赤外線信号を発信したり各種の情報を入力するためのタッチパネル(図示省略)が設けられている。そして、表示部6aには、サーバー4から送信されるホームページの情報が表示されてその内容を閲覧できるようになっている。」 (3) 段落【0028】-【0035】「【0028】次に、上記構成の関連ホームページ自動閲覧システムにおける具体的な操作例を、図3に示すフローチャートを参照して説明する。なお、ここでは、一つの設備X_(1)についての操作について説明するが、その他の設備X_(2),X_(3)…に関してアクセスする場合も同様である。【0029】まず、携帯端末6を持参して、所望の設備X_(1)の前に位置する(ステップ1)。【0030】設備X_(1)に配置されている発信装置2が、常時、当該設備X_(1)に関するURA(審決注:「URA」は「URL」の誤記と認める。)情報を赤外線で発信していない場合には(ステップ2)、携帯端末6のほうから設備X_(1)に向けてURL発信要求の信号を赤外線で送信する(ステップ3)。これには、たとえば、表示部6aの画面のタッチパネルを操作したりして行う。【0031】URL発信要求を受けた発信装置2は、この発信装置2が配置されている設備X_(1)に該当するホームページのURLを赤外線通信などで携帯端末6に向けて送信する(ステップ4)。【0032】携帯端末6が該当するホームページのURLを受信すると(ステップ5)、この携帯端末6は、電話などの無線通信を使ってホームページを格納しているサーバー4にアクセスして、その設備X_(1)に関連するホームページを開く(ステップ6)。【0033】すなわち、その設備X_(1)に関連するホームーぺージ(審決注:「ホームページ」の誤記と認める。)は、携帯端末6の表示部6aに表示されるので、その表示部6aのタッチパネルの操作により設備X_(1)に関する各種の情報を取り出すことができる(ステップ7)。【0034】なお、設備X_(1)に配置されている発信装置2が、常時、当該設備X_(1)に関するURA情報を赤外線で発信している場合には、携帯端末6は直ちに該当するホームページのURLを受信することができ(ステップ8)、この携帯端末6によってその設備X_(1)に関連するホームページを開くことができる(ステップ6)。【0035】また、サーバー4の本体部4aにCGI(Computer Graphics Interface)等の機能を備えるものでは、さらに携帯端末6のタッチパネルの操作により、当該設備X_(1)の制御をすることができる。」 (4) 段落【0036】-【0048】「【0036】上記の実施形態では、工場などの各種設備の情報を取り出したり設備の制御を行う場合について説明したが、それ以外の例を次に説明する。【0037】図4には本発明を各種展示会において展示物の内容を説明するために適用した場合の例を示す。【0038】展示会において、展示物が置かれているパネルY_(1),Y_(2),Y_(3),…の前に立った時にそのパネルY_(1),Y_(2),Y_(3),…に個別に設置されている発信装置2から発信されているURLを携帯端末6で受信して、その展示物に関して説明しているホームページを開くことができる。なお、この場合、説明を図形や文字だけでなく、音声で行うこともできる。このようにすれば、テープによる音声説明よりも観覧者の自由なタイミングに合わせて説明をスタートできるので都合がよい。なお、必要に応じて携帯端末6を操作して展示物を制御できるようにしてもよい。【0039】図5には本発明を店舗の内容を説明するために適用した場合の例を示す。【0040】各店舗Z_(1),Z_(2),Z_(3),…の入口にそれぞれ発信装置2を設置し、その店の前に行って携帯端末6でURLを取得すると、その店舗たとえばZ_(2)のサービス内容を自由に閲覧することができる。【0041】一例としてレストランの場合なら、写真付きのメニューとか日替わり商品とか値段等の情報を得たり、テーブルやメニュー・弁当の予約をすることができる。また、金融機関ならば、各商品のその日の利率情報を取得することができる。【0042】なお、発信装置2は店舗Z_(1),Z_(2),Z_(3),…の入口に設置する他に店舗を表示する看板等の物体に設置してもよい。【0043】図6には本発明を交通情報を取得する場合に適用した場合の例を示す。【0044】道路を跨いで設置されたガントリGに取り付けられた発信装置2から道路を走行している車両Cに配備した図示しない携帯端末によって、道路付近や進行方向の交通情報を発信しているホームページのURLを取得して所望の情報を得ることができる。【0045】その場合、予め、携帯端末にインストールされている地図上にその交通情報を重ねて表示させることもできる。【0046】なお、URL取得の手段は、この実施形態のような赤外線通信の他に、無線通信を使ってもよい。無線通信の場合は、他の装置の無線との混信が無い程度のパワーにする必要がある。【0047】また、上記の実施形態では、各種の設備X_(1),X_(2),X_(3),…に設置した発信装置2からそれらの各設備固有のURLを発信するように構成したが、識別情報としてはURLの代わりに各設備X_(1),X_(2),X_(3),…に固有のIDを送信することも可能である。【0048】すなわち、発信装置2からはURLの代わりに、A,B,Cなどの設備X_(1),X_(2),X_(3),…固有のIDを携帯端末6に対して送信し、図7に示すように、携帯端末6に記憶しているIDとURLとの対応テーブルを参照して該当するURLを選択し、そのURLを格納しているサーバー4にアクセスするようにしてもよい。」よって、引用文献には、次の発明(以下、「引用発明」という。)が開示されているものと認められる。「設備に付帯するURLなどの識別情報を自動的に取得してその設備に関するホームページの情報を閲覧することができる関連ホームページ自動閲覧システムであって、関連ホームページ自動閲覧システムは、たとえば工場などの各種の設備X_(1),X_(2),X_(3),…に対して個別に発信装置2が配置される一方、各設備X_(1),X_(2),X_(3),…に関するホームページを格納するとともにそれらの設備X_(1),X_(2),X_(3),…を制御するサーバー4と、発信装置2から発信される情報を受信してサーバー4が格納するホームページにアクセスする携帯端末6とを含み、一つの設備X_(1)についての操作は、まず、携帯端末6を持参して、所望の設備X_(1)の前に位置し(ステップ1)、設備X_(1)に配置されている発信装置2が、常時、当該設備X_(1)に関するURL情報を赤外線で発信していない場合には(ステップ2)、携帯端末6のほうから設備X_(1)に向けてURL発信要求の信号を赤外線で送信し(ステップ3)、これには、表示部6aの画面のタッチパネルを操作したりして行い、 URL発信要求を受けた発信装置2は、この発信装置2が配置されている設備X_(1)に該当するホームページのURLを赤外線通信などで携帯端末6に向けて送信し(ステップ4)、携帯端末6が該当するホームページのURLを受信すると(ステップ5)、この携帯端末6は、電話などの無線通信を使ってホームページを格納しているサーバー4にアクセスして、その設備X_(1)に関連するホームページを開き(ステップ6)、その設備X_(1)に関連するホームぺージは、携帯端末6の表示部6aに表示されるので、その表示部6aのタッチパネルの操作により設備X_(1)に関する各種の情報を取り出すことができ(ステップ7)、また、サーバー4の本体部4aにCGI等の機能を備えるものでは、さらに携帯端末6のタッチパネルの操作により、当該設備X_(1)の制御をすることができ、上記の工場などの各種設備の情報を取り出したり設備の制御を行う場合以外の例は、各種展示会において展示物の内容を説明するために適用した場合、展示会において、展示物が置かれているパネルY_(1),Y_(2),Y_(3),…の前に立った時にそのパネルY_(1),Y_(2),Y_(3),…に個別に設置されている発信装置2から発信されているURLを携帯端末6で受信して、その展示物に関して説明しているホームページを開くことができ、店舗の内容を説明するために適用した場合、各店舗Z_(1),Z_(2),Z_(3),…の入口にそれぞれ発信装置2を設置し、その店の前に行って携帯端末6でURLを取得すると、その店舗たとえばZ_(2)のサービス内容を自由に閲覧することができ、レストランの場合なら、写真付きのメニューとか日替わり商品とか値段等の情報を得たり、テーブルやメニュー・弁当の予約をすることができ、金融機関ならば、各商品のその日の利率情報を取得することができ、発信装置2は店舗Z_(1),Z_(2),Z_(3),…の入口に設置する他に店舗を表示する看板等の物体に設置してもよく、交通情報を取得する場合、道路を跨いで設置されたガントリGに取り付けられた発信装置2から道路を走行している車両Cに配備した携帯端末によって、道路付近や進行方向の交通情報を発信しているホームページのURLを取得して所望の情報を得ることができ、また、上記では、各種の設備X_(1),X_(2),X_(3),…に設置した発信装置2からそれらの各設備固有のURLを発信するように構成したが、識別情報としてはURLの代わりに各設備X_(1),X_(2),X_(3),…に固有のIDを送信することも可能であり、すなわち、発信装置2からはURLの代わりに、A,B,Cなどの設備X_(1),X_(2),X_(3),…固有のIDを携帯端末6に対して送信し、携帯端末6に記憶しているIDとURLとの対応テーブルを参照して該当するURLを選択し、そのURLを格納しているサーバー4にアクセスするようにしてもよい、関連ホームページ自動閲覧システム。」 3.周知文献1-3 (1) 周知文献1 当審拒絶理由で引用された、周知文献1(Micｒｏｓｏfｔ Cｏｒｐｏｒaｔiｏn、Undeｒｓｔanding Uniｖeｒｓal Plｕg and Plaｙ、ｗhiｔe ｐaｐeｒ、[online]、2000年6月、ｐ.1-39、[平成24年12月5日検索]、インターネット＜URL:http://www.upnp.org/download/UPNP_understandingUPNP.doc＞)には、以下の記載がある(下線は当審付与。)。 a.8頁12-29行「The Well Connected Home It is easy to consider a home in which UPnP makes life easier or richer for many of the day-to-day tasks. Kitchen appliances could be connected to a power line network to form a home network. Information for each of the appliances, such as model, make, and serial number, could be accessed from many locations and retrieved for service calls. A URL for the manufacturer and manual could be accessed for anyone who wants to repair appliances on their own. ・・・(中略)・・・ You could have a kitchen tablet on which you could make online product selections as you peruse your cupboards to see what's missing. An attached bar code scanner might make making lists easier. This device would have automatic access to the home network and Internet using UPnP.」 (当審訳:事例「上手く接続された家庭」 UPnPが、日々のタスクの多くについて、生活をより暮らしやすく豊かなものにする家庭を考察するのは容易である。台所用器具を、ホームネットワークを形成するため、電力線ネットワークに接続できる。修理・保守依頼の電話のために、各器具の情報、例えば、型式、メーカー、製造番号等に多くの場所からアクセスして、検索できるかもしれない。器具を自分で修理したい人は誰でも、メーカーと、取扱説明書のURLにアクセスできる。・・・(中略)・・・あなたは、何が足りないかを見るために食器棚を精査しながら、台所用タブレット上でオンラインで商品を選択できる。付属のバーコードスキャナがあれば、リスト作りはさらに簡単になるだろう。このデバイスは、UPnPを利用することにより、ホームネットワークとインターネットへの自動的なアクセスを備えるだろう。) b.14頁30行-15頁13行「SSDP Simple Service Discovery Protocol (SSDP), as the name implies, defines how network services can be discovered on the network. SSDP is built on HTTPU and HTTPMU and defines methods both for a control point to locate resources of interest on the network, and for devices to announce their availability on the network. ・・・(中略)・・・ Both control points and devices use SSDP. A UPnP control point, upon booting up, can send an SSDP search request (over HTTPMU), to discover devices and services that are available on the network. The control point can refine the search to find only devices of a particular type(such as a VCR), particular services (such as devices with clock services) or even a particular device. UPnP devices listen to the multicast port. Upon receiving a search request, the device examines the search criteria to determine if they match. If a match is found, a unicast SSDP (over HTTPU) response is sent to the control point. Similarly, a device, upon being plugged into the network, will send out multiple SSDP presence announcements advertising the services it supports. Both presence announcements and unicast device response messages contain a pointer to the location of the device description document, which has information on the set of properties and services supported by the device.」 (当審訳:SSDPについてシンプル・サービス発見プロトコル(SSDP)は、その名前が意味するとおり、ネットワーク上で、ネットワーク・サービスを発見する方法を定義する。SSDPは、HTTPUとHTTPMU上で構築され、制御点がネットワーク上で興味のある資源を見つける方法と、デバイスがネットワーク上で自己が利用可能であるとアナウンスする方法の両方を定義している。・・・(中略)・・・制御点とデバイスは、共にSSDPを使用する。UPnP制御点は、起動時に、ネットワーク上で利用可能なデバイスとサービスを発見するために、(HTTPMU上の)SSDP探索リクエストを送る。制御点は、特定の型式(例えば、VTR)、特定のサービス(例えば、時計サービスを備えるデバイス)、又は特定デバイスのみを発見するようにさえ、探索を洗練できる。 UPnPデバイスは、マルチキャスト・ポートを聴取している。探索リクエストを受信すると、デバイスは、サーチの規準との一致を判断するために検討を行う。一致が見つかった場合、(HTTPU上の)ユニキャストSSDP応答が制御点に送られる。同様に、デバイスは、ネットワークに接続された場合、自己がサポートするサービスを広告するために、多数のSSDPプレゼンスのアナウンスを送出する。プレゼンスのアナウンスと、ユニキャストのデバイス応答メッセージはどちらも、デバイスがサポートするプロパティとサービスの集合についての情報を有する、デバイス記述ドキュメントの位置へのポインタを含む。) c.20頁19行-31行「An Example UPnP Network To further understand when and how each of the steps in UPnP networking takes place, it helps to define a small network with just a few UPnP devices. We can then describe how these devices interact as it relates to UPnP. For this paper I have chosen a network that contains the following UPnP enabled devices: An Internet Gateway. This device could be a standalone gateway device or a PC acting as a gateway. The device may be a control point, yet may not. Services provided by the device might include Internet access, a Dynamic Host Configuration Protocol (DHCP) server, a DNS proxy and a storage service. The gateway will also connect to several home LAN media and serve as a bridge for these media. Media used includes IEEE 802.11 Wireless, A Power Line network, A Phone Line network, and IEEE 1394.」 (当審訳:UPnPネットワークの具体例 UPnPネットワーキングの各ステップが、いつ、どのように起こるかについて、さらに理解するには、僅かな数のUPnP装置だけを備えた小規模なネットワークを定義することが役立つ。その後、我々は、これらの装置が、UPnPに関連すると共に、どのように相互作用するかを説明する。この論文のため、私は以下のUPnP可能化装置を含むネットワークを選択した: インターネット・ゲートウエイ:この装置は、スタンド・アロンのゲートウエイ装置、または、ゲートウエイとして動作するPCであり得る。この装置は、制御点である場合も、そうでない場合もある。この装置が提供するサービスには、インターネット・アクセス、ダイナミック・ホスト構成プロトコル(DHCP)サーバ機能、DNSプロキシ機能、ストレージ・サービスを含むだろう。ゲートウエイは、さらにいくつかの家庭内LAN媒体に接続し、これらの媒体のブリッジとして機能し得る。使用される媒体には、IEEE802.11、無線、電力線ネットワーク、電話線ネットワーク、IEEE1394を含む。) (2) 周知文献2 当審拒絶理由で引用された、周知文献2(本田雅一、「海外リポート WinHEC ＆ Windｏｗｓ 2000 Reｖieｗeｒ’ｓ Wｏｒkｓhｏｐ」、ASCII、株式会社アスキー、1999年6月1日、第23巻、第6号、ｐ.214-223)には、以下の記載がある(下線は当審付与。)。 d.216頁中欄10行-217頁右欄15行「Uniｖeｒｓal Plｕg ＆Plaｙは家庭でのPCの地位を高める? Uniｖeｒｓal Plｕg ＆ Plaｙ(UPnP)は,Micｒｏｓｏfｔが中心となって提唱しているシンプルネットワーク構築のためのプロトコルだ(4月号ｐ.183,http://www.upnp.org/参照)(スライド3?5)。これまでMicｒｏｓｏfｔはUPnPに関して,TCP/IPベースの通信を基本とし,HTTPとXMLで情報を交換し,なんらかの標準プロトコルで機器発見の仕組みを構築することをアナウンスしていた。WinHECでは,これをもう少し具体的な話にし,機器へ実装する際の具体的な取り決めに関しての発表がなされた。ネットワーク上で機器間のコミユニケーションを正常に行なうためには,ネットワーク接続の構成が自動的に設定され,同じ通信手順を用い,通信相手の機能や種類を判別したり,目的の相手を発見するための仕組みが必要になる。UPnPでは,これをインターネットと同じTCP/IP技術の上に構築しようとしているわけだ。 Micｒｏｓｏfｔの行なったデモンストレーションでは,UPnPの応用範囲として電子フォトフレーム(液晶画面などに絵を映しこむ額)とデジタルカメラやビデオ,テレビなどの連携や,PCと各種デバイスの通信,デジタルテレビからプリンタなどへの出力,およびTCP/IPでUPnP対応デバイスをコントロールする万能型リモコンなどが紹介された。たとえば万能型リモコンは,UPnP機器と通信してそのデバイスタイプや機能を確認し,そのデバイスに合わせたリモコンのユーザーインターフェイスを液晶に表示。UPnPのネットワーク経由でコントロールコードを送る,といった具合だ。万能リモコンにありがちな設定の面倒さもなく,赤外線で送ったIPベースのコントロールパケットは適切なネットワークヘとゲートウェイされ,コントロール先のデバイスヘと届く。こうした機能を実現するための仕組みだが,まずネットワークの自動構成は、現在のIPネットワークがほとんどそうなっているようにDHCP(Dynamic Host Configuration Protocol:各クライアントに,起動時に動的にIPアドレスを割り当て,終了時にIPアドレスを回収するためのプロトコル)を用いる。各機器に配布されるIPアドレスはグローバルアドレスではなくプライベートアドレス(UPnP接続された家庭内LAN環境でのみ有効なアドレス)に限定される。このため,そのままインターネットにアクセスすることは不可能だが,ネットワーク内にアドレス変換を用いてインターネットに接続するためのゲートウェイを設けることでこれを回避するようだ。Windows 98 Second EditionやWindows 2000には,インターネット接続をネットワークに接続された複数PCでシェアするための機能が組み込まれるが,これと同じ仕組みが,UPnP対応OSやUPnP対応のインターネットゲートウェイ機器に組み込まれることになるのだろう。通信相手を特定するための名前解決は,IPマルチキャストによるDNS(Domain Name System:TCP/IPネットワーク環境において,ホスト名から,対応するIPアドレスを取得できるようにするサービスを提供するシステム)参照で行なう。UPnPネットワークに参加する機器は,マルチキャスト(単一のパケットで,複数のノートに対して同一データを送信する通信方法)で名前登録のパケットを流し,DHCPサーバと連携するダイナミックDNSに登録される。ルックアップ(登録)時にもマルチキャストで問い合わせが行なわれるため,DNS機能を持つ機器のアドレスを各機器が意識する必要はない。次に通信相手の発見や,その機能をやり取りする仕組みだが,まず全機器に対して“サービスを提供できる機器はありますか?”と問い合わせ,それぞれの機器が手を上げるのを待ち,機能(サービス)を提供している機器のアドレスと名前を受け取る。そして,相手がどのようなプロトコルとAPIをサポートしているかを情報交換し,その相手が提供するネットワークサービスの具体的な内容を情報交換する。あとはその相手の機能を利用するだけだ。この仕組みを実現するためのプロトコルとしては「SSDP」というプロトコルを定義している。SSDPとはSimple Service Discover Protocolの略で,IETF(The Internet Engineering Task Force)で仕様提出され,現在ドラフトとしてIETFのホームページ(http://www.et.org/)から仕様が参照できるようになっている。 SSDPは基本的にIPベースのネットワークに依存し,HTTPによるメッセージ交換フォーマットとLDAP(Lightweight Directory Access Protocol:X.500ディレクトリサービスをInternet向けに軽量,簡素化したサービスプロトコル)によるディレクトリ参照を用いながらXMLフォーマットによる情報交換を行なう。SSDPはDiscover Serverがある場合,ネットワークに参加する機器はサーバに対してアナウンスしておき(この時点でサーバに登録される),サーバに対してリクエストすることで情報を得るが,マルチキャストによる参照もサポートしているためサーバなしで機器間コミュニケーションを行なうことも可能だ。このように,具体的な内容が判明したことでUPnPが単なる絵空事ではなく,現実的な機能を提供してくれそうなことはわかったが,問題は完全にフラットなネットワークを構築するのが難しそうなことだ。たとえばUPnPネットワークには,DHCPやDNSといったサービスを提供するサーバが必要だと思われるが,複数のサーバ機能を持つ機器が存在する場合はどうなるのか?また,Universalという名前からすると,すべての機器にそうしたサーバ機能が存在する必要があるのではないか,そうだとすればネットワーク中のどの機器が調停役を行なうのかなど,いくつかの疑問は残っている。おそらくインターネットヘのゲートウェイ役を含め,コンシューマ向けWindowsにUPnPを実装し(西暦2000年に登場する次期コンシューマ向けWindowsにはUPnP機能が加わる予定),PCがすべての調停役を行なうことになるのかもしれない。そうなれば,小型の家電や通信機器にインテリジェント性がどんどん入り込んでいる中で,ホームネットワーク中のPCがその価値を失わずに済むことになるかもしれない。ただ,こうしたコネクティビティの標準は,そう簡単に決まるものでもないだろう。どこかにインターネットとのゲートウェイさえあれば,もっとクローズドなネットワークでAPIさえ定義されていれば問題はない,という考え方もあるかもしれない。個人的にUPnPは優れた約束事だと思うが,ユーザーの立場からすれば動向をウォッチする段階から抜け出しているわけではない。」 (3) 周知文献3 周知文献3(綾塚佑二他、「UbiｑｕiｔｏｕｓLinkｓ: 実世界環境に埋め込まれたハイパーメディアリンク」、情報処理学会研究報告、社団法人情報処理学会、1996年7月11日、Vｏl.96、Nｏ.62、96-HI-67、ｐ.23-30)には、以下の記載がある(下線は当審付与。)。 e.24頁左欄24行-右欄最下行、及び、同頁欄外注「WWWの世界に存在する情報には現実世界のオブジェクトに関する情報も数多く存在する。例えば、あるアーテイストのCDに対して、そのCD自体の情報やアーテイストの情報が存在する。しかし、その現実世界のオブジェクトに関するWWW上の情報を見るためには、ユーザはどこかでその情報の所在地(URL,Uniform Resource Locator)を入手する必要がある。現状では、そのURLは本などの計算機以外の媒体から写してくる^(1)、またはWWW上の検索システムを使うことなどにより得ているため、状況に応じた適切な情報をその場で見るようなことは難しい。すなわち、現実世界のオブジェクトからWWWの世界の関連する情報へのリンクはかなり弱いものとなっている。本研究では、現実世界のオブジェクトからWWWの世界への情報のリンク構築すること(図1)を考え、携帯型の計算機をその仲介とする試作システム(UbiquitousLinks)を構築した。この試作システムは、携帯型の計算機を実世界のオブジェクトに近付けるとそれに関係するWWW上の惰報を見ることができる、というインタフェースを持つ(図2)。WWW上の情報はハイパーテキストの上のリンクを張られた部分(特定の単語、絵など)をマウスなどでクリックすることにより辿る、という一般に広く用いられているインタフェースに準えたものである。このようなシステムを考える際に問題となるのは、”計算機が如何にしてオブジェクトを認識するか”ということである。今回の試作システムでは、製品毎に固有のIDを持つ小さなタグを実世界のオブジェクトに張り付け、その認識装置を携帯型の計算機に取り付けることにより、その認識を行っている。また、計算機が”現在、(この計算機を持った)ユーザは何処にいるのか”ということを認識するために、赤外線LEDによるIDも用いている。以下の節では、この試作システムの構成、機能、使用例などについて述べる。 ^( l)最近では製品自体にURLが記されている例もある」 f.26頁左欄5-12行「3.1 制御アプリケーション制御アプリケーションの機能は基本的にシリアルポートからIDを読み、それを関連付けられたURLに変換しそれをWWWブラウザに伝える、ということである。この変換のためのデータベースは本来ネットワーク経由でアクセスするべき性質のものであるが、今回の試作システムでは携帯端末自身が保持している。」 g.29頁左欄27-最下行「現在はDｒｕid(審決注:Description of Rules for Ubiquitous ID。IDを関連付けられたURLに変換するためのデータベースを記述するために用いるスクリプト。)で記述されたデータベースはRｏc(審決注:Real Object Clicker。実世界に取り付けられるID群を認識し、ネットワークを介してWWWにアクセスし情報を表示する携帯端末。)内部に存在する。しかし、実際に一般のユーザが利用する場合にはこれもネットワーク経由でグローバルなものヘアクセスするようにしなければ使用範囲が大幅に限られてしまうことになる。グローバルなデータベースはただ一つに統合されている必要はない。ユーザの都合に合わせたデータベースを使用すればよいし、またより大きなデータベースの一部を、ローカルなデータベース、さらに個人的なデータベースで置き換えることも考えられる。Dｒｕidの改良に当たっては、このような違う場所に存在する複数のデータベースに跨って適切な動作がなされるように留意しなければならない。」 4.対比本願発明と引用発明とを対比する。 (1) 引用発明の「設備」は、具体的には「たとえば工場などの各種の設備X_(1),X_(2),X_(3),…」、「展示物が置かれているパネルY_(1),Y_(2),Y_(3),…」、「看板等の物体」、「道路を跨いで設置されたガントリG」等が例示されるから、本願発明の「ホームネットワーク上の装置」と、「装置」である点で共通するといえる。 (2) 引用発明の「発信装置2」は、個々の「設備」に対応して個別に配置されるものであって、当該設備に関するURLを発信して、その設備に関連するホームページの自動閲覧機能を付加する点で、個々の「設備」を代理するデバイスすなわちプロキシデバイスであるといえるから、本願発明の「ホームネットワーク上の装置を表すプロキシデバイス」と、「装置を表すプロキシデバイス」である点で共通するといえる。 (3) 引用発明の「携帯端末6」は、「表示部6aの画面のタッチパネル」を備えて入力操作に用いる装置であるから、本願発明の「入力装置」に相当する。 (4) 引用発明の「サーバー4」は、本願発明の「サーバ」に相当する。また、引用発明の「サーバー4が格納するホームページ」は、本願発明の「サーバからのデータ」に相当する。 (5) 上記(1)-(4)より、引用発明の「ステップ3」-「ステップ7」において、「発信装置2」(本願発明の「プロキシデバイス」に対応する。)が、携帯端末6からURL発信要求を受けて、「設備X_(1)に該当するホームページのURLを…携帯端末6に向けて送信し(ステップ4)」、これによって、「この携帯端末6は、電話などの無線通信を使ってホームページを格納しているサーバー4にアクセスして、その設備X_(1)に関連するホームページを開き(ステップ6)」との動作が開始されることは、本願発明の「前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置の型式に固有の所定のURLによる制御の下でネットワークを経由してサーバからのデータの取り込みをゲートウェイ及び前記入力装置を介して開始するプロキシデバイスであって、当該プロキシデバイスは前記装置に貼付され」ることと、「前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置のURLによる制御の下でネットワークを経由してサーバからのデータの取り込みを前記入力装置を介して開始するプロキシデバイスであ」る点で共通するといえる。 (6) 引用発明の「たとえば工場などの各種の設備X_(1),X_(2),X_(3),…」に関連するホームページが、「携帯端末6の表示部6aに表示されるので、その表示部6aのタッチパネルの操作により設備X_(1)に関する各種の情報を取り出すことができ(ステップ7)、また、サーバー4の本体部4aにCGI等の機能を備えるものでは、さらに携帯端末6のタッチパネルの操作により、当該設備X_(1)の制御をすることができ」ることにより、「工場などの各種設備の情報を取り出したり設備の制御を行う場合」に利用されるものであることは、本願発明の「前記データが該装置の使用のコンテキストに関するコンテンツ情報を表して」いることに相当する。したがって、本願発明と引用発明との一致点・相違点は次のとおりである。＜一致点＞「装置を表すプロキシデバイスにおいて、前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置のURLによる制御の下でネットワークを経由してサーバからのデータの取り込みを前記入力装置を介して開始するプロキシデバイスであって、前記データは、前記装置の使用のコンテキストに関するコンテンツ情報を表している、ことを特徴とするプロキシデバイス。」＜相違点1＞本願発明は、プロキシデバイスが表す「装置」が「ホームネットワーク上の装置」であり、「装置のURL」が「装置の型式に固有の所定のURL」であるのに対して、引用発明は、装置が、「たとえば工場などの各種の設備X_(1),X_(2),X_(3),…」であって、装置のURLが、「工場などの各種設備の情報を取り出したり設備の制御を行う」ホームページを示す「各設備固有のURL」であることは例示があるものの、装置が「ホームネットワーク上の装置」であって、装置のURLが「装置の型式に固有の所定のURL」であることは明記がない点。＜相違点2＞本願発明は、「サーバからのデータの取り込みをゲートウェイ及び前記入力装置を介して開始する」のに対して、引用発明では、「携帯端末6は、電話などの無線通信を使ってホームページを格納しているサーバー4にアクセスして、その設備X_(1)に関連するホームページを開き(ステップ6)」との記載はあるものの、ホームページのデータの取り込みにおいて、「ゲートウエイ及び」前記入力装置を介して開始することは記載がない点。＜相違点3＞本願発明では、「当該プロキシデバイスは前記装置に貼付され」るのに対して、引用発明の発信装置2は、「たとえば工場などの各種の設備X_(1),X_(2),X_(3),…に対して個別に発信装置2が配置される」ものであって、装置に「配置される」ことは記載があるものの、「前記装置に貼付され」ることは記載がない点。＜相違点4＞本願発明は「前記装置においてネットワークが構成化されていない場合には、UPnPに従うHTTPマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のURLを得る」のに対して、引用発明は、「携帯端末6に記憶しているIDとURLとの対応テーブルを参照して該当するURLを選択」すること、すなわち、携帯端末6(本願発明の「入力装置」に対応する。)が、携帯端末6に設けた対応テーブルにより装置のIDに対応するURLを得ることによって、サーバー4にアクセスすることは記載があるものの、ネットワークが構成(コンフィギュレーション)されていない場合の動作について記載がない点。 5.当審の判断＜相違点1＞について引用発明における「たとえば工場などの各種の設備X_(1),X_(2),X_(3),…」との記載は、一例であることが明らかであることを考慮すると、引用発明を、周知の「ホームネットワーク上の装置」(周知文献1の上記「3(1)周知文献1、a.」の下線部、周知文献2の上記「3(2)周知文献2、d.」の下線部を参照)に適用することで、装置が「ホームネットワーク上の装置」であって、装置のURLが「装置の型式に固有の所定のURL」である、上記＜相違点1＞に係る構成とすることは、当業者が容易になし得ることである。＜相違点2＞について各種装置を、インターネット等のネットワークに接続するために、「ゲートウエイ」を設けることは、慣用技術である(周知文献1の上記「3(1)周知文献、c.」、周知文献2の上記「3(2)周知文献2、d.」を参照)。よって、引用発明において、各種装置を、インターネット等のネットワークに接続するために、「ゲートウエイ」を設ける慣用技術を付加することによって、データの取り込みを「ゲートウエイ及び」前記入力装置を介して開始する、上記＜相違点2＞に係る構成とすることは、当業者が容易になし得ることである。＜相違点3＞について一般に、装置を配置する手段として、「貼付」は普通に採用されている(周知文献3の上記「3(3)周知文献3、e.」を参照)。よって、「たとえば工場などの各種の設備X_(1),X_(2),X_(3),…に対して個別に発信装置2が配置される」引用発明において、配置する手段として「貼付」を採用することで、「当該プロキシデバイスは前記装置に貼付され」る、上記＜相違点3＞に係る構成とすることは、当業者が容易になし得ることである。＜相違点4＞についてインターネット接続用に「ゲートウェイ」を設けるUPnP規格に基づくネットワークにおいて、ネットワークを構成(コンフィギュレーション)するために、HTTPのマルチキャスト通信によりネットワーク上のデバイスを発見(ディスカバリ)することは、周知技術である(周知文献1の上記「3(1)周知文献1、a.-c.」の下線部、周知文献2の上記「3(2)周知文献2、d.」の下線部を参照)。一般に、アドレス変換用のテーブルを、ネットワーク上のどのデバイスに配置するかは、システムの実装時に、当業者が適宜選択すべき設計的事項であると認められる(周知文献3の上記「3(3)周知文献3、f.及びg.」の下線部を参照。)。したがって、引用発明において、インターネット接続用に「ゲートウェイ」を設けるUPnP規格に基づくネットワークにおいて、ネットワークを構成(コンフィギュレーション)するために、HTTPのマルチキャスト通信によりネットワーク上のデバイスを発見(ディスカバリ)する周知技術を適用すると共に、この際、装置のIDをURLにアドレス変換するための「対応テーブル」を、携帯端末6に記憶することに替えて、ネットワーク上のゲートウエイに配置することによって、「前記装置においてネットワークが構成化されていない場合には、UPnPに従うHTTPマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のURLを得る」、上記＜相違点4＞に係る構成とすることは、当業者が容易になし得ることである。さらに、本願発明の効果も、引用発明及び各周知技術に基づいて、当業者が予測し得る範囲内のものである。 6.小括したがって、本願発明は、引用発明及び各周知技術に基づいて、当業者が容易に発明をすることができたものである。第5 むすび以上のとおり、本件出願は、特許法第36条第6項第1号に規定する要件を満たしていない。また、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第29条第2項の規定により特許を受けることができない。よって、結論のとおり審決する。
審理終結日	2013-04-03
結審通知日	2013-04-09
審決日	2013-04-24
出願番号	特願2002-518693(P2002-518693)
審決分類	P 1 8・ 537- WZ (G06F) P 1 8・ 121- WZ (G06F)
最終処分	不成立
前審関与審査官	古河雅輝
特許庁審判長	和田志郎
特許庁審判官	山田正文稲葉和生
発明の名称	トピック的サービスによるホームネットワーク用のコンテキスト情報の提供
代理人	伊東忠重
代理人	伊東忠彦
代理人	大貫進介

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