2020-003417

第２　原査定の概要

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

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

引用文献等一覧

１．特表２００２－５２５９７３号公報

第３　本願発明

本願請求項１－１５に係る発明（以下、それぞれ「本願発明１」－「本願発明１５」という。）は、令和２年３月１２日になされた手続補正で補正された特許請求の範囲の請求項１－１５に記載された事項により特定される発明であり、本願発明１－１５は以下のとおりの発明である（下線部は補正箇所を示す。）。

「　　【請求項１】

リソースコンフィギュレーション方法であって、

リソース要求をサーバサイドが取得する段階であって、前記リソース要求は、前記リソース要求に示されるリソースについての情報を備える、段階と、

ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、前記リソース要求をクライアントに前記サーバサイドが送信する段階と、

続きを表示（全84行）

前記クライアントから送信されたリソース応答を前記サーバサイドが受信する段階であって、前記リソース応答は、前記サーバサイドに割り当てられるリソースについての情報を備える、段階と

を備える方法であって、

リソース要求をサーバサイドが取得する前記段階の前に、

前記サーバサイドによって使用されるリソースが条件を満たすかを前記サーバサイドが判断する段階であって、前記条件は、前記サーバサイドのリソース使用量を表すために使用される、段階をさらに備え、

リソース要求をサーバサイドが取得する前記段階は、

前記サーバサイドによって使用される前記リソースが前記条件を満たすと判断したとき、前記サーバサイドによって使用される前記リソースと前記条件とにしたがって、前記リソース要求を前記サーバサイドが生成する段階

を有する、方法。

【請求項２】

ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、前記リソース要求をクライアントに前記サーバサイドが送信する前記段階の前に、

前記サーバサイドとアクティブクライアントとの間の通信が異常であると判断したとき、対応関係と前記アクティブクライアントとにしたがって、スタンバイクライアントを前記クライアントとして前記サーバサイドが選択する段階であって、前記対応関係は、前記アクティブクライアントについての情報および前記スタンバイクライアントについての情報を含む、段階をさらに備える、

請求項１に記載の方法。

【請求項３】

前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、

前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、

請求項１または２に記載の方法。

【請求項４】

前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、

前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用される、

請求項１から３のいずれか一項に記載の方法。

【請求項５】

前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、

前記リソース応答に示される前記リソースについての前記情報は、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、

請求項１から３のいずれか一項に記載の方法。

【請求項６】

リソースコンフィギュレーション方法であって、

ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、サーバサイドによって送信されたリソース要求をクライアントが受信する段階であって、前記リソース要求は、前記リソース要求に示されるリソースについての情報を備える、段階と

前記リソース要求に示される前記リソースについての前記情報にしたがって、前記サーバサイドに割り当てられるリソースについての情報を前記クライアントが取得する段階と、

リソース応答を前記サーバサイドに前記クライアントが送信する段階であって、前記リソース応答は、前記サーバサイドに割り当てられる前記リソースについての前記情報を備える、段階と

を備え、

前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含む、または、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、

前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、

前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含む、または、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、

前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用され、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、

方法。

【請求項７】

前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、

前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、

請求項６に記載の方法。

【請求項８】

サーバサイドとして動作する装置であって、

リソース要求を取得する取得モジュールであって、前記リソース要求は、サーバサイドとして動作する前記装置によって前記リソース要求に示されるリソースについての情報を含む、取得モジュールと、

ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、クライアントとして動作する装置に前記リソース要求を送信する送信モジュールと、

クライアントとして動作する前記装置によって送信されたリソース応答を受信する受信モジュールであって、前記リソース応答は、サーバサイドとして動作する前記装置に割り当てられるリソースについての情報を含む、受信モジュールと、

サーバサイドとして動作する前記装置によって使用されるリソースが条件を満たすかを判断する判断モジュールであって、前記条件は、サーバサイドとして動作する前記装置のリソース使用量を表すために使用される、判断モジュールと

を備え、

前記取得モジュールは具体的に、サーバサイドとして動作する前記装置によって使用される前記リソースが前記条件を満たすと判断したとき、サーバサイドとして動作する前記装置によって使用される前記リソースと前記条件とにしたがって、前記リソース要求を生成する、

装置。

【請求項９】

クライアントとして動作する前記装置に前記リソース要求を前記送信モジュールが送信する前に、サーバサイドとして動作する前記装置と、クライアントとして動作するアクティブ装置との間の通信が正常であると判断したとき、クライアントとして動作する前記アクティブ装置をクライアントとして動作する前記装置として選択する第１の選択モジュール

をさらに備える、請求項８に記載の装置。

