特表 2022-546005 ブロックチェーンインセンティブ方式の非集中型データストリーミングおよび配信に対する少額支払いサポートのための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-11-02

(54)【発明の名称】ブロックチェーンインセンティブ方式の非集中型データストリーミングおよび配信に対する少額支払いサポートのための方法およびシステム

(51)【国際特許分類】

   G06Q 20/00 20120101AFI20221026BHJP

   G06Q 20/38 20120101ALI20221026BHJP

【ＦＩ】

G06Q20/00

G06Q20/38 310

【審査請求】未請求

【予備審査請求】有

(21)【出願番号】P 2022506034

(86)(22)【出願日】2020-07-30

(85)【翻訳文提出日】2022-03-18

(86)【国際出願番号】 US2020070336

(87)【国際公開番号】W WO2021022305

(87)【国際公開日】2021-02-04

(31)【優先権主張番号】62/880,682

(32)【優先日】2019-07-31

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/914,176

(32)【優先日】2019-10-11

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/726,148

(32)【優先日】2019-12-23

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＹｏｕＴｕｂｅ

２．ＪＡＶＡＳＣＲＩＰＴ

３．ＸＢＯＸ

４．ＷＣＤＭＡ

５．ＺＩＧＢＥＥ

６．ＢＬＵＥＴＯＯＴＨ

７．ｉＢｅａｃｏｎ

(71)【出願人】

【識別番号】522037562

【氏名又は名称】セタ ラブス，インコーポレイテッド

(74)【代理人】

【識別番号】100114775

【弁理士】

【氏名又は名称】高岡 亮一

(74)【代理人】

【識別番号】100121511

【弁理士】

【氏名又は名称】小田 直

(74)【代理人】

【識別番号】100202751

【弁理士】

【氏名又は名称】岩堀 明代

(74)【代理人】

【識別番号】100208580

【弁理士】

【氏名又は名称】三好 玲奈

(74)【代理人】

【識別番号】100191086

【弁理士】

【氏名又は名称】高橋 香元

(72)【発明者】

【氏名】ロング，ジエイ

(72)【発明者】

【氏名】リウ，ミッチェル シー．

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055AA21

5L055AA71

(57)【要約】

ブロックチェーンのインセンティブを受ける非集中型データストリーミングおよび配信に対する少額支払いサポートのための方法およびシステムが開示される。複数のユーザへのデータリソースのストリーミングに対するブロックチェーンに基づく支払いを受け取るために、キャッシングノードは最初に支払い認可ピアグループに加入し、少額支払いプールの作成について通知される。データリソースの一部をユーザに配信した後、受信側ユーザによって署名されたサービス受領書が取得され、支払い許認可証と共に支払いサーバに提示される。これに対し、支払いサーバから更新されたオフチェーン取引が取得され、最後に更新されたオフチェーン取引が、少額支払いプールからの総支払い額を請求するためにブロックチェーンに提示される。このように、本発明の実施形態は、公開台帳システムを用いた非集中型の信頼と、データ配信およびデータストリーミング少額支払いの固有要件である低い取引コストでの高速でスケーラブルな取引速度という、２つの競合する目的を慎重に歩み寄らせる。
【選択図】図９

【特許請求の範囲】

【請求項1】

少なくとも２人の視聴者とデータリソースを共有する対価として支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るためにキャッシャによって用いられるコンピュータ実装方法であって、プロセッサによって実行可能であり、
前記支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取ることであって、前記少額支払いプールは、前記少なくとも２人の視聴者と前記データリソースを共有するための預金を備える積立て取引を前記ブロックチェーンに提示することによって作成されることと、
前記データリソースの第１の部分を第１の視聴者と共有することと、
前記データリソースの前記第１の部分に関する前記第１の視聴者によって署名された第１のサービス受領書を受け取ることと、
前記第１のサービス受領書を前記支払いサービスモジュールに提示することと、
前記支払いサービスモジュールから第１のオフチェーン取引を受け取ることであって、前記第１のオフチェーン取引は、前記データリソースの前記第１の部分に対する前記少額支払いプールから前記キャッシャへの第１の支払い額の第１の振込みを備えることと、
前記データリソースの第２の部分を第２の視聴者と共有することと、
前記データリソースの前記第２の部分に関する前記第２の視聴者によって署名された第２のサービス受領書を受け取ることと、
前記第２のサービス受領書を前記支払いサービスモジュールに提示することと、
前記第１のオフチェーン取引の更新として、前記支払いサービスモジュールから第２のオフチェーン取引を受け取ることであって、前記第２のオフチェーン取引は、前記データリソースの前記第１の部分および前記データリソースの前記第２の部分に対する前記少額支払いプールから前記キャッシャへの第２の支払い額の第２の振込みを備えることと、
前記少額支払いプールからの前記第２の支払い額を請求するために、前記第２のオフチェーン取引を前記ブロックチェーンに提示することと
を備える方法。

【請求項2】

前記データリソースを前記少なくとも２人の視聴者と共有するためにピアグループに加入することと、
前記第１の視聴者および前記第２の視聴者との前記データリソースの前記共有を認可する支払い許認可証を受け取ることと
を更に備える、請求項１に記載のコンピュータ実装方法。

【請求項3】

前記支払い許認可証を前記支払いサービスモジュールに提示すること
を更に備える、請求項２に記載のコンピュータ実装方法。

【請求項4】

前記ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる、請求項１に記載のコンピュータ実装方法。

【請求項5】

前記ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックで前記ブロックチェーンを検証するために監視者ノードを用い、前記チェックポイントブロックは、前記ブロックチェーン内のブロックのサブセットである、請求項４に記載のコンピュータ実装方法。

【請求項6】

前記通知は、前記積立て取引が新たなブロックに含まれた後の前記積立て取引のマークルプルーフを備える、請求項１に記載のコンピュータ実装方法。

【請求項7】

前記少額支払いプールは、前記データリソースのリソースＩＤ、時限錠、および削除可能な担保に関連付けられる、請求項１に記載のコンピュータ実装方法。

【請求項8】

少なくとも２人の視聴者とデータリソースを共有する対価として支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るためのキャッシャシステムであって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによってアクセス可能なプログラムコードを格納するための非一時的物理媒体と
を備え、
前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに、
前記支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取らせ、ここで前記少額支払いプールは、前記少なくとも２人の視聴者と前記データリソースを共有するための預金を備える積立て取引を前記ブロックチェーンに提示することによって作成され、
前記データリソースの第１の部分を第１の視聴者と共有させ、
前記データリソースの前記第１の部分に関する前記第１の視聴者によって署名された第１のサービス受領書を受け取らせ、
前記第１のサービス受領書を前記支払いサービスモジュールに提示させ、
前記支払いサービスモジュールから、前記データリソースの前記第１の部分に対する前記少額支払いプールから前記キャッシャへの第１の支払い額の第１の振込みを備える第１のオフチェーン取引を受け取らせ、
前記データリソースの第２の部分を第２の視聴者と共有させ、
前記データリソースの前記第２の部分に関する前記第２の視聴者によって署名された第２のサービス受領書を受け取らせ、
前記第２のサービス受領書を前記支払いサービスモジュールに提示させ、
前記第１のオフチェーン取引の更新として、前記支払いサービスモジュールから、前記データリソースの前記第１の部分および前記データリソースの前記第２の部分に対する前記少額支払いプールから前記キャッシャへの第２の支払い額の第２の振込みを備える第２のオフチェーン取引を受け取らせ、
前記少額支払いプールからの前記第２の支払い額を請求するために、前記第２のオフチェーン取引を前記ブロックチェーンに提示させる、キャッシャシステム。

【請求項9】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記データリソースを前記少なくとも２人の視聴者と共有するためにピアグループに加入させ、
前記第１の視聴者および前記第２の視聴者との前記データリソースの前記共有を認可する支払い許認可証を受け取らせる、請求項８に記載のキャッシャシステム。

【請求項10】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記支払い許認可証を前記支払いサービスモジュールに提示させる、請求項９に記載のキャッシャシステム。

【請求項11】

前記ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる、請求項８に記載のキャッシャシステム。

【請求項12】

前記ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックで前記ブロックチェーンを検証するために監視者ノードを用い、前記チェックポイントブロックは、前記ブロックチェーン内のブロックのサブセットである、請求項１１に記載のキャッシャシステム。

【請求項13】

前記通知は、前記積立て取引が新たなブロックに含まれた後の前記積立て取引のマークルプルーフを備える、請求項８に記載のキャッシャシステム。

【請求項14】

前記少額支払いプールは、前記データリソースのリソースＩＤ、時限錠、および削除可能な担保に関連付けられる、請求項８に記載のキャッシャシステム。

【請求項15】

少なくとも２人の視聴者とデータリソースを共有する対価として支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るためにキャッシャによって用いられるプログラムコードを格納するための非一時的格納媒体であって、前記プログラムコードはプロセッサによって実行可能であり、前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに、
前記支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取らせ、ここで前記少額支払いプールは、前記少なくとも２人の視聴者と前記データリソースを共有するための預金を備える積立て取引を前記ブロックチェーンに提示することによって作成され、
前記データリソースの第１の部分を第１の視聴者と共有させ、
前記データリソースの前記第１の部分に関する前記第１の視聴者によって署名された第１のサービス受領書を受け取らせ、
前記第１のサービス受領書を前記支払いサービスモジュールに提示させ、
前記支払いサービスモジュールから、前記データリソースの前記第１の部分に対する前記少額支払いプールから前記キャッシャへの第１の支払い額の第１の振込みを備える第１のオフチェーン取引を受け取らせ、
前記データリソースの第２の部分を第２の視聴者と共有させ、
前記データリソースの前記第２の部分に関する前記第２の視聴者によって署名された第２のサービス受領書を受け取らせ、
前記第２のサービス受領書を前記支払いサービスモジュールに提示させ、
前記第１のオフチェーン取引の更新として、前記支払いサービスモジュールから、前記データリソースの前記第１の部分および前記データリソースの前記第２の部分に対する前記少額支払いプールから前記キャッシャへの第２の支払い額の第２の振込みを備える第２のオフチェーン取引を受け取らせ、
前記少額支払いプールからの前記第２の支払い額を請求するために、前記第２のオフチェーン取引を前記ブロックチェーンに提示させる、非一時的記憶媒体。

【請求項16】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記データリソースを前記少なくとも２人の視聴者と共有するためにピアグループに加入させ、
前記第１の視聴者および前記第２の視聴者との前記データリソースの前記共有を認可する支払い許認可証を受け取らせる、請求項１５に記載の非一時的記憶媒体。

【請求項17】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記支払い許認可証を前記支払いサービスモジュールに提示させる、請求項１６に記載の非一時的記憶媒体。

【請求項18】

前記ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる、請求項１５に記載の非一時的記憶媒体。

【請求項19】

前記ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックで前記ブロックチェーンを検証するために監視者ノードを用い、前記チェックポイントブロックは、前記ブロックチェーン内のブロックのサブセットである、請求項１８に記載の非一時的記憶媒体。

【請求項20】

前記通知は、前記積立て取引が新たなブロックに含まれた後の前記積立て取引のマークルプルーフを備える、請求項１５に記載の非一時的記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、非集中型データ配信の分野であり、特に、分散型ハイブリッドネットワークを介したブロックチェーンインセンティブ方式の非集中型データストリーミングおよび配信に対する少額支払いサポートのための方法およびシステムに関する。

【背景技術】

【0002】

本セクションにおける記述は、本発明およびその用途および使用法を理解する上で役立つ背景の役割を果たし得るものであって、従来技術を構成するものではない。

【0003】

現在、インターネットビデオは、全てのインターネットトラフィックの４分の３を占め、シスコ社の２０１９年２月のＶｉｓｕａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｉｎｄｅｘ（Ｃｉｓｃｏ ＶＮＩ（登録商標））、全世界のＩＰトラフィックの予測、２０１７～２０２２年によると、２０２２年までに更に８２％まで増加するとされる。同報告書によると、２０１７年から２０２２年にかけて、全世界のインターネットビデオトラフィックは４倍、ライブインターネットビデオは１５倍、仮想現実および拡張現実トラフィックは１２倍、インターネットゲームトラフィックは９倍に成長することが予測される。米国では、１８～３４歳のミレニアル世代が、ＹＯＵＴＵＢＥ、ＮＥＴＦＬＩＸ、ＨＵＬＵ、およびＨＢＯなどのサービスの使用によるビデオストリーミングの成長をもたらしている。ＳＳＲＳのメディアおよびテクノロジー調査によると、このグループにおけるビデオストリーミングは、１週間平均で１．６時間から５．７時間に２５６％の急増を示しており、モバイルデバイスがビデオ消費量をリードしている。

【0004】

シスコ社によると、サーバとユーザとの間の地理的距離を低減することによってユーザへのデータ配信の遅延を最小限にする分散型サーバシステムであるコンテンツ配信ネットワーク（ＣＤＮ）が２０２２年までにインターネットトラフィックの７２％を担うことが予測され、それらは、データストリームをエンドユーザに配信するバックボーンインフラを提供することによって、ウェブコンテンツおよびストリーミングビデオデータの配信における重要な役割を果たす。現在のＣＤＮネットワークの主な欠点は、いわゆる「ラストマイル」配信問題であり、限られた数の存在点（ＰＯＰ）データセンタとエンドユーザとの間の「ラストマイル」リンクが、データストリーミングおよび配信パイプラインにおけるボトルネックとなり、多くの場合、リンク障害、顕著な遅延、不安定なストリーム、不十分な画像品質、および頻繁なリバッファリングを含む最適未満のユーザ体験を招く。他の主な懸念としてＣＤＮ帯域幅コストがあり、これは、人気のあるサイトの場合、年間数千万ドルに容易に到達し得る。これらの問題は、たとえば４Ｋ、８Ｋ、および３６０°ＶＲストリーミングなどの高分解能デジタルメディアの時代、およびたとえばライトフィールドストリーミングなどの次世代技術の到来と共により顕著になる。たとえば、現在主流である７２０ｐ／ＨＤストリームの帯域幅要件は、新たなシステムでは桁違いに急増する。

【0005】

そのような帯域幅の限界に対処するために、自己組織化および自己構成メッシュネットワークに基づいて非集中型ピアツーピアデータストリーミングおよび配信プラットフォームが開発されている。エンドユーザは、余分な、または使用されていない計算、帯域幅、およびストレージリソースを共有してよい。利用可能なリソースを積極的に共有するようにユーザに動機付けしインセンティブを与えるためには、非集中型の性質を持つピアツーピアネットワークに準拠した、安全かつ遅延が最小限の報酬システムまたは支払い方法が必要である。また、１または複数のピアに送信され、またはそこから受信される個々の小さなデータチャンクに対する頻度の高い極めて小さな支払いを経済的に処理する能力も重要である。

【0006】

したがって、上述した難点の観点から、超高取引スループットをサポートする、非集中型ビデオストリーミングを含む非集中型データストリーミングおよび配信のための支払いシステムを設計するという未解決の要望が存在する。加えて、たとえば二重使用などの不正行為を検出し、防止し、罰することも必要である。

【0007】

この背景に対抗して、本発明の様々な実施形態が展開された。

【発明の概要】

【0008】

分散型メッシュネットワークによるデータ伝搬および少額支払いに関するオフチェーンブロックチェーン取引処理のための方法およびシステムが提供される。

【0009】

具体的には、１つの態様において、本発明の１つの実施形態は、少なくとも２人の視聴者にデータリソースを共有する対価として支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るための方法であり、この方法は、少なくとも２人の視聴者にデータリソースを共有するための預金を備える積立て取引をブロックチェーンに提示することによって作成される、支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取るステップと、データリソースの第１の部分を第１の視聴者と共有するステップと、データリソースの第１の部分に関する第１の視聴者によって署名された第１のサービス受領書を受け取るステップと、第１のサービス受領書を支払いサービスモジュールに提示するステップと、支払いサービスモジュールから、データリソースの第１の部分に対する少額支払いプールからキャッシャへの第１の支払い額の第１の振込みを備える第１のオフチェーン取引を受け取るステップと、データリソースの第２の部分を第２の視聴者と共有するステップと、データリソースの第２の部分に関する第２の視聴者によって署名された第２のサービス受領書を受け取るステップと、第２のサービス受領書を支払いサービスモジュールに提示するステップと、第１のオフチェーン取引の更新として、支払いサービスモジュールから、データリソースの第１の部分およびデータリソースの第２の部分に対する少額支払いプールからキャッシャへの第２の支払い額の第２の振込みを備える第２のオフチェーン取引を受け取るステップと、少額支払いプールからの第２の支払い額を請求するために、第２のオフチェーン取引をブロックチェーンに提示するステップとを備える。

