System and method for conducting private messaging

A system method are provided for enabling private messaging. The method comprises displaying a first messaging user interface with at least one contact, the first messaging user interface comprising at least one element identifying messaging participants; detecting a first input at the first messaging user interface, to enter a private conversation with the at least one contact; and displaying a second messaging user interface, the second messaging user interface modifying the at least one element to conceal an identity of at least one messaging participant in the second messaging user interface.

TECHNICAL FIELD

The following relates to systems and methods for conducting private messaging.

DESCRIPTION OF THE RELATED ART

Electronic messaging such as email, instant messaging, text messaging and the like has become ubiquitous both in desktop computing environments and mobile environments. While many messaging applications provide some level of security and privacy, the contents of a messaging session are typically visible on a device screen and may be viewed at a later time by another user that comes into possession of the device. Even with device passwords and other security measures in place, there are situations where another user can gain access to the contents of a messaging session and potentially become privy to private or sensitive information.

DETAILED DESCRIPTION

To address potential privacy and security issues concerning the display of messaging content, and to provide a more convenient way to switch between sensitive and non-sensitive messaging, it has been found that a messaging interface such as that used in instant messaging can be transitioned into and out of a private, secure, or “off the record” (OTR) mode. Such an OTR mode enables messages to be temporarily handled as private messages with the private messages removed or otherwise not stored within the normal or existing messaging conversation after the user leaves the OTR mode. Messages displayed during the OTR mode can also be concealed or obscured to further enhance the security and privacy of the private messaging session. It has been found that the following principles can apply to any type of messaging content, for example, text, audio, and video messages.

There is provided a method of messaging comprising: displaying a first messaging user interface with at least one contact, the first messaging user interface comprising at least one element identifying messaging participants; detecting a first input at the first messaging user interface, to enter a private conversation with the at least one contact; and displaying a second messaging user interface, the second messaging user interface modifying the at least one element to conceal an identity of at least one messaging participant in the second messaging user interface.

There is also provided a computer readable storage medium comprising computer executable instructions for messaging, the computer executable instructions comprising instructions for: displaying a first messaging user interface with at least one contact, the first messaging user interface comprising at least one element identifying messaging participants; detecting a first input at the first messaging user interface, to enter a private conversation with the at least one contact; and displaying a second messaging user interface, the second messaging user interface modifying the at least one element to conceal an identity of at least one messaging participant in the second messaging user interface.

There is also provided an electronic device comprising a processor, a display, and memory, the memory comprising computer executable instructions for causing the processor to enable messaging on the electronic device, the computer executable instructions comprising instructions for: displaying a first messaging user interface with at least one contact, the first messaging user interface comprising at least one element identifying messaging participants; detecting a first input at the first messaging user interface, to enter a private conversation with the at least one contact; and displaying a second messaging user interface, the second messaging user interface modifying the at least one element to conceal an identity of at least one messaging participant in the second messaging user interface.

Turning now toFIG. 1an example of a communication system8is shown which facilitates messaging between a first mobile device10aand a second mobile device10b(also referred to generally as “mobile device10” hereinafter) over a communication channel12. In the example shown inFIG. 1, the communication channel12facilitates peer-to-peer (P2P) messaging, e.g., instant messaging, which includes the exchange of P2P messages14. The mobile devices10a,10bare operable to display a conversation user interface (UI)18for conducting a P2P conversation. The conversation UI18provides for both typical, normal, or otherwise “regular” messaging using regular P2P messages14, and private or secure messaging using private P2P messages16, to enable a user to enter and leave private sessions with a contact or group of contacts (e.g., within a private group chat), within the same UI that is used for normal or regular P2P messaging. For example, as shown inFIG. 1, messaging may be conducted in sub-session A1using regular P2P messages14, with the conversation switching to a private sub-session B which uses private P2P messages16, and switching back to regular messaging in sub-session A2using the same conversation UI18. In this way, the advantages of private messaging can be seamlessly incorporated into a familiar and existing messaging environment with the contact for which the private sub-session is desired. For example, during a conversation, one correspondent may wish to have a brief private chat regarding a sensitive topic and not wish to have those messages persisted, particularly within the existing conversation. At the same time, the correspondents can switch to the private mode without having to create and then delete or destroy another conversation and/or utilize another service or application in order to have a “side conversation”.

In the following examples, a private or concealed sub-session or temporary portion of a conversation may also be referred to as an “off-the-record (OTR)” chat or OTR mode for illustrative purposes. It has been found that such an OTR mode is particularly advantageous within P2P-type messaging environments such those utilizing IM UIs since ongoing conversations with contacts can persist indefinitely. The ability to seamlessly navigate into and out of the OTR mode to conduct temporary private sub-chats avoids the need to create additional conversations or utilize alternative services or applications in order to do so, without disrupting the “regular” conversation portions. While the example shown inFIG. 1illustrates messaging between a pair of correspondents, the principles described herein may also be applied to group chats having three or more messaging participants.

