JP5301063B2 - 仮想通貨システム内における創出、償還、及び精算 - Google Patents

Description

本発明は一般的に仮想経済に関し、特に仮想通貨システムによる仮想クレジットを創出すること（creating）、償還すること（redeeming）、追跡すること（tracking）に関する。

仮想通貨システムは、仮想環境内において他のエンティティ（entity：実在するもの）と取引することにより、ユーザが仮想環境内でインタラクト（interact:相互作用）することのできるようにする。ユーザは、例えばベンダー（vendor: 売り手）からの商品やサービスの購入あるいは個人間の贈り物や支払いなどのさまざまな目的のために、仮想クレジットを交換し得る。あるシステムにおいて、仮想クレジットはまた、仮想クレジットを現実通貨で購入することによって、及び／又は仮想クレジットを現実通貨に償還することによって、現実通貨と交換され得る。しかしながら、従来は、すべての仮想クレジットは仮想通貨システム内で同じように処理される。具体的には、仮想クレジットはオリジナル交換レートに基づいて創出され、それらは同じ交換レートで現実通貨に償還される。

この制限のために、従来のシステムにおいて異なるタイプのクレジット間で区別すること、そうでなければ異なるタイプのクレジットを有効にすることは困難である。例えば、ユーザへクレジットを配布することは、初期費用なしであるいは割引費用でクレジットを創出することを含み得る。それから、配布したクレジットが移動されるとき又は償還されるときに、該配布したクレジットが特定される必要があり、及び／又はそれらのオリジナル費用が追跡される。そうでない場合、仮想通貨システムは、該通貨システム内において配布されたクレジットを他のクレジットと区別できないかもしれない。配布されたクレジットを特定することは、例えば、仮想クレジットの償還の際に正しい価格を提供するために又は他の精算要件のために、必要であり得る。

仮想通貨システム内での商品やサービスの割引は、異なる現実通貨??交換レートを有する複数のクレジットを創出することをもたらすかもしれない。例えば、ベンダーは、ユーザへ割引を提供するために商品やサービスの実際の価格よりも低い現実通貨価格（すなわち、償還可能価格）、を有する仮想クレジットを特定し受け入れることを望み得る。しかし、異なる特性を有する複数の仮想クレジットを創出し追跡することができない既存の仮想通貨システムは、このような割引制度を可能にしない。

既存の仮想経済のこれら特有の限界は、どのようにして仮想クレジットは現実通貨に交換されたらよいのかというような、現実通貨との融通性のない関係に、少なくとも部分的に、由来している。さらに、既存の仮想通貨システムは、仮想経済内でより高いレベルの機能を可能にする適切な精算メカニズムを提供できない。したがって、仮想通貨システム内において仮想クレジットを創出すること、追跡すること、償還することの改良方法が必要である。

仮想経済の能力を高めるために、本発明の実施形態は、仮想クレジットと呼ぶ仮想通貨単位を管理する仮想通貨システムを提供する。仮想クレジットは仮想経済内で、様々な参加者によって所有されかつ様々な参加者間で交換され得る。仮想経済内の参加者は、個人のユーザ、ベンダー又は他の非個人のエンティティ、例えば第三者支払人（third party payors）、さらには仮想通貨システムのセントラルマネージャ（central manager：中央管理主体）などを含んでよい。さらに、仮想クレジットは、現実通貨と引き換えに購入及び／又は販売され得る。新たな仮想クレジットの購入は仮想通貨システムによる新たな仮想クレジットの創出を含み、既存クレジットの販売は仮想通貨システムによる既存の仮想クレジットの償還を含み得る。

一実施形態において、仮想通貨システムは複数の仮想クレジットに関する情報を追跡し続ける。例えば、各仮想クレジットは内部値と外部値を持つことができ、これらの値は異なる仮想クレジット（または仮想クレジットバケット）で異なり得る。各仮想クレジットの内部値及び外部値は、それぞれ、仮想クレジットを創出するための交換レート、仮想クレジットを償還するための交換レートを決める。新たな仮想クレジットの創出の際に、これら仮想クレジットの内部値は各仮想クレジット毎に支払われた現実通貨のレートであり、前記仮想クレジットの表面上の額面価格と異なり得る。仮想クレジットの外部値もまた創出時に確立され得るようになっていてよく、該外部値は該仮想クレジットが現実通貨に償還され得るレートを設定する。各仮想クレジットはさらに、額面価格を有していてもよい。額面価格は、仮想経済内での表面上の仮想クレジットの価格であり、仮想通貨を評価するためのベースラインインプレッション（baseline impression：基準相場感覚）をユーザに与える。額面価格はこのように、仮想通貨が現実通貨貨幣価格（例えば、100仮想クレジットは10ドルの額面価格を有し得る）によって示されることのできるようにする。

仮想クレジットは仮想経済内で参加者から参加者へと移動されるので、仮想通貨システムはこれら仮想クレジットの価格を追跡する。額面価格、内部値、外部値の能力は異なり、各参加者によって所有される仮想クレジットのこれらの値の追跡は、通貨配布、クーポン引き換え、チャージバックを含む仮想経済内でのいくつかの有用な活動を有効にする。

本発明の実施形態に係る、クレジットが創出され、移動され、償還される仮想通貨システムを示すハイレベル概念図である。

本発明の実施形態に係る、クレジットを創出し、移動し、償還するためのシステム環境のネットワーク構成図である。

本発明の実施形態に係る、仮想通貨システム内でクレジットを創出するプロセスを表すフローチャートである。

本発明の実施形態に係る、仮想通貨システムの参加者アカウントモジュール及びデータストアモジュールの図である

本発明の実施形態に係る、参加者のアカウント間のクレジット移動を示す図である。

本発明の実施形態に係る、償還処理のフローチャートである。

本発明の実施形態に係る、仮想通貨システムの参加者間のクレジットの創出、移動、償還の図である。

図は、説明だけを目的として本発明の各種の実施の形態を示す。当該分野の技術者には言うまでもなく、本明細書で説明する構造および方法の代替の実施の形態が、本明細書で説明する本発明の原理から逸脱することなく利用できることは、以下の説明から直ちに理解されよう。

概 要
仮想通貨システムは、参加者に仮想オンライン環境内で商品及びサービスを交換する手段を提供する。参加者は、商品、サービス、又は他の価値あるものを購入するために仮想クレジットを交換する。仮想通貨システムは、商品やサービスを購入又は取得するための新しくより簡単な方法を提供することによって、伝統的な通貨システムよりもより幅広い相手のユーザに商品やサービスへのアクセスを提供することができる。ここで用いられるように、用語"クレジット"又は用語"仮想クレジット"は、仮想通貨システム内で用いられる仮想通貨単位のことをいう。"仮想通貨"とは、仮想環境内で価値に交換される通貨のことをいう。対照的に、"現実通貨"は、仮想環境外の価値の取引で用いられるあらゆるタイプの通貨のことをいう。現実通貨はまた、例えばモバイルフォンミニッツ（mobile phone minutes）、エアタイムクレジット（airtime credits）、あるいはワイヤレスサービスアカウントで用いられる他の価格単位などの、無形通貨を含むことができる。仮想通貨システムは、例えばオンラインゲームウェブサイト、オンラインシミュレーション環境、ソーシャルネットワーキング環境、オンライン市場などの、ユーザがインタラクトしかつ価値を交換できるどんな仮想環境内にも存在することができる。仮想通貨システム内で交換される商品やサービスは、現実、仮想、デジタル、またはその組み合わせであってよい。

仮想通貨システム内において、仮想クレジットバケットは内部値、外部値、額面価格と共に創出される。クレジットバケットは、１以上のクレジットを含み得る。内部値は、クレジットを創出するためのオリジナルレートにより設定される。外部値は、クレジットを現実通貨に交換するためのレートにより設定される。額面価格は、システムのユーザに示される仮想通貨の価格である。