【0010】

１つの実施形態において、方法は更に、データリソースを少なくとも２人の視聴者と共有するためにピアグループに加入することと、第１の視聴者および第２の視聴者とのデータリソースの共有を認可する支払い許認可証を受け取ることとを備える。

【0011】

１つの実施形態において、方法は更に、支払い許認可証を支払いサービスモジュールに提示することを備える。

【0012】

１つの実施形態において、ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる。１つの実施形態において、ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックでブロックチェーンを検証するために監視者ノードを用い、チェックポイントブロックは、ブロックチェーン内のブロックのサブセットである。

【0013】

１つの実施形態において、通知は、積立て取引が新たなブロックに含まれた後の積立て取引のマークルプルーフを備える。

【0014】

１つの実施形態において、少額支払いプールは、データリソースのリソースＩＤ、時限錠、および削除可能な担保に関連付けられる。

【0015】

他の態様によると、本発明の他の実施形態は、少なくとも２人の視聴者とデータリソースを共有する対価として支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るためのキャッシャシステムであり、このキャッシャシステムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによってアクセス可能なプログラムコードを格納するための非一時的物理媒体とを備える。プロセッサによって実行されると、プログラムコードは、プロセッサに、少なくとも２人の視聴者とデータリソースを共有するための預金を備える積立て取引をブロックチェーンに提示することによって作成される、支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取らせ、データリソースの第１の部分を第１の視聴者と共有させ、データリソースの第１の部分に関する第１の視聴者によって署名された第１のサービス受領書を受け取らせ、第１のサービス受領書を支払いサービスモジュールに提示させ、支払いサービスモジュールから、データリソースの第１の部分に対する少額支払いプールからキャッシャへの第１の支払い額の第１の振込みを備える第１のオフチェーン取引を受け取らせ、データリソースの第２の部分を第２の視聴者と共有させ、データリソースの第２の部分に関する第２の視聴者によって署名された第２のサービス受領書を受け取らせ、第２のサービス受領書を支払いサービスモジュールに提示させ、第１のオフチェーン取引の更新として、支払いサービスモジュールから、データリソースの第１の部分およびデータリソースの第２の部分に対する少額支払いプールからキャッシャへの第２の支払い額の第２の振込みを備える第２のオフチェーン取引を受け取らせ、少額支払いプールからの第２の支払い額を請求するために、第２のオフチェーン取引をブロックチェーンに提示させる。

【0016】

１つの実施形態において、プログラムコードは、プロセッサによって実行されると、プロセッサに更に、データリソースを少なくとも２人の視聴者と共有するためにピアグループに加入させ、第１の視聴者および第２の視聴者とのデータリソースの共有を認可する支払い許認可証を受け取らせる。

【0017】

１つの実施形態において、プログラムコードは、プロセッサによって実行されると、プロセッサに更に、支払い許認可証を支払いサービスモジュールに提示させる。

【0018】

１つの実施形態において、ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる。１つの実施形態において、ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックでブロックチェーンを検証するために監視者ノードを用い、チェックポイントブロックは、ブロックチェーン内のブロックのサブセットである。

【0019】

１つの実施形態において、通知は、積立て取引が新たなブロックに含まれた後の積立て取引のマークルプルーフを備える。

【0020】

１つの実施形態において、少額支払いプールは、データリソースのリソースＩＤ、時限錠、および削除可能な担保に関連付けられる。

【0021】

また他の態様によると、本発明のまた他の実施形態は、少なくとも２人の視聴者とデータリソースを共有する対価として支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るためにキャッシャによって用いられるプログラムコードを格納するための非一時的格納媒体であり、プログラムコードはプロセッサによって実行可能であり、プロセッサによって実行されると、プロセッサに、本明細書で説明されるステップを実行させる。

【0022】

本発明のまた他の態様は、本明細書で説明されるステップを備える方法、プロセス、およびアルゴリズムを含み、本明細書で説明されるシステムおよびサーバの動作プロセスおよび動作モードも含む。本発明の他の態様および実施形態は、添付図面と併せて詳細な説明を読むことにより明らかになる。

【0023】

本明細書で説明される本発明の実施形態は典型例であり、限定的ではない。実施形態は、以下、例として添付図面を参照して説明される。

【図面の簡単な説明】

【0024】

【図1】従来のコンテンツ配信ネットワーク（ＣＤＮ）を示すネットワーク図である。

【図2】従来のピアツーピアストリーミングネットワークのネットワーク図である。

【図3】本発明の１つの実施形態に係る、ピアツーピアネットワークと従来のＣＤＮとを組み合わせたハイブリッドネットワークアーキテクチャを示すネットワーク図である。

【図4A】本発明の１つの実施形態に係る、スマートトラッカおよび支払いサーバを有する非集中型データストリーミングおよび配信ネットワーク（「ハイブリッドネットワーク」）を示す典型的なネットワーク図である。

【図4B】本発明の実施形態に係る、ハイブリッドネットワークにおける個々のノード間の典型的なインタラクションを示す。

【図5】本発明の１つの実施形態に係る、非集中型データストリーミングおよび配信フレームワークの様々な構成要素を示すソフトウェアアーキテクチャモデル図である。

【図6】本発明の典型的な実施形態に係る、視聴者またはキャッシングノードを実装するためのユーザコンピューティングエンティティの典型的な概略図である。

【図7】本発明の典型的な実施形態に係る、サーバを実装するための管理コンピューティングエンティティの典型的な概略図である。

【図8】本発明のいくつかの実施形態に係る、視聴者が多数のエッジキャッシャにオフチェーン支払いを行う様子を示す、リソース指向少額支払いプールを介した取引を示す図である。

【図9】本発明のいくつかの実施形態に係る、エッジキャッシャが多数の視聴者からのオフチェーン支払いを受け取る様子を示す、コンテンツ配信源によって確立されたリソース指向少額支払いプールを介した取引を示す別の図である。

【発明を実施するための形態】

【0025】

以下の記述において、説明を目的として、本発明の完全な理解を提供するために数々の具体的な詳細が記載される。ただし、当業者には、本発明がこれらの具体的な詳細を伴わずとも実施され得ることが明らかである。他の例において、本発明を不明瞭にしないために、略図、使用事例、および／またはフロー図を用いて構造、デバイス、動作、および方法が示される。以下の記述は、例示のために多くの詳細を含むが、当業者は、提示された詳細に対する多くの変形例および／または変更例が本発明の範囲内であることを理解する。同様に、本発明の特徴の多くは、互いの観点から、または互いに関連して説明されるが、当業者は、これらの特徴の多くが他の特徴とは無関係に提供され得ることを理解する。したがって、本発明に関する本説明は、一般性を損なうことなく、かつ本発明に制限を課すことなく記載される。

【0026】

ＴＨＥＴＡは、本発明の実施形態をもたらす商標名であるため、本発明の実施形態によって提供される製品／サービスを指すために本明細書および図面において、上記の商標名が同義的に用いられ得る。ＴＨＥＴＡという用語は、本明細書において、非集中型データストリーミングネットワークまたはプラットフォーム全体、帯域幅使用またはデータコンテンツ共有の支払いのための公開台帳システム、ならびに上記ネットワーク、プラットフォーム、またはサービスを提供する企業を表すために用いられ得る。以下、図面を参照して、本発明の実施形態が詳しく説明される。
概観

【0027】

本発明の実施形態は、概して、分散型ハイブリッドネットワークを介したブロックチェーンインセンティブ方式の非集中型データストリーミングおよび配信のための超高取引スループット少額支払いを容易にするリソース指向のオフチェーン少額支払いプールのための方法およびシステムに関する。特に、本発明の実施形態は、専用の支払いチャネルまたは支払いルート指定ネットワークを設定する必要なく、多数の関係者間でのブロックチェーンに基づく暗号通貨少額支払いを可能にする。１人の受信者から多数の発信者への（「１対多数」）、また多数の受信者から１人の発信者への（「多数対１」）オフチェーン取引が、プライバシーや安全性を損なうことなく、また暗号通貨の二重使用特性をもたらさず、通常のブロック確認レイテンシを伴わずに集計され、後にブロックチェーンにコミットされる。

【0028】

本発明の様々な実施形態は、多くの場合、厳格な準リアルタイムパラメータの下でのデータコンテンツのタイムリーな配信に焦点を当てる非集中型ピアツーピアデータコンテンツ配信システムおよびプラットフォームに適用可能であるが、これに限定されない。ピアノードは、エンドユーザとして、かつ付近のピアにデータコンテンツを調達するキャッシング中継器として機能してよく、地理的に近くにあるピアソースが存在しない場合しか中央コンテンツサーバへの接続は利用可能ではない。余分な帯域幅およびストレージリソースを共有するためのキャッシングノードに加入するようにエンドユーザにインセンティブを与え、コンテンツプラットフォームおよびコンテンツ作成者との積極的な関与を促すために、新規的な非集中型公開台帳システム（以下、「ＴＨＥＴＡブロックチェーン台帳システム」または「ＴＨＥＴＡブロックチェーン」）が開示され、ここでは、データコンテンツのキャッシングおよびピアノードへの中継に対する報酬または補償を非常に微細な粒度で推進することができ、コンテンツ配信コストを軽減しながら新たな収益を得るためのコンテンツプラットフォームおよび広告主へのサポートが可能である。

【0029】

具体的には、本発明の実施形態は、最初にＴＨＥＴＡブロックチェーン上に少額支払いプールを確立し、データコンテンツを共有するために選択されたピアグループを認可し、共有された各データチャンクに関するサービス受領書を配布し、その後、ＴＨＥＴＡブロックチェーンに支払い取引を提示するために個々のサービス受領書を集計および累積することによって、著しい検証、確認、または決済遅延を伴うことなく、大量の１対多数および多数対１の暗号通貨での少額支払いを容易にすることに関する。加えて、本発明のいくつかの実施形態は、二重使用を防止するための担保を取り入れ、二重使用者が得る正味価値が、いかなる状況下でも真に負であることが保証される。

【0030】

双方向支払いチャネルおよび／または中間取引所の複雑な設定を必要とする既存の支払いネットワークと比べて、本発明に係る台帳システムは、レイテンシおよび複雑性を著しく低減することによりサポート可能なスループットを桁違いに増幅させる新規的かつ発明的なソリューションを提供する。加えて、多くの少額支払い取引をオフチェーンに移動することにより、本発明の実施形態は、ブロックチェーンに格納される取引の数を減少させるため、台帳システムを維持するための記憶空間が低減する。

【0031】

以下、最初にピアツーピアコンテンツ配信のためのハイブリッドネットワークインフラが開示され、ハイブリッドネットワーク内の個々のノードのソフトウェアアーキテクチャが示される。次に、ＴＨＥＴＡブロックチェーン台帳システム、および少額支払いプールおよび少額支払い処理の設計が開示される。以下、例示のみを目的として典型的な実施形態においてビデオストリーミングが論じられるが、それによって本明細書に開示される方法、システム、およびデバイスの範囲が限定されることはなく、様々な信頼性およびレイテンシ要件を有する他のデータコンテンツ型の配信が可能である。
データストリーミングおよび配信のための分散型ハイブリッドネットワーク

【0032】

図１は、従来のコンテンツ配信ネットワーク（ＣＤＮ）１００を示すネットワーク図であり、個々の視聴者が、存在点（ＰＯＰ）データセンタを介してＣＤＮサーバと直接接続されている。視聴者ノードは、文字「Ｖ」で示される。図２は、従来のピアツーピアストリーミングネットワーク２００のネットワーク図である。本明細書に開示する典型的な実施形態において、視聴者は、たとえばビデオおよびオーディオデータストリームなどのデータコンテンツを受信し消費するエンドユーザを表している。

【0033】

ピアツーピア（Ｐ２Ｐ）ストリーミングは、多くの場合、厳格な準リアルタイムパラメータの下、オーディオおよびビデオコンテンツのタイムリーな配信に焦点を当てる。Ｐ２Ｐライブストリーム配信は、多くの人々が同じ時間に同じストリームに波長を合わせる時に最適に機能する。同時ユーザ接続数が多いほど、多くのピアリングリソースが利用可能であることを意味し、ピアノードは、高効率で互いにデータストリームを引き出すことができる。より多くのピアノードが利用可能になることにより、システム全体の性能が高くなる。また、ノードがコンテンツを取得するために集中サーバに頼る必要がないことにより、従来のＣＤＮと比べて、Ｐ２Ｐネットワークにおけるシステムの堅牢性は高い。これは、特にサーバ障害の場合に重要である。一方、図１に示すような集中型ＣＤＮベース配信の場合、多数の同時ユーザによってＣＤＮサーバにスケーラビリティ負荷がかかる。

【0034】

純粋なＰ２Ｐストリーミングの欠点の１つは可用性である。ピアが常時行き来することにより、任意の所与のピアノードの可用性を予測することが困難である。また、たとえばアップロードおよびダウンロード容量など、ノードに固有の差および非対称性も存在する。一方、ＣＤＮサービスは、信頼性および堅牢性が高いことにより、要求したデータがピアノードから利用可能ではない場合、信頼性の高い「バックアップ」として役立ち得る。

【0035】

Ｐ２ＰネットワークおよびＣＤＮネットワークの両方の利点を取り入れることにより、図３は、本発明の１つの実施形態に係る、２つを組み合わせた非集中型データ配信「ハイブリッドネットワーク」のネットワーク図３００を示す。ネットワーク３００において、視聴者（「Ｖ」）およびエッジキャッシャ（「ＥＣ」）の間のピアツーピア接続は、それ自体が１または複数の存在点（「ＰＯＰ」）サーバを備える既存のＣＤＮの上で動作する。本開示において、視聴者は、配信データを消費するネットワークノードであり、エッジキャッシャは、データをキャッシュおよび／または近隣のピアノードに中継する中間中継点である。図３において個々のノードが視聴者またはエッジキャッシャのいずれかとして示されるが、ノードは、同時に視聴者およびエッジキャッシャノードの両方であってもよい。たとえば、ネットワークの端にある視聴者３０１と３０３との間の破線は、データリンクを表し、これを介して、ノード３０１および３０３がキャッシュデータを互いに送信してよい。

【0036】

ハイブリッドメッシュストリーミングは、データ配信のためのＰ２Ｐノード（ＶおよびＥＣ）と１または複数のＣＤＮサーバとの両方を用いることにより、両方の利点、すなわちＰ２Ｐインフラの高いスケーラビリティならびにＣＤＮ配信バックボーンの高い可用性を兼ね備える。このハイブリッドシステムの１つの目的は、たとえばＮＥＴＦＬＩＸ、ＹＯＵＴＵＢＥ、ＴＷＩＴＣＨ、ＦＡＣＥＢＯＯＫなどの確立されたストリーミングプラットフォームに不可欠なサービス品質（ＱｏＳ）を損なうことなく、最大ＣＤＮ帯域幅の低減を実現することである。図１に示す従来のＣＤＮ１００において、全てのノードがＰＯＰサーバから直接データストリームを引き出す。ハイブリッドネットワーク３００において、ピアノードは、可能であればいつでも、ＰＯＰサーバではなく互いからデータを引き出してよい。すなわち、ノードのサブセットがＰＯＰサーバからデータストリームを引き出すだけで、他のノードは、より良好かつ高効率な接続を提供する自身のピアキャッシングノードからデータストリームを容易に引き出せる。このように、キャッシングノードは、ＣＤＮバックボーンのＰＯＰから地理的に離れたエンド視聴者のために多くのキャッシング層で従来のＣＤＮバックボーンを増強する。このハイブリッドアーキテクチャは、ビデオオンデマンドおよびライブストリーミングの両方の状況、ならびに他のデータストリーミングおよび配信環境にも適用される。

