SYNCHRONIZED GROUP LOCATION UPDATES

Abstract

Systems and methods are disclosed in which a location update for a user is utilized as a location update for the user and one or more additional users that have been location-synchronized to the user. In general, a location update is received for a first user. One or more second users that have been location-synchronized to the first user are then identified. A location reported by the location update for the first user is recorded, or stored, as a current location of the first user and a current location of each of the one or more second users that have been location-synchronized to the first user. A location-based service, such as a social location-based service, may then be provided based on the current locations of the first and one or more second users.

Description

RELATED APPLICATIONS

This application claims the benefit of provisional patent application Ser. No. 61/309,903, filed Mar. 3, 2010, the disclosure of which is hereby incorporated herein by reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to location updates.

BACKGROUND

Social Location-Based Services (SLBSs), such as the Gowalla® and FourSquare™ check-in services, require constant location updates to be accurate and useful. However, in many situations, users either are not capable of providing location updates (e.g., they do not have their mobile device with them or turned on) or do not desire to provide location updates (e.g., they are too busy talking with friends). As such, there is a need for a system and method that enables location updates from users even in situations where those users are not capable of providing or do not desire to provide location updates.

SUMMARY

Systems and methods are disclosed in which a location update for a user is utilized as a location update for the user and one or more additional users that have been location-synchronized to the user. In general, a location update is received for a first user. One or more second users that have been location-synchronized to the first user are then identified. A location reported by the location update for the first user is recorded, or stored, as a current location of the first user and a current location of each of the one or more second users that have been location-synchronized to the first user. A location-based service, such as a social location-based service, may then be provided based on the current locations of the first and the one or more second users.

Those skilled in the art will appreciate the scope of the present disclosure and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

FIG. 1 illustrates an exemplary system in which a location update for a user is utilized as a location update for a corresponding location-synchronized group of users according to one embodiment of the present disclosure;

FIG. 2 illustrates the operation of the system of FIG. 1 according to one embodiment of the present disclosure;

FIG. 3 illustrates the operation of a location update server of the Social Location-Based Service (SLBS) of FIG. 1 to receive and process a location update according to one embodiment of the present disclosure;

FIG. 4 illustrates the operation of the location update server of the SLBS of FIG. 1 to create and maintain location-synchronized groups of users according to one embodiment of the present disclosure;

FIG. 5 illustrates the operation of the location update server of the SLBS of FIG. 1 to create and maintain location-synchronized groups of users according to another embodiment of the present disclosure;

FIG. 6 illustrates the operation of the location update server of the SLBS of FIG. 1 to create and maintain location-synchronized groups of users according to yet another embodiment of the present disclosure;

FIG. 7 illustrates the operation of the location update server of the SLBS of FIG. 1 to de-synchronize users in location-synchronized groups of users according to one embodiment of the present disclosure;

FIG. 8 illustrates the operation of the location update server of the SLBS of FIG. 1 to de-synchronize users in location-synchronized groups of users according to another embodiment of the present disclosure;

FIG. 9 illustrates the operation of the location update server of the SLBS of FIG. 1 to de-synchronize users in location-synchronized groups of users according to yet another embodiment of the present disclosure;

FIG. 10 is a block diagram of a computer server that hosts the SLBS of FIG. 1 according to one embodiment of the present disclosure; and

FIG. 11 is a block diagram of one of the mobile devices in the system of FIG. 1 according to one embodiment of the present disclosure.

DETAILED DESCRIPTION

The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

FIG. 1 illustrates a system 10 in which a location update for a user is utilized as a location update for a corresponding location-synchronized group of users according to one embodiment of the present disclosure. As illustrated, the system 10 includes a Social Location-Based Service (SLBS) 12 and a number of mobile devices 14-1 through 14-N having associated users 16-1 through 16-N connected by a network 18. The mobile devices 14-1 through 14-N are more generally referred to herein collectively as mobile devices 14 and individually as mobile device 14. Similarly, the users 16-1 through 16-N are more generally referred to herein collectively as users 16 and individually as user 16. The network 18 may be any type of Wide Area Network (WAN) or Local Area Network (LAN), or any combination thereof. For example, in one preferred embodiment, the network 18 is a distributed public network, such as the Internet, where the mobile devices 16 are connected to the network 18 via local wireless connections (e.g., IEEE 802.11x connections through corresponding IEEE 802.11x base stations or access points) or mobile communications connections. Mobile communications connections may be, for example, 3 G wireless connections such as, for example, Global System for Mobile communications (GSM) or Code Division Multiple Access (CDMA) wireless connections, 4 G wireless connections such as, for example, Wideband CDMA (W-CDMA) or Long Term Evolution (LTE) wireless connections, or the like.

