JP7256638B2 - 通信方法、情報処理装置、およびプログラム - Google Patents

Description

本発明は、通信方法、情報処理装置、およびプログラムに関する。

近年、ネットワークデバイス（例えば、プリンターなど）は複数のプロトコルをサポートしている。そのようなネットワークデバイスとＰＣが通信する技術として特許文献１が開示されている。

特許文献１には、ＰＣとネットワークデバイスとの通信の際、情報取得用プロトコルとして利用するＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）のパケットを、ＴＣＰ（例えば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ））のパケットに包含して通信する技術が記載されている。

米国特許第９５３７８０８号明細書

特許文献１の技術では、デバイスがＳＮＭＰの応答パケットを生成できない状態の場合、デバイスはＳＮＭＰ応答パケットが含まれないＨＴＴＰ応答パケットをＰＣに送信する。一方、ＰＣは、ＳＮＭＰ応答パケットが含まれないＨＴＴＰ応答パケットを受信するため、デバイスがＳＮＭＰパケットを生成できない原因を特定できない。その結果、ユーザーの利便性が低下するおそれがあった。

上記課題を解決するために本発明は以下の構成を有する。すなわち、装置間の通信方法であって、第１の装置において、第１のプロトコルによる第１のパケットを含む第２のプロトコルによる第２のパケットを生成する生成工程と、前記第１の装置において、前記生成工程にて生成された第２のパケットを第２の装置に送信する送信工程と、前記第２の装置において、前記第２のパケットを受信する受信工程と、前記第２の装置において、前記第２のパケットに含まれる前記第１のパケットに対する前記第１のプロトコルによる応答が可能か否かを判定する判定工程と、前記第２の装置において、前記第１のパケットに対する前記第１のプロトコルによる応答が不可であると判定された場合、当該応答が不可である原因に対応するステータス情報を前記第２のパケットに対する応答パケットに含めて前記第１の装置に送信する応答工程とを有し、前記第２のプロトコルにて用いられる標準ステータスコードと、前記第１のプロトコルによる応答が不可である原因とが対応づけて定義されており、前記応答工程では、前記ステータス情報として当該標準ステータスコードを前記第２のパケットに対する前記応答パケットに含めて前記第１の装置に送信することを特徴とする。

本発明によれば、ユーザーの利便性を向上することが可能となる。

本発明に係るシステム構成の例を示す図。 本発明に係るＰＣのハードウェア構成の例を示す図。 本発明に係るデバイスのハードウェア構成の例を示す図。 本発明に係るＰＣのソフトウェア構成の例を示す図。 ＨＴＴＰパケット構成の例を示す図。 デバイスのＳＮＭＰ設定とヘッダ部のステータスの関係を示す図。 デバイスにおいてＳＮＭＰｖ１／ｖ３無効時の処理を示すシーケンス図。 デバイス通信中画面の例を示す図。 デバイス通信失敗画面の例を示す図。 デバイスのＳＮＭＰｖ１／ｖ３機能の有効／無効を設定するリモートＵＩの画面例を示す図。 デバイスにおいてＳＮＭＰｖ１無効時の処理を示すシーケンス図。 ＳＮＭＰｖ１リクエストパケットのコミュニティ名が不一致時の処理を示すシーケンス図。 ＰＣ側のコミュニティ名を変更する画面の例を示す図。 デバイスのＳＮＭＰｖ１のコミュニティ名を設定するリモートＵＩの画面の例を示す図。 デバイスにおいてＳＮＭＰｖ３無効時の処理を示すシーケンス図。 ＨＴＴＰパケット構成の例を示す図。 デバイスのＳＮＭＰ応答パケットを生成できない原因とステータスコードとの関係を示す図。 ＨＴＴＰアクセス制限により通信できない時の処理を示すシーケンス図。 デバイスのＨＴＴＰ設定を変更するリモートＵＩの画面例を示す図。 デバイスにおいてＳＮＭＰｖ１／ｖ３無効時の処理を示すシーケンス図。

以下、添付図面を参照して本発明の好適な実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものではない。また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

＜第１の実施形態＞
［システム構成］
図１は、情報処理装置であるＰＣ１０１を含むネットワークシステムの構成の一例を示すブロック図である。図１に示すシステムでは、ＰＣ１０１、デバイス１０２、およびルーター１０３が、ネットワーク１０４を介して接続されている。各装置は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）とＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の各プロトコルを利用して通信を行う。ネットワーク１０４は、ルーター１０３を介して外部ネットワーク１０５と接続されている。ネットワーク１０４は、有線／無線は問わない。デバイス１０２は、プリンタ、複写機、ファクシミリ、スキャナ等の周辺機器またはそれらの複合機能を備える装置である。ルーター１０３は、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ機能を有し、ＰＣ１０１、デバイス１０２にＩＰアドレスを割り当てる。なお、図１において、ＰＣ１０１やデバイス１０２はそれぞれ１台のみが示されているが、これに限定するものではなく、更に多くの装置がネットワーク１０４に設置されていてよく、これらの装置間で通信が行われてよい。

［ハードウェア構成］
図２は、本実施形態に係るＰＣ１０１のハードウェア構成の例を示す図である。ＰＣ１０１は、モニタ２０１、ＣＰＵ２０２、ＲＯＭ２０３、ＲＡＭ２０４、補助記憶装置２０５、キーボード２０６、ポインティングデバイス２０７、およびネットワークボード２０８を備える。各構成要素は、バス２０９を介して相互に通信可能に接続される。モニタ２０１は、アプリケーション４０１等のアプリケーションやドライバのＵＩを表示する。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０２は、ＰＣ１０１全体を制御する処理部である。ＣＰＵ２０２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０３や補助記憶装置２０５が記憶するアプリケーションやドライバ等のプログラムをＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０４にロードし、ロードしたプログラムを実行する。

ＲＯＭ２０３は、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）等の基本ソフトウェアや、ＰＣ１０１で実行する処理を実現するための各種プログラムを格納する。ＲＡＭ２０４は、アプリケーションやドライバなどのソフトウェアや、それらが利用するデータを一時的に記憶する。補助記憶装置２０５は、不揮発性の記憶部であり、例えば、ハードディスクである。補助記憶装置２０５は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、アプリケーション、ドライバ、種々のモジュールなどのソフトウェア（プログラム）を記憶する。補助記憶装置２０５が記憶するドライバには、デバイス１０２を制御するデバイスドライバが含まれる。このデバイスドライバは、デバイス１０２の機能に応じて、スキャナドライバ、プリンタドライバ、ファクシミリドライバ等が含まれる。また、補助記憶装置２０５が記憶するドライバには、モニタ２０１における表示を制御する表示制御ドライバ、キーボード２０６を制御するキーボードドライバ、ポインティングデバイス２０７を制御するポインティングデバイスドライバが含まれる。さらに、補助記憶装置２０５が記憶するドライバには、ネットワークボード２０８の通信を制御するネットワークドライバが含まれる。補助記憶装置２０５には、図４を用いて後述するアプリケーション４０１、ＳＮＭＰライブラリ４０２、ＨＴＴＰライブラリ４０３が含まれる。

