The present application relates to mobile device communication, and more particularly to group communication capabilities and services for mobile devices.
Mobile devices are used for voice and data communications. Increasingly, mobile devices can be used in a business environment. Businesses can have a need to provide conferencing capabilities, where a moderator can have an audio and/or video feed that is in the context of or otherwise relates to a set of materials, such as a presentation. Mobile devices have different network communication capabilities than do typical landline devices. Approaches to facilitating conferencing capabilities on mobile devices are desirable.
Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:
Mobile devices are increasingly used for communication, such as voice calling and data exchange. Also, mobile devices increasingly can use a wider variety of networks for such communication. For example, a mobile device can have a broadband cellular radio and a local area wireless network radio. Additionally, the broadband cellular capability of a mobile device may itself support a variety of standards, or protocols that have different communication capabilities, such as GSM, GPRS, EDGE and LTE.
One characteristic of mobile devices is that they can have sporadic access to any network, and often can have sporadic access to faster and/or cheaper networks. For example, mobile devices often can have an IEEE 802.11 wireless LAN access capability, as well as a broadband wireless radio capability. Sometimes, a mobile device may be able to use an 802.11 access point, while at other times, the mobile device may only have broadband wireless reception, and at still other times, the mobile device may have no current wireless capability. Different cost structures for usage of these different data networks can be in place, in addition to differences in the speed of different networks
Thus, while relying on general availability of a fast and reliable network connection that can support a content stream may be acceptable for a wired network device, such an assumption would be considerably less reliable for a wireless device, such as a mobile device. Nevertheless, it is desirable to be able to support real time conferencing involving presentation materials, for example, on mobile devices.
One approach to getting presentation material to mobile devices is to push content to the mobile devices at times when the mobile devices have access to a certain kind of network connection. For example, presentation content can be staged so that the content is distributed to different mobile devices when such mobile devices have access to an 802.11 network. However, such staging also can be done, for example, to cope with a more limited bandwidth but generally available broadband wireless connection, such that a large content item can be provided over a period of time to a given mobile device.
A software package can be provided on a mobile device to support such content push. An example of such a software package is known as Chalk™ Pushcast™, which is available for mobile devices offered by Research in Motion. Such a software package can operate to receive and store content that will be performed at a future time on the mobile device on which it is installed.
Systems that use such a device-side application also can have a server that operates to push data to the devices, and to receive data to be pushed to the devices. However, having a capability to conduct a live conference that uses, and synchronizes to, materials pre-loaded on a given mobile device using one or more of voice and video would further extend the usefulness of such a capability.
The depiction of
Device 11 also can include a capability to communicate over a Public Land Mobile Network (50) infrastructure 91. Other devices can use such PLMN 50 as well, such as a device 14. PLMN 50 also may communicatively couple with the PSTN 40 for carriage of voice and/or data traffic. Other devices can interoperate within the depicted context, such as PSTN telephones 87a and 87b, as well as SIP telephone 17.
A datalink 96 is depicted between mobile device 11 and push server 7. Such datalink 96 can be implemented within internet 2, and may also involve PLMN 50, and as such is depicted as a dashed line, indicating a logical, rather than a particular physical connection. Similarly, mobile device 11 also may have a communication channel to conferencing app server 6, which can implement a message passing framework. An example of such message passing framework, and exemplary usages thereof, is described below.
Processing module 221 communicates with mass storage 240, which can be composed of a Random Access Memory 241 and of non-volatile memory 243. Non-volatile memory 243 can be implemented with one or more of Flash memory, PROM, EPROM, and so on. Non-volatile memory 243 can be implemented as flash memory, ferromagnetic, phase-change memory, and other non-volatile memory technologies. Non-volatile memory 243 also can store programs, device state, various user information, one or more operating systems, device configuration data, and other data that may need to be accessed persistently. A battery 297 can power device 11 occasionally, or in some cases, it can be a sole source of power. Battery 297 may be rechargeable.
User input interface 210 can comprise a plurality of different sources of user input, such as a camera 202, a keyboard 204, a touchscreen 208, and a microphone, which can provide input to speech recognition functionality 209. Output mechanisms 212 can include a display 214, a speaker 216 and haptics 218, for example. These output mechanisms 212 can be used to provide a variety of outputs that can be sensed by a user, in response to information provided from processing module 221.
Processing module 221 also can use a variety of network communication protocols, grouped for description purposes here into a communication module 237, which can include a Bluetooth communication stack 242, which comprises a L2CAP layer 244, a baseband 246 and a radio 248. Communications module 237 also can comprise a Wireless Local Area Network (247) interface, which comprises a link layer 252 with a MAC 254, and a radio 256. Communications module 237 also can comprise a cellular broadband data network interface 260, which in turn comprises a link layer 261, with a MAC 262. Cellular interface 260 also can comprise a radio 264 for an appropriate frequency spectrum. Communications module 237 also can comprise a USB interface 266, to provide wired data communication capability. Other wireless and wired communication technologies also can be provided, and this description is exemplary.
Referring to
The mobile device 11 in
An application interface layer 419 controls application access to the media access 421 component. One application that can use network resources, through interface layer 419 is a group messaging client 408. Group messaging client 408 can manage the addressing, transmission and reception of messages in a group of which mobile device 11 is a part.
In an example relating to conferencing, mobile device 11 may join a specified group or begin to listen to messages associated with a specified group in conjunction with joining an audio feed (e.g., “dialing in” in to a conference). Such group messaging client 408 can interoperate with a group messaging framework 457 that can be implemented, for example, by a multicasting algorithm, or by other approaches to distribution of such messages. In some example paradigms, the messages primary are received by mobile device 11; however, the mobile device 11 also can transmit such messages. For example, if the mobile device 11 is being used by a moderator of a conference, then the mobile device 11 may be a source of messages concerning content synchronization that are sent through group messaging client 408 to group messaging framework 457, and ultimately are received by other devices.
Group messaging client 408 can serve as an application messaging service for a number of applications, such that when a message is received at client 408, such message can be distributed through a message distribution framework 410 on mobile device 11. For example, group messaging client 408 may expose an API, which other applications can poll. By further example, client 408 may signal a given application when it detects reception of availability of a message for a particular application. Also, message distribution framework 410 can operate to distribute messages among different applications operable on mobile device 11. One example application is a calendar application 405. Calendar application 405 can maintain a calendar of events or tasks correlated to a time or timeframe in which those events and tasks are expected to occur. For example, a teleconference can be scheduled for a particular time and date by provision of an entry in calendar application 405. The entry can be represented by data stored in a database maintained by calendar application 405. The entry can be added to calendar application 405 by virtue of a message from group messaging client 408, indicating that an event is available to be added. Calendar application 405 can output a notification through an output component interface 403, indicating that a new calendar invite was received, and responsive to acceptance of the invite, then calendar application 405 can add the event to its database.
The entries maintained by calendar application 405 also can contain a variety of other information. For example, dial-in information for an audio bridge, or other identifying information for an audio portion of a conference can be maintained in such entry. Other examples of such identifying information include a URL for an online meeting forum, from which audio and video will be made available, such as through a multicast stream. Other information that can be associated or stored with a calendar entry includes a reference or other identification of content locally stored on mobile device 11 that is expected to be accessed or used during an event associated with the entry.
Such content may be made accessible through a presentation control application 412 that maintains a local presentation storage 414. Presentation control application 412 also can send/receive messages from through message distribution framework 410. For example, a message generated by calendar application 405 can cause presentation control application 412 to start, and access a specified portion of content stored in presentation storage 414. Such content can be stored as a file or files, for example, such as a presentation. The calendar application 405 can initially specify such a presentation file to be loaded by presentation control application 412. Subsequently, messages can be received at group messaging client 408 that index into particular portions of such content. By particular example, a particular slide within a slide deck can be identified. Other content also can be received by group messaging client 408, such as markups or annotations relating to a particular identified slide.
Additionally, calendar application 405 also can generate a message that is provided through message distribution framework 410 to voice communication component 416. For example, calendar application 405 can provide a feature that allows automatic joining of a conference identified by a particular entry, or automatic dialing of an identified telephone number and associated access code for a conference. These data elements that are maintained by calendar application 405 can be provided to voice communication component 416 through messaging distribution framework 410.
The above example components of mobile device 11 can output visual and audio data through output component interface 403, to be displayed or performed through one or more visual 401 and audio 402 outputs, such as those depicted in the example devices of
Mobile device 11 interacts with other devices through such group messaging framework, for reception (or sending) of messages relating to content synchronization. Such messages can be generated from a presentation data server 461, while voice and/or video to which the local content is to be indexed or synchronized can be made available from voice media/conferencing server 4. One or more components of such information can be made available from a presentation audio source, such as a device 463 associated with a presenter. In one example, an instance of mobile device 11 can be used as device 463. Device 463 also can generate presentation content synchronization messages that can be sent to presentation controller 465, for subsequent distribution through server 461. Server 461 and controller 465 can be implemented by any of a variety of combinations of hardware and software. For example, server 461 can represent a geographically distributed and interconnected network of servers that operate to distribute such data to a potentially large number of devices, of which mobile device 11 is an example.
Additionally, data server 461 can operate to pre-stage/download content to mobile device 11 in advance of an event that is expected to use such content. Through such pre-staging, benefits such as lower peak usage of a network connection, usage of a faster or cheaper connection, and other such benefits can be achieved. The availability of group messaging concurrent with an audio (and potentially a video channel) allows synchronization of pre-staged content to what is being discussed, with reduced real-time data exchange.
An example of a method that includes multiple of the functional components described with respect to
The process elements depicted in
In the foregoing, separate boxes or illustrated separation of functional elements of illustrated systems does not necessarily require physical separation of such functions, as communications between such elements can occur by way of messaging, function calls, shared memory space, and so on, without any such physical separation. As such, functions need not be implemented in physically or logically separated platforms, although they are illustrated separately for ease of explanation herein.
For example, different embodiments of devices can provide some functions in an operating system installation that are provided at an application layer or in a middle layer in other devices. Different devices can have different designs, such that while some devices implement some functions in fixed function hardware, other devices can implement such functions in a programmable processor with code obtained from a computer readable medium.
Further, some aspects may be disclosed with respect to only certain examples. However, such disclosures are not to be implied as requiring that such aspects be used only in embodiments according to such examples.
The above description occasionally describes relative timing of events, signals, actions, and the like as occurring “when” another event, signal, action, or the like happens. Such description is not to be construed as requiring a concurrency or any absolute timing, unless otherwise indicated.
Certain adaptations and modifications of the described embodiments can be made. Aspects that can be applied to various embodiments may have been described with respect to only a portion of those embodiments, for sake of clarity. However, it is to be understood that these aspects can be provided in or applied to other embodiments as well. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive.