使用指定帳單特徵的建築支付管理系統和方法

2023-06-03 15:57:21 2

專利名稱：使用指定帳單特徵的建築支付管理系統和方法
使用指定帳單特徵的建築支付管理系統和方法
相關申請 本申請要求2007年4月30日提交的美國臨時申請No. 60/926， 867的優先權，其 內容整體併入此處作為參考。本申請還是2008年4月3日在先提交的共同待審美國申請 No. 12/061,805的部分繼續申請，其內容整體併入此處作為參考。
背景技術：
大建築項目和小建築項目的總承包商可能要求針對所選的子承包商指定發票/ 帳單。根據該實現(稱作"指定帳單")，總承包商在沒有來自子承包商的投入的情況下，直 接指定子承包商所完成的工作的價值。其它情況還要求一方(例如，總承包商、上層子承包 商、估算師或所有者)指定從事該項目的承包者中的一個承包商或全部承包商(例如，收款 人)所完成的工作的價值。例如，對於某些建築項目(如，具有單位定價的項目)，付款人可 以僱用和/或聘用檢查員，所述檢查員"測量"或勘測針對該項目所完成的單位並計算將支 付多少。在這些情況以及其它情況下，可以通過合同或通過實踐使收款人和/或付款人具 有有限的能力來調節將支付多少或者沒有能力調節將支付多少。

發明內容
本發明的一些實施方式提供了一種支付管理系統，該支付管理系統包括由付款人 和收款人可訪問的、軟體啟用的用戶界面。該系統還包括至少一個計算機可讀存儲器以及 處理器。處理器被配置為響應於從付款人接收到的命令，選擇性地在指定帳單模式下工作。 當在指定帳單模式下工作時，付款人輸入發票細節，並且所產生的發票被呈現給收款人以 供批准。當沒有在指定帳單模式下工作時，收款人可以輸入發票細節，付款人可以批准或拒 絕該發票。在一些實施方式中，處理器可以被配置為當開啟或關閉指定帳單時通知收款人。 在一些實施方式中，第一方和第二方能夠創建並傳遞附加信息，如與發票細節的證實有關 的注釋、照片、視頻或音頻。在一些實施方式中，將註解和先前的發票細節保存到計算機可 讀存儲器。 本發明的一些實施方式提供了一種支付管理系統，該支付管理系統包括由三方可 訪問的、軟體啟用的用戶界面。該系統還包括至少一個計算機可讀存儲器以及處理器。處 理器被配置為產生兩個有關的發票一一第一方和第二方之間的第一發票以及第二方和第 三方之間的第二發票。處理器被配置為針對第一發票以及針對第二發票選擇性地在指定帳 單模式下工作。當針對第一發票工作在指定帳單模式下時，第一方輸入發票細節。當沒有 針對第一發票工作在指定帳單模式下時，第二方輸入發票細節。類似地，針對第二發票，當 開啟指定帳單時，第二方輸入發票細節，而當關閉指定帳單時，第三方輸入發票細節。
在一些實施方式中，處理器被配置為在開啟指定帳單模式的情況下發起第二發 票，以及基於第一發票的發票細節創建第二發票的發票細節。在一些實施方式中，處理器被 配置為在關閉指定帳單模式的情況下發起第一發票，以及基於第二發票的發票細節創建 第一發票的發票細節。


