TWI751213B

TWI751213B - 業務對象預訂系統、方法及裝置

Info

Publication number: TWI751213B
Application number: TW106137331A
Authority: TW
Inventors: 薛彬
Original assignee: 香港商阿里巴巴集團服務有限公司
Priority date: 2017-01-20
Filing date: 2017-10-30
Publication date: 2022-01-01
Also published as: US20190340710A1; KR20190103199A; WO2018133699A1; JP2020506470A; TW201828174A; CN108334964A

Abstract

本申請關於電子技術領域，尤其關於一種業務對象預訂系統、方法及裝置，用以解決預訂流程經過的環節較多，導致預訂成功率較低的問題。本申請實施例提供一種業務對象預訂方法，包括：平台伺服器接收客戶端發送的第一預訂請求；根據所述第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷所述庫存的預訂資訊是否滿足所述第一預訂請求；若滿足，則基於所述第一預訂請求對應的預訂對象資訊，生成第一預訂結果；若不滿足，則向所述業務對象伺服器發送所述第一預訂請求，並接收所述業務對象伺服器反饋的第一預訂結果；將所述第一預訂結果反饋給所述客戶端。

Description

業務對象預訂系統、方法及裝置

本申請關於電子技術領域，尤其關於一種業務對象預訂系統、方法及裝置。

酒店在線預訂服務是指透過向用戶提供網頁（web）頁面或手機應用（app），供用戶填寫酒店預訂資訊，並將預訂資訊提交給酒店，完成酒店客房預訂的互聯網服務過程。　　如圖1所示，現有的預訂服務都是在客戶端向平台伺服器提交預訂資訊後，平台伺服器向代理商系統發起請求，然後由代理商系統向通路管理系統發送請求，通路管理系統再請求酒店物業管理系統（Property Management System，PMS）系統，最後再將預訂結果，亦即創建完成的訂單資訊反饋給客戶端。　　可見，現有的訂單資訊創建流程經過的環節非常多，其中任何一個環節有問題就會導致預訂失敗，所以預訂成功率較低。比如，假設每個系統的處理成功率是99%，經過在線預訂服務系統、代理商系統、通路管理系統、酒店PMS系統4個系統處理後總的成功率是99%的4次方，約等於96%。　　綜上，目前由於在用戶提交預訂資訊後，後續的訂單資訊創建流程經過的環節非常多，導致預訂成功率較低。

本申請實施例提供一種業務對象預訂系統、方法及裝置，用以解決訂單資訊創建流程經過的環節較多，導致預訂成功率較低的問題。　　本申請實施例提供一種業務對象預訂系統，包括：　　平台伺服器，用於接收客戶端發送的攜帶有預訂對象資訊的第一預訂請求；根據該預訂對象資訊以及庫存的預訂資訊，判斷庫存的預訂資訊是否滿足所述第一預訂請求，其中所述庫存的預訂資訊為平台伺服器透過預先發起攜帶有預訂對象資訊的第二預訂請求得到的；若滿足，則生成所述第一預訂請求對應的第一預訂結果，若不滿足，則透過向業務對象伺服器發送所述第一預訂請求得到第一預訂結果；將所述第一預訂結果反饋給客戶端；　　客戶端，用於接收用戶提交的預訂對象資訊，並基於該預訂對象資訊向平台伺服器發送所述第一預訂請求；接收所述平台伺服器基於所述第一預訂請求中的預訂對象資訊和所述庫存的預訂資訊反饋的所述第一預訂結果；　　業務對象伺服器，用於接收所述平台伺服器預先發起的所述第二預訂請求，並向所述平台伺服器反饋第二預訂結果，所述第二預訂結果中包含有與所述第二預訂請求對應的預訂成功的資訊，用於作為所述平台伺服器初始庫存的預訂資訊；還用於接收所述平台伺服器發送的由用戶發起的所述第一預訂請求，並向所述平台伺服器反饋所述第一預訂結果。　　本申請實施例提供一種業務對象預訂方法，包括：　　平台伺服器接收客戶端發送的第一預訂請求；所述第一預訂請求中攜帶有預訂對象資訊；　　根據所述第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷所述庫存的預訂資訊是否滿足所述第一預訂請求；其中所述庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；　　若滿足，則基於所述第一預訂請求對應的預訂對象資訊，生成第一預訂結果；若不滿足，則向所述業務對象伺服器發送所述第一預訂請求，並接收所述業務對象伺服器反饋的第一預訂結果；　　將所述第一預訂結果反饋給所述客戶端。　　本申請實施例還提供一種業務對象預訂方法，包括：　　客戶端接收用戶提交的預訂對象資訊；　　向平台伺服器發送第一預訂請求；其中，所述第一預訂請求中攜帶有所述預訂對象資訊；　　接收所述平台伺服器基於所述第一預訂請求中的預訂對象資訊和庫存的預訂資訊反饋的第一預訂結果；其中所述庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；所述第一預訂結果中包含有與所述第一預訂請求對應的預訂成功的資訊。　　本申請實施例提供一種平台伺服器，包括：　　接收模組，用於接收客戶端發送的第一預訂請求；所述第一預訂請求中攜帶有預訂對象資訊；　　預訂處理模組，用於根據所述第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷所述庫存的預訂資訊是否滿足所述第一預訂請求；其中所述庫存的預訂資訊中包含預先透過發送模組向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；若所述庫存的預訂資訊滿足所述第一預訂請求，則基於所述第一預訂請求對應的預訂對象資訊，生成第一預訂結果；若所述庫存的預訂資訊不滿足所述第一預訂請求，則控制發送模組向所述業務對象伺服器發送所述第一預訂請求，並透過所述接收模組接收所述業務對象伺服器反饋的第一預訂結果；　　所述發送模組，還用於將所述第一預訂結果反饋給所述客戶端。　　本申請實施例還提供一種客戶端，包括：　　第一接收模組，用於接收用戶提交的預訂對象資訊；　　第一生成模組，用於基於所述預訂對象資訊，生成第一預訂請求；其中，所述第一預訂請求中攜帶有所述預訂對象資訊；　　發送模組，用於發送所述第一預訂請求；　　第二接收模組，用於接收所述平台伺服器基於所述第一預訂請求中的預訂對象資訊和庫存的預訂資訊反饋的第一預訂結果；其中所述庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；所述第一預訂結果中包含有與所述第一預訂請求對應的預訂成功的資訊。　　採用上述實施例，平台伺服器可以在用戶實際向該平台伺服器發起預訂請求之前預先向系統外的業務對象伺服器發起預訂請求，將得到的預訂結果作為初始庫存的預訂資訊儲存起來。在接收到客戶端實際發起的預訂請求後，再基於本地庫存的預訂資訊向客戶端返回與用戶實際的預訂請求對應的預訂結果。這樣，由於不需要平台伺服器在接收到客戶端請求時再臨時向業務對象伺服器發起請求，客戶端可以及時得到平台伺服器返回的預訂結果，從而提高了預訂效率及預訂成功率，進而提升了用戶體驗。

