AU2014100601A4 - Meeting Management and Project Management Element Reconciliation - Google Patents

Abstract

This invention provides an improved solution for accurately importing and integrating into a Project Register relevant project register data recorded within meeting minutes, using a design and method that ensures the data imported from the minutes of a meeting does not produce erroneous data within the project register items, nor corrupts the documented minutes of a meeting. Specifically, the system allows revising and editing the minutes of meetings, even whilst the project register items continue to evolve independently of the recorded meeting minutes, and seamlessly reconciles data between these elements. 1200 Computer Display Memory Computer Meeting Application 1204 11 1214 Project Module Contact Module User CPU Search Module Minutes Module Computer 12 1208 1222 1208 PROJECT ITEM MODULES: Action Module Issues Module Risks Module Change Orders User I/O Interface Module 1206 1236 DecisionsModule Documents Mod 1244 ule Dashboard Module User 1246 1238 1246 1238 Op rating Sy stem Database I/O Devices Storage Figure 12 System Diagram 120

Description

1 MEETING MANAGEMENT AND PROJECT MANAGEMENT ELEMENT RECONCILIATION Technical Field [0001] This invention is a software and computer system for the recording of the minutes of meetings in a computer database and the export of the meeting outcomes to a central project register for collaborative management. [0002] Meetings which have outcomes that need to be addressed further after a meeting all face a similar problem that is, how to efficiently and effectively follow up on all the outcomes agreed upon within a meeting and ensure that they have been completed. Traditionally, the two most commonly used methods involve: 1) Meeting Minutes, a summarized record of the proceedings at the meeting, are recorded and then distributed to meeting participants and relevant parties to enable follow-up. 2) Subsequent meetings are used to evaluate progress of previous meeting outcomes. Traditional methods for meeting follow-up have significant issues. One meeting outcome that is very pertinent to further exploring these issues are the tasks assigned by the meeting, the so called "actions" or "action items", and these will be used as a representative meeting outcome within this section. [0003] If a person in an organisation was to attend ten different meetings in a week, they would have to rely on their memory, or work through ten different minutes documents to find the actions for which they are responsible. Moreover, a manager who attends 20 different meetings a week, and asks people to do 100 different tasks, would have to analyse 20 different meeting minutes, and hold more follow-up meetings to verify progress. This follow up overload has a time and opportunity cost for all involved. [0004] Traditional methods of keeping track of all these actions are notorious for being ineffective and inefficient, in consequence individuals and managers may miss the follow-up of important meeting outcomes. To counter this, individuals often begin to make lists of the actions they have been assigned. Chairs of meetings or managers also do the same, detailing in lists the actions they have assigned. Some meeting minutes may even become giant lists of actions formatted in spread sheets. This style of minute taking is very common in the construction industry.

2 [0005] The challenge with maintaining individual lists is that an individual's action/task list isn't reconciled to a managers list. If an individual keeps track of delays, progress or completion of their tasks, this isn't automatically reconciled to their team members' or manager's list. Very quickly the task of maintaining up to date lists becomes time consuming. [0006] Software, such as client-server project registers, can be used to address this problem. The Project register can be located on a dedicated computer, the server, which acts as a central archive, where items such as actions, issues, risks, change orders, decisions, documents, etc. can be recorded. Other computing devices, the clients, can then retrieve this data by connecting to the server using the network connecting the clients with the server. Projects and programs have been using project registers for years. They significantly increase the ability of a management team to deliver a project in the shortest duration, at the least cost and with the highest quality. [0007] Meeting minutes are recorded in a meeting register, a tool that acts as an archive similar to the project register, that is designed to record and retrieve the meeting related content. To take advantage of a project register, the meeting outcomes could be recorded both in a meeting register and in a project register. The project register would then provide a facility for staff to be able to collaboratively work on the completion of the meeting's outcomes. [0008] To have a subsequent progress meeting on the outstanding outcomes, one could access the individual status for each of the required items in the project register and include them in the meeting's discussion. Any updates to these outcomes would be noted in the progress meeting's minutes, and the respective items within the project register would also be updated. [0009] While the above method is practically feasible, it is rarely used, for the reason that it requires the double handling of data. The more frequently meetings are held, and the larger the number of meeting outcomes being managed, the more laborious this process becomes. Eventually the time-opportunity cost outweighs the advantage of using this method. [0010] Due to the inefficiency associated with manually reconciling project registers with meeting minutes, the next big step in system design is to automatically integrate the minute taking and data captured in meeting minutes with a project register. In such a system, it would be possible to create or update project items within a project register, directly from a meeting 3 interface. This feature would be in addition to being able to update the project register item directly from its own interface. [0011] Prior art to date have focused heavily on the opportunities that are created by networked computer systems to replace the older video conferencing systems. This type of system is known as an Electronic Meeting System (EMS), Group Support Systems (GSS) and Group Decision Support System (GDSS). See Wikipedia "Electronic Meeting System" and also the section in the list of Citations. [0012] A structured meeting interface that uses a client-server design captures more additional meeting information in comparison to a free form text minutes document. The following paragraphs outline the large majority of the possibilities that are associated with Electronic Meeting Management Systems: [0013] Using a client-server network synchronous collaboration on all aspects of the meetings and its documentation, agenda and minutes production can be done. Participants can simultaneously see the meeting minutes being produced as the meeting progresses. (Curtis et al. US 8,266,534 B2). [0014] Individual parts of the meeting can be time stamped. For example, discussion on agenda item 1 might begin 2 mins and 20 seconds into the meeting, and end 7 minutes and 40 seconds into the meeting. The time stamping could be achieved through a manual interface requiring user input, or it could be achieved when a new agenda item is selected. (Braunstein et al. US 2005/0131714 Al) [0015] Content discussion in the meeting can occur in different forms. This includes formal threaded discussion, or live text chat around the meeting which becomes part of the meeting record. [0016] Audio and video contributions to the meeting have also become part of the meeting record. Participants can pre-record contributions to the meeting or record live video conference feeds as well.

4 [0017] A centralised storage is used for storing and retrieving electronic documents associated with the meeting, where meeting participants are granted access to either read or contribute documents to the meeting record. [0018] Documentation of the meeting can be assisted through the use of the audio file to produce a complete transcript of the meeting. This could be done manually or using an automated process. Such a transcription could also be used as the basis to produce the actual minutes of the meeting. (Poirier. US7047192, Din. US6754631, Doyle et al. WO2006089355A1 and Adams et al. US6100882) [0019] Meeting content publication: Using all the additional information gathered on the meeting, this can be used to build a complete record of the meeting. The output of such a record would utilise various formats such as XPS, PDF, DOC, DOCX, HTML. A more intricate output might build a record with a web-based portal that had a common page for the meeting with sections for all of the information collected. One example of prior art in this area is MinuteTraq, released by IQM2. [0020] Meeting content can also be exported to other software packages for content presentation or further analysis. This might include scheduling software, presentation software, calendar software, etc. [0021] There are many software packages that produce minutes and simple task lists from the minutes. However, there are only a few systems that are known to the inventor, that have produced solutions to accurately address the reconciliation issues that occur between the meeting minutes and a project register. [0022] One existing software package known to the inventor is the LOTUS NOTES (trademark of the IBM Corporation) application TrackMeet by Kolaco Inc. In this software, when the meeting minutes are published, the action items in the minutes are exported to the project register. The software can automatically construct an agenda for the next meeting by importing from the project register the action items still outstanding from the last meeting.

5 [0023] Any updates to the imported action items are recorded during the meeting. When the new meeting minutes are finalised and published, the imported action items are exported back to the project register as a new version of the action that includes the meeting changes. The more meetings held regarding a particular action, the more versions of the action are created in the project register. Each version created is directly linked to its relevant meeting. If there are changes to the meeting minutes, they are propagated to the project register version. The result is that the project register now has multiple action items recorded for the one package of work (one action), and the history of an action is split across multiple action items. [0024] This system is very inflexible as it requires a meeting to be held and minutes published to maintain the action items in the project register. As meetings also create multiple action items for a single package of work in the project register, this software's method makes it more difficult to use. [0025] Another software package known to the inventor is the Layer2 Gmbh "Meeting Manager for SharePoint" software package, which uses the file versioning that is built into SHAREPOINT (trade mark of Microsoft Corporation) to record changes to action items. Since the versioning is controlled by SHAREPOINT, any change to the action item results in a new version being created. Using this type of versioning will almost always result in a loss of synchronisation between the Meeting Register and the Project Register, which will be demonstrated later. [0026] The pertinent point is that none of the existing solutions have overcome the technical difficulties of actually integrating meeting minutes with a project register, whereby the meeting can both create and update action items within a project register without producing duplicate or erroneous data. Technical Problem [0027] The value of a project register is its ability to accurately follow up on items retaining data integrity. In essence, if a project register is going to integrate with a meeting minutes interface, it has to be done in such a way that it does not inappropriately change the data within the project register's items and consequently produce erroneous data. It is the data within a project register that is used to generate management reports and guide decision making.

6 Starting from the project register, the inventor worked backwards to establish how to capture and integrate data from meetings accurately. There are two key enabling steps to ensure the data remains accurate within project register items, while receiving changes to their details (i.e. updates) from a meeting interface. Firstly, the system needs to accurately capture the required data for the project register item from a meeting. Secondly, the captured data needs to be appropriately integrated within the project register item. [0028] Data Capture from a Meeting: Designing the system to capture the relevant data from meeting minutes requires inventiveness. While, meeting minutes are traditionally recorded in a free form text document, the back-end of a project register is a database. To update the project register, a design/method is required to identify within meeting minutes the relevant database records. Although challenging, there is prior art in this area that outlines various methods on how to achieve this. [0029] Data Integration from Meetings: The integration of the captured information and its use that does not compromise the integrity of a project register's data is complicated. There is currently no known prior art or known implemented method that outlines a successful method to address the problems that are raised by integration. [0030] Existing prior art( see citations section "Electronic Meeting Systems" ) is rather heavily concentrated on the possibilities for synchronous or asynchronous collaboration between participants in an electronic meeting system, where the focus is on the meeting and its capabilities. In contrast, this invention has a project management focus. Starting from the project register, the inventor identified data reconciliation problems within meetings, and developed methods to integrate the project register with meeting minutes without compromising the accuracy of the project register. [0031] Prior to describing the invention, it is necessary to describe in detail the elements being integrated and their requirements as well as the challenges with integrating these elements. In order, the items discussed will be: 1) Project Register Items. 2) Meeting Items. 3) Integration. [0032] Project Register Items Overview.

7 [0033] There are five key concepts that need to be addressed to understand relevant details about project register items (also referred to as project items); and any project register must address them to achieve successful integration with meetings items. Firstly, that all project items must use the same layout structure and support functions. Secondly, project items must store their key relevant data. Thirdly, that project items can evolve. Four, there should be a clear difference between a project register items' details and its progress updates, and it is important to know what an update refers to. Finally, it's important to understand the consequences to ordering progress updates if the items details were to change. In order of discussion, these project register item concepts are: 1) Layout Structure and Methodologies. 2) Information Stored. 3) Project Register Items Evolution. 4) What Updates Are 5) Changing a Project Item's Details. [0034] Concept 1 - Layout Structure and Methodologies: Examples of project items include action items, issues, risk items, change orders items, decision items, electronic documents, etc. Although project register item types capture different information, their overall structure, the way they represent data and the rules to update their data must be similar. [0035] Concept 2 - Information Stored: Project items should comprise relevant information. For example, there can be a number of details that a user would want to know about an action item. Firstly, as a minimum they would want a description of the action to be completed, who has been asked to complete the work and by when. Then they might want to know, who requested the action to be done, how critical it is, and see any attached documentation supporting the work to be completed. All of the examples above describe, so called project item properties: details of information related to a project item. In case of an action item, the action item properties or details comprise: a description of the action, a responsible, a due date, a requestor, its status, etc. Similarly, a decision item will need to store pertinent information about the decision, including who made it and when. [0036] Concept 3 - Project Items Evolve: The next key feature about project items is that they need to be able to evolve over time. For example, an action might begin with a due date of next month with the responsible person being Mr X, and later be changed to have a due date of two months with the responsible person being Mr Y. Accordingly, an action item needs to clearly display the most recent action details (also referred as action properties) and the history of an action item's details over time.