【請求項１０】

クライアントとして動作する前記装置に前記リソース要求を前記送信モジュールが送信する前に、サーバサイドとして動作する前記装置と、クライアントとして動作するアクティブ装置との間の通信が異常であると判断したとき、対応関係と、クライアントとして動作する前記アクティブ装置とにしたがって、クライアントとして動作するスタンバイ装置をクライアントとして動作する前記装置として選択する第２の選択モジュールであって、前記対応関係は、クライアントとして動作する前記アクティブ装置についての情報と、クライアントとして動作する前記スタンバイ装置についての情報とを含む、第２の選択モジュールをさらに備える、

請求項８または９に記載の装置。

【請求項１１】

前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、

前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、

請求項８から１０のいずれか一項に記載の装置。

【請求項１２】

前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、

前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用される、

請求項８から１０のいずれか一項に記載の装置。

【請求項１３】

前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、

前記リソース応答に示される前記リソースについての前記情報は、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、

請求項８から１０のいずれか一項に記載の装置。

【請求項１４】

クライアントとして動作する装置であって、

ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、サーバサイドとして動作する装置によって送信されたリソース要求を受信する受信モジュールであって、前記リソース要求は、サーバサイドとして動作する前記装置によって前記リソース要求に示されるリソースについての情報を含む、受信モジュールと、

前記リソース要求に示される前記リソースについての前記情報にしたがって、サーバサイドとして動作する前記装置に割り当てられるリソースについての情報を取得する取得モジュールと、

サーバサイドとして動作する前記装置にリソース応答を送信する送信モジュールであって、前記リソース応答は、サーバサイドとして動作する前記装置に割り当てられる前記リソースについての前記情報を含む、送信モジュールと

を備え、

前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含む、または、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、

前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、

前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含む、または、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、

前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用され、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、

装置。

【請求項１５】

前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、

前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、

請求項１４に記載の装置。」

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

１　引用文献１について

原査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている（下線は当審において付与した。）。

ア　「　　【請求項１３】 インターネットプロトコル（ＩＰ）アドレスを割り当てる方法において、

ａ）ポイントツーポイントプロトコルを使用してワイヤレスリンクを通してアドレス要求メッセージをネットワークリモートサーバに送信し、

ｂ）ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信し、

ｃ）有線ブロードキャスト媒体を通して端末装置ユニットからＩＰアドレスに対する要求を受信し、

ｄ）有線ブロードキャスト媒体を通して端末装置ユニットに送信するための割当可能なＩＰアドレスを含む応答ＩＰアドレス割当メッセージをローカル的に発生させるステップを含む方法。」

イ　「　　　【０００１】

【発明の属する技術分野】

本発明はワイヤレス通信システムに関する。特に本発明はデータ端末装置をワイヤレスデータネットワークにインターフェイスさせる技術に関する。」

ウ　「　　　【００１３】

スペクトルリソースの限定された利用可能性のために、ワイヤレスリンクの容量は非常に貴重なリソースである。単一メッセージを非常に多くのステーションにブロードキャストすると著しいリソースを消費する。この理由のために、イーサネットタイプのブロードキャストメッセージングを使用してワイヤレスリンクを動作させることは実用的ではない。

【００１４】

【発明が解決しようとする課題】

しかしながら、先に述べたように、ワイヤレスリンクをデジタルデータネットワークに導入する際に標準端末装置ユニットインターフェイスメカニズムを使用することは重要である。したがって、工業界には標準端末装置ユニットと高速ワイヤレスリンクとの間のインターフェイスを提供する必要性が存在している。

【００１５】

【課題を解決するための手段】

ワイヤレスモデムを使用して、ワイヤレスリンクを通してイーサネットユニットのような有線ブロードキャスト媒体端末装置ユニットをネットワークユニットに接続する。ワイヤレスリンクを通してネットワークユニットからのブロードキャストメッセージの送信を避けるために、ローカルサーバがワイヤレスモデム内に組み込まれる。端末装置ユニットがアドレスに対する要求をネットワークユニットに送信するとき、ワイヤレスモデムがメッセージを傍受する。ローカルサーバはＩＰアドレスを端末装置ユニットに割り当て、端末装置ユニットに応答する。この方法では、端末装置ユニットを何らかの方法で修正する必要はない。」

エ　「　　　【００１８】

