WO2016149473A1 - Systems and methods for forming a group based on proximity of devices - Google Patents

Abstract

Systems and methods for forming a group based on co-location with a proximity device is described. A plurality of user devices may detect a common beacon. A first user device (105) of the plurality of user devices (105,110,115) may submit a request to a server (125) to form a group associated with the beacon (120). The server (125) may possess information regarding which other user devices (110,115) also detect the beacon (120), and may notify the first user device (105) about those other user devices (110,115). The first user device (105) may invite, via the server (125), one or more of those other user devices (110,115) to join the group. Once the group is formed, participants of the group may communicate and/or share content with each other. The first user device (105) may manage the group.

Description

SYSTEMS AND METHODS FOR FORMING A GROUP BASED ON PROXIMITY OF

DEVICES

CROSS REFERENCE

[0001] This application claims the benefit of U.S. Provisional Application No.

62/135,064 filed on March 18, 2015, the contents of which are each hereby incorporated by reference herein in their entirety.

BACKGROUND

[0002] With the ever increasing popularity of personal computing/communication devices (e.g., wireless transmit/receive units (WTRUs) such as smart phones or tablets, laptops, and/or the like), it is highly likely that people within certain proximity of each other (e.g., at a conference or social gathering) may each be in possession of such a device. A number of these people may decide to form a group and use their respective user devices to communicate and/or share information with each other. Traditionally, to form such a group, potential participants would need to exchange their names, phone numbers, email addresses, and/or the like, so that each person may be identified and added to the group. Such a group forming process may be cumbersome and/or take too much time and/or resources. It may be desirable to take advantage of the fact that the potential participants (and their user devices) may be within close proximity of each other, and therefore a group may be formed, e.g., automatically, by utilizing certain characteristics of the user devices.

SUMMARY

|00Θ3] As described herein, a plurality of user devices may detect a common beacon and determine an identifier associated with the beacon. The user devices may report the detection of the beacon and the beacon's identifier to a server. A first user device of the plurality of user devices may submit a request to the server to form a group associated with the beacon. The server may notify the first user device about which other user devices detect the beacon. The first user device may invite, e.g., via the server, one or more of the other user devices to join the group. Once the group is formed, participants of the group may communicate and/or share content with each other. The first user device may act as a manager of the group. For example, the first user device may remove a participant from the group or may deactivate the group. The first user device may set polices for the group. For instance, the first user device may dictate that, upon joining the group, a participant user device may continue to participate in the group even if the participant user device moves outside the range of the beacon (e.g., the participant use device no longer detects the beacon and may access the group via a different connection). If no such policy is set, the participant user device may detach, e.g., automatically, from the group after losing contact with the beacon. A participant user device may request to be detached from the group (e.g., regardless of whether the user device detects the beacon).

BRIEF DESCRIPTION OF THE DRA WINGS

[0004] A more detailed understanding of the embodiments disclosed herein may be had from, the following description, given by way of example in conjunction with the accompanying drawings.

[0005] Figure 1 depicts an example block diagram of a system and/or devices that maybe used to form a group for sharing content and/or features as described herein.

[00Θ6] Figure 2A illustrates a first example interface associated with forming a group for sharing content and/or features as described herein.

[0007] Figure 2B illustrates a second example interface associated with forming a group for sharing content and/or features as described herein.

[0008] Figure 2C illustrates a third example interface associated with forming a group for sharing content and/or features as described herein.

[0009] Figure 2D illustrates a fourth example interface associated with forming a group for sharing content and/or features as described herein. [0010] Figure 2E illustrates a fifth example interface associated with forming a group for sharing content and/or features as described herein.

[0011] Figure 3 illustrates example message flow between different entities in forming a group for sharing content and/or feature as described herein.

[0012] Figure 4 illustrates an example system architecture that may be provided and/or used as described herein.

[0013] Figure 5 A depicts a diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0014] Figure 5B depicts a system diagram of an example wireless transmit/receive unit

(WT U) that may be used within the communications system illustrated in Figure 5A.

[0015] Figure 5C depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in Figure 5A.

[0016] Figure 5D depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in Figure 5A.

[0017] Figure 5E depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in Figure 5A.

DETAILED DESCRIPTION

[0018] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0019] Personal computing and/or communication devices such as WTRUs (e.g., smart phones, tablets, laptops, etc.) have become an integral part of people's everyday life. As an example, attendees at a social event, business location, or conference may each have at least one mobile device that may be used for communication and/or content sharing. An attendee may desire to form a group (e.g., an ad hoc group) that includes one or more people in the vicinity of the attendee (e.g., in a same dining room, conference hall, business location, etc.). As described in the examples herein, the group may be formed without requiring participants of the group to share email addresses, phone numbers, skype names, WhatsApp names, and/or the like. The group may be formed based on a radiating signal commonly detected by potential participant user devices (e.g., wireless transmit/receive units (WTRUs), laptops, etc.). The radiating signal may be transmitted, for example, by a Bluetooth beacon source (e.g., an iBeacon), a radio- frequency (RF) tag, a WLAN Access Point (AP), and/or the like. Such a radiating signal may be generally referred to herein as a "beacon" and a person skilled in the art will apprec ate that the term may encompass various types of signals that may be detected by a user device (e.g., a

WTRU such as a smartphone, or a tablet, a laptop, etc.).

10020] The detection of a common beacon (e.g., a beacon detectable by each potential participant user device) by potential participant user devices may indicate to the user devices that they may be at a same location (e.g., within a short distance of each other and/or of the beacon). For example, the beacon may be associated with a conference room (e.g., a WLAN router/AP associated with the conference room or hosting business) where the potential participating user devices are also located, the beacon may be radiating from one of the potential participant user devices (e.g., a Bluetooth signal transmitted from a smartphone), etc. The potential participant user devices may each detect the presence of the beacon. The potential participant user devices may be capable of connecting to and/or communicating with the source of the beacon). The potential participant user devices may determine an identifier associated with the beacon (e.g., the SS1D of a Bluetooth device or a Wireless LAN (WLAN), the RFID of a RF tag, etc.). An ad- hoc "location based" group may be conveniently formed among one or more of the participant user devices to exchange or share text, messages, video/audio content, features, and/or the like. One of the participant user devices may initiate the group (e.g., submit an initial request to form the group to the server). The initiating user device may act as a manager of the group, for example, by adding and/or removing participants, setting group policies, and/or deactivating the group. [0021] Figure 1 depicts an example diagram of a system 100. One or more devices may be used to form a group and/or share content as described herein. Three example user devices 105, 110, 1 15 are shown, which may be WTRUs such as smartphones or tablets, or other suitable type of user devices. Each of the user devices 1 5, 110, 1 15 may have a unique identifier associated with the user device (e.g., a UUID, another type of device ID, a screen name associated with an application installed on the user device, etc.). Each of the user devices 105, 110, 1 15 may be able to detect (e.g., connect to, communicate with, and/or sense) a beacon 120, for example via a communication circuit (e.g., a RF transceiver). For example, the beacon 120 may be a Bluetootli signal and the user devices 105, 110, 115 may each detect the beacon and/or be capable of sending/receiving transmissions, messages, and/or signals to/from the source of the beacon 120. The user devices 105, 1 10, 1 15 may determine an identifier associated with the beacon 120, for example, in response to connecting to, communicating with, or sensing the beacon 120. The identifier may comprise, for instance, a UUID, a nickname, a certain bit sequence that uniquely identifies the beacon, etc. The user devices 105, 1 10, 115 may receive other information via the beacon, including, for example, the type of the beacon signal and/or a measured signal strength that may indicate how far away the beacon source is. The user devices 105, 110, 1 15 may each be configured to communicate with a server 125 regarding the beacon(s) detected by the user device. For example, the user devices 105, 110, 115 may be configured to transmit periodic messages over a cellular network or a public network (e.g., the Internet) to the server 125. The messages may identify the respective user devices (e.g., via a device ID, a screen name, etc.) and/or a list of beacons detected by each user device (e.g., via beacon IDs).

[0022] A user of a device, e.g., user device 105 may desire to establish a group associated with the beacon 120. For example, the user may want to form an ad hoc group among user devices that also detect the beacon 120. It may be likely that the user devices are in the vicinity of the user device 105. The user may send a request, e.g., via user device 105, to a server 125 indicating the desire to form the group. The request may include, for example, one or more of the following: a beacon ID of the beacon 120, a unique identifier associated w ith the user device 105, a group name entered by the user, one or more settings or group policies for the group, etc.

[0023] The server 125 may comprise components or functionalities as disclosed herein, e.g., as described with reference to Figure 4. The server 125 may comprise a communication circuit (e.g., a network interface, and/or an RF transceiver, etc.) coupled to a processor and configured to transmit and receive signals to and from the user devices 105, 110, 115. For example, the server 125 may be located remotely from the user devices 105, 1 10, 115 and be configured to communicate with the user devices (e.g., receiving requests and/or status updates from the user devices, sending instructions to the user devices, etc.) via the Internet, a cellular network, etc. For example, the server 125 may reside on one of the user devices 105, 110, 115, and be configured to communicate with client applications installed on the respective user devices.

[0024] Server 125 may be configured to carry out one or more of the following. For example, a computer-readable medium of the server 125 may comprise instructions that, when executed by the processor of the server 125, carry out one or more of the following actions. The server 125 may receive, e.g., via the communication circuit, a request from the user device 105 to form a group associated with the beacon 120. As described herein, the request may include a beacon identifier and/or an identifier associated with the user device 105. The server 125 may be configured to create a group record in response to receiving the group forming request from the user device 105. The group record may include a group ID and/or settings/group policies specified in the group forming request, etc. The server 125 may be configured to save the group record in a storage space (e.g., in a database). The storage space may be part of the computer- readable medium of the server 125 or may be part of a separate storage device (e.g., a database server). The server 125 may be configured to assign a role to the user device 105. For example, the server 125 may assign a "group manager" role to the user device 105 and may associate certain privileges with the role. The server 125 may be configured to determine a list of potential participants to the group. The determination may be made, for example, based on other user devices that detect the beacon (e.g., as reported to the server). As described herein, the server 125 may obtain such information by receiving reports from the other user devices (e.g., the user devices 1 10, 115) regarding beacons detected by the other user devices. The server 125 may be configured to maintain a mapping of beacons to user devices in a storage space (e.g., in a database server).

[0025] The server 125 may provide the list of potential participants (e.g., the user devices

110, 115 and/or user names associated with the user devices 110, 115) to the user device 105 (e.g., via a message). The message may identify the potential participants by their respective identifiers (e.g., device IDs and/or user names). The message may include the group ID assigned to the group and/or the group name specified by the group manager. In an example, if the number of potential participants exceeds a certain threshold, the server 125 may be configured to provide only a subset of the potential participants to the user device 105. For example, the group manager may have set a limit to the number of participants in the original group forming request, or the server 125 may be configured to provide only a limited number of potential participants initially and to prompt the group manager to request more if desired.

