WO2006091578A2 - Procedes, systemes et produits de programme informatique pour realiser une correlation, un routage et une distribution d'informations extensible sur la base du profil et du contexte - Google Patents

Procedes, systemes et produits de programme informatique pour realiser une correlation, un routage et une distribution d'informations extensible sur la base du profil et du contexte Download PDF

Info

Publication number
WO2006091578A2
WO2006091578A2 PCT/US2006/006075 US2006006075W WO2006091578A2 WO 2006091578 A2 WO2006091578 A2 WO 2006091578A2 US 2006006075 W US2006006075 W US 2006006075W WO 2006091578 A2 WO2006091578 A2 WO 2006091578A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
knowledge
metadata
satisfied
rules
Prior art date
Application number
PCT/US2006/006075
Other languages
English (en)
Other versions
WO2006091578A3 (fr
Inventor
Edward L. Bryan
David T. Bennett
Richard W. Zobel, Jr.
Donald J. Bell
Laura C. Vandivier
Jason K. Pace
Robert L. Welton
Willem J. A. Pet
Original Assignee
Knowledge Vector, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Knowledge Vector, Inc. filed Critical Knowledge Vector, Inc.
Publication of WO2006091578A2 publication Critical patent/WO2006091578A2/fr
Publication of WO2006091578A3 publication Critical patent/WO2006091578A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons

Definitions

  • a "sensor” refers to any of a wide number of systems, devices, software, or live observers that are able to capture and transmit data regarding one or more characteristics of the environment, software, database or system that they have been tasked with monitoring.
  • a sensor may include any mechanical, electro-mechanical, or electronic device capable of producing output based on observed or detected input.
  • the need for sensor fusion systems can be thought of as being directly analogous to the need for the trained observers who sit in front of the tens or hundreds of video screens watching the alarms and video surveillance systems as they are individually issuing alerts, then making an informed decision about the particular groupings and/or timings of the alarms as being important, based on their knowledge of policy and experience, and then determining the appropriate means for communicating this information to the people who need it.
  • the subject matter described herein includes a system for merging data from a plurality of different sensors and for achieving sensor fusion based on a rule or policy being satisfied.
  • the system includes a plurality of source plug-ins for receiving data from a plurality of different sensors.
  • a content manager merges the data from the sensors together with metadata that is representative of a context and aggregates the information and context metadata into knowledge items.
  • a scenario engine achieves sensor fusion by comparing the sensor data and its context metadata against a predefined set of policies or rules and for providing an action when a rule or policy is satisfied.
  • the subject matter described herein includes a system that includes the capability to define and utilize scenario-based rule and policy definitions in order to correlate event-based data across a multitude of sensor systems to determine, in real time, if the criteria for the specified policy(ies) have been successfully satisfied.
  • This capability will be referred to herein as sensor fusion, and the system which incorporates this capability will be referred to herein as a knowledge switch (KSX).
  • KSX knowledge switch
  • the present subject matter includes a system for providing the capability to record a specified accumulation of data and the current context (metadata) at the point that the rule/policy is satisfied and for encapsulating this set of disparate data into a self-encapsulated, decomposable data object.
  • the bundle of fused data, along with its metadata context and history will be referred to herein as a knowledge item.
  • the subject matter described herein includes methods for initiating predefined sequences of events when the rule(s)/policy(ies) become valid, which can include the pinpoint distribution of the data object, starting an application, triggering an alarm or handing off the data to another set of rules/policies. Additionally, the subject matter described herein includes the routing of the knowledge item (with additional pre-defined message information, if desired) to people or systems that need to be made aware of this information, based on the recipient's personal profile, as well as both static and dynamic organizational-based delivery rules. This includes the ability to transmit the data object to a second knowledge switch to allow for two-way switch-to-switch communication. Furthermore, the system-based software architecture of the subject matter described herein can be dynamically extended, with its functionalities and capabilities enhanced through the addition of external software modules which are plugged in to the base framework of the application.
  • the event data collected can be of any type (such as any of the types described in the above-referenced priority applications) and as a part of the rules/policies can be compared directly to other data (for example: “If the value of input flow is greater or lesser than output flow by more than 2%."), can be compared in parallel with other data (for example: “If the external temperature is lower than 50, and the internal temperature is lower than 70, and the external vents are reading as being open, then"), or can be evaluated on its own (for example: "If the poisonous gas sensor reads as TRUE, then York).
  • the context is included and shipped with metadata indicating that the data is a thermostat reading, taken at 3:02am, on sensor number 1a2b3c-4, in facility XYZ, in building ABC, has triggered 14 times in the past 7 hours, and is important because it triggered a scenario that was put in place to monitor the temperature inside a mission critical machine room and trigger if any computers in the room are operational and the thermometer is reading at or above 70.
  • the data object that this information is accumulated into is decomposable such that an individual data element can be quickly recovered upon request. This data object is referred to herein as a knowledge item.
  • a knowledge item may include a dollop of content that has actions and whose values over time are preserved, further, a knowledge item may:
  • This methodology allows individuals and systems to be delivered information in a precise way so that not only is the best contact method used, but the message can also be filtered to suit the specific expectations of the recipient, as well as having security measures put in place (authorization methods to prove you are who the system believes you to be and access restrictions to ensure that no information reaches the recipient that they are not allowed to see).
  • information within the profile can define logical next-tier recipients for both personal and organizational messages if the message still cannot be delivered after all possible routes have been exhausted.
  • This methodology also allows for the transmission of queries and/or questions (multi-choice or open-ended) to individuals or systems to respond to and in turn directly influence a next tier of questions or provide important information to be subsequently transmitted out to other individuals or systems.
  • This methodology involves a complex series of filtering and qualifying of the content, the recipient, and the device that may happen prior to a message being presented to recipient.
  • the combination of all of these filters existing within a single system and using these filters to qualify the delivery of a message to an appropriate recipient is believed to be advantageous.
  • Device Escalation Progression from device to device to contact a user
  • Personal Escalation (Personal backup recipient for delivery] The escalation of a recipient's message to another user profile upon the failure to reach the recipient at any of the recipient's specified contacts. This backup contact can be overridden by an organizationally based escalation user which would be specified in the message's certification definition.
  • Organizational Escalation Organizational backup user or system
  • Contact List means for contacting a user
  • the contact list is a master list of all of the user's possible contact modalities and acts as a user's default profile. From this master list can be drawn subsets of modalities called contact profiles.
  • Contact Profile An organization for contacting a user
  • a subset of a user's contact list that can be utilized at different times or for different needs. For example a nighttime profile may only have an email or pager contact, while an office profile may have office phone, cell phone, pager, email, etc. Additionally a contact profile can be defined to capture certain types of messages, (for example a daily corporate message of the day) and take that straight to email rather than have it contact you by phone. Another example would be an override profile for an urgent alarm priority message that would attempt authenticated contact by phone or pager no matter the time of the day or night.
  • Delivery Preferences [User definition for how the user's profile is utilized] The user-based definition of how contact profiles are utilized by the delivery engine to have a message delivered. The preference is established as a default, but can be overridden by a higher priority organizational delivery preference. Delivery preference examples may be:
  • Authorization Level Content access
  • Authorization Level An organizationally defined, controlled and maintained content access profile. Authorization Level is administratively managed, but may be viewed (but not modified) by the user. For example, in governmental applications the authorization level may be "Secret,” "Top Secret,” or
  • Access Profile system resource access
  • ACL Access Control List
  • This methodology allows for time- independent contact.
  • Current telephone call delivery methods require only that a call to be picked up and answered in order for an acknowledgement of receipt to be assumed. This current methodology can fail if the person picking up the call is not the intended recipient (for example, a child picks up), it can fail if voice mail picks up, and it leaves no options if the intended recipient is busy, or cannot be beside a phone.
  • a message can be transmitted (simultaneously if desired) to a pager, email, or a message left on voice mail that defines a range of time for the recipient to respond before the recipient recorded as having not acknowledged the message.
  • a pass-code system can be placed as a front gate (so to speak) that would allow the option of verified access, including access to secure information when the recipient contacts the system. Without this option, all that is known by the transmission system is that the receipt of the transmission was initiated by someone/something.
  • the same methods can be used at the close of the transmission to verify not only that the transmission was sent, but also that the same person who initiated the transmission completed the transmission and verifies that the person received and understood the transmission.
  • U.S. Patent Number 6,658,414 discloses in detail a method referred to as microbroadcasting. This method includes the ability to request GPS-based location data as a part of the process of logging in to a user's personal microbroadcast.
  • the subject matter described herein includes a knowledge switch that can continuously collect this user-profile- specific data such that these fields can be dynamic rather than static.
  • This dynamic data can be utilized within rules (see Roles and Advanced Scenario Logic above) to make moment-by-moment assessments of a rule.
  • This dynamic data can be utilized along with other dynamic data or static data to provide topics of relevance (local forecast or emergency weather alerts for wherever a person is located at that specific time, even if the recipient is driving), access control for physical and content access, roles (as described above), KSX to KSX communications (as described above), and any other mechanism that utilized dynamic input as a factor within a rule to determine the appropriateness of an action or capability.
  • An example of the subject matter described herein could be the use of the dynamic profile data of duty roster, access control, location, and time to make an assessment about a specific user's ability to have the appropriate privileges as dictated by the role of "Tower Chief.
  • a rule that includes all of these variables in English: Give UserX appropriate systems access and authorization to perform as Tower Chief if and only if the following is true: 1 ) User is geographically within fifty feet of the center of the tower; 2) User has used the appropriate credentials to gain access to the tower floor; 3) User is scheduled within the duty roster to perform this role; and 4) the time is currently between the start and end time on the duty roster that this user is scheduled to perform this role.
  • a dynamic group however does not have to be used exclusively for people; it is limited only by objects that can be grouped and the rules available to filter the group at the time it is requested.
  • the concept of a logic engine that is able to take a logical statement with one or more data points and return a true/false response is described in the above-referenced United States Patent Application Number 10/020,260, filed December 14, 2001. Additional capabilities of such a logic engine may include:
  • Ability for rules to reference data queries and any function e.g., statistical functions that do not return on a single data value but rather return information about a set of data elements.
  • the ability for a knowledge switch to communicate with another knowledge switch via the transmission of alerts to a series of predetermined templates has significant benefits for the scaling of systems.
  • the present subject matter may include a facility for allowing administrative-based changes to a knowledge switch's provisioning (content, logic, distribution, profiles) based on a hierarchical relationship. Additionally, methods of making information available based on "need-to-know" rights management within a peer-to-peer relationship are provided. Geographical proximity may also be used as a deterministic factor in the proactive dissemination of information between knowledge switches.
  • KSX-to-KSX communications With a hierarchical relationship utilized for KSX-to-KSX communications, some amount of administrative rights are assigned for a parent KSX to proactively and securely provision a child KSX with new logic, new scenarios, new content, new profiles or new rules for the dissemination of information. This ability to do administrative level provisioning allows a parent KSX to define and control the flow of information across a large umbrella of distributed systems. All communications can be managed through a secure web services layer, and administrative rights can be managed locally for each domain. A top down approach can be used for the hierarchical distribution of information and control logic.
  • This methodology minimizes the direct management that a parent needs to maintain for a child node and allows for a true distributed awareness system with localized, domain specific implementation that allows for a large overall umbrella of awareness for the parent KSX.
  • An example of a hierarchical topology would be the Federal Aviation Administration (FAA) knowledge switch as the top parent node, FAA airport regional coordinator knowledge switches as the next tier in the hierarchy, individual airport knowledge switches as the subsequent tier, and other knowledge switches at individual airports as the lowest tier.
  • FAA Federal Aviation Administration
  • individual divisions such as security, tower, airline, and so forth
  • Each KSX may have some administrative oversight by the next logical tier up to allow for discovery and transmission of specific data that may or may not be being scanned for by the local KSX.
  • the peer-to-peer deployment method presumes a flat topology where all KSX nodes maintain domain-specific knowledge, and there are no administrative rights given to KSX systems to modify another system's provisioning.
  • a peer-to-peer deployment allows communications via subscription and/or need-to-know messaging.
  • the operators of each deployment make determinations of what information to publish and make available to other KSX systems.
  • information may be passed by request rather than by command.
  • An example of this deployment could be all local police stations sharing information about gang-related crime in their respective regions so that similarities or transient gangs can be more quickly spotted and isolated.
  • a geographic-proximity-activated KSX-to-KSX communications methodology allows for domain specific deployment where the sphere of awareness extends to an approximation of a volumetric boundary around the KSX.
  • These spheres of awareness can be located upon a mobile platform (car, train, ship, plane) and can intersect with other spheres of awareness that are also mobile or even perhaps stationary (tunnel, depot, emergency services).
  • the intersection of these spheres of awareness is established, the communication of vital information is initiated between the two systems in a directed, peer-to-peer fashion.
  • An example of this type of deployment could be a train carrying dangerous toxins moving between stations and various emergency districts.
  • the train once it crosses into a new jurisdiction (sphere of awareness based on an emergency services geographical boundary), could pass basic information about cargo types, wheel reports, and emergency information in case of an accident.
  • Information passed into the train could include emergency services contact information for that jurisdiction as it passes through, delays or safety bulletins, and proximity to other known obstacles such as other trains in the area, or traffic tie-ups that could potentially affect an upcoming train crossing.
  • the use of a plug-in to extend the standard core architecture has significant merit over the current methods utilized for developing large, enterprise- or facility-wide unifying architectures.
  • Current methods derive solutions through the purpose- developed solution that is largely customized and non-reusable in nature. In all large deployments into existing sites, there is always a great deal of existing legacy equipment, infrastructure, or systems that must be integrated and utilized, or else replaced with new equipment, and then the new equipment or infrastructure or systems must be integrated.
  • a plug-in in this instance is a piece of software that is adapted (or removed) to the core system during run-time (to avoid starting and stopping the system when operating) that allows the externalized systems (sensors, content provider, content rendering definitions, logic engines, external databases of users, delivery systems and devices) to be added (or removed) in to an operating system and begin the immediate utilization of that resource without affecting the remainder of the systems operations.
  • These plug-ins are created to act as intermediaries between the existing deployed systems and the core of the KSX so that the core system does not have to be modified or even stopped in order to extend the capabilities of the overall system.
  • An example of this could be a KSX deployed as a perimeter security system at a secure facility.
  • a newly developed motion and object detection system has just arrived at the facility along with a new radio communications device.
  • Each of these newly arrived systems has a respective piece of software (plug-in) that was developed by the company to allow their equipment to be utilized as a component of a deployed KSX.
  • the systems are set up and tested separately from the KSX until all the installation bugs are worked out, and the system is ready to be integrated into the operation of the currently operational KSX.
  • the KSX administrator loads the plug-ins from an administrative interface (while the KSX continues to maintain a security watch on the perimeter of the facility), and through the options provided via the plug- in, establishes the way that the subsystem will communicate with the KSX and how the data can be accessed when the provisioning of these new subsystems begins.
  • the plug-in is activated, and data begins to be transferred between the KSX and the subsystems.
  • operations experts can provision the KSX with scenarios that utilize this data from the new systems and cross link it when desirable with the data that was previously in the system.
  • plug-in architecture allows the overall deployment configuration to be maintained and optimized over time by: allowing run-time modifications of what systems are utilized by the KSX, providing specific (yet changeable) definitions of how systems are utilized within the KSX, allowing legacy systems to be utilized or decommissioned easily without modifying code, • precise (and changeable over time) definition of how many systems are needed and thus how large the system needs to be to manage these subsystems, simple scaling of the system through the addition or subtraction of plug-ins, • cost effective deployment, administrative efficiency for deployment, ability for a deployment to change dramatically over time with no adverse impact, ability to control subsystems input on a one-by-one basis, and ability to refine the storing and navigation of a subsystems data for operational use.
  • the knowledge switch utilizes a hot-pluggable and swappable plug-in model that allows for the extensibility of functionality for a KSX during run-time with no need to restart any part of the system.
  • a plug-in is a stand-alone, reusable, extensible, language and platform independent piece of software that is written to adapt any external network available data stream to a fixed, published knowledge switch application programming interface (API) layer which is available for extensible modules within the knowledge switch (content manager, scenario engine, profiles manager, message engine and delivery engine).
  • API application programming interface
  • Plug-ins are write once and reuse over and over, such that once a custom plug-in is created to interface an external system's data stream to the knowledge switch, it is not necessary to create any code to interface this same system to another KSX.
  • the plug-in can be re-used with another knowledge switch.
  • the API layer is the handshake point for all data entering and leaving the KSX and thus allows for a highly customized, site-specific configuration without the need to customize the core system.
  • a plug-in can be created as a generic interface to the KSX such that it conforms to a known data transfer standard, such as a web services standard, XML, SNMP, or other recognized standard. Plug-ins can also be created to interface non-standard data streams from systems, and thus the high levels of flexibility and adaptability that plug-ins afford the KSX can be achieved.
  • the subject matter described herein may be implemented using a computer program product comprising computer-executable instructions embodied in a computer-readable medium.
  • Exemplary computer-readable media suitable for implementing the subject matter described herein include chip memory devices, disk memory devices, programmable logic devices, application specific integrated circuits, and downloadable electrical signals.
  • a computer program product that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
  • Figure 1 is block diagram illustrating a simplified exemplary architecture of a knowledge switch showing only the core modules that typically comprise a system according to an embodiment of the subject matter described herein;
  • Figure 2 is a block diagram illustrating the knowledge switch of Figure 1 where additional detail is provided regarding sensor data format and data transport external and internal to the system according to an embodiment of the subject matter described herein;
  • Figure 3 is a block diagram illustrating an exemplary deployment of a knowledge switch, where the deployment includes an exemplary infrastructure, exemplary sensors, exemplary message delivery methods, exemplary rules, and exemplary plug-ins for the system according to an embodiment of the subject matter described herein;
  • Figure 4 is a block diagram of the knowledge switch of Figure 3 highlighting details of extensible knowledge switch plug-ins according to an embodiment of the subject matter described herein;
  • Figure 5 is a block diagram of the knowledge switch of Figure 3 highlighting details of the knowledge switch core, the core plus the plug-ins, and external systems with which the knowledge switch may interface according to an embodiment of the subject matter described herein;
  • Figure 6 is a block diagram illustrating an exemplary peer-to-peer deployment of knowledge switches according to an embodiment of the subject matter described herein;
  • Figure 7 is a block diagram illustrating an exemplary hierarchical deployment of knowledge switches according to an embodiment of the subject matter described herein;
  • Figure 8 is a block diagram illustrating an exemplary deployment of knowledge switches on mobile and stationary platforms according to an embodiment of the subject matter described herein;
  • Figure 9 is a flow chart illustrating exemplary overall steps for knowledge item creation and sensor fusion according to an embodiment of the subject matter described herein.
  • FIG. 1 is a block diagram illustrating exemplary software modules of an extensible system for profile- and context-based information correlation, routing, and distribution according to an embodiment of the subject matter herein.
  • the system comprise a knowledge switch 100 including a core 102 and plug-ins 104, 106, 108, and 110 that extend the functionality of core 102.
  • core 102 includes software modules that provide basic knowledge switch functionality.
  • Software modules that provide this core functionality included a content manager 111 , a knowledge item database 112, a message engine 113, a message database 114, a delivery engine 116, a microbroadcasting portal 118, a profiles manger 120, and a scenario engine 122.
  • Scenario engine 122 applies rules defined by scenarios 110 to the knowledge items to achieve sensor fusion. For example, scenario engine 122 may compare sensor data and its context against a defined set of policies and/or rules and provide some action when a rule or action is satisfied.
  • Message database 114 stores messages to be delivered to individuals or other knowledge switches when a scenario is triggered.
  • Profiles manager 120 stores contact profiles to determine how a message is to be delivered to a recipient. If the contact profile does not require contact, then the message is placed into a construct referred to as a topic for later retrieval by the recipient via microbroadcasting portal 118. If the contact profile requires contact, the message is placed in a topic and a request is placed to delivery engine 116 to connect to recipient with his or her personal microbroadcast via a specified device and/or based on specified schedule. Delivery engine 116 is responsible for delivery of messages to recipients using information specified in their contact profiles and for interfacing with specific delivery devices via device- specific plug-ins 108.
  • Message engine 113 receives notifications from triggered scenarios and organizes them appropriately. Messages are then associated with a topic via a topic template and a contact profile for the intended recipient.
  • the topic template may specify how a message should be presented.
  • the contact profile may specify unique user preferences for delivering the message.
  • content manager 111 merges data from different sensors with metadata identifying the source of the data using source plug-ins 104.
  • the metadata that can be linked to the sensor data may include information about where a specific sensor is known to reside (geographical location, building, facility room, or other positional information), links back to knowledge item database 112 to other data that is known to be relevant to the context of the sensor data (links to historical data readings, links to data from other sensors in the same general region), current time and date information, context about the type of sensor collecting the data (such as thermostat, range of acceptable data readings, known standard limits), links to history data (when installed, offline times, repair records) and links to any previous points in history when this data was involved in triggering of a scenario.
  • FIG. 2 is a block diagram illustrating exemplary operation of source plug-ins 104, content manager 111, and knowledge item database 112 in more detail.
  • source plug-ins 104 receive data from a plurality of different sensors 200-208. The data arrives in different formats, such as bit stream format, mime format, HTML format, proprietary format, or web formats, such as XML or SOAP.
  • Source plug-ins 104 receive the data in different formats and provide the data to content manager 111.
  • Content manager 111 associates the data from the various sensors with context-specific metadata and stores the data in knowledge item database 112. The data is stored as knowledge items 210-222, which include the sensor data and the context-specific metadata.
  • Figure 3 is a block diagram illustrating an exemplary deployment of knowledge switch 100 illustrated in Figure 1.
  • knowledge switch 100 includes source plug-ins 104 to interface with different types of sensors 300- 306.
  • Knowledge switch 100 may further include rules plug-ins 308 and 310 to interface with external logic engines 312.
  • External logic engines 312 may be logic engines that are associated with agencies that process data using their own internal rules.
  • external logic engines 312 may be logic engines provided by federal or local law enforcement agencies that process data to identify the presence of an event that requires an alert to be generated.
  • an associated rule takes data objects involved at that point when the rule was satisfied and determines who to transfer the information to by the use of profiles stored by profiles manager 118.
  • the profile may include contact information generated when the recipient's profile was created and may be maintained by the recipient or a representative of the recipient. The profile determines what information should be received by the recipient, the format of the information based on the list of devices provided by the recipient, or any organizational information that defines the type of information that the recipient is allowed to receive.
  • the distribution of information may further be qualified by dynamic groups, asynchronous routing, and authentication and acknowledgement methods.
  • a dynamic group may be defined by a profile maintained by profiles manager 120.
  • the profile for a dynamic group may contain an identifier, such as "first shift management team," which is linked with the profiles of individuals that are current members of the management team so that alerts that are generated during the first shift will be distributed to the appropriate individuals and in the appropriate formats.
  • Asynchronous routing refers to a routing method defined in an individual's profile where a message is first attempted to be delivered to the individual. Delivery may be reattempted for a time period defined in the individual's profile. If delivery fails within the time period, delivery may be attempted to a fallback individual defined within the first individual's profile.
  • Authenticated delivery refers to the requiring an individual to provide credentials as a condition to receiving a message.
  • Confirmed delivery refers to requiring the recipient to confirm receipt of a message by providing an acknowledgement when a message is received an understood.
  • delivery engine 116 under the control of profiles provided by profiles manager 118.
  • the system illustrated in Figures 1 -3 is preferably extensible through the use of modular plug-ins.
  • An example of a modular sensor plug-in using an API written using the API provided by core 102 is as follows:
  • “Foo Bar” company provides a weather station aggregator sensor system, which periodically reports temperature, humidity, and wind speed recorded by a number of remote devices.
  • the plug-in developer uses an API provided by the developer of knowledge switch 100, the plug-in developer:
  • the base sensor class to provide the runtime functionality of the plug-in, overriding the default runtime methods (such as init, startup, shutdown, etc) with Too Bar" sensor-specific implementations.
  • the startup method is overridden to initially connect via network socket to the weather station aggregator and register to receive its data reports.
  • the developer may also include custom exception handlers for dealing with the case of a connection or registration error (e.g.: some developers might choose to implement a sleep/retry scheme to re-attempt a connection, while other may prefer to simply log the error and terminate).
  • the shutdown method is overridden to send an un-register message to the weather station aggregator (so that the aggregator does not keep attempting to send reports) and then closes the reporting socket.
  • the plug-in API includes documented methods for reporting and persisting new incoming data from the plug-in to the KSX, and the developer simply invokes these methods in order to have the KSX scenario engine process incoming data from the plug-in.
  • Similar plug-ins may be provided for extending the functionality scenario engine 122, delivery engine 116, and message engine 118 illustrated in Figure 1.
  • FIG. 5 is a block diagram of the system illustrated in Figure 3 illustrating additional areas of system 100 and the associated devices with which it interfaces. More particularly, the system includes core 102 that includes the components that are deployed with each deployment of system 100. These components are described above with regard to Figure 3. Hence, a description thereof will not be repeated herein.
  • Area 500 includes core 102 plus the plug-ins that are responsible for the optimizing core 102 for a particular deployment.
  • the components within areas 502, 504, and 506 represent the external devices with which system 100 interfaces. In the illustrated example, these devices include sensors, external rule and logic systems, communications channels in their associated devices and protocols.
  • FIG. 6 is a block diagram illustrating one deployment of a plurality of knowledge switches 100 that communicate with each other in a peer-to-peer manner.
  • eight switches 100 are illustrated.
  • Each switch 100 preferably has the ability to communicate with every other switch in the distribution.
  • a traditional publish and subscribe communications protocol can be used to ensure that as one switch 100 has a rule that is satisfied, a corresponding knowledge item will be distributed to the full group. Any other switch 100 in the group that is subscribed to receive such information will receive the information immediately upon the information being transmitted by the originating system.
  • Such a deployment will be optimal for a university system or a large international corporation with offices distributed in geographically separate locations.
  • Figure 7 illustrates a hierarchical deployment of knowledge switches 100A-J according to embodiment of the subject matter described herein.
  • communications between knowledge switches are no longer flat, but rather travel up and down a predetermined chain of command.
  • a top node knowledge switch 100A may have the responsibility of passing requests down through the chain and also have receiving information only form links to knowledge switches 100B, 100C, and 100D on the next level in hierarchy.
  • the knowledge switches in the next level may only receive information from knowledge switches 100E-100J on the next level of the hierarchy.
  • this type of deployment would be used in agencies or within a corporation where there is too much event information for a single system to process. As a result, the load is distributed among nodes 100E-100J and processed by rules of increasing discrimination at higher levels in the hierarchy.
  • Hierarchical deployment of knowledge switches also allows for the provisioning of lower tier systems automatically with the subsets of the top tiers systems, the rule sets, recipient profiles, and distribution profiles.
  • Hierarchical provisioning allows an upper tier knowledge switch 100A to load balance various activities (sensor data collection for example) by automatically provisioning lower tier knowledge switches 100B-100J with rules subsets which if satisfied act as a single sensor data event to an upper tier system.
  • Such hierarchical provisioning dramatically lightens the processing overhead. The in same way, redundancy of systems and rules can be instituted.
  • Figure 8 is a block diagram illustrating a deployment of knowledge switches 100K-100O where some of the knowledge switches are located on mobile platforms and other knowledge switches are located on stationary platforms.
  • knowledge switch 100K may be located on a mobile platform such as a car, a train, an aircraft, or a watercraft.
  • Knowledge switch 10OK maintains the responsibility for sensors and events based on the scope of an area of awareness for that system.
  • the area of awareness may be defined as the geographical functional boundaries that describe the limit of the sensors that are associated with the particular system.
  • there can be multiple areas of awareness depending on the sensor events being accessed by the rules in question.
  • the remaining knowledge switches illustrated in Figure 8 may be associated with stationary platforms or other mobile platforms. For example, if knowledge switch 10OK is located on a watercraft, such as barge, knowledge switch 100L may be located on a bridge.
  • Knowledge switches 100K and 100L may be communication with each other when knowledge switch 100K comes with in the area of awareness of knowledge switch 100L.
  • Knowledge switch 100K may communicate cargo being carried into the area of awareness of knowledge switch 100L.
  • Knowledge switch 100L may indicate whether or not it is safe to bring the specific cargo into its area of awareness given circumstances regarding the bridge. For example, it may not be safe to bring a cargo of explosive material through the main channel under the bridge during a time of heavy traffic on the bridge.
  • communications may be initiated through publish and subscribe methodologies.
  • communications between knowledge switches may be initiated by higher nodes querying lower nodes or lower nodes transmitting accumulated data from satisfied rules to higher nodes.
  • communications between systems may be initiated by the geographical functional boundaries from separate systems overlapping or triggering a conversation between systems to determine if and what information needs to be exchanged. This is a hybrid of the two previous systems in that a triggering event initiates the initial communications.
  • a train may have a knowledge switch located on board that is traveling through a specified path, such as path 800.
  • the geographic areas of awareness boundaries 804, 806, 808, and 810 may intersect or not intersect with area of awareness boundary 802 of knowledge switch 100K.
  • the stationary systems may communicate with mobile system 100K. These stationary systems may represent car reporting stations or track repair warnings located at stations. The stations may also represent other transit systems, like another train that could relay operating conditions weather, notices, and other relevant information regarding where they have been and where they are traveling.
  • the code determines whether the motion. detected field in a motion sensor knowledge item is true. If this field indicates that motion was detected, the content manager searches the knowledge item database for a camera knowledge item for the same location and time where the motion was detected. The content manager then calls a send function that invokes the delivery engine to send the camera image, the recording location, and the recording time to members of a contact list.
  • a send function that invokes the delivery engine to send the camera image, the recording location, and the recording time to members of a contact list.
  • the present subject matter may include a library of mathematical and other functional expressions usable to define logic implemented by knowledge switch 100. More particularly, this library may be available to scenario programmers to define scenarios usable by scenario engine 116 to operate on knowledge items stored in database 112 and perform or provide for performance of an action in response to a rule or policy being satisfied.
  • This library may be available to scenario programmers to define scenarios usable by scenario engine 116 to operate on knowledge items stored in database 112 and perform or provide for performance of an action in response to a rule or policy being satisfied.
  • the follow are examples of functional expressions that may be included in such a library:
  • Trigger when a camera detects motion and a check is transacted within 5 seconds correlates a check transaction with a video clip
  • trigger anynwithin ( seconds(5), 2
  • the sensor plug-ins that extend the capabilities of the knowledge switch may interface may receive and store the data output from a first sensor and data from a second sensor which have no relationship to one another, where a sensor is defined as (but not limited to): (1 ) Any mechanical or digital instrument capable of transmitting relevant information
  • a stand-alone element (sensor) that transmits raw data (3) A stand-alone element (sensor) that transmits raw data (4) Requested information transmitted from a human being
  • a public or private content supplier for example a news feed or web site
  • the content manager may provide the ability to merge the received data from the individual sensors with metadata that is representative of a real world context where the contextual metadata is (but is not limited to):
  • the scenario engine may provide the capability to define rules and policy definitions for sensor fusion by:
  • the scenario engine may, when a policy or rule is satisfied, initiate an action where the action can be (but is not limited to):
  • the content manager may generate a data object (called a knowledge item) which:
  • the delivery engine may transmit knowledge item(s) which: (1 ) Are initiated when a defined rule or policy is satisfied (2) Are included in the transmission together with additional predetermined messages (3) Are distributed across a multiplicity of telecommunications channels (4) Are distributed to a multiplicity of recipients
  • the delivery engine may provide secure, authorized, and authenticated transmission of knowledge items including (1 ) Authentication (Prove or confirm a users identity through some mediating technology such as PIN 1 password, pass-phrase, biometric, visual recognition system, trained observer)
  • the scenario engine may utilize libraries of function calls as a part of the evaluation criteria for the rule/ policy definitions.
  • function libraries may include:
  • the subject matter described herein may include a distributed group of knowledge switch systems where:
  • the information transmission can be initiated by satisfying a minimum distance for the geographic proximity between two knowledge switch systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente invention concerne des procédés, des systèmes et des produits de programme informatique pour réaliser une corrélation, un routage et une distribution d'informations extensible sur la base du profil et du contexte. Selon un système, des modules d'extension sources reçoivent la sortie d'une pluralité de détecteurs différents. Un gestionnaire de contenu fusionne des données issues de détecteurs individuels, avec des métadonnées qui représentent un contexte, et réalisent une agrégation des données de détection et des métadonnées de contexte, sous la forme d'éléments de connaissance. Un moteur de scénarios réalise une fusion de détection en comparant les données de détection et leurs métadonnées de contexte avec un ensemble défini de polices et/ou de règles, et assure la mise en oeuvre d'une action lorsqu'une règle ou une police est satisfaite.
PCT/US2006/006075 2005-02-22 2006-02-22 Procedes, systemes et produits de programme informatique pour realiser une correlation, un routage et une distribution d'informations extensible sur la base du profil et du contexte WO2006091578A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US65515205P 2005-02-22 2005-02-22
US60/655,152 2005-02-22

Publications (2)

Publication Number Publication Date
WO2006091578A2 true WO2006091578A2 (fr) 2006-08-31
WO2006091578A3 WO2006091578A3 (fr) 2009-04-16

Family

ID=36927946

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2006/006075 WO2006091578A2 (fr) 2005-02-22 2006-02-22 Procedes, systemes et produits de programme informatique pour realiser une correlation, un routage et une distribution d'informations extensible sur la base du profil et du contexte

Country Status (1)

Country Link
WO (1) WO2006091578A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012001462A1 (fr) * 2010-06-30 2012-01-05 Nokia Corporation Procédé et appareil permettant le contrôle de la consommation d'énergie sur la base du contexte
WO2018166698A1 (fr) * 2017-03-17 2018-09-20 Robert Bosch Gmbh Commande de traitement d'un système de détection
CN114090113A (zh) * 2021-10-27 2022-02-25 北京百度网讯科技有限公司 数据源处理插件动态加载的方法、装置、设备及存储介质
WO2024083955A1 (fr) * 2022-10-18 2024-04-25 Barco N.V. Procédé et système de génération d'un signal de vidéocommunication

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040034795A1 (en) * 2001-04-30 2004-02-19 Anderson Mark Stephen Event handling system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040034795A1 (en) * 2001-04-30 2004-02-19 Anderson Mark Stephen Event handling system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HELMER, GUY ET AL.: 'Lightweight agents for intrusion detection' IN JOUMAL OF SYSTEMS AND SOFTWARE, [Online] vol. 67, no. ISSUE, 24 November 2000, pages 109 - 122 Retrieved from the Internet: <URL:http://www.palisadesys.com/-ghelmer/Papers/NewFacets.ps> [retrieved on 2007-06-20] *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012001462A1 (fr) * 2010-06-30 2012-01-05 Nokia Corporation Procédé et appareil permettant le contrôle de la consommation d'énergie sur la base du contexte
WO2018166698A1 (fr) * 2017-03-17 2018-09-20 Robert Bosch Gmbh Commande de traitement d'un système de détection
CN110753907A (zh) * 2017-03-17 2020-02-04 罗伯特·博世有限公司 传感器系统的处理控制
JP2020510937A (ja) * 2017-03-17 2020-04-09 ロベルト・ボッシュ・ゲゼルシャフト・ミト・ベシュレンクテル・ハフツングＲｏｂｅｒｔ Ｂｏｓｃｈ Ｇｍｂｈ センサシステムの処理制御
US11263163B2 (en) 2017-03-17 2022-03-01 Robert Bosch Gmbh Processing control of a sensor system
CN110753907B (zh) * 2017-03-17 2024-06-04 罗伯特·博世有限公司 传感器系统的处理控制
CN114090113A (zh) * 2021-10-27 2022-02-25 北京百度网讯科技有限公司 数据源处理插件动态加载的方法、装置、设备及存储介质
CN114090113B (zh) * 2021-10-27 2023-11-10 北京百度网讯科技有限公司 数据源处理插件动态加载的方法、装置、设备及存储介质
WO2024083955A1 (fr) * 2022-10-18 2024-04-25 Barco N.V. Procédé et système de génération d'un signal de vidéocommunication

Also Published As

Publication number Publication date
WO2006091578A3 (fr) 2009-04-16

Similar Documents

Publication Publication Date Title
US20060265397A1 (en) Methods, systems, and computer program products for extensible, profile-and context-based information correlation, routing and distribution
Gharaibeh et al. Smart cities: A survey on data management, security, and enabling technologies
Kraijak et al. A survey on internet of things architecture, protocols, possible applications, security, privacy, real-world implementation and future trends
US20190116478A1 (en) System and method for remote asset management
CN103944924B (zh) 一种基于RESTful的泛在网发布订阅中间件模型的方法
US9558645B2 (en) Released offender geospatial location information trend analysis
US20170316181A1 (en) Global disease surveillance platform, and corresponding system and method
Davies et al. The internet of things: from data to insight
EP2801082B1 (fr) Application utilisateur pour des informations de position géospatiale de délinquants remis en liberté
Scherp et al. A core ontology on events for representing occurrences in the real world
CN109684180A (zh) 用于输出信息的方法和装置
AU2015205906B2 (en) Released offender geospatial location information clearinghouse
WO2006091578A2 (fr) Procedes, systemes et produits de programme informatique pour realiser une correlation, un routage et une distribution d&#39;informations extensible sur la base du profil et du contexte
Bhargava et al. An ontological context model for representing a situation and the design of an intelligent context-aware middleware
Ahmed et al. Privacy-preserving active learning on the internet of 5g connected artificial intelligence of things
CN114885012A (zh) 物联网平台的系统接入方法及系统
Alazzawi et al. Insight into iot applications and common practice challenges
CN102483838A (zh) 使用社会网络的安全管理
Masinde et al. A Middleware for Cyber Physical Systems in an Internet of Things Environment: Case of for Mobile Asset Tracking
Li et al. Research of IOT Context-Aware Processing Framework Based on Complex Event for Supply Chain Application
Ferrari et al. Agents and Ambient Intelligence: the LAICA Experience
CN111741071A (zh) 数据处理方法、装置、电子设备及存储介质
Davies et al. The Internet of Things
AYEMHOLAN et al. A Framework for Unified Distributed System for Crime Prevention and Detection (UDSCPD)

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 4757/DELNP/2006

Country of ref document: IN

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06735643

Country of ref document: EP

Kind code of ref document: A2