内部値及び外部値を持つクレジットを創出することは、様々なアプリケーションを可能にする。クレジットバケットの内部値は、例えば割引や配布などの通貨アプリケーションを可能にするように決定され得る。クレジットバケットを創出する実際の費用よりも低い内部値は、ユーザがクレジットを購入する費用の割引を受けることを可能にする。ゼロの内部値は、あるユーザへ初期費用なしでクレジットの配布を可能にする。また、外部値の割引はクレジットの償還価格を下げる。商品やサービスの費用よりも低い外部値は、ベンダーがユーザへ商品やサービスの割引を与えることを可能にする。内部値及び外部値はクレジットバケットの識別属性として用いられ得て、仮想通貨システム内における様々な取引を通じてクレジットの追跡を可能にする。

仮想通貨システムの参加者は、ユーザ、ベンダー、セントラルマネージャ、及び第三者支払人を含み得る。ユーザはクレジットを取得又は購入して、かつそのクレジットを商品やサービスに交換する個人である。他のタイプの参加者は、クレジットと引き換えにサービスや商品を提供する、個人、企業、開発者、あるいはエンティティになることができるベンダーである。セントラルマネージャはクレジットの創出、移動、及び償還を管理しかつ参加者とインタラクトする。セントラルマネージャは、個人、グループ、エンティティ、会社又はソーシャルネットワークプロバイダになることができる。実施形態において、セントラルマネージャはまた、一人のユーザ又は一つのベンダーとして動作し得る。セントラルマネージャは、ユーザからのクレジットと引き換えに商品やサービスを提供することができる。他の参加者は、例えば電子決済プロバイダや携帯電話事業者などの、仮想通貨システム内の取引を容易にする又は取引に参加する、非個人のエンティティ又は第三者支払人を含み得る。様々な他の参加者が、仮想通貨システムに含まれ得る。

図１は、仮想通貨システムの一実施形態のハイレベルブロック図を示す。一実施形態において、セントラルマネージャ１００はユーザ１１０とベンダー１２０とインタラクトする。セントラルマネージャ１００は、現実通貨１４０と引き換えにクレジット１３０を支給する。ユーザ１１０は、クレジット１３０をセントラルマネージャ１００から現実通貨１４０と引き換えに購入することができる。ユーザ１１０は、クレジット１３０をベンダー１２０からの商品やサービス１５０に交換することができる。ベンダー１２０は、ユーザ１１０からのクレジット１３０を商品やサービス１５０と引き換えに受け入れることができ、かつ前記クレジット１３０をセントラルマネージャ１００からの現実通貨１４０に償還することができる。

様々な他の取引が、仮想通貨システムの参加者間で起こり得る。実施形態において、セントラルマネージャ１００はまたベンダー１２０として動作して、商品やサービス１５０をユーザ１１０にクレジット１３０と引き換えに提供する。セントラルマネージャ１００は、ユーザ１１０とベンダー１２０にクレジット１３０を販売することができる。また、セントラルマネージャ１００は、クレジット１３０と商品及びサービス１５０の両方をユーザ１１０に販売することができる。例えば、セントラルマネージャ１００は、50クレジットバケットをユーザ１１０に10ドルで販売することができ、それからオンラインゲームアプリケーションをユーザ１１０に同じクレジット１３０と引き換えに販売することができる。

他の実施形態において、ベンダー１２０はクレジット１３０をユーザ１１０に現実通貨１４０と引き換えに販売することができる。一実施形態において、ベンダー１２０はクレジット１３０を現実通貨１４０に償還することができる、しかし、ユーザはクレジット１３０を現実通貨１４０に償還することができない。ベンダー１２０はまた、クレジット１３０をセントラルマネージャ１００から購入することができる。

別の実施形態において、第三者支払人、例えば電子決済プロバイダ、携帯電話会社、または仮想移動体通信事業者などは、仮想通貨システム内での取引を支援することができる。ある形態において、第三者支払人は、クレジット１３０をセントラルマネージャ１００からユーザ１１０の代理で購入することができる。第三者支払人はまた、取引の料金を請求することができる。例えば、ユーザ１１０は、クレジット１３０を携帯電話会社を介して購入することができる。ユーザ１１０は携帯電話会社と共にアカウントを有し、クレジット１３０の購入のために時間（minutes）を取引するように要求（request）することができる。携帯電話会社は、数分をユーザのアカウントからクレジット１３０の価格のために差し引くことができ、かつ当該取引の追加料金（surcharge）を含めることができる。別の実施形態において、携帯電話会社は、ユーザのアカウントに直接的にクレジット１３０の購入料金を請求することができる。携帯電話会社はクレジット１３０をセントラルマネージャ１００から購入することができ、セントラルマネージャ１００はクレジット１３０を直接ユーザに提供することができる。他の実施形態において、携帯電話会社はクレジット１３０をセントラルマネージャ１００から受け取ることができ、かつ前記クレジット１３０をユーザ１１０に提供することができる。ユーザ１１０はまた、携帯電話会社がサービスや商品１５０をベンダー１２０から該ユーザ１１０の代理として購入することを要求（リクエスト）することができる。例えば、ユーザ１１０は、携帯電話会社がオンラインゲームアプリケーションをベンダー１２０から該ユーザ１１０を代理して購入することを要求することができる。
システムアーキテクチャ

図２は、仮想通貨の創出、償還及び精算に適した仮想通貨システム環境２００を示すハイレベルブロック概念図である。システム環境は、１以上のユーザ装置２１０、１以上の外部ウェブサイト２２０、サーバ２３０、ネットワーク２０１を備え得る。ユーザ装置２１０は、ネットワークを介してユーザ入力を受け取ることができかつデータを送受信することができる１以上のコンピュータ装置を備える。例えば、ユーザ装置２１０は、デスクトップコンピュータ、ラップトップコンピュータ、ポータブルコンピュータ、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、あるいは計算機能とデータ通信能力を含む他のどんな装置であってもよい。ユーザ装置２１０はネットワーク２０１を介して通信するように構成され、ネットワーク２０１は、有線と無線の通信システムの両方を使用する、ローカルエリアネットワーク及び／又はワイドエリアネットワークの組み合わせを構成し得る。

実施形態において、仮想通貨サーバ２３０はウェブサイト２２０を通じてアクセスされる。他の実施形態において、仮想通貨サーバ２３０はソーシャルネットワーキングウェブサイトを通じてアクセスされる。

ネットワーク２０１は、サーバ２３０に接続される。サーバ２３０は、創出モジュール２３１、移動モジュール２３２、償還モジュール２３３、データストアモジュール２３４、ユーザアカウントモジュール２３５、通信モジュール２３６を備える。他の実施形態において、サーバ２３０は、様々なアプリケーションのために追加モジュールや異なるモジュールを小数含んでいてもよい。

創出モジュール２３１は、価格と属性を特定しながら新たなクレジットを創出する。創出処理の実施形態が、図３に詳細に記載されている。一実施形態において、創出モジュール２３１はクレジットバケットを創出し、かつクレジットバケットに関連付けられた属性を決定する。該属性は次の１以上、前記バケット内のクレジットの数、内部値、外部値、額面価格、固有識別（"ＩＤ"）番号、タイムスタンプを含む。その他の識別属性が、クレジットバケットのために創出され得る。

データストアモジュール２３４は、データベース内にクレジットバケットに関する属性を入力し記憶する。実施形態において、データストアモジュール２３４は、クレジットバケットに関連付けられたＩＤ番号、前記バケット内のクレジットの数、内部値、外部値、クレジットバケットのタイムスタンプに関する情報を記録する。データストアモジュール２３４は、クレジットバケット又は一部のクレジットの取引履歴に関するデータを記録することができる。

