2022-001300

第２ 原査定の概要

原査定（令和３年９月２７日付け拒絶査定）の概要は次のとおりである。

理由１ （進歩性）本願請求項１－５２に係る発明は、以下の引用文献１－４に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

引用文献等一覧

１．国際公開第２０１４／１１８９３８号

２．特開２００３－１３４１２８号公報

３．特開２０１３－０５５６４２号公報

４．国際公開第２０１３／１３３３５５号

第３ 当審拒絶理由の概要

理由１ （明確性）この出願は、特許請求の範囲の請求項１－５２の記載が、特許法第３６条第６項第２号に規定する要件を満たしていない。

（１） 請求項１において、「識別子情報」と「サービス・タイプ」とから「候補デバイス・グループを取得するステップ」とは、具体的にどのような処理を行うステップであるのかが、明細書を参照しても記載がなく、不明確である。

請求項２－５２についても同様である。

（２） 請求項１において、「前記第1のデバイス・グループは、サービスを提供するデバイスを含み」との記載と、「前記第1のデバイス・グループの中の前記デバイスに前記サービスを提供する」との記載があることによって、「第1のデバイス・グループ」とは、「サービスを提供する」デバイスであるのか、「サービスを提供される」（サービスを要求する）デバイスであるのかが不明確である。

請求項２－５２についても同様である。

第４ 本願発明

本願請求項１－５０に係る発明（以下、それぞれ「本願発明１」－「本願発明５０」という。）は、令和４年１２月１３日付けの手続補正で補正された特許請求の範囲の請求項１－５０に記載された事項により特定される発明であって、本願発明１は以下のとおりの発明である。

「【請求項１】

サービスを構成する方法であって、

識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップであって、前記識別子情報は、第1のデバイス・グループを識別するのに使用され、前記第1のデバイス・グループは、前記サービスを要求するデバイスを含み、前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し、前記条件は、前記サービスに対応する通信要件であり、前記第1のデバイス・グループは、前記サービスに対応する同じ通信要件を満たすことが可能であるデバイスの組である、ステップと、

前記サービス・タイプに基づいて、前記契約の前記タイプを決定するステップと、

前記取得した識別子情報にしたがって、前記契約の前記決定されたタイプに対応する候補デバイス・グループを取得するステップと、

前記識別子情報及び前記条件にしたがって、前記サービスに対応する前記同じ通信要件を満たすことが可能である前記第1のデバイス・グループに対応する前記候補デバイス・グループから前記契約の前記決定されたタイプに対応するネットワーク・デバイス・グループを選択し、前記識別子情報及び前記条件にしたがって、前記ネットワーク・デバイス・グループについての情報を取得するステップであって、前記ネットワーク・デバイス・グループは、前記条件を満たすネットワーク・デバイスを含む、ステップと、

前記条件にしたがって、第1の転送規則を取得するステップであって、前記第1の転送規則は、前記ネットワーク・デバイス・グループに対応し、前記第1の転送規則は、前記ネットワーク・デバイス・グループの中の前記ネットワーク・デバイスが、前記第1のデバイス・グループの中の前記デバイスに前記サービスを提供することを可能とするのに使用される、ステップと、

前記第1の転送規則を送信するステップと、を含む、

方法。」

なお、本願発明２－５０の概要は以下のとおりである。

本願発明２－２３は、本願発明１を減縮した発明である。

本願発明２４は、請求項１－２３のいずれかを引用する形式で記載された「ネットワーク・デバイス」の発明である。

本願発明２５は、本願発明１に対応する「装置」の発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。

本願発明２６－４５は、本願発明２５を減縮した発明である。

本願発明４６－４９は、請求項２４、２５－４５のいずれかを引用する形式で記載された「ネットワーク・システム」の発明である。

本願発明５０は、請求項１－２３のいずれかを引用する形式で記載された「コンピュータプログラム」の発明である。

第５ 引用文献、引用発明等

１ 引用文献１及び引用発明

（１） 引用文献１

当審拒絶理由に引用した引用文献１には、図面とともに、以下の記載がある（下線は、特に着目した箇所を示す。以下同様。）。

ア 段落【００２５】

