THREADED CONVERSATION CONTENT MANAGEMENT

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of U.S. Provisional Patent Application No. 62/024,294, filed July 14, 2014 and entitled "SYSTEM, DEVICE, AND METHOD FOR SHARING CONTENT AND INFORMATION VIA AN ON-DEMAND MESSAGING SESSION;" and U.S. Provisional Patent Application No. 62/121,314, filed February 26, 2015 entitled "THREADED CONVERSATION CONTENT MANAGEMENT," each of which are hereby expressly incorporated by reference in their entirety. Furthermore, any and all priority claims identified in the Application Data Sheet, or any correction thereto, are hereby incorporated by reference under 37 C.F.R. § 1.57.

[0002] The present application relates generally to creating, maintaining, and managing dynamic directory and communication between a plurality of wireless systems.

SUMMARY

[0003] In one innovative aspect, there is a computer-implemented method of generating a dynamic communication. The method includes, under control of one or more computing devices configured with specific computer-executable instructions for, receiving one or more search strings, searching one or more descriptors associated with one or more contacts of a user account for the one or more search strings. The method also includes sending a search result having one or more contacts associated with the one or more descriptors. The method further includes selecting one or more contacts associated with the one or more descriptors. The method further includes sending a request to create a communication thread between the one or more contacts, the communication thread including a collection of content elements identified as being included in the communication thread prior to receipt of the one or more search strings. The method also includes generating the communication thread. The method may also include a search string that is a public search string based on a public account descriptor for a user account. The public search string may be public including a search for one or more public account descriptors. The public account descriptor may be viewable by a user who is not associated with the user account. The method may also include a search string that is a private search string based on a private account descriptor for a user account. The private search may include a search for one or more private account descriptors. The method may also include a private account descriptor that is viewable only by a user of the user account. The method may also include receiving a request to restrict the communication thread between a multiple users, and restricting the communication thread based on the request to restrict. The request to restrict may include at least one of: limiting an addition of users to the communication thread, restricting a view of recipient list of the communication thread, and restricting a reply to the communication thread. The method may further include receiving a request to create a public communication descriptor for the communication thread based on a string input, creating the public communication descriptor based on the string input, and associating the public communication descriptor to the communication thread. The method may further include receiving a request to perform transaction between multiple users and performing the transaction between multiple users. The method may further include receiving a request to pause the communication thread and pausing the communication thread. The method may further include receiving a request to delete the communication thread and deleting the communication thread. The method may further include receiving a request to muting the communication thread, and muting the communication thread.

[0004] In another innovative aspect, there is a method of bidirectionally guided communication according to any of the embodiments disclosed herein.

[0005] In another innovative aspect, there is a computer readable medium having stored thereon instructions which when executed perform any of the methods disclosed herein.

[0006] In another innovative aspect, there is an apparatus comprising a processor, wherein the processor is configured to perform any of the methods disclosed herein.

[0007] In another innovative aspect, there is a device for generating a dynamic communication. The device includes computer-readable memory storing executable instructions. The device also includes one or more physical computer processors in communication with the computer-readable memory. The one or more physical computer processors are programed by the executable instruction. The computer processors are configured to receive one or more search strings. The computer processors are also configured to search one or more descriptors associated with one or more contacts of a user account for the one or more search strings. The computer processors are further configured to send a search result having one or more contacts associated with the one or more descriptors. The computer processors are also configured to select one or more contacts associated with the one or more descriptors. The computer processors are also configured to send a request to create a communication thread between the one or more contacts, the communication thread including a collection of content elements identified as being included in the communication thread prior to receipt of the one or more search strings. The computer processors are also configured to generate the communication thread.

[0008] In another innovative aspect, there is a communication device. The communication device includes a hardware implemented access controller. The hardware implemented access controller is configured to receive credentials and provide access to a user account based on the received credentials. The communication device also includes a hardware implemented contact manager, having access to the user account. The hardware implemented contact manager is configured to receive contact information for a contact, the contact information including a contact identifier, a public descriptor, and a private descriptor, wherein the public descriptor is received from a central contact directory and the private descriptor is provided by the user account. The private descriptor is searchable only during searches submitted for the user account. The hardware implemented contact manager is also configured to transmit a public user account descriptor to the central contact directory, the public user account descriptor including information searchable during searches submitted by other users. The communication device further includes a hardware implemented conversation module. The hardware implemented conversation module is configured to receive a conversation rule. The conversation rule identifies contacts to receive the content, available response actions to respond to the content, a receipt time period identifying a period of time the content may be accessible by at least one user of the communication device, and a response time period identifying a period of time users may take an associated response action. The hardware implemented conversation module is also configured to communicate content between the user account and an identified contact based at least in part on the conversation rule. The hardware implemented conversation module is further configured to receive an administration rule. The administration rules include identifying available management actions to manage conversation rules, contacts receiving content, and descriptors associated with a conversation rule, where the descriptors include private descriptors and public descriptors. The administration rules further include identifying a communication setting to manage methods of communicating content between the user account and contacts receiving content, and content parameter rules to manage content settings. The communication device further includes a hardware implemented transaction module configured to consummate a transaction between the user and one or more identified contacts based on content communicated between the user and the one or more identified contacts.

[0009] In another innovative aspect, there is a communication server. The communication server includes a hardware implemented account manager configured to receive user account information including credentials. The communication server further includes a hardware implemented tag manager configured to receive public descriptors and private descriptors for a user account, where the public descriptors include a public descriptor that is available for allocation or allocated to the user account. The communication server also includes a hardware implemented allocation search engine configured to determine whether a requested public descriptor is available for allocation to the user account by receiving and executing an allocation search request for the requested public descriptor. The execution of the allocation search request is based at least in part on: private descriptors for the user account, public descriptors for the user account, and the requested public descriptor. The communication server also includes a hardware implemented tag allocator configured to, upon determining by the allocation search engine that the requested public descriptor is available for allocation to the user account, initiate an allocation transaction. The communication server further includes a hardware implemented transaction module configured to consummate the allocation transaction. The consummation of the allocation transaction includes allocating the requested public descriptor to the user account.

[0010] In another innovative aspect, there is a computer-implemented method of allocating a public descriptor under control of one or more computing devices configured with specific computer-executable instructions. The method includes, receiving a request to allocate at least one public descriptor to at least one of a user account and a conversation thread. The method also includes applying at least one availability rule to the at least one public descriptor. The at least one availability rule includes a plurality of public descriptors that are unrestricted from allocation to the at least one of a user account and a conversation thread. The method further includes determining the availability of the at least one public descriptor based on the at least one availability rule. The method also includes sending the request for the at least one public descriptor to a descriptor allocation server. The method includes determining that the at least one public descriptor includes at least one allocation constraint. The method further includes searching the descriptor allocation server for the at least one public descriptor having at least one allocation constraint. The method also includes negotiating for the at least one public descriptor, wherein the negotiation satisfies the allocation constraint. The method further includes allocating the public descriptor to the user account or conversation thread.

[0011] In another innovative aspect, there is an allocation server for allocating a public descriptor. The allocation server includes computer-readable memory storing executable instructions. The allocation server also includes one or more physical computer processors in communication with the computer-readable memory. The one or more physical computer processors are programmed by the executable instructions. The computer processors are configured to receive a request to associate at least one public descriptor to at least one of a user account and conversation thread. The request is received as a result of an availability determination based on at least one availability rule. The at least one availability rule includes a multiple public descriptors that are unrestricted from allocation to the at least one of a user account and a conversation thread. The computer processors are also configured to determine the at least one public descriptor includes at least one allocation constraint. The computer processors are also configured to search the descriptor allocation server for the at least one public descriptor having at least one allocation constraint. The computer processors are further configured to negotiate for the at least one public descriptor. The negotiation satisfies the allocation constraint. The computer processors are also configured to allocate the public descriptor to the user account or conversation thread. [0012] In another innovative aspect, there is a bidirectionally guided directory system. The system includes a communication server. The communication server includes a hardware implemented tag manager configured to receive public descriptors and private descriptors for a user account. The communication server also includes a hardware implemented first search engine configured to receive and execute search requests. The execution of a search request for the user account includes consideration of the public descriptor and private descriptors for the user account. The communication server further includes a hardware implemented conversation module configured to receive and transmit content between user accounts based at least in part on a conversation rule. The conversation rule identifies users to receive the content, where the users include at least one user and at least one enterprise. The conversation rule further identifies available response actions to respond to the content, the response actions including a transaction. The conversation rule also identifies a receipt time period identifying a period of time the content may be accessible by the users. The conversation rule further identifies a response time period identifying a period of time users may take an associated response action. The system also includes an enterprise server. The enterprise server includes a hardware implemented second search engine configured to received and execute representative search requests. The execution of a search request for the customer relationship manager includes consideration of a representative identifier. The enterprise server also includes a hardware implemented customer relationship manager configured to receive content from the communication server and identify, via the second search engine, a representative identifier to receive the content.

[0012] In another innovative aspect, there is a communication device. The communication device includes a hardware implemented access controller. The hardware implemented access controller is configured to receive credentials and provide access to an account based on the received credentials. The communication device also includes a hardware implemented descriptor coupler, having access to the account via data communication with the hardware implemented access controller. The hardware implemented descriptor coupler is configured to receive one or more external descriptor inputs, link one or more external descriptors with the account associated with the communication device based on the one or more external descriptor inputs, receive one or more internal descriptor inputs, and link one or more internal descriptors with an account associated with another communication device based on the one or more internal descriptor inputs. The communication device further includes a hardware implemented communication module. The hardware implemented communication module is configured to access the user account via the hardware implemented access controller, receive one or more communication requests based on the one or more external descriptors, and send one or more communication requests based on the one or more internal descriptors. The one or more external descriptor inputs are generated based in part on an incoming signal to the communication device. The incoming signal of the communication device may be based on a timestamp from a time server. The incoming signal of the communication device may be based on a geo-location indicator from a remote server. The incoming signal of the communication device may be based on a micro- location indicator from an on-site device. The incoming signal of the communication device may be based on account information of the account associated with the communication device from a communication server. The one or more external descriptor inputs may be generated based on one or more selections from multiple external descriptors and the external descriptors may be associated with one another. The multiple external descriptors may have cascading associations with one another. The external descriptors may be stored in one or more descriptor containers.

[0013] The systems, methods, and devices of the invention each have several aspects, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of this invention as expressed by the claims which follow, some features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled "Detailed Description," one will understand how the features of the various embodiments of this invention provide advantages that include improved communications between users system and merchants of the system.

[0014] In the following description, specific details are given to provide a thorough understanding of the examples. However, it will be understood by one of ordinary skill in the art that the examples may be practiced without these specific details. For example, electrical components/devices may be shown in block diagrams in order not to obscure the examples in unnecessary detail. In other instances, such components, other structures and techniques may be shown in detail to further explain the examples.

[0015] It is also noted that the examples may be described as a process, which is depicted as a flowchart, a flow diagram, a finite state diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel, or concurrently, and the process can be repeated. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a software function, its termination corresponds to a return of the function to the calling function or the main function.

[0016] Those of skill in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Embodiments of various inventive features will now be described with reference to the following drawings. Throughout the drawings, reference numbers may be reused to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of disclosure.

[0018] FIG. 1 is a functional block diagram of an exemplary communications network system in accordance with one embodiment.

[0019] FIG. 2 A is a functional block diagram of an exemplary wireless communication system in accordance with one embodiment.

[0020] FIG. 2B is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 2A. [0021] FIG. 3A is an exemplary message diagram for creating a threaded conversation from a private tag search in accordance with one embodiment.

[0022] FIG. 3B is an exemplary message diagram for creating a threaded conversation from a public tag search in accordance with one embodiment.

[0023] FIG. 4 is a flowchart for an exemplary method of searching tags in accordance with one embodiment.

[0024] FIG. 5 A is an exemplary user interface for creating a threaded conversation from a private tag search in accordance with one embodiment.

[0025] FIG. 5B is an exemplary user interface for creating a threaded conversation from a public tag search in accordance with one embodiment.

[0026] FIG. 6A is a flowchart for an exemplary method of initiating an administration portal of a threaded conversation in accordance with one embodiment.

[0027] FIG. 6B is a flowchart for an exemplary method of pausing and unpausing a threaded conversation in accordance with one embodiment.

[0028] FIG. 6C is a flowchart for an exemplary method of muting a threaded conversation in accordance with one embodiment.

[0029] FIG. 6D is a flowchart for an exemplary method of deleting a threaded conversation by an author in accordance with one embodiment.

[0030] FIG. 6E is a flowchart for an exemplary method of deleting a threaded conversation by a non-author participant in accordance with one embodiment.

[0031] FIG. 6F is a flowchart for an exemplary method of initiating administration features of a threaded conversation in accordance with one embodiment

[0032] FIG. 7A is a flowchart for an exemplary method of configuring communication settings of a threaded conversation in accordance with one embodiment.

[0033] FIG. 7B is a functional block diagram of an exemplary content management module of a threaded conversation in accordance with one embodiment.

[0034] FIG. 7C is a flowchart for an exemplary method of configuring tags associated with a threaded conversation in accordance with one embodiment.

[0035] FIG. 7D is a flowchart for an exemplary method of adding participants to a threaded conversation in accordance with one embodiment. [0036] FIG. 7E is a flowchart for an exemplary method of removing participants from a threaded conversation in accordance with one embodiment.

[0037] FIG. 7F is a flowchart for an exemplary method of configuring privacy settings of a threaded conversation in accordance with one embodiment.

[0038] FIG. 7G is a flowchart for an exemplary method of configuring geo- location preferences of a threaded conversation in accordance with one embodiment.

[0039] FIG. 7H is a flowchart for an exemplary method of adding a transaction to a threaded conversation in accordance with one embodiment.

[0040] FIG. 71 is a flowchart for an exemplary method of enabling financial transactions on a threaded conversation in accordance with one embodiment.

[0041] FIG. 7J is a flowchart for an exemplary method of enabling proximity offers to a threaded conversation in accordance with one embodiment.

[0042] FIG. 7K is a flowchart for an exemplary method of adding automatic expiration to a threaded conversation in accordance with one embodiment.

[0043] FIG. 7L is a flowchart for an exemplary method of enabling reviews on a threaded conversation in accordance with one embodiment.

[0044] FIG. 8 is an exemplary message diagram for purchasing tags in accordance with one embodiment.

[0045] FIG. 9 is a flowchart for an exemplary method of allocating a tag having an allocation constraint.

[0046] FIG. 10 is a functional block diagram of an exemplary communications network system in accordance with one embodiment.

[0047] FIG. 11 is a functional block diagram of an exemplary communications server for allocating descriptors.

DETAILED DESCRIPTION

[0048] One non-limiting advantage of the described systems and methods is self- discovery. Self-discovery is directed to users being searchable, via a mobile device, social network, digital communications device, etc., in the marketplace as the user desires. For example, a user may identify themselves as a surfer, an iOS developer, looking for Laker tickets, or other custom set of strings which are accessible by users of a system who are searching, for example, the marketplace. The user may use a mobile device, computer, or other form of digital communication device known in the art, to identify themselves as described. The identification may occur on communication network such as a social networking site. Each user of the system is able to define and associate tags with their account and device for other users to see. For example, the user may associate a tag with their account on a social network, such that when other users search the social network for the tag, the user's account may be located in accordance with the sought tag. Another non-limiting advantage of the described systems and methods is self-tagging. Whereas self-discovery allowed the user to specify to the world how they would like to be found, self-tagging allows users to define and associate tags with contacts (e.g., phonebook entry, other users' accounts, merchants, brands) for the user to see and use to manage interactions (e.g., conversation, transactions, offers, content) with their contacts. Self-discovery and self-tagging afford flexibility and control in how each user sees the world and how the world sees the user.

[0049] Another aspect that relates to self-discovery is a bidirectionally optimized search. Through the use of tags (as one example), users can influence their searches submitted to the system. For example, the user may associate a tag with contacts identified as potential business leads. When the user searches for contacts which may be at a location nearby while on a business trip, including the business leads tags in the search further refines, identifies, and presents the information according to how the user understands their contacts. This takes the optimization out of the "one-size-fits-all" optimizations and allows each individual user to develop their personal view of their online world.

[0050] Users also influence searches by tagging themselves. The user may be able to associate a tag to their profile via a mobile device or digital communication device. The user may select a tag on such a device, and the system may associate the tag to the user's account. These tags provide ways the user wishes to be identified, if at all, within the system. For example, a user may enjoy public singing, but is typically known as an excellent realtor. The user's credentials as a realtor may be discovered via standard search engine optimizations such as those which mine the Internet for web content. However, little or no information may be available about the singing abilities of this user. By enabling custom optimizations through tags, the user influences searches for singers by causing the user to be included in the result list.

[0051] Finding users or conversations in this manner is very powerful. It may be desirable to further facilitate communication with the people and ideas discovered. One non- limiting advantage of the communication systems and methods described is personally controlled privacy. Features such as unique identifiers for contacts and communications, disclosure or privacy by design, pausing conversations, snoozing conversation, and adding or removing contacts from your network allow the system to provide dynamic real-time management of who, what, and where communications occur.

[0052] In one implementation including self-discovery and a central communication engine, the system may be configured to request one or more tags from a user accessing the system via a client device. Using the client device, the user enters one or more tags and submits the tags to system. Just like the user can add tags to associate the user's account and the user's device with the tags and identity established based thereon, the user can dissociate and port the user's identity to another device to take advantage of device- neutral identity. For example, the user may perform credential exchanges to associate the user with the user's current device by logging in to the user's account in the cloud, by establishing a wireless or near-field connection, e.g., handshake, between a user-carried mobile token or fob and a location-specific machine, such as a vending machine, register, billboard, monitor, etc., or by transmitting biometric authentication information, such as fingerprint, retina, iris, voice, face, etc. Once the user authentication is established, the user's identity stored within the system can be ported to the authenticated user device to further the management of self- discovery and communication with others according to the system described herein. Therefore, the user and the user's current device provides context to the user's self- established identity and real-time activities.

[0053] A client device may be provided which will exchange messages with a central communication server. The messages may include information to bidirectionally optimize searches. One type of message which may be communicated is a tag for a friend (e.g., contact). The message may include one or more strings. This may be referred to as a local tag, a private tag, or a private descriptor because the tag is how the user wishes to identify the friend. Other users of the system will not see this tag. Accordingly, when the user who provided the tag submits a search, the tag will be considered as part of the search. When the friend or another user searches, the tag will be omitted from consideration.

[0054] The system may be configured to receive multiple messages to assign multiple tags to friends. The system may provide biographical user interfaces (UI) (e.g., pages) for each user. Via the biographical UI tags may be submitted. The tag may be one or more strings. The tag may be custom text (e.g., user defined). In some implementations, the system may suggest a tag based on previously provided tags. For example, if a user has previously tagged contact with "surfing buddy," when the same user begins entering a new tag for a contact, if the tag begins with "surf the system may suggest a completion of "surfing buddy."

[0055] A user's contact may have additional tags associated with them. In addition to the local tags, the system may be configured to automatically tag the contact based on information retrieved from third party systems such as social media sites.

[0056] Another type of message may be a tag identifying the user. This tag may be referred to as a global tag, public tag, or public descriptor. The global tag may be specified via one or more strings. The global tag indicates how the user wants the world to find and view the user. As such, searches submitted by any user will consider the global tag. This facilitates locating the user by anyone in the system.

[0057] As with other contacts, a user may also be provided a biography UI. The biography UI may include one or more controls to receive tags for the user indicating how the user wants the world (e.g., other users of the system) to find and view them. The global tag may identify a service offered by the associated user. An example of a service may be hair stylist, attorney, or a product for sale. The global tag may identify terms the user wishes to be associated with such that when other users search the marketplace, the user can be located or associated with the tag.

[0058] Consider the use case of selling an item. A user may tag themselves with the following tags: name (e.g., "john smith"), iOS7 developer for hire (a service), little league coach, baby sitter needed, surfer, and MacBook Pro® for sale. When people search for any of these tags in the marketplace John Smith will be identified instantly (e.g., real time relevance). The tagging described has a non-limiting advantage of bidirectional search optimization whereby a user need not wait for a search engine to crawl and optimize searches. A user may add or remove tags which are instantly used to adapt searches. This can also be useful once the MacBook Pro® is sold. John Smith need only remove the tag and he will no longer be identified when someone searches for sellers of a MacBook Pro®. More information related to tagging may be found in U.S. Provisional Patent Application No. 62/024907, filed on April 17, 2015 as U.S. Patent Application No. 14/689799 which is expressly incorporated by reference in its entirety.

[0059] These features allow the system to keep pace with users who are constantly changing each month, even sometimes daily. Individuals can search engine optimize (SEO) themselves in real time. Individuals can also un-SEO themselves by simply deleting tags for which they no longer want to be found. This provides a further non-limiting advantage of providing control of the history of information for a user, unlike online classifieds or the general Internet where users are not in control of what history is out there (e.g., cached, searchable) about them.

[0060] As a further illustration of bidirectional optimization, consider a person who tags himself "ios developer" at 8am because he has availability to pick up some work that day. He also tags himself with "baby sitter needed." At 10am someone searches in the marketplace for an ios developer who is for hire right now. The search considers the global tag submitted at 8am and it is selected by the searcher for an instant threaded conversation with each person participating via respective client devices. The developer agrees to take the job and at 1 lam deletes the tag created at 8am (ios developer). Instantly, the developer will no longer show up when people search for that tag. The developer is no longer bothered with people contacting for this tag and no cached information is retained which may result in stale information. However, the developer is still SEO for a babysitter needed because he still needs that and has not removed the associated tag. This example shows how the SEO is real time, simple, and highly localized, personalized, and relevant. Unlike current SEO solutions where the average user has no idea how to SEO themselves or their companies, the described features allow anyone to list or delist tags thereby optimizing searches at any time with minimal effort. [0061] One non-limiting advantage of the features described is simplified SEO. The systems and methods allow a user to self-tag to associate their account with specific keywords. The systems and methods further allow users to untag themselves to delete SEO tags and keywords associated with their account.

[0062] A further non-limiting advantage of the described features is that because the optimization is performed within the system, no history of the tags is maintained. This prevents stale information about a user account from being attributed to the user longer than is appropriate. Furthermore, it provides a more accurate representation of the services and products offered in the marketplace because each item is tagged for offer in real time rather than delaying the discovery of an item once available or prolonging the discovery of an item beyond its availability.

[0063] Once tagged, the contact can be searched by tags such as when a user creates a threaded conversation. A threaded conversation, a Threadsite, or a conversation thread is a message session initiated by at least one user of the system whereby the user (or other target users) is allowed to add content to the message session (such as photos, texts, audio, video, etc.). A threaded conversation is a messaging session that can be created on- demand or instantly between one or more users of the system. The messaging session may also be added to in real-time by users who are participating in the threaded conversation. A threaded conversation may be initiated in several different ways. In one embodiment, a user can search for a private tag, select one or more users associated with the private tag and then initiate a threaded conversation with those selected users. In some embodiments, a user may search a public or global tag, select one or more users associated with the tag, and initiate a threaded conversation. In some embodiments, a user may create a pre-loaded threaded conversation and then invite other users to join the conversation. These users may be from the author or creator of the threaded conversation's contact list or resulting from a public or private tag search. In some embodiments, a user may view a tag related to a company, product, service, or person (e.g., Coca-Cola, a website, etc.) in the user's real life experiences, the user may search for a unique identifier (e.g., a tag or keyword search) and the system may take the user to a threaded conversation associated with the company, product, service, or person. [0064] The initiating user may be able to setup privacy settings including the ability to modify or select settings related to the participants, communication stream (bidirectional or one-way communication) and settings related to the threaded conversation (e.g., direct or blind carbon copy (BCC)). For example, if the surfing conditions are going to be good, the user may initiate a threaded conversation with all contacts tagged "surfing buddy." As another example, a search may include multiple tags such as "male" and "photographer" and "L.A." The contacts retrieved may be included in an instant group threaded conversation created from that three tag search. This may be referred to as personal relationship management.

