(57)【要約】【課題】コンテンツを受け取る資格のあるデバイスだけが、コンテンツを受け取り、使用することができるようにする。【解決手段】コンテンツアクセス管理は、コンテンツ要求をデバイス１０２から受信可能とする。そのコンテンツ要求に応答して、コンテンツのソースの識別子と、デバイス１０２がそのコンテンツを解読することを可能にする１つまたは複数の鍵がともに、照会ソース１０４からデバイス１０２に送信される。次に、デバイス１０２は、所望に応じて、コンテンツソース１０６からコンテンツ１１６を取得し、そのコンテンツ１１６を解読して使用することができる。【選択図】　　　　図１
2004056793.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツに対するアクセスを管理する方法であって、
デバイスからコンテンツ照会要求を受信するステップと、
前記コンテンツ照会要求に応答して、前記コンテンツのソースの識別子と、前記デバイスが前記コンテンツを解読することを可能にする１つまたは複数の鍵をともに前記デバイスに送信するステップと
を備えたことを特徴とする方法。
【請求項２】
前記識別子と前記１つまたは複数の鍵を送信するステップに先立って、前記コンテンツ照会要求の要求側が前記コンテンツにアクセスすることが許されていることを検証するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記検証するステップは、前記デバイス上で実行されているアプリケーションが前記コンテンツにアクセスすることが許されていることを検証するステップをさらに備えたことを特徴とする請求項２に記載の方法。
【請求項４】
前記要求側は、前記デバイスを含み、かつ前記検証するステップは、前記デバイスが前記コンテンツにアクセスすることが許されていることを検証するステップをさらに含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記要求側は、前記デバイスのユーザを含み、かつ前記検証するステップは、前記ユーザが前記コンテンツにアクセスすることが許されていることを検証するステップをさらに含むことを特徴とする請求項２に記載の方法。
【請求項６】
前記検証するステップは、前記要求側が、前記コンテンツにアクセスすることが許されている国に関連していることを検証するステップをさらに含むことを特徴とする請求項２に記載の方法。
【請求項７】
前記検証するステップは、前記要求側が、前記コンテンツにアクセスすることが許されている地理的区域に関連していることを検証するステップをさらに含むことを特徴とする請求項２に記載の方法。
【請求項８】
前記コンテンツ照会要求の要求側を検証するステップと、
前記要求側が検証された場合にだけ、前記識別子、および前記１つまたは複数の鍵を送信するステップと
をさらに備えた方法であって、
前記検証するステップは、
前記デバイスが前記コンテンツにアクセスすることが許されていることを検証するステップと、
前記デバイス上で実行されるアプリケーションが前記コンテンツにアクセスすることが許されていることを検証するステップと、
前記デバイスが、前記コンテンツにアクセスすることが許されている地理的区域に関連していることを検証するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記コンテンツ照会要求の要求側を検証するステップと、
前記要求側が検証された場合にだけ、前記識別子、および前記１つまたは複数の鍵を送信するステップと
をさらに備えた方法であって、
前記検証するステップは、
前記デバイスのユーザが前記コンテンツにアクセスすることが許されていることを検証するステップと、
前記デバイス上で実行されるアプリケーションが前記コンテンツにアクセスすることが許されていることを検証するステップと、
前記ユーザが、前記コンテンツにアクセスすることが許されている国に関連していることを検証するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記識別子と前記１つまたは複数の鍵を送信するステップに先立って、前記コンテンツの複数のソースを特定し、該複数のソースの１つを選択するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１１】
前記複数のソースのそれぞれは、関連するランキングを有し、かつ前記選択するステップは、最高のランキングを有する前記複数のソースの１つを選択するステップを含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記選択するステップは、少なくともある程度、前記複数のソースのそれぞれに係る現在の負荷に基づくことを特徴とする請求項１０に記載の方法。
【請求項１３】
前記選択するステップは、少なくともある程度、前記デバイスの地理的区域に基づくことを特徴とする請求項１０に記載の方法。
【請求項１４】
前記選択するステップは、少なくともある程度、前記デバイスの加入レベルに基づくことを特徴とする請求項１０に記載の方法。
【請求項１５】
前記選択するステップは、少なくともある程度、前記デバイスのユーザの加入レベルに基づくことを特徴とする請求項１０に記載の方法。
【請求項１６】
前記選択するステップは、少なくともある程度、前記複数のソースのそれぞれの現在の対応可能性に基づくことを特徴とする請求項１０に記載の方法。
【請求項１７】
前記識別子と前記１つまたは複数の鍵を送信するステップに先立って、前記コンテンツの複数のソースを特定するステップをさらに含む方法であって、
前記送信するステップは、前記複数のソースの識別子を前記デバイスに送信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記コンテンツ照会要求の要求側の認証を行い、前記要求側が認証された場合にだけ、前記識別子と前記１つまたは複数の鍵を送信するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１９】
前記要求側は、前記デバイスを含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記要求側は、前記デバイスのユーザを含むことを特徴とする請求項１８に記載の方法。
【請求項２１】
前記要求側は、前記デバイスの複数のユーザを含むことを特徴とする請求項１８に記載の方法。
【請求項２２】
前記１つまたは複数の鍵は、対称鍵、および公開鍵／秘密鍵ペアの公開鍵を含むことを特徴とする請求項１に記載の方法。
【請求項２３】
前記対称鍵は、前記デバイスが前記コンテンツを解読することを可能にし、かつ前記公開鍵は、前記デバイスが前記コンテンツの認証を行うことを可能にすることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記ソースは、リモートのサーバデバイスを含むことを特徴とする請求項１に記載の方法。
【請求項２５】
前記ソースは、ローカルの記憶デバイスを含むことを特徴とする請求項１に記載の方法。
【請求項２６】
前記コンテンツは、ゲーム全体を含むことを特徴とする請求項１に記載の方法。
【請求項２７】
前記コンテンツは、ゲームのセグメントを含むことを特徴とする請求項１に記載の方法。
【請求項２８】
前記コンテンツは、ゲームタイトルに関する新しいフィーチャを含むことを特徴とする請求項１に記載の方法。
【請求項２９】
前記コンテンツは、ゲームタイトルの以前に出荷されたモジュールにおける問題を修正する１つまたは複数の新しいモジュールを含むことを特徴とする請求項１に記載の方法。
【請求項３０】
前記デバイスは、ゲームコンソールを含むことを特徴とする請求項１に記載の方法。
【請求項３１】
コンテンツに対するアクセスを管理する方法であって、
複数のコンテンツパッケージが記憶されている場所のレコードを保持するステップと、
前記複数のコンテンツパッケージの少なくとも１つを解読するのにそれぞれを使用することができる複数の鍵のレコードを保持するステップと、
前記複数のコンテンツパッケージの特定の１つに関して、複数の要求側のデバイスのどれが、前記コンテンツパッケージが記憶されている場所の指示、ならびに前記コンテンツパッケージを解読するのに使用することができる前記複数の鍵の１つを受け取ることができるかを制限するステップと
を備えたことを特徴とする方法。
【請求項３２】
前記制限するステップは、少なくともある程度、前記デバイス上で実行されるゲームタイトルに基づき、前記複数の要求側のデバイスのどれが、前記指示を受け取ることができるかを制限するステップを含むことを特徴とする請求項３１に記載の方法。
【請求項３３】
前記制限するステップは、少なくともある程度、前記デバイスの識別子に基づき、前記複数の要求側のデバイスのどれが、前記指示を受け取ることができるかを制限するステップを含むことを特徴とする請求項３１に記載の方法。
【請求項３４】
前記制限するステップは、少なくともある程度、前記デバイスのユーザに基づき、前記複数の要求側のデバイスのどれが、前記指示を受け取ることができるかを制限するステップを含むことを特徴とする請求項３１に記載の方法。
【請求項３５】
前記制限するステップは、少なくともある程度、前記デバイスに関連する地理的区域に基づき、前記複数の要求側のデバイスのどれが、前記指示を受け取ることができるかを制限するステップを含むことを特徴とする請求項３１に記載の方法。
【請求項３６】
前記複数のコンテンツパッケージのそれぞれが、複数のソースに記憶されることが可能な方法であって、
特定のデバイスに関して、前記複数のソースのどれの指示を前記デバイスが受け取るべきかを選択するステップをさらに備えたことを特徴とする請求項３１に記載の方法。
【請求項３７】
１つまたは複数のプロセッサによって実行されたとき、該１つまたは複数のプロセッサが、
コンテンツが記憶されている複数の場所のレコードを保持するステップと、
前記コンテンツを解読するのに使用することができる鍵のレコードを保持するステップと、
デバイスから前記コンテンツを照会する要求を受信するステップと、
前記コンテンツを解読するのに使用することができる前記鍵と、前記コンテンツが記憶されている前記複数の場所の１つの識別子とをともに前記デバイスに送信するステップと
を行うようにさせる複数の命令を記憶したことを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項３８】
前記命令は、前記デバイス上で実行されるアプリケーションが前記コンテンツにアクセスすることが許されている場合にだけ、前記１つまたは複数のプロセッサが、前記鍵と前記識別子とをともに前記デバイスに送信するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項３９】
前記命令は、前記デバイスが前記コンテンツにアクセスすることが許されている場合にだけ、前記１つまたは複数のプロセッサが、前記鍵と前記識別子とをともに前記デバイスに送信するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４０】
前記命令は、前記デバイスのユーザが前記コンテンツにアクセスすることが許されている場合にだけ、前記１つまたは複数のプロセッサが、前記鍵と前記識別子とをともに前記デバイスに送信するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４１】
前記命令は、前記要求側が、前記コンテンツにアクセスすることが許されている地理的区域に関連している場合にだけ、前記１つまたは複数のプロセッサが、前記鍵と前記識別子とをともに前記デバイスに送信するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４２】
前記命令は、前記１つまたは複数のプロセッサが、少なくともある程度、前記複数の場所のそれぞれに関連するランキングに基づいて前記複数の場所の１つを特定するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４３】
前記命令は、前記１つまたは複数のプロセッサが、少なくともある程度、前記複数の場所のそれぞれに係る現在の負荷に基づいて前記複数の場所の１つを特定するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４４】
前記命令は、前記１つまたは複数のプロセッサが、少なくともある程度、前記デバイスの地理的場所に基づいて前記複数の場所の１つを特定するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４５】
前記命令は、前記１つまたは複数のプロセッサが、少なくともある程度、前記デバイスの加入レベルに基づいて前記複数の場所の１つを特定するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４６】
前記命令は、前記１つまたは複数のプロセッサが、少なくともある程度、前記デバイスのユーザの加入レベルに基づいて前記複数の場所の１つを特定するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４７】
前記命令は、前記１つまたは複数のプロセッサが、少なくともある程度、前記複数のソースのそれぞれの現在の対応可能性に基づいて前記複数の場所の１つを特定するステップをさらに行うようにさせることを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４８】
デバイスの１つまたは複数のプロセッサによって実行されたとき、該１つまたは複数のプロセッサが、
１つのコンテンツのソースを照会する要求をリモートデバイスに送信するステップと、
前記１つのコンテンツを解読するのに使用することができる鍵と、前記１つのコンテンツのソースの識別子とをともに前記リモートデバイスから受信するステップと、
前記ソースから前記１つのコンテンツを取得するステップと、
前記鍵を使用して前記１つのコンテンツを解読するステップと、
前記１つのコンテンツを前記デバイス上にローカルで保存するステップと
を行うようにさせる複数の命令を記憶したことを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４９】
前記命令は、前記１つまたは複数のプロセッサが、前記ソースに関連する公開鍵を使用して前記１つのコンテンツに関連するダイジェストを解読し、前記１つのコンテンツに関するダイジェストを生成し、当該生成されたダイジェストを解読されたダイジェストと比較し、生成されたダイジェストと解読されたダイジェストが同一である場合、前記１つのコンテンツは前記ソースからのものであり、かつ変更されていないと検証することによって、前記ソースから取得された前記１つのコンテンツを検証するステップをさらに行わせることを特徴とする請求項４８に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５０】
前記１つまたは複数のプロセッサが前記コンテンツを保存するステップを行うようにさせる前記命令は、前記１つまたは複数のプロセッサが、前記デバイスのローカルなハードドライブに前記コンテンツを保存するようにさせる命令を含むことを特徴とする請求項４８に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５１】
前記ソースは、前記リモートデバイスからの前記ソースの前記識別子の受信前に、前記デバイスに知られていないことを特徴とする請求項４８に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５２】
前記命令は、前記１つまたは複数のプロセッサが、複数のソースの識別子を受信し、前記１つのコンテンツを取得する源の前記複数のソースの１つを選択するステップをさらに行うようにさせることを特徴とする請求項４８に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５３】
前記複数のソースのそれぞれは、関連するランキングを有し、かつ前記１つまたは複数のプロセッサが前記複数のソースの１つを選択するステップを行うようにさせる前記命令は、前記１つまたは複数のプロセッサが、前記１つまたは複数のソースの最高のランキングを有する１つを選択するようにさせる命令を含むことを特徴とする請求項５２に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５４】
前記デバイスは、ゲームコンソールを含むことを特徴とする請求項４８に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５５】
コンピューティングデバイスにおいて実施される方法であって、
前記コンピューティングデバイスが、別のデバイスによってゲームコンソールに対して特定されており、コンテンツの要求を前記ゲームコンソールから受信するステップと、
要求された前記コンテンツが、前記別のデバイスによって前記ゲームコンソールに通信される鍵を使用して暗号化されており、要求された前記コンテンツを前記ゲームコンソールに送信するステップと
を備えたことを特徴とする方法。
【請求項５６】
前記コンピューティングデバイスに関連する公開鍵／秘密鍵ペアの秘密鍵を使用して暗号化された前記コンテンツのダイジェストを前記ゲームコンソールに送信するステップをさらに備えたことを特徴とする請求項５５に記載の方法。
【請求項５７】
デバイスから１つのコンテンツの要求を受信するように構成された選択モジュールと、
前記デバイスが前記１つのコンテンツにアクセスする許可を有するかどうかを判定するように構成された検証モジュールと
を備えたシステムであって、
前記選択モジュールは、前記検証モジュールが、前記デバイスが前記１つのコンテンツにアクセスする許可を有すると判定した場合、前記コンテンツのソースと、前記デバイスが前記１つのコンテンツを解読することを可能にする１つまたは複数の鍵とをともに前記デバイスに送るようにさらに構成されていることを特徴とするシステム。
【請求項５８】
前記要求は、前記１つのコンテンツを獲得することができる源のソースを照会する要求を含むことを特徴とする請求項５７に記載のシステム。
【請求項５９】
前記検証モジュールは、前記要求の中の情報に少なくともある程度基づき、前記デバイスが前記１つのコンテンツにアクセスする許可を有するかどうかを判定することを特徴とする請求項５７に記載のシステム。
【請求項６０】
前記検証モジュールは、前記要求が受信された送信元の前記デバイスの識別子に少なくともある程度基づき、前記デバイスが前記１つのコンテンツにアクセスする許可を有するかどうかを判定することを特徴とする請求項５７に記載のシステム。
【請求項６１】
前記検証モジュールは、前記要求が受信された送信元の前記デバイスの１名または複数名のユーザの識別子に少なくともある程度基づき、前記デバイスが前記１つのコンテンツにアクセスする許可を有するかどうかを判定することを特徴とする請求項５７に記載のシステム。
【請求項６２】
デバイスからコンテンツ照会要求を受信するための手段と、
前記デバイスが前記コンテンツにアクセスする許可を有するかどうかを判定するための手段と
を備えたシステムであって、
前記要求を受信するための手段は、判定するための手段が前記デバイスが前記コンテンツにアクセスする許可を有すると判定した場合、前記コンテンツのソースと、前記デバイスが前記コンテンツを解読することを可能にする１つまたは複数の鍵とをともに前記デバイスに送るための手段をさらに含む
ことを特徴とするシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンテンツに対するアクセスを管理する方法及びシステム関し、より詳細には、アプリケーションコンテンツに係るコンテンツに対するアクセスを管理する方法、記録媒体、コンピューティングデバイスにおいて実施される方法、及びシステムに関する。
【０００２】
【従来の技術】
専用ゲームコンソールが、ますます普及している。ゲームコンソールの記憶容量が大きくなり、コンソール上に大量のデータを記憶することが可能になるものと予期されている。例えば、最近、発売されたＸｂｏｘ（商標）ビデオゲームシステムは、ローカルハードドライブ上に大量のデータを記憶することを可能にしている。そのような増加した記憶容量により、ローカルのプレーヤ間（例えば、同一のゲームシステムを使用する１〜４名のプレーヤ）で、またはリモートのプレーヤ間（例えば、インターネットベースのオンラインゲームなどのネットワークを介する）でゲームを行っている際、ビデオゲームコンソールに追加のコンテンツをダウンロードすることが可能になる。
【０００３】
しかし、ビデオゲームコンソールおよびその他のデバイスにコンテンツをダウンロードすることにおいて直面する１つの問題は、コンテンツを受け取る資格のあるコンソール（またはデバイス）だけ（例えば、適切な料金を支払ったものだけ）が、コンテンツを受け取り、使用することができるようにするのを確実にするよう注意が払われなければならないことである。残念ながら、以前のコンソールベースのゲームコンソールは、通常、そのようなコンテンツをダウンロードする機能を提供しておらず、まして、コンテンツをダウンロードし、そのコンテンツを使用する資格があるコンソールだけにダウンロードおよび使用を行うことを限定する機能を提供することはなかった。
【０００４】
尚、本明細書では、読者は、暗号化、解読、認証、ハッシング（ｈａｓｈｉｎｇ）、およびデジタル署名などの基本的な暗号法の原理に精通しているものと想定する。いくつかの文献に暗号法の基本的な概説に関連した技術内容が開示されている（例えば、非特許文献１を参照）。
【０００５】
【非特許文献１】
Ｂｒｕｃｅ　Ｓｃｈｎｅｉｅｒ，　”Ａｐｐｌｉｅｄ　Ｃｒｙｐｔｏｇｒａｐｈｙ：　Ｐｒｏｔｏｃｏｌｓ，Ａｌｇｏｒｉｔｈｍｓ，ａｎｄ　Ｓｏｕｒｃｅ　Ｃｏｄｅ　ｉｎ　Ｃ”，　ｐｕｂｌｉｓｈｅｄ　ｂｙ　Ｊｏｈｎ　Ｗｉｌｅｙ　＆　Ｓｏｎｓ，　ｃｏｐｙｒｉｇｈｔ　１９９４　（ｓｅｃｏｎｄ　ｅｄｉｔｉｏｎ　１９９６）
【０００６】
【発明が解決しようとする課題】
従来のシステムには上述のような問題があり、その解決のためにコンテンツに対するアクセスの管理が必要であるという点において、上述した従来技術には未だ改善の余地が残っている。
【０００７】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、コンテンツを受け取る資格のあるデバイスだけが、コンテンツを受け取り、使用することができるようにする、コンテンツに対するアクセスを管理する方法及びシステムを提供することにある。
【０００８】
【課題を解決するための手段】
コンテンツに対するアクセスの管理を本明細書で説明する。
【０００９】
一態様によれば、コンテンツ照会（ｒｅｆｅｒｒａｌ）要求がデバイスから受信される。コンテンツ参照要求に応答して、コンテンツのソースの識別子と、デバイスがそのコンテンツを解読することを可能にする１つまたは複数の鍵がともに、そのデバイスに送信される。
【００１０】
別の態様によれば、複数のコンテンツパッケージがどこに記憶されているかのレコードが保持される。複数のコンテンツパッケージの少なくとも１つを解読するのにそれぞれを使用することができる複数の鍵のレコードも保持される。複数のコンテンツパッケージの特定の１つに関して、複数の要求側デバイスのどれが、コンテンツパッケージが記憶されている場所の指示、ならびにそのコンテンツパッケージを解読するのに使用することができる複数の鍵のなかの１つを受け取ることができるかが制限される。
【００１１】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。本明細書全体で同様の構成要素および／または同様の特徴を指すのに同じ符号を使用する。
【００１２】
以下の解説では、読者は、暗号化、解読、認証、ハッシング（ｈａｓｈｉｎｇ）、およびデジタル署名などの基本的な暗号法の原理に精通しているものと想定する。
【００１３】
コンテンツに対するアクセスの管理を本明細書で説明する。照会ソースが、デバイス（例えば、ゲームコンソール）にダウンロードするのに利用可能な様々なコンテンツ、ならびにどのデバイスおよび／またはユーザが、そのコンテンツをダウンロードすることが許可されているか、およびそのコンテンツを解読するのに使用することができる１つまたは複数の暗号鍵のレコードを保持する。デバイスが、自らに（および／またはデバイスのユーザに）ダウンロードすることが許可されているコンテンツに関する照会を要求したとき、照会ソースは、デバイスがそのコンテンツを解読するのに使用することができる１つまたは複数の鍵と、そのコンテンツのソースの識別子をともに返す。次に、デバイスは、コンテンツソースからコンテンツを取得し、照会ソースから取得された１つまたは複数の鍵を使用して取得されたコンテンツを解読する。
【００１４】
図１は、コンテンツアクセス管理を使用することができる例示的な環境１００を示すブロック図である。ゲームコンソール１０２、照会ソース１０４、およびコンテンツソース１０６は、環境１００の一部である。ゲームコンソール１０２は、ゲームコンソール１０２と照会ソース１０４の間の通信を可能にする様々な結合の任意のものを介して照会ソース１０４に結合される。同様に、ゲームコンソール１０２は、ゲームコンソール１０２とコンテンツソース１０６の間の通信を可能にする様々な結合の任意のものを介してコンテンツソース１０６に結合される。一実施形態では、結合には、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）などの１つまたは複数のネットワークが含まれることが可能である。単一のゲームコンソール１０２、単一の照会ソース１０４、および単一のコンテンツソース１０６を図１に示しているが、複数のコンソール１０２、複数の照会ソース１０４、および／または複数のコンテンツソース１０６が環境１００に含まれることが可能である。
【００１５】
コンテンツソース１０６は、リモートのデバイス、あるいはローカルのデバイスであることが可能であることに留意されたい。リモートのコンテンツソース１０６は、例えば、ネットワーク（インターネット、ＬＡＮ、ＷＡＮなどの）を介してゲームコンソール１０２がアクセスすることができるサーバデバイスであることが可能である。リモートのコンテンツソース１０６は、ゲームコンソール１０２にコンテンツを提供することができる任意のタイプのコンピューティングデバイスであることが可能である。そのようなコンピューティングデバイスは、例えば、サーバデバイス、ワークステーション、デスクトップＰＣ（ｐｅｒｓｏｎａｌ　ｃｏｍｐｕｔｅｒ）、別のゲームコンソール等であることが可能である。ローカルのコンテンツソース１０６は、ゲームコンソール１０２がローカルでアクセスすることができるソースである。例えば、ローカルのコンテンツソース１０６は、取外し可能な光ディスク、取外し可能な磁気ディスク、取外し可能な不揮発性のメモリデバイス（フラッシュメモリデバイスなどの）等であることが可能である。
【００１６】
通常、環境１００において、ゲームコンソール１０２が、コンテンツ照会要求を照会ソース１０４に送信する。照会ソース１０４は、要求側（ゲームコンソール１０２、および／またはゲームコンソール１０２のユーザ）の認証を行い、要求側が要求のコンテンツにアクセスすることが許されていることを検証する。要求側が認証され、検証されると、照会ソース１０４は、ゲームコンソール１０２が要求のコンテンツを獲得することができる場所を選択する。照会ソース１０４は、この場所の識別子、ならびにコンテンツを解読するのに使用することができる１つまたは複数の鍵をゲームコンソール１０２に送信する。次に、ゲームコンソール１０２は、特定された場所においてソースからコンテンツを取得し、照会ソース１０４から受け取られた１つまたは複数の鍵を使用してコンテンツを解読する。
【００１７】
照会ソース１０４は、認証モジュール１０８、検証モジュール１１０、および選択モジュール１１２を含む。照会ソース１０４は、モジュール１０８、１１０、および１１２をそれぞれが含むことが可能な複数のサーバを含むことが可能であり、あるいはモジュール１０８、１１０、および１１２が、異なるサーバ上に配置されることも可能である。照会ソース１０４が複数のサーバを含む状況では、複数のサーバが、インターネット、ＬＡＮ、およびＷＡＮなどの様々なネットワークを介して互いに結合されることが可能である。
【００１８】
認証モジュール１０８は、コンテンツの要求側が、実際に、自ら主張するとおりのユーザおよび／またはゲームコンソールであることを認証することを担う。認証モジュール１０８は、自らこの認証を行うための、構成要素を含みデータへのアクセスを有し、あるいはこの認証のために別のデバイスにアクセスし、そのデバイスを頼りにすることが可能である。１つの例示的な実施形態では、以下により詳細に説明するとおり、セキュリティゲートウェイが、照会ソース１０４とゲームコンソール１０２の間に配置され、前述の認証を行うのに認証モジュール１０８が頼りにする。
【００１９】
検証モジュール１１０は、特定の要求側が要求のコンテンツにアクセスすることが許されているのを検証することを担う。この検証を行う際に、いくつかの異なる基準が、検証モジュール１１０によって使用されることが可能である。そのような基準の例には、次のものが含まれる。すなわち、要求側が適切な料金を支払っているかどうか、要求側が、コンテンツを使用するのが可能な地域に関連しているかどうか、要求の時点にゲームコンソール上で実行されているアプリケーションが、コンテンツにアクセスすることが許されているかどうか、要求側が、要求のコンテンツのレイティングｒａｔｉｎｇ）（例えば、周知のＥＳＲＢ（Ｅｎｔｅｒｔａｉｎｍｅｎｔ　Ｓｏｆｔｗａｒｅ　Ｒａｔｉｎｇ　Ｂｏａｒｄ）評定に基づく）を有するコンテンツにアクセスすることが許されているかどうか、要求側が、コンテンツにアクセスするのに十分な年齢に達しているかどうか、要求側が、コンテンツに対する権利の交付を受けている（例えば、別のユーザにより、トーナメントで勝った結果や競技の賞等として）かどうか等である。
【００２０】
選択モジュール１１２は、特定の要求側が、特定のコンテンツを複数のソースのどれから取得すべきかを判定することを担う。同一のコンテンツが、複数の異なるコンテンツソース１０６から入手可能である可能性がある。そのような状況において、選択モジュール１１２は、様々な基準を使用して、特定の要求側が、そのコンテンツを複数の異なるコンテンツソースのどれから取得すべきかを判定する。そのような基準の例には、次のものが含まれる。すなわち、その他のソースとの対比でそのソースに与えられるべき選好度を示す各ソースに割り当てられたランク、要求側の地理的場所（例えば、要求側に最も近く位置しているソースが選択される）、異なるソースの現在の対応可能性、異なるソースにおける現在のトラフィック、またはかかっている負荷、異なるソースを使用することの費用、要求側の加入レベル（例えば、より高い料金を支払うプレミアム加入者（ゲームコンソール、および／またはゲームコンソールの所有者）が、より高速のサーバを使用する、またはより軽い負荷がかかっているソースに誘導されることが可能である）、サービス品質（例えば、地理的近さ、ネットワークパフォーマンス、参照された加入者ステータス等の１つまたは複数を含む）等である。
【００２１】
したがって、照会ソース１０４が、様々なコンテンツが記憶されている場所のレコードを保持し、どの要求側がコンテンツにアクセスすることが許されているかのレコードを保持し、またコンテンツを解読するのに必要な様々な鍵の配布の制御も行う。照会ソース１０４によって保持される様々なレコードおよび情報は、ソース１０４がアクセスすることができるデータベース１１４の中に保存される。
【００２２】
コンテンツソース１０６は、１つまたは複数のコンテンツ１１６を記憶することができる。コンテンツのそれぞれは、同一の鍵で暗号化されることが可能であり、あるいは異なる鍵で暗号化されることが可能である。コンテンツは、データベースの中、ファイルディレクトリの中、異なる取外し可能なディスク上等に記憶するなどの様々な形の任意の形で記憶することができる。コンテンツ１１６のそれぞれは、アプリケーションのための（例えば、ゲーム、オーディオおよび／またはビデオ再生アプリケーション、参照アプリケーションまたは生産性アプリケーション等のための）実質的にあらゆるタイプのコンテンツであることが可能である。そのようなコンテンツの例には、次のものが含まれる。すなわち、ゲーム全体（またはその他のアプリケーション全体）のそれ自体、ゲームのセグメント（例えば、ゲームのための新しいエピソード）、ゲームに関する統計（例えば、フットボールシーズン中の今週の最新ＮＦＬ（Ｎａｔｉｏｎａｌ　Ｆｏｏｔｂａｌｌ　Ｌｅａｇｕｅ）統計）、ゲームに関するフィーチャ（ｆｅａｔｕｒｅ）（例えば、武器、キャラクタ、レベル、走路、乗り物等）、アプリケーションとともに最初に出荷されたモジュールにおける問題またはバグを修正するモジュール、以上の組合せ等である。さらに、どれだけの量のコンテンツが１つのコンテンツとして記憶されるかは、異なる可能性がある（例えば、コンテンツ開発者および／またはゲーム設計者の所望に基づき）。例えば、１つのコンテンツが、新しい武器だけを含み、別の１つのコンテンツが、新しいキャラクタだけを含み、さらに別の１つのコンテンツが、新しい走路と新しい乗り物をともに含むことが可能である。
【００２３】
本明細書では、コンテンツに対するアクセスを管理することについて、主にゲームコンソールに関連して述べているが、ゲームコンソールは、さらなる機能も含む可能性があることに留意されたい。例えば、ゲームコンソールが、デジタルＶＣＲ（ｖｉｄｅｏ　ｃａｒｔｒｉｄｇｅ　［ｃａｓｓｅｔｔｅ］　ｒｅｃｏｒｄｅｒ）として動作することができるようにデジタルビデオ記録機能を含むこと、ゲームコンソールが、テレビジョン信号（放送信号であれ、ケーブル信号であれ、サテライト信号等であれ）に同調し、復号化することができるようにチャネル同調機能を含むこと等が可能である。さらに、本明細書で説明するコンテンツに対するアクセスの管理は、デスクトップコンピュータ、ワークステーション、サーバ、ノートブックコンピュータ、ポータブルコンピュータまたはハンドヘルドコンピュータ、インターネット機器、携帯電話機、パーソナルデジタルアシスタント（ＰＤＡ）などのゲームコンソール以外のデバイスで使用することも可能である。
【００２４】
さらに、ゲームコンソール、および／またはゲームタイトルに関連する本明細書の解説は、その他のタイプの機器にも同様に当てはまることに留意されたい。
【００２５】
図２は、コンテンツアクセスを管理するための例示的なプロセス１４０を示すフローチャートである。図２のプロセスは、照会ソース（例えば、図１のソース１０４）、ゲームコンソール（例えば、図１のゲームコンソール１０２）、およびコンテンツソース（例えば、図１のソース１０６）によって実施される。照会ソースによって行われる動作を図２の左側に示し、ゲームコンソールによって行われる動作を図２の中央に示し、またコンテンツソースによって行われる動作を図２の右側に示している。図２のプロセスについて図１の構成要素を参照して述べる。
【００２６】
最初、ゲームコンソール１０２が、コンテンツ照会要求を発行する（動作１４２）。コンテンツ照会要求は、特定のコンテンツのソースを照会する要求である。あるいは、ゲームコンソール１０２は、単に照会ソース１０４からコンテンツ自体を要求し、代わりに、コンテンツのソースへの照会を受け取ることが可能である。コンテンツ照会要求は、その要求が行われた時点におけるゲームコンソール１０２のユーザの識別子、その要求が行われた時点におけるゲームコンソール１０２上で実行されているアプリケーション（例えば、ゲームタイトル）の識別子、その要求を行っているゲームコンソール１０２の識別子、要求されているコンテンツの識別子、およびゲームコンソールの最高ＥＳＲＢ評定の現在の設定を含む。
【００２７】
照会ソース１０４が、コンテンツ照会要求を受け取り（動作１４４）、認証モジュール１０８が、要求側の認証を行う（動作１４６）。前述したとおり、この認証は、ゲームコンソール１０２および／またはゲームコンソール１０２のユーザの認証であることが可能である。要求側を認証することができない場合、プロセス１４０は、動作１４６で停止する。要求側を認証することができないという指示を要求側に返すことが可能であり、あるいは照会要求を無視して、そのことの指示が要求側に戻されないことが可能である。
【００２８】
要求側が認証されたものと想定すると、検証モジュール１１０が、要求側が要求のコンテンツにアクセスできることを検証する（動作１４８）。前述したとおり、この検証を行う際、様々な基準（例えば、適切な料金が支払われているかどうか、要求側が、特定の地理的区域に関連しているかどうか等）を使用することができる。要求側が、コンテンツにアクセスすることが許されていない場合、プロセス１４０は、動作１４８で停止する。要求側がコンテンツにアクセスすることが許されていないことをその要求側に知らせる指示を要求側に返すことが可能であり、この指示は、オプションとして、なぜ要求側がそのコンテンツにアクセスすることが許されていないかについての指示を含む。あるいは、そのような指示が全く要求側に戻されないことが可能である。
【００２９】
要求側が、コンテンツにアクセスすることが許されているものとして検証されたと想定すると、選択モジュール１１２が、そのコンテンツのソースを判定する（動作１５０）。前述したとおり、この判定を行う際、様々な基準を使用することができる。コンテンツのソースが判定されると、選択モジュール１１２は、そのソースの識別子、ならびに（コンテンツがソースから受信された後）そのコンテンツを解読するのに使用することができる１つまたは複数の鍵をゲームコンソールに送信する（動作１５２）。ゲームコンソール１０２は、ソース識別子および鍵を受信し（動作１５４）、特定されたソースにコンテンツを要求する（動作１５６）。
【００３０】
そのコンテンツ要求が、コンテンツソース１０６において受信される（動作１５８）。この要求に応答して、コンテンツソース１０６は、要求のコンテンツにアクセスし、要求のコンテンツをゲームコンソール１０２に送信する（動作１６０）。ゲームコンソール１０２は、要求のコンテンツを受信し（動作１６２）、受信されたコンテンツが、実際にコンテンツソース１０６からのものであることを検証する（動作１６４）。
【００３１】
一実施形態では、動作１６４におけるこの検証は、公開鍵／秘密鍵暗号化およびダイジェストを使用して行われる。コンテンツソース１０６は、自らが記憶する各コンテンツに関して、そのコンテンツのダイジェストを記憶する。コンテンツのダイジェストは、従来のハッシングアルゴリズム（例えば、メッセージダイジェスト２（ＭＤ２）、ＭＤ５、セキュアハッシュアルゴリズム（ＳＨＡ）、ＳＨＡ−１等）を使用することによるなど、様々な従来のやり方の任意のやり方で生成することができる。コンテンツに関するダイジェストは、コンテンツソース１０６によって生成されることが可能であり、あるいは別のデバイスによって生成されて、コンテンツソース１０６に通信される（例えば、コンテンツとともに）ことが可能である。また、コンテンツソース１０６は、関連する公開鍵／秘密鍵ペアも有し、そのペアの秘密鍵を使用して各ダイジェストを暗号化する。
【００３２】
要求のコンテンツをゲームコンソールに送信する際、コンテンツソース１０６は、そのコンテンツの暗号化されたダイジェストも送信する。動作１６４における検証の一環として、ゲームコンソール１０２は、コンテンツソース１０６に関連する公開鍵を使用して、自らがコンテンツソース１０６から受信した暗号化されたダイジェストを解読する。次に、ゲームコンソール１０２は、受信されたコンテンツに関するダイジェストを生成し（コンテンツソース１０６によって記憶されたダイジェストを生成するのに使用されたのと同じアルゴリズムを使用して）、その生成されたダイジェストを解読されたダイジェストと比較する。２つのダイジェストが同一である場合、そのコンテンツは、コンテンツソース１０６からのものとして検証される（コンテンツを認証するとも言う）。というのは、コンテンツソース１０６の公開鍵を使用してダイジェストを解読することを可能にするようにダイジェストを暗号化することができる他のデバイスは存在しないものと考えられるからである。２つのダイジェストが同一であることにより、要求のコンテンツが変更されていないことがさらに検証される。というのは、そのコンテンツが、コンテンツソース１０６から転送されているからである。
【００３３】
ゲームコンソール１０２は、コンテンツソース１０６の公開鍵／秘密鍵ペアの公開鍵と、コンテンツのダイジェストを生成している場合、コンテンツのダイジェストを生成するのに使用されたアルゴリズムをともに認知している。ゲームコンソール１０２は、様々な仕方でダイジェストを生成するように公開鍵およびアルゴリズムを認知させられることが可能である。例えば、公開鍵およびアルゴリズムが、照会ソースからの応答の中に含められ（例えば、図２の動作１５２および１５４において）、ゲームコンソール１０２が、周知の場所にアクセスして公開鍵およびアルゴリズムを獲得すること等が可能である。
【００３４】
受信されたコンテンツが検証されなかった場合、そのコンテンツは、ゲームコンソール１０２によって使用されない。ゲームコンソール１０２は、ソースに対するコンテンツの要求を繰り返すことが可能であり、あるいは異なるソースを試みることが可能である（オプションとして、動作１４２で要求を繰り返すが、前に特定されたソース以外のソースを所望するという照会ソース１０４に対する指示を添えて）。しかし、受信されたコンテンツが検証された場合、ゲームコンソール１０２は、受信されたコンテンツを解読し、インストールする（動作１６６）。インストールは、解読されたコンテンツの単なる記憶であることが可能であり、あるいは解読されたコンテンツに対してその他の処理を行って記憶の準備をすることが可能である。このインストールの厳密な性質は、アプリケーション（例えば、ゲームタイトル）により、コンテンツの性質により、および／またはアプリケーション（例えば、ゲームタイトル）開発者の所望により異なることが可能である。
【００３５】
コンテンツは、ローカルのハードドライブに、ローカルの不揮発性メモリ（例えば、フラッシュメモリ）に、書換え可能な光ディスクおよび／または記録可能な光ディスクに記憶するなどの様々な形の任意の形で記憶することができる。要求のコンテンツが動作１６６で解読されると、動作１５４で照会ソース１０４から受信された鍵は、もはや必要ないことに留意されたい。ゲームコンソール１０２は、オプションとして、独自の暗号化鍵を使用して自らが記憶するコンテンツを暗号化することができ、かつ／または自らが記憶するコンテンツを保護する他のセキュリティ策を課すことができる。
【００３６】
一実施形態では、コンテンツを解読するのに使用される鍵は、対称鍵であり、他方、コンテンツのダイジェストを解読するのに使用される鍵は、公開鍵／秘密鍵ペアの公開鍵である。別法では、公開鍵／秘密鍵ペアを使用してコンテンツ自体の暗号化および解読を行うこと、または対称鍵を使用してコンテンツのダイジェストの暗号化および解読を行うことが可能である。
【００３７】
プロセス１４０は、照会ソース１０４が、ゲームコンソール１０２がコンテンツを複数のソースのどれから取得すべきかを判定する（動作１５０において）ものとして示されている。別法では、可能なソース（およびオプションとしてソースのランク）のすべての識別子をゲームコンソール１０２に返すことが可能である。次に、ゲームコンソール１０２が、どのソースにアクセスするかを判定することができ、そのソースが何らかの理由で（例えば、ソースにおけるハードウェア障害、またはネットワーク障害に起因して）アクセス可能ではない場合、別のソースを選択して試みることができる。
【００３８】
図３は、ゲームコンソールとデバイス（例えば、図１の照会ソース１０４、または図５に関連して以下に述べるセキュリティゲートウェイなどの中間デバイス）の間でセキュアな通信チャネルを確立するための例示的なプロセス２００を示すフローチャートである。ゲームコンソールとデバイスの間でセキュアな通信チャネルを確立することにより、ゲームコンソール識別子、およびゲームコンソールの現在のユーザの識別子の認証を行うことができる（例えば、図２の動作１４６において）。図３のプロセスは、ソフトウェアで、ファームウェアで、ハードウェアで、または以上の組合せで行うことが可能である。セキュアな通信チャネルを確立するための特定のプロセスについて図３に関連して述べるが、別法として、様々な他の従来のプロセスの任意のプロセスを使用してセキュアな通信チャネルを確立することも可能であることに留意されたい。
【００３９】
最初、セキュリティチケットが、デバイスにおいて受信される（動作２０２）。１つの例示的な実施形態では、セキュリティチケットは、鍵配信センタ（図５で以下に示す）から獲得されるケルベロス（Ｋｅｒｂｅｒｏｓ）チケットである。ケルベロスチケットは、単一のチケットの中で、特定のゲームコンソール１０２の識別、およびそのゲームコンソール１０２においてゲームを行っている１名または複数名のユーザの識別を認証するケルベロス様式の認証プロトコルを使用してゲームコンソール１０２によって獲得される。ゲームコンソール１０２は、ケルベロスチケットを以下のように獲得する。
【００４０】
解説のため、ゲームコンソール１０２の４名のユーザが存在するものと想定する。各ユーザには、識別Ｕ１、Ｕ２、Ｕ３、およびＵ４が与えられており、ユーザ鍵Ｋ１、Ｋ２、Ｋ３、およびＫ４が割り当てられている。またゲームコンソール１０２にも独自の識別Ｃ、およびゲームコンソール鍵ＫＣが割り当てられている。さらに、ゲームディスクなどのゲームタイトルに、別個の識別Ｇが割り当てられている。同様に、デバイス（例えば、照会ソース１０４またはセキュリティゲートウェイ）に、独自の識別Ａ、および鍵ＫＡが割り当てられている。ユーザ、ゲームコンソール、およびセキュリティゲートウェイの認証は、ある程度、鍵Ｋ１、Ｋ２、Ｋ３、Ｋ４、ＫＣ、および鍵ＫＡに依存することに留意されたい。したがって、以上の鍵を選択し、記憶する際、その鍵が割り当てられたエンティティだけがその鍵を使用することができるように注意が払われなければならない。
【００４１】
ゲームコンソール１０２は、ユーザ識別Ｕ１、Ｕ２、Ｕ３、およびＵ４、ならびにユーザ鍵Ｋ１、Ｋ２、Ｋ３、Ｋ４に基づき、検証されたユーザ識別を生成する。より具体的には、検証されたユーザ識別は、ユーザ鍵から導出されたユーザ識別、および値を含む。検証されたユーザ識別は、鍵配信センタに要求とともにサブミットされ、ゲームコンソールがユーザ鍵の知識を有することを鍵配信センタに実証するのに使用され、したがって、ユーザを暗黙的に認証する。
【００４２】
Ｈ＝ＨＫｙ（Ｍ）：Ｈは、鍵ＫＹを使用するメッセージＭの鍵付き一方向ハッシュ（ＭＡＣ（ｍｅｓｓａｇｅ　ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｃｏｄｅ））である。任意のＭＡＣアルゴリズムを使用することができる。そのようなＭＡＣの一例が、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）ＲＦＣ（Ｒｅｑｕｅｓｔ　Ｆｏｒ　Ｃｏｍｍｅｎｔｓ）　２１０４に準拠するＨＭＡＣ（ｈａｓｈ　ｂａｓｅｄ　ＭＡＣ）アルゴリズムである。
【００４３】
ＥｎｃｒｙｐｔｅｄＭ＝ＥＫｙ（Ｍ）：ＥｎｃｒｙｐｔｅｄＭは、鍵ＫＹを使用して暗号化された形態のメッセージＭである。任意の暗号化アルゴリズムを使用することができる。そのような暗号化アルゴリズムの例には、ＤＥＳ（Ｄａｔａ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）、トリプルＤＥＳ、およびＲＣ４−ＨＭＡＣが含まれる。
【００４４】
Ｍ＝ＤＫｙ（ＥｎｃｒｙｐｔｅｄＭ）：Ｍは、同一の鍵ＫＹを使用して暗号化される前のＥｎｃｒｙｐｔｅｄＭの元のメッセージである。
【００４５】
鍵導出値（ｋｅｙ　ｄｅｒｉｖａｔｉｖｅ　ｖａｌｕｅ）を生成する１つのやり方は、ゲームコンソールの鍵を使用してユーザ鍵の暗号ハッシュをコンピューティングすることである。鍵Ｋ１を有するユーザＵ１の場合、ハッシュＨ１は、以下のとおりコンピューティングされる。
Ｈ１＝ＨＫｃ（Ｋ１）
ハッシュＨ１が鍵導出値を成す。別のやり方は、ユーザ鍵Ｋ１を使用して現在時刻を暗号化することである。
Ｈ１＝ＥＫ１（Ｔ）
この場合も、もたらされる値Ｈ１が鍵導出値を成す。検証されたユーザ識別は、以下のとおり、ユーザ識別Ｕ１と対応する鍵導出値Ｈ１の組合せである。
検証されたユーザ識別＝（Ｕ１，Ｈ１）
【００４６】
ゲームコンソール１０２は、ゲームコンソール識別Ｃ、ゲームタイトル識別Ｇ、デバイスのオンラインサービス識別Ａ、および複数の検証されたユーザ識別（Ｕ１，Ｈ１）、（Ｕ２，Ｈ２）、（Ｕ３，Ｈ３）、および（Ｕ４，Ｈ４）を含む要求を構成する。要求は、以下の識別文字列を有する。
要求　＝　［Ｃ，　Ｇ，　Ａ，　（Ｕ１，　Ｈ１），　（Ｕ２，　Ｈ２），　（Ｕ３，　Ｈ３），　（Ｕ４，　Ｈ４）］
【００４７】
さらに、要求は、あるバージョンの認証プロトコル、およびゲームコンソールによって生成されたランダムなナンス（ｎｏｎｃｅ）を含み、リプライ攻撃に抗することが可能である。要求は、識別文字列全体の受信を検証するのに使用されるチェックサム値をさらに含むことが可能である。ゲームコンソール１０２は、ネットワーク（例えば、図１のネットワーク１０６）を介して要求を鍵配信センタにサブミットする。
【００４８】
鍵配信センタは、要求、ならびにその要求に含まれる識別を評価する。鍵配信センタは、デバイス使用されるランダムなセッション鍵を生成する。この例では、鍵配信センタは、デバイスと通信する際にゲームコンソール１０２によって使用されるランダムなセッション鍵ＫＣＡを生成する（動作２０２において）。
【００４９】
鍵配信センタは、ゲームコンソール１０２によってデバイスに後に提示されるチケットを生成する。デバイスに関して発行される１つのチケットが存在するが、チケットは、複数のユーザに関して有効である。チケットは、要求の中でサブミットされた識別文字列を含む。また、チケットは、チケットが生成された時刻ＴＧ、チケットの失効までの時間の長さを特定する時間ＴＬ、デバイスに関するランダムに生成されたセッション鍵ＫＣＡ、およびゲームコンソール１０２のユーザがアクセスすることが許されたデータセンタ内のサービスデバイス（図１では示さず）を特定するサービスマップＳｍも含む。鍵配信センタは、どのユーザがどのサービスにアクセスすることが許されているか（例えば、どのユーザが、１つまたは複数の有料サービスにアクセスする料金を支払済みであるか）についてのレコードを維持するか、そのレコードを維持する別のデバイス、または別のセンタにアクセスする。チケット内容は、以下のとおり、セキュリティゲートウェイデバイスの鍵ＫＡを利用する対称鍵暗号（例えば、トリプルＤＥＳ）を介して暗号化される。
【００５０】
チケット　＝　ＥＫＡ　［ＴＧ，　ＴＬ，　ＫＣＡ，　Ｓｍ，　Ｃ，　Ｇ，　Ａ，　Ｕ１　，Ｕ２　，Ｕ３　，Ｕ４］
チケットは、対応する鍵導出値Ｈｉを担持しないことに注目されたい。鍵配信センタは、鍵導出値を読み取り、ゲームコンソールがユーザ鍵を知っていると確信すると、ユーザの識別を発行されるチケットの中に入れる。デバイスは、その後、チケットが知らせることはなんでも信頼し、したがって、鍵導出値Ｈｉを見る必要がない。
【００５１】
鍵配信センタは、生成されたチケットをゲームコンソール１０２に返す。ゲームコンソール１０２は、デバイスの鍵ＫＡを知らないので、そのチケットを開くことができず、その内容を変更することができない。また、鍵配信センタは、添付された暗号化されたメッセージの中でセッションセキュリティ鍵も返す。セッション鍵メッセージは、チケット生成時刻ＴＧ、チケット失効までの期間ＴＬ、およびセッションセキュリティ鍵ＫＣＡを含み、メッセージのすべての内容は、以下のとおり、ゲームコンソールの鍵ＫＣを使用して暗号化される。
【００５２】
セッション鍵メッセージ　＝　ＥＫＣ　［ＴＧ，　ＴＬ，　ＫＣＡ］
セッション鍵メッセージは、ゲームコンソールの鍵ＫＣで暗号化されているので、ゲームコンソール１０２は、セッション鍵メッセージを開き、セッション時間パラメータおよびセッション鍵を回復することができる。
【００５３】
ゲームコンソール１０２は、チケットを受け取ると、そのチケットを使用して、デバイスと相互認証を伴うセキュアな鍵交換を行うことができる（動作２０４）。セキュアな鍵交換に関するさらなる情報は、本明細書に組み込まれている米国特許出願１０／１７０，００２号で見ることができる。米国特許出願１０／１７０，００２号の内容は後述される。
【００５４】
鍵交換により、ゲームコンソール１０２およびデバイスが、コンソール１０２とデバイスの間で共有されるが、２つのデバイス間で伝送されることなく、コンソール１０２とデバイスの間で往復するトラフィックに基づいて第三者（例えば、コンソール１０２およびデバイスと同じネットワーク上の別のデバイス）が推論することができない新しい秘密を導出することが可能になる。１つの例示的な実施では、２つのデバイスは、ディフィ−ヘルマン指数演算（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ　ｅｘｐｏｎｅｎｔｉａｔｉｏｎ　ｏｐｅｒａｔｉｏｎ）を使用して新しい秘密を導出する。ディフィ−ヘルマンに関するさらなる情報は、Ｗ．　Ｄｉｆｆｉｅ　ａｎｄ　Ｍ．　Ｅ．　Ｈｅｌｌｍａｎ，　”Ｎｅｗ　ｄｉｒｅｃｔｉｏｎｓ　ｉｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ”，　ＩＥＥＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｈｅｏｒｙ　ｖ．　ＩＴ−１２，　ｎ．　６，　Ｎｏｖ　１９７６，　ｐｐ．　６４４−６５４に見ることができる。
【００５５】
一般に、セキュアな鍵交換は、鍵交換イニシエータ（ｉｎｉｔｉａｔｏｒ）パケットを生成し、そのパケットをデバイスに送信するゲームコンソール１０２によって行われる。デバイスは、鍵交換イニシエータパケットを受信し、受信されたパケットを検証する。パケットが検証されると、デバイスは、ゲームコンソール１０２との通信をセキュアにするのに使用される暗号鍵を生成する。例示的な実施形態では、この暗号鍵は、２つのデバイス間のポイントツーポイント通信をセキュアにするのに使用されるセキュリティ関係鍵である。次に、デバイスは、鍵交換応答パケットを生成し、生成されたパケットをゲームコンソール１０２に送信する。ゲームコンソール１０２は、鍵交換応答パケットを受信し、その受信されたパケットを検証する。パケットが検証されると、ゲームコンソール１０２は、デバイスとの通信をセキュアにするのに使用される暗号鍵を生成する。暗号鍵は、デバイスによって生成されるものと同じである。したがって、ゲームコンソール１０２とデバイスはともに、同じ暗号鍵を有することになるが、双方の間で鍵を実際に伝送することなしにそうなる。
【００５６】
ゲームコンソール１０２は、鍵交換イニシエータメッセージを最初に生成することによって鍵交換イニシエータパケットを生成し、送信する。鍵交換イニシエータメッセージは、以下のとおり、ＮｏｎｃｅＩｎｉｔと呼ばれるゲームコンソール１０２によって生成されたランダム（または擬似ランダム）値を含み、またＸがやはり、ゲームコンソール１０２によって生成されたランダムな（または擬似ランダムな）数であるディフィ−ヘルマン（ｇＸ　ｍｏｄ　Ｎ）値、ならびに鍵交換プロセスが完了した後、このコンソール／セキュリティデバイス通信チャネルを一意的に定義するのに使用されるセキュリティパラメータインデックス値（ＳＰＩ１）を含む。
ＩｎｉｔＭｅｓｓ　＝　［ＮｏｎｃｅＩｎｉｔ，　ＳＰＩ１，　（ｇＸ　ｍｏｄ　Ｎ）］
【００５７】
次に、ゲームコンソール１０２は、鍵配信センタから受信されたケルベロスセッション鍵ＫＣＡを使用して鍵交換イニシエータメッセージのダイジェストをコンピューティングする。ダイジェストは、次のとおりコンピューティングされる。
【００５８】
【数１】
2004056793.tif 000003
【００５９】
あるいは、一般的な一方向ハッシュ（鍵付きでない）も、ＨａｓｈＩｎｉｔＭｅｓｓのコンピューティングにおいて使用することが可能である。鍵のセキュリティは、このハッシュが鍵付きであるか否かに依拠しない。
【００６０】
次に、ゲームコンソール１０２は、ケルベロスオーセンティケータ（ａｕｔｈｅｎｔｉｃａｔｏｒ）を生成する。ケルベロスオーセンティケータは、タイムスタンプ（例えば、ゲームコンソール１０２の現在時刻）、およびＨａｓｈＩｎｉｔＭｅｓｓダイジェストを含む。タイムスタンプは、ゲームコンソール１０２がケルベロスオーセンティケータを生成するたびに毎回、そのデバイス１０２によって増分され、これにより、デバイスが、リプレイ攻撃をよりよく検出することが可能になる。ゲームコンソール１０２は、以下のとおり、ケルベロスセッション鍵ＫＣＡを使用してケルベロスオーセンティケータを暗号化する。
【００６１】
【数２】
2004056793.tif 000004
【００６２】
次に、ゲームコンソール１０２は、鍵交換イニシエータパケットを生成する。鍵交換イニシエータパケットは、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、暗号化されたケルベロスオーセンティケータＡｕｔｈＴ、および鍵配信センタから受信されたデバイスに関するケルベロスチケットを含む。前述したとおり、ケルベロスチケットは、少なくとも、ケルベロスセッション鍵（ＫＣＡ）、チケットが有効でありつづけるある範囲の時間、ゲームコンソール１０２を識別する一意的な番号を含み、以上のすべてが、鍵配信センタとデバイスによって共用される秘密の鍵を使用して暗号化される。ＳＰＩ値は、ゲームコンソール１０２とデバイスの間のセキュリティ関係、すなわち、通信チャネルを識別する。ＳＰＩ１値は、デバイスからゲームコンソール１０２への通信に関連し、またＳＰＩ２値は、ゲームコンソール１０２からデバイスへの通信に関連する。したがって、鍵交換イニシエータパケットは、以下のとおりである。
ＩｎｉｔＰａｃｋｅｔ　＝　［ＩｎｉｔＭｅｓｓ，　ＡｕｔｈＴ，　Ｔｉｃｋｅｔ］
【００６３】
オーセンティケータとチケットの組合せは、ケルベロス用語においてＡＰ要求と呼ばれていることに留意されたい。次に、ゲームコンソール１０２は、鍵交換イニシエータパケットをセキュリティゲートウェイデバイス１５０に送信する。
【００６４】
デバイスは、鍵交換イニシエータパケットＩｎｉｔＰａｃｋｅｔを受信する。一実施では、デバイスは、すべての鍵交換イニシエータパケットが所定の形式になっており、かつ所定のサイズであることを予期している。その所定の形式でない、またはその所定のサイズでないあらゆる鍵交換イニシエータパケットは、デバイスによって無視される。あるいは、デバイスは、鍵交換イニシエータパケットが、様々な形式になっており、かつ／または様々なサイズになっていることを許すことが可能である。
【００６５】
鍵交換イニシエータパケットが受信されると、デバイスは、そのデバイスが鍵配信センタと共有する鍵を使用してケルベロスチケットを解読する。次に、デバイスは、解読されたチケットをチェックして、チケットが失効しているかどうかを判定する。現在時刻が、チケットが有効でありつづける時間の範囲（チケットの中で特定される）内に含まれる場合、そのチケットは、失効していない。しかし、現在時刻が、チケットが有効でありつづける時間の範囲内に含まれない場合、そのチケットは、失効している。ケルベロスチケットが失効している場合、鍵交換プロセスは失敗し、ゲームコンソール１０２とデバイスの間でセキュリティ関係が全く確立されないことがもたらされる。デバイスは、鍵交換プロセスが失敗したことをゲームコンソール１０２に通知することができ、あるいは、デバイスは、受信されたＩｎｉｔＰａｃｋｅｔを単に削除して、ゲームコンソール１０２に通知を行わないことが可能である。
【００６６】
しかし、ケルベロスチケットが失効していない場合、デバイスは、解読されたケルベロスチケットから回復されたケルベロスセッション鍵ＫＣＡを使用してケルベロスオーセンティケータＡｕｔｈＴを解読する。次に、デバイスは、ケルベロスオーセンティケータの中のタイムスタンプＴｉｍｅにアクセスし、そのタイムスタンプが受入れ可能であるかどうかをチェックする。タイムスタンプは、デバイス上の現在時刻との同期が離れすぎていない場合、受入れ可能である。例示的な実施では、タイムスタンプは、デバイス上の現在時間からある閾値時間（例えば、推奨されるケルベロス時間スキューである５分間）の範囲内にある場合、受入れ可能である。タイムスタンプが受入れ可能ではない場合、鍵交換プロセスは失敗である。
【００６７】
タイムスタンプが受入れ可能である場合、デバイスは、鍵交換メッセージＩｎｉｔＭｅｓｓのダイジェストをコンピューティングする。デバイスは、ゲームコンソール１０２がダイジェストＨａｓｈＩｎｉｔＭｅｓｓをコンピューティングしたのと同じ仕方でダイジェストをコンピューティングする。次に、デバイスは、コンピューティングしたダイジェスト値が、暗号化されたケルベロスオーセンティケータＡｕｔｈＴの一部としてゲームコンソール１０２から受け取られたダイジェスト値と一致する（等しい）かどうかをチェックする。２つのダイジェスト値が同じである場合、そのことは、鍵交換メッセージＩｎｉｔＭｅｓｓが、ゲームコンソール１０２とデバイスの間で変更されていない（例えば、鍵交換メッセージＩｎｉｔＭｅｓｓが不正変更されていない）ことを確認する役割をする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは失敗である。
【００６８】
しかし、受け取られたダイジェスト値とコンピューティングされたダイジェスト値が一致する場合、デバイスは、ケルベロスオーセンティケータが再生されているかどうかをチェックする。デバイスは、各ゲームコンソールＣから受け取った各ケルベロスオーセンティケータからのタイムスタンプのレコード（これは、ケルベロスチケットの中で明らかにされる）を維持する。デバイスは、そのデバイスによって記録された最新のタイムスタンプより新しくないタイムスタンプＴｉｍｅを伴うケルベロスオーセンティケータを受け取った場合、そのケルベロスオーセンティケータが再生されていることを知る。ケルベロスオーセンティケータが再生されている場合、鍵交換イニシエータパケットは有効ではなく、鍵交換プロセスは失敗である。しかし、ケルベロスオーセンティケータが再生されていない場合、鍵交換イニシエータパケットは、デバイスによって検証されたことになる。以上すべての試験が満たされ、かつ鍵交換イニシエータパケットが検証された場合、デバイスは、ゲームコンソール１０２を、実際にゲームコンソール１０２による主張どおりのデバイスであるものとして認証した、すなわち、デバイスは、ゲームコンソール１０２がケルベロスセッション鍵ＫＣＡの知識を有すること検証したことになる。
【００６９】
最初、デバイスは、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、ケルベロスセッション鍵ＫＣＡ、ゲームコンソール１０２からのナンス（ＮｏｎｃｅＩｎｉｔ）、およびデバイスによって生成されたナンス（ＮｏｎｃｅＲｅｓｐ）に基づいて暗号鍵を生成する。デバイスは、ランダムな（または擬似ランダムな）数Ｙ、ならびにＮｏｎｃｅＲｅｓｐと呼ばれるランダム値を生成する。デバイスは、ディフィ−ヘルマン値（ｇＸＹ　ｍｏｄ　Ｎ）、およびディフィ−ヘルマン値（ｇＹ　ｍｏｄ　Ｎ）をさらにコンピューティングする。この時点で、デバイスは、セキュリティ関係鍵をコンピューティングするのに十分なデータを有する。セキュリティ関係鍵は、２つのコンソール間のポイントツーポイント通信をセキュアにするのに使用される。例示的な実施では、デバイスは、２つのディフィ−ヘルマン値（（ｇＸ　ｍｏｄ　Ｎ）および（Ｙ））を使用して関数（ｇＸＹ　ｍｏｄ　Ｎ）をコンピューティングする。次に、デバイスは、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、（ｇＸＹ　ｍｏｄ　Ｎ）、およびケルベロスセッション鍵ＫＣＡに基づく様々なアルゴリズムを使用して様々なダイジェストをコンピューティングすることができる。次に、そのダイジェストを使用してセキュリティ関係鍵を形成する。１つの例示的な実施では、デバイスは、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、および（ｇＸＹ　ｍｏｄ　Ｎ）を入力として使用し、またケルベロスセッション鍵ＫＣＡも使用して、両方向ですべてのセキュアなパケットを認証し、かつ暗号化／解読するためのセキュリティ関係鍵として使用される４つの異なるダイジェストをコンピューティングする（認証のための１つの鍵、暗号化のための１つの鍵にそれぞれの方向として２を掛けて、合計で４になる）。あるいは、セッション鍵ＫＣＡ自体を両方向でセキュアなパケットを認証し、かつ／または暗号化／解読するために使用することができる。
【００７０】
次に、デバイスは、鍵交換応答メッセージを生成する。鍵交換応答メッセージは、以下のとおり、ＮｏｎｃｅＩｎｉｔ、ゲームコンソール１０２から受信されたタイムスタンプＴｉｍｅ、ＮｏｎｃｅＲｅｓｐ、ディフィ−ヘルマン値（ｇＹ
ｍｏｄ　Ｎ）、およびＳＰＩ２値を含む。
ＲｅｓｐＭｅｓｓ　＝　［ＮｏｎｃｅＩｎｉｔ，　ＳＰＩ２，　ＮｏｎｃｅＲｅｓｐ，　（ｇＹ　ｍｏｄ　Ｎ）］
ＳＰＩ２値は、デバイスによって生成され、ゲームコンソール１０２からデバイスへのすべての通信に関連付けられる。次に、デバイスは、以下のとおり、ケルベロスセッション鍵およびハッシュ関数Ｈを使用して応答メッセージのダイジェストをコンピューティングする。
【００７１】
【数３】
2004056793.tif 000005
【００７２】
ＨａｓｈＲｅｓｐＭｅｓｓを生成するのに使用されるハッシュ関数Ｈは、ＨａｓｈＩｎｉｔＭｅｓｓ（前述した）を生成するのに使用されるハッシュ関数Ｈと同一であること、あるいは異なるハッシュ関数であることが可能である。
【００７３】
次に、デバイスは、以下のとおり、コンピューティングされたハッシュダイジェストと、ケルベロスオーセンティケータからのタイムスタンプＴｉｍｅをともに含むケルベロス応答メッセージを生成する。
ＲｅｐｌｙＭｅｓｓ　＝　［ＨａｓｈＲｅｓｐＭｅｓｓ，　Ｔｉｍｅ］
【００７４】
次に、デバイスは、以下のとおり、暗号化アルゴリズムＥ（例えば、トリプルＤＥＳ）およびケルベロスセッション鍵ＫＣＡを使用してケルベロス応答メッセージＲｅｐｌｙＭｅｓｓを暗号化する。
【００７５】
【数４】
2004056793.tif 000006
【００７６】
ＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを生成するのに使用される暗号化アルゴリズムＥは、ＡｕｔｈＴ（前述した）を生成するのに使用されたのと同一の暗号化アルゴリズムであること、あるいは異なる暗号化アルゴリズムであることが可能である。
【００７７】
次に、デバイスは、以下のとおり、鍵交換応答メッセージＲｅｓｐＭｅｓｓ、および暗号化されたケルベロス応答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを含む鍵交換応答パケットを生成する。
ＲｅｓｐＰａｃｋｅｔ　＝　［ＲｅｓｐＭｅｓｓ，　ＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓ］
【００７８】
次に、デバイスは、鍵交換応答パケットＲｅｓｐＰａｃｋｅｔをゲームコンソール１０２に送信する。
【００７９】
ゲームコンソール１０２は、デバイスから鍵交換応答パケットＲｅｓｐＰａｃｋｅｔを受信する。ゲームコンソール１０２は、ケルベロスセッション鍵ＫＣＡを使用してケルベロス応答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを解読する。次に、ゲームコンソール１０２は、解読された応答メッセージの中のタイムスタンプＴｉｍｅが、ゲームコンソール１０２がデバイスに送信したタイムスタンプＴｉｍｅと一致するかどうかをチェックする。両タイムスタンプが一致する場合（言い換えれば、タイムスタンプが等しい場合）、その一致により、デバイスが、ケルベロスチケットおよびケルベロスオーセンティケータを解読する（したがって、ケルベロスセッション鍵ＫＣＡの知識を有する）ことができ、したがって、現実に、自ら主張するとおりのデバイスであることが確認される。したがって、デバイスは、以上のタイムスタンプ値が一致する場合、ゲームコンソール１０２に対して認証される。
【００８０】
タイムスタンプ値が一致しない場合、鍵交換プロセスは失敗であり、ゲームコンソール１０２とデバイスの間で全くセキュリティ関係が確立されないことがもたらされる（前述したのと同様に、ゲームコンソール１０２は、鍵交換プロセスが失敗したことをデバイスに通知することも、通知しないことも可能である）。ただし、タイムスタンプ値が一致した場合、デバイスは、ゲームコンソール１０２に対して認証され、ゲームコンソール１０２は、ケルベロスセッション鍵ＫＣＡを使用して鍵交換応答メッセージＲｅｓｐＭｅｓｓのダイジェストをコンピューティングすることにとりかかる。ゲームコンソール１０２は、デバイスがＨａｓｈＲｅｓｐＭｅｓｓ（前述した）をコンピューティングしたのと同じやり方でダイジェストをコンピューティングする。次に、ゲームコンソール１０２は、自らがコンピューティングしたダイジェスト値が、暗号化されたケルベロス応答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓの一部としてデバイスから受け取られたダイジェスト値と一致する（等しい）かどうかをチェックする。２つのダイジェスト値が同じである場合、そのことは、鍵交換応答メッセージＲｅｓｐＭｅｓｓが、デバイスとゲームコンソール１０２の間で変更されていない（例えば、鍵交換応答メッセージＲｅｓｐＭｅｓｓが不正変更されていない）ことを確認する役割をする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは、失敗である。
【００８１】
ただし、２つのダイジェスト値が一致した場合、ゲームコンソール１０２は、ケルベロスセッション鍵ＫＣＡ、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、およびｇＸＹ　ｍｏｄ　Ｎに基づいて暗号鍵を生成する。デバイスが暗号鍵を生成することに関して前述したのと同様に、この時点で、ゲームコンソール１０２は、ディフィ−ヘルマン値（ｇＸＹ　ｍｏｄ　Ｎ）をコンピューティングし、またセキュリティ関係鍵をコンピューティングするのに十分なデータを有している。ゲームコンソール１０２によってコンピューティングされるセキュリティ関係鍵は、デバイスによって生成されるものと同じであり、同じやり方でコンピューティングされる。ｇＸＹ　ｍｏｄ　Ｎは、ゲームコンソール上のｇＹ　ｍｏｄ　Ｎ、およびＸからコンピューティングされることに留意されたい。また、前述したのと同様に、別法として、セッション鍵ＫＣＡ自体を両方向でセキュアなパケットを認証し、かつ／または暗号化／解読するために使用できることにも留意されたい。
【００８２】
ゲームコンソール１０２は、セッション関連鍵を有すると、鍵交換が完了するのを待っていたあらゆるパケットを自由に伝送することができる。ただし、デバイスは、同一のセットの鍵を有していても、それを自由に行うことができない。というのは、自らの応答メッセージＲｅｓｐＭｅｓｓが失われていないと確信することができないからである。デバイスは、ゲームコンソール１０２からのコンピューティングされたセキュリティ関係鍵で認証されたパケットを受信するまで待つか、またはオプションとして、ゲームコンソール１０２から肯定応答パケット（ＡｃｋＰａｃｋ）を受信するまで待つ。
【００８３】
一般的なケースでは、ゲームコンソール１０２は、パケットをデバイスに送信し、したがって、鍵交換プロセスは、２つのパケットだけから、すなわち、ＩｎｉｔＰａｃｋｅｔおよびＲｅｓｐＰａｃｋｅｔだけから成る。あるいは、ゲームコンソール１０２が、送信するパケットを有さない場合、ゲームコンソール１０２は、擬似の肯定応答パケット（「ＡｃｋＰａｃｋ」として表される）を送信する。ＡｃｋＰａｃｋは、ケルベロスセッション鍵ＫＣＡではなく、コンピューティングされたセキュリティ関係鍵を使用してハッシングされることで、このパケットは、他の２つの鍵交換パケットと異なる。
【００８４】
以降、ゲームコンソール１０２およびデバイスは、セキュリティ関係鍵を使用して通信をセキュアにする。相手側に伝送される必要のあるすべてのネットワークパケットは、オプションとして、暗号化された後、認証され、受信側のデバイスが、認証データを検証してから、パケット内容を解読する。コンソール１０２とデバイスのどちらも、同じＮｏｎｃｅを含む相手側からの鍵交換パケットを無視することができる。
【００８５】
デバイスは、ゲームコンソール１０２に関するセキュリティ関係情報のレコード１７２を維持する（動作２０６）。このレコードは、ゲームコンソール１０２に送信されるデータパケットを暗号化する際、およびゲームコンソール１０２から受信されたデータパケットを解読する際に使用されるセキュリティ鍵（セキュリティ関係鍵、および／またはセッション鍵ＫＣＡ）、データセンタ１１０内のどのサービスデバイスにゲームコンソール１０２がアクセスすることが許可されているかを特定するサービスマッピング、完全に適格な（ｆｕｌｌｙ　ｑｕａｌｉｆｉｅｄ）ゲームコンソールアドレス（ＸＮＡＤＤＲとも呼ばれる）、およびセキュリティパラメータインデックス（ＳＰＩ）値を含む。
【００８６】
動作２０４の相互認証の一環として、ゲームコンソール１０２は、自らがデバイスに送信する鍵交換パケットの中に含める、ＳＰＩ１と呼ばれるＳＰＩ値を生成する。同様に、デバイスは、自らが、ゲームコンソール１０２に送信される鍵交換応答パケットの中に含める値ＳＰＩ２を生成する。ＳＰＩ１値により、ゲームコンソール１０２が、ゲームコンソール１０２とデバイスの間のセキュアな通信チャネルを、ゲートウェイデバイスによって送信されるデータパケットが対応する特定のチャネルとして特定することが可能になる。ゲートウェイデバイスからゲームコンソール１０２へのすべてのセキュアなチャネルのパケット（鍵交換後の）は、そのチャネルを特定するＳＰＩ１値を含む。同様に、ＳＰＩ２値により、デバイスが、ゲームコンソール１０２とデバイスの間のセキュアな通信チャネルを、セキュリティゲームコンソール１０２によって送信されるデータパケットが対応する特定のチャネルとして特定することが可能になる。ゲームコンソール１０２からゲートウェイデバイスへのすべてのセキュアなチャネルのパケット（鍵交換後の）は、そのチャネルを特定するＳＰＩ２値を含む。それぞれのセキュアな通信チャネルは、同一のゲームコンソール１０２とデバイスの間であっても、通常、２つの異なるＳＰＩ値（各方向で１つ）を有する。
【００８７】
一実施では、デバイスへのすべてのパケット、およびデバイスからのすべてのパケットが、常に、パケットの先頭にＳＰＩ値を含み、どのセキュリティチャネルにそのパケットが向けられているかを指定している（セキュリティゲートウェイデバイス１５０またはゲームコンソール１０２がこの値を使用して、パケットを解読する対応する鍵をルックアップすることができるように）。鍵交換イニシエータパケット、および鍵交換応答パケットの場合、この先頭のＳＰＩは、ゼロの値に設定されて、パケットが、対応するＳＰＩ番号がまだ確立されていない鍵交換パケットであることを示す。ただし、鍵交換パケット自体の内部には、鍵交換が完了した後に使用される新しい提案のＳＰＩ値（ゼロではない）が含まれる。したがって、鍵交換パケットは、実際には、２つのＳＰＩ値、つまり外部のＳＰＩ値（ゼロである）、および内部のＳＰＩ値（ゼロではない）を含む。
【００８８】
ゲームコンソール１０２に関する完全に適格なアドレスは、次のものを含む。すなわち、ゲームコンソール１０２に関するイーサネット（登録商標）ＭＡＣ（ｍｅｄｉａ　ａｃｃｅｓｓ　ｃｏｎｔｒｏｌ）アドレス、ゲームコンソール１０２のローカルＩＰアドレス（これは、ゲームコンソール１０２が自ら有すると信じるＩＰアドレスであり、デバイスがデータパケットをゲームコンソール１０２から受信する送信元のＩＰアドレスとは異なる可能性がある（例えば、ゲームコンソール１０２とデバイスの間に位置する、ルータなどのＮＡＴデバイスに起因して））、デバイスがデータパケットをゲームコンソール１０２から受信する送信元のＩＰアドレスおよびポート（これは、ゲームコンソール１０２のローカルＩＰアドレスと同じであることが可能であり、あるいは異なることが可能である（例えば、ＮＡＴデバイスのアドレス））、論理上のセキュリティゲートウェイデバイス番号（セキュリティゲートウェイクラスタの中のセキュリティゲートウェイデバイスを一意的に識別するようにセキュリティゲートウェイデバイスに割り当てられた識別子）、ＳＰＩ値（例えば、ＳＰＩ１および／またはＳＰＩ２）、およびゲームコンソールｉｄ（前述したゲームコンソール識別Ｃ）である。完全に適格なアドレスの内容は、ゲームコンソール１０２から受け取られたセキュリティチケットに基づき、またゲームコンソール１０２から受信されたデータパケットに組み込まれた情報に基づいて判定することができる。
【００８９】
デバイスが、セキュリティゲートウェイデバイス（図５に関連して以下に述べる）である一実施形態では、動作２０４における認証の一環として、固有データセンタ可視ＩＰアドレス（データセンタによって内部で使用されるアドレス））が、セキュリティゲートウェイデバイスに利用可能なアドレスのプールから、ゲームコンソールに割り当てられる。固有データセンタ可視ＩＰアドレスは、公共／専用ネットワーク境界を越えてパケットを転送する際、セキュリティゲートウェイデバイスによって使用される。パケットが、ゲームコンソールから受信されて、データセンタ内部で（専用ネットワークを介して）転送され、送信元ＩＰアドレスが、上記のデータセンタ可視ＩＰアドレスとしてリストされる。データセンタ内のサーバがこのトラフィックに応答する際、応答は、その応答の目標ＩＰアドレスを含むアドレス範囲が割り当てられたセキュリティゲートウェイデバイスに戻るようにルーティングされる。セキュリティゲートウェイデバイスは、目標ＩＰアドレスが割り当てられたゲームコンソールに関するセキュリティ関係をルックアップすることによってＮＡＴプロセスを逆転し、応答が指定されたゲームコンソールに戻るように転送し、応答の送信元アドレスは、セキュリティゲートウェイのインターネットアドレスであるように変更される。
【００９０】
デバイスは、ゲームコンソールがもはや使用不可能になるまで（ゲームコンソール１０２が、データセンタ１１０から自発的にログアウトしたか、または別の形で応答不可になったかに関わらず）、ゲームコンソール１０２に関するセキュリティ関係情報を維持し、使用不可能になった時点で、デバイスは、ゲームコンソール１０２に関するセキュリティ関係情報を削除する（動作２０８）。デバイスは、以下により詳細に述べるとおり、ゲームコンソール１０２と通信する際に、この維持されたセキュリティ関係情報を使用する。したがって、セッションセキュリティ鍵および／またはセキュリティ関係鍵を含むセキュリティ関係情報は、各セッションの間にだけ維持される。すなわち、ゲームコンソール１０２がデバイスにログインするたびに毎回、新しいセキュリティ関係が生成される。
【００９１】
図３のプロセス２００は、ゲームコンソールとセキュリティゲートウェイデバイスの間で相互に認証されたセキュアな通信チャネルを確立する、ケルベロスチケットなどのセキュリティチケットの使用について述べている。あるいは、他のプロセスを使用してセキュアな通信チャネルを確立することができる。セキュアな通信チャネルの目的は、特定のゲームコンソール、および特定のデバイスが、チャネル内で通信されているデータを他のデバイスが解釈する、または変更するのを防止する仕方で互いに通信することを可能にすることである。
【００９２】
図４は、図１の例示的なデータベースをさらに詳細に示すブロック図である。データベース１１４は、提供（ｏｆｆｅｒｓ）テーブル２４０、タイトル＿提供（ｔｉｔｌｅ＿ｏｆｆｅｒｓ）テーブル２４２、提供＿場所（ｏｆｆｅｒ＿ｌｏｃａｔｉｏｎｓ）テーブル２４４、加入（ｓｕｂｓｃｒｉｐｔｉｏｎｓ）テーブル２４６、国（ｃｏｕｎｔｒｉｅｓ）テーブル２４８、および提供＿地域（ｏｆｆｅｒ＿ｒｅｇｉｏｎｓ）テーブル２５０を含む。以上の様々なテーブル２４０〜２５０を使用して、図１の照会ソース１０４によって保持される様々な情報を記憶する。代替の実施形態では、データベース１１４は、さらなる情報を記憶することができるが、そのようなさらなる情報は、図面が分かりにくくなるのを避けるために示していない。
【００９３】
テーブル２４０〜２５０は、提供＿ｉｄを参照する。提供＿ｉｄにより、本明細書でコンテンツパッケージとも呼ぶ特定のコンテンツが識別される。コンテンツパッケージは、単にコンテンツ自体であること、あるいはコンテンツの暗号化されたダイジェストを含むことが可能である。一実施形態では、提供＿ｉｄは、上位の３２ビットが、コンテンツを供与することを最初に担うゲームタイトル（例えば、コンテンツの設計が最初に、または主に向けられたゲームタイトル）の識別子である６４ビットの値である。この３２ビットのゲームタイトル識別子は、世界中でそのゲームを一意的に特定する。提供＿ｉｄの下位の３２ビットのうち、２７ビットがゲームタイトルに供与される。すなわち、ゲーム開発者は、その２７ビットを使用して、自らが所望するあらゆる仕方でコンテンツを識別することができる。提供＿ｉｄの下位３２ビットの残りの５ビットは、システム使用のために取っておかれる。一実施形態では、５ビットのうち１ビットは、コンテンツが無料であるか、または代金が支払われるべきかを示すのに使用される。コンテンツが無料である場合、要求側がコンテンツにアクセスすることができるかどうかの検証（例えば、図２の動作１４８）は、要求側が適切な料金を支払ったかどうかについての検査を含む必要がない。別法では、提供＿ｉｄの下位３２ビットのすべてが、ゲーム開発者が所望に応じて使用するように、ゲームタイトルに供与される（オプションとして、コンテンツが無料であるか、または代金が支払われるべきかを示す１ビットを含め）ことが可能である。
【００９４】
提供テーブル２４０は、照会ソース１０４が管理する各コンテンツを記述する情報を含む。照会ソース１０４によって管理される各コンテンツに関して、提供テーブル２４０の中で個別のエントリが存在する。タイトル＿提供テーブル２４２は、どのゲームタイトルが特定のコンテンツにアクセスすることが許されているかを記述する情報を含む。ソース１０４によって管理される各コンテンツ、およびそのコンテンツにアクセスすることが許されている各ゲームタイトルに関して、タイトル＿提供テーブル２４２の中で個別のエントリが存在する。提供＿場所テーブル２４４は、特定のコンテンツの異なるソース、およびその異なるソースのランキングを記述する情報を含む。ソース１０４によって管理される各コンテンツに関して、提供＿場所テーブル２４４の中で個別のエントリが存在する。加入テーブル２４６は、異なる要求側、およびどのコンテンツにその要求側がアクセスする資格があるか（例えば、そのコンテンツにアクセスする権利の代金を支払ったことにより）を記述する情報を含む。ソース１０４によって管理される各コンテンツに関し、そのコンテンツにアクセスする資格のある各要求側に関する個別のエントリが、加入テーブル２４６の中に存在する。
【００９５】
国テーブル２４８は、国コードを含み、また提供＿地域テーブル２５０は、特定のコンテンツを特定の国に国コードでマップする情報を含む。コンテンツへのアクセスの起点となることが照会ソース１０４によって許される各国に関して、個別のエントリが、国テーブル２４８の中に存在する。ソース１０４によって管理される各コンテンツに関して、またコンテンツごとに、そのコンテンツにアクセスすることが国内で許される各国に関して、個別のエントリが、提供＿地域テーブル２５０の中で存在する。本明細書では、国ごとで述べているが、地域は、任意の地理的境界（例えば、複数の国のグループ、１つまたは複数の国、州、県の部分等）であることが可能である。以上の様々なテーブル２４０〜２５０の中に保持される情報を以下のテーブルに示している。
【００９６】
【表１】
2004056793.tif 000007
【００９７】
【表２】
2004056793.tif 000008
【００９８】
【表３】
2004056793.tif 000009
【００９９】
【表４】
2004056793.tif 000010
【０１００】
【表５】
2004056793.tif 000011
【０１０１】
【表６】
2004056793.tif 000012
【０１０２】
テーブル２４０〜２５０を使用して、図１の検証モジュール１１０は、特定の要求側が要求のコンテンツにアクセスすることが許されているかどうかを検証することができる。検証モジュール１１０は、加入テーブル２４６を検査して、要求側が要求のコンテンツに関する有効な加入契約を有することを検証する（あるいは、要求のコンテンツが無料である場合、加入テーブル２４６を検査しなくてもよい）。加入テーブル２４６の中で、要求側の識別子（例えば、ｐｕｉｄ）の要求のコンテンツ（例えば、提供＿ｉｄ）へのマッピングが存在しない場合、その要求側は、そのコンテンツを取得することが許されていない。さらに、加入テーブル２４６の中でそのようなマッピングが存在する場合、検証モジュール１１０は、要求側の加入契約が現在、有効であることを確かめる検査も行う（例えば、現在の日付／時刻が、エントリの中の開始日前でなく、かつエントリの中の終了日後でなく、かつ加入ステータスは、その要求側の加入契約がアクセスを許さないことを示していない（例えば、ユーザの加入契約がキャンセルされていないこと、使用の条項の違反が行われていないこと等））。
【０１０３】
前述したとおり、要求側は、マシン（ゲームコンソール）および／またはユーザであることが可能である。したがって、検証モジュール１１０は、マシン別に、ユーザ別に、またはマシン別とユーザ別の組合せでコンテンツに対するアクセスを制限することができる。検証モジュール１１０がどのようにコンテンツへのアクセスを制限するかは、検証モジュール１１０にプログラミングすることが可能であり、また別法では、コンテンツごとに（ｐｅｒ−ｐｉｅｃｅ　ｂａｓｉｓ）どのように検証モジュール１１０がアクセスを制限するかを特定する追加のエントリを提供テーブル２４０（あるいは作成される新しいテーブル）の中に含めることができる。単一の識別子（例えば、マシン識別子、または単一のユーザ識別子）だけが加入テーブル２４６の中にあればよい状況では、その単一の識別子が探索される。あるいは、複数の識別子（例えば、ゲームコンソールの複数のユーザ、つまりゲームコンソールの識別子、および１名または複数名のユーザ識別子）が存在する場合、その識別子のそれぞれが、加入テーブル２４６の中にある必要があり、また別法では、すべての識別子が存在しなくてもよい（例えば、識別子の多数、少なくとも１つの識別子等）。したがって、４名のユーザが、特定のゲームコンソールを使用しており、コンテンツを要求した場合、検証モジュール１１０は、４名すべてのユーザのユーザ識別子、およびゲームコンソール識別子が加入テーブル２４６の中にある場合にだけコンテンツに対するアクセスを許すこと、あるいはゲームコンソール識別子が加入テーブル２４６の中にある限り、コンテンツに対するアクセスを許すこと、あるいはユーザ識別子の少なくとも１つが加入テーブル２４６の中にある限り、コンテンツに対するアクセスを許すこと等が可能である。
【０１０４】
また、検証モジュール１１０は、提供＿地域テーブル２５０を検査して、要求側がそのコンテンツにアクセスすることが許されている国に関連していることも検証する。異なる国は、しばしば、ゲームコンテンツに関して異なる法律を有する（例えば、ある語またはある記号が、ある国において禁止されている可能性があり、ある国では、血を赤くすることが禁止されている可能性がある等）。したがって、コンテンツにアクセスすることが許されている（例えば、ゲーム開発者が、コンテンツを供与することを所望し、そのコンテンツが法律に違反しないと確信する）各国（またはその他の地理的区域）が、提供＿地域テーブル２５０の中でそのコンテンツにマップされる。提供＿地域テーブル２５０の中で、要求側が関連している国の要求のコンテンツへのマッピングが存在しない場合、その要求側は、そのコンテンツを取得することが許されていない。
【０１０５】
要求側は、様々な形で特定の国、または特定の地理的地域に関連付けられることが可能である。一実施形態では、追加のフィールドが加入テーブル２４６の中に含められ、あるいは要求側が関連している国（例えば、要求側が自らの所在を主張する国（例えば、使用上の合意の条項の一部として合意された）、および／またはコンテンツ加入契約に関する料金請求先アドレスが所在する国）を特定する追加のテーブルが使用される。
【０１０６】
また、検証モジュール１１０は、タイトル＿提供テーブル２４２の検査を行って、コンテンツを要求しているゲームタイトル（要求側がコンテンツを要求する際にゲームコンソール上で実行されているゲームタイトル）がコンテンツにアクセスすることが許されていることも検証する。コンテンツを要求しているゲームタイトルの識別子（例えば、タイトル＿ｉｄ）のコンテンツ識別子（例えば、提供＿ｉｄ）へのマッピングが存在しない場合、要求側は、そのコンテンツを取得することが許可されていない。
【０１０７】
別法では、どの要求側がコンテンツにアクセスすることが許されるかにさらなる制限を課すことを可能にする追加の情報が、データベース１１４の中で保持される。例えば、提供＿加入＿レベルテーブルを含めて、加入アクセスの異なるレベル（例えば、より多くを支払うものがより多くのコンテンツへのアクセスを有する）、ユーザベースのチーム（例えば、特定のコンテンツへのアクセスが許されたユーザのグループ）、アプリケーションのバージョン（例えば、最新バージョンの特定のアプリケーションだけが、特定のコンテンツにアクセスすることが許される）などの様々なクラスの要求側に基づいてコンテンツに対するアクセスを制限することができる。
【０１０８】
テーブル２４０〜２５０には、様々なやり方のうちの任意のやり方でデータを埋めることができる。通常、新しいコンテンツが供与されるたびに毎回、どの要求側がそのコンテンツにアクセスすることが許されるかを記述する適切なエントリが、適切なテーブル２４０〜２５０に追加される。さらに、テーブルに以前に追加されたコンテンツに関連してテーブル２４０〜２５０に変更を行うことができる。例えば、新しい加入契約が、異なる潜在的な要求側によって購入され、加入テーブル２４６の中に新しい（かつ／または変更された）エントリをもたらし、誰がコンテンツにアクセスを有するかが変化する可能性がある。
【０１０９】
別の例として、コンテンツを暗号化するのに使用された対称鍵が、漏洩している（または漏洩したと考えられる）状況が生じる可能性がある。そのような状況では、新しい対称鍵を容易に生成することができ、その新しい対称鍵を使用してコンテンツを暗号化し、その新たに暗号化されたコンテンツを適切なソースに記憶することができる。また、そのコンテンツに関する提供テーブル２４０内のエントリも、その新しい対称鍵を含むように更新される。したがって、以降のあらゆる要求側は、その新しい対称鍵を受け取り、新たに暗号化されたコンテンツを解読することができ、これにより、前の鍵が漏洩したことに対処が行われる。
【０１１０】
さらに別の例として、コンテンツのソースが変わる状況が生じる可能性がある。これは、あるソースが信頼できないこと、および／または障害を生じていること、コンテンツを記憶するのに様々なソースによって課される料金、ソースの地理的場所などの様々な異なる理由によることが可能である。提供＿場所テーブル２４４において適切なエントリを追加すること、削除すること、かつ／または変更することにより、そのようなあらゆる変更に容易に対処することができる。
【０１１１】
ゲームコンソール１０２は、自らが要求する特定のコンテンツの提供＿ｉｄを様々な異なるやり方のうちの任意のやり方で獲得することができる。一実施形態では、ゲームコンソール１０２は、あるパラメータを満足させる１組の提供＿ｉｄ（例えば、特定のタイトル＿ｉｄに（例えば、タイトル＿提供テーブルの中の対応するエントリに基づいて）関連する提供＿ｉｄ、提供＿ｉｄの下位３２ビットが特定の範囲内（例えば、新しい走路、新しい武器、新しいキャラクタなどの何か特定のものを意味するものとしてゲーム開発者に定義された）にある提供＿ｉｄ）を求めて照会ソース１０４にクエリを行うことができる。別の実施形態では、ゲームコンソール１０２に、オンラインゲームソースから提供＿ｉｄが与えられ、ゲームコンソールが、特定のオンラインゲームを行うのに適切なコンテンツ（例えば、ロールプレーイングゲームが行われている特定の世界の新しいバージョン）を獲得できるようになることが可能である。さらに別の実施形態では、ゲームコンソール１０２に、ゲームコンソールに挿入される取外し可能なディスク（例えば、雑誌とともに配布されるディスク）、ユーザによって手作業で入力される（例えば、インターネットや雑誌の記事等からユーザによって獲得され）などの別のソースから提供＿ｉｄが与えられることが可能である。
【０１１２】
一実施形態では、ゲームタイトルが、コンテンツを取得してインストールすることを可能にする複数のアプリケーションプログラミングインターフェース（ＡＰＩ）が、ゲームコンソール上で実行されるゲームタイトルに公開される。１組の例示的なＡＰＩを以下に説明し、これには、次のものが含まれる。
・ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌ
・ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌＧｅｔＰｒｏｇｒｅｓｓ
・ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅ
・ＸＬｏａｄＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅｓ
・ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＮａｍｅ
・ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＩｎｄｅｘ
・ＸＣａｌｃｕｌａｔｅＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅ
【０１１３】
ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌ
指定されたコンテンツのダウンロードおよびインストールを開始する。このファンクションは、ダウンロードおよびインストールを行う非同期タスクを生成する。
2004056793.tif 000013
【０１１４】
パラメータ：
ＯｆｆｅｒｉｎｇＩｄ
［入力］コンテンツに関連する固有識別子。
ｈＷｏｒｋＥｖｅｎｔ
［入力、オプション］インストールタスクに関して作業を行う必要があるとき通知されるイベントに対するハンドル。このパラメータは、そのようなイベントが必要ない場合、ＮＵＬＬであることが可能である。
ｐｈＴａｓｋ
［出力］インストール要求を表すタスクハンドルを受け取るＸＯＮＬＩＮＥＴＡＳＫ＿ＨＡＮＤＬＥタイプの変数に対するポインタ。このハンドルをＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅの呼出しで使用してそのタスクに関連する作業を行うことができる。
【０１１５】
戻り値：
ファンクションが成功した場合、戻り値は、Ｓ＿ＯＫである。
【０１１６】
注釈：
ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌは、コンテンツをダウンロードし、インストールし、確認するのに必要なすべてのステップを行う。ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌは、ＯｆｆｅｒｉｎｇＩｄで指定されたコンテンツのダウンロードおよびインストールを開始する。このファンクションは、非同期タスクを生成し、ｐｈＴａｓｋパラメータでそのタスクに対するハンドルを返す。この非同期タスクに関して作業を行うため（または最終的にタスクを完了するため）、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅは、ＸＯＮＬＩＮＥＴＡＳＫ＿Ｓ＿ＲＵＮＮＩＮＧ以外の値を返すまで、タスクハンドルを使用して繰り返し呼び出すことができる。ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅは、ＸＯＮＬＩＮＥＴＡＳＫ＿Ｓ＿ＳＵＣＣＥＳＳを戻してタスクが成功裏に完了したことを示すか、または誤り戻り値を戻してコンテンツインストールが失敗したことを示す。
【０１１７】
ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌＧｅｔＰｒｏｇｒｅｓｓ
ＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌで開始された提供ダウンロード（ｏｆｆｅｒｉｎｇ　ｄｏｗｎｌｏａｄ）の現在の進行を取り出す。
2004056793.tif 000014
【０１１８】
パラメータ：
ｈＴａｓｋ
［入力］コンテンツのダウンロードおよびインストールを開始するＸＯｎｌｉｎｅＣｏｎｔｅｎｔＩｎｓｔａｌｌの呼出しによって戻されるオンラインタスクハンドル。
ｐｄｗＰｅｒｃｅｎｔＤｏｎｅ
［出力、オプション］０から１００までのダウンロードの完了パーセンテージを受け取る変数に対するポインタ。このパラメータは、その情報が必要ない場合、ＮＵＬＬであることが可能である。
ｐｑｗＮｕｍｅｒａｔｏｒ
［出力、オプション］これまでにダウンロードされたバイトの総数を示すＵＬＯＮＧＬＯＮＧを受け取る変数に対するポインタ。このパラメータは、その情報が必要ない場合、ＮＵＬＬであることが可能である。
ｐｑｗＤｅｎｏｍｉｎａｔｏｒ
［出力、オプション］ダウンロードされる提供物のバイト単位での合計サイズを示すＵＬＯＮＧＬＯＮＧを受け取る変数に対するポインタ。このパラメータは、その情報が必要ない場合、ＮＵＬＬであることが可能である。
【０１１９】
戻り値：
ファンクションが成功した場合、戻り値は、Ｓ＿ＯＫである。
【０１２０】
注釈：
このファンクションは、ダウンロードおよびインストールに関して実際の作業は全く行わず、単にそのダウンロードの進行を示す。
【０１２１】
ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅ
ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅファンクションは、待ち状態の非同期タスクに関して単一のタイムスライスの作業を行う。
2004056793.tif 000015
【０１２２】
パラメータ：
ｈＴａｓｋ
［入力］作業が行われるタスクのタスクハンドル。このハンドルは、非同期タスクを生成したファンクションの以前の呼出しによって戻されていなければならない。
【０１２３】
戻り値：
このファンクションは、タスクが完了したとき、または誤りが生じたとき、タスクのステータスを示す汎用コードか、またはタスク特有の結果コードを返す。汎用結果コードは、以下のとおりである。
2004056793.tif 000016
【０１２４】
完了したタスク、または誤りに遭遇したタスクに関して、タスク特有の戻りコードが存在することが可能である。さらなる情報については、注釈を参照されたい。
【０１２５】
注釈：
いくつかのオンラインファンクションが、作業をブロッキングして同期に行うのではなく、非同期タスクを生成して作業を行う。これらのファンクションは、タスクハンドルを戻し、次に、タスクハンドルは、タイトルがいくつかの予備のサイクルを有し、いくらかのオンライン作業を行うことを望むとき（例えば、タイトルが、次のフリップ（ｆｌｉｐ）を待っているとき、またはタイトルが、グラフィックスプッシュバッファが消去されるのを待って停止している間）、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅに送られる。さらに、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅに複数回の呼出しを行うことにより、タイトルは、ネットワーク活動のバーストをいくつかのビデオフレームにわたって拡散させて、フレームレートを安定させるのを助けることができる。また、複数の待ち状態の非同期タスクが、各タスクに関して順にＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅを呼び出す単一のセクションのコードによって処理されることが可能である。
【０１２６】
タスクに必要な作業が完了したとき、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅは、ＸＯＮＬＩＮＥＴＡＳＫ＿Ｓ＿ＳＵＣＣＥＳＳを戻し、タスクが終了したこと、およびそのタスクに関してＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅのさらなる呼出しは行われるべきでないことが示される。関与する特定のオンラインタスクに依存して、その時点で追加のタスク特有のファンクションを呼び出して、タスクの結果を取得することが可能である。
【０１２７】
いくつかのタスクに関して、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅは、ＸＯＮＬＩＮＥＴＡＳＫ＿Ｓ＿ＲＥＳＵＬＴＳ＿ＡＶＡＩＬを戻して、タスクは完了していないが、部分的結果の用意ができていることを示す。この時点で、タスク特有のファンクションが呼び出されて結果が取得される。次に、タイトルは、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅのさらなる呼出しを使用してタスクを処理することを続ける。
【０１２８】
タスクがまだ実行されている場合、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅは、ＸＯＮＬＩＮＥＴＡＳＫ＿Ｓ＿ＲＵＮＮＩＮＧを返す。この場合、時間が許すので、タイトルは、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅの呼出しを続けてタスクを処理することを続けなければならない。
【０１２９】
いくつかのタスクは、その他の戻りコードを提供して成功、または進行状態を示す。
【０１３０】
タスクが処理されている最中に誤りが生じた場合、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅがそのタスクに関して作業を行うようにタイトルによって呼び出されたとき、その誤りが、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅによって戻される。特定のエラーコードはタスクごとに異なることがある。
【０１３１】
意図的に、いくつかのタスクは、完了まで実行されることが決してなく、代わりに、定期的に呼び出されて更新または他の処理を行う。通常、ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅは、それらのタスクに関して毎フレーム１回、呼び出されなければならず、ＸＯＮＬＩＮＥＴＡＳＫ＿Ｓ＿ＲＵＮＮＩＮＧを戻しつづける。
【０１３２】
ＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅの各呼出しに関して行われる厳密な時間と作業の量は、タスクごとに異なる。時間の割振りは、過度の遅延を生じさせることなしにタスクを進展させるのに十分であるように図られる。
【０１３３】
周期的にＸＯｎｌｉｎｅＴａｓｋＣｏｎｔｉｎｕｅを呼び出すことを、しばしば、タスクをポンピング（ｐｕｍｐｉｎｇ）すると言い、また非同期タスクアーキテクチャをオンラインタスクポンプと呼ぶ。
【０１３４】
ＸＬｏａｄＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅｓ
指定されたコンテンツに関する署名をロードし、署名データに対するハンドルを返す。
2004056793.tif 000017
【０１３５】
パラメータ：
ＴｉｔｌｅＩＤ
［入力］コンテンツをインストールしたタイトルのタイトル識別子を指定する。ＴｉｔｌｅＩＤがゼロである場合、呼出し側タイトルのタイトル識別子を使用する。
ＤｉｒｅｃｔｏｒｙＮａｍｅ
［入力］コンテンツのインストールディレクトリを指定する。
【０１３６】
戻り値：
このファンクションが成功した場合、戻り値は、指定されたコンテンツに関する署名データに対するハンドルである。ファンクションが失敗した場合、戻り値は、ＮＵＬＬである。
【０１３７】
注釈：
ＸＬｏａｄＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅｓは、指定されたコンテンツに属するコンテンツ署名（例えば、前述したダイジェスト）をロードし、署名データの完全性を検証し、その署名データに対するハンドルを返す。このハンドルは、ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＩｎｄｅｘおよびＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＮａｍｅの後の呼出しで使用してコンテンツ署名を取得し、次に、その署名を、コンテンツデータに関してコンピューティングされた署名と比較することができる。
【０１３８】
ＸＣａｌｃｕｌａｔｅＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅｓを使用してコンテンツデータを対象に署名をコンピューティングして、戻された署名と比較する。別法では、署名は、タイトル特有の仕方で生成され、タイトルは、独自のアルゴリズムを使用してコンテンツを対象に署名をコンピューティングして、戻された署名と比較する。
【０１３９】
ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＮａｍｅ
ファイル、またはファイル内のデータのブロックに関して、指定された署名データからコンテンツ署名を取得する。
2004056793.tif 000018
【０１４０】
パラメータ：
ＳｉｇｎａｔｕｒｅＨａｎｄｌｅ
［入力］ＸＬｏａｄＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅｓを使用して開かれる署名データに対するハンドル。
ＦｉｌｅＮａｍｅ
［入力］署名が取得されるべき対象のデータブロックを含むファイルを指定する空白（ｎｕｌｌ）で終了するストリングに対するポインタ。
ＦｉｌｅＯｆｆｓｅｔ
［入力］データブロックのオフセットをバイト数でファイルの中で指定する。
ＤａｔａＳｉｚｅ
「入力」データブロックのサイズをバイト数で指定する。
ＳｉｇｎａｔｕｒｅＤａｔａ
「出力」指定された署名のアドレスを受け取るＬＰＢＹＴＥ変数に対するポインタ。
ＳｉｇｎａｔｕｒｅＳｉｚｅ
［出力］ＳｉｇｎａｔｕｒｅＤａｔａによって指し示された署名のサイズをバイト数で受け取るＤＷＯＲＤ変数に対するポインタ。
【０１４１】
戻り値：
このファンクションが成功した場合、戻り値は、真である。ファンクションが失敗した場合、戻り値は、偽である。
【０１４２】
注釈：
ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＮａｍｅが、指定されたブロックのデータに関する署名を取得する。所与のコンテキストファイルは、単一の署名（そのファイル全体を表す）を有することが可能であり、またはファイルがより小さいデータブロックに分割されて、各データブロックを対象に署名が別々にコンピューティングされることが可能である。複数の署名により、例えば、大きいリソースファイルからより小さいコンテンツをロードし、ロードされたデータの部分だけを対象に署名をコンピューティングし、署名を比較することが可能になる。
【０１４３】
ファイル全体に関して署名を取得するため、ＦｉｌｅＯｆｆｓｅｔおよびＤａｔａＳｉｚｅとしてゼロが指定される。ファイル内で特定のデータブロックに関する署名を取得するため、データブロックの最初のオフセットおよびサイズが指定される。指定されたデータ範囲にマッチする署名が、署名データの中で探索され、見出された場合、戻される。いずれの場合も、データブロックに関する署名は、署名データが最初に生成された際に指定され、コンピューティングされていることに留意されたい。
【０１４４】
ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＩｎｄｅｘ
指定された署名データから索引によりコンテンツ署名を取得する
2004056793.tif 000019
【０１４５】
パラメータ
ＳｉｇｎａｔｕｒｅＨａｎｄｌｅ
［入力］ＸＬｏａｄＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅｓで開かれる署名データに対するハンドル。
ＳｉｇｎａｔｕｒｅＩｎｄｅｘ
［入力］取得すべき署名の索引を指定する。
ＳｉｇｎａｔｕｒｅＤａｔａ
［出力］指定された署名のアドレスを受け取るＬＰＢＹＴＥ変数に対するポインタ。
ＳｉｇｎａｔｕｒｅＳｉｚｅ
［出力］ＳｉｇｎａｔｕｒｅＤａｔａで指し示される署名のサイズをバイト数で受け取るＤＷＯＲＤ変数に対するポインタ。
【０１４６】
戻り値：
このファンクションが成功した場合、戻り値は、真である。ファンクションが失敗した場合、戻り値は、偽である。
【０１４７】
注釈：
ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＩｎｄｅｘは、指定の開かれた署名データから指定された索引において署名を取得する。
【０１４８】
ＸＣａｌｃｕｌａｔｅＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅ
指定されたデータを対象に署名をコンピューティングし、受け取られたコンテンツ署名とマッチングを行う。
2004056793.tif 000020
【０１４９】
パラメータ：
Ｄａｔａ
［入力］署名のコンピューティングが行われた対象のデータを含むバッファに対するポインタ。
ＤａｔａＳｉｚｅ
［入力］Ｄａｔａバッファのサイズをバイト数で指定する。
Ｓｉｇｎａｔｕｒｅ
［出力］コンピューティングされた署名を受け取るバッファに対するポインタ。
ＳｉｇｎａｔｕｒｅＳｉｚｅ
［入力、出力］Ｓｉｇｎａｔｕｒｅで指し示されるバッファのサイズをバイト数で指定するＤＷＯＲＤ変数に対するポインタ。戻りで、ＳｉｇｎａｔｕｒｅＳｉｚｅは、Ｓｉｇｎａｔｕｒｅバッファに書き込まれる実際のバイト数を受け取る。
【０１５０】
戻り値：
このファンクションが成功した場合、戻り値は、真である。ファンクションが失敗した場合、戻り値は、偽である。
【０１５１】
注釈：
ＸＣａｌｃｕｌａｔｅＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅは、コンテンツとともに記憶される署名を生成するのに使用されるのと同じアルゴリズムを使用して、指定されたコンテンツを対象に署名（例えば、前述したダイジェスト）をコンピューティングする。インストールされたコンテンツデータを検証するため、ＸＣａｌｃｕｌａｔｅＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅを使用してそのデータを対象に署名をコンピューティングし、ＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＮａｍｅファンクションまたはＸＬｏｃａｔｅＳｉｇｎａｔｕｒｅＢｙＩｎｄｅｘファンクションによって戻された同じデータに関する署名と比較することができる。
【０１５２】
別法では、ＸＣａｌｃｕｌａｔｅＣｏｎｔｅｎｔＳｉｇｎａｔｕｒｅを呼び出すのではなく、ゲームタイトルは、自らがコンテンツ署名を生成するのに最初に使用したタイトル特有のアルゴリズムを、どのようなものであれ使用することができる。
【０１５３】
署名を保持するのに必要なバッファサイズを判定するため（署名コンピューティングを実際に行うことなしに）、ＳｉｇｎａｔｕｒｅＳｉｚｅとしてゼロを指定する。必要とされるサイズが、ＳｉｇｎａｔｕｒｅＳｉｚｅで戻される。
【０１５４】
図５は、例示的なオンラインゲーム環境３００を示すブロック図である。複数のゲームコンソール３０２−１、３０２−２、．．．３０２−ｎが、ネットワーク３０６を介してセキュリティゲートウェイ３０４に結合されている。ネットワーク３０６は、様々な従来のデータ通信網の任意の１つまたは複数を表す。ネットワーク３０６は、通常、パケット交換網を含むが、回線交換網も含むことが可能である。ネットワーク３０６は、有線部分および／または無線部分を含むことが可能である。１つの例示的な実施では、ネットワーク３０６は、インターネットを含むが、オプションとして、１つまたは複数のローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）を含むことが可能である。ネットワーク３０６の少なくとも一部分は、公衆ネットワークであり、これは、ネットワークが公共アクセス可能であることを指す。実質的に、誰でも公衆ネットワークにアクセスできる。
【０１５５】
一部の状況では、ネットワーク３０６は、ゲームコンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４の間にルーティングデバイスが位置しているＬＡＮ（例えば、ホームネットワーク）を含む。このルーティングデバイスは、ネットワークアドレス変換（ＮＡＴ）を行うことができ、ＬＡＮ上の複数のデバイスが、インターネット上で同一のＩＰアドレスを共有することを可能にし、また悪意のあるユーザ、または性悪な（ｍｉｓｃｈｉｅｖｏｕｓ）ユーザによるインターネットを介してのアクセスに対してＬＡＮ上のデバイスを保護するファイアウォールとして動作する。
【０１５６】
セキュリティゲートウェイ３０４は、公衆ネットワーク３０６と専用ネットワーク３０８の間のゲートウェイとして動作する。専用ネットワーク３０８は、ローカルエリアネットワークなどの多種多様な従来のネットワークの任意のものであることが可能である。専用ネットワーク３０８、ならびに以下にさらに詳述する他のデバイスは、セキュアゾーンとして動作するデータセンタ３１０の内部にある。データセンタ３１０は、信頼される通信を介して通信する信頼されるデバイスから構成される。したがって、セキュアゾーン３１０内における暗号化および認証は必要ない。ネットワーク３０８の専用性が指しているのは、ネットワーク３０８の限定されたアクセス可能性、すなわち、ネットワーク３０８に対するアクセスが、ある個人だけに限定されている（例えば、データセンタ３１０の所有者または運用者によって制限されている）ことである。
【０１５７】
セキュリティゲートウェイ３０４は、１つまたは複数のセキュリティゲートウェイコンピューティングデバイスのクラスタである。このセキュリティゲートウェイコンピューティングデバイスは、集合としてセキュリティゲートウェイ３０４を実現する。セキュリティゲートウェイ３０４は、オプションとして、セキュリティゲートウェイコンピューティングデバイスによって扱われるべき要求が、そのコンピューティングデバイスの適切なものに向けられるように動作する１つまたは複数の従来のロードバランシングデバイス（ｌｏａｄ　ｂａｌａｎｃｉｎｇ　ｄｅｖｉｃｅ）を含むことが可能である。この誘導、つまりロードバランシングは、様々なセキュリティゲートウェイコンピューティングデバイスにかかる負荷をほぼ平等に平衡させようと試みる形で（あるいは、何らかの他の基準に従って）行われる。
【０１５８】
またデータセンタ３１０内に、次のものが存在する。すなわち、１つまたは複数の監視サーバ３１２、１つまたは複数の存在−通知フロントドア（ｐｒｅｓｅｎｃｅ　ａｎｄ　ｎｏｔｉｆｉｃａｔｉｏｎ　ｆｒｏｎｔ　ｄｏｏｒｓ）３１４と、１つまたは複数の存在サーバ３１６と、１つまたは複数の通知サーバ３１８（集合として、存在−通知サービスを実施する）、１つまたは複数のマッチフロントドア３２０と、１つまたは複数のマッチサーバ３２２（集合として、マッチサービスを実施する）、１つまたは複数の統計フロントドア３２４と、１つまたは複数の統計サーバ３２６（集合として、統計サービスを実施する）、ならびに１つまたは複数の照会フロントドア３３０と、サーバ１０４である。サーバ３１６、３１８、３２２、および３２６は、ゲームコンソール３０２−１〜３０２−ｎにサービスを提供し、したがって、サービスデバイスと呼ぶことができる。サーバ３１６、３１８、３２２、および３２６に加えて、かつ／またはその代わりに、他のサービスデバイスも含まれることが可能である。さらに、図５では、１つのデータセンタだけを示しているが、別法では、ゲームコンソール３０２−１〜３０２−ｎが通信することができる複数のデータセンタが存在してもよい。これらのデータセンタ群は、独立に動作することが可能であり、あるいは、集合として（例えば、１つの大型のデータセンタをゲームコンソール３０２−１〜３０２−ｎに供与するように）動作することが可能である。
【０１５９】
ゲームコンソール３０２−１〜３０２−ｎは、データセンタ３１０からリモートに位置し、ネットワーク３０６を介してデータセンタ３１０にアクセスする。データセンタ内の１つまたは複数のデバイスと通信することを望むゲームコンソール３０２−１〜３０２−ｎは、コンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４の間でセキュアな通信を確立する。ゲームコンソール３０２−１〜３０２−ｎおよびセキュリティゲートウェイ３０４は、やり取りされるデータパケットの暗号化および認証を行い、これにより、暗号化を破ることなしにデータパケットをキャプチャすること、またはコピーすることができる何らかの他のデバイスによって理解されることなく、ゲームコンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４の間でデータパケットがセキュアに伝送されることが可能になる。ゲームコンソール３０２−１〜３０２−ｎからセキュリティゲートウェイ３０４に通信される、またはセキュリティゲートウェイ３０４からゲームコンソール３０２−１〜３０２−ｎに通信される各データパケットには、データが組み込まれていることが可能である。この組み込まれたデータは、パケットの内容、またはパケットのデータ内容と呼ばれる。また、追加の情報も、パケットタイプに基づき、本質的にパケットに含まれることが可能である。
【０１６０】
前述したとおり、コンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４の間のセキュアな通信チャネルは、セキュリティチケットに基づく。コンソール３０２−１〜３０２−ｎは、鍵配信センタ３２８に対してコンソール３０２−１〜３０２−ｎ自体、および現行のユーザを認証して、鍵配信センタ３２８からセキュリティチケットを獲得する。次に、コンソール３０２−１〜３０２−ｎは、このセキュリティチケットを使用してセキュリティゲートウェイ３０４とのセキュアな通信チャネルを確立する。セキュリティゲートウェイ３０４とセキュアな通信チャネルを確立する際、ゲームコンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４は、互いに対して自らを認証し、その特定のゲームコンソール３０２−１〜３０２−ｎおよびセキュリティゲートウェイ３０４だけに知られたセッションセキュリティ鍵を確立する。このセッションセキュリティ鍵は、ゲームコンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４のクラスタの間で転送されるデータを暗号化するのに使用され、したがって、その他のデバイス（他のゲームコンソール３０２−１〜３０２−ｎを含め）はどれも、そのデータを読み取ることができない。また、セッションセキュリティ鍵は、データパケットが、データパケットの起点とされるセキュリティゲートウェイ３０４、またはゲームコンソール３０２−１〜３０２−ｎからのものであることを認証するのにも使用される。したがって、そのようなセッションセキュリティ鍵を使用することにより、セキュリティゲートウェイ３０４と様々なゲームコンソール３０２−１〜３０２−ｎの間でセキュアな通信チャネルを確立することができる。
【０１６１】
ゲームコンソール３０２−１〜３０２−ｎとセキュリティゲートウェイ３０４の間でセキュアな通信チャネルが確立されると、暗号化されたデータパケットをその２つの間でセキュアに伝送することができる。ゲームコンソール３０２−１〜３０２−ｎが、データをデータセンタ３１０内の特定のサービスデバイスに送信することを望むとき、ゲームコンソール３０２−１〜３０２−ｎは、そのデータを暗号化してセキュリティゲートウェイ３０４に送信し、そのデータが、データパケットによって目標とされる特定のサービスデバイスに転送されることを要求する。セキュリティゲートウェイ３０４は、そのデータパケットを受信して、そのデータパケットを認証し、解読した後、パケットのデータ内容を、専用ネットワーク３０８を介して適切なサービスに送信される別のメッセージの中にカプセル化する。セキュリティゲートウェイ３０４は、データパケットによって目標とされる要求されたサービスに基づき、そのメッセージに適切なサービスを決定する。
【０１６２】
セキュリティゲートウェイ３０４とゲームコンソール３０２−１〜３０２−ｎの間で暗号化されたデータパケットが主に通信されるものとして本明細書では述べているが、別法では、一部のデータパケットは、部分的に暗号化されることが可能である（データパケットのある部分は暗号化され、他の部分は暗号化されない）。データパケットのどの部分が暗号化され、どの部分が暗号化されないかは、データセンタ１１０および／またはゲームコンソール３０２−１〜３０２−ｎの設計者の所望に基づいて異なる可能性がある。例えば、設計者は、コンソール３０２−１〜３０２−ｎのユーザが互いに話すことができるようにコンソール３０２−１〜３０２−ｎ間で音声データが通信されるのを許すことを選択することができ、設計者は、パケットの中のあらゆる他のデータは暗号化されているが、音声データは暗号化されていないのを許すことをさらに選択することができる。さらに、または別の代案として、一部のデータパケットが、暗号化された部分を全く有さない（すなわち、データパケット全体が暗号化されていない）ことが可能である。データパケットが暗号化されていない、または部分的にだけ暗号化されている場合でも、そのデータパケットは、認証されることに留意されたい。
【０１６３】
同様に、データセンタ３１０内のサービスデバイスが、ゲームコンソール３０２−１〜３０２−ｎにデータを通信することを望むとき、データセンタは、ゲームコンソール３０２−１〜３０２−ｎに送信されるべきデータ内容、ならびにそのデータ内容が送信されるべき先の特定のゲームコンソール３０２−１〜３０２−ｎの指示を含むメッセージを、専用ネットワーク３０８を介してセキュリティゲートウェイ３０４に送信する。セキュリティゲートウェイ３０４は、データ内容をデータパケットに組み込み、次に、データパケットを暗号化して、その特定のゲームコンソール３０２−１〜３０２−ｎだけしか解読することができないようにし、また、セキュリティゲートウェイ３０４を送信元とするものとしてデータパケットを認証する。
【０１６４】
セキュリティゲートウェイ３０４の中の各セキュリティゲートウェイデバイスは、通常、１つまたは複数のゲームコンソール３０２−１〜３０２−ｎとのセキュアな通信チャネルに責任を負い、したがって、各セキュリティゲートウェイデバイスは、１つまたは複数のゲームコンソールを管理すること、または扱うことに責任を負っているものと見なすことができる。種々のセキュリティゲートウェイデバイスは、２つが互いに通信中で、３つ以上が互いにメッセージを通信することが可能である。例えば、自らが管理することに責任を負っていないゲームコンソールにデータパケットを送信する必要があるセキュリティゲートウェイデバイスは、そのゲームコンソールに送信されるべきデータを伴うメッセージをすべての他のセキュリティゲートウェイデバイスに送信することができる。このメッセージが、そのゲームコンソールを管理することに責任を負うセキュリティゲートウェイデバイスによって受信され、適切なデータをそのゲームコンソールに送信する。あるいは、セキュリティゲートウェイデバイスが、どのゲームコンソールがどのセキュリティゲートウェイデバイスによって扱われているかを認知していることが可能であり、この認知は、各セキュリティゲートウェイデバイスが、その他のセキュリティゲートウェイデバイスによって扱われるゲームコンソールのテーブルを維持しているなど、明示的であることが可能であり、あるいは、ゲームコンソールの識別子に基づき、どのセキュリティゲートウェイデバイスが、ある特定のゲームコンソールに責任を負うかを判定するなど、暗黙的であることが可能である。
【０１６５】
監視サーバ３１２は、データセンタ３１０内のデバイスに使用不可能なゲームコンソール３０２−１〜３０２−ｎ、またはセキュリティゲートウェイ３０４の使用不可能なセキュリティゲートウェイデバイスについて知らせるように動作する。ゲームコンソール３０２−１〜３０２−ｎは、ハードウェアまたはソフトウェアの障害、コンソールが、データセンタ３１０からログアウトすることなしに電源遮断されたこと、コンソール３０２−１〜３０２−ｎに対するネットワーク接続ケーブルが、コンソール３０２−１〜３０２−ｎから接続解除されたこと、その他のネットワーク問題（例えば、コンソール３０２−１〜３０２−ｎが配置されているＬＡＮに動作不良が起きていること）などの様々な異なる理由で使用不可能になる可能性がある。同様に、セキュリティゲートウェイ３０４のセキュリティゲートウェイデバイスも、ハードウェアまたはソフトウェアの障害、デバイスが電源遮断されていること、デバイスに対するネットワーク接続ケーブルが、デバイスから接続解除されていること、その他のネットワーク問題などの様々な異なる理由で使用不可能になる可能性がある。
【０１６６】
セキュリティゲートウェイ３０４の中のセキュリティゲートウェイデバイスのそれぞれは、セキュリティゲートウェイデバイスのどれかが使用不可能になったときそれを検出する１つまたは複数の監視サーバ３１２によって監視される。あるセキュリティゲートウェイデバイスが利用不可になった場合、監視サーバ３１２は、データセンタ３１０内のその他のデバイスのそれぞれ（サーバ、フロントドア等）に、そのセキュリティゲートウェイデバイスをもはや使用不可能であるというメッセージを送信する。その他のデバイスのそれぞれは、この情報に基づき、適切と考えられる仕方で動作することができる（例えば、デバイスは、セキュリティゲートウェイデバイスによって管理されているその特定のゲームコンソールが、データセンタ３１０ともはや通信していないものと考え、それに応じて様々なクリーンアップ動作を行うことが可能である）。あるいは、あるデバイスだけ（例えば、セキュリティゲートウェイデバイスが応答可能であるかどうかに関心があるデバイスだけ）が、監視サーバ３１２からそのようなメッセージを受信することが可能である。
【０１６７】
セキュリティゲートウェイ３０４は、個々のゲームコンソール３０２−１〜３０２−ｎを監視し、ゲームコンソール３０２−１〜３０２−ｎのどれかが使用不可能になったときそれを検出する。セキュリティゲートウェイ３０４は、ゲームコンソールがもはや使用不可能であることを検出したとき、応答不可なゲームコンソールについてのメッセージを監視サーバ３１２に送信する。これに応答して、監視サーバ３１２は、データセンタ３１０内のその他のデバイスのそれぞれに（あるいは、選択されたデバイスだけに）、そのゲームコンソールがもはや使用不可能であるというメッセージを送信する。次に、その他のデバイスのそれぞれは、この情報に基づき、適切であると考えられる仕方で動作することができる。
【０１６８】
存在サーバ３１６が、オンラインゲームのためにデータセンタ３１０にログインした所与のユーザのステータスまたは存在に関するデータを維持し、処理する。通知サーバ３１８が、データセンタ３１０にログインしたプレーヤを宛先として発信されるメッセージの複数の待ち行列を維持する。存在−通知フロントドア３１４は、セキュリティゲートウェイ３０４とサーバ３１６および３１８の間の仲介役として動作する１つまたは複数のサーバデバイスである。１つまたは複数のロードバランシングデバイス（図示せず）が、フロントドア３１４として動作する複数のサーバデバイス間で負荷の平衡をとるように存在−通知フロントドア３１４内に含まれることが可能である。セキュリティゲートウェイ３０４は、サーバ３１６および３１８に向けられたメッセージをフロントドア３１４に通信し、フロントドア３１４は、サーバ３１６または３１８のどの特定のサーバにメッセージが通信されるべきかを特定する。フロントドア３１４を使用することにより、どちらのサーバが、どのユーザに関するデータを管理することに責任を負うかなどの、サーバ３１６および３１８の実際の実施が、セキュリティゲートウェイ３０４から抽出される。セキュリティゲートウェイ３０４は、単に、存在−通知サービスを目標とするメッセージを存在−通知フロントドア３１４に転送し、フロントドア３１４が、そのメッセージをサーバ３１６およびサーバ３１８の適切なものにルーティングすることに頼ることができる。
【０１６９】
マッチサーバ３２２が、オンラインプレーヤの互いとのマッチングに関するデータを維持し、処理する。オンラインユーザは、行われる用意のあるゲーム、ならびにゲームの様々な特性（例えば、フットボールゲームが行われる場所、ゲームが日中におこなわれるか、または夜に行われるか、ユーザの技能レベル等）を公示することができる。以上の様々な特性を基準として使用して、一緒にゲームを行うように様々なオンラインユーザを組み合わせることができる。マッチフロントドア３２０は、１つまたは複数のサーバデバイス（および、オプションとして、ロードバランシングデバイス）を含み、フロントドア３１４が、サーバ３１６およびサーバ３１８を抽出するのと同じ仕方で、セキュリティゲートウェイ３０４からマッチサーバ３２２を抽出するように動作する。
【０１７０】
統計サーバ３２６は、オンラインゲームに関する様々な統計に関するデータを維持し、処理する。使用される特定の統計は、ゲーム設計者の所望に基づき、様々である可能性がある（例えば、上位の第１０位までのスコアまたは時間、ゲームのすべてのオンラインプレーヤに関する世界ランキング、最も多くのアイテムを見出した、または最も多くの時間をゲームをして過ごしたユーザのリスト）。統計フロントドア３２６は、１つまたは複数のサーバデバイス（および、オプションとして、ロードバランシングデバイス）を含み、フロントドア３１４が、サーバ３１６およびサーバ３１８を抽出するのと同じような仕方でセキュリティゲートウェイ３０４から統計サーバ３２６を抽出するように動作する。
【０１７１】
照会フロントドア３３０は、セキュリティゲートウェイ３０４と照会ソース１０４の間で仲介役として動作する１つまたは複数のサーバデバイスである。１つまたは複数のロードバランシングデバイス（図示せず）が、照会フロントドア３３０内に含まれて、フロントドア３３０として動作する複数のサーバデバイスの間で負荷の平衡をとることが可能である。照会ソース１０４は、ゲームタイトルに用意されているコンテンツに関する様々な情報を保持し、前述したとおり、ゲームコンソールによるそのコンテンツへのアクセスを管理する（例えば、コンテンツを取得することができる源のコンテンツソース１０６を特定して）。ゲームコンソール識別子、ユーザ識別子、およびゲームタイトルが、前述したとおり、セキュリティゲートウェイ３０４によって認証される。したがって、照会ソースは、ゲームコンソール、ゲームコンソールユーザ、および／またはゲームタイトルを特定するコンテンツ要求を受け取ったとき、その要求の中で示されるゲームコンソール、ユーザ識別子、および／またはゲームタイトルが、実際に、セキュリティゲートウェイ３０４によって認証されているゲームコンソール、ユーザ識別子、および／またはゲームタイトルであるかどうかについて、セキュリティゲートウェイ３０４にクエリを行うことができる。
【０１７２】
したがって、セキュリティゲートウェイ３０４が、信頼されない公衆ネットワーク３０６から、データセンタ３１０のセキュアゾーン内にデバイスを遮蔽するように動作するのを見て取ることができる。データセンタ３１０内の通信は、データセンタ３１０内のすべてのデバイスが信頼されるものであるので、暗号化される必要がない。しかし、データセンタ３１０内のデバイスからゲームコンソール３０２−１〜３０２−ｎに通信されるあらゆる情報は、セキュリティゲートウェイ３０４のクラスタを通過し、その情報によって目標とされるゲームコンソール３０２−１〜３０２−ｎだけが解読できるような仕方で暗号化される。
【０１７３】
以上に述べたことから、コンテンツソースの場所、およびコンテンツパッケージに関する暗号鍵をセキュリティ確保されたチャネルを介して配信することができ、したがって、コンテンツソース自体のセキュリティ確保を行わなくてもよいことを見て取ることができる。例えば、ゲームコンソールが、前述したセキュアな通信チャネルを介して照会ソースと対話して、コンテンツ場所および暗号鍵を獲得する。その後、ゲームコンソールは、コンテンツソースに対してセキュリティ確保されていない接続（例えば、インターネットを介する）を開始して要求のコンテンツをダウンロードする。コンテンツパッケージは、暗号化され、認証されているので、許可されていない、または不正変更されているあらゆるコンテンツパッケージは、ゲームコンソールによって検出され、拒否される。
【０１７４】
図６は、本明細書で説明する技術を実施するのに使用することができる一般的なコンピュータ環境４００を示している。コンピュータ環境４００は、コンピューティング環境の一例に過ぎず、コンピュータアーキテクチャおよびネットワークアーキテクチャの使用または機能の範囲に関する何らかの限定を示唆するものではない。また、コンピュータ環境４００が、例示的なコンピュータ環境４００に図示した構成要素のいずれか１つ、または組合せに関連する何らかの依存性または要件を有するものと解釈すべきでもない。
【０１７５】
コンピュータ環境４００は、コンピュータ４０２の形態で汎用コンピューティングデバイスを含む。コンピュータ４０２は、例えば、図１の照会ソース１０４（または照会ソース１０４におけるサーバ）または１０６のコンテンツソース、または図５のサーバ３１２、３１６、３１８、３２２、および／または３２６、または図５のフロントドア３１４、３２０、３２４、および／または３３０であることが可能である。コンピュータ４０２の構成要素には、１つまたは複数のプロセッサまたはプロセッサ４０４（オプションとして、暗号プロセッサまたは暗号コプロセッサを含む）、システムメモリ４０６、ならびにプロセッサ４０４からシステムメモリ４０６までを含む様々なシステム構成要素を結合するシステムバス４０８が含まれることが可能であるが、以上には限定されない。
【０１７６】
システムバス４０８は、様々なバスアーキテクチャの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄ　ｇｒａｐｈｉｃｓ　ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含むいくつかのタイプのバス構造の任意のものの１つまたは複数を表す。例として、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャ（Ｉｎｄｕｓｔｒｙ　Ｓｔａｎｄａｒｄ　Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Ｍｉｃｒｏ　Ｃｈａｎｎｅｌ　Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＭＣＡ）バス、エンハンストＩＳＡ（Ｅｎｈａｎｃｅｄ　ＩＳＡ）（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（Ｖｉｄｅｏ　Ｅｌｅｃｔｒｏｎｉｃｓ　Ｓｔａｎｄａｒｄｓ　Ａｓｓｏｃｉａｔｉｏｎ）（ＶＥＳＡ）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるペリフェラルコンポーネントインターコネクツ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）（ＰＣＩ）バスが含まれることが可能である。
【０１７７】
コンピュータ４０２は、通常、様々なコンピュータ可読媒体を含む。この媒体は、コンピュータ４０２によってアクセス可能な任意の利用可能な媒体であることが可能であり、揮発性の媒体と不揮発性の媒体、取外し可能な媒体と取外し不可能な媒体がともに含まれる。
【０１７８】
システムメモリ４０６は、ランダムアクセスメモリ（ＲＡＭ）４１０などの揮発性メモリ、および／または読取り専用メモリ（ＲＯＭ）４１２などの不揮発性メモリの形態でコンピュータ可読媒体を含む。始動中など、コンピュータ４０２内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入力／出力システム（ＢＩＯＳ）４１４が、ＲＯＭ４１２の中に記憶される。ＲＡＭ４１０は、通常、プロセッサ４０４が即時にアクセスすることができ、かつ／または現在、演算を行っているデータ、および／またはプログラムモジュールを含む。
【０１７９】
また、コンピュータ４０２は、その他の取外し可能な／取外し不可能な、揮発性／不揮発性のコンピュータ記憶媒体も含む。例として、図７が、取外し不可能な不揮発性の磁気媒体（図示せず）に対して読取りおよび書込みを行うためのハードディスクドライブ４１６、取外し可能な不揮発性の磁気ディスク４２０（例えば、「フロッピー（登録商標）ディスク」）に対して読取りおよび書込みを行うための磁気ディスクドライブ４１８、およびＣＤ（ｃｏｍｐａｃｔ　ｄｉｓｃ　［ｄｉｓｋ］）−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ　ｖｅｒｓａｔｉｌｅ　ｄｉｓｋ）−ＲＯＭ、またはその他の光媒体などの取外し可能な不揮発性の光ディスク４２４に対して読取りおよび／または書込みを行うための光ディスクドライブ４２２を示している。ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２はそれぞれ、１つまたは複数のデータ媒体インタフェース４２５でシステムバス４０８に接続される。あるいは、ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２は、１つまたは複数のインタフェース（図示せず）でシステムバス４０８に接続することも可能である。
【０１８０】
以上のディスクドライブおよび関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストーレッジがコンピュータ４０２に提供される。この例は、ハードディスク４１６、取外し可能な磁気ディスク４２０、および取外し可能な光ディスク４２４を示しているが、磁気カセットまたはその他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）またはその他の光ストーレッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ　ｅｒａｓａｂｌｅ　ｐｒｏｇｒａｍｍａｂｌｅ　ｒｅａｄ−ｏｎｌｙ　ｍｅｍｏｒｙ）などの、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体を利用して例示的なコンピューティングシステムおよびコンピューティング環境を実施することも可能であることを理解されたい。
【０１８１】
例として、オペレーティングシステム４２６ａ、４２６ｂ、１つまたは複数のアプリケーションプログラム４２８ａ、４２８ｂ、その他のプログラムモジュール４３０ａ、４３０ｂ、およびプログラムデータ４３２ａ、４３２ｂを含む任意の数のプログラムモジュールをハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ４１２、および／またはＲＡＭ４１０に記憶することができる。そのようなオペレーティングシステム４２６ａ、４２６ｂ、１つまたは複数のアプリケーションプログラム４２８ａ、４２８ｂ、その他のプログラムモジュール４３０ａ、４３０ｂ、およびプログラムデータ４３２ａ、４３２ｂのそれぞれが（または何らかの組合せが）、分散されたファイルシステムをサポートする常駐の構成要素のすべて、または一部を実施することができる。
【０１８２】
ユーザは、キーボード４３４やポインティングデバイス４３６（例えば、「マウス」）などの入力デバイスを介してコマンドおよび情報をコンピュータ４０２に入力することができる。その他の入力デバイス４３８（特に示さず）には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、および／または以上に類するものが含まれることが可能である。以上の入力デバイス、およびその他の入力デバイスは、システムバス４０８に結合された入力／出力インタフェース４４０を介してプロセッサ４０４に接続されているが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ　ｓｅｒｉａｌ　ｂｕｓ）などのその他のインタフェースおよびバス構造で接続してもよい。
【０１８３】
また、モニタ４４２、またはその他のタイプの表示デバイスも、ビデオアダプタ４４４などのインタフェースを介してシステムバス４０８に接続することができる。モニタ４４２に加え、その他の出力周辺デバイスには、入力／出力インタフェース４４０を介してコンピュータ４０２に接続することができるスピーカ（図示せず）やプリンタ４４６などの構成要素が含まれることが可能である。
【０１８４】
コンピュータ４０２は、リモートコンピューティングデバイスコンピューティングデバイス４４８などの１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することが可能である。例として、リモートコンピューティングデバイス４４８は、パーソナルコンピュータ、可搬コンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイスまたはその他の一般的なネットワークノード、ゲームコンソール等であることが可能である。リモートコンピューティングデバイス４４８は、コンピュータ４０２に関連して本明細書で説明した要素および特徴の多く、またはすべてを含むことが可能な可搬コンピュータとして示されている。
【０１８５】
コンピュータ４０２とリモートコンピュータ４４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５０、および一般的なワイドエリアネットワーク（ＷＡＮ）４５２として描かれている。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットにおいて一般的である。
【０１８６】
ＬＡＮネットワーキング環境において実施されるとき、コンピュータ４０２は、ネットワークインタフェースまたはネットワークアダプタ４５４を介してローカルネットワーク４５０に接続される。ＷＡＮネットワーキング環境において実施されるとき、コンピュータ４０２は、通常、ワイドネットワーク４５２を介して通信を確立するためのモデム４５６、またはその他の手段を含む。コンピュータ４０２の内部にあることも、外部にあることも可能なモデム４５６は、入力／出力インタフェース４４０、またはその他の適切な機構を介してシステムバス４０８に接続することができる。図示したネットワーク接続は、例示的なものであり、コンピュータ４０２と４４８の間で通信リンクを確立する他の手段も使用できることを理解されたい。
【０１８７】
コンピューティング環境４００で例示するようなネットワーク化された環境では、コンピュータ４０２に関連して描いたプログラムモジュール、またはプログラムモジュールの部分が、リモートメモリ記憶デバイスの中に記憶されることが可能である。例として、リモートアプリケーションプログラム４５８が、リモートコンピュータ４４８のメモリデバイス上に常駐する。例示のため、オペレーティングシステムなどのアプリケーションプログラムおよびその他の実行可能プログラム構成要素は、本明細書では別々のブロックとして示されているが、そのようなプログラムおよび構成要素は、様々な時点で、コンピューティングデバイス４０２の異なる記憶構成要素の中に存在し、コンピュータのデータプロセッサによって実行されることが認識されている。
【０１８８】
本明細書では、様々なモジュールおよび技術は、１つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で説明することができる。一般に、プログラムモジュールには、特定のタスクを行う、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造等が含まれる。通常、プログラムモジュールの機能は、様々な実施形態において、所望に応じて結合する、または分散させることが可能である。
【０１８９】
以上のモジュールおよび技術の実施を何らかの形態のコンピュータ可読媒体に記憶する、またはコンピュータ可読媒体を介して伝送することが可能である。コンピュータ可読媒体は、コンピュータがアクセスすることができる任意の利用可能な媒体であることが可能である。例として、限定としてではなく、コンピュータ可読媒体は、「コンピュータ記憶媒体」および「通信媒体」を含むことが可能である。
【０１９０】
「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実装された揮発性の媒体および不揮発性の媒体、取外し可能な媒体および取外し不可能な媒体が含まれる。コンピュータ記憶媒体には、限定するものとしてではなく、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）またはその他の光ストーレッジ、磁気カセット、磁気テープ、磁気ディスクストーレッジまたはその他の磁気記憶デバイス、あるいは所望の情報を記憶するのに使用することができ、コンピュータがアクセスすることができる任意の他の媒体が含まれる。
【０１９１】
「通信媒体」は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波またはその他のトランスポート機構などの変調されたデータ信号として実現する。また、通信媒体には、あらゆる情報デリバリ媒体が含まれる。「変調されたデータ信号」という用語は、情報を信号の中に符号化するような仕方で特定の１つまたは複数が設定されている、または変更されている信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接配線ネットワークなどの有線媒体、および音響媒体、ＲＦ（ｒａｄｉｏ　ｆｒｅｑｕｅｎｃｉｅｓ）媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。以上の媒体の任意のものの組合せも、コンピュータ可読媒体の範囲に含まれる。
【０１９２】
図７は、例示的なゲームコンソール１０２の機能構成要素をより詳細に示している。ゲームコンソール１０２は、中央処理装置（ＣＰＵ）５００、ならびにフラッシュＲＯＭ（読取り専用メモリ）５０４、ＲＡＭ（ランダムアクセスメモリ）５０６、ハードディスクドライブ５０８、およびポータブルメディアドライブ５０９を含む様々なタイプのメモリに対するプロセッサアクセスを円滑にするメモリコントローラ５０２を有する。ＣＰＵ５００は、データを一時的に記憶し、したがって、メモリアクセスサイクルの回数を減らすレベル１キャッシュ５１０およびレベル２キャッシュ５１２を備え、これにより、処理速度およびスループットが向上する。
【０１９３】
ＣＰＵ５００、メモリコントローラ５０２、および様々なメモリデバイスは、様々なバスアーキテクチャの任意のものを使用するシリアルバスおよびパラレルバス、メモリバス、周辺バス、およびプロセッサバスまたはローカルバスを含む１つまたは複数のバスを介して互いに接続される。例として、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られるペリフェラルコンポーネントインターコネクツ（ＰＣＩ）バスが含まれることが可能である。
【０１９４】
１つの適切な実施として、ＣＰＵ５００、メモリコントローラ５０２、ＲＯＭ５０４、およびＲＡＭ５０６が、共通モジュール５１４上に統合される。この実施では、ＲＯＭ５０４は、ＰＣＩ（ペリフェラルコンポーネントインターコネクツ）バスおよびＲＯＭバス（どちらも図示せず）を介してメモリコントローラ５０２に接続されたフラッシュＲＯＭとして構成される。ＲＡＭ５０６は、別個のバス（図示せず）を介してメモリコントローラ５０２によって独立に制御される複数のＤＤＲ　ＳＤＲＡＭ（Ｄｏｕｂｌｅ　Ｄａｔａ　Ｒａｔｅ　Ｓｙｎｃｈｒｏｎｏｕｓ　Ｄｙｎａｍｉｃ　ＲＡＭ）として構成される。ハードディスクドライブ５０８およびポータブルメディアドライブ５０９は、ＰＣＩバスおよびＡＴＡ（ＡＴアタッチメント）バス５１６を介してメモリコントローラに接続される。
【０１９５】
３Ｄグラフィックスプロセッサ５２０およびビデオエンコーダ５２２が、高速かつ高解像度のグラフィックス処理のためのビデオ処理パイプラインを形成する。データは、デジタルビデオバス（図示せず）を介してグラフィックスプロセッサ５２０からビデオエンコーダ５２２に搬送される。オーディオプロセッサ５２４およびオーディオコーデック（エンコーダ／復号器）５２６が、高忠実度、かつステレオの処理を備えた対応するオーディオ処理パイプラインを形成する。オーディオデータは、通信リンク（図示せず）を介してオーディオプロセッサ５２４とオーディオコーデック５２６の間で搬送される。ビデオ処理パイプラインおよびオーディオ処理パイプラインは、テレビジョンまたはその他のディスプレイに伝送するためにデータをＡ／Ｖ（オーディオ／ビデオ）ポート５２８に出力する。図示した実施形態では、ビデオ処理構成要素およびオーディオ処理構成要素５２０〜５２８は、モジュール５１４上に実装される。
【０１９６】
やはりモジュール５１４上に実装されるのが、ＵＳＢホストコントローラ５３０およびネットワークインタフェース５３２である。ＵＳＢホストコントローラ５３０は、バス（例えば、ＰＣＩバス）を介してＣＰＵ５００およびメモリコントローラ５０２に結合され、周辺コントローラ５３６−１〜５３６−４に対するホストの役割をする。ネットワークインタフェース２３２は、ネットワーク（例えば、インターネット、ホームネットワーク等）に対するアクセスを提供し、イーサネット（登録商標）カード、モデム、ブルートゥース（登録商標）モジュール、ケーブルモデム等を含む多種多様な有線または無線のインタフェース構成要素の任意のものであることが可能である。
【０１９７】
ゲームコンソール１０２は、２つのゲームコントローラ５３６−１〜５３６−４）をそれぞれがサポートする２つのデュアルコントローラサポートサブアセンブリ５４０−１および５４０−２を有する。フロントパネルＩ／Ｏサブアセンブリ５４２が、電源ボタン５３１および媒体ドライブ取出しボタン５３３の機能、ならびにゲームコンソールの外面上に露出したあらゆるＬＥＤ（発光ダイオード）またはその他のインディケータをサポートする。サブアセンブリ５４０−１、５４０−２、および５４２は、１つまたは複数のケーブルアセンブリ５４４を介してモジュール５１４に結合される。
【０１９８】
８つのメモリユニット５３４−１〜５３４−８が、４つのコントローラ５３６−１〜５３６−４に、すなわち、各コントローラに対して２つのメモリユニットが、接続可能であるものとして示されている。各メモリユニット５３４は、ゲーム、ゲームパラメータ、およびその他のデータを記憶することができるさらなるストーレッジを提供する。コントローラに挿入されたとき、メモリユニット５３４−１〜５３４−８は、そのメモリコントローラ５０２によってアクセスされることが可能である。
【０１９９】
システム電源モジュール５５０が、ゲームコンソール１０２の構成要素に電力を供給する。ファン５５２が、ゲームコンソール１０２内部の回路を冷却する。
【０２００】
コンソールユーザインタフェース（ＵＩ）アプリケーション５６０が、ハードディスクドライブ５０８に記憶される。ゲームコンソールに電源が投入されたとき、コンソールアプリケーション５６０の様々な部分が、ＲＡＭ５０６および／またはキャッシュ５１０、５１２にロードされ、ＣＰＵ５００上で実行される。コンソールアプリケーション５６０は、ゲームコンソール上で利用可能な異なる媒体タイプにナビゲートする際に、整合性を有するユーザ体験を提供するグラフィカルユーザインタフェースを提示する。
【０２０１】
ゲームコンソール１０２は、暗号化、解読、認証、デジタル署名、ハッシングなどの一般的な暗号機能を行う暗号エンジンを実装する。暗号エンジンは、ＣＰＵ５００の一部として、またはＣＰＵ上で実行されるハードディスクドライブ５０８に記憶されたソフトウェアとして実装され、したがって、ＣＰＵが、暗号化機能を行うように構成されることが可能である。あるいは、暗号機能を行うように設計された暗号プロセッサまたは暗号コプロセッサが、ゲームコンソール１０２内に含まれることが可能である。
【０２０２】
ゲームコンソール１０２は、単にシステムをテレビジョンまたはその他のディスプレイに接続することにより、独立型システムとして動作させることが可能である。この独立型モードでは、ゲームコンソール１０２により、１名または複数名のプレーヤが、ゲームを行うこと、映画を観ること、または音楽を聴くことが可能になる。ただし、ネットワークインタフェース５３２を介して利用可能になるブロードバンド接続が統合されることで、ゲームコンソール１０２を、さらに、前述したとおり、オンラインゲームの参加者として動作させることが可能である。
【０２０３】
また、以下に、米国特許出願１０／１７０，００２号の内容を説明する。
【０２０４】
以下の解説は、ネットワーク化されたデバイスに関する相互認証を使用したセキュアな鍵交換メカニズムを対象とするものである。この解説では、読者が暗号化、解読、認証、ハッシング、およびデジタル署名などの基本的な暗号法に精通しているものと想定される。
【０２０５】
図８は、相互認証を使用したセキュアな鍵交換が使用可能な例示的環境９１００を示す構成図である。クライアント装置９１０２は、鍵配布センタ９１０４およびサーバ装置９１０６に結合される。デバイス９１０２と鍵配布センタ９１０４との結合は、デバイス９１０２とセンタ９１０４との間の通信を可能にする任意の様々な結合が可能である。同様に、デバイス９１０２と９１０６の間の結合も、デバイス９１０２とデバイス９１０６との間の通信を可能にする任意の様々な結合が可能である。一実施では、結合はインターネットを含み、任意選択として１つまたは複数の他のネットワーク（たとえばローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ））を含むこともできる。
【０２０６】
図８には単一のクライアント装置９１０２、単一のセンタ９１０４、および単一のサーバ装置９１０６が示されているが、環境９１００はこうしたデバイスおよびセンタを複数含むことができる。たとえば、複数のクライアント装置９１０２が、１つまたは複数の鍵配布センタ９１０４および１つまたは複数のサーバ装置と通信することができる。
【０２０７】
クライアント装置９１０２とサーバ装置９１０６との間の通信、ならびにクライアント装置９１０２と鍵配布センタ９１０４との間の通信は、任意の様々な異なるパケット形式が可能である。一実施例では、通信はユーザデータグラムプロトコル（ＵＤＰ／Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）形式である。
【０２０８】
鍵配布センタ９１０４は鍵およびセキュリティチケットをクライアント装置９１０２に配布し、これをサーバ装置９１０６とのセキュアな鍵交換で使用することができる。サーバ装置９１０６はクライアント装置９１０２にサービスを提供するか、またはクライアント装置９１０２にサービスを提供する他のデバイス（図８には図示せず）へのゲートウェイとして動作する。
【０２０９】
クライアント装置９１０２は、任意の多種多様なデバイスであってよい。本明細書の解説の中には、クライアント装置９１０２をゲームコンソールと呼ぶものもある。こうしたゲームコンソールは、専用ゲームコンソールであるかまたは追加の機能を含むものであってよい。たとえばゲームコンソールは、デジタルＶＣＲとして動作できるようにデジタルビデオレコーディング機能を含むこと、テレビジョン信号（同報通信信号、ケーブル信号、衛星放送信号などのいずれか）を同調およびデコードできるようにチャネル同調機能を含むこと、などが可能である。クライアント装置９１０２は、デスクトップＰＣ、ポータブルコンピュータ、セルラー式電話、インターネット機器、サーバコンピュータなどの、他のタイプのコンピュータデバイスであってもよい。
【０２１０】
環境９１００では、クライアント装置９１０２とサーバ装置９１０６との間の相互認証を使用したセキュアな鍵交換が望ましい。これにより、デバイス９１０２および９１０６が互いに認証し合うことが可能になり、さらに１つまたは複数の暗号鍵を確立し、セキュアでないネットワーク（たとえばインターネット）を介して相互にセキュアに通信するためにデバイス９１０２および９１０６の基礎として使用することが可能になる。
【０２１１】
相互認証を使用したセキュアな鍵交換を実行するために、鍵配布センタ９１０４からセキュリティチケットが取得される。一実施例では、セキュリティチケットは、単一チケットで、特定のクライアント装置９１０２の識別およびクライアント装置９１０２の１つまたは複数のユーザのユーザ識別を認証する、ケルベロスのような認証プロトコルを使用して、クライアント装置９１０２によって取得されるケルベロスチケットである。クライアント装置９１０２は、ケルベロスチケットを以下のように取得する。
【０２１２】
解説上、クライアント装置９１０２はゲームコンソールであると想定し、さらに４人のゲームコンソールユーザがいると想定する。それぞれのユーザには識別Ｕ１、Ｕ２、Ｕ３、およびＵ４が与えられ、ユーザ鍵Ｋ１、Ｋ２、Ｋ３、およびＫ４が割り当てられる。ゲームコンソールには、それ自体の識別Ｃおよびゲームコンソール鍵ＫＣも割り当てられる。さらに、ゲームディスクなどのゲームコンソール上でプレイされるゲームタイトルには、別の識別Ｇが割り当てられる。同様の方法で、サーバ装置９１０６にはそれ自体の識別Ａおよび鍵ＫＡが割り当てられる。本明細書に記載された認証は、ある程度、鍵Ｋ１、Ｋ２、Ｋ３、およびＫ４、ＫＣ、ならびに鍵ＫＡに依存するものであることに留意されたい。したがって、これらの鍵を選択および格納する際には、それらの鍵を割り当てられたエンティティのみがそれらを使用できることに注意を払わなければならない。
【０２１３】
ゲームコンソールは、ユーザ識別Ｕ１、Ｕ２、Ｕ３、およびＵ４ならびにユーザ鍵Ｋ１、Ｋ２、Ｋ３、およびＫ４に基づいて、検証されたユーザ識別を生成する。より具体的に言えば、検証されたユーザ識別には、ユーザ鍵から導出されたユーザ識別および値が含まれる。検証されたユーザ識別は要求と共に鍵配布センタ９１０４にサブミットされ、ゲームコンソールがユーザ鍵の知識を持っていることを、鍵配布センタに実証するために使用され、暗黙的にユーザを認証する。
【０２１４】
様々なメッセージおよび鍵が算出される方法を簡単に説明するために、次の表記法を導入する。
【０２１５】
Ｈ＝ＨＫｘ（Ｍ）：Ｈとは、鍵Ｋｘを使用するメッセージＭの鍵付き一方向ハッシュ（ＭＡＣ）である。どんなＭＡＣアルゴリズムも使用できる。こうしたＭＡＣアルゴリズムの一例が、ＩＥＴＦ　ＲＦＣ２９１０４に従ったＨＭＡＣアルゴリズムである。
【０２１６】
ＥｎｃｒｙｐｔｅｄＭ＝ＥＫｘ（Ｍ）：ＥｎｃｒｙｐｔｅｄＭとは、鍵Ｋｘを使用するメッセージＭの暗号化形式である。どんな暗号化アルゴリズムも使用できる。こうした暗号化アルゴリズムの例に、ＤＥＳ、トリプルＤＥＳ、およびＲＣ４−ＨＭＡＣが含まれる。
【０２１７】
鍵導出値を生成する方法の１つが、ゲームコンソールの鍵を使用して、ユーザ鍵の暗号ハッシュを算出することである。鍵Ｋ１を持つユーザＵ１の場合、ハッシュＨ１は次のように算出される。
Ｈ１＝ＨＫｃ（Ｋ１）
【０２１８】
ハッシュＨ１が鍵導出値を形成する。他の方法は、ユーザ鍵Ｋ１を使用して次のように現在時刻を暗号化することである。
Ｈ１＝ＥＫ１（Ｔ）
【０２１９】
結果として生じる値Ｈ１が、鍵導出値を再度形成する。検証されたユーザ識別は、次のように、ユーザ識別Ｕ１および対応する鍵導出値Ｈ１の組合せである。
検証されたユーザ識別＝（Ｕ１，Ｈ１）
【０２２０】
ゲームコンソールは、ゲームコンソール識別Ｃ、ゲームタイトル識別Ｇ、サーバ装置９１０６のサーバ識別Ａ、ならびに複数の検証されたユーザ識別（Ｕ１，Ｈ１）、（Ｕ２，Ｈ２）、（Ｕ３，Ｈ３）、および（Ｕ４，Ｈ４）を含む要求を構築する。要求は、次のような識別文字列を有する。
要求＝［Ｃ，Ｇ，Ａ，（Ｕ１，Ｈ１），（Ｕ２，Ｈ２），（Ｕ３，Ｈ３），（Ｕ４，Ｈ４）］
【０２２１】
さらに要求は、あるバージョンの認証プロトコル、およびゲームコンソールによって生成されるランダムナンス（ｎｏｎｃｅ）を含みリプレイ攻撃を阻止することができる。要求は、識別文字列全体の受取りを検証するために使用される、チェックサム値も含むことができる。ゲームコンソールは、鍵配布センタ９１０４への結合を介して要求をサブミットする。
【０２２２】
鍵配布センタ９１０４は、要求ならびに要求に含まれる識別を評価する。鍵配布センタ９１０４は、サーバ装置９１０６用に使用されるランダムセッション鍵を生成する。この例では、鍵配布センタは、ゲームコンソール９１０２がサーバ装置９１０６と通信しながら使用するためのランダムセッション鍵ＫＣＡを生成する。本明細書ではこのランダムセッション鍵ＫＣＡをケルベロスセッション鍵とも呼ぶ。
【０２２３】
鍵配布センタがチケットを生成し、その後そのチケットがゲームコンソールによってサーバ装置９１０６に提示されることになる。サーバ装置９１０６向けに発行されるチケットは１つであるが、このチケットは複数のユーザに対して有効である。チケットには、要求で提出された識別文字列が含まれる。さらに、チケットが生成された時間ＴＧ、チケットが満了するまでの時間長さを識別する時間ＴＬ、およびサーバ装置９１０６向けにランダムに生成されたケルベロスセッション鍵ＫＣＡも含まれる。チケットは、任意選択で、ゲームコンソールのユーザがアクセスを許可されているサーバ装置９１０６を介して使用可能なサービスおよび／またはサービスデバイスを識別する、サービスマップＳｍを含むこともできる。鍵配布センタは、どのユーザがどのサービスへのアクセスを許可されているか（たとえばどのユーザが、１つまたは複数の割増料金（ｐｒｅｍｉｕｍ）サービスにアクセスするための割増料金を払ったか）についての記録を維持するか、あるいは記録を維持する他のデバイスまたはセンタにアクセスする。チケットの内容は、サーバ装置の鍵ＫＡを以下のように使用する対称鍵暗号（たとえばトリプルＤＥＳ）を介して暗号化される。
【０２２４】
【数５】
2004056793.tif 000021
【０２２５】
チケットは対応する鍵導出値Ｈｉを搬送するものでないことに留意されたい。鍵配布センタが鍵導出値を読み取り、ゲームコンソールがユーザ鍵を認識していると確信すると、鍵配布センタはユーザの識別を発行済のチケット内に配置する。その後サーバ装置９１０６はチケットが伝えるすべての内容を信頼することになるため、鍵導出値Ｈｉを確認する必要はない。
【０２２６】
鍵配布センタは、生成されたチケットをゲームコンソールに返す。ゲームコンソールはサーバ装置の鍵ＫＡを知らないため、ゲームコンソールがチケットを開いて内容を変更することはできない。鍵配布センタは、添付の暗号化メッセージでセッションセキュリティ鍵も返す。セッション鍵メッセージには、チケット生成時間ＴＧ、チケット満了長さＴＬ、およびセッションセキュリティ鍵ＫＣＡが含まれ、すべての内容は以下のようにゲームコンソールの鍵ＫＣを使用して暗号化される。
【０２２７】
Ｓｅｓｓｉｏｎ　Ｋｅｙ　Ｍｅｓｓａｇｅ＝ＥＫＣ［ＴＧ，ＴＬ，ＫＣＡ］セッション鍵メッセージはゲームコンソールの鍵ＫＣで暗号化されるため、ゲームコンソールはセッション鍵メッセージを開いて、セッション時間パラメータおよびセッション鍵を回復することができる。
【０２２８】
さらに図８を参照すると、いったんクライアント装置９１０２（たとえばゲームコンソール）が鍵配布センタ９１０４からチケットを受け取ると、クライアント装置９１０２はこのチケットを使用してサーバ装置９１０６との相互認証を使用したセキュア鍵交換を実行することができる。相互認証を使用したセキュア鍵交換は、クライアント装置９１０２およびサーバ装置９１０６にお互いを認証させることが可能であり、すなわちクライアント装置９１０２はサーバ装置９１０６が自分の要求するサーバ装置であることを検証可能であり、サーバ装置９１０６はクライアント装置９１０２が自分の要求するクライアント装置であることを検証可能である。さらにデバイス９１０２および９１０６は、他方が特定鍵の知識を有することを検証可能である。
【０２２９】
鍵交換により、２つのデバイス９１０２および９１０６が、これら２つのデバイス間で共用されるが２つのデバイス間で伝送されることはなく、第三者（たとえばデバイス９１０２および９１０６と同じネットワーク上にある他のデバイス）がデバイス間の往復するトラフィックに基づいて推定することのできない新しい秘密を、導出できるようにすることも可能である。一実施例では、２つのデバイスは新しい秘密を導出するためにディフィ−ヘルマン指数演算（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ　ｅｘｐｏｎｅｎｔｉａｔｉｏｎ　ｏｐｅｒａｔｉｏｎ）を使用する。ディフィ−ヘルマンに関するさらなる情報は、Ｗ．　Ｄｉｆｆｉｅ　ａｎｄ　Ｍ．　Ｅ．　Ｈｅｌｌｍａｎ，　”Ｎｅｗ　ｄｉｒｅｃｔｉｏｎｓ　ｉｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ”，　ＩＥＥＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｈｅｏｒｙ　ｖ．　ＩＴ−１２，　ｎ．　６，　Ｎｏｖ　１９７６，　ｐｐ．　６４４−６５４に見ることができる。デバイス９１０２と９１０６との間の通信は、通信を暗号化することによって保護可能であるか、あるいは暗号化なしに実行することができる。
【０２３０】
図９は、クライアント装置とサーバ装置との間で相互認証を使用してセキュアな鍵交換を実行するための、例示的なプロセス１０１５０を示すフローチャートである。図９のプロセスは、図９の左側に示されたクライアント装置によって実行されるオペレーションと、図９の右側に示されたサーバ装置によって実行されるオペレーションにより、クライアント装置とサーバ装置の両方によって実施される。図９のプロセスは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図９のプロセスは、図８の構成要素を参照して論じられる。さらにプロセスは、クライアント装置とサーバ装置との間のプロセスとして示されているが、互いの間にセキュアな通信チャネルを確立することが望ましい任意の２つのデバイスによって実行することもできる（たとえば、プロセスは２つのクライアント装置または２つのサーバ装置によって実行することができる）。
【０２３１】
初めに、クライアント装置９１０２は鍵交換イニシエータパケットを生成し、このパケットをサーバ装置９１０６に送信する（動作１０１５２）。サーバ装置９１０６は鍵交換イニシエータパケットを受け取り、受け取ったパケットの妥当性を検査する（動作１０１５４）。パケットの妥当性が検査されると、サーバ装置９１０６は、クライアント装置９１０２との通信をセキュアにするために使用される暗号鍵を生成する（動作１０１５６）。一実施例では、これらの暗号鍵は、２つのデバイス間で２地点間通信をセキュアにするために使用されるセキュリティアソシエーション（ｓｅｃｕｒｉｔｙ　ａｓｓｏｃｉａｔｉｏｎ）鍵である。
【０２３２】
次いでサーバ装置９１０６は鍵交換応答パケットを生成し、生成されたパケットをクライアント装置９１０２に送信する（動作１０１５８）。クライアント装置９１０２は鍵交換応答パケットを受け取り、受け取ったパケットの妥当性を検査する（動作１０１６０）。パケットの妥当性が検査されると、クライアント装置９１０２は、サーバ装置９１０６との通信をセキュアにするために使用される暗号鍵を生成する（動作１０１６２）。暗号鍵は、動作１０１５６でサーバ装置９１０６によって生成されたものと同じである。したがって、クライアント装置９１０２とサーバ装置９１０６はどちらも同じ暗号鍵で終わるが、それらの間で実際に鍵を伝送しなくても終わる。
【０２３３】
プロセス１０１５０は、パーフェクトフォワードシークレシ（ｓｅｃｒｅｃｙ）を維持することに留意されたい。パーフェクトフォワードシークレシとは、たとえ第三者に以前の秘密の知識がある可能性があっても、その第三者は新しい秘密を推定できないことを言う。したがって、たとえば第三者（たとえば他のデバイス）がセッション鍵、またはクライアント装置９１０２とサーバ装置９１０６との間で以前に確立された鍵を発見しても、その第三者はセキュアな鍵交換プロセス１０１５０から生成される新しい鍵を推定できないことになる。これは、たとえば第三者に、プロセス１０１５０で使用されるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（以下でより詳細に論じる）の知識がないためである。
【０２３４】
さらに、クライアント装置９１０２とサーバ装置９１０６との間では、２つのパケット、すなわち鍵交換イニシエータパケットおよび鍵交換応答パケットだけを通信すればよいことがわかる。したがって、相互認証を使用したセキュアな鍵交換を実行するために必要となるのは、単一の往復（クライアント装置９１０２からサーバ装置９１０６へのパケット、およびサーバ装置９１０６からクライアント装置９１０２への戻りパケット）のみである。この単一の往復は、使用されるパケット数を減らすことによって、待ち時間を減らし、鍵の確立およびデバイスの相互認証において帯域幅オーバヘッドを減らす働きをする。
【０２３５】
プロセス１０１５０について、図１０〜１３を参照しながら以下でより詳細に論じる。図１０は動作１０１５２をより詳細に示し、図１１は動作１０１５４をより詳細に示し、図１２は動作１０１５６および１０１５８をより詳細に示し、図１３は動作１０１６０および１０１６２をより詳細に示す。
【０２３６】
図１０は、鍵交換イニシエータパケットを生成および送信するための、例示的なプロセス１１２００を示すフローチャートである。図１０は、図９の動作１０１５２をより詳細に示す図である。図１０のプロセスはクライアント装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１０のプロセスは、図８の構成要素を参照して論じられる。
【０２３７】
初めに、クライアント装置９１０２が鍵交換イニシエータメッセージを生成する（動作１１２０２）。鍵交換イニシエータメッセージは、以下のように、ＮｏｎｃｅＩｎｉｔと呼ばれるクライアント装置９１０２によって生成されるランダム（または擬似ランダム）値を含み、さらにＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ｇＸ　ｍｏｄ　Ｎ）値も含み、この式のＸもクライアント装置９１０２によって生成されるランダム（または擬似ランダム）値であって、さらに鍵交換プロセスが完了するとこのクライアント／サーバ通信チャネルを一意に定義する際に使用されることになる、セキュリティパラメータインデックス値（ＳＰＩ１）も含む。ＩｎｉｔＭｅｓｓ＝［ＮｏｎｃｅＩｎｉｔ，ＳＰＩ１，（ｇＸ　ｍｏｄ　Ｎ）］
【０２３８】
次いでクライアント装置９１０２は、鍵配布センタ９１０４から受け取ったケルベロスセッション鍵ＫＣＡを使用して、鍵交換イニシエータメッセージのダイジェストを算出する（動作１１２０４）。ダイジェストは以下のように生成される。
【０２３９】
【数６】
2004056793.tif 000022
【０２４０】
あるいは、ＨａｓｈＩｎｉｔＭｅｓｓのコンピューティングで、総称的一方向ハッシュ（鍵付きではない）を使用することもできる。鍵交換のセキュリティは、このハッシュが鍵付きであるか否かに依拠しない。
【０２４１】
次いでクライアント装置９１０２は、ケルベロス認証符号（ａｕｔｈｅｎｔｉｃａｔｏｒ）を生成する（動作１１２０６）。ケルベロス認証符号は、タイムスタンプ（たとえばクライアント装置９１０２の現在時刻）と、動作１１２０４で算出されたＨａｓｈＩｎｉｔＭｅｓｓダイジェストを含む。タイムスタンプは、クライアント装置９１０２がケルベロス認証符号を生成するごとにクライアント装置９１０２によって増分され、これにより、サーバ装置９１０６にリプレイ攻撃をより良く検出させることができる。クライアント装置９１０２は、以下のように、ケルベロスセッション鍵ＫＣＡを使用してケルベロス認証符号を暗号化する（動作１１２０８）。
【０２４２】
【数７】
2004056793.tif 000023
【０２４３】
次いでクライアント装置９１０２は、鍵交換イニシエータパケットを生成する（動作１１２１０）。鍵交換イニシエータパケットは、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、暗号化されたケルベロス認証符号ＡｕｔｈＴ、および鍵配布センタ９１０４から受け取ったサーバ装置９１０６用のケルベロスチケットを含む。前述のように、ケルベロスチケットは、少なくともケルベロスセッション鍵（ＫＣＡ）、チケットが有効な期間、およびクライアント装置９１０２を識別する一意の番号を含み、これらはすべて、鍵配布センタ９１０４およびサーバ装置９１０６が共用する秘密鍵を使用して暗号化される。ＳＰＩ値は、クライアント装置９１０２とサーバ装置９１０６との間のセキュリティアソシエーションまたは通信チャネルを識別する。ＳＰＩ１値はサーバ装置９１０６からクライアント装置９１０２への通信に関連付けられ、ＳＰＩ２値はクライアント装置９１０２からサーバ装置９１０６への通信に関連付けられる。したがって、鍵交換イニシエータパケットは以下のようになる。
【０２４４】
ＩｎｉｔＰａｃｋｅｔ＝［ＩｎｉｔＭｅｓｓ，ＡｕｔｈＴ，Ｔｉｃｋｅｔ］
認証符号とチケットの組合せは、ケルベロス用語でＡＰ　Ｒｅｑｕｅｓｔと呼ばれることに留意されたい。次いでクライアント装置９１０２は、鍵交換イニシエータパケットをサーバ装置９１０６に送信する（動作１１２１２）。
【０２４５】
図１１は、鍵交換イニシエータパケットを受信および妥当性を検査するための、例示的なプロセス１２２５０を示すフローチャートである。図１１は、図９の動作１０１５４をより詳細に示す図である。図１１のプロセスはサーバ装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１１のプロセスは、図８の構成要素を参照して論じられる。
【０２４６】
初めに、サーバ装置９１０６は鍵交換イニシエータパケットＩｎｉｔＰａｃｋｅｔを受信する（動作１２２５２）。一実施では、サーバ装置９１０６はすべての鍵交換イニシエータパケットが所定の形式および所定のサイズであることを予測する。サーバ装置９１０６は、この所定の形式および所定のサイズに当てはまらないいずれの鍵交換イニシエータパケットも無視する。あるいは、サーバ装置９１０６は、様々な形式および／または様々なサイズの鍵交換イニシエータパケットを可能にすることができる。
【０２４７】
いったん鍵交換イニシエータパケットが受信されると、サーバ装置９１０６は、サーバ装置９１０６が鍵配布センタ９１０４と共用する鍵を使用して、ケルベロスチケットを解読する（動作１２２５４）。次いでサーバ装置９１０６は、解読されたチケットをチェックして、チケットが失効（ｓｔａｌｅ）していないかどうかを判別する（動作１２２５６）。現在時刻が（チケットで識別された）チケットの有効な期間内に含まれる場合、チケットは失効していない。ただし、現在時刻がチケットの有効な期間内に含まれない場合、チケットは失効している。ケルベロスチケットが失効している場合、鍵交換プロセスは失敗し（動作１２２５８）、その結果、クライアント装置９１０２とサーバ装置９１０６との間にセキュリティアソシエーションは確立されない。動作１２２５８の一部として、サーバ装置９１０６は、鍵交換プロセスが失敗したことをクライアント装置９１０２に通知するか、あるいはサーバ装置９１０６は、受信したＩｎｉｔＰａｃｋｅｔを削除するだけでクライアント装置９１０２に通知しないことができる。
【０２４８】
ただし、ケルベロスチケットが失効していない場合、サーバ装置９１０６は、解読されたケルベロスチケットから回復されたケルベロスセッション鍵ＫＣＡを使用して、ケルベロス認証符号ＡｕｔｈＴを解読する（動作１２２６０）。次いでサーバ装置９１０６は、ケルベロス認証符号中のタイムスタンプＴｉｍｅにアクセスし、タイムスタンプが受入れ可能であるかどうかを調べる（動作１２２６２）。タイムスタンプは、サーバ装置９１０６の現在時刻とそれほど同期が外れていなければ、受入れ可能である。一実施例では、タイムスタンプがサーバ装置９１０６の現在時刻からの時間しきい値（たとえば、推奨されるケルベロス時間スキュー（ｓｋｅｗ）である５分）の範囲内であれば、タイムスタンプは受入れ可能である。タイムスタンプが受入れ可能でなければ、鍵交換プロセスは失敗する（動作１２２５８）。
【０２４９】
タイムスタンプが受入れ可能な場合、サーバ装置９１０６は鍵交換メッセージＩｎｉｔＭｅｓｓのダイジェストを算出する（動作１２２６４）。サーバ装置９１０６は、図１０の動作１１２０４でクライアント装置９１０２がダイジェストを算出したのと同じ方法で、ダイジェストを算出する。次いでサーバ装置９１０６は、動作１２２６４で算出したダイジェスト値が、暗号化されたケルベロス認証符号ＡｕｔｈＴの一部としてクライアント装置９１０２から受信したダイジェスト値に一致する（等しい）かどうかを調べる（動作１２２６６）。２つのダイジェスト値が同じであれば、クライアント装置９１０２とサーバ装置９１０６との間の鍵交換メッセージＩｎｉｔＭｅｓｓが変更されていない（たとえば、鍵交換メッセージＩｎｉｔＭｅｓｓが不正変更されていない）ことを確認する働きをする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは失敗する（動作１２２５８）。
【０２５０】
ただし、受信したダイジェスト値と算出されたダイジェスト値が一致した場合、サーバ装置９１０６はケルベロス認証符号が再実行（ｒｅｐｌａｙ）されたかどうかを調べる（動作１２２６８）。サーバ装置９１０６は、各クライアント装置Ｃから受信したそれぞれのケルベロス認証符号（ケルベロスチケットに示されている）からのタイムスタンプの記録を維持する。サーバ装置９１０６が、サーバ装置９１０６によって記録された最後のタイプスタンプよりも新しくないタイムスタンプＴｉｍｅの付いたケルベロス認証符号を受信すると、サーバ装置９１０６はケルベロス認証符号が再実行されたものであることを知る。ケルベロス認証符号が再実行されたものであれば、鍵交換イニシエータパケットは無効であり、鍵交換プロセスは失敗する（動作１２２５８）。ただし、ケルベロス認証符号が再実行されたものでなければ、鍵交換イニシエータパケットはサーバ装置９１０６によって妥当性検査されている（動作１２２７０）。これらの試験すべてに適合し、動作１２２７０で鍵交換イニシエータパケットの妥当性が検査されると、サーバ装置９１０６はクライアント装置９１０２が実際に自分の要求したデバイスであると認証し、サーバ装置９１０６は、クライアント装置９１０２にケルベロスセッション鍵ＫＣＡの知識があることを検証し、クライアントにＫＣの知識があることも（鍵配布センタの信用を通じて間接的に）検証する。
【０２５１】
図１２は、暗号鍵を生成するため、ならびに鍵交換応答パケットを生成および送信するための例示的プロセス１３３００を示すフローチャートである。図１２は、図９の動作１０１５６および１０１５８をさらに詳細に示す図である。図１２のプロセスはサーバ装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１２のプロセスは、図８の構成要素を参照して論じられる。
【０２５２】
初めに、サーバ装置９１０６は、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、ケルベロスセッション鍵ＫＣＡ、クライアント装置９１０２からのナンス（ＮｏｎｃｅＩｎｉｔ）、およびサーバ装置９１０６によって生成されたナンス（ＮｏｎｃｅＲｅｓｐ）に基づいて暗号鍵を生成する（動作１３３０２）。サーバ装置９１０６は、ランダム（または擬似ランダム）数Ｙ、ならびにＮｏｎｃｅＲｅｓｐと呼ばれるランダム値を生成する。さらにサーバ装置９１０６は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇＸＹ　ｍｏｄ　Ｎ）ならびにＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇＹ　ｍｏｄ　Ｎ）を算出する。この時点で、サーバ装置９１０６はセキュリティアソシエーション鍵を算出するのに十分なデータを有する。セキュリティアソシエーション鍵は、２つのコンソール間での２地点間通信をセキュアにするために使用される。一実施例では、サーバ装置９１０６は２つのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（（ｇＸ　ｍｏｄ　Ｎ）および（Ｙ））を使用して関数（ｇＸＹ　ｍｏｄ　Ｎ）を算出する。次いでサーバ装置９１０６は、値ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、（ｇＸＹ　ｍｏｄ　Ｎ）、およびケルベロスセッション鍵ＫＣＡに基づいて、様々なアルゴリズムを使用して様々なダイジェストを算出する。次いでこれらのダイジェストは、セキュリティアソシエーション鍵を形成するために使用される。一実施例では、サーバ装置９１０６が、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、（ｇＸＹ　ｍｏｄ　Ｎ）を入力として使用し、ケルベロスセッション鍵ＫＣＡを双方向ですべてのセキュアパケットを認証および暗号化／解読するためのセキュリティ鍵として使用して、４つの異なるダイジェスト（１つの鍵を認証用、１つの鍵を暗号用に、それぞれの方向用に２倍して合計４つ）を算出する。
【０２５３】
次いでサーバ装置９１０６は、鍵交換応答メッセージを生成する（動作１３３０４）。鍵交換応答メッセージは、以下のように、ＮｏｎｃｅＩｎｉｔ、クライアント装置９１０２から受信したタイムスタンプＴｉｍｅ、ＮｏｎｃｅＲｅｓｐ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇＹ　ｍｏｄ　Ｎ）、およびＳＰＩ２値を含む。
ＲｅｓｐＭｅｓｓ＝［ＮｏｎｃｅＩｎｉｔ，ＳＰＩ２，ＮｏｎｃｅＲｅｓｐ，（ｇＹ　ｍｏｄ　Ｎ）］
【０２５４】
ＳＰＩ２値はサーバ装置９１０６によって生成され、クライアント装置９１０２からサーバ装置９１０６へのすべての通信に関連付けられる。次いでサーバ装置９１０６は、以下のように、ケルベロスセッション鍵を使用して応答メッセージのダイジェストおよびハッシュ関数Ｈを算出する（動作１３３０６）。
【０２５５】
【数８】
2004056793.tif 000024
【０２５６】
動作１３３０６のハッシュ関数Ｈは、動作１１２０４のハッシュ関数Ｈと同じであるか、または異なるハッシュ関数Ｈであってよい。
【０２５７】
次いでサーバ装置９１０６は、以下のように、算出されたハッシュダイジェストおよびケルベロス認証符号からのタイムスタンプＴｉｍｅの両方を含む、ケルベロス回答メッセージを生成する（動作１３３０８）。
ＲｅｐｌｙＭｅｓｓ＝［ＨａｓｈＲｅｓｐＭｅｓｓ，Ｔｉｍｅ］
【０２５８】
次いでサーバ装置９１０６は、以下のように、暗号化アルゴリズムＥ（たとえばトリプルＤＥＳ）およびケルベロスセッション鍵ＫＣＡを使用してケルベロス回答メッセージＲｅｐｌｙＭｅｓｓを暗号化する（動作１３３１０）。
【０２５９】
【数９】
2004056793.tif 000025
【０２６０】
動作１３３０８の暗号化アルゴリズムＥは、図１０の動作１１２０６で使用される暗号化アルゴリズムと同じであるか、または異なる暗号化アルゴリズムであってよい。
【０２６１】
次いでサーバ装置９１０６は、以下のように、鍵交換応答メッセージＲｅｓｐＭｅｓｓおよび暗号化されたケルベロス回答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを含む、鍵交換応答パケットを生成する。
ＲｅｓｐＰａｃｋｅｔ＝［ＲｅｓｐＭｅｓｓ，ＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓ］
【０２６２】
次いでサーバ装置９１０６は、鍵交換応答パケットＲｅｓｐＰａｃｋｅｔをクライアント装置９１０２に送信する（動作１３３１４）。
【０２６３】
図１３は、鍵交換応答パケットを受信および妥当性評価するため、および暗号鍵を生成するための、例示的なプロセスを示すフローチャートである。図１３は、図９の動作１０１６０および１０１６２をより詳細に示す図である。図１３のプロセスはクライアント装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１３のプロセスは、図８の構成要素を参照して論じられる。
【０２６４】
初めに、クライアント装置９１０２は、サーバ装置９１０６から鍵交換応答パケットＲｅｓｐＰａｃｋｅｔを受信する（動作１４３５２）。クライアント装置９１０２は、ケルベロスセッション鍵ＫＣＡを使用して、ケルベロス回答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを解読する（動作１４３５４）。次いでクライアント装置９１０２は、解読された回答メッセージ中のタイムスタンプＴｉｍｅが、クライアント装置９１０２がサーバ装置９１０６に送信したタイムスタンプＴｉｍｅと一致するかどうかを調べる（動作１４３５６）。タイムスタンプが一致する場合（言い換えれば、タイムスタンプが等しい場合）、その一致により、サーバ装置９１０６がケルベロスチケット（ＫＡの知識を証明する）およびケルベロス認証符号（したがってケルベロスセッション鍵ＫＣＡの知識を有する）を解読できたことが確認され、実際にサーバ装置９１０６が自分の要求したものであることが確認される。したがってこれらのタイムスタンプ値が一致すれば、サーバ装置９１０６はクライアント装置９１０２に対して認証され、この時点で、完全な相互認証が達成された（サーバはクライアントに対してＫＡの知識を証明し、クライアントはサーバに対してＫＣの知識を証明した）。
【０２６５】
タイムスタンプ値が一致しなければ、図１１の動作１２２５８と同様に、鍵交換プロセスは失敗する（動作１４３５８）。ただし、タイムスタンプ値が一致する場合、サーバ装置９１０６はクライアント装置９１０２に対して認証され、続いてクライアント装置９１０２は、ケルベロスセッション鍵ＫＣＡを使用して鍵交換応答メッセージＲｅｓｐＭｅｓｓのダイジェストを算出する（動作１４３６０）。クライアント装置９１０２は、図１２の動作１３３０６でサーバ装置９１０６がダイジェストを算出したのと同じ方法で、ダイジェストを算出する。次いでクライアント装置９１０２は、自分が動作１４３６０で算出したダイジェスト値が、暗号化されたケルベロス回答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓの一部としてサーバ装置９１０６から受信したダイジェスト値と一致する（等しい）かどうかを調べる（動作１４３６２）。２つのダイジェスト値が同じであれば、サーバ装置９１０６とクライアント装置９１０２との間の鍵交換応答メッセージＲｅｓｐＭｅｓｓが変更されていない（たとえば、鍵交換応答メッセージＲｅｓｐＭｅｓｓが不正変更されていない）ことを確認する働きをする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは失敗する（動作１４３５８）。
【０２６６】
ただし、２つのダイジェスト値が一致すれば、クライアント装置９１０２は、ケルベロスセッション鍵ＫＣＡ、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、およびｇＸＹ　ｍｏｄ　Ｎに基づいて暗号鍵を生成する（動作１４３６４）。図１２の動作１３３０２に関して上記で解説したのと同様に、この時点でクライアント装置９１０２には、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇＸＹ　ｍｏｄ　Ｎ）を算出し、セキュリティアソシエーション鍵を算出するのに十分なデータがある。動作１４３６４でクライアント装置９１０２によって算出されるセキュリティアソシエーション鍵は、図１２の動作１３３０２でサーバ装置９１０６によって算出されるものと同じであり、同じ方法で算出される。ｇＸＹ　ｍｏｄ　Ｎは、クライアント装置のｇＹ　ｍｏｄ　ＮおよびＸから算出されることに留意されたい。
【０２６７】
いったんクライアント装置９１０２がセキュリティアソシエーション鍵を持てば、デバイス９１０２は、鍵交換の完了を待っていたどんなパケットも自由に伝送することができる。ただしサーバ装置９１０６は、たとえ同じ鍵セットを持っていてもその応答メッセージＲｅｓｐＭｅｓｓが失われたことを確認できないため、自由に伝送することはできない。サーバ装置９１０６は、算出されたセキュリティアソシエーション鍵で認証されたパケットをクライアント装置９１０２から受信するまで、あるいは任意選択でクライアント装置９１０２から肯定応答パケット（ＡｃｋＰａｃｋ）を受信するまで、待機する。
【０２６８】
一般には、クライアント装置９１０２がサーバ装置９１０６にパケットを送信するため、鍵交換プロセスは２つのパケット、すなわちＩｎｉｔＰａｃｋｅｔおよびＲｅｓｐＰａｃｋｅｔのみで構成される。あるいは、クライアント装置９１０２がまだパケットを送信していなければ、クライアント装置９１０２は人工の肯定応答パケット（「ＡｃｋＰａｃｋ」と表記される）を送信することになる。このパケットは他の２つの鍵交換パケットとは異なり、ケルベロスセッション鍵ＫＣＡの代わりに算出されたセキュリティアソシエーション鍵を使用してＡｃｋＰａｃｋがハッシュされる。
【０２６９】
これ以降、２つのデバイス９１０２および９１０４はセキュリティアソシエーション鍵を使用して通信をセキュアにする。他方のデバイスに伝送する必要のあるすべてのネットワークパケットは、任意選択で暗号化された後、受信側デバイスがパケットのコンテンツを解読する前に認証データを検証することによって認証される。デバイス９１０２および９１０４はいずれも、同じナンスを含む他方側からの鍵交換パケットを無視することができる。
【０２７０】
本明細書で論じた相互認証を使用したセキュア鍵交換は、秘密を導出するためのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ指数演算を参照しながら論じられた。別法として、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎの代わりに他の暗号オペレーションまたは方法を使用することもできる。
【０２７１】
（結び）
以上の説明は、構造上の特徴および／または方法上の動作に特有の言い回しを使用したが、特許請求の範囲で定義される本発明は、説明した特定の特徴または動作に限定されないことを理解されたい。むしろ、以上の特定の特徴および動作は、本発明を実施する例示的な形態として開示している。
【０２７２】
【発明の効果】
以上説明したように本発明によれば、コンテンツを受け取る資格のあるデバイスだけが、コンテンツを受け取り、使用することができるように限定する機能を提供できる。
【図面の簡単な説明】
【図１】本発明の実施形態のコンテンツアクセス管理を使用することができる例示的な環境を示すブロック図である。
【図２】本発明の実施形態のコンテンツアクセスを管理するための例示的なプロセスを示すフローチャートの図である。
【図３】本発明の実施形態のゲームコンソールとセキュリティゲートウェイデバイスの間でセキュアな通信を確立するための例示的なプロセスを示すフローチャートの図である。
【図４】本発明の実施形態の図１の例示的なデータベースをさらに詳細に示すブロック図である。
【図５】本発明の実施形態の例示的なオンラインゲーム環境を示すブロック図である。
【図６】本発明の実施形態の一般的なコンピュータ環境を示す図である。
【図７】本発明の実施形態のゲームコンソールの機能上の構成要素をより詳細に示す図である。
【図８】本発明の実施形態の相互認証を使用したセキュアな鍵交換が使用可能な例示的環境を示す構成図である。
【図９】本発明の実施形態のクライアント装置とサーバ装置との間で相互認証を使用してセキュアな鍵交換を実行するための、例示的なプロセスを示すフローチャートの図である。
【図１０】本発明の実施形態の鍵交換イニシエータパケットを生成および送信するための、例示的なプロセスを示すフローチャートの図である。
【図１１】本発明の実施形態の鍵交換イニシエータパケットを受信および妥当性を検査するための、例示的なプロセスを示すフローチャートの図である。
【図１２】本発明の実施形態の暗号鍵を生成し、さらに鍵交換応答パケットを生成および送信するための、例示的なプロセスを示すフローチャートの図である。
【図１３】本発明の実施形態の鍵交換応答パケットを受信および妥当性を検査するため、および暗号鍵を生成するための、例示的なプロセスを示すフローチャートの図である。
【符号の説明】
１００　コンテンツアクセス管理の環境
１０２　ゲームコンソール
１０４　照会ソース
１０６　コンテンツソース
１０８　認証モジュール
１１０　検証モジュール
１１２　選択モジュール
１１４　データベース
１１６　コンテンツ
１４０　コンテンツアクセスを管理するプロセス
２００　セキュアな通信チャネルを確立するプロセス
２４０　提供（ｏｆｆｅｒｓ）テーブル
２４２　タイトル＿提供（ｔｉｔｌｅ＿ｏｆｆｅｒｓ）テーブル
２４４　提供＿場所（ｏｆｆｅｒ＿ｌｏｃａｔｉｏｎｓ）テーブル
２４６　加入（ｓｕｂｓｃｒｉｐｔｉｏｎｓ）テーブル
２４８　国（ｃｏｕｎｔｒｉｅｓ）テーブル
２５０　提供＿地域（ｏｆｆｅｒ＿ｒｅｇｉｏｎｓ）テーブル
３０２−１〜３０２−ｎ　ゲームコンソール
３０４　セキュリティゲートウェイ
３０６　公衆ネットワーク
３０８　専用ネットワーク
３１０　データセンタ
３１２　監視サーバ
３１４　存在−通知フロントドア
３１６　存在サーバ
３１８　通知サーバ
３２０　マッチフロントドア
３２２　マッチサーバ
３２４　統計フロントドア
３２６　統計サーバ
３２８　鍵配信センタ
３３０　照会フロントドア
９１０２　クライアント装置
９１０４　鍵配布センタ
９１０６　サーバ装置
１０１５０　　鍵交換プロセス
【図１】
2004056793.tif 000026
【図２】
2004056793.tif 000027
【図３】
2004056793.tif 000028
【図４】
2004056793.tif 000029
【図５】
2004056793.tif 000030
【図６】
2004056793.tif 000031
【図７】
2004056793.tif 000032
【図８】
2004056793.tif 000033
【図９】
2004056793.tif 000034
【図１０】
2004056793.tif 000035
【図１１】
2004056793.tif 000036
【図１２】
2004056793.tif 000037
【図１３】
2004056793.tif 000038