本發(fā)明涉及互聯(lián)網(wǎng)技術領域，具體而言，涉及一種訂單處理方法、裝置及服務器。

背景技術：

隨著互聯(lián)網(wǎng)技術的不斷發(fā)展，基于互聯(lián)網(wǎng)技術的線上線下電子商務(Online To Offline，O2O)得到了很大的發(fā)展，極大地刺激了傳統(tǒng)的餐飲行業(yè)。

在互聯(lián)網(wǎng)餐飲系統(tǒng)中，由于用戶通過互聯(lián)網(wǎng)進行訂餐的形式單一，不能滿足當前用戶對用餐形式的要求，極大地限定了互聯(lián)網(wǎng)餐飲系統(tǒng)的發(fā)展。基于此，以“約飯”形式的聚餐逐漸得到運用以提高用餐的豐富度。但是由于大多數(shù)用戶在行為上具有被動性，一般不會主動發(fā)起或參加聚餐，因此聚餐難以有效完成。

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

有鑒于此，本發(fā)明的目的在于提供一種訂單處理方法、裝置及服務器，可以自動構成訂單組合，從而完成聚餐，以解決上述問題。

為實現(xiàn)上述目的，本發(fā)明實施例采用如下技術方案：

一種訂單處理方法，包括：

獲取各用戶端發(fā)送的訂單信息，得到多個訂單信息，每個所述訂單信息包括送達信息以及是否提供聚餐場所信息；

根據(jù)預設規(guī)則對多個訂單信息進行組合處理，得到至少一個數(shù)據(jù)集；

針對每個數(shù)據(jù)集，判斷所述數(shù)據(jù)集中是否包括至少一個提供聚餐場所信息的訂單信息，若所述數(shù)據(jù)集中包括至少一個提供聚餐場所信息的訂單信息，則確定該數(shù)據(jù)集包括的各訂單信息構成訂單組合。

在上述基礎上，本發(fā)明實施例還提供了一種訂單處理裝置，所述裝置包括：

信息獲取模塊，用于獲取各用戶端發(fā)送的訂單信息，得到多個訂單信息，所述訂單信息包括送達信息以及是否提供聚餐場所信息；

組合處理模塊，用于根據(jù)預設規(guī)則對多個訂單信息進行組合處理，得到至少一個數(shù)據(jù)集；

組合判斷模塊，用于針對每個數(shù)據(jù)集，判斷所述數(shù)據(jù)集中是否包括至少一個提供聚餐場所信息的訂單信息，若所述數(shù)據(jù)集中包括至少一個提供聚餐場所信息的訂單信息，則確定該數(shù)據(jù)集包括的各訂單信息構成訂單組合。

在上述基礎上，本發(fā)明實施例還提供了一種服務器，包括處理器和存儲器及存儲在存儲器上并可在處理器上運行的計算機程序，所述處理器執(zhí)行所述程序時實現(xiàn)以下步驟：

獲取各用戶端發(fā)送的訂單信息，得到多個訂單信息，每個所述訂單信息包括送達信息以及是否提供聚餐場所信息；

根據(jù)預設規(guī)則對多個訂單信息進行組合處理，得到至少一個數(shù)據(jù)集；

針對每個數(shù)據(jù)集，判斷所述數(shù)據(jù)集中是否包括至少一個提供聚餐場所信息的訂單信息，若所述數(shù)據(jù)集中包括至少一個提供聚餐場所信息的訂單信息，則確定該數(shù)據(jù)集包括的各訂單信息構成訂單組合。

在上述基礎上，本發(fā)明實施例還提供了一種計算機可讀儲存介質(zhì)，其上存儲有計算機程序，該程序被處理器執(zhí)行時實現(xiàn)上述訂單處理方法的步驟。

本發(fā)明提供的訂單處理方法、裝置及服務器，可以自動構成訂單組合，從而完成聚餐，進而有效解決現(xiàn)有互聯(lián)網(wǎng)餐飲系統(tǒng)中因需要用戶自己主動發(fā)起或選擇參加某一個聚餐以及用戶一般具有被動性而存在聚餐難以完成的問題。