For illustrative purposes, an example of a communication system8′ including a wireless infrastructure20that enables mobile devices10a,10bto communicate via a P2P messaging system22over a wireless network12′, is shown inFIG. 2. It will be appreciated that the mobile devices10a,10bshown inFIG. 2are shown as such for illustrative purposes and many other mobile devices10(not shown) may also be capable of communicating with or within the communication system8′. It will also be appreciated that although the examples shown herein are directed to mobile communication devices, the same principles may apply to other devices capable of communicating with the P2P system22. For example, an application (not shown) hosted by a desktop computer or other “non-portable” or “non-mobile” device may also be capable of communicating with other devices (e.g. including mobile devices10) using the P2P system22.

The P2P system22is, in this example, a component of the wireless infrastructure20associated with the wireless network12′. The wireless infrastructure20in this example includes, in addition to the P2P system22, and among other things not shown for simplicity, a personal identification number (PIN) database24. The PIN database24in this example embodiment is used to store one or more PINs associated with respective mobile devices10, whether they are subscribers to a service provided by the wireless infrastructure20or otherwise.

A first mobile device10amay communicate with a second mobile device10band vice versa via the P2P system22, in order to perform P2P messaging or to otherwise exchange P2P-based communications. For ease of explanation, in the following examples, any P2P-based communication may also be referred to as a P2P message14,16as shown inFIG. 2. It can be appreciated that only two mobile devices10a,10bare shown inFIG. 2for ease of illustration and, for example, in an electronic group conversation, three or more mobile devices10would be participating in the group conversation. The P2P system22in the example shown is configured to facilitate communication of both regular P2P messages14and private or OTR P2P messages16. For example, the P2P system22can identify from information included in the messages14,16whether the message is a regular P2P message14or an OTR P2P message16for the purpose of determining whether to store a copy of the message14,16and for how long. The P2P system22may be configured to only cache OTR P2P messages16for a period of time, or the mobile devices10a,10bmay be responsible for temporarily storing OTR P2P messages16for the during of a private OTR session.

In some example embodiments, the P2P system22may be capable of sending multi-cast messages, i.e. forwarding a single message from a sender to multiple recipients without requiring multiple P2P messages64to be generated by such a sender. For example, as shown inFIG. 3, the P2P system22can be operable to enable a single P2P message14,16to be sent to multiple recipients by addressing the P2P message14,16to multiple corresponding P2P addresses, and having the P2P system22multicast the message14,16to those recipients. It can be appreciated that multi-cast messages would not be permitted in an OTR mode unless all recipients are included in the private OTR sub-chat. In such a scenario, the procedures described herein for having participants opt into the OTR mode may be applied to all group chat members that are to participate in the discussion.

An example of a P2P message14,16is shown in greater detail inFIG. 4, and has a format that is particularly suitable for a PIN-to-PIN based system. In a typical P2P protocol, each P2P message14,16has associated therewith a source corresponding to the mobile device10which has sent the P2P message14,16and includes a destination identifying the one or more intended recipients. Each P2P message14,16in this example includes a body32, which contains the content for the P2P message14,16(e.g. text, audio, images, video, or other data), and a header30, which contains various fields used for transmitting and processing each P2P message14,16. In this example, the header30includes a message type field34to specify the type of transmission (e.g. chat, registration, block, presence, etc.), a source field36to specify the device address for the sender, a destination field38to specify the device address(es) for the one or more intended recipients, an ID field40to identify the corresponding P2P application (e.g., see IM application50inFIG. 5) and a timestamp field42to indicate the time (and if desired, the date) at which the P2P message14,16was sent by the designated sender. The message type field34may be used to designate whether the message14,16is a regular P2P message14or an OTR message16. However, the ID field40could also be used with a particular ID type being recognizable as an OTR-type message16. Another field could also be added to the header30to indicate OTR messages16.

It can be appreciated that in this example, the ID field40can be used to specify the application ID to identify a P2P application on the mobile device10. Where the P2P application relates to, for example, an IM system22′, the message type field34can also be used to designate an IM communication, and the ID field40would then correspond to a conversation ID, i.e. a conversation thread the message14,16corresponds to (e.g. such that each message14,16is identified by the conversation in which it was sent).

Other information or attributes may be included in the P2P message14,16, such as a subject field (not shown) to enable a subject for part or all of a conversation (in an IM example) to be transported with the P2P message14,16(e.g. to create new subjects, modify subjects, notify others of subjects, etc.), or application details field (not shown) to provide application-specific information such as the version and capabilities of the application.

The P2P system22can utilize any suitable P2P protocol operated by, for example, a P2P router (not shown), which may be part of the wireless infrastructure20. It can be appreciated however that a stand-alone P2P configuration (i.e. that does not rely on the wireless infrastructure20—not shown) may equally apply the principles herein. The P2P system22may also enable mobile devices10to communicate with desktop computers thus facilitating, for example, communications such as instant messaging (IM) between mobile applications and desktop applications on the desktop computer.

The P2P system22can be implemented using a router-based communication infrastructure, such as one that provides email, SMS, voice, Internet and other communications. Particularly suitable for hosting a P2P messaging router, is a wireless router or server used in systems such as those that provide push-based communication services. InFIG. 2, the wireless infrastructure20facilitates P2P communications such as instant messaging between mobile devices10. P2P messaging, such as IMing, is provided by an associated application stored on each mobile device10, e.g. an IM application50as shown inFIG. 5, which can be initiated, for example, by highlighting and selecting an icon from a display as is well known in the art. The P2P system22routes messages between the mobile devices10according to the P2P protocol being used. For example, the P2P protocol may define a particular way in which to conduct IM or other types of messaging.

