ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1311404 |
| 審判番号 | 不服2015-6898 |
| 総通号数 | 196 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2016-04-28 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2015-04-13 |
| 確定日 | 2016-02-18 |
| 事件の表示 | 特願2013-180891「情報処理装置、および情報処理方法、並びにプログラム」拒絶査定不服審判事件〔平成26年 1月 9日出願公開、特開2014- 2781〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、平成13年12月10日に出願した特願2001-375440号の一部を新たな特許出願である平成21年12月3日の特願2009-275087号とし、当該特願2009-275087号の一部を新たな特許出願である平成23年12月10日の特願2011-231842号とし、さらに当該特願2011-231842号の一部を平成25年9月2日に新たな特許出願としたものである。そして、その手続の経緯は以下のとおりである。 平成26年 5月22日:拒絶理由の通知 (起案日) 平成26年 7月22日:意見書、手続補正書の提出 平成27年 1月 7日:拒絶査定 (起案日) 平成27年 4月13日:審判請求書、手続補正書の提出 第2 平成27年4月13日付けの手続補正についての補正の却下の決定 [補正の却下の決定の結論] 平成27年4月13日付けの手続補正(以下、「本件補正」という。)を却下する。 [理由] 1.本件補正の内容 (1)本件補正後の特許請求の範囲の請求項1の記載 本件補正により、特許請求の範囲の請求項1の記載は、次のとおり補正された。(下線部は、補正箇所である。) 「 【請求項1】 機能提供装置を制御する制御装置であって、 ユーザの移動を検出する行動検出手段と、 前記行動検出手段によるユーザの移動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段と、 前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段と、 前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」 (2)本件補正前の特許請求の範囲の請求項1の記載 本件補正前の、平成26年7月22日付けの手続補正による特許請求の範囲の請求項1の記載は次のとおりである。 「 【請求項1】 機能提供装置を制御する制御装置であって、 ユーザの行動を検出する行動検出手段と、 前記行動検出手段による行動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段と、 前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段と、 前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」 (3)上記特許請求の範囲の請求項1についての補正は、補正前の請求項1に記載した発明を特定するために必要な事項である「行動検出手段」という構成について、ユーザの「移動」を検出するという限定を付加するものであって、平成18年法律第55号改正附則3条1項によりなお従前の例によるとされる同法による改正前の特許法(以下、「平成18年改正前特許法」という。)第17条の2第4項第2号の特許請求の範囲の減縮を目的とするものに該当する。 2.本件補正の適否 そこで、本件補正後の前記請求項1に記載された発明(以下、「本件補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(平成18年改正前特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)について以下に検討する。 (1)本件補正発明 本件補正発明は、上記1.(1)に記載したとおりのものである。 (2)引用例の記載事項 ア.原査定の拒絶の理由で引用された、本願の出願日前に頒布された刊行物である、特開2001-290724号公報(平成13年10月19日出願公開。以下、「引用例」という。)には、図面とともに、次の記載がある。 「【0018】 【発明が解決しようとする課題】したがって、さまざまなタイプのネットワークデバイスを相互接続し、デバイスの発見および利用のための一様な機構を提供する統一フレームワークに対して、強く幅広い受容が認識されており、このようなものがあることは非常に有利である。このような統一フレームワークは、ユーザアプリケーションが、アプリケーション-サービス間通信プロトコル、所望のサービスを提供するデバイスに接続されたホストのIPアドレスの発見、およびさらには、ネットワークサービスのユーザインタフェースの詳細のような低レベルの詳細を組み込むことを不要にするとともに、上記のその他の要求を満たす。」 (下線は、当審で注目する箇所を示すために付与した。以下、同様。) 「【0035】[アクティブコンフィグレーションフレームワークのコンポーネント]完全なアクティブコンフィグレーションアーキテクチャは、ダミーデバイス、ゲートウェイデバイス、および、ネットワークに直接的または間接的に接続されたPnPブローカからなる。アクティブコンフィグレーションフレームワークのアーキテクチャを図1に示す。図1に示すように、ネットワークには1個以上の実行環境102がある。実行環境102は、例えば、インターネットのようなネットワーク101を用いて相互接続される。実行環境102は、ある意味で、ネットワークノードとして作用する。実行環境102は、当業者に周知のJaｖa仮想マシンやWindｏｗｓTMベースのマシン内にあることが可能である。実行環境102は、ゲートウェイ(図示せず)を通じて非インテリジェント(すなわち、ダミー)デバイスに接続された1個以上のPnPブローカ104を有する。ユーザアプリケーション103は、PnPブローカ104を通じて、デバイスを発見し、利用し、デバイスと通信する。以下で、本発明のアクティブコンフィグレーションフレームワークシステムのさまざまなコンポーネントについて詳細に説明する。」 「【0050】[サービスディスカバリ/アベイラビリティエージェント]PnPブローカは、リモートPnPブローカを発見し利用可能なサービスを識別するために、サービスディスカバリ/アベイラビリティエージェントを必要とする。サービスディスカバリ(発見)は、ローカルPnPブローカによって指定される、要求されるサービスタイプを、リモートPnPブローカ上で利用可能なサービスタイプと比較することによって実行される。ローカルPnPブローカからリモートPnPブローカへ要求サービスタイプを送信し、リモートPnPブローカからローカルPnPブローカへその応答を送信するために、上記のJaｖaRMIやHTTPを使用することができる。要求サービスタイプの指定の検査により、PnPブローカは、リモートPnPブローカに登録されているすべてのあるいは特定のサービスの特性を決定することができる。サービスディスカバリ/アベイラビリティエージェントは、SLPユーザエージェントおよびSLPサービスエージェントの上に位置する。」 「【0058】[プロトコルと相互作用]PnPブローカは、ユーザアプリケーションがネットワークのプラグアンドプレイ機能を利用することができるようにする標準化されたインタフェースを公開する。このPnPブローカインタフェースを用いて、アプリケーションは、トランスポート層とは独立にPnPブローカ間プロトコルを用いて相互に通信するように書くことができる。この設計は、ポータビリティ(可搬性)を促進し、ネットワークサービスの発見および選択のためのスケーラブルなフレームワークを提供する。PnPブローカ間プロトコルは、IETF Service Location Protocol v.2に基づいており、サービスをサポートするネットワークホストの名前をユーザアプリケーションが知ることは不要である。むしろ、ユーザは、PnPブローカインタフェースを通じて、所望のサービスタイプと、対応する属性のセットとをPnPブローカに与える。これらは、PnPブローカに対して、所望のサービスを記述する。」 「【0060】[ユーザアプリケーションへのPnPブローカのインタフェース(PnPブローカインタフェース)]PnPブローカは、サービス登録、サービス発見、サービス要求、およびアベイラビリティチェックのために、ユーザアプリケーションに対して、標準化されたAPIおよびインタフェースを公開する。さらに、PnPブローカは、適当なサービスあるいはデバイスのためのユーザの識別および認証を扱う。 【0061】[サービス登録]必要なとき、サービスユニットまたははユーザアプリケーションは、それぞれ、サービスユニットまたはユーザアプリケーションとしてローカルPnPブローカに自分を登録または登録解除するために、RegisterService()またはUnregisterService()を呼び出す。ユーザアプリケーションまたはサービスユニットがPnPブローカに登録された後、その機能は、別のユーザアプリケーションまたはサービスユニットからのQueryService()またはSearchService()要求に対する応答に含まれる。 【0062】[サービス発見]ユーザアプリケーションは、SearchService()を呼び出して、ローカルPnPブローカに対し、特定のサービスを有する登録されたサービスユニットを含むPnPブローカを探索するよう要求する。ユーザアプリケーションは、QueryService()を呼び出して、どのようなサービスユニットが登録されているか、および、ユーザアプリケーションによって指定されたPnPブローカに登録されているサービスユニットの機能を発見する。 【0063】[サービス要求]ユーザアプリケーションまたはサービスユニットは、OpenService()を呼び出して、ローカルPnPブローカに対し、ローカルPnPブローカまたはリモートPnPブローカのいずれかに登録されている特定のサービスユニットとのサービスセッションを開始するよう要求する。TransferData()、ReceiveData()、およびCloseService()コールにより、追加機能が提供される。」 「【0069】[PnPブローカ間通信プロトコル]PnPブローカ間通信プロトコルは、2つの部分に分かれる。第1に、ネットワーク内で新たなデバイスおよびサービスを発見するための、プロトコルおよび機構のセットが使用される。発見(ディスカバリ)手続きは、ユーザアプリケーションがどのようにしてネットワークインフラストラクチャを探索するか、および、ユーザアプリケーションがどのようにして自分自身およびそのサービスを登録することができるかを指定するサービスディスカバリプロトコルの部分に基づく。他方、ルックアップ手続きは、ユーザアプリケーションが、集中化されたレジストリがある場合あるいはない場合に、必要とするサービスを探索するためにどのようにしてレジストリに問合せを行うかを指定するプロトコルに基づく。 【0070】いったんサービスが探索された後、そのサービスを利用するために他のステップが必要になることがある。本発明の実施例では、ユーザアプリケーションは、サービスの品質およびセキュリティ条件を含めて、サービスへのアクセスの交渉を行う。さらに、サービスへのアクセスの交渉が成功した後、ユーザアプリケーションは、JaｖaRMI、HOP、あるいはHTTPプロトコルを使用して、実際にサービスを利用する。 【0071】[サービスディスカバリ/登録プロセス]ルックアップおよびディスカバリの両方のために、サービスロケーションプロトコル(SLP)が使用される。図5に、サービスディスカバリ手続きを示す。SLPは、自動的に、しかも事前の設定なしで、ユーザエージェント(UA:user agent)502の要求を、サービスエージェント(SA:Service Agent)504によって提供されるサービス512と照合する。SLPは、SAによるサービスの公表と、ディレクトリエージェント(DA:Directory Agent)511により管理されるSLPディレクトリ508へのサービスの編成とを処理する。また、SLPは、サービスがユーザアプリケーションにサービスの能力および設定条件を通知する手段を提供する。 【0072】PnPブローカ501内のUA502は、ユーザアプリケーション103によるサービスおよびリソースの要求を理解する。同じくPnPブローカ503(同じPnPブローカでも異なるPnPブローカでもよい)にあるSA504は、各ネットワークサービスを代表し、UA502にとって利用可能なサービスを行う。SLPは、動的にサービス属性を保持するため、UA502は、現在の情報を取得することが可能である。サービスは、アプリケーションによって自動的に探索されることも可能であり、あるいは、サービスブラウザでユーザに提示されることも可能である。SLPは、既存のアプリケーションをサポートするとともに、新たなサービスの公表および発見を容易に可能にする。 【0073】本発明によれば、サービスは、ゲートウェイによって記述される。ゲートウェイは、SA内の属性(そのサービスに対応する)の値を設定する。例えば、プリンタは、ポストスクリプトプリンタとして、青色の紙が利用可能なプリンタとして、あるいは、ユーザのオフィスの同じフロアにあるプリンタとして、記述することができる。UA502は、DA511への要求メッセージSｒｖReｑ505において必要なキーワードおよび属性値を指定することによって適当なプリンタを選択し、応答を待つ。DA511は、適当するサービスのネットワークロケーションを含む応答SｒｖRｐlｙ505により応答する。小規模な施設では、DAがないことも可能であり、その場合、要求メッセージは直接にSAに送られることになる。これを、ブロードキャストによるディスカバリ(507)という。 【0074】サービスは、DA511に登録することによって自分自身を公表する。サービスの登録は、サービスを記述するすべてのキーワードと属性値対(属性と値からなる対)とからなるリストを含む。また、登録は、リソースへのリースを含む。これにより、リースの満期後、サービス情報はDA511によって削除される。リース機構は、サービスが永久に公表され続けているのにサービスハードウェアがもはや利用可能でない状況を避けるために実装される。また、明示的な登録解除も、SAの規則正しいシャットダウン手続きの一部として、DAからサービスの情報を削除することが可能である。また、SAが、現在の属性情報を周期的に登録することにより、UAが、サービスに関連するステータス、負荷、温度、あるいはその他の動的特性を確認することも可能である。 【0075】本発明のフレームワークでは、サービスは、そのサービスタイプに従って分類される。各サービスタイプは、SA504がサービスを記述するために利用可能にする、利用可能なキーワードおよび属性のセットを定義する。サービスブラウザは、まず、UA502にとって利用可能なサービスタイプを発見した後、そのサービスタイプについてSAによって公表されているすべての情報を問い合わせることによって、UA502にとって利用可能なすべてのサービスのすべての特性を決定することができる。」 「【0088】[サービス利用プロセス]サービスディスカバリ/登録プロセスは、サービスロケーションプロトコルによって提供されるURIによって検索可能なサービスレコードを提供する。PnPブローカ間の交換能力は、サービスレコードを含むQueryService()メッセージを交換することにより提供される。この問合せ(query)は、ユーザアプリケーションが利用したいサービスの要件を記述し、リモートPnPブローカに対してサービスの詳細を要求する。 【0089】受信側PnPブローカは、QueryService()メッセージを受信すると、受信したサービスレコードを自己のサービスレコードと比較する。その後、受信側PnPブローカは、一致したサービスレコードを含むサービスレコードを要求側PnPブローカに返す。このアプローチは、すべてのサービスユニット、特定のタイプのサービスユニット、あるいは、特定の能力のセットを有するサービスユニットのうちで、ユーザアプリケーションが探索を行う技術を提供する。ユーザアプリケーションは、サービスレコードを受け取った後、サービスあるいはデバイスを使用するためにPnPブローカとの通信を開始することができる。 【0090】ローカルPnPブローカは、リモートPnPブローカへメッセージを送ることによって、ユーザアプリケーションとサービスの間のサービスセッションの確立を要求する。このメッセージは、ユーザアプリケーションサービスハンドル、リモートサービスユニットハンドル、プロトコルID(ネイティブ/トンネル/ゲートウェイ経由)、要求側(リクエスタ)ID、および要求側資格証明(credential)からなる。 【0091】リモートPnPブローカは、要求されたサービスが受容されるかそれとも拒否されるかを指定するリザルトコードで応答する。リモートPnPブローカは、ある時間後のリダイレクトまたはリトライを含むことも可能である。サービスが受容される場合、リモートPnPブローカは、サービスセッションの開始を識別するサービスハンドルを送信する。サービスセッションは、ユーザアプリケーションとサービスユニットの間、または、2つのサービスユニットの間でのデータ転送を扱う。ユーザアプリケーションは、サービスの使用を完了すると、ローカルPnPブローカに対して、"close service"(サービス終了)メッセージをリモートPnPブローカへ送るよう要求する。さらに、ユーザアプリケーションは、サービスが利用可能であるかどうかを周期的に判定する必要があるとき、それぞれのPnPブローカに対して、フレームワーク内のPnPブローカ間でアベイラビリティチェックを実行するよう要求することができる。アベイラビリティチェックは、1つのデバイス全体に対しても、あるいは、デバイス内で提供される特定のサービスに対しても、実行可能である。」 「【0108】8.ユーザは、デバイスを使用したい場合、PnPブローカインタフェースを用いて、要求するサービスに対する問合せおよび検索を行う。すると、PnPブローカにあるユーザエージェントは、ディレクトリエージェントと連絡をとるか、あるいは、(サービスエージェントおよびユーザエージェントがいずれも1つのPnPブローカ内にある場合には)直接にサービスエージェントへ行く。」 イ.引用例の上記記載事項を、関連図面である図1、4-5と技術常識に照らせば、以下のことがいえる。 (ア)上記段落【0062】の「[サービス発見]ユーザアプリケーションは、SearchService()を呼び出して、ローカルPnPブローカに対し、特定のサービスを有する登録されたサービスユニットを含むPnPブローカを探索するよう要求する。」という記載、上記段落【0063】の「[サービス要求]ユーザアプリケーションまたはサービスユニットは、OpenService()を呼び出して、ローカルPnPブローカに対し、ローカルPnPブローカまたはリモートPnPブローカのいずれかに登録されている特定のサービスユニットとのサービスセッションを開始するよう要求する。」という記載、及び図4から、 引用例には、「リモートPnPブローカのサービスを要求するローカルPnPブローカ」が記載されている。 また、上記段落【0035】の「実行環境102は、当業者に周知のJaｖa仮想マシンやWindｏｗｓTMベースのマシン内にあることが可能である。実行環境102は、ゲートウェイ(図示せず)を通じて非インテリジェント(すなわち、ダミー)デバイスに接続された1個以上のPnPブローカ104を有する。」という記載、及び図1から、引用例の「PnPブローカ」は「マシン内」のものである。 よって、引用例には「マシン内のリモートPnPブローカのサービスを要求するマシン内のローカルPnPブローカ」が記載されていると認められる。 (イ)上記段落【0058】の「ユーザは、PnPブローカインタフェースを通じて、所望のサービスタイプと、対応する属性のセットとをPnPブローカに与える。これらは、PnPブローカに対して、所望のサービスを記述する。」という記載、上記段落【0108】の「ユーザは、デバイスを使用したい場合、PnPブローカインタフェースを用いて、要求するサービスに対する問合せおよび検索を行う。」という記載から、引用例には「ユーザの問合せの検出に応じて、サービスの検索を行う」ことが記載されていると認められる。 また、上記段落【0062】の「[サービス発見]ユーザアプリケーションは、SearchService()を呼び出して、ローカルPnPブローカに対し、特定のサービスを有する登録されたサービスユニットを含むPnPブローカを探索するよう要求する。」という記載、 並びに、上記段落【0073】の「小規模な施設では、DAがないことも可能であり、その場合、要求メッセージは直接にSAに送られることになる。これを、ブロードキャストによるディスカバリ(507)という。」という記載、図5にローカルPnPブローカであるPnPブローカ501のUA502からリモートPnPブローカであるPnPブローカ503のSA504に「ブロードキャストによるディスカバリ507」が送られることが図示されていること、及び、「ブロードキャスト」は一般的に複数の送信先への通信を意味することから、 引用例のローカルPnPブローカは、「リモートPnPブローカのサービスを検索する要求メッセージを、複数のリモートPnPブローカに対して、ブロードキャストにより送信する手段」を備えていると認められる。 (ウ)上記段落【0050】の「サービスディスカバリ(発見)は、ローカルPnPブローカによって指定される、要求されるサービスタイプを、リモートPnPブローカ上で利用可能なサービスタイプと比較することによって実行される。ローカルPnPブローカからリモートPnPブローカへ要求サービスタイプを送信し、リモートPnPブローカからローカルPnPブローカへその応答を送信する」という記載、 上記段落【0088】-【0089】の「PnPブローカ間の交換能力は、サービスレコードを含むQueryService()メッセージを交換することにより提供される。この問合せ(query)は、ユーザアプリケーションが利用したいサービスの要件を記述し、リモートPnPブローカに対してサービスの詳細を要求する。 【0089】受信側PnPブローカは、QueryService()メッセージを受信すると、受信したサービスレコードを自己のサービスレコードと比較する。その後、受信側PnPブローカは、一致したサービスレコードを含むサービスレコードを要求側PnPブローカに返す。このアプローチは、すべてのサービスユニット、特定のタイプのサービスユニット、あるいは、特定の能力のセットを有するサービスユニットのうちで、ユーザアプリケーションが探索を行う技術を提供する。」という記載から、 引用例のローカルPnPブローカは、「要求メッセージにより検索されるサービスと比較して一致するサービスがリモートPnPブローカに含まれる場合に、当該リモートPnPブローカから前記要求メッセージに対する応答を受信する手段」を備えていると認められる。 (エ)上記段落【0089】-【0090】の「ユーザアプリケーションは、サービスレコードを受け取った後、サービスあるいはデバイスを使用するためにPnPブローカとの通信を開始することができる。 【0090】ローカルPnPブローカは、リモートPnPブローカへメッセージを送ることによって、ユーザアプリケーションとサービスの間のサービスセッションの確立を要求する。このメッセージは、ユーザアプリケーションサービスハンドル、リモートサービスユニットハンドル、プロトコルID(ネイティブ/トンネル/ゲートウェイ経由)、要求側(リクエスタ)ID、および要求側資格証明(credential)からなる。」という記載から 引用例のローカルPnPブローカは、「応答を送信したリモートPnPブローカに対して、サービスセッションの確立を要求する手段」を備えることが記載されている。 ウ.以上を踏まえると、引用例には、次の発明(以下、「引用発明」という。)が記載されているといえる。 (引用発明) 「マシン内のリモートPnPブローカのサービスを要求するマシン内のローカルPnPブローカであって、 ユーザの問合せの検出に応じて、リモートPnPブローカのサービスを検索する要求メッセージを、複数のリモートPnPブローカに対して、ブロードキャストにより送信する手段と、 要求メッセージにより検索されるサービスと比較して一致するサービスがリモートPnPブローカに含まれる場合に、当該リモートPnPブローカから前記要求メッセージに対する応答を受信する手段と、 応答を送信したリモートPnPブローカに対して、サービスセッションの確立を要求する手段と、を備えるマシン内のローカルPnPブローカ。」 (3)引用発明との対比 ア.本件補正発明と引用発明とを対比する。 (ア)引用発明の「サービス」、「マシン内のリモートPnPブローカ」、サービスを「要求する」、「マシン内のローカルPnPブローカ」は、 それぞれ本件補正発明の「機能」、「機能提供装置」、「制御する」、「制御装置」に相当する。 (イ)引用発明の「リモートPnPブローカのサービス」、「複数のリモートPnPブローカ」は、 それぞれ本件補正発明の「前記機能提供装置で提供可能な機能」、「複数の機能提供装置」に相当し、それを踏まえると、 引用発明の「ユーザの問合せの検出に応じて、リモートPnPブローカのサービスを検索する要求メッセージを、複数のリモートPnPブローカに対して、ブロードキャストにより送信する手段」と、 本件補正発明の「前記行動検出手段によるユーザの移動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段」は、 「前記機能提供装置で提供可能な機能を検索する要求を、複数の機能提供装置に対して、送信する送信手段」である点で共通する。 (ウ)引用発明の「比較して一致するサービス」は、 本件補正発明の「対応する提供機能」に相当し、それを踏まえると、 引用発明の「要求メッセージにより検索されるサービスと比較して一致するサービスがリモートPnPブローカに含まれる場合に、当該リモートPnPブローカから前記要求メッセージに対する応答を受信する手段」と、 本件補正発明の「前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段」は、 「前記要求により検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記要求に対する応答を受信する受信手段」である点で共通する。 (エ)引用発明の「サービスセッションの確立」、「サービスセッションの確立を要求する」ことは、 それぞれ本件補正発明の「機能の提供」、「機能の提供を要求する」ことに相当し、それを踏まえると、 引用発明の「応答を送信したリモートPnPブローカに対して、サービスセッションの確立を要求する手段」は、 本件補正発明の「前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段」と、 「前記応答を送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段」である点で共通する。 イ.以上のことから、本件補正発明と引用発明との一致点及び相違点は、次のとおりである。 (一致点) 「機能提供装置を制御する制御装置であって、 前記機能提供装置で提供可能な機能を検索する要求を、複数の機能提供装置に対して、送信する送信手段と、 前記要求により検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記要求に対する応答を受信する受信手段と、 前記応答を送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」である点。 (相違点1) 本件補正発明は、「ユーザの移動を検出する行動検出手段」を備え、「前記行動検出手段によるユーザの移動の検出に応じて、」検索する要求を送信するものであるのに対し、 引用発明は、「ユーザの問合せの検出に応じて、」検索する要求を送信するものである点。 (相違点2) 本件補正発明は、検索する要求が「検索パケット」によって送信され、応答が「応答パケットによって」送受信されているのに対し、 引用発明は、検索する要求が「要求メッセージ」によって送信され、応答がどのような応答であるのか不明である点。 (相違点3) 本件補正発明は、「マルチキャストにより」検索する要求を送信するものであるのに対し、 引用発明の「ブロードキャスト」が、その構成に相当するものであるのか明らかではない点。 (4)判断 ア.(相違点1)について 以下の事情を総合すると、引用発明において、相違点1に係る本件補正発明の構成を採用することは、当業者が容易に想到し得たことというべきである。 (ア) あるエンティティ(例えばコンピュータなどの情報処理装置)がネットワークに新たに接続される契機としてユーザの移動があり、そのユーザの移動を検出手段によって検出し、ユーザの移動の検出に応じて利用できるサービスに関する検索を行うことは、周知の技術である。 このことは、「岩本 健嗣,“ウェアラブルネットワークにおける適応的なユーザ要求実行機構”,DICOMO 2000 シンポジウム論文集,日本,社団法人情報処理学会,2000年6月28日,Vol. 2000 No. 7,P. 625-630」(特に、要約、「2.1 ウェアラブルセンタ」の第1段落、「2.2 サービス」の第3段落の「ウェアラブルセンタは,現在接続しているネットワーク上に存在するディレクトリサービスから利用可能なサービスを検索する」という記載、「3. Wappletフレームワーク」の「ユーザの移動などに伴い利用可否状況が頻繁に変化する」という記載、「ミッション機構は環境プローブやディレクトリサービスを用いて,現在の状況を把握し」という記載、及び、「環境プローブは,ウェアラブルセンタに対してユーザの環境情報を提供するセンサ群などの総称であり」という記載参照)や、 特開2000-285053号公報(特に、要約、段落【0003】、【00006】、【0039】参照)から明らかである。 (イ) また、あるマシンが移動などにより新しいネットワークに接続された場合には、当該ネットワークにおいて利用できるサービスを新たに探さなければならいという一般的な課題が存在する。引用発明においても、ローカルPnPブローカを有するマシンが移動などにより新しいネットワークに接続された場合には、利用できるサービスを新たに探さなければならない。 (ウ) よって、引用例において検索する要求(要求メッセージ)を送信する契機として、ユーザの問合せの検出に加えて、上記周知の技術であるユーザの移動の検出手段によるユーザ移動検出を採用することは、当業者であれば容易になし得る。 イ.(相違点2)について 情報の通信の技術分野において、要求やそれに対する応答を、情報の伝送単位(ある程度のデータのかたまり)であるパケットに分割し、パケット単位で送受信を行うことは一般的に行われている。よって引用発明において、要求メッセージやそれに対する応答をパケットとして送受信する構成とすることは、当業者であれば容易に想到し得る。 ウ.(相違点3)について 複数の機能提供装置(サービスユニット)に対して検索パケット(発見要求メッセージ)を送信する際に、マルチキャスト・アドレスを用いたマルチキャストにより送信することは周知の技術である。 このことは、原査定の拒絶の理由で引用されたSLP(サービス・ロケーション・プロトコル)の標準化文書である、「J. VEIZADES, E. GUTTMAN, C. PERKINS, S. KAPLAN, "Service Location Protcol" RFC 2165, P. 6-14, [online], 1997年6月, IETF, インターネット よってこの周知の技術であるマルチキャストを、引用例における検索する要求(要求メッセージ)の送信に採用することは、当業者であれば容易になし得る。 ウ.本件補正発明の効果について 本件補正発明の構成によってもたらされる効果は、引用発明及び周知技術から容易に想到し得た構成のものが奏するであろうと当業者が予測し得る範囲を超えるものではなく、本願発明の進歩性を肯定する根拠となり得るものではない。 エ.まとめ したがって、本件補正発明は、引用例に記載された発明及び周知の技術に基づいて当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。 (5)本件補正の適否についてのむすび 以上のとおり、本件補正は、平成18年改正前特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 よって、上記補正の却下の決定の結論のとおり決定する。 第3 本願発明について 1.本願発明 平成27年4月13日付けの手続補正は、上記のとおり却下されたので、本願の請求項1に係る発明は、平成26年7月22日付けの手続補正書の特許請求の範囲の請求項1に記載された事項により特定されるものである。 その請求項1に係る発明(以下、「本願発明」という。)は、明細書及び図面の記載からみて、その請求項1に記載された事項により特定される、前記第2[理由]1.(2)に記載のとおりのものである。再掲すれば、次のとおり。 「 【請求項1】 機能提供装置を制御する制御装置であって、 ユーザの行動を検出する行動検出手段と、 前記行動検出手段による行動の検出に応じて、前記機能提供装置で提供可能な機能を検索する検索パケットを、複数の機能提供装置に対して、マルチキャストにより送信する送信手段と、 前記検索パケットにより検索される提供機能と対応する提供機能が、前記複数の機能提供装置の少なくともいずれか一つに含まれる場合に、当該機能提供装置から前記検索パケットに対する応答パケットを受信する受信手段と、 前記応答パケットを送信した前記機能提供装置の少なくとも一つに対して、前記機能の提供を要求する機能要求手段とを備える制御装置。」 2.引用例の記載事項 原査定の拒絶の理由で引用された引用例の記載事項は、前記第2[理由]2.(2)に記載したとおりである。 3.対比・判断 本願発明は、前記第2[理由]2.で検討した本件補正発明から、「行動検出手段」という構成について、ユーザの「移動」を検出するという限定事項を削除し、ユーザの「行動」を検出するとしたものである。 本願発明におけるユーザの「行動」を検出するという構成に関しては、引用発明における「ユーザの問合せの検出」を行う構成がこの構成に相当する。 そうすると、本願発明の発明特定事項を全て含み、さらに他の限定事項を付加したものに相当する本件補正発明が、前記第2[理由]2.(3)、(4)に記載したとおり、引用例に記載された発明及び周知の技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用例に記載された発明及び周知の技術に基づいて当業者が容易に発明をすることができたものである。 4.むすび 以上のとおり、本願発明は、特許法第29条第2項の規定により特許を受けることができない。したがって、本願は、拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2015-12-16 |
| 結審通知日 | 2015-12-22 |
| 審決日 | 2016-01-05 |
| 出願番号 | 特願2013-180891(P2013-180891) |
| 審決分類 |
P
1
8・
575-
Z
(G06F)
P 1 8・ 121- Z (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 小林 秀和 |
| 特許庁審判長 |
和田 志郎 |
| 特許庁審判官 |
稲葉 和生 桜井 茂行 |
| 発明の名称 | 情報処理装置、および情報処理方法、並びにプログラム |
| 代理人 | 宮田 正昭 |