参加者アカウントモジュール２３５は、仮想通貨システム内の参加者のアカウントに関する情報を記憶する。実施形態において、各参加者は、該参加者によって所有されるクレジットの記録を持つアカウントを有する。参加者アカウントモジュール２３５は、参加者のアカウント内のクレジットの数に関する情報と、各クレジットバケットに関連付けられたＩＤ番号を記憶する。データ記憶処理の詳細については、図４に示される。

移動モジュール２３２は、クレジットを仮想通貨システム内の参加者のアカウント間で移動する。移動モジュール２３２は、クレジットを送り側の参加者から受け取り側の参加者に移動することができる。例えば、移動モジュール２３２は、クレジットをセントラルマネージャ１００からユーザ１１０へ、第１ユーザ１１０から第２ユーザ１１０へ、あるいはベンダー１２０からユーザ１１０へ移動することができる。移動処理は、図５に詳細に記載される。

通信モジュール２３６は、様々なモジュールとネットワーク間の通信を可能にする。通信モジュールは、仮想精算システム環境での相互接続を可能にする。仮想通貨システムがウェブサイトを介してアクセスされる場合、通信モジュールはウェブサーバである。
仮想クレジットの創出

図３は、仮想通貨システム内におけるクレジットバケット創出の詳細な手順を示す。仮想クレジットの創出は、創出モジュール２３１が新たなクレジットバケットを創出する要求を受け取ると（３００）、始まる。前記要求は、１つのバケットの複数の新しいクレジットを創出するのに必要とされる現実通貨の総額を伴い得る。実施形態において、現実通貨の総額は、１つのバケットの複数の新しいクレジットを創出するのに必要とされない。創出モジュール２３１は、複数の新たなクレジットバケットを創出する複数の要求を受け取り得る。

創出モジュール２３１はまた、新たなバケットのために創出されるであろうクレジットの数を決定する（３１０）。各クレジットバケット毎に、創出モジュール２３１は前記クレジットバケットに割り当てる属性を決定する。例えば、創出モジュールはクレジットバケットの内部値を決定する（３２０）。内部値は、クレジットを創出するための初期交換レートに基づく。例えば、クレジットバケットを創出する初期費用が10.00ドルであるならば、内部値は0.10ドルである。１つのバケット内の各クレジットは、同じ内部値を割り当てられる。実施形態において、クレジットバケットの内部値はシステムのユーザから隠される。

創出モジュール２３１はまた、クレジットバケットの外部値を決定する（３３０）。外部値は、クレジットが現実世界通貨に交換される時点でのレートである。外部値は、バケット内の各クレジットに属する。例えば、100クレジットの１つのバケットのために、該バケット内の各クレジットは0.05ドルの外部値を有する。0.05ドルの外部値は、前記クレジットの償還時に100クレジットの価格を計算するのに用いられ、現実通貨の5.00ドルになる。バケット内の各クレジットは、同じ外部値を有する。実施形態において、クレジットバケットの外部値は、ユーザ又はベンダーから隠されるかもしれない。

仮想通貨システム内のすべてのクレジットは、不変の額面価格を与えられる。額面価格は、システム内のすべてのクレジットで同じであり得る。額面価格は、システム内の参加者に提示される表面上のクレジット価格である。例えば、クレジットは10仮想通貨単位の額面価格を有するかもしれないが、0.01ドルの内部値と0.05ドルの外部値を有するかもしれない。実施形態において、額面価格はクレジットの内部値又は外部値と一致し得る。他の実施形態において、額面価格はクレジットの内部値及び外部値と無関係であり得る。さらに別の実施形態において、額面価格は現実通貨価格が与えられる。例えば、クレジットは0.10ドルの額面価格を有するとして提示され得る。

創出モジュール２３１は、固有識別番号（"ＩＤ番号"）をクレジットバケットに割り当てる（３４０）。バケット内の各クレジットは同じＩＤ番号を持ち運び、同じバケットからの異なるクレジット総額がＩＤ番号に基づいた様々な取引を通じて追跡され得る。創出モジュール２３１はタイムスタンプをクレジットバケットに付与することができ（３５０）、タイムスタンプは、クレジットバケットが創出されたときの時間及び／又は日付に関する詳細を含み得る。創出モジュール２３１は、１以上の追加属性をクレジットバケットに関連付け得る。創出モジュール２３１は、クレジットバケットとすべての属性を結び付ける。

創出処理はデータストレージモジュール２３４とともに続けて、クレジットバケットとそれに関連付けられた属性に関する記録をデータストアに入力する（３６０）。データストアモジュール２３４は、それぞれの新たなバケット及び一致する識別属性に関するデータを記録することにより、複数のクレジットバケットのためにデータストアを更新することができる。

図４は、データストアモジュール４１０と参加者アカウントモジュール４２０の一実施形態を示す。データストアモジュール４１０は、データストア４３０にクレジットバケットに関連付けられたさまざまな属性に関する情報を入力し記憶する。実施形態において、データストアモジュール４１０は、クレジットバケットに関連付けられたＩＤ番号、バケット内のクレジットの数、内部値、外部値、クレジットバケットのタイムスタンプを記録する。データストアモジュール４１０は、バケットから償還されたクレジットの数及び／又は１以上のクレジットが償還された後のバケット内に残っているクレジットの数を記録することができる。データストアモジュール４１０は、クレジットバケットに関する少数又は追加の属性を入力し得る。データストアモジュール４１０は、仮想通貨システム内の各クレジットバケットに関する属性を記憶することができる。

一実施形態において、データストアモジュール４１０はＩＤ番号に従ってクレジットバケットに関する情報を記憶する。実施形態において、データストアモジュール４１０はクレジットバケットをデータベースに、それらが創出された時系列順に記録する。他の実施形態において、データストアモジュール４１０はクレジットバケットを、クレジットの内部値又は外部値に従って記録かつ整理する。

次に、データストアモジュール４１０は、或る数のクレジットを１以上の参加者のアカウントに割り当てる。一つのクレジットバケットは一人の参加者に割り当てられたり、複数の参加者に分けられたりし得る。一つのクレジットバケットが一人の参加者に割り当てられた場合、該バケットの属性は前記参加者のアカウント内にクレジットバケットと共に保持される。

参加者アカウントモジュール４２０は、１以上の参加者に割り当てられたクレジットの記録を作成する。図４は、クレジットバケットやクレジットバケットの一部が参加者のアカウント４４０に割り当てられ得ることを示す。参加者アカウントモジュール４２０は、クレジットに関するデータを各参加者のアカウント４４０に、データストアのデータに従って記録する。例えば、参加者アカウントモジュール４２０は、クレジットの数と前記クレジットのＩＤ番号に関するデータを、参加者アカウント４４０に記録することができる。実施形態において、参加者アカウントモジュール４２０は、仮想通貨システム内のすべてのアカウント４４０のデータベースを含む。一実施形態において、参加者アカウント４４０は、エントリ内のクレジットがもたらされた各エントリに関する情報からの当該バケットのバケットＩＤ番号を含んでいる、クレジットのエントリと各エントリに関する情報を持つテーブルを備える。実施形態において、参加者のクレジットは、参加者がクレジットを取得した又は購入したアカウント内の順番に従って、参加者のアカウント４４０に時系列に記入される。他の実施形態において、参加者アカウントモジュール４２０は、バケットの他の属性、例えばクレジットの数、ＩＤ番号、クレジットの内部値又は外部値などに基づき、テーブルにクレジットを記入する。

