TWI670676B - 設計工程監管系統和方法 - Google Patents

Abstract

一種設計工程監管系統，為一發案方和一接案方的簽約過程產生一合約附件，包含一事件資料庫收集各種需求以及對應的建議檢核事項。一前端模組接收該發案方提交的一或多個發案方需求。一後端模組根據該些發案方需求和該事件資料庫產生一建議檢核表，包含一或多個建議檢核事項。當該發案方和該接案方皆同意該建議檢核表中的所有建議檢核事項時，該設計工程合約監管系統根據該建議檢核表產生該合約附件及一不可否認憑據。

Description

設計工程監管系統和方法

本發明係有關於一種設計工程監管系統，為室內外設計工程產業提供一種第三方見證的監管機制，以保護消費者和業者雙方的權益。

在傳統的室內裝修設計產業中，通常是由消費者向業者提出需求，接著雙方議定服務內容和報價，經過簽約後再開始進行服務。服務的種類通常包含紙上設計服務，以及現場施工。一般合約內容都會大致定義承包商應該要達成的工作項目，工作期限，以及付款時機。

然而，這一切程序皆為業者和消費者雙方人工作業，服務內容品質並無一個公正的評量標準。近年來有關設計施工服務的爭議糾紛與日俱增。面對各種千變萬化的使用者需求類型，業者所提供的服務往往與使用者期待有所落差，因此常常產生糾紛，各執一詞，前功盡棄，勞民傷財。根據設計產業公會統計，常見的糾紛類型可以粗分為合約糾紛，設計糾紛，施工糾紛和驗收糾紛，實際的案例可說是累積成冊，不勝枚舉。

以合約糾紛為例，若雙方僅口頭約定就進場施作，事後無論是施工品質或是工程金額都口說無憑，消費者可能不滿意服務內容或金額而產生糾紛。又舉例來說，付款時機和工程進度的認定，也容易有雙方認知的落差，若是合約中沒有詳細的定義，就會產生糾紛。

以設計糾紛為例，設計師有時候容易與消費者溝通不足。雖然是依照契約按圖施工，但是萬一消費者剛好是行動不便的人，無法使用一般規格的室內家具，導致前功盡棄，這對雙方都是成本和權益上的負擔。又舉例來說，設計服務範圍的認定，雙方容易有認知上的落差，若是沒有在合約中詳盡的定義，就會產生糾紛。

以施工糾紛為例，有時候施工現場隱藏一些前所未見的問題，在施工時才發現與設計圖有差異，或是房屋歪斜腐壞漏水之類，影響原定的進度和品質。又舉例來說，工期的估算，可能有來自業者和消費者各方面的變數而造成的延誤，若是沒有在合約中詳細的定義責任歸屬，就會產生糾紛。

以上這些案例只是冰山一角，顯示設計產業面臨巨大的潛在糾紛壓力，需要專業的協調機制來處理。有些較聰明的傳統業者，會提供定型化契約給使用者，將容易產生問題的事項，預先定義在合約附件中。然而，產生契約的機制掌握在業者手上，缺乏法律經驗消費者容易簽下對自己不利的不公平合約。相對的，業者也常會擔心遇到有心刁難的客戶，翻臉不認帳，造成時間和成本上的損失。

有鑑於此，一種根據使用者需求貼身打造合約範本的機制，以及一種第三方公正的監管機制，是有其必要性的。

本提案是一種設計工程監管系統，主旨在提供設計或施工時減少糾紛的輔助憑據。本系統為一發案方和一接案方的簽約過程產生一合約附件。一事件資料庫收集各種需求，以及該些需求對應的建議檢核事項。一 前端模組接收該發案方提交的一或多個發案方需求。一後端模組主要根據該些發案方需求，產生一建議檢核表。該建議檢核表包含從該事件資料庫中分析出的與該些發案方需求有關聯的一或多個建議檢核事項。當該前端模組接收到該發案方和該接案方皆同意該建議檢核表中的所有建議檢核事項時，該設計工程合約監管系統根據該建議檢核表產生該合約附件，並產生該合約附件的一第一不可否認憑據。

