Patent Description:
Networking architectures have grown increasingly complex in communications environments. In recent years, a series of protocols and configurations have been developed in order to accommodate a diverse group of end users having various networking needs. Many of these architectures have gained significant notoriety because they can offer the benefits of automation, convenience, management, and enhanced consumer selections.

Certain network protocols may be used in order to allow an end user to conduct an on-line search of candidates to fill a given vacancy. These protocols may relate to job searches, person finding services, real estate searches, or on-line dating. While some believe that on-line dating is simply a matter of matching supply and demand, there is statistical and empirical evidence to suggest that successful on-line dating entails far more.

For example, people having similar and/or compatible character traits and values should be matched together. However, effectively linking two participants together can prove to be a challenging endeavor. Coordinating a relationship between two like-minded individuals can be a significant chore, as there are a number of obstacles and barriers that must be overcome.

One problem is that the search results of these services contain many irrelevant entities to the searcher. This costs the user of the service time and may deter them from continuing through all of the search results.

Another problem that has arisen is that matching services have used textual submissions (such as profiles or messages) to determine matches. Users, though, often meet and evaluate others for potential matching using other criteria that matching services have not incorporated.

<CIT> discloses an extension of electronically-defined social networks to include geographic location information of a user. The geographic location information is integrated with user preferences to enable user-to-user contacts and/or the provision of general or specific user information mediated by the social network.

In one embodiment, a method executed by at least one processor includes receiving first historical location information identifying a first location area at which a first user was present at a first time. The method includes receiving second location information identifying a second location area at which a second user was present at a second time. Also, the method includes determining that the first historical location information and the second location information each correspond to a particular location area. In addition, the method includes determining that a characteristic related to the first user corresponds to a preference related to the second user. In response to determining that the first historical location information and the second location information each correspond to the particular location area and in
response to determining that the characteristic related to the first user corresponds to the preference related to the second user, the method includes causing information related to the first user to be presented to the second user. The information related to the first user includes the first location area of the first user relative to the second location area of the second user.

In some embodiments, the location area may be a location type. Causing information related to the first user to be presented to the second user may be performed in response to determining that the difference between the second time and the first time is less than a time threshold. The method may include comparing the first historical location information and the second location information to a database. The database may correlate location information with points-of-interest.

In one embodiment, a system includes an interface. The interface is configured to receive first historical location information identifying a first location area at which a first user was present at a first time and receive second location information identifying a second location area at which a second user was present at a second time. The system includes at least one processor configured to determine that the first historical location information and the second location information each correspond to a particular location area. The at least one processor is also configured to determine that a characteristic related to the first user corresponds to a preference related to the second user. In response to determining that the first historical location information and the second location information each correspond to the particular location area and in response to determining that the characteristic related to the first user corresponds to the preference related to the second user, the at least one processor is configured to cause information related to the first user to be presented to the second user. The information related to the first user includes the first location area of the first user relative to the second location area of the second user.

Depending on the specific features implemented, particular embodiments may exhibit some, none, or all of the following technical advantages. Various embodiments may be capable of allowing a user to submit location information (such as persistent location information) in order to obtain more relevant matches. In some embodiments, a user may be notified of potential matches who visit the same places as the user, thereby providing the user with matching results that may be more relevant. Other technical advantages will be readily apparent to one skilled in the art from the following figures, description and claims.

For a more complete understanding of the present disclosure and its advantages, reference is made to the following descriptions, taken in conjunction with the accompanying drawings, in which:.

Referring to <FIG>, one embodiment of a communication system is shown. <FIG> is a simplified diagram of a system <NUM> for facilitating communication in a network environment. Users <NUM>-<NUM> interact with server <NUM> through terminals 10a-b. Users <NUM>-<NUM> travel to location areas 17a-c as indicated by paths 30a-b and 31a-b. Server <NUM> is coupled to points of interest ("POI") database <NUM>. <FIG> is a diagram showing, in one embodiment, example contents of terminal 10a. Terminal 10a comprises communication module <NUM>, display <NUM>, location module <NUM>, and interface <NUM> (so that user <NUM> may be able to interact with terminal 10a). <FIG> is a diagram showing, in one embodiment, example contents of server <NUM>. Server <NUM> comprises memory <NUM>, at least one CPU <NUM>, and analysis module <NUM>. Terminals 10a-b and server <NUM> are communicatively coupled via network connections <NUM> and network <NUM>. In some embodiments, analysis module <NUM> may be configured to analyze location information, preferences, and characteristics sent from users <NUM>-<NUM> and determine whether user <NUM> should receive information related to user <NUM>.

Users <NUM>-<NUM> are clients, customers, prospective customers, or entities wishing to participate in an on-line dating scenario and/or to view information associated with other participants in the system. Users <NUM>-<NUM> may also seek to access or to initiate communication with other users that may be delivered via network <NUM>. Users <NUM>-<NUM> may review data (such as profiles, for example, with user characteristics and preferences) associated with other users in order to make matching decisions or elections. Data, as used herein, refers to any type of numeric, voice, video, text, or location data, or any other suitable information in any appropriate format that may be communicated from one point to another.

In one embodiment, terminals 10a-b represent (and are inclusive of) a personal computer that may be used to access network <NUM>. Alternatively, terminals 10a-b may be representative of a cellular telephone, an electronic notebook, a tablet computer, a laptop, a personal digital assistant (PDA), or any other suitable device (wireless or otherwise: some of which can perform web browsing), component, or element capable of accessing one or more elements within system <NUM>. Interface <NUM>, which may be provided in conjunction with the items listed above, may further comprise any suitable interface for a human user such as a video camera, a microphone, a keyboard, a mouse, or any other appropriate equipment according to particular configurations and arrangements. In addition, interface <NUM> may be a unique element designed specifically for communications involving system <NUM>. Such an element may be fabricated or produced specifically for matching applications involving a user.

Communication module <NUM> may be implemented using any suitable combination of hardware, firmware, and software. Communication module <NUM>, in some embodiments, may be a modem, network interface card, wireless communication device, cellular data communication device, or other suitable module for communicating information using connections <NUM>. Communication module <NUM> may communicate one or more communication schemes, such as those defined by the IEEE LAN/MAN Standards Committee (IEEE <NUM>), including both wired and wireless standards.

Display <NUM>, in some embodiments, may be a computer monitor, a liquid crystal display (LCD), an active-matrix organic light-emitting diode display (AMOLED), a super AMOLED, a light-emitting diode (LED) based display, or other suitable displays for desktop and/or mobile devices. Alternatively, display <NUM> may be a projector, speaker, or other device that allows users <NUM>-<NUM> to appreciate information that system <NUM> transmits.

Location module <NUM> may be implemented using any suitable combination of hardware, firmware, and software. Location module <NUM> may determine information regarding the physical location of terminal 10a. Examples of such location information include latitude / longitude coordinates, physical address, zip code, area code, city, county, state, country, and geographic area. Location module <NUM> may determine the location information using one or more suitable technologies, such as Global Positioning System (GPS), available IEEE <NUM> networks, and cellular radio signals. For example, location module <NUM> may use triangulation of wireless signals such as <NUM> networks and/or cellular radio signals. As another example, Uplink Time Difference of Arrival (U-TDOA) may be used by location module <NUM> to determine location information. In some embodiments, location module <NUM> may determine location information using input from a user (such as users <NUM>-<NUM>). For example, location module <NUM> may use user input as one factor in determining location and rely on other technologies to make a determination as to the location of terminal 10a. As another example, location module <NUM> may allow user <NUM> to specify location information (i.e., an intersection, an address, or a business). A user may specify location information by selecting location information from a list or map provided by location module <NUM>.

