JP2016046724A - 情報処理装置及び通信装置 - Google Patents

情報処理装置及び通信装置 Download PDF

Info

Publication number
JP2016046724A
JP2016046724A JP2014170785A JP2014170785A JP2016046724A JP 2016046724 A JP2016046724 A JP 2016046724A JP 2014170785 A JP2014170785 A JP 2014170785A JP 2014170785 A JP2014170785 A JP 2014170785A JP 2016046724 A JP2016046724 A JP 2016046724A
Authority
JP
Japan
Prior art keywords
request
information
time
demand response
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014170785A
Other languages
English (en)
Other versions
JP6219248B2 (ja
Inventor
雄 金子
Yu Kaneko
雄 金子
智則 前川
Tomonori Maekawa
智則 前川
恵介 米良
Keisuke Mera
恵介 米良
将志 伊藤
Masashi Ito
将志 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2014170785A priority Critical patent/JP6219248B2/ja
Priority to US14/833,662 priority patent/US9985754B2/en
Publication of JP2016046724A publication Critical patent/JP2016046724A/ja
Application granted granted Critical
Publication of JP6219248B2 publication Critical patent/JP6219248B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1887Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0097Relays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121Timestamp
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】デマンドレスポンス要求に関する時刻を証明する情報処理装置及び通信装置を提供する。
【解決手段】第1のデマンドレスポンス要求を第1の通信装置から受信し、第2のデマンドレスポンス要求を第1の通信装置から受信する通信部と、第1のデマンドレスポンス要求から、要求の内容を表す情報を生成する生成部と、第1のデマンドレスポンス要求に対して時刻認証局が発行した時刻を含む第1の時刻証明情報を取得する時刻証明情報取得部と、第1のデマンドレスポンス要求に関連づけて第1の時刻証明情報を記憶装置に記憶させる記憶処理部と、第2のデマンドレスポンス要求が通信部により受信された場合、第1のデマンドレスポンス要求の再送か否かを判定する判定部と、再送であると判定された場合、第2のデマンドレスポンス要求と、記憶装置に記憶された第1の時刻証明情報とを、通信部から第2の通信装置へ送信させる制御部と、を備える。
【選択図】図3

Description

本発明の実施形態は、情報処理装置及び通信装置に関する。
デマンドレスポンス(Demand Response:DR)とは、電力供給者が電力消費者に対して、電力消費量を調整するように要求することで、電力の需要と供給のバランスを保つ方法である。以下、電力消費量の調整要求であるデマンドレスポンス要求を、DR要求と呼ぶ。電力消費者は、DR要求を受けると、このDR要求の内容に応じて行動する。例えば、DR要求の内容が「明日の12:00〜14:00の電力消費量の削減」の場合は、電力消費者は、明日の12:00〜14:00にエアコンを停止するなどの行動を取る。このように、電力消費量の調整が必要な期間のことを、DR対象期間と呼ぶ。
近年では、DR要求をインターネットを介して伝える方法(DRプロトコル)が規格化されている。このDRプロトコルには、例えば、Open Automated Demand Response(OpenADR)がある。DRプロトコルを用いてDRを実施する場合、電力供給者は、DR要求を送信するためのシステムを用意し、電力消費者は、DR要求を受信するためのシステムを用意する。
デマンドレスポンスを実施する場合、電力供給者(DR要求の送信者)と電力消費者(DR要求の受信者)との間で、デマンドレスポンス契約(以下、DR契約という)を結ぶ。DR要求の送信時刻に基づいて、そのDR要求の有効または無効が決まる場合、送信時刻は、電力供給者と電力消費者の双方にとって重要となる。DR要求が無効になれば、電力供給者が事前に作成した電力調整の計画は崩れてしまう。また、DR要求が無効になれば、電力消費者は、電力消費量の調整を行う必要がなくなる。
このように、DR要求の有効または無効は、電力供給者と電力消費者の行動に影響を与える。電力消費量の調整という目標に向けて、電力供給者と電力消費者が正しく行動するためには、DR要求の送信時刻を双方に証明する仕組みが必要である。
通信網に障害が発生してDR要求が電力消費者に到達しなかった場合、DR要求を再送する。最初にこのDR要求を送信した際の送信時刻(以下、初回送信時刻という)に基づいて、そのDR要求の有効または無効が決まる場合、この初回送信時刻は、電力供給者と電力消費者の双方にとって重要となる。しかしながら、DR要求を再送する場合、初回送信時刻を証明することが難しいという問題があった。
特開2011−72042号公報
そこで本発明の実施形態が解決しようとする課題は、デマンドレスポンス要求を再送する場合であっても、初回のデマンドレスポンス要求に関する時刻を証明することが可能な情報処理装置及び通信装置を提供することである。
一の実施形態によれば、情報処理装置は、第1のデマンドレスポンス要求を第1の通信装置から受信し、前記第1のデマンドレスポンス要求の受信後に、第2のデマンドレスポンス要求を前記第1の通信装置から受信する通信部を備える。情報処理装置は、前記第1のデマンドレスポンス要求から、前記第1のデマンドレスポンス要求の内容を表す第1の要求内容情報を生成する生成部を備える。情報処理装置は、第1の要求内容情報を時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第1のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第1の時刻証明情報を取得する時刻証明情報取得部を備える。情報処理装置は、前記第1のデマンドレスポンス要求に関連づけて前記第1の時刻証明情報を記憶装置に記憶させるための処理を実行する記憶処理部を備える。情報処理装置は、前記第2のデマンドレスポンス要求が前記通信部により受信された場合、前記第2のデマンドレスポンス要求が前記第1のデマンドレスポンス要求の再送であるか否かを判定する判定部を備える。情報処理装置は、前記判定部により再送であると判定された場合、前記第2のデマンドレスポンス要求と、前記記憶装置において前記第1のデマンドレスポンス要求に関連づけられた前記第1の時刻証明情報とを、前記通信部から第2の通信装置へ送信させる制御部を備える。
第1の実施形態における情報処理システム10の構成を示す図。 第1の実施形態におけるDR要求の転送処理の一例を示すシーケンス図。 第1の実施形態における情報処理システム10の詳細な構成を示す図。 OpenADRのDR要求の一部を示す図。 記憶装置25に記録される情報の一例を示す図。 初回のDR要求に対して時刻認証局3が発行した時刻を伝送する処理の一例を示すフローチャート。 初回のDR要求と再送のDR要求に対して時刻認証局3が発行した時刻を伝送する処理の一例を示すフローチャート。 HTTPヘッダ部に付加されたトークンの一例。 送信サーバ1がDR要求を送信する処理の一例を示すフローチャート。 受信サーバ4がDR要求を受信する処理の一例を示すフローチャート。 転送サーバ2がDR応答を転送する処理の流れの一例を示すフローチャート。 第3の実施形態におけるDR要求の転送処理の一例を示すシーケンス図。 第3の実施形態における情報処理システム10bの構成を示す概略ブロック図。 DR要求の初回送信時刻を証明するための処理の一例を示すフローチャート。 DR要求の初回送信時刻と再送送信時刻の両方を証明するための処理の一例を示すフローチャート。 送信サーバ1bがDR要求を送信する処理の一例を示すフローチャート。
以下、図面を参照しながら、本発明の実施形態について説明する。
(第1の実施形態)
まず、第1の実施形態について説明する。図1は、第1の実施形態における情報処理システム10の構成を示す図である。図1に示すように、情報処理システム10は、送信サーバ(第1の通信装置)1、転送サーバ(情報処理装置)2、時刻認証局3、及び受信サーバ(第2の通信装置)4を備える。
送信サーバ1は、DR要求を通信網5を介して、転送サーバ2へ送信する。
転送サーバ2は、送信サーバ1から受信したDR要求を通信網5を介して、受信サーバ4へ転送する。
受信サーバ4は、転送サーバ2から通信網5を介して、DR要求を受信する。
時刻認証局(Time-Stamping Authority:TSA)3は、要求に応じてタイムスタンプ(Time Stamp:TS)を発行する。具体的には例えば、時刻認証局3は、任意のハッシュ値を受信すると、時刻配信局(Time Assessment Authority:TAA)から配信された時刻情報に基づき、タイムスタンプを発行する。そして、時刻認証局3は、このタイムスタンプとこのハッシュ値を自身の秘密鍵で暗号化したトークンを生成する。ここで、トークンは、デマンドレスポンス要求に対して時刻認証局3が発行した時刻を含む時刻証明情報の一例である。
信頼できる第3者(Trusted Third Party)である時刻認証局3がタイムスタンプを発行することで、送信サーバ1と受信サーバ4の両方が、このタイムスタンプが正しいことを信頼できる。
以降、ある入力mから作成されたハッシュ値のことを、hash(m)と表記する。また、時刻認証局3が、あるハッシュ値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)))である。
なお、各サーバは、複数のサーバとネットワークから構成されるシステムであってもよい。また、本実施形態では一例として、情報処理システム10内の送信サーバは一台であるが、これに限らず、複数台、存在してもよい。
同様に、本実施形態では一例として、情報処理システム10内の受信サーバは一台であるが、これに限らず、複数台、存在してもよい。例えば、ビルや家などの建物ごとに受信サーバが存在することもありえる。本実施形態では一例として、時刻認証局3と転送サーバ4の間は通信網5で接続されたが、これに限らず、時刻認証局3と転送サーバ4の間は、専用回線で接続されてもよい。
続いて、第1の実施形態におけるDR要求の転送処理の概要について図2を用いて説明する。図2は、第1の実施形態におけるDR要求の転送処理の一例を示すシーケンス図である。
(T11)まず、送信サーバ1は、DR要求を転送サーバ2へ送信する。ここで、このDR要求の送信は、初回の送信である。
(T21)次に、転送サーバ2は、DR要求からこのDR要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第1のハッシュ値を計算する。この整形は、表現の揺らぎ及び情報の登場順序などのフォーマットである。
(T22)次に、転送サーバ2は、このDR要求が再送であるか否か判定する。ここでは、このDR要求は再送ではないと判定される。
(T23)DR要求が再送ではないので、転送サーバ2は、T21で計算した第1のハッシュ値を時刻認証局3へ送信する。
(T31)次に、時刻認証局3は、第1のハッシュ値を転送サーバ2から受信すると、タイムスタンプTS1を発行する。そして、時刻認証局3は、第1のハッシュ値とタイムスタンプTS1に基づいて、このタイムスタンプTS1を証明するトークンを生成する。ここで、トークンは、例えば、第1のハッシュ値とタイムスタンプTS1との組が、公開鍵暗号方式の秘密鍵で暗号化された情報である。
(T32)次に、時刻認証局3は、T31で生成したトークンを、転送サーバ2へ送信する。
(T24)次に、転送サーバ2は、トークンを時刻認証局3から受信すると、第1のハッシュ値と受信したトークンを関連づけて記憶装置に記憶する。
(T25)次に、転送サーバ2が、DR要求とトークンを受信サーバ4へ向けて送信する。しかし、この送信の途中で障害(転送エラー)が発生した場合を想定する。
(T12)送信サーバ1は、転送エラーの発生を検出すると、DR要求を転送サーバ2へ再送する。
(T26)次に、転送サーバ2は、再送されたDR要求からこのDR要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第2のハッシュ値を計算する。
(T27)次に、転送サーバ2は、このDR要求が再送であるか否か判定する。ここでは、このDR要求が再送であると判定される。
(T28)次に、転送サーバ2は、第2のハッシュ値に対応するトークンを記憶装置から読み出す。
(T29)次に、転送サーバ2は、DR要求と読み出したトークンとを受信サーバ4へ送信する。
(T41)次に、受信サーバ4は、DR要求とトークンとを受信すると、受信したDR要求からこのDR要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第3のハッシュ値を計算する。
(T42)次に、受信サーバ4は、タイムスタンプTS1が信頼できるか否か判定する。例えば、受信サーバ4は、時刻認証局3から配布された公開鍵でトークンを復号し、復号して得たハッシュ値と、第3のハッシュ値とが一致するか否か判定する。ここで、この公開鍵は、時刻認証局3でトークンを暗号化されるときに用いられる秘密鍵と対になるものである。復号して得られたハッシュ値と第3のハッシュ値とが一致する場合、受信サーバ4は、トークンを復号して得られたタイムスタンプTS1を信頼できる。
(T43)次に、受信サーバ4は、タイムスタンプTS1を用いて、DR要求の有効/無効を判断する。以上で、本シーケンスの処理を終了する。
このように、DR要求を再送する場合であっても、受信サーバ4は、DR要求の初回送信時刻であるタイムスタンプTS1を取得することができる。
続いて、図3を用いて、転送サーバ2の構成について説明する。図3は、第1の実施形態における情報処理システム10の詳細な構成を示す図である。
図3に示すように、転送サーバ2は、通信部21、生成部22、時刻証明情報取得部23、記憶処理部24、記憶装置25、判定部26、及び制御部27を備える。
通信部21は、通信網5を介して、送信サーバ1、時刻認証局3、及び受信サーバ4と通信する。例えば、通信部21は、第1のデマンドレスポンス要求を送信サーバ1から受信し、第1のデマンドレスポンス要求の受信後に、第2のデマンドレスポンス要求を送信サーバ1から受信する。
生成部22は、デマンドレスポンス要求から、このデマンドレスポンス要求の内容を表す要求内容情報を生成する。ここで、本実施形態では、要求内容情報は、一例として、整形後の定義情報のハッシュ値である。なお、要求内容情報は、DR対象時刻と省エネ量の組などのDR要求の内容を規定する情報であってもよく、DR要求の内容を規定できればどんな情報であってもよい。
例えば、生成部22は、第1のデマンドレスポンス要求(例えば、図2の初回のDR要求)から、第1のデマンドレスポンス要求の内容を表す第1の要求内容情報 (例えば、図2の第1のハッシュ値)を生成する。また、例えば、生成部22は、第2のデマンドレスポンス要求(例えば、図2の再送のDR要求を送信要求)が通信部21により受信された場合、第2のデマンドレスポンス要求から、第2のデマンドレスポンス要求の内容を表す第2の要求内容情報(例えば、図2の第2のハッシュ値)を生成する。
ここで、生成部22は、定義情報抽出部221、整形部222、及びハッシュ値計算部223を備える。
定義情報抽出部221は、通信部21が受信したDR要求から、DR要求を定義する情報の集まりである定義情報を抽出する。このことから、定義情報抽出部221は、例えば、通信部21が第1のデマンドレスポンス要求を受信した場合、第1のデマンドレスポンス要求を定義する第1の定義情報を抽出する。同様に、定義情報抽出部221は、例えば、通信部21が第2のデマンドレスポンス要求を受信した場合、第2のデマンドレスポンス要求を定義する第2の定義情報を抽出する。
例えば、定義情報は、送信元の送信サーバを識別する送信サーバID、宛先の受信サーバを識別する受信サーバID、DR種類、DR対象期間、電力調整量(例えば、電気料金、電力消費量の削減目標値など)を含む。これらの情報は、初回送信時と再送時で変化しない。もしこれらの情報が変化したら、それは再送ではない。定義情報の具体的な内容は、DRプロトコルによって決まる。
DR要求に含まれており、かつ、定義情報に含まれない情報には、例えば、メッセージID及びメッセージ作成時刻がある。これらの情報は、初回送信時と再送時で変化する。
図4は、OpenADRのDR要求の一部を示す図である。図4内の情報の中で、requestIDやcreatedDateTimeは、送信のたびに変化する情報であり、定義情報に含まれない。逆に、それ以外の情報は、定義情報に含まれる。
デマンドレスポンスのプロトコル(DRプロトコル)によって、定義情報は異なる。そのため例えば、送信元のDR送信サーバIDを含むDRプロトコルと、含まないDRプロトコルが存在する。複数のDRプロトコルに対応するためには、DRプロトコル毎に、定義情報として抽出すべき情報を定義しておけばよい。そして、定義情報抽出部221は、DRプロトコルに応じて、抽出する情報を変更してもよい。これにより、定義情報抽出部221は、DRプロトコルに応じた抽出処理を行うことができる。
図3において、整形部222は、定義情報抽出部221が抽出した定義情報を整形する。例えば、整形部222は、定義情報抽出部221が第1の定義情報を抽出した場合、この第1の定義情報を整形する。また、例えば、整形部222は、定義情報抽出部221が第2の定義情報を抽出した場合、この第2の定義情報を整形する。具体的な整形の内容は、DRプロトコルによって決まる。以下に、整形処理の一例を示す。整形処理には、定義情報の整列がある。整列の基準は、様々である。例えば、アルファベット順、または五十音順などがある。また整形処理には、定義情報内の改行の削除、及び/または不要な空白の削除がある。
DRプロトコルによって、整形の方法は異なる。例えば、情報の改行を許可するDRプロトコルと、許可しないDRプロトコルが存在する。DRプロトコルが改行を許可していなければ、整形部222が、改めて改行を削除する必要はない。複数のDRプロトコルに対応するためには、DRプロトコルごとに、行うべき整形処理を定義しておけばよい。そして、整形部222は、DRプロトコルに応じて、整形する方法を変更する。これにより、整形部222は、DRプロトコルに応じた整形処理を行うことができる。以降、定義情報抽出部221の処理及び整形部222の処理の両方が済んだDR要求のことを、format(DR要求)と表記する。
ハッシュ値計算部223は、DR要求、または整形部222により整形された定義情報を入力として、ハッシュ値を計算する。例えば、ハッシュ値計算部223は、整形された第1の定義情報のハッシュ値を第1の要求内容情報として計算し、整形された第2の定義情報のハッシュ値を第2の要求内容情報として計算する。ハッシュアルゴリズムはMD5やSHA1やSHA2などがある。ハッシュ値を計算する前に、定義情報が抽出され、この定義情報が整形されることで、初回送信時のDR要求から計算されるハッシュ値と、再送時のDR要求から計算されるハッシュ値が等しくなる。
時刻証明情報取得部23は、整形後の定義情報から計算されたハッシュ値を使い、記憶装置25または時刻認証局3から、トークンを取得する。判定部26が再送だと判定した場合、ハッシュ値に対応するトークン(初回送信時に取得され記録されたトークン)が記憶装置に記録されているはずなので、記憶装置からトークンを取得する。一方、判定部26が再送ではないと判定した場合(初回送信の場合)は、時刻証明情報取得部23は、ハッシュ値を時刻認証局3に送り、時刻認証局3にトークンを作成してもらい、時刻認証局3からトークンを取得する。記憶処理部24は、時刻認証局3からからトークンを取得した場合、ハッシュ値とトークンとを関連づけて、記憶装置に記録する。
例えば、時刻証明情報取得部23は、第1の要求内容情報(例えば、図2の第1のハッシュ値)を時刻認証局3へ送信し、この送信に応じて時刻認証局3から送信された、第1のデマンドレスポンス要求に対して時刻認証局3が発行した時刻を含む第1の時刻証明情報(例えば、図2のトークン)を時刻認証局3から取得する。
本実施形態では、第1の時刻証明情報は、一例として、第1のデマンドレスポンス要求に対して時刻認証局3が発行した時刻に加えて、第1の要求内容情報の値も含む。具体的な一例として、第1の時刻証明情報は、第1の要求内容情報の値と第1のデマンドレスポンス要求に対して時刻認証局3が発行した時刻とを含む情報が、時刻認証局3によって暗号化された情報である。ここで、時刻認証局3による暗号化は、公開鍵暗号方式の秘密鍵を用いた暗号化である。
また、時刻証明情報取得部23は、第2の要求内容情報を時刻認証局3へ送信し、この送信に応じて時刻認証局3から送信された、第2のデマンドレスポンス要求に対して時刻認証局3が発行した時刻第2の時刻証明情報を時刻認証局3から取得する。この取得は、例えば、判定部26により、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送でないと判定された場合に行われる。
本実施形態において、第2の時刻証明情報は、一例として、第2のデマンドレスポンス要求に対して時刻認証局3が発行した時刻に加えて、第2の要求内容情報の値も含む。具体的な一例として、第2の時刻証明情報は、第2の要求内容情報の値と第2のデマンドレスポンス要求を前記時刻認証局3が発行した時刻とを含む情報が、時刻認証局3によって暗号化された情報である。
記憶処理部24は、第1のデマンドレスポンス要求に関連づけて第1の時刻証明情報(例えば、図2のトークン)を記憶装置25に記憶させるための処理を実行する。具体的には例えば、記憶処理部24は、第1のデマンドレスポンス要求が通信部21により受信された場合、第1の要求内容情報(例えば、図2の第1のハッシュ値)と第1の時刻証明情報(例えば、図2のトークン)とを関連づけて、記憶装置25に記憶させる。
ここで、複数の送信サーバや受信サーバが存在する場合を考慮して、例えば、送信サーバを識別する送信サーバIDと受信サーバを識別する受信サーバIDも合わせて記憶される。送信サーバIDは、送信サーバ毎に固有の値であり、受信サーバIDは、受信サーバ毎に固有の値である。また、有効期限も合わせて記憶されてもよい。記憶処理部24は、有効期限が切れた情報を削除する。これにより、記憶する情報が増え続けることを避けられる。有効期限の決め方は様々である。例えば、DR要求にて指定されるDR対象期間の終了時刻を、有効期限としてもよい。
図5は、記憶装置25に記録される情報の一例を示す図である。図5のテーブルT1において、送信サーバID、受信サーバID、ハッシュ値、トークン、有効期限の組が示されている。例えば、送信サーバIDが「send.server1」で、受信サーバIDが「recv.server1」で、ハッシュ値が「38a7d9f87e1」で、トークンが「x93hpc」で、有効期限が「2014-04-02T16:00:00」である。
図3において、判定部26は、通信部21が受信したDR要求が、再送されたものであるか否か判定する。例えば、判定部26は、第2のデマンドレスポンス要求(例えば、図2の再送のDR要求)が通信部21により受信された場合、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送であるか否かを判定する。
具体的には例えば、判定部26は、第2の要求内容情報(例えば、図2のハッシュ値)と同じ要求内容情報(例えば、ハッシュ値)が、記憶装置25に記憶されているか否か判定することにより、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送であるか否かを判定する。判定部26は、第2の要求内容情報(例えば、図2のハッシュ値)と同じ要求内容情報(例えば、ハッシュ値)が、記憶装置25に記憶されていれば、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送であると判定する。
このように、定義情報が抽出され、この定義情報が整形されることで、初回送信時のハッシュ値hash(format(初回送信時のDR要求))と再送時のハッシュ値hash(format(再送時のDR要求))とが等しくなるため、このような再送判定が可能となる。
本実施形態では、以下の事項を考慮して、判定部26の再送判定にハッシュ値を使うものとして説明する。まず、元データの大きさによらず、ハッシュ値は固定長さとなるため、ハッシュ値を使うと記憶に必要な容量や、比較に必要な計算量が少なくなるという利点がある。また、時刻認証局3からトークンを取得するためにハッシュ値を計算するので、余計な計算を増やすことにはならないという利点がある。
なお、判定部26は、ハッシュ値の代わりに、ハッシュ値の元データ、すなわち整形後の定義情報同士を比較して、再送判定してもよい。また、判定部26は、ハッシュ値の代わりに、DR要求同士を比較して、再送判定してもよい。
制御部27は、判定部26により再送であると判定された場合、第2のデマンドレスポンス要求と記憶装置25に記憶された第1の時刻証明情報とを、通信部21から受信サーバ4へ送信させる。具体的には例えば、第2の要求内容情報が記憶装置25に記憶されていると判定部26により判定された場合、制御部27は、第2の要求内容情報と同じ要求内容情報に対応する第1の時刻証明情報を記憶装置25から読み出し、読み出した第1の時刻証明情報を、通信部21から受信サーバ4へ送信させる。
一方、判定部26により再送でないと判定された場合、制御部27は、時刻証明情報取得部23が取得した第2の時刻証明情報と第2のデマンドレスポンス要求とを、通信部21から受信サーバ4へ送信させる。
ここで、制御部27は、トークン付加部271を備える。トークン付加部271は、例えば、HTTPリクエストまたはHTTPレスポンスにトークンを付加する。例えば、トークン付加部271は、判定部26により再送であると判定された場合、DR要求と第1の時刻証明情報とをHTTPリクエストに付加する。そして、制御部27は、付加後のHTTPリクエストを、通信部21から受信サーバ4へ送信させる。一方、判定部26により再送でないと判定された場合、トークン付加部271は、DR要求と第2の時刻証明情報とをHTTPリクエストに付加する。そして、制御部は、付加後のHTTPリクエストを、通信部21から受信サーバ4へ送信させる。ここで、具体的なトークンの付加方法は、DRプロトコルによって決定される。
続いて、図3を用いて、送信サーバ1の構成について説明する。図3に示すように、送信サーバ1は、通信部11、DR要求記憶部12、再送実施部13、生成部14、送信時刻確認部15、及び制御部16を備える。
通信部11は、通信網5を介して転送サーバ2と通信する。
DR要求記憶部12は、受信サーバ4に送信するDR要求を記憶する。
再送実施部13は、再送条件を満たす場合、DR要求の再送処理を行う。再送条件は、例えば、一定時間が経過しても、転送サーバからHTTP(Hypertext Transfer Protocol)レスポンスが返されない場合や、一定時間が経過しても、DR転送サーバからXMPP(Extensible Messaging and Presence Protocol)のIQ resultが返されない場合や、またはDR要求に対するDR応答が転送されてこない場合である。
生成部14は、転送サーバ2の生成部2と同様に、デマンドレスポンス要求から、このデマンドレスポンス要求を識別する要求内容情報を生成する。ここで、生成部14は、定義情報抽出部141、整形部142、及びハッシュ値計算部143を備える。
定義情報抽出部141は、転送サーバ2の定義情報抽出部221と同様に、通信部11が受信したDR要求から、DR要求を定義する情報の集まりである定義情報を抽出する。
整形部142は、転送サーバ2の整形部222と同様に、定義情報抽出部141が抽出した定義情報を整形する。
ハッシュ値計算部143は、転送サーバ2のハッシュ値計算部223と同様に、DR要求、または整形部142により整形された定義情報を入力として、ハッシュ値を計算する。
送信時刻確認部15は、送信したDR要求に対して発行されたタイムスタンプを取得する。具体的には、送信時刻確認部15は、このDR要求について時刻認証局3により発行されたトークンを転送サーバ2から取得し、取得したトークンを時刻認証局3から予め配布された公開鍵で復号することにより、タイムスタンプを取得する。
そして、送信時刻確認部15は、DR契約の規定に基づき、DR要求の有効/無効を判断する。例えば、送信時刻確認部15は、DR要求に対して時刻認証局3が発行した時刻がDR対象期間の開始時刻より所定の時間以上前であれば、有効とし、所定の時間未満であれば、無効とする。なお、DR要求が無効になった場合、送信時刻確認部15は、別のDR要求を送信するなどの対策を取ってもよい。
制御部16は、通信部11の通信、及びDR要求記憶部12への読み書きを制御する。
続いて、図3を用いて、受信サーバ4の構成について説明する。図3に示すように、受信サーバ4は、通信部41、制御実施部42、生成部43、及び送信時刻確認部44を備える。
通信部41は、通信網5を介して転送サーバ4と通信する。
制御実施部42は、通信部41が受信したDR要求に基づいて、機器(例えば、エアコンなど)の制御を行う。
生成部43は、転送サーバ2の生成部2と同様に、デマンドレスポンス要求から、このデマンドレスポンス要求を識別する要求内容情報を生成する。ここで、生成部43は、定義情報抽出部431、整形部432、及びハッシュ値計算部433を備える。
定義情報抽出部431は、転送サーバ2の定義情報抽出部221と同様に、通信部41が受信したDR要求から、DR要求を定義する情報の集まりである定義情報を抽出する。
整形部432は、転送サーバ2の整形部222と同様に、定義情報抽出部431が抽出した定義情報を整形する。
ハッシュ値計算部433は、転送サーバ2のハッシュ値計算部223と同様に、DR要求、または整形部432により整形された定義情報を入力として、ハッシュ値を計算する。
送信時刻確認部44は、送信サーバ1の送信時刻確認部15と同様に、受信したDR要求に対して発行されたタイムスタンプを取得する。そして、送信時刻確認部44は、DR契約の規定に基づき、DR要求の有効/無効を確認する。DR要求が有効である場合のみ、制御実施部42による機器制御を行ってもよい。
<初回のDR要求に対して時刻認証局3が発行した時刻を伝送する処理例>
続いて、図6を用いて、初回のDR要求に対して時刻認証局3が発行した時刻を伝送する処理を説明する。図6は、初回のDR要求に対して時刻認証局3が発行した時刻を伝送する処理の一例を示すフローチャートである。
(ステップS101)まず、制御部27は、通信部21がDR要求を受信したか否か判定する。通信部21がDR要求を受信していない場合、制御部27はそのまま待機する。
(ステップS102)ステップS101で通信部21がDR要求を受信した場合、定義情報抽出部221は、通信部21が受信したDR要求から定義情報を抽出する。
(ステップS103)次に、整形部222は、ステップS102で抽出された定義情報を整形する。これにより、format(DR要求)が生成される。
(ステップS104)次に、ハッシュ値計算部223は、整形後の定義情報のハッシュ値を計算する。これにより、hash(format(DR要求))が得られる。
(ステップS105)次に、判定部26は、ステップS104で計算されたハッシュ値と同じハッシュ値が記憶装置25に保存されているか否か判定する。具体的には、判定部26は、送信サーバIDと、受信サーバIDと、ハッシュ値hash(format(DR要求))の三つが一致する情報が記憶装置25に保存されているか否か判定する。三つが一致する情報が記憶装置25に保存されていれば、再送であるので、処理がステップS106に進む。一方、三つが一致する情報が記憶装置25に保存されていなかれば、再送でないので、処理がステップS107に進む。ここで、送信サーバIDと、受信サーバIDは、DR要求内に指定されているIDを使ってもよいし、IPアドレスやHTTPのURLを使ってもよい。
(ステップS106)ステップS105で、計算されたハッシュ値と同じハッシュ値が記憶装置25内に保存されていると判定された場合、ステップS101で受信されたDR要求は再送であるので、制御部27は、記憶装置25からステップS104で計算されたハッシュ値に対応するトークンを読み出す。このトークンは、「初回送信時刻」の証明に使用する。その後、処理がステップS110に進む。
(ステップS107)ステップS105で、計算されたハッシュ値と同じハッシュ値が記憶装置25内に保存されていないと判定された場合、ステップS101で受信されたDR要求は初回の送信であるので、制御部27は、ステップS104で計算されたハッシュ値を、通信部21から時刻認証局3へ送信する。
(ステップS108)次に、通信部21は、時刻認証局3からトークンを受信する。このトークンも同様に、「初回送信時刻」の証明に使用する。
(ステップS109)次に、記憶処理部24は、ステップS104で計算されたハッシュ値と、ステップS108で受信されたトークンとを関連づけて記憶装置25に保存する。その後、処理がステップS110に進む。
(ステップS110)次に、制御部27は、ステップS106またはステップS108で取得されたトークンと、ステップS101で受信されたDR要求とを受信サーバ4へ送信する。その後、処理がステップS101に戻る。
以上、第1の実施形態に係る転送サーバ2は、第1のデマンドレスポンス要求と第2のデマンドレスポンス要求を送信サーバ1から受信する通信部21を備える。転送サーバ2は、第1のデマンドレスポンス要求から、第1のデマンドレスポンス要求の内容を表す第1の要求内容情報を生成する生成部22を備える。転送サーバ2は、第1の要求内容情報を時刻認証局3へ送信し、この送信に応じて時刻認証局3から送信された、第1のデマンドレスポンス要求に対して時刻認証局3が発行した時刻を含む第1の時刻証明情報を取得する時刻証明情報取得部を備える。転送サーバ2は、第1の要求内容情報と第1の時刻証明情報とを関連づけて記憶装置25に記憶させるための処理を実行する記憶処理部24を備える。転送サーバ2は、第2のデマンドレスポンス要求が通信部21により受信された場合、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送であるか否かを判定する判定部26を備える。転送サーバ2は、判定部26により再送であると判定された場合、第2のデマンドレスポンス要求と記憶装置25に記憶された第1の時刻証明情報とを、通信部21から受信サーバ4へ送信させる制御部27を備える。
これにより、転送サーバ2は、再送のDR要求を受信した場合、初回のDR要求に対して時刻認証局3が発行した時刻を含む第1の時刻証明情報を受信サーバ4へ送信することができる。第1の時刻証明情報は時刻認証局3が発行したものであるので、DR要求を再送する場合であっても、信頼できる初回のDR要求の時刻を受信サーバ4へ提供することができる。
また、本実施形態に係る転送サーバ2の生成部22は、受信したDR要求から定義情報を抽出し、抽出した定義情報を整形し、整形後の定義情報のハッシュ値を計算した。これにより、DR要求の初回送信時とDR要求の再送時とでハッシュ値が同じになるので、ハッシュ値を比較することによって、受信したDR要求が再送であるか否かを判定することができる。
(第2の実施形態)
続いて、第2の実施形態について説明する。第1の実施形態では、初回のDR要求に対して時刻認証局3が発行した時刻を伝送する処理例について説明した。それに対し、第2の実施形態では、初回のDR要求と再送のDR要求に対して時刻認証局3が発行した時刻を伝送する処理例について説明する。なお、第2の実施形態における情報システム10の構成は、第1の実施形態における情報処理システム10の構成と同一であるので、その説明を省略する。
以下、サーバ同士はHTTPを使って連携するという前提で、各処理を説明する。まず、図7を用いて、転送サーバ2の処理を説明する。図7は、初回のDR要求と再送のDR要求に対して時刻認証局3が発行した時刻を伝送する処理の一例を示すフローチャートである。
(ステップS201)制御部27は、通信部21がDR要求を受信したか否か判定する。例えば、通信部21が、DR要求が付加されたHTTPリクエストを送信サーバ1から受信した場合、制御部27は、通信部21がDR要求を受信したと判定する。
(ステップS202)ステップS201で通信部21がDR要求を受信した場合、ハッシュ値計算部223は、このDR要求のハッシュ値Aを計算する。これにより、ハッシュ値Aとしてhash(DR要求)が得られる。
(ステップS203)次に、時刻証明情報取得部23は、DR要求のハッシュ値Aに対するトークンaを取得するため、DR要求のハッシュ値Aを時刻認証局3へ送信する。
(ステップS204)そして、時刻証明情報取得部23は、トークンaを時刻認証局3から取得する。このトークンaはtoken(hash(DR要求), ts(hash(DR要求)))と表され、「DR要求の再送時刻」の証明に使用する。
(ステップS205)次に、定義情報抽出部221は、通信部21が受信したDR要求から定義情報を抽出する。
(ステップS206)次に、整形部222は、抽出された定義情報を整形する。これにより、format(DR要求)が生成される。
(ステップS207)次に、ハッシュ値計算部223は、整形後の定義情報からハッシュ値Bを計算する。これにより、ハッシュ値Bとして、hash(format(DR要求))が得られる。
(ステップS208)次に、判定部26は、ハッシュ値Bと同じハッシュ値の情報が記憶装置25に保存されているか否か判定する。例えば、判定部26は、送信サーバIDと、受信サーバIDと、ハッシュ値Bの三つが一致する情報が記憶装置25に保存されているか否か判定する。この情報が記憶装置25に保存されていれば、DR要求は再送であり、この情報が記憶装置25に保存されていなければ、DR要求は、初回の送信である。ここで、DR送信サーバIDと、DR受信サーバIDは、DR要求内に指定されているIDを使ってもよいし、IPアドレスやHTTPのURLを使ってもよい。
(ステップS209)ステップS208でハッシュ値Bと同じハッシュ値の情報が記憶装置25に保存されていると判定された場合、DR要求は再送であるので、記憶装置25から、このハッシュ値Bに対応するトークンcを読み出す。その後、処理がステップS210に進む。このトークンcは、DR要求を初回に受信したときに取得して記憶装置25に保存されたトークンであり、「初回送信時刻」の証明に使用する。
(ステップS210)次に、トークン付加部271は、HTTPレスポンスにトークンaとトークンcを付加する。但し、トークン付加部271は、トークンaとトークンcを区別できるように付加する。例えば、ヘッダ部に付加するのであれば、図8に示すように、ヘッダのフィールド名を分ける。
図8は、HTTPヘッダ部に付加されたトークンの一例である。図8の行L1には、トークンaのフィールド名「X-DR-request-token」と、トークンaの値「HLK241HLPFJS」が示されている。また、その次の行L2には、トークンcのフィールド名「X-format-DR-request-token」と、トークンcの値「QOF893PEKFSD」が示されている。
(ステップS211)次に、トークン付加部271は、転送用のHTTPリクエストに、DR要求、トークンa、及びトークンcを付加する。その際、付加する場所は、HTTPヘッダ部でもよいし、HTTPボディでもよい。但し、トークン付加部271は、トークンaとトークンcを区別できるように付加する。
(ステップS212)ステップS208でハッシュ値Bと同じハッシュ値の情報が記憶装置25に保存されていると判定されていない場合、DR要求は初回の送信であるので、制御部27は、通信部21から時刻認証局3へハッシュ値Bを送信する。
(ステップS213)次に、通信部21は、ステップS212におけるハッシュBの送信に応じて、時刻認証局3から送信されたトークンbを受信する。このトークンbは、token(hash(format(DR要求)), ts(hash(format(DR要求))))と表される。
(ステップS214)次に、記憶処理部24は、ステップS207で計算されたハッシュ値Bと時刻認証局3から得たトークンbとを関連づけて記憶装置25に記録する。記憶処理部24は、送信サーバIDと、受信サーバIDも、合わせて記憶装置25に記録する。これにより、DR要求の再送時に、ハッシュ値Bを用いてトークンbを記憶装置25から読み出すことができる。
(ステップS215)次に、トークン付加部271は、HTTPレスポンスにトークンaとトークンbを付加する。その際、付加する場所は、HTTPヘッダ部でもよいし、HTTPボディでもよい。但し、トークン付加部271は、トークンaとトークンbを区別できるように付加する。例えば、ヘッダ部に付加するのであれば、図8に示すように、ヘッダのフィールド名を分ける。
(ステップS216)次に、トークン付加部271は、転送用のHTTPリクエストに、DR要求、トークンa、及びトークンbを付加する。その際、付加する場所は、HTTPヘッダ部でもよいし、HTTPボディでもよい。但し、トークン付加部271は、トークンaとトークンbを区別できるように付加する。
(ステップS217)次に、通信部21は、トークンが付加されたHTTPレスポンスを、送信サーバ1に送信する。
(ステップS218)次に、通信部21は、転送用のHTTPリクエストを、受信サーバ4へ送信する。
このように、転送サーバ2は、再送のDR要求を受信した場合、この受信したDR要求に対して時刻認証局3が発行したトークンaを取得し、DR要求の初回送信時に時刻認証局3が発行したトークンcを取得する。ここで、トークンaには、時刻認証局3が発行した再送時刻が含まれ、トークンcには、時刻認証局3が発行した初回送信時刻が含まれている。そして、転送サーバ2は、取得したトークンaとトークンcを送信サーバ1と受信サーバ4へ送信する。これにより、送信サーバ1と受信サーバ4は、時刻認証局3が発行した初回送信時刻及び再送時刻を取得することができる。
続いて、送信サーバ1がDR要求を送信する処理について図9を用いて説明する。図9は、送信サーバ1がDR要求を送信する処理の一例を示すフローチャートである。
(ステップS301)まず、送信サーバ1は、DR要求を登録する。具体的には、DR要求記憶部12は、登録対象のDR要求を記憶する。DR要求の登録方法は、運用者がDR要求の登録を送信サーバ1に指示する方法や、送信サーバ1内のプログラムが自動的に登録する方法がある。
(ステップS302)ステップS301でDR要求が登録されたら、制御部16は、HTTPリクエストに、DR要求記憶部12に記録されたDR要求を付加する。付加する場所は、HTTPリクエストのヘッダ部でもよいし、ボディ部でもよい。そして、通信部11は、転送サーバ2に、DR要求が付加されたHTTPリクエストを送信する。
(ステップS303)次に、再送実施部13は、再送実施するか否か判定する。再送実施部13が再送実施すると判定した場合、ステップS302に戻って、DR要求が付加されたHTTPリクエストを再送する。
(ステップS304)ステップS303で再送実施部13が再送実施しないと判定された場合、送信時刻確認部15は、通信部11が、転送サーバ2から返信されるHTTPレスポンスを受信したか否か判定する。HTTPレスポンスには、上述したトークンaとトークンbまたはcが付加されている。通信部11が転送サーバ2から返信されるHTTPレスポンスを受信していない場合、ステップS303に戻って、再送実施部13は、再度、再送実施するか否か決定する。
(ステップS305)ステップS304で通信部11が転送サーバ2から返信されるHTTPレスポンスを受信した場合、送信時刻確認部15は、時刻認証局3から予め配布された公開鍵で、上述したトークンaとトークンbまたはcを復号する。この結果、送信時刻確認部15は、トークンaから[hash(DR要求), ts(hash(DR要求))]の組を得る。また、送信時刻確認部15は、トークンbまたはcから[hash(format(DR要求)), ts(hash(format(DR要求)))]の組を得る。復号に失敗した場合は、時刻認証局3が発行したトークンではない可能性があるため、以降の処理は行わない。
(ステップS306)次に、生成部14は、ステップS302で送信済みのDR要求について、ハッシュ値を計算する。具体的には、生成部14は、DR要求のハッシュ値hash(DR要求)を計算し、DR情報に含まれる定義情報を整形し、整形後の定義情報のハッシュ値hash(format(DR要求))を計算する。ハッシュ値の計算には、定義情報抽出部141、整形部142、ハッシュ値計算部143を利用する。
(ステップS307)次に、送信時刻確認部15は、トークンaを復号して得たハッシュ値hash(DR要求)と、自身で計算したハッシュ値hash(DR要求)とを、比較する。値が一致すれば、送信時刻確認部15は、トークンaを復号して得たタイムスタンプts(hash(DR要求))を、DR要求の再送時刻として取得する。すなわち、このタイムスタンプts(hash(DR要求))が示す時刻で、DR要求が再送されたという証明になる。一致しなければ、タイムスタンプts(hash(DR要求))は信頼できないため、以降の処理は行わない。
(ステップS308)次に、送信時刻確認部15は、トークンbまたはcを復号して得たハッシュ値hash(format(DR要求))と、自身で計算したハッシュ値hash(formt(DR要求))とを、比較する。値が一致すれば、送信時刻確認部15は、トークンbまたはcを復号して得たタイムスタンプts(hash(format(DR要求)))を、DR要求の初回送信時刻として取得する。すなわち、このタイムスタンプts(hash(format(DR要求)))が示す時刻で、初回のDR要求が送信されたという証明になる。一致しなければ、タイムスタンプts(hash(format(DR要求)))は信頼できないため、以降の処理は行わない。
(ステップS309)次に、送信時刻確認部15は、取得した再送時刻と、取得した初回送信時刻と、DR契約に基づいて、DR要求の有効/無効を判断する。無効になった場合は、送信時刻確認部15は、運用者にメールなどで無効になった旨を通知してもよい。
このように、DR要求を再送する場合であっても、送信サーバ1は、DR要求の初回送信時刻を取得することができる。また、送信サーバ1は、DR要求の再送時刻も取得することができる。そして、送信時刻確認部15は、取得した再送時刻と取得した初回送信時刻とを用いて、DR要求の有効/無効を判断することができる。
続いて、受信サーバ4が、DR要求を受信する処理について図10を用いて説明する。図10は、受信サーバ4がDR要求を受信する処理の一例を示すフローチャートである。
(ステップS401)まず通信部41は、HTTPリクエストを受信する。HTTPリクエストには、上述したDR要求とトークンaとトークンbまたはcとが付加されている。
(ステップS402)次に、図9のステップS305と同様に、送信時刻確認部44は、時刻認証局3から予め配布された公開鍵で、上述したトークンaとトークンbまたはcを復号する。この結果、送信時刻確認部44は、トークンaから[hash(DR要求), ts(hash(DR要求))]の組を得る。また、送信時刻確認部44は、トークンbまたはcから[hash(format(DR要求)), ts(hash(format(DR要求)))]の組を得る。復号に失敗した場合は、時刻認証局3が発行したトークンではない可能性があるため、以降の処理は行わない。
(ステップS403)次に、図9のステップS306と同様に、生成部43は、ステップS401で受信済みのDR要求について、ハッシュ値を計算する。具体的には、生成部43は、DR要求のハッシュ値hash(DR要求)を計算し、DR情報に含まれる定義情報を整形し、整形後の定義情報のハッシュ値hash(format(DR要求))を計算する。ハッシュ値の計算には、定義情報抽出部431、整形部432、ハッシュ値計算部433を利用する。
(ステップS404)次に、図9のステップS307と同様に、送信時刻確認部44は、トークンaを復号して得たハッシュ値hash(DR要求)と、自身で計算したハッシュ値hash(DR要求)とを、比較する。値が一致すれば、送信時刻確認部44は、トークンaを復号して得たタイムスタンプts(hash(DR要求))を、DR要求の再送時刻として取得する。すなわち、このタイムスタンプts(hash(DR要求))が示す時刻で、DR要求が再送されたという証明になる。一致しなければ、タイムスタンプts(hash(DR要求))は信頼できないため、以降の処理は行わない。
(ステップS405)次に、図9のステップS308と同様に、送信時刻確認部44は、トークンbまたはcを復号して得たハッシュ値hash(format(DR要求))と、自身で計算したハッシュ値hash(formt(DR要求))とを、比較する。値が一致すれば、送信時刻確認部44は、トークンbを復号して得たタイムスタンプts(hash(format(DR要求)))は、DR要求の初回送信時刻として取得する。すなわち、このタイムスタンプts(hash(format(DR要求)))が示す時刻で、初回のDR要求が送信されたという証明になる。一致しなければ、タイムスタンプts(hash(format(DR要求)))は信頼できないため、以降の処理は行わない。
(ステップS406)次に、送信時刻確認部44は、取得した再送時刻と、取得した初回送信時刻と、DR契約とに基づいて、DR要求の有効/無効を判断する。有効の場合、制御実施部42は、DR対象期間に機器(例えば、エアコン)の停止などの消費電力量を低減させる処理を行う。無効の場合、制御実施部42は、機器制御を行わなくてもよい。
このように、DR要求を再送する場合であっても、受信サーバ4は、DR要求の初回送信時刻を取得することができる。また、受信サーバ4は、DR要求の再送時刻も取得することができる。そして、送信時刻確認部44は、取得した再送時刻と取得した初回送信時刻とを用いて、DR要求の有効/無効を判断することができる。DR要求が有効であると判断された場合、制御実施部42は、DR対象期間に、消費電力量を低減させる処理を行う。その結果、DR要求を再送する場合であっても、DR要求が有効であれば、デマンドレスポンス要求に答えて、消費電力量を低減させることができる。
DRプロトコルによっては、DR要求を転送サーバ2から受信した受信サーバ4が、転送サーバ2を介して送信サーバ1へ、DR応答を返す場合がある。DR契約によっては、DR応答の送信時刻(以下、DR応答送信時刻)を用いて、DR要求の有効/無効を判定する場合もある。よって、DR応答送信時刻を証明することが、重要な場合もある。以下、図11を用いて、DR応答に対して時刻認証局3が発行した時刻を含むトークンとともにDR応答を転送する処理の流れを説明する。図11は、転送サーバ2がDR応答を転送する処理の流れの一例を示すフローチャートである。なお、図11の処理は、図6のステップS110で転送サーバ2がDR要求を受信サーバ4へ送信した後の処理である。
(ステップS501)まず、通信部21は、受信サーバ4から、HTTPリクエストを受信する。HTTPリクエストには、DR要求に対するDR応答が付加されている。
(ステップS502)次に、ハッシュ値計算部223は、このDR応答のハッシュ値hash(DR応答)を計算する。
(ステップS503)次に、時刻証明情報取得部23は、ステップS502で計算されたハッシュ値hash(DR応答)を時刻認証局3に通信部21から送信させ、トークンtoken(hash(DR応答), ts(hash(DR応答)))を時刻認証局3から通信により取得する。ここで、トークンtoken(hash(DR応答), ts(hash(DR応答)))は、ハッシュ値hash(DR応答)と、タイムスタンプts(hash(DR応答))を秘密鍵で暗号化したものである。また、タイムスタンプts(hash(DR応答))は、時刻認証局3が発行したタイムスタンプであり、DR応答送信時刻を表す。
(ステップS504)次に、トークン付加部271は、ステップS503で取得したトークンtoken(hash(DR応答), ts(hash(DR応答)))を、HTTPレスポンスに付加する。
(ステップS505)次に、通信部21は、HTTPレスポンスを、受信サーバ4に返信する。受信サーバ4は、HTTPレスポンスに付加されたトークンを、時刻認証局3から予め配布された公開鍵で復号することにより、DR応答送信時刻を取得することができる。
(ステップS506)次に、トークン付加部271は、DR応答と、トークンtoken(hash(DR応答), ts(hash(DR応答)))を、転送用のHTTPリクエストに付加する。
(ステップS507)次に、通信部21は、転送用のHTTPリクエストを、送信サーバ1へ送信する。送信サーバ1は、HTTPリクエストに付加されたトークンtoken(hash(DR応答), ts(hash(DR応答)))を、時刻認証局3から予め配布された公開鍵で復号することにより、DR応答送信時刻を確認することができる。
このように、転送サーバ2は、DR応答を受信した場合、時刻認証局3が発行したDR応答送信時刻を含むトークンを時刻認証局3から取得し、取得したトークンを送信サーバ1と受信サーバ4へ送信する。これにより、転送サーバ2は、送信サーバ1と受信サーバ4に対して、信頼できるDR応答送信時刻を提供することができる。
以上、第2の実施形態に係る転送サーバ2において、第2のデマンドレスポンス要求が通信部21により受信された場合、生成部22は、第2のデマンドレスポンス要求から、第2のデマンドレスポンス要求の内容を表す第2の要求内容情報(例えば、第2のハッシュ値)を抽出する。そして、時刻証明情報取得部23は、第2の要求内容情報(例えば、第2のハッシュ値)を含む信号を通信部21から時刻認証局3へ送信させ、第2のデマンドレスポンス要求を時刻認証局3が発行した時刻を含む第2の時刻証明情報(例えば、トークンa)を、時刻認証局3から取得する。そして、判定部26により再送であると判定された場合、制御部27は、第1の時刻証明情報(例えば、トークンc)に加えて、第2の時刻証明情報(例えば、トークンa)を、通信部21から送信サーバ1へ送信させる。
これにより、転送サーバ2は、再送のDR要求を受信した場合、初回のDR要求に対して時刻認証局3が発行した時刻を含む第1の時刻証明情報と、この再送のDR要求に対して時刻認証局3が発行した時刻を含む第2の時刻証明情報を受信サーバ4へ送信することができる。第1の時刻証明情報及び第2の時刻証明情報は時刻認証局3が発行したものであるので、DR要求を再送する場合であっても、信頼できるDR要求の初回送信時刻及び信頼できる再送時刻を受信サーバ4へ提供することができる。
本実施形態では、転送サーバ2が、トークンをHTTPリクエストやHTTPレスポンスに付加する方法を説明したが、これに限ったものではない。必要に応じて、送信サーバ1や受信サーバ4が、転送サーバ2に、トークンを要求する方法でもよい。例えば、転送サーバ2が、Webサーバを稼働させて、Webサーバ上でトークンを公開すれば、転送サーバ2にトークンを要求する方法を容易に実現できる。
また、転送サーバ2は、DR要求やDR応答の転送に失敗した場合に、転送を再試行してもよい。また、転送サーバ2は、転送に失敗した場合に、転送に失敗した旨を、送信サーバ1や受信サーバ4に通知してもよい。
(第3の実施形態)
続いて、第3の実施形態について説明する。第1の実施形態及び第2の実施形態では、時刻認証局3が発行したトークンを転送サーバ2が記憶した。それに対し、第3の実施形態は、時刻認証局3が発行したトークンを送信サーバ1が記憶する点で、第1の実施形態及び第2の実施形態とは異なる。
まず、第3の実施形態におけるDR要求の転送処理の概要について図12を用いて説明する。図12は、第3の実施形態におけるDR要求の転送処理の一例を示すシーケンス図である。
T211の処理は、図2のT11の処理と同じであるので、その説明を省略する。T221の処理は、図2のT21の処理と同じであるので、その説明を省略する。
(T222)転送サーバ2bは、T211で送信されたDR要求が再送であるか否か判定する。具体的には、転送サーバ2bは、DR要求とともにトークンを受信したか否か判定することにより再送であるか否か判定する。ここでは、DR要求とともにトークンを受信していないので、再送でない、すなわち初回の送信であると判定する。
T223の処理は、図2のT23の処理と同じであるので、その説明を省略する。T231〜T232の処理は、図2のT31〜T32の処理と同じであるので、その説明を省略する。
(T224)転送サーバ2bは、T221で計算した第1のハッシュ値と、時刻認証局3から取得したトークンとを送信サーバ1bへ送信する。
(T212)次に、送信サーバ1bは、転送サーバ2bから受信した第1のハッシュ値とトークンとを関連づけて記憶する。
(T225)次に、転送サーバ2bが、DR要求とトークンを受信サーバ4へ向けて送信する。しかし、この送信の途中で障害(転送エラー)が発生した場合を想定する。
(T213)次に、送信サーバ1bは、転送エラーの発生を検出すると、DR要求を転送サーバ2bへ再送する。その再送の際、送信サーバ1bは、トークンも一緒に転送サーバ2bへ送信する。
(T226)次に、転送サーバ2bは、再送されたDR要求からこのDR要求を定義する定義情報を抽出し、この定義情報を所定のフォーマットに合致するように整形し、整形後の定義情報のハッシュ値である第2のハッシュ値を計算する。
(T227)次に、転送サーバ2bは、T213で送信されたDR要求が再送であるか否か判定する。具体的には、転送サーバ2bは、DR要求とともにトークンを受信したか否か判定することにより再送であるか否か判定する。ここでは、DR要求とともにトークンを受信したので、再送であると判定する。
T228の処理は、図2のT29の処理と同じであるので、その説明を省略する。T241〜T243の処理は、図2のT41〜T43の処理と同じであるので、その説明を省略する。
図13は、第3の実施形態における情報処理システム10bの構成を示す概略ブロック図である。なお、図13において図3の要素と共通する要素には同一の符号を付し、その具体的な説明を省略する。第3の実施形態における情報処理システム10bの構成は、第1の実施形態における情報処理システム10の構成に対して、送信サーバ1が送信サーバ1bに変更され、転送サーバ2が転送サーバ2bに変更されたものになっている。
(送信サーバ1bの構成)
続いて、送信サーバ1bの構成について説明する。
送信サーバ1bは、第1の実施形態の送信サーバ1に比べて、更に記憶装置17を備える点、通信部11が通信部11bに変更された点、再送実施部13が再送実施部13bに変更された点、制御部16が制御部16bに変更された点が異なっている。
通信部11bは、第1の実施形態における通信部11と同様の機能を有するが、更に以下の機能を有する。通信部11bは、デマンドレスポンス要求を第1の通信装置へ送信し、この送信に応じて、このデマンドレスポンス要求に対して時刻認証局3が発行した時刻を含む時刻証明情報(例えば、トークン)を転送サーバ2bから取得する。
制御部16bは、第1の実施形態における制御部16と同様の機能を有するが、更に以下の機能を有する。制御部16bは、通信部11bが受信した時刻証明情報(例えば、トークン)を記憶装置17に記憶させる。
再送実施部13bは、第1の実施形態における再送実施部13と同様の機能を有するが、以下の点で異なっている。再送実施部13bは、デマンドレスポンス要求の再送を実施すると決定した場合、記憶装置17に記憶された時刻証明情報を読み出し、読み出した時刻証明情報をデマンドレスポンス要求とともに、通信部11bから転送サーバ2bへ送信させる。
転送サーバ2bは、第1の実施形態の転送サーバ2に比べて、記憶装置25を有さない点、更に検証部28を有する点、記憶処理部24が記憶処理部24bに変更された点、判定部26が判定部26bに変更された点が異なっている。
記憶処理部24bは、第1のデマンドレスポンス要求が通信部21により受信された場合、送信サーバ1bが第1の要求内容情報(例えば、ハッシュ値)と第1の時刻証明情報(例えば、トークン)とを関連づけて記憶装置17に記憶させるために、第1の要求内容情報と第1の時刻証明情報とを送信サーバ1bへ送信する。
判定部26bは、通信部21が受信した第2のデマンドレスポンス要求に第1の時刻証明情報が付加されているか否か判定することにより、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送であるか否かを判定する。
第2のデマンドレスポンス要求に第1の時刻証明情報が付加されている場合、制御部27は、付加されている第1の時刻証明情報を、通信部21から受信サーバ4へ送信させる。一方、第2のデマンドレスポンス要求に第1の時刻証明情報が付加されていない場合、第2のデマンドレスポンス要求に対して時刻認証局3が発行した時刻を含む第2の時刻証明情報を、通信部21から受信サーバ4へ送信させる。ここで、第2の時刻証明情報は、時刻証明情報取得部23が、第2の要求内容情報(例えば、第2のハッシュ値)を時刻認証局3へ送信し、この送信に応じて前記時刻認証局から取得したものである。
生成部22は、第2のデマンドレスポンス要求が通信部21により受信された場合、第2のデマンドレスポンス要求から、第2のデマンドレスポンス要求の内容を表す第2の要求内容情報(例えば、第2のハッシュ値)を抽出する。
検証部28は、送信サーバ1bから取得した第1の時刻証明情報(例えば、トークン)が正しいか否かを検証する。例えば、検証部28は、受信された第2のデマンドレスポンス要求に付加されている第1の時刻証明情報と、第2の要求内容情報(例えば、第2のハッシュ値)とを用いて、第1の時刻証明情報が正しいか否か検証する。具体的には例えば、検証部28は、この第1の時刻証明情報を時刻認証局3から予め配布された公開鍵で復号し、復号した値と、第2の要求内容情報(例えば、第2のハッシュ値)とを比較することにより、第1の時刻証明情報が正しいか否か検証する。
続いて、DR要求の初回送信時刻を証明するための処理について、図14を用いて説明する。図14は、DR要求の初回送信時刻を証明するための処理の一例を示すフローチャートである。ステップS601〜S604は、図6のステップS101〜S104と同一であるので、その説明を省略する。
(ステップS605)判定部26bは、DR要求とともにトークンを受信したか否かを判定する。
(ステップS606)ステップS605でDR要求とともにトークンを受信したと判定された場合、検証部28は、受信したトークンを時刻認証局3から予め配布された公開鍵で復号する。
(ステップS607)次に、検証部28は、復号して得られたハッシュ値と、ステップS604で算出されたハッシュ値が一致するか否か判定する。復号して得られたハッシュ値と、ステップS604で算出されたハッシュ値が一致しない場合、処理がステップS601に戻る。復号して得られたハッシュ値と、ステップS604で算出されたハッシュ値が一致する場合、処理がステップS611に進む。
(ステップS608)ステップS605でDR要求とともにトークンを受信していないと判定された場合、通信部21は、ステップS604で算出されたハッシュ値を時刻認証局3へ送信する。これにより、時刻認証局3は、タイムスタンプを発行し、発行したタイムスタンプとこのハッシュ値とを秘密鍵で暗号化したトークンを生成する。
(ステップS609)次に、通信部21は、時刻認証局3からトークンを受信する。
(ステップS610)次に、通信部21は、ステップS604で算出したハッシュ値と、ステップS608で時刻認証局3から受信したトークンとを送信サーバ1bへ送信する。その後、処理がステップS611に進む。
(ステップS611)次に、通信部21は、送信サーバ1bまたは時刻認証局3から取得されたトークンと、ステップS601で受信されたDR要求とを受信サーバ4へ送信する。その後、処理がステップS101に戻る。
このように、判定部26bは、DR要求とともにトークンを受信したか否かを判定する。DR要求とともにトークンを受信したと判定された場合、受信されたDR要求は再送であるので、通信部21は、このトークンとDR要求とを受信サーバ4へ送信する。一方、DR要求とともにトークンを受信していないと判定された場合、受信されたDR要求は初回の送信であるので、通信部21は、時刻認証局3からトークンを取得する。通信部21は、このトークンとDR要求とを受信サーバ4へ送信する。
これにより、トークンは、初回のDR要求に対して時刻認証局3が発行したタイムスタンプが含まれているので、転送サーバ2bは、信頼できる初回送信時刻を受信サーバ4へ提供することができる。
以上、第3の実施形態に係る転送サーバ2bにおいて、記憶処理部24bは、第1のデマンドレスポンス要求が通信部21により受信された場合、第1の通信装置が第1の要求内容情報と第1の時刻証明情報とを関連づけて記憶装置17に記憶させるために、第1の要求内容情報と第1の時刻証明情報とを送信サーバ1bへ送信する。判定部26bは、通信部21が受信した第2のデマンドレスポンス要求に第1の時刻証明情報が付加されているか否か判定することにより、第2のデマンドレスポンス要求が第1のデマンドレスポンス要求の再送であるか否かを判定する。第2のデマンドレスポンス要求に第1の時刻証明情報が付加されている場合、制御部27は、付加されている第1の時刻証明情報を、通信部21から受信サーバ4へ送信させる。
これにより、転送サーバ2bは、再送のDR要求を受信した場合、初回のDR要求に対して時刻認証局3が発行した時刻を含む第1の時刻証明情報を受信サーバ4へ送信することができる。第1の時刻証明情報は時刻認証局3が発行したものであるので、DR要求を再送する場合であっても、信頼できるDR要求の初回送信時刻を受信サーバ4へ提供することができる。
(第4の実施形態)
続いて、第4の実施形態について説明する。第3の実施形態では、DR要求の初回送信時刻のみを証明するための処理例について説明した。それに対し、第4の実施形態では、DR要求の初回送信時刻及び再送時刻の両方を証明するための処理例について説明する。なお、第4の実施形態における情報システム10bの構成は、第3の実施形態における情報処理システム10bの構成と同一であるので、その説明を省略する。
まず、図15を用いて、転送サーバ2bの処理を説明する。図15は、第4の実施形態における、DR要求の初回送信時刻と再送送信時刻の両方を証明するための処理の一例を示すフローチャートである。ステップS701〜S707の処理は、図7のステップS201〜S207の処理と同一であるので、その説明を省略する。
(ステップS708)次に、判定部26bは、DR要求とともにトークンcを受信したか否か判定する。
(ステップS709)ステップS708で、DR要求とともにトークンcを受信したと判定された場合、再送であるので、検証部28は、受信されたトークンcを、時刻認証局3から予め配布された公開鍵で復号する。
(ステップS710)検証部28は、復号して得られたハッシュ値と、ステップS707で計算されたハッシュ値Bとが一致するか否か判定する。復号して得られたハッシュ値と、ステップS707で計算されたハッシュ値Bとが一致しないと判定された場合、処理がステップS701に戻る。
(ステップS711)ステップS710で復号して得られたハッシュ値とステップS707で計算されたハッシュ値Bとが一致すると判定された場合、DR要求は再送であるので、トークン付加部271は、HTTPレスポンスにトークンaとトークンcを付加する。なお、付加する場所は、HTTPヘッダ部であっても、HTTPボディであってもよい。二つのトークンを区別できるように付加すればよい。
(ステップS712)次に、トークン付加部271は、HTTPリクエストにDR要求、トークンa、及びトークンcを付加する。その後、処理がステップS717に進む。なお、付加する場所は、HTTPヘッダ部であっても、HTTPボディであってもよい。二つのトークンを区別できるように付加すればよい。
(ステップS713)ステップS708で、DR要求とともにトークンcを受信していないと判定された場合、DR要求は初回の送信であるので、制御部27は、通信部21から時刻認証局3へハッシュ値Bを送信する。
(ステップS714)次に、通信部21は、ステップS210におけるハッシュBの送信に応じて、時刻認証局3から送信されたトークンbを受信する。このトークンbは、token(hash(format(DR要求)), ts(hash(format(DR要求))))と表される。
(ステップS715)次に、トークン付加部271は、HTTPレスポンスにトークンaとトークンbを付加する。なお、付加する場所は、HTTPヘッダ部であっても、HTTPボディであってもよい。二つのトークンを区別できるように付加すればよい。
(ステップS716)次に、トークン付加部271は、HTTPリクエストにDR要求、トークンa、及びトークンbを付加する。なお、付加する場所は、HTTPヘッダ部であっても、HTTPボディであってもよい。二つのトークンを区別できるように付加すればよい。
ステップS717及びS718の処理は,図7のステップS217及びS218の処理と同一であるので、その説明を省略する。
このように、転送サーバ2bは、再送のDR要求を受信した場合、この受信したDR要求に対して時刻認証局3が発行したトークンaを取得し、DR要求の初回送信時に時刻認証局3が発行したトークンcを取得する。ここで、トークンaには、時刻認証局3が発行した再送時刻が含まれ、トークンcには、時刻認証局3が発行した初回送信時刻が含まれている。そして、転送サーバ2bは、取得したトークンaとトークンcを送信サーバ1bと受信サーバ4へ送信する。これにより、送信サーバ1bと受信サーバ4は、時刻認証局3が発行した初回送信時刻及び再送時刻を取得することができる。
続いて、送信サーバ1bがDR要求を送信する処理について図16を用いて説明する。図16は、送信サーバ1bがDR要求を送信する処理の一例を示すフローチャートである。ステップS801〜S802の処理は、図9のステップS301〜S302の処理と同一であるので、その説明を省略する。
(ステップS803)次に、再送実施部13bは、再送実施するか否か判定する。
(ステップS810)ステップS803で再送実施部13bにより再送実施すると判定された場合、制御部16bは、HTTPリクエストに、DR要求記憶部12に記録されたDR要求とトークンを付加する。付加する場所は、HTTPリクエストのヘッダ部でもよいし、ボディ部でもよい。付加するトークンは、DR要求の初回送信時に転送サーバ2bから返されたトークンである。このトークンは記憶装置17に記録されているはずであり、DR要求のハッシュ値hash(format(DR要求))を計算することで求められる。そして、通信部11bは、転送サーバ2bに、DR要求とトークンが付加されたHTTPリクエストを送信する。
ステップS804〜S809の処理は、図9のステップS304〜S309の処理と同一であるので、その説明を省略する。
このように、再送実施部13bにより再送実施すると判定された場合、制御部16bは、HTTPリクエストに、DR要求記憶部12に記録されたDR要求とトークンを付加する。そして、通信部11bは、転送サーバ2bに、DR要求とトークンが付加されたHTTPリクエストを送信する。これにより、転送サーバ2bは、DR要求とともにトークンを受信した場合、そのDR要求が再送であると判定することができる。
以上、第4の実施形態に係る転送サーバ2bにおいて、第2のデマンドレスポンス要求が通信部21により受信された場合、生成部22は、第2のデマンドレスポンス要求から、第2のデマンドレスポンス要求の内容を表す第2の要求内容情報(例えば、第2のハッシュ値)を抽出する。そして、時刻証明情報取得部23は、第2の要求内容情報(例えば、第2のハッシュ値)を含む信号を通信部21から時刻認証局3へ送信させ、第2のデマンドレスポンス要求に対して時刻認証局3が発行した時刻を含む第2の時刻証明情報(例えば、トークンa)を、時刻認証局3から取得する。
そして、判定部26により第2のデマンドレスポンス要求とともに第1の時刻証明情報(例えば、トークンc)を受信したか否か判定する。判定部26により第2のデマンドレスポンス要求とともに第1の時刻証明情報(例えば、トークンc)を受信したと判定された場合、制御部27は、第1の時刻証明情報(例えば、トークンc)に加えて、第2の時刻証明情報(例えば、トークンa)を、通信部21から送信サーバ1bへ送信させる。
これにより、転送サーバ2bは、再送のDR要求を受信した場合、初回のDR要求に対して時刻認証局3が発行した時刻を含む第1の時刻証明情報と、この再送のDR要求に対して時刻認証局3が発行した時刻を含む第2の時刻証明情報を受信サーバ4へ送信することができる。第1の時刻証明情報及び第2の時刻証明情報は時刻認証局3が発行したものであるので、DR要求を再送する場合であっても、転送サーバ2bは、信頼できるDR要求の初回送信時刻及び信頼できる再送時刻を受信サーバ4へ提供することができる。
なお、各実施形態において、送信サーバ1または1bと、転送サーバ2または2bとは、別々の装置として説明したが、これに限らず、一体の情報処理装置として構成されてもよい。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
1 送信サーバ(第1の通信装置)
2 転送サーバ(情報処理装置)
3 時刻認証局
4 受信サーバ(第2の通信装置)
5 通信網
10 情報処理システム
11、11b、21、41 通信部
12 DR要求記憶部
13、13b 再送実施部
14、22、43 生成部
141、221、431 定義情報抽出部
142、222、432 整形部
143、223、433 ハッシュ値計算部
15、44 送信時刻確認部
16、16b、27 制御部
17、25 記憶装置
23 時刻証明情報取得部
24 記憶処理部
26 判定部
42 制御実施部