[0026] The user device 105 may comprise a display (e.g., a screen) and may be configured to display the list of potential participants on the display. A user of the user device 105 may select one or more of the potential participants (e.g., the use devices 1 10, 115 and/or users names associated with the user devices 110, 115) for inclusion in the group. The selection may be received by the user device 105 and communicated to the server 120 via message(s). The messages may include the identifiers associated with the selected participants and/or the group ID. The messages may include settings/policies related to the entire group and/or to a subset of the selected participants. The settings/policies may have been set by the user of the user device 105, e.g., during the selection process. For example, the user may have specified that, upon joining the group, certain selected participants are allowed to continue to participate in the group regardless of whether they still detect the beacon 120.

[0027] The server 125 may receive the messages from the use device 105. The server

125 may save the group settings/policies included in the messages, e.g., by updating an existing group record or adding a new group record. Based on the list of selected participants identified in the messages, the server 125 may notify each of the selected participants (e.g., the user devices 110, 1 15) about the group that the user devices may be part of. In an embodiment, the server 125 may be configured to send a message (e.g., an invitation) to each of the selected participant user device regarding the group being formed (e.g., to invite the user device to join an ad hoc group). The message may include, for example, the beacon ID associated with the group, the group ID/name, and/or information about the group manager (e.g., the user device 105). Potential participant user devices (e.g., user devices that detect one or more beacons) may be configured to periodically poll the server 125 for available groups that the user devices have been invited to join. The potential participant user devices may be configured to display the groups available to them such that a user may select the group(s) (e.g., provide an indication of acceptance for inclusion in the group) he or she wants to participate in. The user may also deny an invitation to join a certain group.

[0028] The corresponding participant user device may send a message to the server 125 to confirm its participation in the group, e.g., once a user selects a group to join. The message may include one or more of the following: an indication confirming group participation, the group ID, the identifier associated with the participant user device, etc. The participant user device may be configured to verify, at the time of confirming the group participation, that the beacon associated with the group is still detectable by the participant user device. If the beacon is not still detectable by the participant user device, the participant user device may be disallowed to send the confirmation message to the server 125 and/or may not be allowed to participate in the group.

[0029] The server 125 may receive the confirmation message sent by a participant (e.g., from a participant user device). The server 125 may be configured to add the participant user device to the group indicated in the confirmation message. For example, the server 125 may be configured to update the corresponding group record to indicate the addition. Further, the server 125 may be configured to assign a role to the newly added participant (e.g., a "participant" role) and to associate certain group privileges with the role. Once the group is formed, the server 12,5 may distribute digital objects (e.g., messages, image files, video/audio files, etc.) submitted by another participant in the group. For example, the participant submitting the digital objects may- specify whether to be distribute the digital objects to the participants or a selected number of the participants. The distribution may be performed using a notification technique such as application push notifications that may be provided by a device operating system vendor (e.g., Apple's Notification Center or Google's Cloud Messaging service).

[0030] Figures 2A-2E illustrate example user interfaces of an application (e.g., mobile app) that may be used to realize functions described herein. The example application may be a group chatting mobile app, a group messaging client, or other software applications that may be installed and running on a participating user device. For example, as shown in Figure 2A, a user,

John, may have a user device (e.g., "John's Phone") on which a group mobile app may have been installed and run to facilitate the forming of a group as described herein. John may open the group mobile app on his phone, e.g., user device and see a list of beacons displayed on a user interface of the app. The list of beacons may be those detectable by John's Phone and identifiable by respective unique identifiers. The list of beacons may include a beacon transmitted by John's Phone. The unique identifier may be, for example, a UUID (e.g.,

"f7826da6-4fa2-4e98-8024-bc5b71e0893e") or a name unique within the range of the beacon (e.g., "Art Museum," "Conference Hall," or "John's Phone"). John may select one of the beacons (e.g., "Conference Hall," as shown in Figure 2A) to form a group. Although not shown, in some examples, John may enter a desired name for the group: if no name is entered, a default name (e.g., a name linked to the beacon such as "Conference Hall Group") may be assigned to the group. John's selection of the "Conference Hail" beacon may be received by his phone, which may in response send a group forming request to a server (e.g., the server 125). The request may include one or more of the following: an identifier of the beacon, an ID associated with John's Phone, or the group name, as described herein . The server may receive the request and create a group record accordingly. The group may be assigned a group ID and may have, for example, John or John's Phone as a designated group manager.