In general, in a P2P protocol, the sender of the P2P message14,16knows the source address of the intended recipient, e.g. a PIN. This may be established when the two devices request to add each other to their respective contact or buddy lists. A particular mobile device10can communicate directly with various other mobile devices10through the P2P system22without requiring a dedicated server for facilitating communications. In other words, the P2P system22enables the mobile devices10to communicate with each other directly over the wireless infrastructure16′ in accordance with the P2P protocol.

When conducting a P2P session according to the example shown inFIG. 2, the mobile devices10a,10bcan communicate directly with the wireless infrastructure20in a client based exchange where, as noted above, an intermediate server is not required. A P2P message14,16sent by one mobile device10is received by the wireless infrastructure20, which obtains the source address for the intended recipient (or recipients) from information associated with the message14,16(e.g. a data log) or from the message14,16itself. After obtaining the recipient's address according to the P2P protocol, the wireless infrastructure20then routes the message14,16to the recipient associated with the mobile device10having such address (or recipients having respective addresses). The wireless infrastructure20typically also provides a delivery confirmation to the original sender, which may or may not be displayed to the user. The destination device can also provide such delivery information. The wireless infrastructure20may be capable of routing P2P messages14,16reliably as well as being capable of holding onto the P2P messages14,16until they are successfully delivered. Alternatively, if delivery cannot be made after a certain timeout period, the wireless infrastructure20may provide a response indicating a failed delivery. The wireless infrastructure20may choose to expire a message14,16if a certain waiting period lapses.

Turning now toFIG. 5, an example of a configuration for a mobile device10is shown. The mobile device10includes one or more communication interfaces46to enable the mobile device10to communicate with other devices, services, and domains, e.g. to communicate via the wireless network12′ shown inFIG. 2. The one or more communication interfaces46in this example generally represents any one or more short-range, wide-area, wired, or wireless communication connections utilizing a connection/connector/port, wireless radio, etc. The mobile device10also includes a display component48, which may be used by various applications and services on the mobile device10including an IM application50in the example shown inFIG. 5. The IM application50is also configured to utilize the one or more communication interfaces46to enable “IMing” on the mobile device10.

The IM application50includes or otherwise has access to an OTR module52for enabling participating in OTR sub-chats within IM conversations54facilitated by the IM application50. An IM storage58may therefore be included or otherwise accessible to the IM application50for storing both IM conversations54and to provide a temporary storage allocation56for OTR messages16. The OTR module52may represent any programming code, instructions, or component of the IM application50that enables an IM conversation54for the IM application50to navigate into and out of an OTR mode using the same interface with particular contacts. It can be appreciated that the delineation between components shown inFIG. 5is for illustrative purposes and various other configurations are possible.

FIG. 6illustrates operations that may be performed for navigating into and out of a private OTR sub-chat with a particular contact, using an IM conversation UI18for that contact. In the example shown inFIG. 6it is assumed that the same device initiates and leaves the OTR mode, however, it will be appreciated that one device may initiate the OTR mode and another leave the OTR mode thus ending the OTR sub-session, as will be explained in greater detail below. At60a user of the first mobile device10ainitiates use of the OTR mode with a user of the second mobile device10b, e.g., by selecting an option from within an IM conversation UI18with the associated contact to create an “invitation” to participate in the private sub-session. The P2P system22delivers an invitation to the second mobile device10bat62, which is received by the second mobile device10bat64. It can be appreciated that the participation by the P2P system22is shown for illustrative purposes and other exchange mechanisms, including direct communications between mobile device10aand mobile device10bare equally applicable within the principles discussed herein.

The second mobile device10btherefore is provided with an opportunity to accept or decline the invitation, which enables both users to decide whether or not they wish to engage in a private discussion. It can be appreciated that while the invitation is pending (i.e. until the invitation has been accepted or declined), regular P2P messages14may be permitted. For example, after receiving the invitation, the second mobile device10bmay wish to send a regular P2P message14to explain why they are about to decline an invitation to participate in the OTR mode. The second mobile device10bin this example accepts the invitation at66triggering an acceptance notification or other message or indicator, and the P2P system22facilitates delivery of an acceptance notification at68, which is received by the first mobile device10aat70. As discussed above, the OTR mode is advantageously provided within the same IM conversation UI18as the regular P2P messaging. At72, the first mobile device10aupdates, modifies or otherwise changes the IM conversation UI18to provide an indication that the OTR mode is active. As discussed in greater detail below, these changes to the IM conversation UI18may include concealing the identity of the contact with which the user is communicating in the OTR mode, e.g., by concealing names, avatars, and other identity-revealing information from being displayed.