Claims (16)

  1. 第1のデマンドレスポンス要求を第1の通信装置から受信し、前記第1のデマンドレスポンス要求の受信後に、第2のデマンドレスポンス要求を前記第1の通信装置から受信する通信部と、
    前記第1のデマンドレスポンス要求から、前記第1のデマンドレスポンス要求の内容を表す第1の要求内容情報を生成する生成部と、
    前記第1の要求内容情報を時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第1のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第1の時刻証明情報を取得する時刻証明情報取得部と、
    前記第1のデマンドレスポンス要求に関連づけて前記第1の時刻証明情報を記憶装置に記憶させるための処理を実行する記憶処理部と、
    前記第2のデマンドレスポンス要求が前記通信部により受信された場合、前記第2のデマンドレスポンス要求が前記第1のデマンドレスポンス要求の再送であるか否かを判定する判定部と、
    前記判定部により再送であると判定された場合、前記第2のデマンドレスポンス要求と、前記記憶装置において前記第1のデマンドレスポンス要求に関連づけられた前記第1の時刻証明情報とを、前記通信部から第2の通信装置へ送信させる制御部と、
    を備える情報処理装置。
  2. 前記生成部は、前記第2のデマンドレスポンス要求から、前記第2のデマンドレスポンス要求の内容を表す第2の要求内容情報を生成し、
    前記時刻証明情報取得部は、前記第2の要求内容情報を前記時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第2のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第2の時刻証明情報を取得し、
    前記判定部により再送でないと判定された場合、前記制御部は、前記時刻証明情報取得部が取得した第2の時刻証明情報と前記第2のデマンドレスポンス要求とを、前記通信部から前記第2の通信装置へ送信させる
    請求項1に記載の情報処理装置。
  3. 前記第1の時刻証明情報は、前記第1のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含むに加えて、前記第1の要求内容情報の値も含む
    請求項1または2に記載の情報処理装置。
  4. 前記第1の時刻証明情報は、前記第1の要求内容情報の値と前記第1のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻とを含む情報が、前記時刻認証局によって暗号化された情報である
    請求項3に記載の情報処理装置。
  5. 前記第2の時刻証明情報は、前記第2のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻に加えて、前記第2の要求内容情報の値も含む
    請求項2に記載の情報処理装置。
  6. 前記第2の時刻証明情報は、前記第2の要求内容情報の値と前記第2のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻とを含む情報が、前記時刻認証局によって暗号化された情報である
    請求項5に記載の情報処理装置。
  7. 前記時刻認証局による暗号化は、公開鍵暗号方式の秘密鍵を用いた暗号化である
    請求項4または6に記載の情報処理装置。
  8. 前記記憶処理部は、前記第1のデマンドレスポンス要求が前記通信部により受信された場合、前記第1の要求内容情報と前記第1の時刻証明情報とを関連づけて、記憶装置に記憶させ、
    前記第2のデマンドレスポンス要求が前記通信部により受信された場合、前記生成部は、前記第2のデマンドレスポンス要求から、前記第2のデマンドレスポンス要求を識別する第2の要求内容情報を生成し、
    前記判定部は、前記第2の要求内容情報と同じ要求内容情報が、前記記憶装置に記憶されているか否か判定することにより、前記第2のデマンドレスポンス要求が前記第1のデマンドレスポンス要求の再送であるか否かを判定し、
    前記第2の要求内容情報と同じ要求内容情報が前記記憶装置に記憶されていると前記判定部により判定された場合、前記制御部は、前記第2の要求内容情報と同じ要求内容情報に対応する前記第1の時刻証明情報を前記記憶装置から読み出し、読み出した前記第1の時刻証明情報を、前記通信部から前記第2の通信装置へ送信させる
    請求項1から7のいずれか一項に記載の情報処理装置。
  9. 前記記憶処理部は、前記第1のデマンドレスポンス要求が前記通信部により受信された場合、前記第1の通信装置が前記第1の要求内容情報と前記第1の時刻証明情報とを関連づけて前記記憶装置に記憶させるために、前記第1の要求内容情報と第1の時刻証明情報とを前記第1の通信装置へ送信し、
    前記判定部は、前記通信部が受信した前記第2のデマンドレスポンス要求に前記第1の時刻証明情報が付加されているか否か判定することにより、前記第2のデマンドレスポンス要求が前記第1のデマンドレスポンス要求の再送であるか否かを判定し、
    前記第2のデマンドレスポンス要求に前記第1の時刻証明情報が付加されている場合、前記制御部は、前記付加されている前記第1の時刻証明情報を、前記通信部から前記第2の通信装置へ送信させる
    請求項1から7のいずれか一項に記載の情報処理装置。
  10. 前記生成部は、前記第2のデマンドレスポンス要求が前記通信部により受信された場合、前記第2のデマンドレスポンス要求から、前記第2のデマンドレスポンス要求を識別する第2の要求内容情報を抽出し、
    前記付加されている前記第1の時刻証明情報と、前記第2の要求内容情報とを用いて、前記第1の時刻証明情報が正しいか否か検証する検証部を更に備える
    請求項9に記載の情報処理装置。
  11. 前記検証部は、前記付加されている前記第1の時刻証明情報を前記時刻認証局から配布された公開鍵で復号し、復号した値と、前記第2の要求内容情報とを比較することにより、前記第1の時刻証明情報が正しいか否か検証する
    請求項10に記載の情報処理装置。
  12. 前記第2のデマンドレスポンス要求が前記通信部により受信された場合、
    前記生成部は、前記第2のデマンドレスポンス要求から、前記第2のデマンドレスポンス要求の内容を表す第2の要求内容情報を抽出し、
    前記時刻証明情報取得部は、前記第2の要求内容情報を含む信号を前記通信部から時刻認証局へ送信させ、前記第2のデマンドレスポンス要求に対して時刻認証局が発行した時刻を含む第3の時刻証明情報を、前記時刻認証局から取得し、
    前記判定部により再送であると判定された場合、前記制御部は、前記第1の時刻証明情報に加えて、前記第3の時刻証明情報を、前記通信部から第2の通信装置へ送信させる
    請求項1から11のいずれか一項に記載の情報処理装置。
  13. 前記生成部は、
    前記第1のデマンドレスポンス要求を定義する第1の定義情報と、前記第2のデマンドレスポンス要求を定義する第2の定義情報を抽出する定義情報抽出部と、
    前記第1の定義情報と前記第2の定義情報を整形する整形部と、
    前記整形された第1の定義情報のハッシュ値を前記第1の要求内容情報として計算し、前記整形された第2の定義情報のハッシュ値を前記第2の要求内容情報として計算するハッシュ値計算部と、
    を備える請求項1から12のいずれか一項に記載の情報処理装置。
  14. 前記定義情報抽出部は、デマンドレスポンスのプロトコルに応じて、抽出する情報を変更し、
    前記整形部は、デマンドレスポンスのプロトコルに応じて、整形する方法を変更する
    請求項13に記載の情報処理装置。
  15. 通信装置と通信する通信部と、
    第1のデマンドレスポンス要求を前記通信部から前記通信装置へ送信する場合、前記第1のデマンドレスポンス要求から、前記第1のデマンドレスポンス要求の内容を表す第1の要求内容情報を生成する生成部と、
    前記第1の要求内容情報を時刻認証局へ送信し、この送信に応じて前記時刻認証局から送信された、前記第1のデマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む第1の時刻証明情報を取得する時刻証明情報取得部と、
    前記第1のデマンドレスポンス要求に関連づけて前記第1の時刻証明情報を記憶装置に記憶させるための処理を実行する記憶処理部と、
    前記第1のデマンドレスポンス要求より後に前記通信装置へ送信される第2のデマンドレスポンス要求が前記第1のデマンドレスポンス要求の再送であるか否かを判定する判定部と、
    前記判定部により再送であると判定された場合、前記第2のデマンドレスポンス要求と前記記憶装置において前記第1のデマンドレスポンス要求に関連づけられた前記第1の時刻証明情報とを、前記通信部から前記通信装置へ送信させる制御部と、
    を有する情報処理装置。
  16. デマンドレスポンス要求を情報処理装置へ送信し、この送信に応じて、前記デマンドレスポンス要求に対して前記時刻認証局が発行した時刻を含む時刻証明情報を前記情報処理装置から取得する通信部と、
    前記通信部が受信した時刻証明情報を記憶装置に記憶させる制御部と、
    前記デマンドレスポンス要求の再送を実施すると決定した場合、前記記憶装置に記憶された時刻証明情報を読み出し、前記読み出した時刻証明情報を前記デマンドレスポンス要求とともに、前記通信部から前記他の通信装置へ送信させる再送実施部と、
    を備える通信装置。
