JP4981136B2 - アドオンデータファイルへのアクセスを管理する方法及びシステム - Google Patents

Description

本発明は、ソフトウェアアプリケーションによって使用される、アドオンデータファイル属性を有する少なくとも１つのアドオンデータファイルへのアクセスを管理する方法及びシステムに関する。

成功したコンピュータソフトウェアアプリケーション、特にコンピュータゲームは、しばしば、このようなソフトウェアアプリケーションのユーザをして、ソフトウェアアプリケーションの能力拡張を望ましめることとなり、かかる能力拡張は追加アドオンデータファイルを使用することによって行うものだが、例えばコンピュータゲームには追加レベルファイル、ナビゲーションプログラムには追加マップファイル、ワードプロセシングプログラムには追加フォントファイル等があり、又は他の拡張ファイルもある。このようなソフトウェアアプリケーションの経済的成功はあまり予測できるものではないため、このような追加アドオンファイルは、オリジナルソフトウェアアプリケーションにはあまり含まれていない。このような追加アドオンファイルを販売する市場は大きくなっており、追加アドオンファイルは、ソフトウェアアプリケーションのオリジナル開発者やオリジナル供給者ではなく、他のプログラマーが開発したものであり、他の供給者が供給するものである。最近、このような追加アドオンデータファイルは、しばしばインターネットを介して提供される。このようなアドオンファイルのプログラマー、クリエイター及び供給者はまた自分たちの努力に対する見返りも望むため、このようなアドオンデータファイルはコピーに対して保護さればならない。

このような、アドオンデータファイルのためのコピー保護は、簡単に達成できるものではない。１つの可能性としては、オリジナルソフトウェアアプリケーションのプログラマーが、アクセスコードレイヤ、例えば何らかの復号／暗号化アルゴリズムをオリジナルソフトウェアアプリケーション内に実装しなければならないのであるが、このアクセスコードレイヤとは扱いにくいものであり、通常、ソフトウェアアプリケーションの、特にコンピュータゲームのプログラマーはコピー保護ソフトウェアのプログラミングの専門家ではないのである。加えて、コンピュータゲームの開発における時間の制約は非常に厳しく、そのため、アドオンデータファイルのためのアドオンデータファイルを含める手間の追加は防ぐべきである。さらに、オリジナルプログラマー及びオリジナル供給者はアドオンデータファイルのプログラマー及び供給者とは違うため、このようなコピー保護をオリジナルソフトウェアアプリケーションに含める動機はあまりない。

別の手法においては、アドオンデータファイルは暗号化される。このような追加アドオンデータファイルを使用したいユーザが、アドオンデータファイルの使用許可に代金を支払った後、復号鍵を手に入れる。しかしながら、アドオンデータファイルが復号鍵によって復号された後は、さらなる無許可コピー及び流通が可能であり、それにより、アドオンデータファイルのプログラマー及び供給者の収入が削減される。

本発明の目的は、ソフトウェアアプリケーションが使用する少なくとも１つのアドオンデータファイルへのアクセスを管理する方法を提供することであり、かかる方法は、ソフトウェアアプリケーションの発行者が扱いやすく、このようなアドオンデータファイルの無許可コピーに対する効果的な保護を提供するものである。

さらに本発明の目的は、ソフトウェアアプリケーションが使用する少なくとも１つのアドオンデータファイルへのアクセスを管理するシステムを提供することであり、かかるシステムは、ソフトウェアアプリケーションのプログラマーが使用しやすく、このようなアドオンデータファイル無許可コピーに対する効果的な保護を提供するものであり、かかる保護はこのようなアドオンデータファイルのユーザが使用するに便利である。

