本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
まず、本発明の一実施形態に係る機器システムについて説明する。
図1は、本発明の一実施形態に係る機器システムの機能構成図である。
機器システム1は、外部機器の一例としての複数の端末2(2A、2B)と、電子機器の一例としてのプリンタ3とを有する。端末2Aとプリンタ3とは、例えば、USB(Universal serial bus)ケーブル等のローカルケーブル4を介して接続(ローカル接続)されている。また、端末2Bとプリンタ3とは、例えば、イーサネット(登録商標)等のネットワーク5を介して接続(ネットワーク接続)されている。また、プリンタ3は、外部機器の他の例としてのUSBメモリ6(外部記憶媒体)が直接接続(ローカル接続)可能となっている。
端末2は、状態情報取得処理部21と、要求送信手段及び状態情報受信手段の一例としてのJL(Job Language)処理部22及びローカルI/F(インターフェース)23と、SNMP(Simple Network Management Protocol)処理部24と、ソケット処理部25と、ネットワークI/F(インターフェース)26とを有する。端末2は、例えば、図示しないCPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)、HDD(Hard Disk Drive)等のハードウエアを有するPC(Personal Computer)によって構成されている。状態情報取得処理部21、JL処理部22、SNMP処理部24、ソケット処理部25は、主に、CPUがプログラムを実行することによって実現される。
プリンタ3は、ローカル受信手段及びローカル送信手段の一例としてのローカルI/F部31、ローカルI/F32、及びJL処理部33と、JLデータ記憶部35と、JLデータ記憶部35に対するアクセス処理を実行・管理するJLデータ管理部34と、メッセージ生成手段及び応答データ生成手段の一例としてのプロトコルコンバータ36と、ネットワーク受信手段及びネットワーク送信手段の一例としてのネットワークI/F37、ソケット処理部38及びSNMP処理部39と、MIB管理手段の一例としてのMIB(Management Information Base)エージェント40と、MIB41とを有する。プリンタ3は、図示しないCPU、ROM、RAM、EEPROM(Electrically Erasable Programmable Read-Only Memory)、プリンタエンジン等のハードウエアによって構成されている。JL処理部33、JLデータ管理部34、プロトコルコンバータ36、ソケット処理部38、SNMP処理部39、MIBエージェント40は、主に、CPUが所定のプログラムを実行することによって実現される。JL記憶部35及びMIB41は、HDDによって実現される。
ここで、端末2及びプリンタ3の各部を説明する前に、MIB41について説明する。
図2は、本発明の一実施形態に係るMIBの構成の一例を示す図である。
MIB41おいては、プリンタ3の複数の状態情報のそれぞれは、オブジェクトという単位によって管理されている。具体的には、MIB41では、状態情報を管理するオブジェクトに割り当てられている識別情報(OID:Object Identification)411と、当該オブジェクトの名称(オブジェクト名)412と、当該オブジェクトにより管理されている値(状態情報)413とが対応付けられて管理されている。
オブジェクトは、ツリー構造によって管理されており、当該オブジェクトのOID411は、例えば、“1.3.6.1.2.1.43.12.1.1.4.1.1”のように、ツリー構造の最上位階層から該当するオブジェクトに至るまでの各階層の枝の番号(枝番)をピリオドで区切って繋げた形式によって表される。
このMIB41によると、所望する状態情報のオブジェクトのOIDによって、対応する状態情報(値)を把握することができる。
図1の説明に戻り、端末2の各部を詳細に説明する。
状態情報取得処理部21は、所定のタイミングで、状態情報を取得(要求)する対象がネットワーク5を介して接続されたプリンタ3であれば、プリンタ3のMIB35から取得すべき状態情報に対応するOIDを含めたSNMPメッセージ(図5参照:第3のSNMPメッセージ)をHDDから取得してSNMP処理部24に渡す一方、対象がローカルケーブル4によって接続されたプリンタ3であれば、プリンタ3のMIB41から取得すべき状態情報に対応するOIDを示すOID特定情報を含むJLコマンド列(第1のローカル通信用データ)をHDDから取得してJL処理部22に渡す。
JL処理部22は、状態情報取得処理部21から取得したJLコマンド列をローカルI/F23及びローカルケーブル4を介して送信させるとともに、ローカルケーブル4及びローカルI/F23を介してJLコマンド列(第2のローカル通信用データ)を受信し、受信したJLコマンド列を状態情報取得処理部21に渡す。
ここで、ローカルI/F23によるローカルケーブル4を介してのローカル通信では、ASCII(アスキー:American Standard Code for Information Interchange)コードのデータを通信可能となっているので、JLコマンド列は、ASCIIコードのデータに限られ、コマンドの変数としては、ASCIIコード中のプリント可能コード(数字、アルファベット等)しか指定できないという制約がある。
端末2からプリンタ3のMIB41を使用した処理を要求する場合に使用するJLコマンド列(第1のローカル通信用データ)は、例えば、“@JL MDR (短縮文字列)=“(MIBRequestデータ)””となっている。ここで、JLコマンド列の()は、記述そのものを示しておらず、記述内容を示している。なお、JLコマンド列は、各文字に対応するASCIIコードによって構成されている。
“@JL”は、JLコマンド列であることを示す。MDRは、当該JLコマンド列がMIBを利用した処理を行うコマンド列であることを示すコマンドである。このMDRは、既存のJLコマンドにはない新たなコマンドである。
短縮文字列は、対象とするOIDに含まれている短縮対象値を示している。
図3は、本発明の一実施形態に係るOIDの短縮対象値と短縮文字列との対応の一例を示す図である。
図3に示すように、短縮文字列としては、“PM”、“CM”とがあり、“PM”は、MIB41におけるプリンタMIBのOIDを示す短縮対象値“1.3.6.1.2.1.43”に対応し、“CM”は、短縮対応値“1.3.6.1”に対応する。
例えば、対象のOIDが“1.3.6.1.1.515.4”であれば、短縮対象値である“1.3.6.1”を含んでいるので、短縮文字列“CM”がJLコマンド列の短縮文字列として設定される。
次に、MIBRequestデータについて説明する。
図4は、本発明の一実施形態に係るJLコマンド列の一部のデータ構成を示す図である。図4(A)は、MIBRequestデータの構成を示している。
MIBRequestデータは、コマンドフィールド50と、OIDタイプフィールド51、OIDサイズフィールド52と、OIDフィールド53とを有する。なお、MIBRequestデータは、コマンドがSetRequestコマンドの場合には、値タイプフィールド54と、値サイズフィールド55と、値フィールド56とを有する。また、MIBRequestデータは、OIDタイプフィールド51からOIDフィールド53までの組(コマンドがSetRequestコマンドの場合には、OIDタイプフィールド51から値フィールド56までの組)を1以上有することができる。
コマンドフィールド50には、MIBエージェント40に実行させるコマンド(SNMPコマンド)を示す識別情報が格納される。コマンドを示す識別情報としては、SNMPコマンドが、OIDが示すオブジェクトの値(状態情報)の取得を要求するためのGetRequestコマンドであれば、“00”であり、OIDの階層に従った次のオブジェクトの値の取得を要求するためのGetNextRequestコマンドであれば、“01”であり、指定したOIDのオブジェクトの値の変更を要求するためのSetRequestコマンドであれば、“04”である。
OIDタイプフィールド51には、後続するOIDフィールド53に格納するデータのタイプが格納される。本実施形態では、OIDフィールド53に格納するデータがOIDであることを示す“00”が格納される。
OIDサイズフィールド52には、後続するOIDフィールド53に格納されるデータサイズ(データをバイナリ形式で格納した場合のバイト数)が格納される。
OIDフィールド53には、OIDの短縮対象値以外の部分を特定可能な情報(OID部分特定情報)が格納される。本実施形態では、当該OID部分特定情報と、短縮文字列とによって、対象のOIDの全体を特定することができる。ここで、本実施形態では、OID部分特定情報及び短縮文字列が、OID特定情報に相当する。
ここで、OID部分特定情報は、OIDの短縮対象値以外の部分をローカル通信で通信可能な形式に変換した情報である。具体的には、OID部分特定情報は、対象とするOIDの短縮対象値以外の部分の各枝番の値(ピリオドで区切られる各値)が対応する文字列として記述され、それら文字列が前から順に並べられたものとなっている。
図5は、本発明の一実施形態に係るOIDの変換を説明する図である。
OIDの枝の値からOID部分特定情報への変換においては、図5に示すように、対象のOIDの枝の値が00HEX〜7FHEXであれば、その値に対応する文字列“00”〜“7F”とされ、対象のOIDの枝の値が80HEX〜FFHEXであれば、文字列“81”のあとに、値に対応する文字列“80”〜“FF”を追加した文字列“8180”〜“81FF”とされ、対象のOIDの枝の値が0100HEX〜であれば、文字列“82”のあとに、値に対応する文字列を追加した文字列“820100”〜とされる。ここで、文字列“8”は、文字列が数値そのものではないことを示し、次に続く文字は、数値をバイナリコードで表した場合のバイト数を示している。例えば、“1”であれば、バイナリコードの1バイト(文字列では2文字)で数値を表していることを示し、“2”であれば、バイナリコードの2バイト(文字列では4文字)で数値を表していることを示している。
例えば、変換対象のOIDが“1.3.6.1.1.515.4”であれば、短縮対象値である“1.3.6.1”の後に続く“1.515.4”について、“1”を文字列“01”とし、“515”は、0203HEXであるので、文字列“820203”とし、“4”は文字列“04”とし、それらを繋げた“0182020304”がOID部分特定情報となる。
図4の説明に戻り、値タイプフィールド54には、後続する値フィールド56に格納するデータのタイプが格納される。本実施形態では、値フィールド56に格納するデータが8バイト文字であることを示す“14”が格納される。値サイズフィールド55には、後続する値フィールド56に格納されるデータサイズ(バイト数)が格納される。値フィールド56には、OIDが示すオブジェクトに設定させる値が格納される。
例えば、OID“1.3.6.1.2.1.43.6.1.1.2.1.1”に対するGetRequestコマンドを行う場合においては、OIDは、短縮対象値であってプリンタMIBを示す“1.3.6.1.2.1.43”を含んでいるので短縮文字列は、“PM”となる。また、MIBRequestデータのコマンドフィールド50には、GetRequestコマンドに対応する“00”が格納され、OIDタイプフィールド51には、OIDフィールド53に格納するデータがOIDであることを示す“00”が格納され、OIDサイズフィールド52には、OIDフィールドの長さが、6バイトであることを示す“06”が格納され、OIDフィールド53には、OIDのOID部分特定情報である“6.1.1.2.1.1”に対応する“060101020101”が格納される。
したがって、この場合のJLコマンド列は、“@JL MDR PM=“000006060101020101””となる。
次に、プリンタ3から端末2へ送信される、MIB41を使用した処理の要求に対する応答のJLコマンド列(第2のローカル通信用データ)について説明する。
プリンタ2から送信される応答JLコマンド列は、例えば、“@JL MDR (短縮文字列)=“(MIBResponseデータ)””となっている。ここで、JLコマンド列の()は、記述そのものを示しておらず、記述内容を示している。
“@JL”は、JLコマンド列であることを示す。MDR(MIB Direct Request)は、当該JLコマンド列がMIBを利用した処理に関わるコマンド列であることを示すコマンドである。このMDRは、既存のJLコマンドにはない新たなコマンドである。
短縮文字列は、対象とするOIDに含まれている短縮対象値を示している。なお、短縮文字列と短縮対象値との対応関係は、要求のJLコマンド列と同様である。
次に、MIBResponseデータについて説明する。
図4(B)は、MIBResponseデータの構成を示している。
MIBResponseデータは、レスポンスフィールド60と、リザルトフィールド61と、OIDタイプフィールド62、OIDサイズフィールド63と、OIDフィールド64とを有する。なお、MIBResponseデータは、コマンドがGetRequestコマンド、GetNextRequestコマンド等の場合には、値タイプフィールド65と、値サイズフィールド66と、値フィールド67とを有する。また、MIBResponseデータは、OIDタイプフィールド62からOIDフィールド64の組(コマンドがGetRequestコマンド、GetNextRequestコマンド等の場合には、OIDタイプフィールド62から値フィールド67までの組)を1以上有することができる。
レスポンスフィールド60には、MIBエージェント40による応答のコマンド(SNMPコマンド)を示す識別情報が格納される。コマンドを示す識別情報としては、SNMPコマンドが、GetRequestコマンドに対する応答であるGetResponseコマンドであれば、“80”であり、GetNextRequestコマンドに対する応答であるGetNextResponseコマンドであれば、“81”であり、SetRequestコマンドに対する応答であるSetResponseコマンドであれば、“84”である。
リザルトフィールド61には、要求の結果を示す情報が格納される。要求の結果を示す情報としては、例えば、正常である場合には、“00”が格納され、バッファオーバフローが発生した場合には、“81”が格納され、コマンド実行エラーが発生した場合には、“82”が格納される。
OIDタイプフィールド62には、後続するOIDフィールド64に格納するデータのタイプが格納される。本実施形態では、OIDフィールド64に格納するデータがOIDであることを示す“00”が格納される。
OIDサイズフィールド63には、後続するOIDフィールド64に格納されるデータのサイズ(バイト数)が格納される。
OIDフィールド64には、OIDの一部、すなわち、短縮対象値以外の部分を特定可能な情報(OID部分特定情報)が格納される。本実施形態では、当該OID部分特定情報と、短縮文字列とによって、対象のOIDの全体を特定することができる。このOID部分特定情報は、前述の要求時のJLコマンド列と同様な規則に従って設定されている。
値タイプフィールド65には、後続する値フィールド67に格納するデータのタイプが格納される。本実施形態では、値フィールド67に格納するデータが8バイト文字であることを示す“14”が格納される。値サイズフィールド66には、後続する値フィールド67に格納されるデータサイズ(バイト数)が格納される。値フィールド67には、要求時に指定したOIDのオブジェクトの値(状態情報)を示す文字列がASCIIコードで格納される。
OID“1.3.6.1.2.1.43.6.1.1.2.1.1”に対するGetRequestコマンドに対応するJLコマンド列“@JL MDR PM=“000006060101020101””を送信した場合には、例えば、応答のJLコマンド列“@JL MDR PM=“800000060601010201011407436F7665722041””が返信される。この応答のJLコマンド列においては、値タイプフィールド65には、“14”が格納され、値サイズフィールド66には、“07”が格納され、値フィールド67には、“436F7665722041“が格納されている。値フィールド67に格納されている文字列は、ASCIIコードで表現されているので、“CoverA”を示していることがわかる。したがって、この応答のJLコマンド列によると、OID“1.3.6.1.2.1.43.6.1.1.2.1.1”に対応する値は“CoverA”であることが把握できる。
図1の説明に戻り、状態情報取得処理部21は、SNMP処理部24から応答のSNMPメッセージを受け取り、当該SNMPメッセージに含まれているプリンタ3の状態情報を取得し、当該状態情報を用いて所定の処理、例えば、状態情報の表示処理等を実行する。
また、状態情報取得処理部21は、JL処理部22から応答のJLコマンド列を受け取り、当該JLコマンド列に含まれているプリンタ3の状態情報を取得し、当該状態情報を用いて所定の処理、例えば、状態情報の表示処理等を実行する。
SNMP処理部24は、ネットワーク5を介して接続された機器(例えば、プリンタ3)との間でSNMPに従った通信処理を行う。具体的には、SNMP処理部24は、下位プロトコルであるUDP(User Datagram Protocol)、IP(Internet Protocol)等に従った通信を行うソケット処理部25及びネットワークI/F26を使用して、SNMPメッセージの送受信を行う。本実施形態では、SNMP処理部24は、状態情報取得処理部21から取得したSNMPメッセージ(第3のSNMPメッセージ)をソケット処理部25に渡し、また、ソケット処理部25からプリンタ3により送信されたSNMPメッセージ(第4のSNMPメッセージ)を受け取り、状態情報取得処理部21に渡す。
ソケット処理部25は、SNMP処理部24から受け取った第3のSNMPメッセージをSNMPプロトコルパケットとして、ネットワークI/F26を介して、プリンタ3の所定のポート宛に送信し、また、所定のポート宛のSNMPプロトコルパケットをネットワークI/F26を介して受信して、当該SNMPプロトコルパケットから第4のSNMPメッセージを取り出して、SNMP処理部24に渡す。
図6は、本発明の一実施形態に係るSNMPプロトコルパケット及びSNMPメッセージの構成を示す図である。
SNMPプロトコルパケット100は、IPヘッダフィールド101と、UDPヘッダフィールド102と、SNMPメッセージフィールド103とを有する。
IPヘッダフィールド101には、IPに必要な各種情報、例えば、送信元IPアドレス、送信先IPアドレス等が格納される。UDPヘッダフィールド102には、UDPに必要な各種情報、例えば、送信元ポート、送信先ポート等が格納される。SNMPメッセージフィールド103には、SNMPメッセージが格納される。
SNMPメッセージフィールド103は、SNMPバージョンフィールド104と、コミュニティフィールド105と、PDU(Protocol Data Unit)フィールド106とを有する。SNMPバージョンフィールド104には、SNMPのバージョン情報が格納される。コミュニティフィールド105には、コミュニティ名が格納される。PDUフィールド106には、PDUが格納される。PDUは、ASN.1(Abstract Syntax Notation One)形式に従って記述される。
PDUフィールド106は、PDUタイプフィールド107と、リクエスト識別子フィールド108と、エラーステータスフィールド109と、エラー位置番号フィールド110と、MIB情報フィールド111とを有する。
PDUタイプフィールド107には、PDUのタイプが格納される。PDUには、指定したOIDのオブジェクトの値(状態情報)の取得を要求するためのGetRequestコマンドと、指定したOIDの階層に従った次のオブジェクトの値の取得を要求するためのGetNextRequestコマンドと、指定したOIDのオブジェクトの値の変更を要求するためのSetRequestコマンドと、GetRequestコマンドに対する返答のためのGetResponseコマンドと、GetNextRequestコマンドに対する返答のためのGetNextResponseコマンドと、SetRequestコマンドに対する返答のためのSetResponseコマンドと、管理される機器が自発的に状態変更を通知するためのTrapコマンドとがある。リクエスト識別子フィールド108には、要求と応答とを関連付けるための値(リクエスト識別子)が格納される。エラーステータスフィールド109には、正常であるか、エラーが発生しているかを示すステータスコードが格納される。エラー位置番号フィールド110には、エラーが発生した場合におけるエラーが発生したデータを示す値が格納される。MIB情報フィールド111には、PDUの対象となるOIDや、OIDに対応するオブジェクトの値(状態情報)が格納される。
図1の説明に戻り、プリンタ3の各部について説明する。
JLデータ記憶部35は、JLの通常コマンドによって利用される各種情報を記憶する。JLデータ管理部34は、JLデータ記憶部35に記憶されている各種情報に対するアクセス処理を実行管理する。
JL処理部33は、ローカルI/F32を介してUSBメモリ6の所定のディレクトリにアクセスし、当該ディレクトリにJLコマンド列を含む所定の名称のファイルが格納されているか否かを判定し、存在する場合には、ファイルを取得する。本実施形態では、所定のディレクトリとしては、例えば、“¥プリンタ製造会社名¥機種名¥status”とし、所定の名称としては、“Autoexec.jl”としている。
また、JL処理部33は、ローカルケーブル4から受信したJLコマンド列、又はUSBメモリ6から取得したJLコマンド列に、通常コマンド(本実施形態では、“MDR”以外のコマンド)が含まれている場合には、通常コマンドに対応する処理を実行する。例えば、JL処理部33は、通常コマンドに対応する情報をJLデータ管理部34によりJLデータ記憶部35から取得し、JLコマンド列を生成してローカルI/F31を介してローカルケーブル4に送信し、又はローカルI/F32を介してUSBメモリ6に格納する。この構成により、“MDR”コマンドに対応していない端末からの要求や、通常コマンドによる端末2から要求に対して、従来通りの処理を支障なく実行できる。
また、JL処理部33は、ローカルケーブル4からローカルI/F31を介して受信したJLコマンド列に、MIBを利用した処理を示す拡張コマンド(例えば、“MDR”)が含まれている場合には、当該JLコマンド列(第1のローカル通信用データ)をプロトコルコンバータ36に渡す。また、JL処理部33は、プロトコルコンバータ36から渡された応答のJLコマンド列(第2のローカル通信用データ)をローカルI/F31を介してローカルケーブル4に送信する。
また、JL処理部33は、USBメモリ6から取得したファイル中のJLコマンド列にMIBを利用した処理を示す拡張コマンド(例えば、“MDR”)が含まれている場合には、当該JLコマンド列(第1のローカル通信用データ)をプロトコルコンバータ36に渡す。また、JL処理部33は、プロトコルコンバータ36から渡された応答のJLコマンド列(第2のローカル通信用データ)をローカルI/F32を介してUSBメモリ6に所定のファイルとして格納する。JL処理部33は、例えば、ファイルを“¥プリンタ製造会社名¥機種名¥status”のディレクトリに、“機種名+シリアル番号+日時(年月日時)”の名称(例えば、機種A_1234_0707181800.sts)で格納する。
プロトコルコンバータ36は、MIBを利用した処理を示す拡張コマンドに対応する処理を実行するために、追加された機能部である。
プロトコルコンバータ36は、JL処理部33から渡されたJLコマンド列(第1のローカル通信用データ)に基づいてSNMPメッセージ(第1のSNMPメッセージ)を生成する処理を実行し、SNMPメッセージをMIBエージェント40に渡す。
具体的には、プロトコルコンバータ36は、SNMPメッセージのSNMPバージョンフィールド104に所定のSNMPのバージョンを格納し、コミュニティフィールド105に“Public”を格納し、PDUタイプフィールド107に、JLコマンド列のコマンドフィールド50に格納された識別情報に対応するSNMPコマンド(PDUタイプ)を格納し、MIB情報フィールド111に、JLコマンド列の短縮文字列及びOID部分特定情報に基づいて復元(生成)したOIDを格納することにより、SNMPメッセージを生成する。
OIDを復元する場合には、短縮文字列を、短縮文字列に対応する短縮対象値を示すASN.1形式のデータ(バイナリデータ)に変換し、さらに、OID部分特定情報のそれぞれの文字列を、その文字列に対応するASN.1形式のデータに変換する。文字列が“00”〜“7F”であれば、その文字列が示す値のASN.1形式のデータに変換し、“81”であれば、“81”以降の2文字に対応する値を示すASN.1形式のデータに変換し、“82”であれば、“82”以降の4文字に対応する値を示すASN.1形式のデータに変換する。このようにして、SNMPメッセージに設定するためのASN.1形式のデータからなるOIDを得ることができる。
また、プロトコルコンバータ36は、MIBエージェント40から取得した応答のSNMPメッセージ(第2のSNMPメッセージ)に基づいて応答のJLコマンド列(第2のローカル通信用データ)を生成する処理を実行し、JL処理部33に渡す。
応答のJLコマンド列は、前述したように、“@JL MDR (短縮文字列)=“(MIBResponseデータ)””となっている。
ここで、プロトコルコンバータ36は、MIBResponseデータのレスポンスフィールド60に、取得したSNMPメッセージのPDUタイプフィールド107に格納されているSNMPコマンドに対応する識別情報を格納する。例えば、PDUタイプフィールド107にGetResponseコマンドを示す識別情報が含まれていれば、GetResponseコマンドに対応する“80”が格納される。
また、プロトコルコンバータ36は、リザルトフィールド61には、SNMPメッセージのエラーステータスフィールド109に格納されているステータスに対応する情報を格納する。また、プロトコルコンバータ36は、短縮文字列としては、要求時のJLコマンド列に含まれていた短縮文字列を格納する。また、プロトコルコンバータ36は、OIDタイプフィールド62、OIDサイズフィールド63、及びOIDフィールド64には、要求時のJLコマンド列のOIDタイプフィールド51、OIDサイズフィールド52、及びOIDフィールド53に含まれていた情報を格納する。なお、SNMPメッセージのMIB情報フィールド111に格納されているOIDからOIDタイプフィールド62、OIDサイズフィールド63、及びOIDフィールド64に格納する情報を生成するようにしてもよい。
また、プロトコルコンバータ36は、MIB情報フィールド111にOIDに対応する値(状態情報)が含まれている場合には、当該状態情報を対応する文字列のASCIIコードに変換して値フィールド67に格納する。また、プロトコルコンバータ36は、値タイプフィールド65には、値フィールド67に格納するデータが8バイト文字であることを示す“14”を格納する。また、プロトコルコンバータ36は、値サイズフィールド66に、値フィールド67に格納した文字列のサイズを格納する。
SNMP処理部39は、ネットワーク5を介して接続された外部機器(例えば、端末2)との間でSNMPに従った通信処理を行う。具体的には、SNMP処理部39は、下位プロトコルであるUDP(User Datagram Protocol)、IP(Internet Protocol)等に従った通信を行うソケット処理部38及びネットワークI/F37を使用して、SNMPメッセージの送受信を行う。本実施形態では、SNMP処理部39は、MIBエージェント40から取得したSNMPメッセージ(第4のSNMPメッセージ)をソケット処理部38に渡し、また、ソケット処理部38からSNMPメッセージ(第3のSNMPメッセージ)を受け取り、MIBエージェント40に渡す。
ソケット処理部38は、SNMP処理部39から受け取ったSNMPメッセージ(第4のSNMPメッセージ)をSNMPプロトコルパケットとして、ネットワークI/F37を介して、端末2の所定のポート宛に送信し、また、所定のポート宛のSNMPプロトコルパケットをネットワークI/F37を介して受信して、当該SNMPプロトコルパケットからSNMPメッセージ(第3のSNMPメッセージ)を取り出して、SNMP処理部39に渡す。
MIBエージェント40は、プロトコルコンバータ36又はSNMP処理部39からSNMPメッセージ(第1、又は第3のSNMPメッセージ)を受け取り、当該SNMPメッセージのPDUタイプに応じた処理を実行する。例えば、MIBエージェント40は、受け取ったSNMPメッセージのPDUタイプがGetRequestコマンドを示していれば、SNMPメッセージのOIDに対応するオブジェクトの値をMIB41から取得し、当該取得した値を返送するためのPDUタイプがGetResponseコマンドのSNMPメッセージ(第2、又は第4のSNMPメッセージ)を生成して、要求元(プロトコルコンバータ36又はSNMP処理部39)に対して渡す。MIBエージェント40は、SNMPメッセージを利用したAPI(Application Programming Interface)となっているので、プロトコルコンバータ36に対しても、SNMP処理部39と同様に対応することができる。すなわち、SNMP処理部39に対して提供していた既存のSNMPにおける機能を、プロトコルコンバータ36に対しても同様に提供することができる。
次に、上記した各機能部により、端末2及びプリンタ3に構成されるプロトコルスタックについて説明する。
図7は、本発明の一実施形態に係るプロトコルスタックを説明する図である。図7(A)は、ネットワーク5を介して実行される通信におけるプロトコルスタックを説明する図であり、図7(B)は、ローカル接続による通信におけるプロトコルスタックを説明する図である。
ネットワーク5を利用した通信におけるプロトコルスタックは、図7(A)に示すように、ネットワーク5側の下位層から、端末2には、イーサネット(Ethernet)層206、Port層205、UDP層204、ソケット(socket)層203、SNMPマネージャ層202、OIDアプリケーション層201が構成される。本実施形態では、イーサネット層206は、主に、ネットワークI/F26によって実現され、Port層205、UDP層204、及びソケット(socket)層203は、ソケット処理部25によって実現され、SNMPマネージャ層202は、SNMP処理部24によって実現され、OIDアプリケーション層201は、状態情報取得処理部21によって実現されている。
また、プリンタ3には、イーサネット(Ethernet)層306、Port層305、UDP層304、ソケット(socket)層303、SNMPエージェント層302、MIBアプリケーション層301が構成される。本実施形態では、イーサネット層306は、ネットワークI/F37によって実現され、Port層305、UDP層304、及びソケット層303は、ソケット処理部38によって実現され、SNMPエージェント層302は、SNMP処理部39によって実現され、MIBアプリケーション層301は、MIBエージェント40によって実現されている。
また、ローカルケーブル4を利用した通信におけるプロトコルスタックは、図7(B)に示すように、ローカルケーブル4側の下位層から、端末2には、USB層209、要求側JL処理層208、コマンド準備層207、OIDアプリケーション層201が構成される。本実施形態では、USB層209は、ローカルI/F23によって実現され、要求側JL処理層208は、JL処理部22によって実現され、コマンド準備層207及びOIDアプリケーション層201は、状態情報取得処理部21によって実現されている。
また、プリンタ3には、USB層309、JL処理層308、プロトコルコンバータ層307、MIBアプリケーション層301が構成される。本実施形態では、USB層309は、ローカルI/F31によって実現され、JL処理層308は、JL処理部33によって実現され、プロトコルコンバータ層307は、プロトコルコンバータ36によって実現され、MIBアプリケーション層301がMIBエージェント40によって実現されている。
本実施形態によると、ローカル通信において、プロトコルコンバータ36によって提供されるプロトコルコンバータ層307によって、JL処理層308とMIBアプリケーション層301との間を容易且つ適切につなげることができる。
なお、プリンタ3は、USBメモリ6からデータを受信する機能を有しているので、USBメモリ6を接続する場合におけるプロトコルスタックは、図7(B)において、端末2をUSBメモリ6に置き換え、端末2側における要求側JL処理層208、コマンド準備層207、及びOIDアプリケーション層201が存在しないものに相当する。
次に、本発明の一実施形態に係る機器システムの処理動作を説明する。
図8は、本発明の一実施形態に係る端末による状態情報取得処理のフローチャートである。
端末2の状態情報取得処理部21が、電子機器(例えば、プリンタ3)から状態情報を取得する必要があるか否かを判定する(ステップS1)。例えば、状態情報を取得した時点から所定時間経過しているか否かによって、状態情報の取得する必要があるか否かを判定する。この結果、状態情報を取得する必要がないと判定した場合には、ステップS1を繰り返し実行する。
一方、状態情報を取得する必要があると判定した場合(ステップS1のYES)には、状態情報取得処理部21は、状態情報を取得する電子機器がネットワーク接続されている電子機器であるか否かを判定する(ステップS2)。
ネットワーク接続されている電子機器であると判定した場合(ステップS2のYES)には、状態情報取得処理部21は、必要とする状態情報のOIDを含むSNMPメッセージ(第3のSNMPメッセージ)を図示しないHDDから取得し(ステップS3)、SNMP処理部24に渡す。SNMP処理部24は、SNMPメッセージを、ソケット処理部25及びネットワークI/F26によりネットワーク5を介して電子機器に送信する(ステップS4)。
次いで、SNMP処理部24は、SNMPメッセージの送信先の電子機器から、ソケット処理部25及びネットワークI/F26を介して、応答のSNMPメッセージ(第4のSNMPメッセージ)を受信したか否かを判定し(ステップS5)、受信していない場合には、ステップS5を繰り返し実行する。一方、SNMPメッセージを受信した場合には、SNMP処理部24は、当該SNMPメッセージを状態情報取得処理部21に渡し、状態情報取得処理部21は、SNMPメッセージから状態情報を取得し(ステップS6)、当該状態情報を利用した処理を実行する。
一方、ネットワーク接続されていない電子機器、すなわちローカル接続されている電子機器であると判定した場合(ステップS2のNO)には、状態情報取得処理部21は、必要とする状態情報のOIDを特定するOID特定情報を含むJLコマンド列(第1のローカル通信用データ)をHDDから取得し(ステップS7)、JL処理部22に渡す。JL処理部22は、渡されたJLコマンド列をローカルI/F23によりローカルケーブル4を介して電子機器に送信する(ステップS8)。
次いで、JL処理部22は、ローカル接続された電子機器から応答のJLコマンド列(第2のローカル通信用データ)をローカルI/F23を介して受信したか否かを判定し(ステップS9)、受信していない場合には、ステップS9を繰り返し実行する。一方、受信した場合には、JL処理部22は、当該JLコマンド列を状態情報取得処理部21に渡す。状態情報取得処理部21は、JLコマンド列から状態情報を取得し(ステップS6)、当該状態情報を利用した処理を実行する。
この処理によって、ローカル接続されている電子機器に対して、MIB41から状態情報を取得させるコマンドを含むJLコマンド列を送信し、電子機器から受信した応答のJLコマンド列から状態情報を取得することができる。
図9は、本発明の一実施形態に係るプリンタによる状態情報送信処理のフローチャートである。この処理は、例えば、所定時間毎に実行される。
プリンタ3のJL処理部33は、ローカルケーブル4からローカルI/F31を介してJLコマンド列を受信したか否かを判定する(ステップS21)。この結果、JLコマンド列を受信していないと判定した場合には、処理を終了する。
一方、JLコマンド列を受信したと判定した場合には、JL処理部33は、JLコマンド列に、“MDR”(MIB利用処理コマンド)が含まれているか否かを判定する(ステップS22)。
この結果、MDRが含まれていると判定した場合(ステップS22のYES)には、JL処理部33は、JLコマンド列(第1のローカル通信用データ)をプロトコルコンバータ36に渡し、プロトコルコンバータ36は、JLコマンド列に基づいて、SNMPメッセージ用のOIDを生成し(ステップS23)、当該OIDを含むSNMPメッセージ(第1のSNMPメッセージ)を生成し(ステップS24)、SNMPメッセージをMIBエージェント40に引き渡す(ステップS25)。
MIBエージェント40は、引き渡されたSNMPメッセージからOIDを取得し、当該OIDに対応する値(状態情報)をMIB41から取得し(ステップS26)、状態情報を含む応答用のSNMPメッセージ(第2のSNMPメッセージ)を生成し、プロトコルコンバータ36に渡す。
プロトコルコンバータ36は、MIBエージェント40から応答のSNMPメッセージを受け取って(ステップS27)、当該SNMPメッセージから含まれている状態情報を抽出し(ステップS28)、当該状態情報を文字列のASCIIコードに変換して、MIB41を使用した処理要求に対する応答のJLコマンド列(第2のローカル通信用データ)を構築する(ステップS29)。本実施形態では、プロトコルコンバータ36は、応答用のJLコマンド列のデータ領域を確保し、その領域における値タイプフィールド65、値サイズフィールド66、及び値フィールド67に当該状態情報に対応する情報を格納して応答のJLコマンド列を構築する。次いで、プロトコルコンバータ36は、要求のJLコマンド列に次対象のOID特定情報が含まれているか否かを判定し(ステップS30)、次対象のOID特定情報が含まれている場合(ステップS30のYES)には、当該OID特定情報に基づいて、上記ステップS23からの処理を実行する。
一方、次対象のOID特定情報が含まれていない場合(ステップS30のNO)には、プロトコルコンバータ36は、ステップS29で構築した応答用のJLコマンド列に必要な他の情報を格納して完成させ(ステップS31)、JL処理部33に渡す。JL処理部33は、受け取ったJLコマンド列を外部装置にローカルI/F31及びローカルケーブル4を介して送信する(ステップS32)。この処理によって、MIB41から取得した状態情報をローカル接続された外部機器に対して送信することができる。
一方、JLコマンド列に“MDR”が含まれていないと判定した場合(ステップS22のNO)には、既存のJLコマンドの処理であることを意味するので、JL処理部33は、JLコマンド列に含まれているコマンドに対応する処理を、JLデータ管理部34を使用して実行し(ステップS33)、既存のJLコマンドの処理に対応する応答のJLコマンド列を生成し(ステップS34)、当該JLコマンド列を外部装置にローカルケーブル4を介して送信する(ステップS35)。
この処理によって、MDRではない、既存のJLコマンドによる処理を実行して外部機器に応答を返すことができる。
次に、プリンタ3に接続されるUSBメモリ6への状態情報の格納に関する格納制御処理を説明する。
図10は、本発明の一実施形態に係るプリンタによる格納制御処理のフローチャートである。なお、図9に示すステップと同様なステップには、同一符号を付している。
プリンタ3のJL処理部33は、ローカルI/F32に対して、USBメモリ6が接続されたか否かを判定し(ステップS41)、この結果、USBメモリ6が接続されていない場合には処理を終了する。
一方、USBメモリ6が接続されたと判定した場合(ステップS41のYES)には、JL処理部33は、ローカルI/F32を介してUSBメモリ6の所定のディレクトリにアクセスし、当該ディレクトリにJLコマンド列を含む状態取得ファイルが格納されているか否かを判定する(ステップS42)。その結果、状態取得ファイルが格納されていない場合には、処理を終了する。
一方、状態取得ファイルが格納されている場合(ステップS42のYES)には、JL処理部33は、USBメモリ6から状態取得ファイルを取得(受信)し、そのファイルからJLコマンド列を取得する(ステップS43)。
次いで、JL処理部33は、JLコマンド列に、“MDR”(MIB利用処理コマンド)が含まれているか否かを判定する(ステップS44)。
この結果、“MDR”が含まれていると判定した場合(ステップS44のYES)には、応答JLコマンド列生成処理(ステップS45:ステップS23〜ステップS31に相当)を実行する一方、JLコマンド列に“MDR”が含まれていないと判定した場合(ステップS44のNO)には、既存のJLコマンドの処理であることを意味するので、JL処理部33は、JLコマンド列に含まれているコマンドに対応する処理を、JLデータ管理部34を使用して実行し(ステップS33)、処理に対応する応答のJLコマンド列を生成する(ステップS34)。
ステップS45又はステップS34において、JLコマンド列が生成されると、JL処理部33は、ローカルI/F32を介してUSBメモリ6の所定のディレクトリにアクセスし、生成されたJLコマンド列を所定の名称のファイルとして書き込む(送信する)(ステップS46)。
この処理によって、USBメモリ6を使用して、MIB41に管理されている機器情報をUSBメモリ6内に容易に格納させることができる。
以上、本発明を実施形態に基づいて説明したが、本発明は上述した実施の形態に限られず、他の様々な態様に適用可能である。
例えば、上記実施形態では、電子機器の一例としてプリンタを用いて説明していたが、本発明はこれに限られず、イメージスキャナ、FAX等の他の電子機器にも適用することができ、要は、MIBを有し、ローカル接続可能な電子機器であれば本発明を適用することができる。
また、上記実施形態では、外部機器として、USBメモリを例に示していたが、本発明はこれに限られず、外部機器はローカル接続可能な他の記憶媒体であってもよい。
また、上記実施形態では、OID特定情報として、OID部分特定情報及び短縮文字列を用いていたが、本発明はこれに限られず、OID特定情報としては、短縮文字列を用いずに、OIDのそれぞれの数値を文字列に変換した情報であってもよく、要はOIDを特定することができる情報であればよい。
また、上記実施形態では、ローカル接続としてUSB規格による接続を例に示していたが、本発明はこれに限られず、例えば、RS−232C、IrDA(Infrared Data Association)、IEEE1394等の他の規格による接続に対しても適用することができる。
また、上記実施形態では、JLコマンド列においては、SNMPメッセージにおけるコミュニティ名称を指定しないようにしていたが、本発明はこれに限られず、JLコマンド列において、SNMPメッセージにおけるコミュニティ名称を設定できるようにし、生成するSNMPメッセージのコミュニティフィールド105に当該コミュニティ名称を格納するようにしてもよい。このようにすると、所定の権限が必要なMIB41に対する処理を、JLコマンド列を送信することにより実行させることができるようになる。
1 機器システム、2、2A、2B 端末、3 プリンタ、4 ローカルケーブル、5 ネットワーク、6 USBメモリ、21 状態情報取得処理部、22 JL処理部、23 ローカルI/F、24 SNMP処理部、25 ソケット処理部、26 ネットワークI/F、31、32 ローカルI/F、33 JL処理部、34 JLデータ管理部、35 JLデータ記憶部、36 プロトコルコンバータ、37 ネットワークI/F、38 ソケット処理部、39 SNMP処理部、40 MIBエージェント、41 MIB。