8 [0037] Concept 4 - Before discussing ways of managing and sequencing project item information, it is important to understand the difference between a project item's details, and a project item's progress updates, and what an update refers to. Consider an action item; its details define the package of work to be done, and progress updates note on the action item's progress to completion. [0038] Project Item Update: when a meeting minute or a project register updates a project item, the word "update" refers to two possible options. The update could be changing an action item's details (Example 1), or adding a progress update (also referred as a progress comment or comment) (Example 2), or the update could be doing both (Example 3). [0039] Example 1: This is an example of an update that changes the action item's details. The Action item details might be: "Pour some concrete, due date is the end of next week, responsible Mr. X"; and the progress update 1 might be: Mr. X comments, "I really can't get this done by the end of the week, please reassign if possible". Reassigning the action to someone else will result in a change in the action item details. Action item details update: "Pour some concrete, due date is the end of next week, new responsible Mr. Y". [0040] Example 2: This is an example of an update that is a progress update. The action item details might be: "Pour some concrete, due date is the end of next week, responsible Mr. X" and the progress update 1 might be: Mr. X writes, "I need more help to get this done by next week" and the progress update 2 could be: Mr. X writes, "Mr Y says that he can help me" [0041] Example 3: This is an example of an update that changes both the action's details and adds a progress comment: The action item details might be: "Pour some concrete, due date is the end of next week, responsible Mr. X" and the progress comment might be: Mr. X comments, "I need more help to get this done by next week". Reassigning the action to someone else results in a change in the action item details. Action item details update: "Pour some concrete, due date is the end of next week, responsible Mr. Y". This may be accompanied by a comment update: Mr. X comments, "Mr Y says that he can do it on time". [0042] Concept 5: Changing a Project Item's Details: Looking at the above example, it is important to note that if an action item's details were to change, then any progress updates that 9 had been made in reference to the old details, may no longer apply to the new details. This is an important concept, and will be revisited later in the Solution Section. [0043] Meetings Items Overview. [0044] There are three key characteristics of meetings that affect their integration with a project register. 1) Meetings go through phases. 2) Meeting minutes can be produced at different times relative to the time when the meeting actually takes place. 3) Capturing meeting minutes to allow for their integration with a project register database. 4) The challenges involved in saving a structured document to a database. [0045] Concept One - Meeting Phases: A formal meeting goes through stages over a period of time, and the meeting's minutes are progressively produced. There is: 1) Inception of a meeting by the originator. 2) Meeting invitations are sent to participants with a proposed agenda and 3) Agenda feedback is obtained (if required) and finalised in preparation for the meeting. 4) The meeting is held. 5) The meeting minutes are produced. 6) Meeting minutes feedback is obtained (if required) and finally. 7) The minutes are finalised as the official record of the meeting. An informal meeting might skip most of these stages. For example, an impromptu meeting could be called, the minutes taken live and sent out at the end of the meeting as final. [0046] Concept Two - Meeting Minutes Production Time: Meeting minutes can be produced live during a meeting, or they can be produced retrospectively for a meeting that has already taken place, a past meeting. Alternatively, they can be produced in draft for a meeting that has not yet taken place, a future meeting, with final revisions occurring after the meeting. The importance of this will become clearer when analysing data integration from meetings. [0047] Concept Three - Capturing Structured Meeting Minutes: The third element required for an integrated meeting - project register system is to understand how to arrange a meeting interface in such a way that it can produce meeting minutes and also accurately capture the data required to be exported into a project register database. [0048] Software users would likely prefer to use the most traditional method of capturing minutes, which is using a free form text document that is structured entirely at the discretion of 10 its author. As a project register is a structured database, the system would need to identify within the custom text document the field values required. Unfortunately, this is nearly impossible as the export field identification script (e.g. Allen et al. U.S. Patent 7,146,381) that scans the document can never be 100% sensitive and specific. The system would therefore identify for export things that were not meeting outcomes, and miss others that should have been captured. This would then require a meeting participant to check the exportation list, and remove incorrectly identified meeting outcomes, and add those that were missed. [0049] Any effective system design consequently has to diverge from the conventional method of recording minutes in a purely free form text document, to using a software interface that is capable of capturing the minutes in a more structured manner. This more structured method allows accurate identification of the meeting outcomes within the minutes that are ultimately exported to a project register for follow-up. The following paragraphs outline the known methods to capture the meeting outcomes in a structured manner: Method 1: Free form text and structured lists, Method 2: Hierarchical meeting minutes, Method 3: Free form text with embedded objects, Method 4: Free form text with hierarchical embedded objects. [0050] Method One: Free Form Text and Structured Lists. One of the simplest methods is to have a meeting window that has a section for free form text, and then has separate sections to record meeting outcomes. To produce the minutes, the system appends to the free form text the list of outcomes. It then exports to the project register the meeting outcomes for tracking. An example of such a commercial package is Kolaco Inc's "TRACK MEET". [0051] Method Two: Hierarchical Meeting Minutes, Braustein et al. (US 2005/0131714 Al), describes making a meeting minutes document that is made up of individual meeting outcomes organised sequentially into a hierarchical tree. For example, a hierarchical tree may contain an agenda item (level 1), with a "child" element that is a meeting outcome - a decision (level 2), which in turn has 3 more "child" meeting outcomes - 2 action items (level 3) and 1 risk item (level 3). With each part of the meeting recorded in its elemental blocks, the system can produce a meeting minutes document, and export the relevant meeting project register outcomes to the project register. [0052] Method Three: Free Form Text within Embedded Objects. It is possible to use a free form word processing document that is specifically designed to allow for embedding 11 meeting outcome objects. For example, a user who has written up meeting minutes in a free form word processor could drag into their document an action outcome object that has several mandatory fields that must be completed. The object would be nestled within the document like a table or a picture, but it would be specifically designed to link to the project register database. The meeting minutes would be produced as per the free form document. (Moran et al. US 6018346 A). [0053] Method Four, Free Form Text with Hierarchical Embedded Objects: It would also be possible to have hierarchical meeting outcome objects embedded within a free-form document, enabling exportation of meeting outcomes with their relationship to each other captured. The meeting minutes would be produced as per the free form document. [0054] Irrespective of the method selected, these structured systems can accurately capture the details of new meeting outcomes, or updates to existing project register items. Before looking at the relationship between meeting minutes and the meeting outcomes captured, and their integration with a project register, it's important to understand more about project register items. [0055] Concept 4 - Structured Meeting Minutes and Saving: One of the final challenges of capturing meeting minutes in a structured form is saving the data. In a free form document a user can save the content whenever they want. If a structured method is used to capture project register data, the objects within the meeting object have certain fields that must be completed before a document can export its relevant content. Therefore, the challenge of this system design is how to let users save their document at any time, without introducing errors into the project register from incomplete objects. [0056] Understanding Integration. [0057] A meeting management - project register system needs to be able to document a meeting accurately and be able to interface with a project register and have the capacity to: 1) Create a new project item within a project register. 2) Update/close an existing item within the project register. 3) Handle the revision of meeting minutes and any consequential changes to the project register.

12 [0058] These tasks need to be achieved whilst ensuring that the data in the project register is accurate and reflects the natural workflow of project items. To achieve this, the core ideas in the relationship between meeting minutes and project items need to be addressed. These elements will be discussed in the following order: 1) The relationship between Meetings and their outcomes and Project Items. 2) When to Export Meeting Project Register Outcomes. 3) Project Item - Meeting Item Integration Problems. [0059] The relationship between meetings, their outcomes and the project register items: Meeting minutes outcomes are stored in the meeting register as part of the meeting minutes. When exporting a meeting minutes outcome to the project register, the system creates an independent project register item for each corresponding meeting minutes outcome noting the relationship. Therefore, the meeting minutes outcomes in the meeting minutes and their corresponding project register items in the project register are related, but they are two separate objects. [0060] Some systems create a two-way link between the meeting registers and the project items. Therefore, if you subsequently change meeting minutes you automatically change the project item. This may seem ideal but it has the unacceptable side effect: if you change the project item directly in the project register, you inadvertently change the minutes of the meeting. In effect, the meeting minutes are no longer an accurate record of the meeting. [0061] When to Export Meeting Project Register Outcomes: Another key idea considering meeting and project item integration is when a system should export its meeting project items outcomes to the project register. One approach is to export them after the meeting minutes have been published in their final form. At this point in time, the quality of the data in the meeting minutes is at its highest, and it is unlikely to change. This way, people following up on meeting outcomes in the project register have a high level of confidence that the meeting outcome, they are assigned to follow up on, will not change. [0062] The reason not to follow this option is because often it can take weeks for minutes of a meeting to be finalised, and in reality people start working on actions as soon as they have been publicly assigned (e.g. in a meeting, or notified). Any system of value needs to support natural work flow, so project items discussed in a meeting should be exported to the project register before the finalisation of the meeting minutes.

13 [0063] Project Item - Meeting Item Integration Problems: By using any one of the four structured meeting methods outlined previously to capture a meeting's project register item outcomes, the captured data can be directed to its relevant project register item. The project register item should also be able to accept the updates. The details and updates of the item need to be arranged and presented in a way, where the most recent project item details (also referred as properties) and its past history are accurately displayed, while adhering to the natural workflow of the project item. As we shall see shortly, this is quite difficult. This is because the design of such a system needs to overcome four specific design challenges produced by meetings. 1) Minutes are produced after a meeting. 2) Future Meetings. 3) Multiple updates from a meeting. 4) Corrections to minutes. [0064] Problem 1: Meeting Minutes are produced after a meeting takes place. [0065] Meeting minutes are rarely recorded live. They are usually produced after the meeting, and the quality of the meeting minutes improves over time as it is reviewed before being ultimately finalized. The outlined process has consequences for ordering updates within project register items. [0066] Many commercial project register packages sequence updates to project register items in the order that they receive them. Updates from meetings minutes and updates from the project register item's user interface would, therefore, be sequenced in the order that they are created. This causes problems when interfacing with meeting minutes, because as noted, meeting minutes are produced some time after the meeting, and an update at this moment does not reflect the natural sequence of events for a project item. [0067] To illustrate this problem we can consider a progress meeting. In this meeting, participants discuss new project register items and update old ones. Project register items are publicly discussed, and next steps are agreed upon during the meeting. Consequently, after the meeting, participants are likely to begin following up on the project register items they are associated with. [0068] However, meeting minutes are rarely produced immediately at the end of a meeting. Usually a meeting attendee takes notes on the meeting events, and then produces the minutes of the meeting at a later point. Relating this back to system design, the minute taker 14 exports the meeting's project register item updates to the project register, once the minutes have been produced. [0069] Because of this delay, meeting attendees might follow up on a project item before the meetings minute's update is exported to the project register. This introduces the opportunity for data inconsistencies errors to occur. During this time, a project item might receive a new update directly from changes made to the project register item or alternatively from a subsequent progress meeting. If this occurs, when the original minutes are produced and the project register item outcome updates are exported from the meeting, the project register item's updates become out of order and erroneous data is created. The longer the time between the actual meeting, and the production of its minutes, the greater the chance an error will occur. [0070] When a meeting outcome's content documented in a meeting item is exported to the project register, after the meeting had been held, said meeting shall be referred to as a "past meeting". [0071] Figure 1 - Past Meetings outlines this problem in more detail. A new meeting 102 is held and recorded in the system as 'Meeting Object 1 104'. An existing Action Item, 'Action X Object 106' in the Action Register ( a project register module for action items) is imported into the agenda of the meeting and is recorded as 'Meeting Object 1-Meeting Outcome Object 1 108'. As a result of discussions during the meeting, it is agreed that 'Action X Object 106' will be assigned the new date of the 30-Oct-2013. This change is recorded in 'Meeting Object 1 Meeting Outcome Object 1 108' and becomes part of the draft minutes of the meeting. No change will be made to the 'Action X Object 106' until the contents of the minutes are exported. Mr Jones decides the following day, before the meeting minutes are ready and their contained information is exported to the Action Register that he needs to change the due date of the Action Item to the 30-JUN-2013. He does this using the Action Item User Interface 110. This creates 'Action X Object - Update Object 1 112' within 'Action X Object 106' with the due date of 30 JUN-2013. This process updates the 'Action X Object - Properties 114'. The 'Action X Object' new due date is 30-JUN-2013. Subsequently the meeting minutes are exported 118 at 5pm, 4-APR-2013 and a new update object is added to the 'Action X Object' 106, the update 'Action X Object - Update Object 2 116' with the due date of 30-OCT-2013. Again the process updates the 'Action X Object - Properties 114'. The new Due Date is 30-OCT-2013. Anyone 15 looking up the Action Register for this item's due date will now find the action item's due date is not the most recent allocated and is therefore wrong. [0072] Problem 2: Future Meetings. [0073] Meetings that are yet to be held pose a similar chronology problem for ordering a project item's history. A common management technique is to draft a meeting agenda and distribute it, completed with new action items or current action items required to be started or done before a meeting takes place. In effect, the meeting chair (usually a manager) is inserting into people's task list items, the chair wants done without any prior discussion. Principally, the meeting participants will be people with assigned actions. Without determining whether this is good management practice or not, it is a common, thus, it needs to be supported by a meeting management system. As the meeting is set for a time and date in the future; the meeting chair needs to check on the progress of the actions before the meeting occurs. [0074] This technique poses chronology challenges for a project item's history: the project item updates are managed in the present for a meeting that will occur in the future. Nevertheless, it is imperative that the system models a project's natural work flow. [0075] When a meeting outcome's content documented in a meeting item is exported to the project register prior to the meeting being held, said meeting shall be referred to as a "future meeting". [0076] Problem 3: Multiple Updates from a Meeting. [0077] During a meeting, a single project item may be discussed multiple times with other meeting content discussed in between. Within the meeting minutes, to capture the multiple discussions about a single item, one could record all the different discussions consolidated in one meeting outcome, but this wouldn't be an accurate account of the sequence of events that occurred during a meeting.