Once in the OTR mode, a private OTR message16is sent by the first mobile device10aat74. The private OTR message16in this example is similarly configured as the regular P2P messages14, but identifies as an OTR message16, e.g. by changing a message type or utilizing a particular type of message ID. By identifying the message as an OTR message16, during the OTR mode, the messages being exchanged may be stored in the temporary storage56rather than being persisted with the regular P2P messages14associated with the IM conversation data54for that IM conversation. Similarly, when the P2P system22facilitates delivery of the OTR message16at76, the P2P system22is able to identify that the OTR message16should be handled in a different manner, e.g., to store only temporarily or not at all. The OTR message16is received by the second mobile device10bat78, and in this example, an OTR reply message16is generated and sent at80. The OTR reply message16in this example is made while both the first and second mobile devices10a,10bstay within the OTR mode. As discussed in greater detail below, to maintain secrecy, the IM application50can be configured to automatically end an OTR sub-session and revert to regular messaging upon detecting various events, such as navigating away from the IM conversation UI18, de-selection of an OTR option, etc. In the example shown inFIG. 6, the OTR reply message16is sent while the OTR mode is active, and the P2P system22is able to facilitate delivery of the OTR reply message16at82, and the first mobile device10areceives the OTR reply message16at84. As illustrated by the dotted lines inFIG. 6, OTR messaging may continue until one of the users leaves the OTR mode or another predetermined event is detected by the mobile device10, such as a timeout (e.g., inactivity in the UI for a predetermined amount of time), device shutdown, etc.

The first mobile device10adetects leaving the OTR mode at86, which triggers an OTR session ending notification, delivery of which is facilitated by the P2P system22at88and is received by the second mobile device10band indicated to the associated user at90, e.g., by displaying a message in the IM conversation UI18. By exiting or leaving the OTR mode, the respective IM applications50on the first and second mobile devices10a,10breturn the IM conversation UIs18to their normal or regular state, e.g., by revealing the regular message history, names, avatars, and other identifying information. The sending, delivery of, and receipt of normal P2P messages14may then resume at96,98, and100respectively. As shown by the dashed lines inFIG. 6, subsequent OTR sub-chats may be initiated by subsequent use of the OTR mode. As discussed above, either of the users may initiate OTR sub-chats and the example shown inFIG. 6is only one illustrative scenario.

Entering into and navigating out of the OTR mode may be controlled by the IM application50and OTR module52in order to ensure acceptance by both parties and to allow regular messaging until invitations to enter the OTR mode are accepted.FIG. 7illustrates example operations performed by a requestor to enter the OTR mode, e.g., the first mobile device10ain the scenario shown inFIG. 6. At110selection of an OTR option for an IM conversation54is detected, and an invitation is sent to the contact associated with the IM conversation54at112. The requestor mobile device10displays an invitation notification message at114to identify that an OTR mode request/invitation has been made, e.g. by placing such a notification in a regular P2P message14to be displayed within the regular conversation activity. It can be appreciated that such notifications may be optional and/or may expire after a predetermined amount of time (e.g., after the OTR session ends or is declined) in order to maintain secrecy even of the attempt to have the private sub-chat. Such options may be presented as user preferences or selectable options. As illustrated with dashed lines, normal P2P messages14may be sent and received at116while the requestor mobile device10awaits a reply to the invitation to enter the OTR mode. At118it is determined whether or not the OTR attempt/session has been exited, e.g., if the user navigates away from the IM conversation54in which the invitation has been set. If the user has left the OTR attempt, the invitation is canceled at120. If not, normal messaging may continue at116until a reply message is received at122.

The reply message may include an indication that the invitation has been accepted or declined and the IM application50or OTR module52determines this at124. If the invitation has been declined, a decline notification message is displayed at126and the invitation canceled at120. It can be appreciated that normal IM messaging may continue using the same IM conversation UI18when an invitation is declined and therefore subsequent requests may be detected by returning to110as illustrated in dashed lines. When the invitation has been accepted, the IM conversation UI18is transitioned to the OTR mode at128, which may include concealing visual elements related to the identity of the contact. OTR messages16may then be sent and received at130, e.g., as shown inFIG. 6. As discussed by way of example below, one or more concealment operations may be applied at132to the OTR messages16that are temporarily displayed in the modified IM conversation UI18to add further secrecy to the private conversation. For example, only the most recent OTR message16may be displayed in the clear, with the content of older OTR messages16disappearing after a period of time, being faded as they become older, or otherwise concealed or removed from the display according to predetermined criteria. A mechanism to selectively reveal the content for such concealed OTR messages16can also be provided.

The IM application50or OTR module52determines at134whether or not the user has opted to leave the OTR mode, e.g., by actively cancelling or ending the OTR mode or navigating away from the IM conversation UI18. If the user has left the OTR mode, the IM conversation UI18is transitioned back to its normal state at136, e.g., by revealing the regular P2P messages14and removing the OTR messages16. Regular P2P messages14may then be sent and received at138and the process may repeat if further selections of the OTR option are detected. For example, a user may have several smaller private sub-conversations spaced apart in time from each other by navigating into and out of the OTR mode within the IM conversation UI8for the contact with which they wish to have the private sub-chat.

