【事件の表示】
　特願２００４−３７２１４６「ネットワーク上でのサービス共有のための装置及び方法」拒絶査定不服審判事件〔平成１７年　７月２１日出願公開、特開２００５−１９６７７２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、
平成１６年１２月２２日付けの出願（優先日：２００４年１月８日，大韓民国）であって、
同日付けで審査請求がなされ、
平成１８年１１月２７日付けで拒絶理由通知（同年１２月５日発送）がなされ、
平成１９年３月２日付けで意見書が提出されると共に、同日付けで手続補正書が提出され、
同年９月４日付けで拒絶理由通知（同年９月１１日発送）がなされ、
平成２０年２月１日付けで意見書が提出されると共に、同日付けで手続補正書が提出され、
同年３月５日付けで拒絶理由通知（同年３月１１日発送）がなされ、
同年７月１０日付けで意見書が提出されると共に、同日付けで手続補正書が提出され、
同年１０月３１日付けで拒絶査定（同年１１月１１日発送）がなされ、
平成２１年２月９日付けで審判請求がされると共に、
同年３月１０日付けで手続補正書が提出され、
同年５月１３日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２２年９月２９日付けで当該報告に対する意見を求める旨の審尋（同年１０月５日発送)がなされ、これに対して
平成２３年２月２日付けで回答書が提出され、
同年６月１７日付けで拒絶理由通知（同年６月２１日発送）がなされ、
同年１０月２１日付けで意見書が提出されると共に、同日付けで手続補正書が提出されたものである。
　
　
２．上記平成２３年６月１７日付けの拒絶理由通知（以下「当審拒絶理由通知」と記す。）で通知した拒絶理由は次の通りのものである。
『この出願は、発明の詳細な説明及び特許請求の範囲の記載が下記の点で、特許法第３６条第４項第１号及び第６項第１号、第２号、第３号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　 記
（１）本願の請求項１〜１５には、下記（１−１）〜（１−２２）に例示するように、その意味や他の発明特定事項との関連の不明確な記載、発明の詳細な説明と整合しない記載が多数ある。
　このため、請求項１〜１５に係る発明は、これに属する具体的事物の範囲を明確に把握し得るものではなく、明確でない。（第３６条第６項第２号（明確性要件）違反）
　また、請求項１〜１５に係る発明は、発明の詳細な説明に記載したものでないとも言える。（第３６条第６項第１号（サポート要件）違反）
　さらに、このため、本願の発明の詳細な説明は、当業者が請求項１〜１５に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり（第３６条第４項第１号（実施可能要件）違反）、しかも、請求項１〜１５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものでもある（第３６条第４項第１号（委任省令要件）違反）と言える。
　また、請求項２、５〜７、１０〜１３は、冗長な記載を含み、簡潔でない。（第３６条第６項第３号（簡潔要件）違反）
　
（１−１）請求項１に「デバイスが所定のネットワークに連結されると・・・・ネットワーク上でのサービス共有のための装置」とあるが、該「デバイス」「ネットワーク」「装置」の関係（「デバイス」と「装置」は共通のものなのか？別個のものなのか？「装置」は「デバイス」の一部品なのか？　「デバイス」が「装置」の一部品なのか？　「装置」は「ネットワーク」に連結されているものなのか？「ネットワーク」も「デバイス」をも含むものなのか？　等々）が明確でない。（これらの点は発明の詳細な説明及び図面を参酌しても明確に把握し得るものではない（下記（２−２２）（２−２３）等参照））
　
　
（１−２）請求項１に「デバイスが所定のネットワークに連結されると、前記デバイスから収集されたシステムリソース情報を利用して複数のOSGiプラットフォームに各々に設けられて、OSGiプラットフォームに共有されていない機能である所定の標準サービス共有のためのサービス役割を決定するサービス役割設定部」とあるが、
　
（１−２−１）「ネットワークに連結される」「デバイス」と「システムリソース情報」の「収集」元である「デバイス」とが共通のものである旨の記載は、本願の発明の詳細な説明にはない。（なお、本願の発明の詳細な説明中の該発明特定事項に関連する記載としては、段落【００３５】【００３６】【００４９】【００５０】等の記載があるが、該記載からも「連結される」「デバイス」と「システムリソース情報」の収集元の「デバイス」が共通のものであるか否かは定かでない。）
　
（１−２−２）「デバイスから収集されたシステムリソース情報」とは何か（「デバイス」内の「リソース」を示す「情報」なのか？「デバイス」が接続されるネットワークなどを含む「システム」全体の「リソース」を示す「情報」なのか？）が明確でない。
　
（１−２−３）「リソース」と「標準サービス」との関係（何らかの関連があるのか？無関係でよいのか？）が明確でない。
　
（１−２−４）「利用して」は何を修飾しているのかが明確でない。（読点の位置からは「設けられて」を修飾していると解するのが妥当であるが、それでは技術的に不合理である。）
　
（１−２−５）請求項１の「機能である」は何を修飾するのか（「標準サービス共有」は「標準サービス
の
　
（１−２−６）「サービス役割」とは何を意味するのか（どのデバイスにどの標準サービスが実装されているかを示す情報なのか？特定の標準サービスに対してマスターとして動作するかエージェントとして動作するかを示す情報なのか？あるいは他のものなのか？）が明確でない。
　
（１−２−７）「サービス役割を決定する」とは、何を決定することを意味するのか（「デバイス」とは別個に設けられた装置の「サービス役割」を「決定」することを意味するのか？　「連結」された「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」することを意味するのか？「連結」された「デバイス」以外の「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」しなおすことを意味するのか？）、何を基にどう決定するのか（自己のリソースを基に自己が提供可能な「標準サービス」を決定するのか？自己のリソースを基に自己がマスターになり得るか否かを決定するのか？他のデバイスのリソースを基にどのデバイスがどの標準サービスのマスターになるかを決定するのか？）が明確でない。
　
（１−２−８）「決定する」とは、発明の詳細な説明記載の何れの事項に対応するのか（段落【００３５】【００３６】【００４９】【００５０】記載の「決定」に対応するのか？段落【００３７】【００５２】【００５３】の「設定」に対応するのか？段落【００５１】の「判別」に対応するのか？）が明確でない。（用語のみからみれば「決定」に対応すると解するのが最も妥当ではあるが、請求項１の「前記決定されたサービスエージェントモジュール役割によってサービス要請情報を変換する」との記載を考慮すると「設定」や「判別」をも含むとの解釈も成り立つ。）
　
（１−２−９）他にも、発明の詳細な説明における表現と異なる記載があり、明確な対応付けができない。（例えば、「OSGiプラットフォーム」なる用語は発明の詳細な説明にはない。）
　
　
（１−３）請求項１に「前記サービス役割設定部により決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを外部指定され、サービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service Framework）、多様なサービスを実行するための多数の標準サービス（Core Services）、これらの標準サービスを利用して開発されたアプリケーションサービス（Appls Service）とから構成されたOSGiサービスプラットフォームを有するデバイスに対して処理要請するサービス要請処理部とを含み」とあるが、
　
（１−３−１）「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（１−３−２）「サービス役割」と「要求」や「外部指定」「処理要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−３−３）「標準サービスを外部指定」の「標準サービスを」は何を修飾するのか（「外部指定され」を修飾するのか？「実行する」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（１−３−４）「外部指定され」とは如何なる意味なのか（「外部」から「指定」されることの意味なのか？「外部」に対して「指定」することなのか？）が明確でない。
　
（１−３−５）「外部指定され」は何を修飾するのか（「サービスフレームワーク」を修飾するのか？「OSGiサービスプラットフォーム」を修飾するのか？「デバイス」を修飾するのか？「処理要請する」を修飾するのか？「サービス要請処理部」を修飾するのか？）が明確でない。
　
（１−３−６）「外部指定」の「外部」とは何の外部を意味するのか（アプリケーションなどの「標準サービス」の外部の事なのか？「サービス役割設定部」等の「サービス要請処理部」の外部のことなのか？他の「デバイス」の事なのか？）が明確でない。
　
（１−３−７）「所定のサービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（１−３−８）「サービス支援」とは何か（「サービスを実行する」と同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？後者であるならば何がどう異なるのか？「サービス」を「指定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　
（１−３−９）「サービス実行環境提供のためのサービス伝達と管理を実行する」とは何処から何処へ如何なる情報を伝達することを意味するのか（アプリケーションからのサービス要請の情報を標準サービスに引き渡すのか？他のデバイスからのサービス要請を自デバイスの標準サービスやアプリケーションに引き渡すのか？）が明確でない。
　
（１−３−１０）「多様なサービスを実行するための多数の標準サービス」と、上記（１−２）で摘記した「所定の標準サービス共有」の「標準サービス」との関係（同じものなのか異なるものなのか？）上記（１−２）で摘記した「決定」された「サービス役割」との関係（無関係なのか否か？）が明確でない。
　
（１−３−１１）「これらの標準サービスを利用して開発されたアプリケーションサービス」とあるが、その意味が不明。（文言通りの解釈をすると、「標準サービス」とは開発ツールで、該開発ツールを利用して「アプリケーションサービス」を開発することを限定していると解されるが、これは発明の詳細な説明記載の課題等と全く相入れない。「これらの標準サービスを利用」するように「開発されたアプリケーションサービス」の誤訳か？）
　
（１−３−１２）「OSGiプラットフォームを有するデバイス」は、上記（１−２）で摘記した「連結され」た「デバイス」や「収集された」「デバイス」とは如何なる関係にあるのか（無関係でよいのか？）、上記（１−２）で摘記した「決定」された「サービス役割」とは如何なる関係なのか（無関係でよいのか？）が明確でない。
　
（１−３−１３）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（（段落【００４２】や段落【００６２】には「デバイスに対して処理要請する」旨の記載は無い。）
　
　
（１−４）請求項１に「前記サービス要請処理部は、前記決定されたサービスエージェントモジュール役割によってサービス要請情報を変換するデータ変換部を含む」とあるが、
　
（１−４−１）「サービスエージェントモジュール役割」なるものを「決定する」旨の記載は前記されていない。
　
（１−４−２）「サービスエージェントモジュール役割」は本願発明の詳細な説明にも記載されておらず、その結果、その具体的事物の範囲が明確でない。
　
（１−４−３）「サービスエージェントモジュール役割」と「変換」との関係（「サービスエージェントモジュール役割」が、「変換」に如何に関与するのか？「サービスエージェントモジュール役割」と言う物が該「変換」処理を実行する主体となると解してよいのか？「サービスエージェントモジュール役割」と言うパラメータが該「変換」処理の結果に影響すると言う意味か？後者であるならば、「サービスエージェントモジュール役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−４−４）「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（１−４−５）ここでの「変換」は発明の詳細な説明中のどの事項（ステップＳ１４？　ステップＳ１７？　ステップＳ２１？　ステップＳ２４？）と対応するのかが明確でない。（「ステップＳ１４」のみに対応すると仮定すると、ステップＳ１７が特許請求の範囲に反映されていないことになるが、これでは所期の課題を達成できない。「ステップＳ１７」にも対応すると仮定すると、上記（１−３）で摘記した「デバイス」に「処理要請」する旨の事項と矛盾する。）
　
　
（１−５）請求項２に「前記選出アルゴリズムは、前記ネットワーク上で動作するデバイスから収集されるシステムリソース情報によって、サービス役割を決定するメカニズムからなる」とあるが、
　
（１−５−１）「選出アルゴリズム」なるものは前記されていない
　
（１−５−２）「選出アルゴリズム」とは、何の中から何を選出するアルゴリズムなのか（要求され得る「標準サービス」の中からに自己が提供可能な「標準サービス」を選択するのか？自己が提供可能な「標準サービス」の中から自己がマスターになる「標準サービス」を選ぶのか？他の複数のデバイスの中から標準サービスのマスターになるデバイスを選ぶのか？「マスター」と「エージェント」の２つから何れかひとつを選ぶのか？）が明確でない。
　
（１−５−３）請求項２の「サービス役割」の「決定」と請求項１の「デバイスが所定のネットワークに連結されると、前記デバイスから収集されたシステムリソース情報を利用して・・・サービス役割を決定する」との関係（請求項１の「サービス役割」の「決定」と請求項２の「サービス役割」の「決定」とは同義で、請求項２では該「決定」を「メカニズム」なるものが行うことを限定しているのか？請求項１の「連結される」「デバイスから収集されたシステムリソース情報を利用」した「サービス役割」の「決定」とは別に「ネットワーク上で動作するデバイスから収集されるシステムリソース情報によって、サービス役割を決定するメカニズム」を設けるのか？請求項１の「サービス役割」の「決定」においては、「連結される」「デバイスから収集されたシステムリソース情報」だけでなく「ネットワーク上で動作する」他の「デバイスから収集されるシステムリソース情報」も利用する旨を限定しているのか？）が明確でなく、冗長でもある。
　
（１−５−４）「前記ネットワーク上のデバイス」とはなにか（請求項１の「連結」された「デバイス」のことなのか？請求項１の「連結」された「デバイス」以外の「デバイス」でかつ「ネットワーク」上にある「デバイス」のことなのか？発明の詳細な説明記載の何（デバイス２０？　１０？　「サービス役割設定部１１０」？）に対応するのか？）が明確でない。
　
　
（１−６）請求項３に「前記サービス役割設定部は、前記決定される自分のサービス役割を前記ネットワーク上のデバイスに知らせる」とあるが、
　
（１−６−１）「自分」とは何か（請求項１の「装置」のことなのか？請求項１の「連結」された「デバイス」のことなのか？「サービスエージェントモジュール」のことなのか？「サービス役割設定部１１０」のことなのか？発明の詳細な説明記載の何に対応するのか？）が明確でない。
　
（１−６−２）「前記ネットワーク上のデバイス」とはなにか（請求項１の「連結」された「デバイス」のことなのか？請求項１の「連結」された「デバイス」以外の「デバイス」でかつ「ネットワーク」上にある「デバイス」のことなのか？発明の詳細な説明記載の何に対応するのか？）が明確でない。
　
　
（１−７）請求項４に「前記サービス役割設定部は、前記サービス役割によって所定の標準サービスの提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定する」とあるが、
　
（１−７−１）「前記サービス役割によって」は、何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　
（１−７−２）「前記サービス役割」と「要請」や「設定」等の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−７−３）「所定の標準サービス提供のために」は何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　
（１−７−４）「指定されるデバイス」とは何か（請求項１の「連結」された「デバイス」のことか？請求項１の「処理要請」される「デバイス」のことか？これらとは別の（例えば、役割がマスターである）「デバイス」なのか？）が明確でない。
　
（１−７−５）「前記デバイス」とは何か（請求項１の「連結」された「デバイス」のことか？請求項１の「処理要請」される「デバイス」のことか？請求項４の「指定されるデバイス」のことか？）が明確でない。
　
（１−７−６）「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？）が明確でない。
　
（１−７−７）「指定されるデバイスにプロキシ情報を要請して」とは如何なる意味なのか（「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」するのか？「指定されるデバイス」に「プロキシ情報」を「指定されるデバイス」内に設定するように「要請」するのか？）が明確でない。
　
（１−７−８）「前記デバイスのプロキシ情報を設定する。」とは如何なる意味なのか（「前記デバイス」に関連する「プロキシ情報」をどこかに設定するのか？「前記デバイス」内の「プロキシ情報」格納部に所定値を設定するのか？）が明確でない。
　
（１−７−９）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３８】では「決定されるサービス役割によって・・・知らせ」と表現している。また段落【００５７】では「マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」と表現している。）
　
　
（１−８）請求項５に「前記サービス要請処理部は、前記サービス役割によって要求される標準サービスを指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送するように前記標準サービス要請情報を変換するデータ変換部」とあるが、
　
（１−８−１）該「変換部」と請求項１記載の「変換部」との関連（同じものを意味するのか、別個のものなのか？が明確でない。前者であれば冗長である。
　
（１−８−２）「サービス役割」と「要求」や「伝送」「変換」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−８−３）「標準サービスを」は何を修飾するのか（「指定された」を修飾するのか？　「伝送する」を修飾するのか？）明確でない。後者の場合、「標準サービスを」「伝送する」とは何を伝送することを意味するのか（「標準サービス」と言うプログラム等を伝送するのか？「標準サービス」を示す情報を伝送するのか？「標準サービス要請情報」を伝送することと同義なのか？）が明確でない。
　
（１−８−４）「指定された」は何を修飾するのか（「デバイス」を修飾するのか？「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　
（１−８−５）「前記サービス要請処理部は・・・指定されたデバイスのＯＳＧＩサービスプラットフォームに伝送」とは如何なる意味なのか（「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」から「指定」され「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」を「指定」して「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？）が明確でない。
　
（１−８−６）「指定されたデバイス」の「デバイス」は、上記（１−２）で摘記した「連結され」た「デバイス」や「収集された」「デバイス」とは如何なる関係にあるのかが明確でない。（無関係でよいのか？）上記（１−２）で摘記した「決定」された「サービス役割」とは如何なる関係なのかも明確でない。（無関係でよいのか？）
　
（１−８−７）「前記標準サービス要請情報」とあるが「標準サービス要請情報」は前記されていない、また、これは、何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（１−８−８）段落【００４１】【００６１】の実施例の記載と整合しない。（段落【００４１】【００６１】には「ＯＳＧＩサービスプラットフォームへ伝送するように」「変換する」旨の記載は無い。）
　
　
（１−９）請求項５に「前記データ変換部により変換された標準サービス要請情報を前記指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送する標準サービス連結部とを含む」とあるが、
　
（１−９−１）「前記データ変換部」とはどの「データ変換部」なのか（請求項１の「データ変換部」なのか、請求項５の「データ変換部」なのか？）が明確でない。
　
（１−９−２）「前記指定」はどの「指定」のことなのか（請求項１の「外部指定」のことなのか？　請求項５の「標準サービスを指定された」の「指定」のことなのか？）が明確でない。
　
（１−９−３）「標準サービス連結部」が「標準サービス要請情報」を「ＯＳＧＩサービスプラットフォームへ伝送する」ことは、発明の詳細な説明開示の実施例のどのことに対応するのかが明確でない。（段落【００４２】【００６２】には「ＯＳＧＩサービスプラットフォームへ伝送する」旨の記載は無い。）
　
　
（１−１０）請求項６に「前記データ変換部は、前記サービス役割によってサービス要請情報を分析して該当サービス支援のために要求される標準サービスを動作させるように処理する」とあるが、
　
（１−１０−１）「前記サービス役割によって」は何を修飾するのか（「分析して」を修飾するのか？「要求される」を修飾するのか？「処理する」を修飾するのか？）が明確でない。
　
（１−１０−２）「前記サービス役割」と「分析」や「要求」「処理」との関係（「サービス役割」が、「分析」「要求」「処理」に如何に関与するのか？「サービス役割」と言う物が「分析」「要求」「処理」を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが「分析」「要求」「処理」の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
　
（１−１０−３）「該当サービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「動作させる」を修飾するのか？「処理する」を修飾するのか？」）が明確でない。
　
（１−１０−４）「標準サービスを動作させるように処理する」とは如何なる意味か（「標準サービスを動作させる」ことを目的として何らかの「処理」をすると言う意味か？「標準サービスを動作させる」ことができるようなサービス要請情報にデータ変換「処理」をすると言う意味か？）が明確でない。
　
　
（１−１１）請求項７に「前記標準サービス連結部は、前記標準サービス要請情報を伝送するために前記デバイスのプロキシ情報を利用する」とあるが、
　
（１−１１−１）「前記標準サービス要請情報」とはどの「標準サービス要請情報」なのか（変換前の「標準サービス要請情報」なのか？変換後の「標準サービス要請情報」なのか？）が明確でない。
　
（１−１１−２）「前記デバイス」とは、どの「デバイス」のことなのか（「連結」された「デバイス」のことか？「収集された」「デバイス」のことか？「指定されたデバイス」の「デバイス」のことか？）が明確でない。
　
（１−１１−３）「伝送する」とあるが、何処へ伝送するのかが明確でない。
　
（１−１１−４）「プロキシを利用して」とは如何なる意味か（「プロキシ」と言う機能を利用するのか？「プロキシ」と言う装置を利用するのか？「利用」とは「プロキシ」を経由すると言う意味なのか？「プロキシ」が伝送処理を行うと言う意味なのか？）が明確でない。
　
　
（１−１２）請求項８に「サービス役割設定部が、所定のネットワークに連結されたデバイスについて・・・サービス要請処理部が・・・ネットワーク上でのサービス共有のための方法。」とあるが、該「デバイス」と「サービス役割設定部」「サービス要請処理部」の関係（「デバイス」内に「サービス役割設定部」「サービス要請処理部」が有るのか？「デバイス」とは別個の装置内に「サービス役割設定部」「サービス要請処理部」が有るのか？　等々）が明確でない。
（また、これらの点は発明の詳細な説明及び図面を参酌しても明確に把握し得るものではない（下記（２−２２）（２−２３）等参照））
　
　
（１−１３）請求項８に「サービス役割設定部が、所定のネットワークに連結されたデバイスについて、前記デバイスから収集されたシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する段階」とあるが、
　
（１−１３−１）「前記デバイスから収集されたシステムリソース情報」とあるが、「ネットワークに連結された」「デバイス」と「システムリソース情報」の「収集」元である「デバイス」とが共通のものである旨の記載は、本願の発明の詳細な説明には記載されていない。（なお、本願の発明の詳細な説明中の該発明特定事項に関連する記載としては、段落【００３５】【００３６】【００４９】【００５０】等の記載があるが、該記載からも「連結される」「デバイス」と「システムリソース情報」の収集元の「デバイス」が共通のものであるか否かは定かでない。）
　
（１−１３−２）「デバイスから収集されたシステムリソース情報」とは何か（「デバイス」内の「リソース」を示す「情報」なのか？「デバイス」が接続されるネットワークなどを含む「システム」全体の「リソース」を示す「情報」なのか？）が明確でない。
　
（１−１３−３）「リソース」と「標準サービス」との関係（何らかの関連があるのか？無関係でよいのか？）が明確でない。
　
（１−１３−４）何の「サービス役割」を決定するのか（「デバイス」の「サービス役割」を決定するのか？「デバイス」以外の何らかの装置の「サービス役割」を決定するのか？「サービス役割設定部」の「サービス役割」を決定するのか？「サービス要請処理部」の「サービス役割」を決定するのか？）が明確でない。
　
（１−１３−５）「サービス役割」とは何を意味するのか（どのデバイスにどの標準サービスが実装されているかを示す情報なのか？特定の標準サービスに対してマスターとして動作するかエージェントとして動作するかを示す情報なのか？）が明確でない。
　
（１−１３−６）「決定する」とは、発明の詳細な説明記載の何れの事項に対応するのか（段落【００３５】【００３６】【００４９】【００５０】記載の「決定」に対応するのか？段落【００３７】【００５２】【００５３】の「設定」に対応するのか？段落【００５１】の「判別」に対応するのか？）が明確でない。（用語のみからみれば「決定」に対応すると解するのが最も妥当ではあるが、請求項８の「前記決定されるデバイスのサービス役割によって、サービス要請情報を変換する」との記載を考慮すると「設定」や「判別」をも含むとの解釈も成り立つ。）
　
　
（１−１４）請求項８に「サービス要請処理部が、前記サービス役割の設定段階によって決定されるデバイスのサービス役割によって、所定のサービス支援のために要求される標準サービスを外部指定されたデバイスに設けられるＯＳＧＩサービスプラットフォームであってサービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service Framework）、多様なサービスを実行するための多数の標準サービス（Core Services）、これらの標準サービスを利用して開発されたアプリケーションサービス（Appls Service）とから構成されたＯＳＧＩサービスプラットフォームへサービスを要請する段階とを含み、」とあるが、
　
（１−１４−１）「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（１−１４−２）「サービス役割」と「要求」や「外部指定」「処理要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−１４−３）「標準サービスを外部指定」の「標準サービスを」は何を修飾するのか（「外部指定され」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
（１−１４−４）「外部指定された」とは如何なる意味なのか（「外部」から「指定」されることの意味なのか？「外部」に対して「指定」することなのか？）が明確でない。
　
（１−１４−５）「外部指定された」は何を修飾するのか（「デバイス」を修飾するのか？　「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　
（１−１４−６）「外部指定」の「外部」とは何の外部を意味するのか（アプリケーションなどの「標準サービス」の外部の事なのか？「サービス役割設定部」等の「サービス要請処理部」の外部のことなのか？他の「デバイス」の事なのか？））が明確でない。
　
（１−１４−７）「所定のサービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（１−１４−８）「サービス支援」とは何か（「サービスを実行する」と同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「指定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　
（１−１４−９）「サービス実行環境提供のためのサービス伝達と管理を実行する」とは何処から何処へ如何なる情報を伝達することを意味するのか（アプリケーションからのサービス要請の情報を標準サービスに引き渡すのか？他のデバイスからのサービス要請を自デバイスの標準サービスやアプリケーションに引き渡すのか？）が明確でない。
　
（１−１４−１０）「多様なサービスを実行するための多数の標準サービス」と、上記（１−１３）で摘記した「所定の標準サービス共有」の「標準サービス」との関係（同じものなのか異なるものなのか？上記（１−１３）で摘記した「決定」された「サービス役割」との関係（無関係なのか否か？）が明確でない。
　
（１−１４−１１）「これらの標準サービスを利用して開発されたアプリケーションサービス」とあるが、その意味が不明。（文言通りの解釈をすると、「標準サービス」とは開発ツールで、該開発ツールを利用して「アプリケーションサービス」を開発することを限定していると解されるが、これは発明の詳細な説明記載の課題等と全く相入れない。「これらの標準サービスを利用」するように」開発されたアプリケーションサービス」の誤訳か？）
　
（１−１４−１２）「ＯＳＧＩサービスプラットフォーム」は、上記（１−１３）で摘記した「連結され」た「デバイス」や「収集された」「デバイス」とは如何なる関係にあるのか（無関係でよいのか？）、上記（１−１３）で摘記した「決定」された「サービス役割」とは如何なる関係なのか（無関係でよいのか？）が明確でない。
　
（１−１４−１３）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（（段落【００４２】や段落【００６２】には「ＯＳＧＩサービスプラットフォームへサービスを要請する」旨の記載は無い。）
　
　
（１−１５）請求項８に「前記ＯＳＧＩサービスプラットフォームへサービスを要求する段階は、前記決定されるデバイスのサービス役割によって、サービス要請情報を変換する段階を含む」とあるが、
　
（１−１５−１）「サービス役割」と「変換」との関係（「サービス役割」が、「変換」に如何に関与するのか？「サービス役割」と言う物が該「変換」処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該「変換」処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−１５−２）「ＯＳＧＩサービスプラットフォームへサービスを要求する段階」は前記されていない。（「前記ＯＳＧＩサービスプラットフォームへサービスを要請する段階」の誤記？）
　
（１−１５−３）「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（１−１５−４）ここでの「変換」は発明の詳細な説明中のどの事項（ステップＳ１４？　ステップＳ１７？　ステップＳ２１？　ステップＳ２４？）と対応するのかが明確でない。（「ステップＳ１４」のみに対応すると仮定すると、ステップＳ１７が特許請求の範囲に反映されていないことになるが、これでは所期の課題を達成できない。「ステップＳ１７」にも対応すると仮定すると、上記（１−１４）で摘記した「ＯＳＧＩサービスプラットフォーム」に「処理要請」する旨の事項と矛盾する。）
　
　
（１−１６）請求項９に「前記決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを動作させ得られる結果値を前記標準サービスを要請したデバイスへ伝送する段階」とあるが、
　
（１−１６−１）「サービス役割によって」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
（１−１６−２）「サービス役割」と「要求」や「動作」「伝送」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−１６−３）「所定のサービス支援のために」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
（１−１６−４）「所定のサービス支援」と請求項８の「所定のサービス支援」との関係（同じものなのか？異なるものなのか？）が明確でない。
　
（１−１６−５）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００４３】【００６５】では「デバイス」へ「伝送」するとの表現はしていない。）
　
　
（１−１７）請求項１０に「前記サービス役割を決定する段階は、前記ネットワーク上で連結されて動作するデバイスからシステムリソース情報を収集する段階と」、「前記収集されたシステムリソース情報を利用してサービス役割を決定する段階とを含む」とあるが、
　
（１−１７−１）ここでの処理と請求項８の「前記デバイスから収集されたシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する」こととの関係（同じことを繰り返し表現しているのか？別の段階なのか？）が明確でなく、冗長でもある。
　
（１−１７−２）「前記ネットワーク上で連結されて動作するデバイス」とはどのデバイスなのか（「所定のネットワークに連結されたデバイス」のことなのか？「前記ネットワーク」に「連結されて動作」している「デバイス」のことなのか？）が明確でない。
　
（１−１７−３）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３５】【００３６】【００４９】【００５０】では「ネットワーク上で連結されて動作するデバイス」との表現はしていない。）
　
　
（１−１８）請求項１１に「前記決定されるサービス役割を設定し、前記ネットワーク上のデバイスに知らせる段階をさらに含む」とあるが、
　
（１−１８−１）「前記決定されるサービス役割」とは何を意味するのか（前記「サービス役割を決定する段階」で「決定」済みの「サービス役割」のことなのか？これから「サービス役割を決定する段階」で「決定」が予定される「サービス役割」のことなのか？）が明確でない。
　
（１−１８−２）「サービス役割を設定」とは如何なる処理なのか（「サービス役割」を「決定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？レジスタ等に記憶することを意味するのか？どこ（自デバイス内？他のデバイス内？）に設定するのか？）が明確でない。
　
（１−１８−３）何を「知らせる」のか（「サービス役割」を知らせるのか「サービス役割を設定」した旨を知らせるのか？）が明確でない。
　
（１−１８−４）「設定し」「知らせる」とは如何なる意味なのか（「設定」をした後に「知らせる」のか？「設定」をすることで「知らせる」ことがなされると言う意味なのか？）が明確でない。
　
（１−１８−５）「前記ネットワーク上のデバイス」とはどのデバイスなのか（「所定のネットワークに連結されたデバイス」のことなのか？「システムリソース情報」の「収集」元の「デバイス」のことなのか？「前記ネットワーク」に接続されている他の全ての「デバイス」のことなのか？）が明確でない。
　
（１−１８−６）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３８】では「知らせ」た後「設定」している。）
　
　
（１−１９）請求項１２に「前記決定されるサービス役割によって所定の標準サービス提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定する段階をさらに含む」とあるが、
　
（１−１９−１）「前記決定されるサービス役割によって」は、何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　
（１−１９−２）「サービス役割」と「要請」や「設定」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（１−１９−３）この「段階」において「前記決定されるサービス役割」は「要請して」や「設定する」に如何に関与するのか（「サービス役割」によって「設定」内容等が変わるのか？「サービス役割」によって「プロキシ情報」が変わるのか？）が明確でない。
　
（１−１９−４）「所定の標準サービス提供のために」は何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　
（１−１９−５）「指定されるデバイス」とはどのデバイスなのか（請求項８で「連結」された「デバイス」のことなのか？「収集」された「デバイス」なのか？要請された「ＯＳＧＩサービスプラットフォーム」が設けられた「デバイス」なのか？これらとは別の（例えば、役割がマスターである）「デバイス」なのか？）が明確でない。
　
（１−１９−６）「前記デバイス」とはどのデバイスなのか（請求項８で「連結」された「デバイス」のことなのか？「収集」された「デバイス」なのか？要請された「ＯＳＧＩサービスプラットフォーム」が設けられた「デバイス」なのか？「指定されるデバイス」なのか？）が明確でない。
　
（１−１９−７）「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？）が明確でない。
　
（１−１９−８）「指定されるデバイスにプロキシ情報を要請して」とは如何なる意味なのか（「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」するのか？「指定されるデバイス」に「プロキシ情報」を「指定されるデバイス」内に設定するように「要請」するのか？）が明確でない。
　
（１−１９−９）「前記デバイスのプロキシ情報を設定する。」とは如何なる意味なのか（「前記デバイス」に関連する「プロキシ情報」をどこかに設定するのか？「前記デバイス」内の「プロキシ情報」格納部に所定値を設定するのか？）が明確でない。
　
（１−１９−１０）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３８】では「決定されるサービス役割によって・・・知らせ」と表現している。また段落【００５７】では「マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」と表現している。）
　
　
（１−２０）請求項１３に「前記サービス役割は、所定の選出アルゴリズムを通じて前記収集されるシステムリソース情報によって決定される」とあるが、
　
（１−２０−１）請求項８の「前記デバイスから収集されたシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する」こととの関係（なにがどう異なるのか？（表現上は「選出アルゴリズム」を通じるか否かの相違があるが、請求項８でも何らかの「選出アルゴリズム」に従って決定しているのではないのか？））が明確でなく、冗長でもある。
　
（１−２０−２）「選出アルゴリズム」とは、何から何を選出するアルゴリズムなのか（要求され得る「標準サービス」の中から自己が提供可能な「標準サービス」を選択するのか？自己が提供可能な「標準サービス」の中から自己がマスターになる「標準サービス」を選ぶのか？他の複数のデバイスの中から標準サービスのマスターになるデバイスを選ぶのか？「マスター」と「エージェント」の２つから何れか１つを選ぶのか？）が明確でない。
　
（１−２０−３）「所定の選出アルゴリズムを通じて」「決定される」とは「選出アルゴリズム」が「決定」に如何に関与するのか（単に「選出アルゴリズム」に従って「決定」されると言う意味なのか？）が明確でない。
　
（１−２０−４）「通じて」とは如何なる意味なのか（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（１−２０−５）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３６】では「収集されたシステムリソース情報を利用して、サービス役割を決定する。」と表現している。段落【００５０】では「応答メッセージを通じて収集される各デバイスのシステムリソース情報を利用して、サービス役割を決定する」と表現している。）
　
　
（１−２１）請求項１４に「前記標準サービスを外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ要請する段階は、前記標準サービスが要請されると、前記標準サービス要請情報を前記標準サービス提供のために指定されるデバイスへ伝送する段階と、
　前記受信される標準サービス要請情報によって前記デバイスで該当する標準サービスを動作させる段階と、
　前記標準サービスを動作させ得られる結果値を前記標準サービスを要請したデバイスへ提供する段階とを含む」とあるが、
　
（１−２１−１）「前記標準サービスを外部指定された」における「前記標準サービスを」は、何を修飾するのか（「外部指定された」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　
（１−２１−２）「前記標準サービス提供のために指定されるデバイス」「前記デバイス」「前記標準サービスを要請したデバイス」とはどのデバイスか（「外部指定」されるデバイスのことか？これ以外のデバイス（「外部指定」をするデバイス？「サービス要請処理部」を有するデバイス？）のことか？）が明確でない。
　
（１−２１−３）「前記標準サービス要請情報」とあるが「標準サービス要請情報」は前記されていない、またこれは、何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（１−２１−４）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００４１】【００６１】〜【００６５】では「マスターエージェントモジュールへサービス要請情報を伝送する」、「標準サービス処理結果値をエージェントモジュールへ伝送する」等と表現している。）
　
　
（１−２２）請求項１５に「前記標準サービス要請情報は、前記標準サービス提供のために指定されるデバイスのプロキシ情報を利用して伝送される」とあるが、
　
（１−２２−１）「前記標準サービス提供のために指定されるデバイスのプロキシ情報」とは、何処の如何なる情報を意味するのかが明確でない。
　
（１−２２−２）発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００４２】では「サービス要請情報をプロキシ（Core Service Proxy）を利用してマスターへ伝送する」と表現している。段落【００６２】段落では「プロキシ」に関する記載はない。）
　
　
　
（２）本願の発明の詳細な説明には、下記（２−１）〜（２−４４）に例示するように、意味の不明確な記載や具体的構成の不明な記載、特許請求の範囲の記載と整合しない記載が多数あり、ここに記載の実施例等の構成や機能等を正確に把握することが不可能であるとともに、請求項１〜１５に係る発明の課題や作用効果等の技術上の意義も正確に把握することが不可能である。
　したがって、本願の発明の詳細な説明は、当業者が本願請求項１〜１５に係る発明を実施することができる程度に明確かつ十分に記載されていないものである。（第３６条第４項第１号（実施可能要件）違反）
　また、本願の発明の詳細な説明は、請求項１〜１５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものでもある（第３６条第４項第１号（委任省令要件）違反）
　
（２−１）段落【０００１】に「・・・設置せずサービス提供が可能にする」とあるが、その意味が明確でない。
　
（２−２）段落【０００２】に「デジタルホーム構築」とあるが、その意味が明確でない。
　
（２−３）段落【０００３】に「よく具備さえた」とあるが、その意味が明確でない。
　
（２−４）段落【０００６】に「従来ＯＳＧＩサービスプラットフォーム」とあるが、その意味が明確でない。
　
（２−５）段落【０００９】に「自体フレームワーク」とあるが、その意味が明確でない。
　
（２−６）段落【０００９】に「自体実行環境内」とあるが、その意味が明確でない。
　
（２−７）段落【００１５】に「さらに、現在のデバイスで要請したサービスを駆動するために必要な他のサービスが、他のデバイスで実行中であるＯＳＧＩサービスプラットフォームに登録されて管理中である場合にも、他のデバイスに該当サービスを要請するか自分のＯＳＧＩサービスプラットフォームに登録できる方法がない問題点があった。」とあるが、「他のデバイスに該当サービスを要請するか自分のＯＳＧＩサービスプラットフォームに登録できる方法がない」の意味（何を「登録」するのか？「要請」することを「登録」すると言う意味か？）が明確でない。
　
（２−８）段落【００１７】に「本発明は、上述したような従来技術の問題点を解決するためになされたもので、本発明では、所定のネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間でサービスが共有できるようにサービス共有のための役割を決定することを目的とする。」とあるが、「サービス」を「デバイスのＯＳＧＩサービスプラットフォーム」と何との「間」で共有するするのか（複数の「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有すると言う意味なのか？「エージェントモジュール」と「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有すると言う意味なのか？）が明確でない。
　
（２−９）段落【００１８】に「また、本発明の他の目的は、決定される役割によって多数の標準サービスを有するＯＳＧＩサービスプラットフォームを通じて使用者から受信されるサービス要請を処理することにある。」とあるが、
　
（２−９−１）「決定される役割によって・・・ＯＳＧＩサービスプラットフォームを通じて・・・処理する」の意味が明確でない。（文言通りの解釈をすると、「決定される役割」と言う物が「ＯＳＧＩサービスプラットフォームを」経由して「処理する」と解されるが、これでは技術的に意味不明である。）
　
（２−９−２）「前記サービス役割」と「処理」との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）も明確でない。
　
　
（２−１０）段落【００１９】に「前記目的を達成するために、本発明では、ＯＳＧＩサービスプラットフォームに具備されるサービスエージェントモジュールを通じてネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間で所定の標準サービス共有のためのサービス役割を決定してＯＳＧＩサービスプラットフォームに設定することを特徴とする。」とあるが、
　
（２−１０−１）「・・・との間で・・・役割を決定して」の意味が明確でない。（技術的意味不明である。）
　
（２−１０−２）特許請求の範囲の記載とも、上記段落【００１８】の記載とも、段落【００３７】の実施例の記載とも、段落【００５０】の実施例の記載とも、整合しない。（「サービス役割」を「決定」する主体、「設定」先が異なる。）
　
　
（２−１１）段落【００２０】に「また、本発明は、決定された役割によって所定のサービス支援のために要求される標準サービスを指定されたデバイスのＯＳＧＩサービスプラットフォームを通じて提供することを特徴とする。」とあるが、
　
（２−１１−１）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−１１−２）「決定された役割」とは何か（「決定された」「サービス役割」のことか？「サービス役割」とは別の役割なのか？）が明確でない。
　
（２−１１−３）「決定された役割によって」が何を修飾するのか（「要求される」を修飾するのか？「指定された」を修飾するのか？「提供する」を修飾するのか？）が明確でない。
　
（２−１１−４）「決定された役割」と「要求」や「指定」「提供」の処理との関係（「決定された役割」が、該処理に如何に関与するのか？「決定された役割」と言う物が該処理を実行する主体となると解してよいのか？「決定された役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「決定された役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
　
（２−１１−５）「サービス支援のために」が何を修飾するのか（「要求される」を修飾するのか？「提供する」を修飾するのか？）が明確でない。
　
（２−１１−６）「標準サービスを」が何を修飾するのか（「指定された」を修飾するのか？「通じて」を修飾するのか？「提供する」を修飾するのか？）明確でない。
　
　
（２−１２）段落【００２１】に「サービス役割は、各デバイスから収集されるシステムリソース（resource）情報を通じて決定されることで、本発明の一実施例では、所定の選出アルゴリズムを利用して収集されるシステムリソース情報によって所定の標準サービスに対してマスター又はエージェントで決定するようにする。」とあるが、
　
（２−１２−１）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−１２−２）「所定の選出アルゴリズムを利用して」が何を修飾するのか（「収集される」？「決定する」？）明確でない。
　
（２−１２−３）「選出アルゴリズム」とは何の中から何を選択するアルゴリズムなのかが明確でない。
　
（２−１２−４）「マスター又はエージェントで決定する」の意味（「マスター」又は「エージェント」が主体となって「決定」すると解して良いのか？「マスター」又は「エージェント」として「決定」すると言う意味か？）が明確でない。
　
（２−１３）段落【００２２】に「マスターは、所定の標準サービスに対して高いシステムリソース情報を有するデバイスとして、該当標準サービスを提供するように定義され、マスターのＯＳＧＩサービスプラットフォームを通じて提供される指定された標準サービスを利用して所定のサービス支援のために要求される標準サービスを提供するデバイスで定義される。」とあるが、
　
（２−１３−１）「高い」の意味（何が「高い」ことを意味するのか？）が明確でない。
　
（２−１３−２）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−１３−３）「・・・デバイスで定義される。」の意味（「・・・デバイス」が動作して何かの「定義」をするのか？「・・・デバイス」として「定義」がされる旨の意味か？）が明確でない。
　
　
（２−１４）段落【００２３】に「このように決定されるサービス役割よって、サービスエージェントモジュールはマスターエージェントモジュール又はエージェントモジュールで設定される。」とあるが、
　
（２−１４−１）「サービス役割よって」の意味が明確でない。
　
（２−１４−２）「サービスエージェントモジュールはマスターエージェントモジュール又はエージェントモジュールで設定される。」の意味（「マスターエージェントモジュール」又は「エージェントモジュール」が主体となって「サービスエージェントモジュール」を「設定」すると解して良いのか？「サービスエージェントモジュール」が「マスターエージェントモジュール」又は「エージェントモジュール」として「設定」されると言う意味か？）が明確でない。
　
　
（２−１５）段落【００２４】に「本発明一実施例によるネットワーク上でのサービス共有のための装置は、所定のネットワークに連結されると、 所定の標準サービス共有のためのサービス役割を決定するサービス役割設定部と、前記サービス役割設定部により決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ処理要請するサービス要請処理部をと含むことを特徴とする。」とあるが、
　
（２−１５−１）「本発明一実施例」の意味が明確でない。
　
（２−１５−２）「標準サービス共有のための」は何を修飾するのか（「サービス役割」を修飾するのか？「サービス役割設定部」を修飾するのか？）が明確でない。
　
（２−１５−３）何が「所定のネットワークに連結される」のか（「本発明一実施例によるネットワーク上でのサービス共有のための装置」が「所定のネットワークに連結される」のか？該装置とは別のものが「所定のネットワークに連結される」のか？）が明確でない。
　
（２−１５−４）「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（２−１５−５）「サービス役割」と「要求」や「処理要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（２−１５−６）特許請求の範囲の記載と異なる。（特許請求の範囲では「ネットワーク」に「連結」されるのは「デバイス」と明記している。）
　
　
（２−１６）段落【００２５】に「また、本発明の一実施例によるサービス要請処理部は、サービス役割によって要求される標準サービスを指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送するように前記標準サービス要請情報を変換するデータ変換部と、」とあるが、
　
（２−１６−１）「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「伝送する」を修飾するのか？「変換する」を修飾するのか？）が明確でない。
　
（２−１６−２）「サービス役割」と「要求」や「伝送」「変換」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（２−１６−３）「標準サービスを」は何を修飾するのか（「指定された」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
（２−１６−４）何を「伝送」するのか（「標準サービス」を「伝送」するのか？「標準サービス要請情報」を「伝送」するのか？）が明確でない。
　
（２−１６−５）「指定された」は何を修飾するのか（「デバイス」を修飾するのか？「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　
（２−１６−６）「前記サービス要請処理部は・・・指定されたデバイスのＯＳＧＩサービスプラットフォームに伝送」とは如何なる意味なのか（「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」から「指定」され「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」を「指定」して「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？）が明確でない。
　
（２−１６−７）「指定されたデバイス」の「デバイス」とはどのデバイスなのか（「装置」とは如何なる関係にあるのか？）が明確でない。（無関係でよいのか？）上記「決定」された「サービス役割」とは如何なる関係なのか（無関係でよいのか？）も明確でない。
　
（２−１６−８）「前記標準サービス要請情報」とあるが「標準サービス要請情報」は前記されていない、またこれは、何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（２−１６−９）段落【００４１】【００６１】の実施例の記載と整合しない。（段落【００４１】【００６１】には「ＯＳＧＩサービスプラットフォームへ伝送するように」「変換する」旨の記載は無い。）
　
　
（２−１７）段落【００２５】に「前記データ変換部により変換された標準サービス要請情報を前記指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送する標準サービス連結部とを含むことを特徴とする。」とあるが、段落【００４２】【００６２】の実施例の記載と整合しない。（段落【００４２】【００６２】には「ＯＳＧＩサービスプラットフォームへ伝送する」旨の記載は無い。）
　
　
（２−１８）段落【００２６】に「本発明の一実施例によるネットワーク上のサービス共有のための方法は、所定のネットワークに連結され、所定の標準サービス共有のためのサービス役割を決定する段階と、決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ要請する段階とを含むことを特徴とする。」とあるが、
　
（２−１８−１）何が「所定のネットワークに連結され」るのかが不明である。（「方法」は連結しえない。）
　
（２−１８−２）何の「所定の標準サービス共有のためのサービス役割を決定する」のかが不明である。
　
（２−１８−３）「決定されるサービス役割」の意味（前記「決定する段階」の前の段階の「サービス役割」のことなのか？　「決定する段階」で「決定」された「サービス役割」のことなのか？）が明確でない。
　
（２−１８−４）「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　
（２−１８−５）「サービス役割」と「要求」や「外部指定」「要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（２−１８−６）「標準サービスを外部指定」の「標準サービスを」は何を修飾するのか（「外部指定され」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　
（２−１８−７）「外部指定された」とは如何なる意味なのか（「外部」から「指定」されることの意味なのか？「外部」に対して「指定」することなのか？）が明確でない。
　
（２−１８−８）「外部指定された」は何を修飾するのか（「デバイス」を修飾するのか？　「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　
（２−１８−９）「外部指定」の「外部」とは何の外部を意味するのか（アプリケーションなどの「標準サービス」の外部の事なのか？「サービス役割設定部」等の「サービス要請処理部」の外部のことなのか？他の「デバイス」の事なのか？）が明確でない。
　
（２−１８−１０）「所定のサービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（２−１８−１１）「サービス支援」とは何か（「サービスを実行する」と同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「指定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　
（２−１８−１２）段落【００４２】や段落【００６２】の実施例の記載と整合しない。（段落【００４２】や段落【００６２】には「ＯＳＧＩサービスプラットフォームへサービスを要請する」旨の記載は無い。）
　
　
（２−１９）段落【００２７】に「また、本発明の一実施例によるネットワーク上でのサービス共有のための方法は、決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを動作させて得られる結果値を前記標準サービスを要請したデバイスへ伝送する段階をさらに含むことを特徴とする。」とあるが、
　
（２−１９−１）「サービス役割によって」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
（２−１９−２）「前記決定されるサービス役割」と「要求」や「動作」「伝送」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（２−１９−３）「所定のサービス支援のために」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
（２−１９−４）段落【００４３】【００６５】の実施例の記載と整合しない。（段落【００４３】【００６５】では「デバイス」へ「伝送」するとの表現はしていない。）
　
　
（２−２０）段落【００２８】に「本発明によると、 決定されるサービス役割によって、所定のネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間でサービスが共有できるようになる。」とあるが、
　
（２−２０−１）「決定されるサービス役割」と「共有」との関係（「決定されるサービス役割」が、「共有」に如何に関与するのか？「決定されるサービス役割」と言う物が主体となって「共有」を行うと解してよいのか？「サービス役割」と言うパラメータが「共有」に影響すると言う意味か？その場合、「前決定されるサービス役割」と該結果の対応関係は如何になっているのか？それとも、「前決定されるサービス役割」と言うパラメータを導入することによって「共有」が可能になると言う意味なのか？）が明確でない。
　
（２−２０−２）「デバイスのＯＳＧＩサービスプラットフォーム」と何との「間」で「サービス」を共有するするのか（複数の「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有すると言う意味なのか？「エージェントモジュール」と「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有すると言う意味なのか？）が明確でない。
　
　
（２−２１）段落【００３１】【００３２】に記載の事項と特許請求の範囲の記載が整合しない。（特許請求の範囲では「OSGiプラットフォーム」、「ＯＳＧＩサービスプラットフォーム」等を用いるものに限定されている。）
　
　
（２−２２）段落【００３１】〜【００４５】に、【図１】と【図２】を参照しての「本発明の一実施例」の説明がなされているが、【図２】に示される「装置」あるいは「サービスエージェントモジュール１００」が、【図１】に示される「従来ＯＳＧＩサービスプラットフォームの動作構造」中の何処にどう設けられるのか（デバイス２０の中に設けられるのか？１０の中にも設けられるのか？全てのデバイス内なのか？デバイス２０や１０とは別個のものとしてネットワークに接続されるのか？）の説明が、本願発明の詳細説明にも図面にも無い。
　従って、本願請求項１〜１５に係る発明の実施に際し、該「サービスエージェントモジュール１００」を何処にどう設ければよいのかを、本願の発明の詳細な説明及び図面の記載から理解しこれを再現することは、当業者と言えども不可能である。
　
　
（２−２３）段落【００３５】【００３６】に「サービス役割設定部１１０は、ネットワーク上で動作するデバイスから収集されるシステムリソース情報を利用して、所定の標準サービス共有のためのサービス役割を決定する。」「即ち、サービス役割設定部１１０では、デバイスがネットワーク上に連結されると、発見メッセージ(Discovery　Message)をブロードキャスティングして応答メッセージで受信されるデバイスのシステムリソース情報を収集し、収集されたシステムリソース情報を利用して、サービス役割を決定する。」との記載があるが、
　
（２−２３−１）「デバイス」と「サービス役割設定部１１０」の関係（「ネットワーク上で動作するデバイス」や「連結される」「デバイス」とは別個に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」内に「サービス役割設定部１１０」があるのか？「連結される」「デバイス」内に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」及び「連結される」「デバイス」の全ての中に「サービス役割設定部１１０」があるのか？）が明確でない。
　
（２−２３−２）段落【００３６】の「サービス役割設定部１１０では、デバイスがネットワーク上に連結されると、発見メッセージ(Discovery　Message)をブロードキャスティングして」の意味（「サービス役割設定部１１０」がポーリング等を行って新たな「デバイス」が「連結」されたことを発見し、発見した旨の「発見メッセージ」を「ブロードキャスティング」するのか？　「連結される」「デバイス」内に「サービス役割設定部１１０」があり、該「サービス役割設定部１１０」が自「デバイス」が「連結」された旨の「発見メッセージ」を「ブロードキャスティング」するのか？）が明確でない。
　
（２−２３−３）「応答メッセージ」は何が送信するのか（「連結」された「デバイス」が送信するのか？「連結」された「デバイス」以外の「デバイス」も送信するのか？）が明確でない。
　
（２−２３−４）「受信」は何が行うのか（「デバイス」とは別個に設けられた「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」あるいはその内部の「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」以外の「デバイス」あるいはその内部の「サービス役割設定部１１０」も行うのか？）が明確でない。
　
（２−２３−５）「デバイスのシステムリソース」とは何のシステムリソースなのか（「連結」された「デバイス」のシステムリソースのことなのか？「連結」された「デバイス」以外の「デバイス」のシステムリソースも含むのか？「デバイス」が連結されたネットワーク等を含む「システム」全体の「リソース」なのか？）が明確でない。
　
（２−２３−６）「サービス役割を決定する」とは、何を決定することを意味するのか（「デバイス」とは別個に設けられた装置の「サービス役割」を「決定」することを意味するのか？　「連結」された「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」することを意味するのか？「連結」された「デバイス」以外の「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」しなおすことを意味するのか？）、何を基にどう決定するのか（自己のリソースを基に自己が提供可能な「標準サービス」を決定するのか？自己のリソースを基に自己がマスターになり得るか否かを決定するのか？他のデバイスのリソースを基にどのデバイスがどの標準サービスのマスターになるかを決定するのか？）が明確でない。
　
　
（２−２４）段落【００３７】に「また、サービス役割設定部１１０は、 決定されるサービス役割によって、サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する。」とあるが、
　
（２−２４−１）「サービス役割」と「設定」との関係（「サービス役割」が、「設定」に如何に関与するのか？「サービス役割」と言う物が「設定」を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが「設定」の結果に影響すると言う意味か？そうであるならば、「サービス役割」と該結果の対応関係は如何になっているのか？それとも、「サービス役割」と言うパラメータを「設定」すると言う意味なのか？）が明確でない。
　
（２−２４−２）ここで「設定」の対象となる「サービスエージェントモジュール」はどのモジュールなのか（「サービス役割」を「決定」した「サービスエージェントモジュール」なのか？他の「サービスエージェントモジュール」なのか？）が明確でない。
　
（２−２４−３）「サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する」とは如何なる処理を意味するのか（「マスターエージェントモジュール」もしくは「エージェントモジュール」と言うモジュールの動作によって、「サービスエージェントモジュール」内の何らかの設定状態を変更すると言う意味なのか？「サービスエージェントモジュール」を「マスターエージェントモジュール」もしくは「エージェントモジュール」と言うモジュールとして動作するように該「サービスエージェントモジュール」内の何らかの設定状態を変更すると言う意味なのか？他の「デバイス」内の何らかの機能実現手段を「マスターエージェントモジュール」もしくは「エージェントモジュール」と言うモジュールとして動作するように「サービスエージェントモジュール」内の何らかの設定状態を変更すると言う意味なのか？）が明確でない。
　
　
（２−２５）段落【００３８】に「また、決定されるサービス役割によって自分のサービス役割をネットワーク上で動作するネットワークデバイスに知らせ、所定の標準サービス提供のために指定されるデバイスにプロキシ情報を要請して該当デバイスのプロキシ情報を設定する。」とあるが、
　
（２−２５−１）「決定されるサービス役割によって」は何を修飾するのか（「知らせ」を修飾するのか？「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　
（２−２５−２）「決定されるサービス役割」は「知らせ」ることや「設定する」こととの関係（「決定されるサービス役割」と言う物が主体となって「知らせ」ることや「設定する」ことを実行すると解してよいのか？「決定されるサービス役割」と言うパラメータが「知らせ」ることや「設定する」ことの結果に影響すると言う意味か？後者であるならば、「決定されるサービス役割」と結果の対応関係は如何になっているのか？）が明確でない。
　
（２−２５−３）「自分」とは何か（段落【００３６】で「連結」された「デバイス」のことなのか？該デバイスとは別個の「サービスエージェントモジュール」のことなのか？「サービス役割設定部１１０」のことなのか？）が明確でない。
　
（２−２５−４）「ネットワーク上で動作するネットワークデバイス」とは何か（段落【００３６】で「連結」された「デバイス」のことなのか？該デバイスとは別の全「デバイス」のことなのか？）が明確でない。
　
（２−２５−５）「所定の標準サービス提供のために」は何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　
（２−２５−６）「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？）が明確でない。
　
（２−２５−７）「該当デバイス」とは何か（段落【００３６】で「連結」された「デバイス」のことなのか？「サービスエージェントモジュール」のことなのか？「プロキシ」として動作する「デバイス」なのか？要請した「デバイス」なのか？要請された「デバイス」なのか？）が明確でない。
　
（２−２５−８）「指定されるデバイスにプロキシ情報を要請して」とは如何なる意味なのか（「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」するのか？「指定されるデバイス」に「プロキシ情報」を「指定されるデバイス」内に設定するように「要請」するのか？）が明確でない。
　
（２−２５−９）「該当デバイスのプロキシ情報を設定する。」とは如何なる意味なのか（「該当デバイス」に関連する「プロキシ情報」をどこかに設定するのか？「該当デバイス」内の「プロキシ情報」格納部に所定値を設定するのか？）が明確でない。
　
　
（２−２６）段落【００３９】に「サービス要請処理部１３０は、サービス役割設定部１１０を通じて決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを内部的に提供するか或いは外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ処理要請することで、データ変換部（Data conversion）１３１と標準サービス連結部（Core Service Linker）１３３から構成される。」とあるが、
　
（２−２６−１）「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「提供する」を修飾するのか？「外部指定された」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　
（２−２６−２）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−２６−３）「サービス役割」と「要求」や「提供」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（２−２６−４）「外部指定」とは何処から何処への指定なのか（「外部」への「指定」の意味なのか？「外部」からの「指定」の意味なのか？）、「外部」とは何処の外部なのか（「サービス要請処理部１３０」の外部なのか？「サービスエージェントモジュール」の外部なのか？「デバイス」の外部なのか？）が明確でない。
　
（２−２６−５）「外部指定されたデバイス」の「デバイス」とはどのデバイスか（「サービスエージェントモジュール」のことなのか？「マスターエージェントモジュール」を有する「デバイス」のことなのか？「プロキシ」として動作する「デバイス」なのか？）が明確でない。
　
（２−２６−６）「・・・処理要請することで・・・から構成される。」は技術的に意味不明の表現である。
　
　
（２−２７）段落【００４０】に「データ変換部１３１は、サービスエージェントモジュールのサービス役割がマスターであれば、サービス要請情報を分析して該当サービスの提供のために要求される標準サービス（Core Service)を動作させるようにサービス要請情報を変換し、サービス役割がエージェントであれば、マスターへサービス要請情報を伝送するようにサービス要請情報を変換する。」とあるが、
　
（２−２７−１）「サービスエージェントモジュールのサービス役割」とは如何なる意味か（「サービスエージェントモジュール」内に記憶されている「サービス役割」の情報なのか？「サービスエージェントモジュール」が「マスター」であるのか「エージェント」であるのかを示す情報のことなのか？）が明確でない。
　
（２−２７−２）「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（２−２７−３）「提供のために」は何を修飾するのか（「要求される」を修飾するのか？「動作させる」を修飾するのか？「変換し」を修飾するのか？」）が明確でない。
　
（２−２７−４）「標準サービス（Core Service)を動作させるようにサービス要請情報を変換し」とは如何なる意味か（「標準サービスを動作させる」ことを目的として「サービス要請情報を変換」すると言う意味か？「標準サービスを動作させる」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　
（２−２７−５）「マスターへサービス要請情報を伝送するようにサービス要請情報を変換する。」とは如何なる意味か（「マスターへサービス要請情報を伝送する」ことを目的として「サービス要請情報を変換」すると言う意味か？「マスターへサービス要請情報を伝送する」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　
（２−２７−６）「サービス役割がエージェントであれば、マスターへ・・・」とあるが「サービスエージェントモジュール」の「サービス役割」が「エージェント」である場合の「マスター」とは何処でどう定まるものを意味するのか（段落【００３７】では「サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する」ことしかしていないので、ここでの「設定」だけではマスターエージェントモジュールを決められないのでは？）が明確でない。
　
（２−２７−７）「マスターへサービス要請情報を伝送するようにサービス要請情報を変換する」とは如何なる変換を意味するのか（単に伝送規格に従って変換するだけなのか？マスターで処理不可能な情報をマスターで処理可能な形式に変換するか？）が明確でない。また、何故このような変換が必要なのか（何故、マスターとエージェントとで、受け取る情報の形式を異ならせる必要があるのか？）が明確でない。
　
　
（２−２８）段落【００４１】に「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する場合、データ変換部１３１では、ネットワークを通じて要請されたサービスを指定されたマスターエージェントモジュールへ伝送するために使用しようとするサービスと入力データをパッケージングする。」とあるが、
　
（２−２８−１）「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する」とは如何なる意味か（「マスターエージェントモジュールへサービス要請情報を伝送する」ことを目的として「サービス要請情報を変換」すると言う意味か？「マスターエージェントモジュールへサービス要請情報を伝送する」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　
（２−２８−２）「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する場合」とはどの様な場合なのか（段落【００４０】の「サービス役割がエージェントであれば」と同義なのか？異義なのか？）が明確でない。また、同義の場合、（２−２７−６）と同様に「マスターエージェントモジュール」とは何処でどう定まるものを意味するのかが明確でない。
　
（２−２８−３）「ネットワークを通じて」は何を修飾するのか（「要請された」を修飾するのか？「指定された」を修飾するのか？「伝送する」を修飾するのか？「使用しようとする」を修飾するのか？）が明確でない。
　
（２−２８−４）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−２８−５）「伝送するために」は何を修飾するのか（「使用しようとする」を修飾するのか？「パッケージングする」を修飾するのか？）が明確でない。
　
（２−２８−６）「パッケージング」と「変換」の関係（「パッケージング」が「変換」なのか？「パッケージング」は「変換」の一部なのか？「変換」とは別個の処理なのか？）が明確でない。
　
（２−２８−７）「サービスと入力データをパッケージングする」とは何を意味するのか（「サービス」自体は「パッケージング」し得るものではない。「サービス」を示す情報と「入力データ」を「パッケージングする」と言う意味なのか？「サービス」をするためのプログラムと「入力データ」を「パッケージングする」と言う意味なのか？）が明確でない。
　
　
（２−２９）段落【００４２】に「標準サービス連結部１３３は、サービス役割によってデータ変換部１３１により変換されたサービス要請情報をプロキシ（Core Service Proxy）を利用してマスターへ伝送するか或いはデータ変換部１３１により変換されたサービス要請情報によって該当標準サービスを動作させる。」とあるが、
　
（２−２９−１）「サービス役割によって」は何を修飾するのか（「変換された」を修飾するのか？「伝送する」を修飾するのか？「動作させる」を修飾するのか？、「伝送する」と「動作させる」の双方を修飾するのか？）が明確でない。
　
（２−２９−２）「サービス役割」と「変換」や「伝送」「動作」等の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　
（２−２９−３）「プロキシ（Core Service Proxy）を利用して」とは如何なる意味か（「プロキシ」と言う機能を利用するのか？「プロキシ」と言う装置を利用するのか？「利用」とは「プロキシ」を経由するのか？「プロキシ」が伝送を行うのか？）が明確でない。
　
（２−２９−４）「プロキシ（Core Service Proxy）を利用して」は何を修飾するのか（「伝送する」を修飾するのか？「動作させる」を修飾するのか？「伝送する」と「動作させる」の双方を修飾するのか？）が明確でない。
　
（２−２９−５）「該当標準サービスを動作させる」とは如何なる意味か（段落【００５３】の「標準サービスを活性化させる」こととは異なるのか？）が明確でない。
　
　
（２−３０）段落【００４３】に「また、標準サービス連結部１３３では、サービス要請情報が所定のエージェントにより要請されたものであれば、該当サービスを動作させて得られた結果値をサービスを要請したエージェントへ伝送する。」とあるが、
　
（２−３０−１）「所定のエージェント」とは何か（「サービスエージェントモジュール」「マスターエージェントモジュール」「エージェントモジュール」とは別のエージェントなのか？他のデバイス中の「エージェントモジュール」の意味なのか？「所定の」条件（例えば「結果値」を返送する機能を有すると言う条件、あるいは、「結果値」を受信する機能を有すると言う条件）を満たす「エージェント」という意味なのか？）が明確でない。。
　
（２−３０−２）「サービス要請情報が所定のエージェントにより要請された」とは、何が何をしていることを意味するのか（「所定のエージェント」から「サービス要請情報」を送るように「要請された」ことを意味するのか？「所定のエージェント」から「サービス要請情報」が送られて来たことを意味するのか？）が明確でない。
　
（２−３０−３）「要請したエージェント」と「所定のエージェント」との関係（共通のものなのか？別個のものなのか？）が明確でない。
　
　
（２−３１）段落【００４９】【００５０】に「図３に図示されるように、所定のネットワーク上に連結されデバイスが動作すると、サービスエージェントモジュールのサービス役割設定部１１０では、サービス役割決定のためにネットワーク上で動作するデバイスでディスカバリーメッセージをマルチキャストする。」「「これによって、ネットワーク上で動作するデバイスから応答メッセージが受信されると、応答メッセージを通じて収集される各デバイスのシステムリソース情報を利用して、サービス役割を決定する（Ｓ１） 。」との記載があるが、
　
（２−３１−１）「デバイス」と「サービス役割設定部１１０」の関係（「ネットワーク上で動作するデバイス」や「連結される」「デバイス」とは別個に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」内に「サービス役割設定部１１０」があるのか？「連結される」「デバイス」内に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」及び「連結される」「デバイス」の全ての中に「サービス役割設定部１１０」があるのか？）が明確でない。
　
（２−３１−２）段落【００４９】の「所定のネットワーク上に連結されデバイスが動作すると、サービスエージェントモジュールのサービス役割設定部１１０では、サービス役割決定のためにネットワーク上で動作するデバイスでディスカバリーメッセージをマルチキャストする。」の意味（「サービス役割設定部１１０」がポーリング等を行って新たな「デバイス」が「連結」されたことを発見し、発見した旨の「ディスカバリーメッセージ」を「マルチキャスト」するのか？、「連結される」「デバイス」内に「サービス役割設定部１１０」があり、該「サービス役割設定部１１０」が自「デバイス」が「連結」された旨の「ディスカバリーメッセージ」を「マルチキャスト」するのか？）が明確でない。
　
（２−３１−３）「応答メッセージ」は何が送信するのか（「連結」された「デバイス」が送信するのか？「連結」された「デバイス」以外の「デバイス」も送信するのか？）が明確でない。
　
（２−３１−４）「受信」は何が行うのか（「デバイス」とは別個に設けられた「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」あるいはその内の「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」以外の「デバイス」あるいはその内の「サービス役割設定部１１０」も行うのか？）が明確でない。
　
（２−３１−５）「デバイスのシステムリソース」とは何の「システムリソース」なのか（「連結」された「デバイス」のシステムリソースのことなのか？「連結」された「デバイス」以外の「デバイス」のシステムリソースも含むのか？「デバイス」が連結されたネットワーク等を含む「システム」全体の「リソース」なのか？）が明確でない。
　
（２−３１−６）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−３１−７）「サービス役割を決定する」とは、何を決定することを意味するのか（「デバイス」とは別個に設けられた装置の「サービス役割」を「決定」することを意味するのか？　「連結」された「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」することを意味するのか？「連結」された「デバイス」以外の「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」しなおすことを意味するのか？）、何を基にどう決定するのか（自己のリソースを基に自己が提供可能な「標準サービス」を決定するのか？自己のリソースを基に自己がマスターになり得るか否かを決定するのか？他のデバイスのリソースを基にどのデバイスがどの標準サービスのマスターになるかを決定するのか？）が明確でない。
　
　
（２−３２）段落【００５６】に「図４に図示されるように、所定の標準サービス処理のためにサービスエージェントモジュールでは、ネットワーク上で動作するデバイスに自分の役割を知らせ、それに対する応答で受信される情報を通じてマスターエージェントモジュールを検索する。」とあるが、
　
（２−３２−１）段落【００５６】に記載の処理と段落【００３８】【００５４】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】【００５４】記載のものとは別個の処理ステップなのか？）が明確でない。
　
（２−３２−２）「所定の標準サービス処理のために」とは何を修飾するのか（「所定の標準サービス処理のために」「知らせ」「検索する」のか？「所定の標準サービス処理のため」の「マスターエージェントモジュール」を「検索する」のか？）が明確でない。
　
（２−３２−３）「ネットワーク上で動作するデバイス」とは何か（段落【００３６】【００４９】で「連結」された「デバイス」のことなのか？「連結」された「デバイス」とは別の「デバイス」のことなのか？「サービスエージェントモジュール」のことなのか？「マスターエージェントモジュール」のことなのか？）が明確でない。
　
（２−３２−４）「自分」とは何か（「サービスエージェントモジュール」のことなのか？「ネットワーク上で動作するデバイス」のことなのか？）が明確でない。
　
（２−３２−５）「役割」とは何か（「サービス役割」のことなのか？「サービス役割」とは別の「役割」なのか？）が明確でない。
　
（２−３２−６）「自分の役割を知らせ、それに対する応答で受信される情報を通じてマスターエージェントモジュールを検索する」とは、如何なる情報のやりとりを意味しているのか（「自分の役割」が「エージェント」であることを他のデバイスに知らせると、他のデバイスから「マスターエージェントモジュール」がどこに有るのかを示す情報が帰ってくるのか？「自分の役割」が「エージェント」であることを他のデバイスに知らせ、これに正確に「応答」したものを「マスターエージェントモジュール」とするのか？、全ての「デバイス」が「自分の役割」を他の「デバイス」に知らせ、そのときに「受信される情報」をもとに「マスターエージェントモジュール」を決めるのか？）が明確でない。
　
（２−３２−７）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−３２−８）「検索」の結果として如何なるものが見出されるのか（全ての「マスターエージェントモジュール」が見出されるのか？特定の標準サービス提供のための「マスターエージェントモジュール」だけが見出されるのか？）が明確でない。
　
　
（２−３３）段落【００５７】に「次に、マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」とあるが、
　
（２−３３−１）段落【００５７】に記載の処理と段落【００３８】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】記載のものとは別個の処理ステップなのか？）が明確でない。
　
（２−３３−２）「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？）が明確でない。
　
（２−３３−３）どこに「設定」するのか（「サービスエージェントモジュール」内に設定するのか？「サービスエージェントモジュール」とは別の箇所に設定するのか？）が明確でない。
　
　
（２−３４）段落【００５８】に「このようにマスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報を設定したエージェントモジュールでは、応用プログラムのサービス支援のために所定の標準サービスが要求されると、設定されたプロキシ情報を利用して指定されたマスターエージェントモジュールへ該当標準サービス要請情報を伝送する。」とあるが、
　
（２−３４−１）「マスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報」とは何か（「サービス役割」のことか？「プロキシ情報」のことか？他の情報か？）が明確でない。
　
（２−３４−２）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−３４−３）「応用プログラムのサービス支援」とは何か（応用プログラムが提供するサービスを支援することか？応用プログラムから要求された標準サービスを支援することか？）が明確でない。
　
（２−３４−４）「応用プログラムのサービス支援のために」は、何を修飾するのか（「要求される」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　
　
（２−３５）段落【００５９】に「即ち、一例で、サービス役割がエージェントであるエージェントモジュールでは、サービス役割によって応用プログラム等から要求される標準サービス提供のためにマスターエージェントモジュールを検索する（Ｓ１１）。」とあるが、
　
（２−３５−１）段落【００５６】に記載の処理と段落【００３８】【００５４】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】【００５４】記載のものとは別個の処理ステップなのか？）が明確でない。
　
（２−３５−２）「サービス役割によって」は、何を修飾するのか（「要求される」を修飾するのか？「検索する」を修飾するのか？）が明確でない。
　
（２−３５−３）「サービス役割」と「要求」や「検索」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？　また、ここでの「サービス役割」は「エージェント」であることが前提となっているが、さらにその役割が細分化されているのか？）が明確でない。
　
（２−３５−４）「検索」の結果はいかなるものが見出されるのか（全ての「マスターエージェントモジュール」が見出されるのか？特定の標準サービス提供のための「マスターエージェントモジュール」だけが見出されるのか？）が明確でない。
　
（２−３５−５）「要求される標準サービス提供のためにマスターエージェントモジュールを検索する」とあるが、その意味（「検索する」ことで「要求される標準サービス提供」がなされると言う意味なのか？将来の「標準サービス提供」の「要求」に備えて「検索」をすると言う意味なのか？「要求される標準サービス提供のため」の「マスターエージェントモジュールを検索する」と言う意味か？）が明確でない。
　
　
（２−３６）段落【００６０】に「次に、マスターエージェントモジュールが検索されると、検索されたマスターエージェントモジュールへプロキシ情報を要請して受信されるプロキシ情報を設定する（Ｓ１２）。」とあるが、
　
（２−３６−１）段落【００５７】に記載の処理と段落【００３８】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】記載のものとは別個の処理ステップなのか？）が明確でない。
　
（２−３６−２）「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？）が明確でない。
　
（２−３６−３）どこに「設定」するのか（「サービスエージェントモジュール」内に設定するのか？「サービスエージェントモジュール」とは別の箇所に設定するのか？）が明確でない。
　
　
（２−３７）段落【００６１】に「次に、エージェントモジュールでは、応用プログラムから所定のサービス提供のために標準サービスが要請されると（Ｓ１３）、マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する（Ｓ１４）。」とあるが、
　
（２−３７−１）「応用プログラムから所定のサービス提供標準サービスが要請される」とは如何なる意味なのか（「応用プログラム」が「所定のサービス」をユーザなどに「提供」するために、「エージェントモジュール」に対して「標準サービス」を「要請」するのか？「応用プログラム」から「エージェントモジュール」に対して「所定の」標準「サービス」を「提供」することを「要請」するのか？）が明確でない。
　
（２−３７−２）「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する」とは如何なる意味か（「マスターエージェントモジュールへサービス要請情報を伝送する」ことを目的として「サービス要請情報を変換」すると言う意味か？「マスターエージェントモジュールへサービス要請情報を伝送する」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　
（２−３７−３）「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「エージェントモジュール」が予め有している情報なのか？「応用プログラム」から受け取った情報なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　
（２−３７−４）「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する」とは如何なる変換を意味するのか（単に伝送規格に従って変換するだけなのか？マスターエージェントモジュールで処理不可能な情報をマスターエージェントモジュールで処理可能な形式に変換するか？）が明確でない。また、何故このような変換が必要なのか（何故、マスターエージェントモジュールとエージェントモジュールとで、受け取る情報の形式を異ならせる必要があるのか？）が明確でない。
　
（２−３７−５）【図４】の記載と整合しない。（【図４】のステップＳ１４には「メッセージ変換」と記載されている。）
　
　
（２−３８）段落【００６２】に「次に、変換されたサービス要請情報をサービス処理要請メッセージと共にマスターエージェントモジュールへ伝送する（Ｓ１５）。」とあるが、
　
（２−３８−１）「サービス処理要請メッセージ」とは何処で得られた情報なのか（ステップＳ１４で変換して得られた情報なのか？「サービス要請情報」とは別に新たに生成された情報なのか？「応用プログラム」から送られて来た情報なのか？）が明確でない。
　
（２−３８−２）「サービス処理要請メッセージ」とは如何なる情報のことなのか（「サービス処理」の「要請」があった旨を示す「メッセージ」なのか？「サービス処理」の「要請」の内容を示す「メッセージ」なのか？）が明確でない。
　
　
（２−３９）段落【００６３】に「マスターエージェントモジュールでは、サービス処理要請が受信される（Ｓ１６）と、サービス要請情報を分析して要求される標準サービスを動作させるようにサービス要請情報を変換し（Ｓ１７）、ＯＳＧＩサービスプラットフォームへ標準サービス要請を伝送する（Ｓ１８）。」とあるが、
　
（２−３９−１）「サービス処理要請」とは何か（「サービス処理要請メッセージ」のことか？「サービス要請情報」のことか？）が明確でない。
　
（２−３９−２）「要求される標準サービスを動作させるようにサービス要請情報を変換し」とは如何なる意味か（「標準サービスを動作させる」ことを目的として「サービス要請情報を変換」すると言う意味か？「標準サービスを動作させる」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　
（２−３９−３）「標準サービス要請」とは何か（変換後の「サービス要請情報」のことか？「サービス要請情報」とは別の情報なのか？）が明確でない。
　
（２−３９−４）【図４】の記載と整合しない。（【図４】のＳ１７には「メッセージ変換」と記載されている。【図４】のＳ１８を始点とする矢印は「標準サービス」を終点としている。）
　
　
（２−４０）段落【００６４】に「これによって、ＯＳＧＩサービスプラットフォームでは、該当する標準サービスが実行されるように処理し（Ｓ１９）、処理結果得られる結果値をマスターエージェントモジュールへ伝送する（Ｓ２０）。」とあるが、
　
（２−４０−１）「該当する標準サービスが実行されるように処理し」とは如何なる処理なのか（「該当する標準サービス」を「実行」させる「処理」を行うのか？「該当する標準サービス」が「実行」可能となるように「処理」を行うのか？）が明確でない。
　
（２−４０−２）「処理結果得られる結果値」とは如何なるものなのか（「処理結果」であるところの「得られる結果値」と言う意味なのか？「処理」の「結果得られる結果値と言う意味か？）が明確でない。
　
（２−４０−３）【図４】の記載と整合しない。（【図４】のＳ１９、Ｓ２０は「標準サービス」の下に記載されており、「ＯＳＧＩサービスプラットフォーム」の記載は無い。【図４】のＳ２０は「処理結果伝送」となっている。）
　
　
（２−４１）段落【００６５】に「マスターエージェントモジュールでは、ＯＳＧＩサービスプラットフォームから受信される標準サービス処理結果値をエージェントモジュールへ伝送するように変換し（Ｓ２１）、要請された標準サービス処理結果でエージェントモジュールに提供する（Ｓ２２）。」とあるが、
　
（２−４１−１）「標準サービス処理結果値」とは何か（段落【００６４】の「処理結果得られる結果値」のことか？これとは別の値のことか？）が明確でない。
　
（２−４１−２）「標準サービス処理結果」とは何か（「標準サービス処理結果値」のことか？これとは別の情報のことか？）が明確でない。
　
（２−４１−３）「要請された標準サービス処理結果でエージェントモジュールに提供する」とは如何なる処理なのか（「要請された標準サービス処理結果」と言うものを用いて「エージェントモジュールに」何かを「提供する」という意味なのか？「要請された標準サービス」の「処理結果」を「エージェントモジュールに提供する」という意味なのか？「標準サービス」の「処理結果」を「要請された」「エージェントモジュールに提供する」という意味なのか？）が明確でない。
　
（２−４１−４）表現が【図４】の記載と整合しない。（【図４】のＳ２１には「メッセージ変換」と記載されている。【図４】のＳ２２には「処理結果伝送」と記載されている。）
　
　
（２−４２）段落【００６６】に「エージェントモジュールでは、マスターエージェントモジュールから処理結果値が受信されると（Ｓ２３）、受信される処理結果値を標準サービスを要請した応用プログラムへ伝送するように変換し（Ｓ２４）、応用プログラムへ伝送する（Ｓ２５）。」とあるが、
　
（２−４２−１）「処理結果値」とはなにか（段落【００６４】の「処理結果得られる結果値」なのか？段落【００６５】の「標準サービス処理結果値」あるいは「標準サービス処理結果」なのか？これらとは別個の値なのか？）が明確でない。
　
（２−４２−２）表現が【図４】の記載と整合しない。（【図４】のＳ２４には「メッセージ変換」と記載されている。）
　
　
（２−４３）段落【００６７】に「以上のように行われるサービス役割決定及びサービス役割処理過程を通じてネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間で標準サービスを共有するようになる。」とあるが、
　
（２−４３−１）「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　
（２−４３−２）「標準サービス」を「デバイスのＯＳＧＩサービスプラットフォーム」と何との「間」で共有するするのか（複数の「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有するなのか？「エージェントモジュール」と「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有するなのか？）が明確でない。
　
（２−４３−３）「サービス役割処理過程」とはどの「過程」のことなのか（段落【００５５】以降に説明される「サービス処理過程」のことか？段落【００５９】【００６０】で説明されるマスター検索（Ｓ１１）、プロキシ設定（Ｓ１２）のことか？）が明確でない。
　
　
（２−４４）段落【００６８】に「少ないで迅速なプロセス処理」とあるが、その意味が明確でない。』
　
３．本願特許請求の範囲、明細書
　該当審拒絶理由通知に対し、請求人は、上記平成２３年１０月２１日付けの意見書（以下、単に「意見書」と記す。）を提出して意見を述べると共に、同日付けの手続補正書による補正（以下、単に「補正」と記す。）によって、特許請求の範囲及び明細書を全文補正した。
　したがって、本願特許請求の範囲及び明細書は、当該手続補正書によって補正された通りの次のものである。
　
＜本願特許請求の範囲＞
「【請求項１】
　
複数のＯＳＧｉプラットフォームに各々に設けられ、
前記デバイスから受け取った応答メッセージに含まれるシステムリソース情報を用いて、
の共有
　前記サービス役割設定部により決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを外部指定され、サービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service Framework）、多様なサービスを実行するための多数の標準サービス（Core Services）、これらの標準サービスを
利用するように
　前記サービス要請処理部は前記決定された
サービス役割
　　　【請求項２】
　　前記サービス役割設定部は、前記決定される自分のサービス役割を前記ネットワーク上のデバイスに知らせることを特徴とする請求項１に記載のネットワーク上でのサービス共有のための装置。
　　　【請求項３】
　　前記サービス役割設定部は、前記サービス役割によって所定の標準サービスの提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定することを特徴とする請求項１に記載のネットワーク上でのサービス共有のための装置。
　　　【請求項４】
　　前記サービス要請処理部
の前記データ変換部は、
標準サービス要請情報を変換し
　　
前記サービス要請処理部は、この変換された標準サービス要請情報を
連結部を
　　　【請求項５】
　前記データ変換部は、前記サービス役割によってサービス要請情報を分析して該当サービス支援のために要求される標準サービスを動作させるように処理することを特徴とする
請求項４
　　　【請求項６】
　前記標準サービス連結部は、前記標準サービス要請情報を伝送するために前記デバイスのプロキシ情報を利用することを特徴とする
請求項４
　　　【請求項７】
　サービス役割設定部が、所定のネットワークに連結されたデバイスについて、前記デバイスから収集されたシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する段階と、
　サービス要請処理部が、前記サービス役割の設定段階によって決定されるデバイスのサービス役割によって、所定のサービス支援のために要求される標準サービスを外部指定されたデバイスに設けられるＯＳＧＩサービスプラットフォームであってサービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service Framework）、多様なサービスを実行するための多数の標準サービス（Core Services）、
前記決定されたサービス役割がエージェントである場合、
利用するように
　前記ＯＳＧＩサービスプラットフォームへサービスを
要請
　　　【請求項８】
　前記決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを動作させ得られる結果値を前記標準サービスを要請したデバイスへ伝送する段階をさらに含むことを特徴とする
請求項７
　　　【請求項９】
　前記決定されるサービス役割を設定し、前記ネットワーク上のデバイスに知らせる段階をさらに含むことを特徴とする
請求項７
　　　【請求項１０】
　前記決定されるサービス役割によって所定の標準サービス提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定する段階をさらに含むことを特徴とする
請求項７
　　　【請求項１１】
　前記標準サービスを外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ要請する段階は、前記標準サービスが要請されると、前記標準サービス
を要請する
マスターエージェントモジュールである
　前記受信される標準サービス要請情報によって前記デバイスで該当する標準サービスを動作させる段階と、
　前記標準サービスを動作させ得られる結果値を前記標準サービスを要請した
エージェントモジュールであるデバイスへ伝送
請求項７
　　　【請求項１２】
　前記標準サービス要請情報は、前記標準サービス提供のために指定されるデバイスのプロキシ情報を利用して伝送されることを特徴とする
請求項１１
　
＜本願明細書＞
『【発明の名称】ネットワーク上でのサービス共有のための装置及び方法
　　　【技術分野】
　　　【０００１】
　本発明は、ネットワーク上でのサービス共有のための装置及び方法に関し、より詳しくは、所定のネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間でサービスを共有できるようにして各ＯＳＧＩサービスプラットフォームに全ての標準サービスを
設置せずともサービスの提供が可能な
　　　【背景技術】
　　　【０００２】
　急速なデジタル技術とインターネットの普及にしたがって、これを活用して一般の使用者の日常生活に役になるようにサービスを提供する
デジタルホームネットワークの
　　　【０００３】
　デジタルホーム技術は、現在までの超高速インターネット共有、ファイル共有、及び周辺装置共有のために推進されてきた単純なホームネットワーキングの概念を超え、よく具備
された
　　　【０００４】
　このようなデジタルホーム技術の代表的なサービスプラットフォームとしては、Ｊａｖａ(登録商標)仮想マシン（JAVA(登録商標)Virtual　Machine）基盤下で動作可能に作られたＯＳＧＩ（Open　Service　Gateway　initiative）サービスプラットフォームがある。
　　　【０００５】
　ＯＳＧＩサービスプラットフォームは、ホームゲートウエー内部に設置され、ホームネットワーク上で動作するデバイスの連動に基づいて外部から多様なサービスの伝達を受け動作させることができるサービス実行環境を提供する。
　　　【０００６】
　図１は、
従来の
　　　【０００７】
　図１に図示されるように、従来のＯＳＧＩサービスプラットフォームは、サービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service　Framework)１５、多様なサービスを実行するための多数の標準サービス（Core　Services）１３、多数の標準サービス１３を利用して開発された多様なアプリケーションサービス（Appls　Service）１１から構成される。
　　　【０００８】
　このように構成されるＯＳＧＩサービスプラットフォームが具備された多数のデバイスが動作するホームネットワーク上で、各デバイスのＯＳＧＩサービスプラットフォームは、サービスフレームワーク１５の特性によってお互いに標準サービスを共有しない。
　　　【０００９】
　即ち、個別的に必要な標準サービスを
自身の
自身の
　　　【００１０】
　このようなＯＳＧＩサービスプラットフォームを利用する多様なサービスの発展とＯＳＧＩサービスプラットフォームの動的実行環境が重要になることによって、デバイスに適用されてホームネットワーク内で多数個のＯＳＧＩサービスプラットフォームが動作するマルチサービスプラットフォーム（Multi-Service-Platform）構造が出現するようになった。
　　　【００１１】
　これによって、マルチサービスプラットフォームとの間の相互動作の必要性が強調されているが、従来のＯＳＧＩサービスプラットフォームでは同一な機能を実行する標準サービスであっても該当フレームワークに登録されている時だけ適切なサービスが提供できるようになっているので、ホームネットワーク上で動作するＯＳＧＩサービスプラットフォームのフレームワークとの間の資源活用が不可能であった。
　　　【００１２】
　そのため、ホームネットワーク上では同一な機能を実行することによって要求される標準サービスが各ＯＳＧＩサービスプラットフォームのフレームワークに重複設置される場合が発生する問題点があった。
　　　【００１３】
　即ち、デバイスＡで所定のサービスを提供するためにＯＳＧＩサービスプラットフォームＡを通じて標準サービスＡが要求される場合、従来の技術ではネットワーク上で動作するデバイスＢのＯＳＧＩサービスプラットフォームＢで標準サービスＡが支援されてもＯＳＧＩサービスプラットフォームＢの資源活用が不可能であるためＯＳＧＩサービスプラットフォームＡに標準サービスＡを重複して登録設置しなければならなかった。
　　　【００１４】
　また、サービスを賃貸するか販売するビジネスモデルにおいては、使用者が同一なサービスを駆動するためにデバイス別に費用を重複して支払う必要があった。
　　　【００１５】
　さらに、現在のデバイスで要請したサービスを駆動するために必要な他のサービスが、他のデバイスで実行中であるＯＳＧＩサービスプラットフォームに登録されて管理中である場合
には、自身に代わって
実行してもらうよう
標準サービスを登録することができないといった
　　　【００１６】
　このような従来技術の問題点を解決するために、特許文献１の家電機器ネットワーク制御システムでは、使用者インタフェース機能を備えたデバイスにマスターのすべての機能を搭載し、その以外のデバイスは定まったスレイブとの通信又は簡単な制御コードによる通信等を行うことで、通信モジュールが具備されなかった機器をスレイブで設定して全ての機能が搭載されたマスターを通じて制御できるようにしたが、ホームネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間でサービスが共有できるようにする方法としては不足であった。
　　　【特許文献１】大韓民国特許出願第２００１−００３００３６号公報
　　　【発明の開示】
　　　【発明が解決しようとする課題】
　　　【００１７】
　本発明は、上述したような従来技術の問題点を解決するためになされたもので、本発明では、所定のネットワーク上で動作する
複数の
相互間で
　　　【００１８】
　また、本発明の他の目的は、
多数の
各ＯＳＧＩサービスプラットフォームに対して決定される役割に応じて
　　　【課題を解決するための手段】
　　　【００１９】
　前記目的を達成するために、本発明では、ＯＳＧＩサービスプラットフォームに具備されるサービスエージェントモジュールを通じてネットワーク上で動作する
複数の
の相互間で
　　　【００２０】
　また、本発明は、
各ＯＳＧｉプラットフォームに対して決定された役割に応じて、指定されたデバイスのＯＳＧＩサービスプラットフォームを通じて、必要な標準サービスを
　　　【００２１】
　サービス役割は、各デバイスから収集されるシステムリソース（resource）情報を
使用して
収集されるシステムリソース情報を所定のアルゴリズムにより処理することによって、
として
　　　【００２２】
　マスターは、所定の標準サービスに対して高いシステムリソース情報を有するデバイスとして、該当標準サービスを提供するように定義され、マスターのＯＳＧＩサービスプラットフォームを
経由して
　　　【００２３】
　このように決定されるサービス役割が
マスターであるか否か
各デバイスのＯＳＧｉプラットフォームが、
　　　【００２４】
　本発明
の一実施例
デバイスが
　　　【００２５】
　また、本発明の一実施例によるサービス要請処理部は、サービス役割によって要求される標準サービスを指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送するように
前記標準サービスを要請する情報
マスターエージェントモジュールへ伝送する
　　　【００２６】
　本発明の一実施例によるネットワーク上のサービス共有のための方法は、
デバイスが
された際に、複数のＯＳＧｉプラットフォームの間で
を共有するために
決定された
　　　【００２７】
　また、本発明の一実施例によるネットワーク上でのサービス共有のための方法は、決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを動作させて得られる結果値を前記標準サービスを要請したデバイスへ伝送する段階をさらに含むことを特徴とする。
　　　【発明の効果】
　　　【００２８】
　本発明によると、
所定のアルゴリズムを利用して決定されるサービス役割によって、
複数の
相互間で
　　　【００２９】 また、独立されたＯＳＧＩサービスプラットフォームに全ての標準サービスに対する設置及び動作なしにも標準サービス提供が可能になる。
　　　【００３０】 また、システム仕様が不十分なデバイスでもマスターエージェントモジュールのＯＳＧＩ
サービスプラットフォームを通じた標準サービスの提供によるサービスの支援を受けることができる。
　　　【発明を実施するための最良の形態】
　　　【００３１】
　以下、添付の図面を参照して本発明の一実施例によるネットワーク上でのサービス共有のための装置及び方法を説明することにおいて、ＯＳＧＩサービスプラットフォームに具備されるサービスエージェントモジュールを通じて具現されるもので説明しているが、これは例示的なもので、システムリソース情報を利用して所定の標準サービス提供のための各デバイスのサービス役割を決定し、決定されたサービス役割によって指定されたデバイスのＯＳＧＩサービスプラットフォームを通じて標準サービスを提供する方法
の他の
　　　【００３２】
　また、以下本発明によるネットワーク上でのサービス共有のための装置及び方法を説明することにおいて、本発明に対する容易な理解のためにＯＳＧＩサービスプラットフォームを基盤とするシステムを実施例として説明しているが、これも例示的
なものである。
　　　【００３３】
　図２は、本発明の一実施例によるネットワーク上でのサービス共有のためのサービス装置の構造を概略的に示す図である。
　　　【００３４】
　図２に図示されるように、本発明の一実施例によるネットワーク上でのサービス共有のための装置であるサービスエージェントモジュール１００は、サービス役割設定部（configuration）１１０と、サービス要請処理部１３０から構成される。
　　　【００３５】
　サービス役割設定部１１０は、ネットワーク上で動作するデバイスから収集されるシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する。
　　　【００３６】
　即ち、サービス役割設定部１１０では、デバイスがネットワーク上に連結されると、発見メッセージ(Discovery　Message)をブロードキャスティングして応答メッセージで受信されるデバイスのシステムリソース情報を収集し、収集されたシステムリソース情報を利用して、サービス役割を決定する。
　　　【００３７】
　また、サービス役割設定部１１０は、決定されるサービス役割によって、サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する。
　　　【００３８】
　また、決定されるサービス役割によって自分のサービス役割をネットワーク上で動作するネットワークデバイスに知らせ、所定の標準サービス
を提供することにより指定された
　　　【００３９】
　サービス要請処理部１３０は、サービス役割設定部１１０を通じて決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを内部的に提供するか或いは外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ処理要請する
もので、
　　　【００４０】
　データ変換部１３１は、サービスエージェントモジュールのサービス役割がマスターであれば、サービス要請情報を分析して該当サービスの提供のために要求される標準サービス（Core Service)を動作させるようにサービス要請情報を変換し、サービス役割がエージェントであれば、マスターへサービス要請情報を伝送するようにサービス要請情報を変換する。
　　　【００４１】
　標準サービス連結部１３３は、サービス役割によってデータ変換部１３１により変換されたサービス要請処理をプロキシ（Core Service Proxy）
情報
　　　【００４２】
　また、標準サービス連結部１３３では、サービス要請情報が所定のエージェントにより要請されたものであれば、該当サービスを動作させて得られた結果値をサービスを要請したエージェントへ伝送する。
　　　【００４３】
　参考に、上述した本発明の一実施例によるネットワーク上でのサービス共有のための装置は、各モジュールを全てハードウェアで構成するか、一部のモジュールだけをソフトウェアで構成するか、または全体モジュールをソフトウェアで構成することもできる。
　　　【００４４】
　したがって、本発明の一実施例によるネットワーク上でのサービス共有のための装置をハードウェアまたはソフトウェアで構成することは、本発明の思想を離脱せず、ソフトウェア及び／又はハードウェアで構成することによる修正と変更が付加できることは自明である。
　　　【００４５】
　以上のように構成されるネットワーク上でのサービス共有のための装置を利用する本発明によるサービス共有方法について図面を参照して詳細に説明する。
　　　【００４６】
　本発明によるネットワーク上でのサービス共有のための方法は、サービス役割を決定する段階と、決定されたサービス役割によって要請されたサービスを提供する段階から構成される。
　　　【００４７】
　図３は、本発明の一実施例によるネットワーク上でのサービス共有のためのサービス役割決定過程を概略的に示す図である。
　　　【００４８】
　図３に図示されるように、所定のネットワーク上に連結されデバイスが動作すると、サービスエージェントモジュールのサービス役割設定部１１０では、サービス役割決定のためにネットワーク上で動作するデバイスでディスカバリーメッセージをマルチキャストする。
　　　【００４９】
　これによって、ネットワーク上で動作するデバイスから応答メッセージが受信されると、応答メッセージを通じて収集される各デバイスのシステムリソース情報を利用してサービス役割を決定する（Ｓ１）。
　　　【００５０】
　このように、サービス役割が決定されると、サービス役割設定部１１０では、デバイスのサービス役割がマスターであるか否かを判別する（Ｓ２）。
　　　【００５１】
　判別結果、サービス役割がマスターではなければ（Ｓ２で「いいえ」）、ＯＳＧＩサービスプラットフォームにエージェントでサービス役割を設定する（Ｓ３）。
　　　【００５２】
　判別結果、サービス役割がマスターであれば（Ｓ２で「はい」）、ＯＳＧＩサービスプラットフォームにマスターでサービス役割を設定し（Ｓ４）、サービスフレームワーク及び標準サービスを活性化させる（Ｓ５）。
　　　【００５３】
　このような過程を通じてサービス役割が決定されると、サービス役割設定部１１０では、決定された自分のサービス役割をネットワーク上で動作するデバイスに知らせる。
　　　【００５４】
　図４は、本発明の一実施例によるネットワーク上でのサービス共有のためのサービス処理過程を概略的に示す図である。
　　　【００５５】
　図４に図示されるように、所定の標準サービス処理のためにサービスエージェントモジュールでは、ネットワーク上で動作するデバイスに自分の役割を知らせ、それに対する応答で受信される情報を通じてマスターエージェントモジュールを検索する。
　　　【００５６】
　次に、マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。
　　　【００５７】
　このようにマスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報を設定したエージェントモジュールでは、応用プログラムのサービス支援のために所定の標準サービスが要求されると、設定されたプロキシ情報を利用して指定されたマスターエージェントモジュールへ該当標準サービス要請情報を伝送する。
　　　【００５８】
　即ち、一例で、サービス役割がエージェントであるエージェントモジュールでは、サービス役割によって応用プログラム等から要求される標準サービス提供のためにマスターエージェントモジュールを検索する（Ｓ１１）。
　　　【００５９】
　次に、マスターエージェントモジュールが検索されると、検索されたマスターエージェントモジュールへプロキシ情報を要請して受信されるプロキシ情報を設定する（Ｓ１２）。
　　　【００６０】
　次に、エージェントモジュールでは、応用プログラムから所定のサービス提供のために標準サービスが要請されると（Ｓ１３）、マスターエージェントモジュールへサービス要請情報を伝送するように
サービス要請のメッセージに
　　　【００６１】
　次に、変換されたサービス要請情報をサービス処理要請メッセージと共にマスターエージェントモジュールへ伝送する（Ｓ１５）。
　　　【００６２】
　マスターエージェントモジュールでは、サービス処理要請が受信される（Ｓ１６）と、サービス要請情報を分析して要求される標準サービスを動作させるようにサービス要請情報を変換し（Ｓ１７）、ＯＳＧＩサービスプラットフォームへ標準サービス要請を伝送する（Ｓ１８）。
　　　【００６３】
　これによって、
マスターの役割の
　　　【００６４】
　マスターエージェントモジュールでは、ＯＳＧＩサービスプラットフォームから受信される標準サービス処理結果値をエージェントモジュールへ伝送するように変換し（Ｓ２１）、要請された標準サービス処理結果でエージェントモジュールに提供する（Ｓ２２）。
　　　【００６５】
　エージェントモジュールでは、マスターエージェントモジュールから処理結果値が受信されると（Ｓ２３）、受信される処理結果値を標準サービスを要請した応用プログラムへ伝送するように変換し（Ｓ２４）、応用プログラムへ伝送する（Ｓ２５）。
　　　【００６６】
　以上のように行われるサービス役割決定及びサービス役割処理過程を通じてネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間で標準サービスを共有するようになる。
　　　【００６７】
　一例で、ＰＤＡ（Personal Digital Assistant）のような小型デバイスの応用プログラムでＯＳＧＩ標準サービスの中でＸＭＬ Parser サービスを要求する場合、ＰＤＡのＯＳＧＩサービスプラットフォームに具備されるエージェントモジュールでは、ネットワーク上で動作するシステム負荷
が少なく、しかも
　　　【００６８】
　これによって、使用者ＰＤＡを通じてもＸＭＬ Parser サービスによって要求される比較的に速いプロセス処理及び多量のデータ分析の提供が受けられる。
　　　【００６９】
　他の例で、ＰＤＡのような小型デバイスの応用プログラムでＯＳＧＩ標準サービスの中でＵＰｎＰサービスを要求する場合、ＰＤＡのＯＳＧＩサービスプラットフォームに具備されるエージェントモジュールでは、ネットワーク上で動作するマスターエージェントモジュールへＵＰｎＰサービスを要請してマスターエージェントモジュールのＯＳＧＩサービスプラットフォームを通じてＵＰｎＰサービスを提供するようになる。
　　　【００７０】
　これによって、使用者はＰＤＡを通じてもＵＰｎＰサービスによるマルチキャスティングを支援するために要求されるデバイスのネットワーク設定及び持続的なネットワーク分析と共に発見されたデバイスの情報を記憶するための５個以上のスレッド支援の提供が受けられる。
　　　【００７１】
　また、他の例で、所定デバイスの応用プログラムでＯＳＧＩ標準サービスの中でプレファランスサービス（Preference Service）を要求する場合、該当デバイスのＯＳＧＩサービスプラットフォームに具備されるエージェントモジュールでは、ネットワーク上で動作するマスターエージェントモジュールへプレファランスサービスを要請してマスターエージェントモジュールのＯＳＧＩサービスプラットフォームを通じてプレファランスサービスを提供するようになる。
　　　【００７２】
　即ち、プレファランスサービスは、パーシステント（Persistent）記憶領域が支援されるか或いは別の外部データベースに近接してデータを記憶させるメカニズムを提供する必要があるが、本発明によるサービス共有方法によってプレファランスサービスが要求されたデバイスでは、パーシステント記憶領域あるいは外部データベースに近接してデータを記憶するので、メカニズムを具備しなくてもプレファランスサービス支援が可能なマスターエージェントモジュールを通じてサービス支援が可能になる。
　　　【００７３】
　本発明は、本発明の技数的思想から逸脱することなく、他の種々の形態で実施することができる。前述の実施例は、あくまでも、本発明の技数内容を明らかにするものであって、そのような具体例のみに限定して狭義に解釈されるべきものではなく、本発明の精神と特許請求の範囲内で、いろいろと変更して実施することができるものである。
　　　【図面の簡単な説明】
　　　【００７４】
　　　【図１】従来のＯＳＧＩサービスプラットフォームの動作構造を概略的に示す図である。
　　　【図２】本発明一実施例によるネットワーク上でのサービス共有のためのサービス装置の構造を概略的に示す図である。
　　　【図３】本発明の一実施例によるネットワーク上でのサービス共有のためのサービス役割決定過程を概略的に示す図である。
　　　【図４】本発明の一実施例によるネットワーク上でのサービス共有のためのサービス処理過程を概略的に示す図である。
　　　【符号の説明】
　　　【００７５】
　１００　サービスエージェントモジュール
　１１０　サービス役割設定部
　１３０　サービス要請処理部
　１３１　データ変換部　
　１３３　標準サービス連結部』
　
４．当審判断
　そこで、本願特許請求の範囲及び本願明細書の記載が、上記当審拒絶理由の記（１）及び（２）で指摘した不備を解消しているものであるか否かについて、以下に検討する。
　
（１）特許請求の範囲の記載について
　まず、主に特許請求の範囲についての記載不備であるところの、当審拒絶理由通知の（１）で指摘された点について検討する。
　
ア．当審拒絶理由通知の（１−１）で指摘した点について
　補正によって、請求項１は、上記３．の＜本願特許請求の範囲＞の【請求項１】記載の通りのものとなったが、ここに記載の「デバイス」「ネットワーク」「装置」の関係（「デバイス」と「装置」は共通のものなのか？別個のものなのか？「装置」は「デバイス」の一部品なのか？　「デバイス」が「装置」の一部品なのか？　「装置」は「ネットワーク」に連結されているものなのか？「ネットワーク」も「デバイス」をも含むものなのか？　等々）は、依然として明確に記載されていない。
　なお、この点に関し、平成２３年１０月２１日付けの意見書（以下、単に「意見書」と記す。）において、『本発明は、図１に示された従来のＯＳＧＩサービスプラットフォームを改良したもので、本発明を実施するための最良の形態として、段落００３３には、図２を参照して、ネットワーク上でのサービス共有のためのサービス装置の構造が記載されています。すなわち、図１に示されたようなＯＳＧＩサービスプラットフォームが使用者デバイスの一部としてネットワークを介して通信するシステムにおいて、サービス共有（段落００１３で説明されたような標準サービスの重複登録を回避するための標準サービスの共有）の機能を果たす装置（実施形態におけるサービスエージェントモジュール１００に対応する）に関するものであります。本願の各原請求項は、この装置の機能を分析して、その必須構成としてのサービス役割決定部と、サービス要請処理部と、データ変換部とを特定したものであります。すなわち、本願の各原請求項の特定された「装置」は、実施の形態に記載されたサービスエージェントモジュール１００に対応するものであって、原請求項に記載されたサービス役割決定部と、サービス要請処理部と、データ変換部とは、それぞれ、サービス役割決定部１１０と、サービス要請処理部１３０と、データ変換部１３１とに対応しています。
　したがって、本願にかかる「装置」は、デバイス自身が実行すべき機能とともに、各デバイスに搭載されていて、デバイスがネットワークに接続されることにより相互に通信を行うことができるものであります。』と釈明されているが、係る事項（「装置」が「各デバイスに搭載されて」いる点）は請求項１に係る発明を特定するために必要な事項（以下「発明特定事項」と記す。）として明確に記載されているものではない。
　さらに、当該事項は発明の詳細な説明や図面（例えば、段落【００３３】【図１】【図２】等）にも明示されるものではなく、発明の詳細な説明を参酌したとしても明確となるものではない。
　また、当審拒絶理由通知の（２−２２）に対する『図1の符号１０は、ＯＳＧｉサービスプラットフォームを意味し、図２の符号１００は、サービスエージェントモジュールを意味します。なお、本願発明の詳細な説明には、「……ＯＳＧｉサービスプラットフォームに具備されるサービスエージェントモジュール……」と記載されています。したがって、図１の符号１０に図２の符号１００が含まれるものと理解することができます。』との釈明、及び当審拒絶理由通知の（１−１４−５）（１−１４−１２）に対する『「ＯＳＧｉプラットフォーム」は、ハードウェアとしての「デバイス」のソフトウエア上の役割を示すものでありますので、「外部指定された」が、「ＯＳＧｉプラットフォーム」、「デバイス」のいずれを修飾しているとしても、原請求項８（請求項７）で特定される事項が異なるものではないと思料します。』『「ＯＳＧｉプラットフォーム」は、ハードウェアとしての「デバイス」のソフトウエア上の役割を示すものであります。』との釈明からは、「サービスエージェントモジュール１００」は「ソフトウエア」である「ＯＳＧｉサービスプラットフォームに具備される」もの、すなわち、「ソフトウエア」「モジュール」と解釈され、これを「装置」であると説明する当審拒絶理由通知の（１−１）に対する上記釈明とは明らかに矛盾するため、該「デバイス」「ネットワーク」「装置」の関係は、意見書の記載を参酌しても到底明確なものではない。
　したがって、当該不備は依然として解消されていない。
　
　
イ．当審拒絶理由通知の（１−２）で指摘した点について
　ここで指摘した記載は、請求項１における「
複数のＯＳＧｉプラットフォームに各々に設けられ、
前記デバイスから受け取った応答メッセージに含まれるシステムリソース情報を用いて、
の共有
　
イ−１．当審拒絶理由通知の（１−２−１）で指摘した点
　依然として、「デバイスが所定のネットワークに連結されると、前記デバイスから受け取った応答メッセージに含まれるシステムリソース情報を用いて、」との記載、すなわち「ネットワークに連結される」「デバイス」と「システムリソース情報」の「受け取」り元である「デバイス」とが共通のものである旨の記載があるが、「ネットワークに連結される」「デバイス」と「システムリソース情報」の「受け取」り元である「デバイス」とが共通のものである旨の記載は、発明の詳細な説明にはない。（なお、本願の発明の詳細な説明中の該発明特定事項に関連する記載としては、段落【００３５】【００３６】【００４８】【００４９】等の記載があるが、該記載からも「連結される」「デバイス」と「システムリソース情報」の収集元の「デバイス」が共通のものであるか否かは定かでない。）
　この点に関し、意見書において、『段落００３６では、デバイスがネットワークに接続されると、サービス役割設定部１１０がブロードキャストする発見メッセージに対して、デバイスから応答メッセージが発信されると記載されています。サービス役割設定部１１０は、この応答メッセージに含まれるシステムリソース情報から、そのデバイスの仕様、性能等を認識し、それらに応じてサービス役割を決定しています。すなわち段落００３６によれば、サービス役割設定部１１０は、デバイスから受信したシステムリソース情報によって、このサービス役割設定部１１０を備える一つのサービスエージェントモジュール（装置）に対して、マスターエージェントモジュールもしくはエージェントモジュールのいずれかの役割を設定します。この段落［００３６］の記載から、デバイスは、ネットワークに接続されるとことによって応答メッセージを出力するものであって、応答メッセージに含まれるシステムリソース情報からサービス役割が決定される点から見て、デバイスが「共通」のものと解することができるものと思料します。』と釈明されているが、当該分野の技術常識からみて、接続されたデバイスが要求を発し、該要求に応じて他のデバイスが情報を送信することもあり得る（例えば、特開平１１−３３１４号公報（平成１１年１月６日出願公開）の段落【０２８０】参照。）のであるから、段落００３６の記載をもって、「連結される」「デバイス」と「システムリソース情報」の「受け取」り元の「デバイス」が共通のものであると断定することはできない。
　なお、この釈明は当審拒絶理由通知の（２−２３−２）に対する『デバイスがネットワーク上に連結されると、そのデバイスが発見メッセージという情報をネットワーク上の他のデバイスへブロードキャスティングし、このブロードキャスティングに対して、他のデバイスからの応答メッセージが発信され、この応答メッセージから、他のデバイスのシステムリソース情報を収集しています。』との釈明とも、同（２−３１−２）に対する『ある一つのデバイスがネットワークに連結されると、その一つのデバイスから自身が連結された旨を示すディスカバリーメッセージがマルチキャストされます。これはネットワークに接続された他のデバイスを認識するとともに、マスターの役割を果たすためのデバイスを選出するためのシステムリソース情報を収集するために必要な動作であります。なお、このような役割の設定は、デバイスがサービスを実行するために、その実行の前提となる標準サービスを提供してもらう場合にのみ必要となるものであり、ネットワークに接続された全部のデバイスが常時ディスカバリーメッセージをマルチキャストして、他のデバイスのシステムリソース情報を収集することが必要ではありません。すなわち、サービスの実行が必要となる毎に、そのサービスを実行すべきデバイスが行う処理を解すべきものと思量します。』との釈明とも明らかに矛盾している。
　したがって、当該不備は依然として解消されていない。
　
イ−２．当審拒絶理由通知の（１−２−２）で指摘した点
　依然として「デバイスから受け取った応答メッセージに含まれるシステムリソース情報」とは何か（「デバイス」内の「リソース」を示す「情報」なのか？「デバイス」が接続されるネットワークなどを含む「システム」全体の「リソース」を示す「情報」なのか？）が明確でない。
　この点に関し、意見書において、『システムリソース情報とは、デバイス内のリソースを示す情報であります。すなわち、段落００３６には、「デバイスから受け取った応答メッセージで受信されるシステムリソース情報を収集し、」と記載されており、この記載から、システムリソース情報は、あるデバイスのネットワークへの接続に伴い〜発見メッセージの送信〜応答メッセージの発信という一連の処理が行われた結果、サービスエージェントに認識される当該（接続された）デバイスについて、そのリソースを示す情報と解されるものと思料します。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、当業者の通常の知識等を勘案すれば、該「システムリソース情報」の収集元の「デバイス」がネットワークなどを含む「システム」全体の「リソース」を管理するデバイス（例えば、特開２０００−２９３４５３号公報記載の「ネットワーク装置」のようなデバイス）であることも、否定することはできず、段落００３６の記載から「システムリソース情報」とは、「デバイス」内の「リソース」を示す「情報」であると断定する該釈明も失当である。
　したがって、当該不備は依然として解消されていない。
　
イ−３．当審拒絶理由通知の（１−２−６）で指摘した点
　依然として、「サービス役割」とは何を意味するのか（どのデバイスにどの標準サービスが実装されているかを示す情報なのか？特定の標準サービスに対してマスターとして動作するかエージェントとして動作するかを示す情報なのか？あるいは他のものなのか？）が明確でない。
　この点に関し、意見書において『「サービス役割」とは、各ＯＳＧｉプラットフォームに割り当てられるマスターエージェントモジュールまたはエージェントモジュールのいずれかの役割を意味し、マスターエージェントモジュールとしての役割は、自身が有する標準サービスを実行し、エージェントモジュールとしての役割は、マスターエージェントモジュールに対して標準サービスを伝送するよう要請することにあります。これらの役割については、段落００４０に記載された通りであります。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
イ−４．当審拒絶理由通知の（１−２−７）で指摘した点
　依然として、「サービス役割を決定する」とは、何を決定することを意味するのか（「デバイス」とは別個に設けられた装置の「サービス役割」を「決定」することを意味するのか？　「連結」された「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」することを意味するのか？「連結」された「デバイス」以外の「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」しなおすことを意味するのか？）、何を基にどう決定するのか（自己のリソースを基に自己が提供可能な「標準サービス」を決定するのか？自己のリソースを基に自己がマスターになり得るか否かを決定するのか？他のデバイスのリソースを基にどのデバイスがどの標準サービスのマスターになるかを決定するのか？）が明確でない。
　この点に関し、意見書においては『明細書の原段落００３６〜００４３は、サービス役割の決定と、決定に伴うサービス要請情報の伝送等の一連の処理が記載されています。これらの段落において、「サービス役割」が「マスターエージェントモジュール」または「エージェントモジュール」のいずれの役割であるかにより、各ＯＳＧｉプラットフォームの機能が異なり、また、この機能の相違によって、図３のＳ３におけるサービス役割についての判断に基づいて、それぞれの役割に応じた処理が行われています。すなわち、あるデバイスに対応するＯＳＧｉプラットフォームは、決定された役割に応じてそのデバイスの制御に必要なサービスを要請する機能を果たしています。
　本願発明は、所定のアルゴリズムを利用して所定のネットワーク上で動作するデバイスのＯＳＧｉサービスプラットフォームとの間でサービスが共有できるようにすることを目的としています。
　本願発明において、サービスの役割は、各デバイスのシステムリソースに基づいて決定されるが、デバイスのシステムリソースは、時々刻々変化し得るものでありますので、新しいデバイスが既にネットワーク上に存在していたデバイスより、より多いシステムリソースを有することもあります。
　したがって、より多いシステムリソースを有しているデバイスがマスターの役割をすることが本願発明の目的に合致する点から、新しいリソースが接続される度にサービス役割の決定が行われるものと理解することができます。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　したがって、当該不備は依然として解消されていない。
　
イ−５．当審拒絶理由通知の（１−２−８）で指摘した点
　依然として、「決定する」とは、発明の詳細な説明記載の何れの事項に対応するのか（段落【００３５】【００３６】【００４８】【００４９】記載の「決定」に対応するのか？段落【００３７】【００５１】【００５２】の「設定」に対応するのか？段落【００５０】の「判別」に対応するのか？）が明確でない。（用語のみからみれば「決定」に対応すると解するのが最も妥当ではあるが、請求項１の「前記決定されたサービスエージェントモジュール役割によってサービス要請情報を変換する」との記載を考慮すると「設定」や「判別」をも含むとの解釈も成り立つ。）
　この点に関し、意見書において、『「サービス役割の決定」は、原請求項１にサービス役割設定部の機能として特定された処理で、段落００３５、００３６等に記載されたような「サービス役割の決定」に基づいて、段落００３７等に記載されたように、各モジュールにサービス役割が設定されています。また原段落００５１には、サービス役割設定部１１０が行う動作の説明として、Ｓ１で決定された内容について、その内容がマスターであるか否かの「判別」が行われる点が説明されています。すなわち、原請求項１は、サービス役割設定部の機能の内、「サービス役割の決定」のみを特定し、実施形態では、サービス役割設定部が行う一連の処理として、「サービス役割の決定」、決定された役割の設定、さらには、設定された役割がいずれであるのかの判別が行われています。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。（依然として「設定」や「判別」をも含むとの解釈も成り立つ。）
　したがって、当該不備は依然として解消されていない。
　
イ−６．当審拒絶理由通知の（１−２−９）で指摘した点
　依然として、他にも、発明の詳細な説明における表現と異なる記載があり、明確な対応付けができない。（例えば、「ＯＳＧｉプラットフォーム」なる用語は発明の詳細な説明の段落【００２０】【００２３】【００２６】において用いられているのみで、発明の詳細な説明で頻繁に用いられている「ＯＳＧＩサービスプラットフォーム」との関係（同じ意味なのか？別の意味なのか？）も明確なものではない。）
　この点に関し、意見書において、『本願明細書は、ＯＳＧｉプラットフォームの従来技術について、図１を参照した段落０００６〜０００８に記載されたように、各デバイスにＯＳＧｉプラットフォームが設けられていて、これらのＯＳＧｉプラットフォームに標準サービスが重複して登録されるとの前提に立って、この前提により段落００１１〜００１５に記載されたような問題が生じると説明しています。本発明は、図１を参照して説明されたＯＳＧｉプラットフォームを前提として、これに代えて図２に示すようなサービスエージェントモジュールを採用したものであり、明細書中では、図１に示された従来の（標準サービスが重複して登録された）モジュールをＯＳＧｉモジュールと表現し、図２以降に示された本願の実施形態にかかるモジュールをサービスエージェントモジュールと異なる表現として区別しています。また、原段落００５２、００５３には、「ＯＳＧｉプラットフォームにエージェントでサービス役割を設定する」、あるいは、「ＯＳＧｉプラットフォームにマスターでサービス役割を設定する」との記載があります。すなわち、本願実施例では、サービスエージェントモジュールと同義にＯＳＧｉプラットフォームなる語が用いられており、本願明細書の記載は不明瞭なものではないと思料します。』と釈明されているが、段落【０００６】〜【０００８】、【００１１】〜【００１５】、【００５１】〜【００５２】（原段落【００５２】〜【００５３】に対応。）に「ＯＳＧｉプラットフォーム」なる用語は記載されていないのでこの釈明は当を得ない。
　したがって、当該不備は依然として解消されていない。
　
ウ．当審拒絶理由通知の（１−３）で指摘した点について
　ここで指摘した記載は、請求項１における「前記サービス役割設定部により決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを外部指定され、サービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service Framework）、多様なサービスを実行するための多数の標準サービス（Core Services）、これらの標準サービスを
利用するように
　
ウ−１．当審拒絶理由通知の（１−３−１）で指摘した点
　依然として、「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、明細書の段落００４０の記載、「サービス役割がマスターであれば、サービス要請情報を分析して当該サービスの提供のために要求される標準サービス要請情報を変換し、サービス役割がエージェントであれば、マスターへサービス要請情報を伝送するようサービス要請情報を変換する。」を参酌すれば、「要請する」を修飾するものと思料します。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。（読点が「外部指定され」の後ろに付されたため、「サービス役割によって」は「要求され」または「外部指定され」のいずれかを修飾すると解すべき記載に補正されている。）
　また、段落【００４０】は「変換」を説明している段落であり、そこには「要請する」との記載もなく、この記載をもって「サービス役割によって」が「要請する」を修飾するものであるとは到底言えない。
　したがって、当該不備は依然として解消されていない。
　
ウ−２．当審拒絶理由通知の（１−３−２）で指摘した点
　依然として、「サービス役割」と「要求」や「外部指定」「処理要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、ステップＳ２で説明されているように、マスターであるか否かによって各モジュールが実行する処理が変わることから、処理の条件にかかわるものでありますので、「サービス役割」は、処理の結果に影響を及ぼすものであります。すなわち、原段落００５２〜００５４に説明されているように、サービス役割がマスターでなければ、ＯＳＧｉプラットフォームにエージェントでサービス役割が設定され、サービス役割がマスターであれば、マスターでサービス役割が設定されるとあり、これらの記載から、「サービス役割」は、ＯＳＧｉプラットフォームが行う処理の結果に影響するパラメータと解すべきものと思料します。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても『「サービス役割」と該結果の対応関係は如何になっているのか？』が明確でない。
　したがって、当該不備は依然として解消されていない。
　
ウ−３．当審拒絶理由通知の（１−３−３）で指摘した点
　依然として、「標準サービスを外部指定」の「標準サービスを」は何を修飾するのか（「外部指定され」を修飾するのか？「実行する」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において『「標準サービスを」「外部指定され」は、外部から指定された役割によって、自身の標準サービスを動作させるようにサービス要請情報を変換するか、標準サービス情報を伝送するようにマスターへ要求するようにサービス要請情報を変換するかのいずれかの処理を行うことを意味しています。
　「外部指定され」は、標準サービスを修飾しており、自身が決定するのではなく、（１−３−４）で説明したように、マスターかエージェントかの役割が「外部から」指定されることによって、標準サービスを要請するか否かが判断されています。
　「外部」は、標準サービスの外部を意味しています。』と釈明されているが、「標準サービスを」が何を修飾するのかの説明はなされていない。また、これらの点は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
ウ−４．当審拒絶理由通知の（１−３−４）で指摘した点
　依然として、「外部指定され」とは如何なる意味なのか（「外部」から「指定」されることの意味なのか？「外部」に対して「指定」することなのか？）が明確でない。
　この点に関し、意見書において、上記（１−３−３）に関して摘記した通り『「外部指定され」は、標準サービスを修飾しており、自身が決定するのではなく、（１−３−４）で説明したように、マスターかエージェントかの役割が「外部から」指定されることによって、標準サービスを要請するか否かが判断されています。』との釈明がなされているが、上記（１−３−３）に関して指摘したとおり、これらの点は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、この釈明は当審拒絶理由通知の（１−１４−４）に対する『「外部指定された」とは標準サービスを内部に保有するのではなく、マスターサービスモジュールから取得すべきと外部から指定されたという意味であります。』との釈明とも、同（２−１８−７）に対する『「外部指定された」は、「外部」から「指定」されるという意味であり、デバイス自身の意思にかかわらず、所定のルールによって、例えばシステムリソースの状況等によって決定されるという意味であります。』との釈明とも相違する。
　したがって、当該不備は依然として解消されていない。
　
ウ−５．当審拒絶理由通知の（１−３−５）で指摘した点
　依然として、「外部指定され」は何を修飾するのか（「サービスフレームワーク」を修飾するのか？「ＯＳＧｉサービスプラットフォーム」を修飾するのか？「デバイス」を修飾するのか？「処理要請する」を修飾するのか？「サービス要請処理部」を修飾するのか？）が明確でない。
　この点に関し、意見書において、上記（１−３−３）に関して摘記した通り『「外部指定され」は、標準サービスを修飾しており、自身が決定するのではなく、（１−３−４）で説明したように、マスターかエージェントかの役割が「外部から」指定されることによって、標準サービスを要請するか否かが判断されています。』との釈明がなされているが、上記（１−３−３）に関して指摘したとおり、これらの点は請求項１の記載と矛盾する。（『「外部指定され」は、標準サービスを修飾』する旨の釈明は、日本語の文法に適合しない。）
　なお、当審拒絶理由通知の（１−１４−５）に対する『「ＯＳＧｉプラットフォーム」は、ハードウェアとしての「デバイス」のソフトウエア上の役割を示すものでありますので、「外部指定された」が、「ＯＳＧｉプラットフォーム」、「デバイス」のいずれを修飾しているとしても、原請求項８（請求項７）で特定される事項が異なるものではないと思料します。』との釈明と、当審拒絶理由通知の（２−１８−８）に対する『デバイスは、ＯＳＧｉプラットフォームとして機能するハードウェアを意味しており、外部指定されるのは、ＯＩＳＧｉプラットフォームとしてのデバイスと解すべきものと思料します。』との釈明も相違しており、これら他の箇所の釈明を参酌しても請求項１の「外部指定され」が何を修飾すると釈明しようとしているのかを推測することもできない。
　したがって、当該不備は依然として解消されていない。
　
ウ−６．当審拒絶理由通知の（１−３−６）で指摘した点
　依然として、「外部指定」の「外部」とは何の外部を意味するのか（アプリケーションなどの「標準サービス」の外部の事なのか？「サービス役割設定部」等の「サービス要請処理部」の外部のことなのか？他の「デバイス」の事なのか？）が明確でない。
　この点に関し、意見書において、上記（１−３−３）に関して摘記した通り『「外部」は、標準サービスの外部を意味しています。』との釈明がなされているが、上記（１−３−３）に関して指摘したとおり、これらの点は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　なお、この釈明は当審拒絶理由通知の（１−１４−６）に対する『「外部指定」の「外部」は、他のデバイスを示すものであります。』との釈明とも、同（２−１８−９）に対する『「外部」とは、「外部」から「指定」されるという意味であり、デバイス自身の意思にかかわらず、所定のルールによって、例えばシステムリソースの状況等によって決定されるという意味であります。』との釈明とも明らかに相違し、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
ウ−７．当審拒絶理由通知の（１−３−７）で指摘した点
　依然として、「所定のサービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「所定のサービス支援のために」は、「要求される」を修飾しています。すなわち、段落０００７に記載されたように、アプリケーションサービスは、標準サービスを前提として実行されるものでありますので、原請求項１は、「所定のサービス支援のために」このサービスが利用することが必要とされる標準サービスが要求されています。』と釈明されているが、『「所定のサービス支援のために」は、「要求される」を修飾しています。』との釈明と、『「所定のサービス支援のために」このサービスが利用することが必要とされる標準サービスが要求されています。』との釈明とは、互いに異なる意味内容の事項を釈明しており、何れの釈明が正しいのか明確に判断できない。（「要求される」と文言通りに解釈したものと、「必要とされる」に文言を替えて解釈したものとは、異なる技術思想になる。）
　また、後者の釈明は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　なお、この釈明は当審拒絶理由通知の（１−１４−７）に対する『本願の前提となる従来技術についての段落００１１、００１２に記載されているように、一般に、「所定のサービス支援のために」様々な標準サービスが必要とされ、その標準サービスが各ＯＳＧｉプラットフォームに搭載されています。これを前提とすれば、「要求される」は「標準サービス」を修飾すると解するのが妥当であると思料します。』との釈明とも一致しない
　また、「所定のサービス支援のために」が「要求される」を修飾していると仮定しても、「サービス支援のために要求」するとは何か（「サービス」による「支援」を「要求」すると言う意味なのか？「サービス支援」という処理の実行を「要求」すると言う意味なのか？「サービス支援」を目的として「要求」すると言う意味なのか？単に「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　したがって、当該不備は依然として解消されていない。
　
ウ−８．当審拒絶理由通知の（１−３−８）で指摘した点
　依然として、「サービス支援」とは何か（「サービスを実行する」と同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？後者であるならば何がどう異なるのか？「サービス」を「指定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　この点に関し、意見書において、『「サービス支援」は、標準サービスによるサービスの支援を意味し、「サービスを実行」は、この標準サービスの支援を前提として、アプリケーションサービスを実行することを意味しています。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、この釈明は当審拒絶理由通知の（１−１４−８）に対する『「サービス支援」とは、所定のアプリケーションを実行するために必要とされる標準サービスを云い、マスターの場合には、自身で直接標準サービスを搭載し、マスターでないエージェントモジュールの場合には、マスターへ標準サービスの伝送を要求しています。この処理は、段落００６２〜００６５にＳ１８〜Ｓ２５の各ステップの処理として記載された通りであります。』との釈明とも、当審拒絶理由通知の（２−１８−１１）に対する『「サービス支援」とは、「サービスを実行するために必要な」と解すべきものであります。なお、サービスを「実行」するには、その前提となる標準サービスの「支援」が必要とされ、この標準サービスを要請することを意味しています。また、「外部指定」とは、マスターとして指定されたという意味に解すべきものと思量します。』との釈明とも相違し、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
ウ−９．当審拒絶理由通知の（１−３−９）で指摘した点
　依然として、「サービス実行環境提供のためのサービス伝達と管理を実行する」とは何処から何処へ如何なる情報を伝達することを意味するのか（アプリケーションからのサービス要請の情報を標準サービスに引き渡すのか？他のデバイスからのサービス要請を自デバイスの標準サービスやアプリケーションに引き渡すのか？）が明確でない。
　この点に関し、意見書において、『段落００３５〜００４０に記載されているように、役割がマスターであれば自デバイスの標準サービスやアプリケーションに引き渡し、マスターでなければ、サービス要請の情報を標準サービスに引き渡すものである。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても、「何処から」「情報を伝達することを意味するのか」は依然として不明である。
　したがって、当該不備は依然として解消されていない。
　
ウ−１０．当審拒絶理由通知の（１−３−１０）で指摘した点
　依然として、「多様なサービスを実行するための多数の標準サービス」と、上記（１−２）で摘記した「所定の標準サービスの共有」の「標準サービス」との関係（同じものなのか異なるものなのか？）上記（１−２）で摘記した「決定」された「サービス役割」との関係（無関係なのか否か？）が明確でない。
　この点に関し、意見書において、『段落０００７に記載された本願の前提となる技術から明らかなように、共通の標準サービスを前提として、多数のアプリケーションサービスが実行される関係にあります。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても『「多様なサービスを実行するための多数の標準サービス」と、上記（１−２）で摘記した「所定の標準サービスの共有」の「標準サービス」との関係（同じものなのか異なるものなのか？）上記（１−２）で摘記した「決定」された「サービス役割」との関係（無関係なのか否か？）』は不明である。
　したがって、当該不備は依然として解消されていない。
　
ウ−１１．当審拒絶理由通知の（１−３−１２）で指摘した点
　依然として、「ＯＳＧｉサービスプラットフォームを有するデバイス」は、上記（１−２）で摘記した「連結され」た「デバイス」や「受け取」り元の「デバイス」とは如何なる関係にあるのか、上記（１−２）で摘記した「決定」された「サービス役割」とは如何なる関係なのかが明確でない。
　この点に関し、意見書において、『ＯＳＧｉプラットフォームを有するデバイスは、段落０００４に記載されているように、単にＪａｖａ（登録商標）仮想マシン基盤下で動作可能なサービスプラットフォームであるデバイスという意味であります。また、各デバイスは、本願明細書の各所に記載されているように、役割がマスターであるかそうでないかによって異なる動作を行います。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、この意見書の記載を参酌しても、「ＯＳＧｉサービスプラットフォームを有するデバイス」と「連結され」た「デバイス」や「受け取」り元の「デバイス」との関係や、「サービス役割」との関係は不明である。
　したがって、当該不備は依然として解消されていない。
　
ウ−１２．当審拒絶理由通知の（１−３−１３）で指摘した点
　依然として、発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００４０】や段落【００６１】には「デバイスに対して処理要請する」旨の記載は無い。）
　この点に関し、意見書において、『原段落００４２、００６２に直接的に記載されてはいませんが、図４を参照した原段落００５６〜００６７に記載されたエージェントモジュール、マスターエージェントモジュール、間の通信処理によれば、Ｓ１５において、エージェントモジュールがマスターエージェントモジュールとしてのデバイスへ標準サービスを要請し、Ｓ１８において、マスターエージェントモジュールとしてのデバイスが自身の有する標準サービスを要請しており、このことから、「デバイスに対して処理要請する」点は明細書に記載されたものと思料します。』と釈明されているが、明確な対応付けができないことに付いての釈明がなされていない。
　そして、該意見書記載の「マスターエージェントモジュールとしてのデバイスが自身の有する標準サービスを要請」すること（通常はこの場合は「デバイスに対して処理要請する」とは表現しない）をも「デバイスに対して処理要請する」に含めて解釈すべきなのか否かは、該対応づけが明確でないが故に、明確な判断が不可能なものである。
　なお、当審拒絶理由通知の（１−１４−５）（１−１４−１２）に対する釈明等によれば「ＯＳＧＩサービスプラットフォーム」はソフトウエアであり、当審拒絶理由通知の（２−２２）に対する釈明等によれば「サービスエージェントモジュール」は「ＯＳＧＩサービスプラットフォーム」に具備されるものであるから、これも「ソフトウエア」である。また、当審拒絶理由通知の（１−１４−１３）に対する釈明によれば「マスターエージェントモジュール」「エージェントモジュール」は「ＯＳＧＩサービスプラットフォーム」の一種であるから。これもソフトウエアである。しかしながら、当審拒絶理由通知の（１−３−１３）に対する上記釈明によれば「マスターエージェントモジュール」「エージェントモジュール」は「デバイス」として説明しており、これらは整合しない。
　したがって、当該不備は依然として解消されていない。
　
　
エ．当審拒絶理由通知の（１−４）で指摘した点について
　ここで指摘した記載は、請求項１における「前記サービス要請処理部は前記決定された
サービス役割
　
エ−１．当審拒絶理由通知の（１−４−３）で指摘した点
　依然として、「サービス役割」と「変換」との関係（「サービス役割」が、「変換」に如何に関与するのか？「サービス役割」と言う物が該「変換」処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該「変換」処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『サービスエージェントモジュールの役割は、段落００３７に記載されているように、マスターエージェントモジュール（マスター）か、エージェントモジュール（マスターでない）かのいずれかであります。そして、この役割により、サービス要請があった場合の処理が、以下のように相違しています。すなわち、段落００３９に記載されているように、サービス要請情報が提供されると、各エージェントモジュールのサービス役割設定部１１０により、マスターの役割が設定された場合には、サービス要請処理部１３０により、内部的に提供すべきものと判断がされて、段落００４０に記載されているように、標準サービスを動作させるように、データ変換部１３１によって前記サービス要請情報が変換されます。これに対して、マスターの役割が設定されない場合には、段落００４０に示すように、サービス要請処理部１３０のデータ変換部により、前記サービス要求情報が、マスターの役割を有する他のサービスプラットフォームへ標準サービスを要求するよう変換されます。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
エ−２．当審拒絶理由通知の（１−４−４）で指摘した点
　依然として、「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　この点に関し、意見書において、『「サービス要請情報」は、アプリケーションサービスを実行するために標準サービスが必要となったサービスエージェントモジュールであって、役割がマスターでないものから、標準サービスを要求すべくマスターエージェントモジュールへ送信される情報であります。したがって、サービスの要請のために必要な、例えば必要とする標準サービスを特定するための情報と解すべきものと思量します。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
エ−３．当審拒絶理由通知の（１−４−５）で指摘した点
　依然として、ここでの「変換」は発明の詳細な説明中のどの事項（ステップＳ１４？　ステップＳ１７？）と対応するのかが明確でない。
　この点に関し、意見書において、『「変換」という処理は、デバイスの役割がマスターサービスエージェントとサービスエージェントとのいずれの場合でも行われるものであります。したがって、図４において、役割がサービスエージェントの場合には、Ｓ１４によってメッセージが変換されてＳ１５のサービス要請処理が行われ、マスターエージェントモジュールの場合には、Ｓ１８のサービス要請処理が標準サービスに対して行われます。すなわち、役割がマスターであるマスターエージェントモジュールの場合には、Ｓ１８によって直接標準サービスが要請され、役割がマスターでないサービスエージェントモジュールの場合は、Ｓ１４によってメッセージが変換され、マスターエージェントモジュールへ標準サービス処理要請Ｓ１５が送られ、さらに、マスターエージェントモジュールがＳ１８によって標準サービスを要請し、Ｓ２１の変換処理を経て、Ｓ２２で処理結果がサービスエージェントモジュールへ伝送されます。ここに言う「処理結果」はエージェントモジュールの要請に対応する「標準サービス」であります。』と釈明されているが、係る事項は請求項１に係る発明の発明特定事項として明確に記載されているものではない。
　また、図４には「役割がサービスエージェントの場合には、」「マスターエージェントモジュールの場合には、」といった判断処理は記載されておらず、これが「すなわち、役割がマスターであるマスターエージェントモジュールの場合には、Ｓ１８によって直接標準サービスが要請され、役割がマスターでないサービスエージェントモジュールの場合は、Ｓ１４によってメッセージが変換され、マスターエージェントモジュールへ標準サービス処理要請Ｓ１５が送られ、さらに、マスターエージェントモジュールがＳ１８によって標準サービスを要請し、Ｓ２１の変換処理を経て、Ｓ２２で処理結果がサービスエージェントモジュールへ伝送されます。」との説明の根拠となるものではない。
　さらに、仮に該意見書の釈明の通りのもので有ると仮定しても、ここでの「変換」が発明の詳細な説明中のどの事項（ステップＳ１４？　ステップＳ１７？　ステップＳ２１？　ステップＳ２４？）と対応するのかは、依然として明確でない。
　したがって、当該不備は依然として解消されていない。
　
　
オ．当審拒絶理由通知の（１−６）で指摘した点について
　ここで指摘した記載は、請求項２における「前記サービス役割設定部は、前記決定される自分のサービス役割を前記ネットワーク上のデバイスに知らせることを特徴とする請求項１に記載のネットワーク上でのサービス共有のための装置。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
オ−１．当審拒絶理由通知の（１−６−１）で指摘した点
　依然として、「自分」とは何か（請求項１の「装置」のことなのか？請求項１の「連結」された「デバイス」のことなのか？「サービスエージェントモジュール」のことなのか？「サービス役割設定部」のことなのか？発明の詳細な説明記載の何に対応するのか？）が明確でない。
　この点に関し、意見書において、『原請求項３に対応する請求項２の「自分」は、ネットワークに接続された複数のデバイス（マスターエージェントモジュールまたはサービスエージェントモジュール）の内、ある一つのデバイスを意味し、そのマスターエージェントモジュールまたはサービスエージェントモジュールとしてのデバイスにおけるサービス役割設定部（実施形態の符号１１０）を意味しています。』と釈明されているが、係る事項は請求項２に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　なお、該意見書の記載における「ある一つのデバイスを意味し」との記載と「サービス役割設定部（実施形態の符号１１０）を意味しています。」との記載は整合せず、該意見書の記載を参酌しても「自分」とは何かが明確でない。
　また、この釈明は当審拒絶理由通知の（２−２５−３）に対する『「自分」とは、ネットワークへの接続後、段落００３７等の処理によって役割が決定されたデバイス自身を意味しています。』との釈明とも整合していない。
　したがって、当該不備は依然として解消されていない。
　
オ−２．当審拒絶理由通知の（１−６−２）で指摘した点
　依然として、「前記ネットワーク上のデバイス」とはなにか（請求項１の「連結」された「デバイス」のことなのか？請求項１の「連結」された「デバイス」以外の「デバイス」でかつ「ネットワーク」上にある「デバイス」のことなのか？発明の詳細な説明記載の何に対応するのか？）が明確でない。
　この点に関し、意見書において、『原請求項３に対応する請求項２の「前記ネットワーク上のデバイス」は、「自分」以外の「他のデバイス」を意味しています。』と釈明されているが、係る事項は請求項２に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、この釈明は当審拒絶理由通知の（１−１８−５）に対する『「前記ネットワーク上のデバイス」は、「前記ネットワークに接続された全てのデバイス」を意味しています。』との釈明と相違する。
　したがって、当該不備は依然として解消されていない。
　
　
カ．当審拒絶理由通知の（１−７）で指摘した点について
　ここで指摘した記載は、請求項３における「前記サービス役割設定部は、前記サービス役割によって所定の標準サービスの提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定する」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
カ−１．当審拒絶理由通知の（１−７−１）で指摘した点
　依然として、「前記サービス役割によって」は、何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『原請求項４に対応する請求項３の「前記サービス役割によって」は、「サービス役割がマスターでない場合」を意味しており、「サービス役割がマスターでない場合」の処理として、「所定の標準サービス提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定する」を特定したものであります。ここで、標準サービス提供のために指定されるデバイスは、マスターの役割のデバイスと解すべきものと思量します。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても「前記サービス役割によって」が何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）は依然として明確でない。
　また、当審拒絶理由通知の（１−１９−１）に対する『原請求項１２に対応する請求項１０における「決定されるサービス役割によって、」は、サービス役割がマスターか否かによっての意味であり、実施形態を参照すれば、マスターでないエージェントモジュールにおいて、応用プログラムから標準サービスの要請があると（図４のＳ１３）、その要請のメッセージは変換され（Ｓ１４）、サービス処理要請がマスターへ送られ（Ｓ１５）、さらに、その要請が標準サービス要請に変換されて（Ｓ１７）、標準サービスが要請され（Ｓ１８）、要請に応じて受信された標準サービスがエージェントモジュールへ送られます（Ｓ２２）。したがって、「決定されるサービス役割によって、」は、「要請して」を修飾するものであります。』との釈明と、当審拒絶理由通知の（２−２５−１）に対する『「決定されるサービス役割によって」は、「設定する」を修飾しています。』との釈明も相違しており、これら他の箇所の釈明を参酌しても請求項３の「前記サービス役割によって」が何を修飾すると釈明しようとしているのかを推測することもできない。
　したがって、当該不備は依然として解消されていない。
　
カ−２．当審拒絶理由通知の（１−７−２）で指摘した点
　依然として、「前記サービス役割」と「要請」や「設定」等の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、パラメータと解すべきものであり、サービス役割によって、処理が異なるものであります。すなわち、原請求項４にあっては、「サービス役割がマスターでない」場合における処理が特定されています。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても、「サービス役割」と「要請」や「設定」等の処理の結果の対応関係は如何になっているのかは依然として明確でない。
　したがって、当該不備は依然として解消されていない。
　
カ−３．当審拒絶理由通知の（１−７−３）で指摘した点
　依然として、「所定の標準サービス提供のために」は何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「所定の標準サービス提供のために」は「指定される」を修飾されており、「指定されたデバイス」は、マスターエージェントモジュールとしての役割を果たすデバイスを意味しています。ここで、標準サービス提供のために指定されるデバイスは、マスターの役割のデバイスと解すべきものと思量します。』と釈明されているが、この釈明は当審拒絶理由通知の（１−１９−４）に対する『「所定の標準サービス提供のために」は、「要請する」を修飾しています。』との釈明と相違しており、何れの釈明が正しいのか明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
カ−４．当審拒絶理由通知の（１−７−４）で指摘した点
　依然として、「指定されるデバイス」とは何か（請求項１の「連結」された「デバイス」のことか？請求項１の「処理要請」される「デバイス」のことか？これらとは別の（例えば、役割がマスターである）「デバイス」なのか？）が明確でない。
　この点に関し、意見書において、『指定されるデバイスは、マスターエージェントモジュールとしての役割を果たすデバイスを意味しています。ここで、標準サービス提供のために指定されるデバイスは、マスターの役割のデバイスと解すべきものと思量します。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
　
カ−５．当審拒絶理由通知の（１−７−５）で指摘した点
　依然として、「前記デバイス」とは何か（請求項１の「連結」された「デバイス」のことか？請求項１の「処理要請」される「デバイス」のことか？請求項４の「指定されるデバイス」のことか？）が明確でない。
　この点に関し、意見書において、『前記デバイスは、マスターエージェントモジュールとしての役割を果たすデバイスを意味しています。ここで、標準サービス提供のために指定されるデバイスは、マスターの役割のデバイスと解すべきものと思量します。
　すなわち、原段落００５７（段落００５６）には、
　［００５６］
　次に、マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。とあり、また、原段落００５８（段落００５７）には、
　［００５７］
　このようにマスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報を設定したエージェントモジュールでは、応用プログラムのサービス支援のために所定の標準サービスが要求されると、設定されたプロキシ情報を利用して指定されたマスターエージェントモジュールへ該当標準サービス要請情報を伝送する。とあり、これらの記載から見て、マスターの役割を果たしていると解すべきものと思量します。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
カ−６．当審拒絶理由通知の（１−７−６）で指摘した点
　依然として、「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？「プロキシ」を利用するために必要な情報なのか？）が明確でない。
　この点に関し、意見書において、『原段落００５７、００５８には、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されています。したがって、ご指摘の「プロキシ情報」はプロキシであることを示す情報と解すべきものと思料します。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　また、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されているからといって、必ずしも「プロキシ情報」が「プロキシであることを示す情報」であるとは限らず、自己が他の「プロキシ」として動作するために必要な「情報」の可能性もあるのであるから、本願発明の詳細な説明の段落【００５６】【００５７】（原段落００５７、００５８に対応）の記載は、「プロキシ情報」が「プロキシであることを示す情報」であることの根拠にはならない。
　また、この釈明は当審拒絶理由通知の（１−１１−４）に対する『図４に示された処理は、多くのサービスエージェントモジュールのうち、いずれかのサービスエージェントモジュールからサービスの要請があった場合に、そのサービスエージェントモジュールへ標準サービスを提供する一連の処理を示しています。このような一連の処理から見て、「プロキシ情報」は、サービスを要請したサービスエージェントモジュールを特定するためのデータ、例えばＩＰアドレスなどを意味すると解すべきものと思料します。』との釈明とも、当審拒絶理由通知の（１−１９−７）に対する『「プロキシ情報」は、標準サービス提供のために指定されるデバイス、すなわち、マスターの役割を有するデバイスを特定し、このデバイスをプロキシとして動作させるための情報と解すべきものであります。』との釈明とも相違し、何れの釈明が正しいのか明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
カ−７．当審拒絶理由通知の（１−７−７）で指摘した点
　依然として、「指定されるデバイスにプロキシ情報を要請して」とは如何なる意味なのか（「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」するのか？「指定されるデバイス」に「プロキシ情報」を「指定されるデバイス」内に設定するように「要請」するのか？）が明確でない。
　この点に関し、意見書において、『原段落００５７、００５８の記載を参酌すれば、「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」すると解すべきものと思料します。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
カ−８．当審拒絶理由通知の（１−７−８）で指摘した点
　依然として、「前記デバイスのプロキシ情報を設定する。」とは如何なる意味なのか（「前記デバイス」に関連する「プロキシ情報」をどこかに設定するのか？「前記デバイス」内の「プロキシ情報」格納部に所定値を設定するのか？）が明確でない。
　この点に関し、意見書において、『原段落００５７、００５８の記載を参酌すれば、「前記デバイス」に関連する「プロキシ情報」を自身のサービス役割設定部に設定するものと思料します。』と釈明されているが、係る事項は請求項３に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　したがって、当該不備は依然として解消されていない。
　
カ−９．当審拒絶理由通知の（１−７−９）で指摘した点
　依然として、発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３８】では「決定されるサービス役割によって・・・知らせ」と表現している。また段落【００５６】では「マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」と表現している。）
　この点に関し、意見書において、『段落００３８は、役割がマスターでない場合に、マスター（マスターエージェントモジュール）へマスターでない旨を知らせ、その上で、マスターへプロキシ情報を提供するよう要請する点を説明しています。これに対して、段落００５７は、マスターエージェントモジュールからのプロキシ情報がサービスエージェントモジュールで受信される点を説明しており、これらの段落の説明は矛盾するものではないと思料します。』と釈明されているが、請求項３の記載と発明の詳細な説明における表現とが異なっているため、明確な対応付けができないことに対する釈明をしてはいない。
　したがって、当該不備は依然として解消されていない。
　
キ．当審拒絶理由通知の（１−８）で指摘した点について
　ここで指摘した記載は、請求項４における「前記サービス要請処理部
の前記データ変換部は、
標準サービス要請情報を変換し
　
キ−１．当審拒絶理由通知の（１−８−４）で指摘した点
　依然として、「指定された」は何を修飾するのか（「デバイス」を修飾するのか？「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「指定された」は、一つのデバイスのＯＳＧｉプラットフォームすなわちサービスエージェントモジュールとなるデバイスを修飾しています。』と釈明されているが、当該記載を参酌しても、「デバイス」を修飾するのか、「ＯＳＧＩサービスプラットフォーム」を修飾するのかが不明である。
　したがって、当該不備は依然として解消されていない。
　
キ−２．当審拒絶理由通知の（１−８−５）で指摘した点
　依然として、「前記サービス要請処理部の前記データ変換部は・・・指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送する」とは如何なる意味なのか（「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」から「指定」され該「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」を「指定」して該「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？（即ち「指定」の主体））が明確でない。
　この点に関し、意見書において、『マスターエージェントモジュールのサービス要請処理部は、指定されたデバイス、すなわち、標準サービスを要求しているサービスエージェントモジュールに標準サービスを伝送するための標準サービス連結部を有しています。図４を参照すれば、Ｓ１５にてサービス処理要請がなされると、マスターエージェントモジュールは、Ｓ１６〜Ｓ２１の処理により標準サービスを取得して、Ｓ２２の処理によりエージェントモジュールに標準サービスを伝送しています。』と釈明されているが、当該記載を参酌しても、「指定」の主体が不明である。
　したがって、当該不備は依然として解消されていない。
　
キ−３．当審拒絶理由通知の（１−８−６）で指摘した点
　依然として、「指定されたデバイス」の「デバイス」は、上記（１−２）に関して摘記した「連結」された「デバイス」や「受け取」り元の「デバイス」とは如何なる関係にあるのかが明確でない。上記（１−２）に関して摘記した「決定」された「サービス役割」とは如何なる関係なのかも明確でない。
　この点に関し、意見書において、『前述のように、指定されたデバイスは、マスターの役割を持たないサービスエージェントモジュールを意味しています。』と釈明されているが、係る事項は請求項４に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　したがって、当該不備は依然として解消されていない。
　
キ−４．当審拒絶理由通知の（１−８−７）で指摘した点
　依然として、「標準サービス要請情報」とあるが、これは、何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　なお、この点に関し、意見書においては『標準サービス要請情報は、サービス要請処理部の出力を示します』と釈明されているが、係る事項は請求項４に係る発明の発明特定事項として明確に記載されているものではない。
　また、仮に「サービス要請処理部の出力を示」すものとしても、「データ変換部」が予め有している情報なのか、「サービスエージェントモジュール」が予め有している情報なのか、「アプリケーション」から受け取った情報なのか、他の「デバイス」から受け取った情報なのか、「サービス」の「要請」を受けることができることを示す「情報」なのか、「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか、「サービス」の「要請」があった旨を示す「情報」なのか、「サービス」の「要請」の内容を示す「情報」なのか、「サービス」の「要請」の実行のために必要な引数などの「情報」なのかは、依然として、明確でない。また、このため請求項１の「サービス要請情報」との異同も明確でない。
　したがって、当該不備は依然として解消されていない。
　
キ−５．当審拒絶理由通知の（１−８−８）で指摘した点
　依然として、段落【００４０】【００６０】の実施例の記載と整合しない。（段落【００４０】【００６０】には「ＯＳＧＩサービスプラットフォームへ伝送するように標準サービス要請情報を変換」する旨の記載は無い。）
　この点に関し、意見書において、『原請求項５と整合しないと指摘された原段落００４１を削除しました。また同様に原請求項５と整合しないと指摘された原段落００６１に対応する段落００６０のマスターエージェントモジュールは、マスターの役割を有するもの、サービスエージェントモジュールはマスターの役割を有しないものを意味しますので、原請求項５の記載と矛盾するものではないと思料します。』と釈明されているが、段落【００４０】【００６０】の実施例の記載と整合しないと言う不備が解消されているわけではない。
　したがって、当該不備は依然として解消されていない。
　
　
ク．当審拒絶理由通知の（１−９）で指摘した点について
　ここで指摘した記載は、請求項４における「
前記サービス要請処理部は、この変換された標準サービス要請情報を
連結部を
　
ク−１．当審拒絶理由通知の（１−９−２）で指摘した点
　依然として、「前記指定」はどの「指定」のことなのか（請求項１の「外部指定」のことなのか？　請求項４の「標準サービスを、指定された」の「指定」のことなのか？）が明確でない。
　この点に関し、意見書において、『「前記指定」は、原請求項５の第２行において「指定」された、サービスエージェントモジュールを意味しています。』と釈明されているが、係る事項は請求項４に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
ク−２．当審拒絶理由通知の（１−９−３）で指摘した点
　依然として、「標準サービス連結部」が「標準サービス要請情報」を「ＯＳＧＩサービスプラットフォームへ伝送する」ことは、発明の詳細な説明開示の実施例の如何なる事項に対応するのかが明確でない。（段落【００４１】【００６１】には「ＯＳＧＩサービスプラットフォームへ伝送する」旨の記載は無い。）
　この点に関し、意見書において、『原段落００４３に対応する段落００４２の記載によれば、標準サービス連結部１３３は、エージェント（サービスエージェントモジュール）に要請されたサービス要請情報に対して、そのサービスエージェントモジュールに対応する一つのＯＳＧｉプラットフォームで伝送しており、発明の詳細な説明と整合するものと思料します。』と釈明されているが、段落【００４２】には「結果値」の伝送が記載されてはいるものの、「標準サービス連結部」が「標準サービス要請情報」を「ＯＳＧＩサービスプラットフォームへ伝送する」旨の記載は全くない。
　したがって、当該不備は依然として解消されていない。
　
　
ケ．当審拒絶理由通知の（１−１０）で指摘した点について
　ここで指摘した記載は、請求項５における「前記データ変換部は、前記サービス役割によってサービス要請情報を分析して該当サービス支援のために要求される標準サービスを動作させるように処理する」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ケ−１．当審拒絶理由通知の（１−１０−１）で指摘した点
　依然として、「前記サービス役割によって」は何を修飾するのか（「分析して」を修飾するのか？「要求される」を修飾するのか？「処理する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、サービス役割がマスターであるか否かを意味しています。したがって、原請求項５を前提とすれば、原段落００６５（段落００６４）のＳ２１のように、標準サービス処理結果値をエージェントモジュールへ伝送するように変換しています。』と釈明されているが、当該意見書の記載を参酌しても、「前記サービス役割によって」が「分析して」を修飾するのか、「要求される」を修飾するのか、「処理する」を修飾するのかは依然として不明である。
　したがって、当該不備は依然として解消されていない。
　
ケ−２．当審拒絶理由通知の（１−１０−２）で指摘した点
　依然として、「前記サービス役割」と「分析」や「要求」「処理」との関係（「サービス役割」が、「分析」「要求」「処理」に如何に関与するのか？「サービス役割」と言う物が「分析」「要求」「処理」を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが「分析」「要求」「処理」の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『本願の特許請求の範囲、発明の詳細な説明の全般にわたり、「サービス役割」とは、マスターであるか否かという条件、すなわちパラメータを意味しており、役割がマスターでない場合には、サービスエージェントとしての処理を行い、マスターの場合には、マスターエージェントとして処理を行います。』と釈明されているが、係る事項は請求項５に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ケ−３．当審拒絶理由通知の（１−１０−３）で指摘した点
　依然として、「該当サービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「動作させる」を修飾するのか？「処理する」を修飾するのか？」）が明確でない。
　この点に関し、意見書において、『「該当サービス支援のために」は、「要求される標準サービス」を修飾しています。すなわち、予め準備された多くの標準サービスの中から、要求されたサービスを実行するために必要とされる（要求される）標準サービスを動作させるように、処理する。具体的には、図４を参照した原段落００６４（段落００６３）において、Ｓ１８の要請を受けて行われるＳ１９の処理を意味しています。』と釈明されているが、係る事項は請求項５に係る発明の発明特定事項として明確に記載されているものではない。
　なお、「該当サービス支援のために」は連用修飾節である（「に」は助動詞「だ」の連用形である）から、名詞節「要求される標準サービス」の修飾節（連体修飾節）とはなり得ず、この釈明は当を得ないものである。
　また、「サービス役割」が単にマスターであるか否かを意味するパラメータであるとすれば、これによって「予め準備された多くの標準サービスの中から、要求されたサービスを実行するために必要とされる（要求される）標準サービスを動作させるように、処理する。」との解釈は技術的に不合理なものであり、該意見書の釈明は、当審拒絶理由通知の（１−１０−１）（１−１０−２）に対する釈明と整合のとれたものになっておらず、失当である。
　したがって、当該不備は依然として解消されていない。
　
ケ−４．当審拒絶理由通知の（１−１０−４）で指摘した点
　依然として、「標準サービスを動作させるように処理する」とは如何なる意味か（「標準サービスを動作させる」ことを目的として何らかの「処理」をすると言う意味か？「標準サービスを動作させる」ことができるようなサービス要請情報にデータ変換「処理」をすると言う意味か？）が明確でない。
　この点に関し、意見書において、『「標準サービスを動作させるように処理する」によれば、上述の図４にＳ１９の処理として示されたように、マスターエージェントモジュールが、多くの標準サービスから、要求されたサービスを実行するために必要な標準サービスを選択してサービスエージェントモジュールへ提供しています。』と釈明されているが、該釈明を参酌しても、該「マスターエージェントモジュールが、多くの標準サービスから、要求されたサービスを実行するために必要な標準サービスを選択してサービスエージェントモジュールへ提供」すると言う処理が「データ変換部」が行う処理と如何に関連するのか（データ変換の目的を説明しているだけなのか？データ変換後のデータ形式を限定しているのか？）は明確でない。
　なお、図４にも、図４のＳ１９を説明する段落【００６３】にも、「マスターエージェントモジュールが、多くの標準サービスから、要求されたサービスを実行するために必要な標準サービスを選択してサービスエージェントモジュールへ提供」する旨の記載はなく、この釈明は根拠のないものであり、失当である。
　したがって、当該不備は依然として解消されていない。
　
　
コ．当審拒絶理由通知の（１−１１）で指摘した点について
　ここで指摘した記載は、請求項６における「前記標準サービス連結部は、前記標準サービス要請情報を伝送するために前記デバイスのプロキシ情報を利用する」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
コ−１．当審拒絶理由通知の（１−１１−１）で指摘した点
　依然として、「前記標準サービス要請情報」とはどの「標準サービス要請情報」なのか（変換前の「標準サービス要請情報」なのか？変換後の「標準サービス要請情報」なのか？）が明確でない。
　この点に関し、意見書において、『原請求項７に対応する請求項６の「前記標準サービス要請情報」は、変換後の「標準サービス要請情報」を示しています。』と釈明されているが、係る事項は請求項６に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
コ−２．当審拒絶理由通知の（１−１１−２）で指摘した点
　依然として、「前記デバイス」とは、どの「デバイス」のことなのか（「連結」された「デバイス」のことか？「受け取」り元の「デバイス」のことか？「指定されたデバイス」の「デバイス」のことか？）が明確でない。
　この点に関し、意見書において、『「前記デバイス」は、原請求項５（請求項４）における「指定されたデバイス」を意味しています。』と釈明されているが、係る事項は請求項６に係る発明の発明特定事項として明確に記載されているものではない。
　
コ−３．当審拒絶理由通知の（１−１１−３）で指摘した点
　依然として、「伝送する」とあるが、何処へ伝送するのかが明確でない。
　この点に関し、意見書において、『「伝送する」は、図４のＳ１８におけるマスターエージェントントモジュールが標準サービスへ標準サービス要請情報を伝送する処理を意味しています。』と釈明されているが、係る事項は請求項６に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
　
サ．当審拒絶理由通知の（１−１２）で指摘した点について
　ここで指摘した記載は、請求項７における「サービス役割設定部が、所定のネットワークに連結されたデバイスについて・・・サービス要請処理部が・・・ネットワーク上でのサービス共有のための方法。」に相当するが、依然として、該「デバイス」と「サービス役割設定部」「サービス要請処理部」の関係（「デバイス」内に「サービス役割設定部」「サービス要請処理部」が有るのか？「デバイス」とは別個の装置内に「サービス役割設定部」「サービス要請処理部」が有るのか？　等々）が明確でない。
　この点に関し、意見書において、『原請求項８に対応する請求項７は、請求項１で特定されたネットワークのサービス共有のための装置を構成するサービス役割設定部、サービス要請処理部で実行される処理を特定したものであります。したがって、ネットワークに接続されたデバイスが、マスターであるか否かという役割に応じて、各デバイスがソフトウェアにしたがってサービス役割設定部、サービス要請処理部、サービスフレームワーク、標準サービスとしての機能を分担して、あるいは、あるデバイスが複数の機能を果たすものであります。また、これらの機能が実際のサービスを実行するある一つのデバイスとは別個のデバイスによって果たされて、該一つのデバイスが所定のサービスを実行することができるものであります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、発明の詳細な説明及び図面を参酌しても、該意見書で説明される構成を明確に把握し得るものではない。
　したがって、当該不備は依然として解消されていない。
　
　
シ．当審拒絶理由通知の（１−１３）で指摘した点について
　ここで指摘した記載は、請求項７における「サービス役割設定部が、所定のネットワークに連結されたデバイスについて、前記デバイスから収集されたシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する段階」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
シ−１．当審拒絶理由通知の（１−１３−１）で指摘した点
　依然として、「前記デバイスから収集されたシステムリソース情報」とあるが、「ネットワークに連結された」「デバイス」と「システムリソース情報」の「収集」元である「デバイス」とが共通のものである旨の記載は、本願の発明の詳細な説明には記載されていない。（なお、本願の発明の詳細な説明中の該発明特定事項に関連する記載としては、段落【００３５】【００３６】【００４８】【００４９】等の記載があるが、該記載からも「連結される」「デバイス」と「システムリソース情報」の収集元の「デバイス」が共通のものであるか否かは定かでない。）
　この点に関し、意見書において、『本発明は、図１に示された従来のＯＳＧＩサービスプラットフォームを改良したもので、本発明を実施するための最良の形態として、段落００３３には、図２を参照して、ネットワーク上でのサービス共有のためのサービス装置の構造が記載されています。すなわち、図１に示されたようなＯＳＧＩサービスプラットフォームが使用者デバイスの一部としてネットワークを介して通信するシステムにおいて、サービス共有（段落００１３で説明されたような標準サービスの重複登録を回避するための標準サービスの共有）の機能を果たす、例えば、実施形態におけるサービスエージェントモジュール１００において実行される処理に関するものであります。原請求項８は、サービスエージェントモジュールが有する機能としてのサービス役割決定部と、サービス要請処理部とが実行する処理を特定したものであります。』と釈明されているが、「ネットワークに連結された」「デバイス」と「システムリソース情報」の「収集」元である「デバイス」とが共通のものであると言える根拠や理由を説明してはいない。
　また、この釈明は当審拒絶理由通知の（２−２３−２）（２−２３−３）に対する『デバイスがネットワーク上に連結されると、そのデバイスが発見メッセージという情報をネットワーク上の他のデバイスへブロードキャスティングし、このブロードキャスティングに対して、他のデバイスからの応答メッセージが発信され、この応答メッセージから、他のデバイスのシステムリソース情報を収集しています。』との釈明と明らかに矛盾している。
　したがって、当該不備は依然として解消されていない。
　
シ−２．当審拒絶理由通知の（１−１３−２）で指摘した点
　依然として、「デバイスから収集されたシステムリソース情報」とは何か（「デバイス」内の「リソース」を示す「情報」なのか？「デバイス」が接続されるネットワークなどを含む「システム」全体の「リソース」を示す「情報」なのか？）が明確でない。
　この点に関し、意見書において、『デバイスから収集されたシステムリソース情報は、「デバイス」内の「リソース」を示す情報であり、この情報により、当該デバイスの役割がマスターであるか否かが決定されます。すなわち、そのデバイスに求められる機能に応じて「リソース」を示す情報が異なり、その情報に基づいて当該デバイスの役割が決定されています。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。（当該釈明の根拠も説明されていない。）
　したがって、当該不備は依然として解消されていない。
　
シ−３．当審拒絶理由通知の（１−１３−４）で指摘した点
　依然として、何の「サービス役割」を決定するのか（「デバイス」の「サービス役割」を決定するのか？「デバイス」以外の何らかの装置の「サービス役割」を決定するのか？「サービス役割設定部」の「サービス役割」を決定するのか？「サービス要請処理部」の「サービス役割」を決定するのか？）が明確でない。
　この点に関し、意見書において、『段落００３５〜００３７に記載されているように、ネットワーク上にデバイスが連結されると、そのデバイスのシステムリソース情報が収集され、デバイスのサービス役割が決定されており、この記載から見て、「デバイス」のサービス役割を決定すると解すべきものと思料します。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、発明の詳細な説明の段落【００３５】〜【００３７】には「デバイス」の「サービス役割」を決定する旨の記載は無い。
　したがって、当該不備は依然として解消されていない。
　
シ−４．当審拒絶理由通知の（１−１３−５）で指摘した点
　依然として、「サービス役割」とは何を意味するのか（どのデバイスにどの標準サービスが実装されているかを示す情報なのか？特定の標準サービスに対してマスターとして動作するかエージェントとして動作するかを示す情報なのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、特定の標準サービスに対してマスターとして動作するかエージェントとして動作するかを示す情報であります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
シ−５．当審拒絶理由通知の（１−１３−６）で指摘した点
　依然として、「決定する」とは、発明の詳細な説明記載の何れの事項に対応するのか（段落【００３５】【００３６】【００４８】【００４９】記載の「決定」に対応するのか？段落【００３７】【００５１】【００５２】の「設定」に対応するのか？段落【００５０】の「判別」に対応するのか？）が明確でない。（用語のみからみれば「決定」に対応すると解するのが最も妥当ではあるが、請求項７の「前記決定されるデバイスのサービス役割によって、サービス要請情報を変換する」との記載を考慮すると「設定」や「判別」をも含むとの解釈も成り立つ。）
　この点に関し、意見書において、『明細書の段落００３６〜００４２には、サービス役割の決定と、決定に伴うサービス要請情報の伝送等の一連の処理が記載されています。これらの段落において、「サービス役割」が「マスターエージェントモジュール」または「エージェントモジュール」のいずれの役割であるかにより、各ＯＳＧｉプラットフォームの機能が異なり、また、この機能の相違によって、図３のＳ３におけるサービス役割についての判断に基づいて、それぞれの役割に応じた処理が行われています。すなわち、あるデバイスに対応するＯＳＧｉプラットフォームは、決定された役割に応じてそのデバイスの制御に必要なサービスを要請する機能を果たしています。
　本願発明は、所定のアルゴリズムを利用して所定のネットワーク上で動作するデバイスのＯＳＧｉサービスプラットフォームとの間でサービスが共有できるようにすることを目的としています。
　本願発明において、サービスの役割は、各デバイスのシステムリソースに基づいて決定されるが、デバイスのシステムリソースは、時々刻々変化し得るものでありますので、新しいデバイスが既にネットワーク上に存在していたデバイスより、より多いシステムリソースを有することもあります。
　したがって、より多いシステムリソースを有しているデバイスがマスターの役割をすることが本願発明の目的に合致する点から、新しいリソースが接続される度にサービス役割の決定が行われるものと理解することができます。』と釈明されているが、これは請求項７記載の「決定する」が、発明の詳細な説明記載の何れの事項に対応するのか（「設定」や「判別」をも含むのか否か？）を説明するものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ス．当審拒絶理由通知の（１−１４）で指摘した点について
　ここで指摘した記載は、請求項７における「サービス要請処理部が、前記サービス役割の設定段階によって決定されるデバイスのサービス役割によって、所定のサービス支援のために要求される標準サービスを外部指定されたデバイスに設けられるＯＳＧＩサービスプラットフォームであってサービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service Framework）、多様なサービスを実行するための多数の標準サービス（Core Services）、
前記決定されたサービス役割がエージェントである場合、
利用するように
　
ス−１．当審拒絶理由通知の（１−１４−１）で指摘した点
　依然として、「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、「処理要請する」を修飾するものであります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
ス−２．当審拒絶理由通知の（１−１４−２）で指摘した点
　依然として、「サービス役割」と「要求」や「外部指定」「処理要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、その後の標準サービスの要求において、段落００４０に記載されているように、役割がマスターであれば、標準サービスを直接動作させるように、サービス要請情報を変換し、マスターでなければ、マスターエージェントモジュールへ標準サービスの伝送を依頼するようサービス要請情報を変換するためのパラメータとしての役割を果たしています。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても『「サービス役割」と該結果の対応関係は如何になっているのか？』が明確でない。
　したがって、当該不備は依然として解消されていない。
　
ス−３．当審拒絶理由通知の（１−１４−３）で指摘した点
　依然として、「標準サービスを外部指定」の「標準サービスを」は何を修飾するのか（「外部指定され」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「標準サービスを」は、「外部指定され」を修飾しています。』と釈明されているが、係る事項は請求項７の記載に明確に反映されていない。
　また、当該釈明の根拠（発明の詳細な説明のどの記載から如何なる推論で係る事項を導き出せるのか？等）も明確に説明されていないため、係る事項が発明の詳細な説明に記載されるどの事項に対応するのかも定かでない。
　したがって、当該不備は依然として解消されていない。
　
ス−４．当審拒絶理由通知の（１−１４−４）で指摘した点
　依然として、「外部指定された」とは如何なる意味なのか（「外部」から「指定」されることの意味なのか？「外部」に対して「指定」することなのか？）が明確でない。
　この点に関し、意見書において、『「外部指定された」とは標準サービスを内部に保有するのではなく、マスターサービスモジュールから取得すべきと外部から指定されたという意味であります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、当該釈明の根拠（発明の詳細な説明のどの記載から如何なる推論で係る事項を導き出せるのか？等）も明確に説明されていないため、係る事項が発明の詳細な説明に記載されるどの事項に対応するのかも定かでない。
　なお、この釈明は、当審拒絶理由通知の（１−３−４）に対する『「外部指定され」は、標準サービスを修飾しており、自身が決定するのではなく、（１−３−４）で説明したように、マスターかエージェントかの役割が「外部から」指定されることによって、標準サービスを要請するか否かが判断されています。』との釈明とも、同（２−１８−７）に対する『「外部指定された」は、「外部」から「指定」されるという意味であり、デバイス自身の意思にかかわらず、所定のルールによって、例えばシステムリソースの状況等によって決定されるという意味であります。』との釈明とも相違しており、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
ス−５．当審拒絶理由通知の（１−１４−５）で指摘した点
　依然として、「外部指定された」は何を修飾するのか（「デバイス」を修飾するのか？　「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「ＯＳＧｉプラットフォーム」は、ハードウェアとしての「デバイス」のソフトウエア上の役割を示すものでありますので、「外部指定された」が、「ＯＳＧｉプラットフォーム」、「デバイス」のいずれを修飾しているとしても、原請求項８（請求項７）で特定される事項が異なるものではないと思料します。』と釈明されているが、ハードウエアを指定することと、ソフトウエアを指定することとが異なる事項を特定するものであることは明らかであり、この釈明は失当である。
　また、この釈明は当審拒絶理由通知の（１−３−５）に対する『「外部指定され」は、標準サービスを修飾しており、』との釈明とも、当審拒絶理由通知の（２−１８−８）に対する『デバイスは、ＯＳＧｉプラットフォームとして機能するハードウェアを意味しており、外部指定されるのは、ＯＩＳＧｉプラットフォームとしてのデバイスと解すべきものと思料します。』との釈明とも整合しない。
　したがって、当該不備は依然として解消されていない。
　
ス−６．当審拒絶理由通知の（１−１４−６）で指摘した点
　依然として、「外部指定」の「外部」とは何の外部を意味するのか（アプリケーションなどの「標準サービス」の外部の事なのか？「サービス役割設定部」等の「サービス要請処理部」の外部のことなのか？他の「デバイス」の事なのか？））が明確でない。
　この点に関し、意見書において、『「外部指定」の「外部」は、他のデバイスを示すものであります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、当該釈明の根拠（発明の詳細な説明のどの記載から如何なる推論で係る事項を導き出せるのか？等）も明確に説明されていないため、係る事項が発明の詳細な説明に記載されるどの事項に対応するのかも定かでない。
　なお、この釈明は当審拒絶理由通知の（１−３−６）に対する『「外部」は、標準サービスの外部を意味しています。』との釈明とも、同（２−１８−９）に対する『「外部」とは、「外部」から「指定」されるという意味であり、デバイス自身の意思にかかわらず、所定のルールによって、例えばシステムリソースの状況等によって決定されるという意味であります。』との釈明とも明らかに相違し、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
ス−７．当審拒絶理由通知の（１−１４−７）で指摘した点
　依然として、「所定のサービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『本願の前提となる従来技術についての段落００１１、００１２に記載されているように、一般に、「所定のサービス支援のために」様々な標準サービスが必要とされ、その標準サービスが各ＯＳＧｉプラットフォームに搭載されています。これを前提とすれば、「要求される」は「標準サービス」を修飾すると解するのが妥当であると思料します。』と釈明されているが、この釈明は「所定のサービス支援のために」が何を修飾するのかを説明するものではない。また、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　なお、この釈明は当審拒絶理由通知の（１−３−７）（２−１８−１０）に対する『「所定のサービス支援のために」は、「要求される」を修飾しています。』との釈明とも一致せず、何れの釈明が正しいのかも明確に判断できない。（「要求される」と「必要とされる」とは意味が異なる。）
　したがって、当該不備は依然として解消されていない。
　
ス−８．当審拒絶理由通知の（１−１４−８）で指摘した点
　依然として、「サービス支援」とは何か（「サービスを実行する」と同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「指定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　この点に関し、意見書において、『「サービス支援」とは、所定のアプリケーションを実行するために必要とされる標準サービスを云い、マスターの場合には、自身で直接標準サービスを搭載し、マスターでないエージェントモジュールの場合には、マスターへ標準サービスの伝送を要求しています。この処理は、段落００６２〜００６５にＳ１８〜Ｓ２５の各ステップの処理として記載された通りであります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　なお、この釈明は当審拒絶理由通知の（１−３−８）に対する『「サービス支援」は、標準サービスによるサービスの支援を意味し、「サービスを実行」は、この標準サービスの支援を前提として、アプリケーションサービスを実行することを意味しています。』との釈明とも、当審拒絶理由通知の（２−１８−１１）に対する『「サービス支援」とは、「サービスを実行するために必要な」と解すべきものであります。なお、サービスを「実行」するには、その前提となる標準サービスの「支援」が必要とされ、この標準サービスを要請することを意味しています。また、「外部指定」とは、マスターとして指定されたという意味に解すべきものと思量します。』との釈明とも相違し、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
ス−９．当審拒絶理由通知の（１−１４−９）で指摘した点
　依然として、「サービス実行環境提供のためのサービス伝達と管理を実行する」とは何処から何処へ如何なる情報を伝達することを意味するのか（アプリケーションからのサービス要請の情報を標準サービスに引き渡すのか？他のデバイスからのサービス要請を自デバイスの標準サービスやアプリケーションに引き渡すのか？）が明確でない。
　この点に関し、意見書において、『明細書には、背景技術として、
　［０００５］
　ＯＳＧＩサービスプラットフォームは、ホームゲートウエー内部に設置され、ホームネットワーク上で動作するデバイスの連動に基づいて外部から多様なサービスの伝達を受け動作させることができるサービス実行環境を提供する。
　［０００６］
　図１は、従来ＯＳＧＩサービスプラットフォームの動作構造を概略的に示す図である。
　［０００７］
　図１に図示されるように、従来のＯＳＧＩサービスプラットフォームは、サービス実行環境提供のためのサービス伝達と管理を実行するサービスフレームワーク（Service　Framework)１５、多様なサービスを実行するための多数の標準サービス（Core　Services）１３、多数の標準サービス１３を利用して開発された多様なアプリケーションサービス（Appls　Service）１１から構成される。と記載されています。
　すなわち、ＯＳＧｉサービスプラットフォームは、一種のサービスフレームワークとして、このサービスフレームワークが提供するサービス実行環境によれば、デバイスの内部だけでなく、外部の多様なサービスが伝達され動作することができます。すなわち、サービス実行環境はデバイス内部または外部から受信した多様なサービスを動作させることができる環境であると理解することができます。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、該意見書の記載を参酌しても、「何処から」「何処へ」「如何なる」「情報を伝達することを意味するのか」は依然として不明である。
　なお、該意見書の釈明においては、段落【０００５】〜【０００７】記載の背景技術を根拠に『すなわち、ＯＳＧｉサービスプラットフォームは、一種のサービスフレームワークとして、このサービスフレームワークが提供するサービス実行環境によれば、デバイスの内部だけでなく、外部の多様なサービスが伝達され動作することができます。すなわち、サービス実行環境はデバイス内部または外部から受信した多様なサービスを動作させることができる環境であると理解することができます。』との結論を導き出しているが、その過程（如何なる推論でこの結論を導き出せるのか）が説明されておらず、該結論の正否も定かでない。
　さらに、この釈明は当審拒絶理由通知の（１−３−９）に対する『段落００３５〜００４０に記載されているように、役割がマスターであれば自デバイスの標準サービスやアプリケーションに引き渡し、マスターでなければ、サービス要請の情報を標準サービスに引き渡すものである。』との釈明とも相違しており、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
ス−１０．当審拒絶理由通知の（１−１４−１０）で指摘した点
　依然として、「多様なサービスを実行するための多数の標準サービス」と、上記（１−１３）に関して摘記した「所定の標準サービス共有」の「標準サービス」との関係（同じものなのか異なるものなのか？上記（１−１３）で摘記した「決定」された「サービス役割」との関係（無関係なのか否か？）が明確でない。
　この点に関し、意見書において、『「多様なサービスを実行するための多数の標準サービス」とは、様々なサービスにはその前提として対応する様々な標準サービスが必要とされているという明細書の段落００１１、００１２の記載と同義であり、共有とは、本願の実施形態のように、マスターエージェントモジュールで共有される標準サービスと同義であります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても、「多様なサービスを実行するための多数の標準サービス」と、上記（１−１３）に関して摘記した「所定の標準サービス共有」の「標準サービス」との関係（同じものなのか異なるものなのか？上記（１−１３）に関して摘記した「決定」された「サービス役割」との関係（無関係なのか否か？）は不明である。
　したがって、当該不備は依然として解消されていない。
　
ス−１１．当審拒絶理由通知の（１−１４−１２）で指摘した点
　依然として、「ＯＳＧＩサービスプラットフォーム」は、上記（１−１３）に関して摘記した「連結され」た「デバイス」や「収集」元の「デバイス」とは如何なる関係にあるのか、上記（１−１３）に関して摘記した「決定」された「サービス役割」とは如何なる関係なのかが明確でない。
　この点に関し、意見書において、『「ＯＳＧｉプラットフォーム」は、ハードウェアとしての「デバイス」のソフトウエア上の役割を示すものであります。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、この意見書の記載を参酌しても、「ＯＳＧｉサービスプラットフォームを有するデバイス」と「連結され」た「デバイス」や「収集」元の「デバイス」との関係や、「サービス役割」との関係は不明である。
　したがって、当該不備は依然として解消されていない。
　
ス−１２．当審拒絶理由通知の（１−１４−１３）で指摘した点
　依然として、発明の詳細な説明における表現と異なっており、明確な対応付けができない。（（段落【００４１】や段落【００６１】には「ＯＳＧＩサービスプラットフォームへサービスを要請する」旨の記載は無い。）
　この点に関し、意見書において、『発明の詳細な説明では、ＯＳＧｉプラットフォームは役割にかかわらない一般的な場合の表現として用い、マスターの役割を持つ場合にマスターエージェントモジュールントモジュールと表現し、マスターの役割でない場合には、エージェントモジュールと表現しており、原請求項８に対応する請求項７の記載は、発明の詳細な説明と矛盾するものではないと思料します。』と釈明されているが、明確な対応付けができないことに付いての釈明がなされていない。
　また、この釈明の根拠（どこの記載からこのようなことが導き出されるのか？）が説明されておらず、その正否も定かでない。
　なお、この釈明は、当審拒絶理由通知の（１−３−１３）に対する『原段落００４２、００６２に直接的に記載されてはいませんが、図４を参照した原段落００５６〜００６７に記載されたエージェントモジュール、マスターエージェントモジュール、間の通信処理によれば、Ｓ１５において、エージェントモジュールがマスターエージェントモジュールとしてのデバイスへ標準サービスを要請し、Ｓ１８において、マスターエージェントモジュールとしてのデバイスが自身の有する標準サービスを要請しており、このことから、「デバイスに対して処理要請する」点は明細書に記載されたものと思料します。』との釈明、すなわち「デバイス」を「マスターエージェントモジュール」「エージェントモジュール」と同一視する説明とも相入れない。
　したがって、当該不備は依然として解消されていない。
　
セ．当審拒絶理由通知の（１−１５）で指摘した点について
　ここで指摘した記載は、請求項７における「前記ＯＳＧＩサービスプラットフォームへサービスを
要請
　したがって、当該不備は依然として解消されていない。
　
セ−１．当審拒絶理由通知の（１−１５−１）で指摘した点
　依然として、「サービス役割」と「変換」との関係（「サービス役割」が、「変換」に如何に関与するのか？「サービス役割」と言う物が該「変換」処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該「変換」処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『サービス役割によって、は、サービス役割がマスターか否かによっての意味であり、マスターでないエージェントモジュールにおいて、応用プログラムから標準サービスの要請があると（図４のＳ１３）、その要請のメッセージは変換され（Ｓ１４）、サービス処理要請がマスターへ送られ（Ｓ１５）、さらに、その要請が標準サービス要請に変換されて（Ｓ１７）、標準サービスが要請され（Ｓ１８）、要請に応じて受信された標準サービスがエージェントモジュールへ送られます（Ｓ２２）。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
セ−２．当審拒絶理由通知の（１−１５−３）で指摘した点
　依然として、「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　この点に関し、意見書において、『「サービス要請情報」は、エージェントモジュールが応用プログラムを実行しようとするに際し、応用プログラムの前提となる標準プラグを保有していないことによって、発生するもので、マスターエージェントモジュールへ当該応用プログラムに必要な標準サービスの伝送を求めることを内容としています。』と釈明されているが、係る事項は請求項７に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
セ−３．当審拒絶理由通知の（１−１５−４）で指摘した点
　依然として、ここでの「変換」は発明の詳細な説明中のどの事項（ステップＳ１４？　ステップＳ１７？）と対応するのかが明確でない。（「ステップＳ１４」のみに対応すると仮定すると、ステップＳ１７が特許請求の範囲に反映されていないことになるが、これでは所期の課題を達成できない。「ステップＳ１７」にも対応すると仮定すると、上記（１−１４）に関して摘記した「ＯＳＧＩサービスプラットフォーム」に「処理要請」する旨の事項と矛盾する。）
　この点に関し、意見書において、『本願の発明の詳細な説明の段落００４０には次のような記載があります。
　［００４０］
　データ変換部１３１は、サービスエージェントモジュールのサービス役割がマスターであれば、サービス要請情報を分析して該当サービスの提供のために要求される標準サービス（Core Service)を動作させるようにサービス要請情報を変換し、サービス役割がエージェントであれば、マスターへサービス要請情報を伝送するようにサービス要請情報を変換する。
　原請求項８（請求項７）に記載された変換段階は、上記の詳細な説明に記載されている変換段階に対応します。すなわち、サービス役割によるサービス要請情報の変換を意味するものであります。
　なお、拒絶理由通知に指摘された各ステップ別の動作は、次の通りです。
　(1)　S14：マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する。
　(2)　S17：サービス処理要請を受信したマスターエージェントモジュールが標準サービスを動作させるようにサービス要請情報を変換する。
　(3)　S21：マスターエージェントモジュールが標準サービス処理結果値を変換する。
　(4)　S24：サービスエージェントモジュールが受信された標準サービス処理結果値を変換する。
　ここで、(3)と(4)とは、変換の対象を「標準サービス処理結果値」としているので、上記の変換対象とは異なります。
　また、(1)と(2)は、サービス役割によるサービス要請情報の変換を意味するが、(1)はサービス役割がエージェントである場合を意味し、(2)はサービス役割がマスターである場合を意味しています。
　したがって、原請求項８（請求項７）に記載の変換段階は、上記(1)と(2)とであることが解ります。
　なお拒絶理由通知は、原請求項８に記載の「ＯＳＧｉサービスプラットフォームへサービスを要請する段階」が、上記(2)の場合にその内容が矛盾すると指摘しています。この点を明確にすべく、請求項７では、「ＯＳＧｉサービスプラットフォームへサービスを要請する段階」がサービス役割がエージェントである場合に行われる点を特定しました。』と釈明されているが、「サービス要請処理部が、・・・サービス役割によって、・・・サービスフレームワーク（Service Framework）、標準サービス（Core Services）、前記決定されたサービス役割がエージェントである場合、・・・アプリケーションサービス（Appls Service）とから構成されたＯＳＧＩサービスプラットフォームへサービスを要請する段階とを含み」との文のつながりからみて、「ＯＳＧｉサービスプラットフォームへサービスを要請する段階」が「サービス役割がエージェントである場合」に行われる点は正しく特定されていない。また、係る事項が正しく特定されたとしても、ステップＳ１７が特許請求の範囲に反映されていないことになる。
　したがって、当該不備は依然として解消されていない。
　
ソ．当審拒絶理由通知の（１−１６）で指摘した点について
　ここで指摘した記載は、請求項８における「前記決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを動作させ得られる結果値を前記標準サービスを要請したデバイスへ伝送する段階」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ソ−１．当審拒絶理由通知の（１−１６−１）で指摘した点
　依然として、「サービス役割によって」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、「要求される」を修飾しています。』と釈明されているが、係る事項は請求項８の記載に明確に反映されていない。
　また、この釈明は当審拒絶理由通知の（２−１９−１）に対する『「サービス役割によって」は、「伝送する」を修飾しています。』との釈明と矛盾する。
　したがって、当該不備は依然として解消されていない。
　
ソ−２．当審拒絶理由通知の（１−１６−２）で指摘した点
　依然として、「サービス役割」と「要求」や「動作」「伝送」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、役割がマスターであるか否かによって各モジュールが実行する処理が変わることから見て、処理の結果に影響を及ぼすものであります。すなわち、段落００５１〜００５３に説明されているように、サービス役割がマスターでなければ、ＯＳＧｉプラットフォームにエージェントでサービス役割が設定され、サービス役割がマスターであれば、マスターでサービス役割が設定されるとあり、これらの記載から、「サービス役割」は、ＯＳＧｉプラットフォームが行う処理の結果に影響するパラメータと解すべきものと思料します。』と釈明されているが、係る事項は請求項８に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても、「サービス役割」と「要求」や「動作」「伝送」等の処理の結果の対応関係は如何になっているのかは依然として明確でない。
　したがって、当該不備は依然として解消されていない。
　
ソ−３．当審拒絶理由通知の（１−１６−３）で指摘した点
　依然として、「所定のサービス支援のために」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「所定のサービス支援のために」は、「要求される」を修飾するものであります。』と釈明されているが、係る事項は請求項８の記載に明確に反映されていない。
　また、「所定のサービス支援のために」は、「要求される」を修飾すると仮定しても、「サービス支援のために要求」するとは何か（「サービス」による「支援」を「要求」すると言う意味なのか？「サービス支援」という処理の実行を「要求」すると言う意味なのか？「サービス支援」を目的として「要求」すると言う意味なのか？単に「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　したがって、当該不備は依然として解消されていない。
　
ソ−４．当審拒絶理由通知の（１−１６−４）で指摘した点
　依然として、「所定のサービス支援」と請求項７の「所定のサービス支援」との関係（同じものなのか？異なるものなのか？）が明確でない。
　この点に関し、意見書において、『原請求項８、９の「所定のサービス支援」は、同じもの、すなわち、ある標準プログラムが、ある応用プログラムを実行するために要求されることを示しています。』と釈明されているが、係る事項は請求項８の記載に明確に反映されていない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　したがって、当該不備は依然として解消されていない。
　
ソ−５．当審拒絶理由通知の（１−１６−５）で指摘した点
　依然として、発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００４２】【００６４】では「デバイス」へ「伝送」するとの表現はしていない。）
　この点に関し、意見書において、『段落００４２では、エージェント（モジュール）へ伝送し、段落００６４では、エージェントモジュールへ伝送すると表現されていますが、これらの実施形態に記載されたエージェントモジュールは、ハードウェアとしては、応用プログラムを実行しようとするデバイスでありますので、原請求項９に対応する請求項８の記載は、段落００４２、００６４の表現と矛盾するものではないと思料します。』と釈明されているが、明確な対応付けができないことに付いての釈明がなされていない。
　したがって、当該不備は依然として解消されていない。
　
　
タ．当審拒絶理由通知の（１−１８）で指摘した点について
　ここで指摘した記載は、請求項９における「前記決定されるサービス役割を設定し、前記ネットワーク上のデバイスに知らせる段階をさらに含む」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
タ−１．当審拒絶理由通知の（１−１８−１）で指摘した点
　依然として、「前記決定されるサービス役割」とは何を意味するのか（前記「サービス役割を決定する段階」で「決定」済みの「サービス役割」のことなのか？これから「サービス役割を決定する段階」で「決定」が予定される「サービス役割」のことなのか？）が明確でない。
　この点に関し、意見書において、『原請求項１１に対応する請求項９における「決定されるサービス役割」は、「すでに決定されたサービス役割」を意味するものであります。』と釈明されているが、係る事項は請求項９に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
タ−２．当審拒絶理由通知の（１−１８−２）で指摘した点
　依然として、「サービス役割を設定」とは如何なる処理なのか（「サービス役割」を「決定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？レジスタ等に記憶することを意味するのか？どこ（自デバイス内？他のデバイス内？）に設定するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割を設定する」は、デバイス内に自身のサービス役割を設定することを意味するものであります』と釈明されているが、係る事項は請求項９に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
タ−３．当審拒絶理由通知の（１−１８−３）で指摘した点
　依然として、何を「知らせる」のか（「サービス役割」を知らせるのか「サービス役割を設定」した旨を知らせるのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」を知らせるものであります。』と釈明されているが、係る事項は請求項９に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
タ−４．当審拒絶理由通知の（１−１８−４）で指摘した点
　依然として、「設定し」「知らせる」とは如何なる意味なのか（「設定」をした後に「知らせる」のか？「設定」をすることで「知らせる」ことがなされると言う意味なのか？）が明確でない。
　この点に関し、意見書において、『「設定」する以前の段階では、ＯＳＧｉプラットフォームの役割がマスターであるか否かが定まっておらず、設定の後、設定された役割に応じて、標準サービスを要求する処理等が行われています。したがって、「設定」した後に「知らせる」と解すべきものと思料します。』と釈明されているが、係る事項は請求項９に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
タ−５．当審拒絶理由通知の（１−１８−５）で指摘した点
　依然として、「前記ネットワーク上のデバイス」とはどのデバイスなのか（「所定のネットワークに連結されたデバイス」のことなのか？「システムリソース情報」の「収集」元の「デバイス」のことなのか？「前記ネットワーク」に接続されている他の全ての「デバイス」のことなのか？）が明確でない。
　この点に関し、意見書において、『「前記ネットワーク上のデバイス」は、「前記ネットワークに接続された全てのデバイス」を意味しています。』と釈明されているが、係る事項は請求項９に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、この釈明は、当審拒絶理由通知の（１−６−２）に対する『原請求項３に対応する請求項２の「前記ネットワーク上のデバイス」は、「自分」以外の「他のデバイス」を意味しています。』と釈明とも、当審拒絶理由通知の（２−２５−４）に対する『「ネットワーク上で動作するネットワークデバイス」は、自身以外の全部のデバイスと解すべきものと思料します。』との釈明と相違する。
　したがって、当該不備は依然として解消されていない。
　
　
チ．当審拒絶理由通知の（１−１９）で指摘した点について
　ここで指摘した記載は、請求項１０における「前記決定されるサービス役割によって所定の標準サービス提供のために指定されるデバイスにプロキシ情報を要請して前記デバイスのプロキシ情報を設定する段階をさらに含む」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
チ−１．当審拒絶理由通知の（１−１９−１）で指摘した点
　依然として、「前記決定されるサービス役割によって」は、何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『原請求項１２に対応する請求項１０における「決定されるサービス役割によって、」は、サービス役割がマスターか否かによっての意味であり、実施形態を参照すれば、マスターでないエージェントモジュールにおいて、応用プログラムから標準サービスの要請があると（図４のＳ１３）、その要請のメッセージは変換され（Ｓ１４）、サービス処理要請がマスターへ送られ（Ｓ１５）、さらに、その要請が標準サービス要請に変換されて（Ｓ１７）、標準サービスが要請され（Ｓ１８）、要請に応じて受信された標準サービスがエージェントモジュールへ送られます（Ｓ２２）。したがって、「決定されるサービス役割によって、」は、「要請して」を修飾するものであります。』と釈明されているが、「決定されるサービス役割によって」が「要請して」を修飾するものである点は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、段落【００５９】【図４】の記載によれば、「プロキシ情報」の設定は「サービスプロキシ設定」のステップＳ１２で行っており、Ｓ１３〜Ｓ２２のステップで「プロキシ情報」の設定を行っているわけではないので、図４のＳ１３〜Ｓ２２に関する記載は、請求項１０の「決定されるサービス役割によって」が「要請して」を修飾するものであることの根拠にはならず、該意見書の釈明は明らかに失当である。
　また、この釈明は当審拒絶理由通知の（２−２５−１）に対する『「決定されるサービス役割によって」は、「設定する」を修飾しています。』との釈明と矛盾し、何れの釈明が正しいのか明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
チ−２．当審拒絶理由通知の（１−１９−２）で指摘した点
　依然として、「サービス役割」と「要請」や「設定」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『上記（１−１９−１）に対する説明にあるように、サービス役割はパラメータ、あるいは条件と解すべきであります。原請求項１２（請求項１０）の場合、主体となるのは、原段落００６０（段落００５９）に記載されているように、エージェントモジュールであります。すなわちエージェントモジュールは、マスターエージェントモジュールのプロキシ情報を検索し、エージェントモジュールは、そのプロキシ情報をマスターエージェントモジュールに要請して受信したプロキシ情報を設定していますので、エージェントモジュールと解すべきものであります。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても、「サービス役割」と「要請」や「設定」等の処理の結果の対応関係は如何になっているのかは依然として明確でない。
　したがって、当該不備は依然として解消されていない。
　
チ−３．当審拒絶理由通知の（１−１９−３）で指摘した点
　依然として、この「段階」において「前記決定されるサービス役割」は「要請して」や「設定する」に如何に関与するのか（「サービス役割」によって「設定」内容等が変わるのか？「サービス役割」によって「プロキシ情報」が変わるのか？）が明確でない。
　この点に関し、意見書において、『原請求項１２（請求項１０）は、役割がマスターでない場合の処理を示しており、原請求項１２のみにおいては、このサービス役割が変わることはありません。したがって、サービス役割によってプロキシ情報が変わることはなく、エージェントモジュールである限り、マスターエージェントモジュールへプロキシ情報を要請することに変わりありません。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、該意見書の記載を参酌しても、「前記決定されるサービス役割」が「要請して」や「設定する」に如何に関与するのかは依然として明確でない。
　したがって、当該不備は依然として解消されていない。
　
チ−４．当審拒絶理由通知の（１−１９−４）で指摘した点
　依然として、「所定の標準サービス提供のために」は何を修飾するのか（「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「所定の標準サービス提供のために」は、「要請する」を修飾しています。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、この意見書の釈明は当審拒絶理由通知の（１−７−３）に対する『「所定の標準サービス提供のために」は「指定される」を修飾されており、「指定されたデバイス」は、マスターエージェントモジュールとしての役割を果たすデバイスを意味しています。ここで、標準サービス提供のために指定されるデバイスは、マスターの役割のデバイスと解すべきものと思量します。』との釈明と相違しており、何れの釈明が正しいのか明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
チ−５．当審拒絶理由通知の（１−１９−５）で指摘した点
　依然として、「指定されるデバイス」とはどのデバイスなのか（請求項８で「連結」された「デバイス」のことなのか？「収集」された「デバイス」なのか？要請された「ＯＳＧＩサービスプラットフォーム」が設けられた「デバイス」なのか？これらとは別の（例えば、役割がマスターである）「デバイス」なのか？）が明確でない。
　この点に関し、意見書において、『原請求項１２（請求項１０）において「指定されるデバイス」は、マスターエージェントモジュールとしての役割を果たすＯＳＧｉプラットフォームであるデバイスであります。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
チ−６．当審拒絶理由通知の（１−１９−６）で指摘した点
　依然として、「前記デバイス」とはどのデバイスなのか（請求項８で「連結」された「デバイス」のことなのか？「収集」された「デバイス」なのか？要請された「ＯＳＧＩサービスプラットフォーム」が設けられた「デバイス」なのか？「指定されるデバイス」なのか？）が明確でない。
　この点に関し、意見書において、『「前記デバイス」は「指定されるデバイス」を修飾しています。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　したがって、当該不備は依然として解消されていない。
　
チ−７．当審拒絶理由通知の（１−１９−７）で指摘した点
　依然として、「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？「プロキシ」を利用するために必要な情報なのか？）が明確でない。
　この点に関し、意見書において、『「プロキシ情報」は、標準サービス提供のために指定されるデバイス、すなわち、マスターの役割を有するデバイスを特定し、このデバイスをプロキシとして動作させるための情報と解すべきものであります。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、この意見書の釈明は当審拒絶理由通知の（１−７−６）に対する『原段落００５７、００５８には、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されています。したがって、ご指摘の「プロキシ情報」はプロキシであることを示す情報と解すべきものと思料します。』との釈明とも、当審拒絶理由通知の（１−１１−４）に対する『図４に示された処理は、多くのサービスエージェントモジュールのうち、いずれかのサービスエージェントモジュールからサービスの要請があった場合に、そのサービスエージェントモジュールへ標準サービスを提供する一連の処理を示しています。このような一連の処理から見て、「プロキシ情報」は、サービスを要請したサービスエージェントモジュールを特定するためのデータ、例えばＩＰアドレスなどを意味すると解すべきものと思料します。』との釈明とも相違し、何れの釈明が正しいのか明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
チ−８．当審拒絶理由通知の（１−１９−８）で指摘した点
　依然として、「指定されるデバイスにプロキシ情報を要請して」とは如何なる意味なのか（「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」するのか？「指定されるデバイス」に「プロキシ情報」を「指定されるデバイス」内に設定するように「要請」するのか？）が明確でない。
　この点に関し、意見書において、『拒絶理由通知のご認定の通り、「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」する　と解すべきものであります。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　したがって、当該不備は依然として解消されていない。
　
チ−９．当審拒絶理由通知の（１−１９−９）で指摘した点
　依然として、「前記デバイスのプロキシ情報を設定する。」とは如何なる意味なのか（「前記デバイス」に関連する「プロキシ情報」をどこかに設定するのか？「前記デバイス」内の「プロキシ情報」格納部に所定値を設定するのか？）が明確でない。
　この点に関し、意見書において、『本発明では、プロキシ情報はマスターエージェントモジュールへ標準サービス要請情報を伝送することに利用されるものです。したがって、プロキシ情報はエージェントモジュールの役割をするデバイスに設定されるものであります。』と釈明されているが、係る事項は請求項１０に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　また、この意見書の釈明は当審拒絶理由通知の（１−７−８）に対する『原段落００５７、００５８の記載を参酌すれば、「前記デバイス」に関連する「プロキシ情報」を自身のサービス役割設定部に設定するものと思料します。』との釈明と相違し、何れの釈明が正しいのか明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
チ−１０．当審拒絶理由通知の（１−１９−１０）で指摘した点
　依然として、発明の詳細な説明における表現と異なっており、明確な対応付けができない。（段落【００３８】では「決定されるサービス役割によって・・・知らせ」と表現している。また段落【００５６】では「マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」と表現している。）
　この点に関し、意見書において、『段落００３８には、「標準サービス提供のために指定されるデバイスにプロキシ情報を要請して該当デバイスのプロキシ情報を設定する」と記載されており、この記載によれば、標準サービスは、マスターであれ、エージェントであれ、いずれもデバイスにも保存されています。ただし、利用される標準サービスがマスターに保存されているだけであります。』と釈明されているが、発明の詳細な説明における表現と異なっており、明確な対応付けができないことに付いての釈明がなされていない。
　また、段落【００３８】には、「標準サービス提供のために指定されるデバイスにプロキシ情報を要請して該当デバイスのプロキシ情報を設定する」との記載はない。
　したがって、当該不備は依然として解消されていない。
　
　
ツ．当審拒絶理由通知の（１−２１）で指摘した点について
　ここで指摘した記載は、請求項１１における「前記標準サービスを外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ要請する段階は、前記標準サービスが要請されると、前記標準サービス
を要請する
マスターエージェントモジュールである
　前記受信される標準サービス要請情報によって前記デバイスで該当する標準サービスを動作させる段階と、
　前記標準サービスを動作させ得られる結果値を前記標準サービスを要請した
エージェントモジュールであるデバイスへ伝送
　
ツ−１．当審拒絶理由通知の（１−２１−１）で指摘した点
　依然として、「前記標準サービスを外部指定された」における「前記標準サービスを」は、何を修飾するのか（「外部指定された」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『原請求項１４に対応する請求項１１における「前記標準サービスを外部指定された」における「外部指定され」は、標準サービスを修飾しており、自身が決定するのではなく、マスターかエージェントかの役割が「外部から」指定されることによって、標準サービスをマスターに要請するか否かが判断されています。』と釈明されているが、「前記標準サービスを」が何を修飾するのかの釈明はなされていない。
　したがって、当該不備は依然として解消されていない。
　
ツ−２．当審拒絶理由通知の（１−２１−２）で指摘した点
　「前記デバイス」とはどのデバイスか（「所定のネットワークに連結されたデバイス」のことか？「システムリソース情報」の「収集」元の「デバイスから」のことか？「所定のサービス支援のために要求される標準サービスを外部指定されたデバイス」のことか？「前記標準サービス提供のために指定されるマスターエージェントモジュールであるデバイス」のことか？）が明確でない。
　この点に関し、意見書において、『「前記デバイス」および「前記標準サービスを要請したデバイス」は、いずれもマスターでないエージェントモジュールであるデバイスであります。』と釈明されているが、「マスターでないエージェントモジュールであるデバイス」なる記載が「前記」されているわけではない。
　したがって、当該不備は依然として解消されていない。
　
　
テ．当審拒絶理由通知の（１−２２）で指摘した点について
　ここで指摘した記載は、請求項１２における「前記標準サービス要請情報は、前記標準サービス提供のために指定されるデバイスのプロキシ情報を利用して伝送される」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
テ−１．当審拒絶理由通知の（１−２２−１）で指摘した点
　依然として、「前記標準サービス提供のために指定されるデバイスのプロキシ情報」とは、何処の如何なる情報を意味するのか（「前記標準サービス提供のために指定されるデバイス」とはどのデバイスを意味するのか？「・・・デバイスの」とは該デバイスから取得した情報を意味するのか？該デバイスに記憶される情報を意味するのか？該デバイスを特定する情報を意味するのか？）が明確でない。
　この点に関し、意見書において、『図１の符号１０は、ＯＳＧｉサービスプラットフォームを意味し、図２の符号１００は、サービスエージェントモジュールを意味します。なお、本願発明の詳細な説明には、「……ＯＳＧｉサービスプラットフォームに具備されるサービスエージェントモジュール……」と記載されています。したがって、図１の符号１０に図２の符号１００が含まれるものと理解することができます。
　（１−２２−１）
　原請求項１５に対応する請求項１２における「標準サービスの提供のために指定されるデバイスのプロキシ情報」は、標準サービスが搭載されたいずれかのＯＳＧｉプラットフォームを特定するための情報を意味しています。』と釈明されているが、係る事項は請求項１２に係る発明の発明特定事項として明確に記載されているものではない。
　また、係る事項は発明の詳細な説明から明確に把握し得るものでもない。
　したがって、当該不備は依然として解消されていない。
　
ト．小結
　以上のように、本願の請求項１〜１２には、依然として、その意味や他の発明特定事項との関連の不明確な記載、発明の詳細な説明と整合しない記載が多数ある。
　このため、請求項１〜１２に係る発明は、その範囲を明確に把握し得るものではなく、明確でない。したがって、本願特許請求の範囲の記載は特許法第３６条第６項第２号に規定する要件（明確性要件）を満たしていない。
　また、請求項１〜１２に係る発明は、依然として、発明の詳細な説明に記載したものでない。したがって、本願特許請求の範囲の記載は特許法第３６条第６項第１号に規定する要件（サポート要件）を満たしていない。
　さらに、このため、本願の発明の詳細な説明は、当業者が請求項１〜１２に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、請求項１〜１２に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものでもあるから、特許法第３６条第４項第１号に規定する要件（実施可能要件及び委任省令要件）を満たしていない。
　
　
（２）発明の詳細な説明の記載について
　次に、発明の詳細な説明の記載についての記載不備であるところの、当審拒絶理由通知の（２）で指摘された点について検討する。
　
ア．当審拒絶理由通知の（２−７）で指摘した点について
　　ここで指摘した記載は、段落【００１５】の「
自身に代わって
実行してもらうよう
標準サービスを登録することができないといった
　したがって、当該不備は依然として解消されていない。
　
イ．当審拒絶理由通知の（２−１１）で指摘した点について
　ここで指摘した記載は、段落【００２０】における「また、本発明は、
各ＯＳＧｉプラットフォームに対して決定された役割に応じて、指定されたデバイスのＯＳＧＩサービスプラットフォームを通じて、必要な標準サービスを
　
　
イ−１．当審拒絶理由通知の（２−１１−２）で指摘した点
　依然として、「決定された役割」とは何か（「決定された」「サービス役割」のことか？「サービス役割」とは別の役割なのか？）が明確でない。
　なお、意見書においては、何らこの点に関する釈明がなされていない。
　
ウ．当審拒絶理由通知の（２−１３）で指摘した点について
　ここで指摘した記載は、段落【００２２】における「マスターは、所定の標準サービスに対して高いシステムリソース情報を有するデバイスとして、該当標準サービスを提供するように定義され、マスターのＯＳＧＩサービスプラットフォームを
経由して
　
ウ−１．当審拒絶理由通知の（２−１３−１）で指摘した点
　依然として、「高い」の意味（何が「高い」ことを意味するのか？）が明確でない。
　この点に関し、意見書において、『（２−１３−１）、（２−１３−２）
　原段落００２２を下記の通り補正することにより、拒絶理由が解消されたものと思量します。高いシステムリソースとは、一般に、多くの標準サービスを搭載しているという意味に解すべきものと思料します。しかしながら、実行しようとするアプリケーションによって、必要な標準サービスも様々であることから、役割決定に際して、実行しようとするアプリケーションが必要とする標準サービスを多く保有している場合をシステムリソースが「高い」と表現しています。したがって、システムリソースが「高い」か否かは、単に搭載された標準サービスの数の多少によらず、実行しようとするアプリケーションに必要とされる標準サービスを多く搭載しているか否かによって「高い」か否かの判断を行うと解すべきものと思料します。また、「通じて」を「経由して」と補正することにより不明瞭な記載は解消されたものと思料します。「マスターは、所定の標準サービスに対して高いシステムリソース情報を有するデバイスとして、該当標準サービスを提供するように定義され、マスターのＯＳＧＩサービスプラットフォームを経由して提供される指定された標準サービスを利用して所定のサービス支援のために要求される標準サービスを提供するデバイスで定義される。」』と釈明されているが、係る事項は該段落の記載から把握し得るものではない。（当初明細書からも導き出し得るものではない、）
　したがって、当該不備は依然として解消されていない。
　
ウ−２．当審拒絶理由通知の（２−１３−３）で指摘した点
　依然として、「・・・デバイスで定義される。」の意味（「・・・デバイス」が動作して何かの「定義」をするのか？「・・・デバイス」として「定義」がされる旨の意味か？）が明確でない。
　この点に関し、意見書において、『段落００２２は、マスターの役割を果たすための条件(資格)とその機能を定義しており、マスターとして認定される条件として、高いシステムリソース情報を有するデバイスであることが必要とされ、マスターの機能として標準サービスを提供することである旨が定義されています。』と釈明されているが、係る事項を該段落の記載から把握し得るものではない。（当初明細書からも導き出し得るものではない、）
　したがって、当該不備は依然として解消されていない。
　
エ．当審拒絶理由通知の（２−１４）で指摘した点について
　ここで指摘した記載は、段落【００２３】における「このように決定されるサービス役割が
マスターであるか否か
各デバイスのＯＳＧｉプラットフォームが、
　
エ−１．当審拒絶理由通知の（２−１４−２）で指摘した点
　依然として、「サービスエージェントモジュールはマスターエージェントモジュール又はエージェントモジュールで設定される。」の意味（「マスターエージェントモジュール」又は「エージェントモジュール」が主体となって「サービスエージェントモジュール」を「設定」すると解して良いのか？「サービスエージェントモジュール」が「マスターエージェントモジュール」又は「エージェントモジュール」として「設定」されると言う意味か？）が明確でない。
　この点に関し、意見書において、『原段落００２３を下記の通り補正することにより、拒絶理由が解消されたものと思量します。』と釈明されているが、依然として該記載の意味は不明のままである。
　したがって、当該不備は依然として解消されていない。
　
オ．当審拒絶理由通知の（２−１５）で指摘した点について
　ここで指摘した記載は、段落【００２４】における「本発明
の一実施例
デバイスが
　
オ−１．当審拒絶理由通知の（２−１５−４）で指摘した点
　依然として、「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、この処理では、「サービス役割がエージェントモジュールである場合には」と解すべきであり、この場合、「標準サービスを外部指定されたデバイスのＯＳＧＩサービスプラットフォーム」すなわち、役割がマスターであるＯＳＧｉサービスプラットフォームへ処理要請しています。』と釈明されているが、係る事項を該段落の記載から把握し得るものではない。また、該釈明を参酌しても、「サービス役割によって」が何を修飾するのかは依然として不明である。
　したがって、当該不備は依然として解消されていない。
　
オ−２．当審拒絶理由通知の（２−１５−５）で指摘した点
　依然として、「サービス役割」と「要求」や「処理要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、ステップＳ２で説明されているように、マスターであるか否かによって各モジュールが実行する処理が変わることから、処理の条件にかかわるものでありますので、「サービス役割」は、処理の結果に影響を及ぼすものであります。すなわち、段落００５１〜００５３に説明されているように、サービス役割がマスターでなければ、ＯＳＧｉプラットフォームにエージェントでサービス役割が設定され、サービス役割がマスターであれば、マスターでサービス役割が設定されるとあり、これらの記載から、「サービス役割」は、ＯＳＧｉプラットフォームが行う処理の結果に影響するパラメータと解すべきものと思料します。』と釈明されているが、係る事項を該段落の記載から把握し得るものではない。また、該釈明を参酌しても、「サービス役割」と該「要求」や「処理要請」等の処理結果の対応関係は依然として不明である。
　したがって、当該不備は依然として解消されていない。
　
　
カ．当審拒絶理由通知の（２−１６）で指摘した点について
　ここで指摘した記載は、段落【００２５】における「また、本発明の一実施例によるサービス要請処理部は、サービス役割によって要求される標準サービスを指定されたデバイスのＯＳＧＩサービスプラットフォームへ伝送するように
前記標準サービスを要請する情報
　
カ−１．当審拒絶理由通知の（２−１６−１）で指摘した点
　依然として、「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「伝送する」を修飾するのか？「変換する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、サービス役割がマスターか否かによっての意味であり、明細書の段落００４０の記載、「サービス役割がマスターであれば、サービス要請情報を分析して当該サービスの提供のために要求される標準サービス要請情報を変換し、サービス役割がエージェントであれば、マスターへサービス要請情報を伝送するようサービス要請情報を変換する。」を参酌すれば、「変換する」を修飾するものと思料します。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
カ−２．当審拒絶理由通知の（２−１６−２）で指摘した点
　依然として、「サービス役割」と「要求」や「伝送」「変換」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『段落００２５は、サービス役割がマスターでない場合の処理を説明したものであり、役割がマスターでない場合には、標準サービス要請情報を、指定されたデバイスのＯＳＧｉプラットフォームへ標準サービスを伝送するように変換するといサービス要請処理部の機能を示しています。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
カ−３．当審拒絶理由通知の（２−１６−３）で指摘した点
　依然として、「標準サービスを」は何を修飾するのか（「指定された」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「標準サービスを」は「伝送するように」を修飾しています。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　仮に「標準サービスを」「伝送する」を修飾すると解した場合、「標準サービスを」「伝送する」とは如何なる処理を行うことを意味するのかが明確でない。（「標準サービス」自体は「伝送する」ことができるものではないので、技術的にみて不適切な表現である。）
　したがって、当該不備は依然として解消されていない。
　
カ−４．当審拒絶理由通知の（２−１６−５）で指摘した点
　依然として、「指定された」は何を修飾するのか（「デバイス」を修飾するのか？「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「指定された」は「デバイス」を修飾しています。』と釈明されているが、その根拠が説明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
カ−５．当審拒絶理由通知の（２−１６−６）で指摘した点
　依然として、「前記サービス要請処理部は・・・指定されたデバイスのＯＳＧＩサービスプラットフォームに伝送」とは如何なる意味なのか（「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」から「指定」され「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？「データ変換部」が「デバイス」又は「ＯＳＧＩサービスプラットフォーム」を「指定」して「デバイス」又は「ＯＳＧＩサービスプラットフォーム」へ伝送するのか？（即ち「指定」の主体））が明確でない。
　この点に関し、意見書において、『指定されたデバイス（ＯＳＧｉプラットフォーム）へ伝送する解すべきものであります。』と釈明されているが、当該記載を参酌しても、「指定」の主体が不明である。
　したがって、当該不備は依然として解消されていない。
　
カ−６．当審拒絶理由通知の（２−１６−７）で指摘した点
　依然として、「指定されたデバイス」の「デバイス」とはどのデバイスなのか（「装置」とは如何なる関係にあるのか？）が明確でない。上記「決定」された「サービス役割」とは如何なる関係なのかも明確でない。
　この点に関し、意見書において、『指定されたデバイスは、標準サービスを要求しているエージェントモジュールとしてのデバイスと解すべきものであります。』と釈明されているが、その根拠が釈明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
カ−７．当審拒絶理由通知の（２−１６−８）で指摘した点
　依然として、「前記標準サービスを要請する情報」とあるが、これは、何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　この点に関し、意見書において、『また、この情報は、マスターがデバイスから受け取った要請の情報と解すべきものであります。段落００３７を参照すれば、マスターエージェントモジュール（マスター）か、エージェントモジュール（マスターでない）かのいずれかであります。そして、この役割により、サービス要請があった場合の処理が、以下のように相違しています。すなわち、段落００３９に記載されているように、サービス要請情報が提供されると、各エージェントモジュールのサービス役割設定部１１０により、マスターの役割が設定された場合には、サービス要請処理部１３０により、内部的に提供すべきものと判断がされて、段落００４０に記載されているように、標準サービスを動作させるように、データ変換部１３１によって前記サービス要請情報が変換されます。これに対して、マスターの役割が設定されない場合には、段落００４０に示すように、サービス要請処理部１３０のデータ変換部により、前記サービス要求情報が、マスターの役割を有する他のサービスプラットフォームへ標準サービスを要求するよう変換されます。』と釈明されているが、係る事項は該段落には明示されていない。また、該釈明を参酌しても、「前記標準サービスを要請する情報」が如何なる情報のなのか（「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）は明確でなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
キ．当審拒絶理由通知の（２−１８）で指摘した点について
　ここで指摘した記載は、段落【００２６】における「本発明の一実施例によるネットワーク上のサービス共有のための方法は、
デバイスが
された際に、複数のＯＳＧｉプラットフォームの間で
を共有するために
決定された
　
キ−１．当審拒絶理由通知の（２−１８−２）で指摘した点
　依然として、何の（連結されたデバイスの？、連結されたデバイス以外のデバイスの？ネットワーク上の全てのデバイスの？予め決められている特定のデバイスの？これらのデバイス内のＯＳＧＩサービスプラットフォームの？これらのデバイス内のサービス要請処理部の？）「所定の標準サービス共有のためのサービス役割」を決定するのかが不明である。
　この点に関し、意見書において、『上記の補正により不明瞭な記載が解消されたものと思料します。』と釈明されているが、依然として、何のサービス役割を決定するのかは不明である。
　したがって、当該不備は依然として解消されていない。
　
キ−２．当審拒絶理由通知の（２−１８−４）で指摘した点
　依然として、「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、「要請する」を修飾しており、役割がマスターでない場合には、標準サービスをマスターエージェントモジュールへ要請しています。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
キ−３．当審拒絶理由通知の（２−１８−５）で指摘した点
　依然として、「サービス役割」と「要求」や「外部指定」「要請」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、サービス役割がマスターか否かによっての意味であり、サービス役割というパラメータによって処理結果が影響される（標準サービスをマスターエージェントモジュールへ要請するか否かに影響する）ものであります。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　また、該釈明を参酌しても、「サービス役割」と該「要求」や「外部指定」「要請」等の処理結果の対応関係は依然として不明である。
　したがって、当該不備は依然として解消されていない。
　
キ−４．当審拒絶理由通知の（２−１８−６）で指摘した点
　依然として、「標準サービスを外部指定」の「標準サービスを」は何を修飾するのか（「外部指定され」を修飾するのか？「要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「標準サービスを」は「要請する」を修飾するものであります。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　なお、この釈明は当審拒絶理由通知の（１−１４−３）に対する『「標準サービスを」は、「外部指定され」を修飾しています。』との釈明と矛盾する。
　したがって、当該不備は依然として解消されていない。
　
キ−５．当審拒絶理由通知の（２−１８−７）で指摘した点
　依然として、「外部指定された」とは如何なる意味なのか（「外部」から「指定」されることの意味なのか？「外部」に対して「指定」することなのか？）が明確でない。
　この点に関し、意見書において、『「外部指定された」は、「外部」から「指定」されるという意味であり、デバイス自身の意思にかかわらず、所定のルールによって、例えばシステムリソースの状況等によって決定されるという意味であります。』と釈明されているが、その根拠が釈明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載は見当たらない。
　また、この釈明は当審拒絶理由通知の（１−３−４）に対する釈明とも、同（１−１４−４）に対する釈明とも相違する。
　したがって、当該不備は依然として解消されていない。
　
キ−６．当審拒絶理由通知の（２−１８−８）で指摘した点
　依然として、「外部指定された」は何を修飾するのか（「デバイス」を修飾するのか？　「ＯＳＧＩサービスプラットフォーム」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『デバイスは、ＯＳＧｉプラットフォームとして機能するハードウェアを意味しており、外部指定されるのは、ＯＩＳＧｉプラットフォームとしてのデバイスと解すべきものと思料します。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　また、この釈明は当審拒絶理由通知の（１−３−５）に対する釈明とも、同（１−１４−５）に対する釈明とも整合しない。
　
キ−７．当審拒絶理由通知の（２−１８−９）で指摘した点
　依然として、「外部指定」の「外部」とは何の外部を意味するのか（アプリケーションなどの「標準サービス」の外部の事なのか？「サービス役割設定部」等の「サービス要請処理部」の外部のことなのか？他の「デバイス」の事なのか？）が明確でない。
　この点に関し、意見書において、『「外部」とは、「外部」から「指定」されるという意味であり、デバイス自身の意思にかかわらず、所定のルールによって、例えばシステムリソースの状況等によって決定されるという意味であります。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　また、この釈明は当審拒絶理由通知の（１−３−６）に対する『「外部」は、標準サービスの外部を意味しています。』との釈明とも、同（１−１４−６）に対する『「外部指定」の「外部」は、他のデバイスを示すものであります。』との釈明とも矛盾する。
　したがって、当該不備は依然として解消されていない。
　
キ−８．当審拒絶理由通知の（２−１８−１０）で指摘した点
　依然として、「所定のサービス支援のために」は何を修飾するのか（「要求される」を修飾するのか？「外部指定され」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「所定のサービス支援のために」は、「要求される」を修飾しており、全体として、あるＯＳＧｉプラットフォームにおいて実行しようとするサービスを支援するために要求される標準サービスが、マスターとしてのＯＳＧｉプラットフォームへ要請されると解すべきものと思料します。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　なお、この釈明は当審拒絶理由通知の（１−１４−７）に対する『本願の前提となる従来技術についての段落００１１、００１２に記載されているように、一般に、「所定のサービス支援のために」様々な標準サービスが必要とされ、その標準サービスが各ＯＳＧｉプラットフォームに搭載されています。これを前提とすれば、「要求される」は「標準サービス」を修飾すると解するのが妥当であると思料します。』との釈明とも一致しない
　また、「所定のサービス支援のために」が「要求される」を修飾していると仮定しても、「サービス支援のために要求」するとは何か（「サービス」による「支援」を「要求」すると言う意味なのか？「サービス支援」という処理の実行を「要求」すると言う意味なのか？「サービス支援」を目的として「要求」すると言う意味なのか？単に「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　したがって、当該不備は依然として解消されていない。
　
キ−９．当審拒絶理由通知の（２−１８−１１）で指摘した点
　依然として、「サービス支援」とは何か（「サービスを実行する」と同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「要求」することと同義なのか？異義なのか？後者であるならば何がどう異なるのか？「サービス」を「指定」することと同義なのか異義なのか？後者であるならば何がどう異なるのか？）が明確でない。
　この点に関し、意見書において、『「サービス支援」とは、「サービスを実行するために必要な」と解すべきものであります。なお、サービスを「実行」するには、その前提となる標準サービスの「支援」が必要とされ、この標準サービスを要請することを意味しています。また、「外部指定」とは、マスターとして指定されたという意味に解すべきものと思量します。』と釈明されているが、係る事項は該段落には明示されていない。
　なお、この釈明は当審拒絶理由通知の（１−３−８）に対する『「サービス支援」は、標準サービスによるサービスの支援を意味し、「サービスを実行」は、この標準サービスの支援を前提として、アプリケーションサービスを実行することを意味しています。』との釈明とも、当審拒絶理由通知の（１−１４−８）に対する『「サービス支援」とは、所定のアプリケーションを実行するために必要とされる標準サービスを云い、マスターの場合には、自身で直接標準サービスを搭載し、マスターでないエージェントモジュールの場合には、マスターへ標準サービスの伝送を要求しています。この処理は、段落００６２〜００６５にＳ１８〜Ｓ２５の各ステップの処理として記載された通りであります。』との釈明とも相違し、何れの釈明が正しいのかも明確に判断できない。
　したがって、当該不備は依然として解消されていない。
　
キ−１０．当審拒絶理由通知の（２−１８−１２）で指摘した点
　依然として、段落【００４１】や段落【００６１】の実施例の記載と整合しない。（段落【００４１】や段落【００６１】には「ＯＳＧＩサービスプラットフォームへサービスを要請する」旨の記載は無い。）
　この点に関し、意見書において、『原段落００６２には、「マスターエージェントモジュールへ伝送する」と記載があり、このマスターエージェントモジュールは、マスターの役割を有するＯＳＧｉプラットフォームを意味しますので、段落００２６の記載は実施例と整合するものと思料します。』と釈明されているが、この釈明の根拠（どこの記載からこのようなことが導き出されるのか？）が説明されておらず、その正否も定かでない。
　なお、この釈明は、当審拒絶理由通知の（１−３−１３）に対する『原段落００４２、００６２に直接的に記載されてはいませんが、図４を参照した原段落００５６〜００６７に記載されたエージェントモジュール、マスターエージェントモジュール、間の通信処理によれば、Ｓ１５において、エージェントモジュールがマスターエージェントモジュールとしてのデバイスへ標準サービスを要請し、Ｓ１８において、マスターエージェントモジュールとしてのデバイスが自身の有する標準サービスを要請しており、このことから、「デバイスに対して処理要請する」点は明細書に記載されたものと思料します。』との釈明、すなわち「デバイス」を「マスターエージェントモジュール」「エージェントモジュール」と同一視する説明とも整合しない。
　したがって、当該不備は依然として解消されていない。
　
ク．当審拒絶理由通知の（２−１９）で指摘した点について
　ここで指摘した記載は、段落【００２７】における「また、本発明の一実施例によるネットワーク上でのサービス共有のための方法は、決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを動作させて得られる結果値を前記標準サービスを要請したデバイスへ伝送する段階をさらに含むことを特徴とする。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ク−１．当審拒絶理由通知の（２−１９−１）で指摘した点
　依然として、「サービス役割によって」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、「伝送する」を修飾しています。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　また、この釈明は当審拒絶理由通知の（１−１６−１）に対する『「サービス役割によって」は、「要求される」を修飾しています。』との釈明と矛盾する。
　したがって、当該不備は依然として解消されていない。
　
ク−２．当審拒絶理由通知の（２−１９−２）で指摘した点
　依然として、「前記決定されるサービス役割」と「要求」や「動作」「伝送」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、ステップＳ２で説明されているように、マスターであるか否かによって各モジュールが実行する処理が変わることから、処理の条件にかかわるものでありますので、「サービス役割」は、処理の結果に影響を及ぼすものであります。すなわち、原段落００５２〜００５４に説明されているように、サービス役割がマスターでなければ、ＯＳＧｉプラットフォームにエージェントでサービス役割が設定され、サービス役割がマスターであれば、マスターでサービス役割が設定されるとあり、これらの記載から、「サービス役割」は、ＯＳＧｉプラットフォームが行う処理の結果に影響するパラメータと解すべきものと思料します。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　また、該意見書の記載を参酌しても、「サービス役割」と「要求」や「動作」「伝送」等の処理の結果の対応関係は如何になっているのかは依然として明確でない。
　したがって、当該不備は依然として解消されていない。
　
ク−３．当審拒絶理由通知の（２−１９−３）で指摘した点
　依然として、「所定のサービス支援のために」は、何を修飾するのか（「要求される」を修飾するのか？「動作させ」を修飾するのか？「得られる」を修飾するのか？「伝送する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス支援」とは、「サービスを実行するために必要な」と解すべきものであります。なお、サービスを「実行」するには、その前提となる標準サービスの「支援」が必要とされ、この標準サービスを要請することを意味しています。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
ク−４．当審拒絶理由通知の（２−１９−４）で指摘した点
　依然として、段落【００４２】【００６４】の実施例の記載と整合しない。（段落【００４２】【００６４】では「デバイス」へ「伝送」するとの表現はしていない。）
　この点に関し、意見書において、『原段落００４３は、エージェントの動作を示しこのエージェントは、マスターの役割でないＯＳＧｉプラットフォームとしてのデバイスを意味しています。また原段落００６５には、「マスターエージェントモジュールでは……」と、マスターエージェントモジュールが実行する処理についての記載があり、このマスターエージェントモジュールは、マスターの役割を有するＯＳＧｉプラットフォームを意味しますので、段落００２７の記載は実施例と整合するものと思料します。』と釈明されているが、『エージェントの動作を示しこのエージェントは、マスターの役割でないＯＳＧｉプラットフォームとしてのデバイスを意味しています。』との点が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
　
ケ．当審拒絶理由通知の（２−２０）で指摘した点について
　ここで指摘した記載は、段落【００２８】における「本発明によると、
所定のアルゴリズムを利用して決定されるサービス役割によって、
複数の
相互間で
　
ケ−１．当審拒絶理由通知の（２−２０−１）で指摘した点
　依然として、「決定されるサービス役割」と「共有」との関係（「決定されるサービス役割」が、「共有」に如何に関与するのか？「決定されるサービス役割」と言う物が主体となって「共有」を行うと解してよいのか？「サービス役割」と言うパラメータが「共有」に影響すると言う意味か？その場合、「前決定されるサービス役割」と該結果の対応関係は如何になっているのか？それとも、「前決定されるサービス役割」と言うパラメータを導入することによって「共有」が可能になると言う意味なのか？）が明確でない。
　この点に関し、意見書において、『サービス役割がマスターでないデバイスは、マスターエージェントモジュールへ標準サービスを要請し、この標準サービスを利用して所定のサービスを実行し、マスターエージェントモジュールにおいても、自身がサービスを実行するに際して自身が保有する標準サービスを利用することができます。このことから、マスターとマスターでないデバイス（ＯＳＧｉプラットフォーム）との間で標準サービスが共有されていると解すことができるものと思料します。』と釈明されているが、「決定されるサービス役割」が、「共有」に如何に関与するのか、「決定されるサービス役割」と言う物が主体となって「共有」を行うと解してよいのか、「サービス役割」と言うパラメータが「共有」に影響すると言う意味か、その場合、「前決定されるサービス役割」と該結果の対応関係は如何になっているのか、それとも、「前決定されるサービス役割」と言うパラメータを導入することによって「共有」が可能になると言う意味なのかは、依然として不明のままである。
　したがって、当該不備は依然として解消されていない。
　
　
コ．当審拒絶理由通知の（２−２２）で指摘した点について
　段落【００３１】〜【００４５】に、【図１】と【図２】を参照しての「本発明の一実施例」の説明がなされているが、依然として、【図２】に示される「装置」あるいは「サービスエージェントモジュール１００」が、【図１】に示される「従来ＯＳＧＩサービスプラットフォームの動作構造」中の何処にどう設けられるのか（デバイス２０の中に設けられるのか？１０の中にも設けられるのか？全てのデバイス内なのか？デバイス２０や１０とは別個のものとしてネットワークに接続されるのか？）の説明が、本願発明の詳細説明にも図面にも無い。
　従って、本願請求項１〜１５に係る発明の実施に際し、該「サービスエージェントモジュール１００」を何処にどう設ければよいのかを、本願の発明の詳細な説明及び図面の記載から理解しこれを再現することは、当業者と言えども不可能である。
　この点に関し、意見書において、『図1の符号１０は、ＯＳＧｉサービスプラットフォームを意味し、図２の符号１００は、サービスエージェントモジュールを意味します。なお、本願発明の詳細な説明には、「……ＯＳＧｉサービスプラットフォームに具備されるサービスエージェントモジュール……」と記載されています。したがって、図１の符号１０に図２の符号１００が含まれるものと理解することができます。』と釈明されているが、「図1の符号１０は、ＯＳＧｉサービスプラットフォームを意味」することの根拠が不明であり、また、かかる記載は明細書にはなく、係る事項が明細書に明示されているとは言えない。また、図１の符号１０、２０、及び、ネットワークによって構成されるシステムを「ＯＳＧｉサービスプラットフォーム」と称しているとの解釈もなりたち、必ずしも「図1の符号１０は、ＯＳＧｉサービスプラットフォームを意味」するとは言えない。したがって、該意見書の釈明の正否も定かでない。
　したがって、当該不備は依然として解消されていない。
　
　
サ．当審拒絶理由通知の（２−２３）で指摘した点について
　ここで指摘した記載は、段落【００３５】【００３６】における「サービス役割設定部１１０は、ネットワーク上で動作するデバイスから収集されるシステムリソース情報を利用して所定の標準サービス共有のためのサービス役割を決定する。」「即ち、サービス役割設定部１１０では、デバイスがネットワーク上に連結されると、発見メッセージ(Discovery　Message)をブロードキャスティングして応答メッセージで受信されるデバイスのシステムリソース情報を収集し、収集されたシステムリソース情報を利用して、サービス役割を決定する。」との記載に相当し、補正による実質的な変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
サ−１．当審拒絶理由通知の（２−２３−１）で指摘した点
　依然として、「デバイス」と「サービス役割設定部１１０」の関係（「ネットワーク上で動作するデバイス」や「連結される」「デバイス」とは別個に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」内に「サービス役割設定部１１０」があるのか？「連結される」「デバイス」内に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」及び「連結される」「デバイス」の全ての中に「サービス役割設定部１１０」があるのか？）が明確でない。
　この点に関し、意見書において、『サービス役割設定部１１０は、ネットワーク上で動作するデバイス内にあるものです。』と釈明されているが、係る事項は該段落には明示されていない。また、その根拠も釈明されていない。
　なお、この釈明通りであると仮定すると、「ネットワーク上で動作するデバイス内」の「サービス役割設定部１１０」が「ネットワーク上で動作するデバイス」即ち自デバイスから「システムリソース情報」を「収集」することになる。
　したがって、当該不備は依然として解消されていない。
　
サ−２．当審拒絶理由通知の（２−２３−２）で指摘した点
　依然として、段落【００３６】の「サービス役割設定部１１０では、デバイスがネットワーク上に連結されると、発見メッセージ(Discovery　Message)をブロードキャスティングして」の意味（「サービス役割設定部１１０」がポーリング等を行って新たな「デバイス」が「連結」されたことを発見し、発見した旨の「発見メッセージ」を「ブロードキャスティング」するのか？　「連結される」「デバイス」内に「サービス役割設定部１１０」があり、該「サービス役割設定部１１０」が自「デバイス」が「連結」された旨の「発見メッセージ」を「ブロードキャスティング」するのか？）が明確でない。
　この点に関し、意見書において、『デバイスがネットワーク上に連結されると、そのデバイスが発見メッセージという情報をネットワーク上の他のデバイスへブロードキャスティングし、このブロードキャスティングに対して、他のデバイスからの応答メッセージが発信され、この応答メッセージから、他のデバイスのシステムリソース情報を収集しています。』と釈明されているが、係る事項は該段落には明示されていない。また、その根拠も釈明されていない。
　また、この釈明は、請求項１の「デバイスが所定のネットワークに連結されると、前記デバイスから受け取った応答メッセージに含まれるシステムリソース情報を用いて・・・」との記載、請求項７の「所定のネットワークに連結されたデバイスについて、前記デバイスから収集されたシステムリソース情報を利用して・・・」との記載、当審拒絶理由通知の（１−２−１）に対する『段落００３６では、デバイスがネットワークに接続されると、サービス役割設定部１１０がブロードキャストする発見メッセージに対して、デバイスから応答メッセージが発信されると記載されています。サービス役割設定部１１０は、この応答メッセージに含まれるシステムリソース情報から、そのデバイスの仕様、性能等を認識し、それらに応じてサービス役割を決定しています。すなわち段落００３６によれば、サービス役割設定部１１０は、デバイスから受信したシステムリソース情報によって、このサービス役割設定部１１０を備える一つのサービスエージェントモジュール（装置）に対して、マスターエージェントモジュールもしくはエージェントモジュールのいずれかの役割を設定します。この段落［００３６］の記載から、デバイスは、ネットワークに接続されるとことによって応答メッセージを出力するものであって、応答メッセージに含まれるシステムリソース情報からサービス役割が決定される点から見て、デバイスが「共通」のものと解することができるものと思料します。』との釈明、当審拒絶理由通知の（１−１３−１）に対する『本発明は、図１に示された従来のＯＳＧＩサービスプラットフォームを改良したもので、本発明を実施するための最良の形態として、段落００３３には、図２を参照して、ネットワーク上でのサービス共有のためのサービス装置の構造が記載されています。すなわち、図１に示されたようなＯＳＧＩサービスプラットフォームが使用者デバイスの一部としてネットワークを介して通信するシステムにおいて、サービス共有（段落００１３で説明されたような標準サービスの重複登録を回避するための標準サービスの共有）の機能を果たす、例えば、実施形態におけるサービスエージェントモジュール１００において実行される処理に関するものであります。原請求項８は、サービスエージェントモジュールが有する機能としてのサービス役割決定部と、サービス要請処理部とが実行する処理を特定したものであります。』との釈明とも矛盾する。
　したがって、当該不備は依然として解消されていない。
　
サ−３．当審拒絶理由通知の（２−２３−３）で指摘した点
　依然として、「応答メッセージ」は何が送信するのか（「連結」された「デバイス」が送信するのか？「連結」された「デバイス」以外の「デバイス」も送信するのか？）が明確でない。
　この点に関し、意見書において、上記（２−２３−２）に対するものと共通の釈明がなされているが、係る事項は該段落には明示されていない。また、その根拠も釈明されていない。
　また、この釈明は、上記（２−２３−２）に関して示した、請求項１の記載、請求項７の記載、当審拒絶理由通知の（１−２−１）に対する釈明、当審拒絶理由通知の（１−１３−１）に対する釈明とも矛盾する。
　したがって、当該不備は依然として解消されていない。
　
サ−４．当審拒絶理由通知の（２−２３−４）で指摘した点
　依然として、「受信」は何が行うのか（「デバイス」とは別個に設けられた「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」あるいはその内部の「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」以外の「デバイス」あるいはその内部の「サービス役割設定部１１０」も行うのか？）が明確でない。
　この点に関し、意見書において、『上記収集されたシステムリソース情報は、発見メッセージを発信したデバイスのサービス役割設定部１１０において、所定のアルゴリズムに従って役割の設定に利用されます。なお、役割の設定は、発見メッセージを発見したデバイス自身が決定したとしても、他のデバイスとのネゴシエイションや、上位のサーバ等によって決定されたとしても、本願の本質的な動作に影響するものではないと思料します。すなわち、ネットワークに接続された複数のデバイスのシステムリソース情報を利用して、各デバイスの役割を設定することができれば、その役割に応じてその後の標準サービスの要請等の処理を行うことができるものであります。』と釈明されているが、「上記収集されたシステムリソース情報は、発見メッセージを発信したデバイスのサービス役割設定部１１０において、所定のアルゴリズムに従って役割の設定に利用され」る旨の根拠が釈明されていない。また、係る事項が該段落に明示されているとは言えない。
　また、この釈明は、上記（２−２３−２）に関して示した、請求項１の記載、請求項７の記載、当審拒絶理由通知の（１−２−１）に対する釈明、当審拒絶理由通知の（１−１３−１）に対する釈明とも矛盾する。
　したがって、当該不備は依然として解消されていない。
　
サ−５．当審拒絶理由通知の（２−２３−５）で指摘した点
　依然として、「デバイスのシステムリソース」とは何のシステムリソースなのか（「連結」された「デバイス」のシステムリソースのことなのか？「連結」された「デバイス」以外の「デバイス」のシステムリソースも含むのか？「デバイス」が連結されたネットワーク等を含む「システム」全体の「リソース」なのか？）が明確でない。
　この点に関し、意見書において、『「デバイスのシステムリソース」とは、連結された「デバイス」のシステムリソース情報のみならず、他の「デバイス」のシステムリソース情報を含むと解釈すべきものと思料します。すなわち、マスターの役割を果たすべきか否かを決定するには、ハードウェア資源として、あるいは、ソフトウェア資源（標準サービスを多く格納している等）システムリソースが相対的に「高い」かによって決定されるべきものでありますので、ここにいうシステムリソース情報は、単一のデバイスではなく、システムに接続された複数のデバイスのものであるべきと思料します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
サ−６．当審拒絶理由通知の（２−２３−６）で指摘した点
　依然として、「サービス役割を決定する」とは、何を決定することを意味するのか（「デバイス」とは別個に設けられた装置の「サービス役割」を「決定」することを意味するのか？　「連結」された「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」することを意味するのか？「連結」された「デバイス」以外の「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」しなおすことを意味するのか？）、何を基にどう決定するのか（自己のリソースを基に自己が提供可能な「標準サービス」を決定するのか？自己のリソースを基に自己がマスターになり得るか否かを決定するのか？他のデバイスのリソースを基にどのデバイスがどの標準サービスのマスターになるかを決定するのか？）が明確でない。
　この点に関し、意見書において、『連結されたデバイス自身のサービス役割と、他のデバイスの内、マスターの役割を果たすべきいずれかのデバイスを決定しているものと思料します。』と釈明されているが、その根拠が釈明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
シ．当審拒絶理由通知の（２−２４）で指摘した点について
　ここで指摘した記載は、段落【００３７】における「また、サービス役割設定部１１０は、決定されるサービス役割によって、サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する。」との記載に相当し、補正による実質的な変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
シ−１．当審拒絶理由通知の（２−２４−１）で指摘した点
　依然として、「サービス役割」と「設定」との関係（「サービス役割」が、「設定」に如何に関与するのか？「サービス役割」と言う物が「設定」を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが「設定」の結果に影響すると言う意味か？そうであるならば、「サービス役割」と該結果の対応関係は如何になっているのか？それとも、「サービス役割」と言うパラメータを「設定」すると言う意味なのか？）が明確でない。
　この点に関し、意見書において、『発明の詳細な説明は、新たに接続されたデバイスがサービスを実行する際の処理を説明しており、ここでは、サービス役割がマスターであるか否かによって、図３に示すようにその後の処理が変わります。すなわち、段落００３７は、サービス役割というパラメータを「マスター」か否かのいずれかに設定すると解釈すべきものと思料します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
シ−２．当審拒絶理由通知の（２−２４−２）で指摘した点
　依然として、ここで「設定」の対象となる「サービスエージェントモジュール」はどのモジュールなのか（「サービス役割」を「決定」した「サービスエージェントモジュール」なのか？他の「サービスエージェントモジュール」なのか？）が明確でない。
　この点に関し、意見書において、『設定の対象となるサービスエージェントモジュールは、新たにネットワークに接続されたデバイスであると思料します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
シ−３．当審拒絶理由通知の（２−２４−３）で指摘した点
　依然として、「サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する」とは如何なる処理を意味するのか（「マスターエージェントモジュール」もしくは「エージェントモジュール」と言うモジュールの動作によって、「サービスエージェントモジュール」内の何らかの設定状態を変更すると言う意味なのか？「サービスエージェントモジュール」を「マスターエージェントモジュール」もしくは「エージェントモジュール」と言うモジュールとして動作するように該「サービスエージェントモジュール」内の何らかの設定状態を変更すると言う意味なのか？他の「デバイス」内の何らかの機能実現手段を「マスターエージェントモジュール」もしくは「エージェントモジュール」と言うモジュールとして動作するように「サービスエージェントモジュール」内の何らかの設定状態を変更すると言う意味なのか？）が明確でない。
　この点に関し、意見書において、『「サービスエージェントモジュール」を「マスターエージェントモジュール」または「エージェントモジュール」と言うモジュールとして動作するように設定を変更すると解すべきものと思料します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ス．当審拒絶理由通知の（２−２５）で指摘した点について
　ここで指摘した記載は、段落【００３８】における「また、決定されるサービス役割によって自分のサービス役割をネットワーク上で動作するネットワークデバイスに知らせ、所定の標準サービス
を提供することにより指定された
　
ス−１．当審拒絶理由通知の（２−２５−１）で指摘した点
　依然として、「決定されるサービス役割によって」は何を修飾するのか（「知らせ」を修飾するのか？「指定される」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「決定されるサービス役割によって」は、「設定する」を修飾しています。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　また、この意見書の釈明は、当審拒絶理由通知の（１−１９−１）に対する『原請求項１２に対応する請求項１０における「決定されるサービス役割によって、」は、サービス役割がマスターか否かによっての意味であり、実施形態を参照すれば、マスターでないエージェントモジュールにおいて、応用プログラムから標準サービスの要請があると（図４のＳ１３）、その要請のメッセージは変換され（Ｓ１４）、サービス処理要請がマスターへ送られ（Ｓ１５）、さらに、その要請が標準サービス要請に変換されて（Ｓ１７）、標準サービスが要請され（Ｓ１８）、要請に応じて受信された標準サービスがエージェントモジュールへ送られます（Ｓ２２）。したがって、「決定されるサービス役割によって、」は、「要請して」を修飾するものであります。』との釈明とも整合していない。
　したがって、当該不備は依然として解消されていない。
　
ス−２．当審拒絶理由通知の（２−２５−２）で指摘した点
　依然として、「決定されるサービス役割」と「知らせ」ることや「設定する」こととの関係（「決定されるサービス役割」と言う物が主体となって「知らせ」ることや「設定する」ことを実行すると解してよいのか？「決定されるサービス役割」と言うパラメータが「知らせ」ることや「設定する」ことの結果に影響すると言う意味か？後者であるならば、「決定されるサービス役割」と結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「決定されるサービス役割」を「知らせ」ることや「設定」することによって、「サービス役割」というパラメータがネットワーク上のデバイスに知らせられると解すべきもので、決定されたサービス役割がマスター（マスターエージェントモジュール）であれば、他のデバイスは、このマスターであるデバイスへ標準サービスを要請し、決定されたサービス役割がマスターでない（エージェントモジュール）場合には、マスターに対して標準サービスを要請することになります。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
ス−３．当審拒絶理由通知の（２−２５−３）で指摘した点
　依然として、「自分」とは何か（段落【００３６】で「連結」された「デバイス」のことなのか？該デバイスとは別個の「サービスエージェントモジュール」のことなのか？「サービス役割設定部１１０」のことなのか？）が明確でない。
　この点に関し、意見書において、『「自分」とは、ネットワークへの接続後、段落００３７等の処理によって役割が決定されたデバイス自身を意味しています。』と釈明されているが、係る事項は該段落には明示されていない。
　また、この釈明は当審拒絶理由通知の（１−６−１）に対する『原請求項３に対応する請求項２の「自分」は、ネットワークに接続された複数のデバイス（マスターエージェントモジュールまたはサービスエージェントモジュール）の内、ある一つのデバイスを意味し、そのマスターエージェントモジュールまたはサービスエージェントモジュールとしてのデバイスにおけるサービス役割設定部（実施形態の符号１１０）を意味しています。』との釈明と整合していない。
　したがって、当該不備は依然として解消されていない。
　
ス−４．当審拒絶理由通知の（２−２５−４）で指摘した点
　依然として、「ネットワーク上で動作するネットワークデバイス」とは何か（段落【００３６】で「連結」された「デバイス」のことなのか？該デバイスとは別の全「デバイス」のことなのか？）が明確でない。
　この点に関し、意見書において、『「ネットワーク上で動作するネットワークデバイス」は、自身以外の全部のデバイスと解すべきものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　また、この釈明は当審拒絶理由通知の（１−１８−５）に対する『「前記ネットワーク上のデバイス」は、「前記ネットワークに接続された全てのデバイス」を意味しています。』との釈明と相違する。
　したがって、当該不備は依然として解消されていない。
　
ス−５．当審拒絶理由通知の（２−２５−５）で指摘した点
　依然として、「所定の標準サービスを提供することにより」が何を修飾するのか（「指定された」を修飾するのか？「要請して」を修飾するのか？「設定する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「所定の標準サービス提供のために」は「指定されるデバイス」すなわちマスターとしての役割を果たすデバイスを意味しています。すなわち、標準サービスの提供を受ける先のデバイスであるマスターエージェントモジュールと解釈すべきものと思量します。』と釈明されているが、「所定の標準サービス提供のために」に替わる「所定の標準サービスを提供することにより」が何を修飾するのかは釈明されていない。
　また、当審拒絶理由通知の（１−７−３）に対する『「所定の標準サービス提供のために」は「指定される」を修飾されており、「指定されたデバイス」は、マスターエージェントモジュールとしての役割を果たすデバイスを意味しています。ここで、標準サービス提供のために指定されるデバイスは、マスターの役割のデバイスと解すべきものと思量します。』との釈明と、当審拒絶理由通知の（１−１９−４）に対する『「所定の標準サービス提供のために」は、「要請する」を修飾しています。』との釈明とも相違しており、これらを参酌しても「所定の標準サービスを提供することにより」が何を修飾するのかは不明である。
　したがって、当該不備は依然として解消されていない。
　
　
ス−６．当審拒絶理由通知の（２−２５−６）で指摘した点
　依然として、「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？「プロキシ」を利用するために必要な情報なのか？）が明確でない。
　この点に関し、意見書において、『原段落００５７、００５８を参照すると、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されています。したがって、ご指摘の「プロキシ情報」はプロキシであることを示す情報と解すべきものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　また、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されているからといって、必ずしも「プロキシ情報」がプロキシであることを示す情報であるとは限らず、自己が他の「プロキシ」として動作するために必要な「情報」の可能性もあるのであるから、本願発明の詳細な説明の段落【００５６】【００５７】（原段落００５７、００５８に対応）の記載は、「プロキシ情報」がプロキシであることを示す情報であることの根拠にはならない。
　また、この釈明は当審拒絶理由通知の（１−１１−４）に対する『図４に示された処理は、多くのサービスエージェントモジュールのうち、いずれかのサービスエージェントモジュールからサービスの要請があった場合に、そのサービスエージェントモジュールへ標準サービスを提供する一連の処理を示しています。このような一連の処理から見て、「プロキシ情報」は、サービスを要請したサービスエージェントモジュールを特定するためのデータ、例えばＩＰアドレスなどを意味すると解すべきものと思料します。』との釈明とも、当審拒絶理由通知の（１−１９−７）に対する『「プロキシ情報」は、標準サービス提供のために指定されるデバイス、すなわち、マスターの役割を有するデバイスを特定し、このデバイスをプロキシとして動作させるための情報と解すべきものであります。』との釈明とも相違する。
　したがって、当該不備は依然として解消されていない。
　
ス−７．当審拒絶理由通知の（２−２５−７）で指摘した点
　依然として、「該当デバイス」とは何か（段落【００３６】で「連結」された「デバイス」のことなのか？「サービスエージェントモジュール」のことなのか？「プロキシ」として動作する「デバイス」なのか？要請した「デバイス」なのか？要請された「デバイス」なのか？）が明確でない。
　この点に関し、意見書において、『「該当デバイス」は「指定されるデバイス」と解すべきもので、そのデバイスのプロキシ情報を要請するものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ス−８．当審拒絶理由通知の（２−２５−８）で指摘した点
　依然として、「指定されるデバイスにプロキシ情報を要請して」とは如何なる意味なのか（「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」するのか？「指定されるデバイス」に「プロキシ情報」を「指定されるデバイス」内に設定するように「要請」するのか？）が明確でない。
　この点に関し、意見書において、『原段落００５７、００５８を参照すると、「指定されるデバイス」に該「指定されるデバイス」が有する「プロキシ情報」を送信するように「要請」すると解すべきものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ス−９．当審拒絶理由通知の（２−２５−９）で指摘した点
　依然として、「該当デバイスのプロキシ情報を設定する。」とは如何なる意味なのか（「該当デバイス」に関連する「プロキシ情報」をどこかに設定するのか？「該当デバイス」内の「プロキシ情報」格納部に所定値を設定するのか？）が明確でない。
　この点に関し、意見書において、『「該当デバイスのプロキシ情報」を「自分」であるデバイスの所定の格納部に設定しているものと思料します。』と釈明されているが、その根拠が釈明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
セ．当審拒絶理由通知の（２−２６）で指摘した点について
　ここで指摘した記載は、段落【００３９】における
「サービス要請処理部１３０は、サービス役割設定部１１０を通じて決定されるサービス役割によって所定のサービス支援のために要求される標準サービスを内部的に提供するか或いは外部指定されたデバイスのＯＳＧＩサービスプラットフォームへ処理要請する
もので、
　
セ−１．当審拒絶理由通知の（２−２６−１）で指摘した点
　依然として、「サービス役割によって」は何を修飾するのか（「要求される」を修飾するのか？「提供する」を修飾するのか？「外部指定された」を修飾するのか？「処理要請する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、「内部的に提供するか」或いは「外部指定されたデバイスのＯＳＧｉプラットフォームへ処理要請するか」を修飾しています。すなわち、役割がマスターの場合には、「内部的に提供する」であり、マスターでない場合には、「外部指定されたデバイスのＯＳＧｉプラットフォームへ処理要請する」と解すべきものであります。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
セ−２．当審拒絶理由通知の（２−２６−２）で指摘した点
　依然として、「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　この点に関し、意見書において、『「通じて」は、「サービス役割設定部１１０によって」役割が決定されると解すべきと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
セ−３．当審拒絶理由通知の（２−２６−３）で指摘した点
　依然として、「サービス役割」と「要求」や「提供」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、その後の処理をいかに行うかのパラメータとして用いられており、マスターであれば、「標準サービスを内部的に提供する」ことになり、マスターでなければ、「外部指定されたデバイスのＯＳＧｉサービスプラットフォーム」すなわちマスターとしての役割を有するデバイスへ標準サービスの提供を要請するものであります。』と釈明されているが、係る事項は該段落には明示されていない。
　また、該意見書の記載を参酌しても『「サービス役割」と該結果の対応関係は如何になっているのか？』が明確でない。
　したがって、当該不備は依然として解消されていない。
　
セ−４．当審拒絶理由通知の（２−２６−４）で指摘した点
　依然として、「外部指定」とは何処から何処への指定なのか（「外部」への「指定」の意味なのか？「外部」からの「指定」の意味なのか？）、「外部」とは何処の外部なのか（「サービス要請処理部１３０」の外部なのか？「サービスエージェントモジュール」の外部なのか？「デバイス」の外部なのか？）が明確でない。
　この点に関し、意見書において、『「外部決定」とは、マスターとしての役割が段落００３７に示すようなシステムリソース情報に基づく所定のアルゴリズによって決定されると解釈すべきものであります。』と釈明されているが、その根拠が釈明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載は見当たらない。
　また、この釈明は当審拒絶理由通知の（１−３−４）に対する釈明とも、同（１−１４−４）に対する釈明とも相違する。
　したがって、当該不備は依然として解消されていない。
　
セ−５．当審拒絶理由通知の（２−２６−５）で指摘した点
　依然として、「外部指定されたデバイス」の「デバイス」とはどのデバイスか（「サービスエージェントモジュール」のことなのか？「マスターエージェントモジュール」を有する「デバイス」のことなのか？「プロキシ」として動作する「デバイス」なのか？）が明確でない。
　この点に関し、意見書において、『「外部指定されたデバイス」は、「マスターエージェントモジュール」を有するデバイス解すべきものと思料します。発明の詳細な説明には、この「マスターエージェントモジュール」を有するデバイスがプロキシとして動作する旨の記載はなく、「マスターエージェントモジュール」を特定するための「プロキシ情報」をエージェントモジュールへ設定する旨の記載があるのみであり、「外部指定されたデバイス」が「プロキシ」として動作することはないものと思量します。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
　
ソ．当審拒絶理由通知の（２−２７）で指摘した点について
　ここで指摘した記載は、段落【００４０】における「データ変換部１３１は、サービスエージェントモジュールのサービス役割がマスターであれば、サービス要請情報を分析して該当サービスの提供のために要求される標準サービス（Core Service)を動作させるようにサービス要請情報を変換し、サービス役割がエージェントであれば、マスターへサービス要請情報を伝送するようにサービス要請情報を変換する。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ソ−１．当審拒絶理由通知の（２−２７−１）で指摘した点
　依然として、「サービスエージェントモジュールのサービス役割」とは如何なる意味か（「サービスエージェントモジュール」内に記憶されている「サービス役割」の情報なのか？「サービスエージェントモジュール」が「マスター」であるのか「エージェント」であるのかを示す情報のことなのか？）が明確でない。
　この点に関し、意見書において、『「サービスエージェントモジュール」の「サービス役割」が「マスター」であるのか「エージェント」であるのかを示す情報と解すべきものと思料します。』と釈明されているが、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
ソ−２．当審拒絶理由通知の（２−２７−２）で指摘した点
　依然として、「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「データ変換部」が予め有している情報なのか？「サービスエージェントモジュール」が予め有している情報なのか？「アプリケーション」から受け取った情報なのか？他の「デバイス」から受け取った情報なのか？「サービス」の「要請」を受けることができることを示す「情報」なのか？「サービス」の「要請」を何処に渡せばよいのかを示す「情報」なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　この点に関し、意見書において、『「サービス要請情報」は、サービスエージェントモジュールが所定のサービスを実行するために必要な標準サービスの提供をマスターに要請する情報であります。一般に、そのサービスエージェントが実行しようとするアプリケーションから得られる情報と解すべきものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ソ−３．当審拒絶理由通知の（２−２７−３）で指摘した点
　依然として、「提供のために」は何を修飾するのか（「要求される」を修飾するのか？「動作させる」を修飾するのか？「変換し」を修飾するのか？」）が明確でない。
　この点に関し、意見書において、『「提供のために」は、「要求される標準サービス」を修飾しています。』と釈明されているが、係る事項は該段落には明示されていない。
　なお、「提供のために」は連用修飾節である（「に」は助動詞「だ」の連用形である）から、名詞節「要求される標準サービス」の修飾節（連体修飾節）とはなり得ず、この釈明は等を得ないものである。
　したがって、当該不備は依然として解消されていない。
　
ソ−４．当審拒絶理由通知の（２−２７−４）で指摘した点
　依然として、「標準サービス（Core Service)を動作させるようにサービス要請情報を変換し」とは如何なる意味か（「標準サービスを動作させる」ことを目的として「サービス要請情報を変換」すると言う意味か？「標準サービスを動作させる」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　この点に関し、意見書において、『「標準サービスを動作させる」ことを目的として「サービス要請情報を変換」すると解すべきと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ソ−５．当審拒絶理由通知の（２−２７−５）で指摘した点
　依然として、「マスターへサービス要請情報を伝送するようにサービス要請情報を変換する。」とは如何なる意味か（「マスターへサービス要請情報を伝送する」ことを目的として「サービス要請情報を変換」すると言う意味か？「マスターへサービス要請情報を伝送する」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　この点に関し、意見書において、『「マスターへサービス要請情報を伝送する」ことができるような「サービス要請情報」に「変換」すると解すべきと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ソ−６．当審拒絶理由通知の（２−２７−６）で指摘した点
　依然として、「サービス役割がエージェントであれば、マスターへ・・・」とあるが「サービスエージェントモジュール」の「サービス役割」が「エージェント」である場合の「マスター」とは何処でどう定まるものを意味するのか（段落【００３７】では「サービスエージェントモジュールをマスターエージェントモジュールもしくはエージェントモジュールで設定する」ことしかしていないので、ここでの「設定」だけではマスターエージェントモジュールを決められないのでは？）が明確でない。
　この点に関し、意見書において、『段落００３７では、新たなデバイスが接続された場合に、ネットワークに接続された全デバイスにブロードキャストを行ってシステムリソース情報を収集することから、このシステムリソース情報に応じて、新たに接続されたデバイスがマスターでなければ、他のいずれかのデバイスがマスターとしての役割に設定されると解すべきものであります。なお、マスターの役割を有するサービスエージェントモジュールは、そのシステムリソースが高い（新たに接続されたデバイスに対して相対的に高い）ものであり、反対に、新たに接続されるシステムリソースが他のデバイスに対して相対的に低い場合には、新たに接続されるデバイスがマスターとして設定されると解すべきものであります。』と釈明されているが、その根拠が釈明されていない。
　そして、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
ソ−７．当審拒絶理由通知の（２−２７−７）で指摘した点
　依然として、「マスターへサービス要請情報を伝送するようにサービス要請情報を変換する」とは如何なる変換を意味するのか（単に伝送規格に従って変換するだけなのか？マスターで処理不可能な情報をマスターで処理可能な形式に変換するか？）が明確でない。また、何故このような変換が必要なのか（何故、マスターとエージェントとで、受け取る情報の形式を異ならせる必要があるのか？）が明確でない。
　この点に関し、意見書において、『従来技術について説明された段落００１４の記述によれば、標準サービスはデバイス毎に費用を支払って個々に搭載する性格のものであり、エージェントモジュールからの要請によって直ちにマスターエージェントから提供することが可能な互換性を有するとは限りません。これを前提として、形式を問わずに要請される標準サービスの要請に対して、マスターで処理可能に変換することが必要になるものであります。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
　
タ．当審拒絶理由通知の（２−２９）で指摘した点について
　ここで指摘した記載は、段落【００４１】における「標準サービス連結部１３３は、サービス役割によってデータ変換部１３１により変換されたサービス要請処理をプロキシ（Core Service Proxy）
情報
　
タ−１．当審拒絶理由通知の（２−２９−５）で指摘した点
　依然として、「該当標準サービスを動作させる」とは如何なる意味か（段落【００５２】の「標準サービスを活性化させる」こととは異なるのか？）が明確でない。
　この点に関し、意見書において、『「当該標準サービスを動作させる」は、「役割がマスターの場合には、アプリケーションからのサービス要請に対して、自身が有する標準サービスを動作させる」解すべきものであります。』と釈明されているが、係る事項は該段落には明示されていない。また、この釈明を参酌しても、段落【００５２】の「標準サービスを活性化させる」こととは異なるのか否かが明確でない。
　したがって、当該不備は依然として解消されていない。
　
　
チ．当審拒絶理由通知の（２−３０）で指摘した点について
　ここで指摘した記載は、段落【００４２】における「また、標準サービス連結部１３３では、サービス要請情報が所定のエージェントにより要請されたものであれば、該当サービスを動作させて得られた結果値をサービスを要請したエージェントへ伝送する。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
チ−１．当審拒絶理由通知の（２−３０−１）で指摘した点
　依然として、「所定のエージェント」とは何か（「サービスエージェントモジュール」「マスターエージェントモジュール」「エージェントモジュール」とは別のエージェントなのか？他のデバイス中の「エージェントモジュール」の意味なのか？「所定の」条件（例えば「結果値」を返送する機能を有すると言う条件、あるいは、「結果値」を受信する機能を有すると言う条件）を満たす「エージェント」という意味なのか？）が明確でない。
　この点に関し、意見書において、『「所定のエージェント」は、「標準サービスを要請した所定のエージェント」と解すべきものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。また、この釈明を参酌しても、「標準サービスを要請した」「エージェント」の中のどのような「エージェント」が「所定の」なる要件を満たすのかは不明であるため、依然として「所定のエージェント」の意味は明確でない。
　したがって、当該不備は依然として解消されていない。
　
　
チ−２．当審拒絶理由通知の（２−３０−２）で指摘した点
　依然として、「サービス要請情報が所定のエージェントにより要請された」とは、何が何をしていることを意味するのか（「所定のエージェント」から「サービス要請情報」を送るように「要請された」ことを意味するのか？「所定のエージェント」から「サービス要請情報」が送られて来たことを意味するのか？）が明確でない。
　この点に関し、意見書において、『「標準サービスを要請情報が所定のエージェントにより要請されたものであれば」は、「所定のエージェント」から「サービス要請情報」が送られて来たと解すべきものと思料します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
チ−３．当審拒絶理由通知の（２−３０−３）で指摘した点
　依然として、「要請したエージェント」と「所定のエージェント」との関係（共通のものなのか？別個のものなのか？）が明確でない。
　この点に関し、意見書において、『「要請したエージェント」と「所定のエージェント」とは同一のエージェントモジュールを意味するものと解されます。』と釈明されているが、「要請した」と「所定の」とは同義語ではないことは明らかであり、また、「サービス要請情報が所定のエージェントにより要請されたものであれば、該当サービスを動作させて得られた結果値をサービスを要請したエージェントへ伝送する。」との表現からは、「サービス要請情報」が「所定のエージェントにより要請されたもの」ではない場合が想定されていることは明らかであり、「要請したエージェント」と「所定のエージェント」とは同一のエージェントモジュールを意味するものとの釈明は失当である。
　したがって、当該不備は依然として解消されていない。
　
ツ．当審拒絶理由通知の（２−３１）で指摘した点について
　ここで指摘した記載は、段落【００４８】【００４９】における「図３に図示されるように、所定のネットワーク上に連結されデバイスが動作すると、サービスエージェントモジュールのサービス役割設定部１１０では、サービス役割決定のためにネットワーク上で動作するデバイスでディスカバリーメッセージをマルチキャストする。」「これによって、ネットワーク上で動作するデバイスから応答メッセージが受信されると、応答メッセージを通じて収集される各デバイスのシステムリソース情報を利用してサービス役割を決定する（Ｓ１）。」との記載に相当し、補正による実質的な変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
　
ツ−１．当審拒絶理由通知の（２−３１−１）で指摘した点
　依然として、「デバイス」と「サービス役割設定部１１０」の関係（「ネットワーク上で動作するデバイス」や「連結される」「デバイス」とは別個に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」内に「サービス役割設定部１１０」があるのか？「連結される」「デバイス」内に「サービス役割設定部１１０」があるのか？「ネットワーク上で動作するデバイス」及び「連結される」「デバイス」の全ての中に「サービス役割設定部１１０」があるのか？）が明確でない。
　この点に関し、意見書において、『「デバイス」は、ネットワークに連結されたある一つのデバイスを意味し、「サービス役割設定部１１０」は、そのデバイス内に備えられた機能の一つであります。ネットワーク上で動作する全てのデバイスには、このサービス役割設定部１１０を初めとする各機能
（より具体的には、図２に示すサービスエージェントモジュールの機能）が設けられています。原段落００４９に対応する段落００４８は、ネットワークに連結されたある一つのデバイスについて、そのサービス役割決定における処理を説明するものでありますが、実施例では、他のデバイスにおいても、前記ある一つのデバイスと同様にサービスエージェントモジュール１００としての機能が設けられていて、ある一つのデバイスと同様に役割が決定されるものと解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
ツ−２．当審拒絶理由通知の（２−３１−２）で指摘した点
　依然として、段落【００４８】の「所定のネットワーク上に連結されデバイスが動作すると、サービスエージェントモジュールのサービス役割設定部１１０では、サービス役割決定のためにネットワーク上で動作するデバイスでディスカバリーメッセージをマルチキャストする。」の意味（「サービス役割設定部１１０」がポーリング等を行って新たな「デバイス」が「連結」されたことを発見し、発見した旨の「ディスカバリーメッセージ」を「マルチキャスト」するのか？、「連結される」「デバイス」内に「サービス役割設定部１１０」があり、該「サービス役割設定部１１０」が自「デバイス」が「連結」された旨の「ディスカバリーメッセージ」を「マルチキャスト」するのか？）が明確でない。
　この点に関し、意見書において、『ある一つのデバイスがネットワークに連結されると、その一つのデバイスから自身が連結された旨を示すディスカバリーメッセージがマルチキャストされます。これはネットワークに接続された他のデバイスを認識するとともに、マスターの役割を果たすためのデバイスを選出するためのシステムリソース情報を収集するために必要な動作であります。なお、このような役割の設定は、デバイスがサービスを実行するために、その実行の前提となる標準サービスを提供してもらう場合にのみ必要となるものであり、ネットワークに接続された全部のデバイスが常時ディスカバリーメッセージをマルチキャストして、他のデバイスのシステムリソース情報を収集することが必要ではありません。すなわち、サービスの実行が必要となる毎に、そのサービスを実行すべきデバイスが行う処理を解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　また、この釈明は、請求項１の「デバイスが所定のネットワークに連結されると、前記デバイスから受け取った応答メッセージに含まれるシステムリソース情報を用いて・・・」との記載、請求項７の「所定のネットワークに連結されたデバイスについて、前記デバイスから収集されたシステムリソース情報を利用して・・・」との記載、当審拒絶理由通知の（１−２−１）に対する『段落００３６では、デバイスがネットワークに接続されると、サービス役割設定部１１０がブロードキャストする発見メッセージに対して、デバイスから応答メッセージが発信されると記載されています。サービス役割設定部１１０は、この応答メッセージに含まれるシステムリソース情報から、そのデバイスの仕様、性能等を認識し、それらに応じてサービス役割を決定しています。すなわち段落００３６によれば、サービス役割設定部１１０は、デバイスから受信したシステムリソース情報によって、このサービス役割設定部１１０を備える一つのサービスエージェントモジュール（装置）に対して、マスターエージェントモジュールもしくはエージェントモジュールのいずれかの役割を設定します。この段落［００３６］の記載から、デバイスは、ネットワークに接続されるとことによって応答メッセージを出力するものであって、応答メッセージに含まれるシステムリソース情報からサービス役割が決定される点から見て、デバイスが「共通」のものと解することができるものと思料します。』との釈明、当審拒絶理由通知の（１−１３−１）に対する『本発明は、図１に示された従来のＯＳＧＩサービスプラットフォームを改良したもので、本発明を実施するための最良の形態として、段落００３３には、図２を参照して、ネットワーク上でのサービス共有のためのサービス装置の構造が記載されています。すなわち、図１に示されたようなＯＳＧＩサービスプラットフォームが使用者デバイスの一部としてネットワークを介して通信するシステムにおいて、サービス共有（段落００１３で説明されたような標準サービスの重複登録を回避するための標準サービスの共有）の機能を果たす、例えば、実施形態におけるサービスエージェントモジュール１００において実行される処理に関するものであります。原請求項８は、サービスエージェントモジュールが有する機能としてのサービス役割決定部と、サービス要請処理部とが実行する処理を特定したものであります。』との釈明とも、矛盾する。
　したがって、当該不備は依然として解消されていない。
　
ツ−３．当審拒絶理由通知の（２−３１−３）で指摘した点
　依然として、「応答メッセージ」は何が送信するのか（「連結」された「デバイス」が送信するのか？「連結」された「デバイス」以外の「デバイス」も送信するのか？）が明確でない。
　この点に関し、意見書において、『「応答メッセージ」は、サービスを実行しようとするある一つのデバイス以外の他のデバイスから送信されるものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　また、この釈明は、請求項１の「デバイスが所定のネットワークに連結されると、前記デバイスから受け取った応答メッセージに含まれるシステムリソース情報を用いて・・・」との記載、請求項７の「所定のネットワークに連結されたデバイスについて、前記デバイスから収集されたシステムリソース情報を利用して・・・」との記載、当審拒絶理由通知の（１−２−１）に対する『段落００３６では、デバイスがネットワークに接続されると、サービス役割設定部１１０がブロードキャストする発見メッセージに対して、デバイスから応答メッセージが発信されると記載されています。サービス役割設定部１１０は、この応答メッセージに含まれるシステムリソース情報から、そのデバイスの仕様、性能等を認識し、それらに応じてサービス役割を決定しています。すなわち段落００３６によれば、サービス役割設定部１１０は、デバイスから受信したシステムリソース情報によって、このサービス役割設定部１１０を備える一つのサービスエージェントモジュール（装置）に対して、マスターエージェントモジュールもしくはエージェントモジュールのいずれかの役割を設定します。この段落［００３６］の記載から、デバイスは、ネットワークに接続されるとことによって応答メッセージを出力するものであって、応答メッセージに含まれるシステムリソース情報からサービス役割が決定される点から見て、デバイスが「共通」のものと解することができるものと思料します。』との釈明、当審拒絶理由通知の（１−１３−１）に対する『本発明は、図１に示された従来のＯＳＧＩサービスプラットフォームを改良したもので、本発明を実施するための最良の形態として、段落００３３には、図２を参照して、ネットワーク上でのサービス共有のためのサービス装置の構造が記載されています。すなわち、図１に示されたようなＯＳＧＩサービスプラットフォームが使用者デバイスの一部としてネットワークを介して通信するシステムにおいて、サービス共有（段落００１３で説明されたような標準サービスの重複登録を回避するための標準サービスの共有）の機能を果たす、例えば、実施形態におけるサービスエージェントモジュール１００において実行される処理に関するものであります。原請求項８は、サービスエージェントモジュールが有する機能としてのサービス役割決定部と、サービス要請処理部とが実行する処理を特定したものであります。』との釈明とも、矛盾する。
　したがって、当該不備は依然として解消されていない。
　
ツ−４．当審拒絶理由通知の（２−３１−４）で指摘した点
　依然として、「受信」は何が行うのか（「デバイス」とは別個に設けられた「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」あるいはその内の「サービス役割設定部１１０」が行うのか？「連結」された「デバイス」以外の「デバイス」あるいはその内の「サービス役割設定部１１０」も行うのか？）が明確でない。
　この点に関し、意見書において、『「受信」は、サービスを実行しようとするある一つのデバイスが行うものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
ツ−５．当審拒絶理由通知の（２−３１−５）で指摘した点
　依然として、「デバイスのシステムリソース」とは何の「システムリソース」なのか（「連結」された「デバイス」のシステムリソースのことなのか？「連結」された「デバイス」以外の「デバイス」のシステムリソースも含むのか？「デバイス」が連結されたネットワーク等を含む「システム」全体の「リソース」なのか？）が明確でない。
　この点に関し、意見書において、『「連結」された全ての「システムリソース」と解すべきものであります。すなわち、全部のデバイスの「システムリソース」に基づいて、マスターとしての役割を果たすサービスモジュールを決定することが行われています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
ツ−６．当審拒絶理由通知の（２−３１−６）で指摘した点
　依然として、「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　この点に関し、意見書において、『「通じて収集される」は、「応答メッセージを収集することによって、その応答メッセージに含まれるシステムリソース情報を取り込んでサービス役割決定に使用する」と解すべきものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ツ−７．当審拒絶理由通知の（２−３１−７）で指摘した点
　依然として、「サービス役割を決定する」とは、何を決定することを意味するのか（「デバイス」とは別個に設けられた装置の「サービス役割」を「決定」することを意味するのか？　「連結」された「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」することを意味するのか？「連結」された「デバイス」以外の「デバイス」あるいはその中の「サービス要請処理部」等の「サービス役割」を「決定」しなおすことを意味するのか？）、何を基にどう決定するのか（自己のリソースを基に自己が提供可能な「標準サービス」を決定するのか？自己のリソースを基に自己がマスターになり得るか否かを決定するのか？他のデバイスのリソースを基にどのデバイスがどの標準サービスのマスターになるかを決定するのか？）が明確でない。
　この点に関し、意見書において、『自己のリソースを他のデバイスのリソースと比較することにより、マスターの役割を果たすに足るリソースを有するデバイスがマスターに設定され、他のデバイスのリソースが自己のリソースより低い場合には、自身がマスターに設定すべきとの判断がなされていると解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
テ．当審拒絶理由通知の（２−３２）で指摘した点について
　ここで指摘した記載は、段落【００５５】における「図４に図示されるように、所定の標準サービス処理のためにサービスエージェントモジュールでは、ネットワーク上で動作するデバイスに自分の役割を知らせ、それに対する応答で受信される情報を通じてマスターエージェントモジュールを検索する。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
テ−１．当審拒絶理由通知の（２−３２−１）で指摘した点
　依然として、段落【００５５】に記載の処理と段落【００３８】【００５３】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】【００５３】記載のものとは別個の処理ステップなのか？）が明確でない。
　この点に関し、意見書において、『原段落００５６に対応する段落００５５は、役割がマスターでない場合の処理を説明しています。これに対して原段落００５４に対応する段落００５３は、役割がマスターの場合に、自己のサービスフレームワークおよび標準サービスを活性化するというＳ５の処理によって、サービスが実行されています。すなわち、原段落００５６に対応する段落００５５以下には、図４を用いて、役割がマスターでない場合に、いかにしてマスターから標準サービスを取得するかの処理が説明されています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　なお、段落【００５３】には「このような過程を通じてサービス役割が決定されると、サービス役割設定部１１０では、決定された自分のサービス役割をネットワーク上で動作するデバイスに知らせる。」と説明しているだけであり、これが「役割がマスターの場合」を説明している旨の記載も示唆もない。
　したがって、当該不備は依然として解消されていない。
　
テ−２．当審拒絶理由通知の（２−３２−２）で指摘した点
　依然として、「所定の標準サービス処理のために」とは何を修飾するのか（「所定の標準サービス処理のために」「知らせ」「検索する」のか？「所定の標準サービス処理のため」の「マスターエージェントモジュール」を「検索する」のか？）が明確でない。
　この点に関し、意見書において、『「所定の標準サービスの処理のために」は、「自分の役割を知らせ」を修飾しています。』と釈明されているが、該段落の記載（語の配置や読点の位置等）からみて、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
テ−３．当審拒絶理由通知の（２−３２−３）で指摘した点
　依然として、「ネットワーク上で動作するデバイス」とは何か（段落【００３６】【００４８】で「連結」された「デバイス」のことなのか？「連結」された「デバイス」とは別の「デバイス」のことなのか？「サービスエージェントモジュール」のことなのか？「マスターエージェントモジュール」のことなのか？）が明確でない。
　この点に関し、意見書において、『「ネットワーク上で動作するデバイス」は、サービスを実行しようとするある一つのデバイス（サービスエージェントモジュール）以外の他のデバイスを意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
テ−４．当審拒絶理由通知の（２−３２−４）で指摘した点
　依然として、「自分」とは何か（「サービスエージェントモジュール」のことなのか？「ネットワーク上で動作するデバイス」のことなのか？）が明確でない。
　この点に関し、意見書において、『「自分」とは、サービスを実行しようとするある一つのデバイス（サービスエージェントモジュール）を意味し、原段落００５６に対応する段落００５５では、「所定の標準サービス処理のためにサービスエージェントモジュールでは、」を指しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
テ−５．当審拒絶理由通知の（２−３２−５）で指摘した点
「役割」とは何か（「サービス役割」のことなのか？「サービス役割」とは別の「役割」なのか？）が明確でない。
　この点に関し、意見書において、『「役割」とはマスターでないエージェントモジュールであるとの役割を意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
テ−６．当審拒絶理由通知の（２−３２−６）で指摘した点
　依然として、「自分の役割を知らせ、それに対する応答で受信される情報を通じてマスターエージェントモジュールを検索する」とは、如何なる情報のやりとりを意味しているのか（「自分の役割」が「エージェント」であることを他のデバイスに知らせると、他のデバイスから「マスターエージェントモジュール」がどこに有るのかを示す情報が帰ってくるのか？「自分の役割」が「エージェント」であることを他のデバイスに知らせ、これに正確に「応答」したものを「マスターエージェントモジュール」とするのか？、全ての「デバイス」が「自分の役割」を他の「デバイス」に知らせ、そのときに「受信される情報」をもとに「マスターエージェントモジュール」を決めるのか？）が明確でない。
　この点に関し、意見書において、『原段落００５６に続く原段落００５７に対応する段落００５６には、「次に、マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」と記載されています。
　すなわち、本願発明によれば、マスターエージェントモジュールの検索の以後にマスターエージェントモジュールへプロキシ情報を要請するものであって、プロキシ情報を利用してマスターエージェントモジュールを検索するということは妥当ではありません。
　したがって、自身の役割を知らせたことに対して受信される応答メッセージには応答メッセージを送信したデバイスの役割が含まれていると解釈すべきものと思量します。この解釈によれば、自身の役割を知らせ、その応答として他のデバイスの役割が分かり、その役割によりマスターエージェントモジュールがいかなるデバイスであるかを知ることができるからであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
テ−７．当審拒絶理由通知の（２−３２−７）で指摘した点
　依然として、「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　この点に関し、意見書において、『「通じて」は、上記（２−３２−６）に関して説明したように、情報を用いてと解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
テ−８．当審拒絶理由通知の（２−３２−８）で指摘した点
　依然として、「検索」の結果として如何なるものが見出されるのか（全ての「マスターエージェントモジュール」が見出されるのか？特定の標準サービス提供のための「マスターエージェントモジュール」だけが見出されるのか？）が明確でない。
　この点に関し、意見書において、『前記（２−３２−６）に対する意見において説明したように、「検索する」は、「応答メッセージを送信したデバイスのうちどのデバイスがマスターエージェントモジュールであるかを確認する」ことを意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
ト．当審拒絶理由通知の（２−３３）で指摘した点について
　ここで指摘した記載は、段落【００５６】における「次に、マスターエージェントモジュールへプロキシ情報を要請してマスターエージェントモジュールから受信されるプロキシ情報を設定する。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ト−１．当審拒絶理由通知の（２−３３−２）で指摘した点
　依然として、「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？「プロキシ」を利用するために必要な情報なのか？）が明確でない。
　この点に関し、意見書において、『「プロキシ情報」とは、マスターエージェントモジュールとして機能するデバイスを特定するためのＩＰアドレス等の情報を意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　なお、この釈明は、当審拒絶理由通知の（１−７−６）に対する『原段落００５７、００５８には、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されています。したがって、ご指摘の「プロキシ情報」はプロキシであることを示す情報と解すべきものと思料します。』との釈明とも、当審拒絶理由通知の（１−１１−４）に対する『図４に示された処理は、多くのサービスエージェントモジュールのうち、いずれかのサービスエージェントモジュールからサービスの要請があった場合に、そのサービスエージェントモジュールへ標準サービスを提供する一連の処理を示しています。このような一連の処理から見て、「プロキシ情報」は、サービスを要請したサービスエージェントモジュールを特定するためのデータ、例えばＩＰアドレスなどを意味すると解すべきものと思料します。』との釈明とも相違している。
　
ト−２．当審拒絶理由通知の（２−３３−３）で指摘した点
　依然として、どこに「設定」するのか（「サービスエージェントモジュール」内に設定するのか？「サービスエージェントモジュール」とは別の箇所に設定するのか？）が明確でない。
　この点に関し、意見書において、『プロキシ情報を設定するのは、サービスを実行するために標準サービスの伝送を要求するある一つのエージェントモジュールとしてのデバイスであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
ナ．当審拒絶理由通知の（２−３４）で指摘した点について
　ここで指摘した記載は、段落【００５７】における「このようにマスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報を設定したエージェントモジュールでは、応用プログラムのサービス支援のために所定の標準サービスが要求されると、設定されたプロキシ情報を利用して指定されたマスターエージェントモジュールへ該当標準サービス要請情報を伝送する。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ナ−１．当審拒絶理由通知の（２−３４−１）で指摘した点
　依然として、「マスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報」とは何か（「サービス役割」のことか？「プロキシ情報」のことか？他の情報か？）が明確でない。
　この点に関し、意見書において、『原段落００５８に対応する段落００５７の「マスターエージェントモジュールを通じて所定の標準サービス提供のために指定されたデバイスに対する情報」は、原段落００５７に対応する段落００５６の処理によってマスターエージェントモジュールから得られたプロキシ情報を意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
ナ−２．当審拒絶理由通知の（２−３４−２）で指摘した点
　依然として、「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　この点に関し、意見書において、『「通じて」は、「マスターエージェントモジュールから」と解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ナ−３．当審拒絶理由通知の（２−３４−３）で指摘した点
　依然として、「応用プログラムのサービス支援」とは何か（応用プログラムが提供するサービスを支援することか？応用プログラムから要求された標準サービスを支援することか？）が明確でない。
　この点に関し、意見書において、『「応用プログラムのサービス支援」は、応用プログラムが提供するサービスを支援することを意味しており、具体的には、応用プログラムのサービスを実行するために必要な標準サービスを提供することを意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ニ．当審拒絶理由通知の（２−３５）で指摘した点について
　ここで指摘した記載は、段落【００５８】における「即ち、一例で、サービス役割がエージェントであるエージェントモジュールでは、サービス役割によって応用プログラム等から要求される標準サービス提供のためにマスターエージェントモジュールを検索する（Ｓ１１）。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ニ−１．当審拒絶理由通知の（２−３５−１）で指摘した点
　依然として、段落【００５５】に記載の処理と段落【００３８】【００５３】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】【００５３】記載のものとは別個の処理ステップなのか？）が明確でない。
　この点に関し、意見書において、『原段落００５６〜００５９に対応する段落００５５〜００５８の処理は、段落００３８で説明された処理において、マスターでないと判断されてエージェントで設定された場合（Ｓ３）の処理を示しています。』と釈明されているが、依然として、段落【００３８】【００５３】記載のものと同じ処理ステップの説明をしているのか、別個の処理ステップの説明をしているのかは明確でない。
　したがって、当該不備は依然として解消されていない。
　
ニ−２．当審拒絶理由通知の（２−３５−２）で指摘した点
　依然として、「サービス役割によって」は、何を修飾するのか（「要求される」を修飾するのか？「検索する」を修飾するのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって」は、エージェントモジュールで役割が設定された場合と解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ニ−３．当審拒絶理由通知の（２−３５−３）で指摘した点
　依然として、「サービス役割」と「要求」や「検索」の処理との関係（「サービス役割」が、該処理に如何に関与するのか？「サービス役割」と言う物が該処理を実行する主体となると解してよいのか？「サービス役割」と言うパラメータが該処理の結果に影響すると言う意味か？後者であるならば、「サービス役割」と該結果の対応関係は如何になっているのか？　また、ここでの「サービス役割」は「エージェント」であることが前提となっているが、さらにその役割が細分化されているのか？）が明確でない。
　この点に関し、意見書において、『「サービス役割」は、その後の処理が行われる条件となるパラメータと解すべきであって、マスターでない（＝エージェント）であるという条件により、Ｓ１１の処理が行われています。すなわち、マスターでないより細分化されたパラメータが存在することはありません。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ニ−４．当審拒絶理由通知の（２−３５−４）で指摘した点
　依然として、「検索」の結果はいかなるものが見出されるのか（全ての「マスターエージェントモジュール」が見出されるのか？特定の標準サービス提供のための「マスターエージェントモジュール」だけが見出されるのか？）が明確でない。
　この点に関し、意見書において、『「検索」の結果、エージェントモジュールで実行すべきサービスに必要な標準サービスが見出され、最終的にそのエージェントへ伝送されます。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。また、その根拠も説明されていない。
　したがって、当該不備は依然として解消されていない。
　
ニ−５．当審拒絶理由通知の（２−３５−５）で指摘した点
　依然として、「要求される標準サービス提供のためにマスターエージェントモジュールを検索する」とあるが、その意味（「検索する」ことで「要求される標準サービス提供」がなされると言う意味なのか？将来の「標準サービス提供」の「要求」に備えて「検索」をすると言う意味なのか？「要求される標準サービス提供のため」の「マスターエージェントモジュールを検索する」と言う意味か？）が明確でない。
　この点に関し、意見書において、『「サービス役割によって応用プログラム等から要求される標準サービス提供のためにマスターエージェントモジュールを検索する」は、検索することで、「要求される標準サービスの提供」がなされると解すべきものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。また、その根拠も説明されていない。
　したがって、当該不備は依然として解消されていない。
　
　
ヌ．当審拒絶理由通知の（２−３６）で指摘した点について
　ここで指摘した記載は、段落【００５９】における「次に、マスターエージェントモジュールが検索されると、検索されたマスターエージェントモジュールへプロキシ情報を要請して受信されるプロキシ情報を設定する（Ｓ１２）。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ヌ−１．当審拒絶理由通知の（２−３６−１）で指摘した点
　依然として、段落【００５６】に記載の処理と段落【００３８】記載の事項との関係（同じ処理ステップの説明をしているのか？段落【００３８】記載のものとは別個の処理ステップなのか？）が明確でない。
　この点に関し、意見書において、『原段落００６０に対応する段落００５９における「マスターエージェントモジュールが検索されると、検索されたマスターエージェントモジュールへプロキシ情報を要請して受信されるプロキシ情報を設定する（Ｓ１２）」処理は、段落００３８と同じ処理ステップをより詳細に説明したものであります。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ヌ−２．当審拒絶理由通知の（２−３６−２）で指摘した点
　依然として、「プロキシ情報」とは何か（「プロキシ」であることを示す「情報」なのか？自己が他の「プロキシ」として動作するために必要な「情報」なのか？他を自己の「プロキシ」として動作させるために必要な「情報」なのか？「プロキシ」を利用するために必要な情報なのか？）が明確でない。
　この点に関し、意見書において、『「プロキシ情報」とは、他を自己の「プロキシ」として動作させるために必要な情報、例えばマスターエージェントモジュールを特定する情報を意味しています。』と釈明されているが、係る事項は該段落には明示されていない。
　なお、この釈明は、当審拒絶理由通知の（１−７−６）に対する『原段落００５７、００５８には、マスターエージェントモジュールに「プロキシ情報」を要請し、その「プロキシ情報」がサービスエージェントモジュールに設定される点が記載されています。したがって、ご指摘の「プロキシ情報」はプロキシであることを示す情報と解すべきものと思料します。』との釈明とも、当審拒絶理由通知の（１−１１−４）に対する『図４に示された処理は、多くのサービスエージェントモジュールのうち、いずれかのサービスエージェントモジュールからサービスの要請があった場合に、そのサービスエージェントモジュールへ標準サービスを提供する一連の処理を示しています。このような一連の処理から見て、「プロキシ情報」は、サービスを要請したサービスエージェントモジュールを特定するためのデータ、例えばＩＰアドレスなどを意味すると解すべきものと思料します。』との釈明とも相違している。
　したがって、当該不備は依然として解消されていない。
　
ヌ−３．当審拒絶理由通知の（２−３６−３）で指摘した点
　依然として、どこに「設定」するのか（「サービスエージェントモジュール」内に設定するのか？「サービスエージェントモジュール」とは別の箇所に設定するのか？）が明確でない。
　この点に関し、意見書において、『「プロキシ情報」は、サービスエージェントモジュール内に設定されるものと解すべきであります。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
　
ネ．当審拒絶理由通知の（２−３７）で指摘した点について
　ここで指摘した記載は、段落【００６０】における「次に、エージェントモジュールでは、応用プログラムから所定のサービス提供のために標準サービスが要請されると（Ｓ１３）、マスターエージェントモジュールへサービス要請情報を伝送するように
サービス要請のメッセージに
　
ネ−１．当審拒絶理由通知の（２−３７−１）で指摘した点
　依然として、「応用プログラムから所定のサービス提供のために標準サービスが要請される」とは如何なる意味なのか（「応用プログラム」が「所定のサービス」をユーザなどに「提供」するために、「エージェントモジュール」に対して「標準サービス」を「要請」するのか？「応用プログラム」から「エージェントモジュール」に対して「所定の」標準「サービス」を「提供」することを「要請」するのか？）が明確でない。
　この点に関し、意見書において、『応用プログラムを動作させようとしている「エージェントモジュール」が、「所定のサービス」をユーザなどに提供するために標準サービスを「要請」すると解すべきものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ネ−２．当審拒絶理由通知の（２−３７−２）で指摘した点
　依然として、「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請のメッセージに変換する（Ｓ１４）。」とは如何なる意味か（「マスターエージェントモジュールへサービス要請情報を伝送する」ことを目的として「サービス要請のメッセージに変換」すると言う意味か？「マスターエージェントモジュールへサービス要請情報を伝送する」ことができるような「サービス要請のメッセージ」に「変換」すると言う意味か？）が明確でない。
　この点に関し、意見書において、『「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する（Ｓ１４）。」は、「マスターエージェントモジュールへサービス要請情報を伝送する」ことを目的として「サービス要請情報を変換する」と解すべきものと思量します。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ネ−３．当審拒絶理由通知の（２−３７−３）で指摘した点
　依然として、「サービス要請情報」とは何処のあるいは何処から来た如何なる情報のことなのか（「エージェントモジュール」が予め有している情報なのか？「応用プログラム」から受け取った情報なのか？「サービス」の「要請」があった旨を示す「情報」なのか？「サービス」の「要請」の内容を示す「情報」なのか？「サービス」の「要請」の実行のために必要な引数などの「情報」なのか？）が明確でない。
　この点に関し、意見書において、『「標準サービス要請」は「サービス要請情報」と同じ意味であります。すなわち、「サービス要請情報」は、あるデバイスが、例えばユーザの要請に対応してアプリケーションを実行する（サービスを提供する）場合に、アプリケーションの実行に必要な標準サービスを要請するための情報であります。』と釈明されているが、係る事項は該段落には明示されていない。
　したがって、当該不備は依然として解消されていない。
　
ネ−４．当審拒絶理由通知の（２−３７−４）で指摘した点
　依然として、「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請のメッセージに変換する」とは如何なる変換を意味するのか（単に伝送規格に従って変換するだけなのか？マスターエージェントモジュールで処理不可能な情報をマスターエージェントモジュールで処理可能な形式に変換するか？）が明確でない。また、何故このような変換が必要なのか（何故、マスターエージェントモジュールとエージェントモジュールとで、受け取る情報の形式を異ならせる必要があるのか？）が明確でない。
　この点に関し、意見書において、『「マスターエージェントモジュールへサービス要請情報を伝送するようにサービス要請情報を変換する」は、形式を問わずに要請される標準サービスの要請に対して、マスターで処理可能に変換することが必要になるものであります。
　従来技術について説明された段落００１４の記述によれば、標準サービスはデバイス毎に費用を支払って個々に搭載する性格のものであり、エージェントモジュールからの要請によって直ちにマスターエージェントから提供することが可能な互換性を有するとは限りません。これを前提として、形式を問わずに要請される標準サービスの要請に対して、マスターで処理可能に変換することが必要になるものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではなく、また、他の段落の記載を参酌しても、係る事項を明示する記載が見当たらない。
　したがって、当該不備は依然として解消されていない。
　
　
ノ．当審拒絶理由通知の（２−３８）で指摘した点について
　ここで指摘した記載は、段落【００６１】における「次に、変換されたサービス要請情報をサービス処理要請メッセージと共にマスターエージェントモジュールへ伝送する（Ｓ１５）。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ノ−１．当審拒絶理由通知の（２−３８−１）で指摘した点
　依然として、「サービス処理要請メッセージ」とは何処で得られた情報なのか（ステップＳ１４で変換して得られた情報なのか？「サービス要請情報」とは別に新たに生成された情報なのか？「応用プログラム」から送られて来た情報なのか？）が明確でない。
　この点に関し、意見書において、『原段落００６１に対応する段落００６０を補正することにより、Ｓ１４において標準サービスの要請をメッセージに変換し、このメッセージを原段落００６２に対応する段落００６１のＳ１５においてマスターエージェントモジュールへ伝送する点が明確にされたものと思量します。』と釈明されているが、段落【００６０】では「サービス処理要請メッセージ」なる用語は用いられておらず、これらの段落の記載から「サービス処理要請メッセージ」が何処で得られた情報なのかが明確になるものではない。
　したがって、当該不備は依然として解消されていない。
　
ノ−２．当審拒絶理由通知の（２−３８−２）で指摘した点
　依然として、「サービス処理要請メッセージ」とは如何なる情報のことなのか（「サービス処理」の「要請」があった旨を示す「メッセージ」なのか？「サービス処理」の「要請」の内容を示す「メッセージ」なのか？）が明確でない。
　この点に関し、意見書において、『「サービス処理要請メッセージ」は、「サービス処理」の「要請」の内容を示す「メッセージ」と解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ハ．当審拒絶理由通知の（２−３９）で指摘した点について
　ここで指摘した記載は、段落【００６２】における「マスターエージェントモジュールでは、サービス処理要請が受信される（Ｓ１６）と、サービス要請情報を分析して要求される標準サービスを動作させるようにサービス要請情報を変換し（Ｓ１７）、ＯＳＧＩサービスプラットフォームへ標準サービス要請を伝送する（Ｓ１８）。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ハ−１．当審拒絶理由通知の（２−３９−１）で指摘した点
　依然として、「サービス処理要請」とは何か（「サービス処理要請メッセージ」のことか？「サービス要請情報」のことか？）が明確でない。
　この点に関し、意見書において、『「サービス処理要請」は、「サービス処理要請メッセージ」を意味するものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ハ−２．当審拒絶理由通知の（２−３９−２）で指摘した点
　依然として、「要求される標準サービスを動作させるようにサービス要請情報を変換し」とは如何なる意味か（「標準サービスを動作させる」ことを目的として「サービス要請情報を変換」すると言う意味か？「標準サービスを動作させる」ことができるような「サービス要請情報」に「変換」すると言う意味か？）が明確でない。
　この点に関し、意見書において、『「要求される標準サービスを動作させるようにサービス要請情報を変換し（Ｓ１７）」は、エージェントモジュールがアプリケーションの実行に必要とする標準サービスを要求するに際して、「標準サービスを動作させる」ことを目的として、「サービス要請情報」を変換すると解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ハ−３．当審拒絶理由通知の（２−３９−３）で指摘した点
　依然として、「標準サービス要請」とは何か（変換後の「サービス要請情報」のことか？「サービス要請情報」とは別の情報なのか？）が明確でない。
　この点に関し、意見書において、『「標準サービス要請」は、変換後のサービス要請情報と同じ情報であります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ヒ．当審拒絶理由通知の（２−４０）で指摘した点について
　ここで指摘した記載は、段落【００６３】における「これによって、
マスターの役割の
　
ヒ−１．当審拒絶理由通知の（２−４０−１）で指摘した点
　依然として、「該当する標準サービスが実行されるように処理し」とは如何なる処理なのか（「該当する標準サービス」を「実行」させる「処理」を行うのか？「該当する標準サービス」が「実行」可能となるように「処理」を行うのか？）が明確でない。
　この点に関し、意見書において、『「該当する標準サービスが実行されるように処理し」は、該当する標準サービスが実行されるように、標準サービス要請の情報を処理すると解すべきものと思量します。』と釈明されているが、該釈明を参酌しても「該当する標準サービス」を「実行」させる「処理」を行うのか、「該当する標準サービス」が「実行」可能となるように「処理」を行うのかは明確でない。
　したがって、当該不備は依然として解消されていない。
　
ヒ−２．当審拒絶理由通知の（２−４０−２）で指摘した点
　依然として、「処理結果得られる結果値」とは如何なるものなのか（「処理結果」であるところの「得られる結果値」と言う意味なのか？「処理」の「結果得られる結果値と言う意味か？）が明確でない。
　この点に関し、意見書において、『「処理結果得られる結果値」は、「処理」の「結果得られる結果値」と解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
フ．当審拒絶理由通知の（２−４１）で指摘した点について
　ここで指摘した記載は、段落【００６４】における「マスターエージェントモジュールでは、ＯＳＧＩサービスプラットフォームから受信される標準サービス処理結果値をエージェントモジュールへ伝送するように変換し（Ｓ２１）、要請された標準サービス処理結果でエージェントモジュールに提供する（Ｓ２２）。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
フ−１．当審拒絶理由通知の（２−４１−１）で指摘した点
　依然として、「標準サービス処理結果値」とは何か（段落【００６３】の「処理結果得られる結果値」のことか？これとは別の値のことか？）が明確でない。
　この点に関し、意見書において、『「標準サービス処理結果値」は、「処理結果得られる結果値」の意味に解すべきものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
フ−２．当審拒絶理由通知の（２−４１−２）で指摘した点
　依然として、「標準サービス処理結果」とは何か（「標準サービス処理結果値」のことか？これとは別の情報のことか？）が明確でない。
　この点に関し、意見書において、『「標準サービス処理結果」は、「標準サービス処理結果値」の意味に解すべきものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
フ−３．当審拒絶理由通知の（２−４１−３）で指摘した点
　依然として、「要請された標準サービス処理結果でエージェントモジュールに提供する」とは如何なる処理なのか（「要請された標準サービス処理結果」と言うものを用いて「エージェントモジュールに」何かを「提供する」という意味なのか？「要請された標準サービス」の「処理結果」を「エージェントモジュールに提供する」という意味なのか？「標準サービス」の「処理結果」を「要請された」「エージェントモジュールに提供する」という意味なのか？）が明確でない。
　この点に関し、意見書において、『「要請された標準サービス処理結果でエージェントモジュールに提供する」は、「要請された標準サービス」の「処理結果」を「エージェントモジュールに提供する」という意味に解すべきものであります。』と釈明されているが、該段落の記載（語の配置や用いられている助詞等）からみて、係る事項が該段落に明示されているとは言えない。
　したがって、当該不備は依然として解消されていない。
　
　
ヘ．当審拒絶理由通知の（２−４２）で指摘した点について
　ここで指摘した記載は、段落【００６５】における「エージェントモジュールでは、マスターエージェントモジュールから処理結果値が受信されると（Ｓ２３）、受信される処理結果値を標準サービスを要請した応用プログラムへ伝送するように変換し（Ｓ２４）、応用プログラムへ伝送する（Ｓ２５）。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ヘ−１．当審拒絶理由通知の（２−４２−１）で指摘した点
　依然として、「処理結果値」とはなにか（段落【００６３】の「処理結果得られる結果値」なのか？段落【００６４】の「標準サービス処理結果値」あるいは「標準サービス処理結果」なのか？これらとは別個の値なのか？）が明確でない。
　この点に関し、意見書において、『「処理結果値」は、原段落００６４に対応する段落００６３の「処理結果得られる結果値」と解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
ホ．当審拒絶理由通知の（２−４３）で指摘した点について
　ここで指摘した記載は、段落【００６６】における「以上のように行われるサービス役割決定及びサービス役割処理過程を通じてネットワーク上で動作するデバイスのＯＳＧＩサービスプラットフォームとの間で標準サービスを共有するようになる。」との記載に相当し、補正による変更はない。そして、以下の点で当該記載に関する不備は、依然として解消されていない。
　
ホ−１．当審拒絶理由通知の（２−４３−１）で指摘した点
　依然として、「通じて」の意味（通過して、経由してと言う意味でよいのか？他意か？）が明確でない。
　この点に関し、意見書において、『「通じて」は、「経由して」と解すべきものと思量します。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ホ−２．当審拒絶理由通知の（２−４３−２）で指摘した点
　依然として、「標準サービス」を「デバイスのＯＳＧＩサービスプラットフォーム」と何との「間」で共有するするのか（複数の「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有するなのか？「エージェントモジュール」と「デバイスのＯＳＧＩサービスプラットフォーム」の間で共有するなのか？）が明確でない。
　この点に関し、意見書において、『「標準サービス」を「複数のデバイスのＯＳＧｉプラットフォームの間で共有する」と解すべきものであります。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
ホ−３．当審拒絶理由通知の（２−４３−３）で指摘した点
　依然として、「サービス役割処理過程」とはどの「過程」のことなのか（段落【００５４】以降に説明される「サービス処理過程」のことか？段落【００５８】【００５９】で説明されるマスター検索（Ｓ１１）、プロキシ設定（Ｓ１２）のことか？）が明確でない。
　この点に関し、意見書において、『「サービス役割処理過程」は、原段落００５８〜００６６に対応する段落００５７〜００６５において図４を参照して説明された過程全体を意味しています。』と釈明されているが、該段落の記載からは係る事項は明らかなものではない。
　したがって、当該不備は依然として解消されていない。
　
　
マ．小結
　以上のように、本願の発明の詳細な説明には、意味の不明確な記載や具体的構成の不明な記載、特許請求の範囲の記載と整合しない記載が多数あり、ここに記載の実施例等の構成や機能等を正確に把握することが不可能であるとともに、請求項１〜１５に係る発明の課題や作用効果等の技術上の意義も正確に把握することが不可能である。
　したがって、本願の発明の詳細な説明は、当業者が本願請求項１〜１５に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願の発明の詳細な説明は、請求項１〜１５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものでもあるから、本願の発明の詳細な説明は特許法第３６条第４項第１号に規定する要件（実施可能要件及び委任省令要件）を満たしていない。
　
　
５．むすび
　以上のとおり、本願は、発明の詳細な説明及び特許請求の範囲の記載が、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていない。
　
　よって、上記結論のとおり審決する。