第１の観点において、ソフトウェアアプリケーションによって使用される、アドオンデータファイル属性を有する少なくとも１つのアドオンデータファイルへのアクセスを管理する方法によって、目的は達成され、当該方法は、
上記アドオンデータファイルに対するアクセスコードを定めるステップと、
コードレイヤのアプリケーションプログラミングインターフェース（ＡＩＰ）への上記ソフトウェアアプリケーションの入力／出力命令を監視し、上記アドオンデータファイル属性を有するデータファイルへのアクセスが上記ソフトウェアアプリケーションによって要求されるかどうかを判定するステップと、
監視される少なくとも１つの上記入力／出力命令が上記アドオンデータファイルへのアクセスを要求する場合、上記アクセスコードが、上記ソフトウェアアプリケーションに関するアクセスコードリストに存在するかどうかを検査するステップと、
上記アクセスコードが上記アクセス制御リストに存在しない場合、上記アクセス制御リストの外側にある外部ソースから上記アクセスコードを取り出すステップと、
上記アクセスコードが存在する場合、上記アドオンデータファイルへのアクセスを提供するステップと
を含む方法である。

保護されたアドオンデータファイルにソフトウェアアプリケーションがアクセスしようとすると、アプリケーションプログラミングインターフェースのユーザを監視することによって、このアクセスはインターセプトされ、アドオンデータファイルのコンテンツに対してアクセスコードがすでに得られているかどうか検査される。アクセスコードリストにおける有効なエントリが発見される場合、アクセスが許諾される。有効なエントリとは、許可使用の任意の時間内の日付、又は目下の構成又はランタイム環境に整合するユーザ又はハードウェア識別を含むものであってもよい。さもなければ、上記アクセスコードリストの外側にある外部ソースからアクセスコードを、ソフトウェアアプリケーションは取り出そうとする。入力／出力命令自体は、例えばソフトウェアアプリケーションのオリジナルデータファイルへの他の入力／出力命令に対する場合のように、そのまま変化しなくてもよい。したがって、当該方法は透過的（ｔｒａｎｓｐａｒｅｎｔ）であり、つまりは、ソフトウェアアプリケーションは、このような方法を認知する必要がないということを意味し、当該方法は単にオリジナルプログラマーが意図してあったかのように行われる場合がある。ソフトウェアアプリケーションは、このようなアドオンデータファイルへのアクセス制御を実施するために変更される必要はなく、ソフトウェアアプリケーションのソースコードは、当該方法を実施するために認知される必要はない。他方で、上記ソフトウェアアプリケーションのランタイム中はアクセスが制御されるため、ランタイム前に上記アドオンファイルを復号する必要はなく、そのため、復号アドオンファイルをコピーする可能性はない。なぜならば、アドオンファイルはファイルシステム上に単に別個で存在しないものであるからである。

認知されなければならないのは、どのアドオンデータファイル属性が使用されるかということのみであるため、当該方法そのものは実際のソフトウェアアプリケーションから独立しているものである。いかなる場合にせよ、このようなアドオンデータファイル属性を有するアドオンデータファイルへのアクセスがソフトウェアアプリケーションによって要求される場合に、当該方法は適用可能である。外部ソースは、上記ソフトウェアアプリケーションのプログラミングに関与しない第三者によって組織され、供給される場合がある。

当該方法を用いると、ソフトウェア及びアドオンデータファイルに対する異なる所有権及び責任を得ることが容易である。

第２の観点では、ソフトウェアアプリケーションによって使用される、アドオンデータファイル属性を有するアドオンデータファイルへのアクセスを管理するシステムであって、
上記アドオンデータファイルに対するアクセスコードを生成するアクセスコード生成部と、
上記ソフトウェアアプリケーションに関する、移送可能でないアクセスコードリストと、
上記アクセスコードリストの外側に、上記アクセスコードを得るための外部ソースと、
上記ソフトウェアアプリケーションのための別個の制御ロジックであって、
上記アドオンデータファイル属性を有するデータファイルへのアクセスが上記ソフトウェアアプリケーションによって要求されるかどうか、コードレイヤのアプリケーションプログラミングインターフェース（ＡＰＩ）への上記ソフトウェアアプリケーションの入力／出力命令を検査し、
上記入力／出力命令が上記アドオンデータファイルのアクセスを要求する場合、上記アドオンデータファイルにアクセスするための上記アクセスコードが上記アクセスコードリストに存在するかどうかを検査し、
上記アクセスコードが上記アクセスコードリストに存在しない場合、上記アクセスコードが上記外部ソースから獲得可能であるかどうかを検査し、
上記アクセスコードが存在する場合、上記アドオンデータファイルへのアクセスを提供する別個の制御ロジックと
を備えるシステムが提供される。

