TW201802741A

TW201802741A - 訂單信息處理以及訂單類型轉換處理方法及裝置

Info

Publication number: TW201802741A
Application number: TW106118546A
Authority: TW
Inventors: 黃宇舟; 胡光華; 袁超; 劉偉
Original assignee: 阿里巴巴集團服務有限公司
Priority date: 2016-07-06
Filing date: 2017-06-05
Publication date: 2018-01-16
Also published as: CN107590706A; WO2018006717A1

Abstract

本案實施例公開了訂單信息處理以及訂單類型轉換處理方法及裝置，所述方法包括：伺服器接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；如果滿足，則創建訂單，並添加信用標識符，並將所述信用擔保訂單提供給所述第一用戶的資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。藉由本案實施例，能夠提高用戶信息安全性，提高效率，節省網路資源。

Description

訂單信息處理以及訂單類型轉換處理方法及裝置

本案涉及訂單信息處理技術領域，特別是涉及訂單信息處理以及訂單類型轉換處理方法及裝置。

隨著電子商務交易平台以及線上支付業務不斷擴大，線上到線下(O2O)市場的重要性逐漸凸顯出來，而“衣食住行”中“住”作為其中非常重要的組成部分，人們對於旅遊服務品質的追求也上升到了全新的高度。在此背景下，未來的飯店業將需要在技術設備、營銷模式、經營效率及服務理念等方面升級到新的高度，才能滿足消費者預期，提升行業競爭力。

現有技術中，一些電商平台能夠提供“線上訂房線下入住”的服務，線上預訂飯店時，如果指定了入住日期，並且要求飯店為其保留房間，則用戶通常需要支付一定的保證金，如果用戶不按時入住，則保證金不予退還，以免造成飯店的經濟損失。而如果用戶按時入住，則在用戶退房時，將保證金退還給用戶。

以上這種傳統的擔保方式具有一些弊端，首先，需要用戶提前支付保證金，會對用戶的資金造成占用；其次，通常需要將用戶的支付帳戶信息提供給飯店，其中，對於一些國內飯店，能夠支持的支付途徑比較多，可以包括銀行卡、支付寶等、其他第三方支付工具等，而一些國際的飯店，通常只能支持銀行卡支付，但無論採用何種支付方式，都存在將用戶的帳戶信息提供給飯店的情况，因此，在支付的過程中存在安全隱患；再者，操作流程相對複雜，效率比較低，在用戶按時入住的情况下，還需要執行逆向流程，將保證金退還到用戶的帳戶，對於網路資源等也會造成一定程度的浪費，並且逆向流程一般無法即時到帳，用戶資金占用時間更長，另外，通常還需要經由支付工具交易明細查詢資金到帳情况，體驗非常差。

本案提供了訂單信息處理以及訂單類型轉換處理方法及裝置，能夠提高用戶信息安全性，提高效率，節省網路資源。

本案提供了如下方案：一種訂單信息處理方法，包括：伺服器接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；如果滿足，則創建訂單，並添加信用標識符，並將所述信用擔保訂單提供給所述第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

一種訂單信息處理方法，包括：第一用戶資料處理系統接收伺服器提供的信用擔保訂單，所述信用擔保訂單藉由以下方式產生：所述伺服器在接收到客戶端針對目標資料對象創建擔保訂單的請求時，判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則創建訂單，並添加信用標識符；如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。

一種訂單類型轉換處理方法，包括：伺服器記錄業務訂單的相關信息，所述相關信息包括所述業務訂單關聯的第一用戶以及第二用戶信息，所述業務訂單為非擔保訂單；接收將指定非擔保訂單轉換為擔保訂單的請求；判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件；如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單，並將轉換結果提供給第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

一種訂單類型轉換處理方法，包括：第一用戶資料處理系統向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；接收伺服器返回的轉換結果，以便按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

一種訂單類型轉換處理方法，包括：第二用戶客戶端向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；接收伺服器返回的轉換結果。

一種訂單信息處理裝置，應用於伺服器，包括：請求接收單元，用於接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；判斷單元，用於判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；訂單創建單元，用於如果所述判斷單元的判斷結果為滿足，則創建訂單，並添加信用標識符，並將所述信用擔保訂單提供給所述第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

一種訂單信息處理裝置，應用於第一用戶資料處理系統，包括：訂單接收單元，用於接收伺服器提供的信用擔保訂單，所述信用擔保訂單藉由以下方式產生：所述伺服器在接收到客戶端針對目標資料對象創建擔保訂單的請求時，判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則創建訂單，標記為並添加信用擔保訂單標識符；狀態提交單元，用於如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。

