(57)【特許請求の範囲】
【請求項１】
サーバー発生アプリケーション使用ポリシーを施行するための電子装置において、
マシン上でアプリケーションを実行するためにユーザを許可する許可要求をサーバーへ送信する手段と、
前記サーバーから第１の許可ファイル(1004)を受信する手段であって、その第１の許可ファイルは、マシンとユーザとの間の関連性を含むと共に、ユーザに関連した第１の許可解除カウントも含むものである手段と、
マシンにおけるユーザの許可解除から生じそしてユーザがマシンにおいて許可されないことを指示する第２の許可ファイルを、許可解除要求(1220)に応答して、前記サーバーから受信する手段と、
を備え、前記第２の許可ファイルの受信に続いて、前記第２の許可ファイルは、前記第２の許可ファイルの受信前に作られた前記第１の許可ファイルのコピーに置き換えられ、
更に、前記アプリケーションを購入するための購入要求に応答して、アプリケーション購入領収書(1002)を前記サーバーから受信する手段であって、そのアプリケーション購入領収書(1002)は、前記許可解除要求を反映する第２の許可解除カウントを含むものである手段と、
前記アプリケーション購入領収書(1002)で指定された前記第２の許可解除カウントを前記置き換えられた第１の許可ファイルで指定された前記第１の許可解除カウントと比較するための手段(1112)と、
前記第２の許可解除カウントが前記第１の許可解除カウントより大きいときには前記アプリケーションの使用を拒絶する手段と、
を備えた電子装置。
【請求項２】
マシン上でユーザを許可解除するための許可解除要求を、ユーザ入力インターフェイスを経て受信する手段と、
前記許可解除要求を前記サーバーへ送信する手段と、
を更に備えた請求項１に記載の電子装置。
【請求項３】
ユーザのためのアプリケーションを購入する購入要求を、ユーザ入力インターフェイスを経て受信する手段と、
ユーザの識別を含む前記購入要求を前記サーバーへ送信する手段と、
を更に備えた請求項１に記載の電子装置。
【請求項４】
前記アプリケーション購入領収書が有効であることを検証する手段と、
前記第１の許可ファイルが有効であることを検証する手段と、
前記アプリケーション購入領収書で指定されたユーザが前記第１の許可ファイルにあることを検証する手段と、
を更に備えた請求項１に記載の電子装置。
【請求項５】
前記許可要求の送信は、前記アプリケーション購入領収書で指定されたユーザが前記第１の許可ファイルに含まれないときに行われる、請求項４に記載の電子装置。
【請求項６】
アプリケーション購入領収書が有効であることを検証する前記手段は、更に、
前記アプリケーション購入領収書に基づいて第１の署名を発生する手段、
前記第１の署名が前記アプリケーション購入領収書に関連した第２の署名に一致することを検証する手段、
前記アプリケーション購入領収書のアプリケーション識別子が前記アプリケーションの識別子に一致することをチェックする手段、及び
前記アプリケーション購入領収書のアプリケーションバージョン番号が前記アプリケーションのバージョン番号に一致することをチェックする手段、
を含む請求項４に記載の電子装置。
【請求項７】
第１の許可ファイルが有効であることを検証する前記手段は、
前記第１の許可ファイルに基づいて第１の署名を発生する手段、
前記第１の署名が前記第１の許可ファイルに関連した第２の署名に一致することを検証する手段、及び
前記第１の許可ファイルにおける独特のクライアント識別子がマシンの独特の識別子に一致することをチェックする手段、
を更に含む請求項４に記載の電子装置。
【請求項８】
前記検証する手段の各々が成功したときに前記アプリケーションの使用を許す手段、及び
前記検証する手段の少なくとも１つが失敗したときに前記アプリケーションの少なくともある程度の使用を拒絶する手段、
を更に含む請求項７に記載の電子装置。
【請求項９】
マシンにおいてアプリケーションを実行するためにユーザを許可する許可要求を前記サーバーにより受信する手段、
使用ポリシーのもとで許された最大数のマシンにおいてユーザが許可されないことを検証するために許可レコードを前記サーバーによりチェックする手段、
前記最大数のマシンにおいてユーザが許可されないときにユーザを許可する手段であって、ユーザを許可することは、前記許可要求で指定されたマシンを識別するマシン識別子を含ませるように前記ユーザのための許可レコードのエントリを更新することを含むような手段、
前記第１の許可ファイル(1004)にアカウント特有の許可解除カウントを第１の許可解除カウントとして前記サーバーにより含ませる手段、及び
前記第１の許可ファイル(1004)を前記サーバーにより前記マシンへ返送する手段、
を更に含む請求項４に記載の電子装置。
【請求項１０】
前記許可解除要求を前記サーバーにより受信する手段、
前記許可解除要求に関連したユーザに関連した前記アカウント特有の許可解除カウントを前記サーバーによりインクリメントする手段、
前記第２の許可ファイルに前記アカウント特有の許可解除カウントを前記第２の許可解除カウントとして前記サーバーにより含ませる手段、及び
前記第２の許可ファイルを前記マシンへ前記サーバーにより返送する手段、
を更に含む請求項９に記載の電子装置。
【請求項１１】
前記アプリケーションを購入するための前記購入要求を前記サーバーによって受信する手段であって、ユーザが前記許可解除要求に関連しているような手段、
ユーザに関連したアカウント特有の許可解除カウントを第２の許可解除カウントとして前記アプリケーション購入領収書(1002)に前記サーバーにより含ませる手段、及び
前記アプリケーション購入領収書(1002)を前記サーバーにより前記マシンへ返送する手段、
を更に含む請求項１０に記載の電子装置。
【請求項１２】
ユーザ端末によってサーバー発生アプリケーション使用ポリシーを施行するための方法であって、
ユーザ端末が、
ユーザ端末上でアプリケーションを実行するためにユーザを許可する許可要求をサーバーへ送信する処理と、
前記サーバーから第１の許可ファイル(1004)を受信する処理であって、その第１の許可ファイルは、ユーザ端末とユーザとの間の関連性を含むと共に、ユーザに関連した第１の許可解除カウントも含むものである当該処理と、
ユーザ端末におけるユーザの許可解除から生じそしてユーザがユーザ端末において許可されないことを指示する第２の許可ファイルを、許可解除要求(1220)に応答して、前記サーバーから受信する処理とを含み、
前記第２の許可ファイルの受信に続いて、前記第２の許可ファイルは、前記第２の許可ファイルの受信前に作られた前記第１の許可ファイルのコピーに置き換えられ(1240)、更に、
前記アプリケーションを購入するための購入要求に応答して、アプリケーション購入領収書(1002)を前記サーバーから受信する処理であって、そのアプリケーション購入領収書(1002)は、前記許可解除要求を反映する第２の許可解除カウントを含むものである当該処理と、
前記アプリケーション購入領収書(1002)で指定された前記第２の許可解除カウントを前記置き換えられた第１の許可ファイルで指定された前記第１の許可解除カウントと比較する処理(1112)と、
前記第２の許可解除カウントが前記第１の許可解除カウントより大きいときには前記アプリケーションの使用を拒絶する処理と、
を実行する方法。
【請求項１３】
前記サーバーが、ユーザ端末においてアプリケーションを実行するためにユーザを許可する許可要求を受信する処理と、
前記サーバーが、使用ポリシーのもとで許された最大数のユーザ端末においてユーザが許可されないことを検証するために許可レコードをチェックする処理と、
前記サーバーが、前記最大数のユーザ端末においてユーザが許可されないときにユーザを許可する処理であって、ユーザを許可することは、前記許可要求で指定されたユーザ端末を識別するユーザ端末識別子を含ませるように前記ユーザのための許可レコードのエントリを更新することを含む当該処理と、
前記サーバーが、前記第１の許可ファイル(1004)にアカウント特有の許可解除カウントを第１の許可解除カウントとして含ませる処理と、
前記サーバーが、前記第１の許可ファイル(1004)を前記ユーザ端末へ返送する処理と、
を更に含む請求項１２に記載の方法。
【請求項１４】
前記サーバーが、前記許可解除要求を受信する処理と、
前記サーバーが、前記許可解除要求に関連したユーザに関連した前記アカウント特有の許可解除カウントをインクリメントする処理、
前記サーバーが、前記第２の許可ファイルに前記アカウント特有の許可解除カウントを前記第２の許可解除カウントとして含ませる処理と、
前記サーバーが、前記第２の許可ファイルを前記ユーザ端末へ返送する処理と、
を更に含む請求項１３に記載の方法。
【請求項１５】
前記サーバーが、前記アプリケーションを購入するための前記購入要求を受信する処理であって、ユーザが前記許可解除要求に関連付けられる当該処理と、
前記サーバーが、ユーザに関連したアカウント特有の許可解除カウントを第２の許可解除カウントとして前記アプリケーション購入領収書(1002)に含ませる処理と、
前記サーバーが、前記アプリケーション購入領収書(1002)を前記ユーザ端末へ返送する処理と、
を更に含む請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション使用ポリシーの施行に関するもので、より詳細には、コンピュータでのアプリケーションの無断実行を防止することに関する。
【０００２】
関連出願の相互参照：本出願は、２０１０年１０月１９日に出願された“APPLICATION USAGE POLICY ENFORCEMENT”と題する米国特許出願第１２／９０７，９１５号の優先権を主張するものであり、これは、引用としてここにそのまま組み入れられる。
【背景技術】
【０００３】
コンピュータソフトウェアの重要な特徴は、ソフトウェアを変更する必要なくソフトウェアの単一断片を複数のマシンにインストールできることである。これは、ソフトウェア開発者にとって好都合である。というのは、ソフトウェアをいったん開発すると、追加の作業をせずに、多数の異なるユーザに配布できるからである。又、ユーザにとっても好都合である。というのは、例えば、ユーザが新しいコンピュータを購入したときに、ソフトウェアをあるマシンから別のマシンへ移動できるからである。又、ソフトウェアの可搬性は、ユーザがソフトウェアの単一コピーを購入して、それを複数のコンピュータに同時にインストールできるようにもするが、これは、状況によっては望ましからぬことである。例えば、あるソフトウェアは、製造するのに非常に費用がかかり、ターゲットとする市場も非常に小さい。この場合には、無断コピーがあると、開発者がその費用を取り戻す上で妨げとなる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
無断コピーを防止するため、ソフトウェア開発者は、多くの場合、ソフトウェアのインストールごとに独特の製品キーを要求するインストールプロセスを使用する。この解決策は、無断コピーを防止するが、ユーザがあるマシンから別のマシンへ移行するのを困難にする。更に、この解決策は、ユーザが特定の数のマシンにソフトウェアをインストールするのを許すというポリシーをソフトウェア開発者が有するときには厄介なものとなる。
【課題を解決するための手段】
【０００５】
本開示の付加的な特徴及び効果は、以下の説明に述べられそして一部分はその説明から明らかであり、或いはここに開示する原理の実施により学習することができよう。本開示の特徴及び効果は、特許請求の範囲に特に指摘された手段及び組み合わせにより実現され且つ得られる。本開示のこれら及び他の特徴は、以下の説明及び特許請求の範囲から完全に明らかとなるか、或いはここに述べる原理の実施により学習することができる。
【０００６】
ここに開示するのは、アプリケーション使用ポリシーを施行するシステム、方法、及び非一時的コンピュータ読み取り可能な記憶媒体である。
【０００７】
アプリケーションサーバーの実施形態では、この方法を実施するように構成されたシステムは、購入要求を受け取るように構成される。その要求に応答して、システムは、その購入に対する購入証明領収書を生成する。その領収書は、購入トランザクションに関する種々の情報断片、例えば、ユーザのアカウント識別子、アプリケーション識別子、アプリケーションバージョン番号、購入日付、及びアプリケーションのペアレンタルコントロールレーティング(parental control rating)を含む。システムは、領収書に署名し、それをアプリケーションとバンドルし、そしてそのアプリケーションバンドルを要求側クライアント装置へ送信する。
【０００８】
クライアント装置の実施形態では、ユーザがマシンにアプリケーションを使用したいとき、システムは、使用が使用ポリシーを遵守したものであることを検証できる。ユーザがアプリケーションを購入すると、アプリケーション購入証明領収書がアプリケーションと共に含まれる。購入したアプリケーションを特定のクライアント装置で実行するには、購入したアプリケーションに関連したアカウント識別子がクライアント装置において許可されねばならない。各クライアント装置は、そのクライアントマシンに対するクライアント識別子、及びそのクライアント装置でアプリケーションを使用することが許可された全てのユーザ識別子を特定できる許可ファイルを維持する。ユーザがアプリケーションの使用を試みると、システムは、購入証明領収書及び許可ファイルが有効であることを検証する。更に、システムは、購入証明領収書で指定されたユーザが許可ファイル内にあることを検証する。ある実施形態では、ユーザが許可ファイルにない場合には、システムは、ユーザを許可する要求をする。
【０００９】
規範的な施行メカニズムとして、システムは、ユーザがアプリケーション使用ポリシーを回避するのを防止するよう試みるために許可解除カウンタを備えている。許可解除カウントフィールドがアプリケーション購入証明領収書及び許可ファイルに含まれる。許可解除カウントも、システムによって維持される。ユーザがアプリケーションを購入する要求をすると、システムは、ユーザの現在許可解除カウントを含むその購入のための購入証明領収書を構成する。ユーザがアプリケーションの使用を試みると、システムは、購入証明領収書及び許可ファイルが有効であることを検証する。更に、システムは、購入証明領収書で指定されたユーザが許可ファイル内にあることを検証する。最終的に、システムは、領収書の許可解除カウントが許可ファイルの許可解除カウント以下であることを検証する。この施行メカニズムは、アプリケーション使用ポリシーの期間に基づいてユーザがアプリケーションを設定回数転送する簡単な方法を提供することができる。
【００１０】
本開示の前記及び他の効果並びに特徴をどのようにして得るか説明するため、添付図面に示す特定の実施形態を参照して、前記で簡単に述べた原理をより詳細に説明する。これらの図面は、本開示の規範的な実施形態しか示さず、それ故、本発明の範囲を限定するものではないことを理解した上で、ここでは添付図面の使用によりそれらの原理を更に詳細に説明する。
【図面の簡単な説明】
【００１１】
【図１】アプリケーション配布及び使用のための規範的システム構成を示す。
【図２】規範的なアプリケーション購入を示す。
【図３】規範的なアプリケーション購入領収書を示す。
【図４】アプリケーション購入のための規範的な方法実施形態を示す。
【図５】規範的な許可ファイルを示す。
【図６】規範的な許可要求を示す。
【図７】購入時に許可するための規範的なシナリオを示す。
【図８】アプリケーション起動時に許可するための規範的方法を示す。
【図９】アプリケーション検証のための規範的な方法実施形態を示す。
【図１０】許可解除カウンタを伴う規範的なアプリケーション購入領収書及び許可ファイルを示す。
【図１１】許可解除カウンタを使用するアプリケーション検証のための規範的な方法実施形態を示す。
【図１２】規範的な許可解除カウンタ使用シナリオを示す。
【図１３】規範的なシステム実施形態を示す。
【発明を実施するための形態】
【００１２】
本開示の種々の実施形態を以下に詳細に述べる。特定の具現化について述べるが、これは、単なる例示のためであることを理解されたい。当業者であれば、本開示の精神及び範囲から逸脱せずに他の要素及び構成が使用できることが明らかであろう。本開示は、ユーザを表わす特性に基づいてユーザに与えられるターゲットとするコンテンツ、及び／又はそのターゲットとするコンテンツの１つ以上のアイテムとユーザとの相互作用を選択する改良された方法の必要性に向けられる。
【００１３】
ここに開示するシステム及び方法は、コンピュータにおいてアプリケーション使用ポリシーを施行するのに特に有用である。アプリケーション配布及び使用のための規範的なシステム構成１００が図１に示されており、電子装置１０２、１０４は、ネットワーク１１０を経て電子アプリケーションディストリビュータ１１２と通信する。このシステムは、図１に示すように、ワイドエリアネットワーク上で使用するように構成される。しかしながら、本発明の原理は、電子装置の相互通信を容易にする種々様々なネットワーク構成に適用できる。例えば、図１のシステム１００の各要素は、ネットワークにおいて局所的に又は分散的に具現化される。
【００１４】
システム１００において、ユーザターミナル１０２及び１０４は、直接的及び／又は間接的通信を経てアプリケーションディストリビュータ１１２と相互作用して、アプリケーションとしても知られたコンピュータプログラムを得る。任意の数又は形式のユーザターミナルがアプリケーションディストリビュータ１１２と相互作用する。例えば、ユーザターミナル１０２は、デスクトップコンピュータ；ラップトップコンピュータ；複数の又は非持続的なネットワークセッションを使用して接続するハンドヘルド通信装置、例えば、移動電話、スマートホン、タブレット又は任意の他の形式の装置；等である。ユーザターミナル１０２は、購入要求のような要求をアプリケーションディストリビュータ１１２へ行う。アプリケーションディストリビュータ１１２は、それに応答して、その要求されたコンテンツを要求側ユーザターミナル１０２へ供給するか、又はその要求を拒絶する。例えば、ユーザターミナル１０２の側で充分な支払方法を与えることに失敗したために要求が拒絶される。
【００１５】
アプリケーション使用ポリシーの施行を促進するために、アプリケーションディストリビュータは、購入されたアプリケーションと共に、アプリケーション購入証明領収書を要求側ユーザターミナルに与える。図２は、規範的なアプリケーション購入２００を示す。規範的なアプリケーション購入２００において、ユーザターミナル１０２は、アプリケーションディストリビュータ１１２へ購入要求をなす。購入要求の一部分として、ユーザターミナル１０２は、要求側ユーザのためのアカウント情報を与える。ある構成では、アカウント情報は、ユーザ名及びパスワードである。他の構成では、アプリケーションディストリビュータ１１２との個別の相互作用としてアカウント許可が行われ、従って、アカウント情報は、ＤＳｉｄのような独特のアカウント識別子である。購入要求を受け取ると、アプリケーションディストリビュータ１１２は、アプリケーション２０８と、アプリケーション購入証明領収書２１０とで構成されたアプリケーションバンドル２０６を生成する。アプリケーションディストリビュータ１１２は、次いで、アプリケーションバンドル２０６をユーザターミナル１０２へ配信する。以下に詳細に述べるように、アプリケーション購入証明領収書は、アプリケーションに対する使用ポリシーを施行する上で助けとなるように後で使用される。
【００１６】
購入トランザクションは、アプリケーションを取得するための受信者のある種のトランザクションを含み、必ずしも金銭又は他の価値の交換を要求するものではない。購入トランザクションは、第三者がアプリケーションを贈り物として受信者に与えることを含み、又は受信者は、アプリケーションに対する交換においてクーポン、プロモーションコード又は同様の手段で弁済することができる。あるケースでは、無料アプリケーションに対して購入要求をなすことができる。アプリケーションを取得するために金銭の交換が要求されるかどうかに関わらず、アプリケーションディストリビュータは、アプリケーションと共にアプリケーション購入証明領収書を与えることができる。
【００１７】
アプリケーション購入証明領収書は、図３において規範的な購入証明領収書３００に示されたように、種々の情報を含む。アプリケーション購入証明領収書は、図３に示すものより多くの又は少ない情報を含んでもよい。購入証明領収書本体３０２は、アプリケーションを購入したユーザに関連した種々のアカウント情報を含む。ユーザは、個人、個人のグループ又は組織である。アカウント情報は、ユーザ名のようなユーザＩＤを含む。又、アカウント情報は、ＤＳｉｄのような、ユーザの独特のアカウント識別子も含む。ある構成では、プレーンテキストＤＳｉｄを含むのではなくて、購入証明領収書本体３０２は、ＤＳｉｄの独特の表現を含む。例えば、独特の表現は、ＤＳｉｄの一方向表現、例えば、ｆ（ＤＳｉｄ）である。あるケースでは、独特の表現は、領収書及び／又はユーザプライバシーのセキュリティを改善するのに使用できる。購入証明領収書本体３０２は、購入したアプリケーションに関する種々の情報断片も含む。例えば、購入証明領収書本体３０２は、購入したアプリケーションのＩＤ、バージョン番号、及びペアレンタルコントロールレーティングを含む。あるケースでは、アプリケーションに関する付加的な情報は、アプリケーション署名のように、領収書に含ませることができる。更に、購入証明領収書本体３０２は、購入日付を含む。
【００１８】
ある構成では、アプリケーション購入証明領収書本体３０２は、付加的な及び／又は代替え的な情報を含むことができる。更に、購入証明領収書３００内の情報の編成は、システムの構成と共に変化し得る。１つの変形例では、サーバーは、アプリケーション購入証明領収書３００の完全な又は部分的なコピーを保持する。
【００１９】
ある構成では、購入証明領収書３００は、ファイルレイアウトを理解できるユーザであれば誰でも読むことのできるプレーンテキストである。購入証明領収書３００の無断変更を防止し及び／又は検出するために、購入証明領収書３００は、領収書署名３０４を含む。この領収書署名３０４は、購入証明領収書の無断変更を検出するのに使用できるデジタル署名である。例えば、アプリケーションディストリビュータ１１２は、暗号ハッシュ関数を使用して、購入証明領収書本体３０２のデジタル署名を発生する。ある構成では、アプリケーションディストリビュータ１１２は、パブリックキーシステムを使用して、デジタル署名を発生する。このケースでは、アプリケーションディストリビュータ１１２は、そのプライベートキーを使用して、領収書署名３０４を発生する。次いで、ユーザターミナル、アプリケーションディストリビュータ、及び／又はアプリケーションディストリビュータのパブリックキーにアクセスできる他の装置は、領収書３００を検証することができる。或いは又、アプリケーションディストリビュータ１１２は、プライベートキーシステムを使用して、領収書署名３０４を発生してもよい。このケースでは、アプリケーションディストリビュータ１１２がそのプライベートキーを共有しない限り、領収書３００を検証できるのはアプリケーションディストリビュータだけとなる。
【００２０】
図４は、購入証明領収書を含むアプリケーション購入のための規範的方法４００のステップを示すフローチャートである。明瞭化のために、この方法は、図１に示すような規範的システムに関して説明する。図４には特定のステップが示されているが、他の実施形態では、方法のステップが、図示されたものより多くても少なくてもよい。この図及び他の図に示す方法ステップは、図示された順序又は他の組み合わせで具現化されてもよいし、或いは他の順序又は組み合わせで具現化されてもよい。
【００２１】
種々のポイントにおいて、アプリケーションディストリビュータ１１２は、アプリケーションを購入する要求をユーザから受け取る（４０２）。その購入要求は、アプリケーションディストリビュータ１１２へアクセスできるユーザターミナルから到来する。上述したように、購入要求は、トランザクションを促進するために使用できる要求側ユーザのアカウント情報、例えば、ユーザのアカウント識別子を含む。
【００２２】
購入要求に応答して、アプリケーションディストリビュータ１１２は、図３の領収書３００のようなアプリケーション購入証明領収書を構成する（４０４）。アプリケーション購入証明領収書は、トランザクションにとって独特のものである。例えば、ユーザがアプリケーションを以前に購入した場合でも、この購入要求に関連した購入証明領収書は、異なるものとなる。しかしながら、ある構成では、購入証明領収書は、トランザクションではなく、ユーザ、アプリケーションの対にとって独特なものとなる。アプリケーション購入証明領収書を構成した後に、アプリケーションディストリビュータ１１２は、アプリケーション購入領収書及びアプリケーションに基づいてアプリケーションバンドルを生成し（４０６）、そしてそのアプリケーションバンドルを要求側ユーザへ送る（４０８）。
【００２３】
アプリケーションを購入した後に、そのアプリケーションを複数のユーザターミナルで使用することができる。ユーザがこの能力を乱用するのを防止するため、アプリケーション開発者及び／又はアプリケーションディストリビュータは、アプリケーションを一度に使用できるユーザターミナルの数を制限する使用ポリシーを構成することができる。例えば、アプリケーションコストが１０ドルであると仮定する。ユーザはアプリケーションを購入し、次いで、アプリケーションのコピーを９人の友人に１ドルで売ることができる。１０人のユーザは、各々、１０ドルのアプリケーションのコピーを１ドルで入手することができる。あるケースでは、アプリケーション開発者は、このシナリオを認めるが、他のケースでは、そのような行動は、開発者が開発コストを取り戻すのを妨げる。そのような行動を抑制するために、コピーの回数を、例えば、５台のマシンに限定するためのポリシーを確立することができる。ユーザがアプリケーションを指定台数のマシンでしか実行しないよう保証する１つの方法は、ユーザがアプリケーションの使用を希望する各マシンをユーザが許可するようにさせることである。
【００２４】
ユーザのマシンに常駐できる許可ファイルを使用して、ユーザ許可を促進することができる。図５は、規範的な許可ファイル５００を示す。この許可ファイル５００は、許可ファイル本体５０２を含む。この許可ファイル本体５０２は、許可ファイル５００に関連したマシンに対する独特のマシン識別子を含む。この独特のマシン識別子は、ユーザターミナルにリンクできる識別子である。例えば、コンピュータの種々のハードウェアコンポーネントは、シリアル番号のような独特の識別子に関連付けることができる。１つ以上のこれらシリアル番号を使用して、独特のマシン識別子を生成することができる。
【００２５】
許可ファイル本体５０２は、１つ以上の独特のアカウント識別子、例えば、ＤＳｉｄも含む。許可ファイル５００に含まれたアカウント識別子は、マシンにおいて購入したアプリケーションを使用することが許可されたユーザを指示する。ある構成では、プレーンテキストＤＳｉｄを含むのではなく、許可ファイル本体５０２は、ＤＳｉｄの独特の表現を含む。例えば、独特の表現は、ＤＳｉｄの一方向表現、例えば、ｆ（ＤＳｉｄ）である。あるケースでは、独特の表現は、領収書及び／又はユーザプライバシーのセキュリティを改善するのに使用される。
【００２６】
ある構成では、許可ファイル本体５０２は、付加的及び／又は代替え情報を含む。更に、許可ファイル５００内の情報の編成は、システムの構成と共に変化する。
【００２７】
ある構成では、許可ファイル５００は、ファイルレイアウトを理解できるユーザであれば誰でも読むことのできるプレーンテキストである。許可ファイル５００の無断変更を防止し及び／又は検出するために、許可ファイル５００は、許可ファイル署名５０４を含む。この許可ファイル署名５０４は、許可ファイルの無断変更を検出するのに使用できるデジタル署名である。例えば、アプリケーションディストリビュータ１１２は、暗号ハッシュ関数を使用して、許可ファイル本体５０２のデジタル署名を発生する。ある構成では、アプリケーションディストリビュータ１１２は、パブリックキーシステムを使用して、デジタル署名を発生する。このケースでは、アプリケーションディストリビュータ１１２は、そのプライベートキーを使用して、許可ファイル署名５０４を発生する。次いで、ユーザターミナル、アプリケーションディストリビュータ、及び／又はアプリケーションディストリビュータのパブリックキーにアクセスできる他の装置は、許可ファイル５００を検証することができる。或いは又、アプリケーションディストリビュータ１１２は、プライベートキーシステムを使用して、許可ファイル署名５０４を発生してもよい。このケースでは、アプリケーションディストリビュータ１１２がそのプライベートキーを共有しない限り、許可ファイル５００を検証できるのはアプリケーションディストリビュータだけとなる。
【００２８】
アプリケーションディストリビュータ、又はシステム内でユーザを許可する役割を果たす他の装置に、許可要求を行うことができる。許可ファイルは、どのユーザが特定のユーザターミナルでアプリケーションを実行することが許されたか追跡するために使用され、一方、サーバーは、各ユーザに許可されたマシンの台数及び／又は厳密なマシンを追跡するための許可記録を維持することができる。サーバーの許可記録は、ユーザが、使用ポリシーにより許された以上のマシンで許可されないことを保証するために使用される。
【００２９】
図６は、規範的なユーザ許可シナリオ６００を示す。マシンにおいてユーザを許可するために、サーバー６０６は、許可ファイル６０２及びユーザの独特のアカウント識別子６０４を受け取る。次いで、サーバー６０６は、許可レコード６０８をチェックして、使用ポリシーのもとで許可された最大数のマシンにおいてユーザがまだ許可されていないことを検証する。この例では、ユーザＤＳｉｄ８は、限界より低い１つのマシンのみで許可されており、従って、サーバー６０６は、ユーザを許可することができる。ユーザを許可するために、サーバー６０６は、許可ファイル６０２のマシン識別子、即ちＭ１を含ませるようユーザの許可記録のエントリを更新する。これは、許可レコード６１０を生成する。又、サーバーは、ユーザのアカウント番号、即ちｆ（ＤＳｉｄ８）を追加し、そしてファイルを再署名することにより、許可ファイルを更新する。次いで、サーバー６０６は、その更新された許可ファイル６１２をユーザのマシンへ返送する。ある構成では、サーバー６０６は、許可レコードに他の情報を維持することができる。これらステップの全部又は一部分を使用する他の許可方法も考えられる。
【００３０】
ある構成において、使用ポリシーは、全てのユーザ及び全てのアプリケーションにわたってスタティックであるか、或いはユーザ特有及び／又はアプリケーション特有である。例えば、使用ポリシーは、いつでも５台までのマシンにおいてユーザが購入したアプリケーションを使用することが許可されるよう設計される。しかしながら、システムも、個々のアプリケーションに対して使用ポリシーを指定できるように構成される。例えば、あるアプリケーションは、ユーザが１０台のマシンにおいてアプリケーションを使用することを許し、一方、別のアプリケーションは、ユーザが４台のマシンにおいてアプリケーションを使用することしか許さない。可変の使用ポリシースキームをサポートするため、サーバー６０６は、許可レコードに付加的な情報を記憶することが必要となる。
【００３１】
ある構成では、ユーザがアプリケーションを購入するときにユーザ許可が行われる。図７は、購入時に許可を行うための規範的なシナリオ７００を示す。方法７００において、ユーザターミナル１０２は、アプリケーションディストリビュータ１１２へ購入要求を行う。ＤＳｉｄのようなアカウント情報に加えて、購入要求は、ユーザターミナル１０２に常駐する許可ファイル７０６を含む。アプリケーションディストリビュータ１１２は、図４の方法４００を使用してアプリケーションバンドル７０８を生成し、そして図６の許可方法６００を遂行して、許可レコードを更新し、そして許可ファイル７１０を形成する。次いで、アプリケーションディストリビュータ１１２は、アプリケーションバンドル及び更新された許可ファイル７１０を要求側ユーザターミナル１０２へ送信する。ある構成では、アプリケーションディストリビュータ１１２は、許可要求に対する仲介者として働いて、許可要求を別の装置又はサーバーへ単に通し、その別の装置又はサーバーがアプリケーションディストリビュータ１１２へ許可ファイルを返送する。あるケースでは、ユーザは、購入要求を行う前にユーザターミナル１０２において許可される。このケースでは、アプリケーションディストリビュータ１１２は、許可ファイルを変更せずに返送するか、又はファイルを全く返送しない。ある構成では、ユーザターミナルは、サーバーへ許可要求を行うことなくユーザがマシンに対して許可されたことを決定する。
【００３２】
あるケースでは、購入時の許可が不必要である。というのは、ユーザは、アプリケーションを購入したところのマシンにおいてアプリケーションを使用する意図がないためである。例えば、ユーザは、家では低速のインターネット接続を有するが、仕事場では非常に高速の接続をもつことがある。あるケースでは、インターネット接続の速度は問題にならないが、大きなアプリケーションの場合には、ネットワーク接続が低速であると、ユーザが特定のアプリケーションを購入する妨げとなる。ユーザの購入経験を改善するために、ユーザは、仕事場でアプリケーションの購入を決断し、そしてアプリケーションをユーザの家のコンピュータへ転送することができる。例えば、ユーザは、アプリケーションを、例えば、ＣＤ−ＲＯＭ、ＤＶＤ、ＵＳＢドライブ、等のディスクへ転送し、次いで、アプリケーションを家のコンピュータへ転送するか、或いはユーザは、例えば、イーサネット接続を通して、ユーザの仕事場のコンピュータと家のコンピュータとの間に直接的な高速接続を確立する。更に、ユーザがアプリケーションを２つ以上のマシンへコピーするのを許すために、ユーザがアプリケーションの使用を試みるときに許可を行うことができる。
【００３３】
図８は、アプリケーション起動時に許可を行うための規範的なシナリオ８００を示す。このシナリオにおいて、ユーザは、ユーザターミナル１０２から購入要求を行う。その購入要求は、アプリケーションディストリビュータ１１２へ送られ、そこで、図４の方法４００を使用してアプリケーションバンドル８０６が準備される。そのアプリケーションバンドル８０６は、ユーザターミナル１０２へ送られる。ある時点で、アプリケーションバンドル８０６は、ユーザターミナル１０４へコピーされ、ユーザは、アプリケーションの使用を試みる。アプリケーションの起動時に、ユーザターミナルは、許可要求をサーバー６０６へ送信する。ある構成では、サーバー６０６及びアプリケーションディストリビュータ１１２は、同じものである。しかしながら、他のケースでは、サーバー６０６及びアプリケーションディストリビュータ１１２は、異なるものである。許可要求の一部分として、サーバー６０６は、許可ファイル８１２及びユーザのアカウント識別子８１４を受け取る。サーバー６０６は、図６の許可方法６００を遂行し、そして更新された許可ファイル８１６をユーザターミナル１０４へ返送する。ここで、ユーザがマシンにおいて許可されると、アプリケーションを使用することができる。ある構成では、ユーザは、マシンでアプリケーションを使用するように既に許可されていてもよい。このケースでは、許可ファイルへの更新が要求されない。更に、あるケースでは、ユーザターミナルは、サーバーへの許可要求を行わずにユーザが許可されたと決定する。
【００３４】
図６のユーザ許可シナリオ６００は、ユーザが指定台数以上のマシンでアプリケーションを実行することが許可されるのを防止するだけである。購入時点で生成されるアプリケーション購入証明領収書を合体することにより、所与の時間に特定数のマシン又はインスタンスに対して特定アプリケーションの使用を制限するアプリケーション使用ポリシーをアプリケーションの検証で施行することができる。例えば、アプリケーションは、単一の物理的ホストマシンに全て常駐する５つの異なるゲストバーチャルマシンにおける５つの個別のインスタンスに制限される。ユーザがアプリケーションを購入するときに、アプリケーションと共にアプリケーション購入領収書が含まれる。購入したアプリケーションを特定のマシンに使用するために、購入証明領収書のアカウント識別子がマシンにおいて許可されねばならない。上述したように、各マシンは、マシンに対するマシン識別子、及びマシンでアプリケーションを実行することが許可されたユーザの全アカウント識別子を指定できる単一の許可ファイルを維持することができる。購入証明領収書のアカウント識別子が許可ファイルに含まれる場合には、マシンにおいてアプリケーションを使用することができる。しかしながら、アプリケーションに関連したユーザがマシンにおいて許可されない場合には、ユーザは、図６の方法６００のような許可方法を使用して許可することができる。購入証明領収書及び許可ファイルは、両方とも、購入証明領収書及び／又は許可ファイルの無断変更を防止すると共に、領収書がアプリケーションに属し且つ許可ファイルがマシンに属することを保証するために検証される。
【００３５】
図９の規範的なアプリケーション検証方法９００は、購入ユーザを指定台数のマシンに制限することに向けられたアプリケーション使用ポリシーを施行するのに使用される。検証方法９００は、図３のアプリケーション購入証明領収書３００及び図５の許可ファイル５００を使用することができる。明瞭化のために、方法９００は、図１に示す規範的システム１００に関して説明する。図９には特定のステップが示されているが、他の実施形態では、図示されたステップより多くの又はそれより少ないステップが方法に含まれてもよい。
【００３６】
アプリケーション検証方法は、ユーザがアプリケーションを起動するたびに使用され、アプリケーションが常駐するマシンによりローカルに遂行される。しかしながら、システムは、アプリケーションの検証があまり頻繁に行われず、アプリケーションの最初の起動時に行われるように構成することができる。更に、アプリケーションの検証は、サーバーに検証要求を行うことにより遂行されてもよいし、或いはローカルアクション及びリモートアクションの組み合わせであってもよい。
【００３７】
アプリケーションの起動時に、ユーザターミナル１０２は、購入証明領収書３００及び許可ファイル５００に基づいてアプリケーションを検証する要求を受信する（９０２）。アプリケーション検証の一部分として、ユーザターミナル１０２は、領収書の署名が有効であることを最初にチェックすることにより、購入証明領収書３００を検証する（９０４）。署名が有効でない場合には、領収書が変更されたおそれがあり、従って、検証プロセスが中止されて検証が失敗となる。署名が有効である場合には、ユーザターミナル１０２は、領収書のアプリケーション識別子が、検証されるアプリケーションの識別子に一致するかどうかチェックする（９０６）。一致しない場合には、検証が失敗となる。アプリケーション識別子が一致する場合には、ユーザターミナル１０２は、領収書のアプリケーションバージョン番号が、検証されるアプリケーションのバージョン番号に一致するかどうかチェックする（９０８）。バージョン番号が一致しない場合には、検証方法が失敗となり、さもなければ、検証が続けられる。
【００３８】
また、検証方法９００は、許可ファイル５００の検証も含む。許可ファイル５００を検証するために、ユーザターミナル１０２は、ファイルの署名が有効であるかどうかチェックする（９１０）。署名が有効でない場合には、許可ファイルが変更されているおそれがあり、従って、検証プロセスが中止されそして検証が失敗となる。署名が有効である場合には、ユーザターミナル１０２は、許可ファイルのマシン識別子がユーザターミナル１０２の識別子に一致するかどうかチェックする（９１２）。一致しない場合には、検証が失敗となる。マシン識別子が一致する場合には、検証が続けられる。
【００３９】
構成によっては、ステップ９０４、９０６及び９０８は、ステップ９１０及び９１２の前、その後、又はそれと並列に遂行されてもよい。更に、ステップ９０４−９１２は、全く遂行されなくてもよいが、それらステップを遂行することにより、ファイルが変更されずにアプリケーション及びマシンに対応するという保証レベルを得ることができる。領収書３００及び許可ファイル５００を検証した後に、ユーザターミナル１０２は、領収書のアカウント番号、例えば、ｆ（ＤＳｉｄ）が許可ファイルにあるかどうかチェックする（９１４）。もしそうであれば、アプリケーションを購入したユーザは、マシンにおいて許可され、従って、アプリケーションを起動することができる（９１６）。アプリケーションを購入したユーザがまだ許可されていない場合には、ユーザターミナル１０２は、アプリケーションディストリビュータ１１２へ許可要求を行う（９１８）。許可要求が成功した場合には（９２０）、アプリケーションを起動することができ（９１６）、さもなければ、検証は失敗となる。
【００４０】
ある構成では、検証方法９００は、アプリケーションの中で行うことができる。このケースでは、検証失敗時に行われるアクションは、アプリケーション開発者に依存する。例えば、検証失敗時に、アプリケーションは、中止となる。或いは又、検証失敗時に、アプリケーションは、実行を継続できるが、限定された機能しか利用できない。更に、構成にもよるが、アプリケーションは、ユーザのための許可を要求できないこともある。
【００４１】
上述した検証方法９００を使用して、購入したアプリケーションに関連したユーザは、使用ポリシーで指定された台数のマシンにおいてアプリケーションを使用することができる。例えば、マシンの最大数が５である場合には、ユーザは、５台の異なるマシンにアプリケーションをコピーし、各マシンにおいて許可プロセスを通して進むことができる。ユーザが６番目のマシンにおいてアプリケーションの使用を希望する場合には、ユーザは、既に許可されたマシンの１つの許可を解除しなければならない。そのようにするために、ユーザは、許可されたマシンの１つから「許可解除」要求を送信することができる。或いは又、ある構成では、ユーザは、いずれかのマシンから「全許可解除」要求を送信し、ユーザに許可されている全てのマシンの許可を解除させることができる。マシンの許可を解除した後、ユーザは、第６番目のマシンに戻ってそれを許可することができる。この時点で、検証方法９００が成功する場合には、ユーザは、アプリケーションを使用することができる。
【００４２】
あるケースでは、ユーザが最大マシン使用ポリシーの回避を試みるかもしれない。ユーザがこれを試みる１つの方法は、次の通りである。購入したアプリケーションに関連したユーザが、最大数、例えば、５台のマシンにおいて既に許可されていると仮定する。許可を解放するため、ユーザは、マシンの許可を解除する。しかしながら、「許可解除」要求を発生する前に、ユーザは、マシンにおいて許可ファイルのコピーを作成する。許可解除の後に、ユーザは、許可ファイルをコピーして戻す。これで、マシンは、ユーザが許可を解除したのにユーザが許可されたと考える。
【００４３】
この回避攻撃に対処するために、許可解除カウントフィールドをアプリケーション購入証明領収書及び許可ファイルに追加することができる。更に、許可解除カウントをサーバーに維持することもできる。図１０は、許可解除カウントフィールドを伴う規範的な購入証明領収書１００２及び許可ファイル１００４を示す。許可ファイル１００４において、個別の許可解除カウントを、各許可アカウント識別子に関連付けることができる。ユーザがマシンの許可を解除するたびに、アカウント識別子に関連したサーバーの許可解除カウントをインクリメントすることができる。ユーザが新たなアプリケーションを購入するときに、ユーザに関連した許可レコードの許可解除カウントをアプリケーション購入証明領収書に含ませることができる。更に、ユーザがマシンを許可するときに、そのアカウント識別子に関連した許可解除カウントを許可ファイルに含ませることができる。
【００４４】
許可解除カウントは、アプリケーション検証方法に合体させることもできる。ユーザがアプリケーションの使用を試みるとき、検証方法は、検証方法９００で述べた全てのステップを遂行することができる。しかしながら、検証方法は、領収書の許可解除カウントが許可ファイルの許可解除カウント以下であることもチェックできる。このチェックが失敗した場合には、ユーザは、そのマシンにおいてアプリケーションを使用することが防止される。
【００４５】
図１１は、許可解除カウンタを使用する規範的なアプリケーション検証方法１１００を示す。この検証方法１１００は、図１０のアプリケーション購入証明領収書１００２及び許可ファイル１００４を使用する。明瞭化のために、方法１１００は、図１に示すような規範的システムに関して説明する。図１０には特定のステップが示されているが、他の実施形態では、図示されたものより多くの又は少ないステップが方法に含まれてもよい。
【００４６】
アプリケーション検証方法１１００は、ユーザがアプリケーションを起動するたびに使用され、アプリケーションが常駐するマシンによりローカルに遂行される。しかしながら、システムは、アプリケーションの検証があまり頻繁に行われず、例えば、アプリケーションの最初の起動時に行われるように構成することができる。更に、アプリケーションの検証は、サーバーに検証要求を行うことにより遂行されてもよいし、或いはローカルアクション及びリモートアクションの組み合わせであってもよい。
【００４７】
アプリケーション起動時に、ユーザターミナル１０２は、購入証明領収書１００２及び許可ファイル１００４に基づいてアプリケーションを検証する要求を受信する（１１０２）。ユーザターミナル１０２は、次いで、図９の９０４−９１２と同様のステップを使用して購入証明領収書１００２及び許可ファイル１００４が有効であることを検証する（１１０４−１１０６）。いずれかの有効確認段階が失敗した場合には、検証方法が中止となり、検証が失敗となる。構成にもよるが、ステップ１１０４は、ステップ１１０６の前、その後、又はそれと並列に遂行することができる。更に、ステップ１１０４及び１１０６は、全く遂行されなくてもよいが、それらステップを遂行することで、ファイルが変更されずにアプリケーション及びマシンに対応するという保証レベルを得ることができる。
【００４８】
領収書１００２及び許可ファイル１００４を検証した後、ユーザターミナル１０２は、領収書のアカウント番号、例えば、ｆ（ＤＳｉｄ）が許可ファイルにあるかどうかチェックする（１１０８）。もしそうであれば、アプリケーションを購入したユーザは、マシンにおいて許可され、そして検証は、許可解除カウントをチェックするように進む。アプリケーションを購入したユーザがまだ許可されていない場合には、ユーザターミナル１０２は、アプリケーションディストリビュータ１１２へ許可要求を行う（１１１０）。許可要求が成功である場合には（１１１４）、ユーザターミナル１０２は、許可解除カウントをチェックするように進む。
【００４９】
ステップ１１１２において、ユーザターミナル１０２は、領収書の許可解除カウントが、アカウント識別子に関連した許可ファイルの許可解除カウント以下であることをチェックすることにより許可解除カウントを検証する。もしそうであれば、検証が成功であり、ユーザターミナル１０２は、アプリケーションを起動する（１１１６）。許可解除カウントの検証が失敗した場合には、許可解除攻撃がおそらく生じており、従って、ユーザは、マシンにおいてアプリケーションを使用することが防止される。
【００５０】
検証方法９００の場合と同様に、検証方法１１００は、アプリケーションの中で遂行することができる。このケースでは、検証失敗時に行われるアクションは、アプリケーション開発者に依存する。例えば、検証失敗時に、アプリケーションは、中止となる。或いは又、検証失敗時に、アプリケーションは、実行を継続できるが、限定された機能しか利用できない。更に、構成にもよるが、アプリケーションは、ユーザのための許可を要求できないこともある。
【００５１】
図１２は、規範的な許可解除カウンタ使用シナリオを示す。このシナリオでは、アカウント識別子ＤＳｉｄ１をもつユーザが５台のマシンＭ１−Ｍ５において現在許可される。又、ユーザは、第６のマシンＭ６においてアプリケーションを使用できることを希望するが、使用ポリシーが許可の数を５に制限する。この初期のシナリオ設定は、マシンＭ５、Ｍ６の許可ファイル、及びサーバーの許可レコードに反映される（１２１０）。マシンＭ５の許可ファイルは、０の関連許可解除カウントと共にＤＳｉｄ１のエントリを含む。マシンＭ６の許可ファイルは、空である。サーバーにおける許可レコードは、ＤＳｉｄ１がマシンＭ１−Ｍ５において許可されそしてユーザがいずれのマシンも許可解除していないことを示す。
【００５２】
第６のマシンＭ６においてアプリケーションを使用する試みにおいて、ユーザは、Ｍ５において許可ファイルのコピーを作成し、そしてマシンを許可解除する。これらのアクションは、マシンＭ５の許可ファイル及びサーバーの許可レコードに反映される（１２２０）。マシンＭ５の許可ファイルは、現在、空である。更に、許可解除カウントが１に増加され、そしてＭ５は、サーバーの許可レコードにおける許可されたマシンのリストから除去される。
【００５３】
ユーザは、ここで、マシンＭ６を許可する。このアクションで２つの変化が生じ、それらは、マシンＭ５及びＭ６とサーバーとに反映される（１２３０）。第１に、マシンＭ６の許可ファイルは、１の許可解除カウントと共にＤＳｉｄ１を含むように更新される。第２に、サーバーの許可レコードは、許可されたマシンのリストにマシンＭ６を含むように更新される。
【００５４】
許可の後、ユーザは、許可ファイルを古い許可ファイルに置き換え、アプリケーションを購入する。マシンＭ５、Ｍ６及びサーバーに変化が反映される（１２４０）。購入証明領収書の許可解除カウントは、１である。ユーザがマシン５においてアプリケーションの使用を試みるとき、マシンは、検証方法１１００を使用してアプリケーションを検証することができる。購入証明領収書の許可解除カウントは、許可ファイルの許可解除カウントより大きいので、検証方法１１００は、ステップ１１１２において失敗となる。次いで、ユーザは、マシンにおいてアプリケーションを使用することが防止される。
【００５５】
次に、汎用コンピューティング装置について説明する。図１３に示して以下に述べるコンポーネントの全部又は一部分は、上述した種々の装置及びインフラストラクチャーを具現化するのに使用される。図１３を参照すれば、規範的システム１３００は、処理ユニット（ＣＰＵ又はプロセッサ）１３２０及びシステムバス１３１０を含む汎用コンピューティング装置１３００を備え、システムバスは、リードオンリメモリ（ＲＯＭ）１３４０及びランダムアクセスメモリ（ＲＡＭ）１３５０のようなシステムメモリ１３３０を含む種々のシステムコンポーネントをプロセッサ１３２０へ結合する。このシステム１３００は、プロセッサ１３２０に直結されるか、その至近に結合されるか、又はその一部分として一体化される高速メモリのキャッシュ１３２２を備えている。又、システム１３００は、メモリ１３３０及び／又は記憶装置１３６０からのデータを、プロセッサ１３２０による迅速アクセスのためにキャッシュ１３２２へコピーする。このように、キャッシュ１３２２は、データの待機中のプロセッサ１３２０の遅延を回避する性能ブーストを与える。これら及び他のモジュールは、種々のアクションを実行するようにプロセッサ１３２０をコントロールするべく構成される。他のシステムメモリ１３３０を使用することもできる。メモリ１３３０は、異なる性能特性を伴う複数の異なる形式のメモリを含む。本開示は、２つ以上のプロセッサ１３２０を伴うコンピューティング装置１３００、又はより大きな処理能力を与えるように一緒にネットワーク化されたコンピューティング装置のグループ又はクラスターにおいて作用することが明らかである。プロセッサ１３２０は、プロセッサ１３２０をコントロールするように構成された記憶装置１３６０に記憶されたモジュール１  １３６２、モジュール２  １３６４、及びモジュール３  １３６６のような汎用プロセッサ及びハードウェアモジュール又はソフトウェアモジュール、並びにソフトウェアインストラクションが実際のプロセッサ設計に合体された特殊目的プロセッサを備えている。プロセッサ１３２０は、本質的に、複数のコア又はプロセッサ、バス、メモリコントローラ、キャッシュ、等を含む完全自蔵型コンピューティングシステムである。マルチコアプロセッサは、対称的でも、非対称的でもよい。
【００５６】
システムバス１３１０は、メモリバス又はメモリコントローラ、周辺バス、及び種々のバスアーキテクチャーのいずれかを使用するローカルバスを含む多数の形式のバス構造のいずれかである。ＲＯＭ１３４０等に記憶される基本的入力／出力（ＢＩＯＳ）は、スタートアップ中、等に、コンピューティング装置１３００内の要素間で情報を転送する上で役立つ基本的ルーチンを与える。コンピューティング装置１３００は、更に、ハードディスクドライブ、磁気ディスクドライブ、光学ディスクドライブ、テープドライブ、等の記憶装置１３６０を備えている。記憶装置１３６０は、プロセッサ１３２０をコントロールするためのソフトウェアモジュール１３６２、１３６４、１３６６を含む。他のハードウェア又はソフトウェアモジュールも意図される。記憶装置１３６０は、ドライブインターフェイスによりシステムバス１３１０に接続される。ドライブ及びそれに関連したコンピュータ読み取り可能な記憶媒体は、コンピューティング装置１３００のためのコンピュータ読み取り可能なインストラクション、データ構造、プログラムモジュール、及び他のデータの不揮発性記憶を与える。１つの態様において、特定のファンクションを遂行するハードウェアモジュールは、そのファンクションを実行するために、プロセッサ１３２０、バス１３１０、出力装置１３７０、等の必要なハードウェアコンポーネントに関連して非一時的コンピュータ読み取り可能な媒体に記憶されたソフトウェアコンポーネントを含む。当業者であれば、基本的なコンポーネントが明らかであり、そして装置１３００が小型のハンドヘルドコンピューティング装置であるか、デスクトップコンピュータであるか、又はコンピュータサーバーであるかといった装置の形式に基づいて適当な変更が意図される。
【００５７】
ここに述べる規範的実施形態は、ハードディスク１３６０を使用するが、当業者であれば、規範的な動作環境において、コンピュータによりアクセスできるデータを記憶する他の形式のコンピュータ読み取り可能な媒体、例えば、磁気カセット、フラッシュメモリカード、デジタル多様性ディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）１３５０、リードオンリメモリ（ＲＯＭ）１３４０、ビット流を含むケーブル又はワイヤレス信号、等も使用できることが明らかであろう。非一時的なコンピュータ読み取り可能な記憶媒体は、エネルギー、搬送波信号、電磁波、及び信号それ自身のような媒体を明確に除外する。
【００５８】
ユーザがコンピューティング装置１３００と対話できるようにするために、入力装置１３９０は、スピーチのためのマイクロホン、ジェスチャー又はグラフィック入力のためのタッチ感知スクリーン、キーボード、マウス、モーション入力、スピーチ、等々の多数の入力メカニズムを表わす。出力装置１３７０も、当業者に知られた多数の出力メカニズムの１つ以上である。ある場合には、マルチモードシステムは、ユーザがコンピューティング装置１３００と通信するための多数の形式の入力を与えることができるようにする。通信インターフェイス１３８０は、一般的に、ユーザ入力及びシステム出力を支配しそして管理する。特定のハードウェア構成体での動作には制約がなく、それ故、ここでの基本的な特徴は、改良型ハードウェア又はファームウェア構成体が開発されるにつれて、それと容易に置き換えることができる。
【００５９】
説明を明確にするために、ここに示すシステムの実施形態は、「プロセッサ」又はプロセッサ１３２０と示された機能的ブロックを含む個々の機能的ブロックを包含するものとして表される。それらのブロックが表わすファンクションは、これに限定されないが、ソフトウェアを実行できるハードウェア、及び汎用プロセッサで実行されるソフトウェアに等価なものとして動作する専用のものであるプロセッサ１３２０のようなハードウェアを含めて、共有又は専用ハードウェアの使用を通して与えられる。例えば、図１３に示された１つ以上のプロセッサのファンクションは、単一の共有プロセッサ又は複数のプロセッサにより与えられる。（「プロセッサ」という語の使用は、ソフトウェアを実行できるハードウェアを排他的に指すものと解釈してはならない。）ここに示す実施形態は、マイクロプロセッサ及び／又はデジタル信号プロセッサ（ＤＳＰ）ハードウェア、以下に述べる動作を遂行するソフトウェアを記憶するためのリードオンリメモリ（ＲＯＭ）１３４０、及び結果を記憶するためのランダムアクセスメモリ（ＲＡＭ）１３５０を包含する。又、超大規模集積（ＶＬＳＩ）ハードウェア実施形態、並びに汎用ＤＳＰ回路と組み合わされたカスタムＶＬＳＩ回路も設けられる。
【００６０】
種々の実施形態の論理的な動作は、（１）汎用コンピュータ内のプログラム可能な回路で実行される一連のコンピュータ実施ステップ、動作又は手順；（２）特殊目的のプログラム可能な回路で実行される一連のコンピュータ実施ステップ、動作又は手順；及び／又は（３）プログラム可能な回路内の相互接続されたマシンモジュール又はプログラムエンジン；として具現化される。図１３に示すシステム１３００は、ここに述べる方法の全部又は一部を実施することができ、ここに述べるシステムの一部分でもよく、及び／又はここに述べる非一時的コンピュータ読み取り可能な記憶媒体におけるインストラクションに基づいて動作することができる。そのような論理的動作は、モジュールのプログラミングに基づいて特定のファンクションを遂行するようにプロセッサ１３２０をコントロールするよう構成されたモジュールとして具現化される。例えば、図１３は、特定のステップ又は一連のステップを遂行するようにプロセッサ１３２０をコントロールするモジュールである３つのモジュールＭｏｄ１  １３６２、Ｍｏｄ２  １３６４、及びＭｏｄ３  １３６６を示す。これらモジュールは、記憶装置１３６０に記憶されそしてランタイムにＲＡＭ１３５０又はメモリ１３３０へロードされてもよいし、又はこの技術で知られたように、他のコンピュータ読み取り可能なメモリ位置に記憶されてもよい。
【００６１】
また、本開示の範囲内の実施形態は、コンピュータ実行可能なインストラクション又はデータ構造体を搬送するか又はそれを記憶した有形な及び／又は非一時的なコンピュータ読み取り可能な記憶媒体も包含する。そのような非一時的なコンピュータ読み取り可能な記憶媒体は、上述した特殊目的プロセッサの機能的設計を含めて、汎用又は特殊目的コンピュータによりアクセスできる任意の入手可能な媒体である。例えば、そのような非一時的なコンピュータ読み取り可能な記憶媒体は、これに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、或いは他の光学ディスク記憶装置、磁気ディスク記憶装置、又は他の磁気記憶装置、或いはコンピュータ実行可能なインストラクション、データ構造又はプロセッサチップ設計の形態で望ましいプログラムコード手段を搬送し又は記憶するのに使用できる他の媒体を含む。情報がネットワーク又は別の通信接続（ハードワイヤード、ワイヤレス、又はその組み合わせ）を経てコンピュータへ転送され又は与えられるときに、コンピュータは、接続をコンピュータ読み取り可能な媒体として適切に見る。従って、そのような接続は、コンピュータ読み取り可能な媒体と適切に称される。又、上述した組み合わせは、コンピュータ読み取り可能な媒体の範囲内に含まれねばならない。
【００６２】
コンピュータ実行可能なインストラクションは、例えば、汎用コンピュータ、特殊目的コンピュータ又は特殊目的処理装置があるファンクション又はファンクションのグループを遂行するようにさせるインストラクション及びデータを含む。又、コンピュータ実行可能なインストラクションは、スタンドアローン又はネットワーク環境においてコンピュータにより実行されるプログラムモジュールも含む。一般的に、プログラムモジュールは、特殊目的プロセッサの設計、等において固有であって、特定のタスクを遂行するか或いは特定のアブストラクトデータ形式を具現化するルーチン、プログラム、コンポーネント、データ構造、オブジェクト、及びファンクションを含む。コンピュータ実行可能なインストラクション、それに関連したデータ構造、及びプログラムモジュールは、ここに開示する方法のステップを実行するためのプログラムコード手段の例を表わす。そのような実行可能なインストラクション又はそれに関連したデータ構造の特定のシーケンスは、そのようなステップで表されたファンクションを具現化するための対応するアクションの例を表わす。
【００６３】
当業者であれば、本開示の他の実施形態は、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベース又はプログラム可能な消費者向け電子装置、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、等を含めて、多数の形式のコンピュータシステム構成を伴うネットワークコンピューティング環境において実施されることが明らかであろう。又、これらの実施形態は、通信ネットワークを通してリンクされた（ハードワイヤードリンク、ワイヤレスリンク、又はその組み合わせにより）ローカル及びリモート処理装置によってタスクが遂行される分散型コンピューティング環境において具現化される。分散型コンピューティング環境では、プログラムモジュールは、ローカル及びリモートの両メモリ記憶装置に位置される。
【００６４】
上述した種々の実施形態は、例示のためのものに過ぎず、本開示の範囲を限定するものではない。当業者であれば、図示して説明された規範的実施形態及びアプリケーションに従うことなく且つ本開示の精神及び範囲から逸脱せずに、ここに述べた原理に対して種々の修正及び変更がなされ得ることが容易に明らかであろう。
【符号の説明】
【００６５】
１００：システム
１０２、１０４：電子装置（ユーザターミナル）
１１０：ネットワーク
１１２：電子アプリケーションディストリビュータ
２００：アプリケーション購入
２０６：アプリケーションバンドル
２０８：アプリケーション
２１０：購入証明領収書
３００：購入証明領収書
３０２：購入証明領収書本体
３０４：領収書署名
５００：許可ファイル
５０２：許可ファイル本体
５０４：許可ファイル署名
６００：ユーザ許可シナリオ
６０２：許可ファイル
６０４：ユーザ独特のアカウント識別子
６０６：サーバー
６１０：許可レコード
７００：方法
７０６、７１０：許可ファイル
７０８：アプリケーションバンドル
【図１】
0005624681.tif 000002
【図２】
0005624681.tif 000003
【図３】
0005624681.tif 000004
【図４】
0005624681.tif 000005
【図５】
0005624681.tif 000006
【図６】
0005624681.tif 000007
【図７】
0005624681.tif 000008
【図８】
0005624681.tif 000009
【図９】
0005624681.tif 000010
【図１０】
0005624681.tif 000011
【図１１】
0005624681.tif 000012
【図１２】
0005624681.tif 000013
【図１３】
0005624681.tif 000014