[0031] As described herein, the server may have received reports (e.g., via messages) from one or more other user devices (e.g., Mike's Phone, Bill's Tablet, and Katie's Phone, as shown in Figure 2B) that those user devices also detect the "Conference Hall" beacon. The server may identify (e.g., in response to receiving the group forming request from John's Phone) those other user devices and/or users associated with the user devices to John's Phone. The identification may be communicated via messages, which may include the identifier of the respective user devices (e.g., a device ID and/or user name), the beacon ID, and/or die group ID. As described herein, if the number of user devices detecting the "Conference Hall" beacon is large, the server may be configured to provide a subset of user devices to John's Phone. For example, John may have set a limit to the number of participants in his original group forming request, or the server may be configured to provide only a limited number of potential participants initially and to prompt John to request more if desired. Once the list of potential participants (e.g., Mike's Phone, Bill's Tablet, and Katie's Phone) is received by John's Phone, the potential participants may be displayed on John's Phone (e.g., via a user interface, as shown in Figure 2B). John may select from the list all or a subset of the potential participants for inclusion in the group. The selections may be sent from his John's Phone to the server.

[0032] The server may receive John's selection of one or more participants, and transmit a message (e.g., an invitation) to each of the selected participant user devices (e.g., to invite the user and/or user device to join an ad hoc group). The message may include the beacon ID associated with the group, the group ID, and/or information regarding the group manager (e.g., John or John's Phone). The message may be received by the selected user devices (e.g., Mike's Phone and Katie's Phone) and displayed thereon. For example, as shown in Figure 2C, a list of available groups that a selected user device is, or may become, part of may be displayed via a user interface, e.g., of the group chatting mobile app installed and running on the user device. As shown, the user device may have already been participating in two groups (e.g., "Super Team" and "Car Guys," which may be associated with other beacons), and may join a third group (e.g., the "Conference Hall" group initiated by John, as described herein). Using the example interface shown in Figure 2C, a user of the user device may choose to leave an existing group (e.g., "Super Team" or "Car Guys"), to join a new group (e.g., "Conference Hall"), or to deny an invitation to join a group (functionality not shown in the example figure). For example, the user may confirm participation in the new group by selecting the "+" icon displayed next to the new group. The user's selection may be received by the user device, which may in turn send a message to the server to confirm the user device's participation in the group. As described herein, the message may include an indication confirming group participation, the group ID, and/or an identifier associated with the user device. Also as described herein, the user device may be configured to verify, at the time of confirming the group participation, that the beacon associated with the group is still detectable by the user device. Otherwise, the user device may not be allowed to join the group.

[0033] The server may receive the confirmation sent by one or more of the selected user devices, and be configured to add those user devices to the group. Each user or user device may be assigned a role (e.g., a "participant" role) within the group. The role may be associated with privileges delegated to the user or user device. The server may notify John's Phone (e.g., the group manager) about the newly joined group participants. The notification may be sent via messages and may include each participant user devices' identifier, the beacon ID, and/or the group ID. After John's Phone receives the notification, the list of confirmed participants may be displayed via a user interface of the mobile app (e.g., as shown in Figure 2D). John may remove one or more of the group participants (e.g., by selecting the "-" icon displayed next to the group participant), John may deactivate the entire group (e.g., via a "Deactivate Group" button). The action taken by John may be communicated to the server, which may execute the action on the server side. |0034] As described herein, the server may receive a request from a group manager user device to remove a participant and/or to deactivate the group. If, for example, the request is to remove a participant, the server may detach the participant from, the group (e.g., by

deleting/updating relevant database records), upon which the removed participant may no longer communicate with the remaining participants in the group setting. As another example, if the request is to deactivate the entire group, the server may remove the group record (e.g., by deleting relevant database records), upon which the group participants may no longer communicate with each other as a group. Upon taking an action (e.g., removing a participant or deactivating the group), the server may be configured to notify the group participant user device(s) about the action. In response to receiving the notification, the group participant user devices may update their respective displays to reflect the action taken by the server,

[0035] A participant may be automatically removed from a group in certain situations.

For example, after joining the group, a participant user device may move outside the range of the beacon associated with the group (e.g., the beacon is no longer detectable by the user device). The participant user device may be configured to detect such a situation (e.g., by periodically checking whether the beacon is still detectable) and to automatically send a request to the server to be removed from the group. Such automatic removal may be overridden, however, by a predefined group setting/policy. For example, as described herein, the group manager may specify (e.g., during the group forming process) that participants (e.g., selected participants) are allowed to continue to participate in the group regardless of whether the participants still detect the beacon associated with the group.

