Patent Application
20180176256
Not applicable.
Not applicable.
Remote communication has dominated in-person communication for some time. Remote communication includes landline calls, mobile calls, texting, faxing, video chatting, instant messaging, and email. Email remains the dominant medium for communicating secure documents. However, identity thieves and others seek to exploit vulnerabilities in emails. Email providers therefore seek to develop new ways to insure email security.
A reliable recall function, temporal control, and access control are desirable for an email because the email may remain on a sender's device, in an email provider's server, or on a recipient's device so that another person may access the email at a later time, surreptitiously or otherwise. According to various embodiments of the present disclosure, embodiments for temporal control and access control of emails are provided. Control mechanisms in the emails require implementation of the temporal control and the access control. Senders of the emails may recall, or cancel, emails at any time. A security server implementing the control mechanisms need not store the emails, thus reducing a storage load of the security server. The security server encrypts the emails using public keys and private keys, but keeps those keys separate. Thus, because the security server does not store the emails and because the security server separates the public key from the private key, a hack into the security server may yield encryption records of the emails and private keys associated with the emails, but not the emails themselves or the public keys associated with the emails. A hack into recipient devices may yield emails, but not the private key necessary to decrypt the emails. The security server implementing the control mechanisms obviates the problem of recipient devices turning their clocks back to defeat any temporal control mechanisms. As a result, the control mechanisms provide a peace of mind to email senders. Though the disclosure focuses on emails, the disclosed embodiments may apply to other communication media as well.
In one embodiment, the disclosure includes a sender device comprising: a non-transitory memory storage comprising instructions and a temporal control policy; a processor coupled to the memory, wherein the processor executes the instructions to: generate an email; generate a control mechanism for the email, wherein the control mechanism instructs a security server to implement the temporal control policy, and wherein the temporal control policy affects a recipient device's use of the email; and integrate the control mechanism into the email to generate an integrated email; and a transmitter coupled to the processor and configured to transmit the integrated email to the security server for the security server to implement the control mechanism. In some embodiments, the control mechanism comprises an open date field that requires that the email be destroyed if the recipient device does not open the email before an open date; the control mechanism comprises a timer field that requires that the email be destroyed when a timer expires; the control mechanism comprises a maximum openings number field that requires that the email be destroyed when the recipient device opens the email a number of times corresponding to a maximum openings number; the control mechanism comprises an invalidation number field that requires that the email be destroyed when an invalidation counter exceeds the invalidation number; the sender device further comprises a receiver coupled to the processor and configured to receive from the security server a receipt indicating that the security server successfully transmitted the email; the processor executes the instructions further to generate a recall request requesting that the security server instruct the recipient device to destroy the email, and wherein the transmitter is further configured to transmit the recall request to the security server; the sender device further comprises a receiver coupled to the processor and configured to receive, from the security server and in response to the recall request, a destruction confirmation confirming that the recipient device destroyed the email.
In another embodiment, the disclosure includes a security server comprising: a non-transitory memory storage comprising instructions; a receiver configured to receive an email comprising a control mechanism, wherein the control mechanism instructs the security server to implement a temporal control policy that affects a recipient device's use of the email; a processor coupled to the memory and the receiver, wherein the processor executes the instructions to: generate a public key; generate a private key; and encrypt the email using the public key and the private key to create an encrypted email; and a transmitter coupled to the processor and configured to transmit the encrypted email and the public key to the recipient device. In some embodiments, the processor further executes the instructions to destroy the email and the encrypted email after the transmitting; the processor further executes the instructions to destroy the public key after the transmitting; the receiver is further configured to receive a validation request from the recipient device, and wherein the processor is further configured to perform a validation of the recipient device in response to the validation request; the processor further executes the instructions to generate a decryption instruction when the processor determines that the recipient device has complied with the control mechanism, and wherein the transmitter is further configured to transmit the decryption instruction and the private key to the recipient device; the processor is further configured to generate a destruction instruction when the processor determines that the recipient device has not complied with the control mechanism, and wherein the transmitter is further configured to transmit the destruction instruction to the recipient device; receiver is further configured to receive a destruction confirmation from the recipient device in response to the destruction instruction; the destruction instruction includes a predetermined destruction period, and wherein the security server is configured to disable an application in the recipient device responsible for opening the email when the security server does not receive a destruction confirmation from the recipient device by the predetermined destruction period.
In yet another embodiment, the disclosure includes a method implemented by a recipient device, the method comprising: receiving an encrypted email comprising a control mechanism, wherein the control mechanism implements a temporal control policy that affects temporal use or both temporal use and access use of the encrypted email by the recipient device; receiving a public key associated with the encrypted email; transmitting a validation request; and receiving a decryption instruction comprising a private key when the recipient device complies with the control mechanism. In some embodiments, the method further comprises: decrypting the encrypted email to create a decrypted email in response to the decryption instruction; the method further comprises: receiving a first destruction instruction when the apparatus does not comply with the control mechanism; destroying the encrypted email and the public key in response to the first destruction instruction; generating a destruction confirmation in response to the first destruction instruction; and transmitting the destruction confirmation in response to the first destruction instruction; the method further comprises: receiving a second destruction instruction when a sender device requests a recall of the encrypted email; and destroying the encrypted email and the public key in response to the second destruction instruction.
Any of the above embodiments may be combined with any of the other above embodiments to create a new embodiment. These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that, although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
The following acronyms and initialisms apply:
ASIC: application-specific integrated circuit
CPU: central processing unit
DSP: digital signal processor
email: electronic mail
EO: electrical-to-optical
FPGA: field-programmable gate array
GUI: graphical user interface
ID: identifier
LAN: local area network
OE: optical-to-electrical
RAM: random-access memory
ROM: read-only memory
RSA: Rivest-Shamir-Adleman
RX: receiver
SRAM: static RAM
SSH: Secure Shell
TCAM: ternary content-addressable memory
TX: transmitter
UUID: universally unique ID
WAN: wide area network.
Emails often contain sensitive information. As a first example, when a customer purchases a product or a service, a product company may send to the customer an email with a receipt containing the customer's email address, physical address, phone number, and other information. As a second example, an insurance company may send to an insured a policy containing the insured's birth date and social security number. However, current email techniques do not provide sufficient security for such emails.
First, a sender of an email may not send the email in a secure manner. Second, the sender may need to perform an explicit action in order to recall the email when it becomes stale, and an available recall function may be unsuccessful. Third, the sender has no ability to implement temporal control or access control of the email. A reliable recall function, temporal control, and access control are desirable because the email may remain on the sender's device, in an email provider's server, or on a recipient's device so that another person may access the email at a later time, surreptitiously or otherwise.
Disclosed herein are embodiments for temporal control and access control of emails. Control mechanisms in the emails require implementation of the temporal control and the access control. Senders of the emails may recall, or cancel, emails at any time. A security server implementing the control mechanisms need not store the emails, thus reducing a storage load of the security server. The security server encrypts the emails using public keys and private keys, but keeps those keys separate. Thus, because the security server does not store the emails and because the security server separates the public key from the private key, a hack into the security server may yield encryption records of the emails and private keys associated with the emails, but not the emails themselves or the public keys associated with the emails. A hack into recipient devices may yield emails, but not the private key necessary to decrypt the emails. The security server implementing the control mechanisms obviates the problem of recipient devices turning their clocks back to defeat any temporal control mechanisms. As a result, the control mechanisms provide a peace of mind to email senders. Though the disclosure focuses on emails, the disclosed embodiments may apply to other communication media as well.
The sender device 105 is a mobile phone, tablet computer, notebook, or other network-enabled device associated with a sender. The sender device 105 comprises an application 110 and a GUI 115, among other things. The application 110 generates, sends, receives, and processes emails. The GUI 115 provides an interface for a sender to interact with the application 110.
The network 120 enables communication between the sender device 105 and the recipient device 140. The network 120 is a LAN, a WAN, a mobile phone network, the Internet, or another suitable network. Alternatively, the network 120 comprises any combination of such networks.
The email server 125 hosts and services emails exchanged between the sender device 105 and the recipient device 140. The security server 130 comprises and executes an application 135 that provides security services for the emails exchanged between the sender device 105 and the recipient device 140. Multiple entities or the same entity control the email server 125 and the security server 130. The email server 125 and the security server 130 may be separate servers as shown or may be a single server.
The recipient device 140 is similar to the sender device 105 and is associated with a recipient. The recipient device 140 comprises an application 145 and a GUI 150, among other things, which are similar to the application 110 and the GUI 115, respectively. The applications 110, 135, 145 may be the same application or different applications. For instance, the application 135 may be a server-based version of the applications 110, 145. In addition, the applications 110, 135, 145 may be in communication with each other. For instance, the application 135 communicates with the applications 110, 145 in order to maintain control of the applications 110, 145.
The processor 230 is any suitable combination of hardware, middleware, firmware, and software. The processor 230 comprises any combination of one or more CPU chips, cores, FPGAs, ASICs, or DSPs. The processor 230 communicates with the ingress ports 210, RX 220, TX 240, egress ports 250, and memory 260. The processor 230 comprises a security component 270, which implements the disclosed embodiments. The inclusion of the security component 270 therefore provides a substantial improvement to the functionality of the device 200 and effects a transformation of the device 200 to a different state. Alternatively, the memory 260 stores the security component 270 as instructions, and the processor 230 executes those instructions.
The memory 260 comprises one or more disks, tape drives, or solid-state drives. The device 200 may use the memory 260 as an over-flow data storage device to store programs when the device 200 selects those programs for execution and to store instructions and data that the device 200 reads during execution of those programs. The memory 260 may be volatile or non-volatile and may be any combination of ROM, RAM, TCAM, or SRAM.
The control mechanism comprises the fields listed in Table 1.
The open date comprises, in any suitable format, a date such as Jun. 10, 2018; a time such as 12:30 μm; or both a date and a time such as Jul. 1, 2018 at 12:00 μm. The timer comprises a value of a time such as 45 minutes or a date such as Jul. 1, 2018 at 12:00 μm. The value is loaded into the timer and indicates a lifetime of the email, and the email will be destroyed when the timer expires. The timer can be loaded in multiple ways, at multiple times, or at specific occurrences. The recipient device 140 in some embodiments triggers the timer by opening the email before the open date. The maximum openings number may refer to when the recipient device 140 successfully opens the email. The invalidation number may require that the email be destroyed when the security server 130 invalidates the recipient device 140 a number of times corresponding to the invalidation number. The sender device 105 integrates the control mechanism into the email. The open date field and the timer field may together be referred to as temporal control of temporal use, and the maximum openings number and the invalidation number may together be referred to as access control of access use. Enforcement of the temporal control is referred to as a temporal control policy, and enforcement of the access control is referred to as an access control policy.
Though the message sequence diagram 300 shows that the sender device 105 generates the control mechanism, the security server 130 may partially generate or amend the control mechanism. As a first example, the sender device 105 generates the open date field and the timer field, and the security server 130 generates the maximum openings number and the invalidation number. As a second example, the sender device 105 generates all fields in the control mechanism, but the security server 130 reduces the maximum openings number or the invalidation number. The security server 130 may do so if it determines that the recipient device 140 has an out-of-date operating system, is otherwise a security threat, or for other reasons.
Though the recipient device 140 is described as triggering the timer, above, the running of the timer can be initiated by the control mechanism. The timer can be initiated to run in different ways, which can be predetermined or which optionally can be configured by the sender.
The running of the timer can be initiated when the email is sent, in some embodiments, giving the recipient a predetermined time period in which the recipient can open and/or retain the email. In some embodiments, the timer begins running when the e-mail is transmitted by the sender device 105. Alternatively, in other embodiments, the timer begins running when it is received by the email server 125 or when it is received by the security server 130. In yet another alternative, the timer begins running when it is either received by the recipient device 140 or is temporarily stored for reception (such as when the email is temporarily stored on an email server, router, or other intermediate device or network facility, ready to be delivered to the recipient device 140).
The timer can be initiated when the recipient first attempts validation. The timer in this embodiment gives the recipient a predetermined time period to open the email after a first validation attempt. It should be understood that additional initiation points can be used with the timer, and are within the scope of the description and claims.
At step 320, the sender device 105 transmits to the security server 130 the email with the control mechanism. Alternatively, the sender device 105 transmits the email to the email server 125, which recognizes the control mechanism and forwards the email to the security server 130. The sender device 105 may do so using SSH or another suitable protocol. All communications among the sender device 105, the security server 130, and the recipient device 140 may use SSH.
At step 330, the security server 130 encrypts the email and records an encryption record. Specifically, first, the security server 130 generates a UUID and a random key pair using any suitable method. The key pair comprises a public key and a private key. Second, the security server encrypts the email with the key pair using, for instance, RSA encryption, which is described in “RSA (cryptosystem),” https://en.wikipedia.org/wiki/RSA_(cryptosystem), Sep. 16, 2016, which is incorporated by reference. Third, the security server 130 generates an encryption record based on the encryption. The encryption record comprises the fields listed in Table 2.
The sender ID and the recipient ID are email addresses or ID numbers that uniquely identify email accounts of the sender and the recipient, respectively. There may be multiple recipient IDs if there are multiple recipient devices such as the recipient device 140. The open date field, timer field, maximum openings number field, and invalidation number field in the encryption record in Table 2 correspond to the control mechanism in Table 1. The security server 130 initializes the opening counter and the invalidation counter to 0. Fourth, in step 330, the security server 130 records the encryption record in an encryption record table, which may comprise encryption records associated with other emails.
At step 340, the security server 130 transmits the public key and the encrypted email to the recipient device 140, along with the control mechanism. The security server 130 destroys the encrypted email, thus saving storage space in the security server 130. In addition, the security server 130 destroys the public key and records the transmission date in the encryption record. The transmission date comprises, in any suitable format, a date such as Jun. 10, 2018; a time such as 12:30 μm; or both a date and a time such as Jul. 1, 2018 at 12:00 μm.
Finally, at step 350, the security server 130 transmits a receipt to the sender device 105. The receipt indicates that the security server 130 successfully transmitted the encrypted email (with the control mechanism) to the recipient device 140. Though the message sequence diagram 300 shows secure communication between the security server 130 and the recipient device 140, communication between the sender device 105 and the security server 130 may likewise be secure in the same manner or in another suitable manner.
At step 420, the security server 130 validates the recipient device 140 based on the validation request. Specifically, first, the security server 130 confirms that its encryption record table comprises an encryption record corresponding to the UUID in the validation request. Second, the security server 130 reads the encryption record corresponding to the UUID in the validation request. Third, the security server 130 confirms that the recipient ID in the validation request is in the encryption record. Fourth, the security server 130 confirms that a reception date corresponding to the date the security server 130 receives the validation request from the recipient device 140 is on or before the open date. The open date is a predetermined date specified by the sender. The recipient can only open the received email before or on the open date. Once the open date has passed, the recipient cannot open the email. Fifth, the security server 130 confirms that the reception date is not beyond a date corresponding to a sum of the transmission date and the timer. Sixth, the security server 130 confirms that the opening counter does not exceed the maximum openings number and that the invalidation counter does not exceed the invalidation number. Seventh, in step 420, the security server 130 validates the public key with the private key.
At step 430, the security server 130 increments the opening counter. At step 440, the security server 130 transmits a decryption instruction to the recipient device 140. The decryption instruction comprises an encrypted version of the private key and instructs the recipient device 140 that the recipient device 140 may decrypt the encrypted email.
Finally, at step 450, the recipient device 140 decrypts and displays the email. The recipient device 140 decrypts the encrypted email (generating a decrypted email) using the public key and the private key. After decrypting the email, the application 145 in the recipient device 140 destroys the private key. The application 145 may prevent the recipient device 140 from saving the decrypted email or taking a screenshot of the decrypted email. Thus, the recipient device 140 may be required to again obtain the private key from the security server 130 in order to decrypt and display the encrypted email. The public key and the private key are at the same location two times for a brief period, namely at the security server 130 when it first generates the public key and the private key and at the recipient device 140 when it receives the private key in the decryption instruction. The application 135 in the security server 130 or the application 145 in the recipient device 140 prevents the recipient device 140 from caching the private key. Specifically, if the recipient device 140 attempts to cache the private key, then the application 135 in the security server 130 disables the application 145 in the recipient device 140. The application 145 may also destroy the email.
At step 520, the security server 130 invalidates the recipient device 140 based on the validation request. Specifically, the security server 130 invalidates the recipient device 140 if the UUID in the validation request is not in the encryption record table. Alternatively, the security server 130 confirms that the encryption record table comprises an encryption record corresponding to the UUID in the validation request and proceeds as follows. First, the security server 130 reads the encryption record corresponding to the UUID in the validation request. Second, the security server 130 invalidates the recipient device 140 if at least one of the following conditions is met: the recipient ID in the validation request is not in the encryption record, a reception date (corresponding to the date the security server 130 receives the validation request from the recipient device 140) is after the open date, the reception date is beyond a date corresponding to a sum of the transmission date and the timer, the opening counter meets or exceeds the maximum openings number, or the invalidation counter meets or exceeds the invalidation number.
At step 530, the security server 130 increments the invalidation counter. At step 540, the security server 130 transmits a destruction instruction to the recipient device 140. The destruction instruction instructs the application 145 on the recipient device 140 to destroy the email, destroy the private key, and transmit to the security server 130 a destruction confirmation upon doing so. The destruction instruction may comprise a predetermined destruction period by which the recipient device 140 is required to perform those actions. Email destruction may occur without an invalidation step or process, such as when the lifespan of the email expires. Alternatively, when the lifespan expires, the email is invalidated as part of (or to trigger) the destruction of the email. At step 550, the recipient device 140 destroys the email and the public key.
Finally, at step 560, the recipient device 140 transmits a destruction confirmation to the security server 130. The destruction confirmation confirms that the recipient device 140 has destroyed both the email and the private key. If the destruction instruction comprises the predetermined destruction period and if the security server 130 does not receive the destruction confirmation from the recipient device 140 by the predetermined destruction period, then in some embodiments the application 135 in the security server 130 disables the application 145 in the recipient device 140. Alternatively, the security server 130 first transmits one or more requests for destruction confirmation.
At step 620, the security server 130 verifies the recall request and the sender device 105. Specifically, first, the security server 130 confirms that its encryption record table comprises an encryption record corresponding to the UUID in the recall request. Second, the security server 130 reads the encryption record corresponding to the UUID in the recall request. Third, the security server 130 confirms that the sender ID in the recall request is in the encryption record. At step 630, the security server 130 destroys the private key. In some embodiments, the destruction of the private key renders validation of the email impossible.
At step 640, the security server 130 transmits a destruction instruction to the recipient device 140. The destruction instruction instructs the recipient device 140 to destroy the email and transmit to the security server 130 a destruction confirmation upon doing so. The destruction instruction may comprise a predetermined destruction period by which the recipient device 140 is required to perform those actions. At step 650, the recipient device 140 destroys the email and the public key.
At step 660, the recipient device 140 transmits a destruction confirmation to the security server 130. The destruction confirmation confirms that the recipient device 140 destroyed the email. If the destruction instruction includes the predetermined destruction period and if the security server 130 does not receive the destruction confirmation from the recipient device 140 by the expiration of the predetermined destruction period, then the application 135 in the security server 130 disables the application 145 in the recipient device 140 in some embodiments. Alternatively, the security server 130 first transmits one or more requests for destruction confirmation. Finally, at step 670, the security server 130 forwards the destruction confirmation to the sender device 105.
Independently of the message sequence diagrams 300, 400, 500, 600, the security server 130 may transmit to the recipient device 140 a destruction instruction. The security server 130 may do so if the open date expires before the recipient device 140 transmits a validation request to the security server 130, the timer expires, the opening counter reaches the maximum openings number, or the invalidation counter reaches the invalidation number. The destruction instruction instructs the recipient device 140 to destroy the email, destroy the private key, and transmit to the security server 130 a destruction confirmation upon doing so. The destruction instruction may comprise a predetermined destruction period by which the recipient device 140 is required to perform those actions.
The email can be destroyed by the recipient device 140. The email can be destroyed by the recipient device 140 when the number of failed access attempts exceeds the invalidation number. The email can be destroyed by the recipient device 140 when the maximum number of openings has been met or exceeded, i.e., a count of the number of openings of the email exceeds the maximum openings number. The email can be destroyed by the recipient device 140 when the email has not been opened by the recipient by the open date. The email can be destroyed by the recipient device 140 when a lifespan of the email has expired, such as when the timer expires. The email can be destroyed by the recipient device 140 when a validation process fails. The email can be destroyed by the recipient device 140 when the recipient decides to destroy the email, and the email still is valid and in existence.
The email can be destroyed by the security server 130. The email can be destroyed by the security server 130 when the number of failed access attempts exceeds the invalidation number. The email can be destroyed by the security server 130 when the maximum number of openings has been met or exceeded, i.e., a count of the number of openings of the email exceeds the maximum openings number. The email can be destroyed by the security server 130 when the email has not been opened by the recipient by the open date. The email can be destroyed by the security server 130 when a validation process fails. The email can be destroyed by the security server 130 when the UUID received in a validation process is incorrect. The email can be destroyed by the security server 130 when the sender ID received in a validation process is incorrect. The email can be destroyed by the security server 130 when the recipient ID received in a validation process is incorrect.
As previously discussed, destruction of the encrypted e-mail at the recipient device 140 is accompanied by destruction of the public key by the application 145 on the recipient device 140. Further, destruction of the encrypted e-mail at the recipient device 140 is accompanied by destruction of the private key by the security server 130.
At decision diamond 710, the security server 130 determines whether the UUID is valid. Specifically, the security server 130 confirms that its encryption record table comprises an encryption record corresponding to the UUID in the validation request. If the result of decision diamond 710 is no, then the method 700 proceeds to step 715. At step 715, the security server 130 transmits an invalidation response to the recipient device 140. In addition, the security server 130 increments the invalidation counter to record the occurrence of a failed validation attempt. If the result of decision diamond 710 is yes, then the method 700 proceeds to decision diamond 720.
At decision diamond 720, the security server 130 determines whether the recipient ID is valid. Specifically, the security server 130 confirms that the recipient ID in the validation request is in the encryption record corresponding to the UUID. If the result of decision diamond 720 is no, then the method 700 proceeds to step 725. At step 725, the security server 130 transmits a destruction instruction to the recipient device 140. The destruction instruction instructs the recipient device 140 to destroy the email, destroy the private key, and transmit to the security server 130 a destruction confirmation upon doing so. The destruction instruction may comprise a predetermined destruction period by which the recipient device 140 is required to perform those actions, in some embodiments. Alternatively, if the result of the decision diamond 720 is no, then the method 700 proceeds to step 715. If the result of decision diamond 720 is no, then the method 700 proceeds to decision diamond 730.
At decision diamond 730, the security server 130 determines whether a reception date (corresponding to the date the security server 130 receives the validation request from the recipient device 140) is on or before the open date. If the result of decision diamond 730 is no, then the method 700 proceeds to step 725, which is described above. If the result of decision diamond 730 is yes, then the method 700 proceeds to decision diamond 735 in
Turning to
At decision diamond 740, the security server 130 determines whether a timer has expired. Specifically, the security server determines whether the reception date is beyond a date corresponding to a sum of a transmission date and a timer in an encryption record in the security server 130. If the result of decision diamond 740 is yes, then the method proceeds to step 745. At step 745, the security server 130 transmits the destruction instruction to the recipient device 140. If the result of decision diamond 740 is no, then the method 700 proceeds to decision diamond 755.
At decision diamond 755, the security server 130 determines whether an opening counter is less than or equal to a maximum openings number in the encryption record. If the result of decision diamond 755 is no, then the method 700 proceeds to step 745, which is described above. If the result of decision diamond 755 is yes, then the method 700 proceeds to decision diamond 760 in
Turning to
At step 770, the security server 130 increments an opening counter in the encryption record. Finally, at step 775, the security server 130 transmits a decryption instruction to the recipient device 140. The decryption instruction comprises an encrypted version of the private key and instructs the recipient device 140 that it may decrypt the email.
In an example embodiment, an apparatus comprises a processing element configured to generate an email, generate a control mechanism for the email (wherein the control mechanism instructs a security server to implement temporal control of a recipient device's use of the email), and integrate the control mechanism into the email. A transmitting element coupled to the processing element is configured to transmit the email to the security server for the security server to implement the control mechanism.
While several embodiments have been provided in the present disclosure, it may be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and may be made without departing from the spirit and scope disclosed herein.
This application claims priority to U.S. provisional patent application No. 62/435,486 filed on Dec. 16, 2016 by Zongfang Lin, et al., and titled “Temporal Control and Access Control of Emails,” which is incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62435486 | Dec 2016 | US |