「【００２５】 本発明によれば、端末のユーザが利用するソフトウェアリソースを提供するサーバがネットワークに分散して存在する場合に、端末数の増大やトラフィック量増大に対して、ネットワーク制御サーバの処理負荷と通信装置の処理負荷を抑えつつ、端末やアプリ毎に最適なサーバに接続を可能になる。また、前記ソフトウェアリソースを提供するサーバが変更された場合や、端末が移動した場合等においても、端末は速やかに最適なサーバに接続することが可能になる。」

イ 段落【００２８】

「【００２８】 本実施例においては、端末の利用者（またはユーザ）が利用するソフトウェアリソースを提供するサーバの識別子が同一の端末と、アプリケーションの組合せを集約グループとして管理する。以下では、端末のユーザが利用するソフトウェアリソースの一例として、仮想サーバ、アプリケーション、データ、記憶領域（ストレージサービス）などの端末から利用可能なリソースとする。また、端末のユーザが利用するソフトウェアリソースは、ＤａａＳ（Ｄｅｓｋｔｏｐ ａｓ ａ Ｓｅｒｖｉｃｅ）などとして提供される仮想サーバや、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）などとして提供されるアプリケーション、およびデータであってもよい。また、サーバの識別子は、ＩＰアドレス等とは異なり、ネットワーク制御サーバ（またはネットワーク制御装置）１００が管理する一意の識別子である。」

ウ 【図１】

「

［図：0001394776000001.jpg］

」

エ 段落【００３２】

「【００３２】 ネットワーク制御サーバ１００は、複数の通信装置１４０、リソース管理サーバ１１０、及び、サービスルックアップサーバ１２０に接続される。ネットワーク制御サーバ１００は、各通信装置１４０を接続する通信経路を設定する。通信経路を設定する技術としては、前記非参照文献１で提案されているＯｐｅｎ Ｆｌｏｗなどを適用することができる。通信装置１４０を接続する通信経路は、上記集約グループ毎、または、端末とアプリケーションの組合せ毎に設定される。」

オ 段落【００３６】

「【００３６】 サービスルックアップサーバ１２０は、端末１７０、ネットワーク制御サーバ１００、及び、リソース管理サーバ１１０に接続される。サービスルックアップサーバ１２０は、端末１７０からのＩＰアドレスの問い合わせに対して、端末１７０から受け取ったドメイン名と、端末１７０の識別子と、アプリケーションの識別子との組合せによって名前解決を実施して、端末１７０にドメイン名に対応するＩＰアドレスを応答する。ここで、端末１７０の識別子、アプリケーションの識別子とは、サービスルックアップサーバ１２０、リソース管理サーバ１１０、及び、ネットワーク制御サーバ１００が独自に割り当てて、管理する一意の識別子である。」

カ 段落【００５０】－【００５１】

「【００５０】 集約グループ情報記憶部２３１は、端末１７０とアプリケーションの組合せのうち、特徴が類似（または一致）するもの同士を集約したグループの情報を保持する記憶部である。

【００５１】 特徴が類似するとは、ソフトウェアリソースが提供されるサーバ１５０の識別子が同じである、または、ソフトウェアリソースが提供されるサーバ１５０の識別子が同じで、かつ、端末１７０が要求する通信遅延や優先度などの通信特性が同等であることを示す。例えば、通信特性情報のうち通信遅延が閾値（例えば、３０ｍｓ）以下で、帯域が閾値（例えば、２００Ｍｂｐｓ）以上であれば特徴は類似する、と判定することができる。」

キ 【図１４Ａ】

「

［図：0001394776000002.jpg］

」

ク 段落【０１４３】－【０１５３】

「【０１４３】 設定情報テーブル１９５０には、ルール１９５１～１９５４とアクション１９５５～１９５８が含まれる。ルール１９５１～１９５４は、トラフィックを受信した通信装置１４０が処理方法を判断するための条件を示す。ルール１９５１～１９５４には、宛先アドレス１９５１、ポート番号１９５２、送信元アドレス１９５３、優先度１９５４が含まれる。宛先アドレス１９５１は、受信したトラフィックのヘッダーに含まれる宛先ＩＰアドレスを示す。ポート番号１９５２は、受信したトラフィックのヘッダーに含まれるＴＣＰやＵＤＰなどのポート番号を示す。送信元アドレス１９５３は、受信したトラフィックのヘッダーに含まれる送信元ＩＰアドレスを示す。優先度１９５４は、受信したトラフィックが複数のルールに当てはまる場合に、どのルールに対応する処理（アクション）を優先的に適用するかを判断するための値を示す。ただし、通信の状態が輻輳、障害、または、メンテナンスによって、正常には通信ができない場合は、正常には通信できないルールをいて最も優先度が高いルールに対応する処理（アクション）を適用する。

