Patent Publication Number: US-8122498-B1

Title: Combined multiple-application alert system and method

Description:
FIELD OF THE INVENTION 
     The present invention relates to application alerting, and more particularly to alerting users of various computing environment situations. 
     BACKGROUND OF THE INVENTION 
     Security threats have evolved significantly over the past years. Advanced hybrid threats, have been designed to attack systems on multiple fronts, sometimes searching for vulnerabilities until one is found. New threats also attempt to attack security technology itself. 
     Traditional consumer security software suites often included a plurality of various applications such as an anti-virus application, a firewall application, anti-spam applications, content filtering application, etc. Such applications existed in such software suites as a simple bundle. In other words, each product secured its own domain in a vacuum. As such, various security events were acted upon separately by each of the applications. 
     One of the actions taken by the aforementioned applications includes an alert. Prior Art  FIG. 1  illustrates one exemplary prior art system  10  where a plurality of applications separately generate a plurality of separate alerts. As shown, a first application  12  and a second application  14  are included in an application suite  16 . In such prior art system  10 , the first application  12  is capable of generating a first alert  13 , while the second application  14  is capable of generating a second alert  15 , as so on. 
     As is readily apparent, such separate alerting can be quite cumbersome, inefficient, and even bothersome to a user. This is especially the case where each application generates a separate alert for a single event; and further in an environment where a large number of applications exist. 
     There is thus a need for a more effective alerting technique in an environment including a plurality of applications. 
     DISCLOSURE OF THE INVENTION 
     A system, method and computer program product are provided for combined alerting. Initially, an event is identified. First information relating to a first response to the event associated with a first application is received. Further received is second information relating to a second response to the event associated with a second application. In response thereto, a single alert is displayed including the first information and the second information. 
     In one embodiment, the single alert may include a description of the event. The first information may identify a proposed user action relating to the first application based on the event. Similar, the second information may identify a proposed user action relating to the second application based on the event. Moreover, the foregoing information may relate to any automatic responses to the event by the applications. 
     In another embodiment, components of the first information and the second information may be ranked. In such embodiment, the components of the first information and the second information may be conditionally included in the single alert based on the ranking or, in other words, priority. 
     In still another embodiment, the single alert may include a window automatically displayed on a front most window of a user interface. Further, the single alert may include a textual description of the first information and the second information. 
     As an option, the event May include a security event. Still yet, the first application and the second application may include applications such as an anti-virus application, a firewall application, a content filtering application, an anti-spam application, and/or a utilities application. 
     In still yet another embodiment, the receiving and displaying operations may be carried out utilizing an interface. Such interface may include an application program interface. Still yet, the interface may further include a graphical user interface for allowing access to the first application and the second application, and/or provide a status for the same. 
     Thus, a single alert object is provided including a first portion reflecting a first response to an event associated with a first application. Associated therewith is a second portion displayed simultaneously with the first portion for reflecting a second response to the event associated with a second application. 
     Another system, method and computer program product are provided for combined alerting. Initially, an event is identified after which first information and second information are received, similar to above. In the present embodiment, however, the first information corresponds to a first proposed user action in response to the event associated with a first application, and the second information corresponds to a second proposed user action in response to the event associated with a second application. To this end, a single alert is displayed including the first information and the second information. 
     As an option, the single alert may include a plurality of selection icons capable of being selected by a user for executing at least one of the first proposed user action and the second proposed user action. Such selection icons may include links. Moreover, the selection icons may include hyperlinks. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Prior Art  FIG. 1  illustrates one exemplary prior art system. 
         FIG. 1A  illustrates a network architecture, in accordance with one embodiment. 
         FIG. 2  shows a representative hardware environment that may be associated with the data server computers and/or end user computers of  FIG. 1A , in accordance with one embodiment. 
         FIG. 3  illustrates a system adapted for interfacing a plurality of applications, in accordance with one embodiment. 
         FIG. 3A  shows an exemplary graphical user interface associated with the interface of  FIG. 3 . 
         FIG. 4  illustrates a plurality of libraries adapted for facilitating the interfacing of a plurality of applications, in accordance with one embodiment. 
         FIG. 5  illustrates a method for interfacing a plurality of applications, in accordance with one embodiment. 
         FIG. 6  illustrates an exemplary manner in which production and consumption events are correlated according to the method of  FIG. 5  and in the context of the libraries of  FIG. 4 . 
         FIG. 7  illustrates an exemplary alert that may be generated according to the method of  FIG. 5  and in the context of the libraries and correlation of  FIGS. 4 and 6 , respectively. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       FIG. 1A  illustrates a network architecture  100 , in accordance with one embodiment. As shown, a plurality of networks  102  is provided. In the context of the present network architecture  100 , the networks  102  may each take any form including, but not limited to a local area network (LAN), a wide area network (WAN) such as the Internet, etc. 
     Coupled to the networks  102  are data server computers  104  which are capable of communicating over the networks  102 . Also coupled to the networks  102  and the data server computers  104  is a plurality of end user computers  106 . In order to facilitate communication among the networks  102 , at least one gateway or router  108  is optionally coupled therebetween. It should be noted that each of the foregoing network devices as well as any other unillustrated devices may be interconnected by way of a plurality of network segments. 
       FIG. 2  shows a representative hardware environment that may be associated with the data server computers  104  and/or end user computers  106  of  FIG. 1A , in accordance with one embodiment. Such figure illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit  210 , such as a microprocessor, and a number of other units interconnected via a system bus  212 . 
     The workstation shown in  FIG. 2  includes a Random Access Memory (RAM)  214 , Read Only Memory (ROM)  216 , an I/O adapter  218  for connecting peripheral devices such as disk storage units  220  to the bus  212 , a user interface adapter  222  for connecting a keyboard  224 , a mouse  226 , a speaker  228 , a microphone  232 , and/or other user interface devices such as a touch screen (not shown) to the bus  212 , communication adapter  234  for connecting the workstation to a communication network  235  (e.g., a data processing network) and a display adapter  236  for connecting the bus  212  to a display device  238 . 
     The workstation may have resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. It will be appreciated that a preferred embodiment may also be implemented on platforms and operating systems other than those mentioned. A preferred embodiment may be written using JAVA, C, and/or C++ language, or other programming languages, along with an object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. 
     Our course, the various embodiments set forth herein may be implemented utilizing hardware, software, or any desired combination thereof. For that matter, any type of logic may be utilized which is capable of implementing the various functionality set forth herein. 
       FIG. 3  illustrates a system  300  adapted for interfacing a plurality of applications, in accordance with one embodiment. As an option, the present system  300  may be implemented in the context of the architecture of  FIGS. 1 and 2 . Of course, the system  300  may be implemented in any desired context. 
     As shown, included is a plurality of applications  301 . In the context of the present description, such applications  301  may include any type of application program or computer code. For example, the applications  301  may optionally be security related. Of course, the applications  301  may be related to any other aspects such as business, maintenance, entertainment, etc. 
     In the security context, the applications  301  may include an anti-virus application  302 , a firewall application  304 , a content filtering application  308 , an anti-spam application  306 , and/or any other related application  310  (i.e. a utilities application, etc.). 
     In use, the anti-virus application  302  may be capable of scanning for viruses or other malicious code by comparing virus signature files with data located in memory or being transmitted via a network; and taking any appropriate response (i.e. quarantine data, delete data, clean data, alert user, etc.). Moreover, the firewall application  304  may be capable of blocking or alerting a user of accesses to a computer or network based on a predetermined set of rules or policies. 
     Still yet, the content filtering application  308  may be capable of protecting personal information on a computer and preventing the same from being shared. Still yet, the content filtering application  308  may be capable of preventing certain users from accessing predetermined content on a network such as the Internet. Moreover, the anti-spam application  306  may be capable of filtering electronic mail messages based on a predetermined rule set to prevent the receipt (or delivery) of unwanted e-mail. 
     It should be noted that each of the applications may be capable of reporting information back to the interface. For example, the firewall application may report hacker attacks in the form of a consumption event. In a similar manner, the anti-spam application may be able to report spam, viruses, etc. 
     As mentioned earlier, any other related application  310  may be included in the group of applications  301 . For example, a utilities application may be included for executing various maintenance tasks associated with a computer (i.e. cleaning files, optimizing memory, etc.). 
     Further provided in combination with the applications  301  of the system  300  is an interface  312 . In use, such interface  312  may include any specific method, technique or protocol by which an application program can communicate with an operating system or another application. In one embodiment, such interface  312  may include an application program interface. 
     In use, the interface  312  is capable of receiving a signal that an event has been detected or responded to by a first one of the applications  301 . Thereafter, a second one of the applications  301  is prompted to respond to the event utilizing the interface  312 . 
     As an option, the interface  312  may further include a graphical user interface for allowing access to the various applications  301 . Such graphical user interface may further be used for indicating a status of the different applications  301 . 
     It should be noted that the foregoing technique may be accomplished in any desired manner. Additional information regarding specific optional features will be set forth in greater detail during reference to the following figures. 
       FIG. 3A  illustrates an exemplary graphical user interface  350  associated with the interface  312  of  FIG. 3 . To allow access to each of the applications via the single graphical user interface  350 , the graphical user interface  350  may include a home page  362  and a plurality of selection icons  364  for allowing access to a plurality of windows (not shown) associated with each of the applications. Optionally, such windows may each include access to functionality associated with the corresponding one of the related applications. 
     In use, the home page  362  may be adapted for displaying a visual indication as to the status of each of the applications, along with various other information. For example, a security index  366  may be provided for indicating a level of risk associated with various aspects (i.e. security aspects) of a computer or networking environment. Further included is general information and alerts displayed in separate frames  368 . As will soon become apparent, such alerts may be pushed from a server and further provide various options to a user. Still yet, the home page  362  may include an update icon  370 , additional information icon  372 , a support icon  374 , and a help icon  376 . 
     To convey the status of each of the applications, the home page  362  of the single graphical user interface  350  may include a list  337  of a plurality of applications  354 . Still yet, the single graphical user interface  350  may include a plurality of status indicators  356  adjacent to each of the applications  354  in the list  337 . 
     Each status indicator  356  may indicate whether the corresponding the application is installed. Moreover, each status indicator  356  may indicate whether the corresponding the application is enabled. Still yet, each status indicator  356  may indicate whether a subscription associated with the corresponding the application is expired. While this is shown to be accomplished using text, it should be noted that such status may be conveyed in any desired manner. 
     As an option, each status indicator  356  may be color coded. For example, an icon may be included as a status indicator  356 , as shown. In use, such icon may exhibit a red color to reflect the fact that an application is not installed, disabled or expired; and a green color may indicate that the application is installed and running. 
     Of course, the status indicator  356  may include any combination of textual, graphic, numeric visuals that indicates a status of the applications  354 . Moreover, such status may include installed, not installed, expired, enabled, disabled, or any other conceivable state of the applications. 
       FIG. 4  illustrates a plurality of libraries  400  adapted for facilitating the interfacing of a plurality of applications, in accordance with one embodiment. As an option, the libraries  400  may be implemented in the context of the system  300  of  FIG. 3 . Of course, the libraries  400  may be implemented in any desired context. 
     As shown, each of a plurality of applications may have a library associated therewith. In the context of  FIG. 4 , such libraries may include an anti-virus application library  402  associated with an anti-virus application such as that of  FIG. 3 , a firewall application library  404  associated with a firewall application such as that of  FIG. 3 , a content filtering application library  408  associated with a content filtering application such as that of  FIG. 3 , and an anti-spam application library  406  associated with an anti-spam application such as that of  FIG. 3 . 
     In particular, each of the libraries  400  may include a list of production events  410  and a plurality of consumption events  412 . The production events  410  may include any responses generated by the application associated with the particular library. Still yet, the consumption events  412  may include any responses which the application is capable of receiving from other applications, and responding accordingly. It should be noted that the specific production events  410  and consumption events  412  listed in  FIG. 4  are set forth for illustrative purposes only, and should not be construed as limiting in any manner. 
     In use, each of the libraries  400  may, in one embodiment, be installed on a computer in conjunction with the associated application. Moreover, each of the applications may be installed separately as desired. Of course, per the desires of the user, the libraries  400  may be installed at any time, and the applications may be installed in any combination. 
     In any case, logic associated with the aforementioned interface may utilize the foregoing libraries  400  to facilitate the appropriate interaction of the applications. More information regarding exemplary details as to the manner in which this is accomplished will be set forth hereinafter in greater detail. 
     It should be noted that the various events of the libraries  400  may be associated with applications from different companies, thus making the present technique vendor-independent. If an application developer feels that an action taken by their application may be interesting to other applications, the developer may register the action with the logic associated with the interface using the libraries  400 . As an option, restrictions may be put into place regarding events that are registered. See, for example, Table 1 which includes a plurality of exemplary restrictions or requirements as to including the production events  410  in the appropriate libraries  400 . Of course, such restrictions are strictly optional. 
     
       
         
           
               
               
             
               
                 TABLE 1 
               
               
                   
               
             
            
               
                   
                 Application can perform an action 
               
               
                   
                 The action is non-trivial and results in a “significant 
               
               
                   
                 change” to the state of the user computer 
               
               
                   
                 A message is generated and transmitted to the interface 
               
               
                   
                 when this action is performed 
               
               
                   
                 The feature is supported for the foreseeable future 
               
               
                   
               
            
           
         
       
     
     As a further option, certain fields may be included in the libraries  400  for each of the production events  410 . See Table 2, for example. 
     
       
         
           
               
               
             
               
                 TABLE 2 
               
               
                   
               
             
            
               
                   
                 Product Source 
               
               
                   
                 Event Name (i.e. plain English, concise description, etc.) 
               
               
                   
                 Event Source (i.e. stateful response, user-action response, etc.) 
               
               
                   
                 Event Severity 
               
               
                   
                 Event Description (i.e. plain English description which 
               
               
                   
                 MAY be displayed to end-user, etc.) 
               
               
                   
                 Event Parameters (i.e. XML based schema for describing 
               
               
                   
                 additional information possibly contained in event, etc.) 
               
               
                   
               
            
           
         
       
     
     Table 2A illustrates an exemplary production event associated with an anti-virus application. 
     
       
         
           
               
               
             
               
                 TABLE 2A 
               
               
                   
               
             
            
               
                   
                 Product Source: Anti-virus application 
               
               
                   
                 Event Name: “Infected File Detected” 
               
               
                   
                 Event Source: Stateful Response 
               
               
                   
                 Event Severity: High Severity 
               
               
                   
                 Event Description: “An anti-virus application has found an 
               
               
                   
                 infected file on your computer.” 
               
               
                   
                 Event Parameters: N/A 
               
               
                   
                 Filename: Path of the Infected File 
               
               
                   
                 InfectionName: AVERT name of virus/Trojan found 
               
               
                   
                 InfectionType: Trojan, Virus, Script-Virus, etc. 
               
               
                   
               
            
           
         
       
     
     Table 3 includes a plurality of exemplary restrictions or requirements as to including consumption events  412  in the appropriate libraries  400 . Again, such restrictions are strictly optional. 
     
       
         
           
               
               
             
               
                 TABLE 3 
               
               
                   
               
             
            
               
                   
                 The additional functionality augments a consumption event 
               
               
                   
                 There is a desire to change internal product settings in 
               
               
                   
                 response to a consumption event 
               
               
                   
               
            
           
         
       
     
     Similar to the production events  410 , certain fields may be included in the libraries  400  for each of the consumption events  410 . See Table 4, for example. 
     
       
         
           
               
               
             
               
                 TABLE 4 
               
               
                   
               
             
            
               
                   
                 Consuming Product 
               
               
                   
                 Response Name 
               
               
                   
                 Response Description 
               
               
                   
                 Response Default Action 
               
               
                   
                 Response Additional Actions 
               
               
                   
               
            
           
         
       
     
     Table 4A illustrates an exemplary firewall application consumption event associated with the production event set forth in Table 2A. 
     
       
         
           
               
             
               
                 TABLE 4A 
               
               
                   
               
             
            
               
                 Consuming Product: Firewall application 
               
               
                 Response Name: “Infected Application Blocked” 
               
               
                 Response Description: “A firewall application will block the infected file  
               
               
                 from accessing the Internet and optionally report the file to  
               
               
                 HackerWatch.org” 
               
               
                 Response Default Action: Block 
               
               
                 Response Additional Actions: Ignore, Report to HackerWatch.org 
               
               
                   
               
            
           
         
       
     
     It should be noted that the libraries  400  may be updated as desired. This may be accomplished utilizing a server-client communication, etc. 
       FIG. 5  illustrates a method  500  for interfacing a plurality of applications, in accordance with one embodiment. As an option, the method  500  may be implemented in the context of the system and libraries of  FIGS. 3 and 4 . Of course, the method  500  may be implemented in any desired context. 
     Initially, an event is detected with a first application. See operation  502 . Such event may include any event on a computer or network associated with the application. Moreover, the first application may include any desired application. See, for example, the applications of  FIG. 3 . In the context of security applications, the event may include a security event. Such security event may include any event associated with the computer or network that may detrimentally affect the same in any manner. 
     Next, in operation  504 , a first response to the event is processed utilizing the first application. Such processing may encompass any objective associated with the particular application. Next, the event and the first response are identified to the interface utilizing the first application. It should be noted that this or any type of signal may be sent to the interface for prompting a response by another application(s). 
     After such first response is identified in the first library, it is determined whether such production event correlates with a consumption event of another library associated with any other applications. Note operation  506 . 
     If such a correlation is made, the appropriate consumption event or related signal is sent to the application(s). Note, for example, operations  508  and  510 . Such actions, in turn, prompt further responses from the other application(s). Of course, such responses may be reported back to the interface for generating additional consumption events, and so on. 
     It should be noted that the interface may prompt responses from the other application(s) in any desired manner. Just by way of example, the libraries may be used during a registration process to configure the logic governing the interface. Moreover, the logic may be pre-configured and installed with a suite of applications. Of course, any technique capable of prompting responses from the other application(s) may be used. 
     When all of the appropriate responses have occurred, an alert may be generated in operation  512 . Such alerting may be accomplished in any desired manner. For example, the first information may be received relating to the first response to the event associated with the first application. Moreover, second information may be received relating to a second response to the event associated with a second application, and so on. Of course, third and fourth information may be received to reflect the number of applications that have responded to a consumption event in the aforementioned manner. 
     With this information in hand, a single alert may be displayed including the first information and the second information. Such single alert may further include a window automatically displayed on a front most window of a user interface. 
     In various embodiments, the information relating to the responses to the event may include any data relevant to such responses. Just by way of example, the information may include a description of the event, which may be included in the single alert. Moreover, the first information may identify a proposed user action relating to the first application based on the event. Similarly, the second information may identify a proposed user action relating to the second application based on the event. Of course, the information may simply describe the automatic responses to the event by the applications. It should be noted that any combination of the foregoing information or any other information may be included per the desires of the user. 
     Since the amount of information reflected in the single alert may become cumbersome, a ranking may be associated with the first information and the second information. In such embodiment, the single alert may conditionally include the first information and the second information based on the ranking or any other threshold. To this end, only a predetermined amount of information is included in the single alert. Moreover, any type of medium may be employed for transmitting the alert (i.e. Windows® Pop-Up, .NET alert, e-mail, pager, cell phone, etc. 
       FIG. 6  illustrates an exemplary manner  600  in which production and consumption events are correlated according to the method  500  of  FIG. 5  and in the context of the libraries  400  of  FIG. 4 . It should be noted that such correlation logic is set forth for illustrative purposes only, and should not be construed as limiting in any manner. 
     As shown, a plurality of production events  602  is shown to be associated with various applications  604 . Such production events  602  are, in turn, correlated with various consumption events  606 . 
     As shown, a firewall application may consume a “New Infected File Detected” production event from the anti-virus application, and, as consumption events, automatically add the infected file to a blocked Internet application list and send a hash of the application to a hacker tracking website (i.e. HackerWatch.org). Still yet, the anti-virus application may consume a “Trojan application blocked” production event from the firewall application, and automatically perform a scan of the user&#39;s hard drive. Moreover, a content filtering application may consume a “New Internet Protocol Address (IP) Trusted” production event from the firewall application, and automatically add the trusted IP to its trusted site list. Still other examples are set forth in  FIG. 6  for illustrative purposes. 
       FIG. 7  illustrates an exemplary alert  700  that may be generated according to the method  500  of  FIG. 5  and in the context of the libraries  400  and correlation  600  of  FIGS. 4 and 6 , respectively. It should be noted, of course, that such alert  700  is set forth for illustrative purposes only, and should not be construed as limiting in any manner. 
     As shown, the alert  700  may include the various information related to the event and the responses to the event by various applications. For example, a first portion  702  of the alert  700  may relate to the first application (i.e. a firewall application). Similarly, a second portion  704  of the alert  700  may relate to the second application (i.e. an anti-virus application). Specifically, the first portion  702  of the alert  700  may relate to the response of the first application and the second portion  704  of the alert  700  may relate to the response of the second application. Optionally, the first portion  702  and the second portion  704  of the alert  700  may be displayed to the user simultaneously via a single alert. 
     Again, the information included with the alert  700  may include a description of the event, a proposed user action relating to an application based on the event, and/or a description of the response to the event by an application. It should be noted that any combination of the foregoing information or any other information may be included per the desires of the user. 
     As an option, the single alert  700  may include a plurality of selection icons  706  capable of being selected by a user for executing at least one of the proposed user actions, if any. Such selection icons may include links (i.e. hyperlinks, etc.) for connecting to a server or the like for carrying out the proposed user actions. As shown in  FIG. 7 , such actions may include an option to find out more information about the event, launch an application, continuing by doing nothing, etc. 
     Such response options may be carried out by the selection thereof by a user utilizing a mouse-click or the like. While this may be accomplished in any desired manner, one exemplary method may include the technique set forth in U.S. Pat. No. 6,266,774 entitled “Method and system for securing, managing or optimizing a personal computer,” which is incorporated herein by reference in its entirety. 
     In one embodiment, the single alert  700  may be pushed to a plurality of computers from a server, as opposed to a reaction to an application response on a computer. In the context of the present description, such pushing may include any technique where the server initiates the delivery of the alert  700  to the user computers. It should be noted that the foregoing pushing may be accomplished in a variety of foreseeable ways. Just by way of example, the alert  700  pushed from the server to the user computers may actually come as the result of a programmed request from the user computers. That is, a client program may be used to initiate such pushed alerts  700 . Still yet, the pushing may include a simple broadcasting of the alert  700 . In this case, the alert  700  may be pushed to the user computers that have access to a particular channel or frequency. Broadcast may (but not always) involve a continuous flow of information. 
     The foregoing embodiments may thus be useful in a variety of contexts. Just by way of example, if a content filtering application detected someone talking inappropriately to a child, the chat may be blocked and logged. This, in turn, may be reported to the interface which would broadcast this information to the other applications present on the user&#39;s computer. An anti-spam application, for example, may obtain the information on the person propositioning the child over instant messenger and ensure that all e-mails from that person are blocked and logged. Personal firewall may, in turn, add the associated IP address to a banned list. Still yet, a visual trace may then trace the IP to the location of the service provider. As such, the embodiment of the present example may enable the parent to know who, what, when and how information, and would also have all the information available for a report for the authorities. 
     While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. For example, any of the network elements may employ any of the desired functionality set forth hereinabove. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.