In some embodiments, location module <NUM> and/or service <NUM> may receive input of location information from users <NUM>-<NUM>. In some embodiments, users may manually submit their historical location information, current location information, or future location information from a device, such as terminal 10a or terminal 10b. Users <NUM>-<NUM> may specify particular locations, location areas, and/or location types to include in his or her location information. For example, users <NUM>-<NUM> may specify cities they have lived in previously, location types that they frequent on a regular basis (e.g., coffee shop, gym), events they have been to and/or plan to attend in the future (e.g., local sports teams' events, festivals, concerts, art shows, etc.), and/or any other location information to be included in location module. In some embodiments, users <NUM>-<NUM> may indicate what future events they plan to attend or are interested in attending. For example, if user <NUM> plans to attend a music festival in California in a few weeks, he or she may submit that information. In this example, user <NUM> may be matched with other users (e.g., user <NUM>) who are planning to attend the same festival, have attended the festival in the past, have attended similar festivals or events before, or are planning to attend similar festivals or events. User <NUM> may be notified of user <NUM>'s interests, for example, by seeing an indication on the profile of user <NUM> about these past and future events. By allowing location module <NUM> and/or server <NUM> to receive this information from users <NUM>-<NUM> in addition to determining a physical location of users <NUM>-<NUM>, a more complete profile of users <NUM>-<NUM> may be prepared.

Network <NUM> comprises one or more communicative platforms operable to exchange data or information emanating from users <NUM>-<NUM>. Network <NUM> could include a plain old telephone system (POTS). Transmission of information emanating from the user may be assisted by management associated with server <NUM> or manually keyed into a telephone or other suitable electronic equipment. In some embodiments, network <NUM> could include any packet data network offering a communications interface or exchange between any two nodes in system <NUM>. Network <NUM> may alternatively be any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), wireless local area network (WLAN), virtual private network (VPN), intranet, or any other appropriate architecture or system that facilitates communications in a network or telephonic environment, including a combination of any networks or systems described above. In various embodiments, network connections <NUM> may include wired and/or wireless mediums which may be provisioned with routers and firewalls.

In some embodiments, POI database <NUM> may be implemented using any suitable combination of hardware, firmware, and software. POI database <NUM> may include data indicating what is available at certain geographic locations. For example, POI database <NUM> may include data regarding restaurants, retailers, gas stations, historical sites, counties, cities, metropolitan areas, zip codes, or other locations that may be of interest to users such as users <NUM> and <NUM>. Examples of POI database <NUM> include the CITYSEARCH database and the POYNT database.

Server <NUM> is operable to receive and to communicate information to terminal <NUM>. In some embodiments, server <NUM> may comprise a plurality of servers or other equipment, each performing different or the same functions in order to receive and communicate information to terminal <NUM>. Server <NUM> may include software and/or algorithms to achieve the operations for processing, communicating, delivering, gathering, uploading, maintaining, and/or generally managing data, as described herein. Alternatively, such operations and techniques may be achieved by any suitable hardware, component, device, application specific integrated circuit (ASIC), additional software, field programmable gate array (FPGA), server, processor, algorithm, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or any other suitable object that is operable to facilitate such operations. In some embodiments, server <NUM> may comprise one or more clusters of virtual or hardware-based computing nodes, a distributed computing infrastructure, or other suitable forms of providing a software service using multiple computers. In some embodiments, server <NUM> may offer one or more services to users <NUM> and <NUM> via network <NUM> such as social networking, professional networking, conference services, messaging, gaming, online dating, marketplace, discussion board, news, travel services, retail services, or other suitable services. Server <NUM> can be used to identify and to evaluate suitable candidates in various areas (e.g. hiring/employment, recruiting, real estate, general person searches, online dating, etc.).

In some embodiments, memory <NUM> may include multiple storage structures, such as storage structures <NUM> and <NUM>, one or file systems, as well as other suitable structures for storing and retrieving data. For example, storage structures <NUM> and <NUM> may be implemented using one or more databases, file systems, tables, stacks, heaps, or other suitable storage structures.

In some embodiments, location areas 17a-c may be a geographic area that users <NUM>-<NUM> visit. Examples of location areas include: latitude/longitude coordinates, a physical address, an intersection of streets, a city, a state, a zip code, a region, a province, a region defined by an area code, a business, a neighborhood, a shopping center, a borough, or other suitable geographic areas. In some embodiments, location areas 17a-c may be a location type, such as a business, a historical site, a library, or a restaurant. As another example, location areas 17a-c may be an event at a location area, such as a concert, speech, or a sports event.

In some embodiments, users <NUM>-<NUM>, using terminals <NUM>, register with server <NUM>. Registration may include users <NUM>-<NUM> submitting information to server <NUM> about users <NUM>-<NUM> as well as characteristics with which users <NUM>-<NUM> are seeking to be matched. In various embodiments, server <NUM> may be configured to collect this information; for example, such information may include gender, preferred gender of a potential match, height, weight, age, location, ethnicity, birthplace, eating habits, activities, and goals. Server <NUM> may further receive information regarding what users <NUM>-<NUM> may be looking for in a match, such as gender, age, weight, height, location, ethnicity, diet, and education.

Further, server <NUM> may receive information from users <NUM>-<NUM> indicating how important certain factors are when looking for a match. For example, server <NUM> may allow the user to indicate which characteristics in a potential match are a necessity. In another example, server <NUM> may ask, "How important is it that your match does not smoke?" Server <NUM> may also allow the user to indicate that certain characteristics are not important search criteria. For example, when asking user <NUM> about what height or weight user <NUM> is seeking in a match, server <NUM> may be configured to receive "not important" as a response. In yet another example, server <NUM> may allow user <NUM> to rate which factors are important on a numerical scale. For example, server <NUM> may ask user <NUM> the following: "On a scale of <NUM> - <NUM>, how important is it that your match has the same education level as you?" In some embodiments, server <NUM> may specify that any number of questions or requested descriptions are necessary before registration may be concluded. As an example only, server <NUM> may require that user <NUM> communicate the sex of user <NUM> and the sex user <NUM> prefers to be matched with. Server <NUM> may be configured to receive the information submitted by users <NUM>-<NUM> and create profiles for users <NUM>-<NUM> based on that information, storing the profiles in memory <NUM>, such as in storage structure <NUM>.

In some embodiments, server <NUM> may receive information from users <NUM>-<NUM> after registration. Server <NUM> may receive location information from users <NUM>-<NUM> after registration has been completed. For example, terminal 10a may be configured to send location information regarding user <NUM> to server <NUM> passively or actively. For example, user <NUM> may travel to location area 17a as indicated by path 30a. At location area 17a, terminal 10a may transmit location information to server <NUM> (such as latitude and longitude coordinates). This may be done in response to user <NUM> requesting that terminal 10a transmit the location information, or terminal 10a may automatically send the location information. As another example, an application in terminal 10a may be configured to send location information regarding user <NUM> to server <NUM> periodically or continuously. The application may be configured to operate as a background process on terminal 10a. The location information may be transmitted using connections <NUM> and network <NUM>. Server <NUM> may receive location information and store it in storage structure <NUM>. Server <NUM> may also store the time when the location information was received from user <NUM> in storage structure <NUM>.