本設計工程監管系統，進一步包含一編修模組，供該發案方或該接案方提交修改要求，修改該建議檢核表，並確認該發案方和該接案方皆同意修改後的建議檢核表中的所有建議檢核事項。當該發案方和該接案方皆同意修改後的建議檢核表時，該設計工程監管系統註銷該第一不可否認憑據，根據修改後的建議檢核表重新產生該合約附件，並產生該合約附件的一第二不可否認憑據。

在另一實施例中，本設計工程監管系統進一步包含一流程監管模組，用以根據該合約附件產生一服務流程，該服務流程中包含一或多個執行階段，每個執行階段包含一或多個執行項。該流程監管模組接收該發案方和該接案方發出的確認訊息，以判定雙方是否同意對應的執行項或執行階段是否完成。

在另一具體實施例中，該服務流程包含至少一第一階段和一第二階段。該第一階段包含一或多個執行項，對應該合約附件中的一或多個建議檢核事項。該流程監管模組在接收到該發案方和該接案方皆確認該第一階段中所有執行項皆已完成的確認訊息時，才進入該第二階段，否則不允許流程繼續執行。

本設計工程監管系統可進一步包含一驗證模組，在接收到一驗證要求時，提供該不可否認憑據以證明該第一合約附件的完整性與正確性。

在該事件資料庫中，包含一設計需求庫，定義該發案方需要的各種室內設計服務項目，以及對應該些室內設計服務項目的糾紛案例大數據；以及一設計建議庫，對應該些室內設計服務項目，包含根據糾紛案例大數據而設計的多個設計建議檢核項目，具有預防設計服務糾紛的效果。該建議檢核項目庫，包含針對設計契約，設計範圍，設計費用，設計目標，付款時點，以及圖面交付種類而設計之建議檢核提示。

在該事件資料庫中，包含一施工需求庫，定義該發案方需要的各種施工服務項目，以及對應該些施工服務項目的糾紛案例大數據，以及一施工建議庫，對應該些施工服務項目，包含根據糾紛案例大數據而設計的多個施工建議檢核項目，具有預防施工服務糾紛的效果。該施工建議庫，包含針對施工進度，現場狀況，施工工法，施工材料，監工品質，驗收點交，售後保固而設計之建議檢核提示。

該設計工程監管系統係為獨立於該發案方和該接案方之公正第三方，而該不可否認憑據係以數位簽章方式確保其內容的完整性與公正性。由於合約附件的內容是基於使用者需求以及過往各種糾紛案例而得，只要消費者對需求的描述越具體詳細，所產生的合約附件越能確保雙方透過事前的合約簽定來避免糾紛。

100‧‧‧設計工程監管系統

102‧‧‧消費者

104‧‧‧業者

106‧‧‧前端模組

108‧‧‧後端模組

110‧‧‧事件資料庫

112‧‧‧編修模組

114‧‧‧流程監管模組

116‧‧‧線上付費模組

118‧‧‧驗證模組

120‧‧‧憑證資料庫

130‧‧‧銀行

140‧‧‧憑證中心

150‧‧‧區塊鏈

302‧‧‧建議檢核項目

304‧‧‧甲方核取方塊

306‧‧‧乙方核取方塊

308‧‧‧編輯鈕

310‧‧‧建議檢核表

312‧‧‧生成合約附件鈕

314‧‧‧新增自訂項目鈕

320‧‧‧合約本文

502‧‧‧執行項

504‧‧‧甲方核取方格

506、512‧‧‧乙方核取方格

508‧‧‧下一步鈕

510‧‧‧第一階段

520‧‧‧第二階段

530‧‧‧第三階段

600‧‧‧事件資料庫

610‧‧‧設計類資料庫

620‧‧‧施工類資料庫

612‧‧‧設計需求庫

614‧‧‧設計建議庫

616‧‧‧設計服務項目

618‧‧‧設計建議檢核項目

622‧‧‧施工需求庫

