▶ グラブタクシー ホールディングス プライベート リミテッドの特許一覧
特許7389819通信サーバ装置、通信サーバ装置において実行される方法、通信システム、コンピュータプログラム、コンピュータプログラム製品、及び非一時的記憶媒体
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-21
(45)【発行日】2023-11-30
(54)【発明の名称】通信サーバ装置、通信サーバ装置において実行される方法、通信システム、コンピュータプログラム、コンピュータプログラム製品、及び非一時的記憶媒体
(51)【国際特許分類】
G06F 16/9035 20190101AFI20231122BHJP
G06F 16/909 20190101ALI20231122BHJP
【ＦＩ】
G06F16/9035
G06F16/909
【請求項の数】
25
(21)【出願番号】P 2021564198
(86)(22)【出願日】2019-04-29
(65)【公表番号】
(43)【公表日】2022-07-01
(86)【国際出願番号】 CN2019084965
(87)【国際公開番号】W WO2020220188
(87)【国際公開日】2020-11-05
【審査請求日】2022-02-18
【前置審査】
(73)【特許権者】
【識別番号】518236797
【氏名又は名称】グラブタクシー ホールディングス プライベート リミテッド
【氏名又は名称原語表記】ＧＲＡＢＴＡＸＩ ＨＯＬＤＩＮＧＳ ＰＴＥ． ＬＴＤ．
【住所又は居所原語表記】３ Ｍｅｄｉａ Ｃｌｏｓｅ， ＃０１－０３／０６， Ｓｉｎｇａｐｏｒｅ １３８４９８， Ｓｉｎｇａｐｏｒｅ
(74)【代理人】
【識別番号】100137095
【弁理士】
【氏名又は名称】江部 武史
(72)【発明者】
【氏名】ファン， チン
(72)【発明者】
【氏名】ジャオ， ラン
(72)【発明者】
【氏名】ダイ， チェンチェン
(72)【発明者】
【氏名】デン， ジチャン
(72)【発明者】
【氏名】ジャン， ルイ
【審査官】甲斐 哲雄
(56)【参考文献】
【文献】特開２０１８－０４９３３６（ＪＰ，Ａ）
【文献】特開２０１４－０１６２９０（ＪＰ，Ａ）
【文献】米国特許出願公開第２００７／００５０１２８（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１８／０２６８３２４（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／００－１６／９５８
Ｇ０１Ｃ ２１／００－２１／３６
(57)【特許請求の範囲】
【請求項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】
プロセッサによって実行されると、前記プロセッサに、請求項５乃至８、１５乃至１９、及び２２のいずれか１項に記載の方法を実行させる命令を記憶する非一時的記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は一般に、通信の分野に関する。本発明の一態様は、輸送関連サービスの１つ以上の関心地点をユーザーに推奨するための通信サーバ装置に関する。本発明の他の態様は、ユーザーに輸送関連サービスの１つ以上の関心地点を推奨するためのさらなる通信サーバ装置、ユーザーに輸送関連サービスの１つ以上の関心地点を推奨するための方法、ユーザーに輸送関連サービスの１つ以上の関心地点を推奨するための通信システム、およびユーザーに輸送関連サービスの１つ以上の関心地点を推奨するための通信サーバデバイスに関する。さらなる態様は、本明細書で説明される方法のうちのいずれか１つを実施するための命令を有するコンピュータプログラム製品、コンピュータプログラム、および非一時的記憶媒体に関する。
【0002】
本発明の一態様は、それに限定されないが、特に、輸送関連サービスの１つ以上の関心地点をユーザーに推奨するためのアプリケーションを有する。例えば、ユーザーは輸送関連サービス、例えば、乗り物を運ぶ輸送サービスについてリクエストまたは予約を希望する場合があり、開示される技術は異なるアクション／シナリオに対して、または予約の様々な段階で、予約の目的のために、輸送関連サービスに対応する出発地および／または目的地としての１つ以上の関心地点の推奨を提供することができる。ユーザーは予約を行うために、対応するアプリケーションまたは「Ａｐｐ」を使用することができ、推奨される関心地点は検討および／または選択のために、Ａｐｐを介してユーザーに提供または提示することができる。
【背景技術】
【0003】
トランスポートサービスに対するユーザーの問合せに応答して、問合せに関連するＰＯＩ（Ｐｏｉｎｔ‐Ｏｆ‐Ｉｎｔｅｒｅｓｔ）の検索を行う。しかしながら、現在のＰＯＩサービスの品質は、他の要件や属性を考慮せずユーザーの位置に応じてＰＯＩをフィルタリングするため、輸送サービスの既知のアプローチとして満足のいくものではない。
【発明の概要】
【課題を解決するための手段】
【0004】
本発明の態様は、独立請求項に記載されている。一部のオプション機能は、従属請求項に定義される。
【0005】
本明細書に開示される技術の実施形態は、有意な技術的利点を提供することができる。本技術は例えば、複数のデータソースから得られる複数のデータ／情報に基づいて、輸送関連サービスの１つ以上の関心地点（ＰＯＩ）をユーザーに推奨することを可能にすることができる。
【0006】
少なくともいくつかの実装形態では、本明細書で開示される技術が履歴データ、例えば、履歴輸送関連サービスに対応する出発地と目的地との１つ以上のペアに関するデータに基づいて、１つ以上の関心地点（ＰＯＩ）の推奨を提供することができる。
【0007】
少なくともいくつかの実装形態では、本明細書で開示される技術が履歴データと、地域（例えば、都市）内の少なくとも１つの目的地カテゴリにおける最上位の関心地点に対応するデータとに基づいて、１つ以上の関心地点（ＰＯＩ）の推奨を可能にする。
【0008】
少なくともいくつかの実装形態では、本明細書で開示される技術は、候補ＰＯＩのための複数の基準に割り当てられた個々のスコアから決定され得る候補ＰＯＩの結果スコアに基づいて、１つ以上の関心地点（ＰＯＩ）の推奨を提供することができる。少なくともいくつかの基準についての個々のスコアは、履歴データに基づいて決定されてもよい。
【0009】
少なくともいくつかの実装形態では、本明細書で開示される技術は、輸送関連サービスの予約中に、異なるアクション／シナリオのための１つ以上の関心地点（ＰＯＩ）の推奨を提供することができ、これらのアクションは順番に発生してもよい。
【0010】
例示的な実装形態では、本明細書で開示される技術の機能は、携帯電話などの携帯通信装置上で実行されるソフトウェアに実装されてもよい。本明細書で開示される技術の機能を実装するソフトウェアは、ユーザーがオンラインストアからダウンロードした「Ａｐｐ」（コンピュータプログラム、またはコンピュータプログラム製品）に含まれてもよい。例えば、ユーザーの携帯電話上で実行する場合、携帯電話のハードウェア機能を使用して、携帯電話のトランシーバ構成要素を使用してユーザーに輸送関連サービスの１つ以上の関心地点（ＰＯＩ）を推奨するための安全な通信チャネルを確立するなど、以下に説明する機能を実装することができる。
【図面の簡単な説明】
【0011】
ここで、本発明を、例としてのみ、添付の図面を参照して説明する。
【発明を実施するための形態】
【0012】
本技術はリアルタイムで関心地点（points-of-interest；ＰＯＩ）推奨、例えば、リアルタイムでＧｏｌａｎｇベースのＰＯＩ発見および推奨を提供することができる。
【0013】
輸送サービス（例えば、乗り物輸送サービス）の一態様は、ユーザーに、可能な限り少ない労力で、ユーザーの位置に基づいて乗車（ピックアップ）および／または降車（ドロップオフ）として所望のＰＯＩを提供することであり、これは、予約ボタンをクリックする前にユーザーが画面上でクリックする時間によって測定することができる。地理ベースのサービスとして、ＰＯＩの発見および推奨は、多くの幾何学的計算および高いトラフィック・スループットを含むことができる。ＰＯＩの発見および推奨の高い可用性および安定性を確保することが重要である。本技術では、バックエンドシステムの安定性を確保するためにＧｏｌａｎｇベースのサービスアーキテクチャが採用されている。エラスティックサーチを利用して、データベース層上に何百万ものＰＯＩデータを編成することができる。Ｒｅｄｉｓは、キャッシュとしての各リクエストの応答時間を短縮するために使用できる。以下でさらに説明するように、Ｇｏｌａｎｇベースのサービスアーキテクチャを使用することができ、様々なシナリオに従って、エラスティックサーチおよびＲｅｄｉｓなどの技術を展開することによって、オンライン上の課題に対処することができる。ＰＯＩサービスは、画面上でクリックする時間が非常に短い場合に、平均して完了した予約の比率を高めるのに役立つ場合がある。
【0014】
最初に図１を参照すると、様々な実施形態に適用可能な通信システム１００が示されている。通信システム１００は、通信サーバ装置１０２、第１のユーザー（またはクライアント）通信装置１０４および第２のユーザー（またはクライアント）通信装置１０６を含む。これらの装置１０２、１０４、１０６は、例えばインターネット通信プロトコルを実現するそれぞれの通信リンク１１０、１１２、１１４を介して、通信ネットワーク１０８（例えばインターネット）中または通信ネットワーク１０８に接続される。通信装置１０４、１０６は移動セルラー通信ネットワーク（mobile cellular communication network）を含む公衆交換電話網（ＰＳＴＮネットワーク）のような他の通信ネットワークを介して通信することができるが、これらは分かりやすさの観点で図１から省略されている。装置１０４、１０６と同様の１つ以上の他の通信装置が存在し得ることを理解されたい。
【0015】
通信サーバ装置１０２は、輸送関連サービス（transport-related service）の１つ以上のＰＯＩ（Ｐｏｉｎｔ－ｏｆ－ｉｎｔｅｒｅｓｔ）をユーザーに推奨するためのものであってもよい。
【0016】
通信サーバ装置１０２は、図１に概略的に示すように単一のサーバであってもよいし、複数のサーバ構成要素に分散された通信サーバ装置１０２によって実行される機能を有していてもよい。図１の例では通信サーバ装置１０２が１つ以上のマイクロプロセッサ（μＰ）１１６、実行可能命令１２０のロードのためのメモリ１１８（例えば、ＲＡＭ（ランダムアクセスメモリ）のような揮発性メモリ）、通信サーバ装置１０２がプロセッサ１１６の制御の下で実行する機能性を規定する実行可能命令１２０を含むが、これらに限定されず、多数の個々の構成要素を含むことができる。通信サーバ装置１０２はまた、通信サーバ装置１０２が通信ネットワーク１０８を介して通信することを可能にする入出力モジュール１２２を含んでもよい。ユーザーインタフェース１２４はユーザー制御のために設けられ、例えば、ディスプレイモニター、コンピュータキーボードなどの１つ以上のコンピューティング周辺機器を含むことができる。通信サーバ装置１０２はデータベース（ＤＢ）１２６を含むこともでき、その目的は以下の説明から容易に明らかになる。
【0017】
ユーザー通信装置１０４は１つ以上のマイクロプロセッサ１２８、実行可能命令１３２のロードのためのメモリ１３０（例えば、ＲＡＭのような不揮発性メモリ）、ユーザー通信装置１０４がプロセッサ１２８の制御下で実行する機能を規定する実行可能命令１３２を含むが、これらに限定されず、多数の個々の構成要素を含むことができる。ユーザー通信装置１０４はまた、ユーザー通信装置１０４が通信ネットワーク１０８を介して通信することを可能にする入出力（Ｉ／Ｏ）モジュール１３４を含む。ユーザー制御のために、ユーザーインタフェース１３６が提供される。例えば、ユーザー通信装置１０４がスマートフォンまたはタブレットデバイスである場合、ユーザーインタフェース１３６は、多くのスマートフォンおよび他の携帯デバイスにおいて普及しているようなタッチパネルディスプレイを有してもよい。あるいは、例えば、ユーザー通信装置１０４がデスクトップまたはラップトップコンピュータである場合、例えば、ユーザーインタフェースはディスプレイモニター、コンピュータキーボード等の１つ以上のコンピューティング周辺機器を有してもよい。
【0018】
例えば、ユーザー通信装置１０６はユーザー通信装置１０４と同一または類似のハードウェアアーキテクチャを有するスマートフォンまたはタブレットデバイスであってもよい。
【0019】
ユーザー通信装置１０４および／またはユーザー通信装置１０６は、ユーザーへの輸送関連サービスの１つ以上の推奨関心地点（ＰＯＩ）に関する情報またはデータを受信するためのものとすることができる。
【0020】
図２Ａは、輸送関連サービスの１つ以上の関心地点（ＰＯＩ）をユーザーに推奨するための通信サーバ装置２０２ａを示す概略ブロック図を示す。通信サーバ装置２０２ａはプロセッサ２１６ａおよびメモリ２１８ａを含み、通信サーバ装置２０２ａはプロセッサ２１６ａの制御下で、ユーザーの位置（例えば、現在の位置または予想された位置）を示すデータフィールド（例えば、緯度（ｌａｔ）値および経度（ｌｎｇ）値を示すデータ）を含むユーザーデータの受信に応じて、メモリ２１８ａ内の命令を実行するように構成され、さらに、通信サーバ装置２０２ａが、輸送関連サービスに対応するユーザーに関連する履歴データ（historical data）がないと判定したことに応じて、当該位置を有する地図を表すデータ２５５ａを検索し、ユーザーのユーザー通信装置によって受信するために、輸送関連サービスの推奨出発地（recommended origin location）（またはピックアップ位置）として、マップ上に（単一の）関心地点の（例えば、ユーザーの所在地に基づく）決定のために、ユーザーの通信装置を介してユーザーにマップを提示するためのマップを表すデータ２５５ａを送信し、通信サーバ装置２０２ａが、１つ以上のデータレコードに輸送関連サービスに対応する履歴データがあると判断したことに基づいて、ユーザーに関連付けられている履歴データは、履歴データに基づいて、輸送関連サービスの推奨される出発地（またはピックアップ位置）として、（単一の）第１の関心地点を決定し、履歴データに基づいて、輸送関連サービスの推奨される目的地（またはドロップオフ位置）として、（単一の）第２の関心地点を決定し、過去の輸送関連サービスに対応して、第１の関心地点と第２の関心地点とをペアにし、ユーザー通信装置によって受信するために、第１の関心地点を示すデータ２５６ａおよび第２の関心地点を示すデータ２５７ａを送信する。
【0021】
プロセッサ２１６ａおよびメモリ２１８ａは（ライン２１７ａによって表されるように）互いに結合されてもよく、例えば、物理的に結合されてもよく、および／または電気的に結合されてもよい。プロセッサ２１６ａはプロセッサ１１６（図１）の文脈で説明されたものであってもよいし、メモリ２１８ａは、メモリ１１８（図１）の文脈で説明されたものであってもよい。
【0022】
ユーザーデータはさらに、ユーザーの固有性（identity）を表す識別子（例えば、ユーザーＩＤ）を示す別のデータフィールドを含んでもよい。
【0023】
様々な実施形態では、通信サーバ装置２０２ａが、履歴データが存在すると判定することに応答して、さらに、推奨される目的地として第２の関心地点を判定するために、時間（時点）（例えば、現在の時間（時点）または予定された時間（時点））を示すデータフィールドを有するユーザーデータ（ユーザーの位置を示すデータフィールドを有する同じユーザーデータであってもよい）を受信することに応答して、通信サーバ装置２０２ａは履歴データに基づいて、第２の関心地点が時間を含む所定の時間間隔（例えば、１日のうちの数時間）に第１の関心地点と対にされることを判定するようにさらに構成されてもよい。時刻は例えば、予約が行われた時刻、または、輸送関連サービスの開始時刻であってもよい。
【0024】
以下の例に限定されないが、時間は午後３時０５分であってもよく、例えば、過去の３時～３時３０分、または３時～４時００分（例えば、過去２４時間以上）の間隔で第１の関心地点と対になっている第２の関心地点は、推奨目的地（recommended destination location）として決定されてもよい。
【0025】
様々な実施形態では、通信サーバ装置２０２ａが、履歴データがあると判定し、さらにユーザーの位置を示すデータフィールドを受信することに応答して、第１の関心地点を判定するために、通信サーバ装置２０２ａは履歴データに含まれる輸送関連サービスの１つ以上の履歴出発地を示すデータがあるかどうかを判定するように構成されてもよく、１つ以上の履歴出発地を示すデータがあると判定された場合、１つ以上の履歴出発地を示すデータに基づいて、第１の関心地点としてユーザーの位置に距離が最も近い履歴出発地を定義し、ユーザー通信装置による受信のために、履歴出発地を示すデータを送信し、１つ以上の履歴出発地を示すデータがないと判定された場合、１つ以上の履歴出発地（または１つ以上の最後のドロップオフ先）を示すデータを判定する。履歴データに含まれる（ＬＤＦ）は１つ以上の履歴目的地（historical destination location）を示すデータに基づいて、第１の関心地点としてユーザーの位置に距離が最も近い履歴目的地を定義し、ユーザー通信装置による受信のために、履歴目的地を示すデータを送信する。
【0026】
様々な実施形態では、１つ以上の履歴目的地を示すデータを決定するために、通信サーバ装置２０２ａは所定の履歴期間（historical period of time）（例えば、過去２４時間）に関連付けられた１つ以上の履歴目的地を示すデータを決定するように構成されてもよい。
【0027】
図２Ｂは、通信サーバ装置のプロセッサの制御下で、輸送関連サービスの１つ以上の関心地点をユーザーに推奨するために、通信サーバ装置において実行される方法を示すフローチャート２５０である。
【0028】
ユーザーの位置を示すデータフィールドを含むユーザーデータを受信し、さらに、輸送関連サービスに対応するユーザーに関連する履歴データがないと判断したことに応答して、２５１において、位置を有するマップのデータが検索され、２５２において、マップを表すデータがユーザーのユーザー通信装置によって受信されるために、ユーザー通信装置を介して、輸送関連サービスの推奨出発地としてマップ上の関心地点の決定のためにマップをユーザーに提示するために、マップが送信される。
【0029】
１つ以上のデータレコード内に輸送関連サービスに対応する履歴データがあると判定することに応答して、履歴データはユーザーに関連し、２５５において、履歴データに基づいて輸送関連サービスの推奨出発地として、第１の関心地点が決定され、２５６において、履歴データに基づいて、輸送関連サービスの推奨目的地として、第２の関心地点が決定され、第１の関心地点および第２の関心地点は履歴輸送関連サービスに対応して互いに対をなし、２５７において、第１の関心地点を示すデータおよび第２の関心地点を示すデータがユーザー通信装置によって受信されるために送信される。
【0030】
２５６において、履歴データが存在すると判定することに応答して、さらに、時間を示すデータフィールドを含むユーザーデータを受信することに応答して、本方法は、履歴データに基づいて、第２の関心地点が時間を含む所定の時間間隔において第１の関心地点と対になることを判定することを含むことができる。
【0031】
様々な実施形態では、２５５において、履歴データがあると判定することに応答し、さらに、ユーザーの位置を示すデータフィールドを含むユーザーデータを受信することに応答して、本方法は、履歴データに含まれる輸送関連サービスの１つ以上の履歴出発地を示すデータがあるかどうかを判定することと、１つ以上の履歴出発地を示すデータがあると判定された場合、１つ以上の履歴出発地を示すデータに基づいて、第１の関心地点としてユーザーの位置に距離が最も近い履歴出発地を規定することと、ユーザー通信装置による受信のために、履歴出発地を示すデータを送信することと、１つ以上の履歴出発地を示すデータがないと判定された場合、履歴データに含まれる１つ以上の履歴目的地を示すデータを判定することと、１つ以上の履歴目的地を示すデータに基づいて、履歴目的地を規定することとを含むことができる。第１の関心地点として、ユーザーの位置に距離が最も近い位置、およびユーザー通信装置による受信のために、履歴目的地を示すデータを送信する。
【0032】
様々な実施形態では、１つ以上の履歴目的地を示すデータを決定するために、本方法は、所定の履歴期間に関連する１つ以上の履歴目的地を示すデータを決定することを含むことができる。
【0033】
様々な実施形態はさらに、通信サーバ装置（例えば、２０２ａ、図２Ａ）を有する、輸送関連サービスのための１つ以上の関心地点をユーザーに推奨するための通信システムと、通信サーバ装置およびそれを介して相互の通信を確立するための少なくも１つのユーザー装置のために動作可能な少なくとも１つのユーザー通信装置およびネットワーク機器と、を提供することができる。ここで、少なくとも１つのユーザー通信装置は、第１のプロセッサと、第１のメモリとを含み、少なくとも１つのユーザー通信装置は、第１のプロセッサの制御下で、第１のメモリ内の第１の命令を実行して、処理を行うために通信サーバ装置によって受信されるために、ユーザーの位置を示すデータフィールドを含むユーザーデータを送信するように構成され、通信サーバ装置は第２のプロセッサと、第２のメモリとを含み、第２のプロセッサの制御下で、第２の命令を実行するように構成されている通信サーバ装置は、少なくとも１つのユーザー通信装置によって送信されたユーザーデータを示すデータの受信に応答して、さらに、通信サーバ装置が、輸送関連サービスに対応するユーザーに関連付けられた履歴データがない、と判断したことに応答して、位置を含むマップを表すデータを検索し、少なくとも１つのユーザー通信装置によって受信されるために、ユーザー通信装置を介してマップを提示するためのマップを表すデータをユーザーに送信し、マップ上の関心地点を輸送関連サービスの推奨出発地として決定し、通信サーバ装置が１つ以上のデータレコード内に輸送関連サービスに対応する履歴データがあると判断したことに応答して、ユーザーに関連付けられている履歴データは、履歴データに基づいて、輸送関連サービスの推奨出発地として第１の関心地点を決定し、履歴データに基づいて、輸送関連サービスの推奨目的地としての第２の関心地点を決定し、第１の関心地点および第２の関心地点は、関心対象は履歴輸送関連サービスに対応して互いに対をなし、少なくとも１つのユーザー通信装置による受信のために、第１の関心地点を示すデータと、第２の関心地点を示すデータとを送信する。
【0034】
なお、通信サーバ装置２０２ａ、フローチャート２５０の文脈で説明されている方法、およびこれに対応する通信システムは、互いに適用可能であることに留意する必要がある。
【0035】
通信サーバ装置２０２ａの文脈で上述した技術、フローチャート２５０の文脈で説明した方法、および上述した対応する通信システムは、以下でさらに説明するアクション／シナリオ（action/scenario）「予測（Predict）」に対応することができる。さらに、前記技術は輸送関連サービスに対応する（ソフトウェア）アプリケーション（例えば、「Ａｐｐ」）のアクティベーションまたは起動、またはアクティベーションまたは起動の検出（または決定）に応答して実行されてもよく、またはユーザーが輸送関連サービスのリクエストまたは予約を行うプロセスの開始時に実行されてもよい。
【0036】
図２Ｃは、輸送関連サービスの１つ以上の関心地点（ＰＯＩ）をユーザーに推奨するための通信サーバ装置２０２ｃを示す概略ブロック図である。通信サーバ装置２０２ｃは、プロセッサ２１６ｃおよびメモリ２１８ｃを含み、通信サーバ装置２０２ｃは、プロセッサ２１６ｃの制御下で、ユーザーの位置（例えば、現在の位置または予想された位置）を示す第１のデータフィールド（例えば、緯度（ｌａｔ）値および経度（ｌｎｇ）値を示すデータ）を含むユーザーデータの受信に応答して、メモリ２１８ｃ内の命令を実行するように構成され、目的地（またはドロップオフ位置）に対応するユーザーリクエストを示す第２のデータフィールドを含み、１つ以上のデータレコード内の輸送関連サービスに対応する履歴データにアクセスし、ユーザーに関連付けられている履歴データを含み、位置を含む地域（例えば、都市）において、少なくとも１つの目的地カテゴリ（例えば、ショッピングの目的地、食品店、交通ハブ等）における最上位の関心地点（例えば、最も人気度のあるＰＯＩ；上位３、上位５、または他の数）の数を示すデータにアクセスし、履歴データおよび上位関心地点の数を示すデータに基づいて、輸送関連サービスの目的地として推奨される一つ以上の関心の第１の関心地点を決定し、ユーザー通信装置による受領のために、一つ以上の第１の関心地点を示すデータ２５５ｃを送信する。
【0037】
プロセッサ２１６ｃおよびメモリ２１８ｃは（ライン２１７ｃによって表されるように）互いに結合されてもよく、例えば、物理的に結合されてもよく、および／または電気的に結合されてもよい。プロセッサ２１６ｃはプロセッサ１１６（図１）の文脈で説明されてもよいし、メモリ２１８ｃは、メモリ１１８（図１）の文脈で説明されてもよい。
【0038】
ユーザーデータはさらに、ユーザーの固有性（identity）を表す識別子（例えば、ユーザーＩＤ）を示す別のデータフィールドを含んでもよい。
【0039】
目的地に対応するユーザーリクエストを示す第２のデータフィールドは、輸送関連サービス（例えば、目的地の入力データフィールド）に対応する（ソフトウェア）アプリケーション（例えば、“Ａｐｐ”）の入力ボックスまたは入力データフィールドをユーザーがクリックすることに対応してもよい。
【0040】
様々な実施形態の文脈では、履歴データが多数の履歴目的地を示すデータ、および／またはユーザーの１つ以上の好みを示すデータを含むことができる。
【0041】
様々な実施形態では履歴データがユーザーによって最も頻繁に使用されるいくつかの履歴目的地（例えば、最も頻繁に使用される３つの位置、最も頻繁に使用される５つの位置、または任意の他の数）を示すデータを含むことができ、履歴データにアクセスするために、通信サーバ装置２０２ｃはユーザーによって最も頻繁に使用される履歴目的地の数を示すデータにアクセスするようにさらに構成することができ、１つ以上の第１の関心地点を決定するために、通信サーバ装置２０２ｃは、ユーザーによって最も頻繁に使用される履歴目的地の数を示すデータと最上位の関心地点の数を示すデータとに基づいて、１つ以上の第１の関心地点を決定するようにさらに構成することができる。
【0042】
通信サーバ装置２０２ｃはさらに、出発地（またはピックアップ位置）に対応するユーザーリクエストを示すデータフィールドを含むユーザーデータ（上記と同じユーザーデータまたは別のユーザーデータであってもよい）を受信することに応答して、履歴データおよび位置に基づいて、輸送関連サービスの推奨出発地として１つ以上の第２の関心地点を決定し、ユーザー通信装置による受信のために、１つ以上の第２の関心地点を示すデータを送信するように構成されてもよい。
【0043】
履歴データは、多数の履歴出発地を示すデータを含むことができ、１つ以上の第２の関心地点は、履歴出発地の数に基づいて決定することができる。
【0044】
出発地に対応するユーザーリクエストを示すデータフィールドは、輸送関連サービス（例えば、出発地の入力データフィールド）に対応する（ソフトウェア）アプリケーション（例えば、「Ａｐｐ」）の入力ボックスまたは入力データフィールドをユーザーがクリックしたことに対応してもよい。
【0045】
１つ以上の第２の関心地点を決定するために、通信サーバ装置２０２ｃは、ユーザーの位置に対して所定の距離内にある１つ以上の第２の関心地点を推奨出発地として決定するように構成されてもよい。
【0046】
通信サーバ装置２０２ｃは、さらに、１つ以上の第２の関心地点のそれぞれについて、ユーザー通信装置による受信のために、第２の関心地点とユーザーの位置との間の距離を示すデータを送信するように構成されてもよい。
【0047】
図２Ｄは、通信サーバ装置のプロセッサの制御下で、輸送関連サービスの１つ以上の関心地点をユーザーに推奨するために、通信サーバ装置において実行される方法を示すフローチャート２６０である。
【0048】
位置を示す第１のデータフィールドと、目的地を示すユーザーリクエストを示す第２のデータフィールドと、を含むユーザーデータを受信すると、２６２において、１つ以上のデータレコードに対応する輸送関連サービスに対応する履歴データがアクセスされ、２６４において、位置を有する地域における少なくとも１つの目的地カテゴリにおける最上位の関心地点の数を示すデータがアクセスされ、２６６において、履歴データと、最上位のランキングポイントの数を示すデータとに基づいて、輸送関連サービスに対して推奨される目的地としての１つ以上の第１の関心地点が決定され、２６８において、ユーザー通信装置によって受信される１つ以上の第１の関心地点を示すデータが送信される。
【0049】
様々な実施形態では、履歴データがユーザーによって最も頻繁に使用される多数の履歴目的地を示すデータを含むことができる。２６２では、ユーザーによって最も頻繁に使用される履歴目的地の数を示すデータがアクセスされ、２６６では、ユーザーによって最も頻繁に使用される履歴目的地の数を示すデータと、最上位の関心地点の数を示すデータとに基づいて、１つ以上の第１の関心地点が決定される。
【0050】
出発地に対応するユーザーリクエストを示すデータフィールドを含むユーザーデータを受信することに応答して、本方法は、履歴データおよび位置に基づいて、輸送関連サービスの推奨出発地として１つ以上の第２の関心地点を決定することと、ユーザー通信装置による受信のために、１つ以上の第２の関心地点を示すデータを送信することと、をさらに含むことができる。
【0051】
様々な実施形態では、本方法が推奨される出発地として、ユーザーの位置に対して所定の距離内にある１つ以上の第２の関心地点を決定することを含むことができる。
【0052】
様々な実施形態では、本方法が１つ以上の第２の関心地点のそれぞれについて、ユーザー通信装置による受信のために、第２の関心地点とユーザーの位置との間の距離を示すデータを送信することをさらに含むことができる。
【0053】
様々な実施形態は、ユーザーに輸送関連サービスの１つ以上の関心地点を推奨するための通信システムをさらに提供することができ、通信サーバ装置（例えば、図２Ｃの２０２ｃ）と、少なくとも１つのユーザー通信装置と、ネットワーク機器と、を有し、通信サーバ装置および少なくとも１つのユーザー通信装置が互いに通信を確立するように動作可能であり、少なくとも１つのユーザー通信装置が第１のプロセッサおよび第１のメモリを含み、少なくとも１つのユーザー通信装置は、第１のプロセッサの制御下で、第１のメモリ内の第１の命令を実行して、処理を行うために通信サーバ装置によって受信されるために、位置を示す第１のデータフィールドと、目的地に対応するユーザーリクエストを示す第２のデータフィールドと、を含むユーザーデータを送信するように構成され、通信サーバ装置は、第２のプロセッサおよび第２のメモリを含み、通信サーバ装置は、第２のプロセッサの制御下で、第２のメモリ内の第２の命令を実行するように構成される。少なくとも１つのユーザー通信装置によって送信されたユーザーデータを示すデータの受信に応答して、１つ以上のデータレコード内の輸送関連サービスに対応する履歴データにアクセスするステップであって、履歴データはユーザーに関連付けられ、位置を含む地理的エリア内の少なくとも１つの目的地カテゴリ内のいくつかの関心地点の最上位の数を示すデータにアクセスするステップと、履歴データと関心地点の最上位の数を示すデータとに基づいて、輸送関連サービスの推奨される目的地としての１つ以上の第１の関心地点を決定し、少なくとも１つのユーザー通信装置による受信のために、１つ以上の第１の関心地点を示すデータを送信する。
【0054】
通信サーバ装置２０２ｃ、フローチャート２６０の文脈で説明した方法、および上述した対応する通信システムの文脈での説明は、互いに適用可能であることを理解されたい。
【0055】
通信サーバ装置２０２ｃに関連して上述した技術、フローチャート２６０に関連して説明した方法、および上述した対応する通信システムは、以下にさらに説明するアクション／シナリオ「提案（Suggest）」に対応することができ、さらに、これらの技術はシナリオ「予測」の後に、例えば、シナリオ「予測」から得られた結果が輸送関連サービスのリクエストまたは予約を行うユーザーにとって期待されるものではないかまたは満足のいくものではない場合、順次実行することができる。
【0056】
図２Ｅは、輸送関連サービスの１つ以上の関心地点（ＰＯＩ）をユーザーに推奨するための通信サーバ装置２０２ｅを示す概略ブロック図であり、図２Ｆは、通信サーバ装置２０２ｅによって生成され得るデータレコード２４０を示す概略ブロック図である。
【0057】
通信サーバ装置２０２ｅは、プロセッサ２１６ｅおよびメモリ２１８eを含み、プロセッサ２１６ｅの制御下に、ユーザー（例えば、現在の位置された位置または予想された位置）の位置（緯度（ｌａｔ）値および経度（ｌｎｇ）値を示すデータを示す第１のデータフィールドと、ユーザーによって入力された情報（輸送関連サービスの出発地または目的地として、ユーザーによってリクエストされた位置の少なくとも部分的に記述）を示す入力データを有する第２のデータフィールドと、を含むユーザーデータを受信することに応じて、メモリ２１８ｅ内の命令を実行し、入力データに基づいて、対応する複数の関心地点候補に対してデータ２４３ａ、２４３ｂ、２４３ｃ～２４３ｎを有する複数の候補データフィールド２４２ａ、２４２ｂ、２４２ｃ～２４２ｎを有する１つ以上のデータレコード２４０を生成し、複数の候補データフィールド２４２ａ、２４２ｂ、２４２ｃ～２４２ｎの各々の候補データフィールドと、キーワード、領域、人気度、タイミング、距離の少なくとも２つの基準に対するそれぞれの基準データフィールド（非限定的な例として、候補データフィールド２４２ａに対する基準データフィールド２４４ａおよび２４６ａ、候補データフィールド２４２ｃに対する基準データフィールド２４４ｃおよび２４６ｃ）と、距離と、に対して１つ以上のデータレコード２４０を生成し、それぞれの基準データフィールド（例えば２４４ａ、２４６ａ、２４４ｃ、２４６ｃ）の各基準データフィールドにおいて、対象の候補関心地点（非限定的な例として、基準データフィールド２４４ａ、２４６ａ、２４４ｃ、２４６ｃに対するデータ２４５ａ、２４７ｃ、２４５ｃ、２４７ｃ）に対応する基準に関連する個々のスコアを示すデータを生成する。
【0058】
キーワードについて、個人スコアは、情報と、候補関心地点の名前を記述する１つ以上の単語（例えば、フルネーム、部分名、頭字語（acronym））と、の間の類似性に基づいて決定される。領域の場合、個々のスコアはユーザーの位置を含む第１の地域（例えば、都市）と、対象地点の候補を含む第２の地域（例えば、都市）と、の間の近接性に基づいて決定される。人気度については、１つ以上の履歴データレコード内の輸送関連サービスに対応する履歴データに基づいて、個々のスコアは（例えば、任意の１つ以上のユーザーによって、すなわち、輸送関連サービスのリクエストを行うユーザーを含むだけでなく、（１つ以上の）他のユーザーの好みも考慮に入れて）履歴輸送関連サービスのリクエストされた位置として（例えば、候補関心地点は、履歴出発地として選択された時間の数（リクエストされた位置が出発地の場合）または履歴目的地として選択された時間の数（リクエストされた位置が目的地の場合）である）履歴的に選択された時間の数に基づいて決定される。タイミングについては、１つ以上の履歴データレコード（上述の履歴データレコードと同じ履歴データレコードであってもよい）内の輸送関連サービスに対応する履歴データに基づいて、個々のスコアは、定義された時間にユーザーによってリクエストされた位置（出発地または目的地）として選択される候補関心地点の確率（例えば、朝、夕方、または定義された期間中／時間中などに選択される候補関心地点の確率）に基づいて決定される。距離については、ユーザーの位置と候補関心地点との間の距離に基づいて、個々のスコアが決定される。
【0059】
通信サーバ装置２０２ｅは、各候補データフィールド２４２ａ、２４２ｂ、２４２ｃ、２４２ｎについて、（少なくとも２つの基準について決定された）個々のスコアに基づいて、対応する候補関心地点についての結果スコアを生成し、結果スコアを示すデータを処理し、ユーザー通信装置による受信のために、結果スコアを示すデータの処理の結果に従って、ユーザー通信装置を介して、複数の候補関心地点を提示するための複数の候補関心地点を示すデータ２５５ｅを送信するように構成される。様々な実施形態では、通信サーバ装置２０２ｅから送信されるデータ２５５ｅについて、複数の関心地点候補は、処理の結果に従って既に順序付けられていてもよい。
【0060】
プロセッサ２１６ｅおよびメモリ２１８ｅは（ライン２１７ｅによって表されるように）互いに結合されてもよく、例えば、物理的に結合されてもよく、および／または電気的に結合されてもよい。プロセッサ２１６ｅはプロセッサ１１６（図１）の文脈で説明されてもよいし、メモリ２１８ｅは、メモリ１１８（図１）の文脈で説明されてもよい。
【0061】
ユーザーデータはさらに、ユーザーの固有性（identity）を表す識別子（例えば、ユーザーＩＤ）を示す別のデータフィールドを含んでもよい。
【0062】
通信サーバ装置２０２ｅは時間（時点）（例えば、現在の時間（時点）または予想された時間（時点）または予定された時間（時点））を示すデータフィールドを含むユーザーデータ（第１および第２のデータフィールドを有する同じユーザーデータであってもよい）を受信してもよい。
【0063】
非限定的な例として、リクエストされた位置は８文字のストリングを有するフルネームによって表され、または記述されてもよく、入力された情報は名前の一部（例えば、（単に）フル８文字の最初の５文字、フルネーム（すなわち、８文字）、またはリクエストされた位置を表す頭字語を含んでもよい。
【0064】
ｙ≧２（すなわち、２以上）である任意の数ｙの候補データフィールドが存在し得ることを理解されたい。
【0065】
結果スコアを示すデータを処理するために、通信サーバ装置２０２ｅは、結果スコアを示すデータに基づいて、１つ以上のデータレコード２４０において、複数の候補関心地点の結果スコアに従った複数の候補関心地点の順序を示すランキングデータ（例えば、結果スコアの降順）を生成し、データを送信するために、通信サーバ装置２０２ｅは、ランキングデータに従った順序で、ユーザー通信装置を介して、複数の候補関心地点の提示のための複数の候補関心地点を示すデータ２５５ｅを送信するように構成され得る。様々な実施形態では、通信サーバ装置２０２ｅから送信されるデータ２５５ｅについて、複数の関心地点候補は、ランキングデータに従って既に順序付けられていてもよい。
【0066】
結果スコアを示すデータを処理するために、通信サーバ装置２０２ｅは、結果スコアを示すデータに基づいて、複数の候補関心地点の各候補関心地点について、結果スコアを、リクエストされた位置に対する候補関心地点の一致関連性を示す閾値と比較するように構成されてもよく、データを送信するために、通信サーバ装置２０２ｅは、結果スコアが閾値以上であると判定された候補関心地点を示すデータ２５５ｅを送信するように構成されてもよい。
【0067】
結果スコアを生成するために、通信サーバ装置２０２ｅは、個々のスコアの加重和によって結果スコアを生成するように構成されてもよい。
【0068】
様々な実施形態では、少なくとも２つの基準が領域を含んでもよく、第１の地域および第２の地域が異なる国にあることを示すと判定された、地域に関する個々のスコアに応じて、通信サーバ機器２０２ｅは候補関心地点を除外する（または無視する）ようにさらに構成することができる。
【0069】
それぞれの基準データフィールド（例えば、２４４ａ、２４６ａ、２４４ｃ、２４６ｃ）を生成するために、通信サーバ機器２０２ｅは、それぞれの候補データフィールド２４２ａ、２４２ｂ、２４２ｃ～２４２ｎについて、キーワード、領域、人気度、タイミング、および距離のうちの少なくとも３つの基準のためにそれぞれの基準データフィールドを生成するように構成されてもよい。
【0070】
それぞれの基準データフィールド（例えば、２４４ａ、２４６ａ、２４４ｃ、２４６ｃ）を生成するために、通信サーバ機器２０２ｅは、それぞれの候補データフィールド２４２ａ、２４２ｂ、２４２ｃ～２４２ｎについて、キーワード、領域、人気度、タイミング、および距離の少なくとも４つの基準のためにそれぞれの基準データフィールドを生成するように構成されてもよい。
【0071】
様々な実施形態では、それぞれの基準データフィールド（例えば、２４４ａ、２４６ａ、２４４ｃ、２４６ｃ）を生成するために、情報が出発地としてリクエストされた位置を少なくとも部分的に記述していることに応じて、通信サーバ機器２０２ｅは、それぞれの候補データフィールド２４２ａ、２４２ｂ、２４２ｃ～２４２ｎについて、キーワード、領域、人気度、タイミング、および距離のすべての基準のためにそれぞれの基準データフィールドを生成するように構成されてもよい。
【0072】
図２Ｇは、通信サーバ装置のプロセッサの制御下で、輸送関連サービスの１つ以上の関心地点をユーザーに推奨するために、通信サーバ装置において実行される方法を示すフローチャート２７０である。
【0073】
ユーザーの位置を示す第１のデータフィールドと、ユーザーによって入力された情報を示す入力データを有する第２のデータフィールドと、を含むユーザーデータを受信することに応答して、２７２において、１つ以上のデータレコードが入力データに基づいて生成され、１つ以上のデータレコードは、対応する複数の候補関心地点のデータを有する複数の候補データフィールドを含む。２７４において、複数の候補データフィールドの候補データフィールドごとに、キーワード、領域、人気度、タイミング、距離の少なくとも２つの基準について、それぞれの基準データフィールドが、１つ以上のデータレコード内に生成される。２７６において、それぞれの基準データフィールドのそれぞれの基準データフィールドにおいて、対応する基準に関連付けられた個々のスコアを示すデータが候補関心地点について生成される。ここで、キーワードについて、個々のスコアは、情報と候補関心地点の名前を記述する１つ以上の単語との間の類似性に基づいて決定される。領域について、個々のスコアは、人気度について、ユーザーの位置を含む第１の地域と、候補関心地点を含む第２の地域と、の間の近接性に基づいて決定され、１つ以上の履歴データレコードにおける輸送関連サービスに対応する履歴データに基づいて決定され、個人スコアは１つ以上の履歴データレコードにおける輸送関連サービスに対応する履歴データに基づいて決定される。タイミングについて、候補関心地点が履歴輸送関連サービスについてリクエストされた位置として履歴的に選択される時間の数に基づいて決定され、個人スコアはユーザーに関連付けられている。候補関心地点は、定義された時間にリクエストされた位置としてユーザーによって選択される確率に基づいて決定され、その距離について、個々のスコアはユーザーの位置と候補関心地点との間の距離に基づいて決定される。２７８において、各候補データフィールドについて、個々のスコアに基づいて、対応する候補関心地点について結果スコアが生成される。２８０において、得られたスコアを示すデータが処理される。２８２において、ユーザー通信装置による受信のために、結果スコアを示すデータの処理の結果に従って、ユーザー通信装置を介して、複数の候補関心地点を提示するために、複数の候補関心地点を示すデータが送信される。様々な実施形態では、送信されるべき複数の候補関心地点を示すデータについて、複数の候補関心地点は処理の結果に従って既に順序付けられていてもよい。
【0074】
様々な実施形態では、２８０において、結果スコアを示すデータに基づいて、１つ以上のデータレコードにおいて、複数の候補関心地点の結果スコアに従って複数の候補関心地点の順序を示すランキングデータを生成することができ、２８２において、複数の候補関心地点を示すデータを、ユーザー通信装置を介して、ランキングデータに従って順序付けて、複数の候補関心地点の提示のために送信することができる。様々な実施形態では、送信されるべき複数の候補関心地点を示すデータについて、複数の候補関心地点はランキングデータに従って既に順序付けられていてもよい。
【0075】
様々な実施形態では、２８０において、結果スコアを示すデータに基づいて、複数の候補関心地点の各候補関心地点について、結果スコアを、リクエストされた位置に対する候補関心地点の一致関連性を示す閾値と比較することができ、２８２において、閾値以上であると判定された結果スコアを有する候補関心地点を示すデータを送信することができる。
【0076】
様々な実施形態では、２７８において、得られたスコアは個々のスコアの加重和によって生成されてもよい。
【0077】
様々な実施形態では少なくとも２つの基準が領域を含んでもよく、第１の地域および第２の地域が異なる国にあることを示すと判定された、地域に関する個々のスコアに応じて、本方法は、候補関心地点を除外することをさらに含むことができる。
【0078】
様々な実施形態では、２７４において、それぞれの候補データフィールドについて、キーワード、領域、人気度、タイミング、および距離のうちの少なくとも３つの基準について、それぞれの基準データフィールドを生成することができる。
【0079】
様々な実施形態では、２７４において、それぞれの候補データフィールドについて、キーワード、領域、人気度、タイミング、および距離のうちの少なくとも４つの基準について、それぞれの基準データフィールドを生成することができる。
【0080】
様々な実施形態では、２７４において、それぞれの候補データフィールドについて、リクエストされた位置を出発地として少なくとも部分的に記述する情報に応じて、それぞれの基準データフィールドを、キーワード、領域、人気度、タイミング、および距離のすべての基準について生成することができる。
【0081】
様々な実施形態は、通信サーバ装置（例えば、２０２ｅ、図２Ｅ）と、少なくとも１つのユーザー通信装置と、通信サーバ装置および少なくとも１つのユーザー通信装置が互いに通信を確立するように動作可能な通信ネットワーク機器と、を有し、ユーザーに輸送関連サービスの１つ以上の関心地点を推奨する通信システムをさらに提供することができ、少なくとも１つのユーザー通信装置は第１のプロセッサおよび第１のメモリを含み、少なくとも１つのユーザー通信装置は第１のプロセッサの制御下で、第１のメモリ内の第１の命令を実行して、処理のために通信サーバ装置によって受信されるために、ユーザーの位置を示す第１のデータフィールドと、ユーザーによって入力された情報（輸送関連サービスの出発地または目的地として、ユーザーによってリクエストされた位置を少なくとも部分的に記述）を示す入力データを有する第２のデータフィールドとを含むユーザーデータを送信するように構成され、通信サーバ装置は第２のプロセッサおよび第２のメモリを含み、通信サーバ装置は、第２のプロセッサの制御下で、第２のメモリ内の第２の命令を実行するように構成され、前記少なくとも１つのユーザー通信装置によって送信されたユーザーデータを示すデータを受信することに応答して、入力データに基づいて、対応する複数の候補関心地点についてのデータを有する複数の候補データフィールドを含む１つ以上のデータレコードを生成し、１つ以上のデータレコード内で、複数の候補データフィールドの各候補データフィールドについて、キーワード、領域、人気度、タイミング、および距離のうち少なくとも２つの基準についてのそれぞれの基準データフィールドを生成し、それぞれの基準データフィールドの各基準データフィールド内で、候補関心地点についての対応する基準に関連する個々のスコアを示すデータを生成し、キーワードについて、情報と候補関心地点の名前を記述する１つ以上の単語との間の類似性に基づいて個々のスコアが決定され、領域について、ユーザーの位置を含む第１の地域と、人気度を含む第２の地域との間の近接性に基づいて個人スコアが決定され、人気度について、１つ以上の履歴データレコード内の輸送関連サービスのリクエストされた位置として履歴的に選択される時間の数に基づいて個人スコアが決定され、タイミングについて、１つ以上の履歴データレコード内の輸送関連サービスに対応する履歴データに基づいて、履歴的に選択され、履歴データはユーザーに関連付けられ、個人スコアは指定された時間にリクエストされた位置としてユーザーによって選択される候補関心地点の確率に基づいて個人スコアが決定され、距離について、ユーザーの位置と候補関心地点との間の距離に基づいて個人スコアが決定され、各候補データフィールドについて、対応する候補関心地点についての結果スコアを生成し、個々のスコアに基づいて関心対象を処理し、結果スコアを示すデータを処理し、結果スコアを示すデータの処理結果に従って、ユーザー通信装置による受信のために、複数の候補関心地点の提示のための複数の候補関心地点を示すデータを、ユーザー通信装置を介して送信する。
【0082】
なお、通信サーバ装置２０２ｅの文脈における記述、フローチャート２７０の文脈で説明されている方法、および対応する前述の通信システムは、互いに適用可能であることを理解すべきである。
【0083】
通信サーバ装置２０２ｅの文脈で上述した技術、フローチャート２７０の文脈で説明した方法、および上述した対応する通信システムは以下にさらに説明するアクション／シナリオ「検索（Search）」に対応することができ、さらに、これらの技術はシナリオ「提案」の後に、例えば、シナリオ「提案」から得られた結果が輸送関連サービスのリクエストまたは予約を行うユーザーにとって期待されるものではないかまたは満足のいくものではない場合、順次実行することができる。
【0084】
図２Ｈは輸送関連サービスの１つ以上の関心地点をユーザーに推奨するための通信サーバデバイス２０２ｈを示す概略ブロック図であり、通信サーバデバイス２０２ｈは通信サーバ装置２０２ａとして構成され、さらに、通信サーバ装置２０２ｃまたは通信サーバ装置２０２ｅのうちの少なくとも１つとして構成される。
【0085】
なお、通信サーバ装置２０２ｈは、通信サーバ装置２０２ａとして構成されてもよく、その後（順次）、通信サーバ装置２０２ｃとしてさらに構成されてもよい。なお、通信サーバ装置２０２ｈは、その後（順次）、通信サーバ装置２０２ｅとしてさらに構成されてもよい。通信サーバデバイス２０２ｈは、その後（順次）、ユーザーの位置を含むマップを表すデータを検索し、ユーザーのユーザー通信装置による受信のために、マップ上の（単一の）関心地点の決定のために（例えば、ユーザーの位置に基づいて）、輸送関連サービスの推奨される出発地（またはピックアップ位置）として、ユーザー通信装置を介してユーザーにマップを提示するためのマップを表すデータを送信するようにさらに（連続的に）構成され得る。
【0086】
図２Ｉは通信サーバ装置のプロセッサの制御下で、ユーザーに輸送関連サービスの１つ以上の関心地点を推奨するために、通信サーバ装置において実行される方法を示すフローチャート２９０を示す。２９２において、フローチャート２５０の文脈で本明細書に記載された方法が実行される。２９４では、フローチャート２６０の文脈で本明細書に記載される方法またはフローチャート２７０の文脈で本明細書に記載される方法のうちの少なくとも１つが実行される。
【0087】
様々な実施形態では、フローチャート２５０の文脈で本明細書に記載された方法を実行することができ、その後、フローチャート２６０の文脈で本明細書に記載された方法を実行することができる。その後、フローチャート２７０の文脈で本明細書に記載される方法が実行されてもよい。その後、ユーザーの位置を含むマップを表すデータを検索することができ、マップを表すデータを、ユーザーのユーザー通信装置による受信のために送信して、マップ上の関心地点を輸送関連サービスの推奨出発地として決定するために、ユーザー通信装置を介してマップをユーザーに提示することができる。
【0088】
なお、様々な実施形態では、通信サーバ装置（例えば、２０２ｈ、図２Ｈ）と、プロセッサおよびメモリを含む少なくとも１つのユーザー通信装置と、通信サーバ装置および少なくとも１つのユーザー通信装置がそれを介して互いに通信を確立するために動作可能な通信ネットワーク機器と、を有し、輸送関連サービスのための１つ以上の関心地点をユーザーに推奨するための通信システムをさらに提供することができ、通信サーバ装置が通信サーバ装置２０２ａとして構成され、少なくとも１つのユーザー通信装置が、前記プロセッサの制御下で、メモリ内の命令を実行するように構成され、当該少なくとも１つのユーザー通信装置は、ユーザーの所在地を示すデータフィールドを含むユーザーデータを、処理のために通信サーバ装置によって受信されるために送信する命令をメモリ内で実行し、通信サーバ装置は、前記少なくとも１つのユーザー通信装置が、前記プロセッサの制御下で、処理のために通信サーバ装置によって受信されるため、位置を示す第１のデータフィールドと、目的地に対応するユーザーリクエストを示す第２のデータフィールドと、を含むユーザーデータを送信する命令をメモリ内で実行する通信サーバ装置２０２ｃ、または、前記少なくとも１つのユーザー通信装置が、前記プロセッサの制御下で、処理のために通信サーバ装置によって受信されるため、ユーザーの所在地を示す第１のデータフィールドと、ユーザーが入力した情報を示す入力データフィールドを有する第２のデータフィールドと、を含むユーザーデータを送信する命令をメモリ内で実行する通信サーバ通信装置２０２ｅの少なくとも１つとして構成され、前記情報は、輸送関連サービスの出発地または目的地としてユーザーによってリクエストされる所在地の少なくとも一部を記述した情報である。
【0089】
また、フローチャート２５０、２６０、２７０、２９０の文脈で本明細書に記載される方法のうちの少なくとも１つを実施するための命令を有するコンピュータプログラム製品が提供されてもよい。
【0090】
また、フローチャート２５０、２６０、２７０、２９０の文脈で本明細書に記載される方法のうちの少なくとも１つを実施するための命令を有するコンピュータプログラムが提供されてもよい。
【0091】
さらに、命令を記憶する非一時的記憶媒体を提供することができ、命令はプロセッサによって実行されると、プロセッサに、フローチャート２５０、２６０、２７０、２９０の文脈で本明細書において説明する方法のうちの少なくとも１つを実行させる。
【0092】
様々な実施形態の文脈では、履歴データが１つ以上の（履歴）データレコード（(historical) data record）に格納されてもよい。
【0093】
様々な実施形態の文脈では、履歴データが１つ以上のデータベースに格納されてもよい。
【0094】
様々な実施形態の文脈では、履歴データが所定の期間の履歴データ（記憶された）、例えば、過去３０日間の履歴データであってもよい。
【0095】
様々な実施形態の文脈では、ユーザー通信装置は、スマートフォン、タブレット、携帯／ポータブル通信装置、デスクトップまたはラップトップコンピュータ、端末コンピュータ等を含むことができるが、これらに限定されない。
【0096】
様々な実施形態の文脈では、輸送関連サービスは、乗り物輸送サービス（ride-hailing transportation service）を含んでもよく、または乗り物輸送サービスであってもよい。これには、例えば、カー・ヘイリング（car-hailing）、および（モータ）バイク・ヘイリング・サービス（(motor)bike-hailing service）が含まれる。
【0097】
様々な実施形態の文脈では、輸送関連サービスが１つ以上の自律走行車（autonomous vehicle）を含むことができる。
【0098】
様々な実施形態の文脈では、「Ａｐｐ」または「アプリケーション」がユーザー通信装置上にインストールされてもよく、装置上で実行するためのプロセッサ実行可能命令を含んでもよい。非限定的な例として、輸送関連サービスの予約は、Ａｐｐを介して実行されてもよい。
【0099】
ここで、様々な実施形態または技術をさらに詳細に説明する。様々な実施形態は、Ａｐｐ側（フロントエンド）としてのクライアント側と、サーバ側（バックエンド）とを含むことができる。
【0100】
本明細書で開示される技術の輸送サービスでは、ユーザーのピックアップおよびドロップオフを要求して、運転者とのマッチング、ルートの計画、料金の計算を行うことができる。ＰＯＩサービスは、ユーザーの位置に従ってピックアップおよびドロップオフを推奨する役割を果たす。ＰＯＩサービスの品質の１つの測定は、ピックアップおよびドロップオフに適切なＰＯＩを見つけるために顧客（ユーザー）側からどれだけの労力を節約することができるかである。
【0101】
様々な実施形態のＰＯＩサービスは、図３Ａ～３Ｄに示すように、予約フローに４つの主要なアクションまたはシナリオを含むことができる。これらのシナリオには、「予測（Predict）」、「推奨（Suggest）」、「検索（Search）」、および「リバースジオ（ReverseGeo）」が含まれる。
【0102】
「予測」シナリオに関する図３Ａを参照すると、ユーザーまたは乗客（ＰＡＸ）が対応するＡｐｐを開くと、ＡｐｐはＰＯＩ予測エンドポイントを呼び出して、Ｐａｘの履歴データおよび現在位置に基づいて予測ピックアップＰＯＩおよび予測ドロップオフＰＯＩを取得する。図３Ａでは、非限定的な例として、予測ピックアップＰＯＩ２７０が「セティアブディレジデンス（Setiabudi Residence）」として示されている。
【0103】
様々な実施形態では、予測アクションがＡｐｐを開く時点で実行される。「予測」アクションは常に実行され、Ａｐｐを開いたとき、または予約注文を行うときに実行される最初のアクションである。
【0104】
「推奨」シナリオに関する図３Ｂを参照すると、例えば、予測結果が期待通りでない場合、Ｐａｘは入力ボックス２７１をクリックすることができ、ＡｐｐはＰＯＩ推奨エンドポイント（Suggest endpoint）を呼び出して、Ｐａｘ履歴データ、現在位置、および都市人気度ＰＯＩに基づいてＰＯＩの推奨リスト２７２を取得する。
【0105】
「検索」シナリオに関する図３Ｃを参照すると、例えば、提案された結果が期待通りでない場合、Ｐａｘは例えば、１つ以上のキーワード２７３をタイプ（typing）することによって情報を入力することができ、アプリは、ＰＯＩ検索エンドポイント（Search endpoint）を呼び出して、キーワードに基づいて、ＰＯＩの一致リスト２７４を取得する。
【0106】
「リバースジオ（ReverseGeo）」シナリオに関する図３Ｄを参照すると、例えば、提案された／検索結果が期待通りでない場合、Ｐａｘはマップ２７５に進み、ＰＩＮ２７６を移動させて、ＰＯＩを見つけるためにＰＯＩリバースジオエンドポイント（ReverseGeo endpoint）を呼び出すことができる。
【0107】
それぞれのＰＯＩ予測、提案、検索、およびリバースジオエンドポイントはサーバ側（例えば、通信サーバ装置）に配置されてもよいし、言い換えると、予測、提案、検索、およびリバースジオシナリオに関連する処理がサーバ側で実行され、その後、結果がＡｐｐ側のユーザーに返されてもよい。Ａｐｐ側は処理の目的のために、Ｐａｘ ＩＤ、緯度、経度などのうちの１つ以上を含む情報を提供することができる。
【0108】
要約すると、上記のアクションまたはシナリオは、ピックアップおよび／またはドロップオフのためのユーザーの所望のＰＯＩを発見するために、ユーザーに順に提供または示されてもよい。ユーザーが画面をクリックする必要がある回数が少ないほど、ＰＯＩが予約注文を生成するのが簡単になる。輸送サービス全体のための予約注文を生成することの一部として、ＰＯＩサービスは高い可用性および安定性を必要とし、これは、システムに多くの課題を発生し得る。第１に、１つの課題は応答時間に関してサービス全体を安定に保ちながら、一日のピーク時に急増する同時多発的なリクエストをどのように処理するか、である。一方で、これは適切な数のサーバ（例えば、クラウドサーバ）が１日あたりの様々な時間帯に対して構成されるように、マシンを自動的にスケーリングする必要がある。一方、各同時リクエストのリソースは高可用性を保証するために、一部の障害がサービス全体に影響しないよう、適切にリソースが割り当てられた独立したスレッド（thread）で管理する必要がある。第２に、別の課題は、ＰＯＩサービスの目標が、ユーザーが所望のピックアップおよび／またはドロップオフを得るために必要とする労力を節約することであるため、顧客が望むものをより正確に満たすことができるより良い推奨性能を提供するために、履歴データの量をどのように利用するかである。
【0109】
これらの課題に対処し、ＰＯＩサービスを高度に利用可能かつ安定に保つために、以下で説明するように、いくつかの技術を展開することができる。
【0110】
エラスティックサーチ（Elasticsearch）は、ＰＯＩデータを保存し、ＰＯＩクエリを実行するために使用されている。Ｒｔｒｅｅ、ｋ－ｄツリー、または様々なクエリを可能にするための移動オブジェクトに特有のものなど、大量のジオメトリデータ（geometry data）を管理するための様々なインデックス（index）が提案されている。広く使用されているもう１つのインデックス方法は、地理的位置を短い文字と数字の文字列とにエンコードし、近くの場所が同様のプレフィックス（prefix）を共有するようにするジオハッシュ（Geohash）である。様々な実施形態では、内部プロバイダがＰＯＩデータを記憶するためにエラスティックサーチを利用する。ユーザー位置のリクエスト（例えば緯度と経度で記述される）が到着すると、エラスティックサーチはジオハッシュを利用して、次のステップ処理のために与えられた位置に近い上位のＰＯＩを返す。これにより、１台のマシンから、ペタバイトのデータを有する数百のサーバへ水平方向に拡張できる場合がある。数十億のＰＯＩデータを用いて応答時間を安定に保つために、主要な検索式の時間コストを分析し、特定の最適化のためにボトルネックを決定することができる。
【0111】
Ｒｅｄｉｓは、データベース、キャッシュ、メッセージブローカー、およびキューとして使用するための高速なオープンソースのメモリ内データストアである。Ｒｅｄｉｓは例えば、通信サーバ装置において、サーバ側に配置されてもよい。様々な実施形態では、アマゾンエラスティックキャッシュ（Amazon Elasticache）をＲｅｄｉｓに適合させて、ＰＯＩデータをキャッシュし、様々なシナリオ／アプリケーション要件に応じて様々な方法でキャッシュキーを生成することができる。これは、背後にあるデータベースが処理できるものに対するクエリ／秒（ＱＰＳ）の値を制御するのに役立つ場合がある。Ｒｅｄｉｓは通常、関連するデータベース（ｍｙＳＱＬ、ｄｙｎａｍｏＤＢ、エラスティックサーチなど）の前に配置されていることを理解しておく必要がある。一般的に、サーバ側（バックエンド）のロジックは、関連するデータベースから応答を取得するときにリクエスト結果をＲｅｄｉｓに書き込む場合がある。次回同じリクエストが発生したときに、代わりにＲｅｄｉｓから直接返信を取得できる。
【0112】
バックエンドアーキテクチャ（backend architecture）全体は、Ｇｏｌａｎｇに実装されている。その並列処理はゴールーチン（goroutine）およびチャネルに基づくので、各ｈｔｔｐリクエストは、独立したゴールーチンに割り当てて処理することができる。それらの一部がパニック（panic）になったとしても、プロセス全体が影響を受けることはない。ゴールーチンは、非常に軽量で、開始および停止が容易であり、これにより、Ｇｏｌａｎｇは様々な実施形態のバックエンド言語としての安定性に関して他の言語よりも性能が優れている。
【0113】
履歴データの量を分析した後、異なるシナリオ／アプリケーションにおいて妥当なＰＯＩスコアを提供し得るランキングモデルが導出される。また、「コールドスタート（Cold start）」の課題は、新規ユーザーに顧客体験を提供または保証するためのフォールバック（fallback）にも対処されてきた。
【0114】
本明細書で開示される技術のためのＧｏｌａｎｇベースのＰＯＩサービスについて、オンラインＰＯＩ推奨および発見をサポートするためのアーキテクチャ、異なるシナリオにおけるＰＯＩ推奨、およびサービスのいくつかの結果を含めて、以下で詳細に説明する。
【0115】
マルチコアプロセッサが既に利用可能になった２００９年にリリースされた言語として、「Ｇｏ」は並行処理を前提に作られている。ｊａｖａのヒープ（heap）から約１ＭＢのメモリを消費するスレッドの代わりに、Ｇｏには約２ＫＢのメモリを消費するゴールーチンがあり、数百万のゴールーチンをスピン（spin）させることができる。さらに、ルーチンはそれらの間で安全に通信し、ミューテックスロッキング（mutex locking）の使用を回避するためのチャネルを備える。ＧｏはＣ／Ｃ＋＋のようなコンパイル型言語である。また、ガベージコレクション（garbage collection）を使用して、ｊａｖａなどのオブジェクトの割り当てと削除を行う。これにより、ｊａｖａＶＭステップのバイトコード解釈が回避され、Ｃ／Ｃ＋＋のような言語での変数の解放と割り当てる手間が省けるため、ハードウェアでの実行速度が保証される可能性がある。Ｇｏの構文は非常に安定している。これにより、Ｇｏで書かれたコードを容易に維持することができる。Ｇｏにはクラスも継承も存在しない。開発者はコードを容易に理解することができ、異なるコード部分は相互に深く影響しない。さらに、開発者は同じコードベースで共同作業を行うことができる。
【0116】
マイクロサービスは、疎結合サービスの集合としてアプリケーションを構造化するソフトウェア開発技術である。マイクロサービスアーキテクチャ（micro-service architecture）では、サービスはきめ細かく、プロトコルは軽量である。ＰＯＩサービスは、様々な実施形態におけるシステム全体における１つのマイクロサーバである。拡大して見てみると、ＰＯＩのようなマイクロサービスは、例えば、ｈｔｔｐサーバ層４７２、ロジック層４７４、およびデータベース層４７６を有する層ベースのウェブサービス構造体４７０を示す図４に表されているように、多層サービス構造体を利用する。層４７２のｈｔｔｐサーバは、負荷バランス方式（load balance way）でユーザー側から論理層４７４にｈｔｔｐリクエストを送信する役割を果たす。論理層４７４は、ｈｔｔｐリクエストに従って論理を処理する役割を果たす。論理処理に関連するすべてのデータは、データベース層４７６に格納されてもよい。論理層４７４がコンピューティングリソース（computing resource）を使い果たすと、非限定的な例として、Ａｍａｚｏｎ（登録商標）のＡＳＧ（Ａｕｔｏ Ｓｃａｌｉｎｇ Ｇｒｏｕｐｓ）などの水平スケーリングを広く使用することができる。論理層４７４およびデータ層（すなわち、データベース層４７６）は完全に分離されているので、特定の論理層インスタンスの障害がユーザーデータの損傷または欠落につながる可能性は低い。様々な実施形態のＰＯＩサービスは、このようなサービスアーキテクチャに従う。
【0117】
分散システムの場合、そのＣＡＰ（一貫性、可用性、およびパーティション耐性（tolerance））が同時に満たされない可能性があるので、ウェブサービスはカスケード障害（cascading failure）を停止し、障害が避けられない複雑な分散システムにおける復元力を有効にする必要がある。ＰＯＩサービスの場合、非限定的な例として、ヒストリックス（Hystrix）を使用して、回路ブレーカー（circuit breaker）を設定することによって、応答されるサービスの応答時間を有効化または保証することができる。
【0118】
ロジック層はデータ層からのユーザーデータを頻繁に要求するため、キャッシュは、各リクエストの応答時間を短縮するだけでなく、バーストワークロード（burst workload）によるデータベースのダウンを防ぐために広く使用されてもよい。使用する方法は２つある。１つはデータベース層の前にキャッシュ層を設定する方法で、もう１つは各ロジックインスタンス（logic instance）のメモリに個別のキャッシュを設定する方法である。様々な実施形態のＰＯＩサービスのために、Ｒｅｄｉｓは、データベース層の前にキャッシュとして用いられ、異なるシナリオ／アプリケーション要件に従ってキャッシュキーおよび有効期限を設定する。例えば、Ａｍａｚｏｎ Ｅｌａｓｔｉｃａｃｈｅ ｆｏｒ Ｒｅｄｉｓを使用して、キャッシュモジュールを一から構築するのに比べて、弾性的なスケーリングを提供することができ、ダウンタイムサービスがほとんどないか、または最小限である、サービスの安定性の点で役立つ。
【0119】
様々な実施形態のオンラインＰＯＩ推奨におけるＰＯＩサービスアーキテクチャおよびキャッシュの使用について、以下の非限定的な例によって説明する。
【0120】
図５は、ＰＯＩサービスのためのシステム５７０の概要を示す概略図を示す。ＰＯＩシステム５７０は４つの構成要素に分割することができる。第１に、ＡＰＩ５７１ａはミドルウェア層５７１ｂからの結果を有する４つのＰＯＩユーザーシナリオ（例えば、予測、提案、検索、およびリバースジオ）をサポートするための層である。第２に、ディスパッチャ（Dispatcher）５７１ｃは、ｈｔｔｐリクエストをプロバイダ５７１ｄに発送（dispatche）する。第３に、プロバイダ（Providers）５７１ｄはＰＯＩプロバイダ（例えば、内部プロバイダ（Internal Providers）５７２ａおよび／または外部プロバイダ（External Providers）５７２ｂ）からＰＯＩを取得し、それらをミドルウェア層（Middle wares）５７１ｂに返す層である。第４に、ミドルウェア５７１ｂは、プロバイダ層５７１ｄから返されたＰＯＩを処理する層である。ＡＰＩ層５７１ａ、ミドルウェア層５７１ｂ、ディスパッチャ５７１ｃおよびプロバイダ層５７１ｄはサーバ側（例えば、通信サーバ装置で）に位置することができる。ＡＰＩ層５７１ａ、ミドルウェア層５７１ｂ、およびプロバイダ層５７１ｄについては、以下でさらに説明する。
【0121】
ＡＰＩ５７１ａ：
予測、提案、検索、およびリバースジオの４つのエンドポイントがある。予測および提案は、Ｐａｘ履歴データに基づいている。これはＰａｘ３０日間の履歴データに基づいてプレディクタＤＢ（Predictor DB）という名前のＭｙＳＱＬ ＤＢに保存される場合がある。ユーザーまたは乗客が対応するＡｐｐを開くと、ＡｐｐはＰＯＩ予測エンドポイントを呼び出して、Ｐａｘ（ユーザー）履歴データおよびユーザーの現在位置に基づいて、予測されたピックアップＰＯＩおよび／または予測されたドロップオフＰＯＩを得る。予測結果が期待通りでない場合、ＰａｘはＡｐｐ内の入力ボックスをクリックし、ＡｐｐはＰＯＩ提案エンドポイントを呼び出して、履歴データ、ユーザーの現在位置、および都市の人気度ＰＯＩ（すなわち、ピックアップＰＯＩおよび／またはドロップオフＰＯＩに対応する都市内の人気度ＰＯＩ）に基づいて、ＰＯＩの提案リストを取得する。提案の結果が期待通りでない場合、Ｐａｘはキーワードを入力してＰＯＩ検索エンドポイントを呼び出し、キーワードに基づいて一致するＰＯＩのリストを取得する。提案結果が期待通りでない場合、Ｐａｘは、ＰＩＮを移動してＰＯＩを見つけるためにＰＯＩリバースジオエンドポイント（POI ReverseGeo endpoint）を呼び出すマップに進むことができる。様々な実施形態の文脈では、用語「エンドポイント（endpoint）」は、コードで呼び出され得るモジュールを意味するか、または参照し得る。そのようなモジュールは、命令のセットを含むことができる。
予測、提案、検索、およびリバースジオの４つのエンドポイントがある。予測および提案は、Ｐａｘ履歴データに基づいている。これはＰａｘ３０日間の履歴データに基づいてプレディクタＤＢ（Predictor DB）という名前のＭｙＳＱＬ ＤＢに保存される場合がある。ユーザーまたは乗客が対応するＡｐｐを開くと、ＡｐｐはＰＯＩ予測エンドポイントを呼び出して、Ｐａｘ（ユーザー）履歴データおよびユーザーの現在位置に基づいて、予測されたピックアップＰＯＩおよび／または予測されたドロップオフＰＯＩを得る。予測結果が期待通りでない場合、ＰａｘはＡｐｐ内の入力ボックスをクリックし、ＡｐｐはＰＯＩ提案エンドポイントを呼び出して、履歴データ、ユーザーの現在位置、および都市の人気度ＰＯＩ（すなわち、ピックアップＰＯＩおよび／またはドロップオフＰＯＩに対応する都市内の人気度ＰＯＩ）に基づいて、ＰＯＩの提案リストを取得する。提案の結果が期待通りでない場合、Ｐａｘはキーワードを入力してＰＯＩ検索エンドポイントを呼び出し、キーワードに基づいて一致するＰＯＩのリストを取得する。提案結果が期待通りでない場合、Ｐａｘは、ＰＩＮを移動してＰＯＩを見つけるためにＰＯＩリバースジオエンドポイント（POI ReverseGeo endpoint）を呼び出すマップに進むことができる。様々な実施形態の文脈では、用語「エンドポイント（endpoint）」は、コードで呼び出され得るモジュールを意味するか、または参照し得る。そのようなモジュールは、命令のセットを含むことができる。
【0122】
ミドルウェア５７１ｂ：
受信したＰＯＩの位置ＩＤ（識別子または識別）を異なるプロバイダ５７１ｄからユニークな形式の１つに正規化する、入力ＰＯＩの不良ＰＯＩをブラックリストに登録する、入力ＰＯＩの重複ＰＯＩを削除する、いくつかのフィールドに基づいて入力ＰＯＩをランク付けし、提案エンドポイントと検索エンドポイントの両方の結果を取得する（予測およびリバースジオは１つのＰＯＩのみを返すため、ランク付けを行う必要がない）、などの機能を持つミドルウェアがいくつかある。
受信したＰＯＩの位置ＩＤ（識別子または識別）を異なるプロバイダ５７１ｄからユニークな形式の１つに正規化する、入力ＰＯＩの不良ＰＯＩをブラックリストに登録する、入力ＰＯＩの重複ＰＯＩを削除する、いくつかのフィールドに基づいて入力ＰＯＩをランク付けし、提案エンドポイントと検索エンドポイントの両方の結果を取得する（予測およびリバースジオは１つのＰＯＩのみを返すため、ランク付けを行う必要がない）、などの機能を持つミドルウェアがいくつかある。
【0123】
プロバイダ５７１ｄ：
Ｐａｘ位置に基づいて、対応する都市に関連するデータを取得することができ、その関連する都市構成を使用することができる。都市によって、使用するプロバイダを決定するための設定が異なる場合がある。通常、プロバイダには２つまたは３つのグループがあってもよく、同じグループ内で、検索リクエストがこれらのプロバイダに並列に送信されてもよい。同じグループ（例えば、第１のグループ）内のすべてのプロバイダに障害が発生した場合、または応答がない場合、プロバイダの第２（または後続の）グループにリクエストを送信する。非限定的な例として、構成に応じて、内部プロバイダ５７２ａおよびＧｏｏｇｌｅ（登録商標）（外部プロバイダ５７２ｂ）は第１のグループとして設定され、Ｆｏｕｒｓｑｕａｒｅ（登録商標）（外部プロバイダ５７２ｂ）は第２のグループとして設定され、残りのプロバイダは第３のグループとして設定されてもよい。
Ｐａｘ位置に基づいて、対応する都市に関連するデータを取得することができ、その関連する都市構成を使用することができる。都市によって、使用するプロバイダを決定するための設定が異なる場合がある。通常、プロバイダには２つまたは３つのグループがあってもよく、同じグループ内で、検索リクエストがこれらのプロバイダに並列に送信されてもよい。同じグループ（例えば、第１のグループ）内のすべてのプロバイダに障害が発生した場合、または応答がない場合、プロバイダの第２（または後続の）グループにリクエストを送信する。非限定的な例として、構成に応じて、内部プロバイダ５７２ａおよびＧｏｏｇｌｅ（登録商標）（外部プロバイダ５７２ｂ）は第１のグループとして設定され、Ｆｏｕｒｓｑｕａｒｅ（登録商標）（外部プロバイダ５７２ｂ）は第２のグループとして設定され、残りのプロバイダは第３のグループとして設定されてもよい。
【0124】
オンラインＰＯＩ推奨のキャッシュに関しては図５にも見られるように、キャッシュは３つの層、すなわちＡＰＩ層５７１ａ、ミドルウェア層５７１ｂ、およびプロバイダ層５７１ｄに配置することができる。キャッシュ設定については、以下でさらに説明する。
【0125】
簡単に述べると、ＡＰＩ層５７１ａはリクエストを送信し、ディスパッチャ層５７１ｃはリクエストをプロバイダ５７１ｄに送信する。プロバイダ５７１ｄが結果を送り返す。ミドルウェア５７１ｂは、結果を処理して、所望のものまたは必要なものを取得する。最後に、結果がユーザーに返される。キャッシュおよびデータベースを使用して、ＰＯＩ推奨のために過去のリクエストおよび結果を記憶することができる。
【0126】
ＡＰＩ層５７１ａ：
ｈｔｔｐリクエストがＡＰＩ層５７１ａに入ると（例えば、サーバ５７３から）、最初のキャッシュ層は、ｕｒｌ全体をキャッシュキーとして受け取るｈｔｔｐキャッシュ５７４であり、キャッシュの存続時間（ＴＴＬ）は、例えば、３０秒に設定することができる。このキャッシュ設定は、検索シナリオ（図３Ｃおよび対応する説明を参照）のために、同じ場所にいる近くのユーザーの重複したトライアルに使用することができる。提案（図３Ｂおよび対応する説明を参照）および検索の両方は、距離キャッシュ（distance cache）５７７を使用して、過去のリクエストにおける応答結果を格納する。提案は（例えば、緯度（ｌａｔ）、経度（ｌｎｇ）の形式で）Ｐａｘ ＩＤ（またはユーザーＩＤ）および地域（または場所）をキーとして使用する。検索では、入力されたキーワードと場所（ｌａｔ／ｌｎｇ）がキーとして使用される。キャッシュ５７７の生存時間（time-to-live；ＴＴＬ）は例えば、１日に設定することができる。これにより、同じ領域内のユーザーが自分のレスポンスを共有できるようになる。「生存時間（time-to-live）」という用語は、キャッシュ内のデータの有効時間を意味する場合がある。無効なデータは使用できなくなる。
ｈｔｔｐリクエストがＡＰＩ層５７１ａに入ると（例えば、サーバ５７３から）、最初のキャッシュ層は、ｕｒｌ全体をキャッシュキーとして受け取るｈｔｔｐキャッシュ５７４であり、キャッシュの存続時間（ＴＴＬ）は、例えば、３０秒に設定することができる。このキャッシュ設定は、検索シナリオ（図３Ｃおよび対応する説明を参照）のために、同じ場所にいる近くのユーザーの重複したトライアルに使用することができる。提案（図３Ｂおよび対応する説明を参照）および検索の両方は、距離キャッシュ（distance cache）５７７を使用して、過去のリクエストにおける応答結果を格納する。提案は（例えば、緯度（ｌａｔ）、経度（ｌｎｇ）の形式で）Ｐａｘ ＩＤ（またはユーザーＩＤ）および地域（または場所）をキーとして使用する。検索では、入力されたキーワードと場所（ｌａｔ／ｌｎｇ）がキーとして使用される。キャッシュ５７７の生存時間（time-to-live；ＴＴＬ）は例えば、１日に設定することができる。これにより、同じ領域内のユーザーが自分のレスポンスを共有できるようになる。「生存時間（time-to-live）」という用語は、キャッシュ内のデータの有効時間を意味する場合がある。無効なデータは使用できなくなる。
【0127】
プレディクタキャッシュ（Predictor cache）５７６という名前の別のキャッシュがあり、これは、各リクエストのピックアップまたはドロップオフをプレディクタＤＢ（すなわち、データベース記憶装置）５７８に記憶することができる。過去３０日間の履歴データは、以下でさらに説明するように、予測および推測のためにプレディクタＤＢ５７８に格納することができる。プレディクタＤＢ５７８へのリクエストが予測子キャッシュ５７６によって応答できる場合、背後にあるデータベース（すなわちプレディクタＤＢ５７８）を照会する必要はない。
【0128】
ｈｔｔｐキャッシュ５７４と、プロジェクタキャッシュ５７６および距離キャッシュ５７７の間には、サーバのグループが存在する場合がある（例えば、２つのサーバが５７５ａ、５７５ｂとして表現される）。
【0129】
プレディクタＤＢ５７８はマイクロサーバのデータベース層（例えば、図４のデータベース層４７６）に配置することができる。一般に、論理層４７４は、最初にプレディクタキャッシュ層５７６を訪れる。ミスが発生すると、プレディクタＤＢ５７８が訪問またはアクセスされる。
【0130】
プレディクタＤＢ５７８およびプレディクタキャッシュ５７６は、サーバ側、例えば通信サーバ装置に配置される。
【0131】
プロバイダ層５７１ｄ：
リクエストがプロバイダ層５７１ｄに入ると、まず、各プロバイダのキャッシュにアクセスして応答キャッシュ５８３ｂ（例えば、内部プロバイダキャッシュ５８１、Ｇｏｏｇｌｅキャッシュ５８３ａ、Ｆｏｕｒｓｑｕａｒｅキャッシュ５８３ｃ、および「その他」）を取得しようとする（ここで「その他」は、１つ以上の特定プロバイダを指す場合がある）。外部プロバイダ（例えば、Ｇｏｏｇｌｅ５８３ａ、Ｆｏｕｒｓｑｕａｒｅ５８３ｃ、その他５８３ｂ）のいずれか１つまたはすべてのＴＴＬは、何日もかかる場合がある。内部プロバイダ５７２ａからのデータを格納する内部プロバイダキャッシュ５８１のＴＴＬは、１０分とすることができる。これは、内部プロバイダ５７２ａ内の（例えば、発見されたＰＯＩの追加および／または更新に関する）ＰＯＩデータがより頻繁に更新され、新しいＰＯＩデータが、より短いＴＴＬでより迅速に有効になり得るためである可能性がある。ＴＴＬタイミングは、更新の頻度に応じて可変であってもよいことを理解されたい。また、図５には、内部プロバイダ５７２ａに対応するデータベース記憶装置（Data-base）５８２と、外部プロバイダＧｏｏｇｌｅ、「その他」、およびＦｏｕｒｓｑｕａｒｅの対応するクラウドサーバ５８４ａ、５８４ｂ、５８４ｃとが示されている。
リクエストがプロバイダ層５７１ｄに入ると、まず、各プロバイダのキャッシュにアクセスして応答キャッシュ５８３ｂ（例えば、内部プロバイダキャッシュ５８１、Ｇｏｏｇｌｅキャッシュ５８３ａ、Ｆｏｕｒｓｑｕａｒｅキャッシュ５８３ｃ、および「その他」）を取得しようとする（ここで「その他」は、１つ以上の特定プロバイダを指す場合がある）。外部プロバイダ（例えば、Ｇｏｏｇｌｅ５８３ａ、Ｆｏｕｒｓｑｕａｒｅ５８３ｃ、その他５８３ｂ）のいずれか１つまたはすべてのＴＴＬは、何日もかかる場合がある。内部プロバイダ５７２ａからのデータを格納する内部プロバイダキャッシュ５８１のＴＴＬは、１０分とすることができる。これは、内部プロバイダ５７２ａ内の（例えば、発見されたＰＯＩの追加および／または更新に関する）ＰＯＩデータがより頻繁に更新され、新しいＰＯＩデータが、より短いＴＴＬでより迅速に有効になり得るためである可能性がある。ＴＴＬタイミングは、更新の頻度に応じて可変であってもよいことを理解されたい。また、図５には、内部プロバイダ５７２ａに対応するデータベース記憶装置（Data-base）５８２と、外部プロバイダＧｏｏｇｌｅ、「その他」、およびＦｏｕｒｓｑｕａｒｅの対応するクラウドサーバ５８４ａ、５８４ｂ、５８４ｃとが示されている。
【0132】
ミドルウェア層５７１ｂ：
プロバイダ５７１ｄの反応がミドルウェア５７１ｂに入り、返されたＰＯＩを処理する際に、ミドルウェアの機能を処理するのに役立つ様々なキャッシュが存在する。例えば、ユニバーサルキャッシュ（universal cache）（詳細キャッシュ（detailed cache）５７９ｃなど）はエラスティックサーチに保存され、ＰＯＩ詳細キャッシュ５７９ｃにはＰＯＩ詳細説明（ＰＯＩ名、カテゴリ、場所など）が含まれるため、ＴＴＬは１日になる場合がある。ＰＯＩがブラックリストされているか否かに関するＰＯＩステータスを記憶するために１日に設定されたＴＴＬを有するメタキャッシュ（meta cache）５７９ａがあってもよい。さらに、ランク５７９ｄおよびエントランス５７９ｂのためのそれぞれのキャッシュがあり、リクエストのためのランキングおよびエントランス情報（entrance information）を記憶することができる。一例として、「エントランス（entrance）」は車両に乗ったり降りたりするために、大型ショッピングモールや空港のドアなどの大規模な公共施設の利用可能な場所を示す。これらの場所での正確なピックアップおよびドロップオフに関するエントランス情報は、両方の顧客体験を大幅に改善することができる。
プロバイダ５７１ｄの反応がミドルウェア５７１ｂに入り、返されたＰＯＩを処理する際に、ミドルウェアの機能を処理するのに役立つ様々なキャッシュが存在する。例えば、ユニバーサルキャッシュ（universal cache）（詳細キャッシュ（detailed cache）５７９ｃなど）はエラスティックサーチに保存され、ＰＯＩ詳細キャッシュ５７９ｃにはＰＯＩ詳細説明（ＰＯＩ名、カテゴリ、場所など）が含まれるため、ＴＴＬは１日になる場合がある。ＰＯＩがブラックリストされているか否かに関するＰＯＩステータスを記憶するために１日に設定されたＴＴＬを有するメタキャッシュ（meta cache）５７９ａがあってもよい。さらに、ランク５７９ｄおよびエントランス５７９ｂのためのそれぞれのキャッシュがあり、リクエストのためのランキングおよびエントランス情報（entrance information）を記憶することができる。一例として、「エントランス（entrance）」は車両に乗ったり降りたりするために、大型ショッピングモールや空港のドアなどの大規模な公共施設の利用可能な場所を示す。これらの場所での正確なピックアップおよびドロップオフに関するエントランス情報は、両方の顧客体験を大幅に改善することができる。
【0133】
図５にはまた、それぞれメタキャッシュ５７９ａ、エントランスキャッシュ５７９ｂ、詳細キャッシュ５７９ｃに対応するデータベースストレージ５８０ａ，５８０ｂ、５８０ｃが示されている。
【0134】
全体として、サーバは、リクエスト（複数可）を処理することができる。キャッシュには結果が保存され、データベースへのリクエストが増えすぎないようにしてもよい。データベースストレージには、ユーザーデータを保管できる。プロバイダのクラウドサーバは、プロバイダに送信されるリクエストに応答する場合がある。
【0135】
様々な実施形態のオンラインＰＯＩ推奨について、以下の非限定的な例によってさらに説明する。
【0136】
様々な実施形態では、移動されたＰＩＮに従ってリバースジオがＰＯＩを返す。
【0137】
様々な実施形態では、シナリオ予測、検索、および推奨におけるＰＯＩ推奨は履歴データに基づいて実行されてもよい。ＰＯＩサービスの目標は、ユーザーが所望のピックアップおよび／またはドロップオフを得るために必要とする労力を節約することであるので、予測、検索、および提案は、大量の履歴データを使用して、ユーザーまたは顧客が望むものをより正確に当てることができ、より良好な推奨性能を提供することによって、個別に実行されてもよい。提案および予測の場合、履歴データは、例えば、プレディクタＤＢなどのデータベースに格納され、データは異なるテーブルに提供され、管理され、候補ＰＯＩはクエリによって取得することができる。検索の場合、ＰＯＩランキングの合計スコアとして加重和を計算するために、例えば、名前キーワード、領域、人気度、タイミング、および距離など、いくつかの側面または考慮事項がある。これらの側面は、ＰＯＩ特性をより適切に説明し、ユーザーがターゲットＰＯＩをより容易に見つけるのに役立つ場合がある。既知の技術における位置類似性のみを考慮することと比較すると、様々な実施形態のこの包括的なスコアは、ピックアップおよび／またはドロップオフとして対象ＰＯＩを検索する際に、ユーザーにより良好な顧客体験を与えることができる。最も可能性の高い地点（例えば、ピックアップポイントを含む）の推奨について以下に説明する。
【0138】
検索
検索シナリオでは、ユーザーは入力ボックスまたは検索ボックスに１つ以上の単語を入力し、サービスがリターンとしてターゲットＰＯＩを提供することを期待する。ＰＯＩをランキング可能（rankable）にするために、各ＰＯＩにスコアを割り当てることができ、スコアは、以下の要因または基準のうちの１つ以上によって決定することができる。
検索シナリオでは、ユーザーは入力ボックスまたは検索ボックスに１つ以上の単語を入力し、サービスがリターンとしてターゲットＰＯＩを提供することを期待する。ＰＯＩをランキング可能（rankable）にするために、各ＰＯＩにスコアを割り当てることができ、スコアは、以下の要因または基準のうちの１つ以上によって決定することができる。
【0139】
キーワード：
これは、検索キーワードとＰＯＩ名またはＰＯＩ名の頭字語との間のスコアを測定する。各ＰＯＩは、複数の頭字語を有することができる。限定的でない例として、キーワードマッチングスコアＳＫｅｙｗｏｒｄは、式１に示されるように計算されてもよい。
これは、検索キーワードとＰＯＩ名またはＰＯＩ名の頭字語との間のスコアを測定する。各ＰＯＩは、複数の頭字語を有することができる。限定的でない例として、キーワードマッチングスコアＳＫｅｙｗｏｒｄは、式１に示されるように計算されてもよい。
【0140】
【数1】
【0141】
ここで、ｓＪはＰＯＩ名と検索キーワードのジャカール近似（Jaccard Similarity）であり、ｓＡは、検索キーワードがＰＯＩ名または頭字語と完全に一致する場合は１を返し、それ以外の場合は０を返す。
【0142】
領域：
ＳＲｅｇｉｏｎは、ＰＯＩ領域とＰａｘ（またはユーザー）領域間の近接性に基づいてスコアを測定する。ＳＲｅｇｉｏｎのスコアは、ＰＯＩ領域とＰａｘ領域とが同じ場合は１に等しく、それ以外の場合は０に等しくなる（式２を参照）。
ＳＲｅｇｉｏｎは、ＰＯＩ領域とＰａｘ（またはユーザー）領域間の近接性に基づいてスコアを測定する。ＳＲｅｇｉｏｎのスコアは、ＰＯＩ領域とＰａｘ領域とが同じ場合は１に等しく、それ以外の場合は０に等しくなる（式２を参照）。
【0143】
【数2】
【0144】
ここで、ｇｅｔＲｅｇｉｏｎ（．）は任意の位置（ｌａｔ／ｌｎｇ）を入力として取り、その場所がある対応する都市を返す関数である。ＰＯＩとＰａｘとが異なる国にある場合、ＰＯＩは結果リストから除外される。したがって、ＰＯＩはＰａｘと同じ国にあることが保証される。
【0145】
人気度：
ＳＰｏｐｕｌａｒｉｔｙ（＊）は、ＰＯＩがピックアップ／ドロップオフとして選択された回数に基づいてＰＯＩの人気度をスコア化する。これは、以下のように定義することができる。
ＳＰｏｐｕｌａｒｉｔｙ（＊）は、ＰＯＩがピックアップ／ドロップオフとして選択された回数に基づいてＰＯＩの人気度をスコア化する。これは、以下のように定義することができる。
【0146】
【数3】
【0147】
【数4】
【0148】
ここで、ＣｏｕｎｔＰｉｃｋｕｐは、このＰＯＩがピックアップポイントとして選択された回数、ＣｏｕｎｔＤｒｏｐｏｆｆは、ドロップオフとして選択された回数、ＣｏｕｎｔＭａｘは、結果セットのＰＯＩがピックアップまたはドロップオフとして選択された最大回数である。
【0149】
タイミング：
ＰＯＩのスコアは、Ｐａｘまたはユーザーがある時間帯に与えられたこのＰＯＩにおいてピックアップまたはドロップオフを行う確率に基づいて定義される。例えば、朝方は、住宅エリアのＰＯＩがピックアップポイントである可能性が高く、ドロップオフポイントである可能性が低い。ＰＯＩのピックアップおよびドロップオフの時間分布はオフラインで事前に計算することができ、したがって、ＰＯＩがピックアップ点またはドロップオフ点になる確率を自然に導出することができる。詳細スコアは、以下のように定義することができる。
ＰＯＩのスコアは、Ｐａｘまたはユーザーがある時間帯に与えられたこのＰＯＩにおいてピックアップまたはドロップオフを行う確率に基づいて定義される。例えば、朝方は、住宅エリアのＰＯＩがピックアップポイントである可能性が高く、ドロップオフポイントである可能性が低い。ＰＯＩのピックアップおよびドロップオフの時間分布はオフラインで事前に計算することができ、したがって、ＰＯＩがピックアップ点またはドロップオフ点になる確率を自然に導出することができる。詳細スコアは、以下のように定義することができる。
【0150】
【数5】
【0151】
【数6】
【0152】
ここで、Ｄｉｓｔｒｉ＊（．）はＰＯＩの時間分布、ｔＱはＰａｘのクエリ時間である。非限定的な例として、様々な実施形態では、ＰＯＩの時間分布はマップ（図６を参照）によって実施することができ、ここで、キーは時間（０：００から２３：００までの時間、１日の対応する２４時間を表す；図６のＸ軸を参照）であり、値（図６「頻度」を参照）はＰＯＩが履歴内のピックアップまたはドロップオフポイントとして選択された比率であり、したがって、ＰＯＩが所与のまたは定義された時間にピックアップまたはドロップオフポイントとして何回選択されたかに関連する。
【0153】
距離：
これは、ＰＯＩとＰａｘの位置との間の距離に基づいてスコアを測定する。このファクタは、ピックアップ検索にのみ適用可能である。これは、以下のように定義することができる。
これは、ＰＯＩとＰａｘの位置との間の距離に基づいてスコアを測定する。このファクタは、ピックアップ検索にのみ適用可能である。これは、以下のように定義することができる。
【0154】
【数7】
【0155】
ここで、距離ｄｉｓｔは、例えば、ｋｍ（キロメートル）で測定することができる。
次いで、最終スコアは、以下のように加重和によって計算することができる。
次いで、最終スコアは、以下のように加重和によって計算することができる。
【0156】
【数8】
【0157】
ここで、加重係数αi は、機械学習アルゴリズム（machine learnt algorithm）によって決定され、Ｆは上記で識別された一連の因子（set of factor）、すなわち、キーワード、領域、人気度、タイミング、距離である。そして、ＰＯＩは、例えば、降順に、それぞれのスコアに従ってランク付けされてもよい。おすすめのＰＯＩのみが、ユーザーまたはＰａｘにプレゼンテーションするためにアプリ画面に一覧表示される。
【0158】
提案
提案シナリオでは、対応するＡｐｐの入力ボックスをクリックすることによって、ピックアップおよびドロップオフのためのＰＯＩの提案されたリストがＰａｘ（ユーザー）によって取得され得る。ピックアップは通常、Ｐａｘ位置に近いＰＯＩであり、一方、ドロップオフは通常、Ｐａｘが行く必要がある人気度のある場所であり得るので、ピックアップおよびドロップオフは別々に考慮される場合がある。
提案シナリオでは、対応するＡｐｐの入力ボックスをクリックすることによって、ピックアップおよびドロップオフのためのＰＯＩの提案されたリストがＰａｘ（ユーザー）によって取得され得る。ピックアップは通常、Ｐａｘ位置に近いＰＯＩであり、一方、ドロップオフは通常、Ｐａｘが行く必要がある人気度のある場所であり得るので、ピックアップおよびドロップオフは別々に考慮される場合がある。
【0159】
ピックアップ：
ピックアップのために２つのソースを使用することができる。
ピックアップのために２つのソースを使用することができる。
【0160】
第一に、データベース（例えば、プレディクタＤＢ）を使用することができ、その場合、データベースがＰＯＩの優先傾向（preference）に関するテーブルを管理することによって、３０日間の履歴データを保存することができる。これは、Ｐａｘ ＩＤと、対応する過去のピックアップとを格納する。これにより、過去の履歴ピックアップをＰａｘ ＩＤによって照会することができる。
【0161】
第２に、ＰＯＩサービスは、入力としてＰａｘ位置（ｌａｔ／ｌｎｇ）を受け取り、構成に従って異なるプロバイダ（例えば、図５のプロバイダ層５７１ｄを参照）を呼び出すことによって、距離に従って近くのＰＯＩを返す「ｎｅａｒｂｙ」という名前の内部モジュールを有することができる。様々な実施形態では、構成は、サービスがリクエストを行うための異なるプロバイダの優先順位を定義する。例えば、図５を参照すると、内部プロバイダ５７２ａおよびＧｏｏｇｌｅ（外部プロバイダ５７２ｂの一部として）を照会するプロバイダの第１のグループとして設定することができ、満足な結果がない場合、第２のグループ、例えば、（外部プロバイダ５７２ｂの一部としての）Ｆｏｕｒｓｑｕａｒｅを照会することができる。
【0162】
これらの２つのソースを考慮することによって、Ｐａｘの個人的な好みと、Ｐａｘ位置とＰＯＩとの間の距離と、の両方を考慮することができ、これにより、提案されるピックアップの精度を改善することができる。
【0163】
ドロップオフ：
ドロップオフのために２つのソースを使用することができる。
ドロップオフのために２つのソースを使用することができる。
【0164】
第１に、Ｐａｘ ＩＤによって最も頻繁に使用されるドロップオフ（ＭＦＵドロップオフ）をデータベース（例えば、プレディクタＤＢ）に格納する別のテーブルを使用することができる。これにより、最も頻繁に使用されるドロップオフをＰａｘ ＩＤによって照会することができる。
【0165】
第２に、Ｒｅｄｉｓのトップカテゴリを使用することができる。これは、様々な都市において、人気度の高い分類のＰＯＩ（例えば、食品、ショップモール、空港など）を格納し、都市ＩＤによって照会することができる。
【0166】
これらの２つのソースを考慮することによって、Ｐａｘの個人的な好みと他の人の共通の好みの両方が示唆され、示唆されたドロップオフの精度を改善することができる。
【0167】
予測
予測シナリオでは、予約注文を満たすために、予測ピックアップおよび／または予測ドロップオフを提供することができる。同様に、ピックアップとドロップオフは別々に検討することができる。
予測シナリオでは、予約注文を満たすために、予測ピックアップおよび／または予測ドロップオフを提供することができる。同様に、ピックアップとドロップオフは別々に検討することができる。
【0168】
コールドスタート（Cold start）：
古い予約履歴のない新しいＰａｘ（ユーザー）の場合、予測は位置（ｌａｔ／ｌｎｇ）を使用して、コールドスタート問題（cold start problem）に対処または克服するための代替品（フォールバック；fallbackとしてリバースジオ（reverseGeo）を呼び出すことができる。リバースジオは、Ｐａｘの位置をマップ上のＰＩＮと見なして、Ｐａｘに最も近いＰＯＩを見つける。
古い予約履歴のない新しいＰａｘ（ユーザー）の場合、予測は位置（ｌａｔ／ｌｎｇ）を使用して、コールドスタート問題（cold start problem）に対処または克服するための代替品（フォールバック；fallbackとしてリバースジオ（reverseGeo）を呼び出すことができる。リバースジオは、Ｐａｘの位置をマップ上のＰＩＮと見なして、Ｐａｘに最も近いＰＯＩを見つける。
【0169】
ピックアップ：
いくつかの予約履歴を有するＰａｘの場合、ピックアップ予測のための２つのソース、例えば、最後のドロップオフファースト（Last Dropoff First；ＬＤＦ）およびデータベース（例えば、プレディクタＤＢ）内のテーブルが存在する場合がある。データベースに保存されているユーザーの過去のピックアップＰＯＩを使用することができる。これは、Ｐａｘ ＩＤおよびｗｉｆｉ ＳＳＩＤ（サービスセット識別子）を照会して、過去のピックアップＰＯＩを取得することで実行できる。すなわち、過去に出現していたＰａｘの場所を、予測のピックアップとして推奨することができる。データベース（例えばプレディクタＤＢ）に記録が見つからない場合は、ＬＤＦを使用してもよい。ＬＤＦは、過去２４時間以内のＰａｘの最後のドロップオフ時間である。プレディクタＤＢおよびＬＤＦの両方について、ユーザー位置に最も近いＰＯＩが返される。すべてのＰＯＩがある（または閾値）距離から外れている場合、リバースジオに依拠することができる。
いくつかの予約履歴を有するＰａｘの場合、ピックアップ予測のための２つのソース、例えば、最後のドロップオフファースト（Last Dropoff First；ＬＤＦ）およびデータベース（例えば、プレディクタＤＢ）内のテーブルが存在する場合がある。データベースに保存されているユーザーの過去のピックアップＰＯＩを使用することができる。これは、Ｐａｘ ＩＤおよびｗｉｆｉ ＳＳＩＤ（サービスセット識別子）を照会して、過去のピックアップＰＯＩを取得することで実行できる。すなわち、過去に出現していたＰａｘの場所を、予測のピックアップとして推奨することができる。データベース（例えばプレディクタＤＢ）に記録が見つからない場合は、ＬＤＦを使用してもよい。ＬＤＦは、過去２４時間以内のＰａｘの最後のドロップオフ時間である。プレディクタＤＢおよびＬＤＦの両方について、ユーザー位置に最も近いＰＯＩが返される。すべてのＰＯＩがある（または閾値）距離から外れている場合、リバースジオに依拠することができる。
【0170】
ＬＤＦはＰａｘの最後のドロップオフを取得するために、プレディクタＤＢとは異なるデータベース（予約ＤＢなど）にアクセスする別の（マイクロ）サービスから取得される場合がある。予約ＤＢは、ＭｙＳＱＬに配置または保存される場合がある。予約ＤＢは、例えば、通信サーバ装置において、サーバ側に配置されてもよい。予約ＤＢは予約情報、例えば、予約コード、タイムスタンプ、乗客ＩＤ、ピックアップおよびドロップオフなどのうちの１つ以上を格納することができる。
【0171】
ドロップオフ：
ドロップオフ予測のために、１日の時間帯ごとに各乗客（またはユーザー）のピックアップとドロップオフとを対にするデータベース（例えば、プレディクタＤＢ）内のテーブルを使用することができる。任意のＰａｘ ＩＤおよび時間帯が与えられると、ピックアップおよびドロップオフの対は、クエリによって容易に取得され得る。同じピックアップと対になる過去のドロップオフは、Ｐａｘのドロップオフ予測として使用されてもよい。すなわち、ドロップオフ予測では、人々が毎日のルーチンに従う可能性が高いと仮定することができる。１日の同じ時間帯に過去の予約で選択されたＰａｘを同じドロップオフが推奨される場合がある。
ドロップオフ予測のために、１日の時間帯ごとに各乗客（またはユーザー）のピックアップとドロップオフとを対にするデータベース（例えば、プレディクタＤＢ）内のテーブルを使用することができる。任意のＰａｘ ＩＤおよび時間帯が与えられると、ピックアップおよびドロップオフの対は、クエリによって容易に取得され得る。同じピックアップと対になる過去のドロップオフは、Ｐａｘのドロップオフ予測として使用されてもよい。すなわち、ドロップオフ予測では、人々が毎日のルーチンに従う可能性が高いと仮定することができる。１日の同じ時間帯に過去の予約で選択されたＰａｘを同じドロップオフが推奨される場合がある。
【0172】
次に、実稼働環境におけるＰＯＩサービスの性能について説明する。まず、生産環境設定と性能を測定するためのメトリクス（metrics）について説明し、次に、ＰＯＩサービスのメトリクスによる性能結果について説明する。
【0173】
生産環境設定・計測メトリクス
ＰＯＩサービスの構成は、Ａｍａｚｏｎ ｃ５．４ｘｌａｒｇｅ ＥＣ２インスタンスである。ｃ５．４ｘｌａｒｇｅインスタンスの場合、Ａｍａｚｏｎは１６個の仮想ＣＰＵコアと３２Ｇメモリを提供する。ストレージはＥＢＳ専用で、専用ＥＢＳ帯域幅は３，５００Ｍｂｐｓである。また、ネットワーク性能のために最大１０Ｇｂｐｓの帯域幅が提供される。ＡｍａｚｏｎのＥｌａｓｔｉｃａｃｈｅは、オンラインＰＯＩ推奨を実施するためのキャッシュに使用される。
ＰＯＩサービスの構成は、Ａｍａｚｏｎ ｃ５．４ｘｌａｒｇｅ ＥＣ２インスタンスである。ｃ５．４ｘｌａｒｇｅインスタンスの場合、Ａｍａｚｏｎは１６個の仮想ＣＰＵコアと３２Ｇメモリを提供する。ストレージはＥＢＳ専用で、専用ＥＢＳ帯域幅は３，５００Ｍｂｐｓである。また、ネットワーク性能のために最大１０Ｇｂｐｓの帯域幅が提供される。ＡｍａｚｏｎのＥｌａｓｔｉｃａｃｈｅは、オンラインＰＯＩ推奨を実施するためのキャッシュに使用される。
【0174】
異なるシナリオ／アプリケーションにおけるＰＯＩサービスの安定性を測定するために、リクエストを送信してからレスポンスが返されるまでの期間に相当する往復時間（round trip time；ＲＴＴ）が示されている。ＲＴＴをより適切に説明するために、測定は９５パーセンタイルおよび９９パーセンタイルに関して行われる。ピーク時と非ピーク時との間のＲＴＴの変動が少ないほど、システムはより安定である。
【0175】
図５を参照すると、システム内のキャッシュの使用により、キャッシュの有効性は、ＡＰＩ５７１ａ、ミドルウェア５７１ｂ、およびプロバイダ５７１ｄ層内のキャッシュヒット率に関して測定される。ＡＰＩ層５７１ａについては、予測シナリオで使用されるプレディクタキャッシュ５７６は、非限定的な例として使用される。ミドルウェア層５７１ｂについては、ブラックリストチェック用のメタキャッシュ５７９ａが非限定的な例として使用される。プロバイダ層５７１ｆについては、内部プロバイダ５７２ａおよび外部プロバイダ５７２ｂの代わりに、内部プロバイダおよびＧｏｏｇｌｅ用のキャッシュ５８１、５８３ａがそれぞれ示されている。
【0176】
性能結果
ＰＯＩサービスの性能は、上述の測定メトリクスに従って３つの態様で示され、説明される。まず、１日の全体的な性能を示す。次に、シナリオ予測、提案、検索、およびリバースジオの往復時間（ＲＴＴ）の性能を示す。最後に、ＰＯＩサービスにおけるキャッシュの使用法を示す。
ＰＯＩサービスの性能は、上述の測定メトリクスに従って３つの態様で示され、説明される。まず、１日の全体的な性能を示す。次に、シナリオ予測、提案、検索、およびリバースジオの往復時間（ＲＴＴ）の性能を示す。最後に、ＰＯＩサービスにおけるキャッシュの使用法を示す。
【0177】
ＰＯＩサービスの全体的な性能：
統計に基づいて、ＰＯＩサービスの１秒あたりのクエリ（ＱＰＳ）は、１日の間で異なる。午前７：００～午前９：００、午後１７：００～午後２０：００の時間帯をピーク時間と定義する。ピークＱＰＳ値は一般に、午後６：００付近に現れる。ＱＰＳは深夜に非常に低くなる。平均ＱＰＳは、インスタンスあたり約２００である。ＣＰＵ使用率は、予想通りＱＰＳによって異なる。１日あたりの最大ＣＰＵ使用率は６０％未満に制御される。ゴールーチンに関しては、ＱＰＳが多いほど、生成されるゴールーチンが多くなり、ＣＰＵ使用量が増加することになる。ゴールーチンの数の平均値は、インスタンスあたり約１．２ｋである。メモリ使用量は、インスタンスあたり約２５Ｇの値で、一日中安定している。
統計に基づいて、ＰＯＩサービスの１秒あたりのクエリ（ＱＰＳ）は、１日の間で異なる。午前７：００～午前９：００、午後１７：００～午後２０：００の時間帯をピーク時間と定義する。ピークＱＰＳ値は一般に、午後６：００付近に現れる。ＱＰＳは深夜に非常に低くなる。平均ＱＰＳは、インスタンスあたり約２００である。ＣＰＵ使用率は、予想通りＱＰＳによって異なる。１日あたりの最大ＣＰＵ使用率は６０％未満に制御される。ゴールーチンに関しては、ＱＰＳが多いほど、生成されるゴールーチンが多くなり、ＣＰＵ使用量が増加することになる。ゴールーチンの数の平均値は、インスタンスあたり約１．２ｋである。メモリ使用量は、インスタンスあたり約２５Ｇの値で、一日中安定している。
【0178】
様々なシナリオ／アプリケーションにおけるＰＯＩサービスの性能：
図７Ａ～７Ｄは、それぞれ、シナリオ予測、提案、検索、およびリバースジオのＲＴＴを示す。図７Ａ～７ＤのＹ軸は単位「ｍｓ」での往復時間（ＲＴＴ）を表す。図７Ａ～７ＤのＸ軸のラベル「水１６」は、ある月の新しい日の開始を示し、１６日水曜日であることを指す。
図７Ａ～７Ｄは、それぞれ、シナリオ予測、提案、検索、およびリバースジオのＲＴＴを示す。図７Ａ～７ＤのＹ軸は単位「ｍｓ」での往復時間（ＲＴＴ）を表す。図７Ａ～７ＤのＸ軸のラベル「水１６」は、ある月の新しい日の開始を示し、１６日水曜日であることを指す。
【0179】
図７Ａ～７Ｄでは、「警告（Warning）」および「ＣＢオープン（CB Open）」として示されるそれぞれの破線は、それぞれ、サービス安全のための時間閾値、およびサービスがリクエストされた時間内にリクエストに応答できず、応答しないものとして扱われる可能性がある時間閾値を指す。
【0180】
観察され得るように、２つの実線が、図７Ａ～７Ｄの各々について示される。上の実線は「Ｐ９９」、つまり統計データの９９パーセンタイルを表し、下の実線は、「Ｐ９５」、つまり統計データの９５パーセンタイルを表す。
【0181】
図７Ｃの検索について観察され得るように、９５パーセンタイル（95 Percentile）および９９パーセンタイル（99 Percentile）に関するＲＴＴは、それぞれ５００ｍｓおよび７３０ｍｓである。ＲＴＴは、ＱＰＳが１日の時間と共にどのように変化しても安定である。さらに、図７Ａの予測、図７Ｂの提案、および図７Ｄのリバースジオの結果は、ＲＴＴに関して同様の安定性を示す。以下の表１に示すように、ＲＴＴの９５パーセンタイル／９９パーセンタイルはシナリオごとに異なる。検索（Search）およびリバースジオ（ReverseGeo）のロジックは、外部プロバイダ（例えば、ＧｏｏｇｌｅまたはＦｏｕｒｓｑｕａｒｅ）またはエラスティックサーチを照会することを含み、これにより、予測（Predict）および提案（Suggest）と比較してＲＴＴが長くなる。
【0182】
表１は、さまざまなシナリオのＲＴＴである。
【表1】
【0183】
ＰＯＩサービスにおけるキャッシュの性能：
表２は、プレディクタＤＢキャッシュ５７６（ＡＰＩ層５７１ａの場合）、メタキャッシュ５７９ａ（ミドルウェア層５７１ｂの場合）、内部プロバイダキャッシュ５８１（内部プロバイダ５７２ａの場合）、およびＧｏｏｇｌｅキャッシュ５８３ａ（外部プロバイダ５７２ｂの場合）の１日平均キャッシュヒット率（Cache hit ratio）を示している。観察さ得るように、予測値ＤＢキャッシュ５７６およびメタキャッシュ５７９ａにおける高いキャッシュヒット率は、データベースへの重複リクエストを最小化または回避するという観点から、キャッシュ使用の有効性を示している。プロバイダ層５７１ｄについては、内部プロバイダキャッシュ５８１のキャッシュヒット率が外部プロバイダのＧｏｏｇｌｅキャッシュ５８３ａのそれよりもはるかに低い。これは、内部プロバイダが頻繁に更新され、そのキャッシュ５８１のＴＴＬが外部プロバイダ５７２ｂよりもはるかに短いためである。
表２は、プレディクタＤＢキャッシュ５７６（ＡＰＩ層５７１ａの場合）、メタキャッシュ５７９ａ（ミドルウェア層５７１ｂの場合）、内部プロバイダキャッシュ５８１（内部プロバイダ５７２ａの場合）、およびＧｏｏｇｌｅキャッシュ５８３ａ（外部プロバイダ５７２ｂの場合）の１日平均キャッシュヒット率（Cache hit ratio）を示している。観察さ得るように、予測値ＤＢキャッシュ５７６およびメタキャッシュ５７９ａにおける高いキャッシュヒット率は、データベースへの重複リクエストを最小化または回避するという観点から、キャッシュ使用の有効性を示している。プロバイダ層５７１ｄについては、内部プロバイダキャッシュ５８１のキャッシュヒット率が外部プロバイダのＧｏｏｇｌｅキャッシュ５８３ａのそれよりもはるかに低い。これは、内部プロバイダが頻繁に更新され、そのキャッシュ５８１のＴＴＬが外部プロバイダ５７２ｂよりもはるかに短いためである。
【0184】
表２は、異なる層のキャッシュのキャッシュヒット率である。
【表2】
【0185】
上述したように、ＰＯＩ（ｐｏｉｎｔ－ｏｆ－ｉｎｔｅｒｅｓｔ）推奨のための技術をリアルタイムで提供することができる。輸送サービス（乗り物輸送サービスなど）の場合、例えば、予約注文を（例えば、Ａｐｐを介して）作成または生成するとき、ユーザーは１つ以上のアクションを実行して、ピックアップおよび／またはドロップオフのための所望のＰＯＩを見つけることができる。これらのアクションは（ｉ）予測ピックアップＰＯＩおよび／または予測ドロップオフＰＯＩがユーザーの履歴データまたは現在位置のうちの少なくとも１つに基づいて行われる「予測」と、（ｉｉ）ユーザーが入力フィールドをクリックして、ユーザーの履歴データ、現在位置、または関連する都市の人気度ＰＯＩのうちの少なくとも１つに基づいてＰＯＩの提案リストを取得する「提案」と、（ｉｉｉ）キーワードに基づくＰＯＩの一致リストが提供されるように、ユーザーが情報、例えばキーワードを入力する「検索」と、（ｉｖ）ユーザーがマップに移動してＰＩＮを見つけることができる「リバースジオ」とを含むことができる。これらのアクションは互いに独立したものとすることができる。これらのアクションは任意の順序で発生する場合と、シーケンスの順序で発生する場合があり、例えば、「予測」が最初に実行され、続いて、予測結果が期待された「検索」でない場合に「提案」が実行され、提案結果が期待通りでない場合、および提案／検索結果が期待通りでない場合、「リバースジオ（リバースジオ）」が実行される。予約フローはＰＯＩをピックアップまたはドロップオフとして見つけるために、予測／提案／検索／リバースジオを使用する順序で定義することができる。順序は、ユーザーの労力（画面／Ａｐｐ上のクリック数で測定）をどれだけ節約または最小限に抑えられるかに基づいていてもよい。
【0186】
それでも、１つの予約注文ごとに４つのアクションのすべてを実行する必要はないことを理解されたい。言い換えれば、アクション、予測、提案、検索、リバースジオのうちのいずれか１つ、２つ、または３つ、またはすべては、ユーザーが輸送関連サービスの予約注文を行う過程で実行することができる。非限定的な例として、ユーザーは任意のアクションまたはステップをスキップして、任意のアクションを自由に使用することができ、例えば、予測の後に、ユーザーは提案および／または検索を経由せずに、リバースジオに直接ジャンプすることができる。
【0187】
様々な実施形態では、予測、提案、および検索のアクションは履歴データを使用することによって個別に実行され、所望のピックアップおよびドロップオフを得るためのより良い推奨性能を提供することができる。提案および予測の場合、履歴データは異なるテーブル内のデータベース、例えば、プレディクタデータベースに格納されてもよい。検索の場合、１つ以上の側面／基準、すなわち、名前キーワード、領域、人気度、タイミング、および距離を考慮して、ＰＯＩランク付けの結果得られるスコア、例えば、結合スコアとしての加重和を計算することができる。
【0188】
検索の場合、加重和による最終スコアは各ＰＯＩについての以下の基準のスコアを使用して計算されてもよく、ＰＯＩは次に、スコアに従って降順でランク付けされ、推奨されるＰＯＩのリストがユーザーに提供される。
（ｉ）キーワード：検索キーワードとＰＯＩ名またはＰＯＩ名の頭字語とに基づいてスコアが提供され、類似性または一致するものがある場合にスコアが高くなる；
（ｉｉ）領域：スコアは、ユーザーの領域（例えば、国）とＰＯＩ領域との間の関連性または近接性に基づいて提供され、２つの領域が同じである場合には「１」のスコアを有し、それ以外の場合には「０」のスコアを有する（対応するＰＯＩは、その後、検索リストから除外される）；
（ｉｉｉ）人気度：ＰＯＩがピックアップ（ピックアップ検索の場合）またはドロップオフ（ドロップオフ検索の場合）として選択された回数に基づいてスコアが提供され、ＰＯＩが選択された回数が多いほどスコアが高くなる；
（ｉｖ）タイミング：ユーザーが特定のＰＯＩにおいてピックアップまたはドロップオフを行う確率に基づいてスコアが定義され、輸送サービスが必要とされるその特定の時間にＰＯＩにおいてピックアップ（ピックアップ検索の場合）またはドロップオフ（ドロップオフ検索の場合）を行う確率が高い場合、スコアが高くなる；
（ｖ）距離（ピックアップ検索にのみ適用可能）：ＰＯＩとユーザーの位置との間の距離に基づいてスコアが提供され、距離が短いほどスコアが高くなる。
（ｉ）キーワード：検索キーワードとＰＯＩ名またはＰＯＩ名の頭字語とに基づいてスコアが提供され、類似性または一致するものがある場合にスコアが高くなる；
（ｉｉ）領域：スコアは、ユーザーの領域（例えば、国）とＰＯＩ領域との間の関連性または近接性に基づいて提供され、２つの領域が同じである場合には「１」のスコアを有し、それ以外の場合には「０」のスコアを有する（対応するＰＯＩは、その後、検索リストから除外される）；
（ｉｉｉ）人気度：ＰＯＩがピックアップ（ピックアップ検索の場合）またはドロップオフ（ドロップオフ検索の場合）として選択された回数に基づいてスコアが提供され、ＰＯＩが選択された回数が多いほどスコアが高くなる；
（ｉｖ）タイミング：ユーザーが特定のＰＯＩにおいてピックアップまたはドロップオフを行う確率に基づいてスコアが定義され、輸送サービスが必要とされるその特定の時間にＰＯＩにおいてピックアップ（ピックアップ検索の場合）またはドロップオフ（ドロップオフ検索の場合）を行う確率が高い場合、スコアが高くなる；
（ｖ）距離（ピックアップ検索にのみ適用可能）：ＰＯＩとユーザーの位置との間の距離に基づいてスコアが提供され、距離が短いほどスコアが高くなる。
【0189】
提案の場合、（例えば、Ａｐｐ内の）関連する入力フィールドをクリックすることによって、ピックアップおよびドロップオフのために提案されたＰＯＩのリストが提供される。ピックアップは通常、ユーザー位置に近いＰＯＩであるが、ドロップオフは通常、ユーザーが行く必要がある人気度のある場所であるため、ピックアップとドロップオフとは別々に考慮される。ピックアップに関しては、２つのソースが考えられる。すなわち、（ｉ）過去のユーザーＩＤと対応するピックアップを格納するテーブルに、ＰＯＩの優先傾向に関する３０日間の履歴データを格納するデータベース（例えば、プレディクタデータベース）であり、ユーザーＩＤによって過去の履歴ピックアップを照会することを可能にする。（ｉｉ）ユーザー位置（緯度／経度）が入力として使用され、距離に応じて近くのＰＯＩが提供される。したがって、ユーザーの個人的な好みと、ユーザーＰａｘ位置とＰＯＩとの間の距離との両方を考慮することができ、それによって、提案されるピックアップの精度を向上させることができる。ドロップオフに関しては、２つのソースが考えられる。すなわち、（ｉ）ユーザーＩＤによる最も頻繁に使用されるドロップオフ（ＭＦＵドロップオフ）に関するデータを別個のテーブルに格納するデータベース（例えば、プレディクタデータベース）であり、これは、ユーザーＩＤによって最も頻繁に使用されるドロップオフを照会することを可能にする。（ｉｉ）様々な都市において人気のあるＰＯＩ（例えば、食品、ショップモール、空港など）が分類されており、都市ＩＤによって照会することができる。したがって、ユーザーの個人的な好みと一般的な共通の好みの両方を提案することができ、それによって、提案されるドロップオフの精度を向上させることができる。
【0190】
予測のために、ピックアップが予測されてもよく、および／または、ドロップオフが予約注文を満たすように予測されてもよい。提案と同様に、ピックアップとドロップオフは別々に考えることができる。ユーザーが履歴予約データを有するピックアップに関して、ピックアップ予測のために２つのソース、すなわち、最後のドロップオフファースト（ＬＤＦ）と、データベース（例えば、プレディクタデータベース）内のデータを有するテーブルとを考慮することができる。ＬＤＦは、２４時間以内のユーザーの最後のドロップオフ時間である。ＰａｘのＬＤＦがない場合は、データベース（プレディクタＤＢ）に保存されているユーザーの過去のピックアップＰＯＩが使用されることがある。これは、過去のピックアップＰＯＩを取得するためにユーザーＰａｘ ＩＤおよびｗｉｆｉ ＳＳＩＤを照会することによって行うことができる。すなわち、ユーザーが過去に現れた場所を、予測のピックアップとして推奨することができる。ユーザーが過去の予約データを有するドロップオフに関して、１日の時間単位で各ユーザーのピックアップとドロップオフをペアにするデータベース（例えば、プレディクタデータベース）内のテーブルを使用することができる。ユーザーＩＤおよび期間が与えられると、ピックアップおよびドロップオフのペアは、クエリによって取得することができる。同じピックアップとペアになる過去のドロップオフは、ユーザーのためのドロップオフ予測として使用することができる。すなわち、ドロップオフ予測では、人々が毎日のルーチンに従う可能性が高いと仮定することができる。過去の予約で選択されたユーザーを、その日の同じ時間帯に同じドロップオフを推奨することができる。履歴予約データがない新規ユーザーの「コールドスタート」の文脈では、ユーザーの位置（緯度／経度）をマップ上のＰＩＮとして使用して、ユーザーに最も近いＰＯＩを見つけることができる（上記の「リバースジオ」と同様）。
【0191】
また、上述したように、様々な実施形態のＰＯＩ（ｐｏｉｎｔ ｏｆ ｉｎｔｅｒｅｓｔ）は、Ｇｏｌａｎｇベースのマイクロサービスアーキテクチャを用いて構築することができる。オンラインの課題は、適切または独自のシナリオまたはアプリケーションに従って技術を展開することで対処することができる。ＰＯＩサービスは適切なピックアップポイントおよび／またはドロップオフポイントを見つける際の乗客の労力を節約しながら、完了した予約の比率を増加させるのに役立つ場合がある。予測、提案、または検索のいずれかは、潜在的に、ユーザー（または乗客）の習慣または好みに従ってカスタマイズされ得ることが理解されるであろう。さらに、システムの内部モジュールの時間コストを最適化することができる。
【0192】
本発明は、例としてのみ記載されていることが理解されよう。添付の特許請求の範囲の精神および範囲から逸脱することなく、本明細書に記載の技術に様々な修正を加えることができる。開示された技術は、独立した方式で、または互いに組み合わせて提供され得る技術を含む。したがって、１つの技術に関して説明した特徴は、別の技術と組み合わせて提示することもできる。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図2G】
【図2H】
【図2I】
【図3A】
【図3B】
【図3C】
【図3D】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図7C】
【図7D】