In some embodiments, analysis module <NUM> may be implemented using any suitable combination of hardware, firmware, and software. Analysis module <NUM> may be configured to search through information such as profiles stored in storage structure <NUM> regarding users (such as users <NUM>-<NUM>) and present matches to user <NUM>. Techniques for determining relevant matches for users are well known in the art. Some include determining how closely one user's preferences match another user's characteristics and vice versa. In some embodiments, server <NUM> may be configured to generate a pool of potential matching users for user <NUM> according to various characteristics and preferences of user <NUM> and other users of the system. Server <NUM> may assign scores to the pool of potential matching users for user <NUM> based on preferences and/or activity of user <NUM>. Server <NUM> may also restrict entities from being included in the pool of potential matching users based on the status of the profile, location information regarding the entity, or location information regarding user <NUM>. User <NUM> may specify a preference to be matched with or not to be matched with users that visit certain locations or location types, such as stores, libraries, or restaurants. User <NUM> may specify a preference to be matched with or not to be matched with users that visit the same locations or location types as user <NUM>. Analysis module <NUM> may use the location information in storage structure <NUM> received from users <NUM> and <NUM> when applying preferences regarding location information of user <NUM> when determining matching users for user <NUM>.

In some embodiments, analysis module <NUM> may be configured to present information regarding other users registered with server <NUM> (such as user <NUM>) to user <NUM> based on the present or past location(s) of user <NUM>. For example, users <NUM> and <NUM> may travel to location areas 17a-c as indicated by paths 30a-b and 31a-b. User <NUM> arrives at location area 17b and terminal 10b transmits location information regarding user <NUM> and location area 17b to server <NUM>. At a later time, after user <NUM> has left location area 17b, user <NUM> arrives at location area 17b. Terminal 10a sends location information regarding user <NUM> and location area 17b to server <NUM>. Then, server <NUM> sends a notification to terminal 10a indicating that user <NUM> was at location area 17b. Server <NUM> may send the notification after determining that user <NUM> has one or more characteristics that are preferable to user <NUM>. The notification may be sent after user <NUM> has departed location area 17b. Server <NUM> may provide an indication of the time difference between when user <NUM> arrived at location area 17b and when user <NUM> was at location area 17b. Server <NUM> may send information regarding user <NUM> to user <NUM>. User <NUM> may also receive (using terminal 10a) information regarding other users who are registered with server <NUM> that have also been at location area 17b previous to user <NUM>. For example, server <NUM> may send a list of users who have been at location area 17b and indicate when each of those users were at location area 17b relative to when user <NUM> was at location area 17b.

In some embodiments, notifications to user <NUM> may provide information regarding when and where other users (such as user <NUM>) have been as they relate to when and where user <NUM> has been. The notifications may include information regarding a location area 17a-c at which user <NUM> may have been present relative to a location area 17a-c at which user <NUM> may be or have been present. For example, a notification may notify user <NUM> that user <NUM> missed being in the same location area as user <NUM> by a certain amount of time and may present information regarding user <NUM> to user <NUM>. For example, the notification may notify user <NUM> that user <NUM> missed being at the same restaurant as user <NUM> by <NUM> minutes and may provide information regarding user <NUM> such as a picture, profile information, or user identifier. The information provided may indicate that user <NUM> may be a good match for user <NUM>. A notification may notify user <NUM> that user <NUM> has similar patterns of behavior as user <NUM>, such as visiting the same type of location at the same or different times. For example, the notification may notify user <NUM> that user <NUM> and user <NUM> visit the same location area everyday (such as a coffee shop), visit the same park in the mornings, go to a gym three times a week, or attended the same event the previous night. A notification may notify user <NUM> that user <NUM> goes to the same type of locations as user <NUM>. For example, a notification may notify user <NUM> that user <NUM> and user <NUM> go to coffee shops in the morning or go to gyms in the evening. A notification may notify user <NUM> that user <NUM> travels the same or similar routes and/or paths as user <NUM> (i.e., user <NUM> and user <NUM> visit the same locations in the same order). As examples, a notification may notify user <NUM> that user <NUM> and user <NUM> take the same bus to work, use the same roads to get to work, attend the same restaurant and then the same movie theatre, or go to the same gym and then the same smoothie store. A notification may notify user <NUM> that user <NUM> are in nearby location areas at the same or different times. As examples, a notification may notify user <NUM> that user <NUM> and user <NUM> work on the same block during the week or that user <NUM> and user <NUM> go to restaurants in adjacent boroughs on different days. A notification may notify user <NUM> that user <NUM> will be at the same location as user <NUM>. For example, both user <NUM> and user <NUM> may be interested in and/or registered for the same event (e.g., concert in the park tomorrow, baseball game next week, music festival in a few months), planning to visit the same location (e.g., Spain next year, Mexico in a few weeks, New York in spring time), or interested in visiting the same locations (e.g., dream vacation, next travels, future trips).

In some embodiments, this may provide an advantage in that user <NUM> may be provided with other users who visit or plan to visit the same location as user <NUM> which may interest user <NUM> in being matched with such users. Another example of how this may be advantageous is that server <NUM> may provide potential matches to user <NUM> in a manner that may be more relevant to user <NUM> given that such matches have visited or will visit the same location area 17b as user <NUM>.

In some embodiments, analysis module <NUM> may be configured to receive a request from user <NUM> to be matched with users in the same location or location type as the present location of user <NUM>. For example, user <NUM> may travel to location area 17a as indicated by path 30a. User <NUM> causes terminal 10a to send an indication to server <NUM> that user <NUM> would like to be matched with other users that have been in, will be in, or plan to be in location area 17a or in a type of location that is similar to location area 17a. Terminal 10a sends the preference(s) of user <NUM> along with location information regarding location area 17a to server <NUM>. Server <NUM> uses location information stored in storage structure <NUM> of other users (such as user <NUM>) registered with server <NUM> to determine users to match with user <NUM>. Server <NUM> may use information from POI database <NUM> to determine location types that may be similar to location area 17a. Server <NUM> may also use other characteristics of users registered with server <NUM>, such as those stored in storage structure <NUM> (including profile information), to determine users that may be of interest to user <NUM>. Analysis module <NUM> performs comparisons to determine which users should be presented to user <NUM>. The comparisons may take into account the preference expressed by user <NUM> regarding location area 17a. For example, user <NUM> may submit a preference to view profiles of other users who have been, are in, or will be in location area 17a. In some embodiments, the preference submitted by user <NUM> may cause certain profiles to be prioritized in the user's queue of potential matches (e.g., list of users, stack of cards of profiles). For example, if user <NUM> submits a preference for users interested in Europe, analysis module <NUM> may put users higher in the queue who have been to Europe, are in Europe, are planning to visit Europe, or and/or are interested in Europe. The comparisons may be performed by scoring various characteristics of the users in light of stated preferences and activity of user <NUM>. In some embodiments, this may be advantageous in that user <NUM> may be able to express location as a preference to enhance the search for matches performed by server <NUM> which may provide more relevant potential matches.

In some embodiments, analysis module <NUM> may determine the number of users associated with the places related to the preference submitted by user <NUM>. Analysis module <NUM> may analyze the location information (past, present, and future) of a plurality of users and associate those users with particular locations (e.g., city, country, bar, restaurant, event, festival, concert, sport, etc.). Analysis module <NUM> may determine which locations have a significant number of users associated with it by comparing the number of users to a threshold. Analysis module <NUM> may determine which locations are most popular among similar users. When user <NUM> indicates a preference for a location, analysis module <NUM> may present information to user <NUM> related to the popular locations. For example, analysis module <NUM> may indicate to user <NUM> that a certain bar is a place where a significant number of users registered with server <NUM> have been, currently are, or plan to be. As another example, analysis module <NUM> may indicate to user <NUM> that a large number of users are planning to attend a certain music festival in the spring. This may be beneficial for user <NUM> to identify locations to be around other people who are looking to make connections and visit or plan to visit those locations.

