BACKGROUND OF THE INVENTION Many countries experience major emergencies which require management by public emergency services such as police services, fire brigades, civil emergency services and the like. These may include natural disasters such as floods, cyclones or hurricanes, earthquakes and the like, or man made incidents such as major transport or industrial accidents, or acts of terrorism. Recent Australian examples include the Canberra and New South Wales bushfires of January 2003 and the Sydney bushfires of December 2001 to January 2003.

By bushfires, we refer to fires which are sometimes called forest fires, wildfires or brush fires.

In the course of such incidents information passes among emergency services organisations and between emergency services organisations and members of the public who may be endangered by the incident, emergency services personnel, the media, hospitals and other organisations and individuals.

At the moment these communications processes are difficult to manage.

For example, contact details for fire brigade and police employees will most likely be in formal personnel records of the relevant agency. Contact details for emergency services volunteers may or may not be in centralised records.

Several of these personnel may have officially-supplied pagers or mobile telephones for recall to duty in an emergency situation. However many categories of persons who may potentially be affected by an emergency cannot be identified from any centralised contact records. Such persons include homeowners whose properties are located in a danger area, and relatives and friends of such homeowners who are remote from the danger area but who need to know whether persons or property have been injured or damaged.

These processes are difficult to manage and time consuming. For example, procedures for contacting volunteer emergency workers generally rely

on contact details that are kept in paper form. The accuracy and availability of such paper records are contingent on human fallibility in remembering to keep records up to date and secure.

The mass media are also stakeholders in information about emergencies in order to in turn inform the general public. For example, journalists contact emergency services personnel by telephoning on official and private lines, by visiting key areas and by attempting to get on-the-spot stories. It is thus necessary for journalists and other media representatives to, for example, telephone emergency services control centres to endeavour to speak with personnel. During many such situations the telephone systems and the control centre personnel quickly become overloaded.

The present invention accordingly aims at providing a more reliable system of managing communications relating to an emergency or like situation.

SUMMARY OF THE INVENTION In one aspect, the present invention accordingly provides a system for managing electronic communications among: at least one managing organisation which has a management role relating to an emergency, public event, private event or the like ; and a plurality of external entities which are external to the at least one organisation, each of which entities takes part in the electronic communications in the course of the management of the emergency, event or the like, the system including: a computerised database, that database including data about: the nature of each external entity; the conditions under which electronic communications are to take place between the managing entity and the external entity; the identity of at least one electronic communications medium over which those communications are to take place between the managing entity and the external entity; and at least one address of the external entity in the at least one communications medium,

interface means with which an external entity may update data in the computerised database; and communication means for generating and receiving electronic communications messages between the managing entity and external entities, so that communications with each external entity use the address on the at least one electronic communications medium under the conditions in which electronic communications are to take place between that external entity and the managing entity.

In another aspect, the present invention provides apparatus for managing electronic communications among: at least one managing organisation which has a management role relating to an emergency, public event, private event or the like ; and a plurality of external entities which are external to the at least one organisation, each of which entities takes part in the electronic communications in the course of the management of the emergency, event or the like, the apparatus including: a computerised database, that database including data about: the nature of each external entity; the conditions under which electronic communications are to take place between the managing entity and the external entity; the identity of at least one electronic communications medium over which those communications are to take place between the managing entity and the external entity; and at least one address of the external entity in the at least one communications medium, interface means with which an external entity may update data in the computerised database; and communication means for generating and receiving electronic communications messages between the managing entity and external entities, so that communications with each external entity use the address on the at least one electronic communications medium under the conditions in which electronic

communications are to take place between that external entity and the managing entity.