16 [0078] Therefore, any meeting management system needs to be able to capture multiple updates for the same action at different points within a meeting. As follows, the meeting produces multiple meeting outcomes to be exported to the project register for the same project item. [0079] While addressing the issues raised by Problem 1 (Meeting Minutes are produced after a meeting) and Problem 2 (Future Meetings), the system needs to be able to receive multiple updates from the same meeting for a project item. Upon receiving this exported data, the system needs to be able to order the updates within the project item in the correct chronology as per the order in the meeting; and handle any consequential project item detail change from information contained in the multiple updates. [0080] Problem 4: Minute Revision. [0081] Altering meeting minutes that have already been exported introduces a problem of reconciliation. Although a project item is distinct from its related meeting outcome, both items are still related in content. Therefore, if meeting minute change, this still has to be reflected in the corresponding project register item. [0082] For example, if an action item was incorrectly noted in the meeting minutes as being due in two months, and this is exported to the project register, the action item now contains wrong information. If the minutes are revised after two weeks and the correct due date of one month is recorded in the minutes, this change needs to be exported to the project register to potentially update the relevant action item. [0083] Changes to an action item's details as described above, may cause subsequent progress updates that were created after the original update in the project item seem incomprehensible. Therefore, how items within project register are updated as a consequence of revisions to meeting minutes is crucial. [0084] The difficulty in revising minutes, exporting the change and integrating the data accurately, is that the exported change might need to modify some data that was created and became public knowledge in the past.

17 Solution to the Technical Problems [0085] How to accurately transfer data from meeting minutes to project register items, mitigating the integration challenges, is at the core of this invention. It was necessary to: [0086] Design project register item user interfaces, support functions, and invent a layout for their content that allows them to receive updates from both the project register itself and also from meeting minutes, integrate meeting minute revisions, and represent the current data as well as each item's chronological history accurately. [0087] Design a meeting item user interface and support functions, that could capture key meeting information and minutes, whilst identifying the relevant project register outcomes, and invent a method that allows the meeting minute's user interface to approximate the behaviours of a free form text document, save, while assuring the accuracy of the data being passed to the project register item's database tables. [0088] Invent a process to ensure that data being passed from a meeting item to the project register item does not update the project register item in an inappropriate way, producing erroneous data. Advantageous Effects of the Invention [0089] This invention provides an improved solution for managing a meeting and its outcomes in the Project Register. It allows a Project Register to be maintained with accurate data on projects and also integrate Project Register data from electronic meeting systems without producing inaccuracies in the Project Register or the Meeting Minutes Register, while maintaining the natural and most accurate workflow of the project item updates. Description of Drawings Figure 1 Past Meetings Figure 2 Meeting Minutes User Interface with Action Item 18 Figure 3 Project Item Versioning with Updates vs Single Project Item with Updates and Audit Figure 4 Past Meetings - Rule Number 1 Figure 5 Future Meetings - Rule Number 2 Figure 6 Multiple Updates - Rule Number 4 Figure 7 Overwriting Project Item Updates Figure 8 Append the Progress Updates Figure 9 New Action Item Updates as Children of the Parent Update Figure 10 Sequential Updates Figure 11 Flow chart with integration and layout methodologies Figure 12 System Design DESCRIPTION OF THE EMBODIMENTS [0090] Various aspects are now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of one or more aspects. It may be evident that the various aspects may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing these aspects. As used in this invention, the terms "component", "module", "system", "register" , "audit trail" and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and 19 software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Various aspects will be presented in terms of systems that may include a number of components, modules and the like. It is to be understood and appreciated that the various systems may include additional components, modules, etc. and/or may not include all of the components, modules, etc., discussed in connection with the figures. A combination of these approaches may also be used. The various aspects disclosed herein can be performed on electrical devices including devices that utilize touch screen display technologies and/or mouse-and-keyboard type interfaces. Examples of such devices include computers (desktop and mobile), smart phones, personal digital assistants (PDAs), and other electronic devices both wired and wireless. [0091] The invention consists of a meeting-project management software system configured to run in a client-server arrangement, using computing devices, mobile computing and server hardware. The innovation of the system is its ability to accurately capture data from documented meeting minutes, and then integrate that data with a project register whilst maintaining the integrity and accuracy of both meeting minute's records and the project register's entries. As outlined in the background, this required a detailed understanding of the complexities produced by meetings, and their subsequent integration with a project register. [0092] The server part of the software is composed of two main software components. The first component is the server software running on hardware that is capable of managing the communication between client software and the system's database. The second component is the systems database running on a database server. The database server can be running on the same server as the server software, or it may use its own dedicated hardware. [0093] The client software is a client application running on a personal or laptop computer. The software can also be used on a single computer which runs all of the three components, the server, the database and the client application.

20 [0094] As the system is configured to use a client-software arrangement, the system is able to support the development of further client software, in particular for mobile devices, smart tablets and a web-based thin client. The system communicates between the server and the client using secure encrypted communication. [0095] The integration between the client software and the server software is configured to enable the features that are outlined below. [0096] The design of the system is such that it is comprised of modules. The modules are a way of grouping and managing related content. For example, an action item module, would be made up all the user interfaces, methods/functions and related database tables required to record an action item and manage its content in unison with the other modules. There are three different types of modules: the management modules, the configuration modules, and the information modules. [0097] Management Modules: The management modules are made up of the meeting module and the project register item modules. The system is designed to allow for expansion and the addition of additional project register modules, and they would use the same architecture and methodology as the others. [0098] The Meeting Module: The meeting module is comprised of all the meeting user interfaces, management methods/procedures, and database tables required to create, edit, store, retrieve, and display records of meeting. [0099] Project Register Module: The project register is made up of individual modules for actions, issues, risks, decisions, deliverables and change requests. Each module has user interfaces, management methods/procedures and database tables required to create, edit, store, retrieve and display records of the project item. [0100] The system also has two configuration modules: the Folders module and the Contacts module 21 [0101] Folders Modules: The folders modules allows for the creation of a hierarchical folder (directory) structure. The folder structure has a method to control use and access to folders. All items within management modules are allocated to a folder. Although items are still being stored in their respective module's tables, by using the configuration modules, the system can control access to items, and from the user's perspective, each item appears to be located within its respective folder. [0102] Contacts Modules: The contacts module manages the creation and editing of contact details, which can then be used throughout the system. The module is comprised of all the user interfaces, management methods / procedures, and database tables required to create, edit, store and retrieve for display contact records. [0103] The system also has information modules consisting of the dashboard module, and the search module. [0104] Dashboard Module: The system has a dashboard that is capable of being customised to display key data relevant to a user, drawn from each of the separate modules. [0105] Search Module: The system has a module that is capable of searching each of the other modules looking for relevant data. [0106] Reporting: Each module has functionality that produces a range of reports on each of its items. [0107] Integration Overview: As mentioned, the core of the invention is the process of accurately integrating information contained within - Minutes with information in a project register. To do that, there are three core elements involved: meeting items, project register items and the system's integration methodologies. Outlining how these elements work in detail explains how the system innovatively and accurately links meeting minutes with a project register. Each element relies on its software interface design, methods and functions, its corresponding database structures, the system's client-server communication structure and the hardware platform supporting the client and server software platforms.

22 The integration elements will be addressed in following order: 1) Meeting Items. 2) Project Register Items. 3) Integration Methodology [0108] Integration Elements 1 - Meeting Items [0109] Meeting Item Design Overview: To understand how a meeting is managed within the system, the core features of a meeting item are described: 1) How to create a meeting item within the system. 2) The general features of a meeting item. 3) How a meeting item user interface lays out its meeting minutes. 4) How the meeting item user interface specifically captures data for the project register from new and existing project items. 5) How and when the system exports to the project register the data contained within a meeting's project register item outcomes. This exportation occurs within the context of a meeting's life cycle and this should be explored first. Then the methodology of how the system performs the saving of a meeting item on the database server, and how that then allows for user collaboration, is covered. Finally, the meeting item reporting capabilities are described. [0110] Meeting Item Design. The topics will be covered in the following order: 1) Creating and Editing Meeting Items. 2) The General Features of a Meeting Item User Interface. 3) Meeting Minutes Layout Structure. 4) Project Register Item Outcomes. 5) Meeting Phases and Exportation. 6) Exportation Data Validation. 7) Saving Meeting Items. 8) User Collaboration. 9) Meeting Item Reporting [0111] Meeting Item Design Part 1: Creating and Editing Meeting Items [0112] Within the system, the creation and editing of meeting items is managed by the meeting module. The module can be instructed to create a meeting item from various sources, and likewise can be passed data to populate a new meeting item being created. The source of the instructions is the meeting module or the project register. [0113] Source: Meeting Module. New Meeting Item: From anywhere within the system, the program's user interface allows the user to create a new meeting. The instruction is passed to the meeting module to be executed.