【0037】

具体的には、図４Ａは、本発明の１つの実施形態に係る、非集中型ハイブリッドネットワーク４００を示す典型的なネットワーク図である。この典型的な例において、ハイブリッドネットワーク４００は、ＣＤＮサーバまたはバックボーン４０２、視聴者ノード４０４、４０６、および４０８、エッジキャッシャ４１２、スマートトラッカ４１４、および支払いサーバ４４０を備える。視聴者４０４、４０６、および４０８、およびエッジキャッシャ４１２は、各々がＣＤＮ４０２に直接、場合によってはＰＯＰサーバ（不図示）を介して接続され、視聴者４０４および４０６は直接接続され、視聴者４０６および４０８も直接接続され、両者がエッジキャッシャ４１２にリンクされる。このハイブリッド構造において、視聴者ノードは、まずピアからデータを引き出すことを試み、耐障害性バックアップとしてのみＣＤＮ４０２からのダウンロードに頼る。専用エッジキャッシャ４１２に加えて、各視聴者ノードもエッジキャッシャとして機能し得る。

【0038】

上述したように、Ｐ２Ｐストリーミングは、厳格な準リアルタイムパラメータの下でのデータコンテンツのタイムリーな配信に焦点を当てるが、従来のＣＤＮアーキテクチャは、コンテンツの全世界的な可用性に焦点を当てる。ハイブリッドネットワーク４００は、たとえば４０４、４０６、および４０８などの複数のピアノードにコンテンツを提供する既存のＣＤＮの上位で動作するように設計される。簡略化のために１つのＣＤＮサーバ４０２しか示されないが、ハイブリッドネットワーク４００は、複数のＣＤＮサーバと動作してよい。ハイブリッドネットワーク４００は、十分なデータ量を有するネットワーク内で十分な数のピアノードが動作している場合、ＣＤＮサーバ４０２とは無関係に動作してもよい。

【0039】

様々な実施形態において、ハイブリッドネットワーク４００は、以下に限定されないがたとえばライブストリームマルチメディアデータ、ビデオオンデマンド（ＶｏＤ）、大きな静的データファイル、たとえばデータブロブ、システムアップデート、ゲームパッチ、広告などの様々な種類のデータコンテンツおよびファイルの送信をサポートし、ピアノードまたは視聴者ノード４０４、４０６、および４０８によってアクセスおよび共有され得る。一例において、様々な種類のデータは全てファイルと見なすことができ、各ファイルが小さな断片に分割され得る。ハイブリッドネットワーク４００は、ファイル全体ではなく断片を格納してよい。ライブストリームは、同時に生成およびストリーミングされるファイルと見なされ得る。一例において、視聴者およびエッジキャッシャは、Ｗｅｂ ＲＴＣ（リアルタイム通信）ＨＴＴＰ／ＨＴＴＰＳプロトコルをサポートしてよい。

【0040】

したがって、ピアノード４０４、４０６、および４０８は、様々なデータコンテンツ型を処理することが可能な様々な種類の視聴者および／またはエッジキャッシャクライアントを含んでよい。図４Ａは、エッジキャッシャ４１２を視聴者ノード４０４、４０６、および４０８と別のものとして示すが、ピアノード４０４、４０６、および４０８の１または複数は、たとえば４０４ａ、４０６ａ、および４０８ａなどのＴＨＥＴＡソフトウェア開発キット（ＳＤＫ）を用いてエッジキャッシャおよびエンドユーザソフトウェアを同時に実装してよく、視聴者は、コンテンツを消費しながらコンテンツを格納し、Ｐ２Ｐ接続を介して配信してよい。たとえばビデオプレーヤなどの専売コンテンツビューアのインストールを必要とする一部のストリーミングサービスとは異なり、ＴＨＥＴＡ ＳＤＫは、第三者アプリケーションまたはデバイスに統合され得るので、ピアノードによってアクセスされたデータコンテンツは、第三者アプリケーション内で視聴または再生され得る。ソフトウェア開発キット（ＳＤＫ）は、特定のプラットフォームのためのアプリケーションを作成するためのソフトウェア開発ツールまたはプログラミングパッケージのセットである。ＳＤＫは、専用インタフェースおよび機能を提供するために開発されたアプリケーションの一部としてコンパイルされ得る。あるいは、ＳＤＫは、ソースコードにアクセスすることなくアプリケーションに特定の機能を追加するために、プラグイン、アドオン、または拡張として既存のアプリケーションまたはプレーヤに組み込むことが可能な、個別にコンパイルされたモジュールであってよい。

【0041】

様々な実施形態において、ピアノード４０４、４０６、および４０８は、各々が、異なる機能を可能にする異なる種類のクライアントソフトウェアを実装してよい。エッジキャッシャを実装するピアノード４１２は、配信されるコンテンツの断片または断片内のスライスを格納してよい。スライスは、必要に応じて要求側ピアに送信され得る。エッジキャッシャ４１２として機能するピアノードは、メモリおよびハードドライブという２つのローカルキャッシュ層を有するものとして示され得る。そのようなピアノード４１２は、要求されたコンテンツを取得するために、最初にメモリがアクセスされ、次にハードドライブがアクセスされ得るという統一されたキャッシュ探索手順を実施してよい。ただし、一部のクライアントはハードドライブストレージを有さない場合（たとえばモバイルフォンなど）があり、この場合、エッジキャッシャ４１２は、単一のローカルキャッシュとして実装され得る。したがって、ハードドライブを有するデバイスも有さないデバイスもハイブリッドネットワーク４００内のエッジキャッシャノードとしての役割を果たし得るように、抽象化されたキャッシュインタフェースが可能にされ得る。そのようなノードは、メモリ内に格納されたライブストリームおよび同時ＶｏＤを共有するために用いられ得る。パッチ更新の場合、パッチ更新がハードドライブに格納されるので、一般にハードドライブが必要である。

【0042】

ハイブリッドネットワーク４００によってサポートされる様々なコンテンツの種類は、異なる遅延またはレイテンシ要件を有し得る。たとえば、ライブストリームは、リアルタイムまたは準リアルタイム配信を必要とし、ＶｏＤは、ユーザが現在視聴している部分に関してリアルタイム配信を必要とし得る。データブロブは、リアルタイムサポートを必要としないが、その場合でも、ダウンロード時間が最小限にされる必要がある。大きなファイルの中継または伝搬をサポートするために、ハイブリッドネットワーク４００において、コンテンツの断片が更に小さなスライスに分割され、スライスのみが要求および送信される「レンジ要求」がサポートされ得る。たとえば、ＣＤＮサーバ４０２は、データブロブが大きなファイル全体として提供され得る場合でも、レンジ要求をサポートしてよい。

【0043】

ハイブリッドネットワーク４００は、更に、ハイブリッドネットワーク４００内のコンテンツの格納および消費を管理するための１または複数のスマートトラッカ４１４を含む。スマートトラッカ４１４は、データの格納および配信においてエッジキャッシャ４１２を案内する知能を提供し、無限の数のライブストリーム、ＶｏＤデータ、またはデータブロブを同時に処理し得る。スマートトラッカ４１４は、図４Ｂに関連して詳しく説明するように、シグナリングサービス４６２およびディスカバリサービス４６４を備えるマイクロサービスアーキテクチャで実装され得る。

【0044】

スマートトラッカ４１４に案内されることにより、キャッシャノード（エッジキャッシャおよび視聴者）は、それらの地理的位置に基づいて準ランダムに接続されたネットワークに自己組織化してよい。例において、物理的距離が推定され、特定の閾値距離内のノードが、それらの地理的位置に基づいてネットワークに分類され得る。たとえば、図４Ｂは、本発明の実施形態に係る、地理的位置および他の要因に基づいてキャッシャノード間でデータブロブ／断片を配信するためのスマートトラッカ／ディスカバリサービスの図を示す。

【0045】

また、図４Ａに示すピアノードは、データコンテンツがファイルまたはファイルセグメントとして配信される時の視聴者４０４、４０６、および４０８とエッジキャッシャ４１２との間の支払い取引を促進および管理する支払いサーバ４４０に通信可能に結合され得る。支払いサーバ４４０の１または複数の例は、専用ネットワークノードとしてハイブリッドネットワーク４００内に実装され、または、たとえばＣＤＮサーバ４０２、スマートトラッカ４１４、またはハイブリッドネットワーク４００内の任意のピアノードなどの他のネットワークノードと物理的に同位置にあってよい。たとえば、支払いサーバ４４０はスマートトラッカ４１４と同位置にあってよく、各々がソフトウェアモジュールとして実装される。スマートトラッカ４１４は、たとえば地理的距離およびリソース可用性などの要因に基づいてピアノード間のＰ２Ｐ接続を決定する一方、支払い認可グループを決定してもよく、その場合、グループのメンバのみが、Ｐ２Ｐコンテンツ配信への関与に関する支払いをやり取りしてよい。様々な実施形態において、支払いサーバ４４０は、独立型支払いサービスソフトウェアモジュールとして、またはＴＨＥＴＡ ＳＤＫの一部として実装され得る。図４Ａに示す典型的な実施形態において、ピアノード４０４、４０６、４０８、および４１２は、各々が支払いサーバ４４０に個々に接続される。また、いくつかの実施形態において、支払いサーバ４４０は、コンテンツ配信プラットフォームに所有されるソースＣＤＮおよびエンドユーザ視聴者またはキャッシングノードとは別の第三者によって提供されてよく、他のいくつかの実施形態において、コンテンツ配信プラットフォーム自体が支払いサーバ４４０を運営してよい。

【0046】

図４Ｂは、本発明のいくつかの実施形態に係る、たとえばハイブリッドネットワーク４００などのハイブリッドネットワークにおける個々のノード間の典型的なインタラクションを示す。このネットワーク図４５０において、ネットワークエンティティの典型的な機能が示される。ピアノード４０６、４０８、および４１２の各々は、スマートトラッカ４１４によって提供されるシグナリングサービス４６２およびディスカバリサービス４６４に接続される。シグナリングサービス４６２は、たとえばウェブＲＴＣ規格に基づくＪａｖａＳｃｒｉｐｔセッション確立プロトコル（ＪＳＥＰ）を介して、視聴者４０８と視聴者／エッジキャッシャ４０６および４１２との間のハンドシェイクをもたらす。ディスカバリサービス４６４は、以下に限定されないがたとえば地理的位置、ファイル型またはコンテンツ型、インターネットプロトコル（ＩＰ）アドレスなどの様々なピア属性に基づいて、互いに接続されるピアを決定する。

【0047】

ハイブリッドネットワーク上のコンテンツにアクセスするために、視聴者４０８は最初に、コンテンツにアクセスするためにハイブリッドネットワーク内で用いられる自身のＩＤの割当てに関するＩＤ要求４７１を、たとえばＨＴＴＰ要求を介してシグナリングサービス４６２に送信してよい。シグナリングサービス４６２は、アクティブなピアノードを追跡し、視聴者４０８に割り当てられたＩＤ４７７で応答してよい。その後、視聴者４０８は、たとえば自身のＩＰアドレス、自身の地理的位置、および要求されるファイルの種類などの他の属性を伴うＩＤ４７７、および要求されたコンテンツを提供し得る近隣のピアノードのピアリスト４７２に関する要求を送信する。ディスカバリサービス４６４は、その後、提供されたＩＰアドレス、地理的位置、要求されたファイルの種類など４７３に基づいて、スマートトラッカ４１４のデータベース４６８からピアリストにアクセスしてよい。その後、ディスカバリサービス４６４は、この例においてどちらもエッジキャッシャノードの役割を果たす、たとえば視聴者４０６および視聴者４１２などの１または複数のピアノードを備えるピアリスト４７４を選択および返信してよく、視聴者４０８は、要求されたコンテンツにアクセスするためにこれに接続してよい。

【0048】

この実施形態において、シグナリングサービス４６２およびディスカバリサービス４６４は、同じスマートトラッカ４１４内で同位置にある。視聴者４０８のＩＤ４７７は、シグナリングサービス４６２によってディスカバリサービス４６４に直接伝達されてよく、ディスカバリサービス４６４は、選択されたピアノードリスト４７４およびＩＤ４７７で視聴者４０８に応答してよい。いくつかの実施形態において、ディスカバリサービス４６４は、ピアリスト４７４内の選択されたピアノードの属性、たとえば視聴者４０６および視聴者４１２の属性、たとえばそれらのＩＰアドレスなどを送信してよく、それによって視聴者４０８は、ピアキャッシャノード４０６および４１２に、それらの対応するＩＰアドレスでコンテンツ／スライス要求を送信し得る。このように、視聴者４０８は、ＩＤ４７７を用いて、コンテンツを受信するために視聴者４０６および／または視聴者４１２と直接的にチャネルを開くために必要な情報を得る。ピアノード間のデータチャネルは、データ共有／中継動作が完了するまで持続してよい。加えて、個々のコンテンツ断片またはスライスに関する少額支払いを含む、視聴者４０８とエッジキャッシャ４０６および４１２との間の支払い取引は全て、支払いサーバ４４０によって処理され得る。

【0049】

この典型的な実施形態において、各ピアノード４０６、４０８、および４１２、ならびに支払いサーバ４４０は、公開ブロックチェーン台帳４９０、すなわちＴＨＥＴＡブロックチェーンへのアクセスを有する。ＴＨＥＴＡブロックチェーンは、ハイブリッドネットワーク内のエッジキャッシャに対し暗号通貨インセンティブ形式でＴＨＥＴＡトークンを提供する。ＴＨＥＴＡブロックチェーンの更なる詳細は、図８および図９を参照して開示される。

【0050】

いくつかの実施形態において、各エッジキャッシャは、スタッツサービス、信頼性サービス、および私的アプリケーションプログラミングインタフェース（ＡＰＩ）サービスを更に含んでよい。信頼性サービスは、ＣＤＮサーバ４０２が電子タグを提供しない場合に、各データ断片のハッシュを提供してよい。私的ＡＰＩサービスは、たとえば公開コンテンツ、構成変更、強制公開コンテンツなどの機能のために私的ＡＰＩへのアクセスを提供してよい。

【0051】

図５は、本発明のいくつかの実施形態に係る、非集中型データストリーミングおよび配信フレームワークの様々な層を示すソフトウェアアーキテクチャモデル図５００である。アプリケーション層５０２は、アプリケーションのユーザ予想と一致するアプリケーションレベルのプログラム論理を実装するユーザインタフェース（ＵＩ）およびプログラムコード、ハイブリッドネットワーク４００を構築するためのＴＨＥＴＡ ＪａｖａＳｃｒｉｐｔメッシュストリーミングライブラリ、および既存の視聴者／プレーヤ／デバイスにアプリケーションを統合するために用いられるＴＨＥＴＡ ＳＤＫを備えてよい。

【0052】

暗号通貨経済インフラ５０４は、たとえば４０２、４０６、４０８、および４１２などの視聴者およびエッジキャッシャ間の支払いを容易にする支払いサーバ４４０を含む、ハイブリッドネットワーク４００における支払いプロセスの実装を包括する。ＡＰＩ／ライブラリのセットは、暗号通貨ウォレットを構築するために開発者に提供されてよく、クライアント側およびサーバ側のソフトウェアインフラを含む。ＷｅｂＲＴＣに基づくデスクトップクライアントを構築するためにキャッシャソフトウェア／ライブラリも提供され得る。

【0053】

ＴＨＥＴＡプロトコル層５０６は、配信プロトコル５０８および台帳プロトコル５１０を備える。配信プロトコル５０８は、ハイブリッドネットワーク４００内のピア４０４、４０６、４０８、および４１２間でストリーミング方法／帯域幅共有手順を決定するスマートトラッカサーバをサポートしてよい。台帳プロトコル５１０は、コンセンサスメカニズム、オンチェーンおよびオフチェーン取引の構成および処理規則、およびＴＨＥＴＡブロックチェーンに基づく台帳システムを定義する他の通信および暗号プロトコルを備えてよい。
コンピュータプログラム製品、方法、およびコンピューティングエンティティを用いた実装
典型的なシステムアーキテクチャ

【0054】

