WO2009132377A1

WO2009132377A1 - Evidentiary information items relating to multiple proceedings

Info

Publication number: WO2009132377A1
Application number: PCT/AU2008/000584
Authority: WO
Inventors: Ian Chivers
Original assignee: DUNNE MONICA MARY
Current assignee: DUNNE MONICA MARY
Priority date: 2008-04-28
Filing date: 2008-04-28
Publication date: 2009-11-05
Anticipated expiration: 2010-10-28
Also published as: US9524478B2; CN102016903A; CA2774662A1; AU2008355717A1; AU2016203349A1; CA2774662C; AU2016203349B2; US20120017174A1; JP2011519086A; EP2281276A4; EP2281276A1

Abstract

The invention concerns managing information, such as managing evidence that is relevant to multiple legal proceedings. After the item has been received and stored in common database (30) it is automatically duplicated (14) to databases of the pre determined (12) related cases (60,70) and (80). The related cases (60, 70, 80) are able to store information that is specific to the relevant case. Aspects of the invention includ a computer system, method, software and user computer generated interfaces fo managing evidentiary information items.

Description

Title

EVIDENTIARY INFORMATION ITEMS RELATING TO MULTIPLE

PROCEEDINGS

Technical Field

The invention concerns evidentiary information items relating to multiple proceedings. For example, but not limited to, the invention concerns managing evidentiary information items that all relate to multiple legal proceedings. Aspects of the invention include a computer system, method, software and user computer generated interfaces for managing evidentiary information items.

Background Art

Proceedings, such as mediations, court cases and tribunal hearings often share common facts and/or issues. As such, multiple proceedings often share common items of evidentiary information that relates to the common fact or issues.

For example, legal proceedings before the court may have simultaneous cases pending, such as where a patentee commences separate infringement proceedings against three different infringers. The cases share a set of facts and issues that are each proved or disproved by items of evidentiary information. For example, a copy of patent itself, and expert evidence on the construction of the claims will be referred to by the patentee during all three proceedings.

Summary of the Invention In a first aspect the invention is a method of aiding the management of evidentiary information related to a first proceedings and a second proceedings, the method comprising:

(a) receiving an item of evidentiary information;

(b) receiving an indication that the item is related to the first proceedings, and is related to the second proceedings;

(c) if an indication that the item is related to the first proceedings has been received, storing the item in a first datastore of the first proceedings, wherein the first datastore is able to store associated with the item first specific data that is specific to the item and the first proceedings; and (d) if an indication that the item is related to the second proceedings has been received, storing the item in a second datastore of the second proceedings, wherein the second datastore is able to store associated with the item second specific data that is specific to the item and the second proceedings.

The method may further comprise: receiving a modification or addition to the item; if an indication that the item is related to the first proceedings has been received, storing the modification or addition to the item in the first datastore; and if an indication that the item is related to the second proceedings has been received, storing the modification or addition in the second datastore. These storing steps may be automatic.

The method may further comprise storing the received item and indications in a third datastore. The method may further comprise the step of receiving an indication that the item can be stored in datastores of the related proceedings, (i.e. released) and then automatically performing steps (c) and (d).

The method may further comprise receiving and storing an indication that the first and second proceedings are related to the third datastore.

The method may further comprise the steps of: receiving and storing in the first datastore associated with the item first specific data; and receiving and storing in the second datastore associated with the item second specific data.

Receiving an indication that the item is related to a proceeding may comprise: assigning a tag to the item; and assigning the tag to the datastore of the proceeding.

The method may further comprise assigning further tags to the item.

An item of evidentiary information includes, but is not limited to, sound recordings, images, videos, links, maps, plans, drawings or photographs.

The item of evidentiary information may also include bibliographic data of the item. The proceedings may be legal proceedings.

The specific data may include comments, relevant issues, whether it is discoverable, an indication of its importance and any other annotations that relate to specifically relate to the associated legal proceedings.

In a second aspect, the invention provides computer software, that when installed on a computer system causes it to operate in accordance with the method described above.

In a third aspect the invention provides a computer system to aid the management of evidentiary information that is related to a first proceedings and a second proceedings, the computer system comprising: an input port to receive the item; a datastore to store an item of evidentiary information and an indication that the item is related to a first proceedings, and is related to a second proceedings, the datastore is comprised of a first datastore of the first proceedings to store the item and associated with the item first specific data that is specific to the item and the first proceeding, and a second datastore of the first proceedings to store the item and associated with the item second specific data that is specific to the item and a second proceedings; a processor to determine if an indication that the item is related to the first proceedings is stored in the datastore, and if so to cause the item to be stored on the first datastore, and to determine if an indication that the item is related to the second proceedings is stored in the datastore, and if so to cause the item to be stored on the second datastore.