別の実施形態において、創出モジュール２３１は複数のクレジットクラスを創出することができる。創出されたクレジットの１クラスは、例えば外部値、内部値、あるいはここに記載された他の識別属性など、１以上の属性によって定義され得る。１つのクラスにおいて創出されるクレジットの数は、同じ定義属性を持つより多くのクレジットが創出されるように増加させることができる。クレジットクラスは、当該クラスにクレジットが創出された時点又は当該クラスに最初に創出されたクレジットの数によって制限されない。例えば、創出されたクレジットの或るクラスは、クレジット当たり0.05ドルの内部値のように、或る内部値によって定義され得る。該創出されたクレジットの１クラスは、より多くのクレジットが0.05ドルの内部値で創出されるたびに、その数を拡大することができる。創出モジュール２３１は、１乃至複数の識別属性により分類された複数のクレジットクラスを創出することができる。データストアモジュール２３４は、クレジットが創出されたとき及び償還されたときに、クレジットクラスに関するデータをクラス内に記録することができ、かつクレジットの数を該クラス内に入力することができる。
クレジットの移動

移動モジュール２３２は、新たに創出されたクレジットバケットを参加者のアカウントへ移動することができる。移動モジュール２３２は、一人の参加者（例えば、送り側の参加者）のアカウントから他の参加者（例えば、受け取り側の参加者）のアカウントへクレジットを移動する要求を受信すると、クレジットの転送を開始する。クレジットの移動が生じるとき、移動モジュール２３２は、送り側当事者のアカウントと受け取り側当事者のアカウントの両方を更新する。実施形態において、移動モジュール２３２は、送り側当事者のアカウントから移動されるクレジットの数に関する情報と、前記クレジットに関連付けられたバケットＩＤ番号を受け取る。移動モジュール２３２は、受け取り側のアカウントへ移動されるクレジットの数により送り側当事者のアカウント内のクレジットの数を減らす又は差し引くことによって、送り側当事者のアカウントを更新する。クレジットバケットのエントリ全体が、移動要求がバケット内の全てのクレジットを使い果たすならば、送り側当事者のアカウントから削除され得る。次に、移動モジュール２３２は、受け取り側当事者のアカウント内へ移動されたクレジットの数を追加することにより、受け取り側当事者のアカウントを更新することができ、受け取り側当事者のアカウントを更新することは、クレジットバケットに関する属性を受け取り側参加者のアカウントに関連付けることを含む。例えば、バケットＩＤ番号は、図４において移動されたクレジットに関連付けられる。したがって、転送モジュール２３２は、移動されたクレジットに関連付けられた属性に関するデータを保持したまま、参加者のアカウント間でクレジットを移動することができる。

クレジットが移動される順番は、仮想通貨システム内で異なり得る。実施形態において、クレジットは、参加者が取得した時系列順又はクレジットを購入した時系列順に従って移動される。先入れ先出し（"FIFO"）処理では、最初に取得又は購入されたクレジットが最初に移動される。

図５は、参加者Ａのアカウント５１０と参加者Ｂのアカウント５２０との間で、FIFO方式を用いたクレジット移動の一実施形態を示す。参加者Ａは、参加者Ａのアカウント５１０から参加者Ｂのアカウント５２０へ60クレジットを移動する要求を行うことができる。移動に先立って、参加者Ａのアカウント５１０は、参加者Ａが所有しているクレジット及び参加者Ａが該クレジットを取得した順番を表すエントリのリストを示す。参加者Ａのアカウント５１０内のクレジットの順番は、参加者ＡがＩＤ番号１を持つ５０クレジットを最初に取得したこと、それからＩＤ番号２を持つ２５クレジットを取得したことを示す。参加者Ｂのアカウント５２０は、前記移動に先立ってクレジットを有していない。移動モジュール２３２は、参加者Ａのアカウント５１０内の時系列のクレジットリストに基づいて、最も早く取得されたクレジット（ＩＤ番号１）を移動することができる。最初のクレジットバケットが移動要求を満たさない場合、次のクレジットバケット（ＩＤ番号２）が参加者Ｂのアカウント５２０へクレジットを移動する要求を満たすために用いられる。例えば、参加者Ａから参加者Ｂへ60クレジットを移動するために、移動モジュール２３２は最初に、ＩＤ番号１の50クレジットを削除することによって参加者Ａのアカウント５１０を更新する。これは、参加者Ａのアカウント５１０内のＩＤ番号１を持つ全てのクレジットを使い果たし、そしてＩＤ番号1のエントリが参加者Ａのアカウント５１０から削除される。次に、移動モジュール２３２は、参加者Ａのアカウント５１０からＩＤ番号２の10クレジットを削除する。移動モジュール２３２は、ＩＤ番号１の50クレジットのエントリとＩＤ番号２の10クレジットのエントリとを追加することにより、参加者Ｂのアカウントを更新する。移動後、ＩＤ番号２の15クレジットが参加者Ａのアカウント５１０に残る。

実施形態において、データストアモジュール２３４は、移動モジュール２３２により実施された各移動に関する情報を記録することができる。一実施形態において、データストアモジュール２３４は、移動されたクレジットの数、バケットＩＤ番号、参加者のアカウントを、クレジットが取引ごとに移動される参加者のアカウントへ記録することができる。データストアモジュール２３４は、クレジットが仮想通貨システム内で交換され様々な取引に割り当てられるような、クレジットバケットの全ての取引履歴を記憶することができる。

別の実施形態において、最も低い内部値を持つ参加者のアカウント内のクレジットは、より高い内部値を持つ他のクレジットより先に移動される。実施形態において、最も低い外部値を持つクレジットは、より高い外部値を持つ他のクレジットより先に移動のために選択される。他の実施形態において、最も高い外部値を持つクレジットは、参加者のアカウント内で他のクレジットより先に移動のために選択される。関連する実施形態において、参加者のアカウント内に保有された全てのクレジットの外部値が平均化されて、クレジットは該クレジットが取得されたときや該クレジットの外部値又は内部値を考慮することなしに等しく移動される。
クレジットの償還

図６は、償還処理の一実施形態を示す。償還モジュール２３３は、現実通貨への仮想クレジットの償還を実行することができる。償還モジュール２３３は、参加者のアカウントから償還されるクレジットの要求を受け取る（６００）。償還モジュール２３３は、１乃至複数のバケットＩＤ番号に従って参加者のアカウントに償還されるクレジットを特定する（６１０）。次に、前記クレジットに関連付けられた１乃至複数の外部値が特定される（６２０）。前記要求はまた、買い戻されるクレジットに関する情報を含めることができる。償還モジュール２３３は、参加者のアカウントから当該クレジットを削除し（６３０）、データベースから当該クレジットに関する記録を削除する（６４０）。償還モジュール２３３は、前記クレジットに関連付けられた外部値に基づいて、前記ユーザに現実通貨でクレジット価格を支払う（６５０）。償還されたクレジットとそれらに支払われた現実通貨との間の交換レートは、償還されているクレジットの外部値によって設定される。例えば、ベンダーは100クレジットバケットをセントラルマネージャからの現実通貨に交換するように要求するかもしれない。該クレジットは0.05ドルの外部値を持っているかもしれない、だからベンダーはクレジットバケットの償還時に現実通貨の5.00ドルを受け取り得る。

別の実施形態において、データストアモジュール２３４は、前記クレジットがシステムから償還されていることを示すために、データベース内の記録を削除し得る。参加者アカウントモジュール２３３はまた、償還されているクレジットを削除するように、参加者のアカウント内の記録を更新することができる。

実施形態において、あるタイプの参加者、例えばベンダーや第三者支払人だけが、クレジットを現実通貨に償還することができる。一実施形態において、個人のユーザは仮想通貨システム内でクレジットを購入しかつクレジットを商品やサービスに交換することができる、しかし個人のユーザはクレジットを現実通貨に償還されないかもしれない。セントラルマネージャは、ベンダーや第三者支払人からクレジットを償還する要求を受け取り、現実通貨の支払いを管理する。

