US20140222908A1

US20140222908A1 - Methods and systems for a location-based online social network

Info

Publication number: US20140222908A1
Application number: US13/757,574
Authority: US
Inventors: David S. Park; Madison Nixon Bell; Rishi Mukhopadhyay; Thomas F. Kaehler; Jacob L. Hesch; Sean C. Bromage; Rich Barton; David Michael Wiesen; Ryan Patrick Sims
Original assignee: Nextdoor com Inc
Current assignee: Nextdoor com Inc
Priority date: 2013-02-01
Filing date: 2013-02-01
Publication date: 2014-08-07
Also published as: US9940008B2; US20160274785A1; WO2014121145A1; EP2951778A4; EP2951778A1; CA2900042A1

Abstract

Disclosed embodiments relate to a system and a method of managing an online social network having a plurality of neighborhoods. The system may receive a location from a user, and select, based on the location, a neighborhood from the plurality of neighborhoods. The system may further assign the user to the selected neighborhood and grant the user access to communications by users assigned to the selected neighborhood.

Description

TECHNICAL FIELD

The present disclosure relates to methods and systems for a location-based online social network. The location-based online social network may provide communications to a user associated with a location.

BACKGROUND

Online social networks are becoming an increasingly popular way of communication between Internet users. Online social networks facilitate the building and maintaining of social relations among people who share interests, activities, backgrounds, or real-life connections. Some online social networks are geared towards specific types of connections (e.g., LinkedIn mainly promotes professional networking), while others are not limited to any particular use (e.g., Facebook, Google+, Twitter). Online social networks can be global or have some national characteristics (e.g., Nexopia in Canada, and Vkontakte in Russia), but online social networks typically do not collect accurate and reliable residence information from their users, and therefore cannot offer many advantageous features requiring such information.

SUMMARY

Consistent with a disclosed embodiment, a computer-implemented method is provided for managing an online social network having a plurality of neighborhoods. The method includes receiving a location from a user and selecting, based on the location, a neighborhood from the plurality of neighborhoods. The method further includes assigning the user to the selected neighborhood, and granting the user access to communications by users assigned to the selected neighborhood.
Consistent with another disclosed embodiment, a server is provided for managing an online social network having a plurality of neighborhoods. The server includes a processor and a memory storing instructions executable by the processor to provide the method discussed above.
Consistent with yet another disclosed embodiment, a tangible non-transitory computer-readable storage medium is provided storing instructions configured to execute the method discussed above.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments. In the drawings:

FIG. 1 is a block diagram illustrating an exemplary online social network system.

FIG. 2A is a schematic diagram of an exemplary online social network.

FIG. 2B is an exemplary map showing geographical areas associated with neighborhoods of the online social network.

FIG. 3 is a flowchart illustrating an exemplary method of adding a new user to the online social network.

FIG. 4 illustrates an exemplary method of selecting and adjusting a nearby neighborhood list for a particular neighborhood of the online social network.

FIG. 5 illustrates an exemplary method of selecting a nearby neighborhood list for a particular neighborhood of the online social network.