・・・（中略）・・・

【０１４５】 ＜シーケンスの説明＞

図１４Ａ、図１４Ｂは、本実施例における集約グループ判断、及び、宛先と経路切替の設定を行う処理を示すシーケンス図である。

続きを表示（全11行）

・・・（中略）・・・

【０１４８】 シーケンス２０２０において、端末１７０－１は、サービスルックアップサーバ１２０に名前解決要求を送信する。名前解決要求には、ソフトウェアリソースを提供するドメイン名が含まれる。本ドメイン名は、端末１７０とアプリケーションの組み合わせ毎に、一意に決まるソフトウェアリソースを提供するサーバ１５０の識別子である。

・・・（中略）・・・

【０１５１】 シーケンス２０５０において、リソース管理サーバ１１０は、リソース提供位置要求２０５０を、ネットワーク制御サーバ１００に通知する。図１１に示したリソース提供位置要求には、要求通信特性情報テーブル１１００が含まれる。

【０１５２】 ステップ２０６０（当審注：「シーケンス２０６０」の誤記と認める。）において、ネットワーク制御サーバ１００は、リソース提供位置の判定を行う。リソース提供位置の判定では、ネットワーク制御サーバ１００が、要求通信特性情報テーブル１１００、通信装置間通信特性情報テーブル１７００、アクセスポイント－通信装置間通信特性情報テーブル１８００、及び、集約グループ情報テーブル１３００を参照して、リソース提供位置情報テーブル１２００を算出し、集約グループ情報テーブル１３００を更新する。

【０１５３】 ＜集約グループ判断２０６０の処理＞

以下、図１４Ａのシーケンス２０６０で行われる処理を、図１９を用いて説明する。ここで、図１９は、集約グループ判断部２０１と集約グループ生成・変更部２０４が集約グループを判断する処理の一例を示すフローチャートである。」

ケ 【図１９】

「

［図：0001394776000003.jpg］

」

上記【図１９】を参照すると、ステップ５０５０において、「集約グループ判断部は、集約グループ情報テーブルの要件を満たす集約グループのうち、コストが最小の集約グループを選択する。」ことが記載されていると認定できる。

コ 段落【０２３９】

「【０２３９】 次に、図１４Ａに戻り、シーケンス２１３０において、ネットワーク制御サーバ１００は、集約グループ宛先情報テーブル１５００に追記した列の設定対象通信装置１５０２に、設定変更メッセージを送信する。設定変更メッセージには、設定情報テーブル１９５０が含まれる。」

（２） 引用発明

したがって、上記引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。

「端末のユーザが利用するソフトウェアリソースを提供するサーバがネットワークに分散して存在する場合に、端末数の増大やトラフィック量増大に対して、ネットワーク制御サーバの処理負荷と通信装置の処理負荷を抑えつつ、端末やアプリ毎に最適なサーバに接続を可能になり、また、前記ソフトウェアリソースを提供するサーバが変更された場合や、端末が移動した場合等においても、端末は速やかに最適なサーバに接続することが可能になり、

ソフトウェアリソースは、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供され、

ネットワーク制御サーバ１００は、各通信装置１４０を接続する通信経路を設定し、通信経路を設定する技術としては、ＯｐｅｎＦｌｏｗを適用することができ、

サービスルックアップサーバ１２０は、端末１７０からのＩＰアドレスの問い合わせに対して、端末１７０から受け取ったドメイン名と、端末１７０の識別子と、アプリケーションの識別子との組合せによって名前解決を実施して、端末１７０にドメイン名に対応するＩＰアドレスを応答し、

続きを表示（全12行）