[0036] Once a group is formed, the server may create a workspace for the group. The workspace may be used to store digital objects (e.g., messages, images, video/audio files, etc.) that may be shared in the group. A digital object may be submitted by a group participant, e.g., via an example user interface shown in Figure 2E. The object may be shared with other participants. The participant submitting the digital objects may specify to which other participants (e.g., all or a selected number of the participants) the digital objects may be distributed, etc. The digital objects may be sent to the server. Tire server may save the digital objects in the group workspace and/or to distribute them to one or more participants of the group as described herein. |0037] Figure 3 shows example message flow between various entities during the forming of a group as described herein. As shown, a beacon and its associated identifier may be transmitted from the source of the beacon to a group manager device (e.g., user device 105 or John's Phone, which may become the group manager) and a participant device (e.g., user devices 110, 115, which may participate in the group). The group manager device may send a group forming request and beacon ID to a server (e.g., the server 125), w h re the beacon ID may be part of the group forming request. The server may respond to the request by providing a list of devices that detect the beacon. The group manager may select desired devices from the list for inclusion in the group and send the list of selected devices to the server. The server may notify the selected devices about the available groups. The selected devices may choose to join the group (e.g., by sending an indication to join and/or the corresponding group id). Once the group is formed, messages and/or other digital objects may be submitted to the server by a group participant (including the group manager), and the server may distribute the digital objects to one or more of the group participants (including the group manager). A group participant may choose to leave the group. The group manager may remove a group participant from the group. If a group participant no longer detects the beacon, the group participant may automatically detach from the group, e.g., if a group setting/policy requires the group participant to be in continuous contact with the beacon,

[0038] Figure 4 depicts a block diagram of a computing system 400 that may be included in a user device and/or a server as described herein. The computing system 400 may be capable of executing a variety of computing applications 410. The computing applications 410 may be stored in a storage component 415 (and/or RAM 425 or ROM 430 described herein). The computing application 410 may be an application, an applet, a program, a mobile application, and oilier instruction set operative on the computing system 400 to perform at least one function, operation, and/or procedure as described herein. According to an example, the computing applications 410 may include the methods and/or applications described herein. The computing system 400 may be controlled primarily by computer readable instructions thai may be in the form of software. The computer readable instructions may include instructions for the device for storing and accessing the computer readable instructions themselves. Such software may be executed within a processor or a group of processors 440 such as a central processing unit (CPU) and/or other processors such as a coprocessor to cause the computing system 400 to perform the

- Γ? - processes or functions associated therewith. The processor 440 may be implemented by microelectronic chips CPUs called microprocessors.

[0039] In operation, the processor 440 may fetch, decode, and/or execute instructions and may transfer information to and from other resources via an interface 445 such as a main data transfer path or a system bus. Such an interface or system bus may connect the components in the computing system 400 and may define the medium for data exchange. The computing system 400 may further include memory devices coupled to the interface 445. According to an example embodiment, the memory devices may include a random access memory (RAM) 425 and read only memory- (ROM) 430. The RAM 425 and RDM 430 may include circuitry that allows information to be stored and retrieved. In one embodiment, the ROM 430 may include stored data that cannot be modified. Additionally, data stored in the RAM 425 typically may be read or changed by the processor 440 or other hardware devices. Access to the RAM 425 and/or ROM 430 may be controlled by a memory controller 450. The memory controller 450 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed.

[0040] In addition, the computing system 400 may include a peripheral

interface/controller 455 that may be responsible for communicating instructions from, the processor 440 to peripherals such as a printer, a keypad or keyboard, a mouse, and a storage component. The computing system 400 may further include a display controller 465. The display/display controller 465 may be used to display visual output generated by the device. Such visual output may include text, graphics, animated graphics, video, or the like. The display controller 465 associated with the display (e.g., shown in combination as 465 but may be separate components) may include electronic components that generate a video signal that may be sent to the display. Further, the computing system 400 may include a network interface or controller 470 (e.g., a network adapter, a transceiver, etc.) thai may be used to connect the computing system to an external communication network and/or other devices (not shown).

[0041] Figure 5A depicts an example wireless communication network 500 in which one or more disclosed embodiments may be implemented or used. The communications system 500 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 500 may enable multiple wireless users to access such content tlirough the sharing of system resources, including wireless bandwidth. For example, the communications systems 500 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- earner FDMA (SC-FDMA), and the like.

[0042] As shown in Figure 5A, the communications system 500 may include wireless transmit/receive units (WTRUs) 502a, 502b, 502c, and/or 502d (which generally or collectively may be referred to as WTRU 502), a radio access network (RAN) 503/504/505, a core network 506/507/509, a public switched telephone network (PSTN) 508, the Internet 510, and other networks 512, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 502a, 502b, 502c, and/or 502d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 502a, 502b, 502c, and/or 502d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0043] The communications systems 500 may also include a base station 515 A and a base station 515B. Each of the base stations 515A, 515B may be any type of device configured to wireiesslv interface with at least one of the WTRUs 502a, 502b, 502c, and/or 502d to facilitate access to one or more communication networks, such as the core network 506/507/509, the Internet 510, and/or the networks 512. By way of example, the base stations 515A and/or 515B may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 515A, 515B are each depicted as a single element, it will be appreciated that the base stations 515 A, 515 B may include any number of interconnected base stations and/or network elements .

[0044] The base station 515A may be part of the RAN 503/504/505, which may also include other base stations and/or network elements (not shown), such as a base station controller

(BSC), a radio network controller (RNC), relay nodes, etc. The base station 515A and/or the base station 515B may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 515A may be divided into three sectors. Urns, in one embodiment, the base station 515A may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 515A may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0045] The base stations 515A and/or 515B may communicate with one or more of the

WTRUs 502a, 502b, 502c, and/or 502d over an air interface 515/516/517, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 515/5 6/517 may be established using any suitable radio access technology (RAT).

[0046] More specifically, as noted above, the communications system 500 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 515A in the RAN 503/504/505 and the WTRUs 502a, 502b, and/or 502c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 515/516/517 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSP A (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0047] In another embodiment the base station 515 A and the WTRUs 502a, 502b, and/or

502c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 515/516/517 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[0048] in other embodiments, the base station 515A and the WTRUs 502a, 502b, and/or

502c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like. |0049] The base station 515B in Figure 5 A may be a wireless router. Home Node B,

Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 515B and the WTRUs 502c, 502d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 515B and the WTRUs 502c, 502d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 515B and the WTRUs 502c, 502d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc) to establish a picocell or femtocell. As shown in Figure 5 A, the base station 515B may have a direct connection to the Internet 510. Thus, the base station 5 15B may not be required to access the Internet 510 via the core network 506/507/509.

[0050] The RAN 503/504/505 may be in communication with the core network

506/507/509, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 502a, 502b, 502c, and/or 502d. For example, the core network 506/507/509 may provide call control, billing services, mobile location-based sen/ices, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown i Figure 5 A, it will be appreciated that the RAN 503/504/505 and/or the core network 506/507/509 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 503/504/505 or a different RAT. For example, in addition to being connected to the RAN 503/504/505, which may be utilizing an E-UTRA radio technology, the core network 506/507/509 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0051] The core network 506/507/509 may also serve as a gateway for the WTRUs 502a,

