TWI462042B - Network security and how to deal with the server - Google Patents

Description

網路聯保的處理方法和伺服器

本發明涉及電子商務領域，尤其涉及一種網路聯保的處理方法和系統。

中小企業發展遇到的最大瓶頸之一，就是資金缺乏，向銀行貸款時找不到擔保企業。網路聯保是基於網際網路電子商務應用的一種全新的融資-風控業務模式，全面解決中小企業的貸款擔保問題。網路聯保旨在基於企業間對網際網路電子商務的應用，發起和締結聯合擔保的貸款合約並路建立聯合擔保群體，建立擔保群的企業之間彼此結合網際網路電子商務和線下商務進行風險管控，同時聯保群成員接受銀行和電子商務平臺的風險監督和控制，並在網際網路上直接體現聯保動態，對貸款的進行全程控制。

傳統的聯保方式是指三個或三個以上的中小企業自願組成一個擔保聯合體(即聯保群)，通過企業內部的溝通和協調，一起向銀行申請貸款，當聯保群中的某一成員向銀行申請辦理指定的信用業務時，聯保群其餘全部成員為該申請人的銀行的信用業務提供連帶責任擔保，貸款申請人還需要承擔個人無限責任。傳統的聯保群的發起和組成方式完全基於線下。傳統聯保方式的風控機制為：(1)聯保群與銀行直接聯繫，沒有其他任何機構介入；(2)依賴信貸人員上門拜訪，進行監督。目前企業貸款情況已經實現銀行內的資訊互通，各家銀行通過貸款卡進行查詢企業的貸款記錄，傳統聯保方式的企業借貸信用記錄只在銀行內部互通，並未用於其他。

傳統的聯保方式存在以下不足之處：

(1)組成方式單一：傳統的聯保模式完全基於線下，且比較侷限於地域，基本依賴銀行在企業之前進行撮合，大大降低了組群的成功率和成功總量。

(2)監督機制不完整：監督機制單一，僅依靠銀行實地調查的監督，風險控制機制並不完整。

(3)借貸記錄的應用僅限於銀行之間，該記錄對於該企業信用情況的建立卻沒有起到作用。

本發明要解決的問題是提供一種網路聯保的處理方法和系統，使得用戶可以選擇多種方式進行線上聯保組群，並建立成套監督系統，在企業申請貸款以及使用貸款的過程中，對其在網路上的行為進行監督預警。

本發明提供一種網路聯保的處理方法，包括以下步驟：

伺服器接收到用戶發送的申請業務的資訊後，提供不同的聯保組群方式給該用戶選擇；

該伺服器根據該用戶的選擇創建具有唯一編號的聯保群；

該伺服器把該聯保群的資訊組成資料包並發送給銀行系統。

該伺服器接收到用戶發送的申請業務的資訊後，提供不同的聯保組群方式給該用戶選擇之前還包括：

該伺服器判斷該用戶是否符合申請業務的條件，如果符合，則該伺服器提供不同的聯保組群方式給該用戶選擇，否則，該伺服器將該用戶申請業務的資訊儲存在資料庫中。

該伺服器把該聯保群資訊組成資料包並發送給銀行系統之後還包括：

該伺服器接收銀行系統回饋的該用戶申請的業務是否成功的資訊，並通知該用戶。

該伺服器根據該用戶的選擇創建具有唯一編號的聯保群具體為：

該伺服器根據該用戶的選擇生成唯一的聯保群編號，並將該聯保群資訊與該用戶的會員資訊綁定，根據該用戶的會員資訊判斷該用戶是否符合組群條件，如果符合組群條件，則創建聯保群。

該聯保組群的方式具體為：自動匹配、兄弟會、線上發起/加入、或以上聯保組群方式的任意一種或幾種的組合。

該自動匹配的聯保組群方式具體為：

該用戶在填寫申請業務的資訊後，該伺服器根據該用戶事先設置的標準，自動為該用戶推薦與該申請業務資訊相關的其他用戶，提供彼此的資料資料，建議用戶間組成聯保群。

該兄弟會的聯保組群方式具體為：

