Patent Application
20140164255
Not Applicable.
Not Applicable.
Not Applicable.
Not Applicable.
1. Field of the Invention
The invention relates generally to the field of transaction negotiation and management systems and collaborative authoring of a negotiated document and seeks to transform the business and legal process of transaction between one or many parties. More specifically, the invention transforms documents from a manual, text-based and paper-laden process into a data-driven experience via a dynamic, negotiable transaction environment. More specifically still, the invention relates to a system and method for enabling coordinated, collaborative, data-driven contract (and/or other document types) negotiation among multiple, divergent parties either internally or externally in a virtual environment. More specifically still, the invention (certain embodiments of which may be commercially referred to as the CONTRACTROOM® system or platform (“herein CONTRACTROOM®”) and/or the Pro-Authoring™ feature or module of a transaction management system or similar platform) seeks to enable the streamlining of a complete contract/document workflow via a single platform that enables users to: organize and participate in online negotiations; formulate, modify and electronically execute contracts; systematically invite receiving parties (also referred to as a “counterparty” or “counterparties”) into active negotiation sessions; dynamically create, assign and control negotiation team permissions and alerts; structure and coordinate activities for negotiation team members and capture all actions (history, versions, comments) within the system as they relate to each finite negotiation session or instance; transfer and share information/data among multiple users in multiple locations in multiple time zones and in multiple languages; manipulate, prepare and present real-time data from each negotiation session or instance for purposes of fulfillment, analytics, alerts, reporting, audits, compliance, among other deliverables; and/or streamline and automate the process of a text-based negotiation, among other features.
2. Description of the Related Art
Businesses have increasingly turned to computer services and the Internet to better manage documents, in general, and more specifically the contract life cycle, from origination through negotiation, agreement, monitoring, execution, post-execution, and archival. To accomplish this goal, businesses frequently use several different technologies in attempt to consolidate and automate the negotiation and/or contracting process. Some of these technologies include: E-mail, PDF tools, Contract-Related Software, and Electronic Signatures. However, long-time professionals have found that in most industries and verticals, such as technology, media, financials and real estate, which are very contract-intensive, the process is still overwhelmingly dependent on manual and fragmented workflows.
In business today, contract origination and initial offers usually begin with phone calls, emails, and faxes between negotiation parties. An original offer is created and sent by faxing paper contracts or emailing PDF files to the counterparty. In order to make a counter offer, the counterparty typically uses a printout of the contract manually inputting or handwriting strikeouts, edits, comments, and initials onto the original document. This is done in order to keep track of the negotiation history. Once the counteroffer is prepared, it is faxed, scanned, or emailed back to the other party. The receiving party will use the same process to prepare and send back a counteroffer. This back-and-forth workflow occurs until an agreement is reached. Once the agreement is finalized, users can execute the contract by hand-written signatures or electronic signature technologies. E-Signature technologies, such as Docusign® or Adobe®'s Echosign®, require the document to be uploaded via an E-Signature website or API and sent by email to the signatories.
The only real digital part of today's status quo negotiation process is the transfer of the file by uploading or scanning it onto a computer and sending it via email. Furthermore, the nature of the back-and-forth flow of a fixed original document limits a business's ability to establish fluid internal and business-to-business communications, accelerate the time it takes from deal origination to contract execution, promote accountability and transparent monitoring, extract metadata analytics, and consolidate other business operations into one platform.
In many contract negotiations, even after the parties have reached an agreement in principle, a remaining step is to arrive at a final document embodying that agreement. In the context of an electronic system, this process may often be handled through an iterative drafting process known as “red-lining”, which can be laborious, contentious and counterproductive. In word processing, redlining refers to marking text that has been edited. Typically, redlining is used when two or more people are working on a document together; each individual can redline the text he or she has added or edited. The redlined text will then appear in a special color (or as bold, annotated, etc.) so that others can see the changes that have been made. Redlining a document, also known as Track Changes in Microsoft® Word, is a computer process by which changes are identified between two versions of the same document for the purposes of document editing and review.
The software-based document comparison process compares a reference document to a target document, and produces a third document which indicates (by colored highlighting or by differing font characteristics) information (text, graphics, formulas, etc.) that has either been added to or removed from the reference document to produce the target document. Common document formats for comparison include word processing documents (e.g. Microsoft® Word), spreadsheets, presentations (e.g. PowerPoint), and Portable Document Format (PDF) documents.
In some systems, during a document negotiation, all the words in the document (proposal, agreement, contract or otherwise) are scrutinized and available for modification by either party. The process may begin with the document/contract owner creating an offer with the term details spelled out in a document, which may be created using a word processing program and sent to the counterparty for consideration. Oftentimes, the counterparty unilaterally makes modifications to the document using redlining or comparable functionality. This type of exchange may be repeated a number of times, with the document being sent back and forth with changes being rejected or accepted until a final document is co-created by both parties.
Methods of this nature, however, may have one or more of the following characteristics: (1) they lack a formal system or process to capture data and manage the changes, neither with the counterparty or within one's own negotiation team; (2) users lose track of the changes unsure of the accuracy of the most recent version which requires; (3) users must proofread the most recent version of the document against previous iterations to ensure changes were not modified or deleted; (4) after several iterations, it may simply be too difficult and time-consuming to navigate through a document with hundreds of potential changes/revisions. Depending upon a particular application, it may be desirable to partially or fully remove or improve upon one or more of these factors and others.
The system and method of the invention seek to provide a comprehensive platform that enables the features necessary or desired to coordinate the life cycle of a binding agreement from deal origination to contract execution to transaction management to business intelligence. Such features may include, among others, accelerating (i.e. shortening the time required) individual steps and/or the overall process; facilitating internal and business-to-business communications; promoting accountability and transparent monitoring; extracting metadata analytics; and consolidating other business operations. In certain embodiments, a system and method of the invention further seeks to facilitate and manage the generation of a negotiable document, as in the context of a platform for coordinating the life cycle of a binding agreement from deal origination to document execution to transaction management to business intelligence.
The system may be built in a way that enables metadata creation, control, distribution and intelligence by digitizing each piece of an original negotiable document (i.e. terms, conditions, etc.) and building dynamic online negotiation environments. The front-end negotiation interface of the environment is shared by users of every party and manipulated based on a set of basic permissions. Meanwhile, the front-end interface is tied on the back-end to the original negotiable document boilerplate, so that as the users move through the negotiable document lifecycle the process can be completely automated. This means that whatever action a user performs in the front-end interface (i.e. change a negotiation term, make a counteroffer, electronically sign the finalized agreement, etc.), it is being processed, stored, and tracked on the back-end while generating a dynamic front-end that is shared and synced with the applicable users.
In one embodiment, the invention is offered in the form termed Software as a Service (SaaS), as discussed in greater detail herein. In this embodiment, the system may be completely web-based and not require both parties to subscribe to the service or have any other software licenses. Therefore, the service can extend to any person or business with Internet access.
In one aspect, the invention includes a system and method for digitizing negotiable document terms for interactive negotiation, which may include a process of deconstruction, i.e., separating negotiable document text from terms (negotiable items). Preparation of the negotiable document for negotiation may further include digital attributes being assigned to each term (date, currency, etc.) and tagged. The tag is then dragged into the negotiable document text identifying where it appears in the negotiable document once published. Signature fields are also identified and located in the contract. The negotiable document is made available for negotiation in a structured negotiable environment, referred to as a Contract Room™ environment. A Contract Room environment (with a space in between Contract and Room) is broadly defined as the environment where the transaction dealings occur (i.e. origination, negotiation, finalization, execution, etc.). A user will use a different Contract Room environment for every transaction or deal negotiation. A Contract Room environment is set up prior to deal origination and has an extremely flexible interface, so that a Contract Room environment can mirror the widest possible scope of business processes and deals in a company's Contract Management Lifecycle, such as: varying terms, party lines, approvals, etc. The output of a Contract Room environment is a specialized digital contract. These Contract Room environments and digitized contracts are managed within what is termed the CONTRACTROOM® platform, which platform may be implemented in a variety of ways, as described herein.
In another aspect, the invention provides a data-driven environment for structured negotiable document negotiation through a dynamic process, including a system and method for user-defined negotiation between team members and counterparties. The system creates a team leader, the individual creating a negotiable document offer, the beginning of a negotiation. Each team leader can negotiate directly with the counterparty or create his/her own team. Other term participants are invited into the negotiation. Each member has the ability to negotiate, view or approve the contract, plus the ability to sign. The team leader assigns one or many of these roles and responsibility to each participant. These roles are based on the individual's function in the negotiation. Agreements between teams are based on the team settings, all agree, some agree or one decides on a term for the term to be approved or countered.
In another aspect, the system collects user data throughout the negotiation and contracting process. Subscribers define how that data is disseminated throughout the organization pre- and post-contract. Definitions include directing specific information to individuals and departments inside and outside the organization. Data can be sent via email, or text or via integration with other existing technologies. Data can also be configured as timers and alerts to notify users of deadlines or other delivery requirements. Configurations can be defined by agreement template or by individual negotiation.
In another aspect, the system collects user data throughout the negotiation and contracting process for the provisioning of enterprise metrics. Subscribers define how the system analyzes that data and presents it to the user. Personal dashboard: Each CONTRACTROOM® subscriber has a personal dashboard reflecting that user's active and completed negotiations. Personal dashboards are configurable to compare the individual's performance to other subscribers in the enterprise. The system allows managers to see aggregate and individual performance of the users they oversee. Default analytics include: the risk a negotiation will or will not be concluded, projected income or expenses, existing and projected inventory demand, the number of times an agreement template has been used, and template clause and content performance. The system also manages timers and alerts associated with negotiable document deliverables.
In another aspect, the invention enables the extraction of negotiable document intelligence through a system and method for mining and reporting on document negotiation data. For example, the system may enable mining of meta-tag/term data and, in turn, deliver business intelligence on financial projections, sales and revenue pipeline, closing potential by contract, individual salesperson performance, and individual salesperson negotiation strengths and weaknesses, etc.
In another aspect, the invention provides negotiable document alerts through a system and method for delivering alerts and communications during and after document negotiation. The user assigns a unique set of actionable instructions to each negotiable item in a contract. When the data triggers the instructions, custom designed alerts and communications are sent to recipients during and after document negotiation.
In another aspect, a system and method of the invention enable a determination of negotiable document risk, i.e., an identification of the risk of losing a negotiation, such as by monitoring active document negotiation metadata (terms) and processing that data through an algorithm that identifies the potential risk of losing the deal. As more document negotiations take place, the system builds custom modeling unique to the organization using the system.
In another aspect, the invention enables multilingual negotiations through a system and method for translating the Categories and Items, so that parties can look at the dynamic, virtual negotiation environment in their native language, allowing users to select the language in which they wish to negotiate.
In another aspect, a Pro-Authoring feature or module in the context of document negotiation creates a formal structure and process for making collaborative text changes between two or more parties. First, the text (sometimes referred to as “legalese”) from a legal document (proposal, contract, agreement, or otherwise) is prepared by the drafter of the originating party (or “Contract Originator”) involved in a negotiation and uploaded into a contract or document management system.
In another aspect, after all business terms have been negotiated and agreed upon, the party that did not create the negotiable document (known as the “Counterparty” or an internal team member of the “Contract Originator”) is presented the legal text/terms for review and acceptance. If the reviewer does not agree with the text presented, then such individual(s) must formally request changes to the originating party, therein providing a formal, recorded comment that could include the context (the rationale for the requested change) and/or the content (the suggested text change) to be incorporated into the original draft.
In another aspect, the originating party must accept or reject the request and, if rejecting, may provide his/her explanation/comment for the rejection of such “change request”.
In another aspect, once a change request is accepted, the originating party (and/or his/her designated Author/Editor) may be designated as the only user with redrafting privileges. Once the text is redrafted with all the agreed upon text changes, the negotiator and/or reviewer has the ability to accept or reject the rewrite.
In one embodiment, Pro-Authoring's digital process: (1) ensures that all text changes are clearly documented in an audit history that is easy to source and follow; (2) creates a framework and process for text-based negotiation; (3) facilitates flawless consensus between a negotiation team and the counterparty; and/or (4) shows the most recent approved text version. If a text change request has not been approved with newly authored text, users do not see the change.
To summarize, a comprehensive, singular transaction management platform that enables coordination of the life cycle of a binding agreement from deal origination to negotiable document execution to transaction management to business intelligence in an effort to transform the business and legal process of one or many parties reaching consensus on transactions. The system and method controls the process of transforming documents from a text- and paper-based environment into a data-driven negotiable transaction environment. Each negotiable transaction environment is fueled by a negotiation engine that replaces the manual processes of face-to-face, phone, email, and offline discussions as well as the manual and time-consuming administration involved with receiving approvals, signoffs, signatures, commenting, recordkeeping and documentation. The system and method streamlines and automates the negotiation process amongst two or more parties of making collaborative changes to text-based terms as a partial or complete alternative to the iterative drafting process known as “red-lining,” which can be laborious, contentious and counterproductive. The invention encourages a timely, efficient and productive term/text resolution, by promoting agreement on context (rationale) before content. It also provides an online, real-time searchable history of all changes, versioning, commentary, drafting and authoring related to the stored/hosted data and text terms captured in each specific, unique negotiation session or instance, which may be required by any of the negotiation participants or other authorized stakeholders for purposes of discovery, compliance or audit.
Additional features and advantages of the invention will be made apparent from the following detailed description that proceeds with reference to the accompanying Figures.
A portion of the disclosure of this patent document, in particular the figures, contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
In the following detailed description of the invention, reference is made to the accompanying Figures, which illustrate specific exemplary embodiments of the invention. It should be understood that varied or additional embodiments having different structures or methods of operation might be used without departing from the scope and spirit of the disclosure.
As discussed herein, a system and method of the invention seek to provide a comprehensive platform for transaction management by transforming text-based, paper-laden document processes into dynamic, negotiable data environments in an effort to transform the business and legal process of one or many parties reaching consensus or agreement on transactions. In one embodiment, transactions of interest include those occurring during the life cycle of a binding agreement from deal origination to negotiable document execution, enabled by way of a negotiable document management system and associated methods. Some or all of these transactions might occur “online” in the sense of communication between parties at different locations, which may range from different terminals in the same room to different rooms to different cities or countries or other locations, etc. This communication might include use of the Internet or World Wide Web, or other suitable wired or wireless communication means for enabling the transactions and interactions disclosed herein.
The invention might be applicable to a variety of fields and industries, including Media, Technology, Finance, Consulting, Telecommunications and Real Estate, among many others. A macro-depiction of an embodiment of a system in accordance with the invention is presented in
CONTRACTROOM® can be used in any industry/sector where there are buyers and sellers of assets or products or services, or there otherwise are 2 or more individuals negotiating, either internally for consensus or externally for formal agreement. In one embodiment, CONTRACTROOM® not only manages the negotiation and workflows for specific individuals, but can also call in additional users for a variety of purposes to help negotiate, authorize, manage, maintain, and renew a specific or range of contracts/agreements. In this way, CONTRACTROOM® takes the pain out of the entire contracting lifecycle and may allow for a simpler negotiation, smarter negotiable document and better business.
The system/solution was developed with the flexibility to apply to any industry, sector, and circumstance. For purposes of illustration, disclosure will be provided through and in the context of a specific example to illustrate CONTRACTROOM®'s overall workflow and core functionality, while demonstrating the power and potential of this wide-ranging solution.
Consider for purposes of illustration a Sales Manager who manages a team of Sales Associates at a realty company. The Manager wants to implement the use of CONTRACTROOM® for all of his team's operations concerning Residential Leases (similarly, it could be a sales representative executing a software license agreement for a computer software provider or, for that matter, an individual or entity that desires to negotiate and reach consensus/agreement on any document). Once the situation arises in which a negotiable document must be negotiated, a method for taking contracts and negotiations online is provided in accordance with the invention. In one embodiment, by following a four-step process, users are able to configure dynamic negotiation environments based on the negotiable items of any contract or agreement. Below is the core workflow of an embodiment of the process:
This process may be implemented as a tool, feature or service in accordance with the invention termed the CROOMER® service or tool (herein “CROOMER® tool”), which gives rise as well to relative terms such as: “to Croom”, “Crooming”, and a “Croomed Contract”, etc., indicating that a negotiable document has been processed using the CROOMER® tool. Depending upon a particular implementation of the invention, it may be desirable to control use of the CROOMER® tool through system permissions as reflected in step/process 302 in
Continuing with the above example, the Manager has only activated his/her CONTRACTROOM® Account, as shown as a flow diagram in
In order to have the Residential Lease contract made available for use in CONTRACTROOM®, the Manager has chosen to email a Microsoft® Word® or other format copy of the original contract to the staff at CONTRACTROOM® to be processed in the CROOMER® tool. For illustration, the term “Publisher” is employed to denote a CONTRACTROOM® employee in this example, or another party that digitizes the contract, who is using the CROOMER® tool to process a client's original contract.
In one embodiment, as shown as a data flow diagram in
In the illustrative embodiment, when beginning in the CROOMER® tool, the Publisher will be directed to the CROOMER® Dashboard 200 which from a user interface standpoint, acts as a functional starting point to Croom a new contract, as illustrated in
In this illustrative embodiment in
In one embodiment, the order of operations set forth in this step is as follows: The next step in the Crooming process is to create negotiable item via, in one embodiment, a method 500, which corresponds to step 408 in
In continuing with the example, the Publisher will begin by adding, naming, formatting, and tagging items. Steps/processes 502-506 reflect actions with respect to specific fields that may be filled out, negotiated upon, and approved by both parties in the actual negotiation. Looking at an example of a Residential Lease in CONTRACTROOM®'s Negotiation Engine, a Category name may be “Property Info” (see
At any point, the Publisher can make modifications by making selections as seen in the illustration 600 in
Finally, the Publisher may need to set the publishing settings as shown in step/process 610 in
The “Croomed Contract” will be made available in the Contract Owner's (i.e. Manager's) account. The original negotiable document is now a dynamic, negotiable negotiation environment that is compatible with all of CONTRACTROOM®'s functionality. With reference to
To do this, he/she will set the appropriate permissions by proceeding to a “Permissions” page where such permissions can be verified in step 804. The manager selects the appropriate Croomed document in step 806 and a specific, unique name for the negotiation environment, and then is prompted to create the negotiation team by adding users to the environment in step 810. There are different roles that users will be assigned during a negotiation, which is handled by the Enter Collaborators' Data step 812 and then defining and assigning the appropriate roles and permissions for each individual or team member in step 814.
Although the functionality of the roles described in the narrative will remain the same, the naming conventions for the roles may change. For the time being, think of “Team Leaders” as the lead player in a negotiation. By making each of the Sales Associates a Team Leader for the negotiable document, the Sales Associates will be able to create, structure, and manage their own negotiations, and the business and legal process flows using that negotiable document environment. Immediately after the Manager adds all of the Sales Associates to the contract, an email will be sent to each of the Sales Associates alerting them that a negotiable document is available in their Contract Library (
In the example, the Sales Associate will use this data-based, negotiable document template/canvas to create a negotiation in a “Contract Room” environment. A “Contract Room” environment is the name given to the environment that hosts a single negotiation session or instance. This is different than CONTRACTROOM®, which denotes the entire platform. Therefore, Sales Associates may have several Contract Room environments in CONTRACTROOM® relating to several different negotiations.
When a Sales Associate signs into his account, he will first be directed to his dashboard (
Returning to
Following the creation of a Contract Room environment, the subsequent workflow of the actual negotiation works in a way that allows the players in each team to work as a team, communicating with one another internally in order to come to a consensus (steps 828-866) as shown in
The next step is to perform the negotiation. Access to the Contract Room environment is sent to the Team Leader's (Sales Associate's) team for an internal negotiation and collective approval of the terms. The players in the team will receive an email and be directed to the negotiation. The negotiation is structured according to the “Categories” and negotiable “Items” that were defined in the Crooming process and the Create a Contract Room environment process, thereby providing a digital structure to what in the industry are commonly unstructured negotiations. On an active negotiation page, the Categories work as tabs on the left side of the negotiation environment and indicate to the user the status of that category in the negotiation (
The counterparty will be taken through a very similar business and legal process. The Team Leader of the counterparty will first build his team and assign player permissions in steps 836-838. The counterparty will now perform internal negotiations agreeing or disagreeing with the terms put forth by the Sales Associate's team. If a negotiator on the counterparty disagrees with a negotiable item and makes changes to the contract, then the applicable players on the counterparty must agree to the changes (steps 854, 862). Once again, only after all of the negotiable items are agreed upon internally will the negotiable document be sent to the other party. This back-and-forth cross-party negotiation workflow will continue until both parties agree on all of the negotiable items, or the negotiation is withdrawn by the Team Leader (step/process 908). At any time during the negotiation, the Team Leader can review the negotiation history (step/process 910) add or remove players (step/process 904) to the negotiation, as well as preview (step 912) and withdraw (step 908) the negotiable transaction. If both of the parties agree on all of the terms, then the Team Leader can initiate the final execution process by sending (step/process 902) the negotiable document into the signature process (
To finalize the agreement, the negotiable document is legally executed through the use of Electronic Signature capabilities. E-Signature tools in accordance with the invention are designed to make negotiations easy, while upholding the fidelity of the negotiating and contracting process. As noted above, when all of the points in the negotiable document are completed, the negotiable document will become available for Signatures and Initials (
CONTRACTROOM® has a robust metrics component (
Since the system gathers data from transaction activity and publication of the final understanding and/or agreement, it is able to process and analyze such data real-time and subsequently stream processed information, or rather, business intelligence to negotiation participants or other stakeholders. The system can also extend negotiation workflow post-execution to interface and deliver real-time data to other technology solutions within an enterprise so as to report on user activity or provide financial, management, and performance metrics, or other user-defined analytics.
CONTRACTROOM® verifies users and authenticates contracts using technology that enables users to: trust the legal admissibility of the contract, protect against negotiable document fraud and forgery, look-up and cross-reference a printed, emailed or downloaded negotiable document against the authenticated negotiable document that is stored in CONTRACTROOM®'s secure cloud databases at any time, track who has looked-up and viewed the contract, authenticate contracts for third-party affiliates, demonstrate to customers that the negotiable document owner or general business is concerned with security and credibility, as well as rely on CONTRACTROOM®'s trusted services and network to securely store and endorse their sensitive business contracts in steps 890-892 in
CONTRACTROOM®'s mission is to be the global standard in virtual negotiations and to transform the business and legal process involved in negotiable transactions. To attain the highest levels of negotiable document authentication, CONTRACTROOM® uses a method of first verifying and securing the user through a login process, then authenticating user's electronic signature, and authenticating the contracts with a Trust Seal. The user's login and electronic signature can be authenticated in incremental levels by adding unique identifiers that increase the accuracy of the user's identity and actions.
CONTRACTROOM®'s system automatically archives all negotiations and contracts with a history and audit log. This allows users to keep track of all negotiating and contracting activities. Accordingly, all of a user's executed contracts are stored in a digital format on CONTRACTROOM®'s secure databases with an accompanying history to the user's account (
Every CONTRACTROOM® Authentication Seal has a unique barcode embedded in it. The barcode may be in the form of a QR Code (Quick Response Code), standard UPC (Universal Product Code), both types of barcode or potentially other barcode or other identification technology for increased compatibility. The barcode correlates to a single negotiable document that has been authenticated against CONTRACTROOM®'s Trust Seal requirements and is currently being stored in CONTRACTROOM®'s databases. When the negotiable document is printed or downloaded from CONTRACTROOM®'s website, CONTRACTROOM®'s authentication seal is automatically added to every page in the negotiable document like a watermark. Using this barcode and a downloadable barcode scanner application, or potentially any smartphone camera, the actual negotiable document can be pulled from CONTRACTROOM®'s secure databases for viewing on a wireless or mobile device. This way the printed or downloaded negotiable document can be compared for exact authenticity against CONTRACTROOM®'s secure records.
As discussed herein, a system and method of the invention further seeks to provide, in a comprehensive platform for transaction management, a system and method for collaborative drafting of a negotiated document. In one embodiment, as shown as a flow diagram in
In this illustrative embodiment, the method 1202 begins with the counterparty. Following initial negotiations, and a review of a document created by the “Contract Originator (
The Counterparty (not “contract originator”) now has the ability to highlight (in yellow) an area in the document's preview. Once the area has been highlighted, a modal box appears, which may be activated in step 1208 of
The Contract Originator who is designated as negotiator must address each Change Request. User has two options: to Okay (step 1218a) or Not Okay (step 1218b) the Request (
If the originator designates the change request as Not Okay (1218b), a modal box will appear allowing the Negotiator to enter a Counter-Comment, and the text highlighted in red turns to yellow. If the Contract Originator has a team with another negotiator, each negotiator must go through the same change request approval process. Comments may be viewed or added (steps 1220, 1238) along the way. Once all negotiators have agreed upon each change request, they will be sent in step 1222 to the counterparty for viewing in step 1224 of the originator's comments, Okays and Not Okays.
An iterative process 1226 may then ensue, during which the comments and “Not Okays” are approved or not approved and further negotiated, as necessary. Specifically, as above, the counterparty that is designated as negotiator must address each Counter-Comment. User has two options: to Okay or Not Okay the Request. If the counterparty Okays the change request, the text highlighted in red or yellow turns to green. If the counterparty does Not Okay the change request, a modal box, similar to illustration in
Once all counterparty negotiators have agreed on each change request, the Contract Originator may see the counterparty's comments, “Okays” and “Not Okays”, after they are transmitted to their side in step 1228 of
Only the Contract Originator and/or a team member who is the designated Author/Editor is granted rights for a redraft. Now that the status of all change requests have been changed to Pending Changes, the authorized Author/Editor can now see a list of pending changes in step 1232). The Author/Editor reviews each Pending Change and inputs/incorporates the requested text change into body text of the agreement in step 1234.
The Editor/Author's changes are then sent in step 1236 to, and then approved by, authorized team members if Editor/Author is working with a team, or becomes available for the counterparty to Okay or Not Okay. This iterative process as described herein and further illustrated in step 1238 proceeds until a consensus is reached. The text that has been changed now appears with yellow or red highlights, depending on who is viewing. Red indicates that the user has a pending action. Yellow indicates the user does not have a current action, and that the next action is pending on another user in that negotiation.
As reference, any or all approved users may be provided access to a History (method 1000) and all associated changes (
The dynamic transaction management system and method herein disclosed might be implemented in any of a variety of ways, depending upon a particular application, among other variables. In one embodiment, the features of the invention are incorporated into software, in the form of modules or otherwise, as would be readily appreciated by one skilled in the art. SaaS denotes a computing environment where multiple customers access the software application over the Internet (
Countless other features as well might, within the scope of the invention, differ from the embodiments described herein. For example, while described in context of a full-featured contract management system, real estate contract, or other specific type of document, etc., the invention might be applied to any other field, and any other transaction as well in which the disclosed features might find utility, e.g., where terms are negotiated or otherwise evolve over time, where a history of the same is important, where issues of document security are involved, etc. A system and method of the invention might also be offered as, for example, a stand-alone method or service or for incorporation into any suitable system. Furthermore, the invention is not limited to authoring of a negotiated contract, but rather might find applicability in countless environments in which multiple parties are collaborating in any of a variety of ways on a document. While the term “document” is used herein to denote an item of interest to be authored, the invention is not limited to physical manifestations, but rather could take any form, electronic or otherwise.
As a means of illustration, screenshots of webpages and logic flows of embodiments of the invention are provided. The description may reference an individual step in a flow diagram, but need not be limited to a single step; rather, the referenced step may be a series of steps or otherwise comprise a more detailed process or procedure. Depending upon a particular application, however, variations are contemplated in aesthetic presentation, organization, and even logic flows and decision trees, without departing from the scope of the invention.
This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application 61/646,239, filed May 11, 2012, and entitled System and Method for Dynamic Transaction Management, and U.S. Provisional Application 61/723,362, filed Nov. 7, 2012, and entitled System and Method for Collaborative Authoring, each of which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61646239 | May 2012 | US | |
| 61723362 | Nov 2012 | US |
