【事件の表示】
　特願２０１３−１８０８９１「情報処理装置、および情報処理方法、並びにプログラム」拒絶査定不服審判事件〔平成２６年　１月　９日出願公開、特開２０１４−　　２７８１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成１３年１２月１０日に出願した特願２００１−３７５４４０号の一部を新たな特許出願である平成２１年１２月３日の特願２００９−２７５０８７号とし、当該特願２００９−２７５０８７号の一部を新たな特許出願である平成２３年１２月１０日の特願２０１１−２３１８４２号とし、さらに当該特願２０１１−２３１８４２号の一部を平成２５年９月２日に新たな特許出願としたものである。そして、その手続の経緯は以下のとおりである。
　平成２６年　５月２２日：拒絶理由の通知　（起案日）
　平成２６年　７月２２日：意見書、手続補正書の提出
　平成２７年　１月　７日：拒絶査定　（起案日）
　平成２７年　４月１３日：審判請求書、手続補正書の提出
第２　平成２７年４月１３日付けの手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成２７年４月１３日付けの手続補正（以下、「本件補正」という。）を却下する。
［理由］
１．本件補正の内容
（１）本件補正後の特許請求の範囲の請求項１の記載
　本件補正により、特許請求の範囲の請求項１の記載は、次のとおり補正された。（下線部は、補正箇所である。）
「　【請求項１】
　機能提供装置を制御する制御装置であって、
　ユーザの
移動
　前記行動検出手段による
ユーザの移動
　前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段と、
　前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」
（２）本件補正前の特許請求の範囲の請求項１の記載
　本件補正前の、平成２６年７月２２日付けの手続補正による特許請求の範囲の請求項１の記載は次のとおりである。
「　【請求項１】
　機能提供装置を制御する制御装置であって、
　ユーザの行動を検出する行動検出手段と、
　前記行動検出手段による行動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段と、
　前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段と、
　前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」
（３）上記特許請求の範囲の請求項１についての補正は、補正前の請求項１に記載した発明を特定するために必要な事項である「行動検出手段」という構成について、ユーザの「
移動
２．本件補正の適否
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本件補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
（１）本件補正発明
　本件補正発明は、上記１．（１）に記載したとおりのものである。
（２）引用例の記載事項
　ア．原査定の拒絶の理由で引用された、本願の出願日前に頒布された刊行物である、特開２００１−２９０７２４号公報（平成１３年１０月１９日出願公開。以下、「引用例」という。）には、図面とともに、次の記載がある。
「【００１８】
【発明が解決しようとする課題】したがって、
さまざまなタイプのネットワークデバイスを相互接続し、デバイスの発見および利用のための一様な機構を提供する統一フレームワークに対して、強く幅広い受容が認識されており、このようなものがあることは非常に有利である
（下線は、当審で注目する箇所を示すために付与した。以下、同様。）
「【００３５】［アクティブコンフィグレーションフレームワークのコンポーネント］完全なアクティブコンフィグレーションアーキテクチャは、ダミーデバイス、ゲートウェイデバイス、および、ネットワークに直接的または間接的に接続されたＰｎＰブローカからなる。アクティブコンフィグレーションフレームワークのアーキテクチャを図１に示す。図１に示すように、ネットワークには１個以上の実行環境１０２がある。実行環境１０２は、例えば、インターネットのようなネットワーク１０１を用いて相互接続される。実行環境１０２は、ある意味で、ネットワークノードとして作用する。
実行環境１０２は、当業者に周知のＪａｖａ仮想マシンやＷｉｎｄｏｗｓTMベースのマシン内にあることが可能である。実行環境１０２は、ゲートウェイ（図示せず）を通じて非インテリジェント（すなわち、ダミー）デバイスに接続された１個以上のＰｎＰブローカ１０４を有する。
「【００５０】［サービスディスカバリ／アベイラビリティエージェント］ＰｎＰブローカは、リモートＰｎＰブローカを発見し利用可能なサービスを識別するために、サービスディスカバリ／アベイラビリティエージェントを必要とする。
サービスディスカバリ（発見）は、ローカルＰｎＰブローカによって指定される、要求されるサービスタイプを、リモートＰｎＰブローカ上で利用可能なサービスタイプと比較することによって実行される。ローカルＰｎＰブローカからリモートＰｎＰブローカへ要求サービスタイプを送信し、リモートＰｎＰブローカからローカルＰｎＰブローカへその応答を送信する
「【００５８】［プロトコルと相互作用］ＰｎＰブローカは、ユーザアプリケーションがネットワークのプラグアンドプレイ機能を利用することができるようにする標準化されたインタフェースを公開する。このＰｎＰブローカインタフェースを用いて、アプリケーションは、トランスポート層とは独立にＰｎＰブローカ間プロトコルを用いて相互に通信するように書くことができる。この設計は、ポータビリティ（可搬性）を促進し、ネットワークサービスの発見および選択のためのスケーラブルなフレームワークを提供する。ＰｎＰブローカ間プロトコルは、IETF Service Location Protocol v.2に基づいており、サービスをサポートするネットワークホストの名前をユーザアプリケーションが知ることは不要である。むしろ、
ユーザは、ＰｎＰブローカインタフェースを通じて、所望のサービスタイプと、対応する属性のセットとをＰｎＰブローカに与える。これらは、ＰｎＰブローカに対して、所望のサービスを記述する
「【００６０】
［ユーザアプリケーションへのＰｎＰブローカのインタフェース（ＰｎＰブローカインタフェース）］ＰｎＰブローカは、サービス登録、サービス発見、サービス要求、およびアベイラビリティチェックのために、ユーザアプリケーションに対して、標準化されたＡＰＩおよびインタフェースを公開する
【００６１】［サービス登録］必要なとき、サービスユニットまたははユーザアプリケーションは、それぞれ、サービスユニットまたはユーザアプリケーションとしてローカルＰｎＰブローカに自分を登録または登録解除するために、RegisterService()またはUnregisterService()を呼び出す。ユーザアプリケーションまたはサービスユニットがＰｎＰブローカに登録された後、その機能は、別のユーザアプリケーションまたはサービスユニットからのQueryService()またはSearchService()要求に対する応答に含まれる。
【００６２】
［サービス発見］ユーザアプリケーションは、SearchService()を呼び出して、ローカルＰｎＰブローカに対し、特定のサービスを有する登録されたサービスユニットを含むＰｎＰブローカを探索するよう要求する
【００６３】［
サービス要求］ユーザアプリケーションまたはサービスユニットは、OpenService()を呼び出して、ローカルＰｎＰブローカに対し、ローカルＰｎＰブローカまたはリモートＰｎＰブローカのいずれかに登録されている特定のサービスユニットとのサービスセッションを開始するよう要求する
「【００６９】［ＰｎＰブローカ間通信プロトコル］ＰｎＰブローカ間通信プロトコルは、２つの部分に分かれる。第１に、ネットワーク内で新たなデバイスおよびサービスを発見するための、プロトコルおよび機構のセットが使用される。発見（ディスカバリ）手続きは、ユーザアプリケーションがどのようにしてネットワークインフラストラクチャを探索するか、および、ユーザアプリケーションがどのようにして自分自身およびそのサービスを登録することができるかを指定するサービスディスカバリプロトコルの部分に基づく。他方、ルックアップ手続きは、ユーザアプリケーションが、集中化されたレジストリがある場合あるいはない場合に、必要とするサービスを探索するためにどのようにしてレジストリに問合せを行うかを指定するプロトコルに基づく。
【００７０】いったんサービスが探索された後、そのサービスを利用するために他のステップが必要になることがある。本発明の実施例では、ユーザアプリケーションは、サービスの品質およびセキュリティ条件を含めて、サービスへのアクセスの交渉を行う。さらに、サービスへのアクセスの交渉が成功した後、ユーザアプリケーションは、ＪａｖａＲＭＩ、ＨＯＰ、あるいはＨＴＴＰプロトコルを使用して、実際にサービスを利用する。
【００７１】
［サービスディスカバリ／登録プロセス］
ディスカバリの両方のために、サービスロケーションプロトコル（ＳＬＰ）が使用される
図５に、サービスディスカバリ手続きを示す。ＳＬＰは、自動的に、しかも事前の設定なしで、ユーザエージェント（ＵＡ：user agent）５０２の要求を、サービスエージェント（ＳＡ：Service Agent）５０４によって提供されるサービス５１２と照合する
ＳＬＰは、ＳＡによるサービスの公表
を処理する
【００７２】ＰｎＰブローカ５０１内のＵＡ５０２は、ユーザアプリケーション１０３によるサービスおよびリソースの要求を理解する。同じく
ＰｎＰブローカ５０３（同じＰｎＰブローカでも異なるＰｎＰブローカでもよい）にあるＳＡ５０４は、各ネットワークサービスを代表し、ＵＡ５０２にとって利用可能なサービスを行う
【００７３】本発明によれば、サービスは、ゲートウェイによって記述される。ゲートウェイは、ＳＡ内の属性（そのサービスに対応する）の値を設定する。例えば、プリンタは、ポストスクリプトプリンタとして、青色の紙が利用可能なプリンタとして、あるいは、ユーザのオフィスの同じフロアにあるプリンタとして、記述することができる。
ＵＡ５０２は、ＤＡ５１１への要求メッセージＳｒｖＲｅｑ５０５において必要なキーワードおよび属性値を指定することによって適当なプリンタを選択し、応答を待つ。ＤＡ５１１は、適当するサービスのネットワークロケーションを含む応答ＳｒｖＲｐｌｙ５０５により応答する
小規模な施設では、ＤＡがないことも可能であり、その場合、要求メッセージは直接にＳＡに送られることになる。これを、ブロードキャストによるディスカバリ（５０７）という
【００７４】サービスは、ＤＡ５１１に登録することによって自分自身を公表する。サービスの登録は、サービスを記述するすべてのキーワードと属性値対（属性と値からなる対）とからなるリストを含む。また、登録は、リソースへのリースを含む。これにより、リースの満期後、サービス情報はＤＡ５１１によって削除される。リース機構は、サービスが永久に公表され続けているのにサービスハードウェアがもはや利用可能でない状況を避けるために実装される。また、明示的な登録解除も、ＳＡの規則正しいシャットダウン手続きの一部として、ＤＡからサービスの情報を削除することが可能である。また、ＳＡが、現在の属性情報を周期的に登録することにより、ＵＡが、サービスに関連するステータス、負荷、温度、あるいはその他の動的特性を確認することも可能である。
【００７５】本発明のフレームワークでは、サービスは、そのサービスタイプに従って分類される。各サービスタイプは、ＳＡ５０４がサービスを記述するために利用可能にする、利用可能なキーワードおよび属性のセットを定義する。サービスブラウザは、まず、ＵＡ５０２にとって利用可能なサービスタイプを発見した後、そのサービスタイプについてＳＡによって公表されているすべての情報を問い合わせることによって、ＵＡ５０２にとって利用可能なすべてのサービスのすべての特性を決定することができる。」
「【００８８】［サービス利用プロセス］サービスディスカバリ／登録プロセスは、サービスロケーションプロトコルによって提供されるＵＲＩによって検索可能なサービスレコードを提供する。
ＰｎＰブローカ間の交換能力は、サービスレコードを含むQueryService()メッセージを交換することにより提供される。この問合せ(query)は、ユーザアプリケーションが利用したいサービスの要件を記述し、リモートＰｎＰブローカに対してサービスの詳細を要求する。
【００８９】受信側ＰｎＰブローカは、QueryService()メッセージを受信すると、受信したサービスレコードを自己のサービスレコードと比較する。その後、受信側ＰｎＰブローカは、一致したサービスレコードを含むサービスレコードを要求側ＰｎＰブローカに返す。このアプローチは、すべてのサービスユニット、特定のタイプのサービスユニット、あるいは、特定の能力のセットを有するサービスユニットのうちで、ユーザアプリケーションが探索を行う技術を提供する
ユーザアプリケーションは、サービスレコードを受け取った後、サービスあるいはデバイスを使用するためにＰｎＰブローカとの通信を開始することができる
【００９０】
ローカルＰｎＰブローカは、リモートＰｎＰブローカへメッセージを送ることによって、ユーザアプリケーションとサービスの間のサービスセッションの確立を要求する
このメッセージは、ユーザアプリケーションサービスハンドル、リモートサービスユニットハンドル、プロトコルＩＤ（ネイティブ／トンネル／ゲートウェイ経由）、要求側（リクエスタ）ＩＤ、および要求側資格証明(credential)からなる
【００９１】
リモートＰｎＰブローカは、要求されたサービスが受容されるかそれとも拒否されるかを指定するリザルトコードで応答する
サービスが受容される場合、リモートＰｎＰブローカは、サービスセッションの開始を識別するサービスハンドルを送信する
サービスセッションは、ユーザアプリケーションとサービスユニットの間、または、２つのサービスユニットの間でのデータ転送を扱う
「【０１０８】８．
ユーザは、デバイスを使用したい場合、ＰｎＰブローカインタフェースを用いて、要求するサービスに対する問合せおよび検索を行う
　イ．引用例の上記記載事項を、関連図面である図１、４−５と技術常識に照らせば、以下のことがいえる。
　（ア）上記段落【００６２】の「［サービス発見］ユーザアプリケーションは、SearchService()を呼び出して、ローカルＰｎＰブローカに対し、特定のサービスを有する登録されたサービスユニットを含むＰｎＰブローカを探索するよう要求する。」という記載、上記段落【００６３】の「［サービス要求］ユーザアプリケーションまたはサービスユニットは、OpenService()を呼び出して、ローカルＰｎＰブローカに対し、ローカルＰｎＰブローカまたはリモートＰｎＰブローカのいずれかに登録されている特定のサービスユニットとのサービスセッションを開始するよう要求する。」という記載、及び図４から、
引用例には、「リモートＰｎＰブローカのサービスを要求するローカルＰｎＰブローカ」が記載されている。
　また、上記段落【００３５】の「実行環境１０２は、当業者に周知のＪａｖａ仮想マシンやＷｉｎｄｏｗｓTMベースのマシン内にあることが可能である。実行環境１０２は、ゲートウェイ（図示せず）を通じて非インテリジェント（すなわち、ダミー）デバイスに接続された１個以上のＰｎＰブローカ１０４を有する。」という記載、及び図１から、引用例の「ＰｎＰブローカ」は「マシン内」のものである。
　よって、引用例には「マシン内のリモートＰｎＰブローカのサービスを要求するマシン内のローカルＰｎＰブローカ」が記載されていると認められる。
　（イ）上記段落【００５８】の「ユーザは、ＰｎＰブローカインタフェースを通じて、所望のサービスタイプと、対応する属性のセットとをＰｎＰブローカに与える。これらは、ＰｎＰブローカに対して、所望のサービスを記述する。」という記載、上記段落【０１０８】の「ユーザは、デバイスを使用したい場合、ＰｎＰブローカインタフェースを用いて、要求するサービスに対する問合せおよび検索を行う。」という記載から、引用例には「ユーザの問合せの検出に応じて、サービスの検索を行う」ことが記載されていると認められる。
　また、上記段落【００６２】の「［サービス発見］ユーザアプリケーションは、SearchService()を呼び出して、ローカルＰｎＰブローカに対し、特定のサービスを有する登録されたサービスユニットを含むＰｎＰブローカを探索するよう要求する。」という記載、
並びに、上記段落【００７３】の「小規模な施設では、ＤＡがないことも可能であり、その場合、要求メッセージは直接にＳＡに送られることになる。これを、ブロードキャストによるディスカバリ（５０７）という。」という記載、図５にローカルＰｎＰブローカであるＰｎＰブローカ５０１のＵＡ５０２からリモートＰｎＰブローカであるＰｎＰブローカ５０３のＳＡ５０４に「ブロードキャストによるディスカバリ５０７」が送られることが図示されていること、及び、「ブロードキャスト」は一般的に複数の送信先への通信を意味することから、
引用例のローカルＰｎＰブローカは、「リモートＰｎＰブローカのサービスを検索する要求メッセージを、複数のリモートＰｎＰブローカに対して、ブロードキャストにより送信する手段」を備えていると認められる。
　（ウ）上記段落【００５０】の「サービスディスカバリ（発見）は、ローカルＰｎＰブローカによって指定される、要求されるサービスタイプを、リモートＰｎＰブローカ上で利用可能なサービスタイプと比較することによって実行される。ローカルＰｎＰブローカからリモートＰｎＰブローカへ要求サービスタイプを送信し、リモートＰｎＰブローカからローカルＰｎＰブローカへその応答を送信する」という記載、
上記段落【００８８】−【００８９】の「ＰｎＰブローカ間の交換能力は、サービスレコードを含むQueryService()メッセージを交換することにより提供される。この問合せ(query)は、ユーザアプリケーションが利用したいサービスの要件を記述し、リモートＰｎＰブローカに対してサービスの詳細を要求する。
【００８９】受信側ＰｎＰブローカは、QueryService()メッセージを受信すると、受信したサービスレコードを自己のサービスレコードと比較する。その後、受信側ＰｎＰブローカは、一致したサービスレコードを含むサービスレコードを要求側ＰｎＰブローカに返す。このアプローチは、すべてのサービスユニット、特定のタイプのサービスユニット、あるいは、特定の能力のセットを有するサービスユニットのうちで、ユーザアプリケーションが探索を行う技術を提供する。」という記載から、
引用例のローカルＰｎＰブローカは、「要求メッセージにより検索されるサービスと比較して一致するサービスがリモートＰｎＰブローカに含まれる場合に、当該リモートＰｎＰブローカから前記要求メッセージに対する応答を受信する手段」を備えていると認められる。
　（エ）上記段落【００８９】−【００９０】の「ユーザアプリケーションは、サービスレコードを受け取った後、サービスあるいはデバイスを使用するためにＰｎＰブローカとの通信を開始することができる。
【００９０】ローカルＰｎＰブローカは、リモートＰｎＰブローカへメッセージを送ることによって、ユーザアプリケーションとサービスの間のサービスセッションの確立を要求する。このメッセージは、ユーザアプリケーションサービスハンドル、リモートサービスユニットハンドル、プロトコルＩＤ（ネイティブ／トンネル／ゲートウェイ経由）、要求側（リクエスタ）ＩＤ、および要求側資格証明(credential)からなる。」という記載から
引用例のローカルＰｎＰブローカは、「応答を送信したリモートＰｎＰブローカに対して、サービスセッションの確立を要求する手段」を備えることが記載されている。
　ウ．以上を踏まえると、引用例には、次の発明（以下、「引用発明」という。）が記載されているといえる。
（引用発明）
「マシン内のリモートＰｎＰブローカのサービスを要求するマシン内のローカルＰｎＰブローカであって、
　ユーザの問合せの検出に応じて、リモートＰｎＰブローカのサービスを検索する要求メッセージを、複数のリモートＰｎＰブローカに対して、ブロードキャストにより送信する手段と、
　要求メッセージにより検索されるサービスと比較して一致するサービスがリモートＰｎＰブローカに含まれる場合に、当該リモートＰｎＰブローカから前記要求メッセージに対する応答を受信する手段と、
　応答を送信したリモートＰｎＰブローカに対して、サービスセッションの確立を要求する手段と、を備えるマシン内のローカルＰｎＰブローカ。」
（３）引用発明との対比
　ア．本件補正発明と引用発明とを対比する。
　（ア）引用発明の「サービス」、「マシン内のリモートＰｎＰブローカ」、サービスを「要求する」、「マシン内のローカルＰｎＰブローカ」は、
それぞれ本件補正発明の「機能」、「機能提供装置」、「制御する」、「制御装置」に相当する。
　（イ）引用発明の「リモートＰｎＰブローカのサービス」、「複数のリモートＰｎＰブローカ」は、
それぞれ本件補正発明の「前記機能提供装置で提供可能な機能」、「複数の機能提供装置」に相当し、それを踏まえると、
引用発明の「ユーザの問合せの検出に応じて、リモートＰｎＰブローカのサービスを検索する要求メッセージを、複数のリモートＰｎＰブローカに対して、ブロードキャストにより送信する手段」と、
本件補正発明の「前記行動検出手段によるユーザの移動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段」は、
「前記機能提供装置で提供可能な機能を検索する要求を、複数の機能提供装置に対して、送信する送信手段」である点で共通する。
　（ウ）引用発明の「比較して一致するサービス」は、
本件補正発明の「対応する提供機能」に相当し、それを踏まえると、
引用発明の「要求メッセージにより検索されるサービスと比較して一致するサービスがリモートＰｎＰブローカに含まれる場合に、当該リモートＰｎＰブローカから前記要求メッセージに対する応答を受信する手段」と、
本件補正発明の「前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段」は、
「前記要求により検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記要求に対する応答を受信する受信手段」である点で共通する。
　（エ）引用発明の「サービスセッションの確立」、「サービスセッションの確立を要求する」ことは、
それぞれ本件補正発明の「機能の提供」、「機能の提供を要求する」ことに相当し、それを踏まえると、
引用発明の「応答を送信したリモートＰｎＰブローカに対して、サービスセッションの確立を要求する手段」は、
本件補正発明の「前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段」と、
「前記応答を送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段」である点で共通する。
　イ．以上のことから、本件補正発明と引用発明との一致点及び相違点は、次のとおりである。
（一致点）
「機能提供装置を制御する制御装置であって、
　前記機能提供装置で提供可能な機能を検索する要求を、複数の機能提供装置に対して、送信する送信手段と、
　前記要求により検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記要求に対する応答を受信する受信手段と、
　前記応答を送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」である点。
（相違点１）
　本件補正発明は、「ユーザの移動を検出する行動検出手段」を備え、「前記行動検出手段によるユーザの移動の検出に応じて、」検索する要求を送信するものであるのに対し、
引用発明は、「ユーザの問合せの検出に応じて、」検索する要求を送信するものである点。
（相違点２）
　本件補正発明は、検索する要求が「検索パケット」によって送信され、応答が「応答パケットによって」送受信されているのに対し、
引用発明は、検索する要求が「要求メッセージ」によって送信され、応答がどのような応答であるのか不明である点。
（相違点３）
　本件補正発明は、「マルチキャストにより」検索する要求を送信するものであるのに対し、
引用発明の「ブロードキャスト」が、その構成に相当するものであるのか明らかではない点。
（４）判断
　ア．（相違点１）について
　以下の事情を総合すると、引用発明において、相違点１に係る本件補正発明の構成を採用することは、当業者が容易に想到し得たことというべきである。
　（ア）　あるエンティティ（例えばコンピュータなどの情報処理装置）がネットワークに新たに接続される契機としてユーザの移動があり、そのユーザの移動を検出手段によって検出し、ユーザの移動の検出に応じて利用できるサービスに関する検索を行うことは、周知の技術である。
　このことは、「岩本　健嗣，“ウェアラブルネットワークにおける適応的なユーザ要求実行機構”，DICOMO 2000 シンポジウム論文集，日本，社団法人情報処理学会，２０００年６月２８日，Vol. 2000 No. 7，P. 625-630」（特に、要約、「2.1 ウェアラブルセンタ」の第１段落、「2.2 サービス」の第３段落の「ウェアラブルセンタは，現在接続しているネットワーク上に存在するディレクトリサービスから利用可能なサービスを検索する」という記載、「3. Wappletフレームワーク」の「ユーザの移動などに伴い利用可否状況が頻繁に変化する」という記載、「ミッション機構は環境プローブやディレクトリサービスを用いて，現在の状況を把握し」という記載、及び、「環境プローブは，ウェアラブルセンタに対してユーザの環境情報を提供するセンサ群などの総称であり」という記載参照）や、
特開２０００−２８５０５３号公報（特に、要約、段落【０００３】、【００００６】、【００３９】参照）から明らかである。
　（イ）　また、あるマシンが移動などにより新しいネットワークに接続された場合には、当該ネットワークにおいて利用できるサービスを新たに探さなければならいという一般的な課題が存在する。引用発明においても、ローカルＰｎＰブローカを有するマシンが移動などにより新しいネットワークに接続された場合には、利用できるサービスを新たに探さなければならない。
　（ウ）　よって、引用例において検索する要求（要求メッセージ）を送信する契機として、ユーザの問合せの検出に加えて、上記周知の技術であるユーザの移動の検出手段によるユーザ移動検出を採用することは、当業者であれば容易になし得る。
　イ．（相違点２）について
　情報の通信の技術分野において、要求やそれに対する応答を、情報の伝送単位（ある程度のデータのかたまり）であるパケットに分割し、パケット単位で送受信を行うことは一般的に行われている。よって引用発明において、要求メッセージやそれに対する応答をパケットとして送受信する構成とすることは、当業者であれば容易に想到し得る。
　ウ．（相違点３）について
　複数の機能提供装置（サービスユニット）に対して検索パケット（発見要求メッセージ）を送信する際に、マルチキャスト・アドレスを用いたマルチキャストにより送信することは周知の技術である。
　このことは、原査定の拒絶の理由で引用されたSLP（サービス・ロケーション・プロトコル）の標準化文書である、「J. VEIZADES, E. GUTTMAN, C. PERKINS, S. KAPLAN, Service Location Protcol RFC 2165, P. 6-14, [online], １９９７年６月, IETF, インターネットURL: http://www.rfc-editor.org/rfc/pdfrfc/rfc2165.txt.pdf」における、「3.1. Protocol Transactions」のP. 7の最後の段落〜P. 8の最初の段落、P. 10-11の「3.6. Use of TCP, UDP and Multicast in Service Location」〜「3.6.1.1. Sigle Subnet」、P. 11-12の「3.6.2. Service-Specific Multicast Address」に記載されている「Multicast」の説明からも明らかである。
　よってこの周知の技術であるマルチキャストを、引用例における検索する要求（要求メッセージ）の送信に採用することは、当業者であれば容易になし得る。
　ウ．本件補正発明の効果について
　本件補正発明の構成によってもたらされる効果は、引用発明及び周知技術から容易に想到し得た構成のものが奏するであろうと当業者が予測し得る範囲を超えるものではなく、本願発明の進歩性を肯定する根拠となり得るものではない。
　エ．まとめ
　したがって、本件補正発明は、引用例に記載された発明及び周知の技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
（５）本件補正の適否についてのむすび
　以上のとおり、本件補正は、平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１．本願発明
　平成２７年４月１３日付けの手続補正は、上記のとおり却下されたので、本願の請求項１に係る発明は、平成２６年７月２２日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定されるものである。
　その請求項１に係る発明（以下、「本願発明」という。）は、明細書及び図面の記載からみて、その請求項１に記載された事項により特定される、前記第２［理由］１．（２）に記載のとおりのものである。再掲すれば、次のとおり。
「　【請求項１】
　機能提供装置を制御する制御装置であって、
　ユーザの行動を検出する行動検出手段と、
　前記行動検出手段による行動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段と、
　前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段と、
　前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」
２．引用例の記載事項
　原査定の拒絶の理由で引用された引用例の記載事項は、前記第２［理由］２．（２）に記載したとおりである。
３．対比・判断
　本願発明は、前記第２［理由］２．で検討した本件補正発明から、「行動検出手段」という構成について、ユーザの「
移動
　本願発明におけるユーザの「行動」を検出するという構成に関しては、引用発明における「ユーザの問合せの検出」を行う構成がこの構成に相当する。
　そうすると、本願発明の発明特定事項を全て含み、さらに他の限定事項を付加したものに相当する本件補正発明が、前記第２［理由］２．（３）、（４）に記載したとおり、引用例に記載された発明及び周知の技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用例に記載された発明及び周知の技術に基づいて当業者が容易に発明をすることができたものである。
４．むすび
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができない。したがって、本願は、拒絶されるべきものである。
　よって、結論のとおり審決する。