WO2016065153A2 - Système et procédé de fourniture de descripteur - Google Patents

Système et procédé de fourniture de descripteur Download PDF

Info

Publication number
WO2016065153A2
WO2016065153A2 PCT/US2015/056926 US2015056926W WO2016065153A2 WO 2016065153 A2 WO2016065153 A2 WO 2016065153A2 US 2015056926 W US2015056926 W US 2015056926W WO 2016065153 A2 WO2016065153 A2 WO 2016065153A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
information
tags
public
client device
Prior art date
Application number
PCT/US2015/056926
Other languages
English (en)
Other versions
WO2016065153A3 (fr
Inventor
Alexander HERN
Original Assignee
Revolution Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Revolution Technologies, Inc. filed Critical Revolution Technologies, Inc.
Publication of WO2016065153A2 publication Critical patent/WO2016065153A2/fr
Publication of WO2016065153A3 publication Critical patent/WO2016065153A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • FIGs. 20-36 may include one or more registered trademarks. These marks are shown for illustrative purposes only. These marks are owned by their respective entities and are not required to implement the features shown. The present applicant does not claim rights to nor affiliations with the trademarks represented herein, which are presented merely as example interfaces which may present the trademarks. The present applicant does not offer any products or services bearing these marks and makes no claim whatsoever to any interest in these marks. The applicant makes every effort to respect the proprietary nature of the marks, and every effort is made to prevent their use in any manner which might adversely affect their validity as trademarks.
  • the present application relates generally to creating and maintaining a dynamic directory and efficient provisioning of descriptors to the users included therein.
  • a non-transitory computer-readable medium with instructions stored thereon that, when executed by a processor, perform a method includes storing a directory of user accounts, the directory identifying a first association of a public descriptor to a user account, the directory further identifying a second association of a private descriptor to a contact of the user account.
  • the method includes receiving, from a communication device associated with the user account, a public descriptor request message, the public descriptor request message including a value indicating a public descriptor to store in the directory associated with the user account.
  • the method includes identifying a descriptor taxonomy using the value included in the public descriptor request.
  • the method includes generating a set of suggested public descriptors using the descriptor taxonomy and the public descriptor request message.
  • the method also includes transmitting the set of suggested public descriptors to the communication device.
  • FIG. 1 is a functional block diagram of an exemplary communications network system in accordance with one embodiment.
  • FIG. 2A is a functional block diagram of an exemplary wireless communication system in accordance with one embodiment.
  • FIG. 2B is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 2A.
  • FIG. 3 is an exemplary message diagram for creating tags in accordance with one embodiment.
  • FIG. 4 shows a messaging diagram for an example synchronization session between a client device and a communication server.
  • FIG. 5 A is an exemplary message diagram for providing location based tag(s) in accordance with one embodiment.
  • FIG. 5B is an exemplary message diagram for receiving and filtering promotional information in accordance with one embodiment
  • FIG. 5C is an exemplary message diagram for transacting through a conversation thread in accordance with one embodiment.
  • FIG. 6 is an exemplary message diagram for engaging in a conversation thread in accordance with one embodiment.
  • FIG. 7 is an exemplary message diagram for broadcasting a message in a conversation thread in accordance with one embodiment.
  • FIG. 8 is a flowchart for an exemplary method of generating a communication link with offer(s).
  • FIG. 9 is a flowchart for an exemplary method of pausing and unpausing a conversation thread in accordance with one embodiment.
  • FIG. 10 is a flowchart for an exemplary method of snoozing or muting a conversation thread in accordance with one embodiment.
  • FIG. 11 is a flowchart for an exemplary method of deleting a conversation thread in accordance with one embodiment.
  • FIG. 12A is a functional block diagram of an exemplary communications network system in accordance with another embodiment.
  • FIG. 12B is a functional block diagram of searching with an exemplary communications network system in accordance with another embodiment.
  • FIG. 13 is a functional block diagram of an example system integrated with an experience engine.
  • FIG. 14 is an exemplary message diagram for providing experience engine enhanced tagging and offers.
  • FIG. 15 is a functional block diagram of a further example system integrated with an experience engine.
  • FIG. 16 illustrates an example taxonomy tree that may be included in the system.
  • FIG. 17 shows a process flow diagram for an exemplary method of generating a taxonomy.
  • FIG. 18 shows a process flow diagram for an exemplary method of searching with a taxonomy.
  • FIG. 19 shows a functional block diagram of an exemplary taxonomy engine.
  • FIGS. 20 - 36 show various interface diagrams implementing one or more of the features described.
  • One non-limiting advantage of the described systems and methods is self- discovery.
  • Self-discovery is directed to being searchable 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 the system searching, for example, the marketplace.
  • Each user of the system is able to define and associate tags with their account and device for other users to see.
  • Another non-limiting advantage of the described systems and methods is self-tagging.
  • 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.
  • contacts e.g., phonebook entry, other users' accounts, merchants, brands
  • interactions e.g., conversation, transactions, offers, content
  • features to provide a tag pack for users may be included.
  • Such a user may satisfy an initial condition (e.g., attract a minimum number of users, be tagged with a minimum number of tags, payment of a predetermined price) to acquire a tag for his business name, for example Plumbing2000.
  • an initial condition e.g., attract a minimum number of users, be tagged with a minimum number of tags, payment of a predetermined price
  • the system may then provide either an exclusive right to the user to this tag for a defined duration with an option to renew or it will be a shared tag that many users may tag themselves with
  • the system may present the user (e.g., the business owner) tag suggestions such as "Plumbing Deals" or "Plumbing Tips” related to the business tag, which he can also acquire.
  • the tag may then be submitted to the system for review and/or approval by automated and/or manual tags quality review. Once approved, the tag will be publically shown on business owner's profile when used making the business owner discoverable by the acquired business tag.
  • tag packs for a user may be provided once the user satisfies predetermined conditions, such as those discussed above. Once satisfied, the user may obtain a tag for his business name, for example, Plumbing2000.
  • the tag may be unique to the entire system or unique within a determined location.
  • the system may identify "generic tag packs" related to a business or service that the user is offering. At the time the tag is acquired, the system may identify these tags such as by using a taxonomy.
  • the system may also offer the user 1 tag pack along with the acquisition of the desired tag.
  • the system may provide a choice of different tag packs, such as 3 tag packs, to select from, wherein in each tag pack can include up to 10 tags the system has identified as being related to the product/service that the user sells/provides.
  • a Plumbing2000 unique tag owner may select a plumbing tag pack which includes "Drain Inspector", "Plumbing", "Clogged Drain”, etc.
  • the system may restrict the number of tags that can be active for a user from a given tag pack. For example, the user may select 5 of the 10 tags in the tag pack to be enabled and he has the option to edit the tags (turn one off, turn one on).
  • a user may submit a desired string for tagging their account such as "Garage Sale.”
  • the system may return 50 keyword (tags) for which are available to acquire.
  • These enhanced tags available for acquisition provide the following non- limiting benefits if acquired by the user: 1) an enhanced profile page for the user's account; 2) an enhanced listing of the user's account in other users' search results; and 3) a "chat" button directly associated to their listing.
  • the user may then satisfy the conditions to acquire the enhanced tags and the system may then apply the tags to his account.
  • Enhanced tags may include trademarks, unique business names, and registered tags.
  • a user may submit a desired string for tagging their account such as "Garage Sale.”
  • the system may allow the user to apply the tag (e.g., "garage sale") for free to her account.
  • the tag e.g., "garage sale”
  • she may want to purchase enhanced tags to advertise their garage sale.
  • the system may identify a tag pack available for acquisition.
  • an "IKEA" tag pack may be identified by the system for acquisition, wherein the tag pack IKEA may include up to 10 specific tags (that are only available for purchase), and the user may select all or a portion (e.g., 5) of the 10 available tags in the IKEA tag pack to be shown on the user's page.
  • the user is able to edit the tag pack once purchased (to add or remove tags), extend the tag pack ( to renew the purchase of tag pack for longer duration).
  • These tag packs may be suggested to be shared (available for purchase by multiple users), but they may also be exclusive tags sold to the user (to be available to him/her for exclusive period of time).
  • tags as one example
  • users can influence their searches submitted to the system. For example, the user may associate a tag with contact identified as potential business leads.
  • tags 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.
  • 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 influence searches for singers to include him in the result list.
  • Finding users or a conversation 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 or muting conversations, and adding or removing contacts from your network allow the system to provide dynamic realtime management of who, what, and where communications occur.
  • the system may be configured to request one or more tags from a user accessing the system via client device.
  • client device Using the client device, the user enters one or more tags and submits the tags to system.
  • 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.
  • 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 wireless or near-field connection, e.g., handshake, between a user-carried mobile token or fob and a location-specific machines, such as a vending machine, register, billboard, monitor, etc., or by transmitting biometric authentication information, such as fingerprint, retina, iris, voice, face, etc.
  • biometric authentication information such as fingerprint, retina, iris, voice, face, etc.
  • a client device may be provided to 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.
  • 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).
  • 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.”
  • a user's contact may have additional tags associated with them.
  • the system may be configured to automatically tag the contact based on information retrieved from third party systems such as social media sites. Once tagged, the contact can be searched by tag such as when you create conversation threads.
  • a conversation thread or a threadsite is a message session initiated by at least one user of the system whereby the user (or other target users) are allowed to add content to the message session (such as photos, texts, audio, video, etc.), modify or select settings related to the participants, communication stream (bidirectional or one-way communication) and settings related to the conversation thread (e.g., direct or blind carbon copy (BCC)).
  • BCC direct or blind carbon copy
  • a search may include multiple tags such as "male” and “photographer” and "L.A.”
  • the contacts retrieved may be included in an instant group conversation thread created from that three tag search. This may be referred to as personal relationship management.
  • a group chat may involve a number of participants ranging for example from 2 up to 250 participants, allowing any participant to access the history for a set period of time, such as 30 days.
  • a BCC chat may involve a plurality of participants, and the number of participants may depend on whether the participants are selected from their own contact list or from a search result.
  • the creator of a BCC chat may send a message to all participants, and replies may only involve the creator of the BCC chat and the participant sending the reply. In some embodiments, participants may not see each other's replies.
  • a broadcast message may be a type of unidirectional message that involves an unbound number of participants.
  • a threadsite may be a type of chat that can involve an unbound number of participants. Only the owner of the threadsite may publish content on it, and participants may only send comments to specific publications in the threadsite. In some embodiments, history of a threadsite may be kept for longer than 30 days.
  • 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.
  • 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.
  • 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.
  • 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.
  • the client device may be configured to search for users by tags.
  • Conversation threads can be created and filtered based on bidirectional information.
  • the local tags can be used to filter users based on how the user sees the world.
  • global tags can also be used to filter users based on how each user wishes to be seen.
  • This bidirectional optimization enables efficient and flexible communications 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, group broadcast only (e.g., all recipients identified, no responses permitted).
  • Bcc group "blind carbon copy”
  • the system may be configured to pause communications.
  • Pausing communications generally refers to suspension of receipt of conversation item for a conversation thread.
  • 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 conversation thread.
  • 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 conversation thread by different types of media such as video, audio, or text.
  • 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.
  • 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).
  • 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,
  • the author may pause the conversation thread. In some implementations, this may pause the conversation thread for everyone included in the conversation thread. Later, the user may re-enable the thread to resume the conversation.
  • 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.
  • 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.
  • 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.
  • EMV Europay, MasterCard, Visa
  • 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).
  • ACH automated clearing house
  • 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.
  • mobile remittance may be consummated across two or more nations, which may be referred to as cross-border remittance.
  • a further non-limiting advantage of the systems and methods described is the combination of communications and transactions in a single platform.
  • 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 conversation thread with the friend.
  • the friend may transmit a video presentation of this great opportunity.
  • the system may identify that the conversation thread 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.
  • the system may provide an interface element to initiate and consummate the transaction.
  • the transaction may affect the transfer of the requested amount from an account associated with the user to the friend.
  • One aspect of the systems and methods described relate to messaging which is conducted via broadcasting hardware such as beacons, or other wireless transmitting devices.
  • broadcasting hardware such as beacons, or other wireless transmitting devices.
  • Examples include the mlBeaconTM and m2BeaconTM manufactured by Netclearance Systems, Inc. of Escondido, California. Further examples include the GimbalTM 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.
  • 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.
  • the broadcasting hardware may be configured to communicate with client devices or a communication server via one or more wireless communication protocols.
  • wireless protocols include WiFiTM, low power BluetoothTM, or iBeacon.
  • 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.
  • a beacon may be placed near the taco bar transmitting a coupon for a free dessert to customers who visit the taco bar.
  • the client device may receive the beacon signal awarding the customer the dessert credit.
  • 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.
  • the broadcasting hardware may include a native application configured to communicate with client devices and/or communication server as described in further detail herein.
  • a user can meet someone and exchange & start to communicate with a unique identifier (e.g., personal ID code) without giving up your personal information such as cell phone number, email, or mailing address.
  • a unique identifier e.g., personal ID code
  • the system is 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.
  • the systems and methods described allow the person to exchange personal ID codes.
  • the personal ID code may be entered into the system by each person and used to connect, communicate, and even transact with each other.
  • temporary relationships are commonplace. A limited time relationship may be formed between people based on projects they are working on, sales people they are dealing with, or events attended (e.g., conferences).
  • a user may disassociate with a person whom they no longer wish to interact with. This provides a polite way to end those relationships without having to take public (e.g., "unfriending") and potentially expensive (e.g., block them with your cell phone carrier) steps.
  • Communication may also enable broadcasting of tags or conversations throughout the system.
  • beacons or other communication means for example may serve as a location-specific portal to the network for the user to connect.
  • 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.
  • NFC near field communication
  • NCS networked computing systems
  • the system may also be configured to add automatic or inferred tags.
  • the automatic or inferred tags may be based on demographic information provided by the user such as during account creation, information from social media accounts linked by the user or publicly available, geo-location information such as GPS coordinates of the client device used to access the system, and the like.
  • the system is configured to associate the received 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).
  • 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 provides as an output ranked search results. The results are then displayed to user via the client device.
  • 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.
  • the user may transmit an identification of a contact to initiate a conversation thread.
  • the conversation thread 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, and transmit money.
  • a communication device comprising an access controller configured to receive credentials and provide access to a user account based on the received credentials, a contact manager configured to, for an accessed user account, 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 local descriptor is provided by the user account, wherein the private descriptor is searchable only for a search request for the user account, 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, a conversation module configured to receive a conversation rule identifying 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 the users, and a response time
  • a communication server comprising an account manager configured to receive user account information including credentials, a tag manager configured to receive public descriptors and private descriptors for a user account, a search engine configured to receive and execute search requests, wherein execution of a search request for the user account includes consideration of the public descriptor for the user account, and wherein execution of the search request from the user account includes consideration of the private descriptors for the user account, a conversation module configured to receive and transmit content between user accounts based at least in part on a conversation rule, the conversation rule identifying users to receive the content, available response actions to respond to the content, the response actions including a transaction, a receipt time period identifying a period of time the content may be accessible by the users, and a response time period identifying a period of time users may take an associated response action, and a transaction module configured to consummate a transaction between users based on a conversation between the users.
  • a method for generating a dynamic directory comprising receiving a request to create a public account descriptor for a user account based on one or more strings, generating the public account descriptor based on the one or more strings, associating the public account descriptor to the user account, wherein said associating of the public account descriptor is a factor for a public search, receiving another request to create a private descriptor based on another one or more strings, generating the private descriptor based on the another one or more strings, and associating the private descriptor to a contact of the user account, wherein said associating of the private descriptor is a factor for a private search.
  • a bidirectionally guided directory system comprising a user directory of user accounts, the user directory identifying a first association of a public descriptor to a user account, the user directory further identifying a second association of a private descriptor to a contact of the user account, a marketplace directory identifying a plurality of goods and services available, each available good or service associated with another public descriptor, and a search engine configured to receive a search request transmitted from a client device associated with the user account, the search request including a descriptor, and search the marketplace directory and the user directory based on the received search request, wherein the search of the user directory is based on a comparison of the descriptor included in the search request with the private and public descriptors associated with the requesting user account.
  • 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 has an application running locally that performs a set of functions that require communication with a server in order to support desired functionality.
  • the client application may be configured to allow users to input their desired request of the application, after which the request is sent to the server for processing.
  • the server 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 HOn).
  • client device 110a and the client device 1 1 On may be an electronic communication device configured to transmit and receive conversation items in a conversation thread.
  • client device 110 may be an electronic communication device configured to transmit and receive conversation items in a conversation thread. 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.
  • 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.
  • 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.
  • 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.
  • the network 190 is configured to facilitate machine-to- machine messaging for tagging and communication as described herein.
  • the system 100 includes on-site information device(s) 130.
  • the on-site information device 130 may be an electronic communication device configured to transmit messages at a location.
  • the on-site information device 130 may be implemented as a beacon.
  • the beacon may be configured to transmit and receive tagging and communication messages to the client device 1 10 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.
  • the on-site information device(s) 130 may communicate directly with the client device 110. In some implementations, the on-site information device(s) 130 may be communication with the client device 1 10 via the network 190.
  • the on-site information device(s) 130 may be configured by a site operator.
  • 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.
  • 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 conversation thread regarding an event at the site.
  • the conversation item may indicate a sale on a particular item.
  • the conversation item may identify the starting time for a performance.
  • the conversation item may be used to convey emergency information such as a fire, earthquake, or other time and location sensitive event information.
  • 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 some embodiments, the enterprise server 140 may be in communication with a third party marketing server (not shown). In another embodiment, the enterprise server 140 may be a third party marketing server, such as the server of the on-site store operator. For example, the third party marketing server may provide location based marketing services, through which the server may provide destination-specific, theme-based, and/or micro-location based information, offers, deals, guidance, instructions, etc. An example of such a third party service includes the Experience EngineTM (TE2), provided by the Experience Engine, Inc.
  • TE2 Experience EngineTM
  • the client device 110 may transmit and receive tags and communication information.
  • 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 1 10).
  • 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
  • the database 104 may store information in an encrypted format via encrypted communication medium.
  • the database may store information for a predetermined period of time.
  • the database 104 may store conversation archives up to 30 days and transaction history up to 7 years.
  • the database 104 and/or the communication server 102 may be implemented in a distributed system, in which there are more there are more than one databases 104 and/or communication servers 102.
  • the client devices 1 10 may be in communication with the various modules illustrated in FIG. 1 using an application programming interface (API).
  • API application programming interface
  • the client device 110 may be in communication with the enterprise server 140 (e.g., third party marketing server, or experience engine) using an application programming interface (API).
  • the experience engine may reside within the communication server 102 as a separate component.
  • a socket handler process may be created for that user of the client device 110.
  • chat messages targeted at a user of the client devices 110 may be delivered using the socket handler corresponding to the target user. If the message needs to be delivered to a disconnected user, a third-party push notification service can be used, for example.
  • the system 100 implemented in a distributed network may include one or more load balancers configured to distribute the load across all available instances of communication service, for example.
  • the load balancers based on hardware, ngihx, HAProxy, or other similar solutions.
  • the API layer may forward all re 1 quests to the service layer, and all incoming requests can be targeted either at a user or a chat.
  • distributed routing protocol may be deployed across all instances involved in the communication service. Every instance of the communication service, for example, can run several processes that implement the distributed look-up protocol.
  • each one of the processes can be responsible for an evenly distributed number of chat and socket handler processes, and these processes can be used to forward requests to the corresponding socket handler and chat processes based on, for example a routing key such as a chat or user identifier.
  • the service layer may include several chat processes, and a chat process can be responsible for managing all the communication to and from the chat it represents, as well as caching information concerning that chat to reduce the number of required database look-ups, for example.
  • the chat processes can be gracefully terminated after a period of inactivity and requests targeted at chats may require restoring a chat process from its persisted state.
  • the communication service may be implemented using the open telecom platform (OTP) framework.
  • the communication service may be implemented in a modular manner and can be interfaced using multiple methods such as TCP/IP sockets, HTTP representational state transfer (REST), or Websockets.
  • the communication service may be implemented in a service-oriented architecture and may consume other internal services for authentication and profile management and other services such as payment and analytics, for example.
  • the communication service may consume push notification service.
  • a mobile application which my reside in the client device 110, may maintain a bidirectional socket connection. For example, each connected user may have its own process, and each user's geocoordinates may be sent periodically and persisted.
  • device information and diagnostics can be captured on login.
  • transmitting and receiving tags and communication information may be implemented in a multi-node application for increased scalability.
  • each communication or chat service may be implemented in a node, and scaling the system may involve deploying a new node and adding it a cluster of char service nodes.
  • the multi-node communication service can be implemented in an architecture similar to Riak. For example, all data may be persisted on a Riak back-end, and the database may be based on a masterless system with eventual consistency.
  • the fulltext indexing service and geospatial search may be implemented with Solr, for example.
  • the core communication or chat service may have a 160-bit ring, which can be divided into equally sized partitions.
  • the communication service may include a fixed number of virtual nodes, or vnodes, and may have as many vnodes as partitions in the ring as each virtual node may be responsible for one partition of the ring.
  • the ring may be used to distribute the load across all the nodes used by the communication service.
  • the communication service may also include user and chat identifiers, which can serve as routing keys.
  • the requests handled by the chat service may target either a user or a chat, and requests can be routed to the vnode responsible for that user or chat.
  • the total number of partitions and vnodes may remain the same, for example, and the ring may be rearranged according to a new cluster structure.
  • the responsibility of a vnode on a set of users and chats may be handed over to another physical nodes as nodes join and leave the cluster.
  • the system may reduce the load on initially overloaded nodes and may balance loads in multiple servers, for example.
  • the communication server 102 may be implemented with multicore Linux servers clustered around services.
  • Riak database services may be implemented in multiple (e.g., 5 or more) physical boxes, and chat service can be implemented in multiple (e.g., 3 or more) servers scaling to dozens.
  • one or more load balancers may be implemented between mobile clients and the communication service and between the communication service and Riak.
  • firewall may be placed between communication service and Riak.
  • Some implementations may use SSL accelerators.
  • the communication server 102 may be configured to receive conversation threads for user accounts.
  • the conversation threads may be associated one or more tags.
  • the conversation threads may be associated with one or more user accounts.
  • the communication server 102 may be configured to also receive distribution information for a given conversation thread.
  • the conversation thread may not be distributed outside a predetermined set of users.
  • the conversation thread may have limited visibility such as only to users associated with a predetermined tag. Accordingly, when a user performs a search, the conversation thread may be provided if the tags (e.g., global and/or personal) associated with the user satisfy the distribution rules for the conversation thread.
  • the tags e.g., global and/or personal
  • the merchant may post a conversation thread 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.
  • the communication server 102 may further manage the distribution and life of a conversation. For example, the communication server 102 may pause, snooze or mute an ongoing conversation. The communication server 102 may also allow a conversation thread to be deleted. Receiving a message to delete a conversation thread 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. Managing conversation may utilize business logic for processing messages to each communication or chat room type, such as broadcast, BCC, threadsite, group chat, single, etc. The conversation thread may be database-backed, and the communication service described herein may provide a caching layer minimizing database load and decreasing latency for the users of the client devices 1 10.
  • 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.
  • 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.
  • the third party transaction server 150 and the transaction processing module 106 may be in data communication with an inventory management system (not shown).
  • the inventory management system may receive information about items or services to sell.
  • the IMS may be configured to transmit the details via an API to publish their items. Alternatively the item information may be owned/managed by the IMS with distribution centers throughout the country.
  • IMS may be a separate system or a component within the communication server 102.
  • the IMS may include a database to store product details (price, quantity, location, etc.). When integrated with the communication server 102, the database 104 may be used by the IMS.
  • the IMS is configured for communication with elements of the communication server 102 to provide current inventory information, specific items on offer, and details for offered items
  • the IMS data may be provided to improve the selection of tags or content/offers presented to a user. For example, if an offer is identified for a given user, it may be desirable to ensure the product referenced in the offer is available near the given user.
  • Elements which may obtain the IMS data include the tagging module, the conversation module, the transaction module, the content/offer module, and the rating module as described in further detail below.
  • 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.
  • 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.
  • 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 e.g., the user's conversations, and usage history for the user.
  • the trigger may include automatically detecting receipt of a user submitted search for a specific good or service.
  • the detection may be performed at the communication server 102 by, for example, the content/offer module 107.
  • a monitoring component may be installed on a communication channel used by the communication server 102 to receive search requests.
  • the monitoring component may be configured to automatically initiate a request to generate possible search results or offers for the user based on the user input or selection.
  • a log of past user activity may be assessed to identify searches results or offers for the user. For example, if the user has previously searched for iguana related items, the prevalence of the word iguana in an activity log for the user may be identified. This word may then be used to select offers related to iguanas.
  • the identified search results or offers may reside in a folder, may reside within a threadsite request, or another location within the software interface.
  • the location of the search results or offers may be specific to the user such that when a client device logged into the account associated with the user accesses the folder, the custom results or offers are presented for the user.
  • the offers may be filtered based on the geographic location of the client device and may use beacon technology to identify and/or provide offers.
  • a beacon may receive identifying information from a client device which allows the system 102 to determine the identity of the user.
  • the system 102 may identify a custom offer based on the identified user and the beacon which is in contact with the client device.
  • the offers may be provided via the beacon or out-of-band such as via a wireless communication network.
  • the demand may be based on proximity sensing via a beacon.
  • a merchant may deploy a beacon within a store.
  • 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.
  • 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).
  • 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
  • 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.
  • 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.
  • 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.
  • 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 conversation thread 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.
  • the presentation may be via the messaging application on the client device 1 10.
  • 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.
  • 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.
  • the rules for identifying an offer or search result may be specified using configurable logic.
  • a user interface may be provided which allows merchants to identify conditions and terms for offers for dynamic provision.
  • the parameters may include top search term(s), recent search term(s), location identifier, beacon identifier, client device identifier, client device type, account characteristic (e.g., gender, name, mailing address, email address, social media account), or the like.
  • account characteristic e.g., gender, name, mailing address, email address, social media account
  • a merchant may build sophisticated, target marketing campaigns easily. For example, a pet store owner may define an offer of 10% off for users who submitted a search including an animal as a keyword.
  • the pet store owner may also be aware that owners of Bedlington terriers tend to spend more money on their dogs than the average dog parent. Thus, the pet store owner may identify an offer of 20% off for users who submitted a search including the word "Bedlington.” Prioritization, ranking, conditional logic, and other logical operators may be supported as part of the offer identification process.
  • 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.
  • FIG. 2A 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.
  • the elements shown may be configured to provide tagging and communication services via the client device 110.
  • a tagging module 210 is included, and to support third party application integration, a tagging interface module 215 can be 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.
  • 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 1 10 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.
  • the tagging interface module 215 may be in communication with a third party application on the client device 110 (FIG. 1) and the tagging module 210.
  • the tagging interface module 215 may be implemented with an API allowing the tagging features described herein to be integrated with the third party application it communicate with.
  • the tagging interface module 215 may be over a push notification service allowing users of the client device 110 (FIG. 1) who do not have an open process with the communication server 102 to interact with the system 100.
  • the tagging interface module 215 may enable provision of suggested tags to a user of the client device 110 based on the location of the user of the client device 110.
  • the tagging interface module 215 may further be in communication with a third party marketing service server discussed in connection with the enterprise server 140 in FIG. 1.
  • a user of the client device 110 (FIG. 1) may enter a business location, such as a theme park. As the user enters the theme park, which may have an on-site information device 130 near its entrance, the user may be provided with a suggested set of tags within a third party application specific to the theme park.
  • the user may get a list of suggested tags such as “rollercoaster ride,” “smoothies,” “live music,” “interactive museum,” “balloons,” “gift shop,” “games,” etc. that are specific to the theme park.
  • the merchant of the business may have an option to edit what tags should be suggested to its customers as they enter the premises. For instance, available offers by the merchant at the same business local may change over time and/or based on the season.
  • the user of the client device 110 (FIG. 1) is provided with suggested tags, the user may select or deselect the suggested tags so that the selected tags would be associated with the user within the system 100 (FIG. 1). In some instances, the user of the client device 110 (FIG.
  • One non-limiting advantage of the features described above may include integration of the tagging system disclosed herein with a third party application as the user need not initially be actively in communication within the system 100 (FIG. 1).
  • 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.
  • the client device 110 may be configured to operate without a network connection (e.g., "offline").
  • the client device 110 may receive tag information (e.g., new tags, updated tags).
  • 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.
  • a timestamp may be applied to the record.
  • 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.
  • 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.
  • the synchronization module 230 thus far has described synchronization between a client device and a communication server.
  • the client devices are sales associate electronic communication devices (e.g., point-of-sale tablet) at a store
  • This provides a non- limiting advantage of allowing all associates to share information and enhance a customer's experience.
  • 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.
  • 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).
  • 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.
  • the synchronization module 230 may also be configured to coordinate conversation threads.
  • 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 conversation threads to be communicated from the client (e.g., the client device 1 10 in FIG. 1) to the database 220.
  • the conversation module 240 may handle client requests to create a conversation thread 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 conversation thread 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.
  • Another distribution rule may be to remove a conversation. Once removed by the initial author, all copies of the conversation thread 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 conversation thread may be deleted from the system. This affords, as one non-limiting advantage, robust control over various conversation thread or threadsite campaigns.
  • the conversation module 240 may be configured to receive additional content contributed to the conversation.
  • the additional content may be stored in the database 220.
  • the additional content may be presented such as via a graphical user interface.
  • the conversation module 240 may provide a conversation thread or threadsite indicating additional content has been received.
  • 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!
  • the conversation module 240 may generate the conversation thread based on the conversation information (e.g., sender, content).
  • the conversation information may include a summary for quick display.
  • a client device may operate offline. In such circumstances, conversations may be read, responded to, deleted, or started.
  • the conversation information 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.
  • the electronic communication system 200 may include a transaction module 260.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the search module 250 uses the identified terms and attributes to perform 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.
  • 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.
  • 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.
  • a tag may be associated with many users.
  • 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.
  • 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.
  • the tags managed by the system 102 may include authored tags.
  • Authored tags generally refers to tags that are pre-defined by the system 102.
  • Authored tags may be presented via the client device with specific color, format, or label.
  • An authored tag includes a unique identifier.
  • the tag application on the client device may transmit a message to the system 102 to automatically purchase the item/service referenced by the authored tag.
  • the authored tag is pre-associated with a unique item or service and the user is pre-associated with a confirmed payment method and shipping address.
  • the client device provides the user and tag information to automatically fulfill a purchase.
  • the item/service may be automatically triggered for shipment to the user's previously confirmed shipping address.
  • the transaction module 106 may be configured to detect activation of an authored tag and transmit the request including the authored tag and user account identification information when implemented on the client device.
  • the transaction module may be configured to receive the requests for purchase and imitate consummation of the transaction for the identified item/service and user based on the information received in the request.
  • 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.
  • beacons may be deployed to transmit tags or other communications to devices which enter a predetermined area.
  • 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 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • the transceiver 294 may include one or more of an antenna, a network interface controller, a signal generator, an amplifier, and a signal filter.
  • the elements provide services which mirror those described in reference to the client device above.
  • 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.
  • the search optimization module 252 for the communication server 120 may be configured to differentially optimize searches for each user.
  • 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.
  • 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.
  • FIG. 2B is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 2A.
  • 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. 2 A) 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.
  • FIG. 3 is an exemplary message diagram for creating tags in accordance with one embodiment.
  • the message flow of FIG. 3 shows messages exchanged between several entities which can be included in a communication system.
  • 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.
  • the tagging module 210 may be implemented in the communication server 102 and/or the client device 1 10 (FIGS. 1-2B).
  • Messaging 302 may be performed to create a new user account and can be performed by accessing the database 220.
  • the client device 110 may send identifying information, such as name, location, school, job title, etc., of the user's existing online accounts for social networking services (e.g., FacebookTM, TwitterTM, Google+TM, etc.) or any other online services such as e-mail accounts, additional personal information, and new account information such as ID and password with the service provider of the communication server 102.
  • social networking services e.g., FacebookTM, TwitterTM, Google+TM, etc.
  • connection information e.g., username, password, address
  • the user may only be given an option to create a new account with the service provider.
  • existing online account information may be automatically searched based on user-provided profile information (e.g.. name, age, gender, location, school, work, name of business, place of business, industry, etc.), and the user may be prompted to link the automatically searched existing online user personal or business accounts.
  • user-provided profile information e.g.. name, age, gender, location, school, work, name of business, place of business, industry, etc.
  • a new user account space may be created in the database 220 to store further information about the user of the client device 110.
  • the user account may be further linked to the user's existing online account and additional information provided by the user of the client device 1 10.
  • Messaging 304 may be performed to create an automatic user ID specific to the new user of the service.
  • the automatic user ID may function as a unique identifier of the user in the system 100 and may further function as a public identifier of the user.
  • the automatic user ID may also be the only public identifier of the user as the user may change privacy settings associated with the user account.
  • the automatic user ID may be linked to the newly created user account in the database 220.
  • the communication server 102 may automatically generate and assign an internal user ID.
  • the automatic user ID may be of random alphanumeric characters.
  • Messaging 306 may be performed to access existing user information from the user's existing online accounts through the network 190. Messaging 306 may further involve one or more modules to search, request, or select relevant user data from the existing user in the user's existing online account information. Such information may include searches or other system activity of the user.
  • Messaging 308 may be performed to gather existing user information from the user's existing online accounts through the network 190. Messaging 308 may further involve one or more modules to parse and organize the received existing user information to optimize storing the information in the database 220. The new user account and ID created in response to the messages 302 and 304 in the database 220 may be linked to the received existing user information.
  • Messaging 310 may be performed to create automatic tags based on the user information associated with the newly created user account in the database 220.
  • the received existing user information may be automatically forwarded from the database 220 to the tagging module 210 for the tagging module 210 to generate one or more new tags.
  • the user may be prompted with pre-populated potential tags and asked to confirm creation of the pre-populated tags.
  • the tagging module 210 may generate one or more tags based on the user information associated with the user account in the database 220;
  • the tagging module 210 may be configured to parse user information to generate one or more new tags, and it may be further configured to determine the optimal key words or phrases so that the new tags are not redundant and yet adequately represent automatically gathered user information, for example.
  • an experience engine (not shown) may be included.
  • the tagging module 210 may be configured to generate the one or more new tags based on one or more inputs from the experience engine as described in further detail below such as with reference to FIGS. 13-15.
  • Messaging 312 may be performed to store the newly generated tags in the database 220.
  • the newly generated tags may be linked with the user account created in response to message 302.
  • the new tags may be further linked with one or more existing tags associated with other user accounts in the database 220 to facilitate searching of the tags and associating of the tags with related key words or information.
  • a search index in the database 220 may be updated reflecting the addition of the new tags and their association with the new user account.
  • the use may further make a public self tag request, and messaging 314 may be performed to generate one or more public self tags through the tagging module 210.
  • the user may select and input on the client device 110 one or more words or phrases to create public self tags, which may be self-descriptions the user would like to be associated with.
  • the client device 1 10 then may send the user inputted words or phrases and request the tagging module 210 to create public self tags based on the words or phrases.
  • the client device 110 may display a message to the user suggesting a better tag words or phrases.
  • 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.
  • the user may be allowed to override the tagging restrictions, and in another embodiment, the user may be allowed to override only some of the tagging restrictions.
  • the tagging module may generate one or more tags based on the user inputted words or phrases.
  • the tagging module 210 when integrated with an experience engine (not shown), may generate the one or more tags based on an input from the experience engine.
  • Messaging 316 may be performed to store the user generated public self tags in the database 220.
  • the public self tags may be linked to the user's account in the database 220 so that searching for the tags, for example, would lead to the user account.
  • messaging 318 may be performed to update a public search index.
  • the public search index may be one of many search indices in the database 220 and may link and organize various tags to optimize public searches.
  • a public search may be for searching the entire user accounts in the database 220 regardless of whether the search requester has any connection with the users of the user accounts.
  • a public search may be for searching the entire user accounts except the ones listed in the search requester's contacts.
  • a public search may be searching the entire accessible conversation threads in the database 220 regardless of the search requester's involvement in the conversation threads.
  • a public search may be tailored to the search requester's user account.
  • a public search may universal to all the user accounts in the database 220.
  • the user may connect with other users in the system 100 and request to add one or more private contact tags to those other users, and messaging 320 may be performed to generate private contact tags through the tagging module 210.
  • the user may input through the client device 110 one or more words or phrases to generate private contact tags, which may be associated with one or more of the user's contacts.
  • the private contact tags are user-specific, and they may reflect the user's own description of the contact only available to the user.
  • Messaging 322 may be performed to store the private contact tags created by the user in the database 220.
  • the private contact tags may be linked to the user account to allow only the user linked to the private contact tags can view the private contact tags, for example.
  • messaging 324 may be performed to update a private search index.
  • the private search index may be one of many search indices in the database 220.
  • the private search index may be linked to the user account in the database 220 to allow the user's exclusive access to the private contact tags.
  • the database 104 may store the social network data based on the tagging by the users. For example, a graph database may be implemented using Neo4J, storing relationships between users and the likes of and/or commonalities between multiple users.
  • FIG. 4 shows a messaging diagram for an example synchronization session between a client device and a communication server. While the messaging diagram of FIG. 4 shows messages between a client synchronization module 402 and a server synchronization module 404, it will be appreciated that other intermediary elements may be included. For the sake of clarity, these intermediaries have been omitted from the discussion of FIG. 4. In some embodiments, the synchronization session illustrated in FIG. 4 may be implemented in conjunction with push notification services that may be available while the user of the client device 110 (FIG. 1) is not in active communication within the system 100 (FIG. 1).
  • the synchronization session may be used to transfer information obtained while a client device is off line.
  • the information may be obtained at the client device or received from other users at the communication server.
  • both the client and server may be configured to synchronize to ensure the real time search and discovery is maintained.
  • the client synchronization module 402 receives one or more tags from the client device 1 10 (FIG. 1). Via message 452, the tags are stored locally. In storing the tags locally, the client synchronization module 402 may include information indicating that the tags have not been communicated to the server.
  • the client synchronization module 402 receives one or more conversations. Via message 456, the client synchronization module 402 locally stores the conversations. As with the tags, the conversations may be stored in association with information indicating the conversations have not been communicated to the server. As shown in FIG. 4, the server synchronization module 404 may also receive tags and conversations via messages 458 and 460, respectively, while the client is disconnected. [0142] At a point in time, the client device may connect to the communication server. Via message 462, a connection between the client synchronization module 402 and the server synchronization module 404 is established. Establishing a connection may include transmitting a message identifying the client device and a user account for which synchronization is to be performed.
  • the tags to be synchronized are transmitted to the server synchronization module 404.
  • the server synchronization module 404 is configured to process the updated tag information via message 466. Processing the updated tag information may include validating the received tags, updating the database for the received tags, triggering re-indexing, triggering the rebuild of a social graph, triggering the regeneration of search metadata, or the like.
  • the update may include adding new tag, deleting a tag, or modifying a tag for a contact, conversation, or user account.
  • Processing the tag update may also include reconciling the updates received from the client device with any tag information received while the client device was disconnected.
  • the reconciliation process ensures that redundant tags are not stored, thereby conserving resources such as processing time, power, and memory.
  • the server synchronization module 404 may be configured to transmit tags to the client synchronization module 402. For example, a contact included in the contact list at the client device may update their global tags with the server while the client device is offline. Accordingly, when the client device reconnects, the new tag information may be transmitted to the client device such as via message 468.
  • a similar process is performed for conversations whereby via message 470 conversations identified for synchronization are transmitted to the server synchronization module 404 and processed via message 472. Any conversations including the user of the client device which are updated while the client device was offline will be provided to the client synchronization module 402 via message 474.
  • FIG. 5A is an exemplary message diagram for providing location based tag(s) in accordance with one embodiment.
  • the message flow of FIG. 5 A shows messages exchanged between several entities which can be included in a communication system.
  • 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.
  • Messaging 501 may be performed to detect a presence of the client device 110 by one of the on-site information device(s) 130.
  • the on-site information device 130 may be a beacon configured to detect the client device presence through Bluetooth, Wi-Fi, or other wireless technology.
  • the on-site information device 130 may detect the presence of the client device 110 through Wi-Fi and receive the MAC address of the client device 110 for further a processing of the user data in conjunction with the user profile data already available in the database 220.
  • the implementation using the Wi-Fi technology may allow the system 100 long-term tracking of the user activities and behavior by identifying the user of the client device 1 10 through the on-site information device(s) 130.
  • messaging 501 may be specific to one or more on-site information device(s) 130 designated at certain locations, such as at or near the entrance of business premises, to initiate an engagement with incoming customers.
  • Messaging 502 may be performed to launch a third party application on the client device 110.
  • the third party application may be a location or brand-specific application by a merchant similar to the one described in connection with FIG. 1 above.
  • the third party application may be a theme park application providing guidance, directions, information, or offers within the theme park.
  • the third party application may be an application related to a brand of a merchant, and the application may be used at the merchant's stores, for example.
  • the user of the client device 110 may launch the third party application.
  • the third party application may be promoted to the user upon the user's entry to the active premises, such as a store, park, museum, etc., having one or more on-site information device 130.
  • the system disclosed herein may initiate the promotion of the third party application on the client device 1 10.
  • a message 503 may be transmitted from the client device 110 to the tagging interface module 215 to initialize the client device 1 10 for receiving tagging suggestions.
  • the initialization may include transmitting an identifier for at least one of the client device 110 and a user account for a user of the client device 110.
  • the initialization may, in some implementations, also include providing one or more of a location of the client device 110, an identifier for the on-site information device 130 which detected the client device 110, or a characteristic of the client device 110 (e.g., power level, radio access technology, signal strength, bandwidth, operating system, orientation).
  • the tagging interface module 215 may retrieve tag set suggestions via messaging 504.
  • the tag set suggestions may be selected based on the parameters provided during initialization.
  • a parameter provided during initialization may provide a "key" to obtain other data elements. For example, if a user account identifier is included in the initialization parameters, the user account identifier may be used by the tagging interface module 215 to obtain activity information (e.g., recent search terms) for the identified user account.
  • the tagging interface module 215 may identify tag set suggestions by querying the database 220.
  • the tagging interface module 215 may be configured to obtain tag set suggestions, or inputs to the selection thereof, from an experience engine.
  • the tagging interface module 215 may be commonly implemented with the tagging module 210.
  • the tagging module 210 may be configured to interface with third party services, such as enterprise servers, inventory management systems, or experience engines.
  • the tagging interface module 215 may identify the suggested tags based on a public descriptor request message.
  • the public descriptor request message may include a value indicating a tag the user wishes to associate with their account as a public descriptor.
  • An attribute of the user account such as number of public descriptors, transaction consummation history, authorization, and/or accreditation may be used to suggest the tags.
  • each potential suggestion may be associated with an eligibility criterion.
  • the tagging interface module 215 may compare the user account attribute or attributes with the eligibility criterion. If the comparison indicates the user account is eligible, the associated tag is included in the set of suggested tags.
  • messaging 506 may be performed to send the identified tag set suggestions by the tagging interface module 215.
  • Messaging 506 may provide the client device 110 with suggested tags including pre-defined tags or tag packs (i.e., group of associated tags).
  • the user may open or log in to a third party application associated with a place of business, and the tagging interface module 215 may push suggested tags for the user of the client device 1 10 to choose from.
  • the tagging interface module 215 may be otherwise integrated or in communication with the third party application to present suggested tags to the user of the client device 1 10.
  • the owner of the business associated with the third party application may select which tags should be presented to the users with the on-site information device(s) 130.
  • the business owner may have specific offers available to its patrons at specific times and may decide to promote the time- and/or location-specific offers to the customers.
  • the business owner may be presented with a set of tags automatically suggested by the communication server 102 based on the type of business the owner has. In such embodiments, the business owner may further tailor the suggested set of tags to be presented to the users of the client device 110.
  • the tag suggestions to the business owner and/or the customers may be determined based on taxonomy or other similar methods or systems of organizing or categorizing various tags.
  • the tagging interface module 215 may be implemented with a push service triggering a prompt for the tag suggestions to the user of the client device 110.
  • Messaging 508 may be performed to send user selection of one or more of the tags suggested through messaging 506.
  • the user of the client device 110 may be presented with a set of suggested tags within a third party application, which may be associated with the location of the on-site information device 130, and in turn, the current location of the client device 1 10.
  • the user may be prompted to open a dedicated application implementing the features described herein.
  • the user may select tags from the list of suggested tags based on the user's preference, likes, or need.
  • the user may be given an option to select all the tags suggested allowing minimal interaction between the user and the third party or dedicated application presenting the tag suggestions.
  • Messaging 510 may be performed to request to tag the user's account with the user selected tags.
  • the tagging interface module 215, for example, may run in the background of the client device 110 and provide an interface between the third party application and the various features of the system 100 (FIG. 1). Messaging 510 may function in a similar matter as messaging 314 for self tag request as discussed in connection with FIG. 3 above.
  • the tagging may include generating tags based on input from an experience engine (not shown).
  • Messaging 512 may be performed to store tags and link the tags to the account of the user of the client device 110. Messaging 512 may be performed in a substantially similar manner as messaging 316 can be performed as discussed in connection with FIG. 3 above.
  • Messaging 514 may be performed to update tag index associated with the account of the user of the client device 110. Messaging 514 may be performed in a substantially similar manner as messaging 318 can be performed as discussed in connection with FIG. 3 above.
  • Messaging 516 may be performed to send results summary to the client device 110.
  • the user of the client device 110 may be presented with a feed or result summary that is consistent with the tags selected by the user after messaging 506 described above has provided the user with a set of suggested tags.
  • users associated with a suggested tag may be given priority in how they are displayed when included in a search result set. For example, when a search request is submitted by a third-party, a user account associated with a suggested tag along with user accounts who are not associated with the suggested tag may be included in the results. In such instances, it may be desirable to prioritize the user account associated with the suggested tag over the other user accounts. This prioritization may include how the user accounts are ordered within the result set, how the accounts are ranked within the result set, how the accounts are displayed on the requester's communication device, or a combination thereof.
  • a timer may be initiated once the tag is associated with the user account. Upon expiration of the timer, the user may be notified of the expiration and prompted with instructions to renew the tag.
  • FIG. 5B is an exemplary message diagram for receiving and filtering promotional information in accordance with one embodiment.
  • the message flow of FIG. 5B shows messages exchanged between several entities which can be included in a communication system.
  • 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.
  • Messaging 522 may be performed to detect a presence of the client device 110 by one of the on-site information device(s) 130. Messaging 522 may be performed in a similar manner as messaging 502 can be performed as discussed above in connection with FIG. 5 A. In some embodiments, messaging 522 can be performed with the on-site information device(s) 130 that are places at certain location of interest within business premises to continue engaging customers after initial engagement followed by messaging 502 above, for example.
  • Messaging 524 may be performed to request promotional information to eventually send to the user of the client device 110 from the on-site information device 130 upon the detection of the client device 1 10.
  • Message 604 may include information about the client device 1 10, such as the MAC address of the device, as detected by the on-site information device 130, such as a beacon.
  • Message 604 may also include information about the beacon itself, such as the location of the beacon and associated merchant of the beacon.
  • Messaging 526 may be performed to access the user account in the database 220 by the content/offer module 270 in response to the receipt of the promotional information request.
  • the content/offer module 270 may be configured to request to obtain, for example, user preferences, account information, tags, or filters linked to the user account to determine whether and what kind of promotional information the user would like to receive.
  • the client/offer module 270 may receive the requested client information including, for example, tags selected by the user from the suggested tags described in connection with FIG. 5A.
  • the client device 110 may not be associated with an account within the system. However, the device attributes may be identifiable and included in the client information. Even the absence of information for a client device can have meaning to a merchant such as to indicate this is the first time this customer device is in their store. This type of information can help tailor the interaction with this client device, at this merchant location, at this point in time.
  • Messaging 528 may be performed to generate promotional information, such as offers, by the content/offer module 270 once the content/offer module 270 receives client information, if any.
  • the promotional information may be generated by an internal or external targeting engine that processes user profile information, user-created tags, user activities, and other user-specific data accessible through the client information query, such as tags, from the database 220.
  • promotional information may consist of location-specific promotional information, such as a coupon relevant to one section of a mall.
  • Promotional information may consist of time-specific promotional information, such as a coupon that would expire in an hour. The promotional information may be selected based on the parameters provided in the request messaging 524.
  • a parameter provided in the request messaging 524 may provide a "key" to obtain other data elements.
  • the user account identifier may be used by the content/offer module 270 to obtain activity information (e.g., recent search terms) for the identified user account.
  • the content/offer module 270 may identify promotional information by querying the database 220.
  • the content/offer module 270 may be configured to obtain promotional information, or inputs to the selection thereof, from an experience engine. Examples of the features of such an integration are described in further detail below, such as with reference to FIGS. 13-15.
  • Messaging 530 may be performed to determine if the content/offer should be further filtered according to the filters or other preferences set by the user of the client device 110.
  • Message 530 may include information on or the nature of the offer(s) generated by the content/offer module 270 and the client identifying information, such as client account information, and client device information, such as the MAC address.
  • Messaging 532 may be performed to request filtering based on the filters stored and linked to the user account in the database 220.
  • a filter parameter may be based on one or more public or private tags described in connection with FIG. 3.
  • a filter parameter may also be based on the user's managing (e.g., pausing, snoozing, or deleting) a conversation thread described in connection with FIGS. 9-11 below.
  • the user may have an option to create a filter (not shown) and be asked to enter filtering parameters, and the client device 110 may send the filtering parameters along with the request.
  • a filter request may be pre-populated and be confirmed by the user based on the user's public or private tags and conversation thread management.
  • a filter may be automatically generated based on the user's public or private tags and conversation thread management.
  • a filter may be an entity internal to the search module 250 and/or the search optimization module 252 not viewable to the user.
  • a filter may be an entity viewable and alterable by the user.
  • some filters but not others may be viewable and alterable by the user.
  • further messaging may be performed to store the filter requested by the user of the client device 110.
  • the filter may be stored in the form of a tag.
  • the filter may be stored in the form of a conversation thread management (e.g., pausing, snoozing, or deleting, described in connection with FIGS.
  • the filter may be created separate from tags or conversation thread management but may still be based on tags or conversation thread management. In one embodiment, the filter may be created based on user inputted filtering parameters at the time of the user's filter request.
  • the filtering module 254 may store the filter in the database 220 and link the filter to the user account.
  • Messaging 534 may be performed to filter promotional information by the filtering module 254 once the user's existing filters in the database 220 are determined and a filtering query is sent to the filtering module 254.
  • filtering may be based on the tags or conversation thread management (e.g., pausing, snoozing, or deleting, described in connection with FIGS. 9-11 below).
  • filtering may be based on separate user-specified filtering parameters. Based on the user's filters and the promotional information it received from message 530, the filtering module 254 may be configured to determine whether the promotional information should be presented to the user as is, presented with some information blocked, or not presented at all.
  • Messaging 536 may be performed to send filtered promotional information to the on-site information device 130.
  • the filtering module 254 processes the promotional information data based on the user's filters
  • the filtered promotional information may be sent to the on-site information device 130 to be eventually presented to the user of the device 110.
  • the promotional information may not be displayed at all.
  • the promotional information may be filtered to display only new car sales information.
  • the promotional information may not be presented to the user of the client device 110.
  • Messaging 538 may be performed to provide offers to the client device 110.
  • the transmission of promotional information may be in the form of a conversation thread.
  • the promotional information may be a publicly tagged conversation thread, which may be searchable by the users of the system 100.
  • the transmission of promotional information may be in the form of a locked conversation thread privately tagged by the merchant, established only between the user of the client device 110 and the merchant.
  • the transmission of promotional information may be in the form of a sponsored conversation item or thread or advertisement distinct from a conversation thread.
  • the transmission of the promotional information may trigger a prompt to the user of the client device whether to accept or rejection to receive the promotional information.
  • the transmission of the promotional information may require the client device 110 to determine whether any prompt to the user may be displayed. The client device 1 10 may be configured to make such determination based on the account information of the user of the client device 110.
  • One non- limiting advantage of the system is bidirectionally tailored communication between merchants and customers.
  • on-site information devices such as beacons in conjunction with the communication system, such as tagging or selecting suggested tags, disclosed herein
  • merchants may easily gather, track, and process customer data to tailor promotional information to individual customers.
  • customers may influence and manage how the tailored promotional information is presented to them through the highly-personalized communication platform disclosed herein.
  • FIG. 5C is an exemplary message diagram for launching a communication and transaction link in accordance with one embodiment.
  • the message flow of FIG. 5C shows messages exchanged between several entities which can be included in a communication system.
  • 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.
  • the conversation module 240 and the transaction module 260 may be implemented in the communication server 102 and/or the client device 110 (FIGS. 1-2B).
  • Messaging 550 may be performed to launch and engage in a third party application on the client device 110.
  • the third party application on the client device 1 10 may be similar to the third party application discussed in connection with FIG. 5A above.
  • the client device 110 may be configured to process the user interaction with the third party application in conjunction with tags associated with the user of the client device 110.
  • the tags associated with the user may be, for example, tags the user added through a process similar to the one discussed in connection with FIG. 3, or tags the user selected through the process described in connection with FIG. 5A.
  • integrating the tagging features described herein with the third party application on the client device 110 may be implemented using an API.
  • Messaging 552 may be performed to access and search relevant portions of the database 220 by the client device 1 10 either through a third party application or a dedicated application implementing the features disclosed herein.
  • the client device 110 may request to access the database 220, in which the data associated with the tag are stored.
  • the data associated with the tag may include user account information, preferences, and transaction related information, such as credit card information, for example.
  • the client device 110 may be in communication with a credentialing module (not shown) to receive and verify credential information of the user of the client device 110.
  • user preferences may include conversation thread modes and preferences set by the user as further described in connection with FIGS. 6-1 1 below.
  • Messaging 554 may be performed to return the tag data accessed through message 504.
  • the database 220 may return data such as user information, such as tags added or selected, and conversation thread preferences associated with the user of the client device 110 to facilitate creation of a conversation thread in accordance with the user information and the user's conversation thread and mode preferences between the user of the client device 110 and a merchant, for example.
  • the merchant of a business location may be associated with the third party application, and the merchant may have access to the user tag data accessed through the third party application.
  • Messaging 556 may be performed to create a conversation thread based on the tag data gathered from the database 220.
  • the client device 110 may send a request to the conversation module 240 to create a conversation thread based on, for example, tag-based offers prompted in the third party application.
  • the third party application may initiate a launch of a separate dedicated application implementing the features described herein.
  • the user-tag association information may be integrated in or imported to the third party application to facilitate communication between the user of the client device 110 and the merchant, for example.
  • Messaging 558 may be performed by the conversation module 240 to create a conversation thread based on the conversation request from the user of the client device 1 10.
  • the conversation module may create a communication thread to which multiple users of the system 100 may be added.
  • the conversation thread may also be stored in the database 220.
  • the conversation thread may be linked to all the participants of the conversation, and in another embodiment, the conversation thread may be only linked to the conversation requester.
  • the conversation module 240 may be configured to allow two or more participants to send and receive instant conversation items including text, audio, video, image, other content, etc. through the conversation thread.
  • the conversation module 240 may be configured to limit the thread participant's ability to reply to the communication, view other thread participant, and/or add additional participants.
  • the conversation module 240 may be implemented with one or more sockets. Further details of socket based implementation of the conversation module 240 are illustrated in and described in connection with FIGS. 6-7 below.
  • Messaging 560 may be performed to request a transaction between the user of the client device 110 and a merchant as participants of the conversation thread.
  • the user may decide to transact with one of the participants.
  • the user may create a transaction channel associated with the conversation thread.
  • the conversation thread may have embedded transaction options for the user to choose from.
  • a transaction channel may have been created when the conversation was tagged by the user or other participants as a transactional thread.
  • the user of the client device 110 interacts with the third party application or the dedicated application, the user may be presented with a tagged button or icon that says "buy” and then may decide to transact with the creator of the tagged icon.
  • a single input can be used to create a conversation thread to consummate the transaction.
  • the conversation thread may have embedded transaction options for the user to choose from.
  • the user may be prompted to add the amount of money to be exchanged and the method of exchanging money.
  • the transactional information e.g., amount of money, method of payment, etc.
  • 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.
  • Messaging 562 may be performed to send transactional information to the network 190 to consummate the transaction initiated by the user of the client device 110.
  • the transaction module 260 may be configured to forward that information to a different server (e.g., the third party transaction server 150 in FIG. 1) through the network 190.
  • a single transaction may involve more than one transaction server and may involve more than one message similar to messaging 562.
  • Messaging 564 may be performed to report back to the transaction module 260 to indicate whether the transaction requested by the user of the client device 110 was successful.
  • the third party transaction server 150 may be configured to send a confirmation code or a receipt number upon completion of the transaction.
  • more than one server may be involved in the transaction, and there may be more than one message such as messaging 566 to consummate the transaction.
  • 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.
  • 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) without messages 564 and 566.
  • 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) be received by the transaction module 260 implemented in the client device 110 (FIG. 1) from the network 190 in order to finalize the transaction.
  • Messaging 566 may be performed to send a transaction complete report to the client device 110 in response to the transaction initiation by the user of the client device 110.
  • 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 110 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.
  • 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.).
  • 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.
  • FIG. 6 is an exemplary message diagram for engaging in a conversation thread in accordance with one embodiment.
  • the message flow of FIG. 6 shows messages exchanged between several entities which can be included in a communication system.
  • 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.
  • “socket,” “push service,” “ring manager,” “vnode,” and “chat” can be imp and the transaction module 260 may be implemented in the communication server 102 and/or the database 104 (FIGS. 1-2B).
  • a group chat which may involve a plurality of participants, may be implemented, and any participant may be able to access the chat history for a predefined number of days, for example.
  • a chat may involve
  • the user may select one or more of the entries (e.g., other personal users, business users, etc.) in the search result, and the client device 110 (FIG. 1) may request to create a conversation thread.
  • the user may select one or more entries from the public search result to start a conversation thread.
  • anyone who joins the conversation thread may invite and add others.
  • the user may select to create a locked conversation thread, which may limit adding a new participant to the conversation thread.
  • the user may select to create a broadcast conversation thread, which only allows one-way communication from the user to other participants of the thread.
  • An example implementation of a broadcast conversation thread or channel is illustrated in FIG.
  • the user may select to blind carbon copy (BCC) the conversation thread recipients so that a recipient may not be able to view other conversation recipients who received the same conversation item through the conversation thread.
  • the client device 110 (FIG. 1) may be configured to receive from the user all the requisite and optional inputs for creating a conversation thread and may send a conversation request based on the user's inputs.
  • the communication between the chat service and the mobile application may occur over an open socket or using a push notification service. Users of the client device 110 (FIG. 1) or "mobile" in FIG. 6, may run an application implementing the features disclosed herein in the foreground. Such users may have an open socket to the chat server, or the communication server 102 (FIG. 1).
  • the users in other instances may run the application in the background, or not running the application at all. Such users may be reached using a push notification service, "Push Service.”
  • the open socket may be used to deliver messaged from the communication server 102 (FIG. 1) to the mobile application of the client device(s) 1 10 (FIG. 1). Notifications may be sent over the push notification service, and in some embodiments, the notifications may include al information required to fetch the messages they refer to.
  • socket based communication may be more prevalent for group chats while push notification may be more prevalent for the BCC and broadcast messages as illustrated in FIG. 7.
  • a chat item may have various attributes associated with it, such as type, time created, time modified, owner, title, list of participants, conversation rules (such as locked, paused, snoozed, or muted), and message content.
  • a chat item may include attributes that are set by the communication server 102 (FIG. 1) such as the chat id, time created, time modifier, owner, and last message. Some attributes of a chat item may be have a default setting, and a chat item, for example, may be unlocked, unpaused, and unmuted by default when created.
  • a message item may be associated with a chat identified with a chat id, and may have various attributes associated with it, such as author, type, content, sent time, edited time, or flagged.
  • FIG. 7 is an exemplary message diagram for broadcasting a message in a conversation thread in accordance with one embodiment.
  • the message flow of FIG. 7 shows messages exchanged between several entities which can be included in a communication system.
  • 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.
  • “socket,” “user manager,” “broadcaster,” “push service,” “ring manager,” and “vnode” be imp and the transaction module 260 may be implemented in the communication server 102 and/or the database 104 (FIGS. 1-2B).
  • FIG. 8 is a flowchart for an exemplary method of generating a tag based offers.
  • the method shown in FIG. 6B may be implemented in whole or in part by one or more of the tagging module 210 (FIGS. 2A-2B), the content/offer module 270 (FIGS. 2A-2B), the launch module 254 (FIGS. 2A-2B), and the database 220 (FIGS. 2A-2B) in communication with one another.
  • one or more tags from the user may be received.
  • the user may decide to tag oneself with the subject matters of the user's interest.
  • Such tagging by the user may be accomplished through the tagging module 210 (FIGS. 2A- 2B) in a manner similar to the messages discussed in connection with FIG. 3 above.
  • the user may have created or selected tags such as "smoothies" or "gift shop deals,” which may show the user's interest in offers regarding smoothies or gift shop deals.
  • an offer generation request may be received.
  • the on-site information device 130 may detect the client device 110 (FIG. 1) of the user nearby and send the offer generation request to the communication server 102 (FIG. 1).
  • the offer generation request may be implemented in the form of a conversation thread launch request to the communication server 102 (FIG. 1) in a manner similar to the messages discussed in connection with FIG. 6A above.
  • tailored content/offer may be generated based on the previously received tag(s) from the user.
  • the content/offer module 170, 270 may generate tailored content and offer for the user of the client device 110 (FIG. 1). For example, if the user may have created or selected tags such as "smoothies" or "gift shop deals” as discussed above, the content/offer module 170, 270 (FIGS. 1-2B) may generate offers related to smoothies or gift shop deals for the user.
  • the tailored content/offer may be sent to the user.
  • the user may be presented with a stand-alone offer to accept.
  • the user may be given an option to begin or enter a conversation thread or a threadsite as the on-site information device 130 (FIG. 1) such as a beacon may push the offer generated based on the user's tagged preference into a threadsite.
  • the user may be given on option to consummate a transaction.
  • FIG. 8 provides one non-limiting advantage of allowing users to opt into receiving offers which they are most interested in. This can further provide an advantage to merchants because particular users can be targeted based on the tags. It will be appreciated that similar features may be included to opt out of offers. For example, a user may provide a tag for his user account "no fast food” or "block Pat's Pizza” to block offers related to "fast food” or from “Pat's Pizza.” This tag may be considered in isolation or in conjunction with other tags. For example, the user may have the "pizza deals" tag in addition to the opt out tags discussed above. This provides an easy and intuitive way for users to indicate solicitation preferences and control the flow of information to the client device. The opt out may, in some implementations, cause the suppression of the transmission at block 808 to the user/client device.
  • the content or offer may be stored such as in a coupon wallet.
  • the offers may be passively collected as the client device travels through the world of beacons and other offer providing devices.
  • the collected offers and content may be stored, for example, in a wallet viewable via the client device.
  • Each offer or content element may link to a threadsite, conversation, or allow completion of a transaction.
  • FIG. 9 is a flowchart for an exemplary method of pausing and unpausing a conversation thread in accordance with one embodiment.
  • the method shown in FIG. 9 may be implemented in the conversation module 240 in communication with the database 220 in FIGS. 2A-2B.
  • a conversation thread is created and a conversation between two or more users may begin.
  • a conversation thread participant may send a conversation thread item, the process may continue to block 903.
  • a conversation thread item may be received.
  • one or more conversation participant may be disallowed from sending a conversation thread item for a paused conversation, and the conversation thread item may not be received if the conversation is paused.
  • the conversation thread item may be received for later transmission regardless of whether the conversation is paused as depicted in the method of FIG. 9. As a conversation thread participant may send a pause request in the first embodiment, the process may continue to decision block 904.
  • the pause request may include an identifier for the conversation thread to be paused. If a pause request is not received, the process may continue to block 910. If a pause request is received, the process may continue to block 906.
  • the received conversation thread may be paused.
  • a conversation thread may be publically paused upon the conversation thread creator's request.
  • a conversation thread may be only privately paused upon any non-creator conversation participant's request.
  • the conversation may be publicly paused by any conversation participant's request.
  • the conversation thread may be configured by the thread creator to allow or disallow pausing by one or more of the conversation participants. After the conversation thread is paused, the process may continue to decision block 908.
  • the unpause request includes an identifier for the conversation thread. If an unpause request is received, the process may continue to block 910. If an unpause request is not received, the process may continue to decision block 912.
  • a conversation thread item may be received.
  • a conversation thread item may be received.
  • the conversation thread item of interest may be received.
  • a conversation publicly paused may be publicly resumed.
  • a conversation privately pause may be privately resumed as long as the conversation is not publicly paused.
  • FIG. 10 is a flowchart for an exemplary method of snoozing or muting a conversation thread in accordance with one embodiment. The method shown in FIG. 10 may be implemented in the conversation module 240 in communication with the database 220 in FIGS. 2A-2B.
  • a conversation between two or more users may occur through a conversation thread.
  • the conversation thread may have been snoozed or unsnoozed by one or more of the participants of the conversation.
  • a conversation thread participant may send a snooze or unsnooze request, the process may continue to block 1004.
  • a snooze or unsnooze request may be received.
  • a conversation thread participant may send a conversation thread item, the process may continue to block 1006.
  • a conversation thread item may be received. After the conversation thread item is received, the process may continue to block 1008.
  • participants of the conversation thread may be determined.
  • the participants of the conversation may be determined based on which users are linked to the conversation thread in database 220.
  • the process may continue to sub-process 1010 for each of the participant determined. For each participant, sub-process 1010 may continue to decision block 1012.
  • the conversation thread item is transmitted to the participant.
  • the sub- process 1010 may repeat for another participant determined at block 1008 until the sub- process 1010 is run for all the determined participants.
  • the process may continue to decision block 1016.
  • decision block 1016 a determination is made as to whether the conversation has ended. If the conversation has not ended, the process may continue to block 1004 to receive a subsequent snooze or unsnooze request if any. If the conversation has ended, the method shown in FIG. 10 ends.
  • FIG. 11 is a flowchart for an exemplary method of deleting a conversation thread in accordance with one embodiment.
  • the method shown in FIG. 11 may be implemented in the conversation module 240 in communication with the database 220 in FIGS. 2A-2B.
  • the conversation thread is deleted from database upon the conversation delete request from the author of the conversation thread.
  • the database may be substantially similar to the database 220 in FIGS. 2A-2B.
  • 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.
  • a delete request from the author of the conversation thread may delete the conversation thread from the database 220 by default.
  • the client may initiate deletion of a conversation thread, but the server may maintain the conversation history for a period of time (e.g., 30 days) while flagging the conversation thread to be deleted. Once the conversation thread is deleted from the database 220 or flagged as deleted in the database 220, the process may continue to block 11 10.
  • the conversation thread may be 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. Once the non-author requester's account is unlinked from the conversation thread, the method of FIG. 11 ends. [0211] At block 1110, the conversation thread may be 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 another embodiment, the non-author participants may not be given a notification regarding the deleted conversation. Upon deletion of the conversation thread from all participants' devices, the method of FIG. 11 ends.
  • FIG. 12A is a functional block diagram of an exemplary communications network system in accordance with another embodiment.
  • the first user, Client A may generate public user specified tags in the "marketplace," or private user specified tags in the "directory" specific to Client A.
  • the second user, Client B may also generate tags including tags about other users such as Client A in this example.
  • This tagging information may be communicated through a network and to a database of a communications cloud.
  • the database also may have automatic, system-generated tags based on demographic information from social media, geolocation, and social graphs that the communications cloud may gather from the network.
  • the system shown in FIG. 12A illustrates examples of the various sources for tags as well as the use of tags to facilitate providing a bidirectionally directed searchable marketplace and directory.
  • FIG. 12B is a functional block diagram of searching with an exemplary communications network system in accordance with another embodiment.
  • the communications cloud may also comprise a search index module, database, social graph module, and qualitative statistics module that may operate in conjunction with a search module that implements a real-time contextual search and discovery algorithm using text, tags, categories, geography, products, events, and proper names, among others to perform searches.
  • the communications cloud may communicate with users such as Client B in FIG. 12B through the network.
  • Client B in this example may request a search based on one or more phrases or other search attributes.
  • the communications cloud may perform the requested search through the search module and transmit real time results to Client B through the network.
  • the tag information underlying the searches may be continually updated, such as discussed with reference to FIG. 12 A.
  • FIG. 12B illustrates how the information received from user about themselves (self tags) and about others (user to user tags) facilitate bidirectionally directed searches as the basis for the searches submitted by Client B consider both the self tags and user-to-user tags.
  • FIG. 13 is a functional block diagram of an example system integration with an experience engine.
  • the system 1300 shown is a simplified diagram intended to highlight how an experience engine 1399 may be integrated within the communication system described.
  • the content/offer module 270 may include two retrieval components a local retrieval 1310a and an experiential retrieval 1320a.
  • the tagging module 210 may also include two retrieval components, a local retrieval 1310b and an experiential retrieval 1320b. In some implementations, the tagging module 210 and the content/offer module 270 may share a local retrieval and experiential retrieval elements.
  • the tagging module 210 shown in FIG. 13 also includes the tagging interface module 215. As discussed above, the tagging module 210 may include the tagging interface module 215. In some implementations, the tagging interface module 215 may be implemented as a separate element from the tagging module 210. In such implementations, the tagging interface module 215 may also include its own local and experiential retrievals or be configured to use commonly
  • the tagging module 210 and the content/offer module 270 may be configured to receive requests for tags, tag sets, content, or offers.
  • the local retrieval (1310a or 1310b) are configured to contact the database 220 included within the system 1300. This is "local" in the sense that the database 220 is managed by the same entity as the system 1300. As such, the communication links between the database 220 and the local retrieval (1310a or 1310b) may be close and thus fast.
  • the queries and responses for local retrieval (1310a or 1310b) are based on the information contained within the system 1310 as provided by the users (e.g., tags, threadsites, content, offers, etc.).
  • the enterprise may have a robust marketing or experience platform. Making this information available to the system 1300 can provide an efficient method of leveraging the external data to enhance the user experience via the system 1300.
  • the experiential retrieval (1320a or 1320b) communicates with the experience engine 1399 to obtain input information that can be used to generate responses to the content offer or tagging requests.
  • the experience engine 1399 may receive one or more experiential inputs such as weather, demographics, date / time, location, path (e.g., walking or driving direction), social media service (e.g., profile), inventory management system, customer relationship management (CRM) system, and the like.
  • one or more experiential inputs such as weather, demographics, date / time, location, path (e.g., walking or driving direction), social media service (e.g., profile), inventory management system, customer relationship management (CRM) system, and the like.
  • the enhancement may be achieved by enhancing the initial request.
  • the local retrieval (1310a or 1310b) will provide at least a portion of the request received from a client device (not shown) to the experiential retrieval (1320a or 1320b). This portion is then provided to the experience engine 1399 to identify additional terms, concepts, services, items, or information which may be related to the provided portion.
  • the experiential retrieval (1320a or 1320b) then adds the data identified by the experience engine 1399 to the request for execution by the local retrieval (1310a or 1310b).
  • the local retrieval 1310a would submit this search query for processing by the database 220 and provide results as described above.
  • the experiential retrieval 1320a may provide the search terms to the experience engine 1399.
  • the experiential retrieval 1320a may also provide information about the client device submitting the search such as information included in the request (e.g., metadata, header information) or information included in a session for the client device (e.g., user account identifier, device identifier).
  • information included in the request e.g., metadata, header information
  • information included in a session for the client device e.g., user account identifier, device identifier
  • One example may be location information.
  • synonyms and related words to the search term may be identified by the experience engine 1399.
  • the experience engine 1399 may then consider the search terms and other information provided by the experiential retrieval 1320a.
  • the location information may indicate the client device is traveling along a highway.
  • a purpose for the query can be inferred by the experience engine. This purpose can be used to provide additional search terms to include with the search to help guide the user to relevant results.
  • the additional terms are then added to the submitted query and the query is processed by the database 220.
  • the results will include information for "pharmacy" and the additional terms provided by the experience engine 1399.
  • the local retrieval (1310a or 1310b) nay be configured to search the database 220 with the search request as provided by the client device. These initial results may be provided to the client device as the enhancement continues. The enhancement can then be performed on the request or the initial results. In such implementations, the request may be provided to the experiential retrieval (1310a or 1310b) for enhancement as described above.
  • a second search can be executed using the enhanced request. Results overlapping with the initial result set may be removed such that only the newly identified items are provided to the client device.
  • the initial results may also be enhanced.
  • the top result item may be provided to the experience engine 1399 for identification of enhanced terms.
  • the experiential retrieval (1320a or 1320b) may then provide a search to the local retrieval (1310a or 1310b) for execution. These results provide a "drill-down" into one or more result items already identified locally. This can help guide subsequent searches by using the experiential enhancements on items already discovered.
  • FIG. 14 is an exemplary message diagram for providing experience engine enhanced tagging and offers.
  • the message flow of FIG. 14 shows messages exchanged between several entities which can be included in a communication system.
  • the database 220 may be implemented in the communication server 102 and/or the client device 1 10 (FIGS. 1-2B).
  • the tagging module 210 and the content/offer module 270 may be implemented as shown in FIG. 13 to integrate with the experience engine 1399.
  • a tag request message 1402 may be transmitted from the client device 110 to the tagging module 210.
  • the tag request message 1402 may include one or more words for a tag.
  • the tag request message 1402 may also include information about the client device 110 or a user thereof. Additional metadata indicating contextual information such as the time, date, or location of the client device may also be included in the tag request message 1402.
  • the tagging module 210 may be configured to enhance the tag request by transmitting an experience enhancement request 1404 to the experience engine 1399.
  • the request 1404 may include all or a portion of the information from the tag request message 1402.
  • the experience engine 1399 may then identify additional terms related to the provided tag request data.
  • the experience engine 1399 may include prediction models to predict behavior, taste, products, or other topics of interest for a user.
  • the experience engine 1399 may provide a profile for a given request. The profile may indicate general characteristics of a user having the provided enhancement request attributes. For example, if the request identifies a search term "football" and the location is Milwaukee Wisconsin, there is a good chance the user is a Green Bay Packers professional football fan.
  • the information identified by the experience engine 1399 is provided in an experience enhancement response 1406 to the tagging module 210.
  • the tagging module 210 may then perform messaging 1408 to apply tags.
  • the tagging may include suggesting tags based on information identified by the experience engine. For example, a new user may want to tag herself "football fan” not knowing that she may also tag herself “Green Bay Packer fan” or "Wisconsin Badger fan.”
  • the tagging module 210 may be configured to request content/offers based on the updated tags for a user. In some implementations, the request may be based on the experience enhancement response 1406. In the implementation shown in FIG 14, the tagging module 210 transmits a content/offer request message 1410 to the content/offer module 270.
  • the request may include one or more of the new tags, all tags for a user account, the enhanced information provided by the experience engine 1399 or other information upon which the content or offer may be selected.
  • the content/offer request message 1410 may include information about the client device 110 or a user thereof. Additional metadata indicating contextual information such as the time, date, or location of the client device may also be included in the content/offer request message 1410.
  • the content/offer module 270 is configured to retrieve content and/or offers via message 1412 from the database 220. This may include a local retrieval.
  • the content/offer request message 1410 may be enhanced using an experiential retrieval to access the experience engine 1399. Accordingly, the message 1412 may be a local or experience enhanced message 1412.
  • Message 1414 provides the identified content or offers to the content/offer module 270.
  • the identified content or offers may be used to obtain further enhancement information.
  • one or more of the identified content or offers may be provided in a subsequent experience enhancement request submitted from the content/offer module 270 to the experience engine 1399.
  • the identified content or offers are provided via message 1416 to the client device 110. Not shown in FIG. 14 is the filtering. It will be understood that the filtering module 254 may be configured to filter offers or content as shown and described above, such as in FIG. 5B.
  • FIG. 15 is a functional block diagram of a further example system integration with an experience engine.
  • an integrated communication server 1500 may include additional components described above for the communication server 102.
  • the simplified integrated communication server 1500 is intended to focus the reader on how the experience engine 1399 may be integrated within a communication server.
  • the experience engine 1399 is shown in data communication with the content/offer module 270, the tagging module 210, and the tagging interface module 215. This allows the content/offer module 270, the tagging module 210, and the tagging interface module 215 to experientially enhance the functions implemented therein.
  • the experience enhancement may be provided dynamically.
  • the enhancement may be a feature associated with particular user accounts.
  • the enhancement may be performed based on the integrated communication server 1500 characteristics such as number of concurrent sessions, average load, memory usage, or other metric which can impact communications and processing for client requests.
  • the metric may be global (e.g., for the integrated communication server 1500) or per element (e.g., content/offer module 270, tagging interface module 215, or tagging module 210 specific). This allows the enhancements to be disabled when resource demands are high and enabled when the additional resources needed to perform enhancements are available.
  • the system may be queried for several related items. For example, consider a user planning a birthday party. In current systems, a search for "birthday cakes” would likely return a series of bakers, grocers, and other purveyors of fine baked confections. Once discovered, this user may then execute a second query to look for "party table rental" to inquire about renting tables and other furniture for the party. This loop of query and find may be repeated for each item needed for the party. In some instances, the user may overlook an item commonly featured at such an event such as, for example, ice, or entertainment.
  • the results include items tagged with "birthday cakes” but also tagged with alternate phrases akin to birthday cakes such as baker, bakery, or pastry chef.
  • the search may expand the criteria to include related items such as ice, party rentals, and entertainment which are commonly associated with the event identified by the initial query. This can reduce the amount of traffic and processing for the system and the client device by providing a targeted result set that anticipates the needs of the requester.
  • the search results may avoid inadvertently forgetting an important item by including items tagged with a tag that is related to the initially searched tag.
  • the tagging of the system allows a bi-directionally optimized search.
  • the bi-directional optimization allows a user or merchant to define publicly viewable and searchable tags for himself or his business.
  • the user or merchant may also privately tag others to help organize their view of other users and merchants.
  • the taxonomies of tags may be predefined.
  • the system may store in a memory a taxonomy of tags.
  • One method of storing a taxonomy is a hierarchical tree. In such a tree, the root identifies a top- level concept and each descendant node provides a narrowing of the top level concept.
  • FIG. 16 illustrates an example taxonomy tree that may be included in the system.
  • a root node 1602 is shown as "party.”
  • the root node 1602 includes several child nodes 1604a-1604x as well as several leaf nodes 1606a-1606x.
  • a child node as used herein generally refers to a descendent node of another node which itself has descendants.
  • a leaf node as used herein generally refers to an element of the tree which has no further descendants.
  • tags can be personalized, the personalization can be extended to facilitate personalization of taxonomies.
  • a user may privately tag items with both "kegged rootbeer” and with "party.”
  • the affinity for kegged rootbeer may not be a common party item, however for this particular user kegged rootbeer may be essential.
  • the taxonomy may be personalized to identify searches for "kegged rootbeer” as in the category of things related to parties. As such, a search by this user for "kegged rootbeer" might return results for other items within the party taxonomy.
  • the personalized taxonomy may be based only on the user's tagging.
  • the personalized taxonomy may be an extension of a predefined tag taxonomy.
  • the public tags may also allow predefined taxonomies to change over time.
  • a taxonomy for the event of purchasing a new home may include tags for gardener, locksmith, moving company, and painter.
  • the system may identify additional tags for inclusion in this taxonomy.
  • the additional tags may be identified based on an analysis of tags commonly associated with items. For example, if a statistically significant number of items tagged "tax" are also tagged "estate planning" it may be desirable to include "tax" in a taxonomy that includes estate planning and vice-a-versa. Such a connection may not be present in an initially seeded taxonomy, but may emerge over time as the system and users evolve. This can be particularly useful for languages with dynamic words.
  • the additional tags may be identified based on an analysis of system usage. For example, within a given search session, users who search within the "purchase new home" taxonomy may also perform a secondary search for "pet sitters.” Over time, the system may determine based on the quantity of searches for pet sitters in proximity to new home purchase searches that pet sitters should be included in the new home purchase taxonomy.
  • the inverse operation may be performed whereby for a given search, an item included in the taxonomy is rarely activated on the search result. For example, "iguana cages" may be included in an initial taxonomy, but, over time, rarely clicked on in a search result.
  • the system may thus be configured to dynamically adjust the taxonomy to remove these rarely used tags.
  • Taxonomies may be localized. For example, a party taxonomy in San Diego may include different tags than a party taxonomy in Cincinnati.
  • the taxonomy which is closest geographically to the location of the client device may be identified based on location information provided by the client device with the search request.
  • Such taxonomy searches may be useful to facilitate messaging (e.g., chats or threadsites) related to the event.
  • a user may instantly initiate a communication thread with one or more selected results. For example, consider a search for "used car dealer.” This search suggests the user is looking to either buy or sell a used car. As part of this event, a mechanic may be consulted, insurance needs may change, vehicle reports or inspections may be required, or tires may be purchased. Tags for these activities along with those for "used car dealer" may be searched and provided in a result set to the client device. The client device may then receive a message identifying several dealers, mechanics, insurance agents, and tire companies.
  • the message may also include the text "Can you please provide a quote for a 2001 Pontiac Aztek?"
  • the question may then be forwarded to each of the parties identified from the search result. This allows the user to initiate communication with several different parties with a single message. This facilitates efficient communications through the system by reducing the amount of resources needed to request the information of interest.
  • the system also allows each party to communicate in a secure fashion and reveal only desired contact information to the other part.
  • the systems and methods described allow parties to exchange personal ID codes.
  • the personal ID code may be entered into the system by each party and used to connect, communicate, and even transact with each other. In today's connected and transient world, temporary relationships are commonplace. A limited time relationship may be formed between people based on projects they are working on, sales people they are dealing with, or events attended (e.g., conferences).
  • a user may disassociate with a person whom they no longer wish to interact with.
  • the personal ID code may be associated with communication channel preferences. Such preferences indicate, for approved parties, how the party associated with the personal ID code wishes to be contacted.
  • the party may be given options to hide personal information including biographical information, cell phone number, e- mail address, and home or work address thereby limiting the mechanisms available to communicate.
  • Taxonomy or a node within a taxonomy
  • Other events which may serve as the focal point for a taxonomy include: party, birthday, anniversary, engagement, wedding, shower, class reunion, tax, death, graduation, major purchase (e.g., home, car, pet), moving, automobile accident, vacation, college admission, ordination, new baby, adoption, arrest, homecoming,ob promotion, retirement, leveraged buy-out, or the like.
  • FIG. 17 shows a process flow diagram for an example method of generating a taxonomy.
  • a seed taxonomy is received.
  • the seed taxonomy may include a root node.
  • the seed taxonomy may also include a child node and in some cases a leaf node.
  • the seed information may be used to establish an initial default taxonomy which may be adapted over time as will be described.
  • the seed taxonomy may be provided through a network connection.
  • the seed taxonomy may be stored in a memory.
  • a user interface may be provided for receiving taxonomy information.
  • system usage data is obtained.
  • the system usage data may include one or more of public tag information, private tag information, and search session information.
  • the system usage data may be aggregated such as for all users, all users in a location, all users of a particular demographic, or all users with a particular client device. In some implementations the system usage data may be for individual users. Such usage data may be included to personalize taxonomies for specific users.
  • the system usage data may be obtained in real time, that is, as part of a transaction within the system. For example, if a public tag is added, this update will be obtained by the process 1700. In some implementations, it may be desirable to defer the processing associated with taxonomy generation until a period of low system usage (e.g., late night, slow days). In such implementations, obtaining the system usage data may include obtaining a log of system usage for a period of time.
  • the mechanism to obtain the usage data may be a query of a usage log.
  • a messaging queue may be included to receive the incremental updates as they occur.
  • taxonomy data is generated for an individual.
  • the taxonomy data may include adding or removing nodes from a personalized taxonomy.
  • the taxonomy data may include adding or removing leafs from a node.
  • the generation is based on the obtained system usage data for the individual. For example, if a search session for an identified user for "party" is followed by a search for "rootbeer” it may suggest that the terms are related. As such, the personalized taxonomy for this user may associate rootbeer and party.
  • the relationship may be based on statistical processing which determined the probability the terms are linked and not just randomly associated.
  • One example method may include Bayes's theorem.
  • the individual tagging activity may also (or alternatively) be included in the generation process. For example, a user may commonly tag friends with "rootbeer” and who are also tagged with the term "party.” By examining the tags added to contacts and merchants for the identified user, relationships between terms can be discovered and utilized to generate the personalized taxonomy. The association may again be statistically driven through a probability model which identifies a likelihood the relationship between terms for contacts is truly a relationship rather than random happenstance.
  • the generated personalized taxonomy may be stored by the system. In some implementations, it may be stored on a server providing system services to a client device. In some implementations, the taxonomy may be transmitted to the client device or client devices associated with the user who was identified as the basis for the personalized taxonomy.
  • the individual taxonomy generated at block 1706 discussed thus far refers to individual users
  • the individual may be an individual collection of users such as users from a common area, users having common tags, or another aggregation of users.
  • block 1706 may be omitted.
  • the seed taxonomy received at block 1702 is refined.
  • the refinement may include applying similar system usage analytics described in reference to block 1706, but on a system- wide basis.
  • the process 1700 may then return to block 1704 to obtain further system usage data.
  • FIG. 18 shows a process flow diagram for an example method of searching with a taxonomy.
  • the method 300 may be implemented in whole or in part by a taxonomy engine such as that shown and described in FIG. 19 below.
  • a query is received from a client device.
  • the query may be received via wired channels, wireless channels, or a combination thereof.
  • the query is specified in a standardized machine readable format.
  • search terms are extracted from the query.
  • the extraction of search terms identifies the input values entered for searching. These search terms will be expanded upon to provide the taxonomy based result.
  • the extraction may be based on a predetermined query format.
  • the query language syntax may be specified via a configuration.
  • the syntax information may be used to process the received query.
  • taxonomy selection criteria are extracted from the query.
  • the taxonomy selection criteria may be empty or omitted. In this situation, the system default taxonomies will be used.
  • the user or user's device may be identified such as via a login, username, device identifier, or the like. In such implementations, the identity of the user can be included as taxonomy selection criteria to provide a personalized taxonomy for the user
  • the criteria may include location information. As discussed, different locations may have different taxonomies. Therefore, using location information included in the query or message providing the query, the location may be identified.
  • the client device may include location services and provide geospatial coordinates with the query.
  • a network address or access point identifier may be included. These location identifiers may be used to estimate the location of the querying device. In some implementations, the location information may be included in the query, such as "Alabama wedding planner" which identifies Alabama as a location.
  • a taxonomy is selected.
  • the taxonomy is selected by querying a data storage with the identified criteria.
  • a request may be transmitted to a taxonomy service for the taxonomy data.
  • the request includes the identified criteria and, in response, the taxonomy data is provided. It will be appreciated that in some implementations, more than one taxonomy may be selected and used. In some implementations, there may not be available taxonomies. In such implementations, the process 1800 terminates.
  • expansion terms are identified from the selected taxonomy.
  • the identification may be based on an extracted query term wherein the leaf-nodes of a parent node associated with an extracted query term are included as expansion terms.
  • the search term was "cake" the additional leaf-nodes 1606b-1606x would be identified as expansion terms.
  • the number of terms added from the taxonomy may be limited such as by a configured value (e.g., no more than 4, 8, or 20 additional terms from a taxonomy) or dynamically determined (e.g., based on search system resource availability, client device resource availability, network resource availability, service level agreement, provisioned quality of service).
  • an augmented query is generated.
  • the augmented query includes the additional taxonomy terms identified at block 1810 in a query.
  • the augmented query may be built on the received query or may be a new query including both the original query information and the identified terms.
  • the augmented query is provided to a query processor for execution. Executing the query includes searching based on the specified criteria and providing a response associated with the specified criteria.
  • Executing the query includes searching based on the specified criteria and providing a response associated with the specified criteria.
  • the process 1800 described in FIG. 18 allows a single augmented query to be executed.
  • the original query may be processed and, as a second query, the augmented query may be processed. This can be useful in implementations where intermediate results are desired.
  • the results from the original query may be presented to the client device while the augmented query is executed.
  • the results may be merged with the original query results.
  • FIG. 19 shows a functional block diagram of a taxonomy engine. It may be desirable to provide a stand-alone taxonomy engine 1900 which can be introduced into existing search systems. Such a stand-alone taxonomy search engine may be configured to plug into an existing query processor 1990 to provide taxonomically enhanced searches. In some implementations, the stand along taxonomy search engine may be installed on a communication channel between query sources (e.g., client devices) and the query processor. In either implementation, the taxonomy search engine is configured to receive the incoming search query parameters and identify additional query parameters to include based on the appropriate taxonomy.
  • query sources e.g., client devices
  • the taxonomy engine 1900 includes an input channel 1902.
  • the input channel 1902 is coupled so as to receive the query submitted by a client device.
  • the coupling may be a wired, wireless, or hybrid coupling configured to receive a machine readable communication from the client device including the query.
  • the input channel 1902 is configured to provide the received query to a query parser 1904.
  • the query parser 1904 is configured to extract information from the query to obtain key terms included in the query which can be used to identify a taxonomy and terms therefrom.
  • the query parser 1904 may receive a configuration input 1906.
  • the input 1906 may be received from a memory location of the taxonomy engine 1900 (not shown) or from an external source such as a network service.
  • the query parser 1904 may be configured to submit a request message to obtain the configuration. Once obtained, the information may be cached locally to avoid subsequent look-ups of the configuration information. The caching may be for a predetermined period of time, number of queries, or a combination thereof.
  • the configuration input 1906 may identify the query language for the system into which the taxonomy engine 1900 is included.
  • the identification of the query language may also include parsing rules which control how the query parser 1904 can dissect a received query.
  • the query parser 1904 is configured to provide extracted terms to a taxonomy selector 1908.
  • the taxonomy selector 1908 is configured to identify the taxonomy to use for the extracted terms.
  • the taxonomy selector 1908 may also receive the query which may include identification information for the client device transmitting the query. Such identification information may be used to further refine the taxonomy selection such as by identified user, identified user device, location, or other non- search metadata (e.g., headers, cookies, tokens) included in message received that includes the query.
  • non- search metadata e.g., headers, cookies, tokens
  • the taxonomy selector 1908 may be configured to select a locally stored taxonomy from local taxonomy storage 1910.
  • the taxonomy selector 1908 may transmit a message via a network interface 1912 to obtain taxonomy data.
  • the message may be transmitted to a networked taxonomy service 1980 configured to provide taxonomy information as described herein as a response via the network interface 1912.
  • the networked taxonomy service 1980 may be a tag repository including public and private tags and taxonomies as described.
  • the taxonomy selector 1908 may be configured to provide the taxonomy terms to a query generator 1914.
  • the query generator 1914 is configured to generate a new version of the received query which includes the identified terms from the taxonomy.
  • the query generator 1914 may receive as inputs the received query, the configuration input 1906, or both.
  • the received query and the configuration input 1906 may provide additional information to be included in the new version of the received query as well as how to construct the new version.
  • the syntax for query processors can vary.
  • the query generator 1914 may receive the configuration input 1906 which includes information regarding how to form a query that will be understood by the query processor 1990.
  • the query generator 1914 may then transmit the new version of the received query, including any header or metadata information, to the query processor 1990. It will be appreciated that the query processor 1990 may not distinguish between queries from the stand alone taxonomy engine 1900 and queries received directly from a client device. This provides the non-limiting advantage of expanding the capabilities of an existing query processor without disrupting or requiring additional changes to the query processor proper.
  • the taxonomy engine 1900 may be included on a client device.
  • the engine 1900 may plug into a client application generating queries or couple between the client application generating the queries and a transmitter configured to provide the queries to a query processor.
  • the taxonomy engine 1900 may be provided to some client devices without altering the client or server query process flow.
  • queries submitted via the client application are augmented as described above with taxonomy data.
  • the taxonomy features should be understood to provide augmented search results not alternative search results. For example, some systems provide suggestions of items that users purchased instead of a given result item. While the current system may include multiple results for a given tag, the taxonomy aspects provide ancillary items tagged with terms related to the activity associated with the requested tag search terms. These ancillary items may also be selected based on proximity to the location of the device thereby providing not only relevant but local results.
  • One non-limiting advantage of the described aspects is real-time contextual public directory management.
  • the user may further curate the user's listing in the dynamic directory to reflect the user's current status and interests and limit persistence of past, irrelevant information.
  • Another non-limiting advantage of the described aspects is personalized private contact directory management.
  • the user may add or remove descriptions of the user's contacts and the user's communication threads to organize and facilitate search of the user's own directory available exclusively to the user.
  • Another non-limiting advantage of the described aspect is communications and privacy management.
  • the user may prescribe rules to a communications or conversation thread to restrict reply, viewing of recipients, or adding new participants.
  • the user may further pause, snooze, mute or globally (system-wide) delete an existing (or user-created) communication or conversation thread so that the user may reduce disturbances from constant communications and control user-created communications threads.
  • FIGS. 20 - 36 show various interface diagrams implementing one or more of the features described.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array signal
  • PLD programmable logic device
  • 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.
  • 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.
  • 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.
  • any connection is properly termed a computer- readable medium.
  • 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
  • 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 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.
  • computer readable medium may comprise non- transitory computer readable medium (e.g., tangible media).
  • 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.
  • 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.
  • the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.
  • Software or instructions may also be transmitted over a transmission medium.
  • 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.
  • DSL digital subscriber line
  • 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.
  • a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein.
  • 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.
  • storage means e.g., RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.
  • 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.
  • 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.
  • display or "displaying” encompass a variety of actions.
  • "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.
  • 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.
  • the terms "provide” or “providing” encompass a wide variety of actions.
  • “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

