Patent Application
20060282886
An embodiment of the disclosed invention relates generally to a computerized network of devices, and, more particularly, to a service oriented security device management network.
Airports, and other facilities where security devices may be desired, may employ different types of security devices or equipment in an attempt to detect potential threats to security. It may be desirable to connect the security devices (or machines) into a network for centralized communication, control, and/or management. Conventional methods of connecting the security devices in a centrally managed network may be difficult, expensive, and/or time consuming due to the potentially different makes and models of the machines. Upgrading the software in a conventional centralized management system may be difficult, expensive, or time consuming. Also, the security devices may be located within a single facility or distributed across a geographical area presenting additional problems for a central communications and control facility using conventional techniques.
Security devices, such as, for example, airport screening equipment (threat image projection x-ray machines, explosive trace detectors, explosive detection systems, walk through metal detectors, and the like) may often be stand alone machines. This equipment may have network connections, but may not be managed from a central location. There may be a desire to centrally control these devices, for example through the Security Technology Integrated Program (STIP).
An exemplary embodiment of this invention relates to a service oriented architecture approach to providing a centralized management network for security devices, for example, in terminal/airport/regional and/or national/international centralized control and data management center(s). A Service Oriented Architecture (SOA) embodiment in accordance with the present disclosure may allow the entire management task to be broken down into objects that are individually network addressable. A business rules engine using scripting may then invoke the objects and tie them together in a coherent application based on one or more business rules, as described in greater detail below. A network of security devices may be managed using services provided by the objects via the business rules engine and associated scripting.
An exemplary SOA embodiment of the present invention may also allow additional functionality to be added with a change of script and additional software objects. This approach may reduce or eliminate a need for a recompile/re-release cycle of an entire application to add additional functionality. It may also allow software updates to be developed and supplied from multiple sources.
In another example, an aspect of the present disclosure is directed to reducing a need for a control and management system to have knowledge of communications requirements specific to a particular make and model of threat scanning machines, for example, through a service oriented architecture (SOA) system. The SOA control and management system may be loosely coupled to the individual scanning devices though SOA interface coupled to each device under control of the control and management system.
Although one control center 20 and one security device 22 are shown in
The security device 22 may include threat scanning equipment, surveillance equipment, perimeter or area intrusion detection equipment, and/or the like. Threat scanning equipment (or security devices) may include x-rays, metal detectors, chemical sensors, imaging devices, shipping container inspection devices, and/or the like. Threat scanning equipment may include electrical, mechanical, chemical, nuclear, and/or biological sensors in order to attempt to detect potential security threats. The terms “threat scanning machine” and “security device” as used in this disclosure are intended to be interchangeable and may include one or more of the various devices listed above.
In operation, the control center 20 may use a service oriented architecture (SOA) management network system to control, manage, and/or communicate with the security device 22. An SOA system may include a collection of services that may communicate with each other. The communication may involve simple data passing or it may involve two or more services coordinating an activity. Services may be connected to each other. An SOA may provide loose coupling among interacting software agents. A service may be a logical unit of work done by a service provider to achieve a desired end result for a service consumer. Both the service provider and the service consumer may be roles played by software agents on behalf of their owners (or controlling applications or scripts). For example, in a security device update service, a control center may be a provider of updated security device software and the security device may be a consumer requesting updated software if available. It should be appreciated that the control center 20 and security device 22 may each be a service provider and/or service consumer.
An SOA system may be different from an object oriented programming architecture, which may encourage binding data and related processing together. An SOA may achieve loose coupling among interacting software agents by employing two architectural constraints: a small set of simple, generic, and/or ubiquitous interfaces and descriptive messages constrained by an extensible schema delivered through the interfaces. The small set of simple and ubiquitous interfaces may be available to a portion or all of the participating software agents. Generic semantics may be encoded at the interfaces. The interfaces may be universally available for all providers and consumers. The descriptive massages may contain little or no prescribed system behavior. A schema may limit the vocabulary and/or structure of messages. An extensible schema may allow new versions of services to be introduced without causing existing services to become inoperable. In other words, existing service interfaces may be left intact while new interfaces are added (i.e. the schema may be extended), thus allowing the existing service to still function along with a new service. It should be appreciated that while goals of an SOA may differ from an object oriented architecture, object oriented programming and/or languages may be used to implement a portion of the SOA systems and methods of the present invention.
Interfacing may be of significant importance in the disclosed SOA security device management network. For example, if the interfaces between a control center 20 and a security device 22 do not work, then the control and communication system may not work. Interfacing may also be expensive and error-prone for distributed applications. An interface may need to prescribe system behavior, which may be very difficult to implement correctly across different platforms and languages. Remote interfaces may often be the slowest part of a typical distributed application. For these reasons, among others, the SOA systems and methods of the present disclosure may be implemented using a few generic interfaces that may be reused, instead of building new interfaces for each application. Because only a few generic interfaces may be available, application-specific semantics may be expressed within messages. Any kind of message may be sent over the interfaces, but rules may need to be followed in order for the architecture to be a service oriented architecture.
The messages sent and received by the disclosed SOA security device management network may be descriptive, rather than instructive, because the service provider may be responsible for solving the problem. In other words, a service provider may be better positioned to determine how to perform a service, while a service consumer may be in a better position to determine what services are needed or desired.
Service providers in the disclosed system may be unable to process a request if a message containing the request is not composed in a format, structure, and/or vocabulary that may be processed by both the service provider and a service consumer (or requester). Limiting the vocabulary and structure of messages may result in an efficient communication. Further, the more restricted a message may be, the easier it may be to process the message. Although it should be appreciated that message restriction may come at the expense of reduced extensibility.
Extensibility may be a preferred aspect of communications between service providers and services consumers in the disclosed security device management network. For example, software and/or hardware changes may demand corresponding changes in the software system, service consumers, providers, and the messages they exchange. If messages were not extensible, consumers and providers may be locked into one particular version of a service. Extensibility may provide for a cost effective method of updating service messages to reflect changes in a system or in a component of the system.
A service discovery mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer may be a desirable aspect of the disclosed SOA security device management network. The service discovery mechanism may be flexible, and may include a centralized registry.
The disclosed SOA systems and methods may be subject to additional constraints that may be applied in order to improve scalability, performance, and/or reliability. The additional restraints may include stateless service, stateful service, and idempotent request. In a stateful service SOA system, each message that a consumer sends to a provider may contain all necessary information for the provider to process it. This constraint may provide a service provider with greater scalability because the provider does not have to store state information between requests.
Stateful service may be useful in a number of situations, such as, for example, establishing a session between a consumer and a provider. A session may typically be established for efficiency reasons. For example, sending a security certificate with each request may present a serious burden for both consumer and provider. It may be less burdensome to replace the security certificate with a token shared just between the consumer and provider. Stateful services may require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. A potential drawback of the stateful service constraint may be that it may reduce the overall scalability of the service provider because it may need to remember the shared context for each consumer. It may also increase the coupling between a service provider and a consumer and makes switching service providers more difficult.
In an exemplary disclosed idempotent request restrained system, duplicate requests received by a software agent have the same effects as a unique request. An idempotent request embodiment may allow providers and consumers to improve the overall service reliability by simply repeating the request if faults are encountered.
The disclosed SOA security device management network may include interfaces based on standard Internet protocols such as, for example, hypertext transfer protocol (HTTP), file transfer protocol (FTP), simple mail transfer protocol (SMTP), and/or other current or later developed protocols. Also, the messages may be in extensible markup language (XML), or other current or later developed languages. For some messages, XML (or another such language) may not be appropriate, such as, for example, binary data attachments.
The disclosed SOA security device management network may be implemented using standard techniques, such as, for example, one of the styles currently in use for Internet web services: simple object access protocol (SOAP) web services and representational state transfer (REST) web services. SOAP may serve to form a foundation layer of a web services stack, providing a basic messaging framework that more abstract layers can build on. In an SOAP embodiment of the disclosed security device management network, messages may be carried by SOAP and a description of the service may be in web services description language (WSDL). WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. SOAP messages may be exchanged over a variety of underlying protocols. SOAP may provide rich message exchange patterns ranging from traditional request-and-response to broadcasting and sophisticated message correlations.
In a REST embodiment of the disclosed security device management network, the SOA may be based on the concept of a “resource”. A resource may be anything that has a uniform resource identifier (URI). A resource may include zero or more representations. A REST web service may include interfaces limited to HTTP and messages in XML, and may provide encoding of simple messages with URL encoding.
The SOA components of the interface described above in relation to the control center 20 and the security device 22 may be constructed as a component of a new device or may be configured to be an upgrade to an existing control center or security device. An exemplary method of upgrading a security device is described below in relation to
In
The functional software modules (48-54), may be configured to perform or provide a security device service, such as, for example, capturing, transmitting, commanding, or otherwise communicating to the security device (through an interface module) in relation to a task or a group of tasks. Examples of functional modules include modules configured to provide functions including property management; hardware inventory; software inventory; software distribution; configuration management; remote hardware/network/software diagnostics; alarm, error, and warning event status notification, and escalation; data archiving, backup, purging and management; remote access to security device and command center assets; user and system authentication and authentication setup; auditing of some or all actions taken; auditing of some or all messages received; routing of command signals; remote configuration of individual security devices; threat image insertion management; scoring the accuracy of security device screeners; staged storage of images and data; interpreting and reporting security device performance data; remote viewing of images acquired by a security device; searching, displaying, and managing threat data over a distributed network; update of security device threat libraries; screener performance measurement and efficiency reporting; escalation and management of detected threats, and alarms; screener/supervisor communication; linking of passenger identification between remote databases; linking other security device scans of a specific article; scheduling update or software/download of files; remote control of screener/user functions; command and control of security device; gathering of computer/system/user diagnostic data; remote training of users; storing and queuing of information; configuration of the security device; report generation; remote desktop sharing; reporting security device utilization; reporting security device performance; communication of data, image, training, configuration, audit, database, and/or registry data to a central command center for centralized management, archiving, or temporary storage; capturing and reporting of security device operator keystroke information; remote restart monitoring; screener user tracking and time keeping; traveler identification information gathering, comparison to existing databases, and correlating to baggage; security encryption of data stream; and/or the like. It should be appreciated that the functional modules may perform a portion or all of a service or task, and that functional modules (48-54) performing a portion of a task may be accessed in a sequence determined, for example, by a script in the business rule engine 44 in order to provide a complete service. It should also be appreciated that the number of functional modules and translator modules shown in
The service oriented security device network interface module 38 may allow a common piece of software to control system access, security, and message routing. New functionality may be added with relative ease to the interface through plug-in modules and may be rapidly configured with changes to a script in the business rules engine to include new security devices, changes in monitoring requirements, or the like. These changes can be accomplished without a software release to the underlying software. In addition, an XML web services embodiment of the management network may provide messaging that may readily pass through firewalls. Each security device interface module 40 may provide for local storage of threat, training, maintenance, system management, configuration, image libraries, audit files, and/or the like.
As used herein, the phrase. “business rules” refers to rules or rulesets that may describe the operations, definitions and/or constraints that may apply to an organization in achieving its goals. Although the term “business rule” may be used throughout this description in order to aid understanding of those persons of ordinary skill in the art, it should be appreciated that the business rules may pertain to organizations other than businesses. For example, a business rule in the threat scanning machine context may state that a software update must be performed according to a certain schedule. These business rules may be used to help an organization achieve goals, communicate among organization members, communicate between the organization and interested third parties, demonstrate fulfillment of legal obligations, operate more efficiently, automate operations, perform analysis on current practices, and/or the like.
A business rules engine, (or business logic rules module or rule engine), may be a software system or module that provides rule management functions. The rule engine module may, among other functions, help to register, classify and manage rules; verify consistency of rules; infer some rules based on other rules; and relate some of these rules to other services or processes that may be affected or need to enforce one or more of the rules. Rules may also be used to detect situations automatically. For example, a threat scanning rule may be, for example, “notify a supervisor when the same passenger bag has activated an alarm at two different threat scanning machines in the same day.”
In an embodiment of the disclosed network management system, the business rules may change more frequently than the rest of the application code. The business rules engine (rule engine or inference engine) may be a pluggable software component that separates the business rules from the application code. This implementation may allow users of the system to modify the rules frequently while minimizing a need for intervention by technician skilled in software programming, and, hence, may allow the applications to be more adaptable with the dynamic rules. Data may typically be dynamic and may be operated upon by the logic and rules to obtain a desired result. The present invention provides for the dynamic rules in addition to processing dynamic data.
The rules may be production/inference rules or reaction rules. Production/inference rules may be used to answer questions and/or infer answers. For example, such a rule could answer the question: “should a particular passenger be allowed to board an aircraft?” The reactive rules may be used to detect and react to patterns of events occurring. For example, a reactive rule engine could be used to alert a supervisor when a certain pattern of threat alarms occurs among various threat scanning machines. A rule engine processing a production rule may answer questions when a user or application submits the question. A rule engine processing a reactive rule may react automatically, for example, when a certain rule is violated the service may sound an alarm.
A geographic location of a control center (or command center) may not be important as long as there is an internet connection to the network, because the service oriented management network may pass messages from one or more control centers to individual security device interfaces as shown in
Messages to and from the security device and control center may include composed of XML and/or include Simple Object Access Protocol (SOAP) format messages, which (before encryption) may be human readable and self-descriptive, providing messages that are easy to troubleshoot. Message translation problems between different operating systems and memory storage formats may be reduced or eliminated. XML tags and available Document Object Model (DOM) processing algorithms may allow for filtering and aggregation of message data.
The disclosed SOA management network may include XML web services to communicate to and from airport equipment, or other secure facility equipment. The XML web service messages may include hypertext transfer protocol (HTTP) (although other transport methods, such as E-Mail, HTTPS, or the like may also be used) to communicate. The web service protocol may be routed through firewalls, allowing encrypted information to be routed to/from any site having network access, such as, for example, internet access. The disclosed management system may provide near-real-time, two-way communications between security devices and control centers through polling and/or asynchronous communication.
An exemplary service oriented management network may include commercial off the shelf (COTS) business rules engines to implement the basic message routing, tracking, authentication, message delivery, and associated business rules. The use of a COTS business rules engine may allow developers to concentrate on the business object logic modules. The business rule engine may also use open source, or proprietary, scripting languages and web service objects, allowing multiple sourcing. New functionality can easily be added later as stand-alone objects with changes to the script. System administrators distribute only the new business objects and scripts, eliminating the expensive re-compile and re-release cycle of an entire application that may be traditionally associated with custom software. In addition, new services may be discovered using a discovery protocol, such as, for example, universal description discovery and integration (UDDI). New service discovery may be performed. automatically and integrated with little or no manual configuration.
The control center service oriented architecture interface software may include a business rules logic module 65, SOA messaging module 66, and may comprise one or more individually network addressable software modules (or objects). The software modules may include a threat management module 70, a remote management module 72, and/or a maintenance server module 74. The threat management module 70 may be configured to provide services associated with the scanning system itself. For example, these services may include: false alarm processing, confirmed weapons processing, machine utilization processing, machine performance processing, collecting information on scanned items, system identified possible threats and skip count, collecting (and/or archiving) images for all scanned items, system identified possible threats and skip count, logging actions taken, connecting to (i.e. sending and receiving data to/from) “parent” and/or “child” control centers. The threat management module 70 may include functions for providing an operator interface (at security device) to perform operator determination of threats such as weapons, explosives, or the like from remote location, set/clear threats, set/clear alarms, log actions taken, and/or the like.
The remote management module 72 may be configured to provide services for remotely managing the hardware platform that a system may be running on. For example, the remote management services may include: system time synchronization; rebooting the security device and/or sensing system; gathering and reporting security device status; supporting and providing backup and/or recovery capabilities at a control center and/or a security device; providing system administration functions (for example, managing system user IDs and passwords); providing ability to schedule tasks; logging actions taken; viewing system log files; connecting to (i.e., sending and/or receiving data to/from) “parent” and/or “child” control centers.
The maintenance server module 74 may be configured to provide services, such as, for example, including: receiving files (e.g., updated signature and/or code files); sending the updated files to the associated security devices for installation/update; providing configuration management (CM) of data deployed or scheduled for deployment; providing ability to schedule distribution; viewing download schedule; viewing versions deployed; viewing configuration management of stored files, or the like.
The exemplary service oriented security device management network 100 shown in
In operation, the exemplary command and control center 110 communicates with one or more threat scanning machines 106 via the network 112. The command and control center 110 may transmit data to the threat scanning machine, for example, operational software, authorized users and credentials, threat profiles, etc via service oriented messaging. The operational software may comprise any combination of software for the operation of the scanning system and/or software for the operation of the service oriented management network 100. The authorized users and credentials, which may include, for example, a list of user login names and passwords. Threat profiles may include data that the threat scanning machine uses to aid in identification of threats, for example the shape of potential threat items, and/or the physical properties of an item that may indicate a potential threat. However, it should be appreciated that the data transmitted from the command and control center 110 to the threat scanning machine 106 may be any data required for the management and operation of the threat scanning machine and could be used with equal effectiveness according to the present invention.
The exemplary threat scanning machine 106 communicates with the command and control center 110. The threat scanning machine may receive data from the command an control center 110 and/or may transmit data to the command and control center 110. The data that the threat scanning machine may transmit to the command and control center 110 may include, for example, performance data, requests for operator assistance, threat. detection data, and/or the like.
The exemplary command and control center 110 may communicate with one or more command and control centers 104 and/or 102. In the exemplary embodiment shown in
An exemplary. embodiment of the disclosed service oriented security device management network may provide centralized control and management of one or more services from disparate (different devices from different manufacturers) security devices. The services may include remote and system management services. For example, remote and system management services may include access security and auditing; property management and inventory; software inventory, distribution and configuration management; remote hardware/network/software diagnostics; event and status notification, and escalation; data archiving, backup, purging and management; remote access to security devices and command center assets; remote restart monitoring; and/or the like.
The service may also include equipment (security device) specific processing, which may include, for example remote configuration of individual security devices; threat image insertion for security devices; scoring the accuracy of security device operators; staged storage of images and data; interpreting and reporting security device performance data; remote viewing of security device acquired images; searching, displaying, and managing threat data over a distributed network; interfacing to existing security devices; updating of security device software and/or data libraries; screener performance measurement and efficiency reporting; escalation of detected threats; screener/supervisor communication; linking of passenger identification between remote databases; linking other security device scans of a specific article; and/or the like.
As discussed above, the disclosed centralized service oriented management system may use a service oriented architecture. A service oriented architecture may include XML, web services, and Internet transport (other transports such as E-Mail may also applicable). The disclosed service oriented management network may provide a capability for automatic discovery of new security devices and/or new services. The disclosed service oriented management network may provide include HTTPS or WS security to secure message routing and authentication. The disclosed service oriented management network may include “open source” business engines and scripting to implement routing, tracking, authentication, message delivery and associated business logic rules.
The disclosed service oriented management network may provide a capability for new and/or updated capabilities to be added with a change of a script. Further, the disclosed service oriented management network may provide a capability for additional security devices to be added to the system by providing a “plug-in” interface module. This “plug-in” interface module may include a separately programmed application, an agent that resides on the security device itself, or a plug in dynamically linked library (DLL) module that plugs into a generic interface module.
The disclosed service oriented management network may provide a capability for additional capabilities to be added to the server by adding base functionality as generic modules and changing the business engine script, which may be an “open source” script. In other words, the script may be accessible by a variety of appropriate developers for adding and/or updating functionality. The service oriented architecture of the disclosed system may also provide for the partitioning of a system into tiers. For example, the management system may be partitioned to include a presentation tier including graphical user interfaces, a business tier including business rules, a database tier including the data layer, and or the like. The partitioning may prevent software coupling, and may therefore increasing reuse and may decrease costs of software upgrades and modifications. Also, XML tags of a service oriented architecture services may be included to facilitate easy grouping, searching, and aggregiation of data of the raw data stream (permitting easy aggregation, filtering, and forwarding of data for a hierarchical management structure) and easy storage to databases.
An exemplary central management network structure for security devices may be implemented in a hierarchical structure as shown in
Each security device may have a security device interface assigned to it, or alternatively, multiple security devices may be serviced by one interface module. The security device interface may be configured to provide communications, security, connectivity, and control of the messages. The actual implementation of the interface may be a business rule engine that controls the routing of messages to internal plug in modules. In this implementation requests may be received from a control center and routed to the business engine. The business engine may be implemented in custom software or it may be implemented with a COTS Business Rule Engine with scripting to control individual message routing. COTS Business Rule Engines typically also include the communication and security functions to communicate over a web service interface (shown in the SOA Communication Module in the diagram). The business engine routes the message to the appropriate internal software module as shown in the following diagram.
These software modules may be implemented in service oriented architecture themselves and be based on web services, or may be software modules including agents, plug in dynamic link libraries (DLLs), applications, services, daemons, routines, and/or the like, that run on the security devices, or on other computers for the purpose of providing an interface between disparate security devices and centralized command and control centers. The interface module services may also be implemented as hard-coded modules within the interface itself.
The disclosed service oriented management network may be configured to provide one or more centralized management functions. A centralized management function may include, for example, property management; hardware inventory; software inventory; software distribution; configuration management; remote hardware/network/software diagnostics; alarm, error, and warning event status notification, and escalation; data archiving, backup, purging and management; remote access to security device and command center assets; user and system authentication and authentication setup; auditing of some or all actions taken; auditing of some or all messages received; routing of command signals; remote configuration of individual security devices; threat image insertion management; scoring the accuracy of security device screeners; staged storage of images and data; interpreting and reporting security device performance data; remote viewing of images acquired by a security device; searching, displaying, and managing threat data over a distributed network; update of security device threat libraries; screener performance measurement and efficiency reporting; escalation and management of detected threats, and alarms; screener/supervisor communication; linking of passenger identification between remote databases; linking other security device scans of a specific article; scheduling update or software/download of files; remote control of screener/user functions; command and control of security device; gathering of computer/system/user diagnostic data; remote training of users; storing and queuing of information; configuration of the security device; report generation; remote desktop sharing; reporting security device utilization; reporting security device performance; communication of data, image, training, configuration, audit, database, and/or registry data to a central command center for centralized management, archiving, or temporary storage; capturing and reporting of security device operator keystroke information; remote restart monitoring; screener user tracking and time keeping; traveler identification information gathering, comparison to existing databases, and correlating to baggage; security encryption of data stream.
Once the security device has been added to the network, an individually network addressable object is associated with the security device (step 206). This may be an object that resides in a control center or in a service security device network interface module. A business rule engine may provide a service by accessing the individually network addressable object based on a script (step 208). The security device may be monitored from a control center via the service provided by the business rule engine (step 210). Monitoring may include aspects such as, for example, communicating, managing, observing, updating, or the like between the control center and the security device.
An optional service discovery mechanism may be provided to allow a control center and/or a security device to obtain a listing of available services (step 212). Also, a compromised or defective security device and/or service may be detected and removed from the management network if appropriate (step 214). The removal may be accomplished automatically, manually, or through a combination of the above. Automatic removal may be performed when an object manager or rule engine detects a problem with a service and removes the service from a list of available services. Alternatively, the management system could propagate a message throughout the network indicating that a service has been removed. The method ends at step 216. All or a portion of the method may be repeated to provide management of a service oriented security device network. It should be appreciated that the disclosed systems and methods may be implemented in one or more modules comprising hardware, software, or a combination of the above. Further, the disclosed systems and methods may be contained in one module or processor, or may be distributed across more than one module and/or processor.
As shown in the above figures, the security device network management system and methods can be implemented on one or more of a general-purpose computer, a special-purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit element, an ASIC or other integrated circuit, a digital signal processor, a hardwired electronic or logic circuit such as a discrete element circuit, a programmed logic device such as a PLD, PLA, FPGA, PAL, a router or switch, or the like. In general, any component capable of implementing the functions described herein can be used to implement the system and methodology according to this invention.
Furthermore, the disclosed service oriented security device management network may be readily implemented in software using object or object-oriented software development environments that provide portable source code that can be used on a variety of computing platforms. Alternatively, the disclosed service oriented security device management network may be implemented partially or fully in hardware using standard logic circuits or a very large-scale integration (VLSI) design. Other hardware or software can be used to implement and supplement the systems in accordance with this invention depending on the speed and/or efficiency requirements of the system, the particular function, and/or a particular software or hardware system, microprocessor, networking, or microcomputer system being utilized. The system illustrated herein can readily be implemented in hardware and/or software using any known or later developed systems or structures, devices and/or software by those of ordinary skill in the applicable art from the functional description provided herein and with a general basic knowledge of the computer and network communication arts.
Moreover, the disclosed methods may be readily implemented in software executed on programmed general-purpose computer(s), a special purpose computer, a microprocessor, or the like. In these instances, the systems and methods of this invention can be implemented as a program such as JAVA® or a script embedded on a personal computer, as a resource residing on a server or graphics workstation, as a routine embedded in a dedicated network system, or the like. The system can also be implemented by physically incorporating the system and method into a software and/or hardware system, such as the hardware and software systems of a network.
It is, therefore, apparent that there is provided in accordance with the present disclosure, a service oriented security device management network. While this invention has been described in conjunction with a number of embodiments, it is evident that many alternatives, modifications and variations would be or are apparent to those of ordinary skill in the applicable arts. Accordingly, applicants intend to embrace all such alternatives, modifications, equivalents and variations that are within the spirit and scope of this invention.
The present application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 60/688,725, entitled “Centralized Security Equipment Management Utilizing a Service Oriented Architecture (SOA)”, filed Jun. 9, 2005, and U.S. Provisional Application No. 60/688,724, entitled “Information Routing In A Distributed Environment”, filed Jun. 9, 2005 both of which are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60688725 | Jun 2005 | US | |
| 60688724 | Jun 2005 | US |