624‧‧‧施工建議庫

626‧‧‧施工服務項目

628‧‧‧施工建議檢核項目

第1圖係為本發明之設計工程監管系統100系統實施例之架構圖；第2圖係為本發明監管方法實施例之流程圖； 第3圖係為建議檢核表310之實施例；第4圖係為本發明流程控管實施例之流程圖；第5圖係為本發明流程控管界面之實施例；以及第6圖係為本發明事件資料庫600之實施例。

第1圖係為本發明之設計工程監管系統100實施例之架構圖。本發明之設計工程監管系統100係為一種雲端架構，可透過網際網路服務供消費者102和業者104上線使用，主要功能是扮演一個第三方公正者的角色，協助雙方簽約並監管簽約後的執行程序，將糾紛發生率降至最低。本設計工程監管系統100會產生可預防糾紛的建議檢核項目，讓雙方在簽約時能直接當成合約附件，也就是一種具有公證性的輔助文件。該合約附件在產生後，以數位型式儲存在憑證資料庫120中，不但載明了與消費者102提交的需求相關的多項建議檢核項目，也可以記錄簽約雙方皆同意這些項目的數位證據。一般而言為了確保服務的有效性，消費者102和業者104可以是通過實名認證機制註冊的會員，例如線上查核身份證或廠商公司登記證等。關於會員註冊的細節不在此贅述。該消費者102和業者104可以是透過本設計工程監管系統100的媒合功能而相識，或是透過其他管道相識，再一起登入本設計工程監管系統100使用見證監管功能。

為了協助消費者102和業者104產生恰當的合約附件，本設計工程監管系統100需要先了解使用者需求。該前端模組106可以是網頁界面或是行動APP的網路接口。消費者102提交的一或多個發案方需求，透過前端模組106進入設計工程監管系統100。本設計工程監管系統100中包含一事件資 料庫110，當中已收錄市面上各種設計施工需求，與需求相關的常見糾紛，可避免該些糾紛的相關建議檢核事項，以及設計施工需求與建議檢核事項之間的關聯資訊。該前端模組106收到發案方需求後，後端模組108從該事件資料庫中分析篩選出的與該些發案方需求有關聯的一或多個建議檢核事項，羅列成一張建議檢核表，透過前端模組106顯示在消費者102和業者104面前。該消費者102和業者104可透過前端模組106逐項勾選同意每一條建議檢核事項。當前端模組106收到消費者102和業者104皆同意該建議檢核表中的所有建議檢核事項時，該設計工程監管系統100將該建議檢核表轉成一種具有數位加密安全性的文件格式，即可直接做為消費者102和業者104雙方簽約時的合約附件，具有實質法律效力。本設計工程監管系統100尚可以數位簽章的方式為該合約附件產生不可否認憑據，儲存在憑證資料庫120中不受到外人竄改。將來任何人皆可透過公鑰系統，例如憑證中心140，驗證此文件的產生時間、牽涉對象、以及內文真偽。藉此本系統可發揮第三方見證的效力，消費者102或業者104皆無法單方面否認曾經勾選確認過的事實。

當建議檢核表產生後，消費者102和業者104雙方不見得皆同意其中所羅列的建議檢核事項。本設計工程監管系統100提供手動修改的彈性功能。設計工程監管系統100中有一編修模組112，供消費者102或業者104提交修改要求，可新增，修改或刪除該建議檢核表中的任一項建議檢核項目。當消費者102或業者104新增、修改或刪除一或多個建議檢核項目後，同樣地，必須由消費者102和業者104再次同時勾選同意該建議檢核表中的所有建議檢核項目，才可產生有效力的合約附件。該設計工程監管系統100會先註銷原合約附件所對應的不可否認憑據，再根據修改後的建議檢核表重新 產生一新的合約附件和新的不可否認憑據。

