JP2018533774A - メッセージを配信するためのシステム及び方法 - Google Patents

Abstract

システムは、命令を格納するメモリと、メモリと通信するプロセッサと、を含む。命令を実行するとき、プロセッサは、ネットワークを介してモバイルデバイスとの通信を確立し、モバイルデバイスからサービスのユーザと関連付けられたユーザアイデンティティを識別するように構成される。プロセッサは、ユーザアイデンティティと関連付けられたユーザプロファイルを取得し、モバイルデバイスからサービスのためのサービスリクエストを開始するために、ユーザの意図を示すトリガイベントを識別するように構成される。プロセッサは、また、ユーザプロファイル及びトリガイベントに基づいて、プロモーションを決定し、モバイルデバイスへ送信されるプロモーションに関するメッセージを生成ように構成される。【選択図】図１

Description

関連出願の相互参照
本願は、２０１５年１０月２７日に出願された中国特許出願第２０１５１０７０８３５７．Ｘ号、２０１５年１１月２７日に出願された中国特許出願第２０１５１０８５１８５３．０号、２０１５年１２月２３日に出願された中国特許出願第２０１５１０９９１９２８．５号、及び２０１６年４月７日に出願された中国特許出願第２０１６１０２１６３６４．２号の優先権を主張する。上記参照される出願の各々は、それらの全体において参照により本明細書に明示的に援用される。

本願は、概して、サービスの提供の管理に関し、特に、ネットワークベースのシステム及び方法のサービスの供給の管理に関する。

輸送サービス及び食品注文サービス等のようなオンデマンドサービスは、より一般的になってきている。そのオンデマンドサービスを宣伝するために、企業は、バウチャー、クレジット又はディスカウント等のような形式でクーポンを消費者に配信する。消費者の特定のタイプに基づいて、対象のクーポンを配信することが可能なシステムが望まれる。

本開示の一態様は、命令を格納するメモリと、前記メモリと通信するプロセッサと、を含むシステムに向けられる。前記命令を実行するとき、前記プロセッサは、ネットワークを介してモバイルデバイスとの通信を確立し、前記モバイルデバイスからサービスのユーザと関連付けられたユーザアイデンティティを識別するように構成されてもよい。前記プロセッサは、前記ユーザアイデンティティと関連付けられたユーザプロファイルを取得し、前記モバイルデバイスからサービスのためのサービスリクエストを開始するために、前記ユーザの意図を示すトリガイベントを識別するように構成されてもよい。前記プロセッサは、また、前記ユーザプロファイル及び前記トリガイベントに基づいて、プロモーションを決定し、前記モバイルデバイスへ送信される前記プロモーションに関するメッセージを生成するように構成されてもよい。

本開示の別の態様は方法に関連される。前記方法は、ネットワークを介してモバイルデバイスとの通信を確立するステップと、前記モバイルデバイスからサービスのユーザと関連付けられたユーザアイデンティティを識別するステップと、を含んでもよい。前記方法は、前記ユーザアイデンティティと関連付けられたユーザプロファイルを取得するステップと、前記モバイルデバイスからサービスのためのサービスリクエストを開始するために、前記ユーザの意図を示すトリガイベントを識別するステップと、を含んでもよい。前記方法は、また、前記ユーザプロファイル及び前記トリガイベントに基づいて、前記ユーザアイデンティティと関連付けられるプロモーションを決定するステップと、前記モバイルデバイスへ送信される前記プロモーションに関するメッセージを生成するステップと、を含んでもよい。

本開示の更に別の態様は、コンピュータプログラム製品を具体化する非一時的コンピュータ可読媒体に向けられる。前記コンピュータプログラム製品は、コンピューティングシステムに、ネットワークを介してモバイルデバイスとの通信を確立させ、前記モバイルデバイスからサービスのユーザと関連付けられたユーザアイデンティティを識別させるように構成される命令を含む。前記命令は、前記ユーザアイデンティティと関連付けられたユーザプロファイルを取得させ、前記モバイルデバイスからサービスのためのサービスリクエストを開始するために、前記ユーザの意図を示すトリガイベントを識別させるように構成されてもよい。前記命令は、また、前記ユーザプロファイル及び前記トリガイベントに基づいて、前記ユーザアイデンティティと関連付けられるプロモーションを決定させ、前記モバイルデバイスへ送信される前記プロモーションに関するメッセージを生成させるように構成されてもよい。

本明細書で説明される方法、システム及び／又はプログラミングは、例示的な実施形態の観点から更に説明される。これらの例示的な実施形態は、図面を参照して詳細に説明される。これらの実施形態は、非限定な例示的な実施形態であり、同様の参照番号は、図面のいくつかを通じて同様の構造を表す。

図１は、本開示の一部の実施形態に係る例示的なメッセージ配信システムを示す。 図２は、本開示の一部の実施形態に係る図１に示されたシステムにおけるサーバの例示的な図である。 図３は、本開示の一部の実施形態に係る例示的なネットワークインターフェースのブロック図である。 図４は、本開示の一部の実施形態に係る図２のプロセッサの例示的な図である。 図５は、本開示の一部の実施形態に係る情報受信モジュールの例示的なアーキテクチャを示すブロック図である。 図６は、本開示の一部の実施形態に係る分析モジュールの例示的なアーキテクチャを示すブロック図である。 図７は、本開示の一部の実施形態に係る図６の分析モジュールのプロモーション設定ユニットの例示的な図である。 図８は、本開示の一部の実施形態に係るプロセッサにおける情報配信モジュールの例示的なアーキテクチャを示すブロック図である。 図９は、本開示の一部の実施形態に係る例示的なコンピューティングデバイスのブロック図である。 図１０は、本開示の一部の実施形態に係るメッセージを配信するための例示的な方法のフローチャートである。 図１１は、本開示の一部の実施形態に係るユーザプロファイルを決定するための例示的な方法のフローチャートである。 図１２は、本開示の一部の実施形態に係る価格の最大値を決定するための例示的な方法のフローチャートである。 図１３は、本開示の一部の実施形態に係る人口統計学的特徴の分類を決定するための例示的な方法のフローチャートである。 図１４は、本開示の一部の実施形態に係る候補都市を決定するための例示的な方法のフローチャートである。 図１５は、本開示の一部の実施形態に係る居住都市を決定するための例示的な方法のフローチャートである。 図１６は、本開示の一部の実施形態に係る職業を決定するための例示的な方法のフローチャートである。

以下の詳細な説明では、関連する開示の完全な理解を提供するために、具体的な詳細が多数、例として記載される。なお、当業者には当然のことながら、本開示はそのような詳細を用いずに実施されてもよい。他の場合には、本開示の態様を不必要にわかりにくくするのを避けるために、周知の方法、手順、システム、コンポーネント、及び／又は回路は、詳細を伴わずに相対的に高レベルで記載されている。

本明細書で用いられる用語「システム」、「デバイス」、「ユニット」及び／又は「モジュール」は、昇順で異なるレベルの異なる構成要素、要素、部分、区分又はアセンブリを区別するための一つの方法であることが理解されるであろう。しかし、当該用語は、それらが同一目的を実現する場合、他の表現によって置き換えられてもよい。

デバイス、ユニット又はモジュールが、別のデバイス、ユニット又はモジュール「上」、「に接続される」又は「に結合される」ことを示すとき、文脈が他に明確に示さない限り、他のデバイス、ユニット又はモジュール上、に接続される又はに結合される、若しくは他のデバイス、ユニット又はモジュールと通信する、若しくは他の介在するデバイス、ユニット又はモジュールが存在してもよいことが理解されるであろう。本明細書で用いられるように、用語「及び／又は」は、関連するリスト列挙された項目の１以上のいずれか及び全ての組み合わせを含む。

本明細書で用いられる専門用語は、特定の例の実施形態を説明する目的のみのものであり、限定的には意図されない。本明細書で用いられるように、単数「１つ」及び「前記」は、文脈が他に明確に示さない限り、複数形式も含むことが意図される。用語「備える」、「備えている」、「含む」及び／又は「含んでいる」は、本明細書で用いられるとき、述べられた特徴、整数、ステップ、動作、要素及び／又は構成要素の存在を特定するが、１以上の他の特徴、整数、ステップ、動作、要素、構成要素及び／又はそれらの組を排除するものではないことが更に理解されるであろう。

これら及び他の特徴、並びに本開示の特徴は、構造の関連要素の動作及び機能の方法並びに部分の組み合わせ及び製造経済と共に、その全てが本開示の一部を形成する添付の図面を参照して以下の詳細な説明を考慮してより明らかとなる。しかし、図面は、図示及び説明の目的のみのものであり、本開示の範囲を限定することを意図するものではないことが明示的に理解される。図面は、寸法取りではないことが理解される。

また、本開示のシステム及び方法は、乗り物の状態を決定することに関して主に説明されるが、これは、一つの例示的な実施形態のみであることがも理解されるべきである。本開示のシステム又は方法は、他の種類のオンデマンドサービスに適用されてもよい。例えば、本開示のシステム又は方法は、道路、海、宇宙又は同様のもの又はそれらの組み合わせを含む異なる輸送システムに適用されてもよい。輸送システムの乗り物は、タクシー、自家用車、ヒッチハイク、バス、電車、超特急列車、高速鉄道、地下鉄、船舶、航空機、宇宙船、熱気球、無人乗り物又は同様のもの又はそれらの任意の組み合わせを含んでもよい。輸送システムは、また、管理及び／又は配送を適用する任意の輸送システム、例えば、速達を送信及び／又は受信するためのシステムを含んでもよい。本開示のシステム又は方法の適用シナリオは、ウェブページ、ブラウザのプラグイン、クライアント端末、人工知能ロボット又は同様のもの又はそれらの任意の組み合わせを含んでもよい。

本開示では、用語「ユーザ」、「乗客」、「リクエスタ」、「サービスリクエスタ」、及び「顧客」は、区別なく用いられ、サービスをリクエスト又は注文するエンティティ又はツールを指す。また、本開示では、用語「ドライバ」、「プロバイダ」、「サービスプロバイダ」及び「サプライヤ」は、区別なく用いられ、サービスを提供する又はサービスの提供を容易にするエンティティ又はツールを指す。本開示では、用語「ユーザイクイップメント」は、サービスをリクエストする、サービスを注文する又はサービスの提供を容易にするために用いられるツールを指す。本開示では、用語「モバイル端末」は、サービスを提供するドライバにより用いられるツールを指す。本開示では、「ユーザ」及び「ユーザイクイップメント（ＵＥ）」は、区別なく用いられる。

本開示では、用語「サービスリクエスト」は、ユーザ（ユーザ自身又は第三者）、乗客、リクエスタ、サービスリクエスタ、消費者又は同様のもの又はそれらの任意の組み合わせにより開始されたリクエストを指す。リクエストされたサービスは、サービスの完了後に支払い可能である又は無料であってもよい。本開示では、用語「注文（オーダー）」は、サーバ（例えば、図１及び以下で説明されるサーバ１１０）から１以上のサービスプロバイダ（例えば、図１及び以下で説明されるサービスプロバイダ１４０）へ送られる注文（オーダー）を指す。注文（オーダー）は、それを受信するサービスリクエストに基づいてサーバによって生成されてもよい。

