JP6874170B2 - モバイルデバイスにプロンプトメッセージを提示するための人口知能システムおよび方法 - Google Patents

Description

この出願は、２０１７年６月２８日に出願した中国特許出願第２０１７１０５１１７１２．３および２０１７年９月１５日に出願された中国特許出願第２０１７１０８４０３８９．４の優先権を主張し、これらの内容は、参照することによりここに組み込まれる。この出願は、一般に、インターネットの技術分野に関し、特に、モバイルデバイスにプロンプトメッセージを提示するシステムおよび方法に関する。

現代社会では、オンラインからオフラインへのサービスアプリケーションがますます普及してきている。ユーザは、ユーザのユーザモバイル端末にインストールされたアプリケーションを介してオンラインからオフラインへのサービスを要求するオーダー（order)を送信することができる。このアプリケーションを用いて、ユーザは、サービスプロバイダと通信することができ、これは、サービス効率を改善する。アプリケーションのユーザインタフェース上で、アプリケーションは、しばしば、ユーザのためのサービスに関する情報を表示する。既存の技術を用いた問題は、ユーザのための表示された情報が、ユーザの要求を満足させることができないことである。したがって、オンラインからオフラインへのサービス期間中に、モバイルデバイスにプロンプトメッセージを提示するためのシステムと方法を提供することが望ましい。

この開示の一態様は、オンラインからオフラインへのサービスアプリケーションのユーザインタフェースにプロンプトメッセージを提示するように構成されたシステムを、ユーザ端末に導入する。このシステムは、オンラインからオフラインへのサービスアプリケーションのユーザインタフェースにプロンプトメッセージを提示するための命令セットを含む少なくとも１つの記憶媒体と、前記命令セットを実行しているとき、前記記憶媒体と通信している少なくとも１つのプロセッサを、ユーザ端末に含むことができる。前記少なくとも１つのプロセッサは、ユーザ端末から、第１のサービスタイプに関するサービス要求を取得することであって、前記サービス要求は、ユーザ端末のロケーションを含む、取得することと、前記ユーザ端末のロケーションに基づいて、前記第１のサービスタイプの第１の需給比率（supply demand ratio）を決定することと、前記第１の需給比率が、第１の比率しきい値より大きいか否かを決定することと、前記第１の需給比率が、第１の比率しきい値よりも大きくないと決定することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェースに提示された、第１のバブルプロンプト（bubble prompt）メッセージを送信することであって、第１のバブルプロンプトメッセージは、第２のサービスタイプ、および第２のサービスタイプの応答時間を含む、送信することと、を実行するように命令されることができる。

いくつかの実施形態において、第１のバブルプロンプトメッセージは、さらに、第２のサービスタイプを表示するユーザインタフェースへのリンク、または第１のサービスタイプの第１の需給率の表示（view）を含むことができる。

いくつかの実施形態において、第２のサービスタイプは、前記ユーザ端末のロケーションに関連づけられた、複数のサービスタイプの中で、最も大きい需給率を有することができる。

いくつかの実施形態において、前記ユーザ端末から、第１の移動オーダー（travel order）を取得し、第１の移動オーダーは、ターゲットサービスタイプと、第１の移動オーダーの第１の送信時間を含む。ターゲットサービスタイプの未割当のオーダーキュー（order queue）に、少なくとも１つの第２の移動オーダーを取得し、各第２の移動オーダーは、第２の移動オーダーの第２の送信時間を含む。第１の送信時間と、少なくとも１つの第２の送信時間に基づいて、第１の移動オーダーのキュー番号と待ち時間を決定する。前記ユーザ端末に、ユーザ端末のユーザインタフェースに提示された、第２のバブルプロンプトメッセージを送信し、第２のバブルプロンプトメッセージは、第１の移動オーダーのキュー番号と待ち時間を含む。

いくつかの実施形態において、少なくとも１つのプロセッサはさらに、前記第１の移動オーダーが、時間しきい値よりも少ないかどうかを判断し、前記第１の移動オーダーの待ち時間が、時間しきい値以上であると判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェースに提示された、第１のバブルプロンプトメッセージを送信する、ようにさらに指示されることができる。

いくつかの実施形態において、前記少なくとも１つのプロセッサはさらに、前記第１の移動オーダーに基づいて、前記ユーザ端末に、乗り物を割り当て、前記ユーザ端末に、前記ユーザ端末のユーザインタフェースに提示された、割り当てられた乗り物に関する情報を含む、第３のバブルプロンプトメッセージを送信するようにさらに指示されることができる。

いくつかの実施形態において、前記第３のバブルプロンプトメッセージは、割当てられた乗り物の色、割り当てられた乗り物のプレート番号、または、割り当てられた乗り物の乗り物タイプの少なくとも１つを含むことができる。

いくつかの実施形態において、少なくとも１つのプロセッサは、さらに、前記ユーザ端末から第１の移動オーダーを取得することであって、前記第１の移動オーダーは、ターゲットサービスタイプおよび開始ロケーションを含み、ユーザ端末におけるオンラインからオフラインへのサービスアプリケーションのユーザインタフェース上のユーザによりトリガされる、取得することと、第１の移動オーダーが乗り物に割り当てられなかったと判断することと、前記ユーザ端末へ、ユーザ端末のユーザインタフェース上に提示されたカードプロンプトメッセージを送信することであって、前記カードプロンプトメッセージは、推奨されたサービスタイプと、前記推奨されたサービスタイプの応答時間を含む、送信することを指示されることができる。

いくつかの実施形態において、カードプロンプトメッセージは、さらに、前記推奨されたサービスタイプに関する、推奨された移動オーダーをトリガするオプションと、前記推奨されたサービスタイプに関する推奨された移動オーダーの推定料金、または前記推奨されたサービスタイプの推奨された移動オーダーの推定された料金と、前記ターゲットサービスタイプに関する第１の移動オーダーの推定料金との間の料金差のうちの少なくとも１つを含むことができる。

いくつかの実施形態において、第１の移動オーダーは、開始ロケーションを含むことができ、第１の移動オーダーが、乗り物に割り当てられなかったと判断するために、前記少なくとも１つのプロセッサは、さらに、前記開始ロケーションに基づいて、前記ターゲットサービスタイプの第２の需給率を決定し、前記第２の需給率が第２の比率しきい値より大きいかどうか判断し、第２の需給率が第２の比率しきい値より大きくないと判断することに応答して、第１の移動オーダーが乗り物に割り当てられなかったと判断する、ように指示されることができる。

いくつかの実施形態において、第１の移動オーダーが乗り物に割り当てられなかったと判断するために、前記少なくとも１つのプロセッサは、さらに、前記ユーザ端末から第１の移動オーダーのキャンセル要求を取得し、第１の移動オーダーが乗り物に割り当てられなかったと判断する、ようにさらに指示されることができる。

いくつかの実施形態において、第１の移動オーダーは、開示時刻、開始ロケーション、目的地、またはユーザ端末の過去の移動情報の少なくとも１つを含むことができる。

いくつかの実施形態において、少なくとも１つのプロセッサはさらに、第１の移動オーダーに基づいてユーザ端末に促された推奨されたサービスタイプを判断するように指示されることができる。

この開示の他の態様によれば、ユーザ端末内のオンラインからオフラインへのサービスアプリケーションのユーザインタフェースにプロンプトメッセージを提示する方法は、ユーザ端末から、第１のサービスタイプのサービス要求を取得することであって、前記サービス要求は、前記ユーザ端末のロケーションを含む、取得することと、前記ユーザ端末のロケーションに基づいて、前記第１のサービスタイプの第１の需給率を決定することと、前記第１の需給率が第１の比率しきい値よりも大きいかどうかを判断することと、前記第１の需給率が、前記第１の比率しきい値未満であると判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェース上に提示された第１のバブルプロンプトメッセージを送信することであって、前記第１のバブルプロンプトメッセージは、第２のサービスタイプと、第２のサービスタイプの応答時間を含む、送信することと、を含むことができる。

いくつかの実施形態において、第１のバブルプロンプトメッセージは、さらに、第２のサービスタイプを表示するユーザインタフェースへのリンク、または第１のサービスタイプの第１の需給率の表示を含むことができる。

いくつかの実施形態において、第２のサービスタイプは、前記ユーザ端末のロケーションに関連づけられた複数のサービスタイプの中で、最も大きい需給率を有することができる。

いくつかの実施形態において、この方法はさらに、ユーザ端末から、第１の移動オーダーを取得することであって、前記第１の移動オーダーは、ターゲットサービスタイプと、第１の移動オーダーの第１の送信時間を含む、取得することと、前記ターゲットサービスタイプの未割当のオーダーキューに、少なくとも１つの第２の移動オーダーを取得することであって、各第２の移動オーダーは、第２の移動オーダーの第２の送信時間を含む、取得することと、前記第１の送信時間と少なくとも１つの第２の送信時間に基づいて、前記第１の移動オーダーのキューナンバーと待ち時間を決定することと、前記ユーザ端末へ、前記ユーザ端末のユーザインタフェースに提示された、第２のバブルプロンプトメッセージを送信することであって、前記第２のバブルプロンプトメッセージは、第１の移動オーダーのキューナンバーと、待ち時間を含む、送信することをさらに含むことができる。

いくつかの実施形態において、方法は、第１の移動オーダーの待ち時間が、時間しきい値未満であるかどうかを判断することと、前記第１の移動オーダーの待ち時間が、前記時間しきい値以上であることに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェースに提示された、第１のバブルプロンプトメッセージを送信することと、をさらに含むことができる。

いくつかの実施形態において、前記方法は、第１の移動オーダーに基づいて、前記ユーザ端末へ乗り物を割り当てることと、前記ユーザ端末へ、前記ユーザ端末のユーザインタフェース上に提示された、第３のバブルプロンプトメッセージを送信することであって、前記第３のバブルプロンプトメッセージは、前記割り当てられた乗り物に関する情報を含む、送信することと、をさらに含むことができる。

いくつかの実施形態において、第３のバブルプロンプトメッセージは、割当てられた乗物の色、割当てられた乗り物のプレート番号、または割当てられた乗り物の、乗り物タイプ、の少なくとも１つを含むことができる。

いくつかの実施形態において、この方法はさらに、ユーザ端末から、第１の移動オーダーを取得することであって、前記第１の移動オーダーは、ターゲットサービスタイプと、開始ロケーションを含み、ユーザ端末内の、オンラインからオフラインへのサービスアプリケーションのユーザインタフェース上のユーザによりトリガされる、取得することと、前記第１の移動オーダーが、乗り物に割り当てられなかったと判断することと、前記ユーザ端末へ、前記ユーザ端末のユーザインタフェースに提示されたカードプロンプトメッセージを送信することであって、前記カードプロンプトメッセージは、推奨されたサービスタイプと、前記推奨されたサービスタイプの応答時間を含む、送信することと、をさらに含むことができる。

いくつかの実施形態において、カードプロンプトメッセージは、さらに、推奨されたサービスタイプの推奨された移動オーダーをトリガするオプション、前記推奨されたサービスタイプの推奨された移動オーダーの推定された料金、または、前記推奨されたサービスタイプに関する、推奨された移動オーダーの推定された料金と、前記ターゲットサービスタイプの第１の移動オーダーの、推定された料金との間の料金差の少なくとも１つを含む。

いくつかの実施形態において、第１の移動オーダーは、開始ロケーションを含むことができ、前記第１の移動オーダーが乗り物に割り当てられなかったと判断することは、前記開始ロケーションに基づいて、前記ターゲットサービスタイプの第２の需給比率を決定することと、前記第２の需給比率が、第２の比率しきい値よりも大きいかどうかを判断することと、前記第２の需給比率が、前記第２の比率しきい値未満であると判断したことに応答して、前記第１の移動オーダーが、乗り物に割り当てられなかったと判断することとを含むことができる。

いくつかの実施形態において、前記第１の移動オーダーが、乗り物に割り当てられなかったと判断することは、前記ユーザ端末から、前記第１の移動オーダーに関するキャンセル要求を取得することと、前記第１の移動オーダーが、乗り物に割り当てられなかったと判断することと、を含むことができる。

いくつかの実施形態において、第１の移動オーダーは、開始時刻、開始ロケーション、目的地、またはユーザ端末の、過去に用いた移動情報、の少なくとも１つを含むことができる。

いくつかの実施形態において、前記方法はさらに、前記第１の移動オーダーに基づいて、前記ユーザ端末に促した、推奨されたサービスタイプを判断することと、をさらに含むことができる。

この開示のさらに他の態様によれば、非一時的コンピュータ可読媒体は、ユーザ端末内のオンラインからオフラインへのサービスアプリケーションのユーザインタフェース上に、プロンプトメッセージを提示するための少なくとも１つの命令セットを備え、コンピュータデバイスの少なくとも１つのプロセッサにより実行されると、前記少なくとも１つの命令セットは、前記少なくとも１つのプロセッサに、ユーザ端末から、第１のサービスタイプのサービス要求を取得することであって、前記サービス要求は、前記ユーザ端末のロケーションを含む、取得することと、前記ユーザ端末の前記ロケーションに基づいて、前記第１のサービスタイプの第１の需給率を決定することと、前記第１の需給比率が、第１の比率しきい値より大きいかどうかを判断することと、前記第１の需給比率が、第１の比率しきい値未満であると判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェース上に提示された第１のバブルプロンプトメッセージを送信することであって、前記第１のプロンプトメッセージは、第２のサービスタイプと、前記第２のサービスタイプの応答時間を含む、送信することと、を実行するように指示することができる。

この開示のさらに他の態様によれば、ユーザ端末内のオンラインからオフラインへのサービスアプリケーションのユーザインタフェース上に、プロンプトメッセージを提示するように構成されたシステムは、ユーザ端末から、第１のサービスタイプに関するサービス要求を取得するように構成された受信モジュールであって、前記サービス要求は、前記ユーザ端末のロケーションを含む、受信モジュールと、前記ユーザ端末のロケーションに基づいて、前記第１のサービスタイプの第１の需給率を決定するように構成された判断モジュールであって、前記第１の需給比率は、第１の比率しきい値より大きいかどうかを判断する、判断モジュールと、前記第１の需給比率が、前記第１の比率しきい値未満であると判断することに応答して、前記ユーザ端末へ、前記ユーザ端末のユーザインタフェースに提示された、第１のバブルプロンプトメッセージを送信するように構成されたプッシュモジュールであって、前記第１のバブルプロンプトメッセージは、第２のサービスタイプと、前記第２のサービスタイプの応答時間を含む、プッシュモジュールと、を含むことができる。

さらなる特徴は、一部以下の記載において述べられ、一部は、当業者には、以下の記述および添付図面を精査することにより明らかになるであろうし、あるいは、例示実施形態の製造または動作により学習することができる。この開示の特徴は、以下に記載した詳細な例示に述べられた方法、インストルメンタリティ、および組合せの種々の態様の使用または実施により実現され、獲得することができる。この開示はさらに、例示実施形態の観点から、さらに記載される。これらの実施形態は、限定しない例示実施形態であって、図面のいくつかを通して類似の参照符号は、類似の構造を表す。

