JP2000123095A

JP2000123095A - 電子チケット記録媒体、処理方法及び処理装置

Info

Publication number: JP2000123095A
Application number: JP22741699A
Authority: JP
Inventors: Takashi Fujimura; 考藤村
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 1998-08-12
Filing date: 1999-08-11
Publication date: 2000-04-28

Abstract

(57)【要約】【課題】多種多様な電子チケットを汎用的に定義可能
とし、かつ安全に発行、譲渡、消費可能とする。【解決手段】電子チケットにチケットＩＤ 233、発行
機関ＩＤ 237、チケットの権利情報239 、所有者ＩＤ23
4と共に発行条件240 、譲渡条件241 、消費条件242が設
けられており、これら全体に対する発行機関署名235が
付けられている。発行条件、譲渡条件、消費条件のそれ
ぞれには、チケットの送信機関及び受信機関がそれぞれ
所有していなければならないチケットの種類を指定する
チケットスキーマＩＤが記録されており、発行、譲渡、
消費の各段階でこれらの条件が充足しているか検証され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、二重使用や不正
使用を防止することが要求されるデジタル情報よりなる
電子チケットを安全に流通させる方法及び装置に関する
ものであり、特に、応用によって発行条件や譲渡条件等
の様々な流通条件が与えられる電子チケットを汎用的な
処理装置によって流通させるための方法に関するもので
ある。

【０００２】

【従来の技術】現在、既にソフトウェア、画像、ニュー
ス等に関しては、インターネット等の電子的な通信手段
を用いて流通しているが、これらに限らずデジタル情報
として表すことができる商品は電子的に流通させること
が可能である。特にサービス産業等では、以下のような
様々なチケットが商品として流通しているが、これらは
電子的に流通させることが可能な商品である。

【０００３】(1) 予約券コンサートチケット、電車指定券、航空券、ホテル予約
券、テニスコート予約券 (2) 引換券船荷証券、質札、預かり証、不動産権利書 (3) 整理券バーゲン品整理券、銀行窓口整理券、診療整理券 (4) 商品券商品券、ビール券、図書券、米券、レストランクーポン
券 (5) プリペイドカードテレホンカード、Ｕカード、イオカード、ハイウェイカ
ード (6) ライセンス証自動車免許証、パスポート、入館証チケットとは、ここでは発行者がチケット所有者に対し
て負うサービスや物を請求する債権を表章したものと定
義する。このようなチケットは、債権の内容をデジタル
情報として表現し、それに対して発行者がデジタル署名
を添付することにより、電子的に表現できる。

【０００４】チケットを電子化することは、紙の発行や
郵送に伴うコストを削減することができるというメリッ
トがある。また、チケットの販売場所や販売時間等の制
約が減りいつでもどこからでもチケットを入手し、利用
することが可能になる。また、遠隔に離れた友人や知人
に対してネットワークを介して譲渡することが可能にな
る等利便性が向上する。これらの理由から、近年、これ
らのチケットを電子化しようという動きが活発になって
きている。

【０００５】コンサートやスポーツ観戦等の興行チケッ
トに関しては、例えば、e-ticket(http://www.e-ticke
t.net/)のように、既にインターネットを介して電子チ
ケットを販売している業者が存在している。また、引換
券についても米国 Gold & Silver Reserve,Inc. のe-go
ld(http://www.e-gold.com）のように金の引換券を販売
している業者が存在している。また、商品券やプリペイ
ドカードの電子化については、例えば、Glassman,M.Man
asse,M.Abadi,P.Gauthier,P.Sobalvarro著“TheMillice
nt Protocol for Inexpensive Electronic Commerce”
（Proceedings of4th World Wide Web Conference）に
記述されているプリペイドクーポンモデルに基づくマイ
クロペイメント方式や、R.Rivest and Adi Shamir 著、
“Pay Wordand MicroMint：Two simple micropayment s
chemes.”（Technical report,MIT,Cambridge,1996)に
記述されているような電子回数券の実現方法等が提案さ
れている。

【０００６】チケットの場合は、通常の画像やサウンド
等のデジタルコンテンツとは異なり、二重使用等の不正
使用を防止することが必要であるが、これらを防止する
ための技術についても近年急速に発展している。上記の
参考文献においてもいくつかの方式が提案されている
が、電子現金技術に関する参考文献、例えば、Peter Wa
yner著、“Digital Cash”（Academic Press Ltd. ISBN
0-12-788772-5）では、電子現金のような有価情報を安
全に譲渡、取引するための方法がまとめられている。ま
た、米国特許No.5,621,797及び米国特許No.5,557,518で
は、乗車券、興行チケット、通信サービスアクセス券、
ライセンス証等の電子チケットについて焦点を当て、電
子チケットを安全に行使及び譲渡するための方法が提案
されている。また、日本国特許出願公開11-31204には偽
造、複製が困難でチケットの内容を第三者に証明可能な
電子チケットシステムが提案されている。

【０００７】しかしながら、これらの従来の方法は、電
子チケットの不正を防ぐための方法を提案するものであ
って、多種多様な電子チケットを汎用的に定義する方
法、及び多種多様な電子チケットを発行、譲渡、消費す
るための汎用的な処理装置を提案するものではない。例
えば、以下のような様々な流通条件を制御できる汎用的
な電子チケット流通制御方法及びその装置については未
だ検討されていない。

【０００８】(1) 特定の許可を受けた業者しか発行でき
ないようにする。例、宝くじ券や馬券等 (2) 特定の証明を受けた利用者に対してしか発行（販
売）できないようにする。例、学割定期券（学生証を持
っている人に対してのみ発行可） (3) 特定の証明を受けた業者・利用者以外は譲渡（販
売）できないようにする。例、航空券（旅行代理店のみ
譲渡可） (4) 特定の証明を受けた利用者以外は消費できないよう
にする。例、高速券（通行券が必要） (5) 特定の証明を受けた業者以外は改札できないように
する。例、ビール券、図書券

【０００９】

【発明が解決しようとする課題】このように従来におい
ては、いくつかの電子チケット処理方法及び装置が提案
されてきたが、応用毎に専用のシステムが提案されてき
た。このためにそれぞれのチケット毎に個別のチケット
情報読み取りソフトウェアや取引システム等を開発する
ことが必要であり、開発コストが高くなるという問題が
あった。そこで、多様な電子チケットを汎用的に処理で
きる方法が望まれていたが、電子チケットの種類や性質
は多種多様であるため、汎用的なチケット処理装置を作
ることは困難であった。

【００１０】この発明の目的は、上記のような従来の課
題を解決し、多種多様な性質を持つ電子チケットを汎用
的に定義可能とする電子チケットと、多種多様な流通条
件を持つ電子チケットを安全に発行、譲渡、消費できる
汎用的な電子チケット処理方法及び処理装置を提供する
ことにある。

【００１１】

【課題を解決するための手段】この発明によれば、電子
チケットの発行、譲渡、消費などのチケットの移動の各
段階において、電子チケットの受信側機関及び／又は送
信側機関に要求され、流通を制御するチケットを指定す
る機関条件定義部が電子チケットに設けられ、これによ
り電子チケットに対し、関連するチケットが複合した多
様な形態の電子チケットを流通可能にする。この電子チ
ケットには、発行機関の識別子と、前記電子チケットの
権利情報とが設けられ、また前記電子チケットの発行条
件、譲渡条件及び消費条件の少なくとも１つを定義する
機関条件が上記機関条件定義部に設けられ、更に、所有
者の識別子と、発行機関の署名が設けられることにより
電子チケットをより一般化し易くしている。

【００１２】また、電子チケットの情報構造を規定する
チケットスキーマに、電子チケットを適用する応用毎に
異なる多様な権利情報の属性の種類と意味を定義する権
利情報構造定義を設け、更に上記電子チケットの発行条
件、譲渡条件及び消費条件の少なくとも１つを定義でき
るようにする。また、上記構成の電子チケットに、上記
構成のチケットスキーマの識別子を定義するスキーマ識
別子を定義できるようにする。

【００１３】また、上記構成の電子チケットにおいて、
電子チケットを譲受けあるいは改札する際に、流通して
きた電子チケットが正しい取引を経て届いたものである
ことを検証できるように、発行条件、譲渡条件及び消費
条件の少なくとも１つに対し、それを充足したことを証
明する条件充足証明記録部が設けられる。上記電子チケ
ットの発行装置は、チケットスキーマの定義に従って電
子チケットの属性値を記録する手段と、条件記録部に記
録された発行条件を検証する手段と、電子チケットを送
信する手段を備える。

【００１４】また、上記電子チケットの譲渡装置は、電
子チケットの譲渡条件を充足しているかどうか検証する
手段と、充足している場合に譲渡証明を譲渡証明記録部
に記録する手段と、前記電子チケットを譲渡先に送信す
る手段を備える。また、上記電子チケットの譲受装置
は、電子チケットの発行条件充足証明が、発行条件記録
部に記録されている発行条件を充足していることを検証
する手段と、譲渡証明の正当性を検証する手段と、譲渡
条件充足証明が譲渡条件記録部に記録された譲渡条件を
充足していることを検証する手段を備える。

【００１５】また、上記電子チケットの消費装置は、上
記記載の電子チケット定義方法によって定義される電子
チケットの消費条件定義部に記録されている消費条件を
充足しているかどうか検証する手段と、充足している場
合に消費証明を消費証明記録部に記録する手段と、消費
条件充足証明を消費条件充足証明記録部に記録する手段
と、前記電子チケットをサービス機関に送信する手段を
備える。

【００１６】また、上記電子チケットの改札装置は、条
件記録部に記録された消費条件を充足していることを検
証する手段と、検証に成功した場合に上記電子チケット
を蓄積する手段を備える。

【００１７】

【発明の実施の形態】前述のような様々なチケットの発
行、譲渡、使用（消費又は改札）はチケットに伴う権利
の流通と考えることができる。権利の流通は、これら発
行、譲渡、改札の３つの基本トランザクションから構成
される。つまり、電子チケットは発行機関により生成さ
れ、直接又はネットワークを経由して、利用者に対し転
送される（発行）。ここで、利用者は消費者であっても
よいし、販売店であってもよいし、企業であってもよ
い。発行された電子チケットは、利用者間を転々流通し
（譲渡）、最後にサービス提供機関にて、サービスと引
き替えに消費される（改札）。このとき、チケットによ
っては、利用可能回数が減少、あるいは無効化される。

【００１８】様々な種類のチケットを流通制御するパラ
メータとしては、利用回数、有効期間、複製可否、譲渡
可否、流通範囲などがある。流通範囲は電子チケットの
送信側に要求される条件と受信側に要求される条件によ
って制限される。例えば、旅行会社がクラブの会員を募
集し、会員に対し、会員に対し特定の旅行クーポン（チ
ケット）を発行する場合、チケット送信側には旅行会社
の営業許可証を有していることが条件として要求され、
チケット受信側は、そのクラブの会員であることを示す
会員証を有していることが要求される。旅行会社の営業
許可証はその会社の有している権利であるといえ、クラ
ブの会員証は会員の権利であるといえる。即ち、チケッ
トの流通はこの様な権利保持者間での権利の移動と考え
ることができる。この発明では、この様な点に着目し、
送信側要求条件、受信側要求条件をチケットの発行、譲
渡、消費の各段階毎にそのチケット自身に記述すること
により流通を制御する。この発明では、会員証や営業許
可証自体もこの発明による電子チケットの形での流通可
能な権利として扱うことにより、多種多様なチケットを
共通な処理手順で安全に扱うことを可能にしている。

【００１９】以下、この発明の実施例を、図面を参照し
て詳細に説明する。図１は、この発明の一実施例を示す
電子チケット（以下、単にチケットと呼ぶ）の発行、譲
渡、消費に係わるそれぞれの装置を関連づけて示すシス
テム全体のブロック構成図である。図１に示すように、
電子チケットは発行機関装置108 の発行装置102 により
発行され、利用者装置109 の譲受装置103 によって受け
取られる。このチケットの移動において、まず、発行装
置102 は利用者１装置109 が適正であるか検証し、適正
であれば電子チケットを利用者装置の譲受装置103 に転
送し、譲受装置103は受けた電子チケットが適正である
か検証し、適正であれば利用者１装置109 の蓄積装置10
9Sに蓄積する。利用者１装置109 から利用者ｎ装置110
にチケットが譲渡される場合も同様に、譲渡装置104 は
利用者ｎ装置110 が適正であるか検証し、適正であれば
チケットを譲受装置105 に転送し、利用者ｎ装置110 の
譲受装置105 は電子チケットが適正であるか検証し、適
正であれば蓄積装置110Sに蓄積する。

【００２０】利用者ｎ装置110 の消費装置106 によって
電子チケットを消費し、サービス機関装置111 の改札装
置107 によって改札する場合は、利用者ｎ装置110 から
電子チケットをサービス期間装置111 に転送する場合も
同様に、消費装置106 はサービス機関装置111 が適正で
あるか検証し、適正であればチケットをサービス機関装
置の改札装置107 に転送し、改札装置107 は電子チケッ
トが適正であるか検証し、適正であれば蓄積装置111Sに
蓄積する。なお、電子チケットのこれらの移動（譲渡）
が行われない場合や、必要に応じて利用者装置間で移動
が複数回繰り返される場合もある。

【００２１】図２Ａ，２Ｂは、図１に示した発行機関装
置、利用者装置、サービス機関装置の間で流通するチケ
ット230 のデータ構造（図２Ａ）と、そのチケットの構
造を定義するチケットスキーマ210 のデータ構造（図２
Ｂ）を示す。まず、この発明による電子チケットの特徴
の概略を述べる。図２Ａに示す電子チケット230 は、そ
のチケットの発行機関を表す発行機関ＩＤ 237，そのチ
ケットの権利情報（権利の種類、有効期間など）239 、
発行条件240 、譲渡条件241、消費条件242 が含まれて
いる。発行条件240 、譲渡条件241 、消費条件242 はそ
れぞれ発行段階、譲渡段階、消費段階におけるチケット
の送信側に要求される条件（資格）とチケットを受信す
る側に要求される条件（資格）を規定する。このような
チケットの書式により、多種多様なチケットを汎用的に
流通可能な電子チケットとして構成できる。また、図２
Ａ，２Ｂの実施例では、図２Ａのチケットの書式はスキ
ーマＩＤ 231で指定される図２Ｂに示すスキーマ210 に
より定義されており、その書式に従ってチケットが構成
される。このようなチケットスキーマをチケットの権利
種別毎に予め用意し、例えばネットワーク上のサーバに
より公開し、誰もが自由にアクセスできるようにする。
あるいは、権利種別に対応するスキーマのテーブルを予
め利用者に配布してもよい。

