本發(fā)明涉及智能交通技術(shù)領(lǐng)域，尤其涉及一種拼車方法和系統(tǒng)。

背景技術(shù)：

隨著能源成本的持續(xù)增長，以及城市交通的日益堵塞，需要提高現(xiàn)有車輛的利用效率，利用現(xiàn)存的車輛能承載更多的乘客?，F(xiàn)有的公共交通雖然具有載客量大、成本低廉的優(yōu)點，但是它沿規(guī)劃路線上停若干站，從而延長了乘客的通勤時間，缺乏便利性。因此，提倡共享出行的拼車服務(wù)應運而生，既可以在一定程度上提高現(xiàn)有車輛的利用效率，也可以縮短乘客的通勤時間。

在現(xiàn)有的拼車服務(wù)中，為了保證乘客的乘車體驗和控制乘客行程所耗時間，僅允許兩個乘客共享一個行程，因此只要其中一個乘客行程結(jié)束下車后，另一乘客的剩余行程不論有多長都需獨自完成，這就造成拼車效率較低，浪費資源。

技術(shù)實現(xiàn)要素：

為此，本發(fā)明提供一種拼車方法和系統(tǒng)，可以提高行程中的共乘比例，從而提高拼車率。

第一方面，本發(fā)明提供的拼車方法包括：

若接收到終端發(fā)送的載客請求，所述載客請求為所述終端在所屬車輛中的至少一個乘客結(jié)束行程后發(fā)出的包括所述車輛中剩余乘客的剩余行程信息的請求；

則根據(jù)所述載客請求，判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單，所述訂單為根據(jù)用戶設(shè)備發(fā)送的打車請求生成的訂單；

若是，則將相匹配的訂單發(fā)送至所述終端，并將所述終端的所屬 車輛信息發(fā)送至相匹配訂單所對應的用戶設(shè)備。

可選的，將相匹配的訂單發(fā)送至所述終端之前，所述方法還包括：

向相匹配訂單所對應的用戶設(shè)備發(fā)送拼車確認信息；

若接收到所述用戶設(shè)備根據(jù)所述拼車確認信息反饋的同意拼車的響應，則允許執(zhí)行將相匹配的訂單發(fā)送至所述終端的步驟。

可選的，所述根據(jù)所述載客請求，判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單，包括：

根據(jù)所述剩余行程信息和根據(jù)用戶設(shè)備發(fā)送的打車請求所生成的訂單中的行程信息，計算所述剩余乘客與發(fā)送該訂單的用戶設(shè)備的所屬用戶拼車時所述剩余乘客的繞路比例和所述所屬用戶的繞路比例；

判斷所述剩余乘客的繞路比例和所述所屬用戶的繞路比例是否均小于預設(shè)值；

若是，則確定該訂單為與所述載客請求中的剩余行程信息相匹配的訂單。

可選的，判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單之前，所述方法還包括：

判斷接收到載客請求的時刻是否處于平峰期內(nèi)；

若是，則允許執(zhí)行判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單的步驟；

否則，向所述終端發(fā)送拒絕所述載客請求的提示信息。

可選的，所述方法還包括：

若不存在與所述載客請求中的剩余行程信息相匹配的訂單，則每經(jīng)歷預設(shè)時長后執(zhí)行：

步驟a：根據(jù)所述載客請求中的剩余行程信息和所述終端所屬車輛的當前位置坐標，確定所述剩余乘客在當前時刻的剩余行程信息；

步驟b：判斷是否存在與所述剩余乘客在當前時刻的剩余行程信 息相匹配的訂單；

若是，則結(jié)束步驟a和步驟b的周期性執(zhí)行，并將與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單發(fā)送至所述終端，將所述終端的所屬車輛信息發(fā)送至與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單所對應的用戶設(shè)備。

第二方面，本發(fā)明提供的拼車系統(tǒng)包括：

