(57)【要約】  需要メータは、需要サーバやネットワークへのアクセスポイントに位置することができるメータ読込アプリケーションから需要メータと関連付けられた通信モジュールへ、メータを読み込むためのリクエストを送信することによって読み込まれてもよい。通信モジュールは、需要メータとのセッションを開始し、関連付けられた需要メータからデータに対する要求を生成し、需要メータからデータに対する要求への応答を受信し、メータから要求されたデータを全て受信した後、セッションを終了する。次に、需要メータから受信したデータの応答をフォーマットし、メータ読込アプリケーションへフォーマットした応答を送信する。
2010534029.tif 000002
【特許請求の範囲】
【請求項１】
需要ネットワークと関連付けられたシステムであって、
消耗品のメータ情報を読み込むことが可能な複数の需要メータと、
需要ネットワークに配置され、前記需要メータと連動し、前記需要メータから前記有用品のメータ情報を受信し、所定のネットワークアドレスへ情報を送信することができる複数の需要ネットワークノードと
を有し、
少なくとも一つの前記需要ノードは、メータ読込プログラムからの読込メータ要求の受信に応答して、
少なくとも一つの前記需要メータとのセッションを初期化し、
少なくとも一つの前記需要メータへの複数のメータデータ要求を生成し、
前記需要メータから前記メータデータ要求への応答を受信し、
メータ読込要求応答へ、前記メータデータ要求に対する受信した前記応答をフォーマットし、
受信した前記メータ読込要求と関連付けられた所定のネットワークアドレスへ前記メータ読込要求応答を送信する
ことを特徴とするシステム。
【請求項２】
前記需要ネットワークノードは、予め設計されたプロトコルフォーマットに準じた要求／応答メッセージの双方向交換を含むオフネットもしくはオンネットのセッションと関連づけられている需要メータと連動できることを特徴とする請求項１に記載のシステム。
【請求項３】
前記メータ読込要求応答のフォーマットは、ＡＮＳＩのＣ１２．１９もしくはＣ１２．１８のいずれかに基づいていることを特徴とする請求項１に記載のシステム。
【請求項４】
Ｃ１２．１９フォーマットにおいて動作する前記需要メータとのセッションにおいて、前記需要ネットワークによって用いられる前記プロトコルは、前記ＡＮＳＩの１２．１８プロトコルフォーマットに基づいていることを特徴とする請求項１に記載のシステム。
【請求項５】
メータ読込要求に関するメッセージ交換において、前記需要サーバと前記需要ノードによって用いられる上位レベルメッセージプロトコルは、単純Ｃ１２．１８読込プリミティブの単純パススルーであるプリミティブの集合の定義を含むことを特徴とする請求項４に記載のシステム。
【請求項６】
前記送信された読込メータ要求応答は、前記送信されたメータ読込要求応答に含まれた前記消耗品のメータ情報を解釈するために用いられる少なくとも一つの先頭に付加された注釈を含むことを特徴とする請求項５に記載にシステム。
【請求項７】
前記需要ネットワークノードへ前記サーバによって送信される前記メータ読込データ要求を有するより上位レベルのプロトコルメッセージは、ＩＰｖ４、ＩＰｖ６のうちのいずれか一つの形式であることを特徴とする請求項５に記載のシステム。
【請求項８】
前記需要ネットワークノードへ前記需要ネットワークノードによって送信される前記メータ読込データ要求を有するより上位レベルのプロトコルメッセージは、ＩＰｖ４、ＩＰｖ６のうちのいずれか一つの形式であることを特徴とする請求項５に記載のシステム。
【請求項９】
前記受信したメータ読込要求に関連付けられた前記所定のネットワークアドレスは、需要サーバに対応することを特徴とする請求項５に記載のシステム。
【請求項１０】
前記受信したメータ読込要求に関連付けられた前記所定のネットワークアドレスは、前記需要ネットワークへのアクセスポイントに対応し、前記メータ読込プログラムは前記ネットワークアドレスに関連付けられた前記アクセスポイントに位置することを特徴とする請求項５に記載のシステム。
【請求項１１】
前記物資メータとの１以上のＣ１２．１８セッションを介して、前記需要ネットワークノードによって収集された前記データは、ＴＬＶ（時間、長さ、値）の組に基づいていることを特徴とする請求項５に記載のシステム。
【請求項１２】
前記需要ネットワークノードから前記需要サーバへの前記応答メッセージは、前記応答から任意の特定ＴＬＶを削除するためのオプションを有するセクションを符号化した一連の実行時間長である前記要求されたデータを含み、含まれるヘッダは、データのタイプと前記ヘッダの直後に位置する前記データの一部の長さを示すことを特徴とする請求項１１に記載のシステム。
【請求項１３】
需要メータを読み込むための要求に応答する方法であって、
需要メータと対応付けられた通信ノードによってメータ読込アプリケーションからメータ読込要求を受信する工程と、
前記通信モジュールと前記需要メータとの間のセッションであり、前記需要メータとのセッションを開始する工程と、
前記需要メータへの複数のデータ要求を生成する工程と、
前記通信モジュールによって、前記需要メータとの複数のデータ要求に対応付けられた複数の応答を受信する工程と、
前記通信モジュールによって、前記メータ読込アプリケーションからの前記読込メータ要求への応答をフォーマットする工程と、
前記メータ読込アプリケーションへの前記応答を送信する工程と
を有することを特徴とする方法。
【請求項１４】
メータ読込アプリケーションから受信した前記メータ読込要求はＣ１２．１８に準拠していることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記需要メータは、Ｃ１２．１９準拠需要メータであり、前記Ｃ１２．１９準拠需要メータへの複数の前記データ応答は、Ｃ１２．１８準拠であることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記需要ネットワークノードは、前記Ｃ１２．１９準拠需要メータとの独立型Ｃ１２．１８セッションを行うことができることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記メータ読込アプリケーションへの前記応答をフォーマットすることは、注釈情報を含むことを特徴とする請求項１５に記載の方法。
【請求項１８】
需要ネットワークにおいて用いられる通信モジュールであって、
需要メータへのインターフェースと、
命令を格納するためのメモリと、
命令を処理するためのプロセッサと、
ＲＦネットワークを用いてメータ読込アプリケーションと通信するためのＲＦ無線と
を有し、
前記プロセッサは、
メータ読込アプリケーションから受信したメータ読込要求に応答して需要メータとのセッションを開始し、
前記需要メータへの複数のデータ要求を生成し、
前記通信モジュールによって、前記需要メータへの複数の前記データ要求に対応付けられた少なくともいくつかの複数の受信した応答を用い、前記通信モジュールによって、前記メータ読込アプリケーションから前記メータ読込要求への応答をフォーマットし、
前記メータ読込アプリケーションへの前記応答を送信する
命令を実行することを特徴とする通信モジュール。
【請求項１９】
メータ読込アプリケーションからの受信された前記メータ読込要求は、Ｃ１２．１８に準拠していることを特徴とする請求項１８に記載の通信モジュール。
【請求項２０】
前記需要メータは、Ｃ１２．１９準拠需要メータであり、前記Ｃ１２．１９準拠需要メータへの複数の前記データ要求は、Ｃ１２．１８準拠であることを特徴とする請求項１９に記載の通信モジュール。
【請求項２１】
前記需要ネットワークノードは、前記Ｃ１２．１９準拠需要メータと独立型Ｃ１２．１８セッションを行うことができることを特徴とする請求項２０に記載の通信モジュール。
【請求項２２】
前記メータ読込アプリケーションへの前記応答をフォーマットすることは、注釈情報を含むことを特徴とする請求項２０に記載の通信モジュール。
【請求項２３】
前記ＲＦ無線は、ＩＰベースのプロトコルを用いたメッセージを送信することを特徴とする請求項２０に記載の通信モジュール。
【請求項２４】
ＩＰベースのプロトコルは、ＩＰｖ６もしくはＩＰｖ４のうち、少なくとも一つのプロトコルを含むことを特徴とする請求項２０に記載の通信モジュール。
【請求項２５】
前記ＲＦ無線は、ＩＰプロトコルフォーマットにおける前記メータ読込アプリケーションからメータ読込データ要求を受信することを特徴とする請求項２０に記載の通信モジュール。
【請求項２６】
前記ＩＰベースのプロトコルは、ＩＰｖ６及びＩＰｖ４のうち、少なくとも一つのプロトコルを含むことを特徴とする請求項２０に記載の通信モジュール。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、需要ネットワーク、より詳細には、システム及び需要メータの読込に対する需要ネットワーク管理システムの命令の方法に関する。
【背景技術】
【０００２】
Ｃ１２．１９は、表形式の電子需要メータデータを展開し、組み立てるためのＡＮＳＩ規格であり、さらに処理を容易にするための特定のフォーマットに並べられた情報である。
【０００３】
Ｃ１２．１８は、サーバ（メータ読込アプリケーションとして特定されている）とクライアントＣ１２．１９需要メータとの間の転送セッションのためのＡＮＳＩプロトコル仕様であり、Ｃ１２．１９メータに格納されたＣ１２．１９データテーブルに含まれた特定の態様のデータ要求すること、および該データをＣ１２．１９メータから受信することを含む。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
需要メータは、需要サーバやネットワークへのアクセスポイント上に位置することができるメータ読込アプリケーションから需要メータに関連付けられた通信モジュールへ、メータを読み込むための要求が送信されることによって、読み込まれることができる。通信モジュールは、需要メータとのセッションを開始し、関連付けられた需要メータからデータに対する要求へ応答し、全ての要求されたデータを受信した後、セッションを終了する。次に需要メータによって受信されたデータをフォーマットし、メータ読込アプリケーションへフォーマットした応答を送信する。
【０００５】
ひとつの好ましい実施形態において、ＡＮＳＩ規格Ｃ１２．１８及びＣ１２．１９を用いたプロトコルが利用されている。通信モジュールは関連付けられた需要メータとのＣ１２．１８セッションを開始し、メータ読込アプリケーションからのメータを読み込むための要求を実行するために、メータからのデータに対する要求を生成する。関連付けられたメータは、Ｃ１２．１９規格に従った通信モジュールにデータを提供する。通信モジュールは、メータ読込アプリケーションに提供される応答へ受信したメータデータをフォーマットし、メータ読込アプリケーションへフォーマットされた応答を送信する。メータデータは、メータ読込アプリケーションにデータを読み込ませ、解釈させるためにフォーマットされ、Ｃ１２．１９規格に従ってフォーマットされる。
【０００６】
この発明における前述の側面及び多くの付随する利点は、添付した図面を併せて用いることにより、より容易く評価され、以下の詳細な記述を参照してより良く理解されるであろう。
【図面の簡単な説明】
【０００７】
【図１】図１は、メータ読込処理を実装されることができる需要ネットワークを示した一つの可能な実施形態としてのブロック図である。
【図２】図２は、メータ読込要求への応答処理の一つの可能な実施形態としてのフロー図である。
【図３】図３は、メータ読込における通信フローを示した一つの可能な実施形態としてのフロー図である。
【図４】図４は、Ｃ１２．１９メータデータに対する典型的な共有サーバ要求の一般化されたブロック図及び、通信コミュニケーションからの注釈つきの応答である。
【発明を実施するための形態】
【０００８】
図１は、共有メータ１１０が遠隔デバイスによって“読み込み”されてよいシステムを示す一般化されたブロック図である。他で述べられていない限りは、メータの“読み込む”もしくは“読み込み”という単語は、メータからの情報収集を指し、その情報は、消耗品や需要メータ上の情報を含んでよく、また、他の情報、もしくは両方を含んでもよい。需要メータ１１０は、典型的に、ＰＯＴＳモデム、光結合器、通信モジュール１２０のようなその他のシリアルデバイスへ接続されることができるハードウェアインタフェース１４０を含む。通信モジュール１２０は、需要メータインタフェース１６０、ＲＦ無線１７０、コンピュータ可読命令を格納するためのメモリ１８０、コンピュータ可読命令を処理するためのプロセッサ１９０を含んでよい。共有メータは、例えば、電気、ガス、水などの公益事業によって提供される生活必需品を計測もしくは測定する。一つの可能な実施形態において、通信モジュール１２０は、需要メータと統合される。また他の可能な実施形態において、通信モジュールは、需要メータとインタフェースで接続された、別個のモジュールである。現下、好ましい実施形態において、通信モジュールは、１以上の遠隔共有サーバのような遠隔デバイスと通信を行うことができるＲＦ無線を含む。通信モジュールは、ローカルエリアネットワーク（ＬＡＮ）のような無線ネットワークの一部であっても良く、好ましくは、出口／入口サポートを提供するアクセスポイント（ゲートウェイのようにも問い合わされる）を介して、需要ネットワークサーバとの双方向データ通信リンクを有してもよい。アクセスポイントもしくは需要サーバ１３０は、メータ読込アプリケーションを含み、通信モジュールを介してメータとのネットワーク接続されたセッション（例えば、Ｃ１２．１８セッション）を開始することができる。シリアル相互接続にて、Ｃ１２．１８セッションは、通信モジュールとＣ１２．１９メータとの間で導かれることができる。通信モジュールは、“メータアクセスデバイス”としても呼ばれる。一つの好ましい実施形態において、通信モジュールは、関連付けられたメータと通信ネットワークの間の通信を提供するネットワークインタフェースカード（ＮＩＣ）である。通信モジュールは、需要ネットワークノードとして呼ばれてもよい。他で述べられていない限りは、単語需要ネットワークノードは関連付けられた需要メータを組み合わせた通信モジュール、もしくは、特定の共有メータを備えない通信モジュールを示してよい。
【０００９】
図１において、一つの通信モジュールと一つの需要メータのみが示されているが、代わりの実施形態は、１以上の通信モジュールと１以上の需要メータを有して良いし、それらは、多数のネットワーク、もしくは、１以上のアクセスポイントを通って、アクセス可能であることの少なくとも一方であるように構成されてもよい。加えて、１以上のネットワークを通ってアクセス可能な、１以上の需要サーバがあってもよい。
【００１０】
図２は、データに対する要求に応答する処理２００を示す一般化されたフロー図である。ステップ２０１にて、需要メータと対応付けられた通信モジュールは、データに対する需要メータを読み込むためにサーバもしくはアクセスポイントにおけるメータ読込アプリケーションから要求を受信する。対応付けられた需要メータからの読込データへの要求に応答する際に、通信モジュールは、ステップ２０２にて、応答を受信するために、要求が受信された後、任意の時間で、メータ読込アプリケーションによって規定された任意のタイミング期限に従って、共有メータとのセッションを開始する。ステップ２０３にて、共有メータ確認のセッション開始は受信される。ステップ２０４にて、通信モジュールは、共有メータへデータ読込要求を送信する。ステップ２０５にて、通信モジュールは、データ読込要求への需要メータ応答を受信する。応答は、要求されたデータを含んでよく、もしくは、１以上のメッセージ、例えばエラーメッセージもしくはいくつかの他のメッセージを含んでよい。ステップ２０６にて、通信モジュール追加のデータ読込があるか否かを判定する。もし追加のデータ読込があれば、処理は、関連付けられた需要メータへデータ読込要求を送信するステップ２０４へ進む。もし、ステップ２０６にて、実行されるべき追加のデータ読取が無いと判定されたら、処理はステップ２０７へ進む。ステップ２０７にて、通信モジュールは関連付けられた需要メータへセッション終了メッセージを送信する。ステップ２０８にて、セッション終了の需要メータ確認は、通信モジュールにて受信される。ステップ２０９にて、通信モジュールはメータ読込アプリケーションへの応答をフォーマットする。ステップ２１０にて、通信モジュールは、関連付けられた需要メータを読み込むために受信した要求へ応答を送信することによって、ステップ２０１にて受信されたデータに対する要求へ応答する。現下の好ましい実施形態において、応答は、メータ読込アプリケーションに、データに対して一致している要求を応答に関連付けさせるための適当な注釈を有する情報を含む。加えて、もしくは代わりに、応答は、メータ読込アプリケーションに、データを解釈させるための情報を含んでもよい。可能な要求及び応答の一つの例は、図４を関連してより十分に以下で述べられている。
【００１１】
Ｃ１２．１９メータを有するＣ１２．１８セッションを開始する需要サーバにおけるメータ読込アプリケーションの典型的な処理は、ネットワークリソースを浪費する。Ｃ１２．１８プロトコルは、全メータ読込処置の間において、連続的にネットのセッションを有効として指定する、つまり、全セッションの間で維持される転送コネクションを要求する。セッションは、通信モジュールを介して、サーバのメータ読込アプリケーションからの開始処理メッセージをメータへ開始する。ここで受動的であるような単純に動作する通信モジュールは、メータ読込アプリケーションとメータとの間を中継する。命令が、サーバから通信モジュールへ繰り返される際、通信モジュールは、メータへ要求されたデータ収集動作を実行する。要求と応答処理は、セッションがサーバから通信モジュールへの終了メッセージによって、終了されるまで続けられる。特定の識別要求（ｓｔｄ０、ｓｔｄ６３、ｓｔｄ６４など）によってメータ情報ブロックを取得することにより、サーバは、直ちに、情報を構文分析し、解析できる。しかしながら、有益なネットワークリソースは、ネットワークの全継続時間に対してセッションを開き続けることによって、浪費される。共有ネットワークにおいて、メータの数が増加するにつれて、この態様は非常にコスト高となり、限界を迎える。
【００１２】
ここで述べられたメータを読み込む典型的なアプローチの適応は、メータ読込アプリケーションとネットワーク化された通信モジュールを取り付けたメータとの間のより上位レベルのプロトコルを述べることを含んでいる。ここで開示されている適応アプローチは、図３にて述べられる。通信モジュールは、上位レベルのプロトコル要求を受信し、次にプロキシによって、メータとのＣ１２．１８セッションを導く。Ｃ１２．１８セッションの結果は、より上位レベルのプロトコル要求に対する応答を定式化するのに用いられる。これを容易にするため、通信モジュールは単なるバイトパススルーデバイス以上のものとして構成される。上位レベルプロトコルのサーバ側とＣ１２．１８プロトコルのクライアント側両方に構成される。この上位レベルプロトコルは、単純なＣ１２．１８読込プリミティブのストレートパススルーであるプリミティブの集合を定義する。さらに、このプロトコルは、代表として一連のＣ１２．１８プロトコル要求を含むより上位レベルの命令を定義する。この上位レベルプロトコル要求に対する通信モジュールによる応答は、追加的に先頭に付加されたデータを有するＣ１２．１９データの集りである。Ｃ１２．１９データは、自己記述的ではなく、それを取得するために用いたＣ１２．１８プロトコル要求を知った上で解釈できるのみである。従って、サーバにおけるメータ読込アプリケーションは、生のＣ１２．１９データを解釈するために追加の情報を要求する。この追加の“注釈”は、作成され、共有サーバへの通信モジュールの応答に含まれる。
【００１３】
Ｃ１２．１８データ取得セッションの最後において、メータ読込アプリケーションは、Ｃ１２．１９データを構文分析し、それにより要求されたアクションは何であっても実行してよい。
【００１４】
需要メータからの情報に対する要求は、１以上のプロトコルを用いるようにしてもよい。現下の好ましい実施形態において、要求と対応する応答は、ＡＮＳＩ規格のＣ１２．１８とＣ１２．１９を用いるようにしてよい。可能な実施形態は、Ｃ１２．１８とＣ１２．１９を用いる要求と対応する応答が、図３にて示されているの通信フロー図と図４にて示されている例の応答における以下の例Ａにて述べられている。
【００１５】
例Ａ
Ｃ１２．１９規格に準じて動作するメータは、通信モジュールに関連付けられる。通信モジュールは、Ｃ１２．１９に従ってメータ読込アプリケーションへの応答をフォーマットする。図２の上述した接続における場合、通信モジュールは、関連付けられた需要メータからのデータを読み込むために読込メータ要求を受信できる。通信モジュールは、需要メータと関連付けられたＣ１２．１８セッションを開く。需要メータは、通信モジュールによって受信されたＣ１２．１９規格に準じてフォーマットされた情報に応答する。一つの好ましい実施形態において、通信モジュールは、対応付けられた全ての（もしくは複数の）データ読込要求を生成し、読込メータ要求に応答する前にＣ１２．１９に準じてフォーマットされた需要メータからの対応する応答を受信する。そのような実施形態において、メータから受信した応答からの情報は、読込メータ要求への単一の応答、つまり、需要サーバやアクセスポイント上に位置するメータ読込アプリケーションへ送信されている単一の応答に含まれている。読込メータ要求への単一の応答は、Ｃ１２．１９規格に準じてフォーマットされ、メータ読込アプリケーションに、対応する読込メータ要求への応答を関連付けさせるための情報を含む。好ましくは、応答は、メータ読込アプリケーションにデータを解釈させるための情報も含む。
【００１６】
発明の一つの好ましい実施形態は以下で述べられる。メータ読込アプリケーションは、事務管理部門のサーバや、全てのＣ１２．１９需要メータが置かれ、個々の通信モジュールを介してネットワークに接続されている無線ネットワークのアクセスポイントに備わっていてよい。通信モジュールは、ネットワークの接続性及びメータとのネットワークインタフェースを提供するために各Ｃ１２．１９メータ位置に置かれている。サーバやアクセスポイントのメータ読込アプリケーションは、ネットワーク上の通信モジュールへのメータ読込要求を作成する。要求は、データメッセージのように機能し、好ましくは、ＩＰｖ６やＩＰｖ４パケットの形式である。しかしながら、パケットプロトコルの他のタイプが、ここで述べられる発明と同様に適用できる。この要求は、通信モジュールに、多くのＣ１２．１８初期命令が、要求されたデータを収集するように導くための一つのＣ１２．１８セッションを開始するように指示する。通信モジュールは、続いて、データを適切に解釈するために、ネットワークサーバにおけるメータ読込アプリケーションを促進するための解釈や注釈などを有するデータを再パッケージする。要求されたデータは、対応するヘッダやデータ領域を有するＩＰｖ４やＩＰｖ６パケットのグループとして事務管理部門のサーバへ無線ネットワークを越えて送信される。
【００１７】
図３は、媒介やプロキシ機能を実行する通信モジュールを介したメータ読込アプリケーションとメータとの間の同期交換を述べている。サーバにおけるメータ読込アプリケーションは、メッセージ３０１にて、着目通信モジュールへマスタＣ１２．１９メータデータ要求を送信する。これは典型的に（これに限定するわけではないが）、ＩＰｖ４やＩＰｖ６パケットの形式である。これらの要求メッセージのタイプは、他の通信モジュールや他のネットワーク命令メッセージに合わせられた要求を備えるサーバによって、配信されてよい。通信モジュールは、サーバによって生成された要求を実行するために、メータとの“非ネットワーク”Ｃ１２．１８メータ読込セッションを開始する。通信モジュールは、メータとの１以上のＣ１２．１８セッションにおける複数のメータ読込データ要求を実装し、サーバへ応答する前にデータの全て、もしくは一部を組み立ててよい。従って、通信モジュールは、需要サーバのプロキシとして動作する。Ｃ１２．１８セッション自身は、セッションが終了され、応答されるまで、Ｃ１２．１８規格において述べられている要求応答メッセージのシリアル双方向交換を有する標準のＣ１２．１８セッションと似ている。図３にて示された例におけるＣ１２．１８セッションは、３１１を介してメッセージ３０２にて記述される。セッションが完了した後、通信モジュールは、先頭に追加された適切な注釈を有するＣ１２．１９メータデータを組み立て、ＩＰｖ４、ＩＰｖ６、もしくは他のプロトコルパケットの形式にて、そのメッセージ３１２をサーバへ送信する。ここでサイド留意されるべきこととして、サーバが通信モジュールへそのメッセージにおける複数のメータ読込を要求し、通信モジュールは、全ての要求されたデータを取得した後に１以上のメッセージに応答してよい。重要な要件は、通信モジュールが、サーバに対しデータ形式を認識し、それに沿ってそれらを処理するためにＣ１２．１９データに注釈をつけることである。
【００１８】
図４は、（Ｃ１２．１９メータ読込データに対する）要求と通信モジュールからの注釈付けされた応答の例を示す。この通信は、ＩＰパケットの形式における典型的なデータメッセージとしてより上位レベルプロトコルにて行われる。需要サーバからの典型的なメータ読込要求は、メッセージ４１０にて表現される。サーバは、必要とされた識別情報を提供された事前の要求開始を提供している。特定の読込テーブル（Ｃ１２．１９データテーブル）要求は、４１２にて示されている。“ロードプロファイル読込（Ｒｅａｄ  Ｌｏａｄ  Ｐｒｏｆｉｌｅ：ＬＰ）”命令と関連している要求は、４１３にて記述されている。需要ネットワークノードが需要サーバから受信することができるタイプ４１０の複数のメッセージが存在できる。続いて、１以上のＣ１２．１８セッションに、需要サーバからの要求ごとにメータからのデータを取得するようにする。需要ネットワークノードは、続いて、注釈を付された応答４２０を作成し、それを需要サーバへ送信する。応答は、１以上の要求を追跡する。ここで示された例において、４２０は、一つの要求に対する典型的な応答を示している。事前の応答４２１の開始は、事前の要求の開始の後を追う。テーブル読込命令（Ｒｅａｄ  Ｔａｂｌｅ  Ｏｐｅｒａｔｉｏｎ）４２２のデータは、要求の後に続き、需要サーバのメータ読込アプリケーションによって要求された順番で、データを配置する。同様に、ＬＰ読込命令メッセージは４２３は、要求４１３の後に続き、４１３に要求された順番でロードプロファイルデータを配置する。このフォーマットされた応答４２０は、効率的かつ正確にメータ読込情報を処理するために需要サーバを補助する。
【００１９】
データ取得の最後において、サーバのメータ読込アプリケーションは、拡大されたＣ１２．１９データを構文分析し、それによって要求されるアクションは何であっても実行することができる。
【００２０】
＜適応方法の命令及びデータフォーマット＞
適応方法の例となる命令及びデータフォーマットは、上位レベルプロトコルやＣ１２．１９データマークアップ層の性質を述べるために、ここで示される。ここで示された詳細は、要求や応答パケットを認識するために用いられることができるデータ構造と同等に、上位レベルプロトコルの理解を固めることを補助することを意図するのみである。この例が、包括的なものを意味しているわけではなく、また、この実施形態のみに限定するものでもない。
【００２１】
＜要求命令＞
全ての要求の最初の部分は、“要求の開始（Ｓｔａｒｔ  ｏｆ  Ｒｅｑｕｅｓｔ）”ヘッダである。
【００２２】
・３２ビットのユーザによって設定されうるデータ（要求者へエコーバックされる）
・３２ビットの長さ（このヘッダより小さい全要求の長さ）
の形式からなる。
【００２３】
このセクションは、要求もしくは応答にて用いられるデータ構造を述べている。この（もしくは以下のような他のもの）ようなヘッダにおいて、ヘッダの直後に続くデータの長さは、データの構文分析ができることを意味する。“３２ビットの長さ”とは、このヘッダに付随するのに好ましいバイト数である。
【００２４】
各要求命令は、共通のヘッダ部および命令に特有の部分を有する。共通のヘッダ部は、以下の形式からなる。
【００２５】
・３２ビットの命令ＩＤ
本例のプロトコル命令と命令特有の要求ヘッダは、以下の通りである。
【００２６】
・ストレートＣ１２．１８パススルー（Ｓｔｒａｉｇｈｔ  Ｃ１２．１８  ｐａｓｓ−ｔｈｒｕ）
テーブル読込
−１６ビットのテーブルＩＤ
−１６ビットのパディング
・テーブルオフセット読込
−１６ビットのテーブルＩＤ
−１６ビットの長さ
−３２ビットのオフセット
・レジスタ読込
−命令特有のヘッダなし
・前回のレジスタ読込時期
−３２ビットタイムスタンプ（ＵＮＩＸ（登録商標）  ＧＭＴ）
・前回の要求レジスタ読込
−３２ビットタイムスタンプ（ＵＮＩＸ（登録商標）  ＧＭＴ）
・自己読込レジスタ読込
−３２ビット開始シーケンス＃
・ロードプロファイル読込
−３２ビット開始ブロック＃
−３２ビット開始シーケンス＃
−３２ビット終了ブロック
−３２ビット終了シーケンス
・イベントログ読込
−３２ビット開始シーケンス
−３２ビット終了シーケンス
命令は、一つの要求に共にグループ化できる。例えば、レジスタ読込命令と共にテーブル読込命令が実行されてよい。一つのＣ１２．１８セッションの下で、各要求が適切に実行される際、テーブル読込命令とレジスタ読込命令は、互いに同時期に行われるであろう。
【００２７】
＜応答＞
応答の最初の部分は“応答の開始（Ｓｔａｒｔ  ｏｆ  Ｒｅｓｐｏｎｓｅ）”ヘッダである。これは好ましくは以下の形式からなる。
【００２８】
−３２ビットのユーザによって設定されうるデータ（要求から）
−３２ビットの要求ステータス
−３２ビットの長さ（このヘッダより小さい全応答の長さ）
応答命令は、共通のヘッダ部及び命令特有の部分を有してもよい。
【００２９】
共通のヘッダ部は、例えば以下の形式からなる。
【００３０】
−３２ビットの命令ＩＤ
−３２ビットの要求ステータス
−３２ビットの長さ（このヘッダより小さな命令応答の長さ）
プロトコル命令の例として、命令特有の応答ヘッダと要求されたデータは以下のものであってよい。
【００３１】
・ストレートＣ１２．１８パススルー
テーブル読込
−１６ビットのテーブルＩＤ
−１６ビットのパディング
−Ｃ１２．１９テーブルデータ
テーブルオフセット読込
−１６ビットのテーブルＩＤ
−１６ビットの長さ
−３２ビットのオフセット
−Ｃ１２．１９テーブルデータ
・読込レジスタ
−Ｃ１２．１９テーブルデータ（ｓｔｄ２３）
・前回の活動レジスタ読込
−３２ビットの要求されたタイムスタンプ（ＵＮＩＸ（登録商標）  ＧＭＴ）
−Ｃ１２．１９テーブルデータ（ｓｔｄ２４）
・前回のレジスタ読込要求
−３２ビットの要求されたタイムスタンプ（ＵＮＩＸ（登録商標）  ＧＭＴ）
−Ｃ１２．１９テーブルデータ（ｓｔｄ２５）
・自己読込レジスタ読込
−３２ビットの要求された開始シーケンス＃
−３２ビットの自己読込レコードカウント
−Ｃ１２．１９テーブルデータ（ｓｔｄ２６）
・ロードプロファイル読込
−３２ビットの要求された開始ブロック＃
−３２ビットの要求された開始シーケンス＃
−３２ビットの要求された終了ブロック＃
−３２ビットの要求された終了シーケンス＃
−３２ビットブロック＃
−Ｃ１２．１９テーブルデータ（ｓｔｄ６４／ブロックヘッダ）
−３２ビットの開始シーケンス＃
−３２ビットの終了シーケンス＃
−３２ビットの長さ
−Ｃ１２．１９テーブルデータ（ｓｔｄ６４／ロードプロファイルデータ）
（この部分は、要求を満たすために必要なだけ繰り返される）
・イベントログのロード
−３２ビットの開始シーケンス＃
−３２ビットの終了シーケンス＃
−３２ビットのイベントログレコードカウント
−Ｃ１２．１９テーブルデータ
＜“再読込（Ｒｅａｄ  Ａｎｅｗ）”命令＞
この時点に至るまでの読込命令は、データシーケンスにおける開始番号および終了番号を区別する２〜３のパラメータの組を用いてもよい。事務管理部門システムは、時間と共に、データセット中の全ての標本を集約してよい。これは、好ましくは、前回の読込が発生した時間から利用できる最新の時系列データを得るためにメータを繰り返して読み込むことによってなされる。反復における各読込に対して、最後の読込シーケンス番号の知識は、新たなデータに対する読込要求を構成するために続いて用いられる。事務管理部門システムが、最後の読込シーケンス番号を保持しなければならないことを解消する最適化は、ＮＩＣにおける全ての前回の“再読込”命令から最後の読込シーケンス番号を格納することを含む。事務管理部門システムは、続いて、全ての新たなデータを取得するために“再読込”命令を発行するのみであってよい。この読込命令は、メータにおける全ての時間ベースの収入データを扱うことができる。“再読込”要求は、命令特有の入力パラメータを用いない。特定の順番でない場合に、応答は、ランレングス符号化されたセクションの順番となる。この命令は、新たなデータを取得するのために用いられるため、全ての特定ＴＬＶは、応答から省略できる。各セクションは、データのタイプや、ヘッダの直後に続くデータ部の長さを示すヘッダを有してよい。
【００３２】
各ＴＬＶ（タイプ、長さ、値）は以下で述べられる。
【００３３】
・前回の活動レジスタ
−３２ビットのタイプ
−３２ビットの長さ
−３２ビットの前回の活動レジスタ読込時間
−Ｃ１２．１９テーブルデータ
・前回の要求レジスタ
−３２ビットのタイプ
−３２ビットの長さ
−３２ビットの前回の要求レジスタ読込時間
−Ｃ１２．１９テーブルデータ
・自己読込レジスタ
−３２ビットのタイプ
−３２ビットの長さ
−自己読込レコードカウント
−Ｃ１２．１９テーブルデータ
・ロードプロファイル
−３２ビットのタイプ
−３２ビットの長さ
−３２ビットのブロックカウント
−３２ビット開始ブロック＃
−３２ビット開始シーケンス＃
−３２ビット終了ブロック＃
−３２ビット終了シーケンス＃
−３２ビットブロック＃
−Ｃ１２．１９テーブルデータ（ｓｔｄ６４／ブロックヘッダ）
−３２ビット開始シーケンス＃
−３２ビット終了シーケンス＃
−３２ビット長さ
−Ｃ１２．１９テーブルデータ（ｓｔｄ６４／ロードプロファイルデータ）
（データのより遅いグループ化は、全ての新たな読込データを取得するために必要なだけ繰り返される）
・イベントログ
−３２ビットのタイプ
−３２ビットの長さ
−３２ビットイベントログレコードカウント
−Ｃ１２．１９テーブルデータ
当業者にとって、開示された発明の方法が、連続したネットワークセッションの維持を要求するデータ収集方法及びプロトコルの他の形式に適用可能であることは明確である。データ収集プロキシは（好ましい実施形態としてはＮＩＣである）、サーバとより上位レベルプロトコル通信をできる機能を備えることができ、この好ましい実施形態は電気メータである場合に、データソースとＣ１２．１８プロトコルに基準とするセッションを行う能力を保持することもできる。
【００３４】
ここで示された実施形態は、現下の好ましい実施形態を示すために、サブシステムや機能性を組み合わせる。代わりの実施形態は、より小さいもしくは追加のサブシステム、処理、もしくは機能的特性を含んでもよく、もしくは、要求された実装に依存する他のサブシステム、処理、機能的特性を用いられてもよい。本願発明の様々な特徴や利点は、以下のクレームにて説明される。
【図１】
2010534029.tif 000003
【図２】
2010534029.tif 000004
【図３】
2010534029.tif 000005
【図４】
2010534029.tif 000006
【国際調査報告】
2010534029.tif 000007
2010534029.tif 000008
2010534029.tif 000009