本開示の典型的な実施形態は、図６および図７に示すように、１または複数のエンドユーザコンピューティングエンティティ６００、１または複数のネットワーク、および１または複数のＣＤＮ、トラッカサーバ、支払いサーバ、または他の管理コンピューティングエンティティ７００を含んでよい。これらの構成要素、エンティティ、デバイス、システム、および本明細書で同義的に用いられる同様の言葉の各々は、たとえば同じまたは異なる有線または無線ネットワークを介して互いに直接または間接的に通信状態であってよい。また、図６および図７は、様々なシステムエンティティを個別の独立型エンティティとして示すが、様々な実施形態は、この特定のアーキテクチャに限定されない。
典型的なユーザコンピューティングエンティティ

【0055】

図６は、本発明の典型的な実施形態に係る、視聴者ノードまたはキャッシャノードを実装するためのエンドユーザコンピューティングデバイスの典型的な概略図である。ストリームビデオを視聴またはキャッシュすることが可能なエンドユーザコンピューティングデバイス６００は、図示するように１または複数の構成要素を含む。認識されるように、これらのアーキテクチャおよび説明は例示の目的で提供されただけであり、様々な実施形態を限定するものではない。

【0056】

一般に、デバイス、システム、コンピューティングエンティティ、エンティティという用語および／または本明細書で同義的に用いられる同様の言葉は、たとえば１または複数のコンピュータ、コンピューティングエンティティ、デスクトップ、モバイルフォン、タブレット、ファブレット、ノートブック、ラップトップ、分散型システム、ゲーム機（たとえばＸｂｏｘ、プレイステーション、Ｗｉｉ）、時計、眼鏡、キーフォブ、無線周波数識別（ＲＦＩＤ）タグ、イヤピース、スキャナ、カメラ、リストバンド、キオスク、入力端末、サーバまたはサーバネットワーク、ブレード、ゲートウェイ、スイッチ、処理デバイス、処理エンティティ、セットトップボックス、中継器、ルータ、ネットワークアクセスポイント、基地局など、および／または本明細書で説明する機能、動作、および／またはプロセスを行うように適合されたデバイスまたはエンティティの任意の組み合わせを指してよい。そのような機能、動作、および／またはプロセスは、たとえば送信、受信、取得、操作、処理、表示、格納、決定、作成、生成、監視、評価、比較、および／または本明細書で同義的に用いられる同様の用語を含んでよい。様々な実施形態において、これらの機能、動作、および／またはプロセスは、データ、コンテンツ、情報、および／または本明細書で同義的に用いられる同様の用語に行われ得る。一方、コンテンツ、トラッカ、または支払いサーバは、場合によってはクラウド内で、場合によっては論理的または物理的に分散したアーキテクチャで、図７に示す典型的な概略図に従って実装され得る。

【0057】

図６に示すように、ユーザコンピューティングエンティティ６００は、アンテナ６７０、無線トランシーバ６２０、およびトランシーバに信号を提供しトランシーバからの信号を受信する処理ユニット６１０を含んでよい。トランシーバに提供されトランシーバから受信される信号は、適切な無線システムのエアインタフェース規格に準拠するシグナリング情報を含んでよい。この点に関して、ユーザコンピューティングエンティティ６００は、１または複数のエアインタフェース規格、通信プロトコル、変調型、およびアクセス型で動作することが可能であってよい。具体的には、ユーザコンピューティングエンティティ６００は、複数の無線通信規格およびプロトコルのいずれかに従って動作してよい。いくつかの実施形態において、ユーザコンピューティングエンティティ６００は、たとえば５Ｇ、ＵＭＴＳ、ＦＤＭ、ＯＦＤＭ、ＴＤＭ、ＴＤＭＡ、Ｅ－ＴＤＭＡ、ＧＲＰＳ、拡張ＧＰＲＳ、ＣＤＭＡ、ＣＤＭＡ２０００、１ｘＲＴＴ、ＷＣＤＭＡ、ＴＤ－ＳＣＤＭＡ、ＧＳＭ、ＬＴＥ、ＬＴＥアドバンスド、ＥＤＧＥ、Ｅ－ＵＴＲＡＮ、ＥＶＤＯ、ＨＳＰＡ、ＨＳＤＰＡ、ＭＤＭ、ＤＭＴ、Ｗｉ－Ｆｉ、Ｗｉ－Ｆｉダイレクト、ＷｉＭＡＸ、ＵＷＢ、ＩＲ、ＮＦＣ、ＺｉｇＢｅｅ、Ｗｉｂｒｅｅ、Ｂｌｕｅｔｏｏｔｈなどの多数の無線通信規格およびプロトコルに従って動作してよい。同様に、ユーザコンピューティングエンティティ６００は、ネットワークおよび通信インタフェース６２２を介して、多数の有線通信規格およびプロトコルに従って動作してよい。

【0058】

これらの通信規格およびプロトコルを介して、ユーザコンピューティングエンティティ６００は、たとえば非構造付加サービスデータ（ＵＳＳＤ）、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、デュアルトーン多重周波数シグナリング（ＤＴＭＦ）、および／または加入者識別モジュールダイヤラ（ＳＩＭダイヤラ）などの概念を用いて様々な他のコンピューティングエンティティと通信し得る。ユーザコンピューティングエンティティ６００は、たとえば自身のファームウェア、（たとえば実行可能命令、アプリケーション、プログラムモジュールを含む）ソフトウェア、およびオペレーティングシステムに、変更、アドオン、および更新をダウンロードすることもできる。

【0059】

いくつかの実装において、処理ユニット６１０は、いくつかの様々な方法で具体化され得る。たとえば、処理ユニット６１０は、１または複数の複合プログラマブル論理デバイス（ＣＰＬＤ）、マイクロプロセッサ、マルチコアプロセッサ、コプロセッシングエンティティ、特定用途向け命令セットプロセッサ（ＡＳＩＰ）、マイクロコントローラ、および／またはコントローラとして具体化され得る。また、処理ユニットは、１または複数の他の処理デバイスまたは回路として具体化され得る。回路という用語は、全体がハードウェアの実施形態、またはハードウェアおよびコンピュータプログラム製品の組み合わせを指してよい。したがって、処理ユニット６１０は、集積回路、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）、ハードウェアアクセラレータ、他の回路などとして具体化され得る。よって、理解されるように、処理ユニット６１０は、特定の用途のために構成されてよく、または揮発性または不揮発性媒体に格納された、または他の方法で処理ユニットにアクセス可能な命令を実行するように構成され得る。このように、ハードウェアまたはコンピュータプログラム製品で構成されるか、その組み合わせで構成されるかにかかわらず、処理ユニット６１０は、適宜構成されると本発明の実施形態に係るステップまたは動作を行うことが可能であってよい。

【0060】

いくつかの実施形態において、処理ユニット６１０は、制御ユニット６１２と、算術および論理演算を行うための専用算術論理ユニット６１４（ＡＬＵ）とを備えてよい。いくつかの実施形態において、ユーザコンピューティングエンティティ６００は、任意選択的に、専門的な画像およびビデオレンダリングタスクのためのグラフィック処理ユニット６４０（ＧＰＵ）、および／または人工ニューラルネットワーク、機械ビジョン、および機械学習を含むアプリケーションに特化した人工知能（ＡＩ）アクセラレータ６４２を備えてよい。いくつかの実施形態において、処理ユニット６１０は、処理タスクを分散および調整するためにＧＰＵ６４０および／またはＡＩアクセラレータ６４２と結合され得る。

【0061】

いくつかの実施形態において、ユーザコンピューティングエンティティ６００は、各々が処理ユニット６１０に結合された入力インタフェース６５０および出力インタフェース６５２を備えるユーザインタフェースを含んでよい。ユーザ入力インタフェース６５０は、たとえばキーパッド（ハードまたはソフト）、タッチディスプレイ、音声／発語のためのマイク、および動作および姿勢インタフェース用のカメラなど、ユーザコンピューティングエンティティ６００がデータを受信することを可能にする複数のデバイスまたはインタフェースのいずれかを備えてよい。ユーザ出力インタフェース６５２は、たとえばタッチディスプレイまたはオーディオ出力用のスピーカなどを介してユーザコンピューティングエンティティ６００がユーザにコンテンツおよび情報を提供することを可能にする複数のデバイスまたはインタフェースのいずれかを備えてよい。いくつかの実施形態において、出力インタフェース６５２は、オーディオまたはビジュアル出力のために外部拡声器またはプロジェクタにユーザコンピューティングエンティティ６００を接続してよい。

【0062】

ユーザコンピューティングエンティティ６００は、埋込型および／または取外し可能であってよい揮発性および／または不揮発性ストレージまたはメモリ６３０も含んでよい。不揮発性メモリは、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、ＭＭＣ、ＳＤメモリカード、メモリスティック、ＣＢＲＡＭ、ＰＲＡＭ、ＦｅＲＡＭ、ＮＶＲＡＭ、ＭＲＡＭ、ＲＲＡＭ、ＳＯＮＯＳ、ＦＪＧ ＲＡＭ、ミリピードメモリ、レーストラックメモリなどであってよい。揮発性メモリは、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ＦＰＭ ＤＲＡＭ、ＥＤＯ ＤＲＡＭ、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＤＤＲ２ ＳＤＲＡＭ、ＤＤＲ３ ＳＤＲＡＭ、ＲＤＲＡＭ、ＴＴＲＡＭ、Ｔ－ＲＡＭ、Ｚ－ＲＡＭ、ＲＩＭＭ、ＤＩＭＭ、ＳＩＭＭ、ＶＲＡＭ、キャッシュメモリ、レジスタメモリなどであってよい。揮発性および不揮発性ストレージまたはメモリは、ユーザコンピューティングエンティティ６００の機能を実装するためのオペレーティングシステム６１４、アプリケーションソフトウェア６１６、データ６１８、データベース、データベースインスタンス、データベース管理システム、プログラム、プログラムモジュール、ＳＤＫ、スクリプト、ソースコード、オブジェクトコード、バイトコード、コンパイル済みコード、解釈済みコード、機械コード、実行可能命令などを格納してよい。示したように、これは、エンティティに常駐する、または管理コンピューティングエンティティおよび／または様々な他のコンピューティングエンティティと通信するためにブラウザまたは他のユーザインタフェースを介してアクセス可能なユーザアプリケーションを含んでよい。

【0063】

いくつかの実施形態において、ユーザコンピューティングエンティティ６００は、位置を決定する態様、デバイス、モジュール、機能、および／または本明細書で同義的に用いられる同様の言葉を含んでよい。たとえば、ユーザコンピューティングエンティティ６００は、たとえば緯度、経度、標高、ジオコード、航路、方向、進路、速度、万国標準時（ＵＴＣ）、日付、および／または様々な他の情報／データを取得するように適合された、たとえば位置モジュールなどの屋外位置決め態様を含んでよい。１つの実施形態において、位置モジュールは、視野内の複数の衛星およびそれらの衛星の相対位置を識別することによって、場合によってはエフェメリスデータとして知られるデータを取得してよい。あるいは、位置情報は、セルラ塔、Ｗｉ－Ｆｉアクセスポイントなどを含む様々な他のシステムと接続しているユーザコンピューティングエンティティの位置を三角測量することによって決定され得る。同様に、ユーザコンピューティングエンティティ６００は、たとえば緯度、経度、標高、ジオコード、航路、方向、進路、速度、時間、日付、および／または様々な他の情報／データを取得するように適合された、たとえば位置モジュールなどの屋内位置決め態様を含んでよい。一部の屋内システムは、ＲＦＩＤタグ、屋内ビーコンまたは送信器、Ｗｉ－Ｆｉアクセスポイント、セルラ塔、付近のコンピューティングデバイス（たとえばスマートフォン、ラップトップ）などを含む様々な位置決めまたは位置特定技術を用いてよい。たとえば、そのような技術は、ｉＢｅａｃｏｎ、ジンバル近接ビーコン、Ｂｌｕｅｔｏｏｔｈ低エネルギ（ＢＬＥ）送信器、ＮＦＣ送信器などを含んでよい。これらの屋内位置決め態様は、インチまたはセンチメートル単位で人物または物体の位置を決定するために様々な設定で用いられ得る。このように得られた位置情報は、データ配信および取得のために付近のピアを決定する際に用いられ得る。

【0064】

いくつかの実施形態において、２人以上のユーザは、過去にリストされたネットワーキングプロトコルのいずれか、およびＢｉｔＴｏｒｒｅｎｔを含む、またはＴＨＥＴＡハイブリッドネットワークによって提供される任意のピアツーピアプロトコルを用いて、自身のコンピューティングデバイス間の接続を確立してよい。いくつかの実施形態において、ユーザコンピューティングデバイスは、送信、受信、操作、処理、表示、格納などをされ得るデータコンテンツ、情報、および／または本明細書で同義的に用いられる同様の用語を交換するために、たとえば６２２などのネットワークインタフェースを用いて他の様々なコンピューティングエンティティと通信してよい。

【0065】

いくつかの実施形態において、データ（たとえばオーディオ、ビデオなど）は、デバイスがたとえば無線アクセスポイントまたはホットスポットなどのネットワーク接続にアクセスすると、１または複数のユーザコンピューティングデバイスによって、たとえば図７に示すようなサーバにダウンロードされ得る。データ転送は、ファイル転送プロトコル（ＦＴＰ）、ＭＱテレメトリトランスポート（ＭＱＴＴ）、アドバンスドメッセージキューイングプロトコル（ＡＭＱＰ）、ハイパーテキスト伝送プロトコル（ＨＴＰＰ）、およびＨＴＰＰセキュア（ＨＴＴＰＳ）などのプロトコルを用いて行われ得る。これらのプロトコルは、トランスポート層セキュリティ（ＴＬＳ）および／またはセキュアソケット層（ＳＳＬ）を介して安全性が保たれ得る。
典型的な管理コンピューティングエンティティ

【0066】

図７は、本発明の典型的な実施形態に係る、ＴＨＥＴＡネットワークを実装するための、たとえばＣＤＮまたはトラッカサーバなどの管理コンピューティングエンティティ７００の典型的な概略図である。コンピューティングエンティティ、コンピュータ、エンティティ、デバイス、システムという用語、および／または本明細書で同義的に用いられる同様の言葉は、ユーザコンピューティングエンティティ６００に関して詳しく説明される。

【0067】

図示するように、１つの実施形態において、管理コンピューティングエンティティ７００は、たとえば送信、受信、操作、処理、表示、格納などをされ得るデータ、コンテンツ、情報、および／または本明細書で同義的に用いられる同様の用語を通信することによって、様々なコンピューティングエンティティと通信するための１または複数のネットワークまたは通信インタフェース７２０を含んでよい。たとえば、管理コンピューティングエンティティ７００は、ユーザコンピューティングデバイス６００および／または様々な他のコンピューティングエンティティと通信してよい。ネットワークまたは通信インタフェース７２０は、たとえば光ファイバ分散データインタフェース（ＦＤＤＩ）、デジタル加入者線（ＤＳＬ）、イーサネット、非同期転送モード（ＡＴＭ）、フレームリレー、ケーブルによるデータサービスインタフェース標準（ＤＯＣＳＩＳ）、または他の任意の有線伝送プロトコルなどの有線データ伝送プロトコルを用いてよい。同様に、管理コンピューティングエンティティ７００は、ユーザコンピューティングデバイス６００に関して説明したような様々な規格およびプロトコルのいずれかを用いる無線外部通信ネットワークを介して通信するように構成され得る。

【0068】

図７に示すように、１つの実施形態において、管理コンピューティングエンティティ７００は、管理コンピューティングエンティティ７００内の他の要素と通信する１または複数の処理ユニット７１０（プロセッサ、処理回路、処理要素、および／または本明細書で同義的に用いられる同様の用語）を含んでよく、またはそれと通信状態であってよい。理解されるように、処理ユニット７１０は、複数の様々な方法で具体化され得る。たとえば、集積回路、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）、ハードウェアアクセラレータ、他の回路などの形式の１または複数のＣＰＬＤ、マイクロプロセッサ、マルチコアプロセッサ、コプロセッシングエンティティ、ＡＳＩＰ、マイクロコントローラ、および／またはコントローラである。したがって、理解されるように、処理ユニット７１０は、特定の用途のために構成されてよく、または揮発性または不揮発性媒体７３０および７４０に格納された命令を実行するように構成され得る。よって、ハードウェアまたはコンピュータプログラム製品によって構成されるか、その組み合わせによって構成されるかにかかわらず、処理ユニット７１０は、適宜構成されると、本開示の実施形態に係るステップまたは動作を行うことが可能であってよい。