一実施形態において、参加者のアカウント内で最も低い内部値を持つクレジットは、より高い内部値を持つ他のクレジットより先に償還され得る。実施形態において、最も低い外部値を持つクレジットは、より高い外部値を持つ他のクレジットより先に償還される。別の実施形態において、参加者のアカウント内に保有された全てのクレジットの外部値が平均化されて、前記クレジットは該クレジットの外部値を考慮することなしに等しく償還される。

実施形態において、参加者は、クレジットが現実通貨に償還されたときに税金を請求することができる。例えば、売上税は償還時に現実通貨の支払いに適用され得る。他の実施形態において、税金は仮想通貨システム内でのクレジット移動ごとに適用される。

図７は、クレジットを創出する処理、クレジットに関連付けられたＩＤ番号に基づいて様々な取引を通じてクレジットを移動し追跡する処理、及びクレジットを現実通貨に償還する処理の実施形態を示す。実施形態において、クレジットの創出は現実通貨の入力を必要とする（７０１）。前記クレジットは、１以上のユーザに割り当てられる。図７において、ユーザＡはＩＤ番号１を持つ100クレジットを割り当てられる（７１０）。前記クレジットは、例え該クレジットがより小さい一部や個々のクレジットに割り当てられていても、様々なアカウントを通じて追跡され得て、ＩＤ番号に基づき交換され得る。例えば、ユーザＡ（７１０）はＩＤ番号１を持つ50クレジットをベンダーＡ（７２０）に移動し、ＩＤ番号１を持つ50クレジットをユーザＢ（７３０）に移動する。次に、ベンダーＡ（７２０）は、ＩＤ番号１を持つ10クレジットをユーザＣ（７４０）に移動する。ユーザＢ（７３０）は、ＩＤ番号１を持つ20クレジットをベンダーＢ（７５０）に移動する。ＩＤ番号１を持つ複数のクレジット移動が、仮想通貨システム内の様々な参加者の間でこのように発生し得る。移動モジュール２３２はクレジットの各移動を実行することができ、データストアモジュール２３４は、クレジットが様々な参加者のアカウント間で移動されるときに、クレジットバケットの取引履歴を記憶することができる。最後に、ベンダーＢ（７５０）は現実通貨と引き換えにそのクレジットのすべてを償還する（７０２）。セントラルマネージャは、クレジットの創出（７０１）とクレジットの償還（７０２）を管理することができる。複数の参加者間での様々な他のタイプの移動が、発明の実施形態に従って発生し得る。
実施例
クレジットの配布

固有の内部値及び外部値を持つクレジットは、仮想通貨システム内での配布を可能にする。クレジットクラス又はクレジットバケットはゼロの内部値と共に創出され、かつクレジットをユーザへ配布するために用いられ得る。配布は、クレジットがユーザに費用をかけることなく与えられる場合に当該ユーザに生じ得る。例えば、新たなクレジットをあるユーザへ配布することは、あるユーザに新しいオンラインゲームやアプリケーションを使用するよう促す。ユーザは、配布されたクレジットを使用することにより無料でオンラインゲームやアプリケーションを試すことができる。実施形態において、セントラルマネージャはクレジットをユーザへ配布することができ、かつ仮想通貨システムを通じて前記クレジットの移動を追跡することができる。配布したクレジットの追跡は、セントラルマネージャがどこでどのように前記配布したクレジットが使われたかを調べるのに役立つ。それはまた、セントラルマネージャが、アカウント内に配布されたクレジットを有するユーザへのオファーを対象にすることのできるようにし得る。

実施形態において、セントラルマネージャは、クレジットをユーザへ配布する費用を補助することができる。例えば、セントラルマネージャは、0.00ドルの内部値と0.05ドルの外部値を持つ100クレジットの１つのバケットを創出することができ、かつ前記クレジットをユーザへ贈ることができる。ベンダーは、前記ユーザからの前記配布したクレジットと引き換えに5.00ドルのサービスを提供し得、該ベンダーは、前記クレジットバケットを5ドルの現実通貨価格で償還することができる。セントラルマネージャは、クレジットを創出する費用を補助し、かつそのクレジットが償還されたときに5.00ドルを支払う。

配布はまた、クレジットの創出費用を補助するのにベンダーを必要とし得る。例えば、100クレジットのバケットは、0.00ドルの内部値と0.05ドルの外部値と共に創出することができる。クレジットは、ユーザに招待状と共に、オンラインゲームのベンダーで該クレジットを使うように配布され得る。オンラインゲームベンダーは、100クレジットと引き換えに10.00ドルの価値があるサービスを提供し得る。ベンダーが100クレジットを償還するとき、ベンダーは0.05ドルの外部値に基づいた現実通貨で5.00ドルを受け取るだけである。この交換において、ベンダーは配布費用5.00ドルを前記ユーザに補助する。他の実施形態において、セントラルマネージャとベンダーの両方がユーザへクレジットを配布する費用を補助することができる。

関連する実施形態において、ユーザは優先活動や優先行動と引き換えにクレジットを獲得することができる。ベンダーは、クレジットをユーザへ、ユーザ参加やユーザ活動の報酬形態として配布することができる。例えば、オンラインゲーム開発者は、ユーザへそのゲームをプレイする機会や調査に参加する機会を、一定数のクレジットと引き換えに贈ることができる。ユーザが活動や調査を完了すると、開発者はクレジットをユーザへ配布することができる。ユーザは、前記配布されたクレジットを、通貨システム内の開発者のアプリケーション又は他のベンダーで使い得る。
割引

固有の内部値及び外部値を持つクレジットは、仮想通貨システム内で割引のために用いられ得る。

実施形態において、割引はクレジットが創出されるときに生じ得る。ユーザは、そのクレジットがクレジットの額面価格未満である内部値を有数する場合に、クレジットを購入することができる。例えば、100クレジットのバケットを創出する実際の費用は、10.00ドルであるかもしれない。割引は、0.09ドルの内部値を設定することにより、というよりむしろ0.10ドルの実際の費用を設定することにより、ユーザへ提供され得る。これは、ユーザがクレジット当たり0.09ドルの内部値に基づいて、9.00ドルの割引価格で100クレジットのバケットを購入できるようにする。ユーザはベンダーへ割り引かれたクレジットを移動する場合、ベンダーはクレジットの全額未満を受け取る。ユーザはクレジットの額面価格を見るだけであり、購入時の割引価格について認識していないかもしれない。

他の実施形態において、あるベンダーがある価格を、商品やサービスの実際の価格未満である商品やサービスの支払いとして受け入れたときに、割引が生じ得る。例えば、100クレジットのバケットは0.09ドルの外部値を有し得る。あるベンダーは、ユーザへ現実通貨で10.00ドルの実際の価値を有するサービスを提供し得る。該ベンダーは、前記100クレジットのバケットを受け入れることによってサービスの割引を可能にし、該ベンダーは100クレジットのバケットの償還時に9ドルを受け取る。このタイプの割引は、ユーザに商品やサービスを提供する費用を補助するのにベンダーを必要とする。

別の実施形態において、あるユーザのため商品及びサービスを割り引く費用は、セントラルマネージャとベンダーによって共有され得る。例えば、セントラルマネージャは、0.00ドルの内部値と0.05ドルの外部値を持つ100クレジットのバケットをユーザへ配布することができる。ユーザはクレジットバケットを、実際に10.00ドルの価値がある、ベンダーからの商品やサービスに交換することができる。ベンダーはクレジットバケットをセントラルマネージャから償還するときに、ベンダーは0.05ドルの外部値に基づいてセントラルマネージャから5.00ドルを受け取る。この交換において、セントラルマネージャは配布されたクレジットを創出する費用（5.00ドル）を補助し、ベンダーはユーザへ商品やサービスを提供する割引費用（5.00ドル）を補助する。

様々なタイプの割引が、割引費用が仮想通貨システム内のベンダー又はセントラルマネージャによって共有される場合に生じ得る。
再配分