若干用戶相約發起聯保組群，由兄弟會中的某一用戶創建聯保群，並添加該兄弟會中的其他用戶共同申請業務。

該線上發起/加入的聯保組群方式具體為：

有業務需求的用戶，將組群需求發佈在該伺服器上，標明自我條件和組群條件，等待或添加符合條件的用戶加入組群。

本發明還提供一種伺服器，包括：

處理模組，用於接收用戶發送的申請業務的資訊，並提供不同的聯保組群方式給該用戶選擇，並將該用戶的選擇發送給組群模組；

組群模組，用於根據該用戶的選擇創建具有唯一編號的聯保群，並將該聯保群的資訊發送給發送模組；

發送模組，用於接收該組群模組發送的該聯保群的資訊，將該聯保群的資訊組成資料包並發送。

還包括：

判斷模組，用於接收該用戶申請業務的資訊，判斷該用戶是否符合申請業務的條件，如果符合，則把該用戶的申請業務的資訊發送給該處理模組，否則把該用戶的申請業務的資訊發送給儲存模組；

儲存模組，用於當該用戶不符合申請業務的條件時，儲存該用戶的申請業務的資訊。

還包括：

接收模組，用於接收該用戶申請的業務是否成功的資訊，並發送給通知模組；

通知模組，用於將該用戶申請的業務是否成功的資訊發送給該用戶。

與現有技術相比，本發明具有以下優點：

通過使用本發明提供的方法，能夠提升聯保組群的成功率，解決地域的侷限性，通過網際網路讓各個不同地區的企業實現組群的可能性，建立整套網路預警機制，實現非人工的貸中風險控制，完善了企業的信用體系。

下面結合附圖和實施例，對本發明的具體實施方式作進一步詳細描述：

本發明的實施例一中，一種網路聯保的處理方法如圖1所示，具體步驟如下：

步驟S101：用戶通過網路登錄伺服器，向伺服器發送申請業務的資訊。

步驟S102：伺服器接收到用戶申請業務的資訊後，判斷用戶是否符合申請業務的條件，如果符合，轉步驟S103，否則，伺服器將用戶的資訊保存在資料庫中。

步驟S103：伺服器提供不同的聯保組群方式給用戶選擇。

聯保組群方式具體為自動匹配、兄弟會、線上發起/加入、或以上聯保組群方式的任意一種或幾種的組合。

步驟S104：伺服器根據用戶的選擇創建具有唯一編號的聯保群。

步驟S105：組群成功後，伺服器把聯保群資訊組成資料包保存在資料庫中並通過網際網路發送給銀行系統。

步驟S106：伺服器接收銀行系統回饋的用戶業務申請是否成功的資訊，並通知用戶。

以下各實施例中以企業用戶通過伺服器向銀行系統申請貸款業務為例，對本發明進行詳細描述。

本發明的實施例二中，以自動匹配方式為例，一種網路聯保的處理方法如圖2所示，具體步驟如下：

步驟S201：企業用戶通過網際網路登錄伺服器。

步驟S202：伺服器判斷企業用戶是否符合基本准入條件，如果符合基本准入條件，轉步驟S203，否則拒絕企業用戶登錄。

具體的，伺服器在企業用戶登錄時，通過查詢資料庫(DBA)中該企業用戶的info(資訊)判斷該企業用戶是否符合基本准入條件，其中基本准入條件包括企業用戶的登錄地域、身份、行業以及企業規模等，此基本准入條件可以根據不同的情況由伺服器及時調整。

步驟S203：企業用戶登錄成功後，伺服器通過查詢資料庫中企業用戶的資訊判斷企業用戶是否為誠信通會員(誠信通會員是阿裏巴巴網站的付費會員，成為誠信通會員需要經過特別的身份認證)，如果企業用戶為誠信通會員，轉步驟S204，否則結束整個申請過程。

步驟S204：伺服器對企業用戶提供申請貸款的報名表格，並將企業用戶填寫的申請貸款的資訊保存在資料庫中。

