AU2012272509A1

AU2012272509A1 - A system and method for providing safety policies for communications and interaction

Info

Publication number: AU2012272509A1
Application number: AU2012272509A
Authority: AU
Inventors: Leif Stanley RASK
Original assignee: JAJOZA CONNECTED SOLUTIONS Pty Ltd
Current assignee: JAJOZA CONNECTED SOLUTIONS Pty Ltd
Priority date: 2011-06-21
Filing date: 2012-06-21
Publication date: 2014-02-06
Also published as: WO2012174601A1

Abstract

A method of providing safety policies for one or more objects, including the steps of: forming at least one safety policy for each object; storing the safety policies in a central store; enabling each object to access and retrieve at least one corresponding policy from the stored policies via a communication network. The objects can be in a hierarchy, and the system can provide a safety policy for each object, in which elements of the safety policies of objects lower in the hierarchy are derived from elements of safety policies of objects higher in the hierarchy to form an inherited safety policy.

Description

WO 2012/174601 PCT/AU2012/000719 1 A System and Method for Providing Safety Policies for Communications and Interaction Field of the Invention [001] The invention relates to the provision of safety policies to apparatus adapted to interact with other apparatus or connectable to a communication network. In one particular example, the invention is applicable to a hierarchical system of safety policies. [002] The field of the invention can further include provision of safety policies for object interaction where request and provision of the safety policy is over the internet or other communication network. Background of the Invention [003] The internet enables interactions between people, communities, computers and other digitally capable devices, including common household appliances such as refrigerators, televisions, personal video recorders (PVRs) and a host of other devices. All this technology is not only joining people together in online communities, chat forums, blogs, video blogging, micro-blogging and similar, but the technology is joining people with online services such as television programming, on demand video streaming, in-car navigation systems, ordering groceries via the refrigerator, online banking services and similar. On the other side of this technology, it is enabling devices to communicate with each other to enhance their functionality or the offerings they provide, as well as joining business services together in so-called straight through-processing (STP) such as invoicing, requisitioning, supply-chain dynamics and so on. Software applications can be built to work seamlessly with web content, using web services to interact with data provisioned by disparate services existing somewhere on the internet (currently termed "the Cloud"). An example of this technology is Google Earth allowing software, on the web or otherwise, to request a map of a region on the Earth and pinpoint any location using GPS coordinates. This technology continues to expand in terms of applicability and capability, now integrating also with physical services and attractions available near the location requested..

