【事件の表示】
　特願２００２−５１８６９３「トピック的サービスによるホームネットワーク用のコンテキスト情報の提供」拒絶査定不服審判事件〔平成１４年　２月１４日国際公開、ＷＯ０２／１３４６３、平成１６年　２月２６日国内公表、特表２００４−５０６２８１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００１年７月３０日（パリ条約による優先権主張、２０００年８月１０日、米国）を国際出願日とする出願であって、平成２３年４月２１日付けで拒絶査定がされ（発送日：同年５月１０日）、これに対して同年９月９日に拒絶査定不服審判の請求がなされるとともに、手続補正がされたものであり、さらに、平成２４年１２月１１日付けで、当審において拒絶理由（以下「当審拒絶理由」という。）が通知され、これに対して、平成２５年３月１４日に意見書及び補正書が提出されたものである。
　
　
第２　当審拒絶理由
　平成２４年１２月１１日付け当審拒絶理由の概要は、以下のとおりである。
　
＜理由１　進歩性の拒絶理由＞
　本願の請求項１−１５に係る発明は、その優先日前日本国内又は外国において頒布された下記の刊行物に記載された発明に基づいて、その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記
　１．特開平１１−２５９４９１号公報
　２．Ｍｉｃｒｏｓｏｆｔ　Ｃｏｒｐｏｒａｔｉｏｎ、Ｕｎｄｅｒｓｔａｎｄｉｎｇ　Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ、ｗｈｉｔｅ　ｐａｐｅｒ、［online］、２０００年６月、ｐ．１−３９、［平成２４年１２月５日検索］、インターネット＜URL：http://www.upnp.org/download/UPNP_understandingUPNP.doc＞
　３．本田雅一、「海外リポート　ＷｉｎＨＥＣ　＆　Ｗｉｎｄｏｗｓ　２０００　Ｒｅｖｉｅｗｅｒ’ｓ　Ｗｏｒｋｓｈｏｐ」、ＡＳＣＩＩ、株式会社アスキー、１９９９年６月１日、第２３巻、第６号、ｐ．２１４−２２３
　
＜理由２　記載不備の拒絶理由＞
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　　　　　記
（１）　請求項１で、「ＨＴＴＰマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のＵＲＬを得る」とあるが、本願明細書には、段落【００３２】に「ＤＶＤプレーヤ１０２はＵＰｎＰ規格に従いＨＴＴＰマルチキャストメカニズムを用いて
インターネットゲートウェイ１１８を見付ける
　請求項２−１５も同様である。　
　
　以下、上記各理由が解消したか否かについて、まず＜理由２＞について検討し、次いで＜理由１＞について検討する。
　
　
第３　特許法第３６条第６項第１号について
１．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２５年３月１４日付け手続補正書の特許請求の範囲に記載された次のとおりのものである。
　
「ホームネットワーク上の装置を表すプロキシデバイスにおいて、前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置の型式に固有の所定のＵＲＬによる制御の下でネットワークを経由してサーバからのデータの取り込みをゲートウェイ及び前記入力装置を介して開始するプロキシデバイスであって、当該プロキシデバイスは前記装置に貼付され、
　前記データは、前記装置の使用のコンテキストに関するコンテンツ情報を表しており、
　前記装置においてネットワークが構成化されていない場合には、ＵＰｎＰに従うＨＴＴＰマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のＵＲＬを得ることを特徴とするプロキシデバイス。」
　
２．当審拒絶理由の＜理由２　記載不備の拒絶理由＞について
　当審拒絶理由の＜理由２　記載不備の拒絶理由＞は、上記「第２　当審拒絶理由」に記載のとおりである。
　本願の請求項１には、「前記装置においてネットワークが構成化されていない場合には、ＵＰｎＰに従うＨＴＴＰマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のＵＲＬを得る」との記載がある。
　一方、本願明細書の段落【００３２】には、次の記載がある。
「ユーザがリモコン１０８上のサービスアクセス釦１２４を押下した場合、もし、以前の機会に
ネットワーク１０６が構成化されていなかった場合には
ＵＰｎＰ規格に従いＨＴＴＰマルチキャストメカニズムを用いてインターネットゲートウェイ１１８を見付ける
　これらの記載から、本願明細書の段落【００３２】は、そもそも「ＤＶＤプレーヤ１０２」すなわち本願発明の「装置」自体に係る記載であって、本願発明の「プロキシデバイス」に係る記載はない。そして、「ＤＶＤプレーヤ１０２」が、「ＵＰｎＰ規格に従いＨＴＴＰマルチキャストメカニズムを用いて
インターネットゲートウェイ１１８を見付ける
　請求人は、「明細書の段落００３２には、以下のように記載されております。『もし、以前の機会にネットワーク１０６が構成化されていなかった場合には、ＤＶＤプレーヤ１０２はＵＰｎＰ規格に従いＨＴＴＰマルチキャストメカニズムを用いてインターネットゲートウェイ１１８を見付ける。ＤＶＤプレーヤ１０２はインターネットゲートウェイ１１８のＵＰｎＰ記述ドキュメントを得ると共に、
インターネットアドレスをマップするために要するＵＰｎＰサービスのアドレスを得る
インターネットアドレスをマップするために要するＵＰｎＰサービスのアドレス
　しかし、上記のとおり、段落【００３２】は、そもそも本願発明の「プロキシデバイス」に係る記載ではない。そして、明細書段落【００３２】の上記請求人がサポート要件に関して引用する下線部は、「インターネットアドレスをマップするために要する「
ＵＰｎＰサービスのアドレス
前記
　したがって、当審拒絶理由における、特許法第３６条第６項第１号についての＜理由２　記載不備の拒絶理由＞は解消していない。
　
３．小括
　したがって、請求項１に係る発明は、発明の詳細な説明に記載したものであるとはいえないので、本件出願は、特許法第３６条第６項第１号に規定する要件を満たしておらず、特許を受けることができない。
　
　
第４　特許法第２９条第２項について
１．本願発明
　本願発明は、上記「第３　特許法第３６条第６項第１号について、１．本願発明」に記載されたとおりのものである。
　
２．引用文献
　当審拒絶理由で引用された、本願の優先日前である平成１１年９月２４日に公開された、特開平１１−２５９４９１号公報（以下、「引用文献」という。）には、以下の記載がある（下線は当審付与。）。
　
（１）　段落【０００１】−【０００７】
「【０００１】
【発明の属する技術分野】本発明は、
設備に付帯するＵＲＬなどの識別情報を自動的に取得してその設備に関するホームページの情報を閲覧することができる関連ホームページ自動閲覧システム
【０００２】
【従来の技術】携帯端末でブラウザを使って、特定の情報がファイルされているホームページの情報を得ようとする場合、従来技術では、予め調べてあるそのホームページのＵＲＬ(Ｕniform Ｒesource Ｌocator)をインプットして、そのページを呼び出していた。
【０００３】すなわち、ある設備Ａの前に行った時に、
その設備Ａの各種制御ができるホームページ
その設備Ｂに関連するホームページ
【０００４】
【発明が解決しようとする課題】このように、その都度、設備Ａ，Ｂ，…に関連するホームページのＵＲＬを携帯端末にインプットするのは、入力操作に手間がかかるばかりか、ＵＲＬを知らない場合や、忘れた場合には、それらの設備Ａ，Ｂ，…にアクセスすることができない。
【０００５】また、検索エンジンを使ってそのページを探すことも可能であるが、時間がかかるし、そのページを発見できない場合もある。
【０００６】さらに、携帯端末内にそれぞれの設備Ａ，Ｂ等のホームページのＵＲＬを予め記憶させておくことも可能であるが、記憶させたＵＲＬの数が多い場合は、その中から必要なＵＲＬを選ばなければならず、それだけ余分な時間がかかることにもなる。
【０００７】本発明は、上記の問題点を解決するためになされたもので、ＵＲＬを知らなくても即時にその設備に関連するホームページにアクセスして、必要な情報を入手したり、関連する設備の制御ができるようにすることを課題とする。」
　
（２）　段落【００２０】−【００２６】
「【００２０】
【発明の実施の形態】図１は、この関連ホームページ自動閲覧システムの全体を示す構成図である。
【００２１】
この関連ホームページ自動閲覧システムは、たとえば工場などの各種の設備Ｘ
1
，Ｘ
２
，Ｘ
３
，…に対して個別に発信装置２が配置される一方、各設備Ｘ
1
，Ｘ
２
，Ｘ
３
，…に関するホームページを格納するとともにそれらの設備Ｘ
1
，Ｘ
２
，Ｘ
３
，…を制御するサーバー
４と、発信装置２から発信される情報を受信してサーバー４が格納するホームページにアクセスする携帯端末６とを含
【００２２】上記の発信装置２は、各設備Ｘ1，Ｘ２，Ｘ３，…に関するホームページを開くために必要となるＵＲＬを発信するものであって、図２に示すように、マイコン２a、ＵＲＬや各種のデータ等を記憶するメモリ２b、ＵＲＬを赤外線で発信するための発光素子２c、携帯端末６からのＵＲＬ発信要求の赤外線信号を受けるための受光素子２d、両素子２c，２dを駆動する光素子ドライバ２e、電源２f、およびパイロットランプ２gなどから構成されている。
【００２３】この発信装置２のメモリ２bに対して予め各設備Ｘ1，Ｘ２，Ｘ３…に関して固有のＵＲＬ情報をインプットするには、携帯端末６側から赤外線で受光素子２d経由で行ったり、あるいは、サーバー４から有線で各発信装置２のマイコン２aに対してＩ／Ｏ経由で行うことができる。
【００２４】なお、発信装置２が常時、発光素子２cからＵＲＬを発信する構成とする場合には、受光素子２dを省略することが可能である。
【００２５】サーバー４は、本体部４aに無線機４bが接続されて構成されており、この無線機４bによって、携帯端末６との間で携帯電話回線やＰＨＳ回線等によってホームページを開くためのブラウザデータの通信等が行えるようになっている。
【００２６】一方、上記の携帯端末６は、サーバー４との間で無線通信を行うための機能と、発信装置２との間でＩｒＤＡ規格などの赤外線通信を行うための機能を有するとともに、ＬＣＤ等の表示部６aを備えており、この表示部６aには、ＵＲＬ発信要求の赤外線信号を発信したり各種の情報を入力するためのタッチパネル(図示省略)が設けられている。そして、表示部６aには、サーバー４から送信されるホームページの情報が表示されてその内容を閲覧できるようになっている。」
　
（３）　段落【００２８】−【００３５】
「【００２８】次に、上記構成の関連ホームページ自動閲覧システムにおける具体的な操作例を、図３に示すフローチャートを参照して説明する。なお、ここでは、
一つの設備Ｘ
1
についての操作
【００２９】
まず、携帯端末６を持参して、所望の設備Ｘ
1
の前に位置
(ステップ１)
【００３０】
設備Ｘ
1
に配置されている発信装置２が、常時、当該設備Ｘ
1
に関する
ＵＲＬ
情報を赤外線で発信していない場合には(ステップ２)
携帯端末６のほうから設備Ｘ
1
に向けてＵＲＬ発信要求の信号を赤外線で送信
(ステップ３)
これには、
表示部６aの画面のタッチパネルを操作したりして行
【００３１】
ＵＲＬ発信要求を受けた発信装置２は、この発信装置２が配置されている設備Ｘ
1
に該当するホームページのＵＲＬを赤外線通信などで携帯端末６に向けて送信
(ステップ４)
【００３２】
携帯端末６が該当するホームページのＵＲＬを受信すると(ステップ５)
この携帯端末６は、電話などの無線通信を使ってホームページを格納しているサーバー４にアクセスして、その設備Ｘ
1
に関連するホームページを開
(ステップ６)
【００３３】すなわち、
その設備Ｘ
1
に関連する
ホームページ
は、携帯端末６の表示部６aに表示されるので、その表示部６aのタッチパネルの操作により設備Ｘ
1
に関する各種の情報を取り出すことができ
(ステップ７)
【００３４】なお、設備Ｘ1に配置されている発信装置２が、常時、当該設備Ｘ1に関するＵＲＡ情報を赤外線で発信している場合には、携帯端末６は直ちに該当するホームページのＵＲＬを受信することができ(ステップ８)、この携帯端末６によってその設備Ｘ1に関連するホームページを開くことができる(ステップ６)。
【００３５】
また、サーバー４の本体部４aにＣＧＩ
等の機能を備えるものでは、さらに携帯端末６のタッチパネルの操作により、当該設備Ｘ
1
の制御をすることができ
　
（４）　段落【００３６】−【００４８】
「【００３６】上記の実施形態では、
工場などの各種設備の情報を取り出したり設備の制御を行う場合
以外の例
【００３７】図４には本発明を
各種展示会において展示物の内容を説明するために適用した場合
【００３８】
展示会において、展示物が置かれているパネルＹ
1
，Ｙ
２
，Ｙ
３
，…の前に立った時にそのパネルＹ
1
，Ｙ
２
，Ｙ
３
，…に個別に設置されている発信装置２から発信されているＵＲＬを携帯端末６で受信して、その展示物に関して説明しているホームページを開くことができ
【００３９】図５には本発明を
店舗の内容を説明するために適用した場合
【００４０】
各店舗Ｚ
1
，Ｚ
２
，Ｚ
３
，…の入口にそれぞれ発信装置２を設置し、その店の前に行って携帯端末６でＵＲＬを取得すると、その店舗たとえばＺ
２
のサービス内容を自由に閲覧することができ
【００４１】一例として
レストランの場合なら、写真付きのメニューとか日替わり商品とか値段等の情報を得たり、テーブルやメニュー・弁当の予約をすることができ
金融機関ならば、各商品のその日の利率情報を取得することができ
【００４２】なお、
発信装置２は店舗Ｚ
1
，Ｚ
２
，Ｚ
３
，…の入口に設置する他に店舗を表示する看板等の物体に設置してもよ
【００４３】図６には本発明を
交通情報を取得する場合
【００４４】
道路を跨いで設置されたガントリＧに取り付けられた発信装置２から道路を走行している車両Ｃに配備した
携帯端末によって、道路付近や進行方向の交通情報を発信しているホームページのＵＲＬを取得して所望の情報を得ることができ
【００４５】その場合、予め、携帯端末にインストールされている地図上にその交通情報を重ねて表示させることもできる。
【００４６】なお、ＵＲＬ取得の手段は、この実施形態のような赤外線通信の他に、無線通信を使ってもよい。無線通信の場合は、他の装置の無線との混信が無い程度のパワーにする必要がある。
【００４７】
また、上記
では、各種の設備Ｘ
1
，Ｘ
２
，Ｘ
３
，…に設置した発信装置２からそれらの各設備固有のＵＲＬを発信するように構成したが、識別情報としてはＵＲＬの代わりに各設備Ｘ
1
，Ｘ
２
，Ｘ
３
，…に固有のＩＤを送信することも可能であ
【００４８】
すなわち、発信装置２からはＵＲＬの代わりに、Ａ，Ｂ，Ｃなどの設備Ｘ
1
，Ｘ
２
，Ｘ
３
，…固有のＩＤを携帯端末６に対して送信し
携帯端末６に記憶しているＩＤとＵＲＬとの対応テーブルを参照して該当するＵＲＬを選択し、そのＵＲＬを格納しているサーバー４にアクセスするようにしてもよい
　
　よって、引用文献には、次の発明（以下、「引用発明」という。）が開示されているものと認められる。
　
「設備に付帯するＵＲＬなどの識別情報を自動的に取得してその設備に関するホームページの情報を閲覧することができる関連ホームページ自動閲覧システムであって、
　関連ホームページ自動閲覧システムは、たとえば工場などの各種の設備Ｘ1，Ｘ２，Ｘ３，…に対して個別に発信装置２が配置される一方、各設備Ｘ1，Ｘ２，Ｘ３，…に関するホームページを格納するとともにそれらの設備Ｘ1，Ｘ２，Ｘ３，…を制御するサーバー４と、発信装置２から発信される情報を受信してサーバー４が格納するホームページにアクセスする携帯端末６とを含み、
　一つの設備Ｘ1についての操作は、
　まず、携帯端末６を持参して、所望の設備Ｘ1の前に位置し(ステップ１)、
　設備Ｘ1に配置されている発信装置２が、常時、当該設備Ｘ1に関するＵＲＬ情報を赤外線で発信していない場合には(ステップ２)、
　携帯端末６のほうから設備Ｘ1に向けてＵＲＬ発信要求の信号を赤外線で送信し(ステップ３)、これには、表示部６aの画面のタッチパネルを操作したりして行い、
　ＵＲＬ発信要求を受けた発信装置２は、この発信装置２が配置されている設備Ｘ1に該当するホームページのＵＲＬを赤外線通信などで携帯端末６に向けて送信し(ステップ４)、
　携帯端末６が該当するホームページのＵＲＬを受信すると(ステップ５)、
　この携帯端末６は、電話などの無線通信を使ってホームページを格納しているサーバー４にアクセスして、その設備Ｘ1に関連するホームページを開き(ステップ６)、
　その設備Ｘ1に関連するホームぺージは、携帯端末６の表示部６aに表示されるので、その表示部６aのタッチパネルの操作により設備Ｘ1に関する各種の情報を取り出すことができ(ステップ７)、また、サーバー４の本体部４aにＣＧＩ等の機能を備えるものでは、さらに携帯端末６のタッチパネルの操作により、当該設備Ｘ1の制御をすることができ、
　上記の工場などの各種設備の情報を取り出したり設備の制御を行う場合以外の例は、
　各種展示会において展示物の内容を説明するために適用した場合、展示会において、展示物が置かれているパネルＹ1，Ｙ２，Ｙ３，…の前に立った時にそのパネルＹ1，Ｙ２，Ｙ３，…に個別に設置されている発信装置２から発信されているＵＲＬを携帯端末６で受信して、その展示物に関して説明しているホームページを開くことができ、
　店舗の内容を説明するために適用した場合、各店舗Ｚ1，Ｚ２，Ｚ３，…の入口にそれぞれ発信装置２を設置し、その店の前に行って携帯端末６でＵＲＬを取得すると、その店舗たとえばＺ２のサービス内容を自由に閲覧することができ、レストランの場合なら、写真付きのメニューとか日替わり商品とか値段等の情報を得たり、テーブルやメニュー・弁当の予約をすることができ、金融機関ならば、各商品のその日の利率情報を取得することができ、発信装置２は店舗Ｚ1，Ｚ２，Ｚ３，…の入口に設置する他に店舗を表示する看板等の物体に設置してもよく、
　交通情報を取得する場合、道路を跨いで設置されたガントリＧに取り付けられた発信装置２から道路を走行している車両Ｃに配備した携帯端末によって、道路付近や進行方向の交通情報を発信しているホームページのＵＲＬを取得して所望の情報を得ることができ、
　また、上記では、各種の設備Ｘ1，Ｘ２，Ｘ３，…に設置した発信装置２からそれらの各設備固有のＵＲＬを発信するように構成したが、識別情報としてはＵＲＬの代わりに各設備Ｘ1，Ｘ２，Ｘ３，…に固有のＩＤを送信することも可能であり、すなわち、発信装置２からはＵＲＬの代わりに、Ａ，Ｂ，Ｃなどの設備Ｘ1，Ｘ２，Ｘ３，…固有のＩＤを携帯端末６に対して送信し、携帯端末６に記憶しているＩＤとＵＲＬとの対応テーブルを参照して該当するＵＲＬを選択し、そのＵＲＬを格納しているサーバー４にアクセスするようにしてもよい、
　関連ホームページ自動閲覧システム。」
　
　
３．周知文献１−３
（１）　周知文献１
　当審拒絶理由で引用された、周知文献１（Ｍｉｃｒｏｓｏｆｔ　Ｃｏｒｐｏｒａｔｉｏｎ、Ｕｎｄｅｒｓｔａｎｄｉｎｇ　Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ、ｗｈｉｔｅ　ｐａｐｅｒ、［online］、２０００年６月、ｐ．１−３９、［平成２４年１２月５日検索］、インターネット＜URL：http://www.upnp.org/download/UPNP_understandingUPNP.doc＞）には、以下の記載がある（下線は当審付与。）。
　
ａ．８頁１２−２９行
「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.」
（当審訳：事例「上手く接続された家庭」
　
ＵＰｎＰが、
台所用器具を、ホームネットワークを形成するため、電力線ネットワークに接続できる
各器具の情報、例えば、型式
に多くの場所からアクセスして、検索できるかもしれない
取扱説明書のＵＲＬにアクセスできる
　
　　　・・・（中略）・・・
　
　あなたは、何が足りないかを見るために食器棚を精査しながら、
台所用タブレット
このデバイスは、ＵＰｎＰを利用することにより、ホームネットワークとインターネットへの自動的なアクセスを備えるだろう
　
ｂ．１４頁３０行−１５頁１３行
「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.」
（当審訳：ＳＳＤＰについて
　シンプル・サービス発見プロトコル（ＳＳＤＰ）は、その名前が意味するとおり、ネットワーク上で、ネットワーク・サービスを発見する方法を定義する。ＳＳＤＰは、ＨＴＴＰＵとＨＴＴＰＭＵ上で構築され、制御点がネットワーク上で興味のある資源を見つける方法と、デバイスがネットワーク上で自己が利用可能であるとアナウンスする方法の両方を定義している。
　
　　　・・・（中略）・・・
　
　制御点とデバイスは、共にＳＳＤＰを使用する。ＵＰｎＰ制御点は、起動時に、ネットワーク上で利用可能なデバイスとサービスを発見するために、
（ＨＴＴＰＭＵ上の）ＳＳＤＰ探索リクエスト
　
ＵＰｎＰデバイスは、マルチキャスト・ポートを聴取している
　同様に、デバイスは、ネットワークに接続された場合、自己がサポートするサービスを広告するために、多数のＳＳＤＰプレゼンスのアナウンスを送出する。
　プレゼンスのアナウンスと、ユニキャストのデバイス応答メッセージはどちらも、デバイスがサポートするプロパティとサービスの集合についての情報を有する、デバイス記述ドキュメントの位置へのポインタを含む。）
　
ｃ．２０頁１９行−３１行
「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
（当審訳：ＵＰｎＰネットワークの具体例
　ＵＰｎＰネットワーキングの各ステップが、いつ、どのように起こるかについて、さらに理解するには、僅かな数のＵＰｎＰ装置だけを備えた小規模なネットワークを定義することが役立つ。その後、我々は、これらの装置が、ＵＰｎＰに関連すると共に、どのように相互作用するかを説明する。
　この論文のため、私は以下のＵＰｎＰ可能化装置を含むネットワークを選択した：
　
インターネット・ゲートウエイ
　
（２）　周知文献２
　当審拒絶理由で引用された、周知文献２（本田雅一、「海外リポート　ＷｉｎＨＥＣ　＆　Ｗｉｎｄｏｗｓ　２０００　Ｒｅｖｉｅｗｅｒ’ｓ　Ｗｏｒｋｓｈｏｐ」、ＡＳＣＩＩ、株式会社アスキー、１９９９年６月１日、第２３巻、第６号、ｐ．２１４−２２３）には、以下の記載がある（下線は当審付与。）。
　
ｄ．２１６頁中欄１０行−２１７頁右欄１５行
　「Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　＆Ｐｌａｙは家庭でのＰＣの地位を高める？
　Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　＆　Ｐｌａｙ（ＵＰｎＰ）は，Ｍｉｃｒｏｓｏｆｔが中心となって提唱しているシンプルネットワーク構築のためのプロトコルだ（４月号ｐ．１８３，http://www.upnp.org/参照）（スライド３〜５）。これまでＭｉｃｒｏｓｏｆｔはＵＰｎＰに関して，ＴＣＰ／ＩＰベースの通信を基本とし，
ＨＴＴＰと
で情報を交換し
なんらかの標準プロトコルで機器発見の仕組みを構築すること
　
ネットワーク上で機器間のコミユニケーションを正常に行なうためには，ネットワーク接続の構成が自動的に設定され，同じ通信手順を用い，通信相手の機能や種類を判別したり，目的の相手を発見するための仕組みが必要になる
　Ｍｉｃｒｏｓｏｆｔの行なったデモンストレーションでは，ＵＰｎＰの応用範囲として電子フォトフレーム（液晶画面などに絵を映しこむ額）とデジタルカメラやビデオ，テレビなどの連携や，ＰＣと各種デバイスの通信，デジタルテレビからプリンタなどへの出力，およびＴＣＰ／ＩＰでＵＰｎＰ対応デバイスをコントロールする万能型リモコンなどが紹介された。たとえば万能型リモコンは，ＵＰｎＰ機器と通信してそのデバイスタイプや機能を確認し，そのデバイスに合わせたリモコンのユーザーインターフェイスを液晶に表示。ＵＰｎＰのネットワーク経由でコントロールコードを送る，といった具合だ。万能リモコンにありがちな設定の面倒さもなく，赤外線で送ったＩＰベースのコントロールパケットは
適切なネットワークヘとゲートウェイされ，コントロール先のデバイスヘと届く
　こうした機能を実現するための仕組みだが，まずネットワークの自動構成は、現在のＩＰネットワークがほとんどそうなっているようにＤＨＣＰ（Dynamic Host Configuration Protocol：各クライアントに，起動時に動的にＩＰアドレスを割り当て，終了時にＩＰアドレスを回収するためのプロトコル）を用いる。各機器に配布されるＩＰアドレスはグローバルアドレスではなくプライベートアドレス（ＵＰｎＰ接続された家庭内ＬＡＮ環境でのみ有効なアドレス）に限定される。このため，そのままインターネットにアクセスすることは不可能だが，
ネットワーク内にアドレス変換を用いてインターネットに接続するためのゲートウェイを設けることでこれを回避するようだ
ＵＰｎＰ対応のインターネットゲートウェイ機器に組み込まれることになるのだろう
　通信相手を特定するための名前解決は，ＩＰマルチキャストによるＤＮＳ（Domain Name System：ＴＣＰ／ＩＰネットワーク環境において，ホスト名から，対応するＩＰアドレスを取得できるようにするサービスを提供するシステム）参照で行なう。ＵＰｎＰネットワークに参加する機器は，マルチキャスト（単一のパケットで，複数のノートに対して同一データを送信する通信方法）で名前登録のパケットを流し，ＤＨＣＰサーバと連携するダイナミックＤＮＳに登録される。ルックアップ（登録）時にもマルチキャストで問い合わせが行なわれるため，ＤＮＳ機能を持つ機器のアドレスを各機器が意識する必要はない。
　次に通信相手の発見や，その機能をやり取りする仕組みだが，まず全機器に対して“サービスを提供できる機器はありますか？”と問い合わせ，それぞれの機器が手を上げるのを待ち，機能（サービス）を提供している機器のアドレスと名前を受け取る。そして，相手がどのようなプロトコルとＡＰＩをサポートしているかを情報交換し，その相手が提供するネットワークサービスの具体的な内容を情報交換する。あとはその相手の機能を利用するだけだ。
　この仕組みを実現するためのプロトコルとしては「ＳＳＤＰ」というプロトコルを定義している。ＳＳＤＰとはSimple Service Discover Protocolの略で，ＩＥＴＦ（The Internet Engineering Task Force）で仕様提出され，現在ドラフトとしてＩＥＴＦのホームページ（http://www.et.org/）から仕様が参照できるようになっている。
　ＳＳＤＰは基本的にＩＰベースのネットワークに依存し，
ＨＴＴＰによるメッセージ交換フォーマットと
ＳＳＤＰは
マルチキャストによる参照もサポートしているためサーバなしで機器間コミュニケーションを行なうことも可能だ
　このように，具体的な内容が判明したことでＵＰｎＰが単なる絵空事ではなく，現実的な機能を提供してくれそうなことはわかったが，問題は完全にフラットなネットワークを構築するのが難しそうなことだ。
　たとえばＵＰｎＰネットワークには，ＤＨＣＰやＤＮＳといったサービスを提供するサーバが必要だと思われるが，複数のサーバ機能を持つ機器が存在する場合はどうなるのか？また，Universalという名前からすると，すべての機器にそうしたサーバ機能が存在する必要があるのではないか，そうだとすればネットワーク中のどの機器が調停役を行なうのかなど，いくつかの疑問は残っている。
　おそらくインターネットヘのゲートウェイ役を含め，コンシューマ向けWindowsにＵＰｎＰを実装し（西暦２０００年に登場する次期コンシューマ向けWindowsにはＵＰｎＰ機能が加わる予定），ＰＣがすべての調停役を行なうことになるのかもしれない。そうなれば，
小型の家電や通信機器にインテリジェント性がどんどん入り込んでいる中で，ホームネットワーク中の
　ただ，こうしたコネクティビティの標準は，そう簡単に決まるものでもないだろう。どこかにインターネットとのゲートウェイさえあれば，もっとクローズドなネットワークでＡＰＩさえ定義されていれば問題はない，という考え方もあるかもしれない。個人的にＵＰｎＰは優れた約束事だと思うが，ユーザーの立場からすれば動向をウォッチする段階から抜け出しているわけではない。」
　
（３）　周知文献３
　周知文献３（綾塚佑二他、「ＵｂｉｑｕｉｔｏｕｓＬｉｎｋｓ：　実世界環境に埋め込まれたハイパーメディアリンク」、情報処理学会研究報告、社団法人情報処理学会、１９９６年７月１１日、Ｖｏｌ．９６、Ｎｏ．６２、９６−ＨＩ−６７、ｐ．２３−３０）には、以下の記載がある（下線は当審付与。）。
　
ｅ．２４頁左欄２４行−右欄最下行、及び、同頁欄外注
「ＷＷＷの世界に存在する情報には現実世界のオブジェクトに関する情報も数多く存在する。例えば、あるアーテイストのＣＤに対して、そのＣＤ自体の情報やアーテイストの情報が存在する。
　しかし、その現実世界のオブジェクトに関するＷＷＷ上の情報を見るためには、ユーザはどこかでその情報の所在地（ＵＲＬ，Uniform Resource Locator）を入手する必要がある。現状では、そのＵＲＬは本などの計算機以外の媒体から写してくる１、またはＷＷＷ上の検索システムを使うことなどにより得ているため、状況に応じた適切な情報をその場で見るようなことは難しい。すなわち、現実世界のオブジェクトからＷＷＷの世界の関連する情報へのリンクはかなり弱いものとなっている。
　本研究では、現実世界のオブジェクトからＷＷＷの世界への情報のリンク構築すること（図１）を考え、携帯型の計算機をその仲介とする試作システム（UbiquitousLinks）を構築した。この試作システムは、携帯型の計算機を実世界のオブジェクトに近付けるとそれに関係するＷＷＷ上の惰報を見ることができる、というインタフェースを持つ（図２）。ＷＷＷ上の情報はハイパーテキストの上のリンクを張られた部分（特定の単語、絵など）をマウスなどでクリックすることにより辿る、という一般に広く用いられているインタフェースに準えたものである。
　このようなシステムを考える際に問題となるのは、”計算機が如何にしてオブジェクトを認識するか”ということである。今回の試作システムでは、
製品毎に固有のＩＤ
小さなタグを実世界のオブジェクトに張り付け
　
以下の節では、この試作システムの構成、機能、使用例などについて述べる
　　　　ｌ最近では製品自体にＵＲＬが記されている例もある」
　
ｆ．２６頁左欄５−１２行
「３．１　制御アプリケーション
　制御アプリケーションの機能は基本的にシリアルポートからＩＤを読み、それを関連付けられたＵＲＬに変換しそれをＷＷＷブラウザに伝える、ということである。
この変換のためのデータベースは本来ネットワーク経由でアクセスするべき性質のものであるが
　
ｇ．２９頁左欄２７−最下行
「
現在は
実際に一般のユーザが利用する場合にはこれもネットワーク経由でグローバルなものヘアクセスするようにしなければ使用範囲が大幅に限られてしまうことになる
ユーザの都合に合わせたデータベースを使用すればよい
　
　
４．対比
　本願発明と引用発明とを対比する。
　
（１）　引用発明の「設備」は、具体的には「たとえば工場などの各種の設備Ｘ1，Ｘ２，Ｘ３，…」、「展示物が置かれているパネルＹ1，Ｙ２，Ｙ３，…」、「看板等の物体」、「道路を跨いで設置されたガントリＧ」等が例示されるから、本願発明の「ホームネットワーク上の装置」と、「装置」である点で共通するといえる。
　
（２）　引用発明の「発信装置２」は、個々の「設備」に対応して個別に配置されるものであって、当該設備に関するＵＲＬを発信して、その設備に関連するホームページの自動閲覧機能を付加する点で、個々の「設備」を代理するデバイスすなわちプロキシデバイスであるといえるから、本願発明の「ホームネットワーク上の装置を表すプロキシデバイス」と、「装置を表すプロキシデバイス」である点で共通するといえる。
　
（３）　引用発明の「携帯端末６」は、「表示部６aの画面のタッチパネル」を備えて入力操作に用いる装置であるから、本願発明の「入力装置」に相当する。
　
（４）　引用発明の「サーバー４」は、本願発明の「サーバ」に相当する。また、引用発明の「サーバー４が格納するホームページ」は、本願発明の「サーバからのデータ」に相当する。
　
（５）　上記（１）−（４）より、引用発明の「ステップ３」−「ステップ７」において、「発信装置２」（本願発明の「プロキシデバイス」に対応する。）が、携帯端末６からＵＲＬ発信要求を受けて、「設備Ｘ1に該当するホームページのＵＲＬを…携帯端末６に向けて送信し(ステップ４)」、これによって、「この携帯端末６は、電話などの無線通信を使ってホームページを格納しているサーバー４にアクセスして、その設備Ｘ1に関連するホームページを開き(ステップ６)」との動作が開始されることは、本願発明の「前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置の
型式に固有の
　
（６）　引用発明の「たとえば工場などの各種の設備Ｘ1，Ｘ２，Ｘ３，…」に関連するホームページが、「携帯端末６の表示部６aに表示されるので、その表示部６aのタッチパネルの操作により設備Ｘ1に関する
各種の情報を取り出すことができ
当該設備Ｘ
1
の制御をすることができ
　
　したがって、本願発明と引用発明との一致点・相違点は次のとおりである。
　
＜一致点＞
「装置を表すプロキシデバイスにおいて、前記プロキシデバイスは入力装置からのユーザ入力に応答して前記の表された装置のＵＲＬによる制御の下でネットワークを経由してサーバからのデータの取り込みを前記入力装置を介して開始するプロキシデバイスであって、
　前記データは、前記装置の使用のコンテキストに関するコンテンツ情報を表している、
　ことを特徴とするプロキシデバイス。」
　
＜相違点１＞
　本願発明は、プロキシデバイスが表す「装置」が「ホームネットワーク上の装置」であり、「装置のＵＲＬ」が「装置の型式に固有の所定のＵＲＬ」であるのに対して、引用発明は、装置が、「たとえば工場などの各種の設備Ｘ1，Ｘ２，Ｘ３，…」であって、装置のＵＲＬが、「工場などの各種設備の情報を取り出したり設備の制御を行う」ホームページを示す「
各設備固有の
　
＜相違点２＞
　本願発明は、「サーバからのデータの取り込みをゲートウェイ及び前記入力装置を介して開始する」のに対して、引用発明では、「携帯端末６は、電話などの無線通信を使ってホームページを格納しているサーバー４にアクセスして、その設備Ｘ1に関連するホームページを開き(ステップ６)」との記載はあるものの、ホームページのデータの取り込みにおいて、「ゲートウエイ及び」前記入力装置を介して開始することは記載がない点。
　
＜相違点３＞
　本願発明では、「当該プロキシデバイスは前記装置に貼付され」るのに対して、引用発明の発信装置２は、「たとえば工場などの各種の設備Ｘ1，Ｘ２，Ｘ３，…に対して個別に発信装置２が
配置される
　
＜相違点４＞
　本願発明は「前記装置においてネットワークが構成化されていない場合には、ＵＰｎＰに従うＨＴＴＰマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のＵＲＬを得る」のに対して、引用発明は、「携帯端末６に記憶しているＩＤとＵＲＬとの対応テーブルを参照して該当するＵＲＬを選択」すること、すなわち、携帯端末６（本願発明の「入力装置」に対応する。）が、携帯端末６に設けた対応テーブルにより装置のＩＤに対応するＵＲＬを得ることによって、サーバー４にアクセスすることは記載があるものの、ネットワークが構成（コンフィギュレーション）されていない場合の動作について記載がない点。
　
　
５．当審の判断
＜相違点１＞について
　引用発明における「
たとえば
など
　
＜相違点２＞について
　各種装置を、インターネット等のネットワークに接続するために、「ゲートウエイ」を設けることは、慣用技術である（周知文献１の上記「３（１）周知文献、ｃ．」、周知文献２の上記「３（２）周知文献２、ｄ．」を参照）。
　よって、引用発明において、各種装置を、インターネット等のネットワークに接続するために、「ゲートウエイ」を設ける慣用技術を付加することによって、データの取り込みを「ゲートウエイ及び」前記入力装置を介して開始する、上記＜相違点２＞に係る構成とすることは、当業者が容易になし得ることである。
　
＜相違点３＞について
　一般に、装置を配置する手段として、「貼付」は普通に採用されている（周知文献３の上記「３（３）周知文献３、ｅ．」を参照）。
　よって、「たとえば工場などの各種の設備Ｘ1，Ｘ２，Ｘ３，…に対して個別に発信装置２が
配置される
　
＜相違点４＞について
　インターネット接続用に「ゲートウェイ」を設けるＵＰｎＰ規格に基づくネットワークにおいて、ネットワークを構成（コンフィギュレーション）するために、ＨＴＴＰのマルチキャスト通信によりネットワーク上のデバイスを発見（ディスカバリ）することは、周知技術である（周知文献１の上記「３（１）周知文献１、ａ．−ｃ．」の下線部、周知文献２の上記「３（２）周知文献２、ｄ．」の下線部を参照）。
　
　一般に、アドレス変換用のテーブルを、ネットワーク上のどのデバイスに配置するかは、システムの実装時に、当業者が適宜選択すべき設計的事項であると認められる（周知文献３の上記「３（３）周知文献３、ｆ．及びｇ．」の下線部を参照。）。
　
　したがって、引用発明において、インターネット接続用に「ゲートウェイ」を設けるＵＰｎＰ規格に基づくネットワークにおいて、ネットワークを構成（コンフィギュレーション）するために、ＨＴＴＰのマルチキャスト通信によりネットワーク上のデバイスを発見（ディスカバリ）する周知技術を適用すると共に、この際、装置のＩＤをＵＲＬにアドレス変換するための「対応テーブル」を、携帯端末６に記憶することに替えて、ネットワーク上のゲートウエイに配置することによって、「前記装置においてネットワークが構成化されていない場合には、ＵＰｎＰに従うＨＴＴＰマルチキャストメカニズムを用いて、インターネットゲートウェイから前記所定のＵＲＬを得る」、上記＜相違点４＞に係る構成とすることは、当業者が容易になし得ることである。
　
　さらに、本願発明の効果も、引用発明及び各周知技術に基づいて、当業者が予測し得る範囲内のものである。
　
６．小括
　したがって、本願発明は、引用発明及び各周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
第５　むすび 
　以上のとおり、本件出願は、特許法第３６条第６項第１号に規定する要件を満たしていない。また、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。