【0069】

明示されないが、管理コンピューティングエンティティ７００は、たとえばキーボード、マウス、タッチスクリーン／ディスプレイ、動作および移動入力のためのカメラ、オーディオ入力のためのマイク、ジョイスティックなどの１または複数の入力要素を含んでよく、またはそれと通信状態であってよい。管理コンピューティングエンティティ７００は、たとえばスピーカ、スクリーン／ディスプレイなどの１または複数の出力要素も含んでよく、またはそれと通信状態であってよい。

【0070】

様々な実施形態において、管理コンピューティングエンティティ７００の構成要素の１または複数は、たとえば分散型システム内またはクラウド内など、他の管理コンピューティングエンティティ構成要素から遠隔に位置してよい。また、構成要素の１または複数が結合されてよく、本明細書で説明される機能を行う追加の構成要素が管理コンピューティングエンティティ７００に含まれてもよい。
ＴＨＥＴＡブロックチェーンベースの台帳システム

【0071】

ピアノードに計算、帯域幅、およびストレージリソースの提供を促し、インセンティブを与えるために、キャッシングノードがビデオストリームを他の視聴者に中継することにより報酬を得る支払いまたは報酬システムが構成され得る。また、そのような支払いシステムは、広告主が視聴者に直接関与することを可能にすること、および新しい増加的な収入機会をストリーミングおよびコンテンツプラットフォームに提供することによって、ストリーミング市場の効率も大幅に向上させ得る。
ブロックチェーンベースの暗号通貨決済システム

【0072】

上述した報酬システムを推進するために従来の支払い処理ソリューションが考えられ得るが、非集中型データストリーミングおよび配信に自然に対応可能な、安全かつ遅延が最小限である代替案として、たとえばブロックチェーンに基づく非集中型で分散型の公開台帳支払いサービスシステムがある。ブロックチェーンは、暗号によってリンクされ、一般にノード間通信およびブロック検証のためのプロトコルを有するピアツーピアネットワークによって管理される公開取引記録、すなわちブロックのリストである。従来の支払いシステムは、信頼性を維持するために取引を証明および透明化するための中央機関を必要とするが、ブロックチェーン台帳システムは、そのような中央機関の無いグローバルな非集中型コンセンサスを実現する。ブロックチェーンは、取引データの変更がほぼ不可能だという点で不変の特性があり、上述した報酬システムにおける支払い方法として暗号通貨による使用に適している。

【0073】

具体的には、ブロックチェーンに基づく公開台帳システムは、非集中型で分散型の公開台帳、または取引データベースであり、公開取引記録または取引のリストがデータのブロックに書き込まれ、暗号によってリンクされる。取引は、１人のユーザから他のユーザへの価値の移転を符号化するデータ構造または記録である。取引はブロックにまとめられ、各ブロックは、マイニングと呼ばれる暗号計算プロセスによって、ブロックチェーンネットワークの全ノードが従うコンセンサス規則セットに基づいて検証される。ブロックチェーンは、一般に、各ピアがブロックチェーンの全体または部分コピーを維持するピアツーピア暗号通貨ネットワークを通して管理される。ブロックチェーンは、不変性を実現するために全ピア間の非集中型暗号コンセンサスに依拠しており、取引記録は、ブロックに書き込まれ、ブロックが検証されピアによって受諾されると、変更することができない。ブロックのマイニングおよび検証は、新たな取引がブロックチェーンに追加される度に必要な分散型コンセンサスプロセスにおける特定のステップを指す。

【0074】

ブロックチェーンに基づく暗号通貨支払いシステムは、中心的な信頼機関ではなく非集中型の信頼に基づくため、従来の銀行および支払いシステムとは基本的に異なる。すなわち、従来の不換通貨は多くの場合デジタルに格納および送信されるが、たとえば個々の金融機関や手形交換所などの中央機関を通して電子振込みまたは支払いを透明化し決済することによって、不正、二重使用、および他の問題や係争が防止される。それに対し、ブロックチェーンベースの暗号通貨支払いシステムは、第三者に依存することなく、取引の正当性または価値の請求を信頼するために暗号および分散型コンセンサスに依拠する。

【0075】

取引記録または取引は、取引に関与する様々なエンティティに対する借り方および貸し方と見なされ得る１または複数の入力および１または複数の出力を備えるデータ構造である。１つの取引の出力は、他の取引の入力として用いられる。ブロックチェーンに記録されたユーザの残高は、暗号鍵を介してユーザによって制御される、他の取引への入力としてまだ支払われていない全取引出力の集計である。ブロックチェーンは、公開台帳として、暗号通貨ネットワーク内の個々のピアノードによって全体または部分的に格納される。これは、１つの中央サーバまたは中央機関がユーザの口座残高を記録し、通貨の転送が生じる度にこの残高を更新する、従来の集中型で私的な口座に基づく支払いシステムとは非常に異なる。
分散型データ配信のためのＴＨＥＴＡブロックチェーンに基づく台帳システム

【0076】

視聴者がサブスクリプション形式またはペイパービュー方式で中央サーバに直接支払いをする集中型ビデオストリーミングプラットフォームとは異なり、各々がピアツーピアネットワーク内の多数の他のピアに小さなビデオデータセグメントを提供する多数のピアを補償するという代替案は、顕著なスケーリング問題を呈する。一般的なビデオセグメントは、わずか数秒の長さであり、そのような粒度で支払いをするために、１万人の同時視聴者というそれほど多くはない数のライブストリームの場合でも、毎秒何千もの取引が生じることがあり、これは現代の公開ブロックチェーンの最大スループットを大きく上回る。メジャーなｅスポーツトーナメントのように人気のあるライブストリームは、１つのストリームを同時に視聴する１００万人超過の視聴者を集めることがあり、まして複数の同時ライブストリームの場合、必要な取引スループットを更に毎秒数百万の範囲まで押し上げる可能性がある。

【0077】

上述した難点に対処するために、非集中型データストリーミングおよび配信のための新規的な非集中型公開台帳システムであるＴＨＥＴＡブロックチェーンに基づく台帳システムが提案および実装される。たとえば、図４Ｂに示すブロックチェーン４９０は、以下の３つの新規的設計に基づき、ＴＨＥＴＡプロトコルに準拠するＴＨＥＴＡトークンマイニングネットワークにおいて実装され得る。

【0078】

第１に、たとえば毎秒１，０００超過の取引範囲において非常に高い取引スループットをサポートしながらも、数千のノードがコンセンサスプロセスに関与することを可能にする、マルチレベルのビザンチン耐故障（ＢＦＴ）コンセンサスメカニズムが用いられる。データストリーミングアプリケーションは、一般に迅速なコンセンサスを必要とする。帯域幅共有報酬の場合、余分な帯域幅を提供するユーザは、一般に、次のデータセグメントを送信する前に支払いが確認されることを望む。取引確認の遅延を最小限にするために、ＴＨＥＴＡプロトコルは、ノードの小セットを用いて、実用的ＢＦＴ（ＰＢＦＴ）などのプロセスを用いて可能な限り高速でブロックチェーンを生成する検証者委員会を形成する。たとえば１０から２０のノードなどの十分な数の検証者により、検証者委員会は、敵対者がブロックチェーンの保全性を損なうことを防ぐ高い難度を維持しながら、高速でブロックを生成し得る。取引は、新たなブロックに含められると、「コミット」される。検証者委員会に加入する資格を持つために、ノードは、一定期間、特定の量のステークをロックアップしてよい。ロックされたステークは、悪意のある挙動が検出されると削除され得る。委員会がコンセンサスを得たブロックは、決済ブロックと呼ばれ、ブロックチェーンを生成するプロセスは、ブロック決済プロセスと呼ばれる。

【0079】

次に、監視者ノードと呼ばれる数千のコンセンサス関係者が、チェックポイントブロックにおいて検証者委員会が生成したチェーンを検証およびファイナライズしてよい。監視者ネットワークは、検証者委員会の上位セットであり、検証者は監視者でもある。一定の期間にわたる特定量のトークンのロックアップがある場合、ネットワーク内の任意のノードが即座に監視者になり得る。監視者は、検証者委員会によって生成されたブロックチェーンをダウンロードおよび調査し、チェックポイントにおいてコンセンサスを得ようと試みる。「ファイナライズ」とは、正当な監視者の各々に、他の全ての監視者のうちの特定の割合（たとえば２／３）以上が同じブロックチェーンを見ていることを確信させることを指す。監視者ノードがコンセンサスに達したブロックは、ファイナライズされたブロックと呼ばれ、ブロックチェーンをファイナライズするプロセスは、ブロックファイナライズプロセスと呼ばれる。チェックポイントブロックは、たとえばある整数の倍数である高さを持つなどの所与の条件セットを満たす、選択されたブロックのサブセットである。この「リープフロッグ型発展」ファイナライズ手順は、２つの監視者ノードが圧倒的確率でブロックのハッシュについて合意する限り、それらはそのブロックまでのブロックチェーン全体の全く同じコピーを有するという、ブロックチェーンデータ構造の不変特性を利用している。検証者／監視者の区分により、複数レベルの安全保障が提供される。検証者委員会は、第１レベルのコンセンサスを提供し、監視者プールは、第２の防御線を形成する。数千のノードにより、ネットワークの保全性を脅かすことは大幅に困難になるので、更に高いレベルの安全性が提供される。このコンセンサスメカニズムは、取引スループット、一貫性、および非集中レベルに適切な均衡をもたらす。

【0080】

第２に、ＴＨＥＴＡブロックチェーンは、メッセージングの複雑性を著しく低減するために、集合シグネチャゴシップスキームを用いる。各監視者ノードは、自身の全ての近隣からの部分的集合シグネチャをまとめ続け、集計シグネチャについて触れ回る。そうすることで、各ノードのシグネチャ共有は、指数関数的速度で他のノードに到達し得る。加えて、シグネチャ集合は、ノード間のメッセージのサイズを小さく保つので、通信オーバヘッドが更に低減する。

【0081】

第３に、ＴＨＥＴＡブロックチェーンは、データコンテンツストリーミングおよび配信のためのオフチェーン「リソース指向少額支払いプール」を提供する。オフチェーン少額支払いプールは、オフチェーン取引を用いた１対多数および多数対１の取引を可能にする。ビデオストリーミングの場合、限られた数のオンチェーン取引で、視聴者は多数のキャッシャから引き出されたビデオコンテンツに対して支払い、キャッシャは多数の視聴者へのビデオデータの配信に対する支払いを受けることができる。大量の取引をオフラインに移動することにより、ブロックチェーンのスケーラビリティが著しく向上し得る。

【0082】

また、本発明に係るＴＨＥＴＡ台帳システムは、データストリーミング用途に固有のいくつかの難点に対処する。

【0083】

第１に、本発明は、超高取引スループットをサポートする。多くのブロックチェーン計画が取引スループット問題に直面しているが、ライブビデオストリーミングのスケーリングは様々であり、場合によっては更に複雑である。ビデオセグメント単位のトークン報酬少額支払いの粒度において、多くの場合、何百万もの同時視聴者によって多数のライブストリームが確立される人気のあるｅスポーツトーナメントの場合、たとえばビットコインおよびイーサリアムなどの現今の公開チェーンの最大スループットをはるかに上回る毎秒数百万の少額取引が発生し得る。ＤＦＩＮＩＴＹおよびＺＩＬＬＩＱＡなどの新世代のブロックチェーンソリューションは、毎秒数千または数万のオンチェーン取引を処理すると報告されている。これらの他のシステムに関して、毎秒数百万の取引は不可能に近い目標である。これに近付くために、たとえば支払いネットワークなどの２次スケーラビリティソリューションは、追及すべき選択肢の１つであり得る。支払いネットワークは、ユーザが全ての取引をブロックチェーンにコミットすることなく複数の取引を行うことを可能にし、基礎となるブロックチェーンのスケーラビリティを向上させるように設計された類の技術を指す。それでもなお、そのような支払いネットワークは、基礎となる支払いチャネルおよび／または中間取引所、ならびに専用の支払いルート指定経路に依拠しており、累積するレイテンシおよび複雑性を伴う。対して、本発明に係る台帳システムは、サポート可能なスループットを数桁単位で増幅させる「リソース指向少額支払いプール」によってオフチェーンスケーリング形式の新規的かつ発明的なソリューションを提供する。

【0084】

第２に、高い取引スループットの副産物として、急速に増大するストレージ消費があり、少額支払い取引の格納は、多くのストレージを要求する。毎秒数百万の取引が台帳に追加される場合、通常のコンピュータの記憶空間は急速に枯渇し得る。本発明は、ほとんどの少額支払い取引をオフチェーンに移動することにより、ブロックチェーンに格納される必要のある取引数を低減する。

【0085】

第３に、本発明は、二重使用を防止するための担保を取り入れ得る。すなわち、本発明は、二重使用を検出し、あらゆる状況下で二重使用者が得る正味価値が真に負であることを確実にし得る。いくつかの実施形態において、信頼のない少額支払いが行われ得るが、その最大リスクは、たとえば単一のデータパケットに対する少額支払いなど、非常に限られた数の少額支払いの損失である。

【0086】

以下では、最初に、高い取引スループットのＰ２Ｐデータストリーミングにおける使用に関する利点および欠点を強調するために支払いチャネルおよび支払いネットワークが説明される。リソース指向オフチェーン少額支払いプールは、次の項目で開示される。
支払いチャネルおよび支払いネットワーク

【0087】

支払いチャネルは、ユーザがブロックチェーンにコミットすることなく多数の取引を交換することを可能にする既存のメカニズムのクラスである。そのような「オフライン」取引は、後にブロックチェーン上で決済され得るので、最小限の取引確認レイテンシしか生じない。支払いチャネルはステートチャネルの一種であり、２人のユーザ間で共有されるステートは、まず積立て取引を介してブロックチェーン上にロックされ、ステートは、暗号通貨の総額または残高である。後続するコミット取引は、初期ステートを更新するために２人のユーザ間でオフライン交換される。最終決済取引が確認のためにブロックチェーンに提示されると、一方的または双方的にステートチャネルが閉じる。オフラインでステートが更新され、またはユーザ間でコミット取引が交換され得るので、それらが作成および署名されると即座に、積立て取引と決済取引との合間に多数の取引が交換され得る。オンチェーン取引の数を２つに削減することにより、非常に高頻度の少額支払いに関連するコストも大幅に低減される。

【0088】

支払いチャネルの単純かつ典型的な例として、アリスが１月間毎日、暗号トークンを用いてボブから食料品を購入したい場合を考える。アリスは各トークン取引に対し取引料を支払う必要があるため、ボブに対する月末に１回の一括払いを望むが、ボブは、アリスが月末に一括払いを支払うことを完全に信用していないので、各食料品に対し１回のトークン取引を望む。

【0089】

支払いチャネルは、この膠着状態を打破する実行可能な選択肢である。１日目、アリスは、アリスおよびボブの両者からの取引シグネチャを要求することによってのみボブが引き出すことができる個別ウォレットＷに３０トークンを預け入れてよい。この預金取引がブロックチェーンに記録された後、ボブは、アリスが月間で彼に支払うために十分なトークン数を積み立てたことを確認し、このウォレットからの引出しが可能な唯一の人間がボブである。ｎ（１≦ｎ≦３０）日目、ボブはアリスに食料品を提供して、その見返りに部分的に署名されたコミット取引を入手し、この取引はボブにｎ個のトークンを割り当て、残りの３０－ｎ個のトークンを釣銭としてアリスに割り当てる。したがってボブは、任意のｍ日目、ｍ番目の食料品に関する最新の決済取引がアリスによって署名されたかに依存してｍ－１またはｍ個のトークンを請求するために、ブロックチェーン上の決済としてアリスから受け取った最新のコミット取引に署名しそれを発行し得る。決済が終わると、ｍ個のトークンがボブに送られ、残りがアリスに返されることで、預金は使い切られる。毎日の購入プロセスが３０日目まで継続した場合、ボブは、アリスからの最後の取引に署名し、それをブロックチェーンに提示して、ウォレットＷから３０トークン全てを一度に請求することができる。このように、ボブは、アリスが食料品に対し支払わないことを案じる必要なく、最大トークンを得るために、ブロックチェーンに最後の取引のみを提示することへのインセンティブを受ける。加えて、アリスは、アリスおよびボブ両者のシグネチャを必要とするこれらの取引を発行することによって、詐欺を働くことができない。