一種訂單類型轉換處理裝置，應用於伺服器，包括：訂單信息記錄單元，用於記錄業務訂單的相關信息，所述相關信息包括所述業務訂單關聯的第一用戶以及第二用戶信息，所述業務訂單為非擔保訂單；轉換請求接收單元，用於接收將指定非擔保訂單轉換為擔保訂單的請求；信用判斷單元，用於判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件；轉換單元，用於如果所述信用判斷單元的判斷結果為滿足，則將所述指定非擔保訂單轉換為信用擔保訂單，並將轉換結果提供給第一用戶的資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

一種訂單類型轉換處理裝置，應用於第一用戶資料處理系統，包括：第一轉換請求提交單元，用於向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；第一轉換結果接收單元，用於接收伺服器返回的轉換結果，以便按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

一種訂單類型轉換處理裝置，應用於第二用戶客戶端，包括：第二轉換請求提交單元，用於向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；第二轉換結果接收單元，用於接收伺服器返回的轉換結果。

根據本案提供的具體實施例，本案公開了以下技術效果：藉由本案實施例，對於信用度比較高的第二用戶，採用的是信任的態度，在其需要第一用戶為其提供預留線下資源的服務時，可以在不必支付保證金的情况下，即可享受相應的服務。這樣，在用戶未發生違約的情况下，就不會造成對用戶資金的額外占用，並且，由於不必將第二用戶的支付帳戶等信息提供給第一用戶，因此，也保證了第二用戶隱私信息的安全性。另外，由於不必執行第二用戶預先支付保證金、第一用戶再退還保證金等一系列的流程，因此，也大大節省了系統在網路、儲存等方面的資源。對於第二用戶而言，會感覺到自己在消費過程中被信任而獲得尊重，因此，也可以提升第二用戶的體驗。

對於第一用戶而言，在第二用戶未按時履約的情况下，還可以由伺服器將相應的款項，從第二用戶的支付帳戶劃撥到第一用戶的收款帳戶，因此，也不會使得第一用戶受到損失。

當然，實施本案的任一產品並不一定需要同時達到以上所述的所有優點。

701‧‧‧請求接收單元

702‧‧‧判斷單元

703‧‧‧訂單創建單元

801‧‧‧訂單接收單元

802‧‧‧狀態提交單元

901‧‧‧訂單信息記錄單元

902‧‧‧轉換請求單元

903‧‧‧信用判斷單元

904‧‧‧轉換單元

1001‧‧‧第一轉換請求單元

1002‧‧‧第一轉換結果接收單元

1101‧‧‧第二轉換請求提交單元

1102‧‧‧第二轉換結果接收單元

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

圖1是本案實施例提供的系統的示意圖；圖2是本案實施例提供的第一方法的流程圖；圖3是本案實施例提供的第二方法的流程圖；圖4是本案實施例提供的第三方法的流程圖；圖5是本案實施例提供的第四方法的流程圖；圖6是本案實施例提供的第五方法的流程圖；圖7是本案實施例提供的第一裝置的示意圖；圖8是本案實施例提供的第二裝置的示意圖；圖9是本案實施例提供的第三裝置的示意圖；圖10是本案實施例提供的第四裝置的示意圖；圖11是本案實施例提供的第五裝置的示意圖。

下面將結合本案實施例中的附圖，對本案實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本案一部分實施例，而不是全部的實施例。基於本案中的實施例，本領域普通技術人員所獲得的所有其他實施例，都屬本案保護的範圍。

在本案實施例中，第一用戶可以是商家用戶或者賣家用戶等，並且這種第一用戶通常是以提供線下資源的方式，為第二用戶提供服務，相應的，第二用戶就是藉由使用第一用戶提供的線下資源獲得相應服務的買家用戶、消費者用戶等。具體的，對於不同類別的第一用戶，線下資源的具體種類也有所不同，例如，對於飯店類的第一用戶，具體的線下資源可以包括客房、房內的設施等等，對於汽車租賃類的第一用戶，具體的線下資源主要是指汽車等。