為使本發(fā)明的上述目的、特征和優(yōu)點能更明顯易懂，下文特舉較佳實施例，并配合所附附圖，作詳細說明如下。

附圖說明

圖1為本發(fā)明實施例提供的訂單處理方法和裝置的應用場景示意圖。

圖2為本發(fā)明實施例提供的服務器的方框示意圖。

圖3為本發(fā)明實施例提供的訂單處理方法的流程示意圖。

圖4為圖3中步驟S120的流程示意圖。

圖5為本發(fā)明實施例提供的訂單處理方法的另一流程示意圖。

圖6為圖5中步驟S140的流程示意圖。

圖7為圖5中步驟S140的另一流程示意圖。

圖8為圖5中步驟S150的流程示意圖。

圖9為本發(fā)明實施例提供的訂單處理方法的另一流程示意圖。

圖10為圖9中步驟S180的流程示意圖。

圖11為本發(fā)明實施例提供的訂單處理裝置的方框示意圖。

圖標：10-服務器；12-存儲器；14-處理器；16-通信單元；20-用戶端；30-網(wǎng)絡；100-訂單處理裝置；110-信息獲取模塊；120-組合處理模塊；130-組合判斷模塊。

具體實施方式

為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例只是本發(fā)明的一部分實施例，而不是全部的實施例。通常在此處附圖中描述和示出的本發(fā)明實施例的組件可以以各種不同的配置來布置和設計。

因此，以下對在附圖中提供的本發(fā)明的實施例的詳細描述并非旨在限制要求保護的本發(fā)明的范圍，而是僅僅表示本發(fā)明的選定實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

如圖1所示，是本發(fā)明實施例提供的一種訂單處理方法和裝置的應用場景示意圖。該應用場景可以包括服務器10、用戶端20和網(wǎng)絡30。所述服務器10能夠通過網(wǎng)絡30與多個用戶端20進行通信。

可選地，在本實施例中，所述服務器10可以是，但不限于，web(網(wǎng)站)服務器、數(shù)據(jù)服務器等，還可以是電腦、移動上網(wǎng)設備(mobile Internet device，MID)等具有處理功能的電子設備。所述用戶端20可以是，但不限于，智能手機、個人電腦(personal computer，PC)、平板電腦、個人數(shù)字助理(personal digital assistant，PDA)、移動上網(wǎng)設備(mobile Internet device，MID)等。所述用戶端20為訂餐人員使用的終端，所述網(wǎng)絡30可以是，但不限于，有線網(wǎng)絡或無線網(wǎng)絡。

請結合參閱圖2，所述服務器10可以包括存儲器12、處理器14及通信單元16。所述存儲器12、處理器14及通信單元16相互之間直接或間接地電性連接，以實現(xiàn)數(shù)據(jù)的傳輸或交互。例如，這些元件相互之間可通過一條或多條通訊總線或信號線實現(xiàn)電性連接。存儲器12中存儲有以軟件或固件(firmware)的形式存儲于所述存儲器12中的軟件功能模塊，所述處理器14通過運行存儲在存儲器12內(nèi)的軟件程序以及模塊，如本發(fā)明實施例中的訂單處理裝置，從而執(zhí)行各種功能應用以及數(shù)據(jù)處理，即實現(xiàn)本發(fā)明實施例中的訂單處理方法。

其中，所述存儲器12可以是，但不限于，隨機存取存儲器(Random Access Memory，RAM)，只讀存儲器(Read Only Memory，ROM)，可編程只讀存儲器(Programmable Read-Only Memory，PROM)，可擦除只讀存儲器(Erasable Programmable Read-Only Memory，EPROM)，電可擦除只讀存儲器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。其中，存儲器12用于存儲程序，處理器14在接收到執(zhí)行指令后，執(zhí)行所述程序。進一步地，上述存儲器12內(nèi)的軟件程序以及模塊還可包括操作系統(tǒng)。其可包括各種用于管理系統(tǒng)任務(例如內(nèi)存管理、存儲設備控制、電源管理等)的軟件組件和/或驅動，并可與各種硬件或軟件組件相互通訊，從而提供其他軟件組件的運行環(huán)境。

