Patent Publication Number: US-10764361-B2

Title: Distributed server architecture session count system and methods

Description:
TECHNICAL FIELD 
     Various embodiments described herein relate to monitoring sessions hosted by multiple servers. 
     BACKGROUND INFORMATION 
     It may be desirable to monitor the number of sessions hosted by servers in a distributed server architecture including counting the number of calls hosted by geographically distributed servers. The present invention provides devices for same. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1A  is a simplified diagram of a session server architecture according to various embodiments. 
         FIG. 1B  is a simplified diagram of a distributed session server architecture according to various embodiments. 
         FIG. 1C  is a simplified diagram of another distributed session server architecture according to various embodiments. 
         FIG. 2A  is a diagram of communication between a session device, a session processing system, and a session monitoring system in a distributed session server architecture according to various embodiments. 
         FIG. 2B  is another diagram of communication between a session device, a session processing system, and a session monitoring system in a distributed session server architecture according to various embodiments. 
         FIG. 3  is a flow diagram illustrating several methods according to various embodiments. 
         FIG. 4  is a flow diagram illustrating several methods according to various embodiments. 
         FIG. 5A  is a block diagram of an article according to various embodiments. 
         FIG. 5B  is a block diagram of another article according to various embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     An electronic session provider including a software session provider, voice over internet protocol (VOIP) provider, or application service provider (ASP) may provide sessions to or enable sessions between user devices (session capable devices  30 A- 30 I— FIG. 1C ). The sessions may be real time sessions including real time media sessions. The media may include multimedia, where the multimedia may include images, video, or sound. 
     A session provider may employ a communication architecture including a session server/system architecture  10 A-C as shown in  FIG. 1A-1C  that includes one or more session processing systems or servers  20 A- 20 D. The session processing systems  20 A- 20 D may provide requested sessions or communicate session data between systems  20 A- 20 D. In order to support user session devices  30 A-I that are large in number or geographically separated, an architecture  10 C may include multiple session processing systems or servers  20 A- 20 D and form part of a distributed communication architecture. The session processing systems or servers  20 A- 20 D may also be geographically separated based on user session device  30 A-I deployments or density. A user session device  30 A-I may be any session capable device. 
     In such embodiments, it may be desirable to monitor, track, count, or compile sessions conducted, requested, or joined by a user session device  30 A-I via session processing systems  20 A- 20 D. Monitoring sessions may enable, confirm, or determine presence status of user session device(s)  30 A-I such as during various communication activities. Monitoring sessions may enable license control of users associated with session devices  30 A-I including the number of active sessions. Monitoring sessions may enable or determine capacity limit and load balancing of session processing systems  20 A-D employed in an architecture  10 C where sessions may be distributed to various systems  20 A-D as a function of capacity limits and desired load balancing. 
     Monitoring sessions may also enable or determine automatic call distribution via session processing systems  20 A-D employed in architecture  10 A- 10 C where sessions may represent calls including VOIP calls. Monitoring sessions may enable or determine fraud detection present in sessions provided by session processing systems  20 A-D employed in architecture  10 A- 10 C. In a basic session server architecture shown in  FIG. 1A , a user may have a single user session device  30 A coupled to a single node or session processing system  20 A. Another user may also have a single user session device  30 C coupled to the same node or session processing system  20 A. In such an embodiment, session events created or hosted by the session processing system  20 A may be determined by monitoring only transactions conducted by the session processing system  20 A. In an embodiment, the session processing system  20 A may be process VOIP communications and function as a Back to Back User Agent (B2B UA). 
       FIG. 1B  is a simplified diagram of a distributed session server architecture  10 B according to various embodiments. As shown in  FIG. 1B , architecture  10 B may include a 1 st  plurality of user session devices  30 A- 30 B, a 2 nd  plurality of user session devices  30 C- 30 D, a user session device  30 I, and session processing systems  20 A,  20 B, and  20 C. Session devices  30 A-B may communicate with the session processing system  20 A and user session devices  30 C-D may communicate with the session processing system  20 C. The session processing system  20 B may bridge communication between session processing systems  20 A and  20 C in an embodiment. In order to achieve desired session monitoring, it may be desirable to count or monitor communications between the user session devices  30 A-B and  30 C-D but not between the session processing system  20 B and the session processing systems  20 A and  20 C. It is noted that other user session devices  30 I may also communicate with the session processing systems  20 B. 
       FIG. 1C  is a simplified diagram of another distributed session server architecture  10 C according to various embodiments. As shown in  FIG. 1C , architecture  10 C may include a plurality of user session devices  30 A- 30 B,  30 C- 30 D, and  30 E- 30 F, and user session devices  30 G- 30 I, cloud interfaces  40 A- 40 D, session processing systems  20 A- 20 D, and a session monitoring system  50 . The plurality of session devices  30 A-B may communicate with the session processing system  20 A via a first cloud interface  40 A. The plurality of user session devices  30 C-D may communicate with the session processing system  20 B via a second cloud interface  40 B. The session processing system  20 A may be coupled directed or indirectly with session processing system  20 B via other session processing systems or cloud interfaces. Clouds or cloud interfaces  40 A-D may represent local networks or a network of networks termed the “Internet” in an embodiment. 
     User session devices  30 G and  30 H may communicate with another session processing system  20 C. The session processing system  20 C by coupled directly or indirectly to other session processing systems  20 A and  20 D. User session device  30 I may communicate with a session processing system  20 D. The plurality of user session devices  30 E-F may communicate with the session processing system  20 D via cloud interface  40 D. The session processing system  20 D may be coupled directly or indirectly to another session processing systems  20 C. The user session devices  30 A- 30 I may be any device capable of communicating with a session processing system  20 A- 20 D via session communication protocols/channels. For example, a user session device  30 A- 30 I may support VOIP communication protocols and communicate with a session processing system  20 A- 20 D via wired or wireless protocols/channels. A user session device  30 A- 30 I may include a VOIP enabled device, VOIP modem, cellular device, personal data device, laptop, desktop, tablet, or other device including a modulator/demodulator (modem), network interface, or processor capable of communicating and supporting a session protocol/channels as provided, hosted, or communicated by one or more session processing system(s)  20 A- 20 D. 
     Similar to architecture  10 B, it may be desirable to count or monitor communications between the user session devices  30 A-I and session processing systems  20 A-D but not communications between the session processing systems  20 A-D. In an embodiment, session processing systems  20 A-D may track, compile, report, or otherwise monitor sessions between a user session device  30 A-I and a or their session processing system  20 A-D. The session processing systems  20 A-D may also track, compile, report, or otherwise monitor sessions between session processing system  20 A-D that are invoked by a user session device  30 A-I. In a further embodiment, the session processing systems  20 A-D may only track, compile, report, or otherwise monitor sessions between user session devices  30 A-I and a or their session processing system  20 A-D. 
     In an embodiment, an architecture  10 C may include one or more session monitoring system  50  to track, compile, report, or otherwise monitor sessions between user session devices  30 A-I and a session processing system  20 A-D. The session monitoring system  50  may also track, compile, report, or otherwise monitor sessions between session processing system  20 A-D that are invoked by a user session device  30 A-I. In a further embodiment, the session monitoring system  50  may only track, compile, report, or otherwise monitor sessions between user session devices  30 A-I and a session processing system  20 A-D. In an embodiment, a session monitoring system  50  may be coupled directly or indirectly to one or more session processing systems  20 A-D and receive session information directly or indirectly from one or more session processing systems  20 A-D via other channels. The channels may be specialized, monitoring channels that a session monitoring system  50  may monitor. A session processing system  20 A- 20 D may forward session information from other session processing systems  20 A-D to a session monitoring system  50 . In a further embodiment, one or more session processing systems  20 A-D may work in tandem with one or more session monitoring systems  50  to monitor sessions conducted in any manner by one or more user session devices  30 A-I. 
     As shown in  FIGS. 1A-C , an architecture  10 A-C may include multiple user session devices  30 A-I. A user or client may own multiple user session devices  30 A-I and may conduct multiple sessions simultaneously, such as in a call center. A single user may also conduct multiple sessions in an architecture including multiple VOIP sessions (one live call via a user session device  30 A-I and other user session devices  30 A-I providing voicemail). In some session types, determining the number of active sessions may be complex. For example, a VOIP session may include multiple callers or callees such as a conference bridge that accept calls and initiates outbound calls. Further, the callers or callees present/active in a VOIP session may change including due to blind transfers. As a function of the active user session devices  30 A-I, the session processing system(s)  20 A-D handling one or more communication streams for a VOIP session may also change during a VOIP session. As noted, the session processing systems  20 A-D may be geographically separated to support and balance user session devices  30 A-I present at various geographical locations. 
     As noted, it may be desirable to track sessions including VOIP sessions including to provide presence logic as required for VOIP protocol. VOIP or other sessions may be tracked to ensure license terms or capacity constraints based on such licenses are enforced. In addition, VOIP or other sessions may be tracked to balance or distribute sessions across session processing systems  20 A-D in architecture  10 C to optimize session processing and access for user session devices  30 A-I. Further, VOIP or other sessions may be tracked to enable call features including forward on busy, call accounting, fraud detection, statistics and telemetry, and limit call distributions based on user session devices  30 A-I where a user session device or devices may be employed in call centers. 
     In an embodiment, any of the session processing systems  20 A-D may process VOIP sessions by functioning as a Session Initiation Protocol (SIP) agent including a SIP Back-to-Back User Agent (B2BUA) where each B2BUA may maintain two (2) SIP Transactions, each towards an individual endpoint (between two user session devices  30 A- 30 I). As noted and shown in architecture  10 A,  FIG. 1A , a session processing system  20 A may function as a single node where there is one user agent (UA) toward the Caller (via the user session device  30 A) and one UA toward the Callee (via the session device  30 C) in a VOIP session according to SIP. As shown in architectures  10 B and  10 C,  FIG. 1B  and  FIG. 1C , a VOIP session may involve multiple nodes (or session processing systems  20 A-D). In such an embodiment, a session device  30 A-I functioning as a Caller and Callee may communicate with several nodes (session processing systems  20 A-D) including a difference node between endpoint nodes where one UA at each node has a direct SIP transaction with one physical endpoint. 
     During various states, a session processing system  20 A-D may function as a transit only node where both UAs (user agent client and user agent server) include a SIP transaction to a node not directly to either the Caller or Callee (session device  30 A-I). In order to monitor desired sessions or session events, an embodiment may employ the algorithm  80  shown in  FIG. 3 . As shown in  FIG. 3 , in an embodiment one or more events may be determined or selected to be monitored (activity  82 ), where events to be monitored may be limited and predeteremined based on the requirements of underlying architecture. The algorithm  80  may request or direct session processing systems  20 A-D to publish certain limited, predetermined or selected session or session events to one or more session monitoring systems  50  or other particular session processing systems  20 A- 20 D (activity  84 ). The algorithm  80  may employ session counting logic to determine or deduce relevant session or session events of interest based on the desired monitoring activity or actions (activity  86 ) via one or more session monitoring systems  50  or other particular session processing systems  20 A- 20 D. 
     In a VOIP, SIP protocol supported architecture, such an analysis may include requesting or directing session processing systems  20 A-D to publish particular session or session events that signal the Creation, Update or Delete of a Session and its associated Objects, such as associated User and Role, such as Caller and Callee. In an embodiment during a VOIP session using SIP, the session or session events may be published via specialized monitoring channels of a Service Bus (SBUS) to a session monitoring system  50  or particular session processing system  20 A- 20 D according to various embodiments. 
     In an embodiment employing SIP protocol(s) only the session processing systems  20 A-D that generate endpoint session events may be directed to communicate activity via a SBUS to a session monitoring system  50 . In an embodiment a session monitoring system  50  may also be a session processing system  20 A-D. In such an embodiment employing SIP protocol(s) session processing systems  20 A-D acting as transit nodes may not be directed to communicate activity via a SBUS to a session monitoring system  50 . In events employing SIP protocol(s), desired session events may be associated with UA(s) that maintains direct SIP transaction with endpoints (session processing system(s)  20 A-D including acting as a user agent client (UAC) or user agent server (UAS)). A UAC may send SIP requests and a UAS may receive the requests and return a SIP protocol response. 
     In an embodiment, a UA (UAC or UAS) that maintains a direct SIP transaction with an endpoint (session processing system  20 A-D) maybe unique per call or session. In an embodiment, there is only one such unique transaction for the Caller, one for the Callee, and no unique transactions are created in any transit UAs or nodes. In an embodiment, a VOIP event may include “create”, “update”, and “delete” event. In an embodiment, a create event may be generated when a call is initially associated with a specific user (user session device  30 A-I). An update event may be generated when some information associated with the call relevant to a specific user via a session device  30 A-I has changed and periodically as a “heartbeat”. A delete event may be generated when a call stop is associated with a specific user (or user session device  30 A-I). 
     In an embodiment, each node of a session event (session processing system  20 A-D) has a Hostname and a Session ID unique to the generating node (session processing system  20 A-D) associated with the call. While the node&#39;s Session ID is not globally unique, the combination of the nodes call Session ID and nodes Hostname may be globally unique. The combination of session ID and Hostname may be communicated along with session events to a session monitoring system  50 . Other session data may include the user&#39;s Role including Caller, Callee, By, Owner of the Caller Device, and Owner of the Callee Device. In an embodiment, the “By” role may represent a 3rd Party User that initiated the Call, including a User that created a call by a Transfer and now substituted by the current Callee. The Owner of the Caller Device may be provided when the Caller is not the Owner of the Device (session device  30 A-I). The Owner of the Callee Device may be provided when the Callee is not the Owner of the Device. For example, the Owner of the Callee may be provided in an embodiment when a call is dispatched from a Call Center Queue or when the User that owns/controls a Call Queue is not the owner of the device used by the Call Center Agent. 
     Session event data may also include an Origination Call ID, a Termination Call ID, an Origination URL, and a Termination URL. In an embodiment the Origination Call ID may be the SIP&#39;s Call identifier (ID) in an incoming INVITE that originated a call. The Termination Call ID may be the SIP&#39;s CALL ID in an outgoing INVITE towards a Callee. The Origination URL may be the SIP&#39;s From-URL in an incoming INVITE that originated a call. The Termination URL may be the SIP&#39;s To-URI in an outgoing INVITE towards a Callee. 
       FIG. 2A  is a diagram of communication  60  between a session device  30 A, a session processing system  20 A, and a session monitoring system  50  in a distributed session server architecture  10 C according to various embodiments.  FIG. 2B  is another diagram of communication  70  between a session device  30 A, a session processing system  20 A, and a session monitoring system  50  in a distributed session server architecture  10 C according to various embodiments. As shown in  FIG. 2A  and  FIG. 2B , a session monitoring system  50  including a server  52  may request a session processing system  20 A including a server  22 A to provide certain session event data  62 A,  72 A. The session processing system  20 A may create a local session object upon receipt. 
     In communications  60 , a User via a session device  30 A including an interface  32 A may request a session including a VOIP session  66 A. A session processing system  20 A may communicate session data  64 A as requested and forward/publish session events to the session monitoring system  50  including a send session start data  64 B via a SBUS channel in an embodiment. Upon a User request to change a session  66 B, a session processing system  20 A may send session change data  64 C to a session monitoring system  50  via a SBUS channel in an embodiment. In communications  70 , a user session device  30 A may receive a session request communication  74 A. Once a User via a session device  30 A accepts (may be automatic process) a session request  76 A, the session processing system  20 A may send a session update message including a session start data communication  74 C to a session monitoring system  50  via a SBUS channel in an embodiment. Similar to communication  60 , upon a User request to change a session  76 B, a session processing system  20 A may send a session change data communication  74 D to a session monitoring system  50 . 
     In an embodiment, session processing systems  20 A-D may be directed to publish selected events to a session monitoring system  50  via one or more channel(s) of a service bus (SBUS). In order to enable a session processing system  20 A-D, a SBUS Proxy may be implemented in each session processing system  20 A-D to enable the system to generate/publish events to the SBUS. In an embodiment, an SBUS Proxy at each session processing system  20 A-D may be made aware of any peer nodes by a “Cluster Manifest” which may declare any Peer Nodes by the URL to the SBUS Proxy at each peer node (other session processing system  20 A-D in an architecture  10 A-C). Further, the URL of each SBUS Proxy may be defined with a Fully Qualified Domain Name (F QDN) corresponding to a validated SSL Certificate for security. In addition, SBUS Proxies may communicate with each other via Hypertext Transfer Protocol over a Secure Sockets Layer (HTTPS) for both privacy and authentication by associated SSL Certificates. 
     In an embodiment SBUS channels may provide granularity of SBUS Events into subsets where each subset may be sent through its own SBUS Channel. It is noted that each Service or Application that desires to receive SBUS Events must declare their URL with their local SBUS Proxy, acting as a trusted entity to permit such declaration. A physical declaration file may be written in a directory owned by a local SBUS Proxy to form declarations and then be qualified to have physical control of SBUS Proxy&#39;s file system. In an embodiment, each declaration may specify only one SBUS Channel per Service. The URL of each SBUS Service may be defined via a FQDN corresponding to a validated SSL Certificate. SBUS Events may be delivered to the URLs for the declared Services over HTTPS. Session processing systems  20 A-D may distribute events to all declared Service within the SBUS Channel. In an embodiment, a session processing system  20 A-D may declare each service to be delivered as either persistent or non-persistent, where persistent delivery retries until positive acknowledgement is received while non-persistent does not require acknowledgement. 
     In another embodiment, a session processing system  20 A-D may employ a send method to communicate events to a session monitoring system  50 . In such a method, a session processing system  20 A-D may send selected events to the first available Service within an SBUS Channel designated for the event. A SBUS Proxy may retry all declared Services within Channels, in a randomized order, until either a positive acknowledgement, or the all declared Service had been tried. 
     In order to monitor events using the SBUS protocol, a session monitoring system  50  may receive Session Events by making a declaration of its listener&#39;s URL in the “Session Events” SBUS Channel. In an embodiment, a session monitoring system  50  may employ the “non-persistent” push service. Once session processing system  20 A-D (node) receives a create session event from a UA (other node, session device  30 A- 30 I), it may employ the algorithm  90  shown in  FIG. 4 . As shown in  FIG. 4 , once a create session event request (activity  92 ) is received by a session processing system  20 A-D (node), a session processing system  20 A-D or session monitoring system  50  may create a local session object to monitor desired events (activity  94 ). The Session Object may be uniquely identified by a Session ID+Hostname conveyed in the Session Create Event request. All subsequent Session Update or Delete Events associated with this Session Object will have this same pair of Session ID+Hostname in an embodiment. 
     In an embodiment, when a system  20 A-D determines an event or heartbeat period expiration has occurred (no heartbeat signal received) (activity  96 ) (such as an event to/from a session device  30 A-I), the system  20 A-D may publish the activity to a session monitoring system  50  (activity  98 ). In another embodiment, the session monitoring system  50  may determine when an event or heartbeat period expiration has occurred (no heartbeat signal received) (activity  96 ) (such as an event to/from a session device  30 A-I). In an embodiment, each local Session Object has a Heartbeat Timeout, which will be started as soon as the local Session Object is created. In an embodiment, the processing system  20 A-D (node) acting as a UA that generates the Session Create Event is responsible to send a Session Update Event upon any changes to the Session&#39;s information, or upon every Refresh Period (default to 100s in an embodiment but configurable to other periods). 
     In an embodiment, the heartbeat timeout for a local session object may be set to a multiple of the refresh period, 3 times the refresh period in one embodiment. If the heartbeat timeout occurs, the session object may be destroyed and will not report session updates. In such an embodiment, a 3 period timeout may allow  3  session events to be reported prior to destroying the local session object. Further in an embodiment each session event or update may reset the Heartbeat timeout for a session object. 
     A session monitoring system  50  may receive/monitor/listen for published or pushed session events and count the events based on device, user, domain, Host, or other session event datum and User selections. Counting by Device (session device  30 A-I) may be determined by the origination URL or termination URL contained in published session events. In an embodiment, a pointer to the Session may be inserted into a corresponding Origination or Termination Session Map associated with the identified Device respectively. When an associated Session ends, either explicitly by the Session Delete Events or a Heartbeat Timeout, corresponding Origination or Termination Session map entries may be erased. Instantaneous Session (or Call for VOIP sessions) Counts for a device may be determined by the size of the resultant Origination and Termination Session Maps. 
     Counting by User may be determined by the “User ID” contained in the Session Events, which may identify the User associated with the published Session. Similar to counting Devices, a pointer to the Session may be inserted into a Session Map associated with an identified User. When an associated Session ends, either explicitly by a Session Delete Events or Heartbeat Timeout, corresponding map entries may be removed. Instantaneous Session (or Call for VOIP sessions) Counts for a User may be determined by the size of the resultant User Session Map. 
     Counting by Domain may be determined by parsing the Domain from the User ID where User ID contained in the Session Events includes &lt;User&gt;@&lt;Domain&gt; where the &lt;Domain&gt; component identifies the Domain associated with the Session. A pointer to the Session may be inserted into a Session Map associated with the identified Domain. When an associated Session ends, either explicitly by a Session Delete Events or Heartbeat Timeout, corresponding map entries may be removed. Instantaneous Session (or Call for VOIP sessions) Counts for a Domain may be determined by the size of the resultant by the size of the Domain Session Map. 
     Counting by Host may be determined by the “Hostname” contained in the Session Events, which may identify the User associated with the published Session. Similar to counting Devices, a pointer to the Session may be inserted into a Session Map associated with an identified User. When an associated Session ends, either explicitly by a Session Delete Events or Heartbeat Timeout, corresponding map entries may be removed. Instantaneous Session (or Call for VOIP sessions) Counts for a User may be determined by the size of the resultant User Session Map. 
       FIG. 5A  illustrates a block diagram of a device  230  that may be employed at least in part in a session processing system  20 A-D and session monitoring systems  50  in various embodiments. The device  230  may include a central processing unit (CPU)  232 , a random access memory (RAM)  234 , a read only memory (ROM)  237 , a local wireless/GPS modem/transceiver  244 , a display  247 , a camera  257 , a speaker  245 , a rechargeable electrical storage element  256 , and an antenna  246 . The CPU  232  may include a sessions module  254 . The RAM  234  may include a queue or table  248  where the queue  248  may be used to store session events, objects, and maps. The RAM  234  may also include program, algorithm, and session data and session instructions. The rechargeable electrical storage element may be a battery or capacitor in an embodiment. 
     The modem/transceiver  244  or CPU  232  may couple, in a well-known manner, the device  230  in architecture  10 A-C to enable communication with session devices  30 A-I, session processing system  20 A-D, or session monitoring system  50 . The modem/transceiver  244  may also be able to receive global positioning signals (GPS) and the CPU  232  may be able to convert the GPS signals to location data that may be stored in the RAM  234 . The ROM  237  may store program instructions to be executed by the CPU  232  or sessions module  254 . 
       FIG. 5B  illustrates a block diagram of a device  260  that may be employed at least in part in a session device  30 A-I in various embodiments. The device  260  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 , storage  276 , a non-rechargeable or rechargeable electrical energy storage unit  286 , and an antenna  284 . The CPU  262  may include a session module  292 . The RAM  264  may include queues  278  where the queues  278  may store session data. 
     The ROM  266  is coupled to the CPU  262  and may store the program instructions to be executed by the CPU  262  and session module  292 . The ROM  266  may include applications and instructions for the session module  292 . The RAM  264  may be 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 multimedia content. 
     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  275  where the data may include messages, digital media content, or session information. The transceiver ASIC  274  may include an instruction set necessary to communicate in architectures  10 A-C. The transceiver ASIC  274  may be coupled to the antenna  284  to communicate session events and content. When a message is received by the transceiver ASIC  274 , its corresponding data may be transferred to the CPU  262  via the serial bus  275 . The data can include wireless protocol, overhead information, session data, and content to be processed by the device  260  in accordance with the methods described herein. 
     The rechargeable electrical storage element  286  may be a battery or capacitor in an embodiment. The storage  276  may be any digital storage medium and may be coupled to the CPU  262  and may store temporary program data, overhead information, session events, and content. Any of the components previously described can be implemented in a number of ways, including embodiments in software. Thus, the devices  230 ,  260  elements including the RAM  234 , ROM  237 , CPU  232 , modem/transceiver  244 , storage  276 , CPU  262 , RAM  264 , ROM  266 , and transceiver ASIC  274 , may all be characterized as “modules” herein. 
     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 A-C and as appropriate for particular implementations of various embodiments. Devices  30 A-I and systems  20 A-D and  50  may communicate in architecture  10 A-C using one or more known digital communication formats including a cellular protocol such as code division multiple access (CDMA), time division multiple access (TDMA), Global System for Mobile Communications (GSM), cellular digital packet data (CDPD), Worldwide Interoperability for Microwave Access (WiMAX), satellite format (COMSAT) format, and local protocol such as wireless local area network (commonly called “WiFi”), Near Field Communication (NFC), radio frequency identifier (RFID), ZigBee (IEEE 802.15 standard) (and Bluetooth. 
     As known to one skilled on the art the Bluetooth protocol includes several versions including v1.0, v1.0B, v1.1, v1.2, v2.0+EDR, v2.1+EDR, v3.0+HS, and v4.0. The Bluetooth protocol is an efficient packet-based protocol that may employ frequency-hopping spread spectrum radio communication signals with up to 79 bands, each band 1 MHz in width, the respective 79 bands operating in the frequency range 2402-2480 MHz. Non-EDR (extended data rate) Bluetooth protocols may employ a Gaussian frequency-shift keying (GFSK) modulation. EDR Bluetooth may employ a differential quadrature phase-shift keying (DQPSK) modulation. 
     The WiFi protocol may conform to an Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol. The IEEE 802.11 protocols may employ a single-carrier direct-sequence spread spectrum radio technology and a multi-carrier orthogonal frequency-division multiplexing (OFDM) protocol. In an embodiment, Devices  30 A-I and systems  20 A-D and  50  may communicate in architecture  10 A-C via a WiFi protocol. 
     The cellular formats CDMA, TDMA, GSM, CDPD, and WiMax are well known to one skilled in the art. It is noted that the WiMax protocol may be used for local communication between the one or more Devices  30 A-I and systems  20 A-D and  50  in architecture  10 A-C. The WiMax protocol is part of an evolving family of standards being developed by the Institute of Electrical and Electronic Engineers (IEEE) to define parameters of a point-to-multipoint wireless, packet-switched communications systems. In particular, the 802.16 family of standards (e.g., the IEEE std. 802.16-2004 (published Sept. 18, 2004)) may provide for fixed, portable, and/or mobile broadband wireless access networks. Additional information regarding the IEEE 802.16 standard may be found in IEEE Standard for Local and Metropolitan Area Networks—Part 16: Air Interface for Fixed Broadband Wireless Access Systems (published Oct. 1, 2004). See also IEEE 802.16E-2005, IEEE Standard for Local and Metropolitan Area Networks—Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems—Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands (published Feb. 28, 2006). Further, the Worldwide Interoperability for Microwave Access (WiMAX) Forum facilitates the deployment of broadband wireless networks based on the IEEE 802.16 standards. For convenience, the terms “802.16” and “WiMAX” may be used interchangeably throughout this disclosure to refer to the IEEE 802.16 suite of air interface standards. The ZigBee protocol may conform to the IEEE 802.15 network and two or more user session devices  30 A-I and session processing systems  20 A-D may form a mesh network. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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.