具體的，伺服器在企業用戶填寫表格時，自動調用資料庫中該企業用戶的member info(會員資訊)，該member info資訊為伺服器設定，企業用戶不可更改；當企業用戶提交報名表後，伺服器將企業用戶填寫的申請貸款的資訊保存在資料庫中，在資料庫中生成唯一的報名表流水號並與該企業用戶的member info綁定。

步驟S205：伺服器根據企業用戶申請貸款的資訊，判斷該企業用戶是否符合申請貸款的條件，如果符合，轉步驟S206；否則伺服器將企業用戶的資料資訊保存在資料庫中，以便該企業會員在符合申請貸款的條件後重新使用。

具體的，企業用戶申請貸款必須滿足以下三個條件：(1)企業用戶必須為誠信通會員；(2)企業用戶工商註冊的年限最低為18個月；(3)企業用戶無被投訴記錄，企業用戶如果處於詐騙處理中的狀態，不可申請(一旦確定為詐騙，則註銷其ID)；企業用戶在最近6個月中糾紛次數高於兩次(包括兩次)，不可申請。

當伺服器判斷出企業用戶為誠信通會員時，對企業用戶提供申請貸款的報名表格，根據企業用戶填寫的申請貸款的資訊判斷企業用戶是否符合上述另外兩個申請貸款的條件，如果符合，則報名成功，否則企業用戶報名失敗，伺服器將企業用戶的資料資訊保存在資料庫中，以便該企業會員在符合申請貸款的條件後重新使用。

步驟S206：伺服器讀取資料庫中保存的企業用戶的申請貸款的資訊，並顯示在網站上。

具體的，伺服器建立分類顯示列表，讀取資料庫中保存的企業用戶申請貸款的資訊(如企業用戶所在區域、行號、企業規模等)並在網站上對應顯示。企業用戶或其他會員可以通過關鍵字搜索對企業用戶申請貸款的資訊進行查詢，關鍵字搜索包括模糊查詢和精確查詢兩類，企業用戶或其他會員在進行分類查詢時，伺服器可以讀取資料庫中保存的報名表的資訊和member info中的部分資訊，當需要詳細資訊時，伺服器可以將企業用戶申請貸款的資訊以Detailed(詳細)的形式綁定顯示在網站上。

企業用戶報名成功後，銀行和其他會員可以在網站上看到的企業用戶的內容項如下表所示：

步驟S207：企業用戶選擇自動匹配的方式創建聯保群，並在組群成功後，向伺服器提交聯保群的資訊。

自動匹配的聯保組群方式是指企業用戶在填寫申請貸款資訊後，伺服器根據企業用戶事先設置的標準，自動為企業用戶推薦其他條件類似的申貸企業，提供彼此的資料資料，建議企業間組成聯保群。

具體的，企業用戶報名成功後，伺服器判斷企業用戶是否選擇了自動匹配的聯保組群方式，如果企業用戶選擇了自動匹配的聯保組群方式，則伺服器判斷企業用戶是否符合創建聯保群的條件，該創建聯保群的條件與企業用戶登錄的基本准入條件相同，但是等級不同，且此條件可以根據不同的情況由伺服器及時調整。如果企業用戶符合創建聯保群的條件，伺服器為企業用戶創建聯保群，並根據企業用戶的條件和實際情況，在資料庫中搜索符合企業用戶匹配條件的其他企業用戶的資訊，推薦類似條件的企業，建議彼此之間組成聯保群，伺服器每次向企業用戶推薦，都會通過即時通知實體通知相關的企業用戶；如果企業用戶選擇未選擇自動匹配的聯保組群方式，則伺服器進行其他聯保組群方式。

伺服器可以提供多個符合企業用戶設置的聯保群供企業用戶選擇，例如：在某一個區域內的、同行的、企業規模相近的、貸款需求相似的企業用戶等；如果伺服器未能搜索到符合條件的企業用戶，將會向用戶發送提示消息，提示企業用戶修改申貸需求或請其等待。企業用戶選擇伺服器提供的聯保群中的任意一個，申請組群。

伺服器為企業用戶創建的聯保群具有唯一的聯保群編號，並將該企業用戶的member info與聯保群資訊綁定。創建聯保群後，企業用戶可以通過條件查詢添加會員，邀請其他企業用戶加入到聯保圈中，企業用戶添加會員的同時，伺服器在資料庫查詢該會員資訊判斷是否符合貸款條件。