23 [0114] Source: Meeting Module. Cloning a Meeting Item: to clone (copy) a meeting item, the user selects the item to be cloned in the meeting module, and then instructs the system to select the content from the old meeting for cloning. Then the system creates a new meeting populated with the content selected for duplication. [0115] Source: Meeting Module. Editing a Meeting Item: to edit a meeting item, the user opens the relevant meeting item from the meeting module and then makes their changes. [0116] Source: Project Register. Update Meeting: Existing project items can be selected from multiple project modules, and they can be used to create an 'update meeting'. This will be outlined in more detail later. [0117] Meeting Item Design Part 2: General Features of a Meeting Item User Interface. [0118] The meeting user interface is able to capture a range of meeting details. This includes information about the meeting, its logistical details, attendees, the minutes of a meeting and electronic copies of the relevant meeting files / documents. [0119] The meeting user interface runs on a user's computing device as part of the system. The user interface allows collecting or editing information about a meeting. When the user instigates the saving method on the meeting item user interface, the data collected about the meeting, is communicated by the client program from the users computing device across the relevant communication network to the system's server. The server running on computing hardware then processes the data and sends it to the database server. The database server running on the same or different computing hardware uses the data it has received to create a record in the relevant meeting tables of the systems database. [0120] Once the meeting item record has been recorded in the system's database via the server and the client program, it is visible to other users of the system that have access to the folder, to which the project register item was allocated. Multiple users can now access the same server record, and this allows for synchronous or asynchronous collaboration.

24 [0121] The meeting item user interface has five key functions supporting it: 1) Audit Trail. 2) Attachments. 3) Validation. 4) Snap Shots on Phase Change. 5) Related Meetings. [0122] Meeting Item Support Function 1 - Audit Trail: There is an audit support function which keeps a record in a separate database table of every single change made to the meeting item, when the change occurred, and by which user. This can be only be viewed by a system administrator, who is able to audit each individual change made to a meeting item. [0123] Meeting Item Support Function 2 - Attachments: There is an attachments support function which itemises all the attachments that are associated with any part of the meeting item. They are categorised as per their source and can be opened for viewing. [0124] Meeting Item Support Function 3 - Validation: As mentioned, the meeting item is stored in a database. Therefore, unlike a free form document which does not require any particular data to be entered, the database table design requires certain fields to be accurately completed at different moments of the meeting's life cycle. To inform a user about the information they might not have completed accurately, the meeting item user interface has a validation function. The function evaluates missing information and classifies it into three categories: 'Error', 'Warning' and 'Information'. It also flags the incomplete information field within a meeting user interface. As a system rule, the meeting cannot be saved to a meeting register while it has any errors, while the presence of warnings and information categories does not prevent saving. [0125] Meeting Item Support Function 4 - Snap Shots on Phase Change: When a meeting changes phases (see below: Meeting Item Design Part 5: Meeting Phases and Exportation ), the system takes a snap shot of the meeting item record. It is a copy of the meeting at the moment of a capture that can be accessed as an interactive user interface or statically as a PDF report. This allows a user to see a record of the meeting at each key moment of its life cycle. A practical example of this feature is as follows: Suppose a meeting is finalized. A snap shot is taken of the meeting. Then a user reopens the meeting for revisions, and edits the minutes and finalises the meeting again. If another user wants to know what has been changed, they can compare the two finalised minutes documents stored in the snap shot function.

25 [0126] Meeting Item Support Function 5 - Related Meetings: Meetings can be related to each other. For example, a team might have a recurring Monday morning meeting to go through outstanding action items. Meetings can be linked together in series at the discernment of a user. This function provides a space for a user to see what meetings are related to the current meeting, and open them. [0127] Meeting Item Design Part 3: Meeting Minutes Layout Structure. [0128] Capturing the minutes of the meeting can be configured within the system to use either of the following methods outlined in the background section: Method 2 - Hierarchical Meetings or Method 4 - Free form text with hierarchical embedded objects. [0129] Meeting Item Design Part 4: Project Register Item Outcomes. [0130] Using Method 2 or Method 4, the meeting minute's user interface is able to dedicate specific objects to accurately capture pertinent details regarding the project item's details. For each project item type (actions, issues, risks, etc.), there are two dedicated objects with different entry fields to capture meeting outcomes. The first object type creates new project items within its respective module, while another meeting object type is an update to an existing project register item within the project register. [0131] Meeting Outcome - New Project Register Item: The object within a meeting to create a new project item has fields available to capture data from the user regarding the new item. There are core fields that must be completed before exportation, and additional fields which are optional. [0132] Meeting Outcome - Update Project Item: To create an update object of a project item in the meeting minute's user interface, the system needs to know which item within the project register the user wants to update. There are methods to select the required project item within the system. Once the required item is selected, the details of the project item are imported into the meeting user interface. Referring to Figure 2, an imported project item in a meeting is shown as 'Meeting Object 1' 202. The details of the meeting object can be updated, and a progress update of the project item recorded 204. There are some core fields that must be 26 completed before exportation and additional fields, which are optional. This object becomes a record of the meeting, which can export its update back to the project register. [0133] Meeting Item Design Part 5: Meeting Phases and Exportation. [0134] As noted in the background, a meeting goes through several stages from its inception to the minutes of the meeting being published. In terms of the systems design, we have grouped these stages and called them meeting phases. Referring back to the background section for all the meeting stages, there are three meeting phases: [0135] Phase 1, Draft - Draft incorporates every moment of a meeting's life cycle right up to when the minutes of the meeting are produced, and marked as complete for review. [0136] Phase 2, Minutes in Review - This phases incorporates all the discussion and revision of meeting minutes until the meeting minutes are marked as competed. [0137] Phase 3, Minutes Produced - During this phase the minutes are complete and no longer open to further revision. [0138] As discussed in the background section, when a meeting item exports its data to the project register, this needs to occur at a moment that follows the natural workflow of items. As outlined, meeting participants potentially begin following up on meeting outcome items from the moment the meeting ends. This would be the ideal moment to have the minutes signed off and finalised, and export the meeting's action item outcomes to the project register. However, the meeting minutes are generally produced after the meeting takes place. More formal minutes are also reviewed after a draft is produced, corrected and signed off before the minutes are finalised. [0139] To handle these scenarios, the system has the three phases outlined above. The system exports to the project register its meeting minutes outcomes at the earliest possible moment where one might have some confidence in the quality of the data within the meeting minutes. This moment occurs when the note taker declares first draft of the minutes is complete, and corresponds with a changing of the meeting phase from 'Draft' to 'Minutes in Review'. If there 27 are any revisions to the meeting minutes during 'Minutes in Review', these will be managed by the system using methods outlined later in this section. [0140] Live Exportation: One could configure the system to export a meeting's project item outcomes to the register as soon as they are created within the meeting minute's user interface. Live exportation so to speak. Curtis et al. (US 8,266,534 B2) uses this design. However, this method has a much higher chance of introducing erroneous data into the project register. Consequently, the system defined in this invention waits until the meeting minutes note taker or meeting chair declares that the first draft of the minutes is complete. If the minutes are taken during the meeting and reviewed by the participants synchronously, the minutes might be marked first draft or final at the end of the meeting. Crucially, the system waits to receive this instruction. [0141] Meeting Item Design Part 6: Exportation Data Validation. [0142] Within a meeting document, only significant input errors can stop a document from being saved to the meeting register. Like all documents, it's imperative that the meeting user interface only signals an error on absolutely core data. Users need to be able to save their document with minimal restriction. [0143] Whilst the meeting is in the phase "draft", users can add project item meeting objects without completing most of the core fields, and nevertheless save their document. Incomplete fields within the objects will raise a warning within the meeting user interface validation tab, but cannot stop the document being saved. However, before exportation to the project register, these warnings need to be resolved. Without the meeting project item object's core fields being completed, the system would create erroneous data within the project register. [0144] To address this, the system has a method whereby, when the user progresses the meeting from "draft" to "minutes in review", the system checks to see if there are any errors before it tries to export the data to the project register. If there are warnings on the meeting project item, the meeting will save the meeting with its warnings converted to errors, and move the meeting into a "half phase" and adjust the system's interface.

28 [0145] In the half phase created by the fact that the meeting document now has errors, the meeting cannot be saved. At this point the user has two options: 1) The user can cancel the exportation and return the document to draft, converting the meeting project item errors back to warnings. Then the meeting can be saved again. Or 2) The user can resolve the errors. Once all the errors are resolved, the user can progress the meeting to 'Minutes in Review', which exports meeting's project item data to the project register. [0146] Meeting Item Design Part 7: Saving Meeting Items. [0147] When the user instigates the saving method on the meeting item user interface, if the validation module doesn't flag any errors, the data collected is communicated by the client program, from the users computing device, across the relevant communication network to system's server. The server running on hardware then processes the data and passes it to the database server. The database server, running on the same or different computing hardware, uses the data it has received to create a record of the meeting item in the meeting tables of the system's database. [0148] Meeting Item Design Part 8: User Collaboration. [0149] Once the meeting item has been recorded in the system's database, the record is now visible to other users of the system that have access to the folder to which the meeting item was allocated. Multiple users can now access the same server record, and this allows for synchronous or asynchronous collaboration. [0150] Meeting Item Design Part 9: Meeting Item Reporting. [0151] Meeting items have a variety of output methods. These include, the printed minutes of the meeting, summary of revisions to meetings, detailing of project register item outcomes. Also, utilising an email client, emails with meeting invitations, with agendas or meeting minutes for review can be sent out. [0152] Integration Element 2 - Project Register Items Design Overview.

29 [0153] To understand how a project item is managed within the system, the core features will be described. Firstly how to create or update a project item will be described followed by the general features of a project register item. Next the life cycle of a Project Register Item and how it lays out its information will be outlined, followed by how the system saves a project register item, and consequently enables multi-user collaboration, and finally, the details of the reporting options on project register items. [0154] These topics will be covered in parts and in the following order. Project Register Item Design: Part One - Creating and Updating Project Register Items. Part Two - User Interface Features of a Project Register Item. Part Three - The Life Cycle of a Project Register Item. Part Four - Project Register Item Layout Methodology. Part Five - Saving a Project Item. Part Six Collaboration. Part Seven - Project Register Item Reporting [0155] Project Register Item Design Part 1: Creating and Updating Project Register Items. [0156] Within the system, the creation and the update of project register items is managed by their respective modules. The modules can be instructed to create items or edit items from various sources, and likewise can be passed data to populate the new item being created. The two sources of instruction are: 1) The item's respective project register module and 2) The meeting module. [0157] Source: Project Register Modules - New Project Item: From within any of the project item module's, the programs user interface allows the user to create a new project item to be recorded within its respective project module. [0158] Source: Project Register Modules - Cloning a Project Item: To clone (copy) a project item, the user must go into the relevant project module, select the item to be cloned, and then instruct the program to clone it. The system assigns a new unique identifier to the new project item, while keeping the details data the same. [0159] Source: Project Register Modules - Adding an Update: To add an update from the project register modules, a user must go to the relevant project item module, find the project item that they wish to update, open the item, then interacting with the user interface, add an update.

30 [0160] Source: Meeting Modules - Creating Project Register Items: Within the meeting item user interface, in the Meeting Minutes section, there is a meeting outcome object to create a new project register item for each project register item type. The outcome object collects all the minimum information required to create an item within the respective project module. When the meeting exports its data, the item is created within the project register. [0161] Source: Meeting Modules - Updating Project Register Items: Within the meeting item user interface, in the Meeting Minutes section, there is a meeting outcome object to update each different type of project register item. These objects are different to the ones to create new items within the project register. The outcome update object collects all the minimum information required to update the selected project register item. When the meeting exports its data, the update is added within the project register item. [0162] Project Register Item Design Part 2: User Interface Features. [0163] A project register item's user interface is able to capture a range of information about the project register item. The project register item's user interface runs on the user's computing device, whether a personal computer or mobile device. The user interface outlines project register item's details and history. The project register item user interface has three key functions supporting it: 1) Audit Trail. 2) Attachments. 3) Summary. [0164] Project Register Item Support Function - Audit Trail: There is an audit support function which keeps a record in a separate database table of every single change made to the project item record, when the change occurred, and by which user. This can be only be viewed by a system administrator, who is then able to audit each individual change made to the project register item. [0165] Project Register Item Support Function - Attachments: There is an attachments support function which itemises all the attachments that are associated with any part of the project register item. They are categorised as per their source and can be opened for viewing. [0166] Project Register Item Support Function - Summary: Since the system contains an audit record of all the changes that have occurred to a project register item within its database, 31 the next step is to analyse those changes and provide a summary. For example, with an action item, the system provides summary data regarding: the start date, the final date, changes to due dates, the number of times that the responsible for an item has changed, who the original responsible was, who the current responsible is, how much the item is overdue, and how many times its due date has changed. Each project item records different data, and as such the summary provides a different analysis for each. [0167] Project Register Item Design Part 3 - Life Cycle of a Project Register Item. [0168] An Project Register item has a life cycle that it goes through from when it's created through to when it is cancelled or completed. As an item goes through this life cycle, its current evolution is reflected in its work flow status. The various work flow statuses of a project item are: 1) Draft. 2) Awaiting Acceptance. 3) Open, Re-Assignment Requested. 4) Completion Request Pending, Cancellation Request Pending. 5) Completed. 6) Cancelled. [0169] The key point to note is that updates to the project item that change its details may potentially change the project items workflow status. However, the workflow status does not in any way impinge on the project item receiving an update from either a meeting or from the project item modules itself. [0170] Project Register Item Design Part 4: Layout Methodology. [0171] There are two main methods that can be used to layout and present a project item's current and historical information in a coherent and chronological manner, employing a hierarchical structure. The first one we define is 'Project Item Versioning with Updates', and the second is 'Single Project Item with Updates and Audit'. The method to use is set, when the system is configured by its administrator. [0172] 'Project Item Versioning with Updates': The premise of this layout method is: A project register item using this method needs a new version made if there is a change to the project item's details. That way, as noted, all progress updates will refer to the right project item version.