当該システムを用いると、制御ロジックがコピー保護の専門家によって構成され、ソフトウェアアプリケーションはこのようなアドオンデータファイルを使用することに特に適応する必要はない、ということが可能である。ソフトウェアアプリケーションと制御ロジックとの間に特別な関係がないため、制御ロジックは、変化せずとも色々なソフトウェアアプリケーションに簡単に適用可能である。アクセスコードリストは透過的ではないため、単純にアクセスコードリストをコピーすることでは、アドオンデータファイルに対するこのようなコピー保護スキームを避けることは不可能なのである。

第３の観点では、アドオンデータファイル属性を有するアドオンデータファイルへのアクセスを管理するシステムであって、
ランタイム中に上記アドオンデータファイルを使用するソフトウェアアプリケーションと、
上記アドオンデータファイルへの上記ソフトウェアアプリケーションのアクセスを制御するコードレイヤであって、アプリケーションプログラミングインターフェース（ＡＰＩ）を提供するコードレイヤと、
上記アドオンデータファイルに対するアクセスコードを生成するアクセスコード生成部と、
上記ソフトウェアアプリケーションに関するアクセスコードリストと、
上記アクセスコードリストの外側に、上記アクセスコードを得るための外部ソースと、
上記ソフトウェアアプリケーションのための別個の制御ロジックであって、
上記アドオンデータファイル属性を有するデータファイルへのアクセスが上記ソフトウェアアプリケーションによって要求されるかどうか、上記アプリケーションプログラミングインターフェース（ＡＰＩ）への上記ソフトウェアアプリケーションの入力／出力命令を検査し、
上記入力／出力命令が上記アドオンデータファイルのアクセスを要求する場合、上記アドオンデータファイルにアクセスするための上記アクセスコードが上記アクセスコードリストに存在するかどうかを検査し、
上記アクセスコードが上記アクセスコードリストに存在しない場合、上記アクセスコードが上記外部ソースから獲得可能であるかどうかを検査し、
上記アクセスコードが存在する場合、上記アドオンデータファイルへのアクセスを提供する別個の制御ロジックと、
上記別個の制御ロジックと上記ソフトウェアアプリケーションとが同一の処理において動作するように、上記別個の制御ロジックを上記ソフトウェアアプリケーションにリンクさせるためのリンキングプログラムと
を備えるシステムが提供される。

本発明の上述の又は他の課題、特徴及び効果は、添付図面と併せて以下の本発明の現時点で好ましい例示的実施形態から明らかとなろう。

アドオンデータファイルへのアクセスを管理するためのシステムの第1の実施形態の概略ブロック図を示す。 アドオンデータファイルを管理するためのシステムの第２の実施形態の概略ブロック図を示す。 アドオンデータへのアクセスを管理するための方法ステップを示す。

図１において、アドオンデータファイルに対するアクセスを管理するためのシステムの第１の実施形態の概略ブロック図を示す。例えばコンピュータゲーム、ワードプロセッシングプログラム又はナビゲーションプログラムのようなソフトウェアアプリケーション１が、１つの処理３において制御ロジック２とともに動作している。ソフトウェアアプリケーションのまわりに「包装（ｗｒａｐｐｅｒ）」を提供して、無許可コピーに対してソフトウェアアプリケーション１を保護するために制御ロジック２を使用可能である。例えば、ソフトウェアアプリケーションを使用するユーザが、ソフトウェアアプリケーションを開始する前に正しい鍵を入力したかどうかを検査することにより、ソフトウェアアプリケーションの許可使用が確立する。このような検査は制御ロジック２が行う。ソフトウェアアプリケーション１及び制御ロジック２の扱いを容易にするために、両部はリンキングプログラムによって互いにリンクされ、１つの実行可能オブジェクトコードが作成され、適切なハードウェア、例えばコンピュータ上で１つの処理として動作している。適宜、この処理は、追加許可コードの入力後にのみ開始されるものであってもよいし、又は光ディスクの認証後に開始されるものであってもよい。