【0090】

このように、支払いチャネルは、オンチェーン取引の数を低減することにより、ブロックチェーンのスケーラビリティを著しく向上させ得る。上記例において、オンチェーン取引の数は３０から２に減少する。上記例は、一方向支払いチャネルの簡略化された例である。実際の支払いチャネルは、時限錠および関連機能などの更なるカスタマイズを必要とする。

【0091】

上記例における食料品をビデオセグメントと置き換えると、支払いチャネルを用いて、視聴者は、１回だけのオンチェーン決済取引で多数のビデオセグメントに対し支払うことができる。それでもなお、２つの問題点を考慮する必要がある。第１に、緩慢なノード切換え時間は、多数のキャッシャから多数の視聴者へのデータセグメントのストリーミングには役立たない。上述したように、任意の２人の関係者間で支払いチャネルを確立するためにオンチェーン取引が必要であり、これは、ブロックチェーン上で確認されるために少なくとも数秒を要し得る。一般に、ライブストリームセッション（１または２時間の長さ）において、視聴者ノードは、１０超過のキャッシング中継ノードからストリームセグメントを引き出し得る。視聴者ノードが新たな中継またはキャッシングノードからストリームを引き出すことを要する度、最初にオンチェーン取引を行う必要があり、時間の浪費となる。加えて、オンチェーン取引が確認されるまで、視聴者はキャッシング／中継ノードからストリームを引き出すことができない。このためにビデオストリームが停止されることがあり、ユーザ体験の質が低下する。第２に、大量のトークンの積立てが必要である。各支払いチャネルは、前もって積み立てられる特定の数のトークンを必要とする。したがって、視聴者から多数の中継ノードへ、または多数の視聴者から１つの中継器への１０超過の支払いチャネルは、特に視聴者が十分なトークンを有していない場合、常に利用可能なわけではない。その結果、視聴者は、ピアキャッシングノードが所望のストリームセグメントを有する場合でもピアノードから引き出せない場合があり、ネットワークの過少利用が生じ、コンテンツ配信プラットフォームの節減が少なくなる。

【0092】

視聴者および中継器ペア間の直接的な支払いチャネルを作成することに加えて、中間関係者を介して支払いをルート指定するためにオフチェーン「支払いネットワーク」が用いられ得る。たとえば、ライトニングネットワークは、中間ピアを信頼することなく１つの支払いチャネルから次の支払いチャネルに支払いがルート指定されることを可能にする双方向支払いチャネルのネットワークである。しかし、支払いチャネルネットワークを介したルート指定は、視聴者とキャッシャとの間の間接的ルートの発見を伴うが、そのような間接的ルートが常に存在するわけではない。視聴者とキャッシャとの間に間接的ルートが存在する場合でも、余分なホップを介した少額支払いの送付は、レイテンシおよび複雑性を増加させる。
非集中型データストリーミングおよび配信のためのリソース指向少額支払いプール

【0093】

非集中型Ｐ２Ｐデータストリーミングおよび配信に参加するようにピアノードにインセンティブを与える時の支払いチャネルおよび支払いチャネルネットワークに関連する上記問題点を回避するために、二重使用の防止を提供しながら多数のユーザがオフチェーン取引を用いて預け入れまたは引出しをすることが可能な新規的「リソース指向少額支払いプール」が構築され得る。すなわち、視聴者およびキャッシャはデータ送信のために接続され得るが、ブロックチェーンに基づく暗号通貨によってインセンティブを受ける場合、両者は、支払い決済のために支払いサーバおよび／またはブロックチェーンにも接続され、場合によっては少額支払いをルート指定するためにいくつかのピアノードにも接続され得る。この構成は図４Ｂに示される。ＴＨＥＴＡブロックチェーン台帳フレームワークにおいて、開示されるような少額支払いプールは、接続された支払いネットワークを必要とせずに多数の関係者間の少額支払いを容易にする。
マルチソースデータストリーミングおよび配信に関する１対多数の少額支払い処理

【0094】

上述したように、典型的なライブストリームセッションにおいて、視聴者ノードは、多数の中継器またはキャッシングノードからデータストリームセグメントを引き出してよい。１対多数の少額支払いプールを用いると、視聴者は、少額支払いプールを作成するより前に、どの口座が引出し可能であるかを指定する必要がない。そのようなシステムは、従来のオフチェーン支払いチャネルと比べて大幅に柔軟性が高い。特に、非集中型ビデオストリーミングおよび配信の場合、視聴者は、中間オンチェーン取引を介さず、かつ個々のキャッシングノードとの支払い接続を維持することなく、多数のキャッシングノードから引き出されたビデオコンテンツに対し支払うことが可能になる。オンチェーン取引をオフチェーン支払いに置き換えることにより、組込み型「リソース指向少額支払いプール」は、ブロックチェーンのスケーラビリティを著しく向上させる。

【0095】

図８は、リソース指向少額支払いプールを介した取引を示し、視聴者８０２のアリスが、ビデオチャンクに関してキャッシャ８０４のボブおよび８０６のキャロルにオフチェーン支払いを行う様子を示す。すなわち、複数のキャッシャが同じ視聴者アリスとデータを共有し、ＴＨＥＴＡブロックチェーン上でアリスによって作成された少額支払いプールを介して支払いを受ける。この特定の例において、以下のステップが行われる。

【0096】

ステップ１．少額支払いプールの作成。アリスは、場合によってはコマンド８１０：プール作成（リソースＩＤ、預金、担保、持続期間）を用いて、時限錠および削除可能な担保を有する少額支払いプールを作成するためにオンチェーン取引を発行する。

【0097】

プールを作成するために、アリスは、自身が取得しようと意図するデジタルコンテンツを一意的に表す「リソースＩＤ」であるリソースＩＤを指定してよい。これは、ビデオファイルまたはライブストリームを指し得る。預金額は、取得されるリソースの総額以上であってよい。たとえば、リソースが１０トークンの価値のあるビデオファイルである場合、預金は１０トークン以上でなければならない。担保は、アリスの二重使用を抑止する。ブロックチェーンの検証者によってアリスから二重使用の試みが検出されると、担保が削除され得る。後に説明されるが、担保＞預金である場合、二重使用の正味利益は常に負であるため、理性的なユーザは、二重使用にインセンティブを持たない。持続期間は、標準的な支払いチャネルと同様の時限錠である。支払いプールからの引出しは全て、時限錠の満了前でなくてはならない。ブロックチェーンは、プール作成取引がブロックチェーンにコミットされた後のプール作成取引のマークルプルーフならびにプール作成取引の取引ハッシュであるプール作成取引ハッシュをアリスに返す。

【0098】

ステップ２．ピア間の初期ハンドシェイク。アリスは、ピア（たとえばボブ、キャロル、またはデイビッドなど）から特定のリソースを取得しようとする度、オンチェーンプール作成取引８１０のマークルプルーフおよび取引ハッシュをそのピアに送信する８２０。受信側ピアは、プールが要求されたリソースに対し十分な預金および担保を有することを確かめるためにマークルプルーフを検証し、両者は次のステップに進み得る。

【0099】

ステップ３．オフチェーン少額支払い。アリスは、データチャンクまたは特定のリソースの一部（たとえばビデオファイルの断片、ライブストリームセグメントなど）の対価として、サービス支払い取引に署名し、それをオフチェーンでピアに送信する。サービス支払い取引は、次のデータ：ターゲットアドレス、振込金額、プール作成取引ハッシュ、ターゲット決済シーケンス、署名（ＳＫ_Ａ、ターゲットアドレス||振込金額||プール作成取引ハッシュ||ターゲット決済シーケンス）を含んでよい。ターゲットアドレスは、アリスがリソースを取得するピアのアドレスであり、振込金額は、アリスが送付しようと意図するトークン支払い額である。ターゲット決済シーケンスは、リプレイアタックを防ぐためである。これは、イーサリアム取引における「ノンス」パラメータと同様である。ターゲットがサービス支払い取引をブロックチェーンに発行すると（次のステップを参照）、そのターゲット決済シーケンスは１インクリメントする必要がある。受信側ピアは、オフチェーン取引およびシグネチャを検証する。検証した上で、受信側ピアは、プール作成取引によって指定されたリソース８３０または８３２をアリスに送信してよい。また、オフチェーンサービス支払い取引は、２つのピア間で直接送信され得る。したがって、このステップにスケーラビリティボトルネックは存在しない。

【0100】

ステップ４．オンチェーン決済。サービス支払い取引８４０または８４２をアリスから受け取る任意のピア（すなわちボブ、キャロル、またはデイビッドなど）は、トークンを引き出すために時限錠が満了するまでのいつでもブロックチェーンに署名済み取引を発行してよい。発行されたサービス支払い取引は、「オンチェーン決済」取引とも呼ばれ得る。受信側ピアは、オンチェーン決済取引のためのガス料金に対し支払う必要がある。より少ない取引料を支払うために、彼らは、必要な時にのみオンチェーン決済を発行するインセンティブがあり、これはネットワークのスケーラビリティに有益である。

【0101】

留意すべき点として、アリスがリソースを取得するために１つのピアから別のピアに切り換える時、新たなオンチェーン取引は必要ではない。ビデオストリーミングの場合、これは、視聴者が、ビデオストリーム配信を遮断または遅延させる可能性のあるオンチェーン取引を行うことなく、いつでも任意のキャッシングノードに切換え可能であることを意味する。図８に示すように、ボブが離脱した場合、アリスは、ボブからｋ個のチャンクを受け取った後にキャロルに切り換え、オンチェーン取引を伴わずにビデオチャンクまたはセグメントの受信を維持することができる。

【0102】

また、少額支払いプールを作成するために必要なトークンの総数は（担保＋預金）であり、これは、アリスがリソースを取得するピアの数にかかわらず、要求されたリソースの金額のたった２倍であり得る。計算複雑性の言語を用いると、積み立てられたトークンの総額は一方向支払いチャネルのアプローチと比べてＯ（ｎ）からＯ（１）まで減少し、ここでｎは、アリスがリソースを取得するピアの数である。
二重使用検出および罰則分析

【0103】

任意の暗号通貨と同様に、本発明のいくつかの実施形態によると、悪意のある行為者が二重使用を試み、検出後に罰則を受けることがある。

【0104】

この例において、ネットワークは、少額支払いプールの作成者であるアリスが二重使用を行ったことを検出することができ、アリスが二重使用によって得る正味価値が真に負であることを確実にし得る。二重使用を検出するために、検証者ノードは、全てのオンチェーン取引をチェックしてよい。少額支払いプールに残っている預金が、アリスおよび他のピアの両者によって証明された次の連結支払い取引に足りない場合、検証者は、アリスが二重使用を行ったと考え、二重使用時にアリスが損をすることを確実にし得る。

【0105】

より具体的な例において、ピアのボブ、キャロル、およびデイビッドは正当であり、アリスは悪意がある。更に悪い場合、アリスは他の悪意のあるピアであるエドワードと共謀し得る。アリスは、特定のリソースに関してボブ、キャロル、およびデイビッドと部分的に署名済みの取引を交換する。アリスは、重複したリソースに関する超過価値を得ないので、彼女がボブ、キャロル、およびデイビッドから得る最大価値は最大でも預金額である。アリスがエドワードと共謀する場合、アリスはエドワードに全預金額を送付し得る。その後、アリスはエドワードに、他の誰かより先に決済取引をコミットし、後から彼女に預金を返すように求める。すなわち、アリスは、二重使用が検出される前に、最大で預金額に値するリソースを無料で入手する。後にボブ、キャロル、またはデイビッドが決済取引をコミットすると、二重使用が検出され、全担保額が削除される。したがって、アリスの純収益は、ｎｅｔＡｌｉｃｅ＝預金－担保である。よって、この状況に関して、担保＞預金である限り、アリスの純収益は負である。したがって、アリスが理性的であれば、二重使用にインセンティブを持たない。同様に、他の事例に関する分析によって、アリスが二重使用を行う場合にアリスの純収益は常に負であることが示される。

【0106】

他の例において、アリスは正当であるが、彼女のピアの何人かが悪意を有する。アリスがそれらのピアの１人に少額支払いを送付した後、このピアは、アリスが所望するリソースをアリスに返さない場合がある。この場合、アリスは、リソースを得るために他のピアに頼ることができる。理論上、増加的少額支払いの各々は限りなく小さくなり得るので、アリスの損失は任意に小さくされ得る。
Ｐ２Ｐストリーミングにビデオプラットフォームが関与するための多数対１の少額支払い処理

【0107】

視聴者と多数のキャッシングノードとの間のＰ２Ｐストリーミングを容易にすることに加えて、本発明に従って実装されるＴＨＥＴＡ台帳システムは、ビデオプラットフォームにおいて更なる有用性および機能性を有する。たとえば、エンドユーザ視聴者は、コンテンツプロバイダおよび人気のあるインフルエンサに直接贈り物をし、またはインフルエンサに贈られ得る仮想アイテムや商品を購入してよい。広告主およびブランドスポンサは、広告キャンペーンに投資し、これらの広告が表示されるビデオストリームを有するインフルエンサに自動的に報酬を与えてよく、任意選択的に、広告主は、ストリームコンテンツおよび広告への関心に対し視聴者に報酬を与えてよい。またエンドユーザは、プレミアムコンテンツ、仮想商品、および他の有料製品およびサービスを購入してもよい。

【0108】

また、ビデオプラットフォームは、共有された帯域幅に基づいてユーザに支払うことによって、ユーザに帯域幅を共有するように促し得る。典型的な例において、本発明の１つの実施形態によると、アリスは複数のピアのボブ、キャロル、およびデイビッドなどとデータを共有してよく、ビデオプラットフォームは、後述する処理プロトコルを用いて、少額支払いを通して暗号通貨トークンでアリスに報酬を与えてよい。この典型的な実施形態において、支払いサービスモジュールは、署名済みのサービス受領書およびトラッカ許可書を検証し、更新されたオフチェーン取引を最終的なオンチェーン決済のために中継／キャッシュノードに送信してよい。

【0109】

図９は、本発明のいくつかの実施形態に係る、コンテンツ配信源またはビデオプラットフォーム９０１によって確立されたリソース指向少額支払いプールを介した取引を示し、エッジキャッシャ８０２であるアリス（「ピアＡ」）が、８０４のボブおよび８０６のキャロルを含む複数の視聴者へのデータコンテンツの配信に対するオフチェーン支払いを受け取る様子を示す。この特定の例において、以下のステップが行われる。

【0110】

ステップ１．データ共有のためのピアグループの確立。トラッカおよび支払いサーバ９０３は、視聴者８０２、８０４、および８０６をグループにし、１または複数の支払い許認可証９０１を各参加ピアに付与する。たとえば、許認可証ａｕｔｈ（アリス、ボブ）がアリスに付与されてよく、これにより、そのピアまたは視聴者が、サーバが確立する視聴者グループ内でのみ支払いを交換できることが確実になる。図４Ｂを参照して上述したように、支払いサーバまたは支払いサービスモジュールは、トラッカサーバまたはトラッカサービスモジュールと同じ位置にあってよい。支払いサーバは、ビデオプラットフォーム９０１によって直接運営されてもよい。

【0111】

ステップ２．少額支払いプールの作成。ビデオプラットフォーム９０１は、典型的なコマンド９２０：プール作成（リソースＩＤ、預金、担保、持続期間）を用いて、支払いサービスモジュールと時限錠および削除可能な担保を有する少額支払いプールを作成してよい。

【0112】

