(57)【要約】  ユーザの権利を保存する権利ブロックチェーンの生成が、ユーザから登録要求及び公開鍵を受け取るステップと、ユーザが公開鍵に対応する秘密鍵を有していることを検証するステップと、公開鍵を用いてユーザ識別子を生成するステップと、ユーザ識別子を含むジェネシスブロックを有する権利ブロックチェーンを生成してユーザに提供するステップと、を含む。【選択図】      図３
2019532603.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの権利を保存する権利ブロックチェーンの生成方法であって、
前記ユーザから登録要求及び公開鍵を受け取るステップと、
前記ユーザが前記公開鍵に対応する秘密鍵を有していることを検証するステップと、
前記公開鍵を用いてユーザ識別子を生成するステップと、
前記ユーザ識別子を含むジェネシスブロックを有する前記権利ブロックチェーンを生成して前記ユーザに提供するステップと、
を含むことを特徴とする方法。
【請求項２】
前記公開鍵が既に登録済みである場合、異なる公開鍵を要求するステップをさらに含む、
請求項１に記載の方法。
【請求項３】
前記コンテンツのコンテンツ識別子と関連する使用権とを有する新たなブロックを含む前記権利ブロックチェーンを更新するステップをさらに含む、
請求項１に記載の方法。
【請求項４】
前記コンテンツ識別子を有するコンテンツを前記ユーザが取得した旨の情報をコンテンツプロバイダから受け取るステップをさらに含む、
請求項３に記載の方法。
【請求項５】
前記関連する使用権は、認可された言語及び字幕言語のリストを含む、
請求項３に記載の方法。
【請求項６】
ユーザの権利を保存する権利ブロックチェーンを生成するためのシステムであって、前記ユーザから登録要求及び公開鍵を受け取るように構成されるとともに、前記ユーザが前記公開鍵に対応する秘密鍵を有していることを検証し、前記公開鍵を用いてユーザ識別子を生成し、前記ユーザ識別子を含むジェネシスブロックを有する前記権利ブロックチェーンを生成して前記ユーザに提供するようにさらに構成された登録認定機関を備える、
ことを特徴とするシステム。
【請求項７】
前記ユーザがコンテンツを取得した旨を前記登録認定機関に通知するように構成されたコンテンツプロバイダをさらに備える、
請求項６に記載のシステム。
【請求項８】
前記登録認定機関は、前記権利ブロックチェーンを受け取って、前記コンテンツのコンテンツ識別子と関連する使用権とを有する新たなブロックを含む前記権利ブロックチェーンを更新するようにも構成される、
請求項７に記載のシステム。
【請求項９】
前記コンテンツプロバイダは、前記更新された権利ブロックチェーン内の前記コンテンツ識別子に対応する前記コンテンツをスクランブル化して、前記コンテンツのスクランブルバージョンを生成するようにも構成される、
請求項８に記載のシステム。
【請求項１０】
ユーザの権利を保存する権利ブロックチェーンを使用してデジタル権利管理を実行する方法であって、
コンテンツ識別子と、スクランブルエッセンスと、暗号化制御ワードとを含む保護コンテンツを受け取るステップと、
前記権利ブロックチェーンと前記ユーザの認証情報とを受け取るステップと、
前記保護コンテンツの前記コンテンツ識別子を含む第１のブロックを求めて前記権利ブロックチェーンを検索するステップと、
前記第１のブロック内の署名及び使用権が有効であると判定された時に、前記暗号化制御ワードを復号するステップと、
前記復号された制御ワードを用いて前記スクランブルエッセンスをスクランブル解除するステップと、
を含むことを特徴とする方法。
【請求項１１】
前記権利ブロックチェーンの完全性チェックを実行して、前記権利ブロックチェーンに障害が無く改竄もされていないことを確認するステップをさらに含む、
請求項１０に記載の方法。
【請求項１２】
前記権利ブロックチェーンは、前記ユーザのユーザ識別子を有するジェネシスブロックを含む、
請求項１０に記載の方法。
【請求項１３】
前記第１のブロックの前記署名及び前記使用権が有効であるかどうかを判定するステップをさらに含む、
請求項１０に記載の方法。
【請求項１４】
コンテンツアイテムを消費するためのユーザの権利を保存する権利ブロックチェーンの生成方法であって、
前記ユーザから登録要求及び公開鍵を受け取って、前記ユーザが前記公開鍵に対応する秘密鍵を有していることを検証するステップと、
前記公開鍵を用いて、前記ユーザのユーザ識別子を含むジェネシスブロックを生成するステップと、
前記コンテンツアイテムのコンテンツ識別子と関連する使用権とを有する新たなブロックを生成して追加するステップと、
を含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
〔関連出願との相互参照〕
本出願は、２０１６年１０月２０に出願された「ブロックチェーンに基づくＤＲＭ（Ｂｌｏｃｋｃｈａｉｎ−Ｂａｓｅｄ  ＤＲＭ）」という名称の同時係属中の米国仮特許出願第６２／４１０，５５７号の合衆国法典第３５編第１１９条（ｅ）に基づく優先権を主張するものである。上記関連出願の開示は、引用により本明細書に組み入れられる。
【０００２】
本開示は、デジタル権利管理（ＤＲＭ）に関し、具体的には、ブロックチェーンを用いてＤＲＭを実施することに関する。
【背景技術】
【０００３】
通常、現在の多くのＤＲＭソリューションでは、相互運用性のために、権利ロッカー、或いはベンダー又はベンダーグループが管理するその他の共通ストレージが必要である。しかしながら、これらの従来の解決策はそれほど信頼性が高くなく、１つの特異な障害点に依拠することがある。権利ロッカーのプロバイダ又はシステムが廃業したり、或いは別様に失敗した場合、ユーザは、取得した全てのコンテンツを失ってしまう。
【０００４】
今日の多くの相互運用可能な解決策は、１つのコンテンツの使用権を１人のユーザ及び１つの特定のプラットフォーム専用のライセンスに保存するという共通アーキテクチャに基づく。例えば、権利ロッカー及び管理のための１つの共通の解決策はＵｌｔｒａＶｉｏｌｅｔ（商標）である。
【発明の概要】
【課題を解決するための手段】
【０００５】
本開示は、権利ブロックチェーンを用いた相互運用可能なデジタル権利管理（ＤＲＭ）の実施を可能にする。
【０００６】
１つの実装では、ユーザの権利を保存する権利ブロックチェーンの生成方法を開示する。この方法は、ユーザから登録要求及び公開鍵を受け取るステップと、ユーザが公開鍵に対応する秘密鍵を有していることを検証するステップと、公開鍵を用いてユーザ識別子を生成するステップと、ユーザ識別子を含むジェネシスブロックを有する権利ブロックチェーンを生成してユーザに提供するステップと、を含む。
【０００７】
別の実装では、ユーザの権利を保存する権利ブロックチェーンを生成するためのシステムを開示する。このシステムは、ユーザから登録要求及び公開鍵を受け取るように構成されるとともに、ユーザが公開鍵に対応する秘密鍵を有していることを検証し、公開鍵を用いてユーザ識別子を生成し、ユーザ識別子を含むジェネシスブロックを有する権利ブロックチェーンを生成してユーザに提供するようにさらに構成された登録認定機関を含む。
【０００８】
さらに別の実装では、ユーザの権利を保存する権利ブロックチェーンを使用してデジタル権利管理を実行する方法を開示する。この方法は、コンテンツ識別子と、スクランブルエッセンスと、暗号化制御ワードとを含む保護コンテンツを受け取るステップと、権利ブロックチェーンとユーザの認証情報とを受け取るステップと、保護コンテンツのコンテンツ識別子を含む第１のブロックを求めて権利ブロックチェーンを検索するステップと、第１のブロック内の署名及び使用権が有効であると判定された時に、暗号化制御ワードを復号するステップと、復号された制御ワードを用いてスクランブルエッセンスをスクランブル解除するステップと、を含む。
【０００９】
さらに別の実装では、コンテンツアイテムを消費するためのユーザの権利を保存する権利ブロックチェーンの生成方法を開示する。この方法は、ユーザから登録要求及び公開鍵を受け取って、ユーザが公開鍵に対応する秘密鍵を有していることを検証するステップと、公開鍵を用いて、ユーザのユーザ識別子を含むジェネシスブロックを生成するステップと、コンテンツアイテムのコンテンツ識別子と関連する使用権とを有する新たなブロックを生成して追加するステップと、を含む。
【００１０】
本開示の態様を一例として示す本明細書からは、他の特徴及び利点も明らかになるはずである。
【００１１】
同じ部分を同じ参照数字によって示す添付図面を検討することにより、本開示の詳細をその構造及び動作の両方に関して部分的に収集することができる。
【図面の簡単な説明】
【００１２】
【図１】ｎ個のブロックとジェネシスブロックとを含むブロックチェーンのブロック図である。
【図２】ブロックチェーンを用いた新たなＤＲＭシステムの１つの実装におけるコンポーネント及び相互作用のブロック図である。
【図３】権利ブロックチェーン（ＲＢＣ）の１つの実装のブロック図である。
【図４】保護コンテンツの１つの実装のブロック図である。
【図５】本開示の１つの実装による、ブロックチェーンを用いたデジタル権利管理動作を示すフロー図である。
【図６】本開示の１つの実装による、ＲＢＣの生成プロセスを示すフロー図である。
【図７】本開示の１つの実装による、所与のコンテンツを取得してＲＢＣに使用権を追加するプロセスを示すフロー図である。
【図８】本開示の１つの実装による、コンテンツプロバイダにおけるコンテンツパッケージングプロセスを示すフロー図である。
【図９】本開示の１つの実装によるコンテンツ消費プロセスを示すフロー図である。
【発明を実施するための形態】
【００１３】
上述したように、通常、現在の多くのデジタル権利管理ソリューションは、権利ロッカー又は共通ストレージを必要とし、１つの特異な障害点に依拠する。例えば、権利ロッカーのプロバイダ又はシステムが廃業したり、或いは別様に失敗した場合、ユーザは、取得した全てのコンテンツを失ってしまう。従来の解決策は、１つのコンテンツの使用権を１人のユーザ及び１つの特定のプラットフォーム専用のライセンスに保存するものである。
【００１４】
本開示のいくつかの実装は、権利ロッカーを排除してブロックチェーンを用いた永続的相互運用性の見通しをもたらす別の解決策を提供する。これらの説明を読んだ後には、様々な実装及び用途における本開示の実施方法が明らかになるであろう。一方、本明細書では本開示の様々な実装について説明するが、これらの実装は、限定ではなく一例として提示するものにすぎないと理解されたい。従って、様々な実装についての詳細な説明は、本開示の範囲又は外延を限定するものとして解釈すべきではない。
【００１５】
ブロックチェーンデータ構造は、順序付きブロックリストである。各ブロックは、通常は「ジェネシス（起点）」ブロックと呼ばれるブロックチェーン内の最初のブロックまでその先行ブロック（ｐｒｅｄｅｃｅｓｓｏｒ）を確実に遡って示す。ブロック及びその順序付けは、暗号学的ハッシュを後方リンクすることによって完全性が保護される。
【００１６】
１つの実装では、ソフトウェアアプリケーション及びオペレーティングシステムを実行する複数のコンピュータシステムが相互作用して、データとして保存されたビデオコンテンツなどのコンテンツへのアクセスを管理する。これらのコンピュータシステムは、権利ブロックチェーンを使用してアクセスを管理する。権利ブロックチェーンは、ユーザ及びコンテンツアイテムの情報を保存する一連の順序付きデータブロックを含む。権利ブロックチェーンは、最初にいわゆるジェネシスブロックと呼ばれる、ユーザ情報を保存する１つのブロックを含む。権利ブロックチェーンには、コンテンツアイテムの使用権が取得された時にブロックが追加され、各新たなブロックは、１又は２以上のコンテンツアイテムの使用権を示し、権利ブロックチェーン内の前のブロックへの参照を含む。
【００１７】
１つの例では、ユーザが登録コンピュータシステムにユーザ情報を登録し、登録システムが、権利ブロックチェーンのジェネシスブロックを表すコンピュータシステムデータをユーザに提供する。ユーザがコンテンツプロバイダ又は他の何らかのエンティティからコンテンツアイテムの権利を取得すると、ユーザシステムは、コンテンツプロバイダのコンピュータシステムにユーザの権利ブロックチェーンを提供し、コンテンツプロバイダシステム及び登録システムは、ユーザの権利ブロックチェーンを更新して新たな権利を反映し、新たなコンテンツのための新たなブロックを追加する。コンテンツプロバイダシステムは、更新された権利ブロックチェーンと、コンテンツアイテムを表す対応する暗号化コンテンツデータとを戻し、ユーザシステムは、受け取ったデータを保存する。ユーザがさらなる使用権を取得すると、コンテンツプロバイダシステム及び登録システムは、再びユーザの権利ブロックチェーンを更新して、新たなコンテンツのための新たなブロックを追加する。
【００１８】
ユーザがコンテンツデータにアクセスしたいと望むと、ユーザシステムは、ＤＲＭコンピュータシステムにコンテンツデータと権利ブロックチェーンとを提供する。ＤＲＭシステムは、権利ブロックチェーンを検証して、このアクセスが権利ブロックチェーンの対応するブロック内で認められた使用権の範囲内にあることを確認する。検証及び確認が行われると、ＤＲＭシステムは、暗号化コンテンツデータを復号し又は復号を容易にし、ユーザシステムは、復号されたコンテンツにアクセスすることができる。
【００１９】
図１は、ｎ個のブロック１１０、１２０、１３０とジェネシスブロック１４０とを含むブロックチェーン１００のブロック図である。１つの実装では、ブロックが、登録データ及び補助データを保存する情報セクション（例えば、１１２）、前のブロックの暗号学的ハッシュ（例えば、１１４）（ジェネシスブロックは前のブロックを有していない）、及び現在のブロックの暗号学的ハッシュ（例えば、１１６）、という少なくとも３つの要素を有する。
【００２０】
図２は、ブロックチェーンを用いた新たなＤＲＭシステム２００の１つの実装におけるコンポーネント及び相互作用のブロック図である。従来のＤＲＭでは、ユーザ／装置に対して暗号化されたライセンスが、１つのコンテンツ又は一連のコンテンツに関連するデスクランブル鍵と使用権とを含む。新たなシステム２００では、このライセンスが、ユーザが取得した全ての使用権を保持するＲＢＣ２１０のブロックに置き換わる。このブロックチェーン２１０は、機密性が保護されず、完全性のみが保護される。図３は、ＲＢＣ２１０の１つの実装のブロック図である。
【００２１】
図２及び図３に示す実装では、ＤＲＭシステム２００が、ＲＢＣ２１０と、コンテンツプロバイダ２２０と、ユーザ認証情報２３０と、登録認定機関２４０と、保護コンテンツ２５０と、ＤＲＭエージェントと２６０を含む。他の実装では、図２に示す全てのエンティティ又はオブジェクト／データが必要なわけではなく、又は使用されるわけではない。
【００２２】
ユーザ認証情報２３０はユーザ特有のものであり、ＲＢＣ２１０のユーザＩＤ（例えば、図３のユーザＩＤ３２２）に暗号によってリンクされる。登録認定機関２４０は、ユーザのＲＢＣ２１０に新たなブロックを追加する。コンテンツプロバイダ２２０は、保護コンテンツ２５０と関連する使用権とをユーザに配信する。登録認定機関２４０は、この使用権をユーザのＲＢＣ２１０に追加する。保護コンテンツ２５０は、スクランブルコンテンツ（例えば、スクランブル化された映画）を含む。ＤＲＭエージェント２６０は、デジタル権利管理機能を担当する。１つの実装では、ＤＲＭエージェント２６０が、コンテンツを消費／視聴するために使用されるユーザ装置内で動作する。ＤＲＭエージェント２６０は、保護コンテンツ２５０及びＲＢＣ２１０を受け取る。ユーザがコンテンツへのアクセス権を有している場合、ＤＲＭエージェント２６０は、保護コンテンツ２５０をスクランブル解除する。
【００２３】
１つの実装では、コンピュータシステムの各ユニット（例えば、コンテンツプロバイダ２２０、登録認定機関２４０及びＤＲＭエージェント２６０）が独立している。別の実装では、コンピュータシステム同士を同じ場所に配置し又は組み合わせる（例えば、コンテンツプロバイダ２２０と登録認定機関２４０とが同じサーバシステム上で動作する）ことも、或いは図示していないさらなるシステム（例えば、携帯電話機及び／又はタブレットなどの複数のユーザシステム及び複数のコンテンツ配信ネットワークシステム）が参加することもできる。
【００２４】
図３に示す実装では、ジェネシスブロック３２０の情報ブロック３２１が、少なくともユーザＩＤ３２２を保持する。ＲＢＣ２１０は公開されることもあるので、ユーザＩＤ３２２は匿名とすることができる。ユーザＩＤ３２２は、機密的なものではない。ジェネシスブロック３２０は、その情報ブロック３２１のハッシュ３２４も含む。後続ブロック（例えば、ブロック１（３１０））は、現在のブロックのハッシュ３１８及び先行ブロックのハッシュ３１９も含む。
【００２５】
後続ブロック（ブロック１（３１０）〜ブロックｎ（３３０））の情報ブロック（例えば、ブロック１では３１１）は、少なくともコンテンツ識別子（ＩＤ）（例えば、ブロック１では３１２）と、使用権（例えば、ブロック１では３１４）と、デジタル署名（例えば、ブロック１では３１６）とを含む。
【００２６】
コンテンツＩＤ３１２は、１つのコンテンツ又は作品を明確に識別する。作品は、コンテンツの所与のバージョンとすることも、又はフォーマットにかかわらずコンテンツ自体とすることもできる。コンテンツプロバイダ２２０は、コンテンツＩＤ３１２の制御及び規定を行う。使用権３１４は、この作品についてユーザに与えられた又はユーザが取得した権利を規定する。フォーマットは、ｅＸｔｅｎｓｉｂｌｅ  Ｒｉｇｈｔｓ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸｒＭＬ）又はオープンデジタル権利言語（ＯＤＲＬ）などの標準化された権利言語、スマートコントラクト、或いはいずれかの専用フォーマットとすることができる。デジタル署名３１６は、登録認定機関２４０によって発行される。署名３１６は、情報ブロック３１１を含む。
【００２７】
１つの実装では、ＲＢＣ２１０が、ユーザＩＤ３２２によって識別される個人に特有のものである。別の実装では、所与のエコシステムの全てのユーザの使用権を保持するグローバルＲＢＣが存在する。この場合は、ブロック情報がユーザＩＤ３２２も含み、ジェネシスブロック３２０は異なる（特定のユーザＩＤに専念しない）。
【００２８】
１つの実装例では、ブロックチェーンが、ユーザが登録してジェネシスブロック３２０を形成した時に登録認定機関２４０によって提供される２０４８ビット数のユーザＩＤ３２２、コンテンツのＥｎｔｅｒｔａｉｎｍｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ  Ｒｅｇｉｓｔｒｙ（ＥＩＤＲ）識別子（例えば、ｅｉｄｒ．ｏｒｇを参照）を使用するコンテンツＩＤ（１１０）、認可されたオーディオ言語のリストと認可された字幕のリストとを列挙するデータ構造である使用権（例えば、著作権３１４）、及びｂａｓｅ６４で符号化されたＳＨＡ−５１２である全てのハッシュ（例えば、ハッシュ３１８、３１９、３２４）、といった情報及びフォーマットを使用する。ブロックｎでは、署名（例えば、ブロック１では署名３１６）が、コンテンツＩＤ（例えば、３１２）、使用権（例えば、３１４）及びブロックｎ−１のハッシュ（例えば、３１９）という３つのフィールドのＲＳＡ２０４８（Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ及びＡｄｅｌｍａｎａの公開鍵暗号方式）である。登録認定機関２４０は、そのルート署名秘密鍵を用いて署名を生成する。ジェネシスブロックでは、署名が、ユーザＩＤフィールド（例えば、３２２）のＲＳＡ２０４８である。ブロックのハッシュ（例えば、３１８、３１４）は、情報ブロック３１１と前のブロックのハッシュ（例えば、３１９）とを含む。ジェネシスブロック３２０のハッシュ３２４は、情報ブロック３２１のみを含む。
【００２９】
図４は、保護コンテンツ２５０の１つの実装のブロック図である。保護コンテンツ２５０は、少なくともコンテンツＩＤ４１０と、スクランブルエッセンス（ｓｃｒａｍｂｌｅｄ  ｅｓｓｅｎｃｅ）４２０と、暗号化制御ワード（暗号化ＣＷ）４３０とを含む。コンテンツＩＤ４１０は、作品を識別する。このコンテンツＩＤは、ＲＢＣ２１０によって使用されるものと同じものである。スクランブルエッセンス４２０は、コンテンツプロバイダ２２０によって生成された乱数である制御ワード（ＣＷ）を用いて非暗号文コンテンツエッセンス（すなわち、スクランブル化されていない非暗号文形態のコンテンツ）をスクランブル化した結果である。１つの実装では、スクランブルアルゴリズムが、ＣＢＣモードのＡＥＳ１２８ビットである。すなわち、スクランブルエッセンス＝ＡＥＳ（ＣＷ）（非暗号文エッセンス）である。暗号化ＣＷ４３０は、ＤＲＭエージェント２６０に知られている鍵を用いて（例えば、秘密鍵、又は公開鍵と秘密鍵のペアを用いて）（このエッセンスをスクランブル化するために使用される）ＣＷを暗号化した結果である。
【００３０】
１つの実装では、ＤＲＭエージェント２６０が、ＣＷを暗号化するために使用される一意の１２８ビットＤＲＭ＿ＫＥＹを有し、この暗号化は高度暗号化標準（ＡＥＳ）を使用する。１つの実装では、ＣＷが、乱数発生器によって発生した１２８ビットノンスである。すなわち、暗号化ＣＷ＝ＡＥＳ（ＤＲＭ＿ＫＥＹ）（ＣＷ）である。
【００３１】
１つの実装では、コンテンツプロバイダ２２０が複数のＤＲＭ技術を使用することができる。この場合、サポートされる各ＤＲＭエージェント２６０は、ＤＲＭ−ＩＤによって識別される。保護コンテンツ２５０のデータ構造は、ＤＲＭ−ＩＤと対応する暗号化ＣＷ４３０とのペアのリストを含む。各暗号化ＣＷ４３０は、対応するＤＲＭエージェント２６０の秘密ＤＲＭ＿ＫＥＹによって暗号化されたＣＷである。
【００３２】
図５は、本開示の１つの実装による、ブロックチェーンを用いたデジタル権利管理（ＤＲＭ）動作を示すフロー図５００である。１つの実装では、このＤＲＭ動作が、図２のＤＲＭエージェント２６０内で実行される。
【００３３】
図５に示す実装では、ブロック５１０において、保護コンテンツ２５０を受け取る。ブロック５２０において、ユーザの認証情報２３０と、ユーザのＲＢＣ２１０へのポインタとを要求して受け取る。ブロック５３０において、受け取ったＲＢＣ２１０の妥当性をチェックする。ＲＢＣ２１０の妥当性は、全てのブロックのハッシュ（例えば、図３のブロック１のハッシュ３１８、３１９）とジェネシスブロックのハッシュ（例えば、図３のジェネシスブロックのハッシュ３２４）とが一致するかどうかを判定することによってチェックされる。各非ジェネシスブロックでは、この妥当性確認によって、そのブロックの計算されたハッシュがハッシュ３１８に等しく、前のブロックの計算されたハッシュがハッシュ３１９に等しいことが検証される。ジェネシスブロックでは、この妥当性確認によって、そのブロックの計算されたハッシュがハッシュ３２４に等しいことが検証される。
【００３４】
次に、受け取ったＲＢＣ２１０が実際にユーザに属していることを検証する判定を行う。１つの実装では、ブロック５４０において、ＲＢＣ２１０内のユーザＩＤ３２２が受け取ったユーザ認証情報２３０に対応するかどうかを判定するチェックを行う。対応する場合、受け取ったＲＢＣ内に列挙されている全ての使用権（例えば、図３のＲＢＣ２１０のブロック１内の権利３１４）がユーザに関連付けられていると判定することができる。
【００３５】
受け取ったＲＢＣがユーザに関連付けられていることが判定されると、ブロック５５０において、保護コンテンツのコンテンツＩＤを含むＲＢＣ内のブロックを検索する。次に、ブロック５６０において、対応する検索されたブロック内で情報ブロックの署名及び使用権をチェックする。ブロック５７０において、使用権が有効であると判定された場合、ブロック５８０において、秘密鍵（すなわち、ＤＲＭ＿ＫＥＹ）を用いて暗号化ＣＷ４３０を復号して非暗号文ＣＷを取り出す。ブロック５９０において、この非暗号文ＣＷを用いてスクランブルエッセンスをスクランブル解除する。
【００３６】
図５に示す実装では、ブロックチェーンＤＲＭ動作が、集中ライセンスサーバ又は集中権利ロッカーを使用しない。権利ロッカーの代わりに、ＲＢＣ２１０の関連付けと登録認定機関２４０とを使用する。同様に、ライセンスサーバの役割は、必要な使用権を定めるＲＢＣ２１０と、暗号化ＣＷ４３０を保持する保護コンテンツ２５０と、使用権を強要するＤＲＭエージェント２６０との間で共有される。
【００３７】
多くのコンテンツプロバイダは、同じＲＢＣを共有することができる。１つの実装では、ユーザが１つのＲＢＣを有し、各コンテンツプロバイダが、そのユーザの同じＲＢＣを使用する。別の実装では、ユーザが、複数のＲＢＣをコンテンツプロバイダ毎に１つずつ有することができ、或いは複数のプロバイダが同じＲＢＣを共有又は使用することができ、或いは１つのコンテンツプロバイダが複数のＲＢＣを使用することができる。
【００３８】
コンテンツプロバイダ２２０は、そのＤＲＭ技術を追加又は変更する場合、新たなＤＲＭエージェント２６０のための新たな暗号化ＣＷ４３０を用いて新たなバージョンの保護コンテンツ２５０を再発行しさえすればよい。
【００３９】
１つの実装は、Ｅセルスルー（ＥＳＴ）に対処するように設計される。ユーザは、特定の言語（又は言語の組）の字幕を付けることができる所与の言語（又は言語の組）のコンテンツを視聴するためのライセンス権を取得する。このライセンスは恒久的なものであり（又は少なくとも合理的な年数にわたり）、視聴するコンテンツ例の品質とは無関係である。このような１つの実装では、コンテンツプロバイダ２２０が１つのＤＲＭしか使用しない。
【００４０】
以下、ユーザＡがＲＢＣを用いてシステムと相互作用するＤＲＭ動作のいくつかの例を提示する。
【００４１】
ユーザＡは、ＲＢＣを形成するために、ＲＳＡ２０４８の鍵ペアを生成して登録認定機関２４０に連絡することによってユーザ登録を実行する。その後、登録認定機関２４０は、ユーザＡの公開鍵を要求し、この公開鍵が既に登録済みであるかどうかを検証し、既に登録済みである場合には、ユーザＡに異なる鍵ペアを生成するように要求し、チャレンジレスポンスプロトコルを介してユーザＡが対応する秘密鍵を有しているかどうかを検証し、ユーザＡの公開鍵を用いてユーザＩＤ３２２を生成し、ユーザＡのＲＢＣ２１０のためのユーザＡのジェネシスブロック３２０を形成し、形成されたジェネシスブロック３２０をユーザＡに提供する、という動作を実行する。
【００４２】
図６は、本開示の１つの実装による、ＲＢＣの形成プロセスを示すフロー図６００である。図６に示す実装では、ブロック６１０において、登録認定機関においてユーザから登録要求を受け取る。これに応答して、登録認定機関は、ブロック６２０においてユーザに公開鍵を要求し、ブロック６３０において、この公開鍵が既に登録済みであるかどうかを検証する。既に登録済みである場合、登録認定機関は、ブロック６４０において、ユーザに異なる鍵ペアを生成するように要求する。その後、登録認定機関は、ブロック６５０において、チャレンジレスポンスプロトコルを介してユーザが対応する秘密鍵を有しているかどうかを検証し、ブロック６６０において、ユーザの公開鍵を用いてユーザＩＤを生成し、ブロック６７０において、ＲＢＣのジェネシスブロックを含む権利ブロックチェーンを形成してユーザに提供する。
【００４３】
所与のコンテンツを取得して使用権を追加するには、ユーザＡがコンテンツプロバイダ２２０にＲＢＣを提供し、コンテンツプロバイダ２２０が、ユーザＡがコンテンツを取得した旨を登録認定機関２４０に通知し、ユーザ（又はコンテンツプロバイダ２２０）が、ＲＢＣ２１０と、購入したコンテンツのコンテンツＩＤ（例えば、ブロック１のＩＤ３１２）と、認可された言語及び字幕言語のリストなどの関連する使用権（例えば、ブロック１のＩＤ３１４）とを提供し、登録認定機関２４０が、提供されたＲＢＣの妥当性／完全性（すなわち、ＲＢＣに障害が無く改竄もされていないこと）をチェックし、ＲＢＣ２１０が有効である場合、登録認定機関２４０が、提供されたデータと、新たなブロック及び先行ブロック内の情報のハッシュ（例えば、図３のブロック１のハッシュ３１８、３１９）とを含む新たなブロックを追加し、登録認定機関２４０がＲＢＣ２１０をコンテンツプロバイダ２２０に戻し、コンテンツプロバイダ２２０がＲＢＣ２１０をユーザＡに戻す、という動作を実行する。
【００４４】
図７は、本開示の１つの実装による、所与のコンテンツを取得してＲＢＣに使用権を追加するプロセスを示すフロー図７００である。図７に示す実装では、ブロック７１０において、ユーザがコンテンツプロバイダから所与のコンテンツを取得すると、ブロック７２０において、コンテンツプロバイダが、ユーザがコンテンツを取得した旨を登録認定機関に通知する。ブロック７３０において、コンテンツプロバイダが、購入コンテンツのコンテンツＩＤと、認可された言語及び字幕言語のリストなどの関連する使用権とを登録認定機関に提供する。次に、ブロック７４０において、登録認定機関が、提供されたＲＢＣの完全性をチェックし、ＲＢＣが有効であって障害が無く改竄もされていない場合、ブロック７５０において、登録認定機関が、提供されたデータと、新たなブロック及び先行ブロック内の情報のハッシュとを含む新たなブロックを追加する。ブロック７６０において、登録認定機関がユーザにＲＢＣを戻す。
【００４５】
１つの実装では、コンテンツをパッケージ化するために、コンテンツプロバイダ２２０が、このバージョンのコンテンツをＥＩＤＲに登録してコンテンツＩＤ（例えば、ブロック１の３１２）を受け取り、ＣＷになるランダムな１２８ビットの数を生成し、対応するＤＲＭ＿ＫＥＹを用いてＣＷを暗号化することによって、サポートされている各ＤＲＭの対応する暗号化ＣＷ４３０を計算し、このＣＷを用いて非暗号文エッセンスをスクランブル化してスクランブルエッセンス４２０を生成し、これらの情報を全て保護コンテンツ２５０にパッケージ化する、という動作を実行する。１つの実装では、カウンタ（ＣＴＲ）モードのＡＥＳがスクランブルに使用される。保護コンテンツ２５０は、自動保護されているので自由に配信することができる。
【００４６】
図８は、本開示の１つの実装による、コンテンツプロバイダにおけるコンテンツパッケージングプロセスを示すフロー図８００である。図８に示す実装では、ブロック８１０において、コンテンツプロバイダが、現在のバージョンのコンテンツをＥＩＤＲに登録してコンテンツＩＤを受け取る。次に、コンテンツプロバイダは、ブロック８２０において、制御ワード（ＣＷ）になる乱数を生成し、ブロック８３０において、対応する秘密鍵（ＤＲＭ＿ＫＥＹ）を用いてＣＷを暗号化することによって、サポートされている各ＤＲＭの対応する暗号化ＣＷを計算する。また、コンテンツプロバイダは、ブロック８４０において、ＣＷを用いて非暗号文エッセンスをスクランブル化してスクランブルエッセンスを生成し、これらの情報を全て保護コンテンツにパッケージ化する。
【００４７】
ＤＲＭエージェント２６０は、コンテンツを消費する（例えば、保護コンテンツを視聴する）ために、ユーザＡからＲＢＣ２１０及び保護コンテンツ２５０を受け取り、ＲＢＣ２１０の妥当性を検証し、ユーザＩＤ３２２を抽出し、チャレンジレスポンスプロトコルを用いてユーザＡがユーザＩＤ３２２に対応する秘密鍵を有しているかどうかを検証し、ユーザＡのＲＢＣ２１０内に保護コンテンツ２５０のコンテンツＩＤ（例えば、ブロック１の３１２）が存在するかどうかをチェックし、ユーザＡのＲＢＣ２１０内にコンテンツＩＤが存在する場合、ユーザＡによって要求された言語及び字幕言語が使用権（例えば、ブロック１の３１４）に列挙されているかどうかを検証し、使用権が検証された場合、秘密鍵ＤＲＭ＿ＫＥＹを用いて暗号化ＣＷ４３０を復号して非暗号文ＣＷを取り出し、このＣＷを用いてスクランブルエッセンス４２０をスクランブル解除して消費のためにユーザＡに送信する、という動作を実行する。
【００４８】
別の実装では、同じＲＢＣ２１０が複数の独立したコンテンツプロバイダ２２０と協働する。各コンテンツプロバイダ２２０は、独自のＤＲＭエージェント２６０を使用することも、或いはＤＲＭエージェント２６０を他のプロバイダと共有することもできる。
【００４９】
図９は、本開示の１つの実装によるコンテンツ消費プロセスを示すフロー図９００である。図９に示す実装では、ブロック９１０において、ＤＲＭエージェントがＲＢＣ及び保護コンテンツを受け取り、ブロック９２０においてＲＢＣの妥当性を検証する。次に、ブロック９３０において、ＲＢＣからユーザＩＤを抽出し、ブロック９４０において、ＤＲＭエージェントが、チャレンジレスポンスプロトコルを用いてユーザがユーザＩＤに対応する秘密鍵を有しているかどうかを検証する。ブロック９５０において、保護コンテンツのコンテンツＩＤをチェックして、このコンテンツがＲＢＣ内に存在するかどうかを判定する。次に、コンテンツＩＤがＲＢＣ内に存在する場合、ブロック９６０において、ＤＲＭエージェントが、ユーザによって要求された言語及び字幕言語が使用権に列挙されているかどうかを検証する。使用権が検証された場合、ブロック９７０において、ＤＲＭエージェントが、秘密鍵を用いて暗号化ＣＷを復号して非暗号文ＣＷを取り出す。ブロック９８０において、このＣＷを用いてスクランブルエッセンスをスクランブル解除して消費のためにユーザに送信する。
【００５０】
さらなる変形及び実装も可能である。例えば、コンテンツデータは、映画、テレビ、ビデオ、音楽、オーディオ、ゲーム、科学データ、医療データなどの様々なタイプのコンテンツ又はその他のデータのものとすることもできる。様々なＤＲＭ及び暗号化アルゴリズムを使用することができる。ユーザの識別及び権利の関連性は、１人のユーザが異なる装置上に同じ又は異なる権利を有することや、ユーザが権利を共有すること（例えば、家族アカウント又は一次／下位アカウント）や、一時的な権利の共有（例えば、貸し出し、デモモデル）などの異なる方法で取り扱うことができる。従って、本明細書で説明した具体例は、新技術の範囲における唯一の実装ではない。
【００５１】
１つの実装は、ブロックチェーン及びコンテンツを表すデータの生成、記憶、修正及び送信、並びにコンテンツを表すデータの暗号化、復号及びこのようなデータへのアクセスを制御するための情報管理などを行うためのコンピュータ命令を記憶して実行する１又は２以上のプログラマブルプロセッサ及び対応するコンピュータシステムコンポーネントを含む。
【００５２】
開示した実装についての上記説明は、当業者が本開示を実施又は利用できるように行ったものである。当業者には、これらの実装の様々な修正が容易に明らかになると思われ、また本明細書で説明した一般的原理は、本開示の趣旨又は範囲から逸脱することなく他の実装にも適用することができる。従って、これらの技術は、上述した特定の例に限定されるものではない。従って、本明細書で提示した説明及び図面は、本開示の現在のところ考えられる実装を表すものであり、従って本開示が広く意図する主題を表すものであると理解されたい。さらに、本開示の範囲は、当業者にとって明らかになり得る他の実装を完全に含み、従って添付の特許請求の範囲以外のものによって限定されるものではないと理解されたい。
【符号の説明】
【００５３】
２１０  ブロックチェーン
３１０  ブロック１
３１１  情報ブロック
３１２  コンテンツＩＤ
３１４  使用権
３１６  署名
３１８  ハッシュ１
３１９  ハッシュ０
３２０  ジェネシスブロック
３２１  情報ブロック
３２２  ユーザＩＤ
３２４  ハッシュ０
３３０  ブロックｎ
【図１】
2019532603.tif 000003
【図２】
2019532603.tif 000004
【図３】
2019532603.tif 000005
【図４】
2019532603.tif 000006
【図５】
2019532603.tif 000007
【図６】
2019532603.tif 000008
【図７】
2019532603.tif 000009
【図８】
2019532603.tif 000010
【図９】
2019532603.tif 000011
【国際調査報告】
2019532603.tif 000012
2019532603.tif 000013