DETAILED DESCRIPTION

[0037] Described in detail below is a system and associated method that allows users to locate friends or other contacts, businesses, points of interest (POI's) or other locations, and manage this information in a user-friendly environment. A user with a wireless device, such as a cellular phone, may identify the locations of select individuals (via their wireless devices). Likewise, the user may receive directions to a desired location, and even coordinate a meeting place with a friend. For example, the user may notify a friend or other person about wishing to meet, identify a location nearby, and receive directions, all via a central system that coordinates the meeting, including RSVPs and other messages.

[0038] Aspects of the system allow a user to identify, effectively in one step, a location of a friend. User's can modify privileges quickly and in near real time. For example, a user may always deny requests to become another's friend for purposes of various location services. Likewise, the user may remove him or herself from a friend's list at any time, but later then request that they be added to that friend's list. Various other features are described in detail herein.

[0039] In a broad sense, embodiments of the invention relate to location-based services in a system for providing wireless telecommunications services to mobile devices. The system obtains a request from a first mobile device for a meeting with a person associated with a second mobile device. The system automatically determines locations of the first and second mobile devices, and automatically provides information to at least the first or second mobile device regarding a meeting location based at least in part on the determined location of the first or second mobile device. The system can also determine a local time, or time zone, of the first or second mobile devices, and with one or a minimum number of menu choices, a user of a mobile device may readily receive a location of a user or another mobile device.

[0040] The invention will now be described with respect to various embodiments. The following description provides specific details for a thorough understanding of, and enabling description for, these embodiments of the invention. However, one skilled in the art will understand that the invention may be practiced without these details. In other instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments of the invention.

[0041] A representative system in which functionality described herein will first be described. Representative message flows performed by the representative system will then be discussed with respect to adding a “friend,” obtaining directions, meeting friends and finding locations. Thereafter, a representative user interface and location-based functionality is described. Finally, representative data structures are described.

[0042] Representative System

[0043] Referring to FIG. 1A , a system 100 is shown where a wireless device or mobile unit 102 (shown as a 2.5G GPRS-enable mobile handset) communicates wirelessly to a 2.5G uplink 104 . A typical 2.5G uplink 104 includes multiple components not shown, such as (in order), a base transceiver station (BTS), a base station controller (BSC), and in a General Packet Radio Service (GPRS), a Gateway Serving GPRS Support Node (SGSN), a GPRS wide area network (WAN), a Gateway GPRS Support Node (GGSN), a wireless access protocol (WAP) gateway, and other components known by those skilled in the relevant art. Of course, while a 2.5G network and wireless device are shown, embodiments of the invention may be used in various other wireless systems.

[0044] One or more load balancers 106 (such as Alteon load balancers by Nortel of Canada) receive communication packets from (or provide packets to) the wireless device 102 via the uplink 104 . A portal application server or servers 108 communicate with the one or more optional load balancers 106 . The portal application servers 108 include various components.

[0045] For example, the application server 108 includes a servlet 110 , which may be a Java application for handling location requests to or from the wireless device 102 . User interaction and business logic application code 112 and 114 , respectively, work in conjunction with the servlet 110 and an application server 116 . The user interaction and business logic code, as well as the application server, provide much of the functionality described herein. The application server 116 may be a WebLogic server provided by BEA of San Jose, Calif.

[0046] Working below the application server 116 is an application programming interface (API) layer 118 that includes various APIs, such as Java Database Connectivity (JDBC), Java Transaction API (JTA)/Java Transaction Service (JTS), JavaMail, Java Cryptography Architecture (JCA) and EnterpriseJavaBeans (EJB).

[0047] Working below the API layer 118 is a Java Virtual Machine (JVM) 120 , such as Hotspot by Sun Microsystems of Santa Clara, Calif. A suitable operating system 122 , such as Solaris by Sun Microsystems, interfaces with the JVM 120 , as well as a hypertext transfer protocol daemon (HTTPD, e.g., that is provided by Apache), and JDBC and shared libraries. In general, a single server may be used to track all sessions for a given wireless device (based on, for example, the internet protocol (IP) address, Electronic Serial Number (ESN), Mobile Station ISDN (MSISDN) or some other unique identifier). This makes it easier for the system to track sessions for a given device.

[0048] The application server 108 interacts with four components: a portal database 124 , a Gateway Mobile Location Center (GMLC) 126 , a location engine 128 , and a Simple Mail Transfer Protocol (SMTP) gateway 140 or other electronic messaging/mail service. The portal database 124 includes a database application 130 , such as those provided by Oracle of Redwood Shores, Calif. The portal database 124 stores much of the location-based information, friends lists, pending requests, etc., described herein.

[0049] The GMLC 126 includes a phone locator subsystem 132 that works with the GMLC 126 , such as the e-Mobility Location Center provided by Nortel. A WAN 134 connects the GMLC 126 with the application server 108 . The phone locator 132 provides a GMLC API for providing the latitude and longitude information over the WAN 134 for use by the application server 108 or location engine 128 . The GMLC 126 provides location data to the location engine 128 and other location service clients that may interface with it. The phone locator subsystem 132 provides latitude and longitude information about the cell site to which a subscriber is connected. Alternatively, the phone locator subsystem 132 can provide the latitude and longitude coordinates of the wireless device 102 within the cell site.

[0050] A Location Based Service (LBS) application 136 operates on the location engine 128 . The location engine 128 and LBS application 136 may be provided by, for example, Kivera of Oakland, Calif. The LBS application 136 provides geo-coding (providing latitude and longitude based on an address), reverse geo-coding (providing address information based on latitude and longitude), proximity searching (providing items within a predetermined proximity, including points of interest information), routing (providing directions from a first to a second point), and map generation (generating maps of locations and directions). The LBS application 136 provides this functionality as a set of classes that connect to the location engine 128 via a Java-based connection pooling class, which, in turn, attaches to a load balancer, such as the load balancer 106 . This class is responsible for maintaining a set of connections, providing keep-alive reconnect functionality, etc. The load balancer 106 may provide a virtual address space to the Location Engine 128 and automatic fail-over.

[0051] While shown together as a single block in FIG. 1A , the portal application servers 108 are logically separate functions. A portal server provides much of the communication handling with the mobile devices. One or more application servers provide many of the location functions described herein, such as the meet friends functionality. Prior systems provided some location functionality at the GMLC or as middleware. However, as described herein, the portal server is tied closely with the application servers such that authentication and access control, as well as querying location and providing location-based services, are more intimately integrated. Subscriber information is tied more closely with location-based information and other information. Thus, as described below, when the user receives notification that a friend is attempting to locate him or her, the user receives the friend's mobile number, email address, portal subscriber/username, or other information with respect to the friend. Such a configuration provides privacy and control because the portal, subscriber and other applications are within a common network (such as a LAN), all on one side of a firewall (where the firewall may be typically located between the uplink 104 and the load balancers 106 ). Thus, while the terms “portal,” “portal server,” “application server,” and the like are used interchangeably herein, those skilled in the relevant art will recognize that such servers are logically separate entities.

[0052] The portal application server 108 , the portal database 124 , GMLC 126 and location engine 128 may be provided together on one physical server, or divided each among one or more separate servers. The portal database 124 , or other mass storage described herein, may be implemented by storage devices provided by EMC of Massachusetts. The location engine 128 may be implemented on, for example, a Netra 20 server by Sun Microsystems.

[0053] Various alternative system configurations are possible beyond those shown in FIG. 1A . For example, while one or more servers may be co-located, some servers may be remotely located and connected to the remaining components by way of, for example, a virtual private network (VPN). Firewalls and encryption may well be required for security. Alternatively, an application service provider (ASP) model may be provided where the various functions are performed by various servers, which may be either remotely distributed or co-located. However, the applications, such as the LBS application, may be maintained by a third party. Mass storage may be employed as a Storage Area Network (SAN), a Network Attached Storage System (NAS), or other known mass storage systems.

[0054] While a mobile phone is shown in FIG. 1A , those skilled in the relevant art will appreciate that the invention can be practiced with other devices and configurations, including Internet appliances, hand-held devices, wearable computers, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers and the like. The invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured or constructed to perform one or more of the computer-executable instructions explained in detail below. Indeed, the term “computer” or “wireless device,” as used generally herein, refers to any of the above devices and systems, as well as any data processor.

[0055] FIG. 1B shows an example of a high-level call or message flow diagram whereby the wireless device 102 requests, for example, directions. As shown, a wireless WAP gateway (forming part of the uplink 104 ) receives a request from the device and provides it to the portal application server 108 . (The portal application server is generally referred to interchangeably herein as the “portal” or “application server,” unless the context clearly requires otherwise.) The portal database 124 receives the request from the portal application server 108 , and provides back information, such as an IP address or other information regarding the registered user of the wireless device 102 . The portal application server 108 then provides a request to, and receives location information from, the GMLC 126 . Thereafter, the portal application server 108 provides a request to, and receives directions information from, the location engine 128 based on the location of the wireless device provided by the GMLC 126 . The portal application server 108 may then send email or Short Message Service (SMS) messages to the mobile device (or other device) by way of the SMTP gateway 140 . The portal application server 108 also provides the content (in this case directions) to the WAP gateway, which, in turn, provides the content to the mobile device. Alternatively, rather than sending email as SMTP messages, the portal application server 108 may send Short Message Peer-To-Peer Protocol (SMPP) messages. Rather than email messages, such as email alert messages, the portal application server 108 may push WAP messages to the user's (or friend's) mobile device.