組群過程中，聯保群內的企業用戶可以添加其他會員，添加其他會員時，需要現有群內所有成員審批通過，如有成員不同意，則不添加該會員。在創建聯保群的企業用戶提交聯保群資訊前，其他企業用戶均可隨時退出。此時，資料庫中保存的企業用戶的info記錄包括：是否為聯保群的創建人、會員ID、報名表流水號、聯保群編號、聯保群的狀態(例如是否為組群中狀態，如果為組群中狀態，其他會員可以退出，否則狀態資訊不可修改並且企業會員不可退出聯保群)。

步驟S201～S207通常被稱為組群流程。

步驟S208：伺服器接收企業用戶提交的聯保群資訊，並進行審核。

具體的，聯保群判斷群內成員是否符合創建聯保群的條件，聯保群的創建條件具體為：群內企業會員的身份、數量、相關行業、企業間的關係以及企業相關資質。此創建條件可以由伺服器及時調整。如果符合組群條件，伺服器判斷聯保群中的所有企業用戶是否兩兩相互認同且同意風險共存，如果是，則組群成功，轉步驟S209；如果聯保群中有一個以上企業用戶(包含一個)提出異議，則組群失敗，伺服器需要重新匹配或者選擇其他方式組群。伺服器將以上判斷結果在第一時間內以站內信、郵件、短信、頁面等方式通知創建聯保群的企業用戶。

組群失敗的原因包括：聯保群中有任一企業用戶不認同，則組群失敗，伺服器刪除該聯保群；或者聯保群中有任一企業用戶被踢出，則組群失敗，其他企業用戶繼續組群，如果有企業用戶被其原所在准聯保群成員投票決定踢出群體，伺服器將為被踢出的企業用戶匹配相似條件的准聯保群和申貸企業，建議其組成聯保群；或者認同的企業用戶新建一個聯保群，把不認同的企業用戶留在原聯保群。在等待創建聯保群的階段，每一個准聯保群和申貸企業在組群時間過長時，伺服器將主動向企業用戶發送推薦資訊，推薦其他企業或其他群體，建議組成聯保群。

伺服器還提供自動回應的功能，即企業用戶或准聯保群如果對當前匹配結果不滿或其他任何情況，都可以申請自動匹配類似條件的准聯保群或申貸企業，伺服器按照匹配請求向企業用戶發送回應消息，消息中攜帶自動推薦的所需結果。

伺服器還提供優質推薦的功能，即伺服器將根據企業獲貸履約情況對曾經獲貸的企業進行評級，並根據評級結果優先推薦已經退出聯保群但是還有新的申貸需求的企業用戶給其他企業用戶。

步驟S208通常被稱為認同流程。

步驟S209：審核通過後，伺服器將聯保群資訊組成資料包，並通過網路發送給銀行系統。

伺服器與銀行系統之間的介面部分有發送和接收資訊的功能，每條發送的資訊或狀態回饋時均有系統回應，在回饋時間段內如未得到對方系統回應，則自動重發該資訊，並且通過介面調取相應編號資訊的狀態自行同步。

步驟S210：銀行系統根據伺服器發送的企業用戶申請貸款的資訊，對企業用戶進行審核，判斷企業用戶是否符合貸款條件，如果符合貸款條件，轉步驟S211，否則貸款失敗。銀行系統將企業用戶獲貸與否的審核結果發送給伺服器，伺服器接收到審核結果後通知企業會員，該通知的形式包括郵件、短信等。如果企業獲得貸款，伺服器提示企業用戶是否選擇某些內容在網站上公開，如果企業用戶選擇公開其審核內容，伺服器對企業用戶的誠信通指數加分。

步驟S212：銀行系統向符合貸款條件的企業用戶發送通知消息，並發放貸款。

通過審核的企業用戶將會獲得銀行的貸款，且獲得伺服器的誠信通指數的加分。

步驟S213：伺服器和銀行系統通過系統之間的介面交互資訊，完成企業用戶貸款的風險控制。