In some embodiments, analysis module <NUM> may be configured to provide an indication to user <NUM> of other users registered with server <NUM> (such as user <NUM>) that may be in the same location or location type as user <NUM>. For example, user <NUM> may arrive at location area 17b as indicated by paths 31a and 31b. Sometime later, user <NUM> arrives at location area 17b as indicated by paths 30a and 30b. After arriving at location area 17b, terminal 10b transmits location information regarding user <NUM> and location area 17b to server <NUM>. After arriving at location area 17b, terminal 10a transmits information regarding user <NUM> and location area 17b to server <NUM>. User <NUM> may send a request to server <NUM> to receive information regarding other users registered with server <NUM> that may be at location area 17b. Analysis module <NUM> analyzes location information in storage structure <NUM> and information regarding characteristics of users registered with server <NUM> in storage structure <NUM> to determine other users of server <NUM> that may be at location area 17b. Analysis module <NUM> may cause an indication to be sent to user <NUM> that provides information regarding one or more users (such as user <NUM>) that may also be at location 17b at the same time as user <NUM> who have one or more characteristics that match preferences previously submitted by user <NUM>. The indication may be sent after user <NUM> has departed from location 17b or while user <NUM> is still at location 17b. Analysis module <NUM> may be configured to receive and process location information from user <NUM> and provide the indication to user <NUM> in real time. In some embodiments, presenting an indication to user <NUM> informing user <NUM> of one or more users that are at or have been at the same or similar location areas as user <NUM> may be advantageous in that user <NUM> may be provided information regarding other users that may be of interest to user <NUM> that are in the same location as user <NUM>. This may provide user <NUM> an opportunity to meet people in whom user <NUM> may have an interest.

In some embodiments, analysis module <NUM> may be configured to determine whether user <NUM> and user <NUM> have met in person. Analysis module <NUM> may determine that user <NUM> and <NUM> have connected through devices 10a-b (e.g., talked through server <NUM> or a related application, have been presented to each other as potential matches, have been matched together). Analysis module <NUM> may determine that user <NUM> and user <NUM> were in the same location area at the same time. In some embodiments, analysis module <NUM> may determine the proximity of users <NUM> and <NUM> within the same location area. Analysis module <NUM> may compare the proximity to a threshold to determine that users <NUM> and <NUM> interacted at location area. In response to determining that users <NUM> and <NUM> met and/or interacted, analysis module <NUM> may cause an indication or notification to be presented to users <NUM> and <NUM> requesting feedback. For example, analysis module <NUM> may request feedback about how the meeting went, whether the two users went on a date, how the date was, or any feedback about the other user and the interaction. Feedback may be provided by selecting an answer, a rating, a score, a scale, providing written feedback, or any other method of providing feedback. Analysis module <NUM> may utilize this feedback to present different users to user <NUM> and <NUM>, present users <NUM> and <NUM> to different users, or alter its suggestion module to present indications generally. In some embodiments, analysis module <NUM> may request feedback on the location where users <NUM> and <NUM> met. For example, analysis module <NUM> may ask users <NUM> and <NUM> to rate the location, whether it is a good date spot, provide an indication of the ambience, indicate how many other people were there, or provide any information to analysis module <NUM>. Analysis module <NUM> may utilize that feedback to rate locations and provide those ratings to its users. For example, if user <NUM> is looking for a good spot to meet user <NUM>, it may review feedback or an aggregation of the feedback from other users about certain locations.

In some embodiments, analysis module <NUM> may provide suggestions to user <NUM> about potential location areas for an activity depending on the location information of user <NUM>, including the location areas and location types that user <NUM> and/or user <NUM> has been, is currently, or will be. For example, if user <NUM> wants to go on a date with user <NUM>, analysis module <NUM> may determine that both user <NUM> and <NUM> frequent music venues, and suggest a new music venue for them to meet. As another example, analysis module <NUM> may determine that user <NUM> and <NUM> both visit a certain area of town on the weekends, and suggest a restaurant in that area of town. As another example, analysis module <NUM> may determine that user <NUM> and <NUM> are both planning to attend a sporting event next week and may indicate to one or both users to meet up at that sporting event.

<FIG> are flowcharts illustrating embodiments of the operation of system <NUM> of <FIG>. In general, the steps illustrated in <FIG> may be combined, modified, or deleted where appropriate, and additional steps may also be added to the example operation. Furthermore, the described steps may be performed in any suitable order. In some embodiments, the steps described below may be performed by any suitable combination of the elements discussed above with respect to <FIG> or other suitable elements.

<FIG> is a flowchart illustrating one embodiment of how analysis module <NUM> of <FIG> may provide an indication to user <NUM> of <FIG> of users registered with server <NUM> of <FIG> (such as user <NUM>) that were at a location area or location type where user <NUM> also was at some time. One or more of the steps illustrated in <FIG> may be repeated by analysis module <NUM> for one or more users that have registered with server <NUM>.

At step <NUM>, in some embodiments, server <NUM> may receive and store location information from various users who have registered with server <NUM> (such as user <NUM>). For example, historical location information may be received at this step indicating location areas where users registered with server <NUM> have been. Present location information about the current location, location area, and/or location type may also be received. Future location information about locations, location areas, and/or location types where a user (e.g., user <NUM>) will be may also be received. In some embodiments, location information may be stored with a corresponding time of when the user was there and/or when the user will be at the location. Terminals such as terminals 10a-b may send the location information using modules such as location module <NUM>. The location information may include information regarding one or more of: longitude/latitude coordinates, a physical address, an intersection, a neighborhood, a county, a city, a state, a zip code, an area code, a region, a country, or other suitable information that describes geographic location. In some embodiments, a tolerance parameter(s) may be included with the location information indicating how precise the location information is. For example, the location information may include an intersection of two streets, and the tolerance parameter may indicate that the information is accurate within ten blocks. Server <NUM> may cause the location information received at this step to be stored in a stored structure such as storage structure <NUM>. Along with the location information, server <NUM> may store other information, such as: information regarding one or more of the users registered with server <NUM> associated with the location information, characteristics of the users submitting the location information, the times that the users arrived at and/or departed from the location associated with the location information, user preferences as to how the location information should be used, or other data associated with the location information. In some embodiments, server <NUM> may be configured to store the location type associated with the location information received at this step. As an example, server <NUM> may receive information about the location type from POI database <NUM> and store that information with the location information received at this step. Example location types include point-of-interest (POI), restaurant, business, historical site, shopping, names of businesses, museums, or other suitable descriptions of the geographic area identified by the location information. Information received and stored at step <NUM> may include event information related to the location information such as a concert, speech, or a sports event.

At step <NUM>, in some embodiments, location information (such as persistent location information) from user <NUM> may be received by server <NUM>. For example, historical location information may be received at this step indicating location areas or events at location areas where user <NUM> has been. User <NUM> may have arrived at location area 17a and terminal 10a may have transmitted the location information received at this step using information from location module <NUM>. This transmission may have been performed passively or actively. For example, terminal 10a may have been configured to transmit location information as user <NUM> travels to various location areas. As another example, terminal 10a may have been configured to transmit location information when a particular application is launched on terminal 10a. As another example, terminal 10a may be configured to transmit location information in response to an indication from user <NUM> (i.e., user <NUM> presses a button or taps an active portion of a screen of terminal 10a to indicate that the location information should be sent).

