Source: http://www.google.com/patents/US8010098?dq=6,455,937
Timestamp: 2016-06-01 00:39:22
Document Index: 358862609

Matched Legal Cases: ['Application No. 2', 'Application No. 05107028', 'Application No. 07112334', 'Application No. 05107028', 'Application No. 07112334', 'Application No. 05107028']

Patent US8010098 - Device and method for generating user notifications associated with tasks ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA device and method for generating user notifications associated with tasks that are pending completion on a mobile device. When additional input is required from a user of the mobile device to complete performance of a task and is not being received from the user within a predefined time period, at...http://www.google.com/patents/US8010098?utm_source=gb-gplus-sharePatent US8010098 - Device and method for generating user notifications associated with tasks that are pending completionAdvanced Patent SearchPublication numberUS8010098 B2Publication typeGrantApplication numberUS 12/758,254Publication dateAug 30, 2011Filing dateApr 12, 2010Priority dateJul 29, 2005Fee statusPaidAlso published asUS7697926, US8577357, US20070036300, US20100197292, US20110294471Publication number12758254, 758254, US 8010098 B2, US 8010098B2, US-B2-8010098, US8010098 B2, US8010098B2InventorsMichael K. Brown, Michael S. Brown, Michael G. KirkupOriginal AssigneeResearch In Motion LimitedExport CitationBiBTeX, EndNote, RefManPatent Citations (13), Non-Patent Citations (7), Referenced by (1), Classifications (7), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetDevice and method for generating user notifications associated with tasks that are pending completion
US 8010098 B2Abstract
A device and method for generating user notifications associated with tasks that are pending completion on a mobile device. When additional input is required from a user of the mobile device to complete performance of a task and is not being received from the user within a predefined time period, at least one form of user notification is generated. The particular form or forms of user notification are defined by a user profile associated with the user. User notifications may comprise visual, audible, and/or vibratory alerts, and different forms of these user notifications may be generated in a sequence. The volume of audible alerts or the period between periodic user notifications may vary over time.
1. A method of generating user notifications on a mobile device, the method comprising:
receiving user input to initiate processing of a message on the mobile device, wherein the processing comprises encrypting and sending the message to one or more recipients;
determining if a processor of the mobile device is awaiting additional user input to process the message;
determining that the additional user input is not required immediately after the receiving;
upon determining that the processor is awaiting additional user input to process the message, after determining that the additional user input is not required immediately after the receiving, prompting for the additional user input;
determining if the additional user input is not received within a predefined time period; and
generating at least one form of user notification if the additional user input is not received within the predefined time period.
2. The method of claim 1, wherein the generating is repeated until the additional input is received.
3. The method of claim 1, wherein the at least one form of user notification is generated periodically.
4. The method of claim 3, wherein the period at which the at least one form of user notification is generated varies.
5. The method of claim 1, wherein the at least one form of user notification is generated until a second predefined time period has elapsed.
6. The method of claim 1, wherein the at least one form of user notification is generated in accordance with a user profile.
7. The method of claim 6, wherein the user profile defines the at least one form of user notification that is to be generated based on a state of the mobile device.
8. The method of claim 7, wherein the state of the mobile device is a state selected from the following group: the mobile device is in a cradle; the mobile device is in a holster; and the mobile device is neither in a cradle nor in a holster.
9. The method of claim 6, wherein the user profile defines a plurality of forms of user notification that is to be generated in a sequence.
10. The method of claim 1, wherein the at least one form of user notification consists of at least one of the following: a visual alert, an audible alert, and a vibratory alert.
11. The method of claim 1, wherein at least one form of user notification varies over time.
12. The method of claim 1, wherein the processing of the message comprises encoding the message using PGP.
13. The method of claim 1, wherein the processing of the message comprises encoding the message using S/MIME.
14. A non-transitory computer-readable storage medium upon which a plurality of instructions are stored, the instructions, which when executed by a processor, cause the processor to:
receive user input to initiate processing of a message on a mobile device, wherein the processing comprises encrypting and sending the message to one or more recipients;
determine if the processor is awaiting additional user input to process the message;
wherein the processor determines that the additional user input is not required immediately after receiving the user input to initiate processing of the message on the mobile device;
prompt for the additional user input, upon determining that the processor is awaiting additional user input to process the message, after determining that the additional user input is not required immediately after receiving the user input to initiate processing of the message on the mobile device;
determine if the additional user input is not received within a predefined time period; and
generate at least one form of user notification if the additional user input is not received within the predefined time period.
15. A mobile device comprising a processor, wherein the processor is configured to:
determine if the processor is awaiting additional user input is to process the message;
prompt for the additional user input, upon determining that the processor is awaiting additional user input is to process the message, after determining that the additional user input is not required immediately after receiving the user input to initiate processing of the message on the mobile device;
16. The device of claim 15, wherein the processor is configured to generate the at least one form of user notification in accordance with a user profile.
17. The device of claim 16, wherein the user profile defines the at least one form of user notification that is to be generated based on a state of the mobile device.
18. The device of claim 17, wherein the state of the mobile device is a state selected from the following group: the mobile device is in a cradle; the mobile device is in a holster; and the mobile device is neither in a cradle nor in a holster.
19. The device of claim 16, wherein the user profile defines a plurality of forms of user notification that is to be generated in a sequence.
means for receiving user input to initiate processing of a message on the mobile device, wherein the processing comprises encrypting and sending the message to one or more recipients;
means for determining if additional user input is being awaited to process the message;
means for determining that the additional user input is not required immediately after receiving the user input to initiate processing of the message on the mobile device;
means for prompting for the additional user input, upon determining that the additional user input is being awaited to process the message, after determining that the additional user input is not required immediately after the receiving;
means for determining if the additional user input is not received within a predefined time period; and
means for generating at least one form of user notification if the additional user input is not received within the predefined time period.
This application is a continuation of prior U.S. patent application Ser. No. 11/192,264, filed on Jul. 29, 2005, the entirety of which is hereby incorporated by reference.
Embodiments of the invention relate generally to mobile devices and methods for generating user notifications thereon.
When a user wishes to send a message from a mobile device that he or she has composed, such as an electronic mail (“e-mail”) message for example, the user will typically provide some input to the mobile device through the user interface of a messaging application in order to initiate the processing of the message for sending. For instance, the user may select a “send” button or menu option to send the message. Once this selection is made, users generally expect that unless an error message is generated and displayed to them immediately, the message will automatically be sent with no further input or other user intervention required.
When a message is sent by a user that is to be encoded using a secure messaging protocol, such as the Secure Multiple Internet Mail Extensions (“S/MIME”) protocol, or the Pretty Good Privacy™ (PGP) protocol or a variant thereof for example, a number of processing actions may need to take place before the message can actually be sent to its intended destination. For example, it may be necessary for the messaging application to request an update of a security policy from a policy engine (e.g. as implemented in a PGP Universal Server). This security policy dictates the particular encoding that is to be applied to a message. As a further example, it may be necessary for the messaging application to obtain an S/MIME certificate or a PGP key from a local store or a remote server before a message is encoded and sent. It may also be necessary for the messaging application to verify the status of a particular S/MIME certificate before the message is encoded and sent.
Should the messaging application encounter any problems when performing the processing actions for a message or require further input from the user before it can complete the processing of the message for sending, the mobile device may prompt the user for additional information or prompt the user to make a decision as to what should be done with the message. For example, if the messaging application is unable to verify the status of a certain certificate required to encode a message, the user may be asked to decide whether the message should be sent without encoding.
Unfortunately, it may take some time after the user initiates the processing of the message for sending before a problem is identified. Meanwhile, the user may have assumed that the message would be sent, and consequently, the user may no longer be paying attention to the mobile device. In particular, the user may have placed the mobile device into a belt holster, in a cradle, or in some other location (e.g. left on a desk), such that the mobile device is left unattended. In those cases, the user may not be aware that additional input is required before the mobile device will actually send the message.
FIG. 5 is a flowchart illustrating steps in a method of generating user notifications associated with tasks pending completion on a mobile device, in accordance with a number of example embodiments.
Further to the example provided above, if a messaging application encounters any problems when performing certain processing actions for a message that the user has directed the application to send, or if the application requires additional input from the user before it can complete the processing of the message for sending, it may be necessary to regain the attention of the user who may have left the mobile device unattended.
More generally, whenever a user initiates performance of any task on the mobile device that he or she expects to be automatically performed without the need for additional input or user intervention, it may be necessary to subsequently regain the attention of the user who may have left the mobile device unattended, so that the user can be notified that additional input is required before performance of the task can be completed.
Embodiments described herein relate generally to a device and methods in which the user is notified that additional input is required before performance of the task can be completed.
In one broad aspect, there is provided a method of generating user notifications associated with tasks that are pending completion on a mobile device, the method comprising the steps of: receiving input from a user to initiate performance of a task on the mobile device; and when additional input is required to complete performance of the task, prompting the user for the additional input, determining if the additional input is not being received from the user within a predefined time period, and generating at least one form of user notification as defined by a user profile associated with the user, if the additional input is not being received from the user within the predefined time period.
Embodiments described herein make reference to a mobile device. A mobile device is a two-way communication device with advanced data communication capabilities having the capability to communicate with other computer systems. A mobile device may also include the capability for voice communications. Depending on the functionality provided by a mobile device, it may be referred to as a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance, or a data communication device (with or without telephony capabilities). A mobile device communicates with other devices through a network of transceiver stations.
Certificates may be used in the processing of encoded messages, such as e-mail messages, that are encrypted and/or signed, in accordance with certain secure messaging protocols. While Simple Mail Transfer Protocol (SMTP), RFC822 headers, and Multipurpose Internet Mail Extensions (MIME) body parts may be used to define the format of a typical e-mail message not requiring encoding, Secure/MIME (S/MIME), a version of the MIME protocol, may be used in the communication of encoded messages (i.e. in secure messaging applications). S/MIME enables end-to-end authentication and confidentiality, and provides data integrity and privacy from the time an originator of a message sends a message until it is decoded and read by the message recipient. Other standards and protocols may be employed to facilitate secure message communication, such as Pretty Good Privacy™ (PGP) and variants of PGP such as OpenPGP, for example. It will be understood that where reference is generally made to “PGP” herein, the term is intended to encompass any of a number of variant implementations based on the more general PGP scheme.
In the example shown in FIG. 4, a policy engine 290 resides in LAN 250. The policy engine 290 may be provided by way of a PGP Universal Server developed by PGP Corporation. This is only one example. The policy engine may be implemented in some other device or construct other than a PGP Universal Server, and may be applied in the context of protocols other than PGP (e.g. in an S/MIME policy engine).
A PGP Universal Server 290 is adapted to communicate with a user's desktop computer (e.g. 262 a) and the user's mobile device (e.g. 100 via message management server 272), and may be further adapted to encrypt messages and enforce compliance of security requirements with respect to messages being sent by the user, based on security policies established by an administrator, for example. The placement of PGP Universal Server 290 in LAN 250 as shown in FIG. 4 is provided by way of example only, and other placements and configurations are possible. Depending on the placement of the PGP Universal Server 290 and the particular configuration of LAN 250 in which PGP Universal Server 290 may be employed, the level of control over processed messages that are subject to security encoding, and in particular, over messages being sent by a user may vary.
For example, PGP Universal Server 290 may be adapted to directly process all outgoing messages (i.e. messages being sent by the user from the user's desktop computer, mobile device, or other computing device to one or more intended recipients), where it will make decisions on which messages to encrypt and/or sign, if at all, in accordance with policies defined on the PGP Universal Server 290 as configured by the administrator. If a security policy dictates that a message about to be sent by the user to a particular domain or pertaining to a particular subject is to be encrypted and signed using PGP for example, the PGP Universal Server 290 may itself encrypt and sign the message before transmission.
Referring now to FIG. 5, a flowchart illustrating steps in a method of generating user notifications associated with tasks pending completion on a mobile device, in accordance with a number of example embodiments, is shown generally as 300.
Steps of method 300 are performed by an application executing and residing on the mobile device (e.g. mobile device 100 of FIG. 4). The application may be an e-mail or other messaging application, another application coupled to or otherwise integrated with the e-mail or other messaging application (e.g. an add-on component providing the requisite functionality), or some other application programmed to perform such steps.
In embodiments of method 300, the user is notified that additional input is required before performance of a task can be completed. Generally, whenever a user initiates performance of a task on the mobile device that he or she expects to be automatically performed without the need for additional input or user intervention, it may be necessary to subsequently regain the attention of the user who may have left the mobile device unattended.
At step 310, input to initiate performance of a task on a mobile device is received from a user of the mobile device.
By way of example, in one embodiment, the task comprises processing a message (e.g. an e-mail message) composed by the user. The user may wish to send the message securely (e.g. encrypted and/or signed), or a message encoding may be suggested or enforced by a policy engine (e.g. as implemented in a PGP Universal Server 290 of FIG. 4). The user may wish to have the message sent to one or more recipients, and may provide the messaging application with a direction that the message is to be sent, by selecting a “send” button or menu option, for example. When the direction is received by the messaging application, processing of the message for sending is initiated.
Typically, unless an error is detected by the messaging application immediately after the direction is received and the user is notified of the error, the user may assume that the message will be sent without the need for additional input or user intervention. Subsequently, the user may leave the mobile device unattended in a holster (e.g. a belt holster), in a cradle (e.g. cradle 264 of FIG. 4), or in some other location (e.g. desk, pocket, bag, etc.), for example.
At step 320, if in the process of performing the task, additional input is required to complete performance of the task initiated at step 310, the user is prompted for the additional input.
With reference to the above-mentioned example, consider the situation where a message composed by the user is to be encrypted and sent to one or more recipients. The certificate (which may, for example, be a S/MIME certificate or a PGP key) of each recipient to which the message is to be encrypted is required. Therefore, the processing of the message composed by the user will require a number of actions to be performed, which may include searching for and retrieving the requisite certificate(s) from a local or remote certificate/key store or certificate server (e.g. LDAP server 284 of FIG. 4), and verifying the status of the certificate (which may include, for example, verifying certificate validity/expiry, revocation status, key strength, and/or trust status), for example.
Processing of the message may also require that a correct password be obtained from the user as input, as may be required when an attempt to access a certificate in certain protected certificate/key stores on the mobile device is made.
Processing of the message may comprise performing actions that require additional input from the user before the processing of the message for sending can be completed other than those described above, by way of example.
The additional input required to complete the processing of the message may be in the form of input indicating the response to a question that has been posed to a user. For example, in processing the message, the requisite certificate associated with a potential recipient may be determined to be “not trusted”. The messaging application can prompt the user for input indicating whether or not the user still wishes to proceed with sending the message, despite the fact that a certificate that is not trusted would be used to encrypt the message. As a further example, in processing the message, multiple certificates for a given potential recipient may have been located, any of which might be used to encrypt the message. The messaging application may need to prompt the user for additional input indicating which of the located certificates should be used to encrypt the message.
When the user is prompted for additional input at step 320, the messaging application is adapted to wait for a response from the user. Progress in the performance of the task (e.g. further processing of the message) may be temporarily suspended until the additional input is received from the user. Alternatively, other actions may be completed in the background while a response from the user is pending.
If the user is operating the mobile device and notices the prompt, the user may begin to provide the required additional input immediately. However, if the user is not operating the device and has left the mobile device unattended, the user may not notice the prompt. The latter situation may be more likely to occur when the messaging application is unable to determine that additional input is required immediately after the user initiates the task.
For example, when a message is to be encoded using PGP in accordance with a security policy, and where security policy data must first be downloaded from a policy engine (e.g. as implemented in a PGP Universal Server 290 of FIG. 4), there may be a delay between the time the user directed the message to be sent, and the time when the security policy data is retrieved. The reporting of problems arising in the retrieval of security policy data, or of any problems that may arise from actions to be performed after the retrieval of such data, may consequently be delayed. If additional input is required from the user in order to determine how these problems should be overcome, the user is not likely to be prompted for the additional input immediately after the user directs the message to be sent. By the time the messaging application determines that additional input is required, the user may have since left the mobile device unattended.
At step 330, a determination is made as to whether additional input is not being received from the user within a predefined time period. The predefined time period establishes how long the messaging application will wait before proceeding to generate user notifications if the user is not in the process of responding to the prompt. For example, once the user is prompted for the additional input at step 320 (e.g. via a window appearing in a display of the mobile device), the messaging application may allow 30 seconds (or some other length of time) to elapse. If the user has not attempted to respond to the prompt in this period, user notifications will then be generated (step 340).
The predefined time period may be fixed by the messaging application, or it may be configurable by the user by modifying a setting in device preferences or in a user profile, for example. As a further example, the predefined time period may be set in accordance with an IT policy governing use of the mobile device.
If the additional input is received or is at least in the process of being received from the user within the predefined time period (e.g. the user may be scrolling through a number of selections or entering data on the keyboard, and therefore, is in the process of responding to the prompt and need not be further notified), then the flow of method steps proceeds to step 350, wherein progress in the performance of the task can continue upon receipt of the additional input.
However, if the additional input is not being received from the user within the predefined time period, then it is likely that the user is no longer attending to or otherwise paying attention to the device. Meanwhile, completion of the task initiated at step 310 remains pending.
Accordingly, at step 340, at least one form of user notification is generated, in order to regain the attention of the user so that the user can respond to the prompt for additional input.
The at least one form of user notification generated at step 340 may continue to be generated until the additional input is being received by the user (i.e. the user begins to respond to the prompt).
The messaging application may also be adapted to generate the at least one form of user notification until a second predefined time period has elapsed, after which completion of the task may remain pending, or performance of the task, cancelled. For example, if after two minutes (or some other period of time) the user has still not responded to the prompt, it may be that the user is away from the mobile device and is not receiving the notifications. The generation of notifications may be suspended temporarily and subsequently continued at a later time, or performance of the task may be cancelled altogether.
The second predefined time period may be fixed by the messaging application, or it may be configurable by the user by modifying a setting in device preferences or in a user profile, for example. As a further example, the second predefined time period may be set in accordance with an IT policy governing use of the mobile device.
The at least one form of user notification is generated at step 340 as defined by a user profile associated with the user. Accordingly, a flexible notification system tied to a user's profile is provided. For example, a user profile may define certain alert settings, associated with different environments or desired privacy levels (e.g. “Quiet” mode, “Outdoors” mode, etc.). The forms of user notification to be generated at step 340 are configured to be dependent on the user profile and the alert setting currently enabled by the user.
In one embodiment, the at least one form of user notification generated at step 340 is based on a state of the mobile device. For example, different forms of user notification may be generated when the mobile device is in a cradle (e.g. cradle 264 of FIG. 4), when the mobile device is in a holster, and when the mobile device is neither in a cradle nor in a holster.
A number of different forms of user notification may be generated in various embodiments. One form of a user notification that may be employed is a visual alert. A flashing LED indicator on the mobile device may provide the visual alert, for example. Another form of a user notification that may be employed is an audible alert. The audible alert may be provided by a “beep” noise, an audio tone, or a musical tone, for example. Another form of a user notification that may be employed is a vibratory alert. The vibratory alert will cause the mobile device to physically vibrate. Other forms of user notification may be employed in variant embodiments.
Furthermore, successively generated alerts may vary over time. For instance, the color or flashing rate of a visual alert may be varied. Audible alerts may vary in volume (e.g. the volume of audible alerts may escalate over time). The force with which a mobile device vibrates may be varied.
In at least one embodiment, the at least one form of user notification generated at step 340 is generated periodically. For example, an audible alert (e.g. “beep”) may be generated every two seconds (or some other period). Furthermore, the period at which user notifications are generated may also vary. For example, an audible alert may initially be generated every 10 seconds (or some other period) over a certain length of time, with subsequent alerts being generated at a faster rate, until an audible alert is generated every second (or some other period).
In one embodiment, the at least one form of user notification generated at step 340 comprises multiple forms of user notification that are to be generated in sequence. Put another way, the user profile may be customized such that the user notifications change in type over time. For example, when user notifications are to be generated at step 340, a number of visual alerts may first be generated, followed by a number of vibratory alerts, and finally followed by a number of audible alerts. This represents a sequence in which the noise created by each of the different forms of user notification escalates over time.
It will be understood that some or all of the features of the various embodiments described above may be combined in a given implementation. For example, when the additional input is not being received from the user within a predefined time period, an LED indicator may first be flashed every few seconds for 15 minutes, then the mobile device may be vibrated every minute for 15 minutes. This may be followed by the emitting of a “beep” every few seconds for minutes, which may also increase in volume over this period. The rate at which any of these alerts are generated may also be escalated over the indicated periods, for example. This sequence may also be modified depending on the state of the mobile device (e.g. whether the mobile device is in a holster, whether the mobile device is in a cradle, etc.).
As noted above, user notifications may be generated at step 340 until the additional input is received or is in the process of being received from the user, wherein the flow of method steps will then proceed to step 350 at which progress in the performance of the task can continue upon receipt of the additional input. Alternatively, the user notifications may be generated until a second predefined time period has elapsed, after which completion of the task may remain pending or performance of the task may be cancelled [step not shown].
Although features of some of the embodiments of method 300 have been described primarily with respect to tasks comprising the processing of messages composed by a user for sending to one or more recipients, the described features may also be applicable in respect of other tasks, in variant embodiments.
For example, in a variant embodiment, the task comprises searching messages. The user may initiate a search on the mobile device for a message stored in one or more message folders, or for specific text in a message (e.g. text in the body of the message, text in a sender's e-mail address identified in the header of the message, text in a recipient's e-mail address identified in the header of the message, text in the subject of a message, etc.), by providing one or more search terms and possibly selecting a search button or menu selection. While the search is being performed, the messaging application may encounter an encrypted message to which access is required, for example. In that case, it may be necessary to obtain the requisite password from the user before data of the encrypted message can be decrypted and accessed for searching purposes. The search cannot be completed until the user provides the requisite password as additional input, and the search may potentially be suspended until the user provides the requisite password as additional input.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS7221937May 5, 2003May 22, 2007Research In Motion LimitedEvent reminder methodUS7697926Apr 13, 2010Research In Motion LimitedDevice and method for generating user notifications associated with tasks that are pending completionUS20020068615Dec 4, 2001Jun 6, 2002Hironori YamadaCellular phone having an in-absence incoming call reporting functionUS20020102999Feb 8, 2002Aug 1, 2002Qualcomm, Inc.Method and apparatus for enabling group communication services in an existing communication systemUS20030198324Apr 10, 2003Oct 23, 2003Beno CorporationMethod for notifying and reminding phone users of missed callsUS20040198426Jan 29, 2003Oct 7, 2004Hewlett-Packard CompanyTask-related communication via wireless communication hotspotsUS20060030295Aug 3, 2004Feb 9, 2006Research In Motion LimitedMethod and apparatus for providing minimal status displayUS20060073819Oct 4, 2004Apr 6, 2006Research In Motion LimitedAutomatic audio intensity adjustmentUS20070293205May 19, 2005Dec 20, 2007Henderson Daniel AMethod and apparatus for improved personal communication devices and systemsEP1748624A1Jul 29, 2005Jan 31, 2007Research In Motion LimitedPending tasks notification by a mobile deviceEP1858231A1Jul 29, 2005Nov 21, 2007Research In Motion LimitedPending tasks notification by a mobile deviceHK1100249A1 Title not availableWO2005015867A1Apr 2, 2004Feb 17, 2005Research In Motion LimitedSystem and method of accessing keys for secure messagingNon-Patent CitationsReference1Canadian First Office Action. Application No. 2,550,319. Dated: Jan. 27, 2010.2Coskun, Risvao, "Wireless E-mail Security: A State-of-the-Art Review for Message Privacy and Protection form Application Perspective", Southeastcon, 2004, Proceedings, IEEE Greensboro, North Carolina, USA, Piscataway, NJ, USA, IEEE, 2004, pp. 413-418, XP010697866.3European Communication Under Rule 51(4) EPC. Application No. 05107028.2. Dated: Mar. 19, 2007.4European Communication Under Rule 71(3) EPC. Application No. 07112334.3. Dated: Feb. 1, 2008.5European Examination Report. Application No. 05107028.2. Dated: Sep. 21, 2006.6European Search and Examination Report. Application No. 07112334.3. Dated: Oct. 15, 2007.7European Search Report. Application No. 05107028. Dated: Jan. 3, 2006.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8577357Aug 10, 2011Nov 5, 2013Blackberry LimitedDevice and method for generating user notifications associated with tasks that are pending completionClassifications U.S. Classification455/419, 455/550.1International ClassificationH04M3/00Cooperative ClassificationH04M1/72519, G06Q10/107European ClassificationH04M1/725F, G06Q10/107Legal EventsDateCodeEventDescriptionApr 13, 2010ASAssignmentOwner name: RESEARCH IN MOTION LIMITED, ONTARIOFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROWN, MICHAEL K.;BROWN, MICHAEL S.;KIRKUP, MICHAEL G.;REEL/FRAME:024223/0652Effective date: 20050923Nov 3, 2014ASAssignmentOwner name: BLACKBERRY LIMITED, ONTARIOFree format text: CHANGE OF NAME;ASSIGNOR:RESEARCH IN MOTION LIMITED;REEL/FRAME:034150/0483Effective date: 20130709Mar 2, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services