アプリケーション４０１は、ＴＣＰ／ＩＰによるデバイスの検索機能と、ＴＣＰ／ＩＰによるデバイスへの情報設定機能とを有する。なお、アプリケーション４０１が、当該検索機能と当該情報設定機能を有するモジュールを呼び出して、それらの機能を実行させるようにしてもよい。また、当該検索機能と当該情報設定機能とが、それぞれ別のモジュールに設けられていてもよい。キーボード２０６およびポインティングデバイス２０７は、ユーザーからの指示を入力する入力装置である。ネットワークボード２０８は、ネットワーク１０４を介して、外部装置との通信を行う。

図３のデバイス１０２に示すハードウェア構成は、デバイス１０２がプリンタである場合のハードウェア構成の一例である。デバイス１０２は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、通信部３０４、記録部３０５、操作部３０６、および表示部３０７を備える。デバイス１０２を構成する各種構成要素は、バス３０８を介して相互に通信可能に接続される。ＣＰＵ３０１は、例えばマイクロプロセッサである。ＣＰＵ３０１は、デバイス１０２の中央処理装置として機能する。ＣＰＵ３０１は、ＲＯＭ３０２が記憶するプログラムをＲＡＭ３０３にロードし、ロードしたプログラムを実行することによって、通信部３０４、記録部３０５、操作部３０６、および表示部３０７を制御する。ＲＯＭ３０２は、デバイス１０２で実行する処理を実現するための各種プログラムを記憶する。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして用いられる。ＲＡＭ３０３は、各種データを一時的に記憶する。通信部３０４は、ネットワーク１０４を介して、他のデバイスとの通信を行う。記録部３０５は、例えば、画像データを紙などの記録媒体に印刷する。

操作部３０６は、ボタンやタッチパネル等の入力装置で構成される。表示部３０７は、デバイス１０２を操作するための画面や、デバイス１０２の各種情報を表示する。なお、デバイス１０２がプリンタ以外のデバイスである場合には、デバイス１０２は、記録部３０５に代えて、または記録部３０５に加えて、他の構成要素を備える。例えば、デバイス１０２がスキャナであれば、デバイス１０２は、他の構成として原稿上の画像を読み取る読取部を備える。したがって、デバイス１０２は、上記構成に限定するものではなく、提供する機能やサービスに応じて、対応する部位を備えてよい。

［ソフトウェア構成］
図４は、デバイス１０２と通信するＰＣ１０１におけるソフトウェアの構成例を示すブロック図である。ＰＣ１０１は、アプリケーション４０１、ＳＮＭＰライブラリ４０２、およびＨＴＴＰライブラリ４０３を備える。図４に示す各部は、ＰＣ１０１のＣＰＵ２０２が補助記憶装置２０５に記憶されているアプリケーション４０１を読み出して実行することで実現される。なお、アプリケーション４０１は、例えば、検索されたデバイスの状況を確認したり、検索されたデバイスへ印刷データを送信できる否かを確認したりするデバイス管理アプリケーションである。また、アプリケーション４０１は、ＰＣ１０１に、デバイス１０２のデバイスドライバをインストールするセットアップアプリケーションでもよい。

本実施形態では、アプリケーション４０１は、同一ネットワーク内にあるデバイスを検索し、検出したデバイスをモニタ２０１に表示する。一方、同一ネットワーク内にあるデバイスを検索できなかった場合、アプリケーション４０１は、デバイスの検出に失敗した旨をモニタ２０１に表示する。ＳＮＭＰライブラリ４０２は、アプリケーション４０１が使用するライブラリファイルであり、ＨＴＴＰパケットのボディ部に包含するＳＮＭＰリクエストパケットを生成する。ＳＮＭＰライブラリ４０２は、デバイス１０２から受信したＳＮＭＰレスポンスパケットを解析する。

ＨＴＴＰライブラリ４０３は、アプリケーション４０１が使用するライブラリファイルであり、ＳＮＭＰライブラリ４０２で生成したＳＮＭＰリクエストパケットをＨＴＴＰパケットのボディ部に組み込む。また、ＨＴＴＰライブラリ４０３は、デバイス１０２から受信したＨＴＴＰ応答パケットを解析する。このとき、ＨＴＴＰ応答パケットのボディ部にＳＮＭＰレスポンスパケットが含まれている場合、ＨＴＴＰライブラリ４０３は、ＳＮＭＰレスポンスパケットをＳＮＭＰライブラリ４０２に渡す。

［パケット構成］
図５は、デバイス１０２が生成する本実施形態に係るＳＮＭＰレスポンスパケットが含まれたＨＴＴＰ応答パケットの構成例を示す図である。ＨＴＴＰ応答パケット５００のボディ部５０２には、ＳＮＭＰレスポンスパケットが組み込まれる。ＨＴＴＰ応答パケット５００のヘッダ部５０１には、デバイス１０２がＳＮＭＰレスポンスパケットを生成できない場合、その原因を示すＨＴＴＰステータスコードが含まれる。なお、図６にて後述するようなテーブルをＰＣ１０１とデバイス１０２が備える。そのため、例えば、ＰＣ１０１は、デバイス１０２から受信したＨＴＴＰ応答パケット５００のヘッダ部に含まれるステータスコードからデバイスの状態を認識できる。本実施形態では、ステータスコードによりＳＮＭＰレスポンスパケットを生成できない原因が示されているが、他の情報でも構わない。例えば、テキストデータのステータス情報によりＳＮＭＰレスポンスパケットを生成できない原因が示されても構わない。ここで、ＳＮＭＰレスポンスパケットに含まれる情報の一例を説明する。例えば、アプリケーション４０１が、デバイス１０２のＩＰアドレスの取得を要求するＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含めてデバイスに送信する。なお、送信するタイミングは、例えば、後述する図７のＳ７０１または図１１のＳ１１０１などである。この場合、ＳＮＭＰレスポンスには、ＩＰアドレスが含まれる。また、アプリケーション４０１が、デバイス１０２のネットワーク情報として、デバイス１０２が接続しているルーターのＳＳＩＤ、通信モードを要求するＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含めてデバイスに送信する。この場合、ＳＮＭＰレスポンスには、デバイス１０２が接続しているルーターのＳＳＩＤおよび通信モードとして有線モードまたは無線モードの情報が含まれる。

図６は、本実施形態に係るＨＴＴＰ応答パケットのヘッダ部５０１に表現されるコードとデバイス１０２の状態の対応関係の例を示す。本実施形態では、ＳＮＭＰレスポンスパケットを生成できない各原因をＨＴＴＰの標準ステータスコードに紐付けて表現する。例えば、デバイス１０２から受信したＨＴＴＰ応答パケット５００のヘッダ部５０１にて“４０４（ＮｏｔＦｏｕｎｄ）”がステータスとして設定されていた場合、デバイス１０２の状態は、“ＳＮＭＰ通信非サポート”であることを示す。具体的な動作については、シーケンス図と合わせて後述する。

本実施形態においては、ＰＣ１０１およびデバイス１０２は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）およびＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）に対応可能に構成される。また、ＳＮＭＰにおいては、ＳＮＭＰｖ１（バージョン１）機能およびＳＮＭＰｖ３（バージョン３）機能の両方に対応可能なように構成される。また、デバイス１０２では、各機能に対して有効／無効の設定が可能である。