[0056] A benefit of the system configuration noted above is reducing latency for providing location-based services. For example, no wide area network (WAN) connections are necessary to get information. Another advantage is an increase in privacy or security for location-based services. Only one service provider has access to a database containing user or subscriber information. Subscriber information need not be shared with third parties, or transmitted over public networks. Further, as described below, the location-based service functionality described herein provides an “opt-in” model whereby location information is only provided after users first agree to the system providing such information to others.

[0057] Representative Message Flows

[0058] Referring to FIGS. 2A and 2B , some functionality performed by the system 100 is shown as a routine 200 . Beginning in block 202 , the routine determines whether a user wishes to add friends, and if so, the routine branches to perform the message flow shown in FIG. 3 . Under blocks 204 and 206 , the user can determine whether to accept or deny a friend, and if so, the routine branches to perform the message flows of either FIG. 4 or 5 , respectively.

[0059] In block 208 , the routine 200 determines whether the user requests more information, and if so, branches to perform the message flow of FIG. 6 . In blocks 210 and 212 , the routine determines whether the user wishes to alter the display select or modify location, and if so, the routine branches to perform the message flow of FIG. 7A or 8 , respectively.

[0060] In block 214 , the routine 200 determines whether the user wishes to view directions, and if so, the routine branches to perform the message flow shown in FIG. 9 . In blocks 216 , 218 and 220 , the routine 200 determines whether the user wishes to meet a friend at a location between the two of them, near the friend, or near the user, and if so, the routine branches to perform the message flows of FIGS. 10, 11 and 12 , respectively.

[0061] In block 222 , the routine 200 determines whether the user wishes to find nearby places, and if so, the routine branches to perform the functions shown in FIG. 13 . In block 224 , the routine determines whether the user wishes to find nearby friends, and if so, branches to perform the functions shown in FIG. 14 . In block 226 , the routine determines whether the user wishes to edit a list of friends, and if so, branches to perform the functions shown in FIG. 15 . In block 228 , the routine determines whether the user wishes to RSVP to friends, and if so, branches to perform the functions shown in FIG. 16 .

[0062] The routine 200 and others described herein may be implemented as computer-executable instructions, such as routines executed by a general purpose computer (e.g., a server or personal computer). Such instructions may be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer disks, hard-wired or preprogrammed in chips (e.g., EEPROM semiconductor chips or ASICs), as well as distributed electronically over the Internet or over other networks (including wireless networks). Those skilled in the relevant art will recognize that portions of some embodiments of the invention may reside on a server computer, while corresponding portions may reside on a client computer or wireless device. Data structures and transmission of data particular to aspects of the invention are also encompassed within the scope of the invention. In general, while hardware platforms, such as the system 100 , are described herein, aspects of the invention are equally applicable to nodes on a network having corresponding resource locators or addresses to identify such nodes for data routing and requesting execution of commands