所述處理器14可能是一種集成電路芯片，具有信號的處理能力。上述的處理器14可以是通用處理器，包括中央處理器(Central Processing Unit，CPU)、網(wǎng)絡處理器(Network Processor，NP)等。還可以是數(shù)字信號處理器(DSP))、專用集成電路(ASIC)、現(xiàn)場可編程門陣列(FPGA)或者其他可編程邏輯器件、分立門或者晶體管邏輯器件、分立硬件組件?？梢詫崿F(xiàn)或者執(zhí)行本發(fā)明實施例中的公開的各方法、步驟及邏輯框圖。通用處理器可以是微處理器或者任何常規(guī)的處理器等。

所述通信單元16用于通過網(wǎng)絡30建立所述服務器10與外部通信終端之間的通信連接，實現(xiàn)網(wǎng)絡信號及數(shù)據(jù)信息的收發(fā)操作。上述網(wǎng)絡信號可包括無線信號或者有線信號。

可以理解，圖2所示的結構僅為示意，服務器10還可包括比圖2中所示更多或者更少的組件，或者具有與圖2所示不同的配置。圖2中所示的各組件可以采用硬件、軟件或其組合實現(xiàn)。

請結合參閱圖3，本發(fā)明實施例還提供一種可應用于所述服務器10的訂單處理方法，所述方法有關的流程所定義的方法步驟可以由所述處理器14實現(xiàn)。下面將對圖3所示的具體流程進行詳細闡述。

步驟S110，獲取各所述用戶端20發(fā)送的訂單信息，得到多個訂單信息。

在本實施例中，所述用戶端20響應訂餐人員的合點外賣需求生成所述訂單信息，并發(fā)送至所述服務器10。多個訂餐人員通過對應的所述用戶端20向所述服務器10發(fā)送訂單信息，服務器10從而得到多個所述訂單信息。所述多個訂單信息中的每個訂單信息包括，但不限于送達信息和是否提供聚餐場所信息。所述是否提供聚餐場所信息，用于表示該訂餐人員是否愿意或者是否有能力提供一個聚餐場所。

步驟S120，根據(jù)預設規(guī)則對多個訂單信息進行組合處理，得到至少一個數(shù)據(jù)集。

可選地，所述組合處理的具體內(nèi)容不受限制，既可以是將獲取的多個訂單信息直接進行合并處理生成數(shù)據(jù)集，也可以是根據(jù)所述送達信息的內(nèi)容不同進行不同的組合處理。

步驟S130，針對每個數(shù)據(jù)集，判斷所述數(shù)據(jù)集中是否包括至少一個提供聚餐場所信息的訂單信息，若所述數(shù)據(jù)集中包括至少一個提供聚餐場所信息的訂單信息，則確定該數(shù)據(jù)集包括的各訂單信息構成訂單組合。

在本實施例中，所述數(shù)據(jù)集中各訂單信息對應的各訂餐人員中是否有人可以提供至少一個聚餐場所是聚餐能否正常進行的重要因素。當該數(shù)據(jù)集中有人可以提供至少一個聚餐場所時，判定該數(shù)據(jù)集對應的各訂單信息構成訂單組合。

進一步地，在本發(fā)明較佳的實施例中，所述送達信息可以包括，但不限于送達時間信息和/或送達地點信息。根據(jù)所述送達信息的不同內(nèi)容，步驟S120可以包括不同的子步驟。

可選地，根據(jù)訂餐人員的不同需求，所述送達信息可以包括不同的內(nèi)容。例如，對于用餐時間比較在意且無其它要求的訂餐人員，對應的送達信息可以只包括送達時間信息。對于用餐地點比較在意且無其它要求的訂餐人員，對應的送達信息可以包括送達地點信息。對于既在意用餐時間又在意用餐地點的訂餐人員，對應的送達信息可以包括送達時間信息和送達地點信息。