針對上述應用場景，在本申請人提交的其他專利申請案中，提供了以下技術方案：基於現有的電子商務交易平台(例如，阿里旅行、支付寶等，為便於描述，這裏以阿里旅行為例進行介紹)，可以為用戶提供“信用消費服務”，例如，可以稱為“信用住”等。具體實現時，參見圖1，涉及到的交互實體通常包括：平台伺服器，平台提供的第二用戶客戶端，以及第一用戶資料處理系統(例如，飯店的PMS(Property Management System，經營管理系統))或者平台提供的第一用戶客戶端等(為便於描述，這裏以PMS為例進行介紹，此時，平台與第一用戶PMS之間可以是合作關係，可以預先開放自己的一些介面給對方)。當第二用戶具體需要使用信用消費服務(例如，信用住)時，可以首先利用平台的第二用戶客戶端，線上預訂具有“信用住”屬性的飯店，平台伺服器依據支付寶信用體系校驗用戶信用等級，符合信用等級的用戶可以享受信用住模式預定，並將用戶預定信息即時傳遞到第一用戶PMS系統，第一用戶前台也可以直接看到訂單信息。第二用戶到第一用戶辦理入住時，可以直接進行免押金入住，在第二用戶退房時，免查房、免排隊，平台伺服器可以直接將實際消費的資金從第二用戶的關聯帳戶(例如，支付寶帳戶等)劃撥到第一用戶的帳戶。或者，在其中的“信用住”模式下，第二用戶也可以不必預先線上預訂，而是直接到飯店辦理入住，此時，第一用戶PMS系統也可以採集第二用戶的身份信息、支付寶帳戶信息等，將其傳遞給平台伺服器，平台伺服器對第二用戶進行信用權限驗證，如果滿足條件，則可以通知飯店為該第二用戶辦理信用住，同樣，該第二用戶也可以免押金入住，退房時免查房、免排隊，由平台伺服器辦理結帳事宜。

總之，在提供信用消費服務的過程中，阿里旅行等電子商務交易平台可以與第一用戶的PMS系統相互配合，為第一用戶以及第二用戶都提供了便利。相應的，本案實施例就可以在以上技術方案的基礎上，利用伺服器能夠與第一用戶PMS系統相互配合這一特點，進一步提供訂單擔保的處理方法，以便在開具訂單擔保環節上也能夠為第一用戶以及第二用戶提供便利，提高效率，節省用戶時間。當然，在實際應用中，能夠提供“信用消費服務”功能的應用平台也不限於阿里旅行，例如，還可以為該功能提供專用的伺服器，開發專用的第一用戶客戶端、第二用戶客戶端，等等。另外，在實現本案實施例中的處理擔保訂單的功能時，也可以不必以實現“信用消費服務”功能為前提，也就是說，可以單獨提供處理擔保訂單的功能。

需要說明的是，前文所述中提及的“飯店”、“阿里旅行”、“信用住”等是為了對本案實施例的具體實現方式進行舉例說明，不應看作是對本案實施例保護範圍的限定。

下面對具體的實現方式進行詳細介紹。

實施例一

該實施例一首先從伺服器的角度提供了一種訂單信息處理方法，參見圖2，該方法可以包括以下步驟：

S201：伺服器接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；具體實現時，飯店等第一用戶可以將其飯店產品發布到伺服器，伺服器就可以以資料對象的形式提供給客戶端，其中，如果第一用戶想要提供擔保形式的服務，則在發布資料對象時可以提供相應的屬性信息，包括所需的保證金金額等等。伺服器在向客戶端提供資料對象信息時，就可以根據第一用戶發布資料對象時提供的屬性信息，提供相應的信息。這樣，如果某用戶在預訂某第一用戶的資料對象時，發現存在可產生擔保訂單的選項，則可以經由該選項，向伺服器發起創建擔保訂單的請求。

S202：判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；伺服器在收到客戶端的請求後，可以首先對第二用戶的信用信息進行判斷，具體的判斷方式可以有多種，例如，具體的驗證方式可以有多種，並且，具體的業務條件可以根據實際的業務需求來確定。例如，可以是對用戶的信用等級、信用額度的大小、未結帳交易訂單的數量等進行限制。這樣，伺服器具體在進行判斷時，針對業務條件中涉及到的各項參數，可以確定出當前用戶對應的參數值，並與條件中設定的門檻值等進行比對，進而確定用戶是否符合業務條件。例如，在阿里旅行平台下，可以獲取到用戶的支付寶帳戶關聯的“芝麻信用”信息，還可以獲取“螞蟻花唄”為該第二用戶提供的額度信息，另外，還可以確定出該支付寶帳戶關聯的未結帳訂單數量，等等，以上因素都可以用於確定當前用戶是否滿足業務條件。

其中，如果資料對象信息中記錄有如果發生未按時履約的情况下，需要支付的金額信息，則在進行業務條件判斷時，還可以判斷用戶的根據所述第二用戶的信用信息，確定所述第二用戶的授信額度，如果所述授信額度大於所述預置金額，則確定所述第二用戶的信用信息滿足所述預置的業務條件。

