WO2016011257A1

WO2016011257A1 - System and method for dynamic merchant bidding and communication

Info

Publication number: WO2016011257A1
Application number: PCT/US2015/040759
Authority: WO
Inventors: Alexander HERN; William Dean KOSAGE
Original assignee: Mobile Incorporated
Priority date: 2014-07-17
Filing date: 2015-07-16
Publication date: 2016-01-21

Abstract

Features are disclosed which integrate the search and communication functions to provide a sophisticated and secure platform for price negotiations and completion of negotiated transactions. A searching party can search all merchant and vendor users of the system who have identified themselves as being available to provide an item or service. The system may filter or sort the search results according to any number of variables, including, for example only, distance, rating, price range, etc., as selected by the user. After being presented with the search results, the user may select one or more merchants from the search results and immediately request the system initiate a bidding dialog with the one or more selected merchants to complete the transaction.

Description

SYSTEM AND METHOD FOR DYNAMIC

MERCHANT BIDDING AND COMMUNICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of U.S. Provisional Patent Application No. 62/025,903, filed July 17, 2014 and entitled "SYSTEM AND METHOD FOR DYNAMIC MERCHANT BIDDING AND COMMUNICATION" of which is hereby expressly incorporated by reference in its entirety. Furthermore, any and all priority claims identified in the Application Data Sheet, or any correction thereto, are hereby incorporated by reference under 37 C.F.R. § 1.57.

BACKGROUND

[0002] The present application relates generally to searching for and selectively communicating with merchants via a dynamic bidding and communication system.

[0003] A user of a dynamic bidding and communication system may desire to use the system to research and/or purchase an item or service. Such research of an item or service may include determining the costs of purchasing, renting, or bartering and/or availability of the item and/or service. The research of the item or service may further include determining what merchants are available via a search of users of the system and may include narrowing or filtering the search according to various parameters, including, but not limited to, merchant rating, distance of merchant from user, hours of operation of the merchant, availability of the item or service, etc.

[0004] Currently, a party looking to purchase an item or service may access the Internet and perform a search for the item or service to find available merchants (or vendors), and then individually contact or communicate with those merchants to determine availability and/or pricing of the item or service. Additionally, a majority of the discovered merchants may require additional time to provide the item or service to the searching party due to the potentially large distance between the merchant and the party searching for the item or service or the need to package and ship the item. Additionally, the online search and purchasing process may limit the ability to negotiate price terms. To do this, the party wanting to compare pricing and availability of products or services at multiple merchants within a specific geography or with delivery item or performance of the service within a specific time frame may be required to individually search for merchants iteratively. The party may first search for merchants within a specified geography. Then, the party may contact each merchant individually to determine the availability of the item or service from each particular merchant. Once the party knows what merchants are available to provide the item or service, the party may then compare prices, and if the party wishes to negotiate pricing, they must again contact each merchant to discuss said pricing.

[0005] This process is very time consuming and requires an efficient platform for performing the searching of and communications with the various merchants. Furthermore, price negotiations with merchants may be more difficult when the merchants are not aware that they are competing with one another or when that awareness does not occur in real time with available confirmation that another merchant is offering the party a better price. For example, the party may inform a merchant that the party has received a better offer from a different merchant, but the merchant may not know if the party is being honest or trying to pressure the merchant into reducing the current price without having a better offer.

[0006] Accordingly, a system and method for dynamic bidding and communication may greatly facilitate the search for and acquisition of an item or service by a party from merchants and vendors.

SUMMARY

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

[0008] One aspect of the subject matter described in the disclosure provides an apparatus for communicating, the apparatus comprising a database of merchant users and corresponding tags and keywords, a transceiver configured to transmit messages to one or more client devices of a wireless system and receive message from the one or more client devices of the wireless system, and a processing unit operably connected to the memory unit and the transceiver. The processing unit is configured to initiate a search of the database for a merchant user via a search module based on at least one of a user selected tag and a user input keyword received from a requesting client device, receive, via the transceiver, at least one search result comprising at least one merchant user of the wireless system, transmit, via the transceiver, the at least one search result to the requesting client device, receive, via the transceiver, a bidding dialog request from the requesting client device, the bidding dialog request comprising at least one user preference for a bidding dialog and at least one merchant user selected from the at least one search result, initiate the bidding dialog via a bidding module with the at least one merchant user, and complete a transaction via a transaction module for the item or service in exchange for a final bid price. The bidding module comprises a bidirectional dialog between the requesting client device and the at least one merchant user and a bidding event, the bidding event comprising each merchant user of the at least one merchant user providing a bid price on an item or service desired by the requesting client device.

[0009] Another aspect of the subject matter described in the disclosure provides an apparatus for communicating, a receiver configured to receive a search request from a client device, the search request comprising at least one keyword or tag to be searched, a database configured to store at least one user and at least one keyword or tag corresponding to each user, a search module operably coupled to the receiver and the database, a transmitter operably coupled to the search module, configured to transmit the search result to the client device, and a bidding dialog module operably coupled to the receiver and the transmitter. The search module is configured to search the database for the at least one keyword or tag of the search request and compile a search result, the search result comprising at least one user corresponding to the at least one keyword or tag of the search request. The bidding dialog module is configured to generate a bidding dialog in response to a bidding dialog request received by the receiver from the client device, the bidding dialog comprising a bidirectional communication platform between the client device and at least one user from the at least one user of the search result. [0010] An alternate aspect of the subject matter described in the disclosure provides a method for communicating, comprising receiving a search request from a client device, the search request comprising at least one keyword or tag, searching a database of users and associated tags or keywords for the at least one keyword or tag, compiling a search result, the search result comprising at least one user corresponding to the at least one keyword or tag of the search request, transmitting the search result to the client device, receiving a bidding dialog request from the client device, the bidding dialog request comprising at least one user of the search result, and generating a bidding dialog, the bidding dialog comprising a bidirectional communication platform between the user and the at least one user of the search result.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The above-mentioned aspects, as well as other features, aspects, and advantages of the present technology will now be described in connection with various embodiments, with reference to the accompanying drawings. The illustrated embodiments, however, are merely examples and are not intended to be limiting. Throughout the drawings, similar symbols typically identify similar components, unless context dictates otherwise. Note that the relative dimensions of the following figures may not be drawn to scale.

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

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

[0014] FIG. 2B is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 2A.

[0015] FIG. 3 is an exemplary message diagram for creating tags in accordance with one embodiment.

[0016] FIG. 4 A is an exemplary message diagram for creating a conversation thread in accordance with one embodiment.

[0017] FIG. 4B is an exemplary message diagram for creating a bidding dialog thread in accordance with one embodiment. [0018] FIG. 4C is an exemplary message diagram for transacting through a conversation thread in accordance with one embodiment.

[0019] FIG. 4D is an exemplary message diagram for transacting through a bidding dialog thread in accordance with one embodiment.

[0020] FIG. 5 is a flowchart for an exemplary method of searching tags and requesting a bidding dialog in accordance with one embodiment.

[0021] FIG. 6 is a flowchart for an exemplary method of searching the database in accordance with one embodiment.

[0022] FIG. 7 is a flowchart for an exemplary method of creating a bidding dialog thread in accordance with one embodiment.

[0023] FIG. 8 is a flowchart for an exemplary method of pausing and unpausing a bidding dialog thread in accordance with one embodiment.

[0024] FIG. 9 is a functional block diagram of an exemplary communications network system in accordance with another embodiment.

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

[0026] FIG. 11 is an exemplary user interface for creating a bidding dialog thread in accordance with one embodiment.

[0027] FIG. 12A is a flowchart for an exemplary, real-time method of obtaining ratings from users in accordance with one embodiment.

[0028] FIG. 12B is a process flow diagram for an exemplary method of communicating with a reviewer.

[0029] FIG. 13 is an exemplary message diagram for obtaining and verifying ratings through a rating module in accordance with one embodiment.

[0030] FIG. 14 is a process flow diagram illustrating an exemplary method of bidding via a conversation thread.

DETAILED DESCRIPTION

[0031] In some embodiments, the system may integrate the search and communication elements of the process, as well as provide a sophisticated and secure platform for price negotiations and completion of negotiated transactions. The system may provide the searching party with the ability to perform a search of all merchant and vendor users of the system who have identified themselves as being available to provide an item or service. The system may provide the results of the search to the searching party with all available merchant and vendor users that have been identified as having that item or service available. In some embodiments, the system may filter or sort the search results according to any number of variables, including, for example only, distance, rating, price range, etc., as selected by the user. After being presented with the search results, the user may select one or more merchants from the search results and immediately request the system initiate a bidding dialog with the one or more selected merchants. The bidding dialog (as will be discussed below) may be individual with each merchant or it may be a group dialog with each merchant being aware of the dialog with other merchants. Through this dialog, the searching party may discuss specifics of the item or service desired and begin a group auction or bidding event, where each merchant/vendor discloses the lowest price they are willing to accept for the item or service, and the searching party may accept a bid and complete the transaction to purchase the item or service via the system. Accordingly, the searching party may be able to proceed throughout the entire process of searching for, researching, negotiating the price for, and purchasing an item or service within a single, convenient, and secure system.

[0032] For example, a merchant user "Sam" may be a locksmith or may sell door locks and associated hardware and services and may associate himself within the system as being a locksmith and as selling door locks and associated hardware and offering the services associated with a locksmith. Similarly, "Larry," another locksmith, may also be listed in the system with similar identifiers or tags. Thus, a searching party, "Peter," looking to purchase a door lock and installation services, may use the system to search for merchants or vendors that are locksmiths or that sell door locks and associated services. From this search, the system may return Sam and Larry in a search result as merchants with a door lock and associated installation services available for sale. Accordingly, Peter may select at least Sam and Larry from the search results as merchants to start a bidding dialog with and may ask any questions of Sam and Larry regarding the door lock and/or the installation services via the bidding dialog. These questions may include, for example, when Sam or Larry will be available to perform the installation of the door lock and/or if the door lock is in stock. Additionally, Peter may negotiate the price of the door lock and installation services, including having Sam and Larry bid against each other to do the work for the lowest price, and may purchase the door lock and installation services from one of Sam and Larry via the system after the auction/bidding event is complete.

[0033] In an alternate example, Sam the locksmith may broadcast a conversation to a select group of previous clients or potential new clients in a given geographic region. For example, Sam may determine that he is available to do work for clients when he will be in a particular neighborhood or geographic area, for example between 2pm and 5pm of a given day. Accordingly, Sam may select, from a collection of previous clients or new clients, those clients that may be located in the particular neighborhood or geographic area that Sam will be in and send a broadcast conversation only to that subgroup of clients in the particular neighborhood or geographic area. The broadcast conversation may ask if any of these clients have any work that they would like him to perform and what price they would be willing to pay during the specific time period. In some instances, the broadcast conversation may be either private (i.e., like a Bcc conversation), so each client is not aware of the conversation being broadcast to other users and is thus unable to see any responses Sam may receive from the other users, or may be public so that all clients are aware of each other and see each response Sam receives. In some alternate embodiments, the broadcast conversation may be a combination of private and public conversation items. Sam may then select the highest paying job within his available time window from the responses he receives. Thus, Sam may use the bidding process and dialog in a reverse manner to find work and have clients bid on his time and services.

[0034] To facilitate efficient and secure bidding and/or auctions, the described systems and methods include self-discovery. Self-discovery is directed to being searchable by other users as the user desires or chooses. For example, a user may choose to identify or present herself to other users as a surfer, an iOS developer, looking for Laker tickets, or other custom set of strings. These strings, or tags, may be accessible by users of the system during a search process. Each user of the system is able to define and associate tags with their account and device for other users to see. A user's account may identify the personal information of the user and allow the user to personalize their experience with the described systems and methods by identifying their preferences, i.e., saving their identities, tags, contact information, etc. Another non-limiting advantage of the described systems and methods is self-tagging. Whereas self-discovery allows 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 in managing interactions (e.g., conversation, transactions, offers, content) with their contacts. Self-discovery and self-tagging afford flexibility and control in how each user sees the world and how the world sees the user.