在合約附件產生後，本發明設計工程監管系統100尚可監管後續流程的執行。該設計工程監管系統100中包含一流程監管模組114，根據該合約附件產生一服務流程，透過前端模組106呈現在消費者102和業者104面前，供消費者102和業者104執行追蹤。舉例來說，服務流程中包含好幾個執行階段，每個執行階段包含好幾個待辦的執行項目，這些執行階段或執行項目通常就是來自建議檢核表中的一或多個建議檢核事項，或是對應相關的工作事項。一般來說，執行階段可以具體分為簽約階段，設計階段，施工階段，以及付款階段，各於有對應相關的執行項目。當一執行項目在實體世界中被消費者102或業者104執行完成時，該消費者102或業者104可透過前端模組106勾選確認完成該執行項目。每一執行階段中的所有執行項目，都必須有消費者102和業者104雙方的勾選確認，才能進入下一階段。舉例來說，若合約附件中約定某一工程包含幾個施工項目，則這些施工項目必須由雙方皆確認完成了，才能進入付款階段。因此，流程監管模組114具有一種雙方共同驗收的作用，若是某些執行項目無法獲得雙方一致的確認，可以馬上停止流程，待協調解決問題後再進行後續流程，以免糾紛擴大。另一方面，雙方皆勾選確認的執行項目，設計工程監管系統100會本持著第三方公正立場，在憑證資料庫120中留存數位證據，避免任何一方事後否認，製造糾紛。

做為進一步的實施例，本設計工程監管系統100可包含一線上付費模組116，在付款階段與一銀行130連線，提供消費者102和業者104一個安全的線上付款機制。該付款機制可以由流程監管模組114根據雙方流程進 度而觸發。若是流程進度並未達成簽約時所設定的條件，則不啟動付機制。

做為進一步的實施例，本設計工程監管系統100可進一步包含一驗證模組118。若有人欲查詢某個消費者102和某個業者104在某時間所簽的合約內容時，可透過前端模組106發送一驗證要求，由驗證模組118從憑證資料庫120中提取相對應的不可否認憑據以證明所欲查詢的合約附件的完整性與正確性。

做為進一步的實施例，本設計工程監管系統100保留未來與區塊鏈150串接的能力，用雲端大數據的技術來加強不可否認憑據的安全性。區塊鏈技術的原理就是所有與本設計工程監管系統100串接的每一個消費者102和業者104，本身都能貢獻一部份儲存運算能力，以分散式加密技術保存所有人的不可否認憑證資訊。這些不可否認憑證資訊不但公開透明，無法被否認，也很難被竄改。當本設計工程監管系統100擁有越多會員的時候，區塊鏈技術的安全性和效率就會越高。

第1圖的設計工程監管系統100的雲狀圖示中所繪及的各個模組，主要是定義軟體功能上的區別，未必表示現實中具備對應的架構。舉例來說，前端模組106，後端模組108，編修模組112，流程監管模組114，線上付費模組116，驗證模組118通常可以是實作在同一個電腦伺服器中。而事件資料庫110，憑證資料庫120通常可以是獨立的硬體架構，甚至是雲端的虛擬主機。

第2圖係為本發明監管方法實施例之流程圖，藉此說明本發明核心技術要點。首先，在步驟202中，透過大數據收集各種消費者102的設計施工需求，以及容易產生糾紛的案例。在步驟204中，產生可以滿足該些設 計施工需求又能降低糾紛發生率的各種建議檢核事項。這些建議檢核事項可以是透過專家經驗產生，或是根據市面上曾經發生過的糾紛案例經過分析演算法或人工智慧而產生。

在步驟206中，建立一事件資料庫110，將上述設計施工需求和上述各種建議檢核事項的關聯資訊收錄在其中。在步驟210中，由設計工程監管系統100接受消費者102提交的設計施工需求。該設計工程監管系統100可以用問卷的方式引導消費者102釐清需求。在步驟220中，由該後端模組108搜尋事件資料庫110，把與消費者102需求相關的一或多個建議檢核事項撈出來，羅列成表，在此稱為建議檢核表。在步驟230中，該設計工程監管系統100判斷該建議檢核表中的所有建議檢核項目是否皆得到該消費者102和業者104雙方勾選確認。如果否的話，就進入等候狀態不往下進行。如果是的話才進行步驟240。在步驟240中，該設計工程監管系統100根據該建議檢核表產生一合約附件，並產生該合約附件的不可否認憑據。