在送達信息包括送達時間信息時，步驟S120可以包括：將多個訂單信息中送達時間信息屬于同一預設時段的訂單信息進行組合，得到至少一個數(shù)據(jù)集。

在送達信息包括送達地點信息時，步驟S120可以包括：將多個訂單信息中送達地點信息屬于同一預設距離范圍的訂單信息進行組合，得到至少一個數(shù)據(jù)集。

考慮到訂餐人員一般為學生或工作繁忙的社會人員，兩者皆在一定程度上受時間和地點的限制，因此比較在意用餐時間和用餐地點。在本實施例中，優(yōu)選所述送達信息包括送達時間信息和送達地點信息。請結合參閱圖4，在送達信息包括送達時間信息和送達地點信息時，步驟S120可以包括步驟S121和步驟S122兩個子步驟。

步驟S121，查找出多個訂單信息中送達時間信息屬于同一預設時段且送達地點信息屬于同一預設距離范圍的各訂單信息。

可選地，所述服務器10可以預先將一天中的24小時劃分為N個時段。具體劃分方式可以是，但不限于，將24小時等分成N個時段或分成N個不等的時段。考慮到各個時段的訂餐人員的數(shù)量存在較大的差異，例如，訂餐人員的數(shù)量在正常用餐時間會遠大于非正常用餐時間。因此，在本實施例中，所述服務器10可以按照是否屬于正常用餐時間預先將一天中的24小時劃分為N個不等的時段，即越靠近正常用餐時間，對應的時段的時長越短。

在本實施例中，所述服務器10既可以預先將可以送餐的區(qū)域進行劃分，如是否屬于同一小區(qū)，或者是否屬于同一街道。當各所述送達地點信息屬于同一區(qū)域時，即判定各所述送達地點信息屬于同一預設距離范圍。還可以是根據(jù)各所述送達地點信息所代表的經(jīng)緯度坐標，通過K-means、混合Gauss模型等聚類方法判定是否屬于同一預設距離范圍。

可以理解，在步驟S121中所述服務器至少包括兩個處理操作，即查找出所述訂單信息集合中送達時間信息屬于同一預設時段的各訂單信息和查找出所述訂單信息集合中送達地點信息屬于同一預設距離范圍的各訂單信息?？蛇x地，上述兩個處理操作的先后順序不受限制，例如，可以先查找出所述訂單信息集合中送達時間信息屬于同一預設時段的各訂單信息，然后在送達時間信息屬于同一預設時段的各訂單信息中查找出送達地點信息屬于同一預設距離范圍的各訂單信息。又例如，先查找出所述訂單信息集合中送達地點信息屬于同一預設距離范圍的各訂單信息，然后在送達地點信息屬于同一預設距離范圍的各訂單信息中查找出送達時間信息屬于同一預設時段的各訂單信息。又例如，先同時查找出所述訂單信息集合中送達時間信息屬于同一預設時段的各訂單信息與查找出所述訂單信息集合中送達地點信息屬于同一預設距離范圍的各訂單信息，然后查找出送達時間信息屬于同一預設時段的各訂單信息與送達地點信息屬于同一預設距離范圍的各訂單信息的交集，該交集即送達時間信息屬于同一預設時段的各訂單信息且送達地點信息屬于同一預設距離范圍的各訂單信息。

步驟S122，將送達時間信息屬于同一預設時段且送達地點信息屬于同一預設距離范圍的訂單信息進行組合，得到至少一個數(shù)據(jù)集。

進一步地，在本發(fā)明較佳的實施例中，為保證所述組合處理的有效進行，還可以在步驟S120之前，即對所述訂單信息進行組合處理之前，通過預設條件對所述訂單信息進行篩選。因此，在本實施例中，所述訂單處理方法還可以包括以下步驟：從所述多個訂單信息中查找出滿足預設條件的訂單信息，并生成訂單信息集合。

由于在對所述訂單信息進行組合處理之前，增加了前述步驟以對所述訂單信息進行篩選，因此步驟S120的具體流程可以為：根據(jù)預設規(guī)則對所述訂單信息集合中包括的多個訂單信息進行組合處理，得到至少一個數(shù)據(jù)集。