本開示で用いられる位置決め（ポジショニング）技術は、グローバルポジショニングシステム（ＧＰＳ）、グローバルナビゲーションサテライトシステム（ＧＬＯＮＡＳＳ）、コンパスナビゲーションシステム（ＣＯＭＰＡＳＳ）、ガリレオポジショニングシステム、準天頂衛星システム（ｑｕａｓｉ−ｚｅｎｉｔｈ ｓａｔｅｌｌｉｔｅ ｓｙｓｔｅｍ（ＱＺＳＳ））、ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ（ＷｉＦｉ）ポジショニングシステム、又は同様のもの又はそれらの任意の組み合わせを含んでもよい。上記の位置決めシステムの１以上は、本開示において区別しないで用いられてもよい。

本開示は、サービスのプロモーションについてのメッセージを決定及び配信するためのメッセージ配信システムの方法及びシステムを説明する。本明細書で開示される方法及びシステムは、プロモーションの属性、例えば、プロモーションのためのメッセージを配信するタイミング又はプロモーションの量、を決定することを目的とする。図１は、本開示の一部の実施形態に係る例示的なメッセージ配信システム１００を示す図である。メッセージ配信システム１００は、サーバ１１０、ネットワーク１２０、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０及びデータベース１５０を含んでもよい。モバイルユーザイクイップメント１３０へ配信されるメッセージは、クーポン、バウチャー、ディスカウント、又はクレジット等のようなプロモーションであってもよい。

サーバ１１０は、ユーザに関する情報及び／又はデータ（例えば、ユーザアイデンティティ又はユーザＩＤを通じて）を処理してもよい。例えば、サーバ１１０は、ネットワーク１２０を介してモバイルユーザイクイップメント１３０との通信を確立してもよい。サーバ１１０は、また、モバイルユーザイクイップメント１３０からサービスのユーザと関連付けられるユーザアイデンティティを識別し、ユーザアイデンティティと関連付けられるユーザ職業を決定又は取得してもよい。サーバ１１０は、更に、トリガイベントを識別又は検出し、ユーザプロファイル及びトリガイベントに基づいて、ユーザアイデンティティと関連付けられるプロモーションを決定してもよい。サーバ１１０は、また、モバイルデバイスへ送信されるプロモーションに関するメッセージを生成してもよい。一部の実施形態では、トリガイベントは、モバイルユーザイクイップメント１３０からサービスのためのサービスリクエストを開始するために、ユーザの意図を示すモバイルユーザイクイップメント１３０でのユーザによる指示又は操作であってもよい。例えば、トリガイベントは、モバイルユーザイクイップメント１３０からのサービスリクエストであってもよい。サーバ１１０は、モバイルユーザイクイップメント１３０からのサービスリクエストを受信及び処理してもよい。サーバ１１０は、また、モバイルユーザイクイップメント１３０へのサービスリクエストに応答してアクノリッジメントを送信してもよい。サーバ１１０は、更に、サービスリクエストに基づいてオーダーを生成し、生成されたオーダーを１以上のサービスプロバイダ１４０へブロードキャストしてもよい。一部の実施形態では、サーバ１１０は、モバイルユーザイクイップメント１３０へ配信されるプロモーションを決定してもよい。例えば、サーバ１１０は、ネットワーク１２０を通じてデータベース１５０に格納されるユーザＩＤのヒストリカルリクエストにアクセスし、ヒストリカルリクエストを処理してもよい。サーバ１１０は、情報を分析し、プロモーションを生成し、生成されたプロモーションを格納してもよい。一部の実施形態では、プロモーションは、いくつかの利益のあるクーポン（例えば、ある量のクレジット）であってもよい。プロモーションは、トリガイベントが生じたとき、メッセージとしてモバイルユーザイクイップメント１３０へ配信されてもよい。一部の実施形態では、トリガイベントは、モバイルユーザイクイップメント１３０上のプログラムが開始されること、モバイルユーザイクイップメント１３０上のプログラムのログイン情報が入力されること、ユーザＩＤのログインイベント、サービスのためのリクエスト又はユーザによる支払いであってもよい。一部の実施形態では、サーバ１１０は、単一サーバ又はサーバクラスタであってもよい。サーバクラスタは、集中型又は分散型であってもよい。一部の実施形態では、サーバ１１０は、ローカル又はリモートであってもよい。サーバ１１０は、ネットワーク１２０を介して、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０及び／又はデータベース１５０と通信してもよい。通信は、有線又は無線であってもよい。例えば、サーバ１１０は、ネットワーク１２０を介して、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０又はデータベース１５０に格納された情報及び／又はデータにアクセスしてもよい。別の例として、サーバ１１０は、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０又はデータベース１５０に直接接続され、そこに格納された情報及び／又はデータにアクセスしてもよい。一部の実施形態では、サーバ１１０は、クラウドプラットフォーム上に実装されてもよい。例にすぎないが、クラウドプラットフォームは、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散型クラウド、インタークラウド、マルチクラウド又は同様のもの又はそれらの任意の組み合わせを含んでもよい。

ネットワーク１２０は、単一ネットワーク又は異なるネットワークの組み合わせであってもよい。例えば、ネットワーク１２０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、パブリックネットワーク、プライベートネットワーク、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、バーチャルネットワーク、メトロポリタンエリアネットワーク（ＭＡＮ）、パブリックテレフォンスイッチドネットワーク（ＰＳＴＮ）又はそれらの組み合わせを含んでもよい。ネットワーク１２０は、ネットワーク１２０を介して情報を送信するために、ネットワーク１２０と接続する基地局及び／又はインターネット交換ポイント等のような有線又は無線ネットワークアクセスポイントを含んでもよい。ユーザ又はリクエスタは、モバイルユーザイクイップメント１３０からサーバ１１０へリクエストを送信し、ネットワーク１２０を介して結果又は提案を受信してもよい。サーバ１１０は、データベース１５０に格納された情報又はネットワーク１２０を介して直接的に情報にアクセスしてもよい。

ネットワーク１２０に接続されうるモバイルユーザイクイップメント１３０は、モバイルデバイス１３０−１、タブレットコンピュータ１３０−２、ラップトップコンピュータ１３０−３、組み込み装置１３０−４又は同様のもの又はそれらの組み合わせを含んでもよい。一部の実施形態では、モバイルデバイス１３０−１は、ウェアラブルデバイス、スマートモバイルデバイス、バーチャルリアリティデバイス、拡張現実デバイス又は同様のもの又はそれらの任意の組み合わせを含んでもよい。一部の実施形態では、ウェアラブルデバイスは、スマートブレスレット、スマートフットギア、スマートグラス、スマートヘルメット、スマートウォッチ、スマートクロージング、スマートバックパック、スマートアクセサリ又は同様のもの又はそれらの任意の組み合わせを含んでもよい。一部の実施形態では、スマートモバイルデバイスは、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ゲーミングデバイス、ナビゲーションデバイス、ポイントオブセール（ＰＯＳ）デバイス又は同様のもの又はそれらの任意の組み合わせを含んでもよい。一部の実施形態では、バーチャルリアリティデバイス及び／又は拡張現実デバイスは、バーチャルリアリティヘルメット、バーチャルリアリティグラス、バーチャルリアリティパッチ、拡張現実ヘルメット、拡張現実グラス、拡張現実パッチ又は同様のもの又はそれらの任意の組み合わせを含んでもよい。例えば、バーチャルリアリティデバイス及び／拡張現実デバイスは、Ｇｏｏｇｌｅ Ｇｌａｓｓ、Ｏｃｕｌｕｓ Ｒｉｆｔ、Ｈｏｌｏｌｅｎｓ、Ｇｅａｒ ＶＲ等を含んでもよい。一部の実施形態では、組み込み装置１３０−４は、オンボードコンピュータ、オンボードテレビジョン等を含んでもよい。一部の実施形態では、モバイルユーザイクイップメント１３０は、ユーザ及び／又はユーザと関連付けられるモバイルユーザイクイップメント１３０の位置を見つけるための位置決め技術を有するデバイスであってもよい。メッセージを配信するためのトリガイベントは、モバイルユーザイクイップメント１３０で生じる。一部の実施形態では、トリガイベントは、サービスインターフェースの操作を含んでもよく、サービスインターフェースは、モバイルユーザイクイップメント１３０にインストールされたサービスアプリケーション、又はモバイルユーザイクイップメント１３０にインストールされたサードパーティソフトウェア又はインターネットブラウザに表示されるサービスインターフェースであってもよい。一部の実施形態では、サービスアプリケーションは、サービスをリクエストするためにモバイルユーザイクイップメント１３０にソフトウェアインストールされてもよい。一部の実施形態では、トリガイベントは、サービスアプリケーションの起動操作、サービスリクエスト操作、又はサービスの支払い操作を含んでもよい。

モバイルユーザイクイップメント１３０によってリクエストされるサービスは、異なる種類であってもよい。例えば、ユーザＩＤに関連付けられるモバイルユーザイクイップメント１３０は、スポーツユーティリティビークル（ＳＵＶ）、ラグジュアリーカー（ＬＵＸ）、セダン、電気自動車又はタクシーのサービスをリクエストしてもよい。サービスの種類は、ユーザが選択又はクリックするためにモバイルユーザイクイップメント１３０上のリスト又はタグでのオプションとして表示されてもよい。一部の実施形態では、サーバ１１０がモバイルユーザイクイップメント１３０へ配信するクーポンは、特定の種類のサービスのためにユーザによって使用されるが、別の種類のサービスで使用されてもよい。一部の実施形態では、ヒストリカルリクエストは、異なる種類のサービスのグループに分類され、プロモーションは、サービスの種類のヒストリカルリクエストに応じて決定されてもよい。サービスの種類に関するトリガイベント（例えば、ユーザがモバイルユーザイクイップメント１３０で特定の種類のサービスを選択する）が検出されるとき、プロモーション（例えば、クーポン）は、同一種類のサービスのヒストリカルリクエストに基づいてサーバ１１０によって決定され、モバイルユーザイクイップメント１３０へ配信されてもよい。

サービスプロバイダ１４０は、タイプ１、タイプ２、．．．、タイプｎ（図１にそれぞれ１４０−１、１４０−２、．．．、１４０−ｎと示される）のような特定の種類のサービスと関連付けられてもよい。一部の実施形態では、サービスプロバイダ１４０によって行われるサービスは、サービスタイプ分類ストラテジーに基づいて分類されてもよい。例えば、サービスタイプ分類ストラテジーは、サービスを行う乗り物の種類（例えば、乗り物タイプ１６０−１、１６０−２又は１６０−ｎ）に基づいて特定のサービスを分類することであってもよい。サービスタイプ１、タイプ２、．．．、タイプｎは、それぞれ、乗り物タイプ１６０−１、１６０−２及び１６０−ｎに対応してもよい。一部の実施形態では、乗り物タイプは、ＳＵＶ、ＬＵＸ、バス、タクシー又は他のタイプであってもよい。一部の実施形態では、サービスタイプ分類ストラテジーは、サービスを行う乗り物の動力形式に基づいてサービスを分類してもよい（例えば、ガス動力、ディーゼル動力、電気又はハイブリッドカー）サービスタイプ分類ストラテジーは、任意の形式のものであり、サーバ１１０によって調整されてもよいことが留意されるべきである。一部の実施形態では、サービスタイプ分類ストラテジーは、サーバ１１０へアクセス可能なストレージ２２０又はデータベース１５０に格納されてもよい。サービスプロバイダ１４０は、サーバ１１０で登録され、それが行うサービスに関する情報をサーバ１１０へ送信してもよい。サービスタイプは、ユーザが選択するために利用可能なモバイルユーザイクイップメント１３０上に表示されてもよい。