S203：如果滿足，則創建訂單，並添加信用標識符；如果滿足條件，即可產生訂單，並將訂單的類型標記為信用擔保訂單。例如，在一種方式下，可以在保存訂單信息的資料表中提供“是否為擔保訂單”的字段，在產生擔保訂單的情况下，可以將該字段的值置為“是”，等等。

需要說明的是，在本案實施例中，在產生擔保訂單後，只需要添加相應的標識符即可，第二用戶不需要執行支付保證金操作，也就不存在將其支付帳戶信息提供給第一用戶的情况，因此，可以降低安全隱患。當然，關於在用戶未按時入住等情况下需要支付的金額，可以記錄在相應的訂單中，以便後續當發生這種違約情况時，按照訂單中記錄的金額，向第一用戶進行款項的劃撥。

S204：將所述信用擔保訂單提供給所述第一用戶的資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

在產生訂單後，就可以將訂單信息提供給第一用戶的資料處理系統(例如，PMS等)，這樣，在第一用戶收到訂單後，就可以按照訂單中記錄的入住日期、房型等，為第二用戶預留相應的線下資源。之後，如果第二用戶未能按照訂單中約定的時間進飯店入住，則第一用戶的資料處理系統可以將訂單狀態提供給伺服器，該訂單狀態可以為：第二用戶未按時履約，此時，伺服器再從第二用戶關聯的支付帳戶中，將相應的用作保證金的金額劃撥到第一用戶的收款帳戶中。

需要說明的是，在實際應用中，伺服器與第一用戶的資料處理系統之間可以藉由直連的方式進行互通，也即，伺服器可以與第一用戶的資料處理系統之間建立合作關係，相互開放自己的標準化介面給對方，這樣，相互之間就可以藉由介面調用的方式，實現信息的直連式互通，而不需要由雙方的工作人員藉由手動選單的形式來進行信息傳遞。

總之，藉由本案實施例提供的實現方案，對於信用度比較高的第二用戶，採用的是信任的態度，在其需要第一用戶為其提供預留線下資源的服務時，可以在不必支付保證金的情况下，即可享受相應的服務。這樣，在用戶未發生違約的情况下，就不會造成對用戶資金的額外占用，並且，由於不必將第二用戶的支付帳戶等信息提供給第一用戶，因此，也保證了第二用戶隱私信息的安全性。另外，由於不必執行第二用戶預先支付保證金、第一用戶再退還保證金等一系列的流程，因此，也大大節省了系統在網路、儲存等方面的資源。對於第二用戶而言，會感覺到自己在消費過程中獲得尊重，因此，也可以提升第二用戶的體驗。當然，對於第一用戶而言，由於在第二用戶未按時履約的情况下，還可以由伺服器將相應的款項，從第二用戶的支付帳戶劃撥到第一用戶的收款帳戶，因此，也不會使得第一用戶受到損失。

實施例二

該實施例二是與實施例一相對應的，從第一用戶資料處理系統的角度，提供了一種訂單信息處理方法，參見圖3，該方法可以包括以下步驟：S301：第一用戶的資料處理系統接收伺服器提供的信用擔保訂單，所述信用擔保訂單藉由以下方式產生：所述伺服器在接收到客戶端針對目標資料對象創建擔保訂單的請求時，判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則創建訂單，並添加信用標識符；S302：如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。

以上實施例二是與實施例一相對應的，因此，相關的具體實現參見實施例一中的介紹即可，這裏不再贅述。

實施例三

在實際應用中，還可能存在以下應用場景：第二用戶線上預訂時，採用了非擔保訂單的方式，但是，在後來又希望第一用戶為其進行線下資源的預留，此時，如果是在現有技術中，則第二用戶通常只能將原來的非擔保訂單取消，然後再重新進行預訂，並產生擔保訂單，或者要求用戶提供***等信息用來擔保。這樣顯然會使得操作流程比較繁瑣，效率不高，對於平台伺服器而言，也會造成資源的浪費。為此，在本案實施例中，在採用前述實施例中提到的擔保方式的基礎下，還可以提供進行訂單類型轉換的功能。其中，訂單類型轉換的發起方可以是第二用戶客戶端，還可以是第一用戶的資料處理系統，下面分別進行詳細介紹。

在該實施例三中，首先從伺服器的角度提供了一種訂單類型轉換處理方法，參見圖4，該方法可以包括以下步驟：

