Communication devices utilizing wireless communication protocols are ubiquitous. These devices utilize a cellular network (e.g., GSM or CDMA) to place and receive telephone calls to other communication devices. A communication device may include another mobile communication device on the same or another cellular network, a Voice-over Internet Protocol (VoIP) communication device, a hybrid VoIP/Cellular communication device and/or a plain old telephone service (POTS) communication device. Moreover, a variety of computer devices may utilize communication interfaces and protocols for exchanging audio, video, and text data over an Internet Protocol (IP) network such as, for instance, the Internet. Each of these telephony or computer communication devices may use a different access network but all are interfaced at some point to allow for communication among the different networks.
Setting up and conducting conferences among one or more of the aforementioned devices in a simple intuitive manner is a desired feature. Current telephonic systems may utilize a dial-in telephone number and access code that each participant must go through to gain access to a conference bridge. Thus, the participants are required to place an outgoing call to a bridge line and then enter an authentication code before being connected with the other participants. This can be tedious and even dangerous if a participant is using a mobile communication device while operating a motor vehicle. What is needed is a simpler way to establish and connect to a conference.
Described herein are methods, systems, and techniques for constructing and executing a conference.
The embodiments described herein disclose systems and methods for intelligently structuring, handling, and executing conferences among computer and communication devices. The systems and methods of the invention may be embodied in and performed by communication devices, conference servers, conference servers and other devices, and software instructions executed by some or all of such devices, as will be explained in detail below. One or more of the aforementioned devices may be combined. For example, a conference server may include the functions of a conference server or vice-versa. The different types of networks contemplated herein include, for example, cellular mobile networks, cellular mobile networks utilizing Internet Protocol (IP) protocol(s), the public switched telephone network (PSTN), and data networks, such as the Internet or other packet switched IP-based networks, including wide area networks, local area networks, and combinations thereof.
As used herein the term “conference” is meant to generally indicate a two-way exchange of audio (e.g., voice telephony call or audio streaming data), video (e.g., video telephony call or video streaming data), text (e.g., instant messaging (IM) chat sessions), and other information or any combination thereof between two or more computer and/or communication devices. As used herein, the term “device” is intended to mean a device capable of connecting to one or more telephony network(s) (e.g. the PSTN, one or more cellular mobile networks, one or more VoIP networks), one or more data networks (e.g., the Internet, local area networks (LANs)). A device may be wired or wireless and may operate on one or more telephony networks including, but not limited to, a packet switched IP-based network, a cellular mobile network, or the PSTN. As used herein, the term “communication link” is intended to mean a physical or logical channel that connects two or more devices. A communication link may be a signaling link or a media link. In this context, a conference may be established via one or more communication links. One or more media streams may be transmitted over a communication link. A conference server may be situated between devices thereby making the conference server an endpoint in a communication link. A conference server may be hosted within an IP network such as, for instance, the Internet or a LAN/WAN accessible to the Internet.
The convergence of and inter-operation among different types of network technologies (e.g., heterogeneous network inter-operability) blurs the line between various distinct networks. This disclosure's discussion of networks includes the portion of a network that connects devices to a service provider's core network. This portion of a network may also be referred to as the interface between the device and the network. Another type of interface may be the interface between networks. That is, the interface necessary to facilitate seamless communication from one network to another.
Therefore, references herein to a device capable of connecting to or communicating via a cellular mobile network refer to a device equipped with a cellular transceiver for wireless communication with basestations and other cellular mobile access points. Similarly, references herein to a device capable of connecting to or communicating via a data network refer to a device equipped with a transceiver or other network interface for wireless communication (e.g., 802.11) with a router or other data network access point. One particular device may be characterized herein as a wireless handset. A wireless handset may include multiple RF transceivers, one of which may be operable to connect to an access network for a cellular mobile network and another of which may be operable to connect to an access network for an IP data network (e.g., 802.11).
The PSTN 109 can be characterized as a circuit switched point-to-point communication network in which a physical connection between the endpoints is maintained for the duration of the connection or communication link. The PSTN 109 may also be referred to as the legacy telephone network as it is the backbone infrastructure for connecting communication devices comprised of Plain Old Telephone Service (POTS) phones 116.
Cellular mobile networks 105 may come in different varieties based on the radio transmission scheme between a device known as a wireless handset (e.g., mobile or cellular phone) 114 and the cellular mobile network basestation 110 that is in communication with the wireless handset 114. Two such radio transmission schemes are the Global System for Mobile Communication (GSM) and Code Division Multiple Access (CDMA). These radio transmission schemes are incompatible with one another necessitating an intervening interface to allow communication between endpoints on either network. In addition, each network may operate over a specific frequency ranges. Often, there may even be an intervening network such as the PSTN 109 between two distinct cellular mobile networks 105. Each cellular mobile network 105 includes an interface to the PSTN 109 such that calls crossing that interface can be handled by the receiving network whether it is a cellular mobile network 105 or the PSTN 109.
Various cellular mobile network operators base their network on one of the radio transmission schemes and provide service to wireless handsets 114 using that radio transmission scheme over a defined frequency band. For example, a wireless handset 114 wirelessly communicates with a basestation 110 that serves as an access network to the cellular mobile network 105. The basestation 110 authenticates and authorizes the wireless handset 114 to the cellular mobile network 105 and, in conjunction with other equipment within the cellular mobile network 105, manages calls to and from the wireless handset 114. The cellular mobile network 105 provides connectivity for any wireless handsets 114 capable of cellular transmission that are physically located within range of the cellular mobile network 105. The range of a cellular mobile network 105 depends in part on an amplification, power, and/or energy associated with the antennas comprising cellular base station, wireless handsets 114 and the like.
Similarly, an IP based data network 107 like the Internet 101 may provide wireless connectivity to wireless handsets 114 that are also VoIP enabled and VoIP communication devices 118 within range of an IP access point 112. For instance, an IP access point 112 may provide wireless connectivity using any of the 802.11 WiFi standards and/or any other type of IP based connectivity standard. As will be appreciated by those of skill in the art, a wireless handset 114 or VoIP communication device 118 may experience a stronger connection signal when located closer to an IP access point 112 than when located further away from the IP access point 112. Thus, the strength of the wireless data connection may fade as the dual mode wireless handset 114 or VoIP communication device 118 moves away from an IP access point 112. In some cases the VoIP communication device 118 may be wired directly to the IP access point 112 via, for instance, an Ethernet coupling. In another embodiment, a computer device 115 may be used to create and exchange messages with an application server 102 (described below). In addition, if the computer device 115 includes telephony hardware/software, it may also exchange signaling and media data with a conference server like initiating conference server 103a (described below). The computer device 115 may also send and receive media streams via means other than a telephony protocol.
The collection of IP based data networks illustrated in
In certain embodiments, cellular mobile network(s) 105 include cellular networks or portions of cellular networks based on GSM, LTE, CDMA, and/or any other cellular network standards. IP based data networks 107, 101 include, for example, the Internet, one or more intranets, wide area networks (WANs), local area networks (LANs), and the like, portions or all of which may be wireless and/or wired. For instance, an IP based data network 107, 101 may be a wireless network or a portion of a wireless network implemented using an IEEE 802.11 standard, WiMAX, and/or any other wireless data communication standard.
The various networks 109 (PSTN), 105 (Cellular), 107, 101 (IP Based) may interface with a conference server 103a or 103b through gateway devices, routers and/or other appropriate devices (not shown). Similarly, the wireless handsets 114 may interface with the various networks 109 (PSTN), 105 (Cellular), and 107, 101 (IP based) through appropriate access points 110, 111, 112 (others not shown).
An application server 102 may also reside within the packet based IP network 101 and may be configured to communicate with multiple communications devices to exchange signaling and information pertaining to setting up a conference. The application server 102 may be communicable with the initiating conference server 103a that also resides within the packet based IP network 101. In some embodiments, the application server may be co-located with the initiating conference server 103a or the functions of the application server may be performed by the initiating conference server 103a. The application server 102 may provide information such as telephone numbers or other means of contact (e.g., email, SMS/text message, IM, web browser) to the initiating conference server 103a so that the initiating conference server 103a may establish and maintain a conference as described above. Sometimes a telephone number or other means of contact may be associated with a communication device that is not directly reachable by initiating conference server 103a. In such instances, conference server 103a may communicate with an “other conference server 103b” that can reach the communication device of that telephone number. The application server 102 and the initiating conference server 103a may be bundled together or may be separate but communicable with one another.
In addition, the wireless handsets 114 via the cellular mobile network 105 are capable of sending data including short message service (SMS) text messages through the cellular mobile network 105 into the IP network(s) 101, 107. Similarly, the application server 102 and initiating conference server 103a may also be capable of sending data including SMS text messages through the IP network(s) 101, 107 and into the cellular mobile network 105 to reach wireless handsets 114.
The conferencing module 215 may be responsible for connecting the various legs of a conference together. Each participating device in a conference is communicable with the initiating conference server 103a over a separate call leg. The bridge module 220 joins the appropriate call legs together to create group communication.
The bridge module 220 may be responsible for processing call flows including setting up and tearing down call legs with various devices and other conference servers. In one embodiment, the conferencing module 215 may send and receive session initiation protocol (SIP) messages. While the conferencing module 215 may utilize a VoIP protocol such as SIP, it can communicate with end user devices that are not VoIP or SIP based by routing through other conference servers that perform interface conversions from SIP to other protocols such as, for instance, SS7 for the PSTN or CDMA/TDMA/GSM for cellular mobile networks.
Alternatively, a plurality of initiating conference servers 103a may be employed and may be arranged, for example, in one or more server banks or computer banks or other arrangements. For example, a plurality of initiating conference servers 103a together may comprise a cloud computing resource, a grid computing resource, and/or any other aggregated or distributed computing arrangement. Such initiating conference servers 103a may be located in a single installation or may be distributed among different geographical locations. For purposes of convenience, the initiating conference server 103a is illustrated in
The communication interface(s) 225 may include a voice-over-IP (VoIP) interface adapted to exchange IP based telephony signaling and/or media data with other IP network devices using a VoIP protocol. Another communication interface 225 may be a PSTN interface adapted to convert incoming PSTN audio data to VoIP audio data and convert outgoing VoIP audio data to PSTN audio data. Still another communication interface 225 may be an IP data interface 117 adapted to exchange IP data with other IP network devices. The IP data may be indicative of streaming audio and/or streaming video. This may also include IP data exchanged with a mobile wireless handset over an intermediate cellular mobile network. Another communication interface may be the app interface 106. The app interface 106 is specifically directed to exchanging data between the initiating conference server 103a and the application server 102. Yet another communication network interface 225 may be directed toward an alternative network (not shown) adapted to exchange data with a computing and/or communications device. Examples of alternative network(s) may include, but are not limited to, WiMax and whitespace. A whitespace network may be characterized as one that utilizes frequency spectrum that is overlapping with that of broadcast television frequency spectrum.
The application server 102 may also be communicable with a conferencing application on a mobile device 114. As will be described in more detail below, the conferencing application of a wireless handset may send data to the application server 102 indicative of a desire to set up a conference with one or more other participants via their device(s). The application server 102 may receive a conference setup request comprising a list of participants, at least one telephone number or other means of contact for each participant, and a proposed date/time for the conference from an initiator of the conference. In another embodiment, the application server 102 may store means of contact data for frequently or previously used devices such that the conference setup request need only identify the name of the participant. The application server 102 may then lookup the name and determine the preferred means of contact for that participant. The initiator is also a participant and his/her name and means of contact such as, for instance, telephone number are also part of the conference setup request. The application server 102 parses the received data and creates an invitation message to all participants notifying them of the date and time of the proposed conference as well as a list of all participants. The invitation message may be distributed to each participant using one or more means of communication including, but not limited to, email, text message, push notification, or the like.
The WiFi transceiver 410 may be operable to communicate with an IP network access point 112 using one or more of the 802.11 wireless transmission protocols. Upon connection with an IP network access point 112, the wireless handset 114 may exchange IP data with servers or other computers that are connected with or communicable with the Internet 101 via LAN/WAN 107. This may include the application server 102 and initiating conference server 103a shown in
The cellular transceiver 415 may be operable to communicate with a cellular mobile network 105 for both voice and IP data communication. On the voice side, the cellular mobile network 105 may be based on GSM, CDMA, TDMA or other communication protocols while on the IP data side, the cellular mobile network 105 may be based on, for example, GPRS, EDGE, EV-DO, HSPA-D, HSPA-U, LTE, UMTS-WCDMA, UMTS-TDD, etc.
The wireless handset 114 may further include data storage 425, software applications such as, for instance, a conferencing application 440a, a text messaging application 440b, and a browser application 440c. The wireless handset 114 may also include various user interface(s) 402. The data storage 425 may include, for example, one or more types of memory devices including, but not limited to, flash memory usable for ROM, RAM, PROM, EEPROM, and cache. Other software applications (not shown) may include, for example, one or more software applications executable on or by the processor(s) 405 including, but not limited to, email applications, contact applications, calendar applications, and specific data and/or audio/video applications. The user interface(s) 402 may include, for example, a display, a touchscreen for soft-key input, speaker(s), microphone(s), a keyboard for hard-key input, and one or more buttons. The data storage 425 may store contact data comprising for people including, but not limited to, multiple telephone numbers, email addresses, SMS enabled telephone numbers, postal addresses, and the like. The contact data may be used by a contact application in conjunction with other applications on the wireless handset 114 to facilitate communications with the people in the contact database.
The conferencing application 440a may facilitate setting up a future or spontaneous conference with one or more participants. Via the user interface(s) 402 and the conferencing application 440a, a user may initiate a conference. Via the conferencing application 440a an initiating user may identify one or more participants for a conference and date/time for the call. If the participants are in the user's contact database, specific information may be obtained from the contact database and included in a conference invite message to be sent to the application server 102. In another example, contact information may be obtained via the application server 102. The application server may be communicable with another cloud based server that contains contact information. This cloud based server contact information may be synced with contact data on a wireless handset 114. Having cloud based contact information available to the application server 102 permits usage of a web interface such as web browser 440c of wireless handset 114 or a web browser of another computing device that are VoIP enabled.
If a participant is not in the user's contact database, the conferencing application 440a may prompt the user for one or more contact telephone numbers, messaging addresses, and/or email addresses, etc. to which an invitation to the conference may be sent. In another example, the conferencing application 440a may obtain event information from a calendar application, the event information indicative of a conference. Moreover, the conferencing application 440a may prompt for a date/time for the conference. The user may input a specific date/time or may opt to start call now. This latter option may be referred to as a spontaneous conference as its intent is to create a conference as quickly as is practical upon notifying all requested participants.
In another embodiment the conferencing application 440a may allow the conference to be scheduled adhoc. In this embodiment when one or more required participants indicate overlapping availability the call will begin. For example, a group chat session or group SMS text message thread may be established among two or more participants. A decision may be made to convert the chat or SMS text message thread into an adhoc conference. If at least two participants indicate availability for the adhoc conference via a conference invite within the chat session or group SMS text message thread, a command to a conference server 103a may be sent including the relevant contact information of the participants with instructions for the conference server to set up a conference immediately.
Once on a conference, either adhoc or pre-scheduled, certain participant devices (e.g., wireless handset 114 or VoIP telephony enabled computing device) may be able to utilize speech recognition software and processing to receive and process a set of commands. For example, a participant may wish to include yet another person on the call and speak a command such as, “Conference John Black”. The command may be locally processed on the participant's device to find the contact information for John Black and forward it to the conference server with a telephony instruction to call John Black and bridge him to the existing conference. Other commands that may be speech recognized include, but are not limited to, a start recording, stop recording, pause recording, resume recording, etc.
In another embodiment, a participant may be able to switch devices while currently in a conference. For example, a participant may begin a conference on a wireless handset such as their mobile phone. The participant may be in transit and reach a destination such as their office and wish to switch from the wireless handset to a desk phone. The participant may create and send a message to the application server 102 indicative of the desire to switch to another device. The message may include a means of contact for the new device. The application server 102a may then send a message to the initiating conference server 103a with instructions to create another communication link and media stream from the conference server to the new device using the means of contact included in the message received by the application server 102. The initiating conference server 103a may then construct the new media stream once any signaling and response from the new device is achieved. As a last step, the media stream with the previous device may be terminated.
In another embodiment, the application server 102 may maintain a web-page presence for active conferences. For example, the application server may dynamically create and update a webpage URL that displays conference status and may even provide screen sharing for data (e.g., documents, slide presentations, etc.). With respect to conference status, a portion of the web page may graphically illustrate the names of the participants. When available, a photograph of the participant may also be associated with the name likely in a thumbnail format. This would allow participants to be on the conference with one device and use a second computer device to “view” the status of the conference. Such an implementation may also visually highlight in some manner the participant currently speaking. Adding the functionality just described provides for a richer conference experience. Participants are still free to use the device of their choice for connecting to the conference but may simultaneously have a web browser window open to the conference status web page that provides additional information and context for the conference.
The wireless handset 114 may also include a text messaging application 440b for sending and receiving short message service (SMS) text messages. SMS text messages are one mode of communication that may be used to communicate conference invitations and responses among participant devices and the application server 102. The wireless handset 114 may also include a browser application 440c for exchanging data for communicating conference invitations and responses among participant devices and the application server 102. In another embodiment, the wireless handset 114 may also include an email application (not shown) for sending and email messages. Email messages may be another mode of communication that may be used to communicate conference invitations and responses among participant devices and the application server 102. The wireless handset 114 may also include a calendar application (not shown) for managing calendar entries. Calendar entries when synced to an external calendar service may be used as another mode of communication to communicate conference invitations and responses among participants and the application server 102. The embodiments are not necessarily limited to the examples described herein.
Included herein is a set of flow charts and message diagrams representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.
Each participant may respond to the invite message 520 with a response message (CC_Invite_Accept_Msg) 530 indicating whether they will or will not participate in the conference. Upon receiving a response message 530 from a participant device, the application server 102 may create or update a data record indicative of the date/time the conference is to take place along with the designated telephone number(s) (or other contact means) of the participants. The invite response message 530 may be formatted the same way as the invite message 520. For example, if the invite message 520 was received as a text message, the response message 530 may be a reply to the text message. Similarly, if the invite message 520 was received as an email message, the response message 530 may be a reply to the email message. If the invite message 520 was a push notification, the response message 530 may be an action taken on the push notification. For example, the push notification may include soft buttons for “accept”, “tentative”, “accept with different number”, or “deny”. Selecting “accept” may spawn a response message 530 back to the application server 102 indicating that the participant has accepted the conference and may be reached at the telephone number for the device that received the invite message 520 for the conference. Selecting “tentative” may spawn a response message 530 back to the application server 102 indicating that the participant is not sure yet whether they will participate in the conference. The application server may then periodically resend the invite message 520. In another embodiment, the invite message may be entered into the calendar application of the device receiving the invite message 520. A calendar reminder for the invite message 520 may periodically pop up on the device allowing the participant to choose one of the other options of “accept” “accept with new number”, or “deny”. Selecting “accept with new number” may spawn a response message 530 back to the application server 102 indicating that the participant has accepted the conference but is providing a different telephone number than that for the device that received the invite message 520. The different telephone number is the telephone number to be used for the conference. Selecting “deny” may spawn a response message 530 back to the application server 102 indicating that the participant has denied the conference. In each case of acceptance, the participant's device may also enter the conference into the calendar application of the device receiving the invite message 520. This may also occur if a server is integrated with a device's calendar function as well. The cloud based calendar server can scan regularly for external entries made, can add entries arising out of conference scheduling via conference app 440a or as a means of notifying the device of a new calendar entry. For example, an initiating participant sets up a conference with the application server 102. Another participant may also be a user of the service and may have previously linked their calendar application with the application server 102. If a participant has opted to be notified via calendar, they will receive a calendar invite from the application server 102 which may be accepted, tentatively accepted, or denied through normal calendar application functionality from a cloud based web page, a locally hosted computer application, or a calendar application hosted on a wireless handset 114, etc.
At the appropriate time, the application server 102 may forward the call data 535 to an initiating conference server 103a. The initiating conference server 103a via a conferencing module 215 and bridge module 220 may read the call data 535 and prepare resources to bridge and conference the participants. At the time specified for the conference, the initiating conference server 103a via the bridge module 220 may compose and send a series of SIP_Invite messages 540 with media specified via the conferencing module 215 directed to each of the VoIP devices or telephone numbers in the call data 535. A VoIP device is a SIP endpoint and does not necessarily need to include a telephone number. This includes the telephone numbers or contact means for the initiating device and all other participating devices. Since the initiating conference server 103a, in this example, is a SIP based conference server, the messaging to and from the initiating conference server 103a is also SIP based. Other IP based telephony protocols may be implemented in lieu of SIP. In addition, if the initiating conference server 103a were resident in a mobile cellular network, the call signaling may be altered to reflect the protocols used within the network in which the initiating conference server 103a resides. It should also be noted that while the initiating conference server 103a is SIP based, it may still connect with devices hosted in different telephony networks by way of interface servers that resolve messaging and signaling between different telephony networks. As earlier described, examples of different telephony networks include IP based VoIP, cellular, and circuit switched PSTN networks.
If the SIP_Invite message 540 encounters an intermediate interface server (e.g., other conference server 103b) before reaching the device associated with the telephone number to which the SIP_Invite message is intended, the other conference server 103b will translate the SIP_Invite message 540 to a Connect_Request message 544 and forward to the intended participating device. The Connect_Request label is generic and is not intended to represent any specific protocol or telecommunication signaling system. Rather, it is representative of whatever signaling or messaging is implemented by the other conference server 103b in communicating with participant devices. Thus, the Connect_Request message 545 may be an SS7 protocol message, a CDMA protocol message, a TDMA protocol message, etc. depending on the telecommunication protocol implemented by the other conference server 103b.
Each participating device may receive either a SIP_Invite message 540 or a Connect_Request message 544 and respond accordingly. In the case of SIP signaling, a SIP—200 message 550 accepting the SIP_Invite message 540 may be returned to the initiating conference server 103a. In the case of alternate signaling, a form of a Connect message 548 may be returned to the other conference server 103b which, in turn, translates the Connect message 548 to a SIP—200 message 550 and forwards the SIP—200 message 550 to the initiating conference server 103a. The initiating conference server 103a via the conferencing module 215 may then join the various call legs between the initiating conference server 103a and the participant devices into appropriate media streams denoted as the CC_Media_Stream 560. The CC_Media_Stream 560 may traverse one or more telephony networks and one or more conference servers depending on the telephony network to which a participant device subscribes. Upon creating the media stream, a conference has been established by the initiating conference server 103a without any of the participating devices having to call take any action beyond answering a call.
It should be noted that the conference may have been set up as a spontaneous conference. A spontaneous conference is one in which the initiating participant does not specify a future date/time for the conference but rather indicates “now” when sending out the Orig_CC_Invite_Msg 510 to the application server 102. This is similar to the adhoc scheduling of a conference described above.
As described above, the initiating device need not be a wireless handset 114 but could be a telephony enabled computer device or a computer enabled VoIP device. Any device that has IP connectivity and VoIP capability along with the conferencing app can become an initiating or participating device. This may include, for example, a tablet or computer with WiFi connectivity, a tablet or computer with LTE connectivity, a WiFi only personal digital assistant (PDA) or handheld media type device, etc. A wireless handset 114 is used for purposes of illustration with respect to
In the illustrated embodiment shown in
In the illustrated embodiment shown in
In the illustrated embodiment shown in
In the illustrated embodiment shown in
In the illustrated embodiment shown in
Some embodiments may be described using the expression “one embodiment” or “an embodiment” along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. Further, some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
Although the flowcharts and message diagrams of
Where any component discussed herein is implemented in the form of software, any one of a number of programming languages may be employed such as, for example, C, C++, C#, Objective C, Java, Javascript, Perl, PHP, Visual Basic, Python, Ruby, Delphi, Flash, or other programming languages. Software components are stored in a memory and are executable by a processor. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by a processor. Examples of executable programs may be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of a memory and run by a processor, source code that may be expressed in proper format such as object code that is capable of being loaded into a random access portion of a memory and executed by a processor, or source code that may be interpreted by another executable program to generate instructions in a random access portion of a memory to be executed by a processor, etc. An executable program may be stored in any portion or component of a memory including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.
A memory is defined herein as including both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, a memory may comprise, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, or a combination of any two or more of these memory components. In addition, the RAM may comprise, for example, static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM may comprise, for example, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device.
The devices described herein may include multiple processors and multiple memories that operate in parallel processing circuits, respectively. In such a case, a local interface, such as a communication bus, may facilitate communication between any two of the multiple processors, between any processor and any of the memories, or between any two of the memories, etc. A local interface may comprise additional systems designed to coordinate this communication, including, for example, performing load balancing. A processor may be of electrical or of some other available construction.
Although the various modules and other various systems and components described herein may be embodied in software or code executed by general purpose hardware, as an alternative the same may also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits having appropriate logic gates, or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.
Also, any logic, functionality or application described herein, including the bridge module 220, and conferencing modules 215, 315, that comprises software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, for example, a processor in a computer system or other system. In this sense, the logic may comprise, for example, statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system. The computer-readable medium can comprise any one of many physical media such as, for example, magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium may be a random access memory (RAM) including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.
What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.