可選地考慮到商家在制作菜品的過程中需要一定的烹飪時間，送餐人員在配送外賣的過程中也需要一定的運送時間。因此，可以根據(jù)實際情況設定一預約提前時間常量，訂餐人員通過所述用戶端20向所述服務器10發(fā)送訂單信息的時間(訂單信息的生成時刻)與該訂單信息中的送達時間信息之間的時間間隔應大于該預約提前時間常量。基于上述考慮，所述滿足預設條件的訂單信息為生成時刻與送達時間信息的差值大于預設的預約提前時間常量的訂單信息。

可選地，所述訂單信息的生成時刻可以是該訂單信息在對應的用戶端20的生成時刻，或者是發(fā)送給所述服務器10的發(fā)送時刻，還可以是所述服務器10接收到該訂單信息的接收時刻。在本實施例中，優(yōu)選所述訂單信息的生成時刻為該訂單信息在的用戶端20的生成時刻。

可選地，所述送達時間信息既可以是時刻信息，也可以是時段信息。在所述送達時間信息為時刻信息時，則計算訂單信息的生成時刻與訂單信息的送達時刻的差值。在所述送達時間信息為時段信息時，所述送達時間信息包括起始時刻、截止時刻以及位于所述起始時刻和所述截止時刻之間的各中間時刻。計算該訂單信息的生成時刻與該訂單信息的送達時間信息的差值，既可以是計算該訂單信息的生成時刻與該訂單信息的送達時間信息的起始時刻的差值，也可以是計算該訂單信息的生成時刻與該訂單信息的送達時間信息的截止時刻的差值，還可以計算該訂單信息的生成時刻與該訂單信息的送達時間信息包括的中間時刻的差值。在本實施例中，優(yōu)選計算該訂單信息的生成時刻與該訂單信息中送達時間信息的起始時刻的差值。

在本實施例中，通過篩選出滿足預設條件的訂單信息進行組合處理操作，以確保訂單信息集合可靠組成，滿足用戶個性化需求。并能夠使得送餐人員有足夠的時間在滿足送達時間信息的條件下將外賣送至相應的用餐地點。

可選地，篩選滿足預設條件的訂單信息的動作還可以在用戶端20進行。用戶端20在生成訂單信息時，將生成該訂單信息的時間和該訂單信息中的送達時間信息進行差值計算。如果該差值大于預約提前時間常量，則將該訂單信息發(fā)送至所述服務器10。如果該差值小于預約提前時間常量，則提醒該訂餐人員重新選擇送達時間信息并形成新的訂單信息。

進一步地，在本發(fā)明較佳的實施例中，在構成訂單組合時，還可以生成相應的聚餐場所信息以引導各訂餐人員完成聚餐。具體流程請結合參閱圖5中的步驟S140。

步驟S140，針對每一個訂單組合，生成聚餐場所信息并發(fā)送至所述訂單組合中各訂單信息對應的用戶端20。

可選地，所述生成聚餐場所信息的實現(xiàn)方式可以是多種，例如，可以是所述訂單信息中包括聚餐餐所信息，在滿足前述條件時，將該聚餐場所信息作為該數(shù)據(jù)集的聚餐場所信息。請結合參閱圖6，可以通過步驟S141和步驟S142兩個子步驟生成所述聚餐場所信息。

步驟S141，針對每個訂單組合，統(tǒng)計該訂單組合中包括提供聚餐場所信息的訂單信息的數(shù)量。

步驟S142，當所述包括提供聚餐場所信息的訂單信息的數(shù)量為1時，選擇所述包括提供聚餐場所信息的訂單信息的聚餐場所信息作為該訂單組合的聚餐場所信息。

請結合參閱圖7，還可以通過步驟S143和步驟S144兩個子步驟生成所述聚餐場所信息。

步驟S143，針對每個訂單組合，統(tǒng)計該訂單組合中包括提供聚餐場所信息的訂單信息的數(shù)量。