[0063] Referring to FIGS. 3-12 , representative message or data flow diagrams depict exchange of communications between the gateway and other components of the uplink 104 , the portal application server 108 , and other components of the system 100 . These and other flow diagrams do not show all functions or exchanges of data, but instead provide an understanding of commands and data exchanged under the system. Of course, those skilled in the relevant art will recognize that some functions or exchange of commands and data may be repeated, and other (less important) aspects not shown may be readily implemented.

[0064] Adding “Friends”

[0065] Referring to FIG. 3 , a representative call or message flow diagram for allowing a user to add a friend under the system 100 is shown. The wireless uplink 104 , such as the WAP gateway, receives a request from the wireless device 102 to enter a new “friend” into the user's database of friends. The term “friend” as generally used herein refers not only to any acquaintance or other person with whom the user wishes to interact, but any addressable wireless device. Indeed, the terms “user” and “subscriber” are used interchangeably, and refer to a given individual employing or otherwise effected by functionality or systems described herein. A “subscriber” need not necessarily be one who subscribes to the location-based services described herein. With respect to system functionality, the terms “friends,” “user,” “subscriber,” and the like are logically equivalent, and represent any data that the system uses to track and manage wireless devices. The invention may be used for providing location-based services with respect to one or more wireless devices in a group or nodes in any network.

[0066] The flow of FIG. 3 begins by the gateway 104 receiving a request from a wireless device 102 to add a friend to a database of friends associated with the wireless device 102 . The gateway 104 receives a mobile number or username associated with the wireless device 102 , and passes this to the portal 108 . The database 124 receives a query from the portal 108 to check whether the mobile/username corresponds to a subscriber of the service, or is otherwise authorized, and if not, the database returns an error that is then forwarded by the portal 108 to the gateway 104 . The above authorization functions may be performed with most requests to authorize each user of the system.

[0067] If the database 124 does identify the mobile number or username in the database 124 and returns a valid response, then the portal 108 , in response, sends a request prompt to the wireless device 102 requesting input of information regarding the friend to be added. In response, the gateway 104 receives from the wireless 102 device and provides to the portal 108 information regarding the friend to be added (e.g., a mobile telephone number, URL or other electronic or network address associated with the new friend). The portal 108 , in response, sends an update request to the database 124 asking that the database 124 reflect that the user has requested the friend be added to the user's friends list. As explained below, the database 124 stores lists of pending requests and the status of various functions provided by the system 100 . The portal 108 may query the database 124 to retrieve the friend's username based on the received MSISDN (mobile telephone number) or other address. The portal 108 may also generate an SMS message or email to send to the friend, asking whether the friend wishes to be added to the user's list of friends, where this SMS message or email is forwarded to the SMTP gateway 140 for delivery to the user over the Internet or other data packet network (not shown).

[0068] In addition to having a user request a friend to be added to the user's friends list, the user can also ask to become listed on his or her friend's list. The user simply provides the mobile telephone number, user ID or other identifier for the friend into the portal 108 , and the portal 108 then makes an appropriate request to the friend, in much the same manner as described above.

[0069] The friend may accept or deny the request, which is shown in FIGS. 4 and 5 , respectively. Referring to the accept friend flow of FIG. 4 , after validating the friend as explained above, the portal 108 receives from the friend's wireless device (via the gateway) a request to view pending friend requests. The database 124 receives a query from the portal 108 to look up pending requests, and returns a list of friends to the portal 108 , which the portal 108 delivers to the friend's wireless device via the gateway 104 . The portal 108 then receives from the friend's wireless device, via the gateway 104 , one of the friend's requests to accept, and resends back a confirmation message. In response thereto, the wireless device provides the portal 108 , via the gateway 104 , a response to the confirmation message. The portal 108 , in turn, requests the database 124 to update the user's list of friends to now include the newly accepted friend.

[0070] The portal 108 sends an SMS message to the user indicating that the friend has accepted being added to the user's friends list. (The portal 108 may also send an SMS message reflecting the addition once the database 124 has been updated.) The friend may be listed in the user's friends list under the friend's unique username. Alternatively, the user may be able to change or edit the friend's name appearing on the list to something that the user desires (e.g., an alias).

[0071] The system is not reciprocal, in that even though the friend has accepted being added to the user's friends list, this does not mean that the user is automatically added to the friend's list of friends. Thus, the user may be prompted to send a request to the friend, asking the friend whether the friend wishes to locate the user. The portal 108 updates the database 124 to reflect that such a request is pending, and sends an SMS message to the friend asking whether the friend would like to add the user to his or her list of friends.

[0072] As explained herein, information displayed to the user (or friends) may be in the form of WAP messages. While not shown in these Figures, the portal 108 and mobile device 102 may receive or exchange multiple transmissions or “cards,” that form a “deck” to represent a complete display, command, or other transmission, as is common under WAP.

[0073] Referring to the deny friend flow of FIG. 5 , after returning a list of pending friend requests as described above for FIG. 4 , the portal 108 receives a response from the user of deny request or always deny request rather than an accept request. In response to each pending request to be added to someone's friends list, a user can deny each request from a particular friend individually, but keep open the possibility of later being added to the requestor's friends list, or select an option to deny the current request and always deny future requests from that requestor. Regardless of whether the portal 108 receives a response from user of deny request or always deny request, the portal 108 sends a confirmation message to the friend's wireless device, and receives from the wireless device a response to the confirmation message (all via the gateway 104 ). The portal 108 then requests that the database 124 make appropriate changes, and then sends an SMS message to the requestor indicating whether the user has denied, or always wishes to deny, being added to the requestor's friends list.