At step <NUM>, in some embodiments, the location information received at step <NUM> is compared to the location information stored at step <NUM> by analysis module <NUM>. As an example, this may be done to determine whether other users have been in the same location area that user <NUM> is in or have attended the same event that user <NUM> is at as indicated by the location information received at step <NUM>. As another example, this may be done to determine whether other users have been in, are in, or will be in the same location area that user <NUM> has been as indicated by the location information received at step <NUM>. Various methods may be used to compare the location information at this step. Method used may, in various embodiments, be dependent on the type of location information received and/or stored at steps <NUM> and <NUM>. For example, latitude and longitude coordinates may be compared to one another, and a threshold may be used to determine whether they are considered to be within the same location area. As another example, location information such as addresses, zip codes, or area codes may be compared to one another to determine where there is a match. As another example, location information such as latitude and longitude coordinates may be compared to an address by determining what location the latitude and longitude coordinates are indicate of and calculating a distance from that location to the address. The distance may then be compared to a threshold as discussed further below. As another example, latitude and longitude coordinates may be compared to a zip code by determining whether the location indicated by the coordinates falls within geographic area associated with the zip code. As another example, at this step the location type of the location information received at step <NUM> and the location information stored at step <NUM> may be compared.

At step <NUM>, in some embodiments, analysis module <NUM> may determine whether differences between the location information received at step <NUM> and the location information received at step <NUM> is below a threshold. For example, a distance threshold may be used at this step. This may determine whether the location information being compared are geographically close enough to indicate a same location area. Multiple distance thresholds may be used depending on the type of location information being compared. For example, when comparing two addresses, the threshold might be set such that to be below the threshold the addresses must be the same. As another example when comparing addresses, the threshold might be set to allow for the addresses to differ by a specified amount (i.e., <NUM> blocks). As another example, if the location information being compared are two sets of latitude/longitude coordinates, then the threshold might be a distance between the two pairs of coordinates (e.g., two miles). As another example, when comparing an address to a zip code, the threshold may be that the address be located within the area associated with the zip code or may be that the address be located in the area associated with the zip or in an area adjacent to the area associated with the zip. As another example, when comparing location types, the threshold may be set such that a match is determined if the location types are the same. As another example, when comparing location types, the threshold may be set such that a match is determined if the location types are similar (i.e., a location type of a restaurant serving American cuisine may be considered a match to a location type of a restaurant serving Asian cuisine). The thresholds may be different based upon the location areas indicated by the location information. For example, thresholds may vary based on the city or region identified, such as using one threshold for a large city and another threshold for a small city. If the difference between the location information being compared is below the threshold, then users associated with the location information received at step <NUM> may be further considered at step <NUM>. If it is determined that the location information being compared is at or above the threshold, then the users associated with the location information received at step <NUM> may not be considered further. In some embodiments, if the difference between the location information is at or above the threshold, then user <NUM> may not be in the same location area that the user had been whose location information is being compared.

In some embodiments, steps <NUM> and <NUM> may be performed multiple times as analysis module <NUM> analyzes the location information stored at step <NUM> from various users who have subscribed to server <NUM>. Analysis module <NUM> may perform these steps with groups of users or may perform these steps with all the users whose location information is stored in storage structure <NUM>. In some embodiments, steps <NUM> and <NUM> may be performed such that analysis module <NUM> determines whether user <NUM> visits the same or similar multiple location areas as users registered with server <NUM>. For example, analysis module <NUM> may determine that user <NUM> and user <NUM> visit the same or similar multiple location areas or have attended the same event with a location area.

At step <NUM>, in some embodiments, analysis module <NUM> may compare time information included with the location information received at step <NUM> with time information associated with the location information received at step <NUM> that was determined to be in the same location area at steps <NUM> and <NUM>. The time information compared at this step may include milliseconds, seconds, minutes, hours, days, weeks, months, years and/or other suitable measurements of time. This step may be performed so that analysis module <NUM> may determine how long it has been since the users who were determined to be in the same location area as user <NUM> at steps <NUM> and <NUM> arrived at or departed from the location area and user <NUM> arrived at the location area. The time information compared at this step may be the time that user <NUM> arrived at the location area indicated by the location information received at step <NUM>, the time that the other users arrived at that location area, the time that the other users left that location area, and/or the time that the other users arrived at a different location area. In some embodiments, the time that a user left a location area may be determined based on the time that the user arrives at the location area, the time that the user arrives at a different location area, or the period of time the user remained in the same location area.

At step <NUM>, in some embodiments, the difference in the time information compared at step <NUM> may be compared to a time threshold. If the difference is greater than the threshold, then step <NUM> may be performed. If the difference is less than the threshold, then the associated users may no longer be considered. The difference being greater than a threshold may indicate that user <NUM> had arrived at a location area after another user left the location area. The difference being below the threshold may indicate that user <NUM> is at the location area with another user at the same time. Example time thresholds include <NUM> minutes, <NUM> minutes, and <NUM> hour.

In some embodiments, step <NUM> may be performed by determining whether any difference in the time information compared at step <NUM> is less than a time threshold. In such embodiments, if the difference is less than the threshold, then step <NUM> may be performed. If the difference is greater than the threshold, then the associated users may no longer be considered. Example time thresholds include <NUM> seconds, <NUM> minutes, <NUM> minutes, and <NUM> minutes. This may be applied in situations when analysis module <NUM> is configured to determine if user <NUM> has been to the same location area or location type as other users registered with server <NUM> at or near the same time. The time threshold discussed above may be configurable. For example, the time threshold may depend on the location information received at step <NUM>. As another example, the time threshold may depend on the population density associated with the location information received at step <NUM>.

In some embodiments, steps <NUM> and <NUM> may not be performed. For example, analysis module <NUM> may be configured to present user <NUM> with a notification of users registered with server <NUM> who have been in the same location area at the same time as or at a different time than user <NUM>.

At step <NUM>, in some embodiments, characteristics of certain users whose location information was stored at <NUM> may be compared to preferences and/or characteristics of user <NUM>. The users whose characteristics are compared at this step may be users who have been in the same location area as user <NUM> and who have left the location area at a time sufficiently later than when user <NUM> arrived as discussed above with respect to steps <NUM> through <NUM>. Examples of characteristics and/or preferences compared at step <NUM> may include interests, height, age, weight, sex, income, eye color, hair color, profession, residence or other suitable characteristics for matching. This step may be performed using information in storage structure <NUM>, such as profile information of users registered with server <NUM>.

At step <NUM>, in some embodiments, it may be determined whether a sufficient number of preferences of user <NUM> match characteristics of the users compared at step <NUM>. The number of matching characteristics may be set depending on desired levels of tolerance. For example, if user <NUM> has few potential matching candidates according to his or her preferences, then only one preference being satisfied may be sufficient. As another example, if there are many potential candidates that match with user <NUM>, then more than one preference may be required to be met at this step. The determination at step <NUM> may be dynamic by responding to changes in the profile or preferences of user <NUM>. For example, if user <NUM> changes the associated profile, the number of potential matching candidates may change. The change in the number of potential matching candidates may also change the determination of whether a sufficient number of preferences of user <NUM> have been matched that occurs at step <NUM>. Step <NUM> may be performed with respect to users that have characteristics which satisfy a sufficient number of preferences of user <NUM>. Users that do not have characteristics which satisfy a sufficient number of preferences of user <NUM> may no longer be considered in this process. In some embodiments, this may result in selecting only users that user <NUM> be interested in meeting. In some embodiments, one or more scores may be used in step <NUM>. For example, a score may be given to one characteristic because it was close to matching a preference of user <NUM> while another characteristic may receive a lower score because it was not as close to matching a preference of user <NUM>. These scores (separately or combined) may be compared to one or more thresholds to determine if the preferences have been matched. The scores may also be analyzed based on importance levels that user <NUM> has indicated regarding his or her preferences.

