特許 6797944 注文振り分け装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6797944

(24)【登録日】2020年11月20日

(45)【発行日】2020年12月9日

(54)【発明の名称】注文振り分け装置及び方法

(51)【国際特許分類】

   G06Q 10/06 20120101AFI20201130BHJP

   G06Q 50/30 20120101ALI20201130BHJP

   G08G 1/123 20060101ALI20201130BHJP

【ＦＩ】

   G06Q10/06 302

   G06Q50/30

   G08G1/123 A

【請求項の数】14

【全頁数】18

(21)【出願番号】特願2018-567922(P2018-567922)

(86)(22)【出願日】2017年9月14日

(65)【公表番号】特表2019-530042(P2019-530042A)

(43)【公表日】2019年10月17日

(86)【国際出願番号】CN2017101776

(87)【国際公開番号】WO2018076951

(87)【国際公開日】20180503

【審査請求日】2019年2月20日

(31)【優先権主張番号】201610930788.5

(32)【優先日】2016年10月31日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】516317573

【氏名又は名称】ベイジン ディディ インフィニティ テクノロジー アンド ディベロップメント カンパニー リミティッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】リコン・ソン

【審査官】 山崎 誠也

(56)【参考文献】

【文献】 特開２０１１−０６６５８１（ＪＰ，Ａ）

【文献】 特開２００４−１６４６１５（ＪＰ，Ａ）

【文献】 特開２００５−０７０８６５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１６／００２７３０７（ＵＳ，Ａ１）

【文献】 国際公開第２０１６／０１７９２１（ＷＯ，Ａ１）

【文献】 中国特許出願公開第１０３０２１１６７（ＣＮ，Ａ）

【文献】 中国特許出願公開第１０５１６００２１（ＣＮ，Ａ）

【文献】 中国特許出願公開第１０３９８５２４７（ＣＮ，Ａ）

【文献】 中国特許出願公開第１０５０９５３７３（ＣＮ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−９９／００

Ｇ０８Ｇ １／１２３

(57)【特許請求の範囲】

【請求項1】

予め設定されたイベントを検出したとき、前記予め設定されたイベントの影響エリアを決定することと、
前記予め設定されたイベントの前記影響エリアに基づいて、予め設定された注文振り分け（ＰＯＤ）モードで、振り分けられる注文と受注ユーザとを決定することと、
前記影響エリアにおいて、受注ユーザ及び注文生成ユーザに問い合わせを送信することと、
前記ＰＯＤモードで、前記受注ユーザとして、前記問い合わせを確認した受注ユーザを決定することと、
前記ＰＯＤモードで、前記注文として、前記問い合わせを確認した注文生成ユーザからの注文を決定することと、
前記ＰＯＤモードで、前記受注ユーザのサービスエリアを決定することと、
前記受注ユーザの前記サービスエリアに基づいて前記振り分けられる注文から対象注文を決定することと、
前記対象注文を前記受注ユーザにプッシュすることとを含む、注文振り分け方法。

【請求項2】

前記受注ユーザの現在の位置を取得することと、
前記受注ユーザが現在位置している地域を決定することと、
第１のエリアとして設定される、前記地域のサービスエリアを決定することと、
前記第１のエリア内で前記受注ユーザの前記サービスエリアを決定することとをさらに含む、請求項１に記載の方法。

【請求項3】

予め設定された注文振り分け（ＰＯＤ）モードで、受注ユーザのサービスエリアを決定するように構成された第１の決定ユニットと、
受注ユーザの前記サービスエリアに基づいて振り分けられる注文から対象注文を決定するように構成された取得ユニットと、
前記対象注文を前記受注ユーザにプッシュするように構成されたプッシュユニットと、
予め設定されたイベントを検出したとき、前記予め設定されたイベントの影響エリアを決定するように構成された第２の決定ユニットと、
前記予め設定されたイベントの前記影響エリアに基づいて、前記ＰＯＤモードで、前記振り分けられる注文と前記受注ユーザとを決定するように構成された第３の決定ユニットとを含み、
前記第３の決定ユニットは、さらに、
前記影響エリアにおいて、受注ユーザ及び注文生成ユーザに問い合わせを送信し、
前記ＰＯＤモードで、前記受注ユーザとして、前記問い合わせを確認した受注ユーザを決定し、
前記ＰＯＤモードで、前記注文として、前記問い合わせを確認した注文生成ユーザからの注文を決定するように構成される、注文振り分け装置。

【請求項4】

前記第１の決定ユニットは、さらに、
前記受注ユーザの現在の位置を取得するように構成された第１の取得サブユニットと、
前記受注ユーザが現在位置している地域を決定するように構成された決定サブユニットと、
第１のエリアとして設定される、前記地域のサービスエリアを取得するように構成された第２の取得サブユニットと、
前記第１のエリア内で前記受注ユーザの前記サービスエリアを取得するように構成された第３の取得サブユニットとを含む、請求項３に記載の装置。

【請求項5】

前記第２の取得サブユニットは、さらに、
前記地域内の所定の期間内の完了した注文のデータである履歴注文データを取得し、
前記完了した注文に使用された経路を取得し、
第１の閾値回数を超えて使用された経路を第１の基準経路として設定し、
前記第１の基準経路に基づいて、前記地域の前記サービスエリアを決定するように構成される、請求項４に記載の装置。

【請求項6】

前記第２の取得サブユニットは、さらに、
所定の期間内に前記地域内で生成された注文データを取得し、
前記生成された注文に使用された経路を取得し、
第２の閾値回数を超えて使用された経路を第２の基準経路として設定し、
前記第２の基準経路に基づいて、前記地域の前記サービスエリアを決定するように構成される、請求項４に記載の装置。

【請求項7】

前記第３の取得サブユニットは、さらに、
前記受注ユーザが現在位置している前記位置をカバーする前記第１のエリア内で、第２のエリアとして設定されるエリアを取得し、
前記第２のエリアを前記受注ユーザの前記サービスエリアとして決定するように構成される、請求項４から６のいずれか一項に記載の装置。

【請求項8】

前記第３の取得サブユニットは、さらに、
前記受注ユーザが現在位置している前記位置をカバーする前記第１のエリア内で、１つ以上のエリアを第２のエリアとして取得し、
前記第２のエリアを前記受注ユーザに選択のために出力し、
前記選択された第２のエリアを前記受注ユーザの前記サービスエリアとして決定するように構成される、請求項４から６のいずれか一項に記載の装置。