[0035] As noted above, a user may also include a merchant. For example, a merchant may comprise a business or a user with an item or a service available for purchase, rent, or trade. As discussed above with regard to users, merchants may also establish accounts advertising or indicate services or industries with which they are associated or would like to be associated. For example, a merchant may identify himself as a "mechanic," "accepting new clients," or other custom set of strings which are accessible by users of the system. Each merchant of the system may be able to define and associate tags with their account and device for other users to access and search. A merchant's account may identify the information relating to the merchant and allow the merchant to personalize their experience with the described systems and methods by identifying their preferences, i.e., saving their identities, tags, contact information, etc.

[0036] Another non-limiting advantage of the described systems and methods for merchants is self-tagging. Whereas self-discovery allows the merchant to specify to the world how they would like to be found, self-tagging allows merchants to define and associate tags with contacts (e.g., phonebook entry, associated merchant or employee accounts, partnerships, brands) for the merchant to see and use to manage interactions (e.g., conversations, transactions, offers, content, bidding dialogs) with their contacts. Self- discovery and self-tagging afford flexibility and control in how each merchant sees the world and how the world sees the merchant. A person of skill in the art will understand that any user may be a merchant. [0037] In some embodiments, a merchant may not perform searches. In other embodiments, a merchant may perform searches to find new potential patrons or existing patrons and may initiate communications or auctions/bidding events with them.

[0038] Another aspect that relates to self-discovery is the bidirectionally optimized search. Through the use of tags (as one example), users (including merchants) can influence their searches which are submitted to the system. For example, the user may associate a tag with a contact identified as a potential business lead. When the user searches for contacts nearby while on a business trip, including the business lead tags in the search further refines, identifies, and presents the information according to how the user understands and organizes 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.

[0039] Users also influence searches by tagging themselves. These tags indicate the ways in which 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. In some embodiments, tags associated with a merchant (e.g., of services performed, etc.), may be populated automatically based on the name of the merchant (i.e., a merchant called "Sam's Automotive Repair" may result in automatic tags of "Automotive Repair," "Body Work," "Oil Change," etc. to be suggested). The merchant creating the account for the business may determine which of these tags, if any, should be associated with the merchant.

[0040] One non-limiting advantage of tags being automatically generated is the simplification and ease of establishing the account and a set of tags that may be relevant to the services of the merchant, thus allowing a merchant to quickly establish an account. Additionally, as described above with regard to the users, custom tags may be added and associated with the merchant's account based upon those services and features with which the merchant would like to be associated. In some embodiments, the business name may not be indicative of any details of the merchant, or the system may utilize other identifying information sourced from existing online accounts for social networks services (e.g., Facebook™, Twitter™, Google+™, etc.), or directory listings (e.g., YellowPages, Yelp™, Angle's List™, etc.) to develop and generate tags that may be associated with the merchant. In some other embodiments, the system may source identifying information for the merchant from employees whose accounts may be associated with the merchant account (i.e., if Bob is associated as an employee of the business, and Bob has tagged himself as a mechanic, then the system may suggest "Mechanic" or "Automotive Repair" as potential tags).

[0041] 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 indicates 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 client device may also be used to exchange bid requests, bidding dialog content, and bids in an auction or bidding event.

[0042] 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 may indicate how the user wants the world to find and view the user. As such, searches submitted by any user may consider the global tag. This may facilitate locating the user by anyone in the system.

[0043] Consider the use case of selling an item or service. A merchant may tag himself with the following tags: name (e.g., "Bob's Automotive"), automotive repair (associated industry), oil changes (service offered), repair quotes (service offered), same day service, and appointments/discounts available. When people search for any of these tags, Bob's Automotive will be identified instantly (e.g., real time relevance). The tagging described has a non-limiting advantage of bidirectional search optimization whereby a merchant need not wait for a search engine to crawl and optimize searches. A merchant may add or remove tags which are instantly used to adapt searches and that the merchant believes are most relevant to the items and services offered. Accordingly, if the merchant's appointments are all filled, then the merchant can remove the tag for "appointments available" and thus immediately be removed from searches requesting available appointments.

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

[0045] 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.

[0046] 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 by the various users at a given moment because each item is tagged in real time rather than delaying the discovery of an item once available or prolonging the discovery of an item beyond its availability.

[0047] Further innovative aspects are provided which facilitate communications. As discussed above, the client device may be configured to search for users by tags. Conversation threads or bidding dialogs can be created and filtered based on bidirectional information. A bidding dialog may comprise communications between users and/or merchants regarding the purchase, rental, or exchange of a good or service. The bidding dialog may also comprise user bidding or merchant bidding during an auction or bidding event. For example, a user may bid on an item or service offered by a merchant. A user bidding on an item offered by a merchant may comprise the user placing a bid of the amount of money the user is willing to pay for an item. If another user places a higher bid, i.e., a higher amount than the other user is will to pay, then the first user may place another bid. At the end of the auction or bidding event, the merchant may provide the item or service to the winning user (i.e., user who agreed to pay the most) in exchange for the money promised in the bid. Alternatively, the bidding dialog may involve single bids, where each recipient to the bidding dialog has an opportunity to submit the price he or she is will to pay. Then, from all the responses the merchant receives, he may choose the winning bidder. The winning bidder may be selected based on a selection (e.g., via an interface). In some implementations, the selection may be based on predetermined characteristics such as the highest bid, the user located the closest to the merchant, a user associated with certain tags. In some implementations, the presentation of the bids may be order based on these predetermined characteristics to facilitate receipt of a selection via an interface. Similarly, the user may request bids from merchants, meaning a user desiring an item or service may request merchants to provide prices that they would accept in exchange for the item or service. In such situations, the merchants may provide the minimum price that the merchant would accept in exchange for the item or service. If a first merchant places a bid, and a second merchant decides that he/she can accept a lower amount and places a lower bid, then the first merchant may provide a new lower bid. Such a process may be repeated until a time expires or the user accepts a bid. Alternatively, the user may request a single bid from each merchant and choose the lowest priced merchant or choose a merchant based on some other criteria from each merchant response and not allow merchants to reduce their bids in light of bids from other merchants.

[0048] From the user's perspective, the local tags can be used to filter users based on how the user sees the world. From the perspective of any user of the system, global tags can also be used to filter users based on how each user wishes to be seen. This bidirectional optimization enables efficient and flexible communications such as: one to one conversation threads or bidding dialogs between two users, group conversation threads or bidding dialogs amongst several users, and group "blind carbon copy" (Bcc) conversation threads or bidding dialogs. 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)). The system may be configured to pause communications in the conversation thread or bidding dialogs. Pausing communications generally refers to suspension of receipt of conversation items for a conversation thread. The system may be further configured to re-enable the thread upon receipt of a message 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 or bidding dialog 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 or bidding dialog thread by different types of media such as video, audio, or text.

[0049] Consider the following example of the communication features described. As a first step, a user submits via a client device a search of the conversation threads or bidding dialogs conducted via the client device for a tag the user previously created, e.g., an oil change for the user's vehicle. The result of this search is an instant list of any user that had previously had this tag assigned. Next, the user chooses a type of group conversation thread or bidding dialog to conduct. The type may include: group conversation thread or bidding dialog, group Bcc conversation thread or bidding dialog, or individual conversation thread or bidding dialog. Then, the user selects the type of media to send. The media types may include text, audio, picture, video, or emoticon. The user may thus initiate the communication session based on the provided information. At any time, the author may pause the conversation thread or bidding dialog.

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

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

[0052] During a conversation or bidding dialog, at any time the system can pause or resume the conversation or bidding dialog in response to a user's request. At any time the system is configured to receive and process a request to delete the entire conversation thread or bidding dialog 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 any one of the author of the thread, a participant in the thread, or based on another user role defined in relation to the thread. In some embodiments, only the author of the thread may be able to request deletion of the thread. In alternative embodiments, each participant of the thread may confirm and agree to delete the thread before it is deleted, while other embodiments may only have the author confirm a deletion request by any participant.

[0053] During the course of communication, the need to perform a transaction may arise. For example, if a user desires to purchase tickets to a concert, the user may perform a search for other users or entities with tickets for sale. Then, a communication may be sent to a selection of the users or entities returned from the search having a tag value identifying the band playing at the concert and having a tag value identifying tickets available for purchase. Then the user may access the system to initiate an auction with the selection of the other users or entities to see who may be willing to sell their tickets for the lowest price. Once the user identifies an acceptable bid and wants to buy the tickets, the systems and methods described enable the consummation of the transaction. Similarly, a user selling tickets may use the same system in a reverse manner. For example, the user selling tickets may perform a search for users or entities interested in buying tickets. Then, the user selling the tickets may communicate with a selection of the users or entities in the search results having been identified (via tag values or other identifiers) that they are interested in the band or in a concert that evening. Then the user selling the tickets may initiate an auction with the selection of other users or entities to see who may be willing to pay the most for the tickets. Once the user identifies an acceptable bid, the user may use the systems and methods described to enable completion of the transaction. It should be appreciated that the above mentioned privacy measures may be maintained throughout the transaction. This provides a further non-limiting advantage of conducting transactions with limited exchange of personal information.

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

[0055] 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.

[0056] 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).

[0057] 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, bidding dialogs, or the database. The system receives and analyzes search phrases 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 real-time 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.

[0058] Having conducted a search, the user may then enter a discovery phase. Discovery may include the user evaluating the search results. The evaluation may include browsing ranked results, browsing categorized results, filtering the search results, and refining the search. The results may include items available via various other users of the system.

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

[0060] In another innovative aspect, there may be a communication server comprising an account manager configured to receive user account information. The user account information received may include credentials, a tag manager, a search engine, a conversation module, and a transaction module. The tag manager may be configured to receive public descriptors and private descriptors for a user account, while the search engine may be 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. The conversation module may be 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 and 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. The transaction module may be configured to consummate a transaction between users based on a conversation between the users. In some instances, consummating a transaction between users and/or merchants may comprise enabling the transacting parties to exchange money or goods in return for services or goods. Thus, the transaction module may allow parties to exchange money and/or goods as necessary to purchase the desired goods or services, or vice versa. Accordingly, the transaction module may comprise payment processing methods and services, e.g., credit card processing systems or bank account transfer systems, that causes a payment for a service or an item via, for example, messaging between the transaction module and the remote payment systems.

[0061] In another innovative aspect, there may be a bidirectionally guided directory system, the 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 directory identifying a plurality of goods and services available from various users, 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 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.

[0062] Example implementations of the system and method discussed above are described below in further detail in connection with FIGS. 1-12.

[0063] 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 110η). It will be appreciated that fewer or more client devices may be included in the system 100. The client device 110a and the client device 11 On (collectively or individually hereinafter referred to as "client device 110") may be an electronic communication device configured to transmit and receive conversation items in a 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.

[0064] The messages the client device 110 may be configured to transmit and receive may include the tagging and conversation items described herein. For example, a system user may utilize a first client device 110 to communicate with one or more merchant client devices. The client device 110 may include specialized circuitry configured to transmit, receive, generate, and process the messages discussed in further detail below. In some implementations, the client device 110 may include a processor which is configured to execute stored instructions which cause the client device 110 to transmit, receive, generate, and process the messages described. The client device 110 may include additional modules as described in connection with FIG. 2A and FIG. 2B below.

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

[0066] The system 100 includes an enterprise server 140. The enterprise server 140 is configured to provide tagging and communication information. The tags may facilitate the discovery of an item, location, or person. The communication information may include a message regarding an event. In a merchant implementation, the message may indicate a sale on a particular item. In a hospitality implementation, the message may identify the starting time for a performance. In a variety of settings, the message may be used to convey emergency information such as a fire, earthquake, or other time and location sensitive event information.

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

[0068] The communication server 102 may be configured to receive conversation threads or bidding dialogs for user accounts. The conversation threads or bidding dialogs may be associated with one or more tags. The conversation threads or bidding dialogs may also 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 or bidding dialog. For example, the conversation thread or bidding dialog may not be distributed outside a predetermined set of users. As another example, the conversation thread or bidding dialog may have limited visibility such as only being visible to users associated with a predetermined tag. Accordingly, when a user requests the system perform a search, the conversation thread or bidding dialog may be provided if the tags (e.g., global and/or personal) associated with the user satisfy the distribution rules for the conversation thread or bidding dialog.