[0065] One non-limiting advantage of the described features is aspects to facilitate communications. As discussed above, the client device may be configured to search for users by tags. Threaded conversations can be created and filtered based on bidirectional information. From the user's perspective, the local tags can be used to filter users based on how the user sees the world. From the perspective of any user of the system, global tags can also be used to filter users based on how each user wishes to be seen.

[0066] Another non-limiting advantage is that the system may be configured to include threaded conversation administration portal ("admin portal") or method of Threadsite administration and managing pre-loaded Threadsites. The admin portal is a means for a user of the system to manage all threaded conversations that user has loaded on a device. A user is able to view the threaded conversations associated with the users account. Through the admin portal, a user may be able to access a threaded conversations administration features. In one embodiment, the user who created or authored the threaded conversation is the user permitted to modify the administrative features of the threaded conversation. The administration access permits a user to initiate flexibility in the communications. The system may be configured to pause communications. Pausing communications generally refers to suspension of receipt of conversation item for a threaded conversation. The system may be further configured to re- enable the thread upon receipt of a conversation item from the user or upon satisfaction of a predetermined condition (e.g., time period expires, client device enters an area). In one embodiment, an author of a conversation may pause the conversation, thereby disallowing other users from continuing to update the conversation until the conversation is un-paused. In one embodiment, any communications sent by a user to the conversation after an author has paused the conversation may not be transmitted to the conversation. A message may be displayed notifying a user that the conversation has been paused.

[0067] The system may be further configured to re-enable the thread upon receipt of a conversation item from the user or upon satisfaction of a predetermined condition (e.g., time period expires, client device enters an area). The system may be configured to add or delete participants at any time to an existing threaded conversation. The system may also be configured to maintain a curated history of all types of media included in a threaded conversation to organize and display the threaded conversation by different types of media such as video, audio, or text.

[0068] Consider the following example of the communication features described. As a first step, a user submits via a client device a search of the conversations conducted via the client device for a tag the user previously created before such as "Miami Dolphins Player." The result of this search is an instant list of everyone that had previously had this tag assigned. Next, the user chooses a type of group conversation to conduct. The type may include: group conversation, group BCC, group broadcast only (e.g., one way communication, no one can respond to the author). Then, the user selects the type of media to send. The media types may include text, audio, picture, video, or emoticon. The user may thus initiate the communication session based on the provided information.

[0069] In some embodiments, the admin portal may be configured to permit users to mute a threaded conversation. This feature permits a threaded conversation to continue while the user who muted the conversation on his device may not receive updates or notifications related to the conversation in real-time. This feature may be turned on where a user may not want to receive constant updates related to the threaded conversation but does not want to completely delete the conversation. A user may be able to later turn off the mute feature and may continue to receive updates.

[0070] Another non-limiting feature is that the author of a threaded conversation may be able to edit the settings of a threaded conversation. The admin portal may be configured to permit an author to enter an edit request which may take the user to the threaded conversation administration settings. The system may be configured to permit adjusting of several settings, such as: one to one conversations between two users; group conversations amongst several users; group "blind carbon copy" (BCC) broadcast conversations such as advertisements or announcements; and group broadcast only (e.g., all recipients identified, no responses permitted). The system may be configured to permit toggling between locked and unlocked states where a locked state may disallow participants from adding other users. Further, a locked state may disallow system users from searching for tags associated with the threaded conversation. Further still, an unlocked state may allow any system user into the threaded conversation.

[0071] The system may be configured to add or delete participants at any time to an existing threaded conversation. The system may also be configured to maintain a curated history of all types of media included in a threaded conversation in order to organize and display the threaded conversation by different types of media such as video, audio, or text. The system may be configured to enable searching of private or public tags to add participants. The system may be configured to permit adding or removing tags to the Threadsite to drive traffic. The system may be configured to permit setting up privacy settings, such as displaying or hiding an email address, phone number, physical address, etc.

[0072] The system may further be configured to display geo-location information of the author of the threaded conversation. In one embodiment, the system may also be configured to permit displaying all participants' geo-location information to the extent that each participant has turned the feature on. The system may also be configured to permit the author or participants to add items for sale within a threaded conversation and to configure the pricing method (e.g., a fixed price or bidding/auction pricing) for the item. In addition, the system may be configured to enable financial transactions between participants of the threaded conversation.

[0073] As further discussed below, the system may be configured to consummate transactions for one or more users of the system. The transactions may be consummated in conjunction with the various communication features described above. One type of transaction is a mobile payment. Payment credentials or information such as payment card information or digital wallet information may be stored in the network. This allows the payment information to be retained outside the client device (e.g., phone). The payment transaction aspects of the system may be configured to utilize encryption and/or tokenization to protect information needed to effect the payment such as card information, confirmation codes, personal identification numbers (PINs), passwords, personal identification information (e.g., date of birth, social security number, etc.), and the like. In some implementations, the system may include features to identify card-present rates for transactions at a rate that depends on physical presentation of card such as to a reader. For example, a beacon may be provided which is configured to acquire payment information. The payment transactions may be configured to integrate with payment networks or payment processing entities such as Europay, MasterCard, Visa (EMV) (a.k.a. "chip and pin") systems. In some implementations, transaction may include authorization by, for example, a PIN, one-time password (OTP), biometric information, bank-to-bank authorization, peer-to-peer (P2P) authorization, and the like. The system may receive the authorization information from a client device. The authorization information is then securely transmitted to the central server for processing payments such as via automated clearing house (ACH).

[0074] In some implementations, the transaction consummated through the system described herein may be in the form of mobile remittance. Mobile remittance may generally refer to sending money from one account to another and making payments such as bills. In some implementations, mobile remittance may be consummated across two or more nations, which may be referred to as cross-border remittance.