判斷模塊，用于在接收到終端發(fā)送的載客請求時，所述載客請求為所述終端在所屬車輛中的至少一個乘客結(jié)束行程后發(fā)出的包括所述車輛中剩余乘客的剩余行程信息的請求；根據(jù)所述載客請求，判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單，所述訂單為根據(jù)用戶設(shè)備發(fā)送的打車請求生成的訂單；

發(fā)送模塊，用于在所述判斷模塊的判斷結(jié)果為是時，將相匹配的訂單發(fā)送至所述終端，并將所述終端的所屬車輛信息發(fā)送至相匹配訂單所對應的用戶設(shè)備。

可選的，該系統(tǒng)還包括：

確認模塊，用于向相匹配訂單所對應的用戶設(shè)備發(fā)送拼車確認信息；若接收到所述用戶設(shè)備根據(jù)所述拼車確認信息反饋的同意拼車的響應，則允許所述發(fā)送模塊執(zhí)行將相匹配的訂單發(fā)送至所述終端的步驟。

可選的，所述判斷模塊包括：

計算單元，用于根據(jù)所述剩余行程信息和根據(jù)用戶設(shè)備發(fā)送的打車請求所生成的訂單中的行程信息，計算所述剩余乘客與發(fā)送該訂單的用戶設(shè)備的所屬用戶拼車時所述剩余乘客的繞路比例和所述所屬用戶的繞路比例；

判斷單元，用于判斷所述剩余乘客的繞路比例和所述所屬用戶的繞路比例是否均小于預設(shè)值；

確定單元，用于在所述判斷單元的判斷結(jié)果為是時，確定該訂單 為與所述載客請求中的剩余行程信息相匹配的訂單。

可選的，所述判斷模塊還用于：

判斷接收到載客請求的時刻是否處于平峰期內(nèi)；

若是，則允許所述判斷模塊執(zhí)行判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單的步驟；

否則，向所述終端發(fā)送拒絕所述載客請求的提示信息。

可選的，所述系統(tǒng)還包括循環(huán)模塊；

所述循環(huán)模塊用于在不存在與所述載客請求中的剩余行程信息相匹配的訂單時，每經(jīng)歷預設(shè)時長后執(zhí)行：

步驟a：根據(jù)所述載客請求中的剩余行程信息和所述終端所屬車輛的當前位置坐標，確定所述剩余乘客在當前時刻的剩余行程信息；

步驟b：判斷是否存在與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單；

若是，則結(jié)束步驟a和步驟b的周期性執(zhí)行，并將與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單發(fā)送至所述終端，將所述終端的所屬車輛信息發(fā)送至與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單所對應的用戶設(shè)備。

根據(jù)以上技術(shù)方案，當有部分的乘客下車后，終端發(fā)出載客請求，當存在與載客請求相匹配的訂單時，就可使該相匹配訂單所對應打車請求的發(fā)出者與車輛內(nèi)的剩余乘客共乘該車輛?？梢?，相對于現(xiàn)有技術(shù)中當有部分乘客下車后剩余乘客只能單獨完成剩余行程的乘車方式來說，本發(fā)明提供的拼車方法可以提高行程中的共乘比例，從而提高拼車率。

附圖說明

為了更清楚地說明本公開實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本公開的一些實施例，對于 本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些圖獲得其他的附圖。

圖1示出了本公開一實施例提供的拼車方法的流程示意圖；

圖2示出了利用本公開一實施例提供的拼車方法進行拼車的車輛行程圖；

圖3示出了本公開另一實施例提供的拼車方法的流程示意圖；

圖4示出了本公開另一實施例提供的拼車方法的流程示意圖；

圖5示出了本公開一實施例提供拼車系統(tǒng)的結(jié)構(gòu)框圖。

具體實施方式

下面將結(jié)合本公開實施例中的附圖，對本公開實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒竟_中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本公開保護的范圍。

以下對本公開實施例中提及的部分詞語進行舉例說明。

