Abstract:
Embodiments for presenting real-time contact options are described generally herein. The system receives information from a first user about an offered item via a web page and communication preferences for use with a real-time contact option to be presented on the web page, whereby the communication preferences including a first-user-defined real-time contact option presentation condition. The system selectively presents to a second user the information about the offered item and the real-time contact option based on a determination that the first-user-defined real-time contact option presentation condition is satisfied. The system enables the second user to select the real-time contact option. In response to the second user selecting the real-time contact option, the system communicates to the first user a real-time contact request and information identifying the second user.

Description:
PRIORITY 
       [0001]    This application is a continuation of and claims the benefit of priority to U.S. patent application Ser. No. 11/508,091, entitled “SELECTIVE PRESENTATION OF REAL-TIME CONTACT OPTIONS BASED ON USER AND SYSTEM PARAMETERS,” filed on Aug. 22, 2006, which is hereby incorporated by reference herein in its entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    Various embodiments described herein relate generally to publication server systems (ES), including apparatus, systems, and methods used in product or service sales publication servers. 
       BACKGROUND INFORMATION 
       [0003]    A publication server may act as an interface between one or more sellers offering goods or services for purchase or bid. A seller may provide product or service information, pricing information, and contact information to a publication server via a seller interface. The publication server may generate an electronic representation of the sellers&#39; product or service offering where a buyer may be able to view the representations via an electronic interface. 
         [0004]    In order to expedite sales or inspire conference in a seller&#39;s product or service, a publication server may enable a potential buyer to request additional information about a seller&#39;s representation or listing via the buyer interface. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]      FIG. 1  is a block diagram of product or service publication server architecture according to various embodiments. 
           [0006]      FIG. 2  is a diagram of communication between a buyer device, publication device, and seller device in a product or service publication server architecture according to various embodiments. 
           [0007]      FIG. 3  is a block diagram of product or service publication server according to various embodiments. 
           [0008]      FIG. 4  is a flow diagram illustrating several methods according to various embodiments. 
           [0009]      FIG. 5  is a flow diagram illustrating several methods according to various embodiments. 
           [0010]      FIG. 6  is a flow diagram illustrating several methods according to various embodiments. 
           [0011]      FIG. 7  is a flow diagram illustrating several methods according to various embodiments. 
           [0012]      FIG. 8  is a block diagram of an article according to various embodiments. 
           [0013]      FIG. 9  is a block diagram of an article according to various embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]      FIG. 1  is a block diagram of a product or service publication server architecture  10  comprising a buyer device (BD)  42 , publication device (PD)  22 , and seller device (SD)  32 , according to various embodiments. The buyer device  42  may be coupled to the publication device  22  via a network  14  where the network may be a local wired or wireless network or a network of networks such as the Internet. The seller device  32  may also be coupled to the publication device  22  via the network  14  where the network may be a local wired or wireless network or a network of networks such as the Internet. The seller device  32  may be part of the publication device  22  where the publisher is also the seller. 
         [0015]    The publication device  22  includes a server  24  where the server  24  may be configured to communicate messages between the buyer device  42  and the publication device  22 . The server  24  may also be configured to communicate messages between the publication device  22  and the seller device  32 . The seller device  32  may have an interface  34  that may be configured to communicate messages between the publication device  22  and itself. In an embodiment, a buyer device  42  may have an interface  44  that may be configured to communicate messages between the publication device  22  and itself. The interfaces  34  and  44  may each include a hyper-text markup language (HTML) converter such as a browser and the server  24  may communicate messages between the publication device  22  and buyer device  42  and seller device  32  via one or more web pages. 
         [0016]    The architecture  10  may include a voice communication provider (VCP)  52  that is coupled to the network  14 . The voice communication provider  52  may include a Voice over Internet Protocol (VoIP) server  54 . The publication device  22  may enable the voice communication provider  52  to establish voice communication between the buyer device  42  and seller device  32 . The voice communication provider  52  may establish VoIP communication between the seller device  32  and buyer device  42 . The interface  44  or interface  34  may be able to establish VoIP sessions via a browser, a thin client, or a VoIP application specific program (ASP). The publication device  22  server  24  may include a VoIP server. 
         [0017]    The publication device  22  may establish VoIP communication between a seller device  32  and buyer device  42  by providing peer-to-peer connection information for both devices  32 ,  42 . The seller device  32  and buyer device  42  may form a peer-to-peer connection that enables voice or other real-time communication between the devices  32 ,  42 . The seller device  32  and buyer device  42  may act as effective client and servers in peer-to-peer connections and may be responsible for terminating such sessions via peer-to-peer software or protocols. The seller device  32  and buyer device  42  may host a communication client to support peer-to-peer connections and an access client for browser based communication. 
         [0018]    The architecture  10  may also include plain-old-telephone-system (POTS)  12  coupled to the voice communication provider  52 . In an embodiment a seller may have one or more phones  36  coupled to the POTS  12  (including cellular phones). The seller device  32  may specify one or more phone numbers associated with the seller phone(s)  36  where publication device  22  initiated voice communication may be to be directed. In an embodiment a buyer may have one or more phones  46  coupled to the POTS  12  (including cellular phones). The buyer device  42  may specify one or more phone numbers associated with the buyer phone(s)  46  where publication device  22  initiated voice communication may to be directed. The publication device  22  may employ the voice communication provider  52  to establish communication between any combination of a buyer device  42 , a seller device  32 , a seller phone  36 , and buyer phone  46 . 
         [0019]    The buyer device  42  may be any computer device capable of providing an interface  44  including a computer, personal data assistant, or web enabled cellular phone. The buyer device  42  may be able to establish VOW sessions including peer-to-peer sessions via a client or receive calls via a telephone number. The seller device  32  may be any computer device capable of providing an interface  34  including a computer, personal data assistant, or web enabled cellular phone. The buyer device  42  may be able to establish VIP sessions or receive calls via a telephone number. 
         [0020]      FIG. 2  is a diagram of communications  40  between a publication device  22  and a buyer device  42  and between the publication device  32  and a seller device  32  according to various embodiments. In an embodiment, a seller may have products or services for sale or bid. The seller via a seller device  32  may engage a publication device  22  to generate an electronic catalog or listing(s) of the sellers&#39; products or services for sale or bid. A buyer via a buyer device  42  may view the electronic catalog or listing(s) and purchase, offer to purchase, or bid on one or more products or services shown in the electronic catalog or listing(s). In an embodiment a seller via a seller device  32  may register or setup an account or services with the publication device  22 . A seller via a seller device  32  may generate a seller general setup request  62 . In an embodiment a seller may employ the interface  34  to generate the request  62  via a web page provided by the publication device  22  server  24 . 
         [0021]    In response to the seller general setup request  62 , the publication device  22  may generate a seller general setup page  64  and provide it to the seller device  32  as an HTML document, may for example. The setup page  64  may enable a seller to set numerous preferences, account information, and contact information. In an embodiment, the preferences may include the ability of a buyer or potential buyer to contact the seller via real-time communication. The real-time communication preferences may include the seller&#39;s availability schedule (based on the seller&#39;s time zone), the seller&#39;s spoken and written languages, seller&#39;s desire to have an interpreter participate in a voice or text call for certain other languages, one or more contact numbers or VoIP identifiers to be used according to a schedule or product or service. The real-time communication preferences may also include a list of buyers (by identifier or other unique reference) that are excluded or permitted to communicate with the seller via voice communication, required related product or service sale status including requirements that a buyer has offered to buy, purchased, bid, or placed a bid meeting a predetermined minimum or reserve, or has a certain buyer history or rating as established by the publication device  22  server  24 . 
         [0022]    The seller device  32  may forward the seller general setup reply  66  to the publication device  22  server  24 . In an embodiment, the publication device  22  may store the seller information and preferences in one or more databases. A potential buyer or buyer via a buyer device  42  may generate a buyer general setup request  92 . A buyer or potential buyer may employ the interface  44  to generate the request  92  via a web page provided by the publication device  22  server  24 . A buyer device  42  may be able to communicate with the publication device  22  without registration or unique identification. In another embodiment, a buyer via a buyer device  42  may have the option of registering or providing a unique identifier when communicating with the publication device  22 . 
         [0023]    In response to the buyer general setup request  92 , the publication device  22  may generate a buyer general setup page  94  and provide it to the buyer device  42  as an HTML document. The buyer general setup page  94  may enable a potential buyer to set numerous preferences, account information, and contact information. The preferences may include real-time communication preferences. In an embodiment, buyer real-time communication preferences may include the buyer&#39;s availability schedule (for receipt of seller&#39;s communication requests to the buyer), the buyer&#39;s spoken or written languages, buyer&#39;s desire to have an interpreter participate in a voice or text calls for certain other languages, one or more contact numbers or VoIP identifiers to be used according to a schedule or product or service. The real-time communication preferences may also include a list of sellers (by identifier or other unique reference) that are excluded or permitted to communicate with the buyer via voice communication, required related product or service sale status including whether the buyer has offered to buy, purchased, bid, or placed a bid meeting a predetermined minimum or reserve, and the seller&#39;s history or rating as established by the publication device  22  server  24 . 
         [0024]    The buyer device  42  may forward the buyer general setup reply  96  to the publication device  22  server  24 . In an embodiment, the publication device  22  may store the buyer information and preferences in one or more databases. A seller via a seller device  32  may create a catalog or listing of one or more products or services offerings (items in an embodiment) by generating a sell item request  72 . In an embodiment a seller may select an option to generate a sell item request  72  via a seller device  32  from a web page generated by the publication device  22 . A seller may receive a sell item page  74  from the publication device  22  server  24  and populate the page via the seller device  32  interface  34 . The seller may be able to specify item information including description, reserve, multimedia (including pictures, or videos), links to other information or multimedia, and buyer real-time contact preferences for the particular listing. 
         [0025]    Upon completion of the sell item page  74 , a seller via the seller device  32  interface  34  may forward the completed page  74  via a sell item page reply  76 . A buyer via a buyer device  42  interface  44  may generate a view item request  102 . The buyer via a buyer device  42  interface  44  may perform a search for items (e.g., products or services offered) using a number of criteria including item description, multimedia matching, item geographical location, particular seller, ability to potentially contact seller via real-time communication with questions about an item, or pricing. The view item request  102  may be generated by a buyer selecting an item located in a search in an embodiment. The publication device  22  server  24  may generate a view item page  104  for the view item request  102  and forward the view item page  104  to the buyer via the buyer device  42  interface  44 . The publication device  22  server  24  may retrieve information about the requested item from one or more databases when compiling a view item page  104 . The view item page  104  may include a real-time contact icon (or some other user-selectable indicia) that a buyer may select via the buyer device  42  interface  44  to contact a seller via a real-time communication method, apparatus, or protocol including via voice, instant message, or other instant contact method or apparatus. 
         [0026]    The publication device  22  may apply general rules, seller preferences, and buyer preferences to determine what, if any, contact icons may be included on the view item page  104  where the general rules, seller preferences, and buyer preferences may be stored in one or more databases accessible by the server  24 . The publication device  22  server  24  may apply general rules for buyer-seller real-time communications including the number of real-time communications sessions conducted or attempted by a buyer or seller in a predetermined time period via the publication device  22 , geographical attributes of the buyer or seller, the number of buyers already shown a contact icon for the seller and likelihood of one or more such buyers to attempt to contact the seller via the real-time contact icon, or unique identification of buyer (e.g., buyer logged into the publication device  22  server  24  in an embodiment). 
         [0027]    A buyer receiving a view item page  104  with a seller real-time contact option (SRO) may select the real-time contact option icon and generate an item real-time contact request  112 . The publication device  22  server  24  upon detecting the real-time contact option icon selection or receipt of the item real-time contact request may generate a real-time contact request page  82  for the seller device  32 . The seller real-time contact request  82  may include an icon (or some other user-selectable indicia) for accepting the buyer real-time contact request. The page  82  may include a unique buyer identifier, information about the item(s) shown on the view item page  104  including description, item sales status in general and particular to the buyer, past interactions with the buyer including sales, contacts, or buyer language(s). The item sales status may include the number of items in inventory, number of orders in predetermined time frame, offers, offers exceeding preset reserve, buyer&#39;s current offer for item (if any). 
         [0028]    In an embodiment, a seller via a seller device  32  interface  34  may accept a real-time communication request  82  by selecting an acceptance icon on a web page presenting the real-time communication request  82 , The seller via a seller device  32  interface  34  may decline a real-time communication request  82  by selecting a declination icon on a web page presenting the real-time communication request  82 . If a seller accepts or declines the request  82 , the seller device  32  interface  34  may generate a real-time contact reply  84 . The publication device  22  server  24  upon receipt of the real-time contact reply  84  (e.g., selection of the acceptance or declination icon on a web page in an embodiment) may generate an item real-time contact reply  114  and forward the reply  114  to a buyer device  42  interface  44 . The publication device  22  may generate a declination reply if a seller via a seller device  32  interface  34  does not respond within a predetermined time period. The publication device  22  server may store the real-time communication requests and responses in one or more databases. 
         [0029]    When a seller via a seller device  32  interface  34  accepts a real-time communication request  82 , the publication device  22  server  24  may initiate or request initiation of the requested real-time communication. In an embodiment, when the real-time communication request is a voice communication request, the publication device  22  server  24  may forward contact information for the buyer and seller to a voice communication provider  52 . The voice communication provider  22  may attempt to initiate the requested communication based on the received contact information. In an embodiment, the voice communication provider server  54  may create a VoIP session between one of a buyer device  42  and buyer phone  46  and one of a seller device  32  and seller phone  36 . The voice communication provider  52  may forward voice communication to a POTS  12  for communication with a buyer phone  46  or seller phone  36 . The provider  52  may provide connection information to the seller device  32  and buyer device  42  that enables communication clients in each device  32 ,  42  to establish peer-to-peer voice communication. The voice communication provider  52  server  54  may be a VoIP provider such as Skype™ or may employ a VoIP provider such as Skype™ to form VoIP sessions. The seller device  32  and buyer device  42  may employ Skype™ clients to enable peer-to-peer voice communication based on connection information provided by the publication device  22  or VCP  54 . 
         [0030]    The publication device  22  server  24  may determine contact information for the buyer and seller based on their communication preferences, including VoIP unique identifiers or telephone number(s) for the buyer and seller for voice communication sessions. The publication device  22  server  24  may provide the buyer&#39;s and seller&#39;s VoIP unique identifiers (for peer-to-peer sessions in an embodiment) or telephone number(s) to the voice communication provider  52  for voice communication requests. A buyer or seller may be able to end a communication session via a buyer device  42  interface  44 , a buyer phone  46 , a seller device  32  interface  34 , or a seller phone  36 . The publication device  22  server  24  may limit communication sessions to a predetermined time period. 
         [0031]    In an embodiment, the publication device  22  server  24  may include a number of modules such as shown in  FIG. 3  including a buyer general setup module  122 , general contact module  124 , view item module  126 , seller general setup module  128 , buyer contact module  132 , seller—sell item module  134 , seller contact module  136 , and seller—revise item module  138 . In an embodiment, the buyer general setup module  122 . may enable a buyer via a buyer device  42  interface  44  to configure or modify general buyer information including buyer contact information including voice contact information. The module  122  may process buyer general setup requests  92  and replies  96  and generate buyer general setup pages  94 . In an embodiment, the seller general setup module  128  may enable a seller via a seller device  32  interface  34  to configure or modify general seller information including seller contact information including voice contact information. The module  128  may process seller general setup requests  62  and replies  66  and generate seller general setup pages  64 . 
         [0032]    The general contact module  124  may enable an agent or agent administrator to configure or modify general contact rules including voice session rules related to buyers and sellers. In an embodiment, the view item module  126  may enable a buyer via a buyer device  42  interface  44  to view requested item information including potential real-time seller contact options. The view item module  126  may process view item requests  102  and generate view item pages  104 . The seller-sell item module  134  may enable a seller via a seller device  32  interface  34  to configure information for items for sale or bid including potential real-time seller contact options. The seller-sell item module  134  may process sell item requests  72  and replies  76  and generate sell item pages  74 . 
         [0033]    In an embodiment, the seller revise item module  138  may enable a seller via a seller device  32  interface  34  to revise or modify item information including real-time seller contact options. The buyer contact module  132  may enable a buyer via a buyer device  42  interface  44  to request or end real-time communication with a seller. The buyer contact module  132  may process item real-time contact requests  112  and generate item real-time replies  114 . In an embodiment, the seller contact module  136  may enable a seller via a seller device  32  interface  34  to reply to real-time communication requests or end real-time communication with a buyer. The seller contact module  136  may process item real-time contact replies  82  and generate item real-time requests  84 . 
         [0034]      FIG. 4  is a flow diagram of a seller real-time-contact option activation method  150  according to various embodiments. The method  150  may apply general contact rules to determine whether any general rule is flagged or may be violated by presenting a real-time contact option on a view item page requested by a buyer via a buyer device  42  interface  44  (activity  152 ). When a general rule is flagged (due to the item requested, buyer (if known), or seller), a real-time contact option may not be presented on a view item page in an embodiment (activity  154 ). In an embodiment, the method  150  may apply seller contact rules to determine whether any seller rule is flagged or may be violated by presenting a real-time contact option on a view item page requested by a buyer via a buyer device  42  interface  44  (activity  156 ). 
         [0035]    When a seller rule is flagged (due to the item requested, or buyer (if known real-time contact option on a view item page may not be displayed in an embodiment (activity  158 ). In an embodiment, when the general contact rules and the seller contact rules have been cleared (e.g., no flags) set or rule potentially violated by possible presentation of a seller real-time contact option), the method  150  may enable real-time contact option presentation on a buyer view item page (VIP) (activity  162 ). A view item page may present a seller real-time-contact option for different real-time communication methods, apparatus, or protocols including voice, instant message, or other instant contact method, apparatus, or protocol. The method  150  may be employed to separately determine whether to present a real-time-contact option for each seller real-time-contact option where each option may have different general rules or seller rules. 
         [0036]      FIG. 5  is a flow diagram of a general contact rule evaluation method  190  according to various embodiments. In the general contact rule evaluation method  190 , a number of general contact rules may be evaluated to determine whether a real-time contact option should be presented to a buyer. In an embodiment, the method  190  may determine whether a buyer (to possibly be shown a seller real-time contact option) is currently logged into the publication device  22  via the buyer device  42 . In an embodiment a buyer may remain logged into a publication device  22  via buyer device  42  for a predetermined time interval. In another embodiment, the publication device  22  may determine whether a unique buyer is known based on the buyer device  32  coupled to the publication device  22  (such as via a cookie in some Internet browser applications). In an embodiment, when a buyer is not logged into the publication device  22  or cannot be uniquely identified (activity  192 ), the method  190  may set a general contact rule flag (activity  202 ). 
         [0037]    In an embodiment, the method  190  may determine whether the buyer to possibly be shown a real-time contact option has exceeded a predetermined number of real-time contacts (activity  194 ) in a predetermined time interval. The predetermined number may vary as a function the real-time contact type, e.g., voice or instant message. The predetermined time interval may also be based on a calendar day, week, month, year, or some other predetermined time interval. In an embodiment, when a buyer has exceeded a predetermined number of real-time contacts within a predetermined time interval (activity  194 ), the method  190  may set a general contact rule flag (activity  202 ). 
         [0038]    In an embodiment, the method  190  may determine whether any geographical or demographical issues may exist between the buyer and seller. The publication device  22  may employ a number of servers  24  where the servers  24  are geographical based such as for different countries or continents. The method  190  may limit potential voice sessions to buyers and sellers on the same server, within the same country or continent. In an embodiment, the method  190  may determine whether the item to be viewed by a buyer has potential export issues (to the buyer country or from the seller country). If export issues potentially exist, geographical issues exist, or demographical issues exist, the method  190  may set a general contact rule flag (activity  202 ). 
         [0039]    In an embodiment, the method  190  may determine the number of buyer devices  42  actively viewing an item page that includes a real-time contact option icon (activity  198 ). When the buyer device active real-time contact option icon count number exceeds a predetermined limit including a maximum system limit, a seller limit, and a specific item limit, the method  190  may set a general contact rule flag (activity  202 ). The publication device  22  may employ a database or queue to monitor each real-time contact option currently shown on an item page. The method  190  may accumulate totals for the system (publication device  22 ), specific seller(s), or specific items. The method  190  may then determine whether to present an real-time contact option for a specific item based on the accumulated totals, The predetermined real-time contact option limit may be set as a function of past system activity, seller activity, item activity, probably of buyer(s) selecting a shown real-time contact option icon, and other related statistics. 
         [0040]      FIG. 6  is a flow diagram of a seller contact rule evaluation method  210  according to various embodiments. In the seller contact rule evaluation method  210 , a number of seller specific contact rules may be evaluated to determine whether a seller real-time contact option (seller real-time contact option) should be presented to a buyer. In an embodiment, a seller via a seller device  32  may set a number of real-time contact option rules via a seller general setup page  64  ( FIG. 2 ). A seller may select or deselect real-time contact option rules and set associated parameters via the general setup page  64 . A seller via a seller device  32  interface  34  may select or deselect item specific real-time contact option rules and set associated parameters via a sell item page  74 . 
         [0041]    In an embodiment, the method  210  may determine whether item specific requirements or rules (if any) have been met or satisfied (activity  212 ). When an item specific requirement or rule has not been met, the method  210  may set a seller contact rule flag (activity  222 ). The item specific rules may include the item sales status or item sales value. The method  210  may determine whether the buyer associated with the buyer device  42  has been flagged by the seller via the seller device  32  (activity  214 ). When a buyer associated with the buyer device  42  has been flagged by a seller via the seller device  32 , the method  210  may set a seller contact rule flag (activity  222 ). A seller via the seller general setup page  64  may create a list of buyers that are permitted or not permitted to have real-time contact with the seller. The buyer exclude/include real-time contact option list may be maintained by the publication device  22  server  24 . 
         [0042]    The method  210  may determine whether buyer specific requirements or rules (if any) have been met or satisfied (activity  216 ). When a buyer specific requirement or rule has not been met, the method  210  may set a seller contact rule flag (activity  222 ). The buyer specific requirements or rules may include a certain level of buyer experience with one of a publication device  22  and the seller associated with the item page being requested. In an embodiment, the method  210  may determine whether the requested item page is to be shown within a seller&#39;s predefined real-time-contact schedule (activity  218 ). When the requested item page is to be shown outside the associated seller predefined real-time-contact schedule, the method  210  may set a seller contact rule flag (activity  222 ). In an embodiment, a seller may set a general real-time contact schedule or a real-time contact schedule specific to the item to be shown on the view item page. 
         [0043]      FIG. 7  is a flow diagram of a buyer item real-time contact request method  170  according to various embodiments. In an embodiment, when a buyer via a buyer device  42  interface  44  selects a real-time contact option on an item page (activity  172 ), the method  170  may determine whether the seller device  32  interface  34  is active (seller online) (activity  174 ). In an embodiment, when the method  170  determines a seller is not online, the method  170  may determine whether the seller is accepting the requested real-time contact option offline (activity  176 ). The seller via a seller general setup page  64  or sell item page  74  (or revise item page), may specify one or more rules for various real-time-contact options. In an embodiment, when the requested real-time contact option is for voice contact, a seller may specify one or more telephone numbers to used to establish voice communication when the seller is offline or online. 
         [0044]    When the seller has specified an offline setup for the selected seller real-time contact option, the method  170  may enable the selected real-time contact option via the seller specified setup (activity  186 ). The seller via a seller device  32  may specify message options when the seller is offline or does not answer or accept a seller real-time contact option. When the seller has not specified an offline setup for the selected real-time contact option or has elected not to accept the selected real-time contact option offline, the method  170  may give the buyer (via the buyer device  32  or buyer device telephone  36 ) a message option (activity  188 ) specified by a seller for such an real-time contact option request. 
         [0045]    When the seller is online (seller device  32  interface  34  is active), the method  170  may generate a real-time contact request page (RRP)  82  (activity  178 ). In an embodiment, the real-time contact request page  82  may include information about the buyer and item associated with the selected contact option. The buyer information may include a unique buyer identifier, history of past contact attempts by the buyer, history of past sales between the buyer and seller, buyer bid or purchase status for the related item, and buyer general sales history/rating/creditability. The item information may include the item bid or sales status, unique item identifier, item description, and item multimedia (including pictures or video). The method  170  may forward the buyer information page (in the RRP  82  in an embodiment) to the seller&#39;s seller device  32  interface  34  (activity  184 ). 
         [0046]    In an embodiment, when the seller via a seller device  32  accepts the requested seller real-time contact option, the method  170  may enable the requested real-time contact option (activities  184 ,  186 ). The method  170  may engage the publication device  22  server  24  or a voice communication provider  52  to enable or request enablement of the requested and accepted seller real-time contact option. In an embodiment, when the seller via a seller device  32  does not accept the requested seller real-time contact option, the method  170  may give the buyer (via the buyer device  32  or buyer device telephone  36 ) a message option specified by a seller for such an real-time contact option request (activities  184 ,  188 ). 
         [0047]    A device  260  is shown in  FIG. 8  that may be used in various embodiments as a buyer device  42  or seller device  32 . The device  60  may include a central processing unit (CPU)  262 , a random access memory (RAM)  264 , a read only memory (ROM″)  266 , a display  268 , a user input device  272 , a transceiver application specific integrated circuit (ASIC)  274 , a microphone  288 , a speaker  282 , and an antenna  284 . The CPU  262  may include a VoIP client  294  and a publication device  22  message interpreter  292 . The RAM  264  may include a queue  278  where the queue  278  may store publication device  22  messages. The interpreter  292  and the VoIP client  294  may be separate elements. The VoIP client  294  may enable VoIP sessions between a VoIP server and itself, or between another VoIP client and itself. The interpreter  292  may process messages or pages from and generate messages or pages for the publication device  22  server  24 . 
         [0048]    The ROM  266  is coupled to the CPU  262 . and may store the program instructions to be executed by the CPU  262 , VoIP client  294 , and interpreter  292 . The RAM  264  is coupled to the CPU  262  and may store temporary program data, overhead information, and the queues  278 . The user input device  272  may comprise an input device such as a keypad, touch pad screen, track ball or other similar input device that allows the user to navigate through menus in order to operate the device  260 . The display  268  may be an output device such as a CRT, LCD or other similar screen display that enables the user to read, view, or hear received messages or pages from the publication device  22  server  24 . 
         [0049]    The microphone  288  and speaker  282  may be incorporated into the device  260 . The microphone  288  and speaker  282  may also be separated from the device  260 . Received data may be transmitted to the CPU  262  via a serial bus  276  where the data may include messages or pages received, messages or pages to be transmitted, or protocol information. The transceiver ASIC  274  may include an instruction set necessary to communicate messages or pages in architecture  10 . The ASIC  274  may be coupled to the antenna  284  to communicate wireless messages or pages within the architecture  10 . When a message is received by the transceiver ASIC  274 , its corresponding data may he transferred to the CPU  262  via the serial bus  276 . The data can include wireless protocol, overhead information, and pages to be processed by the device  260  in accordance with the methods described herein. 
         [0050]      FIG. 9  illustrates a block diagram of a device  230  that may be employed as a publication device  22  in various embodiments. The device  230  may include a CPU  232 , a RAM  234 , a ROM  236 , a storage unit  238 , a modem/transceiver  244 , and an antenna  246 . The CPU  232  may include a VoIP server  254  and a server  252 . The RAM  234  may include a queue or database  248  where the queue  248  may be used to store buyer or seller information including general information, contact configuration, sales history, and item information. The storage  238  may also include a queue or database  256  where the queue  256  may be used to store may be used to store buyer or seller information including general information, contact configuration, sales history, and item information. The VoIP server  254  and the server  252  may be separate elements. 
         [0051]    In an embodiment, the VoIP server  254  may initiate and maintain VoIP sessions between a buyer device  42  or a buyer telephone  46  and a seller device  32  or a seller telephone  36 . In an embodiment, the VoIP server  254  may be maintained and operated a third party VoIP provider including Skype™. In an embodiment, the server  252  may be a publication server  24  including the modules shown in  FIG. 3 . 
         [0052]    The modem/transceiver  244  may couple, in a well-known manner, the device  230  to the network  14  or POTS to enable communication with the seller device  32 , buyer device  42 , and voice communication provider  52 . In an embodiment, the modem/transceiver  244  may be a wireless modem or other communication device that may enable communication with the seller device  32 , buyer device  42 , or voice communication provider  52 . The CPU  232  via the server  252  may direct communication between modem  244  and the seller device  32 , buyer device  42 , or voice communication provider  52 . 
         [0053]    The ROM  236  may store program instructions to be executed by the CPU  232 , VOW server  254 , or server  252 . The RAM  234  may be used to store temporary program information, queues, databases, and overhead information. The storage device  238  may comprise any convenient form of data storage and may be used to store temporary program information, queues, databases, and overhead information. 
         [0054]    Any of the components previously described can be implemented in a number of ways, including embodiments in software. Any of the components previously described can be implemented in a number of ways, including embodiments in software. Thus, the CPU  232 , VoIP server  254 , server  252 , modem/transceiver  2444 , antenna  246 , storage  238 , RAM  234 , ROM  236 , queue  248 , queue  256 , CPU  262 , interpreter  292 , VoIP client  294 , transceiver ASIC  274 , antenna  284 , microphone  288 , speaker  282 , ROM  266 , RAM  264 , queue  278 , user input  272 , display  268 , publication device  22 , seller device  32 , buyer device  42 , and voice communication provider  52  may all be characterized as “modules” herein. 
         [0055]    The modules may include hardware circuitry, single or multi-processor circuits, memory circuits, software program modules and objects, firmware, and combinations thereof, as desired by the architect of the architecture  10  and as appropriate for particular implementations of various embodiments. 
         [0056]    The apparatus and systems of various embodiments may be useful in applications other than a sales architecture configuration. They are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. 
         [0057]    Applications that may include the novel apparatus and systems of various embodiments include electronic circuitry used in high-speed computers, communication and signal processing circuitry, modems, single or multi-processor modules, single or multiple embedded processors, data switches, and application-specific modules, including multilayer, multi-chip modules. Such apparatus and systems may further be included as sub-components within a variety of electronic systems, such as televisions, cellular telephones, personal computers (e.g., laptop computers, desktop computers, handheld computers, tablet computers, etc.), workstations, radios, video players, audio players (e.g., mp3 players), vehicles, medical devices (e.g., heart monitor, blood pressure monitor, etc.) and others. Some embodiments may include a number of methods. 
         [0058]    It may be possible to execute the activities described herein in an order other than the order described. Various activities described with respect to the methods identified herein can be executed in repetitive, serial, or parallel fashion. 
         [0059]    A software program may be launched from a computer-readable medium in a computer-based system to execute functions defined in the software program. Various programming languages may be employed to create software programs designed to implement and perform the methods disclosed herein. The programs may be structured in an object-orientated format using an object-oriented language such as Java or C++. Alternatively, the programs may be structured in a procedure-orientated format using a procedural language, such as assembly or C. The software components may communicate using a number of mechanisms well known to those skilled in the art, such as application program interfaces or inter-process communication techniques, including remote procedure calls. The teachings of various embodiments are not limited to any particular programming language or environment. 
         [0060]    The accompanying drawings that form a part hereof show, by way of illustration and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. 
         [0061]    Such embodiments of the inventive subject matter may be referred to herein individually or collectively by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept, if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description. 
         [0062]    The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In the foregoing Detailed Description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted to require more features than are expressly recited in each claim. Rather, inventive subject matter may be found in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.