図１は、この開示のいくつかの実施形態に従う、例示のオンラインからオフラインへのサービスシステムを説明する概略図である。 図２は、この開示のいくつかの実施形態に従う、コンピューティングデバイスのハードウェアおよび／またはソフトウェアコンポーネントを説明する概略図である。 図３は、この開示のいくつかの実施形態に従う、モバイルデバイスの例示ハードウェアおよび／またはソフトウェアコンポーネントを説明する概略図である。 図４Ａは、この開示のいくつかの実施形態に従う、プロンプトメッセージを提示する例示の、第１のシステムを説明するブロック図である。 図４Ｂは、この開示のいくつかの実施形態に従う、プロンプトメッセージを提示する例示の、第１のシステムを説明するブロック図である。 図４Ｃは、この開示のいくつかの実施形態に従うプロンプトメッセージのための例示の、第２のシステムを説明するブロック図である。 図４Ｄは、この開示のいくつかの実施形態に従う、プロンプトメッセージを提示するための例示の、第２のシステムを説明するブロック図である。 図５は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図６は、この開示のいくつかの実施形態に従う、第１のバブルプロンプトメッセージを提示する例示プロセスを説明するフローチャートである。 図７は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図８は、この開示のいくつかの実施形態に従う、第２のバブルプロンプトメッセージを提示する例示プロセスを説明するフローチャートである。 図９は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図１０は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図１１は、この開示のいくつかの実施形態に従う、第３のバブルプロンプトメッセージのための例示プロセスを説明するフローチャートである。 図１２は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図１３は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図１４は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図１５は、この開示のいくつかの実施形態に従う、第３のバブルプロンプトメッセージに関する例示プロセスを説明するフローチャートである。 図１６は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。 図１７は、この開示のいくつかの実施形態に従う、ユーザインタフェース上のアプリケーションの例示ユーザインタフェースである。 図１８は、この開示のいくつかの実施形態に従う、ユーザ端末上のカードプロンプトメッセージを提示する命令を説明するフローチャートである。

以下の記載は、当業者が、この開示を作成し、使用することを可能にするために提示され、特定のアプリケーション、およびその要件のコンテキストにおいて提供される。開示された実施形態への種々の変更は、当業者には容易に明白であり、ここに定義された一般的原理は、この開示の精神および範囲から逸脱することなく、他の実施形態およびアプリケーションに適用することができる。したがって、この開示は、図示した実施形態に限定されず、特許請求の範囲と一致する最も広い範囲と一致する。

ここで使用される用語は、特定の例示実施形態のみを記載する目的のためであり、限定することを意図したものではない。ここに使用されるように、単数形「１つ（ａ）」、「１つ（ａｎ）」、および「その（ｔｈｅ）」は、そうではないとコンテキストが明瞭に示さない限り、複数形も同様に含むことを意図することができる。さらに、用語「備える（ｃｏｍｐｒｉｓｅ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、および／または「含む（ｉｎｃｌｕｄｉｎｇ）」は、この開示で使用されるときは、述べられた特徴、ステップ、操作、要素、および／またはコンポーネントの存在を指定するが、１つまたは複数の他の特徴、整数、ステップ、操作、要素、コンポーネント、および／またはそれらのグループの存在または追加を排除しない。

これらのおよび他の特徴、およびこの開示の特性、並びに、構造物の関連する要素、およびパーツの組み合わせ、および製造の経済性の動作と機能の方法は、添付図面（複数の場合もある）を参照して以下の記載を考慮するとき、より明らかとなり、これら全てがこの明細書の一部を形成することが理解される。しかしながら、図面（複数の場合もある）は、説明および記載の目的のためだけであり、この開示を限定することを意図していないことは、明瞭に理解される。図面は、縮尺通りではないことが理解される。

この開示で使用されるフローチャートは、この開示のいくつかの実施形態に従ってシステムが、インプリメントする動作を説明する。フローチャートの動作は、順番に実施しなくてもよいことは、明瞭に理解される。反対に、動作は、逆の順序で、あるいは同時にインプリメントすることができる。さらに、１つまたは複数の他の動作は、フローチャートに追加することができる。１つまたは複数の動作は、フローチャートから除去することができる。

この開示の態様は、モバイルデバイス上にプロンプトメッセージを提示するシステムと方法に関する。この目的のために、システムと方法は、モバイルデバイスのユーザが、需給比率を要求して解析し、他のサービスタイプを、ユーザに推奨するかどうかを判断するために、サービスタイプの需給比率を判断することができる。それらの情報に関する、推奨されるサービスタイプは、モバイルデバイスのユーザインタフェース上に表示された、バブルプロンプトメッセージの形態であり得る。システムと方法は、また、ユーザがサービスプロバイダに割り当てられないか否かも判断することができ、この判断を解析して、別のサービスタイプをユーザに推奨するかどうかを、判断することができる。推奨されたサービスタイプおよび関連する情報は、モバイルデバイスのユーザインタフェース上に表示されるカードプロンプトメッセージの形態であり得る。これらのシステムと方法は、サービスに関する、より多くの情報を提供することができ、ユーザ体験を改善することができる。

図１は、この開示のいくつかの実施形態に従う、例示のオンラインからオフラインへのサービスシステム１００の概略図である。例えば、オンラインからオフラインへのサービスシステム１００は、カーヘイリング（car hailing）、運転代行（chauffeur services）、車の相乗り（car pool）、バスサービス、運転手の雇用（driver hiring）、シャトルサービス、およびオンラインナビゲーションサービスのためのオンラインからオフラインへのサービスプラットフォームであり得る。オンラインからオフラインへのサービスシステム１００は、サーバ１１０およびユーザ端末１２０を含むオンラインプラットフォームであり得る。いくつかの実施形態において、システム１００は、さらに、ストレージデバイス、ネットワーク、およびサービスプロバイダ端末（図示せず）を含むことができる。

サーバ１１０は、サービス要求、および／またはサービスプロバイダに関する情報、および／またはデータを処理するように構成することができる。例えば、サーバ１１０は、サービス要求、および／またはサービスオーダーに応答して、ユーザ端末のユーザインタフェースに提示されたプロンプトメッセージを送信することができる。いくつかの実施形態において、サーバ１１０は、シングルサーバであり、またはサーバグループであり得る。サーバグループは、中央制御され得るか、または分散され得る（例えば、サーバ１１０は、分散システムであり得る）。いくつかの実施形態において、サーバ１１０は、ローカルまたはリモートであり得る。例えば、サーバ１１０は、ユーザ端末１２０、および／またはネットワークを介して、ストレージに記憶された情報、および／またはデータをアクセスすることができる。他の例として、サーバ１１０は、記憶された情報、および／またはデータをアクセスするために、ユーザ端末１２０、および／またはストレージを接続することができる。いくつかの実施形態において、サーバ１１０は、クラウドプラットフォーム上にインプリメントすることができる。単なる例示として、クラウドプラットフォームは、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、インタークラウド、マルチクラウド等、または任意のそれらの組み合わせであり得る。いくつかの実施形態において、サーバ１１０は、この開示において、図２に説明される、１つまたは複数のコンポーネントを有するコンピューティングデバイス２００上に、インプリメントすることができる。

いくつかの実施形態において、サーバ１１０は、処理エンジン（図示せず）を含むことができる。処理エンジンは、この開示に記載された、１つまたは複数の機能を実行するためのサービス要求、および／またはサービスオーダーに関する情報、および／またはデータを処理することができる。例えば、処理エンジンは、サービス要求、および／またはサービスオーダーに応答してユーザ端末のユーザインタフェースに提示された、プロンプトメッセージを送信することができる。いくつかの実施形態において、処理エンジンは、１つまたは複数の処理エンジン（例えば、シングルコア処理エンジン（複数の場合もある）、またはマルチコアプロセッサ（複数の場合もある））を含むことができる。単なる例示として、処理エンジンは、中央処理ユニット（ＣＰＵ）、特定用途集積回路（ＡＳＩＣ）、特定用途命令セットプロセッサ（ＡＳＩＰ）、グラフィクスプロセッサユニット（ＧＰＵ）、物理処理ユニット（ＰＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックデバイス（ＰＬＤ）、コントローラ、マイクロコントローラユニット、縮小命令セットコンピュータ（ＲＩＳＣ）、マイクロプロセッサ等、または任意のそれらの組み合わせのような、１つまたは複数のハードウェアプロセッサであり得る。

ユーザ端末１２０は、カーヘイリングのような、オンラインからオフラインへのサービスを要求するために、ユーザにより使用されるモバイルデバイスであり得る。いくつかの実施形態において、ユーザ端末１２０は、モバイルデバイス、タブレットコンピュータ、ラップトップコンピュータ、モバイルデバイスにおける内蔵デバイス、ユーザ機器（ＵＥ）、モバイルステーション（ＭＳ）、端末等、またはそれらの任意の組み合わせであり得る。いくつかの実施形態において、モバイルデバイスは、ウエアラブルデバイス、スマートモバイルデバイス、バーチャルリアリティデバイス、オーグメンテッドリアリティ（augmented reality）デバイス等、またはそれらの任意の組み合わせであり得る。いくつかの実施形態において、ウエアラブルデバイスは、スマートブレスレット、スマートフットギア（smart footgear）、スマートグラス、スマートヘルメット、スマートウォッチ、スマートクロージング（smart clothing）、スマートバックパック（smart backpack）、スマートアクセサリ等、またはそれらの任意の組み合わせであり得る。いくつかの実施形態において、スマートモバイルデバイスは、スマートフォン、パーソナルデジタルアシスタンス（ＰＤＡ）、ゲームデバイス、ナビゲーションデバイス、ポイントオブセール（ＰＯＳ）デバイス等、またはそれらの任意の組み合わせであり得る。いくつかの実施形態において、バーチャルリアリティデバイス、および／またはオーグメンテッドリアリティデバイスは、バーチャルリアリティヘルメット、バーチャルリアリティグラス、バーチャルリアリティパッチ、オーグメンテッドリアリティヘルメット、オーグメンテッドリアリティグラス、オーグメンテッドリアリティパッチ、等、またはそれらの任意の組み合わせであり得る。例えば、バーチャルリアリティデバイス、および／またはオーグメンテッドリアリティデバイスは、グーグルグラス（登録商標）、ＲｉｆｔＣｏｎ（登録商標）、Ｆｒａｇｍｅｎｔｓ（登録商標）、Ｇｅａｒ ＶＲ（登録商標）等であり得る。いくつかの実施形態において、自動車内の内蔵デバイスは、オンボードコンピュータ、オンボードテレビジョン、等であり得る。

いくつかの実施形態において、ユーザ端末１２０は、ユーザ、および／またはユーザ端末１２０の位置を突き止めるための位置決め技術を備えたデバイスであり得る。この開示で使用される位置決め技術は、グローバルポジショニングシステム（ＧＰＳ）、グローバルナビゲーションサテライトシステム（ＧＬＯＮＡＳＳ）、コンパスナビゲーションシステム（ＣＯＭＰＡＳＳ）、ガリレオポジショニングシステム、準天頂衛星システム（ＱＺＳＳ）、無線フィデリティ（ＷｉＦｉ）位置決め技術、等またはそれらの任意の組み合わせであり得る。上記位置決め技術の１つまたは複数は、この開示では、相互互換性を有して使用することができる。いくつかの実施形態において、ユーザ端末１２０は、さらに少なくとも１つのネットワークポートを含むことができる。前記少なくとも１つのネットワークポートは、ネットワークを介してシステム（例えば、サーバ１１０、ストレージ）内の１つまたは複数のコンポーネントへ情報を送信し、および／またはそれらのコンポーネントから情報を受信するように構成することができる。いくつかの実施形態において、ユーザ端末１２０は、図２に説明される１つまたは複数のコンポーネントを有するコンピューティングデバイス２００上か、またはこの開示の図３に説明される、１つまたは複数のコンポーネントを有するモバイルデバイス３００上にインプリメントすることができる。いくつかの実施形態において、ユーザ端末１２０は、端末内にインストールされたアプリケーションを含むことができる。サーバ１１０は、アプリケーションが提供するサービスのサーバであり得る。

ストレージデバイスは、データ、および／または命令を記憶することができる。例えば、ストレージデバイスは、ユーザ端末１２０から取得されたデータを記憶することができる。他の例として、ストレージデバイスは、サーバ１１０が、この開示に記載した例示方法を実行するように、実行することができ、または使用することができる、データおよび命令を記憶することができる。いくつかの実施形態において、ストレージデバイスは、マスストレージ、リムーバブルストレージ、ボラタイルリードアンドライトメモリ、リードオンリメモリ（ＲＯＭ）、等、またはそれらの任意の組み合わせであり得る。例示マスストレージは、磁気ディスク、光ディスク、ソリッドステートドライブ等を含むことができる。例示リムーバブルストレージは、フラッシュドライブ、フロッピーディスク、光学ディスク、メモリカード、ジップディスク（zip disk）、磁気テープ等を含むことができる。例示ボラタイルリードオンリメモリは、ランダムアクセスメモリ（ＲＡＭ）を含むことができる。例示ＲＡＭは、ダイナミックＲＡＭ（ＤＲＡＭ）、ダブルデートレートシンクロナスダイナミックＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、サイリスタＲＡＭ（Ｔ−ＲＡＭ）、ゼロキャパシタＲＡＭ（Ｚ−ＲＡＭ）等を含むことができる。例示ＲＯＭは、マスクＲＯＭ（ＭＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、イレーザブルプログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的イレーザブルプログラマブルＲＯＭ（ＥＥＰＲＯＭ）、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、およびデジタルバーサタイルディスクＲＯＭ等を含むことができる。いくつかの実施形態において、ストレージデバイスは、クラウドプラットフォーム上でインプリメントすることができる。単なる例示として、クラウドプラットフォームは、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、インタークラウド、マルチクラウド、等またはそれらの任意の組み合わせであり得る。

いくつかの実施形態において、オンラインからオフラインへのサービスシステム１００（例えば、サーバ１１０、ユーザ端末１２０）の１つまたは複数のコンポーネントは、ストレージデバイスをアクセスすることができる。いくつかの実施形態において、オンラインからオフラインサービスシステム１００の１つまたは複数のコンポーネントは、ユーザ、および／または１つまたは複数の条件が満足されたときは、公衆に関する情報を読む、および／または変更することができる。たとえば、サーバ１１０は、サービス完了後の１つまたは複数のユーザの情報を読む、および／または変更することができる。

ネットワークは、情報、および／またはデータの交換を容易にすることができる。いくつかの実施形態において、オンラインからオフラインへのサービスシステム１００（例えば、サーバ１１０、ユーザ端末１２０およびストレージ）の１つまたは複数のコンポーネントは、ネットワークを介してオンラインからオフラインへのサービス内の情報、および／またはデータを他のコンポーネント（複数の場合もある）へ送信することができる。たとえば、サーバ１１０は、ネットワークを介してユーザ端末１２０から、サービスリクエストを受信することができる。いくつかの実施形態において、ネットワークは、有線または無線のネットワーク、またはそれらの組み合わせの任意のタイプであり得る。単なる例示として、ネットワークは、ケーブルネットワーク、有線ネットワーク、光ファイバネットワーク、テレコミュニケーションネットワーク、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ローカルエリアネットワーク（ＷＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、公衆交換電話網（ＰＳＴＮ）、ブルートゥースネットワーク、ＺｉｇＢｅｅネットワーク、近距離無線通信（ＮＦＣ）ネットワーク、等、またはそれらの任意の組み合わせであり得る。