[0074] Under an alternate embodiment, the user may establish sublists of friends (similar to subfolders). Thus, the user can establish hierarchical friends lists that include certain upper level groupings (e.g., “friends,” “clients,” “co-workers,” etc.), with individual friends provided in one or more of these upper level groupings. The user may thus manage friends lists in a manner similar to that with respect to files and folders under the Windows and other PC operating systems. Furthermore, under this alternative embodiment, the user may select certain friends in a list, but not others (e.g., be able to find the first, third and fourth friends in the list, but not the second and fifth in a list of five friends). Having selected a subset of friends in a list, the user may then perform other functionality described herein, such as automatically and simultaneously locate the subset of friends. The system then simply performs the steps described herein for each of the selected friends in the list.

[0075] If the user attempts to add a friend who is not subscribed to a system compatible with system 100 , the friend cannot be added to the user's, friends list. However, the system could send a predetermined solicitation message (prerecorded voice message, SMS message, etc.) to the requested friend, or alternatively the system could prompt the user to do so, asking the friend whether he or she wishes to become a subscriber to the service. Thus, in one embodiment, the system sends an appropriate solicitation message to the friend, where the message is tailored to the particular circumstances. For example, if the friend is a wireless subscriber under the system, but has not subscribed to data services (and thus cannot benefit from the location-based services described herein), the solicitation message encourages the friend to subscribe for such data services. Alternatively, if the friend is a wireless subscriber of another service provider, then the solicitation message encourages the friend to switch service providers.

[0076] Alternatively, or additionally, the system may send a solicitation message to the user requesting that the user send a message to the friend requesting that the friend join as a subscriber. Such a solicitation message to the user may simply ask the user to prepare and send such a message, or include a sample message for the user to forward to the friend. The user, in turn, may receive certain compensation if in fact the friend does join as a subscriber.

[0077] Such solicitation messages could include information to permit the friend to readily become a subscriber of the system, such as providing a URL or toll-free number. For example, a main menu of location-based services options may include an option to send a pre-formatted message to a phone number of the user's choice, where the message may read “Hello! [user's mobile identification number] wants to use Find Friends with you. If you aren't already a subscriber, call 1 - 877 - 400 - 1080 .” The system may track in the database 124 such pending requests for friends to subscribe to the system. Once a friend has subscribed, the portal 108 may send an SMS or other communication to the user indicating that the friend has subscribed, and asking whether the user wishes the friend to now become a member of the user's friends list.

[0078] While a text or visual interface is described generally herein, an alternate embodiment may employ a speech or other audio interface. Thus, the portal 108 may provide directions under either a text-to-speech methodology, or other known ways to provide aural information to users over their wireless devices.

[0079] Referring to FIG. 6 , the example of message flow in the system 100 is shown for when the user requests information. The portal 108 receives from the wireless device 102 (via the gateway 104 ) a request for more information. In response, the portal 108 requests the database 124 to look up a particular message or otherwise retrieve information. In response to a message received from the database 124 , the portal 108 formats the message and returns it to the wireless device 102 via the gateway 104 . The returned information may be, for example, frequently asked questions, a tutorial for the user on how to add friends or perform other functionality, etc. Furthermore, as described herein, the user may request and receive information regarding a person requesting that the user grant them location privileges.

[0080] Obtain Directions, Meet Friends or Find Locations

[0081] As noted above, the system 100 can provide directions between two points, where the directions may be delivered in any number of ways, such as to the user's wireless device 102 , in an email, and/or with respect to a map image. FIG. 7A shows an example of a message flow for network element interaction in generating a screen to display a “from” location with respect to directions. As explained herein, the portal 108 may provide, to the user's mobile device 102 , location information of mobile devices within the network, where the location information is to a cell site (or cell site sector) level of granularity. If the user wishes to receive, for example, directions with greater specificity from a particular location (rather than the center point of a cell), the user may be required to enter a current street address. Thus, as shown in FIG. 7A , the meet friend controller 702 passes the user's and friend's location, as well as a destination location, such as a meeting place, if desired. In response, the direction controller 704 displays the “from” selection screen, which is provided by the portal 108 , via the gateway 104 , to the user's mobile device 102 . The user may then enter a specific “from” location via this screen. Alternatively, no “from” selection screen may be displayed, or such screen may not be filled out, when the level of location granularity is unnecessary/undesired.

[0082] With most location-based services provided under the system 100 , the system must determine the location of the user's wireless device 102 . However, under certain wireless protocols, such as GPRS, when a wireless device 102 is in data mode, the system 100 cannot determine the location of the device. Therefore, referring to FIG. 7B , the system may periodically perform a routine 710 for allowing the system to determine the location for the wireless device 102 .

[0083] Beginning in step 712 , the portal 108 determines whether a wireless device 102 has been in data mode for more than a predetermined time (e.g., more than 5 minutes). A small subroutine running on the portal 108 monitors the accumulated time during which each wireless device 102 is in data mode, and when a wireless device 102 exceeds the time threshold, the portal 108 transmits an appropriate message to the wireless device 102 instructing it to exit from data mode. Alternatively, each wireless device 102 could have a locally running counting subroutine that determines when the device 102 has been continuously operating in data mode for more than the predetermined time. The system 100 may alternatively or additionally request the mobile device 102 to exit data mode whenever the device 102 requests certain location-based services or whenever the location of mobile device 102 has been requested by, for example, a find friends request from a friend authorized to obtain such location. After the time threshold has been exceeded, the routine 710 in block 714 requests the wireless device 102 to send a currently displayed page to the portal 108 for storage. For example, the wireless device 102 may be viewing a particular WAP page, which the portal 108 receives and stores. In block 716 , the portal requests the GMLC 126 and location engine 128 to determine the location of the wireless device 102 . In block 718 , the portal 108 receives the location of the wireless device 102 from the GMLC 126 and/or location engine 128 . Thereafter, in block 720 , the portal 108 transmits back to the wireless device 102 the stored page to be reloaded by the wireless device 102 , and allows the wireless device 102 to return to data mode. The process then repeats. Further information regarding this process may be found in U.S. patent application Ser. No. ______ attorney docket number 654.US, entitled “Method and System for Locating a Mobile Device” (inventors Andre Okada et al.).