図３はワイヤレスリンク５６を含むデータシステムを示しているブロック図である。標準端末装置ユニット４０がイーサネット接続を通してワイヤレスモデム４２に接続されている。イーサネットは有線物理レイヤと、２つ以上の端末装置ユニットを接続するのに使用されるリンクレイヤプロトコルとを規定する。物理レイヤはネットワーク上の２つ以上のステーション間の物理リンクを作動、維持、および不作動させるための電気的、機械的、手続的、および機能的仕様を規定している。電圧レベル、電圧レベル遷移のタイミング、物理データレート、最大送信距離、物理コネクタタイプ、および他の同様な属性のようなこのような特性は物理レイヤ仕様により規定される。リンクレイヤは物理リンクを通るデータの信頼性ある送信を提供する。そのように行う際に、リンクレイヤは物理アドレッシング、ネットワークトポロジー、エラー通知、フレームの順序付け配信およびフロー制御に関係している。

【００１９】

先に言及したように、イーサネットはブロードキャストメッセージを使用して動作する。ブロードキャストシステムでは、ネットワーク中の各ステーションは各データフレームを調査してフレームがそのステーションに向けられているか否かを決定する。ブロードキャストシステムでは各メッセージはネットワーク上のすべてのステーションに送られるかもしれないので、ブロードキャストシステムはメッセージが向けられていないステーションに対してメッセージの送信を要求するかもしれないことから、ブロードキャストシステムはワイヤレスリンクリソースの有効な使用をもたらさない。

【００２０】

したがって、図３中のワイヤレスモデム４２は、端末装置ユニット４０とワイヤレスモデム４２とを接続するイーサネットシステムと、ワイヤレスリンク５６を通してワイヤレスモデム４２とネットワークユニット５８とを接続する標準インターネットプロトコル（ＩＰ）スイートシステムとの間のゲートウェイとして機能する。ＩＰスイートは多様な範囲のローカルエリアネットワーク（ＬＡＮ）とワイドエリアネットワーク（ＷＡＮ）をインターネットワークするのに使用される。例えば、最近２０年では、ネットワークはイーサネット、トークンリング、Ｘ．２５、フレームリレー、統合サービスデジタルネットワーク（ＩＳＤＮ）、および非同期転送モード（ＡＴＭ）にしたがって動作するように実現されてきた。ＩＰスイートはこれらのネットワークのそれぞれを他の任意のネットワークと相互接続させる手段を提供する。」

オ　「　　　【００２６】

端末装置ユニット４０がワイヤレスリンク５６を通してＩＰデータグラムを送信または受信できる前に、それぞれがシステム内で独立してアドレス指定されるように、端末装置ユニット４０にはワイヤレスモデム４２とともにＩＰアドレスが割り当てられなければならない。さらに、独立したＩＰアドレスを使用すると、端末装置ユニット４０とワイヤレスモデム４２は相互に向けられるＩＰメッセージを交換することができる。図３では、ネットワークユニット５８はネットワークリモートサーバ６０と関係しており、ネットワークリモートサーバ６０は、数ある機能の中で、標準ネットワーク情報センタープロトコルにしたがってネットワークユニット５８に接続された有線端末装置ユニットからのブロードキャストメッセージを監視する。ＩＰアドレスをネットワーク上のステーションに割り当てるプロセスはネットワーク管理の一部である。ネットワーク管理は、ネットワーク自体を通信および構成の媒体として使用して中央位置からその自己のリソースを取り扱うネットワーク能力に関係している。ネットワーク管理の１つの領域はネットワーク初期設定である。ＩＰシステムでは、設定をステーション内で固定させるかあるいは人間のユーザによりプログラムさせるよりむしろ、ネットワークに各ステーションのネットワーク設定を決定させることが有効である。この方法では、例えばＩＰアドレスナンバリング方式を変更することは、ネットワーク中の各ステーション上での人によるＩＰアドレス変更よりむしろ、少ないサーバ上での変更しか必要としない。またＩＰアドレスの割り当てをネットワークリモートサーバ６０に割り振ることにより、ユーザ自体はＩＰアドレスの割当プロセスを理解する必要がない。

【００２７】

ＩＰスイートにしたがって動作している標準有線ネットワークでは、端末装置ユニットに最初に電源が投入されるとき、端末装置ユニットはネットワークリモートサーバ６０に向けられたメッセージをブロードキャストする。ブロードキャストメッセージは端末装置ユニットの永久的なハードウェアアドレスと、ＩＰアドレスに対する端末装置ユニットの要求を指定する。ＢｏｏｔＰやＤＨＣＰのような、いくつかの標準ネットワーク情報センタープロトコルが開発されてきた。ＢｏｏｔＰはイーサネットアドレスに基づいてＩＰアドレスを割り当てる簡単な方法である。ＢｏｏｔＰに関する付加的な情報は“ブートストラッププロトコル（ＢｏｏｔＰ）”と題するＲＦＣ－９５１で見出すことができる。ＤＨＣＰはＢｏｏｔＰに対する拡張として構成されており、付加的な情報を要求ユニットに通信することができ、付加的な情報はこれをローカルエリアネットワークホストの初期設定に対するポピュラーな解決方法にしている。ＤＨＣＰに対する付加的な情報は“ダイナミックホスト構成プロトコル”と題するＲＦＣ－２１３１で見出すことができる。