いくつかの実施形態において、ネットワークは、１つまたは複数のネットワークアクセスポイントを含むことができる。たとえば、ネットワークは、オンラインからオフラインへのサービスシステム１００の、１つまたは複数のコンポーネントがネットワークへ接続され、それらの間のデータ、および／または情報を交換することができる、基地局、および／またはインターネット交換ポイントのような、有線または無線ネットワークアクセスポイントを含むことができる。いくつかの実施形態において、オンラインからオフラインへのサービスシステム１００（例えば、サーバ１１０、ユーザ端末１２０、ストレージデバイス）の１つまたは複数のコンポーネントは、有線、および／または無線通信を介して電子、および／または電磁気信号の形態で互いに通信することができる。いくつかの実施形態において、システム１００は、さらに少なくとも１つの情報交換ポートを含むことができる。少なくとも１つの交換ポートは、システム１００内の任意の電子デバイス間でサービス要求（例えば、電子信号、および／または電気信号の形態で）に関する情報を受信、および／または送信するように構成することができる。例えば、少なくとも１つの情報交換ポートは、サーバ１１０とユーザ端末１２０との間の無線通信を介して、ユーザ端末１２０からサービス要求を受信することができる。他の例として、少なくとも１つの情報交換ポートは、無線通信を介してユーザ端末１２０に、プロンプトメッセージを含む電磁気信号を送信することができる。いくつかの実施形態において、少なくとも１つの情報交換ポートは、１つまたは複数のアンテナ、ネットワークインタフェース、ネットワークポート、等または任意のそれらの組み合わせであり得る。例えば、少なくとも１つの情報交換ポートは、情報を送信する、および／またはそこから送信された情報を受信するために、サーバ１１０に接続されたネットワークポートであり得る。

図２は、この開示のいくつかの実施形態に従って、サーバ、および／またはユーザ端末１２０をインプリメントすることができるコンピューティングデバイス２００の例示ハードウェアコンポーネント、およびソフトウェアコンポーネントを説明する概略図である。例えば、処理エンジン１１２は、コンピューティングデバイス２００上にインプリメントすることができ、この開示で開示したサーバまたは処理エンジンの機能を実行するように構成することができる。

コンピューティングデバイス２００は、この開示のためのシステム１００をインプリメントするために使用することができる。通信デバイス２００は、この開示で開示された１つまたは複数の機能を実行するシステム１００の任意のコンポーネントをインプリメントするために使用することができる。例えば、処理エンジンは、ハードウェア、ソフトウェアプログラム、ファームウェア、またはそれらの組み合わせを介してコンピューティングデバイス２００上にインプリメントすることができる。便宜的に、そのようなコンピュータの１つのみが示されているけれども、ここに記載したオンラインからオフラインへのサービスに関するコンピュータ機能は、処理負荷を分散させるために、多数の類似のプラットフォーム上に、分散態様でインプリメントすることができる。

例えば、コンピューティングデバイス２００は、データ通信を容易にするために接続される、ネットワークとの入出力のために、接続されるＣＯＭポート２５０を含むことができる。ＣＯＭポート２５０は、データ通信を容易にする任意のネットワークポート、または情報交換ポートであり得る。コンピューティングデバイス２００は、また、プログラム命令を交換するための、１つまたは複数のプロセッサ（例えば、ロジック回路）の形態の、プロセッサ（例えば、プロセッサ２２０）を含むことができる。例えば、プロセッサは、その中に、インタフェース回路と、処理回路を含むことができる。インタフェース回路は、バス２１０から電子信号を受信するように構成することができ、電子信号は、処理回路が処理するための構造化データ、および／または命令を符号化する。処理回路は、論理計算を行うことができ、次に、結論、結果、および／または電子信号として符号化された命令を決定することができる。処理回路は、または結論、または結果（例えば、文言通りの目的）およびトリガコードを含む電子信号を発生することができる。いくつかの実施形態において、トリガコードは、ＡＩシステム１００内の電子デバイス（例えば、ユーザ端末１３０）のオペレーションシステム（またはそこにインストールされたアプリケーション）により認識可能なフォーマットであり得る。例えば、トリガコードは、モバイルフォンのある機能、および／またはオペレーションを活性化することができる、またはモバイルフォンに所定のプログラム（複数の場合もある）を実行させる命令、コード、マーク、シンボル、等、またはそれらの任意の組み合わせであり得る。いくつかの実施形態において、トリガコードは、電子デバイスのオペレーションシステム（またはアプリケーション）に、結論または結果（例えば、文言通りの目的地）の電子デバイスのインタフェース上への提示を発生させるように構成することができる。次に、インタフェース回路は、バス２１０を介して処理回路から電子信号を送信することができる。

例示コンピューティングデバイスは、通信バス２１０、異なる形態のプログラムストレージおよびデータストレージ、例えば、種々のデータファイルがコンピューティングデバイスにより処理され、および／または送信されるために、ディスク２７０、およびリードオンリメモリ（ＲＯＭ）２３０、またはランダムアクセスメモリ（ＲＡＭ）２４０を含むことができる。例示コンピューティングデバイスは、またプロセッサ２２０により実行される、ＲＯＭ２３０、ＲＡＭ２４０、および／または他のタイプの非一時的ストレージ媒体に記憶されたプログラム命令を含むことができる。この開示の方法、および／またはプロセスは、プログラム命令としてインプリメントすることができる。例示コンピューティングデバイスは、また、プロセッサ２２０により実行される、ＲＯＭ２３０、ＲＡＭ２４０、および／または他のタイプの非一時的記憶媒体に記憶されたオペレーションシステムを含むことができる。プログラム命令は、オンラインからオフラインへのサービスを提供するためのオペレーションシステムと互換性がある。コンピューティングデバイス２００は、また、コンピュータと、他のコンポ−ネントとの間の入出力をサポートするＩ／Ｏコンポーネント２６０を含む。コンピューティングデバイス２００は、また、ネットワーク通信を介してプログラミングとデータを受信することができる。

単なる説明のために唯一のプロセッサが図２に示される。複数のプロセッサも考えられる。従って、この開示に記載された１つのプロセッサによって実行されるオペレーションとステップはまた、複数のプロセッサにより、一緒にまたは別個に実行されることができる。例えば、この開示において、コンピューティングデバイス２００のプロセッサが、ステップＡとステップＢの両方を実行する場合、ステップＡとステップＢは、またコンピューティングデバイス２００内の一緒、または別個の２つの異なるプロセッサによって実行することができる（例えば、第１のプロセッサが、ステップＡを実行し、第２のプロセッサが、ステップＢを実行し、または第１および第２のプロセッサが協働して、ステップＡとステップＢを実行する）ことが理解されねばならない。

図３は、この開示のいくつかの実施形態に従って、ユーザ端末１２０がインプリメントすることができる例示モバイルデバイスの例示ハードウェア、および／またはソフトウェアコンポーネントを説明する概略図である。

図３に説明するように、モバイルデバイス３００は、通信プラットフォーム３１０、ディスプレイ３２０、グラフィック処理ユニット（ＧＰＵ）３３０、中央処理ユニット（ＣＰＵ）３４０、Ｉ／Ｏ３５０、メモリ３６０、およびストレージ３９０を含むことができる。ＣＰＵは、インタフェース回路と、プロセッサ２２０と同様の処理回路を含むことができる。いくつかの実施形態において、これらに限定されないが、システムバス、またはコントローラ（図示せず）を含む任意の他の適切なコンポーネントも、モバイルデバイス３００に含むことができる。いくつかの実施形態において、モバイルオペレーションシステム３７０（例えば、ｉＯＳ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、ＷｉｎｄｏｗｓＰｈｏｎｅ（登録商標）等）、および１つまたは複数のアプリケーション３８０は、ＣＰＵ３４０により実行するために、ストレージ３９０からメモリ３６０にロードすることができる。アプリケーション３８０は、サービスに関する音声要求に関連する情報を受信し、描画するためのブラウザ、または任意の他のモバイルアプリケーションを含むことができる。情報ストリームとのユーザ相互作用は、Ｉ／Ｏデバイス３５０を介して達成することができ、ネットワークを介してシステム１００の処理エンジン、および／または他のコンポーネントに提供することができる。

この開示で記載された、種々のモジュール、ユニット、およびそれらの機能性をインプリメントするために、ハードウェアプラットフォームは、ここに記載されたエレメントの１つまたは複数に関するハードウェアプラットフォーム（複数の場合もある）として使用することができる（例えば、オンラインからオフラインへのサービスシステム１００、および／または図１乃至１８に関して記載された、オンラインからオフラインサービスシステム１００への他のコンポーネント）。そのようなコンピュータのハードウェアエレメント、オペレーティングシステム、およびプログラミング言語は、事実上一般的であり、当業者は、ここに記載した音声要求に応答して、サービスを提供するように、これらの技術を適合させることが推測される。ユーザインタフェースエレメントを備えたコンピュータを使用して、パーソナルコンピュータ（ＰＣ）、または他のタイプのワークステーション、または端末デバイスをインプリメントすることができるが、適切にプログラムされれば、サーバとして動作することもでき得る。当業者は、そのようなコンピュータ機器の構造、プログラミングと汎用オペレーションに精通していると考えられ、この結果、図面は、説明を必要としない。

当業者は、オンラインからオフラインへのサービスシステム１００のエレメントが実行するとき、エレメントは、電気信号、および／または電磁信号を介して実行することができることを理解するであろう。たとえば、サーバ１１０が、サービス要求またはサービスオーダーのようなタスクを処理するとき、サーバ１１０は、そのようなタスクを処理するためにそのプロセッサ内のロジック回路を動作させることができる。サーバ１１０が、サービス要求、またはサービスオーダーを受信するとき、サーバ１１０のプロセッサは、サービス要求を符号化する電気信号を発生することができる。サーバ１１０のプロセッサは、次に、電気信号をサーバ１１０に関連づけられたターゲットシステムの少なくとも１つの情報交換ポートに送信することができる。サーバ１１０は、有線ネットワークを介してターゲットシステムと通信し、少なくとも１つの情報交換ポートは、物理的にケーブルに接続可能であり、それは、ユーザ端末１２０の入力ポート（例えば、情報交換ポート）に、電気信号をさらに送信することができる。サーバ１１０が、無線ネットワークを介してターゲットシステムと通信する場合、ターゲットシステムの少なくとも１つの情報交換ポートは、１つまたは複数のアンテナであり得、それは電気信号を電磁気信号信号に変換することができる。ユーザ端末１２０、および／またはサーバ１１０のような電子デバイス内で、それらのプロセッサが、命令を処理し、命令を送信し、および／またはアクションを実行するとき、命令および／またはアクションは、電気信号を介して行われる。例えば、プロセッサが、ストレージ媒体（例えば、ストレージデバイス）からのデータを受信し、またはセーブすると、電気信号をストレージ媒体のリード／ライトデバイスに送信することができ、それは、ストレージ媒体内の構造化データを読み書きすることができる。構造化データは、電子デバイスのバスを介して電子信号の形態でプロセッサに送信することができる。ここで、電気信号は、１つの電気信号、一連の電気信号、および／または複数の離散した電気信号であり得る。

図４Ａは、この開示のいくつかの実施形態に従うプロンプトメッセージを提示する、例示の第１のシステムを説明するブロック図である。図４Ａに示すように、第１のシステム４１０は、受信モジュール４１１、判断モジュール４１２、およびプッシュモジュール４１３を含むことができる。

受信モジュール４１１は、サービス要求、および／またはオーダーに関する情報を取得するように構成することができる。例えば、受信モジュール４１１は、ユーザ端末１２０から第１のサービスタイプのサービス要求を取得することができる。いくつかの実施形態において、サービス要求は、ユーザ端末のロケーション、開始ロケーション、目的地、要求時間、開示時間、サービスタイム等、またはそれらの任意の組み合わせを含む。いくつかの実施形態において、サービス要求は、第１のサービスタイプを用いて移動する意図であり得る。他の例として、受信モジュール４１１は、ユーザ端末１２０から第１の移動オーダーを取得することができる。いくつかの実施形態において、第１の移動オーダーは、ターゲットサービスタイプ、第１の移動オーダーの第１の送信時間、開始ロケーション、目的地、開示時間等、またはそれらの任意の組み合わせを含むことができる。

判断モジュール４１２は、サービス要求、および／またはオーダーに関係する結果を判断するように構成することができる。例えば、判断モジュール４１２は、ユーザ端末１２０のロケーションに基づいて、第１のサービスタイプの第１の需給率を決定することができる。いくつかの実施形態において、第１の需給率は、ユーザ端末１２０のロケーション（またはユーザの開始ロケーション）から所定の距離内のエリア内のユーザ端末（または、ターゲットサービスタイプを要求するサービス要求者）のカウント値に対する利用可能な乗り物（または利用可能なサービスプロバイダ）のカウント値の比率であり得る。例示として、判断モジュール４１２は、第１の送信時間と、ターゲットサービスタイプの未割当のオーダーキュー内の、少なくとも１つの第２の移動オーダーの、少なくとも１つの第２の送信時間に基づいて、第１の移動オーダーの待ち時間とキュー番号を決定することができる。いくつかの実施形態において、少なくとも１つの第２の移動オーダーは、ユーザ端末１２０のエリア内の複数の他のユーザ端末により送信された、複数の移動オーダーを含むことができる。少なくとも１つの第２の移動オーダーは、第１の移動オーダーのそれと同じターゲットサービスタイプを含むことができる。

プッシュモジュール４１３は、情報をユーザ端末１２０に送信するように構成することができる。例えば、プッシュモジュール４１３は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェースに提示された第１のバブルプロンプトメッセージを送信することができる。いくつかの実施形態において、第１のバブルプロンプトメッセージは、第２のサービスタイプの応答情報を含むことができる。第２のサービスタイプの応答情報は、第２のサービスタイプおよび第２のサービスタイプの応答時間を含むことができる。

他の例として、プッシュモジュール４１３は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェース上に提示された、第２のバブルプロンプトメッセージを送信することができる。いくつかの実施形態において、第２のバブルプロンプトメッセージは、第１の移動オーダーのキュー番号と待ち時間を含むことができる。

さらに他の例として、プッシュモジュール４１３は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェース上に提示された、第３のバブルプロンプトメッセージを送信することができる。いくつかの実施形態において、第３のバブルプロンプトメッセージは、割当てられた乗り物に関する情報を含むことができる。

図４Ｂは、この開示のいくつかの実施形態に従うプロンプトメッセージを提示する例示の第１のシステムを説明するブロック図である。図４Ｂに示すように、第１のシステム４１０は、さらに記録モジュール４１４と、割り当てモジュール４１５をさらに含むことができる。

記録モジュール４１４は、ユーザ端末１２０により送信された、第１の移動オーダーを受信した後に、第１の移動オーダーの待ち時間を記録することができる。いくつかの実施形態において、第１の移動オーダーの待ち時間は、サーバ１１０が、第１のオーダーを処理するのにどれだけ長く費やすかであり得る。

割当モジュール４１５は、第１の移動オーダーに基づいて、ユーザ端末１２０に乗り物を割当てるように構成することができる。いくつかの実施形態において、割当てモジュール４１５は、ユーザ端末１２０のロケーション（またはユーザの開示ロケーション）に基づいて、ユーザをピックアップすることができ、第１の移動オーダーと同じサービスタイプである、ユーザ端末１２０に最も近い乗り物を、ユーザ端末１２０に割り当てることができる。

図４Ａ、および／または図４Ｂに説明された第１のシステム４１０内のモジュールは、有線接続、または無線接続を介して互いに接続、または通信することができる。有線接続は、金属ケーブル、光ケーブル、ハイブリッドケーブル等、またはそれらの任意の組み合わせであり得る。無線接続は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ブルートゥース、ＺｉｇＢｅｅ、近距離通信（ＮＦＣ）等、またはそれらの任意の組み合わせであり得る。２以上のモジュールは、単一モジュールに結合することができ、それらのモジュールの任意の１つは、２以上のユニットに分割することができる。例えば、受信モジュール４１１とプッシュモジュール４１２は、両方が情報を取得および送信することができる単一モジュールとして結合することができる。他の例として、処理エンジン１１２は、モデル、および／または文言通りの目的地のデータ、および／または情報を記憶するのに使用される、ストレージモジュール（図示せず）を含むことができる。