[0075] A further non-limiting advantage of the systems and methods described is the combination of communications and transactions in a single platform. Consider a user sitting in a cafe in New York. The user thinks of a friend who is living somewhere in South America. The user has previously tagged (e.g., self-tagged) this friend in his contacts as "friend" and "South America." Searching the contacts using these two tags, the user identifies and begins a threaded conversation with the friend. During the discussion, it comes up that the friend has found a great opportunity but needs some money to invest. The friend may transmit a video presentation of this great opportunity. After viewing the video in New York and from within the same threaded conversation, the user may want to join by sending a conversation item "Can I send you $100 to invest?" Using, for example, textual analysis of the conversation text, the system may identify that the threaded conversation is related to a potential transaction (e.g., it's a question, includes "send" and a dollar amount). The system may be configured globally (e.g., system-wide keywords or formatting) or dynamically (e.g., for each user, for a payment source) to identify transactional language. Once identified, the system may provide an interface element to initiate and consummate the transaction. Upon authorization from the user, the transaction may affect the transfer of the requested amount from an account associated with the user to the friend.

[0076] One aspect of the systems and methods described relates to messaging which is conducted via broadcasting hardware such as beacons, or other wireless transmitting devices. Examples include the mlBeacon™ and m2Beacon™ manufactured by Netclearance Systems, Inc. of Escondido, California. Further examples include the Gimbal™ proximity beacons manufactured by Qualcomm Retail Solutions, Inc. of San Diego, California; RadBeacon beacons manufactured by Radius Networks, Inc. of Washington, D.C.; and Estimote Beacons manufactured by Estimote, Inc. of New York, New York. By configuring the broadcasting hardware to transmit and receive conversations and/or tags as described in further detail below, physical locations can easily be transformed into virtual worlds.

[0077] The power provisioning for the broadcasting hardware is important because any physical limits placed on the location of the hardware limits access to mobile devices. Accordingly, it is desirable to power the broadcasting hardware via batteries or readily available power sources such as power over Ethernet, solar or other photovoltaic means, or Universal Serial Bus power.

[0078] The broadcasting hardware may be configured to communicate with client devices or a communication server via one or more wireless communication protocols. Examples of the wireless protocols include WiFi™, low power Bluetooth™, or iBeacon.

[0079] The broadcasting hardware may be placed such that each element creates a zone. The zones represent a discrete area within which tags or conversations may be transmitted and received and transactions conducted related to the area. For example, a restaurant may want customers to visit their new taco bar. A beacon may be placed near the taco bar transmitting a coupon, aka a proximity offer, for a free dessert to customers who visit the taco bar. When a customer enters the zone, the client device may receive the beacon signal, sending the proximity offer to the customer on the threaded conversation, and awarding the customer the dessert credit. In such an implementation, the client device may be a smartphone owned by the customer or a client device provided by the restaurant such as a tablet computer or electronic pager. Other zones may be established on premise in parking lots or other indoor or zones. Zones may also be established off premise such as at a kiosk or in a public park.

[0080] The broadcasting hardware may include a native application configured to communicate with client devices and/or communication server as described in further detail herein.

[0081] For example, a user can meet someone and exchange & start to communicate with a unique identifier (e.g., personal ID code) without giving up their personal information such as cell phone number, email, or mailing address.

[0082] Communication may also enable broadcasting of tags or conversations throughout the system. Also, beacons or other communication means, for example may serve as a location-specific portal to the network for the user to connect.

[0083] During the course of communication, the need to perform a transaction may arise. For example, if a user is selling tickets to a concert, a communication may be sent to contacts having a tag value identifying the band playing at the concert. Once a user wants to buy the tickets, the systems and methods described enable the consummation of the transaction. It should be appreciated that the above mentioned privacy measures may be maintained throughout the transaction. This provides a further non-limiting advantage of conducting transactions with limited exchange of personal information.

[0084] While the example transaction described above is a payment based transaction, the transactions included in the systems and methods disclosed below can include payments, remittance, coupons, and offers. The transactions may be real time, on demand, or predetermined. The transactions may be consummated using near field communication (NFC), one or more networked computing systems (NCS), or a combination thereof.

[0085] The system is configured to associate the tags with the user's account and store them in a database. The system may be configured to generate and store a search index to enhance the searching based on the newly provided tag information. The system may also be configured to derive and store metadata such as statistical rankings for the tag information received. The system may be further configured to generate and store a social graph for the user based at least in part on the provided tag information indicating relationships for the user with other actors within the system (e.g., brands, companies, schools, religious institutions).

[0086] The system may be configured for real time contextual search and discovery. For example, a user may input, via a client device, one or more search criteria. Search criteria may include search phrases or search attributes, which may vary depending on searching the user's Threadsite space or the marketplace. The system receives and analyzes search phrase and attributes for terms. The analysis may include identifying free text, tags, categories, geography, products, events, and/or proper names. Using the identified terms and attributes, a search of one or more datastores is performed. The datastores may include structured schemas (e.g., categories and directory), unstructured schemas (e.g., tagging), search index (e.g., relevance scored), and social graph analysis (e.g., relationships). The search may be configured to consider and aggregate these multiple datasources. The search is realtime and up to date with respect to the latest available global and local tags as well as privacy controls. The search results can be based on the proximity to the user. In another embodiment, the search result can be based on endorsement metrics, whereby other users can endorse a user based on a specific tag and the output of search results may be, at least in part, based on the endorsement. The search provides as an output ranked search results. The results are then displayed to user via the client device.

[0087] Having conducted a search, the user may then enter a discovery phase. Discovery may include the user evaluating the search results. The evaluation may include browsing ranked results, browsing categorized results, filtering the search results, and refining the search. The results may include items available via the marketplace and/or contacts.

[0088] In some circumstances, the user may transmit an identification of a contact to initiate a threaded conversation. The threaded conversation may include real time communication between the client devices. The system is configured to identify the receiving user on the network. Once the receiving user is identified, the system identifies a route to the user on the network. The route may include an online route to device. If the receiving user is offline, the route may include a queue for later delivery. The receiving device is notified of a request for a new connection. The connection may be automatically accepted or the client device may prompt user for acceptance. If accepted, a real time connection is established and the users may communicate as well as conduct transactions with one another, such as book appointments, schedule events, receive conversation items, purchase a product, transmit money.

[0089] The real time connection was facilitated by self-tagging, contextual search, and discovery. For example, the user may utilize self-tagging to associate a tag to their account. In one embodiment, self-tagging may be enabled via a mobile device and/or other devices capable of digital communication providing access to the user account via a social network or other account access. Another user may initiate a contextual search, as detailed above, whereby the user searches the system for the associated tag and locates the user's account due to the self-tagging by the user. Then, a contextual search may provide a list of results which a user may sift through during the discovery phase. Finally, a real time connection may be initiated as detailed in the preceding paragraph. Thus, the real time connection is a result of search and discovery.

[0090] In one implementation including self-discovery and a central communication engine, the system may be configured to include tags having at least one allocation constraint and tags that do not have any allocation constraints. Tags having at least one allocation constraint, such as fee-based tags, may comprise a tag that is owned by another user or being held out for sale by a user, where a user who seeks to associate a fee-based tag with a threaded conversation or the user's profile may be required to pay an agreed upon fee to utilize the tag. A free tag may be a tag that is held out for use without requiring any payment by a user. The system may manage a tag marketplace to manage the financial transactions and communicate with a database of tags to enable the purchase and sale of fee- based tags. A user who is interested in using a fee-based tag may have to purchase the tag from another user or operator the system to be permitted the right to associate that tag with the user's profile or a particular threaded conversation. The system may be configured to permit different pricing structures for fee-based tags, such as: fixed price for a fixed duration, a profit sharing model, a fixed price for life, a lease of the tag having a fixed price for a set duration of time and an option to renew, fixed price based on budget considerations, or bidding/auction transactions. Further, the system may be configured to permit a financial transaction based on the use of any fee-based tag.

[0091] For example, a user may wish to drive traffic to his threaded conversation by associating a tag "Coke" to the threaded conversation. The user may search for the tag "Coke" and the system may determine that the tag is a fee-based tag and not available for free. The system may then be configured to direct the user to the tag marketplace, where the user may have the option to purchase the tag. The system may also be configured such that once a user has purchased a tag, the tag may then be associated with the user's profile or threaded conversation as dictated by the user. When another user searches for the public tag "Coke" the user will be directed to the purchasers threaded conversation. In one embodiment, a financial transaction may be configured to occur each time another user connects to the purchaser's threaded conversation associated with the tag "Coke."

[0092] One aspect of the systems and methods described relates to integrating threaded conversations into Customer Relationship Management ("CRM") tools. A CRM tool is a system for managing a company's interactions with consumers. Examples include tools offered by Salesforce.com, SAP AG, Oracle, Microsoft Dynamic CRM, etc. By integrating the system with CRM tools as described in further detail below, companies may utilize the features of threaded conversations improve interactions with consumers.

[0093] The power of integrating CRM with the bidirectional search optimization is important because of the ability to quickly, efficiently, and directly address a particular consumer need. For example, the system may be configured to permit a user to search for a tag, for example "Coke," which may return a threaded conversation or users related to the tag. The user may locate a particular threaded conversation being managed by Coca-Cola Co. and select the threaded conversation. Coca-Cola Co. may manage a single conversation or multiple conversations related to its many products (e.g., Coke, Sprite, etc.), each conversation may be populated by multiple participants each engaging with Coca-Cola. Coca- Cola Co. may engage the user in the threaded conversation initiated by the user or may initiate a second threaded conversation. The second request may be a one-on-one conversation with the user to directly address the user's reasons for connecting with the company. By integrating CRM tools with system, when the user and Coke connect on a threaded conversation, the CRM may manage or direct the threaded conversation to a particular sales representative who may be able to be best address the user's concerns. Once a user initiates a threaded conversation with Coca-Cola Co. via a tag, Coca-Cola's CRM tool may be configured to identify the representative from a list of contacts that should be communicating with the consumer.

[0094] Example implementations of the system and method discussed above are described below in further detail in connection with FIGS. 1-10. Further illustrations, implementations, and descriptions are provided in Appendix A of this application.

[0095] FIG. 1 is a functional block diagram of an exemplary communications network system in accordance with one embodiment. The system 100 may be implemented via a client-server architecture where a client device 110a - 11 On has an application running locally that performs a set of functions that require communication with a communication server 102 in order to support desired functionality. The client application may be configured to allow users to input their desired request of the application via the client device 110a- 11 On, after which the request is sent to the communication server 102 for processing. The communication server 102 may be configured to optionally archive some information (e.g., tags, user contacts information, conversation archives, offers, transaction information, etc.), and the request may be routed either back to the initiating user and/or to a target user device. The system 100 shown includes multiple client devices (e.g., a client device 110a and a client device 11 On). It will be appreciated that fewer or more client devices may be included in the system 100. The client device 110a and the client device 11 On (collectively or individually hereinafter referred to as "client device 110") may be an electronic communication device configured to transmit and receive conversation items in a threaded conversation. Examples of such electronic communication devices include smartphones, feature phones, laptop computers, desktop computers, tablet computers, personal digital assistants, set-top devices, gaming consoles, automotive dashboard systems, kiosks, self-service consoles, and the like.

[0096] The messages the client device 110 may be configured to transmit and receive may include the tagging and conversation items described herein. The client device 110 may include specialized circuitry configured to transmit, receive, generate, and process the messages discussed in further detail below. In some implementations, the client device 110 may include a processor which is configured to execute stored instructions which cause the client device 110 to transmit, receive, generate, and process the messages described. The client device 110 may include additional modules as described in connection with FIGS. 2A-2B below.

[0097] The system 100 includes a network 190. The client device 110 may be configured to transmit and receive messages via the network 190. Examples of the network 190 include a wide area network (WAN), metropolitan area network (MAN), local area network (LAN), wireless local area network (WLAN), or personal area network (PAN). Although shown as one network, the network 190 may include several interconnected networks. The networks which may be included in the system 100 may differ according to the switching and/or routing technique used to interconnect the various network nodes and devices (e.g., circuit switching vs. packet switching), the type of physical media employed for transmission (e.g., wired vs. wireless), and the communication protocols used (e.g., Internet protocol suite, SONET (Synchronous Optical Networking), Ethernet, etc.). Regardless of the form the network 190 may take, the network 190 is configured to facilitate machine-to- machine messaging for tagging and communication as described herein.

[0098] The system 100 includes on-site information device(s) 130. An on-site information device may be an electronic communication device configured to transmit messages at a location. For example, an on-site information device may be implemented as a beacon. The beacon may be configured to transmit and receive tagging and communication messages to the client device 110 within, for example, a store. This allows a store owner to configure messages for broadcasting to the client device upon entry into a predetermined area. Sites may include stores, amusement parks, cruise ships, restaurant, hotels, convention centers, arcades, campuses, hospitals, and casinos. The beacon may be implemented as disclosed in U.S. Patent Pub. No. 2013/0226704, titled "CONSUMER INTERACTION USING PROXIMITY EVENTS," U.S. Patent Pub. No. 2013/0254104, titled "CONSUMER INTERACTION USING PROXIMITY EVENTS," and U.S. Patent Pub. No. 2014/0089111, titled "MOBILE DEVICE ORDER ENTRY AND SUBMISSION USING PROXIMITY EVENTS," which are and expressly incorporated by reference in their entirety. [0099] The on-site information device(s) 130 may communicate directly with the client device 110. In some implementations, the on-site information device(s) may communication with the client device 110 via the network 190.

[0100] The on-site information device(s) 130 may be configured by a site operator. As shown in FIG. 1, the site operator may be a merchant. The system 100 includes an enterprise server 140. The enterprise server 140 is configured to provide tagging and communication information. For example, the enterprise server 140 may provide one or more tags for transmission by the on-site information device(s) 130 at the site. The tags may facilitate the discovery of an item, location, or person at the site. The communication information may include a conversation item in a threaded conversation regarding an event at the site. In a merchant implementation, the conversation item may indicate a sale on a particular item. In a hospitality implementation, the conversation item may identify the starting time for a performance. In a variety of settings, the conversation item may be used to convey emergency information such as a fire, earthquake, or other time and location sensitive event information.

[0101] The enterprise server 140 may communicate directly with the on-site information devices 130. In some implementations, it may be desirable to have a centrally located enterprise server 140 and transmit the tagging and communication information via the network 190 to on-site information device(s) 130 located at one or more sites. In another implementation, it may be desirable to have the enterprise server in further communication with a CRM and enterprise database, as discussed further in FIG. 10.

[0102] The client device 110 may transmit and receive tags and communication information. Similarly, the enterprise server 140 may transmit and receive tags and communication information. The tags and communication information may be processed by a communication server 102. The communication server 102 is configured as a hub to tagging and communication activities within the system 100. The communication server 102 is configured to receive tags for user accounts (e.g., the enterprise server 140 or the client device 110). The communication server 102 may be configured to process the received tags such as by verifying the associated account, validating the tag, storing the tag in a database 104, and transmitting global tags via the network 190. The communication server 102 may be configured to provide searching of user accounts. The searching may be based on the tags stored in the database 104. The database 104 may store offer rules as described further below. The database 104 may store contacts and conversation archives. The database 104 may also store transaction history when a transaction module 260 (FIG. 2) completes a transaction request. In some implementations, the database 104 may store information in an encrypted format via encrypted communication medium. In some implementations, the database may store information for a predetermined period of time. For example, the database 104 may store conversation archives up to 30 days and transaction history up to 7 years.

[0103] The communication server 102 may be configured to receive threaded conversations for user accounts. The threaded conversations may be associated one or more tags. The threaded conversations may be associated with one or more user accounts. The communication server 102 may be configured to also receive distribution information for a given threaded conversation. For example, the threaded conversation may not be distributed outside a predetermined set of users. As another example, the threaded conversation may have limited visibility such as only to users associated with a predetermined tag. Accordingly, when a user performs a search, the threaded conversation may be provided if the tags (e.g., global and/or personal) associated with the user satisfy the distribution rules for the threaded conversation. As one example, consider a merchant interested in providing a promotion for a new product. The merchant may post a threaded conversation to their account with a tag "OurNewCoolThing". If a customer having a user account which is not associated with the tag "OurNewCoolThing" searches the system 100, the new product conversation is not provided. However, if the customer adds the tag "OurNewCoolThing" to the merchant contact as a personal tag, the new product may be returned in a search by the customer.

[0104] The communication server 102 may further manage the distribution and life of a conversation. For example, the communication server 102 may pause an ongoing conversation. The communication server 102 may also allow a threaded conversation to be deleted. Receiving a message to delete a threaded conversation cause the communication server 102 to ensure the user account requesting the deletion is authorized to do so and, if so, transmitting one or more messages to client devices to remove the threaded conversation. This allows users a higher degree of control over conversation items.

[0105] The communication server 102 may include a transaction processing module 106. The transaction processing module 106 is configured to perform payment processing or payment remittance. The transaction processing module 106 may be configured to consummate the transaction. In some implementations, the transaction processing module 106 may be configured to communicate with a third party transaction server 150 to consummate the transaction. The third party transaction server 150 may be, in some implementations, a remittance and/or payment processing server such as an e-wallet, a bank, an automated clearing house, an online money transfer service, or a digital currency exchange.

[0111] The communication server 102 may include a content/offer module 107.

The content/offer module 107 may be configured to provide coupons, offers, or content. The coupons, offers, or content may be provided on demand. The demand triggering the coupon or offer may be a search by a user including specific terms or having predetermined account characteristics. For example, a user account may be identified as associated with a 39 year old iguana owner located in a specific geographic area. A merchant within that area may wish to provide a coupon to lizard owners searching the system. In this example, when the iguana owner searches, the coupon from the merchant may be included in their search result. It should be understood that the coupon need not necessarily be linked to the search. However, the demand may include, for example, the search terms, stored user profile information (e.g., interests, age, home town, gender), current user information (e.g., device type, device connectivity, device operating system, GPS location information for a device), the user's tags, the user's conversations, and usage history for the user.

[0106] The demand may be based on proximity sensing via a beacon. For example, a merchant may deploy a beacon within a store. As a customer holding a wireless device (e.g., smartphone, tablet computer) enters a coverage area for the beacon, the wireless device may transmit information to the beacon. The information transmitted to the beacon may include identification information for the device, for a user of the device, and/or for an account associated with the device. The beacon may receive this information and transmit the information to the content/offer module 107 to receive a customized offer for the user. The customization may be based on the information provided by the wireless device. In some circumstances, the user may not have previously established a personal account with the communication server 102. In such cases, information about the device such as the media access control identifier may be used to determine characteristics of the device holder. Characteristics may include device type, device model, and device interactions (e.g., with this or other beacons). In some circumstances, the user may have previously established a personal account with the communication server 102. In doing so, the user may have provided tags describing themselves to the world (e.g., self discovery tag). The user may also be associated with private tags assigned by the merchant (e.g., self-tagging tags). In such cases, the additional tag data may be used to further select an appropriate offer for the user.

[0107] The selection of the offer may be based on offer rules store in the database 104. An offer rule may include one or more criteria (e.g., device characteristic, tag information, location, date, time, etc.) and an associated offer. In some implementations, a user may qualify for multiple offers. The offer rule may specify whether the associated offer may be combined with other offers, supersedes other offers, or is a default offer in the event another is selected. The offer rules may be provided by the merchant such as via a client device.

[0108] For example, a coupon code may provide content or features for download to the presenting user. The content/offer module 107 may be configured to confirm the content or features made accessible and transmit these to the client device 110. As another example, consider a casino implementation whereby the transaction may be a complimentary buffet dinner for users. The content/offer module 107 may be configured to identify users who qualify for the dinner and provide a threaded conversation or Threadsite including an identifier for the dinner to the user. The identifier may include a code, an image (e.g., QR code or other machine readable indicator), or other identifying information for the promotion. The identifier may then be presented at the restaurant for the dinner. In some implementations, the presentation may be via the messaging application on the client device 110. The communication server 102 may be configure to identify a recipient for this promotion, generate an identifier for the promotional offer to the identified recipient, transmit the identifier to the restaurant or casino management system, and consummate the redemption of the offer. In some implementations, the restaurant or casino management system acting as a third party transaction server may redeem the promotion in concert with the content/offer module 107.

[0109] The communication server 102 may be configured to communicate with the third party transaction server 150 via the network 190. The communication server 102 may include additional modules as described in connection with FIGS. 2A-2B below.

[0110] FIG. 2 A is a functional block diagram of an exemplary wireless communication system in accordance with one embodiment. The electronic communication system 200 may be implemented in whole or in part as the client device 110 or the communication server 102.

[0111] When implemented as the client device 110, the elements shown may be configured to provide tagging and communication services via the client device 110. To support tagging, a tagging module 210 is included. The tagging module 210 is configured to receive tags from a user such as via a user interface. The tagging module 210 may be configured to verify the tags such as verifying that: the tag is locally or globally unique, to ensure the tag is not offensive, the tag conforms to formatting requirements (e.g., minimum length, maximum length, characters included), or that the target item (e.g., conversation or contact) can be tagged by the user.

[0112] The tagging module 210 may be configured to communicate with a database 220 to conduct the tag verification. The database 220 may be implemented as in the database 104 (FIG. 1). The database 220 may include tags 222. The tagging module 210 may allow for predefined set of tags (e.g., tags 222), may allow rules to allow tags to be acceptable by a server (e.g., the communications server 102 in FIG. 1), and may allow for communication of the tags 222 between the client (e.g., the client device 110 in FIG. 1) and the database 220. The tags 222 are associated with one or more user accounts 224 which may also be stored in the database 220. The database 220 may further include tag verification rules. The tag verification rules may be provided through a user interface on the client device 110 to allow personal verification rules. In some implementations, the tag verification rules may be provided by the communication server 102 to enforce system- wide tag verification. [0113] Continuing with the client device implementation of the electronic communication system 200, a synchronization module 230 may be included. The synchronization module 230 is configured to synchronize information stored on the client device 110 with the communication server 102. For example, the client device 110 may be configured to operate without a network connection (e.g., "offline"). In such a configuration, the client device 110 may receive tag information (e.g., new tags, updated tags). Similarly, while the client device 110 is offline, the communication server 102 may receive new tag information. The synchronization module 230 determines which information to transmit to the communication server 102 to synchronize the locally stored information with the centralized storage on the communication server 102. The determination may be based on a timestamp associated with the tag information. For example, when a record is created, modified, or deleted in the database 220, a timestamp may be applied to the record.

[0114] The synchronization module 230 may identify a point in time to synchronize with the communication server 102 based on one or more of time, electronic communication device characteristics (e.g., power, processing bandwidth, network connectivity, temperature, memory, location), or based on a request for synchronization received from the communication server 102. Once the point in time is identified for synchronization, the synchronization module 230 may determine which records have been modified since the last synchronization time. These records are then transmitted to the communication server 102.

[0115] As noted, the synchronization module 230 may be configured to receive information from the communication server 102. The synchronization module 230 in receiving the information for updating is configured to reconcile the received information with the local information. For example, if a tag is updated in the database 220 and, prior to synchronization, another user creates the tag, the synchronization module 230 may be configured to transmit a message indicating the tag had previously been added. Alternatively, the synchronization module 230 may be configured to simply skip any updating of the tag information since the system reflects the desired state.

[0116] The synchronization module 230 thus far has described synchronization between a client device and a communication server. In some implementations, it may be desirable to synchronize a group of client devices. For example, if the client devices are sales associate electronic communication devices (e.g., point-of-sale tablet) at a store, it may be desirable to synchronize the tags between each associate's device. This provides a non- limiting advantage of allowing all associates to share information and enhance a customer's experience. For instance, a first associate in the shoe department may assist a customer with a new pair of Italian leather shoes. The first associate may tag the customer as interested in leather. While assisting the customer, the first associate may learn the customer is preparing for her thirtieth reunion next month. The first associate may subsequently transmit additional tags indicating the age, school, and reunion event for the customer. When the customer is seen browsing a different section of the store, say in the eveningwear department, because the tags from the first associate are synchronized onto other associates' devices, a second associate may use the previous information to direct the customer to a choice which is suited to their current interests and purchases (e.g., reunion attire for someone who graduated about 30 years ago and likes Italian leather).

[0117] The synchronization module 230 may store synchronization rules such as the synchronization point(s) and/or which devices to synchronize with in the database 220 or in a memory 292. While shown in FIGS. 2A-2B as separate elements, the database 220 may be included in a portion of the memory 292.

[0118] The synchronization module 230 may also be configured to coordinate threaded conversations. A conversation module 240 may be included in the electronic communication system 200. The conversation module 240 is configured to manage threaded conversations. The conversation module 240 may allow threaded conversations to be communicated from the client (e.g., the client device 110 in FIG. 1) to the database 220. The conversation module 240 may handle client requests to create a threaded conversation with a target device and respond back to the client (e.g., the client device 110 in FIG. 1) and the target device with information related to the threaded conversation that is created as a result of the client-initiated request. The target device may be another client device, for example. The conversation module 240 may receive information for a new conversation. The new conversation information may include one or more contacts to include in the conversation. The new conversation information may include conversation content such as text, image, video, or executable instructions (e.g., application). The content may be static or streaming (e.g., real-time). The new conversation information may include distribution rules. The distribution rules allow the conversation starter to control when, where, and with whom the conversation may be conducted. For example, the initiator may lock the list of recipients. Once locked, only the recipients identified by the initiator may participate in the conversation. Participation in a conversation can include one or more of accessing the conversation content, replying to the conversation content, forwarding the conversation content, and deleting the conversation content.

[0119] Another distribution rule may be to remove a conversation. Once removed by the initial author, all copies of the threaded conversation are removed from the system. For example, consider a special promotion by a sports team wherein the first one thousand responders receive a limited edition sweatband. The promotion may be published in a conversation to all users tagged as fans of the team. Once one thousand people have responded to the promotion, the threaded conversation may be deleted from the system. This affords, as one non-limiting advantage, robust control over various threaded conversation or Threadsite campaigns.

[0120] Once a conversation is started, the conversation module 240 may be configured to receive additional content contributed to the conversation. In one embodiment, the additional content may be provided in communication with a content management module 718. The content management module is configured to provide adding, editing, and deleting of a variety of media formats. For example, the media formats that may be, but are not limited to, photographs, textual and written media, audio media formats, and video formats, among other digital media. The author can access the content management module to add, delete, or edit media that is posted on the threaded conversation. In one embodiment, the author may be able to add, delete, or edit media uploaded by the author. In some embodiments, the author may be able to add, delete, or edit media regardless of the source, e.g. other participants. In some embodiments, non-author participants of the threaded conversation may be permitted to add, delete, or edit media content on the threaded conversation. In some embodiments, a user may be able to delete or edit the media that user personally added to the conversation. [0121] In some embodiments, the additional content may be provided in communication with content/offer module 270, as described below. The additional content may be stored in the database 220. The additional content may be presented such as via a graphical user interface. In some implementations, the conversation module 240 may provide a threaded conversation or Threadsite indicating additional content has been received. For example, the conversation module 240 may receive the promotion from the sports team and provide a summary for display on via the client device "Limited Time Promotion from Sports Team!" In some implementations, the conversation module 240 may generate the threaded conversation based on the conversation information (e.g., sender, content). In some implementations, the conversation information may include a summary for quick display.

[0122] As discussed above, a client device may operate offline. In such circumstances, conversations may be read, responded to, deleted, or started. The conversation information, like the tags, may be synchronized using the synchronization module 230. The synchronization module 230 may identify a point in time to synchronize with the communication server 102 and/or other client devices as discussed above with reference to tag synchronization.

[0123] The electronic communication system 200 may include a transaction module 260. In a client device, the transaction module 260 is configured to receive payment information and transmit the received information for processing or payment remittance. The payment information received by the transaction module 260 may include username, account number, password, personal identification number, and the like.

[0124] The electronic communication system 200 may include an offer/content module 270. The offer/content module 270 may be configured to receive coupons or offers. The coupons or offers may be received from the communication server 102 or from an on-site information device 130 (e.g., beacon). In some implementations, the coupons or offers are received on demand. The demand triggering the coupon or offer may be a search by a user including specific terms or having predetermined account characteristics as described above in reference to FIG. 1. The triggering demand may be the location of the electronic communication system 200 (e.g., entering an area covered by a beacon). In some implementations, the offer/content module 270 in a client device may transmit to and receive from information the offer/content module 107 of the communication server 102.

[0125] The electronic communication system 200 may include a search module 250. The search module 250 may be optimized in a way to return efficient result sets based upon client initiated public tag search requests. When implemented in a server (e.g., the communication server 102 in FIG. 1), the search module 250 may have the most up to date information related to public tags and may be able to provide this up to date information. When implemented in a client device (e.g., the client device 110 in FIG. 1), the search module 250 is configured to receive search terms and attributes and execute a search based on the received information. The search module may be configured to identify free text, tags, categories, geography, products, events, and/or proper names included in the received information. Using the identified terms and attributes, the search module 250 performs a search of one or more datastores. The datastores may include structured schemas (e.g., categories and directory), unstructured schemas (e.g., tagging), search index (e.g., relevance scored), and social graph analysis (e.g., relationships). The datastore may include the database 220 at the electronic communication system 200. In some implementations, the search module 250 may be configured to transmit the search information via the transceiver 294 to the communication server 102 for searching of a central datastore.

[0126] As shown in FIG. 2A, the database 220 includes search indices 226. The search indices may be used by the search module 250 to expedite searches and provide relevance information for a given search. For example, a tag may be associated with many users. As such, a search for the exact tag may associate the accounts associated with the exact match as a highly ranked result, while an account associated with a tag including the tag text may be given a lesser rank. When searching multiple datastores, the search module 250 may be configured to aggregate the results received from each source. The ranking of the results may also be based on the source. For example, if a search result was obtained from the database 220 on the client device, the rank may be higher than the ranking assigned to a remote source.

[0127] The search module 250 may be configured to communicate via a predefined search service interface (not shown). This can facilitate the search module 250 providing and consuming search services which conform to the service interface. Thus, any third party may publish the location of their search interface and allow client devices to configure these as searchable destinations. Similarly, the user may assign a ranking to each datasource to further personalize how much weight to give to a result from a particular source.

[0128] As discussed above, beacons may be deployed to transmit tags or other communications to devices which enter a predetermined area. To allow client devices to control the flow of information from beacons, a filtering module 254 may be included in the electronic communication system 200. The filtering module 254 may be configured to receive beacon conversation items in a threaded conversation, such as coupons or offers, and selectively process the received conversation items. The selective processing may be based on rules stored in the database 220. A rule may identify beacons sources which the client device will receive beacon conversation items from. Beacon sources may be identified by a unique identifier associated with the entity responsible for deploying the beacon (e.g., merchant). A rule may identify communication types to receive via beacon conversation items. For example, a rule may accept offers from merchants or brands associated with specified tag information. The content of the conversation item may also be limited such as by media type included in the conversation item. This allows the client device to manage resource usage during discovery by dynamically adjusting the content it can/will handle based on available resources (e.g., power, processing, memory, bandwidth).

[0129] When the electronic communication system 200 is implemented as either a client device of a communication server, the memory 292 may include both read-only memory (ROM) and random access memory (RAM). The memory 292 may provide instructions and data to a processor 204. A portion of the memory 292 may also include non- volatile random access memory (NVRAM).

[0130] The processor 290 is configured to control operations of the electronic communication system 200. The processor 290 may also be referred to as a central processing unit (CPU). The processor 290 may perform logical and arithmetic operations based on program instructions stored within the memory 292. The instructions in the memory 292 may be executable to implement aspects of the methods described herein. The elements included in the electronic communication system 200 may be coupled by a bus 299. The bus 299 may be a data bus, communication bus, or other bus mechanism to enable the various components of the electronic communication system 200 to exchange information. It will further be appreciated that while different elements have been shown, multiple features may be combined into a single element, such as bidirectional search configuration and related communications.

[0131] The electronic communication system 200 may also include a transceiver 294. The transceiver 294 may include a transmitter and a receiver configured to transmit and receive data between the electronic communication system 200 and a remote location. The transceiver 294 may be configured for wired, wireless, or hybrid wired/wireless communication. In some implementations, the transceiver 294 may include one or more of an antenna, a network interface controller, a signal generator, an amplifier, and a signal filter.

[0132] When the electronic communication system 200 is implemented as the communication server 120 (FIG. 1), the elements provide services which mirror those described in reference to the client device above. However, as the communication server 120 provides service to many client devices, the communication server 120 implementation of the electronic communication system 200 is configured to control the access of the system and data to authorized users. For example, the search optimization module 252 for the communication server 120 may be configured to differentially optimize searches for each user. For example, the search optimization module 252 may consider the local tags defined by a user for searches submitted by the user in addition to the global tags included in the tags 222. Other optimizations consistent with the methods described may be included in the search optimization module such as consideration of a social graph, search indices, metadata searching, and the like. In another example, a user may initiate a public tag search, and the user request may be performed by the search module 252 in the communication server 102 and processed through the search optimization module 252 in the communication server 102 based in part on predefined system local rules as well as search rules in the communication server 102.

[0133] FIG. 2B is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 2A. As illustrated in FIG. 2B, the electronic communication system 200 (FIG. 2A) may be implemented as an electronic communication system 200a in the client device 110 and/or as another electronic communication system 200b in the communication server 102. Reference to the electronic communication system 200 (FIG. 2A) herein refers to any implementations of the electronic communication system 200a, 200b. The client device 110 may be in communication with the communication server 102 through the network 109. Individual modules of the electronic communication systems 200a, 200b may further in communication with one another either within each of the electronic communication systems 200a, 200b through the network 190. Reference to the modules in the electronic communication system 200 (FIG. 2A) herein, such as the tagging module 210, refers to any implementations of such module in either the client device 110 or the communication server 102, such as tagging modules 210a, 210b. Further, FIG. 2B may include a server tags marketplace module 280 which may be configured to enable allocation of tags having at least one allocation constraint as detailed below in FIGS. 8 and 9.

[0134] FIG. 3 A is an exemplary message diagram for initiating a private tag search and creating a threaded conversation in accordance with one embodiment. The message flow of FIG. 3 A shows messages exchanged between several entities which can be included in a communication system. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein. In one implementation, the device search module 250a, device database 220a, the device conversation module 240a and the server conversation module 240b may be implemented in the communication server 102 and/or the client device 110 (FIGS. 1-2B).

[0135] Messaging 302 is performed to request a private tag search to be executed by the search module 250a. In one embodiment, the user may be prompted with options to select a subset of the user's contacts to narrow the search target. The options may be predefined (e.g., categories) or dynamically specified such a via a user input value. In one embodiment, the user may be given an option to exclude certain contacts from the private search. In some embodiments, a private search may be performed to search the user's entire contacts. In one embodiment, a private search may be performed on the user's threaded conversations with one or more of the user's contacts. In some embodiments, the user may be given an option to exclude threaded conversations from the private search. In one embodiment, the user may be given suggested search terms which the user may select instead of the user inputted search terms.

[0136] Messaging 302 is also be performed to access and search relevant portions of the database 220a by the search module 250a. Once the search module 250a receives a private search request with search terms, for example, the search module 250a may process the search terms to optimize the private search. In one embodiment, only the private search index in the database 220a may be searched in response to the private search request. In some embodiments, the search module 250a may be configured to prioritize the private search index over other types of information of the user's contacts in the database 220a. In one embodiment, the search module 250a may search the user's private tags. In some embodiments, the search module 250a may search the user's private tags in conjunction with the user's contacts' public tags. In one embodiment, the search module 250a may access only information on the user's contacts in the database 220a in response to the private search request. In one embodiment, the search module 250a may access information on the user's contacts as well as the user's conversation with any of the user's contacts in the database 220a in response to the private search request.

[0137] Messaging 304 is performed to retrieve a private tag search response from the database 220a by the search module 250a. After the search module 250a performs a search on relevant subsets of data in the database 220a, the search module 250a may receive tag search response as a result of the private search. The search module 250a may further process the retrieved contact data in preparation for presenting the search result to the user of the client device 110. In one embodiment, messaging 304 may retrieve a private tag search response including contact data from database 220a. In some embodiments,messaging 304 may also be performed to receive and display private tag search response results by the client device 110a. In one embodiment, the search module may sort and organize the private tag search response it retrieved from the database 220a. In some embodiments the device database 220a may send raw search result to the device search module 250a, and the client device may sort and organize the raw search result it received from the search module 250a. In one embodiment, the search result may be presented to the user based on user-defined priorities. In one embodiment, the search result may be prioritized based on relevance and/or the user's communication frequency with the contacts, for example.

[0138] Once the user is provided with a private search result, the user may select one or more of the contacts from the search result, and messaging 305 is performed to request to create a threaded conversation by the device search module 220a. In one embodiment, the user may select one or more contacts from the private search result to start a threaded conversation. In one embodiment, anyone who joins the threaded conversation may invite and add others. In one embodiment, the user may select to create a locked threaded conversation, which may limit adding a new participant to the threaded conversation by participants but may allow the conversation originator the option to add participant at any time. In one embodiment, the user may select to create a broadcast threaded conversation, which only allows one-way communication from the user to other participants of the thread. In one embodiment, a broadcast threaded conversation may allow participants to identify others within the broadcast. In some embodiments, a broadcast threaded conversation may disallow participants from identifying others within the broadcast if the user elects to enable blind carbon copy (BCC). In one embodiment, the user may select to blind carbon copy (BCC) the threaded conversation recipients so that the recipient may not be able to view other conversation participants nor their response to the user. The client device 110a may receive from the user all the requisite and optional inputs for creating a threaded conversation and may send a conversation request based on the user's inputs.

[0139] Messaging 306is performed by the device conversation module 240a to instantly initiate a threaded conversation on server conversation module 240b based on the conversation request from the user of the client device 110a. The server conversation module 240b may be configured to create a communication or threaded conversation to which multiple users of the system 100 may be added. In one embodiment, the threaded conversation may also be stored in the database 220a. In one embodiment, the threaded conversation may be linked to all the participants of the conversation, and in some embodiments, the threaded conversation may be only linked to the conversation requester. The device conversation module 240a and/or server conversation module 240b may be configured to allow multiple participants to send and receive instant conversation items including text, audio, video, image, other content, etc. through the threaded conversation. According to the user's conversation request, the device conversation module 240a and/or server conversation module 240b may be configured to limit the thread participant's ability to reply to the communication, view other thread participant, and/or add additional participants.

[0140] FIG. 3B is an exemplary message diagram for initiating a public tag search and creating a threaded conversation in accordance with one embodiment. The message flow of FIG. 3B shows messages exchanged between several entities which can be included in a communication system. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein. In one implementation the device search module 250a, the server search module 250b, the server database 220b, the device conversation module 240a, and server conversation module 240b may be implemented in the communication server 102 and/or the client device 110 (FIGS. 1-2B).

[0141] Messaging 312 is performed to request a public search to be executed by the server search module 250b. The device search module 250a may be configured to send search terms inputted by the user of the client device 110. In one embodiment, the user may be prompted with options to select a subset of the server database 220a to narrow the search target. In one embodiment, the user may be given an option to exclude the user's entire contacts from the public search, in some embodiments, the user by given an option exclude some of the user's contacts from the public search. In one embodiment, a private search may be performed to search the server database 220a in conjunction with the public search. In one embodiment, a public search may be performed on the public threaded conversations regardless of whether the user or any one of the user's contacts is participating in the conversation. In one embodiment a public search may be performed on public conversation tags. In some embodiments, the user may be given an option to exclude threaded conversations from the public search. In one embodiment, the user may be given suggested search terms which the user may select instead of the user inputted search terms.

[0142] Messaging 314 is performed to request public tag search to access and search relevant portions of the server database 220b by the server search module 250b. Once the search module receives a public search request with search terms, for example, the server search module 250b may be configured to process the search terms to optimize the public search. In one embodiment, the public search index in the server database 220b may be searched in response to the public search request. In one embodiment, the server search module 250b may be configured to search other users' public tags. In some embodiments, the server search module 250b may be configured to search the user's private tags in conjunction with other users' public tags. In one embodiment, the server search module 250b may access information on other users' public profile information in the server database 220b in response to the private search request. In one embodiment, the server search module 250b may be configured to access information on other users' public profile as well as other users' conversation having public tags in the server database 220b in response to the public search request.

[0143] Messaging 316 is performed to retrieve a public tag search response including, for example, public search data from the server database 220b by the server search module 250b. After the search module performs a search on relevant subsets of data in the server database 220b, the server search module 250b may receive data as a result of the public search. The search module may further process the retrieved public search data in preparation for presenting the search result to the user of the client device 110 through the device search module 250a, as shown in messaging 316.

[0144] Messaging 318 is performed to receive and display search result by the client device 110 to the user through the device search module 250a. In one embodiment, the device search module 250a may be configured to sort and organize the public data it retrieved from the server database 220a, via the server search module 250a. In some embodiments the server search module may send raw search result to the client device 110, and the client device may sort and organize the raw search result data it received from the search module. In one embodiment, the search result may be presented to the user based on user-defined priorities. In one embodiment, the search result may be prioritized based on relevance, priority, location, and/or distance from the user, for example.

[0145] Once the user is provided with a public search result, the user may select one or more of the entries (e.g., other personal users, business users, etc.) in the search result. Messaging 320 is performed by the device search module 250a to indicate entities or items of interest the user selected to initiate a threaded conversation in device conversation module 240a. In one embodiment, the user may select one or more entries from the public search result to start a threaded conversation. For example, the user may interact with the user interface of client device 110 to select items of interest. In one embodiment the client device 110 may be a mobile device and the client device may display the search results from message 318. The user may then select items of interest from the search results by either inputting the sought item or by selecting from the list. Items of interest may be, but are not limited to, other users of the system, enterprises associated with a tag, public tags associated with any other user, private tags associated with other contacts, etc.

[0146] Once the user has selected the items of interest, message 320 may be configured transmit the selected items to device conversation module 240a for initiating a threaded conversation with those items of interest. In one embodiment, device search module 250a may be configured to accept a user selection of items of interest and transmit the items to device conversation module 240a. Device conversation module 240a may be configured to accept a user selection and may be configured to receive user inputs for the creation of a threaded conversation. In one embodiment, anyone who joins the threaded conversation may invite and add others. In one embodiment, the user may select to create a locked threaded conversation, which may limit adding a new participant to the threaded conversation. In one embodiment, the user may select to create a broadcast threaded conversation, which only allows one-way communication from the user to other participants of the thread. In one embodiment, the user may select to blind carbon copy (BCC) the threaded conversation recipients so that a recipient may not be able to view other conversation recipients who received the same conversation item through the threaded conversation. The client device 110, via device conversation module 240a and/or content management module 718, may be configured to receive from the user all the requisite and optional inputs for creating a threaded conversation, as described above, and may send a conversation request based on the user's inputs.

[0147] Messaging 322 is performed by the server conversation module 240b to instantly create a threaded conversation based on the conversation request from the device conversation module 240a. The server conversation module 240b may create a communication thread to which multiple users of the system 100 may be added. In one embodiment, the threaded conversation may also be stored in the server database 220a. In one embodiment, the threaded conversation may be linked to all the participants of the conversation, and in some embodiments, the threaded conversation may be only linked to the conversation requester. The server conversation module 240b may be configured to allow multiple participants to send and receive instant conversation items including text, audio, video, image, other content, etc. through the threaded conversation. According to the user's conversation request, the server conversation module 240b may be configured to limit the thread participant's ability to reply to the communication, view other thread participant, and/or add additional participants.

[0148] FIG. 4 is a flowchart for an exemplary method of searching tags in accordance with one embodiment. The method shown in FIG. 4 may be implemented in the search module 250 that is in communication with the database 220 in the communication server 102 as described in connection with, for example, FIGS. 1, 2, and 3.

[0149] At block 402, a search request is received. In one embodiment, a user may input, via a client device, one or more search requests. A search request may include phrases, keywords, tags, or search attributes, which may vary depending on searching a contact or threaded conversation. In some embodiments, the search module 250, upon receipt of the search request, may be configured to process the search request which includes the search terms to facilitate an accurate search. The processing of the search request may include identifying free text, free or fee-based tags, categories, geography, products, events, and/or proper names included in the received information. The processing may further include identification of the data sources for the search. After the search request is received, the process continues to decision block 404.

[0150] At decision block 404, a determination is made whether the search request is for a private search or a public search. In one embodiment, a user may select, by an input on the client device, a public or private search. For example, a menu may list two options, a "public search" option and a "private search" option, whereby the user may select one or the other. In some embodiments, the search module 250a of client device 110 may include a set of locally stored determination rules. Search module 250a may be configured to apply the determination rules to a search request, the determination rules being able to instruct the search module 250 to search the device database 220a (e.g. a private search) or the server database 220b (e.g. a public search).

[0151] In some embodiments, search module 250 may evaluate determination rules to conclude the requested search is either private or public, and then transmit the search, if it is a public search, to search module 250b. Search module 250b may determine the search request is a public search request. If the search request is a public search request, the process continues to block 406. If the search request is a private search request, the process continues to block 408. In one embodiment, the process may continue to blocks 406 and 408 simultaneously and perform a private search and a public search in tandem. The system may return results, in accordance with the process as detailed below, for both a private and public search in the same search results. In one embodiment, the system may display, on client device 110, the search results where each result may be identified as a private tag or public tag. In some embodiments, the search request may return two lists displayed on client device 110 simultaneously, where the user may view public search results while also viewing private search results.

[0152] At block 406, a public tag search is performed. In one embodiment, the public index in the database 220b may be searched in communication with search module 250b to perform the public tag search. In some embodiments, the system may use terms and attributes identified in block 402 to perform a search of one or more datastores having public tags, for example database 220b. The datastores may include structured schemas (e.g., categories and directory), unstructured schemas (e.g., tagging), search index (e.g., relevance scored), and social graph analysis (e.g., relationships). The search may be configured to consider and aggregate these multiple datasources. The search may be in realtime and up to date with respect to the latest available global tags as well as privacy controls. In another embodiment, the search may include an intelligent auto-suggestion feature, where the terms are associated with multiple datasources to automatically suggest applicable tags based on the user's tag request. After the public tag search is performed, the process continues to block 410. [0153] At block 410, the public tag search result set is sent to the requester's device. In one embodiment, the search module 250b may send the results to a client device 110. The public tag search results may include a list of contacts or items having the public tag searched at block 406. In one embodiment, the search may provide an output ranked search result. In another embodiment, the public tag search result set may be displayed in a representative map of an area based on the search requestors location and the public tag search results may be displayed with a ranking based on the proximity to the search requester. In some embodiments, the results may be displayed to the user via the client device 110. After the public tag search results are sent to the user device, the process continues to block 412.

[0154] At block 412, the user selects at least one user or item of interest from the public tag search results received in block 410. The user selection may include the user evaluating the search results. The evaluation may include browsing ranked results, browsing categorized results, filtering the search results, and refining the search. The results may include threaded conversations, contacts, and/or tags with or without allocation constraints, as described in reference to FIG. 8 and 9. Once the user selects at least one contact or item of interest, the process continues to block 414.

[0155] At block 414, upon selecting at least one user or item of interest, the user is able to instantly initiate a threaded conversation with the at least one user or item of interest having the public tag the user previously searched. In one embodiment, the user may transmit an identification of a contact to initiate a threaded conversation over conversation module 240. The threaded conversation may include real time communication between the client devices. The system may be configured to identify the receiving user on the network. Once the receiving user is identified, the system may identify a route to the user on the network. The route may include an online route to device. If the receiving user is offline, the route may include a queue for later delivery. The receiving device may be notified of a request for a new connection. The connection may be automatically accepted or the client device may prompt user for acceptance. If accepted, a real time connection is established and the users may communicate. In one embodiment, the established connection enables a threaded conversation by communication between the conversation module 240a of each client device 110, thereby storing the conversation locally in memory 292a of each client device 110. In some embodiments, the device conversation module 240a may transmit the user's input and response related to a threaded conversation to server conversation module 240b, which may store the conversation in memory 292b. In some embodiments, the threaded conversation may be stored either locally in memory 292a and/or memory 292b of the communication server. When the threaded conversation is initiated, the process ends.

[0156] At block 408, a private tag search is performed. In one embodiment, the private index in the database 220a may be searched in communication with search module 250a to perform the private tag search. In some embodiments, the system may use terms and attributes identified in block 402 to perform a search of one or more datastores having public tags, for example database 220a. The datastores may include structured schemas (e.g., categories and directory), unstructured schemas (e.g., tagging), search index (e.g., relevance scored), and social graph analysis (e.g., relationships). The search may be configured to consider and aggregate these multiple datasources. The search may be in realtime and up to date with respect to the latest available local or private tags as well as privacy controls. After the private tag search is performed, the process continues to block 416.

[0157] At block 416, the private tag search result set is sent to the requester's device. In one embodiment, the search module 250a may send the results to client device 110. The private tag search results may include a list of contacts or items having the private tag searched at block 408. In one embodiment, the search may provide an output ranked search result. In some embodiments, the results may be displayed to the user via the client device 110. The private tag search results may include a list of contacts or items of interest having the private tag previously searched. Once the private search results are sent to the user device, the process continues to block 418.

[0158] At block 418, the user selects at least one contact or item of interest from the private tag search results received in block 416. The user selection may include the user evaluating the search results. The evaluation may include browsing ranked results, browsing categorized results, filtering the search results, and refining the search. The results may include threaded conversations, contacts, and/or tags with or without allocation constraints, as described in reference to FIG. 8 and 9. Once the user selects at least one contact or item of interest, the process continues to block 420. [0159] At block 420, upon selecting at least one user or item of interest, the user is able to instantly initiate a threaded conversation with the at least one user or item of interest having the private tag the user previously searched. In one embodiment, the user may transmit an identification of a contact to initiate a threaded conversation over conversation module 240b. The threaded conversation may include real time communication between the client devices. The system is configured to identify the receiving user on the network. Once the receiving user is identified, the system identifies a route to the user on the network. The route may include an online route to device. If the receiving user is offline, the route may include a queue for later delivery. The receiving device is notified of a request for a new connection. The connection may be automatically accepted or the client device may prompt user for acceptance. If accepted, a real time connection is established and the users may communicate. In one embodiment, the established connection enables a threaded conversation by communication between the conversation module 240a of each client device 110, thereby storing the conversation locally in memory 292a of each client device 110. In some embodiments, the device conversation module 240a may transmit the user's input and response related to a threaded conversation to server conversation module 240b, which may store the conversation in memory 292b. In some embodiments, the threaded conversation may be stored either locally in memory 292a and/or memory 292b of the communication server. When the threaded conversation is initiated, the process ends.

[0160] The search result of public or private tags set may be personalized. Personalization may include reordering the search result sets based on user-defined parameters. For example, the user may provide a data source preference list which identifies a ranking of results from each data source. In such an example, a result from a higher ranked data source may be listed more prominently (e.g., nearer to the first presentation position on the result list) than other results. In one embodiment, the search result may be reordered based on the prioritization derived from the user's general profile.

[0161] FIG. 5A is an exemplary user interface for creating a threaded conversation resulting from a private tag search in accordance with one embodiment. In one embodiment of a user interface, the user device can display a table of contacts including at least one entry associated with each contact that is a private tag descriptor for the contact. In another embodiment, the user may search a private tag, select contacts and items of interest resulting from the private tag search, and may be able to instantly begin a threaded conversation by connecting and sharing information with at least one contact. In this exemplary user interface, the user has searched the private tag "Friends" and able to select "Dean Kosage" and "Personally, Inc," and then begin a threaded conversation with these contacts. In one embodiment, the threaded conversation may have options to lock the threaded conversation, BCC recipients, or turn on a broadcast mode as described in detail in connection with FIGS. 6F and 7 A. In this example, the user has selected to lock the threaded conversation to limit adding new participants and turned on BCC to limit the recipients' viewing of other recipients of the same threaded conversation.

[0162] FIG. 5B is an exemplary user interface for creating a threaded conversation resulting from a public tag search in accordance with one embodiment. In one embodiment of a user interface, the user device can display a table of user profiles including at least one entry associated with a user profile that is a public tag descriptor for the user profile. In another embodiment, the user may search a public tag, select user profiles and items of interest resulting from the public tag search, and may be able to instantly begin a threaded conversation by connecting and sharing information with at least one user profile. In this exemplary user interface, the user is able to select "Dean Kosage" and "Personally, Inc," and then begin a threaded conversation with these contacts. In one embodiment, the threaded conversation may have options to lock the threaded conversation, BCC recipients, or turn on a broadcast mode as described in detail in connection with FIGS. 6F and 7 A. In this example, the user has selected to lock the threaded conversation to limit adding new participants and turned on BCC to limit the recipients' viewing of other recipients of the same threaded conversation.

[0163] Another non-limiting advantage of the described aspect is communications and privacy management, through an administration portal. The user may prescribe rules to a communication or threaded conversation to restrict reply, viewing of recipients, or adding new participants. The user may further pause, mute, or globally (system-wide) delete an existing (or user-created) communication or threaded conversation so that the user may reduce disturbances from constant communications and control user-created communications threads.

[0164] FIG. 6 A is a flowchart for an exemplary method for a user of a threaded conversation to manage the settings of threaded conversations in accordance with one embodiment. The method shown in FIG. 6A may be referred to as a Threadsite administration portal or threaded conversation administration portal. The method shown in FIG. 6 may be implemented in the conversation module 240 in communication with the database 220 in FIGS. 2A-2B.

[0165] At block 602, a threaded conversation is initiated and a conversation between two or more users may commence in accordance with the process described in reference to FIG. 4. In one embodiment, the user initiates the threaded conversation as the author based on the user's contacts, private tag search, public tag search, etc. In some embodiments, the user is a participant in a threaded conversation authored by another user, resulting from a private or public tag search and selecting a resulting threaded conversation. The tag search resulting in a threaded conversation may be performed in accordance with the process described above in reference to FIG. 4. A threaded conversation participant may send a threaded conversation item, and the process continues to block 604.

[0166] At block 604, a determination is made as to whether the user is the author of the threaded conversation. The threaded conversation may include an identifier, where the conversation module 240 may be configured to accept the identifier and based on the identifier determine whether a participant is the author or creator of the particular threaded conversation. In some embodiments, memory 292 may store the identifier indicating whether a stored threaded conversation was authored by the user, and may communicate the identifier to the conversation module 240. If the user is the author of the conversation, the process continues to point A. In one embodiment, the author of the threaded conversation may have the ability to edit the threaded conversations the user created, as shown in further detail in FIG. 6F and 7A-7L. In some embodiments, the author of the threaded conversation is able to delete a threaded conversation the user no longer is interested in managing, thereby deleting the threaded conversation from the database of all users' devices, as explained in more detail in FIG. 6D. In yet some embodiments, the author is able to mute the threaded conversation. Muting the conversation may avoid unwanted updates and notifications regarding the muted conversation while permitting the threaded conversation to continue, as explained in more detail in FIG.6C. In a further embodiment, the author is able to pause the threaded conversation via the threaded conversation administration portal, thereby disallowing others from continuing to communicate on the threaded conversation until the author initiates an unpause command, as is explained in further detail in FIG. 6B.

[0167] If the user is not the author, thereby only a participant in the threaded conversation, the process continues from decision block 604 to point B. In one embodiment, the non-author user may be able to locally delete a threaded conversation from an account but may not remove the threaded conversation from the accounts of all participants, as explained in more detail in FIG. 6E. In some embodiments, the non-author user may be able to mute the threaded conversation, allowing the threaded conversation to continue while not receiving notifications of updates, as explained in more detail in FIG. 6C.

[0168] FIG. 6B is a flowchart for an exemplary method of pausing and unpausing a threaded conversation in accordance with one embodiment. The method shown in FIG. 6B may be implemented in the conversation module 240 in communication with the database 220 in FIGS. 2A-2B.

[0169] At start point A, a threaded conversation may have been created and a determination as to the authorship of the threaded conversation may have been made as described in reference to FIG. 6A. As a threaded conversation participant, the user may send a threaded conversation item and the process continues to block 606.

[0170] At block 606, a threaded conversation item is received. The conversation module 240 may be configured to receive a threaded conversation item from a user. In one embodiment, the conversation item may be input by a user on client device 110 and communicated to conversation module 240. In some embodiments, the conversation module 240 may prepare the conversation item to be transmitted to the threaded conversation either directly to another user's client device or to server conversation module 240b. In one embodiment, one or more conversation participant(s) may be disallowed from sending a threaded conversation item for a paused conversation, and the threaded conversation item may not be received if the conversation is paused. The conversation module 240, having a paused conversation, may be disallowed from sending the conversation item. In some embodiments, the threaded conversation item may be received for later transmission regardless of whether the conversation is paused as depicted in the method of FIG. 6B. The conversation module 240a, having a paused conversation, may transmit the conversation item to conversation module 240b, and the conversation item may be held for later transmission to another user's conversation module 240a. When the system receives a conversation item, the process continues to decision block 607.

[0171] At decision block 607, a determination is made as to whether a pause request was received. An author may access the threaded conversation admin portal, and within the portal select to pause a conversation. In one embodiment, the author may select to pause via a user interface listing a pause option. In one embodiment, the conversation module 240a may determine whether the user selected to pause one or more conversation(s). In some embodiments, a pause request may be applied to all threaded conversations that a user authored. In yet some embodiments, the pause request may include an identifier for the threaded conversation to be paused. The identifier may be a result of the author of the threaded conversation selecting, in a user-interface, to pause a one or more conversation(s). If a pause request is not received, the process continues to block 610. If a pause request is initiated by a user, the process continues to block 608.

[0172] At block 608, the identified threaded conversation is paused. In one embodiment, a threaded conversation may be publically paused upon the threaded conversation creator's request. In one implementation, the conversation module 240 may be configured to receive a pause request from a user. In another implementation, conversation module 240 may be configured to globally pause a conversation thread by communicating a pause request to the conversation module 240 of each participant. In some embodiments, a threaded conversation may be privately paused upon a pause request be a non-creator conversation participant. The conversation module 240 may pause the conversation on the particular user's client device. In some embodiments, the threaded conversation may be configured by the creator to allow or disallow pausing by one or more of the conversation participants. In one embodiment, the user client device may be configured to display to the user whether a threaded conversation is paused or not. After the threaded conversation is paused, the process continues to decision block 609.

[0173] At decision block 609, a determination is made as to whether an unpause request was received. The conversation module 240 may be configured to accept an unpause request. In some embodiments, the conversation module 240 may be configured to access memory 292 to determine whether an existing pause action persists in client device 110. The unpause request may include an identifier for the threaded conversation that the conversation module 240 may be configured to accept. If an unpause request is received, the process continues to block 610. If an unpause request is not received, the process continues to decision block 611.

[0174] At block 610, a threaded conversation item is transmitted to the threaded conversation. In one embodiment, the system does not have a persisting pause action and a threaded conversation item may be transmitted for receipt by all participant(s) in the threaded conversation. The conversation module 240a may be configured to transmit the conversation item, and the item may be received by either the conversation module 240b and/or the conversation modules 240a of each participating client device. In some embodiments, a paused threaded conversation may be unpaused and the threaded conversation item of interest may be transmitted. In one embodiment, a conversation publicly paused may be publicly resumed. In one embodiment, a conversation privately pause may be privately resumed as long as the conversation is not publicly paused. After the threaded conversation item is received, the process continues to decision block 607 to determine receipt of a subsequent pause request.

[0175] At decision block 611, a determination is made as to whether the conversation has ended. If the conversation has not ended, the process continues to decision block 609 to determine if an unpause request was sent. In one implementation, the conversation module 240 may be configured to reevaluate, as described above, whether the conversation has been unpaused. The conversation item may continue to be held either locally on the client device or at the server level. In one embodiment, the conversation item may be held until the system receives an unpause request. If the conversation has ended, the conversation item may not be transmitted, and the method shown in FIG. 6B ends. [0176] FIG. 6C is a flowchart for an exemplary method of muting a threaded conversation in accordance with one embodiment. The method shown in FIG. 6C may be implemented in the conversation module 240 in communication with the database 220 in FIGS. 2A-2B.

[0177] At start point A/B, depending on the outcome of the process of FIG. 6A, a threaded conversation may have been created and a conversation established between two or more users as described in reference to FIG. 6A. The threaded conversation may have been muted or unmuted by one or more of the participants of the conversation. A threaded conversation participant may send a mute or unmute request, and the process thencontinues to block 612.

[0178] At block 612, a mute or unmute request is received. In one embodiment, the conversation module may be configured to receive a mute or unmute request from a user via the admin portal. In one implementation, a mute/unmute command may be initiated in conversation module 240a. In another implementation, conversation module 240a may be configured to transmit a mute/unmute request to conversation module 240b which may be configured to initiate a mute/unmute command. In some embodiments, a user may input a mute/unmute request on client device 110, e.g. by selecting a conversation and selecting a mute option; inputting a mute/unmute option and selecting one or more conversations to apply the selection to, and/or selecting to mute/unmute all conversations with a single action. The user may input the command via a user-interface on the client device 110. Once a mute or unmute command is received by the system, the process continues to block 613.

[0179] At block 613, a threaded conversation item is received. The conversation module 240 may be configured to receive a threaded conversation item from a user. In one embodiment, the conversation item may communicated to conversation module 240 having been input by a user on client device 110. In some embodiments, the conversation module 240 may be configured to prepare the conversation item to be transmitted to the threaded conversation either directly to another user's client device or to server conversation module 240. After having received a threaded conversation item, the process continues to block 614. [0180] At block 614, participants of the threaded conversation are determined. In one embodiment, the participants of the conversation may be determined based on which users are linked to the threaded conversation in database 220. After the conversation participants are determined, the process continues to subprocess 615 for each of the participant(s). For each participant, subprocess 615 continues to decision block 616.

[0181] At decision block 616, a determination is made as to whether the participant's threaded conversation is muted. In one embodiment, conversation module 240 may be configured to send and/or receive notifications or indicators that a particular participant has an existing mute command in effect. In another embodiment, a user device can be configured to display an indicator that the user is muted or not. If the participant's threaded conversation is muted, the subprocess 615 ends for the participant and the process moves to decision block 618. If the participant's threaded conversation is not muted, the subprocess 615 continues to block 617.

[0182] At block 617, the threaded conversation item is transmitted to the participant. In one embodiment, conversation module 240a of the participant's device, having been unmuted or not previously muted, may be configured to receive the conversation item from either another participant's conversation module 240a or server conversation module 240b. Once the threaded conversation item is transmitted to the participant, the subprocess 615 repeats for another participant determined at block 614. This process in block 615 continues until all the determined participants have been processed. Upon completion of subprocess(es) 615, the process continues to decision block 618.

[0183] At decision block 618, a determination is made as to whether the conversation has ended. In one embodiment, the deletion of a threaded conversation by an author may indicate the conversation has ended. In some embodiments, the conversation may be ended by the completion of a transaction of an item for sale, where once the transaction is completed the conversation may be ended. The conversation may be ended by removing the conversation from conversation module 240. If the conversation has not ended, the process continues to block 612 to receive a subsequent mute or unmute request if any. If the conversation has ended, the method shown in FIG. 6C ends. [0184] FIG. 6D is a flowchart for an exemplary method of deleting a threaded conversation by the author of the threaded conversation in accordance with one embodiment. The system may be configured to receive and process a request to delete the entire conversation thread off not just the user's client device, but everyone else's device that was on the thread. The system may be configured to allow deletion requests from the author of the thread, a participant in the thread, or based on another user role defined in relation to the thread. In one embodiment, the communication server 102 may also allow a conversation thread to be deleted from conversation module 240a and/or 240b in accordance with FIG. 6D. Receiving a message to delete a conversation thread may cause the communication server 102 to ensure the user account requesting the deletion is authorized to do so and, if so, transmitting one or more messages to client devices to remove the conversation thread. This allows users a higher degree of control over conversation items.

[0185] At decision block 620, following a determination of that the user is the author of the threaded conversation in accordance with FIG. 6A, a determination is made as to whether a conversation delete request was sent. Conversation module 240 may be configured to receive a delete request from participants of the threaded conversation. In one embodiment, a user may request deletion of a selected conversation. In some embodiments, a user may request deletion of all threaded conversations created by the user. The conversation module 240, via the admin portal, may be configured to receive a user's deletion request. If a conversation delete request is not made by the conversation creator, the process stays at decision block 620. If a conversation delete request is made by a conversation author, the process continues to decision block 621.

[0186] At block 621, the threaded conversation is deleted from database upon the conversation delete request from the author of the threaded conversation. The database may be substantially similar to the database 220 in FIGS. 2A-2B. In one embodiment, the author may be given options to delete the conversation from the database 220, only delete from the author's device, and/or delete from other conversation participants' devices. In some embodiments, a delete request from the author of the threaded conversation may delete the threaded conversation from the database 220 by default. In one embodiment, the client may initiate deletion of a threaded conversation, but the server may maintain the conversation history for a period of time (e.g., 30 days) while flagging the threaded conversation to be deleted. Once the threaded conversation is deleted from the database 220 or flagged as deleted in the database 220, the process continues to block 622.

[0187] At block 622, the threaded conversation is deleted from all conversation participants' devices followed by the conversation author's delete request. In one embodiment, the non-author conversation participants may be given a notification that the conversation was deleted upon the author's request. In some embodiments, the non-author participants may not be given a notification regarding the deleted conversation. Upon deletion of the threaded conversation from all participants' devices, the method of FIG. 6D ends.

[0188] FIG. 6E is a flowchart for an exemplary method of deleting a threaded conversation by a non-author participant of the threaded conversation in accordance with one embodiment. The system may be configured to receive and process a request to delete the entire conversation thread off the user's client device, however such a request may not delete the conversation from all participant devices that are on the thread. In one embodiment, the communication server 102 may also allow a conversation thread to be deleted from conversation module 240a and/or 240b in accordance with FIG. 6E. [0195] At decision block 623, following a determination of that the user is not the author of the threaded conversation in accordance with FIG. 6A, a determination is made as to whether a conversation delete request is sent. Conversation module 240 may be configured to receive a delete request from participant(s) of the threaded conversation. In one embodiment, a user may request deletion of a selected conversation. In some embodiments, a user may request deletion of all threaded conversations that the user is a participant. The conversation module 240, via the admin portal, may be configured to receive a user's deletion request. If a conversation delete request was not made by a conversation participant, the process stays at decision block 623. If a conversation delete request was made by a conversation participant, the process continues to decision block 624.

[0189] At block 624, the threaded conversation is unlinked from the non-author requester's account in the database 220. In one embodiment, the conversation may additionally be deleted only from the non-author's device. In some embodiments, the conversation module 240 may be configured to remove the threaded conversation from a database. The database may be substantially similar to database 220 in FIGS. 2A-2B. Once the non-author requester's account is unlinked from the threaded conversation, the method of FIG. 6E ends.

[0190] FIG. 6F is a flowchart for an exemplary method of initiating the administration features by the author of a threaded conversation in accordance with one embodiment. The conversation administration features, or settings, may allow a user to manage the content and settings associated with a threaded conversation as described in reference to FIGS. 7A-7L. The method shown in FIG. 6F may be implemented in the conversation module 240 in the communication 102 as described with FIGS. 1-2B, 3A, and 3B.

[0191] At start point A, a threaded conversation may be created, a conversation between two or more users may be initiated, and a determination as to the authorship of the threaded conversation may be made as described in FIG. 6A. The creation of a threaded conversation may have been performed via a process substantially similar to that described in reference to FIG. 4. A threaded conversation author may send an edit request and the process then continues to block 624. In one embodiment, the user may send an edit request for a selected threaded conversation, where the administration features adjusted may be applied to only the selected threaded conversation. In some embodiments, the user may apply a single feature selection to one or more threaded conversations via group selection.

[0192] At decision block 624, a determination is made as to whether an edit request was sent. In one embodiment, the conversation module may be configured to receive an edit request from a user via client device 110. If a conversation edit request is not made by the conversation author, the process stays at decision block 624. If a conversation edit request is made by a conversation author or creator, the process continues to point C which is described below with reference to FIGS. 7A-7L. In one embodiment, the edit request may initiate a subsequent user-interface to select administration parameters the user seeks to adjust. In some embodiments, selecting an edit request may initiate a second window or parameter selection subwindow from which the user may select the parameters to adjust.

[0193] The edit request resulting from decision block 624 permits the process to proceed to the threaded conversation administration as detailed further in FIGS. 7A-7L. [0194] FIG. 7 A is a flowchart for an exemplary method of configuring the communication settings of a threaded conversation in accordance with one embodiment. In one embodiment, the process of FIG. 7 A may be implemented following an administration edit request in accordance with FIG. 6F, thus starting at start point C. In some embodiments, the process of FIG. 7A may be implemented as options directly on a user interface of a threaded conversation, as described above in reference to FIGS. 5 A and 5B. The method shown in FIG. 7A may be implemented in the conversation module 240 in the communication server 102 as described in connection with FIGS. 1-2B, 3A, and 3B.

[0195] At decision block 702, a determination is made as to whether a request to configure the communication settings was sent. If a request to configure the communication settings is not made by the conversation author, the process stays at decision block 702. If a request to configure the communications settings is made by the conversation author, the process continues to decision block 704. The configuration request may include a conversation type (e.g., BCC, group conversation, etc.) and one or more participants. In one embodiment, the conversation module 240 may receive additional conversation restrictions from the user. Conversation distribution restrictions may identify one or more of: who (e.g., users, client devices, tagged users, demographic based) can receive the conversation, what recipients can do within the conversation (e.g., reply, forward, and content types permitted to contribute), where the conversation is accessible (e.g., location based conversations), and when the conversation is accessible (e.g., time to live on the system, time to respond, time to send). After the conversation request is received, the process continues to decision block 704.

[0196] At decision block 704, a determination is made as to whether the requested conversation includes blind carbon copy (BCC) as selected by the user. Conversation module 240 may be configured to accept an input by the user selecting BCC. In one embodiment, the BCC option may be chosen where the author wishes participants to be unaware that others are in communication with the author. In some embodiments, the BCC option is selected such that participants may communicate with the author without their communications being shared with other participants in the threaded conversation. If the BCC option is selected, the process continues to block 706. If the BCC option is not selected then participant's replies are visible to all other participants in communication with the author and the process continues to block 708.

[0197] At block 706, viewing of other recipients of the threaded conversation is restricted in response to the selection of the BCC option by the user. In one embodiment, a user may select one or more participants, or all participants, for which the BCC option will apply. Thus, a user may select a subset of participants who may have restricted viewing of the threaded conversation. In some embodiments, at least one or more participants may have the BCC option applied to their participation in the threaded conversation while one or more participants may not have the BCC option applied. After the viewing of the recipients is restricted, the process continues to decision block 708.

[0198] At decision block 708, a determination is made as to whether the requested conversation is in a broadcast mode as chosen by the author. Conversation module 240 may be configured to accept an input by the user selecting broadcast mode. The broadcast mode may allow the user to establish a one-way threaded conversation and send out a conversation item to other users while not allowing the recipients to reply back to the user's conversation item. If the requested conversation is in the broadcast mode, the process continues to block 710. If the requested conversation is not in the broadcast mode, the threaded conversation may operate in two-way communication with participants, and the process continues to decision block 712. Two-way communication may permit the user and participants to send conversation items to the threaded conversation and for each to reply in turn.

[0199] At block 710, the recipients of the threaded conversation in the broadcast mode are restricted from replying in the threaded conversation. In one embodiment, a user may select one or more participants, or all participants, for which the broadcast mode option will apply. Thus, a user may select a subset of participants who may have restricted accessing to transmitting a conversation item to the threaded conversation. In some embodiments, at least one or more participants may have the broadcast mode option applied to their participation in the threaded conversation while one or more participants may not have the broadcast mode option applied. After the recipients' replying options are restricted, the process continues to decision block 712. [0200] At decision block 712, a determination is made as to whether the requested conversation is in a locked mode. The locked mode may allow the user to establish a locked threaded conversation with the recipients. Conversation module 240 may be configured to accept an input by the user selecting to lock the conversation. In one embodiment, in the locked mode, the recipients are restricted from adding any more participants to the conversation. In some embodiments, if the threaded conversation is in locked mode, the participants of the threaded conversation are disallowed from searching on a tag associated with the conversation and being permitted to view or participate in the threaded conversation. If the requested conversation is in the locked mode, the process continues to block 714. If the requested conversation is not in the locked mode, the process continues to block 716.

[0201] At block 714, the recipients of the threaded conversation in the locked mode are restricted from adding new participants. In one embodiment, a user may select one or more participants, or all participants, for which locked mode option will apply. Thus, a user may select a subset of participants who may have restricted ability to add new participants. In some embodiments, at least one or more participants may have the locked mode option applied to their participation in the threaded conversation while one or more participants may not have the locked mode option applied. After adding new participants is restricted, the process continues to block 716.

[0202] At block 716, a threaded conversation is updated, reflecting one or more conversation restrictions, if any, created. The threaded conversation may be update in device conversation module 240a and/or server conversation module 240b. The threaded conversation may or may not have one or more restrictions described above in connection with the method shown in FIG. 7 A. After the threaded conversation reflecting the user's choices is created, the process ends.

[0203] FIG. 7B is a functional block diagram of an exemplary content management module of the threaded conversation administration system in accordance with one embodiment. In one embodiment, an author of a threaded conversation may implement the content management module 718 after accessing the threaded conversation administration options. Content management module 718 may be implemented in client device 110. The content management module may be configured to provide adding, editing, and deleting of a variety of media formats. For example, the media formats that may be, but are not limited to, photographs, textual and written media, audio media formats, and video formats, among other digital media. The author may access the content management module to add, delete, or edit media that is posted on the threaded conversation. In one embodiment, the author may be able to add, delete, or edit media uploaded by the author. In some embodiments, the author may be able to add, delete, or edit media regardless of the source, e.g. other participants. In some embodiments, non-author participants of the threaded conversation may be permitted to add, delete, or edit media content on the threaded conversation. In some embodiments, a user may be able to delete or edit the media that user personally added to the conversation.

[0204] FIG. 7C is a flowchart for an exemplary method of configuring tags associated with a threaded conversation in accordance with one embodiment. An author may add tags to the conversation to drive traffic and other users to the threaded conversation. In one embodiment the author may search for a free tag and apply a free tag to the conversation. In some embodiments, the author may search for tags having allocation constraints, e.g. fee- based tags, and apply the fee-based tag to the conversation. In one embodiment, the fee-based tags may be purchased from a tags marketplace, as described in reference to FIG. 9. In some embodiments, the user may select public and/or private tags to allocate to the threaded conversation. The method shown in FIG. 7C may be implemented, for example, in the conversation module 240, the tagging module 210, or the tag marketplace module 280 in the communication server 102 as described in connection with FIGS. 1-2B, 3A, and 3B.

[0205] At decision block 720, a determination is made as to whether a request to add a tag was made. In one embodiment, a user may select to edit the administration settings of a threaded conversation in accordance with FIG. 6F, thereby starting the process of FIG. 7C at start point C. In some embodiments, a user may select tags to associate or allocate to a threaded conversation upon creating the conversation prior to entering administration settings selection. If a request to add a tag is not made by the conversation author, the process stays at decision block 720. If a request to add a tag is made by the conversation author, the process continues to decision block 721. In one embodiment, the request to add a tag may take place after searching for available tags. In some embodiments, the request to add a tag may occur before searching for available tags. After the add tag request is received, the process continues to decision block 721.

[0206] At block 721, the user selects the tag or tags to be added to the threaded conversation. In one embodiment, a user may select known tags, such tags may be selected from, e.g., a list, index, archive, etc. In some embodiments, a user may search for a tag via a process substantially similar to that described in reference to FIG. 4. The user may search database 220 by tag, keywords, or phrase. The search may return tags that are related or substantially similar to the searched phrase, and the user may, via a user interface, select one or more of the tags to be added to the threaded conversation. After the tags are selected by the user, the process continues to decision block 722.

[0207] At decision block 722, a determination is made as to whether the tags selected to be added to the conversation are free tags or fee-based tags. In one embodiment, the determination of whether a tag is free or fee-based may be performed by a process substantially similar to that described in reference to FIG. 8 and 9. If the tag selected is not a free tag, then the process continues to the tag market place where the user may purchase a tag, in accordance with the process in FIG. 9. In one embodiment, if the user purchases a tag, then the process continues to block 723. If the tag selected is a free tag, the process continues to block 723.

[0208] At block 723, the tag may be applied to the conversation. In one embodiment tagging module 210 may be configured to receive tags from block 722 and/or 723 and associate the tags to a threaded conversation. In some embodiments, tagging module 210 may be configured to communicate with database 220 to conduct tag verification and association with the threaded conversation. In one embodiment, the user may be requested by the system to verify that the tag is the one intended by the user to be associated with the threaded conversation. After the tag is applied to the threaded conversation, the process continues to block 724.

[0209] At block 724, a threaded conversation is updated, reflecting any tags, if any, which have been associated with the threaded conversation. The threaded conversation may be update in conversation module 240 and/or database 220. After the threaded conversation reflecting the user's choices is created, the process ends. [0210] In one exemplary embodiment, the threaded conversation administration system may allow a user to search the contact list stored on the user's personal device for private tags that the user assigned to other users. In some embodiments, the user may search system wide for public tags that other users have chosen to be associated with their profiles. In yet some embodiments, the user may select one or more other users from the either a public or private tag search and add these users as participants to a threaded conversation. FIG. 4, as previously discussed, illustrates this process in more detail.

[0211] FIG.7D and 7E are flowcharts for an exemplary methods of adding (FIG. 7D) or removing (FIG. 7E) participants from a threaded conversation in accordance with one embodiment. In one embodiment, the method of adding a user may be in the form of an invitation or pop-up requesting the user to join a selected threaded conversation. In some embodiments the method of adding or removing a participant may be automatic upon initiating the request to add or remove a selected participant. The methods shown in FIG. 7D and 7E may be implemented in the conversation module 240 in the communication server 102 as described in connection with FIGS. 1-2B, 3A, and 3B.

[0212] In FIG. 7D, at decision block 730, a determination is made as to whether the user has requested to add a participant. In one embodiment, a request to add a participant may be done following a search for public or private tags as detailed in FIG. 4. In some embodiments, a request to add a participant may be made independent of a tag search. In some embodiments, a request to add a participant may be made by a user identifying a single contact by name or selecting from a list of contacts, independent of tags associated with the added participant. In some embodiments, a user may request to add one or more participants, for example by selecting multiple users and requesting the multiple users be added as a group. If a request to add a participant is not made, the process remains at block 730. If a request to add a participant is made, the process continues to decision block 731. In one embodiment, the request to add a participant may be made prior to selecting the particular participant to be added, for example by selecting the "add participant" option on a user interface. The user may then select one or more users to add to the threaded conversation. In some embodiments, the request to add a participant may be made following the selection of the particular participant to be added. For example, a user may select a contact, which may cause a menu selection interface to open having at least the option to add the particular user to a threaded conversation.

[0213] At decision block 731, a determination ismade as to whether an invitation is required before adding the selected user. In one embodiment, a threaded conversation may require an invitation, and may be enabled in the administration settings. In some embodiments, a non-author participant may select to require invitations, either require invitations when added as a participant or require invitations when adding a participant. The conversation module 240 may be configured to accept the invitation requirement as set in the administration settings. If an invitation is not required, the process continues to block 735 and adds the participant to the conversation. If an invitation is required, the process continues to block 732.

[0214] At block 732, an invitation is sent to the participant being added to the conversation. An invitation may be in the form of an email notification requesting a user to accept the invitation, sent by, e.g., the conversation module 240. In some embodiments, the invitation may be in the form of a pop-up or banner notification, wherein the user may then choose to immediately accept, reject, or wait to act on the invitation. In some embodiments, a use may request to add one or more users in a single request, and the system may send a default invitation to each participant. The user may request to customize an invitation for each participant, or the user may select a default invitation be sent to each participant. In this way, a user may send one or more invitations instantaneously upon selecting one or more participants to add to the threaded conversation. After the one or more invitations are sent, the process continues to block 734.

[0215] At block 734, a determination is made as to whether the invited participant has accepted the invitation. In one embodiment, the conversation module 240 may be configured to receive an acceptance notification or identifier from the invited participant's client device or from the server via the invited participant's client device. If the invited participant has not accepted the invitation, the process remains at block 734. If the invited participant has accepted the invitation, the process continues to block 735. At block 735, the participant is added to the threaded conversation. For example, the participant's credentials or user profile may be added to database 220 and associated through the conversation module 240 to the threaded conversation. Each participant may have different communication settings based on the communication settings selected by the author in accordance with FIG. 7A as detailed above.

[0216] In FIG. 7E, a determination is made as to whether the user has requested to remove one or more participants. If the user has not requested to remove a participant, then the process remains at block 740. In one embodiment, the request to remove a participant may be made prior to selecting the particular participant to be removed. In some embodiments, the request to remove a participant may be made following the selection of the particular participant to be removed. In some embodiments, a user may search a list of participants of the threaded conversation displayed on a user interface displaying. The user may select one or multiple participants from the displayed list via the user interface. The system may present the user with a variety of options or actions the user is permitted to perform related to the selected participants, one of which may be a remove the selected participant from conversation option. The user may then select to remove the one or more participants from the conversation.

[0217] In one embodiment, the user may have previously selected one or more users to remove from the threaded conversation prior to block 740. Where the request to remove a participant is performed by a user after selecting one or more participants, the process proceeds to block 744. In some embodiments, if the user has requested to remove a participant, in the process where decision block 740 occurs prior to selecting a particular user, the process continues to block 741. At block 741, the user's device may retrieve a list of contacts, tags, and/or other users that are participating in the conversation. The list of contacts may be retrieved from conversation module 240 and/or database 220 in conjunction with conversation module 240. The list may then be displayed to the user via a client device. This list may display participants in the threaded conversation from which the user may select one or more to remove from the conversation. When the user is prepared to select the participant(s) to remove, the process continues to block 742. At determination block 742, a determination is made whether the user has selected all participants sought to be removed. In one embodiment, the system may issue a verification that the user has finished selecting participants to be removed. For example, the verification may be a pop-up that the user may respond to before removing participants. If the user has not completed selecting the participants to be removed, the process remains at block 742. If the user has selected the participants to be removed, the process continues to block 744 where the participants may be removed from the threaded conversation. In one embodiment, the removed persons will immediately be unable to partake in the threaded conversation.

[0218] FIG.7F is a flowchart for an exemplary method of configuring a user's privacy settings in accordance with one embodiment. In one embodiment, a user may setup privacy settings, for example but not limited to, email addresses, phone numbers, physical addresses, or other personal information. In some embodiments, a user may select to share the privacy information with other participants in the threaded conversation, for example by hiding or displaying selected personal information. In some embodiments, the user may choose specific participants with whom the user would like to share personal information. The method shown in FIG. 7F may be implemented in the conversation module 240 in the communication server 102 as described in connection with FIGS. 1-2B, 3A, and 3B.

[0219] At decision block 750, a determination is made as to whether there was a request to configure the privacy settings. A request to configure the privacy settings may be made by the user accessing the privacy settings via the administration portal as described in reference to FIG. 6F. If a request to configure the privacy settings is not made, the process stays at decision block 750. If a request to configure the privacy settings is made, the process continues to decision block 751. The configuration request may include a personal information type (e.g., email address, phone number, physical address, etc.) and one or more participants. In one embodiment, the conversation module 240 may receive a request to configure personal information from the user. The personal information may be stored in the memory 292 and be displayed in association with a threaded conversation. In some embodiments, the personal information may be in a user profile, which participants of the threaded conversation may be permitted to view. After the configuration request is received, the process continues to decision block 751.

[0220] At decision block 751, a determination is made as to whether a user selected to add an email address. In one embodiment, a user may enter an email address in the privacy settings associated with the threaded conversation. The conversation module 240 may be configured to accept a user input of an email address, where the user has accessed the privacy configurations via the admin portal. If the email address option is selected by the user, the process continues to block 752. If the option is not selected then the process continues to block 754. In some embodiments, the system may already have an email address stored in memory 292 for the user. The conversation module may be configured to access the user profile and display the email address for the selected threaded conversation. Decision block 751 may then determine that an email address is already present and the process continues to block 752.

[0221] At decision block 752, the user may select to hide the email address. In one embodiment, the hide email address option may be chosen where the user wishes participants to be unaware of the user's email address, e.g., the user wishes the email address be hidden from other participants of the conversation. If the hide option is selected, then the process continues to block 753. In one embodiment, the user's email address stored in the system may be hidden from view by the participants of the threaded conversation. A user may select to have an email hidden in select conversations and viewable in other conversations. This may be the case where a user is a merely a participant in a conversation or the conversation is unlocked such that anyone may be a participant. The user may wish to restrict or control those other users who have access to personal information, to keep them from accessing the user's personal information. At block 753 the email address is hidden such that other participants may not view or retrieve the email address. In one embodiment, a user may select to hide an email address in all conversations such that it is globally unavailable. In some embodiments, the user may select hide an email address in select conversations. Once the email address is hidden, the process continues to decision block 754.

[0222] At decision block 754, a determination is made as to whether a user selected to add a phone number. In one embodiment, a user may enter a phone number in the privacy settings associated with the threaded conversation. The conversation module 240 may be configured to accept a user input of a phone number, where the user has accessed the privacy configurations via the admin portal. If the phone number option is selected by the user, the process continues to block 755. If the option is not selected then the process continues to block 757. In some embodiments, the system already has a phone number stored for the user. The conversation module may be configured to access the user profile and display the phone number for the selected threaded conversation. Decision block 754 may then determine that a phone number is already present and the process continues to block 755.

[0223] At decision block 755, the user may select to hide the phone number. In one embodiment, the hide phone number option may be chosen where the user wishes participants to be unaware of the user's phone number, e.g., the user wishes the phone number be hidden from other participants of the conversation. If the hide option is selected, then the process continues to block 756. In one embodiment, the user's phone number stored in the system may be hidden from view by the participants of the threaded conversation. A user may select to have a phone number hidden in selected conversations but viewable in other conversations. This may be the case where a user is a merely a participant in a conversation or the conversation is unlocked such that anyone may be a participant. The user may wish to restrict or control those other users who have access to personal information, to keep them from accessing the user's personal information. At block 756 the phone number is hidden such that other participants may not view or retrieve the phone number. In one embodiment, a user may select to hide a phone number in all conversations such that it is globally unavailable. In some embodiments, the user may select hide a phone number in select conversations. Once the phone number is hidden, the process continues to decision block 757.

[0224] At decision block 757, a determination is made as to whether a user selected to add a physical address. In one embodiment, a user may enter a physical address in the privacy settings associated with the threaded conversation. The conversation module 240 may be configured to accept a user input of a physical address, where the user has accessed the privacy configurations via the admin portal. If the physical address option is selected by the user, the process continues to block 758. If the option is not selected then the process continues to block 760. In some embodiments, the system already has a physical address stored for the user. The conversation module may be configured to access the user profile and display the physical address for the selected threaded conversation. Decision block 757 may then determine that a physical address is already present and the process continues to block 758.

[0225] At decision block 758, the user may select to hide the physical address. In one embodiment, the hide physical address option may be chosen where the user wishes participants to be unaware of the user's physical address, e.g., the user wishes the address be hidden from other participants of the conversation. If the hide option is selected, then the process continues to block 759. In one embodiment, the user's physical address stored in the system may be hidden from view by the participants of the threaded conversation. A user may select to have a physical address hidden in selected conversations but viewable in other conversations. This may be the case where a user is a merely a participant in a conversation or the conversation is unlocked such that anyone may be a participant. The user may wish to restrict or control those other users who have access to personal information, to keep them from accessing the user's personal information. At block 759 the physical address is hidden such that other participants may not view or retrieve the physical address. In one embodiment, a user may select to hide a physical address in all conversations such that it is globally unavailable. In some embodiments, the user may select hide a physical address in select conversations. Once the physical address is hidden, the process continues to decision block 760.

[0226] At decision block 760, a determination is made as to whether a user selected to add any other personal information. In one embodiment, a user may enter personal information in the privacy settings associated with the threaded conversation. The conversation module 240 may be configured to accept a user input of personal information, where the user has accessed the privacy configurations via the admin portal. If the other personal information option is selected by a user, the process continues to block 761. If the option is not selected then the process continues to block 763. In some embodiments, the system already has personal information stored for the user. The conversation module may be configured to access the user profile and display the personal information for the selected threaded conversation. Decision block 760 may then determine that personal information is already present and the process continues to block 761.

[0227] At decision block 761, the user may select to hide the other personal information. In one embodiment, the other personal information option may be chosen where the user wishes hide participants to be unaware of the user's other personal information, e.g., the user wishes the other personal information address be hidden from other participants of the conversation. If the hide option is selected, then the process continues to block 762. In one embodiment, the user's personal information stored in the system may be hidden from view by the participants of the threaded conversation. A user may select to have personal information hidden in selected conversations but viewable in other conversations. This may be the case where a user is a merely a participant in a conversation or the conversation is unlocked such that anyone may be a participant. The user may wish to restrict or control those other users who have access to personal information, to keep them from accessing the user's personal information. At block 762 the other personal information is hidden such that other participants may not view or retrieve the other personal information. In one embodiment, a user may select to hide personal information in all conversations such that it is globally unavailable. In some embodiments, the user may select hide personal information in select conversations. Once the other personal information is hidden, the process continues to decision block 763.

[0228] At block 763, a threaded conversation is updated, reflecting one or more privacy settings, if any, added. The privacy settings may be update in conversation module 240, database 220, and/or memory 292. The threaded conversation may or may not have one or more privacy settings described above in connection with the method shown in FIG. 7F. After the threaded conversation reflecting the user's choices is created, the process ends.

[0229] FIG.7G is a flowchart for an exemplary method of configuring a user's geographic location ("geo-location") preferences in accordance with one embodiment. In one embodiment, a user is able to configure geo-location information preferences to allow the participants of the threaded conversation to view the user's geo-location. In some embodiments, the geo-location may be updated in real-time, or instantly within the threaded conversation, for example, geo-location information such as GPS coordinates of the client device used to access the system. The client device may be configured to accept the GPS location and update the geo-location displayed in the threaded conversation. In some embodiments, the geo-location information may be viewable by the participants of the threaded conversation for the life of the conversation. The method shown in FIG. 7G may be implemented in the conversation module 240 in the communication server 102 as described in connection with FIGS. 1-2B, 3 A, and 3B. [0230] At decision block 764, a determination is made as to whether the user selected to display the geo-location information to participants of the threaded conversation. In one embodiment, a user may access the administration feature through, for example, a user interface, and select to activate the geo-location feature. If a request to display the geo- location information is not made, the process stays at decision block 764. If a request to display the geo-location information is made, the process continues to block 777.

[0231] At block 777, the process enables displaying geo-location information. In one embodiment, the GPS coordinates of the client device are transmitted to the conversation module 240. The conversation module 240 may be configured to display the geo-location within the threaded conversation. In one embodiment, the geo-location of the device may be updated instantaneously with the GPS coordinates of the device. In some embodiments, the geo-location may be set to update at select time intervals, in this way the system may avoid energy depletion due to consistently updating GPS location. In one embodiment, the user may select to enable geo-location display on one or more threaded conversations. In some embodiments, the user may select to enable geo-location display on all threaded conversations that the user is a participant. In some embodiments, the user may select to enable displaying geo-location for the threaded conversations the user created. Once the geo-location display is enabled, the process continues to block 765.

[0232] At block 765, a threaded conversation is updated, reflecting the geo- location information preferences if selected. The geo-location settings may be update in conversation module 240 in conjunction with the communication server 102 and GPS locator of the client device. The threaded conversation may or may not have the geo-location described above in connection with the method shown in FIG. 7G. After the threaded conversation reflecting the user's choices is created, the process ends.

[0233] FIG. 7H is a flowchart for an exemplary method of adding an item or service for sale on a threaded conversation. In one embodiment, a user may be able to configure the threaded conversation to permit items or services to be added for sale within the threaded conversation. In some embodiments, the user may set a specific fixed price. In some embodiments, the user may be able to configure sales settings to allow bidding through an auction sale. For example a user may select a minimum price and participants of the threaded conversation may bid the price higher for that particular item. In some embodiments, the user may select a bargaining system, where the user selects an initial price and participants of the threaded conversation negotiate with the user to reach a mutually agreed upon price. In some embodiments, enabling the selling an item through the threaded conversation (FIG. 7H) may be combined with enabling financial transactions (FIG. 71). In an embodiment where transactions are permitted, a user may pay for an item without leaving the threaded conversation. The method shown in FIG. 7H may be implemented in the conversation module 240 and/or the transaction module 260 in the communication server 102 or transaction processing module 106 as described in connection with FIGS. 1-2B, 3A, and 3B.

[0234] For example, a user may want to sell baseball tickets for $200. The user may add the item to an existing threaded conversation or start a new threaded conversation related to the sale. The use may enable bidding, bargaining, or set the price fixed at $200. In some embodiments, the user may enable financial transactions, to permit the tickets to be sold over the threaded conversation such that the purchaser and seller may avoid having to locate another avenue effectuate the exchange. In some embodiments, financial transaction may be handled by system herein, by permitting a dynamic selection of payment processing systems (e.g., PayPal, Apple app, Store, Android app store, etc.). In some implementations, the transactions may be performed by a remittance and/or payment processing server such as an e- wallet, a bank, an automated clearing house, an online money transfer service, or a digital currency exchange as described above in reference to FIGS. 1-2B.

[0235] At decision block 766, a determination is made whether a user has requested an item be added for sale to the threaded conversation. If a user did not request to add an item for sale, then the process remains at block 766. If a request to add an item for sale was made, the process continues to block 767. In one embodiment, a user may create a new threaded conversation based on the item for sale. In some embodiments, the user may access a threaded conversation already managed by conversation module 240 and select an item to be posted for sale on the existing conversation. The conversation module 240 may be configured to recognize the request by the user and determine that the user wishes to add an item for sale, then the process continues to block 767. [0236] At block 767, an item for sale is added to the threaded conversation. In one embodiment, the user may post a description of the item for sale in a way in accordance with communicating in the threaded conversation. In some embodiments, the item may be added by posting a video, photo, text, or audio file via communication with the content management module 718. The information related to the item for sale may be added, deleted or edited by the user as described above in connection with the content management module 718. The user may access the content management module 718, as described above in reference to FIG. 7B, to add content related to the item. The content management module 718 may communicate with conversation module 240 to add the item to the selected threaded conversation. Once the item is added to the threaded conversation, the process continues to decision block 768.

[0237] At decision block 768, a determination is made as to whether the user selected bidding or auction style of sale. In one embodiment, a user may select from the bidding option drop-down menu or a pop-up menu. In some embodiments, the system may make bidding a default method of pricing or a set price may be default. The user may then access a settings option, for example in the content management module 718 or administration settings to edit the content and/or to change the pricing option. If bidding style has not been selected, the process continues to block 770 where the user may set a price for the item for sale by inputting the selected price into the conversation thread. In some embodiments, the user may announce the price in a threaded conversation. In some embodiments, the user may input a price under the edit content option of the content management module 718. In one embodiment, this price may be a fixed price. In some embodiments, this price may be a negotiable between participants in the threaded conversation.

[0238] If the user selects bidding style, the process continues to block 769. The conversation module 240 may be configured to accept a user input or selection of bidding/auction sale and manage the threaded conversation to account for the user selection. At block 769, the user selects a minimum price. The user may set a minimum price by inputting the selected price into the conversation thread. In some embodiments, the user may announce the minimum price in a threaded conversation. In some embodiments, the user may input a minimum price under the edit content option of the content management module 718. In one implementation, participants of the threaded conversation may update the conversation with bids, or incremental increases in offered price, until the author closes the auction accepting the highest offered price. Once a price has been set in either block 770 or block 769, the process concludes by adding the item for sale on the threaded conversation.

[0239] FIG. 71 is a flowchart for an exemplary method of enabling financial transactions in accordance with one embodiment. The method shown in FIG. 71 may be implemented in the conversation module 240 and/or the transaction module 260 in the communication server 102 or transaction processing module 106 as described in connection with FIGS. 1-2B, 3A, and 3B. In some implementations, the transactions may be performed by a remittance and/or payment processing server such as an e-wallet, a bank, an automated clearing house, an online money transfer service, or a digital currency exchange as described above in reference to FIGS. 1-2B. The method shown in FIG. 71 may be implemented when the Threadsite administrator is purchasing an item and/or when the Threadsite administrator is selling an item. Where a Threadsite administrator is purchasing an item, the method shown in FIG. 71 can send payment. Alternatively, where a Threadsite administrator is selling an item, the method shown in FIG. 71 can receive payment.

[0240] At decision block 771, a determination is made as to whether the user selected to enable financial transactions. As the user communicates with one or more other users through the conversation thread, the user may decide to transact with one of the participants for, e.g., an item posted for sale in accordance with FIG. 7H. In one embodiment, the user may create a transaction channel associated with the conversation thread. In one embodiment, the conversation thread may have embedded transaction options for the user to choose from. In some embodiments, a transaction channel may have been created when the conversation was tagged by the user or other participants as a transactional thread. In one embodiment, the user may be prompted to add the amount of money to be exchanged and the method of exchanging money. In some embodiments, the transactional information (e.g., amount of money, method of payment, etc.) may be prepopulated based on the conversation among the participants in the conversation thread and/or one or more conversation threads. In one embodiment, the user may be prompted to edit transaction information and/or add additional information (e.g., place to meet, delivery method, return or exchange policy information, customer service, information, promotional information, discounts, etc.) in connection with the transaction. If the user has not selected to enable financial transactions, the process remains at block 771. If a user has selected to enable financial transactions in the threaded conversation, then the process continues to block 772. In one embodiment, the conversation module 240 may be configured to accept a user input and/or request to enable transactions. In some embodiments, the conversation module 240 may communicate with transaction module 260 to enable transactions.

[0241] At block 772, a user selects made a method of payment. The system may be configured to consummate transactions for one or more users of the system. In one embodiment, the transaction module 260 may be so configured. The transactions may be consummated in conjunction with the various communication features described above. One type of transaction may be a mobile payment. Payment credentials or information such as payment card information or digital wallet information may be stored in the network. This allows the payment information to be retained outside the client device (e.g., phone). The payment transaction aspects of the system may be configured to utilize encryption and/or tokenization to protect information needed to effect the payment such as card information, confirmation codes, personal identification numbers (PINs), passwords, personal identification information (e.g., date of birth, social security number, etc.), and the like. In some implementations, the system may include features to identify card-present rates for transactions at a rate that depends on physical presentation of card such as to a reader. For example, a beacon may be provided which is configured to acquire payment information. The payment transactions may be configured to integrate with payment networks or payment processing entities such as Europay, MasterCard, Visa (EMV) (a.k.a. "chip and pin") systems, and/or dynamic processing system (e.g., PayPal, Apple app, Store, Android app store, etc.), as described above. In some implementations, transaction may include authorization by, for example, a PIN, one-time password (OTP), biometric information, bank-to-bank authorization, peer-to-peer (P2P) authorization, and the like. The system may receive the authorization information from a client device. The authorization information is then securely transmitted to the central server for processing payments such as via automated clearing house (ACH). After a method of payment is selected, the process continues to decision block 773. [0242] At decision block 773, a determination is made whether merchant account information is stored in the system. In one embodiment, the transaction module 260 may be configured to receive payment information and transmit the received information for processing or payment remittance. The payment information received by the transaction module 260 may include username, account number, password, personal identification number, and the like. In some embodiments, the merchant account information may be any credentials required by the system to enable the exchange over transaction module 260 as described above. In one embodiment, the transaction module may access memory 292 and/or database 220 and determine whether merchant information is located on the client device. If merchant account information is already stored on the system then the process continues to block 774, the transaction is consummated as detailed below, and process concludes. If merchant account information is not located, the process continues to block 775.

[0243] At block 775, the user is prompted to add merchant account information. The user may be required to add payment information to enable processing or payment remittance as detailed in the preceding paragraphs. Merchant account information may be stored in memory 292, conversation module 240, and/or database 220. In one embodiment, the user may be prompted to add merchant account information through a user interface of a mobile device. In some embodiments, the merchant account information may be located in a separate device or server, and the user may establish a connection between client device 110 and the separate merchant device or server. The established connection may permit the exchange of merchant account information. Once merchant account information is added the process continues to block 774, the transaction is consummated, and the process concludes.

[0244] In one embodiment, the transaction may be consummated by a communication server 102 having a transaction processing module 106 (FIG. 1). The transaction processing module 106 may be configured to perform payment processing or payment remittance. The transaction processing module 106 may be configured to consummate the transaction. In some implementations, the transaction processing module 106 may be configured to communicate with a third party transaction server 150 to consummate the transaction. The third party transaction server 150 may be, in some implementations, a remittance and/or payment processing server such as an e-wallet, a bank, an automated clearing house, an online money transfer service, or a digital currency exchange.

[0245] In some embodiments, the third party transaction server 150 may be configured to send a confirmation code or a receipt number upon completion of the transaction. In one embodiment, more than one server may be involved in the transaction to consummate the transaction. In one embodiment, the transaction module 260 may be configured to receive a transaction unsuccessful message through the network 190, and there may be one or more following messages between the transaction module 260, client device 110, and/or third party servers 150 (FIG. 1) to complete a successful transaction. In one embodiment, the transaction may not need a third party server, and the entirety of the transaction may be consummated within the communication server 102 (FIG. 1). In one embodiment, the transaction module 260 implemented in the client device 110 (FIG. 1) may transmit a transaction request to a server by means of the network 190 for processing without requiring that a response (successful or unsuccessful) being received by the transaction module 260 implemented in the client device 110 (FIG. 1) from the network 190 in order to finalize the transaction.

[0246] Transaction module 260 may be configured to send a transaction complete report to the client device 110 in response to the transaction request of the user of the client device 110. Upon completion of a successful transaction, the transaction module 260 may have obtained a confirmation code or a receipt number of the completed transaction. The transaction module 260 may forward that information to the client device 110 for further reference for the user of the client device 110. The transaction module 260 may also send to the client device a message confirming the additional information exchanged between the conversation participants associate with the transaction, such as place to meet, delivery method, return or exchange policy information, customer service, information, promotional information, discounts, etc. Upon receiving the transaction complete message, the client device 110 may further prompt the user to set up an appointment or a reminder for the user based on the additional transaction information (e.g., delivery estimate date reminder, time and place to meet, promotion expiration date reminder, return or exchange expiration date reminder, etc.). [0247] FIG. 7J is a flowchart for an exemplary method of enabling proximity offers in accordance with one embodiment. As described above in reference to FIGS. 2 A and 2B, a demand may be provided by content/offer module 270. The demand may be based on proximity sensing via iBeacon integration. For example, a merchant may deploy a beacon within a store. In one embodiment, a merchant may already manage a threaded communication with a customer, and the merchant may communicate a proximity offer to the customer via a beacon. The method shown in FIG. 7J may be implemented in the conversation module 240, content/offer module 270, and filtering module 254 in the communication server 102 as described in connection with FIGS. 1-2B.

[0248] At start point C, a threaded conversation participant, as established in accordance with FIG. 6F, is sent a request to enable proximity offers and the process continues to decision block 776. The request to enable transmission of proximity offers may be transmitted to the conversation module 240 through a user interface of client device 110 by the merchant participant. In some embodiments, the customer participant may enable receiving of proximity offers within the threaded conversation via the client device 110. In one embodiment, a customer participant may not receive transmitted proximity offers unless the customer participant has enabled the reception of such offers.

[0249] At block 776, a request to enable proximity offers is received. In one embodiment, the conversation module 240 and/or content/offer module 270 may be configured to receive a request to enable proximity offers from user input via the administration settings accessed in accordance with FIG. 6F. If a request to enable proximity offers was not made, then the process remains at block 776. If a request to enable proximity offers was made, the process continues to block 778.

[0250] At block 778, content or offers are transmitted to the beacon. In one embodiment, the transmitted content may include identification information for the participant device intended to receive the content or offer, for a user of the device, and/or for an account associated with the device. In some embodiments, a merchant may initiate an offer which may be transmitted by the conversation module 240 to the beacon. After the transmission is sent to the beacon, the process continues to block 793. [0251] At block 793, participants of the threaded conversation are determined. In one embodiment, the participants of the conversation may be determined based on which users are linked to the threaded conversation in database 220. After the conversation participants are determined, the process continues to subprocess 794 for each of the participant determined. For each participant, subprocess 794 continues to decision block 795.

[0252] At decision block 795, a determination is made as to whether a user device has entered the coverage area for the beacon. In one embodiment, as a customer holding a wireless device (e.g., smartphone, tablet computer) enters a coverage area for the beacon, the wireless device may transmit information to the beacon notifying the beacon that the particular participant of the threaded conversation has entered the coverage area. If the participant has not entered the coverage area the process ends for that participant and the offer may not transmitted. If the participant has entered the coverage area, the process continues to decision block 796.

[0253] At decision block 796, a determination is made as to whether the participant has enabled the accepting of proximity offers on the client device. In one embodiment, the user may be required to enable the receiving of proximity offers to permit the merchant to transmit proximity offers to that participant. In some embodiments, the user may receive proximity offers unless the user has deactivated the feature in the client device. In one embodiment, to allow client devices to control the flow of information from beacons, filtering module 254 may configured to receive beacon conversation items in a conversation thread, such as coupons or offers, and selectively process the received conversation items. The selective processing may be based on rules stored in the database 220. A rule may identify beacons sources which the client device will receive beacon conversation items from. Beacon sources may be identified by a unique identifier associated with the entity responsible for deploying the beacon (e.g., merchant). A rule may identify communication types to receive via beacon conversation items. For example, a rule may accept offers from merchants or brands associated with specified tag information. The content of the conversation item may also be limited such as by media type included in the conversation item. This allows the client device to manage resource usage during discovery by dynamically adjusting the content it can/will handle based on available resources (e.g., power, processing, memory, bandwidth). If the client device is not configured to accept the particular proximity offer, the process ends and the offer is not be transmitted. If the client device is configured to accept the particular proximity offer, the process continues to block 797.

[0254] At block 797, the beacon receives this information and transmits the information to the content/offer module 107 to receive a customized offer for the user. The customization may be based on the information provided by the wireless device. In one embodiment, the user may not have previously established a personal account with the communication server 102. In such cases, information about the device such as the media access control identifier may be used to determine characteristics of the device holder. Characteristics may include device type, device model, and device interactions (e.g., with this or other beacons). In some circumstances, the user may have previously established a personal account with the communication server 102. In doing so, the user may have provided tags describing themselves to the world (e.g., self discovery tag). The user may also be associated with private tags assigned by the merchant (e.g., self-tagging tags). In such cases, the additional tag data may be used to further select an appropriate offer for the user. Once the proximity offer is transmitted to the participant, the subprocess 794 repeats for another participant determined at block 793 until the subprocess 794 is ran for all the determined participants and the process ends.

[0255] FIG. 7K is a flowchart of an exemplary method of setting up automatic expiration or automatic deletion for the threaded conversation. In one embodiment, an author of a threaded conversation may select a date and/or time for a selected threaded conversation to expire. In one embodiment, once the set date/time occurs the threaded conversation may be cleared from database 220 and may be deleted from the device database of all participating users. In some embodiments, an automatic deletion may only remove the threaded conversation from the user's device and may maintain the threaded conversation for participation by others. The method shown in FIG. 7K may be implemented in conversation module 240 in communication with database 220 in FIGS. 1-2B.

[0256] At determination block 779, a determination is made whether the user has selected to setup automatic expiration. In one embodiment, a user may select to setup a time deletion by accessing the administration features in accordance with FIG. 6F. In some embodiments, the conversation module 240 may be configured to accept a user request for timed deletion via input on a user interface. If the user has not selected to setup automatic expiration, the process remains at block 779. If the user has selected to setup automatic expiration, the process continues to block 780. In one embodiment a user may select to setup automatic expiration for a selected threaded conversation. In some embodiments a user may select multiple threaded conversations to be removed at a set date and time.

[0257] At block 780, the user sets up a data and/or time for when automatic expiration of the threaded conversation is to take place. In one embodiment, a user may access the administration features via a menu and select the automatic expiration feature. The user may then be prompted to input a data and/or time for the feature. The user may then input the preferred data and/or time. Once the user has selected and verified the date and/or time, the process continues to block 781.

[0258] At block 781, the threaded conversation is updated, reflecting the changes made, if any, by the user. The threaded conversation setting may be updated in conversation module 240 in conjunction with the communication server 102. After the threaded conversation is updated, the process continues to decision block 782.

[0259] At determination block 782, a determination is made as to whether the data and time, as set in block 780, has occurred. If the data and time has not been reached yet, the process remains at block 782. If the data and time is determined to have been reached, the process continues to subprocess 783. In one embodiment, the client device may include a clock or the like. The clock may continuously update the internal time in the memory 292of the client device. The processor 290 may continuously check the internal clock time and compare with the selected time for automatic expiration in conversation module 240. When the compared date/time is the same, the conversation module 240 may be configured to continue to subprocess 783 to enter a deletion phase.

[0260] Subprocess 783 may represent a process similar to the deletion process as described in reference to FIGS. 6D and 6E. At subprocess 783, the process may make a request to delete the threaded conversation. The process may then continue in a similar manner as described in reference to FIGS. 6D and 6E. Upon completion of subprocess 783, the process ends. [0261] FIG. 7L is a flowchart of an exemplary method of configuring settings for reviews. In one embodiment, a user may permit participants of a threaded conversation to post reviews related to the user , in a manner similar to an endorsement model whereby users may endorse or provide positive reviews of other users. In some embodiments, the reviews may be related to the author of the threaded conversation, a product produced by the author, a service rendered, etc. In one embodiment, the process may permit reviews to be automatically posted to a threaded conversation. In some embodiments, the process may provide for an ability to hide reviews from other participants of the threaded conversation. In some embodiments, the process may provide an ability to completely remove a selected review. In some embodiments, the user may require an approval process where a review may have to be approved by the creator the threaded conversation or the creator's representatives. The approval process may be done by initiating a second threaded conversation between the creator and a reviewer. In some embodiments, the approval process may involve submitting, via email, regular mail, etc., the full review to the creator or his representatives. The method shown in FIG. 7L may be implemented in conversation module 240 in communication with database 220 and filtering module 254 in FIGS. 1-2B.

[0262] At determination block 784, a determination is made whether the user has selected to permit the posting of reviews on a threaded conversation. In one embodiment, the user may access the administration features in accordance with FIG. 6F, and enable the ability to permit participants of a threaded conversation to post reviews. In some embodiments, the conversation module 240 may be configured to receive an indicator of the user's selected setting. If the user has not selected to permit reviews, the process remains at block 784. If the user has selected to permit reviews, the process continues to block 785.

[0263] At block 785, a review is transmitted to the conversation module 240 and posted on a threaded conversation. In one embodiment, the author of the threaded conversation may transmit the review to the threaded conversation. In some embodiments, a participant may post the review to the threaded conversation. In some embodiments, a review may be posted as an entry of the threaded conversation, a link or a subsequent threaded conversation containing the review, or a method of notifying other participants of the threaded conversation of the availability of the review. The review may be transmitted to the conversation module 240 through server 102 and synchronization module 230. In one embodiment, prior to the review being available, the process continues to decision block 786.

[0264] At decision block 786, a determination is made as to whether approval is required prior to posting a review. In one embodiment, an author of a threaded conversation may select in the settings of a threaded conversation to require approval. The user may select the approval requirement in the administration settings accessed through the admin portal. In one embodiment, the conversation module 240 may be configured to accept the user selection. If approval is not required, the process continues to block 789. If approval is required by the creator or representatives, the process continues to decision block 787.

[0265] At decision block 787, a determination is made as to whether the creator or the creator's representatives have approved the review. In one embodiment, the determination may be made by the user, where a user may receive a review and, upon approving the review, accessing the threaded conversation and selecting an "approved" option to permit access by other participants. In some embodiments, the user may receive notification of a pending review and, either including in the notification and/or as a subsequent notification, be prompted to reject or approve the review. In yet some embodiments, the review may be made available to the author, while not viewable to other participants, until approval is provided. In one embodiment, the viewing restriction may be through a BCC operation substantially similar to that described in reference to FIG. 7A. If no approval has been provided, the process remains at block 786. If approval has been provided, the process continues to block 789.

[0266] At block 789, the review is posted to the threaded conversation and available to all participants. In one embodiment, the communication settings as described in reference to FIG. 7A may alter the configuration of participants who are capable of viewing the review. For example, a BCC configuration may already be setup in the threaded conversation, which may affect which participants are capable of viewing the review. In one embodiment, the conversation module 240 may be configured to receive the review, and post the review, only after completion of the approval process. In some embodiments, the conversation module 240 may be configured to receive a review and withhold the review from posting until reception of approval notification. If the review is successfully posted to the threaded conversation, the process continues to decision block 790. [0267] At decision block 790, a user may select to hide the review. In one embodiment, the review may be hidden from view by participants of the threaded conversation. In some embodiments, the review may be hidden from a subset of all participants, where the subset includes at least one or more participants. In some embodiments, the review may be completely removed from the threaded conversation. In some embodiments, the review may be hidden based on displaying rules selected by the creator of the threaded conversation. In some embodiments, the review may be hidden if it is unfavorable or negative to the creator of the threaded conversation, where displaying rules may include criteria for determining that the review is unfavorable or negative. In one embodiment, the system may be able to scan the review for words or phrases indicating a negative review and automatically hide the review. Instructions to hide the review may be transmitted to a conversation module 240. In some embodiments, the conversation module 240 may be configured to receive a user selection, via a user interface, to hide a review. If instructions to hide the review are received, the process continues to block 791. At block 791, the review is hidden in accordance with the user's and/or the system's instructions as described above. Once the review is hidden, and the process continues to block 792. If the hide option is not received or instructions to hide the review are not present, then the process continues to block 792.

[0268] At block 792, the threaded conversation is updated, reflecting any submitted reviews and restrictions, if any, regarding the participants' permissions to view the reviews. The review settings may be updated in conversation module 240 in conjunction with database 220. After the threaded conversation reflecting the review settings is updated, the process ends.

[0269] FIG. 8 is an exemplary message diagram for allocating tags having at least one allocation constraint in accordance with one embodiment. In one implementation, the allocation of tags may be through software transactions that may occur to allow a user to purchase tags having an allocation constraint, e.g. fee-based tags, from the tag marketplace and to associate these tags with a threaded conversation or profile. The message flow of FIG. 8 shows messages exchanged between several entities which can be included in a communication system. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein. In one implementation, the client device 200a, the client device tagging module 210a, the server tagging module 210b, server tag marketplace module 280, and server transaction module 260b may be implemented in the communication server 102 and/or the client device 110 (FIGS. 1-2B).

[0270] Messaging 810 is performed to send a request to add a one or more tags to the device tag module 210a. In one embodiment, message 810 may be sent via an input by a user of a client device requesting to associate public tags to a profile or threaded conversation. In some embodiments, the public tags request may be the result of a general tag search and request to add a tag.

[0271] The client tag module 210a may receive message 810 and, via message 815, may determine if the requested tags are available for public allocation. In one embodiment, the device tag module 210a may include availability rules. The availability rules may be stored on a client device, for example in device database 220a, and allow the device tag module 210a to locally determine if the tags being requested are available. For example, the device database 220a may include a list of public tags that do not include an allocation constraint, e.g. a list of all freely available public tags. The device tag module 210a may determine that the requested tags are not constraint free tags, e.g. not a freely available tags, and determine the requested tags are not available locally for allocation. In some embodiments, the client tag module 210a may access the client device database 220a to determine if the tags are locally available for public allocation. In one embodiment, the client tag module 210a may determine the requested public tags are unavailable, e.g., the tags are not available within the client device database 220a, and may transmit the request to a communication server 102.

[0272] Messaging 820 is performed to send the request to add the tags from the client device 110, via network 190, to the communication server 102. In one embodiment, the server tag module 210b is configured to permit the user to create custom tags without constraints. In another embodiment, the client device 110 requests to add tags that the client tag module 210a determined were unavailable or not approved. In one embodiment, the server tag module 210b receives messaging 820 and, via message 825, may determine that the requested tags include at least one allocation constraints and are unavailable or not approved. Allocation constraints include, but are not limited to, tags that are fee-based or tags that require verification or certification before a user may allocate a tag to a user profile. In some embodiments, the availability of a tag is based on a count value, where if the count is equal to a predetermined maximum value allowed then the tag will be deemed unavailable until other users delete the tag or the count value is reduced. For example, count values may be attributed to whether a word or phrase is permitted or excluded based on the definition or connotation of the word or phrase based on a dictionary of words stored in the communication server 102. In another embodiment, the public tag descriptors may be classified into "Parent" and "Child" tag categories, thereby enabling classification as available or unavailable based on the user and category. In yet another embodiment, an allocation constraint may be based on whether a tag descriptor is certified, such as those tags that require verification before assigned to the user requesting the tag (e.g., attorney, professional driver, doctor, etc.). Allocation constraints may require the user submit proper documentation or verification that the tag is appropriate. For example, if a user wishes to allocate the tag "Attorney" to a profile, the user may be required to provide verification that the user is barred in the appropriate geographical region. Where an allocation constraint exists, the user's public tag request may then be directed to the server tag marketplace module 280 via message 830.

[0273] Messaging 830 is performed to direct the user to the server tag marketplace module 280. In one embodiment, message 830 may include a request to satisfy the allocation constraint of the requested tags. For example, the user may wish to purchase the right to allocate the fee-based tags and associate the tags to a user profile or threaded conversation. In some embodiments, prior to negotiating for the requested tags, server tag marketplace module 280 may initiate a search, via message 835, for the requested tags. In some embodiments, a search for the requested tags, via message 835, may be initiated by the user over the sever tag marketplace 280 and server database 220b. In one embodiment, the search of message 835 includes all public tags contained in server database 220b. In some embodiments, the search of message 835 includes only public tags having an allocation constraint, as identified by server tag module 210b. [0274] Once the requested tags are located by server tag marketplace module 280, the user may satisfy the allocation constraint, e.g. by entering a transaction to purchase the tags. To satisfy the allocation constrains, message 840 is performed to send transactional information to the server transaction module 260b to consummate the transaction requested by the user of the client device 110. In some embodiments, the user may decide to transact for fee-based tags as a result of message 830. In one embodiment, the user may create a transaction channel associated with fee-based tags. In one embodiment, the server tag marketplace module 280 may have embedded transaction options for the user to choose from. In some embodiments, a transaction channel may have been created when the fee-based tags were selected by the user. In one embodiment, the user may be prompted to add the amount of money to be exchanged and the method of exchanging money. In some embodiments, the transactional information (e.g., amount of money, method of payment, etc.) may be prepopulated based on the options of the server tag marketplace module 280. In one embodiment, the user may be prompted to edit transaction information and/or add additional information (e.g., customer service, information, promotional information, discounts, etc.) in connection with the transaction. Once the server transaction module 260b receives and processes the transaction information provided by the user, the server transaction module 260b may be configured to forward at least a portion of the transaction information to a different server (e.g., the third party transaction server 150 in FIG. 1) through the network 190. In one embodiment, a single transaction may involve more than one transaction servers and may involve more than one of messages similar to message 840.

[0275] Messaging 850 is performed to send an allocation satisfaction report, e.g. transaction complete report, and an instructions to associate the fee-based tags to the user's profile or threaded conversation in the server tag module 210b in response to the transaction request of the user of the client device 110. Upon completion of a successful transaction, the server transaction module 260b may have obtained a confirmation code or a receipt number of the completed transaction. The server transaction module 260b may forward that information to the server tag module 210b for further reference for the user of the client device 110. The server transaction module 260b may also send to the client device a message confirming the additional information exchanged associate with the transaction, such as customer service, information, promotional information, discounts, etc. In one embodiment, server tag module 210b may accept message 850 and associate the fee-based tags with the user's profile or threaded conversation as stored communication server 102. In one embodiment, the server tag module 210b may update the tag index, via message 855, to account for the tag being allocated to the profile or threaded conversation. In one implementation, the server database 220b may be updated. In one embodiment, the association of the fee-based tags, resulting from server tag module 210b, may drive traffic to the user's profile or threaded conversation due to other users of the system searching for the fee-based tag.

[0276] Messaging 860 is performed to send verification and provide tagging instructions to the client tagging module 210a from server tagging module 210b. Upon completion of a successful transaction, the server transaction module 260b may send a response to the tag request and subsequent fee-based tags purchased initiated by the user of client device 110. In one embodiment, the client tagging module 210a may accept message 860 to associate the fee-based tags with the user's profile or threaded conversation locally on client device 110. Upon accepting message 860, the client tag module 210a may locally associate the public fee-based tags with the profile or threaded conversation and update the index via message 865. In one embodiment, the database 220a may be updated by message 865.

[0277] Message 870 is performed to display the results of the user's tag request on the client device 110. In one embodiment, message 870 may display a successful transaction notification resulting from purchasing the fee-based tags. In some embodiments, message 870 may display verification that the fee-based tags were successfully associated with the profile or threaded conversation as requested by the user.

[0278] FIG. 9 is a flowchart for an exemplary method of allocating tags having an allocation constraint from the tags marketplace. The method shown in FIG. 9 may be implemented in the server tag marketplace module 280 that is in communication with the database 220b in the communication server 102 as described in connection with FIGS. 1- 2B, 3A, and 3B. In one embodiment, a user may be directed to the process of allocating a tag having an allocation constraint due to the user initiating a search for a tag on the device database 220a where the tag may not be available, e.g. unconstrained, in the client device database 220a. In some embodiments, a user may be directed to the process of purchasing a fee-based tag resulting from a search for a tag on the server database 220b where the tag may be located but is indicated as a fee-based tag as described in reference to FIG. 4. In some embodiments, the user may be directed to the process of purchasing a fee-based tag as a result of the user explicitly searching for a fee-based tag in the server tag marketplace module 280.

[0279] At block 901, a user decides to search a particular network where the user may believe the tag will be located. In one embodiment, a user may select to search an advertising network or "AD Network", for example a network of tags that are placed on the network for advertising purposes. In some embodiments, a user may select to search a "Search Network" where the user may be capable of searching for any public tag. In some embodiments, the user may be capable of selecting both an AD Network and a Search Network. After a user selects the network the process continues to block 902. In some embodiments, the selection of a network to search is optional, in which case the process begins at block 902.

[0280] At block 902, a user enters search for tag the user desires to purchase. The user may select and input on the client device 110 one or more words or phrases to locate fee- based tags, which may be self-descriptions the user would like to be associated with. The client device 110 then may send the user inputted words or phrases and request the server tag marketplace module 280 to locate tags based on the words or phrases. In one embodiment, the client device 110 may display a message to the user suggesting a better tag words or phrases. In some embodiments, the client device 110 may display a message to the user notifying of tagging restrictions and that the tag the user intends to create is too long, spelled incorrectly, inappropriate, or offensive. In some embodiments, the user may be allowed to override the tagging restrictions, and in some embodiments, the user may be allowed to override only some of the tagging restrictions. Upon receiving the fee-based tag requests, the server tag marketplace module may generate one or more tags based on the user inputted words or phrases. In one embodiment, a user may enter a specific tag that the user seeks to purchase. In some embodiments, a user may enter a keyword related to the fee-based tags. In some embodiments, based on a private or public tag search as described in reference to FIGS. 4, block 902 may begin a search of database 220b to locate any tags, free tags, or fee- based tags that are related to the user's entry in block 902. In this way, the process may return and display the results of a search. After a user enters a search for any fee-based tags, the process continues to block 903.

[0281] At decision block 903, a determination is made as to whether the user is seeking to add a group of tags or a single tag from the tags displayed in block 902. In one embodiment, at block 905, a user may select all tags that were returned. In some embodiments, at block 904, a user may select a single tag from the results. In some embodiments, a user may select a subset of the returned results. If a user selects a single fee- based tag, the process continues to block 904. If a user selects a group of fee-based tags, the process continues to block 905. After a user has selected the fee-based tags the user wishes to purchase, the process continues to block 906.

[0282] At block 906, a user selects from a variety of pricing options for the fee- based tags. In one embodiment, a user may select to pay a fixed price of the fee-based tags for a fixed duration. In some embodiments, a user may select to configure a profit sharing model for the selected fee-based tags. In one implementation, a profit sharing model may be a configuration where a user pays an agreed upon amount and is entitled to keep a percentage of the income generated by the fee-based tags while the remaining percentage may be paid to the seller of the fee-based tags. In some embodiments, a user may select to pay a fixed price for the life of the tags. In some embodiments, a user may select to "lease" the fee-based tags. In this configuration, a user may select to pay a fixed price for the fee-based tags for a fixed but limited duration and may be presented the option to renew the "lease" at the end of the duration. The price for the renewed duration may or may not be the same as the previous fixed price. In some embodiments, a user may select to pay a fixed price for the fee-based tags as a function of a specific location (e.g., zip code(s), country(s), state(s), etc.). In some embodiments, a user may select to pay a fixed price for a fee-based tags based on a budget. For example, if a group of tags resulting from a search is $10 for the group but the user would like to spend $5, then the process may return a subset of the group of tags that meet the user's budget. In some embodiments, pricing of fee-based tags may be done through bidding by multiple users in a real-time environment via auction type mechanisms. After a pricing option is selected, the process continues to block 907. [0283] At block 907, a user finalizes the selected fee-based tags and pricing options. In one embodiment, the user may determine that the details of the order is correct (e.g., that the correct tags and the appropriate pricing option were selected) and proceed to block 908. In some embodiments, the use may determine that there was a mistake and return to the appropriate step, of any blocks 901-905, to correct the mistake. After the user has finalized the selections, the process continues to block 908. In some embodiments, the user may be directed to decision block 909.

[0284] At decision block 909, a determination is made whether a user has requested the fee-based tags be added to a threaded conversation or a user profile. In one embodiment, a user may select to attach fee-based tags to the user's profile, in this way the user may drive traffic to the user's profile. In some embodiments, a user may select to add the fee-based tags to one or multiple threaded conversations. In some embodiments, the user may select to add tags to an active or inactive threaded conversation. In a further embodiment, the tags may relate to people, services, products, or anything that the user wishes to use to drive traffic to the threaded conversation(s) selected. In some embodiments, a user may select to add the tags to both a threaded conversation and the user profile. After the user selects to add the tags to a threaded conversation and/or a user profile, the process continues to block 908. In some embodiments, a user may decide first to determine where the user would like to add the tags, e.g., a user profile and/or a threaded conversation, before specifically selecting which tags purchase or before selecting the pricing option as detailed above. In this case, the process directs the user to blocks 905 and 906 as detailed above.

[0285] At block 908, the process directs the user to finalize the purchase of the fee-based tags by completing a billing process. In one embodiment, a user may review an order prior to filling out the billing requirements. In some embodiments, a user may review an order after filling out the billing requirements, as seen in block 910.

[0286] In one embodiment, the system may be configured to consummate transactions for the selected tags. In one embodiment, the transaction module 260 may be so configured. The transactions may be consummated in conjunction with the various communication features described above. One type of transaction may be a mobile payment. Payment credentials or information such as payment card information or digital wallet information may be stored in the network. This allows the payment information to be retained outside the client device (e.g., phone). The payment transaction aspects of the system may be configured to utilize encryption and/or tokenization to protect information needed to effect the payment such as card information, confirmation codes, personal identification numbers (PINs), passwords, personal identification information (e.g., date of birth, social security number, etc.), and the like. In some implementations, the system may include features to identify card-present rates for transactions at a rate that depends on physical presentation of card such as to a reader. For example, a beacon may be provided which is configured to acquire payment information. The payment transactions may be configured to integrate with payment networks or payment processing entities such as Europay, MasterCard, Visa (EMV) (a.k.a. "chip and pin") systems, and/or dynamic processing system (e.g., PayPal, Apple app, Store, Android app store, etc.), as described above. In some implementations, transaction may include authorization by, for example, a PIN, one-time password (OTP), biometric information, bank-to-bank authorization, peer-to-peer (P2P) authorization, and the like. The system may receive the authorization information from a client device. The authorization information is then securely transmitted to the central server for processing payments such as via automated clearing house (ACH).

[0287] In one embodiment, the transaction may be consummated by a communication server 102 having a transaction processing module 106 (FIG. 1). The transaction processing module 106 may be configured to perform payment processing or payment remittance. The transaction processing module 106 may be configured to consummate the transaction. In some implementations, the transaction processing module 106 may be configured to communicate with a third party transaction server 150 to consummate the transaction. The third party transaction server 150 may be, in some implementations, a remittance and/or payment processing server such as an e-wallet, a bank, an automated clearing house, an online money transfer service, or a digital currency exchange.

[0288] In some embodiments, the third party transaction server 150 may be configured to send a confirmation code or a receipt number upon completion of the transaction. In one embodiment, more than one server may be involved in the transaction to consummate the transaction. In one embodiment, the transaction module 260 may be configured to receive a transaction unsuccessful message through the network 190, and there may be one or more following messages between the transaction module 260, client device 110, and/or third party servers 150 (FIG. 1) to complete a successful transaction. In one embodiment, the transaction may not need a third party server, and the entirety of the transaction may be consummated within the communication server 102 (FIG. 1). In one embodiment, the transaction module 260 implemented in the client device 110 (FIG. 1) may transmit a transaction request to a server by means of the network 190 for processing without requiring that a response (successful or unsuccessful) being received by the transaction module 260 implemented in the client device 110 (FIG. 1) from the network 190 in order to finalize the transaction.

[0289] Transaction module 260 may be configured to send a transaction complete report to the client device 110 in response to the transaction request of the user of the client device 110. Upon completion of a successful transaction, the transaction module 260 may have obtained a confirmation code or a receipt number of the completed transaction. The transaction module 260 may forward that information to the client device 110 for further reference for the user of the client device 110. The transaction module 260 may also send to the client device a message confirming the additional information exchanged in association with the transaction, customer service, information, promotional information, discounts, etc.

[0290] At block 911, the process permits the purchased tags to be associated with the user's profile or threaded conversation. In this way, the fee-based tags direct traffic to the selected user profile or threaded conversation as dictated in the above process. In one embodiment this may complete the process for purchasing fee-based tags, and the user may exit the tags marketplace. In some embodiments, the process continues to block 912.

[0291] At block 912, the process enables a financial transaction of each system user that connects to the profile or threaded conversation associated with the fee-based tags. In one embodiment, each fee-based tags purchased by the user may have an active counter associated with the fee-based tags. The counter may increase by an increment when the fee- based tags leads to a connection from another user. In one embodiment, the connection may be more than a search for the fee-based tags by another user. In some embodiments, the connection by another participant results in an increase of the counter, where a connection is either by adding the user profile associated with the fee-based tags or by connecting to the threaded conversation. In some embodiments, a financial transaction may result for each connection by another user, thus the counter may log the number of connections made to allow a tracking of the financial transactions.

[0292] FIG. 10 is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 1, 2 A, and 2B integrated with a threaded conversation customer relations management (CRM) tool in accordance with one embodiment. As illustrated in FIG. 10, the client device 110a (FIG. 1) may be implemented as a client device 1001. The communication server 102 (FIG. 1) may be implemented as communication server 1002 and the enterprise server 140 (FIG. 1) may be implemented as enterprise server 1003. The client device 1001 may be in communication with the communication server 1002 and enterprise server 1003 through a network 190. Individual modules of the client device 1001, communication server 1002, or enterprise server 1003 may further be in communication with one another either within each of the client device 1001, communication server 1002, or enterprise server 1003 through network 190. Reference to modules in the client device 110 (FIG. 2A-2B) herein, such as tagging module 210a, refers to any implementations of such module in either the client device 1001, communication server 1002, or enterprise server 1003, such as tagging module 1010.

[0293] As explained in more detail above, a user, using client device 1001, connects to a threaded conversation authored by another via the conversation module 1040 of the communication server 1002. In one embodiment, the author of a threaded conversation may be an enterprise, for example Coca-Cola. Coca-Cola may author a single threaded conversation or multiple conversations related to different product lines (e.g., Coca-Cola, Diet Coke, Sprite, etc.). These conversations may be managed by the conversation module 1040. In some embodiments, the author may employ a network of their own in enterprise server 1003 to manage its conversations. In one embodiment, a user may initiate a threaded conversation with the enterprise. In some embodiments, a user may join a currently active threaded conversation managed by the enterprise. In some embodiments, the enterprise may choose to engage with the user via the active threaded conversation, which may or may not include multiple users on a single threaded conversation. In some embodiments, the enterprise may decide to imitate a separate threaded conversation, where the enterprise may engage the user one-on-one.

[0294] The enterprise server 1003 includes a CRM module 1030 that may manage the interactions with its customers. In one embodiment, the CRM module 1030 may be configured to communicate with communication server 1002. The CRM module 1030 also is configured to communicate with the enterprise database server 1060. In one embodiment, the enterprise database 1060 may include a list of sales representatives 1061 employed by the enterprise. In some embodiments, the enterprise database 1060 may include a list of technical customer service representatives. In some embodiments, the enterprise database 1060 may include a list of any personnel the enterprise may wish to make available to its customers through a threaded conversation. In one embodiment, the enterprise database 1060 may further include representative identification rules. The representative identification rules may be used by the enterprise to identify which sales representative or other representative should be included in the threaded conversation with the user from the list of representatives contained in enterprise database 1003. In one embodiment, the identification rules may be based on geographic location. In some embodiments, the identification rules may be based on the user's needs. In some embodiments, the identification rules may be based on a particular product or service offered by the enterprise.

[0295] As shown in FIG. 10, once the CRM module 1030, via the enterprise database 1060, has identified the proper representative, the CRM module 1030 communicates with the communication server 1002 to manage the personnel involved with the threaded conversations related to the enterprise. In one embodiment, the enterprise may initiate a one- on-one threaded communication between the consumer and the organization in response to a conversation request sent by the consumer. The CRM module 1030 may identify the proper representative and assign that representative to threaded conversation request. In some embodiments, the enterprise may initiate a "one-to-many" conversation between the consumer and a public threaded conversation managed by the enterprise at the time the user requests a conversation. In an exemplary implementation of the "one-to-many" conversation, all participating consumers may be able to interact with the enterprises representative on a single threaded conversation. In some embodiments, the enterprise may initiate a "one-to-many" communication between the consumer and a public threaded conversation managed by the organization at the time the user requests a conversation. The CRM module 1030 may then identify a representative who may initiate a subsequent one-on-one threaded conversation to more directly address the consumer's needs. In some embodiments, the enterprise may respond to a threaded conversation request from a consumer by initiating a "one-to- enterprise" threaded conversation, where the CRM module 1003 may identify multiple enterprise representatives from database 1060 that may be useful to include in the threaded conversation to address the consumer's needs. The enterprise may decide to initiate a "one-to- enterprise" conversation from a "one-on-one" conversation or "one-to-many" conversation. In some embodiments, the enterprise may select to engage the consumer in any of the above described manners, and may be able to switch between each of the methods of communication as needed to facilitate assisting the consumer.

[0296] The above described features related to threadsites can be integrated to form a persistent advertising network. A persistent advertising network allows a merchant to engage with users whether in- venue such as in a merchant's store or out-of- venue such as near the merchant's store or at a location remote from the merchant's store.

[0297] The client device software application may include at least one deal folder. The deal folder may receive deals in the form of threadsites, or deals which are published through a threadsite. The deal folders, by default, may always be on or enabled to receive deals unless the user deletes the folder. The deal folder may contain a plurality of tags for which the user has opted into to receive deals. Alternatively, the deal folder may contain a plurality of tags auto-suggested for the user which trigger deals based on demographic information regarding the user. Moreover, merchant brands such as AT&T or Verizon or American Express can have their own deal folder pre-configured and allow the users to refine the tags within those deal folders. For example, the deal folders may be customized through an interface presented on the client device which displays the parent tags and allowing the user to select, via the interface, either the parent tags or one or more child tags within a parent tag to be opted into receiving deals. The same may be true for any deal folder configured within the application, user selects either the parent tags or one or more child tags within a parent tag to be opted into. [0298] For an out-of-venue experience, consider a customer at the front of a grocery shopping center and the software application executing on a client device in the user's pocket has identified the front door of the grocery by means of its geographic coordinates (geo-location) as a Point of Interest (POI). When the client device of a user is in close proximity to the POI, a set of tags pop up within the software application to permit the user to opt-in into deals. Either a new deal folder is created with a certain set of tags or an existing deal folder is modified based on a set of tags presented/selected by the user. When the user enters the door at the grocery he is presented with a set of deal tags regardless of prior selection (deal preferences and deals used). In another embodiment, when the user enters the door at grocery he is presented with a set of deal tags based upon prior selection (deal preferences and deals used). Alternatively, when a user is in close proximity to a POI a set of tags pop up within the software to allow to user to initiate a threadsite with the tag owner.

[0299] These suggested tags are triggered based on: time, individual, and proximity. With reference to time, a specific time for a specific set of tags will be identified by the tag owner to be suggested to user. Individual triggering refers to tags suggested to user as being based on the demographic information the software application has on the owner such as age, job, education, income, interests, etc. The third dimension, proximity, refers to a specific distance from the POI identified by the application and stored in the server side database.

[0300] When a user opts into a tag, his deal folder will be updated, and a deal presented to the user. The deal may be in a form of a barcode coupon to scan at the register, a promo-code to be used for online purchase, or a promotion to be used exclusively for purchase through the threadsite transaction interface.

[0301] For an in-venue experience, consider a user inside a casino and the software application executing on a client device has identified the food court by means of the presence of a beacon as a Point of Interest (POI). When the user is in close proximity to the beacon POI, a set of tags may pop up within the software application to permit the user to opt into deals. Either a new deal folder is created with a certain set of tags or an existing deal folder is modified based on a set of tags presented/selected by the user. Inside the casino the user is presented with a set of deal tags regardless of prior selection (deal preferences and deals used). In some embodiments, when the user is inside the casino he is presented with a set of deal tags based upon prior selection (deal preferences and deals used). Alternatively or in addition, when a user is in close proximity to beacon a POI a set of tags pop up within the software to allow to user to initiate a threadsite with the tag owner. The casino may have multiple beacons inside its facility, each beacon identified with its own location and available deal tags. Based upon the movement of the user within the casino different deal tags will be presented to the user for consumption. The presentation of tags may be triggered based on time, individual, and proximity as discussed above. Appendix B includes further examples of implementations including the tagging, conversation, and persistent advertising network features described.

[0302] It may be desirable to configure the tags application server, via an API call, to configures a deal folder within the tags client application. When the user selects their tag preferences, then deals are displayed on the tags client application deals folder or threadsite. Moreover, the tags application server via an API call may configure a deal folder within a third party application. Within the third party application, users can access the deal folder and select tag preferences. The user experience may then directed to the tags client application deals site. The tags client application may require installation and/or sign in on the client device for the API call configuration to work.

[0303] While the client device is generally discussed as a mobile device, it should be appreciated that the client device may be implemented as a tag messaging widget installed within the desktop computer. The user can click the widget a start an instant conversation from desktop to client mobile device as described herein. In some implementations, the client device may be a background process which detects tags displayed on the client device, such as a desktop computer. When the desktop user click on an embedded tag is detected, the process may create an instant conversation from desktop to mobile device as described above, such as launching a threadsite.

[0304] FIG. 11 is a functional block diagram of an exemplary communications server for allocating descriptors. The communications server may include additional elements described above to facilitate the additional communication aspects described. The server 1100 shown in FIG. 11 is simplified to focus on the descriptor allocation features. The allocation may be included as part of a marketplace or other system whereby the use of public descriptors by users may be controlled through allocation of the descriptors. The server 1100 may implement, in whole or in part, the message flow shown in FIG. 8.

[0305] The server 1100 includes an account manager 1102. The account manager 1102 may be configured to receive user account information including credentials. For example, the account manager 1102 may receive a username and password for a user account. In some implementations, the credentials may be specified as a token. The account information may be received via wired, wireless, or hybrid wired/wireless means.

[0306] The server 1100 includes a tag manager 1104. The tag manager 1104 may be configured to receive public descriptors and private descriptors for a user account. The descriptors may be implemented as tags. The public descriptors may include a public descriptor that is either available for allocation or allocated to the user account.

[0307] The server 1100 shown in FIG. 11 also includes an allocation search engine 1106. The allocation search engine 1106 may be configured to determine whether a requested public descriptor is available for allocation to the user account. The determination may include receiving and executing an allocation search request for the requested public descriptor. The search executed may examine private descriptors for the user account, public descriptors for the user account, and the requested public descriptor. For example, a requested descriptor may be allocated only if the user has already been tagged (publicly or privately) with another descriptor. Accordingly, preconditions may be established which determine whether a given user account is "eligible" to be allocated a particular descriptor.

[0308] The server 1100 may include a tag allocator 1108. The tag allocator 1108 may be configured to, upon determining by the allocation search engine 1106 that the requested public descriptor is available for allocation to the user account, initiate an allocation transaction. The determination may also be based on location. For example, a tag may be available for allocation to devices within a geographic area.

[0309] A transaction module 1110 may be included in the server 110 to consummate the allocation transaction. Consummation of the allocation transaction may include allocating the requested public descriptor to the user account. In some implementations, the transaction module 1110 may consummate the transaction via a payment processing server (not shown). In some implementations, the transaction may not include monetary transactions. For example, the transaction may be consummated upon completion of a quiz or viewing content. If the quiz is successfully completed by a user, the requested tag may be allocated to the user's account.

[0310] Various aspects of the novel systems, apparatuses, and methods are described more fully hereinafter with reference to the accompanying drawings. The teachings disclosure may, however, be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that the scope of the disclosure is intended to cover any aspect of the novel systems, apparatuses, and methods disclosed herein, whether implemented independently of or combined with any other aspect of the invention. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the invention is intended to cover such an apparatus or method which is practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the invention set forth herein. It should be understood that any aspect disclosed herein may be embodied by one or more elements of a claim.

[0311] Although particular aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to particular benefits, uses, or objectives. Rather, aspects of the disclosure are intended to be broadly applicable to different data access technologies, system configurations, networks, and transmission protocols, some of which are illustrated by way of example in the figures and in the following description of the preferred aspects. The detailed description and drawings are merely illustrative of the disclosure rather than limiting, the scope of the disclosure being defined by the appended claims and equivalents thereof.

[0312] The various operations of methods described above may be performed by any suitable means capable of performing the operations, such as various hardware and/or software component(s), circuits, and/or module(s). Generally, any operations illustrated in the Figures may be performed by corresponding functional means capable of performing the operations.

[0313] The various illustrative logical blocks, modules and circuits described in connection with the present disclosure may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array signal (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available processor, controller, microcontroller or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0314] In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer- readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Thus, in some aspects computer readable medium may comprise non- transitory computer readable medium (e.g., tangible media). In addition, in some aspects computer readable medium may comprise transitory computer readable medium (e.g., a signal). Combinations of the above should also be included within the scope of computer- readable media.

[0315] The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

[0316] Software or instructions may also be transmitted over a transmission medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of transmission medium.

[0317] Further, it should be appreciated that modules and/or other appropriate means for performing the methods and techniques described herein can be downloaded and/or otherwise obtained by a device as applicable. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can be provided via storage means (e.g., RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.), such that a device can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

[0318] The interfaces shown represent example implementations of a tangible device configured to perform one or more of the features described. The interface elements may be implemented via the execution of machine readable instructions to generate a graphical representation of the interface on a device. The graphical representation may be, for example, a machine readable mark-up language (e.g., HTML), executable machine readable instructions (e.g., JavaScript), or combinations of these or other display technologies. In some implementations, the interface may be constructed of physical components such as buttons, circuits, lights, and the like. The interface components may be controlled by a circuit configured to implement the methods described above. In some implementations, it may be desirable to control the interface components via a processor configured to execute stored instructions which cause the interface components to perform aspects of the methods described.

[0319] As used herein, the terms "display" or "displaying" encompass a variety of actions. For example, "displaying" may include presenting in audio form, visual form, or some other form that can be made known to the senses. The term may also include a combination of two or more of the foregoing.

[0320] As used herein, the terms "determine" or "determining" encompass a variety of actions. For example, "determining" may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, "determining" may include resolving, selecting, choosing, establishing and the like.

[0321] As used herein, the terms "provide" or "providing" encompass a wide variety of actions. For example, "providing" may include storing a value in a location for subsequent retrieval, transmitting a value directly to the recipient, transmitting or storing a reference to a value, and the like. "Providing" may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like.

[0322] It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes and variations may be made in the arrangement, operation and details of the methods and apparatus described above without departing from the scope of the claims. [0323] While the foregoing is directed to aspects of the present disclosure, other and further aspects of the disclosure may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.

APPENDIX A

Threadsite is a name given to our ability to create an on-demand messaging session between 1 or more people to share content and information. The application may use the term "threaded conversation" to mean the same thing.

A Threadsite (which by the way is our preferred term of art) may be initiated in multiple scenarios. One scenario is that a user can search for a private tag (a tag they have placed onto an individual in their contact list), select 1 or more individuals and then initiate a messaging session. Another scenario is that a user can search for a public tag (a tag that the other users of the system have classified themselves as for that point in time), select 1 or more individuals and then initiate a messaging session. In yet another embodiment, is where a user creates a preloaded messaging session, then invites others (his contacts or other users of the system) to join his Threadsite. In another embodiment, the user may see a tag on a product in real life, like a coke can or a web-site, he can type in that unique identifier (i.e. tag) and it will take him directly to the Threadsite.

Figure 1A is a flow diagram that describes the method for which a private tag search leads to a Threadsite.

Figure IB is a flow diagram that describes the method for which a public tag search leads to a Threadsite.

Figure 4 is an illustration of a Threadsite Admin Portal where a user of the system has selected to create a new Threadsite and is given options to customize and add content to the Threadsite and finally be able to share his Threadsite with other users of the system.

Figure 2A is a sequence (message) diagram describing the software process involved in initiating a private tag search which leads to a Threadsite (i.e. threaded conversation).

Figure 2B is a sequence (message) diagram describing the software process involved in initiating a public tag search which leads to a Threadsite (i.e. threaded conversation).

Figure 3A is a graphical illustration of the user interface that a user of the system will utilize in order to initiate a private tag search which leads to a Threadsite. The big feature that we want to highlight is that a user is able to select at least one user from the result list and "instantly" begin a Threadsite to connect and share information with at least one user. In addition, the initiating user is able to setup the privacy settings for the Threadsite. The privacy settings include: (A) Broadcast or 2 way communication, (2) Show replies to all or blind carbon copy, (3)

Lock or Unlock the Threadsite. The privacy settings will be descried in Fig. 4 below.

Figure 3B is a graphical illustration of the user interface that a user of the system will utilize in order to initiate a public tag search which leads to a Threadsite. The big feature that we want to highlight is that a user is able to select at least one user from the result list and "instantly" begin a Threadsite to connect and share information with at least one user. In addition, the initiating user is able to setup the privacy settings for the Threadsite. The privacy settings include: (A)

Broadcast or 2 way communication, (2) Show replies to all or blind carbon copy, (3) Lock or

Unlock the Threadsite. The privacy settings will be descried in Fig. 4 below. Theadsite Admin Portal (a.k.a. Threadsite Administration and Managing Pre-loaded Threadsite)

1. FIG 4A. Threadsite administration portal is a means for a user of the system manage all his/her Threadsites. First, the user is able to view all Threadsites associated with him/her account. The user is able to edit Threadsites that he initiated because he is the author (creator). Moreover, the user is able to delete a Threadsite he is no longer interested in keeping active. An author of a Threadsite who initiates a delete command deletes the Threadsite from all users on that Threadsite. Whereas, an active user member of a Threadsite can delete the Threadsite from his Threadsite admin portal locally, but cannot permanently delete it (only the author has such authority).

2. The Threadsite admin portal allows the user to mute the Threadsite. Mute feature allows the Threadsite to continue on while the user is not receiving notification that updates are occurring. When the user does not want to be bothered by the communication, he turn toggle it to Mute mode. When the user later wants to be engaged (want to receive notification) then he can Un- mute and begin to receive notifications again.

3. The Threadsite admin portal allows the user to pause the Threadsite. Pause feature allows the author of the Threadsite to effectively disallow others from continuing to communicate on the Threadsite until he un-pauses it. So, communication sent by user after the author has paused the Theadsite will not be transmitted to the Threadsite, rather a message will display to the users that this Threadsite is Paused. When the author wants to re-engage the Threadsite participants than he can un-pause and allow participants of the Threadsite to communicate with one another (as configured by the pre-defined communication settings shown in FIG 4B).

4. The Threadsite admin portal allows the user to "edit" his previously created Threadsites. The edit request leads to the Threadsite Administration (FIG. 4B)

5. FIG 4B is the Threadsite Administration.

6. The Threadsite Admin allows a user to manage the content and settings associated with a

Threadsite.

7. The content management module allows the user to ADD, EDIT and DELETE photo, audio, text, video, and other media.

8. The user is able to add free tags to be associated with the Threadsite to drive traffic to the

Threadsite.

9. The user is able to add fee based tags (purchased from the tags marketplace FIG.5A and FIG.5B) to be associated with the Theadsite to drive traffic to the Threadsite.

10. The user is able to search private tags to add participants, (within his contact list)

11. The user is able to search public tags to add participants, (system wide user base)

12. The user is able to ADD/REMOVE participants to the Threadsite. This might be in a form of an invitation to join.

13. The user able to configure communication settings: the user is able to toggle between

broadcast (one way communication) and 2 way communication. Also, the user is able to toggle between allow participant's replies to be visible to all participants or blind carbon copy where the participants are unaware that others are in communication with the author and the participants are communicating with the author without their communication being shared with other participants in the Threadsite. 14. The user can toggle between locked and unlocked state. Locked state disallows participants from adding users to the Threadsite. In addition, it disallows system users from searching on a tag associated with the Threadsite and actually being accepted to participate/view the

Threadsite contents. Unlocked state allows everyone inside the Threadsite to add others to the Threadsite and leaves the Threadsite open for system users to search for the tag associated with the Threadsite and participate/view the Threadsite contents.

15. The user is able to setup privacy settings, to determine what he wants to share with the other participants of the Threadsite. The user can, for examples, hide/show his email, phone number, address, other personal information)