In yet another aspect, the present invention provides a process of managing electronic communications among: at least one managing organisation which has a management role relating to an emergency, public event, private event or the like ; and a plurality of external entities which are external to the at least one organisation, each of which entities takes part in the electronic communications in the course of the management of the emergency, event or the like, the process including: providing a computerised database, that database including data about: the nature of each external entity; the conditions under which electronic communications are to take place between the managing entity and the external entity; the identity of at least one electronic communications medium over which those communications are to take place between the managing entity and the external entity; and at least one address of the external entity in the at least one communications medium, and generating and receiving electronic communications messages between the managing entity and external entities at the address of the external entity on the at least one electronic communications medium under the conditions in which electronic communications are to take place between the managing entity and the external entity.

It will accordingly be seen that the present invention is a system that provides more timely and more easily managed communications relating to emergency situations.

It will be appreciated that electronic communications messages can be sent from the managing entity to the external entities, from the external entities to the managing entity, between the external entities and internal to the managing entity.

By the term managing organisation, it is meant an organisation having a role in the management of an emergency, public event, private event or the like, such as the State Emergency Service.

By the term entity, it is meant an organisation or individual taking part or having an interest in an emergency, public event, private event or the like.

It will be apparent that in an emergency such as a bushfire, a managing organisation such as the Rural Fire Service would manage communications between entities such as property owners, volunteer fire fighters, and media personnel.

By the term address, it is meant identifying information required for sending communication messages over an electronic communications medium, and include things such as mobile telephone numbers, email addresses (including group email addresses and lists), and fax numbers.

By the term database, it is meant a collection of information organised in such a way that the system can quickly select desired pieces of data, and includes things such as distributed databases, which may be used due to privacy issues as sensitive data is stored by the external entity and only accessed when required.

BRIEF DESCRIPTION OF THE DRAWINGS One implementation of the present invention will be described with reference to the accompanying drawings, in which: figure 1 is a conceptual drawing illustrating overall operation of both hardware and logical aspects of an embodiment of the present invention; figure 2 illustrates, at a functional layer level, the physical architecture of the embodiment of figure 1; figure 3 is an alternative illustration of the physical architecture of the embodiment of figure 1; figure 4 illustrates the conceptual architecture of the embodiment of figure 1, illustrating components of the embodiment from the perspective of users; figure 5 is a sitemap diagram illustrating the different pages of the front-end website and functionality.;

figures 6 to 20 illustrate portion of a user interface related to the front end applications presented to media officers, volunteers and the community according to the present embodiment of the invention; figure 21 is a sitemap diagram illustrating the different pages of the web content management website and functionality and figures 22 to 39 illustrate portion of a user interface for the web content management functionality according to the present embodiment of the invention DETAILED DESCRIPTION In order that the invention may be more readily understood, preferred embodiments of it are described below with reference to the drawings. It is to be understood that various other embodiments and variations of the invention may be produced without departing from the spirit or scope of the invention.

The present invention is not specific to any particular hardware or software implementation, and is at a conceptual level above specifics of implementation.

The following is provided to assist in understanding the practical implementation of one embodiment of the invention.

Figure 1 is a composite drawing illustrating both hardware and logical descriptions of the system 1. As illustrated in figure 1, a system 1 according to one embodiment of the present, invention provides linkages among communications devices illustrated generally at 2 and 3, information input mechanisms illustrated generally at 4, databases 6 that are internal to the system and databases 7 of data providers external to the system.

Communications devices illustrated generally at 2 include devices such as personal computers that provide client access to the system 1 using HTTP/HTTPS and other protocols over a global computer network such as the Internet for example by interfacing through the Internet gateway 8.

Communications devices illustrated generally at 3 include devices such as mobile telephones and pagers that provide one-way or two-way text, facsimile, synthesised voice or other messaging with the system over appropriate wireless channels such as by way of wireless gateway (s) 9.

Content delivery/transport layer 11 of the system 1 provides an interface between the system 1 and telco gateways such as Internet gateway 8 and wireless gateway 9.