［シーケンス］
以下、本実施形態に係るデバイス１０２の状態に応じた処理のシーケンスについて、図面を用いて説明する。

（ＳＮＭＰｖ１／ｖ３が無効の場合）
図７は、デバイス１０２のＳＮＭＰｖ１／ｖ３機能が共に無効である場合に、アプリケーション４０１がデバイス１０２を検索する際のシーケンスを示す。ここでは、ＳＮＭＰｖ１の要求を行う場合を例に挙げて説明する。本シーケンスは、ＰＣ１０１およびデバイス１０２それぞれのＣＰＵが対応するプログラムを読み出して実行することにより実現される。

Ｓ７０１にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。そして、アプリケーション４０１は、生成したＨＴＴＰパケットをデバイス１０２に送信する。このとき、ＰＣ１０１のモニタ２０１には、現在、ＰＣ１０１がデバイス１０２と通信中であることを示す画面（図８）をアプリケーション４０１が表示する。図８は、デバイス１０２と通信中であることを示す画面８００の構成例を示す。画面８００に表示する情報は、図８に限定するものではなく、例えば、通信中のデバイスの情報を更に表示してもよい。

Ｓ７０２にて、デバイス１０２は、Ｓ７０１のＨＴＴＰパケットに対するＨＴＴＰ応答パケットをＰＣ１０１に送信する。ここでのＨＴＴＰ応答パケットのヘッダ部には、正常に通信可能であることを示す“２００ ＯＫ”がステータスとして設定される。

Ｓ７０３にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケットを解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケットのステータスに”２００ ＯＫ”が設定されていることを確認する。

Ｓ７０４にて、アプリケーション４０１は、ＳＮＭＰレスポンスパケットを取得するために、ＨＴＴＰパケットをデバイス１０２に送信する。

Ｓ７０５にて、デバイス１０２は、Ｓ７０４にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットを生成する。このとき、デバイス１０２は、デバイス１０２のＳＮＭＰｖ１／ｖ３機能が共に無効に設定されている。そのため、ＳＮＭＰレスポンスパケットの生成に失敗した旨を示すステータスコード“４０３ Ｆｏｒｂｉｄｄｅｎ”がＨＴＴＰ応答パケット５００のヘッダ部５０１に設定される。つまり、この場合は、ＳＮＭＰｖ１によるレスポンスは不可となり、ステータスコードが返される。

Ｓ７０６にて、デバイス１０２は、Ｓ７０５にて生成したＨＴＴＰ応答パケット５００をＰＣ１０１に送信する。

Ｓ７０７にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケット５００を解析する。アプリケーション４０１は、解析の結果、ＨＴＴＰ応答パケット５００のヘッダ部５０１にステータスコード“４０３ Ｆｏｒｂｉｄｄｅｎ”がステータスとして設定されていることを確認する。アプリケーション４０１は、ステータスコードと図６のテーブルに基づいて、デバイス１０２のＳＮＭＰｖ１およびｖ３が無効化されていることを認識する。アプリケーション４０１は、デバイス１０２のＳＮＭＰｖ１／ｖ３機能が共に無効化されているため、ＳＮＭＰレスポンスパケットを生成できない状態であるとみなす。このため、アプリケーション４０１は、再度通信を行っても失敗することが明らかなので、再試行せずに失敗と判定する。

Ｓ７０８にて、アプリケーション４０１は、デバイス１０２との通信を再試行せず、通信を中断する。そして、アプリケーション４０１は、デバイス１０２との通信に失敗した旨を示す画面（図９）を表示する。そして、本シーケンスを終了する。なお、上記では、ＳＮＭＰｖ１のパケットを用いた例を示したが、ＳＮＭＰｖ３においても同様のシーケンスとなる。

図９は、本実施形態において、アプリケーション４０１がデバイス１０２との通信に失敗した場合に、アプリケーション４０１がＰＣ１０１のモニタ２０１に表示するアプリケーション４０１の画面９００の一例である。画面９００には、リトライボタン９０１、およびヘルプボタン９０２を設ける。リトライボタン９０１は、ユーザーがデバイス１０２のＳＮＭＰ設定を変更した後に、ＰＣ１０１とデバイス１０２との通信を再度開始させ、パケットの再送を行うためのボタンである。ヘルプボタン９０２は、各種ヘルプ情報を案内するマニュアルページ（不図示）をＰＣ１０１のモニタ２０１に表示するためのボタンである。ここで図７の処理を経て表示された図９のヘルプボタン９０２が押下されたケースについて説明する。ヘルプボタン９０２が押下された場合、ヘルプ情報として、例えば、デバイス１０２のＳＮＭＰｖ１／ｖ３設定を変更するリモートＵＩ画面（図１０）へのアクセス方法、デバイス側のＳＮＭＰ機能を有効にする方法などが表示される。

図１０は、デバイス１０２のＳＮＭＰｖ１／ｖ３設定を変更するリモートＵＩ画面１０００の例を示す図である。リモートＵＩ画面１０００は、ＰＣ１０１のＷｅｂブラウザ（不図示）上に表示される。ＰＣ１０１のＷｅｂブラウザ（不図示）を介してデバイス１０２にアクセスすることで、デバイス１０２が提供するリモートＵＩ機能により、ユーザーは、デバイス１０２に対する各種設定を行うことが可能となる。なお、リモートＵＩ画面１０００にて設定可能な情報は図１０に示すものに限定するものではなく、他の情報を設定できてもよい。

（ＳＮＭＰｖ１無効、ＳＮＭＰｖ３有効の場合）
図１１は、デバイス１０２のＳＮＭＰｖ１機能のみが無効である場合に、アプリケーション４０１がデバイス１０２を検索する際のシーケンスを示す。つまり、このシーケンスにおいては、ＳＮＭＰｖ３機能は有効であるものとする。本シーケンスは、ＰＣ１０１およびデバイス１０２それぞれのＣＰＵが対応するプログラムを読み出して実行することにより実現される。

Ｓ１１０１にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。そして、アプリケーション４０１は、生成したＨＴＴＰパケットをデバイス１０２に送信する。このとき、ＰＣ１０１のモニタ２０１には、現在、ＰＣ１０１がデバイス１０２と通信中であることを示す画面８００をアプリケーション４０１が表示する。

Ｓ１１０２にて、デバイス１０２は、Ｓ１１０１にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットをＰＣ１０１に送信する。ここでのＨＴＴＰ応答パケットのヘッダ部には、正常に通信可能であることを示すステータスコード“２００ ＯＫ”がステータスとして設定される。

Ｓ１１０３にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケットを解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケットのステータスにステータスコード“２００ ＯＫ”が設定されていることを確認する。

Ｓ１１０４にて、アプリケーション４０１は、ＳＮＭＰレスポンスパケットを取得するために、ＨＴＴＰパケットをデバイス１０２に送信する。