集約グループ情報記憶部２３１は、端末１７０とアプリケーションの組合せのうち、特徴が類似（または一致）するもの同士を集約したグループの情報を保持する記憶部であり、特徴が類似するとは、ソフトウェアリソースが提供されるサーバ１５０の識別子が同じで、かつ、端末１７０が要求する通信遅延や優先度などの通信特性が同等であることを示し、

設定情報テーブル１９５０には、ルール１９５１～１９５４とアクション１９５５～１９５８が含まれ、ルール１９５１～１９５４は、トラフィックを受信した通信装置１４０が処理方法を判断するための条件を示し、

集約グループ判断、及び、宛先と経路切替の設定を行う処理シーケンスにおいて、

シーケンス２０２０において、端末１７０－１は、サービスルックアップサーバ１２０に名前解決要求を送信し、名前解決要求には、ソフトウェアリソースを提供するドメイン名が含まれ、本ドメイン名は、端末１７０とアプリケーションの組み合わせ毎に、一意に決まるソフトウェアリソースを提供するサーバ１５０の識別子であり、

シーケンス２０５０において、リソース管理サーバ１１０は、リソース提供位置要求２０５０を、ネットワーク制御サーバ１００に通知し、リソース提供位置要求には、要求通信特性情報テーブル１１００が含まれ、

シーケンス２０６０において、ネットワーク制御サーバ１００は、リソース提供位置の判定を行い、

シーケンス２０６０で行われる処理のうち、ステップ５０５０において、集約グループ判断部は、集約グループ情報テーブルの要件を満たす集約グループのうち、コストが最小の集約グループを選択し、

シーケンス２１３０において、ネットワーク制御サーバ１００は、集約グループ宛先情報テーブル１５００に追記した列の設定対象通信装置１５０２に、設定変更メッセージを送信し、設定変更メッセージには、設定情報テーブル１９５０が含まれる、方法。」

２ 引用文献２について

原査定で引用された引用文献２には、段落【００５８】－【００５９】に、以下の記載がある。

「【００５８】後述のように、ネットワーク構築によって経路テーブル及び最適経路テーブルが作成される（３０２）。親は、ネットワーク構築を終えた後、作成した最適経路テーブルの最適化処理（３０３）及び伝送失敗ログテーブルの初期化処理（３０４）を実行した上で、定常動作（３０５）に移行する。定常動作中は、親は、所定のスケジュールに従って、またホスト１０から網１１経由で与えられる要求に応じて、データの設定／収集を実行する。データ設定／収集は、そのヘッダ部分にルート情報を設定した電文により行う（先にふれたネットワーク構築の際のデータ伝送も同じくルート情報をヘッダ中にセットした電文により行う）。また、データ設定／収集のための通信は、子が自発的に開始するものではなく、親が開始する。複数の経路についてのデータ設定／収集に当たっては、親がポーリングを行う。

【００５９】更に、無線環境の変化、各ＧＷの動作不調、ＧＷの増設／撤去等に対処するため、親は、定常動作中、所定時間毎に異常監視を実行し（３０６）、その結果に応じネットワーク修復処理を行う（３０７）。異常監視は、経路テーブルや最適経路テーブル上の情報のうち修正する必要がある部分を検出する処理であり、ネットワーク修復は、当該修正を実行する処理である。」

引用文献２の上記記載から、ネットワークの経路設定において、設定状態の異常を検出して修正を行う点は、周知技術であると認められる。

３ 引用文献３について

原査定に引用された引用文献３には、段落【００５４】－【００５５】に、以下の記載がある。

「【００５４】図６は、ＯｐｅｎＦｌｏｗを使用して本発明を実現する場合の概略図である。

【００５５】ＯｐｅｎＦｌｏｗスイッチ６１０内の転送ルールと転送テーブルは、リモートコントローラ６２０によって展開できる。新しいルーティングプロトコル等はすべて、コントローラ６２０上のプログラミングにより実装される。・・・（以下略）」

引用文献３の上記記載から、ＯｐｅｎＦｌｏｗ技術において「転送ルール」を利用する点は、周知技術であると認められる。

４ 引用文献４について

原査定に引用された引用文献４には、段落【００２１】－【００２３】に、以下の記載がある。