The datastore may be distributed. The computer system may itself be distributed with the processor being distributed.

The computer system may further provide a set of computer generated interfaces for presenting the evidentiary information to a secure user group, each datastore having at least one interface.

The interface to the third datastore may be operable to receive the evidentiary information item. The interface to the first datastore may be operable to receive the first specific data, and the processor may operate to store the first specific data in the first datastore.

The interface to the second datastore may be operable to receive the second specific data, and the processor may operate to store the second specific data in the second datastore.

The interface to the first and second datastores may not be operable to receive evidentiary information item.

The interface to the third datastore is not operable to receive specific data specific to the item and a proceeding. The interface to the third datastore may be operable to receive the indications.

The interface may be an online interface, such as a website.

The management and running of related proceedings simultaneously by their nature can be a difficult undertaking. It is an advantage of the invention that it provides a reduction of effort to manage evidence that is common to all proceedings. An advantage of at least one embodiment of the invention includes:

Data Integrity — A superior level of data accuracy can be achieved through the centralisation of the item of evidentiary information and the bibliographic data. A greater level of control can be exercised over the data capture process through the use of controlled look-up fields and a higher level of standardisation can be achieved through the centralised monitoring of the data entry effort. It helps to eliminate the need for repetitious importing and exporting of data across the various proceeding databases as data is further developed.

Resources - As data and analysis need only be entered once on common documents to be available across multiple proceedings, the number of paralegal and legal professional resources which need to be applied to the data capture effort can be reduced. From a technical perspective effort will be minimised as the need to import and export data is all but eliminated from the process. Time - As data and analysis need only be entered once on common documents to be available across multiple proceedings, the time taken to undertake the data capture effort can be reduced. Once again the amount of technical effort to support the multiple cases should be reduced.

Cost - The reduction of time and resources applied to the development of the proceeding databases generates a significant cost benefit.

Brief Description of the Drawings An example of the invention will now be described with reference to the accompanying drawings, in which:

Fig. 1 is a simplified flow chart of the invention;

Fig. 2 is a schematic diagram of the computer system of the invention; and

Figs. 3 to 9 are various examples of the interfaces to the databases used with the invention.

Best Modes of the Invention

In this example multiple proceedings, such as cases, mediations, and other meetings or negotiations share a quantity of evidentiary information that in someway relates to one or more proceedings. These proceedings are referred to here as "satellite cases".

A piece of evidentiary information has two types of information related to it:

1. objective information : based on the factualness of the information.

2. case specific data : based on how the evidentiary information relates to the specifics of the case.

In this example, the item of evidentiary information and its associated objective information is shared by the satellite cases, and is referred here as the "common evidence". An example of an item of evidentiary information is a copy of the document itself. The objective information is usually bibliographic and includes: a unique identifier document type, selected from a set of possible types whether the document represents the original or a copy the date of the document related to which parties or organisations whether the document is "released" (discussed in further detail below) The case specific data is not part of this common evidence and is not shared. Examples of case specific data include issues assigned to the document, the importance of the document and any comments, or annotations made to the document.

In this example, the invention is implemented using a computer system and software to store and manage evidentiary information for multiple proceedings.

The method of creating and managing the satellite cases and common evidence will now be described with reference to the flow chart of Fig. 1 and the computer system schematically shown in Fig. 2.

Firstly, a device to connect the multiple satellite cases that rely on common evidence and to store the common evidence must be created 10.

In this example, a database 30 connected to a server 40 is created that will store all the documents common to the set of satellite cases. This database 30 will be referred as a "common case". The structure of the common case 30 is the central element within a group of multiple related cases. Its structure is similar to satellite cases (discussed below). It has additional structure and functionality to allow it to act as this central element. At the same time the common case has limited functionality by being able to accept and store only objective data (and no case specific data). A common case is the distributor for meta-data publication/updates into one or more satellite cases. The common case 30 contains the objective meta-data for all the documents that are part of the broader group of related cases, and also provide a single data entry point for the other non-evidentiary data such as usernames, passwords, and group memberships.

To aid setup, this additional functionality and limitations of functionality for the common case could be achieved by running a script on an otherwise standard case.