Ｓ１１０５にて、デバイス１０２は、Ｓ１１０４にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットを生成する。このとき、デバイス１０２は、デバイス１０２のＳＮＭＰｖ１機能が無効であるためにＳＮＭＰレスポンスパケットの生成に失敗した旨を示すステータスコード“２０４ ＮｏＣｏｎｔｅｎｔ”をＨＴＴＰ応答パケット５００のヘッダ部５０１に設定する。つまり、このステータスコードは、図６に示すように、ＳＮＭＰｖ１／ｖ３のいずれか一方が無効であることを意味する。

Ｓ１１０６にて、デバイス１０２は、Ｓ１１０５にて生成したＨＴＴＰ応答パケット５００をＰＣ１０１に送信する。

Ｓ１１０７にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケット５００を解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケット５００のヘッダ部５０１にステータスコード”２０４ ＮｏＣｏｎｔｅｎｔ”がステータスとして設定されていることを確認する。このステータスコードが設定されていることにより、アプリケーション４０１は、送信したＳＮＭＰリクエストパケットに対応する機能（ここでは、ＳＮＭＰｖ１機能）がデバイス１０２にて無効であると判定する。そして、アプリケーション４０１は、デバイス１０２がＳＮＭＰｖ１のレスポンスパケットを生成できない状態であるとみなす。

Ｓ１１０８にて、アプリケーション４０１は、ＳＮＭＰｖ１のパケットを用いた通信を再度行っても失敗することが明らかであるため、この通信を再試行せず、代替手段としてＳＮＭＰｖ３でのリクエストを試みる。つまり、アプリケーション４０１は、ＳＮＭＰｖ３のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。そして、アプリケーション４０１は、生成したＨＴＴＰパケットをデバイス１０２に送信する。なお、代替手段への切り替えはアプリケーション４０１が自動的に行う。

Ｓ１１０９にて、デバイス１０２は、Ｓ１１０８にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットをＰＣ１０１に送信する。ここでのＨＴＴＰ応答パケットのヘッダ部には、正常に通信可能であることを示すステータスコード“２００ ＯＫ”がステータスとして設定される。

Ｓ１１１０にて、アプリケーション４０１は、デバイス１０２からのＨＴＴＰ応答パケットを解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケットのステータスにステータスコード“２００ ＯＫ”が設定されていることを確認する。

Ｓ１１１１にて、アプリケーション４０１は、ＳＮＭＰｖ３のレスポンスパケットを取得するために、ＨＴＴＰパケットをデバイス１０２に送信する。

Ｓ１１１２にて、デバイス１０２は、Ｓ１１０８にて受信したＳＮＭＰｖ３のリクエストパケットに対するレスポンスパケットが含まれるＨＴＴＰ応答パケット５００を生成する。ここでは、ＨＴＴＰ応答パケット５００のヘッダ部５０１には、ステータスコード“２００ ＯＫ”がステータスとして設定される。また、ＨＴＴＰ応答パケット５００のボディ部５０２には、ＳＮＭＰｖ３のレスポンスパケットが含められる。

Ｓ１１１３にて、デバイス１０２は、Ｓ１１１２で生成したＨＴＴＰ応答パケット５００をＰＣ１０１に送信する。

Ｓ１１１４にて、アプリケーション４０１は、Ｓ１１１３にて受信したＨＴＴＰ応答パケット５００を解析し、また、ＨＴＴＰ応答パケット５００のボディ部５０２に含まれるＳＮＭＰレスポンスパケットを解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケット５００のステータスにステータスコード“２００ ＯＫ”が設定されていることを確認し、正常に通信できたとみなす。そして、本シーケンスを終了する。

以上、図１１によれば、アプリケーション４０１が、Ｓ１１０６で受信したＨＴＴＰ応答パケット５００のヘッダ部５０１に含まれるステータスコードにより、異なるバージョンのＳＮＭＰパケットが有効であることを認識できる。その結果、アプリケーション４０１が、Ｓ１００８においてバージョンを変更して（図１１ではｖ１からｖ３へ変更して）リクエストを試みるため、デバイス１０２から必要な情報を容易に取得することができる。

（コミュニティ名が不一致の場合）
図１２は、ＰＣ１０１とデバイス１０２との間で、ＳＮＭＰｖ１リクエストパケットに設定されているコミュニティ名がデバイス１０２に設定されているコミュニティ名と不一致の時のシーケンスを示す。本シーケンスは、ＰＣ１０１およびデバイス１０２それぞれのＣＰＵが対応するプログラムを読み出して実行することにより実現される。

Ｓ１２０１にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。アプリケーション４０１は、生成したＨＴＴＰパケットをデバイス１０２に送信する。このとき、ＰＣ１０１のモニタ２０１には、現在、ＰＣ１０１がデバイス１０２と通信中であることを示す画面８００をアプリケーション４０１が表示する。

Ｓ１２０２にて、デバイス１０２は、Ｓ１２０１にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットをＰＣ１０１に送信する。ここでのＨＴＴＰ応答パケットのヘッダ部には、正常に通信可能であることを示す“２００ ＯＫ”がステータスとして設定される。

Ｓ１２０３にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケットを解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケットのステータスにステータスコード“２００ ＯＫ”が設定されていることを確認する。

Ｓ１２０４にて、アプリケーション４０１は、ＳＮＭＰレスポンスパケットを取得するためのＨＴＴＰパケットをデバイス１０２に送信する。

Ｓ１２０５にて、デバイス１０２は、Ｓ１２０４にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットを生成する。このとき、デバイス１０２は、デバイス１０２とＳＮＭＰｖ１リクエストパケットのコミュニティ名が一致しない旨を示すステータスコード“５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ”をＨＴＴＰ応答パケット５００のヘッダ部５０１に設定する。つまり、このステータスコードは、図６に示すように、コミュニティ名が不一致であることを意味する。

Ｓ１２０６にて、デバイス１０２は、Ｓ１２０５にて生成したＨＴＴＰ応答パケット５００をＰＣ１０１に送信する。

Ｓ１２０７にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケット５００を解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケット５００のヘッダ部５０１にステータスコード“５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ”がステータスとして設定されていることを確認する。このステータスコードが設定されていることにより、アプリケーション４０１は、コミュニティ名が一致しないためＳＮＭＰレスポンスパケットを生成できないと判定し、デバイス１０２がＳＮＭＰレスポンスパケットを生成できない状態であるとみなす。アプリケーション４０１は、コミュニティ名の不一致により、デバイス１０２に再度通信を行っても失敗することが明らかであるため、通信を再試行せずに失敗と判定する。

Ｓ１２０８にて、アプリケーション４０１は、デバイス１０２との通信を再試行せず、ＰＣ１０１側のコミュニティ名の変更を促す画面（図１３）に遷移する。そして、本シーケンスを終了する。