[0084] Referring to FIG. 8 , an example of a message flow is shown for modifying the “from” location with respect to directions for location-based services provided under the system. For example, the user may request directions from a location in which the user is not currently located, or may be required to enter a specific address if the user's location cannot be determined with specificity. Thus, as shown in FIG. 8 , the portal 108 receives from the wireless device 102 (via the gateway 104 ) a request by the user to modify the from location. In response, the portal 108 instructs a direction controller 704 to modify the from location, and receives therefrom an appropriate screen to permit the user to modify the from location. The direction controller 704 represents a subsystem, subroutine or group of functions for providing directions as described herein.

[0085] In response to the received screen, the gateway 104 receives from the user's wireless device 102 a new from location, which it forwards to the portal 108 . The portal 108 , in turn, forwards the new from location to the direction controller 704 to check if the new from location corresponds to a new address, or one already recognized by the direction controller 704 . If the address is new, the direction controller 704 returns an appropriate input display screen. The input display screen is then forwarded to the wireless device 102 via the gateway 104 . The gateway 104 receives new address information from the user's wireless device 102 , which the portal 108 receives and forwards to the direction controller 704 for updating. The direction controller 704 generates and forwards back to the portal 108 an updated from screen reflecting the new address, which, in turn, is forwarded to the wireless device 102 via the gateway 104 . In a very similar manner to that described above, the user may change the “to” location.

[0086] Referring to FIG. 9 , an example of a message flow for receiving or viewing directions is shown. The generation and display of directions, and other data, is tracked or managed via a hypertext transfer protocol (HTTP) session 904 running on the portal 108 , or application server, as described above. While not shown in all of the Figures, the portal 108 or application server initiates a session for managing the state of the mobile device's access to functionality provided herein. For example, when viewing directions, a user may request to view a next screen full of directions, act on the directions (e.g., sending the directions by email or fax), or jump to a specific screen of directions. The HTTP session manages the current state to ensure proper functionality. HTTP is the long-haul protocol for handling a Find Friends subscriber's transactional request and helps to minimize the network traffic required to process the request. Other suitable protocols may be substituted for HTTP to perform transaction request handling and/or to reduce network traffic associated with transaction requests. Likewise, other methods for tracking the state of the mobile device or user accessed functionality may be employed.

[0087] Thus, when a user requests directions, the direction controller 704 and a find friend controller 902 (described below) each set from and to locations to initiate a session via the HTTP session 904 . Thereafter, the direction controller 704 requests directions from the location engine 128 . After receiving the directions, the direction controller 704 stores the directions in the session under the HTTP session 904 , and formats the directions as a display screen for the portal 108 . The wireless device 102 receives the display screen of directions from the portal 108 via the gateway 104 . If more directions are to be displayed, the wireless device 102 may provide a request for more directions to the portal 108 (via the gateway 104 ). In response thereto, the portal 108 requests the direction controller 704 to display more directions, and if such directions are available, they are provided to the wireless device 102 via the portal 108 and gateway 104 .

[0088] The user may also view a particular screen of directions. For example, if six screens of directions are provided to the user to navigate the user from a current location to a desired location, the user may jump to the third of six screens. Thus, as shown at the bottom of FIG. 9 , the user may select a particular screen of directions and provide this desired screen number to the portal 108 , which in turn provides the direction number to the direction controller 704 . In response, the direction controller 704 provides the desired screen of directions, which the portal 108 provides back to the mobile device 102 .

[0089] As noted above, the system 100 includes a meet friend subsystem or controller 902 that represents a subroutine or group of functions allowing users to meet their friends, identify points of interest, search for meeting places, and schedule such meetings. The meet friends subsystem 902 also forwards this information on to the direction controller 704 if directions are needed. Referring to FIG. 10 , a message flow for requesting the system to allow a user to coordinate a meeting with a friend between the user and the friend is shown. The flow begins where the portal 108 receives, via the gateway 104 , a request by the user's wireless device 102 to meet a friend. The portal 108 queries the database 124 to look up all friends of that user, and provides back to the user a friends display page containing the user's friends list. Under an alternate embodiment, the friends display page may include not only a list of the user's friends (or first five friends in the list), but also last identified locations for these friends. Thus, the user can identify which friend may be closest, and coordinate a meeting with that friend.

[0090] As shown in FIG. 10 , the portal 108 receives from the wireless device 102 a friend that the user has picked. In response, the portal 108 requests the GMLC 126 to locate and provide the geo-code for this friend. In response to receiving the geo-code, the portal 108 requests the location engine 128 to perform a reverse geo-code to determine the address location of the friend. In response to receiving the friend's address location, the portal 108 sends an SMS message to the friend via the email gateway 140 . The SMS message indicates to the friend that the user has attempted to locate the friend. The portal 108 also sends a friend's location display page to the user's wireless device 102 providing the friend's address location. In response to the user's requesting to meet with the friend, the portal 108 sends a meet options display page to the user. The options page includes at least three options: meet near the user, meet near the friend, or meet between the user and friend.

[0091] As shown in the example of FIG. 10 , the user requests to meet between himself or herself and the friend, which is indicated by a “between us” message the portal 108 receives from the wireless device 102 via the gateway 104 . The portal 108 then gets the user's geo-code from the GMLC 126 and requests a reverse geo-code location from the location engine 128 for the user. Reverse geo-coding converts a latitude and longitude to a street address or other position easily locatable on a map. Thereafter, the portal 108 requests the location engine 128 to identify a midpoint between the user and friend and, based on the midpoint, requests the location engine 128 to find neighborhoods, cities or other sites around the midpoint. In response to the list of neighborhoods/cities/sites, the portal 108 provides a neighborhood display page for the user's wireless device 102 (via the gateway 104 ). The user selects a neighborhood/city/sites and provides this information to the portal 108 via the gateway 104 . In response, the portal 108 requests point of interest (POI) categories based on the chosen neighborhood/city/sites and provides to the wireless device 102 a display page listing POI categories. Categories may include, for example, restaurants, bars, parks, cafes, etc.