In this example all the evidentiary documents and objective data for the common case 30 are stored in the one database. This database 30 could of course be a distributed database (not shown). The common case 30 is connected to a server 40 that in turn is connected to the Internet 50. In this way, contents of the common case 30 can be accessed remotely using this connection to the Internet 50. Next, the satellite cases are created 11. Satellite cases are a database that is part of a group of related cases, and is limited in functionality to subjective data analysis tasks. A satellite case receives evidence items and objective data from a single common case 30. The documents contained in a satellite case are determined by tag-to-case mapping within the common case (discussed later below). These satellite cases are created as separate databases on the same or different server as the common case 30. A database for a satellite case is referred to here as "satellite case".

In this example, three satellite cases are created named "satellite 1" 60, "satellite 2" 70, and "satellite 3" 80. Satellite 1 60 and satellite 3 80 are connected to server 88 that is inturn connected to the Internet 50. Using this Internet 50 connection, these satellite cases 60 and 80 are able to receive the common evidence. Satellite case 70 is connected to the server 40, and it uses the common connection to server 40 to receive the common evidence on the common case 30.

The three satellite cases 60, 70 and 80 are then linked as being related to the common case so that they function as a group 12. This is done at an interface for the common case 30 as shown in Fig, 3. In this example the user accesses the interface using the personal computer 90 that is connected directly to the server 40. Alternatively, using the Internet connection 50 the interface could be viewed remotely 56. This interface is the interface for the management options for the common case, and in particular the management options related to the module "Case Setup" 62. From here the icon representing the "Satellite Cases" 64 is selected to provide a list of all available cases that are displayed on the right hand side of the interface 66. This list may be limited to the cases directly linked to server 40, or may include a search for satellite cases connected to the server 40 using the Internet 50. Cases that are currently linked to the current common case will be pre-selected, as indicated by the tick in the box 68 for the satellite case Satellite 1 60. In this example, a satellite case can only be part of one related group of cases. Consequently, if cases are already part of a different common evidence group of related cases, they will not appear in this display.

Establishing a link to a satellite case will setup the selected satellite case with the necessary database configuration to allow syndication between the common case and the satellite case. Syndication is understood here to mean to publish, or supply for simultaneous publication between multiple systems. Performing this action configures the satellite case to receive and store from the user only data that is subjective to the satellite case, referred herein as the "subjective analysis mode". That means that the satellite case is not able to receive data that is objective to the satellite case, referred herein as "objective analysis mode", other than from the common case 30.

To create a link between the current common case and a satellite case, the user ticks the checkbox next to the appropriate case and then clicks the update button 88. In this example all three satellite cases 60, 70 and 80 are linked in.

Next, tags are created to associate items to one or more satellite cases 13. Firstly, the tags must be created 13(a). Tags are an indication that a group of evidentiary information have something in common and are in someway related. Using tags is a good way to save search results, or group related items into a set. Here, tags are mapped to satellite cases to become part of the common case architecture. These tags defines how the evidentiary information is distributed. Selecting a simple, logical, easy to manage tag hierarchy will assist in being able to identity at a glance precisely how the evidentiary information is distributed throughout the satellite cases.

There are many different ways that you could logically structure a tag hierarchy to best delineate how documents are mapped into the satellite cases and the most suitable structure should be identified and applied.

The tags that define the satellite case mappings may not be the only tags of the common case. Therefore in this example as shown in Fig. 4 a Level 1 tag called 'Satellites' 92 is created that can store all the individual satellite case/tag maps. Under this parent tag, sub-tags 94 are then created for each satellite case.

It may be helpful to further break-down the tag hierarchy into more discrete bundles of documents. Some examples of categories that may be useful are:

• Documents that are only relevant to this case;

• Documents that are common to multiple cases, but not all; or

• Logical groups of categorised documents. It may also be appropriate to create a tag called "common to all", that is comprised of all the documents that will be common to every satellite case.

The important aim is to implement a tag hierarchy that is easy for users to understand, and clearly allows the identification of:

• Which documents belong to a specific satellite case; and

• Which specific cases contain a given document.

The remaining tags that are not associated with cases are created and used to simply group documents that are on the common database. For example, these tags could be used for data entry purposes, with a tag created for each user.

Once a tag for each satellite case is established, a mapping between the designated satellite case and corresponding tag is created 13(b). The purpose of associating a satellite case with a set of tags is to specify the documents that will be mapped to the case. In simpler terms, associating a tag with a satellite case is the equivalent of saying that documents assigned to tag 'A' belong in Satellite Case 'A'.

Referring to Fig. 5, clicking on the Case Mappings module 100 on the common case management interface displays the cases that are were selected as satellite cases at step 12 and the tags 110 present in the common case from step 13 (a). From this screen you can either select a case and assign tags to it, or select a tag and assign case(s) to it.

