【事件の表示】
　特願２００６−２７８０４４「通信装置、通信方法および通信プログラム」拒絶査定不服審判事件〔平成２０年　４月２４日出願公開、特開２００８−　９７２９７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１８年１０月１１日の出願であって、平成２２年８月２５日付けで拒絶査定がなされ、これに対し、平成２２年１２月３日に拒絶査定不服審判が請求されると同時に手続補正がなされたものである。
　
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年１２月３日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
　「宅内ネットワークおよび宅外ネットワークに通信可能に接続される通信装置であって、
　前記宅内ネットワークに設置された第一のデバイスから当該宅内ネットワークに設置された自デバイス以外の不特定多数の第二のデバイスに発信されるリクエストであり、前記第二のデバイスから前記第一のデバイスに提供されるサービスに関する情報を要求する旨のリクエストを受信して宛先に転送するリクエスト受信手段と、
　前記リクエスト受信手段によってリクエストを受信した場合に、当該リクエストを前記宅外ネットワークに設置された第三のデバイスであって、他デバイスに提供するサービスに関する情報の一覧を記憶し、ネットワークを介して他のデバイスから受信したリクエストに応じて当該他のデバイスに提供されるサービスに関する情報を提供する装置に転送して、前記第三のデバイスに送信されたリクエストが当該第三のデバイスにおいて正当なリクエストであると認証されることを条件に、前記第一のデバイスに提供されるサービスに関する情報を前記第三のデバイスから取得し、当該取得した情報を前記不特定多数の第二のデバイスに送信されたリクエストの応答として前記第一のデバイスに送信するリクエスト応答手段と、
　を備えたことを特徴とする通信装置。」　
　
　
３．刊行物
　
刊行物１．特開２００１−７８６１号公報
　
刊行物２．樋口正生 他，“家庭内AVネットワーク技術「HAVi」の概要”，Pioneer RD，２００１年７月３１日，Ｖｏｌ．１１，Ｎｏ．２，ｐｐ．３９−４９
　
３−１．刊行物１の記載
　原査定の拒絶の理由に引用された刊行物１（特開２００１−７８６１号公報）には、図面と共に、以下の事項が記載されている。
　
（ア）第０００２段落
【従来の技術】ＨＡＶｉは、家庭内のＡＶ機器を制御可能にするミドルウェアであり、ＩＥＥＥ１３９４対応のＡＶ機器を制御対象にしている
　
（イ）第０００３段落
【０００３】ＨＡＶｉ仕様の詳細は、Ｔｈｅ ＨＡＶｉ Ｓｐｅｃｉｆｉｃａｔｉｏｎ （Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｈｏｍｅ Ａｕｄｉｏ／Ｖｉｄｅｏ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ） （http://www.havi.org/） で紹介されており、また、家庭外ではインターネットプロトコル（IP）をベースにした多種多様なネットワークサービスが提供されている。インターネットに接続される機器間でのプラグアンドプレイを実現する技術がすでに開示されている。同様に、インターネットでのプラグアンドプレイの技術が開示されている。
　
（ウ）第００１６段落
【発明の実施の形態】（実施の形態１）以下本発明の請求項１記載のゲートウェイ装置の実施の形態を図面を参照しながら説明する。
　
（エ）第００１８段落
【００１８】ＨＡＶｉ機器（第１のネットワークの機器）１０１は、ＨＡＶｉネットワーク（第１のネットワーク）１０２に接続されるＨＡＶｉ仕様に準拠したデジタルテレビ（ＤＴＶ）やビデオテープレコーダ（ＶＴＲ）などのＡＶ機器である。ゲートウェイ（ＧＷ）装置１０３は、ＩＰネットワーク（第２のネットワーク）１０４と前記ＨＡＶｉネットワーク間でそれぞれのネットワークに接続された機器が相互に通信できる機能を提供するものであり、ＨＡＶｉ仕様の定めるＦＡＶ（Full AV device）相当の機能を備えているものとする。ＩＰ機器（第２のネットワークの機器）１０５はＩＰネットワークに接続されるネットワークプリンタなどのネットワーク機器である。
　
（オ）第００３８段落
【００３８】（実施の形態２）以下本発明の請求項２記載のゲートウェイ装置の実施の形態を図面を参照しながら説明する。
　
（カ）第００３９段落から第００４０段落
　また、ＩＰディレクトリ９１５は、IPネットワーク上において、サービスの検索サービスやサービスを利用するためのインタフェース情報の提供を行なうものである。
【００４０】なお、ＩＰディレクトリは必ずしも１つの機器で集中管理する必要はなく、各機器自身が自分のプラグイン情報をネットワーク内に同報し、機器検索には該当する機器自身が応答するような形態であっても良い。
　
（キ）第００４７段落
　なお、本実施例では、通知されたイベントの付加情報によりプラグインされた機器の種類の情報を得たが、HAVi機器側からのレジストリ検索要求をトリガーとして、IP側ディレクトリ情報を検索するように動作しても良い。
　
（ク）第００４９段落
【００４９】ＩＰプラグイン検知手段９０９から依頼を受けた仮想デバイス管理手段９０７は、IPディレクトリサーバ９１５へ問い合わせを行ない、プラグインされた機器のインタフェース情報を取得する。なお、インタフェース情報の取得は、HAVi機器からＩＰ機器が検索された時点や、ＨＡＶｉ機器からＧＷ装置を通しての接続依頼を受けた時点で行なっても良い。
　
（ケ）第００７８段落
【００７８】（実施の形態４）以下本発明の請求項４記載のゲートウェイ装置の実施の形態を図面を参照しながら説明する。
　
（コ）第００８０段落
【００８０】HAViストリーム管理手段１７１６は、ＨＡＶｉ仕様に準拠したHAVi機器間のストリーム転送を可能にするものである。仮想デバイス１７１１は実施の形態１に記載の構成に加えて、IPネットワークに接続されたＩＰ機器とのコネクションを確立し、必要な場合は帯域の確保を行なう。ストリームポート対応管理手段１７１７は、ＧＷ装置上のＨＡＶｉ仕様におけるストリームの管理単位であるＦＣＭプラグ（HAVi Functional Component Plug）とＩＰストリームポートの対応を管理するものである。ストリームパケット変換手段１７１８は、ＨＡＶｉストリームパケットとＩＰストリームパケットを相互に変換して送出するものである。他の要素については、実施の形態１から３の説明と同様である。
　
（サ）第００８５段落
【００８５】映像受信能力を持つIP機器１７０５がプラグインされると、実施例２で説明したように、GW装置１７０３のHAViレジストリ１７１３にIPディレクトリ１７１５と連動して登録される。この際、GW装置はプラグインされたIP機器について、１）ストリームを扱う能力を持つか、２）扱えるデータレート、を機器情報として収集、記憶しておく。
　
（シ）第００８７段落
【００８７】HAVi機器１７０１は、映像を受信することが可能な機器をHAVi Registry の機能を使って検索を行なう[１８０１]。先に説明したように、IP機器１７０５が映像を受信できる機器として登録されているので、GW装置１７０３は、IP機器の仮想デバイス１７１１のHAViアドレスSEIDをHAVi機器へ返信する［１８０２］。
　
　以上の刊行物１の記載によれば、刊行物１には、次の発明（以下、「刊行物１記載発明」という。）が記載されていると認められる。
　
　「ＨＡＶｉ機器（第１のネットワークの機器）１０１は、ＨＡＶｉネットワーク（第１のネットワーク）１０２に接続されるＨＡＶｉ仕様に準拠したデジタルテレビ（ＤＴＶ）やビデオテープレコーダ（ＶＴＲ）などのＡＶ機器であり、
ゲートウェイ（ＧＷ）装置１０３は、ＩＰネットワーク（第２のネットワーク）１０４と前記ＨＡＶｉネットワーク間でそれぞれのネットワークに接続された機器が相互に通信できる機能を提供するものであり、
　ＩＰ機器（第２のネットワークの機器）１０５はＩＰネットワークに接続されるネットワークプリンタなどのネットワーク機器であり、
　映像受信能力を持つＩＰ機器１７０５がプラグインされると、ＧＷ装置１７０３のHAViレジストリ１７１３にIPディレクトリ１７１５と連動して登録され、
　ＨＡＶｉ機器１７０１は、映像を受信することが可能な機器をHAVi Registry の機能を使って検索を行ない、
　ＧＷ装置１７０３は、登録されているＩＰ機器の仮想デバイス１７１１のHAViアドレスSEIDをＨＡＶｉ機器へ返信する、ＧＷ装置を含むネットワーク。」
　
３−２．刊行物２の記載
　周知技術を示す刊行物２には、図面と共に、以下の事項が記載されている。
　
（ス）第４６頁右欄第２行から第２５行
　Registryは全てのFAVとIAV機器に実装され，ホームネットワーク上のソフトウェアエレメントを検索するためのディレクトリサービスを提供する。Registryは機器内（ローカル）にあるソフトウェアエレメントのSEIDとその属性情報が登録されるデータベースを管理する。HAViのメッセージ通信を行いたいソフトウェアエレメントはRegistryのRegisterElement APIを用いて，自分のSEIDとその属性情報（ソフトウェアエレメントの種類やベンダIDなど）をRegistryに登録する。登録されたソフトウェアエレメントはホームネットワーク上の他のソフトウェアエレメントから見えるようになり，通信（APIの呼び出しなど）が可能になる。特定のソフトウェアエレメントのSEIDを検索したい場合は，属性情報をパラメータとしてRegistryのGetElement APIを呼び出すことによりSEIDを得ることができる。またSEIDをパラメータとしてRetrieveElement APIを呼び出すことにより属性情報を取り出すこともできる。これらのAPIを受けたRegistryは自ら持つデータベース内を検索すると共に，他のFAV・IAV機器上にある全てのRegistryに対し検索依頼を出すので，ホームネットワーク全体としての検索を行うことができる。
　
　
４．対比
　本願発明と刊行物１記載発明とを以下で対比する。
　
　ＨＡＶｉは家庭内のＡＶ機器を制御可能にするものであるから（上記摘記事項（ア）を参照）、刊行物１記載発明の「ＨＡＶｉネットワーク（第１のネットワーク）」及び「ＨＡＶｉ機器（第１のネットワークの機器）」は、それぞれ本願発明の「宅内ネットワーク」及び「第一のデバイス」に相当する。
　
　上記摘記事項（イ）の「家庭外ではインターネットプロトコル（IP）をベースにした多種多様なネットワークサービスが提供されている。インターネットに接続される機器間でのプラグアンドプレイを実現する技術がすでに開示されている。同様に、インターネットでのプラグアンドプレイの技術が開示されている。」との記載に鑑みれば、刊行物１記載発明の「ＩＰネットワーク（第２のネットワーク）」及び「ＩＰ機器（第２のネットワークの機器）」は、それぞれ本願発明の「宅外ネットワーク」及び「第三のデバイス」に相当する。
　
　刊行物１記載発明の「ゲートウェイ（ＧＷ）装置」は、「ＩＰネットワーク（第２のネットワーク）１０４と前記ＨＡＶｉネットワーク間でそれぞれのネットワークに接続された機器が相互に通信できる機能を提供するもの」であるから、本願発明の「宅内ネットワークおよび宅外ネットワークに通信可能に接続される通信装置」に相当する。
　
　刊行物１記載発明は、「ＨＡＶｉ機器１７０１は、映像を受信することが可能な機器をHAVi Registry の機能を使って検索を行な」うものである。
　ここで、ＨＡＶｉのＲｅｇｉｓｔｒｙは、「ソフトウェアエレメントのSEIDとその属性情報が登録されるデータベースを管理する」ものであって、かつ、「これらのAPIを受けたRegistryは自ら持つデータベース内を検索すると共に，他のFAV・IAV機器上にある全てのRegistryに対し検索依頼を出すので，ホームネットワーク全体としての検索を行うことができる」ものである（刊行物２に関する上記摘記事項（ス）を参照）。「ソフトウェアエレメントのSEIDとその属性情報」がＨＡＶｉ機器の提供するサービスに関する情報であることは、技術常識から明らかである。
　してみると、刊行物１記載発明の「ＨＡＶｉ１７０１は、映像を受信することが可能な機器をHAVi Registry の機能を使って検索を行な」うという動作は、本願発明の「前記宅内ネットワークに設置された第一のデバイスから当該宅内ネットワークに設置された自デバイス以外の不特定多数の第二のデバイスに発信されるリクエストであり、前記第二のデバイスから前記第一のデバイスに提供されるサービスに関する情報を要求する旨のリクエスト」を第一のデバイスが発信することに相当する。
　刊行物１記載発明は、上記リクエストの発信動作の後に「ＧＷ装置１７０３は、登録されているＩＰ機器の仮想デバイス１７１１のHAViアドレスSEIDをＨＡＶｉ機器へ返信する」という動作をするのであるから、刊行物１記載発明のＧＷ装置の「ＩＰ機器の仮想デバイス１７１１のHAViアドレスSEIDをＨＡＶｉ機器へ返信する」という動作は、上記リクエストに対する応答をＨＡＶｉ機器に対して返信する動作であると解される。
　そして、刊行物１記載発明のＧＷ装置は、上記リクエストに対する応答をする以上、上記リクエストを受信する手段を持たなければならないのは自明である。
　刊行物１記載発明で返信される「ＩＰ機器の仮想デバイス１７１１のHAViアドレスSEID」は、「映像受信能力を持つＩＰ機器１７０５がプラグインされると、ＧＷ装置１７０３のHAViレジストリ１７１３にIPディレクトリ１７１５と連動して登録され」たものであるから、本願発明の「前記第三のデバイスから取得し」た「前記第一のデバイスに提供されるサービスに関する情報」に相当する。
　以上によれば、本願発明と刊行物１記載発明とは、「前記宅内ネットワークに設置された第一のデバイスから当該宅内ネットワークに設置された自デバイス以外の不特定多数の第二のデバイスに発信されるリクエストであり、前記第二のデバイスから前記第一のデバイスに提供されるサービスに関する情報を要求する旨のリクエストを受信するリクエスト受信手段」及び「前記第一のデバイスに提供されるサービスに関する情報を前記第三のデバイスから取得し、当該取得した情報を前記不特定多数の第二のデバイスに送信されたリクエストの応答として前記第一のデバイスに送信するリクエスト応答手段」を備える点で一致する。
　
　すると、本願発明と刊行物１記載発明との一致点及び相違点は、以下のとおりである。
　
〈一致点〉
　「宅内ネットワークおよび宅外ネットワークに通信可能に接続される通信装置であって、
　前記宅内ネットワークに設置された第一のデバイスから当該宅内ネットワークに設置された自デバイス以外の不特定多数の第二のデバイスに発信されるリクエストであり、前記第二のデバイスから前記第一のデバイスに提供されるサービスに関する情報を要求する旨のリクエストを受信するリクエスト受信手段と、
　前記第一のデバイスに提供されるサービスに関する情報を前記第三のデバイスから取得し、当該取得した情報を前記不特定多数の第二のデバイスに送信されたリクエストの応答として前記第一のデバイスに送信するリクエスト応答手段と、
　を備えたことを特徴とする通信装置。」である点。
　
〈相違点１〉
　本願発明のリクエスト受信手段は、「サービスに関する情報を要求する旨のリクエストを受信して
宛先に転送する
　
〈相違点２〉
　本願発明の「第三のデバイス」は、「他デバイスに提供するサービスに関する情報の一覧を記憶し」ているのに対し、刊行物１記載発明の「ＩＰ機器」（本願発明の「第三のデバイス」に相当）は、そのような情報の一覧を記憶しているか否かが明らかではない点。
　
〈相違点３〉
　本願発明の「第三のデバイス」は、「ネットワークを介して他のデバイスから受信したリクエストに応じて当該他のデバイスに提供されるサービスに関する情報を提供する」のに対し、刊行物１記載発明の「ＩＰ機器」（本願発明の「第三のデバイス」に相当）は、そのような動作をするか否かが明らかではない点。
　
〈相違点４〉
　本願発明は、「前記リクエスト受信手段によってリクエストを受信した場合に、当該リクエストを」「第三のデバイス」「に転送」するのに対し、刊行物１記載発明は、そのような動作をするか否かが明らかではない点。
　
〈相違点５〉
　本願発明では、前記第一のデバイスに提供されるサービスに関する情報を前記第三のデバイスから取得する動作が、「前記第三のデバイスに送信されたリクエストが当該第三のデバイスにおいて正当なリクエストであると認証されることを条件に」行われるのに対し、刊行物１記載発明では、前記動作がそのような条件の下で行われるのではない点。
　
　
５．判断
　
５−１．相違点１について
　刊行物１記載発明のＧＷ装置は、ゲートウェイである。
　一般にゲートウェイは、ルーターにソフトウェアとして組み込まれるものであり、ルータは宛先に応じて通信を転送するものである。
　してみると、刊行物１記載発明のＧＷ装置を、ルータに組み込むことによって、本願発明のように「サービスに関する情報を要求する旨のリクエストを受信して宛先に転送する」ものとすることは、当業者が容易になし得ることである。
　
５−２．相違点２について
　刊行物１記載発明において、「他デバイスに提供するサービスに関する情報の一覧」に相当する情報は、原則として「ＩＰディレクトリ」にて提供されるものであるが、上記摘記事項（カ）に「ＩＰディレクトリは必ずしも１つの機器で集中管理する必要はなく、各機器自身が自分のプラグイン情報をネットワーク内に同報し、機器検索には該当する機器自身が応答するような形態であっても良い。」とあるように、ＩＰディレクトリの機能をＩＰ機器に持たせること、すなわち、「第三のデバイス」に「他デバイスに提供するサービスに関する情報の一覧を記憶」させることは、刊行物１に示唆されている。
　したがって、刊行物１記載発明の「ＩＰ機器」（本願発明の「第三のデバイス」に相当）を、「他デバイスに提供するサービスに関する情報の一覧を記憶」するようにすることは、容易になし得る。
　
５−３．相違点３及び４について
　刊行物１には、「なお、本実施例では、通知されたイベントの付加情報によりプラグインされた機器の種類の情報を得たが、HAVi機器側からのレジストリ検索要求をトリガーとして、IP側ディレクトリ情報を検索するように動作しても良い。」との記載（上記摘記事項（キ）を参照）、及び、「ＩＰディレクトリは必ずしも１つの機器で集中管理する必要はなく、各機器自身が自分のプラグイン情報をネットワーク内に同報し、機器検索には該当する機器自身が応答するような形態であっても良い。」との記載（上記摘記事項（カ）を参照）がある。
　これらの記載によれば、本願発明のＧＷ装置は、ＨＡＶｉ機器からのRegistry検索要求を受信したことを契機に、ＩＰ側のディレクトリ情報を検索するように動作させ、ＩＰ側ではRegistry検索要求に対する応答をＩＰ機器が返すことが示唆されている。これは、ＨＡＶｉ機器からのリクエストを、ＩＰ機器に転送し、ＩＰ機器がそれに応答する形で「サービスに関する情報提供」することを示唆しているに他ならない。
　してみれば、刊行物１記載発明において、「第三のデバイス」が「ネットワークを介して他のデバイスから受信したリクエストに応じて当該他のデバイスに提供されるサービスに関する情報を提供する」ようにし、かつ、刊行物１記載発明が「前記リクエスト受信手段によってリクエストを受信した場合に、当該リクエストを」「第三のデバイス」「に転送」するようにすることは、当業者が容易になし得ることである。
　
５−４．相違点５について
　電子通信において、リクエストが正当なものか否かを確認して、正当なリクエストであることを条件にしてその後の動作を行うことは、文献を挙げるまでもない周知技術である。
　刊行物１記載発明に上記周知技術を適用し、「前記第三のデバイスに送信されたリクエストが当該第三のデバイスにおいて正当なリクエストであると認証されることを条件に、前記第一のデバイスに提供されるサービスに関する情報を前記第三のデバイスから取得」するように構成することは、当業者が容易になし得ることである。
　
５−５．効果について
　また、本願発明の構成によって生じる効果も、上記刊行物１発明及び周知技術から当業者が予測し得る範囲内のもので格別顕著であるとはいえない。
　
　
６．むすび
　以上のとおり、本願発明は、刊行物１記載発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。