WO 2012/174601 PCT/AU2012/000719 2 [004] In this increasingly digitised world, provisioning of digital content is fast becoming the norm in just about every facet of society. In this world however, provisioning of safety solutions to cater with the simple question "is this object safe to interact with?" is not being dealt with sufficiently. In providing a digitally connected world, safety has been a secondary consideration. [005] Most software or internet content provisioning solutions (such as web sites, web services and the like) will provide their own methods for safety. In this solution space however, i.e., that of internet content filtering solutions, there are a plethora of existing family centric web content and internet safety solutions that attempt to prevent children being exposed to malicious or otherwise unwanted content or people. Some of these solutions also enable application-to-application safety protocols of sorts, albeit the latter typically within a closed network. Additionally, there are similar filtering solutions available for implementation via hardware at the Internet Service Provider (ISP) or national internet boundary. [0061 In the space of existing web content safety filtering solutions, these solutions attempt to solve the question "can I view this object safely on the internet?" and more recently, in the current climate of digital privacy, "is it. safe to say this on the internet?". However, the definition of what constitutes safety and what objects are catered for by the solution varies greatly per solution. These solutions also rely heavily on the end-user (or parents of the end-user) configuring the desired level of safety required, either by categorical type filtering whereby a certain list of sites within a category, say "gambling" will be blocked or black-listed at the discretion of the vendor, or white-listing methods whereby you can only view sites within a list of predetermined "safe" sites. [0071 The problem of internet, or rather, connected safety is not a trivial problem. With the internet constantly evolving to cater for new technologies, e.g., HTML 5, internet safety vendors constantly have to figure out how to block these new technologies, if at all. More importantly, governments, schools and parents are faced with an ever increasingly difficult problem to solve with little useful guidance. There are a number of initiatives that provide some recommendations that parents and schools can utilise to try to solve the problem, but a comprehensive solution does not yet exist.

WO 2012/174601 PCT/AU2012/000719 3 [008] In the world of digital communications between machines, whether robots or simple digitally enhanced home appliances, and between business services such as suppliers and vendors interacting via a web Application Programming Interface (API), no general solution exists to the safety question either. Vendors of these machines, applications or services typically reinvent the safety model each time according to their own specifications. However, the model is usually the same, i.e. "can object A perform interaction X with object B?". Sometimes, however, the answer is not simple and can vary in detail according to what the objects A and B are and what the different interactions, X, are. In the case of internet filtering, A is usually a person, while B is typically a web resource such as a web site, web page, web page element, IP address or domain name, but can also be applications that use internet connectivity such as Instant Messaging (IM) or multi-player online gaming platforms. [009] At this time, there is no general solution for the question "can I safely interact with this object?". Everyone is left to their own devices to provide, or somehow obtain their own answer. In some instances, this is done by purchasing filtering software and using the vendor's answer, e.g., if it is in the list of sites the vendor has in their "gambling" category, the answer is "no". [010] The system and method described herein may ameliorate the problems discussed above or provide alternative solutions. Summary of the Invention [011] According to an embodiment, there is provided a method of providing a centrally accessible system and method for provision of inheritable safety policies that can be applied to an interaction between two or more objects. According to another embodiment, there is provided a method of providing safety policies for two or more objects communicating via a communication network, the method including the steps of, in a processing system: defining a hierarchy of objects; providing two or more safety policies; and, associating each object with one or more of the safety policies, wherein objects lower in the hierarchy have policies at least partly determined by one or more objects higher in the hierarchy. [012] According to another embodiment of, there is provided a method of providing safety policies for one or more objects, the method including the steps of, in a processing system: forming at least one safety policy for each object; storing the WO 2012/174601 PCT/AU2012/000719 4 safety policies in a central store; and, enabling each object to access and retrieve at least one corresponding policy from the stored policies via a communication network. [013] One of the objects can be a calling object. (014] One of the objects can be a target object. [015] The method can include the step of applying the retrieved safety policy to interactions between the object and a target object. [0161 The method can include the step of forming a combined safety policy for the calling object's interaction with the target object. [017] The step of forming the combined safety policy can include combining elements of the calling object's safety policy with elements of the target object's safety policy. [018] The safety policy can be applied by a calling object to accept or reject access to internet content [019] According to another embodiment, there is provided a method of providing safety policies to two or more objects, including the steps of, in a processing system: organizing the objects being in a hierarchy, providing a safety policy for each object, and, deriving elements of the safety policies of objects lower in the hierarchy from elements of safety policies of objects higher in the hierarchy to form an inherited safety policy. [020] The effective policy can include one or more over-rideable elements. [021] The method can include the step of overriding one or more over-rideable elements of the inherited safety policy to form an effective safety policy. [022] The method can include the step of forming the effective policy from elements of the safety policy of the inheriting object and one or more objects higher in the hierarchy. [023] The method can include the step of assigning ratings to target objects or calling objects.

WO 2012/174601 PCT/AU2012/000719 5 [024] The method can include the step of specifying in one or more elements of a safety policy ratings for applicability of the policy element to other objects (foreign to the safety policy) with respect to the rating assigned to the object. [025] The method can include the step of specifying in one or more elements of a safety policy spatial coordinates or location for applicability of the policy. [026] The method can include the step of specifying in one or more elements of the policy the state of objects for applicability of the policy. [027] According to a further embodiment, there is provided a method of providing safety policies for members of a group, including the steps of, in a processing system: providing one or more safety policies for each group; storing the safety policies in a central store; and, enabling each member of the group to access and retrieve one or more of the safety policies of the group. [028] A plurality of groups can be organized in a group hierarchy, each group inheriting a safety policy from groups higher in the group hierarchy. [029] A member object of a group can derive elements of its safety policy from elements of the safety policy of the group. [030] The inherited safety policy of the group can contain one or more overrideable elements. [031] The method can include the step of overriding one or more overrideable elements of the inherited safety policy to form an effective policy. [032] The method can include the step of forming the effective policy from elements of the safety policy of the inheriting object and one or more groups higher in the group hierarchy. [033] The method can include the step of forming the effective policy from elements of the inheriting object, one or more objects higher in the object hierarchy and one or more groups higher in the group hierarchy. [034] According to an embodiment, there is provided a system that provides for definition, storage, management and retrieval of safety policies for interaction between any two or more objects, such that the system allows inheritance of safety policies.

WO 2012/174601 PCT/AU2012/000719 6 [035] The system can be centrally accessed over the internet by objects capable of communication over the internet and permitted by the system to access it. [036] The system can provide for definition of hierarchy or dependence of objects so allowing for inheritance of safety policies, such that one object related to another object by such hierarchy or dependence may inherit the safety policies of the other object, thereby augmenting its existing safety policies. [037] The system can provide for definition of multiple inheritance of safety policies such that one object may inherit the safety policies of two or more objects. [038] The system can provide for definition of overriding of inherited safety policies such that one object that inherits safety policies of another object may override some or all of the inherited safety policies. [039] The system can provide for definition of whether any condition within a safety policy can be overridden as part of an inheritance of the safety policy from an object to another object. [040] The system can provide for definition and registration of objects that are allowed to interact with the central system over the internet. [041] The system can allow any object capable of internet communication to request via the internet its safety policies for interaction with any other single object, multiple objects or group of objects. [042] The system can provide for definition and registration of objects that permit interaction and safety policy definition. [043] The system can provide for definition of allowable interactions between objects for safety policy definition. [044] The system can provide for definition of states of objects for safety policy definition. 1045] The system can provide for definition of geographic location and spatial data of objects for safety policy definition. [046] The system can provide for definition of categories and object categorisation within the same categories for use in safety policy definition.

WO 2012/174601 PCT/AU2012/000719 7 [047] The system can provide for definition of age appropriate ratings for objects for safety policy definition. [048] The system can provide for definition of date and time periods for safety policy applicability. [049] The system can provide for definition of safety policies for interaction with objects that contain other objects to which safety policies may be themselves be defined. [050] The system can provide for safety policies for interacting with objects based whole or in part on whether safety policies for contained objects restrict or allow such interaction. (051] The system can provide for definition of safety policies for dates and time periods when interaction between objects may occur. [0521 The system can provide for definition of arbitrary properties of objects that can subsequently be referred to in safety policies for application thereof to allow or restrict interaction with other objects. [053] The system can define, store, manage and retrieve inheritable safety policies for interaction between a person or group of people and any object that provides access to internet content or that can be interacted with over the internet by that person or group of people, respectively. [054] The system can provide filtering of internet content accessible by the person on an internet connected device, according to the safety policies of the person defined in the system, inherited or otherwise defined, and retrieved over the internet from the system's centralised storage of safety policies. [055] The system can be centrally accessible to any object capable of communication over the internet and allowed to do so by the system, in order to retrieve safety policies for and on behalf of a person or group of people. [056] Groups can be created and managed for the purpose of defining safety policies that may be retrieved for use, and inherited by any person or other group that may belong to the former group by a parentage relationship, thereby establishing a hierarchy of groups and group membership in the system.

WO 2012/174601 PCT/AU2012/000719 8 [057] The system can provide for age rating of the person or group. [058] The system can provide for age rating of any object that the person or group can interact with over the internet. [059] The system can provide for safety policies for age ratings of the person or group relative to age ratings of objects. [060] An object interacted with or providing internet content over the internet can include an IP address, and the interaction may be that of uploading or downloading any content from that IP address for the purpose of viewing, saving, playing, printing or other action possible following upload or download. [061] An object providing internet content or interacted with over the internet can be an internet domain or sub-domain, and the interaction may be that of uploading or downloading any content from that internet domain for the purpose of viewing, saving, playing, printing or other action possible following upload or download. [062] An object providing internet content or interacted with over the internet can be a web site and the interaction may be that of uploading or downloading any content from that web site for the purpose of viewing, saving, playing, printing or other action possible following upload or download. [063] An object providing internet content or interacted with over the internet can be a web page and the interaction may be that of uploading downloading any content from that web page for the purpose of viewing, saving, playing, printing or other action possible following upload or download. [064] An object providing internet content or interacted with over the internet can be a reference to an internet object in the form of a Universal Resource Identifier (URI), including web page elements, and the interaction may be that of uploading or downloading any content from that URI for the purpose of viewing, saving, playing, printing or other action possible following upload or download. [065] An object providing internet content or interacted with over the internet can be a software application or service and the interaction may be that of using that software or service to access the internet. [066] An object providing internet content or interacted with over the internet can be a communication protocol that can be used to communicate over the internet, and WO 2012/174601 PCT/AU2012/000719 9 the interaction may be that of transmitting data using the communication protocol to access content, transmit data or communicate over the internet. [067] An object providing internet content or interacted with over the internet may be a physical device capable of internet communication, and the interaction may be that of using that device to access the internet. [068] An object providing internet content or interacted with over the internet may be a digital representation of a person via alias, avatar or otherwise, and interaction may be those of communicating with that person using the internet in messages, email, chat, text, audio, visual or other form. [069] An object providing internet content or interacted with over the internet may be a web service, and the interaction may be that of using the web service to access content over the internet. [070] An object providing internet content or interacted with over the internet may be a web method within a web service, and the interaction may be that of using the web method to access content over the internet. [071] An object providing internet content or interacted with over the internet can be a text message or any part thereof, or a stream of text data or any part thereof, and the interaction may be that uploading or downloading the text for the purpose of reading, saving, printing, viewing or otherwise consuming the text following upload or download. [072] According to yet another embodiment, there is provided a method for providing inheritable safety policies for interaction between any two objects, such that one object may inherit safety policies from another object, and allowing for any object capable of communicating over the internet, either directly or via an internet capable device, to retrieve safety policies for and on behalf of another object for application thereof. [073] The method can provide inheritable safety policies for interaction between a person or group of people and internet content or any object capable of providing access to internet content, such that a person may inherit safety policies from another person or group, and allowing for any object capable of communicating over the internet, either directly or via an internet capable device, to retrieve safety policies for an on behalf of the person or group of people for application thereof to filter or WO 2012/174601 PCT/AU2012/000719 10 otherwise limit access to the internet content or object providing access to internet content. [074] In accordance with another embodiment, the safety policy for the interaction may define the context by which the objects can interact in a safe manner. In one embodiment, interactions can be physical interactions between two or more objects. In another embodiment, interactions may be communications over a digital medium between the objects. In this embodiment, objects may include without limitation people, electronic equipment, machinery, robotics and business services. In a further embodiment, interactions may be presentation of, or access to digital content over the internet from one object to another. In this latter embodiment, the content may include, without limitation, web sites, internet domains, IP addresses, applications, web pages, web page elements, chat systems, instant messaging and email. The system and method described herein can be accessible to any object capable of communication over the intemet through the use of centrally distributed services accessible over the internet. The system and method described herein can provide inheritance of safety policies between any two objects related by hierarchical dependence as defined within the system/method described herein. In this context, an object (e.g. a user) that belongs to another object (e.g. a community) can inherit some or all of the safety policies of the latter object and can optionally override features of inherited policies. An object can have multiple hierarchical paths and so inherit safety policies from multiple parents simultaneously. This multiple inheritance allows multiple safety policies to combine to become the effective policy applied to an internet interaction between objects. [075] In yet another embodiment, the system and method described herein can allow any object interacting with another object to obtain a safety policy for such interaction for application thereof. The safety policy can include, but is not limited to, blocking of the entire interaction or parts thereof, alternative interactions to that requested, spatial and geographical restrictions for interaction, timed interaction, effective dates, times and duration for permitted interaction, restriction of words or phrases within such interaction and blocking of interaction based on dategorisation or rating of the objects involved in the interaction. Another embodiment can include a method to define safety policies for objects and object interactions. In one embodiment, the safety policy for an object interacting with another object may be a function of the object being requested, the type of interaction and the time at which WO 2012/174601 PCT/AU2012/000719 11 the interaction is made. The safety policy may also be a function of the location and state of the requesting object and the state of the object being requested. The policy may either be specific to the object requesting the interaction or inherited from a parent object. Safety policies for an object may be defined by owners of the object, with the concept of ownership being defined within an embodiment -of the system/method described herein. [076] In yet another embodiment, there can be provided a centrally accessible, internet communication and content filtering system for people using the internet via Internet browsers or other mechanisms. This embodiment of the invention can provide users with internet content filtering based on inheritable safety policies defined for the communities they belong to, including inherited policies thereof, as well as any individual policies set for the user by their owners. In this context, safety policies define allowable interactions with web accessible content including, but not limited to, domains, IP addresses, web sites, web pages, web page elements, music, videos and chat forums, as well as safety policies for allowable interactions with other users via the internet, such as instant messaging or email, and software applications that may access the internet. Brief Description of the Drawings [077] A detailed description of examples of a system and method for providing safety policies for communications and interaction is given hereafter, while referring to the following Figures: [078] Figure 1 shows the request of a calling object to a server over the internet. [079] Figure 2 illustrates the concept of multiple inheritance of safety policies according to one embodiment of the system/method described herein. [080] Figure 3 illustrates hardware architectures according to an embodiment of the system/method described herein. [081] Figure 4 illustrates a process for login and retrieval of a safety policy according to an embodiment of the system/method described herein. [082] Figure 5 illustrates the processing of a login message in the central server according to an embodiment of the system/method described herein.

WO 2012/174601 PCT/AU2012/000719 12 [083] Figure 6 illustrates a process for caching of safety policies and validity checking in accordance with an embodiment of the system/method described herein. [084] Figure 7 illustrates "just in time" processing to retrieve a safety policy as an object is encountered for interaction in accordance with an embodiment of the i system/method described herein. [085] Figure 8 illustrates a process for determination of effective safety policies at the time of request in accordance with an embodiment of the system/method described herein. [086] Figure 9 illustrates a process of caching of effective safety policies for later retrieval according to an embodiment of the system/method described herein. [087] Figure 10 shows a process for determining effective safety policies on a scheduled basis in accordance with an embodiment of the system/method described herein. [088] Figure 11 shows a process for determining effective safety policies as policies are modified. [089] Figure 12 shows an object diagram of a calling object with associated login details. [090] Figure 13 shows an object diagram of parent objects with multiple child objects and associated login details. [091] Figure 14 shows an object diagram of a calling object with login details and identification features. [092] Figure 15 shows staff using an application to enter registration details into a central registration server. [093] Figure 16 depicts an architecture for locating the registration server behind a firewall. [094] Figure 17 depicts a registration process where a user completes and submits the registration details. [095] Figure 18 shows a process for defining target objects via the API.

WO 2012/174601 PCT/AU2012/000719 13 [096] Figure 19 shows a process for defining a safety policy in accordance with an embodiment of the system/method described herein. [097] Figure 20 shows an object diagram representing the association of safety policies with categories of target objects in accordance with an embodiment of the system/method described herein. [098] Figure 21 shows an object diagram for association of ratings with safety policies in accordance with an embodiment of the system/method described'herein. [099] Figure 22 shows the recalculation of object ratings as time elapses in accordance with an embodiment of the system/method described herein. [0100] Figure 23 shows an object diagram for the use of features in safety policies in accordance with an embodiment of the system/method described herein. [0101] Figure 24 shows the concept of composition whereby access to an object is related to the access of its contained objects in accordance with an embodiment of the system/method described herein. [0102] Figure 25 shows the concept of upward composition whereby non accessibility to a contained object may result, in access to the entire parent object being disallowed in accordance with an embodiment of the system/method described herein. [0103] Figure 26 shows a process for objects updating .their states regularly and safety policies based on states of objects in accordance with an embodiment of the system/method described herein. [0104] Figure 27 shows a process for obtaining safety policies where state is provided by the calling object at the time of request in accordance with an embodiment of the system/method described herein. [0105] Figure 28 shows a process for applying safety policies where state is determined on application of safety policy in accordance with an embodiment of the system/method described herein. [0106] Figure 29 shows a process for objects updating their location regularly via the API according to an embodiment of the system/method described herein.

WO 2012/174601 PCT/AU2012/000719 14 [0107] Figure 30 shows a process for returning safety policies where location is supplied by the calling process at the time of request according to an embodiment of the system/method described herein. [0108] Figure 31 represents a process for requesting group membership via API according to an embodiment of the system/method described herein. (0109] Figure 32 shows a process for determining effective safety policies with inheritance according to an embodiment of the system/method described herein. [0110] Figure 33 shows a process for retrieving and applying safety policies according to an embodiment of the system/method described herein. [0111] Figure 34A & 34B show a process for applying safety policies to internet content and communication filtering according to an embodiment of the system/method described herein. [0112] Figure 35 illustrates group membership and inheritance according to an embodiment of the system/method described herein. [0113] Figure 36. This figure shows the generic nature of the invention allowing for internet content and communications filtering to be applied on multiple arbitrary devices using the central API as the means for requesting the safety policy. [0114] The numbering convention used in the drawings is that the digits in front of the full stop indicate the drawing number, and the digits after the full stop are the element reference numbers. Where possible, the same element reference number is used in different drawings to indicate corresponding elements. [0115] The orientation of the drawings may be chosen to illustrate features of the embodiment of the system/method described herein, and should not be considered as a limitation on the orientation of the invention in use. [0116] It is understood that, unless indicated otherwise, the drawings are intended to be illustrative rather than exact representations, and are not necessarily drawn to scale. The orientation of the drawings is chosen to illustrate the features of the objects shown, and does not necessarily represent the orientation of the objects in use.

WO 2012/174601 PCT/AU2012/000719 15 Detailed Description of the Embodiment or Embodiments [0117] To assist in explaining the system/method described herein, the following expressions have the associated meaning unless the context requires otherwise. [0118] A) An "object" is defined herein as any digital, electronic, mechanical or physical entity, communication method, digital transmission vehicle, or any concept of the aforementioned, representable by a name, alias or identifier in a digital system, and any grouping of such entities by specific arrangement, reference to properties, or other means of categorising similar objects. [0119] B) A "safety policy" is a set of one or more conditions between objects that when evaluated based on the objects given and other supporting data, can allow determination of whether interaction between the objects may be considered safe. As such, a safety policy between two objects may be used to determine if a safe interaction is possible between the objects. [0120] C) A safety policy defined for an object, hereafter referred to as the "calling object", for evaluation of safe interaction of the calling object with other objects, hereafter referred to as the "target objects", is "inheritable" by another calling object if some or all conditions of the safety policy can be evaluated for interaction by the latter calling object with any of the target objects covered by the safety policy. [0121] D) Let A and B be two objects and X be a safety policy of A inheritable by B. Then the safety policy X is said to be "inherited" by B, or B "inherits" X from A, if the safety policy X augments the existing safety policies of B and a relationship is thereby established between (A,X) and (B,X) called "inheritance". [0122] E) An inheritable safety policy allows "override", or can be "overridden" if some or all of its conditions can be modified within an inheritance relationship from object A to object B. The conditions that can be modified are said to allow "override", or can be "overridden". If an inheritable safety policy can be overridden, any condition therein allowing override that is modified in the inheritance relationship is said to have been "overridden". [0123] F) If object B inherits safety policy X from object A, then any change to conditions in the safety policy X that have not been overridden applies to both objects A and B. That is, if a condition x has been overridden by condition x' in the WO 2012/174601 PCT/AU2012/000719 16 inheritance relationship (A,X) to (B,X') where X = {a,b,...,w,x,y,z} and X' = {a,b,...,w,x',y,z}, and a,b,...,w,x,x',y,z are conditions, such that x' overrides x, then any change to condition x can apply to A but not necessarily to B. [0124] The following concepts are used in the discussion of the embodiments of the system/method described herein. [0125] Central Accessibility. The system/method described herein can be a centrally accessible safety policy solution for interaction between any two or more objects. Central accessibility of the solution is achieved using web services, i.e., Application Programming Interfaces (API) exposed over the internet. The web services can be called by any object, hereafter referred to as the "calling" object, to obtain the safety policy of an intended interaction with a second object, the "target" object. The safety policy for this interaction may have been pre-defined using a part of system/method described herein to be discussed later in this article. The policy may have been defined explicitly for the calling object as a policy for the intended interaction with the target object, or a grouping to which the target object belongs. Alternatively, the policy may be defined for a parent object of the calling object as defined by the hierarchical dependence established for the calling object as described later. In this context, the calling object may inherit the policy of its parent object for interaction with the target object. [0126] Requesting a Safety Policy. To obtain the safety policy for an interaction, the calling object can use the API's to request it over the internet. This can be performed prior to the interaction of the calling object with the target object. The centralised services of the system/method described herein can respond to the calling object request and deliver the effective safety policy for the intended interaction. This effective policy can be a combination of all inherited safety policies of the calling object for this interaction with the target object. This request mechanism is depicted in Figure 1. As discussed later, effective safety policies can either be requested at the time of intended interaction or at some time prior to the interaction and cached until required. The choice of when this retrieval occurs can depend largely on the technology to which it is applied. [0127] Calling Objects. A calling object in this context can be any digital or physical object capable of requesting data over the internet, either directly or indirectly using an appliance. This includes, but is not limited to, people, computers, applications, WO 2012/174601 PCT/AU2012/000719 17 digitally capable appliances, machinery, hardware, software, electronics and automated systems. [0128] Target Objects. Target objects in this context can be any digital or physical object. This includes, but is not limited to, people (via email, message text (SMS, MMS), Instant Messaging (IM), chat, or other), internet domains, IP addresses, web sites, web pages, web page content, images, videos, music, television broadcasts, radio broadcasts, books, services, applications and machinery. It will be appreciated that it is not necessary that the target object itself can be delivered over the internet. Target objects can be defined along with identifying criteria similar to that for calling objects described above. In one embodiment, target objects would not be owned by other objects, but may include different Interactions. Interactions in the context, can depend on the calling object and the target object. This can include, but is generally not be limited to, talking, messaging, viewing, editing, deleting, creating, saving, printing and copying, and may further include interactions defined by systems or people using an embodiment of the system/method described herein- when registering objects for future interaction. Interactions may be defined as any action that can be requested of the target object by calling objects. A system according to an embodiment can support the type of interaction being performed between calling objects and target objects. These can be stored within the central servers and defined by the creator of the embodiment, or in another embodiment, may be defined by users of the solution. In either case, means can be provided to store interactions. These interactions may be different for different types of calling objects and target objects. For example, if the calling object is a person and the target object is a web site, interactions may be "view", "print", "download", "post", and so on. If the calling object is a robot and the target object is a person, the interactions may be "speak", "touch", and similar. The types of interactions supported can thus depend on the embodiment(s) of the system/method described herein. [0129] The central servers can provide a mechanism for storing different target objects and identifying criteria. As discussed for calling objects, the identifying criteria may be different for each type of target object. Target objects would require a unique identifier (or set of criteria forming a unique set) so that requests can be made by calling processes to obtain a safety policy for interaction between a specific calling object and a specific target object.