To open the Case Mappings Module, click on the Case Mappings 100 icon under the Case Setup tab.

To associate a satellite case with one or more tags, click on the case you wish to assign to a tag in the CASES section 102 in the top left, in this case "Satellite 1" 103 is selected. This will display the available tags including those that are already assigned to the selected case in the ASSIGNMENT section 104 as shown in Fig. 6. Tick the tag(s) that are to be associated with the case and click the Apply button 106.

This can be repeated for satellite cases "Satellite 2" and "Satellite 3" as required. Alternatively or in addition, tags can be associated with satellite cases 13(b). Referring to Fig. 7, to associate a tag with one or more satellite cases, click on the tag you wish to assign to a case in the TAGS section 110 in the bottom left. This will display the available cases including those that are already assigned to the selected tag in the ASSIGNMENT section. Tick the case(s) that are to be associated with the tag and click the Apply 106 button.

Next, the specific sub-tags (or tags) are then assigned to all the documents that will be part of the corresponding satellite case 13(c). The document is received by the server 40 at an import, such as by CD drive or over the Internet 50 and stored in the common database 30.

Having (i) already identified the cases that are part of the group of related cases for the current common case, (ii) created a tag hierarchy that is appropriate for mapping, and (iii) assigned the relevant tags to their corresponding satellite cases, you are now able to begin tagging documents to these tags and the automated syndication and replication process will begin to work.

This is shown in Fig. 8 where an item of evidence is selected. The possible tags that could be associated with the item are also shown. Here tag "Satellite 1 " is selected to assign this tag to this item. This is repeated for all documents, where tags can be assigned to multiple documents at the same time.

Certain actions, conditions and circumstances that need to be met in order for a document in the common case to be copied into the satellite cases 14. The following conditions are a requirement for documents to syndicate to a Satellite case:

• the satellite case must be selected as being part of the current common case;

• the satellite case must be mapped/associated with at least one tag; • the documents must be tagged to at least one of these mapped tags; and

• the documents must be "released".

There are two ways for a document to syndicate into a satellite case:

1. Assign a tag associated with the satellite case to the document and then release the document for subjective review; or 2. Release the document for subjective review and then assign a tag associated with the satellite case to the document.

Either way, when this condition is met an automatic trigger will copy the item and objective data of the item into all the satellite cases that the document has been assigned to, and the document will then be available for subjective review within the satellite case 15.

Now that the common case, satellite cases and tags have been created the structure can now be used to allow sharing of evidentiary information.

The common case is designed to be the single data entry point for all documents within the common evidence architecture. Single data entry is appropriate because the information is factual and not subject to opinion, and therefore will not change between cases. The satellite cases receive publication of this data from the common case and therefore there is no facility to modify the objective data from within the satellite case. In this example, only a copy of the evidentiary item and the subjective data is copied across. No other information related to the evidentiary information is copied across, such as details of the tags that are assigned to the document.

If any objective data needs to be modified, the changes must be performed in the common case 16. These changes will be automatically applied to each satellite case that as appropriate based on the tag. This process ensures the integrity of the objective data across all cases.

If the documents in the folder have already been tagged to a tag that is mapped to one or more Satellite cases, then the documents will be syndicated to the satellite case upon Release of the relevant folder.

If however, the documents have not already been tagged to a tag that is mapped to one or more satellite cases, then after Releasing the folder you will also need to bulk assign the folder to the relevant satellite tags.

Documents can not be part of a satellite case until they have been released. As described above documents can be released when the folder is released; however, it may be necessary to release a single document (for example, when a new document is added to a folder, or if an existing document is split into multiple documents).

Releasing a single document can be achieved by setting the value of the Released field to 'Yes' as shown at 400 of Fig. 8.

Using an interface to the satellite case, subjective data can be added 15. In this example, Fig. 9 shows the interface for Satellite Case 1. Using this interface an evidence item that has been copied to the satellite database 60 can be viewed. Then, using this interface subjective data, such as making comments, annotating the document, and identifying issues that is related specifically to Satellite 1 can be entered in and is stored on the database 60. This subjective information is not replicated back to any database, such as the common database 30 or database 70 that also store a copy of that piece of evidence. Fig. 9 shows comments 410 on this document that is an example of subjective information. When this document is viewed using the interface to the common database 30, this comment would not be visible.

It is important to note that the objective data relating to document can not be amended using this satellite interface.

If a document that was mapped to satellite case 1 was not "released" it would not be visible from this interface.

