一種由多個控制點組成的合同支付系統的製作方法
2023-11-10 17:41:53
1.本發明涉及一種合同支付領域，特別是涉及一種由多個控制點組成的合同支付系統。
背景技術：
2.合同支付管理系統已廣泛運用在各行各業中，為合同臺帳管理、帳款支付管理、供應鏈收支管理等方面提供了產業應用的支持。目前合同支付管理系統多服務於企業內部或同一集團內部的多個子公司之間。
3.隨著在區塊鏈技術的發展，利用區塊鏈技術賦能於傳統行業，推動傳統行業進行數位化轉型成為一種新的嘗試。
4.本發明涉及一種合同支付領域，將區塊鏈技術應用於合同支付系統，利用區塊鏈的去中心化、不可篡改等特性，構建出基於區塊鏈技術的跨主體、跨區域的，合同支付行業應用系統。該系統主要解決了不同企業之間合同安全支付，解決不同支付類型的適用性問題，解決供應鏈上下遊之間的穿透性支付，解決合同履約過程的低成本存證。
5.本發明在合同支付類要素數據分析基礎上，提出合同支付數據結構化方案；明確應用主要流程包括：
①
合同籤訂後，支付條款數據化；
②
各方提交的資料以及各類合同修改都進行「數據指紋」錄入；
③
完成合同成果提交並經人判斷確認後，達成條件形成支付信息；
④
依據支付信息進行資金支付。從而保證項依據合同條款和智能合同自動啟動付款操作，並為管理者提供了跟蹤逾期付款的工具。
技術實現要素：
6.為了解決上述問題，本發明提供一種由多個控制點組成的合同支付系統，可以基於區塊鏈技術對所有類型的合同進行支付。
7.為了實現發明所要解決的技術問題，並且能夠使智能合約符合各行業場景下的合同支付邏輯，本發明首先需要對合同的支付方式進行研究。
8.通過對收集的各類合同進行分析解構，尋找出不同合同及不同支付方式的共性和歸集方法。同時在這個過程中，由於關於合同數據，我國《民法典》在第三篇第二章第469條第3款規定：「以電子數據交換、電子郵件等方式能夠有形地表現所載內容，並可以隨時調取查用的數據電文，視為書面合同」。這使得將合同由計算機系統記載、並輔助執行有可法律的支撐，但是在技術層面由於計算機系統無法直接解讀人類的語言，也就無法根據合同的條款進行準確地輔助執行合同支付動作。所以需要在人類語言構成的合同的條款和計算機可執行的指令之間建立一個轉化層，這個針對合同支付的轉化方式，就是合同支付數據結構化。
9.對合同支付數據結構化過程中，需要對合同條款中的合同支付全部信息要素進行原子化。合同信息可劃分為合同信息要素、合同支付描述性要素、合同支付動作性要素三類，其互相之間的關係，如圖1所示。這些合同信息要素組成了合同的全部內容。其中有一些
信息，在合同支付環節是非常重要的，它們與每一次支付動作是否能夠在正確的時間將錢款準確無誤地轉移到正確的地方有著直接的關係，如關於合同標的物的描述、收付款雙方的銀行帳號信息等，這些都是在合同支付映射到資料庫中生產智能合約過程中，保證資料庫正常運作所必須的信息。這些信息定義它為合同支付描述性要素。對合同支付描述性要素進一步提煉，形成能夠明確告訴計算機系統，誰在什麼時候向誰支付多少錢款的合同支付動作性要素。
10.本發明在對合同結構化過程中，合同支付數據結構化方式特作如下原則約定：（1）將僅滿足合同支付場景應用的最低的信息量要求的合同支付系統平臺，稱之為「輕平臺」，將全部合同信息要素全部上鏈的系統平臺，稱之為「重平臺」；（2）僅對合同中與支付直接相關的要素進行結構化；（3）將合同條款中與支付直接有關的描述內容梳理處理，形成合同支付描述性要素；（4）對合同支付描述性要素進一步提煉，形成能夠明確告訴計算機系統，誰在什麼時候向誰支付多少錢款的合同支付動作性要素。
11.通過以上2-4步，將用人類語言撰寫的施工合同抽象成由支付發起人、執行人、控制點、支付金額4個簡單的、計算機系統可執行的動作指令。
12.在進一步對「輕平臺」滿足支付的必要條件（也是「輕平臺」的最低信息量要求）展開研究後，形成基於滿足合同支付場景應用的最低的信息量要求的合同支付描述性要素，如表1所示。
13.表1：合同支付描述性要素表
將合同中每一筆支付過程進行動作分解，當出現新的一筆請款請求時：都出現「發起人(請款人）」、「控制點」、「執行人（支付人）」、「支付金額」（這裡的「控制方」可以是某個具體的主體，如發出命令的（合同雙方約定）的某個控制人（例如在施工總承包合同中，這個控制人是發出命令的監理工程師或投資控制工程師），也可以是某個抽象的概念，如經合同雙方提前約定一個時間點）等內容，這裡將這些內容定義為動作指令。這些在合同支付描述性要素中進一步提煉出能夠明確告訴平臺系統，誰在什麼時候向誰支付多少錢款的動作指令的信息要素，即合同支付動作性要素，如表2所示。
14.表2：合同支付動作性要素構成表
注*：在某些合同中，不一定只存在單向支付情況，即甲方（發包人）向乙方（承包人）支付工程款；有時可能還會存在反向支付的情況，即乙方（承包人）向甲方（發包人）支付預付款擔保，所以請款申請「發起人」，既可以是「乙方」，也可以是「甲方」；「執行人」也同理可能是兩者中的任意一方。
15.合同中的支付性要素和描述性要素的分析是對合同中每一筆支付的結構化梳理，要素中的內容是構成智能合約必不可少的信息，智能合約執行合同中每筆錢應該什麼時候支付（即智能合約觸發條件）、支付給誰，應該支付的數量是多少。只有從合同中正確梳理出支付性要素和描述性要素的信息並賦予智能合約，智能合約就能準確無誤的自動籤發支付證書（當平臺與銀行接口聯通後，智能合約則能夠自動完成真實錢款的支付），即智能合約在「正確的時間」向「正確的人」自動籤發「正確金額」的《支付證書》或支付指令。
16.不同行業中包含者各類數不盡的業務形態，不同的種類業務形態又會伴隨著有不同形式的合同，具體在合同條款中的描述和規定也會各不相同。但是無論哪種形式的合同對其支付方式來說，每一次支付，只有固定金額定支付和非固定金額定支付兩者情況，所以以上的研究結果，將對所有業態的合同形式是普遍適用的。
17.合同支付動作性要素是區塊鏈智能合約中形成每一個支付動作的最直接的主要信息，它包含了支付方式信息（即合同支付條件）和支付數額信息，「支付方式信息」告訴智能合約這筆錢應該什麼時候支付（即智能合約觸發條件）、支付給誰；「支付數額信息」告訴智能合約應該支付數量是多少。當從合同中正確梳理出支付動作性要素的信息並賦予智能合約，智能合約就能準確無誤的自動籤發支付證書或指令（當平臺與銀行接口聯通後，智能合約則能夠自動完成真實錢款的支付），即智能合約在「正確的時間」向「正確的人」自動籤發「正確金額」的支付證書或指令，完成「合同支付動作」，見表3。
18.表3：三種控制方式和相應的支付動作說明
對合同支付動作性要素顆粒化和結構化梳理後，合同支付動作性要素包含四個控制點：分別是：「定時」、「付款限時1」、「第三方限時」、「付款限時2」。
19.由這四個控制點分別組合成三種控制方式，分別是：（1）
ꢀ「
定時
」ꢀ
、 （2）
ꢀ「
付款限時1
」ꢀ
、 （3）
ꢀ「
第三方限時」+「付款限時2
」ꢀ
。
20.合同支付金額則分為「確定的支付金額」和「不確定的支付金額」兩種類型。
21.利用智能合約實現合同中單筆錢款支付的路徑是，如圖2（基於智能合約的合同支付動作）所示，首先由收款方（智能合約發起人）發起智能合約（即提出請款申請），其內容包括：
①
支付的觸發條件、
②
支付金額。當智能合約被發起後，計算機會自動且持續地判斷「觸發條件」中的「控制點」的參數是否被滿足，一旦達到「控制點」參數，智能合約的「觸發條件」被立即激活，智能合約自動執行支付動作。
22.而一份合同中可能包含多個支付節點，其中每個支付節點對應一個智能合約，如圖3所示。即一份合同可能由許多個智能合約組成，每一個智能合約對應一筆合同支付款項，該筆款項的合同支付條件就是這個智能合約的「觸發條件」；一旦某筆款項的合同支付條件達到，即觸發條件被激活，對應的智能合約將自動完成支付動作。
23.在本發明的合同支付系統中，利用智能合同的特性，將多個智能合同按預設的規則進行銜接，完成穿透性支付。如圖4所示，圖4（a）是某行業合同支付路徑結構，圖4（b）是圖4（a）所對應的智能合約結構，智能合約的結構和支付路徑與真實的合同支付情況一致，因此智能合同的可以準確無誤的進行穿透性支付。
24.在圖4（a）中所示，次級分包（2.2）完成合同所述的工作量後，要拿到相應工程款，
有個前提條件，就是需要分包（2）完成他的工作量後，由總包（0）先支付給分包（2）所對應的工程量。但不等於總包（0）支付的工程款後，次級分包（2.2）一定能夠及時地從分包（2）處獲得應有的工程款，在這過程中分包（2）企業有可能違規滯留、拖欠、剋扣工程款。圖4（b）中的運用智能合約的支付方式，可以將「智能合約0-2」、「智能合約2-2.2」的合同支付動作性要素相銜接，在同時滿足「合約智能0-2」、「智能合約2-2.2」的支付觸發條件後，由總包（0）將「智能合約2-2.2」所涉及工程款項直接支付給次級分包（2.2），這就是基於智能合約的穿透性支付功能。
25.由於智能合約技術並非區塊鏈所獨有，因此，本發明的合同支付系統也可以在中心化的傳統資料庫平臺上實現多個控制點支付和穿透性支付功能。合同支付系統如果使用去中心化的區塊鏈資料庫，則可以更低成本、更高可信度的進行支付過程存證，也由於建設跨區域、跨行業的開放式應用生態。
26.在本發明在對合同結構化過程中，對合同支付數據結構化方式作的第一條約定：將僅滿足合同支付場景應用的最低的信息量要求的合同支付系統平臺，稱之為「輕平臺」，將全部合同信息要素全部上鏈的系統平臺，稱之為「重平臺」。
27.由於在「輕平臺」中，無需將所有的合同信息要素都上鏈，錄入的合同信息僅滿足智能合約正確生成和執行的最低要求，而「重平臺」是將全部合同信息要素全部上鏈，比如錄入了所有對標的物特徵屬性和履約要求的描述以及相應證據，因此「重平臺」上的「存證」數據相對更廣泛。由於「輕平臺」中上鏈的「合同支付描述性要素」已經滿足了對合同標的物的支付要求，存在於輕平臺之中的「合同」，也可以認為是圍繞合同標的物進行支付的「多個智能合約的集合」。因此這兩種平臺在支付功能實現和支付準確性上，是相同的。
[0028]「輕平臺」的優點是無需改變現有的籤約習慣，合同文字內容表達方式更靈活，合同的適用性強；缺點是在後期人工錄入合同要素時，錄入的這一方存在過失錯誤輸入、二次解讀合同條款和惡性篡改合同內容的風險，這都需要合同的另一方在審核時非常仔細的核對。「重平臺」的優、缺點正好相反，與之對比，需要將所有的合同內容全部上鏈，甚至可以採用無紙化籤約，在系統平臺上甲、乙雙方使用數字身份id（如法人一證通、電子秘鑰等）完成合同籤署，籤約的即是錄入的數據，保持了數據的一致性。
[0029]
另外在「重平臺」是全數據上鏈，較「輕平臺」可以延伸出更多的拓展應用，比如由於「重平臺」上錄入了所有對標的物特徵屬性和履約要求的描述。因此可以將這些描述的信息結構化後，形成合同全息化要素集，圍繞著這些要素，在平臺裡記錄下合同履約過程中所有參與方的行為痕跡及其憑證資料，為合同的履約過程提供全息化的存證服務。
附圖說明
[0030]
圖1 合同信息要素結構（示意）。
[0031]
圖2 基於智能合約的合同支付動作（示意）。
[0032]
圖3 合同與智能合約結構模型（示意）。
[0033]
圖4 穿透性支付的構架（示意）。
[0034]
圖5 基於區塊鏈的某行業平臺應用合同支付系統構架（示意）。
[0035]
圖6 合同信息錄入、確認（籤署）過程（示意）。
[0036]
圖7 合同支付過程（示意）。
具體實施方式
[0037]
以下描述用於揭露本發明以使本領域技術人員能夠實現本發明。以下描述中的優選實施例只作為舉例，本領域技術人員可以想到其他顯而易見的變型。在以下描述中界定的本發明的基本原理可以應用於其他實施方案、變形方案、改進方案、等同方案以及沒有背離本發明的精神和範圍的其他技術方案。
[0038]
為了解決上述問題，發明提供一種由多個控制點組成的合同支付系統，可以基於區塊鏈技術對所有類型的合同進行支付。
[0039]
為了實現發明所要解決的技術問題，本發明構建了一個應用區塊鏈技術的合同支付系統，其整體構架及支付過程，如圖5所示。
[0040]
1、先由使用人在「交互層」的人機界面下錄入業務數據，如「合同信息」；2、「合同信息」經「平臺層」轉換成「合同支付動作性要素」後，傳至「資料庫層」；3、「資料庫層」將「合同支付動作性要素」保存後並向下穿透到「區塊鏈層」；4、在「區塊鏈層」生成「智能合約」。一旦合同支付條件符合後，「智能合約」將自動觸發執行，完成邏輯上的支付動作，並將該「合同支付過程信息」經「資料庫層」，傳遞到「平臺層」。
[0041]
5、「平臺層」根據「合同支付過程信息」生成「合同支付指令」，並通過第三方平臺接口，將「指令」傳遞給合同雙方所約定的支付銀行。
[0042]
6、支付銀行收受「合同支付指令」後，完成數字人幣支付，並通過第三方平臺接口將「電子回單」發送給「平臺層」；7、「平臺層」收到「電子回單」後，將「回單」存證並將數據穿透到「區塊鏈層」；8、「區塊鏈層」將「電子回單」上鏈記錄，完成整個支付的過程。
[0043]
合同支付場景在去中心化行業應用平臺系統中的運用，分解為2個關鍵過程：
①
合同信息錄入、確認（籤署）過程；
②
合同支付過程。
[0044]
1、合同信息錄入、確認（籤署）過程在由合同任意一方首先登入系統並輸入合同信息後，另一方登入系統進行接收，如果同意合同內容，在系統中進行確認後，合同信息確認被視為經雙方確認（籤署完成），合同信息將上鏈存證；如果接收的一方不同意合同內容，在系統中拒絕並提出修改意見。系統將通知合同輸入方進行修改，輸入方完成修改後再次提交接收一方。根據接收方作出的同意或拒絕的動作，系統再次進行分配處理路徑，見圖6所示。
[0045]
其中，合同雙方（第三方將作為聘請方身份）登入系統的方式，可以採用註冊後帳號+密碼方式登入，也可以採用法人一證通電子狗方式登入或其他數字認證的方式，目前建議採用法人一證通電子狗方式登入本系統，以保證支付系統的數據安全性和履約行為有效性。
[0046]
無疑，對於合同信息的輸入，要求滿足合同信息顆粒化和結構化，以便與系統可以生成與合同執行情況向對應的智能合同。這是一個建立基於區塊鏈應用系統時必須解決的問題，本發明已對此展開探討，並提出了合同要素的結構化建設方案（參見表1和表2）「重平臺」在合同信息錄入、確認（籤署）過程時，不再像「輕平臺」那樣只需錄入支付描述性要素，「重平臺」需要錄入全部合同信息要素。在合同支付過程和合同信息向相關方授權、傳遞過程兩個過程，「重平臺」和「輕平臺」的運行方式一致。「重平臺」支付場景在去
中心化行業應用平臺系統中的運用時，同樣分解為三個主要過程：
①
合同信息錄入、確認（籤署）過程；
②
合同支付過程；
③
合同信息向相關方授權、傳遞過程。
[0047]
2、合同支付過程基於區塊鏈的合同支付系統中，將工程合同中的每個支付「動作」建立一個智能合約。一旦智能合約中的觸發條件被滿足，智能合約就自動籤發《支付證書》或支付指令，完成支付動作，見圖7所示。
[0048]
系統中智能合約生成方式有兩種：
①
對有確定支付時間和支付金額的，在合同信息經雙方確認（籤署）後，可自動生成智能合約；
②
其他支付形式，在合同實施過程中，由合同的一方根據合同支付條件手動發起智能合約，當有一方發起智能合約，智能合約即生成。
[0049]
觸發條件應該根據具體約定的合同支付（計劃）條款設定，典型的包含兩種判別條件：相關方確認後支付；時間到達後支付。這兩種判別條件和單獨使用也可同時使用。對於有確定支付時間和支付金額的智能合約，一般只使用「時間」判別條件。
[0050]
值得指出的是，基於區塊鏈合同支付系統生成的「支付證書」或支付指令，是經過驗證和不可篡改的「證據」支持的；這些「證據」對所有利益相關方高度透明，並且是可以通過區塊鏈上可追蹤的數據信息。因此，基於區塊鏈合同支付系統產生的「支付證書」或支付指令，作為真實的有價值的「數據信息」， 該「支付證書」或支付指令將應有廣泛的「利用價值」。
優選實施例
[0051]
舉例一，某合同銷售合同中約定：在合同籤訂的10個自然日內，甲方向乙方支付貨款定金為合同總價的30%；乙方在收到定金後的30個自然日內完成貨品交付；乙方交付貨品後，甲方在10個自然日內完成驗收並付清全部尾款；合同總價為100萬元，該合同籤約時間2021年8月31日。該合同錄入信息後，有2次支付動作，會生成2個智能合約：第一個智能合約的觸發條件為控制方式1，控制點為「定時」（2021年9月10日），「支付金額」的形式為「固定價格」（30萬）。當乙方發起此智能合約後，期間如果甲方沒有回應，到2021年9月10日這天智能合約將自動完成30萬定金的支付動作。第二個智能合約的觸發條件為控制方式2，控制點為「付款限時1」（乙方交付貨品後，甲方在10個自然日內完成驗收，驗收合格後在5個工作日內付清全部尾款），「支付金額」的形式為「固定價格」（70萬），這個智能合約是以乙方先在平臺上提交「交付證明」，作為發起智能合約的前提條件，比如2021年9月20日乙方向甲方交付貨品，並於當天在平臺上上傳「交付證明」後發起第二個智能合約，按照觸發條件「控制方式2」的支付動作，甲方應在「付款限時1」所規定的時間（9月30日）前確認並完成支付，或者甲方在9月30日前提出貨品驗收不合格相關證據並中止該智能合約，否則智能合約將會在9月30日自動完成向乙方支付70萬尾款的支付動作。
[0052]
舉例二，某承包人按照施工合同的約定，向發包人申請2021年9月的工程進度款，雙方執行的是《建設工程施工合同（示範文本）》通用條款的相關內容。承包人於9月20日在平臺上發起智能合約，智能合約發起信息中包括承包人提交的當期工程款的總價和完成的工程量單價清單（相對於每次進度款價格，價格形式為「不固定價格」）。該智能合約的觸發條件為控制方式3，控制點為「第三方限時」和「付款限時2」，在這個合同中「第三方限時」和「付款限時2」都為7天。所以當承包人於9月20日在平臺在發起智能合約後，第三方（監理方）
有7天時間對承包人提出的請款申請進行審查，覆核其提交的總價和完成的工程量單價清單是否準確，到9月27日，監理方必須作出決定，是否確認同意當期工程款的支付。如監理方確認，則「智能合約」會通知發包人籤發《支付證書》；如監理方否決，此智能合約中止（由承包人修改當期工程款的總價和完成的工程量單價清單後，重新發起新的智能合約）；如監理方未按期作出決定，則「智能合約」會自動通知發包人籤發《支付證書》。當發包人收到監理方發出的「確認」信息後，有7天時間主動籤發《支付證書》，如未按期作出決定，則「智能合約」會自動籤發《支付證書》。
[0053]
以上所述中，智能合約最後執行的支付動作都是籤發《支付證書》，如果平臺能夠與銀行接口聯通，銀行根據《支付證書》作出轉帳操作，智能合約則能夠自動完成真實錢款的支付。
[0054]
以上所述的實施例僅用於說明本發明的技術思想及特點，其目的在於使本領域內的技術人員能夠了解本發明的內容並據以實施，不能僅以本實施例來限定本發明的專利採用範圍，即凡依本發明所揭示的精神所作的同等變化或修飾，仍落在本發明的專利範圍內。