專利名稱：Bpc硬件架構及bpc數(shù)據(jù)中心服務器的制作方法
技術領域：
本發(fā)明涉及互聯(lián)網(wǎng)技術領域，特別涉及一種BPC(Business-to-Platform-to-Cust omer,即商家_平臺，平臺-客戶)的硬件架構及BPC數(shù)據(jù)中心服務器。
背景技術：
電子商務指的是利用簡單、快捷、低成本的電子通訊方式，使得買賣雙方可以不見 面地進行各種商貿(mào)活動，電子商務可以通過多種電子通訊方式來完成。目前人們所探討的 電子商務主要是以INTERNET(互聯(lián)網(wǎng))實現(xiàn)為主，尤其是隨著INTERNET技術的日益成熟， 電子商務真正的發(fā)展將是建立在INTERNET技術上的。目前，電子商務可以分為企業(yè)(Business)對終端客戶(Customer)的電子商務 (B2C)和客戶對客戶的電子商務(C2C)等幾個主要模式。這些模式雖然各有自身的優(yōu)勢，但 也存在著共同的缺點，即不適合一些傳統(tǒng)行業(yè)，例如機票銷售行業(yè)等。例如，目前，機票銷售 沒有統(tǒng)一的平臺進行管理，客戶購買機票時都是通過各個票務公司或票務網(wǎng)站訂票，由于 各個票務公司或票務網(wǎng)站執(zhí)行的優(yōu)惠政策不同，因此對于客戶來說，往往不能享受到最優(yōu) 的優(yōu)惠政策，同樣客戶在購買機票時也要經(jīng)過長時間的查詢?nèi)ふ覂?yōu)惠的機票，這些都為 客戶帶來很大的麻煩。另外，由于個別票務公司或票務網(wǎng)站的誠信問題，還可能常常出現(xiàn)假 機票等情況，導致客戶在選擇票務公司或票務網(wǎng)站時變得更加謹慎，也進一步加劇了客戶 的負擔。同時，還有一個目前比較嚴重的問題就是，目前各個票務公司或票務網(wǎng)站的支付方 式都比較單一，這樣也為客戶的購買帶來了障礙。此外，客戶在票務公司或票務網(wǎng)站購買了 機票后，往往無法及時得知自己定購的機票及購買的保險信息。因此可以看出，對于機票銷 售等傳統(tǒng)的行業(yè)中的電子商務模式，還亟待改進以方便客戶及提高客戶的滿意度。