[0069] As one example, consider a user interested in purchasing an item (e.g., an "oil change") from a merchant. The user may perform a search for tags containing or relating to the oil change purchase, and may add the tag to their search tags. As discussed above, one or more merchants may tag themselves as being a "locksmith" or a "mechanic" or as being able to perform "rekeying" or an "oil change" or generally as performing "locksmithing services" or "automotive services," respectively. One or more merchants may post a conversation thread or threadsite (e.g., a promotion) to their account with a tag "Cheap oil change". The user's search may show results of all merchants having a user account which is associated with the tags or conversation threads "Oil change" in the system 100, and both the "oil change" tags and conversation threads may be provided. In some embodiments, a merchant may update its tags or chats based upon availability or appointments. For example, a mechanic with the "oil change" tags and/or "oil change" conversation thread may remove the tags and/or conversation thread when all available appointments are reserved or when they run out of oil. Thus, when the tags are removed, that merchant will no longer be included in the search results for those tags, and thus the merchant may be able to dynamically control exposure to potential clients and patrons as they wish.

[0070] The communication server 102 may further manage the distribution and life of a conversation or bidding dialog. For example, the communication server 102 may pause or snooze an ongoing conversation or bidding dialog. The communication server 102 may also allow a conversation thread or bidding dialog thread to be deleted. Receiving a message to delete a conversation thread or bidding thread causes 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 or bidding dialog thread. This allows users a higher degree of control over conversation thread or bidding dialog messages.

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

[0072] 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 [0073] 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.

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

[0075] 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 a predefined set of tags (e.g., tags 222), may allow rules to allow tags to be acceptable by a server (e.g., the communications server 102 in FIG. 1), and may allow for communication of the tags 222 between the client (e.g., the client device 110 in FIG. 1) and the database 220. The tags 222 are associated with one or more user accounts 224 which may also be stored in the database 220. The database 220 may further include tag verification rules. The tag verification rules may be provided through a user interface on the client device 110 to allow personal verification rules. In some implementations, the tag verification rules may be provided by the communication server 102 to enforce system- wide tag verification.

[0076] Continuing with the client device implementation of the electronic communication system 200, a synchronization module 230 may be included. The synchronization module 230 is configured to synchronize information stored on the client device 110 with the communication server 102. For example, the client device 110 may be configured to operate without a network connection (e.g., "offline"). In such a configuration, the client device 110 may receive tag information (e.g., new tags, updated tags). Similarly, while the client device 110 is offline, the communication server 102 may receive new tag information. The synchronization module 230 determines which information to transmit to the communication server 102 to synchronize the locally stored information with the centralized storage on the communication server 102. The determination may be based on a timestamp associated with the tag information. For example, when a record is created, modified, or deleted in the database 220, a timestamp may be applied to the record. 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.

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

[0078] The synchronization module 230 synchronizes a client device and a communication server. In some implementations, it may be desirable to synchronize a group of client devices. 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 FIG. 2 A and FIG. 2B as separate elements, the database 220 may be included in a portion of the memory 292.

[0079] 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 110 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.

[0080] Once a conversation is started, 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. In some implementations, the conversation module 240 may provide a message indicating additional content has been received. For example, the conversation module 240 may receive the promotion from the sports team and provide a summary for display on via the client device "Limited Time Promotion from Sports Team!" In some implementations, the conversation module 240 may generate the message based on the conversation information (e.g., sender, content). In some implementations, the conversation information may include a summary for quick display.

[0081] A bidding module 245 may be included in the electronic communication device 200. The bidding module 245 is configured to manage threaded bidding dialogs. The bidding module 245 may receive information for a new bidding dialog. The new conversation information may include one or more contacts to include in the bidding dialog. The new bidding dialog information may include bidding dialog content such as text, image, video, or executable instructions (e.g., application). The content may be static or streaming (e.g., realtime). The new bidding dialog information may include distribution rules. The distribution rules allow the bidding dialog starter to control when, where, and with whom the bidding dialog may be conducted. For example, the user who initiates the bidding dialog may choose to lock the list of recipients. Once locked, only the recipients identified by the user may participate in the bidding dialog. Participation in a bidding dialog can include one or more of accessing the bidding dialog content, replying to the bidding dialog content, forwarding the bidding dialog content, providing a bid, responding to bids, reviewing bids, and deleting the bidding dialog content.

[0082] Once a bidding dialog is started, the bidding module 245 may be configured to receive additional content contributed to the bidding dialog. The additional content may be stored in the database 220. The additional content may be presented such as via a graphical user interface. In some implementations, the bidding module 245 may provide a conversation thread, threadsite, or other message indicating additional content has been received. In some embodiments, the functionality of the bidding module 245 may be incorporated into the conversation module 240.

[0083] As discussed above, a client device may operate offline. In such circumstances, conversations may be read, responded to, deleted, or started. The conversation and bidding dialog information, such as the tags or threads, 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.

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

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

[0086] The system 200 in FIG. 2 A includes a rating module 265. When implemented in a client device, the rating module 265 is configured to retrieve rating information for a conversation item. For example, the rating module 265 may obtain a merchant rating value for a merchant that created the conversation item. In another example, the rating module 265 may obtain reviews for a conversation item. The reviews may be aggregated (e.g., total or average review from all users submitting a review). The review module 265 in a client device may be further configured to receive a user review information from a transaction or conversation item. This may include providing a review interface to collect structured, semi- structured, or free-form review information or some combination thereof.

[0087] When implemented in a communication server, the rating module 265 is configured to provide the rating information for a conversation item. For example, the rating module 265 may generate a merchant rating value for a merchant that created the conversation item. In another example, the rating module 265 may provide reviews for a conversation item. The reviews may be aggregated (e.g., total or average review from all users submitting a review). The review module 265 in a server device may be further configured to solicit a user review information from a transaction or conversation item. For example, after a transaction is completed, the server, via the review module 265, may transmit a request for user review information. This may include providing a review interface to collect structured, semi- structured, or free-form review information or some combination thereof. Upon receipt of the review information, the server may store the review information for future consideration (e.g., a request for review information from another client device). The review information provided by the reporting module 265 of the server may include a name (e.g., username) of reviewer, item reviewed, user reviewed, feedback score, an indicator as to whether the submitting reviewer allows communication (e.g., can be contacted for further information through a conversation thread), best time to reach reviewing user, etc.

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

[0089] 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.

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

[0091] 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.

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

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

[0094] FIG. 2B is a functional block diagram of an exemplary implementation of the wireless communication system in FIG. 2A. As illustrated in FIG. 2B, the electronic communication system 200 (FIG. 2A) may be implemented as an electronic communication system 200a in the client device 110 and/or as another electronic communication system 200b in the communication server 102. Reference to the electronic communication system 200 (FIG. 2A) herein refers to any implementations of the electronic communication system 200a, 200b. The client device 110 may be in communication with the communication server 102 through the network 109. Individual modules of the electronic communication systems 200a, 200b may further be in communication with one another either within each of the electronic communication systems 200a, 200b or 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 modules in either the client device 110 or the communication server 102, such as tagging modules 210a, 210b.

[0095] 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. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein. In one implementation, the tagging module 210 may be implemented in the communication server 102 and/or the client device 110 (FIGS. 1-2B).

[0096] Messaging 302 may be performed to create a new user account and can be performed by accessing the database 220. In order to create a user account 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., Facebook™, Twitter™, Google+™, 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. In one embodiment, the system may give the user an option to input connection information (e.g., username, password, address) for the user's existing online accounts. 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 system may prompt the user to link the automatically searched existing online user personal or business accounts. In response to message 302, 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 110.

[0097] 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. In one embodiment, the communication server 102 may automatically generate and assign an internal user ID. The automatic user ID may be of random alphanumeric characters.

[0098] 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.

[0099] 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.

[0100] 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. In one embodiment, 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 system may prompt the user with pre-populated potential tags and asked to confirm creation of the pre-populated tags. Once the tagging module 210 receives the user information, it 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.

[0101] Messaging 312 may be performed to store the newly generated tags in the database 220. In one embodiment, 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. In one embodiment, 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.

[0102] After the user creates the new user account, the user 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 110 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. In one embodiment, 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. In one embodiment, the user may be allowed to override the tagging restrictions, and in some implementations, the user may be allowed to override only some of the tagging restrictions. Upon receiving the public self tag requests, the tagging module may generate one or more tags based on the user inputted words or phrases.

[0103] 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.

[0104] Upon storing the public self tags and linking them to the user account, messaging 318 may be performed to update a public search index. Reflecting various implementations of a public search, 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. In one embodiment, 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. In one embodiment, a public search may be tailored to the search requester's user account. In another embodiment, a public search may universal to all the user accounts in the database 220.

[0105] 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. In one embodiment, the private contact tags are user-specific, and they may reflect the user's own description of the contact only available to the user.

[0106] 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. [0107] Upon storing the private contact tags and linking them to the user account, 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. In one embodiment, 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.

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

[0109] Messaging 502 may be performed to request a private search to be executed by the search module 250. The client device 110 may send search terms inputted by the user of the client device 110. In one embodiment, the system may prompt the user with options to select a subset of the user's contacts to narrow the search target. The options may be predefined (e.g., categories) or dynamically specified such a via a user input value. In one embodiment, the system may present the user with the option to exclude certain contacts from the private search. A private search may be performed to search the user's entire contacts. In one embodiment, a private search may be performed on the user's conversation threads with one or more of the user's contacts. The system may give the user an option to exclude conversation threads from the private search. In one embodiment, the system may give the user suggested search terms which the user may select instead of the user inputted search terms.

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

[0111] Messaging 506 may be performed to retrieve contact data from the database 220 by the search module 250. After the search module 250 performs a search on relevant subsets of data in the database 220, the search module 250 may receive contact data as a result of the private search. The search module 250 may further process the retrieved contact data in preparation for presenting the search result to the user of the client device 110.

[0112] Messaging 508 may be performed to receive and display search result by the client device 110. In one embodiment, the search module may sort and organize the contact data it retrieved from the database 220. The search module 250 may send raw search results to the client device 110, and the client device may sort and organize the raw search results contact data it received from the search module 250. In one embodiment, the search results may be presented to the user based on user-defined priorities. In one embodiment, the search results may be prioritized based on relevance and/or the user's communication frequency with the contacts, for example.

[0113] Once the user is provided with a private search result, the user may select one or more of the contacts from the search result, and messaging 510 may be performed to request to create a conversation thread by the client device 110. In one embodiment, the user may select one or more contacts from the private search result to start a conversation thread. In one embodiment, anyone who joins the conversation thread may invite and add others. In one embodiment, the user may select to create a locked conversation thread, which may limit adding a new participant to the conversation thread by participants but may allow the conversation originator the option to add a participant at any time. In one embodiment, 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. In one embodiment, a broadcast conversation thread may allow participants to identify others within the broadcast. In another embodiment, a broadcast conversation thread may disallow participants from identifying others within the broadcast if the user elects to enable blind carbon copy (BCC). In one embodiment, the user may select to blind carbon copy (BCC) the conversation thread recipients so that the recipient may not be able to view other conversation participants nor their response to the user. When the user utilized the Bcc mode in conversation threads, each user will only receive the name of the sending user and will not receive the names or be aware of other recipients of the communication. When Bcc mode is not selected, the recipient users may be able to see the names of all recipients to whom the communication was sent. For example, referencing the locksmith example above, when Peter receives the search results of Sam and Larry and requests to initiate a communication or conversation thread with both of Sam and Larry, if Peter chooses to create a Bcc conversation, then Sam and Larry will not be aware of the communication or conversation thread going to the other merchant. If Peter chooses not to select a BCC conversation, then Sam and Larry may both see that the message went to the other merchant as well. The client device 110 may receive from the user all the requisite and optional inputs for creating a conversation thread and may send a conversation request (e.g., to a communication server or another client device) based on the user's inputs.

[0114] Messaging 512 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 110. The conversation module 240 may be configured to create a communication or conversation thread to which multiple users of the system 100 may be added. In one embodiment, the conversation thread may also be stored in the database 220. In one embodiment, 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 multiple participants to send and receive instant conversation items including text, audio, video, image, and other content through the conversation thread. According to the user's conversation request, 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. [0115] Messaging 514 may be performed to add one or more tags to the conversation created in response to the user's conversation request. The user may input one or more words describing the conversation thread on the user device 110, and the user device may send the conversation tag information to the tagging module 210. In one embodiment, the conversation tag may be searchable by any user in the system 100. In some implementations, the conversation tag may be searchable only by the user's contacts. The conversation tag may not be searchable by users other than the creator of the conversation thread. In one embodiment, the conversation tags may be public tags, which may be searchable by any user of the system. The conversation tags may be private tags, which may be searchable only by the tag creator. In another embodiment, the conversation tags may be either private or public and the tag creator may be given an option to choose either.