DETAILED DESCRIPTION

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
Online social networks with unrestricted global access have their advantages, but by ignoring the physical whereabouts of their users they fail to exploit the fact that people from the same geographical area, on average, have more in common than people living in different places. This is especially true for people living in the same immediate community, i.e., the same neighborhood. People living in the same neighborhood (e.g., within the same city, town, ZIP code, street block, etc.) are likely to share many interests and concerns even if they have never met in person. They are likely to go to the same shops, restaurants, and parks; their children go to the same schools; they are governed by the same local regulations; and so on.
In addition to sharing many of the same interests, people living in such proximity of each other are capable of providing physical assistance to each other, for example, by lending each other a ladder, giving each other rides to work, or helping each other to locate lost pets. Therefore, it would be highly advantageous to provide an online social network that is location-aware, such as, for example, one that is neighborhood-based.
Disclosed embodiments relate to a system and a method of managing an online social network having a plurality of neighborhoods. The system may receive a location from a user, and select, based on the location, a neighborhood from the plurality of neighborhoods. The system may further assign the user to the selected neighborhood and grant the user access to communications by users assigned to the selected neighborhood.
FIG. 1 is a block diagram illustrating an exemplary online social network system, in accordance with a disclosed embodiment. The online social network system can include, among other things, an application server 102, one or more user devices 104, and a communication network 106.
A user device 104 can be any device with communication and display capabilities. For example, a user device 104 can be a mobile device, such as a cellphone, a smartphone, or a tablet computer; or a PC, laptop computer, or smart TV. A user device 104 can include an internet access application 108, such as a web browser or a dedicated mobile application (“mobile app”) providing the user with a convenient interface to the online social network. A user device 104 may include one or more processors capable of executing instructions configured to provide internet access application 108. The instructions can be stored on one or more tangible non-transitory computer-readable mediums, such as a hard disk, a compact disk (CD-ROM) a digital versatile disk (DVD-ROM or DVD-RAM) or semiconductor memory of any type.
User devices 104 can exchange data with application server 102 through communication network 106. Communication network 106 can be the Internet, or any other type of network or combination of networks, suitable for the data exchanges described herein. Thus, communication network 106 can include, for example, any combination of wired, wireless, LAN or WAN networks. Communication network 106 can also be implemented as a distributed “peer-to-peer” network. Communication network 106 can include cellular networks (e.g., 3GPP) or landline telephone networks, enabling data exchange not-only via IP-based protocols (e.g., HTTP, HTTPS, POP, IMAP, SMTP, SIP, SSH, etc.) but also via text messages, automatic or personal phone calls, voicemails, etc. Furthermore, communication network 106 can include non-electronic means of data exchange, such as regular mail (e.g., postcards).
Application server 102 can be any computer system with networking capabilities, and can include one or more hardware devices and/or software components. Application server 102 can include one or more processors capable of executing instructions. For example, application server 102 can include one or more general purpose central processing units (CPUs), field-programmable gate arrays (FPGAs), or digital signal processors (DSPs). The instructions can be stored on one or more tangible non-transitory computer-readable mediums, such as a hard disk, a compact disk (CD-ROM) a digital versatile disk (DVD-ROM or DVD-RAM) or semiconductor memory of any type.
Application server 102 can store and process information related to an online social network, as described in detail below. For instance, application server 102 can have one or more databases for storing user information, such as login credentials, full name, address, account settings, etc. In addition, application server 102 can have one or more databases for storing user communications, such as personal messages, posts, comments, etc.
Application server 102 can communicate with user devices 104 through communication network 106. For example, application server 102 can receive and process users' requests, such as a request to create a new account, to log into an existing account, to send a message to another user, to create a post and share them with other users, to receive a list of other user's recent posts and comments, and so on. After processing the user's request, application server 102 can, for example, access one or more databases to store and/or load data, and send a response to the user.
Exchange of data between application server 102 and user 104 can be facilitated by interne access application 108, which can, for example, provide the user with a graphical interface through which the user can enter requests to and visualize responses from application server 102.
Although particular types of devices and networks are described, it will be appreciated that other devices and networks can be used without departing from the spirit and scope of the embodiments described herein.
FIG. 2A is a schematic diagram of an exemplary online social network 200, in accordance with a disclosed embodiment. Online social network 200 comprises a plurality of users 210 a-210 j (collectively, 210) who are arranged in a plurality of virtual groups called “neighborhoods” 220 a-220 c (collectively, 220). In some embodiments, each user 210 is associated with one neighborhood 220. A user 210 that is associated with a neighborhood 220 can also be said, for example, to “belong to,” “be in,” “be from,” “be assigned to,” or “be a member of” that neighborhood 220. In other embodiments, a user can be assigned to more than one neighborhood 220.
In an embodiment, a user 210 is assigned to a particular neighborhood 220 based on the user's place of residence, as defined, for example, by an address or by the spatial coordinates of the user's home. Each neighborhood 220 can be associated with a real-world geographical area, and the user can be assigned to the neighborhood 220 that is associated with a geographical area that encompasses the user's place of residence.
FIG. 2B is an exemplary map showing the geographical areas associated with neighborhoods 220 a-220 c, and the addresses of users 210 a-210 j of the online social network 200. Geographical areas associated with neighborhoods 220 can be defined by boundaries (hereinafter, “neighborhood boundaries”). As illustrated in FIG. 2B, neighborhood boundaries can have different shapes and sizes and can be defined in a number of ways. In some embodiments, neighborhood boundaries can be defined based on existing maps, such as street maps, ZIP-code maps, maps of subdivisions and homeowners associations, or neighborhood maps existing in some municipalities. The boundaries can also be based on man-made or natural barriers, such as buildings, roads, parks, rivers or lakes. The boundaries can be drawn by users 210, administrators of the online social network 200, or automatically defined by a computer, for example, by an application server (e.g., application server 102). Users 210 or administrators of the online social network 200 can modify the computer-generated boundaries and draw their own neighborhood boundaries.
In some embodiments, neighborhood boundaries corresponding to different neighborhoods 220 cannot cross each other, that is, the geographical areas associated with the different neighborhoods 220 cannot overlap. In other embodiments, the geographical areas can overlap, and some addresses may be included in more than one geographical area. In some embodiments, users living at such addresses can choose which of the neighborhood 220 they want to be associated with.
FIG. 3 is a flowchart illustrating an exemplary method 300 of adding a new user 210 to online social network 200. Method 300 can be implemented by an application server (e.g., application server 102). While the flowchart discloses the following blocks in a particular order, it is appreciated that the blocks can be moved, modified, combined, or deleted where appropriate.
In block 302, the user connects to the application server. For example, the user can use internet access application 108 running on user device 104 to connect via communication network 106 to the application server.
After connecting to the application server, if user does not already have an account with online social network, in block 304, the application server can create a new account for the user. The user can provide to the application server his or her personal information, such as a full name, address, username, password, etc. In some embodiments, the user is required to disclose the user's physical address, including, for example, house and apartment number, street name, city/town name, state name, zip code, and/or country name, etc. In other embodiments, approximate address information (e.g., zip code or city/town name only,) can be sufficient.
In some embodiments, in block 306, after receiving the address information from the user, the application server can, optionally, verify the provided address. The address can be verified, for example, by receiving from the user a number of a credit card associated with the address, and charging that credit card with a symbolic sum (e.g., $0.01) in order to compare the credit card's billing address with the user-provided address. Alternatively, a postcard comprising a verification code can be sent to the provided address. Upon receiving the postcard in the mail, the user can re-connect to the application server and provide it with the received verification code as printed on the postcard.
In some embodiments, the application server can access a database in which people's addresses are associated with residents' phone numbers and/or full names. If the address provided by the user is associated in the database with a phone number, the application server can send the verification code to that phone number, for example, using a text message or an automatically generated voice message. If the address provided by the user is associated in the database with one or more resident names, the application server can also verify, for example, that the user's last name matches the last name of any of the residents associated with the address.
In some embodiments, the application server can verify the user's address by first verifying the user's real name, for example, by asking the user to log into an existing online account that is likely to be associated with the user's real name (e.g., Facebook). After verifying the user's real name the application server can check, using the database described above, that the name is associated with the provided address. In some embodiments, the application server compares two addresses by first normalizing each address to comply with a certain address format.
In some embodiments, the application server can access databases that can reliably associate the user's IP address with the user's home address. Such databases can be obtained, for example, from Internet-service providers, such as Comcast or AT&T. The application server can use that database to compare the provided user address with the home address associated with the IP address from which the user has logged into the online social network 200.
In some embodiments, if the user is connected to the application server from a device (e.g., a smart phone) equipped with a GPS unit or any other geolocation service, internet access application 108 can, with the user's permission, periodically send to the application server the device's coordinates. The application server can then compare the received coordinates with coordinates associated with the provided address, as obtained, for example, from a geocoding resource. The application server can then determine that the address is verified if the user spends a predefined period of time (e.g., 24 hours) at or within a predefined distance from that address.
In some embodiments, the verification at block 306 can be omitted. For example, if the new user was invited by an existing user from the same neighborhood 220, the application server can decide that address verification is not necessary. In some embodiments, a new user who has not been invited can identify existing users who can confirm that he or she lives at the specified address. The application server can then contact the identified user and ask that user for a confirmation. In some embodiments, to improve reliability and accountability of the invitation/confirmation system described above, the name of the inviting/confirming user can be available as a part of the new user's information visible to other users.
In some embodiments, unverified or partially verified users (e.g., users whose ZIP code was verified, but not the full address) can still have access to the online social network, but their access may be restricted. For example, they may be given “read-only” rights allowing them only to read other neighbors' posts and comments, but not allowing them to create their own posts or make comments.
In block 308, after receiving and (optionally) verifying the user's address, the application server can determine whether the address falls within the boundaries of an existing neighborhood 220. For example, the boundaries of existing neighborhoods 220 can be defined by an ordered set of latitude-longitude points and stored in a database on the application server. The application server can obtain the coordinates of the user's address in the same coordinate system, and determine whether those coordinates are located inside the boundaries of any neighborhood 220. If the user's address can not be tied to a coordinate or set of coordinates, in some embodiments, user 210 may specify a coordinate, or a set of coordinates creating a closed polygon, which is attached to the user's address and used to determine the user's membership in a neighborhood, using the same coordinate system.
In some embodiments, the application server can store, in association with neighborhoods 220, addresses of all households located within the geographical areas associated with the neighborhoods. In that case, in block 308, the application server can locate, in a database, a household whose address matches the user's address.
In block 308, if the user's address falls within one of the existing neighborhoods 220, the process proceeds to block 310 and the application server assigns the user to the neighborhood. In some embodiments, an existing neighborhood can be associated not only with a geographical area, but with a membership group. Membership groups can include, for example, parent-teachers associations (PTAs), professional memberships, memberships based on hobbies, interests, ages, etc. For example, a neighborhood called “Seniors of Sampletown” can be associated both with a geographical area (e.g. defined by the boundaries of Sampletown) and with a membership group requiring that all its members are 65 years old or older. For neighborhoods associated with a geographical area and a membership group, the verification at block 306 can also include verifying that the user is a member of that group.
Furthermore, in some embodiments, some neighborhoods may only be associated with a membership group, and not a geographical area. In some embodiments it may be required that the membership group has a local nature, such as a membership group of “Parents of Marshall Lane Elementary students.”
In block 308, the application server determines that the address does not fall within any of the existing neighborhoods 220, the process proceeds to block 312 and the application server can create a new neighborhood 220 whose boundaries will include the address. The boundaries of the new neighborhood can be manually defined by the user, but the application server can assist the user by automatically generating suggested boundaries. In other embodiments, the application server can determine the boundaries of the new neighborhood.
The application server can consider various factors when it generates the suggested boundaries, including, for example, the size of the enclosed area (e.g., in number of households), major man-made or natural boundaries (e.g., roads, rivers, parks), geographical borders (e.g., city, county, or state borders), boundaries of other neighborhoods 220, and so forth. For example, the application server can generate suggested boundaries such as to include a predefined number of households without crossing any major natural boundaries or boundaries of other neighborhoods 220. In an attempt to create a homogeneous neighborhood whose users would have many common interests and concerns, the application server can also consider factors, such as school districts, home prices, average age of residents, or any other relevant information.
In some embodiments, the suggested boundaries can be presented to the user on a map, for example, via interne access application 108. The user can manually modify the suggested boundaries, for example, by drawing new boundaries on the map or editing the suggested boundaries. In some embodiments, locations of the individual households can also be presented on the map for reference.
In some embodiments, the application server can apply certain restrictions on the shape or size of the boundaries of the new neighborhood. For example, application server may not allow the new neighborhood to overlap with any of the existing neighborhoods 220. In another example, the application server can set minimum and/or maximum restrictions on area size and/or population of the geographic area associated with the new neighborhood, where the population can be defined in either the number of households or the number of residents. For example, the application server can require that the new neighborhood contain at least 10 households but not more than 1000 households, and that its area does not exceed 1 square mile. In block 314, after the new neighborhood has been created, the application server assigns the user to the new neighborhood.
In some embodiments, each neighborhood 220 has at least one of its users designated as the neighborhood's moderator, or “lead.” As will be illustrated below, a moderator can have certain administrative functions with respect to the neighborhood that regular users do not have. In some embodiments, in block 316, the user who creates a neighborhood 220 (i.e., the first user assigned to that neighborhood 220) is automatically designated as a moderator of that neighborhood 220. In some embodiments, neighborhood moderators are selected based on the length of their membership in the neighborhood, the amount of content they have generated (since joining or within a predefined period of time), the number of invitations they send, and so forth. Additionally or alternatively, new moderators can be nominated and/or selected by existing moderators or by other neighbors from the same neighborhood.
In some embodiments, interne access application 108 can present to a user a map of the area associated with the user's neighborhood 220. The map can include, for example, the boundaries of the user's neighborhood 220, the boundaries of nearby neighborhoods 220 in the region, and the locations and boundaries of the individual households in the area. The map can further include boundaries of the local police precincts, school district boundaries, city boundaries, or any other local information the neighbors may find useful.
In some embodiments, the map can also include an indication, for each of the individual households, whether the resident of that household has joined (i.e., has become a user of) online social network 200. If the resident has not joined the network, the user can invite that resident to join the network. For example, the user can compose a personal invitation message, provide that message to the application server, and a postcard containing the message will be mailed to that resident's address. As another example, the user can provide to the application server the email address or other contact information of the resident (e.g., the resident's Facebook or Twitter account), allowing the application server to contact the resident through using that contact information. As yet another example, the user can invite his or her friends on other social platforms by providing them with an invitation link. The link can be obtained by the user from the application server and the user can distribute the link to the invitee(s) via an email, a post in another online social network, a text message, etc. When the recipient of the invitation link follows the link (e.g., using a browser) he or she can be connected to the application server's “sign up” page. Information about the inviting user can be included in the link and recognized by the application server, in which case the application server can, for example, omit the address verification step at block 306 based on the that information. Furthermore, the application server can provide to the user a flyer (e.g., via email or on the website in a printable format or via regular mail) containing information about the online social network and (optionally) about the inviting user. The user can then physically distribute the flyers to his or her neighbors.
If the resident has already joined the network and is one of the users 210, the map can include information about that user, such as his or her personal name, username, status (e.g., online or offline), and offer some means to immediately contact that user, for example, by sending a personal message.
Online social network 200 allows its users to communicate in various ways. For example, a first user can send a personal message to a second user, the message being accessible only to these two users. Alternatively, a user can create a “post” (or a “thread”), a message that is accessible to multiple users, or a message that is sent to multiple users. In some embodiments, users who have access to a particular post can read the post, leave comment to the post, see other users' comments to the post, respond to comments by other users, and so on. This enables a forum-like discussion by multiple users on a particular topic.
In some embodiments, any user from a particular neighborhood 220 automatically has access to all communications posted by other members from the same neighborhood 220 with the intent to share them with all current and future members of the neighborhood 220. Thus, the user does not need to specifically identify those users, among the numerous users of online social network 200, whose communications this user would like to have access to. Instead, by having an automatic access to all communications originating from the user's neighborhood 220, the user is automatically “connected” to users who are likely to share at least one interest, interest in their local community. In addition, users from the same local community often share many other interests, as they often have the same socio-economic and cultural backgrounds.
In some embodiments, a user, after logging into online social network 200, can see (e.g., using internet access application 108) a chronological feed of all posts that the user has access to. However, if too many posts are accessible to the user, the user may not have the time to read or even skim through all of them, which can be frustrating for the user. Therefore, in some embodiments, the amount of accessible posts is controlled by a) restricting the neighborhood size (e.g., when a new neighborhood is created) to a predefined number of households, and/or b) by default, restricting the user's access to communications (e.g., posts) by users from the same neighborhood only. The latter restriction means that, by default, the user cannot see any communications created by users outside of his or her neighborhood. In addition, content available to the user can be filtered and/or prioritized based on the user's personal interests, as determined, for example, based on the user's past activities in online social network 200 (e.g. by analyzing the topics and/or the authors of the posts on which the user often comments) or based on the user's express selection of topics he or she is interested in.