[0092] The portal 108 receives from the wireless device 102 a chosen POI category and requests from the database 124 search radius parameters, which are returned to the user's wireless device 102 in an appropriate radius select display page. The user submits a desired radius to the portal, and the portal requests from the location engine 128 POI's for the given category within the user's selected radius. In response, the portal 108 receives from the location engine 128 a list of all POI's fulfilling the user's desired criteria and provides to the user's wireless device a POI display page listing such POI's. The user chooses a particular POI from the list and provides this to the portal 108 via the gateway 104 . The portal 108 , in turn, provides a POI display page providing details on the selected POI. While not shown, the portal 108 sends an SMS message, email message, or other communication to the friend requesting an RSVP.

[0093] The database 124 stores a list of pending RSVP's in both a record for the user, and another record for the friend. The system 100 may thus keep track of pending RSVP's and other meeting requests. Indeed, the system 100 sends numerous SMS messages to keep the user, as well as friends, updated on the status of various requests. In an alternative embodiment, the portal 108 provides the user and friends with options for opting in or out of receiving various SMS messages, such as messages indicating whether friends have attempted to locate the user. Under this alternative, the user may select whether to receive any such messages, or indicate whether to receive such messages from particular friends or others that the user has allowed the system provide the user's location. Thus, for example, the user may wish to be notified when a first friend tries to locate the user, but not a second friend.

[0094] If the user wishes to receive directions to the POI, the user may request, via the wireless device 102 , directions. In response, the portal 108 receives the request for directions and performs many of the functions described above for obtaining and providing the desired directions to the wireless device 102 . The portal 108 may email directions to both the user and the friend, via the email gateway 140 . For example, the portal 108 may create and format e-mail messages, which the email gateway 140 sends to users at, for example, “[username]@mobile.att.net.” Alternatively, or additionally, the portal 108 may communicate with an appropriate fax server (not shown) to generate a fax of a map image, and send such an image to the user or friend for receipt by a computer, fax machine, etc. Software utilities for generating and sending facsimile images are well known to those skilled in the relevant art. The portal 108 may send an SMS or other communication to mobile devices 102 to alert the users to check their email or fax machine.

[0095] The system requires users to share their mobile phone numbers and usernames twice: once when requesting permission to locate a friend (so that the friend knows who is making the request), and again when granting access to someone. The portal 108 stores the mobile phone number and username in the friend list so that the portal 108 can identify the user and make it easy and secure for friends to contact the user.

[0096] Referring to FIG. 11 , if the user wishes to meet near the friend, much of the same message flow repeats from that shown in FIG. 10 . However, rather than providing a request to meet “between us” when receiving the meet options page, the user's wireless device provides a meet “near friend” request to the portal. The system 100 then provides POI's within the desired radius with respect to the friend's location. Likewise, if the user wishes to meet near himself or herself, a substantially similar message flow is performed, as shown in FIG. 12 .

[0097] The functions described above for meeting a friend allow the user to meet one friend at a time. Under an alternate embodiment, the system 100 permits the user to select two or more friends, and coordinate a meeting equidistant between these friends and the user. The system 100 , via the location engine 128 , computes a midpoint between the user and friends, and performs the functions above to permit the user to identify a desired POI at this midpoint or “geographic center.”

[0098] In another alternative embodiment, the portal 108 may integrate or interface with the user's calendaring application, contact management application, or both applications. For example, the portal 108 receives data regarding a meeting that the user has requested with a friend, and using standard API's associated with Microsoft Outlook, Infospace Calendar, or similar applications, adds the meeting and particulars regarding the meeting to the user's calendar. Likewise, when the user adds a new friend or otherwise adjusts his or her friends list (described herein), then contacts records in the user's contact management software such as Microsoft Outlook are modified to include information regarding the friend.

[0099] The portal 108 may determine the time zone or current local time in which the user is located based on the user's location. Alternatively, or additionally, the user may provide his or her home or office zip code when subscribing for the service described herein, which the portal may use to associate a time zone or local time with that user. Also, when a user locates a friend via the system, the portal 108 may return to the user's mobile device 102 the time zone or local time at the friend's current location. The portal 108 may determine the time zone from the mobile device's location, request it from the mobile device, or obtain it from another system element such as the location engine 128 or GMLC 126 .

[0100] The time zone or current local time may be useful in a variety of applications. For example, the local time may be used in coordinating meetings. The user may be traveling from Seattle to New York City, and may use the meeting function to schedule or coordinate a meeting with a colleague in New York City. The user may enter a “from” location corresponding to a hotel at which the user will be staying, and the meeting location (such as a restaurant near the hotel). The system can then coordinate the meeting based on East Coast time, rather than the user's current West Coast time. The system may also use the user's, or friend's, associated local time to determine appropriate times for receiving or sending messages, deciding whether it's an appropriate time to call the located friend, etc. Thus, the system may use the local time of the user, friend, or others to populate appropriate applications or functionality described herein.

[0101] Under an alternative embodiment, the portal 108 may provide the user with a dropdown list of cross streets near a location (such as the current location of the user, or the location of a point of interest). Such list of cross streets may be particularly helpful in orienting the user with respect to a desired location, filling out a screen (e.g., a “from” location screen), etc. Such a list of cross streets may be provided as an option selectable by the user via any known user input technique (e.g., touch sensitive screen on mobile devices employing such user input devices, simple button selection from a menu list with mobile devices employing only numeric keypad, etc.). The location engine 128 may provide the identification of cross streets.

[0102] The portal 108 may notify the user when a friend on the user's list is “nearby.” For example, if a friend on the user's friends list is in the same cell sector as the user, then the portal 108 may provide an SMS message to the user to identify the friend and indicate that such a friend is “very nearby.”

[0103] As another example, the user may find friends or other individuals sharing a similar interest who are within a certain radius or based on other criteria. As explained below, the portal database 124 may store public profiles for each user of the location-based services described herein. This public profile may include hobbies, interests, and other information regarding that individual. Thus, a user may attempt to locate anyone within 200 meters that likes golf so that the user can send a meeting request and establish a foursome. Many other examples are possible, as described herein.