本申請實施例主要應用在平台伺服器需要向系統外的業務對象伺服器發送預訂請求才能為客戶端用戶提供預訂結果的場景下。在這種場景下，按照現有的請求流程，平台服務端是在接收到用戶實際發起的預訂請求後，再向系統外的業務對象伺服器請求預訂結果，由於預訂過程經歷的環節較多，導致預訂請求失敗率較高。　　下面以酒店預訂為例，對本申請方案做進一步介紹。實施例一　　如圖2所示，為本申請實施例一提供的業務對象預訂方法流程圖，包括：　　S201：客戶端接收用戶提交的預訂對象資訊。　　這裡，針對酒店預訂，用戶提交的預訂對象資訊中可以包括酒店名稱和房間類型等資訊。　　S202：客戶端基於接收的預訂對象資訊，向平台伺服器發送第一預訂請求；其中，所述第一預訂請求中攜帶有所述預訂對象資訊。　　這裡，客戶端在用戶確認預訂後，向平台伺服器發送攜帶有用戶選擇的預訂對象資訊的第一預訂請求。　　S203：平台伺服器根據所述第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷所述庫存的預訂資訊是否滿足所述第一預訂請求，若滿足進入S204a，若不滿足，進入S204b；其中所述庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊。　　在具體實施中，平台伺服器會預先根據在未來預訂時間段內的庫存需求，向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求，並在預訂成功後，儲存業務對象伺服器返回的預訂成功的預訂資訊。之後，在接收到用戶實際發起的預訂請求後，首先查看儲存的預訂資訊是否能夠滿足用戶的預訂請求，若能夠滿足，則可以直接向用戶返回預訂結果，見S204a，若不滿足，則還需要按照現有流程，向業務對象伺服器發送請求，見S204b。　　具體地，平台伺服器根據歷史預訂資料，確定在未來預訂時間段內的庫存需求，該歷史預訂資料包括針對業務對象伺服器提供的預訂對象，用戶實際發起預訂的預訂資料，所述庫存需求包括各用戶針對所述業務對象伺服器提供的每種預訂對象的需求總量（比如標準間需求多少間，大床房需要多少間）；根據確定的庫存需求，向業務對象伺服器發送第二預訂請求；接收業務對象伺服器返回的攜帶預訂成功的資訊的第二預訂結果，用於作為初始庫存的預訂資訊。　　這裡的歷史預訂資料可以儲存在平台伺服器中，也可以儲存在獨立的資料庫中，平台伺服器在有需求時向資料庫發起查詢請求。　　在實際實施時，平台伺服器可以根據儲存的與多個業務對象服務方（比如某個酒店）分別對應的歷史訂單資料，預測在預訂時間段內，針對每個業務對象服務方的庫存需求資訊。之後，根據預測的針對該業務對象服務方的庫存需求，向該業務對象服務方對應的業務對象伺服器（比如酒店的酒店管理系統）發送第二預訂請求。　　在平台伺服器預先向一個業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，建立得到的預訂成功的資訊與該業務對象伺服器對應的服務方標識資訊（比如酒店名稱）之間的映射關係，並將該映射關係作為庫存的預訂資訊進行儲存。之後，在用戶實際發起第一預訂請求後，根據該第一預訂請求中攜帶的服務方標識資訊，從庫存的預訂資訊中查找與該服務方標識資訊對應的預訂成功的資訊，再根據所述第一預訂請求中的其它預訂對象資訊（房間類型，房間數量，比如標準間2間），判斷查找到的預訂成功的資訊是否滿足所述第一預訂請求。　　針對平台伺服器→代理商系統→通路管理系統→業務對象伺服器這種請求路徑，平台伺服器在向業務對象伺服器發送第二預訂請求時，首先向代理商系統發起第二預訂請求，代理商系統接收第二預訂請求後，還會向通路管理系統繼續發起請求，最後由通路管理系統向業務對象伺服器（比如酒店管理系統）發起請求，並將業務對象伺服器返回的第二預訂結果再經過代理商系統返回給平台伺服器。平台伺服器將得到的第二預訂結果儲存起來，作為初始庫存的預訂資訊，比如記錄下預訂成功的酒店名稱、酒店房間類型、入住時間、訂單號等。　　S204a：平台伺服器在庫存的預訂資訊滿足第一預訂請求時，基於第一預訂請求對應的預訂對象資訊，生成第一預訂結果，並更新庫存的預訂資訊。　　這裡，平台伺服器從庫存的預訂資訊中，查找是否存在與第一預訂請求對應的預訂資訊，基於查找出的預訂資訊生成與第一預訂請求對應的第一預訂結果。比如，庫存的預訂資訊中包括平台伺服器預先預訂成功的某連鎖酒店的10間標準間客房資訊，若第一預訂請求中請求預訂一間該連鎖酒店的標準間客房，則從之前預訂成功的10間標準間客房中選擇一間，並將相關訂單資訊（酒店資訊、房間類型、入住時間、訂單號等）返回給客戶端。　　在具體實施中，對於一些需要填寫用戶資訊發起預訂的場景，由於平台伺服器預先創建訂單時並不知道實際的用戶資訊，因此在預先創建訂單時，可以首先使用平台預設的用戶資訊發起預訂，後續在為實際用戶創建訂單後，再發起訂單資訊更新流程。　　具體地，平台伺服器基於第一預訂請求中攜帶的客戶端用戶資訊，和第一預訂請求對應的預訂對象資訊，生成第一預訂結果；其中，第一預訂結果中包含有與第一預訂請求對應的預訂成功的資訊和客戶端用戶資訊；在生成第一預訂結果之後，向業務對象伺服器發送預訂資訊更新請求，該預訂資訊更新請求用於請求將與第一預訂結果關聯的用戶資訊從發送第二預訂請求時使用的預設用戶資訊更新為客戶端用戶資訊。　　比如，根據酒店的預訂要求，平台伺服器需要在預先發起的第二預訂請求中攜帶住客相關資訊，此時平台伺服器可以使用預設用戶資訊發起酒店預訂請求，得到預訂成功的酒店資訊作為初始庫存的預訂資訊。在接收到客戶端用戶實際發起的第一預訂請求後，從之前預訂好的房間中選擇提供給客戶端用戶的房間，並向客戶端返回使用真實的客戶端用戶資訊生成的酒店預訂結果，之後，平台伺服器可以再向酒店管理系統發起訂單資訊更新請求，將之前預留的預設用戶資訊更改為真實的客戶端用戶資訊。　　可選地，在更新庫存的預訂資訊之後，還可以判斷所述預訂對象的庫存量是否低於設定閾值；若是，則向管理方推送庫存告警資訊，用於提示管理方選擇是否補充庫存；或者，自動向業務對象伺服器發起預訂流程。這樣，平台伺服器可以保證預先完成的預訂資訊處於庫存充足的狀態，以滿足用戶實時發起的預訂請求。　　S204b：平台伺服器在庫存的預訂資訊不滿足第一預訂請求時，向業務對象伺服器發送第一預訂請求，並接收業務對象伺服器反饋的第一預訂結果。　　這裡，平台伺服器在庫存不足時，比如客戶端請求預訂某酒店的2個標準間，庫存中沒有了或只剩1個標準間，則此時平台伺服器可以按照現有流程，向業務對象伺服器發起第一預訂請求。　　S205：平台伺服器將第一預訂結果反饋給客戶端。　　這裡，平台伺服器反饋給客戶端的第一預訂結果可能是在庫存滿足需求的情況下，平台伺服器直接生成的預訂結果，也可能是平台伺服器在庫存不足的情況下，臨時向業務對象伺服器請求回的預訂結果。客戶端接收服務端基於庫存的預訂資訊返回的第一預訂結果，並將該第一預訂結果展示給用戶。　　採用上述實施例，平台伺服器可以在用戶實際向該平台伺服器發起預訂請求之前預先向系統外的業務對象伺服器發起預訂請求，將得到的預訂結果作為初始庫存的預訂資訊儲存起來。在接收到客戶端實際發起的預訂請求後，再基於本地庫存的預訂資訊向客戶端返回與用戶實際的預訂請求對應的預訂結果。這樣，由於不需要平台伺服器在接收到客戶端請求時再臨時向業務對象伺服器發起請求，客戶端可以及時得到平台伺服器返回的預訂結果，從而提高了預訂效率及預訂成功率，進而提升了用戶體驗。　　如圖3所示，平台伺服器根據預先統計的庫存需求，分別向XX酒店和YY酒店預先預訂了10間標準間，用戶A後續發起了預訂XX酒店一個標準間的請求，此時平台伺服器根據預存的庫存資訊，確定滿足用戶A的預訂請求，則將與XX酒店一個標準間相關的預訂成功的資訊提供給用戶A，從而可以使用戶A快速獲取到預訂成功的資訊。而用戶B後續發起了預訂YY酒店一個大床房的請求，此時平台伺服器根據預存的庫存資訊，確定無法滿足用戶B的預訂請求，則就需要臨時向YY酒店PMS系統發送預訂請求，並將YY酒店PMS系統反饋的預訂結果再返回給用戶B，顯然，相比用戶A，用戶B的預訂過程需要的時間要長些。　　在實際實施中，本申請除了酒店預訂的場景外，還適用於其它任何需要平台伺服器向業務對象伺服器發送預訂請求才能為客戶端用戶提供預訂結果的場景，比如機票預訂、電影票預訂等。在這些場景下，平台伺服器提前統計用戶需求，預先向平台外的服務方發起預訂請求，並將請求回的預訂結果作為庫存的預訂資訊進行儲存。之後在客戶端實際發起請求時，再基於之前預先請求回的預訂資訊為客戶端提供相關預訂結果。　　下面再透過一個具體的實施例對本申請思想作進一步說明。　　如圖4所示，為本申請實施例二提供的業務對象預訂方法流程圖，包括：　　S401：針對每個業務對象伺服器，平台伺服器根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；所述歷史預訂資料包括針對該業務對象伺服器提供的預訂對象，用戶實際發起預訂的預訂資料，所述庫存需求包括各用戶針對所述業務對象伺服器提供的預訂對象的需求總量。　　在具體實施中，平台伺服器可以根據為用戶提供的各項預訂服務（比如酒店預訂、機票預訂），分別統計每項預訂服務中每個業務對象服務方（比如XX連鎖酒店、YY連鎖酒店等，還可以是連鎖酒店和代理商的組合）能夠提供的每個業務對象（比如標準間客房、大床房等）的庫存需求。具體地，可以統計在最近預設時長（比如一個月）內針對每個業務對象完成的訂單資料，基於統計的訂單資料預測出在預訂時間段（比如一天）內對該業務對象的庫存需求資訊，比如，根據儲存的某連鎖酒店的標準間客房的訂單資料，統計在最近一個月內該連鎖酒店的標準間客房的預訂數量N，從而可以預測出該連鎖酒店的標準間客房每天的預訂數量約為N/30，從而平台伺服器可以在之後每一天的早上7點鐘開始提前預訂N/30個該連鎖酒店的標準間客房。　　上述預測過程僅為舉例，在實際實施中，還可以根據預訂時間段的屬性資訊（比如是否為節假日，是否在特定城市舉辦活動等），首先獲取與該預訂時間段屬性相同的歷史時間段內的訂單資料，然後基於這些訂單資料進行訂單需求資訊預測。比如，若某預訂時間段處於五一假日期間，則可以獲取最近3年內五一期間的訂單資料，基於這些訂單資料預測某請求對象的訂單需求資訊。　　這裡，平台伺服器基於預測的在預訂時間段內對每個業務對象的庫存需求，生成第二預訂請求。這裡針對每個業務對象，平台伺服器可以在一次請求中完成在預訂時間段內對該業務對象的預訂，比如，預測出某連鎖酒店的標準間客房每天的預訂需求數量為N/30，則平台伺服器可以在一次預訂請求中向該連鎖酒店管理系統請求預訂N/30個該連鎖酒店的標準間客房，當然，平台伺服器也可以透過發起多次預訂請求來預訂N/30個該連鎖酒店的標準間客房，比如每次請求只預訂一個房間。　　在具體實施中，可以以上述預訂時間段的長度為一個週期，平台伺服器可以週期性發起第二預訂請求來得到第二預訂結果，比如，在上述舉例中，服務端可以每天早上向系統外發起酒店預訂請求，以預訂好當天的酒店房間。　　S402：平台伺服器根據確定的庫存需求，向所述業務對象伺服器發送第二預訂請求，該第二預訂請求中攜帶預設用戶資訊。　　在實際實施中，平台伺服器還可以根據客戶端實際發起的預訂請求，在確定庫存的預訂資訊中有剩餘的業務對象未被預訂時，向業務對象伺服器發起取消預訂請求。比如，平台伺服器早上7點請求預訂了10間某連鎖酒店的標準間客房，在晚上6點時發現剩餘5間房間沒有被預訂，此時平台伺服器可以發起取消預訂這5間房間的請求。　　S403：平台伺服器接收業務對象伺服器返回的攜帶預訂成功的資訊的第二預訂結果，用於作為初始庫存的預訂資訊。　　S404：客戶端接收用戶提交的預訂對象資訊。　　S405：客戶端基於接收的預訂對象資訊，向平台伺服器發送第一預訂請求；其中，所述第一預訂請求中攜帶有所述預訂對象資訊以及客戶端用戶資訊。　　S406：平台伺服器根據所述第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷所述庫存的預訂資訊是否滿足所述第一預訂請求，若滿足進入S407a，若不滿足，進入S407b。　　S407a：平台伺服器在庫存的預訂資訊滿足第一預訂請求時，基於第一預訂請求對應的預訂對象資訊以及客戶端用戶資訊，生成第一預訂結果，更新庫存的預訂資訊，並進入S408及S409。　　S408：向業務對象伺服器發送預訂資訊更新請求，用於請求將與第一預訂結果關聯的用戶資訊從發送第二預訂請求時使用的預設用戶資訊更新為客戶端用戶資訊。　　S407b：平台伺服器在庫存的預訂資訊不滿足第一預訂請求時，向業務對象伺服器發送第一預訂請求，並接收業務對象伺服器反饋的第一預訂結果。　　這裡，平台伺服器基於正常的預訂流程發起預訂。　　S409：平台伺服器將第一預訂結果反饋給客戶端。　　這裡，客戶端接收平台伺服器基於所述第一預訂請求中的預訂對象資訊和庫存的預訂資訊反饋的第一預訂結果。　　採用上述實施例，平台伺服器可以在用戶實際向該平台伺服器發起預訂請求之前預先向系統外的業務對象伺服器發起預訂請求，將得到的預訂結果作為初始庫存的預訂資訊儲存起來。在接收到客戶端實際發起的預訂請求後，再基於本地庫存的預訂資訊向客戶端返回與用戶實際的預訂請求對應的預訂結果。這樣，由於不需要平台伺服器在接收到客戶端請求時再臨時向業務對象伺服器發起請求，客戶端可以及時得到平台伺服器返回的預訂結果，從而提高了預訂效率及預訂成功率，進而提升了用戶體驗。　　基於同一發明構思，本發明實施例中還提供了一種與業務對象預訂方法對應的業務對象預訂系統及裝置，由於該系統及裝置解決問題的原理與本申請實施例的業務對象預訂方法相似，因此該系統及裝置的實施可以參見方法的實施，重複之處不再贅述。實施例三　　如圖5所示，為本申請實施例三提供的業務對象預訂系統500示意圖，包括：　　平台伺服器51，用於接收客戶端發送的攜帶有預訂對象資訊的第一預訂請求；根據該預訂對象資訊以及庫存的預訂資訊，判斷庫存的預訂資訊是否滿足所述第一預訂請求，其中所述庫存的預訂資訊為平台伺服器透過預先發起攜帶有預訂對象資訊的第二預訂請求得到的；若滿足，則生成所述第一預訂請求對應的第一預訂結果，若不滿足，則透過向業務對象伺服器發送所述第一預訂請求得到第一預訂結果；將所述第一預訂結果反饋給客戶端；　　客戶端52，用於接收用戶提交的預訂對象資訊，並基於該預訂對象資訊向平台伺服器發送所述第一預訂請求；接收所述平台伺服器基於所述第一預訂請求中的預訂對象資訊和所述庫存的預訂資訊反饋的所述第一預訂結果；　　業務對象伺服器53，用於接收所述平台伺服器預先發起的所述第二預訂請求，並向所述平台伺服器反饋第二預訂結果，所述第二預訂結果中包含有與所述第二預訂請求對應的預訂成功的資訊，用於作為所述平台伺服器初始庫存的預訂資訊；還用於接收所述平台伺服器發送的由用戶發起的所述第一預訂請求，並向所述平台伺服器反饋所述第一預訂結果。　　可選地，所述預訂對象為酒店，所述業務對象伺服器為酒店管理伺服器，所述預訂對象資訊包括預訂的酒店名稱和房間類型。　　可選地，所述平台伺服器51具體用於根據以下步驟發起所述第二預訂請求：　　根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；所述歷史預訂資料包括針對所述預訂對象，用戶實際發起預訂的預訂資料，所述庫存需求包括各用戶針對所述業務對象伺服器提供的預訂對象的需求總量；　　根據確定的所述庫存需求，向所述業務對象伺服器發送所述第二預訂請求。　　可選地，所述第一預訂請求中還攜帶有客戶端用戶資訊；所述第二預訂請求中還攜帶有預設用戶資訊；　　在所述庫存的預訂資訊滿足所述第一預訂請求時，平台伺服器51具體用於根據以下步驟生成所述第一預訂結果：　　基於所述第一預訂請求中攜帶的客戶端用戶資訊，和所述第一預訂請求對應的預訂對象資訊，生成所述第一預訂結果；其中，所述第一預訂結果中包含有與所述第一預訂請求對應的預訂成功的資訊和所述客戶端用戶資訊；　　平台伺服器51還用於：　　在生成所述第一預訂結果之後，向所述業務對象伺服器發送預訂資訊更新請求；所述預訂資訊更新請求用於請求將與所述第一預訂結果關聯的用戶資訊從發送所述第二預訂請求時使用的預設用戶資訊更新為所述客戶端用戶資訊；　　業務對象伺服器53還用於：　　根據所述預訂資訊更新請求，將儲存的與所述第一預訂結果關聯的用戶資訊從所述預設用戶資訊更新為所述客戶端用戶資訊。　　可選地，平台伺服器51還用於：　　在更新庫存的預訂資訊之後，判斷所述預訂對象的庫存量是否低於設定閾值；　　若是，則向管理方推送庫存告警資訊，用於提示管理方選擇是否補充庫存；或者，自動向所述業務對象伺服器發起預訂流程。實施例四　　如圖6所示，為本申請實施例四提供的平台伺服器600結構示意圖，包括：　　接收模組61，用於接收客戶端發送的第一預訂請求；所述第一預訂請求中攜帶有預訂對象資訊；　　預訂處理模組62，用於根據所述第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷所述庫存的預訂資訊是否滿足所述第一預訂請求；其中所述庫存的預訂資訊中包含預先透過發送模組63向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；若所述庫存的預訂資訊滿足所述第一預訂請求，則基於所述第一預訂請求對應的預訂對象資訊，生成第一預訂結果；若所述庫存的預訂資訊不滿足所述第一預訂請求，則控制發送模組63向業務對象伺服器發送第一預訂請求，並透過接收模組61接收所述業務對象伺服器反饋的第一預訂結果；　　發送模組63，還用於將所述第一預訂結果反饋給所述客戶端。　　可選地，預訂處理模組62具體用於根據以下步驟發送所述第二預訂請求：　　根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；所述歷史預訂資料包括針對所述預訂對象，用戶實際發起預訂的預訂資料，所述庫存需求包括各用戶針對所述業務對象伺服器提供的預訂對象的需求總量；　　根據確定的所述庫存需求，向所述業務對象伺服器發送所述第二預訂請求。　　可選地，所述第一預訂請求中還攜帶有客戶端用戶資訊；所述第二預訂請求中還攜帶有預設用戶資訊；　　所述預訂處理模組62具體用於根據以下步驟生成所述第一預訂結果：　　基於所述第一預訂請求中攜帶的客戶端用戶資訊，和所述第一預訂請求對應的預訂對象資訊，生成所述第一預訂結果；其中，所述第一預訂結果中包含有與所述第一預訂請求對應的預訂成功的資訊和所述客戶端用戶資訊；　　所述發送模組63還用於：　　向所述業務對象伺服器發送預訂資訊更新請求；所述預訂資訊更新請求用於請求將與所述第一預訂結果關聯的用戶資訊從發送所述第二預訂請求時使用的預設用戶資訊更新為所述客戶端用戶資訊。　　可選地，所述預訂處理模組62還用於：　　基於所述第一預訂請求對應的預訂對象資訊，生成第一預訂結果之後，更新庫存的預訂資訊。　　可選地，所述預訂處理模組62還用於：　　在更新庫存的預訂資訊之後，判斷所述預訂對象的庫存量是否低於設定閾值；若是，則透過所述發送模組63向管理方推送庫存告警資訊，用於提示管理方選擇是否補充庫存；或者，自動向所述業務對象伺服器發起預訂流程。　　可選地，所述第一預訂請求中還攜帶有服務方標識資訊；　　所述平台伺服器600還包括：　　儲存模組64，用於在發送模組63預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，建立得到的預訂成功的資訊與該業務對象伺服器對應的服務方標識資訊之間的映射關係，並將該映射關係作為庫存的預訂資訊進行儲存；　　所述預訂處理模組62具體用於根據以下步驟判斷所述庫存的預訂資訊是否滿足所述第一預訂請求：　　根據所述第一預訂請求中攜帶的服務方標識資訊，從庫存的預訂資訊中查找與該服務方標識資訊對應的預訂成功的資訊；根據所述第一預訂請求中的預訂對象資訊，判斷查找到的預訂成功的資訊是否滿足所述第一預訂請求。　　上述平台伺服器，可以在用戶實際向該平台伺服器發起預訂請求之前預先向系統外的業務對象伺服器發起預訂請求，將得到的預訂結果作為初始庫存的預訂資訊儲存起來。在接收到客戶端實際發起的預訂請求後，再基於本地庫存的預訂資訊向客戶端返回與用戶實際的預訂請求對應的預訂結果。這樣，由於不需要平台伺服器在接收到客戶端請求時再臨時向業務對象伺服器發起請求，客戶端可以及時得到平台伺服器返回的預訂結果，從而提高了預訂效率及預訂成功率，進而提升了用戶體驗。實施例五　　如圖7所示，為本申請實施例五提供的客戶端700結構示意圖，包括：　　第一接收模組71，用於接收用戶提交的預訂對象資訊；　　生成模組72，用於基於所述預訂對象資訊，生成第一預訂請求；其中，所述第一預訂請求中攜帶有所述預訂對象資訊；　　發送模組73，用於發送所述第一預訂請求；　　第二接收模組74，用於接收所述平台伺服器基於所述第一預訂請求中的預訂對象資訊和庫存的預訂資訊反饋的第一預訂結果；其中所述庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；所述第一預訂結果中包含有與所述第一預訂請求對應的預訂成功的資訊。　　採用上述客戶端，可以向用戶及時返回平台伺服器基於預先儲存的預訂資訊返回的預訂結果，提高了預訂效率及預訂成功率，進而提升了用戶體驗。　　本領域內的技術人員應明白，本申請的實施例可提供為方法、系統、或計算機程式產品。因此，本申請可採用完全硬體實施例、完全軟體實施例、或結合軟體和硬體方面的實施例的形式。而且，本申請可採用在一個或多個其中包含有計算機可用程式代碼的計算機可用儲存媒體（包括但不限於磁碟記憶體、CD-ROM、光學記憶體等）上實施的計算機程式產品的形式。　　本申請是參照根據本申請實施例的方法、裝置（系統）、和計算機程式產品的流程圖和／或方框圖來描述的。應理解可由計算機程式指令實現流程圖和／或方框圖中的每一流程和／或方框、以及流程圖和／或方框圖中的流程和／或方框的結合。可提供這些計算機程式指令到通用計算機、專用計算機、嵌入式處理機或其他可編程資料處理設備的處理器以產生一個機器，使得透過計算機或其他可編程資料處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和／或方框圖一個方框或多個方框中指定的功能的裝置。　　這些計算機程式指令也可儲存在能引導計算機或其他可編程資料處理設備以特定方式工作的計算機可讀記憶體中，使得儲存在該計算機可讀記憶體中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖一個流程或多個流程和／或方框圖一個方框或多個方框中指定的功能。　　這些計算機程式指令也可裝載到計算機或其他可編程資料處理設備上，使得在計算機或其他可編程設備上執行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程設備上執行的指令提供用於實現在流程圖一個流程或多個流程和／或方框圖一個方框或多個方框中指定的功能的步驟。　　儘管已描述了本申請的較佳實施例，但本領域內的技術人員一旦得知了基本創造性概念，則可對這些實施例作出另外的變更和修改。所以，所附申請專利範圍意欲解釋為包括較佳實施例以及落入本申請範圍的所有變更和修改。　　顯然，本領域的技術人員可以對本申請進行各種改動和變型而不脫離本申請的精神和範圍。這樣，倘若本申請的這些修改和變型屬於本申請權利要求及其等同技術的範圍之內，則本申請也意圖包含這些改動和變型在內。