Nearby Neighborhoods

Sometimes, users may wish to engage in discussions with users outside of their immediate neighborhood 220. For example, there may be matters that concern residents from several neighborhoods (e.g., city council elections) and it would be beneficial to discuss those matters in a larger forum. To address these needs, in some embodiments, a user can have access to “Nearby Neighborhoods,” neighborhoods other than the user's neighborhood 220, but in proximity thereto. Having access to “Nearby Neighborhoods” may enable members to: make a post with the intent to share it with members of their “Nearby Neighborhoods,” in addition to their own neighborhood; read or comment on posts created by other members of their “Nearby Neighborhoods” with the intent to share it with the authors' “Nearby Neighborhoods,” which may or may not be the same as the viewing member's “Nearby Neighborhoods”; read all comments on posts created by other members of their “Nearby Neighborhoods” with the intent to share with the authors' “Nearby Neighborhoods”, even if the authors of some comments are not members of the viewing member's “Nearby Neighborhoods.” In some embodiments, access to “Nearby Neighborhoods” is enabled by default, and the user can “opt out” of it. In other embodiments, the access is disabled by default, and the user can “opt in” to it.
In some embodiments, the application server can automatically select, for each neighborhood 220, a set of one or more neighborhoods 220 that qualify as its nearby neighborhoods, also described as the “Nearby Neighborhoods” set or the NN-set.
FIG. 4 illustrates an exemplary method 400 of selecting and adjusting the NN-set for a particular neighborhood 220 (“neighborhood N”) of the online social network 200, in accordance with a disclosed embodiment. Method 400 can be performed, for example, by an application server (e.g., application server 102) when neighborhood N is created.
In block 402, method 400 can choose an algorithm and its parameters for selecting the NN-set for a particular neighborhood 220. In some embodiments, the chosen algorithm and parameters may apply for more than one neighborhood. In some embodiments, the method can choose a predefined default algorithm and/or its parameters. In other embodiments, the algorithm and its parameters are chosen by administrators of the online social networks.
In some embodiments, one of the algorithm's parameters used is population threshold. The population threshold can indicate a maximum number of households (or individual residents) to be included in the neighborhoods belonging to the NN-set. The population threshold can either include or exclude the population of neighborhood N itself. Furthermore, the population threshold can either include or exclude potential users, that is, households (or individual residents) that have not yet joined online social network 200. In some embodiments, the population threshold is a fixed and predefined number.
In other embodiments, the population threshold can be set based on the characteristics of neighborhood N, which are provided to the algorithm as parameters. Such characteristics can include, for example, the area size of neighborhood N, its population (in residents or in households), population density (population divided by area), housing prices, and so forth.
For example, the population threshold can be a monotonic decreasing, or non-increasing, function of the population density of neighborhood N. In other words, the population threshold can decrease as the population density increases. As a result, suburban neighborhoods with low population densities will receive higher population thresholds and will therefore receive an NN-set with a larger total population (e.g., 5,000 households), than their urban counterparts (e.g., 2,000 households). This can be advantageous, because there are typically fewer similarities between nearby neighborhoods in an urban area than in a suburban area. Accordingly, decreasing the threshold in urban areas reduces the likelihood that distant neighborhoods having little in common with neighborhood N will be included in its NN-set.
In block 404, after the algorithm and its parameters are chosen, the method selects neighborhoods 220 to be added to the NN-set of neighborhood N based on the algorithm and its parameters. For example, the method can execute the algorithm using one or more processors of application server 102.
In some embodiments, the algorithm selects those neighborhoods 220 that are geographically closest to neighborhood N and whose total population does not exceed (or does not substantially exceed) the population threshold. In some embodiments, the algorithm can sort all neighborhoods by their distance from neighborhood N, and add neighborhoods (from nearest to farthest) to NN-set until the total population of the added neighborhoods reaches the population threshold. The distance between two neighborhoods can be defined, for example, as the distance between the neighborhoods' centers, where the center can be defined, for example, as a geometric median of all the household locations in that neighborhood. Alternatively, a distance between two neighborhoods can be defined as the shortest distance between any household of the first neighborhood and any household of the second neighborhood.
In some embodiments, in addition to a neighborhood's distance from neighborhood N, the algorithm can include other factors in sorting the neighborhoods. One such factor can be the level of similarity between the two neighborhoods, for example, in terms of population density or housing prices. In other words, instead of sorting neighborhoods only by their distance from neighborhood N, the algorithm can also consider their similarity levels to neighborhood N. For example, the algorithm can assign a score to each neighborhood, where the score is in direct proportion to the similarity level and in reverse proportion to their distance, and then sort neighborhoods based on those scores. In this example, neighborhoods with high scores will be added to the NN-set first.
In some embodiments, the algorithm can create an NN-set for a given neighborhood by gradually adding the households around the neighborhood, from closest to the farthest, until the number of households reaches the population threshold. The algorithm can then add to the NN-set all neighborhoods that include at least one of those households.
It will be noted that if some of the added households do not belong to any existing neighborhoods, the total population of the neighborhoods added to the NN-set may be lower than the population threshold. If those households later become associated with newly created neighborhoods, those neighborhoods can be automatically added to the NN-set. Alternatively, if most of the added households belong to neighborhoods, the total population of the NN-set may exceed the population threshold. In either case, however, the total population of neighborhoods included in the NN-set is determined by, or correlates with the population threshold.
FIG. 5 illustrates an exemplary method of selecting an NN-set for a particular neighborhood 220, of the online social network 200, in accordance to some embodiments. FIG. 5 shows households 510, only some of which are associated with neighborhoods 520 a-520 e. When neighborhood 520 b is created, its NN-set can be determined, for example, in accordance with method 400.
For example, in the exemplary scenario shown in FIG. 5, the algorithm sets a threshold of 40 households, including the population of neighborhood 520 b. The algorithm then starts adding households, going from the center of neighborhood 520 b outward, until the number of households added reaches the threshold of 40. In other words, the algorithm increases the radius of a circle 530 (centered, for example, in the center of neighborhood 520 b) until 40 households are included in the circle. The algorithm then adds, to the NN-set of neighborhood 520 b, each neighborhood that includes any of the households that fall within that circle. In this example, neighborhoods 520 d, 520 e, and 520 a, are added to the NN-set, but neighborhood 520 c is not.
In some embodiments, instead of setting a population threshold, the algorithm sets an area threshold or a radius threshold, and adds to the NN-set all the neighborhoods which contain households within that area or radius. The area or radius threshold can also be set based on the characteristics of neighborhood N. For example, the area or radius threshold can increase as the population density of neighborhood N decreases, and vice versa.
In some embodiments, the algorithm considers both population and area/radius when selecting the NN-set. For example, the algorithm can run the population-based selection described above, but also have minimum and maximum restrictions on the area size, to avoid scenarios where the NN-set is too small or too large in terms of the total area of the neighborhoods included therein.
After the NN-set is created, the moderator of neighborhood N can modify the NN-set at block 406. For example, after examining the NN-set, the moderator can decide that some neighborhoods in that set should be removed from the set, for example, if the moderator has personal knowledge that those neighborhoods have little in common with neighborhood N. In some embodiments, the moderator can only remove neighborhoods from the NN-set, while in other embodiments the moderator can also add neighborhoods to the NN-set.
In some embodiments, the automatically generated and (optionally) moderator-modified NN-set applies to all users of neighborhood N by default. That is, if the user has access to nearby neighborhoods (either by opting in or by default), those nearby neighborhoods would be defined by that automatically generated and moderator-modified NN-set.
In some embodiments, in block 408, individual users can further modify the NN-set, as it applies to them. In other words, the user-modified NN-set will only apply to the user who modified it. In some embodiments, users can only modify their NN-set by removing neighborhoods from it, while in other embodiments, users can also add neighborhoods to their NN-set.
To facilitate the modification of the NN-set by the moderator or by the user, the application server can present to the moderator/user a map or a list containing all the neighborhoods that can potentially be added or removed, allowing the moderator/user to make selections on that map or list.
The foregoing description has been presented for purposes of illustration. It is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, the described implementations include hardware and software, but systems and methods consistent with the present disclosure can be implemented as hardware alone.
Computer programs based on the written description and methods of this specification are within the skill of a software developer. The various programs or program modules can be created using a variety of programming techniques. For example, program sections or program modules can be designed in or by means of Java, C, C++, Python, assembly language, or any such programming languages. One or more of such software sections or modules can be integrated into a computer system, computer-readable media, or existing communications software.
Moreover, while illustrative embodiments have been described herein, the scope includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations or alterations based on the present disclosure. The elements in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application, which examples are to be construed as non-exclusive. Further, the disclosed methods can be modified in any manner, including by reordering blocks or inserting or deleting blocks. It is intended, therefore, that the specification and examples be considered as example only, with a true scope and spirit being indicated by the following claims and their full scope of equivalents.

