デジタルチケットは、商品やサービスの権利をデジタル化したチケットの仮想インスタンスです。[ 1]
基準
デジタルチケットは次の基準を満たす必要があります。
- 安全(改ざんや偽造が不可能)
- ポータブル(物理的独立性)
- オフライン対応
- 幅広い受容性(チケットが一般的に受け入れられるためには、ある程度の信頼が必要です。)
- 使いやすい
さらに、デジタルチケットには次の 3 つの要件も重要です。
- 閲覧可能
- サービスの条件と説明は、サービス提供者と消費者または所有者の両方が客観的に理解できる必要があります。これにより、チケットの価値を判断できます。さらに、これはデジタルチケットを追跡するために不可欠な特性です。
- 状態管理可能
- チケットには、支払いステータス(支払済みまたは未払い)や予約ステータス(待機リスト、予約済み、キャンセル済みなど)がある場合もあります。ステータスは動的に変更される可能性があります。さらに、チケットが譲渡されたときにチケットの所有権を書き換えることもできます。ただし、セキュリティを保証しながらこれらの変更を許可することは困難です。
- 分解可能
- サービスを受けるには 2 枚以上のチケットを組み合わせる必要がある場合があります。また、1 枚のチケットが複数の部分で構成される場合もあります。たとえば、旅行チケットは宿泊チケットと航空券またはレンタカーチケットで構成できます。
上記の基準以外にも、匿名性、譲渡可能性、繰り返しの使用可能性など、考慮すべき特徴がいくつかあります。[1]
ライフサイクル
チケットは、まずサービス プロバイダーまたは発行者によって発行されます。チケットの所有権は、チケットの譲渡によって発行後に変更される場合があります。チケットの発行者または所有者は、チケットのステータスを表示できます。最後に、サービス プロバイダーの現在の所有者によってチケットが引き換えられます。
創造
作成者の観点から見ると、各デジタル チケットには特定の構造があり、これは次のように示される多層アーキテクチャで表現できます。

レイヤー1
チケットの種類に依存しない共通のチケット プロパティ:
- 発行者
- お約束(詳細は上層に記載)
- 所有者
- 譲渡可能性
- 消費回数
- 有効期間
- ビュー
- 上記に発行者の署名
レイヤー2
- 各業界によって定義されるチケットプロパティ
レイヤー3
- 各発行会社または個人によって定義されるチケットのプロパティ
[1]
移行
チケットの目的に応じて、チケットは譲渡されることがあります。譲渡プロセス中、チケットは関係する両当事者に表示される必要があります。譲渡プロセスが完了すると、チケットの所有権が変更されます。譲渡の履歴は、チケット自体または中央データベースのいずれかに記録される必要があります。
ビュー
チケットを表示する機能は、サービス プロバイダーとチケット所有者の両方にとって重要です。所有者は自分のチケットが実際に何であるかを知る必要があり、サービス プロバイダーは引き換え時にチケットを確認する必要があります。この表示は、適切に設計されたハードウェアによって実現できます。
償還
デジタル チケットには、サービス プロバイダーで引き換えられる一定の価値が常にあります。通常、引き換え後、チケットは消去されます。一部のチケットは一定期間有効で、この期間が過ぎると削除されます。引き換え後にチケットが配布されない特別なケースでは、パスと呼ばれます。6957429665396
実装
デジタル チケット システムを実装するには、2 つのパラダイムを組み合わせて使用できます。1 つ目は、中央ストレージとネットワーク接続に依存するアカウント ベースのシステムです。2 つ目は、分散ストレージを使用してチケットを保存および転送するスマート カード ベースのシステムです。
アカウントベースのシステム
チケットのアカウントベースのシステムでは、チケットの権利はアカウントで管理されます。[2]アカウント内のチケットの変更は、ネットワークを介していわゆるアカウントマネージャと通信することで行うことができます。これらのシステムに対する信頼は、サービスプロバイダとユーザの観点から見ることができます。サービスプロバイダは通常、システム全体を管理しています。これにより、信頼関係が不均衡になります。これらのシステムの他の2つの欠点は、悪意のあるユーザーからアカウントを保護する必要があることと、ユーザとサービスプロバイダの両方のすべてのアカウントを保存するために比較的大きな労力が必要になることです。
ストレージ
通常、アカウントの保管と維持のタスクはサービス プロバイダーに割り当てられます。これにより、サービス プロバイダー側にコストと労力がかかります。場合によっては、これらのシステムを複数のサービス プロバイダーで共有することもできますが、一般的な契約を結ぶ必要があります。通常、サービス プロバイダーはアカウントを完全に制御するため、チケットが削除または変更され、その後、最初のチケットが表すサービスの実行を拒否される可能性があります。
認証
通常、アカウントベースのシステムでは、ユーザーを認証するために ID とパスワードが使用されます。これでは、サービス プロバイダーによる不正行為を防止できません。いくつかのデジタル キャッシュ システムでは、ユーザーの PC で秘密キーを生成し、サービス プロバイダーの手に渡らないようにすることで、この問題に対処しています。ただし、チケットを実際のサービス プロバイダーで引き換える場合は、これでは不十分です。
重複償還の防止
アカウント管理はサービスプロバイダーによって完全に制御されるため、チケットのコピーなどの望ましくないアクションはサービスプロバイダーによって簡単に検出され、追跡される可能性があります。
スマートカードベースのシステム
スマート カードベースのシステムでは、チケットはスマート カードに保存され、2 枚のスマート カードをリーダーに挿入してトランザクションを完了することで流通します。スマート カード自体が、安全な転送に必要な計算を行います。
ストレージ
チケットはスマート カードに保存されます。スマート カードは、ユーザーとサービス プロバイダーの両方が提供できます。現在のスマート カードのパフォーマンスには限界があるため、非同期取引は困難です。サービス プロバイダーによって標準が異なる可能性が高いため、チケットの種類ごとに異なるスマート カードが必要になります。これは乗客にとって非常に便利です。
認証
スマート カードに秘密鍵を実装すると、カードを携帯して、ネットワーク接続を使用せずにチケットを引き換えることができます。サービス プロバイダーがこれらのカードで秘密鍵を配布および発行する場合、悪意のあるサービス プロバイダーによる詐欺が依然として問題となります。これにより、異なるサービス プロバイダー間でスマート カードを共有することも困難になります。
重複償還の防止
ストレージは通常、サービス プロバイダーによって管理されます。スマート カードは複製から保護する必要があります。ただし、システムが破壊されると、セキュリティは完全に失われます。
参照
参考文献
- ^ abc 藤村 耕; 中島 良明 (1998)。「汎用デジタルチケットフレームワーク」。第 3 回USENIX電子商取引ワークショップ議事録。USENIX。pp . 177–186。
- ^ 松山一夫、藤村 耕 (1999)。「権利取引システムのための分散型デジタルチケット管理」。電子商取引に関する第 1 回 ACM 会議の議事録。Association for Computing Machinery。pp . 110–118。2012 年 7 月 13 日時点のオリジナルよりアーカイブ。2008年1 月 16 日閲覧。
外部リンク
- バスチケットがモバイルに