データベース１５０は、ユーザの登録情報（つまり、乗員又はサービスリクエスタ）及びサービスプロバイダを格納する。データベース１５０は、また、ユーザに関するヒストリカル情報及びサービスプロバイダを格納してもよい。ヒストリカル情報は、例えば、ユーザによる以前のリクエスト、又はどのようにサービスプロバイダが以前のサービスに関して行われるかに関する情報を含んでもよい。図１に示されるように、データベース１５０は、ネットワーク１２０を通じてサーバ１１０へ接続され、かつアクセス可能であってもよい。一部の実施形態では、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０及び／又はサードパーティは、ネットワーク１２０を介してデータベース１５０にアクセスしてもよい。一部の実施形態では、データベース１５０とネットワーク１２０との間に１つのゲートウェイが存在してもよく、認証が必要であってもよい。よって、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０及び／又はサードパーティは、ネットワーク１２０を介してデータベース１５０にアクセスしうる。

以下に説明されるメッセージ配信システムは、システムの一例を示すために単に提供され、本開示の範囲に限定するように意図されないことが留意されるべきである。

図２は、本開示の一部の実施形態に係る図１に示されるシステムにおいて例示的なサーバ１１０のブロック図である。サーバ１１０は、プロセッサ２１０、ストレージ２２０及びネットワークインターフェース２３０を含んでもよい。プロセッサ２１０は、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０、データベース１５０又は他のモジュール又はサーバ１１０内部のユニットから受信された情報を処理してもよい。一部の実施形態では、当該情報は、モバイルユーザイクイップメント１３０からのサービスリクエスト、登録情報又はデータベース１５０からのヒストリカルリクエストに関する情報を含んでもよい。プロセッサ２１０は、ストレージのためのストレージ２２０へ、処理された情報を送信してもよい。一部の実施形態では、処理された情報は、いくつかの利益のあるクーポン等のようなプロモーションを含んでもよい（例えば、特定量のクレジット又はディスカウント）。一部の実施形態では、プロセッサ２１０は、１以上のプロセッサ（例えば、シングルコアプロセッサ又はマルチコアプロセッサ）を含んでもよい。例にすぎないが、プロセッサ２１０は、中央演算ユニット（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け命令セットプロセッサ（ＡＳＩＰ）、グラフィック演算ユニット（ＧＰＵ）、物理演算ユニット（ＰＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックデバイス（ＰＬＤ）、コントローラ、マイクロコントローラユニット、縮小命令セットコンピュータ（ＲＩＳＣ）、マイクロプロセッサ又は同様のもの又はそれらの組み合わせを含んでもよい。

ストレージ２２０は、プロセッサ２１０に対する命令を格納し、命令を実行するとき、プロセッサ２１０は、本開示に記載される１以上の機能を実行してもよい。例えば、ストレージ２２０は、クーポン（例えば、クレジット又はディスカウント）の利益の量を決定するために、プロセッサ２１０によって実行された命令を格納してもよい。ストレージ２２０は、また、特定の機能を実行するためにプロセッサ２１０のために必要なデータを格納してもよい。例えば、ストレージ２２０は、プロセッサ２１０から送信されたクーポン等のようなプロモーションを格納し、トリガイベントが生じたとき、プロモーションは、メッセージの形式でモバイルユーザイクイップメント１３０へ配信されてもよい。別の例として、ストレージ２２０は、モバイルユーザイクイップメント１３０（又は複数のモバイルユーザイクイップメント１３０）からのサービスリクエストを格納し、その後、サービスリクエストに基づいて生成されたオーダーをサービスプロバイダ１４０（又は複数のサービスプロバイダ１４０）へ送信する。ストレージ２２０は、更に、クーポンの利益（例えば、クレジット又はディスカウント）の量を計算するための重み付け係数を決定するためにプロセッサ２１０にデータを格納してもよい。例えば、１以上のサービスタイプ分類ストラテジーは、サービスプロバイダ１４０をタグ付けするために用いられてもよい。サービスタイプは、クーポンの利益の量を計算するために用いられるヒストリカルリクエストをフィルタリングするためのパラメータであってもよい。サービスプロバイダ１４０は、サービスタイプに応じて複数のサービスタイプのうちの１つに分類されてもよい。サービスタイプ分類ストラテジーは、サーバ１１０によって調整されてもよい。クーポンの利益の量を決定するために用いられる他の情報は、ストレージ２２０に格納されてもよい。

一部の実施形態では、ストレージ２２０は、マスストレージ、リムーバブルストレージ、揮発性リードアンドライトメモリ、リードオンリーメモリ（ＲＯＭ）又は同様のもの又はそれらの任意の組み合わせを含んでもよい。例示的なマスストレージは、磁気ディスク、光学ディスク、ソリッドステートドライブ等を含んでもよい。例示的なリムーバブルストレージは、フラッシュデバイス、フロッピーディスク、光学ディスク、メモリカード、ジップディスク、磁気テープ等を含んでもよい。例示的な揮発性リードアンドライトメモリは、ランダムアクセスメモリ（ＲＡＭ）を含んでもよい。例示的なＲＡＭは、ダイナミックＲＡＭ（ＤＲＡＭ）、ｄｏｕｂｌｅ ｄａｔｅ ｒａｔｅ ｓｙｎｃｈｒｏｎｏｕｓ ｄｙｎａｍｉｃ ＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、サイリスタＲＡＭ（Ｔ−ＲＡＭ）、及びゼロキャパシタＲＡＭ（Ｚ−ＲＡＭ）等を含んでもよい。例示的なＲＯＭは、マスクＲＯＭ（ＭＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、デジタルバーサタイルディスクＲＯＭ等を含んでもよい。

ネットワークインターフェース２３０は、ネットワーク１２０とのインターフェース及び／又はシステムの１以上の構成要素とのインターフェースであってもよい（例えば、サーバ１１０、モバイルユーザイクイップメント１３０、サービスプロバイダ１４０及びデータベース１５０）。一部の実施形態では、ネットワークインターフェース２３０は、モバイルユーザイクイップメントインターフェース３１０（本明細書では「ＵＥインターフェース」とも呼ばれる）及びサービスプロバイダインターフェース３２０を含んでもよい。一部の実施形態では、ネットワークインターフェース２３０は、システム１００の他の構成要素と通信するための他のインターフェース（図示せず）を含んでもよい。例えば、ネットワークインターフェース２３０は、データベースへデータを送信するため又はデータベース１５０からデータを受信するためのデータベースインターフェース（図示せず）を含んでもよい。

ＵＥインターフェース３１０は、サーバ１１０とモバイルユーザイクイップメント１３０との間の通信を容易にする。例えば、モバイルユーザイクイップメント１３０からのサービスリクエストは、ＵＥインターフェース３１０を通じてサーバ１１０へ送信されてもよい。別の例として、サーバ１１０は、ＵＥインターフェース３１０を介してモバイルユーザイクイップメント１３０から、トリガイベントの発生を示すモバイルユーザイクイップメント１３０上での操作に関する情報を受信してもよい（つまり、ユーザは、モバイルユーザイクイップメント１３０上でサービスリクエストを開始する）。ＵＥインターフェース３１０は、また、モバイルユーザイクイップメント１３０へ情報を送信してもよい。例えば、サーバ１１０は、サービスリクエストへの応答を、ＵＥインターフェース３１０を介してモバイルユーザイクイップメント１３０へ送信してもよい。別の例として、モバイルユーザイクイップメント１３０の位置情報は、候補サービスプロバイダへのサービスリクエストに基づいて生成されたオーダーをブロードキャストするために、特定領域における候補サービスプロバイダを決定するＵＥインターフェース３１０を通じてサーバ１１０によって受信されてもよい。更に別の例として、サーバ１１０は、ＵＥインターフェース３１０を介してモバイルユーザイクイップメント１３０へのクーポン等のようなプロモーションのメッセージを配信してもよい。

サービスプロバイダインターフェース３２０は、サーバ１１０とサービスプロバイダ１４０との間の通信を容易にする。例えば、サーバ１１０は、サービスプロバイダインターフェース３２０を通じてサービスプロバイダ１４０へオーダーを送信してもよい。別の例として、ガイダンス、マネジメントポリシー又はインセンティブポリシー等のような情報は、サービスプロバイダインターフェース３２０を介してサービスプロバイダ１４０へサーバ１１０から送信されてもよい。サービスプロバイダ１４０は、また、サービスプロバイダインターフェース３２０を通じてオーダーへの応答（例えば、オーダーを許可する又は拒否する）をサーバ１１０へ送信してもよい。別の例として、サービスプロバイダ１４０の位置情報は、候補サービスプロバイダ１４０へのオーダーをブロードキャストするために、特定領域における候補サービスプロバイダを決定するサービスプロバイダインターフェース３２０を通じてサーバ１１０によって受信されてもよい。

一部の実施形態では、ネットワークインターフェース２３０（例えば、ＵＥインターフェース３１０、サービスプロバイダインターフェース３２０）は、いずれかの種類の有線又は無線ネットワークインターフェースであってもよい。例にすぎないが、ネットワークインターフェース２３０（例えば、ＵＥインターフェース３１０、サービスプロバイダインターフェース３２０）は、ケーブルネットワークインターフェース、ワイヤラインネットワークインターフェース、光ファイバーネットワークインターフェース、テレコミュニケーションネットワークインターフェース、イントラネットインターフェース、インターネットインターフェース、ローカルエリアネットワーク（ＬＡＮ）インターフェース、ワイドエリアネットワーク（ＷＡＮ）インターフェース、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）インターフェース、メトロポリタンエリアネットワーク（ＭＡＮ）インターフェース、ワイドエリアネットワーク（ＷＡＮ）インターフェース、パブリックテレフォンスイッチドネットワーク（ＰＳＴＮ）インターフェース、ブルートゥース（登録商標）ネットワークインターフェース、ＺｉｇＢｅｅネットワークインターフェース、近距離通信（ＮＦＣ）ネットワークインターフェース又は同様のもの又はそれらの組み合わせを含んでもよい。