Claims

1. A computer-implemented method of managing an online social network having a plurality of neighborhoods, the method comprising:

receiving, by a processor, a location from a user;

selecting, by the processor, based on the location, a neighborhood from the plurality of neighborhoods;

assigning, by the processor, the user to the selected neighborhood;

selecting, by the processor, from the plurality of neighborhoods, a set of one or more neighborhoods, wherein each neighborhood in the selected set is associated with a geographical area proximate to the geographical area associated with the selected neighborhood; and

granting, by the processor, the user access to communications by users assigned to the selected neighborhood and communications by users assigned to neighborhoods within the selected set.

2. The method of claim 1, wherein the location comprises an address.

3. The method of claim 2, wherein selecting the neighborhood comprises determining which one of the plurality of neighborhoods is associated with a geographical area that includes the address.

4. The method of claim 1, wherein the selected neighborhood is associated with a geographical area that corresponds to one of a city, a town, a ZIP code, and a subdivision.

5. (canceled)

6. The method of claim 1, wherein the total population of the geographical areas associated with the neighborhoods from the selected set is correlated with a population threshold.

7. The method of claim 6, wherein the population threshold is calculated based at least on characteristics of the geographical area associated with the selected neighborhood.

8. The method of claim 1, wherein any user assigned to the selected neighborhood is denied access to communications by users assigned to neighborhoods other than the selected neighborhood and other than the neighborhoods in the selected set.

