電子情報公開証明システム
【課題】 動的に変化するような複雑なwebページに対しても公開証明を行える電子情報公開証明システムを提供する。
【解決手段】 電子情報を公開するwebサーバに対し、該webサーバが電子情報をネットワークに公開してことを証明する電子情報公開証明システムであって、電子情報に所定の方式でアクセスするアクセス手段と、アクセスすることにより取得した電子情報をレンダリングするレンダリング手段と、レンダリングされた電子情報から公開証明に用いられる証明対象データを生成する証明対象データ生成手段と、証明対象データに対する時刻証明を取得する時刻証明手段と、証明対象データと時刻証明とを含むアクセス結果を記録するアクセス結果記録手段と、アクセス結果に基づき、電子情報が公開されていたことを証明する証明書を生成する証明書生成手段とを有する。
【解決手段】 電子情報を公開するwebサーバに対し、該webサーバが電子情報をネットワークに公開してことを証明する電子情報公開証明システムであって、電子情報に所定の方式でアクセスするアクセス手段と、アクセスすることにより取得した電子情報をレンダリングするレンダリング手段と、レンダリングされた電子情報から公開証明に用いられる証明対象データを生成する証明対象データ生成手段と、証明対象データに対する時刻証明を取得する時刻証明手段と、証明対象データと時刻証明とを含むアクセス結果を記録するアクセス結果記録手段と、アクセス結果に基づき、電子情報が公開されていたことを証明する証明書を生成する証明書生成手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットで電子情報が公開されていたことを証明する公開内容電子情報公開証明システムに関する。
【背景技術】
【０００２】
インターネットの普及に伴い、従来紙で公開されていた官報や企業決算報告が電子的に行われるようになってきている。インターネットでの公開内容については、発信者側の裁量に委ねられていたが、近年第三者が証明するような仕組みが提案されている。
【０００３】
その提案の一つである特許文献１には、ネットワーク上に公開されている電子公開物を、ネットワークを介して回収して記録しておくことで、後でその電子公開物が公開されていたことを証明することができるようにするものである。
【０００４】
また、特許文献２、特許文献３には、特許文献１に加えて電子公開物の変更履歴を追跡管理できることや、検索を容易にすることについて言及されている
【特許文献１】特許第３４２０４７２号公報
【特許文献２】特開２００１−１５４９８８号公報
【特許文献３】特開２００１−１５４９８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、最近のwebページには、表示するたびに動的に変化してしまうようなwebページや、サーバとのインタラクションが必要なwebページ等、webページ単体をダウンロードしただけでは内容を表示できないようなwebページがある。
【０００６】
このようなwebページの場合、特許文献１に記載されている方式は、証明を依頼されたURLに公開されている電子公開物をダウンロードしてそのまま保存しておく仕組みになっているため対応することができない。
【０００７】
電子公開物は、たとえ基本がHTMLで記述されていたとしても、スクリプトやアプレットが含まれていたりすると、動的に表示内容が変化したりする可能性があり、またそのHTMLのレンダリングの仕方によっては見え方が変わる可能性がある。したがって、ダウンロードしたデータをそのまま記録しておいたとしても後で確認したときに正しく内容が表示されない可能性があるという問題がある。
【０００８】
特許文献２、特許文献３においても、電子公開物の表示内容という意味では基本的に上記特許文献１と同じ問題がある。
【０００９】
本発明はこのような問題点に鑑み、動的に変化するような複雑なwebページに対しても公開証明を行える電子情報公開証明システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、電子情報を公開するwebサーバに対し、該webサーバが前記電子情報をネットワークに公開してことを証明する電子情報公開証明システムであって、前記電子情報に所定の方式でアクセスするアクセス手段と、アクセスすることにより取得した前記電子情報をレンダリングするレンダリング手段と、レンダリングされた電子情報から公開証明に用いられる証明対象データを生成する証明対象データ生成手段と、前記証明対象データに対する時刻証明を取得する時刻証明手段と、前記証明対象データと前記時刻証明とを含むアクセス結果を記録するアクセス結果記録手段と、前記アクセス結果に基づき、前記電子情報が公開されていたことを証明する証明書を生成する証明書生成手段とを有することを特徴とする。
【００１１】
また、上記課題を解決するために、本発明は、前記アクセス手段を複数有し、各アクセス手段はアクセスする方式が異なることを特徴とする。
【００１２】
また、上記課題を解決するために、本発明は、前記各アクセス手段に対応する前記レンダリング手段を有することを特徴とする。
【００１３】
また、上記課題を解決するために、本発明は、前記証明対象データ生成手段は、レンダリングされた前記電子情報のデータ量を圧縮した証明対象データを生成することを特徴とする。
【００１４】
また、上記課題を解決するために、本発明は、前記証明書は、前記時刻証明を含むことを特徴とする。
【００１５】
また、上記課題を解決するために、本発明は、前記証明書は、電子情報公開証明システムの電子署名を含むことを特徴とする。
【００１６】
また、上記課題を解決するために、本発明は、前記証明書は、該証明書自体の時刻証明を含むことを特徴とする。
【発明の効果】
【００１７】
本発明によれば、動的に変化するような複雑なwebページに対しても公開証明を行える電子情報公開証明システムを提供できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態について図面に基づいて説明する。
【実施例１】
【００１９】
まず最初に、インターネット上に電子情報を公開していたことを証明する一般的な電子情報公開証明システムの仕組みについて、図１を用いて説明する。図１には、依頼者１０と、公開証明サーバ１１と、アクセス結果ＤＢ１２と、アクセスエージェント１３と、時刻証明サーバ１４と、webサーバ１５とが示されている。
【００２０】
依頼者１０は、webサーバ１５がインターネット上に電子情報を公開していたことを証明したい者である。公開証明サーバ１１は、公開証明サーバは依頼者やアクセスエージェントとのやり取りを行い、公開していたことを証明するサーバである。アクセス結果ＤＢ１２は、webサーバにアクセスするアクセスエージェント１３がwebサーバにアクセスしたアクセス結果が記録されるデータベースである。時刻証明サーバ１４は、アクセスしてダウンロードしたデータに付与する時刻を証明するサーバである。webサーバ１５は、電子情報を公開するサーバである。なお、上記アクセスエージェントは、１つ以上存在する。
【００２１】
この構成において、依頼者１０は、証明したい対象電子情報のURL（証明対象URL）と、証明したい期間（証明期間）を指定して公開証明サーバ１１に対して依頼をする。
【００２２】
公開証明サーバ１１はその依頼を元に、各アクセスエージェントに対して、証明対象URLと証明期間を伝える。各アクセスエージェントは指定された証明期間中、ランダムなタイミングで指定された証明対象URLにアクセスを行い、アクセス結果を公開証明サーバ１１に送付し続ける。公開証明サーバ１１は送付されたアクセス結果をアクセス結果ＤＢ１２に記録し、その記録されたアクセス結果ＤＢ１２を基にして証明書を作成して依頼者１０に送付する。
【００２３】
ここで、各アクセスエージェントの処理について説明する。各アクセスエージェントは指定された証明期間中、指定された証明対象URLに対してランダムなタイミングでアクセスを行う。アクセスしてダウンロードしたデータ（対象URLデータ）を元にハッシュ値を計算し、時刻証明サーバにそのハッシュ値を渡して時刻証明を取得する。そして対象URLデータと時刻証明を合わせたアクセス結果を公開証明サーバに送付する。各アクセスエージェントは、この処理を毎回アクセスするたびに行う。
【００２４】
以上が一般的な電子情報公開証明システムの仕組みである。この仕組みにより証明対象URLにある電子情報については公開されていたことを証明することができるようになる。しかし証明対象URLにある電子情報にスクリプトが含まれているなど、その電子情報を表示するたびに異なる表示結果となるようなものも存在する。
【００２５】
したがって、その証明対象URLからダウンロードした電子情報そのものを記録しておいたとしても、その電子情報にアクセスした時点ではその電子情報がどのように表示されていたのかということを後で再現することができなくなる可能性がある。
【００２６】
そこで、本実施の形態では、この問題を解決するために以下のような仕組みにする。上述した一般的な電子情報公開証明システムにおいて、アクセスエージェントは、証明対象URLにある電子情報にアクセスしてダウンロードした際に、その電子情報をwebブラウザで表示する際の表示イメージをレンダリングして生成する。そしてその生成されたイメージデータに圧縮処理などを施し、データフォーマットを整形した上で、そのデータに対してハッシュ値の計算をし、時刻証明を取得してアクセス結果として公開証明サーバに送付する。
【００２７】
公開証明サーバは受け取ったアクセス結果を記録しておき、そのアクセス結果を元に証明書を生成して依頼者に送付する。以下、この仕組みについて具体的に説明する。
【００２８】
図２は、本実施の形態におけるアクセスエージェント１３の内部構成を示す図である。アクセスエージェント１３は、時刻証明部２０と、アクセスエージェント主制御部２１と、証明対象データ生成部２２と、アクセス部２３と、レンダリング部２４とで構成される。
【００２９】
アクセスエージェント主制御部２１は、アクセスエージェント１３の全体的な制御を行う。時刻証明部２０は、時刻証明サーバ１４とやり取りし、時刻の証明に係る処理を行う。証明対象データ生成部２２は、webサーバ１５で公開されていた対象となるデータを生成する。アクセス部２３は、webサーバ１５にアクセスする。レンダリング部２４は、証明対象データの元となるデバイス非依存表示データを取得する。
【００３０】
これらのうち、アクセスエージェント主制御部２１の処理を、図３のフローチャートを用いて説明する。
【００３１】
アクセスエージェント主制御部２１は、公開証明サーバ１１から証明対象URLと証明期間を受け取る（ステップＳ１０１）。次に証明期間中にランダムにアクセスするためのアクセスタイミングのスケジュールを作成する（ステップＳ１０２）。次に証明期間中かどうか判断する（ステップＳ１０３）。証明期間中ではない場合、処理は終了する。証明期間中の場合、ステップＳ１０４へ処理は進む。
【００３２】
スケジュールに従ってアクセス部２３に証明対象URLへのアクセスを指示する（ステップＳ１０４）。次に、レンダリング部２４から証明対象URLに対応するデバイス非依存表示データを取得する（ステップＳ１０５）。取得したデバイス非依存表示データを、証明対象データ生成部２２に渡し、証明対象データを取得する（ステップＳ１０６）。
【００３３】
時刻証明部２０により証明対象データに対する時刻証明を取得する（ステップＳ１０７）。証明対象データと時刻証明を合わせてアクセス結果とする（ステップＳ１０８）。アクセス結果を公開証明サーバに送付する（ステップＳ１０９）。
【００３４】
次に、アクセス部２３の処理を、図４のフローチャートを用いて説明する。まず、アクセスエージェント主制御部２１から対象URLを受け取る（ステップＳ２０１）。次に、対象URLにアクセス（HTTP GET）する（ステップＳ２０２）。対象URLのwebページデータをダウンロードする（ステップＳ２０３）。webページデータを解析（parse）し、埋め込まれているオブジェクト（画像、アプレット等）のURLを特定する（ステップＳ２０４）。
【００３５】
次のステップＳ２０５、ステップＳ２０６は各オブジェクトに対して行われるループ処理であり、オブジェクトの数だけ繰り返される。オブジェクトのURLにアクセスする（ステップＳ２０５）。そのオブジェクトデータをダウンロードする（ステップＳ２０６）。ダウンロードしたすべてのwebページデータ、オブジェクトデータを対象URLデータとしてレンダリング部２４に渡す（ステップＳ２０７）。
【００３６】
次に、レンダリング部２４の処理を、図５のフローチャートを用いて説明する。まず、アクセス部２３から対象URLデータを受け取る（ステップＳ３０１）。対象URLデータを表示するプログラムを起動してウィンドウに表示する（ステップＳ３０２）。ウィンドウが生成するデバイス非依存表示データを取得する（ステップＳ３０３）。デバイス非依存表示データをアクセスエージェント主制御部２１に渡す（ステップＳ３０４）。
【００３７】
次に、時刻証明部２０の処理を、図６を用いて説明する。アクセスエージェント主制御部２１から証明対象データを受け取る（ステップＳ４０１）。証明対象データに対してハッシュ値を計算する（ステップＳ４０２）。ハッシュ値を時刻証明サーバに送付する（ステップＳ４０３）。時刻証明サーバから時刻証明を取得する（ステップＳ４０４）。
【００３８】
なお、上記ハッシュ値の計算は例えば、SHA-1（Secure Hash Algorithm 1）やMD5（Message Digest 5）などのハッシュアルゴリズムを使用して計算すればよい。また、時刻証明サーバ１４とのやり取りはRFC3161 Time-Stamp Protocolに従って行うのが良い。さらに、時刻証明のフォーマットについてもRFC3161やISO18014-1にタイムスタンプトークンとして規定されているものを使用するのが良い。このタイムスタンプトークンの生成方式については、RFC3161やISO18014-1に記述されているため、時刻証明サーバの仕組みについてはここでは特に説明しない。
【００３９】
上述した処理を、Microsoft（登録商標） Windows（登録商標）上で動作するプログラムとして実装する際には、例えば次のようにして実現することができる。Microsoft（登録商標） Internet Explorer（以下、ＩＥと記す）を、証明対象URLを引数として起動し、ＩＥに証明対象URLにアクセスさせ、そのアクセスしたHTMLに含まれている画像データやアプレットなども含めてダウンロードさせる。
【００４０】
そしてダウンロードさせたデータをもとにＩＥに表示データのレンダリングを行わせ、レンダリングさせたデバイス非依存表示データ（Device Context）をブラウザウィンドウに渡して画面上に証明対象のwebページを表示させる。その状態でＩＥに対して印刷処理をさせる。
【００４１】
このとき、例えば表示内容をAdobe（登録商標） PDFファイルとして出力するようなプリンタドライバ（Adobe（登録商標） Acrobatなどの一部として市販されている）を指定して印刷処理をさせると、IEからそのプリンタドライバにデバイス非依存表示データが渡り、ブラウザウィンドウに表示された内容が静的な（動的に表示内容が変化したりしない）PDFファイルとして出力される。したがって、この場合の証明対象データは、PDFファイルとなる。
【００４２】
このPDFファイルに対してハッシュ値を計算し、時刻証明サーバに対してハッシュ値を送付して時刻証明を取得する。取得した時刻証明と先のPDFファイルとを含めたアクセス結果を公開証明サーバに送付する。
【００４３】
印刷処理でPDFを出力させるという証明対象データ生成部における証明対象データを生成する方式は、他にもそのブラウザウィンドウに対してスクリーンキャプチャ（Print Screen）を行った結果をBMPファイル形式で出力する方式や、白黒２値化してTIFFファイル形式で出力する方式など、別の方式を用いてもよい。TIFFファイル形式にするにはリコー（登録商標）製のRICOH（登録商標） File Writerというソフトウェアが利用できる。白黒２値化して圧縮すると、記録しなければならないアクセス結果のファイルサイズを小さくすることができるようになる。
【００４４】
次に、公開証明サーバ１１について説明する。図７は、公開証明サーバ１１の内部構成を示す図である。公開証明サーバ１１は、図７に示されるように、証明書生成部３０と、公開証明サーバ主制御部３１と、アクセス結果記録部３２とを有する。公開証明サーバ主制御部３１は、依頼者と直接やり取りし、証明書を依頼者に送付するなどの処理を行う。証明書生成部３０は、証明書を生成する。アクセス結果記録部３２は、アクセス結果ＤＢ１２にアクセス結果を記録する。
【００４５】
これらのうち、公開証明サーバ主制御部３１の処理を、図８のフローチャートを用いて説明する。まず、依頼者から証明依頼を受け取る（ステップＳ５０１）。次に、証明依頼の内容から証明対象URLと証明期間を取得する（ステップＳ５０２）。証明対象URLと証明期間を複数のアクセスエージェントに送付する（ステップＳ５０３）。証明期間が終了かどうか判断する（ステップＳ５０４）。
【００４６】
証明期間が終了していない場合、アクセスエージェントからアクセス結果を受け取る（ステップＳ５０５）。そして、受け取ったアクセス結果をアクセス結果記録部１１に記録する。
【００４７】
証明期間が終了している場合、アクセス結果記録部１１に記録されたアクセス結果を元に証明書生成部３０で証明書を生成する（ステップＳ５０７）。そして、生成した証明書を依頼者に送付する（ステップＳ５０８）。
【００４８】
この証明書の送付の仕方は、例えば、依頼者からの証明依頼から電子メールアドレスを取り出し、そのアドレスに電子メールを送付するようにしてもよい。
【００４９】
次に、アクセス結果記録部３２の処理を、図９のフローチャートを用いて説明する。証明対象データと時刻証明を含むアクセス結果を受け取る（ステップＳ６０１）。受け取ったアクセス結果に含まれる証明対象データのハッシュ値Ａを計算する（ステップＳ６０２）。アクセス結果ＤＢ１２にすでに同じ証明対象URLに対するレコードが記録されているかどうか判断する（ステップＳ６０３）。
【００５０】
レコードが記録されていない場合、証明対象URL、証明対象データ、ハッシュ値Ａ、時刻証明をアクセス結果ＤＢ１２のレコードとして記録する（ステップＳ６０８）。ステップＳ６０３で、レコードが記録されていると判定された場合、ハッシュ値Ａを、前回同じURLに関して記録されたレコードのハッシュ値Ｂと比較する（ステップＳ６０４）。
【００５１】
ハッシュ値Ａとハッシュ値Ｂが等しいかどうか判断する（ステップＳ６０５）。等しい場合、証明対象URLとハッシュ値Ａ、時刻証明をアクセス結果ＤＢ１２のレコードとして記録する（ステップＳ６０６）。異なる場合、証明対象URL、証明対象データ、ハッシュ値Ａ、時刻証明をアクセス結果ＤＢ１２のレコードとして記録する（ステップＳ６０７）。
【００５２】
次に、アクセス結果ＤＢ１２のレコード構造について、図１０を用いて説明する。アクセス結果ＤＢ１２のレコード構造は、図１０に示されるように、証明対象ＵＲＬと、証明対象データと、ハッシュ値と、時刻証明とからなる構造となっている。なお、アクセス結果ＤＢ１２には、アクセス部２３がダウンロードした対象URLデータをすべて記録しておくようにしても良いし、証明対象データ自体は依頼者が保有しているため、逆に全く記録しないようにしても構わない。
【００５３】
次に、証明書生成部３０の処理を、図１１のフローチャートと、図１２を用いて説明する。図１２は、証明書が生成される様子を示す図であり、図１１のステップと対応させている。
【００５４】
まず、証明対象URLに対するアクセス結果のうち、ハッシュ値と時刻証明の部分のみをすべて受け取る（ステップＳ７０１）。次にハッシュ値と時刻証明のリストを作成する（ステップＳ７０２）。図１２には、ハッシュ値と時刻証明からなるリストが示されている。
【００５５】
証明対象URLと証明期間、上記リストを合わせたデータ４０に対してハッシュ値Xを計算する（ステップＳ７０３）。図１２には、上記リストと証明期間、証明対象ＵＲＬ全体からハッシュ値Ｘが生成される様子が示されている。
【００５６】
ハッシュ値Ｘを公開証明サーバの内部秘密鍵で暗号化して電子署名にする（ステップＳ７０４）。電子署名をデータ４０に付与し、そのデータ４１に対してさらにハッシュ値Ｙを計算する（ステップＳ７０５）。ハッシュ値Ｙを時刻証明サーバに送付し、時刻証明Yを取得する（ステップＳ７０６）。時刻証明Ｙをデータ４１に付与し、証明書４２とする（ステップＳ７０７）。この証明書４２を返す（ステップＳ７０８）。
【００５７】
電子署名を計算するにはハッシュアルゴリズムとしてSHA-1やMD5を使用し、公開鍵暗号アルゴリズムとしてRSAやDSA、楕円暗号を用いればよい。
【実施例２】
【００５８】
実施例１においては、レンダリング部を一つのものとして説明したが、実際にはwebページデータを閲覧する際のレンダリングの仕方によって表示内容が変わることがよくある。例えばＩＥとNetscape（登録商標） Navigator（以下、ＮＮと記す）とでは表示されるイメージが異なるような場合である。
【００５９】
また、実施例１では、アクセス部を一つのものとして説明したが、実際にwebページデータを閲覧する際のアクセスする方式の種類によって、webサーバ側が異なるwebページデータをダウンロードさせることがよくある。例えばＩＥでアクセスした場合とＮＮでアクセスした場合とで、それぞれのブラウザの特性に合わせたwebページデータをwebサーバが送信してくるような場合である。
【００６０】
このような状況に対応して、どのような情報がwebサーバ上に公開されていたのか、一般の利用者には実際に何が公開されていたのかを証明するためには、異なる複数のアクセス部及びレンダリング部を用いてアクセスを試み、そして得られた表示データを記録することが望ましい。
【００６１】
実施例２におけるアクセスエージェントの内部構成を、図１３を用いて説明する。なお、実施例１で説明した符号については、説明を省略する。実施例１で説明したアクセスエージェントと異なる部分は、アクセス部とレンダリング部が複数設けられていることである。そして各アクセス部はアクセスする方式が異なる。
【００６２】
図１３において、アクセス部２３１は、アクセス部２３１に対応するレンダリング部２４１に対象ＵＲＬデータを渡し、アクセス部２３２は、アクセス部２３２に対応するレンダリング部２４２に対象ＵＲＬデータを渡すようになっている。したがって、例えばアクセス部２３１とレンダリング部２４１の組をＩＥに対応させ、アクセス部２３２とレンダリング部２４２の組をＮＮに対応させるようにすると、異なるwebページデータを送信するwebサーバにも対応することができる。これにより、いずれのブラウザを搭載するＰＣに対しても電子情報が公開されていたかどうかを証明することが可能となる。
【００６３】
このように実施例２では、アクセス部とレンダリング部とが１つの組となり、その組が複数存在する実施例である。なお、あるアクセス部Ａとあるレンダリング部Ｂが組となっている場合でも、レンダリング部Ｂが他のアクセス部Ｃとさらに組になるような、１つのレンダリング部が、複数のアクセス部と組になることもありうる。
【００６４】
以上説明した図１３に示されるアクセスエージェントの処理を、図１４のフローチャートを用いて説明する。公開証明サーバから証明対象URLと証明期間を受け取る（ステップＳ８０１）。証明期間中にランダムにアクセスするためのアクセスタイミングのスケジュールを作成する（ステップＳ８０２）。次に証明期間中かどうか判断する（ステップＳ８０３）。証明期間中ではない場合、処理は終了する。証明期間中の場合、ステップＳ８０４へ処理は進む。
【００６５】
ステップＳ８０４とステップＳ８０５は、ループ処理であり、アクセス部とレンダリング部の組の数であるｎ回にわたり処理が繰り返される。スケジュールに従ってアクセス部に証明対象URLへのアクセスを指示する（ステップＳ８０４）。レンダリング部から証明対象URLに対応するデバイス非依存表示データを取得する（ステップＳ８０５）。これらのステップＳ８０４とステップＳ８０５におけるアクセス部とレンダリング部は１つの組である。
【００６６】
ループ処理を抜けると、取得したデバイス非依存表示データを証明対象データ生成部に渡し、証明対象データを取得する（ステップＳ８０６）。時刻証明部により証明対象データに対する時刻証明を取得する（ステップＳ８０７）。証明対象データと時刻証明を合わせてアクセス結果とする（ステップＳ８０８）。 アクセス結果を公開証明サーバに送付する（ステップＳ８０９）。
【００６７】
以上が実施例２の説明である。これら２つの実施例により、アクセスして得た電子情報をレンダリングしてイメージデータを含めアクセス結果を記録するようにしたことで、後で再現しにくいような特殊なwebページが証明対象であっても実際にどのような内容が公開されていたのかを確認できるようになる。
【００６８】
また、複数の方式でアクセスを行うようにしたことで、一つのアクセス方式では得られない電子情報を別のアクセス方式により取得することができ、アクセスしてくる相手によって提供する電子情報が異なるようなwebページであっても適切に公開証明を行うことができるようになる。
【００６９】
さらに、複数の方式でレンダリングを行うようにしたことで、一つのレンダリング方式では表示できなかった内容を別のレンダリング方式では表示できる可能性があり、アクセスしているブラウザの種類によって表示内容が異なるようなwebページであっても適切に公開証明を行うことができるようになる。また、複数のアクセス方式と複数のレンダリング方式を同時に利用することも可能である。
【００７０】
その他、レンダリング部がデータ量の圧縮を行うようにしたことで、アクセス結果の記録に必要となる保存媒体の容量を小さくすることができる。
【００７１】
証明書に時刻証明を含めることによって、その電子公開物がいつ公開されていたのかを証明することができるようになる。
【００７２】
また、公開証明システム自身の電子署名を付与することによって、その証明書が確かに公開証明システムの作成したものであることを保証することができるようになる。
【００７３】
さらに、公開証明システムの電子署名を付与してから更に時刻保証を付与することにより、その証明書がいつ作成されたものであるのかを保証することができるようになる。
【図面の簡単な説明】
【００７４】
【図１】webドキュメント公開システムを示す図である。
【図２】アクセスエージェントの内部構成を示す図である（その１）。
【図３】アクセスエージェント主制御部の処理を示すフローチャートである（その１）。
【図４】アクセス部の処理を示すフローチャートである。
【図５】レンダリング部の処理を示すフローチャートである。
【図６】時刻証明部の処理を示すフローチャートである。
【図７】公開証明サーバの内部構成を示す図である。
【図８】公開証明サーバ主制御部の処理を示すフローチャートである。
【図９】アクセス結果記録部の処理を示すフローチャートである。
【図１０】アクセス結果ＤＢのレコード構造を示す図である。
【図１１】証明書生成部の処理を示すフローチャートである。
【図１２】証明書が生成される様子を示す図である。
【図１３】アクセスエージェントの内部構成を示す図である（その２）。
【図１４】アクセスエージェント主制御部の処理を示すフローチャートである（その２）。
【符号の説明】
【００７５】
１０ 依頼者
１１ 公開証明サーバ
１２ アクセス結果ＤＢ
１３ アクセスエージェント
１４ 時刻証明サーバ
１５ webサーバ
２０ 時刻証明部
２１ アクセスエージェント主制御部
２２ 時刻対象データ生成部
２３、２３１、２３２ アクセス部
２４、２４１、２４２ レンダリング部
３０ 証明書生成部
３１ 公開証明サーバ主制御部
３２ アクセス結果記録部
４０、４１ データ
４２ 証明書
【技術分野】
【０００１】
本発明は、インターネットで電子情報が公開されていたことを証明する公開内容電子情報公開証明システムに関する。
【背景技術】
【０００２】
インターネットの普及に伴い、従来紙で公開されていた官報や企業決算報告が電子的に行われるようになってきている。インターネットでの公開内容については、発信者側の裁量に委ねられていたが、近年第三者が証明するような仕組みが提案されている。
【０００３】
その提案の一つである特許文献１には、ネットワーク上に公開されている電子公開物を、ネットワークを介して回収して記録しておくことで、後でその電子公開物が公開されていたことを証明することができるようにするものである。
【０００４】
また、特許文献２、特許文献３には、特許文献１に加えて電子公開物の変更履歴を追跡管理できることや、検索を容易にすることについて言及されている
【特許文献１】特許第３４２０４７２号公報
【特許文献２】特開２００１−１５４９８８号公報
【特許文献３】特開２００１−１５４９８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、最近のwebページには、表示するたびに動的に変化してしまうようなwebページや、サーバとのインタラクションが必要なwebページ等、webページ単体をダウンロードしただけでは内容を表示できないようなwebページがある。
【０００６】
このようなwebページの場合、特許文献１に記載されている方式は、証明を依頼されたURLに公開されている電子公開物をダウンロードしてそのまま保存しておく仕組みになっているため対応することができない。
【０００７】
電子公開物は、たとえ基本がHTMLで記述されていたとしても、スクリプトやアプレットが含まれていたりすると、動的に表示内容が変化したりする可能性があり、またそのHTMLのレンダリングの仕方によっては見え方が変わる可能性がある。したがって、ダウンロードしたデータをそのまま記録しておいたとしても後で確認したときに正しく内容が表示されない可能性があるという問題がある。
【０００８】
特許文献２、特許文献３においても、電子公開物の表示内容という意味では基本的に上記特許文献１と同じ問題がある。
【０００９】
本発明はこのような問題点に鑑み、動的に変化するような複雑なwebページに対しても公開証明を行える電子情報公開証明システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、電子情報を公開するwebサーバに対し、該webサーバが前記電子情報をネットワークに公開してことを証明する電子情報公開証明システムであって、前記電子情報に所定の方式でアクセスするアクセス手段と、アクセスすることにより取得した前記電子情報をレンダリングするレンダリング手段と、レンダリングされた電子情報から公開証明に用いられる証明対象データを生成する証明対象データ生成手段と、前記証明対象データに対する時刻証明を取得する時刻証明手段と、前記証明対象データと前記時刻証明とを含むアクセス結果を記録するアクセス結果記録手段と、前記アクセス結果に基づき、前記電子情報が公開されていたことを証明する証明書を生成する証明書生成手段とを有することを特徴とする。
【００１１】
また、上記課題を解決するために、本発明は、前記アクセス手段を複数有し、各アクセス手段はアクセスする方式が異なることを特徴とする。
【００１２】
また、上記課題を解決するために、本発明は、前記各アクセス手段に対応する前記レンダリング手段を有することを特徴とする。
【００１３】
また、上記課題を解決するために、本発明は、前記証明対象データ生成手段は、レンダリングされた前記電子情報のデータ量を圧縮した証明対象データを生成することを特徴とする。
【００１４】
また、上記課題を解決するために、本発明は、前記証明書は、前記時刻証明を含むことを特徴とする。
【００１５】
また、上記課題を解決するために、本発明は、前記証明書は、電子情報公開証明システムの電子署名を含むことを特徴とする。
【００１６】
また、上記課題を解決するために、本発明は、前記証明書は、該証明書自体の時刻証明を含むことを特徴とする。
【発明の効果】
【００１７】
本発明によれば、動的に変化するような複雑なwebページに対しても公開証明を行える電子情報公開証明システムを提供できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態について図面に基づいて説明する。
【実施例１】
【００１９】
まず最初に、インターネット上に電子情報を公開していたことを証明する一般的な電子情報公開証明システムの仕組みについて、図１を用いて説明する。図１には、依頼者１０と、公開証明サーバ１１と、アクセス結果ＤＢ１２と、アクセスエージェント１３と、時刻証明サーバ１４と、webサーバ１５とが示されている。
【００２０】
依頼者１０は、webサーバ１５がインターネット上に電子情報を公開していたことを証明したい者である。公開証明サーバ１１は、公開証明サーバは依頼者やアクセスエージェントとのやり取りを行い、公開していたことを証明するサーバである。アクセス結果ＤＢ１２は、webサーバにアクセスするアクセスエージェント１３がwebサーバにアクセスしたアクセス結果が記録されるデータベースである。時刻証明サーバ１４は、アクセスしてダウンロードしたデータに付与する時刻を証明するサーバである。webサーバ１５は、電子情報を公開するサーバである。なお、上記アクセスエージェントは、１つ以上存在する。
【００２１】
この構成において、依頼者１０は、証明したい対象電子情報のURL（証明対象URL）と、証明したい期間（証明期間）を指定して公開証明サーバ１１に対して依頼をする。
【００２２】
公開証明サーバ１１はその依頼を元に、各アクセスエージェントに対して、証明対象URLと証明期間を伝える。各アクセスエージェントは指定された証明期間中、ランダムなタイミングで指定された証明対象URLにアクセスを行い、アクセス結果を公開証明サーバ１１に送付し続ける。公開証明サーバ１１は送付されたアクセス結果をアクセス結果ＤＢ１２に記録し、その記録されたアクセス結果ＤＢ１２を基にして証明書を作成して依頼者１０に送付する。
【００２３】
ここで、各アクセスエージェントの処理について説明する。各アクセスエージェントは指定された証明期間中、指定された証明対象URLに対してランダムなタイミングでアクセスを行う。アクセスしてダウンロードしたデータ（対象URLデータ）を元にハッシュ値を計算し、時刻証明サーバにそのハッシュ値を渡して時刻証明を取得する。そして対象URLデータと時刻証明を合わせたアクセス結果を公開証明サーバに送付する。各アクセスエージェントは、この処理を毎回アクセスするたびに行う。
【００２４】
以上が一般的な電子情報公開証明システムの仕組みである。この仕組みにより証明対象URLにある電子情報については公開されていたことを証明することができるようになる。しかし証明対象URLにある電子情報にスクリプトが含まれているなど、その電子情報を表示するたびに異なる表示結果となるようなものも存在する。
【００２５】
したがって、その証明対象URLからダウンロードした電子情報そのものを記録しておいたとしても、その電子情報にアクセスした時点ではその電子情報がどのように表示されていたのかということを後で再現することができなくなる可能性がある。
【００２６】
そこで、本実施の形態では、この問題を解決するために以下のような仕組みにする。上述した一般的な電子情報公開証明システムにおいて、アクセスエージェントは、証明対象URLにある電子情報にアクセスしてダウンロードした際に、その電子情報をwebブラウザで表示する際の表示イメージをレンダリングして生成する。そしてその生成されたイメージデータに圧縮処理などを施し、データフォーマットを整形した上で、そのデータに対してハッシュ値の計算をし、時刻証明を取得してアクセス結果として公開証明サーバに送付する。
【００２７】
公開証明サーバは受け取ったアクセス結果を記録しておき、そのアクセス結果を元に証明書を生成して依頼者に送付する。以下、この仕組みについて具体的に説明する。
【００２８】
図２は、本実施の形態におけるアクセスエージェント１３の内部構成を示す図である。アクセスエージェント１３は、時刻証明部２０と、アクセスエージェント主制御部２１と、証明対象データ生成部２２と、アクセス部２３と、レンダリング部２４とで構成される。
【００２９】
アクセスエージェント主制御部２１は、アクセスエージェント１３の全体的な制御を行う。時刻証明部２０は、時刻証明サーバ１４とやり取りし、時刻の証明に係る処理を行う。証明対象データ生成部２２は、webサーバ１５で公開されていた対象となるデータを生成する。アクセス部２３は、webサーバ１５にアクセスする。レンダリング部２４は、証明対象データの元となるデバイス非依存表示データを取得する。
【００３０】
これらのうち、アクセスエージェント主制御部２１の処理を、図３のフローチャートを用いて説明する。
【００３１】
アクセスエージェント主制御部２１は、公開証明サーバ１１から証明対象URLと証明期間を受け取る（ステップＳ１０１）。次に証明期間中にランダムにアクセスするためのアクセスタイミングのスケジュールを作成する（ステップＳ１０２）。次に証明期間中かどうか判断する（ステップＳ１０３）。証明期間中ではない場合、処理は終了する。証明期間中の場合、ステップＳ１０４へ処理は進む。
【００３２】
スケジュールに従ってアクセス部２３に証明対象URLへのアクセスを指示する（ステップＳ１０４）。次に、レンダリング部２４から証明対象URLに対応するデバイス非依存表示データを取得する（ステップＳ１０５）。取得したデバイス非依存表示データを、証明対象データ生成部２２に渡し、証明対象データを取得する（ステップＳ１０６）。
【００３３】
時刻証明部２０により証明対象データに対する時刻証明を取得する（ステップＳ１０７）。証明対象データと時刻証明を合わせてアクセス結果とする（ステップＳ１０８）。アクセス結果を公開証明サーバに送付する（ステップＳ１０９）。
【００３４】
次に、アクセス部２３の処理を、図４のフローチャートを用いて説明する。まず、アクセスエージェント主制御部２１から対象URLを受け取る（ステップＳ２０１）。次に、対象URLにアクセス（HTTP GET）する（ステップＳ２０２）。対象URLのwebページデータをダウンロードする（ステップＳ２０３）。webページデータを解析（parse）し、埋め込まれているオブジェクト（画像、アプレット等）のURLを特定する（ステップＳ２０４）。
【００３５】
次のステップＳ２０５、ステップＳ２０６は各オブジェクトに対して行われるループ処理であり、オブジェクトの数だけ繰り返される。オブジェクトのURLにアクセスする（ステップＳ２０５）。そのオブジェクトデータをダウンロードする（ステップＳ２０６）。ダウンロードしたすべてのwebページデータ、オブジェクトデータを対象URLデータとしてレンダリング部２４に渡す（ステップＳ２０７）。
【００３６】
次に、レンダリング部２４の処理を、図５のフローチャートを用いて説明する。まず、アクセス部２３から対象URLデータを受け取る（ステップＳ３０１）。対象URLデータを表示するプログラムを起動してウィンドウに表示する（ステップＳ３０２）。ウィンドウが生成するデバイス非依存表示データを取得する（ステップＳ３０３）。デバイス非依存表示データをアクセスエージェント主制御部２１に渡す（ステップＳ３０４）。
【００３７】
次に、時刻証明部２０の処理を、図６を用いて説明する。アクセスエージェント主制御部２１から証明対象データを受け取る（ステップＳ４０１）。証明対象データに対してハッシュ値を計算する（ステップＳ４０２）。ハッシュ値を時刻証明サーバに送付する（ステップＳ４０３）。時刻証明サーバから時刻証明を取得する（ステップＳ４０４）。
【００３８】
なお、上記ハッシュ値の計算は例えば、SHA-1（Secure Hash Algorithm 1）やMD5（Message Digest 5）などのハッシュアルゴリズムを使用して計算すればよい。また、時刻証明サーバ１４とのやり取りはRFC3161 Time-Stamp Protocolに従って行うのが良い。さらに、時刻証明のフォーマットについてもRFC3161やISO18014-1にタイムスタンプトークンとして規定されているものを使用するのが良い。このタイムスタンプトークンの生成方式については、RFC3161やISO18014-1に記述されているため、時刻証明サーバの仕組みについてはここでは特に説明しない。
【００３９】
上述した処理を、Microsoft（登録商標） Windows（登録商標）上で動作するプログラムとして実装する際には、例えば次のようにして実現することができる。Microsoft（登録商標） Internet Explorer（以下、ＩＥと記す）を、証明対象URLを引数として起動し、ＩＥに証明対象URLにアクセスさせ、そのアクセスしたHTMLに含まれている画像データやアプレットなども含めてダウンロードさせる。
【００４０】
そしてダウンロードさせたデータをもとにＩＥに表示データのレンダリングを行わせ、レンダリングさせたデバイス非依存表示データ（Device Context）をブラウザウィンドウに渡して画面上に証明対象のwebページを表示させる。その状態でＩＥに対して印刷処理をさせる。
【００４１】
このとき、例えば表示内容をAdobe（登録商標） PDFファイルとして出力するようなプリンタドライバ（Adobe（登録商標） Acrobatなどの一部として市販されている）を指定して印刷処理をさせると、IEからそのプリンタドライバにデバイス非依存表示データが渡り、ブラウザウィンドウに表示された内容が静的な（動的に表示内容が変化したりしない）PDFファイルとして出力される。したがって、この場合の証明対象データは、PDFファイルとなる。
【００４２】
このPDFファイルに対してハッシュ値を計算し、時刻証明サーバに対してハッシュ値を送付して時刻証明を取得する。取得した時刻証明と先のPDFファイルとを含めたアクセス結果を公開証明サーバに送付する。
【００４３】
印刷処理でPDFを出力させるという証明対象データ生成部における証明対象データを生成する方式は、他にもそのブラウザウィンドウに対してスクリーンキャプチャ（Print Screen）を行った結果をBMPファイル形式で出力する方式や、白黒２値化してTIFFファイル形式で出力する方式など、別の方式を用いてもよい。TIFFファイル形式にするにはリコー（登録商標）製のRICOH（登録商標） File Writerというソフトウェアが利用できる。白黒２値化して圧縮すると、記録しなければならないアクセス結果のファイルサイズを小さくすることができるようになる。
【００４４】
次に、公開証明サーバ１１について説明する。図７は、公開証明サーバ１１の内部構成を示す図である。公開証明サーバ１１は、図７に示されるように、証明書生成部３０と、公開証明サーバ主制御部３１と、アクセス結果記録部３２とを有する。公開証明サーバ主制御部３１は、依頼者と直接やり取りし、証明書を依頼者に送付するなどの処理を行う。証明書生成部３０は、証明書を生成する。アクセス結果記録部３２は、アクセス結果ＤＢ１２にアクセス結果を記録する。
【００４５】
これらのうち、公開証明サーバ主制御部３１の処理を、図８のフローチャートを用いて説明する。まず、依頼者から証明依頼を受け取る（ステップＳ５０１）。次に、証明依頼の内容から証明対象URLと証明期間を取得する（ステップＳ５０２）。証明対象URLと証明期間を複数のアクセスエージェントに送付する（ステップＳ５０３）。証明期間が終了かどうか判断する（ステップＳ５０４）。
【００４６】
証明期間が終了していない場合、アクセスエージェントからアクセス結果を受け取る（ステップＳ５０５）。そして、受け取ったアクセス結果をアクセス結果記録部１１に記録する。
【００４７】
証明期間が終了している場合、アクセス結果記録部１１に記録されたアクセス結果を元に証明書生成部３０で証明書を生成する（ステップＳ５０７）。そして、生成した証明書を依頼者に送付する（ステップＳ５０８）。
【００４８】
この証明書の送付の仕方は、例えば、依頼者からの証明依頼から電子メールアドレスを取り出し、そのアドレスに電子メールを送付するようにしてもよい。
【００４９】
次に、アクセス結果記録部３２の処理を、図９のフローチャートを用いて説明する。証明対象データと時刻証明を含むアクセス結果を受け取る（ステップＳ６０１）。受け取ったアクセス結果に含まれる証明対象データのハッシュ値Ａを計算する（ステップＳ６０２）。アクセス結果ＤＢ１２にすでに同じ証明対象URLに対するレコードが記録されているかどうか判断する（ステップＳ６０３）。
【００５０】
レコードが記録されていない場合、証明対象URL、証明対象データ、ハッシュ値Ａ、時刻証明をアクセス結果ＤＢ１２のレコードとして記録する（ステップＳ６０８）。ステップＳ６０３で、レコードが記録されていると判定された場合、ハッシュ値Ａを、前回同じURLに関して記録されたレコードのハッシュ値Ｂと比較する（ステップＳ６０４）。
【００５１】
ハッシュ値Ａとハッシュ値Ｂが等しいかどうか判断する（ステップＳ６０５）。等しい場合、証明対象URLとハッシュ値Ａ、時刻証明をアクセス結果ＤＢ１２のレコードとして記録する（ステップＳ６０６）。異なる場合、証明対象URL、証明対象データ、ハッシュ値Ａ、時刻証明をアクセス結果ＤＢ１２のレコードとして記録する（ステップＳ６０７）。
【００５２】
次に、アクセス結果ＤＢ１２のレコード構造について、図１０を用いて説明する。アクセス結果ＤＢ１２のレコード構造は、図１０に示されるように、証明対象ＵＲＬと、証明対象データと、ハッシュ値と、時刻証明とからなる構造となっている。なお、アクセス結果ＤＢ１２には、アクセス部２３がダウンロードした対象URLデータをすべて記録しておくようにしても良いし、証明対象データ自体は依頼者が保有しているため、逆に全く記録しないようにしても構わない。
【００５３】
次に、証明書生成部３０の処理を、図１１のフローチャートと、図１２を用いて説明する。図１２は、証明書が生成される様子を示す図であり、図１１のステップと対応させている。
【００５４】
まず、証明対象URLに対するアクセス結果のうち、ハッシュ値と時刻証明の部分のみをすべて受け取る（ステップＳ７０１）。次にハッシュ値と時刻証明のリストを作成する（ステップＳ７０２）。図１２には、ハッシュ値と時刻証明からなるリストが示されている。
【００５５】
証明対象URLと証明期間、上記リストを合わせたデータ４０に対してハッシュ値Xを計算する（ステップＳ７０３）。図１２には、上記リストと証明期間、証明対象ＵＲＬ全体からハッシュ値Ｘが生成される様子が示されている。
【００５６】
ハッシュ値Ｘを公開証明サーバの内部秘密鍵で暗号化して電子署名にする（ステップＳ７０４）。電子署名をデータ４０に付与し、そのデータ４１に対してさらにハッシュ値Ｙを計算する（ステップＳ７０５）。ハッシュ値Ｙを時刻証明サーバに送付し、時刻証明Yを取得する（ステップＳ７０６）。時刻証明Ｙをデータ４１に付与し、証明書４２とする（ステップＳ７０７）。この証明書４２を返す（ステップＳ７０８）。
【００５７】
電子署名を計算するにはハッシュアルゴリズムとしてSHA-1やMD5を使用し、公開鍵暗号アルゴリズムとしてRSAやDSA、楕円暗号を用いればよい。
【実施例２】
【００５８】
実施例１においては、レンダリング部を一つのものとして説明したが、実際にはwebページデータを閲覧する際のレンダリングの仕方によって表示内容が変わることがよくある。例えばＩＥとNetscape（登録商標） Navigator（以下、ＮＮと記す）とでは表示されるイメージが異なるような場合である。
【００５９】
また、実施例１では、アクセス部を一つのものとして説明したが、実際にwebページデータを閲覧する際のアクセスする方式の種類によって、webサーバ側が異なるwebページデータをダウンロードさせることがよくある。例えばＩＥでアクセスした場合とＮＮでアクセスした場合とで、それぞれのブラウザの特性に合わせたwebページデータをwebサーバが送信してくるような場合である。
【００６０】
このような状況に対応して、どのような情報がwebサーバ上に公開されていたのか、一般の利用者には実際に何が公開されていたのかを証明するためには、異なる複数のアクセス部及びレンダリング部を用いてアクセスを試み、そして得られた表示データを記録することが望ましい。
【００６１】
実施例２におけるアクセスエージェントの内部構成を、図１３を用いて説明する。なお、実施例１で説明した符号については、説明を省略する。実施例１で説明したアクセスエージェントと異なる部分は、アクセス部とレンダリング部が複数設けられていることである。そして各アクセス部はアクセスする方式が異なる。
【００６２】
図１３において、アクセス部２３１は、アクセス部２３１に対応するレンダリング部２４１に対象ＵＲＬデータを渡し、アクセス部２３２は、アクセス部２３２に対応するレンダリング部２４２に対象ＵＲＬデータを渡すようになっている。したがって、例えばアクセス部２３１とレンダリング部２４１の組をＩＥに対応させ、アクセス部２３２とレンダリング部２４２の組をＮＮに対応させるようにすると、異なるwebページデータを送信するwebサーバにも対応することができる。これにより、いずれのブラウザを搭載するＰＣに対しても電子情報が公開されていたかどうかを証明することが可能となる。
【００６３】
このように実施例２では、アクセス部とレンダリング部とが１つの組となり、その組が複数存在する実施例である。なお、あるアクセス部Ａとあるレンダリング部Ｂが組となっている場合でも、レンダリング部Ｂが他のアクセス部Ｃとさらに組になるような、１つのレンダリング部が、複数のアクセス部と組になることもありうる。
【００６４】
以上説明した図１３に示されるアクセスエージェントの処理を、図１４のフローチャートを用いて説明する。公開証明サーバから証明対象URLと証明期間を受け取る（ステップＳ８０１）。証明期間中にランダムにアクセスするためのアクセスタイミングのスケジュールを作成する（ステップＳ８０２）。次に証明期間中かどうか判断する（ステップＳ８０３）。証明期間中ではない場合、処理は終了する。証明期間中の場合、ステップＳ８０４へ処理は進む。
【００６５】
ステップＳ８０４とステップＳ８０５は、ループ処理であり、アクセス部とレンダリング部の組の数であるｎ回にわたり処理が繰り返される。スケジュールに従ってアクセス部に証明対象URLへのアクセスを指示する（ステップＳ８０４）。レンダリング部から証明対象URLに対応するデバイス非依存表示データを取得する（ステップＳ８０５）。これらのステップＳ８０４とステップＳ８０５におけるアクセス部とレンダリング部は１つの組である。
【００６６】
ループ処理を抜けると、取得したデバイス非依存表示データを証明対象データ生成部に渡し、証明対象データを取得する（ステップＳ８０６）。時刻証明部により証明対象データに対する時刻証明を取得する（ステップＳ８０７）。証明対象データと時刻証明を合わせてアクセス結果とする（ステップＳ８０８）。 アクセス結果を公開証明サーバに送付する（ステップＳ８０９）。
【００６７】
以上が実施例２の説明である。これら２つの実施例により、アクセスして得た電子情報をレンダリングしてイメージデータを含めアクセス結果を記録するようにしたことで、後で再現しにくいような特殊なwebページが証明対象であっても実際にどのような内容が公開されていたのかを確認できるようになる。
【００６８】
また、複数の方式でアクセスを行うようにしたことで、一つのアクセス方式では得られない電子情報を別のアクセス方式により取得することができ、アクセスしてくる相手によって提供する電子情報が異なるようなwebページであっても適切に公開証明を行うことができるようになる。
【００６９】
さらに、複数の方式でレンダリングを行うようにしたことで、一つのレンダリング方式では表示できなかった内容を別のレンダリング方式では表示できる可能性があり、アクセスしているブラウザの種類によって表示内容が異なるようなwebページであっても適切に公開証明を行うことができるようになる。また、複数のアクセス方式と複数のレンダリング方式を同時に利用することも可能である。
【００７０】
その他、レンダリング部がデータ量の圧縮を行うようにしたことで、アクセス結果の記録に必要となる保存媒体の容量を小さくすることができる。
【００７１】
証明書に時刻証明を含めることによって、その電子公開物がいつ公開されていたのかを証明することができるようになる。
【００７２】
また、公開証明システム自身の電子署名を付与することによって、その証明書が確かに公開証明システムの作成したものであることを保証することができるようになる。
【００７３】
さらに、公開証明システムの電子署名を付与してから更に時刻保証を付与することにより、その証明書がいつ作成されたものであるのかを保証することができるようになる。
【図面の簡単な説明】
【００７４】
【図１】webドキュメント公開システムを示す図である。
【図２】アクセスエージェントの内部構成を示す図である（その１）。
【図３】アクセスエージェント主制御部の処理を示すフローチャートである（その１）。
【図４】アクセス部の処理を示すフローチャートである。
【図５】レンダリング部の処理を示すフローチャートである。
【図６】時刻証明部の処理を示すフローチャートである。
【図７】公開証明サーバの内部構成を示す図である。
【図８】公開証明サーバ主制御部の処理を示すフローチャートである。
【図９】アクセス結果記録部の処理を示すフローチャートである。
【図１０】アクセス結果ＤＢのレコード構造を示す図である。
【図１１】証明書生成部の処理を示すフローチャートである。
【図１２】証明書が生成される様子を示す図である。
【図１３】アクセスエージェントの内部構成を示す図である（その２）。
【図１４】アクセスエージェント主制御部の処理を示すフローチャートである（その２）。
【符号の説明】
【００７５】
１０ 依頼者
１１ 公開証明サーバ
１２ アクセス結果ＤＢ
１３ アクセスエージェント
１４ 時刻証明サーバ
１５ webサーバ
２０ 時刻証明部
２１ アクセスエージェント主制御部
２２ 時刻対象データ生成部
２３、２３１、２３２ アクセス部
２４、２４１、２４２ レンダリング部
３０ 証明書生成部
３１ 公開証明サーバ主制御部
３２ アクセス結果記録部
４０、４１ データ
４２ 証明書
【特許請求の範囲】
【請求項１】
電子情報を公開するwebサーバに対し、該webサーバが前記電子情報をネットワークに公開してことを証明する電子情報公開証明システムであって、
前記電子情報に所定の方式でアクセスするアクセス手段と、
アクセスすることにより取得した前記電子情報をレンダリングするレンダリング手段と、
レンダリングされた電子情報から公開証明に用いられる証明対象データを生成する証明対象データ生成手段と、
前記証明対象データに対する時刻証明を取得する時刻証明手段と、
前記証明対象データと前記時刻証明とを含むアクセス結果を記録するアクセス結果記録手段と、
前記アクセス結果に基づき、前記電子情報が公開されていたことを証明する証明書を生成する証明書生成手段と
を有することを特徴とする電子情報公開証明システム。
【請求項２】
前記アクセス手段を複数有し、
各アクセス手段はアクセスする方式が異なることを特徴とする請求項１に記載の電子情報公開証明システム。
【請求項３】
前記各アクセス手段に対応する前記レンダリング手段を有することを特徴とする請求項２に記載の電子情報公開証明システム。
【請求項４】
前記証明対象データ生成手段は、レンダリングされた前記電子情報のデータ量を圧縮した証明対象データを生成することを特徴とする請求項１から請求項３のいずれか１項に記載の電子情報公開証明システム。
【請求項５】
前記証明書は、前記時刻証明を含むことを特徴とする請求項１から請求項４のいずれか１項に記載の電子情報公開証明システム。
【請求項６】
前記証明書は、電子情報公開証明システムの電子署名を含むことを特徴とする請求項１から請求項５のいずれか１項に記載の電子情報公開証明システム。
【請求項７】
前記証明書は、該証明書自体の時刻証明を含むことを特徴とする請求項１から６のいずれか１項に記載の電子情報公開証明システム。
【請求項１】
電子情報を公開するwebサーバに対し、該webサーバが前記電子情報をネットワークに公開してことを証明する電子情報公開証明システムであって、
前記電子情報に所定の方式でアクセスするアクセス手段と、
アクセスすることにより取得した前記電子情報をレンダリングするレンダリング手段と、
レンダリングされた電子情報から公開証明に用いられる証明対象データを生成する証明対象データ生成手段と、
前記証明対象データに対する時刻証明を取得する時刻証明手段と、
前記証明対象データと前記時刻証明とを含むアクセス結果を記録するアクセス結果記録手段と、
前記アクセス結果に基づき、前記電子情報が公開されていたことを証明する証明書を生成する証明書生成手段と
を有することを特徴とする電子情報公開証明システム。
【請求項２】
前記アクセス手段を複数有し、
各アクセス手段はアクセスする方式が異なることを特徴とする請求項１に記載の電子情報公開証明システム。
【請求項３】
前記各アクセス手段に対応する前記レンダリング手段を有することを特徴とする請求項２に記載の電子情報公開証明システム。
【請求項４】
前記証明対象データ生成手段は、レンダリングされた前記電子情報のデータ量を圧縮した証明対象データを生成することを特徴とする請求項１から請求項３のいずれか１項に記載の電子情報公開証明システム。
【請求項５】
前記証明書は、前記時刻証明を含むことを特徴とする請求項１から請求項４のいずれか１項に記載の電子情報公開証明システム。
【請求項６】
前記証明書は、電子情報公開証明システムの電子署名を含むことを特徴とする請求項１から請求項５のいずれか１項に記載の電子情報公開証明システム。
【請求項７】
前記証明書は、該証明書自体の時刻証明を含むことを特徴とする請求項１から６のいずれか１項に記載の電子情報公開証明システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００６−２９５５６５（Ｐ２００６−２９５５６５Ａ）
【公開日】平成１８年１０月２６日（２００６．１０．２６）
【国際特許分類】
【出願番号】特願２００５−１１３８１１（Ｐ２００５−１１３８１１）
【出願日】平成１７年４月１１日（２００５．４．１１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成１８年１０月２６日（２００６．１０．２６）
【国際特許分類】
【出願日】平成１７年４月１１日（２００５．４．１１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]