Location based service provider Number:7,386,318 from the United States Patent and Trademark Office (PTO) owispatent

Title: Location based service provider

Abstract: The disclosed method and system provide extensible or stand-alone location enabled services at granularity down to a stand-alone service. The various interfaces are preferably specified via DTD or schemas for communication based on XML. This collection of services enables management of mobile device locations information, and real-time services. Mobile device location is integrated with other location sensitive data, such as maps or demographics of a particular region or even the location of businesses and consumers to enable a richer service offering for customers of wireless carriers and service providers. Examples of such services include obtaining routes to a destination; providing a geocode corresponding to an address; providing an address corresponding to a geocode; providing maps as image files encompassing specified geocodes, locations, or addresses and the like. Additional services may be added to the disclosed system and method seamlessly due to the use of extensible interfaces.

Patent Number: 7,386,318 Issued on 06/10/2008 to Moon,   et al.

---

Inventors:	Moon; George Christopher (Aurora, CA), Li; Xiang (Scarborough, CA), Petronis; Scott (Rexford, CA), Berrill; Arthur R. (Goodwood, CA), Tweedie; Matthew W. (Delmar, NY), Dove; John L. (East Greenbush, NY), Dewald; Edward T. (East Greenbush, NY)
Assignee:	Pitney Bowes MapInfo Corporation (Troy, NY)
Appl. No.:	10/392,370
Filed:	March 19, 2003

---

Related U.S. Patent Documents

---

	Application Number	Filing Date	Patent Number	Issue Date
	60365820	Mar., 2002
	60378805	May., 2002
	60411435	Sep., 2002

---

Current U.S. Class:	455/456.3 ; 455/414.1; 455/456.2
Field of Search:	455/456.3,456.1,414.1,414.3

---

References Cited [Referenced By]

---

U.S. Patent Documents

6944447	September 2005	Portman et al.
2002/0055852	May 2002	Little et al.
2002/0160766	October 2002	Portman et al.
2003/0036379	February 2003	Nikolai et al.

Foreign Patent Documents

	1 320 270		Jun., 2003		EP

Other References

International Search Report, no date listed. cited by other . Xmarc News dated Mar. 20, 2001. cited by other.

Primary Examiner: Gary; Erika A.

---

Parent Case Text

---

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit, under 35 U.S.C. .sctn.119, of U.S. Provisional Patent Application Nos. 60/365,820, 60/378,805, and 60/411,435 filed on Mar. 19, 2002, May 7, 2002, and Sep. 7, 2002, respectively, which applications are incorporated herein by reference in their entirety.

---

Claims

---

The invention claimed is:

1. An integrated system for providing geographical locations based services to clients, the system comprising: a networked routing manager module for receiving a request from a client; a plurality of response modules registered with the routing manager for receiving one or more types of service requests, the service requests including obtaining one or more records containing a geocode corresponding to an address, an address corresponding to a geocode; a route to a destination, a position for a mobile device, identity of a location, one or more geographic features near a location; and a person profile data; a plurality of spatial servers in communication with one or more of said plurality of response modules to provide spatial information and to allow said plurality of response modules to communicate with one another; and an interface for adding response modules, the interface registering an added response module to the plurality of response modules registered with the routing manager, wherein the routing manager forwards the received request to at least two of said plurality of response modules, said at least two of said plurality of response modules communicate with one another regarding the received request and receive spatial information from at least one of said plurality of spatial servers in response to said request, and one of said at least two of said plurality of response modules generates and sends a response corresponding to the request to said routing manager to be forwarded to the client.

2. The system of claim 1, further comprising response modules for mapping, coordinate geometry service for carrying out geometric calculations and measurements, coordinate transformations, providing traffic related information, generating entelrrise specific maps; and providing an enterprise profile.

3. The system of claim 1, wherein at least one of the request and the response is encoded in a markup language.

4. The system of claim 1 further comprising one or more third party servers in communication with one or more of the response modules from the plurality of response modules, wherein the one or more response modules receive requested third party information.

5. The system of claim 1, wherein each of the plurality of response modules has a unique name for registering a service with the routing manager.

6. The system of claim 5, wherein each of the response modules presents at least one interface for interacting with the routing manager whereby the routing manager initializes or closes a selected response module, parses and publishes a request document, and handles results of a received request.

7. The system of claim 1, wherein the request received by the routing manager from a first network address results in the response being directed to a second network address.

8. The system of claim 1, wherein the response containing nearest geographic features includes an instruction or a link for accessing a network address corresponding to at least one geographic feature.

9. The system of claim 8, wherein the at least one geographic feature is an address of a location-based-information-system server associated with a user location, and the location-based-information-system server also provides personalization data as part of the person profile service.

10. The system of claim 9, wherein the location-based-information-system server also provides links to one or more local servers, associated with the user location, corresponding to input profile data or a user profile.

11. The system of claim 9 wherein the location-based-information-system server redirects a user to a first local server, or provides a choice of local servers.

12. The system of claim 11, wherein the first local server has additional user profile information.

13. The system of claim 11, wherein the first local server provides information about one or more of sales, promotions, availability of a product or service, alternative sellers of a specified product close to the user location, or alternative providers of a specified service close to the user location.

14. The system of claim 9 further comprising a user interface responsive to one or more taps or strokes on a pad, one or more clicks of an input device, or a voice command.