図４Ｃは、この開示のいくつかの実施形態に従うプロンプトメッセージを提示する、例示の第２のシステムを説明するブロック図である。図４Ｂに説明されるように、第２のシステム４２０は、送信モジュール４２１、受信モジュール４２２、表示モジュール４２３を含むことができる。

送信モジュール４２１は、情報をユーザ端末１２０に送信するように構成することができる。例えば、送信モジュール４２１は、ユーザ端末１２０へ、ユーザ端末１２０のユーザインタフェースに提示された、カードプロンプトメッセージを送信することができる。いくつかの実施形態において、カードプロンプトメッセージは、推奨されるサービスタイプの属性情報を含むことができる。例えば、推奨されるサービスタイプの属性情報は、推奨されるサービスタイプ、推奨されるサービスタイプのロゴ（例えば、その名前またはイメージ）、推奨されるサービスタイプの応答時間等、またはそれらの任意の組合せを含むことができる。推奨されるサービスタイプの応答時間は、推奨されるサービスタイプの乗り物が、ピックアップ時間とも呼ぶことができる、ユーザの開始ロケーションに到着するのにかかる時間であり得る。

受信モジュール４２２は、サービス要求、および／またはオーダーに関する情報を取得するように構成することができる。例えば、受信モジュール４２２は、ユーザ端末１２０から、第１の移動オーダーを取得することができる。いくつかの実施形態において、第１の移動オーダーは、ユーザ端末１２０内のオンラインからオフラインへのサービスアプリケーションのユーザインタフェース上に、ユーザにより、トリガすることができる。いくつかの実施形態において、第１の移動オーダーは、ターゲットサービスタイプ、第１の移動オーダーの第１の送信時間、開始ロケーション、目的地、開始時間、ユーザ端末のロケーション、等または、それらの任意の組み合わせを含むことができる。

ディスプレイモジュール４２３は、ユーザ端末の１２０のユーザインタフェースに、カードプロンプトメッセージを表示するように、ユーザ端末１２０に指示することができる。

図４Ｄは、この開示のいくつかの実施形態に従うプロンプトメッセージを提示するための、例示第２のシステムを説明するブロック図である。図４Ｄに説明するように、第２のシステム４２０は、さらに処理モジュール４２４を含むことができる。

処理モジュール４２４は、前記第１の移動オーダーに関する結果を決定するように構成することができる。例えば、処理モジュール４２４は、前記第１の移動オーダーが、前記ユーザ端末からのキャンセル要求に基づいて、乗り物に割り当てられないと決定することができる。他の例として、前記処理モジュール４２４は、前記ターゲットサービスタイプの第２需給比率を決定するとともに、前記第２の需給比率が、第２の比率しきい値より大きいかどうかを判断することができる。第２の需給比率が、第２の比率しきい値より大きくない場合、前記処理モジュール４２４は、第１の移動オーダーが、乗り物に割り当てられないと決定することができる。さらに、他の例として、処理モジュール４２４は、推奨されたサービスタイプを決定することができる。

図４Ｃ、および／または図４Ｄに説明された第２のシステム４２０内のモジュールは、有線接続、または無線接続を介して互いに接続、または通信することができる。有線接続は、メタルケーブル、光ケーブル、ハイブリッドケーブル等、または、それらの任意の組合せであり得る。無線接続は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ブルートゥース、ＺｉｇＢｅｅ、近距離通信（ＮＦＣ）、等、またはそれらの任意の組み合わせであり得る。モジュールの２つ以上は、１つのモバイルに結合することができ、モジュールの任意の１つは、２以上のユニットに分割することができる。例えば、受信モジュール４１１とプッシュモジュール４１２は、両方が、情報を取得し、送信することができる、単一モジュールとして結合することができる。さらに他の例として、処理エンジン１１２は、モデル、および／または文言通りの目的地のデータ、および／または情報を記憶するために使用される、ストレージモジュール（図示せず）を含むことができる。

図５は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。図５に説明するように、アプリケーションは、カーヘイリングサービス（a car hailing service）のアプリケーションであり得る。このアプリケーションにおいて、相乗りサービス（a car pooling service）、タクシーサービス、エクスプレスサービス、バスサービス、等、またはそれらの任意の組み合わせのような、複数のサービスタイプがあり得る。いくつかの実施形態において、ユーザが、ユーザ端末１２０上のアプリケーションを使用するとき、サーバ１１０は、ユーザ端末１２０の位置情報を取得することができる。ユーザ端末１２０から、あるサービスタイプに関するサービス要求を受信することに応答して、サーバ１１０は、ユーザ端末１２０の位置決め情報に基づいて、対応するサービスタイプの応答時間を決定することができる。前記サーバ１１０は、さらに、前記応答時間を有するバブルメッセージを、ユーザ端末１２０にプッシュする。いくつかの実施形態において、ユーザ端末１２０は、ユーザまたはユーザ端末１２０の現在のロケーションを、サービスタイプに対応するユーザインタフェースに表示された、マップ上にマークを付けることができ、ユーザまたはユーザ端末１２０のマークを付けた現在のロケーションにバブルメッセージを介して、そのようなサービスタイプの応答時間を、ユーザに思い出させることができる。応答時間は、そのようなサービスタイプの乗り物が、ユーザの開始ロケーションに到着する時間であり得、それは、またピックアップ時間と呼ぶことができる。例えば、バブルメッセージは、「ここで、車に乗るには２分です。」であり得る。図５は、ユーザがエクスプレスサービスを選択したときの、バブルメッセージを説明する例示ユーザインタフェースである。

いくつかの実施形態において、サーバ１１０が、ユーザの開始ロケーション、またはユーザの現在のロケーションから所定距離内のエリア内で、サービスタイプの乗り物が、供給不足であると判断すると、サーバ１１０は、「この付近に利用可能な車はありません」を含むバブルメッセージを、ユーザ端末１２０にプッシュすることができる。しかしながら、上記バブルメッセージにより、ユーザは、そのようなサービスタイプの乗り物が不足していることしか知ることしかできない。ユーザは、ユーザの移動を容易にする他の情報を取得することができず、それによりユーザ体験は相対的に低下する。

上記問題を考慮して、この開示におけるバブルプロンプトメッセージを提示するシステムと方法は、バブルメッセージが従来技術における、ユーザの実際の使用に対する要求を満足させることができないという問題を解決するために提供される。

この開示における車を拾うアプリケーションに含まれるサービスタイプは、特に、カーヘイリングアプリケーションの設計に、特に関連していることに留意する必要がある。例えば、いくつかのカーヘイリングアプリケーションにおいて、サービスタイプは、乗り合いサービス、タクシーサービス、エクスプレスサービス、バスサービス、プライベートカー、等、またはそれらの任意の組み合わせを含むことができる。各サービスタイプは、ユーザインタフェースに対応する。いくつかのカーヘイリングアプリケーションにおいて、サービスタイプは、異なる乗物タイプに基づいて決定することができる。例えば、サービスタイプは、オフィシャルカーサービス、７つのシートを有する商用車サービス、リムジンサービス、等、またはそれらの任意の組み合わせを含むことができる。この開示において、カーヘイリングアプリケーションで説明された乗合サービス、タクシーサービス、エクスプレスサービス、およびバスサービスは、記載および紹介の目的のためにのみ示されている。この開示におけるバブルプロンプトメッセージを提示するシステムと方法は、アプリケーションシナリオに限定されないことは、当業者には理解されなければならない。多くの他のサービスタイプの乗り物に提供される、任意のカーヘイリングアプリケーションは、この開示により提供されるバブルプロンプトメッセージを採用することができ、それにより、ユーザ体験を改善することができる。任意のオンラインからオフラインサービスへのアプリケーションは、またこの開示により提供されたバブルプロンプトメッセージを採用することができる。

図６は、この開示のいくつかの実施形態に従う、第１のバブルプロンプトメッセージに関する例示プロセスを説明するフローチャートである。プロセス６００は、オンラインからオフラインへのサービスシステム１００によって、またはオンラインからオフラインへのサービスシステム１００を統合するサーバによって実行することができる。例えば、プロセス６００は、ストレージＲＯＭ２３０、またはＲＡＭ２４０に記憶された命令のセット（例えば、アプリケーション）としてインプリメントすることができる。プロセッサ２２０は、命令のセットを実行することができ、命令を実行すると、プロセス６００を実行するように構成することができる。以下に提示される、図示された処理の動作は、例示であることを意図している。いくつかの実施形態において、プロセス６００は、記載されていない、および／または１つまたは複数の上記した動作無しに、１つまたは複数のさらなる動作を達成することができる。さらに、図６に示されるプロセスの動作の順番、および以下の説明は、限定することを意図したものではない。

プロセス６００は、ユーザ端末１２０から、あるサービスタイプに関するサービス要求を取得することに応答して、サーバ１１０は、あるサービスタイプの需給比率が、所定の比率しきい値より大きくないとき、他のサービスタイプを含む第１のバブルプロンプトメッセージを、ユーザ端末にプッシュすることができる。

６１０において、サーバ１１０（例えば、プロセッサ２２０、受信モジュール４１１）は、ユーザ端末１２０から第１のサービスタイプのサービス要求を取得することができる。いくつかの実施形態において、サービス要求は、ユーザ端末のロケーション、開始ロケーション、目的地、要求時間、開始時間、サービスタイプ、等、またはそれらの任意の組み合わせを含む。いくつかの実施形態において、サービス要求は、第１のサービスタイプを用いて移動することに関する意図であり得る。

いくつかの実施形態において、ユーザが、カーヘイリングアプリケーション（ユーザは、移動オーダーを送信しなかった）のユーザインタフェース上の第１のサービスタイプを選択すると、ユーザ端末１２０は、第１のサービスタイプの要求をサーバ１１０に送信することができ、サービス要求は、ユーザ端末１２０の第１のサービスタイプに関する要求があることをサーバ１１０に示す。サーバ１１０は、ユーザ端末１２０から第１のサービスタイプに関するサービス要求を取得することができる。

いくつかの実施形態において、ユーザ端末１２０は、第１のサービスタイプに関する要求を、サービス要求メッセージを介して、サーバ１１０に送信することができる。ユーザ端末１２０は、また、第１のサービスタイプに関する要求を、任意の既存の方法を介してサーバ１１０に送信することができる。

いくつかの実施形態において、ユーザ端末１２０は、また、第１のサービスタイプに関するサービス要求を、他の既存のメッセージを介してサーバ１１０に送信することができる。例えば、カーヘイリングアプリケーションにおいて、各サービスタイプは、ユーザインタフェースに対応することができる。それゆえ、ユーザ端末１２０は、第１のサービスタイプに対応するユーザインタフェースのデータを要求するネットワーク要求を、ネットワーク機器に送信して、ユーザ端末１２０の、第１のサービスタイプに関するサービス要求を、暗黙のうちに、ネットワーク要求を介して、ネットワーク機器に知らせることができる。

図７は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。図７に示すように、ユーザが、カーヘイリングアプリケーションの、ユーザインタフェース上のエクスプレス（すなわち、第１のサービスタイプ）を選択すると、ユーザ端末１２０は、エクスプレスに対応するユーザインタフェースのデータを要求する、ネットワーク要求をネットワーク機器に送信して、ユーザ端末１２０の第１のサービスタイプに関するサービス要求を、ネットワーク要求を介してネットワーク機器に、暗黙的に示すことができる。

６２０において、サーバ１１０（例えば、プロセッサ２２０、決定モジュール４１２）は、ユーザ端末のロケーションに基づいて第１のサービスタイプの第１の需給比率を決定することができる。いくつかの実施形態において、サーバ１１０は、開始ロケーションに基づいて、第１のサービスタイプの第１の需給比率を決定することができる。

いくつかの実施形態において、サーバ１１０は、ユーザ端末１２０のロケーション、またはユーザ端末１２０からの、ユーザのロケーションを取得することができる。サーバ１１０は、ユーザ端末のロケーション（またはユーザの開始ロケーション）から所定の距離内のエリア内の、第１のサービスタイプの、第１の需給比率を決定することができる。いくつかの実施形態において、第１の需給比率は、エリア内のユーザ端末のカウント（またはターゲットサービスタイプを要求するサービス要求者）のカウントに対する、利用可能な乗り物（または利用可能なサービスプロバイダ）のカウントの比率であり得る。いくつかの実施形態において、エリアは、ユーザ端末１２０のロケーションの中心（またはユーザの開始ロケーション）である、円形エリア、方形エリア、六角形エリア等を含むことができる。所定の距離は、この開示では、定義されない、サーバの構成に従って、決定することができる。

例えば、サーバ１１０は、ユーザ端末またはユーザ（またはユーザの開始ロケーション）、所定のエリア形状、および所定のエリアサイズに基づいて、エリアを決定することができる。ユーザ１１０は、その決定されたエリア内に、サービスを提供することができる、第１のサービスタイプの利用可能な乗り物のカウントと、決定されたエリア内の第１のサービスタイプを使用することが予想される、ユーザ端末のカウントを、計算することができる。サーバ１１０は、２つの計算されたカウントの比率を、ユーザ端末１２０のエリア内の、第１のサービスタイプの第１の需給比率として計算することができる。

いくつかの実施形態において、ユーザ端末、またはユーザのロケーション（またはユーザの開始ロケーション）を、ユーザ端末１２０からサーバ１１０に送信する方法は、限定されない可能性がある。例えば、ユーザ端末１２０は、６１０内に説明されるサービス要求内のロケーション（または開始ロケーション）をサーバ１１０に送信することができる。他の例として、ユーザ端末１２０は、ロケーション（または開始ロケーション）を別個のメッセージを介して、または任意の他の既存の方法を介してサーバ１１０に送信することができる。

図７に戻ると、ユーザが、カーヘイリングアプリケーションのユーザインタフェース上のエクスプレス（すなわち、第１のサービスタイプ）を選択すると、サーバ１１０は、エクスプレスサービスのサービス要求を取得することができる。サーバ１１０は、ユーザ端末またはユーザのロケーション（またはユーザの開始ロケーション）を取得することができる。サーバ１１０は、決定されたエリア内にサービスを提供することができる、第１のサービスタイプの利用可能な乗り物のカウントと、決定されたエリア内の第１のサービスタイプを使用することが予想される、ユーザのカウントを計算することができる。サーバ１１０は、２つの計算されたカウントを、ユーザ端末１２０のエリア内の、第１のサービスタイプの第１の需給比率として計算することができる。

６３０において、第１の需給比率が、第１の比率しきい値より大きくないと決定することに応答して、サーバ１１０（例えば、プロセッサ２２０、プッシュモジュール４１３）は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェース上に、提示された第１のバブルプロンプトメッセージを送信することができる。いくつかの実施形態において、第１のバブルプロンプトメッセージは、第２のサービスタイプの応答情報を含むことができる。第２のサービスタイプの応答情報は、第２のサービスタイプと、第２のサービスタイプの応答時間を含むことができる。