16. The user is able to configure location information preferences to allow the participants of the Threadsite to view (in real-time) his geo-location information for the life of the Threadsite.

17. The user is able to add items for sale within the Threadsite and set a price. So, for example, the user may want to sell baseball tickets for $200. The user may configure the sales settings to allow fixed price purchase, bidding style (where a min. value is set).

18. In addition, the user is able to enable financial transactions for the theadsite, so that when the baseball tickets on sale for $200 are sold, the sale can take place because the financial transaction will be handled by the system which allows for a dynamic selection of payment processing systems (i.e. PayPal, Apple app. Store, Android app store, etc.). In order for the user to be paid, they need to provide their bank account information or address where the check gets mailed.

19. The user can enable proximity offers, offers that are transmitted to users based on location of user, when the user is passively near a specific location defined by the user. This is handled by having an iBeacon integration with the application. The user can set up the offers and how they are to be distributed to system users.

20. The user can set up an automatic expiration - the user can configure a date/time when the Threadsite is automatically deleted from the system.

21. The user can also configure review settings. First, if users of the system are allowed to post a review on the Threadsite. Ability to remove (hide) reviews that are unfavorable that have already posted to the Threadsite. Ability to require reviews to go through a approval process (approved by the author or his representative) before they automatically posted to the

Threadsite.