32 This layout is illustrated by the left hand side of Figure 3. In this scenario, Mr. Jones creates 'Action 1' 310, using the Action Register Item User Interface, and enters its details. On saving, the system creates the item object 'Action 1 Object' 302 in the Action Register and adds the first version of the action 'Action 1 ver.1 - Properties' 304 that details the items properties. The next day, Mr. Jones adds a progress comment 312 to the action item, which on saving creates the update comment object 'Action 1 ver.1 - Comment Update' 306, a child of 304. The next day Mr. Jones changes the due date again in the Action User Interface, 314. On saving, as this update involves a change to the action items details a new version of the item is made. This creates 'Action 1 ver.2 - Properties' 308. [0173] 'Single Project Item with Updates and Audit': The premise of this layout method is simpler to understand for users than 'Project Item Versioning with Updates', and it provides a good history of an action. There is only one version of the project item, and its properties are continually overwritten, if there are any changes from one of its updates that modify its details. Hence, the item's most recent details are very clear, and the history of evolution can be read in the updates. Additionally, any change to the project item's details is also recorded in a dedicated audit record that details exact changes and their author. This layout is illustrated by the right hand side of Figure 3. In this scenario, Mr. Jones creates 'Action 1' 310 using the Action Register Item User Interface, and enters its details. On saving, the system creates the item object 'Action 1 Object' 316 and adds the first update 'Action 1 Object - Update Object 1' 320. This update is used to define the items properties 318 The next day, Mr. Jones adds a progress comment 312 in the action user interface to the action item, which on saving creates a new update 'Action 1 Object -Update Object 2' 322. A day later Mr. Jones changes the due date again in the Action User Interface, 314. On saving, this change creates 'Action 1 Object - Update Object 3' 324. This again updates the items properties, 318. [0174] Project Register Item Design Part 5: Saving Project Items. [0175] The project register item's validation function enforces some of the project register item's module fields to be filled out, before a save can be executed. [0176] When the project register item receives updates from the meeting module, the update being received has already been checked by the meetings validation.

33 [0177] Updates within the project register item are controlled by a user interface that is used to capture the information to be added. If the update user interface is missing any information upon saving, a special user interface highlighting signals a user of the items to be completed. Until all the items have been completed within the update's user interface, the update cannot be added to the project register item. Every time an update is successfully added, the project register item is saved back to the project register database table. [0178] When the user instigates the saving method in the project register item user interface, the data collected about the project register item is communicated by the client program, from the users computing device, across the relevant communication network to the system's server. The server running on computing hardware then processes the data and passes it to the database server. The database server running on the same or different computing hardware uses the data it has received to create a record in the system database's relevant table. If the project register item, for example, is an action item, then a record of the item will be recorded in the system's action tables in the database storage. [0179] Project Register Item Design Part 6: Collaboration. [0180] Once the project register item has been recorded in the system's database, the record is now visible to other users of the system that have access to the folder to which the project register item was allocated. Multiple users can now access the same server record, and this allows for synchronous or asynchronous collaboration. [0181] Project Register Item Design Part 7: Project Register Item Reporting. [0182] Project Register items have a variety of output methods. These include: a printed report of the project register item with its complete history, or a summary version with the most current details. There is a summary report detailing revisions to project item and a statistic summary report. Also, utilising an email client, emails with content reporting on the project register items can be sent out. [0183] Integration Element 3 - Integration Methodology.

34 [0184] Now that the two elements, Meeting Item and a Project Register Item, that are being reconciled to each other have been outlined, we will now look at the methodologies required to achieve integration. These will be considered over 4 sections. 1) Methods for data acquisition and saving to the project register ('Methods for Data Acquisition'). 2) Methods to present the most recent details and sequence updates within a project register item ('Methods for Project Register Item Detail Revision and Sequencing Updates'). 3) How the system manages meeting revision and represents these changes within the project register ('Minute Revision Design'). [0185] Integration Methodologies Section 1: Methods for Data Acquisition. [0186] Section 1 Overview: This section covers Saving Meeting Item Outcomes to the Project Register. [0187] Saving Meeting Item Outcomes to the Project Register [0188] When a meeting item exports a new project register item from its minutes, the project register data collected is communicated by the client program from the users computing device across the relevant communication network to the system's server. The server running on hardware processes the data and passes it to the database server. The database server, running on the same or different computing hardware, uses the data it has received. The database server creates a new record in the data's respective database tables. [0189] When a meeting item exports a project register update item from its minutes, the project register update data collected, follows the same route as a new project item until it gets to the database server. The database server, analyses the data being received and opens the relevant project item in the project register, and then effectively adds an update populating the relevant part of the database with the data passed. [0190] Integration Methodologies Section 2: Methods for Project Register Item Detail Revision and Sequencing Updates.

35 [0191] Section 2 Overview - Project Register Item Detail Revision and Sequencing Updates: [0192] First, this section covers the rules for changing project item's properties within two layout methodologies: 'Project Item Versioning with Updates' and 'Single Project Item with Updates and Audit' ('Project Register Item Detail Revision'). Additionally, the section outlines the system's solutions to sequencing updates in problem one, two and three, outlined in the background of this document ('Sequencing Updates'). These solutions will be discussed in the following order: 1) Rule One - Delayed Minute Production (Problem 1). 2) Rule Two - Future Meetings (Problem 2). 3) Rule Three - Past and Future Meetings (Problem 1 and 2). 4) Rule Four - Multiple Updates from a Meeting (Problem 3). Before discussing each individual solution for sequencing updates, note that, if the system administrator wishes to block the use of future meetings (this is an option within the system), then Rule 1 can be used to sequence updates. Otherwise, if future meetings are permissible, then the updates should be sequenced using Rule 3. [0193] 'Public assignment time', as a concept, is the time and date at which something is publicly declared, that people might act on or make decisions based on that information. When applied to project items, using the public assignment time to chronologically order elements within a project item, enables the item to most closely model the natural workflow of that project item. This makes the data within a project register more accurate. [0194] To enable the use of public assignment time within the system instead of merely creation time, the system orders elements with a project item using a derived time called "update obtained time" (UOT). There are rules the system follows to ensure that the "update obtained time" most accurately reflects an update's public assignment time. The definitions of these rules are outlined below whilst examining how to address the 'project / meeting minute integration problems' outlined in the background section. [0195] Project Register Item Detail Revision. [0196] Project register items comprise the entire chronological history of the item, but often the system only needs to present the most recent data. How the system's two layout methodologies maintain the most recent project item data is different. This will now be outlined 36 for both in order: 1) Property Update Rule for 'Single Project Item with Updates and Audit'. 2) Methodology for 'Project Item Versioning with Updates'. [0197] Property Update Rule - Revising the Details of a 'Single Project Item with Updates and Audit'. [0198] When using 'Single project Item with updates and audit' layout method, the project item only has one version of the project item's properties. Each new update that the project register item receives is added to the items history, and may be used to update the most current version of the project item properties. [0199] The system updates the project item's properties based on the information contained within the new update, if the update is sequenced as being the most recent update. Updates are sequenced using their 'update obtained time'. [0200] The Property Update Rule is used to establish whether the properties of the project register item should change: If the received update comprises details to update one or more of the project item's properties, and its "update obtained time" is either equal or later than that of a last update from the project register item's update history, the new update is considered the most recent, thus the system updates the project item's properties and makes a record of the changes in the database. [0201] 'Project Item Versioning with Updates' Property Update Methodology. [0202] In case of 'Project Item Versioning with Updates', the system creates a new version each time there is a change to the project register item's details, keeping the older version intact, thus the most recent details of a project register item are presented in its latest version. [0203] Sequencing Updates. [0204] Sequencing updates to a project register item involves not only managing their order to update properties of the project register item, but also their order within the project 37 item's update history. The project item update history is used to keep track of the ordered updates to the project register item and display them in the project register item's user interface. Sequencing updates to the project register item refers to updating project register item properties in order and keeping a history of those updates in the sequential order as well. To conclude, the system uses "update obtained time" to sequence updates to the project register and maintain their order within the project item update history, where the updates are ordered from the earliest to the most recent based on their "update obtained time" value. [0205] Rule 1 on Delayed Minute Production. [0206] 'Project / meeting minute integration - problem 1', detailed in the background section, outlines the need for a project item to accurately handle updates coming from a meeting that has already occurred in the past. [0207] The public assignment time for updates to project items coming from a meeting held in the past, is not their time of exportation from the meeting minutes, it is the time that they were discussed in the meeting. This is best represented by the time and date of the end of the meeting. [0208] Therefore, given problem one, the rule required to define the "update obtained time" and sequence the updates correctly is: [0209] Rule Number 1: All updates coming from a project item user interface, use their creation time and date for the "update obtained time" (UOT). All updates coming from a meeting user interface use the meeting end time and date for the "update obtained time" (UOT). [0210] An example of the use of Rule 1 is found in Figure 4. The Layout Method is 'Single Project Item with Updates and Audit'. The example illustrates the application of the Rule 1 and the Property Update Rule using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. A new meeting 402 is held and recorded in the system as Meeting Object 1 404. An existing Action Item 'Action X Object' 406 is imported into the agenda of the meeting and is recorded as 'Meeting Object 1 - Meeting Outcome Object 1' 408. As a result of 38 discussions during the meeting, it is agreed that 'Action X Object' 406 will be assigned the new date of the 30-OCT-2013. This change is recorded in 'Meeting Object 1-Meeting Outcome Object 1' 408 and becomes part of the draft minutes of the meeting. No change will be made to the 'Action X object' 406 until the contents of the minutes are exported. [0211] Mr Jones decides the following day, before the meeting minutes are ready and their stored information is exported to the Action Register, that he needs to change the due date of the Action Item to 30-JUN-2013. He does this using the Action Item User Interface 410. This creates 'Action X Object - Update Object 1' 416 within 'Action X Object' 406 with a due date of 30-JUN-2013. Using the 'Property Update Rule', the creation of the update 416 updates 'Action X Object-Properties' 414, changing the due date from the 31-Dec-2013 to 30-Jun-2013. [0212] Subsequently, the meeting minutes are exported to the Action Item Register 418 on 4-APR-2013. This creates within the item 406 the new update 'Action X Object - Update Object 2' 412. Using Rule 1, it receives the 'Update Obtained Time' (UOT) from the meeting's end time and date (3pm 1-APR-2013). This makes the UOT of update 412 older than the UOT of the update 416. Hence, using the 'Property Update Rule', the creation of update 412 will not update the actions details in 414 as it is not the most recent update. [0213] When the Action Item is viewed in the system, the correct due date will be displayed, the 30-JUN-2013. [0214] Rule 2 on Future Meetings. [0215] Project / meeting minute integration - problem 2, detailed in the background section, outlines the need for a project register item to accurately sequence updates being exported from meeting minutes, for a meeting that is planned for the future. [0216] As future meetings are somewhat of an abstract concept for users, the use of future meetings is optional within the system. It is one of the system's preferences. If the option to disable future meetings is selected, the system will not allow updates to be passed from the meeting item to their corresponding project register items until the meeting end time has passed. If future meetings are allowed, then this feature needs to be handled correctly.