いくつかの実施形態において、第１の比率しきい値は、第１のサービスタイプが、供給不足かどうかを測定するために使用することができる。いくつかの実施形態において、サーバ１１０は、第１の需給比率は、第１の比率しきい値より大きいと判断することができる。例えば、サーバ１１０は、第１の需給比率と第１の比率しきい値を比較することができる。いくつかの実施形態において、第１の比率しきい値は、サーバ１１０またはそのユーザにより決定することができる。例えば、第１の比率しきい値は、サーバ１１０またはそのユーザにより予め設定された値であり得る。他の例として、第１の比率しきい値は、異なる市、異なる区、異なるエリア、異なる時間、等、またはそれらの任意の組み合わせに従って、決定することができる。

第１のサービスタイプの第１の需給比率が、第１の比率しきい値より大きくないとき、第１のサービスタイプが、ユーザ端末１２０のエリア内で不足していることを示す。そのようなシナリオでは、サーバ１１０は、第１のバブルプロンプトメッセージ内の、第２のサービスタイプの応答情報をユーザ端末１２０に送信することができる。ユーザ端末１２０は、第１のバブルプロンプトメッセージを、そのユーザインタフェース上に表示することができる。いくつかの実施形態において、第２のサービスタイプの応答情報は、第２のサービスタイプと、第２のサービスタイプの応答情報を含むことができる。いくつかの実施形態において、第２のサービスタイプの需給比率は、ユーザ端末１２０のエリア内の、第１のサービスタイプの第１の需給比率より大きい。例えば、第２のサービスタイプの第２の需給比率は、ユーザ端末１２０のエリア内の、複数のサービスタイプの需給比率の中で最大である。

これにより、ユーザは、第１のサービスタイプが不足しているとき、第１のバブルプロンプトメッセージを介して、現在最大の需給率を有する乗り物の応答情報を取得することができる。ユーザは、第１のサービスタイプを選択し続けるか、または第１のバブルプロンプトメッセージに基づいて、第１のサービスタイプより大きな需給比率を有する、サービスタイプを選択し続けるかどうかを、決定することができる。さらに、サーバ１１０は、選択されたサービスタイプの需給比率が不足しているとき、他のサービスタイプを選択するようにガイドすることができ、ユーザの解約率を減らすことができる。

図７を参照すると、ユーザが、カーヘイリングアプリケーションの、ユーザインタフェース上のエクスプレス（すなわち、第１のサービスタイプ）を選択すると、ユーザ端末１２０のロケーション（またはユーザの開始ロケーション）に従って、ユーザ端末１２０内のエクスプレスの第１の需給比率を取得した後で、サーバ１１０は、エクスプレスの第１の需給比率が、事前設定されたしきい値より大きいかどうかを判断することができる。いくつかの実施形態において、事前設定されたしきい値は、サーバ１１０、またはそのユーザにより決定することができる。例えば、このしきい値は、サーバ１１０またはそのユーザにより決定された、事前設定された値であり得る。他の例として、このしきい値は、異なる市、異なる区、異なるエリア、異なる時間、等、またはそれらの任意の組み合わせのような、異なるアプリケーションシナリオに従って、決定することができる。

エクスプレスの第１の需給比率が、第１の比率しきい値より大きくないとき、エクスプレスは、ユーザ端末１２０のエリア内で不足していることを示す。サーバ１１０は、ユーザ端末１２０のエリア内の、最大需給率を有する乗り物（すなわち、第２のサービスタイプ）を決定することができる。例えば、第２のサービスタイプの乗り物は、バスであり得る。サーバ１１０は、バスの応答情報を含む第１のバブルプロンプトメッセージを、ユーザ端末１２０にプッシュすることができる。ユーザ端末１２０は、第１のバブルプロンプトメッセージを、エクスプレスの対応するユーザインタフェース上に、表示することができる。例えば、第１のバブルプロンプトメッセージは、「エクスプレスはビジーです！バスを試してみますか？１分」を含むことができる。第１のバブルプロンプトメッセージは、第２のサービスタイプが、バスサービスであり、第２のサービスタイプの応答時間が、１分であることを示す。バスサービスのバスは、ユーザ端末またはユーザのロケーション（またはユーザの開始ロケーション）に到着するのに１分かかる可能性がある。

これにより、ユーザは、エクスプレスサービスが不足しているとき、第１のバブルプロンプトメッセージを介して現在最大の需給率を有するバスサービスの応答情報を、迅速に取得することができる。ユーザは、第１のバブルプロンプトメッセージに基づいて、エクスプレスサービスを選択し続けるかまたは、バスサービスを選択し続けるかを判断して、ユーザの移動効率を改善し、ユーザ体験を改善することができる。さらに、サーバ１１０は、選択されたサービスタイプの需給比率が不足しているとき、他のサービスタイプを選択するようにユーザを案内することができ、ユーザの解約率を低減することができる。

いくつかの実施形態において、第１のバブルプロンプトメッセージは、さらに第２のサービスタイプを表示する、ユーザインタフェースへのリンクを含むことができる。サーバ１１０が、第１のバブルプロンプトメッセージをユーザ端末１２０に送信した後、ユーザ端末１２０は、第２のサービスタイプの応答情報を、バブルの形態で表示しながら、第１のサービスタイプに対応するユーザインタフェース上に、第２のサービスタイプに対応するユーザインタフェースへのリンクを、表示することができる。このように、ユーザが第１のバブルプロンプトメッセージを介して第２のサービスタイプの応答情報を獲得した後で、ユーザが、第２のサービスタイプで移動するように判断する場合、ユーザは、第１のバブルプロンプトメッセージ上の、表示されたリンクをクリックして、第１のサービスタイプに対応するユーザインタフェースから、第２のサービスタイプに対応するユーザインタフェースへ、迅速にジャンプすることができる。ユーザの移動効率とユーザ体験が改善される。

図７を参照すると、例えば、第２のサービスタイプは、バスサービスである。サーバ１１０は、バスサービスの応答情報と、バスに対応するユーザインタフェースへのリンクを含む、第１のバブルプロンプトメッセージを、ユーザ端末１２０に送信することができる。例えば、第１のバブルプロンプトメッセージは、「エクスプレスはビジーです！バスを試してみますか？１分＞」を含むことができる。シンボル「＞」は、バスサービスのユーザインタフェースへのリンクの、ビジュアルアイコンであり得る。いくつかの実施形態において、ユーザがバスサービスを選択することを判断した場合、ユーザは、第１のバブルプロンプトメッセージ内のシンボル「＞」をクリックすることができる。ユーザ端末１２０は、バスサービスのユーザインタフェースへ迅速にジャンプし、それは、ユーザの移動効率を改善し、ユーザ体験を改善する。

いくつかの実施形態において、第１のバブルプロンプトメッセージは、さらに第１のサービスタイプの第１の需給比率に関するデータを、含むことができる。第１の需給比率に関するデータは、第１のサービスタイプの第１の需給比率のビューを生成するように、ユーザ端末１２０に示すことができる。サーバ１１０は、第１のバブルプロンプトメッセージをユーザ端末１２０に送信し、ユーザ端末１２０は、第１のサービスタイプの第１の需給比率のビュー、およびバブルのフォーマットにおける、第１のサービスタイプに対応する、ユーザインタフェース上の第２のサービスタイプの応答情報を表示することができる。このようにして、ユーザは、第１の需給比率の視覚化された表示を介して、第１のサービスタイプの、第１の需給比率を知覚することができる。ユーザの移動効率と、ユーザ体験は改善される。

いくつかの実施形態において、第１の需給比率の表示は、第１の需給比率の視覚化を供給することができる、任意の表示を含むことができる。図７は、計器盤に類似した表示のフォーマットで、第１の需給比率の表示を説明する。図７は、例示目的のみであり、第１のバブルプロンプトメッセージは、第２のサービスタイプの応答情報と、第２のサービスタイプに対応するユーザインタフェースへのリンクと、第１のサービスタイプの第１の需給比率の表示、またはそれらの任意の組み合わせを含むことができる。

図８は、この開示のいくつかの実施形態に従う、第２のバブルプロンプトメッセージを表すための例示プロセスを説明するフローチャートである。プロセス８００は、オンラインからオフラインへのサービスシステム１００により、実行することができ、あるいは、オンラインからオフラインへのサービスシステム１００を統合するサーバにより、実行することができる。例えば、プロセス８００は、ストレージＲＯＭ２３０またはＲＡＭ２４０に記憶された命令のセット（例えば、アプリケーション）としてインプリメントすることができる。プロセッサ２２０は、命令のセットを実行することができ、命令を実行すると、プロセス８００を実行するように構成することができる。下記に示される図示されたプロセスの動作は、例示を意図したものである。いくつかの実施形態では、プロセス８００は、記載していない、および／または上述した１つ以上の動作無しに達成することができる。さらに、図８に説明されたプロセスの動作および下記に記載したオーダーは、制限することを意図したものではない。

プロセス８００は、以下を含むことができる。ユーザ端末１２０からの第１の移動オーダーを取得することに応答して、サーバ１１０は、第１の移動オーダーのキュー番号を含む第２のバブルプロンプトメッセージをプッシュすることができる。

８１０において、サーバ１１０（例えば、プロセッサ２２０、受信モジュール４１１）は、ユーザ端末１２０から、第１の移動オーダーを取得することができる。いくつかの実施形態において、第１の移動オーダーは、ターゲットサービスタイプ、第１の移動オーダーの第１の送信時刻、開始ロケーション、目的地、開始時刻、等、またはそれらの任意の組み合わせを含むことができる。

いくつかの実施形態において、ユーザ端末のユーザが、開始位置と目的地を有する、第１の移動オーダーを、カーヘイリングアプリケーションのユーザインタフェースを介して送信し、サーバ１１０は、第１の移動オーダーを取得することができる。

８２０において、サーバ１１０（例えば、プロセッサ２２０、決定モジュール４１２）は、第１の送信時間と、ターゲットサービスタイプの未割当オーダーキューにおける、少なくとも１つの第２の移動オーダーの、少なくとも１つの第２の送信時間に基づいて、第１の移動オーダーのキュー番号と待ち時間を決定することができる。

いくつかの実施形態において、少なくとも１つの第２の移動オーダーは、ユーザ端末１２０内のエリア内の、複数の他の端末により送信された複数の移動オーダーを含むことができる。少なくとも１つの第２の移動オーダーは、第１の移動オーダーと同じターゲットサービスタイプを含むことができる。

いくつかの実施形態において、サーバ１１０が、ユーザ端末１２０から、第１の移動オーダーを取得した後、サーバ１１０は、第１の移動オーダーと、その送信時間の降べきの順にしたがって、ユーザ端末１２０のエリア内の、複数の未処理移動オーダー（少なくとも１つの第２の移動オーダーとも呼ばれる）をキューイング（queuing）することができる。サーバ１１０は、第１の移動オーダーのキュー番号を取得することができる。いくつかの実施形態において、未処理移動オーダーは、サーバ１１０が乗り物を割当てなかった移動オーダーであり得る。未処理移動オーダーのユーザは、対応するユーザをピックアップするための乗り物に割り当てられていない。

いくつかの実施形態において、第１の移動オーダーの待ち時間は、サーバ１１０が、第１の移動オーダーを処理するのにかかる時間であり得る。第１の移動オーダーの待ち時間を決定する方法は、この開示に限定されなくてもよい。例えば、サーバ１１０は、所定の移動オーダーの平均処理時間、および第１の移動オーダーのキュー番号に基づいて、待ち時間を決定することができる。

８３０において、サーバ１１０（例えば、プロセッサ２２０、プッシュモジュール４１３）は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェースに提示された、第２のバブルプロンプトメッセージを送信することができる。いくつかの実施形態において、第２のバブルプロンプトメッセージは、第１の移動オーダーのキュー番号と待ち時間を含むことができる。

いくつかの実施形態において、ユーザ端末１２０は、バブルのフォーマットの、複数の未処理移動オーダーのリスト内の、第１の移動オーダーのキュー番号と待ち時間を表示することができる。ユーザは、カーヘイリングアプリケーションを用いるとき、バブルにフォーカスすることができる。それゆえ、ユーザは、第２のバブルプロンプトメッセージを介して、移動オーダーの処理状態をタイムリーに獲得することができる。ユーザ経験が改善される。

図９は、この開示のいくつかの実施形態に従うユーザ端末上のアプリケーションの例示ユーザインタフェースである。図９に示すように、ユーザが、カーヘイリングアプリケーションのユーザインタフェース上に、移動オーダーを送信すると、ユーザ端末１２０は、移動オーダーの状態と、ユーザインタフェース上のバブルフォーマットで、移動オーダーを処理することができる、累積時間を表示することができる。例えば、バブルプロンプトメッセージは、「待機中００：２０。車両を検索しています。」を含むことができる。「待機中００：２０」は、移動オーダーを処理することができる累積時間であり得る。「車両を検索しています。」は、移動オーダーの状態であり得る。

図９に説明するバブルプロンプトメッセージは、サーバ１１０が自分の移動オーダーを処理したかどうか、あるいはユーザの経過待ち時間を、ユーザに提供することができない。ユーザ経験は、貧弱である。

図１０は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。図１０に示すように、ユーザ端末１２０が、エクスプレスサービスを呼びかける（hail）ための第１の移動オーダーを、サーバ１１０に送信した後で、サーバ１１０は、第１の移動オーダーのキュー番号と待ち時間を含む第２のバブルプロンプトメッセージを、ユーザ端末１２０に送信することができる。このように、ユーザ端末１２０は、第１の移動オーダーのキュー番号と待ち時間をバブルフォーマットで、ユーザインタフェース上に表示することができる。例えば、第２のバブルプロンプトメッセージは、「あなたはキュー（待ち行列）の３番にいます。１分、お待ちください。」を含むことができる。「３番」は、複数の未処理移動オーダーのリスト内の、第１の移動オーダーのキュー番号であり得る。「１分」は、第１の移動オーダーの待ち時間であり得る。いくつかの実施形態において、第２のバブルプロンプトメッセージは、また、図１０に示すように、「あなたはキューにいます」の第１の移動オーダー状態のようなオリジナルバブルメッセージを含むことができる。

それゆえ、ユーザは、第２のバブルプロンプトメッセージを介して、ユーザの第１の移動オーダーの処理状態を、タイムリーに獲得することができる。ユーザ体験が改善される。

いくつかの実施形態において、サーバ１１０は、時間しきい値を設定することができる。時間しきい値は、第１の移動オーダーの待ち時間が、長すぎるかどうかを測定するために使用することができる。いくつかの実施形態において、時間しきい値は、サーバ１１０またはそのユーザにより決定することができる。例えば、時間しきい値は、サーバ１１０またはそのユーザにより決定された、プリセット値であり得る。他の例として、時間しきい値は、異なる都市、異なる地区、異なるエリア、異なる時間、等またはそれらの任意の組み合わせのような、異なるアプリケーションシナリオに従って決定することができる。それゆえ、サーバ１１０（例えば、プロセッサ２２０、記録モジュール４１４）は、ユーザ端末１２０により送信された、第１の移動オーダーを受信した後の、第１の移動オーダーの待ち時間を記録することができる。サーバ１１０は、第１の移動時間の待ち時間が、時間しきい値未満であるかどうかを、決定することができる。第１の移動オーダーの待ち時間が、時間しきい値未満でないとき、第１の移動オーダーに対応する利用可能な車両は、ユーザ端末１２０のエリア内には、少ないことを示すことができる。それゆえ、サーバ１１０は、第１の移動オーダーに対応する車両を、長い時間、ユーザ端末１２０に割り当てることができない。いくつかの実施形態において、サーバ１１０は、第１の移動オーダーに対応する車両を、第１のサービスタイプと、みなすことができる。図７に示すようにサーバ１１０は、第２のサービスタイプの応答情報の、第１のバブルプロンプトメッセージを、ユーザ端末１２０にプッシュすることができる。それに応じて、ユーザ端末１２０は、第１のバブルプロンプトメッセージを受信した後、ユーザインタフェースに、第１のバブルプロンプトメッセージを表示することができる。