本公開實施例中提及的用戶設(shè)備(userequipment，簡稱ue)是指呼叫服務(wù)方，如交通工具叫車服務(wù)中的乘客，所使用的移動終端或個人計算機(personalcomputer，簡稱pc)等設(shè)備。例如智能手機、個人數(shù)碼助理(pda)、平板電腦、筆記本電腦、車載電腦(carputer)、掌上游戲機、智能眼鏡、智能手表、可穿戴設(shè)備、虛擬顯示設(shè)備或顯示增強設(shè)備(如googleglass、oculusrift、hololens、gearvr)等。

本公開實施例中提及的終端為提供服務(wù)方，如交通工具叫車服務(wù)中的司機，所使用的用于接單的移動終端或pc端等設(shè)備。諸如上述呼叫服務(wù)方所使用各設(shè)備。本實施例中，為了區(qū)別乘客和司機，分別采用用戶設(shè)備和終端來分別表示乘客和司機所持的移動終端等設(shè)備。

如圖1所示，本公開一實施例提供一種拼車方法，該拼車方法包括如下步驟：

s100、若接收到終端發(fā)送的載客請求，所述載客請求為所述終端在所屬車輛中的至少一個乘客結(jié)束行程后發(fā)出的包括所述車輛中剩余乘客的剩余行程信息的請求；

則根據(jù)所述載客請求，判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單，所述訂單為根據(jù)用戶設(shè)備發(fā)送的打車請求生成的訂單；

載客請求，例如，當車輛中有兩個乘客時，其中一個乘客行程結(jié)束下車后，終端發(fā)出的一個包含未下車的那個乘客的剩余行程信息的請求。

可理解的是，盡管目前為了保證乘客的乘車體驗，控制共享出行的乘客在兩個以內(nèi)。當然，在未下車乘客允許的情況下，共享出行的乘客數(shù)量也可以適當?shù)脑黾?，例如控制共享出行的乘客在三個以內(nèi)。這時，當有一個或兩個乘客下車時，終端就可以發(fā)出載客請求。

可理解的是，打車請求為有乘車需求的用戶發(fā)出，生成的訂單中應當包括該用戶的行程信息。

s200、若存在與所述載客請求中的剩余行程信息相匹配的訂單，則將相匹配的訂單發(fā)送至所述終端，并將所述終端的所屬車輛信息發(fā)送至相匹配訂單所對應的用戶設(shè)備。

可理解的是，相匹配的訂單，是指與載客請求中的剩余行程信息相匹配的訂單。

舉例來說，如圖2所示，乘客a和乘客b共乘一段路程后，乘客b下車，乘客c上車，乘客a與乘客c共乘一段路程后，乘客a下車，而后乘客c下車?？梢?，整個過程中乘客a分別與乘客b、乘客c共享一段路程，提高了行程中的共乘比例。

本實施例提供的拼車方法中，當有部分的乘客下車后，終端發(fā)出 載客請求，當存在與載客請求相匹配的訂單時，就可使該相匹配訂單所對應打車請求的發(fā)出者與與車輛內(nèi)的剩余乘客共乘該車輛?？梢?，相對于現(xiàn)有技術(shù)中當有部分乘客下車后剩余乘客只能單獨完成剩余行程的乘車方式來說，本實施例提供的拼車方法可以提高行程中的共乘比例，從而提高拼車率。

本實施例中，當s100中的判斷結(jié)果為不存在與所述載客請求中的剩余行程信息相匹配的訂單，此時無法進行拼車，因此本實施例提供的拼車方法還可包括：

若不存在與所述載客請求中的剩余行程信息相匹配的訂單，則每經(jīng)歷預設(shè)時長后執(zhí)行：

步驟a：根據(jù)所述載客請求中的剩余行程信息和所述終端所屬車輛的當前位置坐標，確定所述剩余乘客在當前時刻的剩余行程信息；

步驟b：判斷是否存在與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單；

若是，則結(jié)束步驟a和步驟b的周期性執(zhí)行，并將與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單發(fā)送至所述終端，將所述終端的所屬車輛信息發(fā)送至與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單所對應的用戶設(shè)備。