圖1是根據本發明的一個實施方式的建築支付管理系統的示意圖。
圖2是示出了根據本發明的一個實施方式的、在關閉指定帳單的情況下創建發票
的流程圖。 圖3是示出了根據本發明的一個實施方式的、在開啟指定帳單的情況下創建發票 的流程圖。 圖4a是根據本發明的一個實施方式的、用於輸入發票細節的圖形用戶界面。
圖4b是具有活動註解窗口的、圖2a的圖形用戶界面。
圖5是用於批准或拒絕所指定的發票的圖形用戶界面。 圖6是示出了根據本發明的一個實施方式的、由付款人發起的發票創建的流程 圖，其中，可以選擇性地開啟或關閉所指定的帳單。 圖7是示出了根據本發明的一個實施方式的、由收款人發起的發票創建的流程
圖，其中，可以選擇性地開啟或關閉所指定的帳單。 圖8是示出了針對參與者的未完成任務的圖形用戶界面。 圖9是用於管理子承包商發票的圖形用戶界面。
具體實施例方式
在詳細解釋本發明的任何實施方式之前，應該理解，本發明並不將其應用限於說 明書中所闡述的或附圖中所示出的建築細節和組件布置。本發明能夠具有其它實施方式， 並且能夠以各種方式來實踐或執行。同樣地，應該理解，在此使用的措辭和術語是用於描述 的目的，不應被解釋為限制。這裡，"包括"、"包含"或"具有"及其變型的使用意指不僅包含 其後列出的項目及其等效物，還包含附加的項目。術語"安裝"、"連接"和"耦合"被廣泛使 用，並且包含直接和間接地安裝、連接和耦合。此外，"連接"和"耦合"不限於物理或機械的 連接或耦合，而是可以包括不管是直接還是間接地電連接或耦合。同樣，可使用包括直接連 接、無線連接等任何已知的方式來執行電子通信和通知。 建築支付管理系統為涉及到的各方給出了對項目的視覺訪問。在待審美國申請 No. 12/061,805和No. 11/032,699中描述了建築支付管理系統，其全部內容併入此處作為 參考。在此描述的建築支付管理系統的實施方式可以併入在上述待審美國專利申請中描述 的一些或全部特徵 下面描述的一些實施方式在創建和批准發票時提供了更大的靈活性。在一些實施 方式中，可以根據給定情況的需求由付款人、收款人、中間承包者或第三方來直接輸入發票 的細節。此外，一些實施方式允許多方輸入單張發票的細節，同時提供一種批准和記錄對該 發票所做的修改的組織化且安全的方法。 圖1示出了根據本發明實施方式的支付管理系統100。伺服器101連接至付款人 終端103和收款人終端105。伺服器101包括計算機可讀存儲器101A(例如，硬碟驅動器) 和處理器101B。伺服器還包括用於連接至區域網(LAN)和網際網路的硬體。計算機可讀存 儲器101A包括與使用支付管理系統100管理的建築項目有關的存儲數據，以及用於通過 LAN或網際網路與其它計算機通信的程序指令。基於web的用戶界面也存儲在計算機可讀存儲器101A上，並且在處理器101B上執行，以使得其它計算機可以訪問該基於web的用戶界 面。 在一些實施方式中，付款人和收款人終端103、105是通用個人計算機，而在其它 實施方式中，付款人和收款人終端103U05是被專門設計為用在支付管理系統100中的專 用計算機。在本實施方式中，付款人終端103是包含硬碟驅動器和CPU的個人計算機。付 款人終端103通過局域連接(LAN)直接連接至伺服器。收款人終端105是具有硬碟驅動器 和CPU的個人計算機。收款人終端105通過網際網路連接107連接到伺服器。基於web的用 戶界面存儲在伺服器101上的計算機可讀存儲器101A上，並且顯示在付款人和收款人終端 103、 105上。在另一個實施方式中，付款人和收款人終端103、 105可以通過其它方式連接到 伺服器101。例如，終端103、 105都可以通過網際網路107連接到伺服器。
附加終端也可以訪問伺服器101。例如，第三方評估者或政府檢查員可以通過終端 109訪問伺服器101。在一些實施方式中，通過基於web的用戶界面來提供對伺服器101的 訪問。授權用戶可以從接入網際網路的任何計算機訪問伺服器101和支付管理系統100。
圖2示出了使用支付管理系統IOO創建發票的一個示例。在該示例中，付款人 (如，子承包商或總承包商)能夠基於他們希望被支付的量來創建發票。該過程一般稱為 "收款人指定帳單"或"標準帳單"。 在圖2中，付款人請求發票(步驟201)。收款人創建發票(步驟203)並輸入發票 細節(步驟205)。系統基於該發票細節通過將該細節放入格式化模板中來產生發票。然 後，該發票準備好供內部審閱和收款人籤名(步驟207)。收款人可以在終端的用戶界面上 查看表格格式的發票細節，或查看/列印該格式化的發票。如果收款人對發票不滿意，則該 收款人不對該發票籤名(步驟209)，並作出進一步的修改(步驟205)。在一些實施方式中， 為收款人指派了提交修改和批准發票的時限或到期日。備選地，如果在支取日之前所指定 的發票未被籤名並且返回給付款人，則在支取期間將不會向收款人支付。
當收款人滿意發票的內容時，提交電子籤名(步驟209)，並將該發票發送至付款 人以供審閱。然後，付款人接受或者拒絕該發票(步驟211)。如果付款人不滿意發票的內 容，則發票被拒絕並返回給收款人以作進一步的編輯(步驟205)。否者，此刻發票準備好通 過支付過程而繼續(步驟213)。在發票準備好供支付之後，付款人可以手動地執行和交付 支付(例如，使用支票)，或可以使用支付管理系統來實現電子支付(例如，通過自動票據交 換所或通過資金電子轉帳)。 圖3示出了使用支付管理系統100創建發票的另一個示例。在該示例中，付款人 (如，總承包商或資產所有者)能夠基於付款人想要向收款人支付的量來創建發票。該過程 一般稱為"指定帳單"或"付款人指定帳單"。 在該示例中，當付款人希望創建發票(步驟301)時，付款人創建發票(步驟303) 並輸入發票細節(步驟305)。如果付款人滿意發票的內容，就將其發送到收款人(步驟 307)以供審閱(步驟309)。然而，如果付款人不滿意發票的內容，則該付款人可以繼續編 輯該內容(步驟305)。在發票被轉發並且被收款人審閱(步驟309)後，收款人決定是批 準還是拒絕該發票(步驟311)。如果收款人滿意，則提交電子籤名並將該發票返回付款人 (步驟313)。如果收款人不滿意，則該收款人拒絕該發票，並將其返回付款人以供進一步編 輯(步驟305)。在該示例中，收款人不能夠對發票做出任何修改——收款人只能批准或拒
7絕發票。當收款人批准該發票並對其電子籤名時，將該發票返回付款人。付款人仍可以拒絕 該發票並對內容作進一步修改(步驟305)。否則，該發票準備好通過支付過程而繼續(步 驟315)。 支付管理系統100的實施方式可以被配置為符合付款人或項目的地理區的優選 實踐。例如，在一些地區中，一般的慣例是不向付款人返回籤名後的文檔(例如，發票或留 置權放棄(lien waivers))。所指定的發票上的總額是收款人可被支付的總數，收款人不能 磋商或拒絕該發票。因此，系統的一些實施方式還可以被配置為禁止收款人拒絕所指定的 發票。 在其它情況下，付款人把指派發票中將被支付的數值的資格委託給第三方(例 如，估算師)。因此，系統的一些實施方式可以被配置為使第三方有能力控制指定帳單過程。 否則，除非明確聲明，術語"指定帳單"一般包含除收款人外的人輸入發票細節的所有情況 (例如，與"收款人指定帳單"相比較的"指定帳單")。 在一些實施方式中，可針對項目中包括的所有子承包商或項目中包括的單獨子承 包商開啟指定帳單特徵。當在開啟指定帳單的情況下子承包商包括在新的支取中時，系統 如圖3的方法中所示地繼續進行。當針對項目或針對具體的子承包商關閉指定帳單時，系 統如圖2的方法中所示地繼續進行。下面將要討論，在一些實施方式中可以在單個發票的 創建期間開啟或關閉指定帳單特徵，以允許各方協作輸入發票細節。 可在項目級設置默認的指定帳單狀態。開啟指定帳單為指派到該項目的所有新子 承包商設置了默認的設置。當創建第一級子承包商時，總承包商可以選擇針對具體的子承 包商關閉指定帳單。在一些實施方式中，針對項目來開啟指定帳單並不一定意味著針對所 有子承包商的全部設置，而僅是意味著指定帳單設置是該項目的默認設置。還可將該特徵 提供給子承包商的子承包商，並且默認的設置將遵循上層子承包商的指定帳單設置。
在收款人指定帳單和付款人指定帳單中，支付管理系統100都可以被配置為在發 生特定事件發生(如，新創建的發票、籤名的發票、發起的支付等)時發送通知。當總承包 商發送了指定的發票以供批准時，可以向子承包商(例如，子承包商項目管理者)發送包括 用於查看發票細節的連結在內的通知。然後，子承包商可以指派"Send to S"動作，並且將 發生通過建築支付管理過程來開發票的標準過程。下面將討論"動作"項的指派。
圖4a示出了向輸入發票細節的一方(例如，收款人、付款人或第三方評估者)呈 現的圖形用戶界面。本示例的用戶界面包括針對項目名稱401、合同號403和日期405的可 編輯文本區域。還包括可編輯的文本表格407，該文本表格407包括針對帳單項/收款人 名稱、完成百分比、計劃的支付值、和發票中將支付的量的區域。當創建或編輯發票時，可以 修改這些區域並且可以向表格407加入新的條目。當完成時，用戶點擊按鈕409保存修改。 備選地，用戶可以點擊按鈕411放棄任何修改並回復到發票的先前版本。
支付管理系統100的一些實施方式提供了合同等級百分比開發票，而不是表格 407中所示的排列項百分比開發票。為了使用該合同等級百分比開發票特徵，輸入發票細節 的一方可以在表格407中輸入一個百分比值，該百分比值將應用於所有子合同。該開發票 的量將等於子合同的全部計劃值的指定百分比。 在圖4a的示例中，總承包商正在創建針對材料提供商("BuildingSu卯ly Co.") 的發票。表格407包括三個條目-basement finishing、 glass door-parts以及glassdoor-installation。針對表格407中包括的每一排列項有聊天按鈕413。在另外的實施方 式中，只提供單個聊天按鈕413。通過按下聊天按鈕413，用戶可以發起與另一方的異步的、 基於文本的通信。圖4b示出了當按下一個聊天按鈕413時打開的聊天窗口421。聊天窗口 421包括用於輸入文本的區域423、發送按鈕425和示出用戶已發送或接收的消息的顯示區 域427。 如圖4b所示，在聊天窗口 421的顯示區域427中顯示出表示對發票做出的修改的 文本註解和數字值。在每一個條目旁邊是展開/摺疊按鈕429(例如，"+ "和"-")。當展 開條目時(例如，將按鈕429顯示為"-")，顯示區域427包括表格431，表格431列出了具 有註解的用戶所做的任何發票修改細節。表格431示出了先前的發票細節、新的發票細節 以及兩者間的差異。表格431還指示誰輸入了哪些細節。 如以上所述以及下面將要進一步討論的，可以在發票的創建期間開啟或關閉指定 帳單特徵。在圖4b的示例中，關閉了指定帳單特徵。在USER 1輸入原始發票細節後，USER 2將發票的"Glass Door-Install"條目的細節從完成0X修改成完成80X。因為來自USER 1的註解處於摺疊視圖中(如"+ "所指示的)，所以沒有顯示出表格431。因為來自USER 2 的註解處於展開視圖中，所以表格431示出了 USER1原始輸入的細節、USER 2輸入的更新 細節、以及兩者的差異。 在一些實施方式中，還使用聊天窗口 421傳遞照片以提供工作完成或材料交付的 視覺證據。例如，圖4b中的USER 2可以使用聊天窗口 421向USER 1發送部分完成的玻璃 門安裝的照片。在一些實施方式中，聊天窗口 421還利於以音頻(例如，mp3)或視覺(例 如，mpg)形式記錄的消息或注釋的傳遞和接收。在一些實施方式中，將聊天窗口 421替換 成實時通信的形式，如視頻或音頻會議窗口 。 如上所述，支付管理系統100的伺服器101包括存儲發票細節的存儲器單元101A。 在一些實施方式中，伺服器還存儲對發票所做修改的歷史(例如，哪一方做出什麼修改以 及在何時做出)，並且還存儲聊天窗口 421的內容。在一些實施方式中，以日誌的形式存儲 該信息，日誌允許用戶審閱導致發票的當前形式的修改和註解。 圖5示出了向審閱/批准發票的一方呈現的圖形用戶界面。在圖3的示例中，審閱 /批准發票的一方可以是步驟309的收款人，或者是步驟313的付款人。如圖4a中一樣，用 戶界面包括針對項目名稱501、合同號503和數據505的區域。然而，因為該屏幕僅用於審 閱/批准，所以這些區域是不可編輯的。類似地，表格507包括輸入到表格407(圖4a)中 的信息，然而表格507是不可編輯的。用戶可以通過點擊與排列項相對應的"approve"按 鈕509來批准發票上的單獨項。備選地，用戶可以通過選擇"approve all"按鈕511來批 準整個發票。 如上提到的，子承包商可以拒絕指定的發票。用戶可以通過選擇對應的"reject" 按鈕513來拒絕單獨排列項，或可以通過選擇"rejectall"按鈕515來拒絕所有列出的項。 拒絕指定發票的子承包商還可以通過使用"chat"按鈕517來提供拒絕原因。雖然圖5示 出了與每一列出的項相關聯的"chat"按鈕517，然而在其它實施方式中僅提供單個聊天按 鈕517。 如上討論的，選擇"chat"按鈕517將發起與另一方(在這種情況下，指定發票細 節的一方)的實時文本通信。如果該另一方不能"chat"，則在該另一方下次訪問系統時支付管理系統100將該拒絕通知給該另一方。提示指定方重新輸入發票。然後，可以使用 "chat"按鈕413 (圖4a)進行關於被拒絕項的磋商，或離線處理關於被拒絕項的磋商。
在一些實施方式中，可在支取開啟且發票待處理的情況下開啟或關閉指定帳單特 徵。當修改指定帳單設置時，系統回復到與新設置相關聯的操作(從指定帳單到標準，或反 之)。可將該修改應用到具體的發票、具體的收款人(例如，子承包商)或整個項目。
可以在項目期間的任何時刻修改指定帳單設置，並且切換指定帳單設置立即對設 置進行修改。當針對具體的子承包商修改指定帳單設置時，該子承包商的所有尚未送往籤 名人的發票可使用新的指定帳單設置開始開帳單過程。類似地，在具體合同上指定帳單的 開啟和關閉設置之間的切換可以導致尚未送往籤名人的(或未創建的)所有發票將工作流 程修改到新的設置。 例如，如果總承包商(付款人)開始使用指定帳單準備針對子承包商(收款人)的 發票，則子承包商將不能直接更改該發票。然而，如果總承包商在子承包商批准該發票之前 關閉指定帳單(即，轉換到收款人指定帳單)，則子承包商可以增加、移除或編輯發票細節。 在支付管理系統100中，將向子承包商發送針對該子承包商的任何指定帳單狀態的修改的 通知。 圖6示出了使用支付管理系統100的方法，其中在創建發票期間修改指定帳單設 置。付款人向該系統請求發票(步驟601)、發起發票的創建(步驟603)、以及輸入/編輯 發票細節(步驟605)。在付款人輸入/編輯了發票細節後，該付款人將該發票發送至收款 人(步驟607)或者保存該發票而不將該發票發送至收款人。如果沒有發送發票，則付款人 可以對該發票作進一步修改(步驟605)。 如果付款人準備好向收款人發送發票(步驟607)，則該付款人進行關於指定帳單 設置的確定。如果付款人希望使用指定帳單(即，付款人指定帳單)，則將"鎖定"置於發 票上(步驟609)。因而收款人能夠審閱發票細節(步驟611)並批准或拒絕該發票(步驟 613)。如果收款人拒絕該發票，則連同重新輸入發票細節的指令以及收款人(例如，使用 "chat"按鈕517)輸入的任何註解一起，將該發票發送回付款人。如果收款人批准該發票， 則附上電子籤名(步驟613)並將該發票發送回付款人(步驟615)。付款人仍可以拒絕發 票並作進一步編輯(步驟605)。否則，發票準備通過支付過程而繼續(步驟617)。
如果付款人希望使用收款人指定帳單，則在將發票發送至收款人時不在發票上放 置鎖定(步驟607和609)。再次地，收款人審閱該發票(步驟619)，並且向該收款人呈現 附上電子籤名(步驟621)的機會。如果收款人批准該發票，則將該發票返回付款人作如上 討論的最終批准(步驟615)。然而，如果收款人沒有籤名該發票，那麼該收款人現在能夠修 改、增加或刪除該發票(步驟623)。當收款人完成修改時，將更新的發票發送至付款人以供 審閱(步驟625和627)。在審閱該發票(步驟627)後，付款人決定批准還是拒絕收款人更 新的發票(步驟629)。如果付款人批准收款人的修改，則發票準備好通過支付過程而繼續 (步驟617)。否則，付款人對發票作另外的修改(步驟605)並將該發票發送回收款人(步 驟607)。 如上討論的，付款人可以在任何時刻對發票解鎖(例如，關閉指定帳單)(步驟 631)。例如，如果收款人使用"chat"按鈕517在審閱發票(步驟611)時向付款人發送了 消息(圖5)，則付款人可以選擇移除鎖定(步驟631)並允許收款人直接對發票進行修改，而不是付款人自己進行修改。 在一些實施方式中，可僅由收款人或由收款人和付款人來編輯未鎖定的發票。在 收款人和付款人都有編輯許可時，付款人和收款人可以協作修訂發票細節，直到收款人接 受該發票並對其籤名為止。如上所述，可以使用"chat"功能來便於這樣的協作。與未鎖定 的發票相關聯的編輯許可是由項目管理者(例如，付款人或總承包商)可選擇的。
在一些實施方式中，在所指定的發票都被發送至收款人(如，子承包商)之前，付 款人(例如，總承包商)始終可以輸入發票細節。然而，在一些實施方式中，在付款人請求 了發票(例如，步驟601)之後，付款人或收款人都可以輸入該發票的細節。在後者的情況 下，如果在子承包商(作為"收款人")輸入針對該子承包商的發票細節之前，總承包商(作 為"付款人")沒有輸入該發票細節，則系統可限制或防止總承包商輸入針對該子承包商的 指定的發票。 圖7示出了在關閉指定帳單(即，移除發票鎖定)的情況下發起發票的場景。在 付款人請求發票(步驟701)後，解鎖該發票並且收款人能夠輸入並編輯該發票的細節(步 驟703)。在輸入了細節後，可以將發票發送至與對內部收款人審閱具有批准和籤名權的收 款人相關聯的用戶(步驟705)。此時，收款人可對該發票籤名(步驟707)，或作進一步的 增加、刪除或修改(步驟703)。當收款人批准該發票時，附上電子籤名(步驟707)並將該 發票發送至付款人以供審閱。 如果付款人批准該發票(步驟709)，則附上另一的電子籤名(步驟711)並準備好 支付該發票。然而，如果付款人不批准，則該付款人可以將該發票返回收款人以供進一步編 輯(步驟703)，或者可以選擇直接修改該發票(步驟713)。如果付款人直接進行修改(步 驟713)，則將在開啟或關閉鎖定(g卩，付款人指定帳單或收款人指定帳單)的情況下向收款 人返回該發票(步驟715)。如果在鎖定關閉的情況下返回發票，則向收款人發送描述指定 帳單設置狀態的通知(步驟717)，收款人可以進一步修改該發票(步驟703)。該過程如上 討論的繼續進行。還可以與圖6的方法一起使用通知(未示出)。 然而，如果在開啟鎖定的情況下返回發票，則收款人不再能夠直接修改該發票。系 統向收款人發送通知，通知收款人已經開啟了發票鎖定並激活了指定帳單(步驟719)。收 款人審閱該發票(步驟721)，並將該發票發送至具有最終的內部收款人審閱籤名權的一方 (步驟723)。如果收款人批准已更新的發票，則附上電子籤名(步驟725)，並將該發票返回 付款人以供最終批准(步驟709和711)。如果收款人不批准，則將該發票送回付款人以供 進一步編輯(步驟713)。如上參考圖6所討論的，付款人可以在任何時刻解鎖該發票(步 驟727)。 如上討論的，在一些實施方式中，當特定事件發生時，向用戶發送通知和動作項。 例如，如圖7所示，當已經改變指定帳單設置時以及當所創建的發票待審閱時，發送通知。 圖8示出了根據一個實施方式的用於呈現這些通知的圖形用戶界面。當用戶(例如，付款 人、收款人、總承包商或子承包商)訪問系統100時，任務列表頁標識該用戶(801)、合同號 (803)和當前日期(805)。在一些實施方式中，合同號區域(803)是可選擇的，以使得同一 個用戶可以查看針對不同合同的任務。 表格807示出了針對該方的未完成任務/通知。例如，在圖8中，"Building Su卯ly Co."需要審閱編號0001的發票和輸入編號0002的發票細節。任務列表還包括向Building
11Supply Co.通知針對編號0002的發票改變了指定帳單狀態的通知。表格807還包括收到 日期和到期日。該用戶通過選擇與適用的項相對應的"view"按鈕809來從列表中訪問單 獨項。 圖9示出了"階段頁"，用戶(如，總承包商)可以從該"階段頁"中管理若干發票。 階段頁標識了用戶(901)、合同號(903)和當前日期(905)。在一些實施方式中，合同號區 域(903)是可選擇的，以使得用戶可以查看針對不同合同的發票。表格907提供針對每一 發票的信息，如子承包商名稱、發票編號、發票的當前狀態、要開帳單的總額、完成百分比、 以及發票上實際開帳單的量。用戶通過標記與可應用的發票相對應的方框909來選擇發 票。在選擇一個或更多列出的發票後，用戶選擇按鈕911、913、915中的一個來執行關聯的 操作。例如，用戶可以向子承包商發送發票(按鈕911)、查看發票的當前版本(按鈕913) 或查看與發票相關聯的任務(按鈕915)。在一些實施方式中，表格907的"status"區域包 括到用於完成未完成的任務的界面(如，圖4a或圖5的圖形用戶界面)的超文本連結。
在一些實施方式中，支付管理系統100用於針對涉及多於一個合同等級的情況來 管理分級開發票。例如，資產所有者與總承包商籤訂合同修建建築。然後，總承包商僱傭一 個或更多子承包商來完成特定任務(如，木工工作、管道工程等)。在這種情況下，一個等級 的開發票可以約束或通知另一個等級的開發票。 在一些實施方式中，支付管理系統100根據不同等級的指定帳單設置來管理分級 開發票。例如，如果在項目級開啟標準開發票(即，付款人指定開發票)，則子承包商向總承 包商提交發票。如果總承包商批准該發票，則支付管理系統100當產生要由總承包商向資 產所有者提交的發票時使用來自子承包商發票的細節作為默認細節。類似地，如果在項目 級開啟指定帳單，資產所有者所指定的發票提供了針對子承包商發票的發票細節。
支付管理系統100還可以在不同的分級等級實現不同的指定帳單設置。例如，總 承包商可以僅使用指定帳單創建子承包商發票，而使用圖6和7所述的協作開發票來創建 由資產所有者向總承包商支付的發票。在一些實施方式中，支付管理系統ioo然後使用來 自資產所有者發票的細節作為子承包商發票的默認細節。類似地，資產所有者可以僅使用 指定帳單(直接地，或通過如估算師之類的第三方)來準備針對總承包商的發票，而子承包 商使用標準開發票來向總承包商提交發票。在這種情況下，資產所有者的指定發票包括將 向總承包商支付的總額，而與較低等級處的合同子級(contractual children)(如，子承包 商)向收款人提交的發票無關。這種子承包商發票不改變付款人指定發票上的總數。
在於2006年7月12日遞交的待審美國專利申請No. 11/485， 545和2006年7月 12日遞交的待審美國專利申請No. 11/485， 610中討論了對合同子級的支付和這種合同/預 算分級的管理，將這兩份申請併入此處作為參考。 上述構架和方法是示意性的。其它配置、設計和使用也是可能的。本發明的實施 方式可應用於一方指定發票細節而另一方批准該發票並對該發票籤名的各種情況。因此， 本發明的範圍既不限於總承包商和子承包商之間的交易，也不限於涉及付款人和收款人的 情況。例如，如上所述，在特定的實施方式中，第三方限定發票的細節，並且付款人和收款 人對該過程都沒有任何控制。術語"付款人"和"收款人"不限於總承包商和子承包商。例 如，付款人可以是銀行或資產所有者，而收款人是總承包商。在其它示例中，收款人可以是 賣主、材料提供者或子承包商。
雖然以上支付管理系統100被描述為在伺服器上運行並可由個人計算機通過互 聯網來訪問的、基於web的應用，然而其它系統架構也是可能的。例如，在一些實施方式中， 整個軟體應用程式在單個終端上運行。在其它實施方式中，軟體應用程式在沒有中央服務 器的情況下在彼此間直接連接的兩個或更多個人計算機上運行。同樣地，術語"處理器"意 在包括單獨的CPU/微處理器或在連接到支付管理系統100的若干終端上的多個CPU。在權 利要求中闡述了本發明的不同特徵和優點。
權利要求
一種建築支付管理系統，包括與建築項目相關聯的第一方和第二方能夠訪問的軟體啟用用戶界面；計算機可讀存儲器；以及處理器，被配置為響應於從所述第一方接收到的輸入，選擇性地在指定帳單模式下工作；當在所述指定帳單模式下工作時，從所述第一方接收發票細節；當不在所述指定帳單模式下工作時，從所述第二方接收發票細節；基於所述發票細節來產生發票；向所述第一方和所述第二方顯示所述發票，以及請求所述第一方或所述第二方的批准或拒絕所述發票。
2. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為當已開啟 或關閉所述指定帳單模式時通知所述第二方。
3. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為請求所述 第一方和所述第二方批准或拒絕所述發票。
4. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為當不在所 述指定帳單模式下工作時，從所述第一方接收支票細節。
5. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為當在所述 指定帳單模式下工作時，防止所述第二方輸入支票細節。
6. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為當不在所 述指定帳單模式下工作時，防止所述第一方輸入支票細節。
7. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為響應於來 自所述第一方的輸入，針對發票開啟或關閉所述指定帳單模式。
8. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為在接收到 來自所述第二方的對所述發票的拒絕以及來自所述第一方的輸入之後，關閉所述指定帳單 模式。
9. 根據權利要求l所述的建築支付管理系統，其中，所述處理器還被配置為在接收到 來自所述第一方的對所述發票的拒絕以及來自所述第一方的輸入之後，開啟所述指定帳單 模式。
10. 根據權利要求1所述的建築支付管理系統，其中，所述處理器還被配置為針對新 的發票默認地開啟所述指定帳單模式。
11. 根據權利要求1所述的建築支付管理系統，其中，所述處理器還被配置為響應於 來自所述第一方的輸入在任何時刻關閉所述指定帳單模式。
12. 根據權利要求1所述的建築支付管理系統，其中，所述處理器還被配置為 從所述第一方和所述第二方中的一個接收註解，以及 向所述第一方和所述第二方中的另一個顯示所述註解。
13. 根據權利要求12所述的建築支付管理系統，其中，所述處理器還被配置為在以時 間順序排序的列表中顯示所述註解和從所述第一方和所述第二方接收到的多個其它註解。
14. 根據權利要求12所述的建築支付管理系統，其中，所述處理器還被配置為將所述 註解與對發票細節所作的修改相關聯。
15. 根據權利要求12所述的建築支付管理系統，其中，所述處理器還被配置為將所述 註解與發票的批准或拒絕相關聯。
16. 根據權利要求12所述的建築支付管理系統，其中，所述處理器還被配置為將所述 註解存儲到所述計算機可讀存儲器。
17. 根據權利要求12所述的建築支付管理系統，其中，所述處理器還被配置為將所述 註解存儲到所述計算機可讀存儲器。
18. 根據權利要求17所述的建築支付管理系統，其中，所述處理器還被配置為採用以 時間順序排序的列表的形式將所述註解和從所述第一方和所述第二方接收到的多個其它 註解存儲到計算機可讀存儲器。
19. 根據權利要求12所述的建築支付管理系統，其中，所述註解包括文本註解。
20. 根據權利要求19所述的建築支付管理系統，其中，所述文本註解包括到照片的鏈 接。
21. 根據權利要求12所述的建築支付管理系統，其中，所述註解包括照片。
22. 根據權利要求12所述的建築支付管理系統，其中，所述註解包括視頻記錄和音頻 記錄中的至少一個。
23. 根據權利要求1所述的建築支付管理系統，其中，所述第一方是估算師。
24. 根據權利要求1所述的建築支付管理系統，其中，所述第一方是總承包商，所述第 二方是子承包商。
25. 根據權利要求1所述的建築支付管理系統，其中，所述發票細節包括 承包者有責任為所述建築項目提供的材料和服務的總值，以及 與所述材料和服務相關聯的完成百分比。
26. 根據權利要求1所述的建築支付管理系統，其中，所述處理器還被配置為在從所 述第一方和所述第二方接收到對發票的批准之後，發起發票的電子支付。
27. 根據權利要求1所述的建築支付管理系統，其中，所述處理器還被配置為從所述 第一方或所述第二方接收對發票的批准進行驗證的電子籤名。
28. —種建築支付管理系統，包括 第一方和第二方能夠訪問的軟體啟用用戶界面； 計算機可讀存儲器；以及 處理器，被配置為通過所述軟體啟用用戶界面從所述第一方接收發票細節，其中，所述發票細節包括與 針對建築項目執行的工作相關聯的值、或與所供應的、用在所述建築項目中的材料相關聯 的值，基於所述發票細節來產生針對所述建築項目的發票； 通過所述軟體啟用用戶界面向所述第二方顯示所述發票， 向所述第二方請求對所述發票的批准或拒絕， 從所述第一方和所述第二方接收多個註解，將來自所述多個註解的註解與接收到的發票細節、批准和拒絕之一相關聯， 在以時間順序排序的列表中顯示所述多個註解，以及 將所述以時間順序排序的列表存儲到所述計算機可讀存儲器。
29. —種建築支付管理系統，包括與建築項目相關聯的第一方、第二方和第三方能夠訪問的軟體啟用用戶界面；計算機可讀存儲器；以及處理器，被配置為響應於從所述第一方接收到的輸入，選擇性地針對第一發票在指定帳單模式中工作， 其中，所述第一方與所述第一發票的付款人相關聯，所述第二方與所述第一發票的收款人 相關聯，當針對所述第一發票在指定帳單模式中工作時，從所述第一方接收針對第一發票細節 集的發票信息，當沒有針對所述第一發票在指定帳單模式中工作時，從所述第二方接收針對所述第一 發票細節集的發票信息，基於所述第一發票細節集來產生所述第一發票，響應從所述第二方接收到的輸入，選擇性地針對第二發票在指定帳單模式中工作，其 中，所述第二發票與所述第一發票有關，所述第二方與所述第二發票的付款人相關聯，所述 第三方與所述第二發票的收款人相關聯，當針對所述第二發票在指定帳單模式中工作時，從所述第二方接收針對第二發票細節 集的發票信息，當沒有針對所述第二發票在指定帳單模式中工作時，從所述第三方接收針對所述第二 發票細節集的發票信息，以及基於所述第二發票細節集來產生所述第二發票。
30. 根據權利要求29所述的建築支付管理系統，其中，所述處理器還被配置為 在開啟所述指定帳單模式的情況下，發起所述第二發票，以及 基於所述第一發票細節集來創建所述第二發票細節集。
31. 根據權利要求29所述的建築支付管理系統，其中，所述處理器還被配置為 在關閉所述指定帳單模式的情況下，發起所述第一發票，以及 基於所述第二發票細節集來創建所述第一發票細節集。
全文摘要
管理支付的系統和方法。系統的一個構架包括第一方和第二方可訪問的軟體啟用用戶界面，至少一個計算機可讀存儲器，以及處理器。處理器被配置為響應於從第一方接收到的輸入，選擇性地在指定帳單模式下工作。處理器被配置為當在指定帳單模式中工作時從第一方接收發票細節，以及當不在指定帳單模式中工作時從第二方接收發票細節。處理器還被配置為基於發票細節來產生發票，向第一方和第二方顯示該發票，以及請求第一方和第二方批准或拒絕發票。
文檔編號H04K1/00GK101720536SQ200880022870
公開日2010年6月2日 申請日期2008年4月30日 優先權日2007年4月30日
發明者威廉·H·艾希霍恩, 派屈克·J·艾倫, 查爾斯·C·切裡, 約翰·W·史密斯 申請人:特克斯圖拉公司