[0104] FIGS. 13-16 are data and function flow diagrams illustrating how the system 100 finds nearby places for the user, finds nearby friends for the user, permits the user to edit his or her friends list, and permits the user to RSVP to friends in response to meeting requests, respectively. Details regarding these functions are provided below with respect to FIGS. 17-33 .

[0105] More specifically, FIGS. 13 though 16 show examples of software routines or subroutines that provide functionality shown or described in greater detail with respect to FIGS. 17 through 33 and the previous Figures described above. Without sacrificing clarity, but for brevity, and to orient those skilled (or unskilled) in the art, portions of FIG. 13 will now be discussed in detail. From these detailed discussions of FIG. 13 , one can more readily understand Figures 14 through 16 , even though those skilled in the relevant art will find FIGS. 13-16 self-explanatory.

[0106] As shown in FIG. 13 , a FindNearbyController routine 1300 initializes and provides to the user a page “FindNearbyPage” 1302 , which presents to the user the choice between finding a nearby place or a friend. In the example FIG. 13 , the user selects “place,” and in response, the system initiates a subroutine NearbySearchController 1304 which interacts with a subroutine CategoryListBuilding 1306 , which gets all categories from a category database CategoryFactory. The server may execute a script or other executable code to generate a page or other display to the user. Thus, while aspects of this embodiment are described with respect to, for example, providing or displaying the FindNearbyPage page, the system may actually execute a script entitled FindNearbyPage to generate a page or display that is transmitted for display on the user's mobile device. Thus, for the sake of brevity, but without sacrificing clarity, the following discussion simply refers to displaying or providing a page to the user.

[0107] The user next receives a page “NearbyPlaceMenuPage” 1308 which provides the option between restaurants and bars/pubs, or more places. If the user selects “more,” then the NearbySearchController 1304 requests more categories to display to the user from the CategoryListBuilding 1306 . In this example, the user selects “restaurant,” and in response a subroutine PlaceSearchRadiusController 1310 displays to the user a search radius page, which provides search radius options of one, five, and fifteen miles, or other (shown as “PlaceSearchRadiusOptionPage” 1312 ). After selecting a search radius, a subroutine PlaceSearchResultController 1314 launches and gets the information based on the user choice within the radius from the location engine 128 and displays location information. If the user had selected “other” from the page 1312 , then the user receives a page “PlaceSearchRadiuslnputPage” 1316 . If nothing was found within the selected radius, then the user receives a page “NoLocationsFoundPage” 1318 that allows the user to return to the routine FindNearbyController 1300 , or to select another radius from the page 1310 .

[0108] A subroutine PlaceListBuilder 1320 finds places from the selected category and within the selected radius, while maintaining a session. A subroutine FriendLocator 1322 calls the GMLC 126 , and the location agent 128 , which provides location data regarding the location of, for example, the user's mobile device. Places in the selected category and within the selected radius are provided to the user via a NearbyPlaceInfoPage 1324 , which in this example, shows a McDonald's 0.5 miles away, and a Burger King one mile away. The user may receive more details regarding a selected place, where such details are provided in a NearbyPlaceDetailsPage 1326 . From the page 1326 , the user may call the displayed location, or receive directions thereto, via a subroutine NearbyPlaceDescriptionController 1328 . Following the page 1328 , a subroutine DirectionsController 1330 receives source and destination information and obtains directions to provide to the user.

[0109] FIG. 14 shows routines and functionality similar to that of FIG. 13 , but for when a user selects “friends” from page 1302 . FIG. 15 shows routines and functionality for permitting the user to adjust permissions with respect to providing location information to friends, as described herein. FIG. 16 shows routines and functionality for coordinating a meeting with a friend, in particular, providing RSVP functionality to provide notification or confirmation to an individual of the meeting.

[0110] Representative User Interface

[0111] Representative user interface screens for displaying information to users, and associated logic branching and functionality, will now be discussed with respect to FIGS. 17 through 34 . These figures show examples of information displayed to a user (“display pages”), and examples of choices selected by the user. Those skilled in the relevant art will readily recognize that other examples are possible. Likewise, FIGS. 17 through 34 are generally self-explanatory to one skilled in the relevant art (based on the detailed description provided herein). Aspects of some initial user displays and functionality will be described in detail, but subsequent displays and functionality may be described in less detail. Those skilled in relevant art will recognize that subsequently discussed displays and functionality have much of the same details as those described previously. While the following discussion describes providing information to the user, the portal 108 actually provides, via the gateway 104 , a display page for display on the wireless device 102 or other communication to the user.

[0112] The display pages may be implemented in WAP, XML (Extensible Markup Language), HTML (HyperText Markup Language), Handheld Device Markup Language (HDML), Wireless Markup Language (WML) or other language or scripts that provide information to a user. The display pages provide facilities to receive user input data, such as a fields to be filled in, one or more numbered items to be selected from menus, hypertext links to select, displays allowing one or more of several options to be selected, or other known user interface tools for receiving user input. Of course, while one or more ways of displaying information to users in pages are shown and described herein, those skilled in the relevant art will recognize that various other alternatives may be employed. The terms “screen,” “display page” and “page” are generally used interchangeably herein.

[0113] The display pages are stored as display descriptions, graphical user interfaces, or as other methods of depicting information on a computer screen (e.g., commands, links, fonts, colors, layout, sizes and relative positions, and the like), where the layout and information or content to be displayed on the page is stored in the database 124 (or other location). In general, a “link” refers to any resource locator identifying a resource on a network, such as a display description provided by an organization having a site or node on the network. A “display description,” as generally used herein, refers to any method of automatically displaying information on a display screen in any of the above-noted formats, as well as other formats, such as email or character/code-based formats, algorithm-based formats (e.g., vector generated), or matrix or bit-mapped formats.

[0114] Referring to FIG. 17 , the portal 108 provides a Main Menu to the user under block 1702 . As shown, the Main Menu provides the user with seven options: 1) locate friends, 2) locate on/off, 3) meet friend, 4) find nearest., 5) add/edit friends, 6) edit profile, and 7) help. The Main Menu provides the starting place, and initial branching, for options and functions provided to the user. Each of these options will be described in detail below.