可理解的是，若在接收到載客請求時，經(jīng)判斷沒有與載客請求中的剩余行程信息相匹配的訂單，而由于車輛一直在行駛中，因此剩余乘客的剩余行程是一直發(fā)生變化的，因此再次進行匹配判斷時需要重新計算剩余乘客的剩余行程，確定剩余行程信息。舉例來說，在接收到載客請求時，剩余行程信息為從a地到c地的10公里，而經(jīng)歷一個預設(shè)時長后，重新確定的剩余行程信息為從b地到c地的9.55公里。

可以理解的是，預設(shè)時長可以根據(jù)實際需求設(shè)定，例如1秒。

可理解的是，上述判斷過程中若一直不存在相匹配的訂單，則在剩余乘客結(jié)束行程前的一段時間內(nèi)便不再執(zhí)行循環(huán)過程。

本實施例中s100的具體判斷過程可以有多種不同的實現(xiàn)方法，這里不做限定，其中一種實現(xiàn)方法可包括圖中未示出的：

s101、根據(jù)所述終端的所屬車輛中剩余乘客的剩余行程信息和在所述預設(shè)時間段內(nèi)接收到的每一訂單信息中的行程信息，計算所述剩余乘客與發(fā)送該訂單信息的用戶共乘時所述剩余乘客的繞路比例和發(fā)送該訂單信息的用戶的繞路比例；

s102、判斷所述剩余乘客的繞路比例和所述所屬用戶的繞路比例是否均小于預設(shè)值；

s103、在判斷結(jié)果為是時，確定該訂單為與所述載客請求中的剩余行程信息相匹配的訂單。

其中，預設(shè)值可以根據(jù)需要進行設(shè)定，例如1.2。

例如，車輛內(nèi)的剩余乘客在不繼續(xù)拼車的情況下，剩余行程為100公里。若繼續(xù)拼車的話，可能需要一定的繞路接送拼車用戶，假如與其他人拼車后需要走110公里才能到達目的地，則該剩余乘客的繞路比例為1.1，在此過程中，拼車用戶的原本行程為50公里，若與該剩余乘客共乘的情況下，需要走60公里才能達到目的地，這樣的話該拼車用戶的繞路比例為1.2。

這里通過判斷繞路比例的方式判斷匹配度，簡單、方便，同時可以保證乘客的用戶體驗。

如圖3所示，本公開另一實施例提供一種拼車方法，本實施例提供的拼車方法中的s100’、s400’與上述實施例中的s100、s200相同，本實施例提供的拼車方法中除了s100’、s400’外還包括：

s200’、向相匹配訂單所對應的用戶設(shè)備發(fā)送拼車確認信息；

s300’、判斷是否接收到所述用戶設(shè)備根據(jù)所述拼車確認信息反饋的同意拼車的響應，若是，則允許執(zhí)行s400’。

可以理解的是，若反饋信息為不同意拼車，則向終端發(fā)送拼車失敗的提示信息。

本實施例中在生成拼車信息之前確認發(fā)送相匹配訂單信息的用戶是否同意拼車，只有在該用戶同意拼車的前提下才會發(fā)出拼車信息。本實施例中考慮到部分用戶可能不愿意與其他人拼車，通過確認的方式保證這部分用戶的乘車體驗。

如圖4所示，本公開另一實施例提供一種拼車方法，本實施例提供的拼車方法中的s200”、s300”與上述實施例中的s100、s200相同，本實施例提供的拼車方法中除了s200”、s300”外還包括：

s100”、判斷接收到載客請求的時刻是否處于平峰期內(nèi)。

若是，則允許執(zhí)行s200”；

否則，執(zhí)行s400”：向所述終端發(fā)送拒絕所述載客請求的提示信息。