發(fā)明內(nèi)容
本發(fā)明的目的旨在至少解決上述技術缺陷之一，特別是解決對于機票銷售等傳統(tǒng) 的行業(yè)的電子商務中存在的問題。為達到上述目的，本發(fā)明一方面提出了一種BPC的硬件架構，包括多個B2P端，多 個P2C客戶端和通過互聯(lián)網(wǎng)與所述多個B2P端和多個P2C客戶端進行通信的BPC數(shù)據(jù)中心 服務器，其中，B2P端用于使商家通過所述B2P端與所述BPC數(shù)據(jù)中心服務器進行交互；BPC 數(shù)據(jù)中心服務器用于對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處理，并根據(jù)預設的選擇條件 選擇滿足條件的商家的產(chǎn)品提供給所述P2C客戶端；P2C客戶端用于根據(jù)客戶的選擇與所 述BPC數(shù)據(jù)中心服務器進行交互。在本發(fā)明的一個實施例中，BPC的硬件架構還可包括與所述BPC數(shù)據(jù)中心服務器 通過互聯(lián)網(wǎng)相連的保險公司的服務器、銀行的服務器、平臺的服務器或短信網(wǎng)關服務器。另 夕卜，在另一個實施例中，該BPC的硬件架構還可包括與所述BPC數(shù)據(jù)中心服務器相連的支 付服務器、短信接口服務器和保險服務器，使得所述BPC數(shù)據(jù)中心服務器在收到所述P2C客 戶端的訂單之后，通過短信接口服務器將訂單信息發(fā)送給客戶，并通過支付服務器引導客戶進行支付及提交保險，并在支付成功之后將支付成功信息、機票號及保險號發(fā)送給所述 客戶。其中，在上述實施例中，所述BPC數(shù)據(jù)中心服務器根據(jù)預設的選擇條件選擇滿足 條件的商家的產(chǎn)品提供給P2C客戶端可包括所述BPC數(shù)據(jù)中心服務器根據(jù)機票政策信息、 服務信息、商家信譽度、商家地址中的一條或多條進行選擇。在本發(fā)明的一個實施例中，BPC數(shù)據(jù)中心服務器可采用統(tǒng)一的TOBSERVICE方式將 各要素統(tǒng)一并提供給所述P2C客戶端。在本發(fā)明的一個實施例中，BPC數(shù)據(jù)中心服務器可采用智能緩存技術根據(jù)數(shù)據(jù)變 化頻率的不同智能調(diào)整緩存周期。本發(fā)明另一方面還提出了一種BPC數(shù)據(jù)中心服務器，包括交互模塊，用于與B2P 端和P2C客戶端進行交互；匯總處理模塊，用于對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處 理；選擇模塊，用于根據(jù)預設的選擇條件選擇滿足條件的商家的產(chǎn)品通過交互模塊提供給 所述P2C客戶端。其中，在該實施例中，所述選擇條件可包括機票政策信息、服務信息、商家 信譽度、商家地址等中的一條或多條。在本發(fā)明的一個實施例中，BPC數(shù)據(jù)中心服務器還包括與保險服務器相連的保 險接口、與支付服務器相連的銀行支付接口、和與短信接口服務器相連的短信接口。在本發(fā) 明的另一個實施例中，BPC數(shù)據(jù)中心服務器還包括短信偵聽發(fā)送模塊、銀行支付模塊和保險 提交模塊，所述BPC數(shù)據(jù)中心服務器在收到所述P2C客戶端的訂單之后，通過短信偵聽發(fā)送 模塊將訂單信息發(fā)送給客戶，并通過銀行支付模塊引導客戶進行支付及通過保險提交模塊 遞交保險，并在支付成功之后將支付成功信息、機票號及保險號通過短信偵聽發(fā)送模塊發(fā) 送給所述客戶。通過本發(fā)明提出的BPC架構，可以通過本發(fā)明的BPC數(shù)據(jù)中心服務器對各個商家 提供的商品信息，例如機票政策信息、商家服務信息等進行匯總和處理，并且根據(jù)預設的選 擇條件選擇更優(yōu)惠或更適合的商家產(chǎn)品提供給客戶，從而方便客戶進行選擇，提高客戶的 滿意度。本發(fā)明可將傳統(tǒng)電子商務所需要的各要素整合到本發(fā)明的BPC硬件架構中，從而 可快速地構建含渠道數(shù)據(jù)、銀行支付、短信通知為一體的電子商務解決方案，因此可以在客 戶定購機票后隨時用短信通知客戶支付信息、出票信息等。本發(fā)明附加的方面和優(yōu)點將在下面的描述中部分給出，部分將從下面的描述中變 得明顯，或通過本發(fā)明的實踐了解到。


