AU2015238783A1 - Event response management method and apparatus - Google Patents

Abstract

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 42 Apparatus for managing users in response to an event, the apparatus including one or more electronic processing devices that receive user information from at least one user, the user information being indicative of at least one of a user status, collaboration status, user requirements and user capabilities, provide information to the at least one user, the information relating to at least one of the event, immediate environment, available resources and other users, determine actions to be taken by the at least one user and update at least one of the resources data and the user data in accordance with the user instructions. Fig. 1 Receive user 100 information Provide 110 information Determine user 120 actions Update data for 130 resources or user Fig. 1

Description

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 EVENT RESPONSE MANAGEMENT METHOD AND APPARATUS Background of the Invention [0001] This invention relates to a method and apparatus for managing users in response to an event, such as an emergency or other incident. Description of the Prior Art [0002] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates. [0003] During natural disasters or humanitarian incidents information is often slow, inflexible, out of date, or difficult to understand. Furthermore, human behavior during a disaster can be difficult to predict and/or manage, which creates challenges for all stakeholders around preparation, response, and timeliness. [0004] In terms of preparation, even with adequate warning there is often a wide range of responses, such as some individuals preparing well and following advice, some taking no action and then others waiting until the last minute before taking action. Particularly in this latter case, this leads to elevated stress levels that in turn lead to rushed and/or panicked activities, which invariably create unexpected demand, confusion, further inactivity, or the like. [0005] During an event, there is often little information for individuals, other than news broadcasts, which are typically very general, do not provide specific contextualised advice for people based on their circumstances and don't provide for engagement, but rather are a one-way communications model. [0006] Whilst social media channels provide mechanisms for communicating, these are often unregulated meaning little concrete guidance is provided. Furthermore, the data is unstructured, and there is a huge volume, meaning it is difficult to identify relevant data.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -2 Finally, data and user validation and/or integrity is non-existent, meaning much misleading or inaccurate information is disseminated. [0007] Google provides a number of tools to assist during emergency situations. This includes Google Public Alerts, which allows individuals to go online to search for the latest emergency information, Google Person Finder, which provides an open platform for individuals and organizations to let people know who they're looking for and to enter updates about missing persons and Google Crisis Map, which puts critical disaster-related geographic data in context, and in a map-based viewing frame optimized for usability across a range of browsers and mobile devices. However such tools suffer from a number of drawbacks, including a lack of proper oversight and data validation, meaning there can be inaccuracies in the information presented. There is no real time behaviour data collection and analysis, meaning the model is reactive rather than proactive, and tends to be a passive presentation of information. Technical competency can assist in maximising the effectiveness of the tools, which is not always feasible either for end users or agencies. [0008] Accordingly, these mechanisms still provide only limited capabilities. Summary of the Present Invention [0009] In one broad form the present invention seeks to provide apparatus for managing users in response to an event, the apparatus including one or more electronic processing devices that: a) receive user information from at least one user, the user information being indicative of at least one of: i) a user status; ii) collaboration status; iii) user requirements; and, iv) user capabilities; b) provide information to the at least one user, the information relating to at least one of: i) the event; ii) immediate environment; H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -3 iii) available resources; and iv) other users; c) determine actions to be taken by the at least one user; and, d) update at least one of the resources data and the user data in accordance with the user instructions. [0010] Typically the one or more processing systems determine actions by at least one of: a) receiving an indication of actions from the user; and b) generating user instructions defining the actions to be taken. [0011] Typically the one or more processing systems: a) generate user instructions using: i) response rules specific for the respective event; ii) the user data; and, iii) at least one of: (1) resources data indicative of available resources; and, (2) event data indicative of a status of the event; and, b) provide an indication of the instructions to the user. [0012] Typically the one or more electronic processing devices display an indication of at least part of user data of one or more other users to the at least one user, allowing users to collaborate to provide mutual assistance. [0013] Typically the one or more electronic processing devices: a) receive event details; and, b) use the event details to at least one of: i) update event data; and, ii) update resources data. [0014] Typically the one or more electronic processing devices receive the event details from at least one of: a) at least one sensor; b) users; and, c) an event response agency.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -4 [0015] Typically the one or more electronic processing devices: a) receives event details from a user; b) determines a trust rating associated with the user; and, c) uses the event details based at least partially on the trust rating. [0016] Typically the event details includes at least one image of at least part of the event. [0017] Typically the one or more electronic processing devices use event data to provide event information to at least one of users and an event response agency. [0018] Typically each user is assigned to one of a number of nodes, and wherein the one or more electronic processing devices: a) determine a user node assigned to the user; and, b) determine at least one of instructions and information at least partially in accordance with the user node. [0019] Typically the user node is assigned at least one of: a) based on a geographical location of the user; b) environmental factors; c) timelines; d) risk impacts; e) by aggregating nodes; and, f) dynamically. [0020] Typically the one or more electronic processing devices select respective response rules in accordance with the user node. [0021] Typically the one or more electronic processing devices: a) provide one or more questions to a user; and, b) receive user information in response to the questions. [0022] Typically the one or more electronic processing devices use received user information to generate one or more further questions. [0023] Typically the user instructions are indicative of at least one of: H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -5 a) a destination; b) a route to a destination; c) an identity of another user; and, d) assistance required by another user. [0024] Typically the one or more electronic processing devices provides updates to an event response agency, the updates being indicative of changes in at least one of: a) user data; b) event data; c) trust status; d) specific use of keyword; e) online status; and, f) resources data. [0025] Typically the event response agency is responsive to the updates to modify an event response plan. [0026] Typically the one or more electronic processing devices: a) receive agency updates from an event response agency; and b) use the agency updates to update at least one of: i) response rules; ii) event data; and, iii) resources data. [0027] Typically the one or more processing devices: a) determine an event type; and, b) select an event profile in accordance with the event type, the event profile including: i) resources data; ii) severity; iii) impact timeframes; iv) level of local preparation; and, v) response rules.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -6 [0028] Typically the one or more processing devices: a) receives an event notification; and, b) determines the event type from the event notification. [0029] Typically the one or more processing devices: a) receive an event notification; and, b) provide an event alert to users. [0030] Typically the one or more processing devices: a) receive an event response plan for a respective type of event from an event response agency; and, b) use the event response plan to create an event profile in accordance with the event type. [0031] In another broad form the present invention seeks to provide a method for managing users in response to an event, the method including, in one or more electronic processing devices: a) receiving user information from at least one user, the user information being indicative of at least one of: i) a user status; ii) collaboration status; iii) user requirements; and, iv) user capabilities; b) providing information to the at least one user, the information relating to at least one of: i) the event; ii) an immediate environment; iii) available resources; and iv) other users; c) determining actions to be taken by the at least one user; and, d) updating at least one of the resources data and the user data in accordance with the user instructions.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -7 Brief Description of the Drawings [0032] An example of the present invention will now be described with reference to the accompanying drawings, in which: [0033] Figure 1 is a flow chart of an example of a method for managing users in response to an event; [0034] Figure 2 is a schematic diagram of an example of a distributed computer architecture; [0035] Figure 3 is a schematic diagram of an example of a processing system of Figure 2; [0036] Figure 4 is a schematic diagram of an example of a computer system of Figure 2; [0037] Figure 5 is a flow chart of an example of a method for user registration; [0038] Figure 6 is a flow chart of an example of a method for creating an event profile; [0039] Figures 7A and 7B are a flow chart of a further example of a method for managing users in response to an event; [0040] Figure 8 is a flow chart of an example of a method for receiving an update from an agency; [0041] Figure 9 is a flow chart of an example of a method for receiving event details from a user; [0042] Figure 10 is a flow chart of an example of a method for selecting actions; [0043] Figures 11 A to 1 ID are schematic diagrams of an example usage scenario; [0044] Figure 12 is a schematic diagram of a specific example of apparatus for managing users in response to an event; and, [0045] Figures 13A to 13C are schematic diagrams of example operations performed using the arrangement of Figure 12. Detailed Description of the Preferred Embodiments [0046] An example of a method for managing users in response to an event will now be described with reference to Figure 1. [0047] In this example, it is assumed that the process is performed at least in part using an electronic processing device forming part of a processing system, which is in turn connected to one or more other client devices and/or other processing systems via a network architecture, as will be described in more detail below.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 [0048] For the purpose of the example, the following terminology will be used. The term "user" is used to refer to an individual, such as a community member, that is interacting with the system. The term "agency" is used to refer to an official body, such as a federal emergency management agency (FEMA) or the like. The term "event" is intended to refer to any incident, situation or episode, in which it is desirable to provide information and guidance to community members, including but not limited to natural disasters, accidents, emergency situations or the like. For example, this could correspond to any one of a number of events, examples of which include but are not limited to hurricanes, typhoons, cyclones, twisters, earthquakes, monsoon events, wildfires, volcanoes or earth eruptions, tsunami, tidal waves, disease-type incidents/outbreaks, industrial accidents, such as chemical or nuclear leaks, conflict situations, such as invasions, or the like. The term "App" refers to a self contained program or piece of software designed to fulfil a particular purpose, namely an application, especially as downloaded by a user to a mobile device. [0049] At step 100, the one or more electronic processing devices receive user information from at least one user. The user information is typically information regarding a current situation of the user, and could include information regarding a current user status, a collaboration status, resources and/or capabilities of the user. The user data is typically used to establish any requirements the user may have, or any capabilities the user can provide which could assist in the current event. [0050] The information could be received in any suitable manner, but is typically transferred from a client device, such as a mobile phone, tablet device, computer system or the like, via a communications network. The information could be provided as part of a message, such as an SMS, email, or the like, or could be submitted via a webpage, or via a specification application, as will be described in more detail below. The user information could also be received automatically from sensors associated with a user's client device. This could include location-based services, such as GPS sensors, or the like, or other sensors, such ambient environment sensors including temperature or air pressure sensors, or the like. [0051] At step 110, at least some information is provided to the user, the information relating to the event, an immediate environment, available resources and/or other users. The information can be provided to the user in any appropriate manner, but in one example is in H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -9 the form of a representation of a user's local vicinity overlaid with the information. This allows the user to understand how the current event is progressing, what resources might be available to assist, and to understand the situation of other users in their vicinity, such as what resources or requirements do other users have or need. [0052] At step 120, the one or more electronic processing devices determine user actions to be taken by the at least one user. The user actions can be determined in any suitable manner, and this could involve receiving an indication of an intended action from a user, or alternatively generating instructions that can be provided to the user to guide the user to take appropriate action. [0053] The type of action will vary depending on the nature of the event and the user's current circumstances, requirements and available resources. For example, the action could be to evacuate to a defined evacuation centre, wait in their current location, or travel to an alternative location to provide assistance to other users. Examples will be described in more detail below. [0054] At step 130, the one or more processing devices update at least one of the resources data and the user data indicative of at least one of a user status, user requirements and user capabilities, in accordance with the user actions. [0055] This can be used to ensure the resource and/or user data is kept up to date, for example to take into account the actions performed by the user. This is important to ensure that other users can take this into account. For example if an evacuation centre has limited spaces available, then once these spaces have been assigned to users, then other users will be directed to alternative options. [0056] Accordingly, the above described process uses user data for each of the users, as well as information regarding resources available and the current status of the event, to allow actions of individuals to be coordinated. For example, this allows users to collaborate with each other, as well as to allow instructions to be issued to people individually. This also provides a mechanism for information regarding the event to be displayed to the user in an intuitive manner, allowing them to more readily understand what actions could be taken. This allows users to act in a more informed manner and/or to be coordinated collectively, H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 10 thereby ensuring users are acting as effectively as possible. This also allows users to be access relevant information and allows users to take into account resources of other users, which cannot be achieved using traditional disaster management techniques. It will therefore be appreciated that this can lead to significantly improved outcomes. [0057] A number of further features will now be described. [0058] In one example, the one or more processing systems determine actions by receiving an indication of actions from the user or generating user instructions defining the actions to be taken. Thus, this allows user to self-assess the action to be taken and/or receive instructions guiding them as to what action to perform. This provides flexibility to users, whilst also allowing proposed actions to be validated or instructions provided if required. [0059] The one or more processing systems can generate user instructions using response rules specific for the respective event, the user data either resources data indicative of available resources or event data indicative of a status of the event. This could be achieved in any suitable manner, but will typically involve applying the rules to the available data using a rules engine, or other similar arrangement, to create defined instructions guiding the user to take appropriate action. Generated instructions can then be provided to the user, using an appropriate mechanism, such as providing the instructions to a client device, using an appropriate communications process, such as email, SMS, via a webpage, in application messaging, or the like. [0060] Accordingly, this allows instructions to be generated automatically, or allows instructions to be issued in the event that a user's own proposed course of action is unsuitable for any reason. This can significantly assist users and avoid the need for users to consider a wide range of different information sources, which could be contradictory, and avoids the need for users to try and self-assess the best course of action to take, and also avoids them being provided with superfluous information, that provides a distraction, leading users to make poor decisions. [0061] Additionally and/or alternatively, the one or more electronic processing devices can display an indication of at least part of user data of one or more other users to the at least one H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 11 user, allowing the users to collaborate, thereby allowing users to coordinate with each other directly. [0062] In one example, the one or more electronic processing devices receive event details and use the event details to update the event data and/or update the resources data. This allows the system to take into account event details received from a variety of sources and ensure this is up to date, so that for example if roads become blocked, this can be communicated rapidly to potentially affected users, allowing users to be directed via alternative routes. The event details can be received from users and/or an event response agency, so that updates can be received from multiple sources, including not only official agencies, but also from individuals that are on the ground. The event information can also be received from one or more sensors, which could include for example, environmental or meteorological sensors, image capture devices, or the like. These could be standard sensing equipment used for regular monitoring and could include CCTV, weather radar, satellite based imaging or sensing or the like. This could also include sensors deployed specifically for monitoring the event, including static sensors, such as pre-deployed sensors, or movable sensors, for example mounted to vehicles such as emergency vehicles or aircraft, including UAVs, or mounted to individuals, such as emergency workers. As a result the event data tends to be more accurate, current and granular, meaning that better instructions can be provided to users. [0063] If event details are received from a user, the one or more processing devices determine a trust rating associated with the user and use the event details based at least partially on the trust rating. Accordingly, this allows the system to assess the likely accuracy of the event details supplied by the user, depending in the level of trust, and then use the event details accordingly. For example, if the user has not previously supplied information, then the event details provided could be treated as possible details, with these only being used once verified by another source. Once a user has provided event details that have been proved to be correct, the user's trust rating could be increased, meaning event details supplied in future could be used immediately. [0064] The event details could be of any appropriate form, but in one example can include at least one image of at least part of the event. Thus, this provides a mechanism for users to H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 12 submit images of incidence, such as fires, floods, road blockages, accidents, or the like, with these being integrated into the event data, so that this can be viewed by other users and taken into account when determining actions to be performed. [0065] The one or more electronic processing devices can use the event data to provide event information to at least one of users and an event response agency. Thus, updates to the event data can be provided to an event response agency, allowing them to update an event response plan, or the like. Similarly, this can be provided to users allowing them to understand how the event is developing. The event information could be displayed in any suitable manner, but in one example this is part of an augmented reality, allowing users to more easily understand information that is relevant to them. [0066] In this regard, the augmented reality is particularly beneficial for a number of reasons, including that it allows disparate forms of data to be combined on a single representation, it can better account for data that is dynamic and/or subject to real-time and constant change and/or it can represent these data forms in a visual way that is simple and importantly, overlaid into the real world, thereby creating a 3-D representation of previously text or 2-D graphical data. Finally, augmented reality can create an environment of spatial contextual awareness. For example, text and 2-D information can be used to create spatial contextual awareness, making it easier for users to understand and interpret the information being presented. [0067] As part of this process, the information and instructions provided to users could be tailored to ensure they are relevant to them, for example by filtering the information to show only information in the immediate vicinity. To achieve this, in one example, each user is assigned to one of a number of nodes, and wherein the one or more electronic processing devices determine a user node assigned to the user and determine at least one of instructions and information at least partially in accordance with the user node. The user node can be assigned based on a range of factors, such as a geographical location of the user, environmental factors, timelines, risk impacts, or the like. Nodes can be defined dynamically and can be aggregated depending on actions of user. Thus, when providing event information to the user, this could be filtered based on the user node, whereas in the case of user instructions, these are typically based on respective response rules that are selected in H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 13 accordance with the user node, so that for example, different sets of instructions could be generated for different nodes. Additionally a node may initially correspond to a single person, with this changing dynamically to represent multiple people, persons or people with new capabilities. Thus, it will be appreciated that nodes can be fluid data points that form, merge, and even dissolve based on actions, behaviours, and the environment. [0068] In order to obtain the user information, the one or more electronic processing devices typically provide one or more questions to a user and receive user information in response to the questions. The use of questions is particularly desirable as this guides the user to provide the information that is required in order to generate the instructions. This can simplify the process and make it more likely that accurate information is provided. Additionally, the received user information can be used to generate one or more further questions, so that the user is presented with questions that are relevant to their current situation, avoiding the need for them to answer unnecessary questions. This helps reduce the burden on the user, again helping ensure accurate information is obtained. [0069] Additionally, user information can be provided automatically using sensors provided as part of the client device, as well as through other interactions. For example, in the event that the mobile device is entering a location with known connectivity issues, or in the event that the user is deactivating the phone connectivity, by turning the phone off or enabling flight mode, details of this can be provided as part of the user information. In this instance, during periods of poor connectivity, information supplied to the client device could be limited and prioritised to ensure vital information is communicated. Similarly, if communication is re-established following a period of no communication, then user information could be provided to reflect this, with vital information being communicated to the user in preference to less important information. [0070] The user instructions can be of a wide variety of forms, and in one example could be indicative of a destination, such as an emergency centre, source of resources, or the like. This could also be indicative of a route to a destination, for example taking into account any route blockages of the like. The instructions could additionally or alternatively by indicative of an identity of another user and/or assistance required by another user. Thus, the H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 14 instructions could be used to guide users to assist other users, for example to provide first aid, resources, or travel assistance. [0071] The one or more electronic processing devices can provide updates to an event response agency, the updates being indicative of changes in at least one of user data, event data, trust status, specific use of keywords, online status (eg: online, knowingly-offline, degraded online, unresponsive), or resources data, allowing the agency to assess how the event and response plans are progressing, taking into account feedback from users of the system. In one example, the event response agency is responsive to the updates to modify an event response plan. Thus, this allows the event response agency to respond to the event as it progresses and modify the response plan dynamically, to adapt to changes in the event. [0072] In one example, the one or more electronic processing devices receive agency updates from an event response agency and use the agency updates to update response rules, event data and/or resources data. Thus, it will be appreciated that there is two-way information exchange with the event response agency, allowing the event response agency to modify the response as the event progresses. [0073] The one or more processing devices can determine an event type and select an event profile in accordance with the event type, the event profile including resources data, severity, impact timeframes, local level of preparation and response rules. Thus, in advance of events occurring, one or more different event profiles can be established for different events. Furthermore, the one or more processing devices can receive an event notification and determine the event type from the event notification, so that event profiles can be accessed and implemented as soon as possible. Additionally, upon receipt the one or more processing systems can receive an event notification and provide an event alert to users. Thus, this can be used to automatically alert users should an event occur. [0074] The one or more processing devices can also receive an event response plan for a respective type of event from an event response agency and use the event response plan to create an event profile in accordance with the event type. Thus, the developments of the event profiles can be performed by the processing devices based on a plan issued by one or more event response agencies.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 15 [0075] In one example, the process is typically performed by one or more processing systems operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2. [0076] In this example, a base station 201 is coupled via a communications network, such as the Internet 202, and/or a number of local area networks (LANs) 204, to a number of client devices 203. It will be appreciated that the configuration of the networks 202, 204 are for the purpose of example only, and in practice the base station 201 and client devices 203 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.11 networks, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as Bluetooth, or the like. [0077] Specifically this could include network architectures deployed as part of an emergency response, such as rapidly deployable cellular networks, UAV or balloon mounted wireless networks, as well as P2P networks, such as mesh networks, or the like. Thus the communications networks could be temporary networks established in response to the event occurring and need not be permanent networks. [0078] In one example, the base station 201 includes a processing system 210 coupled to a database 211. The base station 201 is adapted to be used in managing users in response to an event and in particular, in coordinating users, updating event data, providing event information or the like. The client devices 203 are typically adapted to communicate with the base station 201, allowing user information to be provided, user instructions to be received and displayed and event information to be received or provided. [0079] Whilst the base station 201 is a shown as a single entity, it will be appreciated that the base station 201 can be distributed over a number of geographically separate locations, for example by using processing systems 210 and/or databases 211 that are provided as part of a cloud based environment. However, the above described arrangement is not essential and other suitable configurations could be used. [0080] An example of a suitable processing system 210 is shown in Figure 3. In this example, the processing system 210 includes at least one microprocessor 300, a memory 301, H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 16 an optional input/output device 302, such as a keyboard and/or display, and an external interface 303, interconnected via a bus 304 as shown. In this example the external interface 303 can be utilised for connecting the processing system 210 to peripheral devices, such as the communications networks 202, 204, databases 211, other storage devices, or the like. Although a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (eg. Ethernet, serial, USB, wireless or the like) may be provided. [0081] In use, the microprocessor 300 executes instructions in the form of applications software stored in the memory 301 to allow the process to be performed, as well as to perform any other required processes, such as communicating with the client devices 203. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system event, or the like. [0082] Accordingly, it will be appreciated that the processing system 210 may be formed from any suitable processing system, such as a suitably programmed client device, PC, web server, network server, or the like. In one particular example, the processing system 210 is a standard processing system, such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement. [0083] As shown in Figure 4, in one example, the client device 203 includes at least one microprocessor 400, a memory 401, an input/output device 402, such as a keyboard and/or display, and an external interface 403, interconnected via a bus 404 as shown. In this example the external interface 403 can be utilised for connecting the client device 203 to peripheral devices, such as the communications networks 202, 204, databases 211, other storage devices, or the like. Although a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (eg. Ethernet, serial, USB, wireless or the like) may be provided.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 17 [0084] In use, the microprocessor 400 executes instructions in the form of applications software stored in the memory 401 to allow communication with the base station 201, for example to allow data to be supplied thereto and allowing details of the bidding process to be displayed to participants, such as bidders. [0085] Accordingly, it will be appreciated that the client devices 203 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, hand-held PC, smart phone, tablet, PDA, web server, or the like. Thus, in one example, the processing system 210 is a standard processing system such as a 32-bit or 64-bit Intel Architecture based processing system, which executes software applications stored on non volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the client devices 203 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement. [0086] Examples of the process for managing users in response to an event will now be described in further detail. For the purpose of these examples, it is assumed that the processing system 210 interacts with users via Apps executed by client devices, such as mobile phones or the like. The processing systems 210 can also host webpages, and interact with other processing systems 210 to transfer data therebetween. The processing system 210 is therefore typically a server which communicates with the client device 203 via a communications network, or the like, depending on the particular network infrastructure available. [0087] To achieve this the processing system 210 of the base station 201 typically executes applications software for hosting webpages and running actions, with actions performed by the processing system 210 being performed by the processor 300 in accordance with instructions stored as applications software in the memory 301 and/or input commands received from a user via the I/O device 302, or commands received from the client device 203.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 18 [0088] It will also be assumed that the user interacts with the processing system 210 via a GUI (Graphical User Interface), or the like presented on the client device 203, and in one particular example via a browser application that displays webpages hosted by the base station 201, or a dedicated App. Actions performed by the client device 203 are performed by the processor 401 in accordance with instructions stored as applications software in the memory 402 and/or input commands received from a user via the I/O device 403. [0089] Additionally, for the purpose of explanation, it will be assumed that multiple different processing systems 210 are provided for performing different functions. For the following examples, reference will be made to an agency server that is operated by an event response agency and a management server, which performs the process of managing users. [0090] However, it will be appreciated that the above described configuration assumed for the purpose of the following examples is not essential, and numerous other configurations may be used. It will also be appreciated that the partitioning of functionality between the client devices 203, and the base station 201 may vary, depending on the particular implementation. [0091] An example process for registering a user will now be described with reference to Figure 5. [0092] In this example, at step 500, the user downloads an App onto their client device, for example by downloading the App from an App store, or other source. At step 505, the App displays prompts to the user, prompting the user to enter user information at step 510. The prompts are typically displayed as a sequence of questions and are typically performed to basic background information regarding the user so that this can be used during an event. For example, this could include an identity and demographic information, such as a name, age, gender and place of residence, as well as information regarding capabilities, such as profession, qualifications and basic skills (i.e. first aid or medical training, heavy or specialist vehicle qualifications, verified former service in armed forces or first-responder roles, verified teachers or child-care skills, blue-card holders, JP's clergy, verified trauma counsellors), and resources, such as details of any vehicles. This could also include preferred H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 19 contact mechanisms for different scenarios, such as receiving alerts of events occurring, or to allow contact by emergency services, or the like. [0093] During this process, the user information is uploaded to the management server, which uses this to generate user data, such as a user profile. This process can also be interactive, with answers to previous questions being used to select additional information. For example, if the user indicates they have a vehicle, additional questions regarding the capacity of the vehicle could be asked, by having the management server 515 generate a question, which is displayed via the App. [0094] The questions can also be adapted to ascertain the preparedness of the user for events. This can therefore assess whether the user has an emergency plan, and suitable resources to cover a range of different events occurring. This can be used to allow the management server to provide information to the user at step 520. For example, the management server could determine a level of preparedness, and provide an indication of this to the user, together with additional information regarding additional steps they can take to improve their preparedness level. The information presented would typically be tailored to the circumstances of the user, and may for example depend on events that are at risk of occurring where the user resides. For example, if the user lives in an area prone to hurricanes, the information provided could advise them how to prepare for a hurricane, and may differ to the advice provided to a user in a region at risk of bush fires. [0095] The above described process can advantageously be performed in advance of events occurring, and therefore assist in users taking basic precautions, such as ensuring they have access to emergency lighting, food, water, communications and first aid supplies, and have an evacuation process prepared should the need arise. These basic steps can assist in ensuring that users are adequately prepared in case events, such as emergencies, natural disasters or the like arise, which can significantly assist in reducing the level of crisis management needed. [0096] If the above described process is only commenced once an event has already started, it will be appreciated that this process could be tailored to ensure that user information H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 20 relevant to the event is collected, with event information being provided by the management server at step 520, as will be apparent from the following description. [0097] An example of a process for creating an event profile for implementing a response plan will now be described with reference to Figure 6. [0098] In this example, at step 600 a response plan is developed by an event response agency. In this regard, it is typical for event response agencies to create different response plans for a range of different events in different areas, and these are typically created and update periodically, taking into account current best event response practice and available requirements and resources in a given area. This process is typically performed in conjunction with consultation with experts and will result in creation of an action plan including an outline of the key stages and steps involved in responding to events. It will be appreciated that this is existing practice and will not therefore be described in any further detail. [0099] At step 605, the response plan is typically provided to either the agency or management server, which uses the plan to develop an event profile. The event profile is a computer readable outline of the plan, requirements and resources, and could be generated automatically and/or using manual input, as will be appreciated by persons skilled in the art. [0100] At step 610, rules are developed as part of the profile. The rules define how users should be instructed depending on the prevailing conditions, including the state of the event, their capabilities and requirements. The rules will typically include default rules that apply to a wide range of scenarios and rules specific to particular situations. Again the rules are typically developed through a combination of automated processes, such as selecting from predefined standard rules and manual processes. [0101] At step 615, the server creates resources data, which typically outlines at a high level the type of resources that are likely to be available during an event. This will also typically define information that will need to be collected once the event occurs, for example information regarding resources that are functioning and/or otherwise available.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -21 [0102] At step 620 an event profile is created for the particular event(s) covered by the response plan, with this being stored for retrieval as needed. [0103] It will be appreciated that the above described process is typically performed during a period of consultation with the event response agency and one or more event management experts. This is typically performed in advance of events occurring, and is usually performed for a number of different events, so that profiles can be implemented immediately when an event occurs. [0104] An example of this will now be described with reference to Figures 7A and 7B. [0105] In this example, at step 700, the management server receives an event notification. This can be achieved in any one of number of manners and can be performed by monitoring feeds of emergency services and news reports, monitoring information such as weather warnings, receiving a notification from an event response agency or the like. It will be appreciated that in some situations a preliminary notification may be received with this being verified before action is taken. [0106] At step 705, the management server selects an event profile appropriate for the relevant event and/or geographic area. At this point, the management server may request or receive additional information from the agency server as part of an update process. This can be used to update information regarding available resources or the like as will be described in more detail below with reference to Figure 8. [0107] At step 710, the management server generates an event alert, which can then be provided to users at step 715. This can be achieved in any one of a number of manners and may for example depending on defined user preferences. Typically however push notifications will be provided to any registered Apps, and optionally additional notifications will be provided, such as emails, SMS, display on a website, or the like. [0108] At step 720, users can be prompted for any required information, with this being used to update user data at step 725. This will typically include at least location information, and may include retrieving location information from the user's client device, to determine whether the user is in a location that is relevant to the event. Thus, at first instance, the user H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 22 could be simply informed of the event and its expected geographical impact, asking the user to indicate if they are likely to be affected. So for example, if the user has location services deactivated on their mobile device, the system will typically assume a default location based on information provided during registration. However, if the user is not in that location, for example if they are overseas, assistance may not be required, in which case the user can indicate this and no further action is taken in respect of that user. This avoids the system taking this user into account when determining instructions for other users. [0109] It should be noted that at this point, the user could also indicate that at this time no further action is required for them, but still elect to provide event and/or user information. For example, in the event of a flood, the individual may be located in a property sufficiently above predicted flood levels meaning they will not impacted upon, in which case they could indicate no action is required. However, we may wish to prompt the user to capture any evidence of rising water or flood activity that conflicts with known information. For example, a user could take a photo of flood water rising up through storm water drains and include in the photo an identifiable landmark (like a street sign or identifiable infrastructure (such as traffic lights or an Energex sub-station)). By capturing this information and feeding this in real time to upstream agencies who can then verify (and pass down trust points), real time learnings can be captured in relation to event activities. [0110] In any event, the user may also be required to provide any other relevant information at this stage, for example to provide details of any resources they have access to or need of, as well as details of any assistance required. Additionally, the user's may be requested to capture images of their surroundings either by way of photographs and/or video, allowing this to be integrated into event and/or resource data. [0111] This can be an iterative process, with users being displayed a series of questions, with further questions presented depending on the responses provided. So for example at step 730 it can be determined if further information is needed, and if so the process returns to step 720 allowing further user information to be supplied. [0112] At step 735, the management server assigns the user to a node, depending at least in part on the information provided. The node is used to define a group of users allowing H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 23 groups to be managed collectively, thereby simplifying the management process, although it will be appreciated that this is not essential. The user nodes are typically defined at least in part geographically for example depending on the user's vicinity to the event. For example, users within 5km of an accident could be assigned to a different node to users within a 5 10km distance. However, this may also be based on other factors, such as available resources, capabilities or needs, so that for example all user's requiring assistance could be assigned to a different node to user able to provide assistance. Additionally, nodes could be assigned based on environmental factors, so that for example users downwind of a chemical spill may be assigned to a different node to users upwind, or could also be based on timelines or risk impact which could be measured in minutes, hours, or days. [0113] Once assigned to the node, the next step will depend on a selection made by the user. For example, the user could request to view information at step 740. The information could be displayed in any appropriate manner, but in one example this is performed by displaying an augmented reality view, such as a map, streetview representation or the like, including icons or markers corresponding to other users, available resources, specific event information or details, or the like. For example, agencies can use an augmented reality view to pre position augmented data that can be switched on when required and subsequently updated from a central point. This allows live information to be displayed, so that users can view this and select actions to be performed based on live information regarding current resources at different locations. [0114] To achieve this, the management server queries the event, resource and/or user data at step 745, and generates the representation 750 for display to the user via the user client device. The data is queried in accordance with the node to which the user is assigned, thereby restricting the information displayed to information that is pertinent to the user. Thus, for example, the representation could include information regarding resources or details of the event within the vicinity of the user. For example, this could include details of road blockages, the location of resources or the like. Additionally, this typically shows other users in the vicinity together with an indication of their capabilities or requirements, allowing the user to select to provide assistance to the user, or conversely request assistance from H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 24 another user. The user can select an action to be performed at step 755, as will be described in more detail below, allowing an indication of this to be provided to the management server. [0115] Alternatively at step 765, the user can request that instructions are generated and transferred to them. [0116] In either case, at step 770 the management server selects rules relating to the respective node and then at step 775 either validates actions proposed by the user, or generates instructions. Thus, the management server applies the rules to the current user data, as well as event data regarding a current event status and resources data regarding available resources, using this to validate proposed instructions or generate new instructions for the user. [0117] For example, the instructions may direct the user to perform certain actions, such as evacuating to an evacuation centre, remaining in their home, or the like. Instructions could also direct the user to seek assistance or resources from or provide assistance or resources to other users. The instructions are typically provided in the form of a sequence of easy to following instructions, allowing the users to focus on simple attainable goals, eventually directing users to a desirable end outcome. [0118] The information can be provided in any one of a number of manners. For example, this could be in the form of a series of simple text based instructions, so users could be instructed to proceed to a waypoint and confirm once this is reached, allowing guidance to the next waypoint to be provided. Alternatively, this could be achieved using the augmented reality visualisation, showing a route and/or directions in which to travel. Typically the system can be configured to allow users to select how they wish to receive and consume information. So someone trained in reading 2-D maps (i.e. with a military background) can receive information in a way that fits their desired information needs, whereas other users could select more simplistic and visual information to help lower stress and/or provide for more hands-on help. [0119] Additionally, by generating the instructions based on the current user data, this optimises the instructions that are generated (or validated) based on the users profile and in particular based on the user's skills and requirements, as well as their capabilities, such as a H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 25 nominated level of mobility. This ensures that should travel be required, the users are sent to the most appropriate destination. [0120] It should also be noted that in generating the instructions, the management server takes into account available resources more broadly, so that users are directed not only taking into account their capabilities and requirements, but also those of other people. For example, more mobile users may be directed to more distant recovery centres so as to ensure less mobile users can minimise how far they need to move. Thus, a user may nominate that they wish to travel to the nearest resource centre. However, if the system determines they are able to move further and other users need the services of the nearest resource centre, users can be issued with alternative instructions. This therefore allows user to be directed individually, whilst taking into account requirements of other users. [0121] At step 780 instructions can be confirmed for the user, with the resource and/or user data being updated at step 785, so that the user and/or resource data reflects the actions being taken by users. This ensures that once users have committed to a course of action, resources will remain available to them. So for example, this can be used to ensure that if a user is travelling to a resource centre, spaces remain available. [0122] This provides a powerful mechanism to match capabilities and resources of different users in an attempt to provide a best possible outcome, as will be described in more detail below. Additionally, the system can be used to dynamically update instructions in response to changes in the data, for example if the event progresses in unexpected ways, or in the event that resources are no longer available. [0123] It will be appreciated that in order for the process to be performed accurately, it is important to take into account as much data as possible regarding the event and resource deployment and usage. Accordingly, a continuous updating process is provided. This can be performed using a number of different mechanisms. [0124] For example, as shown in Figure 8, the agency server can provide agency updates to the management server.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 26 [0125] In this example, at step 800, the management server receives an agency update and then uses this to update the resources data and/or event data at steps 805 and 810. For example, the agency server could have information regarding available space in evacuation centres, or additional evacuation centres opening, allowing this information to be provided to the management server, and taken into account when instructing users. [0126] This process can also operate in reverse, with the management server providing updates to the agency server. So for example, as the management server instructs users to move to an evacuation centre, the agency server can be provided with this information, so that they are also aware of the number of spaces available in evacuation centres and hence whether additional centres need to be opened. [0127] A similar process can be used to receive information from one or more remote sensing systems. In one example, the agency itself will interact with sensing systems, such as satellite systems or the like and interpret data from these, integrating these into the updates provided to the management server. However, additionally and/or alternatively, the management server may receive information from sensors directly. [0128] In this instance, the management server, and/or one or more other processing systems 201, will monitor signals from the sensors and then interpret these to determine event details. In one particular example, the sensors are mounted on UAVs, which are deployed to provide sensor coverage over a relevant geographic area. In addition to this the UAVs can be fitted with wireless communications, such as wi-fi or the like, allowing this to be used for providing communications to user, as well as collecting event details. [0129] An example of the process for receiving event details from a user will now be described with reference to Figure 9. [0130] In this example, at step 900 the management server receives a user update including event details. This can be achieved in any one of a number of manners, and could include for example, having the user submit information via the App on their client device. [0131] At step 905, the management server examines details of the source, such as the identity of the user supplying the event details and/or the nature of the information, with this H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 27 being used to assign a trust level at step 910. To achieve this, users will typically have trust levels associated with them in their user data. The trust level will typically start at a default rating and then be modified depending on the event details they have previously provided, and in particular whether they have been deemed to be correct and/or independently verified. Additionally, the trust level could vary depending on the manner in which the information is provided. So for example, a photograph could be given a higher trust rating than text, whilst an image with metadata that verifies information, such as a location that matches the alleged location of the user, can be given an even higher trust rating. [0132] The level of trust is then used to assess how the event details should be handled, and in particular, whether this should be used to update event and/or resource data. For example, if the information is below a trust threshold, this could be assigned a provisional status, with this then being upgraded or assigned a higher level of importance once independently verified. Thus, once data is independently verified it assumes a higher authority to unverified data, which means another user in a similar situation will see verified data more prominently that unverified data, and further, data that is verified and then liked or shared by other users continues to grow in importance. [0133] In one particular example, the user is directed to capture images of their surrounds either as part of the process of providing user information, with this then being used to update resource and/or event data. This can then be used to provide images and/or video to other users, for example as part of an augmented reality type visualisation. For example, a user could access a street view type representation showing any incidences, allowing them to understand the ability to travel to certain destinations. [0134] An example of the use of an augmented reality type visualisation will now be described with reference to Figure 10. [0135] In this example, at step 1000, the user can request to view information, for example using their App, via a website, or the like. At step 1005, the management server queries the event, resource and/or user data and generates a representation, which is provided to the user for viewing at step 1010. At this stage the user can typically interact with the representation, for example to pan, scroll, zoom or perform other related interactions, as well as engaging H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 28 with the content, for example by cross-posting to public social networks, indicating that they understand the instructions or the intent of the instructions. The user may also be able to filter the information displayed, and also view additional information regarding users, resources or specific details of events through suitable interaction, as will be appreciated by persons skilled in the art. [0136] At step 1015, the user selects once or more options. At step 1020, the management server determines if a user has been selected, and if so the user is put in contact with the other user. At step 1025, the users communicate and identify a proposed course of action, allowing either or both of the users to enter details of this at step 1030. [0137] Accordingly, this allows the management server to access event, resource and user data providing users with filtered versions of this information that are pertinent to their current situation. This allows users to directly select and coordinate the actions to be performed, further allowing them to take into account information they need. This avoids information overload, which can result in information that would be critical to a user being overlooked in amongst large volumes of irrelevant information, whilst maximising the amount of relevant information displayed. [0138] Accordingly, it will be appreciated that the above described system allows the management server to retain up to date information regarding the event and resources, allowing this information to coordinate actions of individual users, thereby more effectively managing users in crisis situations or other events. Examples of this will now be described with reference to Figures 11 A to 1 ID. [0139] For the purpose of this example, there are three users 1101, 1102, 1103 and three resource centres 1111, 1112, 1113. The users 1101, 1102, 1103 have different capabilities and resources, so for example user 1101 has first aid skills, user 1102 has supplies and user 1103 has a vehicle and supplies. [0140] In this example, the users 1101, 1102, 1103 can create respective user profiles via an App or via a website. The users can nominate what type of information they want to receive, including but not limited to weather, local council updates, resource centre locations.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -29 Depending on the type of emergency, the App will prompt the users to complete tasks or nominate level of preparedness. [0141] In this example, the emergency is a storm, and the first user 1101 shares a photo of their house post-storm via the action centre and pushes this to Facebook so as to update friends. The property damage is such that the first user 1101 will need to get to a resource centre. The damaged property also becomes a data point for agencies wanting to track damage. [0142] The first user 1101 then scans the local environment using augmented reality features embedded within the App. As part of this, the first user 1101 can specify a radius, and have the App display available resource and/or details of other users including requirements and capabilities. The user can then nominates an optimal resource centre 1111, 1112, 1113, although alternatively this can be determined using the user profile, council data, nominated mobility status, or capabilities of the user. The first user 1101 also notes that second user 1102 is nearby and has indicated that they need to get to a resource centre 1111, 1112, 1113 but has no mobility. [0143] First and second users 1101, 1102 communicate via the App, with first user 1101 sending an alert to the second user 1102 and offering to assist. The second user 1102 agrees and the management server updates the user data to indicate that both of the users are moving towards the nominated resource centre. At this point, the nominated resource centre could be modified, for example to take into account that one of the resource centres needs first aid assistance. A route can be displayed to the first user 1101, guiding the user to the location of the user 1102. [0144] During this process, third user 1103 shares an update about a road being blocked by fallen power lines. The photo is posted via an activity feed and is tagged and sent to a power company. System admin users validate this update and award trust points to the third user 1103. This update contains location data which is compiled by the system, with indications of property damaged, location of damage, damage severity and details of users evacuating. [0145] It impacts route instructions sent to a number of users. The system now creates alternative instructions. The instructions for the first user 1101 are updated based on the H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -30 altered route. As part of this, the third user 1103 will also need assistance, and so the management server instructs the first user 1101 to collect the third user 1103 on route to the resource centre. Thus, as other users interact with the app, aggregated data about what people are doing and where they are going is pushed to upstream agencies and assist with macro level resource allocation and decision making. [0146] Thus, the system can track movement of individuals based on their capabilities and ensure that the resources they provide are optimally allocated. Accordingly, specific micro resources can be identified and directed to locations of greatest need, whilst aggregated data from the field allows better use of macro resources such as fresh water. [0147] A specific physical implementation will now be described with reference to Figure 12. [0148] In this example, the system 1200 includes a management server 1210 that communicates with client devices 1220 and an agency server 1230. In this regard, the management server 1210, manages a user database, receives feeds of data from trusted agencies such as BOM (Bureau of Meteorology), FEMA, emergency services or the like, extracts macro-data and stores this in location nodes created based on registered users location (both home base and real time location) and information a user has agreed to provide. The use of a contextualised store in this manner, allows smaller packets of data to be transferred, reducing bandwidth requirements and communications network loads, which can assist in ensuring bandwidth is available for critical communications. [0149] In this example, the management server includes a web interface 1211, a context engine, an aggregation engine 1212 and upstream and downstream data stores 1214, 1215, respectively. The upstream data store 1214 receives and stores feeds from one or many agencies and organisations, whilst the downstream data store 1215 stores an aggregation of user data field and individual data that is aggregated up to pre-configured nodes or real-time nodes, allowing this to be supplied to the agency servers 1230, as required. The context engine 1212 interprets and segments the feeds from the agency servers 1230 into smaller nodes ready for push/pull to a device, whilst the aggregation engine 1213 constantly polls user devices and aggregates this data for use by upstream agencies.