【請求項9】

前記第３の取得サブユニットは、さらに、
前記受注ユーザが現在位置している前記位置をカバーする前記第１のエリア内で、１つ以上のエリアを取得し、
各第２のエリア内の注文要求を取得し、
注文要求の数が最も多い前記第２のエリアを前記受注ユーザの前記サービスエリアとして決定するように構成される、請求項４から６のいずれか一項に記載の装置。

【請求項10】

前記取得ユニットは、
各注文の始点及び終点を取得するように構成された始点及び終点取得サブユニットと、
始点及び終点が前記受注ユーザの前記サービスエリアにおいて含まれる注文を前記対象注文として決定するように構成された振り分けサブユニットとを含む、請求項３から９のいずれか一項に記載の装置。

【請求項11】

前記受注ユーザが現在位置している地域の前記サービスエリアの関連情報を出力するように構成された出力ユニットをさらに含み、前記関連情報は、前記地域の前記サービスエリア内の注文情報を含む、請求項３から１０のいずれか一項に記載の装置。

【請求項12】

前記予め設定されたイベントは、予め設定された気象タイプイベント又は交通渋滞を含む、請求項３から１１のいずれか一項に記載の装置。

【請求項13】

注文振り分けのための非一時的なコンピュータ可読媒体であって、その中に記憶された命令を含み、前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
予め設定されたイベントを検出したとき、前記予め設定されたイベントの影響エリアを決定することと、
前記予め設定されたイベントの前記影響エリアに基づいて、予め設定された注文振り分け（ＰＯＤ）モードで、振り分けられる注文と受注ユーザとを決定することと、
前記影響エリアにおいて、受注ユーザ及び注文生成ユーザに問い合わせを送信することと、
前記ＰＯＤモードで、前記受注ユーザとして、前記問い合わせを確認した受注ユーザを決定することと、
前記ＰＯＤモードで、前記注文として、前記問い合わせを確認した注文生成ユーザからの注文を決定することと、
前記ＰＯＤモードで、前記受注ユーザのサービスエリアを決定することと、
前記受注ユーザの前記サービスエリアに基づいて前記振り分けられる注文から対象注文を決定することと、
前記対象注文を前記受注ユーザにプッシュすることとを含む方法を実行させる、注文振り分けのための非一時的なコンピュータ可読媒体。

【請求項14】

前記注文振り分けのための非一時的なコンピュータ可読媒体は、その中に記憶された命令を含み、前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
前記受注ユーザの現在の位置を取得することと、
前記受注ユーザが現在位置している地域を決定することと、
第１のエリアとして設定される、前記地域のサービスエリアを決定することと、
前記ＰＯＤモードで、前記第１のエリア内で前記受注ユーザの前記サービスエリアを決定することとを含む方法を実行させる、請求項１３に記載の注文振り分けのための非一時的なコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０１６年１０月３１日に出願された中国特許出願第２０１６１０９３０７８８．５号に基づく優先権を主張するものであり、その全ての内容は参照により本明細書に組み込まれる。

【0002】

本開示は、概して、コンピュータ技術に関し、特に、注文振り分け方法及び装置に関する。

【背景技術】

【0003】

一般に、特別なタイプの気象（吹雪、竜巻、暴風雨など）、主要な休日、大規模な社会的イベントなどの特定のイベントの発生は、通常、交通渋滞を伴う。そのような場合、出掛けることは非常に不便になり、いくつかのＯ２Ｏ（オンラインツーオフライン）サービス（例えば、タクシーの予約、配達など）に対する需要は劇的に増加する可能性がある。また、交通渋滞により、これらのＯ２Ｏサービスの効率が影響を受ける可能性がある。通常どおりに注文振り分け方法に従って注文を振り分けると、サービス需要が大きいエリアでは、サービスリソースを最適化できない可能性がある。その結果、サービスリソースが無駄になり、サービス効率が低下する。

【発明の概要】

【課題を解決するための手段】

【0004】

特定のイベントでの注文振り分けを最適化し、サービスリソースの無駄を減らし、サービス効率を改善するために、本開示は、予め設定された注文振り分けモードで注文を振り分ける方法及び装置を提供する。

【0005】

本開示の一態様は、注文方法に関する。該方法は、予め設定された注文振り分けモードで、受注ユーザのサービスエリアを決定することと、受注ユーザのサービスエリアに基づいて振り分けられる注文から対象注文を決定することと、対象注文を受注ユーザにプッシュすることとを含み得る。

【0006】

本開示の別の態様は、注文振り分け装置に関する。該装置は、第１の決定ユニット、取得ユニット及びプッシュユニットを含み得る。第１の決定ユニットは、受注ユーザのサービスエリアを決定するように構成することができる。取得ユニットは、予めに設定された注文振り分けモードで、受注ユーザのサービスエリアに基づいて振り分けられる注文から対象注文を決定するように構成することができる。プッシュユニットは、対象注文を受注ユーザにプッシュするように構成することができる。

【0007】

本開示の別の態様は、注文振り分けのための非一時的なコンピュータ可読媒体に関する。非一時的なコンピュータ可読媒体は、その中に記憶された命令を含み得る。該命令は、１つ以上のプロセッサによって実行されると、１つ以上プロセッサに注文振り分け方法を実行させることができる。該方法は、予め設定された注文振り分けモードで、受注ユーザのサービスエリアを決定することと、受注ユーザのサービスエリアに基づいて振り分けられる注文から対象注文を決定することと、対象注文を受注ユーザにプッシュすることとを含み得る。

【0008】

前述の一般的な説明及び以下の詳細な説明は、例示的かつ説明的なものに過ぎず、特許請求の範囲に記載の本発明を限定するものではないことを理解すべきである。

【0009】

本開示の一部を構成する添付の図面は、いくつかの非限定的な実施形態を示し、説明と共に、開示される原理を説明するのに役立つ。

【図面の簡単な説明】

【0010】

【図1】本開示の例示的な実施形態と一致する注文振り分けの例示的なシナリオを示すグラフである。

【図2】本開示の例示的な実施形態と一致するＰＯＤモードでの注文振り分け方法を示すフローチャートである。

【図3】本開示の例示的な実施形態と一致するＰＯＤモードでの別の注文振り分け方法を示すフローチャートである。

【図4】本開示の例示的な実施形態と一致するＰＯＤモードでの別の注文振り分け方法を示すフローチャートである。