可見，只有在平峰期時才允許連續(xù)拼車，在高峰期是不允許進行連續(xù)拼車的，由于在高峰期道路比較擁擠，若連續(xù)拼車的話，可能會影響乘客的乘客體驗。所謂的連續(xù)拼車，在限定車輛中的乘客數(shù)量最多為兩人時，對于某個乘客來說，在完成行程的過程中至少與兩個人共乘。

如圖5所示，本公開另一實施例提供一種拼車系統(tǒng)500，該系統(tǒng)500包括：

判斷模塊501，用于在接收到終端發(fā)送的載客請求時，所述載客請求為所述終端在所屬車輛中的至少一個乘客結(jié)束行程后發(fā)出的包括所述車輛中剩余乘客的剩余行程信息的請求；根據(jù)所述載客請求，判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單，所述訂單為根據(jù)用戶設(shè)備發(fā)送的打車請求生成的訂單；

發(fā)送模塊502，用于在所述判斷模塊的判斷結(jié)果為是時，將相匹配的訂單發(fā)送至所述終端，并將所述終端的所屬車輛信息發(fā)送至相匹配訂單所對應的用戶設(shè)備。

本實施例中，該系統(tǒng)還可包括圖中未示出的：

確認模塊，用于向相匹配訂單所對應的用戶設(shè)備發(fā)送拼車確認信息；若接收到所述用戶設(shè)備根據(jù)所述拼車確認信息反饋的同意拼車的響應，則允許所述發(fā)送模塊執(zhí)行將相匹配的訂單發(fā)送至所述終端的步驟。

本實施例中，所述判斷模塊501包括圖中未示出的：

計算單元，用于根據(jù)所述剩余行程信息和根據(jù)用戶設(shè)備發(fā)送的打車請求所生成的訂單中的行程信息，計算所述剩余乘客與發(fā)送該訂單的用戶設(shè)備的所屬用戶拼車時所述剩余乘客的繞路比例和所述所屬用戶的繞路比例；

判斷單元，用于判斷所述剩余乘客的繞路比例和所述所屬用戶的繞路比例是否均小于預設(shè)值；

確定單元，用于在所述判斷單元的判斷結(jié)果為是時，確定該訂單為與所述載客請求中的剩余行程信息相匹配的訂單。

本實施例中，所述判斷模塊501還用于：

判斷接收到載客請求的時刻是否處于平峰期內(nèi)；

若是，則允許所述判斷模塊執(zhí)行判斷是否存在與所述載客請求中的剩余行程信息相匹配的訂單的步驟；

否則，向所述終端發(fā)送拒絕所述載客請求的提示信息。

本實施例中，該系統(tǒng)還包括圖中未示出的循環(huán)模塊；

所述循環(huán)模塊用于在不存在與所述載客請求中的剩余行程信息相匹配的訂單時，每經(jīng)歷預設(shè)時長后執(zhí)行：

步驟a：根據(jù)所述載客請求中的剩余行程信息和所述終端所屬車輛的當前位置坐標，確定所述剩余乘客在當前時刻的剩余行程信息；

步驟b：判斷是否存在與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單；

若是，則結(jié)束步驟a和步驟b的周期性執(zhí)行，并將與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單發(fā)送至所述終端，將所述終 端的所屬車輛信息發(fā)送至與所述剩余乘客在當前時刻的剩余行程信息相匹配的訂單所對應的用戶設(shè)備。

本領(lǐng)域普通技術(shù)人員可以理解：實現(xiàn)上述方法實施例的全部或者部分步驟可以通過程序指令相關(guān)的硬件來完成，前述的程序可以存儲在計算機可讀取的存儲介質(zhì)中，該程序在執(zhí)行時，執(zhí)行包括上述方法實施例的步驟。

本發(fā)明的說明書中，說明了大量具體細節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中，并未詳細示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。

以上實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領(lǐng)域的普通技術(shù)人員應當理解；其依然可以對前述各實施例所記載的技術(shù)方案進行修改，或者對其中部分技術(shù)特征進行等同替換；而這些修改或者替換，并不使相應技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的精神和范圍。