(57)【要約】【課題】管理・開示コストを削減可能な、署名管理プログラム、署名管理方法及び署名管理装置を提供する。【解決手段】原動画情報のシーケンスヘッダＳＨを、ストリーミングデータ再生に必要なストリームヘッダ情報ＳＨ−Ｇと、ユーザが自由に格納できるユーザヘッダ情報ＳＨ−Ｕに区分する。原動画情報を部分情報ＧＯＰで分割し、各部分情報ＧＯＰのハッシュ情報を生成し、これらハッシュ情報の集まりを用いてひとつのルートハッシュ情報を作成し、このルートハッシュ情報に対して署名者の電子署名を作成し、ルートハッシュ情報と電子署名を合わせて署名者のＰＩＡＴ署名情報とする。ＰＩＡＴ署名情報内にスタートコードが現れないよう、ＰＩＡＴ署名情報生成後に１バイト置きに任意の値を埋め込んで原動画情報のシーケンスヘッダＳＨのユーザヘッダ情報ＳＨ−Ｕ内にＰＩＡＴ署名情報を格納する。【選択図】図１７
2011061815.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークで接続された、署名生成サーバと情報抽出サーバと署名検証サーバを含むシステムにより、ストリーミングデータの部分切り出しに対する署名管理を行う署名管理方法であって、
前記署名生成サーバが、署名者端末より指示を受信し、ストリーミングデータに対する第１の署名関連情報を作成するステップと、
前記署名生成サーバが、ストリーミングデータのシーケンスヘッダを、ストリーミングデータ再生に必要なストリームヘッダ情報と、ユーザが自由に格納できるユーザヘッダ情報とに区分し、署名関連情報が格納されていることを示すスタートコード値をユーザヘッダ情報の終端に追加するとともに、該ユーザヘッダ情報内に前記第１の署名関連情報格納位置を表すスタートコード値と前記第１の署名関連情報を順に格納するステップと、
前記署名生成サーバが、前記署名関連情報が格納されていることを示すスタートコード値、前記第１の署名関連情報格納位置を表すスタートコード値、及び前記第１の署名関連情報が格納されたユーザヘッダ情報を含むシーケンスヘッダが付加されたストリーミングデータを情報抽出サーバに送信するステップと、
前記情報抽出サーバが、前記署名生成サーバが送信したストリーミングデータを受信して第１の文書管理データベースに蓄積するステップと、
前記情報抽出サーバが、抽出者端末の指示を受信し、その指示に基づいて、前記第１の文書管理データベースからユーザヘッダ情報を含むシーケンスヘッダが付加されたストリーミングデータを取り出し、前記抽出者端末に送信するステップと、
前記情報抽出サーバが、前記抽出者端末より、前記送信したストリーミングデータの一部を切り出した部分データを受信し、該部分データに対する第２の署名関連情報を作成するステップと、
前記情報抽出サーバが、前記部分データのシーケンスヘッダとして、前記取り出されたストリーミングデータのシーケンスヘッダのユーザヘッダ情報内の前記第１の署名関連情報の後に、前記第２の署名関連情報の格納位置を表すスタートコード値と前記第２の署名関連情報とを続けて追加格納したものを生成するステップと、
前記情報抽出サーバが、前記署名関連情報が格納されていることを示すスタートコード値、前記第１の署名関連情報格納位置を表すスタートコード値、前記第１の署名関連情報、前記第２の署名関連情報の格納位置を表すスタートコード値、及び前記第２の署名関連情報とが格納されたユーザヘッダ情報を含むシーケンスヘッダが付加された部分データを署名検証サーバに送信するステップと、
前記署名検証サーバが、前記情報抽出サーバが送信した部分データを受信して第２の文書管理データベースに蓄積するステップと、
前記署名検証サーバが、検証者端末より指示を受信し、前記第２の文書管理データベースに蓄積された部分データについて、前記署名関連情報が格納されていることを示すスタートコード値、前記第１の署名関連情報格納位置を表すスタートコード値、及び前記第２の署名関連情報の格納位置を表すスタートコード値を基に取り出された前記第１の署名関連情報と前記第２の署名関連情報に基づいて検証を行い、検証結果を前記検証者端末に送信するステップと、
を実行することを特徴とする署名管理方法。
【請求項２】
前記署名生成サーバが生成する第１の署名関連情報、及び前記情報抽出サーバが生成する第２の署名関連情報は、それぞれの署名関連情報に所定の埋め込みコード値を格納していくことでスタートコードが現れない形の署名関連情報として作成されており、
前記第１の署名関連情報、及び前記第２の署名関連情報を、前記署名検証サーバが検証を行うに際し、前記埋め込みコード値を取り除いた情報を基に検証処理が行われることを特徴とする請求項１記載の署名管理方法。
【請求項３】
ユーザヘッダ情報を含めて原本性対象とする場合には、前記署名生成サーバは、ストリームヘッダ情報とユーザヘッダ情報を有するシーケンスヘッダまで含めて前記第１の署名関連情報を生成することを特徴とする請求項１または請求項２に記載の署名管理方法。
【請求項４】
ユーザヘッダ情報を原本性対象としない場合には、前記署名生成サーバは、ユーザヘッダ情報を除いたシーケンスヘッダを含めて前記第１の署名関連情報を生成することを特徴とする請求項１または請求項２に記載の署名管理方法。
【請求項５】
ストリーミングデータの部分切り出しに対する署名管理を行う署名管理システムであって、
署名者端末より指示を受信し、ストリーミングデータに対する第１の署名関連情報を作成し、ストリーミングデータのシーケンスヘッダを、ストリーミングデータ再生に必要なストリームヘッダ情報と、ユーザが自由に格納できるユーザヘッダ情報とに区分し、署名関連情報が格納されていることを示すスタートコード値をユーザヘッダ情報の終端に追加するとともに、該ユーザヘッダ情報内に前記第１の署名関連情報格納位置を表すスタートコード値と前記第１の署名関連情報を順に格納し、前記署名関連情報が格納されていることを示すスタートコード値、前記第１の署名関連情報格納位置を表すスタートコード値、及び前記第１の署名関連情報が格納されたユーザヘッダ情報を含むシーケンスヘッダが付加されたストリーミングデータを送信する署名生成サーバと、
前記署名生成サーバが送信したストリーミングデータを受信して第１の文書管理データベースに蓄積し、抽出者端末の指示を受信し、その指示に基づいて、前記第１の文書管理データベースからユーザヘッダ情報を含むシーケンスヘッダが付加されたストリーミングデータを取り出し、前記抽出者端末に送信し、前記抽出者端末より、前記送信したストリーミングデータの一部を切り出した部分データを受信し、該部分データに対する第２の署名関連情報を作成し、前記部分データのシーケンスヘッダとして、前記取り出されたストリーミングデータのシーケンスヘッダのユーザヘッダ情報内の前記第１の署名関連情報の後に、前記第２の署名関連情報の格納位置を表すスタートコード値と前記第２の署名関連情報とを続けて追加格納したものを生成し、前記署名関連情報が格納されていることを示すスタートコード値、前記第１の署名関連情報格納位置を表すスタートコード値、前記第１の署名関連情報、前記第２の署名関連情報の格納位置を表すスタートコード値、及び前記第２の署名関連情報とが格納されたユーザヘッダ情報を含むシーケンスヘッダが付加された部分データを送信する情報抽出サーバと、
前記情報抽出サーバが送信した部分データを受信して第２の文書管理データベースに蓄積し、検証者端末より指示を受信し、前記第２の文書管理データベースに蓄積された部分データについて、前記署名関連情報が格納されていることを示すスタートコード値、前記第１の署名関連情報格納位置を表すスタートコード値、及び前記第２の署名関連情報の格納位置を表すスタートコード値を基に取り出された前記第１の署名関連情報と前記第２の署名関連情報に基づいて検証を行い、検証結果を前記検証者端末に送信する署名検証サーバと、
を有することを特徴とする署名管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、署名管理方法、署名管理システムに係り、特に、動画像や音声といったストリーミングデータであって、部分的に抽出（具体的には変更・抽出・墨塗り等を含む）が発生するストリーミングデータに対し、原本データからの抽出箇所の特定、ならびに、抽出したデータの正当性を担保・第三者証明可能な部分完全性保証システムに関する。
【背景技術】
【０００２】
近年、店舗や繁華街、集合住宅等での監視カメラ設置や、業務車両へのドライブレコーダ設置等が一般化し、動画像を証拠物件として取り扱う事例が増加している。また、電話による取引やサポート業務のトラブル対策として、顧客とオペレータとの会話を録音し証拠として保持することも常識となりつつある。
現在、動画像や音声を証拠とする場合、ビデオテープや画像・音声ファイルをそのまま提供している。しかし、画像・音声保存のデジタル化が進めば、それらの改ざんや編集は容易になり、証拠として取り扱う場合は署名やタイムスタンプといった第三者証明が必要となる。現に電話オペレータの音声をタイムスタンプ付で録音・記録するサービスや製品が販売されており、今後このような技術のニーズが高まることが予想される。
【０００３】
一方で、増加する監視カメラ等に対して、撮影された映像の利用に対するプライバシの保護が問題となり、総務省等で議論が行われている。
また、個人情報保護法の施行等により、個人のプライバシ情報の利用が厳しく制限され、本人の要求があれば、開示や部分的な削除等が必要である。
このような、証拠性とプライバシ保護の両立という課題に対して、電子文書の一部に対する部分的な原本性（完全性）の保証や秘匿（墨塗り）する墨塗り署名技術の研究が進んでいる。
【０００４】
特に、特許文献１には、ある文書に対して施された署名が、文書の一部を秘匿することによって検証できなくなる問題を解決する電子文書の墨塗り署名技術（以下、本技術をＰＩＡＴとする）が開示されている。このＰＩＡＴを適用することにより、署名付き電子文書に対して墨塗りを施した状態でも署名検証が可能、かつ、墨塗り（変更や追加も可能）箇所以外は改変がないことを第三者証明することが可能となる。
【０００５】
また、動画像・音声データの原本性の保証、署名対象からのプライバシ保護可能なデータ抽出、及び署名関連データの大幅なデータ量削減を実現することを目的とした、特願２００７−１２０４８号に記載のような技術がある。
更に、特願２００７−３２６８０１号のような、原本ストリームデータの一部を切り出しても、切り出したストリームデータの再生不能を回避しつつ、原本ストリームデータの一部で、かつ改変がないことを第三者に証明可能とする技術も考案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開ＷＯ２００６／００８８４７号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１では、動画像や音声のように大きなデータ（長時間の映像や音声）の一部を抽出するような場合、署名に関連する情報が非常に大きくなるという課題があった。
更に、この課題を解決した特願２００７−１２０４８号の技術では、動画像・音声データのフォーマットに着目されていないため、原本ストリームデータの一部を切り出しても、切り出したストリームデータの再生不能を回避しつつ、原本ストリームデータの一部で、かつ改変がないことを第三者に証明することが困難だった。
【０００８】
更に、この課題を解決した特願２００７−３２６８０１号の技術では、原本ストリームデータへの署名生成時、切り出しストリームデータの保存時、切り出しストリームデータの署名生成時、ストリームデータの署名検証の際、シーケンスヘッダ（ストリーミングデータ全体のシーケンス情報を格納するヘッダ）が付加されていない部分情報（ＧＯＰ）の先頭に直近のシーケンスヘッダの内容を付与し、シーケンスヘッダを含めた形でＰＩＡＴ署名情報の生成・検証を行う手段を提供している。しかしながら、これまでの特許文献１や特願２００７−１２０４８号、特願２００７−３２６８０１号では、検証情報となる署名関連情報の管理方法に課題があった。具体的には、現状、ストリーミングデータと署名関連情報は別ファイルで管理されているため、そのファイル群を管理・開示する際は、ストリーミングデータと署名関連情報の関連付けを行う必要があった。その対策として、場合によっては、原本サーバ等を用意し、管理・運用させる必要があり、コストがかかっていた。
【０００９】
この対策として、ストリーミングデータのシーケンスヘッダ内に署名関連情報を格納し、一体化させることで、上記課題を解決できるが、単純にシーケンスヘッダに格納するだけでは、格納の仕方によっては、ストリーミングデータのデコード解析（再生）ができなくなるという課題があった。
【００１０】
そこで、本発明は、このような問題点を解消するためになされたもので、管理・開示コストを削減可能な署名管理方法、署名管理システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
署名管理方法は、ネットワークで接続された、署名生成サーバと情報抽出サーバと署名検証サーバを含むシステムにより、ストリーミングデータの部分切り出しに対する署名管理を行う署名管理方法であって、署名生成サーバが、署名者端末より指示を受信し、ストリーミングデータに対する第１の署名関連情報を作成するステップと、署名生成サーバが、ストリーミングデータのシーケンスヘッダを、ストリーミングデータ再生に必要なストリームヘッダ情報と、ユーザが自由に格納できるユーザヘッダ情報とに区分し、署名関連情報が格納されていることを示すスタートコード値をユーザヘッダ情報の終端に追加するとともに、ユーザヘッダ情報内に第１の署名関連情報格納位置を表すスタートコード値と第１の署名関連情報を順に格納するステップと、署名生成サーバが、署名関連情報が格納されていることを示すスタートコード値、第１の署名関連情報格納位置を表すスタートコード値、及び第１の署名関連情報が格納されたユーザヘッダ情報を含むシーケンスヘッダが付加されたストリーミングデータを情報抽出サーバに送信するステップと、情報抽出サーバが、署名生成サーバが送信したストリーミングデータを受信して第１の文書管理データベースに蓄積するステップと、情報抽出サーバが、抽出者端末の指示を受信し、その指示に基づいて、第１の文書管理データベースからユーザヘッダ情報を含むシーケンスヘッダが付加されたストリーミングデータを取り出し、抽出者端末に送信するステップと、情報抽出サーバが、抽出者端末より、送信したストリーミングデータの一部を切り出した部分データを受信し、部分データに対する第２の署名関連情報を作成するステップと、情報抽出サーバが、部分データのシーケンスヘッダとして、取り出されたストリーミングデータのシーケンスヘッダのユーザヘッダ情報内の第１の署名関連情報の後に、第２の署名関連情報の格納位置を表すスタートコード値と第２の署名関連情報とを続けて追加格納したものを生成するステップと、情報抽出サーバが、署名関連情報が格納されていることを示すスタートコード値、第１の署名関連情報格納位置を表すスタートコード値、第１の署名関連情報、第２の署名関連情報の格納位置を表すスタートコード値、及び第２の署名関連情報とが格納されたユーザヘッダ情報を含むシーケンスヘッダが付加された部分データを署名検証サーバに送信するステップと、署名検証サーバが、情報抽出サーバが送信した部分データを受信して第２の文書管理データベースに蓄積するステップと、署名検証サーバが、検証者端末より指示を受信し、第２の文書管理データベースに蓄積された部分データについて、署名関連情報が格納されていることを示すスタートコード値、第１の署名関連情報格納位置を表すスタートコード値、及び第２の署名関連情報の格納位置を表すスタートコード値を基に取り出された第１の署名関連情報と第２の署名関連情報に基づいて検証を行い、検証結果を検証者端末に送信するステップと、を実行する。
【発明の効果】
【００１２】
この発明によれば、スタートコードが現れない形でシーケンスヘッダのユーザヘッダ情報内に署名関連情報を格納するので、ストリーミングデータのデコード解析を可能としつつ管理・開示コストを削減することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態における情報抽出証明システムのシステム構成図である。
【図２】実施の形態における認証機関サーバの構成図である。
【図３】実施の形態における署名生成サーバの構成図である。
【図４】実施の形態における情報抽出サーバの構成図である。
【図５】実施の形態における署名検証サーバの構成図である。
【図６】実施の形態における送信装置と認証機関サーバとの間での公開鍵の登録処理を示したフローチャートである。
【図７】実施の形態における電子署名付き情報の送受信処理及び受信装置の検証処理を示したフローチャートである。
【図８】ＰＩＡＴのアルゴリズムの概要を示した図である。
【図９】ＭＰＥＧ１の画像タイプとその並びの一例を示した図である。
【図１０】実施の形態におけるＭＰＥＧ１のＶｉｄｅｏフレーム構成の一例を示した図である。
【図１１】シーケンスヘッダの構造を示した図である。
【図１２】実施の形態における署名生成処理を示したフローチャートである。
【図１３】実施の形態における署名生成処理を示したフローチャートである。
【図１４】実施の形態における情報抽出処理を示したフローチャートである。
【図１５】実施の形態における情報抽出処理を示したフローチャートである。
【図１６】実施の形態における署名検証処理を示したフローチャートである。
【図１７】実施の形態における原動画情報の署名生成方法を示した図である。
【図１８】実施の形態におけるシーケンスヘッダが付加されてない場合のフレーム構成の一例を示した図である。
【図１９】実施の形態における署名者のＰＩＡＴ署名情報の内容を示した図である。
【図２０】実施の形態における原動画情報のＰＩＡＴ署名情報格納後のシーケンスヘッダの構造を示した図である。
【図２１】実施の形態の変形例における原動画情報の署名生成方法を示した図である。
【図２２】実施の形態における原動画情報の抽出操作を示した図である。
【図２３】実施の形態における切り出し動画情報の生成方法を示した図である。
【図２４】実施の形態における切り出し動画情報の署名生成方法を示した図である。
【図２５】実施の形態における抽出者のＰＩＡＴ署名情報の内容を示した図である。
【図２６】実施の形態における切り出し動画情報のＰＩＡＴ署名情報格納後のシーケンスヘッダの構造を示した図である。
【図２７】実施の形態の変形例における切り出し動画情報の署名生成方法を示した図である。
【図２８】実施の形態における検証対象の動画情報の選択画面を示した図である。
【図２９】実施の形態における切り出し動画情報の署名検証方法を示した図である。
【図３０】実施の形態の変形例における切り出し動画情報の署名検証方法を示した図である。
【図３１】実施の形態における切り出し動画情報の署名検証結果を示した図である。
【発明を実施するための形態】
【００１４】
以下、この発明の実施の形態を添付図面に基づいて説明する。
まず、本実施の形態における情報抽出証明システムの構成について図１を用いて説明する。
図１において、１はネットワークである。ただし、１は、インターネット、イントラネット、ワイドエリアネットワーク等のすべての通信回線網を含むものとする。また、２は、電子署名情報を管理する認証機関のサーバである。周知のように電子署名は、署名対象情報を要約（メッセージダイジェスト化）した情報を送信者の秘密鍵で暗号化した署名情報と署名対象情報、及び公開鍵証明書を相手方へ送信し、受信者は、公開鍵証明書の有効性確認を行った上で、暗号化された署名情報を公開鍵証明書に含まれる公開鍵で復号し、署名対象情報から得た要約情報と比較を行う。この比較結果が同一か否かによって、正当な相手からの送信か否かを判断する技術である（詳細は後述する）。
【００１５】
この技術では、証明書の正当性を保証する必要があるため、本実施の形態のように、署名者、抽出者の公開鍵を蓄積した認証機関サーバ２を設置していることが一般的である。この認証機関サーバ２は、図２に示すように、署名者、抽出者の公開鍵を蓄積した公開鍵ＤＢ２１、依頼に応じて公開鍵証明書を発行する証明書発行部２２、公開鍵証明書の検証を行う証明書検証部２３、及びネットワーク１経由での通信を行う通信手段２４を有する。
【００１６】
また、３は、署名者が処理を行う署名生成サーバである。この署名生成サーバ３は、図３に示すように、後述する情報抽出サーバ５へ送信された情報を蓄積する文書管理ＤＢ３１、文書管理ＤＢ３１へのアクセス制御を行う文書管理ＴＢ３２、情報に対して署名者のＰＩＡＴ署名情報ならびに電子署名を付加する署名生成部３３、及びネットワーク１経由での通信を行う通信手段３４を有する。
また、４は、署名者が署名生成サーバ３の操作を行うための端末である。この署名者端末４は署名生成サーバ３と通信可能である。
【００１７】
５は、情報抽出サーバである。この情報抽出サーバ５は、図４に示すように、署名生成サーバ３から送られてきた情報の蓄積及び後述する署名検証サーバ７へ送信された情報を蓄積する文書管理ＤＢ５１、文書管理ＤＢ５１へのアクセス制御を行う文書管理ＴＢ５２、情報に対して抽出者のＰＩＡＴ署名情報ならびに電子署名を付加する署名生成部５３、送られてきた情報に付される電子署名の検証を行う署名検証部５４、及びネットワーク経由で通信を行うための通信手段５５を有する。
６は、抽出者が情報抽出サーバ５の操作を行うための端末である。この抽出者端末６は情報抽出サーバ５と通信可能である。
【００１８】
７は、署名検証サーバである。この署名検証サーバ７は、図５に示すように、情報抽出サーバ５から送られてきた情報を蓄積する文書管理ＤＢ７１、文書管理ＤＢ７１へのアクセス制御を行う文書管理ＴＢ７２、送られてきた情報に付される電子署名ならびにＰＩＡＴ署名情報の検証を行う署名検証部７３、及びネットワーク経由で通信を行うための通信手段７４を有する。
８は、検証者が署名検証サーバ７の操作を行うための端末である。この検証者端末８は署名検証サーバ７と通信可能である。
なお、署名生成サーバ３の署名生成部３３及び情報抽出サーバ５の署名生成部５３により、本発明の署名関連情報作成手段と署名関連情報格納手段が構成されている。
【００１９】
以上のように構成されたシステムの処理動作について以下に説明する。
まず、電子署名処理について説明する。
電子署名においては、送信者は、予め、鍵ペア（秘密鍵及び公開鍵）を生成し、認証機関サーバ２に公開鍵を送信して公開鍵証明書を発行してもらい、送信装置に、この秘密鍵と公開鍵証明書を記憶しておく。送信装置より情報送信を行う際、まず、署名対象情報の要約情報（メッセージダイジェスト）を生成し、この要約情報に対して、送信者の秘密鍵で暗号化したものを署名情報とする。続けて、署名対象情報とこの署名情報、及び送信者の公開鍵証明書を相手方へ送信し、それを受信した相手方（受信者）は、認証機関サーバ２に対して取得した送信者の公開鍵証明書の有効性検証を行い、有効であれば、この公開鍵で署名情報の復号を行う。続けて、署名対象情報の要約を生成し、復号した情報と比較して同一であれば、真に送信者から送信されたもので改変がないことを証明できる。
ここでの要約情報とは、署名対象情報に対して暗号学的一方向性ハッシュ関数を用いて算出された情報（ハッシュ情報）であり、署名対象情報のサイズを圧縮できるという意味で、メッセージダイジェストとも言われる。また、暗号学的一方向性ハッシュ関数で生成されたハッシュ情報は、その署名対象情報からしか生成することができない唯一の情報となり、生成されたハッシュ情報から元の情報を復元することができないという特徴を持っている。このため、情報の暗号化や電子署名生成にはよく使われている。この暗号学的一方向性ハッシュ関数には、ＭＤ５、ＳＨＡ-１、ＳＨＡ-２５６のようなアルゴリズムがある。情報に対してどのアルゴリズムを用いて要約情報（ハッシュ情報）を生成しているかについての情報（ハッシュ情報生成アルゴリズム）は公開鍵証明書に記載されている。
【００２０】
電子署名生成の詳細な手順について以下に説明する。
まず、送信装置と認証機関サーバ２との間での公開鍵の登録について、図６のフローチャートを用いて説明する。
なお、図１のシステムにおいては、署名生成サーバ３及び情報抽出サーバ５が電子署名の送信装置となっている。
まず、送信者は、鍵ペア（秘密鍵及び公開鍵）の生成を行う（Ｓ１００１）。続けて、送信者は、送信装置を操作して、証明書発行依頼情報の入力を行うと（Ｓ１００２）、送信装置は、その入力された証明書発行依頼情報を公開鍵とともに認証機関サーバ２へ送信する（Ｓ１００３）。
【００２１】
この情報を通信手段２４にて受信した認証機関サーバ２の証明書発行部２２は（Ｓ１００４）、公開鍵を含む公開鍵証明書を生成し（Ｓ１００５）、公開鍵ＤＢ２１に生成した公開鍵証明書を蓄積する（Ｓ１００６）。
その後、証明書発行部２２は、通信手段２４を制御し、ネットワーク１を介し、証明書発行依頼情報を送信してきた送信装置へ、発行した公開鍵証明書を送信する（Ｓ１００７）。
この情報を受信した送信装置は（Ｓ１００８）、Ｓ１００１で生成した秘密鍵、及び認証機関サーバ２から発行された公開鍵証明書を自身が有する記憶装置（署名生成サーバ３の署名生成部３３内の記憶領域、情報抽出サーバ５の署名生成部５３内の記憶領域）に蓄積し（Ｓ１００９）、その処理を完了する。
【００２２】
次に、電子署名付き情報の送受信処理、及び受信装置の検証処理について、図７のフローチャートを用いて説明する。
まず、送信者が、ある署名対象情報に対する電子署名生成及び受信装置に対する送信指示の入力を行うと（Ｓ２００１）、送信装置は、記憶領域に記憶している秘密鍵により指示された署名対象情報の要約情報（ハッシュ情報）に対して暗号化し（Ｓ２００２）、同じく記憶している公開鍵証明書とともに受信装置へ送信する（Ｓ２００３）。
【００２３】
これらの情報を受信した受信装置は（Ｓ２００４）、まず、送られてきた公開鍵証明書の有効期限や失効情報等を確認するため、認証機関サーバ２に対して公開鍵証明書を送信する（Ｓ２００５）。ここでは、認証機関サーバ２が証明書発行・証明書検証の一連の機能をサポートしているものとする。次に、認証機関サーバ２は受信した公開鍵証明書の有効性検証を行い（Ｓ２００６）、検証結果を受信装置に対して送信する（Ｓ２００７）。この有効性検証結果を受信した受信装置は（Ｓ２００８）、公開鍵証明書が有効かどうかの確認を行い（Ｓ２００９）、有効性が確認できると、まず、送信装置から取得した送信者の公開鍵証明書に含まれるハッシュ情報生成アルゴリズムを参照し、送信装置より受信した署名対象情報からハッシュ情報を生成する（Ｓ２０１０）。続けて、公開鍵証明書に含まれる公開鍵を利用して、送信装置より受信した署名情報の復号処理を行う（Ｓ２０１１）。受信装置は、Ｓ２０１０で生成されたハッシュ情報と、Ｓ２０１１での復号処理によって得られた情報とを比較し、同一かどうかの判断を行う（Ｓ２０１２）。この判断で同一であることを確認できると、送信装置（送信者）から送られてきた情報であり、改変がないことが証明できたとして（Ｓ２０１３）、それら情報を保管する（Ｓ２０１４）。
【００２４】
一方、ハッシュ情報と復号処理によって得られた情報とが互いに異なる場合、その情報は、送信装置（送信者）からのものと証明できなかった（あるいは通信途中で改変された等）と判断し（Ｓ２０１５）、受信装置の操作者に証明できなかった旨の表示を行う等の通知処理を行う（Ｓ２０１６）。Ｓ２００９の処理で、公開鍵証明書の有効性が確認できなかった場合も同様に、送信装置（送信者）からのものと証明できなかったと判断し（Ｓ２０１５）、受信装置の操作者に証明できなかった旨の表示を行う等の通知処理を行う（Ｓ２０１６）。
【００２５】
ここで、ＰＩＡＴのアルゴリズムの概要について図８を参照して説明する。
署名者は、署名対象データを部分データに分割し、各部分データのハッシュ情報を計算して、ハッシュ情報集合を作成する。その後、作成したハッシュ情報集合に対して署名者の電子署名を行い、ハッシュ情報集合と電子署名をあわせてＰＩＡＴ署名情報とする。
抽出者は、署名者がＰＩＡＴ署名情報を施したデータから、部分データを抽出する（それ以外の部分データは消去する）。その後、署名者と同様の操作を行って、抽出者のＰＩＡＴ署名情報を作成する。
【００２６】
検証者は、まず、署名者と抽出者のＰＩＡＴ署名情報から、ハッシュ情報集合の完全性を検証する。次に、開示された部分データからハッシュ情報集合を作成し、抽出者のＰＩＡＴ署名情報に含まれるハッシュ情報集合と同一であることを検証する。最後に、署名者と抽出者のハッシュ情報集合を比較することで、ハッシュ情報が同じ部分が元のデータからの抽出位置であることがわかる。もし、抽出データのハッシュ情報が署名者のＰＩＡＴ署名情報のハッシュ情報に含まれていない場合は、その部分データは改ざんされていることになる。
【００２７】
続けて、本実施の形態で対象とするストリーミング情報について説明・定義を行う。代表的な動画フォーマットとして、ＭＰＥＧ１／２／４、音声フォーマットは、ＭＰ３（ＭＰＥＧ１・Ａｕｄｉｏ・Ｌａｙｅｒ−３）、ＷＡＶ等が存在する。この実施の形態では、ＭＰＥＧ１を対象に説明する。
ＭＰＥＧ１フォーマットには様々なものがあるが、ここでは、比較的映像が単調な動画像への適用を検討し、単純化のために、音声部分を除去したＭＰＥＧ１のＶｉｄｅｏフレームを対象とし、ＣＢＲ（Ｃｏｎｓｔａｎｔ・Ｂｉｔ・Ｒａｔｅ：固定ビットレート）方式、ＭＰＥＧ１符号化された画像のみを扱うＥＳ（Ｅｌｅｍｅｎｔａｒｙ・Ｓｔｒｅａｍ：エレメンタリストリーム）への適用を検討する。以降、対象とするフォーマットを単にＭＰＥＧ１と記述する。
【００２８】
ＭＰＥＧ１は、ＩＳＯ／ＩＥＣ・１１１７２−２で標準化されている動画像符号化技術である。動画像は、静止画像をある程度高速に表示することによって実現される。例えば、テレビジョンでは秒間３０枚程度の画像を表示しており、この毎秒表示される画像の枚数をフレームレートと呼ぶ。動画像の符号化技術では、データ量を削減するために符号化による（静止）画像圧縮と、フレーム間予測符号化による圧縮を行っている。ＭＰＥＧ１では静止画像圧縮にＤＣＴ技術、フレーム間予測に双方向予測技術を採用している。双方向予測のためにＭＰＥＧ１では、静止画像の保持方法が三タイプ存在する。図９に、ＭＰＥＧ１の画像タイプとその並びの一例を示す。
【００２９】
Ｉフレームは表示に必要な全ての画像データを圧縮して保持している。Ｐフレームはフレーム間予測画像と呼ばれ、直近にデコードされたＩフレーム、もしくはＰフレームの画像を参照画像とし、そこからの差分等の値だけを保持する。Ｂフレームは直近にデコードされた未来と過去のＩフレーム、Ｐフレームの画像を参照画像として、その差分値等を保持する。ＰフレームやＢフレームでは、前後の画像との差分をとることで、時間方向の冗長度を削除し、高いデータ圧縮を実現している。また、ＭＰＥＧ１では、図９のように何枚かの画像をまとめて、ＧＯＰ（Ｇｒｏｕｐ・ｏｆ・Ｐｉｃｔｕｒｅｓ）と呼ばれる動画像の最小単位が構成される。ＧＯＰはその単位での独立した再生が可能で、動画像を途中から再生したり編集したりするための構造である。
【００３０】
図１０に、ＭＰＥＧ１のフレーム構成の一例を示す。ＭＰＥＧ１のＶｉｄｅｏフレームは、シーケンスヘッダ（以降、ＳＨと説明）、ＧＯＰヘッダ（以降、ＧＨと説明）、ピクチャヘッダ（以降、ＰＨと説明）、ピクチャデータ（ＰＨ以下のレイヤのデータのこと、以降、ＰＤと説明）から構成される。特にＳＨは、画像の大きさを表す情報や一秒間に符号化するフレーム数、通信速度の情報等、ビデオシーケンス全体に渡る共通のパラメータを記録している。更に、図１１は、ＳＨの構造を示している。ＳＨは、図１１のＳＨ−Ｇで示す、ストリーミングデータの再生やデコード等に必要な領域（以降、ストリームヘッダ情報と説明）と、図１１のＳＨ−Ｕで示す、ユーザが自由に情報を格納できる領域（以降、ユーザヘッダ情報と説明）に分かれる。このユーザヘッダ情報はＳＨ内に含まれていなくても、ストリームヘッダ情報があればストリーミングデータの再生、デコードは可能である。また、“０ｘ０００００１”が記録される３バイトのスタートコードプリフィックス（ＳＴＡＲＴＣＯＤＥＰＲＩＦＩＸ）と、“Ｂ３”、“Ｂ２”、“Ｂ７”等が記録される１バイトのスタートコード値（ＳＴＡＲＴＣＯＤＥＶＡＬＵＥ）も格納され、このＳＴＡＲＴＣＯＤＥＰＲＩＦＩＸとＳＴＡＲＴＣＯＤＥＶＡＬＵＥを合わせて、４バイトのスタートコード（ＳＴＡＲＴＣＯＤＥ、“０ｘ０００００１ＸＸ”）と呼ばれる。
【００３１】
以下に、このスタートコードの役割を説明する。スタートコードは、ストリーミングデータを正しく解析・復号（再生）可能とするため、必ず付与するよう規格で決められている。具体的には、どのようなシンタックスに基づいて符号化されているかを示し、デコーダはこのスタートコードを基にストリーミングデータを解析している。“０ｘ０００００１ＸＸ”というビット列はスタートコードとして以外に、ビット列中に現れてはいけないと定義されており、デコーダは正規な“０ｘ０００００１ＸＸ”を見つけることで復号を開始することができる。逆に、スタートコードがなければ、ストリームが何処で分割されているのか判定できず、参照しているビット列がどのシンタックスに基づいて符号化されているか判定できないため、復号を行うことができなくなる。
【００３２】
続けて、本実施の形態におけるシステムによるＭＰＥＧ１へのＰＩＡＴ適用について、図１２〜図１６のフローチャートを用いて説明する。本実施の形態には、署名者、抽出者、検証者の３名の操作者を登場させる。対象の原動画情報に対して署名を行う署名者と、その原動画情報の抽出を行う抽出者、及び開示された切り出し動画情報の検証を行う検証者からなる。
【００３３】
また、署名者、抽出者、検証者に対して以下の条件を設ける。署名者は、署名することで署名対象の原動画情報の内容を保証する。対象の原動画情報のうちどの部分が抽出されるかわからないという条件下で署名を行う必要がある。抽出者は、署名者が署名した原動画情報から、部分的にデータを抽出して、切り出し動画情報として検証者に開示する。抽出方法には、抽出者の情報を同時に開示し、誰がその抽出処理を行ったかを明示する顕名抽出と、抽出者が抽出処理を匿名で行う匿名抽出の２種類ある。
本実施の形態では、顕名抽出を行うことを前提に説明を行う。検証者は、開示された切り出し動画情報が署名者によって保証されているかどうかを検証する。開示された切り出し動画情報は、署名者が署名をした原動画情報の一部であることに加え、その抽出が抽出者によって行われたことを検証する。なお、電子署名の処理については、各装置が上記した電子署名の手順を行うものとする。
【００３４】
図１２に示すように、署名者は、まず署名者端末４を用いて、署名対象となる原動画情報を作成する（Ｓ３００１）。原動画情報の作成が完了すると、署名生成サーバ３に対して、作成した原動画情報を送信する（Ｓ３００２）。署名生成サーバ３は、原動画情報を受信すると（Ｓ３００３）、まず、原動画情報を部分情報に分割するところから始める。ＭＰＥＧ１のデータを抽出可能なように部分データに分割する場合、フレーム間予測技術が用いられている関係上、ＰＤ単位の独立性がなく、抽出が制限されることが考えられる。そこで、本発明では、図１０のようなフレーム構成において、ＳＨを先頭とし、次のＳＨ（もしくは、ＳＨが存在しなければ、次のＧＨ）が始まる直前のＰＤまでを１ＧＯＰ（ＭＰＥＧ１の部分データ）とし、単純化のために、部分データへの分割をＧＯＰ単位とする。
【００３５】
更に、記録時間が長い動画像やフレームレートの高い（フレーム数やＧＯＰ数が多い）動画像の場合、ＰＩＡＴ署名情報に含まれるハッシュ情報集合のデータ量が増加することが考えられる。この対策として、例えば、上述した特願２００７−１２０４８号のような発明を利用することで、署名関連データ量の削減を図ることが可能である。上記を踏まえ、ＰＩＡＴアルゴリズムを適用する。なお、動画像データの抽出が目的のため、本実施の形態では、全データのうち、連続するひとつの箇所の動画像を切り出すことを前提とする。
【００３６】
署名生成部３３は、原動画情報に対するＰＩＡＴ署名情報を生成する（Ｓ３００４）。図１７は、その生成方法の様子を示している。原動画情報に対してＰＩＡＴ署名情報を生成する場合、ＳＨ内のユーザヘッダ情報（ＳＨ−Ｕ）も原本性保証の対象とするかどうかの判断により、ＰＩＡＴ署名情報の生成方法が異なる。図１７では、ユーザヘッダ情報は原本性保証対象とせず、ストリームヘッダ情報（ＳＨ−Ｇ）を原本性保証対象とした場合を示している。また、図１７のＥは、原動画情報を生成後、既に他のユーザが格納した情報を示している。
【００３７】
具体的には、まず原動画情報を部分情報（ＧＯＰ）で分割し、各ＧＯＰのハッシュ情報を計算する。この時、原動画情報のＰＩＡＴ署名情報は、検証者が原動画情報の一部であり、改変がないことを確認するための検証情報となるため、原動画情報のＰＩＡＴ署名情報に含まれるルートハッシュ情報は、全ＧＯＰにユーザヘッダ情報を除いたストリームヘッダ情報のみが付加された状態で生成される必要がある。このため、例えば、図１８のようなフレーム構成の場合、どの位置で切り出されるか原動画情報の署名時点ではわからないため、ストリームヘッダ情報が付加されていないＧＯＰには直近のストリームヘッダ情報の内容を付与し、ストリームヘッダ情報を含めた形でハッシュ情報を生成する。この時、既にＳＨが付与されているＧＯＰには、そのまま該ＳＨを含めてハッシュ情報を生成する。ただし、これらＳＨ付与は原動画情報の実体には記録されず、あくまでハッシュ情報の生成を行う際、例えば、記憶領域（メモリ等）上で付与することを意味する。更に、これらハッシュ情報の集まりを用いて、暗号システムで有名なハッシュ情報を二分木で管理する手法（以降、二分木手法とする）を使用し、ひとつのルートハッシュ情報を作成する。その後、作成したルートハッシュ情報に対して、署名者の電子署名を作成し、ルートハッシュ情報と電子署名をあわせて、署名者のＰＩＡＴ署名情報とする。
【００３８】
このようにして署名者のＰＩＡＴ署名情報の生成が完了すると、続けて、原動画情報のＳＨ−Ｕに該ＰＩＡＴ署名情報を格納する（Ｓ３００５）。図１３は、その格納方法のフローチャートを示している。まず、ユーザヘッダ情報の終端にスタートコードを追加する（Ｓ３００５／０１）。続けて、署名者のＰＩＡＴ署名情報がここから格納されていることを示す、ＰＩＡＴ署名情報スタートコード値を追加する（Ｓ３００５／０２）。この時、既に格納されている、他のユーザヘッダ情報（Ｅ）と確実に識別できるよう、重複しないユニークなスタートコード値を追加する必要がある。更に、前述のとおり、ＰＩＡＴ署名情報内にスタートコード（“０ｘ０００００１ＸＸ”）が含まれていると、誤認識により、原動画情報のデコード（再生）時にシーケンスエラーが発生する可能性がある。例えば、スタートコードプリフィックス（“０ｘ０００００１”）の後には、必ず何らかの開始を示すスタートコード値（“Ｂ３”、“Ｂ２”、“Ｂ７”等）を含んでいる必要があり、ＰＩＡＴ署名情報内に、例えば、“０ｘ０００００１ＦＦ”のような値が現れると、デコード（再生）時にシーケンスエラーを招くこととなる。このような事態を回避するため、ＰＩＡＴ署名情報内にスタートコードが現れないようにする対策が必要となる。
【００３９】
その回避対策の一例として、ＰＩＡＴ署名情報内にスタートコード（“０ｘ０００００１ＸＸ”）が現れないよう、ＰＩＡＴ署名情報生成後に、１バイト置きに“０ｘ００”でない値（“０ｘＡＡ”等、以降、ＰＩＡＴ埋め込みコード値と説明）を埋め込んで格納する方法が考えられる（Ｓ３００５／０３）。この時、ＰＩＡＴ署名情報内にスタートコードがひとつも現れなくても、自動的にＰＩＡＴ埋め込みコード値を埋め込む方法と、ＰＩＡＴ署名情報内にスタートコードが現れるかどうかを事前に判定し、必要に応じてＰＩＡＴ埋め込みコード値を埋め込む方法の２とおりの方法が考えられる。ただし、後者の場合は、どこに埋め込んだかを示すタグ等のコード値を、ＰＩＡＴ埋め込みコード値とは別の値を決定して埋め込むか、もしくは別途管理する必要がある。前者の場合は、ＰＩＡＴ署名情報量が増加する（単純計算で２倍となる）というコストがかかるものの、特願２００７−１２０４８号のような発明を利用することで、署名関連データ量の削減を図ることができる。このＰＩＡＴ埋め込みコード値の格納は、例えば、ＰＩＡＴ署名情報生成の完了後（署名者の電子署名が付加された後）に行われることが望ましい。また、このように決めた場合には、署名検証の時等、該ＰＩＡＴ署名情報を取り出して利用する場合には、ＰＩＡＴ埋め込みコード値を除いて行われることが望ましい。これについては、後述する署名検証処理で説明を行う。
【００４０】
図１９は、前者の、自動的にＰＩＡＴ埋め込みコード値を埋め込む方法を適用した、署名者のＰＩＡＴ署名情報の内容を示している。上段（ＰＩＡＴ１１）は、ＰＩＡＴ埋め込みコード値を格納する前のＰＩＡＴ署名情報を、下段（ＰＩＡＴ１２）は、ＰＩＡＴ埋め込みコード値を格納したＰＩＡＴ署名情報を示している。本実施の形態では、原動画情報に対する検証情報として、ルートハッシュ情報を記録している。ルートハッシュ情報の作成には、暗号学的一方向性ハッシュ関数として、ＭＤ５を使用しており、１６バイトの容量で記録されている様子を示している（ＨＡＳＨ１１）。また、ＳＩＧＮ１１は、検証情報（ＨＡＳＨ１１）に対する署名者の電子署名を示している。ＨＡＳＨ１１とＳＩＧＮ１１をあわせて署名者のＰＩＡＴ署名情報（ＰＩＡＴ１１）となる。このＨＡＳＨ１１とＳＩＧＮ１１は事後識別できるようにするため、タグを付けておく必要がある。
【００４１】
ＨＡＳＨ１１、ＳＩＧＮ１１では、共にスタートコード（ＸＳＴＡＲＴＣＯＤＥ）が現れてしまった例を示しており、下段（ＰＩＡＴ１２）のＰＩＡＴ署名情報では、ＨＡＳＨ１２、ＳＩＧＮ１２で示すように、デコード（再生）時にシーケンスエラーを回避するためのＰＩＡＴ埋め込みコード値（ＰＩＡＴＩＮＳＥＲＴＣＯＤＥＶＡＬＵＥ、“０ｘＡＡ”）が１バイト置きに格納されている様子を示している。ＰＩＡＴ１２は、ＰＩＡＴ埋め込みコード値が格納された、署名者のＰＩＡＴ署名情報となる。
本実施の形態では、原動画情報に対する検証情報（ＨＡＳＨ１２）と、署名者の電子署名（ＳＩＧＮ１２）は、ＰＩＡＴ署名情報（ＰＩＡＴ１２）として一体化して記録するようにしているが、原動画情報に対する検証情報と署名者の電子署名を別々に記録・管理する形態もあり得る。ただし、この場合は、原動画情報に対する検証情報と署名者の電子署名がペアであるが事後確認できるようにしておく必要がある。
【００４２】
Ｓ３００５／０３のＰＩＡＴ埋め込みコード値の追加が完了すると、続けて、原動画情報に対するＰＩＡＴ署名情報をユーザヘッダ情報に格納する（Ｓ３００５／０４）。
図１７のＳＴＯＲＥＰＩＡＴ１は、その格納の様子を示している。Ｐ１Ｈは、署名者のＰＩＡＴ署名情報がここから格納されていることを示す、ＰＩＡＴ署名情報スタートコード値を示しており、続けて、Ｐ１Ｄは、署名者のＰＩＡＴ署名情報の実体を示しており、それぞれ図１７で示すとおりに格納されている様子を示している。
【００４３】
図２０は、原動画情報のＰＩＡＴ署名情報が格納された状態のＳＨの構造を示している。図１１の状態から、ユーザヘッダ情報を示す、ＰＩＡＴ署名情報を格納するためのスタートコードが追加され、続けて、原動画情報のＰＩＡＴ署名情報がここから格納されていることを示す、ＰＩＡＴ署名情報スタートコード値（ＰＩＡＴＳＴＡＲＴＣＯＤＥＶＡＬＵＥ）が追加され、最後に、ＰＩＡＴ埋め込みコード値が格納された、原動画情報のＰＩＡＴ署名情報（ＰＩＡＴ１２）の実体が追加されている様子を示している。
また、図１７では、ユーザヘッダ情報は原本性保証対象とせず、ストリームヘッダ情報（ＳＨ−Ｇ）を原本性保証対象とした場合を示していたが、ユーザヘッダ情報を含めて原本性保証対象とする場合も同様の方法で処理が行われる。図２１は、その処理の様子を示している。
【００４４】
原動画情報のＰＩＡＴ署名情報の生成、ＳＨへの格納が完了すると、署名生成サーバ３内の文書管理ＴＢ３２を介して、署名者のＰＩＡＴ署名情報付き原動画情報を文書管理ＤＢ３１に蓄積する（Ｓ３００６）。続けて、署名生成サーバ３は、通信手段３４を介し、情報抽出サーバ５に対して、署名者のＰＩＡＴ署名情報付き原動画情報を送信する（Ｓ３００７）。情報抽出サーバ５は、通信手段５５を介して署名者のＰＩＡＴ署名情報付き原動画情報を受信し（Ｓ３００８）、情報抽出サーバ５内の文書管理ＴＢ５２を介して、署名者のＰＩＡＴ署名情報付き原動画情報を文書管理ＤＢ５１に蓄積する（Ｓ３００９）。
次に、抽出者は、署名者から何らかの伝達手段を通じて、原動画情報の作成完了通知を受け、原動画情報の切り出し処理を開始する。この行為は、例えば、ある第三者に対して原動画情報の開示を求められた際、必要な部分だけ抽出して開示する際に行う。具体的には、原動画情報の一部にプライバシ情報が含まれるため、原動画情報の一部を切り出す場面が考えられる。
【００４５】
図１４に示すように、抽出者は、抽出者端末６を用いて、情報抽出サーバ５に対し、切り出し対象の原動画情報の取り出し指示を送信する（Ｓ４００１）。情報抽出サーバ５は、切り出し対象の原動画情報の取り出し指示を受信する（Ｓ４００２）。情報抽出サーバ５内の文書管理ＴＢ５２を介して、文書管理ＤＢ５１に蓄積された切り出し対象の、署名者のＰＩＡＴ署名情報付き原動画情報を取り出し（Ｓ４００３）、署名検証部５４を介して、原動画情報のユーザヘッダ情報に格納されている、ＰＩＡＴ署名情報に付加された電子署名の検証を行う（Ｓ４００４）。ここで、署名者のＰＩＡＴ署名情報にアクセスするためには、前述のとおり、図２０のスタートコード（ＳＴＡＲＴＣＯＤＥ）を検出し、ＳＴＡＲＴＣＯＤＥの次の領域に記録されているＰＩＡＴ署名情報スタートコード値（ＰＩＡＴＳＴＡＲＴＣＯＤＥＶＡＬＵＥ）を確認する。これにより、署名者のＰＩＡＴ署名情報が格納されていることが確認されると、それ以降に格納されている、ＰＩＡＴ署名情報の実体（ＰＩＡＴ１２）にアクセスできる。ＰＩＡＴ署名情報の終端は、次のスタートコード、つまり本実施の形態の場合、ＳＨの終端を示すスタートコード（“０ｘ０００００１Ｂ７”）が現れる直前までとなる。
【００４６】
署名者のＰＩＡＴ署名情報が取り出せたら（図１９のＰＩＡＴ１２）、続けて、ＰＩＡＴ埋め込みコード値を除く処理を行う。本実施の形態の場合、ＨＡＳＨ１２、ＳＩＧＮ１２共に、１バイト置きにＰＩＡＴ埋め込みコード値（“０ｘＡＡ”）を格納している。このため、電子署名検証時には、該ＰＩＡＴ埋め込みコード値を除いた情報を用いて検証処理を行わなければならない。電子署名検証に失敗した場合は（Ｓ４００５：ＮＯ）、なんらかの改変が発生したものとして、その旨、抽出者に通知される（Ｓ４０９９）。電子署名検証が成功した場合は（Ｓ４００５：ＹＥＳ）、抽出者端末６に、原動画情報が送信される（Ｓ４００６）。抽出者端末６に原動画情報が受信されると（Ｓ４００７）、抽出者端末６に装備された表示装置に原動画情報が表示される。続けて、抽出者は、原動画情報から必要な部分を抽出し、切り出し動画情報を作成する（Ｓ４００８）。図２２は、抽出者による原動画情報の抽出操作の一例を示している。再生ボタン（ＰＲＥＶＩＥＷ）により、切り出し動画情報の再生を行いながら、必要な切り出しを行う範囲を指定することで、抽出者は目視による切り出しが可能となる。切り出しの方法としては、まず、シークバー（ＳＥＥＫＢＡＲ）を利用し、任意の位置で開始ボタン（ＳＴＡＲＴＳＥＴ）を押下し、切り出し開始位置を設定する。続けて、同様にシークバー（ＳＥＥＫＢＡＲ）を利用し、任意の場所で終了ボタン（ＥＮＤＳＥＴ）を押下し、切り出し終了位置を設定する。この操作により、切り出し範囲（ＣＵＴＡＲＥＡ）が決定されるので、切り出し動画情報の生成メニューを選択し、切り出し動画情報を作成する。
【００４７】
図１０で示したＭＰＥＧ１のフレーム構成例では、ＳＨは全ＧＯＰの先頭に付加されているが、ＳＨは必ずしもＧＯＰ毎に付加される必要がないため、ＧＯＰ単位で見た場合、先頭ＧＯＰ（ＧＨ１）にＳＨが付加されており、以降のＧＯＰにはＳＨが付加されていないフレーム構成も存在する（図１８）。
ＧＯＰがＳＨから始まる場合は、ＳＨを検出することでＧＯＰの開始と認識可能である。更に、ＧＯＰにＳＨが付加されておらず、ＧＨから始まる場合でも、ＧＨを検出することでＧＯＰの開始と認識可能である。しかしながら、プライバシ保護のための一部切り出しを考慮すると、図１８のようなフレーム構成を持つＭＰＥＧ１への適用にはやや課題が残る。つまり、図１８のようなフレーム構成の場合、ＧＨ２、ＧＨ３、ＧＨ４のいずれかで切り出されると、切り出された動画が再生不能に陥る場合がある。これは、再生動作保証のために、ストリーミングデータの先頭ＧＯＰ（ＧＨ１）には必ずＳＨを含まなければならないというＭＰＥＧ１標準の決まりがあるために生じる。
【００４８】
このように切り出された動画が再生できない状態を回避するために、以下対策を講じる。
まず、図２３に示すように、ＳＨが付加されていないＧＯＰには直近のＳＨの内容を付与し、ＳＨを含めた形で切り出し動画情報を生成する。この時、原動画情報のユーザヘッダ情報に格納されている情報の全体（他のユーザ情報（Ｅ）と署名者のＰＩＡＴ署名情報）を含めて付与し、切り出し動画情報のＳＨ情報として継承する。付与したＳＨは、切り出し動画情報の実体に付加することで、再生不能を回避する。また、図２３では、ＧＯＰ３を先頭としてＧＯＰ４まで切り出された例を示しているが、先頭ＧＯＰにＳＨが付加されていれば、切り出し動画情報の再生は可能である。したがって、切り出し動画情報のデータ量削減のため、必ずしもＧＯＰ４にはＳＨを付加する必要はない。
【００４９】
切り出し動画情報の作成が完了すると、情報抽出サーバ５に対して、作成した切り出し動画情報を送信する（Ｓ４００９）。切り出し動画情報を受信すると（Ｓ４０１０）、情報抽出サーバ５内の署名生成部５３は、切り出し動画情報に対するＰＩＡＴ署名情報を生成する。図２４は、その生成方法の様子を示している。切り出し動画情報に対してＰＩＡＴ署名情報を生成する場合、原動画情報のＰＩＡＴ署名情報生成時同様、ＳＨ内のユーザヘッダ情報（ＳＨ−Ｕ）も原本性保証の対象とするかどうかの判断により、ＰＩＡＴ署名情報の生成方法が異なる。この生成方法は、原動画情報のＰＩＡＴ署名情報生成時にどのような原本性保証対象としたかにより、決定される。図２４では、ユーザヘッダ情報は原本性保証対象とせず、ストリームヘッダ情報（ＳＨ−Ｇ）を原本性保証対象とした場合を示している。
【００５０】
具体的には、抽出で消去するＧＯＰだけからなる複数のルートハッシュ情報（以降、消去ルートハッシュ情報リストと説明）を作成する。この時、原動画情報に対するＰＩＡＴ署名情報生成時と同様に、消去部分にＳＨが付加されていないＧＯＰには直近のＳＨの内容を付与し、ＳＨを含めた形で消去ルートハッシュ情報リストを生成する。更に、作成した消去ルートハッシュ情報リストに対して、抽出者の電子署名を作成し、消去ルートハッシュ情報リストと電子署名をあわせて、抽出者のＰＩＡＴ署名情報とする（Ｓ４０１１）。抽出者のＰＩＡＴ署名情報の生成が完了すると、続けて、切り出し動画情報のＳＨ−Ｕに該ＰＩＡＴ署名情報を格納する（Ｓ４０１２）。
【００５１】
図１５は、その格納方法のフローチャートを示している。まず、ユーザヘッダ情報の終端にスタートコードを追加する（Ｓ４０１２／０１）。続けて、抽出者のＰＩＡＴ署名情報がここから格納されていることを示す、ＰＩＡＴ署名情報スタートコード値を追加する（Ｓ４０１２／０２）。この時、既に格納されている、他のユーザヘッダ情報（Ｅ）、署名者のＰＩＡＴ署名情報と確実に識別できるよう、重複しないユニークなスタートコード値を追加する必要がある。更に、前述のとおり、ＰＩＡＴ署名情報内にスタートコード（“０ｘ０００００１ＸＸ”）が含まれていると、誤認識により、切り出し動画情報のデコード（再生）時にシーケンスエラーが発生する可能性がある。例えば、スタートコードプリフィックス（“０ｘ０００００１”）の後には、必ず何らかの開始を示すスタートコード値（“Ｂ３”、“Ｂ２”、“Ｂ７”等）を含んでいる必要があり、ＰＩＡＴ署名情報内に、“０ｘ０００００１ＦＦ”のような値が現れると、デコード（再生）時にシーケンスエラーを招くこととなる。このような事態を回避するため、ＰＩＡＴ署名情報内にスタートコードが現れないようにする対策が必要となる。その回避対策の一例は、前述のとおり、ＰＩＡＴ埋め込みコード値（“０ｘＡＡ”）を格納することで対応する（Ｓ４０１２／０３）。このＰＩＡＴ埋め込みコード値の格納は、例えば、ＰＩＡＴ署名情報生成の完了後（抽出者の電子署名が付加された後）に行われることが望ましい。
【００５２】
図２５は、抽出者のＰＩＡＴ署名情報の内容を示している。上段（ＰＩＡＴ２１）は、ＰＩＡＴ埋め込みコード値を格納する前のＰＩＡＴ署名情報を、下段（ＰＩＡＴ２２）は、ＰＩＡＴ埋め込みコード値を格納したＰＩＡＴ署名情報を示している。本実施の形態では、切り出し動画情報に対する検証情報として、最初に、基となる原動画情報の総ＧＯＰ数（ＭＡＸＧＯＰＣＮＴ）、続けて、切り出し開始位置のＧＯＰ番号（ＳＴＡＲＴＧＯＰＮＵＭ）、更に、切り出したＧＯＰ数（ＣＵＴＧＯＰＣＮＴ）、最後に消去ルートハッシュ情報リスト（ＨＡＳＨＬＩＳＴ）を順に記録している（ＨＡＳＨ２１）。また、ＳＩＧＮ２１は、これら検証情報に対する抽出者の電子署名を示している。ＨＡＳＨ２１とＳＩＧＮ２１をあわせて抽出者のＰＩＡＴ署名情報（ＰＩＡＴ２１）となる。このＨＡＳＨ２１とＳＩＧＮ２１は事後識別できるようにするため、タグを付けておく必要がある。
【００５３】
ＨＡＳＨ２１、ＳＩＧＮ２１には、共にスタートコード（ＸＳＴＡＲＴＣＯＤＥ）が現れてしまった例を示しており、下段（ＰＩＡＴ２２）のＰＩＡＴ署名情報では、ＨＡＳＨ２２、ＳＩＧＮ２２で示すように、デコード（再生）時にシーケンスエラーを回避するためのＰＩＡＴ埋め込みコード値（ＰＩＡＴＩＮＳＥＲＴＣＯＤＥＶＡＬＵＥ、“０ｘＡＡ”）が１バイト置きに格納されている様子を示している。ＰＩＡＴ２２は、ＰＩＡＴ埋め込みコード値が格納された、抽出者のＰＩＡＴ署名情報となる。
【００５４】
本実施の形態では、切り出し動画情報に対する検証情報（ＨＡＳＨ２２）と、抽出者の電子署名（ＳＩＧＮ２２）は、ＰＩＡＴ署名情報（ＰＩＡＴ２２）として一体化して記録するようにしているが、切り出し動画情報に対する検証情報と電子署名を別々に記録・管理する形態もあり得る。ただし、この場合は、切り出し動画情報に対する検証情報と抽出者の電子署名がペアであるが事後確認できるようにしておく必要がある。
【００５５】
Ｓ４０１２／０３のＰＩＡＴ埋め込みコード値の追加が完了すると、続けて、切り出し動画情報に対するＰＩＡＴ署名情報をユーザヘッダ情報に格納する（Ｓ４０１２／０４）。
図２４のＳＴＯＲＥＰＩＡＴ２は、その格納の様子を示している。Ｐ２Ｈは、抽出者のＰＩＡＴ署名情報がここから格納されていることを示す、ＰＩＡＴ署名情報スタートコード値を示しており、続けて、Ｐ２Ｄは、抽出者のＰＩＡＴ署名情報の実体を示しており、それぞれ図２４で示すとおりに格納されている様子を示している。また、この時、先に格納されている他のユーザ情報（Ｅ）、署名者のＰＩＡＴ署名情報は残して追記し、版数管理が行われる。
【００５６】
図２６は、切り出し動画情報のＰＩＡＴ署名情報が格納された状態のＳＨの構造を示している。図２０で示した原動画情報のＰＩＡＴ署名情報が格納された状態から、ユーザヘッダ情報を示す、ＰＩＡＴ署名情報を格納するためのスタートコードが追加され、続けて、切り出し動画のＰＩＡＴ署名情報がここから格納されていることを示す、ＰＩＡＴ署名情報スタートコード値（ＰＩＡＴＳＴＡＲＴＣＯＤＥＶＡＬＵＥ）が追加され、最後に、ＰＩＡＴ埋め込みコード値が格納された、切り出し動画情報のＰＩＡＴ署名情報（ＰＩＡＴ２２）の実体が追加されている様子を示している。
また、図２４では、ユーザヘッダ情報は原本性保証対象とせず、ストリームヘッダ情報（ＳＨ−Ｇ）を原本性保証対象とした場合を示していたが、ユーザヘッダ情報を含めて原本性保証対象とする場合も同様の方法で処理が行われる。図２７は、その処理の様子を示している。
【００５７】
更に、別の実施形態として、図２０で示した原動画情報のＰＩＡＴ署名情報が格納された状態から、切り出し動画情報のＰＩＡＴ署名情報を格納する前に、新たな他のユーザ情報（Ｅ２）を作成し、例えば、切り出しを行った実際の日時情報等を格納する形態もあり得る。このＥ２は切り出し動画情報のＰＩＡＴ署名情報と同様に、切り出し動画情報に対する付加情報として格納されることが考えられ、当然のことながら、スタートコードが正しく追加された上で格納されることが前提となる。
【００５８】
切り出し動画情報のＰＩＡＴ署名情報の生成が完了すると、情報抽出サーバ５内の文書管理ＴＢ５２を介して、署名者と抽出者のＰＩＡＴ署名情報付き切り出し動画情報を文書管理ＤＢ５１に蓄積する（Ｓ４０１３）。続けて、情報抽出サーバ５は、通信手段５５を介し、署名検証サーバ７に対して、署名者と抽出者のＰＩＡＴ署名情報付き切り出し動画情報を送信する（Ｓ４０１４）。署名検証サーバ７は、通信手段７４を介し、署名者と抽出者のＰＩＡＴ署名情報付き切り出し動画情報を受信し（Ｓ４０１５）、署名検証サーバ７内の文書管理ＴＢ７２を介して、署名者と抽出者のＰＩＡＴ署名情報付き切り出し動画情報を、文書管理ＤＢ７１に蓄積する（Ｓ４０１６）。
【００５９】
次に、図１６に示すように、検証者は、抽出者から何らかの伝達手段を通じて、切り出し動画情報の開示通知を受け、開示された切り出し動画情報の確認、及び検証を開始する。
検証者は、検証者端末８を用いて、署名検証サーバ７に対し、検証対象の切り出し動画情報の取り出し指示を送信する（Ｓ５００１）。図２８は、検証対象の動画情報の一例を示している。本実施の形態では、署名検証時、切り出し動画情報と、原動画情報の選択が可能で、各動画情報の検証が行えるようになっている（ＶＥＲＩＦＹＴＹＰＥ）。例えば、切り出し動画情報を選択すると、切り出し動画情報が選択できるようになり、参照ボタン（ＧＥＴＳＴＲＥＡＭ）を押下することで選択できる。また、参照ボタンを押下することで、署名検証サーバ７内の文書管理ＤＢ７１に蓄積されている切り出し動画情報を参照・選択できるようになっている。最後に、署名検証ボタン（ＶＥＲＩＦＹＲＵＮ）を押下することで、選択した切り出し動画情報の署名検証処理が実行される。このように、検証者は、検証情報となる各ＰＩＡＴ署名情報の存在を意識せず、切り出し動画情報のみ選択すればよく、検証も容易に行うことができる。また、切り出し動画情報の内容を容易に推測・識別可能なタイトルを付与し、検証者には、それらタイトルを集めた一覧を見せ、該一覧から選択させる方法もあり得る。この場合、該一覧中のある動画情報が選択された際、選択された動画情報が、署名検証サーバ７内の文書管理ＤＢ７１に蓄積されている、どの動画像情報なのかを識別するための、例えば、リンク情報を保持しておく必要がある。
【００６０】
署名検証処理が実行されると、署名検証サーバ７は、検証対象の切り出し動画情報の取り出し指示を受信する（Ｓ５００２）。署名検証サーバ７内の文書管理ＴＢ７２を介して、文書管理ＤＢ７１に蓄積された、署名者と抽出者のＰＩＡＴ署名情報付き切り出し動画情報を取り出し（Ｓ５００３）、署名検証部７３を介して、ＰＩＡＴ署名情報に付加された電子署名の検証を行う（Ｓ５００４）。ここで、署名者のＰＩＡＴ署名情報、抽出者のＰＩＡＴ署名情報にアクセスするためには、前述のとおり、図２６のスタートコード（ＳＴＡＲＴＣＯＤＥ）を検出し、ＳＴＡＲＴＣＯＤＥの次の領域に記録されているＰＩＡＴ署名情報スタートコード値（ＰＩＡＴＳＴＡＲＴＣＯＤＥＶＡＬＵＥ）を確認する。これにより、署名者のＰＩＡＴ署名情報、抽出者のＰＩＡＴ署名情報が格納されていることが確認されると、それ以降に格納されている、各ＰＩＡＴ署名情報の実体（ＰＩＡＴ１２、ＰＩＡＴ２２）にアクセスできる。署名者のＰＩＡＴ署名情報の終端は、次のスタートコード（“０ｘ０００００１Ｂ２”）が現れる直前までとなり、また、抽出者のＰＩＡＴ署名情報の終端は、次のスタートコード、つまり本実施の形態の場合、ＳＨの終端を示すスタートコード（“０ｘ０００００１Ｂ７”）が現れる直前までとなる。
【００６１】
署名者のＰＩＡＴ署名情報と、抽出者のＰＩＡＴ署名情報が取り出せたら（図１９のＰＩＡＴ１２、図２５のＰＩＡＴ２２）、続けて、ＰＩＡＴ埋め込みコード値を除く処理を行う。本実施の形態の場合、ＨＡＳＨ１２、ＳＩＧＮ１２、ＨＡＳＨ２２、ＳＩＧＮ２２共に、１バイト置きにＰＩＡＴ埋め込みコード値（“０ｘＡＡ”）を格納している。このため、電子署名検証時には、該ＰＩＡＴ埋め込みコード値を除いた情報を用いて検証処理を行わなければならない。電子署名検証に失敗した場合は（Ｓ５００５：ＮＯ）、なんらかの改変が発生したものとして、その旨、検証者に通知される（Ｓ５０９９）。電子署名検証が成功した場合は（Ｓ５００５：ＹＥＳ）、続けて、切り出し動画情報に対するＰＩＡＴ署名情報検証を行う（Ｓ５００６）。図２９は、その検証方法の様子を示している。切り出し動画情報に対するＰＩＡＴ署名情報を検証する場合、原動画情報、及び切り出し動画情報のＰＩＡＴ署名情報生成時に、ＳＨ内のユーザヘッダ情報（ＳＨ−Ｕ）も原本性保証の対象としたかどうかの判断により、ＰＩＡＴ署名情報の検証方法が異なる。
【００６２】
この検証方法は、最初に原動画情報のＰＩＡＴ署名情報を生成した際にどのような原本性保証対象としたかにより、決定される。図２９では、ユーザヘッダ情報は原本性保証対象とせず、ストリームヘッダ情報（ＳＨ−Ｇ）を原本性保証対象とした場合を示している。この時、図２３のようにＧＯＰ３とＧＯＰ４の連続する２つの部分情報の切り出しを行った場合、ＧＯＰ４にはＳＨを付加する必要がなかったため、ＧＯＰ４にＳＨを含まない状態でハッシュ情報を生成すると、切り出し動画情報に対するＰＩＡＴ署名情報検証に失敗してしまう。そこで、切り出し動画情報のＰＩＡＴ署名情報検証時も同様に、ＳＨが付加されていないＧＯＰには直近のＳＨの内容を付与し、ＳＨを含めた形でハッシュ情報を生成する。この時付与するのはＳＨ−Ｇのみであり、ＳＨ−Ｕに格納されている、他のユーザ情報（Ｅ）、署名者のＰＩＡＴ署名情報、抽出者のＰＩＡＴ署名情報は付与されない。ただし、このＳＨ−Ｇの付与は切り出し動画情報の実体には記録されず、あくまでハッシュ情報の生成を行う際、例えば、記憶領域（メモリ等）上で付与することを意味する。
【００６３】
続けて、抽出者のＰＩＡＴ署名情報に含まれる消去ルートハッシュ情報リストと共に原動画情報のルートハッシュ情報を復元し、署名者のＰＩＡＴ署名情報と比較・検証を行う。また、図２９では、ユーザヘッダ情報は原本性保証対象とせず、ストリームヘッダ情報（ＳＨ−Ｇ）を原本性保証対象とした場合を示していたが、ユーザヘッダ情報を含めて原本性保証対象とする場合も同様の方法で処理が行われる。図３０は、その処理の様子を示している。この時は、ＳＨ−Ｕに格納されている、署名者のＰＩＡＴ署名情報、及び抽出者のＰＩＡＴ署名情報は付与されない。
【００６４】
ＰＩＡＴ署名情報検証に失敗した場合は（Ｓ５００７：ＮＯ）、なんらかの改変が発生したものとして、その旨、検証者に通知される（Ｓ５０９９）。ＰＩＡＴ署名情報検証が成功した場合は（Ｓ５００７：ＹＥＳ）、検証者端末８に、切り出し動画情報のＰＩＡＴ署名情報検証結果が送信される（Ｓ５００８）。検証者端末８に切り出し動画情報のＰＩＡＴ署名検証結果が受信されると（Ｓ５００９）、検証者端末８に装備された表示装置に切り出し動画情報のＰＩＡＴ署名情報検証結果が表示される（Ｓ５０１０）。図３１は、検証者端末８に装備された表示装置に示される署名検証結果の一例を示している。検証者は、この検証結果を参照することにより、原動画情報の一部であることの確認に加え、原動画情報のどの部分が切り出されたかを示す切り出し範囲と、その部分が改変されていないことが明示されるため、切り出し動画情報の原本性を確認することが可能である（ＶＥＲＩＦＹ１）。
【００６５】
更に、署名者、及び抽出者の電子署名の確認により、原動画情報は誰が作成したのか、誰が切り出しを行ったのか（切り出し動画情報を作成したのは誰か）を確認可能である（ＶＥＲＩＦＹ２）。
更に、原動画情報に対する検証も可能である。例えば、図２８のＶＥＲＩＦＹＴＹＰＥでの原動画情報の選択、及び参照ボタン（図２８のＧＥＴＳＴＲＥＡＭ）を押下することで選択できる。また、参照ボタンを押下することで、署名検証サーバ７内の文書管理ＤＢ７１に蓄積されている原動画情報を参照・選択できるようになっている。最後に、署名検証ボタン（図２８のＶＥＲＩＦＹＲＵＮ）を押下することで、選択した原動画情報の署名検証処理が実行される。
【００６６】
なお、本実施の形態では、ＰＩＡＴ署名情報のデータ量削減を目的として、特願２００７−１２０４８号のような発明を利用し、二分木手法を使用する形態で説明したが、各サーバの文書管理ＤＢの記憶容量に余裕がある場合には、ハッシュ情報を二分木で管理する手法を使用せず、特許文献１のような方式をそのまま適用し、原動画情報に含まれるＧＯＰ単位にハッシュ情報を生成・記録していく形態もあり得る。
【００６７】
このように、動画像情報に対してＰＩＡＴ署名情報の効果を実現できる。結果、本発明では、プライバシ保護等のために原動画情報の一部を切り出しても、切り出し動画情報の再生不能を回避しつつ、切り出し箇所（位置）の検出、及び切り出し動画情報の原本性検証が可能となる。また、抽出者は、ＰＩＡＴ署名情報に付加された電子署名から明らかとなるため、仮に抽出者が切り出し動画情報に対して何らかの改変・追加等を施した場合でも、その追跡は可能である。更に、本発明では、切り出し動画情報のＳＨに検証情報となるＰＩＡＴ署名情報を、デコード解析（再生）ができなくなるという課題を回避しながら格納して流通させたことにより、署名検証時には、検証対象となる動画情報のみを指定すればよく、各ＰＩＡＴ署名情報を動画情報と分けて流通させる形態に比べて、動画情報とＰＩＡＴ署名情報の対応付け、管理が必要なくなり、開示コストの削減効果が期待できる。
なお、上記の実施の形態で図示したフローチャートやステップに示された各動作をコンピュータにより実行させるプログラムを提供することにより、本発明の署名管理プログラムを提供することができる。これらプログラムはコンピュータにより読取可能な媒体に記録されてコンピュータにより実行させることができる。コンピュータは、パーソナルコンピュータのようなホスト装置、試験装置のコントローラ、記憶装置のＭＰＵやＣＰＵのようなコントローラなどを含む。ここで、コンピュータにより読取可能な媒体としては、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
【００６８】
以上、本発明の実施の形態によれば、以下の付記で示す技術的思想が開示されている。
（付記１）  ストリーミングデータの部分切り出しに対する署名管理プログラムにおいて、
ストリーミングデータに対する署名関連情報を作成するステップと、
ストリーミングデータのシーケンスヘッダを、ストリーミングデータ再生に必要なストリームヘッダ情報と、ユーザが自由に格納できるユーザヘッダ情報とに区分し、スタートコードが現れない形でユーザヘッダ情報内に署名関連情報を格納するステップと
をコンピュータに実行させることを特徴とする署名管理プログラム。
（付記２）  付記１に記載の署名管理プログラムにおいて、
ユーザヘッダ情報内に署名関連情報を格納する際に、各版数の署名関連情報を上書きしない版数管理をして格納する署名管理プログラム。
（付記３）  付記１または２に記載の署名管理プログラムにおいて、
署名関連情報が格納されていることを示すスタートコード値をユーザヘッダ情報の終端に追加する署名管理プログラム。
（付記４）  付記１乃至付記３のいずれかに記載の署名管理プログラムにおいて、
ユーザヘッダ情報を含めて原本性対象とする場合には、ストリームヘッダ情報とユーザヘッダ情報を有するシーケンスヘッダまで含めて署名関連情報を生成する署名管理プログラム。
（付記５）  付記１乃至付記３のいずれかに記載の署名管理プログラムにおいて、
ユーザヘッダ情報を原本性対象としない場合には、ユーザヘッダ情報を除いたシーケンスヘッダを含めて署名関連情報を生成する署名管理プログラム。
（付記６）  付記１乃至付記５のいずれかに記載の署名管理プログラムにおいて、
１バイト置きに任意の値を埋め込んで署名関連情報を格納し、署名検証時には埋め込んだ値を除去して検証を行う署名管理プログラム。
（付記７）  付記６に記載の署名管理プログラムにおいて、
署名関連情報内にスタートコードが現れなくても自動的に任意の値が埋め込まれる署名管理プログラム。
（付記８）  付記６に記載の署名管理プログラムにおいて、
署名関連情報内にスタートコードが現れるかどうかを事前に判定し、必要に応じて任意の値が埋め込まれる署名管理プログラム。
（付記９）  付記１乃至付記８のいずれかに記載の署名管理プログラムにおいて、
原本ストリームデータを複数の部分情報に分割し、シーケンスヘッダが付加されていない部分情報には直近のシーケンスヘッダの内容を付加した上で各部分情報に対するハッシュ情報を生成し、これらのハッシュ情報から得られたひとつのルートハッシュ情報に対して署名者の電子署名を作成し、ルートハッシュ情報と署名者の電子署名を合わせて署名者の署名関連情報を作成する署名管理プログラム。
（付記１０）  付記９に記載の署名管理プログラムにおいて、
原本ストリームデータのユーザヘッダ情報内に署名者の署名関連情報を格納する署名管理プログラム。
（付記１１）  付記９または付記１０に記載の署名管理プログラムにおいて、
抽出者が原本ストリームデータから切り出しストリームデータを抽出する際に、抽出により消去される部分情報に対し、シーケンスヘッダが付加されていない部分情報には直近のシーケンスヘッダの内容を付加した上で消去ルートハッシュ情報を生成し、この消去ルートハッシュ情報に対して抽出者の電子署名を作成し、消去ルートハッシュ情報と抽出者の電子署名を合わせて抽出者の署名関連情報を作成する署名管理プログラム。
（付記１２）  付記１１に記載の署名管理プログラムにおいて、
原本ストリームデータのシーケンスヘッダの内容を含めて付与して切り出しストリームデータのシーケンスヘッダとして継承し、この切り出しストリームデータのシーケンスヘッダのユーザヘッダ情報内に抽出者の署名関連情報を格納する署名管理プログラム。
（付記１３）  付記１２に記載の署名管理プログラムにおいて、
切り出しストリームデータに対する付加情報を作成して格納する署名管理プログラム。
（付記１４）  付記１２に記載の署名管理プログラムにおいて、
切り出しストリームデータから署名者の署名関連情報と抽出者の署名関連情報を取り出し、署名者の署名関連情報に含まれる原本ストリームデータのルートハッシュ情報と抽出者の署名関連情報に含まれる切り出しストリームデータの消去ルートハッシュ情報を復元して原本性の検証を行う署名管理プログラム。
（付記１５）  付記１乃至付記１４のいずれかに記載の署名管理プログラムにおいて、
署名関連情報はＰＩＡＴ署名情報である署名管理プログラム。
（付記１６）  ストリーミングデータの部分切り出しに対する署名管理方法において、
ストリーミングデータに対する署名関連情報を作成し、
ストリーミングデータのシーケンスヘッダを、ストリーミングデータ再生に必要なストリームヘッダ情報と、ユーザが自由に格納できるユーザヘッダ情報とに区分し、スタートコードが現れない形でユーザヘッダ情報内に署名関連情報を格納する
ことを特徴とする署名管理方法。
（付記１７）  部分切り出しされるストリーミングデータに対する署名管理装置において、
ストリーミングデータに対する署名関連情報を作成する署名関連情報作成手段と、
ストリーミングデータのシーケンスヘッダを、ストリーミングデータ再生に必要なストリームヘッダ情報と、ユーザが自由に格納できるユーザヘッダ情報とに区分し、スタートコードが現れない形でユーザヘッダ情報内に署名関連情報を格納する署名関連情報格納手段と
を備えたことを特徴とする署名管理装置。
【符号の説明】
【００６９】
１  ネットワーク、２  認証機関サーバ、３  署名生成サーバ、４  署名者端末、５  情報抽出サーバ、６  抽出者端末、７  署名検証サーバ、８  検証者端末、２１  公開鍵ＤＢ、２２  証明書発行部、２３  証明書検証部、２４  通信手段、３１  文書管理ＤＢ、３２  文書管理ＴＢ、３３  署名生成部、３４  通信手段、５１  文書管理ＤＢ、５２  文書管理ＴＢ、５３  署名生成部、５４  署名検証部、５５  通信手段、７１  文書管理ＤＢ、７２  文書管理ＴＢ、７３  署名検証部、７４  通信手段。
【図１】
2011061815.tif 000003
【図２】
2011061815.tif 000004
【図３】
2011061815.tif 000005
【図４】
2011061815.tif 000006
【図５】
2011061815.tif 000007
【図６】
2011061815.tif 000008
【図７】
2011061815.tif 000009
【図８】
2011061815.tif 000010
【図９】
2011061815.tif 000011
【図１０】
2011061815.tif 000012
【図１１】
2011061815.tif 000013
【図１２】
2011061815.tif 000014
【図１３】
2011061815.tif 000015
【図１４】
2011061815.tif 000016
【図１５】
2011061815.tif 000017
【図１６】
2011061815.tif 000018
【図１７】
2011061815.tif 000019
【図１８】
2011061815.tif 000020
【図１９】
2011061815.tif 000021
【図２０】
2011061815.tif 000022
【図２１】
2011061815.tif 000023
【図２２】
2011061815.tif 000024
【図２３】
2011061815.tif 000025
【図２４】
2011061815.tif 000026
【図２５】
2011061815.tif 000027
【図２６】
2011061815.tif 000028
【図２７】
2011061815.tif 000029
【図２８】
2011061815.tif 000030
【図２９】
2011061815.tif 000031
【図３０】
2011061815.tif 000032
【図３１】
2011061815.tif 000033