【図5】本開示の例示的な実施形態と一致する例示的なサービスエリアを示すグラフである。

【図6】本開示の例示的な実施形態と一致するＰＯＤモードでの注文振り分け装置のブロック図である。

【発明を実施するための形態】

【0011】

ここで、例示的な実施形態を詳細に参照するが、それらの例が添付の図面に例示される。以下の説明は、添付の図面を参照し、別段の記載がない限り、異なる図面における同じ番号が同じ又は同様の要素を表す。本発明と一致する例示的な実施形態の以下の説明に記載される実装形態は、本発明と一致する全ての実装形態を表すものではない。代わりに、それらは、本発明に関連する態様と一致するシステム及び方法の例に過ぎない。

【0012】

開示された原理の例及び特徴が本明細書で記載されているが、開示された実施形態の趣旨及び範囲から逸脱することなく、修正、適応及び他の実装形態が可能である。また、「含む」、「有する」、「含有する」、「包含する」という用語、及び他の同様形式は、意味が等価となるように意図されるとともに、これらの用語の任意の１つに続くアイテムまたはアイテム群がこのようなアイテムまたはアイテム群の総記であることを意味しないまたは列記されたアイテムまたはアイテム群だけに限定されることを意味しないという点で開放的であるように意図されている。本明細書及び添付の特許請求の範囲で使用されるように、単数形の用語「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈が明らかにそうでないことを示さない限り、複数の言及を含むことに留意すべきである。本明細書で使用されるように、「及び」及び「又は」という用語は、包括的又は排他的な意味で解釈され、この用語によって接続された１つ以上のアイテムのうちのいずれか又は全てを指すことができる。

【0013】

また、「第１」、「第２」、及び「第３」という用語は、１つの要素、セット、データ、対象、ステップ、プロセス、アクティビティまたは物を別のものから区別するために使用され、特に明記しない限り、相対的な位置又は時間内の配置を限定又は指定するために使用されないことを理解すべきである。例えば、「第１のエリア」というフレーズは「第２のエリア」とも呼ばれ、同様に、「第２のエリア」は「第１のエリア」とも呼ばれてもよい。文脈に基づいて、「すると」という用語は、「とき」、「そのとき」、又は「に応答して」と解釈することができる。

【0014】

図１は、本開示の例示的な実施形態に係る注文振り分けの例示的なシナリオ１００を示すグラフ図である。シナリオ１００は、１つ以上の受注端末装置１０１、１つ以上の注文生成端末装置１０２、及びサーバ１０３を含み得る。受注端末装置１０１は、受注ユーザの携帯端末であってよく、注文を受信するように構成することができる。注文生成端末装置１０２は、注文生成ユーザの携帯端末であってよく、注文を生成し送信するように構成することができる。サーバ１０３は、受注ユーザのサービスエリアを決定するように構成することができる。サービスエリアは、受注ユーザがサービスを提供できるエリアを意味する。都市、街区、又は任意の地理的地域であってよい。

【0015】

１つの実施形態では、注文生成端末装置１０２は、注文を生成してサーバ１０３に送信することができ、サーバ１０３は、受注ユーザのサービスエリアに基づいて、注文を受注端末装置１０１に振り分けることができる。別の実施形態では、受注端末装置１０１は、受注ユーザのサービスエリアを決定し、決定されたサービスエリアに基づいて、１つ以上の注文生成端末装置１０２によって生成された注文から対応する注文を取得するように構成することができる。注文振り分けの詳細な方法は、特定の実施形態を参照して説明される。

【0016】

図２は、本出願の例示的な実施形態に係る予め設定された注文振り分けモードでの注文振り分け方法２００を示すフローチャートである。方法２００は、端末（例えば、受注端末装置１０１）又はサーバ（例えば、図１中のサーバ１０３）によって実施され得る。いくつかの実施形態では、方法２００は、車両呼び出しアプリケーションがインストールされた端末装置によって実施される。当業者であれば、端末装置がスマートフォン、インテリジェントウェアラブル装置、タブレット、携帯情報端末などの携帯端末装置を含み得るが、これらに限定されないことを理解する。

【0017】

図２に示すように、ステップ２０１では、予め設定された注文振り分け（preset order distribution（ＰＯＤ））モードで受注ユーザのサービスエリアを決定する。ＰＯＤモードは、所定の方法で注文を振り分けるモードである。一般に、受注ユーザに注文を振り分ける方法は複数あり、異なるシナリオ又は条件に従って適切な注文振り分けモードを選択して、特定のシナリオ又は条件に対して注文振り分けプロセスを最適化することができる。例えば、特定のイベントが発生したとき、該イベントと一致するモードを選択して注文振り分けを最適化することができる。

【0018】

いくつかの実施形態では、受注ユーザは、注文を受信しサービスを提供するユーザである。例えば、受注ユーザは、運転者（車両呼び出し（タクシーの予約又は呼び出しを含む）のシナリオ）であっても配達員（食品配達を注文するシナリオ）などであってもよい。１つのシナリオにおける受注ユーザは、他のシナリオにおける注文生成ユーザ又は別の状態のユーザであってよく、本出願は、この態様に限定されるべきではない。

【0019】

いくつかの実施形態では、受注ユーザのサービスエリアは、受注ユーザによってサービスを提供するエリアである。サービスエリアは、都市、街区、又は任意の地理的エリアであってよく、サービスが提供され得る始点及び終点を含み得る。いくつかの実施形態では、特定の期間内に、地理的エリアは１つ以上のサービスエリアを含み得る。この地理的エリア内の任意の特定の受注ユーザのサービスエリアは、受注ユーザの物理的位置によって決定され得る。具体的には、まず、受注ユーザの物理的位置の情報を取得し、次に、受注ユーザが所在する地理的エリアを決定することができる。そして、受注ユーザのサービスエリアをこの地理的エリア内で決定することができる。

【0020】

ステップ２０２では、ＰＯＤモードで、サービスエリアに基づいて振り分けられる注文から対象注文を決定することができる。

【0021】

いくつかの実施形態では、ＰＯＤモードでの振り分けられる注文は、注文生成ユーザによって生成され送信される注文を意味する。注文生成ユーザは、注文を生成して送信し、例えばサービスを要求するユーザである。例えば、注文生成ユーザは、（車両呼び出しのシナリオにおいて）車両を呼ぶ乗員であっても、（食品配達を注文するシナリオにおいて）食品配達を注文する人などであってもよい。１つのシナリオにおける注文生成ユーザは、他のシナリオにおける受注ユーザ又は別の状態のユーザであってよく、本出願は、この態様に限定されるべきではない。