「【００２１】 これにより、前記経路要求の送信元は、第３の経路要求調停装置１０Ｃが提供可能なリソース量を把握した上で、サービスレベルの条件（条件Ａ１）を引き下げて経路要求を再送するか否かを判断することができる。図２の例では、第１の経路要求調停装置１０Ａに対して、サービスレベルの条件を、第３の経路要求調停装置１０Ｃから応答された条件（Ａ２）に引き下げて経路要求を再送しているため、交渉が成立し、経路要求調停装置１０Ａ～１０Ｃのそれぞれにおいて、引き下げられた条件（Ａ２）にてリソースの確保が行われている（Ｓ００６～Ｓ０１０）。

・・・（省略）・・・

【００２３】 以上のように、本実施形態によれば、個々のネットワークに配置された経路要求調停装置が自律的に経路要求を転送していき、宛先のネットワークの経路要求調停装置から、提供可能なリソース量のフィードバックを受けて、再度経路要求を行うという形態の対話的な調停プロトコルが実現される。これにより、経路要求元は、少しだけ条件を緩和（引き下げる）させる希望のサービスが受けられる、コストが掛かっても、他のネットワークで条件に合ったサービスを受けたほうが良い、といった柔軟な判断を行うことが可能になる。」

引用文献４の上記記載から、ネットワークの経路設定において、通信条件を緩和して調停を行う点は、周知技術であると認められる。

第６ 対比・判断

１ 本願発明１について

（１） 対比

本願発明１と、引用発明とを対比すると、以下のことがいえる。

ア 引用発明の「ソフトウェアリソース」は、「ソフトウェアリソースは、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供され」るから、本願発明１の「サービス」に相当する。

よって、引用発明の「端末のユーザが利用するソフトウェアリソースを提供する」「方法」は、本願発明１の「サービスを構成する方法」に相当する。

イ

（ア） 引用発明の「シーケンス２０２０において、端末１７０－１は、サービスルックアップサーバ１２０に名前解決要求を送信し」、「サービスルックアップサーバ１２０は、端末１７０からのＩＰアドレスの問い合わせに対して、端末１７０から受け取ったドメイン名と、端末１７０の識別子と、アプリケーションの識別子との組合せによって名前解決を実施して」いることは、本願発明１が「識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップ」を備えることと、「識別子情報を取得するステップ」を備える点で共通するといえる。

（イ） 引用発明の「集約グループ」は、本願発明１の「第1のデバイス・グループ」に相当する。

よって、引用発明の「集約グループ情報記憶部２３１は、端末１７０とアプリケーションの組合せのうち、特徴が類似（または一致）するもの同士を集約したグループの情報を保持する記憶部であ」ることは、本願発明１が「前記第1のデバイス・グループは、前記サービスを要求するデバイスを含」むことに相当する。

（ウ） 引用発明の「端末１７０が要求する通信遅延や優先度などの通信特性」は、本願発明１の「条件」に相当する。

よって、引用発明の「集約グループ情報記憶部２３１は、端末１７０とアプリケーションの組合せのうち、特徴が類似（または一致）するもの同士を集約したグループの情報を保持する記憶部であり、特徴が類似するとは、ソフトウェアリソースが提供されるサーバ１５０の識別子が同じで、かつ、端末１７０が要求する通信遅延や優先度などの通信特性が同等であることを示」すことは、本願発明１が「前記条件は、前記サービスに対応する通信要件であり、前記第1のデバイス・グループは、前記サービスに対応する同じ通信要件を満たすことが可能であるデバイスの組である」ことに相当する。

（エ） 上記（ア）－（ウ）より、引用発明が「シーケンス２０２０」で「名前解決」処理を行うことは、本願発明１が「識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップであって、前記識別子情報は、第1のデバイス・グループを識別するのに使用され、前記第1のデバイス・グループは、前記サービスを要求するデバイスを含み、前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し、前記条件は、前記サービスに対応する通信要件であり、前記第1のデバイス・グループは、前記サービスに対応する同じ通信要件を満たすことが可能であるデバイスの組である、ステップ」を備えることと、「識別子情報を取得するステップであって、前記第1のデバイス・グループは、前記サービスを要求するデバイスを含み、前記条件は、前記サービスに対応する通信要件であり、前記第1のデバイス・グループは、前記サービスに対応する同じ通信要件を満たすことが可能であるデバイスの組である、ステップ」を備える点で共通するといえる。