他の実施形態において、ベンダーはクレジットをセントラルマネージャから購入することができ、かつ該クレジットをユーザへ割り引いて再配分することができる。例えば、ベンダーは0.05ドルの内部値を持つ100クレジットのバケットを購入することができ、それから該クレジットをユーザへクレジット当たり0.04ドル割り引いて販売する。実施形態において、ベンダーはクレジットをユーザへ無料（配布）で再配分することができる。この方法は、通貨システム内でクレジットを保持し、かつ全体的な流動性を向上させる。
アカウントを見ること及びユーザを対象にすること

実施形態において、個人ユーザのアカウント残高と該ユーザのアカウント内のクレジットのタイプは、他の参加者又は特定タイプの参加者例えばベンダーなどに明らかにされる。ユーザアカウント内のクレジットのタイプに関する情報は、該クレジットの他の属性のうちに、外部値又は内部値を含み得る。一実施形態において、個人ユーザは他の参加者、例えばセントラルマネージャやベンダーなどに、ユーザアカウントを見る許可を与えることができる。

他の実施形態において、セントラルマネージャ又はベンダーは、一定数のクレジット又は内部値や外部値を持つクレジットを有する個人ユーザを対象にし得る。例えば、セントラルマネージャは、配布されたクレジットを持つユーザを、仮想通貨システムからそれらのクレジットを削除するために、又はそれらのユーザに前記クレジットを使うよう促すために、対象にしたいかもしれない。他の実施形態において、セントラルマネージャ又はベンダーは、複数のクレジットを持つユーザを対象にし、それらのユーザに前記クレジットを使うよう勧め得る。システム内の他のクレジットと比較して低い外部値を持つクレジットを保持しているユーザはまた、支出の対象にされ得る。

別の実施形態において、セントラルマネージャ又はベンダーは、システム内でのユーザの活動履歴や取引履歴に基づいてユーザを対象にし得る。複数のクレジットを購入したり使ったりした履歴を持つユーザは、セントラルマネージャ又は特定ベンダーでクレジットを使うように、割引やインセンティブ（励み）を提供され得る。例えば、オンラインゲーム開発者（ベンダーの１つのタイプ）は、大規模なオンラインゲーミングに参加するユーザを、該ユーザを顧客として引き付けるために、対象にし得る。開発者は、ゲーム活動に参加しているユーザを決定するために、仮想通貨システム内の複数のユーザのアカウントと彼らの過去の取引を見得る。一実施形態において、開発者はまた、ユーザが開発者の製品やサービスを見た回数、又はユーザが同じようなベンダーの製品やサービスを見たあるいは購入した回数を決定することができる。別の実施形態において、開発者は、開発者ゲームでの排他的利用のためのクレジットバケットを購入するように、ユーザへオファーを提示することができる。実施形態において、クレジットバケットは対象にされたユーザへ割引価格で提示され得る。開発者はまた、ユーザをゲームに引き付けるために、クレジットバケットをユーザへ配布し得る。

関連する実施形態において、個人ユーザは、該個人ユーザが彼又は彼女の購入活動や支出活動を減らしている場合に通知され得る。前記通知は、電子メール、マルチメディアメッセージングサービス（MMS）、テキストメッセージ、ウェブページ警告、あるいは類似の電子通信媒体又はオンライン通信媒体を介して送信され得る。セントラルマネージャ又はベンダーは、ユーザに支出活動に再参加するよう促すために、クレジットを前記ユーザへ配布する。別の実施形態において、ユーザは、彼又は彼女があるベンダーで使うのに十分なクレジットを持っていない場合に通知され得る。ユーザは、特定の製品やサービスを購入するために該ユーザが必要とするクレジットがいくつであるかについて通知され得る。
払い戻し及びチャージバック

固有の内部値及び外部値を持つクレジットはまた、仮想通貨システム内での払い戻しとチャージバックの利用を可能にする。ユーザがクレジットバケットを購入し、後に前記クレジットを返すことを決めた場合、ユーザは該クレジットバケットの内部値に基づいた現実通貨で払い戻しを受け取ることができる。例えば、ユーザは100クレジットの購入のために5.00ドルを支払い、後にそれらの同100クレジットを返すことを決めた場合、ユーザは該クレジットに関連付けられた0.05ドルの内部値に基づいて、5.00ドルの払い戻しを受け取ることができる。セントラルマネージャは、前記クレジット価格をユーザに払い戻し、該クレジットをユーザのアカウントから削除する。実施形態において、ユーザはクレジットの払い戻しを要求し、第三者支払人又はベンダーを介して払い戻しを受け取る。ユーザがベンダーでクレジットを使った後にクレジットの払い戻しを要求する場合、該ベンダーはユーザに前記クレジット価格を払い戻し、セントラルマネージャは前記ベンダーのアカウントから前記クレジットを削除する。例えば、払い戻し要求がユーザ‐ベンダー取引後の一定期間内（すなわち、90日）に受け取られた場合、ベンダーはそのアカウント内でユーザのクレジットを維持することを許可され得る。

他の形態において、送り側の参加者は、受け取り側の参加者のアカウントに一定数のクレジットを移動することができる。クレジットが移動された後、受け取り側の参加者は移動されたクレジットを送り側の参加者へ戻し得る。移動されたクレジットは、例えばＩＤ番号、外部値又は内部値などの、前記クレジットに関連付けられた属性のいずれかによって特定され得る。前記クレジットは送り側の参加者のアカウントへ戻すことができ、受け取り側の参加者は前記移動されたクレジットの払い戻しを受け取ることができる。移動モジュール２３２は移動されたクレジットの返還を行うことができ、データストアモジュール２３４は前記払い戻し取引に関するデータを記録することができる。参加者アカウントモジュール２３５は、それぞれの参加者アカウント内の前記移動されたクレジットに関する記録を更新することができる。
貸し出し

一実施形態において、仮想通貨システム内のクレジットは貸し出しに用いられ得る。参加者（例えば、送り側の参加者や貸し出し側の参加者）は、受け取り側の参加者アカウントに一定数のクレジットを移動することにより、他の参加者（例えば、受け取り側の参加者や借り入れ側の参加者）へクレジットを貸し出し得る。実施形態において、貸し出し側の参加者は他の参加者へクレジットを貸し出す前に、他の参加者のアカウント内容を見ることができる。他の実施形態において、送り側の参加者はまた、関連付けられた属性、例えば外部値、内部値又はバケットＩＤ番号などに基づいて、移動されたクレジットを追跡することができる。例えば、セントラルマネージャは、一定数のクレジットを借り入れ側のユーザへ貸し出すことができ、かつバケットＩＤ番号に基づいて前記クレジットの使用を追跡することができる。前記貸し出されたクレジットに関するデータは、データストアに記録され得る。前記貸し出されたクレジットに関するデータ（つまり、貸し出し残高）もまた記録され、かつ送り側の参加者アカウント及び／又は受け取り側の参加者アカウント内に維持され得る。実施形態において、受け取り側の参加者は後に、前記貸し出されたクレジットを送り側の参加者へ返すか、又は貸し出し参加者に前記クレジットを支払うことができる。貸し出されたクレジット又は貸し出されたクレジット価格が返される場合、参加者アカウントとデータストアの両方が、貸し出し残高の記録を削除するように更新され得る。実施形態において、貸し出しは、ソーシャルネットワーク環境のユーザ間で生じ得る。
第三者支払人

実施形態において、第三者支払人は、ユーザに代わってクレジットを購入することができる。第三者支払人は、モバイルネットワークオペレーター（MNO）、キャリアサービスプロバイダ（CSP）、ワイヤレスサービスプロバイダ、又はその他の無線通信事業者として知られている携帯電話会社であり得る。第三者支払人はまた、モバイル仮想ネットワークオペレータ（MVNO）又は類似のエンティティ（entity）であり得る。実施形態において、第三者支払人は、電子決済プロバイダやオンライン決済サービスプロバイダー（PSP）である。

