JP7270714B2 - 利益分配のための方法、コンピューティングデバイス、及びシステム - Google Patents

Description

本発明は、利益分配のための方法、コンピューティングデバイス、及びシステムに関し、特に、供給者の信頼を得ながら、売上記録を保護することができる利益分配のための方法、コンピューティングデバイス、及びシステムに関する。

分散型台帳技術は、様々な分野において広く使用されている。分散型台帳ネットワークに記録されたデータは不変で否定できないため、分散型台帳は人々の信頼を得ている。しかし、ビジネスの観点からは、分散型台帳上のデータの透明性は、特定のシナリオでは歓迎されない可能性がある。

例えば、取引が利益分配に基づいている場合、売上記録（例えば、顧客からチャージされる手数料等）は、他の人に知られてはならない企業秘密であり得る。しかし、分配される利益は売上記録に基づいており、取引事業者に開示されるべきである。売上記録が隠されている場合、この取引の事業者間の信頼が失われる可能性がある。このような矛盾に直面して、分散型台帳技術の利点を維持し、売上記録を保護し、同時に供給者からの信頼を得る技術的方法を使用することは大きな課題である。

従って、本発明の目的は、供給者の信頼を得ながら、売上記録を保護することができる利益分配のための方法、コンピューティングデバイス、及びシステムを提供することである。

本発明は、利益分配の方法を開示している。当該方法は、第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップ；第１の分配率及び第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得るステップ；第２のイベント情報及び第２のカテゴリ情報に従って、第２の分配率を決めるステップ；第２の分配率及び第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得るステップ；第１の分配量及び第２の分配量を合計することによって、合計分配量を決めるステップ；並びに、ユーザデバイスからの要求を受信することに応答して、合計分配量を戻すステップ；を含む。

本発明は、さらに、利益分配のためのシステムを開示している。当該システムは、ユーザデバイスに接続され、さらに、複数のイベントレコードと共に記録される少なくとも１つの台帳を格納する分散型台帳ネットワーク；及び、分散型台帳ネットワークに接続されたコンピューティングデバイス；を含む。コンピューティングデバイスは：複数のイベントレコードに従って、第１のイベント情報、第１のカテゴリ情報、第２のイベント情報、及び第２のカテゴリ情報を得るステップ；第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップ；第１の分配率及び第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得るステップ；第２のイベント情報及び第２のカテゴリ情報に従って、第２の分配率を決めるステップ；第２の分配率及び第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得るステップ；第１の分配量及び第２の分配量を合計することによって、合計分配量を決めるステップ；並びに、ユーザデバイスからの要求を受信することに応答して、合計分配量を戻すステップ；を行う。

本発明は、さらに、利益分配のためのコンピューティングデバイスを開示している。当該コンピューティングデバイスは、複数のイベントレコードを格納する分散型台帳ネットワークに接続された通信デバイス；及び、通信デバイスに接続されたプロセッサ；を含む。プロセッサは：分散型台帳ネットワークの複数のイベントレコードに従って、第１のイベント情報、第１のカテゴリ情報、第２のイベント情報、及び第２のカテゴリ情報を得るステップ；第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップ；第１の分配率及び第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得るステップ；第２のイベント情報及び第２のカテゴリ情報に従って、第２の分配率を決めるステップ；第２の分配率及び第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得るステップ；第１の分配量及び第２の分配量を合計することによって、合計分配量を決めるステップ；並びに、ユーザデバイスからの要求を受信することに応答して、合計分配量を戻すステップ；を行う。

本発明のこれら及び他の目的は、何の疑いもなく、様々な図及び図面において例示されている好ましい実施形態の以下の詳細な説明を読んだ後に、当業者には明らかになる。

本発明の一実施形態における利益分配のためのシステムの概略図である。 本発明の別の実施形態における利益分配のためのシステムの概略図である。 本発明の一実施形態における利益分配のためのコンピューティングデバイスの概略図である。 本発明の一実施形態における利益分配の方法の流れ図である。

図１を参照すると、図１は、本発明の一実施形態における利益分配のためのシステム１００の概略図を例示している。利益分配のためのシステム１００は、コンピューティングデバイス１１０及び分散型台帳ネットワーク１２０を含み、コンピューティングデバイス１１０は、通信様式で分散型台帳ネットワーク１２０に接続されている。この実施形態では、コンピューティングデバイス１１０は、分散型台帳ネットワーク１２０にアクセスし、利益分配情報を得るためのソフトウェアを実行するサーバであってもよい。分散型台帳ネットワーク１２０は、複数のノードによって形成されてもよく、各ノードは、同一で不変の台帳を有している。この実施形態では、分散型台帳ネットワーク１２０は、ブロックチェーンネットワークである。ユーザデバイス１０～１４は、通信様式でコンピューティングデバイス１１０に接続することによって、利益分配システム１００に接続することができ、従って、利益分配情報を得ることができる。

図２を参照すると、図２は、本発明の別の実施形態における利益分配のためのシステム１００´の概略図を例示している。図１と同様に、システム１００´も、コンピューティングデバイス１１０及び分散型台帳ネットワーク１２０を含むが、コンピューティングデバイス１１０は、分散型台帳ネットワーク１２０上のノードである。すなわち、コンピューティングデバイス１１０も、不変な台帳を格納する。