図１１は、この開示のいくつかの実施形態に従って、第３のバブルプロンプトメッセージを提示する、例示プロセスを説明するフローチャートである。プロセス１１００は、オンラインからオフラインへのサービスシステム１００か、または、オンラインからオフラインへのサービスシステム１００を統合するサーバにより、実行することができる。例えば、プロセス１１００は、ストレージＲＯＭ２３０またはＲＡＭ２４０に記憶された命令のセット（例えば、アプリケーション）として、インプリメントすることができる。プロセッサ２２０は、命令のセットを実行することができ、命令を実行すると、プロセス１１００を実行するように構成することができる。下記に提示した、説明されたプロセスの動作は、例示を意図している。いくつかの実施形態において、プロセス１１００は、記載されていない、および／または上述した動作の、１つまたは複数無しに、達成することができる。さらに、図１１に説明され、下記に記載されるプロセスの動作は限定することを意図していない。

プロセス１１００は、ユーザ端末１２０から、第１の移動オーダーを取得することに応答して、サーバ１１０は、第１の移動オーダーに対応する乗物情報を含む、第３のバブルプロンプトメッセージを、ユーザ端末１２０にプッシュすることができる。

１１１０において、サーバ１１０（例えば、プロセッサ２２０、割り当てモジュール４１５）は、第１の移動オーダーに基づいて、車両をユーザ端末１２０に割り当てることができる。

いくつかの実施形態において、サーバ１１０は、ユーザをピックアップすることができ、第１の移動オーダーと同じサービスタイプのユーザ端末１２０に最も近い車両を、ユーザ端末１２０（またはユーザの開始ロケーション）に基づいて、ユーザ端末１２０に割り当てることができる。

１１２０において、サーバ１１０（例えば、プロセッサ２２０、プッシュモジュール４１３）は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェースに提示された、第３のバブルプロンプトメッセージを送信することができる。いくつかの実施形態において、第３のバブルプロンプトメッセージは、割当てられた車両に関する情報を含むことができる。

いくつかの実施形態において、割当てられた車両に関する情報は、割当てられた車両の色、割当てられた車両のプレート番号、割当てられた車両の車両タイプ、等またはそれらの任意の組み合わせを含むことができる。いくつかの実施形態において、割当てられた車両に関する情報はさらに、割当てられた車両の運転者名、割当てられた車両の運転者名、割当てられた車両が、ユーザ端末１２０のロケーション（またはユーザの開始ロケーション）に到着するのにかかる待ち時間、等、またはそれらの任意の組み合わせを含むことができる。

いくつかの実施形態において、ユーザ端末１２０は、割り当てられた車両に関する情報を、バブルのフォーマットで表示することができる。ユーザは、カーヘイリングアプリケーションを使用するとき、バブルにフォーカスすることができる。それゆえ、ユーザは、割当てられた乗り物（また、ユーザをピックアップする乗物を指す）に関する情報をタイムリーに獲得することができる。ユーザ経験は改善される。

図１２は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。図１２に示すように、ユーザ端末１２０が、エクスプレスサービスを呼び出しするための、第１の移動オーダーをサーバ１１０に送信した後で、サーバ１１０は、ユーザ端末に関するエクスプレスを割り当てることができる。ユーザ端末１２０は、ユーザインタフェースの下部に、エクスプレスの部分情報を表示することができる。例えば、ユーザ端末１２０は、ユーザインタフェースの下部に、エクスプレスのプレート番号を表示することができる。

ユーザは、図１２に説明されたユーザインタフェースを介して、エクスプレスの全ての情報を、取得することができない。ユーザが、エクスプレスについて、さらに学習する必要があるとき、ユーザは、さらなる情報を取得するために、さらに動作しなければならない。ユーザ経験は貧弱である。

図１３は、この開示のいくつかの実施形態に従う、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。図１３に示すように、サーバ１１０が、ユーザ端末１２０にエクスプレスを割当てた後、サーバ１１０は、エクスプレスに関する情報を含む、第３のバブルプロンプトメッセージを、ユーザ端末１２０に送信することができる。ユーザ端末１２０は、エクスプレスに関する情報を、ユーザインタフェース上に、バブルのフォーマットで表示することができる。例えば、第３のバブルプロンプトメッセージは、「黒、ホンダアコード、ＪＨ４ＭＦ６６」を含むことができる。「黒」は、エクスプレスの色であり得る。「ホンダアコード」は、エクスプレスの車両タイプであり得る。「ＪＨ４ＭＦ６６」は、エクスプレスのプレート番号であり得る。いくつかの実施形態において、第３のバブルプロンプトメッセージは、また、図１３に示す、エクスプレスの待ち時間（エクスプレスがユーザをピックアップするのにかかる時間も指す）のような、オリジナルバブルメッセージを含むこともできる。

ユーザは、ユーザ端末１２０のユーザインタフェース上に表示された、第３のバブルプロンプトメッセージを介して割り当てられた車両の、すべての情報を取得することができる。
ユーザ体験は、改善される。

図１４は、この開示のいくつかの実施形態に従う、ユーザ端末上の、アプリケーションの例示ユーザインタフェースである。図１４に示すように、カープールサービス、タクシーサービス、エクスプレスサービス、バスサービス、等、またはそれらの任意の組み合わせのような、複数のサービスタイプであり得る。いくつかの実施形態において、ユーザは、エクスプレスサービスの、ユーザインタフェース上の、エクスプレスサービスの移動オーダーを、トリガすることができる。いくつかの実施形態において、エクスプレスサービスの車両が、ユーザ端末１２０のロケーション（またはユーザの開始ロケーション）から、所定の距離内のエリア内で不十分である（エクスプレスサービスは、不足している）とき、サーバ１１０は、ユーザ端末１２０に一致しない、またはエクスプレスを割り当てることができない。いくつかの実施形態において、ユーザ端末１２０は、アプリケーションのユーザインタフェース上に、カードメッセージを表示することができる。たとえば、カードメッセージは、「あなたの車両の呼び出しが、キャンセルされました」を含むことができる。図１４に説明されたユーザインタフェースを介して、ユーザは、エクスプレスサービスが、そのエリア内で不足していることしか知ることができず、ユーザ移動を容易にする、他の情報を取得することができない。ユーザ体験は、相対的に貧弱である。

図１５は、この開示のいくつかの実施形態に従う、第３のバブルプロンプトメッセージを提示するための、例示プロセスを説明するフローチャートである。プロセス１５００は、オンラインからオフラインへのサービスシステム１００により、またはオンラインからオフラインへのサービス１００を統合するサーバによって、実行することができる。例えば、プロセス１５００は、ストレージＲＯＭ２３０またはＲＡＭ２４０に記憶された命令のセット（例えば、アプリケーション）として、インプリメントすることができる。プロセッサ２２０は、命令のセットを実行することができ、命令を実行すると、プロセス１５００を構成することができる。下記に示す説明されたプロセスの動作は、例示を意図している。いくつかの実施形態において、プロセス１５００は、記載されていない、および／または上述した動作の、１つまたは複数無しに、１つまたは複数のさらなる動作で成就することができる。さらに、図１５に説明され、下記に記載されたプロセスの動作の順番は、限定することを意図したものではない。

プロセス１５００は、ユーザ端末１２０のユーザによりトリガされた第１の移動オーダーを取得することに応答して、ユーザ端末１２０が乗り物に、割り当てられないとき、サーバ１１０が、推奨されるサービスタイプの属性情報を含むカードプロンプトメッセージをユーザ端末１２０に、プッシュすることを含む。

１５１０において、サーバ１１０（例えば、プロセッサ２２０、受信モジュール４２２）は、ユーザ端末１２０から第１の移動オーダーを取得することができる。いくつかの実施形態において、第１の移動オーダーは、ユーザ端末１２０内のオンラインからオフラインへのサービスアプリケーションのユーザインタフェース上で、ユーザによりトリガされることができる。いくつかの実施形態において、第１の移動オーダーは、ターゲットサービスタイプ、第１の移動オーダーの第１の送信時間、開始ロケーション、目的地、開始時間、ユーザ端末のロケーション、等、またはそれらの任意の組み合わせを含むことができる。いくつかの実施形態において、第１の移動オーダーの第１の送信時間は、開始時間が、第１のオーダーを送信する時点でデフォルト開始時間の場合、開始時間と同じであり得る。いくつかの実施形態において、開始ロケーションは、ユーザ端末が位置する場所においてデフォルトである場合、ユーザ端末のロケーションと同じであり得る。

いくつかの実施形態において、ユーザは、ターゲットサービスタイプに関する第１の移動オーダーをトリガするために、カーヘイリングサービスアプリケーションのターゲットサービスタイプに従って、ユーザインタフェース上のカーヘイリングボタンをクリックすることができる。いくつかの実施形態において、ユーザはまた、開始ロケーション、目的地、移動時間等、またはそれらの任意の組み合わせを入力することにより、ターゲットサービスタイプに関する第１の移動オーダーを、トリガすることができる。ユーザは、また、ターゲットサービスタイプの第１の移動オーダーをトリガする、２つの方法の組み合わせを、採用することができる。

１５２０において、第１の移動オーダーが、乗物に割り当てられないと決定することに応答して、サーバ１１０（例えば、プロセッサ２２０、送信モジュール４２１）は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェース上に提示された、カードプロンプトメッセージを送信することができる。いくつかの実施形態において、サーバ１１０（例えば、プロセッサ２２０、表示モジュール４２３）は、ユーザ端末１２０に、ユーザ端末１２０のユーザインタフェース上に、カードプロンプトメッセージを表示するように、指示することができる。いくつかの実施形態において、カードプロンプトメッセージは、推奨されたサービスタイプの属性情報を含むことができる。例えば、推奨されたサービスタイプの属性情報は、推奨されたサービスタイプ、推奨されたサービスタイプのロゴ（例えば、その名前、またはイメージ）、推奨されたサービスタイプの応答時間、等、またはそれらの任意の組み合わせを含むことができる。推奨されたサービスタイプの応答時間は、推奨されたサービスタイプの車両が、ユーザの開始ロケーションに到着するのにかかる時間（ピックアップ時間とも呼ばれる）である。

いくつかの実施形態において、サーバ１１０は、開始ロケーションに基づいて、ターゲットサービスタイプの第２の需給比率を決定することができる。たとえば、サーバ１１０は、開始ロケーションから所定の距離内に、ユーザ端末１２０のエリアを決定することができる。サーバ１１０は、エリア内のターゲットサービスタイプの第２の需給比率を決定することができる。第２の需給比率は、エリア内のユーザ端末（またはターゲットサービスタイプを要求するサービス要求者）のカウントに対する、利用可能な車両（または利用可能なサービスプロバイダ）のカウントの比率であり得る。サーバ１１０は、第２の需給比率は、第２の比率しきい値より大きいかどうかを決定することができる。第２の需給比率が、第２の比率しきい値より大きくない場合、サーバ１１０は、ターゲットサービスタイプを、ユーザ端末１２０に一致させることができない。それゆえ、サーバ１１０は、第１の移動オーダーを、車両に割り当てられないと決定することができる。いくつかの実施形態において、エリアは、ユーザ端末１２０のロケーション（または、ユーザの開始ロケーション）に中心がある円形エリア、方形エリア、六角形エリア等を含むことができる。所定の距離は、この開示において定義されない、サーバの構成に従って、決定することができる。いくつかの実施形態において、第２の比率しきい値は、サーバ１１０、またはそのユーザにより決定することができる。たとえば、第２の比率しきい値は、サーバ１１０、またはそのユーザにより決定されたプリセット値であり得る。他の例として、第２の比率しきい値は、異なる都市、異なる地区、異なるエリア、異なる時間、等、またはそれらの任意の組み合わせのような、異なるアプリケーションシナリオに従って、決定することができます。いくつかの実施形態において、第２の比率しきい値は、第１の比率しきい値と同じであり得る。あるいは、第２の比率しきい値は、第１の比率しきい値と異ならせてもよい。

いくつかの実施形態において、サーバ１１０が、ユーザ端末１２０から、第１の移動オーダーに関するキャンセル要求を取得する場合、サーバ１１０は、第１の移動オーダーが、車両に割り当てられなかったと判断することができる。いくつかの実施形態において、キャンセル要求は、カーヘイリングアプリケーションのユーザインタフェース上で、ユーザによりトリガすることができる。いくつかの実施形態において、キャンセル要求は、サーバ１１０が、ターゲットサービスタイプの車両を、ユーザ端末１２０ターゲットサービスタイプの車両を割り当てる前に、（すなわち、ターゲットサービスタイプの車両は、第１の移動オーダーを取得しない）ユーザによりトリガされた、キャンセル要求であり得る。いくつかの実施形態において、キャンセル要求は、サーバ１１０がターゲットサービスタイプの車両を、ユーザ端末１２０に割り当てた後で、ユーザによりトリガされたキャンセル要求であり得る。

いくつかの実施形態において、推奨されたサービスタイプの応答時間は、ターゲットサービスタイプの応答時間未満であり得る。例えば、推奨されたサービスタイプの利用可能な車両（または推奨されたサービスタイプの利用可能なサービスプロバイダ）は、ターゲットサービスタイプのユーザよりも早く、ユーザ端末のユーザをピックアップすることができる。いくつかの実施形態において、推奨されたサービスタイプの第３の需給比率は、ターゲットサービスタイプの第２の需給比率よりも大きくなり得る。例えば、ターゲットサービスタイプの利用可能な車両よりも、エリア内の推奨されたサービスタイプ（または推奨されたサービスタイプの利用可能なサービスプロバイダ）の、より多くの利用可能な車両があり得る。いくつかの実施形態において、推奨されたサービスタイプの推定された料金は、ターゲットサービスタイプの推定された料金未満であり得る。例えば、推奨されたサービスタイプを用いて、ユーザは、ターゲットサービスタイプを用いることよりも、コストを少なくすることができる。

図１６は、この開示のいくつかの実施形態に従うユーザ端末上のアプリケーションの例示ユーザインタフェースである。図１６に示すように、ユーザが、ユーザ端末１２０のカーヘイリングアプリケーションのユーザインタフェース上に、エクスプレスサービスに関する第１の移動オーダーをトリガした後で、第１の移動オーダーがエクスプレスに割り当てられない場合、ユーザ端末１２０は、推奨されたサービスタイプの属性情報を含む、カードプロンプメッセージを、ユーザインタフェース上に表示することができる。例えば、推奨されたサービスタイプは、バスサービスであり、表示されたカードプロンプトメッセージは、「付近のエクスプレスは少ないです。バスを試してみますか？」を含むことができる。ピックアップするのに１分。「バス」は、推奨されたサービスタイプのロゴであり得る。「１分」は、推奨されたサービスタイプ応答時間であり得る。

例えば、ユーザＡは、エクスプレスサービスのユーザインタフェース上の、エクスプレスサービスに関する第１の移動オーダーを、トリガすることができる。サーバ１１０は、ユーザ端末のエリア内の、エクスプレスサービスの第２の需給比率を決定することができる。第２の需給が、第２の比率しきい値より大きくない場合、サーバ１１０は、エリア内のエクスプレスサービスの、利用可能な車両を決定することができる。サーバ１１０は、エクスプレスを、ユーザＡに割りあてることができる。ユーザＡのユーザ端末は、「付近のエクスプレスは少ないです。ピックアップするのに１分」を含む、カードプロンプトメッセージを表示することができる。カードプロンプトメッセージは、ユーザＡが、バスサービス（推奨されたサービスタイプともいう）を選択するように、ユーザＡをガイドすることができる。目的は、ユーザの解約率を低減するように、サービスの他のタイプに、ガイドすることである。