【0022】

一般に、Ｏ２Ｏサービスの場合に、注文は通常、サービスが提供され得る始点及び終点を含む。したがって、受注ユーザ（すなわち、サービスプロバイダ）がサービスを提供できる地理的エリアは、サービス提供プロセスにおいて始点及び終点を少なくともカバーすべきである。換言すれば、受注ユーザにプッシュされる注文の始点及び終点は、受注ユーザのサービスエリアに含まれるべきである。

【0023】

まず、振り分けられる注文を分析し、その対応する始点及び終点を取得することができる。始点及び終点が全て受注ユーザのサービスエリア内にあると、注文は、受注ユーザの候補注文と見なすことができる。同様に、振り分けられる全ての注文を分析し、各注文の始点及び終点に基づいて受注ユーザの複数の候補注文を取得することができる。次に、複数の候補注文のうち、対象注文を選択して受注ユーザに送信することができる。

【0024】

対象注文を選択するために、任意の合理的な方法を使用することができる。１つの実施形態では、受注ユーザに最も近い始点によって対象注文を選択することができる。換言すれば、複数の候補注文のうち、始点が受注ユーザに最も近い注文を対象注文として選択する。別の実施形態では、候補注文の方向が受注ユーザの移動方向と同じであると、候補注文を対象注文として選択する。候補注文の方向は、始点から終点までの方向を意味する。別の実施形態では、対象注文を複数の候補注文からランダムに選択することができる。任意の他の合理的な手段又は規則を使用して候補注文から対象注文を選択することができ、本出願は候補注文から対象注文を決定する特定の方法を限定しないことを理解すべきである。

【0025】

ステップ２０３では、対象注文を受注ユーザにプッシュする。

【0026】

方法２００は、端末又はサーバによって実施され得る。いくつかの実施形態では、方法２００は、Ｏ２Ｏサービスクライアントアプリケーション（例えば、車両呼び出しアプリケーション、配達アプリケーションなど）を有する端末装置によって実施される。Ｏ２Ｏサービスクライアントアプリケーションがログインするために使用されるアカウントの識別情報は、サービスの識別情報（例えば、運転者、配達員など）として構成される。したがって、端末装置のユーザは、受注ユーザとして構成される。

【0027】

サービスクライアントアプリケーションは、ＰＯＤモードがオンになることを検出したとき、まず、端末装置のユーザのサービスエリア、すなわち、受注ユーザのサービスエリアを決定することができる。次に、サービスエリアに基づいて、ＰＯＤモードで、候補注文から対象注文を取得することができる。そして、対象注文を端末装置のユーザ（すなわち、受注ユーザ）にプッシュし、対象注文の情報を端末装置の画面に表示する。

【0028】

いくつかの実施形態では、方法２００はサーバによって実施され得る。サーバは、車両呼び出しアプリケーション又は配達アプリケーションなどのクライアントにＯ２Ｏサービスを提供できるサーバであってよい。サーバは、ＰＯＤモードで、注文生成ユーザ及び受注ユーザを検出することができる。まず、サーバは、各受注ユーザのサービスエリアを決定することができる。次に、サーバは、決定された各受注ユーザのサービスエリアに基づいて、ＰＯＤモードで、振り分けられる注文のうち、各受注ユーザの対象注文を取得することができる。そして、対象注文を対応する受注ユーザにプッシュすることができる。

【0029】

本出願の上述の実施形態に係る注文振り分け方法２００は、サービスリソースを大きなサービス需要のあるエリアに割り当てて、サービスリソースの無駄を減らし、サービスの効率を改善することができる。

【0030】

図３は、本出願の例示的な実施形態に係るＰＯＤモードでの別の注文振り分け方法３００を示すフローチャートである。方法３００は、端末又はサーバによって実施され得る。いくつかの実施形態では、方法３００は、車両呼び出しアプリケーションがインストールされた端末装置によって実施される。当業者であれば、端末装置がスマートフォン、インテリジェントウェアラブル装置、タブレット、携帯情報端末などの携帯端末装置を含み得るが、これらに限定されないことを理解する。

【0031】

ステップ３０１に示すように、予め設定されたイベントを検出又は決定したとき、予め設定されたイベントの影響エリアを決定することができる。

【0032】

いくつかの実施形態では、予め設定されたイベントは、例えば、吹雪、竜巻、暴風雨などとして予め設定された危険な気象タイプであってよい。予め設定されたイベントは、祝日、例えば、春節、国家の日などであってよい。予め設定されたイベントは、ソーシャルイベント、例えば、国際会議、ボールゲーム、オリンピックゲームなどであってよい。予め設定されたイベントは他のイベントであってもよく、本出願はこの態様において限定されないことを理解すべきである。

【0033】

一般に、予め設定されたイベントが発生したとき、広範囲の交通が影響を受ける可能性がある。予め設定されたイベントの影響エリアは、交通が予め設定されたイベントによって影響されるエリアとして定義される。１つの実施形態では、予め設定されたイベントは暴風雨であってよく、その対応する影響エリアは雨が降るエリアであってよい。別の実施形態では、予め設定されたイベントは交通渋滞であってよく、その対応する影響エリアは渋滞しているエリアであってよい。

【0034】

ステップ３０１では、まず、端末／サーバによって予め設定されたイベントが発生したかどうかを検出することができる。１つの実施形態では、気象情報を取得して、予め設定された気象イベント（例えば、吹雪、竜巻、暴風雨など）が発生したかどうかを決定することができる。別の実施形態では、ローカルエリア内の交通状況（例えば、都市、町、街区など）を取得して、予め設定された交通イベントが発生したかどうかを決定することができる。交通状況は、交通渋滞が発生する各道路の交通状況を含み得る。他の手段によって、予め設定されたイベントが発生したかどうかを検出することも可能であり、本出願は、予め設定されたイベントが発生したかどうかを検出する特定の態様に限定されないことを理解すべきである。

【0035】

予め設定されたイベントが検出されると、次に、予め設定されたイベントの影響エリアを決定する。異なる予め設定されたイベントは、それらの対応する影響エリアを決定するための異なる方法に対応することができる。方法は、端末／サーバに設計され記憶され得る。特定の予め設定されたイベントを検出したとき、端末／サーバは、まず、どの予め設定されたイベントであるかを決定し、次に、特定の予め設定されたイベントによる影響エリアを決定するための対応する方法を見つけることができる。