第3圖係為建議檢核表310之實施例，該建議檢核表310是由設計工程監管系統100根據使用者需求和事件資料庫110自動產生後，呈現在消費者102和業者104眼前時大致的樣貌。一般而言，簽約雙方會簡稱為甲方和乙方。在簽約時，一般會由消費者102和業者104雙方協議產生一份合約本文320，其內容屬於人工作業，不在本發明實施例討論範圍。而本發明的設計工程監管系統100則負責提供該建議檢核表310，做為合約本文320簽約時的輔助文件，具有法律效力，能協助消費者102和業者104避免簽下容易產生糾紛的條約。該建議檢核表310的畫面成份包含一或多個建議檢核項目302，每個建議檢核項目302後面有對應的甲方核取方塊304，乙方核取方塊 306和編輯鈕308。故消費者102或業者104在閱覽此畫面時，可以逐條針對每個建議檢核項目302進行勾選確認。例如甲方核取方塊304是僅供消費者102勾選的方格，而乙方核取方塊306是僅供業者104勾選的方格。當所有的甲方核取方塊304和乙方核取方塊306皆被勾選，生成合約附件鈕312才能作用，使程序往下進行(NEXT)。只要有任何核取方塊沒有被勾選，則生成合約附件鈕312可以處於隱藏狀態或是完全不受作用。

當生成合約附件鈕312開通後，且被消費者102或業者104任一方按下後，該建議檢核表310就被轉換成一份具有數位安全效力的合約附件，亦即合約本文320的附屬文件，可以PDF檔的型式下載，或是直接線上簽章，供消費者102和業者104正式簽約。另一方面，考慮到系統產生建議檢核表310時，有些建議檢核項目302並不是消費者102或業者104雙方所認同的，所以本實施例進一步包含編輯鈕308，對應每條建議檢核項目302。若消費者102或業者104任一方對某一建議檢核項目302有意見，皆可點選對應的編輯鈕308進行修改甚至是刪除的動作。在進一步的實施例中，本建議檢核表310可預留一新增自訂項目鈕314，提供新增建議檢核項目302的功能，讓消費者102和業者104新增自訂檢核項目。編修、刪除或新增完成後，尚留在該建議檢核表310上的所有建議檢核項目302或自訂檢核項目後面的甲方核取方塊304和乙方核取方塊306還是一樣要全部受到消費者102和業者104的勾選確認，始可觸發生成合約附件鈕312產生合約附件。

在進一步的實施例中，雙方新增編修後的自訂檢核項目，經過雙方同意後，可納入事件資料庫110中，成為將來遇有類似需求時可以使用的建議檢核項目。藉此機制，本設計工程監管系統100經過大量使用者長期訓 練之後，將會不斷的擴充進步而更加完善。

第4圖係為本發明流程控管實施例之流程圖，說明在合約附件產生後，設計工程監管系統100監管後續流程的步驟。在步驟402中，設計工程監管系統100中的流程監管模組114執行第一階段的監管，將第一階段所屬的多個待辦執行項目呈現在消費者102和業者104眼前，供消費者102和業者104對已完成的事項進行確認勾選。在步驟404中，判斷第一階段中所有執行項目是否都得到消費者102和業者104雙方的勾選確認。如果結果為否的話，程序停滯，不往下進行，並針對雙方不同意的項目展開協調機制。協調機制可以是雙方修改合約內容重新簽約，或是訴諸法院。在協調過程中，本設計工程監管系統100負責提供不可否認的歷程記錄，公正地保障雙方權益，避免任何人否認之前同意過的事項。如果步驟404得結果為是，則進行步驟406。在步驟406中，流程監管模組114執行第二階段的監管，將第二階段所屬的多個待辦執行項目呈現在消費者102和業者104眼前，供消費者102和業者104對已完成的事項進行確認勾選。步驟408雷同於步驟404，只有雙方皆勾選確認所有的執行項目，才往下進行後續流程，依此類推。