The interface to satellite cases 2 and 3 operate in the same way as the interface to the satellite interface 1 with each referring to their own respective database.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the scope of the invention as broadly described.

The process of establishing a link with a common case and a satellite case can be reversed by deactivating the link. No case data is removed or modified when a link is deactivated, however whilst a case is deactivated it will not receive any updates from the common case. The order of some steps of the method is not important. For example, you can add satellite cases after automatic copying of some documents to other satellite cases has begun.

The interface may be username and password controlled and this may provide users with different levels of access. For example, not everyone can change settings on the common case.

In an alternative embodiment the interface to the satellite cases may allow entry of documents directly into the satellite database. In this case using a satellite case interface objective data can only be entered on documents entered directly into the satellite database and not on documents copied over from the common database. This may be achieved by setting a flag representing the source of the item for each item in the satellite cases.

The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS DEFINING THE INVENTIONS ARE FOLLOWS:

1. A method of aiding the management of evidentiary information related to a first proceedings and a second proceedings, the method comprising:

(a) receiving an item of evidentiary information;

2. A method according to claim 1 , wherein the method further comprises: receiving a modification or addition to the item; if an indication that the item is related to the first proceedings has been received, storing the modification or addition to the item in the first datastore; and if an indication that the item is related to the second proceedings has been received, storing the modification or addition in the second datastore.

3. A method according to claim 1 or 2, wherein the method further comprises storing the received item and indications in a third datastore.

4. A method according to claim 1, 2 or 3, wherein the method further comprises receiving and storing an indication that the first and second proceedings are related to the third datastore.

5. A method according to anyone of the proceeding claims, wherein the method further comprises the steps of: receiving and storing in the first datastore associated with the item first specific data; and receiving and storing in the second datastore associated with the item second specific data.

6. A method according to any one of the preceding claims, wherein receiving an indication that the item is related to a proceeding comprises: assigning a tag to the item; and assigning the tag to the datastore of the proceeding.

7. A method according to any one of the preceding claims, wherein an item of evidentiary information is a sound recording, image, links or video.

8. A method according to any one of the preceding claims, wherein the item of evidentiary information includes bibliographic data of the item.

9. A method according to any one of the preceding claims, wherein the specific data includes any one or more of comments, relevant issues, whether it is discoverable, an indication of its importance and any other annotations that relate to specifically relate to the associated legal proceedings.

10. A method according to any one of the preceding claims, the method further comprising the step of: receiving an indication that the item can be stored in datastores of the related proceedings; and then automatically performing steps (c) and (d).

11. Computer software, that when installed on a computer system causes it to operate in accordance with the method of any one of the preceding claims.

12. A computer system to aid the management of evidentiary information that is related to a first proceedings and a second proceedings, the computer system comprising: an input port to receive the item; a datastore to store an item of evidentiary information and an indication that the item is related to a first proceedings, and is related to a second proceedings, the datastore is comprised of a first datastore of the first proceedings to store the item and associated with the item first specific data that is specific to the item and the first proceedings, and a second datastore of the first proceedings to store the item and associated with the item second specific data that is specific to the item and a second proceedings; a processor to determine if an indication that the item is related to the first proceedings is stored in the datastore, and if so to cause the item to be stored on the first datastore, and to determine if an indication that the item is related to the second proceedings is stored in the datastore, and if so to cause the item to be stored on the second datastore.

13. A computer system according to claim 12, wherein the datastore is distributed.

14. A computer system according to claim 12 or 13, wherein the computer system is operable to provide a set of computer generated interfaces for presenting the evidentiary information to a secure user group, the first and second datastore having at least one interface.

15. A computer system according to claim 14, wherein a third datastore stores the evidentiary information and an interface to the third datastore is operable to receive the evidentiary information item.

16. A computer system according to claim 14 or 15, wherein the interface to the first datastore is operable to receive the first specific data, and the processor is operable to store the first specific data in the first datastore.

17. A computer system according to claim 14, 15 or 16, wherein the interface to the second datastore is operable to receive the second specific data, and the processor is operable to store the second specific data in the second datastore.

18. A computer system according to any one of claims 14 to 17, wherein the interface to the first and second datastores is not operable to receive the evidentiary information item.

19. A computer system according to any one of claims 15 to 18, wherein the interface to the third datastore is not operable to receive specific data specific to the item and a proceeding.

20. A computer system according to any of claims 15 to 19, wherein the interface to the third datastore is operable to receive the indications.

21. A computer system according to any one of claims 14 to 20, wherein the interface is an online interface, such as a website.