本發(fā)明上述的和/或附加的方面和優(yōu)點從下面結合附圖對實施例的描述中將變得明顯和容易理解，其中圖1為本發(fā)明實施例的BPC硬件架構示意圖；圖2為本發(fā)明實施例BPC數(shù)據(jù)中心服務器100的結構圖。
具體實施例方式下面詳細描述本發(fā)明的實施例，所述實施例的示例在附圖中示出，其中自始至終 相同或類似的標號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附圖描述的實施例是示例性的，僅用于解釋本發(fā)明，而不能解釋為對本發(fā)明的限制。本發(fā)明主要在于創(chuàng)新地提出了新型電子商務架構，即BPC(商家到平臺、平臺到客 戶)的硬件架構，以解決傳統(tǒng)行業(yè)的電子商務問題，例如機票銷售行業(yè)，但是需要說明的 是，本發(fā)明雖然以機票銷售行業(yè)為例進行說明，但是本發(fā)明并不限于此行業(yè)，其他與機票銷 售類似的傳統(tǒng)行業(yè)也可采用本發(fā)明，同樣也應包含在本發(fā)明的保護范圍之內(nèi)。在本發(fā)明中，BPC數(shù)據(jù)中心服務器可對來自數(shù)千家(甚至更多)商家的產(chǎn)品進行匯總和處理，輸入BPC數(shù)據(jù)中心服務器的數(shù)據(jù)庫。以機票銷售為例，首先各個票務公司或票 務網(wǎng)站通過B2P端將機票信息以及政策數(shù)據(jù)(即機票的優(yōu)惠信息)等信息發(fā)送至BPC數(shù)據(jù) 中心服務器，BPC數(shù)據(jù)中心服務器將這些信息導入到數(shù)據(jù)庫中，之后BPC數(shù)據(jù)中心服務器可 根據(jù)預設的選擇條件從其中選出一些滿足條件的商家的產(chǎn)品提供給P2C客戶端，例如選擇 最優(yōu)惠的機票提供給P2C客戶端，或者選擇商家信譽度最好的商家提供給P2C客戶端。從 而通過本發(fā)明平臺的處理可以方便客戶進行選擇，提高客戶的滿意度。另外，通過此種方式 可以發(fā)展更多的B端，通過平臺的推廣得到更多的C端。具體地，如圖1所示，為本發(fā)明實施例的BPC硬件架構示意圖。在該BPC硬件架構 中包括多個B2P端200，多個P2C客戶端300和通過互聯(lián)網(wǎng)與B2P端200和P2C客戶端300 進行通信的BPC數(shù)據(jù)中心服務器100，該架構以BPC數(shù)據(jù)中心服務器100為核心，B2P端200 通過B2P軟件與BPC數(shù)據(jù)中心服務器100交互，P2C客戶端300通過P2C軟件與BPC數(shù)據(jù)中 心服務器100交互。BPC數(shù)據(jù)中心服務器100對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處理， 導入數(shù)據(jù)庫，并根據(jù)預設的選擇條件選擇滿足條件的商家的產(chǎn)品提供給P2C客戶端300。 其中，在本發(fā)明的一個實施例中預設的選擇條件可以包括機票政策信息、服務信息、商家信 譽度、商家地址等中的一條或多條。該預設的選擇條件可以有很多，本領域技術人員可以 增加或減少選擇條件，這些增加或減少的方式在不脫離本發(fā)明的發(fā)明思想的范圍內(nèi)均應包 含在本發(fā)明的保護范圍之內(nèi)。當然，作為優(yōu)選實施例，也可以將這些選擇條件提供給客戶， 這樣客戶在買機票時可根據(jù)自身的要求定制這些選擇條件，從而可以進一步提高用戶的滿 意度，例如有些客戶喜歡價格便宜的機票，但是有些客戶可能時間比較緊，需要馬上買到機 票，因此他可能就會選擇地點比較近的商家能夠買上送票。因此可以看出，根據(jù)本發(fā)明實施 例可以對選擇條件進行設定或隨時的調(diào)整，可以根據(jù)機票政策信息，即機票的優(yōu)惠幅度進 行選擇，選擇優(yōu)惠幅度最大的商家的產(chǎn)品提供給客戶，如果價格相同則選擇服務最好或者 商家信譽度最高的提供給客戶等?；蛘撸部梢约尤霑r間條件或位置條件，例如可以在白天 選擇優(yōu)惠幅度最大的商家提供給客戶，由于很少有商家會在夜晚出票，因此如果客戶訂票 的時間在夜間則為該客戶選擇服務最好的，將能夠夜晚出票服務的商家提供給客戶；或者， 加入商家的位置條件，在客戶訂票時，選擇距離客戶最近的商家提供給客戶。因此從以上描述可見，在本發(fā)明實施例中，選擇條件是可調(diào)整的，對于不同需求的 客戶會選擇不同的選擇條件，這樣客戶在購買機票時就可以節(jié)省大量尋找便宜或合適的機 票的時間，從而提高客戶的滿意度。另外，在本發(fā)明實施例中，通過BPC數(shù)據(jù)中心服務器100 的匯總，還可以自動刪除一些沒有資質(zhì)或者信譽度差的商家，從而能夠保證客戶通過該BPC 硬件架構不會購買到假機票。進一步優(yōu)選地，在本發(fā)明實施例中，該BPC的硬件架構還包括與BPC數(shù)據(jù)中心服務 器100通過互聯(lián)網(wǎng)相連的保險公司服務器410、銀行服務器420、平臺服務器430或短信網(wǎng)關服務器440，從而可以通過本發(fā)明的BPC的硬件架構實現(xiàn)用戶的直接支付、保險提交和短信通知等業(yè)務。需要說明的是，在本發(fā)明實施例中，BPC數(shù)據(jù)中心服務器100可以與全部保 險公司或銀行的服務器相連，也可以與全部的電信運營商的短信網(wǎng)關服務器相連從而為客 戶提供最多最全的支付方式及短信通知方式，當然也可以選擇其中的一些作為合作伙伴， 等等。具體地，該BPC的硬件架構還包括與BPC數(shù)據(jù)中心服務器100相連的短信接口服務 器510、支付服務器520和保險服務器530，使得BPC數(shù)據(jù)中心服務器100在收到P2C客戶端 300的訂單之后，可以通過短信接口服務器510將訂單信息發(fā)送給客戶，并通過支付服務器 520引導客戶進入支付頁面系統(tǒng)，并根據(jù)客戶所選擇的銀行進行網(wǎng)銀支付，以及通過保險服 務器530提交保險，在支付成功之后通過短信接口服務器510將支付成功的消息發(fā)送給客 戶并告知客戶已成功支付且正在出票，當商家出票成功后再次通過短信接口服務器510將 機票號及保險號等信息發(fā)送給客戶。在這個實施例中，客戶可以通過本發(fā)明的BPC的硬件 架構進行在線支付及保險的購買，并且可以為用戶提供多個銀行的支付及多個保險公司的 選擇，另外，在該實施例中，通過對用戶的短信提醒可以使用戶隨時得知目前機票定購的狀 況，進一步地提高用戶的滿意度。在本發(fā)明的另一個優(yōu)選實施例中，可以TOB SERVICE方式將數(shù)據(jù)以統(tǒng)一的BPC格 式供應給P2C客戶端，簡化接口開發(fā)難度，例如，如圖1所示，BPC數(shù)據(jù)中心服務器100通過 WEB SERVICE方式將數(shù)據(jù)提供給P2C客戶端網(wǎng)站服務器610和P2C客戶端手機服務器620。 BPC數(shù)據(jù)中心服務器100將所有不同的外部接口進行封裝，制定統(tǒng)一的TOB SERVICE接口 標準，從而簡化了客戶端開發(fā)，目前外部的各種接口參數(shù)定義多樣，規(guī)則多樣，分為XML型、 Jeson型及文本型，并沒有一個統(tǒng)一的標準，因此導致開發(fā)難度大。在本發(fā)明中，BPC數(shù)據(jù)中 心服務器100可將各接口數(shù)據(jù)提取到BPC數(shù)據(jù)中心服務器100再以統(tǒng)一的參數(shù)及格式標準 (分為XML與JESON兩種)提供給客戶端，這樣客戶端無需再針對各大銀行，各大平臺，各大 保險公司，各大短信運營商分別開發(fā)接口，當BPC數(shù)據(jù)中心服務器100增加接口時，客戶只 需要更改參數(shù)就可以對接。其次，在本發(fā)明的另一個實施例中，BPC數(shù)據(jù)中心服務器100可以采用智能緩存技 術，根據(jù)數(shù)據(jù)變化頻率的不同智能調(diào)整緩存周期，例如如果是變化頻率大的政策就把其緩 存時間設短一些，變化不大的就設長一些，從而可以有效地節(jié)約外部資源，提高效率。具體 地，政策數(shù)據(jù)緩存算法可分為普通政策緩存算法(例如周期可為5分鐘)、ETERM特價政策 緩存算法(例如周期可為1小時)和B2P特價緩存算法(例如周期可為1天)。本發(fā)明另一方面還提出了一種BPC數(shù)據(jù)中心服務器，如圖2所示，為本發(fā)明實施例 BPC數(shù)據(jù)中心服務器100的結構圖。該BPC數(shù)據(jù)中心服務器100包括交互模塊110、匯總處 理模塊120和選擇模塊130。交互模塊110用于與B2P端200和P2C客戶端300進行交互。 匯總處理模塊120用于對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處理。選擇模塊130用于根 據(jù)預設的選擇條件選擇滿足條件的商家的產(chǎn)品通過交互模塊提供給P2C客戶端300。其中， 上述選擇條件可包括機票政策信息、服務信息、商家信譽度、商家地址等中的一條或多條， 本領域技術人員也可對這些選擇條件進行擴展。在本發(fā)明的一個實施例中，BPC數(shù)據(jù)中心服務器100還包括政策同步模塊140和 政策狀態(tài)更新模塊150，政策同步模塊140用于與各個商家的機票政策信息進行同步，政策 狀態(tài)更新模塊150用于在機票政策信息發(fā)生變化時，及時更新所述BPC數(shù)據(jù)中心服務器保存的機票政策信息，從而保證BPC數(shù)據(jù)中心服務器100中存儲的數(shù)據(jù)的及時性，這需要通過 BPC數(shù)據(jù)中心服務器100與B2P端200之間的B2P軟件實現(xiàn)。在本發(fā)明的一個實施例中，BPC數(shù)據(jù)中心服務器100還包括與保險服務器530相 連的保險接口 160、與支付服務器520相連的銀行支付接口 170、和與短信接口服務器530 相連的短信接口 180。還可包括短信偵聽發(fā)送模塊190、銀行支付模塊210和保險提交模塊 220，其中，BPC數(shù)據(jù)中心服務器100在收到P2C客戶端300的訂單之后，通過短信偵聽發(fā)送 模塊190將訂單信息發(fā)送給客戶，并通過銀行支付模塊210引導客戶進行支付及通過保險 提交模塊220遞交保險，并在支付成功之后將支付成功信息、機票號及保險號通過短信偵 聽發(fā)送模塊1190發(fā)送給客戶。通過本發(fā)明提出的BPC架構，可以通過本發(fā)明的BPC數(shù)據(jù)中心服務器對各個商家 提供的商品信息，例如機票的政策信息、商家的服務信息等進行匯總和處理，并且根據(jù)預設 的選擇條件選擇更優(yōu)惠的商家產(chǎn)品提供給客戶，從而方便客戶進行選擇，提高客戶的滿意 度。本發(fā)明可將傳統(tǒng)電子商務所需要的各要素整合到本發(fā)明的BPC硬件架構中，從而可快 速地構建含渠道數(shù)據(jù)、銀行支付、短信通知為一體的電子商務解決方案，因此可以在客戶定 購機票后隨時用短信通知客戶支付信息、出票信息等。
盡管已經(jīng)示出和描述了本發(fā)明的實施例，對于本領域的普通技術人員而言，可以 理解在不脫離本發(fā)明的原理和精神的情況下可以對這些實施例進行多種變化、修改、替換 和變型，本發(fā)明的范圍由所附權利要求及其等同限定。
權利要求
一種商家-平臺-客戶BPC的硬件架構，其特征在于，包括多個商家-平臺B2P端，多個平臺-客戶P2C客戶端和通過互聯(lián)網(wǎng)與所述多個B2P端和多個P2C客戶端進行通信的BPC數(shù)據(jù)中心服務器，所述B2P端，用于使商家通過所述B2P端與所述BPC數(shù)據(jù)中心服務器進行交互；所述BPC數(shù)據(jù)中心服務器，用于對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處理，并根據(jù)預設的選擇條件選擇滿足條件的商家的產(chǎn)品提供給所述P2C客戶端；所述P2C客戶端，用于根據(jù)客戶的選擇與所述BPC數(shù)據(jù)中心服務器進行交互。
2.如權利要求1所述的BPC的硬件架構，其特征在于，還包括與所述BPC數(shù)據(jù)中心服 務器通過互聯(lián)網(wǎng)相連的保險公司服務器、銀行服務器、平臺服務器或短信網(wǎng)關服務器。
3.如權利要求2所述的BPC的硬件架構，其特征在于，還包括與所述BPC數(shù)據(jù)中心服 務器相連的支付服務器、短信接口服務器和保險服務器，使得所述BPC數(shù)據(jù)中心服務器在 收到所述P2C客戶端的訂單之后，通過短信接口服務器將訂單信息發(fā)送給客戶，并通過支 付服務器引導客戶進行支付及通過保險服務器提交保險，并在支付成功之后將支付成功信 息、機票號及保險號發(fā)送給所述客戶。
4.如權利要求1所述的BPC的硬件架構，其特征在于，所述BPC數(shù)據(jù)中心服務器根據(jù)預 設的選擇條件選擇滿足條件的商家的產(chǎn)品提供給P2C客戶端包括所述BPC數(shù)據(jù)中心服務器根據(jù)機票政策信息、服務信息、商家信譽度、商家地址中的一 條或多條進行選擇。
5.如權利要求1所述的BPC的硬件架構，其特征在于，所述BPC數(shù)據(jù)中心服務器采用統(tǒng) 一的TOB SERVICE方式將各要素統(tǒng)一并提供給所述P2C客戶端。
6.如權利要求1所述的BPC的硬件架構，其特征在于，所述BPC數(shù)據(jù)中心服務器采用智 能緩存技術根據(jù)數(shù)據(jù)變化頻率的不同智能調(diào)整緩存周期。
7.—種BPC數(shù)據(jù)中心服務器，其特征在于，包括交互模塊，用于與B2P端和P2C客戶端進行交互；匯總處理模塊，用于對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處理；選擇模塊，用于根據(jù)預設的選擇條件選擇滿足條件的商家的產(chǎn)品通過交互模塊提供給 所述P2C客戶端。
8.如權利要求7所述的BPC數(shù)據(jù)中心服務器，其特征在于，所述選擇條件包括機票政策 信息、服務信息、商家信譽度、商家地址中的一條或多條。
9.如權利要求8所述的BPC數(shù)據(jù)中心服務器，其特征在于，還包括政策同步模塊，用于與各個商家的機票政策信息進行同步；政策狀態(tài)更新模塊，用于在機票政策信息發(fā)生變化時，及時更新所述BPC數(shù)據(jù)中心服 務器中所保存的機票政策信息。
10.如權利要求9所述的BPC數(shù)據(jù)中心服務器，其特征在于，還包括與保險服務器相 連的保險接口、與支付服務器相連的銀行支付接口、和與短信接口服務器相連的短信接口。
11.如權利要求10所述的BPC數(shù)據(jù)中心服務器，其特征在于，還包括短信偵聽發(fā)送模 塊、銀行支付模塊和保險提交模塊，所述BPC數(shù)據(jù)中心服務器在收到所述P2C客戶端的訂單 之后，通過短信偵聽發(fā)送模塊將訂單信息發(fā)送給客戶，并通過銀行支付模塊引導客戶進行 支付及通過保險提交模塊遞交保險，并在支付成功之后將支付成功信息、機票號及保險號通過短信偵聽發(fā)送模塊發(fā)送給所述客戶。
全文摘要
本發(fā)明提出一種BPC的硬件架構，包括多個B2P端，多個P2C客戶端和通過互聯(lián)網(wǎng)與所述多個B2P端和多個P2C客戶端進行通信的BPC數(shù)據(jù)中心服務器，BPC數(shù)據(jù)中心服務器用于對多個商家提供的產(chǎn)品數(shù)據(jù)進行匯總和處理，并根據(jù)預設的選擇條件選擇滿足條件的商家的產(chǎn)品提供給所述P2C客戶端。通過本發(fā)明提出的BPC架構，可以通過本發(fā)明的BPC數(shù)據(jù)中心服務器對各個商家提供的商品信息，例如機票政策信息、商家服務信息等進行匯總和處理，并且根據(jù)預設的選擇條件選擇更優(yōu)惠或者更適合的商家產(chǎn)品提供給客戶，從而方便客戶進行選擇，提高客戶的滿意度。
文檔編號G06Q30/00GK101833726SQ20101014974
公開日2010年9月15日 申請日期2010年4月19日 優(yōu)先權日2010年4月19日
發(fā)明者黃雷 申請人:昆山科大宏威軟件科技有限公司;黃雷