【0036】

例えば、予め設定されたイベントが暴風雨として検出されると、端末／サーバは、まず、暴風雨の影響エリアを決定することができる。１つの方法では、暴風雨の影響エリアを、雨が降る全てのエリアとして設定することができる。この方法に従って、端末／サーバは、例えばオンラインで得られた天気予報に基づいて、雨が降る全てのエリアを検索し、これらのエリアを予め設定されたイベント（暴風雨）の影響エリアとして設定することができる。別の例では、予め設定されたイベントが交通渋滞として検出されると、端末／サーバは、まず、交通渋滞の影響エリアを決定することができる。１つの方法では、交通渋滞指数は、交通渋滞の程度を示すように定義される。当業者は、例えば、端末又はサーバ上の地図アプリケーションから、又はオンライン地図アプリケーション、交通量レポートから、交通情報を取得する多くの方法があることを理解すべきである。１つの実施形態では、本出願の方法を実施する端末又はサーバ上のソフトウェアアプリケーションは、ソフトウェアアプリケーションのユーザから収集した情報に基づいて、それ自体の交通情報を生成することができる。エリアが閾値より大きい交通渋滞指数を有し、エリアのサイズも閾値サイズより大きいとき、エリアは、予め設定されたイベントの影響エリアに含まれる。交通渋滞指数の閾値及びエリアの閾値サイズは、予め設定された値であってよい。この方法に従って、端末／サーバは、交通指数が閾値よりも大きく、サイズが閾値サイズより大きい全てのエリアを検索することができる。そして、これらのエリアを、予め設定されたイベント（交通渋滞）の影響エリアとして設定することができる。予め設定されたイベントの影響エリアは、他の手段によって決定されてもよく、本出願は、予め設定されたイベントの影響エリアを決定する特定の方法に限定されないことを理解すべきである。

【0037】

ステップ３０２では、予め設定されたイベントの影響エリアに基づいて、ＰＯＤモードで注文及び受注ユーザを決定することができる。予め設定されたイベントが発生すると、影響エリア内の交通状況は影響を受ける可能性がある。したがって、影響エリア内でＰＯＤモードをオンにすることができる。ＰＯＤモードで注文を振り分けることにより、予め設定されたイベントが発生したとき、注文振り分けプロセスを最適化することができる。

【0038】

１つの実施形態では、受注ユーザの位置を取得して、受注ユーザが影響エリアに位置するかどうかを決定することができる。ＰＯＤモードで、影響エリアに位置する受注ユーザを受注ユーザとして決定することができる。一方、さらに、注文生成ユーザの位置を取得して、注文生成ユーザが影響エリアに位置するかどうかを決定することができる。ＰＯＤモードで、影響エリアに位置する注文生成ユーザを注文生成ユーザとして決定することができる。これにより、ＰＯＤモードでの注文生成ユーザからの注文をＰＯＤモードでの注文として決定することができる。

【0039】

別の実施形態では、サーバは、受注ユーザ及び影響エリアに位置する注文生成ユーザに問い合わせを送信することができる。例えば、問い合わせは、「ＰＯＤモードで注文を受信したいですか？」であってよく、問い合わせを確認した受注ユーザをＰＯＤモードでの受注ユーザとして決定する。同様に、問い合わせを確認した注文生成ユーザからの注文をＰＯＤモードでの注文として決定することができる。

【0040】

ステップ３０３では、ＰＯＤモードで受注ユーザのサービスエリアを決定する。ステップ３０４では、ＰＯＤモードでの決定されたサービスエリアに基づいて、ＰＯＤモードでの注文から対象注文を決定することができる。ステップ３０５で、ＰＯＤモードで対象注文を受注ユーザにプッシュする。ステップ３０３〜３０５の詳細は、注文振り分け方法２００と同様であり、ここで繰り返して説明しない。

【0041】

方法３００は、端末又はサーバによって実施され得る。いくつかの実施形態では、方法３００は、ユーザが受注ユーザであってよい端末装置によって実施される。端末装置は、まず、予め設定されたイベントが発生したかどうかを検出することができる。例えば、端末装置は、現在の位置（例えば、都市、街区、郡など）での気象情報、交通情報などのいくつかのリアルタイム情報を取得することができる。そして、端末装置は、リアルタイム情報に基づいて、予め設定されたイベントが発生したかどうかを決定することができる。予め設定されたイベントを検出したとき、予め設定されたイベントの影響エリアを決定し、さらに決定された影響エリアに基づいてＰＯＤモードを決定する。ＰＯＤモードが有効であると、受注ユーザをＰＯＤモードでの受注ユーザとして決定するそれとともに、端末装置は、さらに、影響エリアに位置する注文生成ユーザを決定し、ＰＯＤモードでの注文生成ユーザとしてＰＯＤモードをオンにすることができる。これにより、ＰＯＤモードでの受注ユーザからの注文をＰＯＤモードでの注文として決定することができる。

【0042】

いくつかの実施形態では、方法３００はサーバによって実施され得る。サーバは、予め設定されたイベントがサーバの稼働エリア、すなわち、サーバがサービスするエリアにおいて発生したかどうかを検出することができる。サーバは、まず、気象情報、交通情報などの動作エリア内のリアルタイム情報を取得することができる。次に、サーバは、リアルタイム情報に基づいて、予め設定されたイベントが発生したかどうかを決定することができる。予め設定されたイベントを検出したとき、予め設定されたイベントの影響エリアを決定し、さらに決定された影響エリアに基づいてＰＯＤモードを決定する。そして、影響エリアに位置しＰＯＤモードを有効化した受注ユーザを、ＰＯＤモードでの受注ユーザとして決定することができる。それとともに、サーバは、さらに、影響エリアに位置する注文生成ユーザを決定し、ＰＯＤモードでの注文生成ユーザとしてＰＯＤモードをオンにすることができる。これにより、ＰＯＤモードでの受注ユーザからの注文をＰＯＤモードでの注文として決定することができる。

【0043】