一部の実施形態では、ネットワークインターフェース２３０（例えば、ＵＥインターフェース３１０、サービスプロバイダインターフェース３２０）は、プログラミング及び／又はコンピュータ言語に基づいて実装されてもよい。ネットワークインターフェース２３０（例えば、ＵＥインターフェース３１０、サービスプロバイダインターフェース３２０）は、１以上のネットワークにサーバ１１０を結合する回路を含み、１以上の通信プロトコル及びｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、ｃｏｄｅ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ（ＣＤＭＡ）、ｔｉｍｅ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ（ＴＤＭＡ）、ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ（ＧＰＲＳ）、ｅｎｈａｎｃｅｄ ｄａｔａ ｒａｔｅ ｆｏｒ ＧＳＭ ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ｗｉｄｅｂａｎｄ ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ（ＷＣＤＭＡ（登録商標））、ｈｉｇｈ ｓｐｅｅｄ ｄｏｗｎｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ（ＨＳＤＰＡ）、ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ（ＵＤＰ）、ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）、ショートメッセージサービス（ＳＭＳ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、超広域帯（ＵＷＢ）、ＩＥＥＥ ８０２．１６ ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ ｍｉｃｒｏｗａｖｅ ａｃｃｅｓｓ（ＷｉＭａｘ）、ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｅｄ ｐｒｏｔｏｃｏｌ／ｒｅａｌ−ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（ＳＩＰ／ＲＴＰ）又はいずれかの種類の他の無線通信プロトコルを含む技術による使用のために構築される。

図４は、本開示の一部の実施形態に係る例示的なプロセッサ２１０の図である。プロセッサ２１０は、情報受信モジュール４１０、分析モジュール４２０、及び情報配信モジュール４３０を含んでもよい。情報受信モジュール４１０は、モバイルユーザイクイップメント１３０からのサービスリクエストを受信してもよい。情報受信モジュール４１０は、また、トリガイベントの発生（つまり、ユーザがモバイルユーザイクイップメント１３０上でサービスリクエストを開始する）を示すモバイルユーザイクイップメント１３０上での操作に関する情報、及び／又はデータベース１５０から（ユーザＩＤと関連付けられた）ユーザの登録情報及びヒストリカルリクエストを受信してもよい。一部の実施形態では、情報受信モジュール４１０は、モバイルユーザイクイップメント１３０から又はネットワークインターフェース２３０を通じてデータベース１５０から情報を受信してもよい。図５に示されるように、情報受信モジュール４１０は、操作受信モジュール５１０及びユーザＩＤ受信ユニット５２０を含んでもよい。一部の実施形態では、ユーザＩＤ受信ユニット５２０は、ユーザＩＤと関連付けられるヒストリカルリクエストに関する情報及び／又はデータベース１５０からユーザＩＤと関連付けられる登録情報を受信してもよい。一部の実施形態では、ユーザＩＤと関連付けられるヒストリカルリクエストに関する情報及び／又はデータベース１５０からユーザＩＤと関連付けられる登録情報は、クーポンの利益の量等のようなプロモーションを決定するために用いられてもよい。一部の実施形態では、操作受信モジュール５１０は、ネットワーク１２０を通じてモバイルユーザイクイップメント１３０からサービスリクエストに関するイベントをトリガする動作に関する情報を受信してもよい。一部の実施形態では、操作受信モジュール５１０によって受信される動作に関する情報は、トリガイベントを検出するために用いられてもよい。一部の実施形態では、プロモーションは、トリガイベントの前に決定され、ストレージ２２０に格納されてもよい。プロセッサ２１０が、操作受信ユニット５１０によって受信された操作に関する情報がトリガイベントを示すことが決定された場合、ストレージ２２０に格納されたプロモーションは、モバイルユーザイクイップメント１３０へ配信されてもよい。

ユーザＩＤ受信ユニット５１０によって受信されるヒストリカルリクエスト及び登録情報は、ユーザと関連付けられる人口統計学的特徴（ｄｅｍｏｇｒａｐｈｉｃ ｆｅａｔｕｒｅ（ＤＦ））を含んでもよい。ＤＦは、ユーザの１以上のカテゴリを識別するために用いられてもよい。ヒストリカルリクエスト及び登録情報は、また、ユーザによる複数のヒストリカルサービスリクエストと関連付けられるリクエスト統計（ｒｅｑｕｅｓｔ ｓｔａｔｉｓｔｉｃｓ（ＲＳ））及び／又はユーザによるヒストリカルサービスリクエストの支出を示す支出統計（ｅｘｐｅｎｄｉｔｕｒｅ ｓｔａｔｉｓｔｉｃｓ（ＥＳ））を含んでもよい。ＤＦは、ユーザＩＤと関連付けられる登録情報の一部又は全部を含んでもよい。一部の実施形態では、ユーザの１以上の人口統計学的特徴は、性別、職業及び／又は年齢層を含んでもよい。一部の実施形態では、ユーザと関連付けられるＲＳは、ユーザによるヒストリカルサービスリクエストの数、少なくとも１つのプロモーションを有するヒストリカルサービスリクエストの数、ヒストリカルサービスの平均走行距離（マイレージ）、及び／又は複数のヒストリカルサービスの開始及び行先を含んでもよい。ＲＳは、また、そのヒストリカルリクエストが開始された又はヒストリカルサービスが行われた都市と関連付けられる都市係数を含んでもよい。一部の実施形態では、ＥＳは、ヒストリカルサービスリクエストの総支出、ヒストリカルサービスリクエストの平均支出、及び／又はヒストリカルサービスリクエストで用いられたプロモーション（クレジット又はディスカウント）の総量を含んでもよい。

分析モジュール４２０は、情報受信モジュール４１０から受信されるヒストリカルリクエスト及び／又は登録情報に基づいてクーポンの利益の量を決定してもよい。図６に示されるように、分析モジュール４２０は、期間設定ユニット６１０、ユーザプロファイル分析ユニット６２０、及びプロモーション設定ユニット６３０を含んでもよい。一部の実施形態では、ヒストリカルリクエスト及び登録情報は、ユーザＩＤ受信ユニット５２０から期間設定ユニット６１０へ送信されてもよい。期間設定ユニット６１０は、ヒストリカルリクエストをフィルタリングするための１以上の期間を設定する。一部の実施形態では、期間は、異なるユーザＩＤ又は異なる状況下で調整されてもよい。一部の実施形態では、ヒストリカルリクエストの期間は、ストレージ２２０に格納される一部のプリセット値に基づいて決定されてもよい。期間設定ユニット６１０は、１以上のプリセット期間内にヒストリカルリクエストを選択するためのフィルタとして実行してもよい。一部の実施形態では、フィルタとして機能する期間設定ユニット６１０は、情報受信モジュール４１０において決定され、ユーザＩＤ受信ユニットから受信されるデータ５２０は、ユーザプロファイル分析ユニット６２０へ直接送信されてもよい。

一部の実施形態では、サーバ１１０が、特定の種類のサービスと関連付けられるサービスリクエストを受信する場合、サーバ１１０は、サービスリクエストと関連付けられるサービスの種類を実行しうる複数のサービスプロバイダ１４０へサービスリクエストをブロードキャストしてもよい。サービスリクエストが受信される又は他のトリガイベント（例えば、サービスをリクエストするためのモバイルユーザイクイップメント１３０でのアプリケーション）がサーバ１１０によって検出される場合、サーバ１１０は、モバイルユーザイクイップメント１３０へクーポンを配信する。クーポンの利益の量は、登録情報及び／又はヒストリカルリクエストのデータに基づいて決定されてもよい。一部の実施形態では、クーポンの利益の量を計算するために用いられるヒストリカルリクエストは、特定の種類のサービスに限定されてもよい。例えば、モバイルユーザイクイップメント１３０がサーバ１１０へラグジュアリーカーサービスのサービスリクエストを送信するとき、クーポンは、ラグジュアリーカーサービスのヒストリカルリクエストに基づいて決定されるが、全ての種類のサービスではない。一部の実施形態では、分析モジュール４２０のサービスタイプ設定ユニット６４０は、クーポンを決定するためにユーザ（例えば、ユーザＩＤをマッチングすることによって）と関連付けられるヒストリカルリクエストをフィルタする。

一部の実施形態では、クーポンは、サービスリクエストが送信される又はサービスが行われた都市に基づいて決定されてもよい。サーバ１１０は、それが受信するモバイルユーザイクイップメント１３０の位置に基づいて都市情報を決定してもよい。例えば、サーバ１１０がモバイルユーザイクイップメント１３０からのサービスリクエストを受信した場合、クーポンは、現在のリクエストと同一都市と関連付けられるヒストリカルリクエストに基づいて決定されてもよい。分析モジュール４２０は、現在のリクエストと同一都市と関連付けられるユーザと関連付けられるヒストリカルリクエストをフィルタしてもよい。

ユーザプロファイル分析ユニット６２０は、期間設定ユニット６１０から情報を受信し、ユーザプロファイルを生成してもよい。一部の実施形態では、ユーザプロファイルは、例えば、ＤＦ、ＲＳ及び／又はＥＳに関するデータを含むプロモーションを決定するためのデータを含んでもよい。ユーザプロファイル分析ユニット６２０は、ＤＦ、ＲＳ及び／又はＥＳに関するデータを、期間設定ユニット６１０から受信されたヒストリカルリクエストから抜き出してもよい。ユーザプロファイルは、プロモーション設定ユニット６３０へ送信されてもよい。

プロモーション設定ユニット６３０は、ユーザプロファイルに基づいてクーポンの利益の量を決定してもよい。プロモーション設定ユニット６３０は、ＤＦ、ＲＳ及び／又はＥＳのデータを処理してもよい。一部の実施形態では、図７に示されるように、プロモーション設定ユニット６３０は、ユーザの消費能力、クーポンを用いる確率を決定する、人口統計学的係数を決定する及び／又は行われるサービスの価格の最大値を設定するように構成されてもよい。一部の実施形態では、プロモーション設定ユニット６３０は、ＤＦ、ＲＳ及び／又はＥＳのデータに基づいて、ユーザの消費能力、クーポンを用いる確率、人口統計学的係数、及び／又はサービスの価格の最大値を決定してもよい。プロモーション設定ユニット６３０は、また、行われるサービスの価格の最大値、及びユーザの消費能力、クーポンを用いる確率又は人口統計学的係数の少なくとも１つに基づいて、モバイルユーザイクイップメント１３０へ配信されるクーポンの利益の量を決定するように構成されてもよい。行われるサービスの価格の最大値は、図１２に示される例示的な方法に基づいて決定されてもよく、これは、図１２に関して以下に詳細に説明される。

一部の実施形態では、消費能力は、ＲＳ及びＥＳのデータに基づいて決定されてもよい。例にすぎないが、消費能力は、ユーザと関連付けられるヒストリカルサービスリクエストの数（又はｎ_ｃａｒ）及びユーザと関連付けられるヒストリカルサービスリクエストの支出の総量（又はｃｏｓｔ_ａｌｌ）に基づいて決定されてもよい。一部の実施形態では、消費能力Ｃは、以下の式に基づいて決定されてもよい：
ここで、パラメータｓｐｅｎｄは、以下のように決定される：