502b, 502c, and/or 502d to access the PSTN 508, the Internet 510, and/or other networks 512. The PSTN 508 may include circuit-switched telephone networks that provide plain old telephone sendee (POTS). The Internet 510 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 512 may include wired or wireless communications networks owned and/or operated by other sen/ice providers. For example, the networks 512 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 503/504/505 or a different RAT.

[0052] Some or all of the WTRUs 502a, 502b, 502c, and/or 502d in the communications system 500 may include multi-mode capabilities, i.e., the WTRUs 502a, 502b, 502c, and/or 502d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 502c shown in Figure 5A may be configured to communicate with the base station 5 5A, which may employ a cellular-based radio technology, and with the base station 515B, which may employ an IEEE 802 radio technology.

[0053] Figure 5B depicts a system diagram of one or more components or additional components that may be included in a device such as a WTRU 502, an authentication server, a server (e.g., such the server 125), and /or the like as described herein. As shown in Figure 5B, the components may include a processor 518, a transceiver 520, a transmit/receive element 522, a speaker/microphone 524, a keypad 526, a display/touchpad 528, non-removable memory 530, removable memory 532, a power source 534, a global positioning system (GPS) chipset 536, and other peripherals 538. It will be appreciated that the device may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 515A and 515B, and/or the nodes that base stations 515A and 515B may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in Figure 5B and described herein.

[0054] The processor 518 may be a general purpose processor, a special puipose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller. Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 518 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the device to operate in a wireless environment. The processor 518 may be coupled to the transceiver 520, which may be coupled to the transmit/receive element 522. While Figure 5B depicts the processor 518 and the transceiver 520 as separate components, it may be appreciated that the processor 518 and the transceiver 520 may be integrated together in an electronic package or chip.

[0055] The transmit/receive element 522 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 515A) over the air interface

515/516/517. For example, in one embodiment, the transmit/receive element 522 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 522 may be an emitter/detector configured to transmit and/or receive 1R, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 522 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 522 may be configured to transmit and/or receive any combination of wireless signals.

|0056] In addition, although the transmit/receive element 522 is depicted in Figure 5B as a single element, the device may include any number of transmit/receive elements 522. More specifically, the device may employ MIMO technology. Thus, in one embodiment, the device may include two or more transmit/receive elements 522 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 515/516/517.

[0057] The transceiver 520 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 522 and to demodulate the signals that are received by the transmit/receive element 522. As noted above, the device may have multi-mode capabilities. Thus, the transceiver 520 may include multiple transceivers for enabling the device to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0058] The processor 518 of the device may be coupled to, and may receive user input data from, the speaker/microphone 524, the keypad 526, and/or the display/touchpad 528 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 518 may also output user data to the speaker/microphone 524, the keypad 526, and/or the display/touchpad 528. In addition, the processor 518 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 530 and/or the removable memory 532. The non-removable memory 530 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 532 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 518 may access information from, and store data in, memory that is not physically located on the device, such as on a server or a home computer (not shown).

[0059] The processor 518 may receive power from the power source 534, and may be configured to distribute and/or control the power to the other components in the device. The power source 534 may be any suitable device for powering the device. For example, the power source 534 may include one or more dry cell battenes (e.g., nickel-cadmium ( iCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium -ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0060] The processor 518 may also be coupled to the GPS chipset 536, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the device. In addition to, or in lieu of, the information from the GPS chipset 536, the device may receive location information over the air interface 515/516/517 from a base station (e.g., base stations 515A, 515B) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the device may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0061] The processor 518 may further be coupled to other peripherals 538, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 538 may- include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0062] Figure 5C depicts a system diagram of the RAN 503 and the core network 506 according to an embodiment. As noted above, the RAN 503 may employ a UTRA radio technology to communicate with the WTRUs 502a, 502b, and/or 502c over the air interface 515. The RAN 503 may also be in communication with the core network 506. As shown in Figure 5C, the RAN 503 may include Node-Bs 540a, 540b, and/or 540c, which may each include one or more transceivers for communicating with the WTRUs 502a, 502b, and/or 502c over the air interface 515. The Node-Bs 540a, 540b, and/or 540c may each be associated with a particular cell (not shown) within the RAN 503. The RAN 503 may also include RNCs 542a and/or 542b. It will be appreciated that the RAN 503 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0063] As shown in Figure 5C, the Node-Bs 540a and/or 540b may be in communication with the RNC 542a. Additionally, the Node-B 540c may be in communication with the RNC542b. The Node-Bs 540a, 540b, and/or 540c may communicate with the respective RNCs 542a, 542b via an lub interface. The RNCs 542a, 542b may be in communication with one another via an lur interface. Each of the RNCs 542a, 542b may be configured to control the respective Node-Bs 540a, 540b, and/or 540c to which it is connected. In addition, each of the RNCs 542a, 542b may be configured to cany out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0064] The core network 506 shown in Figure 5C may include a media gateway (MGW)

544, a mobile switching center (MSC) 546, a serving GPRS support node (SGSN) 548, and/or a gateway GPRS support node (GGSN) 550. While each of the foregoing elements are depicted as part of the core network 506, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0065] The RNC 542a in the RAN 503 may be connected to the MSC 546 in the core network 506 via an IuCS interface. The MSC 546 may be connected to the MGW⁷ 544. The MSC 546 and the MGW 544 may provide the WTRUs 502a, 502b, and/or 502c with access to circuit-switched networks, such as the PSTN 508, to facilitate communications between the WTRUs 502a, 502b, and/or 502c and traditional land-line communications devices.

