PATENT DOCUMENT

Publication Number: US-8538685-B2
Application Number: US-75891207-A
Country: US
Kind Code: B2

Title: System and method for internet connected service providing heterogeneous mobile systems with situational location relevant content

Abstract:
Situational location dependent information is transmitted from a server data processing system to a receiving data processing system. The server data processing system communicates with the receiving data processing system in a manner by pushing content when appropriate. A candidate delivery event associated with a current positional attribute of the receiving data processing system is recognized and a situational location of the remote data processing system is determined. The candidate delivery event may be a location and/or direction change, device state change, or movement exceeding a movement tolerance. The situational location of the remote data processing system may be its location, direction, location and direction, proximity to a location, state change, or location and/or direction relative to a previous location and/or direction, or combinations thereof. A set of delivery content from a deliverable content database is transmitted from the server data processing system to the receiving data processing system according to the situational location of the receiving data processing system, and according to delivery constraints. The delivery content is configurable by authorized administrators on an instant activation basis for proactive delivery.

Claims:
What is claimed is: 
     
       1. An internet connected service, said service comprising:
 one or more processors; and 
 a computer-readable medium including one or more sequences of instructions which, when executed by the one or more processors, causes: 
 receiving input from a plurality of content administrators over an internet connection to the service to add content to a database of the service for presentation to a mobile data processing system of a mobile user, the input specifying an association between the content and at least one configured situational location; 
 authenticating the plurality of content administrators to be content administrators of the service; 
 generating an association between the content and the at least one configured situational location; 
 determining a mobile situational location of the mobile user; 
 automatically finding the content in the database by comparing the mobile situational location with the configured situational location; and 
 sending the content to the mobile data processing system. 
 
     
     
       2. The internet connected service of  claim 1  further including instructions that cause causing presentation of the content at the mobile data processing system. 
     
     
       3. The internet connected service of  claim 1  wherein the input is received from a plurality of administrator data processing systems; and wherein at least one of the administrator data processing systems and the mobile data processing system are heterogeneous data processing systems. 
     
     
       4. The internet connected service of  claim 1  wherein the plurality of content administrators use heterogeneous data processing systems for configuring the content. 
     
     
       5. The internet connected service of  claim 1  wherein the mobile user is one of a plurality of mobile users that use heterogeneous data processing systems for participating with the service. 
     
     
       6. The internet connected service of  claim 1  wherein the instructions that cause determining a mobile situational location comprise instructions that cause using global positioning system data to determine the mobile situational location of the mobile user. 
     
     
       7. The internet connected service of  claim 1  wherein the instructions that cause determining a mobile situational location comprise instructions that cause triangulating with radio wave signals the mobile situational location of the mobile user. 
     
     
       8. The internet connected service of  claim 1  wherein the instructions that cause determining a mobile situational location comprise instructions that cause using a network cell identifier to determine the mobile situational location of the mobile user. 
     
     
       9. The internet connected service of  claim 1  wherein the instructions that cause determining a mobile situational location comprise instructions that cause using a telephone number to determine the mobile situational location of the mobile user. 
     
     
       10. The internet connected service of  claim 1  wherein the instructions that cause determining a mobile situational location comprise instructions that cause using a network address to determine the mobile situational location of the mobile user. 
     
     
       11. The internet connected service of  claim 1  wherein the instructions that cause determining a mobile situational location comprise instructions that cause using proximity to a location to determine the mobile situational location of the mobile user. 
     
     
       12. The internet connected service of  claim 1  wherein at least one content administrator, of the plurality of content administrators, is the mobile user. 
     
     
       13. The internet connected service of  claim 1  wherein the content is stored to a local cache of the mobile data processing system for later presentation. 
     
     
       14. The internet connected service of  claim 1  further including instructions that cause maintaining a history of content sent. 
     
     
       15. The internet connected service of  claim 1  wherein instructions that cause sending the content to the mobile data processing system comprise instructions that cause sending the content according to capabilities of the mobile data processing system. 
     
     
       16. The internet connected service of  claim 1  wherein the instructions that cause sending the content to the mobile data processing system comprise instructions that cause sending the content according to interests of the mobile user. 
     
     
       17. The internet connected service of  claim 1  wherein the instructions that cause sending the content to the mobile data processing system comprise instructions that cause sending an indicator for the content to the mobile data processing system. 
     
     
       18. The internet connected service of  claim 1  wherein the content includes an invocable speed reference. 
     
     
       19. A method in an internet connected service, the method comprising:
 receiving input, at a computing device, from a plurality of users that specifies deliverable content and associations between deliverable content and configured situational locations; 
 authenticating, by the computing device, the plurality of users to be administrators of the service; 
 generating, by the computing device, an association between the deliverable content and the configured situational locations; 
 adding, by the computing device, the deliverable content to a deliverable content database of the service; 
 periodically receiving, by the computing device, automatically determined situational locations from a plurality of mobile data processing systems; 
 comparing, by the computing device, the automatically determined situational location of said mobile data processing systems with the configured situational locations associated with deliverable content stored in the deliverable content database; 
 determining, by the computing device, whether one or more of the automatically determined situational locations match one or more of the configured situational locations associated with deliverable content stored in the deliverable content database; and 
 causing presentation, at the mobile data processing systems, of information for deliverable content associated with configured situational locations which match the automatically determined situational locations of the mobile data processing systems. 
 
     
     
       20. The method of  claim 19  further comprising sending the information to the mobile data processing system. 
     
     
       21. The method of  claim 19  wherein the input is received from a plurality of administrator data processing systems; and wherein at least one of the administrator data processing systems and at least one of the mobile data processing system are heterogeneous data processing systems. 
     
     
       22. The method of  claim 19  wherein the plurality of users use heterogeneous data processing systems for configuring the deliverable content. 
     
     
       23. The method of  claim 19  wherein the plurality of mobile data processing systems are heterogeneous data processing systems. 
     
     
       24. The method of  claim 19  wherein the automatically determined situational location is automatically determined using global positioning system data. 
     
     
       25. The method of  claim 19  wherein the automatically determined situational location is automatically determined using triangulation with radio wave signals. 
     
     
       26. The method of  claim 19  wherein the automatically determined situational location is automatically determined using a network cell identifier. 
     
     
       27. The method of  claim 19  wherein the automatically determined situational location is automatically determined using a telephone number. 
     
     
       28. The method of  claim 19  wherein the automatically determined situational location is automatically determined using a network address. 
     
     
       29. The method of  claim 19  wherein the automatically determined situational location is automatically determined using proximity to a location. 
     
     
       30. The method of  claim 19  wherein at least one user, of the plurality of users, is a mobile user. 
     
     
       31. The method of  claim 19  wherein the information is stored to a local cache of the mobile data processing system. 
     
     
       32. The method of  claim 19  further comprising maintaining a history of the information presented. 
     
     
       33. The method of  claim 19  wherein causing presentation, at the mobile data processing systems, of information includes causing presentation, at the mobile data processing systems, of information according to capabilities of the mobile data processing systems. 
     
     
       34. The method of  claim 19  wherein causing presentation, at the mobile data processing systems, of information includes causing presentation, at the mobile data processing systems, of information according to user interests configured for the mobile data processing systems. 
     
     
       35. The method of  claim 19  wherein causing presentation, at the mobile data processing systems, of information includes causing presentation, at the mobile data processing systems, of an indicator for the information. 
     
     
       36. The method of  claim 19  wherein the information includes an invocable speed reference.

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
     The present application is a divisional application of co-pending application Ser. No. 11/464,671, filed Aug. 15, 2006, entitled “System and Method for Proactive Content Delivery by Situational Location,” which is a divisional application of application Ser. No. 10/823,386, filed on Apr. 12, 2004, entitled “System and Method for Proactive Content Delivery By Situational Location”, now U.S. Pat. No. 7,187,997, issued Mar. 6, 2007, which is a divisional application of application Ser. No. 10/167,532, filed on Jun. 11, 2002, entitled “System and Method for Proactive Content Delivery By Situational Location,” now U.S. Pat. No. 6,731,238, issued May 4, 2004, which is a divisional of application Ser. No. 09/589,328 filed on Jun. 7, 2000, entitled “System and Method for Proactive Content Delivery By Situational Location,” now U.S. Pat. No. 6,456,234, issued Sep. 24, 2002. 
    
    
     BACKGROUND OF THE INVENTION 
     The present invention relates generally to location dependent delivery of information to mobile data processing systems, and more particularly to a system for pushing situational location dependent content to data processing system devices traveling to locations for, or in directions of, that place which delivery content is designated as deliverable. 
     The boom of the internet has greatly provided information to mobile users through wireless web server connected devices such as laptops, personal digital assistants (PDAs), and telephones. People with an internet enabled device can access yahoo.com (yahoo is a trademark of Yahoo corporation) and other internet connected resources. There are also Global Positioning System (GPS) devices that enable mobile users to know exactly where they are on a particular map. Users with GPS device functionality can further manually enter their known location into an internet MAP directory service (e.g. yahoo.com Maps) devices provide local processing for directing, and narrating to, a driver. Mating automated location finding systems with internet travel direction services is an attractive blend. 
     Cadillac recently announced the OnStar program with sales of Cadillac automobiles (Cadillac and OnStar are trademarks of General Motors corporation). A person is enabled with calling upon an “OnStar Advisor” 7 days a week, 24 hours a day, with the press of a button. An emergency call, for example 911, or for a disabled Cadillac vehicle, allows a driver to instantly call upon wireless connected assistance. The driver may also call upon the OnStar Advisor for directions to a destination. The Advisor has access to automatic processing for determination of the vehicle&#39;s current location in case of auto theft, a disabled vehicle, or assisting with directions. The Advisor can also remotely unlock the vehicle should the driver lock the keys in the car. In effect, Cadillac drivers have full time wireless connected assistance around the clock for many reasons. While the location determination of the vehicle is automatic, there remain manual processes performed by the Advisor. Automation of some of these processes is desirable. 
     Many internet services derive their revenue stream from advertising. Advertisers pay to have their content delivered to users who access web site and web server interfaces. Advertisers desire to target their audience at the most appropriate time. Knowing the location of a user as being relevant to a particular advertisement is desirable. Automating the delivery of the content is desirable. 
     A method is needed for a low cost business model that enables the efficient configuration of deliverable content for automatic delivery to mobile users based on their situational location that is relevant to receive such content. 
     BRIEF SUMMARY OF THE INVENTION 
     The present invention provides transmission of situational location dependent information from a server data processing system (SDPS) to a receiving data processing system (RDPS). The server data processing system (SDPS) communicates with the receiving data processing system (RDPS) by pushing content (i.e. proactive content delivery) when appropriate, rather than in response to a user query. A candidate delivery event associated with a current positional attribute of the receiving data processing system is recognized and a situational location of the remote data processing system is determined. The candidate delivery event may be a location and/or direction change, device state change, or movement exceeding a movement tolerance. The situational location of the remote data processing system may be its location, direction, location and direction, proximity to a location, state change, or location and/or direction relative to a previous location and/or direction, or combinations thereof. At the SDPS, a set of delivery content from a deliverable content database is retrieved according to the situational location of the RDPS, and according to system delivery constraints and/or configured user delivery constraints. The SDPS transmits any applicable content found to the RDPS. The delivery content is configurable by authorized administrators in a manner that enables the configured content for immediate delivery should a RDPS meet the criteria of the associated situational location and delivery constraints. 
     Various embodiments with respect to recognizing a candidate delivery event and determining a situational location include:
         the SDPS recognizes the candidate delivery event (e.g. various wireless embodiments and physical connection embodiments)   the RDPS recognizes the candidate delivery event (e.g. GPS and some wireless)   the SDPS determines the situational location associated with the candidate delivery event which may have been determined by the RDPS and communicated to the SDPS, or determined by the SDPS   the RDPS determines the situational location associated with the candidate delivery event and communicates the information to the SDPS for further processing       

     A situational location is completely determined for the RDPS upon the candidate delivery event. Content that can be delivered is fully configurable, of any type, and can be instantly activated for candidate delivery upon convenient administration. As well known in the art of software installation, the present invention may be installed to a variety of network embodiments and underlying operating systems through installation parameters, or as distinct installations for the particular platform. Preferably, an internet connection is used for configuring deliverable content, and for the interoperation of communications between the RDPS and SDPS. 
     The present invention enables a user of a RDPS to be made aware of content that is applicable for the current situational location of the user. Depending on the application of the present invention, the content and configurations will take on a variety of themes. 
     For example, in an outdoor wireless embodiment of the present invention, advertisement content can be configured by paying customer advertisers through an internet web interface, and then automatically delivered to people when the people are in a location, or heading path to a location, for reasonable delivery of the content to their automobile installed, or handheld, RDPS. For example, as a driver or pedestrian (i.e. user) approaches a retail store with a mobile RDPS, a configured advertisement of a special deal at the retail store can be proactively delivered (i.e. pushed) to the user automatically on behalf of the store. Likewise, an indoor wireless embodiment of the present invention enables the driver or pedestrian, now a shopper inside the store, to receive configured content to a shopping cart mounted, or handheld, RDPS directing the shopper to specific sales items as the shopper moves about the inside of the store. 
     In another application, a policeman may activate a mobile police automobile device (i.e. RDPS) in a police car for automatic delivery of a person&#39;s criminal record as the policeman drives by the location of a person&#39;s house. The police establishment configures criminal record content, or pointers thereto, along with the location of the residence that is believed to harbor the person with a record. As the policeman drives by locations with addresses of known offenders, the RDPS displays applicable criminal data. Of course, the policeman can enable or disable the functionality as needed. 
     In another application, a traveling vehicle, for example a touring bus, carries tourists for a narrated drive through a geographic area. Currently, there are human narrators for providing narration of sites and landmarks to people of the narrated drive. The present invention allows configuring deliverable content for locations on the touring bus path so that an automated narrator RDPS installed in the bus can be provided to people on the bus. For example, an RDPS providing audio, video, multimedia, or combination thereof, communicates narration content to people on the touring bus automatically as locations are encountered, or driven by. 
     In another application, a person attending a large park (e.g. Disney World (Disney World is a trademark of Walt Disney corporation)) could simply carry a RDPS, and receive content to a handheld device for what attraction lies ahead based on the current location and direction of the person. The person would not have to consult a directory or ask where to find something. Informative content would be proactively delivered, rather than reactively in response to a person&#39;s manual query to a service, or question to a human being. 
     In yet a further example, a valuable use would be for emergencies such as when a child is kidnapped. Currently, there is an Amber-Alert mechanism in Dallas/Ft. Worth, Tex. where radio stations broadcast an emergency message along with a distinguishable series of tones. This enables any pertinent information known about the kidnapper and child to be broadcast immediately to everyone with the radio on. The present invention enables the emergency broadcast to be immediately configured and then communicated to everyone with a RDPS, for example with a wireless internet connection. A picture of the victim and other multimedia information could be delivered along with audio immediately. 
     In still a further use of the present invention, garage sale and estate sale advertisements could be configured on behalf of paying customers that would otherwise use a newspaper classified section. As drivers become in reasonably close proximity to the sale, in the desired time window, advertisement content would be proactively delivered to a wireless RDPS installed, or handheld, in the automobile. 
     Thus, there are many applications for the present invention, all accomplished through simply changing the way the present invention is used. Content is pushed out to receiving devices at the most appropriate times. Users do not pull the content with a query. 
     It is therefore an advantage of the present invention in supporting a variety of applications and uses. The way the invention is used makes it applicable to a wide range of applications. For example, a deliverable content database can be configured with content that is appropriate for the particular application. Situational location parameters associated with the particular application are also variable, provided the installed methodology is utilized consistently. For example, world coordinates, GPS coordinates, regional coordinates, MAPSCO references, Application Address Book locations and directions, a user&#39;s caller id, a cell number in a cellular network, and like means used to describe a location can be used. Directional information of North, South, East, West, Northeast, Southeast, Northwest, Southwest, Up, Down, Left, Right, Straight, Back, and like methods used to describe a direction can be used. Further still, there are delivery constraints that can be set up for a system, or configured by a user, which provides flexibility in adapting to a variety of applications. 
     It is another advantage of the present invention in providing deliverable content to a person, based on the situational location of the person. Content is pushed to a user&#39;s RDPS when it is most appropriate for the user to see the content. 
     It is another advantage of the present invention in automatically recognizing a candidate delivery event of a RDPS and automatically determining a situational location of the RDPS. A user is not burdened with providing information on a query. The present invention automatically determines when content should be delivered and then automatically and proactively delivers it. Content is pushed to the user (of the RDPS). The user is not burdened with pulling content via a query. 
     It is a farther advantage of the present invention to deliver any type, variety, or combination of content. The content is fully configurable by an authorized administrator who may be a paying customer for the privilege of performing configurations. Upon configuration, the content is immediately and instantly activated for proactive delivery to any RDPS meeting the configured criteria. Content may be audio, video, graphical, textual, multimedia, intranet/internet web address(es) activated for transposable selection, image, or any combination thereof. 
     It is another advantage in maintaining a history of delivered content at the RDPS with information that is useful for later browsing. Contained therein is information relevant to the delivered content. Additionally, provided is an invocable speed address enabling the user to transpose to a web address, or perform a speed dial phone call, that is associated with the delivered content. 
     Yet another advantage of the present invention is providing new and useful query functionality for querying the total number of known receiving data processing systems for a particular situational location, querying any content configured for delivery to a particular situational location with a comprehensive variety of query parameters, and querying up to a maximum threshold number of deliverable content instances for a particular location in a manner which automatically determines containing (ascending) locations, if necessary, until the specified number is met. 
     Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention will be described with reference to the accompanying drawings, wherein: 
         FIG. 1  depicts a network illustration for discussing the various outdoor embodiments of the present invention; 
         FIG. 2  depicts an aerial view of a city region useful for discussing aspects of the present invention; 
         FIG. 3A  depicts a locating by triangulation illustration for discussing a wireless, or cellular, embodiment of the present invention; 
         FIG. 3B  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a wireless, or cellular, embodiment of the present invention, in the context of positional attribute(s) being monitored by a SDPS; 
         FIG. 3C  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a wireless, or cellular embodiment, of the present invention, in the context of positional attribute(s) being monitored by a RDPS; 
         FIG. 4A  depicts a locating by triangulation illustration for discussing a GPS, or satellite, embodiment of the present invention; 
         FIG. 4B  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a GPS, or satellite, embodiment of the present invention; 
         FIG. 5A  depicts a locating by triangulation illustration for discussing an indoor wireless embodiment of the present invention; 
         FIG. 5B  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to an indoor wireless embodiment of the present invention; 
         FIG. 6  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a physically connected embodiment of the present invention; 
         FIG. 7A  depicts a preferred embodiment of a data record in the deliverable content database of the present invention; 
         FIG. 7B  depicts a preferred embodiment of a data record in the keyword data of the present invention; 
         FIG. 8  depicts a preferred embodiment of a data record in the location hierarchy data of the present invention; 
         FIG. 9A  depicts a preferred embodiment of a data record in the registration data of the present invention; 
         FIG. 9B  depicts a preferred embodiment of a data record in the location history data of the present invention; 
         FIG. 9C  depicts a preferred embodiment of a data record in the SDPS transmission history data of the present invention; 
         FIG. 9D  depicts a preferred embodiment of a data record in the RDPS transmission history data of the present invention; 
         FIG. 10A  depicts a preferred embodiment high level example componentization of a RDPS of the present invention when the RDPS generates the candidate delivery event; 
         FIG. 10B  depicts a preferred embodiment high level example componentization of a RDPS of the present invention when the SDPS generates the candidate delivery event; 
         FIG. 10C  depicts a block diagram of a data processing system useful for implementing RDPS aspects of the present invention, and SDPS aspects of the present invention; 
         FIG. 11  depicts a flowchart for describing data processing system aspects relevant to a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event determination by the RDPS; 
         FIGS. 12A and 12B  depict flowcharts for describing user event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event determination by the RDPS; 
         FIG. 13  depicts a flowchart for describing system event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event determination by the RDPS; 
         FIG. 14  depicts a flowchart for describing the content administration aspects of the present invention; 
         FIGS. 15A ,  15 B, and  15 C depict flowcharts for service event handling aspects of a preferred embodiment of the SDPS of the present invention, in the context of candidate delivery event determination by the RDPS; 
         FIG. 16  depicts a flowchart for describing the content transmission aspects of the present invention; 
         FIG. 17  depicts a flowchart for describing data processing system aspects relevant to a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event determination not by the RDPS; 
         FIGS. 18A and 18B  depict flowcharts for describing user event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event determination not by the RDPS; 
         FIG. 19  depicts a flowchart for describing system event management.
         processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event determination not by the RDPS; and       

         FIGS. 20A ,  20 B, and  20 C depict flowcharts for service event handling aspects of a preferred embodiment of the SDPS of the present invention, in the context of candidate delivery event determination not by the RDPS. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     With reference now to detail of the drawings, the present invention is described. Obvious errorhandling is omitted from the flowcharts in order to focus on the key aspects of the present invention. 
       FIG. 1  depicts a network illustration for discussing the various outdoor embodiments of the present invention. In one embodiment, a cellular network cluster  102  and cellular network cluster  104  are parts of a larger cellular network. Cellular network cluster  102  contains a controller  106  and a plurality of base stations, shown generally as base stations  108 . Each base station covers a single cell of the cellular network cluster, and each base station  108  communicates through a wireless connection with the controller  106  for call processing, as is well known in the art. Wireless devices communicate via the nearest base station (i.e. the cell the device currently resides in), for example base station  108   b . Roaming functionality is provided when a wireless device roams from one cell to another so that a session is properly maintained with proper signal strength. Controller  106  acts like a telephony switch when a wireless device roams across cells, and it communicates with controller  110  via a wireless connection so that a wireless device can also roam to other clusters over a larger geographical area. Controller  110  may be connected to a controller  112  in a cellular cluster through a physical connection, for example, copper wire, optical fiber, or the like. This enables cellular clusters to be great distances from each other. Controller  112  may in fact be connected with a physical connection to its base stations, shown generally as base stations  114 . Base stations may communicate directly with the controller  112 , for example, base station  114   e . Base stations may communicate indirectly to the controller  112 , for example base station  114   a  by way of base station  114   d . It is well known in the art that many options exist for enabling interoperating communications between controllers and base stations for the purpose of managing a cellular network. A cellular network cluster  116  may be located in a different country. Base controller  118  may communicate with controller  110  through a Public Service Telephone Network (PSTN) by way of a telephony switch  120 , PSTN  122 , and telephony switch  124 , respectively. Telephony switch  120  and telephony switch  124  may be private or public. In one cellular network embodiment of the present invention, the SDPS executes at controllers, for example controller  110 . The RDPS executes at a wireless device, for example mobile laptop computer  126 , wireless telephone  128 , a personal digital assistant (PDA)  130 , or the like. As the RDPS moves about, positional attributes are monitored for determining a situational location. The RDPS may be handheld, or installed in a moving vehicle. Locating a wireless device using wireless techniques such as Time Difference of Arrival (TDOA) and Angle Of Arrival (AOA) are well known in the art. The SDPS may also execute on a server computer accessible to controllers, for example server computer  132 , provided an appropriate timely connection exists between cellular network controller(s) and the server computer  132 . Wireless devices (i.e. RDPS) are known by a unique identifier, for example a caller id, device identifier, or like appropriate unique handle. 
     In another embodiment of the present invention, GPS satellites such as satellite  134 , satellite  136 , and satellite  138  provide information, as is well known in the art, to GPS devices on earth for triangulation locating of the GPS device. In this embodiment, a RDPS has integrated GPS functionality so that the RDPS monitors its positional attribute(s). When the RDPS determines a candidate delivery event, it communicates parameters to the controller by way of the nearest base station. Thus, positional attribute information is provided by the RDPS to the SDPS. The RDPS is again known by a unique identifier, for example a caller id, device identifier, or like appropriate unique handle. 
     In yet another embodiment of the present invention, a physically connected device, for example, telephone  140 , computer  142 , PDA  144 , telephone  146 , and fax machine  148 , may be newly connected to a network. Each is a RDPS. Physical connections include copper wire, optical fiber, or the like. Devices are known by a unique identifier, for example a caller id, device identifier, physical or logical network address, or like appropriate unique handle. When the RDPS is detected for being newly located, the SDPS determines the candidate delivery event. The SDPS may execute at an Automatic Response Unit (ARU)  150 , a telephony switch, for example telephony switch  120 , a web server  152  (for example, connected through a gateway  154 ), or a like data processing system that communicates with the RDPS. RDPS detection may be a result of the RDPS initiating a communication with the SDPS directly or indirectly. Thus, a user may connect his laptop to a hotel network, initiate a communication with the SDPS, and the SDPS determines that the user is in a different location than the previous communication. A local area network (LAN)  156  may contain a variety of connected devices, each an RDPS that later becomes connected to a local area network  158  at a different location, such as a PDA  160 , a server computer  162 , a printer  164 , an internet protocol telephone  166 , a computer  168 , or the like. Hard copy presentation could be made to printer  164  and fax  148 . Electronic content could be delivered to any RDPS. 
     Current technology enables devices to communicate with each other, and other systems, through a variety of heterogeneous system and communication methods. Current technology allows executable processing to run on diverse devices and systems. Current technology allows communications between the devices and/or systems over a plethora of methodologies at close or long distance. Many technologies also exist for automatic locating of devices. It is well known how to have an interoperating communications system that comprises a plurality of individual systems communicating with each other with one or more protocols. As is further known in the art of developing software, executable processing of the present invention may be developed to run on a particular target data processing system in a particular manner, or customized at install time to execute on a particular data processing system in a particular manner. 
       FIG. 2  depicts an aerial view of a city region useful for discussing aspects of, and helps explain one application of, the present invention. A Starbucks coffee shop  202  (Starbucks is a trademark of Starbucks corporation) is located in an area frequented by handheld wireless device (i.e. RDPS) user pedestrians, for example pedestrian  204 , and wireless device (i.e. RDPS) equipped vehicles, for example automobile  206  and automobile  208 . Starbucks is a paying customer to the owner of the present invention wherein content can be configured for advertising to potential customers of Starbucks. An authorized and authenticated Starbucks representative uses the present invention, for example by way of an internet connected web browser, to configure the deliverable content. The representative also configures situational location information that is to be matched to situational locations of a RDPS of mobile customers. Upon configuration completion, the content is immediately activated for proactive delivery. The present invention will automatically deliver the Starbucks configured content to any RDPS according to the representative&#39;s configurations, for example, when pedestrian  204  becomes in a specified proximity to the Starbucks location, encounters a specific location, travels in a manner which provides predictive information, heads in a specified direction at, to, or from a location, or the like, using positional attribute(s). Likewise, automobile  206  will receive the content according to configurations, for example, when making a left hand turn (i.e. changing direction at a location area) onto the street bearing Starbucks&#39; address. Likewise, automobile  208  will receive the content according to configurations, for example, when encountering a location in proximity to the Starbucks location while heading North. One example of the content may be a textual message such as “Starbucks has a 60% off sale just ahead at 314 Main Street with free no-spill coffee mugs!!!”. Other examples may include a graphical map showing where the Starbucks establishment is in relation to showing where the RDPS is currently located and headed. 
       FIG. 3A  depicts a locating by triangulation illustration for discussing a wireless, or cellular, embodiment of the present invention. A RDPS  302  is located through triangulation, as is well known in the art. At least three base towers, for example, base tower  108   b , base tower  108   d , and base tower  108   f , are necessary for locating the RDPS. A fourth base tower would be used if altitude was configured for use by the present invention. There are cases where only two base towers are necessary given routes of travel are limited and known, for example, in spread out roadways or limited configured locations. 
       FIG. 3B  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a wireless, or cellular, embodiment of the present invention, in the context of positional attribute(s) being monitored by a SDPS. Processing begins at block  310  and continues to block  312  where base stations able to communicate to any degree with a RDPS continue reporting to their controller the RDPS signal strength with an RDPS identifier (i.e. a unique handle) and Time Difference of Arrival (TDOA) information, or alternatively, Angle of Arrival (AOA) information, depending on the embodiment. When the RDPS turns on, it registers itself. The RDPS can pick signals from base stations. In one embodiment, the RDPS monitors a paging channel, called a forward channel. There can be multiple forward channels. A forward channel is the transmission frequency from the base tower to the RDPS. Either the RDPS provides heartbeat for base stations, or the base stations provide heartbeats for a response from the RDPS. Communication from the RDPS to the base tower is on what is called the reverse channel. Forward channels and reverse channel are used to perform call setup for a created session channel. 
     TDOA is conventionally calculated from the time it takes for a communication to occur from the RDPS back to the RDPS via the base tower, or alternatively, from a base tower back to that base tower via the RDPS. AOA is conventionally performed through calculations of the angle by which a signal from the RDPS encounters the base tower antenna. Simple triangle geometry is then used to calculate a location. The AOA antenna is typically of a phased array type. 
     The controller at block  314  may communicate with other controllers when base stations in other cellular clusters are picking up a signal, for example, when the RDPS roams. In any case, at block  314 , the controller(s) determines the strongest signal base stations needed for locating the RDPS, at block  314 . The strongest 3 (or 2 or 4 as discussed above) are used. Thereafter, block  316  accesses base station location information for base stations determined at block  314 . The base station provides location anchors used to (relatively) determine the location of the RDPS. Then, block  318  uses the TDOA, or AOA, information together with known base station locations to calculate the RDPS location. Blocks  310  through  318  are well known to those skilled in art. Thereafter, block  320  accesses historical RDPS location information, and block  322  performs housekeeping by pruning location history data for the RDPS by time, number of entries, or other criteria. Block  324  then determines a direction of the RDPS based on previous location information. Block  324  may perform Artificial Intelligence (AI) to determine where the traveler may be going by consulting many or all of the location history data. Block  324  may also consider when and/or where a candidate delivery event (CADE) was generated for a direction change in order to cause certain flow from block  330 . Block  326  calculates how much (e.g. distance) the RDPS has moved since the previous location that caused a candidate delivery event (CADE) generation for the RDPS (event generated Y/N field in location history data). Thereafter, block  328  compares the movement since the last CADE generation, and if the distance exceeds a movement tolerance, then block  332  posts (generates) a CADE to a present invention service handling RDPS situational location changes. The movement tolerance may be a system wide setting for all RDPS devices, particular to a type of RDPS, or specific for an RDPS. 
     If, at block  328 , movement did not exceed the tolerance, then block  330  checks for a direction change as determined at block  324 . If, at block  330 , the direction did change, then a CADE is generated at block  332 . If, at block  330 , the direction of the RDPS did not change, then block  334  appends an appropriate entry to the location history data (see  FIG. 9B ). Block  332  also flows to block  334 . Blocks  324  through  330  determine if a CADE is to be generated, and if so, a CADE is generated at block  332 . Blocks  324  through  330  determine part, or all, (i.e. a subset) of the situational location, depending on the installation.  FIG. 3B  processing is continuous for every RDPS in the wireless network 7 days a week, 24 hours a day. 
       FIG. 3C  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a wireless, or cellular, embodiment, of the present invention, in the context of positional attribute(s) being monitored by a RDPS.  FIG. 3B  demonstrated the CADE and part, or all, of the situational location being determined by a SDPS service.  FIG. 3C  demonstrates the CADE, and part, or all, of the situational location being determined by the RDPS itself, and then communicated to the SDPS for any further situational location determination and applicable content delivery. Communications between the base stations and RDPS is similar to above except the RDPS receives information for performing calculations and related processing. Processing begins at block  350  and continues to block  352  where the RDPS continues receiving pulse reporting from base stations. Block  354  determines the strongest 3 signals (or 2 or 4). Thereafter, block  356  parses base station location information from the pulse messages that are received by the RDPS. Block  358  communicates with base stations to perform TDOA calculations. The time it takes for a communication to occur from the RDPS back to the RDPS, or alternatively, from a base tower back to that base tower is used. Block  358  uses the TDOA information with the known base station information to determine the RDPS location. Blocks  350  through  358  are well known to those skilled in art. 
     Thereafter, block  360  accesses historical RDPS location information, and block  362  performs housekeeping by pruning the location history data for the RDPS by time, number of entries, or other criteria. Block  364  then determines a direction of the RDPS based on previous location information. Block  364  may perform Artificial Intelligence (AI) to determine where the traveler may be going by consulting much or all of the location history data. Block  364  may also consider when and/or where a candidate delivery event (CADE) was generated for a direction change in order to cause certain flow from block  370 . Block  366  calculates how much (e.g. distance) the RDPS has moved since the previous location that caused a candidate delivery event (CADE) generation for the RDPS (event generated Y/N field in location history data). Thereafter, block  368  compares the movement since the last CADE generation and if the distance exceeds a movement tolerance, then block  372  posts (generates) a CADE to the present invention system event manager of the RDPS. The movement tolerance may be a system or user configured setting. 
     If, at block  368 , movement did not exceed the tolerance, then block  370  checks for a direction change as determined at block  364 . If, at block  370 , the direction did change, then a CADE is generated to the system event manager at block  372 . If, at block  370 , the direction of the RDPS did not change, then block  374  appends an appropriate entry to the location history data (see  FIG. 9B ). Block  372  also flows to block  374 . Blocks  364  through  370  determine if a CADE is to generated, and if so, a CADE is generated at block  332 . Blocks  364  through  370  determine part, or all, (i.e. a subset) of the situational location, depending on the installation.  FIG. 3C  processing is continuous for the RDPS as long as the RDPS is enabled. 
       FIG. 4A  depicts a locating by triangulation illustration for discussing a GPS, or satellite, embodiment of the present invention. A RDPS  402  is located through GPS triangulation as is well known in the art. At least three satellites, for example, satellite  134 , satellite  136 , and satellite  138 , are necessary for locating the RDPS. A fourth satellite would be used if altitude was configured for use by the present invention. 
       FIG. 4B  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a GPS, or satellite, embodiment of the present invention. GPS location processing begins at block  410  and continues to block  412  where the RDPS initializes for using a system management interface. The system event manager may be a software interrupt, hardware interrupt, queue, or other event handling entity. Block  414  performs the conventional locating of the GPS enabled RDPS, and block  416  posts (generates) a CADE to the RDPS system event manager. Block  414  may be an implicit wait for pulses from satellites, or an event driven mechanism when GPS satellite pulses are received for synchronized collection. Block  414  processing is well known in the art. Block  416  may post the event information to other processes depending on the RDPS features using such information. Thereafter, the GPS location information is used at block  418  as applicable to the particular RDPS embodiment, for example showing the RDPS location on a graphical map. GPS location processing is continuous for the RDPS as long as the RDPS is enabled. 
     The CADE in this example is a result of a simple location change. Any further situational location determination task remains for the system event manager. An alternative embodiment to block  414  would further include processing of  FIG. 3C  blocks  360  through  370  to determine part, or all, (i.e. a subset) of the situational location so that a CADE is generated at block  416  only if the situation warrants it. 
       FIG. 5A  depicts a locating by triangulation illustration for discussing an indoor wireless embodiment of the present invention. There may be communication/transmission issues when an RDPS is taken indoors. There are also unique applications of the present invention for indoor use. Shown is a top view of an indoor floor plan  502 . Antenna stations  504  (shown generally as  504 ) are strategically placed over the area so that an RDPS, for example, an RDPS equipped shopping cart  506 , can be located. The conventional triangulation techniques again apply. At least three antenna stations, for example, station  504   f , station  504   h , and station  504   i  are used to locate the RDPS equipped shopping cart  506 . In floor plan embodiments where aisles delimit travel, only two antenna stations may be necessary, for example at either end of the particular aisle. While most stations  504  may receive signals from the RDPS, only the strongest stations are used. 
     In this example embodiment of using the present invention, a shopper with a grocery cart receives content at the RDPS as the shopping cart is navigated throughout the store. Special deal, sales, or other promotional content is pushed automatically by the present invention to the RDPS of the shopping cart, at appropriate situational locations of the shopping cart. A store representative will manage what content to deliver through convenient configuration of the present invention. The store will provide RDPS equipped shopping carts, or may provide handheld RDPS devices, so that shoppers will get the most of their experience by automatically receiving content that is appropriate to the shopper&#39;s situational location in the store. 
       FIG. 5B  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to an indoor wireless embodiment of the present invention. In one embodiment, indoor location technology of Pinpoint corporation (Pinpoint is a trademark of Pinpoint Corporation) is utilized to locate any RDPS that moves about the indoor location. The Pinpoint corporation methodology begins at block  510  and continues to block  512 . A cell controller drives antenna stations to emit a broadcast signal from every station. Any RDPS within range (i.e. indoors), will phase modulate its unique identifier onto a return signal it transmits, at block  514 . Stations at block  516  receive the transmission and strength of signal. The cell controller that drives stations sorts out and selects the strongest 3 signals. The cell controller, at block  518 , also extracts the RDPS unique identifier from the return signal, and TDOA (or AOA if phase array antennas are used) is used to calculate distances from the stations receiving the strongest signals from the RDPS at block  520 . The locations of the controller selected stations are registered in an overlay map in an appropriate coordinate system, landmark system, or grid of cells. Block  522  locates the RDPS using the overlay map, locations of the 3 selected stations, and the calculated distances triangulated from the selected stations. Processing through block  522  has located the RDPS with known Pinpoint corporation technology. Thereafter, a block  524  can perform a CADE generation to a SDPS service of the present invention. Processing continues with repeated broadcast at block  512  and subsequent processing for every RDPS. 
     The CADE in this example is a result of a simple location change. Any further situational location determination task remains for the SDPS event handler. An alternative embodiment to block  524  would further include processing of  FIG. 3B  blocks  320  through  330  to determine part, or all, (i.e. a subset) of the situational location so that a CADE is generated at block  524  only if the situation warrants it. 
       FIG. 6  depicts a flowchart for describing a preferred embodiment of the candidate delivery event generation aspect relevant to a physically connected embodiment of the present invention. A RDPS may be newly located and physically connected, whereby communications between the RDPS and SDPS is over a physical connection. With reference now to  FIG. 1 , when a RDPS, for example internet protocol telephone  166 , is moved from LAN  156  to a LAN  158  in a different location, the present invention detects the location change when the RDPS initiates a communication to the SDPS. With reference back to  FIG. 6 , relevant processing according to the present invention begins at block  602  and continues to block  604  where an RDPS device is physically connected to a network. Thereafter, the RDPS accesses a SDPS incorporating the present invention, at block  606 . Then, at block  608 , the SDPS accesses historical RDPS location information (i.e. the previous location history data record  900 —see  FIG. 9B  location history data discussion below), and block  610  performs housekeeping by pruning the location history data maintained for the RDPS by time, number of entries, or other criteria. Block  608  may perform Artificial Intelligence (AI) to determine where the traveler may be going (e.g. using direction based on previous locations) by consulting much or all of the location history data. Thereafter, SDPS processing, at block  612 , compares the current network address with the previous network address. If they are identical, then SDPS processing continues to block  616 . If they are different, then the SDPS generates a CADE to the event handling service of the SDPS at block  614 . Thereafter, SDPS processing continues to block  616 . Block  616  appends an entry to the location history data for the RDPS, and SDPS processing ends at block  618 . Block  612  may compare to other location history data information, depending on any AI of block  608 . 
       FIG. 7A  depicts a preferred embodiment of a data record in the deliverable content database of the present invention. A deliverable content database record  700  includes fields  702  through  724  as shown. Rec id field  702  is a unique identifier to the record in the database. Rec id field  702  is system generated, for example, using an Oracle unique sequence number function (Oracle is a trademark of Oracle corporation) upon inserting the record (i.e. database row) into the deliverable content database (i.e. database table). The rec id field  702  is used in the transmission history data to correlate transmitted content, enables detection of redundant delivery, and enables later RDPS retrieval of content when only a content delivery indicator is transmitted to an RDPS. Location field  704  contains a positional attribute of location information for which the associated content will be delivered. Depending on the installation, the location field contains a cellular network cell identifier, truncated precision geocentric coordinates, truncated precision geodetic coordinates, truncated three dimensional space coordinates, area described by GPS coordinates (e.g. four corners of a grid rectangle), overlay grid region identifier or coordinates, GPS coordinates with truncated precision, altitude, MAPSCO reference, telephone number (e.g. caller id), physical or logical network address (including a wildcard (e.g. ip addresses 145.32.*.*)), particular application address, or a like location. Truncated precision allows specifying a broader scope, for example, latitude/longitude in degrees, minutes, seconds, etc., depends on how the number is truncated. Zooming in implies more precision. Zooming out implies less precision. Combinations of these positional attributes may also designate a location. Depending on the installation, the positional attribute direction field  706  contains a direction such as North, South, East, West, or Southwest, Southeast, Northwest, Northeast, or Left, Right, Straight, Back, or Up, Down, or the like. A value of null may also be present when a direction is inappropriate, for example in one embodiment of  FIG. 6 . Time criteria field  708  contains a time window(s), or time interval(s), for which the associated deliverable content is valid for delivery. Preferably, time points of time criteria are entered in “YYYYMMDDHHMMSS” format. Content type field  710  describes the type of content field  712 . Content types include, and are not limited to, web address, audio, image, multimedia, text, and video. The content field  712  contains the deliverable content, or a reference such as a filename, pointer, or the like, to the content. Short Text info field  714  allows configuration of a short textual message to be delivered to the RDPS and maintained in the RDPS transmission history data, for example, a business address. Speed reference info  716  is a web address or phone number that is delivered to the RDPS with the content, and is also maintained in the RDPS transmission history for convenient invocation. Thus, the user may browse the history, and invoke the speed reference for automatic telephone call dialing from the RDPS, or for automatic web address transposition in a launched web browser, upon a simple user selection of the speed reference from the history. Depending on the installation, delivery activation setting(s) field  718  will contain a bit mask, or the like, for the RDPS state which establishes delivery. For example, the bit mask will contain a settable bit for:
         Deliver on RDPS registration   Deliver on RDPS termination   Deliver only when RDPS requests   Deliver always (used for emergency use—see Amber-Alert discussion above)   Deliver for situational location change   3 or more bits reserved for future use       

     Authorization id field  720  contains a handle to the user who configured the database record  700 , for example, a password, user identifier, or the like (may be encrypted). Content links field  722  contains a YES/NO flag for whether there are multiple content fields associated with the database record  700 . A separate database entity (not shown), for example a database table, can be maintained with 3 fields: one containing a matching rec id field  702  to associate the content to the deliverable content database record  700 , one for the content type (like content type field  710 ), and one for the content (like content field  712 ). There may be a plurality of database records in the separate database entity that are associated with the deliverable content database record  700 . The value in the rec id field  702  will be used to join all content items. 
     Applications specific data fields  724  are available for the SDPS being an integrated solution with some other service. Location field  704 , direction field  706 , time criteria field  708 , and delivery activation setting(s) field  718  together form the situational location information associated with the content which establishes a delivery. 
       FIG. 7B  depicts a preferred embodiment of a data record in the keyword data of the present invention. A keyword data record  750  is joined to a deliverable content database record  700  through a matching rec id field  752 . Keywords field  754  contains one or more comma separated text strings used to associate criteria to the deliverable content database record  700 . Phrases containing blank separated words are enclosed in quote marks. In one embodiment of the present invention, a RDPS user specifies interests that are matched to the keywords field  754 . Only the user&#39;s interests, along with the RDPS situational location, will cause delivery of associated content. An alternative embodiment for maintaining keyword data will associate a plurality of keyword data records  750  to a deliverable content database record  700 , each containing a singular keyword, or phrase, in keywords field  754 . Fields  704 ,  706 ,  708 ,  718 , and  754  are system delivery constraints of the present invention. 
       FIG. 8  depicts a preferred embodiment of a data record in the location hierarchy data of the present invention. A location hierarchy data record  800  has fields as shown. Rec id field  802  is a unique identifier to the record. Rec id field  802  is system generated, for example, using an Oracle unique sequence number function upon inserting the record (i.e. database row). Location field  804  is a location of the nature as described for location field  704 . Ascending location field  706  is a value found in rec id field  802  of another location hierarchy data record  800 . If used, the configuration of this table must be performed carefully so as to affect its use appropriately. Semantically, field  806  must be an ascending location to field  804 . For example, Texas is ascending to Denton County, and Denton County is ascending to Flower Mound. Similarly, a set of MAPSCO grid numbers, that surround a MAPSCO reference grid D of map  691 , are ascending to MAPSCO reference grid D of map  691 . Ascending implies zooming out to cover more surrounding area. Location hierarchy data is searched in the following manner:
         For content by candidate delivery events, content is retrieved by the location, and any locations descending to that location (i.e. zoom in)   For situational location queries, content is optionally retrieved by the location and descending locations, and optionally, ascending locations as necessary (i.e. zoom out) according to parameters (discussed below)       

       FIG. 9A  depicts a preferred embodiment of a data record in the registration data of the present invention. A registration data record  900  is maintained by the SDPS and includes fields as shown. Device id field  902  is a unique handle to an RDPS. Depending on the installation, device id field  902  may be a telephone #, physical or logical address, or some other unique handle to the RDPS. Communications bind information field  904  is a record describing the communications session between the RDPS and SDPS, as is well known in the art. In some embodiments, field  904  contains capability information sent from the RDPS so that only the appropriate content is delivered, for example acceptable types of, or acceptable amounts (size) of, content. Interests field  906  contains one or more comma separated user configured text strings used to match to the keywords field  754 . If used, only the user&#39;s interests, along with the RDPS situational location, will cause proactive delivery of associated content. Filter criteria field  908  is identical in nature to interests field  906  and keywords field  754  except the criteria is for exclusion. If used, filter criteria field  908  is also compared with keywords field  754 . Thus, the RDPS user can configure interests for inclusion through field  906 , or criteria for exclusion through field  908 . Movement tolerance field  910  defines the minimal amount of movement since the last delivery content retrieval attempt that determines to perform another retrieval. Movement tolerance field  910  is optional depending on the installation. The movement tolerance may be a system wide setting enforced by the SDPS, associated to a class of RDPS devices, or individualized by the user or system. Field  910  may not be present because the movement tolerance is maintained by the RDPS, or is not applicable to the installation (e.g. RDPS physically connected, or located by caller id). The movement tolerance depends on the installed use of location field  704 . For example, in a coordinate system, a distance may be configured. In an overlay map, region, or cell change, a number of regions or cells from a previous location may be configured. Fields  906  and  908  are user configured delivery constraints of the present invention. Registration data record  900  presence enables delivery to the associated RDPS, otherwise the RDPS is not an eligible receiver. Obvious error handling at the SDPS ignores all requests that are not from a RDPS with a device id in the registration data (except for registration types of requests (i.e. events)). 
       FIG. 9B  depicts a preferred embodiment of a data record in the location history data of the present invention. A location history data record  920  is maintained for the travels of a RDPS, and includes fields as shown. Device id field  922  is identical in nature to device id field  902 . Location field  924  is identical in nature to location field  704 . Direction field  926  is identical in nature to direction field  706 . Event posted field  928  is a YES/NO flag for whether or not this location history data record  920  is associated with generating a CADE. Date/time stamp field  930  is the time that the RDPS was detected at the associated location and specified direction of fields  924  and  926 . Direction field  926  is optional depending on the installation, as discussed above. 
       FIG. 9C  depicts a preferred embodiment of a data record in the SDPS transmission history data of the present invention. A transmission history data record  940  is maintained at the SDPS for all content that is transmitted to the RDPS, and includes fields as shown. Device id field  942  is identical in nature to device id field  902 . Location field  944  is identical in nature to location field  704 . Direction field  946  is identical in nature to direction field  706 . Rec id field  948  contains a copy of rec id field  702  for content that was transmitted to the RDPS of field  942 . Indicator sent field  950  is a YES/NO flag for whether or not the content was actually transmitted, or a content delivery indicator for the content was transmitted. Date/time stamp field  952  is the time that content described by field  948  was transmitted to the RDPS. Direction field  946  is optional depending on the installation, as discussed above. 
       FIG. 9D  depicts a preferred embodiment of a data record in the RDPS transmission history data of the present invention. A transmission history data record  970  is maintained at the RDPS for all content that is received by the RDPS, and includes fields as shown. Date/time stamp field  972  is the time that content described by rec id field  976  was received by the RDPS. Indicator sent field  974  is a YES/NO flag for whether or not the content was actually received, or an indicator for the content was received. Rec id field  976  contains a copy of rec id field  702  for content that was received by the RDPS. Speed reference information field  978  contains a phone number for automatic dialing, a web page reference for automatic transposition, or both. Speed reference information field  978  is obtained by the RDPS from field  716 . Short text field  980  is obtained by the RDPS from  714 . Location field  982  is identical in nature to field  704 . Direction field  984  is identical in nature to field  706 . Field  982  and  984  may not be used if this information is maintained at the SDPS. Fields  982  and  984  are preferably used when the RDPS handles CADE generation, or if the SDPS additionally transmits the information with the content. Direction field  984  is optional depending on the installation, as discussed above. 
       FIG. 10A  depicts a preferred embodiment high level example componentization of a RDPS of the present invention when the RDPS generates the candidate delivery event. An RDPS  1000  includes system manager  1002 , location management system  1004 , system event management  1006 , user event management  1008 , user interface management  1010 , and communications interface  1012 . System manager  1002  is the operating system environment of the RDPS  1000 . Location management system  1004  provides means for locating the RDPS  1000 , for example GPS functionality. System event management  1006  provides an interface to system event processing relevant to the present invention that is not directly caused by a user. User event management  1008  provides an interface to event processing relevant to the present invention that is directly caused by a user, for example when the user uses the RDPS user interface. User interface management  1010  is the user interface system environment of the RDPS  1000 , for example, a variety of Microsoft Windows (Microsoft and Windows are trademarks of Microsoft corporation), a wireless phone interface, or some other user interface system. Communications interface  1012  provides the interface between the RDPS  1000  and the SDPS. 
       FIG. 10B  depicts a preferred embodiment high level example componentization of a RDPS of the present invention when the SDPS generates the candidate delivery event. An RDPS  1020  includes a system manager  1022 , system event management  1026 , user event management  1028 , user interface management  1030 , and communications interface  1032 . System manager  1022  is the operating system environment of the RDPS  1020 . System event management  1026  provides an interface to system event processing relevant to the present invention that is not directly caused by a user. User event management  1028  provides an interface to event processing relevant to the present invention that is directly caused by a user, for example when the user uses the RDPS user interface. User interface management  1030  is the user interface system environment of the RDPS  1020 , for example, a variety of Microsoft Windows (Microsoft and Windows are trademarks of Microsoft corporation), a wireless phone interface, or some other user interface system. Communications interface  1032  provides the interface between the RDPS  1020  and the SDPS. RDPS  1000  and RDPS  1020  may further include a local cache with a cache management component that facilitates cacheing the deliverable content database and associated data at the RDPS for efficient access. 
       FIG. 10C  depicts a block diagram of a data processing system useful for implementing RDPS aspects of the present invention, and SDPS aspects of the present invention. A data processing system  1050  according to the present invention includes at least one processor  1052  coupled to a bus  1054 . The data processing system  1050  also includes main memory  1056 , for example, random access memory (RAM). Optionally, the data processing system  1050  may include secondary storage devices  1058  such as a hard disk drive  1060 , and/or removable storage device  1062  such as a compact disk, floppy diskette, or the like, also connected to bus  1054 . In one embodiment, secondary storage devices could be remote to the data processing system  1050  and coupled through an appropriate communications interface. 
     The data processing system  1050  may also include a display device interface  1064  for driving a connected display device (not shown). The data processing system  1050  may further include one or more input peripheral interface(s)  1066  to input devices such as a keyboard, telephone keypad, Personal Digital Assistant (PDA) writing implements, mouse, voice interface, or the like. User input (i.e. user events) to the data processing system are inputs accepted by the input peripheral interface(s)  1066 . The data processing system  1050  may still further include one or more output peripheral interface(s)  1068  to output devices such as a printer, facsimile device, or the like. 
     Data processing system  1050  will include a communications interface  1070  for communicating to another data processing system  1072  via analog signal waves, digital signal waves, infrared proximity, copper wire, optical fiber, or the like. Other data processing system  1072  is an RDPS when data processing system  1050  is an SDPS. Other processing system  1072  is an SDPS when data processing system  1050  is an RDPS. In any case, the RDPS and SDPS are said to be interoperating when communicating. Thus, the RDPS and SDPS form an interoperating communications system between which data may be communicated. 
     Data processing system programs (also called control logic) may be completely inherent in the processor  1052  being a customized semiconductor, or may be stored in main memory  1056  for execution by processor  1052  as the result of a read-only memory (ROM) load (not shown), or may be loaded from a secondary storage device into main memory  1056  for execution by processor  1052 . Such programs, when executed, enable the data processing system  1050  to perform features of the present invention as discussed herein. Accordingly, such data processing system programs represent controllers of the data processing system. 
     In one embodiment, the invention is directed to a control logic program product comprising a processor  1052  readable medium having control logic (software) stored therein. The control logic, when executed by processor  1052 , causes the processor  1052  to perform functions of the invention as described herein. 
     In another embodiment, the invention is implemented primarily in hardware, for example, using a prefabricated component state machine (or multiple state machines) in a semiconductor element such as processor  1052 . 
     Those skilled in the art will appreciate various modifications to the data processing system  1050  without departing from the spirit and scope of the invention. Data processing system  1050 , as discussed, is representative of a RDPS of the present invention. Data processing system  1050 , as discussed, is representative of a SDPS of the present invention. 
     Receiving Data Processing System Candidate Delivery Event Generation Embodiment 
       FIG. 11  depicts a flowchart for describing data processing system aspects relevant to a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event generation by the RDPS. When the RDPS is enabled, for example, by a power switch, system manager processing begins at block  1102  and continues to block  1104  where the system appropriately initializes, for example to default interfaces. Processing continues to block  1106  where the location management system is initialized as is appropriate for the particular RDPS, and then on to block  1108  where a movement tolerance is defaulted, depending on the RDPS installation, and depending on what it was during the last power-on. The movement tolerance may be user configurable or system set, and is therefore either a system delivery constraint, or user configured delivery constraint. Thereafter, block  1110  defaults situational location information to the most recent setting for a CADE from last power-on, or system just started if this is the first power-on, and block  1112  waits for a user event or system event. User interface management is coupled with the system manager to enable a user to the RDPS. Upon detection of an event, block  1112  flows to block  1114  for any user event management processing. Should block  1114  processing return, block  1116  performs any system event management processing. Should processing of block  1116  return, block  1118  handles the event appropriately as is relevant for other events of the RDPS, for example, user interface control of little interest to discussion of the present invention. Thereafter, block  1118  flows to block  1112  for processing as described. 
     An alternate embodiment of  FIG. 11  will implement a multithreaded system wherein events are handled asynchronously as they occur. 
       FIGS. 12A and 12B  depict flowcharts for describing user event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event generation by the RDPS. User event management begins at block  1202  and continues to block  1204 . If block  1204  determines that the user event is powering the RDPS off, then block  1206  communicates with the SDPS to remove (if any) its RDPS data record  900  from the registration data, block  1208  terminates any communication session gracefully (if required) depending on the RDPS, block  1210  saves settings, for example, the movement tolerance and delivery setting for the next power on, and RDPS processing stops at block  1211 . 
     If block  1204  determines the RDPS was not turned off, then processing continues to block  1212 . If block  1212  determines that the user selected to enable communications with the SDPS, then block  1214  establishes communications with the SDPS (if not already established), and block  1216  consults the current delivery setting. In one embodiment, block  1214  through  1220  may be processed just as the result of a wireless device being powered on. If block  1216  determines that the content delivery setting for receiving situational location dependent content is enabled, then block  1218  communicates with the SDPS for inserting a registry data record  900  into the registry data. Thereafter, block  1220  sets a RDPS user interface indicator showing that communications to the SDPS is enabled, and processing returns to block  1112  of  FIG. 11  by way of off page connector  11000 . If block  1216  determines the delivery setting is not enabled, then processing continues to block  1220 . 
     If block  1212  determines that the user did not select to enable communications to the SDPS, then processing continues to block  1222 . If block  1222  determines that the user selected to disable SDPS communications, then block  1224  communicates with the SDPS to remove its registry data record  900  from registry data, block  1226  terminates the communications session gracefully (if required) depending on the RDPS embodiment, block  1228  sets the communications to SDPS user interface indicator to disabled, and processing continues back to block  1112 . In one embodiment, block  1224  through  1228  may be processed just as the result of a wireless device being powered off. 
     If block  1222  determines the user did not select to disable communications to the SDPS, then processing continues to block  1230 . If block  1230  determines that the user selected to modify the RDPS content delivery setting, then the user modifies the setting at block  1232 , the delivery setting is set accordingly at block  1234 . Preferably, blocks  1230 / 1232  allow a user to toggle the content delivery setting. No content will be delivered when this setting is disabled. Being registered with the SDPS constitutes being eligible for delivery. Alternative embodiments won&#39;t have such a feature. The content delivery setting is a user configured delivery constraint. Block  1234  also sets and an indicator in the user interface for displaying that setting, and block  1236  communicates with the SDPS to insert or remove its registry data record  900  should the setting be different than previous. Of course, appropriate error handling is performed by block  1236  if there is no communications enabled. Thereafter, processing continues to block  1112 . 
     If block  1230  determines that the user did not select to modify the content delivery setting, then processing continues to block  1238 . If block  1238  determines that the user selected to modify the movement tolerance, then the user modifies a validated movement tolerance at block  1240 , the movement tolerance is set at block  1242 , and processing continues back to block  1112 . 
     If block  1238  determines that the user did not select to modify the movement tolerance, then processing continues to block  1244 . If block  1244  determines that the user selected a content delivery indicator, as maintained in a transmission history data record  970  for deliverable content from the SDPS, then block  1246  communicates with the SDPS using the rec id field  976 . In one embodiment, the user peruses the transmission history data in response to receiving a content delivery indicator from the SDPS. In another embodiment, correlation is maintained between individual user interface indicators to their associated transmission history data record  970  for allowing the user to simply select the indicator in the user interface for communicating with the SDPS to deliver the associated content. Providing a visual and/or audible presentation of the indicator is well known in the art, and may be implemented with a variety of methods. Block  1246  makes the request for content to the SDPS with the rec id  976 . Thereafter, via a received system event, blocks  1318  through  1326  handle receipt, delivery, and RDPS user interface presentation of the content in a manner appropriate to the content type from the SDPS. Processing continues from block  1246  back to block  1112 . 
     If block  1244  determines that the user did not select an indicator of deliverable content, then processing continues to block  1250  by way of off page connector  12000 . If block  1250  determines that the user selected to configure interests or filters, then block  1252  interfaces with the user to configure interests or filters which are saved locally at block  1254 , and processing continues back to block  1112  by way of off page connector  11000 . Any configured interests and filters are communicated to the SDPS at blocks  1218  and  1236  as part of registration. Interests field  906  and filter criteria field  908  are set with data configured at block  1252 . The RDPS must de-register and re-register with new settings. In an alternative embodiment, block  1254  communicates with the SDPS to update the RDPS&#39; registry data record  900 . 
     If block  1250  determines that the user did not select to configure interests or filters, then processing continues to block  1256 . If block  1256  determines the user selected to perform a situational location query, then the user specifies validated parameters (discussed with  FIG. 15B ) at block  1258 . Thereafter, block  1260  communicates an appropriate formatted request to the SDPS. Thereafter, via a received system event, blocks  1318  through  1326  handle receipt, delivery, and RDPS user interface presentation of the content in a manner appropriate to the content type from the SDPS. Processing leaves block  1260  and returns to block  1112 . 
     If block  1256  determines that the user did not select to perform a situational location query, then processing continues to block  1264 . If block  1264  determines that the user selected to query the number of known RDPS devices at a location(s) (i.e. a client count request), then block  1266  interfaces with the user to specify valid parameters including situational location information and time criteria, and processing continues to block  1260  which was described. A content specification parameter may also be specified for retrieving the situational location content as well. Time criteria embodiments include any time window in history, a current time window (of request, transmission of request, SDPS receipt of request, or processing the request), or a truncated precision time. Truncated precision time allows specifying time windows (e.g. 12:04 pm implies 4 minutes after 12:00 pm and additionally any number of seconds up to and not including 5 minutes after 12:00 pm). 
     If block  1264  determines that the user did not select to query the number of RDPS devices at a location(s) (i.e. a client count request), then processing continues to block  1268 . If block  1268  determines that the user selected to browse transmission history data, then block  1270  interfaces with the user until he either exits, or selects information from the speed reference information field  978  from a transmission history data record  970 . Preferably, block  1270  permits scrolling transmission history data records  970  with fields columnized. If, at block  1272 , the user selected information of field  978 , then block  1274  automatically performs the action, an automatic dialing of a telephone number, or automatic transposition to a web page. Speed reference information field  978  is preferably related to content that was delivered as referenced by rec id field  976 . Thereafter, processing continues back to block  1112 . If block  1272  determines that the user exited from block  1270 , then processing continues back to block  1112 . 
     If block  1268  determines that the user did not select to browse the transmission history data, then processing stops at block  1276 . 
     Note that some RDPS embodiments will not require blocks  1212  through  1228  because there may not be an active session required to have communications between the RDPS and SDPS. 
       FIG. 13  depicts a flowchart for describing system event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event generation by the RDPS. System event management begins at block  1302 , and continues to block  1304 . If block  1304  determines the system event is a positional attribute change (e.g. location change) from the RDPS location management system, housekeeping is performed at block  1306  by pruning the location history data maintained at the RDPS. Pruning may be by time, number of entries, or other criteria. Thereafter, block  1308  determines if a CADE is to be generated. In one embodiment, block  1308  compares the current positional attribute (e.g. location) with the former positional attribute of location history data record  920  that contains an event posted YES/NO field  928  set to YES. The distance is calculated and then compared with the movement tolerance. Block  1308  also determines if there was a direction positional attribute change. Processing continues to block  1310  where a location history data record  920  is appended to the location history data for the current location and/or direction with the event posted field  928  set according to what block  1308  determined. Block  1310  flows to block  1312 . 
     If block  1312  determines that a CADE is to be generated to the SDPS, then processing continues to block  1314 . If block  1314  determines that the content delivery setting is set to enabled, then block  1316  formats and issues a CADE request to the SDPS, and processing continues to block  1112  by way of off page connector  11000 . 
     If block  1314  determines that the content delivery setting is not enabled, then processing continues to block  1112 . If block  1312  determines that a CADE is not to be generated, then processing continues to block  1112 . 
     If block  1304  determines that the system event was not for a RDPS positional attribute change from the location management system, then processing continues to block  1318 . If block  1318  determines that the system event is a transmission from the SDPS with content to deliver, or a content delivery indicator to content, then block  1320  performs housekeeping by pruning transmission history data records  970 . Pruning is performed by time, number of entries, or some other criteria. Block  1320  flows to block  1322  where the transmission history data is checked to see if the rec id field  702  for the content or content delivery indicator, communicated with the system event, is already present in a transmission history data record  970 . If the same content was already delivered, a rec id field  976  will match the rec id field  702  for pending presentation. The system event contains parameters including rec id field  702  with an indicator status for allowing the user to retrieve the content at a later time. If block  1324  determines the rec id field  702  of the event is already contained in the transmission history data, then processing continues back to block  1112  with no delivery processing. If block  1324  determines it is not a redundant delivery, then block  1326  communicates with the SDPS for retrieval of the location field  704 , direction field  706 , content type field  710 , short text field  714 , and speed reference info field  716 . Any type of content is presented to the RDPS user interface in the appropriate manner. Various embodiments may limit types of content using a variety of methods, located at the RDPS or SDPS. Additionally, either content field  712  and linked content via content links field  722  is retrieved, or content delivery indicator(s) status is retrieved. Thereafter, block  1328  appends a transmission history data record  970  to the RDPS transmission history data, and processing continues to block  1112 . Blocks  1320  through  1326  handle all content (or indicator) delivery to the RDPS, preferably asynchronously to all other RDPS processing. 
     If block  1318  determines that the system event was not for delivery, then processing stops at block  1330 . 
     An alternative embodiment to  FIG. 13  processing will not check history for redundant content delivery. Or, a user may enable or disable the feature. 
     Block  1326  may also include applying client located filters for filtering out content. In such an embodiment, a filter criteria field  908  may not be required. 
     The user of the RDPS may also modify the transmission history data to allow a redundant refresh. 
       FIG. 14  depicts a flowchart for describing the content administration aspects of the present invention. An administrator, preferably a paying customer with rights to configure the deliverable content database, invokes the present invention administration interface.  FIG. 14  is preferably a public access enabled, internet connected user interface for modifying the deliverable content database. The administrator may act on behalf of a paying customer. Processing begins at block  1402  and continues to block  1404  where the administrator is first authenticated as a valid user to perform administration. Then, block  1406  appropriately initializes the administration interface. Thereafter, block  1408  waits for user action (a user event). Once a user action is detected, processing continues. 
     If block  1410  determines that the administrator selected to list his deliverable content database records  700 , then the deliverable content database is searched using the administrator&#39;s authorization id against the authorization id field  720 . Any deliverable content database records  700  belonging to the administrator are put into a scrollable list at block  1414 , and processing continues back to block  1408 . Options are available for appropriately presenting the content, keywords data record  750 , and linked content via content links field  722 . The scrollable list preferably columnizes the displayable fields  702 ,  704 ,  706 ,  708 ,  710 ,  714 ,  716 ,  718 , and  724 . 
     If block  1410  determines the user did not select to list his deliverable content database configurations, then processing continues to block  1416 . If block  1416  determines that the user selected to delete a deliverable content data record  700  from the scrollable list, then block  1418  deletes the record  700  from the content deliverable database along with any associated keywords data record  750 , and linked content via content links field  722 . Thereafter, block  1420  updates the scrollable list data, and processing continues back to block  1414 . 
     If block  1416  determines that the administrator did not select to delete, then processing continues to block  1422 . If block  1422  determines the administrator selected to add a deliverable content database record  700 , then block  1424  interfaces with the administrator for validated entry. Thereafter, block  1426  generates a unique number record identifier for rec id field  702 , block  1428  inserts into the deliverable content database, block  1430  inserts any associated keyword data record  750  to the keyword data, and processing continues back to block  1414 . Keywords specification allows associating delivery content to a user&#39;s interests or filters in registration data for establishing a basis of delivery. Block  1424  provides appropriate interfaces for specifying and reviewing all types of content. Block  1428  additionally populates linked content if content links field  722  is used. Once a deliverable content database record  700  is inserted, it is instantly activated for candidate delivery. The delivery is proactive when the RDPS situational location is automatically determined. 
     If block  1422  determines the user did not select to add a deliverable content database record  700 , then processing continues to block  1432 . If block  1432  determines that the user selected to modify location hierarchy data records  800 , then the user modifies the data at block  1436  and processing continues back to block  1408 . If block  1432  determines the user did not select to modify location hierarchy data, then processing continues to block  1434  where other user actions are handled. Other user actions include scrolling, window manipulation, exiting the administration interface, or other navigation not relevant for discussion. Processing then continues back to block  1408 . 
     Preferably, the block  1432  option only presents itself to a special super-user administrator who is unlikely to cause problems for all other administrated configurations. It is very important that all data be maintained with integrity by blocks  1418  and  1428 . For example, a deliverable content database record  700  deleted should not be referenced by transmission history data  940 . The rec id field  702  will no longer be valid.  FIG. 14  processing may include an update deliverable database record option in alternative embodiments. 
       FIGS. 15A ,  15 B, and  15 C depict flowcharts for service event handling aspects of a preferred embodiment of the SDPS of the present invention, in the context of candidate delivery event generation by the RDPS. SDPS processing relevant to the present invention begins at block  1502  when a service event (request) is posted (generated) to the SDPS, and continues to block  1504 . All events are requests containing parameters including at least the device id  902  of the RDPS. Flowchart processing block discussions describe other parameters received, depending on the event (request) type. 
     If block  1504  determines that the event is an RDPS registration request, then block  1506  accesses registration data to see if the RDPS unique device id is already present (i.e. already registered) in a device id field  902 . Thereafter, if block  1508  determines the RDPS does not already have a registration data record  900  registered, then block  1510  inserts a registration data record  900  into registration data. Much of the information may be provided as parameters to the event, or alternatively, block  1506  communicates with the RDPS to gather needed field information. Then, block  1512  provides an acknowledgement to the RDPS, or an error if already registered. Processing continues to block  1514  by way of off page connector  15000 . If block  1514  determines that the RDPS was newly registered (i.e. an error was not provided), then block  1516  searches the deliverable content database for delivery activation setting(s) field  718  with a “deliver on RDPS registration” bit enabled. Thereafter, if block  1517  determines there are deliverable content database records  700  with the bit set, then block  1518  processes applicable content transmission (see  FIG. 16 ), and processing stops at block  1519 . If block  1517  determines that there was no records, then processing stops at block  1519 . If block  1514  determines that the RDPS was already registered (existing entry), then processing continues to block  1519 . Thus, a situational location change may be an RDPS state changed to registered. 
     If block  1504  determines that the event was not a registration request, then processing continues to block  1520 . If block  1520  determines that the event is a de-registration request, then block  1522  access the registration data for the device id field  902  provided with the event parameters, and if block  1524  determines one is found, then it is deleted at block  1526 , and then an acknowledgement is provided at block  1512  with processing continuing from there as was described except block  1516  searches for the “deliver on RDPS termination bit” enabled. If block  1524  determines that a registration data record  900  was not found, then an error is provided at block  1512  and processing continues as previously described. Thus, a situational location change may be an RDPS state changed to terminated. 
     If block  1520  determines that the event was not for an RDPS de-registration, then processing continues to block  1528 . If block  1528  determines that the RDPS user selected to retrieve content for a content delivery indicator previously sent to the RDPS by the SDPS, then block  1530  accesses the deliverable content database by the rec id field  702  provided as parameters to the event, processing continues to block  1532  where the applicable content is processed (see  FIG. 16 ), and processing stops at block  1534 . 
     If block  1528  determines that the event was not an indicator selection request, then processing continues to block  1536 . If block  1536  determines the event is a CADE generated by the RDPS, then block  1538  parses parameters from the request, for example, location and direction. Thereafter, block  1540  completes determination of the situational location from the parameters and converts into a form suitable for searching the deliverable content database. Block  1540  consults location hierarchy data and determines the date/time to further refine the RDPS situational location. Then, block  1544  retrieves deliverable content database records using RDPS parameters and any applicable location hierarchy data records  800  to fields  704 ,  706  and  708 . Also used is data in interests field  906  and filter criteria  908  of the RDPS for comparing against keywords field  754  in keywords data associated with content deliverable database records  700 . Delivery activation setting(s) field  718  is consulted as well. In some embodiments, the capabilities of the RDPS are maintained in field  904  to ensure no content of an inappropriate type is delivered. Thus, field  904  may also be utilized. If block  1546  determines that content was found, then block  1548  prunes transmission history data records  940  (by time, depth of records, etc.), block  1550  accesses the SDPS transmission history data, and block  1552  continues. If block  1552  determines that the content was not already transmitted (device id field  942  and rec id field  948  don&#39;t match any record in transmission history), then processing continues to block  1532  for processing described by  FIG. 16 . If block  1552  determines that the content was transmitted, then processing stops at block  1534 . If block  1546  determines content applies, then processing stops at block  1534 . 
     If block  1536  determines that the event was not a CADE, then processing continues to block  1554  by way of off page connector  15002 . If block  1554  determines that the event is for a situational location query, then block  1556  searches deliverable content database records  700  with parameters from the RDPS: positional attribute parameters from the RDPS with the location field  704  and direction field  706 , time criteria with time criteria field  708 , and so on. All fields associated to record  700  are searchable through parameters. Block  1556  also applies location hierarchy data depending on a zoom specification parameter. The zoom specification allows control over the block  1556  search algorithm for whether or not to use hierarchy data, and whether or not to check descending locations, ascending locations up to a maximum threshold parameter of content, both descending and ascending (respectively) up to a threshold of content, or neither ascending nor descending hierarchy data functionality. The maximum threshold parameter may be specified regardless, and optionally limits the amount of content to deliver to the RDPS by size, number of content instances, or number of hierarchical data record nestings to search. Further still block  1556  may use field  904  as described above, or the user&#39;s interest and/or filters as described above. Information for records found are transmitted as content to the RDPS at block  1558  (see  FIG. 16 ) and processing stops at block  1572 . 
     If block  1554  determines that the event was not a situational location query, then processing continues to block  1562 . If block  1562  determines that the request is a client count query request, then block  1564  retrieves the known number of RDPS devices at the specified situational location (e.g. location/direction) given specified time criteria; the number of transmission history data records  940  for unique values in rec id field  948  that contain a date/time stamp  952  according to the user&#39;s specified time criteria. A null time criteria parameter implies use the current time of processing the request with a truncated precision for a time window. Otherwise, a specified time window was entered by the user, or automatically inserted as a parameter by the RDPS or SDPS. Presence of the content specification parameter implies to additionally retrieve content from the deliverable content database as described by blocks  1538  through  1544 . This allows providing information (e.g. graphical) to complement presentation of the total number of RDPS devices identified. Processing then continues to block  1558  for transmitting the count as content. 
     If block  1562  determines that the event was not a client count query request, then processing continues to block  1570  where any other SDPS event (request) is processed as is appropriate for the particular service application, and processing stops at block  1572 . 
       FIG. 16  depicts a flowchart for describing the content transmission aspects of the present invention.  FIG. 16  describes processing of blocks  1518 ,  1532 ,  1558 ,  2018 ,  2032 , and  2058 . Processing begins at block  1602 , continues to block  1604  where registration data is accessed for communications bind information field  904  that is inserted when the RDPS registers, and then continues to block  1606 . Block  1606  checks the size of the transmission destined for the RDPS. Thereafter, if block  1608  determines that the information is small enough to not worry about transmission, then block  1610  transmits the situational location dependent information using field  904 , block  1612  appends a transmission history data record  940  to transmission history data, and processing stops at block  1616 . Block  1610  may first compress and/or encrypt content transmission for efficient and/or safe communications that is then decompressed and/or decrypted by the RDPS at block  1326 . Content may also by transmitted at block  1610  depending on capabilities of the RDPS maintained in field  904 , for example, transmission speed, memory, storage space, etc. Thus, block  1610  may transmit using transmission delivery constraints of field  904 . 
     If block  1608  determines there may be too much information to unquestionably transmit, then block  1614  transmits content delivery indicator(s) information to the RDPS and processing continues to block  1612 . Thus, the total size of the transmission is a transmission delivery constraint affecting the delivery information of the content. Of course,  FIG. 16  could always transmit an indicator, or a transmission delivery constraint size could be configured to cause content delivery indicators delivered all, or most, of the time. 
     Block  1608  may use a system size setting (e.g. number of bytes), or may use size information relative to RDPS capabilities maintained in communications bind information field  904 . 
     Server Data Processing System Candidate Delivery Event Generation Embodiment 
     The reader should make note of the nearly identical descriptions and enumerations between the figures in different embodiments. The rightmost two digits of the block numbering have been preserved to facilitate correlation.  FIG. 17  correlates  FIG. 11 , and so on.  FIG. 14  and  FIG. 16  are applicable to both embodiments: SDPS CADE generation and RDPS CADE generation. 
       FIG. 17  depicts a flowchart for describing data processing system aspects relevant to a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event generation by the SDPS. When the RDPS is enabled, for example, by a power switch, system manager processing begins at block  1702  and continues to block  1704  where the system appropriately initializes, for example to default interfaces. Processing continues to block  1712 . Block  1712  waits for a user event or system event. User interface management is coupled with the system manager to enable a user to the RDPS. Upon detection of an event, block  1712  flows to block  1714  for any user event management processing. Should block  1714  processing return, block  1716  performs any system event management processing. Should processing of block  1716  return, block  1718  handles the event appropriately as is relevant for other events of the RDPS, for example, user interface control of little interest to discussion of the present invention. Thereafter, block  1718  flows to block  1712  for processing as described. 
     An alternate embodiment of  FIG. 17  will implement a multithreaded system wherein events are handled asynchronously as they occur. 
       FIGS. 18A and 18B  depict flowcharts for describing user event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event generation by the SDPS. User event management begins at block  1802  and continues to block  1804 . If block  1804  determines that the user event is powering the RDPS off, then block  1806  communicates with the SDPS to remove (if any) its RDPS data record  900  from the registration data, block  1808  terminates any communication session gracefully (if required) depending on the RDPS, block  1810  saves settings, for example, the delivery setting for the next power on, and RDPS processing stops at block  1811 . 
     If block  1804  determines the RDPS was not turned off, then processing continues to block  1812 . If block  1812  determines that the user selected to enable communications with the SDPS, then block  1814  establishes communications with the SDPS (if not already established), and block  1816  consults the current delivery setting. In one embodiment, block  1814  through  1820  may be processed just as the result of a wireless device being powered on. If block  1816  determines that the content delivery setting for receiving situational location dependent content is enabled, then block  1818  communicates with the SDPS for inserting a registry data record  900  into the registry data. Thereafter, block  1820  sets a RDPS user interface indicator showing that communications to the SDPS is enabled, and processing returns to block  1712  of  FIG. 17  by way of off page connector  17000 . If block  1816  determines the delivery setting is not enabled, then processing continues to block  1820 . 
     If block  1812  determines that the user did not select to enable communications to the SDPS, then processing continues to block  1822 . If block  1822  determines that the user selected to disable SDPS communications, then block  1824  communicates with the SDPS to remove its registry data record  900  from registry data, block  1826  terminates the communications session gracefully (if required) depending on the RDPS embodiment, block  1828  sets the communications to SDPS user interface indicator to disabled, and processing continues back to block  1712 . In one embodiment, block  1824  through  1828  may be processed just as the result of a wireless device being powered off. 
     If block  1822  determines the user did not select to disable communications to the SDPS, then processing continues to block  1830 . If block  1830  determines that the user selected to modify the RDPS content delivery setting, then the user modifies the setting at block  1832 , the delivery setting is set accordingly at block  1834 . Preferably, blocks  1830 / 1832  allow a user to toggle the content delivery setting. No content will be delivered when this setting is disabled. Being registered with the SDPS constitutes being eligible for delivery. Alternative embodiments won&#39;t have such a feature. Block  1834  also sets an indicator in the user interface for displaying that setting, and block  1836  communicates with the SDPS to insert or remove its registry data record  900  should the setting be different than previous. Of course, appropriate error handling is performed by block  1836  if there is no communications enabled. Thereafter, processing continues to block  1712 . 
     If block  1830  determines that the user did not select to modify the content delivery setting, then processing continues to block  1844 . If block  1844  determines that the user selected a content delivery indicator, as maintained in a transmission history data record  970  for deliverable content from the SDPS, then block  1846  communicates with the SDPS using the rec id field  976 . In one embodiment, the user peruses the transmission history data in response to receiving a content delivery indicator from the SDPS. In another embodiment, correlation is maintained between individual user interface indicators to their associated transmission history data record  970  for allowing the user to simply select the indicator in the user interface for communicating with the SDPS to deliver the associated content. Providing a visual and/or audible presentation of the indicator is well known in the art and may be implemented with a variety of methods. Block  1846  makes the request for content to the SDPS with the rec id  976 . Thereafter, via a received system event, blocks  1918  through  1926  handle receipt, delivery, and RDPS user interface presentation of the content in a manner appropriate to the content type from the SDPS. Processing continues from block  1846  back to block  1712 . 
     If block  1844  determines that the user did not select an indicator of deliverable content, then processing continues to block  1850  by way of off page connector  18000 . If block  1850  determines that the user selected to configure interests or filters, then block  1852  interfaces with the user to configure interests or filters which are saved locally at block  1854 , and processing continues back to block  1712  by way of off page connector  17000 . Any configured interests and filters are communicated to the SDPS at blocks  1818  and  1836  as part of registration. Interests field  906  and filter criteria field  908  are set with data configured at block  1852 . The RDPS must de-register and re-register with new settings. In an alternative embodiment, block  1854  communicates with the SDPS to update the RDPS&#39; registry data record  900 . 
     If block  1850  determines that the user did not select to configure interests or filters, then processing continues to block  1856 . If block  1856  determines the user selected to perform a situational location query, then the user specifies validated parameters (discussed with  FIG. 20B ) at block  1858 . Thereafter, block  1860  communicates an appropriate formatted request to the SDPS, and thereafter via a received system event, blocks  1918  through  1926  handle receipt, delivery, and RDPS user interface presentation of the content in a manner appropriate to the content type from the SDPS. Processing leaves block  1860  and returns to block  1712 . 
     If block  1856  determines that the user did not select to perform a situational location query, then processing continues to block  1864 . If block  1864  determines that the user selected to query the number of known RDPS devices at a location(s) (i.e. a client count request), then block  1866  interfaces with the user to specify valid parameters including situational location information and time criteria, and processing continues to block  1860  which was described. A content specification parameter may also be specified for retrieving the situational location content as well. Time criteria embodiments include any time window in history, a current time window (of request, transmission of request, SDPS receipt of request, or processing the request), or a truncated precision time. If block  1864  determines that the user did not select to query the number of RDPS devices at a location(s) (i.e. a client count request), then processing continues to block  1868 . If block  1868  determines that the user selected to browse transmission history data, then block  1870  interfaces with the user until he either exits, or selects information from the speed reference information field  978  from a transmission history data record  970 . Preferably, block  1870  permits scrolling transmission history data records  970  with fields columnized. If, at block  1872 , the user selected information of field  978 , then block  1874  automatically performs the action, an automatic dialing of a telephone number, or automatic transposition to a web page. Speed reference information field  978  is preferably related to content that was delivered as referenced by rec id field  976 . Thereafter, processing continues back to block  1712 . If block  1872  determines that the user exited from block  1870 , then processing continues back to block  1712 . 
     If block  1868  determines that the user did not select to browse the transmission history data, then processing stops at block  1876 . 
     Note that some RDPS embodiments will not require blocks  1812  through  1828  because there may not be an active session required to have communications between the RDPS and SDPS. In one embodiment, the movement tolerance is communicated to the SDPS at blocks  1818  and  1836 , and then inserted to movement tolerance field  910 . 
       FIG. 19  depicts a flowchart for describing system event management processing aspects of a preferred embodiment of the RDPS of the present invention, in the context of candidate delivery event generation by the SDPS. System event management begins at block  1902 , and continues to block  1918 . If block  1918  determines that the system event is a transmission from the SDPS with content to deliver, or a content delivery indicator to content, then block  1920  performs housekeeping by pruning transmission history data records  970 . Pruning is performed by time, number of entries, or some other criteria. Block  1920  flows to block  1922  where the transmission history data is checked to see if the rec id field  702  for the content or content delivery indicator, communicated with the system event, is already present in a transmission history data record  970 . If the same content was already delivered, a rec id field  976  will match the rec id field  702  for pending presentation. The system event contains parameters including rec id field  702  with an indicator status for allowing the user to retrieve the content at a later time. If block  1924  determines the rec id field  702  of the event is already contained in the transmission history data, then processing continues back to block  1712  with no delivery processing. If block  1924  determines it is not a redundant delivery, then block  1926  communicates with the SDPS for retrieval of the location field  704 , direction field  706 , content type field  710 , short text field  714 , and speed reference info field  716 . Any type of content is presented to the RDPS user interface in the appropriate manner. Various embodiments may limit types of content using a variety of methods, located at the RDPS or SDPS. Additionally, either content field  712  and linked content via content links field  722  are retrieved, or content delivery indicator status is retrieved. Thereafter, block  1928  appends a transmission history data record  970  to the RDPS transmission history data, and processing continues to block  1712 . Blocks  1920  through  1926  handle all content (or indicator) delivery to the RDPS, preferably asynchronously to all other RDPS processing. 
     If block  1918  determines that the system event was not for delivery, then processing stops at block  1930 . 
     An alternative embodiment to  FIG. 19  processing will not check history for redundant content delivery. Or, a user may enable or disable the feature. 
     Block  1926  may also include applying client located filters for filtering out content. In such an embodiment, a filter criteria field  908  may not be required. 
     The user of the RDPS may also modify the transmission history data to allow a redundant refresh. 
       FIGS. 20A ,  20 B, and  20 C depict flowcharts for service event handling aspects of a preferred embodiment of the SDPS of the present invention, in the context of candidate delivery event generation by the SDPS. SDPS processing relevant to the present invention begins at block  2002  when a service event (request) is posted (generated) to the SDPS, and continues to block  2004 . All events are requests containing parameters including at least the device id  902  of the RDPS. Flowchart processing block discussions describe other parameters received, depending on the event (request) type. 
     If block  2004  determines that the event is an RDPS registration request, then block  2006  accesses registration data to see if the RDPS unique device id is already present (i.e. already registered) in a device id field  902 . Thereafter, if block  2008  determines the RDPS does not already have a registration data record  900  registered, then block  2010  inserts a registration data record  900  into registration data. Much of the information may be provided as parameters to the event, or alternatively, block  2006  communicates with the RDPS to gather needed field information. Then, block  2012  provides an acknowledgement to the RDPS, or an error if already registered. Processing continues to block  2014  by way of off page connector  20000 . If block  2014  determines that the RDPS was newly registered (i.e. an error was not provided), then block  2016  searches the deliverable content database for delivery activation setting(s) field  718  with a “deliver on RDPS registration” bit enabled. Thereafter, if block  2017  determines there are deliverable content database records  700  with the bit set, then block  2018  processes applicable content transmission (see  FIG. 16 ), and processing stops at block  2019 . If block  2017  determines that there was no records, then processing stops at block  2019 . If block  2014  determines that the RDPS was already registered (existing entry), then processing continues to block  2019 . Thus, a situational location change may be an RDPS state changed to registered. 
     If block  2004  determines that the event was not a registration request, then processing continues to block  2020 . If block  2020  determines that the event is a de-registration request, then block  2022  access the registration data for the device id field  902  provided with the event parameters, and if block  2024  determines one is found, then it is deleted at block  2026 , and then an acknowledgement is provided at block  2012  with processing continuing from there as was described except block  2016  searches for the “deliver on RDPS termination bit” enabled. If block  2024  determines that a registration data record  900  was not found, then an error is provided at block  2012  and processing continues as previously described. Thus, a situational location change may be an RDPS state changed to terminated. 
     If block  2020  determines that the event was not for an RDPS de-registration, then processing continues to block  2028 . If block  2028  determines that the RDPS user selected to retrieve content for a content delivery indicator previously sent to the RDPS by the SDPS, then block  2030  accesses the deliverable content database by the rec id field  702  provided as parameters to the event, processing continues to block  2032  where the applicable content is processed (see  FIG. 16 ), and processing stops at block  2034 . 
     If block  2028  determines that the event was not an indicator selection request, then processing continues to block  2036 . If block  2036  determines the event is a CADE generated by a service of, or to, the SDPS (see  FIG. 3B ,  FIG. 5B , and  FIG. 6 ), then block  2038  parses parameters from the request, for example, location and direction. Thereafter, block  2040  completes determination of the situational location from the parameters and converts into a form suitable for searching the deliverable content database. Block  2040  consults location hierarchy data and determines the date/time to further refine the RDPS situational location. Then, block  2044  retrieves deliverable content database records using RDPS parameters and any applicable location hierarchy data records  800  to fields  704 ,  706  and  708 . Also used is data in interests field  906  and filter criteria  908  of the RDPS for comparing against keywords field  754  in keywords data associated with content deliverable database records  700 . Delivery activation setting(s) field  718  is consulted as well. In some embodiments, the capabilities of the RDPS are maintained in field  904  to ensure no content of an inappropriate type is delivered. Thus, field  904  may also be utilized. If block  2046  determines that content was found, then block  2048  prunes transmission history data records  940  (by time, depth of records, etc.), block  2050  accesses the SDPS transmission history data, and block  2052  continues. If block  2052  determines that the content was not already transmitted (device id field  942  and rec id field  948  don&#39;t match any record in transmission history), then processing continues to block  2032  for processing described by  FIG. 16 . If block  2052  determines that the content was transmitted, then processing stops at block  2034 . If block  2046  determines content applies, then processing stops at block  2034 . 
     If block  2036  determines that the event was not a CADE, then processing continues to block  2054  by way of off page connector  20002 . If block  2054  determines that the event is for a situational location query, then block  2056  searches deliverable content database records  700  with parameters from the RDPS: positional attribute parameters from the RDPS with the location field  704  and direction field  706 , time criteria with time criteria field  708 , and so on. All fields associated to record  700  are searchable through parameters. Block  2056  also applies location hierarchy data depending on a zoom specification parameter. The zoom specification allows control over the block  2056  search algorithm for whether or not to use hierarchy data, and whether or not to check descending locations, ascending locations up to a maximum threshold parameter of content, both descending and ascending (respectively) up to a threshold of content, or neither ascending nor descending hierarchy data functionality. The maximum threshold parameter may be specified regardless, and optionally limits the amount of content to deliver to the RDPS by size, number of content instances, or number of hierarchical data record nestings to search. Further still block  2056  may use field  904  as described above, or the user&#39;s interest and/or filters as described above. Information for records found is transmitted as content to the RDPS at block  2058  (see  FIG. 16 ) and processing stops at block  2072 . 
     If block  2054  determines that the event was not a situational location query, then processing continues to block  2062 . If block  2062  determines that the request is a client count query request, then block  2064  retrieves the known number of RDPS devices at the specified situational location (e.g. location/direction) given specified time criteria; the number of location history data records  920  for unique values in rec id field  922  that contain a date/time stamp  930  according to the user&#39;s specified time criteria. A null time criteria parameter implies use the current time of processing the request with a truncated precision for a time window. Otherwise, a specified time window was entered by the user, or automatically inserted as a parameter by the RDPS or SDPS. Presence of the content specification parameter implies to additionally retrieve content from the deliverable content database as described by blocks  2038  through  2044 . This allows providing information (e.g. graphical) to complement presentation of the total number of RDPS devices identified. Processing then continues to block  2058  for transmitting the count as content. 
     If block  2062  determines that the event was not a client count query request, then processing continues to block  2070  where any other SDPS event (request) is processed as is appropriate for the particular service application, and processing stops at block  2072 .  FIG. 16  depicts a flowchart for describing the content transmission aspects.  FIG. 16  describes processing of blocks  2018 ,  2032 , and  2058 . 
     In any of the embodiments described above, a performance conscious implementation of the present invention including a cache may be pursued given the RDPS has appropriate capability. Without departing from the spirit and scope of the invention, deliverable content database records  700 , and joined data from them, may be stored at an RDPS. The SDPS may transmit a compression of the data to the RDPS for decompression and local maintaining. Transmission may be at registration and/or performed asynchronously to the RDPS as necessary. Thus, the deliverable content database, and joined data from it, will be accessed locally to the RDPS to prevent real-time communication of what could be large amounts of content.  FIG. 14  processing would include updating any RDPS with a local cache when configuration was complete. 
     While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention 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.

Metadata:
Filing Date: 20070606
Publication Date: 20130917
Grant Date: 20130917
Priority Date: 20000607
Inventors: JOHNSON WILLIAM J.
Assignee: APPLE INC
CPC Classifications: [{"code": "G01S2205/02", "inventive": false, "first": false, "tree": "[]"}, {"code": "G01S5/02", "inventive": false, "first": false, "tree": "[]"}, {"code": "G01S2205/02", "inventive": false, "first": false, "tree": "[]"}, {"code": "G01S5/02", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L67/54", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L67/54", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L67/52", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L67/52", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/021", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F16/972", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F16/9537", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L67/04", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F16/958", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/33", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F16/9535", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F16/9537", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q30/02", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M3/4878", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M3/4878", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q30/02", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W24/00", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F16/9535", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F16/958", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F16/444", "inventive": true, "first": false, "tree": "[]"}, {"code": "Y10S707/99945", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W4/02", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/021", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L69/329", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q30/0277", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M2242/15", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L67/04", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M2242/30", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W4/024", "inventive": false, "first": false, "tree": "[]"}, {"code": "Y10S707/99952", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W4/024", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04M3/42348", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q30/0261", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M2242/30", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04M2242/15", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F16/972", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q30/0239", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F16/444", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L69/329", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/027", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M2242/14", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W4/029", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/33", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06Q30/0239", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06Q30/0277", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M2242/14", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W4/027", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04M3/42348", "inventive": true, "first": false, "tree": "[]"}, {"code": "Y10S707/99953", "inventive": false, "first": false, "tree": "[]"}, {"code": "Y10S707/99948", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06Q30/0261", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 24357554