使用指定账单特征的建筑支付管理系统和方法

专利名称：使用指定账单特征的建筑支付管理系统和方法
使用指定账单特征的建筑支付管理系统和方法
相关申请 本申请要求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·史密斯 申请人:特克斯图拉公司