いくつかのソフトウェアアプリケーションには、追加アドオンデータファイル４によって、その能力を拡張する可能性が存在し、追加アドオンデータファイル４は、ソフトウェアアプリケーション１に依存して色々なコンテンツを有する場合があるものである。例えば、コンピュータゲームをソフトウェアアプリケーション１とした場合、このようなアドオンデータファイル、又はソフトウェアが解釈可能なデータファイルは、追加レベルファイル、プレイ中に使用するための追加キャラクターファイル、フライトシミュレーションプログラム用追加テリトリーとしての追加マップ等を含む場合があるが、それらに限定されるものではない。また、他の拡張データファイルも使用可能であり、例えば、ワードプロセッシングには追加フォントファイル、又はナビゲーションプログラムには追加マップがある。しばしば、このような追加アドオンデータファイル４のクリエイター、プログラマー、発行者及び／又は供給者は、オリジナルソフトウェアアプリケーション１のプログラマーとは異なる。このような追加アドオンデータファイル４への無許可アクセスを制限するために、このようなアドオンデータファイル４を暗号化し、復号鍵を販売するという可能性がある。しかしながら、このような暗号化アドオンデータファイル４復号してしまった後は、このようなアドオンデータファイル４の無許可流通をそれ以降も防止するのは困難である。

図示する実施形態の中では、アプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）の入力／出力命令を監視してアドオンデータファイル４へのソフトウェアアプリケーション１のアクセスを妨害することによって、ソフトウェアアプリケーション１のアクセスはランタイム中には制御され、ＡＰＩはコードレイヤ、例えばＷｉｎｄｏｗｓ（著作権）オペレーションシステムが提供するものである。アドオンデータファイル属性で識別されるものであるアドオンデータファイル４のアクセスをソフトウェアアプリケーション１が要求する場合、制御ロジック２は、このようなアドオンデータファイル４にアクセスするためのアクセスコードがアクセスコードリスト１１、例えばアクセス制御リスト（ＡＣＬ：ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ）内に存在するかどうか検査している。このようなアクセスコードは、生成ユニットを使用して、アドオンデータファイル４の供給者又はクリエイターが生成する。アクセスコードは、例えば、データファイル属性としてコンテンツ識別（コンテンツＩＤ）とハードウェア又はユーザ識別と、又は、コンテンツＩＤを有するこのようなアドオンデータファイルに対するアクセスコードが有効である間の時間を含む。アドオンデータファイル４に対するこのようなアクセスコードがアクセスコードリスト１１内に存在する場合、制御ロジック２は、グラフィカルユーザインターフェースＧＵＩ１３及び／又は有効化（ａｃｔｉｖａｔｉｏｎ）サーバ１２を介して外部ソースからアクセスコードを取り出そうとする。アドオンデータファイル属性は、アドオンデータファイル４へのアクセス要求を識別するのに使用されるものであり、ファイルフォーマット仕様又はコンパイルの日付を含んでもよいが、それに限定されるものではない。

グラフィカルユーザインターフェースＧＵＩ１３は、別々に提供可能であり、事前に取得してあったアクセスコードをユーザが手動入力するのに使用可能であり、又はユーザ識別を入力するのに使用可能である。このようなユーザ識別を使用すると、例えばユーザがアドオンデータファイルを正しく持ち込み、そのユーザ識別を有効化サーバへ入力したため、アドオンデータファイルへのアクセスが当該ユーザに許可されるかどうかを、このようなアクセスが誰に許可されるべきであるかを識別するために有効化サーバ１２内で検査可能である。また対応の「専用化（ｐｅｒｓｏｎａｌｉｚｅｄ）」アクセスも、制御ロジック２によって直接有効化サーバ１２へ送信されるだろうハードウェア識別で可能である。そのため、アドオンデータファイル４へのユーザ又はハードウェア特定アクセス権を許諾することが可能である。有効化サーバ１２への通信中に、それまでにユーザが対応のアクセスコードを持ち込んでいないことが明らかとなる場合、ユーザ入力支払データ、グラフィカルユーザインターフェース１３によって、例えばクレジットカードデータ、ということを許可することさえ可能であり、その後アクセスコードが取り出され、そのためユーザがアドオンデータファイル４をその後すぐに使用可能となる。通信はインターネットを介して行われる場合がある。