S401：伺服器記錄業務訂單的相關信息，所述相關信息包括所述業務訂單關聯的第一用戶以及第二用戶信息，所述業務訂單為非擔保訂單；具體實現時，如果是第二用戶預先藉由客戶端預訂了“信用消費服務”，則相應的業務訂單通常是由伺服器產生的，該業務訂單中可以記錄第一用戶以及第二用戶的標識信息。其中，由於是採用線上預訂的方式，因此，也即意味著第一用戶以及第二用戶都是當前平台(例如阿里旅行)的註册用戶，因此，在保存第一用戶以及第二用戶的標識信息時，可以藉由用戶id、用戶名、帳戶信息等進行保存。

如果第二用戶並沒有提前線上預訂“信用消費服務”，而是在第二用戶進店消費時，由第一用戶客戶端向伺服器發起對第二用戶的信用校驗，並在校驗通過，伺服器確定該第二用戶為可信用戶的情况下，第一用戶客戶端為其產生業務訂單，則第一用戶客戶端在產生業務訂單後，可以將業務訂單信息保存到伺服器(例如，阿里旅行的伺服器等)，包括訂單的狀態、關聯的第一用戶第二用戶標識信息等，伺服器可以對業務訂單的這些相關信息進行保存。

需要說明的是，在上述第二種情况下，關於第二用戶，該用戶通常是在阿里旅行等平台注册的用戶，因此，可以利用該用戶在平台中注册的用戶id、用戶名或者帳戶名等信息，作為第二用戶的標識。而關於第一用戶，如果第一用戶使用的是阿里旅行平台提供的客戶端，則也可以經由第一用戶在阿里旅行平台中注册的用戶id、用戶名或者帳戶名等信息進行標識。而如果是使用的第三方PMS系統，則可以藉由其他信息對第一用戶進行標識，例如，可以是第一用戶使用的設備id，或者，在PMS系統中注册的用戶id、帳戶名等等。

S402：接收將指定非擔保訂單轉換為擔保訂單的請求；具體實現時，轉換訂單類型的請求可以是由第二用戶發起的，例如，此時，可以由第二用戶客戶端向伺服器提交轉換請求。當然，在實際應用中，上述轉換請求可以是由第二用戶主動發起，或者，也可以由第一用戶的資料處理系統根據非擔保訂單中記錄的計劃入住時間等信息，提前發出提醒消息，以提醒第二用戶進行訂單類型的轉換。其中，對於後者，第一用戶的資料處理系統，可以首先將提醒信息提交到伺服器，然後，再由伺服器將提醒消息發送到第二用戶客戶端，或者，還可以根據伺服器中記錄的第二用戶的聯繫方式，藉由簡訊等方式，將提醒消息發送給第二用戶，等等。

或者，轉換訂單類型的請求也可以是由第一用戶的資料處理系統發起的，在這種情况下，可以是在第二用戶藉由某種途徑聯繫到第一用戶的情况下，兩者進行協商之後，由第一用戶資料處理系統發起訂單類型轉換的請求。當然，對於這種情况，為了確保第二用戶對該轉換操作的知情權，伺服器在接收到第一用戶的資料處理系統發送的請求後，還可以首先向第二用戶客戶端發送通知消息，通知其訂單被第一用戶的資料處理系統申請進行訂單類型轉換，在第二用戶客戶端返回確認可以轉換的情况下，再執行後續的轉換操作。

S403：判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件；該步驟中具體對第二用戶信用信息的驗證過程可以與實施例一中類似，參見實施例一中的記載即可。需要說明的是，如果之前的非擔保訂單已經是“信用消費訂單”，則意味著在產生非擔保訂單時，已經對第二用戶進行了信用驗證，因此，也可以直接根據非擔保訂單是否為信用消費訂單進行驗證。當然，由於在轉換成擔保訂單後，如果第二用戶不能按時履約，則存在按照預置的標準對第一用戶進行賠付的情况，因此，即使在之前的非擔保訂單產生過程中已經對第二用戶進行了信用校驗，該步驟中，也可以進行進一步的校驗，例如，判斷第二用戶的授信額度，是否高於失約時的賠付標準，等等。

S404：如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單，並將轉換結果提供給第一用戶的資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

在確定第二用戶的信用符合預置業務條件的情况下，即可將非擔保訂單轉換為信用擔保訂單，在本案實施例中，該轉換的過程，只需要對訂單進行標記即可，不需要執行其他操作，包括第二用戶預先支付保證金等。在類型轉換完成後，即可將轉換結果提供給第一用戶的資料處理系統，這樣，第一用戶就可以按照信用擔保的方式為第二用戶提供服務，也即，在無需第二用戶預先支付保證金的情况下，即可按照訂單中的預約信息，保留相應的線下資源，包括房間，等等。另外，在訂單類型轉換完成後，還可以將轉換結果提供給第二用戶客戶端。