JP2014170785A 2014-08-25 2014-08-25 情報処理装置及び通信装置 Active JP6219248B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014170785A JP6219248B2 (ja) 2014-08-25 2014-08-25 情報処理装置及び通信装置
US14/833,662 US9985754B2 (en) 2014-08-25 2015-08-24 Information processing apparatus and communication device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014170785A JP6219248B2 (ja) 2014-08-25 2014-08-25 情報処理装置及び通信装置

Publications (2)

Publication Number Publication Date
JP2016046724A true JP2016046724A (ja) 2016-04-04
JP6219248B2 JP6219248B2 (ja) 2017-10-25

Family

ID=55349217

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014170785A Active JP6219248B2 (ja) 2014-08-25 2014-08-25 情報処理装置及び通信装置

Country Status (2)

Country Link
US (1) US9985754B2 (ja)
JP (1) JP6219248B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019121369A (ja) * 2017-12-28 2019-07-22 トヨタ自動車株式会社 支援装置、支援方法、プログラムおよび支援システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005101883A (ja) * 2003-09-25 2005-04-14 Hitachi Ltd 電子メール文書原本性保証装置
US20050198170A1 (en) * 2003-12-12 2005-09-08 Lemay Michael Secure electronic message transport protocol
US20070027821A1 (en) * 2005-07-27 2007-02-01 Mitsubishi Denki Kabushiki Kaisha Method for controlling the delivery of a flow of items to at least a client of an item provider
US20140046836A1 (en) * 2012-08-10 2014-02-13 Kabushiki Kaisha Toshiba Information communication system, method thereof, and computer readable medium

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6367013B1 (en) * 1995-01-17 2002-04-02 Eoriginal Inc. System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents
CN100452072C (zh) * 1995-02-13 2009-01-14 英特特拉斯特技术公司 用于管理在第一装置和第二装置之间的数字文档的分布的方法
US8380630B2 (en) * 2000-07-06 2013-02-19 David Paul Felsher Information record infrastructure, system and method
AU2001287164B2 (en) * 2000-08-04 2008-06-26 First Data Corporation Method and system for using electronic communications for an electronic contact
US7096354B2 (en) * 2000-08-04 2006-08-22 First Data Corporation Central key authority database in an ABDS system
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
JP5102880B2 (ja) 2006-08-22 2012-12-19 セイコープレシジョン株式会社 タイムスタンプ付加装置、タイムスタンプ付加方法、電子メール中継サーバ及びコンピュータプログラム
KR101544629B1 (ko) * 2008-02-19 2015-08-17 인터디지탈 패튼 홀딩스, 인크 안전하고 신뢰성있는 시간 기술을 위한 방법 및 장치
US20150012974A1 (en) * 2013-07-06 2015-01-08 Newvoicemedia, Ltd. System and methods for tamper proof interaction recording and timestamping

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005101883A (ja) * 2003-09-25 2005-04-14 Hitachi Ltd 電子メール文書原本性保証装置
US20050102499A1 (en) * 2003-09-25 2005-05-12 Masayuki Kosuga Apparatus for proving original document of electronic mail
US20050198170A1 (en) * 2003-12-12 2005-09-08 Lemay Michael Secure electronic message transport protocol
US20070027821A1 (en) * 2005-07-27 2007-02-01 Mitsubishi Denki Kabushiki Kaisha Method for controlling the delivery of a flow of items to at least a client of an item provider
JP2007109209A (ja) * 2005-07-27 2007-04-26 Mitsubishi Electric Information Technology Centre Europa Bv 分配ネットワークを介する供給を制御する方法及び装置、供給を検査する装置、装置によって送信される信号並びにコンピュータプログラム
US20140046836A1 (en) * 2012-08-10 2014-02-13 Kabushiki Kaisha Toshiba Information communication system, method thereof, and computer readable medium
JP2014035745A (ja) * 2012-08-10 2014-02-24 Toshiba Corp 情報通信システムおよびその方法、ならびにプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019121369A (ja) * 2017-12-28 2019-07-22 トヨタ自動車株式会社 支援装置、支援方法、プログラムおよび支援システム
US11200759B2 (en) 2017-12-28 2021-12-14 Toyota Jidosha Kabushiki Kaisha Support apparatus, support method, program, and support system