図１及び図２のいずれも、単に例示を目的としたものであり、本発明は、これに限定されるものではないということに留意すべきである。例えば、外部サーバ及び外部データベースを、任意的に、システム１００又は１００´に接続することができる。ユーザデバイスの数は、３未満の数、３に等しい数、又は３を超える数であり得る。

図３を参照すると、図３は、本発明の一実施形態における利益分配のためのコンピューティングデバイス１１０の概略図を例示している。図１及び図２におけるコンピューティングデバイス１１０は、図３に示されているハードウェアとして実装することができる。

コンピューティングデバイス１１０は、通信デバイス１１２及びプロセッサ１１４を含む。通信デバイス１１２は、例えば、Ｗｉ－Ｆｉ、ＬＡＮ、Ｅｔｈｅｒｎｅｔ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、及びＬＴＥのうち少なくとも１つと互換性があるチップである。コンピューティングデバイス１１０は、通信デバイス１１２を介して分散型台帳ネットワーク１２０に接続される。

プロセッサ１１４は、コンピューティングデバイス１１０によって提供される機能を実装するために必要な全ての計算を行う。プロセッサは、例えば、ＣＰＵ、ＤＳＰ、ＡＳＩＰ、又は、計算能力を有する他の装置である。

一部の実施形態において、コンピューティングデバイス１１０は、任意的に、ハードディスクドライブ（ＨＤＤ）及びソリッドステートドライブ（ＳＳＤ）等の記憶装置を有して構成されてもよい。別の実施形態では、コンピューティングデバイス１１０は、外部装置（例えば、クラウドストレージ又はブロックチェーンネットワーク等）にデータを格納することができるが、本発明は、これに限定されない。

分散型台帳ネットワーク１２０のノードは、通信能力、格納スペース、及び計算能力を有する任意の装置、例えば、パーソナルコンピュータ、ノートブック、タブレット、及びモバイルデバイス等であってもよいが、本発明は、これらに限定されない。

ユーザデバイス１０～１４は、通信機能を有する任意の電子装置、例えば、パーソナルコンピュータ、ノートブック、タブレット、及びモバイルデバイス等であってもよく、本発明は、これらに限定されない。

図４は、本発明の一実施形態における利益分配の方法４０の流れ図を例示している。方法４０は、図１又は図２において例示されているシステム１００又は１００´のコンピューティングデバイス１１０上で実施されてもよいが、これに限定されない。

この実施形態では、システム１００又は１００´のシステムプロバイダが技術サービスを提供し、ユーザデバイス１０～１４は、供給者によって所有されてもよい。例えば、システムプロバイダは、商業広告を有するオンラインニュースを読者に提供し、広告主からの手数料を請求するニュースプラットフォームシステムとして、システム１００又は１００´を確立する。ユーザデバイス１０～１４は、システムプロバイダと利益を分配することができるニュースプロバイダによって所有される。以下の説明において、この例は、本発明を例示するために使用されることになるが、これに限定されない。この例において、広告はニュースページに表示され、例えば、広告は、ウィジェットに埋め込まれるか、又はニュースページ上でポップアップ表示される。言い換えると、ユーザがニュースページを読む場合、ユーザは同時に広告も見ることになる。

この実施形態の方法４０は、以下のステップを含む。

ステップＳ４１０：第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決める。

ステップＳ４２０：第１の分配率及び第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得る。

ステップＳ４３０：第２のイベント情報及び第２のカテゴリ情報に従って、第２の分配率を決める。

ステップＳ４４０：第２の分配率及び第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得る。

ステップＳ４５０：第１の分配量及び第２の分配量を合計することによって、合計分配量を決める。

ステップＳ４６０：ユーザデバイスからの要求を受信することに応答して、合計分配量を戻す。

カテゴリは、「ライフ」、「不動産」、「天気」、及び「ビジネス」であってもよいが、これらに限定されない。一例において、ニュースページは、その内容に従って異なるカテゴリに分けられる。例えば、ニュースの内容がレストランのオープニングに関するものである場合は、「ライフ」として分類される。ニュースページの内容が住宅の販売に関する場合は、「不動産」として分類される。ニュースページの内容が天気予報に関する場合は、「天気」として分類される。ニュースページの内容が最高経営責任者（ＣＥＯ）の話に関する場合は、「ビジネス」として分類される。簡潔にするために、以下の説明では２つのカテゴリのみが採用されるが、これに限定されない。

読者がニュースページに表示されている広告をクリックすると、イベントが検出される。別の実施形態では、読者がニュースのハイパーリンクをクリックすると、イベントが検出され、イベントレコードとして記録される。いずれの実施形態においても、イベントが属するカテゴリは、ニュースページの内容に従って決定される。例えば、クリックされる広告が「ライフ」のニュースに表示されているか又はそのニュースがハイパーリンクに接続されている場合、イベントは「ライフ」のカテゴリに属する。さらに、イベントが検出されると、クリックログ、ニュースの視聴時間、及びイベントのトラフィック値のうち少なくとも１つが、イベントレコードとして記録される。

この実施形態では、イベントレコードは、分散型台帳ネットワーク１２０（すなわちチェーン）に格納されるということに留意すべきである。すなわち、分散型台帳ネットワーク１２０にリンクされたいかなる装置も、イベントが発生したことを知ることができる。

