(57)【要約】      （修正有）【課題】デマンドレスポンス要求に関する時刻を証明する情報処理装置及び通信装置を提供する。【解決手段】第１のデマンドレスポンス要求を第１の通信装置から受信し、第２のデマンドレスポンス要求を第１の通信装置から受信する通信部と、第１のデマンドレスポンス要求から、要求の内容を表す情報を生成する生成部と、第１のデマンドレスポンス要求に対して時刻認証局が発行した時刻を含む第１の時刻証明情報を取得する時刻証明情報取得部と、第１のデマンドレスポンス要求に関連づけて第１の時刻証明情報を記憶装置に記憶させる記憶処理部と、第２のデマンドレスポンス要求が通信部により受信された場合、第１のデマンドレスポンス要求の再送か否かを判定する判定部と、再送であると判定された場合、第２のデマンドレスポンス要求と、記憶装置に記憶された第１の時刻証明情報とを、通信部から第２の通信装置へ送信させる制御部と、を備える。【選択図】図３
2016046724.tif 000002
【特許請求の範囲】
【請求項１】
第１のデマンドレスポンス要求を第１の通信装置から受信し、前記第１のデマンドレスポンス要求の受信後に、第２のデマンドレスポンス要求を前記第１の通信装置から受信する通信部と、
前記第１のデマンドレスポンス要求から、前記第１のデマンドレスポンス要求の内容を表す第１の要求内容情報を生成する生成部と、
前記第１の要求内容情報を時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第１のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第１の時刻証明情報を取得する時刻証明情報取得部と、
前記第１のデマンドレスポンス要求に関連づけて前記第１の時刻証明情報を記憶装置に記憶させるための処理を実行する記憶処理部と、
前記第２のデマンドレスポンス要求が前記通信部により受信された場合、前記第２のデマンドレスポンス要求が前記第１のデマンドレスポンス要求の再送であるか否かを判定する判定部と、
前記判定部により再送であると判定された場合、前記第２のデマンドレスポンス要求と、前記記憶装置において前記第１のデマンドレスポンス要求に関連づけられた前記第１の時刻証明情報とを、前記通信部から第２の通信装置へ送信させる制御部と、
を備える情報処理装置。
【請求項２】
前記生成部は、前記第２のデマンドレスポンス要求から、前記第２のデマンドレスポンス要求の内容を表す第２の要求内容情報を生成し、
前記時刻証明情報取得部は、前記第２の要求内容情報を前記時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第２のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第２の時刻証明情報を取得し、
前記判定部により再送でないと判定された場合、前記制御部は、前記時刻証明情報取得部が取得した第２の時刻証明情報と前記第２のデマンドレスポンス要求とを、前記通信部から前記第２の通信装置へ送信させる
請求項１に記載の情報処理装置。
【請求項３】
前記第１の時刻証明情報は、前記第１のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含むに加えて、前記第１の要求内容情報の値も含む
請求項１または２に記載の情報処理装置。
【請求項４】
前記第１の時刻証明情報は、前記第１の要求内容情報の値と前記第１のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻とを含む情報が、前記時刻認証局によって暗号化された情報である
請求項３に記載の情報処理装置。
【請求項５】
前記第２の時刻証明情報は、前記第２のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻に加えて、前記第２の要求内容情報の値も含む
請求項２に記載の情報処理装置。
【請求項６】
前記第２の時刻証明情報は、前記第２の要求内容情報の値と前記第２のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻とを含む情報が、前記時刻認証局によって暗号化された情報である
請求項５に記載の情報処理装置。
【請求項７】
前記時刻認証局による暗号化は、公開鍵暗号方式の秘密鍵を用いた暗号化である
請求項４または６に記載の情報処理装置。
【請求項８】
前記記憶処理部は、前記第１のデマンドレスポンス要求が前記通信部により受信された場合、前記第１の要求内容情報と前記第１の時刻証明情報とを関連づけて、記憶装置に記憶させ、
前記第２のデマンドレスポンス要求が前記通信部により受信された場合、前記生成部は、前記第２のデマンドレスポンス要求から、前記第２のデマンドレスポンス要求を識別する第２の要求内容情報を生成し、
前記判定部は、前記第２の要求内容情報と同じ要求内容情報が、前記記憶装置に記憶されているか否か判定することにより、前記第２のデマンドレスポンス要求が前記第１のデマンドレスポンス要求の再送であるか否かを判定し、
前記第２の要求内容情報と同じ要求内容情報が前記記憶装置に記憶されていると前記判定部により判定された場合、前記制御部は、前記第２の要求内容情報と同じ要求内容情報に対応する前記第１の時刻証明情報を前記記憶装置から読み出し、読み出した前記第１の時刻証明情報を、前記通信部から前記第２の通信装置へ送信させる
請求項１から７のいずれか一項に記載の情報処理装置。
【請求項９】
前記記憶処理部は、前記第１のデマンドレスポンス要求が前記通信部により受信された場合、前記第１の通信装置が前記第１の要求内容情報と前記第１の時刻証明情報とを関連づけて前記記憶装置に記憶させるために、前記第１の要求内容情報と第１の時刻証明情報とを前記第１の通信装置へ送信し、
前記判定部は、前記通信部が受信した前記第２のデマンドレスポンス要求に前記第１の時刻証明情報が付加されているか否か判定することにより、前記第２のデマンドレスポンス要求が前記第１のデマンドレスポンス要求の再送であるか否かを判定し、
前記第２のデマンドレスポンス要求に前記第１の時刻証明情報が付加されている場合、前記制御部は、前記付加されている前記第１の時刻証明情報を、前記通信部から前記第２の通信装置へ送信させる
請求項１から７のいずれか一項に記載の情報処理装置。
【請求項１０】
前記生成部は、前記第２のデマンドレスポンス要求が前記通信部により受信された場合、前記第２のデマンドレスポンス要求から、前記第２のデマンドレスポンス要求を識別する第２の要求内容情報を抽出し、
前記付加されている前記第１の時刻証明情報と、前記第２の要求内容情報とを用いて、前記第１の時刻証明情報が正しいか否か検証する検証部を更に備える
請求項９に記載の情報処理装置。
【請求項１１】
前記検証部は、前記付加されている前記第１の時刻証明情報を前記時刻認証局から配布された公開鍵で復号し、復号した値と、前記第２の要求内容情報とを比較することにより、前記第１の時刻証明情報が正しいか否か検証する
請求項１０に記載の情報処理装置。
【請求項１２】
前記第２のデマンドレスポンス要求が前記通信部により受信された場合、
前記生成部は、前記第２のデマンドレスポンス要求から、前記第２のデマンドレスポンス要求の内容を表す第２の要求内容情報を抽出し、
前記時刻証明情報取得部は、前記第２の要求内容情報を含む信号を前記通信部から時刻認証局へ送信させ、前記第２のデマンドレスポンス要求に対して時刻認証局が発行した時刻を含む第３の時刻証明情報を、前記時刻認証局から取得し、
前記判定部により再送であると判定された場合、前記制御部は、前記第１の時刻証明情報に加えて、前記第３の時刻証明情報を、前記通信部から第２の通信装置へ送信させる
請求項１から１１のいずれか一項に記載の情報処理装置。
【請求項１３】
前記生成部は、
前記第１のデマンドレスポンス要求を定義する第１の定義情報と、前記第２のデマンドレスポンス要求を定義する第２の定義情報を抽出する定義情報抽出部と、
前記第１の定義情報と前記第２の定義情報を整形する整形部と、
前記整形された第１の定義情報のハッシュ値を前記第１の要求内容情報として計算し、前記整形された第２の定義情報のハッシュ値を前記第２の要求内容情報として計算するハッシュ値計算部と、
を備える請求項１から１２のいずれか一項に記載の情報処理装置。
【請求項１４】
前記定義情報抽出部は、デマンドレスポンスのプロトコルに応じて、抽出する情報を変更し、
前記整形部は、デマンドレスポンスのプロトコルに応じて、整形する方法を変更する
請求項１３に記載の情報処理装置。
【請求項１５】
通信装置と通信する通信部と、
第１のデマンドレスポンス要求を前記通信部から前記通信装置へ送信する場合、前記第１のデマンドレスポンス要求から、前記第１のデマンドレスポンス要求の内容を表す第１の要求内容情報を生成する生成部と、
前記第１の要求内容情報を時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第１のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第１の時刻証明情報を取得する時刻証明情報取得部と、
前記第１のデマンドレスポンス要求に関連づけて前記第１の時刻証明情報を記憶装置に記憶させるための処理を実行する記憶処理部と、
前記第１のデマンドレスポンス要求より後に前記通信装置へ送信される第２のデマンドレスポンス要求が前記第１のデマンドレスポンス要求の再送であるか否かを判定する判定部と、
前記判定部により再送であると判定された場合、前記第２のデマンドレスポンス要求と前記記憶装置において前記第１のデマンドレスポンス要求に関連づけられた前記第１の時刻証明情報とを、前記通信部から前記通信装置へ送信させる制御部と、
を有する情報処理装置。
【請求項１６】
デマンドレスポンス要求を情報処理装置へ送信し、この送信に応じて、前記デマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む時刻証明情報を前記情報処理装置から取得する通信部と、
前記通信部が受信した時刻証明情報を記憶装置に記憶させる制御部と、
前記デマンドレスポンス要求の再送を実施すると決定した場合、前記記憶装置に記憶された時刻証明情報を読み出し、前記読み出した時刻証明情報を前記デマンドレスポンス要求とともに、前記通信部から前記他の通信装置へ送信させる再送実施部と、
を備える通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、情報処理装置及び通信装置に関する。
【背景技術】
【０００２】
デマンドレスポンス（Demand Response：ＤＲ)とは、電力供給者が電力消費者に対して、電力消費量を調整するように要求することで、電力の需要と供給のバランスを保つ方法である。以下、電力消費量の調整要求であるデマンドレスポンス要求を、ＤＲ要求と呼ぶ。電力消費者は、ＤＲ要求を受けると、このＤＲ要求の内容に応じて行動する。例えば、ＤＲ要求の内容が「明日の１２：００〜１４：００の電力消費量の削減」の場合は、電力消費者は、明日の１２：００〜１４：００にエアコンを停止するなどの行動を取る。このように、電力消費量の調整が必要な期間のことを、ＤＲ対象期間と呼ぶ。
【０００３】
近年では、ＤＲ要求をインターネットを介して伝える方法（ＤＲプロトコル）が規格化されている。このＤＲプロトコルには、例えば、Open Automated Demand Response（ＯｐｅｎＡＤＲ）がある。ＤＲプロトコルを用いてＤＲを実施する場合、電力供給者は、ＤＲ要求を送信するためのシステムを用意し、電力消費者は、ＤＲ要求を受信するためのシステムを用意する。
【０００４】
デマンドレスポンスを実施する場合、電力供給者（ＤＲ要求の送信者）と電力消費者（ＤＲ要求の受信者）との間で、デマンドレスポンス契約（以下、ＤＲ契約という）を結ぶ。ＤＲ要求の送信時刻に基づいて、そのＤＲ要求の有効または無効が決まる場合、送信時刻は、電力供給者と電力消費者の双方にとって重要となる。ＤＲ要求が無効になれば、電力供給者が事前に作成した電力調整の計画は崩れてしまう。また、ＤＲ要求が無効になれば、電力消費者は、電力消費量の調整を行う必要がなくなる。
【０００５】
このように、ＤＲ要求の有効または無効は、電力供給者と電力消費者の行動に影響を与える。電力消費量の調整という目標に向けて、電力供給者と電力消費者が正しく行動するためには、ＤＲ要求の送信時刻を双方に証明する仕組みが必要である。
【０００６】
通信網に障害が発生してＤＲ要求が電力消費者に到達しなかった場合、ＤＲ要求を再送する。最初にこのＤＲ要求を送信した際の送信時刻（以下、初回送信時刻という）に基づいて、そのＤＲ要求の有効または無効が決まる場合、この初回送信時刻は、電力供給者と電力消費者の双方にとって重要となる。しかしながら、ＤＲ要求を再送する場合、初回送信時刻を証明することが難しいという問題があった。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−７２０４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
そこで本発明の実施形態が解決しようとする課題は、デマンドレスポンス要求を再送する場合であっても、初回のデマンドレスポンス要求に関する時刻を証明することが可能な情報処理装置及び通信装置を提供することである。
【課題を解決するための手段】
【０００９】
一の実施形態によれば、情報処理装置は、第１のデマンドレスポンス要求を第１の通信装置から受信し、前記第１のデマンドレスポンス要求の受信後に、第２のデマンドレスポンス要求を前記第１の通信装置から受信する通信部を備える。情報処理装置は、前記第１のデマンドレスポンス要求から、前記第１のデマンドレスポンス要求の内容を表す第１の要求内容情報を生成する生成部を備える。情報処理装置は、第１の要求内容情報を時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第１のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第１の時刻証明情報を取得する時刻証明情報取得部を備える。情報処理装置は、前記第１のデマンドレスポンス要求に関連づけて前記第１の時刻証明情報を記憶装置に記憶させるための処理を実行する記憶処理部を備える。情報処理装置は、前記第２のデマンドレスポンス要求が前記通信部により受信された場合、前記第２のデマンドレスポンス要求が前記第１のデマンドレスポンス要求の再送であるか否かを判定する判定部を備える。情報処理装置は、前記判定部により再送であると判定された場合、前記第２のデマンドレスポンス要求と、前記記憶装置において前記第１のデマンドレスポンス要求に関連づけられた前記第１の時刻証明情報とを、前記通信部から第２の通信装置へ送信させる制御部を備える。
【図面の簡単な説明】
【００１０】
【図１】第１の実施形態における情報処理システム１０の構成を示す図。
【図２】第１の実施形態におけるＤＲ要求の転送処理の一例を示すシーケンス図。
【図３】第１の実施形態における情報処理システム１０の詳細な構成を示す図。
【図４】ＯｐｅｎＡＤＲのＤＲ要求の一部を示す図。
【図５】記憶装置２５に記録される情報の一例を示す図。
【図６】初回のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理の一例を示すフローチャート。
【図７】初回のＤＲ要求と再送のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理の一例を示すフローチャート。
【図８】ＨＴＴＰヘッダ部に付加されたトークンの一例。
【図９】送信サーバ１がＤＲ要求を送信する処理の一例を示すフローチャート。
【図１０】受信サーバ４がＤＲ要求を受信する処理の一例を示すフローチャート。
【図１１】転送サーバ２がＤＲ応答を転送する処理の流れの一例を示すフローチャート。
【図１２】第３の実施形態におけるＤＲ要求の転送処理の一例を示すシーケンス図。
【図１３】第３の実施形態における情報処理システム１０ｂの構成を示す概略ブロック図。
【図１４】ＤＲ要求の初回送信時刻を証明するための処理の一例を示すフローチャート。
【図１５】ＤＲ要求の初回送信時刻と再送送信時刻の両方を証明するための処理の一例を示すフローチャート。
【図１６】送信サーバ１ｂがＤＲ要求を送信する処理の一例を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１２】
（第１の実施形態）
まず、第１の実施形態について説明する。図１は、第１の実施形態における情報処理システム１０の構成を示す図である。図１に示すように、情報処理システム１０は、送信サーバ（第１の通信装置）１、転送サーバ（情報処理装置）２、時刻認証局３、及び受信サーバ（第２の通信装置）４を備える。
【００１３】
送信サーバ１は、ＤＲ要求を通信網５を介して、転送サーバ２へ送信する。
【００１４】
転送サーバ２は、送信サーバ１から受信したＤＲ要求を通信網５を介して、受信サーバ４へ転送する。
【００１５】
受信サーバ４は、転送サーバ２から通信網５を介して、ＤＲ要求を受信する。
【００１６】
時刻認証局（Time-Stamping Authority：ＴＳＡ）３は、要求に応じてタイムスタンプ（Time Stamp：ＴＳ）を発行する。具体的には例えば、時刻認証局３は、任意のハッシュ値を受信すると、時刻配信局（Time Assessment Authority：ＴＡＡ）から配信された時刻情報に基づき、タイムスタンプを発行する。そして、時刻認証局３は、このタイムスタンプとこのハッシュ値を自身の秘密鍵で暗号化したトークンを生成する。ここで、トークンは、デマンドレスポンス要求に対して時刻認証局３が発行した時刻を含む時刻証明情報の一例である。
【００１７】
信頼できる第３者（Trusted Third Party）である時刻認証局３がタイムスタンプを発行することで、送信サーバ１と受信サーバ４の両方が、このタイムスタンプが正しいことを信頼できる。
【００１８】
以降、ある入力ｍから作成されたハッシュ値のことを、hash(m)と表記する。また、時刻認証局３が、あるハッシュ値hvに対して発行したタイムスタンプのことをts(hv)と表記する。また、あるハッシュ値hvと、タイムスタンプtsから作成されたトークンのことを、token(hv,ts)と表記する。例えば、hv=hash(m)の場合、token(hv,ts)=token(hash(m),ts(hv))=token(hash(m),ts(hash(m)))である。
【００１９】
なお、各サーバは、複数のサーバとネットワークから構成されるシステムであってもよい。また、本実施形態では一例として、情報処理システム１０内の送信サーバは一台であるが、これに限らず、複数台、存在してもよい。
【００２０】
同様に、本実施形態では一例として、情報処理システム１０内の受信サーバは一台であるが、これに限らず、複数台、存在してもよい。例えば、ビルや家などの建物ごとに受信サーバが存在することもありえる。本実施形態では一例として、時刻認証局３と転送サーバ４の間は通信網５で接続されたが、これに限らず、時刻認証局３と転送サーバ４の間は、専用回線で接続されてもよい。
【００２１】
続いて、第１の実施形態におけるＤＲ要求の転送処理の概要について図２を用いて説明する。図２は、第１の実施形態におけるＤＲ要求の転送処理の一例を示すシーケンス図である。
【００２２】
（Ｔ１１）まず、送信サーバ１は、ＤＲ要求を転送サーバ２へ送信する。ここで、このＤＲ要求の送信は、初回の送信である。
【００２３】
（Ｔ２１）次に、転送サーバ２は、ＤＲ要求からこのＤＲ要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第１のハッシュ値を計算する。この整形は、表現の揺らぎ及び情報の登場順序などのフォーマットである。
【００２４】
（Ｔ２２）次に、転送サーバ２は、このＤＲ要求が再送であるか否か判定する。ここでは、このＤＲ要求は再送ではないと判定される。
【００２５】
（Ｔ２３）ＤＲ要求が再送ではないので、転送サーバ２は、Ｔ２１で計算した第１のハッシュ値を時刻認証局３へ送信する。
【００２６】
（Ｔ３１）次に、時刻認証局３は、第１のハッシュ値を転送サーバ２から受信すると、タイムスタンプＴＳ１を発行する。そして、時刻認証局３は、第１のハッシュ値とタイムスタンプＴＳ１に基づいて、このタイムスタンプＴＳ１を証明するトークンを生成する。ここで、トークンは、例えば、第１のハッシュ値とタイムスタンプＴＳ１との組が、公開鍵暗号方式の秘密鍵で暗号化された情報である。
【００２７】
（Ｔ３２）次に、時刻認証局３は、Ｔ３１で生成したトークンを、転送サーバ２へ送信する。
【００２８】
（Ｔ２４）次に、転送サーバ２は、トークンを時刻認証局３から受信すると、第１のハッシュ値と受信したトークンを関連づけて記憶装置に記憶する。
【００２９】
（Ｔ２５）次に、転送サーバ２が、ＤＲ要求とトークンを受信サーバ４へ向けて送信する。しかし、この送信の途中で障害（転送エラー）が発生した場合を想定する。
【００３０】
（Ｔ１２）送信サーバ１は、転送エラーの発生を検出すると、ＤＲ要求を転送サーバ２へ再送する。
【００３１】
（Ｔ２６）次に、転送サーバ２は、再送されたＤＲ要求からこのＤＲ要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第２のハッシュ値を計算する。
【００３２】
（Ｔ２７）次に、転送サーバ２は、このＤＲ要求が再送であるか否か判定する。ここでは、このＤＲ要求が再送であると判定される。
【００３３】
（Ｔ２８）次に、転送サーバ２は、第２のハッシュ値に対応するトークンを記憶装置から読み出す。
【００３４】
（Ｔ２９）次に、転送サーバ２は、ＤＲ要求と読み出したトークンとを受信サーバ４へ送信する。
【００３５】
（Ｔ４１）次に、受信サーバ４は、ＤＲ要求とトークンとを受信すると、受信したＤＲ要求からこのＤＲ要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第３のハッシュ値を計算する。
【００３６】
（Ｔ４２）次に、受信サーバ４は、タイムスタンプＴＳ１が信頼できるか否か判定する。例えば、受信サーバ４は、時刻認証局３から配布された公開鍵でトークンを復号し、復号して得たハッシュ値と、第３のハッシュ値とが一致するか否か判定する。ここで、この公開鍵は、時刻認証局３でトークンを暗号化されるときに用いられる秘密鍵と対になるものである。復号して得られたハッシュ値と第３のハッシュ値とが一致する場合、受信サーバ４は、トークンを復号して得られたタイムスタンプＴＳ１を信頼できる。
【００３７】
（Ｔ４３）次に、受信サーバ４は、タイムスタンプＴＳ１を用いて、ＤＲ要求の有効／無効を判断する。以上で、本シーケンスの処理を終了する。
【００３８】
このように、ＤＲ要求を再送する場合であっても、受信サーバ４は、ＤＲ要求の初回送信時刻であるタイムスタンプＴＳ１を取得することができる。
【００３９】
続いて、図３を用いて、転送サーバ２の構成について説明する。図３は、第１の実施形態における情報処理システム１０の詳細な構成を示す図である。
【００４０】
図３に示すように、転送サーバ２は、通信部２１、生成部２２、時刻証明情報取得部２３、記憶処理部２４、記憶装置２５、判定部２６、及び制御部２７を備える。
【００４１】
通信部２１は、通信網５を介して、送信サーバ１、時刻認証局３、及び受信サーバ４と通信する。例えば、通信部２１は、第１のデマンドレスポンス要求を送信サーバ１から受信し、第１のデマンドレスポンス要求の受信後に、第２のデマンドレスポンス要求を送信サーバ１から受信する。
【００４２】
生成部２２は、デマンドレスポンス要求から、このデマンドレスポンス要求の内容を表す要求内容情報を生成する。ここで、本実施形態では、要求内容情報は、一例として、整形後の定義情報のハッシュ値である。なお、要求内容情報は、ＤＲ対象時刻と省エネ量の組などのＤＲ要求の内容を規定する情報であってもよく、ＤＲ要求の内容を規定できればどんな情報であってもよい。
【００４３】
例えば、生成部２２は、第１のデマンドレスポンス要求（例えば、図２の初回のＤＲ要求）から、第１のデマンドレスポンス要求の内容を表す第１の要求内容情報 （例えば、図２の第１のハッシュ値）を生成する。また、例えば、生成部２２は、第２のデマンドレスポンス要求（例えば、図２の再送のＤＲ要求を送信要求）が通信部２１により受信された場合、第２のデマンドレスポンス要求から、第２のデマンドレスポンス要求の内容を表す第２の要求内容情報（例えば、図２の第２のハッシュ値）を生成する。
【００４４】
ここで、生成部２２は、定義情報抽出部２２１、整形部２２２、及びハッシュ値計算部２２３を備える。
【００４５】
定義情報抽出部２２１は、通信部２１が受信したＤＲ要求から、ＤＲ要求を定義する情報の集まりである定義情報を抽出する。このことから、定義情報抽出部２２１は、例えば、通信部２１が第１のデマンドレスポンス要求を受信した場合、第１のデマンドレスポンス要求を定義する第１の定義情報を抽出する。同様に、定義情報抽出部２２１は、例えば、通信部２１が第２のデマンドレスポンス要求を受信した場合、第２のデマンドレスポンス要求を定義する第２の定義情報を抽出する。
【００４６】
例えば、定義情報は、送信元の送信サーバを識別する送信サーバＩＤ、宛先の受信サーバを識別する受信サーバＩＤ、ＤＲ種類、ＤＲ対象期間、電力調整量（例えば、電気料金、電力消費量の削減目標値など）を含む。これらの情報は、初回送信時と再送時で変化しない。もしこれらの情報が変化したら、それは再送ではない。定義情報の具体的な内容は、ＤＲプロトコルによって決まる。
【００４７】
ＤＲ要求に含まれており、かつ、定義情報に含まれない情報には、例えば、メッセージＩＤ及びメッセージ作成時刻がある。これらの情報は、初回送信時と再送時で変化する。
【００４８】
図４は、ＯｐｅｎＡＤＲのＤＲ要求の一部を示す図である。図４内の情報の中で、requestIDやcreatedDateTimeは、送信のたびに変化する情報であり、定義情報に含まれない。逆に、それ以外の情報は、定義情報に含まれる。
【００４９】
デマンドレスポンスのプロトコル（ＤＲプロトコル）によって、定義情報は異なる。そのため例えば、送信元のＤＲ送信サーバＩＤを含むＤＲプロトコルと、含まないＤＲプロトコルが存在する。複数のＤＲプロトコルに対応するためには、ＤＲプロトコル毎に、定義情報として抽出すべき情報を定義しておけばよい。そして、定義情報抽出部２２１は、ＤＲプロトコルに応じて、抽出する情報を変更してもよい。これにより、定義情報抽出部２２１は、ＤＲプロトコルに応じた抽出処理を行うことができる。
【００５０】
図３において、整形部２２２は、定義情報抽出部２２１が抽出した定義情報を整形する。例えば、整形部２２２は、定義情報抽出部２２１が第１の定義情報を抽出した場合、この第１の定義情報を整形する。また、例えば、整形部２２２は、定義情報抽出部２２１が第２の定義情報を抽出した場合、この第２の定義情報を整形する。具体的な整形の内容は、ＤＲプロトコルによって決まる。以下に、整形処理の一例を示す。整形処理には、定義情報の整列がある。整列の基準は、様々である。例えば、アルファベット順、または五十音順などがある。また整形処理には、定義情報内の改行の削除、及び／または不要な空白の削除がある。
【００５１】
ＤＲプロトコルによって、整形の方法は異なる。例えば、情報の改行を許可するＤＲプロトコルと、許可しないＤＲプロトコルが存在する。ＤＲプロトコルが改行を許可していなければ、整形部２２２が、改めて改行を削除する必要はない。複数のＤＲプロトコルに対応するためには、ＤＲプロトコルごとに、行うべき整形処理を定義しておけばよい。そして、整形部２２２は、ＤＲプロトコルに応じて、整形する方法を変更する。これにより、整形部２２２は、ＤＲプロトコルに応じた整形処理を行うことができる。以降、定義情報抽出部２２１の処理及び整形部２２２の処理の両方が済んだＤＲ要求のことを、format(DR要求)と表記する。
【００５２】
ハッシュ値計算部２２３は、ＤＲ要求、または整形部２２２により整形された定義情報を入力として、ハッシュ値を計算する。例えば、ハッシュ値計算部２２３は、整形された第１の定義情報のハッシュ値を第１の要求内容情報として計算し、整形された第２の定義情報のハッシュ値を第２の要求内容情報として計算する。ハッシュアルゴリズムはＭＤ５やＳＨＡ１やＳＨＡ２などがある。ハッシュ値を計算する前に、定義情報が抽出され、この定義情報が整形されることで、初回送信時のＤＲ要求から計算されるハッシュ値と、再送時のＤＲ要求から計算されるハッシュ値が等しくなる。
【００５３】
時刻証明情報取得部２３は、整形後の定義情報から計算されたハッシュ値を使い、記憶装置２５または時刻認証局３から、トークンを取得する。判定部２６が再送だと判定した場合、ハッシュ値に対応するトークン(初回送信時に取得され記録されたトークン)が記憶装置に記録されているはずなので、記憶装置からトークンを取得する。一方、判定部２６が再送ではないと判定した場合(初回送信の場合)は、時刻証明情報取得部２３は、ハッシュ値を時刻認証局３に送り、時刻認証局３にトークンを作成してもらい、時刻認証局３からトークンを取得する。記憶処理部２４は、時刻認証局３からからトークンを取得した場合、ハッシュ値とトークンとを関連づけて、記憶装置に記録する。
【００５４】
例えば、時刻証明情報取得部２３は、第１の要求内容情報（例えば、図２の第１のハッシュ値）を時刻認証局３へ送信し、この送信に応じて時刻認証局３から送信された、第１のデマンドレスポンス要求に対して時刻認証局３が発行した時刻を含む第１の時刻証明情報（例えば、図２のトークン）を時刻認証局３から取得する。
【００５５】
本実施形態では、第１の時刻証明情報は、一例として、第１のデマンドレスポンス要求に対して時刻認証局３が発行した時刻に加えて、第１の要求内容情報の値も含む。具体的な一例として、第１の時刻証明情報は、第１の要求内容情報の値と第１のデマンドレスポンス要求に対して時刻認証局３が発行した時刻とを含む情報が、時刻認証局３によって暗号化された情報である。ここで、時刻認証局３による暗号化は、公開鍵暗号方式の秘密鍵を用いた暗号化である。
【００５６】
また、時刻証明情報取得部２３は、第２の要求内容情報を時刻認証局３へ送信し、この送信に応じて時刻認証局３から送信された、第２のデマンドレスポンス要求に対して時刻認証局３が発行した時刻第２の時刻証明情報を時刻認証局３から取得する。この取得は、例えば、判定部２６により、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送でないと判定された場合に行われる。
【００５７】
本実施形態において、第２の時刻証明情報は、一例として、第２のデマンドレスポンス要求に対して時刻認証局３が発行した時刻に加えて、第２の要求内容情報の値も含む。具体的な一例として、第２の時刻証明情報は、第２の要求内容情報の値と第２のデマンドレスポンス要求を前記時刻認証局３が発行した時刻とを含む情報が、時刻認証局３によって暗号化された情報である。
【００５８】
記憶処理部２４は、第１のデマンドレスポンス要求に関連づけて第１の時刻証明情報（例えば、図２のトークン）を記憶装置２５に記憶させるための処理を実行する。具体的には例えば、記憶処理部２４は、第１のデマンドレスポンス要求が通信部２１により受信された場合、第１の要求内容情報（例えば、図２の第１のハッシュ値）と第１の時刻証明情報（例えば、図２のトークン）とを関連づけて、記憶装置２５に記憶させる。
【００５９】
ここで、複数の送信サーバや受信サーバが存在する場合を考慮して、例えば、送信サーバを識別する送信サーバＩＤと受信サーバを識別する受信サーバＩＤも合わせて記憶される。送信サーバＩＤは、送信サーバ毎に固有の値であり、受信サーバＩＤは、受信サーバ毎に固有の値である。また、有効期限も合わせて記憶されてもよい。記憶処理部２４は、有効期限が切れた情報を削除する。これにより、記憶する情報が増え続けることを避けられる。有効期限の決め方は様々である。例えば、ＤＲ要求にて指定されるＤＲ対象期間の終了時刻を、有効期限としてもよい。
【００６０】
図５は、記憶装置２５に記録される情報の一例を示す図である。図５のテーブルＴ１において、送信サーバＩＤ、受信サーバＩＤ、ハッシュ値、トークン、有効期限の組が示されている。例えば、送信サーバＩＤが「send.server1」で、受信サーバＩＤが「recv.server1」で、ハッシュ値が「38a7d9f87e1」で、トークンが「x93hpc」で、有効期限が「2014-04-02T16:00:00」である。
【００６１】
図３において、判定部２６は、通信部２１が受信したＤＲ要求が、再送されたものであるか否か判定する。例えば、判定部２６は、第２のデマンドレスポンス要求（例えば、図２の再送のＤＲ要求）が通信部２１により受信された場合、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送であるか否かを判定する。
【００６２】
具体的には例えば、判定部２６は、第２の要求内容情報（例えば、図２のハッシュ値）と同じ要求内容情報（例えば、ハッシュ値）が、記憶装置２５に記憶されているか否か判定することにより、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送であるか否かを判定する。判定部２６は、第２の要求内容情報（例えば、図２のハッシュ値）と同じ要求内容情報（例えば、ハッシュ値）が、記憶装置２５に記憶されていれば、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送であると判定する。
【００６３】
このように、定義情報が抽出され、この定義情報が整形されることで、初回送信時のハッシュ値hash(format(初回送信時のDR要求))と再送時のハッシュ値hash(format(再送時のDR要求))とが等しくなるため、このような再送判定が可能となる。
【００６４】
本実施形態では、以下の事項を考慮して、判定部２６の再送判定にハッシュ値を使うものとして説明する。まず、元データの大きさによらず、ハッシュ値は固定長さとなるため、ハッシュ値を使うと記憶に必要な容量や、比較に必要な計算量が少なくなるという利点がある。また、時刻認証局３からトークンを取得するためにハッシュ値を計算するので、余計な計算を増やすことにはならないという利点がある。
【００６５】
なお、判定部２６は、ハッシュ値の代わりに、ハッシュ値の元データ、すなわち整形後の定義情報同士を比較して、再送判定してもよい。また、判定部２６は、ハッシュ値の代わりに、ＤＲ要求同士を比較して、再送判定してもよい。
【００６６】
制御部２７は、判定部２６により再送であると判定された場合、第２のデマンドレスポンス要求と記憶装置２５に記憶された第１の時刻証明情報とを、通信部２１から受信サーバ４へ送信させる。具体的には例えば、第２の要求内容情報が記憶装置２５に記憶されていると判定部２６により判定された場合、制御部２７は、第２の要求内容情報と同じ要求内容情報に対応する第１の時刻証明情報を記憶装置２５から読み出し、読み出した第１の時刻証明情報を、通信部２１から受信サーバ４へ送信させる。
【００６７】
一方、判定部２６により再送でないと判定された場合、制御部２７は、時刻証明情報取得部２３が取得した第２の時刻証明情報と第２のデマンドレスポンス要求とを、通信部２１から受信サーバ４へ送信させる。
【００６８】
ここで、制御部２７は、トークン付加部２７１を備える。トークン付加部２７１は、例えば、ＨＴＴＰリクエストまたはＨＴＴＰレスポンスにトークンを付加する。例えば、トークン付加部２７１は、判定部２６により再送であると判定された場合、ＤＲ要求と第１の時刻証明情報とをＨＴＴＰリクエストに付加する。そして、制御部２７は、付加後のＨＴＴＰリクエストを、通信部２１から受信サーバ４へ送信させる。一方、判定部２６により再送でないと判定された場合、トークン付加部２７１は、ＤＲ要求と第２の時刻証明情報とをＨＴＴＰリクエストに付加する。そして、制御部は、付加後のＨＴＴＰリクエストを、通信部２１から受信サーバ４へ送信させる。ここで、具体的なトークンの付加方法は、ＤＲプロトコルによって決定される。
【００６９】
続いて、図３を用いて、送信サーバ１の構成について説明する。図３に示すように、送信サーバ１は、通信部１１、ＤＲ要求記憶部１２、再送実施部１３、生成部１４、送信時刻確認部１５、及び制御部１６を備える。
【００７０】
通信部１１は、通信網５を介して転送サーバ２と通信する。
【００７１】
ＤＲ要求記憶部１２は、受信サーバ４に送信するＤＲ要求を記憶する。
【００７２】
再送実施部１３は、再送条件を満たす場合、ＤＲ要求の再送処理を行う。再送条件は、例えば、一定時間が経過しても、転送サーバからＨＴＴＰ（Hypertext Transfer Protocol）レスポンスが返されない場合や、一定時間が経過しても、ＤＲ転送サーバからXMPP（Extensible Messaging and Presence Protocol）のIQ resultが返されない場合や、またはＤＲ要求に対するＤＲ応答が転送されてこない場合である。
【００７３】
生成部１４は、転送サーバ２の生成部２と同様に、デマンドレスポンス要求から、このデマンドレスポンス要求を識別する要求内容情報を生成する。ここで、生成部１４は、定義情報抽出部１４１、整形部１４２、及びハッシュ値計算部１４３を備える。
【００７４】
定義情報抽出部１４１は、転送サーバ２の定義情報抽出部２２１と同様に、通信部１１が受信したＤＲ要求から、ＤＲ要求を定義する情報の集まりである定義情報を抽出する。
【００７５】
整形部１４２は、転送サーバ２の整形部２２２と同様に、定義情報抽出部１４１が抽出した定義情報を整形する。
【００７６】
ハッシュ値計算部１４３は、転送サーバ２のハッシュ値計算部２２３と同様に、ＤＲ要求、または整形部１４２により整形された定義情報を入力として、ハッシュ値を計算する。
【００７７】
送信時刻確認部１５は、送信したＤＲ要求に対して発行されたタイムスタンプを取得する。具体的には、送信時刻確認部１５は、このＤＲ要求について時刻認証局３により発行されたトークンを転送サーバ２から取得し、取得したトークンを時刻認証局３から予め配布された公開鍵で復号することにより、タイムスタンプを取得する。
【００７８】
そして、送信時刻確認部１５は、ＤＲ契約の規定に基づき、ＤＲ要求の有効／無効を判断する。例えば、送信時刻確認部１５は、ＤＲ要求に対して時刻認証局３が発行した時刻がＤＲ対象期間の開始時刻より所定の時間以上前であれば、有効とし、所定の時間未満であれば、無効とする。なお、ＤＲ要求が無効になった場合、送信時刻確認部１５は、別のＤＲ要求を送信するなどの対策を取ってもよい。
【００７９】
制御部１６は、通信部１１の通信、及びＤＲ要求記憶部１２への読み書きを制御する。
【００８０】
続いて、図３を用いて、受信サーバ４の構成について説明する。図３に示すように、受信サーバ４は、通信部４１、制御実施部４２、生成部４３、及び送信時刻確認部４４を備える。
【００８１】
通信部４１は、通信網５を介して転送サーバ４と通信する。
【００８２】
制御実施部４２は、通信部４１が受信したＤＲ要求に基づいて、機器(例えば、エアコンなど)の制御を行う。
【００８３】
生成部４３は、転送サーバ２の生成部２と同様に、デマンドレスポンス要求から、このデマンドレスポンス要求を識別する要求内容情報を生成する。ここで、生成部４３は、定義情報抽出部４３１、整形部４３２、及びハッシュ値計算部４３３を備える。
【００８４】
定義情報抽出部４３１は、転送サーバ２の定義情報抽出部２２１と同様に、通信部４１が受信したＤＲ要求から、ＤＲ要求を定義する情報の集まりである定義情報を抽出する。
【００８５】
整形部４３２は、転送サーバ２の整形部２２２と同様に、定義情報抽出部４３１が抽出した定義情報を整形する。
【００８６】
ハッシュ値計算部４３３は、転送サーバ２のハッシュ値計算部２２３と同様に、ＤＲ要求、または整形部４３２により整形された定義情報を入力として、ハッシュ値を計算する。
【００８７】
送信時刻確認部４４は、送信サーバ１の送信時刻確認部１５と同様に、受信したＤＲ要求に対して発行されたタイムスタンプを取得する。そして、送信時刻確認部４４は、ＤＲ契約の規定に基づき、ＤＲ要求の有効／無効を確認する。ＤＲ要求が有効である場合のみ、制御実施部４２による機器制御を行ってもよい。
【００８８】
＜初回のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理例＞
続いて、図６を用いて、初回のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理を説明する。図６は、初回のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理の一例を示すフローチャートである。
【００８９】
（ステップＳ１０１）まず、制御部２７は、通信部２１がＤＲ要求を受信したか否か判定する。通信部２１がＤＲ要求を受信していない場合、制御部２７はそのまま待機する。
【００９０】
（ステップＳ１０２）ステップＳ１０１で通信部２１がＤＲ要求を受信した場合、定義情報抽出部２２１は、通信部２１が受信したＤＲ要求から定義情報を抽出する。
【００９１】
（ステップＳ１０３）次に、整形部２２２は、ステップＳ１０２で抽出された定義情報を整形する。これにより、format(DR要求)が生成される。
【００９２】
（ステップＳ１０４）次に、ハッシュ値計算部２２３は、整形後の定義情報のハッシュ値を計算する。これにより、hash(format(DR要求))が得られる。
【００９３】
（ステップＳ１０５）次に、判定部２６は、ステップＳ１０４で計算されたハッシュ値と同じハッシュ値が記憶装置２５に保存されているか否か判定する。具体的には、判定部２６は、送信サーバＩＤと、受信サーバＩＤと、ハッシュ値hash(format(DR要求))の三つが一致する情報が記憶装置２５に保存されているか否か判定する。三つが一致する情報が記憶装置２５に保存されていれば、再送であるので、処理がステップＳ１０６に進む。一方、三つが一致する情報が記憶装置２５に保存されていなかれば、再送でないので、処理がステップＳ１０７に進む。ここで、送信サーバＩＤと、受信サーバＩＤは、ＤＲ要求内に指定されているＩＤを使ってもよいし、ＩＰアドレスやＨＴＴＰのＵＲＬを使ってもよい。
【００９４】
（ステップＳ１０６）ステップＳ１０５で、計算されたハッシュ値と同じハッシュ値が記憶装置２５内に保存されていると判定された場合、ステップＳ１０１で受信されたＤＲ要求は再送であるので、制御部２７は、記憶装置２５からステップＳ１０４で計算されたハッシュ値に対応するトークンを読み出す。このトークンは、「初回送信時刻」の証明に使用する。その後、処理がステップＳ１１０に進む。
【００９５】
（ステップＳ１０７）ステップＳ１０５で、計算されたハッシュ値と同じハッシュ値が記憶装置２５内に保存されていないと判定された場合、ステップＳ１０１で受信されたＤＲ要求は初回の送信であるので、制御部２７は、ステップＳ１０４で計算されたハッシュ値を、通信部２１から時刻認証局３へ送信する。
【００９６】
（ステップＳ１０８）次に、通信部２１は、時刻認証局３からトークンを受信する。このトークンも同様に、「初回送信時刻」の証明に使用する。
【００９７】
（ステップＳ１０９）次に、記憶処理部２４は、ステップＳ１０４で計算されたハッシュ値と、ステップＳ１０８で受信されたトークンとを関連づけて記憶装置２５に保存する。その後、処理がステップＳ１１０に進む。
【００９８】
（ステップＳ１１０）次に、制御部２７は、ステップＳ１０６またはステップＳ１０８で取得されたトークンと、ステップＳ１０１で受信されたＤＲ要求とを受信サーバ４へ送信する。その後、処理がステップＳ１０１に戻る。
【００９９】
以上、第１の実施形態に係る転送サーバ２は、第１のデマンドレスポンス要求と第２のデマンドレスポンス要求を送信サーバ１から受信する通信部２１を備える。転送サーバ２は、第１のデマンドレスポンス要求から、第１のデマンドレスポンス要求の内容を表す第１の要求内容情報を生成する生成部２２を備える。転送サーバ２は、第１の要求内容情報を時刻認証局３へ送信し、この送信に応じて時刻認証局３から送信された、第１のデマンドレスポンス要求に対して時刻認証局３が発行した時刻を含む第１の時刻証明情報を取得する時刻証明情報取得部を備える。転送サーバ２は、第１の要求内容情報と第１の時刻証明情報とを関連づけて記憶装置２５に記憶させるための処理を実行する記憶処理部２４を備える。転送サーバ２は、第２のデマンドレスポンス要求が通信部２１により受信された場合、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送であるか否かを判定する判定部２６を備える。転送サーバ２は、判定部２６により再送であると判定された場合、第２のデマンドレスポンス要求と記憶装置２５に記憶された第１の時刻証明情報とを、通信部２１から受信サーバ４へ送信させる制御部２７を備える。
【０１００】
これにより、転送サーバ２は、再送のＤＲ要求を受信した場合、初回のＤＲ要求に対して時刻認証局３が発行した時刻を含む第１の時刻証明情報を受信サーバ４へ送信することができる。第１の時刻証明情報は時刻認証局３が発行したものであるので、ＤＲ要求を再送する場合であっても、信頼できる初回のＤＲ要求の時刻を受信サーバ４へ提供することができる。
【０１０１】
また、本実施形態に係る転送サーバ２の生成部２２は、受信したＤＲ要求から定義情報を抽出し、抽出した定義情報を整形し、整形後の定義情報のハッシュ値を計算した。これにより、ＤＲ要求の初回送信時とＤＲ要求の再送時とでハッシュ値が同じになるので、ハッシュ値を比較することによって、受信したＤＲ要求が再送であるか否かを判定することができる。
【０１０２】
（第２の実施形態）
続いて、第２の実施形態について説明する。第１の実施形態では、初回のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理例について説明した。それに対し、第２の実施形態では、初回のＤＲ要求と再送のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理例について説明する。なお、第２の実施形態における情報システム１０の構成は、第１の実施形態における情報処理システム１０の構成と同一であるので、その説明を省略する。
【０１０３】
以下、サーバ同士はＨＴＴＰを使って連携するという前提で、各処理を説明する。まず、図７を用いて、転送サーバ２の処理を説明する。図７は、初回のＤＲ要求と再送のＤＲ要求に対して時刻認証局３が発行した時刻を伝送する処理の一例を示すフローチャートである。
【０１０４】
（ステップＳ２０１）制御部２７は、通信部２１がＤＲ要求を受信したか否か判定する。例えば、通信部２１が、ＤＲ要求が付加されたＨＴＴＰリクエストを送信サーバ１から受信した場合、制御部２７は、通信部２１がＤＲ要求を受信したと判定する。
【０１０５】
（ステップＳ２０２）ステップＳ２０１で通信部２１がＤＲ要求を受信した場合、ハッシュ値計算部２２３は、このＤＲ要求のハッシュ値Ａを計算する。これにより、ハッシュ値Ａとしてhash(DR要求)が得られる。
【０１０６】
（ステップＳ２０３）次に、時刻証明情報取得部２３は、ＤＲ要求のハッシュ値Ａに対するトークンａを取得するため、ＤＲ要求のハッシュ値Ａを時刻認証局３へ送信する。
【０１０７】
（ステップＳ２０４）そして、時刻証明情報取得部２３は、トークンａを時刻認証局３から取得する。このトークンａはtoken(hash(DR要求), ts(hash(DR要求)))と表され、「ＤＲ要求の再送時刻」の証明に使用する。
【０１０８】
（ステップＳ２０５）次に、定義情報抽出部２２１は、通信部２１が受信したＤＲ要求から定義情報を抽出する。
【０１０９】
（ステップＳ２０６）次に、整形部２２２は、抽出された定義情報を整形する。これにより、format(DR要求)が生成される。
【０１１０】
（ステップＳ２０７）次に、ハッシュ値計算部２２３は、整形後の定義情報からハッシュ値Ｂを計算する。これにより、ハッシュ値Ｂとして、hash(format(DR要求))が得られる。
【０１１１】
（ステップＳ２０８）次に、判定部２６は、ハッシュ値Ｂと同じハッシュ値の情報が記憶装置２５に保存されているか否か判定する。例えば、判定部２６は、送信サーバＩＤと、受信サーバＩＤと、ハッシュ値Ｂの三つが一致する情報が記憶装置２５に保存されているか否か判定する。この情報が記憶装置２５に保存されていれば、ＤＲ要求は再送であり、この情報が記憶装置２５に保存されていなければ、ＤＲ要求は、初回の送信である。ここで、ＤＲ送信サーバＩＤと、ＤＲ受信サーバＩＤは、ＤＲ要求内に指定されているＩＤを使ってもよいし、ＩＰアドレスやＨＴＴＰのＵＲＬを使ってもよい。
【０１１２】
（ステップＳ２０９）ステップＳ２０８でハッシュ値Ｂと同じハッシュ値の情報が記憶装置２５に保存されていると判定された場合、ＤＲ要求は再送であるので、記憶装置２５から、このハッシュ値Ｂに対応するトークンｃを読み出す。その後、処理がステップＳ２１０に進む。このトークンｃは、ＤＲ要求を初回に受信したときに取得して記憶装置２５に保存されたトークンであり、「初回送信時刻」の証明に使用する。
【０１１３】
（ステップＳ２１０）次に、トークン付加部２７１は、ＨＴＴＰレスポンスにトークンａとトークンｃを付加する。但し、トークン付加部２７１は、トークンａとトークンｃを区別できるように付加する。例えば、ヘッダ部に付加するのであれば、図８に示すように、ヘッダのフィールド名を分ける。
【０１１４】
図８は、ＨＴＴＰヘッダ部に付加されたトークンの一例である。図８の行Ｌ１には、トークンａのフィールド名「X-DR-request-token」と、トークンａの値「HLK241HLPFJS」が示されている。また、その次の行Ｌ２には、トークンｃのフィールド名「X-format-DR-request-token」と、トークンｃの値「QOF893PEKFSD」が示されている。
【０１１５】
（ステップＳ２１１）次に、トークン付加部２７１は、転送用のＨＴＴＰリクエストに、ＤＲ要求、トークンａ、及びトークンｃを付加する。その際、付加する場所は、ＨＴＴＰヘッダ部でもよいし、ＨＴＴＰボディでもよい。但し、トークン付加部２７１は、トークンａとトークンｃを区別できるように付加する。
【０１１６】
（ステップＳ２１２）ステップＳ２０８でハッシュ値Ｂと同じハッシュ値の情報が記憶装置２５に保存されていると判定されていない場合、ＤＲ要求は初回の送信であるので、制御部２７は、通信部２１から時刻認証局３へハッシュ値Ｂを送信する。
【０１１７】
（ステップＳ２１３）次に、通信部２１は、ステップＳ２１２におけるハッシュＢの送信に応じて、時刻認証局３から送信されたトークンｂを受信する。このトークンｂは、token(hash(format(DR要求)), ts(hash(format(DR要求))))と表される。
【０１１８】
（ステップＳ２１４）次に、記憶処理部２４は、ステップＳ２０７で計算されたハッシュ値Ｂと時刻認証局３から得たトークンｂとを関連づけて記憶装置２５に記録する。記憶処理部２４は、送信サーバＩＤと、受信サーバＩＤも、合わせて記憶装置２５に記録する。これにより、ＤＲ要求の再送時に、ハッシュ値Ｂを用いてトークンｂを記憶装置２５から読み出すことができる。
【０１１９】
（ステップＳ２１５）次に、トークン付加部２７１は、ＨＴＴＰレスポンスにトークンａとトークンｂを付加する。その際、付加する場所は、ＨＴＴＰヘッダ部でもよいし、ＨＴＴＰボディでもよい。但し、トークン付加部２７１は、トークンａとトークンｂを区別できるように付加する。例えば、ヘッダ部に付加するのであれば、図８に示すように、ヘッダのフィールド名を分ける。
【０１２０】
（ステップＳ２１６）次に、トークン付加部２７１は、転送用のＨＴＴＰリクエストに、ＤＲ要求、トークンａ、及びトークンｂを付加する。その際、付加する場所は、ＨＴＴＰヘッダ部でもよいし、ＨＴＴＰボディでもよい。但し、トークン付加部２７１は、トークンａとトークンｂを区別できるように付加する。
【０１２１】
（ステップＳ２１７）次に、通信部２１は、トークンが付加されたＨＴＴＰレスポンスを、送信サーバ１に送信する。
【０１２２】
（ステップＳ２１８）次に、通信部２１は、転送用のＨＴＴＰリクエストを、受信サーバ４へ送信する。
【０１２３】
このように、転送サーバ２は、再送のＤＲ要求を受信した場合、この受信したＤＲ要求に対して時刻認証局３が発行したトークンａを取得し、ＤＲ要求の初回送信時に時刻認証局３が発行したトークンｃを取得する。ここで、トークンａには、時刻認証局３が発行した再送時刻が含まれ、トークンｃには、時刻認証局３が発行した初回送信時刻が含まれている。そして、転送サーバ２は、取得したトークンａとトークンｃを送信サーバ１と受信サーバ４へ送信する。これにより、送信サーバ１と受信サーバ４は、時刻認証局３が発行した初回送信時刻及び再送時刻を取得することができる。
【０１２４】
続いて、送信サーバ１がＤＲ要求を送信する処理について図９を用いて説明する。図９は、送信サーバ１がＤＲ要求を送信する処理の一例を示すフローチャートである。
【０１２５】
（ステップＳ３０１）まず、送信サーバ１は、ＤＲ要求を登録する。具体的には、ＤＲ要求記憶部１２は、登録対象のＤＲ要求を記憶する。ＤＲ要求の登録方法は、運用者がＤＲ要求の登録を送信サーバ１に指示する方法や、送信サーバ１内のプログラムが自動的に登録する方法がある。
【０１２６】
（ステップＳ３０２）ステップＳ３０１でＤＲ要求が登録されたら、制御部１６は、ＨＴＴＰリクエストに、ＤＲ要求記憶部１２に記録されたＤＲ要求を付加する。付加する場所は、ＨＴＴＰリクエストのヘッダ部でもよいし、ボディ部でもよい。そして、通信部１１は、転送サーバ２に、ＤＲ要求が付加されたＨＴＴＰリクエストを送信する。
【０１２７】
（ステップＳ３０３）次に、再送実施部１３は、再送実施するか否か判定する。再送実施部１３が再送実施すると判定した場合、ステップＳ３０２に戻って、ＤＲ要求が付加されたＨＴＴＰリクエストを再送する。
【０１２８】
（ステップＳ３０４）ステップＳ３０３で再送実施部１３が再送実施しないと判定された場合、送信時刻確認部１５は、通信部１１が、転送サーバ２から返信されるＨＴＴＰレスポンスを受信したか否か判定する。ＨＴＴＰレスポンスには、上述したトークンａとトークンｂまたはｃが付加されている。通信部１１が転送サーバ２から返信されるＨＴＴＰレスポンスを受信していない場合、ステップＳ３０３に戻って、再送実施部１３は、再度、再送実施するか否か決定する。
【０１２９】
（ステップＳ３０５）ステップＳ３０４で通信部１１が転送サーバ２から返信されるＨＴＴＰレスポンスを受信した場合、送信時刻確認部１５は、時刻認証局３から予め配布された公開鍵で、上述したトークンａとトークンｂまたはｃを復号する。この結果、送信時刻確認部１５は、トークンａから[hash(DR要求), ts(hash(DR要求))]の組を得る。また、送信時刻確認部１５は、トークンｂまたはｃから[hash(format(DR要求)), ts(hash(format(DR要求)))]の組を得る。復号に失敗した場合は、時刻認証局３が発行したトークンではない可能性があるため、以降の処理は行わない。
【０１３０】
（ステップＳ３０６）次に、生成部１４は、ステップＳ３０２で送信済みのＤＲ要求について、ハッシュ値を計算する。具体的には、生成部１４は、ＤＲ要求のハッシュ値hash(DR要求)を計算し、ＤＲ情報に含まれる定義情報を整形し、整形後の定義情報のハッシュ値hash(format(DR要求))を計算する。ハッシュ値の計算には、定義情報抽出部１４１、整形部１４２、ハッシュ値計算部１４３を利用する。
【０１３１】
（ステップＳ３０７）次に、送信時刻確認部１５は、トークンａを復号して得たハッシュ値hash(DR要求)と、自身で計算したハッシュ値hash(DR要求)とを、比較する。値が一致すれば、送信時刻確認部１５は、トークンａを復号して得たタイムスタンプts(hash(DR要求))を、ＤＲ要求の再送時刻として取得する。すなわち、このタイムスタンプts(hash(DR要求))が示す時刻で、ＤＲ要求が再送されたという証明になる。一致しなければ、タイムスタンプts(hash(DR要求))は信頼できないため、以降の処理は行わない。
【０１３２】
（ステップＳ３０８）次に、送信時刻確認部１５は、トークンｂまたはｃを復号して得たハッシュ値hash(format(DR要求))と、自身で計算したハッシュ値hash(formt(DR要求))とを、比較する。値が一致すれば、送信時刻確認部１５は、トークンｂまたはｃを復号して得たタイムスタンプts(hash(format(DR要求)))を、ＤＲ要求の初回送信時刻として取得する。すなわち、このタイムスタンプts(hash(format(DR要求)))が示す時刻で、初回のＤＲ要求が送信されたという証明になる。一致しなければ、タイムスタンプts(hash(format(DR要求)))は信頼できないため、以降の処理は行わない。
【０１３３】
（ステップＳ３０９）次に、送信時刻確認部１５は、取得した再送時刻と、取得した初回送信時刻と、ＤＲ契約に基づいて、ＤＲ要求の有効／無効を判断する。無効になった場合は、送信時刻確認部１５は、運用者にメールなどで無効になった旨を通知してもよい。
【０１３４】
このように、ＤＲ要求を再送する場合であっても、送信サーバ１は、ＤＲ要求の初回送信時刻を取得することができる。また、送信サーバ１は、ＤＲ要求の再送時刻も取得することができる。そして、送信時刻確認部１５は、取得した再送時刻と取得した初回送信時刻とを用いて、ＤＲ要求の有効／無効を判断することができる。
【０１３５】
続いて、受信サーバ４が、ＤＲ要求を受信する処理について図１０を用いて説明する。図１０は、受信サーバ４がＤＲ要求を受信する処理の一例を示すフローチャートである。
【０１３６】
（ステップＳ４０１）まず通信部４１は、ＨＴＴＰリクエストを受信する。ＨＴＴＰリクエストには、上述したＤＲ要求とトークンａとトークンｂまたはｃとが付加されている。
【０１３７】
（ステップＳ４０２）次に、図９のステップＳ３０５と同様に、送信時刻確認部４４は、時刻認証局３から予め配布された公開鍵で、上述したトークンａとトークンｂまたはｃを復号する。この結果、送信時刻確認部４４は、トークンａから[hash(DR要求), ts(hash(DR要求))]の組を得る。また、送信時刻確認部４４は、トークンｂまたはｃから[hash(format(DR要求)), ts(hash(format(DR要求)))]の組を得る。復号に失敗した場合は、時刻認証局３が発行したトークンではない可能性があるため、以降の処理は行わない。
【０１３８】
（ステップＳ４０３）次に、図９のステップＳ３０６と同様に、生成部４３は、ステップＳ４０１で受信済みのＤＲ要求について、ハッシュ値を計算する。具体的には、生成部４３は、ＤＲ要求のハッシュ値hash(DR要求)を計算し、ＤＲ情報に含まれる定義情報を整形し、整形後の定義情報のハッシュ値hash(format(DR要求))を計算する。ハッシュ値の計算には、定義情報抽出部４３１、整形部４３２、ハッシュ値計算部４３３を利用する。
【０１３９】
（ステップＳ４０４）次に、図９のステップＳ３０７と同様に、送信時刻確認部４４は、トークンａを復号して得たハッシュ値hash(DR要求)と、自身で計算したハッシュ値hash(DR要求)とを、比較する。値が一致すれば、送信時刻確認部４４は、トークンａを復号して得たタイムスタンプts(hash(DR要求))を、ＤＲ要求の再送時刻として取得する。すなわち、このタイムスタンプts(hash(DR要求))が示す時刻で、ＤＲ要求が再送されたという証明になる。一致しなければ、タイムスタンプts(hash(DR要求))は信頼できないため、以降の処理は行わない。
【０１４０】
（ステップＳ４０５）次に、図９のステップＳ３０８と同様に、送信時刻確認部４４は、トークンｂまたはｃを復号して得たハッシュ値hash(format(DR要求))と、自身で計算したハッシュ値hash(formt(DR要求))とを、比較する。値が一致すれば、送信時刻確認部４４は、トークンｂを復号して得たタイムスタンプts(hash(format(DR要求)))は、ＤＲ要求の初回送信時刻として取得する。すなわち、このタイムスタンプts(hash(format(DR要求)))が示す時刻で、初回のＤＲ要求が送信されたという証明になる。一致しなければ、タイムスタンプts(hash(format(DR要求)))は信頼できないため、以降の処理は行わない。
【０１４１】
（ステップＳ４０６）次に、送信時刻確認部４４は、取得した再送時刻と、取得した初回送信時刻と、ＤＲ契約とに基づいて、ＤＲ要求の有効／無効を判断する。有効の場合、制御実施部４２は、ＤＲ対象期間に機器（例えば、エアコン）の停止などの消費電力量を低減させる処理を行う。無効の場合、制御実施部４２は、機器制御を行わなくてもよい。
【０１４２】
このように、ＤＲ要求を再送する場合であっても、受信サーバ４は、ＤＲ要求の初回送信時刻を取得することができる。また、受信サーバ４は、ＤＲ要求の再送時刻も取得することができる。そして、送信時刻確認部４４は、取得した再送時刻と取得した初回送信時刻とを用いて、ＤＲ要求の有効／無効を判断することができる。ＤＲ要求が有効であると判断された場合、制御実施部４２は、ＤＲ対象期間に、消費電力量を低減させる処理を行う。その結果、ＤＲ要求を再送する場合であっても、ＤＲ要求が有効であれば、デマンドレスポンス要求に答えて、消費電力量を低減させることができる。
【０１４３】
ＤＲプロトコルによっては、ＤＲ要求を転送サーバ２から受信した受信サーバ４が、転送サーバ２を介して送信サーバ１へ、ＤＲ応答を返す場合がある。ＤＲ契約によっては、ＤＲ応答の送信時刻（以下、ＤＲ応答送信時刻）を用いて、ＤＲ要求の有効／無効を判定する場合もある。よって、ＤＲ応答送信時刻を証明することが、重要な場合もある。以下、図１１を用いて、ＤＲ応答に対して時刻認証局３が発行した時刻を含むトークンとともにＤＲ応答を転送する処理の流れを説明する。図１１は、転送サーバ２がＤＲ応答を転送する処理の流れの一例を示すフローチャートである。なお、図１１の処理は、図６のステップＳ１１０で転送サーバ２がＤＲ要求を受信サーバ４へ送信した後の処理である。
【０１４４】
（ステップＳ５０１）まず、通信部２１は、受信サーバ４から、ＨＴＴＰリクエストを受信する。ＨＴＴＰリクエストには、ＤＲ要求に対するＤＲ応答が付加されている。
【０１４５】
（ステップＳ５０２）次に、ハッシュ値計算部２２３は、このＤＲ応答のハッシュ値hash(DR応答)を計算する。
【０１４６】
（ステップＳ５０３）次に、時刻証明情報取得部２３は、ステップＳ５０２で計算されたハッシュ値hash(DR応答)を時刻認証局３に通信部２１から送信させ、トークンtoken(hash(DR応答), ts(hash(DR応答)))を時刻認証局３から通信により取得する。ここで、トークンtoken(hash(DR応答), ts(hash(DR応答)))は、ハッシュ値hash(DR応答)と、タイムスタンプts(hash(DR応答))を秘密鍵で暗号化したものである。また、タイムスタンプts(hash(DR応答))は、時刻認証局３が発行したタイムスタンプであり、ＤＲ応答送信時刻を表す。
【０１４７】
（ステップＳ５０４）次に、トークン付加部２７１は、ステップＳ５０３で取得したトークンtoken(hash(DR応答), ts(hash(DR応答)))を、ＨＴＴＰレスポンスに付加する。
【０１４８】
（ステップＳ５０５）次に、通信部２１は、ＨＴＴＰレスポンスを、受信サーバ４に返信する。受信サーバ４は、ＨＴＴＰレスポンスに付加されたトークンを、時刻認証局３から予め配布された公開鍵で復号することにより、ＤＲ応答送信時刻を取得することができる。
【０１４９】
（ステップＳ５０６）次に、トークン付加部２７１は、ＤＲ応答と、トークンtoken(hash(DR応答), ts(hash(DR応答)))を、転送用のＨＴＴＰリクエストに付加する。
【０１５０】
（ステップＳ５０７）次に、通信部２１は、転送用のＨＴＴＰリクエストを、送信サーバ１へ送信する。送信サーバ１は、ＨＴＴＰリクエストに付加されたトークンtoken(hash(DR応答), ts(hash(DR応答)))を、時刻認証局３から予め配布された公開鍵で復号することにより、ＤＲ応答送信時刻を確認することができる。
【０１５１】
このように、転送サーバ２は、ＤＲ応答を受信した場合、時刻認証局３が発行したＤＲ応答送信時刻を含むトークンを時刻認証局３から取得し、取得したトークンを送信サーバ１と受信サーバ４へ送信する。これにより、転送サーバ２は、送信サーバ１と受信サーバ４に対して、信頼できるＤＲ応答送信時刻を提供することができる。
【０１５２】
以上、第２の実施形態に係る転送サーバ２において、第２のデマンドレスポンス要求が通信部２１により受信された場合、生成部２２は、第２のデマンドレスポンス要求から、第２のデマンドレスポンス要求の内容を表す第２の要求内容情報（例えば、第２のハッシュ値）を抽出する。そして、時刻証明情報取得部２３は、第２の要求内容情報（例えば、第２のハッシュ値）を含む信号を通信部２１から時刻認証局３へ送信させ、第２のデマンドレスポンス要求を時刻認証局３が発行した時刻を含む第２の時刻証明情報（例えば、トークンａ）を、時刻認証局３から取得する。そして、判定部２６により再送であると判定された場合、制御部２７は、第１の時刻証明情報（例えば、トークンｃ）に加えて、第２の時刻証明情報（例えば、トークンａ）を、通信部２１から送信サーバ１へ送信させる。
【０１５３】
これにより、転送サーバ２は、再送のＤＲ要求を受信した場合、初回のＤＲ要求に対して時刻認証局３が発行した時刻を含む第１の時刻証明情報と、この再送のＤＲ要求に対して時刻認証局３が発行した時刻を含む第２の時刻証明情報を受信サーバ４へ送信することができる。第１の時刻証明情報及び第２の時刻証明情報は時刻認証局３が発行したものであるので、ＤＲ要求を再送する場合であっても、信頼できるＤＲ要求の初回送信時刻及び信頼できる再送時刻を受信サーバ４へ提供することができる。
【０１５４】
本実施形態では、転送サーバ２が、トークンをＨＴＴＰリクエストやＨＴＴＰレスポンスに付加する方法を説明したが、これに限ったものではない。必要に応じて、送信サーバ１や受信サーバ４が、転送サーバ２に、トークンを要求する方法でもよい。例えば、転送サーバ２が、Webサーバを稼働させて、Webサーバ上でトークンを公開すれば、転送サーバ２にトークンを要求する方法を容易に実現できる。
【０１５５】
また、転送サーバ２は、ＤＲ要求やＤＲ応答の転送に失敗した場合に、転送を再試行してもよい。また、転送サーバ２は、転送に失敗した場合に、転送に失敗した旨を、送信サーバ１や受信サーバ４に通知してもよい。
【０１５６】
（第３の実施形態）
続いて、第３の実施形態について説明する。第１の実施形態及び第２の実施形態では、時刻認証局３が発行したトークンを転送サーバ２が記憶した。それに対し、第３の実施形態は、時刻認証局３が発行したトークンを送信サーバ１が記憶する点で、第１の実施形態及び第２の実施形態とは異なる。
【０１５７】
まず、第３の実施形態におけるＤＲ要求の転送処理の概要について図１２を用いて説明する。図１２は、第３の実施形態におけるＤＲ要求の転送処理の一例を示すシーケンス図である。
【０１５８】
Ｔ２１１の処理は、図２のＴ１１の処理と同じであるので、その説明を省略する。Ｔ２２１の処理は、図２のＴ２１の処理と同じであるので、その説明を省略する。
【０１５９】
（Ｔ２２２）転送サーバ２ｂは、Ｔ２１１で送信されたＤＲ要求が再送であるか否か判定する。具体的には、転送サーバ２ｂは、ＤＲ要求とともにトークンを受信したか否か判定することにより再送であるか否か判定する。ここでは、ＤＲ要求とともにトークンを受信していないので、再送でない、すなわち初回の送信であると判定する。
【０１６０】
Ｔ２２３の処理は、図２のＴ２３の処理と同じであるので、その説明を省略する。Ｔ２３１〜Ｔ２３２の処理は、図２のＴ３１〜Ｔ３２の処理と同じであるので、その説明を省略する。
【０１６１】
（Ｔ２２４）転送サーバ２ｂは、Ｔ２２１で計算した第１のハッシュ値と、時刻認証局３から取得したトークンとを送信サーバ１ｂへ送信する。
【０１６２】
（Ｔ２１２）次に、送信サーバ１ｂは、転送サーバ２ｂから受信した第１のハッシュ値とトークンとを関連づけて記憶する。
【０１６３】
（Ｔ２２５）次に、転送サーバ２ｂが、ＤＲ要求とトークンを受信サーバ４へ向けて送信する。しかし、この送信の途中で障害（転送エラー）が発生した場合を想定する。
【０１６４】
（Ｔ２１３）次に、送信サーバ１ｂは、転送エラーの発生を検出すると、ＤＲ要求を転送サーバ２ｂへ再送する。その再送の際、送信サーバ１ｂは、トークンも一緒に転送サーバ２ｂへ送信する。
【０１６５】
（Ｔ２２６）次に、転送サーバ２ｂは、再送されたＤＲ要求からこのＤＲ要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第２のハッシュ値を計算する。
【０１６６】
（Ｔ２２７）次に、転送サーバ２ｂは、Ｔ２１３で送信されたＤＲ要求が再送であるか否か判定する。具体的には、転送サーバ２ｂは、ＤＲ要求とともにトークンを受信したか否か判定することにより再送であるか否か判定する。ここでは、ＤＲ要求とともにトークンを受信したので、再送であると判定する。
【０１６７】
Ｔ２２８の処理は、図２のＴ２９の処理と同じであるので、その説明を省略する。Ｔ２４１〜Ｔ２４３の処理は、図２のＴ４１〜Ｔ４３の処理と同じであるので、その説明を省略する。
【０１６８】
図１３は、第３の実施形態における情報処理システム１０ｂの構成を示す概略ブロック図である。なお、図１３において図３の要素と共通する要素には同一の符号を付し、その具体的な説明を省略する。第３の実施形態における情報処理システム１０ｂの構成は、第１の実施形態における情報処理システム１０の構成に対して、送信サーバ１が送信サーバ１ｂに変更され、転送サーバ２が転送サーバ２ｂに変更されたものになっている。
【０１６９】
（送信サーバ１ｂの構成）
続いて、送信サーバ１ｂの構成について説明する。
【０１７０】
送信サーバ１ｂは、第１の実施形態の送信サーバ１に比べて、更に記憶装置１７を備える点、通信部１１が通信部１１ｂに変更された点、再送実施部１３が再送実施部１３ｂに変更された点、制御部１６が制御部１６ｂに変更された点が異なっている。
【０１７１】
通信部１１ｂは、第１の実施形態における通信部１１と同様の機能を有するが、更に以下の機能を有する。通信部１１ｂは、デマンドレスポンス要求を第１の通信装置へ送信し、この送信に応じて、このデマンドレスポンス要求に対して時刻認証局３が発行した時刻を含む時刻証明情報（例えば、トークン）を転送サーバ２ｂから取得する。
【０１７２】
制御部１６ｂは、第１の実施形態における制御部１６と同様の機能を有するが、更に以下の機能を有する。制御部１６ｂは、通信部１１ｂが受信した時刻証明情報（例えば、トークン）を記憶装置１７に記憶させる。
【０１７３】
再送実施部１３ｂは、第１の実施形態における再送実施部１３と同様の機能を有するが、以下の点で異なっている。再送実施部１３ｂは、デマンドレスポンス要求の再送を実施すると決定した場合、記憶装置１７に記憶された時刻証明情報を読み出し、読み出した時刻証明情報をデマンドレスポンス要求とともに、通信部１１ｂから転送サーバ２ｂへ送信させる。
【０１７４】
転送サーバ２ｂは、第１の実施形態の転送サーバ２に比べて、記憶装置２５を有さない点、更に検証部２８を有する点、記憶処理部２４が記憶処理部２４ｂに変更された点、判定部２６が判定部２６ｂに変更された点が異なっている。  
記憶処理部２４ｂは、第１のデマンドレスポンス要求が通信部２１により受信された場合、送信サーバ１ｂが第１の要求内容情報（例えば、ハッシュ値）と第１の時刻証明情報（例えば、トークン）とを関連づけて記憶装置１７に記憶させるために、第１の要求内容情報と第１の時刻証明情報とを送信サーバ１ｂへ送信する。
【０１７５】
判定部２６ｂは、通信部２１が受信した第２のデマンドレスポンス要求に第１の時刻証明情報が付加されているか否か判定することにより、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送であるか否かを判定する。
【０１７６】
第２のデマンドレスポンス要求に第１の時刻証明情報が付加されている場合、制御部２７は、付加されている第１の時刻証明情報を、通信部２１から受信サーバ４へ送信させる。一方、第２のデマンドレスポンス要求に第１の時刻証明情報が付加されていない場合、第２のデマンドレスポンス要求に対して時刻認証局３が発行した時刻を含む第２の時刻証明情報を、通信部２１から受信サーバ４へ送信させる。ここで、第２の時刻証明情報は、時刻証明情報取得部２３が、第２の要求内容情報（例えば、第２のハッシュ値）を時刻認証局３へ送信し、この送信に応じて前記時刻認証局から取得したものである。
【０１７７】
生成部２２は、第２のデマンドレスポンス要求が通信部２１により受信された場合、第２のデマンドレスポンス要求から、第２のデマンドレスポンス要求の内容を表す第２の要求内容情報（例えば、第２のハッシュ値）を抽出する。
【０１７８】
検証部２８は、送信サーバ１ｂから取得した第１の時刻証明情報（例えば、トークン）が正しいか否かを検証する。例えば、検証部２８は、受信された第２のデマンドレスポンス要求に付加されている第１の時刻証明情報と、第２の要求内容情報（例えば、第２のハッシュ値）とを用いて、第１の時刻証明情報が正しいか否か検証する。具体的には例えば、検証部２８は、この第１の時刻証明情報を時刻認証局３から予め配布された公開鍵で復号し、復号した値と、第２の要求内容情報（例えば、第２のハッシュ値）とを比較することにより、第１の時刻証明情報が正しいか否か検証する。
【０１７９】
続いて、ＤＲ要求の初回送信時刻を証明するための処理について、図１４を用いて説明する。図１４は、ＤＲ要求の初回送信時刻を証明するための処理の一例を示すフローチャートである。ステップＳ６０１〜Ｓ６０４は、図６のステップＳ１０１〜Ｓ１０４と同一であるので、その説明を省略する。
【０１８０】
（ステップＳ６０５）判定部２６ｂは、ＤＲ要求とともにトークンを受信したか否かを判定する。
【０１８１】
（ステップＳ６０６）ステップＳ６０５でＤＲ要求とともにトークンを受信したと判定された場合、検証部２８は、受信したトークンを時刻認証局３から予め配布された公開鍵で復号する。
【０１８２】
（ステップＳ６０７）次に、検証部２８は、復号して得られたハッシュ値と、ステップＳ６０４で算出されたハッシュ値が一致するか否か判定する。復号して得られたハッシュ値と、ステップＳ６０４で算出されたハッシュ値が一致しない場合、処理がステップＳ６０１に戻る。復号して得られたハッシュ値と、ステップＳ６０４で算出されたハッシュ値が一致する場合、処理がステップＳ６１１に進む。
【０１８３】
（ステップＳ６０８）ステップＳ６０５でＤＲ要求とともにトークンを受信していないと判定された場合、通信部２１は、ステップＳ６０４で算出されたハッシュ値を時刻認証局３へ送信する。これにより、時刻認証局３は、タイムスタンプを発行し、発行したタイムスタンプとこのハッシュ値とを秘密鍵で暗号化したトークンを生成する。
【０１８４】
（ステップＳ６０９）次に、通信部２１は、時刻認証局３からトークンを受信する。
【０１８５】
（ステップＳ６１０）次に、通信部２１は、ステップＳ６０４で算出したハッシュ値と、ステップＳ６０８で時刻認証局３から受信したトークンとを送信サーバ１ｂへ送信する。その後、処理がステップＳ６１１に進む。
【０１８６】
（ステップＳ６１１）次に、通信部２１は、送信サーバ１ｂまたは時刻認証局３から取得されたトークンと、ステップＳ６０１で受信されたＤＲ要求とを受信サーバ４へ送信する。その後、処理がステップＳ１０１に戻る。  
このように、判定部２６ｂは、ＤＲ要求とともにトークンを受信したか否かを判定する。ＤＲ要求とともにトークンを受信したと判定された場合、受信されたＤＲ要求は再送であるので、通信部２１は、このトークンとＤＲ要求とを受信サーバ４へ送信する。一方、ＤＲ要求とともにトークンを受信していないと判定された場合、受信されたＤＲ要求は初回の送信であるので、通信部２１は、時刻認証局３からトークンを取得する。通信部２１は、このトークンとＤＲ要求とを受信サーバ４へ送信する。
【０１８７】
これにより、トークンは、初回のＤＲ要求に対して時刻認証局３が発行したタイムスタンプが含まれているので、転送サーバ２ｂは、信頼できる初回送信時刻を受信サーバ４へ提供することができる。
【０１８８】
以上、第３の実施形態に係る転送サーバ２ｂにおいて、記憶処理部２４ｂは、第１のデマンドレスポンス要求が通信部２１により受信された場合、第１の通信装置が第１の要求内容情報と第１の時刻証明情報とを関連づけて記憶装置１７に記憶させるために、第１の要求内容情報と第１の時刻証明情報とを送信サーバ１ｂへ送信する。判定部２６ｂは、通信部２１が受信した第２のデマンドレスポンス要求に第１の時刻証明情報が付加されているか否か判定することにより、第２のデマンドレスポンス要求が第１のデマンドレスポンス要求の再送であるか否かを判定する。第２のデマンドレスポンス要求に第１の時刻証明情報が付加されている場合、制御部２７は、付加されている第１の時刻証明情報を、通信部２１から受信サーバ４へ送信させる。
【０１８９】
これにより、転送サーバ２ｂは、再送のＤＲ要求を受信した場合、初回のＤＲ要求に対して時刻認証局３が発行した時刻を含む第１の時刻証明情報を受信サーバ４へ送信することができる。第１の時刻証明情報は時刻認証局３が発行したものであるので、ＤＲ要求を再送する場合であっても、信頼できるＤＲ要求の初回送信時刻を受信サーバ４へ提供することができる。
【０１９０】
（第４の実施形態）
続いて、第４の実施形態について説明する。第３の実施形態では、ＤＲ要求の初回送信時刻のみを証明するための処理例について説明した。それに対し、第４の実施形態では、ＤＲ要求の初回送信時刻及び再送時刻の両方を証明するための処理例について説明する。なお、第４の実施形態における情報システム１０ｂの構成は、第３の実施形態における情報処理システム１０ｂの構成と同一であるので、その説明を省略する。
【０１９１】
まず、図１５を用いて、転送サーバ２ｂの処理を説明する。図１５は、第４の実施形態における、ＤＲ要求の初回送信時刻と再送送信時刻の両方を証明するための処理の一例を示すフローチャートである。ステップＳ７０１〜Ｓ７０７の処理は、図７のステップＳ２０１〜Ｓ２０７の処理と同一であるので、その説明を省略する。
【０１９２】
（ステップＳ７０８）次に、判定部２６ｂは、ＤＲ要求とともにトークンｃを受信したか否か判定する。
【０１９３】
（ステップＳ７０９）ステップＳ７０８で、ＤＲ要求とともにトークンｃを受信したと判定された場合、再送であるので、検証部２８は、受信されたトークンｃを、時刻認証局３から予め配布された公開鍵で復号する。
【０１９４】
（ステップＳ７１０）検証部２８は、復号して得られたハッシュ値と、ステップＳ７０７で計算されたハッシュ値Ｂとが一致するか否か判定する。復号して得られたハッシュ値と、ステップＳ７０７で計算されたハッシュ値Ｂとが一致しないと判定された場合、処理がステップＳ７０１に戻る。
【０１９５】
（ステップＳ７１１）ステップＳ７１０で復号して得られたハッシュ値とステップＳ７０７で計算されたハッシュ値Ｂとが一致すると判定された場合、ＤＲ要求は再送であるので、トークン付加部２７１は、ＨＴＴＰレスポンスにトークンａとトークンｃを付加する。なお、付加する場所は、ＨＴＴＰヘッダ部であっても、ＨＴＴＰボディであってもよい。二つのトークンを区別できるように付加すればよい。
【０１９６】
（ステップＳ７１２）次に、トークン付加部２７１は、ＨＴＴＰリクエストにＤＲ要求、トークンａ、及びトークンｃを付加する。その後、処理がステップＳ７１７に進む。なお、付加する場所は、ＨＴＴＰヘッダ部であっても、ＨＴＴＰボディであってもよい。二つのトークンを区別できるように付加すればよい。
【０１９７】
（ステップＳ７１３）ステップＳ７０８で、ＤＲ要求とともにトークンｃを受信していないと判定された場合、ＤＲ要求は初回の送信であるので、制御部２７は、通信部２１から時刻認証局３へハッシュ値Ｂを送信する。
【０１９８】
（ステップＳ７１４）次に、通信部２１は、ステップＳ２１０におけるハッシュＢの送信に応じて、時刻認証局３から送信されたトークンｂを受信する。このトークンｂは、token(hash(format(DR要求)), ts(hash(format(DR要求))))と表される。
【０１９９】
（ステップＳ７１５）次に、トークン付加部２７１は、ＨＴＴＰレスポンスにトークンａとトークンｂを付加する。なお、付加する場所は、ＨＴＴＰヘッダ部であっても、ＨＴＴＰボディであってもよい。二つのトークンを区別できるように付加すればよい。
【０２００】
（ステップＳ７１６）次に、トークン付加部２７１は、ＨＴＴＰリクエストにＤＲ要求、トークンａ、及びトークンｂを付加する。なお、付加する場所は、ＨＴＴＰヘッダ部であっても、ＨＴＴＰボディであってもよい。二つのトークンを区別できるように付加すればよい。
【０２０１】
ステップＳ７１７及びＳ７１８の処理は，図７のステップＳ２１７及びＳ２１８の処理と同一であるので、その説明を省略する。
【０２０２】
このように、転送サーバ２ｂは、再送のＤＲ要求を受信した場合、この受信したＤＲ要求に対して時刻認証局３が発行したトークンａを取得し、ＤＲ要求の初回送信時に時刻認証局３が発行したトークンｃを取得する。ここで、トークンａには、時刻認証局３が発行した再送時刻が含まれ、トークンｃには、時刻認証局３が発行した初回送信時刻が含まれている。そして、転送サーバ２ｂは、取得したトークンａとトークンｃを送信サーバ１ｂと受信サーバ４へ送信する。これにより、送信サーバ１ｂと受信サーバ４は、時刻認証局３が発行した初回送信時刻及び再送時刻を取得することができる。
【０２０３】
続いて、送信サーバ１ｂがＤＲ要求を送信する処理について図１６を用いて説明する。図１６は、送信サーバ１ｂがＤＲ要求を送信する処理の一例を示すフローチャートである。ステップＳ８０１〜Ｓ８０２の処理は、図９のステップＳ３０１〜Ｓ３０２の処理と同一であるので、その説明を省略する。
【０２０４】
（ステップＳ８０３）次に、再送実施部１３ｂは、再送実施するか否か判定する。
【０２０５】
（ステップＳ８１０）ステップＳ８０３で再送実施部１３ｂにより再送実施すると判定された場合、制御部１６ｂは、ＨＴＴＰリクエストに、ＤＲ要求記憶部１２に記録されたＤＲ要求とトークンを付加する。付加する場所は、ＨＴＴＰリクエストのヘッダ部でもよいし、ボディ部でもよい。付加するトークンは、ＤＲ要求の初回送信時に転送サーバ２ｂから返されたトークンである。このトークンは記憶装置１７に記録されているはずであり、ＤＲ要求のハッシュ値hash(format(DR要求))を計算することで求められる。そして、通信部１１ｂは、転送サーバ２ｂに、ＤＲ要求とトークンが付加されたＨＴＴＰリクエストを送信する。
【０２０６】
ステップＳ８０４〜Ｓ８０９の処理は、図９のステップＳ３０４〜Ｓ３０９の処理と同一であるので、その説明を省略する。
【０２０７】
このように、再送実施部１３ｂにより再送実施すると判定された場合、制御部１６ｂは、ＨＴＴＰリクエストに、ＤＲ要求記憶部１２に記録されたＤＲ要求とトークンを付加する。そして、通信部１１ｂは、転送サーバ２ｂに、ＤＲ要求とトークンが付加されたＨＴＴＰリクエストを送信する。これにより、転送サーバ２ｂは、ＤＲ要求とともにトークンを受信した場合、そのＤＲ要求が再送であると判定することができる。
【０２０８】
以上、第４の実施形態に係る転送サーバ２ｂにおいて、第２のデマンドレスポンス要求が通信部２１により受信された場合、生成部２２は、第２のデマンドレスポンス要求から、第２のデマンドレスポンス要求の内容を表す第２の要求内容情報（例えば、第２のハッシュ値）を抽出する。そして、時刻証明情報取得部２３は、第２の要求内容情報（例えば、第２のハッシュ値）を含む信号を通信部２１から時刻認証局３へ送信させ、第２のデマンドレスポンス要求に対して時刻認証局３が発行した時刻を含む第２の時刻証明情報（例えば、トークンａ）を、時刻認証局３から取得する。
【０２０９】
そして、判定部２６により第２のデマンドレスポンス要求とともに第１の時刻証明情報（例えば、トークンｃ）を受信したか否か判定する。判定部２６により第２のデマンドレスポンス要求とともに第１の時刻証明情報（例えば、トークンｃ）を受信したと判定された場合、制御部２７は、第１の時刻証明情報（例えば、トークンｃ）に加えて、第２の時刻証明情報（例えば、トークンａ）を、通信部２１から送信サーバ１ｂへ送信させる。
【０２１０】
これにより、転送サーバ２ｂは、再送のＤＲ要求を受信した場合、初回のＤＲ要求に対して時刻認証局３が発行した時刻を含む第１の時刻証明情報と、この再送のＤＲ要求に対して時刻認証局３が発行した時刻を含む第２の時刻証明情報を受信サーバ４へ送信することができる。第１の時刻証明情報及び第２の時刻証明情報は時刻認証局３が発行したものであるので、ＤＲ要求を再送する場合であっても、転送サーバ２ｂは、信頼できるＤＲ要求の初回送信時刻及び信頼できる再送時刻を受信サーバ４へ提供することができる。
【０２１１】
なお、各実施形態において、送信サーバ１または１ｂと、転送サーバ２または２ｂとは、別々の装置として説明したが、これに限らず、一体の情報処理装置として構成されてもよい。
【０２１２】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０２１３】
１  送信サーバ（第１の通信装置）
２  転送サーバ（情報処理装置）
３  時刻認証局
４  受信サーバ（第２の通信装置）
５  通信網
１０  情報処理システム
１１、１１ｂ、２１、４１  通信部
１２  ＤＲ要求記憶部
１３、１３ｂ  再送実施部
１４、２２、４３  生成部
１４１、２２１、４３１  定義情報抽出部
１４２、２２２、４３２  整形部
１４３、２２３、４３３  ハッシュ値計算部
１５、４４  送信時刻確認部
１６、１６ｂ、２７  制御部
１７、２５  記憶装置
２３  時刻証明情報取得部
２４  記憶処理部
２６  判定部
４２  制御実施部
【図１】
2016046724.tif 000003
【図２】
2016046724.tif 000004
【図３】
2016046724.tif 000005
【図４】
2016046724.tif 000006
【図５】
2016046724.tif 000007
【図６】
2016046724.tif 000008
【図７】
2016046724.tif 000009
【図８】
2016046724.tif 000010
【図９】
2016046724.tif 000011
【図１０】
2016046724.tif 000012
【図１１】
2016046724.tif 000013
【図１２】
2016046724.tif 000014
【図１３】
2016046724.tif 000015
【図１４】
2016046724.tif 000016
【図１５】
2016046724.tif 000017
【図１６】
2016046724.tif 000018