IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ カリプトン インターナショナル リミテッドの特許一覧

特開2024-164013分散トランザクション処理及び認証システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024164013
(43)【公開日】2024-11-26
(54)【発明の名称】分散トランザクション処理及び認証システム
(51)【国際特許分類】
   H04L 9/32 20060101AFI20241119BHJP
   G06F 21/64 20130101ALI20241119BHJP
   G06F 21/60 20130101ALI20241119BHJP
【FI】
H04L9/32 200A
H04L9/32 200C
G06F21/64
G06F21/60 320
【審査請求】有
【請求項の数】10
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2024118373
(22)【出願日】2024-07-24
(62)【分割の表示】P 2019521195の分割
【原出願日】2017-07-07
(31)【優先権主張番号】1611948.9
(32)【優先日】2016-07-08
(33)【優先権主張国・地域又は機関】GB
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ブルートゥース
2.JAVASCRIPT
(71)【出願人】
【識別番号】519007651
【氏名又は名称】カリプトン インターナショナル リミテッド
【氏名又は名称原語表記】KALYPTON INTERNATIONAL LIMITED
(74)【代理人】
【識別番号】100105957
【弁理士】
【氏名又は名称】恩田 誠
(74)【代理人】
【識別番号】100068755
【弁理士】
【氏名又は名称】恩田 博宣
(74)【代理人】
【識別番号】100142907
【弁理士】
【氏名又は名称】本田 淳
(72)【発明者】
【氏名】デイビス、ラーズ
(57)【要約】      (修正有)
【課題】単一の実施において全てのタイプのトランザクションを大規模かつ安全にリアルタイムで行う方法及びシステムを提供する。
【解決手段】第1エンティティに関連するデバイスでデータトランザクションレコーディングする方法は、第1シードデータを決定するステップと、第1エンティティと第2エンティティとの間の第1データトランザクションのレコードを生成するステップと、少なくとも第1シードデータ及び第1データトランザクションのレコードを結合して第2シードデータを決定するステップと、第2シードデータをハッシュして、第1エンティティを含むデータトランザクションのヒストリーを含む第1ハッシュを生成するステップと、第1データトランザクションのレコードに対する第1ハッシュをメモリに格納するステップと、を含む。
【選択図】図1
【特許請求の範囲】
【請求項1】
第1エンティティに関連するデバイスでのデータトランザクションレコーディング方法において、
第1シードデータを決定するステップと、
前記第1エンティティと第2エンティティとの間の第1データトランザクションのレコードを生成するステップと、
少なくとも前記第1シードデータ及び前記第1データトランザクションのレコードを結合して第2シードデータを決定するステップと、
前記第2シードデータをハッシュして第1ハッシュを生成するステップであって、前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む、前記第1ハッシュを生成するステップと、
前記第1データトランザクションの前記レコードに対する前記第1ハッシュをメモリに格納するステップと、
を含むデータトランザクションレコーディング方法。
【請求項2】
前記第1シードデータは開始ハッシュを含む、請求項1に記載のデータトランザクションレコーディング方法。
【請求項3】
前記開始ハッシュは、前記第1エンティティに関連する以前のデータトランザクションのレコードをハッシュした結果である、請求項2に記載のデータトランザクションレコーディング方法。
【請求項4】
前記開始ハッシュはランダムハッシュを含む、請求項2に記載のデータトランザクションレコーディング方法。
【請求項5】
前記ランダムハッシュは、前記デバイスからの署名、前記ランダムハッシュが生成された日付、及び前記ランダムハッシュが生成された時間のうちの少なくとも1つを含む、請求項4に記載のデータトランザクションレコーディング方法。
【請求項6】
第2シードデータを提供するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと第1ゼロ知識証明及び第2ゼロ知識証明を結合するステップをさらに含み、
前記第1ゼロ知識証明は、前記開始ハッシュが前記第1エンティティに関連する前記以前のデータトランザクションの真のハッシュを含むという証明を含み、
前記第2ゼロ知識証明は、第2ハッシュが前記第2エンティティに関連する以前のデータトランザクションの前記真のハッシュを含むという証明を含む、請求項1乃至請求項5のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項7】
第2シードデータを提供するステップは、前記第1シードデータ、前記第1データトランザクションの前記レコード、前記第1ゼロ知識証明及び前記第2ゼロ知識証明と第3ゼロ知識証明を結合するステップをさらに含む、請求項6に記載のデータトランザクションレコーディング方法。
【請求項8】
前記第3ゼロ知識証明は、ランダムデータから生成される、請求項7に記載のデータトランザクションレコーディング方法。
【請求項9】
前記第3ゼロ知識証明は、前記第1ゼロ知識証明又は前記第2ゼロ知識証明の繰り返しである、請求項7に記載のデータトランザクションレコーディング方法。
【請求項10】
前記第3ゼロ知識証明は、前記第2ゼロ知識証明に対応する前記第1データトランザクションの第2レコードを用いて構成される、請求項7に記載のデータトランザクションレコーディング方法。
【請求項11】
前記第1データトランザクションは少なくとも2つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第1ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
前記第1データトランザクションの前記第2ステージのレコードと前記第2ゼロ知識証明を結合するステップと、
を含む、請求項6に記載のデータトランザクションレコーディング方法。
【請求項12】
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第2ステージのレコードから第3ゼロ知識証明を構成するステップと、
前記第1データトランザクションの前記第2ステージのレコードと前記第2ゼロ知識証明及び前記第3ゼロ知識証明を結合するステップと、
を含む、請求項11に記載のデータトランザクションレコーディング方法。
【請求項13】
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
前記第1データトランザクションの前記第3ステージのレコードと前記第3ゼロ知識証明を結合するステップと、
をさらに含む、請求項11に記載のデータトランザクションレコーディング方法。
【請求項14】
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
ランダムデータと前記第3ゼロ知識証明を結合するステップと、
をさらに含む、請求項11に記載のデータトランザクションレコーディング方法。
【請求項15】
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
前記第1データトランザクションの第4ステージのレコードと前記第2ゼロ知識証明を結合するステップと、
を含み、
前記第1データトランザクションの前記第4ステージは、前記第1データトランザクションの前記第3ステージの繰り返しである、請求項11に記載のデータトランザクションレコーディング方法。
【請求項16】
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、前記第1データトランザクションの前記第3ステージのレコードと第3ゼロ知識証明を結合するステップをさらに含む、請求項11に記載のデータトランザクションレコーディング方法。
【請求項17】
前記第1ゼロ知識証明は、前記第1エンティティに関連する前記デバイスによって構成され、
前記第2ゼロ知識証明は、前記第2エンティティに関連するデバイスによって構成される、請求項6乃至請求項16のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項18】
前記第1ゼロ知識証明及び前記第2ゼロ知識証明を構成するステップは、キー交換アルゴリズムを使用するステップを含む、請求項17に記載のデータトランザクションレコーディング方法。
【請求項19】
前記キー交換アルゴリズムは、PAKEアルゴリズムを含む、請求項18に記載のデータトランザクションレコーディング方法。
【請求項20】
前記第2エンティティに関連するデバイスに前記第1ハッシュを送信するステップと、
前記第2エンティティに関連するデバイスから第2ハッシュを受信するステップであって、前記第2ハッシュは、前記第2エンティティに関連する以前のデータトランザクションのハッシュを含む、前記第2ハッシュを受信するステップと、
前記第1パーティー及び前記第2パーティー間の第2データトランザクションのレコードを生成するステップと、
前記第1ハッシュ及び前記第2ハッシュと前記第2データトランザクションの前記レコードを結合して第3シードデータを決定するステップと、
前記第3シードデータをハッシュし、第3ハッシュを生成するステップであって、前記第3ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリー及び前記第2エンティティに関連するデータトランザクションのヒストリーを含む、前記第3ハッシュを生成するステップと、
前記第2データトランザクションの前記レコードに対する前記第3ハッシュを前記メモリに格納するステップと、
をさらに含む、請求項1乃至請求項19のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項21】
第3シードデータを提供するステップは、
前記第2データトランザクションの前記レコード、前記第1ハッシュ及び前記第2ハッシュと、第3ゼロ知識証明及び第4ゼロ知識証明とを結合するステップをさらに含み、
前記第3ゼロ知識証明は、前記第1ハッシュが前記第1データトランザクションの真のハッシュを含むという証明を含み、
前記第4ゼロ知識証明は、前記第2ハッシュが前記第2エンティティに関連する前記以前のデータトランザクションの前記真のハッシュを含むという証明を含む、請求項20に記載のデータトランザクションレコーディング方法。
【請求項22】
前記第2エンティティに関連する前記以前のデータトランザクションは、前記第1データトランザクションである、請求項20又は請求項21に記載のデータトランザクションレコーディング方法。
【請求項23】
前記第1エンティティ及び前記第2エンティティの少なくとも一方の識別子と前記ハッシュのそれぞれを関連づけるステップをさらに含む、請求項1乃至請求項22のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項24】
前記第1ハッシュを再算出するステップと、
マッチング(match)を決定するために前記生成された第1ハッシュを前記再算出された第2ハッシュと比較するステップと、
をさらに含む、請求項1乃至請求項23のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項25】
前記比較が不成功である場合、追加データトランザクションを取り消すステップをさらに含む、請求項24に記載のデータトランザクションレコーディング方法。
【請求項26】
前記第1データトランザクションに対応するシステムハッシュをシステムデバイスに生成するステップをさらに含む、請求項1乃至請求項25のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項27】
第2シードデータを提供するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記システムハッシュを結合するステップをさらに含む、請求項26に記載のデータトランザクションレコーディング方法。
【請求項28】
前記システムハッシュは、前記システムデバイス上の以前のデータトランザクションのレコードをハッシュした結果である、請求項26又は請求項27に記載のデータトランザクションレコーディング方法。
【請求項29】
第2シードデータを提供するステップは、
ライセンスデバイスからライセンスハッシュを受信するステップと、
前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記ライセンスハッシュを結合するステップと、
をさらに含む、請求項1乃至請求項28のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項30】
前記ライセンスデバイスにおいて、
前記第1ハッシュを受信するステップと、
ライセンス入力を提供するために前記ライセンスハッシュと前記第1ハッシュを結合するステップと、
前記ライセンス入力をハッシュして第2ライセンスハッシュを生成するステップと、
をさらに含む、請求項29に記載のデータトランザクションレコーディング方法。
【請求項31】
第2シードデータを提供するステップは、
ディレクトリデバイスからディレクトリハッシュを受信するステップと、
前記第2シードデータを提供するために、前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記ディレクトリハッシュを結合するステップと、
をさらに含む、請求項1乃至請求項30のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項32】
前記ディレクトリサーバにおいて、
前記第1ハッシュを受信するステップと、
ディレクトリ入力を提供するために前記ディレクトリハッシュと前記第1ハッシュを結合するステップと、
前記ディレクトリ入力をハッシュして第2ディレクトリハッシュを生成するステップと、
をさらに含む、請求項31に記載のデータトランザクションレコーディング方法。
【請求項33】
第2シードデータを提供するステップは、
前記第1データトランザクションに対する暗号化キーからキーハッシュを生成するステップと、
前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記キーハッシュを結合するステップと、
をさらに含む、請求項1乃至請求項32のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項34】
前記暗号化キーは、公開キー又は個人キーを含む、請求項33に記載のデータトランザクションレコーディング方法。
【請求項35】
前記第1シードデータ及び前記第1データトランザクションの前記レコードを結合するステップは、前記第1データトランザクションが完了するとすぐに実行される、請求項1乃至請求項34のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項36】
前記メモリは遠隔デバイスに位置する、請求項1乃至請求項35のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項37】
他のデバイスから受信されたハッシュに対応する前記第1ハッシュを前記遠隔デバイスで比較するステップをさらに含む、請求項36に記載のデータトランザクションレコーディング方法。
【請求項38】
前記デバイスに接続された他のデバイスに前記第1ハッシュを受信することを予想するよう通知するステップをさらに含む、請求項36又は請求項37に記載のデータトランザクションレコーディング方法。
【請求項39】
前記メモリにハッシュのチェーンを格納するステップをさらに含む、請求項1乃至請求項38のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項40】
送信された前記ハッシュのチェーンに対するアクセスを制限するように構成されたデバイス上に位置する第2メモリに前記ハッシュのチェーンを送信するステップをさらに含む、請求項39に記載のデータトランザクションレコーディング方法。
【請求項41】
前記ハッシュのチェーンでハッシュを修正又は削除するステップをさらに含み、
前記ハッシュのチェーンでハッシュを修正又は削除するステップは、
前記ハッシュのチェーンで対象のハッシュを再生成するステップと、
前記レコードが修正されていないかの有無を確認するステップと、
前記再生成されたハッシュをレコーディングするステップと、
前記レコードを修正又は削除するステップと、
前記対象のハッシュの結合及び前記修正および削除されたレコードをハッシュして前記レコードに対する新しいハッシュを生成するステップと、
前記新しいハッシュをレコーディングするステップと、
を含む、請求項39は請求項40に記載のデータトランザクションレコーディング方法。
【請求項42】
前記新しいハッシュを用いてシステムハッシュを生成するステップをさらに含む、請求項41に記載のデータトランザクションレコーディング方法。
【請求項43】
第1エンティティに関連するデバイスにおいて、前記デバイスは、請求項1乃至請求項42のいずれか一項に記載の方法を実行するデバイス。
【請求項44】
前記デバイスはサーバを含む、請求項43に記載のデバイス。
【請求項45】
前記デバイスはユーザデバイスを含む、請求項43に記載のデバイス。
【請求項46】
前記ユーザデバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネット(IoT)可能デバイスのうち少なくとも1つを含む、請求項45に記載のデバイス。
【請求項47】
前記ユーザデバイスは、前記デバイス上のメモリで前記第1ハッシュを格納する、請求項46に記載のデバイス。
【請求項48】
前記ユーザデバイスは、該当サーバからオフラインである場合にのみ、前記デバイス上のメモリで前記第1ハッシュを格納する、請求項47に記載のデバイス。
【請求項49】
前記デバイスは、前記第2エンティティに関連するデバイスに前記第1ハッシュを送信する、請求項43乃至請求項48のいずれか一項に記載のデバイス。
【請求項50】
前記デバイスは、前記第1データトランザクションの前記レコードの署名及び暗号化されたコピーを前記第2エンティティに関連する前記デバイスに送信し、
前記署名は、前記第1データトランザクションの前記レコードに対する配信先サーバの指示(indication)を含む、請求項49に記載のデバイス。
【請求項51】
前記デバイスは、特定のオフライン公開キーで前記レコードにサインする、請求項50に記載のデバイス。
【請求項52】
前記デバイスは、前記デバイスに属するキーで前記レコードにサインする、請求項50に記載のデバイス。
【請求項53】
前記配信先サーバのみが前記第1データトランザクションの前記レコードの前記暗号化されたコピーを解読できる、請求項50乃至請求項52のいずれか一項に記載のデバイス。
【請求項54】
前記デバイスが、対応するサーバへの接続を回復するとき、前記デバイスは、前記関連するハッシュ及びそのオフラインデータトランザクションの前記暗号化されたレコードを対応するサーバに送信する、請求項48乃至請求項53のいずれか一項に記載のデバイス。
【請求項55】
前記デバイスは、自身が保有する他のエンティティに関連するデータトランザクションのレコードのコピーを前記他のエンティティに対応するサーバへの送信のために自身に対応するサーバに送信する、請求項54に記載のデバイス。
【請求項56】
前記送信することは、前記レコードが適用される全てのサーバに前記レコードを受信することを期待して通知することを含む、請求項55に記載のデバイス。
【請求項57】
前記デバイスは、前記第1データトランザクションでこの部分を識別するために固有の内部トランザクション番号を生成する、請求項43乃至請求項56のいずれか一項に記載のデバイス。
【請求項58】
ライセンスデバイスであって、
第1エンティティに関連するデバイスから第1ハッシュを受信することであって、前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む、前記第1ハッシュを受信すること、
ライセンス入力を提供するためにライセンスハッシュと前記第1ハッシュを結合すること、
前記ライセンス入力をハッシュして第2ライセンスハッシュを生成すること、
メモリに前記第2ライセンスハッシュを格納すること、を行うように構成されたライセンスデバイス。
【請求項59】
ディレクトリデバイスであって、
第1エンティティに関連するデバイスから第1ハッシュを受信することであって、前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む、前記第1ハッシュを受信すること、
ディレクトリ入力を提供するためにディレクトリハッシュと前記第1ハッシュを結合すること、
前記ライセンス入力をハッシュして第2ディレクトリハッシュを生成すること、
メモリに前記第2ディレクトリハッシュを格納すること、を行うように構成されたディレクトリデバイス。
【請求項60】
実行されるときコンピューティングデバイスが請求項1乃至請求項42のいずれか一項に記載の方法を実行させる複数のコード部分を含むコンピュータ可読記録媒体。
【請求項61】
デバイスから第1サービスにアクセスする方法において、
要求サーバに前記デバイスの識別子を提供するステップと、
前記識別子に基づいて前記デバイスが前記第1サービスに対するアクセスを要求することを許可するステップと、
前記デバイスが前記第1サービスが位置する第1ホストサーバから前記第1サービスにアクセスさせるステップであって、前記アクセスは、前記要求サーバを介して行われる、前記第1サービスにアクセスさせるステップと、
を含む方法。
【請求項62】
前記許可するステップは、前記識別子に基づいて前記ユーザデバイスが前記第1サービスにアクセスするように許可されるかを確認するステップを含む、請求項61に記載の方法。
【請求項63】
確認するステップは、前記識別子に基づいて前記ユーザが少なくとも1つの基準(criteria)を満足するかを確認するステップを含む、請求項62に記載の方法。
【請求項64】
第1基準が前記第1ホストサーバ又は前記要求サーバに格納され、第2基準が他のサーバに位置する、請求項63に記載の方法。
【請求項65】
前記許可するステップは、前記要求サーバ及び前記第1ホストサーバ間の通信に対する署名を検証するステップを含む、請求項61乃至請求項64のいずれか一項に記載の方法。
【請求項66】
前記許可するステップは前記要求サーバで実行される、請求項61乃至請求項65のいずれか一項に記載の方法。
【請求項67】
前記許可するステップは、前記要求サーバで前記デバイスが前記第1サービスにアクセスするように以前に許可されたかを決定するステップを含む、請求項66に記載の方法。
【請求項68】
前記許可するステップはディレクトリサーバで実行される、請求項61乃至請求項65のいずれか一項に記載の方法。
【請求項69】
前記許可するステップは、前記要求サーバが前記ディレクトリサーバから前記デバイスに対する許可を要求するステップを含む、請求項68に記載の方法。
【請求項70】
前記アクセスさせるステップは、前記ディレクトリサーバが前記第1ホストサーバに対する識別子を前記要求サーバに送信するステップを含む、請求項68又は請求項69に記載の方法。
【請求項71】
前記識別子を許可するデータは、前記ディレクトリサーバに格納される、請求項68乃至請求項70のいずれか一項に記載の方法。
【請求項72】
第2サービスに対するアクセスを要求するステップと、
前記識別子に基づいて前記デバイスが前記第2サービスにアクセスすることを許可するステップと、
前記デバイスが前記要求サーバを介して前記第2サービスにアクセスさせるステップと、
をさらに含む、請求項61乃至請求項71のいずれか一項に記載の方法。
【請求項73】
前記第2サービスは前記第1ホストサーバに位置する、請求項72に記載の方法。
【請求項74】
前記第2サービスは第2ホストサーバに位置する、請求項72に記載の方法。
【請求項75】
前記デバイスが前記第1サービスにアクセスすることを許可するステップは、第1ディレクトリサーバで実行され、
前記ユーザデバイスが前記第2サービスにアクセスすることを許可するステップは、第2ディレクトリサーバで実行される、請求項72乃至請求項74のいずれか一項に記載の方法。
【請求項76】
第3サービスに対するアクセスを要求するステップと、
前記識別子に基づいて前記デバイスが前記第3サービスにアクセスすることを許可するステップと、
前記デバイスが前記第3サービスにアクセスさせるステップと、
をさらに含む、請求項72乃至請求項75のいずれか一項に記載の方法。
【請求項77】
前記第2サービスは、前記第1ホストサーバ、前記第2ホストサーバ又は第3ホストサーバに位置する、請求項76に記載の方法。
【請求項78】
前記デバイスが前記第3サービスにアクセスすることを許可するステップは、第3ディレクトリサーバで実行される、請求項76又は請求項77に記載の方法。
【請求項79】
識別子を提供するステップは、前記デバイスが暗号化されたトンネルを介して前記要求サーバと通信するステップを含む、請求項61乃至請求項78のいずれか一項に記載の方法。
【請求項80】
それぞれの個別サーバで受信されるデータをキャッシュするステップをさらに含む、請求項61乃至請求項79のいずれか一項に記載の方法。
【請求項81】
それぞれのホストサーバは、二以上のサービスを提供する、請求項61乃至請求項80のいずれか一項に記載の方法。
【請求項82】
請求項61乃至請求項81のいずれか一項に記載の方法を実行するデバイス。
【請求項83】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、請求項82に記載のデバイス。
【請求項84】
実行されるとき、コンピュータデバイスが請求項61乃至請求項81のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【請求項85】
第1データストアーから第2データストアーに第1データをスイッチングするための要求を提供するステップと、
前記要求に含まれた識別子に基づいて前記第1データストアーの識別子をディレクトリサーバから決定するステップと、
前記第1データストアーから前記第2データストアーに前記第1データをマイグレーションするステップと、
を含むデータマイグレーション方法。
【請求項86】
前記マイグレーションするステップは、前記ディレクトリサーバにおいて、
前記第2データストアーで前記データに対する開始タイムスタンプを割り当てるステップと、
前記第1データストアーで前記データに対する終了タイムスタンプを割り当てるステップと、
を含む、請求項85に記載のデータマイグレーション方法。
【請求項87】
前記終了タイムスタンプの後に、前記第1データストアーを介して前記データにアクセスしようと試みる要求サーバに、前記ディレクトリサーバを介して前記第2データストアーで前記ユーザを検索するように指示するステップをさらに含む、請求項86に記載のデータマイグレーション方法。
【請求項88】
前記第1データストアーにおける前記データは、第1アカウント提供者との第1アカウント登録を含み、
前記第2データストアーにおける前記データは、新しいアカウント提供者との第2アカウント登録を含む、請求項85乃至請求項87のいずれか一項に記載のデータマイグレーション方法。
【請求項89】
前記マイグレーションするステップは、前記現在のアカウント提供者から前記新しいアカウント提供者に前記第1アカウント登録に関する情報を送信するステップを含む、請求項88に記載のデータマイグレーション方法。
【請求項90】
前記情報は、登録(registrations)、残額(balances)、コンフィギュレーション(configurations)及び支払い指示(payment instructions)のうち少なくとも1つを含む、請求項89に記載のデータマイグレーション方法。
【請求項91】
マイグレーションするステップは、前記第1登録が前記現在のアカウント提供者から前記新しいアカウント提供者にスイッチされなければならないことを示す認証コード(authentication code)を確認するステップを含む、請求項88乃至請求項90のいずれか一項に記載のデータマイグレーション方法。
【請求項92】
前記第1アカウント登録は第1ユーザ・クリデンシャルを含み、
前記第2アカウント登録は第2ユーザ・クリデンシャルを含む、請求項88乃至請求項91のいずれか一項に記載のデータマイグレーション方法。
【請求項93】
前記第1ユーザ・クリデンシャルは第1サーバに登録され、
前記第2ユーザ・クリデンシャルは第2サーバに登録される、請求項92に記載のデータマイグレーション方法。
【請求項94】
前記第1アカウント提供者によって前記第1ユーザ・クリデンシャルを用いてユーザに伝えられる通信を受信するステップと、
前記第2ユーザ・クリデンシャルを用いて前記通信を前記第2アカウント提供者にルーティングするステップと、
をさらに含む、請求項93に記載のデータマイグレーション方法。
【請求項95】
前記第1クリデンシャルを使用する前記第1登録提供者で作られたデータトランザクションを、前記第2ユーザ・クリデンシャルを使用する前記第2登録提供者に反転させるステップをさらに含む、請求項93又は請求項94に記載のデータマイグレーション方法。
【請求項96】
前記トランザクション時に前記ユーザが前記第1ユーザ・クリデンシャルを使用したことを決定するステップを含む、請求項95に記載のデータマイグレーション方法。
【請求項97】
前記通信を送信するサーバは、前記第2ユーザ・クリデンシャルにアクセスするように承認されなければならない、請求項94乃至請求項96のいずれか一項に記載のデータマイグレーション方法。
【請求項98】
前記第1ユーザ・クリデンシャル及び前記第2ユーザ・クリデンシャルは同一である、請求項92乃至請求項97のいずれか一項に記載のデータマイグレーション方法。
【請求項99】
請求項85乃至請求項98のいずれか一項に記載の方法を実行するデバイス。
【請求項100】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、請求項99に記載のデバイス。
【請求項101】
実行されるとき、コンピュータデバイスが請求項85乃至請求項98のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【請求項102】
第1エンティティから第2エンティティに第1通信を送信するステップであって、前記第1通信は2つ以上のデータフィールドを含み、それぞれのフィールドは個別ラベルを含む、前記第1通信を送信するステップと、
前記第1エンティティから前記第2エンティティに第2通信を送信するステップであって、前記第2通信は前記2つ以上のデータフィールドを含み、前記第2通信における前記2つ以上のデータフィールドの順は、前記第1通信における前記2つ以上のデータフィールドの順と異なる、前記第2通信を送信するステップと、
を含む通信方法。
【請求項103】
ランダムフィールドを前記第2通信に追加するステップをさらに含む、請求項102に記載の通信方法。
【請求項104】
それぞれのフィールドは2つ以上の特徴を含み、
少なくとも1つのフィールドで2つ以上の特徴のケースをミキシングするステップをさらに含む、請求項102又は請求項103に記載の通信方法。
【請求項105】
前記第2通信を処理する前に、前記第2エンティティによって前記第2通信で前記フィールドを解読及び順序化するステップをさらに含む、請求項102乃至請求項104のいずれか一項に記載の通信方法。
【請求項106】
前記第2エンティティによって処理できないフィールドを廃棄するステップをさらに含む、請求項105に記載の通信方法。
【請求項107】
前記1エンティティ及び前記第2エンティティのうち少なくとも1つはサーバを含む、請求項102乃至請求項106のいずれか一項に記載の装置。
【請求項108】
前記1エンティティ及び前記第2エンティティのうち少なくとも1つは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスを含む、請求項102乃至請求項106のいずれか一項に記載の装置。
【請求項109】
請求項102乃至請求項108のいずれか一項に記載の方法を実行するデバイス。
【請求項110】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、請求項109に記載のデバイス。
【請求項111】
実行されるとき、コンピュータデバイスが請求項102乃至請求項108のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【請求項112】
USSD(unstructured supplementary service data)を介した通信方法において、
第1デバイスと第2デバイスとの間のUSSDセッションを開放するステップと、
前記第1デバイスにおいて前記セッションで通信に対するサイファーテキスト(cypher text)を生成するステップと、
前記第1デバイスで前記サイファーテキストを符号化するステップと、
前記第2デバイスで解読のために前記第1デバイスから前記第2デバイスに前記符号化されたサイファーテキストを送信するステップと、
を含む通信方法。
【請求項113】
前記符号化するステップは、前記サイファーテキストを7ビット又は8ビットの文字ストリングに符号化するステップを含む、請求項112に記載の通信方法。
【請求項114】
前記サイファーテキストの長さが前記USSDセッションで前記許容されたスペースよりも長い場合、
前記サイファーテキストを2つ又は2つ以上の部分に分割するステップと、
前記2つ又は2つ以上の部分を個別的に送信するステップと、
をさらに含む、請求項112又は請求項113に記載の通信方法。
【請求項115】
前記第2デバイスにおける解読のために、前記第2デバイスから前記サイファーテキストの全体に前記パートをリアセンブルするステップを含む、請求項114に記載の通信方法。
【請求項116】
前記1及び第2デバイスを認証するステップをさらに含む、請求項112乃至請求項115のいずれか一項に記載の通信方法。
【請求項117】
認証するステップは、2つの通信コンピュータアプリケーション間のプライバシー及びデータ無欠性を提供するアルゴリズムを使用するステップを含む、請求項116に記載の通信方法。
【請求項118】
認証するステップは、TLS(transport layersecurity)を使用するステップを含む、請求項117に記載の通信方法。
【請求項119】
TLSを使用するステップは、第1セッションキーを生成するステップを含む、請求項118に記載の通信方法。
【請求項120】
第2セッションキーを生成するためにPAKEプロトコルネゴシエーション(PAKE
protocol negotiation)を暗号化する前記第1セッションキーを使用するステップと、
前記第2セッションキーを用いて前記第1デバイスと前記第2デバイスとの間の前記セッションで追加通信を暗号化するステップと、
をさらに含む、請求項119に記載の通信方法。
【請求項121】
請求項112乃至請求項120のいずれか一項に記載の方法を実行するデバイス。
【請求項122】
実行されるとき、コンピュータデバイスが請求項112乃至請求項120のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【請求項123】
第1エンティティに関連する第1デバイスと第2エンティティに関連する第2デバイスとの間の通信方法において、前記第1デバイスで、
第1共有秘密を用いて前記第1デバイス及び前記第2デバイス間の第1PAKEセッションを生成するステップと、
前記第2デバイスから登録キー及び第2共有秘密を受信するステップと、
第2PAKEセッションを生成するための第3共有秘密を提供するために、前記第1共有秘密、前記登録キー、及び前記第2共有秘密をハッシュするステップと、
を含む通信方法。
【請求項124】
前記1エンティティ及び前記第2エンティティを認証するステップをさらに含む、請求項123に記載の通信方法。
【請求項125】
認証するステップは、2つの通信コンピュータアプリケーション間のプライバシー及びデータ無欠性を提供するアルゴリズムを使用するステップを含む、請求項124に記載の通信方法。
【請求項126】
前記認証するステップはTLSを使用するステップを含む、請求項125に記載の通信方法。
【請求項127】
第4共有秘密を用いて前記第1デバイス及び第3デバイス間の第2PAKEセッションを生成するステップをさらに含む、請求項123乃至請求項126のいずれか一項に記載の通信方法。
【請求項128】
前記第4共有秘密は、前記第1デバイスのために前記第3デバイスによって生成された認証コードを含む、請求項127に記載の通信方法。
【請求項129】
前記第1共有秘密は、前記第1デバイスのために前記第2デバイスによって生成された認証コードを含む、請求項123乃至請求項128のいずれか一項に記載の通信方法。
【請求項130】
前記認証コードは、前記第1デバイスのために識別子と共に前記第1デバイスに送信される、請求項129に記載の通信方法。
【請求項131】
前記識別子は、前記第1デバイスの電話番号又はシリアル番号を含む、請求項130に記載の通信方法。
【請求項132】
前記第1共有内緒は、前記1エンティティに関連する銀行カードのPAN(personal account number)を含む、請求項123乃至請求項131のいずれか一項に記載の通信方法。
【請求項133】
前記第1共有秘密は、前記1エンティティに関連する銀行カードの符号化されたシリアル番号を含む、請求項123乃至請求項131のいずれか一項に記載の通信方法。
【請求項134】
請求項123乃至請求項133のいずれか一項に記載の方法を実行するデバイス。
【請求項135】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、請求項134に記載のデバイス。
【請求項136】
実行されるとき、コンピュータデバイスが請求項123乃至請求項133のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【請求項137】
サービスにアクセスする方法において、
クリデンシャル及び前記クリデンシャルに対するコンテキストを提供するステップと、
前記クリデンシャル及び前記コンテキストに基づいて前記サービスに対するアクセスを認証するステップと、
を含む方法。
【請求項138】
前記サービスに対するアクセスを認証するステップは、
前記クリデンシャル及び前記コンテキストのうちの少なくとも一方に基づいてサービスの一部に対するアクセスを認証するステップを含む、請求項137に記載の方法。
【請求項139】
前記クリデンシャルは、デバイス及び前記デバイスのプライマリユーザ(primary user)に関連する第1クリデンシャルを含む、請求項137又は請求項138に記載の方法。
【請求項140】
前記クリデンシャルは、デバイス及び前記デバイスのセカンダリーユーザに関連する第2クリデンシャルをさらに含む、請求項139に記載の方法。
【請求項141】
前記クリデンシャルに基づいて前記サービスに対するアクセスを認証するステップは、前記第1クリデンシャル及び前記第2クリデンシャルのそれぞれに基づいて前記プライマリユーザ及び前記セカンダリーユーザに対する異なるサービスに対するアクセスを認証するステップを含む、請求項140に記載の方法。
【請求項142】
前記デバイスは、前記プライマリユーザ及び前記セカンダリーユーザに対する異なる支出限度である前記異なるサービス及び銀行カードを含む、請求項141に記載の方法。
【請求項143】
前記クリデンシャルは、前記コンテキストに基づいて選択される、請求項137乃至請求項142のいずれか一項に記載の方法。
【請求項144】
前記サービスは、前記コンテキストに基づいて選択された複数のサービスを含む、請求項137乃至請求項143のいずれか一項に記載の方法。
【請求項145】
管理者又はユーザは、前記コンテキスト又はクリデンシャルを修正、追加又は取り消しできる、請求項137乃至請求項144のいずれか一項に記載の方法。
【請求項146】
前記クリデンシャルは、パスワード、PIN、及び他の直接認証クリデンシャル(direct authentication credential)のうち少なくとも1つを含む、請求項137乃至請求項145のいずれか一項に記載の方法。
【請求項147】
前記コンテキストは、前記クリデンシャルを提供するデバイス、前記デバイス上のアプリケーション、前記デバイスが接続されたネットワーク、前記デバイスの地理的位置、及びアクセスされる前記サービスのうち少なくとも1つを含む、請求項137乃至請求項146のいずれか一項に記載の方法。
【請求項148】
請求項137乃至請求項147のいずれか一項に記載の方法を実行するデバイス。
【請求項149】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、請求項148に記載のデバイス。
【請求項150】
実行されるとき、コンピュータデバイスが請求項137乃至請求項147のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【請求項151】
コンピュータシステム内の複数のモジュール間の通信方法において、
第1モジュールからプロキシに共有メモリチャネルを伝達するステップと、
前記プロキシから第2モジュールに前記共有メモリチャネルを伝達するステップであって、前記プロキシは、前記コンピュータシステムの前記カーネルをバイパスして前記第1モジュールと前記第2モジュールとの間のデータを送信するハンドオフモジュールを含む、前記共有メモリチャネルを伝達するステップと、
前記第1モジュールから前記第2モジュールにデータを送信するステップと、
を含む通信方法。
【請求項152】
複数の要求を前記第1モジュールのバッファメモリでバッチされたメッセージ(batched message)にバッチするステップと、
前記第2モジュールに送信される前記バッチされたメッセージをキューイングするステップと、
システム機能を許可する少なくとも1つのシステムフラグをセッティングするステップと、
前記第2モジュールで前記少なくとも1つのシステムフラグをチェックするステップと、
前記第2モジュールで前記バッチされたメッセージを処理するステップと、
をさらに含む、請求項151に記載の通信方法。
【請求項153】
前記第1モジュールと前記第2モジュールとの間の少なくとも1つの共有メモリチャネルを設定するステップをさらに含む、請求項151又は請求項152に記載の通信方法。
【請求項154】
前記少なくとも1つの共有メモリチャネルを介して前記第1モジュールに応答する前記第2モジュールを含む、請求項153に記載の通信方法。
【請求項155】
前記少なくとも1つの共有メモリチャネルは、前記バッチされたメッセージを受信及びアセンブルし、前記第2モジュールに前記メモリの所有権を渡す、請求項153又は請求項154に記載の通信方法。
【請求項156】
前記少なくとも1つの共有メモリチャネルは、前記コンピュータシステムのネットワークスタック(network stack)を介してバッチされたメッセージを受信する、請求項155に記載の通信方法。
【請求項157】
前記少なくとも1つの共有メモリチャネルは、HTTPゲートウェイを含む、請求項153乃至請求項156のいずれか一項に記載の通信方法。
【請求項158】
HTTPゲートウェイはウェブサービスとして用いられる、請求項151乃至請求項157のいずれか一項に記載の通信方法。
【請求項159】
通信は、パスワード認証されたキー交換プロトコルを使用する、請求項151乃至請求項158のいずれか一項に記載の通信方法。
【請求項160】
前記コンピュータシステムのネットワークスタックでゼロコピーネットワーキング(zero-copy networking)を使用するステップをさらに含む、請求項151乃至請求項159のいずれか一項に記載の通信方法。
【請求項161】
前記コンピュータシステムのネットワークスタックでユーザモードネットワーキングを使用するステップをさらに含む、請求項151乃至請求項160のいずれか一項に記載の通信方法。
【請求項162】
前記第1モジュールから前記データ送信の前記コンポーネントが単一データストリームに結合され、前記第1モジュールで前記コンポーネントに分離されるようにデータを直列化するステップをさらに含む、請求項151乃至請求項161のいずれか一項に記載の通信方法。
【請求項163】
前記直列化は、各モジュールのエッジで抽象化される、請求項162に記載の通信方法。
【請求項164】
各モジュールのバッファメモリは、構成可能なバッファリング閾値を有する、請求項151乃至請求項163のいずれか一項に記載の通信方法。
【請求項165】
前記第1モジュール及び前記第2モジュールは、同じコンピューティングデバイス上に位置する、請求項151乃至請求項164のいずれか一項に記載の通信方法。
【請求項166】
前記第1モジュール及び前記第2モジュールは、異なるコンピューティングデバイス上に位置する、請求項151乃至請求項164のいずれか一項に記載の通信方法。
【請求項167】
前記第1モジュールから前記第2モジュールに送信されたデータはバージョンIDを運ぶ、請求項151乃至請求項166のいずれか一項に記載の通信方法。
【請求項168】
前記バージョンIDが前記第1モジュールから前記第2モジュールに送信された前記データに対して、最新であるかを検証するステップをさらに含む、請求項167に記載の通信方法。
【請求項169】
前記データのうち任意のデータがアップデートされる場合、前記バージョンIDを現在のバージョンに再検証するステップをさらに含む、請求項168に記載の通信方法。
【請求項170】
前記バージョンIDが検証されない場合、前記データ送信は失敗する、請求項169に記載の通信方法。
【請求項171】
前記第1モジュール及び前記第2モジュールのうち少なくとも1つは少なくとも1つのデータサービスモジュールを含み、
前記コンピュータシステム内の各データ処理は、前記少なくとも1つのデータサービスモジュールを介して実行される、請求項151乃至請求項170のいずれか一項に記載の通信方法。
【請求項172】
前記少なくとも1つのデータサービスモジュールは、コアデータベースストアーによって実現されるデータストアーと通信する、請求項171に記載の通信方法。
【請求項173】
前記少なくとも1つのデータサービスモジュールは、前記データストアーに直接アクセスする前記コンピュータシステムのコンポーネントである、請求項172に記載の通信方法。
【請求項174】
前記コアデータベースストアーは、少なくとも1つの分散データベースを含む、請求項173に記載の通信方法。
【請求項175】
前記少なくとも1つの分散データベースは、別途の読み出し及び記録アクセスチャネルを有する、請求項174に記載の通信方法。
【請求項176】
前記データストアーは、少なくとも1つの異種データベースにインタフェースを提供する、請求項173乃至請求項175のいずれか一項に記載の通信方法。
【請求項177】
前記データストアーは、複数のインタフェースタイプを提供する、請求項173乃至請求項176のいずれか一項に記載の通信方法。
【請求項178】
前記複数のインタフェースタイプは、少なくとも1つのSQL(Structured Query Language)インタフェース、セル及びコラムインタフェース(cell and column interface)、文書インタフェース(document interface)、及び前記コアデータベースストアー上にあるグラフィックインタフェース(graph interface)のうち少なくとも1つを含む、請求項177に記載の通信方法。
【請求項179】
前記データストアーレイヤに対する全ての記録は、1つ又は1つ以上のデータトランザクションの全て又は一部を制御する単一共有モジュールによって管理される、請求項176乃至請求項178のいずれか一項に記載の通信方法。
【請求項180】
少なくとも1つの前記共有モジュールのリダンダント・バックアップ(redundant backup)を作動させるステップをさらに含む、請求項179に記載の通信方法。
【請求項181】
全てのデータ変更は、シリアルの速いシーケンス(serial rapid sequence)で前記単一共有モジュールを介して行われる、請求項179又は請求項180に記載の通信方法。
【請求項182】
前記単一共有モジュールは、その自体をデータ・トランザクタ・クラスタ(data transactor cluster)に示すホットバックアップ・リダンダンシー・モデル(hot backup redundancy model)を使用し、
前記データ・トランザクタ・クラスタは、ハイアラーキー(hierarchy)で1組のモジュールであり、各モジュールは、マスタモジュールが失敗する場合にデータトランザクションを制御する、請求項179乃至請求項181のいずれか一項に記載の通信方法。
【請求項183】
ドメインによって構成される規則に基づいて、複数のモジュール又は複数のデータストアーにわたってデータを分割するステップをさらに含む、請求項171乃至請求項182のいずれか一項に記載の通信方法。
【請求項184】
データトランザクションのレコード又は親データトランザクション(parent data transaction)のレコードのターゲットデータをハッシュするステップをさらに含む、請求項183に記載の通信方法。
【請求項185】
前記ハッシュするステップは、データパーティションの数と同じカーディナリティ(cardinality)を有する、請求項184に記載の通信方法。
【請求項186】
挙げられた地理的領域、名字、及び通貨のうち少なくとも1つによってターゲットデータをハッシュするステップをさらに含む、請求項184又は請求項185に記載の通信方法。
【請求項187】
複数のデータパーティションの全てに前記少なくとも1つのデータサービスモジュールを介して少なくとも1つのデータ送信を行うステップをさらに含む、請求項171乃至請求項186のいずれか一項に記載の通信方法。
【請求項188】
複数のモジュールによって前記少なくとも1つのデータサービスモジュールを介して少なくとも1つのデータ送信を完了するステップをさらに含む、請求項171乃至請求項187のいずれか一項に記載の通信方法。
【請求項189】
前記少なくとも1つのデータサービスモジュール上の少なくとも1つのデータ送信を前記データストアーで複数のデータストレージノード上に保持するステップをさらに含む、請求項171乃至請求項188のいずれか一項に記載の通信方法。
【請求項190】
前記コンピュータシステムは、複数のデータサービスモジュールを含み、
それぞれのデータサービスモジュールは、該当インスタンスに対する全ての前記ホットデータのキャッシュされた表現を含み、イン-メモリ(in-memory)またはイン-プロセス(in-process)データベースエンジンをホストする、請求項171乃至請求項189のいずれか一項に記載の通信方法。
【請求項191】
前記コンピュータシステムは、複数のデータサービスモジュールを含み、
それぞれのデータサービスモジュールは、複数の異種又は同種データベースエンジンを含む、請求項171乃至請求項189のいずれか一項に記載の通信方法。
【請求項192】
全てのデータ読み出しが一貫し、対応するデータ記録を反映するように、前記データストアーに対するアクセスの同時性を管理するMVCC(Multiversion Concurrency Control)バージョンシステムを使用するステップをさらに含む、請求項172乃至請求項191のいずれか一項に記載の通信方法。
【請求項193】
データレコードが前記データストアーに記録され、任意の後続データトランザクションが前記データレコードにアクセスする前に記録されたことが確認されるように、前記データストアーに対するアクセスの同時性を管理する悲観的一貫性(pessimistic consistency)を使用するステップをさらに含む、請求項172乃至請求項191のいずれか一項に記載の通信方法。
【請求項194】
前記コンピュータシステムは、アプリケーションレイヤをさらに含み、
前記少なくとも1つのデータサービスモジュールが前記レコードを記録し、前記データ送信を完了することを確認するまで、前記アプリケーションレイヤは、データトランザクションを進めることができない、請求項171乃至請求項193のいずれか一項に記載の通信方法。
【請求項195】
請求項151乃至請求項194のいずれか一項に記載の方法を実行するコンピューティングデバイス。
【請求項196】
実行されるときコンピュータデバイスが請求項151乃至請求項194のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、単一の実施において全てのタイプのトランザクションを大規模かつ安全にリアルタイムで行う方法及びシステムに関する。
【背景技術】
【0002】
トランザクション処理には、広範囲な分散コンピュータ基盤システム及び、特に、支払いに関するトランザクションを行う多重ランザクション(transactors)を含むだけではなく、他の金融資産及び取引、物理的アクセス制御、データに対する論理的アクセス、IoT(Internet of Things)を構成する管理、及びモニタリングデバイスなどにおけるトレード(trade)に関する。
【0003】
最近、トランザクション処理システムを開発するとき、エンジニアは難しいトレードオフ(trade-offs)を行わなければならない。これは速度及び回復力、処理量と一貫性、セキュリティーと性能、一貫性と拡張性などの間の選択が含まれる。このようなトレードオフは、常にシステム全体に影響を及ぼす侵害(compromises)を発生させる。支払い処理システムは、このようなトレードオフの効果を示す。それは1秒当たり600から数万のトランザクションを処理しなければならないこともあるが、ひたすらシステムの業務量において、しばらくの間に追加的な処理のためにそれを部分処理し、詳細を格納するだけであった。これはたびたび紛失したレコードを調整し、トランザクションを重複し、トランザクション時間からトランザクション処理時間までにアカウントが超過して引き落されるという信用問題の露出などといった問題を発生させる。しかし、問題は支払いに制限されない。
【0004】
全体的なトランザクションがロールバックされて(原子性)、データベースを一貫性のない状態にしておくことができず(一貫性)、互いに干渉できず(分離性)、さらにサーバが再び開始する時にも持続される(耐久性)場合、ACID(原子性、一貫性、分離性、及び耐久性)は、各データベーストランザクションが成功しなければならないというデータベースに対する一貫性モデルである。
【0005】
このモデルは、一般的に、既存の銀行支払いネットワーク及びその他の「ビッグデータ」の取引システムのような大規模システムの可用性及び性能要求事項と互換されないものと見なされる。代わりに、このようなシステムは、BASE一貫性(基本可用性)、ソフト状態、及び最終てきな一貫性に依存する。このモデルは、データベースが窮極的に一貫性のある状態に達することで充分であると主張する。銀行システムは、一貫性のある状態に達するために頻繁に調整チェックし、トランザクションの処理を一時中止しなければならないことから、このモードで作動する。トレードオフは大容量トランザクション処理で行われなければならないという概念は、基本的な形態で分散コンピュータシステムが一貫性、可用性、及びパーティション耐性(partition tolerance)といった3つの全てを同時に提供できない点を示すCAP整理に明示されている。現在のベスト思慮ソリューション(best practice solutions)は、新らに出現する現在の要件を満たすには多すぎる制限及びトレードオフを含んでいる。
【0006】
IoTによって生成されたデータを調整する方法に対する問題は、エンジニアがネットワーク及びトランザクション処理システムを構築するとき、それらを行う必要があると考えるトレードオフの効果によって発生する。その効果のうちの1つは、共にモノのインターネットを構成しているデバイスとサーバ間の通信に対するセキュリティーの欠如である。他の1つは、デバイスによって収集されたデータが実際に該当のデバイスにより検出された特定のイベントに関わっていることを保障できないことにある。
【0007】
また、クラウド基盤の情報格納システムは、このようなトレードオフの効果を示すが、多くの場合、究極的な一貫性のみを保障できる数多いサーバ及びシステムが膨大になる。
したがって、既知のシステムにおいて、BASE一貫性でのみ利益を取得できる大規模システムにACID一貫性を提供することが求められる。
【発明の概要】
【発明が解決しようとする課題】
【0008】
上述したように本発明は、現在のトレードオフによって考慮又は制限する必要のないトランザクションを処理する新しい方法に関する。本発明は、既存のシステムよりも数倍も大きい比率でトランザクションをリアルタイムに認証及び処理し、このようなトランザクションをリアルタイムに支払い又は処理及び完了する方法を提供する。
【0009】
リアルタイム支払いは、金融トランザクションにのみ適用されるものではない。これは即刻的な認証、許可、処理及び完了の一部又は全体から利益を取得できるか、求められる任意のトランザクションに適用される。これはアクセス制御からレコード有効性検査(records validation)、レコード及び文書交換(records and document exchange)、命令及び制御指示(command and control instructions)などに至るまで様々である。
【0010】
この方法は7種類の主な領域に構成される。
・任意のデータベース製品に極めて高いスケールでACID準拠のトランザクションを記録するための方法
・単一リアルタイムセッションの範囲内で極めて高いスケールで完全な数学的証明によりマルチプライベート元帳(multiple private ledgers)にわたってレコード認証を伝達するハッシュチェーンの実現
・拡張性問題を引き起こす「ハブ・アンド・スポーク(hub and spoke)」アーキテクチャーを実現するものではなく、トランザクションサービス提供者などのメッシュネットワークを支援するディレクトリサービス
・販売者又はユーザデバイスが無線及び1つのトランザクションから次にトランザクションを処理するために使用するアプリケーション(又は、アプリ)をアップデートさせる拡張可能なフレームワーク
・多様な相違なトランザクションタイプ及び共通データベース構造を支援するアプリ間の移動行列として機能するデータサービスレイヤ
・サービス又はデバイスがサービス又は機能のセットにアクセスさせるクリデンシャルのアッドホクセットをアセンブル及び提案する方法
・NFC(Near Field Communications)及びUSSD(Unstructured Supplementary Service Data)を含む任意のプロトコルで安全なリアルタイム通信を生成する方法
本発明のシステムは、処理方法のうち固有にトランザクション数が増加することによりゼロ増分コスト(zero incremental cost)でリアルタイムトランザクション処理及び完了を達成する方法を提供する。
【課題を解決するための手段】
【0011】
一実施形態に係る第1エンティティに関連するデバイスでデータトランザクションレコーディング方法は、第1シードデータを決定するステップと、前記第1エンティティと第2エンティティとの間の第1データトランザクションの前記レコードを生成するステップと、少なくとも前記第1シードデータ及び前記第1データトランザクションのレコードを結合して第2シードデータを決定するステップと、前記第2シードデータをハッシュして第1ハッシュを生成するステップ(前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む)と、前記第1データトランザクションの前記レコードに対する前記第1ハッシュをメモリに格納するステップとを含むデータトランザクションレコーディング方法が提供される。他の実施形態によれば、前記方法は実行し、第1エンティティに関連するデバイスが提供される。他の実施形態によれば、実行されるときコンピューティングデバイスが前記方法を実行させる複数のコード部分を含むコンピュータで可読記録媒体が提供される。
【0012】
他の実施形態によれば、第1エンティティに関連するデバイスから第1ハッシュを受信し(前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む)、ライセンス入力を提供するためにライセンスハッシュと前記第1ハッシュを結合し、前記ライセンス入力をハッシュして第2ライセンスハッシュを生成し、及びメモリに前記第2ライセンスハッシュを格納するライセンスデバイスを提供する。
【0013】
他の実施形態によれば、第1エンティティに関連するデバイスから第1ハッシュを受信し(前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む)、ディレクトリ入力を提供するためにディレクトリハッシュと前記第1ハッシュを結合し、前記ライセンス入力をハッシュして第2ディレクトリハッシュを生成し、及びメモリに前記第2ディレクトリハッシュを格納するディレクトリデバイスを提供する。
【0014】
他の実施形態によれば、デバイスから第1サービスにアクセスする方法は、要求サーバに前記デバイスの識別子を提供するステップと、前記識別子に基づいて前記デバイスが前記第1サービスに対するアクセスを要求することを許可するステップと、前記デバイスが前記第1サービスが位置する第1ホストサーバから前記第1サービスにアクセスさせるステップ(前記アクセスは、前記要求サーバを介して行われる)を含むアクセス方法が提供される。他の実施形態によれば、前記方法を行うデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0015】
他の実施形態によれば、第1データストアーから第2データストアーに第1データをスイッチングするための要求を提供するステップと、前記要求に含まれた識別子に基づいて前記第1データストアーの識別子をディレクトリサーバから決定するステップと、前記第1データストアーから前記第2データストアーに前記第1データを移行するステップを含むデータ移行方法が提供される。他の実施形態によれば、前記方法を行うデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0016】
他の実施形態によれば、第1エンティティから第2エンティティに第1通信(前記第1通信は2つ以上のデータフィールドを含み、それぞれのフィールドは、個別ラベルを含む)を送信するステップと、前記第1エンティティから前記第2エンティティに第2通信(前記第2通信は前記2つ以上のデータフィールドを含み、前記第2通信における前記フィールドの順は、前記第1通信における前記フィールドの順と異なる)を送信するステップを含む通信方法が提供される。他の実施形態によれば、前記方法を行うデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0017】
他の実施形態によれば、USSD(unstructured supplementary service data)を通した通信方法において、第1デバイスと第2デバイス間のUSSDセッションを開放するステップと、前記第1デバイスにおいて前記セッションで通信に対するサイファーテキスト(cypher text)を生成するステップと、前記第1デバイスで前記サイファーテキストを符号化するステップと、前記第2デバイスで解読のために前記第1デバイスから前記第2デバイスに前記符号化されたサイファーテキストを送信するステップとを含む通信方法が提供される。他の実施形態によれば、前記方法を行うデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0018】
他の実施形態によれば、第1エンティティに関連する第1デバイスと第2エンティティに関連する第2デバイス間の通信方法において、前記第1デバイスで、第1共有秘密を用いて前記第1デバイス及び前記第2デバイス間の第1PAKEセッションを生成するステップと、前記第2デバイスから登録キー及び第2共有秘密を受信するステップと、第2PAKEセッションを生成するための第3共有秘密を提供するために前記第1共有秘密、前記登録キー、及び前記第2共有秘密をハッシュするステップとを含む通信方法が提供される。他の実施形態によれば、前記方法を行うデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0019】
他の実施形態によれば、サービスにアクセスする方法において、クリデンシャル及び前記クリデンシャルに対するコンテキストを提供するステップと、前記クリデンシャル及び前記コンテキストに基づいて前記サービスに対するアクセスを認証するステップとを含むアクセス方法が提供される。他の実施形態によれば、前記方法を行うデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0020】
他の実施形態によれば、コンピュータシステム内のモジュール間の通信方法において、第1モジュールからプロキシに共有メモリチャネルを伝達するステップと、前記プロキシから第2モジュールに前記共有メモリチャネルを伝達するステップ(前記プロキシは、前記コンピュータシステムの前記カーネルをバイパスして前記第1モジュールと前記第2モジュールとの間のデータを送信するハンドオフモジュールを含む)と、前記第1モジュールから前記第2モジュールにデータを送信するステップとを含む通信方法が提供される。他の実施形態によれば、前記方法を行うコンピューティングデバイスが提供される。他の実施形態によれば、実行されるときコンピュータデバイスが前記方法を実行させる複数のコード部分(code portions)を含むコンピュータで可読記録媒体が提供される。
【0021】
前記第1シードデータは、開始ハッシュを含んでもよい。前記開始ハッシュは、前記第1エンティティに関連する以前のデータトランザクションのレコードをハッシュした結果であり得る。前記開始ハッシュは、ランダムハッシュを含んでもよい。前記ランダムハッシュは、前記デバイスからの署名、前記ランダムハッシュが生成された日付及び/又は時間のうちの少なくとも1つを含んでもよい。
【0022】
第2シードデータを提供するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと第1ゼロ知識証明及び第2ゼロ知識証明を結合するステップをさらに含んでもよい。ここで、前記第1ゼロ知識証明は、前記開始ハッシュが前記第1エンティティに関連する前記以前のデータトランザクションの前記真のハッシュを含むという証明を含んでもよい。前記第2ゼロ知識証明は、第2ハッシュが前記第2エンティティに関連する以前のデータトランザクションの前記真のハッシュを含むという証明を含んでもよい。第2シードデータを提供するステップは、前記第1シードデータ、前記第1データトランザクションの前記レコード、前記第1ゼロ知識証明及び前記第2ゼロ知識証明と第3ゼロ知識証明を結合するステップをさらに含んでもよい。前記第3ゼロ知識証明は、ランダムデータから生成されてもよい。前記第3ゼロ知識証明は、前記第1ゼロ知識証明又は前記第2ゼロ知識証明の繰り返しであってもよい。前記第3ゼロ知識証明は、前記第2ゼロ知識証明に対応する前記第1データトランザクションの第2レコードを用いて構成してもよい。
【0023】
前記第1データトランザクションは少なくとも2つのステージを含み、第2シードデータを提供するステップは、前記第1データトランザクションの前記第1ステージのレコードと前記第1ゼロ知識証明を結合するステップと、前記第1データトランザクションの前記第2ステージのレコードと前記第2ゼロ知識証明を結合するステップを含んでもよい。第2シードデータを提供するステップは、前記第1データトランザクションの前記第2ステージのレコードから第3ゼロ知識証明を構成するステップと、前記第1データトランザクションの前記第2ステージのレコードと前記第2ゼロ知識証明及び前記第3ゼロ知識証明を結合するステップを含んでもよい。前記第1データトランザクションは少なくとも3つのステージを含み、第2シードデータを提供するステップは、前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、前記第1データトランザクションの前記第3ステージのレコードと前記第3ゼロ知識証明を結合するステップをさらに含んでもよい。
【0024】
前記第1データトランザクションは、少なくとも3つのステージを含んでもよく、第2シードデータを提供するステップは、前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、ランダムデータと前記第3ゼロ知識証明を結合するステップをさらに含んでもよい。前記第1データトランザクションは、少なくとも3つのステージを含んでもよく、第2シードデータを提供するステップは、前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、前記第1データトランザクションの第4ステージのレコードと前記第2ゼロ知識証明を結合するステップを含んでもよく、前記第1データトランザクションの前記第4ステージは、前記第1データトランザクションの前記第3ステージの繰り返しであってもよい。
【0025】
前記第1データトランザクションは、少なくとも3つのステージを含んでもよくて、第2シードデータを提供するステップは、前記第1データトランザクションの前記第3ステージのレコードと第3ゼロ知識証明を結合するステップをさらに含んでもよい。
【0026】
前記第1ゼロ知識証明は、前記第1エンティティに関連する前記デバイスによって構成され、前記第2ゼロ知識証明は、前記第2エンティティに関連するデバイスによって構成され得る。
【0027】
前記第1ゼロ知識証明及び前記第2ゼロ知識証明を構成するステップは、キー交換アルゴリズムを使用するステップを含んでもよい。前記キー交換アルゴリズムはPAKEアルゴリズムを含んでもよい。
【0028】
前記方法は、前記第2エンティティに関連するデバイスに前記第1ハッシュを送信するステップと、前記第2エンティティに関連するデバイスから第2ハッシュを受信するステップ(前記第2ハッシュは、前記第2エンティティに関連する以前のデータトランザクションのハッシュを含む)と、前記第1パーティー及び前記第2パーティー間の第2データトランザクションのレコードを生成するステップと、前記第1ハッシュ及び前記第2ハッシュと前記第2データトランザクションの前記レコードを結合して第3シードデータを決定するステップと、前記第3シードデータをハッシュして第3ハッシュを生成するステップ(前記第3ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリー及び前記第2エンティティに関連するデータトランザクションのヒストリーを含む)と、前記第2データトランザクションの前記レコードに対する前記第3ハッシュを前記メモリに格納するステップをさらに含んでもよい。
【0029】
第3シードデータを提供するステップは、前記第2データトランザクションの前記レコード、前記第1ハッシュ及び前記第2ハッシュと第3ゼロ知識証明及び第4ゼロ知識証明を結合するステップをさらに含み、前記第3ゼロ知識証明は、前記第1ハッシュが前記第1データトランザクションの真のハッシュを含むという証明を含み、前記第4ゼロ知識証明は、前記第2ハッシュが前記第2エンティティに関連する前記以前のデータトランザクションの前記真のハッシュを含むという証明を含んでもよい。前記第2エンティティに関連する前記以前のデータトランザクションは前記第1データトランザクションであってもよい。
【0030】
前記方法は、前記第1エンティティ及び/又は前記第2エンティティの識別子と前記ハッシュのそれぞれを関連づけるステップをさらに含んでもよい。前記方法は、前記第1ハッシュを再算出するステップと、マッチング(match)を決定するために前記生成された第1ハッシュを前記再算出された第2ハッシュと比較するステップをさらに含んでもよい。前記方法は、前記比較が不成功である場合、追加データトランザクションを取り消すステップをさらに含んでもよい。前記方法は、前記第1データトランザクションに対応するシステムハッシュをシステムデバイスに生成するステップをさらに含んでもよい。
【0031】
第2シードデータを提供するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記システムハッシュを結合するステップをさらに含んでもよい。前記システムハッシュは、前記システムデバイス上の以前のデータトランザクションのレコードをハッシュした結果であってもよい。
【0032】
第2シードデータを提供するステップは、ライセンスデバイスからライセンスハッシュを受信するステップと、前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記ライセンスハッシュを結合するステップをさらに含んでもよい。
【0033】
前記方法は、前記ライセンスデバイスで、前記第1ハッシュを受信するステップと、ライセンス入力を提供するために前記ライセンスハッシュと前記第1ハッシュを結合するステップと、前記ライセンス入力をハッシュして第2ライセンスハッシュを生成するステップをさらに含んでもよい。
【0034】
第2シードデータを提供するステップは、ディレクトリデバイスからディレクトリハッシュを受信するステップと、前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記ディレクトリハッシュを結合するステップをさらに含んでもよい。
【0035】
前記方法は、前記ディレクトリサーバで、前記第1ハッシュを受信するステップと、ディレクトリ入力を提供するために前記ディレクトリハッシュと前記第1ハッシュを結合するステップと、前記ディレクトリ入力をハッシュして第2ディレクトリハッシュを生成するステップをさらに含んでもよい。
【0036】
第2シードデータを提供するステップは、前記第1データトランザクションに対する暗号化キーからキーハッシュを生成するステップと、前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記キーハッシュを結合するステップをさらに含んでもよい。前記暗号化つける公開キー又は個人キーを含んでもよい。
【0037】
前記第1シードデータ及び前記第1データトランザクションの前記レコードを結合するステップは、前記第1データトランザクションが完了するとすぐに実行されてもよい。前記メモリは遠隔デバイスに位置してもよい。前記方法は、他のデバイスから受信されたハッシュに対応する前記第1ハッシュを前記遠隔デバイスで比較するステップをさらに含んでもよい。前記方法は、前記デバイスに接続された他のデバイスに前記第1ハッシュを受信することを予想するよう通知するステップをさらに含んでもよい。
【0038】
前記方法は、前記メモリにハッシュチェーンを格納するステップをさらに含んでもよい。前記方法は、送信された前記ハッシュチェーンに対するアクセスを制限するように構成されたデバイスに位置する第2メモリに前記ハッシュチェーンを送信するステップをさらに含んでもよい。前記方法は、前記ハッシュチェーンでハッシュを修正又は削除するステップをさらに含み、前記ハッシュチェーンでハッシュを修正又は削除するステップは、前記ハッシュチェーンで対象のハッシュを再生成するステップと、前記レコードが修正されていないかの有無を確認するステップと、前記再生成されたハッシュをレコーディングするステップと、前記レコードを修正又は削除するステップと、前記対象のハッシュの結合及び前記修正及び削除されたレコードをハッシュして前記レコードに対する新しいハッシュを生成するステップと、前記新しいハッシュをレコーディングするステップを含んでもよい。前記方法は、前記新しいハッシュを用いてシステムハッシュを生成するステップをさらに含んでもよい。
【0039】
前記デバイスはサーバを含んでもよい。前記デバイスはユーザデバイスを含んでもよい。前記ユーザデバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネット(IoT)可能デバイスのうちの少なくとも1つを含んでもよい。前記ユーザデバイスは前記デバイス上のメモリで前記第1ハッシュを格納してもよい。前記ユーザデバイスは、該当サーバからオフラインである場合にのみ、前記デバイス上のメモリで前記第1ハッシュを格納してもよい。前記デバイスは、前記第2エンティティに関連するデバイスに前記第1ハッシュを送信してもよい。前記デバイスは、前記第1データトランザクションの前記レコードに署名し、暗号化されたコピーを前記第2エンティティに関連する前記デバイスに送信し、前記署名は、前記第1データトランザクションの前記レコードに対する配信先サーバの表示を含んでもよい。前記デバイスは、特定のオフライン公開キーで前記レコードに署名してもよい。前記デバイスは、前記デバイスに属するキーで前記レコードに署名してもよい。前記配信先サーバのみが前記第1データトランザクションの前記レコードの前記暗号化されたコピーを解読してもよい。前記デバイスが対応するサーバと接続を回復するとき、前記デバイスは、前記関連するハッシュ及びそのオフラインデータトランザクションの前記暗号化されたレコードを対応するサーバに送信してもよい。前記デバイスは、自身が保有する他のエンティティに関連するデータトランザクションのレコードのコピーを前記他のエンティティに対応するサーバへの送信のために自身に対応するサーバに送信してもよい。前記送信は、前記レコードが適用される全てのサーバに前記レコードを受信することを期待するよう通知することを含んでもよい。前記デバイスは、前記第1データトランザクションでこれの部分を識別するために固有の内部トランザクション番号を生成してもよい。
【0040】
前記許可するステップは、前記識別子に基づいて前記ユーザデバイスが前記第1サービスにアクセスするように許可されるかを確認するステップを含んでもよい。前記確認するステップは、前記識別子に基づいて前記ユーザが少なくとも1つの基準(criteria)を満足するかを確認するステップを含んでもよい。第1基準が前記第1ホストサーバ又は前記要求サーバに格納され、第2基準が他のサーバに位置してもよい。前記許可するステップは、前記要求サーバ及び前記第1ホストサーバ間の通信に対する署名を検証するステップを含んでもよい。
【0041】
前記許可するステップは、前記要求サーバで実行されてもよい。前記許可するステップは、前記要求サーバで前記デバイスが前記第1サービスにアクセスするように以前に許可されたかを決定するステップを含んでもよい。
【0042】
前記許可するステップは、ディレクトリサーバで実行されてもよい。前記許可するステップは、前記要求サーバが前記ディレクトリサーバから前記デバイスに対する許可を要求するステップを含んでもよい。前記アクセスさせるステップは、前記ディレクトリサーバが前記第1ホストサーバに対する識別子を前記要求サーバに送信するステップを含んでもよい。前記識別子を許可するデータは、前記ディレクトリサーバに格納されてもよい。
【0043】
前記方法は、第2サービスに対するアクセスを要求するステップと、前記識別子に基づいて前記デバイスが前記第2サービスにアクセスすることを許可するステップと、前記デバイスが前記要求サーバを介して前記第2サービスにアクセスさせるステップをさらに含んでもよい。前記第2サービスは、前記第1ホストサーバに位置してもよい。前記第2サービスは、第2ホストサーバに位置してもよい。
【0044】
前記デバイスが前記第1サービスにアクセスすることを許可するステップは、第1ディレクトリサーバで実行され、前記ユーザデバイスが前記第2サービスにアクセスすることを許可するステップは、第2ディレクトリサーバで実行されてもよい。
【0045】
前記方法は、第3サービスに対するアクセスを要求するステップと、前記識別子に基づいて前記デバイスが前記第3サービスにアクセスすることを許可するステップと、前記デバイスが前記第3サービスにアクセスさせるステップをさらに含んでもよい。
【0046】
前記第2サービスは、前記第1ホストサーバ、前記第2ホストサーバ又は第3ホストサーバに位置してもよい。前記デバイスが前記第3サービスにアクセスすることを許可するステップは、第3ディレクトリサーバで実行されてもよい。
【0047】
識別子を提供するステップは、前記デバイスが暗号化されたトンネルを介して前記要求サーバと通信するステップを含んでもよい。前記方法は、それぞれの個別サーバで受信されるデータをキャッシュするステップをさらに含んでもよい。それぞれのホストサーバは二以上のサービスを提供してもよい。
【0048】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうちの少なくとも1つを含んでもよい。
前記移行するステップは、前記ディレクトリサーバで、前記第2データストアーで前記データに対する開始タイムスタンプを割り当てるステップと、前記第1データストアーで前記データに対する終了タイムスタンプを割り当てるステップを含んでもよい。
【0049】
前記方法は、前記終了タイムスタンプの後に前記第1データストアーを介して前記データにアクセスしようと試みる要求サーバに前記ディレクトリサーバを介して前記第2データストアーで前記ユーザを検索するように指示するステップをさらに含んでもよい。前記第1データストアーにおける前記データは第1アカウント提供者との第1アカウント登録を含んでもよく、前記第2データストアーにおける前記データは新しいアカウント提供者との第2アカウント登録を含んでもよい。前記移行するステップは、前記現在のアカウント提供者から前記新しいアカウント提供者に前記第1アカウント登録に関する情報を送信するステップを含んでもよい。前記情報は、登録(registrations)、残高balances)、コンフィギュレーション(configurations)及び/又は支払い指示(payment instructions)のうちの少なくとも1つを含んでもよい。前記移行するステップは、前記第1登録が前記現在のアカウント提供者から前記新しいアカウント提供者にスイッチされることを示す認証コード(authentication code)を確認するステップを含んでもよい。前記第1アカウント登録は第1ユーザ・クリデンシャルを含んでもよく、前記第2アカウント登録は第2ユーザ・クリデンシャルを含んでもよい。前記第1ユーザ・クリデンシャルは第1サーバに登録されてもよく、前記第2ユーザ・クリデンシャルは第2サーバに登録されてもよい。前記方法は、前記第1アカウント提供者によって前記第1ユーザ・クリデンシャルを用いてユーザに伝えられる通信を受信するステップと、前記第2ユーザ・クリデンシャルを用いて前記通信を前記第2アカウント提供者にルーティングするステップをさらに含んでもよい。前記方法は、前記第1クリデンシャルを使用する前記第1登録提供者で作られたデータトランザクションを前記第2ユーザ・クリデンシャルを使用する前記第2登録提供者に反転させるステップをさらに含んでもよい。前記方法は、前記データトランザクション時に前記ユーザが前記第1ユーザ・クリデンシャルを使用したことを決定するステップをさらに含んでもよい。前記通信を送信するサーバは、前記第2ユーザ・クリデンシャルにアクセスするように承認されなければならない。
【0050】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうちの少なくとも1つを含んでもよい。
前記方法は、ランダムフィールドを前記第2通信に追加するステップをさらに含んでもよい。それぞれのフィールドは2つ以上の特徴を含み、前記方法は、少なくとも1つのフィールドで特徴のケースをミキシングするステップをさらに含んでもよい。
【0051】
前記方法は、前記第2通信を処理する前に、前記第2エンティティによって前記第2通信で前記フィールドを解読及び順序化するステップをさらに含んでもよい。前記方法は、前記第2エンティティによって処理できないフィールドを廃棄するステップをさらに含んでもよい。前記第1エンティティ及び前記第2エンティティのうちの少なくとも1つはサーバを含んでもよい。前記第1エンティティ及び前記第2エンティティのうちの少なくとも1つは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスを含んでもよい。前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうちの少なくとも1つを含んでもよい。
【0052】
前記符号化するステップは、前記サイファーテキストを7ビット又は8ビット文字ストリングに符号化するステップを含んでもよい。前記方法は、前記サイファーテキストの前記長さが前記USSDセッションで前記許されたスペースよりも長い場合、前記サイファーテキストを2つ又は2つ以上の部分に分割ステップと、前記2つ又は2つ以上の部分を個別的に送信するステップをさらに含んでもよい。前記解読は、前記第2デバイスから前記全体サイファーテキストに前記2つ又は2つ以上の部分をリアセンブルするステップをさらに含んでもよい。
【0053】
前記方法は、前記第1及び第2デバイスを認証するステップをさらに含んでもよい。前記認証するステップは、2つの通信コンピュータアプリケーション間のプライバシー及びデータ無欠性を提供するアルゴリズムを使用するステップを含んでもよい。前記認証するステップは、TLS(transport layersecurity)を使用するステップを含んでもよい。TLSを使用するステップは第1セッションキーを生成するステップを含んでもよい。
【0054】
前記方法は、第2セッションキーを生成するためにPAKEプロトコルネゴシエーション(PAKE protocol negotiation)を暗号化する前記第1セッションキーを使用するステップと、前記第2セッションキーを用いて前記第1デバイスと前記第2デバイス間の前記セッションで追加通信を暗号化するステップをさらに含んでもよい。
【0055】
前記方法は、前記第1エンティティ及び前記第2エンティティを認証するステップをさらに含んでもよい。前記認証するステップは、2つの通信コンピュータアプリケーション間のプライバシー及びデータ無欠性を提供するアルゴリズムを使用するステップを含んでもよい。前記認証するステップは、TLSを使用するステップを含んでもよい。前記方法は、第4共有秘密を用いて前記第1デバイス及び第3デバイス間の第2PAKEセッションを生成するステップをさらに含んでもよい。前記第4共有秘密は、前記第1デバイスのために前記第3デバイスによって生成された認証コードを含んでもよい。
【0056】
前記第1共有秘密は、前記第1デバイスのために前記第2デバイスによって生成された認証コードを含んでもよい。前記認証コードは、前記第1デバイスのために識別子と共に前記第1デバイスに送信されてもよい。前記識別子は、前記第1デバイスのモバイル番号又はシリアル番号を含んでもよい。前記第1共有秘密は、前記第1エンティティに関連する銀行カードのPAN(personal account number)を含んでもよい。前記第1共有秘密は、前記第1エンティティに関連する銀行カードの符号化されたシリアル番号を含んでもよい。
【0057】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうちの少なくとも1つを含んでもよい。
前記サービスに対するアクセスを認証するステップは、前記クリデンシャル及び/又は前記コンテキストに基づいてサービスの一部に対するアクセスを認証するステップを含んでもよい。前記クリデンシャルは、デバイス及び前記デバイスのプライマリユーザ(primary user)に関する第1クリデンシャルを含んでもよい。前記クリデンシャルは、デバイス及び前記デバイスのセカンダリーユーザに関する第2クリデンシャルをさらに含んでもよい。前記クリデンシャルに基づいて前記サービスに対するアクセスを認証するステップは、前記第1クリデンシャル及び前記第2クリデンシャルのそれぞれに基づいて前記プライマリユーザ及び前記セカンダリーユーザに対する異なるサービスに対するアクセスを認証するステップを含んでもよい。前記デバイスは、前記プライマリユーザ及び前記セカンダリーユーザに対する異なる支出限度である前記異なるサービス及び銀行カードを含んでもよい。前記クリデンシャルは、前記コンテキストに基づいて選択されてもよい。前記サービスは、前記コンテキストに基づいて選択された複数のサービスを含んでもよい。管理者又はユーザは、前記コンテキスト又はクリデンシャルを修正、追加又は取り消してもよい。前記クリデンシャルは、パスワード、PIN、及び/又は他の直接認証クリデンシャル(direct authentication credential)のうちの少なくとも1つを含んでもよい。前記コンテキストは、前記クリデンシャルを提供するデバイス、前記デバイス上のアプリケーション、前記デバイスが接続されたネットワーク、前記デバイスの地理的位置、及び/又はアクセスされる前記サービスのうちの少なくとも1つを含んでもよい。
【0058】
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうちの少なくとも1つを含んでもよい。
前記方法は、複数の要求を前記第1モジュールのバッファメモリでバッチされたメッセージにバッチするステップと、前記第2モジュールに送信される前記バッチされたメッセージをキューイングするステップと、システム機能を許可する少なくとも1つのシステムフラグをセッティングするステップと、前記第2モジュールで前記少なくとも1つのシステムフラグをチェックするステップと、前記第2モジュールで前記バッチされたメッセージを処理するステップをさらに含んでもよい。
【0059】
前記方法は、前記第1モジュールと前記第2モジュールとの間の少なくとも1つの共有メモリチャネルを設定するステップをさらに含んでもよい。前記方法は、前記少なくとも1つの共有メモリチャネルを介して前記第1モジュールに応答する前記第2モジュールを含んでもよい。前記少なくとも1つの共有メモリチャネルは、前記バッチされたメッセージを受信及びアセンブルし、前記第2モジュールに前記メモリの所有権を渡してもよい。前記少なくとも1つの共有メモリチャネルは、前記コンピュータシステムのネットワークスタックを介してバッチされたメッセージを受信してもよい。前記少なくとも1つの共有メモリチャネルは、HTTPゲートウェイを含んでもよい。前記HTTPゲートウェイは、ウェブサービスとして使用されてもよい。
【0060】
通信は、パスワード認証されたキー交換プロトコルを使用してもよい。前記方法は、前記コンピュータシステムのネットワークスタックでゼロコピーネットワーキング(zero-copy networking)を使用するステップをさらに含んでもよい。前記方法は前記コンピュータシステムのネットワークスタックでユーザモードネットワーキングを使用するステップをさらに含んでもよい。
【0061】
前記方法は、前記第1モジュールから前記データ送信の前記コンポーネントが単一データストリームに結合し、前記第1モジュールで前記コンポーネントに分離されるようにデータを直列化するステップをさらに含んでもよい。前記直列化は、各モジュールのエッジで抽象化されてもよい。
【0062】
各モジュールのバッファメモリは、構成可能なバッファリング閾値を有してもよい。前記第1モジュール及び前記第2モジュールは同じコンピューティングデバイス上に位置してもよい。前記第1モジュール及び前記第2モジュールは、異なるコンピューティングデバイス上に位置してもよい。
【0063】
前記第1モジュールから前記第2モジュールに送信されたデータはバージョンID(version ID)を運んでもよい。前記方法は、前記バージョンIDが前記第1モジュールから前記第2モジュールに送信された前記データに対して最新であるかを検証するステップをさらに含んでもよい。前記方法は、前記データのうち任意のデータがアップデートされる場合、前記バージョンIDを現在のバージョンに再検証するステップをさらに含んでもよい。前記バージョンIDが検証されない場合、前記データ送信は失敗することがある。
【0064】
前記第1モジュール及び前記第2モジュールのうちの少なくとも1つは少なくとも1つのデータサービスモジュールを含んでもよく、前記コンピュータシステム内のそれぞれのデータ処理は、前記少なくとも1つのデータサービスモジュールを介して実行されてもよい。前記少なくとも1つのデータサービスモジュールは、コアデータベースストアーによって実現されるデータストアーと通信してもよい。前記少なくとも1つのデータサービスモジュールは、前記データストアーに直接アクセスする前記コンピュータシステムのコンポーネントであってもよい。前記コアデータベースストアーは、少なくとも1つの分散データベースを含んでもよい。前記少なくとも1つの分散データベースは、別途の読み出し及びレコードアクセスチャネルを有してもよい。前記データストアーは、少なくとも1つの異種データベースにインタフェースを提供してもよい。前記データストアーは、複数のインタフェースタイプを提供してもよい。前記複数のインタフェースタイプは、少なくとも1つのSQL(Structured Query Language)インタフェース、セル及びコラムインタフェース(cell and column interface)、文書インタフェース(document interface)、及び前記コアデータベースストアー上にあるグラフィックインタフェース(graph interface)のうちの少なくとも1つを含んでもよい。前記データストアーレイヤに対する全てのレコードは、1つ又は1つ以上のデータトランザクションの全て又は一部を制御する単一共有モジュールによって管理されてもよい。
【0065】
前記方法は、少なくとも1つの前記共有モジュールのリダンダント・バックアップを作動させるステップをさらに含んでもよい。全てのデータ変更は、シリアルの高速シーケンス(serial rapid sequence)で前記単一共有モジュールを介して行われてもよい。前記単一共有モジュールは、それ自体をデータトランザクタククラスタ(data transactor cluster)に示すホットバックアップリダンダンシーモデル(hot backup redundancy model)を使用し、前記データトランザクタククラスタは、ハイアラーキー(hierarchy)でモジュールのセットであり、各モジュールは、マスタモジュールが失敗する場合にデータトランザクションを制御してもよい。前記方法は、ドメインによって構成される規則に基づいて、モジュール又はデータストアーにわたってデータを分割するステップをさらに含んでもよい。前記方法は、データトランザクションのレコード又は親データトランザクション(parent data transaction)のレコードのターゲットデータをハッシュするステップをさらに含んでもよい。前記ハッシュするステップは、データパーティションの数と同じカーディナリティ(cardinality)を有してもよい。前記方法は、挙げられた地理的領域、名字及び/又は通貨のうちの少なくとも1つによってターゲットデータをハッシュするステップをさらに含んでもよい。
【0066】
前記方法は、複数のデータパーティションにわたって前記少なくとも1つのデータサービスモジュールを介して少なくとも1つのデータ送信を行うステップをさらに含んでもよい。前記方法は、多重モジュールによって前記少なくとも1つのデータサービスモジュールを介して少なくとも1つのデータ送信を完了するステップをさらに含んでもよい。前記方法は、前記少なくとも1つのデータサービスモジュール上の少なくとも1つのデータ送信を前記データストアーで複数のデータストレージノード上に保持するステップをさらに含んでもよい。
【0067】
前記コンピュータシステムは、複数のデータサービスモジュールを含んでもよく、それぞれのデータサービスモジュールは、該当インスタンスに対する全ての前記ホットデータのキャッシュされた表現を含み、イン-メモリ(in-memory)/イン-プロセス(in-process)データベースエンジンをホストしてもよい。前記コンピュータシステムは複数のデータサービスモジュールを含んでもよく、それぞれのデータサービスモジュールは、複数の異種又は同種データベースエンジンを含んでもよい。
【0068】
前記方法は、正確に全てのデータ読み出しが一貫し、対応するデータレコードを反映するように、前記データストアーに対するアクセスの同時性を管理するMVCC(Multiversion Concurrency Control)バージョンシステムを使用するステップをさらに含んでもよい。前記方法は、データレコードが前記データストアーにレコードされ、任意の後続データトランザクションが前記データレコードにアクセスする前にレコードされたことが確認されなければならないように、前記データストアーに対するアクセスの同時性を管理する悲観的一貫性(pessimistic consistency)を使用するステップをさらに含んでもよい。
【0069】
前記コンピュータシステムは、アプリケーションレイヤをさらに含んでもよく、前記少なくとも1つのデータサービスモジュールが前記レコードをレコードし、前記データ送信を完了することを確認するまで、前記アプリケーションレイヤはデータトランザクションを進めることができない。
【0070】
第1実施形態ないし第26実施形態の全ての選択的な特徴は、必要な部分のみを変更し、他の全ての実施形態に関連する。説明された実施形態の変形が想定され、例えば、全ての開示された実施形態の特徴は任意の方式により組み合わせられてもよい。
【図面の簡単な説明】
【0071】
図1】Tereonのモジュラー概念を示す。
図2】Tereonシステムアーキテクチャーの例を示す。
図2a】Tereonがサービス及びデバイスを機能領域及びコンテキスト、デバイス、コンポーネント及びプロトコルで抽象化する方法を示す。
図3】仲介者プロキシを通したTLS接続を介して開始された通信を示す。
図4】プロキシメモリで共有メモリ及びメッセージ伝達の使用を示す。
図4a】共有メモリ及びセマフォハンドオーバーモジュールを示す。
図5】4つのアカウントを含むハッシュチェーンを示す。
図6】同一システム上の2つのアカウントを含むハッシュチェーンを示す。
図6a】トランザクションステップがインターリビングする同一システム上の3つのアカウントを含むハッシュチェーンを示す。
図7】ライセンスハッシュの樹枝状特性(dendritic nature)を示す。
図8】しばらくの間にオフライン状態になる4つのデバイスを含むハッシュチェーンを示す。
図9】2つのサーバによって実現された逆ルックアップ機能を示す。
図10】Tereonサーバ間の通信設定を示す。
図11】ユーザが他のサーバに移動する通信を示す。
図12】ディレクトリサービスが要求サーバを2つの他のサーバに接続できる方法を示す。
図13】多角的なクリデンシャルを構成するためにサーバが3つのサーバからクリデンシャルを取得しなければならないケースを示す。
図14】銀行とユーザとの関係を示す。
図15】アカウントが振込されるプロセスを示す。
図16】登録されたモバイル番号が変更されるプロセスを示す。
図17】2つの貨幣にアクセスするために予め登録されたモバイル番号の保持を示す。
図17a】それぞれの通貨が別途のサーバ上にある2つの通貨にアクセスするために予め登録されたモバイル番号の保持を示す。
図18】ワークフローを示す。
図19】代案的なワークフローを示す。
図20】代案的なワークフローを示す。
図21】例示的なコンピューティングシステムを示す。
【発明を実施するための形態】
【0072】
本発明の実施形態は同じ部分を示すために同じ参照番号が用いられた添付図面を参照して例として説明される。
Tereonは、電子トランザクション処理及び認証エンジンである。これはモバイル及び電子支払い処理システムで実現される。また、これはIoT通信システムの一部として他の実現で使用され得る。
【0073】
Tereonは、任意のIP(internet protocol)支援デバイス及びこのようなIP支援デバイスと相互作用できる任意のデバイスに対するトランザクション機能を提供する。各デバイスは、固有なIDを有する。Tereonの使用事例は、IoTデバイスから医療記録アクセス及び管理、モバイル、支払い端末又はATM(Automated Teller Machin)のような、よく見られる支払いまで様々である。初期の実現例において、Tereonは、モバイル、カード、POS(poing-of-sale)端末及び固有参照IDを支援する。Tereonは、消費者及び販売者が支払い、支払いの受領、資金の送金、資金の受領、返金、返金の受領、資金の引き出し、アカウントデータを確認し、過去のトランザクションのミニ明細書の表示を可能にするために必要な機能を提供する。Tereonは、通貨間及び国を越えたトランザクションを支援する。したがって、消費者は、1つの通貨でアカウントを保有できるが、例えば、別の通貨で振込みすることができる。
【0074】
Tereonの初期の具現において、最終のユーザが特定のトランザクションを実行できるかどうかは、その時点で使用していたアプリケーションによって異なる。販売者又は販売者の端末は、一部のトランザクションを開始することができる一方、消費者デバイスは他のものを開始することができる。
【0075】
Tereonが支払いを処理するために用いられる場合、トランザクションは次のようなモードに細分化される。支払い、支払いの受領、モバイル消費者対モバイル販売者、モバイル消費者対オンライン販売者ポータル、顧客のないモバイル消費者対モバイル販売者、アカウントポータル内で消費者アカウント対販売者アカウント、NFC-Tereonカード消費者対カード販売者、NFC又は他のカード消費者対カード販売者、資金振込み及び受領、アカウントポータル内で消費者アカウント対消費者アカウント、モバイル消費者対ピアツーピアモバイル消費者、モバイル消費者対ピアツーピアカード消費者、カード消費者対ピアツーピアモバイル消費者、カード消費者対ピアツーピアカード消費者、モバイル消費者対ピアツーピア非ユーザ、カード消費者対ピアツーピア非ユーザ、非ユーザ対ピアツーピア非ユーザ、非ユーザ対ピアツーピアモバイル消費者、及び非ユーザ対ピアツーピアカード消費者、非ユーザは、送金の未受取人のように前に支払いサービスへ登録されていない人を示す。
【0076】
・システムアーキテクチャー
内部的に、Tereonサーバは、2つのメインコンポーネントであるTRE(Tereon Rules Engine)及びSDASF(Smart Device Application Services Framework)を含む。
【0077】
SDASFは、Tereonが様々な相異なるデバイス及びインタフェースを管理することができる。これは、Tereonが該当のデバイス及びインタフェースが作動し、Tereonに接続される方式を定義するために、一連の抽象化されたレイヤを使用及びリンク可能にすることによって実現される。
【0078】
例えば、全ての銀行カードは、基本カード抽象化レイヤを使用する。磁気ストライプ抽象化レイヤは、磁気ストライプのあるカード、NFCチップのあるカードに対するNFCレイヤ、及びチップコンタクトのあるカードに対するマイクロプロセッサーレイヤに適用されるのであろう。カードが3つの全てを使用する場合、Tereonは、メインカード抽象化レイヤ及び3つのインタフェースレイヤでそのカードを定義する。NFCレイヤのそれ自体がカードにのみ適用されるものではない。これは、モバイルを含むNFCを支援できる任意のデバイスにも適用され得る。SDASFは、デバイス又はインタフェースそれぞれに対するモジュールを生成するために、このような抽象化レイヤを使用する。
【0079】
外部的には、デバイス又はネットワークに対する各接続及び各サービスはモジュールである。したがって、ピアツーピア支払いサービス、入金サービス、及びミニ明細書のようなサービスは全てモジュールである。カード製造社、銀行、サービス提供者、端末、ATMなどに対するインタフェースも同様である。Tereonのアーキテクチャーは、様々なモジュールを支援し得る。
【0080】
・モジュラー観点(Modular view)
図1は、Tereonのモジュラー概念を示す。本質的に、Tereonは、モジュールの集まりであり、そのほとんどはモジュールを含んでいる。モジュールは、該当のモジュールが動作するコンテキスト及び機能ドメイン、及びそれが実行するために必要な機能を決定するビジネスロジックによって定義される。このような機能は、例えば、IoTデバイス間の動作及び通信を管理し、電子又はデジタル支払いの管理及び取引、識別又は要求による許可クリデンシャルを管理及び構成したり、任意の他の形式の電子トランザクション又はデバイスを管理及び運営するような任意のタイプの電子トランザクションであり得る。
【0081】
・Tereonサーバ
図1に示すように、Tereonサーバ102を構成するモジュールは、SDASF104及び規則エンジン106といった2つのレベルで見ることができる。規則エンジン106そのものは、モジュール108(その中の一部は図1に示され、これはサービスを定義するモジュール、プロトコル(図示せず)、スマート装置、端末などを含む)それぞれの機能ドメイン及びコンテキストを定義し、次に、このようなモジュール108は、SDASF104の構造を定義する。その次に、SDASF104及びこれが支援している結果サービス及びインタフェースは、Tereonが利用できるシステムプロトコルを定義する。その次に、このようなプロトコルは、Tereonが支援できる規則及びサービス((例えば、スマートデバイス、端末など)それ自体はTereonが提供する機能ドメイン及びコンテキストを定義する)を定義する。この循環的又は繰り返し的なアプローチは、モジュールの定義及びそれが支援している機能又は要求事項が互いに一致するかを確認するために用いられる。これにより、システムの動作を制限することなく、元の位置でモジュールがアップデートかつアップグレード、及び交換することができる。
【0082】
ブロック及びモジュールは、抽象化されたAPIs((application programming interfaces)それ自体は、Tereonが提供する機能ドメイン及びコンテキストを定義する)を用いてインタフェースする。可能であれば、これは共有メモリを使用できるオーダーメード型セマフォハンドオフモジュールを用いて通信し、その一例が図4aに示されている。これについては後述する。このような方式により、ブロック及びモジュールの内部動作及び機能は、全体システムの動作を損なうことなく、アップデートされたり交換され得る。
【0083】
・フレームワークインフラストラクチャーコンポーネント(Framework infrastructure components)
インフラストラクチャーコンポーネントもモジュラーである。SDASFの場合、このコンポーネント自体がモジュールを含む。
【0084】
・マルチインタフェース(Multiple interfaces)
各インタフェースは、コアサーバに接続される別途のモジュールとして構成される。したがって、Tereonのモジュラー構造は、バックオフィス(back offices)及びコアシステムを含むマルチインタフェース、カード、決済機関、販売者、モバイル電話機、サービス、サービス提供者、ストレージ、端末、SMS(short messaga service)ゲートウェイ、HLR(home location register)ゲートウェイなどを支援し得る。
【0085】
データベースインタフェースは、SQL(structured query language)エントリ及び格納されたデータのグラフ分析の全てを支援する。また、インタフェースは、データベース内にフィールドを区分するためにアクセス制御を支援する。他のユーザ規則及び許可レベルは、定義されたデータセット及びフィールドをアクセスし得る。アクセスは、様々なセキュリティー手段によって制御される。アクセス、認証、及び許可は、ACLs(access control lists)、LDAP(lightweight directory access protocol)、セル及びローセキュリティー(cell and rowsecurity)のようなカスタムの役割ベースのアクセス(custom role-based access)、及び個別の役割に制限されるアクセスインタフェースを含む産業標準の様々なアクセス方法により提供され得る。
【0086】
・Eコマースポータル(E-commerce portals)
Tereonは、ポータルの運営者が該当のポータルに対するプラグインを生成できるように、APIを介してEコマースポータルを支援し得る。
【0087】
・規則エンジン(Rules engine)
規則エンジン106は、新しいサービスがトランザクションに対して抽象化された様々なコンポーネントを共に編成して構築したり、新しいデバイスを支援する。規則は、配布されたサービスに対するビジネス論理を定義し、サービス提供者などはこのようなサービスを個別ユーザに合わせて調整できる。
【0088】
規則は、UML(unofied modelling language)又は一般英語(plain english)に類似のコードで定義される。エンジンは、規則を構文分析し、抽象化されたコンポーネントからサービスを生成し得る。
【0089】
コンポーネントの抽象化された特性は、新しいサービス又はデバイスモジュールが迅速に生成できる。これにより、Tereonは、必要に応じて、新しいサービス又はデバイスを支援できる。
【0090】
Tereonの内部インタフェースは、プロトコルに影響を受けないことから、外部プロトコルモジュールが機能に影響を及ぼすことなく交換することができる。例えば、銀行コアシステムにインタフェースを行うために、カスタムデータ交換プロトコルは、組織の一部とISO20022プロトコルモジュールを他の部分と共に使用される。
【0091】
SDASF104により、Tereonが多重スマートデバイス及びプロトコルを支援できる。SDASF104のアイディアは、エンティティをデバイスタイプ及びプロトコルに抽象化することにある。SDASF104は、各デバイスが特定のサービス又は機能に必要なプロトコルを呼び出すものと多重プロトコルを定義する。
【0092】
SDASF104は、インストールの動作に影響を与えることなく、既存のインストールに新しいモジュールを追加して拡張される。どちらの方法を用いて全てのサービスをバックオフィスサーバに定義できる。販売者端末(merchant terminals)にインストールされれば、Tereon端末アプリケーションは、消費者にサービスを提供するためにSDASFと通信する。
【0093】
図2は、Tereonシステムアーキテクチャー200を示す。ここで、ダイヤグラム及び描写が特定のソリューションを介して特定のコンポーネントを示す場合、これが単に実施形態で選択されるコンポーネント又は言語であるためである。オーダーメード型(bespoke)システムは、このようなコンポーネントを置き換えたり、より効率的なものと立証され得る他の言語及びシステムを使用するために構築される。
【0094】
・Tereonサーバ(The Tereon server)
Tereonサービス202は、モノリシックアーチファクトとして識別される論理的構造である。実際に、それは各機能及び範囲により異なる、隔離されたマイクロサービスのセットとして存在し得る。
【0095】
・通信レイヤ(The communications layer)
通信レイヤ204は、仲介者プロキシを経てTLS(transport layersecurity)接続を介して開始される。これについても図3に示される。TLSは、コンピュータネットワーク、一般的にTCP/IP(transmission control protocol/internet protocol)ネットワークを介して通信セキュリティーを提供する暗号化プロトコルである。各コンポーネントは、システム、オブジェクト又はサービスに接続されたり、アクセスできるユーザ又はシステムプロセスを明示するACL(access control list)がある。これにより、仲介者のみがくるオリジナル接続(incoming、original connection)を設定し、本質的なセキュリティーが強化され、危険プロファイルは減少される。この例では、プロキシは、専門化されたTereonカスタマイズを使用した、従来技術で知られているHTTPゲートウェイプラットフォームを使用している。
【0096】
・個人DNSネットワーク(Private DNS network)
DNS206は、ディレクトリサービス216の基礎として用いられる。ディレクトリサービス216は極めて重複し、地理的な位置にわたって複製される。しかし、その構造及び機能は、下記に説明されるように既存のDNSサービスが提供できるものを遥かに超えるものである。
【0097】
・抽象化(Abstractions)
図2aは、Tereonがそのサービス及びデバイスを、消費者又は消費者の処理及び規則、販売者の処理及び規則、銀行の処理及び規則、振込みの処理及び規則、デバイス機能及び規則などのような機能ドメイン及びコンテキストに抽象化する方法を示す。図1は、コンポーネント及びシステムのサービスを機能ブロック又はモジュールに抽象化することにより、Tereonがこのような抽象化にどのように映像を及ぼすかを図示する。
【0098】
Tereonモジュールは、このような抽象化から構成される。各デバイス、各インタフェース、及び各トランザクションタイプは、そのドメイン及びコンテキストに抽象化される。このような抽象化は再利用でき、意味がある場合や許可される場合に、他のものにインタフェースし得る。例えば、チャージカード、クレジットカード、デビットカード、及びロイヤルティカードの各モジュールは、一般的な基本抽象概念を使用する。支払い及び資金の振込みモジュールも同様である。
【0099】
・プロトコル(Protocols)
Tereonが支援するプロトコル204及び212のそれぞれは、それ自体がモジュールとして実現される。Tereonは、このようなモジュールを必要とするサービス又はコンポーネントがこのモジュールを利用できるようにする。
【0100】
レガシーシステムでは、ハードウェアを追加する前に、100s又は1000sに同時に生じるトランザクションを処理するのに苦労している。システムをアップデートする代わりに、銀行は、調整アカウント及び支払いポイントまで信用をカバーするための高いコストが要求される定期的な支払いシステムに依存してきた。Tereonは、信用露出及びこのようなアカウントに対する必要性から離隔されている。これは秒当たり100、000件のトランザクションを処理するように求められる極めて安価なシステムを提供する。Tereonは弾力性が構築され、サーバ当たり秒当たり1、000、000件のトランザクションを支援し、高価なハードウェアに依存することなく、ハイエンドの商品ハードウェアで動作するように設計されている。また、Tereonは、ACID保証やそのリアルタイム性能を損傷することなく、ほぼ水平方式(near-linear fashion)で水平及び垂直スケーリングを支援する。
【0101】
・ライセンスサブシステム(The licensing subsystem)
Tereonライセンスサーバ210は、システムのコンポーネントが単一に配布されたインスタンス(単一インスタンスのマイクロサービスはマシーンが、例えば、物理的機械、論理的機械、仮想機械、コンテナや実行可能なコードを含むための一般的に用いられるメカニズム、及び任意の数又は機械のタイプに関わらず単一マシーン上のプロセス間通信に結合される)内で配布インスタンスの全体(例えば、相互通信する個々の消費者プラットフォーム)内で、合法的で、認証されて認可されたピアシステム(peer systems)と通信することを保障する。ライセンスプラットフォームは、当技術分野で知られた認証機関の構造を介して実現される。
【0102】
コンポーネントがシステムにインストールされるとき、それらは規定されて設定可能な間隔で、安全で認証された接続を介して、ライセンスサーバに認証書署名要求と共にそれらのインストール詳細(組織、コンポーネントタイプ及び詳細、ライセンスキーなど)を伝達する。
【0103】
認証書サーバは、その詳細を許可されたコンポーネントディレクトリと比較し、一致すると、インストールの要求を開始するデバイスへ内部の認証機関ハイアラーキーで隔離されたセキュリティー署名キー(一般的に、ハードウェアセキュリティーモジュールを介して)で署名され、一定期間(例えば、1ヶ月)の間に使用可能な新しい認証書を承認する。接続システムの全てのクロックは同期化される。
【0104】
その次に、呼出者(caller)は、他のモジュールとの通信を開始するときクライアント認証書として、また、接続の受信者として役割を果たすとき、サーバ認証書として認証書を使用する。個人キーを受信していないライセンスサーバは、たとえ損傷されても、他の第3者がこの認証書を偽装することを可能にするような詳細を有しない。必要に応じて、呼出者は、クライアント認証書及びサーバ認証書といった2つの認証書をライセンスサーバから要求できる。
【0105】
各コンポーネントは、サーバ及びクライアント認証書が信頼できる認証された認証機関のエージェントによって署名されていることを検証し、それが中間者攻撃又は監視の対象ではなく、相手側(counter-party)がそれが言う人であるという相当な確信をもって通信できる。各認証書は、各モジュールそのもの(例えば、特定の組織に対するルックアップサーバとして)を表示できる方法を制限する使用コードメタデータによって承認される。組織は、全ての関係者がライセンスを取得した合法的で有効なインスタンスを運営することを保証する。
【0106】
多くの認証書は、期限が満了して固定期間の間に更新されることなく、また承認されない。しかし、認証書が損傷されたり、ライセンスが終了又は一時停止される場合に取り消しリストが使用され、必要に応じて、プロキシサービスに非同期的に分配される。アクティブ認証書ディレクトリは常に保持され、定期的な監査に使用できる。
【0107】
双方向の有効検査の利点の他に(クライアントは、自分が話者であり、各接続のサーバは報告する者である)、この実現によって、コンポーネントが遠隔ライセンスサーバとの通信に必要な各接続の構築なしに安全に相互通信を可能にし、プラットフォームの全般的な信頼性を低下させることなく安全に通信可能にする。
【0108】
・サイト間の通信(Site to site communications)
サイト間の通信は、識別されて公開されているHTTPゲートウェイインスタンス(HTTP gateway instance)212を介して容易になり、カスタムゼロ-コピー及び選択的なユーザモード機能を実行する。これは、モバイルデバイス、端末、及びその他の外部関係者がサイト間の接続は勿論、インスタンスと通信するために用いられるプラットフォームである。これは、産業標準の侵入検知、レート制限、及びDDOS(distributed denial-of-service)攻撃保護、ハードウェア暗号化オフロードなどに対応する。これは機能的に、論理的インスタンスプロキシメカニズムであり、同じ機能(クライアント/サーバ認証書及び有効性検査を含む)を全て支援すると共に、外部で認められている認証機関を外部の当事者に使用する。
【0109】
・Tereonデータサービス(The Tereon data service)
Tereonシステムの重要な特徴の1つとして、以前のシステムよりも遥かに多いトランザクション(処理量の観点で)を処理できることである。これは、データ及びトランザクションを処理できる高度な同時性、迅速性、及び拡張性に優れる処理ネットワーク、極めて効率的なデータサービスレイヤのみならず、処理オーバーヘッドを最小化するアルゴリズム及びオーダーメード型モジュールを実現する独自の設計によるものである。
【0110】
説明された性能特性は、コンピューティングハードウェアの特定の部分で多く実行される規模拡張に主にターゲットされることで、運営コスト及び消費電力が大幅に減少される。ただし、設計は単一システムに限定されず、Tereonシステムは、複数のデバイス上に同時に実行できる各サービスを用いて垂直及び水平的に膨大な規模でスケールアウト(scaling out)し得る。
【0111】
単一のシステム又はサーバ上で高いレベルの性能を取得するために、システムは、不要な直列化を避け、不要なストリーム処理を避け、不要なメモリコピーを避け、ユーザからカーネルモードへの不要な切り替えを避け、プロセス間のコンテキストスイッチを避け、ランダム又は不要なI/Oを避けることで、処理オーバーヘッドを可能であれば最小化する。システムが正常に作動するとき、これは該当システム上に極めて高いレベルのトランザクションパフォーマンス達成を図ることができる。
【0112】
既存のモデルでは、サーバAが要求を受信する。その後、サーバBへのクエリを構築して直列化し、すぐにサーバBに該当クエリを送信する。その後、サーバBは(必要に応じて)該当クエリを解読し、逆直列化して解釈する。その後、応答を生成して直列化し、必要に応じて該当び応答を暗号化してから応答をサーバA又は他のサーバに再度送信する。カーネル及びプロセスコンテキストの切り替えは、メッセージごとに数十回行われ、単一のメッセージは様々な形態に何度もキャストされ、メモリは多くの作業バッファ間でコピーされる。このようなカーネル及びプロセスコンテキストの切り替えは、処理されるメッセージごとに大規模の処理オーバーヘッドを課する。
【0113】
・通信アーキテクチャー(Communications architecture)
Tereonは、システムによって処理される従来方式のデータ及び通信を再構成し、その処理量を達成する。可能であれば、Tereonは、カーネルによって課される処理オーバーヘッドを避け、標準データ管理モデルで頻繁に発生するセキュリティー問題を回避するために、運営システムカーネルをバイパスする。
【0114】
システムで各データ処理は、データサービスインスタンス214を介して実行される。これは、直接データプラットフォームアクセスを有するシステムの唯一のコンポーネントである、規模の縮小されたサービス(指向データサービスレイヤ)である。したがって、システム上の全てのデータ処理は、必ずこれを通過しなければならない。
【0115】
データサービスレイヤ214は、別途の専用の読み出し及びレコードアクセスチャネル226を介してデータストアレイヤ220と通信する。データストアレイヤ220は、それ自体が少なくとも1つの分散データベースを含むコアデータベースストア224を介して実現される。このようなデータベースは、ACID保証を提供する必要がない。これはデータストアレイヤによって管理される。
【0116】
データストアレイヤ220に対する全てのレコードは、全てのデータ変更が因果関係を保持するためにシリアルの高速シーケンスで進行されながら、単一共有トランザクタによって管理され、これを通じて全てのデータ変更が因果関係を保持するためにシリアルの高速シーケンスで進行される。トランザクタの設計は、データトランザクタクラスタ222として自身を提示するホットバックアップリダンダンシーモデル(hot backup redundancy model)を使用する。1つのトランザクタがいずれかの理由によって失敗したり停止する場合、他のランザクションのいずれか1つはすぐに引き継ぐのであろう。
【0117】
データプラットフォームは、全てのデータドメインに対する分割を支援するが、その支援は図示されていない。いずれのケースで単一データストアレイヤ(無制限データノードによってバックアップされる)が禁止されたり、又は規制上の理由がある場合、データは互いに異なるトランザクションを用いて互いに異なるデータクラスタに格納するために、命令的又は宣言的な方法によって分割される。例えば、1つのサイトは4つのデータプラットフォームがあり、プラットフォームは、地理的又は司法的な基準により顧客を分割したり、1~5で始まるアカウト、又は6~0で始まる他のアカウントで顧客を分割する。これに対する処理上の問題があるが、これはプラットフォームによって支援される。
【0118】
図3は、データサービスレイヤ214及びそれから通信をルートする通信レイヤ204を通した通信を示す。モジュール350が他のモジュール360と通信する必要がある場合、まずプロキシ370と接続を開始し、ステップ302でクライアント認証書を認証し、ステップ304でプロキシ認証書が構築するとき有効に信頼されるかをチェックする。モジュール350は、ステップ306でメッセージをプロキシ370に伝達する。プロキシ370は、ステップ308でターゲットモジュール360と関係接続(correlating connection)を設定する。まず、ステップ308で自身を認証し、ステップ310でモジュールの認証書が有効に信頼されるかを検証する。プロキシ370は、ステップ314でモジュールの応答を受信する前に、ステップ312でイニシエーター(モジュール350)の確認された詳細を伝達する。プロキシ370は、ステップ316でターゲット(モジュール360)の詳細及びその応答を返す。これにより、プロキシ370を介してモジュール350及びモジュール360間の通信チャネルを確立し、2つのモジュール全てが高い信頼度で互いに認証されて識別され、必要に応じて、全ての通信及びデータが暗号化される。プロキシ370は、ステップ318でモジュール350からのメッセージをステップ320においてターゲットモジュール360に中継し、ステップ322において、ターゲットモジュールの応答をステップ324でモジュール350に中継する。
【0119】
このような接続は、発信者及び受信者の認証書の詳細に基づいてセッション共有及び接続保持(keep-alive)を使用する(例えば、モジュール350は、プロキシ370を介してターゲットモジュール360に対する接続を「閉じ(close)」、実際に新しいエンドツーエンド接続(end-to-end connection)を構築することなくリオープン(reopen)し、接続は任意の他の回路で絶対共有されない)。通信プロキシ370は、HTTPゲートウェイ又は他の適切なモジュールもしくはコンポーネントであってもよい。
【0120】
このようなアーキテクチャーは、主に大量のメモリの使用によって相当な性能上のコストが発生する。モジュール350がターゲットモジュール360と通信するために、伝統的に、ターゲットモジュール360へ伝達する前にペイロードを直列化し、ペイロードを暗号化し、これをプロキシ370にストリームし(ここで、プロキシ370はペイロードを解読する)、コンテンツを逆直列化及び解釈し、ペイロードを再直列化し、ターゲットモジュール360に対してこれを暗号化する必要がある。ターゲットモジュール360は、コンテンツを解読し、逆直列化して解釈し得る。
【0121】
Tereonは、平均及び最大の待ち時間(latency)を減らし、メモリの負荷を減らし、常用のハードウェア上の単一プラットフォームの性能を向上させるために様々な技術を使用している。これはマイクロサービスの配布利点(deployment benefits)、メンテナンス、及びセキュリティーの全てを保持しながら、モノリシックインプロセス性能を達成できる。このようなシステムが提供しなければならない高いレベルのセキュリティー及び制御を損なうことなく実行される。
【0122】
Tereonは、図3に示すように、通信レイヤを介してバッチされたメッセージングモデルを用いることができる。ステップ306において、モジュール350からプロキシ370に伝えられたメッセージのような伝達された各メッセージは、メッセージのバッチであり得る。しかし、Tereonは、これ以上のことを実行することができる。
【0123】
バッチされたメッセージングに加え、図4は、2つのモジュールのサーバが互いに共有メモリチャネルを交渉するためにプロキシモジュール(オーダーメード型ハンドオーバーモジュール)を介して通信することを示す。ステップ402ないし412は、図3でステップ302ないし312に類似し、必要に応じて、サービスの属性をチェックし、それがクライアント要求とマッチするかを確認する。これはステップ302ないし312で発生し得る。
【0124】
モジュール450ないしモジュール460のインスタンスは、TLS、又は伝統的なTLS HTTPSだけでなく、呼出者トランザクションに対するHTTPゲートウェイのユーザモード及びゼロコピーをともに最適した形で使用できる。
【0125】
ソースモジュール450及び配信先モジュール460がローカルである場合、ステップ402ないし412からのプロキシ470を介して接続を設定した後、発信者及び受信者は共有メモリを介して直接接続を選択的に要求し、この選択的な要求により、この方法は図3に設定された方法と異なる。発信者及び受信者が互いに直接接続を要求する場合、ネゴシエーション後で、共有チャネルはステップ414でモジュール460からプロキシ470に、ステップ416でプロキシからモジュール450に伝えられ、この点から2つのモジュールは、セマフォ及び共有メモリを再び使用する直接処理メカニズムを使用する。これは、ステップ418、420、422などにおけるモジュール450及びモジュール460間のメッセージによって示される。
【0126】
Tereonモデルでは、サーバ450は、タスクに最適した形で基本メモリバッファ(native memory buffers)内の複数の要求をバッチ処理し、サーバ460にメッセージをキューイングし、セマフォをトリップする。サーバ460は、フラグをチェックし、直接的に共有されたメモリを処理し、共有メモリに応答する。接続には、発信者及び受信者の認証書の詳細と通信のためのセマフォ及び共有メモリに基づいて接続保持及び共有されたメモリを使用する。
【0127】
上述した方法を用いて、通信は、単一発信者の配信先、ACL-制御、セキュリティーに対する直列化及びストリーミングのオーバーヘッド(機械内に含まれる場合)を回避する。暗号化は不要である。接続は、有効性が検証かつ認証され、セットアップ時に許可され、無効化されず、適切であれば、プロセスは大規模な独自のメモリ構造を共有できる。
【0128】
プロキシ470及びTereonコードモジュール450及び460の全ては可能であれば、ゼロコピーネットワーキング及びユーザモードネットワーキングを支援する(必須のRCP/IPライブラリーでコンパイルされる場合、HTTPプロキシはネットワークパケットに対するカーネルコンテキストスイッチの相当なコストを削減できるソリューションを提供する)。これは、プロキシ470及びTereonコードモジュールが使用できるネットワークドライバ特定のコードを介して容易になる。これにより、小さなパケットの要求及び応答に対するメモリ使用を最小化できる。これは膨大なTereon動作(ここで多くの動作は単一TCPパケットに適する)を構成する。
【0129】
図4aは、TereonシステムがTereonシステムの任意の2つのコンポーネント(例えば、Tereon内の機能を提供するHTTPゲートウェイ406a及びマイクロサービス410a)の間でデータを効率よく交換するために用いられる共有メモリを使用できるオーダーメード型セマフォハンドオフモジュール408aのセットを実現する方法を示す。図4aにおいて、データサービスレイヤ214は、マイクロサービス410aによって実現される。しかし、マイクロサービスは、全ての種類のサービスモジュールを示すことができる。
【0130】
ネットワークスタック404a(ループバック仮想デバイスを含む)は、接続サーバ402aから要求を受信及びアセンブルし、これをユーザモードターゲットメモリにコピーする代わり、単にメモリ承認の所有権を受信者(この場合にはHTTPゲートウェイ406a)に渡す。これはメモリ帯域幅の飽和が発生し始める極めて大きい負荷(例えば、秒当たり数百万の要求)で主に有用である。
【0131】
カスタムTereonアップストリームHTTPゲートウェイモジュール(custom Tereon upstream HTTP gateway module)406aは、ローカルインスタンス(一般的に各コンテナ又はそれぞれ物理的、論理的、又は仮想機械上にHTTPゲートウェイインスタンスがある場合にはHTTPゲートウェイインスタンスに関し)がゲートウェイからモジュールにプロキシメモリに対するメモリ伝達及び共有メモリを使用するためのオプションを許容し、その反対の場合も、該当のアップストリーム接続を許容する。HTTPゲートウェイ406aが既存のメカニズムを介して要求を直列化してこれを伝達する代わりに、共有メモリアップストリーム提供者のために構成されるとき、HTTPゲートウェイ406aは受信者に伝達する共有メモリを使用する。
【0132】
この場合に、共有メモリは、他のHTTPゲートウェイ、HTTPゲートウェイインスタンス、又は他の要素をプロキシに使用して設定される。HTTPゲートウェイを使用することは特に効率的である。
【0133】
運営システムカーネルによって提供される通信フックを使用する代わりに、各データ交換モジュールは、カーネルをバイパスする。これにより、カーネルオーバーヘッドを回避してシステムの処理量を増加させ、データがカーネルによって提供されるサービスに/から伝達されるとき発生しうる不安定な領域を扱う。例えば、Tereon内のモジュールは、システムコンポーネントから直接データサービスレイヤ214に、及びデータサービスレイヤ214からシステムコンポーネントにデータを効率よく交換するために用いられる。
【0134】
このアーキテクチャーがもたらす利点の他の例は、HTTPゲートウェイ406aの向上した効率(HTTPゲートウェイ406aがデータサービスレイヤ214又は他のコンポーネントのようなマイクロサービス410aに対する全ての入力データ、及びマイクロサービス410a又はデータサービスレイヤ214からの全ての出力データをHTTPゲートウェイ406aにハンドオーバーにするハンドオフモジュール408aを用いて達成される)である。基本HTTPゲートウェイのデータ及びメッセージングハンドオフを使用する代わりに、それ自体が効率的で、共有メモリを使用できるセマフォハンドオフモジュールは、データがカーネルを迂回し、データレーサー214からHTTPゲートウェイ406aに、及びデータレイヤ214から直接伝えられるようにする。これは、システムの処理量を増加させるのみならず、HTTPゲートウェイを使用するシステムにおいて共通の弱点領域のうち1つを保護するという点で追加的な利点がある。
【0135】
共有メモリチャネルを提供するモジュール又は共有メモリチャネルと通信するモジュールは、要求をバッチ及び直列化したり逆直列化して分離する。該当のタスクを行うモジュールは、該当モジュールの機能及びモジュールが正常に作動するとき発生する処理オーバーヘッドに達することになる。例えば、ある場合には、それ自体が複数のメッセージ(要求であってもなくてもよい)を受信するモジュールは、受信者モジュールに対してそのメッセージをバッチ及び直列化する共有メモリモジュールにメッセージを伝達するが、バッチ及び直列化のオーバーヘッドが効率的かつロード時にメッセージを処理する他の方法から該当モジュールを妨げるためである。他の場合に、モジュールは、共有メモリチャネルを介して該当受信者にバッチを伝達する前に、そのメッセージを特定の受信者にバッチ及び直列化し得る。
【0136】
更なる場合では、メッセージを受信者モジュールに伝達するモジュールは、メッセージをバッチ及び直列化するために共有メモリチャネルを提供するモジュールに依存し得るが、バッチメッセージを受信するモジュールは、それ自体がメッセージを逆直列化及び分離し得る。どのモジュールがバッチ及び直列化、又は、逆直列化及び分離のタスクを行うかに対する問題は、いずれかの選択によりモジュールが行う機能のための最適性能レベルを提供するかにかかっている。バッチ及び直列化の順は、メッセージタイプ及び通信モジュールによって提供される機能に応じて異なる。
【0137】
Tereonは、ウェブサービスになるためHTTPゲートウェイ406aを使用し、ネットワーク運営者が非標準サービスを遮断する潜在的な問題を回避する。Tereonは、勿論、必要に応じて、任意の他のサービスのふりをすることが可能であるため、周知のネットワークセキュリティー構成を容易に作業でできる。
【0138】
このような設計により、システム(このシステムは、利用可能な資源を使用するように設計されたモジュールを使用)は、全体のアーキテクチャーに通じてこのモジュラーアクセス方式を採用し、可能な場合、オーバーヘッドを回避する。追加的な例として、ネットワークスタック404aでゼロコピーネットワーキング又はユーザモードネットワーキングを支援するモジュールのネットワーキングシステム(可能な場合にTereonを使用)である。これにより、ネットワーキングに対するカーネルを使用する多くのオーバーヘッドを避けることができる。また、モジュラー設計は、Tereonがシステムの多重タイプ(類似オーダーメード型モジュールが類似機能を提供し、各運営システム又はハードウェア構成に適するようにカスタマイズされる)で動作可能にする。
【0139】
図3及び図4に示された方式により、仲介者を使用することは内部機械又は外部機械の全ての通信に対する中央集中制御地点を許容する。これは、速度及びセキュリティー制御、モニタリング及び監査、及び特殊な規則又は再指示に対する単一制御地点である。これにより、ダウンタイムや重大なリスクを招くことなく、システムの運営中にもシステムを柔軟に展開できる。また、クライアントの認識又は複雑性なしに、ロード分散(load-balancing)及びリダンダンシー(redundancies)を容易にする。
【0140】
図3に示すモジュール350がターゲットモジュール360に通信することを所望する場合、仲介者の使用は、ターゲットモジュール360が「n」機械にわたってロード分散し、仲介者を単に再設定する代わりに、全ての潜在的クライアントを再設定することなく、任意の数又は機械のタイプ間で移動可能にする。
【0141】
システムは、2つの通信当事者が互いのキー交換を認証する機能を提供するために生成されたPAKE(password authenticated key exchange)プロトコルを使用する。これは、異なる周知の共用キー交換プロトコル(例えば、Diffie-Hellmanキー交換プロトコルのような、中間者攻撃にプロトコルを脆弱させる)に対しては不可能である。正しく使用される場合に、PAKEプロトコルは中間者攻撃の影響を受けない。
【0142】
Tereonが外部デバイス又はサーバのような外部システムと通信する場合、通信システムに追加レイヤが追加される。多くのキー交換プロトコルは、中間者攻撃に理論的に脆弱であり、通信が2つの知られたエンティティ間にあることを確認するために、認証書及び署名されたメッセージを用いて接続が設定されれば、システムは、第2セキュリティーセッションキーを設定するためにPAKEプロトコルを使用することから、通信は中間者攻撃に影響を受けない。したがって、通信は、TLSセッションキーを用いて、次の全ての通信を暗号化するためにPAKEプロトコルのセッションキーを使用する。
【0143】
不可避の識別ストリングを有するデバイスと通信する場合、必要に応じて、TLSは省略され、PAKEプロトコルがメインセッションキープロトコルとして用いられる。例えば、デバイスがモノのインターネットのコンポーネントのセットを形成する小型のハードウェアセンサである場合に発生し得る。
【0144】
・通信方法(Communication methods)
Tereonデータサービス214は、調整トランザクタ(1つ以上のトランザクションの全て又は一部を実行、管理又は制御するデバイス又はモジュール)を介して完全なACID保証を提供し、n+1又はそれより大きいリダンダンシー及び選択的多重サイト複製を提供するグラフ機能を有するキーバリューストアーに基づく。データサービス214は、共有メモリ機能の他に、ゼロコピー機能及び無制限の読み出しスケーリング、インメモリキャッシュ、及び非常に高いレベルのレコード性能を提供するデータ)ドメインサービスにカプセル化される。これは、大量のメモリキャッシュを従う、可変サイズデータクラスタで保持される。非常に独特の状況では、データサービスは、キーバリューストアーを直接使用するために回避され得る。
【0145】
データサービス214は、高い性能の基本SQLスタイル機能と共に、貨幣の流れ分析のような機能を支援するグラフ処理機能を提供する。極めて高性能なモジュール通信アーキテクチャー(プラットフォームの効率性及び性能を提供する)と結合されたデータサービス214は、汎用サーバハードウェア(結合された10Gbpsネットワーキングを有する)のテストにおいて、秒当たり280万トランザクションを超える極めて効率的な設計を提供する。
【0146】
以下のアーキテクチャー上の優先順位を実現することで、システムはシステム内及びシステム間で送信されるメッセージを処理するために必要なカーネル及び処理コンテキストスイッチ数を大幅減らすことができる。
【0147】
a)ゼロコピーネットワーキングは、ネットワークエッジからサービスまでの送信コストを最小化できる。
b)ユーザモードネットワーキングは、ネットワークエッジからサービスまでの送信コストを最小化できる。
【0148】
c)直列化が必要な場合(主に、機械又はサーバの境界を越えるとき)、高効率の直列化は、SOAP(Simple Object Access Protocol)のような高いオーバーヘッドの直列化とは対照的に、プロトコルバッファ又はAvroで用いられる。これは、各サーバのエッジで抽象化されているため、性能及び効率性レベルが低くても、特定のサーバがインターネットを介して他の大陸(continent)のピアサーバで容易に通信できる。
【0149】
d)サーバは、処理コンテキストスイッチを最小化し、特定のサーバに対するキャッシュ一貫性を最大化にするための要求を、バッチ処理することを試みるバッファリング閾値を設定できる。例えば、サーバAに10000個のリクエストが20ms期間内に到達し、プラットフォームが20msバッファウィンドウを目標とし、該当10000個のリクエストのためにサーバBの支援が必要な場合に、10000個のリクエストを単一のリクエストとしてまとめた後セマフォをフラグ(flagging)し、サーバBに対する非同期メッセージを待機させる。その後、サーバBは、10000個のリクエストを迅速に処理し、サーバAに単一の応答を提供できる。これは、効率と最大応答時間の最適化に基づいて構成できる。
【0150】
実際に、カーネル及びプロセスコンテキストスイッチの数を減らすことで、プラットフォームの性能レベルが大幅改善された。メッセージごとに多くのカーネル及びプロセスコンテキストスイッチが発生するのではなく、Tereonモデルは、通信されるメッセージのバッチによってメッセージのブロックごとに多くのカーネル及びプロセスコンテキストスイッチを発生させる。テストによると、このモデルを用いて既存のモデル及びTereonモデル間の性能差は大きく作業負荷に対して1:1000以上になる。
【0151】
しかし、モジュール及びその利点は単一システムに制限されない。例えば、サーバA及びサーバBが個々の機械にある場合でも、Tereonシステムは効率的な直列化及びバッチ処理を使用できるのであろう。これは選択的なゼロコピー又はユーザモードネットワーキングと組み合わされるかどうかに関わらず、Tereonモデルは、ネットワーク及び処理性能を大きく向上させる。
【0152】
テストにより、このような設計要素は、超高速ネットワークワイヤー(例えば、10Gpsボンディング)を介して毎秒数千万のメッセージ要求及び応答のアラウンドトリップ(バッチ、共有メモリモード)でローカルサーバ間のサーバ運営を実証したことを示した。
【0153】
このようなトランザクションは、全てリアルタイムで処理され、すぐに調整されるために、特に銀行、IoT、医療、ID管理、輸送、及び正確なデータ処理が必要な環境では多くの長所がある。特に、このようなシステムは、現在のリアルタイムでトランザクションを調整しない。その代わりに、トランザクションは、一定期間の後に、時にはバッチで調整される。例えば、金融トランザクションは通常、数時間後に実行される別途の照会プロセスを用いてバッチ処理される。Tereonシステムを使用することで、銀行は今まで不可能であった方式により、全ての金融トランザクションをリアルタイムに調整できるようになる。その結果、銀行は、全てのトランザクションがそれを処理されるとき調整されるため、正確に調整されないか、又はまだ調整されていない金融トランザクションをカバーするために調整アカウントを保有する必要がなくなる。
【0154】
トランザクション及びデータ分割
Tereonシステムの全ての原子処理(atomic activities)はトランザクションである。トランザクションに対するACID保証を裏付けるシステムの基本的が要求事項として、それらは全体的に失敗したり、全体的に成功する。このセクションは、これがどのように実行されるかに簡単に説明し、Tereonがトランザクションに対するACID保証を達成する上での分割の影響を緩和するために、トランザクション及びデータ分割対して行ったアクセス方式の詳細を説明する。
【0155】
上述したように、Tereonプラットフォーム内の各データ処理は、Tereonデータサービスインスタンス214(それ自体がマイクロサービス410aの組みとして動作できる)を介して実行される。これは直接データプラットフォームアクセスのある唯一システムのコンポーネントである拡張されたサービス(指向システム)であるため、全てのデータ処理はこれを通過しなければならない。このようなデータサービスは、インスタンスキャッシュデータMVCC(Multiversion Concurrency Control)を用いて常に一貫した読み出しデータを有する様々なデータサービスインスタンスを介してシステム内の並列トランザクションを実行するように拡張される。
【0156】
データ処理は、データサービスインスタンスへの原子メッセージを介して行われ、全体データジョブ(job)を含むメッセージと共に発生する。例えば、ジョブには数個のレコード及び属性を読み出したり、従属データ(dependent data)に基づいたデータのアップデート又は挿入、あるいはタスクの組合せを含んでもよい。データサービスインスタンスは、全てのバッキング(backin)、トランザクションデータストアーにわたって2フェーズコミットトランザクション(two-phased commit transaction)として実行する。
【0157】
Tereonモデルは次の技術によってデータの一貫性を保証する。
a)読み出しデータのどのセットにもバージョンIDがある。
全てのレコード(アップデート及び従属挿入)は、このバージョンIDが楽観的トランザクションとして全ての関連データに対して最新であるかを検証する。これは、様々なアカウント属性(例えば、許可(permissions)、残高(balance)、及び通貨データ(currency data))を取得するために3つのソースがレコードを読み出す場合、このデータのクラスタが一貫したバージョンIDが存在することを意味する。これらの値のいずれかがアップデートされるか、従属データがレコードされれば(例えば、金融の振込み)、バージョンIDが最新バージョンであるかが再び確認され、レコードが異なる場合(通貨の仮定が変更されたり、為替レートが変更されるなど)、レコードは全体として完全に失敗する。ダウンストリームサービスは、必要に応じて、重要な方式によりトランザクションを変更するか否かを再度読み出し、評価する。そうでなければ、トランザクションは再び提出される。再びトランザクションが失敗した場合、これは設定可能な再試行回数を超えて深刻なエラーが発生するまで繰り返す。深刻なエラーは、通常の状況ではきわめて珍しい。
【0158】
大多数の実際のシナリオにおいて、大量のトランザクション容量及びアカウントの多様性があっても、失敗した楽観的なトランザクションは発生しない。まれに、データは損傷することなく、処理のオーバーヘッドも最小限に抑えられる。このMVCC/楽観的なモデルは、使用されているプラットフォームが(例外的な状況で要求される規制上の削除を除く)永久履歴データベースの場合、削除されたレコードに対しても完全に保護する。
【0159】
b)与えられたデータパーティション(これはデータサービスの水平拡張とは別途の概念である)のためにプラットフォームへのレコード
多くのデータサービスインスタンスは、1つのデータパーティションから読み出し及び1つのデータパーティションでレコードされ、単一のデータサービスインスタンスは、複数のデータパーティションから読み出し及び複数のデータパーティションで全て格納する。全ての読み出し及びレコードは、必要に応じて、1つ以上の冗長動作バックアップ(redundant operating backup)と共に、単一のマスタトランザクタクインスタンス(single master transactor instance)222を介して発生する。しかし、単一のインスタンスのみ常に活性化する。これは、トランザクション及び因果的な妥当性が全ての状況(例えば、ネットワーク分割中、又は短時間の通信遅延中にスキューが発生しない)下で保持されることを保障する。このトランザクタは、全ての楽観的なトランザクションが有効であるか否かを確認し、該当のインスタンスに対して文脈上重要なものとしてアップデートされた最新情報でデータサービスインスタンス内のキャッシュ管理者を持続的にリフレッシュする。
【0160】
c)選択的なデータ分割
単一トランザクタに制約されれば、極めて大きいTereonインスタンスの拡張性を潜在的に制限される可能性がある(単一の組織が地域ごとに多重Tereonインスタンスを管理できるということを理解)。データ分割は、Tereonデータサービスクラスタがドメインごとに構成されたTereon規則に基づいて、トランザクタドゥル222又はデータストアー224にわたってデータを分割できるという概念である。Tereonプラットフォームは、現在、異種、多重コンポーネントハッシュ戦略として、次のパーティショニング規則を支援する。
【0161】
i)与えられた要素又は上位要素の対象データにハッシュ(例えば、親レコードにより詳細ハッシュ)。高性能ハッシュは、パーティション数と同じカーディナリティ(cardinality)を有する。
【0162】
システムは、再調整(rebalancing)を現在提供しないため、将来の実現で再調整が提供されても、現在の実現でハッシュは前もって行う必要がある(起源の日時によるハッシュを含む多重部分規則(multi-part rule)を用いてパーティションが現在追加されることができる)。
【0163】
ii)与えられた要素又は任意の上位要素(例えば、挙げられた地理的な地域ごと、A~K又はL~Zなど姓別、通貨別、その他)のターゲットされたデータのハッシュが構成されたデータ。
【0164】
データターゲットハッシュは、アルファニューメリック(alphanumeric)、ユニコード(unicode)、及び他の文字コード範囲、整数範囲、浮動小数点範囲、及び挙げられたセットを支援する。
【0165】
iii)上記の組合せ
実現例において、二文字A及びBは、地理的な地域全体にわたって該当地域の2つの部分を示す数字1及び2で共通の2つの個別データセットを示す。例えば、単一パーティション規則は、地理的な地域のような最上位レベルパーティション1AB及び2AB間の分割を支援し、次に、アカウント番号ハッシュを介してA及びBサブパーティション間の分割をさらに支援する。
【0166】
d)単一のデータサービスインスタンスを介して実行される単一ジョブは、複数のデータパーティションを横断し、多重トランザクタドゥルにより完了され、複数のデータストレージノードに存続する。
【0167】
これは明白なデータ無欠性複雑さを示す。しかし、データの無欠性は、トランザクションの全ての構成要素が単一の2フェーズコミットラッパー(single two-phased commit wrapper)にバインドされていることにより保障される。全ての永久的なノード及びアクターに対するトランザクションの全体が、全体として完了又は失敗し、全ての同じバージョンの保証を提供する。
【0168】
アーキテクチャーの設計の合流の結果、システムは完全にトランザクション的に安全で、冗長性が高く、水平的かつ垂直的に拡張性が高くなる。レコードトランザクション(多くのシナリオで小さいパーセントの処理を含む)は、パーティションごとに単一トランザクタのトランザクション上の必要によって制限されるが、規則ベース分割の付加(特に、優れたデータ要素)は、分岐インスタンスを検討する前に、概念的に無制限のレベルでシステムを拡張できる柔軟性を提供する。
【0169】
Tereonデータストアーの実現
Tereonインフラストラクチャーは、1秒当たり1000000を超えるACIS保障トランザクションを処理する。これは、個別の読み出し及びレコードアクセスチャネル226と共に、ストレージレイヤに対する高性能キー/値分散データベースを用いて分散したデータベース又はデータベース224上にデータストアーレイヤ220を抽象化又は他の方法により実現することによって達成される(これは、Tereonデータサービスによって抽象化からストレージレイヤに対する直接データベース使用に至るまで全ての深層レベルであり得る)。Tereonのデータストアーの使用及び構成は独特である。
【0170】
データサービスレイヤは、そのオーダーメード化データ交換モジュールを介してデータストアーレイヤと通信する。データベース自体は、データストアーレイヤ220によって処理されるACID保証を提供する必要が全くない。これがレコードプロセスを著しく遅延させるため、それらはグラフ機能を提供する必要もない。データストアーレイヤ220は、異種データレイヤに対するインタフェースを提供し、システムの他の部分が必要とするインタフェース機能を提供する。したがって、書き込み効能は高速のセル及び列構造を提供する一方、読み出しインタフェースは、グラフィックインタフェースを提供し、マイクロ秒で分散データストアーをトラバースできるようにする。
【0171】
データストアーレイヤは、コアデータストアーデータベースの上にSQLインタフェース及びグラフィックインタフェースレイヤを提供し、Tereonを区分する多くの重要なアーキテクチャー長所を提供する。各クライアントインスタンス(Tereonデータサービスインスタンス)214は、該当インスタンスに対する全てのホットデータのキャッシュされた表現を含むインメモリ/インプロセスデータベースエンジンをホストする。その結果、インスタンスはデータベースエンジン及び全ての現在のトランザクションデータのキャッシュされた表現、各現在のトランザクションの状態、及び該当インスタンスが動作中の機械又は機械の異なる高速メモリ又はそのRAMの部分内のインスタンスの現在状態に関する全ての異なる情報をホストする。
【0172】
これにより、Tereonデータサービスが極めて高速レートで多くの読み出し指向のタスクを容易にし(1秒当たり、インスタンスごとに数百万の分離されたクエリ、ここで、ホット関連データはローカルでキャッシュされる)、達成される性能レベル以上の重要度(magnitudes)は、外部データベースシステムへの外部又は機械以外の要求を直列化して行う。データがインプロセスキャッシュにない場合は、キーバリューストアーから検索される。
【0173】
MVCCバージョンシステムは、同時性を管理するために使用され、データレイヤの属性はデータが決して削除されないこと(規定準拠のための強制削除の他)、システムは、データシステムの存続期間中全てのレコード変更の全ヒストリーを保有する。これによって、「as of」クエリ、及び全てのプラットフォーム変更の監査のような簡単な作動を可能にする。
【0174】
データレイヤの書き込み実現は、単一の共有トランザクタを使用し、全てのデータ変更は一連の高速シーケンスで処理される。これはトランザクションの有効性、一貫性、多くのデータベースプラットフォームで負担となる加重値である変更同時性オーバーヘッドを最小化する。トランザクタクの設計は、ホットバックアップリダンダンシーモデルを使用する。トランザクタクプロセスが変更されれば、これは全ての活性クエリエンジン(この場合、Tereonデータサービスに存在)を通知し、必要に応じて、インメモリキャッシュをアップデートする。
【0175】
この設計は、データストアーのサイズに関係なく、読み出し、書き込み、及び検索に対するマイクロ秒の待ち時間を提供する。また、動作に影響を与えることなく、コンポーネントのアップデート及び交換を可能にするモジュラー構成を提供する。このデータストアーは、既存となる実現から抽象化され、Tereonデータサービスの他のストアーに代替されてもよい。
【0176】
データストアーレイヤが悲観的なACID保証226で動作するように設定された場合、すなわち、次のトランザクションに進む前にレコードを書き込んだことを確認するための追加ステップを入れる場合、これは短い遅延を追加するが、ACID一貫性及びデータ無欠性の絶対的な保証を提供する。
【0177】
この設計の利点は、データレイヤがレコードを書き込んでトランザクションを完了したことをデータレイヤが確認するまで進行できないため、ACID保証を提供するのである。
【0178】
これは、例えば、銀行、支払い、及び因果関係を維持しなければならない他のトランザクションタイプでは、最終的な一貫性により発生した問題が除去されることを意味する。また、ACID保証で設計することで、銀行システムが不一致なプロセスを発見するとき、不足分を補うための調整アカウントに対する必要性もなくなる。リアルタイム処理は、最終的な一貫性システム上で調整プロセスが発生する時間遅延も除去されることを意味する。
【0179】
このプラットフォームの設計は、汎用ハードウェア上の極めて高いレベルのリダンダンシーと安定性、及び優れた拡張性(垂直及び水平的の両方)を提供する。トランザクタクシステムの可能性のある限界に対する理論的な懸念は、それらの限界を克服するためにデータサービスで分割プラットフォームを構築したが、多くのシナリオの下では該当のプラットフォームを使用する必要がない。
【0180】
ルックアップ/ディレクトリサービス
Tereonシステムは、ユーザ又はデバイス218がどのようなサーバに登録されるか、又は、特定の機能、リソース、設備、トランザクションタイプ、又は、他のタイプのサービスを提供しているサーバを識別するシステムにおいてクリデンシャル及び情報のディレクトリであるディレクトリサービス216を有する。ディレクトリサービスは、特定ユーザに関する様々な異なるタイプのクリデンシャルを格納するため、ユーザ218の複数の認証方法を可能にする、例えば、ユーザ218は、自分のモバイル番号、メールアドレス、地理的位置、PANs(primary account numbers)などを用いて認証され、毎回認証する必要がないようにデータをキャッシュする。
【0181】
ディレクトリサービス216は、基本サービス、サーバ、及び実際のユーザアカウントからユーザの認証IDを分離する抽象化レイヤを提供する。これは、ユーザ218又はマーチャントがサービスにアクセスするために使用できるクリデンシャル、及びTereonがサービスそのものを行うために必要な情報間の抽象化を提供する。例えば、支払いサービスでは、ディレクトリサービス216は、単にモバイル番号のような認証ID、サーバアドレスと共に恐らく通貨コードをサーバアドレスとリンクさせるのであろう。ユーザ218が銀行アカウントを保有しているか否か、ユーザ218がどの銀行を使用しているかを決定する方法は全くない。
【0182】
システムアーキテクチャーにより、Tereonが既存システムの範囲を簡単に越える様々な新しいサービス又は機能を提供する。
Tereonシステムアーキテクチャーは、拡張可能でリダンダントシステムを許容するため有効である。銀行コアシステムは、例えば、カード管理、Eコマース、モバイルの支払いなど、個別チャネル専用のモジュールを提供する傾向がある。これはサイロ(silos)を強化され、そのITシステムの複雑性を増加させる。このような複雑性は、銀行が自身のサービスやシステムを定期的にアップデートできない理由の1つである。
【0183】
Tereonは、高度な構成及びオーダーメード可能なモジュラーアーキテクチャーで全てのデバイス及び全てのユースケースを支援されるように設計されている。この核心は、上述したSDASF104、高レベルの抽象化、ビジネス規則エンジン106である。これは、Tereonの柔軟性を可能にする拡張可能なフレームワークの組合せである。
【0184】
Tereonは、運営者が標準キャリアグレードシステム(standard carrier-grade systems)を使用し、様々なトランザクションタイプを提供及び支援する。Tereonは、トランザクションが認証を必要とするか否かに関係なく、全てのトランザクションを支援するのであろう。
【0185】
スペシャルプロセス
スペシャルプロセス208は、データサービスの機能を理想的に活用する。しかし、独特の要求事項がコアデータサービスを変更又は拡張する正当化しないインスタンスがあるため、データライブラリーはデータから直接もってくるためにスペシャルプロセス内に活用される。例えば、これはAML(anti-money laundering)、CRM(customer relationship management)、又はERP(enterprise resource planning)機能のようなグラフィック機能プロセスを含んでもよい。
【0186】
複数のサービス
各サービスがモジュールであるため、Tereonのモジュラー構造は様々なタイプのサービス及びデバイスを支援し得る。例えば、支払いにおいて、この構造はTereonが銀行、請求カード、クレジットサービス、クレジットユニオン、デビットサービス、従業員制度、ePurse、ロイヤリティー制度、メンバーシップ制度、小額金融、前払い、学生サービス、発券、SMSの知らせ、HLR検索などを含んで複数の支払いタイプ及びデバイスを支援することを可能にする。
【0187】
マルチエンドポイントデバイス(Multiple end-point devices)
Tereonモジュラー構造により、磁気ストライプカード、スマートカード、フィーチャーフォン、スマートフォン、タブレット、カード端末、POS(point of sales)端末、ATM、PC、表示画面、電子アクセス制御、Eコマースポータル、リストバンド及びその他のウェアラブルなどを含み、直接または間接的に通信可能な全てのエンドポイントデバイスを支援する。
【0188】
多重データベース(Multiple databases)
モジュラー構造は、システムが1つのデータベースに制限されない点で異なる利点がある。代わりに、様々なデータベースは、問題のデータベースに固有モジュールでそれぞれ接続され得るため、特定の目的に特定データベースを使用したり、複数の異種データベースにわたるデータレコードの組合せを使用する。
【0189】
ライセンスサブシステム210の実現は、これが提供する許可及び認証の利点に加えて、ライセンス目的のための認証書機関のその使用において新規である。各モジュールは、相互の主張を信頼する代わりに共有データベースとの簡単な認証を使用するか、各接の続構築時に個別ライセンスサーバへの委任(性能及び安定性のオーバーヘッドを従う)がモジュール基幹システムに対する最も一般的な実現パターンである。Tereonで、ライセンスサブシステムは、モジュール間の接続が本質的に安全で、最小限の性能及び安定性オーバーヘッドでアクターに関する信頼できる検証済みのメタデータを有することを保障できる。
【0190】
また、この実現は、ライセンスサーバの侵害(compromise)のインスタンス内潜在的な脆弱性の範囲も制限する。従来の展開では、このような侵害は全てのコンポーネントの大規模な再構築に値するのであろう。Tereonモデルでは、新しい仲介者の署名認証書を要求する(ハードウェアセキュリティーモジュールによって保護されない場合)時間ベースの露出がある。事前感染が付与された既存の全ての認証書は古く、正常なスケジュールに更新され得る。新しい認証書は新しい権限の下で付与され、その他の不正な認証書は侵害されているとして拒否される。この露出ウィンドウ制御は、最悪のシナリオに役に立つ。ライセンスサーバが保有しているデータは、ハードウェアセキュリティーモジュールに理想的に保管される署名認証書の個人キーの外部にある、完全に権限のない情報である。
【0191】
また、Tereonの設計は、モバイル又はIoTデバイスのようなエンドポイントデバイスを、そのようなサーバネットワーク一部として他のTereonサーバと通信する小型のTereonサーバと組み合わせることができる。それらはデータを収集し、処理を調整するためにTereonライセンスサーバ210、及び恐らく1つ以上の運営者が運営するTereonサーバと通信するのであろう。それにもかかわらず、エンドポイントデバイス及びTereonサーバの間の区別(全ての区別はデバイス及びサーバが置かれているユースケースにのみ基づく)は抽象的なものである。
【0192】
ハッシュチェーン
ブロックチェーンの大きい短所の1つは、ブロックチェーンが以前の全てのトランザクションに対する監査を格納することである(すなわち、認証のために用いられるブロックチェーン内のトランザクションヒストリーを判断できる)。これはブロックチェーンのサイズが最終的に大きくなって現実的な時間フレームで管理できないことから、ブロックチェーンアクセス方式が無限に拡張できないことを意味し、一方、各ブロックのサイズがブロックチェーンが登録できる秒当たり最大トランザクションを制限することを意味する。
【0193】
第2の短所は、トランザクションヒストリーがブロックチェーンにアクセスできる人であれば誰でも使用できることである。そのため、トランザクション当事者が誰であるかを確認することができる。そのため、プライバシー及び/又は機密性の最も重要な要求事項である意味のある全ての処理において、ブロックチェーンを使用することに対する重大なプライバシー及び規制上の問題を提示する。
【0194】
更なる短所は、ブロックチェーンがトランザクションの結果又は最終レコードをハッシュすることができず、実際のプロセス又はトランザクション自体のステップを検証できないことにある。
【0195】
ここに開示されたハッシュチェーンは、トランザクション当事者間のレコードを非公開にし、Tereon全てのユーザ(それが公開または非公開のネットワーク上で動作するに関係なく)を含む分散した認証ネットワークを提供するため、特定ハッシュアクセス方法を使用して上記のような問題を克服しようとする。
【0196】
これは、第3者に基盤となる通信のコンテンツを公開せず、公開及び非公開ネットワークにわたってリアルタイム動作する分散チェーンの持続的な構成によって達成される。これは、分散したハッシュ又は元帳の標準モデルと直接的に対照される(ここで、全ての当事者は、全ての通信コンテンツをそれが該当通信に対する当事者であるか否かに関係なく報告、受け入れる)。
【0197】
ハッシュチェーンがゼロ知識証明を含むプロトコルを使用すると、トランザクションの各ステップ及び情報又はトランザクションのステップによって生成された結果を認証できる。
【0198】
実現は、同一の中間ハッシュを生成する通信に対する当事者、又は、同一の通信に対して固有な中間ハッシュを生成する、それが発生する可能性がある。また、この構造により、ハッシュチェーンの無欠性に影響を与えることなく、既存のアルゴリズムが廃止されることから、当事者は新しいハッシュアルゴリズムに移行できる。これは、ブロックチェーンのような既存のライブソリューションで用いられるアルゴリズムをアップデート又はアップグレードする困難さと直接的に対照される。
【0199】
Tereonは、トランザクションの各側面(アカウント)に対してハッシュ監査チェーンを生成する。ここで、
・Tereonはレコードに関するハッシュを生成し、該当レコードに対するハッシュを格納する。Tereonは、レコードを生成するアクションが完了すると、該当ハッシュを生成するが、レコードを生成するステップと該当ステップから発生する情報又は結果を使用するためである。
【0200】
・Tereonは、現在のレコードに対するデータの一部として前のレコードに対するハッシュを使用する、そして、
・全てのレコードチェーンの最初のハッシュは、サーバの署名、Tereonが該当ハッシュを生成する日時、必要に応じてランダム番号を有するランダムハッシュであり得る。
【0201】
このレコードが2以上の当事者が関与するアクションのレコードであり、各当事者がこのアクションの側面のレコードを保有しなければならない場合、Tereonはそれぞれのアクションについて次のことを行う。
【0202】
・他の当事者又は当事者と各当事者のレコードのハッシュを共有する。
・そのハッシュを使用して、レコードハッシュを生成するTereonに対する受信当事者のレコードの一部を形成する。
【0203】
・他の当事者又は当事者からのハッシュを含むレコードの中間ハッシュを生成する。
・各当事者が各アクションで他の当事者の一部をカプセル化したハッシュを有するように、該当中間ハッシュを他の当事者と共有する。
【0204】
・アクションのレコードに中間ハッシュを含む。
・アクションに対して格納し、次のレコードの一部として使用する最終ハッシュを生成する。そして、
・送信された各ハッシュ、又は、ゼロ知識証明を用いてプロトコルで生成された中間ハッシュを送信者のID又はTereon番号と関連づける。
【0205】
Tereonは、以下に説明するように、これに必要なACID保証及びリアルタイムセッショントランザクション及び処理速度を提供できる。また、ブロックチェーンの普及により、この分野における開発は考慮されていないことを意味する。
【0206】
トランザクションが完了ると、ブロックチェーンは、トランザクションのレコードをハッシュする。ブロックチェーンに伝えられたレコードが実際にトランザクションそれ自体の本物レコードであり保証はない。基礎となるハッシュ構造は、動的及びリアルタイムトランザクションではない静的データの収集用として設計されているため、ブロックチェーンは、正直に行動するその運営者の大多数に依存するため、この方式に制限される。ブロックチェーンそれ自体は、最終的な一貫性しか提供できない点でさらに限界がある。ACIDの一貫性は、トランザクションの時系列順ではなく、それらのトランザクションがブロックに組み込まれる順序、およびわずかに異なるトランザクションセットを含2つ以上のブロックが検出された場合のブロックチェーン内のフォーク管理のコンセンサスモデルによって決定される。
【0207】
図5は、4つのアカウント502、504、506及び508を含むハッシュチェーンの樹枝状特性(dendritic nature)を示す。アカウントは、同じサーバ上にあったり、個別サーバにあってもよい。各システムは、1つ以上のサーバを支援し、各サーバは1つ以上のアカウントを支援する。アカウントのある位置は関係ない。また、図5は、対のアカウント間に発生する5つのトランザクションを示す。アカウント502及び504との間に発生する2つのトランザクション、アカウント502及び506との間に発生する2つのトランザクション、及びアカウント506及び508との間に発生する1つのトランザクションがある。図面において、各ボックスは、列が最上位にあるアカウントに関するステップである。各ステップは、該当アカウント内における検索、又は、該当アカウント及び他に見えないアカウント又はシステムのような見えないアクション又はトランザクションを含む。これらのトランザクション又はアクションが何であるかは関係ない。重要なことは、それらが、この監査にTereonシステムレコードを何かを含んでいることである。
【0208】
ステップ510において、Tereonシステムは、このアカウントに対する以前のハッシュh502を取得する。上述したように、最初のハッシュはサーバの署名、Tereonがハッシュを生成した日時、必要に応じて、ランダム番号のあるランダムハッシュである。Tereonは、ハッシュをステップ510で発生するトランザクション又はアクションに対するレコードに追加し、その次に、このトランザクションに対するハッシュh512を算出するシードとして使用する。このステップでのレコードは、h502及びh512を含む。
【0209】
ステップ512において、システムは、アカウント504を保有するサーバとハッシュh510を交換する。これは、アカウント504に対するこのトランザクションに対するハッシュh504をレコードに追加し、中間ハッシュh512iを生成し、このレコードに追加し、その次に、アカウント504から中間ハッシュh514i(後述するように、ステップ514で生成される)で交換する。次に、このハッシュをそのレコードに追加してハッシュh512を生成する。
【0210】
ハッシュh512は、アカウント502からステップ512まで、及びアカウント504からステップ514の中間段階までのハッシュチェーンを有効にした情報をさらに含む。レコードは、h510、h512i、h514i、h504、及びh512を含む。
【0211】
ステップ514において、システムは、アカウント502を保有するサーバとハッシュh504を交換する。これは、アカウント502からのハッシュh510をレコードに追加し、中間ハッシュh514iを生成し、これをレコードに追加し、次に、これをアカウント502からの中間ハッシュh512iと交換する。次に、それからこのハッシュをレコードに追加してハッシュh514を生成する。
【0212】
このチェーンは、アカウント502からステップ512まで、及びアカウント504からステップ514までハッシュチェーンを有効にした情報をさらに含む。
この順は、上述したように、まったく同じ方式に基づいてトランザクションに対するハッシュを生成するためにアカウント502、504、506及び508間の追加トランザクションのために実行される。例えば、ステップ534において、システムは、ステップ528で生成されたアカウント502に対する以前のハッシュh528を取得し、監査レコードを発生させるトランザクション又はアクション(見えない)に対するレコードにこれを追加し、このトランザクションに対するハッシュh534を生成する。このチェーンは、ステップ534までのアカウント502、ステップ526までのアカウント504、ステップ530までのアカウント506、ステップ530において、h530を生成するために使用されたアカウント508からの中間ハッシュまでのアカウント508に対するハッシュチェーンを有効にした情報が含まれる。レコードh534及びh528を含む。Tereonは、ステップ530において、h524から生成されたh530iを含むレコードからステップ528でハッシュh528を生成する。ハッシュh524には、ステップ524において、h524を生成するために使用されたアカウント508から中間ハッシュまでのアカウント508を有効にした情報が含まれる。
【0213】
調整(Reconciliation)
詐欺師が以前のトランザクションのレコードを変更した場合、トランザクションが実行されないようにするため、最初の最後の「N」トランザクションについて調整できる。したがって、例えば、Tereonがステップ522で提示されるトランザクションを行う前に、これはアカウント502に対する以前「N」トランザクションまでステップ516、及び、恐らくステップ512などに対するハッシュをまず再算出することができる。監査追跡は、トランザクションのために最終ハッシュ値を再算出するための十分な情報を有する。同様に、アカウント504を保有しているシステムは、ステップ526、ステップ520などのためにハッシュを再算出してもよい。Tereonは、ステップ522のトランザクションのためにアカウント506に対する全てのハッシュを再算出する必要がない。
【0214】
ハッシュチェーンでは、レコードされたハッシュのいずれか1つが再算出されたハッシュと一致しない場合、これはレコードが認証なしに変更されたことを意味し、運営者はすぐに問題を調査したり追加トランザクションを遮断する。
【0215】
システムハッシュチェーン
また、システムハッシュは、各レコードに追加されてもよい。これはアクションがハッシュされたレコードが属するアカウントと関連があるかに関係なく、レコードのハッシュであり、ここで、シードはシステム上に以前のアクションのハッシュであろう。次に、システムハッシュが各アカウント内のハッシュチェーンに追加される場合、システム全体のハッシュチェーンが提供される。
【0216】
図6は、同一のシステム上の2つのアカウント602及び604を含むハッシュチェーンの樹枝状特性を図示して、全てのシステムイベントを記録する‘システムアカウント(system account)’は606である。システムはレコードが常駐する位置に関係なく、レコードを発生させる全てのアクションに対するレコードの新しいハッシュを生成する。h606、h608、h612等システムハッシュがある。
【0217】
図6は、同じシステム上の2つのアカウント602及び604を含むハッシュチェーンの樹枝状特性を示し、全てのシステムイベントを記録する「システムアカウント」は606である。システムは、レコードが存在する場所に関係なく、レコードを発生させる全てのアクションに対するレコードの新しいハッシュを生成する。h606、h608、h612などがシステムハッシュである。
【0218】
ステップ608において、Tereonはシステムの監査レコードでエントリをトリガーするアカウント602で見えないアクション又はトランザクションのレコードのハッシュを生成し(アカウント602に対するレコードは、該当アカウントに対する以前のレコードハッシュ、ハッシュh602を含む)、新しいシステムハッシュh602に対するh606を使用する。そして、システムは、トランザクションに対するレコードに対してこのハッシュをレコードし、ステップ610でアカウント602に対するハッシュh610を算出する。
【0219】
システムのコンピューティング性能が許容すれば、これはアカウントハッシュの動作を反映するシステムハッシュのために強力な変形を使用できる。
ステップ610において、Tereonは、システムアカウント606とハッシュh602をハッシュh606で交換する。これは、システムアカウント606からのハッシュh606をそのレコードに追加し、中間ハッシュh610iを生成する。システムの監査レコードへのエントリをトリガーし、レコードにハッシュを追加するアカウント602での見えないアクション又はトランザクションを完了した後、これを生成する。その次に、Tereonは、中間システムハッシュh608iでこの中間ハッシュを交換する。その後、これとh608をそのレコードに追加して新しいアカウントハッシュh610を生成する。
【0220】
ステップ612において、Tereonは、ステップ608で生成されたハッシュh608をアカウント602及び604と交換する。ステップ610で生成されたh610、及びh604をそのレコードに追加して中間ハッシュh612iを生成する。アカウント602及び604とそれらの中間アカウントシステムハッシュh614si及びh616si、及びアカウント602に対応する中間ハッシュh614i及びアカウント604に対応するh616iで交換する。その後、新しいシステムハッシュh612を生成する。その後、システムはこのハッシュを記録する。
【0221】
ステップ614で、Tereonは、ステップ610で生成されたハッシュh610をシステムアカウント606と交換する。これはシステムアカウント606からのハッシュh608(ステップ608で生成)をレコードに追加し、中間アカウントシステムハッシュh614siを生成する。これは、アカウント604を用いてトランザクションを完了した後にハッシュを生成し(中間トランザクションハッシュh614i及びh616iを交換)、これをレコードに追加し、それからこれを中間システムハッシュh612iで交換する。その後、これとh618をそのレコードに追加してアカウントハッシュh614を生成する。
【0222】
ステップ616において、Tereonは、システムアカウント606とハッシュh604を交換する。システムアカウントからのハッシュh608をそのレコードに追加し、中間アカウントシステムハッシュh616siを生成する。アカウント602を使用してトランザクションを完了した後これを生成し(そして、中間トランザクションハッシュh614i及びh616iを交換)、ハッシュをそのレコードに追加し、それからこれを中間システムハッシュh612iで交換する。そのあと、これとh608をそのレコードに追加してアカウントハッシュh616を生成する。
【0223】
ステップ612において、システムがアカウント604に中間システムハッシュh614siを送信し、アカウント602に中間システムハッシュh616siを送信することが1つのオプションである。これは、これらのアカウントに対する最終レコードハッシュを意味し、h614及びh616は3つの中間システムハッシュh614si、h614si、及びh612iのレコードを含んでいるため、確実性の追加レイヤを提供する。
【0224】
システムハッシュチェーンは、個々のトランザクションの両側のハッシュのみならず、トランザクション全体的にハッシュチェーンを含み、ハッシュチェーンが大幅に強化する。
【0225】
Tereonが異なるシステム上にアカウント間のトランザクションを管理する場合、プロセスは、それらの各システムに対するステップ608及び610の場合と同様である。
【0226】
ライセンスサーバハッシュ(Licence server hashes)
ハッシュは、個別Tereonシステム間に生成されたハッシュに関連がある。このようなシステムが相互作用することから、それらのシステムの全てのトランザクションを検証された情報を含んだハッシュツリーに参加できる。しかし、このようなシステムが相互作用する速度でしか増加しない。システムは一層進んで、各サーバがすぐにグローバルハッシュツリーに参加できることを保証する別のレイヤを構築することができる。これはブロックチェーンとハッシュチェーンを完全に区別する。
【0227】
ブロックチェーン運営者がプライベートブロックチェーンを設定すると、該当ブロックチェーンは他の全てと別に作動する。全般的な処理速度が向上するのは別の方法で提供できる任意のセキュリティーで失われるが、ユーザがトランザクションの有効性を検査するために大規模ブロックチェーンのネットワークに依存できないためである。セキュリティーに対するブロックチェーンの主張のうちの1つは、攻撃者がセキュリティーを侵害させるために多くのブロックチェーンネットワークのノードを侵害させなければならない(ノードの25-33%程度の侵害はブロックチェーンを侵害させるのに充分である)。単一プライベートブロックチェーンは定義によりその数を1つに減らす。
【0228】
ハッシュチェーンを使用すると、プライベートTereonサーバ又はネットワークはさらにパブリックTereonサーバ及びネットワークによって生成されたハッシュチェーンからの利点を取得できる。プライベートTereonサーバ又はネットワークを運営するのは、運営者がTereonシステムの認証強度に対して妥協しなければならないことを意味しないが、該当システムが依然としてグローバルハッシュチェーンのメンバーであるためである。これは単に、トランザクション(ライセンスサーバに関連したその以外)が該当システムに対して完全にプライベートに保持されるのであろう。
【0229】
これを達成するために、全てのサーバは他のTereonサーバと相互作用するか否かに関わらず、ライセンスサーバと相互作用しなければならない。Tereonサーバが閉ループサーバとして動作し、該当のループが2つ以上のサーバから構成される場合に該当ループ内で他のTereonサーバとのみ相互作用するのであろう。
【0230】
ライセンスサーバハッシュを追加することで、全てのサーバはライセンスサーバと相互作用すると同時に(基本的に毎日行わなければならない)グローバルサーバハッシュチェーンに参加する。ライセンスサーバハッシュは、基本的にTereonサーバ及びライセンスサーバ間の2つのパーティートランザクションによって生成される。ライセンスサーバトランザクションは、Tereonサーバ間の基本データトランザクションに影響を及ぼさないということ以外にも、各サーバのためのシステムハッシュがライセンスサーバハッシュから派生した情報をさらに含むものであり、その反対の場合も同様である。
【0231】
図7は、ライセンスハッシュの樹枝状特性を示す。簡単な例で、システムサーバ702は、システムサーバ704及び706が相互接続する閉ループシステムである。3つのす全てはライセンスサーバ708と周期的に相互作用しなければならない。
【0232】
ライセンスサーバ708との最初質問において、各サーバはその公開キー、サーバが初めてライセンスが付与された日時、及びデータのランダムセットから最初のハッシュを生成する。
【0233】
ステップ710において、Tereonは、中間ライセンスハッシュh710iを生成するためにハッシュh708を生成し、それをレコードに追加し、これをサーバ702からの中間システムハッシュh712iと交換する。その後、これはこのハッシュをそのレコードに追加し、それからそのレコードに追加するライセンスハッシュh710を生成する。
【0234】
ステップ712において、Tereonは、中間システムハッシュh712iを生成するためにハッシュh702を生成し、それをレコードに追加し、これをライセンスサーバ708からの中間ライセンスハッシュh710iと交換する。その後、これはこのハッシュをそのレコードに追加し、そのレコードに追加するシステムハッシュh712を生成する。
【0235】
ステップ712において、Tereonは、中間システムハッシュh712iを生成するためにハッシュh702を生成し、それをそのレコードに追加し、これをライセンスサーバ708からの中間ライセンスハッシュh710iと交換する。その後、これはこのハッシュをそのレコードに追加し、そのレコードに追加するシステムハッシュh712を生成する。
【0236】
ステップ716において、Tereonは、中間システムハッシュh716iを生成するためにハッシュh704を生成し、それをライセンスサーバ708からの中間ライセンスハッシュh714iと交換する。その後、これはこのハッシュをそのレコードに追加し、そのレコードに追加するシステムハッシュh716を生成する。
【0237】
ステップ718において、Tereonは、中間ライセンスハッシュh718iを生成して、これをそのレコードに追加し、これをサーバ706からの中間システムハッシュh720iと交換する。その後、これはこのハッシュをそのレコードに追加し、そのレコードに追加するライセンスハッシュh718を生成する。
【0238】
ステップ720において、Tereonは、中間システムハッシュh720iを生成するためにハッシュh706を使用し、これをそのレコードに追加し、これをライセンスサーバ708からの中間ライセンスハッシュh718iと交換する。その後、このハッシュをそのレコードに追加し、そのレコードに追加するシステムハッシュh720を生成する。
【0239】
Tereonサーバトランザクションに対する3つのライセンスサーバは、次のような結果を取得される。
・ステップ712で生成されたハッシュh712は、以下の状態を検証する情報を含む。
【0240】
・中間ハッシュh710iまでライセンスサーバ708のハッシュチェーン
・ハッシュh712までサーバ702のハッシュチェーン
・ステップ716で生成されたハッシュh716は、以下の状態を検証する情報を含む。
【0241】
・中間ハッシュh714iまでライセンスサーバ708のハッシュチェーン
・中間ハッシュh702iiまでサーバ702のハッシュチェーン
・ハッシュh716までサーバ704のハッシュチェーン
・ステップ720で生成されたハッシュh720は、以下の状態を検証する情報を含む。
【0242】
・中間ハッシュh718iまでライセンスサーバ708のハッシュチェーン
・中間ハッシュhk702iiまでサーバ702のハッシュチェーン
・中間ハッシュh716iまでサーバ704のハッシュチェーン
・ハッシュh720までサーバ70のハッシュチェーン
・ステップ718で生成されたハッシュh718は、以下の状態を検証する情報を含む。
【0243】
・ハッシュh718までライセンスサーバ708のハッシュチェーン
・中間ハッシュhk702iiまでサーバ702のハッシュチェーン
・ハッシュhk704iまでサーバ704のハッシュチェーン
・ハッシュh720までサーバ706のハッシュチェーン
したがって、ライセンス及びシステムハッシュは、それらのサーバが相互接続されたか、閉ループで動作するか否かに関係なく、ネットワーク内の全てのサーバ上にトランザクションを検証するようにする情報が含まれる。
【0244】
Tereonは、ライセンスサービスによって作成されたハッシュチェーンと同様の方法で動作するルックアップディレクトリサービスを用いて、同様のレイヤを実現できる。
オフライントランザクション(Off-line transactions)
このアプローチを用いて、オフライントランザクションはデバイスとそれらのサーバ間の持続的な通信リンクを除去されなければならないため、オンライントランザクションと同じ有効性をもう有し得る。したがって、センサ、モバイル支払い端末、及びその他のようなデバイスは、互いに通信でき、データをダウンロード及びアップロードするために一定の間隔でそれらのサーバとを接続する。システムは接続環境と非接続環境との間で円滑に動作することができる。
【0245】
ハッシュチェーンは、デバイスが各サーバと通信できない間にあっても、それがオフライントランザクションに関与するか否かを決定するためにビジネス規則を使用し、その間のトランザクションを有効にして監査することを可能にする。デバイスは、それらが再度それらのサーバと接続されるとき、それらのサーバとそれらの監査及びトランザクションレコードを単に調整する。
【0246】
図8は、4つのデバイスのTereonサーバから一時的にオフラインされる4つのデバイスを含むハッシュチェーンの例を示す。そのうち3個802、804及び806は視角化される(ステップ828で4番目デバイス808はチェーンと相互作用する)。
【0247】
デバイス間のオフライントランザクションを支援するために、デバイス自身が参加する各トランザクションのハッシュを生成する。デバイスがオンラインに戻ってサーバと通信するとき、該当デバイスはそのトランザクションに対するハッシュをサーバに送信する。
【0248】
トランザクションを開始するデバイスがオフラインであれば、トランザクションに対するハッシュを生成して該当ハッシュを格納する。また、それは、相手側のデバイス(これがトランザクション中であるデバイス)に該当ハッシュを送信することで、相手側デバイスは第1デバイスにこのハッシュを送信する。これは、上述したハッシュチェーンと同じ方式により達成される。デバイスは、ブルートゥース、NFC、ローカルWi-Fiなどのような双方向チャネルを介して通信し得る。それらは、さらに異なる者が読み出すようにし、各トランザクションステージに対するこのコードをスクリーン上に掲示する。また、各デバイスは、自分のトランザクションレコードの署名済みの暗号化コピーを他のデバイスにも送信する。ここで、署名にはそのレコードの配信先サーバも含まれる。送信先サーバのみが該当レコードを解読できる。
【0249】
デバイスがそのTereonサーバと通信を回復すると、該当デバイスはこのオフライントランザクション及びそれらに関するハッシュの暗号化されたレコードをサーバに送信する。また、それはまた、相手側からのレコードなど、それが保有する他のトランザクションのコピーを該当サーバに送信し、その後、サーバはそれらのレコード及びそれらに関するハッシュを相手側デバイスが登録されているサーバに送信する。各デバイスは、トランザクションでこの部分を識別する自身の固有内部トランザクション番号(例えば、モノトニクカウンタによって生成されるもののような)を生成する。また、トランザクションがオンラインの場合、デバイスに接続されたサーバは、デバイスとサーバの両方が使用する固有のトランザクション番号を生成する。
【0250】
デバイスは、各トランザクションの因果関係を保持するために内部トランザクション番号と日時スタンプ、デバイスクロックスキュー(devices clock skew)に関する情報、及び他の情報を組み合わせる。それらの各サーバがトランザクション情報を受信すると、それらはトランザクションの順を再構成することができ、全てのデバイスに対するオンライン及びオフライントランザクションの両方の因果関係を保持する。
【0251】
図8を参照すると、ステップ812において、デバイス802はh812を生成するために、サーバ810からのハッシュh802、以前のレコードハッシュ、及びハッシュh810を含むトランザクションのレコードをハッシュする。その次に、このハッシュをサーバ810に伝達するが、ここで、該当ハッシュはステップ814でh814を算出するために用いられるレコードの一部を形成する。デバイス802は、このTereonサーバ810に接続されることを意味する。ここで、オンラインである。ステップ814において、Tereonは、サーバ810に対する以前のハッシュh810を使用し、これとh812をレコードに追加し、その次にh814を算出する。レコードはh810、h812、及びh814を含む。
【0252】
運営者がシステムハッシュを含むためにTereonを構成した場合、上述したように、ハッシュh814を算出する前にこれをレコードに追加する。その後、レコードは、h812、h810、関連する場合は中間システムハッシュ、及びh814を含んでもよい。
【0253】
ステップ816において、デバイス802はオフラインであるため、サーバ810に接続されることができない。これはデバイス804とトランザクションする。デバイス804も、この各Tereonサーバからオフラインである。デバイス802及び804は、ステップ818でデバイス802からの中間ハッシュh816、デバイス804からの中間ハッシュh818、デバイス802からのハッシュh816、及びデバイス804からのハッシュh818を生成するために、上述したハッシュの手続きに従う。デバイス802及び804は、自分のオフライン公開キーで自分のハッシュに署名し、他のデバイスにこれを該当トランザクションに対するレコードの暗号化されたコピーと共に伝達する。これはデバイス802の最初のオフライントランザクションであり(これはサーバ810と接触がなくなったため)、デバイス804の最初のオフライントランザクションである(このサーバと接触がなくなったため)。管理者は、アプリケーションがオフラインでトランザクションする固有のデバイスに、最後のn個までのトランザクションを送信できるようにシステムを設定する。
【0254】
この順はデバイス802及びデバイス804の間、及びデバイス804及びデバイス806の間のチェーン内の更なるトランザクションのために繰り返す。このようなトランザクションで、デバイス802及び804は、それぞれ既にコピーを保有しているため、以前のトランザクションについてハッシュ及びレコードを交換する必要がない。
【0255】
デバイス802は、ステップ830において、そのサーバ810と接触を再設定するまでこの方式で続けて動作する。デバイス802は、オフライントランザクション及びそれに関するハッシュ(一例でとして、ステップ816、822、及び826でそれぞれ生成されたh816、h822、及びh826)の暗号化されたレコードの全てをアップロードする。また、これはデバイス804、806、及び808に対して、保有する暗号化されたトランザクションレコード及びハッシュをアップロードする。サーバはこれらを格納し、各デバイス804、806及び808に対応するサーバにアップロードする。サーバ810は、デバイス804、806、及び808からのハッシュのレコードとこのアップロードをトランザクションで登録して、ステップ832でハッシュh832を生成する。デバイス802は、デバイス804、806、及び808からのハッシュのレコードとそれぞれのトランザクションレコードとをクリアし、ステップ830でハッシュh830を生成する。
【0256】
デバイス802は、ステップ820において、ハッシュh820及びh808を発生させるデバイス806及び808間のトランザクションに対するハッシュ及び暗号化されたレコードを保有する。この例では、オフライントランザクションがいくつ発生したか分からないため、h808を用いて該当トランザクションのために生成されたデバイス808に対するハッシュを参照する。
【0257】
サーバ810は、それがデバイス802から受信したオフラインレコードをデバイス804、806、及び808、ならびにそれらのトランザクションを含む任意の他のサーバから受信するものと調整する。サーバ810は、どのようなサーバからレコードを受信したか分かるのであろう。それは、これらはデバイス802に関するトランザクションのレコードが送信されたサーバに対応するためである。デバイス802は、デバイス808からのレコードを受信することを期待せず、デバイス802がデバイス808とトランザクションしていないためである。デバイス804又は806が他のサーバに接続されたオフラインデバイスとトランザクションした場合、サーバ810は、これらの他のサーバから追加レコードを受信することができる。
【0258】
サーバ810は、該当トランザクションの注文及び番号付けのためにトランザクションレコード及び署名に対する日時スタンプを使用して、それらをオフライントランザクションで表示する。
【0259】
オフラインモードは、様々な変形を提示する。最初は、中間オフラインハッシュを使用せず、各デバイスの以前トランザクションに対するハッシュを簡単に使用することにある。これは階層の確実性を失うが、よく作動する。第二に、オフライントランザクション専用のデバイスハッシュを生成することにある。これはオンライントランザクションを僅かに単純化するが、やはり階層の確実性は失う。第3に、変形は、特定のオフライン公開キーでオフライントランザクションのレコードに署名するのではなく、単にデバイスキーを用いて全てのレコードに簡単に署名することにある。アカウント監査追跡にレコードされるため、サーバ及びデバイスの両方は、どのトランザクションがどのオンライン及びオフラインであるかを確認できる。しかし、デバイスに対して個別キー及び一連のトランザクション番号を実行すると、オフライントランザクションとオンライントランザクションを示すことは簡単になる。
【0260】
第4の変形は、接続されたデバイスからオフライントランザクションのレコードを受信するとき、各サーバがそれらのレコードが適用される全てのサーバがそのサーバからのレコードを予想できるよう通知することにある。例えば、図8に示されたオフラインダイヤグラムにおいて、デバイス804が後でサーバに接続し、デバイス806が他のデバイス(図示せず)とトランザクションすることを仮定する。デバイス804がサーバに接続すると、該当サーバは、デバイス802に関するレコードをサーバ810に送信する。デバイス804は、他のデバイスとオフラインでトランザクションせず、他のデバイスについてのオフラインレコードを保有しない。一方、サーバ810は、デバイス804に対するレコードをデバイス804に対応するサーバに送信し、該当サーバにデバイス806から同じレコードのコピーを受信することを予想できるように通知する(ステップ826及び828においてトランザクションの間にデバイス802はこれをデバイス806へ伝達)。同様に、デバイス806がそのサーバに接続すると、該当サーバは、デバイス802に関するレコードをサーバ810へ、デバイス804に関するものをデバイス804に対応するサーバへ、デバイス808に対するものをデバイス808に対応するサーバへ、他のデバイスに対するものを各サーバに送信するのであろう。また、これはデバイス802(サーバ810)及び804に対応する両方のサーバに他のデバイスに対応するサーバからのレコードを予想するよう通知する。
【0261】
ハッシュチェーンを使用しても、Tereonにこれ以上の負荷がかかることはない。1つのアクションは2以上の当事者が関与することはほとんどなく、そのアクションは、一般的に、一対多(one-to-many)の送信になり、それ自体は一対一(one-to-one)の送信の集合となる。また、多対一(many-to-one)の送信は、一般的に一連の一対一の送信であり、これは単に2者間のアクション集合である。
【0262】
レコードの修正(Amending record)
ユーザがレコードを修正する場合、Tereonはオリジナルレコードを上書きしない。代わりに、Tereonは、単に修正されたレコードを含んでいる新しいレコードを生成し、これは、該当レコードが再び修正されるまでTereonが示すバージョンである。修正はアクションである。これは、前のトランザクション結果を効率よく修正する全ての金融及びトランザクションレコード(支払いなどのようなトランザクションの結果)で発生する。また、これは、運営者がEメール、医療記録などのような他のレコードタイプを管理するためにTereonのサブセットを使用する場合にも発生する。これにより、Tereonはレコードの各バージョンのコピーを保持する。
【0263】
裁判所、又は、一般的な法の運営において、運営者がレコードを完全に消したり、オリジナルレコードを修正することを要求する状況が発生しえる。このような状況で、Tereonは、オリジナルレコードの内容、及び恐らく関連するレコードの内容を削除又は修正する。Tereonは、後続ハッシュを無効にすることなくこれを達成できる。
【0264】
Tereonが履歴レコードを削除又は修正する場合、次のようになる。
・Tereonがレコードを削除又は修正する前に、該当レコードを修正又は変更されていないことを確認し、該当レコードのハッシュを再生性し、再生成されたハッシュを記録する。
【0265】
・削除又は修正されたレコードの内容、及び削除又は修正の理由をオリジナルレコード新しいフィールドに記録する。
・レコード内の関連フィールドの削除又は修正、及び該当削除又は修正の日時を追加する。
【0266】
・該当レコードにその新しいハッシュ生成する。
・新しいハッシュを記録する。
この順に従うことで、Tereonはどのような方式でもハッシュチェーンを修正する必要がない。削除又は修正されたレコードのオリジナルハッシュから生成された有効なレコードの全てのハッシュは有効である。システムハッシュは、削除又は修正がアクションであることから、削除又は修正されたレコードの新しいハッシュを含む。このような方式により、詐欺行為は、再算出されたハッシュと一致しない全てのレコードされたハッシュを探し出して容易に認識することができる。
【0267】
ゼロ知識証明を有するハッシュチェーン(Hash chain with zero
knowledge proofs)
ハッシュチェーンは、トランザクションの両側でハッシュらに関するレコードをハッシュしたことを相手に証明できるようにする追加レイヤを提供する。これはレコードのハッシュが該当レコードの実際のハッシュであることを1方の当業者が他方の当業者(検証者)に証明するようにするハッシュチェーン内にキー交換アルゴリズムを含んで行われる。
【0268】
二人の当事者が共通のキーを交渉することを可能にする任意のアルゴリズムがここで使用されることができ、ゼロ知識証明を使用する必要がない。しかし、ゼロ知識証明を使用するPAKE(password authenticated key exchange)アルゴリズムは、ここで使用することが最も効率的である。中間段階で正しいPAKEプロトコル及びゼロ知識証明を使用することは、当事者が同じ中間ハッシュを生成することになるので、ハッシュを交換する必要がない。
【0269】
両側がゼロ知識証明を用いて同じハッシュを生成することを可能にするPAKEアルゴリズムのようなアルゴリズムを使用すると、当事者はさら進むことができる。トランザクションを構成する情報を含んで使用して「証明」を生成することのできるゼロ知識照明を使用することにより、当事者は両方とも同じ中間ハッシュを生成することができる。これによって、それらの中間ハッシュを互いに交換する必要がない。また、これは、レコード及び情報を生成するステップとそれらのステップから発生する結果がハッシュチェーンプロセスのコンポーネントになることを意味する。2以上の当事者が参加する場合、Tereonはプロトコル及びゼロ知識証明のグループ変形を使用して、全ての当事者が共用ハッシュを生成できるようにする。
【0270】
当事者が同じハッシュが生成されるようにするPAKEアルゴリズムは、通常、当事者間で中間ハッシュを生成できるようになるまでに2回又は3回の情報伝達を行う。トランザクションが完了するのに2つの段階しか必要としない場合(例えば、要求及び受諾/検証)、当事者は、1つの中間ハッシュのみを生成する。トランザクションが3つの段階を必要とし、アルゴリズムが2つのパスによりハッシュを生成する場合、当事者は3つの段階を2回繰り返して4セットの情報を交換し、2つのハッシュ(トランザクションで最初の2つの段階後に最初のハッシュ、その次に3つの段階を繰り返してから2番目のハッシュ)を生成する。
【0271】
このようなゼロ知識証明の例がSchnorr NIZK証明である。このゼロ知識証明は、Schnorr NIZK証明に対する明細書に開示されたように、証明の一部に送信される情報及び証明の一部であるハッシュを生成するために用いられる情報の全てに追加情報を追加することで簡単に拡張できる。
【0272】
また、SPEKE(simple password exponential key exchange)プロトコルにおける共用キーを生成する方法を採択することのような他の方法も使用でき、その方式は上記のことから明らかである。
【0273】
また、当事者がトランザクションデータに基づいて共用キーを生成するようキー交換プロトコルを拡張できることも簡単な方法である。言い換えれば、ここでは簡潔さが目的として単純に図示されていない。
【0274】
共用キーを生成するために、当事者は共用キーのハッシュを簡単に生成する。ハッシュは、トランザクション情報を有効にできる情報を含むが、該当の情報が共用キー、及びハッシュを生成するプロセッサで使用されたためである。
【0275】
2段階のトランザクション(Transaction in two stage)
この動作方法を示す例は、4つのアカウント502、504、506及び508を含むハッシュチェーンの樹枝状特性を示す図5に示されている。アカウントは、同じシステム上に存在してもよく、個別システム上に存在してもよい。アカウントが存在する位置は関係ない。ステップ512及び514でのトランザクションは2つの段階を必要とする。
【0276】
2パスPAKE(Two pass PAKE)
ステップ512の最初のパスで、アカウント502は、ステップ510で生成されたアカウントの前のハッシュh510を取り、最初の段階のトランザクション情報に加え、最初のゼロ知識証明を構成し、これをアカウント504に伝達する。ゼロ知識証明は、最初の段階のトランザクション情報及びハッシュhを構成する情報を伴う。
【0277】
第2パスで、アカウント504は、該当アカウントの前のハッシュh504を取って、これを第2段階のトランザクション情報に加え、第2ゼロ知識証明を構成し、これをアカウント502に伝達する。第2ゼロ知識証明は、第2段階のトランザクション情報及びハッシュh504を構成する情報を伴う。
【0278】
アカウント502及び504は、両方のアカウントの中間ハッシュであるハッシュh512i~514iを独立的に構成する。2つのアカウント502及び504は、このハッシュをそのレコードに追加する。アカウント502は、ステップ512でトランザクションのレコードのハッシュh512を生成し、アカウント504は、ステップ514でトランザクションのレコードのハッシュh514を生成する。
【0279】
3パスPAKE(Three pass PAKE)
この例で、ステップ512及び514において、トランザクションは当事者が3つのパスの後で共通ハッシュを構成するようにするPAKEアルゴリズムを用いて2段階を取る。
【0280】
第1パス及び第2パスは上記のように実行される。第3パスで、アカウント502は、アカウント504が第2パスで送信した情報を取って、該当情報で第3ゼロ知識証明を構成し、これをアカウント504に送信する。また、第3ゼロ知識証明は、第2段階のトランザクション情報及びハッシュh504を構成する情報を伴う。
【0281】
アカウント502及び504は、ハッシュh512i~514iを独立的に構成する。2つのアカウント502及び504は、ハッシュをそれらのレコードに追加する。2パスPAKEアクセス方式と同様に、アカウント502は、ステップ512においてトランザクションのレコードのハッシュh512を生成し、アカウント504は、ステップ514においてトランザクションのレコードのハッシュh514を生成する。
【0282】
どちらの場合も、チェーンには、アカウント502からステップ512まで、およびアカウント504からステップ514までのハッシュのチェーンを検証する情報が含まれている。アカウント502と504の両方に、それらの記録のために中間ハッシュh512i、514iとそのハッシュが含まれる。ただし、ここでの中間ハッシュは、ゼロ知識証明を使用しない前述した例のシステム間で交換された中間ハッシュのものとは微妙に異なる。ここでは、中間ハッシュは、アカウント502と504の間のトランザクションのハッシュであるため、アカウント502と504の両方に共有である。ハッシュは、トランザクションのハッシュであり、トランザクションの一部として生成される。トランザクションと同時に発生する。ハッシュh512は、アカウント502のそのトランザクションのレコードのハッシュであり、それに対して私的な情報を含むが、アカウント504のハッシュh514は、トランザクションのそのレコードのそのハッシュである。したがって、アカウント502とアカウント504は、それらの間のトランザクションにおける実際のステップと、そのトランザクションのレコードとの両方を証明できる。
【0283】
3段階のトランザクション(Transaction in three stages)
図5を用いて他の例として、ステップ528及び530において、トランザクションが2つではなく3つの個別段階を含むと仮定する。
【0284】
2パスPAKE(Two pass PAKE)
最初のパスで、アカウント502は、ステップ522で生成されたこのアカウントの前のハッシュh522を取り、これを最初の段階のトランザクション情報に追加して第1ゼロ知識証明を構成し、これをアカウント506に送信する。ゼロ知識証明は、第1段階のトランザクション情報及びハッシュh522を構成する情報を伴う。
【0285】
第2パスでは、アカウント506は、ステップ524で生成された該当アカウントの前のハッシュh524を取り、これを第2段階のトランザクション情報に追加して第2ゼロ知識証明を構成し、これをアカウント502に送信する。第2ゼロ知識証明は、第2段階のトランザクション情報及びハッシュh524を構成する情報を伴う。
【0286】
アカウント502及び506は、共用ハッシュをハッシュh528i530iを独立的に構成できるが、PAKEアルゴリズムが第2パス後で当事者が共用ハッシュを構成するためである。しかし、トランザクションには実行すべき第3段階がまだある。
【0287】
この例では、システムは単に、PAKEアルゴリズムを用いて第2パスセットを介して実行する(トランザクションの第3段階で開始す)。第2パスセットの第2パスは、単にランダムデータを使用してもよい。また、これは、2段階トランザクションで3パスPAKEを使用するのと同様に、最後の段階を繰り返すこともできる。
【0288】
後者の場合で、第3パス(新しいPAKEアルゴリズムの第1パス)は実行され、アカウント502が署名したh528i530iを取り、これを第3段階のトランザクション情報に追加し、第3ゼロ知識証明を構成し、これをアカウント506に送信する。第4パス(新しいPAKEアルゴリズムの第2パス)は実行され、アカウント506が署名したh528i530iを取り、これをアカウント502が送信した第3段階のトランザクション情報に追加し、その情報を用いて第4ゼロ知識証明を構成し、これをアカウント502に送信する。アカウント502及び506は、ハッシュh528i2530i2を独立的に構成してもよい。これは、このトランザクションで生成された第2共通ハッシュであり、これがトランザクションの3つの段階の全てを含んでいるため、アカウント502及び506間のトランザクションのハッシュである。アカウント502及び506の両方が、このハッシュをレコードに追加する。アカウント502は、ステップ528において、このトランザクションのレコードのハッシュh528を生成し、アカウント506は、ステップ530において、このトランザクションのレコードのハッシュh530を生成する。
【0289】
この順は、上述したものと全く同じ方式で各トランザクションのハッシュを生成するために、アカウント502、504、506及び508の間の追加トランザクションについて実行される。
【0290】
3パスPAKE(Three pass PAKE)
第1パス及び第2パスは、上記のように実行される。第3パスでは、アカウント502は、第3段階のトランザクション情報を構成する情報を用いて第3ゼロ知識証明を構成し、これをアカウント506に送信する。ゼロ知識証明は、第3段階のトランザクション情報を構成する情報を伴う。
【0291】
アカウント502及び506は、ハッシュh528i~530i独立的に構成する。アカウント502及び506の両方は、このハッシュをレコードに追加する。アカウント502は、ステップ528でこのトランザクションのレコードのハッシュh528を生成し、アカウント506は、ステップ530でこのトランザクションのレコードのハッシュh530を生成する。
【0292】
図5に関する例示として、システムは、中間ハッシュ又はトランザクションハッシュを生成するためにゼロ知識証明を使用し、ハッシュh530は、アカウント502のハッシュの全てをh528i、アカウント504のハッシュの全てをh526i、アカウント508のハッシュの全てをアカウント506がh524を生成したときに生成されるアカウント508の中間又はトランザクションハッシュまで、及びアカウント506のハッシュの全てをh530で検証された情報を含む。しかし、それがトランザクションネットワーク内の全てのハッシュを検証するが、アカウント506は、他のアカウント、システム、又は、サーバに入力されたトランザクションに対するトランザクションレコードのみを保有する。たとえ、そのハッシュがアカウント502又はアカウント504がそれらのトランザクションのハッシュを検証するために使用できる情報を含んでいても、アカウント502及び504間のトランザクションに対するトランザクションレコードの内容について何も知らない。
【0293】
重要なことは、当事者の全てが同じ中間ハッシュを独立的に生成するために使用されるアルゴリズムは、当事者がトランザクションに影響を与えるために交換するステップを使用することにある。したがって、レコードを生成するトランザクションは、ハッシュチェーンプロセスのコンポーネントになり、ハッシュチェーンエントリ(hash chain entry)を生成するプロセスは、トランザクションに影響を与えるプロセスと同一である。もう1つの見方は、トランザクションがトランザクションの一部としてハッシュを生成し、該当ハッシュ及びこれに伴う情報がトランザクションの監査になるのであろう。それらは1つになって同一である。ブロックチェーンを使用すると、トランザクションの開始者はトランザクションを完了し、後で監査のためにそのレコードをブロックチェーンに送信する。これにより、トランザクションに統合されることなく、他のステップがプロセスに追加される。
【0294】
トランザクション自体がハッシュチェーンが提供する監査追跡の同時コンポーネントになると、監査追跡によって詳細がキャプチャー又は検証されないトランザクションを有するということは不可能である。トランザクションの完了後に、ほとんど完了されたトランザクションレコードが監査システムに伝えられる点で、多くの監査追跡は「イベント後(after the event)である。このような場合、監査によって受信されたレコードがトランザクションにより生成されたレコードと同一でない可能性がある。したがって、コンピュータの記録は通常小文字(hearsay)と見なされる。正しいPAKE又は類似のプロトコルを使用してゼロ知識証明を統合することは、監査追跡がトランザクションによって生成され、トランザクション及びそのレコードが監査追跡の一部になることを意味する。これはリアルタイムで報告されるため、これはリアルタイムトランザクションに対して重大な影響を与える。
【0295】
ゼロ知識証明を用いてハッシュを構成するプロセスは、ハッシュチェーンでハッシュを生成するいずれのシナリオに適用されてもよい。これは図8によって示されたシステムハッシュ、ライセンスサーバハッシュ、及びオフラインハッシュに使用されてもよい。重要なことは、ハッシュが2つ又はそれ以上のエンティティ間のトランザクションを含むことにより、そのエンティティが当事者、デバイス、又は、システムであるか否かに関係ない。プロセスは、標準ハッシュの使用も排除されない。したがって、1つのシステムは、デバイスがオンライン又はオフラインであるか否かに関係なく、アカウント間のトランザクションのゼロ知識証明を用いて生成されたハッシュを使用できるが、システムハッシュ及びライセンスハッシュのために標準ハッシュを使用してもよい。第2システムは全てのハッシュに対してゼロ知識証明を使用できるが、第3システムは標準ハッシュのみを使用する。
【0296】
多重トランザクション段階を含むマルチパスPAKE(Multiple pass PAKEs with multiple transaction stages)
前記の例は、2つ又は3つの段階を含むPAKEで2つ又は3つの段階を含むトランザクションを用いてトランザクションの両側で共用キーを生成できるようにする方法であり、システムは、該当の例に限定されない。実際には、異なる複数のパスが必要なPAKEを使用する複数の段階を含むトランザクションを支援するシステムに対して同じ方法が効果を有する点である。しかし、システムは、トランザクション全ての段階をカバーするために必要な多くのPAKE実行を簡単に使用する。これは、最終的な共通キーを生成するために要求されるPAKEパスを生成するために最終段階を何度も繰り返してトランザクションハッシュを生成する。
【0297】
ゼロ知識証明を有するシステムハッシュチェーン(System hash chain with zero knowledge proofs)
図6に戻って、ゼロ知識証明及び古典的なハッシュを用いて生成されたハッシュの全てを使用できるハッシュチェーンが示されている。図面には、システムハッシュh606、h608、h612、などと共に、同じシステム606上の2つのアカウント602及び604を示す。システムは、レコードが存在する位置に関係なく、レコードを発生させる全てのアクションに対するレコードの新しいハッシュを生成する。アカウント間のトランザクションは、上述したように、アカウントそれぞれに対する中間ハッシュ又はトランザクションハッシュを生成するためにゼロ知識証明を使用してもよい。システムハッシュは、該当レコードを生成するとき各レコードのシステムハッシュを含む。
【0298】
ステップ614及び616において、アカウント602及び604間のトランザクションが3パス後も当事者が共通ハッシュを構成することを可能にするPAKEアルゴリズムを用いて3つの個別段階を含むと仮定する。
【0299】
トランザクションの第1ステップで、アカウント602は、以前のレコードのハッシュであるハッシュh610を、ステップ608で生成されたシステムハッシュh608のシステムアカウント606と交換する。それは、このシステムハッシュ及びこのハッシュh610をステップ610で生成された第1段階のトランザクション情報に追加し、第1ゼロ知識証明を構成し、これをアカウント604に送信する。ゼロ知識証明は、第1段階のトランザクション情報、ハッシュh610、及びハッシュh608を構成する情報を伴う。
【0300】
トランザクションの第2ステップで、アカウント604は、ステップ608で生成されたシステムハッシュh608に対するシステムアカウントとハッシュh604を交換する。それは、このシステムハッシュ及び第1段階のトランザクション情報に対するこの以前のレコードのハッシュであるハッシュh604第1段階のトランザクション情報に追加し、第2ゼロ知識証明を構成し、これを602に送信する。ゼロ知識証明は、第2段階のトランザクション情報、ハッシュh604、及びハッシュh608を構成する情報を伴う。
【0301】
トランザクションの第3ステップで、システムアカウント606は、h610及びh604をレコードに追加し、中間システムハッシュh612iを生成する。
第4ステップで、アカウント602は、第3段階のトランザクション情報を構成する情報を用いて第3ゼロ知識証明を構成し、これをアカウント604に送信する。第3ゼロ知識証明は、第3段階のトランザクション情報を構成する情報を伴う。
【0302】
第5ステップで、アカウント602及び604は、ハッシュh614i616iを独立的に構成する。アカウント602及び604両方はこのハッシュをそれらのレコードに追加する。ハッシュh614i616iは、トランザクションのハッシュである。
【0303】
第6ステップで、アカウント602は、システムアカウント606とh614i616iをh612iに交換し、h612iをそのレコードに追加し、ステップ613で、トランザクションのレコードのハッシュh614を生成する。アカウント604は、システムアカウント606とh614i616iをh612iに交換し、h612iをそのレコードに追加し、ステップ616で、トランザクションのレコードのハッシュh616を生成し、システムアカウント606は、h614i616iの2つのコピーをレコードに追加して、ステップ612で新しいシステムハッシュh612を生成する。
【0304】
ステップ614で、トランザクションに対するアカウント602のレコードは、ハッシュh610、ハッシュh604、システムハッシュh608、トランザクションハッシュh614i616i、中間システムハッシュh612i、3段階のトランザクション情報、トランザクションのレコード、アカウントID、及びハッシュh614を含む。
【0305】
ステップ616で、トランザクションに対するアカウント604のレコードは、ハッシュh610、ハッシュh604、システムハッシュh608、トランザクションハッシュh614i616i、中間システムハッシュh612i、3つの段階のトランザクション情報、これのトランザクションのレコード、アカウントID、及びハッシュh616を含む。
【0306】
(アカウント602のトランザクションのレコードは、それぞれ異なる状態でトランザクションを開始及び終了したため、アカウント604のレコードとは異なり、それぞれ異なるアカウントの詳細及びIDを有する異なるアカウントである。)
システムハッシュh612は、個々のトランザクションだけではなく、全体トランザクションといった両側のハッシュを含むため、ハッシュチェーンを相当強化する。
【0307】
Tereonが異なるシステム上のアカウント間のトランザクションを管理する場合、プロセスは若干ことなる。ここでは、各システムが管理するアカウントとシステムハッシュ及び中間システムハッシュを交換する。そうでなければ、図6も関連して上述した方法は、アカウント602及び604及びシステム606を有する代わりに、関連するアカウント602に関するシステム606、及びアカウント604に関する第2システム605を示すこと以外は同一である。ステップ614及び616で発生したトランザクションと共に、発生するシステムハッシュはステップ612で行われるトランザクションでは、結果として生じるハッシュシステムは、ステップ612でのシステムトランザクションと、アカウント604に対応する第2システム605上の同等のトランザクションと表す。同時にトランザクションできるアカウントでは、システムはレコードを生成する各対話に対してハッシュを生成する。
【0308】
図6は、順次ハッシュ及び中間ハッシュを示すが、現実は異なる。図6aは3つのアカウント602a、604a、及び606a図示し、全てシステムアカウント608aと共に外部サーバ上のアカウントと相互作用している。トランザクションの段階はトランザクションがシステム上で同時に行われるとき発生の可能性を説明するためにインターリビングする。便宜のために、これらは全て同じサーバ上に示されている。
【0309】
前記の例で、ステップ612aで、アカウント602aは、h612aを取得するためにシステム608aとハッシュh602aを交換するだろう。システム608aは、前記例が中間ハッシュh616aiとして示すものを生成する。この添字「i」は、各トランザクションが3つのシステムハッシュ、トランザクション前のオリジナルハッシュ、トランザクションの特定段階でのシステムハッシュ(中間ハッシュ)、及びトランザクションの終わりでシステムハッシュを含むことを明確にするために用いられる。添字「i」は、中間ハッシュを示す。前記の推理により、最終システムハッシュはh616aであり得る。複数の同時に発生する又はインターリーブされたトランザクションがある場合、ラベリングによりこれ以上の進行状況が分からない。代わりに、各システムハッシュは、トランザクションのうち又はその後で生成の有無に関係なく、以前のハッシュに対する増分(increment)ではあるが、システムハッシュである。アカウント602aが開始し、次にアカウント604aが開始し、アカウント606aが開始し、アカウント602aが終了し、アカウント604aが終了する前にアカウント606aが終了するために3つのトランザクションが発生する場合、他のトランザクション又はアクションがサーバ上のこれ(又はアカウント)又は任意の他のアカウントで発生していない場合、ハッシュの順は次のようになり、結果的にダイヤグラムは以前の図面と微妙に異なる。
【0310】
アカウント602aは、h612aを取得するためにシステムとハッシュh610aを交換する。システムは、該当ハッシュh610aを使用して、次のシステムハッシュh616aを生成する(これは、H628aiがそのトランザクションの最終的なシステムハッシュであるため、アカウント602aのトランザクションが完了すると、h628aiは元々のラベルされているのである)。
【0311】
アカウント604aは、h616aを取得するためにシステムとハッシュh614aを交換する。システムは、次のシステムハッシュh620aを生成するために該当ハッシュh614aを使用する。
【0312】
アカウント606aは、h620aを取得するためにシステムとハッシュh718aを交換する。システムは、次のシステムハッシュh624aを生成するために該当ハッシュh618aを使用する。
【0313】
アカウント602aがその中間又はトランザクションハッシュを生成すると、そのハッシュh622aをシステムハッシュh624aと交換する。システムは、次のシステムハッシュh628aを生成するために該当ハッシュh622aを使用する。
【0314】
アカウント606aがその中間又はトランザクションハッシュを生成すると、そのハッシュh626aをシステムハッシュh628aと交換する。システムは、次のシステムハッシュh632aを生成するために該当ハッシュh626aを使用する。
【0315】
アカウント604aがその中間又はトランザクションハッシュを生成すると、そのハッシュh630aをシステムハッシュh632aと交換する。システムは、次のシステムハッシュh636a(図示せず)を生成するために該当ハッシュh630aを使用する。
【0316】
ハッシュチェーンは、システムがトランザクションを処理し、該当トランザクションを監査し、同時に、該当トランザクションによって送信されたり生成されたデータを認証するようにする。このようなステップは同時に発生する。デバイスがトランザクションを監査システムで正直に報告すると仮定する必要がない。トランザクションは監査を生成し、監査はトランザクションを生成する。
【0317】
これにより、プログラムされたデバイスによって実行されるトランザクションの特性を全て変更する。IoTデバイスを含む任意のプログラムされたデバイスは、トランザクションと、その監査及び認証が同時に行われるため、他のデバイスとの間のトランザクション及びデータを有効にして信頼し得る。
【0318】
該当トランザクション及び監査が同じプロセスの一部として生成されるため、デバイスがトランザクションの正確なレコードを監査システムに送信すると仮定する必要がない。この同時発生する特性は、監査追跡の証拠値(evidential value)の品質を変更する。各デバイスは他のデバイスによって送信される情報に依存できるが、他のデバイスの信頼性に関して仮定することはない。送信及び受信されるデータは、処理されるデータ及び認証及び監査されるデータである。
【0319】
ルックアップサービスと組み合わせるとき、以前に相互作用していないデバイスは互いに認証し、それぞれが行うサービス又は機能を決定し、その次に相互間に通信し、その通信に依存して任意の人が介入する必要なくプログラムされた通りに作業を行うことができる。
【0320】
ハッシュチェーンは、IoTデバイスを含むプログラムされたデバイスがオンライン及びオフラインの全てに動作できる。デバイスがオフラインのとき、タイムスタンプ、該当デバイスのクロックスクリューに関する情報、デバイス固有のトランザクションID(内部モノトニックカウンタなどによって生成されたもの)、及びトランザクション情報にその他同期化情報を含む場合、それらのサーバがデバイス又は第3パーティーサーバからオフライントランザクションのレコードを最終的に受信するとき、それらのサーバが各トランザクションに対する因果関係を格納する正確なタイムラインを再構成するようにする。ハッシュチェーンは、オンライン及びオフラインモード両方で、サーバがトランザクションレコードの内容に依存することを可能にする。
【0321】
デバイス間の通信を保護する通信セキュリティーモデルと組み合わせると、デバイス及びサーバは、中間者攻撃に影響を受けない方式で通信し得る。Tereonは、IoT及び他のプログラムされたデバイスが安全に通信し、該当デバイス間の送信されたデータに依存するようにする。
【0322】
その1つの例として、産業用センサ及び制御装置のセットで動作するIoT及び他のプログラムされたデバイスのネットワークであり得る。セキュリティーモデルは、ルックアップディレクトリサービスを使用し、このようなデバイス間で安全に通信するようにし、オリジナルコレクションに追加されるとき該当デバイスが新しいデバイスと相互作用するようにする。Tereonは、新しいデバイスを認識し、新しいデバイスを信頼できるようにするために再構成する必要がない。ハッシュチェーンは、デバイスがそれらの間の通信コンテンツ及びタイミングを信頼できるようにし、送信されたデータの真実性に対する人の評価を必要とせずに運営者が生成及び送信されたデータに依存可能にする。第3者が、データとインタフェースすることができない。その監査及び認証チェーンがその送信と同時に発生する。
【0323】
ルックアップサービスは、セキュリティーモデル及びルックアップサービスと結合されるとき人の介入を必要とせず、デバイスが信頼及び認証できるアドホック相互接続を生成できるようにする。デバイスが認証され、これの詳細がルックアップサービスに追加されれば、必要に応じて、他のデバイスは該当デバイスに接続できる。該当デバイスが任意の方式により損傷される場合、これに対する全てのアクセスは、同一のルックアップサービスによって不活性化される。
【0324】
システムは、ハッシュチェーン及びルックアップサービスから発生する追加利点を提供する。全てのデバイスが個別的に認証され、監査されるため、システムは必要に応じて、特定のデバイスがそれらのデバイスのソフトウェアに対するアップデートをダウンロードするよう指示し、デバイスは安全で、信頼されるソースのみを行う。ルックアップサービスは、特定のデバイスが提供及び使用する、例えば、サービス、インタフェース、及びデータフォーマットを詳細に説明する。したがって、デバイスが特定のデバイス(survive)にアクセスするため、他のデバイスに接続を試みる場合、要求されるインタフェース又はフォーマットを支援するために必要なソフトウェアがないとき、接続中であるデバイスのいずれか1つ、又は必要に応じて、デバイスの両方のデバイスが互いに通信できるようにする必要なソフトウェア又は構成をダウンロードするためにシステムサーバと通信し得る。デバイス間通信が完了した後、デバイスがソフトウェアを保持するか否かは、デバイス又はデバイスが行うサービス、及び該当デバイスの容量により決定される。ハッシュチェーンは、たとえ、それらが該当ソフトウェアを除去したとしても(それがダッシュ通信するとき、それを再びインストールしてもよい)、2つのデバイスは必要に応じて、後ほど他のデバイス又はサーバにアップロードできるデバイス間通信の完全な監査及びレコードを保持することを意味する。この機能は、完全に自動化されたIoTデバイスから支払いデバイスのようなプログラムされた他のデバイスに至るまで、全タイプのデバイスに拡張される。
【0325】
ハッシュチェーンの分散レコード(Distributed records of the hash chain)
全体のハッシュチェーンの分散複製を提供するために、Tereonシステムは、該当サーバの現在の接続と最後の接続間に発生した全てのトランザクションに対してハッシュチェーンをライセンスサーバ、ルックアップサーバ、又は、他のサーバセットのような中央サーバ集合にアップロードする。同じTereonシステムが異なるTereonシステムに対応するハッシュチェーンをダウンロードし得る。これにより、全てのTereonシステムの全てのトランザクションに対してハッシュチェーンの分散元帳が提供するが、トランザクションごとに各ハッシュチェーンを再び算出する必要がない。しかし、Tereonシステムに追加のストレージ負担がかかる。中央サーバは、ライセンス及び検索サーバのようなグローバルサーバにする産業、地域又はその他の制約条件に限定され得る。ハッシュチェーンのコピーの到達範囲を制限することで、この変形の算出及び格納上の負担を減らし得る。
【0326】
中央サーバの範囲を制限する代わりに、他のシステムでアップロードしたハッシュチェーンをダウンロードできるシステムを制限することができる。したがって、ある銀行のハッシュチェーンは他の銀行によってダウンロードされることができるが、該当銀行がアップロード銀行と同じ地域にあるか、又は他の銀行と取引したか否かに応じて制約を受ける。同様に、病院システムは、同じ地域の病院によってアップロードされたハッシュチェーンのみをダウンロードできる。柔軟性には制約されない。
【0327】
Tereonで用いられるハッシュチェーンには極めて有用な属性を有する。それはローカル元帳のを提供するが、分散認証を提供する。トランザクション情報をトランザクションに関するユーザ及びサービスに非公開として保持するが、ハッシュによって提供された認証を全てのサーバ、サービス及びデバイスに分散する。ゼロ知識証明で生成されたハッシュはこれを示す。特定トランザクションに関するシステムのみがトランザクション情報を保有する。しかし、システムと相互作用する全てのシステムとデバイスは、該当システムの初期ハッシュに関する情報を含むハッシュを生成する。
【0328】
分散認証は、変調されたレコード(tampered record)を隠そうとする潜在的な詐欺師に対して算出不可能な障壁を提供するため重要である。
ブロックチェーンを使用すると、詐欺師は、変調されたレコードを隠してブロックチェーンを変更し、誤ったレコードを有効なレコードとして記録するために25~33%のサーバだけを制御すれば良い。一回行われると、プロセスを元に戻すことは不可能である。
【0329】
Tereonハッシュチェーンを使えば、詐欺師は全てのTereonサーバ、全てのTereonサービス及び全てのTereonデバイスを制御して該当サーバ及びデバイス皆でチェーンの全てのハッシュを再び算出しなければならない。これは算出上で実行不可能である。
【0330】
ハッシュチェーンは、ブロックチェーンの提案者が後者に対して予測するのと少なくとも同じレベルの経済的節減及び経済的効率性を提供する。差異点は、Tereonハッシュチェーンが実際にそうすることができることである。ブロックチェーンは、その設計とその設計に固有の限界のために、そうすることができない。
【0331】
このシステムの長所は、詐欺師が全てのハッシュ及び該当レコードと接続されたハッシュを再び算出しないと、データベースでレコードを削除したり修正できないことである。Tereonがシステムハッシュやライセンスサーバへの接続なしで単一のサーバ上で作動する場合、これは理論的に可能であるが、リンクされたチェーンのうちの1つが他のサーバ又はデバイスのパーティーとのトランザクションを含む場合、詐欺師は、他のサーバ又はデバイスの全てのハッシュを再び算出する必要がある。そうすることの困難さは、オリジナルレコードの日時の後にハッシュチェーンと相互作用する追加のサーバ又はデバイスごとに急激に増加する。
【0332】
ハッシュチェーンにより、組織は全てのデバイスによって収集、生成、又は管理されるデータの正確を保障し、レコードのオリジナルコンテンツと無欠性を保障して、以前のレコードを基盤としたトランザクションのコンテンツと無欠性を保障できるようにする。これは、支払いデバイスから医療デバイス、交通センサ、気象センサ、水流検出器などに至る、あらゆる全てのデバイス又はトランザクションに適用される。
【0333】
各地域の元帳は個々の組織の責任であるため、これは明確なガバナンス上の利点を有するが、それらは強度を共有しながら明確な責任と説明の責任を提供する方式により、他の組織の元帳のから学び、頼ることができる。ハッシュチェーンは、情報及びトランザクション管理を施行して支援する技術ツールを作成する。
【0334】
また、ハッシュチェーンが支払いシステムの構成要素として使用されるとき、Tereonは、支払い金額を処理し、アーキテクチャーは支払いが今日行われている方式と整合し、Bitcoinのような暗号化通貨と同等又はそれ以上の利点を提供する。それは、確立された支払いサービスの提供者と中央銀行に「Bitcoin beater」を提供する。
【0335】
ハッシュチェーンは、極めて安定した迅速な認証を可能にするためTereonシステムで特に魅力的な部分である。
Tereonのユニークな機能の1つは、包括的なリアルタイムログ及び監査証跡を作成する機能である。Tereonトランザクションレコードには、トランザクションに必要なすべてのキーストローク(実際の認証資格情報(PINやパスワードなど)は除く)であるが、そのトランザクションに関するすべてのデータおよびメタデータと共に、規制および業務上の要件を満たすために求められる。必要条件の複数のサービスプロバイダにまたがって格納されている場合、そのレコードを改ざんされやすいものにし、問題となっているトランザクション以降の一連のトランザクションを改ざんされないようにすることが重要である。
【0336】
ブロックチェーンはこれができない。そのレコードが生成されてから権限が付与される前にトランザクションレコードのみ承認できる。ブロックチェーンは、様々なレコードに接続され、ブロックを生成した後これをブロックチェーンに追加する。それは、ブロックチェーンが以前の全てのトランザクションに関する情報が含まれたブロックを含む事実に依存する。ブロックチェーンが追加ブロックを追加するにつれて、このようなブロックの存在の有無に応じてブロックチェーン内のレコードと全ての以前のレコードの有効性を検査する。これによって、ファイルの大きさが増大するにつれてスケーリングの問題が発生し、もし不一致が発生すると、ブランチ全体が認証を失う。
【0337】
ブロックチェーン又はその派生物を使用するのではなく、Tereonのハッシュチェーンは後続トランザクションの認証を損傷させることなく、調査のために疑わしいレコードを隔離するハッシュ戦略を使用する。それは静的レコードでもリアルタイムトランザクションでも関係なく、あらゆるレコードタイプに合わせて設計されているため、スケーリングの問題を回避できる。
【0338】
中間ハッシュを含むハッシュは、管理者がハッシュチェーンを迅速に探索してハッシュ及び該当レコードを確認し、その確認に必要な情報を提供できる。レコード自体も同じである。
【0339】
トランザクション又はアクションが発生すると、以前のハッシュが調整されるため、ユーザとシステムが新しいトランザクションの出力を信頼する可能性があることを意味する。したがって、Tereonは、トランザクションを行う前に各アカウントの累積合計(running totals)を信頼し得る。ハッシュチェーンの有効性は累積合計が正しいかを確認する。
【0340】
ハッシュチェーンをブロックチェーン及びその派生物から分離する改正されたレコード、削除されたレコード、又は変調されたレコードの効果を隔離することがこの機能である。定義上、ブロックチェーンが確実に隠されている修正又は変調されたレコードは、該当ブロックチェーンの全体再算出に影響を及ぼす。全てのブロックチェーンを修正しなければならないため、全体ブロックチェーンコミュニティの民主的な決定以外に、偽造されたレコード又は偽りレコードを検索して修正する方法がない。セキュリティー研究者がブロックチェーン設計の主な欠陥として確認したのはこの機能である。その設計は変更できない。
【0341】
ハッシュチェーンでは、攻撃者が後続のハッシュを全て再計算できない限り、改ざんされたレコードがハッシュチェーンの残りの部分に影響を与えることができない。改ざん前のハッシュは有効であり、有効なままであるため、それらのハッシュに基づくトランザクション及びそれらのハッシュに関する値は有効なままである。
【0342】
オフライントランザクションに対する樹枝状ハッシュチェーンは、オフラインデバイスがサーバに再び接続できる前に該当デバイスが失われたり侵害されても、オフラインデバイスによって実行されたオフライントランザクションを登録する可能性があることを意味する。
【0343】
ハッシュチェーンは、ブロックチェーン及びその派生物だけでは達成できないオフライントランザクションの有効性を完ぺきに支援する。ブロックチェーンのコピーを運営するノードは、ブロックを確認するためにオンライン状態でなければならない。ビットコインウォレットは、オフラインでトランザクションを生成できるが、オンライン状態になって該当トランザクションのレコードをノードにプッシュするまで該当トランザクションの有効性を検査することができない。ノードのうの1つがブロックチェーンで次のブロックを生成する競争で勝ってブロックにレコードを追加するまでトランザクションの有効性が検査されない。
【0344】
ディレクトリサービス(Directory Service)
輸送システム、EMV(Europay、MasterCard、Visa)のような支払いネットワーク、及びその他のレガシーシステムのような既存システムは、ハブ・アンドスポーク・アーキテクチャー(hub and spoke architecture)を使用する。ここで、全てのトランザクションは、障害又は脆弱性の潜在的な単一地点を示して拡張のために高いコストの中央ユーティリティを通過する。
【0345】
Tereonシステムはピアツーピアで、あるサーバが他のサーバーと直接通信するため、ハッシュチェーンの検証はピアツーピアネットワークの全ての要素で行われるため、セキュリティ上のハッシュチェーンが極めて重要である。
【0346】
説明したように、Tereonシステムは、システムのクリデンシャル及び情報のディレクトリであるディレクトリサービス216を有する。ディレクトリサービス216は、特定のユーザに関する複数のタイプのクリデンシャルを格納するため、ユーザ又はデバイス218がどのサーバに登録されているか、又はあるサーバが特定のサービス又は機能を提供するかを識別し、ユーザ218の複数認証方法が発生できるようにする。例えば、ユーザ218は、自身のモバイル番号、メールアドレス、地理的位置、PAN(プライマリアカウント番号)などを用いて認証され、毎回認証する必要がないよう全てのものをキャッシュする。
【0347】
ディレクトリサービス216は、基本となるサービス、サーバ及び実際のユーザアカウントからユーザの認証IDを分離する抽象化レイヤを提供する。これはユーザ218又はマーチャントサービスにアクセスするために使用できるクリデンシャルとTereonがサービス自体を行うために必要な情報間に抽象化を提供する。例えば、支払いサービスとして、ディレクトリサービス216は、モバイル番号のような認証ID及び恐らく通貨コードをサーバアドレスとリンクさせるのであろう。ユーザ218が銀行アカウントを有しているか否か又はユーザ218がどの銀行を決定するの方法は全くない。
【0348】
ディレクトリサービス216は、サービス提供者が相互を見ることができず、ユーザデータのセキュリティーが提供されるよう様々なサービス間の仲介者の役割を果たす。各サービスは、当該サービスに特定のフィールド(変数)及び値を定義する。しかし、各サービスは、サービスを識別する特定のフィールドと値を含む。
【0349】
トランザクションが知られていない当事者との間でトランザクションが完了すれば、ユーザ218に関するTereonサーバは、ディレクトリサービス216にURN(uniform resource name)を送信し、ディレクトリサービス216は、ユーザ218によって要求されたサービスに対する支払いサービス提供者のTereonサーバに対するIPアドレスを返送する。これは、トランザクションがピアツーピアに基づいてユーザ218とサービス提供者との間で直接完了することを可能にする。また、Tereonサーバは、後続の全てのトランザクションがディレクトリサービス216を使用する必要がないように、キャッシュにIPアドレスを保持する。
【0350】
このような抽象化は、ユーザ及びサービス詳細にセキュリティー及び個人情報を提供し、一般ユーザ・クリデンシャル(public user クリデンシャル)に影響を与えることなく、基本となるサービスを追加及び修正できる柔軟性を提供し、必要に応じて、それぞれ異なるものと隔離されている様々なサービスを分割して支援できる機能を提供する。データサービスのどのフィールドもトランザクションを開始するために必要なデータを含まず、ユーザの認証ID以外のユーザデータはディレクトリサービス216に格納されない。
【0351】
しかし、Tereonディレクトリサービス216は、これ以上のものである。複数のクリデンシャルを支援する。したがって、ユーザ218は、任意数のクリデンシャルを支払いIDとして使用してもよい。例として、モバイル番号、PAN、電子メールアドレスなどを含む。クリデンシャルが一意である限り、Tereonは支援される。
【0352】
ディレクトリサービス216は、複数のサービスを支援する。これは多面的クリデンシャル(又は「サイキックペーパー(psychic paper)」の概念が生まれた所である。サービス提供者がディレクトリサービス216上のクリデンシャルをチェックすると、クリデンシャルが自身のサービスに対して登録されているかどうか、そのクリデンシャルをサービスするTereonサーバのみを見ることができる。サービス提供者は、ユーザ218が資格を取得したり登録できる異なるサービスの詳細を見ることができない。
【0353】
例えば、モバイル又はカードは、図書館の図書館カードクリデンシャル、バス又は汽車の交通機関のチケット、部屋又は施設にアクセスするためのセキュリティーキー、会社の食堂の社内支払いデバイス、劇場チケット、及びスーパーマーケットの標準的な支払いデバイスとなる。それは、運転免許証、健康管理カード又はIDカードとなり、サービスへの資格を証明することができる。サービスが必要に応じて、マーチャントのデバイス上で写真IDを表示されることがある。デバイスが作成できるクリデンシャルタイプに対する制限はほとんどない。
【0354】
カードの本来の外観を偽装することは難しいが(カードがOLEDカバー又はカラー電子ペーパーカバーが組み込まれている場合に可能、例えば、サービスがカードに特定クリデンシャルやサービスに必要な情報を表示するよう指示できる。)、フォンアプリケーションの外観は、クリデンシャル及びサービスの性質を反映するようにTereonによって変更される。
【0355】
逆ルックアップ機能は、各サーバに対して実現され得る。この機能は、それと通信するサーバが認可されて認証されているか否かを確認できる。Tereonデバイス(カード、端末、モバイル又はサーバ)間の全ての通信が署名されなければならないため、この機能は必要ではない。しかし、運営者が逆ルックアップを介して追加セキュリティーを必要としたり所望する状況が存在し得る。ここで、ディレクトリサービス216は、サービス、TereonサーバドメインアドレスTereonサーバ番号、Tereonサーバ運営者、TTL(Time To Live)、端末認証IDなどのような複数のフィールドを含む。ここで、サービスタグは、トランザクションサービスではないサーバ逆ルックアップを示す。
【0356】
図9は、2つのサーバ、すなわちサーバ202a及びサーバ202bを有する例を示している。ユーザ218はサーバ202bに登録され、サーバ202aに接続された端末を介してサービスにアクセスする。
【0357】
ステップ902で、ユーザ218は、自分の装置を使って自身を端末に対して自身を識別し、それは自動的に自身を端末に対して自身を識別する。スマートデバイスを用いる場合、端末はそのIDをユーザのデバイスにも渡す。ユーザ218がカードを使用する場合、そのデバイスがマイクロプロセッサ・カードである場合には、デバイスはその識別をユーザの装置に渡すだけでよい。この場合、カードは、それが登録されているサーバ202bと通信する。端末を通した暗号化されたトンネルを介してデバイスのIDをサーバ202bに渡す。
【0358】
ステップ904で、サーバ202aは、ユーザのデバイスによって提供されるIDを受け取り、それが保持するリストに対してIDをチェックする。それはIDを保有しないため、以前にユーザ218を扱っていない。サーバ202aは、ディレクトリサービス216に接続する。ディレクトリサービス216は、サーバ202aの通信上の署名を検査し、それが有効なことと見なす。ディレクトリサービス216は、要求されたサービス(サーバ202aの署名がサーバがそのサービスに対する要求を行う権限があることを確認する)に対するサービスタグに対してIDを検索し、ライブ情報に対するキャッシュタイムと共にサーバ202cを識別する情報で応答する。
【0359】
ステップ906で、サーバ202aは、ユーザのデバイスがサーバ202bに登録されているかを確認するためにサーバ202bに接続する。サーバ202aは、端末のIDをサーバ202bに伝達する。
【0360】
ステップ908で、サーバ202bはそれがまだ行われていない場合、端末が登録されているサーバを検索するようディレクトリサービス216に同様の要求を行う。また、それはサーバ202aへ端末が要求されたサービスに登録されたかを確認できる。ディレクトリサービス216は、ライブ情報へのキャッシュタイムと共にサーバ202aを識別する情報で応答する。
【0361】
ステップ910で、サーバ202aとサーバ202bは、必要なトランザクションを行うために互いに直接通信する。これは支払いをすることからドアが開けることに至るまで多様である。
【0362】
Tereonサーバそのものは、トランザクションを開始するために必要な情報を含み、ライセンスが付与されて認証された他のサーバ又はデバイスとのみ通信する。
まず、サーバがディレクトリサービス216及び互いに通信すると、それらはデータ自身のミニディレクトリサービスで期限きれするまでデータをキャッシュする。
【0363】
この場合、Tereonサーバ202aとTereonサーバ202b間の接続を確立するための通信は明らかに簡単である。これは図10に示されている。
ステップ1002で、ユーザ218は、自分のデバイスを用いてサーバ202aに接続された端末に対して自身を識別し、それは自動にそれ自身をデバイスに対して識別する。スマートデバイスを使用している場合、端末はそのIDをユーザのデバイスにも伝達する。
【0364】
ステップ1004で、サーバ202aは、ユーザのデバイスによって提供されるIDを受け取り、それが保持するリストに対してIDをチェックする。それが保有しているデータは有効であるため、サーバ202aはサーバ202bに接続し、デバイスが要求されたサービスについてデバイスが登録されているかを確認する。また、サーバ202aは、端末のIDをサーバ202bに伝達する。サーバ202bは、デバイスが登録されていることを確認する。
【0365】
サーバ202aのキャッシュは、端末のIDに対する有効なデータを含んでいるため、それは端末がそれに登録されているかを確認するためにサーバ202bへ接続する。サーバ202bはこれを確認する。
【0366】
ステップ1006で、サーバ202a及びサーバ202bは、必要なトランザクションを行うために互いに直接通信する。
キャッシュされたデータがサーバで期限切れになった場合、該当サーバは、以前のようにディレクトリサービス216へ接続する。ユーザ218が他のサーバに移動した場合、通信は僅かに異なる。この場合について図11に示されている。差異点は、現在キャッシュされていない情報に基づいた、サーバ202bとの1番目の通信は、サーバ202aがディレクトリサービス216で新しいデータを検索させることである。
【0367】
ステップ1102で、ユーザ218は、自分のデバイスを用いてサーバ202aに接続された端末に対して自分を識別し、それは自動的に自分を端末に対して識別する。スマートデバイスを使用している場合、端末はそのIDをユーザのデバイスにも伝達する。サーバ202aは、ユーザデバイス装置によって提供された識別を受け取り、それが維持するリストに対してそのIDをチェックする。それはそのIDを保持し、キャッシュされたデータがそのIDがサーバ202bに登録されていることを示すことを見る。
【0368】
ステップ1104で、サーバ202aは、ユーザデバイスがサーバ202bに登録されているかを確認するためにサーバ202bへ接続する。サーバ202aは、端末のIDをサーバ202bに伝達する。サーバ202bは、IDがこれ以上登録されていないことを応答する。
【0369】
ステップ1106で、サーバ202aは、ディレクトリサービス216に接続する。ディレクトリサービス216は、サーバ202aの通信上の署名を検査してそれが有効であることを確認する。ディレクトリサービス216は、要求されたサービスに対するサービスタグに対してIDを検索し、ライブ情報に対するキャッシュタイムと共にサーバ202cを識別する情報で応答する。
【0370】
ステップ1108で、サーバ202aは、ユーザのデバイスが同じサービスに対してサーバ202cへ登録されているかを確認するためにサーバ202cへ接続する。また、サーバ202aは、端末のIDをサーバ202cに伝達し、ユーザのデバイスからIDに対する新しい詳細でそのキャッシュをアップデートする。
【0371】
ステップ1110で、サーバ202cはそれがまだ行われていなければ、この端末が登録されたサーバを検索するようにディレクトリサービス216に同様の要求を行う。また、端末がサーバ202aに要求されたサービスに対して登録されたかを確認できる。ディレクトリサービス216は、ライブ情報に対するキャッシュタイムと共にサーバ202aを識別する情報で応答する。
【0372】
ステップ1112で、サーバ202aとサーバ202cは必要なトランザクションを行うために互いに直接通信する。
ディレクトリサービス216は、ユーザ218がユーザ218に割り当てられた日付と共に、ユーザ218が登録したユーザIDの新旧両方の完全な証跡を常に保持する。
【0373】
サーバ202cは、IDがそれに登録された日付から、登録されたIDに関する情報のみを保持する。サーバ202bは、そのIDをサービスした期間に関するデータを保有する。
【0374】
ディレクトリサービス216によって提供される抽象化レイヤは、サービスを分割するにつれてさらに進む。したがって、危疑例で、サーバ202aは要求されたサービスに対してユーザのデバイスを登録したサーバを識別する情報のみを要求し得る。
【0375】
サーバ202aは、デバイスとの各通信に署名しなければならず、その署名は、通信が関連するサービスを識別する。サーバが二以上のサービスを提供できる場合、それは当該サービスそれぞれに対して個人キーを有し、該当キーを用いて関連通信に署名する。
【0376】
Tereonサーバ自体は、上記の場合にはサーバ202a及び202bで、提供されるタグ又は情報からユーザのアカウントデータを識別するルックアップ情報を含む。したがって、サーバ202bのみがユーザデバイスのIDをユーザのアカウントにマッピングするデータを含む。ディレクトリサービス216の情報は、単にサーバ202bに対するポインタである。ユーザのデバイスは、様々なサービスのために他のサーバに容易に登録され得る。Tereonサーバが正確なサーバを見つけることができるのは、ユーザのデバイスIDとサービスを定義するクリデンシャルの組合せである。
【0377】
まず、サーバ202aがサーバ202bと通信し、サービスタグ、ユーザID、及び任意の他の関連トランザクションデータ(例えば、年齢、通貨、金額など)を伝達すると、サーバ202bは関連ユーザのデータを検索し、トランザクションの側(side)を行う。サーバ202aは、ユーザデータを決して見ない。見ることができるのは、ユーザの認証IDとサーバ202bによって伝えられたトランザクションデータだけである。
【0378】
同様に、サーバ202bは、端末が接続されているアカウントを識別する情報を決して見ることができない。それは単にサーバ202aによって伝えられた端末ID及びトランザクションデータを見るだけである。
【0379】
サイキックペーパー・多面的クリデンシャル(Psychic paper - the multifaceted credential)
ディレクトリサービスのより興味深い効果の1つは、クリデンシャルが必要な時特定のサービスに合わせてカスタマイズされたアドホック多面的クリデンシャルを作成する機能である。ディレクトリサービスがこのようなクリデンシャルを提供できるように、ディレクトリサービスが作成された時点でサービスは想定された必要がない。これは「サイキックペーパー(psychic paper)」として知られている。
【0380】
アドホック多面的クリデンシャルは、ユーザのデバイスが特定のサービスに必要なクリデンシャルになることを意味する。それはサービス認証、権限付与、又は、サービスから他の恩恵を受けるために必要な情報を正確に提供し、それがサービス提供業者が表示される全てのものである。
【0381】
例として、ユーザ218は、自分の銀行からの支払いサービス及び地域図書館での図書館借入サービスなど、複数の異なるサービスに登録している。それはTereonに登録するとき誕生日を提供しなければならないため、自動的に年齢確認サービスへのアクセスを有する。
【0382】
図12は、ディレクトリサービス216が、ユーザ218の要求したサービスに応じて、要求元サーバ(サーバ202a)を2つの他のサーバ(サーバ(202b及び202c))に向かうようにする方法を示す。必要に応じて、別途のサービスのための2つ以上の個別ディレクトリサービスは使用されてもよい。重要なことは、トランザクションデータが抽象化の一部であり、基本アカウントデータと分離されていることである。
【0383】
ユーザ218は、例えば、バー(サービス2)でアルコール飲み物を購入するために年齢を確認する必要がある。ステップ1202ないし1210は、図9のステップ902ないし910として実行される。この場合、サーバ202a及び202bではなく、サーバ202a及び202cの間にある。したがって、ステップ1210で、サーバ202a及びサーバ202cは互いに直接通信する。この場合、サーバ202aは、ユーザ218が21歳以上であることを確認したい。サーバ202cは、単に彼が21歳以上であることを確認する。
【0384】
運営者が法的又は規制上の要求事項により追加確認を要求すると、サーバ202cは、端末に表示するためにユーザ218のパスポートタイプのイメージを送ることができ、これによって運営者は彼又は彼女が実際にユーザ218と話していることを見ることができる。ユーザ218が自身をサーバ202aにすでに識別したため、そうする必要がほとんどないが、サーバは正確なユーザであることを追加確認するために、ユーザ218が答えるための質問を送ってもよい。運営者は、ユーザの実際の年齢又は不要な個人情報を見ることができない。運営者が確認する必要があることは、ユーザ218がアルコールの飲み物を買うのに十分に年上であるかだけである。ユーザ218が自分の飲み物を支払うためにそのデバイスを使用すると、サーバ202aに接続された端末はサーバ202cに再び接続するが、今回は支払いサービス(サービス1)についてである。
【0385】
ユーザ218は、自分の地域図書館で行って本を借りたい(サービス3)。ステップ1212で、ユーザ218は、自分のデバイスを使って自身をライブラリ内の端末に自分を識別させ、それは自動的にそれを端末に自身を識別する。図書館内の端末はサーバ202bに接続されている。スマートデバイスを使用している場合、端末はそのIDをユーザのデバイスに伝達する。
【0386】
ステップ1214で、サーバ202bは、ユーザのデバイスによって提供されるIDを受け取り、それが保持しているリストに対してIDをチェックする。それは該当IDを保有するが、キャッシュが古くなっている。サーバ202bは、ディレクトリサービス216と接続する。ディレクトリサービス216は、サーバ202bの通信上の署名をチェックし、それが有効であることを確認する。ディレクトリサービス216は、要求されたサービスに対するサービスタグに対してIDを検索し、ライブ情報に対するキャッシュタイムと共に、サーバ202cを識別する情報で応答する。
【0387】
ステップ1216で、サーバ202bは、ユーザのデバイスがサーバ202cに登録されているかを確認するためにサーバ202cに接続する。また、サーバ202bは、端末のIDをサーバ202cに伝達し、ユーザのデバイスからのIDに対する新しい詳細でキャッシュを更新する。
【0388】
ステップ1218で、それがまだ行われていなければ、サーバ202cは、端末が登録されたサーバを検索するようディレクトリサービス216に同様の要求を行うことができる。また、端末がサーバ202bに要求されたサービスに対して登録されたかを確認してもよい。ディレクトリサービス216は、サーバ202bを識別するクリデンシャルで応答する。
【0389】
ステップ1220で、サーバ202bとサーバ202cは必要なトランザクションを行うために互いに直接通信する。サーバ202bは、ユーザ218が本を借りることができるかどうか(サービス3)を知りたく、サーバ202cは、ユーザが218が本を借りることができる図書館サービスに登録されていることを確認する(Tereon運営者が図書館に提供するサービスである)。ユーザ218が本を借りるために料金を支払うために自分のデバイスを使用する必要があれば、端末は、サーバ202cに再び接続するが、今回は支払いサービス(サービス1)についてである。
【0390】
サーバ202cは、いかなるサービスを図書館に提供する必要がない。ユーザ218は、サーバ202d(図示せず)のような他のサーバへ容易に登録することができ、この場合、サーバ202dは、ユーザ218が本を借りる可能性があることをサーバ202bに確認する。重要なことは、最初の場合では、サーバ202aはユーザ218が21歳以上であることを確認するだけである。彼が本を借りることができることを知らず、ユーザ218がTereonによって支払うことを知らない。同様に、サーバ202bは、ユーザ218が本を借りることができることを知っているが、彼が特定の年齢を越えたり、Tereonによって支払うことができることを知らない。
【0391】
要求サーバは、特定のトランザクションに対するクリデンシャル集合をまとめる必要がある場合、別途のサーバに様々な要求を出すこともできる。例えば、ユーザ218が年齢制限のある映画を借りたいと仮定する。この場合、要求サーバは、ユーザの年齢を確認するための1つの要求と、図書館から映画を借りるために登録されていることを確認する2種類の別途の要求を行う。Tereonは、図書館で要求するクリデンシャル集合を構成するために検証された個別クリデンシャルを集める。
【0392】
ディレクトリサービス216の構造は、個別クリデンシャルを伝達するサーバが分離することを可能にする。したがって、要求サーバは、特定のサービスをユーザ218に伝達できるか否かを確認するために必要なクリデンシャルセットを構成するのに必要な個別クリデンシャルを取得するために任意の数のサーバに問い合わせることができる。
【0393】
図13は、サーバ202aがユーザ218にサービスを提供するための多面的なクリデンシャルを構成するために3つのサーバ202c、202d、及び202eからクリデンシャルを取得する必要のある場合を示す。例えば、サーバ202d上でサービス2はフィルムをレントするサービスで、サーバ202cから第1クリデンシャルとしての年齢検証、サーバ202dからメンバーシップクリデンシャル及びサーバ202eから十分な資金のクリデンシャル(sufficient funds credential)を必要とする。
【0394】
関係は、必ず一対一でなく、3つのサーバそれぞれが1つのクリデンシャルだけを保有する。3つのサーバのうち、任意のサーバは、それぞれ1つ以上のクリデンシャルをサーバ202aに伝達し得る。これはサーバ202aに1つのクリデンシャルのみを伝達してもよい。クリデンシャルの数は関係ない。重要なことは、サーバ202aでユーザ218がサービスにアクセス可能にするために必要なクリデンシャルを取得するために1つ以上の外部サーバと接触することにある。
【0395】
ユーザ218が端末にアクセスするサーバ202aは、一部のサービスをユーザ218に伝達するために必要なクリデンシャルをすでに保有していてもよい。しかし、データ保護の目的で、ユーザ218は、サーバ202aに特定の詳細(例えば、年齢など)を提供することを所望しない。全てのサーバ202aで使用218が特定の年齢を越えたり特定の商品を注文するよう許可されていることを検証する必要がある場合、その問い合わせを確認したり拒否するサーバへ簡単に接続できる。これはEコマースウェブサイトに極めて有用である。それらは正確な詳細を知らなくても特定の事実やパラメータを確認できる。基本的に、ディレクトリサービス216は、ゼロ知識証明提供者又は機密公証人としての役割を果たす。Tereonは、その事実が何であるかを開示せず、事実又はパラメータをサーバ202aに証明したり反証することができます。
【0396】
したがって、特定のサービスに対するクリデンシャルは、202a、202c、202d、202e及び他のサーバからのクリデンシャルを含んでもよい。クリデンシャルは、1つのサーバ上にあっても、様々なサーバに分散してもよい。
【0397】
個人や組織は、開示する必要のない情報を公開する必要がなく、サービスを受ける権利があることを証明できるため、極めて強力である。再び、Eコマースウェブサイトの例をとると、ユーザ218は、自分の名前とアドレスをウェブサイトに登録してもよい。しかし、その銀行は支払いクリデンシャルを保有し、政府のサーバは、彼が制限されたアイテムを購入できる権限のあるという事実を登録し、地域鉄道会社は彼の旅行承認を保有し、彼の保健当局のサーバはその年齢を確認できる。
【0398】
サービスに対するクリデンシャルのアドホック集合を組み合わせる方法は、ユーザと該当デバイスにしか適用されない。たとえば、異なる時間に異なるサービスへ接続されなければならないIoTデバイスのような自律センサ、デバイス及びサービスにも同様に適用できる。このようなクリデンシャルの集合が要求されたとき、それらのサービスに必要なクリデンシャルを簡単に組み合わせることができる。
【0399】
アカウントの切り替え(Account switching)
新しいシステムの採択を遅延させる主な問題は、損失又はサービスの中断なしにデータをレガシーシステムから新しいシステムへ送信することの困難さが認識されていることである。同じ問題がシステムのアップグレードに影響を及ぼし、運営者は、アップグレード又はアップデート時にデータを失う危険性に対する認識により、アップグレード及びアップデートではなく、初期ハードウェア及びソフトウェアの構成をそのまま使用する場合が多い。
【0400】
ディレクトリサービス216は、データ、アカウント及び構成情報を1つのサーバ又はデータストアーから他のサーバ又はデータストアーへ円滑に移動させるメカニズムを提供することで、このような問題を解決する。機関間のリアルタイム口座振込を支援するブロックの1つは、未定の支払い(in-the-air payments)を把握して処理する方法の問い合わせである。この産業は、現在に合計18ヶ月かかるアカウント振込みシステムを有している(初期の切り替えの場合、7日後、支払い又は振込みを受けとるまで18ヶ月)。これは、あるデータストアーから他のデータストアーにデータの集合を切り替えるのにも適用できる。
【0401】
ディレクトリサービス216は、基礎となるサービス、サーバ及び実際のユーザアカウントからユーザの認証IDを分離する抽象化レイヤを提供する。したがって、ユーザ218は、自分のデバイスが登録されたサービス及び基本サーバを変更する間に自身の認証IDを維持できる。
【0402】
アカウントの切り替えプロセスは、例で最もよく説明されている。この例では、ユーザ218は、銀行Aと取引する(bank)。図14は、銀行A及びTereonサーバ202aとのユーザ関係を示す。ユーザ218がまだ顧客でなくても、銀行Bはサーバ202b上でTereonを支援する。ユーザ218は、自分のアカウントを銀行Aから銀行Bへ移動させることを決定する。
【0403】
図15は、ユーザ218が自分のアカウントを銀行Aから銀行Bへ振り込むために着手するプロセスを示す。この例で、ユーザ218は、銀行Aから超過に引き落とされず、ローンもない。
【0404】
ステップ1502で、ユーザ218は、銀行Bにアカウントを開設し、そのカード及びモバイルをその銀行及びTereonサーバ202bに登録する。
ステップ1504で、銀行BのTereonサーバ202bは、Tereonディレクトリサービス216上でユーザのモバイル及びカードのPANを検索し、その全てが銀行Aに登録されているかを検出する。
【0405】
ステップ1506で、銀行BのTereonサーバ202bは、自分の登録を銀行Bに移動したいことを確認するためにユーザ218と接触し、ユーザ218は、特に、この目的のためにユーザ218に送られた追加認証コードを入力することでこれを確認する。
【0406】
ステップ1508で、銀行BのTereonサーバ202bは、銀行Aのサーバ202aに接続し、ユーザ218が自分のアカウント及びIDに対して銀行Bへの移動を要求し、これを確認したことを銀行Aのサーバ202aに通知する。
【0407】
ステップ1510で、銀行AのTereonサーバ202aは、ユーザ218にアカウントへの移動を所望するかを確認する要求を送信し、ユーザ218は自分の移動を確認する。
【0408】
ステップ1512で、銀行AのTereonサーバ202aは、これを銀行BのTereonサーバ202bと確認し、ユーザのアカウント登録、残高、構成、支払い指示などをユーザBのサーバ202bに通知する。銀行Bのサーバ202bは、このようなアカウントを銀行Aと同じ方式で設定したり、提供権限の付与されたサービスを提供するためにできる限り近く設定する。
【0409】
例えば、ユーザ218は、GBP、USD及びEURを保有可能にする銀行Aに3つの分離した通貨アカウントを有する。残念ながら、銀行Bは、GBPとUSDアカウントのみを提供しているが、それは任意のアカウントとの間でEURの支払いを受けることができる。銀行Bのサーバ202bは、ユーザがアカウントを開設すればこれをユーザ218に通知し、ユーザはEURをGBPに変換することを決定する。その後、銀行Bは、銀行AにGBPとしてEURを送るように指示する。
【0410】
ステップ1514で、銀行BのTereonサーバ202bは、ユーザのIDがサーバ202bに登録されていることをディレクトリサービス216に通知する。
ステップ1516で、銀行BのTereonサーバ202bは、ディレクトリサービス216にユーザのIDを登録したことを銀行Aのサーバ202aに通知し、銀行Aに残高を振り込むように指示する。
【0411】
ステップ1518で、銀行Aは、これ以上ユーザのIDを管理しないことをディレクトリサービス216で確認する。ディレクトリサービス216は、新しいID登録に対する開始日時を銀行Bに設定し、銀行Aに対する旧登録に対して終了日時をフィールドに設定する。銀行Aは、ディレクトリサービスを設定し、これ以上のユーザアカウントを保有していないユーザ218に支払うことを試みる任意のサーバへ通知し、該当サーバにユーザの詳細をディレクトリサービス216内で検索するように指示する。終了日フィールドに日時を入力しこれを実行する。銀行Bは、初めには銀行Aに接続されたユーザ218に支払われた全ての支払いを受信する。
【0412】
ディレクトリサービス216は、ユーザ218が新しいアカウントに切り替えた後ユーザの古いアカウントに行われた支払いである未定の支払い(in-the-air payments)をキャッチし得る。同じ方式で、Tereonは、古いアカウントから支給される予定の延期された支払い(deferred payments)も受けとることができる。残高が送信されること、これらのアカウントは新しいアカウントから出金され、このタスクにはは数日、数週間又は数ヶ月でなく数分かかる。
【0413】
ステップ1520で、銀行Aは、残高を銀行Bに振り込む。銀行Bは、銀行Aに資金を受信したことを通知する。
ステップ1522で、銀行Aは、ユーザのアカウントをクローズし、そのように行った新しい銀行で残高を振込んだことをユーザ218に通知する。
【0414】
ステップ1524で、銀行Bは、銀行Aから自分の残高を受信したことをユーザ218に通知する。
ユーザ218が銀行Aで自分のアカウントの1つ以上に超過に引き落とされ、銀行Bが自分の事業を引き受けることに同意した場合、ステップ516及び520で銀行Bは残高を銀行Aに振込み、銀行Bのユーザに対応するアカウントは引き落とされる。ユーザ218は、銀行Bに自分のアカウントを振り込む前に超過に引き落とされること(overdraft)をクリアするため、銀行Aのアカウント間で資金を振り込むことを決定してもよい。
【0415】
支払いの場合、Tereon番号付けシステム(Tereon numbering system)は、ユーザ、組織、アカウント、サービスのタイプ及びトランザクションを区分する。それらは全て別途の番号付けシステムを有する。このような特性は、ディレクトリサーバは、ユーザ218が自分のアカウントを新しいサービス提供者にリアルタイム移動させるプロセスを管理することができる。ディレクトリサービス216の構造は、トランザクションをリアルタイムで処理する能力と共に、ユーザが数日ではなく数分でアカウントを変更することを可能にする。
【0416】
ディレクトリサービス216は、上述したように、全てのトランザクションのリアルタイム処理と共に未定の支払い(in-the-air payment)のような未定のトランザクション(in-the-air transaction)の問題を除去する。Tereonでは、トランザクションは単に未定の状態に進入できない。それらは完了したり取り消される。
【0417】
Tereonは、銀行アカウントの移動性(bank account portability)、市場での競争を増加させる機能、そして銀行及び規制機関は実現できないものと考えている機能などの、アカウントの移動性(account portability)という概念を支援する。Tereonは、アカウントの詳細を直接使用せず、各支払人(payer)と受取人(payee)を識別するために別途のクリデンシャルを使用することから、ユーザ218とユーザの銀行アカウントの詳細間に抽象化を挿入する。ディレクトリサービス216が提供する抽象化は、アカウントスイッチング及び移動性を容易にする。
【0418】
クリデンシャルの変更(Changing credentials)
ディレクトリサービス216は、運営者及びユーザが既存のIDクリデンシャルを新しいクリデンシャルに変更し、IDの以前のユーザとのトランザクションを混乱させることなく、過去のクリデンシャルを再利用することを可能にする。ディレクトリサービス216によって提供される抽象化レイヤは、Tereonがこれを可能にする。
【0419】
ユーザ218が自分のアカウントを他のサーバに振り込む場合、ユーザ218は、PANのような特定クリデンシャルを保有することができ、又は、サーバがユーザ218に新しいクリデンシャルを発行し得る。後者の場合、本来のサーバはほとんどすぐにクリデンシャルを再利用できる。各クリデンシャルは、それがユーザ218に発行されるときを反映する日時スタンプを有するため、特定のクリデンシャルの新しいユーザ218はそのクリデンシャルをほとんどすぐに使用できる。
【0420】
各クリデンシャルは、特定のサーバの特定のユーザに発行された日時スタンプを有する。各トランザクションも日時スタンプを保持し、各Tereonサーバも各トランザクションに使用されたクリデンシャルを保有するため、Tereonはトランザクションを正しい配信先にルーティングするためにこのコンポーネントを使用する。例えば、ユーザ218は、クリデンシャルA(例えば、モバイル番号)を有するマーチャントから何かを購買し、他のクリデンシャルB(例えば、新しいモバイル番号)を使用する必要があるとき、数日後に他の銀行に移動する。アイテムが欠陥のある場合、後でユーザ218はアイテムをマーチャントに送り返す。マーチャントは、トランザクションを探して払い戻せば良い。本来のトランザクションがクリデンシャルAを使用したが、クリデンシャルAに対するサーバは、クリデンシャルの変更を示す日時スタンプを報告する。マーチャントのサーバは、クリデンシャルAを探して、トランザクション当時にクリデンシャルAを使用したユーザ218が現在にクリデンシャルBを使用していることを発見する。サーバは、クリデンシャルBに対するサーバ(クリデンシャルBに対するユーザ218がトランザクション当時にクリデンシャルAを使用したことを確認する)に接続し、サーバは払い戻しのプロセスを開始する。
【0421】
Tereonのセキュリティーモデルでは全ての通信に署名しなければならないため、ユーザAはユーザBが不正でないことを確信できる。サーバ202bは、ライセンスサーバからの有効なライセンスを有する場合にのみその通信に署名し、サーバ202bがデバイスのライセンスを発行して確認することからユーザBのデバイスはサーバ202bが有効な場合、その通信を署名する。ユーザBがトランザクションを承認するかデバイスのアプリケーションにアクセスするために必要な正確なクリデンシャルを知らない限り、ユーザBはトランザクションを完了できない。
【0422】
更なる例として、ユーザは自分の電話帳に連絡先のモバイル番号を入力し、その連絡先にサプライズP2P振込みを所望することもある。Tereonは、該当番号に対するレコードを検索し、上記のように連絡先がモバイル番号に変更されたことを検出する(連絡先がTereonユーザである場合)。新しいサーバ番号を使用するユーザが以前のサーバに登録された古い番号を使用したことを正確なサーバで確認する。また、Tereonは、特定の承認された連絡先が古いクリデンシャルを介してトランザクションを試みるとき、ディレクトリサーバで該当ユーザのモバイル番号又は異なるTereonクリデンシャルをアップデートできるように連絡先が自分のアカウントを設定する機能を支援する。この例で、叔母の姪が家族全員をアップデートするようにアカウントを設定しているため、次に叔母が自分の連絡先リストにアクセスすれば、彼女は自分の姪の新しいモバイル番号を確認できる。
【0423】
図16は、サーバ202a、サーバ202b、及びディレクトリサービス216に対する例を示す。ここで、古いユーザは、自分のアカウントをサーバ202aからサーバ202bで移転した。202aは銀行Aのサーバ、202bは銀行Bのサーバである。
【0424】
古いユーザは、最初に自分のIDとしてモバイル番号1を使用する。そのアカウントを移転した後、彼はしばらくの間モバイル番号1を続けて使用する。ユーザ218、ディレクトリサービス216、及びサーバ202a及び202b間の通信は、図15に図示されて上述したように行われる。ディレクトリサービスのエントリは、ユーザ218が日時1(date-time1)から日時3(date-time 3)までサーバ202aを使用し、日時2(date-time 2)から彼がサーバ202bを使用したことを示す。僅かな重複は、全ての未定の支払いがキャッチされ、ユーザが自分のIDが登録されているサーバを有しないという時間的なギャップがないことを保証することである(アカウントの移行先のサーバがその移行のすべての日時エントリとIDエントリを制御可能にすることで、日時エントリが重複しないようにすることができる。これがシステム移行の動作方法である)。
【0425】
ある時点で、ユーザ218は、モバイル番号を変更することを決定した。新しいモバイル番号2を自分のIDとしてサーバ202bに登録し、モバイル番号1を登録解除する。サーバ202bは、ディレクトリサービス216に変更を通知する。これはユーザが日時4にモバイル番号2を自分のIDとして使い始めたことを示し、モバイル番号1が日時5でサーバ202bに対してIDでの使用が中止されたことを示す。
【0426】
後で、新しいユーザはサーバ202aにアカウントを生成し、日時6で自分のIDとしてモバイル番号1を登録する。新しいユーザへ古いユーザの以前のモバイルが提供された場合もあり、該当番号がモバイル運営者によって再利用のために解除されることもあり得る。サーバ202aは(IDが利用可能であることを確認した後)IDを登録したことをディレクトリサービス216に通知し、ディレクトリサービスは、日時6の時点でモバイル番号1がサーバ202aに登録されていることを示す。
【0427】
図16に示すように、古いユーザが銀行A202aによって発行されたカードを使用する場合、まずユーザ218が自分のアカウントを銀行B202bに送信すると、銀行はPANのようなクリデンシャルを用いて新しいカードをユーザ218に発行する。ユーザ218はカードを受け取ると、カードを活性化し、銀行Bのサーバ202bは、ユーザの本来のクリデンシャルがこれ以上使用されないことを銀行Aのサーバ202aに通知する。銀行Bは、Tereonディレクトリサービス216に新しいクリデンシャルを登録する。ユーザ218は、本来のクリデンシャルを保持することを要求してもよく、銀行Aが要求に同意した場合、そのようにするために彼は銀行Aから小額が割り与えられる。したがって、Tereonはカード番号又はPANの移動性を支援する。
【0428】
ユーザは、将来のある時点で、最初に銀行Aから発行したカードの使用を中断し、該当クリデンシャルを解除してもよい。銀行Bがそれを解除した後、又はユーザがアカウントを銀行Bへ振込んだ後6ヶ月の間に、銀行Aは該当PANのクリデンシャルを再利用できない。正確な時間は、銀行の規制当局が許容する内容に応じて異なる。ここで、時間が経過すると、ディレクトリサービス216がモバイル番号、PAN又は他のクリデンシャルを含まないため、それはクリデンシャルを使用することができる。また、それはクリデンシャルの登録された日付、ユーザ基準として期限切れになった日付、又はユーザごとにリリースされた日付のリストを含む。
【0429】
アカウントの切り替え方法は、システムが未定の支払いをキャプチャー可能にする。また、以前のトランザクションで使用されたクリデンシャルに基づいて以前のトランザクションから後続のトランザクションを送信できる極めて柔軟で強力な方法を提供する。以前のトランザクションに対する払い戻しは、実際の事例の1つである。元のIDが後で再び使用された場合にもディレクトリサービス216がサーバに正しいIDを支払うように指示するため、古いIDに対して返金するマーチャントは、正しいアカウントを返金できる。EMV及び現在のモバイルルックアップ技術は、数字が再利用されることは決してないと仮定する。残念ながら、彼らは時にはそうである。
【0430】
これについて図16で示されている。日時1と日時2の間のある時間で、古いユーザがモバイル番号1をIDとして有するデバイスを用いてマーチャントからアイテムを購入すると仮定する。後でそのアイテムが誤ったことが分かり、ユーザは払い戻しを所望する。
【0431】
ユーザ218が払い戻しのために日時1と日時2の間にマーチャントへ行く場合、Tereonシステムは、マーチャントシステムがシステム202a上のユーザアカウントに払い戻しの支払いを行うよう指示する(ユーザがまだアカウントを閉鎖していないため)。
【0432】
ユーザ218が払い戻しのために日時2と日時4の間にマーチャントへ行く場合、アイテムに対する支払いが元のサーバ202aからきたにもかかわらず、Tereonシステムは、マーチャントシステムがシステム202b上のユーザアカウントに払い戻しするように指示する。
【0433】
アカウントの切り替え方法は、ユーザの新しいIDも考慮されるのであろう。ユーザ218が払い戻しのために日時4の後マーチャントに行き、そのモバイル番号2をそのIDとして使用した場合、たとえアイテムに対する支払いが元のサーバ202aからきたとしても、ユーザが本来自分の支払いIDでモバイル番号1を使用したにもかかわらず、Tereonシステムは、マーチャントシステムがシステム202b上のユーザアカウントに払い戻しするように指示する。
【0434】
PAN、電子メールアドレス、その他の再利用可能なクリデンシャルのレコードも同一に保持される(明らかな理由で生体クリデンシャル(Biometric クリデンシャル)は再利用できない)。
【0435】
このシステムは、クリデンシャルをあらゆるレベルに細分化できる。この支払い方法の1つの例は、通貨又は通貨コードを含む。ここで、ユーザは同じ通貨又は別途のサーバで互いに異なる通貨に対して互いに異なるIDを使用してもよい。
【0436】
図17は、サーバ202b、サーバ202c、及びディレクトリサービス216に対する例を示す。図面において、ユーザ218は、図15に示すように管理されるサーバ間の通信を介して図16に示すものと同じ方式により、サーバ202bからサーバ202cへ自分のアカウントをすでに移動させている。
【0437】
ユーザ218は、初期に自分のIDとしてモバイル番号1を使用する。そのアカウントを移動した後、彼は通貨1及び通貨2内のトランザクションに対してしばらくの間にモバイル番号1を続けて使用する。ディレクトリサービス216のエントリは、ユーザ218が日時1から日時3までサーバ202bを使用し、日時2から彼がサーバ202cを使用したことを示す。僅かな重複は、全ての未定の支払いがキャッチャされ、ユーザが自分のIDの登録されているサーバを有しない場合に、時間差がないようことを保証することにある。
【0438】
ある時点で、ユーザ218は、通貨2内のトランザクションに対して新しいモバイルを使用することを決定した。彼は、通貨2内のトランザクションに対して自分の新しいモバイル番号2を自分のIDとしてサーバ202bに登録した。サーバ202bは、ディレクトリサービス216に変更を通知した。これは、ユーザが日時4で通貨2の全てのトランザクションに対してモバイル番号2を自分のIDとして使い始め、モバイル番号1が日時5までの全てのトランザクションに対してIDでの使用が中止されたことを示す。
【0439】
図17aは、サーバ202b、サーバ202c、及びディレクトリサービス216に対する異なる例を示す。図面において、ユーザ218は、図15に示すように管理されるサーバ間の通信を介して図16に示されたものと同じ方式でサーバ202bからサーバ202cへ自分の通貨1アカウントをすでに移動させた。
【0440】
アカウントを移動した後、ユーザはモバイル番号1を使用する時間の間に、通貨1と通貨2間のトランザクションを続く。ディレクトリサービス216内のエントリは、ユーザ218が日時1から日時3までサーバ202bを使用し、日時2から彼が通貨1内のトランザクションに対してモバイル番号1を自分のIDとしてサーバ202cに使用したことを示す。また、ディレクトリサービスエントリは、ユーザが通貨2内のトランザクションに対してモバイル番号1を自分のIDとしてサーバ202bに続けて使用したことを示す。
【0441】
ある時点で、ユーザ218は、通貨2内のトランザクションに対して新しいモバイルを使用することを決定する。彼は通貨2内のトランザクションに対して自分の新しいモバイル番号2を自分のIDとしてサーバ202bに登録した。サーバ202bは、ディレクトリサービス216に変更を通知する。これはユーザが日時4で通貨2内の全てのトランザクションに対してモバイル番号2を自分のIDとして使い始め、モバイル番号1が日時5までの全てのトランザクションに対してIDでの使用が中止されたことを示す。
【0442】
日時4より前では、ユーザ218は、自分のモバイル番号1を全てのトランザクションに対してIDとして使用した。ディレクトリサービス216は、単にトランザクションが通貨2である場合にトランザクションをサーバ202bに向かうようにし、トランザクションが通貨1内にあれば、トランザクションをサーバ202cに向かうようにした。トランザクションの伝えられるサーバを制御するクリデンシャルの完全な集合であるため、ユーザが2つのサーバに同じIDを登録したという事実は無関係である。日時2の後に初めて通貨1でユーザとトランザクションするマーチャントのシステムは、ユーザが前に該当の通貨内のトランザクションに対してサーバ202bを使用したことを知らない。同様に、マーチャントのシステムが通貨2でユーザとトランザクションを開始しない限り、マーチャントのシステムは、ユーザが通貨2内のトランザクションに対して同じIDをサーバ202bを使用したことを知らないのであろう。
【0443】
Tereonは、単にユーザ218を1つのネットワークから別のネットワークに切り替えること以上の役割をする。すでに前述したように、ユーザを切り替える一般的な方法は、未定の支払いを処理できない。創始者などによって主張されたように、現在の利用可能な最も進歩したアカウントの切り替えシステムは、ユーザが自分を待つ前に支払い金を受けるために18ヶ月の手動プロセスを必要とする。18ヶ月の間に、銀行とユーザは古いアカウントから新しいアカウントへ既存の全ての支払い命令を移行するように努めなければならない。Tereonはこの要件を完全になくしたのである。
【0444】
現在、銀行は支払いクリデンシャルを再利用できない。Tereonのアカウントの切り替えメカニズムは、このような制限を取り除き、規制機関から許容された場合、特定期間が過ぎた後銀行がPAN及びアカウント番号を再発行できる。
【0445】
この方法は、をアカウントの切り替え機能と呼ばれるが、実際には、基本アカウントの切り替えに加えて多くのアプリケーションがある。例えば、銀行のコアシステムが障害が生じた場合、バックアップサービス提供者に障害克服(failover)を提供し、情報の損失なく、1つのデータ形式から別のデータ形式に変換することで、あるシステムから他のシステムにデータを移行移行できる方法を提供する。
【0446】
更なる例は、モバイルシステムで番号の移動性(number portability)を簡素化することにある。現在、ユーザが自分のモバイル番号をある供給者から他の供給者に切り替えた場合、第1供給者は、新しい供給者に対する全ての呼出(call)を再びルーティングしなければならない。ユーザが第3供給者に切り替えた場合、第1供給者は、第2供給者に呼出をルーティングしなければならず、第2供給者は、第3供給者に呼出をルーティングしなければならない。これは効率的ではなく、多くのコストがかかるが、運営者は、番号の移動性を支援しなければならない。Tereonは、呼出を何度もルーティングする必要がなくなる。
【0447】
運営者が番号の移動性を支援するためにTereonを使用すれば、彼らは複数のホップを支援する必要がない。ユーザ自分の番号を第1運営者から第2運営者に移すことと決定すれば、第2運営者は、単にディレクトリサーバに現在の該当モバイル番号を支援することを通知だけすればよい。第1運営者は、該当番号に対する呼出をディレクトリサーバに送信すれば第2運営者に呼出がルーティングされる。ユーザが自身の番号を再び移転するごとに、新しい運営者は、ディレクトリサーバに変更事項を通知し、ディレクトリサーバは、該当番号をサービスする運営者に呼出をルーティングする(ユーザが全世界に固有なIBANのような銀行アカウントを保有している場合、Tereonは、モバイル番号の移動性を支援するのと同じ方式で銀行アカウントの移動性を支援する)。
【0448】
同様の例は、物理的機械、論理機械、仮想機械、コンテナ、又は、実行可能なコードを含む他の一般的に用いられるメカニズムなどの単純移行は充分でないTereonシステムをアップグレードするために、運営者が1つのサーバから別のサーバにIoTサービスとデバイスを移行する例である。
【0449】
他の例は、システムが移行ツールとして作動することにある。例えば、これは運営者が、あるバージョンのTereonシステムからジョンでアップグレードされたバージョンでデバイスの登録されたアカウントと共にサービスを移行しようとする場合である。運営者は、デバイス登録、アカウント、及びシステム構成(system configurations)を新しいサーバに送信するように古いサーバを設定し、システムがその送信を行う。各アカウントは、データ及び監査ログ(audit logs)と共に送信され、送信進行によってサーバはディレクトリサービス216をアップデートする。今、その分野のデバイスが、支払いデバイス、交通センサ、IoTデバイスなどのサーバと通信することを所望する場合、ディレクトリサービス216は、それらを古い又は新しいサーバに単にリダイレクトする。アカウントが送信される前または後に、彼らはサーバに接続する。
【0450】
上記の例は、Tereonがクリデンシャル移動性を容易にし、アドホック多面的なクリデンシャルを支援する方法を示す。これは幅広いアプリケーションを保有し、Tereonをネットワークでクリデンシャルを管理しなければならないことの全てのネットワーク分野に適用する。
【0451】
拡張可能なフレームワーク(Extensible Framework)
既存のトランザクション処理システムのワークフローは、本質的に静的なものである。ひとまず具現されると、それらは変更することが難しく、システムが支援するサービス又は動作は柔軟性がない。
【0452】
今まで、支払い提供者がサービスを開始した場合、当該サービスに対する支払いパターンは静的であった。提供者は交換又は修正されたサービスを開始し、当該のサービスを支援するために新しいカード又はアプリケーションを発行することで当該サービスを修正のみを行ってもよい。これがEMVの深刻な弱点に対する普遍的な知識にもかかわらず、既存のすべてのEMVカードをリコールしてEMV支払いインフラを再プログラミングして実行し、新しいカードを発行する意味を意味し、システムを修正できない理由のうちの1つである。カードこれは何千もの発行者と取得者が協力することを要求する。
【0453】
TereonはSDASFを用いて全ての機能をバックエンドに置き、バックエンド(back-end)は、プロセスを介してリアルタイムにマーチャントデバイスを案内できる。これにより、サービス提供者が個別ユーザだけ細部的な新しいサービスを作成できる。
【0454】
拡張可能なフレームワークは、Tereonシステム内に位置するフレームワークで、Tereonシステムを再構成する必要がなく、新しいサービスを追加し得る。拡張可能なフレームワークは、Tereonシステムに様々な利点を提供するためにディレクトリサービス216と共に作動する。
【0455】
柔軟なメッセージ構造(Flexible message structure)
拡張可能なフレームワークは、柔軟なメッセージ構造(可変長フィールドのある全てのデータ又はレコードタイプが提供され、Tereonシステムがレガシー又は互換されないシステムで作動するようにフィールドの長さを修正できる)によって部分的に提供される。
【0456】
拡張可能なフレームワークは、標準的なプロセスの順序を変更することによって通信インフラストラクチャーに追加のセキュリティーレイヤを追加できる。多くの産業分野で支払いは単に一例であり、通信は、固定されたメッセージ構造を使用する。通信が暗号化された場合にも、これは犯罪者が悪用できる脆弱さが発生させる。構造化されたメッセージは、徹底的な攻撃に脆弱である。組織及び他の組織は、HMAC(hash message authentication code)を用いてメッセージの無欠性を保護できるが、HMACはメッセージが引き付けるべき絶対的な機密性を保管しない。
【0457】
拡張可能なフレームワークは、全てのトランザクション処理システムに対して静的システムの問題を解決する。それは既存のシステム及びサービスと共に作動できる柔軟性を提供し、提供者が既存のサービスをアップデートし、インフラストラクチャーを再び稼動したり、カードのような新しいエンドポイントデバイス(end-point device)を発行する必要がなく、新しいサービスを構築できるようにする。これについては下記で説明する。
【0458】
乱読化(Obfuscation)
構造化されたメッセージ形式を有するシステムが直面する理論的なリスクの1つは、メッセージ形式を繰り返し使用すると、ハッカーが無差別な攻撃に使用できる十分な資料を提供する。これは、いずれかの形態のランダムシード(random seeding)を用いて暗号化アルゴリズムを正しく実現していないシステムに該当する。
【0459】
拡張可能なフレームワークにより、運営者とユーザはデバイスとサーバとの間に構造化メッセージを送信する必要性をなくす。代わりに、メッセージは乱読化される。
Tereonの各トランザクション通信は、該当フィールドのレーベルと共に2つ以上のフィールドを含む。通信ごとにフィールドの固定順序をたどる代わりに、順序をランダムに変更することができる。各フィールドには常に識別タグが付いているため、通信の両端にあるデバイスをまず復号化し、次にフィールドを処理する前に順序付けするようにする必要がある。
【0460】
例えば、JSON(JavaScript Object Notation)の資料で提供される例からの抜粋を利用すれば(もちろん他の形式もシステム内にあり、使用される)、次の3つの表現が同一である。・{“version”: 1, "firstName": "John", "lastName": "Smith", "isAlive": true, "age": 25}・{“version”: 1, "firstName": "John", "isAlive": true, "lastName": "Smith", "age": 25}・{"age": 25, "firstName": "John", "isAlive": true, "lastName": "Smith", “version”: 1}
攻撃者は自分が有するサイファーテキスト(cypher texts)に既存の同じ順のような情報を含んでいるか分からない。乱読化の正確なモードは、使用されている形式及び使用されているシリアル化プロトコルによって異なるが、原則は変わらない。
【0461】
乱読化モードは、追加の利点を有する。予め定義された通信のコンテンツは、通信プロトコルを壊すことなく拡張される。デバイスが処理できないフィールドを受信すると、デバイスは、該当フィールドとその値は単に廃棄される。したがって、1つ以上のランダムフィールド及び値の対(pair)はシステムが廃棄することに含まれ、追加的な不確実性を通信に追加する。
【0462】
したがって、次の3つ通信は同一である。・{“version”: 1, "firstName": "John", “nonce”: 5780534, "lastName": "Smith", "isAlive": true, "age": 25}・{“whoknows”: “698gtHGF”, “version”: 1, "firstName": "John", "isAlive": true, "lastName": "Smith", "age": 25}・{"age": 25, "firstName": "John", "isAlive": true, "lastName": "Smith", “whatis this”: “Jor90%hr,” “version”: 1}
上記の通信において、デバイスは未知のフィールド及び値の対を捨てる。
【0463】
通信ごとにケースをランダムに混在させることで、フィールド名をさらに難読化できる。デバイスはこれらのフィールドを標準形式に処理する。
したがって、次の3つ通信は同一である。・{“veRsioN”: 1, "firstName": "John", “nOnce”: 5780534, "laStnAMe": "Smith", "isAlive": true, "Age": 25}・{“whoknows”: “698gtHGF”, “vErsion”: 1, "fiRStname": "John", "iSaLive": true, "lastName": "Smith", "age": 25}・{"aGE": 25, "firstname": "John", "isAlive": true, "lasTName": "Smith", “whatis this”: “Jor90%hr,” “versIOn”: 1}
追加フィールドを含む可能性のあるバージョン2メッセージが送信されれば、バージョン1しか理解できないデバイスはメッセージを拒否したり、下位の互換性(backwards compatibility)が保障される場合は、理解したフィールドを処理して残りは捨てる。どのジョンが一部のフィールドと下位互換されるかを示すフィールドを提供することで、これらをより向上させ得る。
【0464】
これにより、攻撃に対する脆弱性を徹底に除去する。メッセージの構造も保持さできるが、可変長フィールドを使用する。これもまた、同じ結果を達成する。また、HMACを使用することで、メッセージの無欠性と機密性の両方が保護される。エンド組織のコアシステムが構造化された形式のメッセージを必要とする場合、Tereonは、メッセージがサーバに達すればメッセージを再構成し、組織のコアシステムから要求される形式にメッセージを再フォーマットする。拡張可能なフレームワークは、レガシーシステムのセキュリティー問題を克服することを可能にし、依然としてこのようなシステムで動作することを可能にする。
【0465】
拡張可能なフレームワークは上記と同じレベルのセキュリティー及び柔軟性で、あらゆるデータ又はレコードタイプを支援する。
抽象化されたワークフローコンポーネント(Abstracted workflow components)
既存ソリューションでは、支払いプロセスはソフトウェアで定義され、具現され、テストされ、そして、リリースされる。その支払いトランザクション構造は固定され、デバイス、端末、及びサーバをリコール及び交換したり再プログラムするための著しい努力なしには変えることができない。
【0466】
Tereonはこれを行わない。代わりに、これは個々が接続されたコンポーネントと相互作用する個別コンポーネントから支払いプロセスを構成する。このようなコンポーネントは、本質的にプロセスのワークフローを配置する。各コンポーネントは、アップデートされ、支払いプロセスそのものに影響を与えることなく機能を追加することができる。これは、デバイスからプロセスコンポーネントを抽象化するため、一度定義されたトランザクションがカードやカード端末、モバイル、又は、ウェブポータルのような複数のデバイスに適用されてもよい。
【0467】
各コンポーネントは、受信した命令の結果に応じて命令及び情報を次のコンポーネントに伝達する。命令は、トランザクション式(transactional)でも次のコンポーネントが作動する方法などの制御を含むことができる(例えば、選択事項である場合にPINの要求、選択の集合を提供、特定メッセージの表示、及び予想される応答又は許可される応答)。
【0468】
これにより、既存のエンドポイントを再プログラミングしたり置き換えする必要がなく、既存の支払いサービスを変更して新しいサービスを構築することができる。現在、支払いサービスの提供者が支払いシステムを実現すると、支払いサービス提供者は、エンドポイントを交換せずシステムを容易に変更することができない。既存のシステムは基本的に静的である。これは、それらを動的システムに置き換える。
【0469】
拡張可能なフレームワークにより、運営者がこのようなコンポーネントを用いて特定のトランザクションに対するワークフローを計画することができる。それは、意思決定ツリーなどを含むワークフローを実現する。運営者は、既存のコンポーネントを再配列したり、新しい機能を提供する新しいコンポーネントを追加したり、コンポーネントを除去することによって既存のワークフローを修正する。既存のシステムでこれを行うために、サーバ及び端末を再プログラムし、カード自体を交換させる必要がある。
【0470】
これの例が図18図20に図示されている。各コンポーネントが何をしているかを視覚化しやすくするために、コンポーネント自体は端末画面によってブロックとして表されています。しかし、これらのコンポーネントは、モバイルトランザクション、ウェブポータルトランザクション、及びカード端末トランザクションに同じく適用される。既存のワークフローを変更するために、コンポーネントの順と接続は簡単に変更される。新しいワークフローを作るためには、必要なコンポーネントを単に所望する順に接続する。
【0471】
通常の支払いプロセスは、非接触式、連絡先、及びモバイルの支払いに対して別途の支払いプロセスを生成する。コンポーネント1804は、図18に示すような「定時に完全なトランザクション(complete transaction in time)」コンポーネント1802直後にチェーンの左側に一般的に示される。
【0472】
しかし、図19に示すように、このコンポーネントを右側に沿ってさらに移動させることで、2つの異なる決定コンポーネント1902及び1904をチェーンに挿入すると、運営者は、単一支払いプロセスで接触、非接触、及びモバイル支払いを管理できる単一支払いプロセスを生成し得る。
【0473】
運営者は、さらに進むことができる。システムが顧客を識別した後プロセスに特別な季節の提案(seasonal offer)を追加しようとする。図20に示すように、それはいつでもコンポーネント1804をさらに右側に移動させ、マーチャントが金額及びPINを入力しなければならない前に、自動的に顧客へ提案を提供する新しいコンポーネント2002を本来の位置に挿入する。運営者は、例えば、そのコンポーネントをクリスマスまでの24日間で動作するように設定し、それ以降は新年までの間は別のコンポーネントを提供することができる。運営者がリコール、再プログラム、及びデバイスを必要とせず、これはクリスマス及び新年シーズンの支払いプロセスを動的に変更し得る。コンポーネントは、顧客に提案を表示するようモバイル又はカード端末であるディスプレイデバイスに指示するだけでよい。運営者は、PIN要求事項を不活性化するコンポーネント1804を構成することで、PIN要求事項を容易に不活性化し得る。同様に、コンポーネントがPINを要求する機能を有していない場合、運営者は機能を含むように該当コンポーネントをアップデートし得る。
【0474】
運営者はさらに進んで、顧客が必要に応じて様々な提案の中から選択できるように全体的な意思決定ツリーを構築し得る。提案シーズンが終了すると、運営者は、新しいコンポーネントを除去するだけで、プロセスは本来の構造を再び開始する。
【0475】
重要なことは、運営者がいつでもプロセスを変更するためにデバイスをリコールする昼用がないことにある。バックエンド(back end)でプロセスを再構成してから、選択した日時に変更事項を実現する。
【0476】
Tereonサーバの内部管理及び運営を提供するフレームワークは、正確に同じ方式で構成できる。ここで、フレームワークコンポーネントは、ユーザと管理者がアクセスできる方法及び情報、実行できるタスクを管理するアクセスコンテキストと相互作用する。
【0477】
動的サービス(Dynamic services)
拡張可能なフレームワークにより、組織は新しいサービスを迅速に作動及び実現可能にする。運営者は、必要なブロックを互いにリンクし、関連メッセージを定義することで、このようなサービスを簡単に定義する。サービスコードを作成するためにプログラマーを雇用する必要がなく、フレームワークはマーケティング及びIT部門がワークフローを定義する定義ファイルを作成したり、「ワークフローを描く」ためのグラフィックシステム(graphical system)を使用したり、又は、プロセスを定義する異なるワークフローによりサービスを実現することができる。ワークフローを確認した後、運営者は定義されたステップ又はブロックをともにリンクすることによってワークフローを簡単に実現し、Tereonは、全ての資格のあるユーザがサービスを利用できるようにする。
【0478】
例えば、運営者は、ブロックを用いて任意の値の支払いを受け取ることができ、その後のブロックでPINを要求する必要がある。しかし、運営者がアクセス制御システムを提供しようとする場合、同じ運営者は、別のセットのルームにアクセスできるPINを要求するためのブロックを使用する一方で、ワンセットのルームにPINなしでアクセスを許容するブロックを生成する。
【0479】
これは、既存のシステムとは異なり、組織がトランザクション処理システムを始めた後でもユーザに発行されたデバイスを交換する必要なく、組織が新しいサービスを設計及び実現したり、既存のサービスを修正又は除去できることを意味する。デバイスが定義されたステップを理解してそれを作動できる場合、該当デバイスは、組織が定義した任意のサービスを該当ステップを使用して提供し得る。組織がサービスを定義すると、システムは、当該サービスを対象ユーザ又はユーザに直ちに利用可能にする。
【0480】
抽象化されたデバイス(Abstracted devices)
拡張可能なフレームワークは、抽象化の原理を取り入れ、デバイスそのものを抽象化する。フレームワークは、それらのデバイスの機能に関するデバイスの各クラスのプロセスコンポーネントを定義する。プロセスコンポーネントは、該当機能コンポーネントと相互作用する。使用可能な機能により、プロセスコンポーネントは何を出力し、何を入力するかのような作業を実行するような機能コンポーネントに指示する。
【0481】
粒度(Granularity)
Tereonは、各デバイス、ユーザ、及びアカウントを個別的に識別し、ユーザがデバイスを用いてサービスにアクセスするコンテキストをアクセスできる。したがって、運営者は、個々のユーザがサービスにアクセスするコンテキストに基づいて動作(action)をトリガーするために、コンポーネント及び該当コンポーネント内のオプションを設定できる。Tereonは、運営者が効率よく各ユーザ、各ユーザのデバイス、及びユーザが該当デバイスを使用してサービスにアクセスするコンテキストに合わせてサービスを調整できる。
【0482】
例えば、あるユーザが1つのトランザクションで3つの提案のうち1つを選択することができ、他のユーザは自動的に受け取る1つの提案のみを選択することができ、3番目のユーザは提案が全く表示されない場合もある。
【0483】
プロセスがレコード(例えば、患者レコード)にアクセスすることに関する場合、ユーザは自分のレコードにアクセスし、ユーザが医療施設又はホームドメインのレコードにアクセスすれば、ユーザはアクセス権限を管理することができる。しかし、ユーザ(又は、他のユーザ)が該当ドメイン外部のレコードにアクセスする場合、ユーザは、該当レコードの下位集合しか表示されないか、又は該当レコードにアクセスできない(当該サービスに対するコンテキスト設定に応じて異なる)。
【0484】
ユーザがカード端末を用いてサービスにアクセスする場合、コンポーネントは、カード端末に関連情報を表示するように指示する。ユーザがモバイル又は他の画面デバイスを用いて同じサービスにアクセスする場合、コンポーネントは、スクリーンに関連情報を表示するように指示する。このような方式で、拡張可能なフレームワークの抽象化レイヤはデバイスに独立的である。ユーザシステム間の相互作用を制御するために適切なディスプレイ及びアクセスポイントを使用し得る。
【0485】
提供されるサービスにも同一に適用される。各ユーザのアカウントには、サービスの提供者デフォルトレベル(default level)を有する。運営者が新しいサービスを追加したり、1つ以上のユーザに対する既存サービスを修正する場合、該当ユーザのアカウントには当該サービスが存在する。サービスの核心は、提供者タグ、ユーザのアカウント番号、ユーザのデバイス登録タグの組合せである。これにより、該当ユーザ対するサービスの定義及び規則に樹枝状経路(dendritic path)を生成する。
【0486】
例えば、発信者は、双方向又は自動振込み(interactive or automatic transfer)を許容する規則を設定したモバイルを使用してもよい。受信者は、自動振込みを許容するようにデバイスを設定してもよい。この場合、発信者のデバイスは自動振込みを行うためのステップを実行するだけである。サービスタグは、振込みが双方向であるか否かに対する情報を含まない。これは発信者と受信者のサーバに格納されたサービスに関する情報に残る。
【0487】
受信者が双方向又は自動振込みを許容するようデバイスを設定した場合、発信者のデバイスは発信者に使用するモードを要求する。受信者が特定の時間内に自動振込みを許容するようにデバイスを設定し、それ以外の時間には双方向振込みを許容するようにデバイスを設定してもよい。ここで、受信者のTereonサーバは、受信者の時間に応じて発信者のサーバに使用する振込みモードを通知するだけである。
【0488】
発信者又は受信者のデバイスが双方向振込みのみを受け入れる場合、受信者及び発信者が同時にオンライン状態であると、彼らは振込みを実行するステップを行う。受信者がカードしか持っていない場合、受信者はトランザクションのその側面(his side)を実行するためにマーチャントの端末に行かなければならない。受信者がオフラインである場合、発信者はそのステップを実行するが、受信者は、Tereonが振込みを完了する前に振込みを受諾してPINを入力するなどのようなトランザクション内のステップを行わなければならない。それまで、Tereonは、Tereon以外のユーザに振込みを扱う同じ方式により、エスクロー機能(escrow facility)で振込みを保留する。
【0489】
動的インタフェース(Dynamic interfaces)
拡張可能なフレームワークは、コンテキスト依存的サービス(例えば、提案、イベントで着席できるようにユーザを助けること、マーチャント特定のプロセスなど)を誘導する。これは組織がユーザがTereonと相互作用するとき、各ユーザが有するサービスと経験、コンテキストによりサービス可能な程度、表示されるボタン、使用可能なオプションなどをユーザが指定可能にする。
【0490】
各ユーザ及び各マーチャントが相互作用できるサービス数は、個々のユーザがアクセスできるサービスとマーチャントが提供できるサービス間の重複的な部分に完全に依存する。
【0491】
例えば、マーチャントが支払い、入金、及び引き出しを提供できて、ユーザが該当マーチャントを訪問し、該当ユーザはマーチャントの支払いにしかアクセスできない場合に、ユーザとマーチャントは支払いに関する機能、すなわち支払いと返金のみを見ることができる。ユーザが同じマーチャントを訪問した場合、該当ユーザは支払い、入金、及び引き出しにアクセスし、該当ユーザは全ての機能を見ることができる。該当マーチャントが入金及び引き出しを支援する十分な資金がない場合、フルサービスユーザが該当マーチャントを訪問したとき、ユーザは自分のデバイス又はマーチャントの端末で支払い機能のみを見ることができる。該当マーチャントは、マーチャントまで入金又は引き出しを提案するマーチャントに対する検索にもこれ以上表示されなくなる。ユーザが一部のマーチャントの特定サービスにアクセスできないが、他のマーチャントのサービスにアクセスすることはできる。フレームワークはこのような場合を処理する。
【0492】
動的インタフェースは、多面的なクリデンシャルの使用を補完し、デバイス及び関連アプリケーションが言及したように「サイキックペーパー(psychic paper)」に類似したものにすることを可能にする。この場合、デバイスは、利用可能なサービスのみを提供し、ユーザが登録される複数のサービスに関係なく、インタフェースはそのようなサービスに合わせて調整される。あるサービスへの支払いデバイス、他のサービスに対するトランスポートチケット、他のサービスに対するドアキーなどとのように見えることができる。サービス提供者は、サービスにアクセスするために別途のデバイスを発行する必要がないことから、サービス提供及び当該サービスアップグレードの複雑性とコストを節減できる。
【0493】
拡張可能なフレームワークはデバイスがその外観を変えること、デバイスが使用されるコンテキストによって求められるクリデンシャル及びサービスを提供することを可能にする。例えば、ユーザが食料品店にあるような独立的なATMへアクセスするとき、ユーザの運営者の外観と感じを取るために該当ATMのスクリーンを調整し、ユーザが加入したサービスのみを提供する。
【0494】
他のレイヤとの相互作用(Interaction with other layers)
Tereonシステム内の他のコンポーネントと相互作用できる拡張可能なフレームワークの能力は、拡張可能なフレームワークの基本的な機能である。さらに広いセキュリティーモデルを含むコンテキストセキュリティー(contextualsecurity)とは別に、拡張可能なフレームワーク命令は、ハッシュチェーンを介して送信されるトランザクション情報内に埋め込むことができる(ゼロ知識証明を有するハッシュチェーンと関連して開始されたように)。
【0495】
オフラインモード(Off-line mode)
Tereonは、3つオフラインモードを提供する。ユーザオフライン、マーチャントオフライン、及び両方オフライン。
【0496】
最初の2つの場合では、Tereonは四角の反対方向に移動してリアルタイムトランザクションを完了する。すなわち、ユーザは、マーチャント端末及びマーチャントのTereonサーバを介して自分のTereonサーバと通信する。マーチャントやユーザの全てはサービス低下を経験しない。Tereonは、関連のデバイスに対する正方形の3辺を通るセキュリティー経路を作るためにPAKEプロトコル又は類似の機能を有するプロトコルを使用する。
【0497】
2つのデバイスがオフラインである3番目の場合では、即刻的な引き上げは、Tereonがユーザ又はマーチャントがトランザクションを支援する十分な資金を有するかどうかをリアルタイム確認できないため、Tereonが克服するために設計された信用リスクの露出が生じる。
【0498】
拡張可能なフレームワークの機能及びハッシュチェーンのバージョンを使用することで、Tereonはシステムが資金を続けて確認できるようにする。ユーザとマーチャントの両方は、自分の全ての機能を実行できる。ユーザはモバイル又はマイクロプロセッサー・カードを使用しなければならないが、ユーザやマーチャントは自分が経験するサービスの低下を見ることはない。マーチャントデバイスとユーザデバイスの両方はそれらの間のトランザクションの暗号化された細部情報と、マーチャントが作った前のオフライントランザクションのランダムサンプルを格納する。マーチャントデバイスは、ユーザのカードや電話に伝達される各トランザクションの最大のコピー数を設定する。
【0499】
Tereonはあるユーザがオフラインデバイスとオンラインデバイスを組合せて使用し、アカウント内の存在する以上の金額を引き出さないようにするため、ビジネスロジックとセキュリティーモデル及びハッシュチェーンの結合せを使用する。アカウントが信用機能を提供する場合、アカウントは、オフラインデバイスのみを支援する。オフラインロジックはクレジットを必要としないが、クレジットを提供するための許可は、サービス提供者の規制機関によって要求され得る。
【0500】
デバイスがオフラインで作動するように許可されていない場合、オフラインのときには他のデバイスとトランザクションすることができない。デバイスの署名がオンライントランザクションを支援するものとして識別するため、セキュリティー及び認証モデルはそうすることを防止し、デバイスは、登録されたアカウントの価値にも影響を与える、どのトランザクションも処理できない。
【0501】
デバイスがオフライントランザクションを支援できる場合、サービス提供者は、これをオフライン許容量(off-line allowance)の一定の金額に制限する(デバイスがオンラインであるとき常にアップデートされるクレジットの限度、又はアカウントの残高の一部)。デバイスは、アカウントから合計額又は該当オフライン許容量での資金の振込み又は支払いのみを承認する。もちろん、サービス提供者は、デバイスが振込み又は資金を受容するよう権限を付与することができ、このような受容価値(オフライン受容許容量)を制限し得る。第1デバイスがオフライン間ユーザがアカウントにアクセスすると、ポータルを介して直接又は他のオンラインデバイスへ、ユーザがアカウントの残高からオフライン許容量を差し引いた金額までのみアカウント振込み又は支払いを承認する。
【0502】
Tereonは、関連レコードの含まれたデバイスの1つがオンラインになると、全てのオフライントランザクションを調整する。当然一部のトランザクションのコピーを受け取ることになるが、これを用いて以前の調整を確認することができる。
【0503】
したがって、サーバがオフラインデバイスへの振込み又は支払いに関するオフライントランザクションの第3者サーバ(third-party servers)からレコードを受信すると、それは該当トランザクションのコピーを十分に受信すれば該当トランザクションを処理し、その資金をアカウントの残高に追加する。同様に、サーバがオフラインデバイスからの支払い又は振込みに関するオフライントランザクションの第三者サーバからレコードを受信すると、それは該当トランザクションの十分なコピーを受信すれば該当トランザクションを処理し、アカウントの残高と残りのオフライン許容量からそれらの金額を差し引く。
【0504】
上記の図では支払いに関するものが示され、これらは視角化が容易であるため、同じ動作モードは全てのタイプのトランザクションシステムに適用されてもよい。1つ例として、IoTデバイス又は他の産業コンポーネント間の相互作用である。再配置、挿入、又は、除去可能なモジュールを含むワークフローを生成することによって、運営者などは再プログラム及び再インストールする必要なしに新しい方式で作動するようにデバイスを再構成できる。
【0505】
運営者は、現場でデバイスの用途を変更したり、作動方式を変更したり、デバイスが異なるデバイスを制御して該当デバイスが作動する環境で検出した変更事項によってワークフローを修正したりすることができる。
【0506】
また、IoTデバイスは、必要に応じて、ワークフローを構成するモジュールのアセンブリを修正して互いのワークフローを修正してもよい。ルックアップサービスは、デバイスが互いを識別し認証することを可能にする間に、デバイス間通信を管理するセキュリティーモデルは、その通信を中間者攻撃に対して遮断する。
【0507】
オフラインモードは、このようなデバイスが自律的又は半自動的に作動して互いに相互運用され、該当デバイス間の全てのトランザクションを確認及び検証し、必要に応じて運営者のシステムと相互作用できるようにする。
【0508】
以下説明されたコンテキストセキュリティーモデルは、IOTデバイスのような全てのタイプのデバイスまで拡張される。デバイスが作動することを許可される限り、該当デバイスのサービスが関連ルックアップサービスにリストされている限り、任意のデバイスや他のデバイスと通信し、それぞれはデバイス間トランザクション及びデータ通信を信頼して有効にするためにハッシュチェーンを使用し、それぞれはデバイスのワークフローを修正したりデバイスのシステムをアップグレードしたり、該当システムの間にデータを単に伝達又は対照するための命令を含む。各デバイスは、トランザクションに対する完全な監査を保持する。
【0509】
セキュリティー(Security)
Tereonシステムは、レガシートランザクション処理システムに用いられる現在のセキュリティーモデル及びプロトコルに存在する欠陥及び制限事項を克服する複数の固有セキュリティーモデルを使用する。例えば、セキュリティーモデルは、デバイスにデータを格納する必要性がなくなる。これは既存システムの主なイシューである。
【0510】
USSDのセキュリティー(Securing USSD)
USSD(unstructured supplementary service data)は、フィーチャーフォンとの支払いをはじめとする様々なトランザクションタイプに対する通信チャネルとして一般的に用いられる。TereonはUSSDを安全に使用可能にする。
【0511】
多くの実現では、ユーザがUSSDコードを入力するか、番号の決められたメニューから動作(action)を選択する必要がある。暗号化されていない一連のメッセージは前後に移動する。これは、コスト、セキュリティーの低下、及びユーザ経験不足のイシューを発生させる。
【0512】
セキュリティーの問題が発生する7ビット又は8ビットテキストでメッセージを送信する代わりに、Tereonは、新しい方式でUSSD及び類似の通信チャネルを使用する。Tereonは、単にそれをセッション基盤の短いバースト通信チャネル(session-based short-burst communications channel)と見なす。
【0513】
Tereonは、USSDに合わせてメッセージを調整しない。これは既存のシステムの動作である。代わりに、トランザクションセッション内の各暗号化された通信に対して、Tereonは、サイファーテキストを生成するためにTCP/IP(GPRS、3G、4G、WiFiなど)を通した通信と同様に通信を暗号化し、サイファーテキストを基本64 7ビット文字列に符号化する。その次に、Tereonは、サイファーテキストの長さを確認する。USSDメッセージの許された空間よりも長い場合、サイファーテキストを2つ以上の部分に分割し、USSDを用いてこれらを個別的に送信する。反対側の端では、Tereonは、部分を全体の文字列に再調合し、これをサイファーテキストに変換して解読する。
【0514】
Tereonはこの方法を用いて、当事者を識別して認証するためにまずTLS(transport layersecurity)を使用する。これで第1セッションキーを生成する。その次に、Tereonは、当事者がセッション内の以降の全ての通信を暗号化するために使用する第2セッションキーを生成するPAKEプロトコルネゴシエーションを暗号化するために、このセッションキーを用いてもよい。
【0515】
一部のフィーチャーフォンは、WAP(wireless application protocol)を支援する。このような実現がUSSD上でWAPを使用する場合、TereonはUSSDを介して通信する方法としてWAPプロトコルスタックを使用する。これは、単に追加認証レベルとして機能するWTLS(wireless transport layersecurity)レイヤを提供する(これは、Tereonが基本的に使用するTLS及び高級暗号化標準256(AES256))よりも弱いため、Tereonは全てのイベントに通信を暗号化するためにAES256を使用する)。
【0516】
これはまた、Tereonがセキュリティーが不足している他の通信チャネル(例えば、NFC、ブルートゥースなど)を確保する方法でもある。メッセージングセッションを慎重に構成することにより、USSD及びその他の「セキュアでない」チャネルの性質は完全に変更されることができる。
【0517】
能動デバイス(及びIoT)のセキュリティーモデル(Security model for active devices(and the Internet of Things))
モバイル、カード端末などのような能動デバイスのセキュリティーモデルは、カードに対するセキュリティーモデルと同じ方式で動作する(下記参照)。セキュリティーアルゴリズムがこの前にクラックされたため、SIMは使用されない。代わりに、デバイスに暗号化されて格納される登録キーは、ネットワークが生成する固有のキーと共に用いられる。モバイルデバイスで、Tereonは該当キーを用いて検索し、モバイルによって報告されるIMSI(international mobile subscriber identity)が本物であるかを確認できる。
【0518】
ユーザが最初にアプリケーションを実行すれば(ユーザが所望する場合、複数のアプリケーションを有してもよい)、アプリケーションはTereonサーバがデバイスのモバイル番号又はシリアル番号と共にユーザのアカウントに対して生成する一回だけの性質認証コード(one-time authentication code)を要求する(アプリケーションが該当番号を最初に確認できない場合)。ユーザは、複数のTereonサーバに自分のアプリケーションを登録してもよい。ここで、各サーバは、サーバがユーザに対して作動する各アカウント又はサービスに対して固有な一回だけの性質活性化コード(one-time activation code)を生成する。
【0519】
ユーザが一回だけの活性化コードを入力すると、アプリケーションは、第1PAKEセッションを生成するために該当コードをサーバとの間の共有秘密(sharedsecret)として使用する(必要に応じて、アプリケーションとTereonサーバがTLS又は類似のプロトコルを用いて互いに有効検査した後)。それが第1PAKEセッションを確立すると、Tereonサーバは、暗号化されて署名された登録キーを新しい共有秘密と共にアプリケーションに送信する。サーバとアプリケーションの両方は、一回だけの活性化コード、登録キー、及び共有秘密のハッシュを生成することにより、新しい共有秘密を生成するために一回だけの活性化コード、登録キー、及び共有秘密を使用する。
【0520】
サーバとアプリケーションが通信するたびに、それらは、オンライン通信でそれらの間で通信した以前のメッセージのハッシュで以前の共有秘密をハッシュして共有秘密を生成する。アプリケーションとサーバが互いに通信するたびに、それらは以前の交換のハッシュと交換したトランザクションのコンテンツのハッシュ(トランザクションハッシュ)を生成する。どちらもこのトランザクションハッシュを使用して新しい共有秘密を生成する。
【0521】
ユーザがデバイスを紛失したり、アプリケーションを再び登録したり、デバイスを変更しなければならない場合、Tereonサーバは、新しい一回だけの認証コードと登録キーを生成する。サーバがアプリケーションに伝達する新しい共有秘密は、サーバとアプリケーションの間に交換された以前のメッセージのハッシュから生成される。
【0522】
このキー伝達により、アプリケーションとTereonサーバが各PAKEセッションに対して新しい共有秘密を有することができる。したがって、攻撃者がTLSセッションを切断できる場合(サーバとアプリケーションがメッセージに署名をする時非常に難しい)、攻撃者は、依然としてPAKEセッションキーを切断する必要がある。当事者が特徴的な事項(feat)を管理したのであれば、それは当事者にセッションに対するキーが与えられるのであろう。各通信に対して新しいキーを生成するプロセスは、当事者が各通信に対して特徴的な事項(feat)を繰り返さなければならないことを意味し、これは事実上算出不可能である。
【0523】
アプリケーションは全てのセッションで特定のサービスに対して認証されるため、ユーザのアプリケーションは当該サービスとのみ相互作用する。サーバは、ユーザのアプリケーションが登録された他のサービスについて知らない。事実上、アプリケーションは、ユーザが登録されることができる複数のサービスとは関係なく、「サイキックペーパー」と類似なもの、サービスに要求されるクレデンシャルのみを提供する識別デバイスとなる。それは、あるサービスへの支払いデバイス、他のサービスへの移送チケット、他のサービスへのドアキーなどのように見える。サービス提供者は、サービスにアクセスするために別途のデバイスを発行する必要がないことから、サービス提供及び当該サービスアップグレードの複雑性とコストを節減できる。
【0524】
セキュリティーモデルは、追加の利点を有する。ユーザが自分のデバイスを失う場合、ユーザはまったく同じ番号の新しいデバイスを取得し得る。アプリケーションがある古いデバイスは作動しないが、新しいデバイスが一度登録されれば有効な秘密キーと登録コードを有するので作動できる。紛失のデバイスを報告するまでには時間がかかるが、必要なパスワードとPIN又は他の認証トークンを有しないために、誰もトランザクションを行うことができない。
【0525】
ユーザがアプリケーションにアクセスする前に、ユーザ又はTereonシステム管理者は、暗号を要求するようにアプリケーションを構成してもよい。このパスワードは、Tereonサーバと共に点検される。有効な場合、Tereonサーバはアプリケーションに(常に署名され暗号化された通信で)作動するよう指示する。パスワードが無効な場合、Tereonサーバは、アプリケーションに制限された回数の試みで(limited number of attempts)新しいパスワードを要求するように指示する。その後、Tereonサーバはユーザのアプリケーションをかけて(lock out)、ユーザは、アプリケーションのロックを解除し、デバイスを再登録するために、管理者とコンタクトする必要がある。
【0526】
各クリデンシャルは時間が計られている。すなわち、あるユーザが定義された期間中に特定のクリデンシャルが割り当てられ、その期間中に該当クリデンシャルで発生する全てのトランザクションはそのユーザにリンクされることを意味する。そのユーザがクリデンシャルを変更すると、元のクリデンシャルは他のユーザに割り当てられる。しかし、ルックアップサーバは、クリデンシャルとそのクリデンシャルに登録された期間の組合せに基づいて、トランザクションとクリデンシャルをリンクし続ける。
【0527】
同じモデルを「IoT」内のデバイス間の通信を保護するために採択することができる。ここで、認証書又はハードウェアに内蔵されたシリアル番号を用いて各デバイスを識別することができる。これは、トランザクション日付又はデバイス間で送信された以前のメッセージとハッシュされるとき、それは各デバイスが最初のコンタクトでスワップ(swap)する第1共有秘密になる。2つの番号は、デバイスを識別できる公開シリアル番号、PKI(public key infrastructure)認証書の代わりに機能する役割、及び共有秘密として作用する暗号で保護されたシリアル番号に使用されてもよい。あるいは、単一シリアル番号をIDと第1共有秘密として使用し、新しい秘密キーをセキュリティー通信チャネルを介してアップロードしてもよい(システムアーキテクチャーの通信レイヤに対する説明を参照)。
【0528】
Tereonのモバイルセキュリティーモデルは、他の利点を有する。運営者は個々のサービスに対するアクセス権限を設定し、特定の使用がそのサービスを成功させようと試みるデバイス及びネットワークによりアクセスレベルを構成するためにこれを使用する。例えば、提供者は、管理者がモバイルデバイスでなく固定されたデバイスを介してセキュリティー共用ネットワークを介してシステムログを見て、インターネットネットワークを介してシステム管理機能にのみアクセスできるように指定してもよい。
【0529】
この機能は、支払いに一部のアプリケーションを有するが(定義されたネットワーク及びデバイスのシステム管理機能に対するアクセスを保障)、機密性の高いコンテンツ又は権限のあるコンテンツに対する制限されたアクセスが必要な他のサービスに対して提供されるため、ユーザは、特定データ、これを見ることができる人、このような第三者が閲覧できるデータ、及び閲覧できる場所を正確に制御できる。
【0530】
セキュリティーモデルにより、組織はあらゆるデバイスによって収集、生成、又は送信される全てのデータの個人情報及びセキュリティーを保証できる。これは、全てのデバイスやトランザクション、支払いから医療デバイス、交通センサ、気象センサ、水流検出器などに適用される。
【0531】
カードセキュリティーモデル(Cardsecurity model)
ホストカードエミュレーションを使用するEMVカード及びモバイルは、チップ又はモバイルのセキュリティー要素にPINを格納する。非接触式カード及びこのカードをエミュレートするモバイルも、カードの詳細の大部分を明確かつ容易に読みやすい形式で格納する。カード端末は、ユーザが入力したPINをカードに格納されているPINと照合する。これはEMVシステムの多くの弱点が明らかになるようにし、EMVプロセスを十分に立証された攻撃にたいしてオープンさせる。
【0532】
Tereonは、認証キーだけをカードに格納し、Tereonサービスに格納された値(値が実際の値と一致しないことのみを確認する管理者に対して閉鎖されているデータベースのセキュリティー領域)と入力された値を確認する。それは、サービスと特定の機能、リソース、施設、又は、トランザクションタイプ、又は、当該サービスによって提供される他のタイプのサービスを認証する。Tereonは、2種類のセキュリティーモデルを使用し、その1つは他のモデルの下位集合(subset)である。
【0533】
多くのカードは、PAN(長い番号)を表示する。Tereonは、アカウントを識別するためにこの番号を使用しない。むしろ、モバイル番号のような方式でPANを使用する。これは単にアクセスクリデンシャルである。各カードは。暗号化されたPANを有する。カードは。モバイルに登録キーが該当デバイスを認証するのと同じ方式で、カードの登録された各サービスに対して有効であることを識別する暗号化された登録キーを有する。Tereonサービスに登録された暗号化されたPAN文字列に関するアドレスの詳細がまだ有していない場合、暗号化されたコードは、マーチャントのTereonサービスが要求する必要があるカントリールックアップディレクトリサービス(country look-up directory service)を示すプレフィクス(prefix)を有する。
【0534】
ユーザがカードを端末に提示するとき、端末は暗号化されたPANを読み出し、暗号化された登録キーを使用してカードの登録された端末でカードの有効性を検査する。ユーザのTereonサービスがカードとマーチャントのTereonサービスを全て確認及び認証すれば、ユーザサービスは、マーチャントのTereonサービスにPANを暗号化されない形式で送信し、ここで、それは暗号化された形式でこれをキャッシュに登録してもよい。したがって、ユーザが後ほどEコマースポータル又はマーチャントの端末を介してPANを暗号化無しで(in the clear)入力すると、サービスは、連絡する他のサービスを知るようになる。
【0535】
カード読み出し機器が何らかの理由でもカードを読み出すことができなければ、ユーザ又はマーチャントはPANを入力してマーチャントのTereonサービスはユーザのTereonサービスのアドレスを取得するためにこのPANを使用する。カードのPANは、ユーザが使用できる多くのクリデンシャルの1つだけである。
【0536】
マーチャントのTereonサービスがカードを認証すると、マーチャントの端末は、ハッシュされたキーを用いてTLSを設定し、次にハッシュされたキーを用いてPAKEセッションをTereonサービスとして設定する(端末がそのサービスと通信するごとに以前のキーを登録キーとしてハッシュしてPAKEセッションに対する新しい共有秘密を生成する)。マーチャントの端末がPINを要求するまで、マーチャントプロセスは続く(支払いサービス提供者によって決定され、Tereonサービスのビジネス規則エンジンに明示されたように、ユーザが該当トランザクションにPINを必要とする場合)。ユーザのTereonサービスは、マーチャントのサービスとPAKEセッションを生成し、次に一回だけのキーをマーチャントのサービスに送信し、TLSを最初に使用して生成された他のPAKEセッションを介して暗号化されたメッセージを端末に送信する。
【0537】
マーチャント端末はキーを受信し、ユーザによって選択されたテキスト(端末がマーチャントのサービスによって許可されることを示す)を表示するためにメッセージを解読する。ユーザは、端末のPAKEセッションを介してユーザのサービスと通信される自分のPINを入力する。このプロセスは、ユーザが自分のPINをマーチャント端末に入力しなければならない場合にのみ発生する。これは、セキュリティーアプリ(マーチャントの端末がユーザのTereonサービスからアクセスし、ユーザのサービスが安定の署名されたキー交換で端末に送信する第2のワンタイムキー(second one-time key)に暗号化される)に入力されるため、マーチャントの端末は、PINを明確に見ることができない。全ての通信は一般的にマーチャントのサービスによって行われ、端末とユーザTereonサービス間の直接通信は端末がその機能を支援できる場所で設立される。
【0538】
カードがマイクロ-プロセッサカード(Chip&PIN、非接触式、又は2種類両方)の場合、カードは発行時に最初生成された共有秘密を有してもよい。
マイクロ-プロセッサカードは、登録されたTereonサービス(又はサービス用サービス)とセッションを確立するためにPAKEを使用する。このセッションは、Tereonサービスのあるカード端末(モバイルタブレット又はPoSカード端末であり得る)によって確立されたセッションと共に行われる。これは既存の端末及びChip&PINカードが示す主な脆弱性(複数の「中間者」又は「ウェッジ(wedge)」攻撃を介してPIN検証プロセスを妨害して破壊する既存のインフラストラクチャーの脆弱性)を即座に除去する。
【0539】
カードは、サービスに送信するキー(サービスがPINを暗号化するためにマーチャント端末に送信)を生成するためにこのチャネルを使用する。カードが最後のオンライントランザクションの残高、オフライントランザクションに対して使用する一連のキーを生成するためのシードとして使用するキー、及び第三者オフライントランザクションのレコードを格納するとき、それはオフライントランザクションを容易にするためにこのチャネルを使用する。
【0540】
カードの紛失又は盗難された場合、Tereonのセキュリティーモデルは、発行者が新しいPANを発行する必要がないことを意味する。
コンテキスト基盤のセキュリティー(Context basedsecurity)
多くのセキュリティープロトコルは、いくつかのクリデンシャルを使用し、基本的な前提を基盤とする。この仮定が、エラー及びセキュリティの低下を招く可能性がある。Tereonシステムは、このシステムがないと通信ネットワークが安全ではなく信頼できないという仮定、及びデバイスが動作する環境も安全でないという仮定以外の根本的な仮定には依存しない。
【0541】
Tereonシステムは様々な段階を経て、クリデンシャルセットとこのクリデンシャルが提示されるコンテキストを全て調べる。これは追加的なセキュリティーを提供し、組織が従業員又は構成員が一部又は全ての状況で自分のデバイス(BYODともいう)を使用可能にする手段1つを確保する。
【0542】
Tereonは、ユーザのパスワード、PIN、又は、その他の直接認証クリデンシャルだけではなく、デバイスの詳細、該当デバイスのアプリケーション、該当デバイスがTereonにアクセスするネットワーク、セッション時間にこのデバイスの地理的な位置、及びユーザがこのデバイスにアクセスしているサービス又は情報を使用する。
【0543】
Tereonはクリデンシャルを受け取り、該当クリデンシャルと設定されたコンテキストに基づいて、クリデンシャルに適切なアクセスレベルを付与する情報のアクセスを制御する。
【0544】
例えば、Tereonにより承認されない個人デバイスの深層管理サービスにアクセスしようとする管理者は、この管理者が職場と会社のネットワークにあるかどうかに関わらず、当該サービスから遮断される。しかし、同じ管理者は同じデバイスのシステムログの一部を見る権限がある。
【0545】
第2の例は、コンテキストセキュリティーモデルがセカンダリーユーザが見ることのできるサービスを管理する場合である。ユーザは設定限度(信用限度又は使用可能な最大金額まで)なしに入金、引き出し、及び支払いのような様々な機能を提供するモバイル又はカードを保有している。そのユーザは、何回もカフェを訪問し、いつもコーヒーとアーモンドクロワッサンを購入した。現在、ユーザは自分のカードを息子に渡し、合計40ポンドをそのカードの上限として設定した。ユーザは、コーヒーを買うために同じカフェにカードを持っていく息子の使用のために第2PINを設定した。彼は過去6個をすでに購入したため、Tereonシステムは、一般的に無料アーモンドクロワッサンをユーザに提供し、カフェはその提案を顧客に伝達するためにTereonを使用する。しかし、ユーザの息子がPINを入力するとき、Tereonシステムは支払っているのがユーザの息子であること(自分の父のPINを知らない)を検出し、彼がピーナッツアレルギーがあるため、その父が息子のPINを息子のプロファイルと接続したことから、今日の提案は遮断される。マーチャントは、無料クロワッサン提供に対する通知を見ることができず、Tereonはユーザの息子がナッツ類を食べることができないことを知っている。マーチャントが見ることができるのはコーヒーの支払いである。
【0546】
ユーザは、その息子が10ポンドまで現金を引き出すことを許容したが、資金を入金することを許容していない。したがって、ユーザの息子は最大10ポンドの引き出しを提供できるマーチャントに入ると、彼はマーチャントのオプションを見ることができる。
【0547】
コンテキスト基盤のセキュリティーは、アクセス制御よりも優れている。ユーザがデバイスを提示したり使用するコンテキストに応じて、該当デバイスは、該当コンテキストに必要なクリデンシャルのみを提供する。それが「サイキックペーパー」となる。このような方式で、ディレクトリサービス216は、コンテキスト基盤のセキュリティーを支援できる機能を提供する。
【0548】
コンテキスト基盤のセキュリティーでは、特定のコンテキストに対する別のクリデンシャル及びデバイスが不要になる。これで、単一のデバイスが図書館の図書館カードクリデンシャル、バスや汽車の交通チケット、部屋や施設にアクセスするためのセキュリティーキー、会社の食堂の社内支払いデバイス、劇場のチケット、スーパーマーケット内の標準支払いデバイス、運転免許証、NHSカード、サービスへの資格を証明するIDカード(サービスが必要であればマーチャントのデバイスに写真付きのIDを提示できる)などである。
【0549】
Tereonは、動的でリアルタイムトランザクション処理及び支払いを提供するために、管理者又はユーザは許可されたコンテキストやクリデンシャルをリアルタイムで修正、追加、又は取り消すことができる。修正は、サービスを提供するTereonサーバ、又は、ルックアップディレクトリサービス216、又は両方に直ちに反映される。現在のシステムがデバイスを不活性化するまで、紛失したデバイスはこれ以上金銭的又はIDの露出期限といったリスクをもたらす必要がない。ユーザ又は、管理者がクリデンシャル又はコンテキストを取り消し又は修正すると、変更事項はすぐに活性化される。
【0550】
ワンタッチトランザクション(One touch transaction)
Tereonは、既存システムのセキュリティーの欠陥を除去するワンボタントランザクション権限付与及びアクセス方法(one-button transaction authorisation and access method)を実現する。例えば、現在のPINなし、又はNPCの支払いは、支払いに対する認証を提供しないことから極めて危険である。カード発行者が非接触式EMVシステムでモバイル又はカードクリデンシャルを取り消すまで、ユーザは全ての支払いに対して責任を負う。デバイスが発行者によって取り消されても、消費者は依然として支払いを活性化していないことを証明しなければならない。支払いが認証のためにPINを必要としない場合、どのようにすればよいか。これは誰かが非接触式カードやモバイルを手に取り、単にタップして支払うことを可能にする大きな穴を残す。デバイスが取り消すまで、デバイスは続けて有効である。
【0551】
Tereonは、3つのモードのうち1つでタップアンドゴー(tap-and-go)を支援し、それぞれのモードは運営のためにコンテキストにより異なる。これらの1つは、個人を識別するアクセス方式を使用するワンタッチトランザクションを提供する。ユーザとサービス提供者が提供される認証レベルが満足である点に同意すると、システムはワンタッチ認証方法を提供し、デバイスが大きいボタンを表示したりユーザがタッチできるように画面に広い領域を構成する。他のモードは、ユーザがクリデンシャルを入力しない従来の非接触式トランザクションとデバイスが互いに識別した後、ユーザが標準支払いクリデンシャルを入力することのような完全に非接触式モードである。
【0552】
ボタン又は領域そのものは、タッチスクリーンを介して認証を提供する。全ての個人は、各自が押す場所と使用する圧力パターンの観点から、全て独特の方式で画面を押す。個人がこの機能を使用しようとする場合、Tereonは、該当の個人に各自の署名が押された(signature press)ことを知るまで、ボタン又は領域を何度も押すように要求する。画面は、論理的には数個の個別セルに分割され、Tereonはトレーニング期間中にユーザがタッチしたセルの近接とパターンを見て、可能であれば、ユーザが押すときに発生する圧力パターンとデバイスの動きを確認する。ユーザ認証のために使用されるプロファイルを作成するために該当データを用いてモニターする。
【0553】
図21は、上述した任意の1つ以上の方法を実行させるための命令セットが実行できるコンピューティングデバイス2100の一実施のブロック図を示す。代案的な実現形態で、コンピューティングデバイスは、近距離通信網(LAN)、イントラネット、エクストラネット又は、インターネット内の他の機械に接続(例えば、ネットワーク化される)される。コンピューティングデバイスは、クライアントサーバネットワーク環境でサーバ又はクライアント機械の容量で動作したり、ピアツーピア(又は、分散)ネットワーク環境でピアマシン(peer machine)として動作してもよい。コンピューティングデバイスは、PC、タブレットコンピュータ、セットトップボックス(STB)、PDA(Personal Digital Assistant)、セルラー電話(cellular telephone)、ウェブ機器、サーバ、ネットワークルータ、スイッチ又はブリッジ、プロセッサ、又は機械によって取られる動作を指定する一連の命令(順次的又は他の方法)を実行できる任意の機械であり得る。また、1つのコンピューティングデバイスが図示されているが、「コンピューティングデバイス」という用語は、説明された方法のうち任意の1つを行うための命令セット(又は、複数のセット)を個別的又は共通に実行する任意の機械の集合(例えば、コンピュータ)を含むように使用されなければならない。
【0554】
例示的なコンピューティングデバイス2100は、バス2130を介して通信する処理デバイス2102、メインメモリ2104(例えば、ROM(read-only memory)、フラッシュメモリ、SDRAM(synchronous DRAM)又はRDRAM(Rambus DRAM)のようなDRAM)、静的メモリ2106(例えば、フラッシュメモリ、SRAM(static random access memory))、及びセカンダリーメモリ(例えば、データ格納デバイス)2118を含む。
【0555】
処理デバイス2102は、マイクロ・プロセッサ、中央処理デバイスなどのような1つ以上の汎用プロセッサを示す。特に、処理デバイス2102は、CISC(complex instruction set computing)マイクロプロセッサー、RISC(reduced instruction set computing)マイクロプロセッサー、VLIW(very long instruction word)マイクロプロセッサー、他の命令のセットを実現するプロセッサ、又は、命令のセットの組合せを実現するプロセッサであり得る。また、処理デバイス2102は、ASIC(application specific integrated circuit)、FPGA(field programmable gate array)、DSP(digital signal processor)、ネットワークプロセッサなどのような1つ以上の特殊目的の処理デバイスであり得る。処理デバイス2102は、本明細書で説明された動作及びステップを行うための処理ロジック(命令2122)を実行するように構成される。
【0556】
コンピューティングデバイス2100は、ネットワークインタフェースデバイス2108をさらに含んでもよい。また、コンピューティングデバイス2100は、ビデオディスプレイユニット2110(例えば、LCD(liquid crystal display)、CRT(cathode ray tube))、英数字入力デバイス2112(例えば、キーボード又はタッチスクリーン)、カーソル制御デバイス2114(例えば、マウス又はタッチスクリーン)、及びオーディオデバイス2116(例えば、スピーカ)を含んでもよい。
【0557】
データ格納デバイス2118は、上述した任意の1つ以上の方法又は機能を実現する1つ以上の命令のセット2122が格納された1つ以上の機械)可読格納媒体2128、又は、さらに具体的には、1つ以上の非一時的にコンピュータ可読格納媒体)を含んでもよい。コンピュータシステム2100、メインメモリ2104、及びコンピュータで可読格納媒体を構成する処理デバイス2102によって実行される間に、命令2122は、メインメモリ2104及び/又は処理デバイス2102内に完全又は少なくとも部分的に存在し得る。
【0558】
上述した様々方法は、コンピュータプログラムによって実現され得る。コンピュータプログラムは、上述した1つ以上の様々な方法の機能を行うために指示するように構成されたコンピュータコードを含んでもよい。そのような方法を行うためのコンピュータプログラム及び/又はコードはコンピュータのようなデバイス、1つ以上のコンピュータで可読記録媒体、又は、より一般的には、コンピュータプログラム製品上に提供されてもよい。コンピュータで可読記録媒体は、一時的又は非一時的であり得る。例えば、1つ以上のコンピュータで可読記録媒体は、電子、磁気、光学、電磁気、赤外線、又は半導体システム、又は、データ送信(例えば、インターネットを介してコードをダウンロード)のための電波媒体であり得る。代案的に、1つ以上のコンピュータで可読記録媒体は、半導体又は固体状態メモリ、磁気テープ、着脱式コンピュータディスケット、RAM(random
access memory)、ROM(read-only memory)、剛性磁気ディスク、及び光学ディスク-CD-ROM、CD-R/W、又はDVDと同様な1つ以上の物理的コンピュータで可読記録媒体の形態を有する。
【0559】
一実施形態で、ここで説明されたモジュール、コンポーネント及びその他の特徴は、個別コンポーネントとして具現されたり、個別化サーバの一部としてASICS、FPGA、DSP又は類似のデバイスのようなハードウェアコンポーネントの機能に統合され得る。
【0560】
「ハードウェアコンポーネント」は、特定の動作を行うことのできるタイプの(例えば、一時的でない(non-transitory))物理的なコンポーネント(例えば、1つ以上のプロセッサセット)であり、特定の物理的方式で構成されたり配列されてもよい。ハードウェアコンポーネントは、特定の動作を行うよう永久的に構成された専用回路又はロジックを含んでもよい。ハードウェアコンポーネントは、FPGA(field programmable gate array)又はASICのような特殊目的のプロセッサを含んでもい。また、ハードウェアコンポーネントは、特定の動作を行うためにソフトウェアによって一時的に構成されるプログラミング可能なロジック又は回路を含んでもよい。
【0561】
したがって、「ハードウェアコンポーネント」という文句は物理的に構成されたり、永久的に構成されたり(例えば、ハードウェアに内蔵された)、又は、特定の方式で動作したり記述された特定の動作を行うように一時的に構成(例えば、プログラミング)されるタイプのエンティティ(entity)を含むものとして理解されなければならない。
【0562】
機械(machine)は、例えば、物理的機械、論理的機械、仮想機械、コンテナ、又は実行可能なコードを含むために一般的に用いられるメカニズムであり得る。機械は単一機械であってもよく、又は、機械が同じタイプであるか、又は複数のタイプであるかに関わらず、複数接続された又は分散された機械を示す。
【0563】
モジュール及びコンポーネントは、ハードウェアデバイス内のファームウェア又は機能回路で実現されてもよい。また、モジュール及びコンポーネントは、ハードウェアデバイス及びソフトウェアコンポーネントの任意の組合せ又はソフトウェア(例えば、機械可読媒体又は送信媒体に格納又は具現されたコード)でのみ実現される。
【0564】
特に説明しない限り、次の説明から明らかなように、「送信(sending)」、「受信(receiving)」、「決定(determining)」、「比較(comparing)」、「可能(enabling)」、「保持(maintaining)」、「識別(identifying)などのような用語は、コンピュータシステム又は類似の電子コンピューティングデバイス(コンピュータシステムのレジスタ及びメモリ内の物理的(電子的)量で表現されたデータをコンピュータシステムメモリ又はレジスタ又は他の情報ストレージ内の物理量と同様に表現される他のデータに操作及び変換)送信又はディスプレイデバイスの動作及びプロセスを指し示す。
【0565】
上述した説明は、例示的であり、制限的ではないことを理解しなければならない。上述した説明を読んで理解すれば、多くの異なる実現例が当業者にとって明白になるのであろう。本発明は、特定の例示的な実現例を参照して説明されたが、説明される実施形態に限定されず、添付の請求範囲の思想及び範囲内で変形及び変更して実施できることは理解できるのであろう。したがって、明細書及び図面は制限的な意味であるよりも例示的な意味として見なす。したがって、請求範囲が属する均等物の全体範囲と共に、添付された請求範囲を参照して本発明の範囲が決定されなければならない。
【0566】
様々な側面の全ての選択的特徴は、他の全ての側面に関する。記述された実施形態の変形例が考慮され、例えば、開示された全ての実施形態の特徴が任意の方式により組み合わせられてもよい。
図1
図2
図2a
図3
図4
図4a
図5
図6
図6a
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図17a
図18
図19
図20
図21
【手続補正書】
【提出日】2024-08-15
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
第1エンティティに関連するデータトランザクションを処理するかまたは前記第1エンティティに含まれるデバイスにより実行されるデータトランザクションレコーディング方法において、
第1シードデータを決定するステップと、
前記第1エンティティと第2エンティティとの間の第1データトランザクションのレコードを生成するステップと、
少なくとも前記第1シードデータ及び前記第1データトランザクションのレコードを結合して第2シードデータを決定するステップと、
前記第2シードデータをハッシュして第1ハッシュを生成するステップであって、前記第1ハッシュは、前記デバイスにより実行されるデータトランザクションのヒストリーを含み、前記第1データトランザクションと、前記第1データトランザクションの前記レコードの生成と、前記第1ハッシュの生成とは、同じトランザクションプロセス内で実行される、前記第1ハッシュを生成するステップと、
前記第1データトランザクションの前記レコードに対する前記第1ハッシュをメモリに格納するステップと、
を含むデータトランザクションレコーディング方法。
【請求項2】
前記第1シードデータは開始ハッシュを含む、請求項1に記載のデータトランザクションレコーディング方法。
【請求項3】
前記開始ハッシュは、前記第1エンティティに関連する以前のデータトランザクションのレコードをハッシュした結果である、請求項2に記載のデータトランザクションレコーディング方法。
【請求項4】
前記開始ハッシュはランダムハッシュを含む、請求項2に記載のデータトランザクションレコーディング方法。
【請求項5】
前記ランダムハッシュは、前記デバイスからの署名、前記ランダムハッシュが生成された日付、及び前記ランダムハッシュが生成された時間のうちの少なくとも1つを含む、請求項4に記載のデータトランザクションレコーディング方法。
【請求項6】
第2シードデータを決定するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと第1ゼロ知識証明及び第2ゼロ知識証明を結合するステップをさらに含み、
前記第1ゼロ知識証明は、前記開始ハッシュが前記第1エンティティに関連する前記以前のデータトランザクションの真のハッシュを含むという証明を含み、
前記第2ゼロ知識証明は、第2ハッシュが前記第2エンティティに関連する以前のデータトランザクションの前記真のハッシュを含むという証明を含む、請求項1乃至請求項5のいずれか一項に記載のデータトランザクションレコーディング方法。
【請求項7】
第2シードデータを決定するステップは、前記第1シードデータ、前記第1データトランザクションの前記レコード、前記第1ゼロ知識証明及び前記第2ゼロ知識証明と第3ゼロ知識証明を結合するステップをさらに含む、請求項6に記載のデータトランザクションレコーディング方法。
【請求項8】
前記第3ゼロ知識証明は、ランダムデータから生成される、請求項7に記載のデータトランザクションレコーディング方法。
【請求項9】
前記第3ゼロ知識証明は、前記第1ゼロ知識証明又は前記第2ゼロ知識証明の繰り返しである、請求項7に記載のデータトランザクションレコーディング方法。
【請求項10】
前記第3ゼロ知識証明は、前記第2ゼロ知識証明に対応する前記第1データトランザクションの第2レコードを用いて構成される、請求項7に記載のデータトランザクションレコーディング方法。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0566
【補正方法】変更
【補正の内容】
【0566】
様々な側面の全ての選択的特徴は、他の全ての側面に関する。記述された実施形態の変形例が考慮され、例えば、開示された全ての実施形態の特徴が任意の方式により組み合わせられてもよい。
以下に、上記実施形態から把握できる技術思想を付記として記載する。
[付記1]
第1エンティティに関連するデバイスでデータトランザクションレコーディング方法において、
第1シードデータを決定するステップと、
前記第1エンティティと第2エンティティとの間の第1データトランザクションのレコードを生成するステップと、
少なくとも前記第1シードデータ及び前記第1データトランザクションのレコードを結合して第2シードデータを決定するステップと、
前記第2シードデータをハッシュして第1ハッシュを生成するステップであって、前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む、前記第1ハッシュを生成するステップと、
前記第1データトランザクションの前記レコードに対する前記第1ハッシュをメモリに格納するステップと、
を含むデータトランザクションレコーディング方法。
[付記2]
前記第1シードデータは開始ハッシュを含む、付記1に記載のデータトランザクションレコーディング方法。
[付記3]
前記開始ハッシュは、前記第1エンティティに関連する以前のデータトランザクションのレコードをハッシュした結果である、付記2に記載のデータトランザクションレコーディング方法。
[付記4]
前記開始ハッシュはランダムハッシュを含む、付記2に記載のデータトランザクションレコーディング方法。
[付記5]
前記ランダムハッシュは、前記デバイスからの署名、前記ランダムハッシュが生成された日付、及び前記ランダムハッシュが生成された時間のうちの少なくとも1つを含む、付記4に記載のデータトランザクションレコーディング方法。
[付記6]
第2シードデータを提供するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと第1ゼロ知識証明及び第2ゼロ知識証明を結合するステップをさらに含み、
前記第1ゼロ知識証明は、前記開始ハッシュが前記第1エンティティに関連する前記以前のデータトランザクションの真のハッシュを含むという証明を含み、
前記第2ゼロ知識証明は、第2ハッシュが前記第2エンティティに関連する以前のデータトランザクションの前記真のハッシュを含むという証明を含む、付記1乃至付記5のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記7]
第2シードデータを提供するステップは、前記第1シードデータ、前記第1データトランザクションの前記レコード、前記第1ゼロ知識証明及び前記第2ゼロ知識証明と第3ゼロ知識証明を結合するステップをさらに含む、付記6に記載のデータトランザクションレコーディング方法。
[付記8]
前記第3ゼロ知識証明は、ランダムデータから生成される、付記7に記載のデータトランザクションレコーディング方法。
[付記9]
前記第3ゼロ知識証明は、前記第1ゼロ知識証明又は前記第2ゼロ知識証明の繰り返しである、付記7に記載のデータトランザクションレコーディング方法。
[付記10]
前記第3ゼロ知識証明は、前記第2ゼロ知識証明に対応する前記第1データトランザクションの第2レコードを用いて構成される、付記7に記載のデータトランザクションレコーディング方法。
[付記11]
前記第1データトランザクションは少なくとも2つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第1ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
前記第1データトランザクションの前記第2ステージのレコードと前記第2ゼロ知識証明を結合するステップと、
を含む、付記6に記載のデータトランザクションレコーディング方法。
[付記12]
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第2ステージのレコードから第3ゼロ知識証明を構成するステップと、
前記第1データトランザクションの前記第2ステージのレコードと前記第2ゼロ知識証明及び前記第3ゼロ知識証明を結合するステップと、
を含む、付記11に記載のデータトランザクションレコーディング方法。
[付記13]
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
前記第1データトランザクションの前記第3ステージのレコードと前記第3ゼロ知識証明を結合するステップと、
をさらに含む、付記11に記載のデータトランザクションレコーディング方法。
[付記14]
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
ランダムデータと前記第3ゼロ知識証明を結合するステップと、
をさらに含む、付記11に記載のデータトランザクションレコーディング方法。
[付記15]
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、
前記第1データトランザクションの前記第3ステージのレコードと前記第1ゼロ知識証明を結合するステップと、
前記第1データトランザクションの第4ステージのレコードと前記第2ゼロ知識証明を結合するステップと、
を含み、
前記第1データトランザクションの前記第4ステージは、前記第1データトランザクションの前記第3ステージの繰り返しである、付記11に記載のデータトランザクションレコーディング方法。
[付記16]
前記第1データトランザクションは少なくとも3つのステージを含み、
第2シードデータを提供するステップは、前記第1データトランザクションの前記第3ステージのレコードと第3ゼロ知識証明を結合するステップをさらに含む、付記11に記載のデータトランザクションレコーディング方法。
[付記17]
前記第1ゼロ知識証明は、前記第1エンティティに関連する前記デバイスによって構成され、
前記第2ゼロ知識証明は、前記第2エンティティに関連するデバイスによって構成される、付記6乃至付記16のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記18]
前記第1ゼロ知識証明及び前記第2ゼロ知識証明を構成するステップは、キー交換アルゴリズムを使用するステップを含む、付記17に記載のデータトランザクションレコーディング方法。
[付記19]
前記キー交換アルゴリズムは、PAKEアルゴリズムを含む、付記18に記載のデータトランザクションレコーディング方法。
[付記20]
前記第2エンティティに関連するデバイスに前記第1ハッシュを送信するステップと、
前記第2エンティティに関連するデバイスから第2ハッシュを受信するステップであって、前記第2ハッシュは、前記第2エンティティに関連する以前のデータトランザクションのハッシュを含む、前記第2ハッシュを受信するステップと、
前記第1パーティー及び前記第2パーティー間の第2データトランザクションのレコードを生成するステップと、
前記第1ハッシュ及び前記第2ハッシュと前記第2データトランザクションの前記レコードを結合して第3シードデータを決定するステップと、
前記第3シードデータをハッシュし、第3ハッシュを生成するステップであって、前記第3ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリー及び前記第2エンティティに関連するデータトランザクションのヒストリーを含む、前記第3ハッシュを生成するステップと、
前記第2データトランザクションの前記レコードに対する前記第3ハッシュを前記メモリに格納するステップと、
をさらに含む、付記1乃至付記19のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記21]
第3シードデータを提供するステップは、
前記第2データトランザクションの前記レコード、前記第1ハッシュ及び前記第2ハッシュと、第3ゼロ知識証明及び第4ゼロ知識証明とを結合するステップをさらに含み、
前記第3ゼロ知識証明は、前記第1ハッシュが前記第1データトランザクションの真のハッシュを含むという証明を含み、
前記第4ゼロ知識証明は、前記第2ハッシュが前記第2エンティティに関連する前記以前のデータトランザクションの前記真のハッシュを含むという証明を含む、付記20に記載のデータトランザクションレコーディング方法。
[付記22]
前記第2エンティティに関連する前記以前のデータトランザクションは、前記第1データトランザクションである、付記20又は付記21に記載のデータトランザクションレコーディング方法。
[付記23]
前記第1エンティティ及び前記第2エンティティの少なくとも一方の識別子と前記ハッシュのそれぞれを関連づけるステップをさらに含む、付記1乃至付記22のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記24]
前記第1ハッシュを再算出するステップと、
マッチング(match)を決定するために前記生成された第1ハッシュを前記再算出された第2ハッシュと比較するステップと、
をさらに含む、付記1乃至付記23のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記25]
前記比較が不成功である場合、追加データトランザクションを取り消すステップをさらに含む、付記24に記載のデータトランザクションレコーディング方法。
[付記26]
前記第1データトランザクションに対応するシステムハッシュをシステムデバイスに生成するステップをさらに含む、付記1乃至付記25のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記27]
第2シードデータを提供するステップは、前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記システムハッシュを結合するステップをさらに含む、付記26に記載のデータトランザクションレコーディング方法。
[付記28]
前記システムハッシュは、前記システムデバイス上の以前のデータトランザクションのレコードをハッシュした結果である、付記26又は付記27に記載のデータトランザクションレコーディング方法。
[付記29]
第2シードデータを提供するステップは、
ライセンスデバイスからライセンスハッシュを受信するステップと、
前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記ライセンスハッシュを結合するステップと、
をさらに含む、付記1乃至付記28のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記30]
前記ライセンスデバイスにおいて、
前記第1ハッシュを受信するステップと、
ライセンス入力を提供するために前記ライセンスハッシュと前記第1ハッシュを結合するステップと、
前記ライセンス入力をハッシュして第2ライセンスハッシュを生成するステップと、
をさらに含む、付記29に記載のデータトランザクションレコーディング方法。
[付記31]
第2シードデータを提供するステップは、
ディレクトリデバイスからディレクトリハッシュを受信するステップと、
前記第2シードデータを提供するために、前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記ディレクトリハッシュを結合するステップと、
をさらに含む、付記1乃至付記30のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記32]
前記ディレクトリサーバにおいて、
前記第1ハッシュを受信するステップと、
ディレクトリ入力を提供するために前記ディレクトリハッシュと前記第1ハッシュを結合するステップと、
前記ディレクトリ入力をハッシュして第2ディレクトリハッシュを生成するステップと、
をさらに含む、付記31に記載のデータトランザクションレコーディング方法。
[付記33]
第2シードデータを提供するステップは、
前記第1データトランザクションに対する暗号化キーからキーハッシュを生成するステップと、
前記第2シードデータを提供するために前記第1シードデータ及び前記第1データトランザクションの前記レコードと前記キーハッシュを結合するステップと、
をさらに含む、付記1乃至付記32のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記34]
前記暗号化キーは、公開キー又は個人キーを含む、付記33に記載のデータトランザクションレコーディング方法。
[付記35]
前記第1シードデータ及び前記第1データトランザクションの前記レコードを結合するステップは、前記第1データトランザクションが完了するとすぐに実行される、付記1乃至付記34のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記36]
前記メモリは遠隔デバイスに位置する、付記1乃至付記35のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記37]
他のデバイスから受信されたハッシュに対応する前記第1ハッシュを前記遠隔デバイスで比較するステップをさらに含む、付記36に記載のデータトランザクションレコーディング方法。
[付記38]
前記デバイスに接続された他のデバイスに前記第1ハッシュを受信することを予想するよう通知するステップをさらに含む、付記36又は付記37に記載のデータトランザクションレコーディング方法。
[付記39]
前記メモリにハッシュのチェーンを格納するステップをさらに含む、付記1乃至付記38のいずれか一項に記載のデータトランザクションレコーディング方法。
[付記40]
送信された前記ハッシュのチェーンに対するアクセスを制限するように構成されたデバイス上に位置する第2メモリに前記ハッシュのチェーンを送信するステップをさらに含む、付記39に記載のデータトランザクションレコーディング方法。
[付記41]
前記ハッシュのチェーンでハッシュを修正又は削除するステップをさらに含み、
前記ハッシュのチェーンでハッシュを修正又は削除するステップは、
前記ハッシュのチェーンで対象のハッシュを再生成するステップと、
前記レコードが修正されていないかの有無を確認するステップと、
前記再生成されたハッシュをレコーディングするステップと、
前記レコードを修正又は削除するステップと、
前記対象のハッシュの結合及び前記修正および削除されたレコードをハッシュして前記レコードに対する新しいハッシュを生成するステップと、
前記新しいハッシュをレコーディングするステップと、
を含む、付記39は付記40に記載のデータトランザクションレコーディング方法。
[付記42]
前記新しいハッシュを用いてシステムハッシュを生成するステップをさらに含む、付記41に記載のデータトランザクションレコーディング方法。
[付記43]
第1エンティティに関連するデバイスにおいて、前記デバイスは、付記1乃至付記42のいずれか一項に記載の方法を実行するデバイス。
[付記44]
前記デバイスはサーバを含む、付記43に記載のデバイス。
[付記45]
前記デバイスはユーザデバイスを含む、付記43に記載のデバイス。
[付記46]
前記ユーザデバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネット(IoT)可能デバイスのうち少なくとも1つを含む、付記45に記載のデバイス。
[付記47]
前記ユーザデバイスは、前記デバイス上のメモリで前記第1ハッシュを格納する、付記46に記載のデバイス。
[付記48]
前記ユーザデバイスは、該当サーバからオフラインである場合にのみ、前記デバイス上のメモリで前記第1ハッシュを格納する、付記47に記載のデバイス。
[付記49]
前記デバイスは、前記第2エンティティに関連するデバイスに前記第1ハッシュを送信する、付記43乃至付記48のいずれか一項に記載のデバイス。
[付記50]
前記デバイスは、前記第1データトランザクションの前記レコードの署名及び暗号化されたコピーを前記第2エンティティに関連する前記デバイスに送信し、
前記署名は、前記第1データトランザクションの前記レコードに対する配信先サーバの指示(indication)を含む、付記49に記載のデバイス。
[付記51]
前記デバイスは、特定のオフライン公開キーで前記レコードにサインする、付記50に記載のデバイス。
[付記52]
前記デバイスは、前記デバイスに属するキーで前記レコードにサインする、付記50に記載のデバイス。
[付記53]
前記配信先サーバのみが前記第1データトランザクションの前記レコードの前記暗号化されたコピーを解読できる、付記50乃至付記52のいずれか一項に記載のデバイス。
[付記54]
前記デバイスが、対応するサーバへの接続を回復するとき、前記デバイスは、前記関連するハッシュ及びそのオフラインデータトランザクションの前記暗号化されたレコードを対応するサーバに送信する、付記48乃至付記53のいずれか一項に記載のデバイス。
[付記55]
前記デバイスは、自身が保有する他のエンティティに関連するデータトランザクションのレコードのコピーを前記他のエンティティに対応するサーバへの送信のために自身に対応するサーバに送信する、付記54に記載のデバイス。
[付記56]
前記送信することは、前記レコードが適用される全てのサーバに前記レコードを受信することを期待して通知することを含む、付記55に記載のデバイス。
[付記57]
前記デバイスは、前記第1データトランザクションでこの部分を識別するために固有の内部トランザクション番号を生成する、付記43乃至付記56のいずれか一項に記載のデバイス。
[付記58]
ライセンスデバイスであって、
第1エンティティに関連するデバイスから第1ハッシュを受信することであって、前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む、前記第1ハッシュを受信すること、
ライセンス入力を提供するためにライセンスハッシュと前記第1ハッシュを結合すること、
前記ライセンス入力をハッシュして第2ライセンスハッシュを生成すること、
メモリに前記第2ライセンスハッシュを格納すること、を行うように構成されたライセンスデバイス。
[付記59]
ディレクトリデバイスであって、
第1エンティティに関連するデバイスから第1ハッシュを受信することであって、前記第1ハッシュは、前記第1エンティティに関連するデータトランザクションのヒストリーを含む、前記第1ハッシュを受信すること、
ディレクトリ入力を提供するためにディレクトリハッシュと前記第1ハッシュを結合すること、
前記ライセンス入力をハッシュして第2ディレクトリハッシュを生成すること、
メモリに前記第2ディレクトリハッシュを格納すること、を行うように構成されたディレクトリデバイス。
[付記60]
実行されるときコンピューティングデバイスが付記1乃至付記42のいずれか一項に記載の方法を実行させる複数のコード部分を含むコンピュータ可読記録媒体。
[付記61]
デバイスから第1サービスにアクセスする方法において、
要求サーバに前記デバイスの識別子を提供するステップと、
前記識別子に基づいて前記デバイスが前記第1サービスに対するアクセスを要求することを許可するステップと、
前記デバイスが前記第1サービスが位置する第1ホストサーバから前記第1サービスにアクセスさせるステップであって、前記アクセスは、前記要求サーバを介して行われる、前記第1サービスにアクセスさせるステップと、
を含む方法。
[付記62]
前記許可するステップは、前記識別子に基づいて前記ユーザデバイスが前記第1サービスにアクセスするように許可されるかを確認するステップを含む、付記61に記載の方法。
[付記63]
確認するステップは、前記識別子に基づいて前記ユーザが少なくとも1つの基準(criteria)を満足するかを確認するステップを含む、付記62に記載の方法。
[付記64]
第1基準が前記第1ホストサーバ又は前記要求サーバに格納され、第2基準が他のサーバに位置する、付記63に記載の方法。
[付記65]
前記許可するステップは、前記要求サーバ及び前記第1ホストサーバ間の通信に対する署名を検証するステップを含む、付記61乃至付記64のいずれか一項に記載の方法。
[付記66]
前記許可するステップは前記要求サーバで実行される、付記61乃至付記65のいずれか一項に記載の方法。
[付記67]
前記許可するステップは、前記要求サーバで前記デバイスが前記第1サービスにアクセスするように以前に許可されたかを決定するステップを含む、付記66に記載の方法。
[付記68]
前記許可するステップはディレクトリサーバで実行される、付記61乃至付記65のいずれか一項に記載の方法。
[付記69]
前記許可するステップは、前記要求サーバが前記ディレクトリサーバから前記デバイスに対する許可を要求するステップを含む、付記68に記載の方法。
[付記70]
前記アクセスさせるステップは、前記ディレクトリサーバが前記第1ホストサーバに対する識別子を前記要求サーバに送信するステップを含む、付記68又は付記69に記載の方法。
[付記71]
前記識別子を許可するデータは、前記ディレクトリサーバに格納される、付記68乃至付記70のいずれか一項に記載の方法。
[付記72]
第2サービスに対するアクセスを要求するステップと、
前記識別子に基づいて前記デバイスが前記第2サービスにアクセスすることを許可するステップと、
前記デバイスが前記要求サーバを介して前記第2サービスにアクセスさせるステップと、
をさらに含む、付記61乃至付記71のいずれか一項に記載の方法。
[付記73]
前記第2サービスは前記第1ホストサーバに位置する、付記72に記載の方法。
[付記74]
前記第2サービスは第2ホストサーバに位置する、付記72に記載の方法。
[付記75]
前記デバイスが前記第1サービスにアクセスすることを許可するステップは、第1ディレクトリサーバで実行され、
前記ユーザデバイスが前記第2サービスにアクセスすることを許可するステップは、第2ディレクトリサーバで実行される、付記72乃至付記74のいずれか一項に記載の方法。
[付記76]
第3サービスに対するアクセスを要求するステップと、
前記識別子に基づいて前記デバイスが前記第3サービスにアクセスすることを許可するステップと、
前記デバイスが前記第3サービスにアクセスさせるステップと、
をさらに含む、付記72乃至付記75のいずれか一項に記載の方法。
[付記77]
前記第2サービスは、前記第1ホストサーバ、前記第2ホストサーバ又は第3ホストサーバに位置する、付記76に記載の方法。
[付記78]
前記デバイスが前記第3サービスにアクセスすることを許可するステップは、第3ディレクトリサーバで実行される、付記76又は付記77に記載の方法。
[付記79]
識別子を提供するステップは、前記デバイスが暗号化されたトンネルを介して前記要求サーバと通信するステップを含む、付記61乃至付記78のいずれか一項に記載の方法。
[付記80]
それぞれの個別サーバで受信されるデータをキャッシュするステップをさらに含む、付記61乃至付記79のいずれか一項に記載の方法。
[付記81]
それぞれのホストサーバは、二以上のサービスを提供する、付記61乃至付記80のいずれか一項に記載の方法。
[付記82]
付記61乃至付記81のいずれか一項に記載の方法を実行するデバイス。
[付記83]
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、付記82に記載のデバイス。
[付記84]
実行されるとき、コンピュータデバイスが付記61乃至付記81のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
[付記85]
第1データストアーから第2データストアーに第1データをスイッチングするための要求を提供するステップと、
前記要求に含まれた識別子に基づいて前記第1データストアーの識別子をディレクトリサーバから決定するステップと、
前記第1データストアーから前記第2データストアーに前記第1データをマイグレーションするステップと、
を含むデータマイグレーション方法。
[付記86]
前記マイグレーションするステップは、前記ディレクトリサーバにおいて、
前記第2データストアーで前記データに対する開始タイムスタンプを割り当てるステップと、
前記第1データストアーで前記データに対する終了タイムスタンプを割り当てるステップと、
を含む、付記85に記載のデータマイグレーション方法。
[付記87]
前記終了タイムスタンプの後に、前記第1データストアーを介して前記データにアクセスしようと試みる要求サーバに、前記ディレクトリサーバを介して前記第2データストアーで前記ユーザを検索するように指示するステップをさらに含む、付記86に記載のデータマイグレーション方法。
[付記88]
前記第1データストアーにおける前記データは、第1アカウント提供者との第1アカウント登録を含み、
前記第2データストアーにおける前記データは、新しいアカウント提供者との第2アカウント登録を含む、付記85乃至付記87のいずれか一項に記載のデータマイグレーション方法。
[付記89]
前記マイグレーションするステップは、前記現在のアカウント提供者から前記新しいアカウント提供者に前記第1アカウント登録に関する情報を送信するステップを含む、付記88に記載のデータマイグレーション方法。
[付記90]
前記情報は、登録(registrations)、残額(balances)、コンフィギュレーション(configurations)及び支払い指示(payment instructions)のうち少なくとも1つを含む、付記89に記載のデータマイグレーション方法。
[付記91]
マイグレーションするステップは、前記第1登録が前記現在のアカウント提供者から前記新しいアカウント提供者にスイッチされなければならないことを示す認証コード(authentication code)を確認するステップを含む、付記88乃至付記90のいずれか一項に記載のデータマイグレーション方法。
[付記92]
前記第1アカウント登録は第1ユーザ・クリデンシャルを含み、
前記第2アカウント登録は第2ユーザ・クリデンシャルを含む、付記88乃至付記91のいずれか一項に記載のデータマイグレーション方法。
[付記93]
前記第1ユーザ・クリデンシャルは第1サーバに登録され、
前記第2ユーザ・クリデンシャルは第2サーバに登録される、付記92に記載のデータマイグレーション方法。
[付記94]
前記第1アカウント提供者によって前記第1ユーザ・クリデンシャルを用いてユーザに伝えられる通信を受信するステップと、
前記第2ユーザ・クリデンシャルを用いて前記通信を前記第2アカウント提供者にルーティングするステップと、
をさらに含む、付記93に記載のデータマイグレーション方法。
[付記95]
前記第1クリデンシャルを使用する前記第1登録提供者で作られたデータトランザクションを、前記第2ユーザ・クリデンシャルを使用する前記第2登録提供者に反転させるステップをさらに含む、付記93又は付記94に記載のデータマイグレーション方法。
[付記96]
前記トランザクション時に前記ユーザが前記第1ユーザ・クリデンシャルを使用したことを決定するステップを含む、付記95に記載のデータマイグレーション方法。
[付記97]
前記通信を送信するサーバは、前記第2ユーザ・クリデンシャルにアクセスするように承認されなければならない、付記94乃至付記96のいずれか一項に記載のデータマイグレーション方法。
[付記98]
前記第1ユーザ・クリデンシャル及び前記第2ユーザ・クリデンシャルは同一である、付記92乃至付記97のいずれか一項に記載のデータマイグレーション方法。
[付記99]
付記85乃至付記98のいずれか一項に記載の方法を実行するデバイス。
[付記100]
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、付記99に記載のデバイス。
[付記101]
実行されるとき、コンピュータデバイスが付記85乃至付記98のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
[付記102]
第1エンティティから第2エンティティに第1通信を送信するステップであって、前記第1通信は2つ以上のデータフィールドを含み、それぞれのフィールドは個別ラベルを含む、前記第1通信を送信するステップと、
前記第1エンティティから前記第2エンティティに第2通信を送信するステップであって、前記第2通信は前記2つ以上のデータフィールドを含み、前記第2通信における前記2つ以上のデータフィールドの順は、前記第1通信における前記2つ以上のデータフィールドの順と異なる、前記第2通信を送信するステップと、
を含む通信方法。
[付記103]
ランダムフィールドを前記第2通信に追加するステップをさらに含む、付記102に記載の通信方法。
[付記104]
それぞれのフィールドは2つ以上の特徴を含み、
少なくとも1つのフィールドで2つ以上の特徴のケースをミキシングするステップをさらに含む、付記102又は付記103に記載の通信方法。
[付記105]
前記第2通信を処理する前に、前記第2エンティティによって前記第2通信で前記フィールドを解読及び順序化するステップをさらに含む、付記102乃至付記104のいずれか一項に記載の通信方法。
[付記106]
前記第2エンティティによって処理できないフィールドを廃棄するステップをさらに含む、付記105に記載の通信方法。
[付記107]
前記1エンティティ及び前記第2エンティティのうち少なくとも1つはサーバを含む、付記102乃至付記106のいずれか一項に記載の装置。
[付記108]
前記1エンティティ及び前記第2エンティティのうち少なくとも1つは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスを含む、付記102乃至付記106のいずれか一項に記載の装置。
[付記109]
付記102乃至付記108のいずれか一項に記載の方法を実行するデバイス。
[付記110]
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、付記109に記載のデバイス。
[付記111]
実行されるとき、コンピュータデバイスが付記102乃至付記108のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
[付記112]
USSD(unstructured supplementary service data)を介した通信方法において、
第1デバイスと第2デバイスとの間のUSSDセッションを開放するステップと、
前記第1デバイスにおいて前記セッションで通信に対するサイファーテキスト(cypher text)を生成するステップと、
前記第1デバイスで前記サイファーテキストを符号化するステップと、
前記第2デバイスで解読のために前記第1デバイスから前記第2デバイスに前記符号化されたサイファーテキストを送信するステップと、
を含む通信方法。
[付記113]
前記符号化するステップは、前記サイファーテキストを7ビット又は8ビットの文字ストリングに符号化するステップを含む、付記112に記載の通信方法。
[付記114]
前記サイファーテキストの長さが前記USSDセッションで前記許容されたスペースよりも長い場合、
前記サイファーテキストを2つ又は2つ以上の部分に分割するステップと、
前記2つ又は2つ以上の部分を個別的に送信するステップと、
をさらに含む、付記112又は付記113に記載の通信方法。
[付記115]
前記第2デバイスにおける解読のために、前記第2デバイスから前記サイファーテキストの全体に前記パートをリアセンブルするステップを含む、付記114に記載の通信方法。
[付記116]
前記1及び第2デバイスを認証するステップをさらに含む、付記112乃至付記115のいずれか一項に記載の通信方法。
[付記117]
認証するステップは、2つの通信コンピュータアプリケーション間のプライバシー及びデータ無欠性を提供するアルゴリズムを使用するステップを含む、付記116に記載の通信方法。
[付記118]
認証するステップは、TLS(transport layersecurity)を使用するステップを含む、付記117に記載の通信方法。
[付記119]
TLSを使用するステップは、第1セッションキーを生成するステップを含む、付記118に記載の通信方法。
[付記120]
第2セッションキーを生成するためにPAKEプロトコルネゴシエーション(PAKE
protocol negotiation)を暗号化する前記第1セッションキーを使用するステップと、
前記第2セッションキーを用いて前記第1デバイスと前記第2デバイスとの間の前記セッションで追加通信を暗号化するステップと、
をさらに含む、付記119に記載の通信方法。
[付記121]
付記112乃至付記120のいずれか一項に記載の方法を実行するデバイス。
[付記122]
実行されるとき、コンピュータデバイスが付記112乃至付記120のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
[付記123]
第1エンティティに関連する第1デバイスと第2エンティティに関連する第2デバイスとの間の通信方法において、前記第1デバイスで、
第1共有秘密を用いて前記第1デバイス及び前記第2デバイス間の第1PAKEセッションを生成するステップと、
前記第2デバイスから登録キー及び第2共有秘密を受信するステップと、
第2PAKEセッションを生成するための第3共有秘密を提供するために、前記第1共有秘密、前記登録キー、及び前記第2共有秘密をハッシュするステップと、
を含む通信方法。
[付記124]
前記1エンティティ及び前記第2エンティティを認証するステップをさらに含む、付記123に記載の通信方法。
[付記125]
認証するステップは、2つの通信コンピュータアプリケーション間のプライバシー及びデータ無欠性を提供するアルゴリズムを使用するステップを含む、付記124に記載の通信方法。
[付記126]
前記認証するステップはTLSを使用するステップを含む、付記125に記載の通信方法。
[付記127]
第4共有秘密を用いて前記第1デバイス及び第3デバイス間の第2PAKEセッションを生成するステップをさらに含む、付記123乃至付記126のいずれか一項に記載の通信方法。
[付記128]
前記第4共有秘密は、前記第1デバイスのために前記第3デバイスによって生成された認証コードを含む、付記127に記載の通信方法。
[付記129]
前記第1共有秘密は、前記第1デバイスのために前記第2デバイスによって生成された認証コードを含む、付記123乃至付記128のいずれか一項に記載の通信方法。
[付記130]
前記認証コードは、前記第1デバイスのために識別子と共に前記第1デバイスに送信される、付記129に記載の通信方法。
[付記131]
前記識別子は、前記第1デバイスの電話番号又はシリアル番号を含む、付記130に記載の通信方法。
[付記132]
前記第1共有内緒は、前記1エンティティに関連する銀行カードのPAN(personal account number)を含む、付記123乃至付記131のいずれか一項に記載の通信方法。
[付記133]
前記第1共有秘密は、前記1エンティティに関連する銀行カードの符号化されたシリアル番号を含む、付記123乃至付記131のいずれか一項に記載の通信方法。
[付記134]
付記123乃至付記133のいずれか一項に記載の方法を実行するデバイス。
[付記135]
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、付記134に記載のデバイス。
[付記136]
実行されるとき、コンピュータデバイスが付記123乃至付記133のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
[付記137]
サービスにアクセスする方法において、
クリデンシャル及び前記クリデンシャルに対するコンテキストを提供するステップと、
前記クリデンシャル及び前記コンテキストに基づいて前記サービスに対するアクセスを認証するステップと、
を含む方法。
[付記138]
前記サービスに対するアクセスを認証するステップは、
前記クリデンシャル及び前記コンテキストのうちの少なくとも一方に基づいてサービスの一部に対するアクセスを認証するステップを含む、付記137に記載の方法。
[付記139]
前記クリデンシャルは、デバイス及び前記デバイスのプライマリユーザ(primary user)に関連する第1クリデンシャルを含む、付記137又は付記138に記載の方法。
[付記140]
前記クリデンシャルは、デバイス及び前記デバイスのセカンダリーユーザに関連する第2クリデンシャルをさらに含む、付記139に記載の方法。
[付記141]
前記クリデンシャルに基づいて前記サービスに対するアクセスを認証するステップは、前記第1クリデンシャル及び前記第2クリデンシャルのそれぞれに基づいて前記プライマリユーザ及び前記セカンダリーユーザに対する異なるサービスに対するアクセスを認証するステップを含む、付記140に記載の方法。
[付記142]
前記デバイスは、前記プライマリユーザ及び前記セカンダリーユーザに対する異なる支出限度である前記異なるサービス及び銀行カードを含む、付記141に記載の方法。
[付記143]
前記クリデンシャルは、前記コンテキストに基づいて選択される、付記137乃至付記142のいずれか一項に記載の方法。
[付記144]
前記サービスは、前記コンテキストに基づいて選択された複数のサービスを含む、付記137乃至付記143のいずれか一項に記載の方法。
[付記145]
管理者又はユーザは、前記コンテキスト又はクリデンシャルを修正、追加又は取り消しできる、付記137乃至付記144のいずれか一項に記載の方法。
[付記146]
前記クリデンシャルは、パスワード、PIN、及び他の直接認証クリデンシャル(direct authentication credential)のうち少なくとも1つを含む、付記137乃至付記145のいずれか一項に記載の方法。
[付記147]
前記コンテキストは、前記クリデンシャルを提供するデバイス、前記デバイス上のアプリケーション、前記デバイスが接続されたネットワーク、前記デバイスの地理的位置、及びアクセスされる前記サービスのうち少なくとも1つを含む、付記137乃至付記146のいずれか一項に記載の方法。
[付記148]
付記137乃至付記147のいずれか一項に記載の方法を実行するデバイス。
[付記149]
前記デバイスは、パーソナルコンピュータ、スマートフォン、スマートタブレット又はモノのインターネットが可能なデバイスのうち少なくとも1つを含む、付記148に記載のデバイス。
[付記150]
実行されるとき、コンピュータデバイスが付記137乃至付記147のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
[付記151]
コンピュータシステム内の複数のモジュール間の通信方法において、
第1モジュールからプロキシに共有メモリチャネルを伝達するステップと、
前記プロキシから第2モジュールに前記共有メモリチャネルを伝達するステップであって、前記プロキシは、前記コンピュータシステムの前記カーネルをバイパスして前記第1モジュールと前記第2モジュールとの間のデータを送信するハンドオフモジュールを含む、前記共有メモリチャネルを伝達するステップと、
前記第1モジュールから前記第2モジュールにデータを送信するステップと、
を含む通信方法。
[付記152]
複数の要求を前記第1モジュールのバッファメモリでバッチされたメッセージ(batched message)にバッチするステップと、
前記第2モジュールに送信される前記バッチされたメッセージをキューイングするステップと、
システム機能を許可する少なくとも1つのシステムフラグをセッティングするステップと、
前記第2モジュールで前記少なくとも1つのシステムフラグをチェックするステップと、
前記第2モジュールで前記バッチされたメッセージを処理するステップと、
をさらに含む、付記151に記載の通信方法。
[付記153]
前記第1モジュールと前記第2モジュールとの間の少なくとも1つの共有メモリチャネルを設定するステップをさらに含む、付記151又は付記152に記載の通信方法。
[付記154]
前記少なくとも1つの共有メモリチャネルを介して前記第1モジュールに応答する前記第2モジュールを含む、付記153に記載の通信方法。
[付記155]
前記少なくとも1つの共有メモリチャネルは、前記バッチされたメッセージを受信及びアセンブルし、前記第2モジュールに前記メモリの所有権を渡す、付記153又は付記154に記載の通信方法。
[付記156]
前記少なくとも1つの共有メモリチャネルは、前記コンピュータシステムのネットワークスタック(network stack)を介してバッチされたメッセージを受信する、付記155に記載の通信方法。
[付記157]
前記少なくとも1つの共有メモリチャネルは、HTTPゲートウェイを含む、付記153乃至付記156のいずれか一項に記載の通信方法。
[付記158]
HTTPゲートウェイはウェブサービスとして用いられる、付記151乃至付記157のいずれか一項に記載の通信方法。
[付記159]
通信は、パスワード認証されたキー交換プロトコルを使用する、付記151乃至付記158のいずれか一項に記載の通信方法。
[付記160]
前記コンピュータシステムのネットワークスタックでゼロコピーネットワーキング(zero-copy networking)を使用するステップをさらに含む、付記151乃至付記159のいずれか一項に記載の通信方法。
[付記161]
前記コンピュータシステムのネットワークスタックでユーザモードネットワーキングを使用するステップをさらに含む、付記151乃至付記160のいずれか一項に記載の通信方法。
[付記162]
前記第1モジュールから前記データ送信の前記コンポーネントが単一データストリームに結合され、前記第1モジュールで前記コンポーネントに分離されるようにデータを直列化するステップをさらに含む、付記151乃至付記161のいずれか一項に記載の通信方法。
[付記163]
前記直列化は、各モジュールのエッジで抽象化される、付記162に記載の通信方法。
[付記164]
各モジュールのバッファメモリは、構成可能なバッファリング閾値を有する、付記151乃至付記163のいずれか一項に記載の通信方法。
[付記165]
前記第1モジュール及び前記第2モジュールは、同じコンピューティングデバイス上に位置する、付記151乃至付記164のいずれか一項に記載の通信方法。
[付記166]
前記第1モジュール及び前記第2モジュールは、異なるコンピューティングデバイス上に位置する、付記151乃至付記164のいずれか一項に記載の通信方法。
[付記167]
前記第1モジュールから前記第2モジュールに送信されたデータはバージョンIDを運ぶ、付記151乃至付記166のいずれか一項に記載の通信方法。
[付記168]
前記バージョンIDが前記第1モジュールから前記第2モジュールに送信された前記データに対して、最新であるかを検証するステップをさらに含む、付記167に記載の通信方法。
[付記169]
前記データのうち任意のデータがアップデートされる場合、前記バージョンIDを現在のバージョンに再検証するステップをさらに含む、付記168に記載の通信方法。
[付記170]
前記バージョンIDが検証されない場合、前記データ送信は失敗する、付記169に記載の通信方法。
[付記171]
前記第1モジュール及び前記第2モジュールのうち少なくとも1つは少なくとも1つのデータサービスモジュールを含み、
前記コンピュータシステム内の各データ処理は、前記少なくとも1つのデータサービスモジュールを介して実行される、付記151乃至付記170のいずれか一項に記載の通信方法。
[付記172]
前記少なくとも1つのデータサービスモジュールは、コアデータベースストアーによって実現されるデータストアーと通信する、付記171に記載の通信方法。
[付記173]
前記少なくとも1つのデータサービスモジュールは、前記データストアーに直接アクセスする前記コンピュータシステムのコンポーネントである、付記172に記載の通信方法。
[付記174]
前記コアデータベースストアーは、少なくとも1つの分散データベースを含む、付記173に記載の通信方法。
[付記175]
前記少なくとも1つの分散データベースは、別途の読み出し及び記録アクセスチャネルを有する、付記174に記載の通信方法。
[付記176]
前記データストアーは、少なくとも1つの異種データベースにインタフェースを提供する、付記173乃至付記175のいずれか一項に記載の通信方法。
[付記177]
前記データストアーは、複数のインタフェースタイプを提供する、付記173乃至付記176のいずれか一項に記載の通信方法。
[付記178]
前記複数のインタフェースタイプは、少なくとも1つのSQL(Structured Query Language)インタフェース、セル及びコラムインタフェース(cell and column interface)、文書インタフェース(document interface)、及び前記コアデータベースストアー上にあるグラフィックインタフェース(graph interface)のうち少なくとも1つを含む、付記177に記載の通信方法。
[付記179]
前記データストアーレイヤに対する全ての記録は、1つ又は1つ以上のデータトランザクションの全て又は一部を制御する単一共有モジュールによって管理される、付記176乃至付記178のいずれか一項に記載の通信方法。
[付記180]
少なくとも1つの前記共有モジュールのリダンダント・バックアップ(redundant backup)を作動させるステップをさらに含む、付記179に記載の通信方法。
[付記181]
全てのデータ変更は、シリアルの速いシーケンス(serial rapid sequence)で前記単一共有モジュールを介して行われる、付記179又は付記180に記載の通信方法。
[付記182]
前記単一共有モジュールは、その自体をデータ・トランザクタ・クラスタ(data transactor cluster)に示すホットバックアップ・リダンダンシー・モデル(hot backup redundancy model)を使用し、
前記データ・トランザクタ・クラスタは、ハイアラーキー(hierarchy)で1組のモジュールであり、各モジュールは、マスタモジュールが失敗する場合にデータトランザクションを制御する、付記179乃至付記181のいずれか一項に記載の通信方法。
[付記183]
ドメインによって構成される規則に基づいて、複数のモジュール又は複数のデータストアーにわたってデータを分割するステップをさらに含む、付記171乃至付記182のいずれか一項に記載の通信方法。
[付記184]
データトランザクションのレコード又は親データトランザクション(parent data transaction)のレコードのターゲットデータをハッシュするステップをさらに含む、付記183に記載の通信方法。
[付記185]
前記ハッシュするステップは、データパーティションの数と同じカーディナリティ(cardinality)を有する、付記184に記載の通信方法。
[付記186]
挙げられた地理的領域、名字、及び通貨のうち少なくとも1つによってターゲットデータをハッシュするステップをさらに含む、付記184又は付記185に記載の通信方法。
[付記187]
複数のデータパーティションの全てに前記少なくとも1つのデータサービスモジュールを介して少なくとも1つのデータ送信を行うステップをさらに含む、付記171乃至付記186のいずれか一項に記載の通信方法。
[付記188]
複数のモジュールによって前記少なくとも1つのデータサービスモジュールを介して少なくとも1つのデータ送信を完了するステップをさらに含む、付記171乃至付記187のいずれか一項に記載の通信方法。
[付記189]
前記少なくとも1つのデータサービスモジュール上の少なくとも1つのデータ送信を前記データストアーで複数のデータストレージノード上に保持するステップをさらに含む、付記171乃至付記188のいずれか一項に記載の通信方法。
[付記190]
前記コンピュータシステムは、複数のデータサービスモジュールを含み、
それぞれのデータサービスモジュールは、該当インスタンスに対する全ての前記ホットデータのキャッシュされた表現を含み、イン-メモリ(in-memory)またはイン-プロセス(in-process)データベースエンジンをホストする、付記171乃至付記189のいずれか一項に記載の通信方法。
[付記191]
前記コンピュータシステムは、複数のデータサービスモジュールを含み、
それぞれのデータサービスモジュールは、複数の異種又は同種データベースエンジンを含む、付記171乃至付記189のいずれか一項に記載の通信方法。
[付記192]
全てのデータ読み出しが一貫し、対応するデータ記録を反映するように、前記データストアーに対するアクセスの同時性を管理するMVCC(Multiversion Concurrency Control)バージョンシステムを使用するステップをさらに含む、付記172乃至付記191のいずれか一項に記載の通信方法。
[付記193]
データレコードが前記データストアーに記録され、任意の後続データトランザクションが前記データレコードにアクセスする前に記録されたことが確認されるように、前記データストアーに対するアクセスの同時性を管理する悲観的一貫性(pessimistic consistency)を使用するステップをさらに含む、付記172乃至付記191のいずれか一項に記載の通信方法。
[付記194]
前記コンピュータシステムは、アプリケーションレイヤをさらに含み、
前記少なくとも1つのデータサービスモジュールが前記レコードを記録し、前記データ送信を完了することを確認するまで、前記アプリケーションレイヤは、データトランザクションを進めることができない、付記171乃至付記193のいずれか一項に記載の通信方法。
[付記195]
付記151乃至付記194のいずれか一項に記載の方法を実行するコンピューティングデバイス。
[付記196]
実行されるときコンピュータデバイスが付記151乃至付記194のいずれか一項に記載の方法を実行させる複数のコード部分(code portions)を含むコンピュータ可読記録媒体。
【外国語明細書】