The IM application50or OTR module52also determines at140whether or not the recipient has left the OTR mode. For example, if the recipient leaves the OTR mode, a notification message would be received by the requestor. If the recipient has not left, OTR messages16may continue to be sent and received at130. If the recipient has left, it is determined at142whether or not the requestor stays in the OTR mode. This may occur if the recipient leaves the OTR mode for a brief period of time and then re-enters OTR mode. In such a scenario, the requestor may stay in the OTR mode during the brief absence while the IM conversation UI18for the recipient transitions out of OTR mode and into normal IM messaging and back again. If the requestor stays in the OTR mode, the IM application50or OTR module52determines at144whether or not the recipient has returned or otherwise re-entered the OTR mode. If so, the requestor may continue to send and receive OTR messages16without having to perform the invitation operations described above. If, however, the requestor leaves OTR mode or the recipient does not return to the OTR mode (e.g., after a particular amount of time), the IM conversation UI18transitions back to normal messaging as described above at136.

FIG. 8illustrates operations that are performed by the recipient of a request to enter the OTR mode. At150an invitation to enter the OTR mode is received by the recipient from within an IM conversation UI18associated with the requestor. An invitation message displayed at152to enable the recipient to accept or decline the invitation and regular P2P messages14may be sent and received at154(illustrated in dashed lines) until an action is taken with respect to the invitation. The IM application50or OTR module52determines at156whether or not the invitation has been accepted by the user associated with the recipient mobile device10. If the invitation is not accepted, decline reply message is sent to the requestor mobile device10at158and a decline notification message may be displayed on the recipient mobile device10at160. As illustrated in dashed lines inFIG. 8, despite declining the invitation, subsequent invitations may be received and the process repeated at a later time.

If the user accepts the invitation at156, an acceptance reply message is sent to the requestor mobile device10at162and the IM conversation UI18is transitioned to the OTR mode at164, similar to what is described above. OTR messages16may then be sent and received at166and the aforementioned concealment operations may be applied at168as discussed above.

The IM application50or OTR module52determines at168whether or not the user has opted to leave the OTR mode, e.g., by actively cancelling or ending the OTR mode or navigating away from the IM conversation UI18. If the user has left the OTR mode, the IM conversation UI18is transitioned back to its normal state at172, e.g., by revealing the regular P2P messages14and removing the OTR messages16. Regular P2P messages14may then be sent and received at174and the process may repeat if further invitations are received. Also, as shown inFIG. 8, the recipient mobile device10may also detect selection of the OTR option at176, e.g., to subsequently re-enter the OTR mode with the same contact (formerly the requestor), at which point the operations shown inFIG. 7may be performed.

The IM application50or OTR module52also determines at178whether or not the requestor has left the OTR mode. For example, if the requestor leaves the OTR mode, a notification message would be received by the recipient. If the requestor has not left, OTR messages16may continue to be sent and received at166. If the requestor has left, it is determined at180whether or not the recipient stays in the OTR mode. This may occur if the requestor leaves the OTR mode for a brief period of time and then re-enters OTR mode. In such a scenario, the recipient may stay in the OTR mode during the brief absence while the IM conversation UI18for the requestor transitions out of OTR mode and into normal IM messaging and back again. If the recipient stays in the OTR mode, the IM application50or OTR module52determines at182whether or not the requestor has returned or otherwise re-entered the OTR mode. If so, the recipient may continue to send and receive OTR messages16without having to perform the invitation operations described above. If, however, the recipient leaves OTR mode or the requestor does not return to the OTR mode (e.g., after a particular amount of time), the IM conversation UI18transitions back to normal messaging as described above at172.

FIG. 9illustrates operations that may be performed by the IM application50or OTR module52in handling messages upon a transition from regular IM messaging to OTR messaging. At186the IM application50or OTR module52detects entry into the OTR mode and changes a message type for sent or received messages from the associated contact at188, during the OTR mode. In the example described herein, OTR messages16are therefore used during the OTR mode and are stored in the temporary storage56at190. The IM application50or OTR module52determines at192whether or not the user has left the OTR mode. If not, the message type continues to be changes and OTR messages16stored at188and190. Once the user has left the OTR mode, normal messaging resumes at194, in which normal P2P messages14are used and stored as the IM application50normally would.

In addition to displaying P2P messages14,16in the IM conversation UI18, notifications may also be displayed by the mobile device10, e.g., to indicate that a message14,16has been received, including messages14inviting a user to chat in the OTR mode.FIG. 10illustrates operations that may be performed by the IM application50or other application or service on the mobile device10for handling notifications during use of the OTR mode. At196receipt of an OTR message16is detected and information in a corresponding message notification is concealed at198. For example, as described below, the sender and/or content that would normally be displayed in the notification, as well as other message preview content, can be removed to maintain secrecy of the private messaging. In other words, regular notifications can be modified to inform the use of the new “invitation” to chat privately, without explicitly revealing its context or underlying sensitive information. A modified message notification is then displayed at200.

Turning now toFIGS. 11 to 39, various screen shots are provided to illustrate navigation into and out of the OTR mode from the perspective of the requestor and the recipient of an invitation to participate in a private OTR sub-chat.