一部の実施形態では、クーポンを用いる確率は、ＲＳ及びＥＳのデータに基づいて決定されてもよい。例にすぎないが、クーポンを用いる確率は、ユーザと関連付けられるヒストリカルサービスリクエストの数（又はｎ_ｃａｒ）、ユーザが少なくとも１つのクーポンを用いるヒストリカルサービスリクエストの数（又はｎ_{ｃｏｕｐｏｎ}）、ユーザと関連付けられるヒストリカルサービスリクエストの支出の総量（又はｃｏｓｔ_ａｌｌ）、及びヒストリカルサービスリクエストに用いられるクーポンの総量ｃｏｓｔ_{ｃｏｕｐｏｎ}に基づいて決定されてもよい。一部の実施形態では、クーポンを用いる確率Ｐは、以下のような式に基づいて決定されてもよい：

一部の実施形態では、サーバ１１０は、ユーザの消費に関する１以上の特徴（又はユーザの消費特徴）に基づいて複数の消費者グループのうちの１つの消費者グループへユーザを分類してもよい。一部の実施形態では、ユーザは、Ｋ平均クラスタリングアルゴリズム等のようなクラスタリングアルゴリズムを用いて、第１の消費者グループ及び第２の消費者グループへ分類されてもよい。消費特徴は、特定のサービスタイプ（例えば、ＬＵＸ又はＳＵＶ等のようなアップスケールサービス）、支出（常時又は特定期間内の）、クーポンを用いる確率、用いられるクーポンの総量、及びユーザが与えるチップを選択するための特性を含んでもよい。サーバ１１０は、ユーザと関連付けられるヒストリカルリクエストに基づいて消費特徴を決定してもよい。

一部の実施形態では、第１の消費者グループは、クーポンを用いる確率が高く、用いられるクーポンの総量が多い消費者のグループであってもよい。第２の消費者グループは、クーポンを用いる確率が低く、用いられるクーポンの総量が少ない消費者のグループであってもよい。第１の消費者グループにおける消費者は、クーポンを用いる確率が高いクーポンに敏感な消費者であり、第２の消費者グループにおける消費者は、クーポンを用いる確率が中程度又は低い消費者である。一部の実施形態では、消費特徴について、特徴ベクトルは、サーバ１１０によって決定されてもよい。
は、ｋ番目クラスタに対するｉ番目の特徴ベクトルとして示される。
によって示される消費特徴は、複数の特徴のメンバーである。サーバ１１０は、１以上の特徴ベクトルに基づいて未知のサンプルｘ（例えば、消費者グループ）を分類してもよい。一部の実施形態では、分類方法は、以下のように実装されてもよい。
ここで、ｇは、ｋ番目のクラスタに割り当てられる未知のサンプルｘについてのメンバーシップの度合いである。サーバ１１０は、サンプルｘと特徴ベクトル
との間の距離を決定してもよい。
サーバ１１０は、更に、そこに未知のサンプルｘが属するカテゴリとしてｇの最大値に対応するクラスタｋを決定してもよい。

一部の実施形態では、モバイルユーザイクイップメント１３０へ配信されるクーポンは、特別なクーポン又は通常のクーポンであってもよい。一部の実施形態では、特別なクーポンは、春節及びクリスマス等のような特別なプロモーション中に配信されるクーポンであってもよい。通常のクーポンは、特別なプロモーションにかかわらず、モバイルユーザイクイップメント１３０へ配信されるクーポンであってもよい。一部の実施形態では、クーポンは、トリガイベントが生じたときにユーザへ配信され、サーバ１１０によって検出される。それに代えて、クーポンは、１以上の他の条件が、トリガイベントの検出に加えて一致したときに、モバイルユーザイクイップメント１３０へ配信される。一部の実施形態では、１以上のある条件が一致したことを決定した後に、サーバ１１０は、新たなクーポンのためにユーザからトリガイベントを検出してもよい。例えば、サーバ１１０は、ユーザに利用可能な数のクーポン（例えば、ユーザアカウントと関連付けられる）が閾値よりも小さく、トリガイベントが検出されたときにのみ、クーポンを生成し、クーポンをモバイルユーザイクイップメント１３０へ送信してもよい。別の例として、サーバ１１０は、ユーザのクーポンが何日かで有効期限が切れたことを決定し、トリガイベントを検出すると、サーバ１１０は、クーポンを生成し、クーポンをモバイルユーザイクイップメント１３０へ送信してもよい。

一部の実施形態では、トリガイベントは、ユーザ又は第三者（サードパーティ）によって開始されてもよい。サーバ１１０は、ユーザＡをユニークＩＤで登録し、ユーザＡがサーバ１１０（又はログインサービスをホストする他の適切なサーバ）へログインしたときにユーザＡを記録する。サーバ１１０は、ユーザプロファイルに基づいてプロモーションストラテジーのリストを生成してもよい。例にすぎないが、サーバ１１０により生成されたプロモーションストラテジーは、以下の表１に示される：

表１によって示されるように、サーバ１１０は、ユーザプロファイルタイプ及び所定期間内のそれらの対応するクーポンを特定するプロモーションストラテジーに基づいて、ユーザへ配信されるクーポンを決定してもよい。トリガイベントを開始するユーザがユーザプロファイルタイプＩユーザとしてサーバ１１０によって決定された場合、サーバ１１０は、（ランダムに、所定期間に、又はトリガイベントを検出すると、）「￥２クーポン」を含むプロモーションをモバイルユーザイクイップメント１３０へ送信してもよい。

それに代えて、トリガイベントを開始するユーザがユーザプロファイルタイプＩ及びＩＩＩユーザとしてサーバ１１０によって決定された場合、サーバ１１０は、（ランダムに、所定期間に、又はトリガイベントを検出すると、）「￥２クーポン」及び「５ポイントＡｌｉｐａｙクレジット」を含むプロモーションをモバイルユーザイクイップメント１３０へ送信してもよい。

それに代えて、トリガイベントを開始するユーザがユーザプロファイルタイプＩユーザ、ユーザプロファイルタイプＩＩユーザ又はユーザプロファイルタイプＩＩＩユーザのいずれでもないとしてサーバ１１０によって決定された場合、サーバ１１０は、モバイルユーザイクイップメント１３０へプロモーションを送信しなくてもよい。

一部の実施形態では、トリガイベントは、ユーザがサードパーティ（例えば、ｅコマースショップ）でビジネスを行うときにサードパーティによって開始されてもよい。サードパーティのサーバは、ユーザＢをユニークＩＤで登録し、ユーザＢがｅコマースショップ（又はｅコマースサービスをホストする他の適切なサーバ）で商品を購入したときに、ユーザＢを記録してもよい。サードパーティのサーバが特定のトリガイベントを開始するとき、例えば、システム１００においてサーバ１１０との接続を要求するとき、サーバ１１０は、サーバ１１０がサードパーティのサーバとの接続を確立したときに、サードパーティのサーバからユーザＢに対するプロモーションに関する情報を取得してもよい。

一部の実施形態では、ユーザＢに対するプロモーションに関する情報は、「ＩＤ及びクーポンの使用」であってもよい。ユーザＢのＩＤが既にサーバ１１０に登録及び格納されている場合、サーバ１１０は、ユーザＢのＩＤと関連付けられるユーザプロファイルを決定してもよい。ユーザＢのＩＤと関連付けられるユーザプロファイルに対してサーバ１１０においてクーポンを配信するためのプロモーションストラテジーがない場合、サーバ１１０は、（ランダムに、所定期間に、又はトリガイベントを検出すると、）クーポンをモバイルユーザイクイップメント１３０へ送信してもよい。

それに代えて、ユーザＢに対するプロモーションに関する情報は、「ＩＤ及びクーポンの使用」であってもよい。ユーザＢのＩＤが既にサーバ１１０に登録及び格納されている場合、サーバ１１０は、ユーザＢのＩＤと関連付けられるユーザプロファイルを決定してもよい。サーバ１１０においてクーポンを配信するためのプロモーションストラテジーがない場合、サーバ１１０は、クーポンを配信するためのプロモーションストラテジーのリストを生成してもよい。

一部の実施形態では、消費能力及びクーポンを用いる確率に加えて、クーポンの量もまた、ユーザの人口統計学的係数に基づいて決定されてもよい。人口統計学的係数は、ユーザの性別、職業及び年齢等のようなユーザの１以上の人口統計学的特徴に基づいて決定されてもよい。人口統計学的特徴はまた、ユーザが属する年齢層を含んでもよい。例にすぎないが、人口統計学的特徴は、ユーザがビジネスマンである場合、０．９に設定され、教員である場合、０．７に設定されてもよい。人口統計学的係数は、値決定ストラテジーに基づいて割り当てられてもよい。値決定ストラテジーは、サーバ１１０にアクセス可能なストレージ２２０に格納されてもよい。値決定ストラテジーは、サーバ１１０によって調整されてもよい。一部の実施形態では、値割り当てストラテジーは、ストレージ２２０に格納されたルックアップテーブルであってもよく、これは、人口統計学的特徴、人口統計学的特徴のパラメータ、及び対応する人口統計学的係数値を特定してもよい。

図８は、本開示の一実施形態に係るプロセッサ２１０の例示的な情報配信モジュール４３０の図である。図８に示されるように、情報配信モジュール４３０は、トリガイベント検出ユニット８１０と、メッセージ配信ユニット８２０と、を含んでもよい。一部の実施形態では、トリガイベント検出ユニット８１０は、操作受信ユニット５１０から情報を受信し、操作がトリガイベントか否かを検出する。一部の実施形態では、トリガイベント検出ユニット８１０は、１以上のトリガイベントテンプレートに基づいて操作がトリガイベントかを検出する。トリガイベント検出ユニット８１０が操作受信ユニット５１０からモバイルユーザイクイップメント１３０での操作に関する情報を受信する場合、トリガイベント検出ユニット８１０は、当該操作をトリガイベントテンプレートと比較する。一部の実施形態では、トリガイベントテンプレートは、ストレージ２２０に格納され、サーバ１１０によって調整されてもよい。

メッセージ配信ユニット８２０は、モバイルユーザイクイップメント１３０へのプロモーションを含むメッセージを配信してもよい。プロモーションは、クーポン又はバウチャー、ディスカウント、クレジット又はそれらの組み合わせであってもよい。一部の実施形態では、プロモーションは、いくつかの利益のあるクーポン（例えば、特定量のクレジット又はディスカウント）。一部の実施形態では、プロモーションは、プロモーション設定ユニット６３０からストレージ２２０に送信され、ストレージ２２０に格納され、トリガイベントが検出されたときにメッセージ配信ユニット８２０へ送信されてもよい。

一部の実施形態では、クーポン検出ユニット（図８には図示せず）は、（ユーザアカウントと関連付けられるクーポンを決定することによって）ユーザが保持するクーポンを検出してもよい。一部の実施形態では、クーポン検出ユニットは、ユーザの保持するクーポンの数が閾値数以下である場合のみ、クーポンを配信することを可能にしてもよい。