[0116] Messaging 516 may be performed to store the conversation tags created in response to the user's conversation tag request. In one embodiment, the conversation tags may be linked to the conversation thread in the database 220. In one embodiment, the conversation tags may also be linked to all the participants of the conversation thread or only to the conversation tag creator.

[0117] Messaging 518 may be performed to update one or more indices in the database 220 based on the newly created conversation tags. In one embodiment, the private search index may be updated to reflect a creation of the private conversation tags. The public search index may be updated to reflect a creation of the public conversation tags. It may be desirable for both the private and public search indices may be updated to reflect a creation of the private and public conversation tags.

[0118] FIG. 4B is an exemplary message diagram for creating a bidding thread in accordance with one embodiment. This message diagram may result from a user's need to find and contact a business. In some embodiments, the user may need to purchase an item or service from a business. In some embodiments, the user may initiate communications with one or more businesses as the result of a search, and may initiate a bidding event during which target businesses may bid on the user's patronage. The message flow of FIG. 4B shows an embodiment of messages exchanged between several entities which can be included in a communication system. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein. In one implementation the search module 250, 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, 2 A, and 2B).

[0119] FIGs. 4A and 4B share many of the same messages to show the potential overlap that may occur between the conversation module 240 and the bidding module 245. The messages that are similarly numbered may be performed by either the conversation module 240 or the bidding module 245 and are intended to show that the system may comprise a dedicated bidding module 245 or may utilize the existing conversation module 240 to perform the function of the bidding module 245. For example, this may show that an existing user device without a bidding module 245 may be capable of providing the user with bidding dialog and bidding capabilities via an updated device configuration to enable functionality of the conversation module 240. For example, an existing user device 110 without a bidding module 245 may be given a software update to allow the conversation module 240 to act as a bidding module 245. Alternatively, an existing user device 110 without a bidding module 245 may be upgraded with additional hardware (e.g., component chips) containing the bidding module 245. The updated configuration may comprise introducing an additional bidding module 245 with the sole function of providing bidding dialog and bidding capabilities to the user device.

[0120] Contact/Global Search request 502 may be performed to request a public or private search to be executed by the search module 250. The client device 110 may send search terms inputted by the user of the client device 110. In some embodiments, the search terms may be sourced from client device memory, having been stored by the client device 110 after a previous search. In one embodiment of a private search, the system may prompt the user with options to select a subset of the user's contacts to narrow the search target. The options may be predefined (e.g., categories) or dynamically specified, such as via a user input value. In one embodiment of a private search, the system may provide the user with an option to exclude certain contacts from the private search. A private search may be performed to search the user's entire contacts. In one embodiment, a public search may be performed on the database of public users and threadsites. As with the private search, in an embodiment of the public search, the system may prompt the user with options to narrow the search target, e.g., proximity, the business type, hours of operation, etc. In one embodiment, the system may suggest search terms which the user may select instead of the user inputted search terms. It will be appreciated that the search may be distributed between a client device and a server device such that the contact search is performed by the search module 250a of the client device 110 and the global search is performed by the search module 250b of the communication server 102.

[0121] Messaging 504 may be performed to access and search relevant portions of the database 220 by the search module 250. The relevant portions of the database may be determined by the search terms provided in contact/global search request 502 and/or the options narrowing the search target. Once the search module 250 receives a public or private search request with search terms, the search module 250 may process the search terms to optimize the public or private search. In one embodiment, only the private search index in the database 220 may be searched in response to the private search request. In one embodiment, the search module 250 may search the public tags of business profiles. In one embodiment, the search module 250 may search the user's private tags. The search module 250 may search the user's private tags in conjunction with the user's contacts' public tags. In one embodiment, the search module 250 may access only information on the user's contacts in the database 220 in response to the private search request. In one embodiment, the search module 250 may access information on the user's contacts as well as information with any number of public contacts that meet the requirements of the user's public search request.

[0122] Contact/Global contact data response 506 may be performed to communicate contact data from the database 220 to the search module 250. This contact data may be the contact data of businesses and contacts who meet the search criteria of the user's public or private search request. After the search module 250 performs a search on relevant subsets of data in the database 220, the search module 250 may receive contact data as a result of the public or private search. The search module 250 may further process the retrieved contact data in preparation for presenting the search result to the user of the client device 110. [0123] Messaging 508 may be performed to receive and display search result by the client device 110. In one embodiment, the search module may sort and organize the contact data it retrieved from the database 220 before they are received and displayed by the client device 110. The search module 250 may send raw search results to the client device 110, and the client device 110 may sort and organize the raw search results data it received from the search module 250. In one embodiment, the search results may be presented to the user based on user-defined priorities or based on the narrowing options of the Contact/Global search request 502. In one embodiment, the search results may be prioritized based on relevance and/or the user's communication frequency with the resulting contacts, for example.

[0124] Once the user is provided with a public or private search result, the user may select one or more of the contacts from the search result, and bidding dialog request 510 may be communicated to the bidding module 245 to request to create a bidding dialog thread by the client device 110. In one embodiment, the user may select one or more contacts from the private search result to start a bidding dialog thread. In one embodiment, only the user may invite and add other parties to the bidding dialog thread, the user selecting to create a locked bidding dialog thread, which may limit adding a new participant to the bidding dialog thread. In one embodiment, the user may select to create a bidding dialog thread while remaining anonymous to all entities or other users involved in the bidding dialog thread. Additionally, in some embodiments, the user may select a time limit or deadline by which the bidding dialog may terminate or be completed. In one embodiment, the user may select to blind carbon copy (BCC) the bidding dialog thread recipients so that each recipient may not be able to view other recipients of the bidding dialog thread. As discussed above, when the user utilizes the BCC mode when requesting a bidding dialog thread be created, each selected recipient may only receive the name of the sending user and may not receive the names or be aware of other participants in the bidding dialog. When BCC mode is not selected, the recipients may be able to see the names of all recipients who are participating in the bidding dialog. For example, referencing the locksmith example above, when Peter receives the search results of Sam and Larry and requests to initiate a bidding dialog with both of Sam and Larry, if Peter chooses to create a BCC bidding dialog, then Sam and Larry will not be aware of the other merchant participating in the bidding dialog. If Peter chooses not to select a BCC bidding dialog, then Sam and Larry may both see that the other merchant is participating in the bidding dialog. The client device 110 may receive from the user all the requisite and optional inputs for creating a bidding dialog thread, for example an item or service the user wishes to bid on, any maximum or minimum prices or quantities, or delivery/service dates for the item or service. The client device 110 may send a bidding dialog request based on the user's inputs.

[0125] Bidding dialog thread created message 512 may be communicated by the bidding module 245 to create a bidding dialog thread based on the bidding dialog request 510 from the user of the client device 110. The bidding module 245 may be configured to create a bidding, or bidding dialog, thread to which multiple users of the system 100 may be added. In one embodiment, the bidding dialog thread may also be stored in the database 220. In one embodiment, the bidding dialog thread may be linked to all the participants of the bidding or only linked to the bidding requester, i.e., the user. The bidding module 245 may be configured to allow one or more participants to send and receive instant messages through the bidding dialog thread. According to the user's bidding dialog request, the bidding module 245 may be configured to limit the thread participant's ability to reply to the bidding or bidding dialog, view other thread participants, and/or add additional participants.

[0126] Messaging of the bidding dialog tag request 514 may be performed to add one or more tags to the bidding dialog created in response to the user's bidding dialog request. The user may input one or more words describing the bidding dialog thread on the user device 110, and the user device 110 may send the bidding dialog tag information to the tagging module 210. In one embodiment, the bidding dialog tag may be searchable by any user in the system 100. The bidding dialog tag may be searchable only by the user's contacts. It may be desirable for a bidding dialog tag to not be searchable by users other than the creator of the bidding dialog thread. The bidding dialog tags may be either private or public and the tag creator may be given an option to choose either.

[0127] Store bidding dialog tag message 516 may be communicated to store the bidding dialog tags created in response to the user's bidding dialog tag request. In one embodiment, the bidding dialog tags may be linked to the bidding dialog thread in the database 220. In one embodiment, the bidding dialog tags may also be linked to all the participants of the bidding dialog thread, or only linked to the bidding dialog tag creator.

[0128] Update index messaging 518 may be performed to update one or more indices in the database 220 based on the newly created bidding dialog tags. In one embodiment, the private search index may be updated to reflect a creation of the private bidding dialog tags. The public search index may be updated to reflect a creation of the public bidding dialog tags. Both the private and public search indices may be updated to reflect a creation of the private and public bidding dialog tags.

[0129] In some embodiments, the messaging and actions performed by the bidding module 245 may also be performed by the conversation module 240. The technical features of the bidding module 245 may also be integrated into the conversation module 240.

[0130] FIG. 4C is an exemplary message diagram for transacting through a conversation thread in accordance with one embodiment. The message flow of FIG. 4C shows messages exchanged between several entities which can be included in a communication system. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein.

[0131] Messaging 550 may be performed to request a public search to be executed by the search module 250. The client device 110 may be configured to send search terms inputted by the user of the client device 110. In one embodiment, the system may prompt the user with options to select a subset of the database 220 to narrow the search target. In one embodiment, the system may give the user an option to exclude the user's entire contacts from the public search. The system may be configured by the user to exclude some of the user's contacts from the public search. In one embodiment, a private search may be performed to search the database 220. In one embodiment, a public search may be performed on the public conversation threads regardless of whether the user or any one of the user's contacts is participating in the conversation. In one embodiment a public search may be performed on public conversation tags. The system may give the user an option to exclude conversation threads from the public search. In one embodiment, the system may give the user suggested search terms which the user may select instead of the user inputted search terms. [0132] Messaging 552 may be performed to access and search relevant portions of the database 220 by the search module 250. Once the search module receives a public search request with search terms, for example, the search module 250 may be configured to process the search terms to optimize the public search. In one embodiment, the public search index in the database 220 may be searched in response to the public search request. In one embodiment, the search module 250 may be configured to search other users' public tags. The search module 250 may be configured to search the user's private tags in conjunction with other users' public tags. In one embodiment, the search module 250 may access information on other users' public profile information in the database 220 in response to the private search request. In one embodiment, the search module 250 may be configured to access information on other users' public profile as well as other users' conversation having public tags in the database 220 in response to the public search request.

[0133] Messaging 554 may be performed to retrieve public search data from the database 220 by the search module 250. After the search module performs a search on relevant subsets of data in the database 220, the search module 250 may receive data as a result of the public search. The search module may further process the retrieved public search data in preparation for presenting the search result to the user of the client device 110.

[0134] Messaging 556 may be performed to receive and display search result by the client device 110 to the user. In one embodiment, the search module 250 may be configured to sort and organize the public data it retrieved from the database 220, for example based on proximity to the user or availability of the item or appointment for the service. The search module may send raw search result data to the client device 110, and the client device may sort and organize the raw search result data it received from the search module. In some other embodiment, the search result may be presented to the user based on user-defined priorities. In alternate embodiments, the search result may be prioritized based on relevance, priority, location, and/or distance from the user, for example.

[0135] Once the user is provided with a public search result, the user may select one or more of the entries (e.g., other personal users, business users, etc.) in the search result, and messaging 558 may be performed to request to create a conversation thread by the client device 110. In one embodiment, 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. In an additional embodiment, the user may select to create a locked conversation thread, which may limit adding a new participant to the conversation thread. In some other embodiments, 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. 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. As discussed above, when the user utilizes the BCC mode when requesting creation of a conversation thread, each selected recipient may only receive the name of the sending user and may not receive the names or be aware of other participants in the conversation thread. When BCC mode is not selected, the recipients may be able to see the names of all recipients who are participating in the conversation. For example, referencing the locksmith example above, when Peter receives the search results of Sam and Larry and requests to initiate a bidding dialog with both of Sam and Larry, if Peter chooses to create a BCC conversation, then Sam and Larry will not be aware of the other merchant participating in the conversation. If Peter chooses not to select a BCC conversation, then Sam and Larry may both see that the other merchant is participating in the conversation. The client device 110 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.