WO 2012/174601 PCT/AU2012/000719 18 [0130] Registration. The embodiment of the system/method described herein may require that calling objects be registered with the system/method described herein in order to define and retrieve safety policies for their interaction with other objects. This registration may be accomplished by an owner of the object using a registration process established to adequately describe the object and its characteristic features. The registration details may vary according to the type of object being registered, and proof of ownership for the purposes of safety may vary per object also. For example, proof of ownership for a person, e.g. a child, may require proof of birth or parentage, legal guardianship or similar. Following successful registration, each registered object may obtain login credentials to the system for future access, as may the owner for subsequent safety policy maintenance. [0131] Target objects may be similarly registered, however, except in the case where a target object may be a calling object in another context, e.g. a person, ownership is not required in order to register the target object. Similarly, no login credentials are provided for registration of target objects, as these are used only for the purpose of defining safety policies for later retrieval by calling objects. [0132] Defining Safety Policies. Safety policies may be defined by owners of calling or target objects, as well as owners of groups that calling and target objects may belong via hierarchical membership. In one embodiment of the system/method described herein, owners of the calling and target objects may use a service provided herein to define safety policies. For calling objects, the safety policy may be defined for different target objects, types of target objects or groups of target objects. For example, the safety policy may indicate that the calling object cannot interact with any target object belonging to a specific group, of a specific type or containing some other element e.g. a word. In the context of target objects, safety policies may be defined for calling objects that may want to interact with them. The effective safety policy for an interaction between a calling object and a target object can be the combination of all safety policies defined for the target object for interaction with the calling object and safety policies defined for the calling object for interaction with the target object. In this context, safety policies defined for the calling object include those defined for groups to which the calling object belongs by hierarchical membership. These may be defined for the specific target object, or for -groups or categorisations to which the target object belongs. Similarly, safety policies for the target object include those defined for groups to which the target object belongs, by WO 2012/174601 PCT/AU2012/000719 19 inheritance, and defined specifically for the calling object, or for groups or categorisations to which the calling object belongs. [0133] Safety Policy Elements. Safety policies may contain any number of elements that combined make up the total policy for interaction. Without loss of generality, we discuss elements for a safety policy defined for a calling object. These equally apply to safety policies defined for target objects. An embodiment of the system/method described herein may allow for definition of further elements depending on the type of objects performing the interaction and those that may arise in the future e.g. for the case of robotic interactions yet to be determined, but envisaged. The safety policy elements include the following. [0134] Effective Dates. When defining a safety policy, the policy may specify an effective date and time for which the policy takes effect and an expiry date and time at which the policy no longer applies. The safety policy obtained by the calling object may then change depending on the date and time at which the policy request is made. [0135] Categorisation and Grouping. The safety policy may further identify the target object specifically, or may specify a category into which the target object has been categorised during registration. For example, the policy may indicate that the calling object cannot interact with any object of type X, e.g. Instant Messaging applications. The safety policy may also identify the target object by group membership. For example, the policy may state that the calling object cannot interact with any target object belonging to group A, with group A having been pre-defined by a user of the system/method described herein. By inheritance, this can also apply to all groups belonging to group A. [0136] Ratings. The safety policy may also define a rating above which interaction is allowed for target objects with the specified characteristics or categorisation, and a rating for the calling object allowed to participate in the' interaction. The rating, if defined, can have a specific meaning for different types of calling objects, target objects and interactions. The rating for a calling object in a safety policy may be used in the case of inherited safety policies to determine the calling objects to which the inherited policy applies, as well as in the case where the rating of a calling object - may change as time elapses. For example, a person's rating can be an age classification, say PG13, M15 or similar, while ratings for appliances may be WO 2012/174601 PCT/AU2012/000719 20 undefined for this purpose. Similarly, some interactions can be rated differently to other interactions. For example, it may be acceptable for a robot to physically interact with a human only if the device has been rated suitably to the human involved in the interaction, e.g. an adult (RI8+). Some types of objects and interactions may not have a rating that is meaningful within context and the safety policy may not require it in these cases. The embodiment of the system/method described herein may specify multiple ratings for calling objects or target objects. For example, this may be the case where objects are humans and rating schemes for age vary throughout different geographical regions. [0137] Features. The safety policy may allow restriction by features. For example, the safety policy may indicate that the calling object cannot interact with the target object if it contains specific words, images, sentences, has a certain name, is from a certain location, has a specific wave form (for music and videos) or other feature representative of the object being requested. An embodiment of the system/method described herein may cater for definition of additional features for future objects and interactions. [0138] Time and Duration of Interaction. The safety policy may allow definition of when and how long an interaction can take place between a calling object and a target object. [0139] Composition. The safety policy may allow specification of whether a target object can be accessed in whole or in part depending on composition of elements it contains that may be accessed according to their own safety policy. For example, while an image in a web page may be blocked, the entire page may be accessible otherwise. Alternatively, if a web page contains an image otherwise blocked, it too may be restricted based solely on this ownership. [0140] State. The safety policy may allow for definition of elements based on the state of the calling and target object. For example, a calling object that is moving may have different policies to one that is stationary. This may be the case, for example, with accessibility of mobile phones while in transit, while otherwise allowed if stationary. The state of calling and target objects is also relevant to interaction between systems and machinery, e.g. robots. For example, a system that is already busy performing one action (i.e. its state) may not allow interactions that may compromise it.