Tags Marketplace

Module where the user is able to purchase fee-based tags to associate to his profile or Threadsite.

FIG 5A: is a illustration of the process flow that a user has to go through in order to purchase fee-based tags.

First, (OPTIONALLY) the user selects the network for which this tag will be found: (A) AD network which is the advertising network (TBD), (B) the Search network which is the search capability to search for a tag publically and display results, or (C) both AD network and Search Network

The user then types in a keyword (or tag) that he desires to purchase. The user may be provided a group of tags closely associated with the keyword(tag) he provided, the user can add just one tag from the options provided or a subset of the tags provided, or the entire group of tags presented to him.

One option would be to pay a fixed price for the tag(s) selected for a fixed duration.

One option would be to configure a profit sharing model for the tag(s) selected. Where the user pays us a certain amount and gets to keep a certain amount of the $$ generated by the tag. One option would be to configure fixed price for the tag(s) select for life.

One option would be to pay a fixed price for the tag(s) selected for a fixed duration with options to re-new.

One option would be to pay a fixed price for the tag(s) selected for a specific location (zip code, country, state, etc.)

One option would be to pay a fixed price for tags based on budget, so if the group of tags shown is $10 and the user only wants to spend $5, we can present him with a sub-set of tags available for $5 that meet his needs.

One option would be to allow bidding for tags in a real-time environment permitting auction type mechanisms.