他の例として、ユーザＢは、エクスプレスサービスのユーザインタフェース上の、エクスプレスサービスに関する第１の移動オーダーを、トリガすることができる。ユーザＢは、エクスプレスに割り当てられるまでに長い時間（エクスプレスのマッチング時間が長い）待つか、あるいは、他の移動モードを選択することにより、第１の移動オーダーを、主導的にキャンセルすることができる。ユーザＢのユーザ端末は、「近くのエクスプレスが少ない、バスを試してみますか？」を含むカードプロンプトメッセージを表示することができる。カードプロンプトメッセージは、ユーザＢが、バスサービス（推奨されたサービスタイプ）を選択するようにガイドすることができる。この目的は、ユーザが、ユーザの解約率を低減するために、他のサービスタイプを選択するようにガイドすることである。

カードプロンプトメッセージは、推奨されたサービスタイプの属性情報を、ユーザに主導的、かつ迅速に提供することができる。この目的は、ユーザの解約率を低減するために、他のタイプのサービスを選択するようにガイドすることである。これに対応して、ユーザは、また、他のサービスタイプの属性情報に基づいて、他のサービスタイプを選択するかどうかを迅速に決定することができる。ユーザの移動効率とユーザ経験が改善される。

いくつかの実施形態において、カードプロンプトメッセージは、推奨されたサービスタイプに関する、推奨された移動オーダーを、トリガするオプションを含むことができる。いくつかの実施形態において、推奨されたサービスタイプに関する、推奨された移動オーダーをトリガするオプションは、推奨されたサービスタイプをトリガする操作ボタン、推奨されたサービスタイプのユーザインタフェースへのリンク、推奨されたサービスタイプをトリガするリンク、等またはそれらの任意の組み合わせを含む。このようにして、ユーザが、カードプロンプトメッセージを介して推奨された、サービスタイプの属性情報を取得した後、ユーザは、カードプロンプトメッセージ上に表示されたオプションをクリックすることにより、推奨されたサービスタイプに関する、推奨された移動オーダーを迅速にトリガすることができる。ユーザの移動効率と、ユーザ経験が改善される。

いくつかの実施形態において、カードプロンプトメッセージは、推奨されたサービスタイプに関する、推奨された移動オーダーの、推定された料金、推奨されたサービスタイプに関する、推奨された移動オーダーの推定された料金と、ターゲットサービスタイプに関する第１の移動オーダーの、推定された料金との間の料金差、等、またはそれらの任意の組み合わせを含むことができる。このように、カードプロンプトメッセージは、推奨されたサービスタイプの推定された料金を、ユーザに、直観的かつ迅速に提供することができる。ユーザは、また、２つのサービスタイプ間の料金差も取得することができる。ユーザは、料金差、および推奨されたサービスタイプの、推定された料金に基づいて、推奨されたサービスタイプを選択するかどうかを決定することができる。ユーザの移動効率とユーザ経験が改善される。

いくつかの実施形態において、カードプロンプトメッセージは、推奨されたサービスタイプ、推奨されたサービスタイムの応答時間、推奨されたサービスタイプに関する推奨された移動オーダーを、トリガするオプション、推奨されたサービスタイプに関する、推奨された移動オーダーの推定された料金、推奨されたサービスタイプに関する、推奨された移動オーダーの推定された料金と、ターゲットサービスタイプに関する第１の移動オーダーの推定された料金と、の間の料金差、等、またはそれらの任意の組み合わせを含むことができる。図１７は、この開示のいくつかの実施形態に従って、ユーザ端末上のアプリケーションの例示ユーザインタフェースである。図１７に示すように、カードプロンプトメッセージは、推奨されたサービスタイプの属性情報、推奨されたサービスタイプをトリガする操作ボタン、推奨されたサービスタイプの、推奨された移動オーダーの推定された料金、および推奨されたサービスタイプの、推奨された移動オーダーの推定された料金と、ターゲットサービスタイプの、第１の移動オーダーの推定された料金と、の間の料金差を含むことができる。

図１７に示すように、「バス」は、推奨されたサービスタイプのロゴであり得る。「１分」は、推奨されたサービスタイプの応答時間であり得る。「Ｈａｉｌ」のボタンは、推奨されたサービスタイプをトリガするための操作ボタンであり得る。「￥６節約します」は、推奨されたサービスタイプに関する、推奨された移動オーダーと、ターゲットサービスタイプの推定された料金と、の間の料金差であり得る。「約￥１７」は、推奨されたサービスタイプの推定された料金であり得る。

いくつかの実施形態において、ユーザが、効率的な情報を迅速に取得することを可能にするために、カードプロンプトメッセージは、２つのエリアを含むことができる。第１のエリアは、運用広告プロンプトメッセージ、例えば、「近くのエクスプレスは少ない。バスをお試しください。ピックアップするのに１分、￥６節約になります」を含むことができる。いくつかの実施形態において、第１のエリア内の運用広告プロンプトメッセージは、強調表示することができるので、ユーザは、迅速にプロンプトメッセージを補足することができる。第２のエリアは、推奨されたサービスタイプの詳細な情報を含むことができる。例えば、第２のエリアは、第２のサービスタイプの属性、推奨されたサービスタイプ、および推奨されたサービスタイプの、推奨された移動オーダーの、推定された料金に関する操作ボタンを含むことができる。第２のエリア内の詳細な情報は、直観的にかつ迅速に推奨された、サービスタイプの関連情報を提供することができる。ユーザの移動効率とユーザ経験が改善される。

いくつかの実施形態において、カードプロンプトメッセージは、さらに推奨されたサービスタイプの車両が、目的地に到着するのにかかる合計推定時間、推奨されたサービスタイプの広告、等、またはそれらの任意の組み合わせを含むことができる。図１７に示すように、カードプロンプトメッセージは、「到着するのに３４分」および「ランダムに無料（Randomly free）」を含むことができる。ユーザは、推奨されたサービスタイプの、包括的関連情報を取得することができる。

図１７は、例示目的のためだけであることに留意する必要がある。例えば、図１７に示す、カードプロンプトメッセージ内のすべてのコンテンツのレイアウト、分配および表示は、概略に過ぎず、この開示に限定されない。例えば、カードは、下から上に飛び出してユーザインタフェース上に表示されるか、左から右に飛び出したり、右から左に飛び出したり、上から下に飛び出したり、回転で飛び出したりするような形式で、ユーザインタフェースに表示することができる。この開示は、上記カードプロンプトメッセージが、ユーザインタフェース上に表示される位置を定義しない。

いくつかの実施形態において、推奨されたサービスタイプの属性情報を含むカードプロンプトメッセージを提示するプロセスは、ユーザ端末１２０から記載することができる。あるいは、プロセスは、サーバ１１０から記載することができる。

図１８は、この開示のいくつかの実施形態に従って、ユーザ端末上に、カードプロンプトメッセージを提示するための命令を、説明するフローチャートである。図１８に示すように、命令は、ユーザ端末１２０が、第１の移動オーダーを、サーバ１１０に送信した後に、サーバ１１０が生成した命令を含むことができる。サーバが、ターゲットサービスタイプの車両を、ユーザ端末１２０に割り当てられない状況に応答して、サーバ１１０は、カードプロンプトメッセージを、ユーザ端末１２０にプッシュすることができる

１８１０において、ユーザ端末１２０は、第１の移動オーダーを、サーバ１１０に送信することができる。いくつかの実施形態において、第１の移動オーダーは、サーバ１１０に、ユーザ端末１２０のターゲットサービスタイプの車両を一致させるように指示するために、使用することができる。第１の移動オーダーは、ユーザが選択したターゲットサービスタイプのロゴ、開始ロケーション、開始時間、目的地等、またはそれらの任意の組み合わせを含むことができる。

１８２０において、サーバ１１０は、第１の移動オーダーを取得することができる。１８３０において、第１の移動オーダーが、車両に割り当てられなかったと判断することに応答して、サーバ１１０は、ユーザ端末１２０に、カードプロンプトメッセージを送信することができる。

いくつかの実施形態において、ユーザ端末１２０のユーザが、ユーザ端末１２０のユーザインタフェース上の第１の移動オーダーに関するキャンセル要求を、トリガする場合、サーバ１１０は、ユーザ端末１２０から第１の移動オーダーに関するキャンセル要求を取得する。サーバ１１０（例えば、プロセッサ２２０、処理モジュール４２４）は、第１の移動オーダーが、乗り物に割り当てられなかったと判断することができる。

いくつかの実施形態において、サーバ１１０（プロセッサ２２０、処理モジュール４２４）は、開始ロケーションに基づいて、ターゲットサービスタイプの第２の需給比率を決定することができる。例えば、サーバ１１０は、開始ロケーションから所定の距離内に、ユーザ端末１２０のエリアを決定することができる。サーバ１１０は、エリア内のターゲットサービスタイプの、第２の需給比率を決定することができる。第２の需給比率は、エリア内のユーザ端末（またはターゲットサービスタイプを要求するサービス要求者）のカウントに対する利用可能な乗物（または利用可能なサービスプロバイダ）のカウントの比率であり得る。サーバ１１０（例えば、プロセッサ２２０、処理モジュール４２４）は、第２の需給比率が、第２の比率しきい値より大きいかどうかを決定することができる。第２の需給比率が、第２の比率しきい値より大きくない場合、サーバ１１０は、ターゲットサービスタイプの車両を、ユーザ端末１２０にマッチさせることができない。それゆえ、サーバ１１０（例えば、プロセッサ２２０、処理モジュール４２４）は、第１の移動オーダーが、車両に割り当てられないと判断することができる。いくつかの実施形態において、エリアは、ユーザ端末１２０のロケーションに中心がある（またはユーザの開始ロケーション）円形エリア、方形エリア、六角形エリア等を含むことができる。所定の距離は、この開示では定義していない、サーバの構成に従って決定することができる。

いくつかの実施形態において、サーバ１１０（例えば、プロセッサ２２０、処理モジュール４２４）は、カーヘイリングアプリケーションの運用戦略に基づいて、推奨されるサービスタイプを決定することができる。例えば、推奨されるサービスタイプは、カーヘイリングアプリケーションが提供する、最新のサービスタイプである。いくつかの実施形態において、サーバ１１０は、ユーザの行動データ、またはカーヘイリングアプリケーションのユーザ端末１２０の、過去の走行履歴情報に基づいて、推奨されるサービスタイプを決定することができる。たとえば、推奨されるサービスタイプは、ユーザ端末１２０のユーザが、過去に最も頻繁に使用したサービスタイプであり得る。

いくつかの実施形態において、過去の移動情報は、ユーザ端末１２０の過去の移動時間、ユーザ端末１２０の過去の開始情報、ユーザ端末１２０の過去の目的地、過去のターゲットサービスタイプ、ユーザ端末１２０の過去の移動記録、等、またはそれらの任意の組み合わせを含むことができる。

いくつかの実施形態において、サーバ１１０は、ターゲットサービスタイプの需給比率よりも、大きな需給比率を有するサービスタイプを決定し、そのサービスタイプを、推奨されたサービスタイプとして割り当てることができる。例えば、ターゲットサービスタイプは、エキスプレスサービスタイプである。サーバ１１０は、ユーザ端末１２０のエリア内のプライベートカーサービスの需給比率Tは、ユーザ端末１２０の開始ロケーションに基づいたエクスプレスサービスの需給比率より大きいと決定することができる。プライベートカーサービスは、ユーザ端末に推奨される、推奨されたサービスタイプとして割り当てることができる。

いくつかの実施形態において、サーバ１１０は、開始ロケーションに到着するための対応する距離は、ターゲットサービスタイプの対応する距離より短い、サービスタイプを決定することができ、対応するサービスタイプを、推奨されたサービスタイプとして割り当てることができる。いくつかの実施形態において、サーバ１１０は、応答時間が、ターゲットサービスタイプの応答時間より短いサービスタイプを、決定することができ、対応するサービスタイプを、推奨されたサービスタイプとして割り当てることができる。例えば、ターゲットサービスタイプは、エクスプレスサービスである。サーバ１１０は、ユーザ端末１２０のエリア内の、複数のサービスタイプの複数の車両の位置情報を取得することができる。サーバ１１０は、エリア内の最も近いエクスプレスよりも、ユーザ端末１２０に近いプライベートカーがあると決定する場合、サーバ１１０は、プライベートカーサービスを、ユーザ端末１２０に推奨するための推奨されたサービスタイプとして割り当てることができる。

いくつかの実施形態において、サーバ１１０は、開始ロケーション、目的地、および開始時間に基づいて、エリア内の複数のサービスタイプの中で、対応する推定料金が最も少ないサービスタイプを決定することができる。サーバ１１０は、決定されたサービスタイプを、推奨されるサービスタイプとして、割り当てることができる。例えば、ターゲットサービスタイプは、エクスプレスサービスである。サーバ１１０は、エリア内のタクシーサービスの推定料金が、エクスプレスサービスの推定料金未満であると決定することができる。サーバ１１０は、タクシーサービスを、ユーザ端末１２０へ推奨するための、推奨されたサービスタイプとして割り当てることができる。

いくつかの実施形態において、サーバ１１０は、ユーザの移動の好みを決定することができる。サーバ１１０は、移動の好みに基づいて、サービスタイプを決定することができる。例えば、ターゲットサービスタイプは、エクスプレスサービスである。サーバ１１０は、ユーザ端末１２０の過去の移動情報に基づいて、ユーザが、バスサービスのような、経済的で迅速なサービスタイプを用いて移動することを、意図しているかもしれないと判断することができる。サーバ１１０は、バスサービスを、ユーザ端末１２０に推奨するための、推奨されたサービスタイプとして割り当てることができる。１８４０で、ユーザ端末１２０は、カードプロンプトメッセージを取得することができる。

ユーザは、ユーザ端末１２０のユーザインタフェース上に表示された、カードプロンプトメッセージを介して、他のサービスタイプの属性情報を取得することができる。目的は、ユーザの解約率を低減するために、サービスの他のタイプを選択するようにガイドすることである。さらに、ユーザは、属性情報に基づいて、他のサービスタイプを選択するかどうかを決定することができる。ユーザの移動効率と移動経験が改善される。

以上、基本的概念を述べたが、当業者には、この詳細な記述を読んだ後で、上述の開示は、例示による提示に過ぎないことを意図したものであり、限定するものではないことが明らかであろう。ここには明示的に記載していないけれども、種々の変更、改良、および変形を生じさせることができ、当業者に意図されている。これらの変更、改善、および変形は、この開示により示唆されることが意図され、この開示の例示実施形態の精神と範囲内である。

さらに、この開示の実施形態を記載するために、ある用語が使用されている。例えば、用語「一実施形態（one embodiment）」、「一実施形態（an embodiment）」、および／または「いくつかの実施形態（some embodiments）」は、実施形態に関連して記載した特定の特徴、構造または特性は、この開示の少なくとも１つの実施形態に含まれることを意味する。それゆえ、この明細書の種々の部分の「一実施形態（an embodiment）」、「一実施形態（one embodiment）」、または「代替実施形態（an alternative embodiment）」への１つ以上の参照は、必ずしもすべての同じ実施形態を参照するわけではない。さらに、特定の特徴、構造、または特性は、この開示の、１つまたは複数の実施形態に適切なものとして組み合わせることができる。