重ねて、プールを作成するために、ビデオプラットフォーム９０１は、取得されるデジタルコンテンツを一意的に表す「リソースＩＤ」を明記する。これは、ビデオファイルまたはライブストリームを指してよい。預金額は、少なくとも取得されるリソースの総額である必要がある。たとえば、リソースが１０トークンの価値のあるビデオファイルである場合、預金は、少なくとも１０トークンとなる。担保は、二重使用を抑止するために必要である。ブロックチェーンネットワークの検証者によって二重使用の試みが検出されると、担保は削除され得る。持続期間は、標準的な支払いチャネルと同様の時限錠である。支払いプールからの引出しは全て、時限錠の満了前でなくてはならない。ライブストリームの場合、削除された預金は、二重使用の混乱を避けるために自動的に補充され得る。

【0113】

ビデオプラットフォーム９０１が帯域幅の共有に対して視聴者に報酬を与えることを目的として、ビデオプラットフォーム９０１のためのトークン保管サービスを提供するために、ここでは第三者によって支払いサーバまたは支払いサービスモジュール９０３が維持され得る。ビデオプラットフォーム９０１は、市場から暗号通貨を購入し、購入したトークンを支払いサーバに格納してよい。ビデオプラットフォーム９０１は、積立て取引を提示する必要がある場合、プロセスを開始するために支払いサーバ９０３によって提供されるＡＰＩを呼び出してよい。他のいくつかの実施形態において、ビデオプラットフォーム９０１が直接支払いサーバ９０３を運営してよく、積立て取引の提示は、内部コールとして実行され得る。

【0114】

積立て取引がコミットされた後、支払いサーバ９０３は、コミットされた後のプール作成（）取引のマークルプルーフならびにプール作成（）取引の取引ハッシュであるプール作成取引ハッシュを含む情報９２２をビデオプラットフォーム９０１に返す。ビデオプラットフォーム９０１は、通知メッセージ９２４においてアリスにマークルプルーフを受け渡すので、アリスは、少額支払いプールの作成を認知する。いくつかの実施形態において、通知メッセージは、他のデータ型および／または構造を含んでもよい。

【0115】

ステップ３．データ共有。アリスは、同時または非同期的に、ピアであるボブとデータチャンク９３０を、ピアであるキャロルとデータチャンク９３２を共有する。データ９３０および９３２は、各々が、過去に指定されたデジタルコンテンツデータリソースの一部であってよい。たとえば、それらの各々は、ビデオファイルの断片またはスライス、単一データパケット、ライブストリームセグメントなどであってよい。

【0116】

ステップ４．オフチェーン少額支払い。ボブは、サービス受領書９４０に署名し、それを、指定されたリソースの一部と引き換えにアリスにオフチェーンで送信する。同様に、キャロルは、サービス受領書９４２に署名し、それをオフチェーンでアリスに返送する。

【0117】

ステップ５．少額支払い領収書の提示。アリスは、サービス提供したピアから少額支払い領収書を受け取ると、アップロードデータ９５０として、許認可証と共に少額支払い領収書を支払いサーバ９０３に提示する。支払いサーバ９０３は、１）各ピアによって署名されたサービス受領書、および２）トラッカサーバが各ピアとアリスとの間での共有を認可したことを検証する必要がある。

【0118】

具体的には、アリスがデータ９３０をボブに提供または共有し、サービス受領書９４０を受け取った後、アリスは、サービス受領書９４０を支払いサーバ９０３に提示し、ボブと共有されたデータ９３０に対する少額支払いプールからアリスへの支払い振込み額を記録する支払いサーバ９０３からのオフチェーン取引を受信する。次に、アリスがデータ９４０をキャロルに提供または共有し、サービス受領書９５０を受け取った後、アリスは、サービス受領書９５０を支払いサーバ９０３に提示し、更新された取引、または過去のオフライン取引を更新する別のオフライン取引を受信する。この更新された取引は、ボブと共有されたデータ９３０およびキャロルと共有されたデータ９４０の両方に対する少額支払いプールからアリスへの別の更新された支払い振込み額を記録する。

【0119】

同様に、より多くのデータピースがボブ、キャロル、または他の視聴者と共有されると、支払いサーバ９０３は、１または複数の新たなサービス受領書によってトリガされた時、それぞれの更新されたオフライン取引をアリスに送信し、各更新されたオフライン取引は、オンチェーン決済取引を介して支払われていない、これまでアリスによってピアに共有された全てのデータの分であるそれぞれの更新された支払い振込み額を記録している。

【0120】

ステップ６．オンチェーン決済。支払いサーバ９０３は、アリスがこれまで受け取った支払い総額を累積する更新されたオフチェーン取引をアリスに送信し、アリスは、それをいつでもオンチェーン取引９７０としてブロックチェーンに提示し、報酬９７２の更新された残高を請求することができる。取引９６０は、次のデータ：ターゲットアドレス、振込み額、プール作成取引ハッシュ、ターゲット決済シーケンス、署名（ＳＫ_Ａ、ターゲットアドレス||振込み額||プール作成取引ハッシュ||ターゲット決済シーケンス）を含んでよい。

【0121】

オンチェーン決済の場合、ビデオプラットフォームまたはアリスのいずれかは、アリスにトークンで報酬を与えるために、時限錠が満了するまでいつでも、署名済み取引をブロックチェーンに定期的に発行し得る。発行されるサービス支払い取引は、「オンチェーン決済」取引と呼ばれ得る。共有されるデータチャンクまたはセグメントの数にかかわらず、個々の少額支払いの全てを含む支払い総額を請求するために、単一のオンチェーン決済取引のみが必要である。すなわち、後続の取引が過去の取引を更新し、全ての視聴者に共有された全ての未払いデータチャンクの費用を含む支払い総額を請求するために、最後の取引のみがブロックチェーンに提示される。２より多い数のデータチャンクが複数の視聴者に共有される時、オンチェーン決済取引の数は一定して１に保たれるので、暗号通貨少額支払いに伴う取引確認時間遅延が償却および大幅に低減される。

【0122】

重ねて、オンチェーン決済取引に対してガス料金が支払われる必要がある。支払う取引料を少なくすることは、必要時のみオンチェーン決済を発行することへの強いインセンティブとなり、これはネットワークのスケーラビリティに有益である。

【0123】

また、アリスが同時に複数のピアとビデオストリームを共有する場合、オンチェーン取引は必要ではない。ビデオストリーミングの場合、これは、視聴者が、ビデオストリーム配信を遮断または遅延させる可能性のあるオンチェーン取引を行うことなくいつでも任意のキャッシングノードに切換え可能であることを意味する。

【0124】

また、いくつかの実施形態において、支払いフローは、二重使用に関する信頼がなくとも進行し得る。ピアは、ブロックチェーンにおいて少額支払いプールが生成されたことを確かめた時のみ、データ共有サービスを提供し得る。その後、各データパケットについて、ピアは、ビデオプラットフォーム／支払いサーバが対応する少額支払い取引に署名するかをチェックしてよい。ピアは、少額支払いへの署名の違反を検出すると、帯域幅の共有を停止してよい。このように、ピアは、単一の少額支払いを危険にさらし得る。理論上、増加的少額支払いの各々は限りなく小さくなり得るので、この損失は任意に小さくされ得る。あるいは、ピアは、そのパケットに対する署名済みの支払いを受け取った後にのみデータパケットを送信してよく、代わりにビデオプラットフォームが損失のリスクを負う。

【0125】

支払いサーバまたは支払いサーバモジュールの使用および上述したプロセスステップの組み合わせは、ブロックチェーンインセンティブ方式のピアツーピアデータ共有技術を改善し、キャッシャが複数の視聴者にデータを配信する時に必要なオンチェーン決済取引の数を低減することによって、暗号通貨少額支払いに伴う取引確認時間遅延を著しく低減する。高スループット少額支払いの処理におけるこの大幅な性能改善は、特に、高い時間的感度およびリアルタイム要件を有するライブストリーミングの状況で有利である。そのような少額支払いプールを利用するライブストリームプラットフォームの特定の実装の１つにおいて、毎日のように、１００，０００を超える集計オンチェーン支払い取引が処理され、各オンチェーン取引は、平均して約３０～４０のオフチェーン少額支払いに対応する。よって、３～４百万の少額支払いが処理され得るが、これは、システムが設計される実現可能なスループット制限を大きく下回っている。

【0126】

結論として、本発明の実施形態は、公開台帳システムを用いた非集中型の信頼と、データ配信およびデータストリーミング少額支払いの固有の要件に関する低い取引コストでの高速でスケーラブルな取引速度という、競合する２つの目的を慎重に歩み寄らせる。すなわち、支払いサーバまたは支払いサービスモジュールの使用と、中央信頼機関ではなく非集中型の信頼に依拠するブロックチェーンベースの支払いシステムの非集中型の性質とにトレードオフが存在する。上記の典型的な実施形態において、ブロックチェーンによって提供される非集中型の信頼に依拠した状態を保ちながら、各キャッシャノードは、支払いサーバに通信可能に接続される必要があり、そのように重なり合うトポロジは、純粋なピアツーピアデータ共有の直観に反する集中化の層の追加と考えられ得る。それでもなお、支払いサーバは、上述したような新規的なハイブリッドデータ配信ネットワークに組み込まれ、ビデオプラットフォームが、取引確認時間遅延を最小限に維持しながら、多数の視聴者へのデータ共有に対しキャッシャに報酬を与えることを可能にする。
ビデオストリーミングの範囲外での少額支払いプールの適用

【0127】

上記説明において、リソース指向少額支払いプールは、ビデオ配信の状況において提示される。これは、リソースが識別可能であれば、ユーザが異なるピアからリソースの複数のコピーを取得する場合に超過価値を得ることができない他の用途でも用いられ得る。いくつかの例を挙げると、リソースは、汎用ファイルであってよく、リソース指向少額支払いプールは、汎用ファイル共有／格納を容易にし得る。アプリ配信（たとえばアップル社のアプリストア、グーグルプレイなど）の場合、アプリがリソースと見なされ得る。またリソースは、特定の種類のサービス、たとえばファイル圧縮サービス、ビデオトランスコーディングサービス、一次方程式セットを解くことなどであってもよい。これらのサービスに関して、要求者は、２つのベンダから同じサービスを入手することによって超過価値を得ることはない。
結論

【0128】

当業者は、使用事例、構造、概略図、およびフロー図が他の順序または組み合わせで行われ得ることを知っているが、本発明の発明概念は、本発明の広大な範囲から逸脱することなく維持される。全ての実施形態は独自的であってよく、方法／ステップは、全てのエンドユーザデバイスが本発明の方法を実施するためにサーバによって融通されるように、短縮または延長、他の活動と重複、延期、遅延、および時間間隔の後に継続されてよい。

【0129】

本発明は、ハードウェアおよび／またはソフトウェアで実装され得る。システムの多くの構成要素、たとえば信号処理モジュールまたはネットワークインタフェースなどは、本発明を不明瞭にしないように図示されていない。ただし、当業者は、システムがこれらの構成要素を必ず含むことを認識する。図６に示すようなコンピューティングデバイスは、メモリに結合された少なくとも１つのプロセッサを含むハードウェアである。プロセッサは、１または複数のプロセッサ（たとえばマイクロプロセッサ）を表してよく、メモリは、ハードウェアの主要ストレージを備えるランダムアクセスメモリ（ＲＡＭ）デバイス、ならびに任意の補助レベルのメモリ、たとえばキャッシュメモリ、不揮発性またはバックアップメモリ（たとえばプログラマブルメモリまたはフラッシュメモリ）、読取専用メモリなどを表してよい。加えて、メモリは、ハードウェア内のどこかに物理的に存在するメモリストレージ、たとえばプロセッサ内の任意のキャッシュメモリ、ならびに、たとえば大容量記憶デバイスに格納されるような仮想メモリとして用いられる任意の記憶容量を含むことが考えられ得る。

【0130】

また、コンピューティングデバイスのハードウェアは、一般に、外部で情報を通信するために複数の入力および出力を受信する。ユーザとのインタフェースのために、ハードウェアは、１または複数のユーザ入力デバイス（たとえばキーボード、マウス、スキャナ、マイクロフォン、カメラなど）およびディスプレイ（たとえば液晶ディスプレイ（ＬＣＤ）パネル）を含んでよい。追加のストレージのために、ハードウェアは、１または複数の大容量記憶デバイス、特に、たとえばフロッピーまたは他の取出し可能ディスクドライブ、ハードディスクドライブ、ダイレクトアクセスストレージデバイス（ＤＡＳＤ）、光学ドライブ（たとえばコンパクトディスク（ＣＤ）ドライブ、デジタルバーサタイルディスク（ＤＶＤ）ドライブなど）、および／またはテープドライブも含んでよい。またハードウェアは、ネットワークに結合された他のコンピュータとのストリーミングコンテンツおよび情報の通信を可能にするために、１または複数のネットワーク（特に、たとえばローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、無線ネットワーク、および／またはインターネット）とのインタフェースを含んでよい。理解すべき点として、ハードウェアは、一般に、互いに通信するための適当なアナログおよび／またはデジタルインタフェースを含む。

【0131】

本発明のいくつかの実施形態において、いわゆるクラウド実装では、インターネットを介してシステム全体が実装され、エンドユーザおよびオペレータに提供され得る。ソフトウェアまたはハードウェアのローカルな設置は必要なく、エンドユーザおよびオペレータは、クライアント上のウェブブラウザまたは同様のソフトウェアを用いて、インターネットを介して直接、本発明のシステムにアクセスすることが可能であり、このクライアントは、デスクトップ、ラップトップ、モバイルデバイスなどであってよい。これにより、クライアント側でカスタムソフトウェアを設置する必要がなくなり、サービスを供給する柔軟性が高まり（ｓｏｆｔｗａｒｅ－ａｓ－ａ－ｓｅｒｖｉｃｅ）、ユーザの満足度および使い易さが増加する。本発明に関する様々なビジネスモデル、収益モデル、および配信メカニズムが想起されるが、それらは全て、本発明の範囲内と見なされるべきである。

【0132】

ハードウェアは、オペレーティングシステムの制御下で動作し、上述した方法、プロセス、および技術を行うために様々なコンピュータソフトウェアアプリケーション、構成要素、プログラムコード、ライブラリ、オブジェクト、モジュールなどを実行する。

【0133】

一般に、本発明の実施形態を実施するために実行される方法は、オペレーティングシステムまたは「コンピュータプログラム（複数も可）」または「プログラムコード（複数も可）」と称される特定のアプリケーション、構成要素、プログラム、オブジェクト、モジュール、または命令のシーケンスの一部として実装され得る。コンピュータプログラムは、一般に、コンピューティングデバイスまたはコンピュータにおける様々なメモリおよびストレージデバイスに様々な時に設定され、コンピュータにおける１または複数のプロセッサによって読み取られ実行されると、コンピュータに、本発明の様々な態様に伴う要素を実行するために必要な動作を行わせる１または複数の命令を備える。また、本発明は、全体で機能するコンピュータおよびコンピュータシステムの文脈で説明されたが、当業者は、本発明の様々な実施形態が様々な形式のプログラム製品として分散されることが可能であること、本発明は、実際に分散を行うために用いられる機械またはコンピュータ可読媒体の特定の種類にかかわらず等しく適用されることを理解する。コンピュータ可読媒体の例は、たとえば揮発性および不揮発性メモリデバイス、フロッピーおよび他の取出し可能ディスク、ハードディスクドライブ、光学ディスク（たとえばコンパクトディスク読取専用メモリ（ＣＤ－ＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）など）、およびデジタルおよびアナログ通信媒体などの記録可能型媒体を含むが、これに限定されない。

【0134】

本開示の特定の実施形態が説明されたが、当業者は、他の数々の変更例および代替実施形態が本発明の範囲内であることを認識する。たとえば、特定のデバイスまたは構成要素に関して説明された機能および／または処理能力のいずれかが、他の任意のデバイスまたは構成要素によって行われ得る。また、本開示の実施形態に従って様々な典型的な実装およびアーキテクチャが説明されたが、当業者は、本明細書で説明される典型的な実装およびアーキテクチャに対する数々の他の変更例もまた本開示の範囲内であることを理解する。

【0135】