各カテゴリは、カテゴリ情報に対応し、カテゴリ情報は、そのカテゴリの対応するイベントレコードから得られる。例えば、「ライフ」及び「不動産」のカテゴリが、それぞれ第１のカテゴリ情報及び第２のカテゴリ情報に対応し、第１のカテゴリ情報及び第２のカテゴリ情報はそれぞれ、イベントレコードに従って、イベントの合計クリック数、合計視聴時間、及び合計トラフィック値のうち少なくとも１つを含む。例えば、「ライフ」のカテゴリに対応するイベントレコードが１００クリックログである場合、第１のカテゴリ情報は、「クリック数，１００」であってもよい。「ライフ」のカテゴリに対応するイベントレコードが合計６０分である場合、第１のカテゴリ情報は、「時間，６０分」であってもよい。「ライフ」のカテゴリに対応するイベントレコードが合計１ギガビットである場合、第１のカテゴリ情報は、「トラフィック値，１ＧＢ」であってもよい。第２のカテゴリ情報も類似の方法で設定することができ、ここでは、簡潔にするためにさらに記載されない。

加えて、対応するカテゴリの合計の利益又は手数料も、各カテゴリ情報に含まれ、以後、合計利益と呼ばれる。

イベント情報は、特定のカテゴリ及び特定のエンティティ（すなわち、特定のニュースプロバイダ）のイベントレコードから得られる。例えば、第１のイベント情報は、「ライフ」のカテゴリ及びＡメディア企業に対応するイベントレコードから得られ、第２のイベント情報は、Ａメディア企業及び「不動産」のカテゴリに対応するイベントレコードから得られ、第３のイベント情報は、Ｂメディア企業及び「ライフ」のカテゴリに対応するイベントレコードから得られ、第４のイベント情報は、Ｂメディア企業及び「不動産」のカテゴリに対応するイベントレコードから得られる。第１のイベント情報、第２のイベント情報、第３のイベント情報、及び第４のイベント情報は、カテゴリ情報と類似の方法で設定することができ、ここでは、簡潔にするために記載されない。

一実施形態では、不正を回避するために、カテゴリ情報及びイベント情報は、正常なイベントレコードのみに従って決定されてもよい。言い換えると、異常なイベントレコード（すなわち、対応するイベントが異常なアクティビティとして決定される）は、除外されてもよい。異常なアクティビティは、例えば、特定のニュースに示されている広告が、特定のＩＰから１分間に１００回クリックされるといったことである。その場合、最初のクリックログのみが、正常なイベントレコードとして決定される。異常なアクティビティの判定基準は、システムプロバイダによって様々であってもよく、リリースされない場合があり、それによって、異常なアクティビティが判定基準をうまく逃れることを防いでいるが、これに限定されない。

カテゴリ情報及びイベント情報は、分散型台帳ネットワーク１２０に記録されても、されなくてもよい（例えば、第１のイベント情報、第１のカテゴリ情報、第２のイベント情報、及び第２のカテゴリ情報と共に記録された少なくとも１つの台帳を格納する）が、これに限定されないということに留意すべきである。

別の実施形態において、システム１００は、読者のトラックをトレースし、読まれたニュースの寄与率を決定して、それに応じて第１のイベント情報を得るようにすることができる。例えば、読者はまず、ホームページから最初のニュースをクリックし、次に、最初のニュースに埋め込まれたハイパーリンクをクリックすることによって、２番目のニュースを見る。３番目のニュースは、その後、２番目のニュースに埋め込まれたハイパーリンクをクリックすることによって表示され、次に、読者が３番目のニュースを見ている間にイベントが発生する。その場合、システム１００は、最初のニュース、２番目のニュース、及び３番目のニュースの寄与率を１０％、３０％、及び６０％と決定することができる。言い換えると、このイベントレコードがクリックログである場合、最初のニュースには０．１クリック数が与えられ、２番目のニュースには０．３クリック数が与えられ（例えば、余分なクリック数が与えられるか又はクリック数をシェアし）、３番目のニュースには０．６クリック数が与えられ、対応するカテゴリ情報及び対応するイベント情報がそれに応じて更新される。一例では、読者がホームページに戻ったときに、依存関係がリセットされてもよい。別の例では、システム１００は、クリック数を、限定された依存レベルにのみ（すなわち、３つのレベル単位（ｔｈｅ ｎｅａｒｅｓｔ ｔｈｒｅｅ ｌｅｖｅｌｓ）で）分け、これに限定されない。また、システムプロバイダの方針に従って、依存関係及び寄与のレベルを決めることができるが、これに限定されない。

ステップＳ４１０において、コンピューティングデバイス１１０は、第１のイベント情報（例えば、「ライフ」のカテゴリに対応し、Ａメディア企業によって提供されるイベント情報等）及び第１のカテゴリ情報（例えば、「ライフ」のカテゴリに対応するイベント情報等）に従って、第１の分配率を決める。具体的には、第１のイベント情報が第１のクリック数から得られる場合、コンピューティングデバイス１１０は、第１のカテゴリ情報の合計のクリック数に対する第１のクリック数の比率を、第１の分配率として計算する。第１のイベント情報が第１の視聴時間から得られる場合、コンピューティングデバイス１１０は、第１のカテゴリ情報の合計視聴時間に対する第１の視聴時間の比率を、第１の分配率として計算する。第１のイベント情報が第１のトラフィック値から得られる場合、コンピューティングデバイス１１０は、第１のカテゴリ情報の合計のトラフィック値に対する第１のトラフィック値の比率を、第１の分配率として計算する。