H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -31 [0150] In more detail, the upstream data store 1214 receives data from one or many agencies, with agencies being able to push and overwrite, or push to a table and allow system to determine what needs to be updated. This function can be contextualised and can also be driven by urgency so that non-urgent updates can be cached and delivered when bandwidth and network integrity is optimal, general updates can be pulled to the device based on user settings and urgent updates can be pushed to the device based on contextualised needs (i.e. known location). In the downstream data store 1213 user data is aggregated based on a pre defined node, with a system operator being able to create new nodes in real-time based on environmental needs. The management server 1210 also allows operators to poll specific users based on location activity, profile. Historical information is stored for future use and research. Operators of the management server 1210 can also tag, flag, and promote user content, with users being assigned trust points based on validity, profile, and/or usefulness of information provided. [0151] The context engine 1212 stores data from user profiles and uses this information to interpret upstream data and prepare contextualised packets. Users can pre-configure what data they wish to have available and as a user's status changes the context engine can be alerted and any new information is pulled from upstream data and pushed to a user's device [0152] The aggregation engine 1213 collects data from users, including both static, and dynamic information. The information is grouped into micro-communities, based on nodes, with these being aggregated and sent to the downstream data store 1215, for onward distribution to the agency server 1230. This also aggregates behavioural data including: what resources a user has available, specific skill sets and movements or intended movements. Action based data is aggregated based on agency needed. There may also be a need for the system to allow for upstream agencies to access a parallel data warehouse where they can set up and monitor unique, ad-hoc, or real time data queries. This allows agencies to mash-up data in real time based on 'on-the-fly' scenarios or hypotheticals, in turn allow the effect of these to be modelled without impacting on the live system. [0153] The client device 1220 typically implements a mobile user interface, which can outline details of threats, such as direction, impact path, severity of threat, time of impact, or H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 32 the like, other user contacts, evacuation points, trusted resources, such as agency details, or the like. Information is typically colour coded for ease of reference. [0154] User data in the form of user profiles typically include information such as profile pictures, home base information, type and level of mobility, available resources and who is physically with the community members. [0155] The user interface can also provide an action centre that can be used to monitor a level of preparedness and integrate FEMA/CFA/EMCP type checklists. The interface can provide action updates, which can include user created 'status update' like updates, including information regarding what other users are experiencing, seeing etc. This can include sharing of photos or videos. Such updates can be automatically shared with social networks, avoiding the need for unnecessary and/or duplicate updates, thereby minimising battery and bandwidth use. [0156] Action updates can be created when the user is in augmented reality mode, for example, when the user scans environment and nominate where they intend to follow a route as to meet or collect another community member. [0157] A number of examples will now be described in more detail with reference to Figures 13A to 13C. [0158] An example of the process of creating a user account will now be described with reference to Figure 13A. In this example, a user creates a profile via the app at 1301. The profile includes basic profile data including home location; default type of mobility; skills; resources; authenticated social networks; preferred data feeds (i.e. weather, council info, agency updates). Information is analysed by the base system, including location; default risk profile (types of risk); or the like, before the context engine and aggregation engine are updated at 1302, 1303. [0159] An example of the process for updating an account will now be described with reference to Figure 13B. In this example, a user enters an incident report regarding property and personal status at 1311, indicating they will need to evacuate. The interface 1211 detects this and forwards this to the aggregation engine 1213 at 1312, which in turn stores the data in H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 33 the downstream data store 1215 at 1313. The context engine 1212 interprets the upstream data store at 1314 and determines an optimal recovery centre (RC) and route, and sends this to the user device, 1315, 1316. The user elects to cross-post this to their authenticated social networks 1221 at 1317. [0160] The upstream data store 1214 continues to send data to the context engine 1212 at 1318 continues to feed master data into the system, with the context engine 1212 interpreting this and sending updates to users based on pre-configured data requests, real-time requests, and real-time Master Urgency Level (MUL), at 1319 and 1320. [0161] The user nominates an intended movement time and micro-collaboration status (set to 'available') at 1321, with the system prompting the user to validate mobility and resource status information at 1322. The information is returned to the aggregation engine 1213 at 1323 and stored in the downstream data store 1215 at 1324, with the system allocating trust points to the user based on the interaction. [0162] An example process for micro-collaboration will now be described with reference to Figure 13C, which includes first and second user client devices 1220.1, 1220.2. [0163] In this example, at a first user indicates they are about to move to the resource centre at 1331. This is passed to the context engine 1212 at 1332, which validates this behavioural intention against real-time data in the upstream data store 1214 at 1333, to determine if route and destination are still optimal. If the data is still valid, no further information is sent to the first user's client device 1220.1 at this time. [0164] The second user posts an incident report indicating that they need evacuation but lack mobility. This is transferred via the interface to the aggregation engine 1213 at 1334, 1135, which stores this in the downstream data store 1215 at 1136. [0165] The first user scans his surrounds using the augmented reality function to determine whether any threats exist or if any other locals need assistance. The system utilises both master data provided by agencies and other user data, which is supplied from the upstream data store 1214, by the context engine 1212 at 1337, 1338, 1339. The first user is able to H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 34 custom set a scan distance based on their needs and identifies the second user is nearby and requires assistance. [0166] The first user send the second user an alert offering assistance, with the second user accepting as shown at 1340. This information is then transferred to the aggregation engine 1213 at 1441, 1442 and then the downstream data store 1215 at 1343. [0167] Accordingly, the above described system provides a mechanism for allowing users to supply information, including about their own capabilities and requirements, as well as about progression of the event. This information can then be used together with information about resources and the event, to coordinate the actions of individuals. [0168] Thus, this improves how information is generated, gathered, and used by all parties that are impacted by an event. The system can use a dialogue based model that leverages mobile and social media technology allowing nodes of micro-communities to collaborate and self-help. The system can provide augmented reality, adding a visual layer to the real world and online data, so that users can more easily collaborate. [0169] The app can be used to provide contextualised information to the user, minimising information overload, and allows information to flow in many directions rather than one-way from authorities, for example, allowing micro information about users inc mobility, headcount, resources, capability to be captured. This can significantly assist authorities in understanding how the event is progressing, allowing them to allocate resources more effectively. [0170] This in effect turns human behaviour to communicate into a data source so that as users engage with the app, use it to find resources or log their movement intentions, this data can be aggregated up in real time for agencies to macro-manage resource allocation. [0171] The augmented reality also allows a visual layer to be added to the user experience, helping them visually understand threat directions and incorporating user-generated content around damage, routes, thereby simplifying evacuation instructions. [0172] The app also allows collaboration within communities and micro-communities, so that rather than waiting for help to arrive the app provides a platform for users to help each H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 - 35 other, with data being rolled up so oversight agencies can better understand what is really needed. Specifically the agencies can observe what is really happening and identify where they can allow self-management, where they need to intervene, where they need to start modifying behaviour and how can they help effectively and in real time. [0173] Accordingly, the above provides a mechanism to improve the flow of information around a community and optimise what the community does before, during, and after an event. It can promote micro-collaboration within communities in ways that also allows agencies to better understand community needs, allowing human behaviour to be used as a real-time data source for agencies. [0174] The system can use a combination of existing and emerging technologies, focused on improving existing practices, and creates new ways to manage resources, particularly micro resources. Specifically, the system can empower micro-communities to collaborate and self help. Whilst this happens now on social media, there is no mechanism to aggregate this data and provide overall oversight, allowing for individual instruction that takes into account the need of other community members. [0175] Although the above described implementations have focused on scenarios in which data communications are available, this is not essential and the system can use a range of mechanisms for allowing for offline implementation. For example, data could be downloaded to local devices, such as client devices, allowing them to provide basic guidance. For example, a portion of a response plan could be locally supported based on the user's location when available, so that the user can specify on their own device the nature of the event, with basic information such as guidance to resource centres being available. [0176] In this situation, user information provided will be stored, and the system can synchronise once communications are once more available. This could include uploading the latest user information to the management server, and receiving the latest event information, updated instructions or the like. [0177] As part of this, it will be appreciated that the operation of the system could be tailored to provide intermediate levels of operation in the event that communications are available but limited. In this case, data could be prioritised, so that essential information is provided, with H:\stp\Interwoven\NRPortbl\DCC\STP\8585457_1.docx-24/10/20 11 -36 subsequent information only being provided in the event that sufficient bandwidth is available, either to each individual device, or across the network as a whole. [0178] It will be appreciated from the above, that users could elect to store different amounts of information locally on their device and/or elect to update this periodically, thereby minimising bandwidth requirements during emergencies. Such updates of locally cached data could be performed periodically as App updates or the like, as will be appreciated by persons skilled in the art. [0179] Throughout this specification and claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers. [0180] Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.