在一具體實施例中，第一階段可以是設計階段，而第一階段中的執行項目可以是提供設計圖，提供估價單，申請建照許可之類。而第二階段可以是施工階段，包含的執行項目可以是支付第一階段費用，確認工期，確認材料之類。實際運用原則上以使用者需求為核心，以事件資料庫110所儲存的經驗來減低糾紛發生率。

第5圖係為本發明流程控管界面之實施例，說明一服務流程可能包含至少第一階段510，第二階段520，甚至是第三階段530。以第一階段510 為例，其呈現畫面可能包含多個執行項502，每個執行項502對應一甲方核取方格504和乙方核取方格506、512。每一甲方核取方格504僅供消費者102勾選確認，每一乙方核取方格506僅供業者104勾選確認。只有在所有的甲方核取方格504和乙方核取方格506皆得到勾選確認，下一步鈕508才開通。當下一步鈕508開通後且被消費者102或業者104任一方按下，流程控制界面將從第一階段510畫面切換到第二階段520。依此類推，每個階段的執行項502一定要全部被雙方確認完成，設計工程監管系統100才會切換至下一階段的監管。除此之外，所有的勾選確認動作，都會在設計工程監管系統100中留存數位證據，以供將來必要時查核。

萬一有任何一執行項502無法獲得消費者102和業者104的同時認可，則服務流程必須暫停，並啟動協調機制來解決雙方歧見。舉例來說，在第5圖的乙方核取方格512中顯示乙方可以打叉的型式表示對某一階段其中任一項待辦的執行項有爭議。此時本設計工程監管系統100可將爭議發生的時間和相關事項記錄下來，做為數位證據。若是糾紛能順利化解，乙方可以解除打叉的狀態，使程序繼續往下進行。

第6圖係為本發明事件資料庫600之實施例。該事件資料庫600主要包含需求方面的大數據，可減少糾紛的建議檢核項目，以及需求與建議檢核項目之間的關聯資訊。舉例來說，該事件資料庫600中可包含一設計類資料庫610，其中尚可細分為一設計需求庫612及一設計建議庫設計建議庫614。該設計需求庫612定義消費者102需要的各種室內設計服務項目616，以及對應該些室內設計服務項目616的糾紛案例大數據。該設計建議庫設計建議庫614包含根據糾紛案例大數據而設計的多個設計建議檢核項目618， 關聯至該些設計服務項目616。每一設計服務項目616和設計建議檢核項目618之間的關聯性未必是一對一，也有可能是一對多，多對一，或多對多(第6圖中室內設計服務項目616和設計建議檢核項目618之間的多條虛線為關聯性的示意線)。舉例來說，許多需求都同樣地牽涉到預算和工期。有些設計需求會需要檢核色彩、大小或造型。一般來說，設計建議庫設計建議庫614中至少包含針對設計契約，設計範圍，設計費用，設計目標，付款時點，以及圖面交付種類而設計之建議檢核提示。

做為進一步的實施例，該事件資料庫600中可包含一施工類資料庫620，其中尚可細分為一施工需求庫622和一施工建議庫624。該施工需求庫622定義消費者102需要的各種施工服務項目626，以及對應該些施工服務項目626的糾紛案例大數據。該施工建議庫624包含根據糾紛案例大數據而設計的多個施工建議檢核項目628，關聯至該些施工服務項目626。具體來說，該施工建議庫624中可包含針對施工進度，現場狀況，施工工法，施工材料，監工品質，驗收點交，售後保固而設計之建議檢核提示。