ウ 引用発明の「ステップ５０５０において、集約グループ判断部は、集約グループ情報テーブルの要件を満たす集約グループ」を決定していることは、本願発明１が「前記取得した識別子情報にしたがって、前記契約の前記決定されたタイプに対応する候補デバイス・グループを取得するステップ」を備えることと、「候補デバイス・グループを取得するステップ」を備える点で共通するといえる。

エ 引用発明の「ステップ５０５０において、集約グループ判断部は、集約グループ情報テーブルの要件を満たす集約グループのうち、コストが最小の集約グループを選択し」ていることは、本願発明１が「前記識別子情報及び前記条件にしたがって、前記サービスに対応する前記同じ通信要件を満たすことが可能である前記第1のデバイス・グループに対応する前記候補デバイス・グループから前記契約の前記決定されたタイプに対応するネットワーク・デバイス・グループを選択し、前記識別子情報及び前記条件にしたがって、前記ネットワーク・デバイス・グループについての情報を取得するステップであって、前記ネットワーク・デバイス・グループは、前記条件を満たすネットワーク・デバイスを含む、ステップ」を備えることと、「前記条件にしたがって、前記サービスに対応する前記同じ通信要件を満たすことが可能である前記第1のデバイス・グループに対応する前記候補デバイス・グループから、ネットワーク・デバイス・グループを選択するステップであって、前記ネットワーク・デバイス・グループは、前記条件を満たすネットワーク・デバイスを含む、ステップ」を備える点で共通するといえる。

オ 引用発明の「シーケンス２１３０において、ネットワーク制御サーバ１００は、集約グループ宛先情報テーブル１５００に追記した列の設定対象通信装置１５０２に、設定変更メッセージを送信し、設定変更メッセージには、設定情報テーブル１９５０が含まれ」ることは、「設定情報テーブル１９５０には、ルール１９５１～１９５４とアクション１９５５～１９５８が含まれ、ルール１９５１～１９５４は、トラフィックを受信した通信装置１４０が処理方法を判断するための条件を示し」ているから、本願発明１が「前記条件にしたがって、第1の転送規則を取得するステップであって、前記第1の転送規則は、前記ネットワーク・デバイス・グループに対応し、前記第1の転送規則は、前記ネットワーク・デバイス・グループの中の前記ネットワーク・デバイスが、前記第1のデバイス・グループの中の前記デバイスに前記サービスを提供することを可能とするのに使用される、ステップと、

前記第1の転送規則を送信するステップと、を含む」ことに相当する。

カ したがって、本願発明１と引用発明との間には、次の一致点、相違点があるといえる。

［一致点］

「サービスを構成する方法であって、

識別子情報を取得するステップであって、前記第1のデバイス・グループは、前記サービスを要求するデバイスを含み、前記条件は、前記サービスに対応する通信要件であり、前記第1のデバイス・グループは、前記サービスに対応する同じ通信要件を満たすことが可能であるデバイスの組である、ステップと、

候補デバイス・グループを取得するステップと、

前記条件にしたがって、前記サービスに対応する前記同じ通信要件を満たすことが可能である前記第1のデバイス・グループに対応する前記候補デバイス・グループからネットワーク・デバイス・グループを選択するステップであって、前記ネットワーク・デバイス・グループは、前記条件を満たすネットワーク・デバイスを含む、ステップと、

前記条件にしたがって、第1の転送規則を取得するステップであって、前記第1の転送規則は、前記ネットワーク・デバイス・グループに対応し、前記第1の転送規則は、前記ネットワーク・デバイス・グループの中の前記ネットワーク・デバイスが、前記第1のデバイス・グループの中の前記デバイスに前記サービスを提供することを可能とするのに使用される、ステップと、

前記第1の転送規則を送信するステップと、を含む、

方法。」

［相違点１］

本願発明１では、「識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップ」を備え、「前記識別子情報は、第1のデバイス・グループを識別するのに使用され」、「前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し」ているのに対して、引用発明の「シーケンス２０２０」における「名前解決」処理は、識別子情報、「サービス・タイプ、及び条件を含む契約」を取得するステップではなく、引用発明の「識別子」とは「端末１７０の識別子と、アプリケーションの識別子」であって「前記識別子情報は、第1のデバイス・グループを識別するのに使用され」るものではなく、引用発明では、「前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し」ていない点。