At step <NUM>, in some embodiments, analysis module <NUM> may cause an indication to be presented to user <NUM> that includes information related to users of server <NUM> that were at a location area or location type where user <NUM> also was at some time. The information in the indication may include information regarding a location area at which a user registered with server <NUM> may have been present relative to a location area at which user <NUM> may be or have been present. The indication may not reveal the exact location area that user <NUM> has in common with the other users. For example, instead of indicating exactly which coffee shop or gym another user attends, the indication may disclose to user <NUM> the area, neighborhood, shopping center, street block, or other geographical description that user <NUM> has in common with user <NUM>. As another example, the information in the indication may include information regarding the location type that user <NUM> has in common with other users registered with server <NUM> (e.g., user <NUM> and other users visit coffee shops, libraries, or bowling alleys). In some embodiments, the indication may include information indicating that: user <NUM> was at or near the same location area as user <NUM> at different times, user <NUM> was at or near the same location area as user <NUM> at the same or nearly the same time, user <NUM> was at the same location type as user <NUM> at the same or nearly the same time, or user <NUM> was at or near the same location type as user <NUM> at different times.

The information that may be included in this indication may include user identifiers used in communicating with server <NUM>, real names, photographs, interests, personal information, contact information, and/or other characteristics of users registered with server <NUM>. The list of users presented to user <NUM> at this step may be sorted by one or more factors including residence of the users, the difference in time between when those users left the location area and when user <NUM> arrived at the location area, how many preferences of user <NUM> are met, future locations that the users have in common, or other suitable characteristics or factors. The information may also include the difference in time between when user <NUM> arrived or will arrive at the location area and when the users whose information is presented at this step arrived, will arrive, or left the location area. The information may also include the distance between the location information of user <NUM> received at step <NUM> and the location information of users whose information is presented at this step. The information presented at this step may indicate that user <NUM> and user <NUM> have a path or route in common (i.e., users <NUM> and <NUM> visit the same location areas in the same order).

The information presented at this step may be sent from server <NUM> to terminal 10a. Terminal 10a may provide user <NUM> with a notification that the indication is available to be presented. As an example, this information may be useful to user <NUM> in that user <NUM> may be able to determine which user <NUM> missed the opportunity to meet and may be motivated to attempt to contact such users using one or more services offered by server <NUM>. User <NUM> may perceive that he or she missed a connection with a potential match because of the indication that analysis module <NUM> caused to be presented at step <NUM>. As another example of an advantage, user <NUM> may be able to determine characteristics of people who have visited the location area before and may determine to return because those characteristics are of interest to user <NUM>. User <NUM> may be provided with information or options to contact people-of-interest. For example, user <NUM> may contact people-of-interest using a service offered by server <NUM>, by e-mail, or by telephone. As another example of an advantage, user <NUM> may indicate that user <NUM> should not be matched with other users from the location areas user has visited after user <NUM> has been presented with the information at step <NUM>.

In some embodiments, the steps of <FIG> may be performed in a different order than illustrated. For example, steps <NUM> and <NUM> may be performed before steps <NUM> and <NUM>. As another example, steps <NUM> and <NUM> may be performed before steps <NUM> and <NUM>.

<FIG> is a flowchart illustrating one embodiment of how analysis module <NUM> of <FIG> may provide an indication to user <NUM> of <FIG> of the number of users registered with server <NUM> of <FIG> (such as user <NUM>) that have been at places in the same location area as user <NUM>.

At step <NUM>, in some embodiments, location information may be received by server <NUM> from users that have registered with one or more services offered by server <NUM> (such as user <NUM>). This step may be performed similarly to step <NUM> of <FIG>. Users registered with server <NUM> may have devices with them such as terminals 10a and 10b that transmit location information to server <NUM> actively or passively. The location information may be stored in a structure such as storage structure <NUM>. Various types of location information may be received, such as a physical address or latitude/longitude coordinates.

At step <NUM>, in some embodiments, places associated with location information received at step <NUM> may be determined. This step may be performed by analysis module <NUM>. The location information received by step <NUM> may compared to one or more databases or services to determine what places are at or near the location information received at step <NUM>. Examples of places determined at this step may include a type of place, a restaurant, a business, a shopping center, a neighborhood, a historical site, a service, or other points of interest. As another example, events occurring at a place at a time may be determined. Places may be determined using a database or service such as POI database <NUM> of <FIG>. In some embodiments, multiple places may be determined for a given item of location information associated with one of the users registered with server <NUM>. For example, an address may have been received at step <NUM>, and, at step <NUM>, a business associated with that address may be determined. As another example, a zip code may be received at step <NUM> and multiple businesses or neighborhoods may be determined at step <NUM>. As another example, an address may have been received at step <NUM>, and, at step <NUM>, multiple businesses at or near that address may be determined.

At step <NUM>, in some embodiments, the number of users associated with the places determined in step <NUM> may be determined. Analysis module <NUM> may perform this step. At this step, the places determined at step <NUM> from the information received at step <NUM> are then correlated to the users who sent the location information received at step <NUM>. The number of users registered with server <NUM> that have been to or will be going to the places determined at step <NUM> may be determined at this step. For example, it may be determined that ten users submit the location information that was associated with a restaurant determined at step <NUM>. As another example, it may be determined that one thousand users plan to or will attend a concert next week.

At step <NUM>, in some embodiments, server <NUM> may receive location information from user <NUM>. This step may be performed similarly to step <NUM> of <FIG>. User <NUM> may have caused this information to be sent via terminal 10a. This information may be sent via terminal 10a passively or actively.