15. A user interface for navigating through a plurality of location based services to accumulate data for a task requiring results from two or more services, said interface comprising: a system for providing geographical locations based services to clients comprising: a networked routing manager module for receiving a request from a client; a plurality of response modules registered with the routing manager for receiving one or more types of service requests, the service requests including obtaining one or more records containing a geocode corresponding to an address, an address corresponding to a geocode; a route to a destination, a position for a mobile device, identity of a location, one or more geographic features near a location, and person profile data; a plurality of spatial servers in communication with one or more of said plurality of response modules to provide spatial information and to allow said plurality of response modules to communicate with one another; and a first interface for adding response modules, the first interface registering an added response module to the plurality of response modules registered with the routing manager, wherein the routing manager forwards the received request to at least two of said plurality of response modules, said at least two of said plurality of response modules communicate with one another regarding the received request and receive spatial information from at least one of said plurality of spatial servers in response to said request, and one of said at least two of said plurality of response modules generates and sends a response corresponding to the request to said routing manager to be forward to the client, the response contains nearest geographic features including an instruction or a link for accessing a network address corresponding to at least one geographic feature, the at least one geographic feature is an address of a location-based-information-system server associated with a user location, and the location-based-information-system server also provides personalization data as part of the person profile service, and the first local server provides information about one or more of sales, promotions, availability of a product or service, alternative sellers of a specified product close to the user location, or alternative providers of a specified service close to the user location.

16. The user interface of claim 15, further comprising navigation through sales, promotions, products, services, or events associated with a user profile or preference, the navigation being via one or more of choosing a location from a sorted list, selecting one or more entries corresponding to products or services, and requesting/receiving directions to a selected location.

17. The user interface of claim 16, further comprising functionality for navigation backwards to visit a previously presented screen.

18. The user interface of claim 16, wherein one or more of the sales, promotions, products, services, or events are presented to the user as a sorted list.

19. The user interface of claim 18, wherein the sorted list is based on one or more of attribute values matching with the user profile or preference.

20. The user interface of claim 18, wherein each of said events presented to the user is associated with values of a plurality of event attributes, and each user profile comprises values of a plurality of profile attributes, wherein one or more of the event and profile attributes are weighted to reflect their relative significance followed by the generation of a similarity score based on shared attributes and their respective weights.

21. The user interface of claim 20, wherein the profile attributes are standardized, based on their distribution in a reference database.

---

Description

---

FIELD OF THE INVENTION

The present invention pertains generally to the field of location-based information systems.

BACKGROUND

Advances in telecommunications technology have enabled faster and more accurate location of users carrying mobile devices. Examples of such technology are described in U.S. Pat. Nos. 6,477,362 and 6,477,379, both issued on Nov. 5, 2002, which patents are incorporated herein by reference in their entirety. These patents respectively describe systems for directing emergency services to a user based on her or his location and for locating a mobile device with the aid of two base stations.

Global Positioning Systems (GPS) receivers are described in several publications and references, such as the U.S. Pat. No. 5,528,248, issued on Jun. 18, 1996, which is hereby incorporated by reference herein in its entirety. This patent discloses a personal Digital Location Assistant based on a GPS Smart Antenna and a computing device.

GPS utilizes signals transmitted by a number of in-view satellites to determine the location of a GPS antenna which is connected to a receiver. Each GPS satellite transmits two coded L-band carrier signals which enable some compensation for propagation delays through the ionosphere. Each GPS receiver contains an almanac of data describing the satellite orbits and uses ephemeris corrections transmitted by the satellites themselves. Satellite to antenna distances may be deduced from time code or carrier phase differences determined by comparing the received signals with locally generated receiver signals. These distances are then used to determine antenna position. Only those satellites which are sufficiently above the horizon can contribute to a position measurement, the accuracy of which depends on various factors including the geometrical arrangement of the satellites at the time when the distances are determined.

Distances measured from an antenna to four or more satellites enable the antenna position to be calculated with reference to the global ellipsoid WGS-84. Local northing, easting and elevation coordinates can then be determined by applying appropriate datum transformation and map projection. By using carrier phase differences in any one of several known techniques, the antenna location can be determined to an accuracy on the order of .+-0.1 cm.

Locations may be specified by various means, both actual and representational, including geocodes, centroids, and street vectors/segments. These and other terms are used by various technologies to provide systems and methods for delivering spatially-dependent services.

A geocode is a specification of a position using a suitable coordinate system and at a granularity that is sufficient for a particular application. For example, a geocode specifying a latitude and a longitude specifies a position on the surface of the earth. A geocode may also specify a height above the surface of the earth. A geocode encompasses providing spatial information in a form other than specifying the longitude and the latitude. Other examples of geocodes include postal centroids that are associated with areas sharing a common zip code. A centroid is a geographic center of an entire area, region, boundary, etc. for which the specific geographic area covers. A familiar example is the association between a centroid and a postal code, such as the ZIP codes defined and used by the United States Postal Service.

Street vectors are address ranges assigned to segments of individual streets. Street vectors assist in displaying digitized computer-based street maps. Often, street vectors appear as left and right side address ranges, and may be also used for geocoding a particular address to a particular street segment.