本出願では、注文振り分け方法３００は、予め設定されたイベントを検出したとき、予め設定されたイベントの影響エリアを決定することができる。影響エリアに基づいて、ＰＯＤモードでの受注ユーザ及び注文を決定することができる。任意の特定の受注ユーザに対して、対応するサービスエリアを決定することができる。サービスエリアに基づいて、ＰＯＤモードでの注文から対象注文を選択し、受注ユーザにプッシュすることができる。したがって、予め設定されたイベントでは、サービス需要が大きい、予め設定されたイベントの影響エリアにサービスを集中させることができる。したがって、注文振り分け方法３００は、サービスリソースの無駄を減らし、さらにサービスの効率を改善するのに役立つ。

【0044】

図４は、本出願の実施形態に係るＰＯＤモードでの別の注文振り分け方法４００を示すフローチャートである。方法４００は、ＰＯＤモードでの受注ユーザのサービスエリアを決定するプロセスと、サービスエリアに基づいてＰＯＤモードでの注文から対象注文を取得する別のプロセスとを示す。方法４００は、端末又はサーバによって実施され得る。方法４００は、ステップ４０１〜４０９を含み得る。

【0045】

ステップ４０１では、予め設定されたイベントを検出したとき、予め設定されたイベントの影響エリアを決定することができる。

【0046】

ステップ４０２では、予め設定されたイベントの影響エリアに基づいて、ＰＯＤモードで注文及び受注ユーザを決定することができる。

【0047】

ステップ４０３では、受注ユーザの現在の位置を取得することができる。いくつかの実施形態では、ＰＯＤモードで受注ユーザの位置データを取得し、該位置データを受注ユーザの現在の位置として使用することができる。

【0048】

ステップ４０４では、受注ユーザが現在位置している地域を決定することができる。いくつかの実施形態では、該地域は地質学的位置であってよい。いくつかの実施形態では、該地域は、都市（例えば、北京、上海など）、郡、又は街区であってよい。この地域は他の手段によって分割されたエリアであってもよく、本出願の具体的な態様は限定されないことを理解すべきである。いくつかの実施形態では、受注ユーザが現在位置している地域を、受注ユーザの現在の位置に基づいて決定することができる。

【0049】

ステップ４０５では、受注ユーザが現在位置している地域に基づいて、第１のエリアとして定義される、この地域のサービスエリアを決定することができる。

【0050】

いくつかの実施形態では、受注ユーザが現在位置している地域は、１つ以上のサービスエリアに対応することができる。図５に示すように、地域５０１は、３つのサービスエリア５０２、５０３、５０４に対応することができる。具体的には、該地域のサービスエリアは、大量のサービスが要求されるエリアとすることができる。該サービスエリアが予め設定されたイベントの影響を受けると、要求されるサービスの量が増加し、サービスの効率に影響を及ぼす可能性がある。したがって、サービスエリアは、予め設定されたエリアであっても、履歴注文データに基づいて決定されたエリアであっても、現在の注文データに基づいて決定されたエリアであってもよい。

【0051】

いくつかの実施形態では、各地域に対して、リアルタイム情報及び統計データに基づいて、サービス需要が大きいエリアを該地域のサービスエリアとして設定することができる。例えば、タクシーを呼ぶ場合、都市の繁華街と地下鉄駅との間に大量のタクシー呼び出し要求を生成し、繁華街と地下鉄駅との間のエリアを該地域のサービスエリアとして設定することができる。これらの予め設定されたサービスエリアを対応するエリアに関連して記憶することができる。記憶データから任意の地域に関連付けられたサービスエリアを取得し、該地域のサービスエリアを決定することができる。

【0052】

いくつかの実施形態では、履歴注文の経路に基づいて、該地域のサービスエリアを決定することができる。例えば、任意の所定の期間に履歴注文データを検索することができる。履歴注文データのうち、サービスを完了した注文を選択することができ、これらの完了した注文で使用される経路を取得し分析することができる。経路が所定の回数（閾値回数）を超えて使用されていると、該経路を基準経路として設定することができる。基準経路に基づいて、該地域のサービスエリアを、１つ以上の基準経路を含むエリアとして定義することができる。

【0053】

いくつかの実施形態では、所定の期間内に該地域で生成された注文データを取得することができる。そして、これらの生成された注文の各々で使用される経路を取得し分析することもできる。経路が所定の回数（閾値回数）を超えて使用されていると、該経路を基準経路として設定することができる。基準経路に基づいて、該地域のサービスエリアを、１つ以上の基準経路を含むエリアとして定義することができる。

【0054】

いくつかの実施形態では、基準経路に基づいて、１つ以上の独立したエリアを設定することができる。独立したエリアの各々は、１つ以上の完全な参照経路を含み得て、独立したエリアは、互いに重なり合うことができる。独立エリアの各々を該地域のサービスエリアとして設定することができる。

【0055】

ステップ４０６では、第１のエリアから受注ユーザのサービスエリアを選択することができる。いくつかの実施形態では、第１のエリアは、１つ以上の独立したエリアを含み得て、独立エリアから受注ユーザのサービスエリアを選択することができる。具体的には、受注ユーザの現在の位置に対応するエリアを第１のエリア内で取得し、該エリアを第２エリアとして定義することができる。そして、第２のエリアに基づいて、受注ユーザのサービスエリアを決定することができる。第１のエリアは１つ以上であってもよく、第１のエリアは互いに重なり合うことができる。第１のエリアの各々に対応する第２のエリアが１つ以上であってもよい。

【0056】

いくつかの実施形態では、第２のエリアは、受注ユーザのサービスエリアと直接的に考えられてもよい。いくつかの実施形態では、受注ユーザは、１つ以上の第２のエリアからサービスエリアを決定することができる。いくつかの実施形態では、注文要求の量に基づいてサービスエリアを決定することができる。最大量の注文が要求される第２のエリアを受注ユーザのサービスエリアとして選択することができる。

【0057】

ステップ４０７では、注文の始点及び終点を取得することができる。

【0058】

ステップ４０８では、始点及び終点が受注ユーザのサービスエリアにおいて含まれる注文を受注ユーザの対象注文として選択することができる。

【0059】

ステップ４０９では、対象注文を受注ユーザにプッシュする。

【0060】

１つの例示的な実施形態では、例えば、都市は暴風雨がある。車両呼び出しアプリケーションを使用しているクライアントは、ＰＯＤモードに切り替わることができる。ＰＯＤモードでは、車両運転者（受注ユーザの一例）の現在の位置を決定することができる。例えば、車両運転者は地下鉄駅に位置する。次に、現在の位置に基づいて、車両運転者のサービスエリアを決定することができる。車両運転者が１つ以上のサービスエリアによってカバーされる位置に位置すると、これらのサービスエリアを車両運転者に報告し、車両運転者は、自分がどのサービスエリアに属するかを決定することができる。又は、サービスエリアを、注文要求の最大量を有するエリアとして決定することができる。例えば、サービスエリアが繁華街と地下鉄駅との間のエリアであると、始点及び終点がサービスエリアにおいて含まれる注文のみを車両運転者にプッシュする。