ブロック図およびフロー図のブロックは、記載された機能を行うための手段の組み合わせ、記載された機能を行うための要素またはステップの組み合わせ、および記載された機能を行うためのプログラム命令手段に対応する。また、ブロック図およびフロー図の各ブロック、およびブロック図およびフロー図のブロックの組み合わせは、記載された機能、要素、またはステップを行う専用のハードウェアベースのコンピュータシステムによって、または専用ハードウェアとコンピュータ命令との組み合わせによって実装され得ることも理解される。

【0136】

ソフトウェア構成要素は、様々なプログラミング言語のいずれかで符号化され得る。典型的なプログラミング言語は、たとえば特定のハードウェアアーキテクチャおよび／またはオペレーティングシステムプラットフォームに関連するアセンブリ言語などの下位レベルのプログラミング言語であってよい。アセンブリ言語命令を備えるソフトウェア構成要素は、ハードウェアアーキテクチャおよび／またはプラットフォームによる実行より前に、アセンブラによって実行可能な機械コードに変換することが必要であり得る。

【0137】

ソフトウェア構成要素は、ファイルまたは他のデータ記憶構造で格納され得る。同様の種類または機能的に関連するソフトウェア構成要素は、たとえば特定のディレクトリ、フォルダ、またはライブラリなどに共に格納され得る。ソフトウェア構成要素は、静的（たとえば事前確立または固定）、または動的（たとえば実行時に生成または修正）であってよい。

【0138】

ソフトウェア構成要素は、様々なメカニズムのいずれかを介して他のソフトウェア構成要素を呼び出し、または他のソフトウェア構成要素に呼び出され得る。呼び出された、または呼び出し側のソフトウェア構成要素は、他のカスタム開発アプリケーションソフトウェア、オペレーティングシステム機能（たとえばデバイスドライバ、データ格納（たとえばファイル管理）ルーチン、他の共通ルーチンおよびサービスなど）、または第三者ソフトウェア構成要素（たとえばミドルウェア、暗号化、または他のセキュリティソフトウェア、データベース管理ソフトウェア、ファイル転送または他のネットワーク通信ソフトウェア、数学または統計学ソフトウェア、画像処理ソフトウェア、およびフォーマット変換ソフトウェア）を備えてよい。

【0139】

特定のソリューションまたはシステムに関連するソフトウェア構成要素は、単一のプラットフォーム上に存在し、実行されてよく、または複数のプラットフォームに分散され得る。複数のプラットフォームは、複数のハードウェアベンダ、基礎となるチップ技術、またはオペレーティングシステムに関連付けられ得る。また、特定のソリューションまたはシステムに関連するソフトウェア構成要素は、最初、１または複数のプログラミング言語で書かれ得るが、他のプログラミング言語で書かれたソフトウェア構成要素を呼び出してよい。

【0140】

コンピュータ実行可能命令は、専用コンピュータまたは他の特定の機械、プロセッサ、または特定の機械を生成するための他のプログラマブルデータ処理装置にロードされてよく、コンピュータ、プロセッサ、または他のプログラマブルデータ処理装置での命令の実行により、フロー図に記載される１または複数の機能または動作が行われ得る。これらのコンピュータプログラム命令は、実行されるとコンピュータまたは他のプログラマブルデータ処理装置に特定の方法で機能させるコンピュータ可読記憶媒体（ＣＲＳＭ）に格納されてもよく、コンピュータ可読記憶媒体に格納された命令は、フロー図に記載される１または複数の機能または動作を実施する命令を含む製品を生成する。コンピュータプログラム命令は、一連の動作要素またはステップが、コンピュータまたは他のプログラマブル装置で行われ、コンピュータ実装プロセスを生成するために、コンピュータまたは他のプログラマブルデータ処理装置にロードされてもよい。

【0141】

実施形態は、構造特徴および／または方法論的動作に特化した言語で説明されたが、本開示は、必ずしも説明される特定の特徴または動作に限定されないことを理解すべきである。むしろ、特定の機能および動作は、実施形態を実装する典型的な形式として開示される。たとえば特に「できる」、「し得る」、「する場合がある」、または「してよい」などの条件付き言語は、特に明記しない限り、または使用される文脈で別のように理解されない限り、特定の実施形態が特定の特徴、要素、および／またはステップを含み得るが、他の実施形態は含まないことを伝えることが意図されている。したがって、そのような条件付き言語は、一般に、特徴、要素、および／またはステップが１または複数の実施形態にいかなる場合も必要であること、または１または複数の実施形態が、ユーザの入力またはプロンプトを伴い、または伴わずに、これらの特徴、要素、および／またはステップが任意の特定の実施形態において含まれる、または行われるかを決定するための論理を必ず含むことを暗示することは意図されていない。

【0142】

本発明は、典型的な実施形態を参照して説明されたが、本発明の広範な範囲から逸脱することなく、これらの実施形態に様々な修正および変更がなされ得ることは明らかである。したがって、本明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。また、上述した実施形態は、教示される個別の記述のいずれよりも広い範囲を有し得る単一の広範な発明の特定の例であることが当業者には明らかである。本説明において、本発明の範囲から逸脱することなく、多数の変更がなされ得る。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【手続補正書】

【提出日】2021-05-31

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

分散型データ配信ネットワーク内の少なくとも２つの視聴者ピアノードとデータリソースを共有する対価として前記分散型データ配信ネットワーク内の支払いサーバノードにおける支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るために前記分散型データ配信ネットワーク内のキャッシャピアノードにおけるキャッシャクライアントモジュールによって行われるコンピュータ実装方法であって、プロセッサによって実行可能であり、
前記支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取ることであって、前記少額支払いプールは、前記少なくとも２つの視聴者ピアノードと前記データリソースを共有するための預金を符号化する積立て取引記録を前記ブロックチェーンに提示することによって作成されることと、
前記データリソースの第１の部分を前記少なくとも２つの視聴者ピアノードの第１の視聴者ピアノードにおける第１の視聴者クライアントモジュールと共有することであって、前記第１の視聴者ピアノードは、第１のピアツーピア接続によって前記キャッシャピアノードに接続されることと、
前記データリソースの前記第１の部分に関する前記第１の視聴者クライアントモジュールによって暗号で署名された第１のサービス受領書を受け取ることと、
前記第１のサービス受領書を前記支払いサービスモジュールに提示することと、
前記支払いサービスモジュールから第１のオフチェーン取引記録を受け取ることであって、前記第１のオフチェーン取引記録は、前記データリソースの前記第１の部分に対する前記少額支払いプールから前記キャッシャピアノードに行われる第１の支払い額の第１の振込みを符号化することと、
前記データリソースの第２の部分を前記少なくとも２つの視聴者ピアノードの第２の視聴者ピアノードにおける第２の視聴者クライアントモジュールと共有することであって、前記第２の視聴者ピアノードは、第２のピアツーピア接続によって前記キャッシャピアノードに接続されることと、
前記データリソースの前記第２の部分に関する前記第２の視聴者クライアントモジュールによって暗号で署名された第２のサービス受領書を受け取ることと、
前記第２のサービス受領書を前記支払いサービスモジュールに提示することと、
前記第１のオフチェーン取引記録の更新として、前記支払いサービスモジュールから第２のオフチェーン取引記録を受け取ることであって、前記第２のオフチェーン取引記録は、前記データリソースの前記第１の部分および前記データリソースの前記第２の部分に対する前記少額支払いプールから前記キャッシャピアノードに行われる第２の支払い額の第２の振込みを符号化することと、
前記少額支払いプールからの前記第２の支払い額を請求するために、前記第２のオフチェーン取引記録を前記ブロックチェーンに提示することと
を備える方法。

【請求項2】

前記データリソースを前記少なくとも２つの視聴者ピアノードと共有するためにピアグループに加入することと、
前記第１の視聴者ピアノードおよび前記第２の視聴者ピアノードとの前記データリソースの前記共有を認可する支払い許認可証を受け取ることと
を更に備える、請求項１に記載のコンピュータ実装方法。

【請求項3】

前記支払い許認可証を前記支払いサービスモジュールに提示すること
を更に備える、請求項２に記載のコンピュータ実装方法。

【請求項4】

前記ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる、請求項１に記載のコンピュータ実装方法。

【請求項5】

前記ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックで前記ブロックチェーンを検証するために監視者ノードを用い、前記チェックポイントブロックは、前記ブロックチェーン内のブロックのサブセットである、請求項４に記載のコンピュータ実装方法。

【請求項6】

前記通知は、前記積立て取引記録が新たなブロックに含まれた後の前記積立て取引記録のマークルプルーフを備える、請求項１に記載のコンピュータ実装方法。

【請求項7】

前記少額支払いプールは、前記データリソースのリソースＩＤ、時限錠、および削除可能な担保に関連付けられる、請求項１に記載のコンピュータ実装方法。

【請求項8】

分散型データ配信ネットワーク内の少なくとも２つの視聴者ピアノードとデータリソースを共有する対価として前記分散型データ配信ネットワーク内の支払いサーバノードにおける支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るための前記分散型データ配信ネットワーク内のキャッシャピアノードにおけるキャッシャクライアントモジュールシステムであって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによってアクセス可能なプログラムコードを格納するための非一時的物理媒体と
を備え、
前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに、
前記支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取らせ、ここで前記少額支払いプールは、前記少なくとも２つの視聴者ピアノードと前記データリソースを共有するための預金を符号化する積立て取引記録を前記ブロックチェーンに提示することによって作成され、
前記データリソースの第１の部分を前記少なくとも２つの視聴者ピアノードの第１の視聴者ピアノードにおける第１の視聴者クライアントモジュールと共有させ、ここで前記第１の視聴者ピアノードは、第１のピアツーピア接続によって前記キャッシャピアノードに接続されており、
前記データリソースの前記第１の部分に関する前記第１の視聴者クライアントモジュールによって暗号で署名された第１のサービス受領書を受け取らせ、
前記第１のサービス受領書を前記支払いサービスモジュールに提示させ、
前記支払いサービスモジュールから、前記データリソースの前記第１の部分に対する前記少額支払いプールから前記キャッシャピアノードに行われる第１の支払い額の第１の振込みを符号化する第１のオフチェーン取引記録を受け取らせ、
前記データリソースの第２の部分を前記少なくとも２つの視聴者ピアノードの第２の視聴者ピアノードにおける第２の視聴者クライアントモジュールと共有させ、ここで前記第２の視聴者ピアノードは、第２のピアツーピア接続によって前記キャッシャピアノードに接続されており、
前記データリソースの前記第２の部分に関する前記第２の視聴者クライアントモジュールによって暗号で署名された第２のサービス受領書を受け取らせ、
前記第２のサービス受領書を前記支払いサービスモジュールに提示させ、
前記第１のオフチェーン取引記録の更新として、前記支払いサービスモジュールから、前記データリソースの前記第１の部分および前記データリソースの前記第２の部分に対する前記少額支払いプールから前記キャッシャピアノードに行われる第２の支払い額の第２の振込みを符号化する第２のオフチェーン取引記録を受け取らせ、
前記少額支払いプールからの前記第２の支払い額を請求するために、前記第２のオフチェーン取引記録を前記ブロックチェーンに提示させる、キャッシャシステム。

【請求項9】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記データリソースを前記少なくとも２つの視聴者ピアノードと共有するためにピアグループに加入させ、
前記第１の視聴者ピアノードおよび前記第２の視聴者ピアノードとの前記データリソースの前記共有を認可する支払い許認可証を受け取らせる、請求項８に記載のキャッシャクライアントモジュールシステム。

【請求項10】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記支払い許認可証を前記支払いサービスモジュールに提示させる、請求項９に記載のキャッシャクライアントモジュールシステム。

【請求項11】

前記ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる、請求項８に記載のキャッシャクライアントモジュールシステム。

【請求項12】

前記ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックで前記ブロックチェーンを検証するために監視者ノードを用い、前記チェックポイントブロックは、前記ブロックチェーン内のブロックのサブセットである、請求項１１に記載のキャッシャクライアントモジュールシステム。

【請求項13】

前記通知は、前記積立て取引記録が新たなブロックに含まれた後の前記積立て取引記録のマークルプルーフを備える、請求項８に記載のキャッシャクライアントモジュールシステム。

【請求項14】

前記少額支払いプールは、前記データリソースのリソースＩＤ、時限錠、および削除可能な担保に関連付けられる、請求項８に記載のキャッシャクライアントモジュールシステム。

【請求項15】

分散型データ配信ネットワーク内の少なくとも２つの視聴者ピアノードとデータリソースを共有する対価として前記分散型データ配信ネットワーク内の支払いサーバノードにおける支払いサービスモジュールからブロックチェーンに基づく支払いを受け取るために前記分散型データ配信ネットワーク内のキャッシャピアノードにおけるキャッシャクライアントモジュールによって行われるプログラムコードを格納するための非一時的格納媒体であって、前記プログラムコードはプロセッサによって実行可能であり、前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに、
前記支払いサービスモジュールによるブロックチェーン上での少額支払いプールの作成について通知を受け取らせ、ここで前記少額支払いプールは、前記少なくとも２つの視聴者ピアノードと前記データリソースを共有するための預金を符号化する積立て取引記録を前記ブロックチェーンに提示することによって作成され、
前記データリソースの第１の部分を前記少なくとも２つの視聴者ピアノードの第１の視聴者ピアノードにおける第１の視聴者クライアントモジュールと共有させ、ここで前記第１の視聴者ピアノードは、第１のピアツーピア接続によって前記キャッシャピアノードに接続されており、
前記データリソースの前記第１の部分に関する前記第１の視聴者ピアノードによって暗号で署名された第１のサービス受領書を受け取らせ、
前記第１のサービス受領書を前記支払いサービスモジュールに提示させ、
前記支払いサービスモジュールから、前記データリソースの前記第１の部分に対する前記少額支払いプールから前記キャッシャピアノードに行われる第１の支払い額の第１の振込みを符号化する第１のオフチェーン取引記録を受け取らせ、
前記データリソースの第２の部分を前記少なくとも２つの視聴者ピアノードの第２の視聴者ピアノードにおける第２の視聴者クライアントモジュールと共有させ、ここで前記第２の視聴者ピアノードは、第２のピアツーピア接続によって前記キャッシャピアノードに接続されており、
前記データリソースの前記第２の部分に関する前記第２の視聴者クライアントモジュールによって暗号で署名された第２のサービス受領書を受け取らせ、
前記第２のサービス受領書を前記支払いサービスモジュールに提示させ、
前記第１のオフチェーン取引記録の更新として、前記支払いサービスモジュールから、前記データリソースの前記第１の部分および前記データリソースの前記第２の部分に対する前記少額支払いプールから前記キャッシャピアノードに行われる第２の支払い額の第２の振込みを符号化する第２のオフチェーン取引記録を受け取らせ、
前記少額支払いプールからの前記第２の支払い額を請求するために、前記第２のオフチェーン取引記録を前記ブロックチェーンに提示させる、非一時的記憶媒体。

【請求項16】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記データリソースを前記少なくとも２つの視聴者ピアノードと共有するためにピアグループに加入させ、
前記第１の視聴者ピアノードおよび前記第２の視聴者ピアノードとの前記データリソースの前記共有を認可する支払い許認可証を受け取らせる、請求項１５に記載の非一時的記憶媒体。

【請求項17】

前記プログラムコードは、前記プロセッサによって実行されると、前記プロセッサに更に、
前記支払い許認可証を前記支払いサービスモジュールに提示させる、請求項１６に記載の非一時的記憶媒体。

【請求項18】

前記ブロックチェーンは、ブロック決済プロセスにおいて新たなブロックをマイニングするためにマイニングノードの検証者委員会を用いる、請求項１５に記載の非一時的記憶媒体。

【請求項19】

前記ブロックチェーンは更に、ブロックファイナライズプロセスにおいて、チェックポイントブロックで前記ブロックチェーンを検証するために監視者ノードを用い、前記チェックポイントブロックは、前記ブロックチェーン内のブロックのサブセットである、請求項１８に記載の非一時的記憶媒体。

【請求項20】

前記通知は、前記積立て取引記録が新たなブロックに含まれた後の前記積立て取引記録のマークルプルーフを備える、請求項１５に記載の非一時的記憶媒体。

【国際調査報告】