図９は、本願に開示される、モバイルユーザイクイップメント１３０又はサービスプロバイダ１４０が、モバイルユーザイクイップメント１３０又はサービスプロバイダ１４０の機能を実行するように実装された例示的なコンピューティングデバイス９００を示すブロック図である。コンピューティングデバイス９００は、プロセッシングユニット（本明細書ではＣＰＵともいう）９１０、メモリ９２０、電源９３０、グローバルポジショニングシステム（ＧＰＳ）モジュール９４０を含んでもよい。ＣＰＵ９１０は、コンピューティングデバイス９００の他の構成要素から又はシステム１００における他のモジュール又はユニットからの情報を処理してもよい。例えば、ＣＰＵ９１０は、情報を格納するためのメモリ９２０又はデータストレージ媒体９２３を制御してもよい。メモリ９２０は、ランダムアクセスメモリ（ＲＡＭ）９２１及びリードオンリーメモリ（ＲＯＭ）９２６を含んでもよい。ＲＡＭ９２１は、オペレーティングシステム（ＯＳ）９２２、１以上のアプリケーションプログラム９２４又はデータ９２３を含む一部の情報を格納してもよい。オペレーティングシステム９２２は、ｉＯＳ、Ａｎｄｒｏｉｄ、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ又は同様のものを含んでもよい。輸送システムについて、アプリケーションプログラム９２４は、輸送サービスアプリケーションプログラム９２５を含んでもよい。アプリケーションプログラム９２４は、ＣＰＵ９１０によって実行されてもよい。ＲＯＭ９２６は、ベーシックインプット／アウトプットシステム（ＢＩＯＳ）９２７を含んでもよい。電源９３０は、コンピューティングデバイス９００に電気エネルギーを供給してもよい。グローバルポジショニングシステム（ＧＰＳ）モジュール９４０は、コンピューティングデバイス９００の位置を提供してもよい。

一部の実施形態では、コンピューティングデバイス９００は、また、ネットワークインターフェース９５１を含んでもよい。ネットワークインターフェース９５１は、コンピューティングデバイス９００とネットワーク１２０との通信を容易にする。例えば、モバイルユーザイクイップメント１３０からのサービスリクエストは、ネットワークインターフェース９５１を通じてサーバ１１０へ転送される。別の例として、サービスプロバイダ１４０は、ネットワークインターフェース９５１を通じてサーバ１１０から受信されたオーダーを受け付けてもよい。モバイルユーザイクイップメント１３０又はサービスプロバイダ１４０の位置は、ネットワークインターフェース９５１を通じてサーバ１１０へ転送される。

一部の実施形態では、コンピューティングデバイス９００は、オーディオインターフェース９５２を含んでもよい。オーディオインターフェース９５２は、様々なオーディオ入力を取得し、それらをデジタルデータに変換する。一部の実施形態では、コンピューティングデバイス９００は、外部Ｉ／Ｏデバイス（例えば、マウス、キーボード、モニタ、プリンタ又は同様のもの）と接続する入／出力インターフェース（Ｉ／Ｏインターフェース）９５３を含んでもよく、ユーザ又はドライバから入力を受信し、ユーザ又はドライバへ情報を出力するように構成されてもよい。一部の実施形態では、コンピューティングデバイス９００は、マイクロフォン９５６を含んでもよい。一部の実施形態では、コンピューティングデバイス９００は、キーパッド又はキーボード９５７を含んでもよい。一部の実施形態では、コンピューティングデバイス９００は、ディスプレイ９５５を含んでもよい。一部の実施形態では、コンピューティングデバイス９００は、また、ハプティックインターフェース９５４を含んでもよい。

図１０は、プロモーションを決定し、プロモーションを含むメッセージを配信するための例示的な処理のフローチャートである。処理は、ストレージ２２０に格納された命令に基づいてサーバ１１０のプロセッサ２１０によって行われてもよい。１０１０において、プロセッサ２１０は、ネットワーク１２０を介してモバイルユーザイクイップメント１３０との通信を確立する。サーバ１１０は、また、モバイルユーザイクイップメント１３０からサービスのユーザと関連付けられるユーザアイデンティティを識別する。プロセッサ２１０は、ユーザアイデンティティと関連付けられるユーザプロファイルを取得及び分析する。ユーザプロファイルに含まれる情報は、プロモーションを決定するために用いられる。例えば、ユーザプロファイルは、ＤＦ、ＲＳ及び／又はＥＳのデータを含んでもよい。一部の実施形態では、ＤＦは、ユーザの１以上のカテゴリを識別するために用いられる。ＤＦは、ユーザＩＤと関連付けられる登録情報の一部又は全部を含んでもよい。一部の実施形態では、ユーザの１以上のカテゴリは、性別、職業及び／又は年齢層を含んでもよい。一部の実施形態では、ユーザと関連付けられるＲＳは、ユーザによるヒストリカルサービスリクエストの数、用いられる少なくとも１つのプロモーションを有するヒストリカルサービスリクエストの数、ヒストリカルサービスの平均走行距離、及び／又は複数のヒストリカルサービスの開始及び行先を含んでもよい。ＲＳはまた、そのヒストリカルリクエストが開始される又はヒストリカルサービスが行われる都市と関連付けられる都市係数を含んでもよい。一部の実施形態では、ＥＳは、ヒストリカルサービスリクエストの総支出、ヒストリカルサービスリクエストの平均支出、及び／又はヒストリカルサービスリクエストで用いられたプロモーションの総量（クレジット又はディスカウント）を含んでもよい。

１０２０において、プロモーションは、プロセッサ２１０によって決定される。一部の実施形態では、プロセッサ２１０は、ユーザの消費能力、クーポンを用いる確率を決定する、人口統計学的係数を決定する、及び／又は行われるサービスの価格の最大値を設定するように構成されてもよい。プロセッサ２１０は、更に、決定されたユーザの消費能力、クーポンを用いる確率、人口統計学的係数、及び／又は行われるサービスの価格の最大値に基づいて、プロモーションを決定してもよい。一部の実施形態では、プロセッサ２１０は、行われるサービスの価格の最大値及びユーザの消費能力、クーポンを用いる確率又は人口統計学的係数のうちの少なくとも１つに基づいて、モバイルユーザイクイップメント１３０へ配信されるクーポンの利益の量（つまり、ユーザへ配信されるプロモーション）を決定してもよい。一部の実施形態では、クーポンの利益の量についてのプロモーション情報に関する情報は、ストレージ２２０に格納されてもよい。

１０３０において、トリガイベントは、プロセッサ２１０によって検出される。プロセッサ２１０のトリガイベント検出ユニット８１０は、操作受信ユニット５１０から情報を受信し、操作がトリガイベントか否かを検出する。一部の実施形態では、トリガイベント検出ユニット８１０は、１以上のトリガイベントテンプレートに基づいて操作がトリガイベントかを検出してもよい。トリガイベント検出ユニット８１０が、操作受信ユニット５１０からモバイルユーザイクイップメント１３０での操作に関する情報を受信した場合、トリガイベント検出ユニット８１０は、当該操作をトリガイベントテンプレートと比較する。一部の実施形態では、トリガイベントテンプレートは、ストレージ２２０に格納され、サーバ１１０によって調整されてもよい。１０４０において、プロセッサ２１０は、決定されたプロモーションを含むメッセージを生成し、当該メッセージをモバイルユーザイクイップメント１３０へ配信する。

図１１は、ユーザプロファイルを決定し、ユーザプロファイルに基づいてプロモーションを決定する例示的な処理のフローチャートである。１１１０において、プロセッサ２１０の分析モジュール４２０は、ユーザと関連付けられるヒストリカルリクエストを取得する。一部の実施形態では、ヒストリカルリクエストは、データベース１５０に格納され、サーバ１１０（及びプロセッサ２１０）へアクセス可能である。

１１２０において、分析モジュール４２０の期間設定ユニット６１０は、１１１０において取得されたヒストリカルリクエストをフィルタリングするための期間フィルタを決定してもよい。例えば、期間設定ユニット６１０は、期間フィルタのための期間ウィンドウとして第１の期間及び第２の期間を決定してもよい。分析モジュール４２０は、その後、期間ウィンドウにおいてヒストリカルリクエストを選択する。それに代えて、分析モジュール４２０は、期間フィルタを初めに決定し、その後、データベース１５０から、決定された期間フィルタによって特定される期間内にヒストリカルリクエストを直接取得してもよい。

それに代えて又は加えて、１１３０において、プロセッサ２１０は、現在のリクエストのサービスタイプを決定してもよい。プロセッサ２１０は、決定されたサービスタイプに基づいてヒストリカルリクエスト（１１１０において取得されたヒストリカルリクエスト又は１１２０において取得された期間フィルタによりフィルタされたヒストリカルリクエスト）もフィルタし、現在のサービスリクエストとして同一タイプのサービスを有するヒストリカルリクエストを取得してもよい。

それに代えて又は加えて、１１４０において、プロセッサ２１０は、ヒストリカルリクエストに関する情報（例えば、１１１０において取得されたヒストリカルリクエスト、１１２０において取得された期間フィルタによりフィルタされたヒストリカルリクエスト又は１１３０において取得されたフィルタ後のヒストリカルリクエスト）に基づいてユーザプロファイルを決定してもよい。一部の実施形態では、ユーザプロファイルは、ＤＦ、ＲＳ又はＥＳのデータを含んでもよく、これは、プロモーションの決定のために用いられてもよい。一部の実施形態では、ＤＦ、ＲＳ又はＥＳのデータは、価格の最大値及び／又は消費能力、クーポンを用いる確率等のような重み付け係数、及び人口統計学的係数を決定するために用いられてもよい。

一部の実施形態では、プロセッサ２１０は、１１５０において、ユーザプロファイルに含まれる情報に基づいてプロモーションを決定する。それに代えて又は加えて、プロセッサ２１０は、ヒストリカルリクエスト（例えば、１１１０において取得されたヒストリカルリクエスト、１１２０において取得された期間フィルタによりフィルタされたヒストリカルリクエスト又は１１３０において取得されたフィルタ後のヒストリカルリクエスト）に基づいてプロモーションを決定してもよい。

図１２は、本開示の一部の実施形態に係る価格の最大値を決定するための例示的な方法のフローチャートである。一部の実施形態では、プロセッサ２１０は、都市係数、活動係数及び／又は価格−走行距離係数に少なくとも部分的に基づいて、行われるサービスの価格の最大値を決定してもよい。

１２１０において、プロセッサ２１０は、ユーザと関連付けられる複数のヒストリカルリクエストを取得する。ヒストリカルリクエストは、本開示の他の箇所で説明された、１１１０において取得されたヒストリカルリクエスト、１１２０において取得された期間フィルタによりフィルタされたヒストリカルリクエスト又は１１３０において取得されたフィルタ後のヒストリカルリクエストであってもよい。