WO 2012/174601 PCT/AU2012/000719 21 [0141] Spatial and Geographical Location. The safety policy may allow for definition of elements by spatial and geographical location. For example, a calling object located in one country may not be able to safely interact with a target object in another country. Similarly, a robot may be able to interact with a human if a safe distance away from them, but otherwise not. This is the case also for robotic (or non human controlled) cars that need to keep a safe distance from each other. [0142) Safety Policy Inheritance. The system/method described herein can include the concept of inheritance of safety policies. This concept is akin to inheritance within computer programming concepts, whereby within the context of computer programming a class that is derived from another base class inherits the protected and public properties of the base class and can override inherited properties and methods. In this context, safety policies for an object may inherit from the groups to which the object belongs by membership. If a calling or target object belongs to a group, by default it may inherit policies from that group that have been defined to be inheritable, and can optionally override them if the group's policy allows this. In this manner, the effective safety policy of the object itself becomes the combination of all inherited policies of groups to which the object belongs, any inherited policies of those groups and so on up the hierarchy. The system/method described herein may further allow calling or target objects to belong to more than one group, thereby allowing the concept of multiple inheritance, i.e. deriving the effective safety policy from multiple parent groups via inheritance. This is illustrated in Figure 2. [0143) Inheritance Conflicts. In the case of multiple inheritance, conflicts can arise when contradictory safety policies are defined in the groups to which the object belongs by membership. For example, suppose an object X belongs to groups A and B, with group A having a policy not allowing interaction with object Y, but group B allowing interaction with Y. While this provides a contradiction, the effective safety policy may be to thus disallow interaction with Y, being the most restrictive combination of these policies. [0144] Group Inheritance. The system/method described herein may also allow for groups to belong to other groups in order to inherit safety policies and to have safety policies set for groups, so establishing a group hierarchy. In this manner, an object that belongs to a group also belongs to any parent groups of that group in the hierarchy.

WO 2012/174601 PCT/AU2012/000719 22 (0145] Overriding Safety Policies. Within the system/method described herein, a group may be defined with a safety policy that allows it to be overridden during inheritance. In this case, the safety policy for the object or group that is inheriting the safety policy may elect to use the inherited policy as defined, or can change it. [0146] Centrally Accessible Inherited Policies. The system/method described herein canprovide central accessibility to inheritable safety policies. In this manner, groups may be defined in one location, e.g. country, that can be used in any other location by inheritance. [0147] Internet Communications and Content Filtering. The system/method described herein, while generic in applicability, can also include a specific system/method of a centrally accessible Internet communication and content filtering solution enabling inheritance of safety policies for this purpose. [0148] In an embodiment, calling objects are people, services and software applications using devices to access or interact with content over the internet. These devices include any internet enabled device such as computers, mobile (cell) phones, televisions, refrigerators, telephone consoles, game consoles and so on. Target objects in this context may be other people (via chat, Instant Messaging (IM), email, messaging services (SMS, MMS)), web content including but not limited to domains, IP addresses, web sites, web pages, images, text, videos and music, as well as software applications. In the latter case, safety policies may define that a person may. not be able to use a certain software application due to age restriction or otherwise. [0149] Safety policies may be defined for groups (or communities) that people can belong to. These groups may include schools, trusted friends, social networks, companies, countries and similar, and may be defined by users of the system/method described herein. Safety policies may also be defined for people using the system/method, e.g., children, that can belong to these groups, or not. In the case where a person belongs to a group, the safety policy defined for that person may inherit the safety policies of the group and may override those safety policies allowing this. In this manner, the person's effective safety policy may be defined by their own policy, the collective policy of all groups to which the person belongs, and the safety policies of these groups inherited from the group hierarchy.

