Source: https://patents.google.com/patent/US8661267
Timestamp: 2018-07-18 12:56:58
Document Index: 439455113

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 04103998', 'Application No. 2', 'Application No. 02754007', 'Application No. 02752898', 'Application No. 02752898', 'Application No. 02752898', 'Application No. 02754007', 'Application No. 02754007', 'Application No. 02817741', 'Application No. 02819798', 'Application No. 200810009944', 'Application No. 02817741', 'Application No. 02819798', 'Application No. 2', 'Application No. 2', 'Application No. 02817741', 'Application No. 02817741', 'Application No. 200810009944', 'Application No. 200810009944', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 02817741', 'art 3', 'Application No. 02817741', 'Application No. 02752898', 'Application No. 02752898', 'Application No. 02752898', 'Application No. 02754007', 'Application No. 02754007', 'Application No. 02817741', 'Application No. 02819798', 'Application No. 200810009944', 'Application No. 02817741', 'Application No. 200810009944']

US8661267B2 - System and method for processing encoded messages - Google Patents
System and method for processing encoded messages Download PDF
US8661267B2
US8661267B2 US13228485 US201113228485A US8661267B2 US 8661267 B2 US8661267 B2 US 8661267B2 US 13228485 US13228485 US 13228485 US 201113228485 A US201113228485 A US 201113228485A US 8661267 B2 US8661267 B2 US 8661267B2
US13228485
US20110320807A1 (en )
This application is a continuation of U.S. patent application Ser. No. 10/486,406, filed Feb. 6, 2004 and issued as U.S. Pat. No, 8,019,081 on Sep. 13, 2011, which is the National Stage Entry of PCT International Application No. PCT/CA02/01225, filed Aug. 6, 2002, which claims the benefit of U.S. Provisional Application No. 60/310,330, filed Aug. 6, 2001. The entirety of U.S. patent application Ser. No. 10/486,406, PCT International Application No, PCT/CA02/01225, and U.S. Provisional Application No. 60/310,330 are hereby incorporated by reference.
When an encrypted message is received, it must be decrypted before being displayed or otherwise processed. Decryption is a processor-intensive operation which, on a mobile device with limited processing resources, tends to take a relatively long time, on the order of several seconds. Such time delays may be unacceptable for many mobile device users. Even if the message is not encrypted, it may be encoded in such a way that some processing may be required before displaying the message to the user. Two examples of such an encoding would be the Base-64 encoding commonly used to transfer binary data embedded in email messages on the Internet, and the ASN.1 encoding required by many Internet and security standards. The decoding step may also cause a time delay that is unacceptable for many mobile device users.
Since the content of encrypted messages should generally remain secure even after receipt, such messages are normally saved to long term storage only in encrypted form and decryption operations must be performed each time an encrypted message is opened. Also, when a user asks to verify a signature on a message, the original message contents are typically required to perform the operation, so messages are often stored in their encoded form. Therefore, each time such an encoded message is opened or displayed for example, the decoding operations must be repeated as well.
FIG. 3 illustrates an example system for transferring messages that were encoded by encryption and possibly signed using S/MIME or similar techniques.
FIG. 11 is schematic diagram of a wireless communication device that could be used with the systems and methods described herein.
As used in this description, references to “encoding” should be interpreted to include such operations as signing, encryption, encoding such as Base-64 or ASN.1 encoding, more general encoding by otherwise reversibly transforming data, or any combination thereof. Similarly, “decoding” should therefore includes any processing operations necessary to invert or reverse any encoding applied to a message.
FIG. 1 is an overview of an example communication system in which a wireless communication device may be used. One skilled in the art will appreciate that there may be hundreds of different topologies, but the system shown in FIG. 1 helps demonstrate the operation of the encoded message processing systems and methods described in the present application. There may also be many message senders and recipients. The system shown in FIG. 1 is for illustrative purposes only, and shows perhaps the most prevalent Internet e-mail environment where security is not generally used.
An e-mail sender system 10 may for example be connected to an ISP (Internet Service Provider) on which a user of the system 10 has an account, located within a company, possibly connected to a local area network (LAN), and connected to the Internet 20, or connected to the Internet 20 through a large ASP (application service provider) such as America Online (AOL). Those skilled in the art will appreciate that the systems shown in FIG. 1 may instead be connected to a wide area network (WAN) other than the Internet, although e-mail transfers are commonly accomplished through Internet-connected arrangements as shown in FIG. 1.
The message server 40 may be implemented for example on a network computer within the firewall of a corporation, a computer within an ISP or ASP system or the like, and acts as the main interface for e-mail exchange over the Internet 20. Although other messaging systems might not require a message server system 40, a mobile device 100 configured for receiving and possibly sending e-mail will normally be associated with an account on a message server. Perhaps the two most common message servers are Microsoft Exchange™ and Lotus Domino™. These products are often used in conjunction with Internet mail routers that typically use UNIX-based Sendmail protocols to route and deliver mail. These intermediate components are not shown in FIG. 1, as they do not directly play a role in the secure message processing described below. Message servers such as server 40 typically extend beyond just e-mail sending and receiving; they also include dynamic database storage engines that have predefined database formats for data like calendars, to-do lists, task lists, e-mail and documentation.
The wireless gateway 85 and infrastructure 90 provide a link between the Internet 20 and wireless network 105. The wireless infrastructure determines the most likely network for locating a given user and tracks the user as they roam between countries or networks. A message is then delivered to the mobile device via wireless transmission, typically at a radio frequency (RF), from a base station in the wireless network 105 to the mobile device 100. The particular network 105 may be virtually any wireless network over which messages may be exchanged with a mobile device.
As shown in FIG. 1, a composed e-mail message 15 is sent by the e-mail sender 10, located somewhere on the Internet 20. This message 15 is normally fully in the clear and uses traditional Simple Mail Transfer Protocol (SMTP), RFC822 headers and Multipurpose Internet Mail Extension (MIME) body parts to define the format of the mail message. These techniques are all well known to those skilled in the art. The message 15 arrives to the message server 40 and is normally stored in a message store. Most known messaging systems support a so-called “pull” message access scheme, wherein a mobile device must request that stored messages be forwarded by the message server to the mobile device. Some systems provide for automatic routing of such messages which are addressed using a specific e-mail address associated with the mobile device. Messages addressed to a message server account associated with a host system such as a home computer or office computer which belongs to the user of a mobile device 100 are redirected from the message server 40 to the mobile device 100 as they are received.
Regardless of the specific mechanism controlling the forwarding of messages to a mobile device 100, the message 15, or possibly a translated or reformatted version thereof, is sent to the wireless gateway 85. The wireless infrastructure 90 includes a series of connections to wireless network 105. These connections could be Integrated Services Digital Network (ISDN), Frame Relay or T1 connections using the TCP/IP protocol used throughout the Internet. As used herein, the term “wireless network” is intended to include three different types of networks, those being (1) data-centric wireless networks, (2) voice-centric wireless networks and (3) dual-mode networks that can support both voice and data communications over the same physical base stations. The combined dual-mode networks may include, but are not limited to (1) the modern Code Division Multiple Access (CDMA) network, (2) the Groupe Special Mobile or the Global System for Mobile Communications (GSM) and the General Packet Radio Service (GPRS) network both developed by the standards committee of CEPT, and (3) the future third-generation (3G) networks like Enhanced Data-rates for Global Evolution (EDGE) and Universal Mobile Telecommunications Systems (UMTS). GPRS is a data overlay on the very popular GSM wireless network, operating in virtually every country in Europe. Some older examples of data-centric network include the Mobitex™ Radio Network, and the DataTAC™ Radio Network. Examples of older voice-centric data networks include Personal Communication Systems (PCS) networks like GSM and TDMA systems that have been available in North America and world-wide for nearly 10 years.
The central host system 30 will typically be a corporate office or other LAN, but may instead be a home office computer or some other private system where mail messages are being exchanged. Within the host system 30 is the message server 40, running on some computer within the firewall of the host system, that acts as the main interface for the host system to exchange e-mail with the Internet 20. In the system of FIG. 2, the redirection program 45 enables redirection of data items from the server 40 to a mobile device 100. Although the redirection program 45 is shown to reside on the same machine as the message server 40 for ease of presentation, there is no requirement that it must reside on the message server. The redirection program 45 and the message server 40 are designed to co-operate and interact to allow the pushing of information to mobile devices 100. In this installation the redirection program 45 takes confidential and non-confidential corporate information for a specific user and redirects it out through the corporate firewall to mobile devices 100. A more detailed description of the redirection software 45 may be found in the commonly assigned U.S. Pat. No. 6,219,694 (“the '694 patent”), entitled “System and Method for Pushing Information From A Host System To A Mobile Data Communication Device Having A Shared Electronic Address”, and issued to the assignee of the instant application on Apr. 17, 2001, and U.S. patent application Ser. No. 09/401,868, Ser. No. 09/545,963, Ser. No. 09/528,495, Ser. No. 09/545,962, and Ser. No. 09/649,755, all of which are hereby incorporated into the present application by reference. This push technique may use a wireless friendly encoding technique preferably including encryption to deliver all information to a mobile device thus effectively extending the security firewall 30 to include each mobile device 100 associated with the host system.
As shown in FIG. 2, there may be many alternative paths for getting information to the mobile device 100. One method for loading information onto the mobile device 100 is through a port designated 50, using a device cradle 65. This method tends to be useful for bulk information updates often performed at initialization of a mobile device 100 with the host system or a computer 35 within the system 30. The other main method for data exchange is over-the-air using wireless networks to deliver the information. As shown in FIG. 2, this may be accomplished through a wireless VPN router 75 or through a traditional Internet connection 95 to a wireless gateway 85 and a wireless infrastructure 90, as described above. The concept of a wireless VPN router 75 is new in the wireless industry and implies that a VPN connection could be established directly through a specific wireless network 110 to a wireless mobile device 100. The possibility of using a wireless VPN router 75 has only recently been available and could be used when the new Internet Protocol (IP) Version 6 (IPV6) arrives into IP-based wireless networks. This new protocol will provide enough IP addresses to dedicate an IP address to every mobile device 100 and thus make it possible to push information to a mobile device 100 at any time. A principal advantage of using this wireless VPN router 75 is that it could be an off-the-shelf VPN component, thus it would not require a separate wireless gateway 85 and wireless infrastructure 90 to be used. A VPN connection would preferably a Transmission Control Protocol (TCP)/IP or User Datagram Protocol (UDP)/IP connection to deliver the messages directly to the mobile device 100. If a wireless VPN 75 is not available then a link 95 to the Internet 20 is the most common connection mechanism available and has been described above.
In the automatic redirection system of FIG. 2, a composed e-mail message 15 leaving the e-mail sender 10 arrives to the message server 40 and is redirected by the redirection program 45 to the mobile device 100. As this redirection takes place the message 15 is re-enveloped, as indicated at 80, and a possibly proprietary compression and encryption algorithm can then be applied to the original message 15. In this way, messages being read on the mobile device 100 are no less secure than if they were read on a desktop workstation such as 35 within the firewall. All messages exchanged between the redirection program 45 and the mobile device 100 preferably use this message repackaging technique. Another goal of this outer envelope is to maintain the addressing information of the original message except the sender's and the receiver's address. This allows reply messages to reach the appropriate destination, and also allows the “from” field to reflect the mobile user's desktop address. Using the user's e-mail address from the mobile device 100 allows the received message to appear as though the message originated from the user's desktop system 35 rather than the mobile device 100.
Turning back to the port 50 and cradle 65 connectivity to the mobile device 100, this connection path offers many advantages for enabling one-time data exchange of large items. For those skilled in the art of personal digital assistants (PDAs) and synchronization, the most common data exchanged over this link is Personal Information Management (PIM) data 55. When exchanged for the first time this data tends to be large in quantity, bulky in nature and requires a large bandwidth to get loaded onto the mobile device 100 where it can be used on the road. This serial link may also be used for other purposes, including setting up a private security key 210 such as an S/MIME or PGP specific private key, the Certificate (Cert) of the user and their Certificate Revocation Lists (CRLs) 60. The private key is preferably exchanged so that the desktop 35 and mobile device 100 share one personality and one method for accessing all mail. The Cert and CRLs are normally exchanged because they represent the largest part of S/MIME, PGP and other public key security methods. A certificate chain is a Cert along with a number of other Certs required to verify that the original Cert is authentic. The receiver of the message is able to verify that each Cert in the chain was signed by the next Cert in the chain, until a Cert is found that was signed by a root Cert from a trusted source, perhaps from a large Public Key Server (PKS) associated with a Certificate Authority (CA) such as Verisign or Entrust for example, both prominent companies in the area of public key cryptography. Once such a root Cert is found a signature can be verified and trusted, since both the sender and receiver trust the source of the root Cert.
Although the encoded message processing systems and methods described herein are in no way dependent upon pre-loading of information from a host computer or a computer 35 in a host system 30 through a port arrangement, such pre-loading of typically bulky information such as Certs and CRLs may facilitate transmission of encoded messages, particularly those that have been encrypted and/or signed or require additional information for processing, to mobile devices 100. If an alternate mechanism for transferring such messages, like S/MIME or PGP e-mail messages for example, to a mobile device is available, then these messages may be processed as described herein.
Having described several typical communication network arrangements, the transfer and processing of secure e-mail messages will now be described in further detail.
E-mail messages generated using the S/MIME and PGP techniques may include encrypted information, and/or a digital signature on the message contents. In signed S/MIME operations, the sender takes a digest of a message and signs the digest using the sender's private key. A digest is essentially a checksum, CRC or other preferably non-reversible operation such as a hash on the message, which is then signed. The signed digest, the Cert of the sender, and any chained Certs and CRLs are all appended to the outgoing message. The receiver of this signed message must also take a digest of the message, then retrieve the sender's public key, verify the Cert and CRLs and decrypt the signed digest. Finally the two digests are compared to see if they match. If the message content has been changed, then the digests will be different. If the message is not encrypted, this signature does not prevent anyone from seeing the contents of the message, but does ensure the message has not been tampered with and is from the actual person as indicated on the ‘From’ field of the message.
In encrypted S/MIME message operations, a one-time session key is generated and used for each message, and is never re-used for other messages. The session key is then further encrypted using the receiver's public key. If the message is addressed to more than one receiver, the same session key is encrypted using the public key of each receiver. Only when all receivers have an encoded session key is the message then sent to each receiver. Since the e-mail retains only one form, all encrypted session keys must be sent to every receiver, even though they cannot use these other session keys. Each receiver must then locate its own session key, possibly based on a generated Recipient Info summary of the receivers that may be attached to the message, and decrypt the session key using its private key. Once the session key is decrypted it is then used to decrypt the message body. The S/MIME Recipient Info attachment can also specify a particular encryption scheme that must be used to decrypt the message. This information is normally placed in the header of the S/MIME message.
In FIG. 3, User X at system 10 creates a mail message 15 and decides to encrypt and sign the message. To achieve this, the system 10 first creates a session key and encrypts the message. Then the public key for each recipient is retrieved from either local storage or a Public Key Server (PKS) (not shown) on the Internet 20 for example if public key cryptography is used. Other crypto schemes may instead be used, although public key cryptography tends to be common, particularly when a system includes a large number of possible correspondents. In a system such as shown in FIG. 3, there may be millions of e-mail systems such as 10 that may from time to time wish to exchange messages with any other e-mail systems. Public key cryptography provides for efficient key distribution among such large numbers of correspondents. For each recipient, the session key is encrypted, as shown at A, B and C for three intended recipients, and attached to the message preferably along with the RecipientInfo section. Once the encryption is complete, a digest of the new message, including the encrypted session keys, is taken and this digest is signed using the sender's private key. In the case where the message is signed first a digest of the message would be taken without the encrypted session keys. This digest, along with all the signed components, would be encrypted using a session key and each session key would be further encrypted using each recipient's public key if public key crypto is used, or another key associated with each recipient if the sender is able to securely exchange e-mail with one or more recipients through some alternate crypto arrangement.
The encrypted and signed message 200, with the session keys 205 and digital signature and signature-related information 305 is sent to the message server 40 running on a computer system. As described above, the message server 40 may process the message and place it into the appropriate user's mailbox. Depending upon the mobile device e-mail access scheme, a mobile device 100 may request the e-mail from the message server 40, or redirection software 45 (see FIG. 2) may detect the new message and begin the redirection process to forward the new e-mail message to each recipient that has a mobile device 100. Alternatively, the e-mail message and attachments may possibly be sent directly to a mobile device 100 instead of or in addition to a message server system. Any of the transfer mechanisms described above, including over the Internet 20 through a wireless gateway and infrastructure 85/90 and one or more wireless networks 110 or through the Internet 20 and wireless network 110 using a wireless VPN router 75 (FIG. 2) may be used to forward the e-mail message and attachments to a mobile device 100. Other transfer mechanisms that are currently known or may become available in the future, may also be used to send the message and attachments to a mobile device 100.
FIG. 3 illustrates receipt of the entire message on each mobile device 100. Before the message is sent to a mobile device 100, the signature or encryption sections of the message may instead be re-organized and only the necessary portions sent to each mobile device 100, as described in detail in U.S. patent application Ser. No. 60/297,681, titled “An Advanced System and Method for Compressing Secure E-Mail for Exchange with a Mobile Data Communication Device”, filed on Jun. 12, 2001, and Ser. No. 60/365,535, titled “Advanced System And Method For Compressing Secure E-Mail For Exchange With A Mobile Data Communication Device”, filed on Mar. 20, 2002, both assigned to the assignee of the present application and incorporated in their entirety herein by reference. These earlier applications disclose several schemes for rearranging secure messages and limiting the amount of information sent to a mobile device. For example, in accordance with one scheme described in the above application, the message server system determines the appropriate session key for each mobile device and sends only that encrypted session key with the message to the mobile device. The above applications also disclose techniques for limiting signature-related information that may be sent to a mobile device with an encrypted and signed message. Therefore, although FIG. 3 shows entire messages, with all encrypted session keys and signature-related attachments, at each mobile device 100, the present encrypted message processing techniques require only that the encrypted session key be forwarded to the mobile device with the message. Other encrypted session keys and signature information may or may not necessarily be received at the mobile device.
For example, consider first a message that is encoded by being signed but not encrypted. The contents of the message are not secret in this case, but they have nonetheless been encoded in some way. When the message is decoded, in this example by verifying the signature, it is stored in a temporary storage area such as in a random access memory (RAM) on a mobile device 100. The next time the message must be decoded, to be displayed or further processed for example, the stored decoded message is instead retrieved from memory. Note that the original encoded message may be retained so that signature verification may still be performed using the original encoding if necessary.
As another example, consider an encoded message that is encrypted (and possibly signed). When the message is decrypted, it can also be stored in a temporary storage area such as in RAM on a mobile device 100. The next time the message must be decrypted, the stored decrypted message is retrieved from memory. When both a session key and message content must be decrypted, as for an encrypted S/MIME message, retrieval of the decrypted message from memory may be substantially faster than the decryption operations. However, unlike a message that is not encrypted, the contents of the decrypted message are secret and for security reasons should not be stored in RAM for long periods of time, in case an attacker were to gain control of the mobile device. Therefore, as a possible option, the message could be stored for only a short period of time, after which it would automatically be removed from RAM. The length of this short period of time could be configured, for example, by the user or by a system administrator; some such configurations are described below.
FIG. 3 a shows a general encoded message format, and is useful in illustrating a system utilizing temporary message storage. An encoded message 350 will generally include a header portion 352, an encoded body portion 354, possibly one or more encoded message attachments 356, possibly one or more encrypted session keys 358, and may also include a signature and related information 360 such as CRLs and certs. As described above, encoded messages such as 350 may include encrypted messages, signed messages, encrypted and signed messages, or otherwise encoded messages.
Those skilled in the art will appreciate that the header portion typically includes addressing information such as “To”, “From” and “CC” addresses, as well as possibly message length, indicators, sender encryption and signature scheme identifiers when necessary, and the like. Actual message content will normally include a message body or data portion 354 and possibly one or more file attachments 356, which may be encrypted by the sender using a session key. If a session key was used, it is typically encrypted for each intended recipient and included in the message as shown at 358. Depending upon the particular message transport mechanism used to send the message to a receiver such as a mobile device 100, the message may include only the specific encrypted session key for that recipient or all session keys. If the message is signed, a signature and related information 360 are included. Where the message is signed before encryption, according to a variant of S/MIME for example, the signature may also be encrypted.
As described in further detail below, if the encoded message is unencrypted, a receiver decodes the message body, stores the decoded message content so that it may be subsequently viewed and/or processed without repeating the decoding operations. If the message is encrypted, the decoding process may proceed as follows: the receiver locates and decrypts a corresponding encrypted session key, possibly after verifying a signature, uses the decrypted session key to decrypt any encrypted message content, and then if necessary further decodes the message body, for example where the message body has been base-64 encoded. The resultant decoded message content may also be stored by the receiver, possibly for only a short time for security reasons, and may be subsequently viewed and/or processed without repeating the decoding operations. It is noted that at least the message body portion 354 may be decoded and stored to memory, although it may also be feasible and advantageous to also store decoded message attachments where desired. It should therefore be understood that references in this description to stored decoded messages and decoded content may include decoded versions of the message body 354, attachment(s) 356 or both.
The format shown in FIG. 3 a is for illustrative purposes only and it is to be understood that the encoded messages may have other formats. For example, as described above, the processing systems and techniques described herein are applicable to signed or unsigned, encrypted or unencrypted, and otherwise encoded messages, such that a received message may not necessarily include the portions related to encryption and/or signing. In addition, the particular message components may appear in a different order than shown in FIG. 3 a. Depending upon the message scheme used, a message may include fewer, additional, or different message sections or components.
The temporary storage area in which the decoded message is stored is preferably in a volatile and non-persistent store. The decoded message may for example be stored for only a particular period of time, which may preferably be set by a user. A single message storage time period may be set and applied to all messages, although more customized settings are also contemplated. Particularly sensitive messages that normally arrive from certain senders or from senders whose e-mail addresses have the same domain name for example, may have a specific relatively short decoded message storage period, whereas decoded versions of encoded e-mails received from other senders, perhaps personal contacts, may be stored for a longer period of time. Alternatively, a user may be prompted for a storage time period each time a message is opened or closed. The decoded message storage feature might also be disabled for certain messages or messages received from certain senders. Message storage operations may possibly be automatically controlled by detection of specific predetermined keywords in a message. For example, the text “Top Secret” in an e-mail subject line may be detected by the mobile device when the e-mail is decoded and prevent the decoded message from being stored or delete the decoded message from storage if it had already been stored.
The particular criteria controlling decoded message storage will preferably be determined in accordance with the desired level of security of encoded messages at a mobile device. Storage of decoded message content represents a trade-off between usability and security. Longer decoded message storage intervals improve usability at the cost of decreased security, since the decoded content of an encoded message may be viewed or processed for a longer period of time after the encoded message is first decoded without having to decode the message again. A shorter message storage interval reduces the amount of time that decoded message contents remain accessible to an unauthorized user of a mobile device. When the decoded message is removed from storage, an unauthorized user would preferably be required to first correctly enter the device user's password or passphrase in order to decode and view encoded message content, particularly where the encoded message includes encrypted content.
FIG. 4 is a flow diagram representing a method for initial processing of an encoded message. At step 402, a received message is accessed for the first time. If the received message was signed by the sender, as determined at step 404, then the mobile device will attempt to verify the signature. If the signature is properly verified at step 406, for example by determining a match between digests as described above, processing continues at step 410. Otherwise, the user will typically be given an indication that the signature verification failed, at step 408. Depending upon the particular signature scheme implemented or perhaps in response to a user selection to end processing, a message might not be further processed if the signature cannot be verified, and processing ends at step 418. However, in certain circumstances, the user may wish to proceed to view or otherwise process the message, even though the digests do not match and thus the message content may have been altered after the sender signed the message.
If the message was not signed, the signature is verified, or processing should continue after a failed signature verification attempt, the mobile device determines in step 409 whether the message was encrypted. If the message was encrypted, the receiving mobile device locates its corresponding session key in the message (at step 410) if session keys were used in encrypting the message. However, if the session key could not be found or the key required to decrypt the session key is not available (at step 412), for example if the user does not input a correct password or passphrase, then the mobile device cannot decrypt the session key or the message (at step 414) and an error is preferably returned to the user (at step 416). When a session key is found and the required decryption key is available (i.e. a correct password or passphrase is entered) on the mobile device, the session key is then decrypted (at step 420) and used to decrypt the message, at step 422.
In step 424, the contents of the message, having already been decrypted if required, are further decoded if necessary according to the particular encoding used to send the message. The decoded message is then preferably stored to a non-persistent store at step 426. Any determinations relating to whether or not the decoded message should be stored or for how long the decoded message should be stored would be performed as part of step 424. As described above, the overall decoding scheme shown in FIG. 4 may include any of the operations of signature verification, decryption and further decoding.
FIG. 4 illustrated temporarily storing a decoded message, and FIG. 5 describes a processing method for previously decoded messages. With reference to FIG. 5, Step 502 represents an operation of accessing a message that has previously been decoded. New messages are processed as described above and shown in FIG. 4. Since the message being accessed in step 502 has previously been decoded, if a signature is appended to the message, it may have already been verified. If not, or if the signature should be verified again, for example where a new CRL has been loaded onto the mobile device, a positive determination is made at step 504. At step 506, signature verification operations are performed. Steps 508 and 510 operate substantially as described above in reference to the signature verification steps 408 and 410 in FIG. 4. Where the signature cannot be verified, processing may either end at step 511 or continue at step 512.
If the signature need not be verified, is verified, or processing should continue even if a signature could not be verified, then the mobile device checks to see if the decoded version of the message is currently in storage (at step 512). As described above, the message is preferably stored in a non-persistent store and for a certain time period. Thus, if the time period has expired, the mobile device has lost power or been turned off since the message was stored, or the message was not stored at all, then processing reverts (at step 514) to initial message processing at step 410 (FIG. 4). Since the message is not in memory, it must be decoded again in order to be viewed or processed. If the decoded message is found in storage, message decoding operations are avoided and the message can thereby be displayed or processed much more quickly than in known message processing schemes. The mobile device need only retrieve the stored message and display or process it (at step 516).
Those skilled in the art will appreciate that an encoded message processing method need not necessarily include all of the steps shown in FIGS. 4 and 5 or may include further steps and operations in addition thereto. The operations may also be performed in a different order. For example, a message that was both signed and encrypted may have been signed and then encrypted, or encrypted and then signed. Depending on the order in which such operations were applied when the message was sent, the order in which the verification and decryption steps are applied may also need to change when the message is received. Other variations of the methods described above will be apparent to those skilled in the art and as such are considered to be within the scope of the invention.
As further examples of the wide variations of the systems and methods described herein, FIGS. 6 and 7 illustrate encoded messages being handled by a mobile device. FIG. 6 depicts an example wherein a wireless connector system 606 transmits a message 604 from a sender 602 that is addressed to one or more message receivers. In this example, the sender's encoded message 604 is an encrypted message that includes encrypted content and further includes encryption accessing information (e.g., a session key or other equivalent technique) which allows the decryption of the encrypted content. The encoded message 604 also may be signed or unsigned.
The encoded message 604 is then transmitted to the mobile device 614. The mobile device 614 decodes the message 604 and uses a storage software module 622 to store the decoded message content portion 616 in memory 618 which is volatile and non-persistent. The memory 618 may include a message access data structure 620 to store the decoded message content portion 616 as well as access information (e.g., signature verification information) in the memory 618.
FIG. 7 depicts a message access data structure 620 for use when the decoded message may be accessed multiple times. In this example, several messages' decoded content is stored in the message access data structure 620, such as a first decoded message 710 and a second decoded message 720. If the decoded contents of the first message are accessed multiple times as shown at 700, then the mobile device 614 uses an accessing software module 702 to retrieve the first message's decoded content 710 from memory 618. The retrieved information 710 is provided for use by the user of the mobile device or by a software application that requested the content.
The message server 820, running on a computer behind the firewall 808, acts as the main interface for the corporation to exchange messages, including for example electronic mail, calendaring data, voice mail, electronic documents, and other PIM data with the WAN 804, which will typically be the Internet. The particular intermediate operations and computers will be dependent upon the specific type of message delivery mechanisms and networks via which messages are exchanged, and therefore have not been shown in FIG. 8. The functionality of the message server 820 may extend beyond message sending and receiving, providing such features as dynamic database storage for data like calendars, todo lists, task lists, e-mail and documentation, as described above.
The microprocessor 1138 preferably manages and controls the overall operation of the mobile device 100. Many types of microprocessors or microcontrollers could be used here, or, alternatively, a single DSP 1120 could be used to carry out the functions of the microprocessor 1138. Low-level communication functions, including at least data and voice communications, are performed through the DSP 1120 in the transceiver 1111. Other, high-level communication applications, such as a voice communication application 1124A, and a data communication application 1124B may be stored in the flash memory 1124 for execution by the microprocessor 1138. For example, the voice communication module 1124A may provide a high-level user interface operable to transmit and receive voice calls between the mobile device 100 and a plurality of other voice or dual-mode devices via the network 1119. Similarly, the data communication module 1124B may provide a high-level user interface operable for sending and receiving data, such as e-mail messages, files, organizer information, short text messages, etc., between the mobile device 100 and a plurality of other data devices via the networks 1119.
The microprocessor 1138 also interacts with other device subsystems, such as the display 1122, flash memory 1124, RAM 1126, auxiliary input/output (I/O) subsystems 1128, serial port 1130, keyboard 1132, speaker 1134, microphone 1136, a short-range communications subsystem 1140 and any other device subsystems generally designated as 1142.
Decrypted session keys or other encryption accessing information is preferably stored on the mobile device 100 in a volatile and non-persistent store such as the RAM 1126. Such information may instead be stored in the flash memory 1124, for example, when storage intervals are relatively short, such that the information is removed from memory soon after it is stored. However, storage of this information in the RAM 1126 or another volatile and non-persistent store is preferred, in order to ensure that the information is erased from memory when the mobile device 100 loses power. This prevents an unauthorized party from obtaining any stored encryption accessing information such as a decrypted session key by removing a memory chip from the mobile device 100, for example.
1. A computing device for accessing an encoded message comprising at least an encoded message content portion, the computing device comprising:
a persistent memory store configured to store the encoded message in an encoded state;
a processor operatively coupled to the volatile memory and the persistent memory store, the processor configured to:
decode the encoded message content portion to produce a decoded message content portion;
store the decoded message content portion to the volatile memory;
remove the decoded message content portion from the volatile memory after a preselected time has elapsed; and
re-decode the encoded message stored in the persistent memory store in response to a further message open request after the decoded message content portion has been removed from the volatile memory.
2. The computing device of claim 1, wherein the encoded message continues to be stored in the persistent memory store in the encoded state following decoding by the processor.
3. The computing device of claim 1, further comprising a wireless communication subsystem, wherein the processor is further configured to receive the encoded message via the wireless communication subsystem prior to decoding the encoded message content portion.
4. The computing device of claim 1, wherein the encoded message comprises an encrypted session key usable, when decrypted, to decrypt the encoded message content portion, and wherein the processor is further configured to:
decrypt the encrypted session key to produce a decrypted session key; and
store the decrypted session key to the volatile memory.
5. The computing device of claim 4, wherein the processor is further configured to:
determine whether the encrypted session key has been decrypted and a decrypted session key stored to the volatile memory; and
retrieve the decrypted session key from the volatile memory and use the stored decrypted session key to decrypt the encrypted message content portion.
6. The computing device of claim 4, wherein the encrypted session key is a one-time session key that is generated and used for the encoded message.
7. The computing device of claim 1, wherein the encoded message content portion comprises at least one of an encoded message body and an encoded message attachment.
8. The computing device of claim 1, wherein the encoded message content portion was encoded using a session key and encryption algorithm, and wherein a public key cryptographic algorithm was used to encrypt the session key to generate the encrypted session key.
9. The computing device of claim 1, wherein the encoded message was encrypted using at least one of Secure Multipurpose Internet Mail Extensions (S/MIME), Pretty Good Privacy (PGP), and OpenPGP techniques.
10. The computing device of claim 1, wherein the encoded message comprises a digital signature.
11. The computing device of claim 1, wherein the preselected time is configurable by a user of the computing device.
12. The computing device of claim 1, wherein the decoded message content portion is removed from the volatile memory based upon electrical power being removed from the wireless mobile communication device.
13. The computing device of claim 1, wherein the decoded message content portion is removed from the volatile memory based upon a characteristic associated with the encoded message.
14. The computing device of claim 13, wherein the characteristic comprises an identity of a sender of the encoded message.
15. The computing device of claim 14, wherein the identity of the sender of the encoded message comprises an e-mail address of the sender.
16. The computing device of claim 1, wherein the decoded message content portion is removed from the memory based upon a sensitivity level associated with the encoded message.
17. The computing device of claim 16, wherein the sensitivity level is determined based upon a subject line contained within the encoded message.
18. The computing device of claim 1, wherein the processor is further configured to set a disabling flag to prevent storage of the decoded message content portion in the volatile memory for use in additional accesses of the message content portion.
19. The computing device of claim 1, wherein the processor is further configured to set a disabling flag to remove the decoded message content portion from the volatile memory after accessing the message content portion.
20. The computing device of claim 1, wherein the computing device is a mobile communication device.
US13228485 2001-08-06 2011-09-09 System and method for processing encoded messages Active 2022-09-13 US8661267B2 (en)
US31033001 true 2001-08-06 2001-08-06
PCT/CA2002/001225 WO2003015367A3 (en) 2001-08-06 2002-08-06 System and method for processing encoded messages
US10486406 US8019081B2 (en) 2001-08-06 2002-08-06 System and method for processing encoded messages
US13228485 US8661267B2 (en) 2001-08-06 2011-09-09 System and method for processing encoded messages
US10486406 Continuation
PCT/CA2002/001225 Continuation WO2003015367A3 (en) 2001-08-06 2002-08-06 System and method for processing encoded messages
US10486406 Continuation US8019081B2 (en) 2001-08-06 2002-08-06 System and method for processing encoded messages
US20110320807A1 true US20110320807A1 (en) 2011-12-29
US8661267B2 true US8661267B2 (en) 2014-02-25
ID=23202023
US10486406 Active 2024-06-18 US8019081B2 (en) 2001-08-06 2002-08-06 System and method for processing encoded messages
US13228485 Active 2022-09-13 US8661267B2 (en) 2001-08-06 2011-09-09 System and method for processing encoded messages
US (2) US8019081B2 (en)
EP (1) EP1417814B1 (en)
CN (2) CN101232504B (en)
CA (1) CA2456839C (en)
DE (1) DE60229645D1 (en)
ES (1) ES2315379T3 (en)
WO (1) WO2003015367A3 (en)
DE60115072T3 (en) * 2000-09-21 2010-04-01 Research In Motion Ltd., Waterloo System and method for signing a software-kodes
JP2005516389A (en) 2002-01-23 2005-06-02 スピネカ セミコンダクター， インコーポレイテッド A field effect transistor having a source and / or drain forming a contact such as a Schottky or Schottky using strained semiconductor substrate
CA2564833C (en) * 2006-01-04 2009-01-27 Steven J. Mccarthy Electronic mail (email) system providing enhanced message retrieval from email storage server and related methods
US9407284B2 (en) 2013-03-15 2016-08-02 John W. Ogilvie Improvements for Base64 encoding and decoding
CN104244084B (en) * 2014-09-10 2017-08-29 广东欧珀移动通信有限公司 A method of controlling playback of an audio file, system and mobile terminal
WO1997041661A3 (en) 1996-04-29 1997-12-11 Motorola Inc Use of an encryption server for encrypting messages
WO1998034374A1 (en) 1997-01-31 1998-08-06 Motorola Inc. Encryption and decryption method and apparatus
WO1999001756A1 (en) * 1997-07-02 1999-01-14 Mine Safety Appliances Company Electrochemical sensor approximating dose-response behavior and method of use thereof
JP2000010477A (en) 1998-06-22 2000-01-14 Mitsubishi Electric Corp Certificate collection information forming apparatus, certificate certification apparatus and public key cipher operating system
WO2000031931A1 (en) 1998-11-24 2000-06-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for securing data objects
US6141422A (en) 1997-06-04 2000-10-31 Philips Electronics North America Corporation Secure cryptographic multi-exponentiation method and coprocessor subsystem
WO2000069114A1 (en) 1999-05-10 2000-11-16 Telefonaktiebolaget Lm Ericsson (Publ) Indirect public-key encryption
WO2001001644A1 (en) 1999-06-29 2001-01-04 Samsung Electronics Co., Ltd. Apparatus for securing user's information in a mobile communication system connected to the internet and method thereof
WO2001024434A1 (en) 1999-09-30 2001-04-05 B.M.N. Technology System for providing messages
WO2001063386A1 (en) 2000-02-23 2001-08-30 Kim Leeper A system and method for authenticating electronic documents
US20020053023A1 (en) 2000-08-17 2002-05-02 Patterson Andrew John Certification validation system
WO2001071608A3 (en) 2000-03-17 2002-05-02 Mark Nair System, method and apparatus for controlling the dissemination of digital works
US20020138722A1 (en) 2001-03-26 2002-09-26 Douceur John R. Encrypted key cache
JP2002535884A (en) 1999-01-14 2002-10-22 タンブルウィード コミュニケーションズ コーポレイション Distribution of secure e-mail messages based on web
WO2003009561A3 (en) 2001-07-16 2003-05-30 Research In Motion Ltd A system and method for supporting multiple certificate authorities on a mobile communication device
WO2003015367A3 (en) 2001-08-06 2003-05-30 Research In Motion Ltd System and method for processing encoded messages
WO2003079627A2 (en) 2002-03-20 2003-09-25 Research In Motion Limited System and method for supporting multiple certificate status providers on a mobile communication device
JP2004048139A (en) 2002-07-09 2004-02-12 Nikon Corp Image transmission system, image relay apparatus and electronic image apparatus
US6693964B1 (en) * 2000-03-24 2004-02-17 Microsoft Corporation Methods and arrangements for compressing image based rendering data using multiple reference frame prediction techniques that support just-in-time rendering of an image
WO2003005636A8 (en) 2001-07-04 2004-05-13 Luis Barriga Secure header information for multi-content e-mail
US6754276B1 (en) * 1999-09-20 2004-06-22 Matsushita Electric Industrial Co., Ltd. System stream creating apparatus which adjusts system clock reference based on total number of pictures to be stored and decoded during certain time period
JP2007162407A (en) 2005-12-16 2007-06-28 Daiho Constr Co Ltd Method and device for holding mud pressure in chamber in soil pressure type shield
EP1580953B1 (en) 2004-03-22 2011-02-09 Research In Motion Limited System and method for viewing message attachments
US20100124333A1 (en) 2001-06-12 2010-05-20 Research In Motion Limited System and Method for Processing Encoded Messages for Exchange with a Mobile Data Communication Device
US20100122089A1 (en) 2001-06-12 2010-05-13 Research In Motion Limited System and method for compressing secure e-mail for exchange with a mobile data communication device
US20090292916A1 (en) 2001-06-12 2009-11-26 Little Herbert A Certificate Management and Transfer System and Method
US20100115264A1 (en) 2001-06-12 2010-05-06 Research In Motion Limited System and Method for Processing Encoded Messages for Exchange with a Mobile Data Communication Device
CN1554176B (en) 2001-07-10 2012-12-05 捷讯研究有限公司 Method for processing encrypted message in wireless mobile communication device and device for processing multiple access for encrypted contents
CA2454218C (en) 2001-07-10 2013-01-15 Research In Motion Limited System and method for secure message key caching in a mobile communication device
Advisory Action from USPTO dated Aug. 19, 2009 for U.S. Appl. No. 10/483,282.
Advisory Action from USPTO dated Jul. 24, 2007 for U.S. Appl. No. 10/486,406.
Advisory Action from USPTO dated Mar. 16, 2009 for U.S. Appl. No. 10/486,406.
Berson T et al.: "Cryptography as a network serivce" 8th Annual Symposium on Network and Distributed System Security. (NDSS'01) Internet Soc Reston, VA, USA, Feb. 7, 2001-Feb. 9, 2001 pp. 1-12, XP002551706.
Brown I., et al.: "A Proxy Approach to E-Mail Security", Software Practice & Experience, John Wiley & Sons Ltd. Chichester, GB, vol. 29, No. 12, Oct. 1999, pp. 1049-1060, XP00852351.
Brown M., et al.: "PGP in Constrained Wireless Devices", Proceedings of the 9th Usenix Security Symposium, Denver, CO, Aug. 14-17, 2000, XP002210575.
Butrico M. et al.: "Enterprise data access from mobile computers: an end-to-end story" Research Issues in Data Engineering, 2000. Ride 2000. Proceedings. Tenth International Workshop on San Diego, CA, USA Feb. 28-29, 2000, Los Alamitos, CA, USA, IEEE Comput. Soc. US, Feb. 28, 2000, pp. 9-16, XP010377083.
Certificate of Grant of Patent, Hong Kong Application No. 04103998.2, dated Apr. 24, 2009.
Certificate of Invention dated Sep. 19, 2012, Chinese Patent No. ZL200810009944.X.
Certificate of Patent dated Jan. 15, 2013, Canadian Patent Application No. 2,454,218.
Chadwick, D.W., et al., "Modifying LDAP to Support X.509-based PKIs", In Seventeenth Annual IFIP WG 11.3 Working Conference on Database and Applications Security at Estes Park, Colorado, Aug. 2003.
Cole R., et al: "An Architecture For a Mobile OSI Mail Access System", IEEE Journal ON Selected Areas in Communications, IEEE Inc., New York, US, vol. 7, No. 2, Feb. 1989, pp. 249-256, XP000904914.
Co-pending U.S. Appl. No. 10/483,282 entitled, "System and Method for Secure Message Key Caching in in a Mobile Communication Device", filed Jan. 8, 2004.
Crocker S. et al. "MIME Object Security Services: rfc1848.text". IETF Standard, Internet Engineering Task Force, IETF, CH, Oct. 1995, XP015007633.
DeRoest J.: "Ubiquitous Mobile Computing" Sunexpert Magazine, ′Online! Jul. 1998, pp. 54-56, SP002213003 Retrieved from the Internet: <URL:http://swexpert.com/C8/SE.C8.JUL.98.pdf> retrieved on Sep. 10, 2002.
DeRoest J.: "Ubiquitous Mobile Computing" Sunexpert Magazine, 'Online! Jul. 1998, pp. 54-56, SP002213003 Retrieved from the Internet: retrieved on Sep. 10, 2002.
Dusse et al., "S/MIME Version 2 Message Specification," Mar. 1998, pp. 1-37.
Dusse et al.: "S/MIME Version 2 Certificate Handling," Database IETF RFC Online IETF: RFC 2312, Mar. 1998, pp. 1-20 (Chapter 2.1, Chapter 4.1), XP002220385.
Encrypt Pre-shared Keys in Cisco IOS Router Configuration Example, Document 1D 46420 Cisco Systems, Internet Address: htto:/lwww.cisco.com/en/US/tech/tk5S3/tk3721technologies-configuration-example09186a00801f2336.shtml.
EPO Communication Pursuant to Article 71(3) EPC (Decision to Grant), in connection with Application No. 02754007.9-2413 dated May 15, 2008.
EPO Communication Pursuant to Article 94(3) EPC, in connection with Application No. 02752898.3-2413, dated May 6, 2010.
EPO Communication Pursuant to Article 96(2) EPC, in connection with Application No. 02752898.3-2413, dated Jun. 2, 2004.
EPO Communication Pursuant to Article 96(2) EPC, in connection with Application No. 02752898.3-2413, dated Mar. 2, 2006.
EPO Communication Pursuant to Article 96(2) EPC, in connection with Application No. 02754007.9-2413 dated Aug. 17, 2007.
EPO Communication Pursuant to Article 96(2) EPC, in connection with Application No. 02754007.9-2413 dated Jul. 26, 2006.
Eskicioglu et al. "A Key Transport Protocol Based on Secret Sharing Applications to Information Security", IEEE Transactions on Consumer Electronics, vol. 46, No. 4, Nov. 2002, pp. 816-824.
Examiner Interview Summary Record, dated Jun. 7, 2007 for U.S. Appl. No. 10/486,406.
Examiner's Answer dated May 23, 2013, U.S. Appl. No. 10/483,282.
Final Office Action from USPTO dated Apr. 30, 2009 for U.S. Appl. No. 10/483,282.
Final Office Action from USPTO dated Aug. 9, 2011 for U.S. Appl. No. 10/483,282.
First Office Action, Chinese Application No. 02817741.X, dated Mar. 9, 2007.
First Office Action, Chinese Application No. 02819798.4, dated Jun. 9, 2006.
First Office Action, Chinese Application No. 200810009944.X, dated May 4, 2010.
Fourth Office Action, Chinese Application No. 02817741.X, dated Mar. 31, 2012.
Gong et al.: "Multicast Security and its Extension to a Mobile Environment," SRI International, Computer Science Laboratory, J.C. Baltzer AG, Science Publishers, Wireless Networks I (1995) pp. 281-295.
Hämetvaara, Vesa. "Certificate Management in Mobile Devices", University of Tampere, Department of Computer and Information Sciences, Master's Thesis, May 14, 2002.
Harris A.: "Content Privacy and Content Security Working Together", Internet Article. Content Technologies White Paper, Online! Sep. 1999, XP002223158, pp. 8-9.
Hoffman: "Enhanced Services For S/MIME," Database IETF RFC Online IETF; RFC 2634, Jun. 1999, pp. 1-58 (Chapter 3, pp. 24-32), XP002220386.
Housley, R. et al. "Internet X.509 Pubic Key Infrastructure Certificate and CRL Profile (RFC 2459)", Jan. 1999.
International Preliminary Examination Report for PCT/CA02/01060 dated Oct. 23, 2003.
International Preliminary Examination Report for PCT/CA02/01225 dated Dec. 4, 2003.
International Search Report for PCT/CA02/01060 dated Nov. 26, 2002.
International Search Report for PCT/CA02/01225 mailed Feb. 27, 2003.
Interview Summary dated Jun. 10, 2011 for U.S. Appl. No. 10/483,282.
Jin Jing et al.: "Client-server computing in mobile environments" ACM Computing Surveys, Jun. 1999, ACM, USA, vol. 31, No. 2, pp. 117-157, XP002212945.
Katsuro Inaya, et al., "Use Windows CE now", ASCII, Oct. 1, 1999, vol. 23, No. 10, pp. 266-285.
Kiely, Don, Sal Server 2005 Secures Your Data Like Never Before, Sep. 29, 2005. Internet Address: http://www.devx.com|codemag|Article/29351?trk=DXESS-DB.
Kiely, Don, Sal Server 2005 Secures Your Data Like Never Before, Sep. 29, 2005. Internet Address: http://www.devx.com|codemag|Article/29351?trk=DXESS—DB.
Kotzanikoloau et al. "Hybrid Key Establishment for Multiphase Self-Organized Sensor Networks", 6 IEEE International Symposium on a World of Wireless Mobile and Multimedia Networks, Jun. 13-16, 2005, pp. 581-587.
Lai, M.K.E., et al.: "A Mobile Subscriber Proxy Preserving Writer-to-Reader Message Security", Military Communications Conference, 1996, Milcom '96, Conference Proceedings, IEEE McLean, VA, USA Oct. 21-24, 1996, New York, NY, USA, IEEE, US, Oct. 21, 1996, pp. 461-467, XP010203896 (XP00090914).
Levien: "Protecting Internet E-Mail From Prying Eyes," Data Communications, McGraw Hill, New York, US, vol. 25, No. 6 (May 1, 1996), pp. 117-118, 120, 122, XP 000587586.
Mambo M. et al.: "Proxy Signatures: Delegation of the Power to Sign Messages" IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, IECE Tokyo, JP, vol. E79-A, No. 9, Sep. 1, 1996, pp. 1338-1353, XP000679624.
Myers, M. et al. "Certificate Management Messages over CMS (RFC 2797)", Apr. 2000.
Nakajima et al.: "Adaptive continuous media applications in mobile computing environments" Multimedia Computing Systems '97. Proceedings., IEEE International Conference on Ottawa, Ont., Canada Jun. 3-6, 1997, Los Alamitos, CA, USA, IEEE Comput. Soc. US, Jun. 3, 1997, pp. 152-160, XP010239184.
Notice of Allowance (Notification for the Grant of Invention), Chinese Application No. 02819798.4, dated Nov. 30, 2007.
Notice of Allowance from USPTO dated Jul. 22, 2011 for U.S. Appl. No. 10/486,406.
Notice of Allowance from USPTO dated Mar. 22, 2011 for U.S. Appl. No. 10/486,406.
Notice of Allowance from USPTO dated Nov. 29, 2010 for U.S. Appl. No. 10/486,406.
Notice of Allowance, Canadian Application No. 2,454,218, dated Aug. 21, 2012.
Notice of Allowance, Canadian Application No. 2,456,839, dated Sep. 4, 2009.
Notice of Appeal and Appeal Brief dated Jan. 22, 2013, U.S. Appl. No. 10/483,282.
Notice of Appeal dated Oct. 30, 2009 for U.S. Appl. No. 10/483,282.
Notice of Appeal to USPTO dated Jun. 24, 2009 for U.S. Appl. No. 10/486,406.
Notice of Revocation of Rejection Decision, Chinese Application No. 02817741.X, dated Aug. 18, 2010.
Notification of Grant, Chinese Application No. 02817741, dated Sep. 5, 2012.
Notification of Grant, Chinese Application No. 200810009944.X, dated Jul. 12, 2012.
Notification of Grant, Chinese Application No. 200810009944.X, dated Jun. 6, 2012.
Office Action dated Oct. 25, 2012 for U.S. Appl. No. 10/483,282.
Office Action from USPTO dated Feb. 2, 2012 for U.S. Appl. No. 10/483,282.
Office Action from USPTO dated Jan. 6, 2009 for U.S. Appl. No. 10/486,406.
Office Action from USPTO dated Jul. 8, 2008 for U.S. Appl. No. 10/483,282.
Office Action from USPTO dated Jun. 23, 2010 for U.S. Appl. No. 10/486,406.
Office Action from USPTO dated Jun. 30, 2008 for U.S. Appl. No. 10/486,406.
Office Action from USPTO dated Mar. 20, 2007 for U.S. Appl. No. 10/486,406.
Office Action from USPTO dated Mar. 4, 2010 for U.S. Appl. No. 10/483,282.
Office Action from USPTO dated Nov. 10, 2009 for U.S. Appl. No. 10/486,406.
Office Action from USPTO dated Nov. 13, 2007 for U.S. Appl. No. 10/486,406.
Office Action from USPTO dated Oct. 18, 2010 for U.S. Appl. No. 10/483,282.
Office Action from USPTO dated Oct. 5, 2007 for U.S. Appl. No. 10/483,282.
Office Action from USPTO dated Sep. 29, 2011 for U.S. Appl. No. 12/686,046.
Office Action from USPTO dated Sep. 8, 2006 for U.S. Appl. No. 10/486,406.
Office Action, Canadian Application No. 2,454,218, dated Aug. 23, 2011.
Office Action, Canadian Application No. 2,454,218, dated Aug. 6, 2008.
Office Action, Canadian Application No. 2,454,218, dated Jul. 23, 2007.
Office Action, Canadian Application No. 2,454,218, dated Mar. 7, 2005.
Office Action, Canadian Application No. 2,454,218, dated May 12, 2010.
Office Action, Canadian Application No. 2,456,839, dated Apr. 15, 2008.
Patent Certificate dated Dec. 5, 2012, Chinese Patent Application No. 02817741.
Policht, Martin, Sal Server 2005 Security-Part 3 Encryption, Database Journal Internet Address: http://www.databasejournal.com/features/mssql/article.php/34S3931.
Pre-Brief Appeal Conference Decision dated Aug. 13, 2009 for U.S. Appl. No. 10/486,406.
Pre-Brief Appeal Conference Decision dated Dec. 18, 2009 for U.S. Appl. No. 10/483,282.
Pre-Brief Appeal Conference Request dated Jun. 24, 2009 for U.S. Appl. No. 10/486,406.
Ramsdell, D. et al. "Secure/Multi-purpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling (RFC 3850)", Jul. 2004.
Rejection Decision, Chinese Application No. 02817741.X, dated Mar. 29, 2010.
Reply Brief dated Jul. 23, 2013 for U.S. Appl. No. 10/483,282.
Request for Continued Examination (RCE) dated Aug. 22, 2007 for U.S. Appl. No. 12/486,406.
Request for Continued Examination (RCE) dated Feb. 25, 2011 for U.S. Appl. No. 10/486,406.
Request for Continued Examination dated Jun. 21, 2011 for U.S. Appl. No. 10/486,406.
Research in Motion Limited, Blackberry Security White Paper Release 4.0 2005 Internet Address: http://blackberry.com|knowledgecenterpubliclivelink.exe?func=ll&objld=S2S044&objAction=browse&sort=name.
Response in connection with EP Application No. 02752898.3-2413, dated Dec. 9, 2004.
Response in connection with EP Application No. 02752898.3-2413, dated Nov. 15, 2010.
Response in connection with EP Application No. 02752898.3-2413, dated Sep. 12, 2006.
Response in connection with EP Application No. 02754007.9-2413, dated Feb. 27, 2008.
Response in connection with EP Application No. 02754007.9-2413, dated Nov. 27, 2006.
Response to Office Action from USPTO dated Aug. 3, 2010 for U.S. Appl. No. 10/483,282.
Response to Office Action from USPTO dated Dec. 12, 2006 for U.S. Appl. No. 10/486,406.
Response to Office Action from USPTO dated Feb. 12, 2010 for U.S. Appl. No. 10/486,406.
Response to Office Action from USPTO dated Feb. 15, 2011 for U.S. Appl. No. 10/483,282.
Response to Office Action from USPTO dated Jan. 8, 2009 for U.S. Appl. No. 10/483,282.
Response to Office Action from USPTO dated Jul. 19, 2007 for U.S. Appl. No. 10/486,406.
Response to Office Action from USPTO dated Jun. 30, 2009 for U.S. Appl. No. 10/483,282.
Response to Office Action from USPTO dated Mar. 13, 2008 for U.S. Appl. No. 10/486,406.
Response to Office Action from USPTO dated Mar. 5, 2008 for U.S. Appl. No. 10/483,282.
Response to Office Action from USPTO dated Mar. 6, 2009 for U.S. Appl. No. 10/486,406.
Response to Office Action from USPTO dated Nov. 4, 2011 for U.S. Appl. No. 10/483,282.
Response to Office Action from USPTO dated Oct. 30, 2008 for U.S. Appl. No. 10/486,406.
Response to Office Action from USPTO dated Sep. 16, 2010 for U.S. Appl. No. 10/486,406.
Response, U.S. Appl. No. 10/483,282, dated Apr. 27, 2012.
Russell S: "Fast checking of individual certificate revocation on small systems" Computer Security Applications Conference, 1999. (ACSAC '99). Proceedings. 15th Annual Phoenix, AZ, USA Dec. 6-10, 1999, Los Alamitos, CA, USA, IEEE Comput. Soc. US. Dec. 6, 1999, pp. 249-255, XP010368617.
Second Office Action, Chinese Application No. 02817741.X, dated Jan. 25, 2008.
Second Office Action, Chinese Application No. 02819798.4, dated Jul. 20, 2007.
Second Office Action, Chinese Application No. 200810009944.X, dated May 25, 2011.
Stale Schumacher: "AutoPGP FAQ, Version 1," Internet Newsgroup, ′Online (Apr. 19, 1994), XP002230742.
Stallings, W.: "S/MIME: E-mail Gets Secure". Byte, McGraw-Hill Inc., St. Peterborough, US, vol. 23, No. 7, Jul. 1998, pp. 41-42, XO000774260.
Subramanyam V., et al.: "Security in mobile systems", Reliable Distributed Systems, 1998 Proceedings. 17th IEEE Symposium on W. Lafayette, IN, USA, Oct. 20-23, 1998, Los Alamitos, CA, USA IEEE Comput. Soc., US. Oct. 20, 1998, pp. 407-412, XP010319125.
Syverson: "Limitations on Design Principles for Public Key Protocols," Security and Privacy, 1996, Proceedings, 1996 IEEE Symposim on Oakland, CA, USA, May 6-8, 1996, Los Alamitos, CA, USA, IEEE Comput. Soc., US, May 6, 1996, pp. 62-72, XP010164926.
Third Office Action, Chinese Application No. 02817741.X, dated Nov. 10, 2011.
Third Office Action, Chinese Application No. 200810009944.X, dated Mar. 1, 2012.
Torvinen V.; "Wireless PKI: Fundamentals", Internet Article, Radicchio White Paper, ′Online! 2000, XP002223159, pp. 1-15.
Wasley D.L. et al.: "Improving Digitial Credential Management in Browsers" Internet Article. HEPKI-TAG Recommendation, ′Online! Jul. 21, 2000, XP02213004 Retrieved from the Internet: <URL:http://middleware.internet2.edu/hepk i-tag/HEPKI-TAG-Certs-Browser-03.pdf> retrieved on Feb. 10, 2002.
Written Opinion issued on Apr. 16, 2003 by European Patent Office for PCT/CA02/01060.
Written Opinion issued on Feb. 14, 2003 by European Patent Office for PCT/CA02/01060.
Written Opinion issued on Jul. 1, 2003 by European Patent Office for PCT/CA02/01225.
Written Opinion issued on Sep. 12, 2003 by European Patent Office for PCT/CA02/01225.
Zollner J: "Gateways to Overcome Incompatibilities of Security Mechanisms" Reliable Distributed Systems, 1999. Proceedings of the 19th IEEE Symposium on Lausanne, Switzerland Oct. 19-22, 1999, Los Alamitos, Cal., USA, IEEE Comput. Soc, US Oct. 19, 1999, pp. 372-377.
CN1565112A (en) 2005-01-12 application
CA2456839C (en) 2010-05-18 grant
CA2456839A1 (en) 2003-02-20 application
EP1417814B1 (en) 2008-10-29 grant
WO2003015367A2 (en) 2003-02-20 application
US20040202327A1 (en) 2004-10-14 application
US20110320807A1 (en) 2011-12-29 application
CN101232504A (en) 2008-07-30 application
CN100380895C (en) 2008-04-09 grant
WO2003015367A3 (en) 2003-05-30 application
US8019081B2 (en) 2011-09-13 grant
CN101232504B (en) 2012-09-19 grant
EP1417814A2 (en) 2004-05-12 application
ES2315379T3 (en) 2009-04-01 grant
DE60229645D1 (en) 2008-12-11 grant
US20060036859A1 (en) 2006-02-16 Automated key management system and method
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LITTLE, HERBERT A.;BROWN, MICHAEL S.;REEL/FRAME:026876/0993