上記外部ソースを介して、すなわちグラフィカルユーザインターフェース１３及び／又は有効化サーバ１２を介してアクセスコードが入手可能である場合、当該アドオンデータファイル４へのさらなるアクセスを加速するために、このアクセスコードは後でアクセスコードリスト１１内に格納可能である。追加検証（ｖａｌｉｄａｔｉｏｎ）情報も格納される場合があり、それは例えば、アクセスが許可される時間の日付、ユーザ識別またはハードウェア識別である。加えて、アドオンデータファイル４へのアクセスは、プロセス３のランタイム中は許諾される。ランタイム中にアドオンデータ４の暗号化バージョンを復号するために、アクセスコードは復号鍵を含む場合がある。

格納されるアドオンデータファイル４にとって使用可能なさらなるコピー保護がある場合でない限り、アドオンデータファイルの無許可コピーを防止するためにソフトウェアアプリケーションは、アドオンデータファイル４のオリジナル又は変更バージョンを格納することから防止される。ソフトウェアアプリケーション２がファイルシステムへファイルを書き込もうとしているかどうかを制御ロジック２によって検査することは、このような防止を確証する場合がある。

アクセスコードリスト１１は移送不可能であり、例えば、ファイルシステムに隠されているか、又はコピーに対するさらなる措置によって守られている。さもなければ、アドオンデータファイル４の無許可使用を可能とするために、このようなアクセスコードリスト１１をコピーすることが可能であろう。別の可能性は、アドオンデータファイルへのアクセスが要求されると、チェックされるハードウェア識別又はユーザ識別を利用することである。

アクセスコードは、アクセス制御リスト１１に格納され、アドオンデータファイルのコンテンツ識別（コンテンツＩＤ１、コンテンツＩＤ２）によって構成され、コンテンツ識別はデータファイル属性として使用可能なものである。

データファイル属性は、さらに、特別な組合せの値として実現される場合があり、一般的に「マジック（ｍａｇｉｃ）」値と呼ぶ。

図２において、アドオンデータファイルへのアクセスを管理するためのシステムの第２の実施形態を示す。これは第１の実施形態と同様であり、そのため、図１中と同一の機能の同一のブロックは同一の番号で識別してあり、ここではもう説明しない。この第２の実施形態において、制御ロジック２とともにある動的リンクライブラリ（ＤＬＬ：ｄｙｎａｍｉｃ ｌｉｎｋ ｌｉｂｒａｒｙ）をランタイム中にローダ１４によりソフトウェアアプリケーション１の処理へロードすることによって、ソフトウェアアプリケーション１と制御ロジック２とのリンキングはランタイム中に動的に行われる。第１の実施形態においては、ランタイム前に１つの実行可能ファイルを構成することによって、リンキングは静的に行われていた。

図３において、の方法ステップを示す。第１のステップＳ１において、ソフトウェアアプリケーション１のランタイム中、アプリケーションプログラミングインターフェースＡＰＩのその入力／出力命令が監視される。当該監視中に制御ロジックが、第２のステップＳ２においてアドオンデータファイル属性を有するデータファイルが要求されると認識すると、第３のステップＳ３において、要求されるアドオンデータファイル４に対するアクセスコードがアクセスコードリスト１１に存在するかどうかということが検査される。アクセスコードがアクセスコードリスト１１において入手不可能である場合、第４のステップＳ４において制御ロジックは外部ソース１２、１３からアクセスコードを取り出す。外部ソース１２、１３に、又はアクセスコードリスト１１内にこのようなアクセスコードが存在する場合、アドオンデータファイル４へのアクセスが第５のステップＳ５において許諾され、さもなければ、第６のステップＳ６においてアクセスは拒否される。適宜、アクセスコードが有効であるかどうかを、例えばアクセスが許可されている時間が満たされるかどうか、又は格納されたユーザ識別又はハードウェア識別に対応する正しいユーザ又はハードウェアがアクセスを要求しているかどうかを、検査可能である。第２のステップＳ２においてアドオンデータファイル属性を有するデータファイルが１つも要求されない場合、要求は第８のステップＳ８において単に転送される。