InFIG. 11, an IM conversation UI300is shown which includes an OTR option302, which enables a user to enter an OTR mode with the associated contact for that conversation, in this example, Contact A. By selecting the OTR option302as shown inFIG. 11, an invitation notification message304is displayed in the IM conversation UI300for the requestor as shown inFIG. 12. The notification message304includes a Cancel option306to enable the requestor to cancel the invitation request while the invitation is pending. The recipient of the invitation is the associated contact for the IM conversation UI300. An IM conversation UI310for the recipient (i.e. Contact A in this example) is shown inFIG. 13. The recipient IM conversation UI310displays an invitation message312that includes a decline option314to enable the recipient to decline the invitation, and an accept option316to enable the recipient to accept the invitation and enter a private OTR sub-chat. While the invitation is pending, normal P2P messages14can be sent or received, e.g., as shown inFIG. 14in which the recipient sends a message318to User indicating that they are unable to enter the OTR mode at that time.

To avoid the recipient of the invitation accepting the invitation only to find that the requestor has left the chat, the requestor may be committed to staying within the IM conversation UI300until the recipient responds. For example, as shown inFIG. 15, upon selecting the Cancel option306, or navigating away from the IM conversation UI300by selecting a Back option320or re-selecting (or de-deselecting) the OTR option302. As shown inFIG. 16, the recipient may also decline the invitation by selecting the decline option314.FIGS. 17 and 18illustrate invitation request decline messages322and324that are displayed to the requestor and the recipient respectively after the invitation is canceled or declined. As shown inFIGS. 17 and 18, the decline messages322,324may be generated by replacing the Cancel option306, decline option314, and accept option316with notifications, in this example “REQUEST DECLINED”.

As shown inFIGS. 19 and 20, if the recipient accepts the invitation request, entry mechanisms330,332may be displayed on the requestor IM conversation UI300and recipient IM conversation UI310respectively to enable the users to enter the OTR mode. In the example shown inFIGS. 19 and 20, a set of arrows is displayed which may be swiped upwardly to transition the IM conversation UI300,310into an OTR screen340as shown inFIG. 21. As can be seen inFIG. 21, the OTR screen340is a modified version of an IM conversation screen300,310wherein identifying information is removed (e.g., header with name, avatar, etc.), the message area342is cleared, an explanation message344is displayed, and wherein a messaging option portion346remains the same. The OTR screen340may also be configured as an overlay that is displayed on top of the IM conversation UI300,310to obscure viewing of the IM conversation UI300,310while the OTR mode is being used. Although not shown inFIG. 21, the OTR screen340may also be overlaid such that a small portion of the IM conversation UI300,310(e.g., an outermost border) is visible such that the UI appears as a private conversation within a regular conversation with one or more contacts. As such, messages can be composed and sent to the other correspondent as if a normal IM conversation was taking place, thus providing the familiarity of the normal messaging environment while providing additional security and privacy. Also, as shown inFIG. 21, the regular conversation messages have been removed with only the OTR portion of the conversation (i.e. the OTR sub-chat) being displayed.

FIG. 22illustrates an OTR screen340in which various OTR messages348are displayed. A concealment mechanism350such as blurring or fading (or removal) is applied to the avatar normally displayed with the message to identify the other correspondent. Similarly, the name of the other correspondent can be removed. The IM application50or OTR module52can also be configured to enable or disable various features normally provided within an IM conversation. For example, as shown inFIG. 22, photo messages may be supported along with the ability to send text, voice notes, and video. As discussed above, while messages may be sent, received, and accumulate within the OTR screen340, by navigating away from the OTR screen340, the private OTR messages348are deleted and irretrievable to maintain the secrecy of the private sub-chat.

The number of messages348displayed in an OTR screen340may be limited such that after a predetermined number of messages348accumulate, the oldest one(s) is/are deleted. Also, as shown inFIG. 23, messages348may begin to fade or become obscured as they move towards the top of the visible portion of the OTR conversation leaving an obscured message354on the display. It can be appreciated that while fading is applied to only the topmost message inFIG. 23, a gradient of fading could also be applied to all messages except the most recent, and/or fading can gradually become more obscure as time elapses. To avoid the contents of the private sub-chat being copied to device memory, the ability to take screen shots can be disabled during OTR mode. As shown inFIG. 24, a system notification356may be displayed upon detecting an attempt to take a screen shot. The OTR mode may also prohibit certain message types and/or attachment types (e.g., documents, etc.). If a user attempts to send such an unsupported message or attachment type, a dialogue360may be displayed as shown inFIG. 25prompting the user to leave OTR mode in order to send such a message or attachment type.

Turning now toFIG. 26, as discussed above, navigating away from the OTR screen340triggers leaving the OTR mode, e.g., by selecting the back option320or the OTR option302as shown inFIG. 26. By selecting the back option320, the user is navigated back to a conversation list UI370as shown inFIG. 27. To re-enter the normal IM conversation UI300, the user selects the Contact A entry372in the conversation list, bringing the user back to the IM conversation UI300shown inFIG. 11. By selecting the OTR option302, the user is directed directly back into the IM conversation UI300shown inFIG. 11.

When a user leaves the OTR mode, the other correspondent can be notified of the departure, e.g., as shown inFIG. 28in which a system notification message380is displayed indicating that the other participant has left OTR mode and the corresponding time. In one example, the OTR screen340as shown inFIG. 28can be configured to automatically transition back to the regular IM conversation UI300as shown inFIG. 29, after a timeout period elapses. Alternatively, the OTR screen340can remain displayed for the user that did not leave the OTR mode until that user navigates away from the OTR screen340. In this way, the other correspondent may be given the ability to leave and return to OTR mode without forcing the remaining correspondent to redo the invitation opt-in process discussed above.