[0115] As explained below, the system 100 permits users and friends to modify privileges and profiles whenever desired. Thus, users or friends may turn off the ability to have the system locate them (to “go invisible”). Likewise, users can modify their friends lists to permanently or temporarily remove friends from the list. Users and friends may create, edit and view public profiles that provide information regarding such users/friends. Further description of the ability for users to modify privileges in real time is described herein.

[0116] Referring to FIG. 18 , if the user selects “locate friends” (such as by depressing the “1” button on a mobile phone), the portal 108 provides a list of friends to the user in block 1802 . If the user selects a friend, the system 100 attempts to locate the friend, and if the friend cannot be found, provides a locate error message, and may send a locate alert SMS message to the user, as described herein. If the friend is found, then one of two results are provided to the user depending upon, e.g., how accurately the system 100 can locate the friend, as shown in blocks 1804 and 1806 .

[0117] If the user wishes to view more friends than those shown in the initial friends list under block 1802 , the user may ask the portal 108 to display more friends, as shown in block 1808 . Under block 1808 , additional friends are displayed to the user, together with the options to add a friend (as described below), or the ability to find all friends. In this example, the user has selected the option “find all” friends, and if the user has more than 20 friends, the system 100 provides under block 1810 an error message indicating that the system 100 cannot locate more than 20 friends at a time. The user can then request additional friends, or a subset of these 20 friends, under block 1810 . If the user elects to act on the 20 friends, or a subset thereof, both blocks 1810 and 1812 branch to an option menu 1816 that permits the user to call one or more friends, send an SMS message to one or more friends, or meet one or more friends. Likewise, after selecting the friend in block 1804 or 1806 , or finding all friends under block 1814 , the routine branches to the option menu 1816 .

[0118] Many display screens shown in the FIGS. 17 through 34 include options “OK” and “Menu”. Selecting the “OK” option selects a given choice or command displayed on the screen. The selecting the “Menu” option returns the user to the Main Menu. Additionally, many display screens shown in the FIGS. 17-34 , and other functionality described herein, provide specific, suitable values for certain parameters. Those skilled in the relevant art will readily recognize that system may employ other values. For example, while the system 100 is indicated above as not being able to locate more than 20 friends at a time, an alternative system may locate only 10 friends at a time, or may be capable of locating 30 or more friends simultaneously. Thus, such specific numbers or values provided herein are only examples, and many other values may be employed.

[0119] Referring FIG. 19 , if the user elects to call a selected friend under block 1816 , then in block in 1902 , the system 100 calls that friend, and the display shown in block 1902 is provided to the user. Alternatively, if the user elects to send an SMS message, then the user is shown an input screen (block 1904 ) in which to enter text, and after clicking “OK”, is shown a display (block 1906 ) indicating that the message has been sent. (The option for meeting a friend is described below.) Following blocks 1902 or 1906 , the routine branches back to displaying the Main Menu.

[0120] Referring to FIG. 20 , if the user wishes to turn his or her location on or off with respect to the system 100 , (also referred to as “going invisible/visible”), the portal 108 displays under block 2002 a screen indicating a current location status for the user. The user then may edit this state under a screen 2004 . Thus, the invisibility functions are provided as a top level menu item to permit the user to readily turn off the ability to locate the user with only a minimum number of keystrokes. Invisibility may be based on time, group, etc., such as “after 10 P.M. I don't want to be visible” or “only let my family find me.” The portal 108 saves the results, and the routine branches back to the Main Menu. Alternatively, some embodiments of the invention would maintain a list of friends to whom the user can never be invisible and from whom location permission cannot be withdrawn. Such a list would be useful for parents who wish to be able to locate their children, employers who wish to locate their deliverymen, or other persons who might sponsor a user's account.

[0121] Referring to FIG. 21 , if the user selects from the Main Menu to meet a friend, then under blocks 2102 or 2104 , the user may select a friend, and view a location of the friend in block 2106 . In block 2108 , the user receives a meeting area display page which provides the options: 1) meet near the friend, 2) meet near the user, or 3) meet between the user and the friend.

[0122] Referring to FIG. 22 , if the user selects to meet near him or herself, or near the user's friend, the system acquires the user's location. After selecting to meet near the user or the friend, the user receives a meeting place or POI category list under block 2202 . As shown, the list may include options such as restaurants, coffee shops, bars/pubs, bookstores, etc. Other examples of points of interest include pharmacies, hospitals, fire/police department locations, and other emergency-type locations. (In general, a point of interest may be any physical or geographic location.) The system provides a list of most common types of meeting places, as described herein. The meeting places are associated with a location or location context. The location context need not be an exact street location, but a general area, such as city, state, neighborhood, site (e.g., cell site). The portal database 124 , location engine 128 , or both, store such information regarding these points of interest.

[0123] If the user is too far away from his or her friend, then the user receives a too far display under block 2204 . If the user wishes to meet at a geographic midpoint, then the user receives one of three possible displays: multiple cities or neighborhoods are located at the midpoint (block 2206 ), the friend is in the same cell site or is otherwise nearby the user (block 2208 ), or the friend is in the same city or neighborhood as the user. If more than one city/neighborhood are available, then the user receives a city/neighborhood select screen, as shown in block 2210 .

[0124] Referring to FIG. 23 , after the user has selected a category of meeting places under block 2202 , the user receives a search radius screen under block 2302 to select a 1, 5, 15 or other mile radius. If the user selects a radius and no POI is found within that radius, the user receives an expand search screen 2304 , whereby the user may expand the radius (and is then returned to block 2302 ). If the user selects to enter a desired radius, the user may enter the desired radius in a radius input screen (blocks 2306 ). Under block 2308 , the user receives a list of POIs associated with the chosen meeting place category (in this example, restaurants). After selecting a restaurant, the user receives in block 2310 details on the selected restaurant, such as its address, a distance from the user, telephone number, and options to call the restaurant or receive directions to the restaurant. If the user selects to call the restaurant, the user receives a calling-display (block 2312 ).

[0125] Referring to