步驟S144，當所述包括提供聚餐場所信息的訂單信息的數(shù)量大于1時，根據(jù)預設條件選擇其中1個包括提供聚餐場所信息的訂單信息的聚餐場所信息作為該訂單組合的聚餐場所信息。

在本實施例中，由于各訂單組合中包括提供聚餐場所信息的訂單信息的數(shù)量具有不確定性，當包括提供聚餐場所信息的訂單信息的數(shù)量為1時，由于只存在一個可以提供聚餐場所的訂餐人員，則直接以該訂餐人員提供的聚餐場所信息作為該訂單組合的聚餐場所信息。當包括提供聚餐場所信息的訂單信息的數(shù)量大于1時，所述服務器10可以根據(jù)預設條件選擇其中1個包括提供聚餐場所信息的訂單信息的聚餐場所信息作為該訂單組合的聚餐場所信息?？蛇x地，根據(jù)預設條件選擇的方式可以是多種，例如隨機選擇。又例如，按照各訂餐人員的位置分布選擇，如以各訂餐人員到聚餐場所的距離均衡或是各訂餐人員的位置分布的分布密度更大為原則進行選擇。

在本實施例中，通過將生成的聚餐場所信息發(fā)送至對應的用戶端20，還可以提示訂餐人員該訂單組合有效構成，以使對應的訂餐人員獲知聚餐成功，以便于完成聚餐。

可以理解，使對應的訂餐人員獲知聚餐成功的實現(xiàn)方式，還可以是在判定該訂單組合組合成功時，生成一個聚餐成功標識，并將所述聚餐成功標識發(fā)送至對應的用戶端20。具體流程請結合參閱圖5中的步驟S150。

步驟S150，向提供所述訂單組合的聚餐場所信息的用戶端20發(fā)送標識信息。

在本實施例中，所述服務器10可以對向提供所述訂單組合的聚餐場所信息的用戶端20進行標識，將具有該標識的用戶端20作為主用戶端。

所述標識信息的內(nèi)容不受限制，既可以是用于提示該訂單組合中提供聚餐場所的訂餐人員的選中提示信息，以便于提示該訂餐人員及時準備聚餐場所，保證聚餐的順利進行。還可以是用于向該訂單組合中提供聚餐場所的訂餐人員再次確認的確認信息，以充分確保聚餐的可靠進行。

當所述標識信息為確認信息時，請結合參閱圖8，步驟S150可以包括步驟S151-S156六個子步驟。

步驟S151，向提供所述訂單組合的聚餐場所信息的用戶端20發(fā)送確認信息。

步驟S152，判斷是否接收到該用戶端20發(fā)送的確認反饋。若接收到所述用戶端20發(fā)送的確認反饋，則執(zhí)行步驟S153。若未接收到所述用戶端20發(fā)送的確認反饋，則執(zhí)行步驟S154。

步驟S153，判定該訂單組合組合成功。

步驟S154，判斷所述訂單組合中包括提供聚餐場所信息的訂單信息的數(shù)量是否大于1。若所述訂單組合中包括提供聚餐場所信息的訂單信息的數(shù)量為1，則執(zhí)行步驟S155。若所述訂單組合中包括提供聚餐場所信息的訂單信息的數(shù)量大于1，則執(zhí)行步驟S156。

步驟S155，判定該訂單組合組合失敗。

步驟S156，向另一提供所述訂單組合的聚餐場所信息的用戶端20發(fā)送確認信息。

在本實施例中，在判定該訂單組合組合失敗時，所述服務器10可以生成一個聚餐失敗提示信息，并將該聚餐失敗提示信息發(fā)送至對應的用戶端20，以達到及時通知各訂餐人員的目的。

進一步地，在本發(fā)明較佳的實施例中，所述服務器10還預存有各訂餐人員的聯(lián)絡信息，在該訂單組合組合成功時，將該訂單組合中各訂餐人員的聯(lián)絡信息打包處理生成一個聯(lián)絡信息集合，并將該聯(lián)絡信息集合發(fā)送至對應的用戶端20，以使對應的訂餐人員可以得知同一訂單組合中其他訂餐人員的聯(lián)絡信息，便于各訂餐人員之間的聯(lián)絡，以保證聚餐的順利進行。具體流程請結合參閱圖5中的步驟S160。