【００２２】以下に、この発明の実施例を具体的に説明
する。図２Ａに示すように、一つのチケット230 は、ス
キーマＩＤ 231、チケットＩＤ 232、チケットインスタ
ンス233 、所有者ＩＤ 234、発行機関署名235 、及び流
通証明236 から構成される。スキーマＩＤ 231は、チケ
ット230 の構造や持つべき属性の種類を指定するチケッ
トスキーマ210 （図２Ｂ）に対する識別子である。チケ
ットスキーマ210 の詳細は後で述べる。

【００２３】チケットＩＤ 232は、チケット230 に対す
る識別子であり、あらゆるチケットの間でユニークにな
るように付与する。チケットインスタンス233 は、発行
機関ＩＤ 237、権利種別238 、権利情報239 、発行条件
240 、譲渡条件241 、消費条件242 から構成される。発
行機関ＩＤ237は、チケットを発行する人あるいは組織
の識別子である。権利種別238 は、航空券、商品券、宝
くじ券、興行チケット等のチケットの種別を表わす識別
子である。権利情報239 は、航空券の場合には、出発
日、便名等、興行チケットの場合には、開催時刻、開催
場所等のチケット依存の詳細な権利情報が定義される。
発行条件240 、譲渡条件241 、消費条件242 については
後で述べる。

【００２４】所有者ＩＤ 234は、そのチケットを所有す
る人あるいは組織の識別子である。発行機関署名235
は、前記のスキーマＩＤ 231、チケットＩＤ 232、チケ
ットインスタンス233 、所有者ＩＤ 234の結合に対する
発行機関の署名である。署名方法としては、例えば、RS
A Data Security 社のＲＳＡ方式や日本電信電話のＥＳ
ＩＧＮ等の電子署名方式が利用できる。具体的には、発
行機関は公開鍵暗号における秘密鍵と公開鍵を生成し、
秘密鍵により情報231〜234に対する署名235 を生成し、
公開鍵は、たとえばチケット230 に公開鍵証明書と共に
添付して配布する（図示せず）。ただし、公開鍵を発行
機関ＩＤ 237として使用し、電子チケット230に記載し
ておけば、公開鍵及びその証明書を添付で配布する必要
はない。

【００２５】流通証明236 の詳細については後で述べ
る。チケットスキーマ210 は、チケット230 の構造や持
つべき属性の種類を指定する情報であり、発行機関、あ
るいはサービス機関、あるいは業界団体等のスキーマ定
義機関によって自由に定義することができる。また、チ
ケットスキーマ210は、図１４に示すように、スキーマ
サーバ1401等を用いてネットワーク1407を介して誰でも
自由に取得できるようにする。ただし、図１５に示すよ
うに、予め発行機関装置1506、利用者装置1505，1504、
サービス機関装置1503等に配布しておくこともできる。
この場合には、チケットスキーマ獲得のためにネットワ
ーク1507に常時接続しておく必要はない。従って、チケ
ットの授受についてもＩＣカード等を介して行う場合に
は、オフラインで処理することができる。

【００２６】チケットスキーマ210 は、図２Ｂに示すよ
うにメタスキーマＩＤ 211、スキーマ定義機関ＩＤ 21
2、スキーマＩＤ 213、チケットスケルトン214 、スキ
ーマ定義機関署名215 から構成される。スキーマ定義機
関署名215 もチケットの発行機関署名の場合と同様に、
スキーマ定義機関は秘密鍵と公開鍵を生成し、秘密鍵に
より情報211〜214に対し署名215 を生成し、公開鍵及び
鍵証明書を例えばスキーマに添付して配布する（図示せ
ず）。ただし、公開鍵をスキーマＩＤ 213として使用
し、チケットスキーマ210に記載しておけば、公開鍵及
びその証明書を添付で配布する必要はない。

