(57)【要約】【課題】  ネットワーク全体に対する重複問い合わせ、および管理者に対する重複問い合わせの双方に関し、一意識別子候補の重複検査を容易に実現する。【解決手段】  一意識別子作成管理装置（重複検査ノード２）は、一意識別子候補を構成するビット列の一部に作成時点の時刻の表現を導入し、これらの重複検査の問合せにおいて、一意識別子候補が保持する時間情報をチェックする。このとき、ネットワーク上で予想される時刻精度と、計算される通信遅延量の和を上回る所定の時間範囲を定義し、識別子候補が保持する時刻情報が現在時刻から所定の時間範囲に含まれないとき、当該識別子候補を識別子候補から除外する。【選択図】      図１
2005339134.tif 000002
【特許請求の範囲】
【請求項１】
ドキュメンの識別子の候補を作成する第１のコンピュータと、前記識別子を管理する第２のコンピュータが時刻同期して動作するコンピュータネットワークにおいて、一意に識別可能な前記識別子の作成方法であって、
前記第２のコンピュータが備える演算装置は、
作成された識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定する第１のステップと、
重複検査不要と判断された場合に前記識別子候補の再作成を指示する第２のステップと、
を実行することを特徴とするドキュメントの一意識別子の作成方法。
【請求項２】
前記第１のステップは、
前記ネットワーク上で予想される時刻精度と、計算される通信遅延量の和を上回る所定の時間範囲を定義する第１のサブステップと、
前記識別子候補が保持する時刻情報が現在時刻から前記所定の時間範囲に含まれないとき、当該識別子候補を識別子候補から除外する第２のサブステップと、
を含むことを特徴とする請求項１に記載のドキュメントの一意識別子の作成方法。
【請求項３】
前記第２のサブステップは、
前記所定の時間範囲を上回る任意の時間を時間制限として定め、前記時刻表現を含む識別子候補ないしその一部の前記重複検査の際、その検査自体が前記時間制限内に完了できない場合、検査不能であった旨を応答するサブステップ、
を含むことを特徴とする請求項１または２に記載のドキュメントの一意識別子の作成方法。
【請求項４】
前記重複検査において重複が発見できない場合、公開鍵で検証できる電子署名および検証した前記識別子ないしその一部を含む非重複証明書を発行する第３のステップと、
新規に作成された識別子、乃至その一部を使用するドキュメントを公開する際に、前記非重複証明書をドキュメントとして公開する第４のステップと、
を実行することを特徴とする請求項１〜３のいずれか１項に記載のドキュメントの一意識別子の作成方法。
【請求項５】
時刻表現を含む識別子候補を作成し、前記識別子候補の重複検査を依頼する第１のコンピュータと、
前記第１のコンピュータと時刻同期して動作し、前記第１のコンピュータで作成された前記識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定し、重複検査不要と判断された場合、前記第１のコンピュータに前記識別子候補の再作成を指示する第２のコンピュータがネットワークを介して接続されることを特徴とする、一意識別子作成管理システム。
【請求項６】
時刻同期して動作する第１と第２のコンピュータを含むコンピュータネットワークにおいて、前記第２のコンピュータから成る一意識別子作成管理装置であって、
前記第１のコンピュータによって作成された識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定する重複検査部と、
重複検査不要と判断された場合に前記識別子候補の再作成を指示する応答作成部と、
を具備することを特徴とする一意識別子作成管理装置。
【請求項７】
時刻同期して動作する第１と第２のコンピュータを含むコンピュータネットワークにおいて、前記第２のコンピュータから成る一意識別子作成管理装置に用いられるプログラムであって、
前記第１のコンピュータによって作成された識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定する処理と、
重複検査不要と判断された場合に前記識別子候補の再作成を指示する処理と、
を前記第２のコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドキュメンの識別子の候補を作成する第１のコンピュータと、識別子を管理する第２のコンピュータが時刻同期して動作するコンピュータネットワークにおいて、一意に識別可能な、ドキュメントの一意識別子の作成方法およびシステム、ならびに一意識別子作成管理装置、プログラムに関する。
【背景技術】
【０００２】
ＨＴＭＬ（Hyper Text Markup Language）やＸＭＬ（eXtended Markup Language）などネットワーク上で公開、閲覧され、全体ないしその一部を指定してリンクを行なわれることを前提としたドキュメントでは、ドキュメントの全体ないしその一部を指定するための識別子が必要である。このうち、ドキュメントの一部を指定することはドキュメントの全体を指定した上で更に追加情報を加えれば良いため、この問題はドキュメントの全体に識別子を付与する問題に帰着する。
閲覧の際、あるいは閲覧の上でリンクを行なう際に、どのドキュメントであるかを確実に判別するために、ドキュメントの識別子は、少なくとも、公開、閲覧される範囲においては一意である必要がある。
【０００３】
ネットワークにおいて複数の主体がドキュメントを公開する際、ドキュメントの識別子を一意にするためには何らかの一意性の保証が必要である。このような一意識別子としてＵＲＩ（例えば、非特許文献１参照）が広く用いられている。ＵＲＩ（Uniform Resource Identifiers）を実現する方法としては、ＵＲＬ（Uniform Resource Locator）を用いるか、あるいは他の方法で一意性を保証されたビット列を生成する必要がある。ＵＲＩは、ネットワークにおけるノードの名前を決定するＤＮＳ（Domain Name Server）の名前空間に更に情報を追加することで、ドキュメントの一意識別子を表現するものである。
【０００４】
従来、ＵＲＩとして、ほとんどの場合ＵＲＬが使用されてきた。これはＤＮＳで定義されるノードの名前が少なくともある時点においてはインターネット上における一意性が保証されているため、そのノードを利用するユーザはノード内での名前の一意性にのみ留意すればある時点におけるインターネット上の一意性を保証できるからである。しかしながらＵＲＬを利用する場合、ドキュメントの作成者は少なくともインターネット上のＤＮＳに登録されたノードの名前を必要とする。
これはインターネットに接続していない作成者にとっては困難である。さらに、ＤＮＳ上のノードの名前は必ずしも未来における一意性を保証するものではない。ドメイン名の売買などは頻繁に行なわれているのであり、ＵＲＬに関連するドメイン名の売買やドメイン名の維持中止による再利用などによってＵＲＬの一意性は脅かされる。また、現時点に限ってもＵＲＬの一意性を保証しているＤＮＳの管理者は、自身の管理方針による名前空間の管理を行なうため、既に割り当てられたドメイン名の方針変更による廃棄等の可能性も否定はできない。
【０００５】
このように、ＤＮＳをベースにしたＵＲＬをＵＲＩとして使用することは、ＤＮＳの管理者に名前空間の管理に間する特権的な地位を与えてしまい、管理方針、コスト分担の問題を抱えるにもかかわらず、ドキュメントの一意識別子に必要な将来における一意性を必ずしも保証できないという問題を抱えている。
【０００６】
この問題を解決するためには、ＵＲＩとして、ＵＲＬではない一意なビット列の生成を行ない、その一意性を特権的な管理者が存在しなくても保証可能とするか、あるいは管理者の運用および管理者の交替に要するコストを低減することが必要である。ここで、ビット列で記述される一意識別子の規定された一部が重複しなければ、残りのビット列に一意識別子の作成者が一意性を管理するビット列を挿入してもやはり一意である。このため、一意性を検証する対象となるのは、一意識別子全体ないしその規定された一部のビット列である一意識別子候補である。
このようなビット列の決定方法としては、分散コンピューティングの分野で用いられるＵＵＩＤ（例えば、非特許文献２参照）がある。ＵＵＩＤ（Universally Unique Identifier）は、一意性の確保のためにＥｔｈｅｒｎｅｔ（登録商標）Ｉ／ＯのＭＡＣ（Media Access Control Address）アドレスのごとく既に世界における一意性があるはずの値に、時刻や乱数などを付加することにより一意性を確保する。ここで、ＭＡＣアドレスの一意性は必ずしも保証されているわけではなく、また、ＭＡＣアドレスが含まれることで一意識別子を作成した端末の情報が外部に漏洩する問題もある。さらに、一意性を確保するために、自身のＭＡＣアドレスを規定の場所に入れなければならないことから、文書の一意識別子を大量に集めて観測することで、どの文書群がどの端末において作成され一意識別子が構成されたかを推測することが可能となる。このことにより、複数の文書、記録が同一の端末によって作られたことから、同一の作者によって書かれたと推測することが可能となり、プライバシー漏洩などの問題につながる。
【０００７】
ＵＵＩＤではこの問題を解決するために、ＭＡＣアドレスに相当する部分を乱数の発生により作成することをオプションとして可能にしている。ビット列の長さが十分に長くかつ発生される乱数の品質が十分に高ければ、このような方法でも重複の可能性を減少させることは可能である。しかしながら、発生する乱数の品質が、一意識別子の必要量に対して十分かどうかは個別の乱数発生プログラムの実装と一意識別子の必要量のそれぞれに依存する。このため、重複が無い事を保証するためには既に存在を知られている一意識別子候補との重複の有無の検査を行なうことが望ましい。さらに、悪意あるノードが一意識別子候補を重複させて作成して使用することを防止するためには、他のノードによる一意識別子の重複検査が行なわれる必要がある。
【非特許文献１】ＲＦＣ２３９６ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ（ＵＲＩ）：Ｇｅｎｅｒｉｃ Ｓｙｎｔａｘ
【非特許文献２】＜インターネットＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｌｉｎｕｘ．ｏｒ．ｊｐ／ＪＭ／ｈｔｍｌ／ｅ２ｆｓｐｒｏｇｓ／ｍａｎ３／ｕｎｉｄ＿ｇｅｎｅｒａｔｅ．３．ｈｔｍｌ＞
【発明の開示】
【発明が解決しようとする課題】
【０００８】
このような検査の方法としては、（１）ネットワーク全体に問い合わせる方法と、（２）ネットワーク内の一意識別子候補の管理者に問い合わせる方法の２つがある。
（１）ネットワーク全体への問い合わせは、完全に固定された構成のネットワーク以外では常にネットワークからの離脱や問い合わせ対象の休止の可能性があるために、過去に使用されたが現在ネットワークを構成するコンピュータ群が知らない一意識別子候補が存在する場合があり得るので、重複の可能性はネットワークが長期に存在してその中での離脱や休止の回数が増えるほど高くなり続ける。したがってネットワーク全体に問い合わせる方法をとる場合には、あるネットワークからのコンピュータの離脱や休止の影響を抑制する技術が必要になる。
一方、（２）ネットワーク内の一意識別子候補の重複を管理する管理者への問い合わせの場合、重複を検査するための既存の一意識別子候補のデータベースが膨大な量になる。ＵＲＬにおけるＤＮＳの管理者が特権的な立場となったのは、この重複検査のためのデータベースの維持、管理、運用にかかるコストおよびこれを他管理者へ移行するコストが大きな要因であった。
【０００９】
さらに、文書や記録の一意識別子を用いた作成端末や作者の一貫性を手がかりとした追跡と分析を防ぐか、少なくとも困難性を克服するためには、作成者ないしその端末に付与されている一意識別可能な情報を用いてはならず、かつ、一意識別子候補をある文書の作成主体が複数保持し使い分ける必要がある。このことは、作成者ないしその端末以外のネットワーク上で通信可能な他一意識別子管理者に対する大量の一意識別子候補作成要求の発生を意昧し、従来のＤＮＳ以上に重複検査用データベースの量が膨大となる。
したがってＵＲＬの問題点を解決し、一意性のあるビット列を簡便に利用してかつその一意性を保証するためには、大量に発生する一意識別子候補の重複検査のためのデータベースを容易に作成、維持、管理、運用および移行するための技術を必要とする。
【００１０】
本発明は上記事情に鑑みてなされたものであり、ネットワーク全体への問い合わせでのコンピュータの離脱や休止の影響抑制としては重複検査対象たる一意識別子候補がある時点においては一定の範囲の時間表現しか持ちえないことを利用し、一意識別子候補を構成するビット列の一部に作成時点の時刻の表現を導入することで、ネットワーク全体に対する重複問い合わせ、および管理者に対する重複問い合わせの双方に関して一意識別子候補の重複検査を容易に実現可能とした、ドキュメントの一意識別子の作成方法およびシステム、ならびに一意識別子作成管理装置、プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記した課題を解決するために本発明は、ドキュメンの識別子の候補を作成する第１のコンピュータと、前記識別子を管理する第２のコンピュータが時刻同期して動作するコンピュータネットワークにおいて、一意に識別可能な前記識別子の作成方法であって、前記第２のコンピュータが備える演算装置は、作成された識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定する第１のステップと、重複検査不要と判断された場合に前記識別子候補の再作成を指示する第２のステップと、を実行することを特徴とする。
【００１２】
また、本発明において、前記第１のステップは、前記ネットワーク上で予想される時刻精度と、計算される通信遅延量の和を上回る所定の時間範囲を定義するサブステップと、前記識別子候補が保持する時刻情報が現在時刻から前記所定の時間範囲に含まれないとき、当該識別子候補を識別子候補から除外するサブステップと、を含むことを特徴とする。
【００１３】
また、本発明において、前記第２のサブステップは、前記所定の時間範囲を上回る任意の時間を時間制限として定め、前記時刻表現を含む識別子候補ないしその一部の前記重複検査の際、その検査自体が前記時間制限内に完了できない場合、検査不能であった旨を応答するサブステップ、を含むことを特徴とする。
【００１４】
また、本発明において、前記重複検査において重複が発見できない場合、公開鍵で検証できる電子署名および検証した前記識別子ないしその一部を含む非重複証明書を発行する第３のステップと、新規に作成された識別子、乃至その一部を使用するドキュメントを公開する際に、前記非重複証明書をドキュメントとして公開する第４のステップと、を実行することを特徴とする。
【００１５】
また、本発明は、時刻表現を含む識別子候補を作成し、重複検査を依頼する第１のコンピュータと、前記第１のコンピュータと時刻同期して動作し、前記第１のコンピュータで作成された前記識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定し、重複検査不要と判断された場合、前記第１のコンピュータに前記識別子候補の再作成を指示する第２のコンピュータがネットワークを介して接続される、ドキュメントの一意識別子作成管理システムである。
【００１６】
また、本発明は、時刻同期して動作する第１と第２のコンピュータを含むコンピュータネットワークにおいて、前記第２のコンピュータから成るドキュメントの一意識別子作成管理装置であって、前記第１のコンピュータによって作成された識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定する重複検査部と、重複検査不要と判断された場合に前記識別子候補の再作成を指示する応答作成部と、を具備することを特徴とする。
【００１７】
また、本発明は、時刻同期して動作する第１と第２のコンピュータを含むコンピュータネットワークにおいて、前記第２のコンピュータから成る一意識別子作成管理装置に用いられるプログラムであって、前記第１のコンピュータによって作成された識別子候補が保持する時刻情報と、現在時刻から重複検査の要否を判定する処理と、重複検査不要と判断された場合に前記識別子候補の再作成を指示する処理と、を前記第２のコンピュータに実行させることを特徴とする。
【発明の効果】
【００１８】
本発明によれば、一意識別子候補を構成するビット列の一部に作成時点の時刻の表現を導入し、これをチェックすることで、ネットワーク全体に対する重複問い合わせ、および管理者に対する重複問い合わせの双方に関して一意識別子候補の重複検査を容易に実現することができる。このことにより、従来のＤＮＳのようなサーバの長期存在と大きな負荷を前提とせずに一意性を保証された一意識別子が大量に使用でき、かつプライバシー流出に対する対抗が可能な環境を構築することができる。
【発明を実施するための最良の形態】
【００１９】
図１は、本発明のドキュメントの一意識別子作成管理システムにおけるシステム構成の一例を示す図である。
本発明のドキュメント一意識別子作成管理システムは、第１のコンピュータに相当する重複検査依頼ノード１と、第２のコンピュータに相当する重複検査ノード２が、図示せぬ通信ネットワークを介して接続されている。
重複検査依頼ノード１と重複検査ノード２は、それぞれ内部時計１１、２１を持ち、これは何らかの方法で同期しているものとする。重複検査依頼ノード１は、他に、一意識別子候補を作成する一意識別子候補作成部１２と、重複検査ノード２から重複がないことを応答された、使用可能な一意識別子候補を保持する、使用可能一識別子候補リスト１３（記憶装置）とを有する。
【００２０】
一方、重複検査を行なう重複検査ノード２は、本発明の一意識別子作成管理装置として動作し、重複検査依頼ノード１から送付され、判定を未だ行なっていない一意識別子候補の時間表現が許容範囲内であることをチェックする時間超過チェック部（演算装置）２２と、時間表現別で重複検査を行なう前の一意識別子候補を保存する判定待ち一意識別子リスト群（記憶装置）２７と、既に判定された一意識別子候補を時間表現別で保存する判定済一意識別子リスト群（記憶装置）２８と、判定待ち一意識別子リスト群２７から取り出した一意識別子候補を判定済一意識別子リスト群２８中の一意識別子候補と比較し、重複の有無を確認する重複検査部（演算装置）２３と、重複検査の結果、重複が無いことを確認した一意識別子候補とこれに付随する電子署名を応答する、応答作成部２４ならびに電子署名作成部２５で構成される。また、後述する時間監視の結果、判定待ち一覧識別子リスト群２７から検索対象から除外する一意識別子廃棄部（演算装置）２６も含む。
なお、括弧内は、これら機能が実装されるコンピュータ内のハードウェアを示す。図に示されるように、時刻同期、重複検査依頼、応答の３つのインクラクションを行なう。詳細は後述する。
【００２１】
図２（ａ）は、重複検査ノード２がサーバとして明示的に指定されている際における一意識別子の構造の例を示す。重複検査ノード２が（集中、分散を問わず）明示的に指定されていない場合の一意識別子の構造は、図２（ｂ）に示されている。
一意識別子は、いずれも１２８ビット長となっているが、この長さは、本来、任意であり、この他の長さをとっても、あるいは最低長さを決めた上でそれ以上の任意長さをとっても良い。ここでは、冒頭の３２ビットに時刻表現が記述されている。このため、１０秒単位で３２ビットの時刻表現を行なえば、開始時点から１３６０年程度の時刻を表現することができ、文書の一意性を保証する時間範囲としては十分である。
ここでは、ある時刻に発生させられた一意識別子は、その時間を越えない最大の時間表現に属する（時間表現の単位より小さい時間を切り捨てた時間に相当する表現）を持つこととする。図２（ａ）では、その後に、乱数フィールドが続き、ここまでが一意識別子候補の重複を確認する範囲である。その後にＮビットの内部管理番号フィールドが存在する。このフィールドは、重複確認時何であっても良い番号であるため、仮に、０を埋め込むことにする。
【００２２】
図３に、重複検査依頼ノード１の処理の流れをフローチャートで示す。図３において、一意識別子が必要となる、あるいは必要であると予想したノードは重複検査依頼ノード１として、まずネットワーク内の標準時計などにアクセスして内部時計１１を同期させる（Ｓ３１）。次に、そのネットワークにおける一意識別子候補の重複検査ノード２が明示的に指定されている場合、タイムアウトの時間設定条件などを取得する（Ｓ３２）。
以後、重複検査ノード２が明示的に指定されている場合について説明する。重複検査依頼ノード１は、一意識別子候補を作成するために、一意識別子候補作成部１２で所定の桁数の乱数を発生させ、その時点における時刻表現と組み合わせて一意識別子候補を作成する（Ｓ３３）。この形式は、図２（ａ）に示すものである。そして、重複検査依頼を重複検査ノード２に対して送出すると共に（Ｓ３４）、タイムアウトを判断するための時間測定を開始する。ここで、タイムアウト内に応答が返り、重複がないことが明らかになった場合（Ｓ３５、Ｙｅｓ）、重複検査依頼ノード１は、この応答内容内の一意識別子候補と付随する電子署名、さらに必要なら電子署名を認証するための公開鍵を自身で持つ使用可能一意識別子候補リスト１３に追加する（Ｓ３６）。
【００２３】
重複検査依頼の処理は以上で終了し、以後、一意識別子が必要になる度に取得した一意識別子候補に加えて内部管理番号フィールドに、自身に重複がないことを確認している番号を入力して一意識別子を作成し利用する。
【００２４】
図４〜図９、図１２は、一意識別子の重複検査を行なう重複検査ノード２の処理の流れを示すフローチャートである。図１２は、重複検査ノード２が自身で持つ各機能を立ち上げる前段階の処理を示す。
図１２において、重複検査ノード２は、まず、時刻同期、およびネットワーク内の一意識別子の重複検査に関する設定の確認を行なった上で（Ｓ１２１）、リスト廃棄時間（例えば、１分とする）の間待つ（Ｓ１２２）。これによって、仮に停止したはずの他の重複検査ノード２が引き継ぎの寸前に既に割り振った一意識別子が存在したとしても、これに重複する可能性が無くなる。この後で各種の処理を起動し、重複検査を開始する（Ｓ１２３）。これ以前に到来した重複検査依頼は単に廃棄される。
【００２５】
図４に、重複検査依頼の受信と、これを判定待ち一意識別子リスト群２７に入力するまでの処理の流れを示す。重複検査ノード２は、まず、設定を取得し（Ｓ４１）、ネットワーク内と時刻を同期した後で（Ｓ４２、Ｓ４３）、重複検査依頼待ちに入る（Ｓ４４）。
重複検査依頼が到来すると、この時刻表現をチェックし（Ｓ４５）、許容範囲を越えたものは廃棄（Ｓ４６）して再び重複検査依頼待ちの処理へ移行する（Ｓ４４）。許容範囲内の重複検査依頼は、判定待ち一覧識別子リスト群２７に入力し、再び重複検査依頼待ちとなる（Ｓ４７）。これにより、許容範囲でない時刻表現を待つ一意識別子候補を検査することなく破棄することが可能となる。ここで許容範囲は、ネットワーク上で予想される時刻精度と、計算される通信遅延量の和を上回る所定の時間範囲によって定義される。そして一意識別子候補が保持する時刻情報が現在時刻から前記所定の許容範囲に含まれないとき、当該一意識別子候補を識別子候補から破棄（除外）することとなる。
【００２６】
図５は、判定待ち一覧識別子リスト群２７中の一意識別子候補と、判定済み一覧識別子リスト群２８との比較、およびこれに基づく応答の処理の流れを示すフローチャートである。
ここで、重複検査ノード２は、判定待ち一意識別子リスト群２７に対して読み出し要求を行ない（Ｓ５１）、判定待ち一意識別子リスト群２７から、都度一識別子候補を取り出して（Ｓ５２）、重複検査部２３を起動し、既に重複が検査された判定済み一意識別子リスト群２８と比較して重複を検査する（Ｓ５３）。ここで、重複が発見されれば、一意識別子破棄部２６を介して一意識別子候補は廃棄される（Ｓ５６）。重複が発見されなければ一意識別子候補は、判定済み一意識別子候補リスト２８に追加され、電子署名作成部２５を起動して対応する電子署名を作成した上で（Ｓ５４）、応答作成部２４を介して依頼元の重複検査依頼ノード１へ一意識別子候補と電子署名を含む応答（非重複証明書）を送出する（Ｓ５５）。なお、応答作成部２４は、一意識別子が重複検査不要と判断された場合や、一意識別子が破棄された場合には、一意識別子候補の再作成を重複検査以来ノード１へ指示する。
そして、検査済の一意識別子候補は重複検査依頼ノードヘ送出され、使用可能な一意識別子候補として保存され利用される。
【００２７】
図６、図７は、判定待ち一意識別子リスト群２７の一意識別子候補を管理するための処理の流れを示すフローチャートである。
重複検査ノード２は、起動時に時刻同期確認および設定確認を行なった後（図６、Ｓ６１）、既に存在している判定待ち一意識別子リスト群２７の時刻表現（図１０参照）を確認する（Ｓ６２）。そして、現在時刻に対応した判定待ち一意識別子リストが存在するか否かをチェックし（Ｓ６３）、存在なければ対応したリスト（バッファ）を作成する（Ｓ６４）。このバッファには書き込み許可フラグが付随し、作成当初は書き込み許可設定がなされている。
次に、保持許容時間を越えたバッファが存在するか否かをチェックする（Ｓ６５）。保持許容時間を越えたバッファは、その中にまだ保持されている一意識別子候補と共に破棄される（Ｓ６７）。これは、比較対象となる判定待ち一意識別子リスト群２７が保持許容時間を越えた場合に、後述するようにやはり削除されるためで、それ以降、バッファを保持したとしても比較できないためである。
【００２８】
続いて、一意識別子が到来し、時刻表現をチェックされて入力される時、一意識別子候補の時間表現に対応するバッファが書き込み可能であるか否かのチェックを行なう（Ｓ６８）。書き込み不可能であれば一意識別子候補を破棄する（Ｓ６９）。書き込み可能であれば、一意識別子をバッファに入力する（７０）。
この後、バッファの残り容量をチェックする（図７、Ｓ７１）。バッファの残り容量がまだあれば、書き込みを継続できるが、残り容量が無いようであれば該当するバッファを書き込み不能とする（Ｓ７２）。なお、バッファの初期容量は、重複検査依頼処理を時間内に行なえる個数や記憶容量の制限などを考慮して決定される。
更に読みだし要求があり、かつバッファ内に出力できる一意識別子候補があるか否かを判断する（Ｓ７３）。上記したように、読み出し要求は、図５で一意識別子の検査を行なうルーティンが発生する、出力できる一意識別子候補がある場合、これを出力すると共にバッファからは削除する（Ｓ７４）。上記した処理を繰り返すことにより、判定待ち一意識別子リスト群２７の操作が行なわれる。
【００２９】
図８、図９は、判定済み一意識別子リスト群２８の一意識別子を管理するための処理の流れを示すフローチャートである。
重複検査ノード２は、まず、時刻の同期確認および設定の確認の後（図８、Ｓ８１）、現在存在する複数の判定済み一意識別子リスト群２７の時刻表現（図１１参照）を確認する（Ｓ８２）。そして、現在時間、さらには保持許容時間と比較のうえ（Ｓ８３、Ｓ８５）、対応したリスト（バッファ）がなければ対応したバッファを作成し（Ｓ８４）、許容時間を超過したバッファに対してはこれを削除する（Ｓ８６）。このことにより、許容時間を超過した一意識別子の破棄が実現される。さらに重複検査要求があれば（Ｓ８７）、対応する時間表現を持つバッファに対して一意識別子候補と同じものがあるか否かを検索する（Ｓ８８）。そして、重複の有無をチェックし（図９、Ｓ８９）、ここで重複が発見されれば重複ありを応答するとともに、一意識別子候補を破棄する（Ｓ９０）。重複がなければ重複無しを応答し（Ｓ９１）、バッファに一意識別子候補を追加する。これによって重複がないことが確認された一意識別子候補がバッファ内に蓄積され、次の一意識別子候補の検索に用いられる。
【００３０】
図１０は、判定待ち一意識別子リスト群２７のデータ構造の一例を示す。各バッファは、書き込みフラグおよび対応する時刻表現を持ち、さらにこれらのバッファが保持許容時間分だけ存在してリスト全体を構成する。対応する時刻表現は一意識別子候補のそれと同じ構造を持つ。
図１１は、判定済み一意識別子リスト群２８のデータ構造の一例を示す。各バッファは、対応する時刻表現を持ち、さらにこれらのバッファが保持許容時間分だけ存在してリスト全体を構成する。対応する時刻表現は、一意識別子候補のそれと同じ構造を持つ。
【００３１】
図１３は、以上説明した前提とは異なり、サーバを明示的に定めず、全てのノードが余力に応じてサーバ機能を実現する場合のネットワーク構成の一例を示す。
図１３のシステム構成によれば、重複検査依頼ノード１は、周囲の重複検査ノード２と成り得るノード一つを選ぶか、あるいは複数に対して一度に重複検査依頼を行なうことになる。複数のノードに対して一度に重複検査依頼を行なう場合、当該依頼がネットワーク全体に対して到達する必要はなく、通常は到達範囲をネットワーク上の中継回数などで制限する。重複検査ノード２は、上記により説明した設定により一意識別子の形式などは共有するが、バッフアの容量などは白身の能力や余裕に併せて決定する。
【００３２】
この時、重複検査ノード２は、基本的にこれまで説明した通りの方法で重複検査を行ない、重複がなければ重複検査依頼ノード１に対して応答を返す。複数の応答が返った場合、重複検査依頼ノード２は、それら全て、ないし一部を白身で保持し、一意識別子候補として利用する。但し、重複検査ノード２は、応答内に自身を一意識別する情報を入力しなければならない。その理由は、重複検査ノード１つにおいて一意識別子候補の重複をチェックしたとしても、その情報がネットワーク全てに行き渡っている保証はないため、誰がチェックしたかという情報も一意識別子候補中に存在しなければ一意性の保証ができないからである。
【００３３】
図１４に、明示的にサーバが指定されない環境における、図５に対応する処理の流れがフローチャートで示されている。
ここでは、Ｓ１４５の処理が付加され、自身のＩＤ(ＭＡＣアドレス、ＩＰアドレスなどがありうるが、これは設定によって決められる)を一意識別子候補中に入力して応答する点のみ異なる。
【００３４】
以上説明のように、本発明は、ネットワーク全体に対する重複問い合わせ、および管理者に対する重複問い合わせの双方に関し、一意識別子候補を構成するビット列の一部に作成時点の時刻の表現を導入し、これらの重複検査の問合せにおいて、一意識別子候補が保持する時間情報をチェックすることを特徴とする。このように、ネットワーク全体への問い合わせでのコンピュータの離脱や休止の影響抑制としては重複検査対象である一意識別子候補が、ある時点においては一定の範囲の時間表現しか持ちえないことを利用し、離脱や休止したコンピュータによる検査を行なえなくても長時間存在しているネットワークにおいても重複検査を行なうことができるものである。
また、一意識別子の管理者への問い合わせにおいては、同じく重複検査対象である一意識別子候補が、ある時点においては一定の範囲の時間表現しか持ち得ないことから、管理者が一定時間以上の過去の一意識別子を管理者が保持する必要を無くすことでこれを廃棄することを容易にし、かつ他の管理者へ移行する際にも、移行の際に一定時間以上経過するまで重複検査を中断することにより重複を検査する一意識別子候補の記録を移行せずに重複検査を可能にすることができる。
【００３５】
なお、ここで用いられる時刻の表現は、必ずしも何らかの標準時計に準拠するものである必要はなく、一意識別子管理者のコンピュータと一意識別子候補を作成するコンピュータの時計が同期していれば本発明の用途には十分である。すでに標準時計に準拠した時刻の取得はＮＴＰ（Network Time Protocol）２のような時刻の同期プロトコルを用いたサービスにより実現され公開されているため、少なくともあるグループに属するコンピュータ群が内部時計を１秒以下程度の同期することは現在でも容易である。このため、上記したコンピュータは、時刻の同期を本発明で必要とする１秒程度の精度で行ない得ることを前提としている。ＲＦＣ１３０５で規定されたネットワークを経由したコンピユータ間の時刻同期プロトコルに従う同期に要する通信のネットワーク遅延を考慮に入れても、この程度の精度は十分に確保できる
【００３６】
また、重複検査依頼ノード１は、一意識別子候補を作成するが、この中の規定された位置に時刻の表現が記述される。時刻表現は任意であるが、ここでは仮に１０秒単位で３２ビット程度記述されているとする。そして、重複検査依頼ノード１は、作成した一意識別子候補を一意識別子管理者の重複検査ノード２に送出する。これらコンピュータ間の内部時計は、１秒程度の精度で同期されているため、通信遅延などを考慮に入れても、重複検査ノード２に重複検査依頼ノード１が作成した一意識別子候補が到達した時、一意識別子候補内に先に記述された時刻をチェックして現時点の時刻の表現として正しいか否かを判別することは容易である。
重複検査依頼ノード１は、この判別が行なわれた後に時刻表現が正しくなければ放棄してこの一意識別子候補に開するその後の処理を行なわず、他の一意識別子候補の送付を待つ。正しければ、重複検査依頼ノード１は送付された一意識別子を判別待ち行列に人力する。重複検査依頼ノード２は、更に判別待ち行列の先頭にある一意識別子候補を既に発行した一意識別子候補のリストと比較して一致の有無を判別する。一致がなければその旨を重複検査依頼ノード１に通知する。また、一致すれば、その旨を重複検査依頼ノード１に通知し、あるいは通知を行なわない方法の両方がありうる。本発明はこの双方を含むが、ここでは通知を行なわないこととして説明した。
【００３７】
一致しなかった旨を通知された重複検査依頼ノード１は、一意識別子候補の一意性を重複検査ノード２に保証されて使用することが可能になる。通知が届かなかった場合には重複検査依頼ノード１はタイムアウト処理を行ない、一意識別子候補を改めて作成して重複検査ノード２に対して重複判断を依頼する。
重複検査ノード２は、発行した一意識別子候補のリストを保持するが、このリストは一意識別しない、記述された時刻表現によって分類されている。この場合、この単位は１０秒程度であるが、一定時刻以上が経過した際には、そもそもその時刻表現を含む一意識別子候補は判別前に判別不要として放棄されるため不要になる。このリストが完全に不要になるのはある時刻表現を持った一意識別子候補の判別が全て終了した場合であるか、あるいは残りがあったとしても終了することにしてしまう場合かのいずれかである。ここでは、重複検査ノード２がタイムアウト処理を行なうため、それ以上の保持は不要である。ここでは、このタイムアウト時刻を１分と規定した。このことにより、重複検査依頼ノード１は、送付後１分以上経過した一意識別子候補リストの分類はこれを削除する。これにより重複検査依頼ノード１は、長時間に渡って多数の一意識別子候補の重複検査を行なった場合にも過去１分以内の通知以上のリストを保持する必要がない。このため、重複検査依頼ノード１は大量のリストを保持することなく重複判定を行なうことが可能となる。
【００３８】
さらに、重複検査依頼ノード１（Ａ）が、何らかの理由で重複検査を行なうことをやめて他のノード（Ｂ）が重複検査依頼ノード１になる場合、その重複検査依頼ノード１（Ｂ）は、先の重複検査依頼ノード１（Ａ）が最後に行なっていた時刻から、少なくとも時刻表現の単位分の時刻ないしその数倍程度の時刻が経過してから重複検査依頼の受信を開始する。これにより、重複検査依頼ノード１（Ｂ）は、重複検査依頼ノード１（Ａ）が保持していたリストを一切引き継ぐこと無しに、既に重複検査依頼ノード１（Ａ）が重複検査ノード２に対して応答を行なった一意識別子と重複した一意識別子を別の重複検査依頼を行なった重複検査依頼ノード１（Ｃ）に対して行なう可能性を排除することができる。これによってＤＮＳの場合とは異なり、重複検査を行なう重複検査ノード２は、可能な場合にそのサービスを行ない、都合が悪くなれば別の重複検査ノード２（Ｄ）に対して大量の情報を引き継ぐこと無く重複検査を引き継がせることが可能となる。
【００３９】
また、本発明実施形態によれば、タイムアウト時間をあらかじめ規定して重複検査依頼ノード１と重複検査ノード２が共有している。特に一意識別子の管理を行なう重複検査ノード２は、タイムアウト時間までに自身が判別し応答処理まで済ませることが可能な一意識別子候補の数をあらかじめ予想し、これ以上の一意識別子候補を最初から待ち行列に入れず放棄することも可能となる。これによってある時刻に集中して行なわれた問い合わせに対しても、重複検査ノード２は少しずつ判別処理を行ない、特に失敗したことを示す通知を行なわなかったとしても重複検査依頼ノード１が再度問い合わせることが可能になる。また、失敗した待ち行列の時刻表現を含む処理に失敗した通知を重複検査ノード２が重複検査依頼ノード１に対して行なうことで、重複検査依頼ノード１が少し時間をおいて再度判別依頼を行なうことも可能である。
更に、重複がないことを通知する通信において、重複検査ノード２が、あらかじめ公開している公開鍵に対応した秘密鍵を用いて一意識別子候補の電子署名を作成してこれを同時に通知し、重複検査依頼ノード１は一意識別子を使用する際にこの電子署名を同時に記述することで、一意識別子候補の正当性を証明できる。一意識別子候補を決められた手順抜きで作り公開することは可能であるが、このことにより、重複した一意識別子を持つ文書を発見した際にも正当な物を判別することが可能になる。
【００４０】
本発明によれば、ドキュメント識別子の一意性の管理を大量のデータを長期間管理する必要をなく実現することができ、また、一意識別子の特定フィールドで文書作成者を特定してトラッキング不能とすることが可能となり、ＤＮＳのように負担を長期に渡りサーバに負わせることなく一意識別子の管理が可能となる点で有益である。
また、一意識別子の重複を検査する重複検査ノード２は必ずしも一台のコンピュータである必要はない。例えば、複数のコンピュータが一意識別子の一部のビットをキーにしてあらかじめ分担範囲を決め、一意識別子のリストを分散して持って重複検査処理も分担し、重複検査ノード２としての動作を分散して行なう方法がある。この時、重複検査依頼ノード１は、重複検査を行なうのにあらかじめ一意識別子の分担範囲と担当サーバのアドレスを入手しておくか、あるいはサーバのどれか一つに対して送出し、受信したサーバが担当サーバヘ転送するといった方法等が考えられる。このようなサーバの分散は本発明から容易に類推が可能である。
【００４１】
さらに、分担範囲の決定を前もって行なわず、たまたま近接しているノードが一意識別子の管理を行なう方法もあり得る。この場合、重複検査依頼ノード１は、近接したノードに対して一意識別子の重複検査を行なうノードを表すアドレスに対するマルチキャストないしユニキャストによって一意識別子候補を重複検査のために送出する。これを受信した重複検査ノード２に相当するノード（群）は、受信した一意識別子候補を自身のリストでチェックし応答を行なう。この時、全ての重複検査ノード群が同じリストを保持している保証はないため、重複検査ノード群は、重複がなかったことを確認した一意識別子候補中に白身特有の情報であるＭＡＣアドレスやＩＰアドレスなどを挿入して応答し、重複検査依頼ノード１は、この重複検査ノード群のＭＡＣアドレスやＩＰアドレスを含めて一意識別子として用いる。複数の応答があった場合にはこれらを全て一意識別子候補として用いることができる。実際に一意識別子に内容を記入するのは重複検査依頼ノード１であるため、重複検査ノード群のＭＡＣアドレスやＩＰアドレスが挿入されていたとしても、これをキーにしてトラッキングすることはできない。このような重複検査ノード群の利用もまた本発明から容易に類推されるものである。
【００４２】
なお、図１に示す、内部時計１１、２１、一意識別子候補作成部１２、時間超過チェック部２２、重複検査部２３、応答作成部２４、電子署名作成部２５、一意識別子破棄部２６のそれぞれで実行される手順をコンピュータ読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって本発明の一意識別子作成管理装置を実現することができる。ここでいうコンピュータシステムとは、ＯＳや周辺機器等のハードウェアを含む。
【００４３】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００４４】
以上、この発明の実施形態につき、図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００４５】
【図１】本発明実施形態に係わるにおける一意識別子作成管理システムのシステム構成の一例を示す図である。
【図２】本発明実施形態に係わる一意識別子のデータ構造の一例を示す図である。
【図３】本発明実施形態に係わる重複検査依頼ノード１の処理の流れをフローチャートで示した図である。
【図４】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図５】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図６】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図７】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図８】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図９】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図１０】本発明実施形態に係わる判定待ち一意識別子リスト群の構成の一例を示す図である。
【図１１】本発明実施形態に係わる判定済み一意識別子リスト群の構成の一例を示す図である。
【図１２】本発明実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【図１３】本発明の他の実施形態に係わる一意識別子作成管理システムのシステム構成の一例を示す図である。
【図１４】本発明の他の実施形態に係わる重複検査ノード２の処理の流れをフローチャートで示した図である。
【符号の説明】
【００４６】
１…重複検査依頼ノード、２…重複検査ノード、１１、２１…内部時計、１２…一意識別子候補作成部、１３…使用可能一意識別子候補リスト、２２…時間超過チェック部、２３…重複検査部、２４…応答作成部、２５…電子署名作成部、２６…一意識別子破棄部、２７…判定待ち一覧識別子リスト群、２８…判定待ち一覧識別子リスト群
【図１】
2005339134.tif 000003
【図２】
2005339134.tif 000004
【図３】
2005339134.tif 000005
【図４】
2005339134.tif 000006
【図５】
2005339134.tif 000007
【図６】
2005339134.tif 000008
【図７】
2005339134.tif 000009
【図８】
2005339134.tif 000010
【図９】
2005339134.tif 000011
【図１０】
2005339134.tif 000012
【図１１】
2005339134.tif 000013
【図１２】
2005339134.tif 000014
【図１３】
2005339134.tif 000015
【図１４】
2005339134.tif 000016