步驟S160，在預存的聯(lián)絡信息數(shù)據(jù)庫中查找出訂單組合中各訂單信息對應的各用戶的聯(lián)絡信息，生成聯(lián)絡信息集合并發(fā)送至所述訂單組合中各訂單信息對應的用戶端20。

進一步地，在本發(fā)明較佳的實施例中，考慮到某一個訂單組合中各訂單信息對應的訂餐人員的數(shù)量如果過多，會存在因訂餐人員到達用餐地點的時間不統(tǒng)一而導致各訂餐人員無法及時用餐的問題。因此，所述服務器10可以設置一個預設值以限制各訂單組合中各訂單信息對應的訂餐人員的數(shù)量?；诖?，結合圖9，所述方法還可以包括步驟S170和步驟S180兩個步驟。

步驟S170，針對每個訂單組合，判斷該訂單組合中的訂單信息數(shù)量是否大于預設值。

步驟S180，若該訂單組合中的訂單信息數(shù)量大于所述預設值，則將該訂單組合劃分為多個子訂單組合，以使各所述子訂單組合中的訂單信息數(shù)量小于所述預設值。

進一步地，在本發(fā)明較佳的實施例中，將各訂單組合中訂單信息數(shù)量大于所述預設值的訂單組合劃分為多個子訂單組合的實現(xiàn)方式可以是多種，例如，可以按照距離進行劃分，還可以按照其它信息進行劃分，如預算金額、希望聚餐人數(shù)、忌口信息、性別、年齡以及歷史數(shù)據(jù)等。以所述訂單信息還包括預算金額、希望聚餐人數(shù)以及忌口信息為例。請結合參閱圖10，步驟S180可以包括步驟S181和步驟S182兩個子步驟。

步驟S181，根據(jù)預設規(guī)則對各訂單信息包括的預算金額、希望聚餐人數(shù)、忌口信息進行匹配度計算，得到所述訂單組合中各訂單信息的匹配度。

步驟S182，按計算得到的匹配度對所述訂單組合進行劃分，得到多個子訂單組合。

在本實施例中，可以分別計算各預算金額之間的匹配度、各希望聚餐人數(shù)之間的匹配度以及各忌口信息之間的匹配度，進而得出各訂單信息之間的總匹配度或平均匹配度，將總匹配度或平均匹配度較高的劃分為一個子訂單組合，所述平均匹配度可以是根據(jù)訂餐人員對預算金額、希望聚餐人數(shù)以及忌口信息的在意程度計算出的加權平均匹配度，以使得到的訂單組合更貼合訂餐人員的需求。還可以將計算得出的匹配度與預設匹配度進行比較，將大于預設匹配度的訂單信息歸于同一個子訂單組合。

可選地，上述的匹配度的計算的具體方式不受限制。在本實施例中，可以采用以下實施方式：以預算金額為例，分別計算出各預算金額中任意兩個預算金額之間的匹配度，該匹配度大小可以以對應兩個預算金額之間的差值大小進行度量，即該差值越小，對應的兩個預算金額之間的匹配度越大。以忌口信息為例，假設共有N個用戶，M種類型的忌口信息，通過概率矩陣分解方法，將用戶和忌口信息映射到同一個向量空間，則該向量空間內(nèi)兩個向量的內(nèi)積可以表示用戶與忌口信息之間的關聯(lián)度，給定一個向量P_n代表一個用戶，給定一個向量Q_m代表一種類型的忌口信息，給定一個用戶與忌口信息的關聯(lián)度R_nm，則通過公式R_nm＝Q_m^TP_n，可以計算出用戶對各種類型的忌口信息的偏好程度，從而根據(jù)任意兩個用戶的偏好程度的相似度得出相應的匹配度。所述概率矩陣分解方法可以是p-LSA或LDA等概率矩陣分解方法。

應理解，若還需考慮性別、年齡、歷史數(shù)據(jù)等信息，也可按類似方式進行處理，因而在此不作贅述。