ステップＳ４２０において、コンピューティングデバイス１１０は、第１の分配率及び第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得る。詳細には、システムプロバイダは、広告主と（例えば、スマートコントラクトによって）手数料協定を結ぶことができる。従って、対応する手数料協定に従って利益を得ることができ、第１のカテゴリに属する全てのイベントの利益に従って第１のカテゴリの合計利益を得ることができる。

第１の分配される利益は、システムプロバイダのポリシーに従って決定される。第１の分配される利益は、第１のカテゴリの合計利益の特定の割合であってもよい。この実施形態において、特定の割合は、５０％として与えられる（すなわち、第１の分配される利益＝第１のカテゴリの合計利益の５０％である）が、これに限定されない。コンピューティングデバイス１１０は、第１のカテゴリ情報から第１の分配される利益を得て、第１の分配率と第１の分配される利益とを乗じることによって第１の分配量を計算する。

ステップＳ４３０において、コンピューティングデバイス１１０は、第２のイベント情報（例えば、「不動産」のカテゴリに対応し、Ａメディア企業によって提供されるイベント情報等）及び第２のカテゴリ情報（例えば、「不動産」のカテゴリに対応するイベント情報等）に従って、第２の分配率を決める。ステップＳ４４０において、コンピューティングデバイス１１０は、第２の分配率及び第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得る。ステップＳ４３０～Ｓ４４０は、ステップＳ４１０及びＳ４２０と類似しており、ここでは、さらなる詳細は記載されない。

第１／第２の分配される利益に対応する特定の割合は異なっていてもよく、例えば、第１の分配される利益に対応する特定の割合は５０％であってもよく、第２の分配される利益に対応する特定の割合は３０％であってもよい。一部の実施形態において、特定の割合は浮動小数点値（ａ ｆｌｏａｔｉｎｇ ｖａｌｕｅ）であってもよく、対応する利益によって影響され得る。詳細には、システム１００の費用比率は、利益が高く成長している場合に比較的低く、従って、利益が閾値よりも高い場合には、特定の割合は高くなることがある。特定の割合は、任意の様々な方法で設定することができ、これに限定されない。

ステップＳ４５０において、コンピューティングデバイス１１０は、第１の分配量及び第２の分配量を合計することによって、合計分配量を決める。

詳細には、ステップＳ４２０及びＳ４４０において言及される分配量は、以下の式（１）：

によって表すことができる。ｘ_ｎは、カテゴリｎに対応する分配される利益である。ｆ_ｎ（ｋ）は、カテゴリｎに対応するニュースプロバイダｋの分配率である。ｙは、ニュースプロバイダｋに属するカテゴリに対応する分配量である。

分配量の式は、分配ポリシーに従って異なっていてもよいということに留意すべきである。例えば、分配量を、以下の式（２）：

に従って得ることもできる。ｘ_ｎ、ｆ_ｎ（ｋ）、及びｙは、式（１）のパラメータと同じであるが、ｍは、以下のように分配ポリシーに従って決められる動的パラメータである（例えば、より高い分配率が、より高い又はより低い動的パラメータに対応してもよく、従って、より高い又はより低い多くの分配量が、実用的な要求に従って得られる）。

別の例では、以下の式（３）：

に従って分配量を得ることができる。

式（３）は、式（２）と類似している。しかし、式（３）は、動的ｍ（ｉ）を乗じることによる累進割合であり、式（２）は、一定割合である。分配量の式は、式（１）～（３）に限定されず、本発明においては、任意の適切な変形を認めることができる。

従って、例えば、式（１）を受け入れて、ステップＳ４５０を、以下の式（４）～（６）：

によって表すことができる。

上記のように、第１の分配量及び第２の分配量は、同じエンティティ（ニュースプロバイダｋ）に対応し、従って、集約した合計分配量も、同じエンティティに対応する。

さらに、条件が満たされた場合に、ステップＳ４１０～Ｓ４５０が行われてもよい。一例において、条件は、例えば、１週間、１ヶ月、３ヶ月、半年、又は１年といった特定の期間であるが、これらに限定されない。別の例において、条件は、イベント情報又はカテゴリ情報の予め設定された閾値であってもよい。例えば、カテゴリ情報の１つが閾値（すなわち、１０，０００クリック）に達した場合、又はエンティティのイベント情報が閾値（すなわち、対応するカテゴリの１，０００クリック又は２０％クリック）に達した場合、ステップＳ４１０～Ｓ４５０は自動的に行われる。別の例では、カテゴリの（クリックに対応する）利益の１つが特定の量に達すると、それに従ってステップＳ４１０～Ｓ４５０は行われる。別の例では、新しいニュースプロバイダがこの利益分配プロジェクトに加わり、システム１００に登録すると、ステップＳ４１０～Ｓ４５０は、現在の分配される量の合意のために行われる。別の例では、ステップＳ４１０～Ｓ４５０は、手動アクティベーションによって行われる。本発明は、これらに限定されない。