FIG. 30illustrates an OTR screen in which a first system message380indicates that the other participant has left OTR mode, but since the user stays in the OTR screen340, upon the other participant re-entering OTR mode, a second system message400is displayed rather than a second invitation. Subsequent OTR messages450may then be sent and received to carry on the private sub-chat. It can be appreciated that since the OTR-based conversation would be deleted by the IM application50or OTR module52for the participant that left the OTR mode, the OTR message history can be made irretrievable for re-entering participants to avoid unnecessary sharing of the sensitive content. It can be appreciated however, that it at least some examples, a participant that does not leave OTR mode can be relied upon to re-send the OTR message history. The remaining participant may also be forced to leave the OTR mode after a predetermined amount of time, e.g., 60 seconds. Within that time frame, the user who has left can re-enter OTR mode and continue the conversation without going through the invitation flow again, but may not have the message history due to the navigation out of and then back into the OTR mode. Such re-entry navigations accommodate temporary multi-tasking, e.g., to answer an incoming phone call, without requiring a complete re-application of the invitation flow.

As discussed above in connection withFIG. 10, a notification520associated with a private OTR message16may be modified to remove at least the content that would normally be displayed, e.g., in a home screen500as shown inFIG. 31. In this way, the notification can continue to have the desired impact of indicating that a new message (e.g., invitation to enter the OTR mode) has been received, but without revealing the contents of the message outside of the OTR environment.

FIGS. 32 to 39illustrate various additional ways of concealing OTR messages16in the form displayed within the OTR screen340.FIG. 32illustrates hidden messages550that can be dragged or “pulled” outwardly to reveal the contents of the message. InFIG. 32, the second-to-most recent message552is dragged outwardly using a left-to-right swipe gesture554. As shown inFIG. 33the same message552can be pushed back to a hidden position using a right-to-left swipe gesture558.FIG. 34illustrates that faded messages610can be revealed by applying an input to a desired one of the faded messages610, in this example a tap-and-hold input620. After tapping and holding for a predetermined amount of time, the previously faded message becomes a revealed message630as shown inFIG. 35. The revealed message630returns to being a faded message610after a predetermined amount of time, or by re-applying the tap-and-hold gesture, to return to the OTR screen340shown inFIG. 36. As noted above, messages in the conversation UI340can be configured to disappear after a period of time such that any given message is only displayed for a relatively short period of time. The expiration of such messages can also be combined with fading during the period of time during which the message is displayed.

In yet another example shown inFIGS. 37-39, the contents of the message can also be encoded to create scrambled content710within a concealed message700. The concealed message can also include a “read” bar720that can be pulled or swiped730across the scrambled content710to generate decoded content740as shown inFIG. 38. Upon reaching the other end of the message700, the complete content is revealed, e.g., for a predetermined amount of time, until detecting a reverse gesture applied to the read bar720, etc.

For messages containing other types of media, such as voice or video messages, concealment methods can also be applied, e.g., by performing masking to any identifying features. For example, a voice message can be modified to conceal or mask the pitch and timber of the voice to obscure the identity of the creator of the voice message. Similarly, for video messages, the face and/or other identifying features of the participant shown in the video can be obscured by blurring, fading, etc. Additionally, techniques to mask the accompanying voice can also be applied.

It can therefore be seen that various mechanisms may be applied to the OTR messages16as displayed in order to enhance the privacy of the OTR sub-chat to not only prevent persisting such messages, but also limiting the exposure of the contents of the displayed messages.

Referring toFIG. 40, to further aid in the understanding of the example mobile devices10described above, shown therein is a block diagram of an example configuration of a device configured as a “mobile device”, referred to generally as “mobile device10”. The mobile device10includes a number of components such as a main processor802that controls the overall operation of the mobile device10. Communication functions, including data and voice communications, are performed through at least one communication interface46. The communication interface46receives messages from and sends messages to a wireless network12′. In this example of the mobile device10, the communication interface46is configured in accordance with the Global System for Mobile Communication (GSM) and General Packet Radio Services (GPRS) standards, which is used worldwide. Other communication configurations that are equally applicable are the 3G and 4G networks such as Enhanced Data-rates for Global Evolution (EDGE), Universal Mobile Telecommunications System (UMTS) and High-Speed Downlink Packet Access (HSDPA), Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (Wi-Max), etc. New standards are still being defined, but it is believed that they will have similarities to the network behavior described herein, and it will also be understood by persons skilled in the art that the examples described herein are intended to use any other suitable standards that are developed in the future. The wireless link connecting the communication interface46with the wireless network12′ represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for GSM/GPRS communications.

The main processor802also interacts with additional subsystems such as a Random Access Memory (RAM)806, a flash memory808, a touch-sensitive display860, an auxiliary input/output (I/O) subsystem812, a data port814, a keyboard816(physical, virtual, or both), a speaker818, a microphone820, a GPS receiver821, a front camera817, a rear camera819, short-range communications subsystem822, and other device subsystems824. Some of the subsystems of the mobile device10perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. By way of example, the touch-sensitive display860and the keyboard816may be used for both communication-related functions, such as entering a text message for transmission over the wireless network12′, and device-resident functions such as a calculator or task list. In one example, the mobile device10can include a non-touch-sensitive display in place of, or in addition to the touch-sensitive display860. For example the touch-sensitive display860can be replaced by a display48that may not have touch-sensitive capabilities.

