(57)【特許請求の範囲】
【請求項１】
複数の利用者端末装置、複数の文書サーバがネットワークに接続された署名付ハイパーテキストシステムであって、
上記文書サーバは、
ハイパーテキスト構成部と、ハイパーテキスト配布部と、これらに機能された文書蓄積部と、ハイパーテキスト配布部をネットワークに接続するネットワーク接続部とを備え、
上記ハイパーテキスト構成部は文書識別子と、文書発行者識別子と、属性名、属性値、リンク先文書識別子及びリンク先文書に対する制約条件を規定する属性定義部と、署名とを有する文書の複数のリンク結合よりなるハイパーテキスト中の少なくとも１つの文書を作成し、その際にリンク元文書であってリンク先の文書が具体化されていない文書に対してユニークな文書識別子を上記リンク先文書識別子とし、上記リンク元文書の制御条件に従ったリンク先文書が具体化したときに上記リンク先文書識別子を文書識別子とする上記具体化した文書を作成するものであり、
他の文書サーバから受信した文書は文書蓄積部に格納され、
上記利用者端末装置は、ハイパーテキスト取得部と、ハイパーテキスト検証部と、ネットワーク接続部と、ハイパーテキスト表示部とを備え、
ハイパーテキスト検証部は、ハイパーテキスト取得部で取得した文書に属性定義部があればリンク先文書識別子を取り出し、そのリンク先文書識別子のリンク先文書を文書サーバから取得し、そのリンク元の文書をリンク先文書識別子がリンク先の文書の文書識別子と一致するかを検証し、またそのリンク先文書が上記制約条件を充足しているかを検証し、またそのリンク先文書が検証し、属性定義部がなければ署名の検証を行うものである
ことを特徴とする署名付ハイパーテキストシステム。
【請求項２】
上記制約条件はリンク先文書が従うべき文書形式であり、
上記文書サーバは上記文書形式に従った上記リンク先文書を作成し、
上記ハイパーテキスト検証部は上記リンク先文書が上記文書形式を定義した制約スキーマの整合性を検証する
ことを特徴とする請求項１記載の署名付ハイパーテキストシステム。
【請求項３】
上記制約条件はリンク先文書の特定の属性の値を限定するものであり、
上記文書サーバは上記限定された特定の属性の値に従って上記リンク先文書を作成し、
上記ハイパーテキスト検証部は上記リンク先文書の上記特定の属性の値を検証する
ことを特徴とする請求項１記載の署名付ハイパーテキストシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、例えば商取引に必要な様々な文書を電子的に流通させるシステム、特に、流通の過程で文書の記載内容の変更を伴う電子チケット、電子証明書等を安全に流通させることを可能とする署名付ハイパーテキストシステムに関するものである。
【０００２】
【従来の技術】
近年、ネットワーク上での商取引が盛んになってきており、ネットワーク上で電子現金、電子チケット、電子証明書、受発注伝票等の授受が行われるようになってきた。このような文書をインターネットのような不特定多数の人で共有するネットワーク上で流通させるためには、文書を改竄（かいざん）、盗聴、なりすまし等の不正行為から守る必要である。そのような不正行為を防ぐ代表的な技術としては、例えばRSA Data Security 社のＲＳＡ方式や日本電信電話株式会社のESIGN 等のようなディジタル署名がある。ディジタル署名（以後、単に署名と記）では、署名者が、署名者しか知らない秘密鍵によって署名対象の文書を暗号化することにより、その文書を受取った人が、上記秘密鍵に対する公開鍵を使ってその文書の解読を行うことにより、その文書が署名者本人によって署名され、また、改竄されていないことを検証することができる。
【０００３】
しかしながら、一旦、署名された文書に対し内容を変更すると、署名が無効になるため、例えば、電子チケットのように、予約状態、支払状態、所有者等のチケットの属性が動的に変化する文書に署名を適用する場合には、工夫が必要となる。単純な方式では、図１で示されるように、変更の度に、変更前の文書に、どの属性をどのように変更したかを記述した変更情報を添付して全体を再署名する。図において矢印は署名を適用する範囲を表している。つまり発行者ＩＤ 101と本文102 に対し発行者署名103 が付けられ、これら101, 102, 103 と、変更者１のＩＤ 104と変更情報105 に対し変更者１の署名106 が付けられ、このようにして、変更時にはそれまでのすべての情報と変更者ｎのＩＤ 107と変更情報ｎ 108に対する変更者ｎの署名109 を付ける。
【０００４】
しかしながら、この方式では、本文102 のある属性に対する最終的な値を得るためには、変更情報１（105）…変更情報ｎ（108）を全て解析することが必要になり、処理が複雑になる。また、署名も多重に行うため署名の処理コストが大きい等の問題がある。
また、電子チケットや契約文書等における属性は一般に誰でも自由に変更することが許されるわけではなく、特定の権限を持つ人のみに限定したい場合がある。例えば、予約状態の変更は発行者に限定する、あるいは、支払状態の変更は銀行のみに限定する、あるいは、所有者の変更は代理店のみに限定する等である。これらの権限制御を行うための汎用的な方法については、未だ検討されていない。
【０００５】
また、電子チケットや契約文書等では、流通あるいは回覧の過程で、別の文書が添付される場合があるが、これらの添付される文書を特定の形式の文書に限定したい場合がある。例えば、予約状態の変更は、予約券が添付されなければならない、あるいは、支払状態の変更は小切手が添付されなければならない、あるいは、所有者の変更は、譲渡証明書が添付されなければならない等である。これらの制御を行うための汎用的な方法については、未だ検討されていない。
【０００６】
【発明が解決しようとする課題】
このように従来においては、文書の特定のフィールドあるいは属性に対して、特定の権限を持つ人のみが変更できるように限定する汎用的な方法、あるいは、特定の形式の文書のみを添付できるように限定するための汎用的な方法がないため、これらの制御が必要な文書を流通させたい場合には、応用毎あるいは流通する文書の種別毎に特別なソフトウェアを開発する必要があった。また、流通あるいは回覧の過程で変更される属性を持ち、かつ不正な改竄を防止するために署名されている文書は、最終的な値を参照するためには、すべての変更情報の解析する必要があり、処理が複雑になるという問題があった。
【０００７】
この発明の目的は、上記のような従来の課題を解決した署名付ハイパーテキストシステムを提供することにある。
【０００８】
【課題を解決するための手段】
この発明による署名付ハイパーテキストシステムによれば、リンクにより結合した複数の文書から構成するハイパーテキストが記録された記録媒体が用いられ、
上記ハイパーテキストを構成する複数の文書の少なくとも１つは、その文書の識別子と、その文書の発行者の識別子と、少なくとも１つの属性定義部と、その文書全体に対する発行者署名とから構成され、
上記少なくとも１つの属性定義部には、属性の値とリンク先文書の識別子と、リンク先文書に対する制約条件を定義する制約条件定義部とが設けられている。
【０００９】
上記構成の署名付ハイパーテキストの記録媒体において、リンク先文書に対する制約条件として、リンク先文書が従うべき文書形式定義したリンク先文書のスキーマを指定してもよい。
また、上記構成の署名付ハイパーテキストの記録媒体において、リンク先文書に対する制約条件として、リンク先文書の特定の属性の値を指定してもよい。
【００１０】
また、上記構成の署名付ハイパーテキストの記録媒体において、リンク先文書に対する制約条件として、リンク先文書のハッシュ値を指定してもよい。
この発明によれば、リンクにより結合した複数の文書から構成されるハイパーテキストを構成する際に、以下のステップを用いるとよい。
(a) 上記ハイパーテキストを構成する複数の文書の少なくとも１つを、その文書の識別子と、その文書の発行者の識別子と、属性の値を規定する少なくとも１つの属性定義部と、その文書全体に対する発行者署名とから構成し、
(b) 上記属性定義部がリンクを持つ場合には、上記属性定義部にリンク先文書の識別子と、そのリンク先文書に対する制約条件を定義する制約条件定義部とを構成し、
(c) リンク元の文書を構成する時にリンク先の文書が具体化していない文書に対しユニークなリンク先文書識別子を生成し、将来のリンク先文書の識別子として上記リンク元文書の上記属性定義部に含め、
(d) 上記リンク先の文書が具体化したときに、上記リンク先文書の識別子を識別子とする上記具体化した文書を生成する。
【００１１】
この発明において、上記署名付ハイパーテキストに対する検証の際に、(a) 上記リンク先の文書が上記リンク元の文書に定義された上記制約条件にあっているかどうかを検証し、(b) 上記ハイパーテキストを構成する各文書の発行者の署名を検証する。
リンク元の文書を定義する時にリンク先の文書が具体化していない場合に上記構成の署名付ハイパーテキストを構成する装置としては、具体化していない文書に対するユニークな文書識別子を生成する手段と、前記識別子を将来のリンク先文書の識別子としてリンク元文書に格納し、リンク元の文書を生成する手段と、リンク先の文書が具体化したときに、前記リンク先文書の識別子を前記具体化した文書の識別子として前記具体化した文書を生成する手段により、リンク先文書を添付する。
【００１２】
また、上記構成の署名付ハイパーテキストを検証するための装置としては、リンク先の文書の識別子がリンク元の文書に定義されたリンク先文書の識別子と一致するかどうかを検証する手段と、リンク先の文書がリンク元の文書に定義された制約条件に合っているかどうかを検証する手段と、前記ハイパーテキストを構成する各文書の発行者の署名を検証する手段とを備える。
【００１３】
【発明の実施の形態】
以下、この発明の実施例を、図面により詳細に説明する。
図２〜図４Ｂは、この発明に用いる署名付ハイパーテキスト250 の構造図である。一つの署名付ハイパーテキスト250 は、図２に示すようにリンクによって結合した例えばHTMLやXML による複数のハイパーテキスト文書200〜240の集合によって構成する。このリンクの少なくともルートの文書200 は署名付文書である。ルート以外のリンク先文書は署名付の場合（220, 230）もあるし、署名付でない場合（210, 240）もある。また、各文書は複数のことなるリンク先を持ってもよい。図２の例では、文書210 は１つのリンク先に文書230 を有しており、もう１つのリンク先には文書が設けられてないが、将来文書を設けることが可能なことを示している。
【００１４】
図３に示すように一つの署名付文書200 は、スキーマＩＤ 201、文書ＩＤ 202、発行者ＩＤ 203、本文204 と、これらに対する発行者の署名205 から構成される。ただし、後で述べるように、例えば文書210 のように他の署名付文書200 によって指定されたハッシュ制約によって、その文書210 の内容が改竄できなくなっている場合、あるいは、その文書210 がサーバのアクセスコントロール等の別の手段によって変更が制御される場合では、署名による改竄防止は必要ではない。この様な場合には、文書210 の発行者ＩＤ（203 に対応）及び発行者署名（205 に対応）は省略してもよい。スキマーＩＤ 201は、署名付文書200 の構造（書式）を指定するスキマー定義に対する識別子である。また、文書の形式に関して制約がない場合、あるいは、後で述べるように、他の署名付文書によって指定されたスキーマ制約によってスキーマＩＤが指定される場合には、スキーマＩＤを取得できるので、スキーマＩＤ 201も省略できる。文書ＩＤ 202は、署名付文書200 に対する識別子であり、あらゆる文書の間でユニークになるように付与する。また、後で述べるように、実施例によっては、文書ＩＤ 202についても省略できる。発行者ＩＤ 203は、文書に署名する人あるいは機関の識別子である。
【００１５】
本文204 は、０個以上の属性定義部206，207によって構成される。更にこれらの各属性定義部は、図４Ａに示すように属性名302 と値303 の組、あるいは図４Ｂに示すように属性名402、値403、リンク先文書ＩＤ 404、制約条件定義部405 の４つ組で構成される。
属性名302，402は、例えば、署名付文書200 がコンサートチケットの場合では、例えば「開催日」、「開催場所」等のカテゴリ名であり、値303，403は、カテゴリの内容を特定する例えば「1998-03-03」、「ニューヨーク・シティホール」等の具体的な値である。リンク先文書ＩＤ 404は、リンク先の署名付文書の識別子である。制約条件定義部405 は、リンク先の文書の構造あるいは属性値を限定するための制約条件であり、詳細は後述する。
【００１６】
図４Ａに示したように属性定義部301 が属性名302 と値303 の組で構成される場合は、属性名302 で表わされる属性の値が値303 であると解釈する。
図４Ｂに示したように属性定義部401 が属性名402 、値403 、リンク先文書ＩＤ 404、制約条件定義部405 の４つ組で構成される場合は、リンク先文書ＩＤ 404によって参照されるリンク先に文書が存在する場合と、存在しない場合でその属性値の解釈が異なることとする。つまり、リンク先文書ＩＤ 404によって参照されるリンク先に文書410 が存在しない場合（以後、不完全リンクと呼ぶ）は、値403 が属性名402 で表わされる属性の値であると解釈する。リンク先文書ＩＤ 404によって参照されるリンク先に文書410 が存在する場合（以後、完全リンクと呼ぶ）で、かつ文書410 が制約条件定義部405 に定義されている条件を充足する場合には、リンク先文書410 の本文414 が属性名402 で表わされる属性の値であると解釈する。リンク先文書ＩＤ 404によって参照されるリンク先に文書410 が存在するが、制約条件定義部405 に定義されている条件を充足しない場合には、署名付ハイパーテキスト200, 410が正当ではないと解釈する。なお、リンク先は複数の属性定義部206, 207にそれぞれ異なるリンク先を設けてもよい。
【００１７】
リンク元文書を生成する際に、リンク先文書が具体化していない場合は、予めリンク先文書に対するユニークな文書ＩＤを生成し、これを将来のリンク先文書ＩＤ 404としてリンク元文書に格納し、リンク元の文書に署名する。そして、リンク先の文書410 の本文（値）414 が具体化したときに、前述のリンク先文書ＩＤ 404で指定された文書ＩＤ 412の文書として前記具体化した本文414 を有する文書410 を生成する。
【００１８】
制約条件定義部405 としては、この実施例では、ハッシュ値による制約406 、スキーマＩＤによる制約407 、属性値による制約408 について以下に記載するが、これ以外にも属性値の値域や型、あるいは属性値間の大小関係などの指定を含む多様な条件が考えられる。
ハッシュ値による制約406 は、リンク先の文書410 がリンク元の文書作成時に完全に確定している場合にリンク先の文書が不正に置き換えることを防止するための制約として利用するものであり、リンク先の文書のスキーマＩＤ 411、文書ＩＤ 412、発行者ＩＤ 413、本文414 の結合に対してハッシュ値を生成し、この値をリンク元の署名付文書200 における属性定義部401 の制約条件定義部405 が定義する制約条件の１つとして定義する。また、リンク先の文書410 の文書ＩＤ 412をリンク元の署名付文書の属性定義部のリンク先ＩＤ 404として定義する。これにより、他の目的で作成した文書をリンク先文書として置き換えると、ハッシュ値制約を充足しなくなるため、不正な置き換えを検出することができる。また、ハッシュ値制約が与えられた場合には、リンク先の文書を改竄した場合においてもハッシュ値制約を充足しなくなり、不正な改竄を検出できる。このため、前述のようにこの制約が与えられた場合には、リンク先文書410 の発行者署名415 は省略できる。なお、ハッシュ値の生成方法としては様々な方法が提案されているが、例えば、RSA Data Security 社によるＭＤ５方式等が利用できる。なお、Ross J. Anderson等の"The Eternal Resource Locator: An Alternative Means of Establishing Trust on the World Wide Web," 3rd USENIX Workshop on Electronic Commerce, 31 August-3 September 1998にはそれぞれの専門分野の医師により作成され、更新された医療情報のカタログリストをHTML文書でＷＷＷ上に公開し、その各リストのハッシュ値をリンク先に設けることによりリンク元文書を改変できないように制約することが示されているが、この発明ではこのようなハッシュ制約のみならず多様な制約条件によりリンク先文書を制約することを可能にしている。
【００１９】
別の実施例としては、文書ＩＤ 202を用いず、リンク先の文書中の特定の属性値に対して、文書ＩＤと同様な方法により生成したユニークな識別子を有することを、属性値制約として指定してもよい。こうすることにより、他の目的で作成した署名付文書をリンク先の文書として置き換えることを防止することもできる。従ってこの場合には、本実施例のように、署名付文書として必ずしも文書ＩＤ 412を持たせる必要はない。
【００２０】
スキーマＩＤによる制約407 及び属性値制約408 は、リンク先の文書がリンク元の文書作成時に具体化していない場合に、リンク先文書の発行者あるいはその他の属性値や構造を限定するための制約条件である。
スキーマＩＤによる制約407 は、リンク先文書のスキーマＩＤ 411がスキーマＩＤ制約407 と一致するだけではなく、スキーマＩＤによって参照されるスキーマと整合していること（例えば図８で説明するように各属性に対し指定された数の値が入っていること）が制約条件となる。従って、この整合性を検証するためには、スキーマＩＤからスキーマ定義を獲得する必要があるが、この方法については、例えば、スキーマＩＤとしてWorld Wide Web Consortium (W3C) において仕様化しているUniversal Resource Identifier (URI) 等によって指定し、IETFにおいて仕様化しているHTTPプロトコル等により、ネットワーク上に置かれたスキーマ定義を獲得する等の方法がある。また、予め利用が想定されるスキーマ定義に関しては、ローカルにキャッシュを置いておくことで、オフラインでスキーマ定義を獲得することもできる。
【００２１】
一つのスキーマ定義500 は、図５に示すようにメタスキーマＩＤ 501、スキーマ定義者ＩＤ 502、スキーマＩＤ 503、発行者ＩＤ 504、本文構造定義505 、スキーマ定義者署名506 の６つ組で構成される。
メタスキーマＩＤ 501は、スキーマ定義の構造に対する識別子であり、将来、スキーマ定義500 の構造を変更した場合に、新旧のスキーマ定義を区別可能にし、移行を容易にするためのものである。
【００２２】
スキーマ定義者ＩＤ 502は、スキーマを定義する人あるいは組織の識別子である。スキーマＩＤ 503は、スキーマ定義500 自身の識別子である。これをスキーマ定義に含めることでスキーマ定義者によって署名されるが、これにより例えば、このスキーマ定義500 がローカルな記憶媒体にキャッシュされている場合、あるいは取引相手から直接渡された場合であってもそのスキーマＩＤに対する正当なスキーマ定義であることを検証できる。
【００２３】
発行者ＩＤ 504は、スキーマ定義が対象とする署名付文書200，410の発行者ＩＤを限定するものである。例えば、航空券において、航空会社毎に異なるスキーマを定義する場合には、この発行者ＩＤ 504に各航空会社の識別子を指定することが可能であるが、例えば、航空業界で共通の航空券のスキーマを定義する場合には、この属性は指定されない。
【００２４】
本文構造定義505 は、具体的な電子チケットや証明書の種類に依存して必要となる属性を定義する部分であり、例えば、コンサートチケットの場合は、開催日、開催場所等、航空券の場合は、出発日、便名等の属性が定義される。これらの属性は、スキーマ定義者によって自由に定義することができる。また、これらの属性それぞれについて、必須属性なのかオプション属性であるかの種別、あるいは、複数の値が指定されることが許されるかどうかの種別が定義される。また、スキーマ毎に固定化したい属性値については、その具体的な値を指定することもできる。
【００２５】
スキーマ定義者署名506 は、メタスキーマＩＤ 501、スキーマ定義者ＩＤ 502、スキーマＩＤ 503、発行者ＩＤ 504、本部構造定義505 の結合に対するスキーマ定義者の署名である。尚、この実施例では、制約条件定義部405 におけるスキーマを指定する方法として、署名付文書の外でスキーマ定義500 が定義されていることを前提とし、これをスキーマＩＤによって参照するという方法を示したが、別の方法として、スキーマ定義500 によって定義される内容自身を、直接制約条件405 として定義することもできる。
【００２６】
属性値による制約408 は、リンク先文書ＩＤ 412、発行者ＩＤ 413あるいは本文414 内の一つあるいは複数の属性値の値を指定するものである。この制約条件は、スキーマＩＤ制約によって参照されるスキーマ定義による制約では十分限定できない場合に、更に特定の属性値に関する制約を付与した場合等に有効である。例えば、業界団体等の第３者機関によって定義された共通のスキーマによる制約に加えて、発行者ＩＤ 413の値として特定の会社ＩＤを指定したい場合等である。
【００２７】
図６は、航空券600 を上記で述べた署名付文書200 （図３）によって表現した具体例であり、図７は航空券600 の所有者ＩＤ属性を変更した場合にリンク先文書410 （図４Ｂ）として添付される値変更証明書700 の具体例である。航空券600 の具体的構成は図８に示す航空券スキーマ800 によって定義されるが、基本的には図３で示した署名付文書200 と同様の構成であり、スキーマＩＤ 601、文書ＩＤ 602、発行者ＩＤ 603、本文604〜612、発行者署名613 からなる。本文604 〜612 は権利種別604、出発日605、便名606、出発地607、到着地608 、所有者ＩＤ 607〜612 をそれぞれ属性定義部として有している。この例では、予め作成された航空券600 はその所有者ＩＤ属性に対してスキーマＩＤと属性値による制約付の不完全リンクであったが、その後、値変更証明書700 を添付して完全リンクとした場合である。値変更証明書700 の具体的構成は図９に示す値変更証明書スキーマ900 によって定義されているが、基本的には図４Ｂで示したリンク先文書410 と同様の構成であり、スキーマＩＤ 701、文書ＩＤ 702、発行者ＩＤ 703、本文704〜708、発行者署名709 からなる。本文704〜708は変更値である値704 、リンク先文書705 、スキーマＩＤ制約706、属性値制約707と、変更日時708 とを有している。所有者ＩＤの値は、値変更証明書700 が添付されていない場合には、値609 で指定された値であると解釈され、値変更証明書700 が添付された場合には、変更値704 と、変更日時708 の組である。
【００２８】
この例では、更に、変更値属性にリンク先文書ＩＤ 705を指定することにより値変更証明書700 の変更値属性に対して、スキーマＩＤと属性値による制約706, 707付の不完全リンクを形成している。従って、もう１つの値変更証明書を値変更証明書700 の変更値属性に対して添付する（即ち、リンク先文書ＩＤ 708で指定されたリンク先にもう１つの値変更証明書を設ける）ことにより更なる変更が可能になる。
【００２９】
この例では、スキーマＩＤ制約611，706として添付される署名付文書のスキーマＩＤの値を指定し、添付される署名付文書のスキーマを限定している。また、属性値制約612，707として発行者ＩＤの値を指定し、添付される署名付文書の発行者ＩＤを限定し、変更権限の無い人が変更することを防止している。
文書ＩＤ602，702は既に述べたようにあらゆる署名付文書間でユニークになるように付与する。このような識別子を生成する方法としては、例えば、The Open Groupで仕様が出版されているDCE RPC (Distributed Computing Environment Remote Procedure Call)のUUID(Universally Unique Identifier)の生成方法などが利用できる。一つの署名付ハイパーテキストを構成する複数の署名付文書をネットワーク上に分散させて配置させる場合には、文書ＩＤ602、702としてはWorld Wide Web consortium (W3C) において仕様化しているUniversal Resource Identifier (URI) 等をユニークな識別子として利用することもできる。
【００３０】
リンク先文書ＩＤ610（図４Ｂでは404）は、リンク先文書が未だ生成されていない不完全リンクの場合であっても予め生成され、リンク元の署名付文書600 に格納され署名613 される（図３の署名205 ）。そして、リンク先の文書700 （図４Ｂの410 ）を生成する時には、この値610 （404 ）が文書ＩＤ 702（412 ）として格納され署名される709（415）。これにより、他の目的で作成した署名付文書をリンク先文書700 として置き換えると、リンク元の署名付文書600 のリンク先文書ＩＤ 610とリンク先の署名付文書700 の文書ＩＤ 702の値が一致しないため、不正な置き換えを検出することができる。値変更証明書700 をリンクもとの署名付文書とした場合のリンク先文書ＩＤ 705についても同様に、そのリンク先文書が将来作成作成される可能性がある場合に予め作成しておく。
【００３１】
図８及び図９は、それぞれ航空券６００、値変更証明書７００のスキーマ定義の例である。スキーマ定義は、各署名付文書の構造、即ち、持つべき属性の種類と、スキーマによって固定される属性値と、固定されない属性に対する必須・オプションの区別が指定される。
航空券スキーマ800 は図５で説明したようにメタスキーマＩＤ 801、スキーマ定義者ＩＤ 802、スキーマＩＤ 803、発行者ＩＤ 804、本文805〜810、スキーマ定義者署名811 から構成されている。各属性に対する必須・オプションの区別としては、この実施例では、次の４種類を指定できる。
【００３２】
#ExactlyOne ：１個の値が設定されなければならない。
#ZeroOrOne  ：０個あるいは１個の値が設定されなければならない。
#OneOrMore  ：１個あるいは複数個の値が設定されなければならない。
#ZeroOrMore ：０個あるいは複数個の値が設定されなければならない。
【００３３】
メタスキーマＩＤ801，901は、スキーマ定義の構造に対する識別子であり、システム定義の固定値として#System が格納されている。
値変更証明書スキーマ定義900 は使用頻度が高いことが想定されるため、この実施例ではシステムによって提供し、そのスキーマＩＤとして特別な値＃SysValueが与えられている。ただし、このスキーマを航空券スキーマ定義800 と同様に一般のスキーマ定義者によって定義することも可能である。図８に示す航空券スキーマ800 の例では、本文において権利種別805 に固定値として航空券が格納され、出発日806 、便名807 、出発地808 、到着地809 、所有者ＩＤ 810にはそれぞれ格納されるべき属性値の数が規定されている。図９に示す値変更証明書スキーマ900 の例では、本文において変更値905 、変更日時906 にそれぞれ格納されるべき属性値の数が規定されている。
【００３４】
以下、図１０を参照して署名付ハイパーテキストの正当性の検証処理を詳細に説明する。署名付ハイパーテキストの検証は、他の署名付文書からのリンクが無い署名付文書（ルート署名付文書）を指定し、リンクを辿りながら関連する全ての署名文書を検証することによって行う。例えば、図２に示す署名付ハイパーテキスト250 では、署名付文書200 がルート署名付文書にあたる。
【００３５】
図１０の処理において、入力として検証対象の署名付文書200 と、その署名付文書200 が充足しなければならない属性値制約と、スキーマＩＤ制約（スキーマＩＤで指定される）が与えられると、出力として、成功（正常終了）、あるいは、失敗（例外終了）が返される手続きである。検査対象の署名付文書がルートである場合には、ルート署名付文書に対する検証のためのこの手続きの入力として与える属性値制約及びスキーマＩＤ制約は空である。
【００３６】
検証対象の署名付文書200 が与えられると、そのスキーマＩＤ 201を取出す（ステップ1001）。署名付文書にこのスキーマＩＤ属性が存在しない場合には、本手続きの入力として与えられるスキーマＩＤを用いる。もし、両方指定されているときは、これらの値が一致しているかを検査し、一致していない場合は例外イベントを発生させる。もし、両方指定されていない場合には、文書の形式に対する制約条件は無いものとする。このスキーマＩＤを元にスキーマを取得する（ステップ1002）。スキーマＩＤを取得する方法としては、ＨＴＴＰプロトコル等を用いてネットワークからダウンロードする方法、あるいは予めローカルシステムにキャッシュしておく方法、あるいは署名付文書が流通あるいは回覧してきた場合には、その送信者から直接受取る等の方法がある。
【００３７】
署名付文書200 の発行者ＩＤ及び本文中の各属性定義部に対して、以下に記載するようにステップ1003〜1018の処理を適用する。
署名付文書に未検証の属性定義部があるかチェックする（ステップ1003）。
未検証の属性定義部が存在する場合はステップ1004に移り、その属性定義部を取り出す。未検証の属性定義部が存在しない場合はステップ1016に移動する。ステップ1016の処理については後で述べる。
【００３８】
属性定義部が図４Ａで示す属性名302 と属性値303 の組で表される場合（リンク無し）はステップ1011、図４Ｂで示す属性名402 、属性値403 、リンク先文書ＩＤ 404、制約条件定義部405 の組で表される場合（リンクあり）はステップ1006に移動する（ステップ1005）。ステップ1011の処理については後で述べる。
リンクがあった場合、リンク先文書ＩＤ 404を取得する（ステップ1006）。
【００３９】
リンク先文書ＩＤ 404で指定されたリンク先に署名付文書が存在しなかった場合（不完全リンクの場合）は、ステップ1011、存在する場合（完全リンクの場合）は、ステップ1008に移動する（ステップ1007）。
リンク先に文書があった場合、そのリンク先の署名付文書410 を取得し、リンク元のリンク先文書ＩＤ 404がリンク先の署名付文書410 の文書ＩＤ 412と一致するかどうか検証する。また、リンク先文書410 に対するハッシュ値制約406 が与えられている場合は、リンク先の署名付文書410 からハッシュ値を計算し、一致するかどうか検証する（ステップ1008）。
【００４０】
これらの検証により、検証に失敗した場合は例外イベントを発生し（ステップ1015）、成功した場合は、ステップ1010に移動する（ステップ1009）。
リンク先の署名付文書410 を検証する。ステップ1010は図１０の処理自身であり再帰的にこの処理の流れを適用する。このとき、リンク先の文書に対する制約条件として、スキーマ制約が指定されている場合には、この手続きの入力として指定されたスキーマＩＤを与える。また、属性値制約が指定されている場合には、この手続きの入力としてこの属性値制約を与える（ステップ1010）。
【００４１】
ステップ1005においてリンクが存在しない場合、あるいは、ステップ1007においてリンクはあるが、リンク先に署名付文書が存在しなかった場合は、その属性の値303又は403に対してスキーマとの整合性を検証する。例えば、ステップ1002で取得したスキーマ定義にその属性に対する具体的な値が定義されている場合には、その値と一致しているかどうか調べる。スキーマ定義に具体的な値は定義されていないが、前述の＃ExactlyOne、＃ZeroOrOne、＃OneOrMore、＃ZeroOrMoreの制約が指定されている場合には、その制約が充足するかどうか検証する。もし、これらの検証に失敗した場合は、例外イベントを発生（ステップ1013）し、成功した場合は、ステップ1012に移動する（ステップ1011）。
【００４２】
リンク元の署名付文書に制約条件として属性値制約が指定されている場合には、その制約を充足するかどうか検証する。もし、この検証に失敗した場合は、例外イベントを発生（ステップ1014）し、成功した場合は、ステップ1003に移動する（ステップ1012）。
ステップ1003において検証すべき属性定義部が無い場合、即ち、全ての属性定義部206〜206（図３）について検証が終了した場合には、発行者署名の検証を行う（ステップ1016）。
【００４３】
検証に失敗した場合は、例外イベントを発生（ステップ1018）し、成功した場合には、正常に終了する（ステップ1017）。
このように、この発明においては、
(1) 一つの文書を、リンクを持つ複数の文書から構成される署名付ハイパーテキストとして表し、前記ハイパーテキストを構成する各文書が、その文書の識別子と、その文書の発行者の識別子と、その文書の本文と、リンク先文書の識別子と、リンク先文書に対する制約条件と、その文書全体に対する発行者署名から構成した。これにより、署名付文書の属性に対する変更履歴がその属性に付与されたリンクを辿ることによって獲得できるので、ある属性の最終的な値を得るために、他の属性に付与された変更履歴を解析する必要がなくなり処理が単純化できる。
【００４４】
(2) また、この発明では、上記構成の署名付ハイパーテキスト記録媒体において、リンク先文書に対する制約条件として、リンク先文書が従うべきリンク先文書のスキーマを指定できるようにした。これにより、リンク先に添付される署名付文書の形式を限定することが可能になる。
(3) また、この発明では、上記構成の署名付ハイパーテキスト記録媒体において、リンク先文書に対する制約条件として、リンク先文書の特定の属性の値を指定できるようにした。これにより、リンク先に添付される署名付文書の特定の属性の値を限定することが可能になる。これにより、例えば、発行者ＩＤ属性203 の値を指定することにより、リンク先の文書の発行者を限定することが可能になる。また、他の例としては、図１１の表1100に署名付文書の種類と、その添付対象の属性と、添付文書に対する制約条件の例を示すように、署名付文書の処理に伴って、所有者(1101)、予約状態(1102)、支払状態(1003)、決済状態(1004)等の属性の値が変化し得る電子チケットや契約書の状態推移を自在に制御することが可能になる。尚、契約書やスタンプラリーの台紙に対する押印1105、1106は、署名付文書の添付として実現できる。
【００４５】
(4) また、この発明では、上記構成の署名付ハイパーテキスト記録媒体において、リンク先文書に対する制約条件として、リンク先文書のハッシュ値を指定できるようにした。これにより、リンク先文書の改竄あるいは置き換えを防止できるので、例えば、図１１に示すコンサートチケット1107の約款のように長い文書については、流通対象の電子チケットに直接記述せずに、ネットワーク上に署名付文書として公開し、電子チケット自体には、そのリンク先文書ＩＤのみを記載し流通させることが可能になり、効率的かつ安全な取引が可能になる。
【００４６】
(5) 更に、この発明では、リンク元の文書を定義する時にリンク先の文書が具体化していない場合に上記構成の署名付ハイパーテキストを構成する装置として、具体化していない文書に対するユニークな文書識別子を生成する手段と、前記識別子を将来のリンク先文書の識別子としてリンク元文書に格納し、リンク元の文書を生成する手段と、リンク先の文書が具体化したときに、前記リンク先文書の識別子を前記具体化した文書の識別子として前記具体化した文書を生成する手段により、リンク先文書を添付することによって、動的に署名付ハイパーテキストを構成するようにした。これにより、他の目的で作られた署名付文書を別の目的の署名付文書のリンク先文書として置き換えると、リンク元の署名付文書のリンク先文書ＩＤとリンク先の署名付文書の文書ＩＤの値が一致しないため、不正な置き換えの検出が可能になる。
【００４７】
(6) また、この発明では、上記構成の署名付ハイパーテキストを検証するための方法として、リンク先の文書の識別子がリンク元の文書に定義されたリンク先文書の識別子と一致するかどうかを検証する手段と、リンク先の文書がリンク元の文書に定義された制約条件に合っているかどうかを検証する手段と、前記ハイパーテキストを構成する各文書の発行者の署名を検証する手段とを備えることを特徴とした。これにより、図１１に示すように、予約の取れていないオープン航空券1102、未払い状態の予約券1103、決済者印の無い決済文書1104、印紙が貼られていない契約書1105、スタンプがすべてに押されていないスタンプラリー台紙1106、等を機械的なフローにより検出することが可能になる。
【００４８】
上述においてハイパーテキスト構成装置、ハイパーテキスト検証装置はコンピュータによりプログラムを読出して解読実行することにより処理を行わせることもできる。
図１２は上述したこの発明のハイパーテキストが作成され、使用されるシステムの例を示す。この例ではネットワーク１０に利用者端末装置２１、２２、スキーマ定義配布サーバ４１、４２及び文書サーバ３１、３２が接続されている。スキーマ定義配布サーバ４１、４２内のスキーマ定義蓄積部４１Ｍ、４２Ｍには電子チケット、電子証明書などのスキーマがそれらのＩＤと対応して設けられている。
【００４９】
文書サーバ３１はコンピュータで構成され、その機能構成として図１３Ａに示すようにハイパーテキスト構成部３１Ａ、ハイパーテキスト配布部３１Ｂ、これらに接続された文書蓄積部３１Ｍ、ハイパーテキスト配布３１Ｂをネットワーク１０に接続するネットワーク接続部３１Ｃとを有している。文書サーバ３２も同様の構成である。ハイパーテキスト構成部３１Ａにより前述のようにして作成された例えば署名付証明書が文書蓄積部３１ＭにＩＤに対応して格納され、その証明書のリンク先文書がハイパーテキスト配布部３１Ｂにより、例えば図１２の文書サーバ３２に送信され、その文書蓄積部３２Ｍに格納されている。
【００５０】
利用者端末装置２１はコンピュータで構成され、その機能構成として図１３Ｂに示すように、例えばハイパーテキスト取得部２１Ａ、ハイパーテキスト検証部２１Ｂネットワーク接続部２１Ｃ、ハイパーテキスト表示部２１Ｄを有している。利用者端末装置２２も同様に構成される。利用者はハイパーテキスト取得部２１Ａにより例えば端末装置２１から例えば航空券を得ると、それをハイパーテキスト表示部２１Ｄに表示し、ハイパーテキスト検証部２１Ｂによりプログラムとして格納されている例えば図１０の検証処理手順に従って検証する。その検証において、航空券に例えば所有者の変更が記録された文書ＩＤがリンク先文書として記録されている場合には、そのリンク先文書のＩＤにより例えば文書サーバ３１からリンク先文書を取得し、そのリンク先文書の検証を行い、正当であればリンク先文書に記載されている所有者の変更は正規のものであると判定する。
【００５１】
上述の使用例は、この発明を実施する例の本の一部であり、これ以外にも多様な使用形態があることは明らかである。
【００５２】
【発明の効果】
以上説明したように、この発明によれば、ある特定の属性の最終的な値を獲得するには、変更された属性に付与されたリンクを辿るだけで済む。また、リンク先の文書に対する多様な制約条件、文書の識別子、スキーマ、属性値、ハッシュ値等により定義することにより、変更権限のない者による不正な変更、あるいは他の目的で作成した文書をリンク先の文書として不正に置かれた場合に、それを機械的な手順により検出することが可能になる。これにより、文書中の特定の属性に対する変更権限を制御すること、及び、流通あるいは回覧の過程で添付される文書の形式を限定すること等が可能になる。
【図面の簡単な説明】
【図１】従来方法における署名付文書の変更方法の実現例を示す図。
【図２】署名付ハイパーテキストの全体構成図。
【図３】署名付ハイパーテキストの構成要素である署名付文書のデータ構造図。
【図４】Ａはリンクを持たない属性定義部のデータ構造図、Ｂはリンクを持つ属性定義部のデータ構造、リンク先の署名付文書との制約条件による依存関係を示す図である。
【図５】署名付文書に対するスキーマ定義のデータ構造図。
【図６】署名付文書によって表現された航空券の一定義例であって、所有者ＩＤ属性に対して不完全リンクが定義されている場合の図。
【図７】署名付文書によって表現された値変更証明書の一定義例であって、図６中の所有者ＩＤ属性に付与されているリンクに添付されているものを示す図。
【図８】図６に示した航空券のスキーマ定義の一例を示す図。
【図９】図７に示した値変更証明書のスキーマ定義の一例を示す図。
【図１０】署名付ハイパーテキストの正当性の検証方法の一実現方法を示すフローチャート。
【図１１】署名付文書とその添付対象の属性と、添付する署名は文書の制約条件との関係の各種例を示す図。
【図１２】この発明によるハイパーテキストが作成され、使用されるシステムの例を示す図。
【図１３】Ａは図１２における文書サーバの構成例を示す図、Ｂは図１２における利用者端末装置の構成例を示す図である。
【図１】
0003825586.tif 000002
【図２】
0003825586.tif 000003
【図３】
0003825586.tif 000004
【図４】
0003825586.tif 000005
【図５】
0003825586.tif 000006
【図６】
0003825586.tif 000007
【図７】
0003825586.tif 000008
【図８】
0003825586.tif 000009
【図９】
0003825586.tif 000010
【図１０】
0003825586.tif 000011
【図１１】
0003825586.tif 000012
【図１２】
0003825586.tif 000013
【図１３】
0003825586.tif 000014