項目處理方法及裝置、計算設備及儲存媒體
本發明涉及保險技術領域，特別涉及一種項目處理方法及裝置、一種計算設備及儲存媒體。
目前，一般的商業健康保險，根據疾病發生率定價，讓用戶先行支付固定保費，在進行賠付時也是根據繳納保費的額數確定賠付金額。而現有的互助產品並不是保險，不承諾剛性兌付，在有互助人申請賠付的情況下，不能很好的保障參與互助人的個人權益。
有鑑於此，本說明書實施例提供了一種項目處理方法及裝置、一種計算設備及儲存媒體，以解決現有技術中存在的技術缺陷。
第一方面，本說明書實施例公開了一種項目處理方法，包括：
接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊；
基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊；
基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目；
在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
第二方面，本說明書實施例公開了一種項目處理裝置，包括：
第一接收模組，被配置為接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊；
第一獲取模組，被配置為基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊；
第一審核模組，被配置為基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目；
第一綁定模組，被配置為在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
第三方面，本說明書實施例公開了一種計算設備，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦指令，所述處理器執行所述指令時實現該指令被處理器執行時實現如上所述項目處理方法的步驟。
第四方面，本說明書實施例公開了一種電腦可讀儲存媒體，其儲存有電腦指令，該指令被處理器執行時實現如上所述項目處理方法的步驟。
本說明書提供了一種項目處理方法及裝置、一種計算設備及儲存媒體，其中，所述方法包括接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊；基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊；基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目；在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
在下面的描述中闡述了很多具體細節以便於充分理解本發明。但是本發明能夠以很多不同於在此描述的其它方式來實施，本領域技術人員可以在不違背本發明內涵的情況下做類似推廣，因此本發明不受下面公開的具體實施的限制。
在本說明書一個或多個實施例中使用的術語是僅僅出於描述特定實施例的目的，而非旨在限制本說明書一個或多個實施例。在本說明書一個或多個實施例和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本說明書一個或多個實施例中使用的術語“和/或”是指並包含一個或多個相關聯的列出項目的任何或所有可能組合。
應當理解，儘管在本說明書一個或多個實施例中可能採用術語第一、第二等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書一個或多個實施例範圍的情況下，第一也可以被稱為第二，類似地，第二也可以被稱為第一。取決於語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“回應於確定”。
首先，對本發明一個或多個實施例涉及的名詞術語進行解釋。
後付費：指滿足條件的用戶在加入的時候不需要支付保障費用，就可以先享受保障，當成員中有出險核賠用戶後，根據實際發生賠付案件的情況，才向全體成員進行均攤收取保費。不同於一般的商業健康保險，根據疾病發生率定價，讓用戶先行支付固定保費。
信用審核：是指對申請加入的用戶進行申請條件判斷，符合條件用戶才可加入，並且與平臺信用結合，開發給誠信用戶。
健康告知：指保險公司在接受用戶投保申請時，要求對被保險人健康狀況的確認說明，保險公司一旦承保，健康告知書將成為保險合同的一個組成部分。
在本發明中，提供了一種項目處理方法及裝置、一種計算設備及儲存媒體，在下面的實施例中逐一進行詳細說明。
圖1是示出了根據本說明書一實施例的計算設備100的結構方塊圖。該計算設備100的部件包括但不限於儲存器110和處理器120。處理器120與儲存器110藉由匯流排130相連接，資料庫150用於保存資料。
計算設備100還包括存取設備140，存取設備140使得計算設備100能夠經由一個或多個網路160通訊。這些網路的示例包括公用交換電話網路(PSTN)、區域網路(LAN)、廣域網路(WAN)、個人區域網路(PAN)或諸如網際網路的通訊網路的組合。存取設備140可以包括有線或無線的任何類型的網路介面(例如，網路介面卡(NIC))中的一個或多個，諸如IEEE802.11無線區域網路(WLAN)無線介面、全球互通微波存取(Wi-MAX)介面、乙太網路介面、通用序列匯流排(USB)介面、蜂窩網路介面、藍牙介面、近場通訊(NFC)介面，等等。
在本說明書的一個實施例中，計算設備100的上述以及圖1中未示出的其他部件也可以彼此相連接，例如藉由匯流排。應當理解，圖1所示的計算設備結構方塊圖僅僅是出於示例的目的，而不是對本說明書範圍的限制。本領域技術人員可以根據需要，增添或替換其他部件。
計算設備100可以是任何類型的靜止或行動計算設備，包括行動電腦或行動計算設備(例如，平板電腦、個人數位助理、膝上型電腦、筆記型電腦、小筆記型個人電腦等)、行動電話(例如，智慧型手機)、可佩戴的計算設備(例如，智慧型手錶、智慧型眼鏡等)或其他類型的行動設備，或者諸如臺式電腦或PC的靜止計算設備。計算設備100還可以是行動式或靜止式的伺服器。
其中，處理器120可以執行圖2所示方法中的步驟。圖2示出了本說明書一個或多個實施例提供的一種項目處理方法，包括步驟202至步驟208。
步驟202：接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊。
本說明書一個或多個實施例中，所述用戶標識資訊包括但不限於在用戶參與項目的過程中針對某一用戶產生的唯一的參與項目的標識號，例如由用戶姓名、身份證號、參保日期以及參保流水號組成的用戶標識號。
步驟204：基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊。
其中，所述第一用戶資訊包括但不限於用戶的健康資訊，所述第二用戶資訊包括但不限於用戶的信用資訊。
本說明書一個或多個實施例中，獲取用戶的第一用戶資訊包括：
獲取用戶基於預設的第一用戶資訊報表確定的第一用戶資訊；或者
基於預設的第一用戶資訊獲取模型獲取用戶的第一用戶資訊。
所述獲取用戶的第二用戶資訊包括：
基於預設的信用評價模型獲取用戶的第二用戶資訊。
其中，所述第一用戶資訊報表包括但不想限於預設的健康測算報表，所述第一用戶資訊獲取模型包括但不限於預設的健康模型。
步驟206：基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目。
本說明書一個或多個實施例中，基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，即基於所述用戶的健康資訊以及信用資訊判斷所述用戶是否滿足准入審核，並給予審核結果。
步驟208：在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
本說明書一個或多個實施例中，審核結果為允許用戶參與項目，即是在所述用戶的健康資訊為健康以及信用資訊為達標的情況下，確定用戶滿足准入審核，允許用戶參與項目。
為所述用戶標識資訊和用戶對應的帳號建立綁定關係，即是為所述用戶的標識資訊和用戶對應的銀行帳號或者系統可扣款帳號建立綁定關係。
本說明書一個或多個實施例中，還包括：
在審核結果為不允許用戶參與項目的情況下，建立用戶黑名單；
在所述用戶黑名單中的用戶的第二用戶資訊滿足准入審核的情況下，根據預設時間間隔獲取所述用戶黑名單的用戶的第一用戶資訊；
在所述用戶的第一用戶資訊滿足准入審核的情況下，允許所述用戶參與項目。
即為了提高用戶參與項目的積極性，在審核結果為不允許用戶參與項目的情況下，為未通過參與項目審核的用戶建立用戶黑名單，然後在用戶黑名單中挑選出信用資訊達標、健康資訊為亞健康的用戶，然後每隔一定的時間週期對這些用戶的健康資訊進行一次更新，當這些用戶的健康資訊為健康的情況下，允許這些用戶參與項目。
另一種情況下，在審核結果為不允許用戶參與項目的情況下，建立用戶黑名單之後，還包括：
在所述用戶黑名單中的用戶的第一用戶資訊滿足預設要求，並且接收到所述用戶繳納指定費用的情況下，允許用戶參與項目。
即在用戶黑名單為挑選出健康資訊為健康、信用資訊不達標的用戶，然後在這些用戶同意繳納指定費用即保證金或預存費用的情況下，允許這些用戶參與項目。例如某一用戶的健康資訊為健康，因信用資訊造成不達標，那麼當在用戶同意預存費用的情況下，則可以允許該用戶參與項目。
本說明書一個或多個實施例中，所述參與項目請求中攜帶有用戶的關聯人資訊，
在審核結果為允許用戶參與項目的情況下，所述方法還包括：
接收用戶的指定關聯人的參與項目請求。
其中，所述關聯人包括但不限於用戶的未成年子女等，在審核結果為運行用戶參與項目的情況下，可以允許用戶添加未成年子女也參與該項目。
本說明書一個或多個實施例中，所述項目處理方法藉由根據用戶的第一用戶資訊以及第二用戶資訊的審核模式實現用戶參與項目，採用這種免費參與項目的方式極大的提高了用戶的參與項目體驗，並且根據用戶的基本資料實現用戶的關聯人也可以參與該項目，保障了項目的持續發展性。
參見圖3，本說明書一個或多個實施例提供了一種項目處理方法，包括步驟302至步驟316。
步驟302：接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊。
步驟304：基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊。
步驟306：基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目。
步驟308：在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
本說明書一個或多個實施例中，步驟302至步驟308的具體實現方式可以參見上述實施例，在此不再贅述。
步驟310：接收對待申領互助金案件的申領互助金請求，所述申領互助金請求中攜帶所述待申領互助金案件內容。
本說明書一個或多個實施例中，所述待申領互助金案件內容包括但不限於案件發生事件、地點以及案件發生的具體詳細過程等。
步驟312：在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，根據當前參與項目人數和所述待申領互助金案件的申領互助金額確定每個當前參與項目用戶的分攤金額。
步驟314：在所述分攤金額不超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中進行扣款。
本說明書一個或多個實施例中，所述預設分攤閾值可以根據實際情況進行設置，本發明對此不作限定。例如預設分攤閾值可以為2元、5元或10元等。
例如，在所述分攤金額不超過預設分攤閾值的情況下，根據當前參與項目用戶人數和所述待申領互助金案件的申請互助金的總金額確定每個當前參與項目用戶的分攤金額為10元。
本說明書一個或多個實施例中，從每個當前參與項目用戶對應的帳號中進行扣款包括：
在預設扣款週期內從每個當前參與項目用戶對應的帳號中進行輪巡扣款，直至扣款成功或者扣款週期結束。
其中，所述每個當前參與項目用戶對應的帳號包括自定義帳號和非自定義帳號。
所述自定義帳號可以為指定的銀行帳號，例如當需要從每個當前參與項目用戶對應的帳號中進行扣款時，可以從用戶的指定銀行帳號中進行扣款。所述非自定義帳號可以為隨機帳號，例如當需要從每個當前參與項目用戶對應的帳號中進行扣款時，可以先從用戶的平臺帳號中扣款，若扣款失敗則順序的從用戶的其他綁定銀行帳號中扣款。
步驟316：在所述分攤金額超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額。
其中，所述第二帳號為與所述項目關聯的帳號，即在分攤金額超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額後，剩餘的分攤金額從與項目關聯的第二帳號扣除，即由項目承擔剩餘的分攤金額。
本說明書一個或多個實施例中，以預設分攤閾值為10元為例，在所述分攤金額超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額進行詳細說明。
若所述分攤金額為20元，確定所述分攤金額20元超過預設分攤閾值10元的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額10元，然後從與所述項目關聯的第二帳號扣除分攤金額中每個當前參與項目用戶超過預設分攤閾值部分的分攤金額即每個當前參與項目用戶的10元。
本說明書一個或多個實施例中，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額包括：
在預設扣款週期內從每個當前參與項目用戶對應的帳號中進行輪巡扣除與預設分攤閾值相同的分攤金額，直至扣款成功或者扣款週期結束。
實際使用中，在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，為每個當前參與項目用戶發出扣款通知。
參見圖4，本說明書一個或多個實施例中，以所述項目處理方法應用於M項目平臺為例，對從每個當前參與項目用戶對應的帳號中進行扣款詳細說明。
每個當前參與項目用戶對應的帳號中進行扣款分為兩種情況，一種是未設置自定義扣款渠道，另一種是已設置自動以扣款渠道。
以未設置自定義扣款渠道為例，進行說明包括步驟402至步驟404。
步驟402：在已開通項目餘額、Y渠道以及H渠道的情況下，在第一天00:00:00-8:00:00從餘額、Y渠道或者H渠道進行在扣款；若扣款失敗，則在第一天8:00:00-22:00:00從餘額、Y渠道或者H渠道繼續扣款；若還是扣款失敗，則在第二天00:00:00-8:00:00從餘額、Y渠道或者H渠道繼續扣款；若還是扣款失敗，則在第二天8:00:00-22:00:00從餘額、Y渠道或者H渠道繼續扣款。
上述Y渠道和H渠道均為M項目平臺對應的相關內部渠道。即若存在與M項目平臺對應的內部渠道，優先藉由內部渠道扣款。
若扣款成功則可以隨時結束扣款流程，若扣款不成功則需要繼續執行後續扣款流程。
步驟404：在未開通餘額、Y渠道以及H渠道的情況下，在第一天8:00:00-22:00:00從指定銀行帳號進行扣款；若扣款失敗，則在第二天8:00:00-22:00:00從指定銀行帳號進行繼續扣款。
以已設置自定義扣款渠道為例，進行說明包括步驟406至步驟408。
步驟406：若自定義設置的第一扣款渠道為餘額、Y渠道以及H渠道的情況下，在第一天00:00:00-8:00:00從餘額、Y渠道或者H渠道進行在扣款；若扣款失敗，則在第一天8:00:00-22:00:00從餘額、Y渠道或者H渠道繼續扣款；若還是扣款失敗，則在第二天00:00:00-8:00:00從餘額、Y渠道或者H渠道繼續扣款；若還是扣款失敗，則在第二天8:00:00-22:00:00從餘額、Y渠道或者H渠道繼續扣款。
步驟408：若自定義設置的第一扣款渠道不是為餘額、Y渠道以及H渠道，而是為銀行帳號的情況下，在第一天8:00:00-22:00:00從指定銀行帳號進行扣款；若扣款失敗，則在第二天8:00:00-22:00:00從指定銀行帳號進行繼續扣款。
本說明書一個或多個實施例中，採用上述代扣繳費方式可以結合項目關聯帳戶、銀行帳號等，制定出上述智能的代扣發起機制，極大的提高扣款成功率。
本說明書一個或多個實施例中，所述項目處理方法採用分攤金額不超過預設分攤閾值的方法，使得在每個待申領互助金案件中每個當前參與項目用戶的分攤金額不超過預設分攤閾值，使得每個參與項目人員獲得項目保障的情況下，確保自己的利益不會受到無限制損失。
參見圖5，以所述項目為互助項目，所述參與項目請求為參與互助項目請求，所述第一用戶資訊為健康資訊，所述第二用戶資訊為信用資訊為例，對本說明書一個或多個實施例提供的一種項目處理方法進行詳細說明，包括步驟502至步驟516。
步驟502：接收用戶的參與互助項目請求，所述參與互助項目請求中攜帶用戶標識資訊。
步驟504：基於所述用戶標識資訊獲取用戶的健康資訊以及信用資訊。
本說明書一個或多個實施例中，獲取用戶的健康資訊包括但不限於：獲取用戶基於預設的健康報表確定的健康資訊；或者基於預設的健康模型獲取用戶的健康資訊。
例如，預先設置健康測算報表，在接收某個用戶的參保請求後，基於該用戶填寫的健康測算報表測算出用戶的健康資訊，產生健康告知書。所述健康告知書從易於用戶理解出發、以疾病、症狀以及常見醫學定義，解構健康告知內容，便於用戶依據自身健康情況進行告知。所述健康資訊可以包括但不限於該用戶的健康得分或者是直接可以確定出該用戶為健康、亞健康或者不健康等結果，其中，健康測算報表中包括但不限於身高、體重、家族病史以及個人病史等測試問題。
此外，針對健康問題不確定的用戶還可以基於預設的健康模型獲取用戶的健康資訊，即接收某個用戶的參保請求後，會基於智能的健康問題測試獲取用戶的健康資訊。例如首先會詢問用戶的身高、體重以及個人病史，若無個人病史則對家族病史進行詢問，若有個人病史則針對個人病史進行詳細測試，藉由這種智慧型機器人模式，對用戶的健康資訊進行獲取，保證了健康資訊獲取的精確性，並且極大的提高了對健康資訊獲取的高效性。無論是採用哪種健康資訊獲取的方式，均可以提供健康告知的過程資料回溯、結果資料記錄，為後期進行待申領互助金案件的申領互助金確定時提供必要資料支持、減少爭議。
本說明書一個或多個實施例中，獲取用戶的信用資訊包括但不限於：基於預設的信用評價模型獲取用戶的信用資訊。
實際使用中，可以藉由結合互助平臺的信用分、保險平臺的風控資料、保險公司的行業騙賠風控資料以及第三方授權資料等，藉由人工智慧模型分析，對用戶進行畫像，逐步形成用戶准入審核的信用評價模型，然後採用該信用評價模型對用戶的信用資訊進行判斷。
例如某一用戶為互助平臺信用分650分、屬逾期欠款用戶群、業務黑名單用戶、事實黑名單用戶即互保理賠用戶群、保險行業黑名單用戶群、行為黑名單用戶，那麼藉由預設的信用評價模型進行用戶的信用資訊的獲取，則可以確定該用戶的信用資訊不滿足准入審核的標準，即獲取到的用戶的信用資訊為不達標，反之，獲取到的用戶的信用資訊為達標。
步驟506：基於所述用戶的健康資訊以及信用資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與互助參保。
步驟508：在審核結果為允許用戶參與互助參保的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
步驟510：接收對待申領互助金案件的申領互助金請求，所述申領互助金請求中攜帶所述待申領互助金案件內容。
步驟512：在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，根據當前參與互助參保人數和所述待申領互助金案件的申領互助金額確定每個當前參與互助參保用戶的分攤金額。
步驟514：在所述分攤金額不超過預設分攤閾值的情況下，從每個當前參與互助參保用戶對應的帳號中進行扣款。
步驟516：在所述分攤金額超過預設分攤閾值的情況下，從每個當前參與互助參保用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述互助項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額。
需要說明的是，該互助項目處理方法的技術方案與上述的項目處理方法的技術方案屬同一構思，該互助項目處理方法的技術方案未詳細描述的細節內容，均可以參見上述項目處理方法的技術方案的描述。
本說明書一個或多個實施例中，所述項目處理方法應用在互助項目中，使得互助參保用戶可以先享受保障後參與分攤，且分攤金額按照實際出險並通過核賠公示無異議的情況來計算，根據實際發生申請互助金案例的情況進行費用分攤，不同於一般的商業健康保險，根據疾病發生率定價，讓用戶先行支付固定保費，並且採用分攤金額不超過預設分攤閾值的方法，使得對於每個待申領互助金案件每個當前互助參保用戶的分攤金額不超過預設分攤閾值，使得每個互助參保人員獲得參保保障的情況下，確保自己的利益不會受到無限制損失。
參見圖6，以所述項目為保險項目，所述參與項目請求為參保請求，所述第一用戶資訊為健康資訊，所述第二用戶資訊為信用資訊，所述待申領互助金案件為待理賠案件，所述申領互助金請求為理賠請求為例，對本說明書一個或多個實施例提供的一種項目處理方法進行詳細說明，包括步驟602至步驟616。
步驟602：接收用戶的參保請求，所述參保請求中攜帶用戶標識資訊。
步驟604：基於所述用戶標識資訊獲取用戶的健康資訊以及信用資訊。
步驟606：基於所述用戶的健康資訊以及信用資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參保。
步驟608：在審核結果為允許用戶參保的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
步驟610：接收對待理賠案件的理賠請求，所述理賠請求中攜帶所述待理賠案件內容。
本說明書一個或多個實施例中，理賠是保險公司執行保險合同，履行保險義務，承擔保險責任的具體體現。具體指保險事故發生後，保險人對被保險人所提出的索賠案件的處理。被保險人遭受災害事故後，應立即或藉由理賠代理人對保險人提出索賠申請，根據保險單的規定審核提交的各項單證，查明損失原因是否屬保險範圍，估算損失程度，確定賠償金額，最後給付結案。
實際使用中，所述待理賠案件內容包括但不限於大病理賠、住院理賠等。
步驟612：在根據所述待理賠案件內容確定所述待理賠案件需要理賠的情況下，根據當前參保人數和所述待理賠案件的理賠額確定每個當前參保用戶的分攤金額。
步驟614：在所述分攤金額不超過預設分攤閾值的情況下，從每個當前參保用戶對應的帳號中進行扣款。
本說明書一個或多個實施例中，所述預設分攤閾值可以根據實際情況進行設置，不申請對此不作限定。例如預設分攤閾值可以為0.1元等。
例如，在根據所述待理賠案件內容確定所述待理賠案件需要理賠的情況下，根據當前參保人數和所述待理賠案件的理賠額確定每個當前參保用戶的分攤金額為0.05元。
此時所述分攤金額0.05元不超過預設分攤閾值0.1元的情況下，從每個當前參保用戶對應的帳號中進行扣款0.1元。
本說明書一個或多個實施例中，所述每個當前參保用戶對應的帳號包括自定義帳號和非自定義帳號。
所述自定義帳號可以為指定的銀行帳號，例如當需要從每個當前參保用戶對應的帳號中進行扣款時，可以從用戶的指定銀行帳號中進行扣款。所述非自定義帳號可以為隨機帳號，例如當需要從每個當前參保用戶對應的帳號中進行扣款時，可以先從用戶的平臺帳號中扣款，若扣款失敗則順序的從用戶的其他綁定銀行帳號中扣款。
實際使用中，在根據所述待理賠案件內容確定所述待理賠案件需要理賠的情況下，可以先為每個當前參保用戶發出扣款通知。其中，所述扣款通知可以是系統提示或者是簡訊通知等。
步驟616：在所述分攤金額超過預設分攤閾值的情況下，從每個當前參保用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述保險項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額。
本說明書一個或多個實施例中，以預設分攤閾值為0.1元為例，對在所述分攤金額超過預設分攤閾值的情況下，從每個當前參保用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述保險項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額進行詳細說明。
若所述分攤金額為0.2元，確定所述分攤金額0.2元超過預設分攤閾值0.1元的情況下，從每個當前參保用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額0.1元，然後從與所述保險項目關聯的第二帳號扣除分攤金額中每個當前參保用戶超過預設分攤閾值部分的分攤金額即每個當前參保用戶的0.1元。
本說明書一個或多個實施例中，從每個當前參保用戶對應的帳號中進行扣款包括：
在預設扣款週期內從每個當前參保用戶對應的帳號中進行輪巡扣款，直至扣款成功或者扣款週期結束；
從每個當前參保用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額包括：
在預設扣款週期內從每個當前參保用戶對應的帳號中進行輪巡扣除與預設分攤閾值相同的分攤金額，直至扣款成功或者扣款週期結束。
需要說明的是，該保險項目處理方法的技術方案與上述的項目處理方法的技術方案屬同一構思，該保險項目處理方法的技術方案未詳細描述的細節內容，均可以參見上述項目處理方法的技術方案的描述。
本說明書一個或多個實施例中，所述項目處理方法，使得參保用戶可以先享受保障後參與分攤，且分攤金額按照實際出險並通過核賠公示無異議的情況來計算，根據實際發生賠付案例的情況進行費用分攤，不同於一般的商業健康保險，根據疾病發生率定價，讓用戶先行支付固定保費，並且採用分攤金額不超過預設分攤閾值的方法，使得對於每個待理賠案件每個當前參保用戶的分攤金額不超過預設分攤閾值，使得每個參保人員獲得參保保障的情況下，確保自己的利益不會受到無限制損失。
參見圖7，以保險平臺A為例，對本說明書一個或多個實施例提供的一種項目處理方法進行說明，包括步驟702至步驟730。
步驟702：接收保險平臺A中用戶的參保請求，所述參保請求中攜帶用戶標識資訊。
步驟704：基於所述用戶標識資訊獲取用戶的健康資訊以及信用資訊，並判斷所述用戶是否滿足准入參保審核，允許用戶0費用參保的情況，若滿足，則執行步驟706，若不滿足，則執行步驟708。
步驟706：允許用戶參保，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
步驟708：不允許用戶參保。
步驟710：用戶1出現，保險平臺A接收參保用戶中的用戶1對待理賠案件的理賠請求，所述理賠請求中攜帶所述待理賠案件內容。
步驟712：保險平臺A根據所述待理賠案件內容判斷所述待理賠案件是否需要理賠，若是，則執行步驟714，若否，則執行步驟724。
步驟714：對該理賠案件進行案件受理，根據當前參保人數和所述待理賠案件的理賠額確定每個當前參保用戶的分攤金額。
步驟716：每月的7日、21日對理賠案件內容以及分攤金額進行全民公示。
本說明書一個或多個實施例中，全民公示有助於對虛假案件的剔除。
步驟718：在所述分攤金額不超過預設分攤閾值的情況下，每月14日、28日從每個當前參保用戶對應的帳號中進行扣款。
本說明書一個或多個實施例中，單一案件人均分攤=(賠付金額+管理費)/賠付當日，此外，所述預設分攤閾值為0.1元，即在保人數單一案件每個參保人的分攤金額上限為0.1元。
步驟720：全部扣款成功後，保險平臺A匯總從每個當前參保用戶對應的帳號中進行扣款的總金額。
步驟722：保險平臺A支付賠付金額給用戶1。
步驟724：保險平臺A的項目審核組對該理賠案件進行案件審理，由項目審核組判斷是否同意分攤該理賠案件的分攤金額，若同意，則執行步驟726，若不同意，則執行步驟728。
步驟726：同意分攤，繼續執行步驟712。
步驟728：不同意分攤，結束該理賠案件。
步驟730：參保人員主動退出，不參與理賠。
本說明書一個或多個實施例中，所述項目處理方法，使得參保用戶可以先享受保障後參與分攤，且分攤金額按照實際出險並通過核賠公示無異議的情況來計算，根據實際發生賠付案例的情況進行費用分攤，不同於一般的商業健康保險，根據疾病發生率定價，讓用戶先行支付固定保費，並且採用分攤金額不超過預設分攤閾值的方法；並且每月兩次公示、兩次分攤。在公示日，其間發生的確診的理賠案件均會在適度隱藏敏感資訊的前提下，給予公示並接受異議申訴，公示無異議的所有理賠案件產生的保障金，加上規定的10%管理費，會在分攤日由所有參保用戶均攤，均攤實際金額視每期公示的實際情況而定。但單一理賠案件中，每個用戶被分攤到的金額不會超過1毛錢，使得每個參保人員獲得參保保障的情況下，確保自己的利益不會受到無限制損失。
參見圖8，本說明書一個或多個實施例提供的一種項目處理裝置，包括：
第一接收模組802，被配置為接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊；
第一獲取模組804，被配置為基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊；
第一審核模組806，被配置為基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目；
第一綁定模組808，被配置為在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
可選地，所述裝置還包括：
第二接收模組，被配置為接收對待申領互助金案件的申領互助金請求，所述申領互助金請求中攜帶所述待申領互助金案件內容；
第一確定模組，被配置為在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，根據當前參與項目人數和所述待申領互助金案件的申領互助金額確定每個當前參與項目用戶的分攤金額；
第一扣款模組，被配置為在所述分攤金額不超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中進行扣款；
第二扣款模組，被配置為在所述分攤金額超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額。
可選地，所述項目包括互助項目，包括：
第三接收模組，被配置為接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊；
第二獲取模組，被配置為基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊；
第二審核模組，被配置為基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目；
第二綁定模組，被配置為在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
可選地，所述裝置還包括：
第四接收模組，被配置為接收對待申領互助金案件的申領互助金請求，所述申領互助金請求中攜帶所述待申領互助金案件內容；
第二確定模組，被配置為在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，根據當前參與項目人數和所述待申領互助金案件的申領互助金額確定每個當前參與項目用戶的分攤金額；
第三扣款模組，被配置為在所述分攤金額不超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中進行扣款；
第四扣款模組，被配置為在所述分攤金額超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額。
可選地，所述項目為保險項目，包括：
第五接收模組，被配置為接收用戶的參與項目請求，所述參與項目請求中攜帶用戶標識資訊；
第三獲取模組，被配置為基於所述用戶標識資訊獲取用戶的第一用戶資訊以及第二用戶資訊；
第三審核模組，被配置為基於所述用戶的第一用戶資訊以及第二用戶資訊對所述用戶進行准入審核並給予審核結果，所述審核結果包括是否允許所述用戶參與項目；
第三綁定模組，被配置為在審核結果為允許用戶參與項目的情況下，為所述用戶標識資訊和用戶對應的帳號建立綁定關係。
可選地，所述裝置還包括：
第六接收模組，被配置為接收對待申領互助金案件的申領互助金請求，所述申領互助金請求中攜帶所述待申領互助金案件內容；
第三確定模組，被配置為在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，根據當前參與項目人數和所述待申領互助金案件的申領互助金額確定每個當前參與項目用戶的分攤金額；
第五扣款模組，被配置為在所述分攤金額不超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中進行扣款；
第六扣款模組，被配置為在所述分攤金額超過預設分攤閾值的情況下，從每個當前參與項目用戶對應的帳號中扣除與預設分攤閾值相同的分攤金額，從與所述項目關聯的第二帳號扣除分攤金額中超過預設分攤閾值部分的分攤金額。
可選地，所述第一獲取模組804、所述第二獲取模組或所述第三獲取模組進一步被配置為：
獲取用戶基於預設的第一用戶資訊報表確定的第一用戶資訊；或者
基於預設的第一用戶資訊獲取模型獲取用戶的第一用戶資訊。
可選地，所述第一獲取模組804、所述第二獲取模組或所述第三獲取模組進一步被配置為包括：
基於預設的信用評價模型獲取用戶的第二用戶資訊。
可選地，所述裝置還包括：
建立模組，被配置為在審核結果為不允許用戶參與項目的情況下，建立用戶黑名單；
第四獲取模組，被配置為在所述用戶黑名單中的用戶的第二用戶資訊滿足准入審核的情況下，根據預設時間間隔獲取所述用戶黑名單的用戶的第一用戶資訊；
第四審核模組，被配置為在所述用戶的第一用戶資訊滿足准入審核的情況下，允許所述用戶參與項目。
可選地，所述裝置還包括：
費用接收模組，被配置為在所述用戶黑名單中的用戶的第一用戶資訊滿足預設要求，並且接收到所述用戶繳納指定費用的情況下，允許用戶參與項目。
可選地，所述參與項目請求中攜帶有用戶的關聯人資訊，
在審核結果為允許用戶參與項目的情況下，所述裝置還包括：
指定關聯人接收模組，被配置為接收用戶的指定關聯人的參與項目請求。
可選地，所述每個當前參與項目用戶對應的帳號包括自定義帳號和非自定義帳號。
可選地，所述裝置還包括：
扣款通知發送模組，被配置為在根據所述待申領互助金案件內容確定所述待申領互助金案件需要申領互助金的情況下，為每個當前參與項目用戶發出扣款通知。
可選地，所述第一扣款模組、所述第三扣款模組或所述第五扣款模組進一步被配置為：
在預設扣款週期內從每個當前參與項目用戶對應的帳號中進行輪巡扣款，直至扣款成功或者扣款週期結束；
所述第二扣款模組、所述第四扣款模組或所述第六扣款模組進一步被配置為：
在預設扣款週期內從每個當前參與項目用戶對應的帳號中進行輪巡扣除與預設分攤閾值相同的分攤金額，直至扣款成功或者扣款週期結束。
本說明書一個或多個實施例中，所述項目處理裝置藉由根據用戶的第一用戶資訊以及第二用戶資訊的審核模式實現用戶參與項目，採用這種免費參與項目的方式極大的提高了用戶的參與項目體驗，並且根據用戶的基本資料實現用戶的關聯人也可以參與該項目，保障了項目的持續發展性。
需要說明的是，該項目處理裝置的技術方案與上述的項目處理方法的技術方案屬同一構思，該項目處理裝置的技術方案未詳細描述的細節內容，均可以參見上述項目處理方法的技術方案的描述。
本發明一實施例還提供一種電腦可讀儲存媒體，其儲存有電腦指令，該指令被處理器執行時實現如前所述項目處理方法的步驟。
上述為本實施例的一種電腦可讀儲存媒體的示意性方案。需要說明的是，該儲存媒體的技術方案與上述的項目處理方法的技術方案屬同一構思，儲存媒體的技術方案未詳細描述的細節內容，均可以參見上述項目處理方法的技術方案的描述。
所述電腦指令包括電腦程式碼，所述電腦程式碼可以為原始碼形式、對象代碼形式、可執行文件或某些中間形式等。所述電腦可讀媒體可以包括：能夠攜帶所述電腦程式碼的任何實體或裝置、記錄媒體、USB隨身碟、行動硬碟、磁碟、光碟、電腦儲存器、唯讀記憶體(ROM，Read-Only Memory)、隨機存取記憶體(RAM，Random Access Memory)、電載波信號、電信信號以及軟體分發媒體等。需要說明的是，所述電腦可讀媒體包含的內容可以根據司法管轄區內立法和專利實踐的要求進行適當的增減，例如在某些司法管轄區，根據立法和專利實踐，電腦可讀媒體不包括電載波信號和電信信號。
需要說明的是，對於前述的各方法實施例，為了簡便描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本發明並不受所描述的動作順序的限制，因為依據本發明，某些步驟可以採用其它順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬優選實施例，所涉及的動作和模組並不一定都是本發明所必須的。
在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其它實施例的相關描述。
以上公開的本發明優選實施例只是用於幫助闡述本發明。可選實施例並沒有詳盡敘述所有的細節，也不限制該發明僅為所述的具體實施方式。顯然，根據本說明書的內容，可作很多的修改和變化。本說明書選取並具體描述這些實施例，是為了更好地解釋本發明的原理和實際應用，從而使所屬技術領域技術人員能很好地理解和利用本發明。本發明僅受申請專利範圍及其全部範圍和等效物的限制。
100:計算設備
110:儲存器
120:處理器
130:匯流排
140:存取設備
150:資料庫
160:網路
202~208:步驟
302~316:步驟
402~408:步驟
502~516:步驟
602~616:步驟
702~730:步驟
802:第一接收模組
804:第一獲取模組
806:第一審核模組
808:第一綁定模組
圖1是本說明書一實施例提供的一種計算設備的示意圖；
圖2是本說明書一實施例提供的一種項目處理方法的流程圖；
圖3是本說明書一實施例提供的一種項目處理方法的流程圖
圖4是本說明書一實施例提供的一種項目處理方法的流程圖；
圖5是本說明書一實施例提供的一種項目處理方法的流程圖；
圖6是本說明書一實施例提供的一種項目處理方法的流程圖；
圖7是本說明書一實施例提供的一種項目處理方法的流程圖；
圖8是本說明書一實施例提供的一種項目處理裝置的結構示意圖。