The SLBS 12 is generally any type of social location-based service and is preferably implemented in software hosted by a computer server or a number of computer servers operating in a collaborative manner for purposes of load sharing and/or redundancy. As an example, the SLBS 12 may be a Mobile Aggregate Profile (MAP) service such as that described in U.S. patent application Ser. No. 12/645,532, entitled FORMING CROWDS AND PROVIDING ACCESS TO CROWD DATA IN A MOBILE ENVIRONMENT, which was filed Dec. 23, 2009; U.S. patent application Ser. No. 12/645,539, entitled ANONYMOUS CROWD TRACKING, which was filed Dec. 23, 2009; U.S. patent application Ser. No. 12/645,535, entitled MAINTAINING A HISTORICAL RECORD OF ANONYMIZED USER PROFILE DATA BY LOCATION FOR USERS IN A MOBILE ENVIRONMENT, which was filed Dec. 23, 2009; U.S. patent application Ser. No. 12/645,546, entitled CROWD FORMATION FOR MOBILE DEVICE USERS, which was filed Dec. 23, 2009; U.S. patent application Ser. No. 12/645,556, entitled SERVING A REQUEST FOR DATA FROM A HISTORICAL RECORD OF ANONYMIZED USER PROFILE DATA IN A MOBILE ENVIRONMENT, which was filed Dec. 23, 2009; U.S. patent application Ser. No. 12/645,560, entitled HANDLING CROWD REQUESTS FOR LARGE GEOGRAPHIC AREAS, which was filed Dec. 23, 2009; and U.S. patent application Ser. No. 12/645,544, entitled MODIFYING A USER'S CONTRIBUTION TO AN AGGREGATE PROFILE BASED ON TIME BETWEEN LOCATION UPDATES AND EXTERNAL EVENTS, which was filed Dec. 23, 2009; all of which are hereby incorporated herein by reference in their entireties. As described in the aforementioned published U.S. patent applications, the MAP service operates to, among other things, create and maintain a historical record of anonymized user profile data by geographic location and to create and track crowds of users all based on location updates received for users of the MAP service. Note, however, that the SLBS 12 is not limited to the MAP service. For example, the SLBS 12 may alternatively be a check-in service similar to the FourSquare™ check-in service or the Gowalla® check-in service. Other types of social location-based services will be apparent to one of ordinary skill in the art upon reading this disclosure and are to be considered within the scope of the present disclosure.

As illustrated, the SLBS 12 includes a location update server 20 and a user records repository 22. The location update server 20 is preferably implemented in software and generally operates to receive location updates, process the location updates, and update user records of the users 16 stored in the user records repository 22. As described below in detail, location-synchronized groups of users are created either manually by the users 16 or programmatically by the location update server 20. The location-synchronized groups of users are recorded in the user records of the users 16 stored in the user records repository 22.

The user records repository 22 generally includes a user record for each of the users 16, where each of the users 16 is a registered user of the SLBS 12. The user record of each of the users 16 includes a current location of the user 16. In addition, the user record of the user 16 includes a list of other users that are location-synchronized to the user 16 and/or an identifier of another user 16 to which the user 16 is location-synchronized. Note that, in one embodiment, the other users that are location-synchronized to the user 16 may all be users 16 of the SLBS 12. However, in another embodiment, the other users that are location-synchronized to the user 16 may include one or more of the users 16 of the SLBS 12 and/or users (e.g., user 32, discussed below) that are not registered with the SLBS 12. In some embodiments, the user record of the user 16 may also include a historical record of location updates received for the user 16 that includes one or more previous locations of the user 16 as defined by one or more previous location updates for the user 16. Still further, in some embodiments, the user record of the user 16 may include one or more user settings defined by the user 16 for use by the location update server 20 in programmatically location-synchronizing the user 16 to other users 16, programmatically location-synchronizing other users 16 to the user 16, programmatically de-synchronizing the user 16 from other users 16, and/or programmatically de-synchronizing other users 16 from the user 16.