【0061】

本実施形態は、上記適用シナリオに限らず、他のシナリオにも適用することができる。本出願に係る注文振り分け方法は、予め設定されたイベントを検出したとき、予め設定されたイベントの影響エリアを決定し、次に影響エリアに基づいてＰＯＤモードで受注ユーザ及び注文を決定することができる。本方法は、受注ユーザの現在の位置を取得することと、受注ユーザが現在位置している地域を決定することと、第１のエリアとして定義される地域のサービスエリアを決定することと、その後に第１のエリア内で受注ユーザのサービスエリアを決定することを含み得る。その後、受注ユーザのサービスエリアに基づいて対象注文を決定し、受注ユーザにプッシュすることができる。予め設定されたイベントでは、サービス需要が大きい、予め設定されたイベントの影響エリアにサービスを集中させることができる。したがって、注文振り分け方法は、サービスリソースの無駄を減らし、さらにサービスの効率を改善するのに役立つ。

【0062】

いくつかの実施形態では、上記方法は、さらに、受注ユーザが現在位置している地域のサービスエリアの関連情報を出力することを含み得る。関連情報は、サービスエリア内のサーバサイト情報とサービスエリア内の注文情報とを含み得る。例えば、受注ユーザが現在位置している地域が北京であると仮定すると、該方法は、北京エリアでの全てのサービスエリアの情報とその関連情報を出力することを含み得る。関連情報は、サービスエリア内の各サイト情報とサービスエリア内の注文情報とを含み得る。受注ユーザは、関連情報を用いて、大量の注文が要求されるサービスエリアを受注ユーザのサービスエリアとして選択することができ、それによって、サービスリソースの無駄を減らし、サービスの効率を改善することができる。

【0063】

本出願の方法の動作は、図面において特定の順序で説明されているが、所望の結果を達成するために、そのような動作は特定の順序で実行されなければならず、又は示された全ての動作は実行されなければならないことに留意すべきである。ステップの順序は変更可能である。追加的又は代替的に、特定のステップを省略してもよく、複数のステップを１つのステップに組み合わせてもよく、及び／又は１つのステップを複数のステップに分解してもよい。

【0064】

図６は、本出願の例示的な実施形態に係るＰＯＤモードでの注文振り分け装置６００のブロック図である。装置６００は、第１の決定ユニット６０１、取得ユニット６０２、及びプッシュユニット６０３を含み得る。

【0065】

第１の決定ユニット６０１は、ＰＯＤモードで受注ユーザのサービスエリアを決定するように構成することができる。取得ユニット６０２は、上記サービスエリアに基づいて、ＰＯＤモードで振り分けられる注文から対象注文を取得するように構成することができる。プッシュユニット６０３は、対象注文を受注ユーザにプッシュするように構成することができる。

【0066】

いくつかの代替実施形態では、装置６００は、第２の決定ユニット及び第３の決定ユニット（図６に図示せず）をさらに含み得る。第２の決定ユニットは、予め設定されたイベントを検出したとき、予め設定されたイベントの影響エリアを決定するように構成することができる。第３の決定ユニットは、影響されたエリアに基づいて注文及び受注ユーザを決定するように構成することができる。

【0067】

いくつかの実施形態では、第３の決定ユニットは、さらに、ＰＯＤモードで、影響エリア内の受注ユーザを受注ユーザとして決定し、ＰＯＤモードで、影響エリア内の注文生成ユーザによって生成された注文を注文として決定するように構成することができる。

【0068】

いくつかの実施形態では、第３の決定ユニットは、影響エリア内の注文生成ユーザ及び受注ユーザに要求を送信し、ＰＯＤモードで、要求に応答した受注ユーザを受注ユーザとして設定し、ＰＯＤモードで、要求に応答した受注ユーザからの注文を注文として設定するように構成することができる。

【0069】

いくつかの実施形態では、第１の決定ユニット６０１は、第１の取得サブユニット、決定サブユニット、第２の取得サブユニット、及び第３の取得サブユニット（図６に図示せず）を含み得る。

【0070】

第１の取得サブユニットは、受注ユーザの現在の位置を取得するように構成することができる。決定サブユニットは、受注ユーザが現在位置している地域を決定するように構成することができる。第２の取得サブユニットは、受注ユーザが現在位置している地域のサービスエリアを決定し、該地域のサービスエリアを第１のエリアとして設定するように構成することができる。第３の取得サブユニットは、第１のエリア内の受注ユーザのサービスエリアを決定するように構成することができる。いくつかの実施形態では、第２の取得サブユニットは、記憶データ中の地域に関連するサービスエリアを取得し、該サービスエリアを該地域のサービスエリアとして決定するように構成することができる。

【0071】

いくつかの実施形態では、第２の取得ユニットは、特定の期間内の該地域内の完了した注文の履歴データを取得し、履歴データ内でこれらの完了した注文の各々で使用される経路を取得し、所定の回数（閾値回数）を超えて使用される経路を選択して該経路を基準経路として設定し、基準経路に基づいて該地域のサービスエリアを決定するように構成することができる。

【0072】

いくつかの実施形態では、第２の取得ユニットは、特定の期間内の該地域内で生成された注文のデータを取得し、該データからこれらの生成された注文の各々で使用される経路を取得し、所定の回数（閾値回数）を超えて使用される経路を選択して該経路を基準経路として設定し、基準経路に基づいて該地域のサービスエリアを決定するように構成することができる。

【0073】

いくつかの実施形態では、第３の取得サブユニットは、受注ユーザが現在位置している地域をカバーする第１のエリア内で１つ以上のエリアを取得し、１つ以上のエリアを第２のエリアとして設定し、第２のエリアを受注ユーザのサービスエリアとして決定するように構成することができる。いくつかの実施形態では、第３の取得サブユニットは、受注ユーザが現在位置している地域をカバーする第１のエリア内で１つ以上のエリアを取得し、これらのエリアを第２のエリアとして設定し、第２のエリアを受注ユーザに選択のために出力し、受注ユーザによって選択された第２のエリアを受注ユーザのサービスエリアとして決定するように構成することができる。いくつかの実施形態では、第３の取得サブユニットは、受注ユーザが現在位置している地域をカバーする第１のエリア内で１つ以上のエリアを取得し、これらのエリアを第２のエリアとして設定し、各第２のエリアでの現在の注文要求を取得し、現在の注文要求が最も多い第２のエリアを受注ユーザのサービスエリアとして決定するように構成することができる。

