コンピューティング環境において、少なくとも1つのプロセッサー上の少なくとも一部で実行される方法であって、患者の属性を含むデリゲートされた患者トークンを入力するステップと、前記患者トークンを処理して、前記患者を直接識別することが可能な情報を含むことなく、ヘルスケアプロバイダーもしくはファーマシーpharmacyを識別し、インシュアラーinsurerからの払い戻しが望まれる1つまたは複数の補償された医療サービスもしくは製品を識別する、匿名トークンにするステップとを備えることを特徴とする方法。前記匿名トークンを支払の受領者に送信するステップをさらに備えることを特徴とする請求項1に記載の方法。前記患者のトークンを処理して前記匿名トークンにするステップは、前記患者について施された少なくとも1つの医療手順に対応する情報を含めることを含むことを特徴とする請求項1に記載の方法。前記患者について施された少なくとも1つの医療手順に対応する暗号化された患者レコードを保持するステップ、前記患者について施された少なくとも1つの医療手順に対応する匿名データを、データアグリゲーターに送信するステップ、または前記患者について施された少なくとも1つの医療手順に対応する暗号化された患者レコードを保持することと、前記患者について施された少なくとも1つの医療手順に対応する匿名データを、データアグリゲーターに送信することとの両方を行うステップをさらに備えることを特徴とする請求項3に記載の方法。前記患者のトークンを処理して前記匿名トークンにするステップは、前記患者に提供される少なくとも1つの処方箋に対応する情報を含めること、前記患者に関連付けられたエンドースメントendorsementからのデータを、ヘルスケアプロバイダーから受信されたアンエンドースドunendorsedトークンに結合すること、または前記患者に提供される少なくとも1つの処方箋に対応する情報を含めることと、前記患者に関連付けられたエンドースメントからのデータを、ヘルスケアプロバイダーから受信されたアンエンドースドトークンに結合することとの両方を備えることを特徴とする請求項1に記載の方法。インシュアラーにより患者へ提供される患者トークンからデリゲートトークンを生成するメカニズムであって、前記患者トークンは患者の属性および前記インシュアラーのデータを含むことと、前記デリゲートトークンから匿名トークンを生成するメカニズムであって、前記匿名トークンは、前記インシュアラーが前記匿名トークンに対応する前記患者トークンを発行したことを示すデータ、および前記患者を直接識別することが可能な情報を含むことなく、前記患者が医療サービスもしくは製品を受領したことを示すデータを含むこととを備えることを特徴とするシステム。前記デリゲートトークンを生成するメカニズムは、前記患者トークンにおける1つまたは複数の患者の属性を追加、削除もしくは修正することが可能なトークンエディターを備えることを特徴とする請求項6に記載のシステム。前記匿名トークンは、前記患者に医療サービスを提供したヘルスケアプロバイダーから前記患者へ送信され、または前記匿名トークンは、前記患者に医療製品を提供した薬局により前記インシュアラーへ送信されることを特徴とする請求項6に記載のシステム。薬局が、匿名エンドースメントendorsementを含むエンドースドendorsedデリゲートトークン、および匿名アンエンドースドunendorsedトークンを備える匿名トークンを受信し、前記受信されたトークンから前記匿名トークンを生成する前記メカニズムは、前記患者に関連付けられた前記エンドースメントとヘルスケアプロバイダーからのアンエンドースドトークンとを結合するメカニズムを備えることを特徴とする請求項6に記載の方法。暗号化された患者レコードをストレージサービスにアップロードする手段、患者レコードの匿名バージョンをデータアグリゲーターサービスにアップロードする手段、または暗号化された患者レコードをストレージサービスにアップロードする手段と、患者レコードの匿名バージョンをデータアグリゲーターサービスにアップロードする手段との両方をさらに備えることを特徴とする請求項6に記載のシステム。前記匿名トークンは、信頼された関係者が暗号化された患者レコードを復号することができる情報を含むことを特徴とする請求項6に記載のシステム。コンピューターにより実行可能な命令を有する1つまたは複数のコンピューター可読媒体であって、実行されると、患者およびインシュアラーに関連付けられた患者トークンに対応する匿名トークンを生成するステップであって、前記匿名トークンはヘルスケアプロバイダーおよび前記患者に提供される1つもしくは複数の医療サービスを、前記患者を直接識別することが可能な情報を含むことなく識別することと、前記1つもしくは複数の医療サービスに基づいて患者レコードを暗号化して、ストレージサービスにアップロードするステップと、前記匿名トークンを支払の受領者に送信するステップとを備える処理を実行することを特徴とする1つまたは複数のコンピューター可読媒体。処方箋に対応する情報を含む匿名エンドースドendorsedトークンを生成するステップであって、前記匿名エンドースドトークンは、患者と関連付けられた匿名エンドースメントendorsementおよび薬局の受領者に送信される匿名アンエンドースドunendorsedトークンを含むことと、前記エンドースメントの表示を印刷または出力するステップとをさらに備える処理を実行することを特徴とする請求項12に記載の1つまたは複数のコンピューター可読媒体。前記アンエンドースドトークンに対応するデータを、前記エンドースメントに対応するデータに結合して匿名結合トークンにするステップと、前記匿名結合トークンを支払の受領者に送信するステップとをさらに備える処理を実行することを特徴とする請求項13に記載の1または複数のコンピューター可読媒体。前記患者レコードを監査の一部として復号するステップをさらに備える処理を実行することを特徴とする請求項12に記載の1または複数のコンピューター可読媒体。本明細書において説明される技術の様々な態様は、一般に、患者IDをインシュアラーまたはファーマシーに公開することなく、サービスおよび/または調剤製品に対する支払いが達成される技術に関する。一実施態様では、互いにリンク可能な同一の患者による別々の訪問をすることなしに、これを達成することができる。さらに、患者レコードの匿名バージョンを、医療調査などの目的に、データアグリゲーターにアップロードすることができる。この目的のために、様々な関係者ヘルスケアプロバイダー、インシュアラー、患者およびファーマシーが公開鍵基盤においてIDを有することができる。本明細書で説明するように、患者はインシュアラーとインシュアランスポリシーを締結し、インシュアラーと双方向のプロトコルを実行することにより、患者は電子著名されたプルーフステートメントproofstatementトークンを保有することになる。当該プルーフステートメントは、患者がある特性との有効なインシュアランスポリシーを保有することを示す。このトークンはヘルスケアプロバイダー例えば、医者または病院に提示され、匿名な、かつリンク不可能な署名された承認ステートメントを生成するために使用される。当該承認ステートメントは支払のためにインシュアラーに提示される。類似の方法において、患者のIDを知ることなく、ファーマシーはインシュアラーから処方箋のための支払を受ける。本明細書における例は、一般的な医療のシナリオに関するが、本明細書のいかなる例は限定的なものではなく、その他のシナリオも本明細書で説明される技術から利益を得ることができることを理解されるであろう。このように、本発明は、本明細書で説明されるいかなる特定の実施形態、態様、概念、構造、機能または例に限定されない。むしろ、本明細書で説明される実施形態、態様、概念、構造、機能または例は限定的でなく、概してコンピューティングおよびプライバシーに利益および有利な点を提供する様々な方法で使用することができる。図1はヘルスケア環境における様々な関係者を表すブロック図を示す。ヘルスケア環境は、患者102がコンシューマーヘルスシステム104例えば、マイクロソフトAMALGA登録商標などを介してヘルスケア環境にアクセスすることを含む。ある相当の時期において、患者102または患者の使用者などはインシュアラー106とインシュアランスポリシーを締結する。匿名認証情報プルーフシステムを使用することで、患者102は1つまたは複数のトークンをインシュアラー106から受信する。これらはスマートカード、および必要に応じて例えば、インターネットを介してアクセスすることができる電子証明書などにおけるデータの形式であってもよい。本明細書でトークンを使用する場合、匿名認証情報システム技術に基づく任意の適切なデータ構造における任意の適切なデータのセットに言及する。このような匿名認証情報システムは、本明細書にて参照により組み込まれる文献特許文献1および特許文献2において説明されるように公知となっている。その他の文献は、非特許文献1および非特許文献2を含む。Idemixは、非特許文献3および非特許文献4により説明される技術として、別の適切な匿名認証情報システム技術である。概して本明細書で説明するように、ヘルスケアプロバイダー108とともに、後にトークンを使用して、サービスに対する支払のためにインシュアラー106に再び提示する匿名トークンを作成する。インシュアラーは、例えば患者/組織がポリシーをキャンセルし、さもなければ保険料の支払を停止する場合に、トークンを取り消しにする必要があることに留意されたい。取り消しは、非特許文献5で説明されるような既存の匿名認証情報取り消し技術を使用して行われる。匿名トークンでは、ヘルスレコードをインシュアラー106またはファーマシー110と共有するときに、患者と関連付けない。代わりに、患者102がヘルスケアプロバイダー108を訪問するときに、治療のプライベートレコードを生成して、患者の機密ヘルスレコードに格納する。一の例示的なシナリオでは、患者102がヘルスケアプロバイダー108により治療を受けるときに、ヘルスケアプロバイダー108はこの訪問のレコードを生成し、患者の機密個人クリニカルヘルスレコードに安全な方法でアップロードする例えば、コンシューマーヘルスシステム104に保持される。患者のプライベートレコードは暗号化されて保持され、明確な承諾および適切な秘密鍵なしに、コンシューマーヘルスシステム104またはその他のいかなる者によっては閲覧することができない。以下で説明するように、ヘルスケアプロバイダー108はインシュアラー106に支払の請求を行い、インシュアラー106がどの患者の支払が行われたかを知ることなく、支払が処理される。別の主たるシナリオでは、ヘルスケアプロバイダー108が患者に対して薬剤を処方する場合、ヘルスケアプロバイダー108はファーマシー110に関連する情報を含むトークンまたは以下に説明する部分トークンを送信する。このトークンは患者を識別することができる情報を含まず、患者に対して薬剤を処方する国家によりプロバイダー医者が認証されることを示す署名された承認ステートメント可能であれば公的給付データを含む。送信は電子メールによるものでもよく、トークンを特定のサイトなどにアップロードする。また、以下に説明するように、ヘルスケアプロバイダー108は追加的に患者についてのデジタル著名された処方箋トークン例えば、印刷されたバーコード形式でを生成し、これをファーマシー110へ持っていき、処方箋を手に入れる。物理的なプリントアウトは必ずしも提供されず、例えば、バーコードが患者の携帯電話またはファーマシーにおいてスキャンすることができるその他のデバイスにダウンロードされてもよいことに留意されたい。図1は、患者のレコードの匿名バージョンが生成され随意に、調査データ114にアグリゲートするなど、アグリゲーター112へアップロードするメカニズムをさらに示す。このようなデータを匿名にする様々な方法が知られている。しかしながら、匿名性を後に取り消しにする必要がある場合に、信頼できる第三者の使用を含めるなどのソリューションを採用することができる。このようにして、ヘルスケアプロバイダー108は、インシュアランス106およびファーマシー110との取引における患者102の信頼できる代理としての役割を果たすことができる。特に、ヘルスケアプロバイダー108は、ファーマシー110と対話し、匿名の、デリゲートすることができ、かつリンク不可の認証情報システムにおいてトークンを使用して、患者102の代わりにインシュアラー106に支払の請求をする。以下で説明するように、セーフガードを使用してこのようなトークンが悪用されないことを保障する例えば、複数の使用についてはその他へ回す。図2は、匿名の認証情報を含む暗号化ツールに基づいた匿名ヘルスケアおよびレコード技術の態様を要約したものであり、ステップ202から始まり、そこでは患者はインシュアラーからインシュアランスポリシーを取得し、匿名プルーフシステムを使用してトークンを受信する。概して、このトークンは、所与のポリシーに準じて患者の治療が隠蔽されることを証明する。ステップ204は、妥当なインシュアランスポリシーを表すトークンを受理する医者/病院を訪れる患者を表す。患者は当該ポリシーの関連部分を公開し、この訪問についてのトークンをヘルスケアプロバイダーに送り、当該トークンが処理されて匿名トークンになる。以下に説明するように、医者と患者との間のいくつかの対話が要求されて、訪問についてインシュアラーに提示される匿名トークンを生成することができる。一実施形態では、医者/病院は、この訪問により生成されるいかなるレコードまたはデータに関して、患者により全面的に信頼されると仮定する。ステップ206は、訪問についての患者レコードを暗号化して、当該レコードをコンシューマーヘルスシステムにアップロードする医者/病院を表す。医者/病院は随意に、患者の訪問/ヘルスレコードの匿名バージョンをデータアグリゲーターシステムにアップロードすることもできるステップ208。ステップ210では、医者/病院は有効な、匿名の、リンク不可のトークンを使用して、インシュアラーに支払の請求を行う。医者は、保険請求が患者のポリシーの下、有効であるかをチェックし可能であれば治療前に、匿名トークンを、提供されるサービスの詳細を含むインシュアラーに送信する。インシュアラーはこのトークンをチェックし、当該請求の払い戻しを行う。すなわち、医者/病院は、インシュアラーがこのトークンの有効性をチェックした後に、支払いを受ける。患者についてのいかなる手順を実行する前に、医者/病院は、トークンが所望の手順に対して少なくとも部分的に有効であることをチェックするメカニズムを有することができることに留意されたいいかなる相違も患者に責任がある。ステップ212および214は、様々な医者/患者/ファーマシーのオペレーションを表す。概して、ステップ212では、医者は患者に対して1つまたは複数の薬剤を処方する。この情報は、訪問に関する患者のレコードに含まれる。いったんこの情報が電子的に格納されると、薬剤のやり取りが自動的にエラーとなり得、ファーマシーはこの処理においては大きな役割を果たす必要がない。処方箋をファーマシーに伝達するために、医者/病院は処方する権利を証明する国家により発行された認証情報を使用して、保険が当該薬物を補償することを示す匿名トークンを介して、特定の患者と結び付けられた署名された処方箋を生成する。したがって、ファーマシーに与えられた情報は、処方箋の詳細と、保険の補償範囲の支払/証明のためにインシュアラーに提示するのにファーマシーが使用することができる1つまたは複数のトークンとを含む。ステップ214により示されるように、手書きにより署名された処方箋を発行することに代えて、医者は印刷するか、または患者に付与し、ファーマシーに持ち込むデジタル著名された処方箋バーコードの形式とすることができるを含むトークン例えば、部分的トークンを生成することができる。次に、患者は、当該患者から受信されたトークンを照合する、対応するファーマシーに行き、医者は事前に適切な薬物の調剤を行う。払い戻しのために、患者により確かに受け取られた医療製品の請求を証明することとして、ファーマシーは医者からのトークンと患者からのトークンを結合して、その証明および請求の払い戻しを照合するインシュアラーにその結果を提示する。この方法では、患者IDをインシュアラーやファーマシーに公開することなく、かつリンク可能な同一の患者により別々の訪問がされなくとも、サービスや医療製品に関する支払を達成することができる。これは、匿名認証情報システムが、ユーザーが組織から認証情報を取得し、必要な認証情報を保持することを証明するトークンを生成している間に、リソース/サービスにアクセスすることを可能にするからである。これらのトークンは患者に関する情報を公開しないという点で匿名であり、それらは初期の保険に再びリンクすることができず、同一の認証情報を使用して、2つのトークンが生成されることを区別することも不可能である。一実施形態におけるトークンの様々な態様に目を向けると、図3で示すように患者102は1つまたは複数の属性の組を含む認証情報320をインシュアラー106から受信する。当該属性から1つまたは複数のトークンの組を発行することができる。患者102が所与の属性を有することを証明する、1つまたは複数のステートメントに対応するトークンの組は、所与の属性を有しておらず、所与の範囲内で属性、またはこのようなステートメントの任意の組み合わせを有するまたは有さない。認証情報/トークン320を備える患者は、デリゲートされたトークン322を別の関係者、すなわち、ヘルスケアプロバイダー108に発行することができる。患者102はまた、例えば、ある属性を修正することが可能なトークンエディター324例えば、ソフトウェアプログラムを介して、デリゲートされたトークン322に含まれるこの属性のいずれかを選択することができる。デリゲートされたトークン322によって、ヘルスケアプロバイダー108は、組織からの有効な認証情報を備えるいずれかの人によって発行された認証情報の所有権を証明することが可能になるこの仲介ユーザーに関する情報を公開することなしに。したがって、一実施形態では、患者102に関するトークン320は、ポリシーが標準化された形式を有すると仮定して、当該ポリシーの属性を含む単一の認証情報を備えることができる。ヘルスケアプロバイダー108に関するトークンは、ハードコード化された訪問日などを有するデリゲートトークン322を備えることができる。トークンエディター324を介して、患者は、施された治療に関連しない場合のいくつかのフィールドを除去することを選択することができる。例えば、患者の主要な担当医を訪問すると、医療認証情報を除去することができる。代わりに、請求されている各治療を承認するのに必要であるなど、このプロセスに患者をより関与させることができる。インシュアラー106についての匿名トークン326に関しては、ヘルスケアプロバイダー108はデリゲートトークン322を使用して、請求される手順および/またはサービスが確かに補償されることの証明を生成する匿名トークンジェネレーター328、例えばソフトウェアプログラムを介して。匿名トークン326の生成において、患者102はヘルスケアプロバイダー108をともに作用することができることに留意する。次に、支払い330は、上記説明のようにヘルスケアプロバイダー108に送信される。あるケースでは、同一の設定において2回以上、認証情報を使用しないことを保証することが重要になる。このケースでは、患者102は各設定に対して使い捨てトークンを提供する。患者102が同一の設定に対して2以上のトークンを生成する場合、より容易に当該トークンを検出することができるが、しかしながらそれぞれの使用が異なる設定である限り、同一の患者102により複数のトークンが生成されたことを区別する手法が存在しない。したがって、匿名トークン326を、患者および日付に関する使い捨てラベルに結合することができ、それにより同一の手順に対する複数の請求を防止することができる。インシュアラーのポリシーがより複雑である場合は、トークン内のデータを介してその他の特徴既存の技術により達成可能なを提供することができる。例えば、1週間ごとに1つのリハビリ手順のみを行うなどのある手順の間で必要とされる時間差であってもよく、それをトークン内のデータとして含めることができる。インシュアラーのトークンのその他の特徴は、先行手順が既に払い戻しを受けたことを証明すること、患者の生涯または年間の上限が超過していないことを証明すること、およびこの患者についての研究からの署名された結果の証明などに向けられる。図4は、患者/医者/ファーマシー/インシュアラーの対話の様々な態様を示す図である。2つの部分においてトークンを生成することができ、他方がいなければ有効にならないことに留意されたい。トークンのこれらの部分は、本明細書においてはアンエンドースドトークンおよびエンドースメントendorsementとして言及される。エンドースメントは、証明されるステートメントの長さにもかかわらず、非常に短くすることができる特徴を有している。ファーマシー110にとって、医者408がデリゲートトークン422を与えられるときに、一実施形態では、医者408は、請求を照合するのに必要ないかなる情報を備えるエンドースドendorsedデリゲートトークン440を生成するエンドースドデリゲートトークンジェネレーター、ソフトウェアプログラムなどを介して。このことは、基本的にはインシュアラー108についての匿名トークンのエンドースドバージョンであり、処方する医者が認証されることのみを公開する。アンエンドースドトークン部分441は、印刷され、もしくは何らかの方法で電子的に生成され例えば、1次元または2次元バーコードとして、患者102に関連付けられた例えば、与えられたエンドースメント442とともに、ファーマシーに送信、または送られる。上記説明したように、患者102または患者の代表は、エンドースメント442をファーマシー110に提供して、それにより当該エンドースメントはアンエンドースドトークン441と再結合され、匿名にされて例えば、匿名トークンコンバイナーcombiner/ジェネレーターソフトウェアプログラム428を介して、支払い430のためにインシュアラー106に提供される匿名結合トークン426となる。別の態様に目を向けると、匿名性を取り消して、許可監査が必要となる状況がある場合がある。したがって、例えば監査の場合などに、治療情報および各患者のIDを検索する方法が提供される。1つのオプションは、復号キーを保持し、または復号キーを共有する1つのまたは複数の信頼された関係者を有することである。トークンが形成されてインシュアラーに送信されるときに、医者はまた、このキーを基に暗号化されたデータを含むことができ、当該データは治療情報この情報についての当該医者の署名とともにを含む。監査が必要な場合に、インシュアラーは信頼された関係者に問い合わせを行い、復号化を実行することができる。虚偽が発見された場合、医者はそれから責任を負うことができる。トークンの共有を防止することに関しては、インシュアラーは、患者が他人例えば、共同で保険をかけられた家族以外とポリシーを共有することを望まないであろう。1つの解決策は、関係者患者を含むが公開鍵基盤において証明可能なIDを有すると仮定することである。やや劣るが別の解決策は、患者が当該患者の権利を共有して、別の誰かによるポリシーの使用を許可することを要求することである。さらに別の解決策は、発行されたポリシートークンおよび患者が医者に示すデリゲートトークンしかし匿名トークンではないに患者名を含ませることであり、医者は患者のIDを証明することに責任を負う。図5は、図1乃至4の例を実装することができる適切なコンピューティングおよびネットワーク環境500の例を示す。コンピューティングシステム環境500は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に関していかなる限定を示唆することを意図するものではない。また、コンピューティング環境500は、例示的な動作環境500において示されるコンポーネント内の任意の1つまたは組み合わせに関していかなる依存もしくは要件がないと解釈されるべきである。本発明は、多くのその他の汎用もしくは専用コンピューティングシステム環境もしくは構成により動作可能である。本発明により使用されるのに適切となり得る既知のコンピューティングシステム、環境および/または構成の例は、パーソナルコンピューター、サーバーコンピューター、ハンドヘルドデバイスもしくはラップトップデバイス、タブレットデバイス、マルチプロセッサーシステム、マイクロプロセッサーベースシステム、セットトップボックス、プログラミング可能な家庭用電化製品、ネットワークPC、ミニコンピューター、メインフレームコンピューター、および上記システムもしくはデバイスのうちのいずれかを含む分散コンピューティング環境などを含むが、これらに限定されない。本発明は、コンピューターにより実行されるプログラムモジュールなどのコンピューターにより実行可能な命令の一般的なコンテキストにおいて説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などを含む。本発明はまた、通信ネットワークを通じてリンクされるリモート処理デバイスによりタスクが実行される分散コンピューティング環境において実施することができる。分散コンピューティング環境においては、プログラムモジュールを、メモリー記憶装置を含むローカルおよび/またはリモートコンピューター記憶媒体に位置させることができる。図5を参照すると、本発明の様々な態様を実装するための例示的なシステムは、コンピューター510の形式で汎用コンピューティングデバイスを含むことができる。コンピューター510のコンポーネントは、プロセシングユニット520、システムメモリー530、およびシステムメモリー530からプロセシングユニット520までを含む様々なシステムコンポーネントを結合するシステムバス521を含むが、それらに限定されない。システムバス521は、メモリーバス、メモリーコントローラー、周辺機器用バス、および種々のバスアーキテクチャーのうちのいずれかを使用したローカルバスを含む様々なタイプのバス機構のうちのいずれかであってもよい。例として、このようなアーキテクチャーは、ISAIndustryStandardArchitectureバス、MCAMicroChannelArchitectureバス、EISAEnhancedISAバス、VESAVideoElectronicsStandardsAssociationバス、およびメザニンMezzanineバスとしても知られるPCIPeripheralComponentInterconnectバスを含むが、これらに限定されない。コンピューター510は、主として、種々のコンピューター可読媒体を含む。コンピューター可読媒体は、コンピューター510によりアクセスすることができる任意の利用可能な媒体であることができ、揮発性および不揮発性、ならびに着脱可能および着脱不能媒体を含むことができる。例として、コンピューター可読媒体は、コンピューター記憶媒体および通信媒体を含むことができるが、これらに限定されない。コンピューター記憶媒体は、コンピューター可読命令、データ構造、プログラムモジュールもしくはその他のデータなどの情報を記憶するための任意の方法もしくは技術において実装される揮発性および不揮発性、着脱可能および着脱不能媒体を含む。コンピューター記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリーもしくはその他のメモリー技術、CD-ROM、DVDdigitalversatilediskもしくはその他の光学ディスク装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または所与の情報を記憶するのに使用することができ、コンピューター510によりアクセスすることができるその他の任意の媒体を含むが、これらに限定されない。通信媒体は、主として、搬送波もしくはその他の搬送メカニズムなどの変調データ信号において、コンピューター可読命令、データ構造、プログラムモジュールもしくはその他のデータを具体化し、かつ任意の情報配信媒体を含む。用語変調データ信号は、信号内の情報をエンコードするような方法において、設定されまたは変更された1つまたは複数の特性を有する信号を意味する。例として、通信媒体は有線ネットワークもしくは直接配線接続などの有線媒体、ならびに音声、RF、赤外線およびその他の無線媒体などの無線媒体を含むが、これらに限定されない。上記いずれの組み合わせはまた、コンピューター可読媒体の範囲内に含まれてもよい。システムメモリー530は、ROMreadonlymemory531およびRAMrandomaccessmemory532などの揮発性および/または不揮発性メモリーの形式のコンピューター記憶媒体を含む。スタートアップ中など、コンピューター510内の要素間において情報を転送するのに役立つ基本ルーチンが含まれるBIOSbasicinputoutputsystem533は、主として、ROM531に格納される。RAM532は主として、データ、および/またはプロセシングユニット520により直接アクセス可能であり、および/またはプロセシングユニット520上で間もなく動作するプログラムモジュールを含む。例として、図5はオペレーティングシステム534、アプリケーションプログラム535、その他のプログラムモジュール536およびプログラムデータ537を示すが、これらに限定されない。コンピューター510はまた、その他の着脱可能/着脱不能、揮発性/不揮発性コンピューター記憶媒体を含んでもよい。ほんの一例として、図5は着脱不能、不揮発性磁気媒体から読み取り、もしくはそれらに書き込むハードディスクドライブ541、着脱可能、不揮発性磁気ディスク552から読み取り、もしくはそれらに書き込む磁気ディスクドライブ551、およびCD-ROMもしくはその他の光学媒体などの着脱可能、不揮発性光学ディスク556から読み取り、もしくはそれらに書き込む光学ディスクドライブ555を示す。例示的な動作環境で使用することができるその他の着脱可能/着脱不能、揮発性/不揮発性コンピューター記憶媒体は、磁気テープカセット、フラッシュメモリーカード、DVD、デジタルビデオテープ、ソリッドステートRAM、およびソリッドステートROMなどを含むが、これらに限定されない。ハードディスクドライブ541は主として、インタフェース540などの着脱不能メモリーインタフェースを通じてシステムバス521に接続され、磁気ディスクドライブ551および光学ディスクドライブ555は主として、インタフェース550などの着脱可能メモリーインタフェースによりシステムバス521に接続される。上記説明され、図5で示されたドライブおよびそれに関連するコンピューター記憶媒体は、コンピューター510に関するコンピューター可読命令、データ構造、プログラムモジュールおよびその他のデータのストレージを提供する。図5では、例えば、ハードディスクドライブ541が、オペレーティングシステム544、アプリケーションプログラム545、その他のプログラムモジュール546およびプログラムデータ547を格納するものとして示される。これらのコンポーネントは、オペレーティングシステム534、アプリケーションプログラム535、その他のプログラムモジュール536およびプログラムデータ537と同一かあるいは別のものであってもよいことに留意されたい。オペレーティングシステム544、アプリケーションプログラム545、その他のプログラムモジュール546およびプログラムデータ547は、本明細書では異なる番号が付与され、最低限、それらが様々な複製であることを示す。ユーザーはタブレットもしくは電子デジタイザー564、マイクロフォン563、キーボード562および一般にマウスと称されるポインティングデバイス561、トラックボールもしくはタッチパッドなどを通じてコマンドおよび情報を入力することができる。図5では示されないその他の入力デバイスは、ジョイスティック、ゲームパッド、サテライトディッシュ、またはスキャナーなどを含んでもよい。これらおよびその他の入力デバイスは、システムバスに結合されたユーザー入力インタフェース560を通じてプロセシングユニット520に接続されることが多いが、パラレルポート、ゲームポートまたはUSBなどのその他のインタフェースおよびバス機構により接続されてもよい。モニター591またはその他のタイプのディスプレイデバイスはまた、ビデオインタフェース590などのインタフェースを介してシステムバス521に接続される。モニター591はまた、タッチスクリーンパネルなどと一体化されてもよい。モニターおよび/またはタッチスクリーンパネルは、コンピューティングデバイス510がタブレットタイプのパーソナルコンピューターなどに組み込まれる、ハウジングに物理的に結合されてもよいことに留意されたい。加えて、コンピューティングデバイス510などのコンピューターはまた、周辺出力インタフェース594などを通じて接続され得るスピーカー595およびプリンター596などのその他の周辺出力デバイスを含んでもよい。コンピューター510はリモートコンピューター580などの1または複数のリモートコンピューターへの論理接続を使用して、ネットワーク環境において動作してもよい。リモートコンピューター580は、パーソナルコンピューター、サーバー、ルーター、ネットワークPC、ピアデバイスもしくはその他の共通ネットワークノードであってもよく、図5ではメモリーストレージデバイス581だけが示されたが、主として、コンピューター510と比較して上記説明した要素の多くもしくはすべてを含んでもよい。図5で示した論理接続は、1つまたは複数のLANlocalareanetwork571および1つまたは複数のWANwideareanetworkを含むが、また、その他のネットワークを含んでもよい。このようなネットワーク環境は、オフィス、企業規模のコンピューターネットワーク、イントラネットおよびインターネットにおいて一般的となっている。LANネットワーク環境において使用されるときに、コンピューター510はネットワークインタフェースもしくはアダプター570を通じてLAN571に接続される。WANネットワーク環境において使用されるときに、コンピューター510は主として、モデム572もしくはインターネットなどのWAN572上で通信を確立するその他の手段を含む。内部もしくは外部であり得るモデム572は、ユーザー入力インタフェース560もしくはその他の適切なメカニズムを介して、システムバス521に接続されてもよい。インタフェースおよびアンテナなどを含む無線ネットワークコンポーネントは、アクセスポイントもしくはピアコンピューターなどの適切なデバイスを通じてWANもしくはLANに結合されてもよい。ネットワーク環境では、コンピューター510と比較して示されたプログラムモジュール、もしくはその一部がリモートメモリー記憶装置に格納されてもよい。例として、図5はメモリーデバイス581内に存在するリモートアプリケーションプログラム585を示す。示されるネットワーク接続は例示的であり、コンピューター間で通信リンクを確立するその他の手段を使用してもよいことが理解できるであろう。補助的サブシステム599例えば、コンテンツの補助的な表示は、コンピューターシステムの主要な部分が低電力状態にある場合でも、ユーザーインタフェース560を介して接続されてもよく、プログラムコンテンツ、システムステータスおよびイベント通知などのデータをユーザーに提供することを可能にする。補助的なサブシステム599は、モデム572および/またはネットワークインタフェース570に接続されてもよく、それによりメインプロセシングユニット520が低電力状態にある間に、これらのシステム間における通信を可能にする。本発明は、種々の変形および代替の構造が可能であり、本明細書で説明したある実施形態を図面において示し、上記詳細に説明してきた。しかしながら、本発明を開示された特定の形態に限定する意図はなく、むしろ、本発明は、本発明の精神および範囲内でのすべての変形、代替構成および同等のものをカバーするものである。