１２３０において、プロセッサ２１０は、ヒストリカルリクエストに基づいてユーザに対する活動係数を決定してもよい。活動係数は、リクエストするサービスのユーザの頻度を示す係数であってもよい。一部の実施形態では、活動係数は、ヒストリカルリクエスト（例えば、１１１０において取得されたヒストリカルリクエスト、１１２０において取得された期間フィルタによりフィルタされたヒストリカルリクエスト又は１１３０において取得されたフィルタ後のヒストリカルリクエスト）の数に基づいて決定されてもよい。一部の実施形態では、活動係数は、時間ウィンドウ内のヒストリカルリクエストの数に基づいて決定されてもよい。一部の実施形態では、活動変化係数は、最大価格を決定するための活動係数と共に用いられてもよい。それに代えて、活動変化係数は、２以上の時間ウィンドウ内のヒストリカルリクエストの数に基づいて決定されてもよい。一部の実施形態では、２以上の時間ウィンドウは、同一の時間フレーム又は異なる時間フレームを有してもよい。活動変化係数は、以下の式に基づいて決定されてもよい：
ここでＡＣは活動変化係数であり、αは定数である。
ここでＶ_１は、第１の時間ウィンドウにおけるヒストリカルリクエストの活動係数であり、Ｖ_２は、第２の時間ウィンドウにおけるヒストリカルリクエストの活動係数である。一部の実施形態では、第１の時間ウィンドウは、第２の時間ウィンドウの前であってもよい。一部の実施形態では、第１の時間ウィンドウは、第２の時間ウィンドウと同一長さを有してもよい。

それに代えて又は加えて、プロセッサ２１０は、１２４０において、ヒストリカルリクエストに基づいて価格−走行距離係数を決定してもよい。価格−走行距離係数は、価格係数及び走行距離係数を含んでもよい。一部の実施形態では、価格係数は、ヒストリカルリクエストの支出の平均量に基づいて決定されてもよく、走行距離係数は、ヒストリカルリクエストの平均走行距離に基づいて決定されてもよい。一部の実施形態では、価格係数は、以下の式に基づいて決定されてもよい：
ここでＰＦは活動係数であり、βは定数であり、ｙはヒストリカルリクエストの支出の平均量である。価格係数は、サービスの価格に対するユーザの感度を示してもよい。一部の実施形態では、走行距離係数は、以下の式に基づいて決定されてもよい：
ここでＭＦは走行距離係数、γは定数、ｚはヒストリカルリクエストの平均走行距離であってもよい。

それに代えて又は加えて、１２２０において、プロセッサ２１０は、都市係数を決定してもよい。都市係数は、（例えば、モバイルユーザイクイップメント１３０の位置情報を通じて）モバイルユーザイクイップメント１３０から取得された現在のリクエスト又は情報に含まれる位置情報に基づいて決定されてもよい。例えば、サービスリクエストが開始される又はサービスが行われる都市が取得されてもよく、都市に対応する都市係数は、複数の都市及びそれらの対応する都市係数を特定するルックアップテーブルに基づいて決定されてもよい。一部の実施形態では、ルックアップテーブルは、ストレージ２２０及び／又はデータベース１５０に格納されてもよい。

１２５０において、プロセッサ２１０は、（１２２０において決定された）都市係数、（１２３０において決定された）活動係数又は（１２４０において決定された）価格−走行距離係数又はそれらの任意の組み合わせに基づいて、行われるサービスの価格の最大値を決定してもよい。例にすぎないが、価格の最大値は、以下の式に基づいて決定されてもよい：
ＭＶ＝ＣＦ＊Ｖ_２＊ＡＣ＊ＰＦ＊ＭＦ＊ｙ 式（６）
ここでＭＶは価格の最大値、ＣＦは都市係数、Ｖ_２は第２の時間ウィンドウにおけるヒストリカルリクエストの活動係数、ＡＣは活動変化係数、ＰＦは価格係数、ＭＦは走行距離係数、ｙはヒストリカルリクエストの支出の平均量である。

本開示の他の箇所で説明されたように、クーポンの利益の量は、ユーザの消費能力、クーポンを用いる確率、人口統計学的係数及び／又は価格の最大値に基づいて決定されてもよい。例にすぎないが、クーポンの利益の量は、以下の式に基づいて決定されてもよい：
ＡＢ＝ＭＶ＊ｆ_１（Ｃ）＊ｆ_２（Ｐ）＊ｆ_３（Ｄ） 式（７）
ＭＶは価格の最大値であり、ＡＢはクーポンの利益の量であり、Ｄは人口統計学的係数であり、ｆ_１（Ｃ）は消費能力の関数であり、ｆ_２（Ｐ）はクーポンを用いる確率の関数であり、ｆ_３（Ｄ）は人口統計学的係数の関数である。一部の実施形態では、係数（例えば、ユーザの消費能力、クーポンを用いる確率、人口統計学的係数又は価格の最大値）が利益の量を決定する目的のために無視される場合、係数の関数は１に設定されてもよい。例にすぎないが、クーポンの利益の量は、２つの係数‐価格の最大値及び消費能力に基づいて決定され、利益の量は、式ＡＢ＝ＭＶ（１−Ｃ）に基づいて決定され、ここでＭＶは価格の最大値であり、Ｃは消費能力である。すなわち、ｆ_１（Ｃ）＝１−Ｃ、ｆ_２（Ｐ）＝１、及びｆ_３（Ｄ）＝１である。

上記の関数は、図示及び説明のためのみのものであり、本開示の範囲を限定することを意図するものではないことが留意されるべきである。一部の実施形態では、ヒストリカルリクエストは、異なる都市及び／又は異なるサービスタイプで開始されてもよい。トリガイベントが特定サービスタイプのある１つの都市で生じるとき、サーバ１１０は、同一都市で生じ、かつ同一サービスタイプを有する登録情報及びヒストリカルリクエストに基づいて決定されるいくつかの利益（例えば、特定量のクレジット又はディスカウント）のあるクーポンを配信する。サービスアプリケーションを起動することのようなトリガイベントがサービスタイプを示さない場合、ユーザがヒストリカルリクエストで最もリクエストしたサービスタイプによるヒストリカルリクエストに基づいて決定されるクーポンは、モバイルユーザイクイップメント１３０へ配信されてもよい。

人口統計学的係数は、性別、居住都市、職業及び／又は年齢層等のような１以上の人口統計学的特徴に基づいて決定されてもよい。ユーザの居住都市及び職業は、図１４−１６に示され、かつ本開示の他の箇所で説明される処理１４００−１６００に基づいて決定されてもよい。例にすぎないが、人口統計学的係数は、ユーザの職業がビジネスマンである場合、０．９に設定され、ユーザが教員である場合、０．７に設定されてもよい。人口統計学的係数は、値決定ストラテジーに基づいて割り当てられてもよい。値決定ストラテジーは、サーバ１１０にアクセス可能なストレージ２２０に格納されてもよい。値決定ストラテジーは、サーバ１１０によって調整されてもよい。一部の実施形態では、値割り当てストラテジーは、ストレージ２２０に格納されたルックアップテーブルであってもよく、これは、人口統計学的特徴、人口統計学的特徴の値、及び対応する人口統計学的係数値を特定してもよい。

一部の実施形態では、人口統計学的係数は、ストレージ２２０及び／又はデータベース１５０に格納されたルックアップテーブルに基づいて決定されてもよい。例にすぎないが、表２は２つの人口統計学的特徴‐ユーザが属する職業及び年齢層に基づいて人口統計学的係数を決定するためにプロセッサ２１０によって用いられる。

一部の実施形態では、ルックアップテーブルは、ｎ次元のチャートであり、ここで１≦ｎ≦人口統計学的特徴の数、である。ルックアップテーブルは、プロセッサ２１０によって調整又は更新されてもよい。

一部の実施形態では、プロセッサ２１０は、図１３に示される例示的な処理１３００に基づいてユーザの人口統計学的特徴を決定してもよい。１３１０において、ユーザＩＤと関連付けられる登録情報及び／又はヒストリカルリクエストは、情報受信モジュール４１０のユーザＩＤ受信ユニット５１０によって取得される。１３２０において、プロセッサ２１０は、登録情報が人口統計学的特徴を含むかを決定する。プロセッサ２１０が探す人口統計学的特徴は、特定の人口統計学的特徴タイプ（例えば、職業又は年齢層）又はプロモーションを決定するために用いられる任意の人口統計学的特徴であってもよい（１以上の人口統計学的特徴に少なくとも部分的に基づいてプロモーションを決定する方法は、本開示の他の箇所で説明される）。プロセッサ２１０が、人口統計学的特徴が登録情報に含まれると決定した場合、プロセッサ２１０は、１３８０において、人口統計学的特徴を抜き出す（菱形１３２０から出る矢印「Ｙｅｓ」）。一部の実施形態では、ユーザの登録情報は、人口統計学的特徴を含んでもよい。例えば、ユーザは、（モバイルユーザイクイップメント１３０又は他のデバイスで）ユーザのアカウントを登録するとき、このような情報をサーバ１１０に提供してもよい。別の例として、プロセッサ２１０は、以前に決定された人口統計学的特徴（例えば、処理１３００）を有してもよい。一方、プロセッサ２１０が、人口統計学的特徴がないことを決定した場合、プロセッサ２１０は、１３３０において、人口統計学的特徴のタイプを決定する。例えば、プロセッサ２１０が、人口統計学的係数を決定するためにユーザの職業（つまり、人口統計学的特徴のタイプ）が必要なことを決定する場合、プロセッサ２１０は、「職業」として人口統計学的特徴のタイプを決定してもよい。

１３４０において、プロセッサ２１０は、付加的に、分析されるヒストリカルリクエストを選択するための期間を決定してもよい。１３５０において、プロセッサ２１０は、ヒストリカルリクエスト（１３４０において取得される選択ヒストリカルリクエスト、又は１３１０において取得されるヒストリカルリクエスト）を分析し、ヒストリカルリクエストに含まれるポイントオブインタレスト（又は複数のＰＯＩｓ）を識別してもよい。本願においてＰＯＩは、リクエストの開始点又は行先を指し、商業的、居住的、魅力、及び／又は地球上の特定位置に位置される居住位置に関する情報を含んでもよい。ＰＯＩは、学校、病院、駅、空港、企業、居住コミュニティ、ホテル景観、スポット等のような様々なタイプに分類されてもよい。一部の実施形態では、ＰＯＩの識別は、分析モジュール４２０のユーザプロファイル分析ユニットによって行われてもよい。

１３６０において、プロセッサ２１０は、ＰＯＩに基づいて人口統計学的特徴を決定する。例えば、ヒストリカルリクエストに含まれるＰＯＩがビジネス地域である場合、プロセッサ２１０は、ユーザがビジネスマンであると決定してもよい。別の例として、ユーザが通常訪れる又は出発するヒストリカルリクエストに含まれるＰＯＩが、企業である場合、当該ＰＯＩはユーザの勤務地である可能性が高く、プロセッサ２１０は、ユーザがビジネスマン（又はＰＯＩが小学校である場合、ユーザが教員）であると決定してもよい。１３７０において、プロセッサ２１０は、将来の使用のためにユーザの登録情報を更新する。一部の実施形態では、プロセッサ２１０は、取得されるべき人口統計学的特徴が更にあるかどうかを決定してもよい。そうである場合、プロセッサ２１０は、ステップ１３２０から１３７０（又は１３８０）を繰り返し、人口統計学的特徴を決定してもよい。