具體的，伺服器和銀行系統在整個申請貸款的每一階段都有交互資訊的過程，如圖3所示，具體步驟如下：

步驟S301：企業用戶通過網際網路登錄伺服器，提交申請貸款的資訊。

步驟S302：伺服器接收企業用戶提交的申請貸款的資訊，進行初步審核，審核該企業用戶是否符合申請貸款的條件，轉步驟S303；如果未通過審核，則通知企業用戶。

步驟S303：伺服器將通過審核的企業用戶的資訊提交給銀行系統。

步驟S304：銀行系統接收到伺服器發送的企業用戶的申請貸款資訊後，審核該企業用戶是否符合申請貸款的條件，如果符合，轉步驟S305；對於未通過審核的企業用戶的資訊也發送給伺服器，通知企業用戶以及伺服器。

步驟S305：銀行系統將通過審核的企業用戶的資訊發送給伺服器，要求企業用戶在網上簽訂合同，對企業用戶進行授信。

步驟S306：企業用戶通過銀行系統進行還貸，銀行系統將企業用戶的還貸資訊發送給伺服器，伺服器根據企業用戶的還貸情況，對企業用戶的誠信通指數加分或減分。

伺服器通過和銀行系統交互資訊獲得企業用戶的信用記錄，具體包括企業用戶的貸款申請、貸款審核、貸款支用，以及貸款歸還等狀況的資訊，對獲得貸款且按時還清貸款的企業用戶的誠信通指數加分，如果伺服器判定企業用戶未按時還清貸款，則對企業用戶的誠信通指數減分，並啟動止損和風險控制機制。

自企業用戶申請貸款開始，伺服器便對企業用戶採取風險控制機制，具體包括對企業用戶的貸款申請、貸款支用等情況進行監督，風險控制的流程如圖4所示，包括以下步驟：

步驟S401：伺服器接收企業用戶提交的貸款申請。

步驟S402：伺服器從伺服器中提取該企業用戶的歷史記錄，判斷其是否有欺詐等不良記錄，如果無不良記錄，伺服器將企業用戶的資訊提交給銀行系統；如果企業用戶有不良記錄，則不符合報名條件，伺服器保存其資料資訊，以便該企業會員在符合要求後重新使用。

步驟S403：企業用戶貸款成功後，伺服器監控企業用戶的狀況。

步驟S404：伺服器判斷出企業用戶的狀況出現異常，則進行預警。

具體的，該企業用戶的狀況具體為：企業用戶日常操作行為、企業用戶貸款業務相關操作、會員間相互評價、相關的交易評價及投訴資訊、貸款業務流程狀態、誠信通服務期限狀態以及伺服器及銀行系統相關的線下資料導入。如果上述任意一項出現超過貸款前的平均情況或者出現異常，伺服器則進行預警處理。

本發明的實施例三中，以兄弟會的聯保方式為例，一種網路聯保的處理方法如圖5所示，具體步驟如下：

步驟S501～步驟S506為組群流程，與實施例二中步驟S201～步驟S202中描述的組群流程一致，在此不再贅述。

步驟S507：企業用戶選擇兄弟會(即相熟企業)的方式創建聯保群，並在組群成功後，向伺服器提交聯保群的資訊。

兄弟會的聯保組群方式是指若干原本熟悉的企業，相約發起聯保組群，其中由兄弟會中的某一企業用戶先完成申貸表格，建立聯保群，然後添加兄弟會中的其他企業用戶，並開始申請貸款，該聯保群是一個私密的、不公開的群。

具體的，企業用戶報名成功後，伺服器判斷企業用戶是否選擇兄弟會的聯保組群方式，如果企業用戶選擇了兄弟會的聯保組群方式，則伺服器判斷企業用戶是否符合創建聯保群的條件，該創建聯保群的條件與企業用戶登錄的基本准入條件相同，但是等級不同，且此條件可以由伺服器及時調整。如果企業用戶符合創建聯保群的條件，伺服器為企業用戶創建聯保群，該聯保群具有唯一的編號，組群的企業用戶被稱為管理員，管理員組群後，添加其他兄弟會中的企業用戶加入該聯保群；如果企業用戶未選擇兄弟會的聯保組群方式，則伺服器進行其他聯保組群方式。