アドオンデータファイル４への要求が行われるかどうかを判定する非常に効果的な方法は、所定のファイルフォーマット仕様に関するアドオンデータファイル４を構成することであり、これはソフトウェアアプリケーション１のアクセスを制御するためのトリガーとして使用可能なものである。

外部ソース１２、１３から取り出したアクセスコードがアクセスコードリスト１１内に格納される場合、外部ソース１２、１３から再び上記アクセスコードを取り出す必要がないため、さらなるアドオンデータファイル４へのアクセス要求はよりはやく扱われる。この場合、このようなアクセスコードが有効である時間を、又は他の検証情報、例えばユーザ又はハードウェア識別を追加格納することが可能である。

アドオンデータファイル４が暗号化されると、非常に効果的なコピー保護がアドオンデータファイル４に得られる。そのため、対応の復号鍵をもたないいかなる無許可コピーは役に立たない。復号鍵はアクセスコードと連結されており（アクセスコードそのものである場合もある）、そのため、このアクセスコードを有するユーザのみにこのようなアドオンデータファイル４を使用する権限があり、アドオンデータファイル４は、ランタイム中に復号鍵で復号されるのである。

アクセスコードを取り出す便利な方法としては、ユーザによるアクセスコードの手動入力を要求することによる。この実施形態においては、アドオンデータファイル提供者から対応のアドオンデータファイル４を購入することにより、ユーザは事前にアクセスコードを獲得してある。

アクセスコードを取り出すさらなる便利な方法としては、例えばインターネットを介して、ユーザがこのようなアドオンデータファイル４を対応のアクセスコードとともに持ち込んだ後に、アクセスコードが格納されているところの有効化サーバ１２へ接続することによる。有効化サーバ１２は、アドオンデータファイルの提供者が、又は他の第三者、例えば制御ロジック２の提供者が提供する場合もある。そのため、ソフトウェアアプリケーション１のプログラマー又は供給者がこのようなアクセス許可を対処する必要はない。

ユーザごと又はハードウェアごとのアクセスが、アクセスコードに対するユーザ又はハードウェアの関係を確証することによって、提供可能である。このようなユーザごと又はハードウェアごとのアクセス権を用いて、アドオンデータファイルの無許可流通がさらに妨害される。

当該方法は、コンピュータゲームをソフトウェアアプリケーションとした、レベルファイル及び／又はマップファイル及び／又はスタイルファイル及び／又は拡張ファイルのようなアドオンデータファイル４に対して特に有用である。

この実施形態を実施する透過的で効果的な方法が、制御ロジック２を使用することであり、制御ロジック２はソフトウェアアプリケーション１の使用を許可することにも適するものである。そのため、ソフトウェアアプリケーション１のプログラマーはソフトウェアアプリケーション自体を対処しなければならないだけなのである。制御ロジック２はコピー保護を処置する、つまり、ソフトウェアアプリケーション１のコピー保護を処置し、またアドオンデータファイル４のコピー保護も処置する。

ユーザがアクセスコードを入力するための、又はユーザ識別を入力するための別個のグラフィカルユーザインターフェース１３は、アドオンデータファイル４のクリエイター又は供給者に対して、このようなグラフィカルユーザインターフェース１３に適応して、例えば広告又は支払スキーム等に関する自身の要望を満たすという可能性を与えるものである。ユーザが予めアクセスコードを購入していないのだが、制御ロジック２が有効化サーバ１２と通信している前には購入するつもりである場合には、グラフィカルユーザインターフェース１３は、クレジットカードデータのような支払データを入力するという可能性も与えるであろう。