一部の実施形態では、ユーザの職業（つまり、ユーザの人口統計学的特徴）は、図１４−１６に示される例示的な処理に基づいて決定されてもよい。本開示で用いられる用語「職業」は、ユーザが保持する仕事（又はその種類）であってもよい。一部の実施形態では、ユーザの職業は、ユーザが教員としての仕事を持っているが、ユーザがサービスをリクエストするときに、旅行者として決定されてもよい。例えば、ユーザは、ユーザの居住都市において教員であるが、ユーザは、別の都市においてサービスをリクエストするときに旅行者として決定されてもよい。

一部の実施形態では、１４１０において、プロセッサ２１０は、１以上の非属性都市と関連付けられるヒストリカルリクエストからＰＯＩを識別する。ユーザの属性都市は、そのユーザの登録された電話番号が属する都市を指す。非属性都市は、属性都市ではない都市である。ユーザの属性都市は、例えば、登録された電話番号のエリアコード又は位置識別コードに基づいて決定されてもよい。

１４２０において、非属性都市の各々（又は非属性都市の一部）について、プロセッサ２１０（例えば、ユーザプロファイル分析ユニット６２０）は、非属性都市と関連付けられるヒストリカルリクエストの数、及び／又は（例えば、ホテル、モーテルを含む）ホテルの数及び非属性都市における居住コミュニティ（又はその一部）の数を決定する。

１４３０において、非属性都市について、プロセッサ２１０は、居住コミュニティの数が、非属性都市におけるホテルの数よりも大きいかどうかを決定する。そうである場合、プロセッサ２１０は、ユーザの予備居住都市として非属性都市を設定してもよい。プロセッサ２１０は、非属性都市の各々（又は非属性都市の一部）に対してステップ１４３０を繰り返し、複数の予備居住都市を決定してもよい。

１４４０において、プロセッサ２１０は、どの予備居住都市が、全ての予備居住都市のうち、最大数の居住コミュニティを有するかを決定する。プロセッサ２１０は、また、ユーザの候補都市として最大数の居住コミュニティを有する予備居住都市を設定してもよい。

図１５は、ユーザの居住都市を決定するための例示的な処理のフローチャートである。１５１０において、プロセッサ２１０は、属性都市と関連付けられるヒストリカルリクエストの数と、候補都市と関連付けられるヒストリカルリクエストの数との比（又はＲＡＣ）を決定する。プロセッサ２１０は、ＲＡＣが第２の閾値よりも大きいかを更に決定してもよい。そうである場合（図１５の菱形１５１０からのＹｅｓの矢印）、プロセッサ２１０は、１５２０において、属性都市がユーザの居住都市であることを決定する。一方、そうでない場合（図１５の菱形１５１０からのＮｏの矢印）、１５３０において、プロセッサ２１０は、属性都市における居住コミュニティの数が、候補都市における居住コミュニティの数よりも小さいかを決定する。そうである場合（図１５の菱形１５３０からのＹｅｓの矢印）、プロセッサ２１０は、１５４０において、候補都市がユーザの居住都市であるかを決定する。一方、そうでない場合（菱形１５３０からのＮｏの矢印）、プロセッサ２１０は、１５５０において、属性都市におけるホテルの数が、候補都市におけるホテルの数よりも大きいかを決定する。そうである場合（図１５の菱形１５５０からのＹｅｓの矢印）、プロセッサ２１０は、１５４０において、候補都市がユーザの居住都市であるかを決定する。一方、そうでない場合（菱形１５５０からのＮｏの矢印）、プロセッサ２１０は、１５２０において、属性都市がユーザの居住都市であるかを決定する。

図１６は、居住都市及び１以上の非居住都市におけるヒストリカルリクエストに基づいてユーザの職業を決定するための例示的な処理のフローチャートである。ユーザの居住都市及び非居住都市は、上述した処理１４００及び１５００に基づいて決定されてもよい。

１６１０において、プロセッサ２１０は、ＰＯＩ分類ストラテジーに基づいて第１のタイプのＰＯＩ及び第２のタイプのＰＯＩを決定する。一部の実施形態では、ＰＯＩ分類ストラテジーは、ユーザの人口統計学的特徴の異なる職業及びカテゴリを決定するために調整されてもよい。ＰＯＩ分類ストラテジーは、プロセッサ２１０へアクセス可能なストレージ２２０又はデータベース１５０に格納されてもよい。一部の実施形態では、第１のタイプのＰＯＩは、空港、地下鉄駅、バスステーション、及び鉄道駅等のような公共輸送機関を含んでもよい。一部の実施形態では、第２のタイプのＰＯＩは、企業、公共コミュニティ、居住コミュニティ、ホテル、観光地、空港、鉄道駅等のような場所を含んでもよい。

１６１０において、プロセッサ２１０は、識別されたＰＯＩの各々に対してポイントを決定する。一部の実施形態では、ＰＯＩに対するポイントは、ストレージ２２０及び／又はデータベース１５０に格納されてもよい。ＰＯＩに対するポイントは、サーバ１１０によって調整されてもよい。例にすぎないが、下記の表３は、空港、企業、鉄道駅及び観光地を含むＰＯＩに対するポイントを示す。

１６３０において、プロセッサ２１０は、ヒストリカルリクエストに基づいて、ユーザの居住都市及び１以上の非居住都市におけるＰＯＩの数を決定する。例にすぎないが、下記の表４は、居住都市における第１のタイプのＰＯＩ（つまり、空港及び鉄道駅を含む公共輸送機関）の数を示す。

１６４０において、プロセッサ２１０は、第１のタイプのＰＯＩ及び第２のタイプのＰＯＩに対する総ポイントを決定する。一部の実施形態では、プロセッサ２１０は、ユーザの居住都市における第１のタイプのＰＯＩに対する総ポイント、及びユーザの１以上の非居住都市における第２のタイプのＰＯＩに対する総ポイントを決定してもよい。例にすぎないが、（表４に示される）ユーザの居住都市における第１のタイプのＰＯＩに対する総ポイントは、５＊２＋１０＊１＝２０である。一部の実施形態では、第１のタイプのＰＯＩに対する総ポイントは、居住都市及び１以上の非居住都市における第１のタイプのＰＯＩに対するポイントに基づいて決定されてもよい。第２のタイプのＰＯＩに対する総ポイントは、居住都市及び１以上の非居住都市における第２のタイプのＰＯＩに対するポイントに基づいて決定されてもよい。

１６５０において、プロセッサ２１０は、第１のタイプのＰＯＩに対する総ポイント及び第２のタイプのＰＯＩに対する総ポイントに基づいてユーザの職業を決定する。一部の実施形態では、プロセッサ２１０は、居住都市における第１のタイプのＰＯＩに対する総ポイント、及び１以上の非居住都市に対する第１のタイプ及び第２のタイプのＰＯＩに対する総ポイントに基づいて、職業を決定してもよい。一部の実施形態では、ユーザは、第１のタイプのＰＯＩに対する総ポイントが第３の閾値よりも大きい場合、ビジネスマンとして分類されてもよい。一部の実施形態では、ユーザは、第２のタイプのＰＯＩに対する総ポイントが第４の閾値よりも大きい場合、旅行者として分類されてもよい。一部の実施形態では、第３及び第４の閾値は、調整可能であり、ストレージ２２０に格納されてもよい。

以下の例は、特定の例示的な実施形態を説明する目的のためのみに提供され、開示の範囲に限定することが意図されない。表５は、ユーザＩＤを有するユーザに対するヒストリカルリクエストの例示的な記録を示す。説明の目的のために、ヒストリカルリクエストの詳細は省略される。

表５に示されるように、ユーザは、３つの都市、つまり１、４及び２９におけるヒストリカルリクエストを開始する。ユーザの職業は、処理１４００−１６００（図１４−１６に図示され、本開示の他の箇所で説明される）に基づいて決定されてもよい。例えば、ホテル、居住コミュニティの数、及びヒストリカルリクエストの数は、サーバ１１０によって決定されてもよい。結果は、一例として表６に示される。居住コミュニティの数は、都市１及び４の両方のホテルの数よりも大きい。よって、都市１及び４は、両方とも予備居住都市である。更に、都市４における居住コミュニティの数は、都市１のものよりも大きい。よって、都市４は、候補都市として決定される。

ユーザＰＩの居住都市は、処理１５００（図１５に図示）に基づいて決定されてもよい。例えば、都市４及び都市２９に対するＲＡＣは、都市４と都市２９との間の居住都市を設定するために決定される。第２の閾値が０．４であり、ＲＡＣが１／４６に等しい場合、ＲＡＣは、第２の閾値よりも小さい。更に、都市４における居住コミュニティの数は、都市２９のものよりも大きい。したがって、都市４は、居住コミュニティとして決定される。

ユーザの職業は、第１のタイプのＰＯＩに対する総ポイント及び第２のタイプのＰＯＩに対する総ポイントに基づいて決定されてもよい。居住都市４について、空港及び鉄道駅に対する訪問回数は、それぞれ９及び２である。よって、第１のタイプのＰＯＩに対するポイントは、２＊９＋１＊２＝２０と決定され、第２のタイプのＰＯＩに対するポイントは、２＊９＋１＊２＝２０と決定される。非居住都市１及び２９について、企業、空港及び他の場所に対する訪問回数は、それぞれ、３６、１及び７２である。よって、第１のタイプのＰＯＩに対するポイントは、３６＊５＋１＊２＋７２＊０．１＝１８９．２であり、第２のタイプのＰＯＩに対するポイントは、１＊２＋７２＊０．１＝９．２である。第１のタイプのＰＯＩに対する総ポイントは、２０＋１８９．２＝２０９．２であり、第２のタイプのＰＯＩに対する総ポイントは、２０＋９．２＝２９．２である。第１のタイプのＰＯＩは、ビジネスマンに更に関連され、第２のタイプのＰＯＩは、旅行者に更に関連される。したがって、このユーザは、第１のタイプのＰＯＩに対する総ポイントと第２のタイプのＰＯＩに対する総ポイントとの比較に基づいてビジネスマンと決定される。

Claims (28)

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. コンピュータプログラム製品を具体化する非一時的コンピュータ可読媒体であって、前記コンピュータプログラム製品は、コンピューティングシステムに、
    ネットワークを介してモバイルデバイスとの通信を確立させ、
    前記モバイルデバイスからサービスのユーザと関連付けられたユーザアイデンティティを識別させ、
    前記ユーザアイデンティティと関連付けられたユーザプロファイルを取得させ、
    前記モバイルデバイスからサービスのためのサービスリクエストを開始するために、前記ユーザの意図を示すトリガイベントを識別させ、
    前記ユーザプロファイル及び前記トリガイベントに基づいて、前記ユーザアイデンティティと関連付けられるプロモーションを決定させ、
    前記モバイルデバイスへ送信される前記プロモーションに関するメッセージを生成させる、
    ように構成される命令を備える非一時的コンピュータ可読媒体。