伺服器為企業用戶創建的聯保群具有唯一的聯保群編號，並將該企業用戶的member info與聯保群資訊綁定。創建聯保群後，企業用戶可以通過條件查詢添加會員，添加其他企業用戶加入到聯保圈中，企業用戶添加會員的同時，伺服器在資料庫查詢該會員資訊判斷是否符合貸款條件。

組群過程中，聯保群內的企業用戶可以添加其他會員，任何會員加入時，需要現有群內所有成員審批通過，如有成員不同意，則會員不得加入聯保群內。在創建聯保群的企業用戶提交聯保群資訊前，其他企業用戶均可隨時退出。此時，資料庫中保存的企業用戶的info記錄包括：是否為聯保群的創建人、會員ID、報名表流水號、聯保群編號、聯保群的狀態(如是否為組群中狀態，如果為組群中狀態，會員可以退出，否則狀態資訊不可修改並且會員不可退出聯保群)。

步驟S501～S507通常被稱為組群流程。

步驟S508：伺服器接收企業用戶提交的聯保群資訊，並進行審核。

具體的，聯保群判斷群內成員是否符合創建聯保群的條件，聯保群的創建條件具體為：群內企業會員的身份、數量、相關行業、企業間的關係以及企業相關資質。此創建條件可以由伺服器及時調整。如果符合組群條件，伺服器判斷聯保群中的所有企業用戶是否兩兩相互認同且同意風險共存，如果是，則組群成功，轉步驟S509；如果聯保群中有一個以上企業用戶(包含一個)提出異議，則組群失敗，伺服器需要重新匹配或者選擇其他方式組群。伺服器將以上判斷結果在第一時間內以站內信、郵件、短信、頁面等方式通知創建聯保群的企業用戶。

如果聯保群中的所有企業用戶兩兩互相認同，則組群成功，組群成功的企業用戶不能參加其他群的創建；如果聯保群中有一個以上(包含一個)的企業用戶提出異議，則組群失敗，可以由聯保群的管理員決定是否需要刪除該企業用戶的資格，然後添加其他符合條件的企業用戶，直至群內所有企業用戶兩兩互相認同。

步驟S509～S512與實施例二中步驟S209～S212所做操作一致，在此不再贅述。

本發明的實施例四中，以線上發起/加入為例，一種網路聯保的處理方法如圖6所示，具體步驟如下：

步驟S601～步驟S606為組群流程，與實施例二中步驟S201～步驟S202中描述的組群流程一致，在此不再贅述。

步驟S607：企業用戶選擇線上發起/加入的方式創建聯保群，並在組群成功後，向伺服器提交聯保群的資訊。

線上發起/加入的聯保方式是指有貸款需求又無法立即通過其他方式創建聯保群的企業用戶，可以將自己的組群需求發佈在伺服器上，標明自我條件和組群條件，等待或邀請符合條件的企業用戶加盟組群。其他企業用戶無論是否發佈組群資訊(只要是沒有加入其他聯保圈並且簽訂聯保協定的)都可以申請加入別的准聯保群。自動匹配失敗並且無兄弟企業可組成聯保群的企業，可以選擇該種方式。

步驟S601～S607通常被稱為組群流程。

步驟S608：伺服器接收企業用戶提交的聯保群資訊，並進行審核。

具體的，聯保群判斷群內成員是否符合創建聯保群的條件，聯保群的創建條件具體為：群內企業會員的身份、數量、相關行業、企業間的關係以及企業相關資質。此創建條件可以由伺服器及時調整。如果符合組群條件，伺服器判斷聯保群中的所有企業用戶是否兩兩相互認同且同意風險共存，如果是，則組群成功，轉步驟S609；如果聯保群中有一個以上企業用戶(包含一個)提出異議，則組群失敗，伺服器需要重新匹配或者選擇其他方式組群。伺服器將以上判斷結果在第一時間內以站內信、郵件、短信、頁面等方式通知創建聯保群的企業用戶。