【0074】

いくつかの実施形態では、取得ユニットは、始点及び終点取得サブユニット及び振り分けサブユニット（図６に図示せず）をさらに含み得る。始点及び終点取得サブユニットは、注文の始点及び終点を取得するように構成することができる。振り分けサブユニットは、始点及び終点がサービスエリアにおいて含まれる注文から対象注文を選択するように構成することができる。

【0075】

いくつかの実施形態では、取得ユニットは、出力ユニット（図６に図示せず）をさらに含み得る。出力ユニットは、受注ユーザが現在位置している地域のサービスエリアの情報を出力するように構成することができる。情報は、サービスエリア内のサーバサイトの情報とサービスエリア内の注文要求の情報とを含み得る。

【0076】

いくつかの実施形態では、予め設定されたイベントは、予め設定された気象タイプイベント及び交通渋滞のうちの１つ以上を含み得る。

【0077】

当業者であれば、上記装置は、端末又はサーバに予めインストールされてもよいし、ダウンロードなどによって端末又はサーバにロードされてもよいことを理解すべきである。上記装置における対応するユニットは、端末又はサーバ内のユニットと協働して注文振り分けを実行することができる。

【0078】

本開示の実施形態は、本開示の実施形態に係る方法、装置（システム）、及びコンピュータプログラム製品の流れ図及び／又はブロック図を参照して説明される。流れ図及び／又はブロック図の各フロー及び／又はブロック、並びにフローチャート及び／又はブロック図のフロー及び／又はブロックの組合せは、コンピュータプログラム命令によって実装できることを理解すべきである。これらのコンピュータプログラム命令は、特殊用途の機械を製造するように、コンピュータのプロセッサ、組み込みプロセッサ、又はのプログラム可能なデータ処理に提供され、これによって、コンピュータのプロセッサ又は他のプログラム可能なデータ処理を介して実行される命令は、流れ図の１つ以上の流れ及び／又はブロック図の１つ以上のブロックで指定された機能を実施する手段を作成する。

【0079】

添付の図面におけるフローチャート及びブロック図は、本発明の複数の実施形態に係るシステム及び方法の可能な実装形態のシステムアーキテクチャ、機能及び動作を示す。フローチャート又はブロック図の各ブロックは、指定された論理機能を実装するために使用される１つ以上の実行可能な命令を含む１つのユニット／モジュール、１つのプログラムセグメント、又は一部のコードを示す。いくつかの代替的な実装形態では、ブロック内にマークされた機能はまた、図面内にマークされたシーケンスとは異なるシーケンスで行われることにも留意すべきである。例えば、２つの連続するブロックは実際には実質的に並列に実行することができ、時々、それらは関与する機能に依存して逆の順序で実行することもできる。

【0080】

当業者には理解されるように、本開示の実施形態は、方法、システム、又はコンピュータプログラム製品として具体化され得る。したがって、本開示の実施形態は、完全なハードウェアの実施形態、完全なソフトウェアの実施形態、又は、専用の構成要素が上記機能を実行することを可能にするためのソフトウェア及びハードウェアを組み合わせた実施形態の形態をとることができる。さらに、本開示の実施形態は、コンピュータ可読プログラムコードを含む１つ以上の有形及び／又は非一時的コンピュータ可読記憶媒体に組み込まれたコンピュータプログラム製品の形態をとることができる。非一時的コンピュータ可読記憶媒体の一般的な形態は、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、又は任意の他の磁気データ記憶媒体、ＣＤ−ＲＯＭ、任意の他の光学データ記憶媒体、孔のパターンをもつ任意の物理的媒体、ＲＡＭ、ＰＲＯＭ及びＥＰＲＯＭ、フラッシュＥＰＲＯＭ、又は任意の他のフラッシュメモリ、ＮＶＲＡＭ、キャッシュ、レジスタ、任意の他のメモリチップ又はカートリッジ、並びにネットワーク化されたバージョンを含む。

【0081】

さらに、コンピュータプログラム命令をコンピュータ又は他のプログラム可能なデータ処理装置にロードすることにより、コンピュータ又は他のプログラム可能な装置で一連の動作ステップを実行して、コンピュータによって実行される処理を生成し、これによって、命令（コンピュータ又は他のプログラム可能な装置で実行される）は、流れ図の１つ以上の流れ及び／又はブロック図の１つ以上のブロックで指定された機能を実施するためのステップを提供する。典型的な構成では、コンピュータ装置は、１つ以上の中央処理ユニット（ＣＰＵ）、入力／出力インタフェース、ネットワークインタフェース及びメモリを含む。メモリは、コンピュータ可読記憶媒体内のリードオンリメモリ（ＲＯＭ）又はフラッシュＲＡＭなどの揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、及び／又は不揮発性メモリなどの形態を含み得る。メモリは、コンピュータ可読記憶媒体の一例である。

【0082】

上記様々な装置は、主に説明のためのものである。上記装置の実施形態は単なる例示であり、分離手段として記載されたユニット及びサブユニットは物理的に分離されてもなくてもよく、ユニット及びサブユニットは物理ユニットであってもなくてもよい。ユニット及びサブユニットは、物理的に１つの場所に位置してもよく、又はネットワーク要素の形態で存在してもよい。装置の一部又は全体は、実際の要件及び条件に従って選択され実装され得る。当業者であれば、進歩性を伴うことなく理解し実践することができる。

【0083】

本明細書で説明され特許請求される本発明は、本発明のいくつかの態様の例示として意図されているので、本明細書で開示する特定の好ましい実施形態によって範囲が限定されるものではない。実際に、本明細書に示され説明されたものに加えて、本発明の様々な修正は、前述の説明から当業者に明らかになる。そのような修正はまた、添付の特許請求の範囲内に収まることが意図される。

【符号の説明】

【0084】

１００ シナリオ
１０１ 受注端末装置
１０２ 注文生成端末装置
１０３ サーバ
６００ 装置
６０１ 第１の決定ユニット
６０２ 取得ユニット
６０３ プッシュユニット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】