Abstract

Cette invention concerne un support non transitoire lisible par ordinateur, comprenant des instructions stockées sur celui-ci qui, lorsqu'elles sont exécutées par un processeur, réalisent un procédé. Ledit procédé consiste à stocker un répertoire de comptes utilisateurs, le répertoire identifiant une première association d'un descripteur public à un compte d'utilisateur, le répertoire identifiant en outre une seconde association d'un descripteur privé à un contact du compte utilisateur. Le procédé consiste en outre à recevoir un message de requête d'un descripteur public comprenant une valeur indiquant un descripteur public à stocker dans le répertoire associé au compte utilisateur. Le procédé consiste en outre à identifier une taxonomie de descripteur à l'aide de la valeur comprise dans la requête de descripteur public. Le procédé consiste en outre à générer un ensemble de descripteurs publics suggérés à l'aide de la taxonomie de descripteur et du message de requête de descripteur public. Le procédé consiste enfin à transmettre l'ensemble de descripteurs publics suggérées au dispositif de communication.
PCT/US2015/056926 2014-10-24 2015-10-22 Système et procédé de fourniture de descripteur WO2016065153A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201462068178P 2014-10-24 2014-10-24
US62/068,178 2014-10-24

Publications (2)

Publication Number Publication Date
WO2016065153A2 true WO2016065153A2 (fr) 2016-04-28
WO2016065153A3 WO2016065153A3 (fr) 2016-06-16