[0066] The RNC 542a in the RAN 503 may also be connected to the SGSN 548 in the core network 506 via an IuPS interface. Hie SGSN 548 may be connected to the GGSN 550. The SGSN 548 and the GGSN 550 may provide the WTRUs 502a, 502b, and/or 502c with access to packet-switched networks, such as the Internet 510, to facilitate communications between and the WTRUs 502a, 502b, and/or 502c and IP-enabled devices. |0067] As noted above, the core network 506 may also be connected to the networks 512, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0068] Figure 5D depicts a system diagram of the RAN 504 and the core network 507 according to an embodiment. As noted above, the RAN 504 may employ an E-UTRA radio technology to communicate with the WTRUs 502a, 502b, and/or 502c over the air interface 516. The RAN 504 may also be in communication with the core network 507.

[0069] Hie RAN 504 may include eNode-Bs 560a, 560b, and/or 560c, though it will be appreciated that the RAN 504 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 560a, 560b, and/or 560c may each include one or more transceivers for communicating with the WTRUs 502a, 502b, and/or 502c over the air interface 516. In one embodiment, the eNode-Bs 560a, 560b, and/or 560c may implement M1MO technology. Thus, the eNode-B 560a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 502a.

[0070] Each of the eNode-Bs 560a, 560b, and/or 560c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in Figure 5D, the eNode-Bs 560a, 560b, and/or 560c may communicate with one another over an X2 interface.

[0071 ] The core network 507 shown in Figure 5D may include a mobility management gateway (MME) 562, a serving gateway 564, and a packet data network (PDN) gateway 566. While each of the foregoing elements are depicted as part of the core network 507, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0072] The MME 562 may be connected to each of the eNode-Bs 560a, 560b, and/or

560c in the RA 504 via an SI interface and may serve as a controi node. For example, the MME 562 may be responsible for authenticating users of the WTRUs 502a, 502b, and/or 5 2c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 502a, 502b, and/or 502c, and the like. The MME 562 may also provide a control plane function for switching between the RAN 504 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0073] The serving gateway 564 may be connected to each of the eNode-Bs 560a, 560b, and/or 560c in the RAN 504 via the SI interface. The serving gateway 564 may generally route and forward user data packets to/from the WTRUs 502a, 502b, and/or 502c. The serving gateway 564 may also perform oilier functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 502a, 502b, and/or 502c, managing and storing contexts of the WTRUs 502a, 502b, and/or 502c, and the like.

[0074] The serving gateway 564 may also be connected to the PDN gateway 566, which may provide the WTRUs 502a, 502b, and/or 502c with access to packet-switched networks, such as the Internet 510, to facilitate communications between the WTRUs 502a, 502b, and/or 502c and IP -enabled devices.

[0075] The core network 507 may facilitate communications with other networks. For example, the core network 507 may provide the WTRUs 502a, 502b, and/or 502c with access to circuit-switched networks, such as the PSTN 508, to facilitate communications between the WTRUs 502a, 502b, and/or 502c and traditional land-line communications devices. For example, the core network 507 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core netw ork 507 and the PSTN 508. In addition, the core network 507 may provide the WTRUs 502a, 502b, and/or 502c with access to the networks 512, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0076] Figure 5E depicts a system diagram of the RAN 505 and the core network 509 according to an embodiment. The RAN 505 may be an access service network (ASM that employs IEEE 802.16 radio technology to communicate with the WTRUs 502a, 502b, and/or 502c over the air interface 517. As will be further discussed below, the communication links between the different functional entities of the WTRUs 502a, 502b, and/or 502c, the RAN 505, and the core network 509 may be defined as reference points.

[0077] As shown in Figure 5E, the RAN 505 may include base stations 580a, 580b, and/or 580c, and an ASN gateway 582, though it will be appreciated that the RAN 505 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 580a, 580b, and/or 580c may each be associated with a particular cell (not shown) in the RAN 505 and may each include one or more transceivers for

communicating with the WTRUs 502a, 502b, and/or 502c over the air interface 517. In one embodiment, the base stations 580a, 580b, and/or 580c may implement MIMO technology. Thus, the base station 580a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 502a. The base stations 580a, 580b, and/or 580c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 582 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 509, and the like.

|0078] The air interface 517 between the WTRUs 502a, 502b, and or 502c and the RAN

505 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 502a, 502b, and/or 502c may establish a logical interface (not shown) with the core network 509. The logical interface between the WTRUs 502a, 502b, and/or 502c and the core network 509 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0079] The communication link between each of the base stations 580a, 580b, and/or

580c may be defined as an R8 reference point that includes protocols for facilitating WTR handovers and the transfer of data between base stations. The communication link between the base stations 580a, 580b, and/or 580c and the ASN gateway 582 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility

management based on mobility events associated with each of the WTRUs 502a, 502b, and/or 502c.

[0080] As shown in Figure 5E, the RAN 505 may be connected to the core network 509.

The communication link between the RAN 505 and the core network 5 9 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 509 may include a mobile IP home agent (MIP-HA) 584, an authentication, authorization, accounting (AAA) server 586, and a gateway 588. While each of the foregoing elements are depicted as part of the core network 509, it will he appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0081] The MIP-HA may be responsible for IP address management, and may enable the