Content personalisation and presentation layer 12 provides the presentation and user interface to different user groups such as media, personnel, volunteers and the like by using JSP/xHTML web pages. This layer 'personalises'data output by formatting it for consistency with the communications requirements of each user. For example, messages which are identical in content may be sent to a user who receives the message as an SMS message and to a user who receives it via a web browser running on a desktop PC. The content personalisation and presentation layer 12 formats those messages to respectively meet the presentation requirements of the SMS messaging system and of a web browser.

The application services layer indicated generally at 10 includes application software modules which perform the operational tasks of the system.

Preferred application software modules include a media management module 13, a community/public services module 14, a staff/volunteer management module 16 and a supply & logistics management module 17.

A further module preferably included in the system is a web content management module 19. This module presents interfaces to personnel within emergency services agencies with which those personnel enter web content matter for publication by the system. As explained further below, the web content management-module can also communicate with external databases 7 for the input or capture of third-party data. Non-limiting examples of such third-party data include weather maps, weather forecasts, street maps and other geographic information.

The core platform of the logical architecture indicated generally at 15 includes a number of key components. These components provide user management, a personalisation engine, content management, messaging & notification, site search, reporting and site administration. The functions of these components are described in more detail below.

The system includes a data services layer which is indicated generally at 31. The data services layer 18 manages communications between the core

platform 15 and databases, be they internal or third party. Internal databases include pre-live content such as messages and news, live content, user profiles and an audit log.

As shown in figures 2 and 3, the physical architecture of the system includes server hardware and software indicated generally at 33 and client hardware indicated generally at 32.

The server hardware may be physically located anywhere that is convenient, such as within an emergency service organisation or at a remote site, such as within a telco. By the term telco, it is meant a telephone company providing telecommunications services such as telephony and data communications. This hardware includes a data services layer 31, an application services layer 39 and a presentation services layer 44. Each of these service layers runs software under a server-grade operating system such as Microsoft Windows 2000 Advanced Server indicated at 37,41 and 46 respectively.

The data services layer 31 runs a database management system such as Microsoft SQL 2000 Standard Edition indicated at 36 which interfaces with the application services layer 39.

The application services layer 39 in turn runs applications preferably written in J2EE (Java 2 Enterprise Edition) under a J2EE application server such as the WebLogic product from BEA.

The presentation services layer 44 interfaces with the application services layer 39 and runs presentation server software such as Microsoft Interne Information Server (IIS) for input and output of information over the Internet or other networks to and from client hardware 32.

The data services layer 31 manages communication with, storage and caching of, the information contained within the system. Structured data passes in both directions between this layer and the application services layer 39. The software applications which run within the application services layer 39 provide the required services to users. Interactions take place in both directions between the application services layer 39 and the presentation services layer 44.

The presentation services layer 44 organises the presentation of information within the system, modifying it in relation to the users who interact

with the system according to their particular needs and method of communication or interaction.

The services provided by the application services layer 39 are shown in more detail in figure 4.

The components 150 to 159 in the framework of the messaging platform 15 represent the shared services which enable the system to provide capabilities that apply across all of the software modules such as 13,14, 16,17 and 19 of figure 1. It will however be appreciated that not every software module (13,14, 16,17 or 19) will necessarily be accessed by each of the user groups. The functionality provided by the shared services components 150 to 159 is as follows : The user management component 151 allows parties to manage information relating to records of those who are registered within the system.

The personalisation engine component 152 provides each party to the system the ability to modify the amount and type of information that is presented to them by the system. Parties may also modify the user interface, prior to system implementation as previously defined in this document. It is preferred that in any practical implementation, it is not possible for individual users of the system to dynamically modify the user interface.

The content management component 153 provides the capability for those who have authorisation to use this component to input, distribute and store particular classes of information, and manage the variables relating to those classes of information.

The messaging & notification component 154 provides the instructions which the system utilises to manage alert mechanisms and distributes the appropriate alert information to the relevant parties. This component also receives, correlates and records response messages from the relevant parties.