在將訂單轉換為信用擔保訂單之後，後續的處理便可以與前述實施例一中相同，也即，如果第二用戶按時履約，則第二用戶無需支付與保證金相關的額外費用，而當第二用戶存在未按時履約的情况時，第一用戶的資料處理系統可以將訂單狀態信息提供給伺服器，以通知伺服器，第二用戶未能按時履約，此時，就可以由伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。

可見，在該實施例三中，可以靈活的進行訂單類型的轉換，將非擔保訂單轉換為擔保訂單，並且，在轉換過程中，同樣無需第二用戶提前支付保證金，即可享受到第一用戶為其預留相應線下資源的服務，提高效率，節省系統資源，同時，也可以提升用戶體驗。

實施例四

該實施例四是與實施例三相對應的，從第一用戶的資料處理系統角度進行介紹，具體的，參見圖5，該實施例四提供了一種訂單類型轉換處理方法，該方法可以包括以下步驟：S501：第一用戶資料處理系統向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；S502：接收伺服器返回的轉換結果，以便按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

如果第二用戶未能按時履約，則還可以向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。

實施例五

在上述實施例四中，訂單類型轉換請求是由第一用戶資料處理系統提交到伺服器的，而在另一種實現方式下，該訂單類型轉換請求也可以是由第二用戶客戶端提交到伺服器，具體的，參見圖6，該實施例五提供了一種訂單類型轉換處理方法，該方法可以包括以下步驟：S601：客戶端向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；S602：接收伺服器返回的轉換結果。

以上實施例四、五均是與實施例三相對應的，因此，相關的具體實現參見實施例三中的介紹即可，這裏不再贅述。

與實施例一相對應，本案實施例還提供了一種訂單信息處理裝置，該裝置應用於伺服器，參見圖7，該裝置具體可以包括：請求接收單元701，用於接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；判斷單元702，用於判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；訂單創建單元703，用於如果所述判斷單元的判斷結果為滿足，則創建訂單，並添加信用標識符，並將所述信用擔保訂單提供給所述第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

具體實現時，所述訂單創建單元703具體可以藉由預先獲知的所述第一用戶資料處理系統的介面，將所述信用擔保訂單提供給所述第一用戶資料處理系統。

在一種具體的實現方式下，該裝置還可以包括：訂單狀態接收單元，用於接收所述第一用戶的資料處理系統提供的所述訂單的狀態信息；資源劃撥單元，用於如果所述訂單狀態為第二用戶未按時履約，則從所述第二用戶關聯的支付帳戶劃撥預置資源信息到所述第一用戶的收款帳戶。

其中，所述預置資源信息可以由所述第一用戶在發布所述目標資料對象時提供。

此時，判斷單元702具體可以用於：根據所述第二用戶的信用信息，確定所述第二用戶的授信額度；如果所述授信額度大於所述預置金額，則確定所述第二用戶的信用信息滿足所述預置的業務條件。

與實施例二相對應，本案實施例還提供了一種訂單信息處理裝置，該裝置應用於第一用戶資料處理系統，參見圖8，該裝置具體可以包括：訂單接收單元801，用於接收伺服器提供的信用擔保訂單，所述信用擔保訂單藉由以下方式產生：所述伺服器在接收到客戶端針對目標資料對象創建擔保訂單的請求時，判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則創建訂單，標記為並添加信用擔保訂單標識符；狀態提交單元802，用於如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。

與實施例三相對應，本案實施例還提供了一種訂單信息處理裝置，該裝置應用於伺服器，參見圖9，該裝置具體可以包括：訂單信息記錄單元901，用於記錄業務訂單的相關信息，所述相關信息包括所述業務訂單關聯的第一用戶以及第二用戶信息，所述業務訂單為非擔保訂單；轉換請求接收單元902，用於接收將指定非擔保訂單轉換為擔保訂單的請求；信用判斷單元903，用於判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件；轉換單元904，用於如果所述信用判斷單元的判斷結果為滿足，則將所述指定非擔保訂單轉換為信用擔保訂單，並將轉換結果提供給第一用戶的資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

具體實現時，轉換請求接收單元902具體可以用於接收第一用戶的資料處理系統提交的將指定非擔保訂單轉換為擔保訂單的請求；此時，該裝置還可以包括：通知單元，用於在判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件之前，向所述指定非擔保訂單關聯的第二用戶客戶端發送通知消息；觸發單元，用於在接收到第二用戶客戶端返回的確認轉換的響應後，觸發執行所述判斷操作。