一実施形態において、携帯電話会社は、ユーザに代わってクレジットを購入することができ、かつユーザのアカウントにクレジット費用を請求することができる。第三者支払人は、クレジット購入のために追加料金（例えば、サーチャージ）をユーザに請求し得る。セントラルマネージャは、第三者支払人から現実通貨（マイナスのサーチャージ）を受け取ることができ、前記割り引かれた外部値を有するクレジットバケットをアカウントに前記サーチャージのために創出することができる。セントラルマネージャはそれから、ユーザに直接クレジットを提供することができる。

他の実施形態において、ユーザは、彼または彼女の携帯電話アカウント内の時間（minutes）をクレジット購入のために交換することができる。携帯電話会社は、携帯電話クレジットをユーザに提供している場合、前記ユーザは彼または彼女の携帯電話クレジット内で仮想クレジットを購入するように取引し得る。

別の実施形態において、第三者支払人は、セントラルマネージャ又はベンダーに代わってクレジットをユーザへ販売することができる。一実施形態において、第三者支払人は、ユーザへクレジットを販売するセントラルマネージャから、現実通貨のボーナスを与えられ得る。
概要

本発明の実施形態の上記説明は、説明の目的で示されたものである。開示されている形態そのもので本発明を網羅することも限定することも意図されていない。当業者は、本開示を踏まえて、多くの変更および変形が可能であることを理解できる。

本開示のいくつかの部分は、本発明の実施形態を、情報処理のアルゴリズム及び記号的表現に特有の言葉で記述した。これらアルゴリズム的記述及び記号的表現は、データ処理技術の当業者において、他の当業者に彼らの仕事の要旨を効果的に伝えるために、一般的に使われている。これらの動作は、機能的に、コンピュータ処理的に、又は、論理的に記述されたが、コンピュータプログラム又は同等な電子回路、マイクロコードなどにより実装できることは理解できる。更に、一般性を失することなしに、これらの動作の配置をモジュールとして適用することが時として便利なことは証明されている。上述した動作及び関連するモジュールは、ソフトウェア、ファームウェア、ハードウェア又はそれらの組み合わせにより実施できる。

上述したステップ、動作又は処理のいずれも、１以上のハードウェア又はソフトウェアモジュール単独で又は他の装置と組み合わせて、実装及び実行できる。一実施形態において、ソフトウェアモジュールは、上述したいずれの又は全てのステップ、動作、又は処理を実行するために、コンピュータプロセッサによって実行されるコンピュータプログラムコードを収納したコンピュータで読み取り可能な媒体を含むコンピュータプログラム製品として実装される。

本発明の実施形態は、本明細書に記載する動作を行う装置に関するものでもよい。この装置は必要な目的のために特別に構成されたものでもよく、及び／又はコンピュータに記憶されたコンピュータプログラムにより選択的に起動または再構成される汎用計算装置を備えてもよい。このようなコンピュータプログラムは、電子的命令を記憶するのに適した、コンピュータシステムバスに連結される、有形のコンピュータ読み取り可能記憶媒体または如何なる種類の媒体に記憶してもよい。更に、本明細書で参照する如何なる計算システムも、単一のプロセッサを含むか、計算能力を増大する目的で複数プロセッサによる設計を採用したアーキテクチャであってもよい。

本発明の実施の形態は搬送波に実現されたコンピュータデータ信号に関するもとのであってもよく、この場合、前記コンピュータデータ信号は、ここに説明されたコンピュータプログラムまたはその他のデータの組合せの実施の形態を含む。前記コンピュータデータ信号は、有形の媒体または搬送波という形で提供され、前記搬送波において変調されまたはその他の方法でエンコードされる製品であり、有形のものであり、任意の適当な伝送方法に従って伝送される。

最後に、明細書で用いられている文言は、主として、読み易さおよび教示目的のために選択されており、発明の主題を描写又は制限するために選択されたのではない。したがって、発明の対象の範囲は詳細な説明によって限定されるのではなく、むしろ、これに基づく特許出願に係る請求項により限定される。したがって、本発明の実施形態の開示は、説明を目的としており、以下の特許請求の範囲で明らかにされる本発明の範囲を限定しない。

Claims (35)

1. 仮想経済の複数の参加者それぞれのアカウントを記憶するステップと、
   新たな仮想通貨クレジットを創出する複数のリクエストを受け取るステップと、
   前記新たなクレジットを創出する各リクエスト毎に、
   プロセッサにより、創出されたクレジットの数及び該クレジットの１組の属性をデータストアに記録することと、前記属性は、該創出されたクレジット当たりに受け取った現実通貨のレートを表す内部値と、償還時にクレジット当たりに提供されるべき現実通貨のレートを表す外部値とを含み、
   前記創出されたクレジットを１以上の参加者のアカウントに割り当てることと、
   前記クレジットにそれらの属性を関連付けること、
   を行うステップと、
   送り側の参加者のアカウントから受け取り側の参加者のアカウントへとクレジットを移動する複数のリクエストを受け取るステップと、
   クレジットを移動する各リクエスト毎に、
   前記送り側の参加者からクレジット額を差し引くことと、
   前記受け取り側の参加者へ前記クレジット額を加えることと、
   前記受け取り側の参加者へ加えられた前記クレジットにそれらの属性を関連付けること、
   を行うステップと、
   或る参加者のアカウントからクレジットを償還する複数のリクエストを受け取るステップと、
   前記或る参加者のアカウントからクレジットを償還する各リクエスト毎に、
   プロセッサにより、前記或る参加者のアカウントから前記償還されるクレジットを差し引くことと、
   前記償還されるクレジットの前記外部値に基づき決定される現実通貨額を前記或る参加者へ提供することと、
   を行うステップと
   を備える方法。
2. 前記属性はさらに額面価格を備えており、該額面価格は当該システムにおいて参加者に提示される価格を表す、請求項１に記載の方法。
3. 前記参加者は、セントラルマネージャーを含む、請求項１に記載の方法。
4. 前記参加者は、１以上の個人ユーザを含む、請求項１に記載の方法。
5. 前記参加者は、１以上のベンダーを含む、請求項１に記載の方法。
6. 前記参加者は、１以上の第三者支払人を含む、請求項１に記載の方法。
7. 前記クレジットの内部値は、該クレジットの額面価格未満である、請求項２に記載の方法。
8. 前記クレジットの外部値は、該クレジットの額面価格未満である、請求項２に記載の方法。
9. 前記クレジットの内部値は、該クレジットの外部値未満である、請求項１に記載の方法。
10. 前記クレジットの外部値は、該クレジットの内部値未満である、請求項１に記載の方法。
11. 新たなクレジットを創出する少なくとも１つの前記リクエストに関し、前記クレジットを創出するのと交換で現実通貨額を受け取るステップをさらに備えてなり、該受け取る現実通貨額は前記創出されたクレジットの内部値に基づくことを特徴とする請求項１に記載の方法。
12. クレジットを移動する各リクエスト毎に、前記クレジットの移動についての記録をデータストアに記憶するステップをさらに備える請求項１に記載の方法。
13. 前記クレジットを移動する各リクエスト毎に、前記送り側の参加者からクレジット額を差し引くことは、前記クレジットがアカウントに加えられた順番に当該アカウント内のクレジットを差し引くことからなる請求項１に記載の方法。
14. 前記クレジットを移動する各リクエスト毎に、前記送り側の参加者からクレジット額を差し引くことは、前記アカウント内の他のクレジットと比較されるより小さい内部値を有する当該アカウント内のクレジットを差し引くことからなる請求項１に記載の方法。
15. 前記クレジットを移動する各リクエスト毎に、前記送り側の参加者からクレジット額を差し引くことは、前記アカウント内の他のクレジットと比較されるより小さい外部値を有する当該アカウント内のクレジットを差し引くことからなる請求項１に記載の方法。
16. 受け取り側の参加者のアカウントへゼロの内部値を有するクレジットを移動するリクエストを受け取るステップをさらに備える請求項１に記載の方法。
17. 前記送り側の参加者から前記受け取り側の参加者へとクレジットを移動する前記リクエストを受け取る前記ステップは、前記送り側の参加者による商品又はサービスの購入に結び付けられることを特徴とする請求項１に記載の方法。
18. 第１参加者へ第２参加者のアカウント残高を提供するステップをさらに備える請求項１に記載の方法。
19. 前記第１参加者はベンダーであり、前記第２参加者は個人ユーザであることを特徴とする請求項１８に記載の方法。
20. ゼロの内部値を有する１以上のクレジットを持つ個人ユーザのアカウントを選択するステップと、
    前記個人ユーザに前記クレジットと交換に商品又はサービスを購入するように勧めるステップと
    をさらに備える請求項１に記載の方法。