WTRUs 502a, 502b, and/or 502c to roam between different ASNs and/or different core networks. The MIP-HA 584 may provide the WTRUs 502a, 502b, and/or 502c with access to packet-switched networks, such as the Internet 510, to facilitate communications between the WTRUs 502a, 502b, and/or 502c and IP -enabled devices. The AAA server 586 may be responsible for user authentication and for supporting user services. The gateway 588 may facilitate interworking with other networks. For example, the gateway 588 may provide the WTRUs 502a, 502b, and/or 502c with access to circuit-switched networks, such as the PST 508, to facilitate communications between the WTRUs 502a, 502b, and/or 502c and traditional land-line communications devices. In addition, the gateway 588 may provide the WTRUs 502a, 502b, and/or 502c with access to the networks 512, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0082] Although not shown in Figure 5E, it should, may, and/or will be appreciated that the RAN 505 may be connected to other ASNs and the core network 509 may be connected to other core networks. The communication link between the RAN 505 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 502a, 502b, and/or 502c between the RAN 505 and the other ASNs. The communication link between the core network 509 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0083] The examples described herein may be implemented as a group messaging application for a mobile device and/or a back end service or server (e.g., the server 125). The examples/service may be used to automatically create a group among users who may be at the same location (e.g., in communication with or connected to the same beacon). For example, a group of hobbyists that may gather to the same place may create a discussion group that may be utilized for communication between the meetings. As another example, at a meeting of resellers, meeting participants may be automatically connected to a discussion group using the application/server described herein. |0084] Although features and elements are described above in particular combinations, one of ordinar - skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

A method for forming a group, the method comprising:

receiving, from each of a plurality of user devices, an identifier associated with the user device and an identifier associated with a beacon, wherein the plurality of user devices comprises a first user device:

receiving, from the first user device, a request to form a group associated with the beacon, the request comprising the identifier associated with the beacon;

sending a message to the first user de vice, the message comprising information associated with one or more other user devices associated with the beacon;

receiving, from the first user device, a request to add a list of one or more participants to the group, the list indicative of all or a subset of the one or more other user devices associated with the beacon;

sending, to each participant in the list, an invitation to join the group, the invitation comprising an identifier associated with the group;

receiving, from each participant in the list, a confirmation to join the group; and adding the list of one or more participants to the group.

The method of claim 1, further comprising:

receiving a request to remove a participant from the group; and

detaching the participant from the group.

The metliod of claim 2, wherein the request to remove the participant is submitted by the first user device.

The method of claim 2, wherein the request to remove the participant is submitted by the participant.

The method of claim 1, further comprising receiving, from the first user device, a group policy regarding whether a participant is to be removed from the group if the participant no longer detects the beacon.

6. The method of claim 5, further comprising:

determining that a participant of the group no longer detects the beacon; and detaching the participant from the group based on the group policy.

7. The method of claim 1, wherein the information associated with the one or more other user devices comprises a respective identity indicator for each respective user device.

8. The method of claim 7, wherein the respective identity indicator is a user name

associated with the respective user device.

The method of claim 1, further comprising:

receiving a digital object to be shared in the group; and

distributing the digital object in the group.

A server, comprising:

a transceiver configured to:

send and receive messages; and

a processor configured to:

receive, via the transceiver, a message from each of a plurality of user devices, the message comprising an identifier associated with the respective user devices and an identifier associated with a beacon, wherein the beacon is detectable by each of the plurality of user devices, and the plurality of user devices comprises a first user device;

receive, via the transceiver, a request from, the first user device to form a group associated with the beacon, the request comprising the identifier associated with the beacon;

send, via the transceiver, a message to the first user device, the message comprising information associated with one or more other user devices by which the beacon is detectable;

receive, via the transceiver, a request from the first user device to add a list of participants to the group, the list of participants indicative of all or a subset of the one or more other user devices; send, via the transceiver, an invitation to each of the list of participants to join the group:

receive, via the transceiver, a confirm ation from, each of the list of participants to join the group; and

add the list of participants to the group.

11. The server of claim 10, wherein the processor is further configured to:

receive a request to remove a participant from the group; and

detach the participant from the group.

12. The server of claim 1 , wherein the request to remove the participant is submitted by the first user device.

13. The server of claim 11, wherein the request to remove the participant is submitted by the participant.

14. The server of claim 10, wherein the processor is further configured to receive, via the transceiver, a group policy from the first user device regarding whether a participant is to be removed from the group if the participant no longer detects the beacon.

15. The server of claim 14, wherein the processor is further configured to:

determine that a participant of the group no longer detects the beacon; and detach the participant from the group based on the group policy.

16. The server of claim 10, wherein the information associated with the one or more other user devices comprises a respective identity indicator for each respective user device.

17. The server of claim 16, wherein the respective identity indicator is a user name associated with the respective user device.

18. The server of claim 10, wherein the processor is further configured to:

receive, via the transceiver, a digital object to be shared in the group; and distribute, via the transceiver, the digital object in the group.

19. A user device, comprising:

a display;

a processor configured to:

determine an identifier associated with a beacon detected by the user device;

send a first request to a server to form a group associated with the beacon, wherein the first request comprises the identifier associated with the beacon;

receive a message from the server, wherein the message comprises information associated with one or more other user devices associated with the beacon;

display the information associated with the one or more other user devices on the display of the user device; receive, from a user of the user device, a selection of participants for inclusion in the group; and

send a second request to the server to include the participants in the group.

20. The user device of claim 19, wherein the information associated with the one or more other user de vices comprises a respective user name associated with each respective user device.