如果聯保群中的企業用戶兩兩互相認同，則組群成功，組群成功的企業用戶不能參加其他群的創建；如果聯保群中有一個以上(包含一個)提出異議，則組群失敗，可以由群中的管理員(即組群企業)決定是否需要刪除某家企業用戶的資格，然後添加其他符合條件的企業用戶，直至群內所有企業用戶兩兩互相認同。

步驟S609～S612與實施例二中步驟S209～S212所做操作一致，在此不再贅述。

以上實施例中以自動匹配、兄弟會和線上發起/加入為例，對本發明的進行描述，除了以上方法外，本發明還可以採取其他方法實現，具體為：

(1)自動匹配加線上發起的聯保組群方式。

企業用戶填寫完申請貸款的資訊後，伺服器提供不同的聯保組群方式供企業用戶選擇，如果企業選擇自動匹配加線上發起的聯保組群方式，則伺服器在發佈該企業用戶的申請貸款的資訊後，按照該企業用戶的設置，搜索與該企業用戶條件類似的已經上線的其他企業用戶和/或沒有上線的其他企業用戶，按照不同類別和性質分別自動匹配建立聯保群。

(2)自動匹配加線上加入的聯保組群方式。

對於不願意發佈申請貸款的資訊且組織發起聯保群的企業用戶，伺服器自動幫助其匹配線上線下的貸款需求類似的其他企業用戶，按照不同類別和性質分別自動匹配建立聯保群。

(3)自動匹配加臨時出缺的聯保組群方式。

當某個准聯保群由於意見不合導致有企業用戶被剔除時，伺服器將自動根據經過修改後的准聯保群的條件，向該聯保群推薦符合要求的其他企業用戶。

(5)自動匹配加被剔除出群的聯保組群方式。

當某個准聯保群由於意見不合導致有企業用戶被剔除時，伺服器將自動向該企業用戶推薦的其他聯保群或企業用戶。

通過上述實施例提供的方法，能夠提升聯保群組成的成功率，解決地域的侷限性，通過網際網路讓各個不同地區的企業實現組群的可能性，建立整套網路預警機制，實現非人工的貸中風險控制，完善了企業的信用體系。

本發明的實施例五中提供一種伺服器，如圖7所示，包括：

處理模組11，用於接收用戶發送的申請業務的資訊，並提供不同的聯保組群方式給用戶選擇，並將用戶的選擇發送給組群模組12。聯保組群方式具體為自動匹配、兄弟會、線上發起/加入、或以上聯保組群方式的任意一種或幾種的組合。組群模組12，用於根據用戶的選擇創建具有唯一編號的聯保群，並將聯保群的資訊發送給發送模組13。發送模組13，用於接收組群模組12發送的聯保群的資訊，將聯保群的資訊組成資料包並發送。

還包括：判斷模組14，用於接收用戶申請業務的資訊，判斷用戶是否符合申請業務的條件，如果符合，則把用戶的申請業務的資訊發送給處理模組11，否則把用戶的申請業務的資訊發送給儲存模組15。儲存模組15，用於當用戶不符合申請業務的條件時，儲存用戶的申請業務的資訊。

還包括：接收模組16，用於接收用戶申請的業務是否成功的資訊，並發送給通知模組17。通知模組17，用於將用戶申請的業務是否成功的資訊發送給用戶。

通過上述實施例提供的系統，能夠提升聯保群組成的成功率，解決地域的侷限性，通過網際網路讓各個不同地區的企業實現組群的可能性，建立整套網路預警機制，實現非人工的貸中風險控制，完善了企業的信用體系。

通過以上的實施方式的描述，本領域的技術人員可以清楚地瞭解到本發明可借助軟體加必需的通用硬體平臺的方式來實現，當然也可以通過硬體，但很多情況下前者是更佳的實施方式。基於這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該獲取機軟體產品儲存在一個儲存介質中，包括若干指令用以使得網路設備執行本發明各個實施例該的方法。

以上公開的僅為本發明的幾個具體實施例，但是，本發明並非侷限於此，任何本領域的技術人員能思之的變化都應落入本發明的保護範圍。

11‧‧‧處理模組

12‧‧‧組群模組

13‧‧‧發送模組

