複数のユーザーの各々から登録要求を受信し、前記登録要求の各々と共に、対応するユーザー側で生成された公開鍵と秘密鍵のペアのうち公開鍵のみを受信し、前記登録要求に応じて、互いに異なるユーザー識別名を決定し、このユーザー識別名を対応する前記公開鍵に関連付けてデータベースに登録し、前記ユーザーに対して、前記ユーザー識別名が前記公開鍵に関連付けられて登録されたことを通知し、互いに関連付けられた前記公開鍵とユーザー識別名を、インターネットを介して、一般に公開することを特徴とする識別名管理システム。プライバシーの観点から匿名の利用は必要と言えるが、一方で、ネットワーク上での発言は、こういう意見もあるといった、その場限りの点の集まりとなってしまう。誰が言っているのかという情報は、その意見の有用性の評価にとって重要であるし、こういう意見を言っている人は、他にどんなことを言っているのかといった情報もまた信頼性を評価する参考とするなど、非常に有用である。また、バラバラの匿名個人が発信する情報には、責任がないので、信頼性の欠ける情報が気軽に発信されてしまうこともある。ツイッターなどでは、ユーザー名によって、ある程度までは匿名個人を識別できる。また、著名人では、本人確認済みのアカウントとすることで、なりすましや紛らわしいユーザー名による混乱を避けることが出来る。しかしながら、ツイッター以外にも、他のコミュニティサービスや、ネットオークションや、通販サイトのユーザーレビュー、新聞サイトの投稿欄や、QAへの書き込み、SNSやブログなど、一般個人からの情報発信の場所は数多くある。これらを含めたインターネット上で、匿名個人を統一的に識別し確実に検証する手段は存在しない。一般に或る情報が有用なものかどうかは、その情報の提供ソースが重要な手がかりとなる。もし、有力な新聞サイトの社説であれば、読んでみる価値があると考える。また、信頼できる書き手であれば、時間を使って読もうと考える。特に、地震や噴火などの災害において、しばしば流言飛語や風評被害などが問題となる。緊急性を要する事態においては、情報の信憑性についての一定の手掛かりがあると被害が抑制されることがある。大手サイト、例えば新聞社のサイトならば、一定レベルの信頼性は期待できる。しかし、次の3つの点では一般ユーザーによる情報発信の方が優位にある。一つは、情報の細かさである。電気製品に関して言えば、或る特定機種の或る特定操作に関わる不具合といったものや、或る特定地域の或る特定分野に関わる情報といったものは、個人レベルの情報に頼らざるを得ないことが多い。もう一つは、情報の速さである。現在進行形の事象については、その場に居合わせた一般ユーザーの情報が最も早い。更に、情報の量という点でも、圧倒的な数の一般ユーザーが優位にある。また、情報は獲得するだけでなく、その内容を正しく解釈し信憑性を判断する必要がある。ところが、日々発信される情報は、個人の許容量をはるかに超えている。各自の得意分野における個人レベルの分業といった作業が不可欠と思われる。ところが誤った情報または有害な情報が多く混じっていると、良質の正しい情報を選別することは困難である。以下に、不必要な情報を選別するかが、集合知のメリットを最大限に活かすには、如何にして不必要な情報を選別するかがポイントとなる。一方で、或る人物が新聞サイトの投稿欄へ投稿する場合、その人物は、一定の労力と時間を費やす。そして、その情報が他の人々にとって有用なものならば、その情報には一定の価値が存在する。しかし、その人物が無名の人物であれば、その投稿は単発の情報であり、そのサイトを閲覧した人だけが参照するその時だけの情報となっている。投稿した人物が無名であれば、その人物が得るものは、投稿したという自己満足だけにとどまってしまう。すなわち、その投稿はその場限りのものであり、一般にはその人物の信用度を向上させることはない。なので、労力と時間を費すメリットは小さく、時間をかけて良質な情報を提供しようとする意欲は出てこない。これに対して実名により投稿を行うという方法もある。実際、実名投稿を義務付けているSNSも存在する。しかしながら、実名の公表にはプライバシーの侵害など大きなリスクが伴う。又、その実名自体の信頼性についても疑念が残る。実名確認のために電子証明書に求められるような煩雑な手続きを行うことも考えられるが、費用がかかる上に面倒なので一般ユーザーの理解は得られない。更に、実名投稿は特定のSNSに限定されており、インターネットの様々なメディアにおける横の関係はバラバラである。更に、同一実名や類似実名も非常に多い。もう一つの課題として、非常にユニークで価値ある投稿を行っても、他人に剽窃されてしまう可能性があるという点がある。特に、エッセイ、映像や音楽といった創作物については、創作証明が出来ないことは、発表や流布を妨げる大きな要因となっている。また、PKIは主体の特定に利用できるが、その原理的な有効性にもかかわらず、少なくとも個人レベルでは、主にその一方向についてのみ普及している。すなわち、サービスの提供側といった法人が、公開鍵証明書を持ち、サービスに関する情報に電子署名を行い、それを一般の個人が確認してサービスを利用するといった利用が大部分である。本来は、個人も電子証明書を持ち、電子署名を行うことで、インターネットの可能性は大きく拡がるはずであるが、そのようは利用は例外的と言って良い。実際、個人が電子証明書を利用する場面というのは、非常に限られている。この理由は、やはりPKIの導入には煩雑さがある為と思われる。現在では、どうしても必要な場合には、認証局に申し込みを行い、必要な手続きに従って個人の電子証明書を取得する。これには手間と時間だけでなく費用もかかる。また有効期間にも気を配る必要がある。そして、その電子証明書はそのユーザー個人を特定するものなので、印章と同様にその管理を慎重に行う必要がある。ある意味では、印章よりももっと直接にユーザー個人を特定する機能を有するので、もしも漏洩すれば、悪用される危険性がより高いと言える。更に、個人ユーザーが、実名によってインターネット上で活動する場合には、プライバシーに関するリスクが伴う。従って、本発明の目的は、個人レベルで、自己証明に電子署名を気軽に利用出来る環境を提供することである。本発明の他の目的は、匿名であっても電子署名を利用出来る環境を提供することである。本発明の更に他の目的は、個々のユーザーにユニークな識別名を与え、その識別名によってインターネット上に発信された情報に対して、その出自を明確にして信頼性の評価基準を与えることである。上記課題を解決するために、本発明の識別名管理システムは、複数のユーザーの各々から登録要求を受信し、前記登録要求の各々と共に、対応するユーザー側で生成された公開鍵と秘密鍵のペアのうち公開鍵のみを受信し、前記登録要求に応じて、互いに異なるユーザー識別名を決定し、このユーザー識別名を対応する前記公開鍵に関連付けてデータベースに登録し、前記ユーザーに対して、前記ユーザー識別名が前記公開鍵に関連付けられて登録されたことを通知し、互いに関連付けられた前記公開鍵とユーザー識別名を、インターネットを介して、一般に公開することを特徴とする。本発明の識別名管理システムによれば、インターネットで情報の発信を行うユーザーは、その識別名において信用を累積させることができる。また、識別名の利用を匿名で行うことで、現実生活とは切り離すことができるので、プライバシーに関するリスクを回避できる。更に、本発明の識別名管理システムによれば、インターネットに有用な情報を発信することが、直接にユーザーの利益となる為、各ユーザーは積極的に有用な情報の発信を行うようになり、インターネット上の情報が豊かとなり、公共の利益につながる。更に、本発明の識別名管理システムによれば、インターネットを利用する一般のユーザーは、情報の有用性や信頼性を、その情報の発信者によって評価することが可能となり、より安心してその情報を利用することが可能となる。電子署名アルゴリズムにおいては、平文を署名鍵で処理することで署名を生成し、署名の検証を検証鍵で行う。しかし、データベースにおいては、各レコードにユニークな情報のみが問題となる。従って、この明細書においては、適宜、各鍵ペアにユニークな検証鍵情報を公開鍵と呼び、各鍵ペアの秘匿される署名鍵情報を秘密鍵と呼ぶこととする。例えば、RSA署名では、平文cと署名値sとの関係は以下の通りである。csemodnscdmodnつまり、平文cに対して、dとnを用いて署名値sを計算できる。また、署名値sに対して、eとnを用いて平文cを計算できる。ここで、署名鍵はdとnであり、検証鍵は、eとnとなっている。通常、eは予め一定の数に決めておくので、実質的な検証鍵、つまり各レコードにユニークな公開鍵はnである。また、nが公開されているので、実質的な秘匿すべき署名鍵はdである。この明細書でも、eは予め一定の数に決めておく。従って、以下の記述では、dのみを秘密鍵と呼び、nのみを公開鍵と呼ぶことにする。また、以下の記述では、パディングやハッシュ処理など平文への前処理も含めて署名の処理とする。本発明の実施例1に関わる識別名管理システムは、インターネットに接続し、識別名を管理する管理サーバーとして実装される。この管理サーバーと通信して識別名を利用する為に、ユーザーのパソコン側には専用のユーティリティソフトがインストールされる。管理サーバーでは、個々の匿名ユーザーに対して、識別名としてユニークなサイバーネームを発行し、このサイバーネームを対応する匿名ユーザーの公開鍵に関連付けて公開する。個々のサイバーネームがユニークであることは、管理サーバーが管理し保証するが、全て公開されるので誰でも重複の有無を確認できる。パソコンのユーティリティソフトでは、公開鍵と秘密鍵のペアを生成し保存する。ただし秘密鍵は暗号化しておく。そして、その公開鍵とサイバーネームを関連付けて登録を行うように、管理サーバーに依頼する。秘密鍵は管理サーバーへは送信されず、ユーザーが自己責任において秘匿する。また、ユーザーがメッセージを投稿する際に、署名をすることでサイバーネームで認証を付けたり、他人のメッセージの認証を検証したりすることができる。この実施例では、署名アルゴリズムとして2048ビットのRSAを用いるものとする。なお、管理サーバーとユーザーとは、SSLで保護された通信を行うが、このSSLはTLSも含むものとする。特に、必須ではないが、クライアント認証も行うことが好ましい。この場合は、サイバーネームに関連付けられた公開鍵を用いると便利である。識別名管理システムの基本的な機能は、インターネットのユーザーが、個人情報を開示すること無く、電子署名を利用出来るようにするものである。その為に、各ユーザーの識別名と公開鍵を対応付けて、登録し一般に公開する。これによって各ユーザーは、インターネットにおける自分の活動に対して、電子署名を付けることで他人と明確に区別し、自分の識別名によって、インターネットにおけるアイデンティティを確立することが出来る。<実装形態>この識別名管理システムの動作フェーズとしては、サイバーネームと公開鍵を関連付けて管理サーバーへ登録する登録フェーズと、ユーザーがメッセージ等の発信データに署名して情報発信を行う発信フェーズと、他人の発信情報の認証を検証する検証フェーズがある。また、ユーザー側のユーティリティソフトの実装形態としては、ブラウザの機能を持った単独で動作する独立のソフトウエアとして実装する場合と、既存のブラウザを利用する場合がある。独立のソフトウエアの場合には、インターフェースの自由度は高いが、ユーザーは使い慣れたブラウザから離れる必要がある。既存のブラウザを利用する場合にも、先ず、ブラウザとは完全に独立して動作するソフトウエアとしての実装が考えられる。この場合は、ブラウザで開いているサイトとの情報の受け渡しはユーザーが行う必要がある。また、プラグインのようなダイナミックリンクライブラリとして、ユーティリティソフトを既存のブラウザに組み込む方法もある。更には、ブラウザとCOMなどによって連携して動作する方法など、様々な実装方法が考えられる。これらはブラウザ側の対応状況によって、実装可能な実装形態を適宜選択する。以下の実装形態では、登録フェーズを行うプログラムのみを独立のソフトウエアとして実装し、発信フェーズと検証フェーズは、プラグインとして実装する場合について説明を行う。それ以外の実装形態も、当業者であれば、容易に実装可能である。<サイバーネームの登録>この実施例では、サイバーネームの登録は匿名で行われる。この場合、一人のユーザーが、多くのサイバーネームを登録してしまうと、サイバーネームが足りなくなってしまう。従って、むやみに発行依頼ができないような仕組みが必要となる。その目的で、例えば、機械が自動的に読み取ることが難しい不鮮明で歪んだような文字を画面に表示し、ユーザーに読み取らせるCAPTCHAキャプチャシステムを利用することができる。また、適宜、同じIPアドレスからの登録を制限したり、クッキーを利用するようにしてもよい。以下、図1を参照して、サイバーネーム登録の手続きを説明する。この識別名管理システムの管理サーバー10にサイバーネームの登録を希望するユーザーは、先ず、自分のパソコンへユーティリティソフトをインストールする必要がある。このユーティリティソフトを立ち上げて、サイバーネーム登録申請のウィンドウ1を開く。ウィンドウ1には、希望サイバーネームを入力するボックスが表示される。ユーザーはここに希望するサイバーネームを入力する。入力後に更新ボタンをクリックすると、そのサイバーネームが管理サーバー10へ送信されS1、発行可能なサイバーネームが管理サーバー10から返され、発行サイバーネームのボックスに表示されるS2。ただし、発行可能なサイバーネームは、入力されたサイバーネームの先頭にプリフィックスが付加されている。このプリフィックスは、ユニークなサイバーネームを得るためのハッシュ値であり、見た目でもなるべく類似するサイバーネームがないように管理サーバー10側で選択される。プリフィックスの末尾はアンダーバーとなっている。例えば、図1の例ではサイバーネームとしてNuagesを希望し、aZ38Nuagesが発行可能な例として管理サーバー10から返されている。これにより、Nuagesというパターンを持つサイバーネームは、複数のユーザーが利用出来ることになる。この例のように、Base64で利用されている4文字を用いることにすれば、16777216通りのプリフィックスが存在することになる。また、アンダーバーで明確に区切られているので、プリフィックスの文字数は固定しなくても良い。また、管理サーバー10からは、CAPTCHAの歪んだ文字列の画像が送信され、ウィンドウ1に表示される。ユーザーは、この文字列を隣の入力ボックスへ入力しておく必要がある。更に、CAPTCHAの画像を表示した後に、ユーティリティソフトは、公開鍵と秘密鍵のペアを生成する。生成された公開鍵に対応する秘密鍵は、暗号化されパソコンのハードディスクで保管管理されるが、それに必要なパスワードを入力ボックスへ入力しておく必要もある。発行サイバーネームが決まり、ユーザーが申請ボタンをクリックすると、管理サーバー10へ公開鍵が、発行サイバーネームおよびCAPTCHAの入力文字列と共に送信されるS3。管理サーバー10では、CAPTCHAの入力文字列が正しければ、現在日時を仮登録日時として、その発行サイバーネームと受信した公開鍵に互いに関連付けて、管理データベースに保存する。管理サーバー10は、仮登録の完了を通知するメッセージを、ユーザーへ送信するS4。仮登録完了通知を受信したユーティリティソフトは、サイバーネーム、公開鍵および秘密鍵をパソコンのハードディスクへ保存する。ただし、秘密鍵は上記パスワードで暗号化してから保存する。例えば、AES等の既存の共通鍵暗号を使って暗号化できる。又は、SHA512でパスワードを再帰的に例えば、千回以上繰り返し処理し、得られた値を連結して2048ビットのキーとし、そのビット列と秘密鍵とのビット毎の排他的論理和を暗号化された秘密鍵として保存する。復号するにはユーザーが入力したパスワードからキーを計算し、暗号化された秘密鍵との排他的論理和をとれば良い。この実施例では、無駄な登録を排除する目的で、上記の登録は仮登録とし、最初のサイバーネームの利用を行った時を本登録とする。もし、仮登録から一週間以内に本登録がなされなければ、仮登録を抹消するようにする。その場合、ユーザーは最初からやり直さなければならない。<登録情報の明証化>管理データベースの記録は専用のサイトで一般に公開され、誰でもサイバーネームに対応する公開鍵を取得することができる。また、一定期間に登録された記録は、ファイルとしてダウンロードできる。例えば、一週間単位で、その期間に登録されたサイバーネームと公開鍵が登録日と共に、CSVファイル等のリストファイルとしてダウンロード可能に公開される。そして、そのリストファイルのハッシュ値が、新聞などの刊行物に公表される。これを登録情報の明証化と呼ぶS5新聞広告の具体例を図2に示す。また、リストファイルの具体例は、図3に示す。なお、図2の具体例では、2つのハッシュ値を公表している。万一何れか一方が破られても、他方の有効性が保たれる。また、リンク情報の代表値も公表されている。この代表値については後に詳しく説明する。従って、対応する秘密鍵の所有者サイバーネームの使用者は、当該リストファイルを保存しておくことで、管理サーバー10とは無関係に、何時でも自分が当該サイバーネームの使用者であることを証明できる。このリストファイルと公表されたハッシュ値は、利用しているハッシュ関数の安全性が確認されている期間について、有効性が保証される。すなわち、リストファイルと刊行物の組み合わせで、そのサイバーネームに対する公開鍵証明書となっている。その期間を延長するには、それまでのリストファイルと公表されたハッシュ値との組み合わせを、より強固なハッシュ関数で処理し、そのハッシュ値を再度公表すれば良い。その後に作成されるリストファイルは、この強固なハッシュ関数を利用する。<サイバーネームの利用>登録が済むと、掲示板などのWebサイトにユーザーが何らかの意見や情報を書きこむ際などに、サイバーネームを用いて認証を付けることができる。ここでは、子ども手当23000円増額は、大歓迎ですという書き込みを掲示板サイトのエディットボックスへ行う場合を図4を参照して説明する。なお、予めブラウザには必要な処理を行うためのプラグインがインストールしてあるものとする。上記のとおり、暗号化された秘密鍵はローカルのハードディスクに保存されている。従って、メッセージに認証を付けるには公開鍵と秘密鍵が必要なので、プラグインによるローカルのハードディスクへのアクセスが必要となる。プラグインによるローカルのハードディスクを行わない場合には、プラグインの内部に予めダミーの公開鍵と秘密鍵をデータ定数として組み込んでおき、ブラウザへのインストールの前に、プラグインのファイルイメージにおいて、当該ユーザーの公開鍵と暗号化した秘密鍵で上書きするようにすれば良い。この処理はユーティリティソフトが、保存してある公開鍵と暗号化した秘密鍵を用いて、プラグインのインストーラとなって行う。ユーザーは、エディットボックス内にメッセージの書き込みを行う。これに認証をつけるには、認証ボタンを押せば良い。この認証ボタンは、プラグインによってブラウザのウインドウに設けられたものである。すると、図5のようなパスワードの入力画面がでるので、ユーザーはパスワードを入力する。プラグインは、ローカルのハードディスクまたは自身のメモリ領域から公開鍵と暗号化した秘密鍵を読みだし、秘密鍵のほうは入力されたパスワードによって復号しておく。そして、サイバーネームと共にメッセージを送信し、管理サーバーへ認証要求を行う。認証要求を受けた管理サーバーは、先ずサイバーネームの有効期限が切れていないことを確認する。有効期限が切れていれば、その旨通知して処理を終了する。有効期限内であれば、サイバーネームの後に、サイバーネームと現在時刻認証日時を加えた署名用メッセージを作成して、これをユーザープラグインへ返す。この署名用メッセージは図6に示されたようなものである。図6に示された署名用メッセージは、ユーザーへ表示する必要はない。プラグインは、署名用メッセージの認証日時とパソコン内部の現在時刻とを比較し、大きな差異がなければ、署名用メッセージに署名を行って、管理サーバーへ返す。大きな差異があれば、その旨ユーザーへ表示して、署名の是非を確認する。通常は両者に大きな差異はないと考えられる。管理サーバーでは、署名用メッセージを基に、受信したユーザー署名を検証する。検証に失敗すれば、その旨、プラグインへ通知して処理を終了する。検証に成功すれば、署名用メッセージにシリアルナンバーを割り振って認証メッセージを作成して、これをユーザープラグインへ返す。この認証メッセージは図7に示されたようなものである。ここで、シリアルナンバーは、全てのユーザーのメッセージを時系列に並べるもので、16進数図6の括弧内の8桁の数字で表記されている。後述の通り、これらシリアルナンバーは、対応する認証メッセージのハッシュ値に関連付けられることで、このメッセージに対する認証データとなっている。すなわち、サイバーネームに対応してユーザー署名がされていることと、記載されている認証日時が正しいことが、管理サーバーにおいて確認され認証されていることを示している。管理サーバーから認証メッセージを受け取ると、プラグインは、この認証メッセージを用いて、エディットボックスのメッセージを置き換えてから投稿を行う。なお、この実施例では、プラグインが認証要求を行う際に、ブラウザから現在表示中のページのURLを取得し、メッセージと共に、管理サーバーへ送信する。この情報も、管理サーバーのデータベースに記録され、投稿先を示す情報として後述の発言リストで使用する。或る認証メッセージが、確かにそこに含まれるサイバーネームのユーザーによるものかどうかを、第三者が確認するには、ユーザー署名を検証する必要がある。管理サーバーは、ユーザー署名を公開しているので、誰でもそれが可能となっている。万一、ユーザー署名の検証に失敗するようであれば、その責任が管理サーバーにあることは明白である。<メッセージの管理>図8に示すとおり、管理サーバーには、サイバーネームとユーザー公開鍵を関連付けるサイバーネーム管理テーブル61と、全ての認証メッセージを時系列で管理するメッセージ管理テーブル62とが設けられている。サイバーネーム管理テーブル61の各エントリーには、サイバーネームCyNとユーザー公開鍵Kupと、ユーザーの信頼性の目安を示す後述のポイント数Pointsと、ランキング情報Rankingと、登録日Registrationと、有効期限Expirationを格納するフィールドが含まれている。メッセージ管理テーブル62の各エントリーは、各認証メッセージが作成される際に、時系列に割り当てられた連続番号であるシリアルナンバーSerialNoと、保存されている認証メッセージ本文へのポインタpMsgと、当該認証メッセージ本文のハッシュ値hと、署名用メッセージへのユーザー署名SigUと、当該認証メッセージの認証日時Dateと、サイバーネームCyNが格納されている。なお、この例では、ユーザーのブラウザから取得した現在表示中のページのURLのエントリーURL1も含まれている。更に、後述の通り、実際に認証メッセージが掲載されているページのURLのエントリーURL2と、その掲載ページの管理サーバー内キャッシュへのポインタpCacheも含まれている。これらのURL1、2は後述の発言リストで使用する。シリアルナンバーは、全てのメッセージを時系列に並べて付けた連続番号である。これによってメッセージの認証日時の前後関係が特定できる。後述の通り、ここでは、シリアルナンバーを時系列IDとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される図2。また、リンク情報の最後の公表データは、対応するシリアルナンバーと、代表値の組63として管理サーバーでも保存される。上記のとおり、管理サーバーは、ユーザー署名を検証し、メッセージにシリアルナンバーを割り当てる。なので、メッセージに付加されたシリアルナンバーは、認証済みであることを示す認証データとなっている。尚、誰でも管理サーバーへアクセスして、上記データベースの情報を取得できる。例えば、サイバーネームを特定して、サイバーネーム管理テーブル61の該当エントリーの全ての情報を取得できる。また、シリアルナンバーを指定して、メッセージ管理テーブル62の該当エントリーの全ての情報を取得できる。<日時認証>電子データに対して時刻認証を行う為の手段として、タイムスタンプが利用されている。このタイムスタンプは、電子公証や電子署名法でも使用されており、e文書法で電子化が許可された文書の中にも、一部省令でタイムスタンプの利用が義務付けられているものがある。タイムスタンプの実装方法としてよく利用されているのが、リンキングプロトコルである。このリンキングプロトコルは、電子署名の信頼性に依存せずに長期にわたって認証日時における存在証明と非改竄証明を可能とするものである。以下、図9を参照して、本実施例による時刻認証の方法を説明する。シリアルナンバーをiとした場合、対応するリンク情報Lとその前後のリンク情報L、Lは、認証メッセージMsgと認証メッセージMsgの前後関係を特定する情報である。すなわち、リンク情報Lは、リンク情報Lと認証メッセージMsgから算出された情報である。ここでは、リニアリンキングプロトコルを用いる。すなわち、hをハッシュ関数として、リンク情報Lは、Lhihによって算出される数値である。すなわち、リンク情報によって、認証メッセージのチェーンが形成される。ハッシュ関数の特性から、リンク情報Lと認証メッセージMsgは共に、リンク情報Lよりも前の情報である。同様に、リンク情報Lと認証メッセージMsgは、リンク情報Lよりも前の情報である。なので、リンク情報L、L、Lが、認証メッセージMsg、Msgと整合していれば、認証メッセージMsgの認証日時Dateは、認証メッセージMsgの認証日時Dateよりも前でなければならない。もし、Date>Dateならば、少なくとも一方は正しくない。図10を参照して、更に説明する。ここで、リンク情報Lとリンク情報Lは、新聞などの刊行物に公表された代表値である。それらの間の認証メッセージが全て分かれば、j<k<nとして常にDate>Date>Dateであることが確認できる。もし、認証メッセージMsgの認証日時Dateが正しいことが確実であれば、j<m<k<nとしてDate>Date>Dateであることが確実となる。このリニアリンキングプロトコルは、一般的なタイムスタンプサービスで用いられるタイムスタンププロトコルの一つであるが、この実施例では、通常のタイムスタンプサービスよりもシステムとしての信頼性が高くなっている。通常のタイムスタンプサービスの場合、事実上の乱数であるハッシュ値が特定の日時に存在したという証明をするだけである。情報自体はユーザーのみが所有して、一般には公開されない。また、タイムスタンプサービス側は途中のハッシュ値を公開するのみで、情報の内容には関知しない。また、一週間間隔で代表値を刊行物に公開する場合、一週間という期間内の何処に本当の認証日時があるかについては、リニアリンキングプロトコル自体は保証しない。確実なのは、タイムスタンプ間の順序関係のみである。認証日時そのものは、タイムスタンプサービス提供サイトの信頼性に依存する。上記の通り、本実施例でも、シリアルナンバーを時系列IDとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される図2。しかしながら、ここでは認証メッセージMsgは、管理サーバーに保存管理され、また不特定多数のサイトに掲載され公開される。認証メッセージMsgが公開されるということは、そのハッシュ値も事実上公開されるということになる。このハッシュ値は、公開リンク情報を繋ぐ照合用データとなっている。本実施例の場合には、管理サーバーの付与した認証日時に加えて、不特定多数のサイトにも投稿日時と共に認証メッセージが掲載され公開される。この多数の第三者の公開データ特に投稿日時の分だけ、認証日の正しさに対する蓋然性が高くなる。仮に、隣接する代表値の公表日の間に、一つの信頼できるサイトで公開された認証メッセージがあり、そのハッシュ値および投稿日時がリンクチェーンに矛盾なく収まる値であれば、そのリンクチェーンの認証日時の信頼性は、その信頼できるサイトでの投稿日時によって補強されることになる。従って、管理サーバー側からは、隣接する代表値の公表日の間の認証メッセージのハッシュ値と掲載サイトのURLのリストがダウンロード可能に公開される。また、図2のような公表情報の画像データと、刊行物の書誌事項も公開される。希望するユーザーは、このハッシュ値のリストと公表情報のデータを保存しておけば、認証メッセージの投稿日に関する客観的な証拠データとすることができる。<リンク情報の効果>認証日時の信頼性に関して、リンク情報がどのような関連を持っているかについて更に詳しく説明する。図11に、サイバーネーム、ユーザー署名、リンク情報、日時情報管理サーバー付与および日時情報各サイト付与が時系列に並んでいる様子を示す。これらは全て投稿先のサイトで公開される情報である。又、管理サーバーにおいても公開されているので、リンクを辿ることは容易にできる。リンク情報は、投稿先のサイトでは直接は公開されないが、認証メッセージのハッシュ値を用いて、公表されている代表値から算出できる。図12に、日時情報メッセージ内の信頼性が、他の情報とどのように関連しているかを示す。ただし、ハッシュ関数の性質から、リンク情報によって各認証メッセージの前後関係は保証されている。ここでは、或るサイトに掲載されたメッセージ内の日時情報Dateのメッセージを考える。当該サイトでは、この日時情報Dateとは無関係に付与された日時情報DateSと共に、メッセージの掲載を行う。なので、Dateの信頼性とDateSの信頼性は相互に補完する関係にある。すなわち、DateとDateSは一対一に対応している。リンク情報によって各認証メッセージの前後関係は保証されているので、もしi<jであってDate>Dateとなっていれば、DateとDateの何れかが誤っていることになる。この場合、日時情報DateやDateSのチェーンの中で、不自然な方が誤りである可能性が極めて高い。例えば、或るメッセージの日時情報を一週間前の日時情報とする不正を行う場合を考える。まず、管理サーバーにアクセス可能な協力者を得るか、侵入して改竄を行う必要がある。ただ単に、そのメッセージの日時情報を一週間前の日時情報とすると、日時情報Dateの一週間のチェーンの中で、それだけ単調増加の規則から外れていることになる。なので、チェーン自体を再構成する必要がある。一週間のチェーンを全て削除して、それよりも前の日時情報と連結する新たなチェーンを作成する。この場合、削除したチェーンのメッセージが投稿されている各サイトにも侵入して痕跡を消す必要がある。更に、新たなチェーンのメッセージも、各ユーザーが投稿したような痕跡を各サイトに書きこむ必要がある。更には、各ユーザーのパソコンへも侵入して整合性を取る必要性も考えなければならない。このような事は現実的には極めて困難と思われる。すなわち、管理サーバーと、メッセージを発信した各ユーザーと、メッセージが掲載された各サイトの夫々の信頼性とは、夫々に、各日時情報の信頼性と独立に対応している。そして、日時情報に疑念がある場合、ハッシュ関数の一方向性に基づいて、何れの日時情報が正しくないかは容易に推測できる。また、その責任が何処にあるかも明瞭となっている。従って、意図的でない誤りを別とすれば、不正が行われる可能性は非常に低くなっている。<署名の確認>一般ユーザーのメッセージを掲載している掲示板の一例を図13に示す。この閲覧ユーザーのパソコンのブラウザには、上記プラグインがインストールされており、それにより上記認証ボタンと検証ボタンが表示されているものとする。この掲示板の閲覧者が、認証メッセージを検証するには、ブラウザの検証ボタンを押せば良い。するとプラグインは、現在表示されているページの内容を解析して、認証メッセージを特定する。具体的には、メッセージの末尾が、Base64の4文字アンダーバー_サイバーネーム空白格付け後述改行日時201011301152といった形式空白シリアルナンバー括弧内の8桁の16進数という形式となっていれば認証メッセージとしての検証を行う。まず、それらの認証メッセージのハッシュ値を算出する。そして、各認証メッセージのハッシュ値は、対応するシリアルナンバーと共に、管理サーバーに送信する。この例では、上から二番目のメッセージには、認証は付加されていないので、ハッシュ値とシリアルナンバーの組は3つである。管理サーバーでは、受信したハッシュ値と、対応するシリアルナンバーのデータベースのエントリのハッシュ値が同一かどうかを確認する。同一であれば認証済みのメッセージであり、同一でなければ、認証されていないメッセージとなる。更に、管理サーバーは、各認証済みのメッセージについて、当該サイバーネームの有効期限が切れていないことを確認する。そして、各シリアルナンバー毎に、認証の可否とサイバーネームの有効性を通知する。認証されており且つ有効である場合には、対応するサイバーネームから現在の格付けを取得し後述の格付けを決定し、認証確認の通知と共にユーティリティソフトへ送信する。認証情報を受信したプラグインは、図14のように、掲示板の該当する位置に認証結果を付け加える。すなわち、認証が失敗した場合には認証失敗という表示を行う。認証が成功した場合には認証済に現在の格付けを付けて認証済AAといった表示を行う。上から4番目のメッセージでは、投稿時に格付けはAであったが、現在はAAと昇格したことが分かる。更に、プラグインは、認証が成功したサイバーネームに、後述の発言リストのURLへのリンクを設定する。図14では、リンクには下線が付けられている。また、認証されていても、当該サイバーネームの有効期限が切れていれば認証済に格納される情報は、この順位114である。このランキングは、後に説明するポイント数Pointsに基づいて順位付けられる。すなわち、ここでは114番目にポイント数が多いユーザーであることを示している。また、このランキングに基づいて、ユーザーの格付けが行われる。例えば、サイバーネーム全体の中の上位5に含まれていればAAAとし、それ以下で上位15に含まれていればAAとし、更にそれ以下で上位30に含まれていればAとし、更にそれ以下の場合はBとする。この格付けは、認証メッセージに含めて投稿されるので、書き込みを読む際にそのユーザーの格付けが分かって好都合である。ただし、掲示板などに表示されている認証メッセージの格付けの値は、そのメッセージの書き込みの際の格付けの値である。従って、認証確認の時点での格付けの値とは、一般的に一致しないことになる。図14の認証済の表示の右側には、認証確認の時点、すなわち現在の格付けの値が表示される。なお、発言リストの各項目の右下には、当該メッセージの内容と類似した他のユーザーの認証メッセージを表示するためのボタンが示されている。このボタンを押すと、図16のような画面が表示される。ここでは、最上段に当該メッセージが表示され、その下に、内容がより近いものから表示される。これにより、類似のテーマに関する他のユーザーの意見を参考することができる。また、当該メッセージの日付より前のものと後のものを色分けして表示する。このようにすることで、オリジナリティ豊かな内容が含まれていた場合、どのユーザーが最初かを知ることができる。<ポイント数>ポイント数Pointsは、サイバーネームを所有するユーザーの信頼性を示す数値として、各ユーザーによる管理サーバーの利用状況に関する情報から算出される。そのような情報としては次のようなものが考えられる。1当該ユーザーの発言リストを、他のユーザーが表示した回数2当該ユーザーのお気に入りページを、他のユーザーが表示した回数3当該ユーザーのお気に入りページのリンクを、他のユーザーがクリックを行った回数4当該ユーザーのお気に入りページから、他のユーザーが商品の購入を行った回数5当該ユーザーの発言リストの絞込み検索を、他のユーザーが行った回数6当該ユーザーのブログを、他のユーザーが表示した回数7当該ユーザーの発言が引用され、その引用から元の発言が表示された回数8当該ユーザーの発言が引用され、その引用から当該ユーザーの発言リストが表示された回数上記情報に適当な重み付けを行ってから、例えば、計算式Points=Σで累計する。この計算式は、上記項目の番号をiとして、fiは上記項目のi番目の回数、ciはi毎に設定された係数であり、全てのiについての総和がPointsとなることを示している。<著作権>一般ユーザーが発信する場合には、コピペの問題が生じることがある。ユニークで見識の高いメッセージの投稿を見て、それをそのままコピーして自分の認証を付けて、あたかも自分独自のメッセージとして別の掲示板へ投稿するというようなことである。このような場合でも、最初のユーザーが自分の署名を付けていれば、いずれが先かが明瞭となる。コピペを行ったユーザーのサイバーネームの信頼性は低下するであろう。これをポイント数に反映させるには、悪質と判断したユーザーが、対象のサイバーネームのポイントを下げること、つまり減点を行うことを可能とすれば良い。乱用を防ぐために、格付けがA以上のユーザーに限って、自らのポイントを消費して減点を行えるようにする。例えば、格付けAの場合は、自らのポイントの減少分の2倍の減点を行えるようにし、格付けAAの場合は、自らのポイントの減少分の4倍の減点を行えるようにし、格付けAAAの場合は、自らのポイントの減少分の8倍の減点を行えるようにする。通常のメッセージではなく、自作曲、イラスト、詩作といった創作コンテンツをネットで発表する場合には、認証の日付があれば他人の盗作に対して一定の歯止めがかかる。例えば、映像や音楽の場合には、ハッシュ値をメッセージに付加してから認証を行うようにする。図17では、忘却の彼方へという自作曲に映像を付けて、MPEG4のファイルとして発表した例を示している。ここでは、島取への小旅行の記念に曲を作りました。というメッセージに、OblivescencempgSHA2a1yOOj...1jOを加えて、サイバーネームと共に認証を行っている。Oblivescencempgはビデオのファイル名であり、ハッシュ関数としてSHA2を用い、Base64でエンコードしa1yOOj...1jOというハッシュ値が得られたことを示している。例えば、他のユーザーが音楽だけを取り出して、少し変えて自作曲として発表したとする。この場合、先のMPEG4ファイルを発表した認証日時は、盗作であるか否かについての有力な証拠となり得る。<Webサイト認証>Webサイトのページは複数のファイルから構成されている。このようなデータに対して認証を行うには、認証を確認する為のページを別途設けることが便利である。例えば、図18に示したようなWebサイトのトップページの場合、認証ページのURLリンクを記載しておく。ここでは、個別ファイル認証というボタンに認証ページへのリンクが設定されている。この認証ページは、例えば、図19に示したような内容を含んでいる。すなわち、この認証ページには、認証を行うデータ通常はファイルのURLが列挙されている。そして、これらのURLで指定されるデータのハッシュ値に対して上記のとおり認証を行っている。例えば、myhomenejpmember1content1htmというファイルのハッシュ値を計算し、Base64でエンコードしてテキストデータとする。このテキストデータを、通常のメッセージと同様にユーザー署名を付加して、所定のフォーマットにメッセージを組み立てて、サーバーへ認証を依頼する。図19では、このファイルが200612231923に作成され、シリアルナンバー00383093で認証されていることを示している。この場合、認証メッセージは、次のように組み立てられる。すなわち、図20に示したように、ファイル名、ハッシュ関数、ファイルのハッシュ値、サイバーネーム、格付け、認証日時、シリアルナンバー、所定のフォーマットに従って組み合わせれば良い。上記の通り、この認証メッセージのハッシュ値によって認証の確認を行うことができる。Webサイトの作成者が認証を得るには、図20から認証日時、シリアルナンバーを除いたような所定のフォーマットに従って組み立てたメッセージについて、認証を求めれば良い。Webページは度々更新されることがある。この場合、同じURLに関して、認証日時の異なる複数の認証を得るようにしても良い。図19では、myhomenejpmember1content2htmに別々の認証日時を持つ2つのエントリが示されている。<本人認証>上記した方法では、認証を行ったメッセージは、誰でも自由に閲覧できることになる。つまり、サイバーネームによるネット上の活動はすべて公開ということになる。公開したくはないが、サイバーネームで認証を行いたい場合には、登録されているRSA鍵を用いて署名を付ければ良い。その場合、ユーティリティソフトは、メッセージへのユーザー署名を算出するが、管理サーバーへは送信しない。ユーザー署名はBase64でエンコードして、メッセージの最後に署名:という文字列と共に付加する。図21は、電子メールで受信した本人認証付きメッセージを、一般的なメーラーで表示している画面を示している。ここでは2048ビットのRSA署名を用いているので、Base64でエンコードした342文字とやや長いユーザー署名が付加されている。RSAの代わりに224ビットのECDSAを用いれば、ユーザー署名は448ビットとなり、Base64でエンコードした場合75文字まで短くできる。本人認証付きメッセージを検証するには、ユーザー署名を含むメッセージのテキストをコピーして、サイバーネームと共にユーティリティソフトに入力する図22。そして、検証ボタンを押すと、ユーティリティソフトは、管理サーバーにアクセスして、サイバーネームに対応する公開鍵を取得して、メッセージ本文に付けられた署名を検証する。検証に成功すれば、ユーティリティソフトによってUQjSatohさんのメッセージですといった表示がなされる図23。この表示には、そのサイバーネームの現在の格付けも表示される。格付けは管理サーバーから取得する。ここで、発言リスト表示ボタンをクリックすれば、UQjSatohの発言リストを表示できる。また、検証できなければ、UQjSatohさんのメッセージであるとは確認できませんといった表示がなされる図24。UQjSatohが知らないサイバーネームであっても、格付けの値を信頼性の目安とすることができる。また、発言リストを表示して、その人物の信用評価を行うこともできる。UQjSatohが周知のユーザーであれば、その公開鍵を予め保存しておいても良い。また、署名を付加したい場合には、図25のようにメッセージを打ち込んで署名付加のボタンを押す。すると、所定のフォーマットに従って、メッセージの最後に署名を付加して、図22に示したような内容に変換される。ユーザーは、それをコピーして任意のメールソフトで送信すれば良い。<その他の機能>発言リストなどを介して信頼を得ているユーザーに対して直接メールを送りたい場合もある。それには管理サーバーにメール機能を実装すれば良い。このメール機能は、発言リストのウインドウを介して提供される。例えば、図26に示したように、発言リストのウインドウに設けられたメールタブをクリックすることで利用可能とする。また、管理サーバーにブログ機能を実装して、これも発言リストのウインドウに設けられたブログタブをクリックすることで利用可能とする。このブログは、サイバーネームで特定されるユーザーの行ったインターネット上のすべての活動とリンクしているという点で、通常のブログとは異なる。<サイバーネームの無効>各ユーザーは、自分のサイバーネームを無効に出来る。それには、無効の申請を管理サーバーへ署名付きで行えば良い。無効となったサイバーネームと公開鍵の情報も、図2のような新聞広告でハッシュ値が公表されるリストに載せておく。無効にする理由としては、秘密鍵が漏洩してしまった場合などが考えられる。図3では、登録されたサイバーネームのリストの下に無効となったサイバーネームのリストが示されている。その場合、サイバーネーム管理テーブル61の有効期限Expirationフィールドを、無効となった日時で上書きする。また、サイバーネームには有効期限が設定される。格付けがA以上のユーザーの場合には、自動的に有効期限は更新される。有効期限の更新も新規の登録と同様に、新聞による公表が行われる。しかし、格付けがA以下のユーザーでは、一定期間以上サイバーネームの有効利用がない場合、有効期限の更新は行われない。<引用>他人の文章を、そのまま黙って自分の投稿に利用するというのは、余り行儀の良いものではない。しかし、有用な書き込みの再利用はインターネットの利便性を向上させる。この場合、引用先を明記することで、オリジナルの書き手に配慮することができる。それにはシリアルナンバーの表記で足りる。更にサイバーネームを加えておけば、より敬意を払うことになる。図27に具体例を示す。ここではsnの後のシリアルナンバーとCbnの後のサイバーネームが引用先を示している。プラグインは、認証が成功したメッセージに、引用が含まれていれば、シリアルナンバーの表示に引用先のリンクを設定する。また、引用先サイバーネームの表示にそのユーザーの発言リストへのリンクを設定する。閲覧ユーザーが、引用先や発言リストを参照したい場合には、これらのリンクをクリックすれば良い。上記のとおり、このように引用されて発言リストが表示されれば、ポイントを加算するようにする。<収益モデル>図15のような発言リストにはお気に入りタブが含まれている。このお気に入りを選択すると図28のようなウインドウが表示される。このような発言リストを、ネットワークメディアとして利用することで、収益モデルの設計が可能となる。すなわち、ウインドウでお気に入りのタブを選択すれば、そのサイバーネームを所有するユーザーのお薦めの商品やサービスを知ることができる。このお気に入りの内容は、そのユーザーの信頼性が高ければ有効な広告媒体となり得る。また、アフィリエイトプログラムを利用することも可能である。その収益をユーザーとシステム提供者が分け合うことで、システム運営に必要な収益が可能となる。実施例1では、サイバーネームの所有者が、投稿メッセージが自分が発信したもの又は自分が発信したものでない、という事実を証明するには、管理サーバーの信頼性と協力が不可欠である。管理サーバーとは無関係に証明を行うには、以下のようにシールを用いれば良い。シールの付加を除いて、実施例2の実装は、上記実施例1の実装と同じである。この実施例2では、管理サーバーは、図6に示したような署名用メッセージへのユーザー署名を受信し検証すると、このユーザー署名のハッシュ値を算出して、その最後の24ビットをBase64でエンコードすることで4文字のシールSealを生成する。ここでのハッシュ関数としては、SHA-1などを用いれば良い。そして、図29のように、シリアルナンバーの前にこのシールを付加することで認証メッセージとする。メッセージの検証は、シールも含めた認証メッセージのハッシュ値を確認することで行う。図13の具体例に対して、実施例2を適用した場合の認証メッセージを図30に示す。シールも近似的に24ビットの乱数と考えられるので、ユーザー署名の一つのハッシュ値と言える。ユーザー署名と同じビット長を持ち、且つ上記24ビットのハッシュ値と同じハッシュ値を生成するような、別のデータを探すことは困難ではない。しかし、そのデータをユーザー署名とみなして、検証を行った場合に、検証に成功するようなハッシュ値の原像となるような認証メッセージを算出することは困難である。従って、シールを用いれば、各ユーザーは、或る投稿を自分のものである事も、自分のものでない事も管理サーバーとは独立に証明できる。自分のものである事は、メッセージへの署名を作成して、その署名がシールと対応していることを示せば良い。また、自分のものでない事は、メッセージへの署名を作成して、その署名がシールと対応していないことを示せば良い。サイバーネームと公開鍵との対応は、リストのファイルと新聞での公表情報により証明できる。実施例1および実施例2では、メッセージの認証日時の信頼性は、新聞などの刊行物に公表されたリンク情報の代表値に基づいて評価される。その場合、隣接する代表値の公表日の間のメッセージのハッシュ値が必要となる。なので、管理サーバーではそれらのハッシュ値を纏めて公開する。管理サーバーに問題が生じて、ハッシュ値が利用できない場合には、シリアルナンバー等からメッセージを検索することも考えられる。しかし、必ずしも必要な全てのメッセージが検索出来るとは限らない。実施例3では、隣接するメッセージの前後関係を、それらメッセージのみから確定する方法を提案する。この実施例では、図31に示したように、認証メッセージそのものにリンク情報を含ませる。図13の具体例に対して、実施例3を適用した場合の認証メッセージを図32に示す。すなわち、図32に示したように、認証メッセージの最後にBase64でエンコードされた44文字のリンク情報が加わっている。このリンク情報は、ユーザー署名を検証した後に、シリアルナンバーと同時に付与され、認証メッセージとしてユーザーに返される。図31の例では、i003F4959、LmU0OjBha...gICACAgIG0aとなっている。シリアルナンバーiは丸括弧で括られている。シリアルナンバーの前にシールが付加されている。図33を参照して、更に説明する。認証メッセージMsgには、シリアルナンバーiだけでなくリンク情報Lも含まれている。なので、認証メッセージMsgのみで、次のリンク情報Lを算出することが出来る。このリンク情報Lは次の認証メッセージMsgに表示される。従って、認証メッセージMsgの認証日時よりも前に、認証メッセージMsgが存在していたことが、リンク情報Lによって証明される。この実施例では、各々のリンク情報が不特定多数のサイトに掲載されるので、代表値の刊行物への掲載は必ずしも要求されない。認証メッセージ同士が互いの認証日時を補強しあっている。また、認証メッセージにおけるリンク情報の表記では、最初の12文字の後にスペースが挿入されている。これは最初の12文字を単語として独立させるためである。もし、最初の12文字に等の単語を分離する文字が含まれていれば、それ以後に12文字の文字列を単語として独立させるためのスペースや改行コードを挿入する。この単語は、認証メッセージの掲載ページの検索を行う際に、検索タームとして使用する。12文字の文字列は72bitの数値に対応し、ハッシュ関数の性質から擬似乱数とみなされる。従って、検索結果は掲載ページのみとなる可能性が極めて高い。但し、一般的なサーチエンジンは、インデックスの更新に数日ないし一週間以上かかることがあるので、認証後、しばらくは検索にかからないこともある。このようにすることで、仮に、管理サーバーに問題が生じても、リンク情報を検索サイトで検索することでリンクを辿ることは容易にできる。例えば、或る認証メッセージMsgに含まれているリンク情報と、その認証メッセージMsgのハッシュ値から、次の認証メッセージMsgに含まれるべきリンク情報が得られる。このリンク情報の表示に含まれるべき単語を検索すれば、当該次の認証メッセージMsgを確認できる。更に、同様に認証メッセージMsgに含まれるべきリンク情報の単語を検索すれば、認証メッセージMsgを確認できる。これらの認証メッセージMsg、Msgは、夫々に認証メッセージMsgの存在を保証している。