The site search component 155 provides the capability to search for information residing within the system according to variables specified by

any party utilising this component, and provide the location of the information that meets the stipulated variables.

The reporting component 156 provides the capability for the system to produce statistics in relation to a number of areas which may include the performance of the system, the interaction of the system with external components, and the interaction of information and components within the system itself.

The site administration component 157 allows authorised users to configure the variables relating to the method which the system uses to manage the routing of external instructions and communication of information to external components.

Those modules 13,14, 16 and 17 on the outer edges of the framework represent the functional modules which enable specific capabilities to the respective constituent groups, namely media, community/public, volunteers/staff and suppliers. These modules also enable the emergency services agencies which administer the system, specific capabilities in respect to management of information relating to those parties respectively.

Operation of a preferred embodiment As described in more detail below, operation of the presently-described embodiment of the communications system is with a view to: 1. managing communications between emergency agencies and the media; 2. informing population of the local area under threat; 3. informing the population of the broader community which is likely to come under threat in several days time; 4. meeting the information needs of the broad community; 5. communicating information to persons remote from the threatened area who are seeking information about family or friends in the threatened area; 6. notifications of recalls from leave, RDO or the like for salaried emergency service staff and volunteers, 7. notifications to volunteers of likely call-out for duty as an emergency develops;

8. immediate call-up of volunteers for emergency duty; 9. providing information to volunteers inquiring about call-out requirements; 10. self-management by volunteers'of personal information and call-out availability ; 11. pre-planning logistics arrangements; 12. placement of urgent requests for supplies for incidents; 13. communications to/from units in the field unable to communicate by radio but who have access to mobile telephone coverage; and 14. enabling mobile forward command/control units to send information/requests to central command.

The management of interactions between the system and members of the mass media is representative of the operation of the system. Those interactions typically also involve a media liaison officer in an emergency services agency.

Those typical interactions are now described with the aid of the sitemap diagram of figure 5 and example web interface of figures 6 to 20.

As shown by the sitemap diagram of figure 5, the web interface presented to an external user who is a member of the mass media preferably includes a registration process illustrated at 601 and interactions that are assessable through homepage tabs illustrated at 602.

The web pages used in the registration process 601 are illustrated in figures 13 to 20. Those web pages are typical of a web-based sign-in or registration process otherwise than for the pages illustrated by figures 17 and 20.

The pages illustrated by figures 17 and 20 allow a mass-media user of the system 1 to create an'alert profile'.

As shown in figure 17, the web page that is indicated generally at 2301, the alert profile creation process first requires users to select the communications medium (s) by which they wish to receive alerts. Preferred communications media include by mobile telephone (by way of an SMS, MMS or synthesised voice message), e-mail, fax, pager or a combination of two or more of these. It will be apparent that the system can support any type of communications medium which can be specified by an address in the database, and for which a suitable delivery device exists.

Other areas of the web page provide the facilities by which users specify the nature of the alerts about which they want to be notified. Preferred criteria for specifying the required alerts include : the geographic area involved (such as a specified city, region of a state, or state) and the nature of the emergency (such as new fire, fire update or general). Optional functionality can be included which allows users to specify that alerts that are generated during user-specified hours of the day are not to be delivered, or are to be held and delivered outside those specified hours.

Once mass-media users are registered or signed-in, the top level of their interactions with the system is by way of the homepage tabs represented at 602 in figure 5 and by the pages represented by figures 6 to 12. As illustrated by figures 6 to 12, the registered mass-media user is presented with a set of home page tabs 701 to 707 which preferably include'My Alerts','My Reports','Search', 'Alert Profile'and'Personal Details'tabs. Optional functionality can be included under a'News'tab, providing users with a listing of published news items which meet criteria specified in the user's profile as previously registered. The listing of news items includes a synopsis of each item and a link to the full text of the item.