加えて、一事例において、ステップＳ４１０～Ｓ４５０は、要求が受信される毎に行われてもよい。別の例において、ステップＳ４１０～Ｓ４５０は１回のみ行われ、ステップＳ４１０～Ｓ４５０が初めて行われた後、第１／第２のイベント情報、第１／第２のカテゴリ情報、第１／第２の分配率、第１／第２の分配量、及び合計分配量が、履歴情報として記録され、さらに、第１／第２のイベント情報及び第１／第２のカテゴリ情報が、対応してリセットされる。さらに、コンピューティングデバイス１１０は、格納された履歴の合計分配量を読み出すことによって、合計分配量を戻す。

ステップＳ４６０において、コンピューティングデバイス１１０は、ユーザデバイス１０～１４のうち１つからの要求を受信することに応答して、合計分配量を戻す。

以下は、さらなる例示のための事例である。３つの異なるニュースプロバイダのみが存在し、２つの異なるカテゴリのニュースのみ存在する場合、以下の表のような事例があり得る：

この例では、第１のカテゴリＣ１の合計利益は２ｘ_１であり、第１のカテゴリＣ１の分配される利益はｘ_１（第１のカテゴリＣ１の合計利益の５０％）である。上記のように、カテゴリＣ１下の各ニュースプロバイダの分配率は、カテゴリ情報（のイベントレコード）に対するイベント情報（のイベントレコード）の比率に従って決定され、従って、カテゴリＣ１における異なるニュースプロバイダＰ１、Ｐ２、及びＰ３の分配率の全ての合計は１００％となるべきであり、上記の表を参照されたい。

加えて、分配量は、この例においては式（１）に従って得られる。従って、ニュースプロバイダＰ１に対しては、第１の分配率は２０％であり、第２の分配率は４０％であり、カテゴリＣ１における２０％の分配される利益、及びカテゴリＣ２における４０％の分配される利益が得られ、従って、合計の分配される利益Ｙｐ_１は：

として表すことができる。

同様に、ニュースプロバイダＰ２、Ｐ３の合計の分配される利益Ｙｐ_２、Ｙｐ_３は：

として表すことができる。

さらに、合計分配量は：

として表すことができる。

そのような状況下では、カテゴリｎの分配される利益ｘ_ｎ及び対応する合計利益を、ユーザデバイスによって計算することができないように、コンピューティングデバイス１１０は、ユーザデバイスからの要求に応答して、式（１）～（６）におけるデータの一部のみを戻してもよい。一例において、コンピューティングデバイス１１０は、第１の分配率（例えばｆ_１（ｋ）等）及び第２の分配率（例えばｆ_２（ｋ）等）、又は第１のイベント情報、第１のカテゴリ情報、第２のイベント情報、及び第２のカテゴリ情報を戻さない。しかし、分散型台帳ネットワーク１２０から、分配量の式（すなわち、式（１））を得ることができる。所与の合計分配量（例えばＹ等）の下で、第１の分配利益（例えばｘ_１等）、第２の分配利益（例えばｘ_２等）、第１の分配率（例えばｆ_１（ｋ）等）、及び第２の分配率（例えばｆ_２（ｋ）等）の多くの異なる組み合わせが存在するため、第１／第２の分配率、第１／第２のイベント情報、第１／第２のカテゴリ情報、及び第１／第２のカテゴリ利益の正確な値を知ることは不可能である。

別の例において、コンピューティングデバイス１１０は、合計分配量（例えばＹ等）、第１の分配率（例えばｆ_１（ｋ）等）、及び第２の分配率（例えばｆ_２（ｋ）等）を戻す。しかし、分配量の式（例えば、式（１）～（３）のうちどれ、及び動的パラメータｍ又はｍｋ等）はユーザには不明である。従って、ニュースプロバイダは、合計分配量、第１の分配率、及び第２の分配率をせいぜい知ることができる。正確な第１のカテゴリ利益の第１の分配量及び第２のカテゴリ利益の第２の分配量を推論によって知ることは困難である。

別の例において、コンピューティングデバイス１１０は、合計分配量（例えばＹ等）、第１の分配率（例えばｆ_１（ｋ）等）、及び第２の分配率（例えばｆ_２（ｋ）等）を戻し、ここでも、式（１）を分散型台帳ネットワーク１２０から得ることができる。ユーザでさえも、第１／第２の分配率及び式（１）を知っているが、第１／第２の分配率（例えばｆ_１（ｋ）／ｆ_２（ｋ）等）と第１／第２のカテゴリ利益（例えばｘ_１／ｘ_２等）との組み合わせは、特定の合計分配量（例えばＹ等）の下で無限に近づいている。従って、第１／第２のカテゴリ利益を得ることは困難である。

別の例において、コンピューティングデバイス１１０は、式（１）及び第１／第２の分配率（例えばｆ_１（ｋ）／ｆ_２（ｋ）等）なしで、第１の分配量（例えばｙ_１等）及び第２の分配量（例えばｙ_２等）を戻す。或いは、コンピューティングデバイス１１０は、第１／第２の分配量及び分配量の式を戻すが、第１／第２の分配率はユーザには不明である。従って、第１のカテゴリの実際の利益及び第２のカテゴリの実際の利益の正確な値を知ることは困難である。

要するに、コンピューティングデバイス１１０は、第１／第２のカテゴリ利益の漏れを回避するために、分配量、分配率のみを戻してもよく又はそのどちらも戻さなくてもよい。第１／第２のカテゴリの分配される利益がユーザに不明である場合、いかなる変形も採用することができる。