［相違点２］

本願発明１では、「前記サービス・タイプに基づいて、前記契約の前記タイプを決定するステップ」を備えるのに対して、引用発明では、「前記サービス・タイプに基づいて、前記契約の前記タイプを決定するステップ」を備えていない点。

［相違点３］

本願発明１では、「前記取得した識別子情報にしたがって、前記契約の前記決定されたタイプに対応する」候補デバイス・グループを取得するステップを備えるのに対して、引用発明では、「前記取得した識別子情報にしたがって、前記契約の前記決定されたタイプに対応する」候補デバイス・グループを取得することが特定されていない点。

［相違点４］

本願発明１では、「前記識別子情報及び前記条件にしたがって、前記サービスに対応する前記同じ通信要件を満たすことが可能である前記第1のデバイス・グループに対応する前記候補デバイス・グループから前記契約の前記決定されたタイプに対応するネットワーク・デバイス・グループを選択し、前記識別子情報及び前記条件にしたがって、前記ネットワーク・デバイス・グループについての情報を取得するステップ」を備えているのに対して、引用発明では、「前記識別子情報及び」前記条件にしたがって、前記サービスに対応する前記同じ通信要件を満たすことが可能である前記第1のデバイス・グループに対応する前記候補デバイス・グループから「前記契約の前記決定されたタイプに対応する」ネットワーク・デバイス・グループを選択し、「前記識別子情報及び前記条件にしたがって、前記ネットワーク・デバイス・グループについての情報を取得」するステップを備えていない点。

（３） 当審の判断

上記［相違点１］について検討すると、上記［相違点１］に係る、「識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップ」を備え、「前記識別子情報は、第1のデバイス・グループを識別するのに使用され」、「前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し」ている構成は、上記引用文献１－４には記載されておらず、周知技術であるともいえない。

したがって、本願発明１は、上記相違点２－４について判断するまでもなく、当業者であっても引用発明、引用文献２－４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

２ 請求項２－５０について

本願発明２－５０も、本願発明１の上記［相違点１］に係る、「識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップ」を備え、「前記識別子情報は、第1のデバイス・グループを識別するのに使用され」、「前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し」ている構成と、（実質的に）同一の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明、引用文献２－４に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

第７ 当審拒絶理由について

１．理由１（特許法第３６条第６項第２号）について

当審では、請求項１において、（１）「識別子情報」と「サービス・タイプ」とから「候補デバイス・グループを取得するステップ」とは、具体的にどのような処理を行うステップであるのかが明細書を参照しても不明確であり、（２）「第1のデバイス・グループ」とは、「サービスを提供する」デバイスであるのか、「サービスを提供される」（サービスを要求する）デバイスであるのかが不明確である旨の拒絶の理由を通知しているが、令和４年１２月１３日付けの手続補正において、（１）「前記取得した識別子情報にしたがって、前記契約の前記決定されたタイプに対応する候補デバイス・グループを取得するステップ」であることを明確にする補正がなされるとともに、（２）「前記第1のデバイス・グループは、前記サービスを要求するデバイスを含」むことを明確にする補正がなされた結果、この拒絶の理由は解消した。

第８ 原査定についての判断

令和４年１２月１３日付けの手続補正により、補正後の請求項１－５０は、本願発明１の上記［相違点１］に係る、「識別子情報、サービス・タイプ、及び条件を含む契約を取得するステップ」を備え、「前記識別子情報は、第1のデバイス・グループを識別するのに使用され」、「前記サービス・タイプは、アクセス契約、ルーティング契約、及びマルチキャスト契約を含む前記契約のタイプを識別し」ているという技術的事項を有するものとなった。

当該技術的事項は、原査定における引用文献１－４には記載されておらず、周知技術でもないので、本願発明１－５０は、当業者であっても、原査定における引用文献１－４に基づいて容易に発明をすることができたものではない。

したがって、原査定を維持することはできない。

第９ むすび

以上のとおり、原査定の理由によって、本願を拒絶することはできない。

他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。