The user must then determine to add the tags to his profile or to his (active/inactive)

Threadsite.

Then the user has to pay for the tag(s) selected, so he has to go through a billing process.

Then the user can review his order placed.

Then the newly purchased tag(s) allows for the user's profile or Threadsite to be discovered by the users of the system.

Optionally, if the user's Threadsite associated with the fee-based tag leads to a financial transaction.

Each tag purchased by the user will have an active counter- the counter will automatically increment every time the tag leads to an instant connection by another user (Not just search discovery) but rather the searcher must actually connect with (by means of a Threadsite) the tag buyer.

Fig. 5B is a sequence diagram of the software transactions that must occur to allow fee-based tags to be purchased and added to user account.

The client device sends a request to add a tag in the device tag module. The device tag module has a set of rules (locally) to determine if the tag being requested is available. If it cannot find it in its local database, it will send the request up to the server to be handled. The server tag module then determines that the tag is fee-based and not available for free. The user is then directed to the tag marketplace to allow him to purchase the tag he desires. The user then searches the tag marketplace, finds a tag or multiple tags of interest, he pays for them, he associates them to his profile or Threadsites. Then the user can see the tags displayed on his account profile and the Threadsites he selected the tags to be associated with. Threadsite Customer Relationship Management Integration

1. FIG. 6 relates to Threadsite Customer Relationship Management (CRM) Integration