上記の説明においては、第１／第２のイベント情報、第１／第２の分配率、第１／第２の分配量、及び第１／第２のカテゴリ情報のみ（すなわち、２）が記載されているが、イベント情報、分配率、分配量、カテゴリ情報の数はこれに限定されないということに留意すべきである。

この実施形態の別の例において、ニュースの代わりに、広告が異なるカテゴリに分割される。従って、どのカテゴリにイベントが属するかは、広告の内容に従って決定される。

第１のイベント情報及び第２のイベント情報はそれぞれ、異なるカテゴリに対応するが、同じエンティティ（すなわち、ニュースプロバイダ）に対応する。具体的には、第１のイベント情報が、Ａメディア企業によって提供されたニュースに表示される「ライフ」の広告がクリックされたことに対応するイベントレコードから得られる。第２のイベント情報が、Ａメディア企業によって提供されたニュースに表示される「不動産」の広告がクリックされたことに対応するイベントレコードから得られる。また、別のイベント情報が、Ｂメディア企業によって提供されたニュースに表示される「ライフ」の広告がクリックされたことに対応するイベントレコードから得られてもよい。

利益分配の方法は、この例のカテゴリ及びイベントの情報の設定に従って実施されてもよく、その詳細については、上記の説明を参照することができるが、ここでは、簡潔にするために繰り返すことはしない。

しかし、ニュースプロバイダは、各カテゴリの実際の利益量を知らないため、本発明は、さらに、ニュースプロバイダがこの利益分配方法を信頼するための証明様式を提供する。この証明様式は、証明のために合計証明分配量（ａ ｔｏｔａｌ ｐｒｏｏｆ ｓｈａｒｉｎｇ ａｍｏｕｎｔ）を戻すように、ニュースプロバイダから証明利益（ｐｒｏｏｆ ｐｒｏｆｉｔｓ）を受信して（例えば、ニュースプロバイダは、任意の値として証明利益を設定することができる）、式（１）～（６）における分配される利益ｘ_ｎと置き換える。

従って、一実施形態において、コンピューティングデバイス１１０は、ユーザデバイス１０～１４から第１の証明利益及び第２の証明利益を受信する。コンピューティングデバイス１１０は、第１の分配率及び第１の証明利益に従って第１の証明量（ｐｒｏｏｆ ａｍｏｕｎｔ）を得て、第２の分配率及び第２の証明利益に従って第２の証明量を得る。従って、コンピューティングデバイス１１０は、第１の証明量及び第２の証明量を合計することによって合計証明分配量を決め、その合計証明分配量をユーザデバイス１０～１４まで戻す。

すなわち、ニュースプロバイダは、任意の証明利益量を入力して、その出力が正しいかどうかをチェックすることができる。ニュースプロバイダによって入力された証明利益及びニュースプロバイダに提供された他の情報を用いて出力が常に正しい場合、ニュースプロバイダは、システム１００及びコンピューティングデバイス１１０は信頼できると仮定すること（ゼロ知識証明）ができる。

この実施形態では、ニュースプロバイダからの入力は、証明のためだけのものである。従って、証明利益の入力及び対応する合計証明分配量の出力は、分散型台帳ネットワーク１２０に格納されない。

本発明は、異なるシナリオで使用することができるということに留意すべきであり、例えば、システムプロバイダは、出版社が旅行ノートを発行し、ポストに異なる旅行代理店の対応する旅行ツアーを自動的に添付することを可能にする旅行ブログのプラットフォームを提供することができる。

旅行ツアーがクリック又は予約されると、システムプロバイダは旅行代理店に料金を請求し、利益を出版社に分配する。又は、システムプロバイダは、対応するローカルホテルを自動的に添付することができ、ホテルがクリック又は予約されると、システムプロバイダがホテルに料金を請求し、その利益を出版社に分配する。本発明の上記の実施形態によって、どの旅行代理店から利益が得られるかを出版社が知ることはない。

要約すると、本発明の実施形態は、売上記録（例えば、分配される利益）を保護し、同時に供給者の信頼を得ながら、分散型台帳技術の利点を維持することができる。

当業者は、本発明の教示を保持しながら、装置及び方法の多くの修正及び変更を行うことができるということを容易に認めることになる。従って、上記の開示は、添付の特許請求の範囲によってのみ限定されると解釈されるべきである。

Claims (10)