Family

ID=55761748

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/056926 WO2016065153A2 (fr) 2014-10-24 2015-10-22 Système et procédé de fourniture de descripteur

Country Status (1)

Country Link
WO (1) WO2016065153A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106060762A (zh) * 2016-05-24 2016-10-26 中国联合网络通信集团有限公司 一种信息推送方法、信息推送装置、信息推送系统
WO2019222024A1 (fr) * 2018-05-18 2019-11-21 Dexyp Procédé et système d'attribution et d'optimisation de budgets par prospect sur une plateforme de gestion et de paiement de campagne multimédia multicanal
US20210319032A1 (en) * 2016-08-09 2021-10-14 Ripcord Inc. Systems and methods for contextual retrieval and contextual display of records

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8775327B2 (en) * 2008-07-03 2014-07-08 Oracle International Corporation Combined directory of personal and enterprise application system data
KR20110118073A (ko) * 2010-04-22 2011-10-28 김동주 개체지향적인 접근 형식의 정보제공서비스 시스템 및 방법
JP5065470B2 (ja) * 2010-12-07 2012-10-31 楽天株式会社 サーバ、情報管理方法、情報管理プログラム、及びそのプログラムを記録するコンピュータ読み取り可能な記録媒体
US8538806B2 (en) * 2011-10-20 2013-09-17 Rawllin International Inc. Systems and methods for establishing transactions utilizing a data store of billing information
JP6020196B2 (ja) * 2013-01-23 2016-11-02 富士ゼロックス株式会社 情報提供装置及びプログラム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106060762A (zh) * 2016-05-24 2016-10-26 中国联合网络通信集团有限公司 一种信息推送方法、信息推送装置、信息推送系统
CN106060762B (zh) * 2016-05-24 2020-03-13 中国联合网络通信集团有限公司 一种信息推送方法、信息推送装置、信息推送系统
US20210319032A1 (en) * 2016-08-09 2021-10-14 Ripcord Inc. Systems and methods for contextual retrieval and contextual display of records
WO2019222024A1 (fr) * 2018-05-18 2019-11-21 Dexyp Procédé et système d'attribution et d'optimisation de budgets par prospect sur une plateforme de gestion et de paiement de campagne multimédia multicanal
US10685376B2 (en) 2018-05-18 2020-06-16 Thryv, Inc. Method and system for lead budget allocation and optimization on a multi-channel multi-media campaign management and payment platform
US11257109B2 (en) 2018-05-18 2022-02-22 Thryv, Inc. Method and system for lead budget allocation and optimization on a multi-channel multi-media campaign management and payment platform
US11386449B2 (en) 2018-05-18 2022-07-12 Thryv, Inc. Method and system for lead budget allocation and optimization on a multi-channel multi-media campaign management and payment platform