[0136] Messaging 560 may be performed by the conversation module to create a conversation thread based on the conversation request from the user of the client device 110. The conversation module may create a communication thread to which multiple users of the system 100 may be added. In one embodiment, the conversation thread may also be stored in the database 220. In one embodiment, the conversation thread may be linked to all the participants of the conversation. For example, the conversation module 240 may add tags defining individual users to the conversation thread, indicating that the individual users were either associated with the conversation thread itself or were discussed in the thread. Alternatively, the conversation module 240 may add the conversation thread as a tag to the individual users to that all the users are associated with the conversation thread and may discovered via a search of the thread or elements of the thread. The conversation thread may be only linked to the conversation requester, wherein only the conversation requestor may be added as a tag to the conversation thread or the conversation thread may only be added to the tags of the conversation requestor. In some embodiments, no users may be associated with the conversation thread via tagging or any other means. The conversation module 240 may be configured to allow multiple participants to send and receive instant conversation items including text, audio, video, images, and/or other content through the conversation thread. According to the user's conversation request, 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.

[0137] Messaging 562 may be performed to request a transaction with one of the participants of the conversation thread. As the user communicates with one or more other users through the conversation thread, the user may decide to transact with one of the participants. In one embodiment, the user may create a transaction channel associated with the conversation thread. In one embodiment, the conversation thread may have embedded transaction options for the user to choose from. A transaction channel may have been created when the conversation was tagged by the user or other participants as a transactional thread. In one embodiment, the system may prompt the user to input the amount of money to be exchanged and the method of exchanging money. In another embodiment, the transactional information (e.g., amount of money, method of payment, etc.) may be prepopulated based on the conversation among the participants in the conversation thread and/or one or more conversation threads. In one embodiment, the system may prompt the user 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.

[0138] Messaging 564 may be performed to send transactional information to the network 190 to consummate the transaction requested by the user of the client device 110. Once the transaction module 260 receives and processes the transaction information provided by the user, 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. In one embodiment, a single transaction may involve more than one transaction server and may involve more than one message similar to message 564.

[0139] Messaging 566 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. In one embodiment, the third party transaction server 150 may be configured to send a confirmation code or a receipt number upon completion of the transaction. In one embodiment, more than one server may be involved in the transaction, and there may be more than one message such as message 566 to consummate the transaction. In one embodiment, the transaction module 260 may be configured to receive a transaction unsuccessful message through the network 190, and there may be one or more following messages between the transaction module 260, client device 110, and/or third party servers 150 (FIG. 1) to complete a successful transaction. In one embodiment, the transaction may not need a third party server, and the entirety of the transaction may be consummated within the communication server 102 (FIG. 1) without messages 564 and 566. In one embodiment, the transaction module 260 implemented in the client device 110 (FIG. 1) may transmit a transaction request to a server by means of the network 190 for processing without requiring that a response (successful or unsuccessful) 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.

[0140] Messaging 568 may be performed to send a transaction complete report to the client device 110 in response to the transaction request of the user of the client device 110. Upon completion of a successful transaction, the transaction module 260 may have obtained a confirmation code or a receipt number of the completed transaction. The transaction module 260 may forward that information to the client device 110 for further reference for the user of the client device 110. The transaction module 260 may also send to the client device a message confirming the additional information exchanged between the conversation participants associate with the transaction, such as place to meet, delivery method, return or exchange policy information, customer service, information, promotional information, discounts, etc. Upon receiving the transaction complete message, the client device 110 may further prompt the user to set up an appointment or a reminder for the user based on the additional transaction information (e.g., delivery estimate date reminder, time and place to meet, promotion expiration date reminder, return or exchange expiration date reminder, etc.).

[0141] FIG. 4D is an exemplary message diagram for transacting through a bidding dialog thread in accordance with one embodiment. This message diagram may result from a user's need to find and contact an entity and a desire to purchase a service or item from the entity. In some embodiments, the user may perform a search of entities offering the desired service or item, initiate communications with one or more entities provided in a search result, and may initiate a bidding dialog event during which target entities may communicate with the user and bid (i.e., lower the price of their service or item) to earn the user's patronage. In some embodiments, once the user has accepted a price offered by one of the entities, the user may transact with that entity to order the service or item and/or to reserve the service or item. FIGs. 4C and 4D share many of the same messages to show the potential overlap that may exist between the conversation module 240 and the bidding module 245. The messages that are similarly numbered may be performed by either the conversation module 240 or the bidding module 245 and are intended to show that the system may comprise a dedicated bidding module 245 or may utilize the existing conversation module 240 to perform the function of the bidding module 245. For example, the ability for a conversation module 240 to perform the tasks of a bidding module 245 suggests that an existing user device without a bidding module 245 may be capable of providing the user with bidding dialog and bidding capabilities via an updated device configuration that enables functionality of the conversation module 240 to provide the benefits of a bidding module 245. As discussed above, an existing user device 110 without a bidding module 245 may be given a software update to allow the conversation module 240 to act as a bidding module 245. Alternatively, an existing user device 110 without a bidding module 245 may be upgraded with additional hardware (e.g., component chips) containing the bidding module 245. In another embodiment, the updated configuration may comprise introducing an additional bidding module 245 with the sole function of providing bidding dialog and bidding capabilities to the user device.

[0142] The message flow of FIG. 4D shows messages exchanged between several entities which can be included in a communication system. For ease of explanation, the number of entities shown has been limited. However, it will be understood that additional entities can be added or multiple entities combined consistent with the description herein. Additionally, it will be understood that fewer or additional messages may be included in the message flow of FIG. 4D with the same results.

[0143] Global/contact search request messaging 550 may be performed to request a public or private search to be executed by the search module 250. The client device 110 may be configured to send search terms inputted by the user of the client device 110. In one embodiment, the search terms may be saved in the memory of the client device 110 from a previous public or private search. The system may prompt the user with options to select a subset of the database 220 to narrow the search target. The system may prompt the user with options to narrow the search target, i.e., proximity of the entity, availability of the service or item, hours of operation for the entity, methods of payment accepted, etc. The system may give the user an option to exclude the user's entire contacts from the public or private search. The system may give the user an option to exclude some of the user's contacts from the public or private search. It will be appreciated that the search may be distributed between a client device and a server device such that the contact search is performed by the search module 250a of the client device 110 and the global search is performed by the search module 250b of the communication server 102.

[0144] In one embodiment, a public or private search may be performed to search the database 220. A public search may be performed on the public conversation and/or bidding dialog threads regardless of whether the user or any one of the user's contacts is participating in the conversation and/or bidding dialog. Such a search may assist the user by providing details of other recent searches, conversations, and bidding dialogs of the same or similar services or items the user may be searching for. In one embodiment a public search may be performed on public conversation and/or bidding dialog tags. The system may give the user an option to exclude conversation and/or bidding dialog threads from the public search. In one embodiment, the system may give the user suggested search terms which the user may select instead of the user inputted search terms.

[0145] Messaging 552 may be performed to access and search relevant portions of the database 220 by the search module 250. The relevant portions of the database may be determined by the search terms provided in global/contact search request 550 and/or the options narrowing the search target. Once the search module 250 receives a public or private search request with search terms, for example, the search module 250 may be configured to process the search terms to optimize the public or private search. In one embodiment, the public search index in the database 220 may be searched in response to the public search request. The private search index in the database 220 may be searched in response to the private search request. In one embodiment, the search module 250 may be configured to search other users' public tags. The search module 250 may be configured to search the user's private tags in conjunction with other users' public tags. In one embodiment, the search module 250 may access information on other users' public profile information in the database 220 in response to the private search request. In one embodiment, the search module 250 may be configured to access information on other users' public profile as well as other users' conversations and/or bidding dialogs having public tags in the database 220 in response to the public search request.

[0146] In one embodiment, the search module 250 may search the public tags of business profiles. In one embodiment, the search module 250 may search the user's private tags. In one embodiment, the search module 250 may access only information on the user's contacts in the database 220 in response to the private search request.

[0147] Global/contact data 554 may be communicated to retrieve public or private search data from the database 220 by the search module 250. After the search module performs a search on relevant subsets of data in the database 220, the search module 250 may receive data as a result of the public or private search. The search module may further process the retrieved public or private search data in preparation for presenting the search result to the user of the client device 110.

[0148] Messaging of the search result 556 may be performed to receive and display the search result by the client device 110 to the user. In one embodiment, the search module 250 may be configured to sort and organize the public and private data it retrieved from the database 220 before they are received and displayed by the client device 110. It may be desirable to configure the search module 250 to send raw search result to the client device 110, and the client device 110 may sort and organize the raw search result data it received from the search module 250 before displaying to the user. In one embodiment, the user may be able to sort and organize the raw search result data using various display options on the client device 110. In one embodiment, the search result may be presented to the user based on user-defined priorities or based on the narrowing options of the Global/contact search request message 550. In one embodiment, the search result may be prioritized based on relevance, popularity, the user's communication frequency with the resulting contacts, and/or sponsorship status, for example.

[0149] Once the system provides the user with a public or private search result, the user may select one or more of the entries (e.g., other personal users, merchant users, etc.) in the search result, and bidding dialog request 558 may be performed to request to create a bidding dialog thread by the client device 110. In one embodiment, the bidding dialog request 558 may be communicated to the bidding module 245. The bidding dialog request 558 may also be communicated to the conversation module 240. In one embodiment, the user may select one or more entries from the public or private search result to start a conversation thread. In one embodiment, only the user may invite and add other parties to the bidding dialog thread when the user elects to create a locked bidding dialog thread, which may limit adding a new participant to the bidding dialog thread. In one embodiment, the user may elect to create a bidding dialog thread while remaining anonymous to all entities or other users involved in the bidding dialog thread. Additionally, in some embodiments, the user may select a time limit or deadline by which the bidding dialog may terminate or be completed. Alternatively, in some embodiments the user may establish a price/bid range within which the user wishes to stay during the bidding process. In one embodiment, the user may elect to blind carbon copy (BCC) the bidding dialog thread recipients so that a recipient may not be able to view other bidding dialog recipients who received the same message through the conversation thread. As discussed above, when the user utilizes the BCC mode when requesting a bidding dialog thread be created, each selected recipient may only receive the name of the sending user and may not receive the names or be aware of other participants in the bidding dialog. When BCC mode is not selected, the recipients may be able to see the names of all recipients who are participating in the bidding dialog. For example, referencing the locksmith example above, when Peter receives the search results of Sam and Larry and requests to initiate a bidding dialog with both of Sam and Larry, if Peter chooses to create a BCC bidding dialog, then Sam and Larry will not be aware of the other merchant participating in the bidding dialog. If Peter chooses not to select a BCC bidding dialog, then Sam and Larry may both see that the other merchant is participating in the bidding dialog. The client device 110 may be configured to receive from the user all the requisite and optional inputs for creating a bidding dialog, for example a service or item the user wishes to bid on, any maximum or minimum prices or quantities, or delivery/service dates for the item or service. The client device 110 may send a bidding dialog request based on the user's inputs.

[0150] Message 512 may be communicated by the bidding module 245 to create a bidding dialog thread based on the bidding dialog request 510 from the user of the client device 110. The bidding module 245 may be configured to create a bidding or bidding dialog thread to which multiple users of the system 100 may be added. In one embodiment, the bidding dialog thread may also be stored in the database 220. In one embodiment, the bidding dialog thread may be linked to all the participants of the bidding dialog or linked only to the bidding requester, i.e., the user. The bidding module 245 may be configured to allow one or more participants to send and receive instant messages through the bidding dialog thread. According to the user's bidding dialog request, the bidding module 245 may be configured to limit the thread participant's ability to reply to the bidding or bidding dialog, view other thread participants, and/or add additional participants.