【００２８】

端末装置ユニットからのブロードキャスト要求に応答して、ネットワークリモートサーバ６０は返答メッセージをブロードキャストする。一般的に、返答メッセージはブロードキャストされる。その理由は、要求ユニットがそのＩＰアドレスをまだ知らず、したがってＩＰプロトコルを使用して直接的にアドレス指定されることができないためである。返答メッセージは要求ユニットのハードウェアアドレスと、そのユニットに割り当てられているＩＰアドレスを含む。先に言及したように、図３に示されているシステムへのワイヤレスリンク５６の導入では、ワイヤレスリンク５６の帯域幅と容量を節約して使用するためにメッセージをブロードキャストするのを避けることは有用である。」

カ　「　　　【００３１】

本発明の１つの実施形態では、ワイヤレスモデム４２にはその自己の使用のためにＩＰアドレスが事前割り当てされ、端末装置ユニット４０への割り当てのためのＩＰアドレスが供給される。割り当て可能なアドレスはローカルサーバ５２内に記憶される。典型的な実施形態では、ローカルサーバ５２はワイヤレスモデム４２を有する共通構造およびハウジングと一体化される。図５は一連の２つのプロトコルスタック図であり、それぞれ図３で示されている対応した機能ブロックの動作を図示している。図５のプロトコルスタックは、端末装置ユニット４０とローカルサーバ５２がＢｏｏｔＰアプリケーションレイヤを使用して通信しているときのシステム動作を図示している。電源投入時、端末装置ユニット４０中のＢｏｏｔＰクライアントプロトコルレイヤ９６はブロードキャストメッセージを生成し、それをＩＰレイヤ７０に渡す。このブロードキャストメッセージはＩＰアドレスを要求し、それ自体のハードウェアアドレスを指定する。ＩＰレイヤ７０は要求メッセージをイーサネットレイヤ７２に渡す。イーサネットレイヤ７２はＩＰアドレス要求メッセージを１つ以上のブロードキャストイーサネットフレームにカプセル化し、周知の手順にしたがいイーサネット接続によりそれらをブロードキャストする。

【００３２】

ワイヤレスモデム４２中のイーサネットレイヤ７４はブロードキャストイーサネットフレームを受信する。イーサネットレイヤ７４はブロードキャストイーサネットフレームからＩＰアドレス要求メッセージを取り出し、それをＩＰレイヤ７８に渡す。ＩＰアドレス要求メッセージをリモートサーバ６０に転送するのではなく、ＩＰレイヤ７８はそれをＢｏｏｔＰサーバアプリケーションレイヤ９８に渡す。ＢｏｏｔＰアプリケーションサーバレイヤ９８は次に要求メッセージを、ＩＰアドレスを提供するローカルサーバ内のアプリケーション１００に渡す。ローカルサーバ５２は記憶されているＩＰアドレスの１つを端末装置ユニット４０に割り当てる。アプリケーション１００は応答メッセージを生成し、この応答メッセージはリバースプロトコルスタック動作により、アプリケーション１００からＢｏｏｔＰクライアントプロトコルレイヤ９６に渡される。この方法では、ワイヤレスリンクリソースは、ＩＰアドレス応答メッセージ用のブロードキャストメッセージを端末装置ユニット４０に伝えるのに使用されない。したがって、リモートサーバ６０のこの機能は端末装置ユニット４０のために、ローカルサーバ５２に割り当てられている。代わりに、端末装置ユニット４０は電源投入時に事前割り当てされるＩＰアドレスを持っていてもよい。

【００３３】

ローカルサーバ５２はさまざまな方法の１つで端末装置ユニット４０に対するＩＰアドレスを獲得してもよい。例えば、１つの実施形態では、ワイヤレスモデム４２はカスタムＩＰアドレス要求メッセージを生成して送信してもよく、このＩＰアドレス要求メッセージはリモートサーバ６０からの１つ以上のＩＰアドレスを要求する。カスタムＩＰアドレス要求メッセージはより低いレイヤプロトコルではなくアプリケーションから発信され、この方法では、このような標準的なより低いレイヤプロトコルの修正を避ける。ワイヤレスモデム４２で利用可能な機能のライブラリへのカスタムＩＰアドレス要求メッセージの追加は大きな負担とならない。その理由はワイヤレスモデム４２はカスタムアプリケーションレイヤソフトウェアを実行させる新しいエンティティであるからである。ワイヤレスモデム４２を修正して端末装置ユニット４０のために、そしておそらく自己のためにも１つ以上のＩＰアドレスを取得させることにより、端末装置ユニット４０の修正は避けることができる。」