39 [0217] When the system exports its data from the meeting minutes of a future meeting to the project register, thus creating new project items or project item updates, the contained information becomes publicly available. Consequently, when this exportation occurs is the public assignment time. [0218] Therefore, in the case of 'problem two', the rules required to define the "update obtained time" and sequence the elements correctly is: [0219] Rule number 2: All updates from the Project Item user interface use their creation date and time for the "update obtained time" (UOT). All updates coming from a future meeting use the meeting export date and time for their "update obtained time" (UOT). [0220] An example of the use of Rule 2 is found in Figure 5 Future Meetings. The layout Method is 'Single Project Item with Updates and Audit'. The example illustrates the application of the Rule 2 and the Property Update Rule using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. A new meeting 502 is created and recorded in the system as Meeting Object 1 504. An existing Action Item 'Action X Object' 506, has its properties 514 imported into the agenda of the meeting and is recorded as 'Action X Object 1-Meeting Outcome Object 1' 508. While drafting the meeting minutes for a future meeting, the minute taker decides that 'Action Object X' 506 should be assigned a new due date of the 30-OCT-2013. This change is recorded in 'Meeting Object 1-Meeting Outcome Object 1' 508 and becomes part of the draft minutes of the meeting. The meeting's minutes are exported 518 to the Action Register Item on 2-APR-2013 creating the update 'Action X Object - Update Object 1' 512 before the meeting has occurred (planned for the 14-OCT-2013). Using Rule 2, the update 512 receives the "update obtained time" (UOT) that is the same as the export time. Using the 'Property Update Rule', the creation of update 512 will update the actions details 514 as it is the most recent update. The due date changes from the 31-DEC-2013 to 30-OCT-2013. [0221] Mr. Jones decides the following day (11 am, 3-APR-2013) that he needs to change the due date of the Action Item to 30-JUN-2013. He does this using the Action Item User Interface 510. This creates 'Action X Object - Update Object 2' 516, within 'Action X Object' 506, with a due date of 30-JUN-2013 and the UOT of the 11 am 3-APR-2013 according to the 40 Rule 2 . Using the 'Property Update Rule', the creation of the update 516 modifies 'Action X Object-Properties' 514, changing the due date from the 30-OCT-2013 to 30-JUN-2013. [0222] When the Action Item is viewed in the system, the correct due date will be displayed, the 30-JUN-2013. [0223] Rule 3 on Past and Future Meetings. [0224] Given that the rules for past meeting and future meetings contradict each other (Rule 1 and Rule 2), the system needs to be designed to accurately manage past and future meetings, if the system is configured by the system administrator to manage both. [0225] The solution to this problem is as follows: combining solutions to problem one and problem two, the public assignment time can be established by resolving whichever is earlier: either the future meeting date or the update's exportation date. For all updates for future meetings, the earlier date is the exportation time and date, and for past meetings it is the meeting end time and date. [0226] Therefore, in the case of trying to address 'problem one and two', the rule required to define the "update obtained time" and sequence the elements correctly is: [0227] Rule number 3: All updates from a project item user interface use their creation time for the "update obtained time (UOT)". All new items or updates from a meeting user interface, use the earlier of either the meeting end time and date or its exportation time and date, to define the "update obtained time" (UOT). [0228] An example of how the system would manage a past meeting is the same as Figure 4, and how it would manage a future meeting is the same as Figure 5. [0229] Rule 4 on Multiple Updates.

41 [0230] Project / meeting minute integration - problem 3, detailed in the background section, outlines the need for a project item to accurately handle multiple updates coming from one meeting. [0231] As the updates come from the same meeting, they all share the same exportation and meeting end date and time. Therefore, to sequence them in the project register item's history in a way that reflects their order within the meeting, the time stamps of the "update obtained time" values need to differ. Therefore, sequence the updates, the system gives each update the same initial "update obtained time", but includes then includes for each update the addition of an amount of time that proportionally represents the relative position of the update within the source meeting. [0232] For example, the first of multiple updates in the meeting receives the same "update obtained time" (UOT) with 1 of a second included, the second update the same initial UOT with 2 seconds, the third update the same initial UOT add 3 of a second, etc.. [0233] In the case of trying to address 'problem three', the rule required to define the "update obtained time" and sequence the elements correctly is: [0234] Rule number 4: All updates from a project item user interface use their creation time for the "update obtained time" (UOT). All new multiple updates from a meeting to the same project register item, use the earlier of either the meeting end time and date or its exportation time and date, with the addition of an amount of time that proportionally represents the relative position of the update within the source meeting, to define the "update obtained time" (UOT). [0235] An example of the use of Rule 4 is found in Figure 6 Multiple Updates. The Layout Method is 'Single Project Item with Updates and Audit'. The example illustrates the application of the Rule 4 and the Property Update Rule using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. In this figure, a Meeting 602 is being planned (on the 23 MAR-2013) for a future meeting to be held on the (4-OCT-2013). During this meeting the action Item 'Action X Object' 604 will be discussed twice under two different agendas. Each agenda section needs the ability to record the discussion and reflect changes to the same Action Item during that part of the meeting. To achieve this, 'Meeting Object 1' 606 imports the properties 42 of the action item twice as per user instruction from the system's user interface and they are recorded within the meeting object as meeting outcome objects 608, 610. Required changes to the action item during each part of the meeting are reflected in these objects. The minutes are prepared and its relevant contents are exported 622 to the project register at 10am on the 1-APR 2013. The Meeting Outcome 608 and 610 correspond with the Update Objects 612 and 614 of the 'Action X Object' 604 respectively. Using Rule 4, the system stamps the updates 608, 610 to the same action item 'Action X Object' 604 with an "update obtained time" that shares the same date 1-APR-2013, but differs in time value by a number of seconds equal to their respective order counts within the meeting 606. Therefore, the Update Objects 612 and 614 to the 'Action X Object' 604 are sequenced one after the other based on their "update obtained time" values. As per 'Property Update Rule', this updates the properties 620, of Action Item 604, and updates the items due date property twice, changing first to the 30 NOV-2013 and then to 30-OCT-2013. [0236] Mr. Jones at 11am on the 03-APR-2013 then decides to change the due date of the Action item 604 again, and using the Action User Interface 616 creates a new action item update 'Action X Object - Update Object 1' 618 and sets the due date as the 30-JUN-2013. As per 'Property Update Rule', this updates the properties 620, of Action Item 604, and the due date from the 30 OCT-2013 to 30-JUN-2013. [0237] When the Action Item is viewed in the system, the correct due date is displayed, the 30-JUN-2013. [0238] Integration Methodologies Section 3: Minute Revision Design [0239] Section 3 Overview - Minute Revision Design: As outlined in the background section, the system needs to be able to handle revisions to the meeting minutes and appropriately update their related content within the project register. [0240] The system has been configured to use any one of the four methods outlined below. Each has its advantages and disadvantages, and ultimately the decision on which to use comes down to user preference. Method 1: Overwriting the Current Item Update. Method 2: Append the Progress Updates. Method 3: Updates as Children. Method 4: New Version of the Update Sequentially Ordered.

43 [0241] All of these methods can be applied to the project item being configured to use the layout methodology 'Single Project Item with Updates and Audit'. [0242] Finally this section on Minute Revision Design will describe a scenario on managing project register items that were sourced from a meeting, in the event that the source meeting is cancelled. [0243] In considering the following scenarios, a revision to the meeting minutes has included a revision to a meeting project register item outcome. Upon the system saving the changes to the meeting, the meeting user interface recognizes that there has been a change to a meeting project register item outcome, and then exports the new version of the outcome to its respective item in the project register. The project register item then needs to handle the update appropriately using Rules 1 to 4 as well as the 'Property Update Rule'. [0244] There are several ways that minute revision changes can be represented within a project item, but whichever method is selected, it is imperative that the system achieves three points. Firstly, the minute revision can't affect, overwrite or interfere with other updates that did not originate from the revised meeting. Secondly, if there have been no updates from another source since the meeting, and if the revision contains changes to the project item's details, then this change needs to be represented as the project item's most recent item details. Thirdly, the changes affected by the meeting minute revision can be shown in the project item to facilitate the understanding of the item's history. [0245] Meeting Minute Revision: Method 1 - Overwriting the Current Item Update. [0246] In this Method, the existing updates within the project items are overwritten with the revised meeting project item updates that are been exported from the revised minutes. The new update keeps the same UOT as the project item update it is replacing, thereby protecting the chronological order of elements. This is important in the context of future meetings, where the exportation date is used for the update obtained time.