WO 2012/174601 PCT/AU2012/000719 23 [0150] Safety policies in this embodiment may also allow definition of allowed interactions between people using the system/method described herein, or between groups defined within the system/method. For example, people in a certain community may not be allowed to interact with another community, or children of a certain age could be restricted from communicating with older people using the age rating system described herein. [0151] The rating system defined in an embodiment of the system/method described herein may also be used to help classify safe interaction between people and web content. By defining an age applicable rating to web content, the system may restrict people in younger age ratings from accessing content in older age ratings. For example, a certain web site may be rated as R18+ (or similar), accessible only to those over 18, with any child younger than 18 being automatically blocked from accessing it. This part of the system/method described herein canimpose a natural rating system on internet content, with such ratings being defined by users of the system within the context of a group, person or application. For example, some groups may consider a specific web site offensive and rate it R18+, while other groups would rate it as suitable for over 15 age groups. [0152] Various embodiments/examples of the system/method described herein are illustrated in the drawings/figures. [01531 Figure 1 shows the basic architecture for enabling a calling object 1.002 to request a safety policy, 1.008, from a policy server 1.006 via the internet 1.004, and for delivering a safety policy 1.010 to the calling object 1.002 via the internet. [0154] Figure 2 illustrates an embodiment of the concept of multiple inheritance of safety policies, 2.020, whereby an object X, 2.048, belonging to two parent objects M, 2.040, and N, 2.044, inherits both their safety policies. In turn, object M, 2.040 inherits policies from objects A, 2.022, and B 2.026, while N, 2.044, inherits policies from B, 2.026, and C, 2.030. As such, the effective policy of object X becomes the combined effective policy of M and N and any specific policy set for X. The safety policy for object M is in turn the combined effective policies of A and B with specific policy elements for object M (overriding inherited policy or other), and similarly, object N has an effective policy combining that of B and C with its own policy elements. As such, a safety policy element defined by object A may be inherited by object M and hence by object X also. Thus hierarchies of inheritance of policies are established, WO 2012/174601 PCT/AU2012/000719 24 providing higher order objects with the opportunity and capability to determine the policies of lower order objects. [01551 In one embodiment, lower order objects can be inhibited from changing inherited policies or parts thereof. In an alternative embodiment, some lower order objects can be authorized to change their inherited policies or part thereof. Central Accessibility. (01561 Figure 3 shows hardware architecture of an embodiment. In this figure, a requesting process, 3.052, communicates with the Application Programming Interface (API,) (a web service), 3.056, over the internet 3.004. The API is exposed from a web server 3.058. A database server 3.062, resides behind a firewall 3.060 providing safety of data in the database store 3.064. [0157] This embodiment of the system/method provides a centrally accessible safety policy solution for interaction between any two or more objects. The centrality of the solution is achieved by providing centralised services accessible over the internet via an internet based Application Programming Interface (API), typically Web Services. A web service is defined by W3C as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. There are two major classes of web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web' resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations.' [0158] This embodiment of the system/method described herein uses at least one centralised server 3.058 exposing its API 3.056 to the internet 3.004 and capable of storing object definitions and safety policies for definition and retrieval via the API. The centralised server would therefore have an associated database 3.064 for recording such data. In one example, the centralised server 3.058 would be a web server, exposing a Web Service 3.056 with a different server 3.062 to store the data within a database 3.064. Communication between the two servers can be accomplished via a typical data access protocol, e.g. SQL, through a firewall 3.060.

WO 2012/174601 PCT/AU2012/000719 25 The firewall in this instance prevents the database server being exposed directly to the internet. [0159] In an alternative embodiment, a server can handle both data requests via API and the database storage. In a further embodiment, a web server can be provided for handling the web service API, and one or more application- servers can cater for the functionality of the system, and another database server can store the data. It is noted that any of these configurations is possible and the inclusion of firewalls and similar network protection devices is included for security only, but may be excluded or included depending on the mode used to deploy the solution. [0160] As the server is centralised through a web services API, the device connecting to the service is arbitrary, provided that it supports internet communication to the API. Additionally, the API itself may be provided in a variety of formats such as using eXtensible Markup Language (XML), other text based format, using the Simple Object Access Protocol (SOAP), Representational State Transfer (REST), or other method for relaying the API and typically over TCPIP to communicate across the internet. There are many modes for providing this in addition to those mentioned above. The methods of providing the web facing API may change in the future, however, it will be appreciated that such changes are within the scope of the system/method described herein. [0161] Requesting a Safety Policy: Figure 4 illustrates the process of logging in and requesting a safety policy in accordance with an embodiment of the system/method described herein. This figure shows an interaction with the central server 4.058 exposing the API 4.056 whereby a requesting process 4.052, on behalf of a calling object, sends messages to the API to login and retrieve the safety policy for the calling object. Similarly, the policy server responds through the API with login success and safety policy messages. [0162] Calling objects use a safety policy API according to an embodiment to request safety policies over the internet. In this embodiment, this is accomplished by the calling object 1.002 (Figure 1), or a requesting process 4.052 on its behalf. The requesting process sends authorisation credentials 4.053 to the central server 4.058 using the API to firstly login to the service before being able to request the safety policy for the calling object 4.052. Once successfully logged in to service using the API, a message 4.066 can be sent by the requesting process to obtain the calling WO 2012/174601 PCT/AU2012/000719 26 object's safety policy for intended interaction with some target object. The login and request messages can be sent over the internet using TCPIP containing API instructions (schematically illustrated at 3.054 in Figure 3) for the central server to process. [0163] Figure 5 shows the steps of the login process 5.070 carried out at the central server 5.058 to handle login messages through the API 5.056. A login API message 5.053 is received by the central server via the API 5.056. A validation check is carried out at 5.072, 5.074 and, if valid, a login approval message 5.053 is compiled at 5.076, and returned via the API 5.056 and the internet to the requesting process. If the login fails, a login fail message 5.057 is compiled at 5.078 and returned to the requesting process. [0164] Further access is prohibited until successful login is achieved. [0165] The hardware configuration may vary as noted earlier depending on the mode of deployment desired. [0166] Authentication. In one embodiment of the system/method described herein, the login credentials provided to the central server may be a username and password, possibly with other data providing further security such as entry of a Captcha'(a textual confirmation of words represented in image form). In another mode, login credentials can be in the form of biometric data such as representation of a fingerprint or retinal scan image. In another mode, login credentials can be auditory data such as voice recognition of private keywords. Further modes for providing login credentials are possible and the different embodiments of the system/method described herein may use different login methods depending on the device connecting to the central servers. [0167] Sessions. Successful login to the central servers using login credentials may result in a session being established for a calling object whereby several API interactions may occur between the calling process and the central servers prior to disconnecting the session. In this case, the calling process can be responsible for caching the login session details for communication back to the central servers to maintain recognition of the calling object identity during the session. The central servers can in turn have corresponding functionality to identify session details for identification of the calling process. As with typical session caching mechanisms, this functionality would stop invalid sessions from reconnecting, forcing session timeouts WO 2012/174601 PCT/AU2012/000719 27 as necessary. The logistics of this session identification mechanism can be implemented for any centralised, intemet-based or otherwise stateless system. [0168] When using session caching, the policy server provides the calling object with an identification token at initial login. The "session" is maintained by the calling object calling the API multiple times and then finally disconnecting the session when complete. During such a session, the central servers may disconnect the session for some reason, at which time the calling process may need to re-establish connection with login credentials as before. In this context, "session" refers not to a physical connection being maintained between the client device and central servers, as this could be disconnected and re-connected multiple times, but rather the identification token supplied by the server to identify the calling process when it needs to interact with the API. This session mechanism serves to avoid credential authorisation every time the calling process calls the API, which is not necessary. In another example of the system/method described herein, the system/method may not use sessions but rather require login credentials be passed to the API on every call, but this would be less efficient. [0169] Figure 6 illustrates the process for caching of safety policies and validity checking. [0170] Initially 6.082, a request for a safety policy 6.084 initiates a check 6.086 of the existing policy to determine if it is still current. If the policy in not valid, a request for an updated policy 6.096 is sent to the API 6.056. The API returns the updated policy, and the calling process stores it in the local cache 6.098, 6.090. [0171] If the safety policy in cache is still valid 6.086, the safety policy is retrieved from cache 6.088 and returned for use. (0172] The request of a safety policy for interaction between a calling object and a target object may be performed at any time prior to the interaction occurring, or may be just-in-time (JIT) processing as the interaction is about to occur. In some embodiments of the system/method described herein, such as internet content filtering for example, caching of the safety policies may be required to obtain optimal efficiency. In this embodiment, a process on the device may obtain the safety policy for a calling object at some time after establishing a valid session (i.e. after successful login) and cache this safety policy in. local memory or storage until it is needed. As the cache may become invalid as time progresses, or as the safety policy WO 2012/174601 PCT/AU2012/000719 28 changes on the central servers, the device would require a process to validate the cached safety policy prior to use. This process may use the system's API to perform the validation. [0173] In a further embodiment of the system/method described herein, the safety policy may have a validity time period embedded in it specifying the elapsed time before the cache needs to be refreshed from the central servers using the API. [0174] Figure 7 illustrates "just in time" processing to retrieve a safety policy as an object is encountered for interaction according to an embodiment of the system/method described herein. Upon encountering an object 7.104, the calling object logs in 7.106 retrieves the safety policy 7.108 for potential interaction with the other object 7.110. When the safety policy is retrieved, the calling object uses the safety policy to interact safely with the other object. In the just-in-time, or JIT processing, a calling object can request a safety policy from the system's API at the intended time of interaction, with no caching being performed. This may be the most practical solution in some embodiments described herein, such as robot-to-human interaction, other robotics, or mechanised services where the target object may not be known beforehand making caching mechanisms difficult if not impossible. In the JIT mode, calling objects may establish a connection with the API server with valid login credentials and subsequently request a safety policy for interaction with a target object. In this mode however, it may be practical for the calling object to cache the login session to avoid needing to reconnect to the central servers to establish a new session (as discussed earlier). In this manner, when new target objects are encountered, the calling object can obtain the safety policy in minimal time without the necessity of requiring authentication. [0175] Figure 8 illustrates, in accordance with an embodiment of the system/method described herein, the determination of effective safety policies at the time of request. In this figure, a calling process 8.080 requests a safety policy via the API 8.056. The central servers 8.058 in turn create the effective safety policy 8.120 and return it via the API to the calling process. When a safety policy is requested by a calling object the central servers can respond with the effective safety policy for the calling object. This effective safety policy may be the combination of safety policies defined for the calling object, or for objects that the calling object inherits from. In one embodiment, the central servers can determine this effective safety policy when requested, in order to return it to the calling object.

WO 2012/174601 PCT/AU2012/000719 29 [0176] In an alternative embodiment, shown in Figure 9, the central servers 9.058 can provide server side caching mechanisms 9.124 for calling object safety policies, so as to be able to respond to calling objects 9.080 as efficiently as possible. In this mode, the central servers can at some prior time determine the effective safety policy for each calling object sequentially, randomly or otherwise, and store this-safety policy until requested or until otherwise regenerated by the same process. [0177] As shown in Figure 9, a calling process 9.080 is registered with a system including an API 9.056 and server 9.058. A number of effective safety policies have been generated 9.120 and cached 9.124. When a calling process requests a safety policy, a check is made 9.126 to determine if one of the cached policies meets the requirements of the calling process. If so, the appropriate policy is retrieved 9.128 and returned 9.122. If, at 9.126, it is determined that there is no cached policy which meets the requirements of the calling process, a suitable policy is generated at 9.130, stored in cache 9.132, retrieved 9.128, and returned 9.122. [0178] In Figure 9, a process generates effective safety policies on a cycle and stores these into a cache for later use. [0179] In this way, a library of policies can be built up. The characteristics of the policies can be recorded for matching with future requests for policies. [0180] Figure 10 illustrates a process which checks if it is time to generate the effective safety policies. [0181] Where caching of effective safety policies is employed as the mode for carrying out the system/method described herein, this can be accomplished in a few ways. In one example of the system/method described herein, determining effective safety policies may be performed on a scheduled basis, cycling through the calling objects described herein and caching these accordingly. The method for cycling through the calling objects may be sequential, random or using some other algorithm. [0182] In the process of Figure 10, at step 10.136 a check is made as to whether it is time to generate a new policy. If it is, the process generates the effective safety policies 10.138 and stores them in cache 10.140, 10.124. If it is not yet time, the process waits for a period of time 10.146 (depicted as "N seconds") where N is some number and then checks again. After generating the effective safety policies and storing them in cache, the process checks if it should stop 10.142. If it should stop, it WO 2012/174601 PCT/AU2012/000719 30 stops 10.148. Otherwise the process waits for a period of time 10.144 and continues to check again (i.e. a loop). [0183] Figure 11 illustrates according to an embodiment of the system/method described herein, a process by which effective safety policies may be determined whenever a safety policy is modified for a calling object. In this mode, if a safety policy is modified for a calling object, that object and any objects that inherit safety policies from it, and those that inherit from them and so on, can have their effective safety policies regenerated and cached. In this mode it may be necessary to have a time interval to wait to capture any additional changes to a safety policy prior to regenerating inherited policies, that is, some form of delay mechanism. This can allow for quick subsequent updates to a policy to occur and these to flow through to inherited safety policies all at once. In this manner, the caching mechanism is more efficient. [0184] The process first waits for a period of time to accept more changes to the safety policy, then finds related safety policies, generates the effective safety policy and stores it in cache. [0185] At step 11.152, a policy is modified, and then a wait counter is initiated at 11.154, 11.156, 11.162. After the wait period (eg, N seconds), a check is made for further changes 11.158. [0186] When all changes are complete, related safety policies are identified at 11.160 and effective safety policies generated at 11.138, and cached 11.140, 11.124. [0187] In a further modification of the 'system/method described herein, a mixture of these methods may be deployed to maximise efficiency. [0188] Figure 12 illustrates a schema for calling objects with associated login details. Calling Objects 12.166 are any digital or physical object capable of requesting data over the internet, either directly or via an appliance. The calling objects usually include identification and login details. The central servers must provide a mechanism in the database for identification of calling objects and storage of their safety policies for definition, modification and retrieval. As calling objects can use login credentials to access the system to obtain their safety policies, the login credentials must be associated with the calling object in the database. Thus login details 12.168 can be stored at the server. These details can include, for example, WO 2012/174601 PCT/AU2012/000719 31 login name of the calling object (UserName), a link between the calling object and the login details (LoginDetailsID), User Name, password (PasswordIdentifier), number of incorrect login attempts before deactivation (GraceLogins), date of expiry of the calling object's access (ExpiryDate), etc. 10189] There can be a one-to-one relationship between the calling object and their login details. [0190] An example of the system/method described herein may specify typical password history, expiry, grace logins and similar mechanisms found in many login authorisation based systems. [0191] In yet another example, authorisation and identification may be accomplished by biometric data such as fingerprints, the biometric data, or some unique data calculated from it, must be associated with the calling object to enable identification upon login. Similarly, in yet another example, an auditory signal can be used for login authentication, the signal, or some unique data calculated from it, must be associated with the calling object to enable identification for subsequent safety policy retrieval. [0192] Figure 13 illustrates a schema for parent objects 13.170 and the parent/child relationship 13.172, and interaction with a calling object 13.166 and central server login details 13.168. [0193] Parent objects are in a one-to-one relationship with their login details and calling objects are also in a one-to-one relationship with their login details. There can be many calling objects per parent and many parents for one calling object. In this way, a calling object can be in a one-to-many relationship with parents in the parent/child relationship object 13.172. Similarly, parent objects can be in a one to many relationship with child calling objects. [0194] Calling objects can be owned by other parent objects for the purposes of registration and management such that parent objects can login to the system to manage the safety policies of the objects that they own. In a specialisation of this to internet content filtering to be discussed later, parents would manage children's safety policies for interacting with web content. In this particular example, the central servers provide an association between parent and child objects such that a parent object can login to the central servers using the API and then request safety policies for any of the objects owned by it.

WO 2012/174601 PCT/AU2012/000719 32 (0195] Figure 14 illustrates elements of an identification process. For the purposes of finding calling objects for safety policy inheritance and parentage, the central servers must enable identification of calling objects by some recognisable criteria such as the login details at 14.164, which may be user-defined. The criteria may include a picture, name, description, location, country, age, type of object, or some similar typical feature set depending on the embodiment described herein. For example, where the calling object is a mechanical device, the criteria shown at 14.184 may be a type of device, model and serial number, whereas if the calling object is a person, the criteria may be a name, location and age. In any case, the central servers must provide a mechanism for maintaining such criteria for calling objects of potentially different types. There is a one-to-one relationship between calling objects and their features 14.184. [0196] Figure 15 illustrates the registration process according to another example. Calling objects can be registered with a policy server 15.194 in order to define and retrieve safety policies for their interaction with other objects. According to one particular example, this may be a wholly or partially off-line task for registering new calling objects whereby a person 15.186 completes a registration form (on the internet, on paper or otherwise) and the system operator confirms registration details 15.188 prior to creating the new objects on the central servers 15.192 for subsequent use. In this mode, there may still need to be a central process whereby the system operator can enter the registration details 15.190 into the central server database, eg, via terminal 15.192, for storage in a registration store 15.196. This can be done in many different ways. In one mode of accomplishing this, there would be a software application, provided as a web site or otherwise, whereby staff enter in these details after performing some sort of login process for their own verification. [0197] Entering registration data may be accomplished by using a database editor to enter the details directly into the central server database. This approach would typically not be employed due to security reasons as well as integrity of the data. [0198] Figure 16 illustrates a system including a registration server. A consideration of registration is the security of the data being entered and stored as part of the registration process. In one mode for on-line registration, a separate server 16.208 with registration store 16.210 can be provided for storing this registration data that can be accessed only by system operator. The registration server can be behind a WO 2012/174601 PCT/AU2012/000719 33 firewall 16.230 from the rest of the system so as not to be accessible by any outside party. [0199] In yet a further example, this data can be stored on another central server, or otherwise depending on security required. [0200] Figure 17 illustrates the registration process, the dashed line separating the user actions from the server actions. In Figure 17, a process inputs the registration details into the central registration database and returns login credentials back to the registrant. The user 17.198 completes the required registration request 17.214 and submits this at 17.216. At the server, the registration request is processed at 17.218 and, where the registration is successful, the outcome of this process is input at 17.220 to be stored at store 17.210. Additionally, the registration details are returned to the user at 17.222. [0201] As part of the registration process, the system described herein may not only specify the details of the object being registered, but also the person or persons registering the object. As discussed earlier, this would form a parent-child relationship between the objects and allow for either the parent object or the child object to login to the solution to obtain safety policies for the child object. As such, the output of a successful registration process would be login credentials that can be subsequently used to access the system/method described herein. In one further embodiment, the login credentials may be specified by the registrant during the registration process in the form of desired usemame and password, biometric or audio data, these modes of authentication having been discussed earlier. [0202] Figure 18 shows a process for defining target objects via the API. In this process, the calling process logs into the system/method described herein via an API, and then sends a message to create a target object. The API responds with a message indicating success or failure [0203] The definition of target objects described herein can also be performed on line or off-line. In one example, this can be performed through the API 18.056 by prior registrants, being either calling objects 18.080 or parents of calling objects. After login 18.224, 18.226, calling objects or their parents can use the API to define target objects 18.228. The system according to one example, may then associate this target object as being created by the calling object or parent thereof. In one embodiment, validation can be performed by the system operator.

WO 2012/174601 PCT/AU2012/000719 34 [0204] In yet another example, this may be an on-line or off-line process whereby calling objects would request a type of target object be created, via the API or otherwise, and the target object is created at some later time by the creators of an embodiment of the system/method described herein after confirming its validity. Similarly to entering registration data, entering target objects after validation may be accomplished by the creators of the embodiment of the system/method described herein in multiple ways. In one mode, this may be provided via software provided for this purpose, either as a web site or otherwise. In another mode, this may be recorded via a database editing program to directly enter the data into the central servers. In yet another mode for carrying out the system/method described herein, there may be software provided, as a web site or otherwise, that calling objects or their parent objects can use to register target objects. [0205] Figure 19 shows a process for defining a safety policy. A calling object (represented as a user 19.250) logs into the system at 19.252, identifies an object 19.254 to define a policy and then defines the safety policy 19.256. On the service side (below the dashed line, i.e. the centralised servers and store 19.264), the login process 19.258 validates and logs in the caller, locating an object also validates that the caller has access 19.260 to the object and the process of defining the safety policy associates the safety policy with the object 19.262. [0206] Requests made by calling processes for intended interactions can then specify the calling object, the target object and the intended interaction to retrieve the appropriate safety policy. [0207] Safety policies may be defined by parents of calling or target objects, as well as parents of other objects to which calling and target objects may belong via hierarchical membership. Parents in this context having been defined by the registration process described earlier. In one embodiment of the system/method described herein, defining safety policies may be performed by parents using the system's API, while another embodiment may allow for the operator of the system to define safety policies for objects, or a further embodiment of the system/method described herein may allow for a mixture of both. In the case of operators defining safety policies for objects, one mode for carrying out the system/method described herein may perform this via a software application (web based or otherwise) for the purpose, while another mode may perform this using database editing tools to directly modify data on the central servers.

WO 2012/174601 PCT/AU2012/000719 35 [0208] Whether being performed by a parent object, or by operators of the system, definition of a safety policy is similar in the case where either the API is used to achieve this, or a software application (web based or otherwise) is provided for this purpose, this application using the API to achieve this on behalf of the user. The process may require the parent object or operator to login to the central server to establish authentication, determine the calling or target object to define the safety policy for, and then define the safety policy. The safety policy would then be associated with the calling or target object in the database. [0209] Where the embodiment of the system/method described herein supports interactions defined for objects, defining the safety policy for an object may require defining an interaction also, or selecting the interactions to which the safety policy or elements of the safety policy are associated. [0210] Figure 20 shows an object diagram representing the association of safety policies with categories of target objects. In this figure,. safety policies 20.270 are associated with target objects 20.274 via TargetObjectPolicies entities 20.272. Categories of target object are maintained in the CategoryObjects entities 20.276 and safety policies associated with categories 20.278 are maintained in the CategorySafetyPolicies entities 20.280. There can be a one-to-many relationship between a safety policy 20.270 and target objects that are associated to the policy 20.272. [0211] A target object can have multiple policies so there is a one-to-many relationship between the target object 20.274 and its policies 20.272. [0212] Target objects 20.274 can belong to many categories, forming a one-to-many relationship, and a category 20.278 can contain many target objects. [0213] Safety policies 20.270 may have different elements according to the embodiment of the system/method described herein. These may include effective dates, categorisation and grouping, ratings, features, time and duration of the interaction, composition, state or spatial and geographical location. When defining the safety policy for a calling or target object, these elements may form part of the definition specifying the elements to which the safety policy applies. As such the database structure can be adapted to cater for~this association. Similarly, the API may need to cater for these elements in the safety policy transmitted from the central servers to the process requesting the safety policy.

WO 2012/174601 PCT/AU2012/000719 36 [0214] One element of a safety policy can be the effective date of the policy. The embodiment of the system/method described herein may cater for effective dates being defined for a safety policy such that the policy is effective between the dates specified. The storage of safety policies can then cater for application of effective dates to a safety policy and for retrieval of safety policies through the API to respect these effective dates relative to the date of the safety policy being requested. The API can also cater for association of effective dates with a safety policy as it is defined. The central server may inform the process calling via the API what the current server's date and time are so that adjustments can be made by the calling process to calculate the correct date to transmit to the server in the case of time differences between the calling process and the server. In one example, this may be achieved during the authentication response, while another mode may have a distinct API call to determine this date and time. [0215] An embodiment of the system/method described herein may cater for categorisation of target objects 20.274 so that safety policies can be defined relative to these categories 20.278. In one example, categories can be defined by users of the system/method described herein. Another mode can have these categories pre defined by system operators, while another mode may employ a combination of pre defined and user defined categories. For this purpose, the API can be adapted to cater for such category creation and in one particular example, may provide a software solution for this purpose, web based or otherwise. There may also be a corresponding way to modify the association of a target object with a category in the case where mistakes are made. [0216] During the registration process for target objects as defined earlier, one or more categories may be picked to which the target object belongs. The database schema and registration process (via API or otherwise) should cater for the association of categories with target objects accordingly. [0217] Definition of safety policies may in embodiments catering for categorisation as discussed, provide for a safety policy between a calling object and a category rather than a target object specifically. In this manner, the safety policy applies to all target objects in that category by membership. This example may thus cater for this mode of safety policy definition.

WO 2012/174601 PCT/AU2012/000719 37 [0218] Figure 21 shows an object diagram for association of ratings with safety policies. In this figure ratings 21.282 are associated with calling objects in the CallingObjects entity 21.250. Ratings 21.282 are associated with safety policies in the SafetyPolicy entity 21.270 as the minRatinglD and maxRatinglD fields. Ratings are associated with target objects in the TargetObject entity 21.274 as a RatinglD field. [0219] An embodiment of the system/method described herein may include ratings as part of the safety policy definition. The safety policy may include a rating as part of its definition so that it only applies to target objects with a rating matching that specified in the safety policy, or within the range of ratings so defined. The safety policy may also specify a rating of the calling object to which the safety policy applies, so that in the case of an inherited safety policy the system/method described herein can determine if the inherited safety policy is effective or not according to the calling object's rating. The association of a rating with a safety policy may thus be by calling object, target object, category or interaction. Depending on the-embodiment, the database schema and API should then cater for this association of ratings with a safety policy element and for the determination of whether a target object or calling object is affected by a safety policy according to rating. [0220] Ratings can also be associated with calling objects and target objects driving the registration process. Figure 22 shows the recalculation of object ratings as time elapses. This process uses a RatingChangesDue entity 22.294 to maintain the list of objects and their next due rating change. The process finds the items due for ratings changes at step 22.292 by inspecting the entity 22.294, checks for due updates at 22.296 and, where updates are due, performs the update at step 22.298 and keeps this table up to date. The embodiment of the invention may provide that multiple ratings be associated with objects and the mode for carrying out the embodiment can cater for this in the registration process, database schema and API accordingly. [0221] Depending on the embodiment, the rating of a target object or calling object may change with time. For example, the rating of a human by age can change as time elapses. The embodiment may thus call for recalculation of the.rating for calling objects and target objects as time elapses. One mode for achieving this is on a scheduled basis updating ratings for objects. This can be achieved by cycling through all objects in sequence or at random to calculate this, or in another mode, by WO 2012/174601 PCT/AU2012/000719 38 having a separate storage of due dates for rating changes of objects and updating only those as the due date arrives. [0222] As the rating for an object changes, so too may the object's effective safety policy. This may also need to be determined at such time and cached according to the embodiment described herein, although in yet another example, may just flag the object as requiring the effective safety policy to be determined on next cache refresh or on next request for the safety policy. [0223] Figure 23 shows an object diagram for the use of features in safety policies. In this figure, features 23.302 are associated with objects via the ObjectFeatures entity 23.304 and associated with safety policies via the SafetyPolicyElement entity 23.306. Different types of features are supported using the FeatureType and FeatureContentlD fields in the Features entity. This allows for different types of features to be added as required. This is shown for the case of words 23.310 and pictures 23.312 by way of example. [0224] Embodiments of the system/method described herein may cater for features of objects to be included in safety policies. These features may differ based on the embodiment being deployed and the types of objects supported. In the case of filtering web content, for example, features may include words, phrases, names and images and safety policies may be able to be defined to restrict interaction based on target objects containing these features. In one example, features may be defined by users of the embodiment. In another mode, features may be defined by creators of the system/method described herein, while another mode may employ a combination of both. To define features, users or creators of the system/method described herein may use a software application (web-based or otherwise) for this purpose, or may interact with the API directly. Where creators of the system/method described herein define the features, the mode for carrying out the system/method may simply be via database editing on the central servers. For application of features to safety policies, features may be able to be associated with target objects either during the registration process, or as a process available in the API or other software application for this purpose. Features that atarget object possesses relative to those defined in a safety policy may also be able to be determined dynamically by the embodiment of the system/method described herein during application of the safety policy.

WO 2012/174601 PCT/AU2012/000719 39 [0225] Where the embodiment of the system/method described herein supports features, the system/method may be able to store features in the database, associate these with target objects if required by the embodiment being deployed and be able to define features within a safety policy that applies to a target object, or a category of target objects. The API should similarly provide such features, along with any software application provided for the purpose of defining features or safety policies. While the exact mode for how this is done can depend on the features being deployed, a generic storage mechanism and API methods should be possible to handle all cases. [0226] Figure 24 shows the concept of composition whereby access to an object is related to the access of its contained objects. In this figure the process, at step 24.313, first determines if the object can be access in entirety regardless of contained objects. If so, access is allowed at step 24.320 and the process stops. If not, the process checks if any of the object can be accessed at step 24.314, and, if not, then access is disallowed at step 24.322 and the process stops. If some of the object can be accessed, the process checks if composition is allowed or not at step 24.316. If composition is not allowed, access to the object is disallowed at step 24.322 and the process stops, otherwise non-accessible parts of the object are blocked at 24.318 and access to the object is allowed at 24.320, i.e. without the non accessible parts. [0227] The safety policy may include the time and duration that an interaction between a calling object and target object (or category thereof) may or may not occur. This may be achieved easily by storing a time and duration as part of the policy definition. [0228] Composition. The safety policy may cater for restriction according to composition of the target object, so that a target object containing other target objects may be interacted with in whole or in part according to the safety policies of its contained target objects. For example, if a target object A contains another target object B and B is not accessible by calling object X, the concept of composition specifies whether A can be accessed by X excluding B, or not at all. One mode for achieving this is to specify on a safety policy a composition element indicating "whole" or "part", where "whole" means only allow access if the whole target object is accessible, and "part" meaning only allow access to contained target objects that can be accessed or the whole target object if all contained objects can be accessed.

WO 2012/174601 PCT/AU2012/000719 40 [0229] Figure 25 shows the concept of upward composition whereby non accessibility to a contained object may result in access to the entire parent object being disallowed. In this figure, as all contained objects are checked, if access is disallowed for an element the process can check if the entire object should be blocked, i.e., restrict upwards, or only the element should be blocked. At step 25.332, a check is made to ensure all elements have been analysed. Any remaining unanalysed elements are then checked at step 25.334. This process is repeated until all elements have been checked. If an element is not allowed, the process then checks if it is necessary to restrict upwards at step 25.336. If upward restriction is not necessary, the element being checked is blocked at step 25.340. If upward restriction is required, the parent is blocked at step 25.338. [0230] The safety policy may cater for upward restriction of target objects. This may restrict composition upward, so that if a target object cannot be accessed, this element can specify that any parent object also cannot be accessed. This may be useful for target objects of a severe nature. To achieve this, a safety policy element could specify "inherit-restrict" or "inherit-allow" accordingly. In the case of "inherit restrict" if the target object is blocked, then any parent object is also blocked. In the case of "inherit-allow" the parent is not blocked. [0231] Figures 26A & 26B show a process for objects updating their states regularly and safety policies based on states of objects. In this figure, shown in two parts, the first part illustrates objects (robots) 26.344, 26.346, 26.348 updating their state in server 26.354 and store 26.356 via network 26.359 and the API 26.352. This would occur regularly. [0232] Figure 26B depicts a calling process requesting the safety policy for an object based on its state where the state has been updated regularly as in Figure 26A. In Figure 26B, a calling process 26.358 requests a safety policy via the API 26.354 over network 26.350. The central server 26.354 determines the stored state of the calling object and returns the safety policy corresponding to that state. [0233] The safety policy may cater for state of calling objects and target objects. According to one example, states of objects may be defined and assigned to objects by interaction with the API. In this mode, possible states may be defined by parents of calling objects and target objects and the objects use the API to update their state. For this to occur, both calling objects and target objects can have some method of WO 2012/174601 PCT/AU2012/000719 41 identification, whether through login or other process. This would alter the registration process earlier so that target objects would also be provided with authentication details to perform this action. As states are constantly maintained by the objects themselves in this example, safety policies could specify that it is conditional on a certain calling object state, target object state, or both. In this mode, effective safety policies are generated based on the current state of objects. [0234] Figure 27 shows a process for obtaining safety policies where state is provided by the calling object at the time of request. In this figure, the calling process 27.358 requests the safety policy via the API 27.352 indicating the state of the object as X. The central servers 27.354 find the safety policy 27.366 corresponding to this state and return it to the calling process. [0235] In this embodiment, safety policies can still refer to the state of the objects, but rather than trying to keep the state constantly up-to-date, the request mechanism for a safety policy can identify the state of the calling object and target object involved in the interaction. The states provided by the requesting process enable the central server to provide the effective policy based on the states given. This makes the process simpler and less error-prone due to inaccurate current states being recorded for objects. [0236] Figure 28 shows a process for applying safety policies where state is determined on application of safety policy. In this figure, the calling process 28.358 requests the safety policy for an object. The entire safety policy 28.368 is returned covering all states of the object. The calling process then inspects the state of the object at 28.370, 28.372 and applies the appropriate policy at 28.374. [0237] In this example, the request for a safety policy between a calling object and a target object need not specify the states of the object. The state of the object is used by the calling object in determining the safety policy to be' applied. In this mode, the effective safety policy retrieved includes all states of the objects and the calling process determines which to apply based on the current state of the objects. [0238] In all modes, a list of possible states for objects can be maintained in the database. These states can be associated with safety policies for both the calling object and the target object or category.

WO 2012/174601 PCT/AU2012/000719 42 [0239] In the example as depicted in Figures 26A & B, the state of calling objects and target objects can be stored for each object. In this mode, the API can provide a mechanism for any object to login to the system/method described herein and update its current state. The object itself knows the list of possible states that it can be in. [0240] In another example as shown in Figure 27, association of the state with objects is not required and the request for the safety policy specifies the states of the objects involved producing an effective safety policy for the states provided. Any caching mechanisms employed for effective safety policies can take this into consideration. [0241] In yet another example (Figure 28), association of the state with objects is not required, and the effective safety policy includes all possible states of the object to be applied by the calling process as required. This may increase the size of the effective safety policy communicated between the central server and the client processes, but simplifies the caching mechanisms for effective safety policies. (0242] Figure 29 shows a process for objects updating the location of the objects regularly via the API. The safety policy may cater for spatial and geographic location. According to one example, calling objects 29.344, 29.346, 29.348 and target objects could provide their location to the central servers 29.354 on a regular basis and safety policies could identify the policy elements that apply for a given location or set of locations. In this example, the location could be provided via Global Positioning System (GPS) associated with a mobile communication device or otherwise. The central servers would need to maintain the position of the calling objects and target objects and any method of caching of safety policies would need to cater for re caching as the location and hence, safety policy changes. Additionally, the registration mechanisms noted above would need to change to cater for target objects being able to login to the system to update their location. [0243] Figure 30 shows a process for returning safety policies where location is supplied by the calling process 30.358.at the time of request. In this figure, the calling process 30.358 requests the safety policy specifying the object's location 30.362. The central servers 30.354 locate the safety policy "X" corresponding to the location given and return it to the calling process. [0244] The location of calling objects and target objects can be supplied to the central servers as the safety policy is requested and the central servers can provide WO 2012/174601 PCT/AU2012/000719 43 the effective safety policy for the given locations. This is a simpler mechanism and does not require continual communication with the central servers to identify location when no corresponding safety policy is required. In this example, it is not necessary that target objects be able to update their location, as the calling object can provide this upon request. [0245] In both examples for the purpose of identifying location, embodiments described herein may identify location by GPS coordinates, radial proximity to a GPS location, country, region or city, or similar geographical measures. Safety policies would use these identifiers to specify safety policies that apply for different locations. [0246] Figure 31 represents a process for requesting group membership via API. In this figure, the calling process 31.358 communicates with the API 31.352 to firstly locate the group 31.376 and then to request membership 31.380. [0247] Safety policies for an object may be inherited from other objects or groups to which the object belongs by membership. In one example, the API 31.352 and supporting software may enable registrants of the system to create groups to which calling objects can belong by hierarchical membership. Calling objects 31.358 or parents thereof would request that the calling object become a member of a group. In yet another example, this request may be provided via the API, while in another example, there may be provided herein, software for the purpose of managing group memberships. [0248] The owner, creator or moderator of the group could subsequently accept or reject the group membership 31.382 accordingly. In one example, this may be achieved via an API or the like, while in another example, may provide software for the purpose of maintaining, accepting and rejecting group memberships. [0249] In one example, requests for membership to a group may trigger notification to the group owner, creator or moderator to action. This may be achieved in various modes such as e-mail, SMS, or other messaging system. Similarly, when membership is accepted or rejected, this may trigger a corresponding notification to the parent of the calling object using a similar messaging system. [0250] Where group membership is accepted for a calling object, the safety policies defined for the group, as discussed earlier in this document, can be inherited by the calling object. In one embodiment of the system/method described herein, safety WO 2012/174601 PCT/AU2012/000719 44 policies and safety policy elements would identify whether they can be inherited and if so, whether they can be overridden or modified by the calling object. Only inheritable safety policies and elements can be inherited by the calling object. Selection of safety policies to inherit could be achieved using the API, or a software system provided for such purpose. [0251] In a similar fashion to that described above for group membership, calling objects could inherit safety policies from other calling objects directly, with similar request and acceptance or rejection of hierarchical dependence by the calling objects or parents of calling objects. Upon inheriting safety policies from a group or another object, the effective safety policy of the calling object can include the inherited safety policies and any overrides thereof. [0252] Figure 32 shows a process for determining effective safety policies 32.384 with inheritance. In this figure, a calling object, X 32.344, requests its effective safety policy from the API. The central server in turn locates parent objects 32.386 of X , here A, B and C 32.390, obtains the parent objects' effective safety policies 32.390, obtains the safety policy of X 32.394 (the specific policy set for the object) and then combines these 32.396 to produce the effective safety policy 32.398 for X, denoted as UX, A, B, C". This effective safety policy is then returned to the calling object. [0253] Inheriting safety policies may result in conflicts of policies. In one example, the resolution of conflicts can be achieved when determining the effective safety policy for a calling object. This can be performed during caching of effective safety policies, or upon request according to the mode adopted for carrying out the system/method described herein. [0254] An embodiment of the system/method described herein can allow for groups to belong to other groups so forming a group hierarchy. In one example, owners of groups can apply for membership with another group in a similar fashion to objects applying for membership. These requests can then either be accepted or rejected accordingly and notifications sent as discussed above. The means of applying for group membership can be accomplished via the API, or via software supplied for the purpose of maintaining groups and their membership. When a group belongs to another group by membership, it can inherit one or more of the inheritable safety policies of the parent group. Those safety policies defined for the parent group that have been designated as inheritable can be inherited by the child group. Where an WO 2012/174601 PCT/AU2012/000719 45 inheritable safety policy has further been designated as overridable, the child group can modify it after inheriting it, if required. [0255] Safety policies that are inheritable by objects via hierarchical group membership or object hierarchy, can be designated as being overridable. Where a safety policy or safety policy element is overridable, the calling object inheriting the policy or element can alter it if required. This mechanism allows for inheritance of safety policies by objects with some items being optional (via override). In one example, inheriting and overriding safety policies would be achieved via the API, while another mode may provide software for the purpose of maintaining safety policies. [0256] Figure 33 shows a process for retrieving and applying safety policies. A calling object 33.344 initiates a calling process 33.410 to request a safety policy via network 33.350 and API 33.352. An effective safety policy 33.412 is returned and applied 33.414 to facilitate safe interaction 33.416. [0257] The centralised nature of the system according to the yet another example, allows for arbitrary processes or objects to connect to the, central servers to retrieve safety policies for intended interactions with other objects. Upon retrieval of effective safety policies, the calling object may need to process the safety policy. The interaction between 33.444 and 33.416 can be via a network or via any other suitable communication link. [0258] In one mode for carrying out the systemlmethod described herein, this can be achieved by a process 33.410 on the device that the calling object 33.344 is using to interact with the target object. This would be the case for a user of the internet via some internet enabled device for example, where the target object is some internet accessible content or person's avatar. In another mode for carrying out the system/method described herein, the calling object 33.344 can be the process or device itself, as would be the case for robotic interactions. In another example, the calling object may be a process such as a web service talking to another web service in a business-to-business sense. In all modes, some process can be responsible for applying the safety policy obtained from the central servers. This process may in turn decide to proceed with the interaction, or use the safety policy to determine how to proceed with the interaction.

WO 2012/174601 PCT/AU2012/000719 46 [0259] Figure 34A & 348 show a process for applying safety policies to internet content 34.422 and communication filtering. In these figures the safety policy 34.412 for the user is retrieved via the API. Web content 34.420 is then requested 34.422 by the user and the safety policy applied 34.424, 34.426 to it to produce modified content 34.428 to be viewed or used by the user. [0260] An example specialisation of the system/method described herein is to that of internet content and communication filtering. In this application, the interaction is between people, software or services using internet enabled devices to interact with internet content or services. In one example, a process would reside on the device being used for internet communication. This process can communicate using the API to the central servers to retrieve the effective safety policy for the user of the device currently logged into the system/method described herein. This process would apply the safety policy to the internet content being accessed, or communication being received or sent. As needed, the process would communicate with the central servers to update the effective safety policy, or re-authenticate the user for continued use. [0261]. Figure 35 illustrates group membership and inheritance. In this figure, the parent 35.450 interacts with software 35.452 implementing an embodiment of the system/method described herein to request membership of groups A, B and C 35.454, 35.456, 35.458, each with corresponding safety policy 35.464, 35.466, 35.368, for the child 35.460, and also configure the safety policy 35.462 of the child. As a result, the effective safety policy 35.470 of the child becomes the combined policy of the groups and the policy set for the child. [0262] In the case of Internet filtering, safety policies can be inherited from groups or other users via hierarchical membership. In one example, parents of children can join one or more groups in order to inherit the safety policies of the groups. Groups can be established by industry leaders, companies, schools and similar, to provide safety policies for children to inherit. In yet another example, groups can be established using software provided for this purpose, web based or otherwise. [0263] As the system/method described herein can be agnostic as to the device being used and provides a centrally accessible API, any internet enabled device can, connect to the central servers to request safety policies and apply them. In this manner, one an example can include on personal computers, or desktops, another WO 2012/174601 PCT/AU2012/000719 47 on laptops, another on hand-held devices, another on hands-free devices e.g. internet enabled goggles or wristbands (currently being invented), another on internet enabled appliances e.g. fridges, watches, tvs, etc. In these examples, a process on .the device would typically be responsible for communicating using the API to authenticate the user and retrieve safety policies for them to apply. [0264] In the case of internet filtering, one mode for carrying out the system/method described herein can include having safety policies being defined by users of a computer using software, -web based or otherwise, designed to maintain safety policies. Safety policies would have elements as described in this document allowing for policies around any web content in the form or Universal Resource Identifier (URI), domain or IP address, with or without contextual qualification e.g. associated query string. Additionally, safety policy elements described herein apply to internet filtering as follows. [0265] In yet another example, categorisation and grouping can be used to classify. internet content, be it web sites, web pages, images, text or other. Common classifications could be "pornography", "social networking", "news" and similar. Classifications used can also depend on the embodiment of the system/method described herein. [0266] In another example, ratings may be used to classify internet content by suitable age of users viewing or otherwise interacting with it. Safety policies could specify these age ratings as discussed throughout this document. (0267] In yet a further example, features of internet content may be used in safety policies to determine whether the content can be viewed or otherwise interacted with. These features may be words, e.g., swearing or bullying, images of a sexual nature, or similar. Features that are provided can depend on the embodiment of the invention. [0268] In another example, time and duration of interaction could be used to specify in the safety policy how long the user can view or otherwise interact with the internet content or communication. [0269] In yet a further example, composition could be used to specify whether internet pages or sites can be viewed or interacted with based on other elements WO 2012/174601 PCT/AU2012/000719 48 found on the site or page. For example, if a page on the web site is not safe to view, the entire site could be blocked based on this fact alone. [0270] yet an additional example, state of the user can be used to determine if the user can interact with internet content or communications. For example, if the user is in a car, viewing the internet may not be safe. [0271] In another example, geographical location may be used to determine if the user can interact with internet content. For example, filtering of content may be per region. INDUSTRIAL APPLICABILITY [0272] It will be appreciated that the system/method described herein may be applicable to a variety of industries. In particular, any industry where a safety policy can exist that defines interaction between objects. [0273] This includes but is not limited to robotics and cybernetics, whereby robots are interacting with other robots or with humans; machinery interacting with other machinery in dynamic situations, e.g. cars keeping safe distances from other cars or traffic; computing devices enabling people to access internet content; computing devices enabling people to interact with other people over the internet e.g. chat rooms; business-to-business systems that integrate via web services to request internet content or functions; multi-player gaming platforms enabling user interaction within virtual reality; electronic machinery using the internet to request content or services e.g. refrigerators requesting orders. This could also be used for transportation of goods to establish goods that can safely be transported with other goods and under what conditions; use by web content providers to determine safety of users interacting with their own content e.g. limiting access to certain people or applications; and so on. As discussed herein, any object that can interact with other objects can utilise the system/method described herein to provide for safe interaction. [0274] In this specification, reference to a document, disclosure, or other publication or use is not an admission that the document, disclosure, publication or use forms part of the common general knowledge of the skilled worker in the field of this invention at the priority date of this specification, unless otherwise stated. [0275] In this specification, terms indicating orientation or direction, such as "up" "down", "vertical", "horizonta", "left", "right" "upright", "transverse" etc. are not WO 2012/174601 PCT/AU2012/000719 49 intended to be absolute terms unless the context requires or indicates otherwise. These terms will normally refer to orientations shown in the drawings. [0276] Where ever it is used, the word "comprising" is to be understood in its "open" sense, that is, in the sense of "including", and thus not limited to its "closed" sense, that is the sense of "consisting only of". A corresponding meaning is to be attributed to the corresponding words "comprise", "comprised" and "comprises" where they appear. [0277] It will be understood that the invention disclosed and defined herein extends to all alternative combinations of two or more of the individual features mentioned or evident from the text. All of these different combinations constitute various alternative aspects of the invention. [0278] While particular embodiments of this invention have been described, it will be evident to those skilled in the art that the present invention may be embodied in other specific forms without departing from the essential characteristics thereof. The present embodiments and examples are therefore to be considered in all respects as illustrative and not restrictive, and all modifications which would be obvious to those skilled in the art are therefore intended to be embraced therein.

Claims

1. A method for providing safety policies for one or more objects, the method including the steps of, in a processing system: (a) forming at least one safety policy for each object; (b) storing the safety policies in a central store; and, (c) enabling each object to access and retrieve at least one corresponding policy from the stored policies via a communication network.

2. A method as claimed in claim 1, wherein one of the objects is a calling object.

3. A method as claimed in claim 1 or claim 2, wherein one of the objects is a target object.

4. A method as claimed in any one of claims 1 to 3, including the step of applying the retrieved safety policy to interactions between the object and a target object.

5. A method as claimed in any one of claims 1 to 4, including the step of forming a combined safety policy for the calling object's interaction with the target object.

6. A method as claimed in claim 5, wherein the step of forming the combined safety policy includes combining elements of the calling object's safety policy with elements of the target object's safety policy.

7. A method of providing safety policies to two or more objects, including the steps of, in a processing system: organizing the objects being in a hierarchy, providing a safety policy for each object, deriving elements of the safety policies of objects lower in the hierarchy from elements of safety policies of objects higher in the hierarchy to form an inherited safety policy.

8. A method as claimed in claim 7, wherein the effective policy includes one or more overrideable elements. WO 2012/174601 PCT/AU2012/000719 51

9. A method as claimed in claim 8, including the step of overriding one or more overrideable elements of the inherited safety policy to form an effective safety policy.

10. A method as claimed in claim 9, including the step of forming the effective policy from elements of the safety policy of the inheriting object and one or more objects higher in the hierarchy.

11. A method as claimed in any one of claims 1 to 10, including the step of assigning ratings to target objects or calling objects.

12. A method as claimed in claim 11, including the step of specifying in one or more elements of a safety policy ratings for applicability of the policy element to other objects (foreign to the safety policy) with respect to the rating assigned to the object.

13. A method as claimed in any one of claims 1 to 12, including the step of specifying in one or more elements of a safety policy spatial coordinates or location for applicability of the policy elements.

14. A method as claimed in any one of claims 1 to 13, including the step of specifying in one or more elements of the policy the state of objects for applicability of the policy elements.

15. A method as claimed in any one of the preceding claims, wherein the safety policy is applied by a calling object to accept or reject access to internet content.

16. A method of providing safety policies for members of a group, including the steps of, in a processing system: providing one or more safety policies for each group; storing the safety policies in a central store; enabling each member of the group to access and retrieve one or more of the safety policies of the group.

17. A method as claimed in claim 16, wherein a plurality of groups are organized in a group hierarchy, each group inheriting a safety policy from groups higher in the group hierarchy. WO 2012/174601 PCT/AU2012/000719 52

18. A method as claimed in claim 17, wherein a member object of a group derives elements of its safety policy from elements of the safety policy of the group.

19. A method as claimed in claim 18, wherein the inherited safety policy of the group contains one or more overrideable elements.

20. A method as claimed in claim 19, including the step of overriding one or more overrideable elements of the inherited safety policy to form an effective policy.

21. A method as claimed in claim 20, including the step of forming the effective policy from elements of the safety policy of the inheriting object and one or more groups higher in the group hierarchy.

22. A method as claimed in claim 21, including the step of forming the effective policy from elements of: the inheriting object, one or more objects higher in the object hierarchy and one or more groups higher in the group hierarchy.

23. A method of providing safety policies to objects substantially as herein described with reference to the accompanying drawings.

24. A system for providing safety policies including a server connected to a communication network and accessible by calling objects thereby, the server being adapted to provide safety policies to the calling objects according to the method of any one of the preceding claims.