キ　「　　　【００３８】

ワイヤレスリンク接続は複数の周知あるいは後で開発された動作プロトコルの１つのもとで動作させてもよい。例えば、ワイヤレスリンクは時分割多元接続、符号分割多元接続、あるいはポイントツーポイント接続をサポートする他のインターフェイスを使用して動作させてもよい。」

ク　「【図３】

」

以上ア～クより、特に下線部に着目すると、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。

「ワイヤレスリンク５６を含むデータシステムにおいて、

標準端末装置ユニット４０がイーサネット接続を通してワイヤレスモデム４２に接続されており、

ローカルサーバがワイヤレスモデム内に組み込まれ、

ワイヤレスモデム４２は、端末装置ユニット４０とワイヤレスモデム４２とを接続するイーサネットシステムと、ワイヤレスリンク５６を通してワイヤレスモデム４２とネットワークユニット５８とを接続する標準インターネットプロトコル（ＩＰ）スイートシステムとの間のゲートウェイとして機能し、

ネットワークユニット５８はネットワークリモートサーバ６０と関係しており、

ワイヤレスモデム４２にはその自己の使用のためにＩＰアドレスが事前割り当てされ、端末装置ユニット４０への割り当てのためのＩＰアドレスが供給され、割り当て可能なアドレスはローカルサーバ５２内に記憶され、

ローカルサーバ５２はさまざまな方法の１つで端末装置ユニット４０に対するＩＰアドレスを獲得してもよく、ワイヤレスモデム４２はカスタムＩＰアドレス要求メッセージを生成して送信してもよく、このＩＰアドレス要求メッセージはリモートサーバ６０からの１つ以上のＩＰアドレスを要求し、

ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信する、

方法。」

第５　対比・判断

１　本願発明１について

（１）対比

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

ア　引用発明の「ローカルサーバ」が組み込まれた「ワイヤレスモデム４２」は、サーバとしての機能を有しているから、本願発明１の「サーバサイド」に相当する。

イ　引用発明の「ＩＰアドレス」と、本願発明１の「リソース」とは、「通信資源」である点で共通する。

ウ　引用発明の「カスタムＩＰアドレス要求メッセージ」と、本願発明１の「リソース要求」とは、「通信資源の要求」である点で共通する。そして、引用発明の「カスタムＩＰアドレス要求メッセージ」が、要求する「ＩＰアドレス」についての情報を備えていることは明らかであるから、引用発明の「ワイヤレスモデム４２」が「カスタムＩＰアドレス要求メッセージを生成」することと、本願発明１の「リソース要求をサーバサイドが取得する段階であって、前記リソース要求は、前記リソース要求に示されるリソースについての情報を備える、段階」とは、「通信資源の要求をサーバサイドが取得する段階であって、前記通信資源の要求は、前記通信資源の要求に示される通信資源についての情報を備える、段階」である点で共通する。

エ　引用発明の「リモートサーバ６０」と、本願発明１の「クライアント」とは、「通信装置」である点で共通する。

オ　引用発明の「ワイヤレスモデム４２」が「カスタムＩＰアドレス要求メッセージ」を「送信」して「リモートサーバ６０からの１つ以上のＩＰアドレスを要求」することと、本願発明１の「ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、前記リソース要求をクライアントに前記サーバサイドが送信する段階」とは、「前記通信資源の要求を通信装置に前記サーバサイドが送信する段階」である点で共通する。

カ　引用発明は、「ワイヤレスモデム４２」が「リモートサーバ６０からの１つ以上のＩＰアドレスを要求」し、「ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信する」との構成を備えるものであり、引用発明の「リモートサーバ６０」が応答する「割当可能なＩＰアドレス」が、「ワイヤレスモデム４２」に割り当てられる「ＩＰアドレス」についての情報を備えていることは明らかである。

よって、引用発明の「割当可能なＩＰアドレス」と、本願発明１の「前記サーバサイドに割り当てられるリソースについての情報を備える」「リソース応答」とは、「前記サーバサイドに割り当てられる通信資源についての情報を備える」「通信資源の応答」である点で共通し、引用発明の「ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信する」ことと、本願発明１の「前記クライアントから送信されたリソース応答を前記サーバサイドが受信する段階であって、前記リソース応答は、前記サーバサイドに割り当てられるリソースについての情報を備える、段階」とは、「前記通信装置から送信された通信資源の応答を前記サーバサイドが受信する段階であって、前記通信資源の応答は、前記サーバサイドに割り当てられる通信資源についての情報を備える、段階」である点で共通する。

キ　引用発明は、「ワイヤレスモデム４２はカスタムＩＰアドレス要求メッセージを生成して送信してもよく、このＩＰアドレス要求メッセージはリモートサーバ６０からの１つ以上のＩＰアドレスを要求」し、「ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信する」との構成を備えるものであり、「ワイヤレスモデム４２」は「ＩＰアドレス要求メッセージ」を送信することで「ＩＰアドレス」の設定を行うものであるから、「ワイヤレスモデム４２」が実施する一連の処理の方法と、本願発明１の「リソースコンフィギュレーション方法」とは、「通信資源のコンフィギュレーション方法」である点で共通する。

（２）一致点・相違点

以上から、本願発明１と引用発明とは、以下の点において一致ないし相違する。

［一致点］

「通信資源のコンフィギュレーション方法であって、

通信資源の要求をサーバサイドが取得する段階であって、前記通信資源の要求は、前記通信資源の要求に示される通信資源についての情報を備える、段階と、

前記通信資源の要求を通信装置に前記サーバサイドが送信する段階と、

前記通信装置から送信された通信資源の応答を前記サーバサイドが受信する段階であって、前記通信資源の応答は、前記サーバサイドに割り当てられる通信資源についての情報を備える、段階と

を備える方法。」

［相違点］

＜相違点１＞

本願発明１は、「通信資源」が「リソース」であり、それに伴い、「通信資源の要求」及び「通信資源の応答」が、それぞれ「リソース要求」及び「リソース応答」であるのに対し、引用発明では、「通信資源」は「ＩＰアドレス」であり、「通信資源の要求」及び「通信資源の応答」についても、それぞれ「リソース要求」及び「リソース応答」と特定されるものではない点。

＜相違点２＞

本願発明１は、通信資源の要求を受信して通信資源の応答を送信する動作の主体が「クライアント」であるのに対し、引用発明では、当該動作の主体が「ネットワークリモートサーバ」である点。

＜相違点３＞

本願発明１は、リソース要求の送信が「ＮＥＴＣＯＮＦ」又は「ＲＥＳＴＣＯＮＦ」に基づいて行われ、「リソース要求をサーバサイドが取得する前記段階の前に、前記サーバサイドによって使用されるリソースが条件を満たすかを前記サーバサイドが判断する段階であって、前記条件は、前記サーバサイドのリソース使用量を表すために使用される、段階をさらに備え、リソース要求をサーバサイドが取得する前記段階は、前記サーバサイドによって使用される前記リソースが前記条件を満たすと判断したとき、前記サーバサイドによって使用される前記リソースと前記条件とにしたがって、前記リソース要求を前記サーバサイドが生成する段階を有する」のに対し、引用発明は、「カスタムＩＰアドレス要求メッセージ」を「送信」するものではあるが、「ＮＥＴＣＯＮＦ」又は「ＲＥＳＴＣＯＮＦ」を使用することは特定されておらず、「前記サーバサイドによって使用されるリソースが条件を満たすかを前記サーバサイドが判断する段階であって、前記条件は、前記サーバサイドのリソース使用量を表すために使用される、段階」及び「前記サーバサイドによって使用される前記リソースが前記条件を満たすと判断したとき、前記サーバサイドによって使用される前記リソースと前記条件とにしたがって、前記リソース要求を前記サーバサイドが生成する段階」を備えることも特定されていない点。

（３）相違点についての判断

事案に鑑みて、上記相違点３について先に検討する。

引用文献１には、「カスタムＩＰアドレス要求メッセージ」の送信を「ＮＥＴＣＯＮＦ」又は「ＲＥＳＴＣＯＮＦ」に基づいて行うこと、及び「カスタムＩＰアドレス要求メッセージ」を「生成」する前に、「前記サーバサイドによって使用されるリソース」が「前記サーバサイドのリソース使用量を表すために使用される」「条件」を満たすかを「判断」し、「前記サーバサイドによって使用される前記リソースが前記条件を満たすと判断したとき、前記サーバサイドによって使用される前記リソースと前記条件とにしたがって、前記リソース要求を前記サーバサイドが生成」することは記載も示唆もされておらず、これらの構成は本願の優先日前において周知技術であるともいえない。

