Abstract:
Information is collected regarding an event in a computer system that includes a group of client application caches that each temporarily store information associated with one of a group of client applications. A set of rules is stored at one or more of the group of client application caches. Each rule triggers the event in another one of the group of client application caches in response to receipt of a message from a client application associated with the respective client application cache. Another message directed to another specified client application cache is generated for each rule that matches a first received message at a first client application cache. The generated message directs the other specified client application cache to collect and cache specified information from a server associated with the other specified client application cache.

Description:
BACKGROUND 
     The invention relates to automated services, and especially to the automated collection of data and information for personal information managers, personal data assistants (PIM and PDAs), laptops and any type of electronic device that individuals might use in a mobile environment for the containment of personal and business information. 
     Many of today&#39;s organizations are going global, meaning that employees located in one geography might need to interact with their counterparts and customers in another remote geography. In a recent survey conducted in the US, it was found that, last year, American “road warriors” (business people) took 207 million business trips, spending an average of about three and a half days away from the office per trip. (&lt;&lt;media3pub.com/usbank/articles/road_warrior.html&gt;&gt;). Because of this shifting paradigm, employees are often working at remote locations with limited or no real-time access to needed corporate or personal information. 
     One of the big inhibitors to productivity in this environment is the inability to access needed information to accomplish short term tasks, like finding the right person in a back-office to answer a question, or perhaps reviewing the purchase history of a customer before tomorrow&#39;s meeting. Even though many organizations have their own corporate directory holding employee and customer information, they need a way to always have access at their mobile devices to the latest and authentic information available, along with important related business information. 
     What is needed is a way to ensure that important information is available in one&#39;s laptop or mobile device, regardless of where the user might be. 
     The above problem statement brings forth a number of issues, including the size of corporate databases that encompass multimedia elements, such as graphics, pictures, maps, even video presentations. Important business information might also include information found in customer relations management (CRM) systems, social link networks, blogs, etc. 
     According to the Wikipedia website (&lt;&lt;wikipedia.org/&gt;&gt;), a mashup is a website or web application that uses content from more than one source to create a completely new service. The origin of the term “mashup” comes from the music industry where a DJ mixes a vocal track from one song with the instrumental track of another. Recently, mashups have started to appear in non-browser based applications like instant messaging, where plug-ins are used to produce compositions of information for end users, like showing directory and social networking data in a chat window. The focus of mashups at the present has been on producing real time compositions for an end user. 
     There is a long history of caching techniques for specific application domains, such as for relational databases, email systems, and for edge servers in the web. Some of these cache techniques have intelligent features that preload elements of the associated application domains. For example, one known email application fetches copies of email messages when their titles appear on screen in representation of the in-box; a known database application prefetches related table subsets when some table rows are retrieved, if there has been a history of the database application using a query to “join” these related table subsets. 
     There have also been attempts to replace multiple application access to remote data in mobile devices with a specialized data access client, a matching server extension and an optional middle tier. In this arrangement rules were used to allow those files that were most likely to be needed, based on recent history, to be copied to a mobile device before the device disconnected from a network. 
     BRIEF SUMMARY 
     The invention provides a data mashup on a user&#39;s device. The preferred and probably most useful device is a mobile one. However, there is no reason to so limit the invention. When the user makes an application data entry, such as a calendar entry for a meeting with a customer, the mashup uses rules and data patterns that have been defined by the user to query other relevant information sources to collect related information about the customer or the meeting, and to cache the collected information on the device for the user. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
       A better understanding of the invention will be had when the following detailed description is read in conjunction with the drawings in which: 
         FIG. 1  is a block diagram of an illustrative cache mashup system, including client applications, application caches, application servers, and a message queuing system for communications between these system components; 
         FIG. 2  shows illustrative user-defined rules that govern the operation of the system in response to user entries into client applications, such as calendars, browsers and similar client applications; 
         FIG. 3  shows one illustrative format of messages that are passed in the system of  FIG. 1 ; 
         FIG. 4  is a simplified and illustrative block diagram of the system of  FIG. 2  to illustrate operations of the invention in response to the entry of a meeting into a client calendar application; 
         FIG. 5  shows illustrative process steps performed at a client application, such as a calendar client application; 
         FIG. 6  shows illustrative process steps performed at an application cache, such as a calendar cache application according to the invention; and 
         FIG. 7  is a block diagram of a laptop computer or other illustrative device suitable for practicing the invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows a block diagram of a client computer with a number of Illustrative software applications, which are be used to describe the invention. For example, client computer  100  contains an address book  104 , a calendar application  106 , a web browser  108  and a customer relations manager (CRM)  110 . 
     These applications are logically connected to a cache mashup application  102  by message queues  112 ,  114 ,  116  and  118 , which in turn are respectively connected to caches  128 ,  130 ,  132  and  134  that are respectively associated with the mentioned client applications. The message queues are used to pass messages between the client applications and the mashup and can be implemented with IBM&#39;s Message Queuing system. Each of the caches is also, by way of example, connected to a backend server that services the respective client application. For example, address book  104  is associated with a backend address server  136 , Calendar  106  is associated with backend calendar server  138 , and so on for browser  108  and web server  140 , and CRM  110  and server  142 . Each of the mashup caches is also illustratively associated with a rules and pattern (R&amp;P) module. For example, address cache  128  is associated with R&amp;P  120 ; calendar cache  130  is associated with R&amp;P  122  and so on for R&amp;P  124  and R&amp;P  126  for the browser and CRM caches. These R&amp;P modules contain information entered by a user of the client computer to control the actions that are taken when the user enters or deletes information in a backend server via one of the client applications. 
       FIG. 2  shows one illustrative example of a set of rules that a user might enter into the R&amp;P modules. The focus is primarily on the calendar application  106  and calendar cache  130 . The example chosen to illustrate the invention is one in which a user wishes a calendar entry for a customer meeting to initiate a series of actions that automatically collects customer information likely to be useful for the user to prepare for the meeting. There is no intention to limit the invention to this example. It is merely illustrative of the types of actions that a user might find useful. Thus, in R&amp;P  122 , the user has entered rule RI that instructs the calendar cache  130  that for every new scheduled customer meeting with Sam, initiate actions to the other client applications so that the mashup collects the email address of Sam and employer company name from the address server. Rule R 2  of  122  instructs the mashup to fetch some recent news articles from a designated news source, such as the Wall Street Journal, and cache them at browser cache  132 . Rule R 3  instructs the mashup that for a customer meeting with Sam, fetch Sam&#39;s most favorite web bookmarks. For R 3 , the rule would contain a social networking URL, such as &lt;&lt;del.icio.us&gt;&gt; to query for Sam&#39;s bookmarks. 
     With reference to  FIG. 4 , which is a simplified and re-arranged system view to aid this description, as a result of a user entering at  400  a calendar entry for a customer meeting with Sam, a meeting entry is made into Sam&#39;s calendar at the calendar server  138  via a message sent from the calendar client  106  via communication link  402 , queue  112 , calendar cache  130  and links  404  and  405 . This user entered message contains a COUNT field set to the integer value one (1) to prevent the client application from discarding the message for a reason that will become apparent from the following discussion. As that calendar entry is being made, calendar cache  130  also queries R&amp;P  122  to determine which, if any, user rules might be triggered by the contents of the calendar message. Since this is a customer meeting with Sam, rules R!, R 2 , R 3  and R 4  are triggered. As a result of R 1 , calendar cache  130  queues a message in queue  114  via logical connection  406  to the queue  112  that serves the address book cache  104  to fetch Sam&#39;s company address and his email address from the address server  136 . When this message arrives at the address cache  128 , it triggers rule R 2  to fetch and cache the desired information. Of course, it is assumed for this example, that this information for Sam has previously been entered into the address server by the user.  FIG. 3  shows an example of what this message might look like. In  FIG. 3 , TYPE is set to ADDR, meaning fetch information from the address server. HANDLE is set to Sam to identify the party whose address information is desired. TARGET DATE is set to the date of the meeting; PATTERN might be set to other information specific to the type of message being generated, but is empty for this message in this preferred embodiment; COUNT is set to an arbitrary integer greater than zero to prevent the looping of messages. This will be explained in more detail later. The purpose of this message to the address book cache is to store Sam&#39;s address information from the address server  136  into the user&#39;s address cache  128  The TARGET DATE prevents the stored address information from being deleted from the address cache before it is needed. 
     The original meeting entry message at calendar cache  130  also triggers rules R 2 , R 3  and R 4  of the calendar R&amp;P  122 . Rule R 2  results in the generation and queuing in queue  114  of a message to the browser cache  132  via logical link  408  and connection  414  to fetch, in this example, recent news articles regarding the company that employs Sam. The HANDLE of rule R 2  will contain the company name taken from R&amp;P  122 . It is also possible to fetch this information from the address book if desired, but this requires a slightly more complicated application at the calendar cache  130 . For this message, rule R 2  of R&amp;P  122  contains a user-entered URL of a desired news source for Sam&#39;s company and is stored in PATTERN of the generated message to browser application  108 . This might be, for example, &lt;&lt;.wsj.com&gt;&gt; identifying the Wall Street Journal web site. Rule R 2  could also contain a number, say 10, to limit the number of news articles that will be retrieved, but in this simplified embodiment, the number is placed in the rules of the other client applications. This message triggers rule R 2  in the browser R&amp;P  124 . 
     Rule R 3  also results in a second message to the browser cache  132  to fetch Sam&#39;s favorite bookmarks. This message in this example is related to social networking web sites to fetch and store in the user&#39;s browser cache  132  a number of items that illustrate the likes, or perhaps dislikes, of Sam. In this example, assuming that Sam participates in social networking, Sam&#39;s favorite Web bookmarks are used for this purpose. TYPE of the message is set to BROWSER to identify the browser cache, HANDLE is set to &lt;&lt;del.icio.us/sam&gt;&gt; to identify the location of Sam&#39;s stored favorite bookmarks. This particular site is only an example of course. There can be any number of social networking web sites at any given time that a user might wish to use. This message triggers rule R 1  in the browser R&amp;P  124 . 
     Rule R 4  at calendar cache R&amp;P  122  triggers a message to queue  112  to the CRM cache  134  via logical link  410  and connection  416 . The purpose of this message is to store information about Sam into CRM cache  134  from the user&#39;s internal CRM server  142 . TYPE is set to CRM and HANDLE is set to Sam. Again, COUNT is set to some arbitrary integer greater than zero. This message triggers rule R 2  of the CRM R&amp;P  126 . 
       FIG. 5  shows an illustrative flowchart of the steps taken to implement the invention at the calendar client application. When a user enters a new calendar entry, step  502  at the calendar application generates and sends an appropriate message to the calendar cache to initiate operations as above described. 
       FIG. 6  shows illustrative steps at the calendar cache  130  that are performed in response to the receipt of a message from the calendar client. Step  602  retrieves the integer in the COUNT field of the incoming message, decrements the value by 1 and stores the resulting integer back into the COUNT field. Step  604  next examines the value of the decremented integer. If it is less than zero (0), step  606  discards the message. This prevents incoming requests from generating an infinite number of messages as a result of the triggering of other rules that might be stored at the various cache R&amp;P&#39;s. If the value of the decremented COUNT is not negative, step  608  determines if this is a customer meeting entry. If not, calendar cache  130  performs other appropriate steps in this example, such as merely sending the entry onto the backend calendar server  138 . If this is an entry for a customer meeting, step  610  fetches the customer name from the incoming message and step  612  searches the calendar R&amp;P  122  to determine which, if any, rules are matched. As each matching rule is found as determined at step  614 , step  616  executes the rule, which in the typical case causes the calendar cache  130  to generate an outgoing message to one of the client applications, as above described, to initiate an appropriate action to cache the desired information. As mentioned, the meeting date included in each outgoing message to the client applications prevents the caches from deleting the retrieved information from the caches until after the meeting. 
     It is noted, that each of the client application caches will perform steps similar to those described above. It is also noted that an application cache may delay caching the data described by a queued request to a time just prior to the target date in the request. For example, the browser cache might delay retrieving the bookmarks requested by calendar rule R 3  until, say, three days before the calendar meeting, which is the target date in the respective queued request. 
       FIG. 7  illustrates a simplified example of an information handling system that may be used to practice the present invention. The invention may be implemented on a variety of hardware platforms, including embedded systems, personal computers, workstations, servers, and mainframes. The computer system of  FIG. 7  has at least one processor  710 . Processor  710  is interconnected via system bus  712  to random access memory (RAM)  717 , read only memory (ROM)  714 , and input/output (I/O) adapter  718  for connecting peripheral devices such as disk unit  720  and tape drive  740  to bus  712 . The system has a user interface adapter  722  for connecting a keyboard  724 , a mouse  727 , or other user interface devices such as audio output device  777  and audio input device  778  to bus  712 . The system has a communication adapter  734  for connecting the information handling system to a data processing network  770 , and display adapter  737  for connecting bus  712  to a display device  738 . Communication adapter  734  may link the system depicted in  FIG. 7  with hundreds or even thousands of similar systems, or other devices, such as remote printers, remote servers, or remote storage units. The system depicted in  FIG. 7  may be linked to both local area networks (sometimes referred to as intranets) and wide area networks, such as the Internet. 
     It will be appreciated that the computer system  700  illustrated in  FIG. 6  is merely illustrative, and is not meant to be limiting in terms of the type of system which may provide a suitable operating environment for practicing the present invention. While the computer system described in  FIG. 7  is capable of executing the processes described herein, this computer system is simply one example of a computer system. Many systems are capable of performing the processes of the invention. 
     Artisans in the field of this invention will quickly realize that the preferred and disclosed embodiment can have many variations that are within the intent and scope of the teaching. It is the intent of the inventor to encompass these variations to the extent possible in accordance with the state of the applicable relevant art in the field of the invention.