The mobile device10can send and receive communication signals over the wireless network12′ after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the mobile device10. To identify a subscriber, the mobile device10may use a subscriber module component or “smart card”826, such as a Subscriber Identity Module (SIM), a Removable User Identity Module (RUIM) and a Universal Subscriber Identity Module (USIM). In the example shown, a SIM/RUIM/USIM826is to be inserted into a SIM/RUIM/USIM interface828in order to communicate with a network.

The mobile device10is typically a battery-powered device and includes a battery interface832for receiving one or more rechargeable batteries830. In at least some examples, the battery830can be a smart battery with an embedded microprocessor. The battery interface832is coupled to a regulator (not shown), which assists the battery830in providing power to the mobile device10. Although current technology makes use of a battery, future technologies such as micro fuel cells may provide the power to the mobile device10.

The mobile device10also includes an operating system834and software components836to842,50and58. The operating system834and the software components836to842,50and58, that are executed by the main processor802are typically stored in a persistent store such as the flash memory808, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system834and the software components836to842,50and58, such as specific device applications, or parts thereof, may be temporarily loaded into a volatile store such as the RAM806. Other software components can also be included, as is well known to those skilled in the art.

The subset of software applications836that control basic device operations, including data and voice communication applications, may be installed on the mobile device10during its manufacture. Software applications may include a message application838, a device state module840, a Personal Information Manager (PIM)842, an IM application50, and an IM message storage58. A message application838can be any suitable software program that allows a user of the mobile device10to send and receive electronic messages, wherein messages are typically stored in the flash memory808of the mobile device10. A device state module840provides persistence, i.e. the device state module840ensures that important device data is stored in persistent memory, such as the flash memory808, so that the data is not lost when the mobile device10is turned off or loses power. A PIM842includes functionality for organizing and managing data items of interest to the user, such as, but not limited to, e-mail, contacts, calendar events, and voice mails, and may interact with the wireless network12′.

Other types of software applications or components839can also be installed on the mobile device10. These software applications839can be pre-installed applications (i.e. other than message application838) or third party applications, which are added after the manufacture of the mobile device10. Examples of third party applications include games, calculators, utilities, etc.

The additional applications839can be loaded onto the mobile device10through at least one of the wireless network16′, the auxiliary I/O subsystem812, the data port814, the short-range communications subsystem822, or any other suitable device subsystem824.

The data port814can be any suitable port that enables data communication between the mobile device10and another computing device. The data port814can be a serial or a parallel port. In some instances, the data port814can be a Universal Serial Bus (USB) port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery830of the mobile device10.

For voice communications, received signals are output to the speaker818, and signals for transmission are generated by the microphone820. Although voice or audio signal output is accomplished primarily through the speaker818, the display48can also be used to provide additional information such as the identity of a calling party, duration of a voice call, or other voice call related information.

The touch-sensitive display860may be any suitable touch-sensitive display, such as a capacitive, resistive, infrared, surface acoustic wave (SAW) touch-sensitive display, strain gauge, optical imaging, dispersive signal technology, acoustic pulse recognition, and so forth, as known in the art. In the presently described example, the touch-sensitive display860is a capacitive touch-sensitive display which includes a capacitive touch-sensitive overlay864. The overlay864may be an assembly of multiple layers in a stack which may include, for example, a substrate, a ground shield layer, a barrier layer, one or more capacitive touch sensor layers separated by a substrate or other barrier, and a cover. The capacitive touch sensor layers may be any suitable material, such as patterned indium tin oxide (ITO).

The display48of the touch-sensitive display860may include a display area in which information may be displayed, and a non-display area extending around the periphery of the display area. Information is not displayed in the non-display area, which is utilized to accommodate, for example, one or more of electronic traces or electrical connections, adhesives or other sealants, and protective coatings, around the edges of the display area.

One or more touches, also known as touch contacts or touch events, may be detected by the touch-sensitive display860. The processor802may determine attributes of the touch, including a location of a touch. Touch location data may include an area of contact or a single point of contact, such as a point at or near a center of the area of contact, known as the centroid. A signal is provided to the controller866in response to detection of a touch. A touch may be detected from any suitable object, such as a finger, thumb, appendage, or other items, for example, a stylus, pen, or other pointer, depending on the nature of the touch-sensitive display860. The location of the touch moves as the detected object moves during a touch. One or both of the controller866and the processor802may detect a touch by any suitable contact member on the touch-sensitive display860. Similarly, multiple simultaneous touches, are detected.

In some examples, an optional force sensor870or force sensors is disposed in any suitable location, for example, between the touch-sensitive display860and a back of the mobile device10to detect a force imparted by a touch on the touch-sensitive display860. The force sensor870may be a force-sensitive resistor, strain gauge, piezoelectric or piezoresistive device, pressure sensor, or other suitable device.

The steps or operations in the flow charts and diagrams described herein are just for example. There may be many variations to these steps or operations without departing from the principles discussed above. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.