以下幾個情境說明需求與建議檢核項目的關係。在設計需求庫612中的其中之一設計服務項目616可能是設計衣櫃，設計建議庫614中包含若干與衣櫃需求相關的設計建議檢核項目618，建議根據衣服尺寸預留吊掛空間，以預防衣服尺寸不合，或是建議預留通道以防動線不良。若設計需求庫612中的其中一設計服務項目616是為殘障人士設計的需求，設計建議庫614中可包含若干對應的設計建議檢核項目618，建議雙方簽約時檢核人體工學、操作方便性與使用安全性。若是設計需求庫612中有浴室設計的需求，則設計建議庫614的設計建議檢核項目618可建議雙方檢核浴室落水口 的設計位置，以防設計不當造成清潔上的困難。

在施工需求庫622中，包含與排水管有關的施工服務項目626，而施工建議庫624中包含的628建議雙方檢核排水管是否具備存水彎，以防漏水或臭氣外溢。另外，施工需求庫622中可包含與管道間有關的施工服務項目626，而施工建議庫624中的施工建議檢核項目628則建議雙方檢核管道間填塞是否踏實，以防風壓倒灌，臭味四溢。再舉一例，若施工需求庫622中包含與冷氣裝置有關的施工服務項目626，而施工建議庫624中可收錄相關的628，提醒雙方在施工時檢核冷氣管路是否破壞主結構，排水孔是否確實接通等。

由上可知，設計和施工時可能會發生的各種疑難雜症，千奇百怪，不勝枚舉，而本發明有效地提供了預防的機制，確保雙方權益。

本發明的精神不限定於設計和施工的實施例。其他階段例如簽約和驗收時可能產生的需求和糾紛，皆可在事件資料庫600中建立需求糾紛關聯和建議檢核項目。

與習知技術不同的是，本設計工程監管系統100係為獨立於該發案方和該接案方之公正第三方，並非廠商自有的系統，因此可避免消費者102掉入定型化契約的陷井，或是被單方面修改證據。此外，設計工程監管系統100中產生的不可否認憑據，可以是透過憑證中心140的數位簽章方式確保其內容的完整性與公正性。

Claims (10)