14‧‧‧判斷模組

15‧‧‧儲存模組

16‧‧‧接收模組

17‧‧‧通知模組

圖1是本發明實施例一的一種網路聯保的處理方法的流程圖；圖2是本發明實施例二的一種網路聯保的處理方法的流程圖；圖3是本發明實施例二中伺服器和銀行系統交互資訊流程圖；圖4是本發明實施例二的風險控制的流程圖；圖5是本發明實施例三的一種網路聯保的處理方法的流程圖；圖6是本發明實施例四的一種網路聯保的處理方法的流程圖；圖7是本發明實施例五的一種伺服器示意圖。

Claims (11)

1. 一種網路聯保的處理方法，包括以下步驟：接收來自用戶裝置的貸款申請；使用戶能選擇該貸款申請的聯保組群方式；該伺服器根據該用戶的選擇創建指定給該貸款申請的聯保群；指定唯一編號給該聯保群；以及將該唯一編號及與該聯保群的群組會員相關聯的資訊傳送給銀行系統。
2. 如申請專利範圍第1項所述之方法，還包括：該伺服器判斷該用戶是否符合申請貸款的預定條件，如果該用戶符合該預定條件，則該伺服器提供聯保組群方式給該用戶選擇，否則，該伺服器將該用戶的貸款申請資訊儲存在資料庫中。
3. 如申請專利範圍第1項所述之方法，還包括：從銀行系統接收該銀行系統是否接受該用戶的貸款申請的通知；將該通知傳送到該用戶裝置。
4. 如申請專利範圍第1項所述之方法，還包括：將與該用戶相關聯的資訊加入到該聯保群作為聯保群編號；以及該伺服器根據該加入之與該用戶相關聯的資訊判斷該用戶是否符合成為該聯保群會員的預定條件，其中創建該聯保群的步驟包括在該用戶合該預定條件之後創建該聯保 群。
5. 如申請專利範圍第1項所述之方法，其中，該聯保組群的種類包括：自動匹配組群、兄弟會組群、線上發起/加入組群的至少其中一者。
6. 如申請專利範圍第5項所述之方法，其中，該聯保組群種類包括自動匹配組群，該自動匹配組群係由如下步驟實施：判斷出對該貸款申請有興趣的其他用戶；在該用戶與該另一用戶間提供用戶資訊；以及推薦組成包含該用戶及其他用戶的聯保群。
7. 如申請專利範圍第5項所述之方法，其中，該兄弟會的聯保組群方式為：若干用戶相約發起聯保組群，由該兄弟會中的某一用戶創建聯保群，並添加該兄弟會中的其他用戶共同申請業務。
8. 如申請專利範圍第5項所述之方法，其中，該線上發起/加入的聯保組群方式為：有業務需求的用戶，將組群需求發佈在該伺服器上，標明自我條件和組群條件，等待或添加符合條件的用戶加入組群。
9. 一種伺服器，包括：一或多個處理器；記憶體；處理模組，用於接收用戶發送的貸款申請，並提供不 同的該貸款申請的聯保組群方式給該用戶選擇；組群模組，用於根據該用戶的選擇創建指定給該貸款申請的聯保群，並指定唯一編號給該聯保群；以及發送模組，將該唯一編號及與該聯保群的群組會員相關聯的資訊傳送給銀行系統。
10. 如申請專利範圍第9項所述之伺服器，還包括：判斷模組，儲存於該記憶體且執行於該一或多個處理器，用於接收該用戶發送的貸款申請的資訊，判斷該用戶是否符合貸款申請的條件，如果符合，則把該用戶的貸款申請的資訊發送給該處理模組；以及儲存模組，儲存於該記憶體且執行於該一或多個處理器，用於當該用戶不符合貸款申請的條件時，儲存該用戶的貸款申請的資訊。
11. 如申請專利範圍第9項所述之伺服器，還包括：接收模組，儲存於該記憶體且執行於該一或多個處理器，用於接收該用戶貸款申請是否成功的資訊；以及通知模組儲存於該記憶體且執行於該一或多個處理器，用於將該用戶貸款申請是否成功的資訊發送給該用戶。