44 [0247] The advantage of this method is its simplicity. The disadvantage of this method is that there is no way of seeing the change that was made from the old update within the new project item. [0248] An example of this scenario can be found in Figure 7 'Overwriting Project Item Updates'. The Layout type is 'Single Project Item with Updates and Audit'. The example illustrates the application of the Rule 3, the Property Update Rule and the minutes revision method 1 Overwriting the Current Item Update using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. The scenario is of a future meeting, as it is an abstract concept, and is more complicated for the system to handle. A new future meeting 702 is planned and created in the system as 'Meeting Object 1' 704. Mr. Jones is the meeting chair and is also taking the meeting minutes. An existing Action Item, 'Action X Object' 712 has its details / properties 714 imported into the agenda of the meeting, and these details are recorded as 'Action X Object 1-Meeting Outcome Object 1' 706. The meeting minutes are made by Mr. Jones for the future meeting and the meeting outcome 706 assigns the new date of the 30-OCT 2013. Upon Mr. Jones's direction, 3pm 2-APR-2013, 'Meeting Object 1' 704 exports 708 its relevant changes to the 'Action X Object' 712 creating the update 'Action X Object - Update Object 1' 716. As per 'Property Update Rule', this in turn updates the 'Action X Object Properties' 714, changing the due date from 31-DEC-2013 to the 30-OCT-2013. [0249] Mr. Smith, the responsible for the action, decides the following day that the due date of the Action Item should be the 30-JUN-2013. He makes this change directly in the Action Register Item, using the Action Item User Interface 722, adding a comment as well. Upon completing this process, the update 'Action X Object - Update Object 2' 720 is created. As per 'Property Update Rule', this in turn updates the 'Action X Object - Properties' 714, changing the due date from the 30-OCT-2013 to the 30-JUN-2013. [0250] On following day, on the 4-APR-2013, Mr. Jones realises that he has made a typing error in the minutes that he wrote on the 2-APR-2013, two days earlier. The date he had intended to write down was the 30-SEP-2013. He accordingly edits the meeting minutes, and this revision is reflected in a change to the 'Meeting Object 1 - Meeting Outcome Object 1' 706. Mr. Jones saves these meeting changes, at which time, the system then exports 710 the revised meeting outcome 706 to the relevant action item 712. This change is to the existing update object, 45 'Action X Object - Update Object 1' 716. Using Method 1, the update object 716 is replaced using the revised information coming from the meeting, by creating 'Action X Object - Update Object 3' 718. Following Method 1, the update object 718 retains the UOT of the previous object 716 that is being revised. This avoids the new update 718 being incorrectly ordered and allows later minutes revisions to overwrite this project item update. As per 'Property Update Rule', no change is made to 'Action X Object - Properties' 714, because there is a more recent update 'Action X Object - Update Object 2' 720 , that has a later UOT than the 'Action X Object Update Object 3' 718, within the project register item. [0251] In Figure 7, using Method 1 the final due date of 'Action X Object' 712 is 30-JUN 2013. [0252] Meeting Minute Revision: Method 2 - Append the Progress Updates. [0253] In this scenario, when a meeting item outcome revision occurs, the system creates a new project item update and appends it in a text form to its relevant update within a project item. The new project item update keeps the same UOT as the update it is revising. This process can be repeated, where coming revision updates from the meeting to the existing update, would be ordered sequentially as they are created within the revised update. [0254] The advantage of this method is that both the previous update from the meeting and the current update with the revised minutes can be seen, when reading the project item's history. The disadvantage of this method is that a project item's user interface can become cluttered with particularly large objects outlining all of the changes to an update. [0255] An example of this scenario can be found in Figure 8 'Append the Progress Updates'. The Layout is 'Single Project Item with Updates and Audit'. The example illustrates the application of the Rule 3, the Property Update Rule and the minutes revision method 2 Append the Progress Updates using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. The scenario is of a future meeting, as it is an abstract concept and is more complicated for the system to handle. A new future meeting 802 is planned and created in the system as 'Meeting Object 1' 804. Mr. Jones is the meeting chair and is taking the meeting minutes. An existing Action Item, 'Action X Object' 812 has its details / properties 814 imported into the 46 agenda of the meeting, and these details are recorded as 'Action X Object 1-Meeting Outcome Object 1' 806. The meeting minutes are made by Mr. Jones for the future meeting and the meeting outcome 806 is assigned the new date of the 30-OCT-2013. Upon Mr. Jones's direction, 3pm 2-APR-2013, 'Meeting Object 1' 804 exports 808 its relevant changes to the 'Action X Object' 812, and creates the update 'Action X Object - Update Object 1' 816. As per 'Property Update Rule', this in turn updates the 'Action X Object - Properties' 814, changing the current due date from 31-DEC-2013 to 30-OCT-2013. [0256] On following day, 3-APR-2013, Mr. Jones reviews the minutes that he wrote on the 2-APR-2013. He decides to push the due date of 812 to the 30-SEP-2013. He accordingly edits the meeting minutes, and this revision is reflected in a change to the 'Meeting Object 1 Meeting Outcome Object 1' 806. Mr. Jones saves these meeting changes, at which time, the system then exports 810 the revised meeting outcome 806 to the relevant action item 812. This change is to the existing update object, 'Action X Object - Update Object 1' 816. Using Method 2, the new update from the meeting 'Action X Object - Update Object 3' 818 is appended as text to the update object 816, keeping the same UOT as the update it is modifying, 3pm 2-APR-2013. According to the 'Property Update Rule' further, this in turn updates the 'Action X Object - Properties' 814, changing the due date from 30-JUN-2013 to 30-SEP-2013, for the reason that there is no other update that has a UOT later than that of the 'Action X Object - Update Object 3' 818 - 3 pm 2-APR-2013. [0257] Mr. Smith, the responsible for the action, decides the following day, 1 1am 4 APR-2013, that the due date of the Action Item 812 should be 30-JUN-2013. He makes this change directly in the Action Register Item, using the Action Item User Interface 822, he also comments on the reasons for the change. Upon completing this process, the update 'Action X Object - Update Object 2' 820 is created. As per 'Property Update Rule', this in turn updates the 'Action X Object - Properties' 814, changing the due date from 30-SEP-2013 to 30-JUN 2013. [0258] In Figure 8, the final due date of 'Action X Object' 812 is 30-JUN-2013. [0259] Meeting Minute Revision: Method Three - Updates as Children.

47 [0260] In this scenario, the new update being passed from the meeting is linked to the existing project item update, that it is revising, using a parent-child relationship. Consequently, the new update becomes a child of the existing update. This process can be repeated, where new revision updates from the meeting to the existing update, would be ordered using the secondary sort on their creation time children. [0261] This way, both the previous updates from the meeting and the current update with the revised minutes can be easily seen when reading the project item's history. [0262] A worked example of this scenario can be found in Figure 9 'New Action Item Updates as Children of the Parent Update'. The Layout Method is 'Single Project Item with Updates and Audit'. The scenario is of a past meeting. The example illustrates the application of the Rule 3, the Property Update Rule and the minutes revision method 3 Updates as Children using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. A new meeting 902 is held in the system as 'Meeting Object 1' 904 from 11am to 1pm on 1-APR-2013. Mr. Jones is the meeting chair and is also taking the meeting minutes. An existing Action Item, 'Action X Object' 912 has its details / properties 914 imported into the agenda of the meeting, and these details are recorded as 'Action X Object 1-Meeting Outcome Object 1' 906. During the meeting, it was agreed to assign the new date of the 30-MAY-2013 to the Action X Object 912. However, Mr. Jones made a mistake and exported a different due date of 30-SEP-2013, which was included in 'Action X Object 1-Meeting Outcome Object 1' 906. Upon Mr. Jones's direction at 3pm 2-APR-2013, 'Meeting Object 1' 904 exports 908 its relevant changes to the 'Action X Object' 912 creating the update 'Action X Object - Update Object 1' 916 with the UOT of 1pm, 1-APR-2013 following Rule 1. As per 'Property Update Rule', this in turn updates the 'Action X Object - Properties' 914, changing the due date from 05-JUN-2013 to the 30- SEP -2013. [0263] Mr. Smith, the responsible for the action, decides the following day that the due date of the Action Item should be the 25-MAY-2013. He makes this change directly in the Action Register Item, using the Action Item User Interface 922, he also comments as to why he made the change. Upon completing this process, the update 'Action X Object - Update Object 2' 920 is created. As per 'Property Update Rule', this in turn updates the 'Action X Object Properties' 914, changing the due date from the 30- SEP -2013 to the 25-MAY-2013.

48 [0264] On following day, on the 4-APR-2013, Mr. Jones realises that he has made a typing error in the minutes that he wrote on the 2-APR-2013, two days earlier. The due date he had intended to write down was the 30-MAY-2013. He accordingly edits the meeting minutes, and this revision is reflected in a change to the 'Meeting Object 1 - Meeting Outcome Object 1' 906. Mr. Jones saves these meeting changes, at which time, the system then exports 910 the revised meeting outcome 906 to the relevant action item 912. This change is to the existing update object, 'Action X Object - Update Object 1' 916. Using Method 3, the new update 'Action X Object - Update Object 3' 918, becomes a child of the update 916. As per the 'Property Update Rule', this update 918 cannot change 'Action X Object - Properties' 914, because the project item has another update 920 with a later UOT of 11am, 3-APR-2013. [0265] In Figure 9, the final due date of 'Action X Object' 912 is 25-MAY -2013. [0266] Meeting Minute Revision: Method Four - New Version of the Update Sequentially Ordered. [0267] In this scenario, a new update produced after the meeting revisions, is exported as a new version of the update, while keeping the same 'update obtained time' as the update it is revising. Therefore, the project item uses a secondary sort on creation data and time to sequence the revision updates. [0268] There is no distinct advantage of this method over making the new updates / old updates children of each other. The disadvantage of this method is that at first glance, it might make it look like there have been a lot more updates to the project item than there actually were. [0269] A worked example of this scenario can be found in Figure 10 'Sequential Updates'. The Layout Method is "Single Project Item with Updates and Audit'. The example illustrates the application of the Rule 3, the Property Update Rule and the minutes revision method 4 New Version of the Update Sequentially Ordered using a due date property of an action item; however, the rules are applicable for updates containing any one of the other action item's properties or a combination of those. The scenario is of a future meeting, as it is an abstract concept, and is more complicated for the system to handle. A new future meeting 1002 is planned and created in the system as 'Meeting Object 1' 1004. Mr. Jones is the meeting chair 49 and is also taking the meeting minutes. An existing Action Item, 'Action X Object' 1012 has its details / properties 1014 imported into the agenda of the meeting, and these details are recorded as 'Action X Object 1-Meeting Outcome Object 1' 1006. The meeting minutes are made by Mr. Jones for the future meeting and the meeting outcome 1006 is assigned the new date of the 30 OCT-2013. Upon Mr. Jones's direction, 3pm, 2-APR-2013, 'Meeting Object 1' 1004 exports 1008 its relevant changes to the 'Action X Object' 1012 creating the update 'Action X Object Update Object 1' 1016. As per 'Property Update Rule', this in turn updates the 'Action X Object - Properties' 1014, changing the due date from 31-DEC-2013 to the 30-OCT-2013. [0270] Mr. Smith, the responsible for the action, decides the following day that the due date of the Action Item should be the 30-JUN-2013. He makes this change directly in the Action Register Item, using the Action Item User Interface 1022, he also comments as to why he made the change. Upon completing this process, the update 'Action X Object - Update Object 2' 1020 is created. As per 'Property Update Rule', this in turn updates the 'Action X Object Properties' 1014, changing the due date from the 30-OCT-2013 to the 30-JUN-2013. [0271] On following day, on the 4-APR-2013, Mr. Jones realises that he has made a typing error in the minutes that he wrote on the 2-APR-2013, two days earlier. The date he had intended to write down was the 30-SEP-2013. He accordingly edits the meeting minutes, and this revision is reflected in a change to the 'Meeting Object 1 - Meeting Outcome Object 1' 1006. Mr. Jones saves these meeting changes, at which time, the system then exports 1010 the revised meeting outcome 1006 to the relevant item action item 1012. This change is to the existing update object, 'Action X Object - Update Object 1' 1016. Using Method 4, the 'Action X Object - Update Object 3' 1018 is sequenced immediately after the update that it's updating 1016, and obtains the same Update Obtained Time and is sequenced as per its update revision chronology in order (+1 each addition update). As per 'Property Update Rule', the update 1018 does not become the most recent update, and no change is made to 'Action X Object Properties' 1014. [0272] In Figure 10, using Method 4 the final due date of 'Action X Object' 1012 is 30 JUN-2013. [0273] Meeting Minute Revision: Cancelled Meetings.

50 [0274] If a meeting is cancelled, two things happen. When the system is using the layout methodology 'Project Item Versioning with Updates' for its project item, then the system automatically adds a progress update, sequenced with its time of creation. The progress note explains that the contributing meeting was cancelled. The original progress update that came from the cancelled meeting, details its source. This source label would now additionally have the note "Meeting Cancelled" added to it. When the system is using the layout methodology 'Project Item Versioning with Updates', any update from any meeting has its source noted, and the additional comment "Meeting Cancelled" is again added to that note. In either layout methodology, the system does not automatically remove the content, or change the project items details in anyway. From a user perspective, the system merely flags that a contributing source for the project item has been cancelled. The user can then cancel the project item at their discretion. [0275] Integration Methodology Summary. [0276] Technical solutions have now been outlined to the major issues identified in the background section, which need to be addressed when integrating meeting minutes with a project register. Within each part of these solutions, there were certain options that were offered that would allow customization of the system as per the system manager's preference. [0277] These options build on each other and are laid out in Figure 11. In the figure, at 1102 the project register items receives an update containing data collected from a meeting outcome with data for the creation of a new project item, or with data to add an update to an existing project item. In the system settings, the layout of the project item will be configured to use either 1104-Layout 1, or 1106 Layout 2. At 1108, if the data being received is an update, then the updates will then be sequenced as per 1110 - Rule 1. 1112-Rule 2, 1114-Rule 3 that were previously outlined. Multiple Updates from a meeting are all managed the same way using Rule 4, and is not an option and therefore not in Figure 11. 1116, The next option a project item has to configure its history is how it wants to display revisions to meeting minutes. The project item can be instructed to use 1118-Method 1, 1120-Method 2, 1122-Method 3, 1124-Method 4. These have all been previous outlined. At 1126, finally, for project items that use 1106-Layout 2, the system will use 'Property Update Rule' to update its project item details. This is not an option, but is listed to outline 'Property Update Rule' doesn't not apply to 1104-Layout 1.