在另一種實現方式下，所述轉換請求接收單元902具體可以用於：接收第二用戶客戶端提交的將指定非擔保訂單轉換為擔保訂單的請求。

此時，該裝置還可以包括：轉換結果提供單元，用於將訂單轉換結果提供給第二用戶客戶端。

另外，該裝置還可以包括：訂單狀態信息接收單元，用於接收所述第一用戶的資料處理系統提供的訂單狀態信息；資源劃撥單元，用於如果所述訂單狀態為第二用戶未按時履約，則從所述第二用戶關聯的支付帳戶劃撥預置資源信息到所述第一用戶的收款帳戶。

與實施例四相對應，本案實施例還提供了一種訂單信息處理裝置，該裝置應用於第一用戶資料處理系統，參見圖10，該裝置具體可以包括：第一轉換請求提交單元1001，用於向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；第一轉換結果接收單元1002，用於接收伺服器返回的轉換結果，以便按照信用擔保的方式為所述第二用戶提供線下資源預留服務。

與實施例五相對應，本案實施例還提供了一種訂單信息處理裝置，該裝置應用於第二用戶客戶端，參見圖11，該裝置具體可以包括：第二轉換請求提交單元1101，用於向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；第二轉換結果接收單元1102，用於接收伺服器返回的轉換結果。

藉由本案實施例，對於信用度比較高的第二用戶，採用的是信任的態度，在其需要第一用戶為其提供預留線下資源的服務時，可以在不必支付保證金的情况下，即可享受相應的服務。這樣，在用戶未發生違約的情况下，就不會造成對用戶資金的額外占用，並且，由於不必將第二用戶的支付帳戶等信息提供給第一用戶，因此，也保證了第二用戶隱私信息的安全性。另外，由於不必執行第二用戶預先支付保證金、第一用戶再退還保證金等一系列的流程，因此，也大大節省了系統在網路、儲存等方面的資源。對於第二用戶而言，會感覺到自己在消費過程中被信任而獲得尊重，因此，也可以提升第二用戶的體驗。

藉由以上的實施方式的描述可知，本領域的技術人員可以清楚地瞭解到本案可借助軟體加必需的通用硬體平台的方式來實現。基於這樣的理解，本案的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該電腦軟體產品可以儲存在儲存媒體中，如ROM/RAM、磁碟、光碟等，包括若干指令用以使得一台電腦設備(可以是個人電腦，伺服器，或者網路設備等)執行本案各個實施例或者實施例的某些部分所述的方法。

本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統或系統實施例而言，由於其基本相似於方法實施例，所以描述得比較簡單，相關之處參見方法實施例的部分說明即可。以上所描述的系統及系統實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位於一個地方，或者也可以分布到多個網路單元上。可以根據實際的需要選擇其中的部分或者全部模塊來實現本實施例方案的目的。本領域普通技術人員在不付出創造性勞動的情况下，即可以理解並實施。

以上對本案所提供的訂單信息處理以及訂單類型轉換處理方法及裝置，進行了詳細介紹，本文中應用了具體個例對本案的原理及實施方式進行了闡述，以上實施例的說明只是用於幫助理解本案的方法及其核心思想；同時，對於本領域的一般技術人員，依據本案的思想，在具體實施方式及應用範圍上均會有改變之處。綜上所述，本說明書內容不應理解為對本案的限制。

Claims