1. コンピューティングデバイスを介したブロックチェーン上での利益分配の方法であって、前記ブロックチェーンは複数のノードを有し、各ノードは、複数のイベントレコードと共に記録される同一で不変の台帳を有し、前記利益は商業広告から得られ、前記コンピューティングデバイスは、前記ブロックチェーンにアクセスして当該方法を行い、当該方法は、
   オンライン情報プラットフォームに基づき、第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップと、
   前記第１の分配率及び前記第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得るステップと、
   前記オンライン情報プラットフォームに基づき、第２のイベント情報及び第２のカテゴリ情報に従って、第２の分配率を決めるステップと、
   前記第２の分配率及び前記第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得るステップと、
   前記第１の分配量及び前記第２の分配量を合計することによって、合計分配量を決めるステップと、
   ユーザデバイスからの要求を受信することに応答して、前記合計分配量を戻すステップであり、
   前記第１のイベント情報、前記第１のカテゴリ情報、前記第２のイベント情報、及び前記第２のカテゴリ情報の値セット、
   前記第１の分配率及び前記第２の分配率の値セット、並びに
   前記第１の分配量及び前記第２の分配量の値セット、
   のうち少なくとも１つを戻すことなく、前記合計分配量を戻すステップと、
   前記ユーザデバイスから、第１の証明利益及び第２の証明利益を受信することに応答して、利益検証方法を行うステップであり、前記利益検証方法は、
   前記第１の分配率及び前記第１の証明利益に従って、第１の証明量を得るステップ、
   前記第２の分配率及び前記第２の証明利益に従って、第２の証明量を得るステップ、
   前記第１の証明量及び前記第２の証明量を合計することによって、合計証明分配量を決めるステップ、並びに
   戻された合計証明分配量の信頼性をチェックするために、前記合計証明分配量を前記ユーザデバイスに戻すステップ、
   を含む、ステップと、
   を含み、前記複数のイベントレコードに従って、読者のトラックがトレースされ、さらに、前記第１のカテゴリ情報、前記第２のカテゴリ情報、前記第１のイベント情報、又は前記第２のイベント情報は、前記読者のトラックに従って得られるか若しくは更新される、方法。
2. ニュースページに表示された広告のクリック又はニュースのハイパーリンクのクリックに応答してイベントを検出するステップと、
   前記イベントの検出に応答してイベントレコードを記録するステップであって、前記イベントレコードは、ブロックチェーンに記録され、クリックログ、視聴時間、及びトラフィック値のうち少なくとも１つに対応する、ステップと、
   前記イベントレコードの正常なイベントレコードに従って、前記第１のカテゴリ情報、前記第２のカテゴリ情報、前記第１のイベント情報、及び前記第２のイベント情報を決定するステップと、
   をさらに含む、請求項１に記載の方法。
3. 前記第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップは、
   前記第１のカテゴリ情報の第１のカテゴリクリック数に対する前記第１のイベント情報の第１のクリック数の比率を、前記第１の分配率として計算すること、
   前記第１のカテゴリ情報の第１のカテゴリ視聴時間に対する前記第１のイベント情報の第１の視聴時間の比率を、前記第１の分配率として計算すること、及び
   前記第１のカテゴリ情報の第１のカテゴリトラフィック値に対する前記第１のイベント情報の第１のトラフィック値の比率を、前記第１の分配率として計算すること、
   のうち少なくとも１つを含む、請求項１に記載の方法。
4. ユーザデバイスに接続された、利益分配のためのシステムであって、前記利益は商業広告から得られ、当該システムは、
   複数のノードを有し、さらに、各ノードにおいて、複数のイベントレコードと共に記録される少なくとも１つの台帳を格納する分散型台帳ネットワークと、
   前記分散型台帳ネットワークにアクセスするコンピューティングデバイスと、
   を含み、
   前記コンピューティングデバイスは、
   前記複数のイベントレコードに従って、第１のイベント情報、第１のカテゴリ情報、第２のイベント情報、及び第２のカテゴリ情報を得るステップと、
   オンライン情報プラットフォームに基づき、前記第１のイベント情報及び前記第１のカテゴリ情報に従って、第１の分配率を決めるステップと、
   前記第１の分配率及び前記第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得るステップと、
   前記オンライン情報プラットフォームに基づき、前記第２のイベント情報及び前記第２のカテゴリ情報に従って、第２の分配率を決めるステップと、
   前記第２の分配率及び前記第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得るステップと、
   前記第１の分配量及び前記第２の分配量を合計することによって、合計分配量を決めるステップと、
   ユーザデバイスからの要求を受信することに応答して、前記合計分配量を戻すステップであり、
   前記第１のイベント情報、前記第１のカテゴリ情報、前記第２のイベント情報、及び前記第２のカテゴリ情報の値セット、
   前記第１の分配率及び前記第２の分配率の値セット、並びに
   前記第１の分配量及び前記第２の分配量の値セット、
   のうち少なくとも１つを戻すことなく、前記合計分配量を戻すステップと、
   前記ユーザデバイスから、第１の証明利益及び第２の証明利益を受信することに応答して、利益検証方法を行うステップであり、前記利益検証方法は、
   前記第１の分配率及び前記第１の証明利益に従って、第１の証明量を得るステップ、
   前記第２の分配率及び前記第２の証明利益に従って、第２の証明量を得るステップ、
   前記第１の証明量及び前記第２の証明量を合計することによって、合計証明分配量を決めるステップ、並びに
   戻された合計証明分配量の信頼性をチェックするために、前記合計証明分配量を前記ユーザデバイスに戻すステップ、
   を含む、ステップと、
   を行い、前記複数のイベントレコードに従って、読者のトラックがトレースされ、さらに、前記第１のカテゴリ情報、前記第２のカテゴリ情報、前記第１のイベント情報、又は前記第２のイベント情報は、前記読者のトラックに従って得られるか若しくは更新される、システム。