51 [0278] System Productivity and analysis. [0279] With the integration issues resolved between meeting minutes and project items, it is consequently possible to use the system capture key data more efficiently, and then report against it. The document will briefly discuss two of these possibilities, in order:- Part 1 Update Meetings. Part 2 - Reporting and Analysis. [0280] Reporting Part 1: Update Meetings. [0281] The premise of the 'update meetings' is that multiple project items to discuss can be selected from the project register to automatically generate an 'update meeting' around those items. Upon command, the system imports the details of each project item selected into a meeting minutes interface. It then organises each item under separate agenda items. The allocation to an agenda item can be based on any common criteria to the project items, but by default the system uses folder location to arrange the agendas. [0282] Each imported project item can be updated. That is, its project item's properties (details) can be modified, and progress updates can be added. When instructed by a user, the system exports the captured data back to the project register. The system then adds the respective updates to the relevant project items using the methodologies outlined in this invention. [0283] The power of 'update meetings' is the ability to run an update meeting for a range of different scenarios. One could, for example, select all the outstanding actions and issues for a staff member and run an update meeting with that staff member only. One could run an update meeting for all items within a folder. One could run an update meeting for all high priority actions, issues, risks, etc. [0284] Reporting Part 2: Analysis. [0285] With the meeting and the project register captured in the system's database, it then becomes possible to do more in-depth analysis of the systems content. Examples include: Reports that outline all overdue project items, with sub criteria such as 'which have the priority: critical', or 'belong to a certain team/person'; Reports that detail all the actions that are due in 52 the next day, week, or months; A report on all the decisions that were taken for a certain part of the project; A list of all the current risks facing the project with the sub criteria 'high'. [0286] Illustrative system for managing a meeting. [0287] Turning to the drawings, Figure12 shows an illustrative system 1200 for managing a meeting. In particular, a user, such as user 1238, can schedule a meeting with users 1202 and 1206 and create an agenda for the meeting. The meeting can comprise a traditional face to face meeting, a meeting conducted over a network (e.g., online meeting), or the like. In the latter case, users 1238, 1202 and 1206 can conduct the meeting by using computers 1204, 1208 and 1210 to communicate with one another. Communications can comprise audio, video, data or any combination thereof, and can occur over a network 1244. To this extent, network 1244 can comprise any type of communications link. For example, network 1244 can comprise an addressable connection in a client-server (or server-server) environment that may utilize any combination of Wireline and/or wireless transmission methods. In this instance, computers 1204, 1208 and 1210 may utilize conventional network connectivity, such as Token Ring, Ethernet, WiFi or other conventional communications standards. Further, network 1244 can comprise any type of network, including the Internet, a wide area network (WAN), a local area network (LAN), a virtual private network (VPN), etc. Where computers 1204, 1208 and 1210 communicate via the Internet, connectivity could be provided by conventional TCP/IP sockets based protocol, and one or more computers 1204, 1208 and 1210 could utilize an Internet service provider to establish connectivity. [0288] As shown, computer 1210 generally includes a central processing unit (CPU) 1234, a memory 1212, an input/output (1/0) interface 1236, a bus 1246, external I/O devices/resources 1242, and a storage unit 1240. CPU 1234 may comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g., on a client and server. Memory 1212 may comprise any known type of data storage and/or transmission media, including magnetic media, optical media, random access memory (RAM), read-only memory (ROM), a data cache, a data object, etc. Storage unit 1240 may comprise any type of data storage for providing storage for information necessary to carry out the invention as described above. As such, storage unit 1240 may include one or more storage devices, such as a magnetic disk drive or an optical disk drive. Moreover, similar to CPU 1234, memory 1212 and/or storage unit 1240 may reside at a single physical location, comprising one or more types of data storage, or be 53 distributed across a plurality of physical systems in various forms. Further, memory 1212 and/or storage unit 1240 can include data distributed across, for example, a LAN, a WAN or a storage area network (SAN) (not shown). [0289] I/0 interface 1236 may comprise any system for exchanging information to/from one or more external 1/0 devices 1242. I/0 devices 1242 may comprise any known type of external device, including speakers, a CRT, LED screen, handheld device, keyboard, mouse, voice recognition system, speech output system, printer, monitor/display, facsimile, pager, communication hardware/software, etc. Bus 1246 provides a communication link between each of the components in computer 1210 and likewise may comprise any known type of transmission link, including electrical, optical, wireless, etc. Operating system software 1228, may also be present in the memory of the computer together with database software 1230. [0290] It is understood that computers 1204 and 1208 typically include the same elements as shown in computer 1210 (e.g.,CPU, memory, I/O interface, etc.). These have not been separately shown and discussed for brevity. Further, it is understood that each computer 1204, 1208 and 1210 comprises any type of computing device capable of communicating with one or more other computing devices, such as a server, a desktop computer, a laptop, smart TV, a handheld device, a mobile phone, a pager, a personal data tablet, etc. However, it is understood that if a computer 1204, 1408 or 1210 is a handheld device or the like, a display could be contained within the computer 1204, 1208 or 1210, and not as an external I/O device 1232 as shown for computer 1210. [0291] Computer 1210 is shown including the previously described meeting application 1214 for managing a meeting. In particular, a user, such as user 1238, can operate meeting system 1214 to plan, conduct, store, and obtain data about a meeting. To this extent, meeting application 1214 is shown including a project module 1216 a contact module 1218 for obtaining a set of attendees for the meeting. To assist in conducting and retrieving information about the meeting, meeting application 1214 is shown including a minutes module 1222 for generating a minutes document using the meeting document, and a Project Item module 1224 to record the meeting outcomes. The processing and transfer of data between the meeting module and the Project Register is performed by the meeting application according to methods and rules as previously described.

54 [0292] While the system 1200 is shown implemented using a peer-to-peer network architecture (e.g., users 1202 and 1206 connect to computer 1210 operated by user 1240 in order to use meeting application 1214), it is understood that the system 1200 could be implemented using any type of network architecture. For example, the system 1200 could comprise a client server network architecture in which meeting application 1214 executes on the server, and all users 1202, 1204 and 1240 connect to the server using their respective computers 1204, 1208 and 1210. In any event, it is understood that some of the various systems shown in FIG. 12 can be implemented independently, combined, duplicated, and/or stored in memory for one or more separate computers 1204, 1208 and 1210. For example, meeting application 1214 could be implemented on each computer 1204, 1208,and 1210, and the functions available to each user 1202, 1204 and 1240 can be varied based on the meeting document and the particular user 1202, 1204 or 1210. Further, it is understood that some of the systems and/or functionality may not be implemented, or additional systems and/or functionality may be included as part of system 1200. [0293] The foregoing description of various aspects of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to a person skilled in the art are intended to be included within the scope of the invention as defined by the accompanying claims. CITATIONS Patent Literature US 7,146,381 BI 12/2006 Allen et al. Information Organization and Collaboration Tool for Processing Notes and Action Requests in Computer Systems. US 2005/0131714 Al 6/2005 Braunstein et al. Method, System and Program Product for Hierarchically Managing a Meeting. US 6018346 A 1/2000 Moran et al. Freeform graphics system having meeting objects for supporting meeting objectives US7047192 5/2006 Poirier. Simultaneous multi-user real-time speech recognition system.

55 US6754631 6/2004 Din. Recording meeting minutes based upon speech recognition. W02006089355A1 8/2006 Doyle et al. A system for recording and analysing meetings. US6100882 8/2000 Adams et al. Textual recording of contributions to audio conference using speech recognition. Electronic Meeting System Patents US 8,266,534 B2 11/2012 Curtis et al. Collaborative Generation of Meeting Minutes and Agenda Confirmation. US 2007/0112926 Al 5/2007 Brett et al. Meeting Management Method and System. US 7,159,178 B2 1/2007 Vogt et al. System for supporting a Virtual Community. US 2003/0158845 Al 8/2003 Braley. Integrated Management Database US 2006/0106872 Al 5/2006 Leban et al. Active Agenda US 2006/0053194 Al 3/2006 Schneider et al. Systems and Methods for Collaboration US 2002/0032592 Al 3/2002 Krasnick et al. Online Meeting Planning Program US 2007/0005408 Al 1/2007 Boss et al. Method and Structure for Agenda Based Scheduling using Sub-Events with Automated Management Functions US 10/648,991 8/2003 Karstens. System and Method for Dynamic Meeting Agenda with Event Firing Progress Indicators US 7,530,021 B2 5/2009 Cheng et al. Instant Meeting Preparation Architecture US 5,890,131 3/1999 Ebert et al. Project Organization and Optimization Tool and Method of use Thereof 56 US 2007/0106931 Al 5/2007 Vartiainen et al. Active Notes Application US 2009/0204414 Al 8/2009 Shah. Method and System to Enable In-Context Pre-Meeting Dialogue and Collaboration Among Invitees US 2007/0016661 Al 1/2007 Malik. Event Organizer US 2009/0192845 Al 7/2009 Gudipaty et al. Integrated Real Time Collaboration Experiences with Online Workspace. Non-Patent Literature Kolaco Inc TrackMeet www.trackmeet.net Layer 2 GmbH Meeting Manager for Sharepoint 2010 Microsoft Sharepoint Server 2007 Help. Introduction to versioning Softalot LLC Action Item Manager 7.0 Enterprise Edition User's Guide Wikipedia "Electronicmeeting-system"

Claims (5)

1. A method, comprising: providing a common platform to capture and manage meeting and project item content; providing a user interface to capture 'project items', and updates to 'project items'; providing a user interface to capture meeting item content, inclusive of meeting minutes; managing project item data, using a design that maintains a single version of a project item's properties, whilst handling associated updates which: add content to a project item, comprising either text or changes to the project item's properties, or a combination of both; are sequenced within the project item using a time stamp that is derived either from the chronological order of their creation, or from an algorithm; may contain either a single change to a project item property, or multiples changes to multiple properties, and following an algorithm, the said property change(s) can be used to replace the relevant property value(s) in the project item; providing a user interface to record meeting minutes which can integrate user interfaces designed to capture project item content, allowing for both the capture of the meeting minutes and the identification of content for exportation to a project register; managing meeting item data, using a design which can process the exportation of project item content from a meeting item to a project item.

2. The method of claim 1, further comprising an algorithm to assign to all new project item updates an 'update obtained time', a derived time stamp used to sequence the project item's updates, which specifies that: if a project item update comes from a source other than a meeting, then the 'update obtained time' shall be equivocal to its time of creation; if a project item update comes from a meeting, then the 'update obtained time' shall be calculated as follows: if the exportation time is after the recorded meeting end date and time, then the 'update obtained time' of the project item update, shall be equivalent to the meeting end date and time; if the exportation time is before the recorded meeting end date and time, then the 'update obtained time' of the project item update, is equivalent to the exportation date and time.

3. The method of claim 1, further comprising an algorithm to update a project items properties, which specifies that: if a project item receives a new update, and the assigned time stamp for sequencing the new update is equal to or later than the sequencing time stamp of last update in the project item, then the new update shall be considered the most recent update; then 2 if the new update is evaluated as being the most recent, and also contains changes to the project item's properties, then said changes shall replace the relevant project item properties.

4. The method of claim 1, further comprising: a design for handling revisions to meetings minutes that consequently introduce a discrepancy between the revised project items details recorded within the minutes, and previously exported project item details; said design requires re-exporting the revised changes as new updates, which are then assigned the same time stamp as the update they are revising, but differ in having a more recent creation time; a design for displaying to the user the revised updates, and includes layouts in which a revision update is displayed to the user, either: as an overwrite of the existing update; as appended text to the revised project item's description property; as a child of the update been revised, and where multiple revision updates exist, creation time can be used as a secondary sort to display updates in sequence; as new update in immediate succession to the revised update, sequenced using creation time as a secondary sort.

5. A system, comprising: one or more computing devices connected via a network, programmed to perform any one of the methods of claims I to 4;