Also Published As

Publication number Publication date
JP6219248B2 (ja) 2017-10-25
US20160056925A1 (en) 2016-02-25
US9985754B2 (en) 2018-05-29

Similar Documents

Publication Publication Date Title
JP6608256B2 (ja) 電子データの存在証明プログラムおよび存在証明サーバ
JP5432999B2 (ja) 暗号鍵配布システム
US8788811B2 (en) Server-side key generation for non-token clients
US10708047B2 (en) Computer-readable recording medium storing update program and update method, and computer-readable recording medium storing management program and management method
CN107659406B (zh) 一种资源操作方法及装置
CA2748927C (en) Secure, auditable file exchange system and method
US20060059549A1 (en) Device authentication apparatus, service control apparatus, service request apparatus, device authentication method, service control method, and service request method
US20090316909A1 (en) Utilization apparatus, servicer apparatus, service utilization system, service utilization method, service utilization program, and integrated circuit
US20080031458A1 (en) System, methods, and apparatus for simplified encryption
US20060036850A1 (en) Digital certificate management system, digital certificate management apparatus, digital certificate management method, update procedure determination method and program
US11824853B2 (en) Mutual secure communications
US20110296171A1 (en) Key recovery mechanism
US20110293098A1 (en) Key recovery mechanism
JP6275302B2 (ja) 存在証明装置、存在証明方法、及びそのためのプログラム
JP2009532970A (ja) 電子データ通信システム
JP4235824B2 (ja) 暗号化装置
JP2007053569A (ja) 電子メールセキュリティ化装置及び該システム
US20100319061A1 (en) Personal information managing device, service providing device, program, personal information managing method, checking method and personal information checking system for falsification prevention of personal information and non repudiation of personal information circulation
CN106330529B (zh) 具有通信日志记录的听力设备和相关方法
KR20110083886A (ko) 휴대용 단말기에서 다른 휴대용 단말기를 인증하는 장치 및 방법
CN109992286A (zh) 设备升级方法、服务器及计算机可读存储介质
US20100316218A1 (en) Personal information managing device for falsification prevention of personal information and non repudiation of personal information circulation
GB2381717A (en) system and method , for secure data transmission, which includes generating a hash key using a character string and a private key
JP6219248B2 (ja) 情報処理装置及び通信装置
KR102462411B1 (ko) 전자 신원확인 및 인증 서비스(eidas)를 위한 전자 공고를 인증하는 플랫폼 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160914

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170614

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170623

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170817

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170829

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170927

R151 Written notification of patent or utility model registration

Ref document number: 6219248

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151