Under the alerts tab 701 in figure 6, users are presented with a listing of alerts which have been sent to the user over the past week and therefore meet the criteria specified in the user's alert profile as previously registered. The listing of alerts includes a synopsis of each alert and a link to a full report on the alert and/or the alert history, in this example fire history, which is a listing of all alerts with the same fire name. Users are also able to reorder and search the listed alerts by specifying search criteria, such as severity, time period, State and keywords, on a data input form located next to the listing.

Under the reports tab 702 in figure 7, users are presented with a listing of reports which meet criteria specified in the user's profile as previously registered.

The listing of reports includes a synopsis of each report and a link to the full report. The full report as indicated in figure 9 contains full details of the fire report including location details, fire behaviour and damage reports.

Under the search tab 704 in figure 8, users are presented with a data input form to specify search criteria. It is preferred that the search form includes fields which allow for searching of various categories of items (such as emergency

alerts and emergency reports) on a current or historical basis and on a geographical basis. It is similarly preferred that the search form includes a field for the entry of a keyword or keywords. Upon submitting the search criteria, users are presented with a listing of search results as illustrated in figure 10 including alerts or summaries of reports matching the criteria entered.

Under the alert profile tab 706 in figure 11, users are presented with a data input form which allows for the changing of the user's profile. The user is presented with options, similar to the options that were presented at the user registration stage, including details of communications medium (s) available to the user, preferred communication means, the nature of the alert and the geographic region of the alert. Data entered at registration is displayed in the data input fields and may be updated. Users are also able to deactivate all alerts and reactivate them when they are ready.

Under the personal details tab 707 in figure 12, users are presented with a data input form which allows them to change their registered personal details such as name, address, telephone numbers, username and password.

It will be appreciated that members of the media are not the only persons who may register contact details within the system 1 as illustrated in figures 13 to 20. The software of the emergency communications system also provides facilities for the registration of persons or entities such as: 1. property owners, of the location of their property (particularly of property in regions prone to emergencies such as fire, flood, cyclones and terrorist incidents); and 2. the public generally, indicating that they wish to receive information about a specific emergency which affects a friend or relative 3. authorised users of the web content management admin system It will be appreciated that interactions between the system 1 and some other categories of users will be analogous to the interactions between the system 1 and mass media users. For example, contact details and preferred methods of communication are stored within the system 1 in respect of users such as property owners, emergency services volunteers, employed emergency services workers and suppliers. Messages passed to property owners include such items as alerts on the outbreak of a fire in the region of the property, reports

on the progress of. fire fighting and warnings to evacuate from the path of a fire, flood or other emergency. Messages passed to emergency services volunteers or workers from the system 1 include items such as calls to attend for duty.

Messages passed to suppliers from the system 1 include items such as request for urgent supplies.

It will be appreciated that registration of users take place in a number of ways, such as users selecting a login name and password, and then registering their own details using the web interface, login name and passwords being issued by the managing entity to the external entities, or the management of user registration being entirely delegated to the external entities which may provide immense advantages in terms of privacy, to the external entities.

Such registration of information from, and communication of messages to, other users of the system 1 are handled by dedicated applications modules such as the community/public services module 14, the staff/volunteer management module 16, the supply & logistics management module 17 and the web content management module 19.

In the cases of emergency services volunteers, it is preferable that users may update their personal details only and any changes to normal availability are made in the form of an electronic message to their brigade captain or personnel officer who is authorised to then update the system.. Similarly, media liaison officers or other responsible officers may update the system with new alerts or reports.

Once responsible officers are signed-in, the top level of their interactions with the system is by way of the homepage tabs represented at 603 in figure 21 and by the pages represented by figures 22 to 39. As illustrated by figures 22 to 39, the responsible officer is presented with a set of home page tabs 801 to 803 which preferably include'Alerts','Reports'and'User Database'tabs.