さらに、当業者には、この開示の態様は、本明細書において、新規かつ有用なプロセス、機械、製造、または組成物を含む、多くの特許性のあるクラス、または文脈のいずれかで例示、および説明され得ることを理解されたい。従って、この開示の態様は、全体がハードウェアでインプリメントすることができ、全体が（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）ソフトウェアでインプリメントすることができ、または、ここでは、一般的に「ブロック」、「モジュール」、「ユニット」、「コンポーネント」または「システム」と呼ぶことができる、ソフトウェアとハードウェアのインプリメンテーションの組み合わせでインプリメントすることができる。さらに、この開示の態様は、コンピュータ読出し可能プログラムコードが、その中に具現化される、１つまたは複数のコンピュータ可読媒体に具現化されたコンピュータプログラムプロダクトの形態をとることができる。

コンピュータ可読信号媒体は、例えば、ベースバンドに、または搬送波の一部として、その中に具現化されたコンピュータ可読プログラムコードを備えた伝搬データ信号を含むことができる。そのような伝搬信号は、電磁気、光学等、またはそれらの任意の組み合わせを含む、種々の形態のいずれかを採用することができる。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、命令実行システム、装置、またはデバイスによって、または関連して使用するプログラムを通信し、伝搬し、または輸送することができる、任意のコンピュータ可読媒体であり得る。コンピュータ可読信号媒体上で具現化されたプログラムコードは、無線、有線、光ファイバケーブル、ＲＦ等またはそれらの任意の組み合わせを含む任意の適当な媒体を用いて送信することができる。

この開示の態様に関して動作を実行するコンピュータプログラムコードは、Ｊａｖａ、Ｓｃａｌａ、Ｓｍａｌｌｔａｌｋ、Ｅｉｆｆｅｌ、ＪＡＤＥ、Ｅｍｅｒａｌｄ、Ｃ＋＋、Ｃ＃、ＶＢ、ＮＥＴ、Ｐｙｔｈｏｎ等、のようなオブジェクト指向プログラミング言語、「Ｃ」プログラミング言語、Ｖｉｓｕｌａ Ｂａｓｉｃ、Ｆｏｒｔｒａｎ １７０３、Ｐｅｒｌ、ＣＯＢＯＬ １７０２、ＰＨＰ、ＡＢＡＰのような、汎用手続プログラミング言語、Ｐｙｔｈｏｎ、Ｒｕｂｙ ａｎｄ Ｇｒｏｏｖｙのような、ダイナミックプログラミング言語または他のプログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで書くことができる。プログラムコードは、ユーザのコンピュータで全体的に、スタンドアロンソフトウエアパッケージとして、ユーザのコンピュータで部分的に、一部をユーザのコンピュータで、一部をリモートコンピュータで、または全体をリモートコンピュータまたはサーバで実行することができる。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を含む、任意のネットワークを介して接続することができ、または接続は、外部コンピュータ（例えば、インターネットサービスプロバイダを用いたインターネットを介して）またはクラウドコンピューティング環境またはＳｅｒｖｉｃｅ ａｓ ａ Ｓｏｆｔｗｅａｒ（ＳａａＳ）のようなサービスとして提供される。

さらに、エレメントまたはシーケンスを処理する、記載した順番、または番号、文字または他の指示の使用は、特許請求の範囲に記載したプロセスおよび方法を、特許請求の範囲で特定した順番を除いて、任意の順番に限定することを意図したものではない。上記開示は、現在考えられる、この開示の種々の有効な実施形態である、種々の例を介して記載したけれども、そのような詳細は、その目的のためだけであり、添付した特許請求の範囲は、開示された実施形態に限定されず、反対に、開示された実施形態の精神と範囲内にある変形例および等価な構成を、カバーすることを意図している。たとえば、上述した種々のコンポーネントのインプリメンテーションは、ハードウエアデバイスで具現化されるけれども、ソフトウェアのみのソリューション、例えば、既存のサーバまたは、モバイルデバイス上のインストールとしてインプリメントすることができる、

同様に、この開示の実施形態の上述の記述において、種々の実施形態の、１つまたは複数への理解を支援する開示を簡素化する目的で、種々の特徴が、時として、単一の実施形態、図、またはそれらの記述において、一緒にグループ化されることを理解されたい。しかしながら、この開示の方法は、特許請求の範囲に記載した主題が、各請求項に明示的に記載した、より多くの特徴を必要とする意図を反映するものとして解釈されない。むしろ、特許請求の範囲に記載した主題は、単一の、上記開示した実施形態の全特徴未満に存在することができる。

いくつかの実施形態において、出願の、ある実施形態を記載し、請求するのに使用される量または特性表す数は、用語「約（about）」、「およそ（approximate）」、または「実質的に」によりいくつかのインスタンスに変更されるものとして理解されたい。例えば、「約（about）」、「およそ（approximate）」、または「実質的に（substantially）」は、そうでないと記載しない限り、記載した値の±２０％の変更を示すことができる。したがって、いくつかの実施形態において、明細書および添付した特許請求の範囲で述べた数値パラメータは、特定の実施形態により、取得しようとする所望の特性に応じて、変化することができる近似値である。いくつかの実施形態において、数値パラメータは、報告された有効数字の数を考慮して、通常の丸め手法を適用することにより、解釈されるべきである。本出願のいくつかの実施形態の広い範囲を示す数値範囲、およびパラメータ近似値であるにもかかわらず、特定の例に示される数値は、実行可能な限り正確に報告されている。

特許、特許出願、特許出願の出版物、および記事、書籍、仕様書、出版物、文書、物などの、その他の資料のそれぞれは、関連する検索ファイルの履歴、現在の文書と一致しない、または相容れないもの、または、現在または今後関連する請求の最も広い範囲に関して、制限的な影響を与える可能性のある、現在のドキュメントすべての目的の全体において、参照により、その全体が本明細書に組み込まれる。例として、説明、定義、および／または組み込まれた資料のいずれかに関連する用語の使用と、本文書、説明、定義、および／または関連する用語の使用との間に不一致、または相容れない場合、本書での用語の使用が優先するものとする。

最後に、本明細書で開示される、本出願の実施形態は、本出願の実施形態の原理を例示するものであることを理解されたい。採用され得る他の変更は、この出願の範囲内である。従って、限定ではなく、例として、出願の実施形態の代替構成は、ここの教示に従って、利用することができる。従って、この出願の実施形態は、図示し、説明されたものの通りに限定されない。

Claims (15)

1. ユーザ端末において、オンラインからオフラインへのサービス出願のユーザインタフェースに、プロンプトメッセージを提示するように構成されたシステムにおいて、前記システムは、
   ユーザ端末において、オンラインからオフラインへのサービスアプリケーションについてのプロンプトメッセージを提示する命令のセットを含む、少なくとも１つのストレージ媒体と、
   前記ストレージ媒体と通信している少なくとも１つのプロセッサとを備え、前記命令のセットを実行すると、前記少なくとも１つのプロセッサは、
   ユーザ端末から、第１のサービスタイプのサービス要求を取得することであって、前記サービス要求は、前記ユーザ端末のロケーションを含む、取得することと、
   前記ユーザ端末の前記ロケーションに基づいて、前記第１のサービスタイプの第１の需給比率を決定することと、
   前記第１の需給比率が、第１の比率しきい値より大きいかどうかを判断することと、
   前記第１の需給比率が、前記第１の比率しきい値より大きくないと判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェース上に提示された、第１のバブルプロンプトメッセージを送信することであって、前記第１のバブルプロンプトメッセージは、第２のサービスタイプと、前記第２のサービスタイプの応答時間を含む、送信することと、
   を実行するように指示される、システム。
2. 前記第１のバブルプロンプトメッセージは、さらに、前記第２のサービスタイプを表示するユーザインタフェースへのリンク、または、前記第１のサービスタイプの、前記第１の需給比率の表示を含む、請求項１に記載のシステム。
3. 前記第２のサービスタイプは、前記ユーザ端末の前記ロケーションに関連する複数のサービスタイプの中で、最大の需給比率を有する、請求項１または２に記載のシステム。
4. 前記少なくとも１つのプロセッサは、さらに、
   前記ユーザ端末から、第１の移動オーダーを取得することであって、前記第１の移動オーダーは、ターゲットサービスタイプと、前記第１の移動オーダーの第１の送信時間を含む、取得することと、
   前記ターゲットサービスタイプの未割当のオーダーキューにおいて、少なくとも１つの第２の移動オーダーを取得することであって、各第２の移動オーダーは、前記第２の移動オーダーの第２の送信時間を含む、取得することと、
   前記第１の送信時間と、前記少なくとも１つの第２の送信時間に基づいて、前記第１の移動オーダーのキュー番号と待ち時間を決定することと、
   前記ユーザ端末に、前記ユーザ端末の前記ユーザインタフェース上に提示された、第２のバブルプロンプトメッセージを送信することであって、前記第２のバブルプロンプトメッセージは、前記第１の移動オーダーのキュー番号と、待ち時間を含む、送信することとを、実行するように指示される、請求項１乃至３のいずれか一項に記載のシステム。
5. 前記少なくとも１つのプロセッサは、さらに、
   前記第１の移動オーダーの前記待ち時間が、時間しきい値未満であるかどうかを判断し、
   前記第１の移動オーダーの前記待ち時間が、前記時間しきい値未満ではないと判断することに応答して、前記ユーザ端末に、前記ユーザ端末の、前記ユーザインタフェース上に提示された、前記第１のバブルプロンプトメッセージを送信するようにさらに指示される、請求項４に記載のシステム。
6. 前記少なくとも１つのプロセッサは、さらに、
   前記第１の移動オーダーに基づいて、前記ユーザ端末に乗物を割り当てることと、
   前記ユーザ端末に、前記ユーザ端末の前記ユーザインタフェース上に提示された、第３のバブルプロンプトメッセージを送信することであって、前記第３のバブルプロンプトメッセージは、前記割り当てられた乗り物に関する情報を含む、送信することと、を実行するように指示される、請求項４に記載のシステム。
7. 前記第３のバブルプロンプトメッセージは、
   前記割り当てられた乗り物の色、前記割り当てられた乗り物のプレート番号、または、前記割り当てられた乗り物の乗り物タイプの少なくとも１つを含む、請求項６のシステム。
8. 前記少なくとも１つのプロセッサは、さらに、
   前記ユーザ端末から、第１の移動オーダーを取得することであって、前記第１の移動オーダーは、ターゲットサービスタイプと、開始ロケーションを含み、前記ユーザ端末内の、前記オンラインからオフラインへのサービスアプリケーションの、前記ユーザインタフェース上のユーザにより、トリガされる、取得することと、
   前記第１の移動オーダーは、乗り物に割り当てられないと決定することと、
   前記ユーザ端末に、前記ユーザ端末の、前記ユーザインタフェースに提示されたカードプロンプトメッセージを、送信することであって、前記カードプロンプトメッセージは、推奨されるサービスタイプと、前記推奨されたサービスタイプの応答時間を含む、送信することと、を実行するように指示される、請求項１乃至３のいずれか一項に記載のシステム。
9. 前記カードプロンプトメッセージは、さらに、
   前記推奨されたサービスタイプに関する、推奨された移動オーダーをトリガするオプションと、前記推奨されたサービスタイプに関する、前記推奨された移動オーダーの推定された料金と、または、前記推奨されたサービスタイプに関する、前記推奨された、推定された料金と、前記ターゲットサービスタイプに関する、前記第１の移動オーダーの前記推定された料金との間の料金差、の少なくとも１つを含む、請求項８に記載のシステム。
10. 前記第１の移動オーダーは、開始ロケーションを含み、前記第１の移動オーダーは、乗り物に割り当てられないと決定するために、前記少なくとも１つのプロセッサは、さらに、
    前記開始ロケーションに基づいて、前記ターゲットサービスタイプの第２の需給比率を決定し、
    前記第２の需給比率が、第２の比率しきい値より大きいかどうか判断し、
    前記第２の需給比率が、前記第２の比率しきい値より大きくないと判断することに応答して、前記第１の移動オーダーは、乗り物に割り当てられないと判断する、ように指示される、請求項８または９に記載のシステム。
11. 前記第１の移動オーダーが乗り物に割り当てられないと判断するために、前記少なくとも１つのプロセッサは、さらに、
    前記ユーザ端末から、前記第１の移動オーダーのキャンセル要求を取得し、
    前記第１の移動オーダーが、乗り物に割り当てられないと判断する、ように指示される、請求項８乃至１０のいずれか一項に記載のシステム。
12. 前記第１の移動オーダーは、
    開始時間、開始ロケーション、目的地、または前記ユーザ端末の過去の移動情報の少なくとも１つを含む、請求項８乃至１１のいずれか一項に記載のシステム。
13. ユーザ端末内において、オンラインからオフラインへのサービスアプリケーションのユーザインタフェース上にプロンプトメッセージを提示する方法において、
    ユーザ端末から、第１のサービスタイプに関するサービス要求を取得するステップであって、前記サービス要求は、前記ユーザ端末のロケーションを含む、取得するステップと、
    前記ユーザ端末のロケーションに基づいて、前記第１のサービスタイプの第１の需給比率を決定するステップと、
    前記第１の需給比率が、第１の比率しきい値より大きいかどうかを判断するステップと、
    前記第１の需給比率が、前記第１の比率しきい値より大きくないと判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェースに提示された第１のバブルプロンプトメッセージを、送信するステップであって、前記第１のバブルプロンプトメッセージは、第２のサービスタイプと、前記第２のサービスタイプの応答時間を含む、送信するステップと、を備えた、方法。
14. ユーザ端末において、オンラインからオフラインへのサービスアプリケーションの、ユーザインタフェース上にプロンプトメッセージを提示するための少なくとも１つの命令のセットを備え、コンピューティングデバイスの少なくとも１つのプロセッサにより実行されると、前記少なくとも命令のセットは、前記少なくとも１つのプロセッサに、
    ユーザ端末から、第１のサービスタイプに関するサービス要求を取得することであって、前記サービス要求は、前記ユーザ端末のロケーションを含む、取得することと、
    前記ユーザ端末の前記ロケーションに基づいて、前記第１のサービスタイプの第１の需給比率を決定することと、
    前記第１の需給比率は、第１の比率しきい値より大きいと判断することと、
    前記第１の需給比率が、前記第１の比率しきい値より大きくないと判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェースに提示された、第１のバブルプロンプトメッセージを送信することであって、前記第１のバブルプロンプトメッセージは、第２のサービスタイプと、前記第２のサービスタイプの応答時間を含む、送信することと、
    を実行するように指示する、非一時的コンピュータ可読媒体。
15. オンラインからオフラインへのサービスアプリケーションの、ユーザインタフェース上にプロンプトメッセージを提示するように構成されたシステムであって、
    ユーザ端末から、第１のサービスタイプに関するサービス要求を取得するように構成された受信モジュールと、
    前記ユーザ端末のロケーションに基づいて、前記第１のサービスタイプの、第１の需給比率を決定し、前記第１の需給比率が、第１の比率しきい値より大きいかどうかを判断するモジュールと、
    前記第１の需給比率が、前記第１の比率しきい値より大きくないと判断することに応答して、前記ユーザ端末に、前記ユーザ端末のユーザインタフェース上に提示された、第１のバブルプロンプトメッセージを、送信するように構成されたプッシュモジュールであって、前記第１のバブルプロンプトメッセージは、第２のサービスタイプと、前記第２のサービスタイプの応答時間を含む、プッシュモジュールと、
    を備えた、システム。

Images