Geocoding is described in U.S. Pat. No. 6,101,496 issued on Aug. 8, 2000, and assigned to the assignee of the present application, which patent is incorporated herein by reference in its entirety. In the context of spatially meaningful databases, geocoding is the act, method or process of assigning x and y coordinates (usually but not limited to latitude and longitude) to records, lists and files containing location information (full addresses, partial addresses, zip codes, census FIPS codes, etc.) for cartographic or any other form of spatial analysis or reference. Geocoding encompasses assigning spatial parameters to data to visualize information and exploring relationships based on spatial distribution. Some examples include census data or survey data that identify the residences of individuals with a particular income bracket, ethnicity, political affiliations, employment, and the like.

Geocoding is often performed by running ungeocoded (referred to hereafter as "raw data") information such as a list of customers through software and/or data which performs table lookup, fuzzy logic and address matching against an entire "library" of all known or available addresses (referred to hereafter as "georeferenced library") with associated x,y location coordinates.

A georeferenced library may be compiled from a number of varied sources including US Census address information and US postal address information, along with Zip Code boundaries and other various sources of data containing geographic information and/or location geometry. If a raw data address cannot be matched exactly to a specific library street address (known as a "street level hit"), then an attempt may be made to match the raw data address to geographic hierarchy of point, line or region geography of ever decreasing precision until a predetermined tolerance for an acceptable match is met. The geographic hierarchy to which a raw data record is finally assigned is also known as the "geocoding precision." Geocoding precision tells how closely the location assigned by the geocoding software matches the true location of the raw data. Geocoding technology generally provides for two main types of precision: street level and postal ZIP centroid. Street level precision is the placement of geocoded records at the street address. Street level precision attempts to geocode all records to the actual street address. In all likelihood, some matches may end up at a less precise location such as a ZIP centroid (ZIP+4, ZIP+2, or ZIP code) or shape path (the shape of a street as defined by points that make up each segment of the street.

One form of spatial indexing for storing and accessing location sensitive information in databases is disclosed by U.S. Pat. No. 6,363,392 issued on Mar. 26, 2002, which is hereby incorporated by reference it its entirety. This patent uses quad keys to provide a flexible, web-sharable database with proximity searching capability. The process for generating quad keys begins with geocoding where a description of a geographic location is converted into a longitude and latitude, which may be represented as integers at some resolution. Then, a quad key is generated in binary form, with the bits interleaved (most significant bit (MSB) from x, followed by MSB from y, followed by next-MSB from x, next-MSB from y, etc.).

Various technologies for providing location information include triangulation using radio signals, global positioning systems ("GPS"), and other technologies described in U.S. Pat. Nos. 5,528,248 and 6,477,379. U.S. patent application Ser. No. 10/159,195 filed on May 31, 2002 discloses a method and system for obtaining geocodes corresponding to addresses and addresses corresponding to geocodes. This application claims the benefit of the disclosure and filing date of U.S. Provisional Patent Application No. 60/256,103 filed on May 31, 2001. These patent applications are also incorporated herein by reference in their entirety. These and other means for determining position, including those developed subsequent to this invention, may be used to provide location information.

In another aspect, it should be noted that the term "interface" is commonly used in describing software and devices. For clarity, as used herein the term "interface" differs from a "user interface" in that a user interface is a presentation made to a user offering various choices, information, and operable elements such as buttons, knobs, and the like. A user interface may include physical components as well as transient displayed information. An interface, in contrast, in the context of object oriented ("OO") languages represents methods that are supported either by the interface itself in some OO languages, or provided in the interface as abstract methods which are provided by classes implementing the interface. A familiar example of the latter kind of OO paradigms is JAVA, which allows platform independent coding of software.

SUMMARY OF THE INVENTION

A method and system are disclosed for providing extensible or stand-alone location enabled services. The disclosed method and system provide services that may also utilize the internet using an eXtensible Markup Language Application Interface (XML-API). These services enable a collection of applications to manage information specific to mobile locations, provide services, including real-time services, with complete or partial integration via a common service manager. Preferably, the XML-API forms a platform that ties together the key services commonly used in the development of these mobile location applications.

In the context of cellular networks and their integration into web-based communication, mobile location is integrated with other location sensitive data, such as maps or demographics of a particular region or the location of businesses and consumers to enable a richer service offering for customers of wireless carriers and service providers.

Examples of such services may include obtaining one or more routes between a starting point and a destination; providing a geocode corresponding to an address; providing an address corresponding to a geocode; providing maps as image files encompassing specified geocodes, locations, or addresses; obtaining a position for a mobile device; obtaining the identity of a location; obtaining one or more geographic features near a location; managing person profile data; providing a map corresponding to a location; providing a coordinate geometry service for carrying out geometric calculations and measurements; performing coordinate transformations; providing traffic related information; generating enterprise specific maps; and providing an enterprise profile.

Additional services may be added to the disclosed system and method. Moreover, although the illustrative embodiments disclose integration of the various services, they may be offered at various levels of granularity down to offering stand-alone services or any combination of services.

DETAILED DESCRIPTION OF THE FIGURES

FIG. 1 is an illustration of an exemplary context for providing an integrated location-based service platform.

FIG. 2 is a schematic representation of an integrated location-based service platform.

FIG. 3 is an illustration of various interactions at a service manager in the course of providing services via an integrated location-based service platform.

FIG. 4 is an illustration of an integrated location-based service platform along with the various service provider modules, spatial servers accessed by the service provider modules, third party servers and data repositories used to respond to service requests.

FIG. 5 is an illustration of an integrated location-based service platform for providing location based services that integrate the London subway with vehicular traffic routes and pedestrian traffic routes.

FIG. 6 is an illustrative embodiment of the present invention that includes a communication system comprising a central server and a peer-to-peer location-information based information system.

FIG. 7 is an illustration of the interactions between a mobile user and a peer-to-peer system for providing location based services.

FIG. 8 further illustrates interactions between a client and an integrated location-based service platform performing multiple functions

FIG. 9 illustrates storage of sale and authorization information in a location based system that allows secure access and public access with more limited privileges.

FIG. 10 is a flow chart indicating the actions available to a store administrator.

FIG. 11 is a flow chart indicating the actions available to a user who has been provided with a list of local-content servers.

FIG. 12 shows the Java panels corresponding to the various steps described in FIG. 11.

FIG. 13 shows a user interface viewed by a user upon starting a mall and store browsing application on his mobile device.

FIG. 14 shows a user interface displaying a list of local-content servers serving the user's location.

FIG. 15 shows a user interface that allows the user to indicate whether the user wishes to enter a store name, or to select a store by specifying a product.

FIG. 16 shows a user interface that allows the user to indicate whether the user wishes to enter a product name, or to select a product by category.

FIG. 17 shows a user interface displaying categories of items for which a mall-server contains sale information.

FIG. 18 shows a user interface displaying a list of stores having sale items in a mall-server database in the category selected by the user.

FIG. 19 shows a user interface displaying sale items in a local-content server database for the specific store.

FIG. 20 shows a user interface displaying information about a sale item selected by the user.

FIG. 21 shows a user interface displaying a map showing the location of a store relative to the user.

FIG. 22 shows a user interface displaying a map zoomed-in to show the store location in more detail.

FIG. 23 illustrates an exemplary architecture for an embodiment of the location sensitive event service.

FIG. 24 provides another illustration of an architecture providing a location sensitive event service.

FIG. 25 summarizes an illustrative process for generating ordered lists of events corresponding to user profiles.

DETAILED DESCRIPTION OF THE INVENTION

A method and system for providing one or more location-based services with the aid of a markup language based interface with one or more service managers and access to one or more databases is disclosed. The method and system are typically, but not as a requirement for practicing the invention, implemented via at least one server, possibly in the form of a servlet, and a database that in combination with specified location information, enables delivery of customized services, options, and offers to customers. The method and system extend the advances made in determination of location of mobile users to offer customized location-based services. In addition, these services also integrate, when desirable, demographic data to generate services suited to various demographic segments and markets. Such demographic data includes user preferences, geographical distribution of users, mobility patterns and the like. These and other applications, including stand alone and integrated implementations, are described by way of the following examples and exemplary embodiments, starting with a description of an integrated implementation that allows one or more location-based services to be offered to users.

An Integrated Location-Based Service Platform

The method and system of the present invention leverage wired and/or wireless connectivity, including that over the Internet, to provide services of interest to consumers. A preferred embodiment of the present invention includes providing an integrated location-based service platform, an example of which is the miAware.TM. set of services provided by the MapInfo.RTM. Corporation of Troy, NY as part of its Mobile Location Services (MLS). miAware.TM. includes an XML based API that enables both implementation and efficient communication of various requests and responses as described at, milocate.mapinfo.com/miAware/, a copy of which, dated Mar. 19, 2003, is attached as APPENDIX to this application.

An integrated location-based service platform is also described in the U.S. Provisional Patent Application No. 60/365,820 filed on Mar. 19, 2002, which is incorporated herein by reference in its entirety.

Such an integrated location-based service platform, for instance, the miAware.TM., provided by the MapInfo.RTM. Corporation of Troy, NY, provides numerous services and facilities including providing a route to a target, finding a nearest specified type of target, geocoding, geodecoding, and determining a mobile position service for a person with a mobile device such as a GPS or cell phone and the like. These services are accessed via user interfaces and underlying XML APIs.

FIG. 1 illustrates a typical context for providing an integrated location-based service platform. Users 100, including mobile users, access via antenna 105 gateway 110 and location server 115. Location server 115 may further connect to the Internet 120 or to portal platform 125 to provide an integrated location-based service platform.

FIG. 2 illustrates a schematic representation of an integrated location-based service platform. Client requests 200 are directed to service manager 205, which is in contact with a service catalogue 210 containing a description of various services available via service manager 205. The service catalogue is preferably in the form of document-type definitions ("DTD") or a schema (e.g., specified under the OpenLS standard), or any other suitable format specifying the form of requests and responses for obtaining a particular service. This enables a client request to be formatted for proper parsing and processing. Typically requests are sent encoded in a markup language such as XML. Such use of a markup language allows a large number of interfaces to be provided to a variety of services at a common portal, service manager 205. Preferably, communications by various services 215, as part of service provider level 220, with service manager 205 are also encoded in a markup language in accordance with a DTD specification that requires support for resource management and methods for starting and terminating a particular module with support for multi-threading. This enables a service to register itself with service manager 205 and publish itself to service catalogue 225, where it may be discovered, along with the syntax for service requests directed to the service, by client requests directed to the service catalogue 225. This architecture makes the integrated location-based service platform flexible since various different services may be added or removed from the integrated location-based service platform to provide customized services. With the ease of adding new services or terminating existing services, the integrated location-based service platform provides a common platform for accessing a variety of location-based services. It should be noted that many of the services accessed through service manger 205 may also be provided as stand alone services, possibly concurrently with providing access via service manager 205.

FIG. 3 provides an illustration of various interactions at a service manager in the course of providing services via an integrated location-based service platform. Service request 305 elicits service response 310 to client 300. Advantageously, service request 305 and response 310 may be transmitted via a network, such as Internet 315, to service manager 320. Service manager 320 has integrated location-based service platform configuration information 325, as well as information about the various available services in service catalogue 330. In response to receiving service request 305, service manager 320 generates service object 335, which is directed to service provider interface 340 specified in service request 305. Service response object 345 generated by the service provider via service provider interface 340 is sent to service manager 320, which in turn, generates service response 310 directed to client 300.

FIG. 4 illustrates an integrated location-based service platform along with various service provider modules, spatial servers accessed by the service provider modules, third party servers and data repositories used to respond to service requests. Request 400 from client 405 is received at integrated location-based service platform server 410 via service provider interface 415. Service provider interface 415 directs request 400 to one of service modules providing services for positioning 420, coordinate system transformation 425, position refinement 430, finding location 435, geodecoding 440, profiling 445, geocoding 450, Cogo 455 (coordinate geometry service), finding nearest geographical of interest 460, mapping 465, routing 470, and administration 475. As illustrated, although not as a requirement for practicing the invention, service modules: position refinement 430, finding location 435, geodecoding 440, finding nearest geographical of interest 460, and mapping 465 communicate with spatial server 480, which may be a MapXtreme.RTM. Server provided by Mapinfo.RTM. Corporation, accessing in turn relational database 482. Similarly, routing 470 accesses routing server 485 while geocoding 450 accesses spatial server 490, which may be a MapMarker.RTM. Server provided by MapInfo.RTM. Corporation. In addition, modules for profiling 445 access third party directory server 492, which, in turn, accesses LDAP 494, while positioning 420 accesses third party location server 496. The result sent by one or more of the various service modules is used to generate response 498 to request 400. Thus, response 498 may integrate information from more than one service module.

In one aspect the present invention encompasses a system including: a routing module that receives and routes requests to an appropriate response module; a plurality of response modules registered with the routing module for responding to different types of requests; a plurality of spatial servers from which the response modules retrieve spatial information to be used in responding to the requests; and an interface for adding response modules to the system. The interface further includes methods for publication of information regarding the response module to the service manager, also referred to as the routing module, including information required for starting or terminating a particular response module, and methods to allocate or deallocate resources.

The system of the present invention further encompasses: a servlet within a platform independent implementation (JAVA). The servlet is in communication with a service catalog to determine or update available services/response modules and a user profile and geographic database. The servlet also provides support for one or more of HTTP/POST, XML, and SOAP, while being adapted to forward requests to a registered response module, which module, in turn, receives spatial information from a spatial server, and sends results to the routing manager for generation of the response to the request.

The system of the present invention also encompasses the functionality of a response sent to a different address than the address from which the request was received.

The system of the present invention further encompasses a plurality of spatial servers that may include one or more of: a routing server (Routing J Server.TM.) for obtaining one or more routes between a starting point and a destination; a geocoding server (e.g., MapMarker J Server.TM.) for providing geocodes corresponding to an address; a geodecoding server (e.g., MapMarker J Server.TM.) for providing an address corresponding to a geocode; and a mapping server (MapXtreme server.TM.) for providing maps as image files encompassing specified geocodes, locations, or addresses.

The system of the present invention also encompasses at least one service module comprising: an interface for receiving a request; an interface for generating a response to the request; and an interface for initializing and shutting down the service module.

Embodiments of the system of the present invention may also encompass services such as obtaining one or more records containing a geocode corresponding to an address; obtaining an address corresponding to a geocode; obtaining a route to a destination; obtaining a position for a mobile device; obtaining the identity of a location; obtaining one or more geographic features near a location; and a person profile data; providing a map corresponding to a location; a coordinate geometry service for carrying out geometric calculations and measurements; performing coordinate transformations; providing traffic related information; generating enterprise specific maps; and providing an enterprise profile.

Embodiments of the system of the present invention may also encompass Pass-Thru Service, which refers to a service provider creating a service request specification that contains a request of another service or server (typically encoded in XML as well). The Pass-Thru Service facility extracts a request content (or payload) from the request document in the original request envelope, passes this payload to another server (third-party server) that accepts the XML request, processes the payload, and wraps the response payload back into an envelope for returning the response document. Thus, the integrated location-based service platform, or its modules, may not only receive requests, it may also make requests and process the response thereto.

FIG. 5 illustrates an example of an integrated location-based service platform for providing routing information in London, U.K. The integrated location-based service platform preferably comprises service manager 500, which receives requests 502 from user 504. User 504 may request a route that could include walking, driving and subway legs for providing the lowest cost, shortest distance, and/or shortest time or other specifications. Alternatively, a default specification may be provided to the user. User 504 sends request 502 via interface 506, which allows additional requests to be sent as well. Interface 506 is extensible and includes tube (i.e., subway) interface 508 for communicating with tube service 510 underlying service manager 500. Extensibility denotes providing interfaces to allow anyone including third parties to extend the functionality of the system. Thus if a subway routing module for a city was available, it may be added without the need for express integration for incorporating the functionality directly into the routing modules. It is preferred that such modules are registered only following an authentication or a limited gate-keeping step to ensure that the module provider is trusted, as well as retain a measure of control over potential providers of service modules. To the user, the added functionality appears seamlessly integrated.

Service manager 500 sends a request object 512 to tube schedule service 514, which is part of service providers 516. Tube schedule service 514 requests information from tube map server 518, which is one of the spatial servers 520, and receives information 522 in response thereto. This information enables service provider modules 516, such as tube schedule service 514 to generate response object 524 for service manager 500 in response to processing request 502. Service manager 500, in turn, generates response document 526 for sending to user 504 via interface 506.

Notably, FIG. 5 also illustrates that service providers 516 (response modules) may provide various services that may have security components as well. For instance, a service provider providing security or personal profile information may provide permissions that enable all users to (1) access one or more of all applications; (2) access some services by way of some applications only; (3) allow specified user to access specified services; or (4) characterize the profile of an enterprise.

In addition, the wireless carrier may provide additional services through intuitive and automated interfaces that allow a user to advertise event such as a garage sale. This service is enhanced in value by the smooth integration of the functionality for providing directions from existing modules integrated via the with directions to the garage sale generated in a customized fashion for individual users, such as user 504, based on use of the tube, walking and/or driving. User 504 may be provided information, for instance that regarding the garage sale, in response to detecting user 504 via LAN/WiFi 530. Such detection triggers, preferably with the consent of the user, the obtaining of profile and preference information for user 504 over a secure Wide Area Network (WAN) 540. In addition, user 504 may be presented with a choice of or information about malls and supplier stores 550 in the vicinity, along with directions to a supplier store from a location of user 504. All of these activities are preferably carried out automatically, thus integrating user 504 with the surroundings.

Thus, the choice of mall stores, as is also further illustrated in FIG. 6, may be provided by a wireless carrier along with information about a garage sale in the vicinity. Notably, WiFi is not necessary for accessing information about a garage sale or a store in a shopping mall. Such information could be provided by way of local data going back through the carrier to the device being carried by the end user. The connection is still preferably point-to-point in the sense that a handoff request is given to the system(s) to hold the mall information even if the mall returns it back to the carrier for delivery rather than delivering it directly. Garage sale advertising functionality may interact with a carrier in a similar way.

The wireless provider (or some other agent) brokers an arrangement with a person wishing to hold a garage sale and the person wishing to have the garage sale (or any other similar activity) provides the details for the garage sale by interacting through an interface managed by the carrier or other agent without any need for direct intervention by the carrier or other agent. In some embodiments there may not even be a charge for such a service, but likely there will be a charge if that matters. The party advertising the garage sale provides an address for where the garage sale is being held, the carrier or other agent knows the location of the sale and can therefore provide the end user wishing to know about any sales in the vicinity of the end user. The actual details about the selected sales are then delivered preferably in response to a user request.

WiFi functionality is likely to be used if a user were looking for a sale rather than push sales related information to a user. Preferably, mobile users, for instance, moving in a vehicle or walking through a neighbourhood, are sensed via carrier detection and interaction. Thus, the provider of the `sale` or any event in general may provide advertisement and notice of the event along with directions and other sophisticated functions without the need of any programmer by merely using a friendly user-interface to guide them through the setting up of such a service to make their local event detectable through the carrier or other agent.

In another aspect, the present invention comprises stand-alone services that may be provided by stand-alone service providers or by service providers that may be accessed both through an integrated location-based service platform and directly. An example is provided by a peer-to-peer location-based information system (LBS) in which locally relevant information may be maintained by local entities, such as local businesses. In another aspect, the present invention comprises a combination of location-based service and personalization, in which locally- and personally-relevant information is automatically provided to users based on their location and previously-stored personalization information. In a preferred embodiment, the peer-to-peer aspect and the personalized localization aspects are combined into a single system. In one such preferred embodiment, a central server maintains personalization information in the form of a customer profile, and maintains a list of servers providing locally relevant information, and automatically refers the user to a server providing information relevant to the user's location. The profile is used to refer the user only to information that matches the user's profile, and/or to provide the server providing locally relevant information with the ability to personalize the information for the user.

In a preferred embodiment, the present system and method comprise a site adapted to host one or more location-based services. A Service Provider Java API is preferably provided, which is a set of Java interfaces and classes for development of new services. New services can be deployed to the existing set of services hosted by a the site. Once deployed, services may be accessed from the outside world.

In order to deploy a new service, a service provider preferably implements three main interfaces: ServiceProvider, ServiceRequest, and ServiceResponse. ServiceProvider is the main interface to a provider. At initialisation, a ServiceProperties object is passed into the provider so configuration information specified in the Service Catalog can be utilized. Since initialisation is only a one time operation, global information necessary for performing service requests in a multi-threaded environment should be cached. At shutdown, the provider preferably de-allocates resources so to avoid memory leakage and/or holding up unnecessary resources (e.g. database connections). These tasks are performed by methods such as init( ), shutdown( ), getServiceRequest( ), and perform( ). The ServiceRequest contains parsed information of a request document. The provider creates the ServiceRequest object based on the input request document. This object parses the content of the document and provides information for rendering a request. The ServiceRequest is passed into the provider at a later stage for carrying out the service request. Implementation of this interface also provides capability to create request document conformaning to a suitable DTD, such as the miAwareServiceRequest DTD, which includes specifications for methods (e.g. setDistanceUnit( ) of the RouteRequest object) that are available for filling the content of this document including setters & getters to XMLdocument( ).

A ServiceResponse object contains results of a service request and is returned after a service is rendered. This object also provides methods for publishing its content to a XML document conforming to the miAwareServiceResponse DTD. In addition, this object is also able to parse its own response XML document and provides "get" methods (e.g. getTotalTime( ) of the RouteResponse( ) object) for retrieving the content.

If other third-party JAR files are required, they are also bundled together with the implementation class(es) of the ServiceProvider interface. The request and response DTDs, their sample XML documents, and Javadoc for the ServiceRequest and ServiceResponse implementation classes are also made available.

In another aspect, a client Java API is provided, which comprises a set of helper classes grouped by services, which assist Java application developers to publish service requests and retrieve information from a response document. Helper classes which assist development of client applications include constructing service requests as XML (e.g., String req=routeReq.toXMLDocument( );), submitting requests to miAware.TM. Service Manager (e.g., InputStream is=miAwareConn.submit(req);), and parsing results from service response XML (e.g., RouteResponse res=New RouteResponse(is);). The client is super thin due to no dependency on core software. Typically, the client needs W3C compliant SAX/DOM parsers (which are provided by many entities such as Sun.RTM., Oracle.RTM., IBM.RTM., etc).

Turning to the form of response and request specifications, some useful features are readily apparent. These messages are encoded in a markup language, and include a location of interest and a plurality of nested tags, preferably conforming to the XML specification, such that the message comprising an outer tag indicates a first service. The inner tag is associated with a plurality of attributes for processing the request so that at a user interface (supported in a thin client) one or more fields corresponding to the plurality of attributes are presented to receive data for providing the first service or the result of a service request. The location of interest may be provided by many different means, such as user input, a base station location signal, an address, a geocode, two or more base station signals detected by a mobile phone, and two or more GPS signals. As noted previously, a part of the request is forwarded to a service provider module by using the nested tag structure.

In another aspect, the tags correspond to requests for services such as routes to a specified destination, a list of local servers for obtaining local information, an ordered list of events, a list of products or services, a location, a map, a list of nearest geographical features, transformed coordinates, an event matching service, a traffic monitoring service, a peer-to-peer communication shopping service, a user profile service, and a location aware service. The attributes provide data for an address, authenticating information, personal preference information, event description, a route, geographically accessible locations, product description, traffic conditions, weather conditions, a map, and coordinates transformation.

In a preferred embodiment of the invention, a central LBS server in the peer-to-peer system maintains a database of local-content servers (peers) providing locally relevant information that is spatially indexed so as to permit the network addresses of the local-content servers to be resolved based on a provided indication of the location of a user. Such a database may include records indicating categories of content available from at least a portion of the servers.

When a user of a mobile device accesses the system of the present invention by running a client program for interacting with the LBS server, the LBS server is provided with an indication of the user's geographic location. The client system may comprise a cellular telephone comprising a location determination system such as GPS or any mobile positioning technology, and Java. Using the indication of the user's geographic location, the LBS server queries the database for local-content servers providing information or services relevant to the area of the user's geographic location. If the results include only one local-content server, the user is preferably re-directed to the local-content server. If the results include more than one local-content server, the user is preferably provided with a list of links to local-content servers.

The LBS server may not include information about the content or services provided by the local-content servers, thus avoiding the need for updates when the content or services provided by local-content servers are updated. In an alternative embodiment, the LBS server database includes records indicating the categories of content or services provided by at least a portion of the local-content servers.

The information and/or services provided by local-content servers are preferably maintained by entities, such as businesses, that also provide goods and/or services through facilities physically located near the geographic locations for which the local-content servers provide information and/or services. There is no requirement for the local-content servers to be physically located in or near geographic areas for which the local-content servers provide information and/or services. However, in one preferred embodiment, local-content servers are maintained locally by area organizations, such as shopping malls, and may be accessed by local-content providers, such as stores within the shopping mall. Preferably, wireless access is provided for maintenance by local-content providers.

Personalization services may be provided by the LBS server, or by the local-content servers, or both. In a preferred embodiment, personalization services are provided by local-content servers, which act upon information provided from a customer profile maintained by the LBS server operator. In this way, only personally relevant local content is provided to the user. Personalization services are preferably provided by Mapinfo.RTM. Corporation's miAware.TM. profile module. Servers running MapInfo.RTM.'s miAware.TM. also preferably provide LBS services and local-content services.

An illustrative embodiment of the present invention includes a communication system comprising a central LBS server, a plurality of local-content servers called, a central database (repository) attached to the central LBS server containing one or more URL of each local-content server, a plurality of local-content databases (repositories) attached to each local-content server, and a map server. Each local-content database preferably comprises product and sales information of stores in a shopping mall. Each central LBS server and local-content server may, for instance, be implemented as an Apache Tomcat web server with Java Servlets with the databases or repository being an Oracle database accessed by Servlets via JDBC. An example map server preferably comprises MapInfo.RTM. Corporationg's MapXtremeJava.TM. 3.1 servlet for retrieving maps for specific local malls, as shown in FIG. 6. Collaborations of these system components are shown in FIG. 7 and FIG. 8.

In phase one, illustrated in FIG. 7, a mobile user 700 sends a request to the central LBS server, hosted by integrated location-based service platform 705 via a wireless carrier gateway 710 and Internet 715. Notably, the central LBS server may be hosted independent of integrated location-based service platform 705 as well. The request seeks the address of local-content servers, possibly including local-content server 720 serving the user's geographical location. The request preferably further comprises an indication of the geographical location of the mobile user, such as the user's approximate latitude and longitude, although such an indication is not required for practicing the invention since it may be obtained automatically via a location determination service by triangulation or other means.

Upon receiving the request, central LBS server 600, illustrated in FIG. 6, preferably implemented as a collection of servlets, forwards the message to mall selection servlet 605 residing in server 600. Mall selection servlet 605 includes a listing of various malls and may be connected to an integrated location based service platform. Mall selection servlet 605 then parses the message to obtain the user's geographical location and queries database 610, with the aid of mall specific service 630, for the name and URL of local-content servers, such as local-content server 720 of FIG. 7, serving the user's location. Central LBS server 600 then responds to the request with a list of names and URLs of the local-content servers serving the user's location. As shown in FIG. 6, central LBS server 600 may be a standalone server including store information and administrative operations capability via mall specific servlet 615, mapping and directions from mapping servlet 620 and local service integration by integrated location-specific platform 625. Alternatively, mall specific servlet 615 may serve as the front-end to an integrated location specific services platform. FIG. 6 also shows store table 635 and sales table 640 for providing various services, and which tables are preferably stored in RDBMS 610.

In phase two, the mobile user establishes contact with specific local-content server 720, by sending a request with privileges of either a mall administrator or a simple end-user. If only one local-content server was found by central LBS server 600, the mobile user client may be redirected to local-content server 720 without the user's intervention. Otherwise the user is presented with a display comprising a list of local-content servers servicing the user's location. The list may be filtered based on personalization information stored on the user's client 700 or provided by central LBS server 600.

FIG. 8 further illustrates interactions between clients 800 and 840 and an integrated location-based service platform performing multiple functions. Client 800 sends a request to a central operations center, e.g., using a wireless link, and is connected to central LBS server 810 (which could also be an integrated location-based service provider). The request may comprise a mall map, store location, sales/specials, updating of sale data and the like. Integrated location-based service provider 810 connects to repository 815 to retrieve necessary information, and may further request second local central LBS server 820, if required, for a map, a specific location, or specials. Second central LBS server 820, in turn communicates with a map service 825 or specials service 830, in communication with repository 835 for determining available specials. In addition, client 840, being in the vicinity, directly communicates with second central LBS server 820 for services.

In this example, users can retrieve sale information for stores in the malls in their area. Sale information for each store is maintained by a store administrator for each store. A store administrator can get, add, delete and update sale information for the administrator's store, while an end-user can, preferably, only retrieve sale information. Sale and authorization information is stored, for instance, in two tables in the local-content server database, stores table 900 and sales table 910, as shown in FIG. 9. The stores table 900 comprises authentication (password) information for stores in the mall. When a user attempts to administer sale information for a store, the user is prompted for a password. If the password matches the password for the store in the stores table 910, the user is allowed to administer the store sale information stored in the sales table for that store. FIG. 10 is a flow chart indicating the actions available to a store administrator, which allow remote monitoring of stores with the possibility of conducting inspections and the like if required.

During step 1000 in FIG. 10, a user with store administrator privileges chooses a mall to access. Next, during step 1005, the store administrator is presented with a secure login screen. Control passes to step 1010 in the event the login fails, and preferably at least a limited number of retries are allowed by transferring control to step 1005. Limiting retries is preferred, but not required, since it counters denial of service attacks and other security breaches.

From step 1005 control flows to step 1015, during which sales for a target store may be retrieved. In response, or otherwise, the administrator may elect to, during step 1020, add, update, or delete a sale. For these illustrative operations, control flows to step 1025 for entering a new sale, which may be approved in step 1030 or fail during step 1035; step 1040 for deleting a sale, which may be approved in step 1045 or fail during step 1050; and step 1055 for selecting a sale for updating during step 1060, which may be approved in step 1065 or fail during step 1070 respectively.

FIG. 11 is a flow chart indicating the actions available to a user who has been provided with a list of local-content servers by the central LBS server or may have received a splash screen image during step 1102, possibly of a promotion, advertisement, or a message indicating start of an application. During step 1100, selection or a response results in a user receiving a mall list selection followed by, during step 1105, selection of a store search method. The user may, during step 1110 find a store by name; or during step 1115 find stores based on products. Control flows to step 1120 from step 1115, so that a user may find all stores by a specific product category or to step 1125 for finding stores by their typical product categories with selection of a store by product during step 1130. Control following store selection flows from steps 1110 and 1130 to step 1135, during which the display of a target store's sales list information is selected. Control then flows to step 1140, during which sale information is displayed. Directions to or maps for the target store may then be obtained during steps 1145 and 1150 with various degrees of specificity, denoted by selection of a zoom parameter value.

FIG. 12 indicates the corresponding Java panels used by the example application illustrated in FIG. 11. Thus, step 1102 corresponds to map panel 1202, which is shown in FIG. 13, step 1100 to selection panel 1200, and so on. Corresponding panels in FIG. 12 are labeled in a manner similar to the labeling in FIG. 11. The individual user interface is depicted in FIGS. 13-22, which are described in greater detail next.

In FIG. 13, corresponding to 1202 and 1102, the user has started a client application on his mobile device, preferably a java-enabled cell phone using a mobile positioning system. When the user selects "OK" 1301, a request including an indication of the user's location is sent to the central LBS server. The central LBS server responds with a list of local-content servers serving the user's location, which is displayed on the user's client system as illustrated in FIG. 14, corresponding to step 1100 and panel 1200. In this example, two malls are near the user, the Crossgates mall and the Colonie Center mall.