5. 前記コンピューティングデバイスは、前記分散型台帳ネットワークの複数のノードのうちの１つである、請求項４に記載のシステム。
6. 前記コンピューティングデバイスは、さらに、
   ニュースページに表示された広告のクリック又はニュースのハイパーリンクのクリックに応答してイベントを検出するステップと、
   前記イベントの検出に応答してイベントレコードを記録するステップであって、前記イベントレコードは、ブロックチェーンに記録され、クリックログ、視聴時間、及びトラフィック値のうち少なくとも１つに対応する、ステップと、
   前記イベントレコードの正常なイベントレコードに従って、前記第１のカテゴリ情報、前記第２のカテゴリ情報、前記第１のイベント情報、及び前記第２のイベント情報を決定するステップと、
   を行う、請求項４に記載のシステム。
7. 前記第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップは、
   前記第１のカテゴリ情報の第１のカテゴリクリック数に対する前記第１のイベント情報の第１のクリック数の比率を、前記第１の分配率として計算すること、
   前記第１のカテゴリ情報の第１のカテゴリ視聴時間に対する前記第１のイベント情報の第１の視聴時間の比率を、前記第１の分配率として計算すること、及び
   前記第１のカテゴリ情報の第１のカテゴリトラフィック値に対する前記第１のイベント情報の第１のトラフィック値の比率を、前記第１の分配率として計算すること、
   のうち少なくとも１つを含む、請求項４に記載のシステム。
8. 利益分配のためのコンピューティングデバイスであって、前記利益は商業広告から得られ、当該コンピューティングデバイスは、
   複数のノードを有する分散型台帳ネットワークに接続された通信デバイスであり、前記分散型台帳ネットワークは、各ノードにおいて、複数のイベントレコードと共に記録される少なくとも１つの台帳を格納する、通信デバイスと、
   前記通信デバイスに接続されたプロセッサであり、
   前記分散型台帳ネットワークの前記複数のイベントレコードに従って、第１のイベント情報、第１のカテゴリ情報、第２のイベント情報、及び第２のカテゴリ情報を得るステップと、
   オンライン情報プラットフォームに基づき、前記第１のイベント情報及び前記第１のカテゴリ情報に従って、第１の分配率を決めるステップと、
   前記第１の分配率及び前記第１のカテゴリ情報の第１の分配される利益に従って、第１の分配量を得るステップと、
   前記オンライン情報プラットフォームに基づき、前記第２のイベント情報及び前記第２のカテゴリ情報に従って、第２の分配率を決めるステップと、
   前記第２の分配率及び前記第２のカテゴリ情報の第２の分配される利益に従って、第２の分配量を得るステップと、
   前記第１の分配量及び前記第２の分配量を合計することによって、合計分配量を決めるステップと、
   ユーザデバイスからの要求を受信することに応答して、前記合計分配量を戻すステップであり、
   前記第１のイベント情報、前記第１のカテゴリ情報、前記第２のイベント情報、及び前記第２のカテゴリ情報の値セット、
   前記第１の分配率及び前記第２の分配率の値セット、並びに
   前記第１の分配量及び前記第２の分配量の値セット、
   のうち少なくとも１つを戻すことなく、前記合計分配量を戻すステップと、
   前記ユーザデバイスから、第１の証明利益及び第２の証明利益を受信することに応答して、利益検証方法を行うステップであり、前記利益検証方法は、
   前記第１の分配率及び前記第１の証明利益に従って、第１の証明量を得るステップ、
   前記第２の分配率及び前記第２の証明利益に従って、第２の証明量を得るステップ、
   前記第１の証明量及び前記第２の証明量を合計することによって、合計証明分配量を決めるステップ、並びに
   戻された合計証明分配量の信頼性をチェックするために、前記合計証明分配量を前記ユーザデバイスに戻すステップ、
   を含む、ステップと、
   を行うプロセッサと、
   を含み、前記複数のイベントレコードに従って、読者のトラックがトレースされ、さらに、前記第１のカテゴリ情報、前記第２のカテゴリ情報、前記第１のイベント情報、又は前記第２のイベント情報は、前記読者のトラックに従って得られるか若しくは更新される、コンピューティングデバイス。
9. 前記プロセッサは、さらに、
   ニュースページに表示された広告のクリック又はニュースのハイパーリンクのクリックに応答してイベントを検出するステップと、
   前記イベントの検出に応答してイベントレコードを記録するステップであって、前記イベントレコードは、ブロックチェーンに記録され、クリックログ、視聴時間、及びトラフィック値のうち少なくとも１つに対応する、ステップと、
   前記イベントレコードの正常なイベントレコードに従って、前記第１のカテゴリ情報、前記第２のカテゴリ情報、前記第１のイベント情報、及び前記第２のイベント情報を決定するステップと、
   を行う、請求項８に記載のコンピューティングデバイス。
10. 前記第１のイベント情報及び第１のカテゴリ情報に従って、第１の分配率を決めるステップは、
    前記第１のカテゴリ情報の第１のカテゴリクリック数に対する前記第１のイベント情報の第１のクリック数の比率を、前記第１の分配率として計算すること、
    前記第１のカテゴリ情報の第１のカテゴリ視聴時間に対する前記第１のイベント情報の第１の視聴時間の比率を、前記第１の分配率として計算すること、及び
    前記第１のカテゴリ情報の第１のカテゴリトラフィック値に対する前記第１のイベント情報の第１のトラフィック値の比率を、前記第１の分配率として計算すること、
    のうち少なくとも１つを含む、請求項８に記載のコンピューティングデバイス。

Images