図１３は、本実施形態において、ＰＣ１０１とデバイス１０２との通信の際にコミュニティ名の不一致が発生した際に表示する画面１３００の一例である。画面１３００は、ＰＣ１０１のモニタ２０１に表示され、ＰＣ１０１側のコミュニティ名の変更が可能である。ラジオボタン１３０１は、デバイス１０２のベンダーがデフォルトで設定しているコミュニティ名を使用するか、ユーザーが任意のコミュニティ名を指定するかを選択するための設定項目である。テキストボックス１３０２は、ユーザーが設定したい任意のコミュニティ名を指定するための設定項目である。リトライボタン１３０３は、ラジオボタン１３０１とテキストボックス１３０２で指定したコミュニティ名でデバイス１０２との通信を再度開始させるためのボタンである。ヘルプボタン１３０４は、各種ヘルプ情報を案内するマニュアルページ（不図示）をＰＣ１０１のモニタ２０１に表示するためのボタンである。ここで図１２の処理を経て表示された図１３のヘルプボタン１３０４が押下されたケースについて説明する。ヘルプボタン１３０４が押下された場合、ヘルプ情報としては、例えば、デバイス１０２のコミュニティ名を変更するリモートＵＩ（図１４）へのアクセス方法、デバイス１０２側のコミュニティ名の設定方法などが表示される。

図１４は、デバイス１０２のＳＮＭＰｖ１コミュニティ名の設定を変更するリモートＵＩ画面１４００の例を示す図である。リモートＵＩ画面１４００は、ＰＣ１０１のＷｅｂブラウザ（不図示）上に表示される。なお、リモートＵＩ画面１４００にて設定可能な情報は図１４に示すものに限定するものではなく、他の情報を設定できてもよい。

（ＳＮＭＰｖ１有効、ＳＮＭＰｖ３無効の場合）
図１５は、デバイス１０２のＳＮＭＰｖ３機能が無効である場合に、アプリケーション４０１がデバイス１０２を検索する際のシーケンスを示す。つまり、このシーケンスにおいては、ＳＮＭＰｖ１機能は有効であるものとする。本シーケンスは、ＰＣ１０１およびデバイス１０２それぞれのＣＰＵが対応するプログラムを読み出して実行することにより実現される。

Ｓ１５０１にて、アプリケーション４０１は、ＳＮＭＰｖ３のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。なお、Ｓ１５０２～Ｓ１５０６は、ＳＮＭＰのバージョンが異なる点を除いて基本的にＳ１１０２～Ｓ１１０６と同じ処理であるため詳細な説明は省略する。なお、アプリケーション４０１は、リクエストの目的により、Ｓ７０１を行うのか、Ｓ１５０１を行うのかを決定する。例えば、アプリケーション４０１がデバイス１０２のＩＰアドレスを取得する場合、暗号化する必要はないため、Ｓ７０１を実行する。つまり、アプリケーション４０１は、図７のようにＳＮＭＰｖ１のリクエストパケットを含むＨＴＴＰパケットをデバイス１０２に送信する。一方、アプリケーション４０１は、デバイス１０２が接続しているルーターのパスワードを取得する場合、暗号化する必要があるため、Ｓ１５０１を実行する。

Ｓ１５０７にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケット５００を解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケット５００のヘッダ部５０１にステータスコード“２０４ ＮｏＣｏｎｔｅｎｔ”がステータスとして設定されていることを確認する。このステータスコードが設定されていることにより、アプリケーション４０１は、送信したＳＮＭＰリクエストパケットに対応する機能（ここではＳＮＭＰｖ３機能）がデバイス１０２にて無効であると判定する。そして、アプリケーション４０１は、デバイス１０２がＳＮＭＰｖ３のレスポンスパケットを生成できない状態であるとみなす。アプリケーション４０１は、再度通信を行っても失敗することが明らかであるため、ＳＮＭＰｖ３機能を用いた通信を再試行しない。

Ｓ１５０８にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットをボディ部に含めたＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）パケットを代替として、デバイス１０２に送信する。これは、ＳＮＭＰｖ３のパケットはセキュア情報を含める場合があるため、セキュリティを考慮してＨＴＴＰＳによる暗号化された通信を用いる。なお、ＳＮＭＰｖ３のパケットは暗号化して送信可能である。一方、ＳＮＭＰｖ１のパケットは暗号化して送信することはできない。以降の処理であるＳ１５０９～Ｓ１５１４も、ＳＮＭＰのバージョンが異なる点を除いて基本的にＳ１１０９～Ｓ１１１４と同じ処理であるため詳細な説明は省略する。

以上、図１５によれば、アプリケーション４０１が、Ｓ１５０６で受信したＨＴＴＰ応答パケット５００のヘッダ部５０１に含まれるステータスコードにより、異なるバージョンのＳＮＭＰパケットが有効であることを認識できる。その結果、アプリケーション４０１が、Ｓ１００８においてバージョンを変更して（図１１ではｖ３からｖ１へ変更して）リクエストを試みるため、デバイス１０２から必要な情報を容易に取得することができる。この際、Ｓ１５０８にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットをボディ部に含めたＨＴＴＰＳパケットを使用するため、セキュリティの低下を軽減できる。

ここで他の処理についても説明する。例えば、アプリケーション４０１が、遠隔からデバイス１０２の設定変更を行うことも可能である。アプリケーション４０１は、例えば、設定変更情報を含むＳＮＭＰｖ３のリクエストパケットがボディ部に含まれたＨＴＴＰパケットをデバイス１０２に送信する。このＨＴＴＰパケットを受信したデバイス１０２は、設定変更処理を行うと共に、ＨＴＴＰ応答パケットを送信する。ここでのＨＴＴＰ応答パケット５００のヘッダ部５０１には、正常に通信可能であることを示すステータスコード“２００ ＯＫ”がステータスとして設定される。続いてアプリケーション４０１は、ＳＮＭＰｖ３のレスポンスパケットを取得するために、ＨＴＴＰパケットをデバイス１０２に送信する。ここで、デバイス１０２が設定変更中である場合、デバイス１０２は設定変更中であることを示すステータスコードをＨＴＴＰ応答パケット５００のヘッダ部５０１に設定して、ＨＴＴＰ応答パケット５００を送信する。アプリケーション４０１は、ＨＴＴＰ応答パケット５００を解析することでデバイス１０２が設定変更中であると認識できる。この場合、アプリケーション４０１は、再度、ＳＮＭＰｖ３のレスポンスパケットを取得するために、ＨＴＴＰパケットをデバイス１０２に送信する。つまり、アプリケーション４０１は、ＳＮＭＰレスポンスがＨＴＴＰ応答パケット５００に含まれない場合であってもリトライが必要な場合、アプリケーション４０１は適切にリトライ処理を実行することができる。

本実施形態により、アプリケーション４０１はデバイス１０２がＳＮＭＰ応答パケットを生成できない原因を判明できる。これにより、不要なリトライ処理とリトライ処理が成功するまでユーザーを待機させる必要がなく、アプリケーション４０１は通信ができない旨をユーザーに通知して処理を終了することができる。その際、本実施形態では、図６のように、ＳＮＭＰ応答パケットを生成できない原因毎にＨＴＴＰの標準ステータスコードに紐付けて定義する。これにより、ステータスコードをアプリケーション４０１は、ステータスコードに合わせた代替処理（図１１、図１５）や、ユーザーへのＰＣ１０１またはデバイス１０２の設定変更へ案内（図９、図１３）することができる。また、アプリケーション４０１は、ステータスコードに基づいてリトライ処理を実行するか否かを切り替えることが可能となる。

また、図６のようにデバイスがＳＮＭＰ応答パケットを生成できない原因をＨＴＴＰの標準ステータスコードで表現することは、ＳＮＭＰ応答パケットを包含するプロトコルに拡張ヘッダ機能を持たない場合でも対応できるメリットがある。なお、拡張ヘッダ機能を持たない場合の一例は、例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などが使用される場合である。