500‧‧‧業務對象預訂系統51‧‧‧平台伺服器52‧‧‧客戶端53‧‧‧業務對象伺服器600‧‧‧平台伺服器61‧‧‧接收模組62‧‧‧預訂處理模組63‧‧‧發送模組64‧‧‧儲存模組700‧‧‧客戶端71‧‧‧第一接收模組72‧‧‧生成模組73‧‧‧發送模組74‧‧‧第二接收模組

圖1為背景中的預訂流程示意圖；　　圖2為本申請實施例一提供的業務對象預訂方法流程圖；　　圖3為本申請實施的一個示例效果圖；　　圖4為本申請實施例二提供的業務對象預訂方法流程圖；　　圖5為本申請實施例三提供的業務對象預訂系統示意圖；　　圖6為本申請實施例四提供的平台伺服器結構示意圖；　　圖7為本申請實施例五提供的客戶端結構示意圖。

Claims

一種業務對象預訂系統，其特徵在於，該系統包括：平台伺服器，用於接收客戶端發送的攜帶有預訂對象資訊的第一預訂請求；根據該預訂對象資訊以及庫存的預訂資訊，判斷庫存的預訂資訊是否滿足該第一預訂請求，其中該庫存的預訂資訊為平台伺服器透過預先發起攜帶有預訂對象資訊的第二預訂請求得到的；若滿足，則生成該第一預訂請求對應的第一預訂結果，若不滿足，則透過向業務對象伺服器發送該第一預訂請求得到第一預訂結果；將該第一預訂結果反饋給客戶端；客戶端，用於接收用戶提交的預訂對象資訊，並基於該預訂對象資訊向平台伺服器發送該第一預訂請求；接收該平台伺服器基於該第一預訂請求中的預訂對象資訊和該庫存的預訂資訊反饋的該第一預訂結果；業務對象伺服器，用於接收該平台伺服器預先發起的該第二預訂請求，並向該平台伺服器反饋第二預訂結果，該第二預訂結果中包含有與該第二預訂請求對應的預訂成功的資訊，用於作為該平台伺服器初始庫存的預訂資訊；還用於接收該平台伺服器發送的由用戶發起的該第一預訂請求，並向該平台伺服器反饋該第一預訂結果，其中，該平台伺服器具體用於根據以下步驟發起該第二預訂請求：根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；該歷史預訂資料包括針對該預訂對象，用戶實際發起預訂的預訂資料，該庫存需求包括各用戶針對該業務對象伺服器提供的預訂對象的需求總量；根據確定的該庫存需求，向該業務對象伺服器發送該第二預訂請求。
如請求項1所述的系統，其中，該預訂對象為酒店，該業務對象伺服器為酒店管理伺服器，該預訂對象資訊包括預訂的酒店名稱和房間類型。
如請求項1所述的系統，其中，該第一預訂請求中還攜帶有客戶端用戶資訊；該第二預訂請求中還攜帶有預設用戶資訊；在該庫存的預訂資訊滿足該第一預訂請求時，該平台伺服器具體用於根據以下步驟生成該第一預訂結果：基於該第一預訂請求中攜帶的客戶端用戶資訊，和該第一預訂請求對應的預訂對象資訊，生成該第一預訂結果；其中，該第一預訂結果中包含有與該第一預訂請求對應的預訂成功的資訊和該客戶端用戶資訊；該平台伺服器還用於：在生成該第一預訂結果之後，向該業務對象伺服器發送預訂資訊更新請求；該預訂資訊更新請求用於請求將與該第一預訂結果關聯的用戶資訊從發送該第二預訂請求時使用的預設用戶資訊更新為該客戶端用戶資訊；該業務對象伺服器還用於：根據該預訂資訊更新請求，將儲存的與該第一預訂結果關聯的用戶資訊從該預設用戶資訊更新為該客戶端用戶資訊。
如請求項1所述的系統，其中，該平台伺服器還用於：在更新庫存的預訂資訊之後，判斷該預訂對象的庫存量是否低於設定閾值；若是，則向管理方推送庫存告警資訊，用於提示管理方選擇是否補充庫存；或者，自動向該業務對象伺服器發起預訂流程。
一種業務對象預訂方法，其特徵在於，該方法包括：平台伺服器接收客戶端發送的第一預訂請求；該第一預訂請求中攜帶有預訂對象資訊；根據該第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷該庫存的預訂資訊是否滿足該第一預訂請求；其中該庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；若滿足，則基於該第一預訂請求對應的預訂對象資訊，生成第一預訂結果；若不滿足，則向該業務對象伺服器發送該第一預訂請求，並接收該業務對象伺服器反饋的第一預訂結果；將該第一預訂結果反饋給該客戶端，其中，該平台伺服器預先向業務對象伺服器發起該第二預訂請求，包括：該平台伺服器根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；該歷史預訂資料包括針對該預訂對象，用戶實際發起預訂的預訂資料，該庫存需求包括各用戶針對該業務對象伺服器提供的預訂對象的需求總量；根據確定的該庫存需求，向該業務對象伺服器發送該第二預訂請求。
如請求項5所述的方法，其中，該第一預訂請求中還攜帶有客戶端用戶資訊；該第二預訂請求中還攜帶有預設用戶資訊；在該庫存的預訂資訊滿足該第一預訂請求時，所述基於該第一預訂請求對應的預訂對象資訊，生成該第一預訂結果，包括：基於該第一預訂請求中攜帶的客戶端用戶資訊，和該第一預訂請求對應的預訂對象資訊，生成該第一預訂結果；其中，該第一預訂結果中包含有與該第一預訂請求對應的預訂成功的資訊和該客戶端用戶資訊；生成該第一預訂結果之後，還包括：向該業務對象伺服器發送預訂資訊更新請求；該預訂資訊更新請求用於請求將與該第一預訂結果關聯的用戶資訊從發送該第二預訂請求時使用的預設用戶資訊更新為該客戶端用戶資訊。
如請求項5所述的方法，其中，基於該第一預訂請求對應的預訂對象資訊，生成第一預訂結果之後，還包括：更新庫存的預訂資訊。
如請求項7所述的方法，其中，所述更新庫存的預訂資訊之後，還包括：判斷該預訂對象的庫存量是否低於設定閾值；若是，則向管理方推送庫存告警資訊，用於提示管理方選擇是否補充庫存；或者，自動向該業務對象伺服器發起預訂流程。
如請求項5所述的方法，其中，該第一預訂請求中還攜帶有服務方標識資訊；該平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，還包括：建立得到的預訂成功的資訊與該業務對象伺服器對應的服務方標識資訊之間的映射關係，並將該映射關係作為庫存的預訂資訊進行儲存；所述根據該第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷該庫存的預訂資訊是否滿足該第一預訂請求，包括：根據該第一預訂請求中攜帶的服務方標識資訊，從庫存的預訂資訊中查找與該服務方標識資訊對應的預訂成功的資訊；根據該第一預訂請求中的預訂對象資訊，判斷查找到的預訂成功的資訊是否滿足該第一預訂請求。
一種用戶請求處理方法，其特徵在於，該方法包括：客戶端接收用戶提交的預訂對象資訊；向平台伺服器發送第一預訂請求；其中，該第一預訂請求中攜帶有該預訂對象資訊；接收該平台伺服器基於該第一預訂請求中的預訂對象資訊和庫存的預訂資訊反饋的第一預訂結果；其中該庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；該第一預訂結果中包含有與該第一預訂請求對應的預訂成功的資訊，其中，該平台伺服器預先向業務對象伺服器發起該第二預訂請求，包括：該平台伺服器根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；該歷史預訂資料包括針對該預訂對象，用戶實際發起預訂的預訂資料，該庫存需求包括各用戶針對該業務對象伺服器提供的預訂對象的需求總量；根據確定的該庫存需求，向該業務對象伺服器發送該第二預訂請求。
一種平台伺服器，其特徵在於，包括：接收模組，用於接收客戶端發送的第一預訂請求；該第一預訂請求中攜帶有預訂對象資訊；預訂處理模組，用於根據該第一預訂請求中的預訂對象資訊以及庫存的預訂資訊，判斷該庫存的預訂資訊是否滿足該第一預訂請求；若滿足，則基於該第一預訂請求對應的預訂對象資訊，生成第一預訂結果；若不滿足，則控制發送模組向該業務對象伺服器發送該第一預訂請求，並透過該接收模組接收該業務對象伺服器反饋的第一預訂結果；該發送模組，還用於將該第一預訂結果反饋給該客戶端；其中，該庫存的預訂資訊中包含預先透過發送模組向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊，其中，該預訂處理模組具體用於根據以下步驟發送該第二預訂請求：根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；該歷史預訂資料包括針對該預訂對象，用戶實際發起預訂的預訂資料，該庫存需求包括各用戶針對該業務對象伺服器提供的預訂對象的需求總量；根據確定的該庫存需求，向該業務對象伺服器發送該第二預訂請求。
如請求項11所述的平台伺服器，其中，該第一預訂請求中還攜帶有客戶端用戶資訊；該第二預訂請求中還攜帶有預設用戶資訊；該預訂處理模組具體用於根據以下步驟生成該第一預訂結果：基於該第一預訂請求中攜帶的客戶端用戶資訊，和該第一預訂請求對應的預訂對象資訊，生成該第一預訂結果；其中，該第一預訂結果中包含有與該第一預訂請求對應的預訂成功的資訊和該客戶端用戶資訊；該發送模組還用於：向該業務對象伺服器發送預訂資訊更新請求；該預訂資訊更新請求用於請求將與該第一預訂結果關聯的用戶資訊從發送該第二預訂請求時使用的預設用戶資訊更新為該客戶端用戶資訊。
如請求項11所述的平台伺服器，其中，該預訂處理模組還用於：基於該第一預訂請求對應的預訂對象資訊，生成第一預訂結果之後，更新庫存的預訂資訊。
如請求項13所述的平台伺服器，其中，該預訂處理模組還用於：在更新庫存的預訂資訊之後，判斷該預訂對象的庫存量是否低於設定閾值；若是，則透過該發送模組向管理方推送庫存告警資訊，用於提示管理方選擇是否補充庫存；或者，自動向該業務對象伺服器發起預訂流程。
如請求項11所述的平台伺服器，其中，該第一預訂請求中還攜帶有服務方標識資訊；該平台伺服器還包括：儲存模組，用於在該發送模組預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，建立得到的預訂成功的資訊與該業務對象伺服器對應的服務方標識資訊之間的映射關係，並將該映射關係作為庫存的預訂資訊進行儲存；該預訂處理模組具體用於根據以下步驟判斷該庫存的預訂資訊是否滿足該第一預訂請求：根據該第一預訂請求中攜帶的服務方標識資訊，從庫存的預訂資訊中查找與該服務方標識資訊對應的預訂成功的資訊；根據該第一預訂請求中的預訂對象資訊，判斷查找到的預訂成功的資訊是否滿足該第一預訂請求。
一種客戶端，其特徵在於，包括：第一接收模組，用於接收用戶提交的預訂對象資訊；生成模組，用於基於該預訂對象資訊，生成第一預訂請求；其中，該第一預訂請求中攜帶有該預訂對象資訊；發送模組，用於發送該第一預訂請求；第二接收模組，用於接收該平台伺服器基於該第一預訂請求中的預訂對象資訊和庫存的預訂資訊反饋的第一預訂結果；其中該庫存的預訂資訊中包含有平台伺服器預先向業務對象伺服器發起攜帶有預訂對象資訊的第二預訂請求後，得到的預訂成功的資訊；該第一預訂結果中包含有與該第一預訂請求對應的預訂成功的資訊，其中，該平台伺服器預先向業務對象伺服器發起該第二預訂請求，包括：該平台伺服器根據歷史預訂資料，確定在未來預訂時間段內的庫存需求；該歷史預訂資料包括針對該預訂對象，用戶實際發起預訂的預訂資料，該庫存需求包括各用戶針對該業務對象伺服器提供的預訂對象的需求總量；根據確定的該庫存需求，向該業務對象伺服器發送該第二預訂請求。