[0151] Bidding dialog thread created message 560 may be communicated by the dialog module 245 to create a bidding dialog thread based on the bidding dialog request 558 from the user of the client device 110 to the bidding module 245. The bidding module 245 may create a bidding dialog thread to which multiple users of the system 100 may be added. In one embodiment, the bidding dialog thread may also be stored in the database 220. In one embodiment, the bidding dialog thread may be linked to all the participants of the bidding dialog or linked only to the bidding dialog requester. The bidding module 245 may be configured to allow multiple participants to send and receive instant messages through the bidding dialog thread. According to the user's bidding dialog request, the bidding module 245 may be configured to limit the thread participant's ability to reply to the bidding dialog, view other thread participants, and/or add additional thread participants. [0152] Transaction request messaging 562 may be performed to request a transaction with one or more of the participants of the bidding dialog thread. In one embodiment, the transaction request may be in response to an agreement reached in the bidding dialog thread regarding the purchase of an item or service. The transaction request may be in response to an agreement for a rental or trade of an item. As the user communicates with one or more other users through the bidding dialog thread, the user may decide to transact with one of the participants. In one embodiment, the user may create a transaction channel associated with the bidding dialog thread. In one embodiment, the bidding dialog thread may have embedded transaction options for the user to choose from. A transaction channel may have been created when the bidding dialog was tagged by the user or other participants as a transactional thread. In one embodiment, the system may prompt the user 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.) may be prepopulated based on the bidding dialog among the participants in the bidding dialog thread and/or one or more bidding dialog threads. In one embodiment, the transactional information may be prepopulated based on details of historical transactions placed by the user. In one embodiment, the system may prompt the user 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.

[0153] Messaging 564 may be performed to send transactional information to the network 190 to consummate the transaction requested by the user of the client device 110. Once the transaction module 260 receives and processes the transaction information provided by the user, 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. In one embodiment, a single transaction may involve more than one transaction server and may involve more than one of messages similar to message 564.

[0154] Messaging 566 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 and is completed. In one embodiment, the third party transaction server 150 may be configured to send a confirmation code or a receipt number upon completion of the transaction. In one embodiment, more than one server may be involved in the transaction, and there may be more than one message such as message 566 indicating the transaction is or is not consummated. In one embodiment, the transaction module 260 may be configured to receive a transaction unsuccessful message through the network 190, and there may be one or more following messages between the transaction module 260, client device 110, and/or third party servers 150 (FIG. 1) to complete a successful transaction. In one embodiment, the transaction may not need a third party server, and the entirety of the transaction may be consummated within the communication server 102 (FIG. 1) without messages 564 and 566.

[0155] Messaging 568 may be performed to send a transaction complete report to the client device 110 in response to the transaction request of the user of the client device 110. In one embodiment, the transaction complete message 568 may also be communicated to the entity with which the user transacted. In some embodiments, this communication to the entity may be via the bidding module 245 or via the bidding dialog thread. Upon completion of a successful transaction, the transaction module 260 may have obtained a confirmation code or a receipt number of the completed transaction. The transaction module 260 may forward that information to the client device 110 for further reference for the user of the client device 110. The transaction module 260 may also send to the client device 110 a message confirming the additional information exchanged between the bidding dialog participants associated with the transaction, such as place to meet, delivery method, return or exchange policy information, customer service, information, promotional information, discounts, etc. Upon receiving the transaction complete message, the client device 110 may further prompt the user to set up an appointment or a reminder for the user based on the additional transaction information (e.g., delivery estimate date reminder, time and place to meet, promotion expiration date reminder, return or exchange expiration date reminder, etc.).

[0156] FIG. 5 is a flowchart for an exemplary method of searching tags and requesting a bidding dialog in accordance with one embodiment. The method shown in FIG. 5 may be implemented by the wireless communication system of FIGS. 2 A or 2B. Implementation of the method of FIG. 5 may involve one or more of the database 220, search module 250, the bidding module 245, and the transaction module 260 in the communication server 102 as described in connection with FIGS. 2, 4A, 4B, 4C, and 4D.

[0157] In some situations, a user may desire to have a service performed by a merchant or purchase an item from a merchant (i.e., the locksmith example discussed above). Accordingly, the user may perform a search on their client device, selecting tags associated with the service or item or merchant they are searching for. The search module 250 may then use the search parameters to effectuate a search of the database 220. The search module 250 may then compile a list of discovered merchants and users into a search result list, which it then transmits to the client device. The user may then select one or more of the merchants and users from the search result list to transmit a bidding dialog request to the bidding module 245. The bidding dialog may allow for the user to communicate with the selected merchants and users regarding the desired item or service. During the bidding dialog, the user may determine to initiate a transaction to purchase the desired item or service from one of the merchants and users after a bidding event or auction takes place in the bidding dialog. In the locksmith example discussed above, the user may receive on his client device a search result of merchants and users able to supply the door lock and installation services, and from that list may select one or more of the merchants and users to initiate a bidding dialog with one or more of the merchants and users and may then initiate a transaction for the item or service desired.

[0158] At block 570, the system may receive a search request from a client device 110. For example, the receiver 298 may receive the search request from the client device 110. The search request, in some embodiments, may comprise at least one keyword or tag for which the user wishes to search the database 220. In one embodiment, the search module 250, upon receipt of the search request, may be configured to process the search request which includes the search terms to facilitate an accurate search of the database 220. The processing of the search request may include identifying free text, tags, categories, geography, products, events, and/or proper names included in the received information. The processing may further include identification of the data sources for the search. After the search request is received, the method may continue to block 572. [0159] At block 572, the database 220 may be searched for the keyword or tag as requested by the user. In one embodiment, the search of the database 220 may be either a public or private database search. The search of the database 220 may be performed by the search module 250. After the public tag search is performed, the method may continue to block 574.

[0160] At block 574, the method may next compile a search result of the merchants and users found in the search of the database 220. In some embodiments, the search module 250 may compile the search result list. In other embodiments, the database 220 may compile the search result list. In some embodiments, the results may comprise private tags or public tags. After the search result list is completed, the method may continue to block 576.

[0161] At block 576, the method may transmit the search result list to the requesting client device 110. The transmission may be transmitted by transmitter 296 or transceiver 294. At block 578, the receiver 298 or transceiver 294 may receive a bidding dialog request from the client device 110. The bidding dialog request may comprise one or more merchants or users from the search result list with which the client device 110 requests to be able to communicate with via a bidding dialog. The bidding dialog may be a bidirectional communication platform between the client device and the selected merchants and users.

[0162] Additionally, at block 578, the bidding module 245 may receive the bidding dialog request received from the client device. The bidding dialog request may comprise various settings and a selection of the merchants and users from the search result with which the client device wishes to establish a bidding dialog. The bidding dialog request may be received by the receiver 298 or the transceiver 294

[0163] At block 580, the bidding module may use the elements of the bidding dialog request to generate a bidding dialog with the settings communicated in the bidding dialog request. The bidding dialog may be established between the client device 110 and the merchants and users selected. The bidding dialog generated by the bidding module may allow for the client device 110 to establish an auction or bidding event with multiple merchants and users from the search results to purchase an item or service. [0164] At block 582, after generating the bidding dialog as requested, the details of the bidding dialog may be transmitted to the client device and to the merchants so that the client device and the selected merchants may connect to and utilize the bidding dialog. As described above, the bidding dialog may be used to communicate details of the item or service desired by the client device and to participate in an auction or similar bidding event.

[0165] FIG. 6 is a flowchart for an exemplary method of searching the database in accordance with one embodiment. The method shown in FIG. 6 may be implemented in the search module 250 that is in communication with the database 220 in the communication server 102 as described in connection with FIGS. 2, 4A, 4B, 4C, and 4D.

[0166] In some situations, a user may desire to have a service performed by a merchant or purchase an item from a merchant (i.e., the locksmith example discussed above). Accordingly, the user may perform a search on their device, selecting tags associated with the service or item or merchant they are searching for. Additionally, in some embodiments, the user may select the area within which the search is performed (e.g., a specific city or zip code, etc.) or a distance from the user's location within which the search is to be performed. A non- limiting advantage of these options is the ability to allow the user to restrict the search based on convenience to the user (i.e., if the user needs an item or service immediately, the user may desire to restrict the search to within one mile of the user). Then, a search request that includes the search parameters selected by the user may be sent from the user device to the search module 250. The search module 250 may then use the search parameters to effectuate a search of the database 220. For the locksmith example, the search module 250 may search the database 220 for merchants or other users having tags identifying them as being locksmiths, having door locks available for sale, and/or having the ability to perform door lock installation. The search module 250 may then compile a list of discovered merchants and users into a search result list, which it then sends to the user device.

[0167] At block 602, a search request may be received. In one embodiment, the search module 250, upon receipt of the search request, may be configured to process the search request which includes the search terms to facilitate an accurate search. The processing of the search request may include identifying free text, tags, categories, geography, products, events, and/or proper names included in the received information. The processing may further include identification of the data sources for the search. After the search request is received, the process may continue to decision block 604.

[0168] At decision block 604, a determination is made as to whether the search request is a private search request or a public search request. If the search request is a public search request, the process continues to block 606. If the search request is a private search request, the process may continue to block 608.

[0169] At block 606, a public tag search may be performed. In one embodiment, the public index in the database 220 may be searched to perform the public tag search. After the public tag search is performed, the process may continue to block 608.

[0170] At block 608, a private tag search may be performed. In one embodiment, the private index in the database 220 may be searched to perform the private tag search. After the private tag search is performed, the process may continue to block 610.

[0171] At block 610, the search result set may be personalized. Personalization may include reordering the search result sets based on user-defined parameters. For example, the user may provide a data source preference list which identifies a ranking of results from each data source. In such an example, a result from a higher ranked data source may be listed more prominently (e.g., nearer to the first presentation position on the result list) than other results. In one embodiment, the search result may be reordered based on the prioritization derived from the user's general profile, for example ordered based on distance from the user, hours of the merchant user, merchant user ratings or reviews, or personal experience with the merchant user. After the search result is personalized, the process may continue to block 612.

[0172] At block 612, the search result set may be sent to the requester's device. After the search result set is sent to the requester's device, the process ends.

[0173] FIG. 7 is a flowchart for an exemplary method of creating a bidding dialog thread in accordance with one embodiment. The method shown in FIG. 7 may be implemented in the bidding module 245 as described in connection with FIGS. 2, 4 A, 4B, 4C, and 4D. In some embodiments, as will be described below, the method shown in FIG. 7 may be implemented in the conversation module 240 in the communication server 102 configured for bidding as described in connection with FIGS. 1, 2 A, and 2B. [0174] The bidding dialog creation method creates a communication platform through which a user may communicate with merchants, or vice versa. The method may generate the communication platform allowing selected users and merchants to communicate with each other. The user requesting that the bidding dialog be created may select various parameters that may restrict actions within the bidding dialog. Additionally, the bidding dialog may provide the platform for the price bidding to take place. The bidding dialog may allow for the searching party to restrict the bidding merchants from seeing each other's bids or may allow the bidding merchants to see the current bid but not be aware who made the bid. This may allow the bidding merchants to be confident that they are competing with another merchant as opposed to being tricked by a user who claims to have received a cheaper bid elsewhere. For example, in the locksmith example above, the user Peter may request a bidding dialog be created between himself and selected merchants from the search result, i.e., Sam and Larry. When requesting the bidding dialog be created, Peter may choose to allow either or both of Sam and Larry to invite other merchants to the bidding dialog or may restrict either or both of Sam and Larry from inviting others to the bidding dialog. Peter, Sam, and Larry may use the bidding dialog to discuss the door locks, prices, and any other related issues. The bidding dialog may also be used for the auction/bidding event, where Peter may request each of Sam and Larry to provide the lowest price they would accept for the door lock and installation service.

[0175] At block 702, a bidding dialog request may be received. The bidding dialog request may include a bidding dialog type (e.g., BCC, minimum bid increments, etc.) and one or more participants. In one embodiment, the bidding module 245 may receive additional bidding dialog restrictions from the user. Bidding dialog restrictions may identify one or more of: who (e.g., users, client devices, tagged users, demographic based) can receive the bidding dialog, what recipients can do within the bidding dialog (e.g., reply, forward, bid, exit and content types permitted to contribute), where the bidding dialog is accessible (e.g., location based conversations), and when the bidding dialog is accessible (e.g., time to live on the system, time to respond, time to send, time to bid). After the bidding dialog request is received, the process may continue to decision block 704. [0176] At decision block 704, a determination is made as to whether the requested bidding dialog involves blind carbon copy (BCC) as selected by the user. The BCC option may be chosen by the user when the user wishes to send the same bidding dialog messages to multiple entities without the entities discovering what other entities have received the same bidding dialog messages. In some embodiments, one or more of the other entities may be aware of the existence and/or the quantity of other entities participating in the bidding dialog but not know their identities. In some other embodiments, one or more of the other entities may be aware of the existence, quantity, and/or identities of other entities participating in the bidding dialog, but may not be aware of what entity may be associated with a particular dialog or bid. If the BCC option is selected, the process may continue to block 706. If the BCC option is not selected, the process may continue to block 708.