2. A popular CRM tool is Saleforce.com and we want to be able to integrate with that platform or other CRM tools that provide similar features and services to the organization for which they have been adopted to support.

3. The idea is that we have a user (via a mobile device) searching for a tag (or finding a tag

(keyword) on a Coke can) which then leads into a Threadsite (a.k.a. threaded conversation) between the user and Coke. Now, Coke can have one static Threadsite that it manages or it can have multiple instances of Threadsites related to its product lines (COKE, SPRIT, etc.) or Coke employee network or whatever else. So, the user types in a tag in the search module on his device and is automatically shown the Threadsites or users related to that tag. The user can then click on a Threadsite and begins an instant dialog with the author of the Threadsite. Now, Coke can either engage with the consumer via the Threadsite or it may initiate a second, more 1-on-l Threadsite conversation, with the user to understand his needs with connecting with Coke today.

4. The Coke enterprise server running CRM is connected with our communication server. The Coke CRM is connected with its own database server having a listing of all Sales Representatives (for example), and thus can match a sales representative with a territory or product line or whatever it wants. So, once a user initiates a threaded conversation with Coke via tag, Coke CRM is able to identify who within Coke's list of contacts, should be communicating with the consumer at that point in time.

5. This leads us to at least 3 permutations means for which Coke can manage this new relationship with the consumer.