21. システム内の他のクレジットと比較して、より小さな外部値を有する１以上のクレジットを持つ個人ユーザのアカウントを選択するステップと、
    前記個人ユーザに前記クレジットと交換に商品又はサービスを購入するように勧めるステップと
    をさらに備える請求項１に記載の方法。
22. 前記クレジットを移動する１以上の前記リクエストに関して、該移動は送り側の参加者から受け取り側の参加者へのクレジットの貸し出しを含み、該貸し出しを実施することは、
    貸し出されたクレジット額の貸し出し残高をデータストア内に記憶するステップと、
    前記送り側の参加者のアカウント及び前記受け取り側の参加者のアカウントにおいて貸し出し残高を保持するステップと、
    １以上の移動を通して前記貸し出されたクレジットを追跡するステップと、
    前記貸し出しの支払を反映するために前記貸し出し残高を更新するステップと
    をさらに備える請求項１に記載の方法。
23. 前記新たなクレジットを創出するリクエストを、個人ユーザを代理して第三者支払人から受け取ることを特徴とする請求項１に記載の方法。
24. 前記第三者支払人は前記新たなクレジットを創出する前記リクエストに関して追加料金を課し、前記方法は、前記追加料金に基づいて前記新たなクレジットの前記外部値を割り引くステップをさらに備えることを特徴とする請求項２３に記載の方法。
25. 前記第三者支払人は、前記個人ユーザのアカウントを保持している携帯電話会社である、請求項２３に記載の方法。
26. 個人ユーザから前記創出されたクレジットを現実通貨に払い戻すリクエストを受け取るステップであって、前記創出されたクレジットは、前記クレジットを創出する前記リクエストの１つと関連付けられたものと、
    前記創出されたクレジットと関連付けられた前記内部値を取り出すステップと、
    前記個人ユーザのアカウントから前記創出されたクレジットを差し引くステップと、
    前記クレジットの内部値に基づいて、前記創出されたクレジットの価値を前記個人ユーザに現実通貨で払い戻すステップと
    をさらに備える請求項１に記載の方法。
27. 前記移動されたクレジットを前記送り側の参加者へ返すリクエストを、前記受け取り側の参加者から受け取るステップと、
    前記移動されたクレジットを特定するステップと、
    前記受け取り側の参加者のアカウントから前記移動されたクレジットを差し引くステップと、
    前記送り側の参加者のアカウントへ前記移動されたクレジットを加算するステップと
    をさらに備える請求項１に記載の方法。
28. 特定のベンダーと関連付けられた固有の識別番号を前記創出されたクレジットの属性とするステップと、
    前記創出されたクレジットを個人ユーザのアカウントに割り当てるステップと、
    前記個人ユーザに、該個人ユーザのアカウント内のクレジットの合計数を示すステップと、
    前記個人ユーザに、前記特定のベンダーと関連付けられた固有の識別番号を有する前記創出されたクレジットの数を示すステップと、
    商品又はサービスと交換に前記特定のベンダーだけに前記創出されたクレジットの移動を認めるステップであって、前記創出されたクレジットは、前記商品又はサービスの価格より小さい前記外部値に基づく償還価格を有するものと
    をさらに備える請求項１に記載の方法。
29. 仮想経済の複数の参加者それぞれのアカウントを記憶するステップと、
    プロセッサにより、１以上のクレジットを含んでなるクレジットバケットを創出するステップであって、前記クレジットバケットは、創出されるクレジット当たりに受け取った現実通貨のレートを表す内部値、及び償還時にクレジット当たりに提供される現実通貨のレートを表す外部値と関連付けられたものと、
    前記クレジットバケット内のクレジットを１以上の前記アカウントに割り当てるステップであって、各アカウント内の前記クレジットは、前記内部値又は前記外部値と関連付けられるものと、
    １以上の参加者の前記アカウント間でクレジットを移動するステップと、
    アカウント間で移動されたクレジットを追跡するステップであって、前記移動されたクレジットは、それらの内部値及び外部値との関連を保持するものであり、
    １つのアカウントから１以上のクレジットを償還するためのリクエストを前記プロセッサで受信するステップであって、前記償還されるクレジットは前記アカウントから差し引かれるものであり、前記アカウントに関連付けられた前記参加者は前記差し引かれたクレジットの外部値に従って現実通貨額を受け取るものと
    を備える方法。
    
30. 受け取り側の参加者のアカウントへゼロの内部値を有するクレジットを移動するステップをさらに備える請求項２９に記載の方法。
31. ゼロの内部値を有する１以上のクレジットを持つ参加者のアカウントを選択するステップと、
    前記参加者に前記クレジットと交換に商品又はサービスを購入するように勧めるステップと
    をさらに備える請求項２９に記載の方法。
32. 前記移動するクレジットは、送り側の参加者から受け取り側の参加者へのクレジットの貸し出しを含み、該貸し出しを実行することは、
    貸し出されたクレジット額の貸し出し残高をデータストア内に記憶するステップと、
    前記送り側の参加者のアカウント及び前記受け取り側の参加者のアカウントにおいて貸し出し残高を維持するステップと、
    １以上の移動を通して前記貸し出されたクレジットを追跡するステップと、
    前記貸し出しの支払を反映するために前記貸し出し残高を更新するステップと
    をさらに備える請求項２９に記載の方法。
33. 参加者から前記クレジットを現実通貨に払い戻すリクエストを受け取るステップと、
    前記クレジットと関連付けられた前記内部値を取り出すステップと、
    前記参加者のアカウントから前記クレジットを差し引くステップと、
    前記クレジットの内部値に基づいて、前記参加者に前記クレジット価格を現実通貨で払い戻すステップと
    をさらに備える請求項２９に記載の方法。
34. 前記移動されたクレジットを前記送り側の参加者へ返すリクエストを、受け取り側の参加者から受け取るステップと、
    前記移動されたクレジットを特定するステップと、
    前記受け取り側の参加者のアカウントから前記移動されたクレジットを差し引くステップと、
    前記送り側の参加者のアカウントへ前記移動されたクレジットを加算するステップと
    をさらに備える請求項２９に記載の方法。
35. 特定のベンダーと関連付けられた固有の識別番号を前記クレジットの属性とするステップと、
    前記クレジットを参加者のアカウントに割り当てるステップと、
    前記参加者に、該参加者のアカウント内のクレジットの合計数を示すステップと、
    前記参加者に、前記特定のベンダーと関連付けられた固有の識別番号を有する前記クレジットの数を示すステップと、
    商品又はサービスと交換に前記特定のベンダーだけに前記クレジットの移動を認めるステップであって、前記クレジットは、前記商品又はサービスの価格より小さい前記外部値に基づく償還価格を有するものと
    をさらに備える請求項２９に記載の方法。

Images