[0177] At block 706, viewing the recipients of other recipients of the bidding dialog thread may be restricted in response to the selection of the BCC option by the user. After the viewing of the recipients is restricted, the process may continue to decision block 708.

[0178] At decision block 708, a determination is made as to whether the requested bidding dialog is in an anonymous mode as chosen by the user. The anonymous mode may allow the user to establish a bidding thread with one or more entities or other users while maintaining complete anonymity from each of the entities or other users. In some embodiments, the user may be able to select to stay anonymous from a subset of the entities or other users involved in the bidding dialog. If the requested bidding dialog is in the anonymous mode, the process may continue to block 710. If the requested bidding dialog is not in the anonymous mode, the process may continue to decision block 712.

[0179] At block 710, the recipients of the bidding dialog thread in the anonymous mode are restricted from seeing the identifying information of the user who requested the bidding dialog thread. After the user's identity is anonymized or otherwise restricted, the process may continue to decision block 712.

[0180] At decision block 712, a determination is made as to whether the requested bidding dialog is in a locked mode. The locked mode may allow the user to establish a locked bidding dialog thread with the recipients. In the locked mode, the system may restrict or prevent recipients from adding any more participants to the bidding dialog. If the requested bidding dialog is in the locked mode, the process may continue to block 714. If the requested bidding dialog is not in the locked mode, the process may continue to block 716.

[0181] At block 714, the recipients of the bidding dialog thread in the locked mode are restricted from adding new participants. After adding new participants is restricted, the process may continue to block 716.

[0182] At block 716, a bidding dialog thread reflecting one or more bidding dialog restrictions, if any, is created. The bidding dialog thread may or may not have one or more restrictions described above, for example a time limit for the auction/bidding, maximum or minimum prices, time to delivery of item or completion of service, and other terms (e.g., increment of price change allowed, maximum number of complaints allowed, etc.). After the bidding dialog thread reflecting the user's choices is created, the process ends.

[0183] FIG. 8 is a flowchart for an exemplary method of pausing and unpausing a bidding dialog thread created in FIG. 7 by bidding module 245 in accordance with one embodiment. The method shown in FIG. 8 may be implemented in the bidding module 245 in communication with the database 220 in FIGS. 2 A or 2B. The method shown in FIG. 8 may be implemented in the conversation module 240 in communication with one of the database 220 in FIGS. 2 A or 2B or the bidding module 245.

[0184] The pausing and unpausing method may be used by a user or merchant to temporarily pause the bidding dialog. When paused, users and merchants involved in the bidding dialog may be unable to communicate with each other or may be unable to bid on the item or service. In some embodiments, the user or merchant who pauses the bidding dialog may be the only one who can unpause the bidding dialog. In other embodiments, the pause may expire after a pre-determined or user-selectable time period. In alternate embodiments, any user or merchant may unpause a paused bidding dialog. The controls for who may pause or unpause a bidding dialog may be selected by the bidding dialog requestor when requesting the bidding dialog be created. A merchant may request to pause the bidding dialog to assist a patron that may be requesting the merchant's assistance or a searching party may request to pause the bidding dialog to deal with another matter more important than the item or service request. For example, in the locksmith example above, if Peter pauses the bidding dialog, Sam and Larry may be unable to bid against each other until the bidding dialog is unpaused. Similarly, if Sam or Larry pauses the bidding dialog, Peter will be unable to communicate with the other merchant until the merchant who paused the dialog returns (assuming an embodiment where only the party who paused the bidding dialog may unpause the bidding dialog).

[0185] At block 802, a bidding dialog thread is created and a bidding dialog between a user and one or more entities may begin. As a bidding dialog thread participant may send a bidding dialog thread item, the process may continue to block 803.

[0186] At block 803, a bidding dialog thread item may be received. In one embodiment, the system may not allow one or more bidding dialog participants to send a bidding dialog thread item for a paused bidding dialog, and the bidding dialog thread item may not be received if the bidding dialog is paused. The bidding dialog thread item may be received for later transmission regardless of whether the bidding dialog is paused as depicted in the method of FIG. 8. As a bidding dialog thread participant may send a pause request in the first embodiment, the process may continue to decision block 804. In some embodiments, only the user who initiated the bidding dialog may sent a pause request or an unpause request. In some other embodiments, any user or entity participating in the bidding dialog may send a pause or unpause request. In alternate embodiments, only the user and selected entities participating in the bidding dialog may send pause or unpause requests.

[0187] At decision block 804, a determination is made as to whether a pause request was received. The pause request may include an identifier for the bidding dialog thread to be paused. If a pause request is not received, the process may continue to block 810. If a pause request is received, the process may continue to block 806.

[0188] At block 806, the received bidding dialog thread may be paused. In one embodiment, a bidding dialog thread may be publically paused upon the bidding dialog thread creator's request. In one embodiment, a bidding dialog thread may be only privately paused upon any non-creator bidding dialog participant's request. The bidding dialog may be publicly paused by any bidding dialog participant's request. In one embodiment, the bidding dialog thread may be configured by the thread creator to allow or disallow pausing by one or more of the bidding dialog participants. After the bidding dialog thread is paused, the process may continue to decision block 808.

[0189] At decision block 808, a determination is made as to whether an unpause request was received. The unpause request may include an identifier for the bidding dialog thread. If an unpause request is received, the process may continue to block 810. If an unpause request is not received, the process may continue to decision block 812.

[0190] At block 810, a bidding dialog thread item may be received. When there is no pause request, a bidding dialog thread item may be received. For a paused bidding dialog thread, upon receipt of an unpause request, the bidding dialog thread item of interest may be received. In one embodiment, a bidding dialog publicly paused may be publicly resumed. In one embodiment, a bidding dialog privately pause may be privately resumed as long as the bidding dialog is not publicly paused. After the bidding dialog thread item is received, the process may continue to decision block 804 to determine receipt of a subsequent pause request.

[0191] At decision block 812, a determination is made as to whether the bidding dialog has ended. If the bidding dialog has not ended, the process may continue to decision block 808 to determine if an unpause request is made. If the bidding dialog has ended, the method shown in FIG. 8 ends. A bidding dialog may be determined to have ended when the user is the only participant in the bidding dialog. In some embodiments, the determination of whether the bidding dialog has ended may be based on a minimum number of participants established by the user or the bidding module 245.

[0192] FIG. 9 is a functional block diagram of an exemplary communications network system 900 in accordance with another embodiment. As illustrated in FIG. 9, the first user, Client A, may generate public user specified tags 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 902 and to a database 912 of a communications cloud 910. The database 912 also may have automatic, system-generated tags 914 based on demographic information from social media, geolocation, and social graphs that the communications cloud 910 may gather from the network 902. Thus, the system 900 shown in FIG. 9 illustrates examples of the various sources for tags as well as the use of tags to facilitate providing a bidirectionally directed searchable information such as bids or auctions.

[0193] FIG. 10 is a functional block diagram of searching with the exemplary communications network system 900 in accordance with another embodiment. The communications cloud 910 may also comprise a search index module 916, database 912, social graph module 918, and qualitative statistics module 920 that may operate in conjunction with a search module (not shown) 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 910 may communicate with users such as Client B in FIG. 10 through the network 902. Client B in this example may request a search based on one or more phrases or other search attributes. The communications cloud 910 may perform the requested search through the search module and transmit real time results to Client B through the network 902. The tag information underlying the searches may be continually updated, such as was discussed with reference to FIG. 9. FIG. 10 illustrates how the information received from Client B about himself (self tags) and about others (user to user tags) facilitates bidirectionally directed searches as the basis for the searches submitted by Client B consider both the self tags and user-to-user tags.

[0194] FIG. 11 is an exemplary user interface for creating a bidding dialog thread in accordance with one embodiment. In one embodiment, the user may create a bidding dialog thread with entities returned in the search result. The user may select any number of entities to include in the bidding dialog. In this exemplary user interface, the user is creating a bidding dialog thread with "Dean Kosage" and "Personally, Inc." In some embodiments, the user interface may include fields to include the item or service being bid on, a price range within which the user wishes to stay within, and/or a time by or within which the user wishes to complete the bidding process or complete the entire transaction. In one embodiment, the bidding dialog thread may have options to lock the conversation thread or BCC recipients, or turn on an anonymous mode as described in detail in connection with FIGS. 4B, 4D, and 8. In this example, the user has selected to lock the bidding dialog thread to limit adding new participants and turned on BCC to limit the recipients' viewing of other recipients of the same message. However, the user has not chosen to remain anonymous from the recipient entities. [0195] FIG. 12A is a flowchart for an exemplary, real-time method of obtaining ratings from users in accordance with one embodiment. The rating method may allow users who have consummated a transaction to rate the merchant or user with whom they consummated the transaction. In some embodiments, the rating created by the user may include details describing the experience of working with the other party, for example describing the quality of the item or services provided or the accuracy of the bid price agreed upon compared to a final price charged after the service was performed or item was received. Additionally, users that are looking to begin an communication or transaction with a merchant or user may review the ratings left by previous users and, in some implementations, may communicate with a user who rated the merchant in real-time to verify information in the rating or to request additional information and/or thoughts of the merchant or of specific details of the current user's desired transaction.

[0196] After consummating and completing the transaction and, in some implementations, once the item has been delivered or the service has been performed, the users involved may rate each other, the items or services provide, or the transaction as a whole. The user creating the rating may choose to provide a numerical or other indicator representing the overall grade or rating of the transaction. For example, a user may provide a general rating of a number of stars or letter grade, etc. Additionally, a user may be able to provide details or descriptions of the transaction or the item or service, for example details explaining the quality of the service or item or the other party. Additionally, a user leaving a rating may choose to provide his contact information so that a later user may request additional information or contact the user providing the rating. In the locksmith example provided above, if Sam and Peter perform a transaction, both Sam and Peter may be given the opportunity to leave a rating for each other. Sam, as the merchant user, may provide details regarding how Peter was, as a client, to deal with or whether there were any issues when Sam provided his item or service to Peter, for example if Peter tried to demand more items or services than had been agreed to or if Peter was difficult to work with (e.g., changed agreed upon times, etc.). Additionally, Sam may select to remain available for future users to contact regarding his rating and experience with Peter. For example, Larry may later be interested in providing a service or item to Peter, but may want to ensure that Peter is trustworthy and easy to work with or may want to ask Sam if Sam thinks that a particular transaction is a good deal or a worthwhile exchange. Similarly, Peter may leave his own rating of Sam, rating his impression of the interaction and which may include his thoughts of the transaction, the quality of the item or service, or the interaction with Sam when receiving the item or service. Additionally, similar to as discussed above for Sam, Peter may also choose to be available for future potential clients of Sam to contact Peter and ask about specifics of the transaction or ask if Peter believes a certain transaction is a worthwhile exchange.

[0197] The method 1200 shown in FIG. 12A may be implemented in a client device and a rating module 265 in communication with the database 220 in FIGS. 2 A or 2B. The review information is stored in the database 220. In some implementations, the review information as received by the rating module 265 is stored. In some implementations, the rating module 265 may be configured to process the received review information prior to storage. Examples of processing of the review information include encrypting, anonymizing, augmenting (e.g., adding demographic information of the reviewer), aggregating (e.g., combining several reviews into an average or total review), and the like. The method 1200 shown in FIG. 12A may alternatively be implemented in at least one of the conversation module 240 in communication with one of the database 220 and the rating module 265 in FIGS. 2 A or 2B or the transaction module 260 in communication with the database 220 and the rating module 265 in FIGS. 2 A or 2B.

[0198] The rating method 1200 may be used by a user or merchant to rate the transaction and opposing party in the transaction after the transaction has been completed and consummated. The rating module 265 may also allow users to view previous ratings by specific users about other users.