a. 1-on-l between the consumer and the organization (by means of a representative

assigned by the CRM tool) at the time that the Threadsite request is initiated by the user.

b. 1-to-many between the consumer and the organization's public Threadsite at the time that the Threadsite request is initiated by the user, where the organization representative (identified by the CRM tool) can initiate a subsequent 1-on-l Threadsite with the consumer.

c. 1-to-many between the consumer and the organization 's public Threadsite at the time that the Threadsite request is initiated by the user, where all consumers are interacting with the organization's sales reps all conversing on the same message thread.

d. Other permutations that you can think of here. PRIVATE TAG SEARCH WHICH LEADS TO A THREADED CONVERSATION

FIG. 1A PUBLIC TAG SEARCH WHICH LEADS TO THREADED CONVERSATION

FIG. 1 B

PRIVATE TAG SEARCH LEADS TO THREADED CONVERSATION

FIG. 2A

PUBLIC TAG SEARCH LEADS TO THREADED CONVERSATION

FIG, 2B

FIG. 3A

FIG. 3B

THREADSITE ADMIN PORTAL

FIG. 4A THREADSITE ADMINISTRATION

FIG. 4B SELLING TAGS TO CONSUMERS OR BUSINESS

(TAGS MARKETPLACE)

FIG. 5A BUY TAG FROM TAG MARKETPLACE SEQUANCE (MESSAGE) DIAGRAM

FIG. 5B

THREADSITE CUSTOMER RELATIONSHIP MANAGEMENT INTEGRATION

FIG. 6

APPENDIX B

Persistent Ad Network:

Deal Folder via API:

Deal Folder User Interface: