(57)【要約】      （修正有）【課題】インターネットにおいて個人レベルで、また匿名であっても自己証明に電子署名を利用できる環境を提供する。【解決手段】識別名管理システムは、複数のユーザーの各々から登録要求を受信し、前記登録要求の各々と共に、対応するユーザー側で生成された公開鍵と秘密鍵のペアのうち公開鍵のみを受信し、前記登録要求に応じて、互いに異なるユーザー識別名を決定し、このユーザー識別名を対応する前記公開鍵に関連付けてデータベースに登録し、前記ユーザーに対して、前記ユーザー識別名が前記公開鍵に関連付けられて登録されたことを通知し、互いに関連付けられた前記公開鍵とユーザー識別名を、インターネットを介して、一般に公開する。【選択図】図１
2012248915.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザーの各々から登録要求を受信し、
前記登録要求の各々と共に、対応するユーザー側で生成された公開鍵と秘密鍵のペアのうち公開鍵のみを受信し、
前記登録要求に応じて、互いに異なるユーザー識別名を決定し、
このユーザー識別名を対応する前記公開鍵に関連付けてデータベースに登録し、
前記ユーザーに対して、前記ユーザー識別名が前記公開鍵に関連付けられて登録されたことを通知し、
互いに関連付けられた前記公開鍵とユーザー識別名を、インターネットを介して、一般に公開する
ことを特徴とする識別名管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットにおいて、ユーザーにユニークな識別名を割り当て、登録管理するシステムに関するものである。
【背景技術】
【０００２】
現在、世界のインターネット・ユーザー数は２０億人を超え、爆発的な勢いで増加している。その利用者の大部分が何らかの形でツイッターやブログ、ＳＮＳ、掲示板といったコミュニティサービスを利用している。コミュニティサービスでは、自由に情報を発信したり、意見を述べ合うことが可能となっている（特許文献１）。また、リアルタイム検索の実現により、現在進行中の出来事についての有用な情報が得られるようになり、日常生活に大きな変化が起こりつつある。
【０００３】
一方で、インターネットでは、個人情報の漏洩は深刻な被害に結びつく可能性があるため、大半の利用は匿名で行われている。サービス提供側へは個人情報を開示することはあっても、ユーザー同士は、互いに実名などは明かさないことが多い。一方で、匿名によるコミュニケーションには信用問題があるので、実名を前提としたサービスも有効に機能している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１４６４５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
プライバシーの観点から匿名の利用は必要と言えるが、一方で、ネットワーク上での発言は、「こういう意見もある」といった、その場限りの点の集まりとなってしまう。「誰」が言っているのかという情報は、その意見の有用性の評価にとって重要であるし、「こういう意見を言っている人は、他にどんなことを言っているのか」といった情報もまた信頼性を評価する参考とするなど、非常に有用である。また、バラバラの匿名個人が発信する情報には、責任がないので、信頼性の欠ける情報が気軽に発信されてしまうこともある。
【０００６】
ツイッターなどでは、ユーザー名によって、ある程度までは匿名個人を識別できる。また、著名人では、本人確認済みのアカウントとすることで、なりすましや紛らわしいユーザー名による混乱を避けることが出来る。しかしながら、ツイッター以外にも、他のコミュニティサービスや、ネットオークションや、通販サイトのユーザーレビュー、新聞サイトの投稿欄や、Q&Aへの書き込み、ＳＮＳやブログなど、一般個人からの情報発信の場所は数多くある。これらを含めたインターネット上で、匿名個人を統一的に識別し確実に検証する手段は存在しない。
【０００７】
一般に或る情報が有用なものかどうかは、その情報の提供ソースが重要な手がかりとなる。もし、有力な新聞サイトの社説であれば、読んでみる価値があると考える。また、信頼できる書き手であれば、時間を使って読もうと考える。特に、地震や噴火などの災害において、しばしば流言飛語や風評被害などが問題となる。緊急性を要する事態においては、情報の信憑性についての一定の手掛かりがあると被害が抑制されることがある。
【０００８】
大手サイト、例えば新聞社のサイトならば、一定レベルの信頼性は期待できる。しかし、次の３つの点では一般ユーザーによる情報発信の方が優位にある。一つは、情報の細かさである。電気製品に関して言えば、或る特定機種の或る特定操作に関わる不具合といったものや、或る特定地域の或る特定分野に関わる情報といったものは、個人レベルの情報に頼らざるを得ないことが多い。もう一つは、情報の速さである。現在進行形の事象については、その場に居合わせた一般ユーザーの情報が最も早い。更に、情報の量という点でも、圧倒的な数の一般ユーザーが優位にある。
【０００９】
また、情報は獲得するだけでなく、その内容を正しく解釈し信憑性を判断する必要がある。ところが、日々発信される情報は、個人の許容量をはるかに超えている。各自の得意分野における個人レベルの分業といった作業が不可欠と思われる。ところが誤った情報または有害な情報が多く混じっていると、良質の正しい情報を選別することは困難である。以下に、不必要な情報を選別するかが、集合知のメリットを最大限に活かすには、如何にして不必要な情報を選別するかがポイントとなる。
【００１０】
一方で、或る人物が新聞サイトの投稿欄へ投稿する場合、その人物は、一定の労力と時間を費やす。そして、その情報が他の人々にとって有用なものならば、その情報には一定の価値が存在する。しかし、その人物が無名の人物であれば、その投稿は単発の情報であり、そのサイトを閲覧した人だけが参照するその時だけの情報となっている。
【００１１】
投稿した人物が無名であれば、その人物が得るものは、投稿したという自己満足だけにとどまってしまう。すなわち、その投稿はその場限りのものであり、一般にはその人物の信用度を向上させることはない。なので、労力と時間を費すメリットは小さく、時間をかけて良質な情報を提供しようとする意欲は出てこない。
【００１２】
これに対して実名により投稿を行うという方法もある。実際、実名投稿を義務付けているＳＮＳも存在する。しかしながら、実名の公表にはプライバシーの侵害など大きなリスクが伴う。又、その実名自体の信頼性についても疑念が残る。実名確認のために電子証明書に求められるような煩雑な手続きを行うことも考えられるが、費用がかかる上に面倒なので一般ユーザーの理解は得られない。更に、実名投稿は特定のＳＮＳに限定されており、インターネットの様々なメディアにおける横の関係はバラバラである。更に、同一実名や類似実名も非常に多い。
【００１３】
もう一つの課題として、非常にユニークで価値ある投稿を行っても、他人に剽窃されてしまう可能性があるという点がある。特に、エッセイ、映像や音楽といった創作物については、創作証明が出来ないことは、発表や流布を妨げる大きな要因となっている。
【００１４】
また、ＰＫＩは主体の特定に利用できるが、その原理的な有効性にもかかわらず、少なくとも個人レベルでは、主にその一方向についてのみ普及している。すなわち、サービスの提供側といった法人が、公開鍵証明書を持ち、サービスに関する情報に電子署名を行い、それを一般の個人が確認してサービスを利用するといった利用が大部分である。
【００１５】
本来は、個人も電子証明書を持ち、電子署名を行うことで、インターネットの可能性は大きく拡がるはずであるが、そのようは利用は例外的と言って良い。実際、個人が電子証明書を利用する場面というのは、非常に限られている。
【００１６】
この理由は、やはりＰＫＩの導入には煩雑さがある為と思われる。現在では、どうしても必要な場合には、認証局に申し込みを行い、必要な手続きに従って個人の電子証明書を取得する。これには手間と時間だけでなく費用もかかる。また有効期間にも気を配る必要がある。
【００１７】
そして、その電子証明書はそのユーザー個人を特定するものなので、印章と同様にその管理を慎重に行う必要がある。ある意味では、印章よりももっと直接にユーザー個人を特定する機能を有するので、もしも漏洩すれば、悪用される危険性がより高いと言える。更に、個人ユーザーが、実名によってインターネット上で活動する場合には、プライバシーに関するリスクが伴う。
【００１８】
従って、本発明の目的は、個人レベルで、自己証明に電子署名を気軽に利用出来る環境を提供することである。
【００１９】
本発明の他の目的は、匿名であっても電子署名を利用出来る環境を提供することである。
【００２０】
本発明の更に他の目的は、個々のユーザーにユニークな識別名を与え、その識別名によってインターネット上に発信された情報に対して、その出自を明確にして信頼性の評価基準を与えることである。
【課題を解決するための手段】
【００２１】
上記課題を解決するために、本発明の識別名管理システムは、複数のユーザーの各々から登録要求を受信し、前記登録要求の各々と共に、対応するユーザー側で生成された公開鍵と秘密鍵のペアのうち公開鍵のみを受信し、前記登録要求に応じて、互いに異なるユーザー識別名を決定し、このユーザー識別名を対応する前記公開鍵に関連付けてデータベースに登録し、前記ユーザーに対して、前記ユーザー識別名が前記公開鍵に関連付けられて登録されたことを通知し、互いに関連付けられた前記公開鍵とユーザー識別名を、インターネットを介して、一般に公開することを特徴とする。
【発明の効果】
【００２２】
本発明の識別名管理システムによれば、インターネットで情報の発信を行うユーザーは、その識別名において信用を累積させることができる。また、識別名の利用を匿名で行うことで、現実生活とは切り離すことができるので、プライバシーに関するリスクを回避できる。
【００２３】
更に、本発明の識別名管理システムによれば、インターネットに有用な情報を発信することが、直接にユーザーの利益となる為、各ユーザーは積極的に有用な情報の発信を行うようになり、インターネット上の情報が豊かとなり、公共の利益につながる。
【００２４】
更に、本発明の識別名管理システムによれば、インターネットを利用する一般のユーザーは、情報の有用性や信頼性を、その情報の発信者によって評価することが可能となり、より安心してその情報を利用することが可能となる。
【図面の簡単な説明】
【００２５】
【図１】図１は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネーム登録の手続きを説明する図である。
【図２】図２は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネームと公開鍵と対応を記載したリストファイルのハッシュ値を公表する為の新聞広告の具体例を示す図である。
【図３】図３は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネームと公開鍵と対応を記載したリストファイルの具体例を示す図である。
【図４】図４は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネームで認証を行う手続きを説明する図である。
【図５】図５は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネームで認証を行う際に表示される、パスワード入力画面を示す図である。
【図６】図６は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネームで認証を行う際にユーザーが署名を行うべきメッセージの具体例を示す図である。
【図７】図７は、本発明の実施例１に係る識別名管理システムにおいて、サイバーネームで認証されたメッセージの具体例を示す図である。
【図８】図８は、本発明の実施例１に係る識別名管理システムとして実装された管理サーバーに設けられているサイバーネーム管理テーブルとメッセージ管理テーブルを説明する図である。
【図９】図９は、本発明の実施例１に係る識別名管理システムにおけるリンキング・プロトコルの実装方法を示す図である。
【図１０】図１０は、本発明の実施例１に係る識別名管理システムにおけるリンキング・プロトコルの効果を説明する図である。
【図１１】図１１は、本発明の実施例１に係る識別名管理システムのリンク情報において、日時情報（メッセージ内）の信頼性が、他の情報とどのように関連しているかを説明する図である。
【図１２】図１２は、本発明の実施例１に係る識別名管理システムのリンク情報が認証日時の信頼性に関してどのような関連を持っているかについて説明する図である。
【図１３】図１３は、本発明の実施例１に係る識別名管理システムによって認証されたメッセージを含む、一般ユーザーのメッセージを掲載している掲示板の具体例を示す図である。
【図１４】図１４は、図１３の掲示板の画面を表示しているブラウザにおいて、識別名管理システムに対応したプラグインによって、表示されている各メッセージの認証を検証した結果が表示されている画面を示す図である。
【図１５】図１５は、本発明の実施例１に係る識別名管理システムにおいて生成された発言リストがブラウザによって表示されている画面を示す図である。
【図１６】図１６は、本発明の実施例１に係る識別名管理システムにおいて、特定のメッセージと類似したメッセージが抽出され、ブラウザによって表示されている画面を示す図である。
【図１７】図１７は、本発明の実施例１に係る識別名管理システムにおいて、映像や音楽コンテンツに対して認証が行われる例を示す図である。
【図１８】図１８は、本発明の実施例１に係る識別名管理システムにおいて、認証が行われたWebサイトの例を示す図である。
【図１９】図１９は、本発明の実施例１に係る識別名管理システムにおいて、Webサイトの各ファイルに対する認証データを表示している例を示す図である。
【図２０】図２０は、図１９の認証データから構成された、ファイルの認証を示す認証メッセージの例を示す図である。
【図２１】図２１は、電子メールの本文に対して、本発明の実施例１に係る識別名管理システムにおいて登録された公開鍵で検証可能な電子署名を付けた具体例を示す図である。
【図２２】図２２は、図２１の電子メールのテキストを、ユーティリティソフトで検証する場合を説明する図である。
【図２３】図２３は、図２２のユーティリティソフトによる検証結果を示す図である。
【図２４】図２４は、図２２のユーティリティソフトによる検証結果を示す図である。
【図２５】図２５は、図２２のユーティリティソフトに打ち込んだ電子メールの本文に対して、本発明の実施例１に係る識別名管理システムにおいて登録された公開鍵で検証可能な電子署名を付ける手順を説明する図である。
【図２６】図２６は、本発明の実施例１に係る識別名管理システムにおいて生成された発言リストからメールの送受信を行う場合を説明する図である。
【図２７】図２７は、本発明の実施例１に係る識別名管理システムにおいて認証されたメッセージを引用する場合を説明する図である。実装された管理サーバーに設けられているサイバーネーム管理テーブルとメッセージ管理テーブルを説明する図である。
【図２８】図２８は、本発明の実施例１に係る識別名管理システムにおいて生成された発言リストから、そのユーザーのお気に入りを表示する場合を説明する図である。
【図２９】図２９は、本発明の実施例２に係る識別名管理システムにおいて認証されたメッセージの具体例を示す図である。
【図３０】図３０は、本発明の実施例２に係る識別名管理システムにおいて認証されたメッセージを含む、一般ユーザーのメッセージを掲載している掲示板の具体例を示す図である。
【図３１】図３１は、本発明の実施例３に係る識別名管理システムにおいて認証されたメッセージと、サイバーネーム管理テーブルとメッセージ管理テーブルを説明する図である。
【図３２】図３２は、本発明の実施例３に係る識別名管理システムにおいて認証されたメッセージを含む、一般ユーザーのメッセージを掲載している掲示板の具体例を示す図である。
【図３３】図３３は、本発明の実施例３に係る識別名管理システムにおいて、リンク情報がどのように局所的に認証日時の信頼性を証明するかを説明する図である。
【発明を実施するための形態】
【００２６】
電子署名アルゴリズムにおいては、平文を署名鍵で処理することで署名を生成し、署名の検証を検証鍵で行う。しかし、データベースにおいては、各レコードにユニークな情報のみが問題となる。従って、この明細書においては、適宜、各鍵ペアにユニークな検証鍵情報を公開鍵と呼び、各鍵ペアの秘匿される署名鍵情報を秘密鍵と呼ぶこととする。例えば、RSA署名では、平文cと署名値sとの関係は以下の通りである。
c = s^e mod n
s = c^d mod n
【００２７】
つまり、平文cに対して、dとnを用いて署名値sを計算できる。また、署名値sに対して、eとnを用いて平文cを計算できる。ここで、署名鍵はdとnであり、検証鍵は、eとnとなっている。通常、eは予め一定の数に決めておくので、実質的な検証鍵、つまり各レコードにユニークな公開鍵はnである。また、nが公開されているので、実質的な秘匿すべき署名鍵(秘密鍵)はdである。
【００２８】
この明細書でも、eは予め一定の数に決めておく。従って、以下の記述では、dのみを秘密鍵と呼び、nのみを公開鍵と呼ぶことにする。また、以下の記述では、パディングやハッシュ処理など平文への前処理も含めて署名の処理とする。
【実施例１】
【００２９】
本発明の実施例１に関わる識別名管理システムは、インターネットに接続し、識別名を管理する管理サーバーとして実装される。この管理サーバーと通信して識別名を利用する為に、ユーザーのパソコン側には専用のユーティリティソフトがインストールされる。管理サーバーでは、個々の匿名ユーザーに対して、識別名としてユニークなサイバーネームを発行し、このサイバーネームを対応する匿名ユーザーの公開鍵に関連付けて公開する。個々のサイバーネームがユニークであることは、管理サーバーが管理し保証するが、全て公開されるので誰でも重複の有無を確認できる。
【００３０】
パソコンのユーティリティソフトでは、公開鍵と秘密鍵のペアを生成し保存する。ただし秘密鍵は暗号化しておく。そして、その公開鍵とサイバーネームを関連付けて登録を行うように、管理サーバーに依頼する。秘密鍵は管理サーバーへは送信されず、ユーザーが自己責任において秘匿する。また、ユーザーがメッセージを投稿する際に、署名をすることでサイバーネームで認証を付けたり、他人のメッセージの認証を検証したりすることができる。この実施例では、署名アルゴリズムとして2048ビットのRSAを用いるものとする。
【００３１】
なお、管理サーバーとユーザーとは、ＳＳＬで保護された通信を行うが、このＳＳＬはＴＬＳ(Transport Layer Security)も含むものとする。特に、必須ではないが、クライアント認証も行うことが好ましい。この場合は、サイバーネームに関連付けられた公開鍵を用いると便利である。
【００３２】
識別名管理システムの基本的な機能は、インターネットのユーザーが、個人情報を開示すること無く、電子署名を利用出来るようにするものである。その為に、各ユーザーの識別名と公開鍵を対応付けて、登録し一般に公開する。
【００３３】
これによって各ユーザーは、インターネットにおける自分の活動に対して、電子署名を付けることで他人と明確に区別し、自分の識別名によって、インターネットにおけるアイデンティティを確立することが出来る。
【００３４】
＜実装形態＞
この識別名管理システムの動作フェーズとしては、サイバーネームと公開鍵を関連付けて管理サーバーへ登録する登録フェーズと、ユーザーがメッセージ等の発信データに署名して情報発信を行う発信フェーズと、他人の発信情報の認証を検証する検証フェーズがある。
【００３５】
また、ユーザー側のユーティリティソフトの実装形態としては、ブラウザの機能を持った単独で動作する独立のソフトウエアとして実装する場合と、既存のブラウザを利用する場合がある。独立のソフトウエアの場合には、インターフェースの自由度は高いが、ユーザーは使い慣れたブラウザから離れる必要がある。
【００３６】
既存のブラウザを利用する場合にも、先ず、ブラウザとは完全に独立して動作するソフトウエアとしての実装が考えられる。この場合は、ブラウザで開いているサイトとの情報の受け渡しはユーザーが行う必要がある。また、プラグインのようなダイナミックリンク・ライブラリとして、ユーティリティソフトを既存のブラウザに組み込む方法もある。更には、ブラウザとCOMなどによって連携して動作する方法など、様々な実装方法が考えられる。これらはブラウザ側の対応状況によって、実装可能な実装形態を適宜選択する。
【００３７】
以下の実装形態では、登録フェーズを行うプログラムのみを独立のソフトウエアとして実装し、発信フェーズと検証フェーズは、プラグインとして実装する場合について説明を行う。それ以外の実装形態も、当業者であれば、容易に実装可能である。
【００３８】
＜サイバーネームの登録＞
この実施例では、サイバーネームの登録は匿名で行われる。この場合、一人のユーザーが、多くのサイバーネームを登録してしまうと、サイバーネームが足りなくなってしまう。従って、むやみに発行依頼ができないような仕組みが必要となる。その目的で、例えば、機械が自動的に読み取ることが難しい不鮮明で歪んだような文字を画面に表示し、ユーザーに読み取らせるCAPTCHA（キャプチャ）システムを利用することができる。また、適宜、同じIPアドレスからの登録を制限したり、クッキーを利用するようにしてもよい。
【００３９】
以下、図１を参照して、サイバーネーム登録の手続きを説明する。この識別名管理システムの管理サーバー１０にサイバーネームの登録を希望するユーザーは、先ず、自分のパソコンへユーティリティソフトをインストールする必要がある。このユーティリティソフトを立ち上げて、サイバーネーム登録申請のウィンドウ１を開く。
【００４０】
ウィンドウ１には、希望サイバーネームを入力するボックスが表示される。ユーザーはここに希望するサイバーネームを入力する。入力後に更新ボタンをクリックすると、そのサイバーネームが管理サーバー１０へ送信され（Ｓ１）、発行可能なサイバーネームが管理サーバー１０から返され、発行サイバーネームのボックスに表示される（Ｓ２）。
【００４１】
ただし、発行可能なサイバーネームは、入力されたサイバーネームの先頭にプリフィックスが付加されている。このプリフィックスは、ユニークなサイバーネームを得るためのハッシュ値であり、見た目でもなるべく類似するサイバーネームがないように管理サーバー１０側で選択される。プリフィックスの末尾はアンダーバーとなっている。例えば、図１の例ではサイバーネームとしてNuagesを希望し、aZ38_Nuagesが発行可能な例として管理サーバー１０から返されている。
【００４２】
これにより、****_Nuagesというパターンを持つサイバーネームは、複数のユーザーが利用出来ることになる。この例のように、Base64で利用されている４文字を用いることにすれば、16,777,216通りのプリフィックスが存在することになる。また、アンダーバー"_"で明確に区切られているので、プリフィックスの文字数は固定しなくても良い。
【００４３】
また、管理サーバー１０からは、CAPTCHAの歪んだ文字列の画像が送信され、ウィンドウ１に表示される。ユーザーは、この文字列を隣の入力ボックスへ入力しておく必要がある。更に、CAPTCHAの画像を表示した後に、ユーティリティソフトは、公開鍵と秘密鍵のペアを生成する。生成された公開鍵に対応する秘密鍵は、暗号化されパソコンのハードディスクで保管管理されるが、それに必要なパスワードを入力ボックスへ入力しておく必要もある。
【００４４】
発行サイバーネームが決まり、ユーザーが申請ボタンをクリックすると、管理サーバー１０へ公開鍵が、発行サイバーネームおよびCAPTCHAの入力文字列と共に送信される（Ｓ３）。管理サーバー１０では、CAPTCHAの入力文字列が正しければ、現在日時を仮登録日時として、その発行サイバーネームと受信した公開鍵に互いに関連付けて、管理データベースに保存する。管理サーバー１０は、仮登録の完了を通知するメッセージを、ユーザーへ送信する（Ｓ４）。
【００４５】
仮登録完了通知を受信したユーティリティソフトは、サイバーネーム、公開鍵および秘密鍵をパソコンのハードディスクへ保存する。ただし、秘密鍵は上記パスワードで暗号化してから保存する。例えば、AES等の既存の共通鍵暗号を使って暗号化できる。又は、SHA-512でパスワードを再帰的に（例えば、千回以上）繰り返し処理し、得られた値を連結して2048ビットのキーとし、そのビット列と秘密鍵とのビット毎の排他的論理和を暗号化された秘密鍵として保存する。復号するにはユーザーが入力したパスワードからキーを計算し、暗号化された秘密鍵との排他的論理和をとれば良い。
【００４６】
この実施例では、無駄な登録を排除する目的で、上記の登録は仮登録とし、最初のサイバーネームの利用を行った時を本登録とする。もし、仮登録から一週間以内に本登録がなされなければ、仮登録を抹消するようにする。その場合、ユーザーは最初からやり直さなければならない。
【００４７】
＜登録情報の明証化＞
管理データベースの記録は専用のサイトで一般に公開され、誰でもサイバーネームに対応する公開鍵を取得することができる。また、一定期間に登録された記録は、ファイルとしてダウンロードできる。例えば、一週間単位で、その期間に登録されたサイバーネームと公開鍵が登録日と共に、ＣＳＶファイル等のリストファイルとしてダウンロード可能に公開される。そして、そのリストファイルのハッシュ値が、新聞などの刊行物に公表される。これを登録情報の明証化と呼ぶ（Ｓ５）
【００４８】
新聞広告の具体例を図２に示す。また、リストファイルの具体例は、図３に示す。なお、図２の具体例では、２つのハッシュ値を公表している。万一何れか一方が破られても、他方の有効性が保たれる。また、リンク情報の代表値も公表されている。この代表値については後に詳しく説明する。
【００４９】
従って、対応する秘密鍵の所有者（サイバーネームの使用者）は、当該リストファイルを保存しておくことで、管理サーバー１０とは無関係に、何時でも自分が当該サイバーネームの使用者であることを証明できる。このリストファイルと公表されたハッシュ値は、利用しているハッシュ関数の安全性が確認されている期間について、有効性が保証される。すなわち、リストファイルと刊行物の組み合わせで、そのサイバーネームに対する公開鍵証明書となっている。
【００５０】
その期間を延長するには、それまでのリストファイルと公表されたハッシュ値との組み合わせを、より強固なハッシュ関数で処理し、そのハッシュ値を再度公表すれば良い。その後に作成されるリストファイルは、この強固なハッシュ関数を利用する。
【００５１】
＜サイバーネームの利用＞
登録が済むと、掲示板などのWebサイトにユーザーが何らかの意見や情報を書きこむ際などに、サイバーネームを用いて認証を付けることができる。ここでは、「子ども手当2-3000円増額は、大歓迎です」という書き込みを掲示板サイトのエディットボックスへ行う場合を図４を参照して説明する。
【００５２】
なお、予めブラウザには必要な処理を行うためのプラグインがインストールしてあるものとする。上記のとおり、暗号化された秘密鍵はローカルのハードディスクに保存されている。従って、メッセージに認証を付けるには公開鍵と秘密鍵が必要なので、プラグインによるローカルのハードディスクへのアクセスが必要となる。
【００５３】
プラグインによるローカルのハードディスクを行わない場合には、プラグインの内部に予めダミーの公開鍵と秘密鍵をデータ（定数）として組み込んでおき、ブラウザへのインストールの前に、プラグインのファイルイメージにおいて、当該ユーザーの公開鍵と暗号化した秘密鍵で上書きするようにすれば良い。この処理はユーティリティソフトが、保存してある公開鍵と暗号化した秘密鍵を用いて、プラグインのインストーラとなって行う。
【００５４】
ユーザーは、エディットボックス内にメッセージの書き込みを行う。これに認証をつけるには、認証ボタンを押せば良い。この認証ボタンは、プラグインによってブラウザのウインドウに設けられたものである。すると、図５のようなパスワードの入力画面がでるので、ユーザーはパスワードを入力する。プラグインは、ローカルのハードディスクまたは自身のメモリ領域から公開鍵と暗号化した秘密鍵を読みだし、秘密鍵のほうは入力されたパスワードによって復号しておく。そして、サイバーネームと共にメッセージを送信し、管理サーバーへ認証要求を行う。
【００５５】
認証要求を受けた管理サーバーは、先ずサイバーネームの有効期限が切れていないことを確認する。有効期限が切れていれば、その旨通知して処理を終了する。有効期限内であれば、サイバーネームの後に、サイバーネームと現在時刻（認証日時）を加えた署名用メッセージを作成して、これをユーザー（プラグイン）へ返す。この署名用メッセージは図６に示されたようなものである。
【００５６】
図６に示された署名用メッセージは、ユーザーへ表示する必要はない。プラグインは、署名用メッセージの認証日時とパソコン内部の現在時刻とを比較し、大きな差異がなければ、署名用メッセージに署名を行って、管理サーバーへ返す。大きな差異があれば、その旨ユーザーへ表示して、署名の是非を確認する。通常は両者に大きな差異はないと考えられる。
【００５７】
管理サーバーでは、署名用メッセージを基に、受信したユーザー署名を検証する。検証に失敗すれば、その旨、プラグインへ通知して処理を終了する。検証に成功すれば、署名用メッセージにシリアルナンバーを割り振って認証メッセージを作成して、これをユーザー（プラグイン）へ返す。この認証メッセージは図７に示されたようなものである。ここで、シリアルナンバーは、全てのユーザーのメッセージを時系列に並べるもので、１６進数（図６の括弧内の８桁の数字）で表記されている。
【００５８】
後述の通り、これらシリアルナンバーは、対応する認証メッセージのハッシュ値に関連付けられることで、このメッセージに対する認証データとなっている。すなわち、サイバーネームに対応してユーザー署名がされていることと、記載されている認証日時が正しいことが、管理サーバーにおいて確認され認証されていることを示している。
【００５９】
管理サーバーから認証メッセージを受け取ると、プラグインは、この認証メッセージを用いて、エディットボックスのメッセージを置き換えてから投稿を行う。なお、この実施例では、プラグインが認証要求を行う際に、ブラウザから現在表示中のページのＵＲＬを取得し、メッセージと共に、管理サーバーへ送信する。この情報も、管理サーバーのデータベースに記録され、投稿先を示す情報として後述の発言リストで使用する。
【００６０】
或る認証メッセージが、確かにそこに含まれるサイバーネームのユーザーによるものかどうかを、第三者が確認するには、ユーザー署名を検証する必要がある。管理サーバーは、ユーザー署名を公開しているので、誰でもそれが可能となっている。万一、ユーザー署名の検証に失敗するようであれば、その責任が管理サーバーにあることは明白である。
【００６１】
＜メッセージの管理＞
図８に示すとおり、管理サーバーには、サイバーネームとユーザー公開鍵を関連付けるサイバーネーム管理テーブル６１と、全ての認証メッセージを時系列で管理するメッセージ管理テーブル６２とが設けられている。
【００６２】
サイバーネーム管理テーブル６１の各エントリーには、サイバーネーム（CyN）とユーザー公開鍵（Kup）と、ユーザーの信頼性の目安を示す後述のポイント数（Points）と、ランキング情報（Ranking）と、登録日（Registration）と、有効期限（Expiration）を格納するフィールドが含まれている。
【００６３】
メッセージ管理テーブル６２の各エントリーは、各認証メッセージが作成される際に、時系列に割り当てられた連続番号であるシリアルナンバー（Serial No.）と、保存されている認証メッセージ本文へのポインタ（pMsg）と、当該認証メッセージ本文のハッシュ値h(Msg)と、署名用メッセージへのユーザー署名SigUと、当該認証メッセージの認証日時（Date）と、サイバーネームCyNが格納されている。
【００６４】
なお、この例では、ユーザーのブラウザから取得した現在表示中のページのＵＲＬのエントリーＵＲＬ１も含まれている。更に、後述の通り、実際に認証メッセージが掲載されているページのＵＲＬのエントリーＵＲＬ２と、その掲載ページの管理サーバー内キャッシュへのポインタｐＣａｃｈｅも含まれている。これらのＵＲＬ１、２は後述の発言リストで使用する。
【００６５】
シリアルナンバーは、全てのメッセージを時系列に並べて付けた連続番号である。これによってメッセージの認証日時の前後関係が特定できる。後述の通り、ここでは、シリアルナンバーを時系列ＩＤとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される（図２）。また、リンク情報の最後の公表データは、対応するシリアルナンバーと、代表値の組６３として管理サーバーでも保存される。
【００６６】
上記のとおり、管理サーバーは、ユーザー署名を検証し、メッセージにシリアルナンバーを割り当てる。なので、メッセージに付加されたシリアルナンバーは、認証済みであることを示す認証データとなっている。
【００６７】
尚、誰でも管理サーバーへアクセスして、上記データベースの情報を取得できる。例えば、サイバーネームを特定して、サイバーネーム管理テーブル６１の該当エントリーの全ての情報を取得できる。また、シリアルナンバーを指定して、メッセージ管理テーブル６２の該当エントリーの全ての情報を取得できる。
【００６８】
＜日時認証＞
電子データに対して時刻認証を行う為の手段として、タイムスタンプが利用されている。このタイムスタンプは、電子公証や電子署名法でも使用されており、e-文書法で電子化が許可された文書の中にも、一部省令でタイムスタンプの利用が義務付けられているものがある。タイムスタンプの実装方法としてよく利用されているのが、リンキング・プロトコルである。このリンキング・プロトコルは、電子署名の信頼性に依存せずに長期にわたって認証日時における存在証明と非改竄証明を可能とするものである。
【００６９】
以下、図９を参照して、本実施例による時刻認証の方法を説明する。シリアルナンバーをｉとした場合、対応するリンク情報L(i)とその前後のリンク情報L(i-1)、L(i+1)は、認証メッセージMsg(i)と認証メッセージMsg(i+1)の前後関係を特定する情報である。
【００７０】
すなわち、リンク情報L(i)は、リンク情報L(i-1)と認証メッセージMsg(i)から算出された情報である。ここでは、リニアリンキング・プロトコルを用いる。すなわち、h()をハッシュ関数として、リンク情報L(i)は、L(i)=h(L(i-1), i, h(Msg(i)))によって算出される数値である。すなわち、リンク情報によって、認証メッセージのチェーンが形成される。
【００７１】
ハッシュ関数の特性から、リンク情報L(i-1)と認証メッセージMsg(i)は共に、リンク情報L(i)よりも前の情報である。同様に、リンク情報L(i)と認証メッセージMsg(i+1)は、リンク情報L(i+1)よりも前の情報である。
【００７２】
なので、リンク情報L(i-1)、L(i)、L(i+1)が、認証メッセージMsg(i)、Msg(i+1)と整合していれば、認証メッセージMsg(i)の認証日時Date(i)は、認証メッセージMsg(i+1)の認証日時Date(i+1)よりも前でなければならない。もし、Date(i)＞Date(i+1)ならば、少なくとも一方は正しくない。
【００７３】
図１０を参照して、更に説明する。ここで、リンク情報L(j)とリンク情報L(n)は、新聞などの刊行物に公表された代表値である。それらの間の認証メッセージが全て分かれば、j＜k＜nとして常にDate(j)＞Date(k)＞Date(n)であることが確認できる。もし、認証メッセージMsg(k)の認証日時Date(k)が正しいことが確実であれば、j＜m＜k＜nとしてDate(j)＞Date(m)＞Date(k)であることが確実となる。
【００７４】
このリニアリンキング・プロトコルは、一般的なタイムスタンプ・サービスで用いられるタイムスタンプ・プロトコルの一つであるが、この実施例では、通常のタイムスタンプ・サービスよりもシステムとしての信頼性が高くなっている。
【００７５】
通常のタイムスタンプ・サービスの場合、事実上の乱数であるハッシュ値が特定の日時に存在したという証明をするだけである。情報自体はユーザーのみが所有して、一般には公開されない。また、タイムスタンプ・サービス側は途中のハッシュ値を公開するのみで、情報の内容には関知しない。
【００７６】
また、一週間間隔で代表値を刊行物に公開する場合、一週間という期間内の何処に本当の認証日時があるかについては、リニアリンキング・プロトコル自体は保証しない。確実なのは、タイムスタンプ間の順序関係のみである。認証日時そのものは、タイムスタンプ・サービス提供サイトの信頼性に依存する。
【００７７】
上記の通り、本実施例でも、シリアルナンバーを時系列ＩＤとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される（図２）。しかしながら、ここでは認証メッセージMsg(i)は、管理サーバーに保存管理され、また不特定多数のサイトに掲載され公開される。
【００７８】
認証メッセージMsg(i)が公開されるということは、そのハッシュ値も事実上公開されるということになる。このハッシュ値は、公開リンク情報を繋ぐ照合用データとなっている。
【００７９】
本実施例の場合には、管理サーバーの付与した認証日時に加えて、不特定多数のサイトにも投稿日時と共に認証メッセージが掲載され公開される。この多数の第三者の公開データ（特に投稿日時）の分だけ、認証日の正しさに対する蓋然性が高くなる。仮に、隣接する代表値の公表日の間に、一つの信頼できるサイトで公開された認証メッセージがあり、そのハッシュ値および投稿日時がリンクチェーンに矛盾なく収まる値であれば、そのリンクチェーンの認証日時の信頼性は、その信頼できるサイトでの投稿日時によって補強されることになる。
【００８０】
従って、管理サーバー側からは、隣接する代表値の公表日の間の認証メッセージのハッシュ値と掲載サイトのＵＲＬのリストがダウンロード可能に公開される。また、図２のような公表情報の画像データと、刊行物の書誌事項も公開される。希望するユーザーは、このハッシュ値のリストと公表情報のデータを保存しておけば、認証メッセージの投稿日に関する客観的な証拠データとすることができる。
【００８１】
＜リンク情報の効果＞
認証日時の信頼性に関して、リンク情報がどのような関連を持っているかについて更に詳しく説明する。図１１に、サイバーネーム、ユーザー署名、リンク情報、日時情報（管理サーバー付与）および日時情報（各サイト付与）が時系列に並んでいる様子を示す。これらは全て投稿先のサイトで公開される情報である。又、管理サーバーにおいても公開されているので、リンクを辿ることは容易にできる。リンク情報は、投稿先のサイトでは直接は公開されないが、認証メッセージのハッシュ値を用いて、公表されている代表値から算出できる。
【００８２】
図１２に、日時情報（メッセージ内）の信頼性が、他の情報とどのように関連しているかを示す。ただし、ハッシュ関数の性質から、リンク情報によって各認証メッセージの前後関係は保証されている。ここでは、或るサイトに掲載されたメッセージ内の日時情報Date(i)のメッセージを考える。
【００８３】
当該サイトでは、この日時情報Date(i)とは無関係に付与された日時情報DateS(i)と共に、メッセージの掲載を行う。なので、Date(i)の信頼性とDateS(i)の信頼性は相互に補完する関係にある。すなわち、Date(i)とDateS(i)は一対一に対応している。
【００８４】
リンク情報によって各認証メッセージの前後関係は保証されているので、もしｉ＜ｊであってDate(i)＞Date(j)となっていれば、Date(i)とDate(j)の何れかが誤っていることになる。この場合、日時情報Date()やDateS()のチェーンの中で、不自然な方が誤りである可能性が極めて高い。
【００８５】
例えば、或るメッセージの日時情報を一週間前の日時情報とする不正を行う場合を考える。まず、管理サーバーにアクセス可能な協力者を得るか、侵入して改竄を行う必要がある。ただ単に、そのメッセージの日時情報を一週間前の日時情報とすると、日時情報Date()の一週間のチェーンの中で、それだけ単調増加の規則から外れていることになる。
【００８６】
なので、チェーン自体を再構成する必要がある。一週間のチェーンを全て削除して、それよりも前の日時情報と連結する新たなチェーンを作成する。この場合、削除したチェーンのメッセージが投稿されている各サイトにも侵入して痕跡を消す必要がある。更に、新たなチェーンのメッセージも、各ユーザーが投稿したような痕跡を各サイトに書きこむ必要がある。更には、各ユーザーのパソコンへも侵入して整合性を取る必要性も考えなければならない。このような事は現実的には極めて困難と思われる。
【００８７】
すなわち、管理サーバーと、メッセージを発信した各ユーザーと、メッセージが掲載された各サイトの夫々の信頼性とは、夫々に、各日時情報の信頼性と独立に対応している。そして、日時情報に疑念がある場合、ハッシュ関数の一方向性に基づいて、何れの日時情報が正しくないかは容易に推測できる。また、その責任が何処にあるかも明瞭となっている。従って、意図的でない誤りを別とすれば、不正が行われる可能性は非常に低くなっている。
【００８８】
＜署名の確認＞
一般ユーザーのメッセージを掲載している掲示板の一例を図１３に示す。この閲覧ユーザーのパソコンのブラウザには、上記プラグインがインストールされており、それにより上記認証ボタンと検証ボタンが表示されているものとする。この掲示板の閲覧者が、認証メッセージを検証するには、ブラウザの検証ボタンを押せば良い。
【００８９】
するとプラグインは、現在表示されているページの内容を解析して、認証メッセージを特定する。具体的には、メッセージの末尾が、Base64の４文字＋アンダーバー"＿"＋サイバーネーム＋空白＋格付け（後述）＋改行＋日時（20101130 11:52といった形式）＋空白＋シリアルナンバー（括弧内の８桁の１６進数）という形式となっていれば認証メッセージとしての検証を行う。
【００９０】
まず、それらの認証メッセージのハッシュ値を算出する。そして、各認証メッセージのハッシュ値は、対応するシリアルナンバーと共に、管理サーバーに送信する。この例では、上から二番目のメッセージには、認証は付加されていないので、ハッシュ値とシリアルナンバーの組は３つである。
【００９１】
管理サーバーでは、受信したハッシュ値と、対応するシリアルナンバーのデータベースのエントリのハッシュ値が同一かどうかを確認する。同一であれば認証済みのメッセージであり、同一でなければ、認証されていないメッセージとなる。更に、管理サーバーは、各認証済みのメッセージについて、当該サイバーネームの有効期限が切れていないことを確認する。
【００９２】
そして、各シリアルナンバー毎に、認証の可否とサイバーネームの有効性を通知する。認証されており且つ有効である場合には、対応するサイバーネームから現在の格付けを取得し後述の格付けを決定し、認証確認の通知と共にユーティリティソフトへ送信する。
【００９３】
認証情報を受信したプラグインは、図１４のように、掲示板の該当する位置に認証結果を付け加える。すなわち、認証が失敗した場合には「認証失敗」という表示を行う。認証が成功した場合には「認証済」に現在の格付けを付けて「認証済AA」といった表示を行う。上から４番目のメッセージでは、投稿時に格付けはAであったが、現在はAAと昇格したことが分かる。更に、プラグインは、認証が成功したサイバーネームに、後述の発言リストのＵＲＬへのリンクを設定する。図１４では、リンクには下線が付けられている。また、認証されていても、当該サイバーネームの有効期限が切れていれば「認証済(現在無効）」と表示される。
【００９４】
＜発言リスト＞
インターネットを使っていて、特に気になる書き込みに目が止まった場合、このような発言をする人は、他にどのような発言をしているかを知りたいと思うことがある。或いは、このような発言をする人はどんな人か知りたいと思うことがある。そのような場合、ユーザーは発言リストを表示することができる。すなわち、図１４に示したように、認証が成功したサイバーネームの表示aZ38_Nuagesを選択すると、管理サーバーへサイバーネームaZ38_Nuagesと共に発言リスト表示のリクエストが送信される。
【００９５】
そのリクエストに対して、管理サーバーは、メッセージ管理テーブル６２からaZ38_Nuagesのエントリを抽出して発言リストを作成し、その他の情報と共にWebページとして送信する。この発言リストを含む情報はブラウザで受信され、図１５のようなウインドウが表示される。
【００９６】
発言リストでは、その発言者（ここではaZ38_Nuages）の過去の認証メッセージの一覧が最新のものから列挙されている。相当数の発言がある場合なら、ここで絞込み検索などを利用することにより、aZ38_Nuagesというユーザーの人物像をある程度まで知ることができる。各項目の左下には、そのメッセージが掲載されているサイトへのリンク情報が示されている。
【００９７】
このリンク情報は、上記のとおり、認証時に表示中の最前面のブラウザから取得されたＵＲＬである。なので、認証メッセージの掲載ページへのリンクとなっているとは限らない。しかし、実際の掲載ページを知る上での情報としての利用が可能である。
【００９８】
また、管理サーバーは、認証メッセージの掲載ページの検索を行うようにする。これは、メッセージ管理テーブル６２のシリアルナンバーとサイバーネームをサーチタームとして、Webを検索により行う。但し、一般的なサーチエンジンは、インデックスの更新に数日ないし一週間以上かかることがあるので、認証後、しばらくしてから検索を行うようにする。
【００９９】
図１５のリストの二番目の発言に示されているように、検索で得られた認証メッセージの掲載ページのＵＲＬの下に、認証時に表示中の最前面のブラウザから取得されたＵＲＬもそのまま表示しておく。従って、上のＵＲＬをクリックすることで、掲載ページを直接表示することが出来る。
【０１００】
なお、過去の認証メッセージから得られる人物像は、そのサイバーネームを所有する生身の人物の人物像そのものという訳ではない。その生身の人物が、インターネットというサイバー空間で例えば、aZ38_Nuagesという別の人物像を自由に形成できる。
【０１０１】
すなわち、発言の質と量が、そのサイバーネームの価値を決定する。従って、一つのサイバーネームを大事に育てることが重要で、多重登録を行う意味は余り無い。この点をより強調する意味で、客観的なランキングを用いる。
【０１０２】
図１５の例では、ランキングとして144/48237と表示されている。これは、48237個のサイバーネームの中で、第114位であることを示している。サイバーネーム管理テーブル６１のランキング・フィールド(Ranking)に格納される情報は、この順位114である。このランキングは、後に説明するポイント数（Points）に基づいて順位付けられる。すなわち、ここでは114番目にポイント数が多いユーザーであることを示している。
【０１０３】
また、このランキングに基づいて、ユーザーの格付けが行われる。例えば、サイバーネーム全体の中の上位5%に含まれていれば「AAA」とし、それ以下で上位15%に含まれていれば「AA」とし、更にそれ以下で上位30%に含まれていれば「A」とし、更にそれ以下の場合は「B」とする。この格付けは、認証メッセージに含めて投稿されるので、書き込みを読む際にそのユーザーの格付けが分かって好都合である。
【０１０４】
ただし、掲示板などに表示されている認証メッセージの格付けの値は、そのメッセージの書き込みの際の格付けの値である。従って、認証確認の時点での格付けの値とは、一般的に一致しないことになる。図１４の「認証済」の表示の右側には、認証確認の時点、すなわち現在の格付けの値が表示される。
【０１０５】
なお、発言リストの各項目の右下には、当該メッセージの内容と類似した他のユーザーの認証メッセージを表示するためのボタンが示されている。このボタンを押すと、図１６のような画面が表示される。ここでは、最上段に当該メッセージが表示され、その下に、内容がより近いものから表示される。
【０１０６】
これにより、類似のテーマに関する他のユーザーの意見を参考することができる。また、当該メッセージの日付より前のものと後のものを色分けして表示する。このようにすることで、オリジナリティ豊かな内容が含まれていた場合、どのユーザーが最初かを知ることができる。
【０１０７】
＜ポイント数＞
ポイント数（Points）は、サイバーネームを所有するユーザーの信頼性を示す数値として、各ユーザーによる管理サーバーの利用状況に関する情報から算出される。そのような情報としては次のようなものが考えられる。
【０１０８】
１）当該ユーザーの発言リストを、他のユーザーが表示した回数
２）当該ユーザーのお気に入りページを、他のユーザーが表示した回数
３）当該ユーザーのお気に入りページのリンクを、他のユーザーがクリックを行った回数
４）当該ユーザーのお気に入りページから、他のユーザーが商品の購入を行った回数
５）当該ユーザーの発言リストの絞込み検索を、他のユーザーが行った回数
６）当該ユーザーのブログを、他のユーザーが表示した回数
７）当該ユーザーの発言が引用され、その引用から元の発言が表示された回数
８）当該ユーザーの発言が引用され、その引用から当該ユーザーの発言リストが表示された回数
【０１０９】
上記情報に適当な重み付けを行ってから、例えば、計算式Points＝Σ(ci×fi)で累計する。この計算式は、上記項目の番号をｉとして、fiは上記項目のｉ番目の回数、ciはｉ毎に設定された係数であり、全てのｉについての総和がPointsとなることを示している。
【０１１０】
＜著作権＞
一般ユーザーが発信する場合には、コピペの問題が生じることがある。ユニークで見識の高いメッセージの投稿を見て、それをそのままコピーして自分の認証を付けて、あたかも自分独自のメッセージとして別の掲示板へ投稿するというようなことである。このような場合でも、最初のユーザーが自分の署名を付けていれば、いずれが先かが明瞭となる。
【０１１１】
コピペを行ったユーザーのサイバーネームの信頼性は低下するであろう。これをポイント数に反映させるには、悪質と判断したユーザーが、対象のサイバーネームのポイントを下げること、つまり減点を行うことを可能とすれば良い。乱用を防ぐために、格付けがA以上のユーザーに限って、自らのポイントを消費して減点を行えるようにする。例えば、格付けAの場合は、自らのポイントの減少分の２倍の減点を行えるようにし、格付けAAの場合は、自らのポイントの減少分の４倍の減点を行えるようにし、格付けAAAの場合は、自らのポイントの減少分の８倍の減点を行えるようにする。
【０１１２】
通常のメッセージではなく、自作曲、イラスト、詩作といった創作コンテンツをネットで発表する場合には、認証の日付があれば他人の盗作に対して一定の歯止めがかかる。例えば、映像や音楽の場合には、ハッシュ値をメッセージに付加してから認証を行うようにする。
【０１１３】
図１７では、「忘却の彼方へ」という自作曲に映像を付けて、MPEG-4のファイルとして発表した例を示している。ここでは、「島取への小旅行の記念に曲を作りました。」というメッセージに、「Oblivescence.mpg: SHA-2 a1yOOj…1jO=」を加えて、サイバーネームと共に認証を行っている。Oblivescence.mpgはビデオのファイル名であり、ハッシュ関数としてSHA-2を用い、Base64でエンコードし「a1yOOj…1jO=」というハッシュ値が得られたことを示している。
【０１１４】
例えば、他のユーザーが音楽だけを取り出して、少し変えて自作曲として発表したとする。この場合、先のMPEG-4ファイルを発表した認証日時は、盗作であるか否かについての有力な証拠となり得る。
【０１１５】
＜Webサイト認証＞
Webサイトのページは複数のファイルから構成されている。このようなデータに対して認証を行うには、認証を確認する為のページを別途設けることが便利である。例えば、図１８に示したようなWebサイトのトップページの場合、認証ページのURL（リンク）を記載しておく。ここでは、個別ファイル認証というボタンに認証ページへのリンクが設定されている。この認証ページは、例えば、図１９に示したような内容を含んでいる。
【０１１６】
すなわち、この認証ページには、認証を行うデータ（通常はファイル）のURLが列挙されている。そして、これらのURLで指定されるデータのハッシュ値に対して上記のとおり認証を行っている。
【０１１７】
例えば、"myhome.ne.jp/member1/content1.htm"というファイルのハッシュ値を計算し、Base64でエンコードしてテキストデータとする。このテキストデータを、通常のメッセージと同様にユーザー署名を付加して、所定のフォーマットにメッセージを組み立てて、サーバーへ認証を依頼する。図１９では、このファイルが20061223 19:23に作成され、シリアルナンバー00383093で認証されていることを示している。
【０１１８】
この場合、認証メッセージは、次のように組み立てられる。すなわち、図２０に示したように、ファイル名、ハッシュ関数、ファイルのハッシュ値、サイバーネーム、格付け(Rating)、認証日時、シリアルナンバー、所定のフォーマットに従って組み合わせれば良い。上記の通り、この認証メッセージのハッシュ値によって認証の確認を行うことができる。Webサイトの作成者が認証を得るには、図２０から認証日時、シリアルナンバーを除いたような所定のフォーマットに従って組み立てたメッセージについて、認証を求めれば良い。
【０１１９】
Webページは度々更新されることがある。この場合、同じＵＲＬに関して、認証日時の異なる複数の認証を得るようにしても良い。図１９では、"myhome.ne.jp/member1/content2.htm"に別々の認証日時を持つ２つのエントリが示されている。
【０１２０】
＜本人認証＞
上記した方法では、認証を行ったメッセージは、誰でも自由に閲覧できることになる。つまり、サイバーネームによるネット上の活動はすべて公開ということになる。公開したくはないが、サイバーネームで認証を行いたい場合には、登録されているＲＳＡ鍵を用いて署名を付ければ良い。
【０１２１】
その場合、ユーティリティソフトは、メッセージへのユーザー署名を算出するが、管理サーバーへは送信しない。ユーザー署名はBase64でエンコードして、メッセージの最後に「署名(sha256WithRSAEncryption)：」という文字列と共に付加する。
【０１２２】
図２１は、電子メールで受信した本人認証付きメッセージを、一般的なメーラーで表示している画面を示している。ここでは2048ビットのRSA署名を用いているので、Base64でエンコードした342文字とやや長いユーザー署名が付加されている。RSAの代わりに224ビットのECDSAを用いれば、ユーザー署名は448ビットとなり、Base64でエンコードした場合75文字まで短くできる。
【０１２３】
本人認証付きメッセージを検証するには、ユーザー署名を含むメッセージのテキストをコピーして、サイバーネームと共にユーティリティソフトに入力する（図２２）。そして、検証ボタンを押すと、ユーティリティソフトは、管理サーバーにアクセスして、サイバーネームに対応する公開鍵を取得して、メッセージ本文に付けられた署名を検証する。
【０１２４】
検証に成功すれば、ユーティリティソフトによって「U+Qj_Satohさんのメッセージです」といった表示がなされる（図２３）。この表示には、そのサイバーネームの現在の格付けも表示される。格付けは管理サーバーから取得する。ここで、発言リスト表示ボタンをクリックすれば、U+Qj_Satohの発言リストを表示できる。また、検証できなければ、「U+Qj_Satohさんのメッセージであるとは確認できません」といった表示がなされる（図２４）。
【０１２５】
U+Qj_Satohが知らないサイバーネームであっても、格付けの値を信頼性の目安とすることができる。また、発言リストを表示して、その人物の信用評価を行うこともできる。U+Qj_Satohが周知のユーザーであれば、その公開鍵を予め保存しておいても良い。
【０１２６】
また、署名を付加したい場合には、図２５のようにメッセージを打ち込んで署名付加のボタンを押す。すると、所定のフォーマットに従って、メッセージの最後に署名を付加して、図２２に示したような内容に変換される。ユーザーは、それをコピーして任意のメールソフトで送信すれば良い。
【０１２７】
＜その他の機能＞
発言リストなどを介して信頼を得ているユーザーに対して直接メールを送りたい場合もある。それには管理サーバーにメール機能を実装すれば良い。このメール機能は、発言リストのウインドウを介して提供される。例えば、図２６に示したように、発言リストのウインドウに設けられたメールタブをクリックすることで利用可能とする。
【０１２８】
また、管理サーバーにブログ機能を実装して、これも発言リストのウインドウに設けられたブログタブをクリックすることで利用可能とする。このブログは、サイバーネームで特定されるユーザーの行ったインターネット上のすべての活動とリンクしているという点で、通常のブログとは異なる。
【０１２９】
＜サイバーネームの無効＞
各ユーザーは、自分のサイバーネームを無効に出来る。それには、無効の申請を管理サーバーへ署名付きで行えば良い。無効となったサイバーネームと公開鍵の情報も、図２のような新聞広告でハッシュ値が公表されるリストに載せておく。無効にする理由としては、秘密鍵が漏洩してしまった場合などが考えられる。図３では、登録されたサイバーネームのリストの下に無効となったサイバーネームのリストが示されている。その場合、サイバーネーム管理テーブル６１の有効期限（Expiration）フィールドを、無効となった日時で上書きする。
【０１３０】
また、サイバーネームには有効期限が設定される。格付けがA以上のユーザーの場合には、自動的に有効期限は更新される。有効期限の更新も新規の登録と同様に、新聞による公表が行われる。しかし、格付けがA以下のユーザーでは、一定期間以上サイバーネームの有効利用がない場合、有効期限の更新は行われない。
【０１３１】
＜引用＞
他人の文章を、そのまま黙って自分の投稿に利用するというのは、余り行儀の良いものではない。しかし、有用な書き込みの再利用はインターネットの利便性を向上させる。この場合、引用先を明記することで、オリジナルの書き手に配慮することができる。それにはシリアルナンバーの表記で足りる。更にサイバーネームを加えておけば、より敬意を払うことになる。
【０１３２】
図２７に具体例を示す。ここでは「sn:」の後のシリアルナンバーと「Cbn:」の後のサイバーネームが引用先を示している。プラグインは、認証が成功したメッセージに、引用が含まれていれば、シリアルナンバーの表示に引用先のリンクを設定する。また、引用先サイバーネームの表示にそのユーザーの発言リストへのリンクを設定する。閲覧ユーザーが、引用先や発言リストを参照したい場合には、これらのリンクをクリックすれば良い。上記のとおり、このように引用されて発言リストが表示されれば、ポイントを加算するようにする。
【０１３３】
＜収益モデル＞
図１５のような発言リストには「お気に入り」タブが含まれている。このお気に入りを選択すると図２８のようなウインドウが表示される。このような発言リストを、ネットワークメディアとして利用することで、収益モデルの設計が可能となる。すなわち、ウインドウでお気に入りのタブを選択すれば、そのサイバーネームを所有するユーザーのお薦めの商品やサービスを知ることができる。このお気に入りの内容は、そのユーザーの信頼性が高ければ有効な広告媒体となり得る。また、アフィリエイト・プログラムを利用することも可能である。その収益をユーザーとシステム提供者が分け合うことで、システム運営に必要な収益が可能となる。
【実施例２】
【０１３４】
実施例１では、サイバーネームの所有者が、投稿メッセージが自分が発信したもの又は自分が発信したものでない、という事実を証明するには、管理サーバーの信頼性と協力が不可欠である。管理サーバーとは無関係に証明を行うには、以下のようにシールを用いれば良い。シールの付加を除いて、実施例２の実装は、上記実施例１の実装と同じである。
【０１３５】
この実施例２では、管理サーバーは、図６に示したような署名用メッセージへのユーザー署名を受信し検証すると、このユーザー署名のハッシュ値を算出して、その最後の２４ビットをBase64でエンコードすることで４文字のシール（Seal）を生成する。ここでのハッシュ関数としては、ＳＨＡ−１などを用いれば良い。そして、図２９のように、シリアルナンバーの前にこのシールを付加することで認証メッセージとする。メッセージの検証は、シールも含めた認証メッセージのハッシュ値を確認することで行う。図１３の具体例に対して、実施例２を適用した場合の認証メッセージを図３０に示す。
【０１３６】
シールも近似的に２４ビットの乱数と考えられるので、ユーザー署名の一つのハッシュ値と言える。ユーザー署名と同じビット長を持ち、且つ上記２４ビットのハッシュ値と同じハッシュ値を生成するような、別のデータを探すことは困難ではない。しかし、そのデータをユーザー署名とみなして、検証を行った場合に、検証に成功するようなハッシュ値の原像となるような認証メッセージを算出することは困難である。
【０１３７】
従って、シールを用いれば、各ユーザーは、或る投稿を自分のものである事も、自分のものでない事も管理サーバーとは独立に証明できる。自分のものである事は、メッセージへの署名を作成して、その署名がシールと対応していることを示せば良い。また、自分のものでない事は、メッセージへの署名を作成して、その署名がシールと対応していないことを示せば良い。サイバーネームと公開鍵との対応は、リストのファイルと新聞での公表情報により証明できる。
【実施例３】
【０１３８】
実施例１および実施例２では、メッセージの認証日時の信頼性は、新聞などの刊行物に公表されたリンク情報の代表値に基づいて評価される。その場合、隣接する代表値の公表日の間のメッセージのハッシュ値が必要となる。なので、管理サーバーではそれらのハッシュ値を纏めて公開する。
【０１３９】
管理サーバーに問題が生じて、ハッシュ値が利用できない場合には、シリアルナンバー等からメッセージを検索することも考えられる。しかし、必ずしも必要な全てのメッセージが検索出来るとは限らない。実施例３では、隣接するメッセージの前後関係を、それらメッセージのみから確定する方法を提案する。
【０１４０】
この実施例では、図３１に示したように、認証メッセージそのものにリンク情報(Link Inf.)を含ませる。図１３の具体例に対して、実施例３を適用した場合の認証メッセージを図３２に示す。すなわち、図３２に示したように、認証メッセージの最後にBase64でエンコードされた４４文字のリンク情報が加わっている。このリンク情報は、ユーザー署名を検証した後に、シリアルナンバーと同時に付与され、認証メッセージとしてユーザーに返される。図３１の例では、i = 003F4959、L(i-1) = mU0OjBha…gICACAgIG0a=となっている。シリアルナンバーｉは丸括弧で括られている。シリアルナンバーの前にシールが付加されている。
【０１４１】
図３３を参照して、更に説明する。認証メッセージMsg(i)には、シリアルナンバーiだけでなくリンク情報L(i-1)も含まれている。なので、認証メッセージMsg(i)のみで、次のリンク情報L(i)を算出することが出来る。このリンク情報L(i)は次の認証メッセージMsg(i+1)に表示される。従って、認証メッセージMsg(i+1)の認証日時よりも前に、認証メッセージMsg(i)が存在していたことが、リンク情報L(i)によって証明される。
【０１４２】
この実施例では、各々のリンク情報が不特定多数のサイトに掲載されるので、代表値の刊行物への掲載は必ずしも要求されない。認証メッセージ同士が互いの認証日時を補強しあっている。
【０１４３】
また、認証メッセージにおけるリンク情報の表記では、最初の１２文字の後にスペースが挿入されている。これは最初の１２文字を単語として独立させるためである。もし、最初の１２文字に「/」等の単語を分離する文字が含まれていれば、それ以後に１２文字の文字列を単語として独立させるためのスペースや改行コードを挿入する。
【０１４４】
この単語は、認証メッセージの掲載ページの検索を行う際に、検索タームとして使用する。１２文字の文字列は72bitの数値に対応し、ハッシュ関数の性質から擬似乱数とみなされる。従って、検索結果は掲載ページのみとなる可能性が極めて高い。但し、一般的なサーチエンジンは、インデックスの更新に数日ないし一週間以上かかることがあるので、認証後、しばらくは検索にかからないこともある。
【０１４５】
このようにすることで、仮に、管理サーバーに問題が生じても、リンク情報を検索サイトで検索することでリンクを辿ることは容易にできる。例えば、或る認証メッセージMsg(j)に含まれているリンク情報と、その認証メッセージMsg(j)のハッシュ値から、次の認証メッセージMsg(j+1)に含まれるべきリンク情報が得られる。このリンク情報の表示に含まれるべき単語を検索すれば、当該次の認証メッセージMsg(j+1)を確認できる。更に、同様に認証メッセージMsg(j+2)に含まれるべきリンク情報の単語を検索すれば、認証メッセージMsg(j+2)を確認できる。これらの認証メッセージMsg(j+1)、Msg(j+2)・・・は、夫々に認証メッセージMsg(j)の存在を保証している。
【産業上の利用可能性】
【０１４６】
以上のように、本発明による識別名管理システムは、インターネット上での個人による情報発信の量と質を向上させるのに大変有用である。
【符号の説明】
【０１４７】
１ サイバーネーム登録申請ウィンドウ
１０ 管理サーバー
６１ サイバーネーム管理テーブル
６２ メッセージ管理テーブル
【図１】
2012248915.tif 000003
【図２】
2012248915.tif 000004
【図３】
2012248915.tif 000005
【図４】
2012248915.tif 000006
【図５】
2012248915.tif 000007
【図６】
2012248915.tif 000008
【図７】
2012248915.tif 000009
【図８】
2012248915.tif 000010
【図９】
2012248915.tif 000011
【図１０】
2012248915.tif 000012
【図１１】
2012248915.tif 000013
【図１２】
2012248915.tif 000014
【図１３】
2012248915.tif 000015
【図１４】
2012248915.tif 000016
【図１５】
2012248915.tif 000017
【図１６】
2012248915.tif 000018
【図１７】
2012248915.tif 000019
【図１８】
2012248915.tif 000020
【図１９】
2012248915.tif 000021
【図２０】
2012248915.tif 000022
【図２１】
2012248915.tif 000023
【図２２】
2012248915.tif 000024
【図２３】
2012248915.tif 000025
【図２４】
2012248915.tif 000026
【図２５】
2012248915.tif 000027
【図２６】
2012248915.tif 000028
【図２７】
2012248915.tif 000029
【図２８】
2012248915.tif 000030
【図２９】
2012248915.tif 000031
【図３０】
2012248915.tif 000032
【図３１】
2012248915.tif 000033
【図３２】
2012248915.tif 000034
【図３３】
2012248915.tif 000035