なお、本実施形態では、ＳＮＭＰを生成できない原因を示すエラーが設定されたＨＴＴＰ応答パケットを、アプリケーションからの２回目のＨＴＴＰ応答パケットで返す例を示したが、これに限定するものではない。例えば、図７のＳ７０２のように、ＰＣが送信する最初のＨＴＴＰ送信パケットに対するＨＴＴＰ応答パケットで、ＳＮＭＰを生成できない原因を示すエラーを返してもよい。

＜第２の実施形態＞
第１の実施形態では、デバイスがＳＮＭＰ応答パケットを生成できない原因をＨＴＴＰの標準ステータスコードに対応付けて表現していた。第１の実施形態のように標準ステータスコードでエラータイプを通知した場合、アプリケーションが適切にエラーを判定できないケースもある。

例えば、デバイスにＨＴＴＰの機能で、デバイスにアクセスできるＰＣを制限する機能があるとする。そして、既にアクセス制限されたＰＣが、ＳＮＭＰリクエストパケットが含まれたＨＴＴＰパケットをデバイスに送信したとする。この場合、ＰＣはデバイスからのＨＴＴＰ応答パケットのヘッダにステータスコード“４０３ Ｆｏｒｂｉｄｄｅｎ”が含まれたＨＴＴＰ応答パケットを受信する。しかし、ＰＣ側は、デバイスにＨＴＴＰ通信によるアクセス制限が設定されているため通信できないことを示す通信エラーなのか、ＳＮＭＰｖ１／ｖ３が共に無効を示しているのか判定できない。また、このような例に限らず、ＨＴＴＰとＳＮＭＰとのステータスコードを１つのヘッダで表現すると、どちらのプロトコルのエラーなのかをＰＣ上では判定が困難となる。

本発明の第２の実施形態では、ＨＴＴＰによるエラーなのか、または、ＳＮＭＰによるエラーなのかを判定できる形態について図を用いて説明する。なお、第１の実施形態と重複する構成については説明を省略する。

［パケット構成］
図１６は、本実施形態に係る、デバイス１０２が生成するＳＮＭＰレスポンスパケットが含まれたＨＴＴＰ応答パケットの構成例を示す図である。ＨＴＴＰ応答パケット１６００のボディ部１６０４にはＳＮＭＰレスポンスパケットを組み込む。ＨＴＴＰ応答パケットのヘッダ部１６０１は、ステータス部１６０２と拡張部１６０３が設けられる。ステータス部１６０２では、ＨＴＴＰ層で発生したエラーを表現する。拡張部１６０３では、ＳＮＭＰレスポンスパケットを生成できない原因を示すステータスコードをＨＴＴＰのカスタムヘッダ機能を用いて表現する。なお、図１７にて後述するようなテーブルをＰＣ１０１とデバイス１０２が備える。そのため、例えば、ＰＣ１０１は、デバイス１０２から受信したＨＴＴＰ応答パケット５００の拡張部１６０３に含まれるステータスコードからデバイスの状態を認識できる。

図１７は、本実施形態に係るＨＴＴＰ応答パケット１６００の拡張部１６０３で表現するステータスコードの対応表の一例である。本実施形態においては、ＳＮＭＰレスポンスパケットを生成できない各原因をＨＴＴＰの標準ステータスコードと切り分けられるよう、ＨＴＴＰのカスタムヘッダ機能を用いて独自のステータスコードで表現する。なお、ステータス部１６０２には、ＨＴＴＰの標準ステータスコードが設定されるものとする。

［シーケンス］
（アクセス制限がされている場合）
図１８は、本実施形態に係るＨＴＴＰアクセス制限によってＰＣ１０１がデバイス１０２と通信できない時のシーケンスを示す。本シーケンスは、ＰＣ１０１およびデバイス１０２それぞれのＣＰＵが対応するプログラムを読み出して実行することにより実現される。

Ｓ１８０１にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。そして、アプリケーション４０１は、生成したＨＴＴＰパケットをデバイス１０２に送信する。このとき、ＰＣ１０１のモニタ２０１には、現在、ＰＣ１０１がデバイス１０２と通信中であることを示す画面８００をアプリケーション４０１が表示する。

Ｓ１８０２にて、デバイス１０２は、Ｓ１８０１にて受信したＨＴＴＰパケットに対するＨＴＴＰ応答パケットを生成する。このとき、デバイス１０２は、ＨＴＴＰアクセスが拒否された旨を示すステータスコード“４０３ Ｆｏｒｂｉｄｄｅｎ”をＨＴＴＰ応答パケット１６００のヘッダ部１６０１のステータス部１６０２に設定する。

Ｓ１８０３にて、デバイス１０２は、Ｓ１８０２にて生成したＨＴＴＰ応答パケット１６００をＰＣ１０１に送信する。

Ｓ１８０４にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケット１６００を解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケット１６００のヘッダ部１６０１のステータス部１６０２にステータスコード“４０３ Ｆｏｒｂｉｄｄｅｎ”が設定されていることを確認する。アプリケーション４０１は、ＨＴＴＰ応答パケット１６００のヘッダ部１６０１のステータス部１６０２にステータスコード“４０３ Ｆｏｒｂｉｄｄｅｎ”が設定されていることにより、デバイス１０２側でＨＴＴＰアクセス制限がかけられていることを判定する。アプリケーション４０１は、ＨＴＴＰ通信を再度行っても失敗することが明らかであるため、通信を再試行せず失敗と判定する。

Ｓ１８０５にて、アプリケーション４０１は、デバイス１０２との通信に失敗した旨を示す画面９００を表示する。そして、本シーケンスを終了する。なお、上記では、ＳＮＭＰｖ１のパケットを用いた例を示したが、ＳＮＭＰｖ３においても同様のシーケンスとなる。

図１９は、デバイス１０２のＨＴＴＰ設定を変更するリモートＵＩの構成例を示す図である。図１８のＳ１８０５のときに、画面９００がＰＣ１０１のモニタ２０１に表示されたとする。このとき、ユーザーが画面９００のヘルプボタン９０２を押下すると、デバイス１０２のＨＴＴＰアクセス制限の確認方法が記載されたマニュアル（不図示）が表示される。ユーザーは、マニュアル（不図示）の案内に従って、図１９のリモートＵＩ画面１９００を表示させ、設定内容の確認や設定変更を行うことが可能である。リモートＵＩ画面１９００は、ＰＣ１０１のＷｅｂブラウザ（不図示）上に表示される。なお、リモートＵＩ画面１９００にて設定可能な情報は図１９に示すものに限定するものではなく、他の情報を設定できてもよい。ユーザーは、図１９のリモートＵＩ画面を使って、ＰＣ１０１に対応する識別情報を選択して削除ボタンを押下することにより、デバイス１０２に設定されているＰＣ１０１のアクセス制限を解除できる。