[0199] At block 1202, the user may complete a transaction. In some embodiments, the user may also complete a conversation or a bidding dialog with another user that does not result in a transaction. At block 1204, the user may receive a request to complete a rating of the other user(s) of the transaction (or conversation or bidding dialog). In some embodiments, the user may volunteer to leave a request of another user after the transaction is completed. At block 1206, the user may provide information regarding the rating of the other user(s). This information may comprise, for example, how easy the other user was to deal with, how friendly the other user was, whether the other user upheld the original terms of the transaction, etc. At block 1208, the rating may be stored in memory. This memory may be the database 220 discussed above or may be memory internal to the rating module 265 or may be memory at another location.

[0200] FIG. 12B illustrates a process flow diagram for an exemplary method of communicating with a reviewer. The method 1250 shown in FIG. 12B may be implemented in a communication server device and a rating module 265 in communication with the database 220 in FIGS. 2 A or 2B. The method 1200 shown in FIG. 12A may alternatively be implemented in at least one of the conversation module 240 in communication with one of the database 220 and the rating module 265 in FIGS. 2 A or 2B or the transaction module 260 in communication with the database 220 and the rating module 265 in FIGS. 2 A or 2B.

[0201] At block 1210, a user may perform a search for an item or service, as discussed above. The search may be performed using the search module 250. The search, as described above, may comprise the client device 110 sending a message to the search module 250, which may then search the database 220 for users being associated with specific tags or keywords. At block 1212, the search module 250 may return search results found in the database 220. The search results may comprise one or more merchants or users being associated with the searched for tags. The search results may also comprise indications that ratings exist or the ratings themselves for each of the one or more merchants or users returned in the search results. If the search results only provide indications of the existence of ratings, then the client device 110 may request the ratings from the database 220 or another memory storage device (not shown in this figure). In some implementations, the request may be placed with the communication server 102 which is configured to provide the results. The client device 110 may then review the ratings such as via a graphical interface. At block 1214, a user of the client device 110 may review the ratings of the merchants or users of the search results. During the review, the client device 110 may receive a request for communications with one or more users who left ratings of the one or more merchants of the search results. The request may include receiving a review identifier associated with the review of interest.

[0202] At decision block 1215, a determination is made as to whether the reviewer allows communications. In some implementations, the determination may be based on the review details initially submitted and discussed above. For example, one reviewer may provide comments on merchant, and also include a value indicating no communications about the review. In some implementations, the communication permissions may be based on relationships between users. For example, if the requesting user is associated with a particular tag (e.g., "Hillsdale College Alum"), the reviewer will accept communication requests.

[0203] If the determination at block 1215 is negative, at block 1220 a message is provided indicating that communication cannot be initiated with the requested user. In some implementations, the ability to initiate communication may be provided with each rating. For example, a "contact reviewer" icon may appear next to reviews written by reviewer with whom communication may be initiated. From block 1220, the method 1250 ends.

[0204] Returning to decision block 1215, if the determination is affirmative, at block 1216, that the merchant or user who left the rating decided that he would allow future users to contact him, then the client device 110 may initiate communicate directly with the user who left the rating. In some embodiments, as discussed above, this communication may comprise a message asking the user if a specific deal or exchange is worthwhile. The communication may be a threaded communication as described above. At block 1218, the client device 110 may generate and send a communication directly to the reviewing user via the communication module. The method 1250 then ends but may be repeated for a subsequent search.

[0205] FIG. 13 is an exemplary message diagram for obtaining and verifying ratings through a rating module in accordance with one embodiment. A user using the client device 110 submits a search request 1302 to the server search module 250b. The search request 1302 may include keywords, tags, unique identifiers, or other search terms. The search terms may be provided via a search entry box graphical user interface element displayed via the client device 110. As a result, the server search module 250b is configured to provide a search result response 1304 which provides a listing (filtered by preference) of items that match the user's search query. The user, finding one item of interest from the list provided by the server search module 250b, selects one item/user to get review/rating information about that specific item/user. In an effort to obtain review information, the client device 110, sends a review rating request 1306 to the server rating module 265B. The review rating request 1306 may include an identifier for the review of interest. The identifier may be absolute (e.g., uniquely identifying the rating of interest within the system) or relative (e.g., identifying the rating of interest within the search results response).

[0206] The server rating module 117 may be configured to provide a response including all rating information available for the specific item/user selected by the user by means of a review rating response 1308. The rating information may be obtained from the database (not shown) via the identifier provided in the review rating request. The user then is given the opportunity to read and review the reviews left by previous system user. He may find at least one reviewer that allows for communication and decide to contact that reviewer to get more information from him or her about their experience with the item or user.

[0207] The client device 110 may be configured to initiates a request to communicate with the user 1310 which is sent to the server conversation module 240bB. The system automatically generates a conversation thread 1312 between the user and the reviewer selected by the user.

[0208] FIG. 14 is a process flow diagram illustrating an exemplary method of bidding via a conversation thread. The method 1400 may be performed in whole or in part by one or more of the devices shown in FIGS. 1, 2 A, or 2B.

[0209] The method 1400 begins at block 1410 where a search request is initiated from a client device. The search request may include at least one search criteria. The search criteria may include a keyword, a tag, or a geolocation or other location information. At block 1420, a search response is received from a communication server. The search response may include a user or an item fitting the provided search criteria. In some implementations, the search response may include users or items that match the criteria exactly. In some implementations, the search response may include so-called "fuzzy" searching whereby words having the same stem or similar phonetics may be included. At block 1430, at least one user or item of interest is selected from the search response. The selection may include receiving an indicator for the search result item of interest via a graphical user interface. At block 1440 a threaded conversation including a bidding request is initiated with the identified user or item of interest. The bidding request may include, for example, a description of a service to be performed (e.g., "change 5 external door locks" or "clogged toilet") or an item of interest (e.g., "Spiderman #347" or "69 el camino carburetor"). The threaded conversation may also include privacy settings, such as blind bidding (e.g., recipients do not see each other's bids) or method of responding (e.g., can bidders contact the user via email, phone, threaded conversation, or some combination). At block 1450, the at least one bid response is received from the at least one user or item of interest. At block 1460, the user may utilize the client device to optionally select a favorable bid from the received bid responses. Assuming a bid response is selected, optionally, at block 1470, the transaction is completed based on the information in the bid response. Completing the transaction may include processing payment information to transfer funds from the initiator to the selected bidder, transferring a digital asset between the parties, or providing a proof of purchase (e.g., voucher, QR code, barcode, one time use token, etc.) redeemable for the negotiated item or service.

[0210] Because tags may be used to quickly find merchants or items within the system, it may be desirable to control how tags may be applied and discovered. For example, in some implementations, executing a search and receiving search results may be permitted for all users. Similarly, tagging your contacts (e.g., local tagging) is freely permitted. In each case, the optimization caused by the tagging is either provide externally (e.g., search results from the communication server) or for private use (e.g., local tagging). In some implementations, tagging of a person (e.g., public tagging) may be free or based upon satisfaction of certain conditions. Whether a tag is free or based upon satisfaction of certain conditions is determined by the communication server. For example, certain tags may be associated with licensed professionals such as attorneys. Thus, for the tag "lawyer" or "attorney" a condition may be attached before a user may apply the tag publically. For example, it may be desirable to confirm that a user tagging himself as an attorney has a valid license to practice law. In some implementations, it may be desirable to allow tagging upon payment of a fee determined by the system. Merchants or users may utilize free (public tags) or fee-based (public tags) in order to be discovered by other users of the system. The conditions may be dynamically assessed based on time, date, location, or other factors of the tagged user and/or the searching user.

[0211] 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.

[0212] 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.

[0213] 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, 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.

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

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

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

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

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

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

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

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

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

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

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

[0225] The terms "processor" and "processor module," as used herein are a broad terms, and are to be given their ordinary and customary meaning to a person of ordinary skill in the art (and are not to be limited to a special or customized meaning), and refer without limitation to a computer system, state machine, processor, or the like designed to perform arithmetic or logic operations using logic circuitry that responds to and processes the basic instructions that drive a computer. In some embodiments, the terms can include ROM and/or RAM associated therewith.

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

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

[0228] As used herein, the term "message" encompasses a wide variety of formats for transmitting information. A message may include a machine readable aggregation of information such as an XML document, fixed field message, comma separated message, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed/transmitted/stored/received/etc. in multiple parts.

[0229] Any reference to an element herein using a designation such as "first," "second," and so forth does not generally limit the quantity or order of those elements. Rather, these designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise a set of elements may include one or more elements.

[0230] Conditional language used herein, such as, among others, "can," "could," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.

[0231] The term "or" as used herein is intended to mean an inclusive "or" rather than an exclusive "or." Unless specified otherwise, or clear from the context, the phrase "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, the phrase "X employs A or B" is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from the context to be directed to a singular form.

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

Claims

WHAT IS CLAIMED IS:

1. An apparatus for communicating, comprising:

a database of merchant users and corresponding tags and keywords;

a transceiver configured to transmit messages to one or more client devices of a wireless system and receive message from the one or more client devices of the wireless system; and

a processing unit operably connected to the memory unit and the transceiver and configured to:

initiate a search of the database for a merchant user via a search module based on at least one of a user selected tag and a user input keyword received from a requesting client device;

receive, via the transceiver, at least one search result comprising at least one merchant user of the wireless system;

transmit, via the transceiver, the at least one search result to the requesting client device;

receive, via the transceiver, a bidding dialog request from the requesting client device, the bidding dialog request comprising at least one user preference for a bidding dialog and at least one merchant user selected from the at least one search result;

initiate the bidding dialog via a bidding module with the at least one merchant user, the bidding dialog comprising:

a bidirectional dialog between the requesting client device and the at least one merchant user; and

a bidding event, the bidding event comprising each merchant user of the at least one merchant user providing a bid price on an item or service desired by the requesting client device; and

complete a transaction via a transaction module for the item or service in exchange for a final bid price.

2. The apparatus of claim 1, wherein the transceiver comprises a transmitter configured to transmit messages to one or more client devices of a wireless system separate from a receiver configured to receive message from the one or more client devices of the wireless system

3. An apparatus for communicating, comprising:

a receiver configured to receive a search request from a client device, the search request comprising at least one keyword or tag to be searched;

a database configured to store at least one user and at least one keyword or tag corresponding to each user;

a search module operably coupled to the receiver and the database and configured to:

search the database for the at least one keyword or tag of the search request; and

compile a search result, the search result comprising at least one user corresponding to the at least one keyword or tag of the search request;

a transmitter operably coupled to the search module, configured to transmit the search result to the client device; and

a bidding dialog module, operably coupled to the receiver and the transmitter, configured to generate a bidding dialog in response to a bidding dialog request received by the receiver from the client device, the bidding dialog comprising a bidirectional communication platform between the client device and at least one user from the at least one user of the search result.

4. The apparatus of Claim 3, further comprising a transaction module configured to:

perform a transaction in response to a transaction request received by the receiver, the transaction request comprising an item or a service from the client device to be exchanged for another item or another service from the selected at least one user, and a method of exchanging the items or services; and provide a confirmation of a completed transaction to the client device and the selected at least one user.

5. The apparatus of Claim 1, wherein the processor is further configured to present the at least one search result to the client device in a filtered manner, wherein the client device selects to filter the at least one search result based in part on at least one of a rating of the merchant user, the distance between the client device and the merchant user, a maximum price, a minimum price, an available of the item or service, and the hours of operation of the merchant user.

6. A method for communicating, comprising:

receiving a search request from a client device, the search request comprising at least one keyword or tag;

searching a database of users and associated tags or keywords for the at least one keyword or tag;

compiling a search result, the search result comprising at least one user corresponding to the at least one keyword or tag of the search request;

transmitting the search result to the client device;

receiving a bidding dialog request from the client device, the bidding dialog request comprising at least one user of the search result; and

generating a bidding dialog, the bidding dialog comprising a bidirectional communication platform between the user and the at least one user of the search result.

7. The method of Claim 5, further comprising:

receiving a transaction request, the transaction request comprising an item or a service to be exchanged for another item or another service and a method of exchanging the items or services;

performing the requested transaction; and

providing a confirmation of a completed transaction to the client device.