データファイル属性を使用せずにアドオンデータファイルへのアクセスを識別するさらなる可能性としては、このような要求に対して、ソフトウェアアプリケーション１と制御ロジック２との間に特別なアプリケーションプログラミングインターフェース（ＡＰＩ）を定めることである。この可能性では、アクセスが拒否される場合、ソフトウェアアプリケーション１と制御ロジックとの間の協力が必要となる。特別なＡＰＩを使用して、アクセスが拒否された場合に、アドオンデータファイルのアクセスに関するソフトウェアアプリケーション１の挙動を改善可能である。

１ ソフトウェアアプリケーション
２ 制御
３ 処理
４ アドオンデータファイル
５ アドオンデータファイル属性
６ アプリケーションプログラミングインターフェースＡＰＩ
１１ アクセスコードリスト
１２ 有効化サーバ
１３ グラフィカルユーザインターフェースＧＵＩ
１４ ローダ
Ｓ１ 第１のステップ
Ｓ２ 第２のステップ
Ｓ３ 第３のステップ
Ｓ４ 第４のステップ
Ｓ５ 第５のステップ
Ｓ６ 第６のステップ
Ｓ７ 第７のステップ
Ｓ８ 第８のステップ

Claims (16)

1. ソフトウェアアプリケーション（１）によって使用される、アドオンデータファイル属性を有する少なくとも１つのアドオンデータファイル（４）へのアクセスを管理する方法であって、
   前記ソフトウェアアプリケーションの許可使用を検査する別個の制御ロジックによってコードレイヤのアプリケーションプログラミングインターフェース（ＡＩＰ、６）への前記ソフトウェアアプリケーションの入力／出力命令を監視し、前記アドオンデータファイル属性を有するデータファイルへのアクセスが前記ソフトウェアアプリケーション（１）によって要求されるかどうかを判定するステップと、
   監視される少なくとも１つの前記入力／出力命令が前記アドオンデータファイル（４）へのアクセスを要求する場合、前記アドオンデータファイル（４）に対するアクセスコードが、前記ソフトウェアアプリケーション（１）に関するアクセスコードリスト（１１）に存在するかどうかを検査するステップと、
   前記アクセスコードが前記アクセス制御リスト（１１）に存在しない場合、前記アクセス制御リスト（１１）の外側にある外部ソース（１２、１３）から前記アクセスコードを取り出すステップと、
   前記アクセスコードが存在する場合、前記アドオンデータファイル（４）へのアクセスを提供するステップと
   を含む方法。
2. 前記アドオンデータファイル属性はファイルフォーマット仕様を含み、
   前記ファイルフォーマット仕様を使用することによって、前記入力／出力命令が前記アドオンデータファイル（４）への前記アクセスを要求するかどうかを判定するステップをさらに含む、請求項１に記載の方法。
3. 連続して得られた前記アクセスコードを前記アクセスコードリスト（１１）に格納するステップをさらに含む、請求項１又は２に記載の方法。
4. 前記アドオンデータファイル（４）を暗号化するステップと、
   前記アドオンデータファイル（４）が前記ソフトウェアアプリケーションによって要求される場合、前記アクセスコードによって前記アドオンデータファイル（４）を復号するステップと
   をさらに含む、請求項１、２又は３に記載の方法。
5. ユーザによる前記アクセスコードの手動入力を要望するステップをさらに含む、請求項１〜４のいずれかに記載の方法。
6. 前記外部ソースとして有効化サーバ（１２）に接続するステップと、
   前記アクセスコードは前記有効化サーバ（１２）上で入手可能かどうかを検査するステップと
   をさらに含む、請求項１〜５のいずれかに記載の方法。
7. 前記アドオンデータファイル（４）とともに、前記ソフトウェアアプリケーションの使用を許可されるユーザに対するユーザ識別を提供するステップと、
   前記有効化サーバ（１２）に接続される間に、当該ソフトウェアアプリケーション（１）を実際に使用している当該ユーザに前記ユーザ識別が対応するかどうかを検査するステップと、
   前記ユーザ識別を有する前記ユーザにのみ前記アクセスを許諾するステップと
   をさらに含む、請求項６に記載の方法。