一種訂單信息處理方法，其特徵在於，包括：伺服器接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；如果滿足，則創建訂單，並添加信用標識符，並將所述信用擔保訂單提供給所述第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。
根據申請專利範圍第1項所述的方法，其中，所述將所述信用擔保訂單提供給所述第一用戶資料處理系統，包括：經由預先獲知的所述第一用戶資料處理系統的介面，將所述信用擔保訂單提供給所述第一用戶資料處理系統。
根據申請專利範圍第1項所述的方法，其中，還包括：接收所述第一用戶資料處理系統提供的所述訂單的狀態信息；如果所述訂單狀態為第二用戶未按時履約，則從所述第二用戶關聯的支付帳戶劃撥預置資源信息到所述第一用戶的收款帳戶。
根據申請專利範圍第3項所述的方法，其中，所述預置資源信息由所述第一用戶在發布所述目標資料對象時提供。
根據申請專利範圍第4項所述的方法，其中，所述判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，包括：根據所述第二用戶的信用信息，確定所述第二用戶的授信額度；如果所述授信額度大於所述預置金額，則確定所述第二用戶的信用信息滿足所述預置的業務條件。
一種訂單信息處理方法，其特徵在於，包括：第一用戶資料處理系統接收伺服器提供的信用擔保訂單，所述信用擔保訂單藉由以下方式產生：所述伺服器在接收到客戶端針對目標資料對象創建擔保訂單的請求時，判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則創建訂單，並添加信用標識符；如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。
一種訂單類型轉換處理方法，其特徵在於，包括：伺服器記錄業務訂單的相關信息，所述相關信息包括所述業務訂單關聯的第一用戶以及第二用戶信息，所述業務訂單為非擔保訂單；接收將指定非擔保訂單轉換為擔保訂單的請求；判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件；如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單，並將轉換結果提供給第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。
根據申請專利範圍第7項所述的方法，其中，所述接收將指定非擔保訂單轉換為擔保訂單的請求，包括：接收第一用戶資料處理系統提交的將指定非擔保訂單轉換為擔保訂單的請求；所述判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件之前，還包括：向所述指定非擔保訂單關聯的第二用戶客戶端發送通知消息；在接收到第二用戶客戶端返回的確認轉換的響應後，觸發執行所述判斷操作。
根據申請專利範圍第7項所述的方法，其中，所述接收將指定非擔保訂單轉換為擔保訂單的請求，包括：接收第二用戶客戶端提交的將指定非擔保訂單轉換為擔保訂單的請求。
根據申請專利範圍第7項所述的方法，其中，還包括：將訂單轉換結果提供給第二用戶客戶端。
根據申請專利範圍第7項所述的方法，其中，還包括：接收所述第一用戶資料處理系統提供的訂單狀態信息；如果所述訂單狀態為第二用戶未按時履約，則從所述第二用戶關聯的支付帳戶劃撥預置資源信息到所述第一用戶的收款帳戶。
一種訂單類型轉換處理方法，其特徵在於，包括：第一用戶資料處理系統向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；接收伺服器返回的轉換結果，以便按照信用擔保的方式為所述第二用戶提供線下資源預留服務。
根據申請專利範圍第12項所述的方法，其中，還包括：如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。
一種訂單類型轉換處理方法，其特徵在於，包括：第二用戶客戶端向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；接收伺服器返回的轉換結果。
一種訂單信息處理裝置，其特徵在於，應用於伺服器，包括：請求接收單元，用於接收客戶端針對指定第一用戶的目標資料對象創建擔保訂單的請求；判斷單元，用於判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件；訂單創建單元，用於如果所述判斷單元的判斷結果為滿足，則創建訂單，並添加信用標識符，並將所述信用擔保訂單提供給所述第一用戶資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。
一種訂單信息處理裝置，其特徵在於，應用於第一用戶資料處理系統，包括：訂單接收單元，用於接收伺服器提供的信用擔保訂單，所述信用擔保訂單藉由以下方式產生：所述伺服器在接收到客戶端針對目標資料對象創建擔保訂單的請求時，判斷所述客戶端關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則創建訂單，標記為並添加信用擔保訂單標識符；狀態提交單元，用於如果第二用戶未能按時履約，則向所述伺服器提交訂單狀態信息，所述狀態信息為第二用戶未按時履約，以便伺服器從所述第二用戶關聯的支付帳戶劃撥預置金額到所述第一用戶的收款帳戶。
一種訂單類型轉換處理裝置，其特徵在於，應用於伺服器，包括：訂單信息記錄單元，用於記錄業務訂單的相關信息，所述相關信息包括所述業務訂單關聯的第一用戶以及第二用戶信息，所述業務訂單為非擔保訂單；轉換請求接收單元，用於接收將指定非擔保訂單轉換為擔保訂單的請求；信用判斷單元，用於判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件；轉換單元，用於如果所述信用判斷單元的判斷結果為滿足，則將所述指定非擔保訂單轉換為信用擔保訂單，並將轉換結果提供給第一用戶的資料處理系統，以便所述第一用戶按照信用擔保的方式為所述第二用戶提供線下資源預留服務。
一種訂單類型轉換處理裝置，其特徵在於，應用於第一用戶資料處理系統，包括：第一轉換請求提交單元，用於向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；第一轉換結果接收單元，用於接收伺服器返回的轉換結果，以便按照信用擔保的方式為所述第二用戶提供線下資源預留服務。
一種訂單類型轉換處理裝置，其特徵在於，應用於第二用戶客戶端，包括：第二轉換請求提交單元，用於向伺服器提交將指定非擔保訂單轉換為擔保訂單的請求，以便所述伺服器判斷所述指定非擔保訂單關聯的第二用戶的信用信息是否滿足預置的業務條件，如果滿足，則將所述指定非擔保訂單轉換為信用擔保訂單；第二轉換結果接收單元，用於接收伺服器返回的轉換結果。