At step <NUM>, in some embodiments, one or more places may be determined from the location information received from user <NUM> at step <NUM>. For example, if location information received at step <NUM> was a physical address, then one place may be determined such as a business, residence, or other entity occupying the physical address. As another example, if a zip code was received at step <NUM>, then the places within the zip code (such as businesses, residences, neighborhoods and other entities within the zip code's region) may be determined. In some embodiments, information that refers to a specific geographic location (such as an address or latitude/longitude coordinates) multiple places may be determined. For example, if an address was received at step <NUM>, then places in or around that address may be determined within a given radius (such as one mile, two blocks, <NUM> yards, and/or other suitable measurements). This step may be performed similarly to step <NUM>. For example, POI database <NUM> of <FIG> may be used to compare the location information to the database to determine places such as points of interest that are in the database.

At step <NUM>, in some embodiments, analysis module <NUM> may compare the places determined at step <NUM> to the places stored at step <NUM>. This may be done to determine whether there is a match between the places determined at step <NUM> to the places stored at step <NUM>. In some embodiments, this may be done to determine whether these place(s) are within the same geographic region (such as a block, neighborhood, zip code, shopping center, mall, or other suitable geographic region).

At step <NUM>, in some embodiments, the number of users registered with server <NUM> and associated with the places determined at determined at step <NUM> are presented to user <NUM>. This may be performed by identifying the number of users determined at step <NUM> corresponding to the matching places determined at step <NUM>. For example, if a restaurant was determined to have <NUM> associated users registered with server <NUM> at step <NUM>, and that restaurant was determined at step <NUM>, <NUM> users would be determined at this step. After determining the number of users associated with the places determined at step <NUM>, analysis module <NUM> may cause server <NUM> to send an indication of the places determined at step <NUM> and the number of registered users that have visited the places determined at step <NUM>. In some embodiments this may be advantageous because user <NUM> may be presented with information regarding the number of users that frequent the places near which user <NUM> is located. For example, server <NUM> may offer a dating service or matchmaking service where user <NUM> and other registered users of server <NUM> are attempting to be matched or date each other. Being able to determine the number of registered users that have been to the places surrounding user <NUM> may be beneficial in that user <NUM> may be able meet the registered users in person in that location. In some embodiments, user <NUM> may be presented with information about the places, such as whether they are good locations for a date, the ambience of the location, or any other helpful information for user <NUM>. This information may be generated through feedback from other users, third party sources, or the locations themselves. As another example, user <NUM> may be a student and server <NUM> may be offering a service for students. Presenting user <NUM> with the number of other registered users of server <NUM> that have visited places surrounding user <NUM> may help user <NUM> to make a decision as to what place user <NUM> would prefer visiting. For example, if user <NUM> was attempting to choose a restaurant to eat at knowing that other students frequent that restaurant may help user <NUM> to make the decision. Terminal 10a associated with user <NUM> may receive the communication from server <NUM> and present the indication of the number of users and other places surrounding user <NUM> via a screen. Terminal 10a may provide a notification that server <NUM> has sent such information, such as a sound, icon, badge, or vibration. As another example, this information may be provided as an augmented reality experience for user <NUM> such that user <NUM> may be capable of moving terminal 10a to different location areas and receiving the number of other registered users in the places at the location areas. Such information may be visually represented on the screen of terminal 10a along with the places at the location areas.

<FIG> is a flowchart illustrating one embodiment of how analysis module <NUM> of <FIG> may receive preferred location information from user <NUM> of <FIG> and use it to enhance matching services with other users registered with server <NUM> of <FIG> (such as user <NUM>).

At step <NUM>, in some embodiments, location information from users registered with server <NUM> may be received and stored at server <NUM>. This may be performed similar to step <NUM> of <FIG>. Location information may be sent from terminals such as terminal 10a of users registered with server <NUM> actively or passively. Location information may include, for example, physical addresses or latitude/longitude coordinates. The location information and users associated with that location information may be stored at server <NUM> along with other information (such as the time the location information was received or sent) in a structure such as storage structure <NUM> of <FIG>.

At step <NUM>, in some embodiments, preferred location information from user <NUM> may be received by server <NUM>. For example, user <NUM> may be in a place such as a restaurant that user <NUM> appreciates. User <NUM> may desire to meet other people who also have visited the restaurant. As a result, user <NUM> may submit the location information of the restaurant to server <NUM> in order to be matched with others who have been at the restaurant. Terminal 10a may be used to send the preferred location information that is received at step <NUM>. Examples of the location information received at step <NUM> may include latitude/longitude coordinates, an address, a city, a state, a zip code, a point of interest, and/or other suitable descriptions of a location. As an example, user <NUM> may use a mobile device, such as a smart phone, to start an application that is configured to communicate with server <NUM>. When at a location that user <NUM> appreciates, user <NUM> may indicate to the application to send the current location information regarding user <NUM> to server <NUM>. As another example, user <NUM> may be in a neighborhood that user <NUM> appreciates. User <NUM> may send the location information to server <NUM> in order to be matched with other users of server <NUM> that may be associated with the neighborhood. For example, server <NUM> may provide a matching service, a dating service, or a real estate listing service in which user <NUM> would want to be matched with those who are associated with the neighborhood. As another example, user <NUM> may be planning to visit a location or planning to attend an event in the future. User <NUM> may indicate to the application to send that location or the event in order to be matched with other users of server <NUM> that may be associated with that location or that event.

At step <NUM>, in some embodiments, analysis module <NUM> may compare the preferred location information received at step <NUM> to the location information stored at step <NUM>. This may be done to identify registered users of server <NUM> that have location information associated with them that match or correspond to the preferred location information received at step <NUM>. In some embodiments, location types corresponding to the location information are compared. Location types may be determined for the location information, and it may be determined whether there is a match in location types. Events occurring at places corresponding to the location information may be determined. For example, it may be determined that the preferred location information received at step <NUM> corresponds to a coffee shop. The location information submitted at step <NUM> may be analyzed to determine others who have been to coffee shops to see if there is a match in location type. Other characteristics may be taken into account during the comparison at step <NUM>. For example, user <NUM> may specify other preferences regarding desired matches and those preferences may be compared to users identified by comparing the preferred location information to the stored location information. For example, user <NUM> may have registered with a dating service offered by server <NUM>. User <NUM> may have specified that they prefer to be matched with users that are under the age of <NUM>. Analysis module <NUM> may determine that a user over the age of <NUM> also had the same preferred location information and may disregard the user even though the preferred location information is the same as the stored location information. As another example, the preferred location information may be given more weight than other preferences submitted by user <NUM>. For example, user <NUM> may specify that he would prefer to meet with people who have blonde hair yet analysis module <NUM> may determine matches with user <NUM> of those that do not have blonde hair yet have matching location information.

At step <NUM>, in some embodiments, matches based on the comparison of the preferred location information to the stored location information may be presented to user <NUM>. For example, analysis module <NUM> may cause such matches to be presented to user <NUM>. In some embodiments, this may be advantageous in that user <NUM> may be able to provide more preferences to one or more services offered by server <NUM> in order to obtain more relevant results. User <NUM> may also have an opportunity to discover new preferences and efficiently provide them to server <NUM> to obtain more relevant results. The matches may be presented on devices that user <NUM> has access to, such as terminal 10a. The results may be presented as a response to user <NUM> submitting the preferred location information. For example, user <NUM> may enter into a location such as a museum and desire to be matched with those that have also attended a museum. As a response, server <NUM> may analyze the stored location information and provide the matches presented at step <NUM> within seconds, minutes, hours or days. User <NUM> may be notified of the new matches at terminal 10a as they are sent by server <NUM> or user <NUM> may appreciate the new matches when accessing one or more services offered by server <NUM> after sending the preferred location information. The matches presented at step <NUM> may be matches that server <NUM> has already determined prior to receiving the preferred location information but have been prioritized as a result of receiving the preferred location information. For example, based on an initial set of preferences submitted before the preferred location information was submitted by user <NUM>, server <NUM> may have identified <NUM> candidates for potential matches with user <NUM>. As a result of receiving preferred location information and identifying of those <NUM> candidates those who also have location information that corresponds to the preferred location information analysis module <NUM> may reorder the set of <NUM> users such that those with matching location information may be presented sooner to user <NUM> than those matches without corresponding location information. In some embodiments, this may provide an advantage in that user <NUM> may be able to perceive more relevant results sooner.

<FIG> illustrates an example computer system <NUM> suitable for implementing one or more portions of particular embodiments. Although the present disclosure describes and illustrates a particular computer system <NUM> having particular components in a particular configuration, the present disclosure contemplates any suitable computer system having any suitable components in any suitable configuration. Moreover, computer system <NUM> may have take any suitable physical form, such as for example one or more integrated circuit (ICs), one or more printed circuit boards (PCBs), one or more handheld or other devices (such as mobile telephones or PDAs), one or more personal computers, one or more super computers, one or more servers, and one or more distributed computing elements. One or more components of <FIG> and one or more steps of <FIG> may be implemented using all of the components, or any appropriate combination of the components, of computer system <NUM> described below.

Computer system <NUM> may have one or more input devices <NUM> (which may include a keypad, keyboard, mouse, stylus, or other input devices), one or more output devices <NUM> (which may include one or more displays, one or more speakers, one or more printers, or other output devices), one or more storage devices <NUM>, and one or more storage medium <NUM>. An input device <NUM> may be external or internal to computer system <NUM>. An output device <NUM> may be external or internal to computer system <NUM>. A storage device <NUM> may be external or internal to computer system <NUM>. A storage medium <NUM> may be external or internal to computer system <NUM>. In some embodiments, terminals 10a and 10b, server <NUM>, and POI database <NUM> of <FIG> may be implemented using some or all of the components described above included in computer system <NUM>.

System bus <NUM> couples subsystems of computer system <NUM> to each other. Herein, reference to a bus encompasses one or more digital signal lines serving a common function. The present disclosure contemplates any suitable system bus <NUM> including any suitable bus structures (such as one or more memory buses, one or more peripheral buses, one or more a local buses, or a combination of the foregoing) having any suitable bus architectures. Example bus architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, Enhanced ISA (EISA) bus, Micro Channel Architecture (MCA) bus, Video Electronics Standards Association local (VLB) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express bus (PCI-X), and Accelerated Graphics Port (AGP) bus.

Computer system <NUM> includes one or more processors <NUM> (or central processing units (CPUs)). A processor <NUM> may contain a cache <NUM> for temporary local storage of instructions, data, or computer addresses. Processors <NUM> are coupled to one or more storage devices, including memory <NUM>. Memory <NUM> may include random access memory (RAM) <NUM> and read-only memory (ROM) <NUM>. Data and instructions may transfer bidirectionally between processors <NUM> and RAM <NUM>. Data and instructions may transfer unidirectionally to processors <NUM> from ROM <NUM>. RAM <NUM> and ROM <NUM> may include any suitable computer-readable storage media.

Computer system <NUM> includes fixed storage <NUM> coupled bi-directionally to processors <NUM>. Fixed storage <NUM> may be coupled to processors <NUM> via storage control unit <NUM>. Fixed storage <NUM> may provide additional data storage capacity and may include any suitable computer-readable storage media. Fixed storage <NUM> may store an operating system (OS) <NUM>, one or more executables (EXECs) <NUM>, one or more applications or programs <NUM>, data <NUM> and the like. Fixed storage <NUM> is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. In appropriate cases, the information stored by fixed storage <NUM> may be incorporated as virtual memory into memory <NUM>. In some embodiments, fixed storage <NUM> may include network resources, such as one or more storage area networks (SAN) or network-attached storage (NAS). In some embodiments, memory <NUM>, storage structures <NUM> and <NUM>, and analysis module <NUM> of <FIG> and <FIG> may be implemented using configurations such as the description of memory <NUM> above.

Processors <NUM> may be coupled to a variety of interfaces, such as, for example, graphics control <NUM>, video interface <NUM>, input interface <NUM>, output interface <NUM>, and storage interface <NUM>, which in turn may be respectively coupled to appropriate devices. Example input or output devices include, but are not limited to, video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styli, voice or handwriting recognizers, biometrics readers, or computer systems. Network interface <NUM> may couple processors <NUM> to another computer system or to network <NUM>. Network interface <NUM> may include wired, wireless, or any combination of wired and wireless components. Such components may include wired network cards, wireless network cards, radios, antennas, cables, or any other appropriate components. With network interface <NUM>, processors <NUM> may receive or send information from or to network <NUM> in the course of performing steps of particular embodiments. Particular embodiments may execute solely on processors <NUM>. Particular embodiments may execute on processors <NUM> and on one or more remote processors operating together. In some embodiments, processors <NUM> may be used to implement analysis module <NUM> of <FIG> and/or may perform the steps specified in instructions or code included in analysis module <NUM> of <FIG>.

In a network environment, where computer system <NUM> is connected to network <NUM>, computer system <NUM> may communicate with other devices connected to network <NUM>. Computer system <NUM> may communicate with network <NUM> via network interface <NUM>. For example, computer system <NUM> may receive information (such as a request or a response from another device) from network <NUM> in the form of one or more incoming packets at network interface <NUM> and memory <NUM> may store the incoming packets for subsequent processing. Computer system <NUM> may send information (such as a request or a response to another device) to network <NUM> in the form of one or more outgoing packets from network interface <NUM>, which memory <NUM> may store prior to being sent. Processors <NUM> may access an incoming or outgoing packet in memory <NUM> to process it, according to particular needs.

Particular embodiments involve one or more computer-storage products that include one or more tangible, computer-readable storage media that embody software for performing one or more steps of one or more processes described or illustrated herein. In particular embodiments, one or more portions of the media, the software, or both may be designed and manufactured specifically to perform one or more steps of one or more processes described or illustrated herein. In addition or as an alternative, in particular embodiments, one or more portions of the media, the software, or both may be generally available without design or manufacture specific to processes described or illustrated herein. Example computer-readable storage media include, but are not limited to, CDs (such as CD-ROMs), FPGAs, floppy disks, optical disks, hard disks, holographic storage devices, ICs (such as ASICs), magnetic tape, caches, PLDs, RAM devices, ROM devices, semiconductor memory devices, and other suitable computer-readable storage media. In particular embodiments, software may be machine code which a compiler may generate or one or more files containing higher-level code which a computer may execute using an interpreter.

As an example and not by way of limitation, memory <NUM> may include one or more tangible, non-transitory, computer-readable storage media embodying software and computer system <NUM> may provide particular functionality described or illustrated herein as a result of processors <NUM> executing the software. Memory <NUM> may store and processors <NUM> may execute the software. Memory <NUM> may read the software from the computer-readable storage media in mass storage device <NUM> embodying the software or from one or more other sources via network interface <NUM>. When executing the software, processors <NUM> may perform one or more steps of one or more processes described or illustrated herein, which may include defining one or more data structures for storage in memory <NUM> and modifying one or more of the data structures as directed by one or more portions the software, according to particular needs. In some embodiments, memory <NUM>, storage structures <NUM> and <NUM>, and analysis module <NUM> of <FIG> and <FIG> may be implemented using configurations such as the description of memory <NUM> above.

In some embodiments, the described processing and memory elements (such as processors <NUM> and memory <NUM>) may be distributed across multiple devices such that the operations performed utilizing these elements may also be distributed across multiple devices. For example, software operated utilizing these elements may be run across multiple computers that contain these processing and memory elements. Other variations aside from the stated example are contemplated involving the use of distributed computing. In addition or as an alternative, computer system <NUM> may provide particular functionality described or illustrated herein as a result of logic hardwired or otherwise embodied in a circuit, which may operate in place of or together with software to perform one or more steps of one or more processes described or illustrated herein. The present disclosure encompasses any suitable combination of hardware and software, according to particular needs.

Although the present disclosure describes or illustrates particular operations as occurring in a particular order, the present disclosure contemplates any suitable operations occurring in any suitable order. Moreover, the present disclosure contemplates any suitable operations being repeated one or more times in any suitable order. Although the present disclosure describes or illustrates particular operations as occurring in sequence, the present disclosure contemplates any suitable operations occurring at substantially the same time, where appropriate. Any suitable operation or sequence of operations described or illustrated herein may be interrupted, suspended, or otherwise controlled by another process, such as an operating system or kernel, where appropriate. The acts can operate in an operating system environment or as stand-alone routines occupying all or a substantial part of the system processing.

Claim 1:
A system (<NUM>), comprising:
an interface (<NUM>) configured to:
receive first future location information of a first user (<NUM>) at a first time;
receive second future location information of a second user (<NUM>) at a second time, wherein the difference between the first time and the second time is less than a threshold;
one or more processors communicatively coupled to the interface (<NUM>) and configured to:
determine that the first future location information and the second future location information each correspond to a future location;
determine that a characteristic related to the first user (<NUM>) corresponds to a preference related to the second user (<NUM>); and
in response to determining that a characteristic related to the first user (<NUM>) corresponds to a preference related to the second user (<NUM>) and in response to determining that the first future location information and the second future location information each correspond to a future location, cause information to be presented to the second user (<NUM>), the information to be presented to the second user (<NUM>) comprising the future location and that the first user (<NUM>) and the second user (<NUM>) have the future location in common.