In some embodiments, the user records repository 22 may also store user records for each of a number of non-registered users of the SLBS 12 such as, for example, user 32 (discussed below). For each non-registered user, the user record of that non-registered user includes a current location of the non-registered user. Further, the current location of the non-registered user is the current location of the user 16 to which the non-registered user has been location-synchronized. The user record of the non-registered user may also include user profile data, which may be provided by the non-registered user or obtained from a third-party source (e.g., the non-registered user's Facebook® profile).

The mobile devices 14 may be mobile smart phones, portable media player devices, mobile gaming devices, mobile computers (e.g., laptop computers), or the like. Some exemplary mobile devices that may be programmed or otherwise configured to operate as the mobile devices 14 are the Apple® iPhone®, the Palm Pre®, the Samsung Rogue™, the Blackberry Storm™, the Motorola DROID or similar phone running Google's Android™ Operating System, an Apple® iPad®, and the Apple® iPod Touch® device. However, this list of exemplary mobile devices is not exhaustive and is not intended to limit the scope of the present disclosure.

The mobile devices 14-1 through 14-N include SLBS clients 24-1 through 24-N (generally referred to herein collectively as SLBS clients 24 or individually as SLBS client 24) which include corresponding location update clients 26-1 through 26-N (generally referred to herein collectively as location update clients 26 and individually as location update client 26). The mobile devices 14-1 through 14-N also include location functions 28-1 through 28-N (generally referred to herein collectively as location functions 28 and individually as location function 28).

The SLBS clients 24 are preferably implemented in software and generally operate to provide an interface by which the mobile devices 14 and the users 16 interact with the SLBS 12. The location update clients 26 generally operate to obtain current locations of the mobile devices 14, and thus the users 16, from the location functions 28 and send corresponding location updates to the location update server 20 of the SLBS 12. The location update clients 26 may send the location updates periodically, in response to triggering events such as a change in the location of the users 16, or in response to a request from the location update server 20. As discussed below, the location updates may be for geographic locations at which the users 16 are located (e.g., latitude and longitude, street address, or the like) or for “check-in” locations. “Check-in” locations are Points of Interest (POIs) at or near the current geographic locations of the users 16 that have been selected by the users 16, or programmatically selected on behalf of the users 16, for “check-in” in a manner similar to that done for check-in services such as, for example, the FourSquare™ and Gowalla® check-in services.

For each mobile device 14, the location function 28 of the mobile device 14 may be implemented in hardware, software, or a combination thereof. In general, the location function 28 of the mobile device 14 operates to determine or otherwise obtain the geographic location of the mobile device 14. For example, the location function 28 of the mobile device 14 may be, or include, a Global Positioning System (GPS) receiver. In addition or alternatively, the location function 28 may include hardware and/or software that enables improved location tracking in indoor environments such as, for example, shopping malls. For example, the location function 28 may be part of, or compatible with, the InvisiTrack Location System provided by InvisiTrack and described in U.S. Pat. No. 7,423,580 entitled “Method and System of Three-Dimensional Positional Finding” which issued on Sep. 9, 2008, U.S. Pat. No. 7,787,886 entitled “System and Method for Locating a Target using RFID” which issued on Aug. 31, 2010, and U.S. Patent Application Publication No. 2007/0075898 entitled “Method and System for Positional Finding Using RF, Continuous and/or Combined Movement” which published on Apr. 5, 2007, all of which are hereby incorporated herein by reference for their teachings regarding location tracking.

In this embodiment, the system 10 also includes a guest device 30 having an associated user 32. The guest device 30 may be a mobile device similar to the mobile devices 14 or other computing device (e.g., a personal computer). The user 32 is enabled to access the SLBS 12 via the guest device 30 to, for example, request to be location-synchronized with a select one of the users 16. Notably, the user 32 is not a registered user of the SLBS 12. Further, while only one guest device 30 and associated user 32 are illustrated, the system 10 may include multiple guest devices 30 and associated users 32.

FIG. 2 illustrates the operation of the system 10 of FIG. 1 according to one embodiment of the present disclosure. As illustrated, the mobile device 14, and more specifically the location update client 26 of the SLBS client 24 of the mobile device 14, sends a location update to the SLBS 12 for the user 16 of the mobile device 14 (step 100). The location update includes a current location of the user 16. In one embodiment, the current location of the user 16 is the current geographic location of the mobile device 14, and thus the user 16, as determined by the location function 28 of the mobile device 14. In this case, the current location of the user 16 may be expressed as any data that defines the location of the user 16 in 2-dimensional or 3-dimensional space. For example, in one embodiment, the current location of the user 16 may be expressed as a latitude and longitude coordinate pair and, in some embodiments, an altitude. As another example, the current location of the user 16 may be expressed as a street address. In another embodiment, the current location of the user 16 may be a “check-in” location selected by the user 16 or programmatically selected by the SLBS client 24 on behalf of the user 16. More specifically, the SLBS client 24 may interact with the SLBS 12 to obtain a list of one or more POIs at or near the current geographical location of the user 16 (e.g., street address, latitude and longitude, or the like) as determined by the location function 28. In one embodiment, the SLBS client 24 may then present the list of POIs to the user 16, and the user 16 may select a POI for which to “check-in.” The location update for the user 16 may then be expressed as data that identifies the POI selected by the user 16 for check-in.

Next, the location update server 20 of the SLBS 12 identifies one or more other users that are location-synchronized to the user 16 (step 102). The other users that are location-synchronized to the user 16 may include only other ones of the users 16 of the SLBS 12, only non-registered users of the SLBS 12 such as the user 32, or one or more of the other users 16 of the SLBS 12 and non-registered users of the SLBS such as the user 32 depending on the particular implementation. Several embodiments of a process by which other users are location-synchronized to the user 16 are described below in detail. The location update server 20 of the SLBS 12 then records the location of the user 16 of the mobile device 14 reported in the location update as the current location of the user 16 of the mobile device 14 and the current location(s) of the other user(s) that are location-synchronized to the user 16 (step 104). The location reported in the location update is recorded as the current locations of the user 16 and the other user(s) that are location-synchronized to the user 16 by storing the location as the current locations in the user records of those users 16. The SLBS 12 provides a desired social location-based service to the users 16 of the SLBS 12 using the current locations of the users 16 and, in some embodiments, the current locations of non-registered users (step 106).

FIG. 3 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to receive and process location updates according to one embodiment of the present disclosure. As illustrated, the location update server 20 receives a location update for one of the users 16 (step 200). The location update server 20 then determines whether any users are location-synchronized to the user 16 (step 202). If not, the process proceeds to step 206. If so, then the location update server 20 records, or stores, the location reported by the location update as the current location of the user(s) that are location-synchronized to the user 16 (step 204). In addition, the location update server 20 records, or stores, the location reported by the location update as the current location of the user 16 for which the location update was received (step 206). The process then returns to step 200 and is repeated for the next received location update from one of the users 16.

FIG. 4 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to create and maintain location-synchronized groups of users according to one embodiment of the present disclosure. In this embodiment, requesting users manually request other users 16 to which to be location-synchronized. More specifically, the location update server 20 of the SLBS 12 first receives a location-synchronization request from a requesting user (step 300). The requesting user may be one of the users 16 of the SLBS 12. In some embodiments, the requesting user may alternatively be a non-registered user such as, for example, the user 32 of the guest device 30. The location-synchronization request is a request from the requesting user to be location-synchronized to a select one of the users 16 of the SLBS 12 (referred to herein as the “select user”). The select user is identified in the location-synchronization request. Further, the manner in which the select user is selected by the requesting user may vary depending on the particular implementation. For example, the requesting user may select the select user by entering an identifier (ID) of the select user for the SLBS 12, entering an e-mail address that may be utilized by the SLBS 12 to identify one of the users 16 as the select user, selecting the select user from a list of users such as, for example, a contact list of the requesting user maintained by the SLBS 12, or the like.

In some embodiments, the location-synchronization request may also include one or more settings configured by the requesting user that define when the requesting user is to be de-synchronized from the select user (i.e., define when the requesting user is to no longer be location-synchronized to the select user). The settings may include one or more time-based settings. For example, the settings may include a setting that defines an amount of time that the requesting user is to be location-synchronized to the select user or an end-time that defines the time at which the requesting user is to be de-synchronized from the select user. It should be noted that while the settings may be included in the location-synchronization request, the settings may alternatively be predefined by the requesting user and included in the user record of the requesting user.

In response to receiving the location-synchronization request, the location update server 20 of the SLBS 12 records, or stores, the requesting user as a location-synchronized user of the select user (step 302). More specifically, in one embodiment, the location update server 20 adds the requesting user to a list of location-synchronized users of the select user maintained in the user record of the select user. In another embodiment, the location update server 20 adds the select user as the user to which the requesting user is location-synchronized, which may be maintained in the user record of the requesting user. From this time and until the requesting user and the select user are de-synchronized, location updates for the select user will also be recorded as location updates for the requesting user.

FIG. 5 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to create and maintain location-synchronized groups of users according to another embodiment of the present disclosure. In this embodiment, the users 16 manually request other users that are to be location-synchronized to the users 16. More specifically, the location update server 20 of the SLBS 12 first receives a location-synchronization request from a requesting user, which in this embodiment is one of the users 16 of the SLBS 12 (step 400). In this embodiment, the location-synchronization request is a request from the requesting user for a select user, or possibly multiple select users, to be location-synchronized to the requesting user. The select user is identified in the location-synchronization request. Depending on the embodiment, the select user may be a select one of the users 16 of the SLBS 12, a non-registered user such as but not limited to the user 32 of the guest device 30, or either a select one of the users 16 of the SLBS 12 or a non-registered user. Further, the manner in which the select user is selected by the requesting user may vary depending on the particular implementation. For example, the requesting user may select the select user by entering an ID of the select user for the SLBS 12, entering an e-mail address that may be utilized by the SLBS 12 to identify the select user, selecting the select user from a list of users such as, for example, a contact list of the requesting user, or the like.

In some embodiments, the location-synchronization request may also include one or more settings configured by the requesting user that define when the select user is to be de-synchronized from the requesting user (i.e., define when the select user is to no longer be location-synchronized to the requesting user). The settings may include one or more time-based settings. For example, the settings may include a setting that defines an amount of time that the select user is to be location-synchronized to the requesting user or an end-time that defines the time at which the select user is to be de-synchronized from the requesting user. It should be noted that while the settings may be included in the location-synchronization request, the settings may alternatively be predefined by the requesting user and included in the user record of the requesting user.

In response to receiving the location-synchronization request, the location update server 20 of the SLBS 12 records, or stores, the select user as a location-synchronized user of the requesting user (step 402). More specifically, in one embodiment, the location update server 20 adds the select user to a list of location-synchronized users of the requesting user maintained in the user record of the requesting user. In another embodiment, the location update server 20 adds the requesting user as the user to which the select user is location-synchronized, which may be maintained in the user record of the select user. From this time and until the requesting user and the select user are de-synchronized, location updates for the requesting user will also be recorded as location updates for the select user.

FIG. 6 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to create and maintain location-synchronized groups of users according to yet another embodiment of the present disclosure. In this embodiment, the location update server 20 programmatically selects users to be location-synchronized. As illustrated, the location update server 20 first determines whether a particular user pair should be location-synchronized (step 500). More specifically, the location update server 20 determines whether a first user in the user pair should be location-synchronized to a second user in the user pair. The determination may be made based on user settings of one or both of the users in the user pair, one or more system-defined rules, the current location of one or both of the users in the user pair, historical locations of one or both of the users in the user pair, information obtained from one or more third-party sources that is indicative of spatial proximity of the first and second user at the current time or historically, or a combination thereof. The third-party source may include, for example, the Twitter® micro-blogging and social networking service where current and/or historical tweets from the two users that are tagged with the geographic locations of the users in the user pair at the time of sending the tweets are utilized to determine the current and/or historical spatial proximity of the two users. A text analysis of the tweet may additionally or alternatively be analyzed to determine users that the sending user is near at that time. As an example, user settings of one or both of the users in the user pair may indicate that the first user is to be location-synchronized to the second user if a location update has not been received from the first user within a defined amount of time (e.g., 30 minutes) and the two users have been located together for at least a defined amount of time (e.g., past 2 hours). As another example, user settings of one or both of the users in the user pair may indicate that the first user is to be location-synchronized to the second user if the first user has historically been located at the same location as the second user. As a more specific example, if the current time is 7 pm on a Friday evening, the user settings of one or both of the users may indicate that the first user is to be location-synchronized to the second user if the first user has been located at the same location as the second user on each of the last three Friday evenings from 7 pm to 10 pm. Note that while the examples above are based on user settings, system-defined rules may additionally or alternatively be used.

If the location update server 20 determines that the first user is to be location-synchronized to the second user, then the location update server 20 records the first user as a location-synchronized user of the second user (step 502). In some embodiments, a weight may be assigned to the first user as a location-synchronized user of the second user that reflects a degree of certainty, or sureness, that the first user should be location-synchronized to the second user. This weighting may subsequently be adjusted by users, such as but not limited to the first user or the second user, or other entities. Such feedback may be utilized by the location update server 20 to improve its methods of determining when it is appropriate to location-synchronize these particular users and/or users in the system in general based on, for example, a statistical analysis of the feedback. In this example, the process ends, at least with respect to this particular user pair. It should be noted that the process of FIG. 6 may be performed in response to a triggering event and may also be repeated for additional user pairs. For example, the process of FIG. 6 may be performed in response to receiving a location update for the second user and may be repeated for a number of user pairs that each include the second user (e.g., N−1 user pairs that each include the second user and a different one of the users 16). As a more specific example, the process of FIG. 6 may be performed between steps 200 and 202 of the process of FIG. 3 such that any additional users that should be location-synchronized to the second user are identified before the location reported in the location update for the second user is recorded as the current locations of the other users 16 that are location-synchronized to the second user.

FIG. 7 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to de-synchronize users in location-synchronized groups of users according to one embodiment of the present disclosure. In this embodiment, requesting users manually request users 16 from which to be de-synchronized. More specifically, the location update server 20 of the SLBS 12 first receives a de-synchronization request from a requesting user (step 600). In one embodiment, the requesting user is one of the users 16 of the SLBS 12. In another embodiment, the requesting user is a non-registered user of the SLBS 12. In yet another embodiment, the requesting user is either one of the users 16 of the SLBS 12 or a non-registered user of the SLBS 12. The de-synchronization request is a request from the requesting user to be de-synchronized, or removed, as a location-synchronized user of a select user. The select user is a select one of the users 16 and is identified in the de-synchronization request. Further, the manner in which the select user is selected by the requesting user may vary depending on the particular implementation. For example, the requesting user may select the select user by entering an ID of the select user for the SLBS 12, entering an e-mail address that may be utilized by the SLBS 12 to identify one of the users 16 as the select user, selecting the select user from a list of users such as, for example, a contact list of the requesting user maintained by the SLBS 12, or the like.

In response to receiving the de-synchronization request, the location update server 20 of the SLBS 12 removes the requesting user as a location-synchronized user of the select user (step 602). More specifically, in one embodiment, the location update server 20 removes the requesting user from a list of location-synchronized users of the select user maintained in the user record of the select user. In another embodiment, the location update server 20 removes the select user as the user to which the requesting user is location-synchronized as maintained in the user record of the requesting user.

FIG. 8 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to de-synchronize users in location-synchronized groups of users according to another embodiment of the present disclosure. In this embodiment, requesting users manually request users 16 that are to be de-synchronized from the requesting user. More specifically, the location update server 20 of the SLBS 12 first receives a de-synchronization request from a requesting user, which in this embodiment is one of the users 16 of the SLBS 12 (step 700). In this embodiment, the de-synchronization request is a request from the requesting user for a select user, or possibly multiple select users, to be de-synchronized from the requesting user. The select user is identified in the de-synchronization request and may be another one of the users 16 of the SLBS 12 or a non-registered user depending on the particular implementation. Further, the manner in which the select user is selected by the requesting user may vary depending on the particular implementation. For example, the requesting user may select the select user by entering an ID of the select user for the SLBS 12, entering an e-mail address that may be utilized by the SLBS 12 to identify the select user, selecting the select user from a list of users such as, for example, a contact list of the requesting user, or the like.

In response to receiving the de-synchronization request, the location update server 20 of the SLBS 12 removes the select user as a location-synchronized user of the requesting user (step 702). More specifically, in one embodiment, the location update server 20 removes the select user from a list of location-synchronized users of the requesting user maintained in the user record of the requesting user. In another embodiment, the location update server 20 removes the requesting user as the user to which the select user is location-synchronized as maintained in the user record of the select user.

FIG. 9 illustrates the operation of the location update server 20 of the SLBS 12 of FIG. 1 to de-synchronize users in location-synchronized groups of users according to yet another embodiment of the present disclosure. In this embodiment, the location update server 20 programmatically de-synchronizes users. As illustrated, the location update server 20 first determines whether a particular user pair should be de-synchronized (step 800). More specifically, the location update server 20 determines whether a first user in the user pair should be de-synchronized from second user in the user pair. The determination may be made based on user settings of one or both of the users in the user pair, one or more system-defined rules, the current location of one or both of the users in the user pair, historical locations of one or both of the users in the user pair, information obtained from one or more third-party sources that is indicative of spatial proximity of the first and second users, or a combination thereof. For example, user settings of one or both of the users in the user pair may indicate that the first user is to be de-synchronized from the second user if a location update is received from the first user and the reported location of the first user is different from (e.g., more than a pre-defined distance from) the current location of the second user. Note that while the examples above are based on user settings, system-defined rules may additionally or alternatively be used. As another example, the user settings may indicate that the first user is to be de-synchronized from the second user once the first user is no longer spatially proximate to the second user (e.g., not within a predefined distance from the second user, not at the same street address as the second user, or the like).

If the location update server 20 determines that the first user is to be de-synchronized from the second user, then the location update server 20 de-synchronizes the users by removing the first user as a location-synchronized user of the second user (step 802). In this example, the process ends, at least with respect to this particular user pair. It should be noted that the process of FIG. 9 may be performed in response to a triggering event and may also be repeated for additional user pairs. For example, the process of FIG. 9 may be performed in response to receiving a location update for the second user and may be repeated for a number of location-synchronized user pairs that each include the second user and a different user that is location-synchronized to the second user. As a more specific example, the process of FIG. 9 may be performed between steps 200 and 202 of the process of FIG. 3 such that any users that should be de-synchronized from the second user are identified and removed before the location reported in the location update for the second user is recorded as the current locations of the location-synchronized users of the second user.

While FIGS. 7 through 9 illustrate three exemplary processes by which users are de-synchronized, other processes may be used. For example, in one embodiment, when users are location-synchronized, de-synchronization of those users is scheduled for a defined point in time in the future. For instance, a synchronization request from a requesting user may define an amount of time that the users are to be location-synchronized or define a specific time at which de-synchronization is to occur. In this case, the location update server 20 may schedule de-synchronization at the appropriate time and perform de-synchronization at that time. In a similar manner, when users are programmatically location-synchronized, the user settings of one or both of the users or system-defined settings may define an amount of time that the users are to be synchronized. The location update server 20 may then schedule de-synchronization at the appropriate time and then de-synchronize the users at that time.

FIG. 10 is a block diagram of a computer server 36 hosting the SLBS 12 according to one embodiment of the present disclosure. As illustrated, the computer server 36 includes a controller 38 connected to memory 40, one or more secondary storage devices 42, and a communication interface 44 by a bus 46 or similar mechanism. The controller 38 is a microprocessor, digital Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or similar hardware component. In this embodiment, the controller 38 is a microprocessor, and the SLBS 12 is implemented in software and stored in the memory 40 for execution by the controller 38. Further, the user records repository 22 may be stored in the memory 40 or the one or more secondary storage devices 42. The secondary storage devices 42 are digital data storage devices such as, for example, one or more hard disk drives. The communication interface 44 is a wired or wireless communication interface that communicatively couples the computer server 36 to the network 18 (FIG. 1). For example, the communication interface 44 may be an Ethernet interface, local wireless interface such as a wireless interface operating according to one of the suite of IEEE 802.11 standards, or the like.

FIG. 11 is a block diagram of one of the mobile devices 14 according to one embodiment of the present disclosure. This discussion is equally applicable to the other mobile devices 14. As illustrated, the mobile device 14 includes a controller 48 connected to memory 50, a communication interface 52, one or more user interface components 54, and the location function 28 by a bus 56 or similar mechanism. The controller 48 is a microprocessor, digital ASIC, FPGA, or similar hardware component. In this embodiment, the controller 48 is a microprocessor, and the SLBS client 24 is implemented in software and stored in the memory 50 for execution by the controller 48. In this embodiment, the location function 28 is a hardware component such as, for example, a GPS receiver. The communication interface 52 is a wireless communication interface that communicatively couples the mobile device 14 to the network 18 (FIG. 1). For example, the communication interface 52 may be a local wireless interface such as a wireless interface operating according to one of the suite of IEEE 802.11 standards, a mobile communications interface such as a cellular telecommunications interface (e.g., 3 G telecommunications interface such as a GSM interface or the like, or a 4 G telecommunications interface such as a LTE interface or the like). The one or more user interface components 54 include, for example, a touchscreen, a display, one or more user input components (e.g., a keypad), a speaker, or the like, or any combination thereof.

The following use case is provided to illustrate some, but not necessarily all, of the embodiments described above. This use case is provided for illustrative purposes only and is not intended to limit the scope of the present disclosure in any manner whatsoever.

• • 1. Jack is planning a night on the town with his girlfriend, Sarah, and his friends Sam, Jessica, Frank, and Charlene. Sarah, Jessica, Sam, and Jack are all users 16 of the SLBS 12. Since Sarah and Jessica are dressed up and did not want to have to bother with purses and Sam did not want to potentially lose his mobile device 14, they have all opted to leave their mobile devices 14 in Jack's car and let Jack represent them to the SLBS 12.
  • 2. Before they leave for downtown, Sarah, Jessica, and Sam all log into the SLBS 12 via their mobile devices 14 and request to be synchronized with Jack for the night. Jack logs into the SLBS 12 and accepts their requests and requests that the SLBS 12 also synchronize two more friends, namely Frank and Charlene, to him for the night.
  • 3. Using the SLBS 12, Jack peruses crowds downtown, particularly paying attention to crowds at a few potentially desirable POIs. Jack eventually chooses one POI and has the SLBS 12 give him directions to that POI.
  • 4. The SLBS 12 sends an alert that includes information about Jack and his group to advanced users (e.g., owners or managers) of the POIs in which he has shown an interest. The SLBS 12 also gives the advanced user of the POI chosen by Jack an estimate for time of arrival.
  • 5. The advanced users of the POIs in which Jack has expressed an interest may send some incentives to Jack and his group of synchronized users in hopes of attracting them.
  • 6. Jack and his group end up going to the chosen POI, and they are able to get a dollar off admission each for going there.
  • 7. They run into their friend Randolph, who is also a user 16 of the SBLS 12. Randolph decides to hang with Jack and his group for the evening.
  • 8. As the night goes on and Jack updates his location, the SLBS 12 automatically updates the locations of all of the other users that are synchronized to Jack.
  • 9. After Randolph updates his location at one of the same locations as Jack, the SLBS 12 determines that Randolph has been part of Jack, Sarah, Sam, and Jessica's groups in the past. In response, the SLBS 12 programmatically, or automatically, synchronizes Randolph to Jack. Since the SLBS 12 is not certain that Randolph should be synchronized with Jack, location updates received from Jack are also stored for Randolph but with a lower weighting or sureness value.
  • 10. After the SLBS 12 finds a tweet by Randolph that the SLBS 12 determines means he is hanging out with Jack's group, the SLBS 12 increases the sureness value of location updates from Jack that are stored as Randolph's location.
  • 11. Jessica had made plans to meet up with some other friends later on in the evening, so she takes her mobile device 14 from Jack's car and heads out to hang out with her other friends. The SLBS 12 sees that Jessica updates her location at least a predefined threshold distance from Jack, so it automatically de-synchronizes her from Jack.
  • 12. Finally, Jack's group heads their separate ways for the evening. After a specified amount of time has expired, the SLBS 12 automatically de-synchronizes the rest of the group from Jack.

Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Claims

1. A computer-implemented method comprising:

receiving a location update for a first user;

identifying one or more second users that have been location-synchronized to the first user in response to receiving the location update for the first user; and

recording a location reported in the location update for the first user as a current location of the first user and a current location of each of the one or more second users that have been location-synchronized to the first user.

2. The method of claim 1 further comprising providing a social location-based service based on current locations of a plurality of users comprising the first user and the one or more second users.

3. The method of claim 1 wherein the location reported in the location update for the first user is a current geographic location of the first user.

4. The method of claim 1 wherein the location reported in the location update for the first user is a check-in location for the first user.

5. The method of claim 1 further comprising, prior to receiving the location update for the first user:

receiving, from a requesting user, a request to location-synchronize the requesting user to the first user; and

recording the requesting user as being location-synchronized to the first user;

wherein identifying the one or more second users that have been location-synchronized to the first user comprises identifying the requesting user as one of the one or more second users that have been location-synchronized to the first user.

6. The method of claim 1 further comprising, prior to receiving the location update for the first user:

receiving, from the first user, a request to location-synchronize a select user to the first user; and

recording the select user as being location-synchronized to the first user;

wherein identifying the one or more second users that have been location-synchronized to the first user comprises identifying the select user as one of the one or more second users that have been location-synchronized to the first user.

7. The method of claim 1 further comprising, prior to receiving the location update for the first user:

programmatically determining that a user is to be location-synchronized to the first user; and

recording the user as being location-synchronized to the first user;

wherein identifying the one or more second users that have been location-synchronized to the first user comprises identifying the user as one of the one or more second users that have been location-synchronized to the first user.

8. The method of claim 7 wherein programmatically determining that the user is to be location-synchronized to the first user comprises programmatically determining that the user is to be location-synchronized to the first user based on one or more user settings.

9. The method of claim 7 wherein programmatically determining that the user is to be location-synchronized to the first user comprises programmatically determining that the user is to be location-synchronized to the first user based on one or more system-defined rules.

10. The method of claim 7 wherein programmatically determining that the user is to be location-synchronized to the first user comprises programmatically determining that the user is to be location-synchronized to the first user based on current locations of the first user and the user at that time.

11. The method of claim 7 wherein programmatically determining that the user is to be location-synchronized to the first user comprises programmatically determining that the user is to be location-synchronized to the first user based on one or more historical locations of the first user and the user.

12. The method of claim 7 wherein programmatically determining that the user is to be location-synchronized to the first user comprises programmatically determining that the user is to be location-synchronized to the first user based on information obtained from one or more third-party sources that is indicative of spatial proximity of the first user and the user.

13. The method of claim 1 further comprising:

receiving, from a requesting user, a request to de-synchronize the requesting user from the first user; and

de-synchronizing the requesting user from the first user such that the requesting user is no longer location-synchronized to the first user.

14. The method of claim 1 further comprising:

receiving, from the first user, a request to de-synchronize a select user from the first user; and

de-synchronizing the select user from the first user such that the select user is no longer location-synchronized to the first user.

15. The method of claim 1 further comprising, prior to receiving the location update for the first user:

programmatically determining that a user is to be de-synchronized from the first user; and

de-synchronizing the user from the first user such that the user is no longer location-synchronized to the first user.

16. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user after a defined amount of time has expired since the user was location-synchronized to the first user.

17. The method of claim 16 wherein the defined amount of time is defined by the user.

18. The method of claim 16 wherein the defined amount of time is a system-defined amount of time.

19. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user at a time specified by the user.

20. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user based on one or more user settings.

21. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user based on one or more system-defined rules.

22. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user based on current locations of the first user and the user at that time.

23. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user based on one or more historical locations of the first user and the user.

24. The method of claim 15 wherein programmatically determining that the user is to be de-synchronized from the first user comprises programmatically determining that the user is to be de-synchronized from the first user based on information obtained from one or more third-party sources that is indicative of spatial proximity of the first user and the user.

25. A computer server comprising:

a communication interface adapted to communicatively couple the computer server to a network; and

a controller associated with the communication interface that is adapted to: receive, via the communication interface, a location update for a first user; identify one or more second users that have been location-synchronized to the first user in response to receiving the location update for the first user; and record a location reported in the location update for the first user as a current location of the first user and a current location of each of the one or more second users that have been location-synchronized to the first user.

26. A non-transitory computer-readable medium storing software for instructing a controller of a computing device to:

receive a location update for a first user;

identify one or more second users that have been location-synchronized to the first user in response to receiving the location update for the first user; and

record a location reported in the location update for the first user as a current location of the first user and a current location of each of the one or more second users that have been location-synchronized to the first user.