1. 一種設計工程監管系統，為一發案方和一接案方的簽約過程產生一合約附件，做為在設計或施工時減少糾紛的輔助憑據，包含：一事件資料庫，用以收集各種需求，以及該些需求對應的建議檢核事項；一前端模組，用以接收該發案方提交的一或多個發案方需求；一後端模組，用以根據該些發案方需求，產生一建議檢核表，其中該建議檢核表包含從該事件資料庫中分析出的與該些發案方需求有關聯的一或多個建議檢核事項，其中：當該前端模組接收到該發案方和該接案方皆同意該建議檢核表中的所有建議檢核事項時，該設計工程監管系統根據該建議檢核表產生該合約附件，並產生該合約附件的一第一不可否認憑據。
2. 如申請專利範圍第1項所述之設計工程監管系統，進一步包含：一驗證模組，在接收到一驗證要求時，提供該第一不可否認憑據以證明該合約附件的完整性與正確性；一編修模組，供該發案方或該接案方提交修改要求，修改該建議檢核表，並確認該發案方和該接案方皆同意修改後的建議檢核表中的所有建議檢核事項；其中：當該發案方和該接案方皆同意修改後的建議檢核表時，該設計工程監管系統註銷該第一不可否認憑據，根據修改後的建議檢核表重新產生該合約附件，並產生該合約附件的一第二不可否認憑據。一流程監管模組，用以：根據該合約附件產生一服務流程，包含至少一第一階段和一第二階段，該第一階段包含一或多個執行項，對應該合約附件中的一或多個建議檢核事項；以及接收該發案方和該接案方發出的確認訊息，以判定雙方是否同意對應的執行項或執行階段是否完成；其中：該流程監管模組在接收到該發案方和該接案方皆確認該第一階段中所有執行項皆已完成的確認訊息時，才進入該第二階段。
3. 如申請專利範圍第1項所述之設計工程監管系統，其中該事件資料庫包含：一設計需求庫，定義該發案方需要的各種室內設計服務項目，以及對應該些室內設計服務項目的糾紛案例大數據；以及一設計建議庫，對應該些室內設計服務項目，包含根據糾紛案例大數據而設計的多個設計建議檢核項目，具有預防設計服務糾紛的效果；其中：該建議檢核項目庫，包含針對設計契約，設計範圍，設計費用，設計目標，付款時點，以及圖面交付種類而設計之建議檢核提示。
4. 如申請專利範圍第1項所述之設計工程監管系統，其中該事件資料庫包含：一施工需求庫，定義該發案方需要的各種施工服務項目，以及對應該些施工服務項目的糾紛案例大數據；以及一施工建議庫，對應該些施工服務項目，包含根據糾紛案例大數據而設計的多個施工建議檢核項目，具有預防施工服務糾紛的效果；其中：該施工建議庫，包含針對施工進度，現場狀況，施工工法，施工材料，監工品質，驗收點交，售後保固而設計之建議檢核提示。
5. 如申請專利範圍第1項所述之設計工程監管系統，其中：該設計工程監管系統係為獨立於該發案方和該接案方之公正第三方；以及該不可否認憑據係以數位簽章方式確保其內容的完整性與公正性；其中該公正第三方包含區塊鏈。
6. 一種設計工程監管方法，為一發案方和一接案方的簽約過程產生一合約附件，做為在設計或施工時減少糾紛的輔助憑據，包含：收集各種需求，以及該些需求對應的建議檢核事項；接收該發案方提交的一或多個發案方需求；根據該些發案方需求，產生一建議檢核表，其中該建議檢核表包含從該事件資料庫中分析出的與該些發案方需求有關聯的一或多個建議檢核事項；以及當接收到該發案方和該接案方皆同意該建議檢核表中的所有建議檢核事項時，根據該建議檢核表產生該合約附件，並產生該合約附件的一第一不可否認憑據。
7. 如申請專利範圍第1項所述之設計工程監管方法，進一步包含：在接收到一驗證要求時，提供該第一不可否認憑據以證明該合約附件的完整性與正確性；當該發案方或該接案方提交修改要求時，修改該建議檢核表，並確認該發案方和該接案方皆同意修改後的建議檢核表中的所有建議檢核事項；當該發案方和該接案方皆同意修改後的建議檢核表時，註銷該第一不可否認憑據，根據修改後的建議檢核表重新產生該合約附件，並產生該合約附件的一第二不可否認憑據；根據該合約附件產生一服務流程，包含至少一第一階段和一第二階段，該第一階段包含一或多個執行項，對應該合約附件中的一或多個建議檢核事項；接收該發案方和該接案方發出的確認訊息，以判定雙方是否同意對應的執行項或執行階段是否完成；以及在接收到該發案方和該接案方皆確認該第一階段中所有執行項皆已完成的確認訊息時，才進入該第二階段。
8. 如申請專利範圍第6項所述之設計工程監管方法，進一步包含：定義一設計需求庫，包含該發案方需要的各種室內設計服務項目，以及對應該些室內設計服務項目的糾紛案例大數據；以及定義一設計建議庫，對應該些室內設計服務項目，包含根據糾紛案例大數據而設計的多個設計建議檢核項目，具有預防設計服務糾紛的效果；其中：該建議檢核項目庫，包含針對設計契約，設計範圍，設計費用，設計目標，付款時點，以及圖面交付種類而設計之建議檢核提示。
9. 如申請專利範圍第6項所述之設計工程監管方法，進一步包含：定義一施工需求庫，包含該發案方需要的各種施工服務項目，以及對應該些施工服務項目的糾紛案例大數據；以及定義一施工建議庫，對應該些施工服務項目，包含根據糾紛案例大數據而設計的多個施工建議檢核項目，具有預防施工服務糾紛的效果；其中：該施工建議庫，包含針對施工進度，現場狀況，施工工法，施工材料，監工品質，驗收點交，售後保固而設計之建議檢核提示。
10. 如申請專利範圍第6項所述之設計工程監管方法，係由獨立於該發案方和該接案方之公正第三方所執行，而該不可否認憑據係以數位簽章方式確保其內容的完整性與公正性；其中該公正第三方包含區塊鏈。