（ＳＮＭＰｖ１／ｖ３が無効の場合）
図２０は、デバイス１０２のＳＮＭＰｖ１／ｖ３機能が共に無効である場合に、ＰＣ１０１がデバイス１０２を検索する際のシーケンスを示す。ここでは、ＳＮＭＰｖ１の要求を行う場合を例に挙げて説明する。本シーケンスは、ＰＣ１０１およびデバイス１０２それぞれのＣＰＵが対応するプログラムを読み出して実行することにより実現される。

Ｓ２００１にて、アプリケーション４０１は、ＳＮＭＰｖ１のリクエストパケットを生成し、ＨＴＴＰパケットのボディ部に含める。そして、アプリケーション４０１は、生成したＨＴＴＰパケットをデバイス１０２に送信する。このとき、ＰＣ１０１のモニタ２０１には、現在、ＰＣ１０１がデバイス１０２と通信中であることを示す画面８００をアプリケーション４０１が表示する。

Ｓ２００２にて、デバイス１０２は、Ｓ２００１のＨＴＴＰパケットに対するＨＴＴＰ応答パケットをＰＣ１０１に送信する。ここでのＨＴＴＰ応答パケットのヘッダ部には、正常に通信可能であることを示す“２００ ＯＫ”がステータスとして設定される。

Ｓ２００３にて、アプリケーション４０１は、デバイス１０２からのＨＴＴＰ応答パケットを解析する。解析の結果、アプリケーション４０１は、ＨＴＴＰ応答パケットのステータスに“２００ ＯＫ”が設定されていることを確認する。

Ｓ２００４にて、アプリケーション４０１は、ＳＮＭＰレスポンスパケットを取得するために、ＨＴＴＰパケットをデバイス１０２に送信する。

Ｓ２００５にて、デバイス１０２は、Ｓ２００４にて受信したパケットに対するＨＴＴＰ応答パケットを生成する。このとき、デバイス１０２は、デバイス１０２のＳＮＭＰｖ１／ｖ３機能が共に無効に設定されている。そのため、ＳＮＭＰ応答パケットの生成に失敗した旨を示すステータスコード“５５１ ＳＮＭＰ Ｉｎｖａｌｉｄ“がＨＴＴＰ応答パケット１６００のヘッダ部１６０１の拡張部１６０３に設定される。

Ｓ２００６にて、デバイス１０２は、Ｓ２００５にて生成したＨＴＴＰ応答パケット１６００をＰＣ１０１に送信する。

Ｓ２００７にて、アプリケーション４０１は、デバイス１０２から受信したＨＴＴＰ応答パケット１６００を解析する。アプリケーション４０１は、解析の結果、ＨＴＴＰ応答パケット１６００のヘッダ部１６０１の拡張部１６０３にステータスコード“５５１ ＳＮＭＰ Ｉｎｖａｌｉｄ”がステータスとして設定されていることを確認する。これにより、アプリケーション４０１は、デバイス１０２のＳＮＭＰｖ１／ｖ３機能が共に無効のためＳＮＭＰレスポンスパケットを生成できない状態であるとみなす。このため、アプリケーション４０１は再度通信を行っても失敗することが明らかなので、通信を再試行せず失敗と判定する。

Ｓ２００８にて、アプリケーション４０１は、デバイス１０２との通信を再試行せず、デバイスとの通信に失敗した旨を示す画面９００を表示する。そして、本シーケンスを終了する。なお、上記では、ＳＮＭＰｖ１のパケットを用いた例を示したが、ＳＮＭＰｖ３においても同様のシーケンスとなる。

以上、本実施形態では、ＨＴＴＰで発生したエラーをＨＴＴＰ標準ステータスコード、ＳＮＭＰで発生したエラーをＨＴＴＰのカスタムヘッダ機能を用いて独自ステータスコードで表現する。これにより、第１の実施形態の効果に加え、ＨＴＴＰとＳＮＭＰのどちらで発生したエラーかを適切に通知することができる。

＜その他の実施形態＞
上記の実施形態では、デバイスの情報管理用プロトコルにＳＮＭＰのパケットを包含し、通信するプトロコルにＨＴＴＰを用いた例を示したが、これに限定するものではない。例えば、ＴＣＰのみサポートしているＩＭＡＰ（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）パケットをＳＮＭＰのようなＵＤＰ（User Datagram Protocol）をサポートするプロトコルで包含する。これにより、ＴＣＰによる通信ができない環境でも、ＵＤＰを用いてデバイスと通信できる効果がある。このように、デバイスとの情報の送受信と、ＰＣとデバイスとの通信が可能であれば他の標準プロトコル、または、デバイスベンダー独自で定義したプロトコルに適用してもよい。

また、上記の実施形態では、ＰＣとデバイス間をネットワークインターフェース経由で通信する例を示したが、これに限定するものではない。例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インターフェースを経由（以下、ＵＳＢ経由）してＳＮＭＰやＨＴＴＰパケットを用いての通信が可能であれば、ＵＳＢ経由でもよい。特にＵＳＢ経由の場合、以下のような効果が期待できる。例えば、ＵＳＢドライバを未インストールのＰＣ上で動作するアプリケーション４０１が、ＵＳＢ経由でデバイスと通信する。このとき、デバイスをＵＳＢケーブルで接続した瞬間、ＰＣ側ではＵＳＢドライバのインストールが開始する場合がある。ＰＣは、ＵＳＢ経由でデバイスと通信するために、ＵＳＢドライバのインストールが完了するまでＵＳＢ通信を待機しなくてはならない。この場合、ＵＳＢドライバのインストールが完了するまではデバイス検索処理の結果として０台がＨＴＴＰライブラリ４０３からアプリケーション４０１に通知される。この場合、アプリケーション４０１は、デバイス検索処理のリトライを実行する。このように、ＵＳＢ経由の場合、デバイスと通信するためにＰＣ側で必要な処理待ちがある。一方、ＵＳＢドライバがインストール済みのＰＣ上で動作するアプリケーションが、ＳＮＭＰパケットを生成できない状態のデバイスと通信する場合、アプリケーション４０１は、デバイスがＳＮＭＰパケットを生成できない理由を認識できる。その結果、アプリケーション４０１は、リトライ処理をするか否かを決めることができ、リトライ処理が不要な場合、次の処理へと進むことができる。以上により、ＰＣ側での不要な処理待ちを回避できる。つまり、本発明により、ＰＣ側は必要な処理待ちと不要な処理待ちを判別できる効果が期待される。

また、上記の実施形態では、デバイスのＳＮＭＰ機能無効やコミュニティ名の不一致など、ＳＮＭＰ標準エラーでは表現できない状態をＨＴＴＰヘッダで表現する例を示したが、これに限定するものではない。例えば、ＳＮＭＰ標準エラー（ｔｏｏＢｉｇ、ｎｏＳｕｃｈＮａｍｅなど）もＳＮＭＰパケットを組み込む上位プロトコルのヘッダ情報などで表現してもよい。これにより、ＨＴＴＰのボディ部にＳＮＭＰの応答パケットを組み込む必要がなくなるため、パケットサイズ・通信量の削減が期待できる。

また、デバイス１０２は、上述した装置の他に、例えば、デジタルカメラやスピーカなどＰＣと通信可能な装置であってもよい。