8. 前記ソフトウェアアプリケーション（１）が前記アドオンデータファイル（４）とともに動作することが許可されるコンピュータに対するハードウェア識別を提供するステップと、
   前記有効化サーバ（１２）に接続される間に、前記ソフトウェアアプリケーション（１）が目下動作中である当該コンピュータに前記ハードウェア識別が対応するかどうかを検査するステップと、
   前記ハードウェア識別を有する前記コンピュータにのみ前記アクセスを許可するステップと
   をさらに含む、請求項１〜６のいずれか１項に記載の方法。
9. 前記ソフトウェアアプリケーション（１）はコンピュータゲームであり、前記アドオンデータファイル（４）はレベルファイル及び／又はマップファイル及び／又はスタイルファイル及び／又は拡張ファイルである、請求項１〜８のいずれか１項に記載の方法。
10. ソフトウェアアプリケーション（１）によって使用される、アドオンデータファイル属性を有するアドオンデータファイル（４）へのアクセスを管理するシステムであって、
    前記アドオンデータファイル（４）に対するアクセスコードを生成するアクセスコード生成部と、
    前記ソフトウェアアプリケーション（１）に関するアクセスコードリスト（１１）と、
    前記アクセスコードリスト（１１）の外側に、前記アクセスコードが得られる外部ソース（１２、１３）と、
    前記ソフトウェアアプリケーションのための別個の制御ロジック（２）であって、
    前記ソフトウェアアプリケーション（１）の許可使用を検査し、
    前記アドオンデータファイル属性を有するデータファイルへのアクセスが前記ソフトウェアアプリケーション（１）によって要求されるかどうか、コードレイヤのアプリケーションプログラミングインターフェース（ＡＰＩ、１３）への前記ソフトウェアアプリケーションの入力／出力命令を検査し、
    前記入力／出力命令が前記アドオンデータファイル（４）のアクセスを要求する場合、前記アドオンデータファイル（４）にアクセスするための前記アクセスコードが前記アクセスコードリスト（１１）に存在するかどうかを検査し、
    前記アクセスコードが前記アクセスコードリスト（１１）に存在しない場合、前記アクセスコードが前記外部ソース（１２、１３）から獲得可能であるかどうかを検査し、
    前記アクセスコードが存在する場合、前記アドオンデータファイル（４）へのアクセスを提供する別個の制御ロジック（２）と
    を備えるシステム。
11. 前記ソフトウェアアプリケーション（１）は、前記ソフトウェアアプリケーション（１）と前記別個の制御ロジック（２）とが１つの処理（３）において動作するように、前記別個の制御ロジック（２）と組み合わされる、請求項１０に記載のシステム。
12. 前記アクセスコードを得るための前記外部ソースとしてグラフィカルユーザインターフェース（ＧＵＩ、１３）をさらに備える、請求項１０又は１１のいずれか１項に記載のシステム。
13. 前記グラフィカルユーザインターフェース（１３）は前記制御ロジックから分離される、請求項１２に記載のシステム。
14. 前記検査中に前記制御ロジック（２）が接続される、前記外部ソースである有効化サーバ（１２）と、
    前記アクセスコードが前記有効化サーバ（１２）上に存在するかどうかを検査する前記制御ロジック（２）と
    をさらに備える、請求項１０〜１３のいずれか１項に記載のシステム。
15. 前記制御ロジック（２）は、前記アドオンデータファイルが暗号化バーションで存在する場合、前記アドオンデータファイル（４）を復号する、請求項１０〜１４のいずれか１項に記載のシステム。
16. ランタイム中に前記アドオンデータファイル（４）を使用する前記ソフトウェアアプリケーション（１）と、
    前記アドオンデータファイル（４）への前記ソフトウェアアプリケーション（１）のアクセスを制御する前記コードレイヤであって、アプリケーションプログラミングインターフェース（ＡＰＩ、６）を提供する前記コードレイヤと、
    前記別個の制御ロジック（２）と前記ソフトウェアアプリケーション（１）とが同一の処理（３）において動作するように、前記別個の制御ロジック（２）を前記ソフトウェアアプリケーション（１）にリンクさせるためのリンキングプログラムと
    を備える、請求項１０〜１５に記載のシステム。

Images