請結合參閱圖11，本發(fā)明實施例還提供一種可應用于所述服務器10的訂單組合裝置100。所述訂單組合裝置100包括信息獲取模塊110、組合處理模塊120以及組合判斷模塊130。

所述信息獲取模塊110，用于獲取各所述用戶端20發(fā)送的訂單信息，得到多個訂單信息，所述訂單信息包括送達信息以及是否提供聚餐場所信息。

本實施例中，圖3的步驟S110可以由所述信息獲取模塊110執(zhí)行。

所述組合處理模塊120，用于根據(jù)預設規(guī)則對多個訂單信息進行組合處理，得到至少一個數(shù)據(jù)集。

本實施例中，圖3的步驟S120可以由所述組合處理模塊120執(zhí)行。

所述組合判斷模塊130，用于針對每個數(shù)據(jù)集，判斷所述數(shù)據(jù)集中是否包括至少一個提供聚餐場所信息的訂單信息，若所述數(shù)據(jù)集中包括至少一個提供聚餐場所信息的訂單信息，則確定該數(shù)據(jù)集包括的各訂單信息構成訂單組合。

本實施例中，圖3的步驟S130可以由所述組合判斷模塊130執(zhí)行。

本發(fā)明實施例還提供一種計算機可讀儲存介質(zhì)，其上存儲有計算機程序，該程序被處理器14執(zhí)行時實現(xiàn)所述訂單處理方法的步驟。

綜上所述，本發(fā)明提供的一種訂單處理方法、裝置及服務器，通過該方法，可以自動構成訂單組合，從而完成聚餐，進而有效解決現(xiàn)有互聯(lián)網(wǎng)餐飲系統(tǒng)因需要用戶自己主動發(fā)起或選擇參加某一個聚餐以及用戶一般具有被動性而存在聚餐難以完成的問題。其次，通過設置預約提前時間常量，可以保證送餐人員有足夠的時間用于在滿足送達時間信息的條件下將外賣送至相應的用餐地點，有效地提高了該方法的實用性。最后，在訂單組合組合成功時通過生成標識信息并發(fā)送至用戶端20，方便訂餐人員及時準備聚餐場所，保證聚餐的順利進行，進一步地提高了該方法的實用性。

在本發(fā)明實施例所提供的幾個實施例中，應該理解到，所揭露的裝置和方法，也可以通過其它的方式實現(xiàn)。以上所描述的裝置和方法實施例僅僅是示意性的，例如，附圖中的流程圖和框圖顯示了根據(jù)本發(fā)明的多個實施例的裝置、方法和計算機程序產(chǎn)品的可能實現(xiàn)的體系架構、功能和操作。在這點上，流程圖或框圖中的每個方框可以代表一個模塊、程序段或代碼的一部分，所述模塊、程序段或代碼的一部分包含一個或多個用于實現(xiàn)規(guī)定的邏輯功能的可執(zhí)行指令。也應當注意，在有些作為替換的實現(xiàn)方式中，方框中所標注的功能也可以以不同于附圖中所標注的順序發(fā)生。例如，兩個連續(xù)的方框實際上可以基本并行地執(zhí)行，它們有時也可以按相反的順序執(zhí)行，這依所涉及的功能而定。也要注意的是，框圖和/或流程圖中的每個方框、以及框圖和/或流程圖中的方框的組合，可以用執(zhí)行規(guī)定的功能或動作的專用的基于硬件的系統(tǒng)來實現(xiàn)，或者可以用專用硬件與計算機指令的組合來實現(xiàn)。

另外，在本發(fā)明各個實施例中的各功能模塊可以集成在一起形成一個獨立的部分，也可以是各個模塊單獨存在，也可以兩個或兩個以上模塊集成形成一個獨立的部分。

所述功能如果以軟件功能模塊的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算機可讀取存儲介質(zhì)中。基于這樣的理解，本發(fā)明的技術方案本質(zhì)上或者說對現(xiàn)有技術做出貢獻的部分或者該技術方案的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，電子設備，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括：U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。需要說明的是，在本文中，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。