Also Published As

Publication number Publication date
WO2016065153A3 (fr) 2016-06-16

Similar Documents

Publication Publication Date Title
US9367631B2 (en) Dynamic directory and content communication
US20160110467A1 (en) Tagged proximity training and timing
US20190340622A1 (en) Enhanced customer interaction
AU2012301789B2 (en) Recommending items to users based on social graph information
US20190197034A1 (en) Recommendation filtering based on common interests
US20070271234A1 (en) Information Exchange Among Members of a Group of Communication Device Users
US20140324624A1 (en) Wine recommendation system and method
US20150181383A1 (en) Location-based messages
US20130311315A1 (en) Systems and methods for managing group buy transactions
US20130132221A1 (en) Social shoppping on a networked publication system
US10091323B2 (en) Social discovery feed for facilitating social exploration in social networking environments
US20230283649A1 (en) Determining and managing social interaction options in social networking environments
US20130054365A1 (en) Enhancing User Shopping Experience Using Social Graph Information
US20130226628A1 (en) Event-centric matching and social networking services
US20170277799A1 (en) Person-to-person viewing of recommended items as grouped into categories
US20170083954A1 (en) Obtaining Referral Using Customer Database
WO2016065153A2 (fr) Système et procédé de fourniture de descripteur
US20160042413A1 (en) Systems and Methods for the Recording and Selective Distribution and Selective Communal Analysis of Consumer Reviews
US9213725B2 (en) Systems and methods for generating automated social interactions in social networking environments
WO2016011257A1 (fr) Système et procédé pour enchères et communication marchand dynamiques
US8713104B1 (en) Sharing networks determined by sharing of items between individuals
US9135650B2 (en) Person-to-person item recommendation with decline
US20130006817A1 (en) Enabling control or use of personal metadata
US10855689B2 (en) System configurations for data stream accessibility
WO2016025461A2 (fr) Système et procédé de communication mobile

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15851684

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15851684

Country of ref document: EP

Kind code of ref document: A2