そして、本願発明１は、これらの構成を備えることで、「サーバサイドのリソース要求にしたがってクライアントによってサーバサイドに割り当てられるリソースは、サーバサイドの実際の要件をより良く満たすことができ、それによって、リソースを浪費する可能性の低減を助ける」という有利な効果を奏するものである。

したがって、本願発明１は、他の相違点について検討するまでもなく、当業者であっても、引用発明に基づいて容易に発明できたものであるとはいえない。

２　本願発明２－５、８－１３について

本願発明２－５、８－１３も、上記相違点３に係る本願発明１の構成と同様の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明に基づいて容易に発明できたものであるとはいえない。

３　本願発明６について

（１）対比

本願発明６と引用発明とを対比すると、次のことがいえる。

ア　引用発明の「ローカルサーバ」が組み込まれた「ワイヤレスモデム４２」は、サーバとしての機能を有しているから、本願発明６の「サーバサイド」に相当する。

イ　引用発明の「ＩＰアドレス」と、本願発明６の「リソース」とは、「通信資源」である点で共通する。

ウ　引用発明の「カスタムＩＰアドレス要求メッセージ」と、本願発明６の「リソース要求」とは、「通信資源の要求」である点で共通する。

エ　引用発明は、「ワイヤレスモデム４２はカスタムＩＰアドレス要求メッセージを生成して送信してもよく、このＩＰアドレス要求メッセージはリモートサーバ６０からの１つ以上のＩＰアドレスを要求し」との構成を備えるものであるから、引用発明の「リモートサーバ６０」が、「ワイヤレスモデム４２」から送信される「ＩＰアドレス要求メッセージ」を受信することは明らかである。

また、引用発明の「カスタムＩＰアドレス要求メッセージ」が、要求する「ＩＰアドレス」についての情報を備えていることは明らかである。

よって、引用発明の「リモートサーバ６０」と、本願発明６の「クライアント」とは、「通信装置」である点で共通し、引用発明の「ワイヤレスモデム４２」が「カスタムＩＰアドレス要求メッセージ」を「送信」して「リモートサーバ６０からの１つ以上のＩＰアドレスを要求」することと、本願発明６の「ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、サーバサイドによって送信されたリソース要求をクライアントが受信する段階であって、前記リソース要求は、前記リソース要求に示されるリソースについての情報を備える、段階」とは、「サーバサイドによって送信された通信資源の要求を通信装置が受信する段階であって、前記通信資源の要求は、前記通信資源の要求に示される通信資源についての情報を備える、段階」である点で共通する。

オ　引用発明は、「ワイヤレスモデム４２はカスタムＩＰアドレス要求メッセージを生成して送信してもよく、このＩＰアドレス要求メッセージはリモートサーバ６０からの１つ以上のＩＰアドレスを要求し、ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信する」との構成を備えるものであるから、引用発明の「リモートサーバ６０」が、「ワイヤレスモデム４２」から送信される「カスタムＩＰアドレス要求メッセージ」を受け、応答としての「割当可能なＩＰアドレス」を取得して「ワイヤレスモデム４２」に対して送信するものであることは明らかである。

また、引用発明の「リモートサーバ６０」が応答する「割当可能なＩＰアドレス」は、「ワイヤレスモデム４２」に割り当てられる「ＩＰアドレス」についての情報を備えていることは明らかであるから、本願発明６の「前記サーバサイドに割り当てられる前記リソースについての前記情報を備える」「リソース応答」とは、「前記サーバサイドに割り当てられる前記通信資源についての前記情報を備える」「通信資源の応答」である点で共通する。

よって、引用発明の「リモートサーバ６０」が、「ワイヤレスモデム４２」から送信される「アドレス要求メッセージ」を受けて、応答としての「割当可能なＩＰアドレス」を取得して「ワイヤレスモデム４２」に対して送信することと、本願発明６の「前記リソース要求に示される前記リソースについての前記情報にしたがって、前記サーバサイドに割り当てられるリソースについての情報を前記クライアントが取得する段階と、リソース応答を前記サーバサイドに前記クライアントが送信する段階であって、前記リソース応答は、前記サーバサイドに割り当てられる前記リソースについての前記情報を備える、段階」とは、「前記通信資源の要求に示される前記通信資源についての前記情報にしたがって、前記サーバサイドに割り当てられる通信資源についての情報を前記通信装置が取得する段階と、通信資源の応答を前記サーバサイドに前記通信装置が送信する段階であって、前記通信資源の応答は、前記サーバサイドに割り当てられる前記通信資源についての前記情報を備える、段階」である点で共通する。

カ　引用発明は、「ワイヤレスモデム４２はカスタムＩＰアドレス要求メッセージを生成して送信してもよく、このＩＰアドレス要求メッセージはリモートサーバ６０からの１つ以上のＩＰアドレスを要求し、ワイヤレスリンクを通してのアドレス要求メッセージに応答したネットワークリモートサーバから割当可能なＩＰアドレスを受信する」との構成を備えるものであり、「リモートサーバ６０」は「ＩＰアドレス要求メッセージ」に応答して「割当可能なＩＰアドレス」を送信することで「ＩＰアドレス」の設定を行うものであるから、「リモートサーバ６０」が実施する一連の処理の方法と、本願発明６の「リソースコンフィギュレーション方法」とは、「通信資源のコンフィギュレーション方法」である点で共通する。

（２）一致点・相違点

以上から、本願発明６と引用発明とは、以下の点において一致ないし相違する。

［一致点］

「通信資源のコンフィギュレーション方法であって、

サーバサイドによって送信された通信資源の要求を通信装置が受信する段階であって、前記通信資源の要求は、前記通信資源の要求に示される通信資源についての情報を備える、段階と

前記通信資源の要求に示される前記通信資源についての前記情報にしたがって、前記サーバサイドに割り当てられる通信資源についての情報を前記通信装置が取得する段階と、

通信資源の応答を前記サーバサイドに前記通信装置が送信する段階であって、前記通信資源の応答は、前記サーバサイドに割り当てられる前記通信資源についての前記情報を備える、段階と

を備える方法。」

［相違点］

＜相違点４＞

本願発明６は、「通信資源」が「リソース」であり、それに伴い、「通信資源の要求」及び「通信資源の応答」が、それぞれ「リソース要求」及び「リソース応答」であるのに対し、引用発明では、「通信資源」は「ＩＰアドレス」であり、「通信資源の要求」及び「通信資源の応答」についても、それぞれ「リソース要求」及び「リソース応答」と特定されるものではない点。

＜相違点５＞

本願発明６は、通信資源の要求を受信して通信資源の応答を送信する動作の主体が「クライアント」であるのに対し、引用発明では、当該動作の主体が「ネットワークリモートサーバ」である点。

＜相違点６＞

本願発明６は、リソース要求の送信が「ＮＥＴＣＯＮＦ」又は「ＲＥＳＴＣＯＮＦ」に基づいて行われ、「前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含む、または、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含む、または、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用され、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している」のに対し、引用発明は、「カスタムＩＰアドレス要求メッセージ」を受けて、応答としての「割当可能なＩＰアドレス」を送信するものではあるが、「ＮＥＴＣＯＮＦ」又は「ＲＥＳＴＣＯＮＦ」を使用することは特定されておらず、「通信資源の要求」及び「通信資源の応答」のそれぞれが含む情報の内容についても具体的に特定されていない点。

（３）相違点についての判断

事案に鑑みて、上記相違点６について先に検討する。

引用文献１には、「カスタムＩＰアドレス要求メッセージ」の送信を「ＮＥＴＣＯＮＦ」又は「ＲＥＳＴＣＯＮＦ」に基づいて行うこと、及び「前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含む、または、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含む、または、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用され、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している」ことは記載も示唆もされておらず、これらの構成は本願の優先日前において周知技術であるともいえない。

そして、本願発明６は、これらの構成を備えることで、「サーバサイドのリソース要求にしたがってクライアントによってサーバサイドに割り当てられるリソースは、サーバサイドの実際の要件をより良く満たすことができ、それによって、リソースを浪費する可能性の低減を助ける」という有利な効果を奏するものである。

したがって、本願発明６は、他の相違点について検討するまでもなく、当業者であっても、引用発明に基づいて容易に発明できたものであるとはいえない。

４　本願発明７、１４－１５について

本願発明７、１４－１５も、上記相違点６に係る本願発明６の構成と同様の構成を備えるものであるから、本願発明６と同じ理由により、当業者であっても、引用発明に基づいて容易に発明できたものであるとはいえない。

第６　原査定について

令和２年３月１２日に提出された手続補正書による補正により、補正後の請求項１－５、８－１３は、上記相違点３に係る本願発明１の構成と同一又は同様の構成を有するものとなり、補正後の請求項６－７、１４－１５は、上記相違点６に係る本願発明６の構成と同一又は同様の構成を有するものとなった。

これらの構成は、原査定における引用文献１には記載されておらず、本願の優先日前における周知技術でもないので、本願発明１－１５は、当業者であっても、原査定における引用文献１に基づいて容易に発明できたものではない。

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

第７　むすび

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

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

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