9. A server for managing an online social network having a plurality of neighborhoods, the server comprising:

a processor; and

a memory storing instructions, the instructions executable by the processor to:

receive a location from a user;

select, based on the location, a neighborhood from the plurality of neighborhoods;

assign the user to the selected neighborhood;

select, from the plurality of neighborhoods, a set of one or more neighborhoods, wherein each neighborhood in the selected set is associated with a geographical area proximate to the geographical area associated with the selected neighborhood; and

grant the user access to communications by users assigned to the selected neighborhood and communications by users assigned to neighborhoods within the selected set.

10. The server of claim 9, wherein the location comprises an address.

11. The server of claim 10, wherein selecting the neighborhood comprises determining which one of the plurality of neighborhoods is associated with a geographical area that includes the address.

12. The server of claim 9, wherein the selected neighborhood is associated with a geographical area that corresponds to one of a city, a town, a ZIP code, and a subdivision.

13. (canceled)

14. The server of claim 9, wherein the total population of the geographical areas associated with the neighborhoods from the selected set is correlated with a population threshold.

15. The application server of claim 14, wherein the population threshold is calculated based at least on characteristics of the geographical area associated with the selected neighborhood.

16. The application server of claim 9, wherein any user assigned to the selected neighborhood is denied access to communications by users assigned to neighborhoods other than the selected neighborhood and other than the neighborhoods in the selected set.

17. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method of managing an online social network having a plurality of neighborhoods, the method comprising:

receiving a location from a user;

selecting, based on the location, a neighborhood from the plurality of neighborhoods;

assigning the user to the selected neighborhood;

selecting, from the plurality of neighborhoods, a set of one or more neighborhoods, wherein each neighborhood in the selected set is associated with a geographical area proximate to the geographical area associated with the selected neighborhood; and

granting the user access to communications by users assigned to the selected neighborhood and communications by users assigned to neighborhoods within the selected set.

18. The non-transitory computer-readable storage medium of claim 17, wherein the location comprises an address.

19. The non-transitory computer-readable storage medium of claim 18, wherein selecting the neighborhood comprises determining which one of the plurality of neighborhoods is associated with a geographical area that includes the address.

20. The non-transitory computer-readable storage medium of claim 17, wherein the selected neighborhood is associated with a geographical area that corresponds to one of a city, a town, a ZIP code, and a subdivision.

21. (canceled)

22. The non-transitory computer-readable storage medium of claim 17, wherein the total population of the geographical areas associated with the neighborhoods from the selected set is correlated with a population threshold.

23. The non-transitory computer-readable storage medium of claim 22, wherein the population threshold is calculated based at least on characteristics of the geographical area associated with the selected neighborhood.

24. The non-transitory computer-readable storage medium of claim 17, wherein any user assigned to the selected neighborhood is denied access to communications by users assigned to neighborhoods other than the selected neighborhood and other than the neighborhoods in the selected set.