【００２７】メタスキーマＩＤ 211は、チケットスキー
マの構造に対する識別子であり、将来、チケットスキー
マの構造を変更した場合に、新旧のチケットスキーマを
区別可能にし、移行を容易にするためのものである。ス
キーマ定義機関ＩＤ 212は、チケットスキーマを定義す
る人あるいは組織の識別子である。スキーマＩＤ 213
は、スキーマ210 自身の識別子である。これをチケット
スキーマに含めてスキーマ定義機関によって署名するこ
とにより例えば、図１５に示すようにチケットスキーマ
210 がローカルな記憶媒体（スキーマキャッシャＳＣ
Ｈ）にキャッシュされている場合、あるいは取引相手か
ら直接渡された場合であってもそのスキーマＩＤに対す
る正当なチケットスキーマであることを検証できる。チ
ケットスキーマ210 は、既に述べたように図１４のスキ
ーマサーバ1401等により、公開する必要があるが、この
方法については、例えば、World Wide WebConsortium
(Ｗ３Ｃ）において仕様化しているUniversal Resource
Identifier（ＵＲＩ）等によってスキーマＩＤとして指
定し、IETFにおいて仕様化しているHTTPプロトコル等に
より、ネットワーク上に置かれたチケットスキーマを獲
得する等の方法がある。

【００２８】チケットスケルトン214 は、チケットイン
スタンス233 と同様に、発行機関ＩＤ216 、権利種別21
7 、権利情報構造定義218 、発行条件219 、譲渡条件22
0 、消費条件221 から構成される。発行機関ＩＤ 216
は、チケットの発行機関ＩＤ 237と同様にチケットを発
行する人あるいは組織の識別子である。ただし、チケッ
トの発行機関ＩＤ 237とは違って必ずしも値が指定され
ている必要はない。権利種別217 は、チケットの権利種
別238 と同じ値が定義される。権利情報構造定義218
は、チケットの権利情報239 で定義するべき属性の種類
が定義される。例えば、航空券の場合には、出発日、便
名等、興行チケットの場合には、開催時刻、開催場所等
のチケット依存の詳細な属性である。また、権利情報構
造定義218 には、これらの属性に対する具体的な値を指
定することもできる。この場合には、このチケットスキ
ーマを指定したチケットには、その具体的な属性値以外
を定義することはできない。

【００２９】発行条件219 は、チケットを発行する側に
要求される条件とチケットを受け取る側に要求される条
件がある。発行する側の条件としては、宝くじ券や馬券
等のように特定の認可を受けた業者（認定書を持ってい
る業者）しか発行できない等の発行条件がある。また、
チケットを受け取る側の条件としては、学割定期券のよ
うに学生（学生証を持っている人）に対してのみ発行で
きる等の条件がある。このような発行条件を定義するた
め、この発明では、図３Ａに示すように送信機関要求チ
ケットスキーマＩＤ 251と受信機関要求チケットスキー
マＩＤ 252により発行条件を定義する。送信機関要求チ
ケットスキーマＩＤ 251は、例えば、上記の例では、宝
くじ発行許可の認定書のスキーマＩＤがこれにあたる。
受信機関要求チケットスキーマＩＤ 252は、例えば、上
記の例では、学生証のスキーマＩＤがこれにあたる。

【００３０】譲渡条件220 は、そのチケットの譲渡が許
されているかどうかという譲渡可否条件と、譲渡できる
場合には、チケットを譲渡する側に要求される条件と、
チケットを譲受する側に要求される条件がある。チケッ
トを譲渡する側の条件としては、航空券のように、特定
の認可を受けた利用者（旅行代理店証を持つ業者）のみ
譲渡あるいは販売できる等がある。チケットを譲受する
側の条件としては、発行条件と同様に、学割定期券のよ
うに学生（学生証を持っている人）に対してのみ譲渡で
きる等の条件がある。このような譲渡条件を定義するた
め、この発明では、図３Ｂに示すように譲渡可否261 と
送信機関要求チケットスキーマＩＤ 262と受信機関要求
チケットスキーマＩＤ 263により譲渡条件を定義する。
送信機関要求チケットスキーマＩＤ 262は、例えば、上
記の例では、旅行代理店の認定書のスキーマ識別子がこ
れにあたる。受信機関要求チケットスキーマＩＤ 263
は、例えば、上記の例では、学生証のスキーマＩＤがこ
れにあたる。

【００３１】消費条件221 は、チケット自身の条件と、
チケットを消費する側の条件と、チケットを改札する側
の条件がある。チケット自身の条件として、この発明で
は、図３Ｃに示すようにそのチケットの有効期限271
と、有効回数272 と、順序性273 によりチケット自身の
条件を指定する。有効期限271 はそのチケットが有効に
なる開始日時と無効になる終了日時等から構成される。
有効回数272 は、そのチケットが何回使用できるかを指
定するものであり、大別すると定期券やパスポートのよ
うに使用回数が無制限のものと、テレホンカードや回数
券のように指定回数あるいは指定度数（いずれも金額に
対応）に達するまで有効なものと、乗車券やコンサート
チケットのように一回限り有効なもの３種類に分類でき
る。順序性273 は、サービスを受ける順番を指定するも
のであり、銀行や病院の順番待ち整理券のように指定さ
れた番号の順に消費されなければならない場合に指定さ
れる。

【００３２】チケットを消費する側の条件としては、会
員割引利用券のように、特定の会員（会員証を持つ人）
のみ消費できる等がある。チケットを改札する側の条件
としては、特定のサービス提供者（改札証を持っている
人）のみ改札できる等の条件がある。このような消費条
件を定義するため、この発明では、送信機関要求チケッ
トスキーマＩＤ 274と受信機関要求チケットスキーマＩ
Ｄ 275により消費条件を定義する。送信機関要求チケッ
トスキーマＩＤ 274は、例えば、上記の例では、会員券
のスキーマＩＤがこれにあたる。受信機関要求チケット
スキーマＩＤ 275は、例えば、上記の例では、改札証の
スキーマＩＤがこれにあたる。

【００３３】図２Ｂにおいて発行条件219 、譲渡条件22
0 、消費条件221 としては、上で述べたように各種証明
書を所有しているとする以外にも例えば、発行機関の規
模や資本金に関する条件や、チケットの譲受機関の年齢
や身長等の条件等、多様なものが考えられる。この実施
例では、これらの条件の指定方法についての詳細は述べ
ないが、この発明で述べたチケットスキーマＩＤによる
各種証明書の指定に加えて、上記に述べたような特定の
属性とその値を指定すること等により実現することがで
きる。

【００３４】チケット側に定義される発行条件240 、譲
渡条件241 、消費条件242 の構造は、上記で述べたチケ
ットスキーマ側に定義される発行条件219 、譲渡条件22
0 、消費条件230 と同じ構造を持つ。また、チケットが
参照するチケットスキーマで定義されている発行条件21
9 、譲渡条件220 、消費条件221 の内容は、チケット側
で定義されている発行条件240 、譲渡条件241 、消費条
件242 でもすべて同じく定義される。但し、チケットス
キーマ側で追加定義が許されている場合には、チケット
側には、別の条件を追加することができる。これによ
り、例えば、行政機関あるいは業界団体がチケットスキ
ーマを規定し、各企業からそのチケットスキーマに従う
チケットを発行する場合、チケットスキーマで定義され
た発行、譲渡、消費条件よりも厳しい条件で流通制御す
ることができるが、一方、緩い条件で流通させることを
禁止すること等が可能になる。別の実施例としては、チ
ケット側に定義される発行条件240 、譲渡条件241 、消
費条件242 を省略し、チケット230 に定義されたチケッ
トスキーマＩＤ 231からチケットスキーマ210 を取得
し、チケットスキーマ側に定義される発行条件219 、譲
渡条件220 、消費条件221 をチケットの流通条件として
使うこともできる。ただし、この場合にはチケット毎に
条件を追加定義することはできない。

【００３５】また、別の実施例として譲渡をサポートし
ないチケット処理システムでは、譲渡条件260 （図３
Ｂ）は省略することができる。また、発行機関が固定の
チケット処理システムでは、発行条件250 （図３Ａ）の
送信機関条件251 をチケット230 自身に記述しなくても
チケット処理システム側で保持することにより、この情
報は省略することができる。同様に、サービス機関が固
定のチケット処理システムでは、消費条件270 （図３
Ｃ）の受信機関条件275 は省略することができる。

【００３６】更に別の実施例として、利用者の資格条件
が固定のチケット処理システムの場合、即ち、例えばそ
のチケット処理システムの利用者が特定の会員に加入し
ていることが前提の場合には、チケット230 自身に記述
しなくてもチケット処理システム側で保持することによ
り、発行条件250 の受信機関条件である要求スキーマＩ
Ｄ 252、及び譲渡条件260 の送信機関条件である要求ス
キーマＩＤ 262及び受信機関条件である要求スキーマＩ
Ｄ 263、及び消費条件270 の送信機関条件である要求ス
キーマＩＤ 274は省略することができる。

【００３７】また、別の実施例として、利用者の資格条
件がチケット毎に異なるが、上記の発行条件250 の受信
機関要求スキーマＩＤ 252、及び譲渡条件260 の送信機
関要求スキーマＩＤ 262及び受信機関条件263 、及び消
費条件270 の送信機関要求スキーマＩＤ 274を共通の条
件（利用者条件）としてよい場合には、発行条件250、
譲渡条件260 、消費条件270 の代わりに、発行機関条
件、利用者条件、サービス機関条件の３種類の条件とし
て定義することもできる。この場合は、発行機関条件に
よって指定された内容を発行条件250 の送信機関条件25
1 とし、利用者条件によって指定された内容を発行条件
250 の受信機関条件252 、及び譲渡条件260 の送信機関
条件262 及び受信機関条件263 、及び消費条件270 の送
信機関条件274 とし、サービス機関条件によって指定さ
れた内容を消費条件270 の受信機関条件275 とすること
で、以下で詳細を述べる実施例と同様の方法で実施でき
る。なお、この場合には、特定の利用者（例えば代理店
証を持っている人）だけには譲渡が可能で、一般の利用
者は、譲渡を禁止するといった制御ができないという違
いがある。以上のように、チケット処理システムの前提
条件によっては、これらの全ての条件をチケットあるい
はチケットスキーマにおいて定義する必要はない。

【００３８】流通証明236 は、図２Ａに示すようにその
チケットの流通過程を記録する部分であり、チケットを
発行する際に、発行条件240 を充足していることを証明
する発行条件充足証明243 、譲渡する際に、誰が誰に対
して譲渡したかを証明する譲渡証明244，246、譲渡条件
241 を充足したことを証明する譲渡条件充足証明245，2
47 、消費する際に利用者が消費したことを証明する消
費証明248 、消費条件242 を充足したことを証明する消
費条件充足証明249 から構成される。発行条件充足証明
243 、譲渡条件充足証明245, 247、消費条件充足証明24
9 は、具体的には、発行許可証、学生証、代理店証、改
札券証等のチケットである。

【００３９】別の実施例としては、流通過程を記録する
流通証明236 をチケット230 に保持する代わりに、流通
過程の利用者がそれぞれのログとしてこれらの情報を記
録しておき、二重使用などの不正使用が発覚した場合に
そのログを調査機関に提示するという方法もある。ある
いはこれらの流通情報を一括してサーバに記録しておい
てもよい。また、更に別の実施例としては、このログさ
えも記録しないという方法もある。この場合には、後で
二重使用などの不正使用が発覚したとしても、犯人を追
跡することは困難であるが、低価格のチケットを扱う場
合や、電子チケット処理装置のプログラムが耐タンパ装
置内に格納され、改変が困難な場合には、実用上問題な
い場合がある。

【００４０】図４〜図１３は、上記で示したチケット及
びチケットスキーマの具体例である。以下これらの具体
例を示しながら、発行条件や消費条件の制御方法につい
ての詳細を述べる。尚、図４〜図１３において斜線が引
かれている属性については、その属性は定義されていな
いことを意味する。また、チケットスキーマにおいて
“＊”マークが指定されている項目は、任意の値が指定
できることを意味する。

【００４１】公開鍵証明書から公開鍵の値を取得できる
ので、発行機関ＩＤ 216、237 、所有者ＩＤ 234、スキ
ーマ定義機関ＩＤ 212などの識別子としてそれぞれの機
関が生成した公開鍵そのものではなく、公開鍵証明書の
識別子あるいは公開鍵証明書のハッシュ値あるいは公開
鍵のハッシュ値を用いることができる。その場合は公開
鍵と公開鍵証明書を配布する必要がある。ただし、公開
鍵証明書についても発行、譲渡、消費の際に必要なチケ
ットとして送信機関要求チケットスキーマＩＤ及び受信
機関要求チケットスキーマＩＤに指定することも可能で
あり、署名検証の際にその鍵情報を利用するように実現
することもできる。この実施例では、公開鍵の配布を省
き処理を簡略化するため、発行機関ＩＤ 216、237 、所
有者ＩＤ234、スキーマ定義機関ＩＤ 212等の識別子と
してそれぞれの機関が生成した公開鍵を利用することに
する。

【００４２】図１２は宝くじ券の定義例を示す。それぞ
れの属性配置1201〜1205, 1217〜1219は図２Ａのは図２
Ａ，３Ａ，３Ｂ，３Ｃに示した属性配置と同様であり、
宝くじ券としてのそれらの属性に対する値の例を示して
いる。個々の属性値の説明は省略する。また、図１３に
示す宝くじ券スキーマの構造も図２Ｂに示すものと同様
である。宝くじは誰でも自由に発行できるわけではな
く、政府が発行した発行許可証を持つ機関のみが発行で
きるように制限する必要がある。そこで、この発明では
図３Ｄに示す権利種別301, 302, 303 毎にスキーマ定義
の発行が許されるスキーマ定義機関ＩＤを指定するテー
ブル300 を広く公開する。このテーブル300 に対してチ
ケット処理システムが保持する秘密鍵等により署名（30
4 ）し、改竄されることを防止する。これにより、ある
チケットが、このテーブル300 に掲載されている権利種
別のチケットであるにも関わらず、そのチケットから参
照されるチケットスキーマが、このテーブル300 に掲載
されていない団体あるいは企業により定義されていれ
ば、信用できないチケットであることが検出することが
可能になる。

【００４３】別の実施例としては、図３Ｄの代わりに、
図３Ｅに示すように、権利種別311,312, 313 毎にチケ
ットスキーマＩＤを定義したスキーマＩＤテーブル310
を広く公開するという方法がある。この方法では、ある
チケットがこのテーブル310に掲載されている権利種別
のチケットであるにも関わらず、そのチケットのチケッ
トスキーマＩＤが、このテーブル310 に掲載されていな
い場合には、信用のできないチケットであると判定する
ことが可能になる。ただし、この場合は、チケットスキ
ーマＩＤとチケットスキーマとの関係の一意性を保証す
る必要があるが、これには例えば、スキーマＩＤとして
チケットスキーマのハッシュ値などを用いる方法などが
ある。また、この実施例の場合においても、スキーマＩ
Ｄテーブルの改竄を防止するため、チケット処理システ
ムが保持する秘密鍵などによりテーブル310 に対し署名
314 を生成する。

【００４４】スキーマ定義機関テーブルあるいはスキー
マＩＤテーブル310 の公開方法としては、本実施例で
は、ネットワークに接続されたスキーマサーバ1401（図
１４）を用いてHTTPプロトコルなどにより配布する。た
だし、これ以外にも、電子メール、衛星放送、あるいは
書店で販売されるCD-ROMを用いて配布するなどの多様な
方法がある。なお、改竄される危険性がない配送手段を
用いる場合には、スキーマ定義機関テーブル300 の署名
304 、スキーマＩＤテーブル310 の署名314 は省略でき
る。

【００４５】例えば、図１３に示す宝くじ券のチケット
スキーマにおける権利種別1305として“宝くじ券”が指
定されている場合、図３Ｄのテーブルを用いてその権利
種別に対応するスキーマ定義機関のリストが得られる。
この中に、図１３のスキーマ定義機関ＩＤ1302が含まれ
ていれば、正当で信用できるチケットスキーマであるこ
とが分かる。

【００４６】図１３に示す宝くじのチケットスキーマで
は、発行条件の送信機関要求チケットスキーマＩＤ1307
として、図５に示す宝くじ発行機関認定書スキーマ500
のスキーマＩＤ 503が指定され、受信機関要求チケット
スキーマＩＤ1308として、図７に示す利用者登録証スキ
ーマ700 のスキーマＩＤ７０３が指定されている。これ
により宝くじ券の発行機関が宝くじ発行機関認定書400
（図４）を持つ必要があること、そして宝くじの受け取
り機関が図６に示す利用者登録証600 を持つ必要がある
ことを定義している。また同様に、消費条件の送信機関
要求チケットスキーマＩＤ1316に指定されている消費機
関が図６に示す利用者登録証600 を持つ必要があるこ
と、受信機関要求チケットスキーマＩＤ1317に指定され
ている換金所側が換金所証明（図示せず）を持つ必要が
あることを定義している。譲渡に関しては、宝くじ券ス
キーマ3100は譲渡可否属性1309として不可を指定し譲渡
を禁止している。換金所証明の例については省略する。

【００４７】図４は宝くじ発行機関認定書400 の例であ
り、図５に示す同スキーマ500 のインスタンスである。
図６は利用者登録証600 の例であり、図７に示す同スキ
ーマ700 のインスタンスである。これらのチケットの場
合には発行、譲渡、消費の際にさらに必要となるチケッ
トは指定されていないが、これらのチケットスキーマ50
0, 700のチケットスケルトンに指定された発行機関ＩＤ
504, 704 が、発行機関ＩＤ 403, 603 として指定され
ており、この発行機関以外はこれらの証明書を発行する
ことを不可能にしている。

【００４８】図１４は上述のこの発明による電子チケッ
トがネットワークを経由して移動する場合のシステム概
念図を示す。ネットワーク1407にはスキーマサーバ140
1，発行機関装置1406、利用者１装置1405，利用者２装
置1404，サービス機関装置1403，二重使用チェックサー
バ1402が接続されている。発行機関装置1406は発行しよ
うとするチケットの権利種別に対応するスキーマとその
ＩＤをスキーマサーバ1401から得て電子チケットを作成
し、ネットワーク1407を経由して利用者１装置1405に送
信する。この例では利用者１は利用者２にチケットを譲
渡し、利用者２がサービス機関装置1403に電子チケット
を送ってサービスを受ける。

【００４９】電子チケットの移動の各段階においてチケ
ットの送信側は送信すべきチケットの送信側及び受信側
に要求される条件を、送信機関要求スキーマＩＤ及び受
信機関要求スキーマＩＤに基づいてスキーマサーバ1401
から得たスキーマにより検証する。チケットの受信側は
受信チケットの検証時にチケットスキーマＩＤによりス
キーマサーバ1401からチケットスキーマを得て、スキー
マの整合性を検証し、さらに、移動段階に応じて発行条
件、または譲渡条件、または消費条件における送信機関
要求スキーマＩＤ及び受信機関要求スキーマＩＤに基づ
いてスキーマサーバから得たスキーマが条件を満たすか
検証する。

【００５０】サービス機関1403に送信された電子チケッ
トは、最終的には二重使用チェックサーバ1402に送ら
れ、不正使用の有無が検証される。図１５は電子チケッ
トがネットワーク1507を経由せず、電子チケットが書き
込まれた例えばＩＣカード（あるいは他の記録媒体）が
移動することにより、発行機関1506から利用者１装置15
05へ、あるいは利用者１装置1505から利用者２装置1504
へ、あるいは利用者２装置1504からサービス機関装置15
03へ移動する場合を示している。

【００５１】この例ではスキーマサーバ1501から装置15
02〜1506の各スキーマキャッシャSCH に予めスキーマＩ
Ｄとスキーマの表及び権利種別とスキーマＩＤの表が配
布格納されている。従って、電子チケットの移動の各段
階で検証に必要なスキーマはこのスキーマキャッシャSC
H から得ることができる。電子チケットの移動の各段階
における処理は図１５の場合と同様である。また、図１
５における電子チケットの移動の１つまたは複数の段階
は図１４の場合と動用にネットワーク1507を経由して行
ってもよい。

【００５２】図１６は、以上に示した流通制御に関わる
チケットの流れを表わすブロック図である。図１６に示
すように、宝くじにおける行政機関のように、あるチケ
ットの流通を制御しようとする機関装置を流通組織者装
置1601と呼ぶと、流通組織者装置1601がそのチケットの
流通を制御するために必要なチケットとして発行権証、
譲受権証、譲渡権証、消費権証、改札権証等を予め発行
機関装置1606、販売機関装置1605、利用者装置1604、サ
ービス機関装置1603等に配布しておき、ターゲットのチ
ケット及びそのスキーマに流通時にどの権利証を参照利
用するのかを定義することにより、非常に柔軟な流通制
御が可能になる。また、上記で述べた発行権証等の流通
制御チケット自体も以下で述べる汎用的なチケット発
行、譲渡、消費装置を用いて自己流通させることができ
るので、これらの流通制御チケットを予め配布する等の
運用も統一的に行うことが可能になる。図４、図６、図
８、図１０に示すように、認定証、登録証、証明などは
いずれも、チケットと同一のフォーマットをしており、
統一的運用流通が、汎用装置により行える。

【００５３】発行権証、譲渡権証などもチケットであ
り、これらに対してもその流通を制御する流通条件を指
定することができる。以下、この発明の構成要素である
発行装置、譲受装置、譲渡装置、消費装置、改札装置の
各処理手順を図面により説明する。図１７は発行機関装
置108 （図１）の発行装置102 におけるチケット生成と
送信を行う主処理手順である。

【００５４】ステップ1701：発行対象のチケットスキー
マ210 （図２Ｂ）を雛形としてチケットインスタンスを
生成する。そして、チケットＩＤ 232と、その他チケッ
トスキーマでは値が定義されていない属性に対する値と
を利用者からの要求等の情報に基づきチケット230 （図
２Ａ）に設定する。ステップ1702：チケットの発行条件240 をそのチケット
インスタンス233 中から取り出す。

【００５５】ステップ1703：発行条件を入力として受信
機関検証手続きを実行する。受信機関検証（受信機関が
もつべき条件の検証）手続きの詳細は図２１で述べる。ステップ1704：受信機関検証手続きが成功した場合には
ステップ1706に移動し、失敗した場合にはステップ1705
に移る。ステップ1705：例外イベントを発生し終了する。

【００５６】ステップ1706：発行条件240 を入力として
送信機関検証手続きを実行する。送信機関検証（送信機
関がもつべき条件の検証）手続きの詳細は図２２で述べ
る。ステップ1707：送信機関検証手続きが成功した場合には
ステップ1709に移動し、失敗した場合にはステップ1708
に移る。ステップ1708：例外イベントを発生して終了する。

【００５７】ステップ1709：送信機関検証（ステップ17
06）で成功すれば、この検証手続きで発行条件充足証明
243 （図２Ａ）を添付するが、この充足証明243 として
例えば図４の発行機関認定証400 が添付される。チケッ
ト230 に所有者ＩＤ 234を設定する。ステップ1710：発行機関の署名235 を作成し添付する。

【００５８】ステップ1711：チケットを送信する。ステップ1712：受信確認が到着するのを待つ。ステップ1713：受信確認が届いたら生成したチケット23
0 を削除する。図１８は例えば利用者１装置109 （図
１）の譲渡装置104 による電子チケットを譲渡する主処
理手順である。

【００５９】ステップ1801：譲渡対象のチケットを記憶
媒体から取り出す。ステップ1802：チケット230 の譲渡条件241 を取り出
す。ステップ1803：譲渡可否261 （図３Ｂ）を検証する。ステップ1804：譲渡可の場合はステップ1806に移動し、
譲渡不可の場合にはステップ1805に移る。

【００６０】ステップ1805：例外イベントを発生して終
了する。ステップ1806：譲渡条件241 を入力として受信機関検証
手続きを実行する。受信機関検証手続きの詳細は図２１
で述べる。ステップ1807：受信機関検証手続きが成功した場合には
ステップ1809に移動し、失敗した場合にはステップ1808
に移る。

【００６１】ステップ1808：例外イベントを発生して終
了する。ステップ1809：譲渡条件を入力として送信機関検証手続
きを実行する。送信機関検証手続きの詳細は図２２で述
べる。ステップ1810：送信機関検証手続きが成功した場合には
ステップ1812に移動し、失敗した場合にはステップ1811
に移る。

【００６２】ステップ1811：例外イベントを発生して終
了する。ステップ1812：譲渡証明書を作成し添付する。譲渡証明
書の例を1000として図１０に示す。また譲渡証明書のチ
ケットスキーマは図１１に1100として示す。譲渡証明書
のチケットスキーマは、この発明の譲渡装置の提供シス
テムによって定義され、特別のスキーマＩＤが付与され
ている（1001，1103）。また譲渡条件充足証明245 が送
信機関検証手続き1809で添付されるが、これは例えば図
６の利用者登録証600 となる。

【００６３】譲渡証明書1000（図１０）の署名1018を作
成するためには所有者の秘密鍵が必要であるので、これ
が作れるということは所有者本人しか知らない秘密鍵を
持っているということの証明となる。この発明では、こ
れが認証機能として作用している。他の目的で作られた
譲渡証明書を添付するという攻撃に対しては、この発明
では、譲渡証明書の内容として権利情報1005内にチケッ
ト固有の識別子であるチケットＩＤとその譲渡日時を持
つことで防御している。別の方法としては、譲受側で作
成した乱数値を貰いそれに対して署名するという方法も
ある。

【００６４】ステップ1813：チケットを送信する。ステップ1814：受信確認が到着するのを待つ。ステップ1815：受信確認が届いたら生成したチケットを
削除する。図１９は利用者２装置110 （図１）の消費装
置106 により電子チケットを消費する処理のメインフロ
ーである。

【００６５】ステップ1901：消費対象のチケットを記憶
媒体から取り出す。ステップ1902：チケットの消費条件242 （図２Ａ）を取
り出る。ステップ1903：有効期限、有効回数、順序性（図３Ｃ）
の検証を行うことによって消費可否を検証する。ステップ1904：消費可の場合はステップ1906に移動し、
消費不可の場合にはステップ1905に移る。

【００６６】ステップ1905：例外イベントを発生して終
了する。ステップ1906：消費条件を入力として受信機関検証手続
きを実行する。受信機関検証手続きの詳細は図２１で述
べる。ステップ1907：受信機関検証手続きが成功した場合には
ステップ1909に移動し、失敗した場合にはステップ1908
に移る。

【００６７】ステップ1908：例外イベントを発生して終
了する。ステップ1909：消費条件を入力として送信機関検証手続
きを実行する。送信機関検証手続きの詳細は図２２で述
べる。ステップ1910：送信機関検証手続きが成功した場合には
ステップ1912に移動し、失敗した場合にはステップ1911
に移る。

【００６８】ステップ1911：例外イベントを発生して終
了する。ステップ1912：消費証明書248 を作成し添付する。ただ
し、回数券の場合で、既に一部が消費されている場合に
は既に消費証明書が作成されているので、残有効回数を
更新した新しい消費証明書に更新する。ステップ1913：チケットを送信する。

【００６９】ステップ1914：受信確認が到着するのを待
つ。ステップ1915：受信確認が届いたら、消費条件と消費証
明を入力としてチケット消費手続きを実行する。消費手
続きの詳細は図２０で述べる。上記ステップ1912におい
て作成する消費証明書の例を800 として図８に示す。ま
た、その消費証明書800 のチケットスキーマ900 を図９
に示す。消費証明書800 のチケットスキーマ900 は、こ
の発明の消費装置の提供システムによって定義され、特
別のスキーマＩＤが付与されている（801，903）。残有
効回数を更新せずに何度でも繰り返し利用することを防
ぐ方法としては、利用者が内容を書き換えることができ
ないＩＣカード等の耐タンパ装置を利用する方法等が利
用できる。また、後で述べる改札装置側の二重使用チェ
ックＤＢ等を利用する方法等がある。

【００７０】消費証明書800 の署名818 を作成するため
には所有者の秘密鍵が必要であるので、これが作れると
いうことは所有者本人しか知らない秘密鍵を持っている
ということの証明となる。この発明では、これが認証機
能として作用している。他の目的で作られた消費証明書
を添付するという攻撃に対しては、この発明では、消費
証明書800 の権利情報805 の内容としてチケット固有の
識別子であるチケットＩＤとその消費日時を持つことで
防御している。別の方法としては、譲受側で作成した乱
数値を貰いそれに対して署名するという方法もある。

【００７１】図２０は利用者装置110 の消費装置106 に
よるチケット消費手続きのフローである。ステップ2001：図２Ａに示すチケット230 の消費条件24
2 に指定された有効回数272 （図３Ｃ）を取り出す。ステップ2002：定期券や入場パスのように有効回数が無
制限のチケットの場合は、チケット消費手続きは終了す
る。そうでなければステップ2003に移動する。

【００７２】ステップ2003：消費証明248 （例えば図８
に示す消費証明800 も参照）から残有効回数ｎ（805 ）
を取り出す。ステップ2004：コンサートチケットや乗車券のように一
回限り有効であるチケット、あるいは、回数券やプリペ
イドカードのように度数指定があるが、今回の消費によ
り残り度数が０となったかどうかを調べ、０の場合はス
テップ2005に移る。

【００７３】ステップ2005：チケットを削除して終了す
る。図２１は図１７のステップ1703，図１８のステップ
1806及び図１９のステップ1906における各受信機関検証
手続きのフローである。ステップ2101：発行条件250 （図３Ａ）あるいは譲渡条
件260 （図３Ｂ）あるいは消費条件270 （図３Ｃ）の受
信機関要求チケットスキーマＩＤ 252, 263 あるいは27
5 のリストから未検証の受信機関要求チケットスキーマ
ＩＤを一つ取り出す。

【００７４】ステップ2102：未検証の受信機関要求チケ
ットスキーマＩＤが存在しなけば正常終了する。存在し
た場合はステップ2103に進む。ステップ2103：受信機関要求チケットスキーマＩＤによ
って制約されるチケットを受信機関が保持しているかど
うかを調べるため、図２４に示す改札装置メインフロー
を実行する。受信機関検証手続きが実行される本来の発
行、譲渡、消費の向きとは逆の方向で改札装置メインフ
ローを適用することに注意。このため、改札装置メイン
フローの入力として与える改札チケットスキーマＩＤと
して上記ステップ2101で取り出された受信機関要求チケ
ットスキーマＩＤを与え、また、改札装置メインフロー
の入力として与える受信機関ＩＤとして受信機関検証手
続きにおける送信機関ＩＤを与える。

【００７５】ステップ2104：上記ステップ2103における
改札処理に成功した場合には、次の受信機関要求チケッ
トスキーマＩＤによる受信機関（受信機関条件）の検証
のため、再びステップ2101に移動する。失敗した場合に
はステップ2105に移る。ステップ2105：例外イベントを発生して終了する。図２
２は図１７のステップ1706，図１８のステップ1809及び
図１９のステップ1909の各送信機関検証手続きのフロー
である。

【００７６】ステップ2201：発行条件あるいは譲渡条件
あるいは消費条件の送信機関要求チケットスキーマＩＤ
251, 262 あるいは274 のリストから未検証の送信機関
要求チケットスキーマＩＤを一つ取り出す。ステップ2202：未検証の送信機関要求チケットスキーマ
ＩＤが存在しなければ正常終了する。存在した場合はス
テップ2203に進む。

【００７７】ステップ2203：送信機関要求チケットスキ
ーマＩＤによって指定されたチケットを記憶媒体から検
索し、発行条件240(250)あるいは譲渡条件241(260)ある
いは消費条件242(270)の充足証明243, 245, 247, 249と
して添付する。これらの条件充足証明書はそのチケット
の発行機関、譲渡機関、消費機関に要求される資格を表
す証明書であり、例えば発行条件に対しては発行機関認
定証を、譲渡条件、消費条件に対しては例えば利用者登
録証を添付する。

【００７８】ステップ2204：指定されたチケットの検索
に失敗した場合にはステップ2205に移る。成功した場合
には、次の送信機関要求チケットスキーマＩＤによる送
信機関（送信機関条件）の検証のため、再びステップ22
01に移動する。ステップ2205：失敗した場合、送信機関の条件を充足し
ないので、例外イベントを発生して終了する。

【００７９】図２３は利用者装置109又は110（図１）の
譲受け装置103又は105によるチケット譲受け処理のメイ
ンフローである。ステップ2301：譲渡対象のチケット230 を送信機関から
受信する。ステップ2302：チケット検証手続きを実行しチケットの
正当性を検証する。チケット検証手続きの詳細は図２５
に示す。

【００８０】ステップ2303：チケット検証手続きに成功
し場合にはステップ2305に移動し、失敗した場合にはス
テップ2304に移る。ステップ2304：例外イベントを発生して終了する。ステップ2305：受け取ったチケットを記憶媒体に蓄積す
る。ステップ2306：正常に受け取ったことを送信機関に通知
する。

【００８１】図２４はサービス機関装置111 （図１）改
札装置107 によるチケット改札処理のメインフローであ
る。ステップ2401：改札対象のチケットスキーマＩＤ 231と
受信機関ＩＤを送信機関に送信する。ステップ2402：送信機関より改札対象のチケット230 を
受信する。

【００８２】ステップ2403：チケット検証手続きを実行
しチケット230 の正当性を検証する。チケット検証手続
きの詳細は図２５に示す。ステップ2404：チケット検証手続きに成功した場合には
ステップ2406に移動し、失敗した場合にはステップ2405
に移る。ステップ2405：例外イベントを発生して終了する。

【００８３】ステップ2406：受け取ったチケットを記憶
媒体に蓄積する。ステップ2407：正常に受け取ったことを送信機関に通知
する。図２５は電子チケットの検証手続きフローを示
す。チケット検証手続きは、図１で説明した発行処理に
おける譲受装置103、譲渡処理における譲受装置105及び
消費処理における改札装置107によりそれぞれ実行され
るが、チケット移動の各段階での受け側により実行され
るチケット検証処理は、チケット発行からその段階に至
るまでの各段階でのチケット移動時に行うチケット検証
を全て実行する。即ち、利用者１装置109の譲受装置103
は図２３のステップ2302で図２５のステップ2501〜2509
を実行し、利用者ｎ装置110の譲受装置105は図２３のス
テップ2302で図２５のステップ2501〜2512を実行し、サ
ービス機関装置111の改札装置107は図２４のステップ24
03で図２５のステップ2501〜2515を実行する。

【００８４】ステップ2501：スキーマ整合性検証手続き
を実行する。スキーマ整合性検証手続きの詳細は図２６
に示す。ステップ2502：スキーマ整合性検証手続きに成功した場
合にはステップ2504に移動し、失敗した場合にはステッ
プ2503に移る。ステップ2503：例外イベントを発生して終了する。

【００８５】ステップ2504：発行機関の公開鍵を使って
発行機関の署名235 を検証する。ステップ2505：発行機関の署名検証に成功した場合には
ステップ2507に移動し、失敗した場合にはステップ2506
に移る。ステップ2506：例外イベントを発生して終了する。ステップ2507：発行条件検証手続きを実行する。発行条
件検証手続きの詳細は図２７に示す。

【００８６】ステップ2508：発行条件検証手続きに成功
した場合にはステップ2510に移動し、失敗した場合には
ステップ2509に移る。ステップ2509：例外イベントを発生して終了する。譲受
装置103が行うチケット検証処理はここまでである。ステップ2510：譲渡条件検証手続きを実行する。譲渡条
件検証手続きの詳細は図２９に示す。

【００８７】ステップ2511：譲渡条件検証手続きに成功
した場合にはステップ2513に移動し、失敗した場合には
ステップ2512に移る。ステップ2512：例外イベントを発生して終了する。譲受
装置105が行うチケット検証処理はここまでである。ステップ2513：消費条件検証手続きを実行する。消費条
件検証手続きの詳細は図３２に示す。

【００８８】ステップ2514：消費条件検証手続きに成功
した場合には正常終了する。失敗した場合にはステップ
2515に移る。ステップ2515：例外イベントを発生して終了する。改札
装置107はステップ2501からここまでのすべての検証処
理を実行する。図２６は図２５のステップ2501における
スキーマ整合性検証手続きフローである。

【００８９】ステップ2601：受け取ったチケット230 の
スキーマＩＤ 231を取り出す。ステップ2602：改札の場合には、上記ステップで取得し
たスキーマＩＤ231 と改札装置が要求したスキーマＩＤ
と一致しているか調べ、一致していればステップ2604に
移動する。一致していなければステップ2603に移る。ステップ2603：例外イベントを発生して終了する。

【００９０】ステップ2604：チケットスキーマＩＤ 231
によって指定されたチケットスキーマ210 を取得する。
この方法としては既に述べたように図１４に示すスキー
マサーバ1401からHTTPプロトコルを利用して取得する等
の方法がある。このとき、実施例によっては、チケット
スキーマ自体の信用を検証するため、既に述べた方法に
より別途取得したスキーマ定義機関テーブル300（図３
Ｄ）あるいはスキーマＩＤテーブル310 （図３Ｅ）を参
照し、取得したチケットスキーマ210 がスキーマ定義機
関テーブル300 に掲載されている機関によって定義され
ているかどうか、あるいは、取得したチケットスキーマ
210 のチケットスキーマＩＤ 213がスキーマＩＤテーブ
ル310 に掲載されているかどうかをチェックする。

【００９１】ステップ2605：チケットスキーマ210 のチ
ケットスケルトン214 とチケット230 のチケットインス
タンス233 を比較し、チケットインスタンス233 がチケ
ットスケルトン214 のインスタンスとなっていることを
検証する。具体的には、チケットスケルトン214 で具体
的な属性値が定義されている場合には、その属性値がチ
ケットインスタンス233 の属性値と一致していることを
検証する。チケットスケルトンで“＊”マークが定義さ
れている属性については、チケットインスタンスで何ら
かの値が定義されていることを検証する。

【００９２】ステップ2606：上記のインスタンス233 の
検証に成功した場合は正常終了し、失敗した場合にはス
テップ2607に移る。ステップ2607：例外イベントを発生して終了する。図２
７は図２５のステップ2507における発行条件検証手続き
フローである。ステップ2701：発行条件250 を取り出す。

【００９３】ステップ2702：発行条件が存在しなかった
場合は正常終了し、存在した場合には、ステップ2703に
移動する。ステップ2703：発行条件250 に定義されている送信機関
要求チケットスキーマＩＤ 251のリストを入力として条
件充足証明検証手続きを実行する。条件充足証明検証手
続きの詳細は図３２に示す。

【００９４】ステップ2704：条件充足証明検証手続きに
成功した場合は正常終了し、失敗した場合にはステップ
2705に移る。ステップ2705：例外イベントを発生して終了する。図２
８は図２５のステップ2510における譲渡条件検証手続き
のフローである。ステップ2801：流通証明236 の中から譲渡証明244, 246
の一つ取り出す。

【００９５】ステップ2802：譲渡証明が存在した場合に
は、ステップ2805に移動し、存在したなかった場合に
は、末尾の所有者ＩＤ 234が自分のＩＤと一致するか調
べる。ステップ2803：一致した場合は正常終了する。一致しな
い場合にはステップ2804に移る。ステップ2804：例外イベントを発生して終了する。

【００９６】ステップ2805：譲渡証明検証手続きを実行
する。譲渡証明検証手続きの詳細は図２９に示す。ステップ2806：譲渡証明検証手続きに成功した場合は、
ステップ2808に移動する。失敗した場合は、ステップ28
07に移る。ステップ2807：例外イベントを発生して終了する。

【００９７】ステップ2808：譲渡条件260 を取り出す。ステップ2809：譲渡条件が存在しなかった場合は、次の
譲渡証明書を検証するため、ステップ2801に移動し、存
在した場合には、ステップ2810に移動する。ステップ2810：譲渡条件260 に定義されている送信機関
要求チケットスキーマＩＤ 262のリストを入力として条
件充足証明検証手続きを実行する。条件充足証明検証手
続きの詳細は図３２に示す。

【００９８】ステップ2811：条件充足証明検証手続きに
成功した場合には、次の譲渡証明書を検証するため、再
びステップ2801に移動する。失敗した場合にはステップ
2812に移る。ステップ2812：送信機関の条件を充足しないので、例外
イベントを発生し終了する。

【００９９】図２９は図２８のステップ2805における譲
渡証明検証手続きのフローである。ステップ2901：一つ前の譲渡証明書（例えば244 ）によ
って指定された所有者ＩＤ、あるいは以前に譲渡されて
いないチケットの場合は、そのチケットの所有者ＩＤが
譲渡証明書の発行機関ＩＤと一致するかどうかを調べる
ことにより、譲渡連続性を検証する。

【０１００】ステップ2902：譲渡連続性検証に成功した
場合には、ステップ2904に移動する。失敗した場合には
ステップ2903に移る。ステップ2903：例外イベントを発生して終了する。ステップ2904：譲渡証明書を入力としてチケット検証手
続きを実行する。チケット検証手続きの詳細は図２５に
示したものと同じである。

【０１０１】ステップ2905：チケット検証手続きに成功
した場合には、正常に終了する。失敗した場合にはステ
ップ2906に移る。ステップ2906：例外イベントを発生して終了する。図３
０は図２５のステップ2513における消費条件検証手続き
のフローである。ステップ3001：流通証明236 の中から消費証明248 を取
出す。

【０１０２】ステップ3002：消費証明が存在した場合に
は、ステップ3004に移動し、存在しなかった場合にはス
テップ3003に移る。ステップ3003：例外イベントを発生して終了する。すてっぷ3004：消費証明検証手続きを実行する。消費証
明検証手続きの詳細は図３１に示す。

【０１０３】ステップ3005：消費証明検証手続きに成功
した場合は、ステップ3007に移動し、失敗した場合には
ステップ3006に移る。ステップ3006：例外イベントを発生して終了する。ステップ3007：消費条件270 を取り出す。ステップ3008：消費条件が存在しなかった場合はステッ
プ3012に移動し、存在した場合には、ステップ3009に移
動する。ステップ3009：消費条件270 に定義されている送信機関
要求チケットスキーマＩＤ 274のリストを入力として条
件充足証明検証手続きを実行する。条件充足証明検証手
続きの詳細は図３２に示す。

【０１０４】ステップ3010：条件充足証明検証に成功し
た場合はステップ3012に移動し、失敗した場合にはステ
ップ3011に移る。ステップ3011：例外イベントを発生して終了する。ステップ3012：二重使用チェック手続きを実行する。二
重使用チェック手続きの詳細は、図３３に示す。

【０１０５】ステップ3013：二重使用チェック手続きに
成功した場合は正常に終了し、失敗した場合にはステッ
プ3014に移る。ステップ3014：例外イベントを発生して終了する。図３
１は図３０のステップ3004における消費証明検証手続き
のフローである。ステップ3101：最終的な譲渡証明書246 （図２Ａ、具体
例として図１０）によって指定された所有者ＩＤ 1017
あるいは以前に譲渡されていないチケットの場合は、そ
のチケットの所有者ＩＤが消費証明書の発行機関ＩＤと
一致するかどうかを調べることにより、消費連続性を検
証する。

【０１０６】ステップ3102：消費連続性検証に成功した
場合には、ステップ3104に移動する。失敗した場合には
ステップ3103に移る。ステップ3103：例外イベントを発生して終了する。ステップ3104：消費証明書を入力としてチケット検証手
続きを実行する。チケット検証手続きの詳細は図２５に
示した。

【０１０７】ステップ3105：チケット検証手続きに成功
した場合には、正常に終了する。失敗した場合にはステ
ップ3106に移る。ステップ3106：例外イベントを発生して終了する。図３
２は図２７のステップ2703，図２８のステップ2810及び
図３０のステップ3009における条件充足証明検証手続き
のフローを示す。

【０１０８】ステップ3201：送信機関要求チケットスキ
ーマＩＤのリストから未検証の送信機関要求チケットス
キーマＩＤを一つ取り出す。ステップ3202：未検証の送信機関要求チケットスキーマ
ＩＤが存在しなければ正常終了する。存在した場合はス
テップ3203に進む。ステップ3203：送信機関要求チケットスキーマＩＤによ
って指定された条件充足証明を取り出す。

【０１０９】ステップ3204：指定された条件充足証明が
存在した場合には、ステップ3206に移動する。存在しな
かった場合にはステップ3205に移る。ステップ3205：送信機関の条件を充足しないので、例外
イベントを発生して終了する。ステップ3206：条件充足証明に対するチケット検証手続
きを実行し条件充足証明の正当性を検証する。チケット
検証手続きの詳細は図２５に示した。

【０１１０】ステップ3207：チケット検証手続きに成功
した場合には、次の送信機関要求チケットスキーマＩＤ
による送信機関の条件を検証するため、再びステップ32
01に移動する。失敗した場合にはステップ3208に移る。ステップ3208：送信機関の条件を充足しないので、例外
イベントを発生して終了する。

【０１１１】図３３は図３０のステップ3012における二
重使用チェック手続きのフローである。ステップ3301：消費条件270 の有効回数272 を取り出
す。ステップ3302：定期券や入場パスのように有効回数272
が無制限のチケットの場合は、チケット消費手続きは終
了する。そうでなければステップ3303に移動する。

【０１１２】ステップ3303：二重使用チェックＤＢに対
してチケットＩＤを入力として検索し、既に使用された
チケットであるかどうかをチェックする。二重使用チェ
ックＤＢは、有効期限内にあって既に使用済みとなった
チケットのチケットＩＤを蓄積している。回数券のよう
に使用回数があるものについては、残使用回数管理を管
理し使用済のチケットを不正に再利用することを検出す
る。

【０１１３】この実施例ではオンラインで二重使用チェ
ックを行う方法について述べたが、ＩＣカード等の耐タ
ンパ装置を利用し、不正利用が未然に防止できる場合に
ついては、この処理を省略あるいは安全性を高めるため
の補助手段としてオフラインで事後チェックすることも
できる。この処理を省略した場合には、チケットＩＤ23
2は不要なので省略することもできる。

【０１１４】また、二重使用チェックは、各種チケット
毎に個別のサーバを利用することもできるし、図１６に
示す二重使用チェック機関装置1602のような汎用的なサ
ービスを利用することもできる。ステップ3304：上記二重使用チェックにより、不正が検
出されなかった場合には、ステップ3306に移動する。不
正が検出された場合にはステップ3305に移る。

【０１１５】ステップ3305：例外イベントを発生して終
了する。ステップ3306：コンサートチケットや乗車券のように一
回限り有効であるチケット、あるいは、回数券やプリペ
イドカードのように回数指定があるが残り度数が１であ
るかどうかを調べる。ステップ3307：残り度数が２以上の場合は、残有効回数
272 を１減らし、ステップ3309に移る。

【０１１６】ステップ3308：残り度数が１の場合は、チ
ケットの状態を使用済とし、ステップ3309に移る。ステップ3309：二重使用チェックＤＢを更新し、終了す
る。次に、この発明による電子チケットを実施する図１
に示したシステムにおける発行装置102 、譲受装置10
3、 105、譲渡装置104 、消費装置106 、改札装置107の
機能構成を示す。

【０１１７】図３４に示す発行装置102 は、属性生成部
1021と、検証部1022と、記録部1023と、送信部1024とを
含み、検証部1022は更に送信機関チケット所有検証部10
22Aと受信機関チケット所有検証部1023B とを含む。属
性生成部1021は入力された情報に基づいて電子チケット
の発行機関識別子、チケットの権利情報、発行条件、所
有者識別子、等の属性値を図２Ａで示した電子書式で記
録媒体に書き込むことにより電子チケットを作成する。
電子チケットを書き込むべき対象としての記録媒体は外
部から装着した記録媒体であっても、装置内の記録媒体
であってもよい。

【０１１８】受信機関チケット所有検証部1022A は、電
子チケットに記録された発行条件に指定された、送信先
である受信機関が所有していなければならないチケット
を受信機関が所有しているか検証する。送信機関チケッ
ト所有検証部1022B は、電子チケットに記録された発行
条件に指定された、送信機関が所有していなければなら
ないチケットを送信機関が所有しているか検証する。

【０１１９】記録部1023は、検証部1022により電子チケ
ットが発行条件を充足した場合に、発行条件充足証明を
電子チケットに記録する。この電子チケットは送信部10
24から受信機関に送信される。図３５に示す譲渡装置10
4 は、蓄積部109Sと、検証部1041と、記録部1042と、送
信部1043とを含み、検証部1041は受信機関チケット所有
検証部1041A と、送信機関チケット所有検証部1041B と
を含む。なお、図１に示したように蓄積部109Sは譲受装
置103と共用されている。

【０１２０】蓄積部109Sから読出された電子チケットは
検証部1041に与えられる。受信機関チケット所有検証部
1041A は、電子チケットに記録された譲渡条件に指定さ
れた、受信機関が所有していなければならないチケット
を受信機関が所有しているか検証する。送信機関チケッ
ト所有検証部1041B は、電子チケットに記録された譲渡
条件に指定された、送信機関が所有していなければなら
ないチケットを送信機関が所有しているか検証する。

【０１２１】記録部1042は、検証部1041により電子チケ
ットが譲渡条件を充足した場合に、譲渡証明と譲渡条件
充足証明を電子チケットに記録する。この電子チケット
は送信部1043から受信機関に送信される。図３６に示す
譲受装置は、図１に示したように発行機関装置102から
電子チケットを譲受する場合の譲受装置103 と、譲渡装
置104 から電子チケットを譲受する場合の譲受装置105
のいずれにも適用される。譲受装置103 は、受信部1031
と、検証部1032と、蓄積部109Sとを含み、検証部1032は
送信機関チケット所有検証部1032Aと、受信機関チケッ
ト所有検証部1032Bと、チケット検証部1032C と、スキ
ーマ検証部1032D とを含む。

【０１２２】受信部1031で受信された電子チケットに対
し検証部1032で次の検証が行われる。送信機関チケット
所有検証部1032A は、電子チケットに記録された発行条
件（譲渡装置105 の場合は譲渡条件）に指定された、送
信機関が所有していなければならないチケットを送信機
関が所有しているか検証する。受信機関チケット所有検
証部1032B は、電子チケットに記録された発行条件に指
定された、受信機関が所有していなければならないチケ
ットを受信機関が所有しているか検証する。

【０１２３】チケット検証部1032C は、電子チケットの
送信機関が電子チケットに記録した発行条件充足証明
（譲渡装置105 の場合は譲渡証明と譲渡条件充足証明）
と発行機関署名とを検証する。スキーマ検証部1032D
は、この電子チケットのスキーマ定義機関識別子が電子
チケットの権利種別毎にスキーマ定義機関識別子が記載
されているスキーマ定義機関テーブルに記録されている
ことを確認する。あるいはこの電子チケットのスキーマ
が、電子チケットの権利種別毎にチケットスキーマ識別
子が記載されたスキーマ識別子テーブルに記録されてい
ることを確認してもよい。

【０１２４】検証部1032によるこれらの検証に成功する
と、電子チケットは他機関に譲渡されるまで蓄積部109S
に蓄積される。図３７に示す消費装置106 の機能構成を
示し、蓄積部110Sと、検証部1061と、記録部1062と、送
信部1063とを含み、検証部1061は受信機関チケット所有
検証部1061A と、送信機関チケット所有検証部1061B と
を含む。蓄積部110Sは図１において譲受装置105と共用
している。

【０１２５】蓄積部110Sから読出された電子チケットは
検証部1061に与えられる。受信機関チケット所有検証部
1061A は、電子チケットに記録された消費条件に指定さ
れた、受信機関が所有していなければならないチケット
を受信機関が所有しているか検証する。送信機関チケッ
ト所有検証部1061B は、電子チケットに記録された消費
条件に指定された、送信機関が所有していなければなら
ないチケットを送信機関が所有しているか検証する。

【０１２６】記録部1062は、検証部1061により電子チケ
ットが消費条件を充足した場合に、消費証明と消費条件
充足証明を電子チケットに記録する。この電子チケット
は送信部1063から受信機関に送信される。図３８に示す
改札装置107 は、受信部1071と、検証部1072と、蓄積部
111Sとを含み、検証部1072は送信機関チケット所有検証
部1072A と、受信機関チケット所有検証部1072B と、チ
ケット検証部1072Cと、スキーマ検証部1072Dとを含む。

【０１２７】送信機関チケット所有検証部1072A は、受
信部1071から与えられた電子チケットに記録された消費
条件に指定された、送信機関が所有していなければなら
ないチケットを送信機関が所有しているか検証する。受
信機関チケット所有検証部1072B は、電子チケットに記
録された消費条件に指定された、受信機関が所有してい
なければならないチケットを受信機関が所有しているか
検証する。

【０１２８】チケット検証部1072C は、電子チケットに
記録された発行条件充足証明、譲渡証明、譲渡条件充足
証明、消費証明、及び消費条件充足証明と発行機関署名
を検証する。スキーマ検証部1072D は、この電子チケッ
トのスキーマ定義機関識別子が電子チケットの権利種別
毎にスキーマ定義機関識別子が記載されているスキーマ
定義機関テーブルに記録されていることを確認する。あ
るいは、この電子チケットのスキーマが、電子チケット
の権利種別毎にチケットスキーマ識別子が記載されたス
キーマ識別子テーブルに記録されていることを確認して
もよい。

【０１２９】検証部1072によるこれらの検証に成功する
と、電子チケットは蓄積部111Sに蓄積される。上述した
電子チケットの発行装置、譲渡装置、譲受装置、消費装
置、改札装置における各処理は、コンピュータによりプ
ログラムを読出し、解読実行することによって行わせる
ことができる。

【０１３０】以上説明したように、この発明では、 (1) チケットを適用する応用毎に異なる多様な権利情報
を定義する権利情報239 と、チケットの発行条件240
と、譲渡条件241 と、消費条件242 をチケット230 に定
義できるようにする。 (2) また、この発明では、電子チケットを適用する応用
毎に異なる多様な権利情報の属性の種類と意味を定義す
る権利情報構造定義218 、前記電子チケットの発行条件
219 と、譲渡条件220 と、消費条件221 をチケットスキ
ーマ210 に定義できるようにする。

【０１３１】(3) また、この発明では、上記構成の電子
チケット230 に、上記構成のチケットスキーマの識別子
231 を定義できるようにする。 (4) また、この発明では、上記構成のチケット定義方法
において、チケットの発行条件、譲渡条件及び消費条件
を充足したことを証明する条件充足証明記録部243, 24
5, 247, 249を有する。この結果、チケットを譲受ある
いは改札する際に、流通してきたチケットが正しい取引
を経て届いたものであることを検証することが可能にな
る。

【０１３２】(5) この発明によるチケット発行装置102
は、チケットスキーマの定義に従って電子チケットの属
性値を記録する手段と、条件記録部に記録された発行条
件を検証する手段を備える。この結果、多様な流通条件
を持つチケットが共通の発行装置により発行可能にな
る。 (6) また、この発明によるチケット譲渡装置104 は、チ
ケットの譲渡条件を充足しているかどうか検証する手段
と、充足している場合に譲渡証明を譲渡証明記録部に記
録する手段と、前記チケットを譲渡先に送信する手段を
備える。この結果、多様な流通条件を持つチケットが共
通の譲渡装置により譲渡可能になる。

【０１３３】(7) また、この発明によるチケット譲受装
置103 、105 は、チケットの発行条件充足証明が、発行
条件記録部に記録されている発行条件を充足しているこ
とを検証する手段と、譲渡証明の正当性を検証する手段
と、譲渡条件充足証明が譲渡条件記録部に記録された譲
渡条件を充足していることを検証する手段を備える。こ
の結果、多様な流通条件を持つチケットが共通の譲受装
置により譲受可能になる。

【０１３４】(8) また、この発明によるチケット消費装
置106 は、上記記載のチケット定義方法によって定義さ
れるチケットの消費条件定義部に記録されている消費条
件を充足しているかどうか検証する手段と、充足してい
る場合に消費証明を消費証明記録部に記録する手段と、
消費条件充足証明を消費条件充足証明記録部に記録する
手段と、前記チケットをサービス機関に送信する手段を
備える。この結果、多様な流通条件を持つチケットが共
通の消費装置により消費可能になる。

【０１３５】(9) また、この発明によるチケット改札装
置107 は、消費条件記録部に記録された消費条件を充足
していることを検証する手段と、検証が成功した場合に
消費証明を消費署名記録部に記録する手段を備える。こ
の結果、多様な流通条件を持つチケットが共通の改札装
置により改札可能になる。上述では発行条件、譲渡条
件、消費条件を設けたが、これらの１つだけでもよい。

【０１３６】

【発明の効果】以上説明したように、この発明によれ
ば、電子チケットを適用する応用毎に異なる多様な権利
情報の属性の種類と意味を定義する権利情報構造定義
と、電子チケットを適用する応用毎に異なる多様な電子
チケットの発行条件と、譲渡条件と、消費条件を電子チ
ケットの構造を規定するチケットスキーマあるいは電子
チケット自体に定義されるため、これらの電子チケット
を処理する発行装置、譲受装置、譲渡装置、消費装置、
改札装置がこれらの条件を解釈しながら処理することが
でき、これにより、多種多様な流通条件を持つ多様なチ
ケットが共通の発行装置、譲受装置、譲渡装置、消費装
置、改札装置により、処理できるようになる。これによ
り、従来のように、チケット毎に個別のチケット情報読
み取りソフトウェアや取引システム等を開発することが
必要なくなり、開発コストの大幅な削減が可能になる。

【図面の簡単な説明】

【図１】この発明の一実施例を示すチケットの発行、譲
渡、消費の各装置全体のブロック構成図。

【図２】Ａは図１に示した発行機関装置、利用者装置、
サービス機関装置の間で流通するチケットのデータ構造
図、Ｂはそのチケットの構造を定義するチケットスキー
マのデータ構造図である。

【図３】Ａは発行条件の定義を示す例、Ｂは譲渡条件の
定義を示す例、Ｃは消費条件の定義を示す例、Ｄは各権
利種別に対してスキーマ定義が許されるスキーマ定義機
関を指定するスキーマ定義機関テーブル、Ｅは権利種別
に対応するスキーマＩＤの、署名されたテーブルであ
る。

【図４】宝くじ発行機関認定書の例を示す図。

【図５】宝くじ発行機関認定書スキーマの例を示す図。

【図６】利用者登録証の例を示す図。

【図７】利用者登録証スキーマの例を示す図。

【図８】消費証明書の例を示す図。

【図９】消費証明書スキーマの例を示す図。

【図１０】譲渡証明書の例を示す図。

【図１１】譲渡証明書スキーマの例を示す図。

【図１２】宝くじ券の定義例を示す図。

【図１３】宝くじ券スキーマの定義例を示す図。

【図１４】この発明の構成要素である発行機関装置、利
用者装置、サービス機関装置、スキーマ定義機関装置、
二重使用チェック機関装置がネットワークを介して接続
されている形態の一構成例を示す図。

【図１５】この発明の構成要素である発行機関装置、利
用者装置、サービス機関装置、スキーマ定義機関装置、
二重使用チェック機関装置がネットワークを介して接続
されていない形態の一構成例を示す図。

【図１６】流通制御に関わるチケットの流れを表わすブ
ロック図。

【図１７】発行装置のメインフローを示す図。

【図１８】譲渡装置のメインフローを示す図。

【図１９】消費装置のメインフローを示す図。

【図２０】チケット消費手続きのフローを示す図。

【図２１】受信機関検証手続きのフローを示す図。

【図２２】送信機関検証手続きのフローを示す図。

【図２３】譲受装置のメインフローを示す図。

【図２４】改札装置のメインフローを示す図。

【図２５】チケット検証手続きのフローを示す図。

【図２６】スキーマ整合性検証手続きのフローを示す
図。

【図２７】発行条件検証手続きのフローを示す図。

【図２８】譲渡条件検証手続きのフローを示す図。

【図２９】譲渡証明検証手続きのフローを示す図。

【図３０】消費条件検証手続きのフローを示す図。

【図３１】消費証明検証手続きのフローを示す図。

【図３２】条件充足証明検証手続きのフローを示す図。

【図３３】二重使用チェック手続きのフローを示す図。

【図３４】発行装置の機能構成ブロック図。

【図３５】譲渡装置の機能構成ブロック図。

【図３６】譲受装置の機能構成ブロック図。

【図３７】消費装置の機能構成ブロック図。

【図３８】改札装置の機能構成ブロック図。

Claims

【特許請求の範囲】

【請求項１】電子チケットが記録された記録媒体で
あって、上記電子チケットの発行機関の識別子を定義する発行機
関識別子と、上記電子チケットの権利情報を定義する権利情報と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件と、所有者の識別子を定義する所有者識別子と、発行機関の署名と、が記録されており、上記機関条件は
上記電子チケットを受信する受信機関と送信する送信機
関の少なくとも一方が所有していなければならないチケ
ットを指定している。
【請求項２】請求項１に記載の記録媒体において、
上記電子チケットの情報構造を定義した電子チケットス
キーマの識別子を定義するスキーマ識別子が記録されて
いる。
【請求項３】電子チケットが記録された記録媒体で
あって、電子チケットの発行機関の識別子を定義する発行機関識
別子と、上記電子チケットの権利情報を定義する権利情報と、上記電子チケットの情報構造を定義した電子チケットス
キーマの識別子を定義するスキーマ識別子、とが記録さ
れており、上記電子チケットスキーマは、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とを含む。
【請求項４】請求項１，２又は３の記録媒体におい
て、上記機関条件として上記送信機関及び上記受信機関
の少なくとも一方が予め所有していなければならないチ
ケットの情報構造を定義したチケットスキーマの識別子
が記録されている。
【請求項５】請求項１、２、３又は４に記載の記録
媒体において、上記指定された条件を充足したことを証
明する条件充足証明記録がなされている。
【請求項６】電子チケットの情報構造を定義した電
子チケットスキーマが記録された記録媒体であって、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項７】電子チケットの発行機関の識別子を記
録する発行機関識別子記録部と、上記電子チケットの権
利情報を記録する権利情報記録部と、上記電子チケット
の発行条件を記録する条件記録部と、所有者の識別子を
記録する所有者識別子記録部と、上記発行機関の署名を
記録する署名記録部とを有し、上記条件記録部は上記電
子チケットを受信する受信機関が所有していなければな
らないチケットを発行条件として指定する機関条件定義
部を有している電子チケットを発行する発行装置であっ
て、上記電子チケットの上記発行機関識別子記録部、上記権
利情報記録部、上記条件記録部、上記所有者識別子記録
部、上記署名記録部にそれぞれ上記発行機関識別子、権
利情報、発行条件、所有者識別子、発行機関署名を記録
する手段と、上記機関条件定義部に指定されたチケットを上記受信機
関が所有しているか否かを検証する手段と、上記検証手段による検証が満たされた場合、上記電子チ
ケットを上記受信機関に送信する手段、とを含む。
【請求項８】請求項７の発行装置において、上記電
子チケットの上記機関条件定義部には上記電子チケット
の受信機関が所有していなければならないチケットのス
キーマを指定するスキーマ識別子が上記発行条件として
記録されている。
【請求項９】請求項７の発行装置において、上記条
件記録部の上記機関条件定義部は、上記電子チケットを
送信する送信機関が所有していなければならないチケッ
トのスキーマを指定するスキーマ識別子を上記発行条件
として更に含んでおり、上記検証する手段は上記機関条
件定義部のスキーマ識別子により指定されたスキーマの
上記チケットが存在しているかを検証する手段を含む。
【請求項１０】請求項９の発行装置において、上記
電子チケットは上記発行条件の充足を証明する発行条件
充足証明を記録するための発行条件充足証明記録部を含
み、上記発行装置は更に上記検証に成功した場合に、発
行条件充足証明を上記発行条件充足証明記録部に記録す
る手段を含む。
【請求項１１】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの譲渡条件を記録する譲渡条件記録部と、所有者の識
別子を記録する所有者識別子記録部と、上記発行機関の
署名を記録する署名記録部とを有し、上記譲渡条件記録
部は、上記電子チケットを受信する受信機関が所有して
いなければならないチケットを上記譲渡条件として指定
する機関条件定義部を有する電子チケットの譲渡装置で
あって、上記機関条件定義部に指定された上記受信機関が所有し
ていなければならないチケットを所有しているか否かを
検証する手段と、上記検証手段による検証が満たされた場合、上記電子チ
ケットを上記受信機関に送信する手段、とを含む。
【請求項１２】請求項１１の譲渡装置において、上
記機関条件定義部は上記受信機関が所有していなければ
ならないチケットのスキーマを指定するスキーマ識別子
を上記譲渡条件として含む。
【請求項１３】請求項１１の譲渡装置において、上
記機関条件定義部は、上記電子チケットを送信する送信
機関が所有していなければならないチケットのスキーマ
を指定するスキーマ識別子を上記譲渡条件として含んで
おり、上記検証する手段は上記機関条件定義部のスキー
マ識別子により指定されたスキーマの、上記送信機関が
所有していなければならない上記チケットが存在してい
るかを検証する手段を含む。
【請求項１４】請求項１３の譲渡装置において、上
記電子チケットは上記譲渡条件の充足を証明する譲渡条
件充足証明を記録するするための譲渡条件充足証明記録
部を含み、上記譲渡装置は更に上記検証に成功した場合に譲渡条件
充足証明を上記譲渡条件充足証明記録部に記録する手段
を含む。
【請求項１５】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を指定する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを送信する送信機関が所有していなければ
ならないチケットを上記移動条件として指定する機関条
件定義部を有する電子チケットの譲受装置であって、上記機関条件定義部に指定された上記送信機関が所有し
ていなければならないチケットを所有しているかどうか
を検証する手段と、電子チケットを蓄積するための蓄積装置と、上記検証が満たされた場合、上記電子チケットを上記蓄
積装置に蓄積する手段、とを含む。
【請求項１６】請求項１５の譲受装置において、上
記電子チケットの上記機関条件定義部には上記移動条件
として、上記電子チケットの発行機関が所有していなけ
ればならないチケットのスキーマを指定するスキーマ識
別子が記録されている。
【請求項１７】請求項１６の譲受装置において、上
記電子チケットは上記移動条件の充足を証明する条件充
足証明を記録する条件充足証明記録部を含み、上記検証
する手段は、上記条件充足証明記録部に記録されている
上記条件充足証明を検証する手段を含む。
【請求項１８】請求項１７の譲受装置において、上
記移動条件は上記電子チケットの発行における発行条件
であり、上記条件充足証明記録部は上記発行条件の充足
証明を記録する発行条件充足証明記録部を含み、上記条
件充足証明検証手段は、上記発行条件として記録された
上記スキーマ識別子により指定されたスキーマのチケッ
トが存在するかを検証し、かつ上記発行条件充足証明が
上記発行条件充足証明記録部に記録されているかを検証
する手段を含む。
【請求項１９】請求項１７の譲受装置において、上
記移動条件は上記電子チケットの譲渡における譲渡条件
であり、上記条件充足証明記録部は上記譲渡条件の充足
証明を記録する譲渡条件充足証明記録部を含み、上記条
件充足証明検証手段は、上記譲渡条件として記録された
上記スキーマ識別子により指定されたスキーマの上記チ
ケットが存在するか検証し、かつ上記譲渡条件充足証明
が上記譲渡条件充足証明記録部に記録されていることを
検証する手段を含む。
【請求項２０】請求項１５、１６、１７、１８、又
は１９の譲受装置において、上記条件記録部の上記機関
条件定義部には、上記電子チケットを受信する受信機関
が所有していなければならない第２チケットのスキーマ
を指定する第２スキーマ識別子が上記移動条件として含
まれている。
【請求項２１】請求項２０の譲受装置において、上
記検証する手段は上記受信機関として上記機関条件定義
部の上記第２スキーマ識別子により指定されたスキーマ
の第２チケットを有しているかを検証する手段を含む。
【請求項２２】請求項１５の電子チケット譲受装置
において、譲受する上記電子チケットのチケットスキー
マが、権利種別情報毎に電子チケットスキーマ定義機関
の識別子が記録されたスキーマ定義機関テーブルに掲載
されている電子チケットスキーマ定義機関によって定義
されていることを検証する手段を含み、上記チケットス
キーマは、上記チケットスキーマを定義した上記電子チケットスキ
ーマ定義機関の識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件と、が記録されて
いる。
【請求項２３】請求項１５の電子チケット譲受装置
において、譲受する電子チケットのチケットスキーマ
が、権利種別情報毎にチケットスキーマの識別子が記録
されたスキーマ識別子テーブルに掲載された識別子を持
つことを検証する手段を含み、上記チケットスキーマ
は、上記チケットスキーマの識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項２４】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの消費条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は、上
記電子チケットを受信する受信機関が所有していなけれ
ばならないチケットを上記消費条件として指定する機関
条件定義部を有する電子チケットの消費装置であって、上記機関条件定義部に指定された上記受信機関が所有し
ていなければならないチケットを所有しているか否かを
検証する手段と、上記検証手段による検証が満たされた場合、上記電子チ
ケットを上記受信機関に送信する手段、とを含む。
【請求項２５】請求項２４の消費装置において、上
記機関条件定義部は上記受信機関が所有していなければ
ならないチケットのスキーマを指定するスキーマ識別子
を上記消費条件として含む。
【請求項２６】請求項２４の消費装置において、上
記機関条件定義部は、上記電子チケットを送信する送信
機関が所有していなければならないチケットのスキーマ
を指定するスキーマ識別子を上記消費条件として含んで
おり、上記検証する手段は上記機関条件定義部のスキー
マ識別子により指定されたスキーマの、上記送信機関が
所有していなければならない上記チケットが存在してい
るかを検証する手段を含む。
【請求項２７】請求項２６の消費装置において、上
記電子チケットは上記消費条件の充足を証明する消費条
件充足証明を記録するするための消費条件充足証明記録
部を含み、上記消費装置は更に上記検証に成功した場合に消費条件
充足証明を上記消費条件充足証明記録部に記録する手段
を含む。
【請求項２８】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを送信する送信機関が所有していなければ
ならないチケットを指定する機関条件定義部を有する電
子チケットの改札装置であって、上記機関条件定義部に指定された上記送信機関が所有し
ていなければならないチケットを所有しているかどうか
を検証する手段と、上記検証が満たされた場合、上記電子チケットを蓄積す
る蓄積装置、とを含む。
【請求項２９】請求項２８の改札装置において、上
記電子チケットの上記機関条件定義部には上記移動条件
として、上記送信機関が所有していなければならないチ
ケットのスキーマを指定するスキーマ識別子が記録され
ている。
【請求項３０】請求項２９の改札装置において、上
記電子チケットは上記移動条件の充足を証明する条件充
足証明を記録する条件充足証明記録部を含み、上記検証
する手段は、上記条件充足証明記録部に記録されている
上記条件充足証明を検証する手段を含む。
【請求項３１】請求項３０の改札装置において、上
記移動条件は上記電子チケットの発行における発行条件
であり、上記条件充足証明記録部は上記発行条件の充足
証明を記録する発行条件充足証明記録部を含み、上記条
件充足証明検証手段は、上記発行条件として記録された
上記スキーマ識別子により指定されたスキーマのチケッ
トが存在するかを検証し、かつ上記発行条件充足証明が
上記発行条件充足証明記録部に記録されているかを検証
する手段を含む。
【請求項３２】請求項３０の改札装置において、上
記移動条件は上記電子チケットの譲渡における譲渡条件
であり、上記条件充足証明記録部は上記譲渡条件の充足
証明を記録する譲渡条件充足証明記録部を含み、上記条
件充足証明検証手段は、上記譲渡条件として記録された
上記スキーマ識別子により指定されたスキーマの上記チ
ケットが存在するか検証し、かつ上記譲渡条件充足証明
が上記譲渡条件充足証明記録部に記録されていることを
検証する手段を含む。
【請求項３３】請求項３０の改札装置において、上
記移動条件は上記電子チケットの消費における消費条件
であり、上記条件充足証明記録部は上記消費条件の充足
証明を記録する消費条件充足証明記録部を含み、上記条
件充足証明検証手段は、上記消費条件として記録された
上記スキーマ識別子により指定されたスキーマのチケッ
トが存在するかを検証し、かつ上記消費条件充足証明が
上記消費条件充足証明記録部に記録されているかを検証
する手段を含む。
【請求項３４】請求項２８、２９、３０、３１、３
２又は３３の改札装置において、上記条件記録部の上記
機関条件定義部には、上記電子チケットを受信する受信
機関が所有していなければならない第２チケットのスキ
ーマを指定する第２スキーマ識別子が上記移動条件とし
て含まれている。
【請求項３５】請求項３４の改札装置において、上
記検証する手段は上記受信機関として上記機関条件定義
部の上記第２スキーマ識別子により指定されたスキーマ
の第２チケットを有しているかを検証する手段を含む。
【請求項３６】請求項２８の改札装置において、受
信された上記電子チケットのチケットスキーマが、権利
種別情報毎に電子チケットスキーマ定義機関の識別子が
記録されたスキーマ定義機関テーブルに掲載されている
電子チケットスキーマ定義機関によって定義されている
ことを検証する手段を含み、上記チケットスキーマは、上記チケットスキーマを定義した上記電子チケットスキ
ーマ定義機関の識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項３７】請求項２８の改札装置において、受
信された上記電子チケットのチケットスキーマが、権利
種別情報毎にチケットスキーマの識別子が記録されたス
キーマ識別子テーブルに掲載された識別子を持つことを
検証する手段を含み、上記チケットスキーマは、上記チケットスキーマの識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項３８】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの発行条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを受信する受信機関が所有していなければ
ならないチケットを発行条件として指定する機関条件定
義部を有している電子チケットの発行方法であって、以
下のステップを含む： (a) 上記電子チケットの上記発行機関識別子記録部、上
記権利情報記録部、上記条件記録部、上記所有者識別子
記録部、上記署名記録部にそれぞれ上記発行機関識別
子、権利情報、発行条件、所有者識別子、発行機関署名
を記録し、 (b) 上記機関条件定義部に指定された上記受信機関が所
有していなければならないチケットを所有しているか検
証し、 (c) 上記ステップ(b) による検証が満たされた場合、上
記電子チケットを上記受信機関に送信する。
【請求項３９】請求項３８の発行方法において、上
記電子チケットの上記機関条件定義部には上記電子チケ
ットの受信機関が所有していなければならないチケット
のスキーマを指定するスキーマ識別子が上記発行条件と
して記録されている。
【請求項４０】請求項３８の発行方法において、上
記条件記録部の上記機関条件定義部は、上記電子チケッ
トを送信する送信機関が所有していなければならないチ
ケットのスキーマを指定するスキーマ識別子を上記発行
条件として更に含んでおり、上記検証する手段は上記機
関条件定義部のスキーマ識別子により指定されたスキー
マの上記チケットが存在しているかを検証する手段を含
む。
【請求項４１】請求項４０の発行方法において、上
記電子チケットは上記発行条件の充足を証明する発行条
件充足証明を記録するための発行条件充足証明記録部を
含み、上記発行方法は更に上記検証に成功した場合に、
発行条件充足証明を上記発行条件充足証明記録部に記録
するステップを含む。
【請求項４２】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は、上
記電子チケットを受信する受信機関が所有していなけれ
ばならないチケットを上記移動条件として指定する機関
条件定義部を有する電子チケットの譲渡方法であって、
以下のステップを含む： (a) 上記機関条件定義部に指定された上記受信機関が所
有していなければならない全てのチケットを所有してい
るか否かを検証し、 (b) 上記ステップ(a) による検証が満たされた場合、上
記電子チケットを上記受信機関に送信する。
【請求項４３】請求項４２の譲渡方法において、上
記機関条件定義部は上記受信機関が所有していなければ
ならないチケットのスキーマを指定するスキーマ識別子
を上記譲渡条件として含む。
【請求項４４】請求項４２の譲渡方法において、上
記機関条件定義部は、上記電子チケットを送信する送信
機関が所有していなければならないチケットのスキーマ
を指定するスキーマ識別子を上記譲渡条件として含んで
おり、上記検証するステップ(a) は上記機関条件定義部
のスキーマ識別子により指定されたスキーマの、上記送
信機関が所有していなければならない上記チケットが存
在しているかを検証するステップを含む。
【請求項４５】請求項４２の譲渡方法において、上
記電子チケットは上記譲渡条件の充足を証明する譲渡条
件充足証明を記録するするための譲渡条件充足証明記録
部を含み、上記ステップ(a) の検証に成功した場合に譲渡条件充足
証明を上記譲渡条件充足証明記録部に記録するステップ
を含む。
【請求項４６】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を指定する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを送信する送信機関が所有していなければ
ならないチケットを上記移動条件として指定する機関条
件定義部を有する電子チケットの譲受方法であって、以
下のステップを含む： (a) 上記機関条件定義部に指定された上記送信機関が所
有していなければならないチケットを所有しているかど
うかを検証し、 (b) 上記検証が満たされた場合、上記電子チケットを蓄
積する。
【請求項４７】請求項４６の譲受方法において、上
記電子チケットの上記機関条件定義部には上記移動条件
として、上記電子チケットの発行機関が所有していなけ
ればならないチケットのスキーマを指定するスキーマ識
別子が記録されている。
【請求項４８】請求項４７の譲受方法において、上
記電子チケットは上記移動条件の充足を証明する条件充
足証明を記録する条件充足証明記録部を含み、上記ステ
ップ(a) は、上記条件充足証明記録部に記録されている
上記条件充足証明を検証するステップを含む。
【請求項４９】請求項４８の譲受方法において、上
記移動条件は上記電子チケットの発行における発行条件
であり、上記条件充足証明記録部は上記発行条件の充足
証明を記録する発行条件充足証明記録部を含み、上記ス
テップ(a) は、上記発行条件として記録された上記スキ
ーマ識別子により指定されたスキーマのチケットが存在
するかを検証し、かつ上記発行条件充足証明が上記発行
条件充足証明記録部に記録されているかを検証するステ
ップを含む。
【請求項５０】請求項４８の譲受方法において、上
記移動条件は上記電子チケットの譲渡における譲渡条件
であり、上記条件充足証明記録部は上記譲渡条件の充足
証明を記録する譲渡条件充足証明記録部を含み、上記ス
テップ(a) は、上記譲渡条件として記録された上記スキ
ーマ識別子により指定されたスキーマの上記チケットが
存在するか検証し、かつ上記譲渡条件充足証明が上記譲
渡条件充足証明記録部に記録されていることを検証する
ステップを含む。
【請求項５１】請求項４６、４７、４８、４９、又
は５０の譲受方法において、上記条件記録部の上記機関
条件定義部には、上記電子チケットを受信する受信機関
が所有していなければならない第２チケットのスキーマ
を指定する第２スキーマ識別子が上記移動条件として含
まれている。
【請求項５２】請求項５１の譲受方法において、上
記ステップ(a) は上記受信機関として上記機関条件定義
部の上記第２スキーマ識別子により指定されたスキーマ
の第２チケットを有しているかを検証するステップを含
む。
【請求項５３】請求項４６の譲受方法において、上
記ステップ(a) は譲受する上記電子チケットのチケット
スキーマが、権利種別情報毎に電子チケットスキーマ定
義機関の識別子が記録されたスキーマ定義機関テーブル
に掲載されている電子チケットスキーマ定義機関によっ
て定義されていることを検証するステップを含み、上記
チケットスキーマは、上記チケットスキーマを定義した上記電子チケットスキ
ーマ定義機関の識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件と、が記録されて
いる。
【請求項５４】請求項４６の譲受方法において、上
記ステップ(a) は譲受する電子チケットのチケットスキ
ーマが、権利種別情報毎にチケットスキーマの識別子が
記録されたスキーマ識別子テーブルに掲載された識別子
を持つことを検証するステップを含み、上記チケットス
キーマは、上記チケットスキーマの識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項５５】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの消費条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は、上
記電子チケットを受信する受信機関が所有していなけれ
ばならないチケットを上記消費条件として指定する機関
条件定義部を有する電子チケットの消費方法であって、
以下のステップを含む： (a) 上記機関条件定義部に指定された上記受信機関が所
有していなければならないチケットを所有しているか否
かを検証し、 (b) 上記ステップ(a) による検証が満たされた場合、上
記電子チケットを上記受信機関に送信する。
【請求項５６】請求項５５の消費方法において、上
記機関条件定義部は上記受信機関が所有していなければ
ならないチケットのスキーマを指定するスキーマ識別子
を上記消費条件として含む。
【請求項５７】請求項５５の消費方法において、上
記機関条件定義部は、上記電子チケットを送信する送信
機関が所有していなければならないチケットのスキーマ
を指定するスキーマ識別子を上記消費条件として含んで
おり、上記ステップ(a) は上記機関条件定義部のスキー
マ識別子により指定されたスキーマの、上記送信機関が
所有していなければならない上記チケットが存在してい
るかを検証するステップを含む。
【請求項５８】請求項５７の消費方法において、上
記電子チケットは上記消費条件の充足を証明する消費条
件充足証明を記録するするための消費条件充足証明記録
部を含み、上記ステップ(a) は更に上記検証に成功した場合に消費
条件充足証明を上記消費条件充足証明記録部に記録する
ステップを含む。
【請求項５９】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを送信する送信機関が所有していなければ
ならないチケットを指定する機関条件定義部を有する電
子チケットの改札方法であって、以下のステップを含
む： (a) 上記機関条件定義部に指定された上記送信機関が所
有していなければならないチケットを所有しているかど
うかを検証し、 (b) 上記検証が満たされた場合、上記電子チケットを蓄
積する。
【請求項６０】請求項５９の改札方法において、上
記電子チケットの上記機関条件定義部には上記移動条件
として、上記送信機関が所有していなければならないチ
ケットのスキーマを指定するスキーマ識別子が記録され
ている。
【請求項６１】請求項６０の改札方法において、上
記電子チケットは上記移動条件の充足を証明する条件充
足証明を記録する条件充足証明記録部を含み、上記ステ
ップ(a) は、上記条件充足証明記録部に記録されている
上記条件充足証明を検証するステップを含む。
【請求項６２】請求項６１の改札方法において、上
記移動条件は上記電子チケットの発行における発行条件
であり、上記条件充足証明記録部は上記発行条件の充足
証明を記録する発行条件充足証明記録部を含み、上記ス
テップ(a) は、上記発行条件として記録された上記スキ
ーマ識別子により指定されたスキーマのチケットが存在
するかを検証し、かつ上記発行条件充足証明が上記発行
条件充足証明記録部に記録されているかを検証するステ
ップを含む。
【請求項６３】請求項６１の改札方法において、上
記移動条件は上記電子チケットの譲渡における譲渡条件
であり、上記条件充足証明記録部は上記譲渡条件の充足
証明を記録する譲渡条件充足証明記録部を含み、上記ス
テップ(a) は、上記譲渡条件として記録された上記スキ
ーマ識別子により指定されたスキーマの上記チケットが
存在するか検証し、かつ上記譲渡条件充足証明が上記譲
渡条件充足証明記録部に記録されていることを検証する
ステップを含む。
【請求項６４】請求項６１の改札方法において、上
記移動条件は上記電子チケットの消費における消費条件
であり、上記条件充足証明記録部は上記消費条件の充足
証明を記録する消費条件充足証明記録部を含み、上記ス
テップ(a) は、上記消費条件として記録された上記スキ
ーマ識別子により指定されたスキーマのチケットが存在
するかを検証し、かつ上記消費条件充足証明が上記消費
条件充足証明記録部に記録されているかを検証するステ
ップを含む。
【請求項６５】請求項５９、６０、６１、６２、６
３又は６４の改札方法において、上記条件記録部の上記
機関条件定義部には、上記電子チケットを受信する受信
機関が所有していなければならない第２チケットのスキ
ーマを指定する第２スキーマ識別子が上記移動条件とし
て含まれている。
【請求項６６】請求項６５の改札方法において、上
記ステップ(a) は上記受信機関として上記機関条件定義
部の上記第２スキーマ識別子により指定されたスキーマ
の第２チケットを有しているかを検証するステップを含
む。
【請求項６７】請求項５９の改札方法において、上
記ステップ(a) は受信された上記電子チケットのチケッ
トスキーマが、権利種別情報毎に電子チケットスキーマ
定義機関の識別子が記録されたスキーマ定義機関テーブ
ルに掲載されている電子チケットスキーマ定義機関によ
って定義されていることを検証するステップを含み、上
記チケットスキーマは、上記チケットスキーマを定義した上記電子チケットスキ
ーマ定義機関の識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項６８】請求項５９の改札方法において、上
記ステップ(a) は受信された上記電子チケットのチケッ
トスキーマが、権利種別情報毎にチケットスキーマの識
別子が記録されたスキーマ識別子テーブルに掲載された
識別子を持つことを検証するステップを含み、上記チケ
ットスキーマは、上記チケットスキーマの識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項６９】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの発行条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを受信する受信機関が所有していなければ
ならないチケットを発行条件として指定する機関条件定
義部を有している電子チケットの発行方法をコンピュー
タで実施するプログラムとして記録した発行方法記録媒
体であり、上記プログラムは以下のステップを含む： (a) 上記電子チケットの上記発行機関識別子記録部、上
記権利情報記録部、上記条件記録部、上記所有者識別子
記録部、上記署名記録部にそれぞれ上記発行機関識別
子、権利情報、発行条件、所有者識別子、発行機関署名
を記録し、 (b) 上記機関条件定義部に指定された上記受信機関が所
有していなければならないチケットを所有しているか検
証し、 (c) 上記ステップ(b) による検証が満たされた場合、上
記電子チケットを上記受信機関に送信する。
【請求項７０】請求項６９の発行方法記録媒体にお
いて、上記電子チケットの上記機関条件定義部には上記
電子チケットの受信機関が所有していなければならない
チケットのスキーマを指定するスキーマ識別子が上記発
行条件として記録されている。
【請求項７１】請求項６９の発行方法記録媒体にお
いて、上記条件記録部の上記機関条件定義部は、上記電
子チケットを送信する送信機関が所有していなければな
らないチケットのスキーマを指定するスキーマ識別子を
上記発行条件として更に含んでおり、上記検証するステ
ップは上記機関条件定義部のスキーマ識別子により指定
されたスキーマの上記チケットが存在しているかを検証
するステップを含む。
【請求項７２】請求項７１の発行方法記録媒体にお
いて、上記電子チケットは上記発行条件の充足を証明す
る発行条件充足証明を記録するための発行条件充足証明
記録部を含み、上記発行方法は更に上記検証に成功した
場合に、発行条件充足証明を上記発行条件充足証明記録
部に記録するステップを含む。
【請求項７３】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は、上
記電子チケットを受信する受信機関が所有していなけれ
ばならないチケットを上記移動条件として指定する機関
条件定義部を有する電子チケットの譲渡方法をコンピュ
ータで実施するプログラムとして記録した譲渡方法記録
媒体であって、上記プログラムは以下のステップを含
む： (a) 上記機関条件定義部に指定された上記受信機関が所
有していなければならない全てのチケットを所有してい
るか否かを検証し、 (b) 上記ステップ(a) による検証が満たされた場合、上
記電子チケットを上記受信機関に送信する。
【請求項７４】請求項７３の譲渡方法記録媒体にお
いて、上記機関条件定義部は上記受信機関が所有してい
なければならないチケットのスキーマを指定するスキー
マ識別子を上記譲渡条件として含む。
【請求項７５】請求項７３の譲渡方法記録媒体にお
いて、上記機関条件定義部は、上記電子チケットを送信
する送信機関が所有していなければならないチケットの
スキーマを指定するスキーマ識別子を上記譲渡条件とし
て含んでおり、上記検証するステップ(a) は上記機関条
件定義部のスキーマ識別子により指定されたスキーマ
の、上記送信機関が所有していなければならない上記チ
ケットが存在しているかを検証するステップを含む。
【請求項７６】請求項７５の譲渡方法記録媒体にお
いて、上記電子チケットは上記譲渡条件の充足を証明す
る譲渡条件充足証明を記録するするための譲渡条件充足
証明記録部を含み、ステップ(a) の検証に成功した場合
に譲渡条件充足証明を上記譲渡条件充足証明記録部に記
録するステップを含む。
【請求項７７】電子チケットの発行機関の識別子を記録
する発行機関識別子記録部と、上記電子チケットの権利
情報を記録する権利情報記録部と、上記電子チケットの
移動条件を指定する条件記録部と、所有者の識別子を記
録する所有者識別子記録部と、上記発行機関の署名を記
録する署名記録部とを有し、上記条件記録部は上記電子
チケットを送信する送信機関が所有していなければなら
ないチケットを上記移動条件として指定する機関条件定
義部を有する電子チケットの譲受方法をコンピュータで
実施するプログラムとして記録した記録媒体であり、上
記プログラムは以下のステップを含む： (a) 上記機関条件定義部に指定された上記送信機関が所
有していなければならないチケットを所有しているかど
うかを検証し、 (b) 上記検証が満たされた場合、上記電子チケットを蓄
積する。
【請求項７８】請求項７７の譲受方法記録媒体にお
いて、上記電子チケットの上記機関条件定義部には上記
移動条件として、上記電子チケットの発行機関が所有し
ていなければならないチケットのスキーマを指定するス
キーマ識別子が記録されている。
【請求項７９】請求項７８の譲受方法記録媒体にお
いて、上記電子チケットは上記移動条件の充足を証明す
る条件充足証明を記録する条件充足証明記録部を含み、
上記ステップ(a) は、上記条件充足証明記録部に記録さ
れている上記条件充足証明を検証するステップを含む。
【請求項８０】請求項７９の譲受方法記録媒体にお
いて、上記移動条件は上記電子チケットの発行における
発行条件であり、上記条件充足証明記録部は上記発行条
件の充足証明を記録する発行条件充足証明記録部を含
み、上記ステップ(a) は、上記発行条件として記録され
た上記スキーマ識別子により指定されたスキーマのチケ
ットが存在するかを検証し、かつ上記発行条件充足証明
が上記発行条件充足証明記録部に記録されているかを検
証するステップを含む。
【請求項８１】請求項７９の譲受方法記録媒体にお
いて、上記移動条件は上記電子チケットの譲渡における
譲渡条件であり、上記条件充足証明記録部は上記譲渡条
件の充足証明を記録する譲渡条件充足証明記録部を含
み、上記ステップ(a) は、上記譲渡条件として記録され
た上記スキーマ識別子により指定されたスキーマの上記
チケットが存在するか検証し、かつ上記譲渡条件充足証
明が上記譲渡条件充足証明記録部に記録されていること
を検証するステップを含む。
【請求項８２】請求項７７、７８、７９、８０、又
は８１の譲受方法において、上記条件記録部の上記機関
条件定義部には、上記電子チケットを受信する受信機関
が所有していなければならない第２チケットのスキーマ
を指定する第２スキーマ識別子が上記移動条件として含
まれている。
【請求項８３】請求項８２の譲受方法記録媒体にお
いて、上記ステップ(a) は上記受信機関として上記機関
条件定義部の上記第２スキーマ識別子により指定された
スキーマの第２チケットを有しているかを検証するステ
ップを含む。
【請求項８４】請求項７７の譲受方法記録媒体にお
いて、上記ステップ(a) は譲受する上記電子チケットの
チケットスキーマが、権利種別情報毎に電子チケットス
キーマ定義機関の識別子が記録されたスキーマ定義機関
テーブルに掲載されている電子チケットスキーマ定義機
関によって定義されていることを検証するステップを含
み、上記チケットスキーマは、上記チケットスキーマを定義した上記電子チケットスキ
ーマ定義機関の識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件と、が記録されて
いる。
【請求項８５】請求項７７の譲受方法記録媒体にお
いて、上記ステップ(a) は譲受する電子チケットのチケ
ットスキーマが、権利種別情報毎にチケットスキーマの
識別子が記録されたスキーマ識別子テーブルに掲載され
た識別子を持つことを検証するステップを含み、上記チ
ケットスキーマは、上記チケットスキーマの識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項８６】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの消費条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は、上
記電子チケットを受信する受信機関が所有していなけれ
ばならないチケットを上記消費条件として指定する機関
条件定義部を有する電子チケットの消費方法をコンピュ
ータで実施するプログラムとして記録した記録媒体であ
り、上記プログラムは、以下のステップを含む： (a) 上記機関条件定義部に指定された上記受信機関が所
有していなければならないチケットを所有しているか否
かを検証し、 (b) 上記ステップ(a) による検証が満たされた場合、上
記電子チケットを上記受信機関に送信する。
【請求項８７】請求項８６の消費方法記録媒体にお
いて、上記機関条件定義部は上記受信機関が所有してい
なければならないチケットのスキーマを指定するスキー
マ識別子を上記消費条件として含む。
【請求項８８】請求項８６の消費方法記録媒体にお
いて、上記機関条件定義部は、上記電子チケットを送信
する送信機関が所有していなければならないチケットの
スキーマを指定するスキーマ識別子を上記消費条件とし
て含んでおり、上記ステップ(a) は上記機関条件定義部
のスキーマ識別子により指定されたスキーマの、上記送
信機関が所有していなければならない上記チケットが存
在しているかを検証するステップを含む。
【請求項８９】請求項８８の消費方法記録媒体にお
いて、上記電子チケットは上記消費条件の充足を証明す
る消費条件充足証明を記録するするための消費条件充足
証明記録部を含み、上記ステップ(a) は更に上記検証に成功した場合に消費
条件充足証明を上記消費条件充足証明記録部に記録する
ステップを含む。
【請求項９０】電子チケットの発行機関の識別子を
記録する発行機関識別子記録部と、上記電子チケットの
権利情報を記録する権利情報記録部と、上記電子チケッ
トの移動条件を記録する条件記録部と、所有者の識別子
を記録する所有者識別子記録部と、上記発行機関の署名
を記録する署名記録部とを有し、上記条件記録部は上記
電子チケットを送信する送信機関が所有していなければ
ならないチケットを指定する機関条件定義部を有する電
子チケットの改札方法をコンピュータで実施するプログ
ラムとして記録した記録媒体であり、上記プログラムは
以下のステップを含む： (a) 上記機関条件定義部に指定された上記送信機関が所
有していなければならないチケットを所有しているかど
うかを検証し、 (b) 上記検証が満たされた場合、上記電子チケットを蓄
積する。
【請求項９１】請求項９０の改札方法記録媒体にお
いて、上記電子チケットの上記機関条件定義部には上記
移動条件として、上記送信機関が所有していなければな
らないチケットのスキーマを指定するスキーマ識別子が
記録されている。
【請求項９２】請求項９１の改札方法記録媒体にお
いて、上記電子チケットは上記移動条件の充足を証明す
る条件充足証明を記録する条件充足証明記録部を含み、
上記ステップ(a) は、上記条件充足証明記録部に記録さ
れている上記条件充足証明を検証するステップを含む。
【請求項９３】請求項９２の改札方法記録媒体にお
いて、上記移動条件は上記電子チケットの発行における
発行条件であり、上記条件充足証明記録部は上記発行条
件の充足証明を記録する発行条件充足証明記録部を含
み、上記ステップ(a) は、上記発行条件として記録され
た上記スキーマ識別子により指定されたスキーマのチケ
ットが存在するかを検証し、かつ上記発行条件充足証明
が上記発行条件充足証明記録部に記録されているかを検
証するステップを含む。
【請求項９４】請求項９２の改札方法記録媒体にお
いて、上記移動条件は上記電子チケットの譲渡における
譲渡条件であり、上記条件充足証明記録部は上記譲渡条
件の充足証明を記録する譲渡条件充足証明記録部を含
み、上記ステップ(a) は、上記譲渡条件として記録され
た上記スキーマ識別子により指定されたスキーマの上記
チケットが存在するか検証し、かつ上記譲渡条件充足証
明が上記譲渡条件充足証明記録部に記録されていること
を検証するステップを含む。
【請求項９５】請求項９２の改札方法記録媒体にお
いて、上記移動条件は上記電子チケットの消費における
消費条件であり、上記条件充足証明記録部は上記消費条
件の充足証明を記録する消費条件充足証明記録部を含
み、上記ステップ(a) は、上記消費条件として記録され
た上記スキーマ識別子により指定されたスキーマのチケ
ットが存在するかを検証し、かつ上記消費条件充足証明
が上記消費条件充足証明記録部に記録されているかを検
証するステップを含む。
【請求項９６】請求項９０、９１、９２、９３、９
４又は９５の改札方法記録媒体において、上記条件記録
部の上記機関条件定義部には、上記電子チケットを受信
する受信機関が所有していなければならない第２チケッ
トのスキーマを指定する第２スキーマ識別子が上記移動
条件として含まれている。
【請求項９７】請求項９６の改札方法記録媒体にお
いて、上記ステップ(a) は上記受信機関として上記機関
条件定義部の上記第２スキーマ識別子により指定された
スキーマの第２チケットを有しているかを検証するステ
ップを含む。
【請求項９８】請求項９０の改札方法記録媒体にお
いて、上記ステップ(a) は受信された上記電子チケット
のチケットスキーマが、権利種別情報毎に電子チケット
スキーマ定義機関の識別子が記録されたスキーマ定義機
関テーブルに掲載されている電子チケットスキーマ定義
機関によって定義されていることを検証するステップを
含み、上記チケットスキーマは、上記チケットスキーマを定義した上記電子チケットスキ
ーマ定義機関の識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。
【請求項９９】請求項９０の改札方法記録媒体にお
いて、上記ステップ(a) は受信された上記電子チケット
のチケットスキーマが、権利種別情報毎にチケットスキ
ーマの識別子が記録されたスキーマ識別子テーブルに掲
載された識別子を持つことを検証するステップを含み、
上記チケットスキーマは、上記チケットスキーマの識別子と、上記電子チケットの権利情報の構造を定義した権利情報
構造と、上記電子チケットを発行するための条件を定義する発行
条件、上記電子チケットを譲渡するための条件を定義す
る譲渡条件、上記電子チケットを消費するための条件を
定義する消費条件の少なくとも１つの条件が指定され、
上記指定された条件として送信機関条件と受信機関条件
の少なくとも１つを定義する機関条件、とが記録されて
いる。