When a responsible officer is informed of a new incident or an update on a current incident, the responsible officer is able to sign-in to the system and create an alert for transmission to relevant users or create a report for publication to the web interface.

Under the alerts tab 801 in figure 22, the responsible officer is presented with an alert history and a listing of all sent alerts, which they can then manage.

As illustrated in figures 23 to 29, after creating a new incident, or otherwise, the responsible officer can create a new general, fire alert or call out alert by generating (for example) an SMS message for transmission to selected or all users who have been identified as relevant to a new emergency situation such as a fire. The responsible officer may create a new alert message by selecting the alert type and inserting the appropriate details into an input form illustrated in figures 23 to 29. This alert is then sent to users via the communication medium (s) specified if the parameters of the new alert match their alert profile, as registered.

For example, an SMS message is sent to each relevant volunteer regarding the fire emergency and contains instructions about what action the volunteer is to take in response. This message may also require the volunteer to confirm if they are available for duty or not.

Optionally, these messages can be automatically re-sent at regular time intervals (such as every 5 to 10 minutes) until the volunteer sends a confirmation of receipt of the message or until the message repetition is otherwise cancelled.

The responsible officer may also view a delivery report, illustrated in figure 30 preferably including the delivery statistics for each of these alerts, a graph outlining these delivery statistics, details of any undelivered alerts and a listing of all reports created and published online by the user, which they may then update if required.

It will be apparent that there are major advantages in relation to privacy because the responsible officer does not need to be shown the addresses to which the electronic communication messages are sent, as the process of sending these messages are automated once the responsible officer selects the recipients of the message. In circumstances such as a listing of police officers it is most advantageous to have the personal details of individual police officers only accessible by the system and hidden to individual users.

Along with all sent messages, the responsible officer is presented with a listing of all messages received from volunteers in regards to a particular incident, which they can then filter or reply to by SMS message, similar to a typical email inbox. As replies are received from volunteers, a status report can be generated which displays the status of all volunteers that have replied to the call out alert.

This report can be printed, or emailed as required.

Under the reports tab 802 in figure 31, the responsible officer is presented with a listing of published reports. Using a report input form such as is illustrated by figures 32 to 35 a media liaison officer or other authorised persons within an emergency service may input details of an emergency. It is to be appreciated that information items captured by an input form such as is illustrated may include items that are of use or interest only internally to the emergency service and that not all of these items would necessarily be published to media or other end users.

Under the user database tab 803 in figure 36, the responsible officer is presented with a listing of users, which they can then manage. For example, the brigade captain is able to search through and maintain the volunteer database amending such things as personal details, normal availability, qualifications and the brigade crew to which a volunteer is assigned. A new brigade crew can also be created by authorised users if required. As illustrated by figures 37 to 39 a responsible officer may enter the details for a new user.

In the case of suppliers, along with their personal details and notification preferences, they are able to pre plan emergency logistics arrangements. The supply & logistics management module 17 also automates the supply purchase and authorisation process, and allows the incident management team and other authorised users to notify suppliers of urgent supplies required.

As illustrated in figure 1, web content management module 19 presents data entry web pages such as those illustrated at 4 by which emergency services personnel enter data relating to new emergency situations and updating data about existing emergency systems.

Data entered by emergency services personnel, via the content management tool is processed by the messaging platform 15 and stored within the databases illustrated at item 6 in figure 1. In the course of processing that input data, the messaging platform 15 also generates the alerts and reports that are specified by the inputs from other internal web content management module users, such as media liaison officers. The Content Delivery/Transport Layer 11 propagates submitted alerts into messages of various formats (such as SMS, MMS and Email) and connects to delivery devices 8,9 for transmission to users over the specified communications medium. As these messages are successfully delivered, positive delivery acknowledgements are received and logged.

It will be appreciated that additional features utilising the modules described can be incorporated as required.

The present invention may be implemented in many different ways, and with numerous variations and additions as will be apparent to those skilled in the art.