本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１…ＰＣ、１０２…デバイス、１０４…ネットワーク、４０１…アプリケーション、４０２…ＳＮＭＰライブラリ、４０３…ＨＴＴＰライブラリ

Claims (13)

1. 装置間の通信方法であって、
   第１の装置において、第１のプロトコルによる第１のパケットを含む第２のプロトコルによる第２のパケットを生成する生成工程と、
   前記第１の装置において、前記生成工程にて生成された第２のパケットを第２の装置に送信する送信工程と、
   前記第２の装置において、前記第２のパケットを受信する受信工程と、
   前記第２の装置において、前記第２のパケットに含まれる前記第１のパケットに対する前記第１のプロトコルによる応答が可能か否かを判定する判定工程と、
   前記第２の装置において、前記第１のパケットに対する前記第１のプロトコルによる応答が不可であると判定された場合、当該応答が不可である原因に対応するステータス情報を前記第２のパケットに対する応答パケットに含めて前記第１の装置に送信する応答工程と
   を有し、
   前記第２のプロトコルにて用いられる標準ステータスコードと、前記第１のプロトコルによる応答が不可である原因とが対応づけて定義されており、
   前記応答工程では、前記ステータス情報として当該標準ステータスコードを前記第２のパケットに対する前記応答パケットに含めて前記第１の装置に送信する、
   ことを特徴とする通信方法。
2. 前記第１の装置において、前記応答パケットに含まれるステータス情報に応じて、当該ステータス情報に対応付けて定義された処理を実行する実行工程を更に有することを特徴とする請求項１に記載の通信方法。
3. 前記処理は、前記第２の装置への前記第２のパケットの再送を行うか否かをユーザーに確認する処理であることを特徴とする請求項２に記載の通信方法。
4. 前記処理は、前記第２の装置への前記第２のパケットの送信を再試行せず、通信を中断する処理であることを特徴とする請求項２または３に記載の通信方法。
5. 前記処理は、前記第１の装置または前記第２の装置における前記第１のプロトコルに関する設定変更をユーザーに案内する処理であることを特徴とする請求項２乃至４のいずれか１項に記載の通信方法。
6. 前記応答パケットに含まれる前記ステータス情報が前記第１のパケットに対応する前記第１のプロトコルのバージョンが無効化されていることを示すステータス情報である場合、前記処理は、前記第１のプロトコルの異なるバージョンによる第３のパケットを含む前記第２のプロトコルによるパケットを再送する処理であることを特徴とする請求項２乃至５のいずれか１項に記載の通信方法。
7. 前記応答パケットに含まれる前記ステータス情報が前記第１のパケットに対応する前記第１のプロトコルの第１バージョンが無効化されていることを示すステータス情報である場合、前記処理は、前記第２のプロトコルによる暗号化の機能を用いて、前記第１のプロトコルの異なる第２バージョンによる第３のパケットを含むパケットを再送する処理であり、
   前記第１のプロトコルの前記第１バージョンは前記第１のパケットを暗号化して送信可能であり、
   前記第１のプロトコルの前記第２バージョンは前記第１のパケットを暗号化せずに送信することを特徴とする請求項２乃至６のいずれか１項に記載の通信方法。
8. 前記応答パケットは、ヘッダ部とボディ部とから構成され、
   前記標準ステータスコードは、前記ヘッダ部に含められ、
   前記第１のプロトコルによるパケットは、前記ボディ部に含められることを特徴とする請求項１乃至７のいずれか一項に記載の通信方法。
9. 前記第１のプロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であり、
   前記第２のプロトコルは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）であることを特徴とする請求項１乃至８のいずれか一項に記載の通信方法。
10. 第１のプロトコルおよび第２のプロトコルを用いて外部装置と通信可能な情報処理装置であって、
    前記第１のプロトコルによる第１のパケットを含む第２のプロトコルによる第２のパケットを生成する生成手段と、
    前記生成手段にて生成された第２のパケットを前記外部装置に送信する送信手段と、
    前記第１のパケットに対する応答が不可である原因に対応するステータス情報を含む、前記第２のパケットに対する応答パケットを前記外部装置から受信する受信手段と
    前記応答パケットに含まれるステータス情報に応じて、当該ステータス情報に対応付けて定義された処理を実行する実行手段と
    を有し、
    前記第２のプロトコルにて用いられる標準ステータスコードと、前記第１のプロトコルによる応答が不可である原因とが対応づけて定義されており、
    前記ステータス情報としての当該標準ステータスコードが前記第２のパケットに対する前記応答パケットに含まれる、
    ことを特徴とする情報処理装置。
11. 第１のプロトコルおよび第２のプロトコルを用いて外部装置と通信可能な情報処理装置であって、
    前記第１のプロトコルによる第１のパケットを含む前記第２のプロトコルによる第２のパケットを前記外部装置から受信する受信手段と、
    前記第２のパケットに含まれる前記第１のパケットに対する前記第１のプロトコルによる応答が可能か否かを判定する判定手段と、
    前記第１のパケットに対する前記第１のプロトコルによる応答が不可であると判定された場合、当該応答が不可である原因に対応するステータス情報を前記第２のパケットに対する応答パケットに含めて前記外部装置に送信する応答手段と
    を有し、
    前記第２のプロトコルにて用いられる標準ステータスコードと、前記第１のプロトコルによる応答が不可である原因とが対応づけて定義されており、
    前記応答手段は、前記ステータス情報として当該標準ステータスコードを前記第２のパケットに対する前記応答パケットに含めて前記外部装置に送信する、
    ことを特徴とする情報処理装置。
12. コンピュータを、
    第１のプロトコルによる第１のパケットを含む第２のプロトコルによる第２のパケットを生成する生成手段、
    前記生成手段にて生成された第２のパケットを外部装置に送信する送信手段、
    前記第１のパケットに対する応答が不可である原因に対応するステータス情報を含む、前記第２のパケットに対する応答パケットを前記外部装置から受信する受信手段
    前記応答パケットに含まれるステータス情報に応じて、当該ステータス情報に対応付けて定義された処理を実行する実行手段
    として機能させ、
    前記第２のプロトコルにて用いられる標準ステータスコードと、前記第１のプロトコルによる応答が不可である原因とが対応づけて定義されており、
    前記ステータス情報としての当該標準ステータスコードが前記第２のパケットに対する前記応答パケットに含まれる、
    ことを特徴とするプログラム。
13. コンピュータを、
    第１のプロトコルによる第１のパケットを含む第２のプロトコルによる第２のパケットを外部装置から受信する受信手段、
    前記第２のパケットに含まれる前記第１のパケットに対する前記第１のプロトコルによる応答が可能か否かを判定する判定手段、
    前記第１のパケットに対する前記第１のプロトコルによる応答が不可であると判定された場合、当該応答が不可である原因に対応するステータス情報を前記第２のパケットに対する応答パケットに含めて前記外部装置に送信する応答手段
    として機能させ、
    前記第２のプロトコルにて用いられる標準ステータスコードと、前記第１のプロトコルによる応答が不可である原因とが対応づけて定義されており、
    前記応答手段は、前記ステータス情報として当該標準ステータスコードを前記第２のパケットに対する前記応答パケットに含めて前記外部装置に送信する、
    ことを特徴とするプログラム。

Images