/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432 DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 12-15 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 12, it depends from system claim 11 and recites, "The system of claim 11, further comprising: receiving the protected encrypted file with the encrypted portion and the security information portion from an external client device; and decrypting the encrypted portion using a data decryptor." However, "receiving" and "decrypting" are method steps or operations, not structural components of the claimed system. Claim 11 recites a system including a computer memory having instructions that, when executed, cause the client device to carry out operations. Claim 12 does not clearly state whether the additional "receiving" and "decrypting" operations are encompassed within the instructions of claim 11 (i.e., “The system of claim 11, wherein the instructions further comprise: receiving …; decrypting …”) or are intended to be method steps in combination with the system. Therefore, the metes and bounds of claim 12 are unclear. See MPEP 2173.05(p)(II).
Similarly regarding claim 13, claim 13 depends from system claim 11 and recites, "The system of claim 11, further comprising: receiving a file access request on the client device from an application requesting access to the protected unencrypted file; determining, based on the security information metadata, to grant limited access to the unencrypted content; and authorizing the application requesting file access with the limited access to the unencrypted content." However, "receiving," "determining," and "authorizing" are method steps or operations, not structural components of the claimed system. Since claim 11 recites a system with instructions that cause the client device to perform operations, claim 13 should clarify whether these additional operations are performed by the instructions. As written, the metes and bounds of claim 13 are unclear. See MPEP 2173.05(p)(II).
Regarding claim 14, claim 14 depends from claim 13 and recites, "wherein the security information metadata is enforced across multiple applications on the client device accessing the unencrypted content." Claim 13 is indefinite for the reasons discussed above. In addition, claim 14 recites result-oriented language that describes a past-tense state, without clearly identifying how any structure within claim 11 is affected. For example, it’s unclear whether the instructions are configured, when executed, to perform enforcement, etc., by the client device, or some other structure. Therefore, the metes and bounds of claim 14 are unclear.
Similar to claims 12 and 13, Regarding claim 15, claim 15 depends from system claim 13 and recites, "The system of claim 13, further comprising: receiving an additional protected encrypted file from an external device; creating an additional protected unencrypted file from the additional protected encrypted file, wherein the additional protected unencrypted file includes additional unencrypted content based on additional security information metadata bound to the additional unencrypted content being met; and re-encrypting the additional protected unencrypted file with the additional security information metadata." However, "receiving," "creating," "authorizing," and "re-encrypting" are method steps or operations, not structural components of the claimed system. Since claim 15 depends from a system claim, claim 15 should clarify whether these additional operations are performed by the instructions/client device. As written, the metes and bounds of claim 15 are unclear. See MPEP 2173.05(p)(II).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Limitations from claims 2, 12, and 17 are found to invoke 112f.
The limitation "data decryptor" is interpreted under 35 U.S.C. 112(f). The term "data decryptor" is a generic placeholder for structure that performs the function of decrypting data. Claims 2, 12, and 17 recite decrypting an encrypted portion or encrypted content "using a data decryptor," but the claims do not recite sufficient structure, material, or acts for performing the decrypting function.
Regarding claim 2, it recites "decrypting the encrypted portion to generate the unencrypted content using a data decryptor." The term "data decryptor" does not identify sufficient structure for performing the decrypting function.
Regarding claim 12, it recites "decrypting the encrypted portion using a data decryptor." For the same reasons discussed above, the term "data decryptor" is interpreted under 35 U.S.C. 112(f).
Regarding claim 17, it recites "decrypting encrypting content from the encrypted portion using a data decryptor to generate the unencrypted content." For the same reasons discussed above, the term "data decryptor" is interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tsai, U.S. Patent Application NO. US 20150188910 A1 in view of Smalley (“Implementing SELinux as a Linux Security Module”)
Regarding claim 1, claim 1 recites "generating, on a client device, security information metadata for unencrypted content" and "binding the security information metadata to the unencrypted content to create a protected unencrypted file on the client device." Tsai provides for file access control based on security/access information because Tsai discloses that the file management driver determines whether the client can access the file according to the certificate, and that "the certificate 3141 records the encrypted data and the authorized information for the policy group data (ex. the access control list of the policy group)" (Tsai; [0052]). However, Tsai does not explicitly provide for generating security information metadata for unencrypted content and binding that metadata to the unencrypted content to create a protected unencrypted file on the client device.
Smalley provides for the missing protected-unencrypted-file arrangement. In particular, Smalley discloses that the selinux_inode_init_security hook function is called when creating a new file in order to obtain the security attribute to assign to the new and to set up the inode security structure for the new inode. Smalley further discloses that this operation allows new inodes to be labeled as part of the inode creation transaction, and that the function generates the SELinux attribute name and the security context value for the inode for storage as the file security attribute (Smalley; Section 14.1.4). Smalley also discloses that file security contexts are stored in each filesystem using extended attributes (Smalley; Sections 4 and 5.3.1). The SELinux security context/extended attribute corresponds to the claimed security information metadata because it is file-associated security information used to control permissions for the file.
Claim 1 further recites "receiving a file access request on the client device from an application requesting access to the protected unencrypted file." Tsai provides for this limitation because Tsai discloses that when the file management driver detects a request from a file access application for executing a file open procedure and opening the file, the file management driver determines whether to allow the file access application to execute the file open procedure and access the file based on the certificate received (Tsai; claim 1). Tsai further discloses that the request is executed by the file access application installed in the client device, and the file management driver determines whether the client device has authority for opening the file of the policy group (Tsao; [0081]).
Claim 1 further recites "determining, based on the security information metadata, to grant limited access to the unencrypted content" and "authorizing the application requesting file access with the limited access to the unencrypted content based on determining to grant the limited access to the unencrypted content." Tsai provides for determining and allowing access based on security/access information because Tsai discloses that the certificate records authorized information for the policy group data, such as an access control list, and that the file management driver determines whether the client device has authority to open the file according to the certificate (Tsai; [0052], [0056], [0081]). Smalley further provides for enforcing limited file access based on the file-associated security information because Smalley discloses that inode_has_perm checks whether a task has a particular permission to an inode by calling the access vector cache to check the requested permission to the inode (Smalley; Section 14.2.1). Smalley further discloses that file_has_perm checks whether a task can use an open file descriptor to access a file in a given way and, if use permission is granted, checks the requested permissions to the file using inode_has_perm (Smalley; Section 15.2.1). Smalley also discloses that file permission checks are applied for operations such as read and write (Smalley; Section 15.2.2). This provides for granting limited access according to the security information associated with the file.
Smalley does not disclose encrypting the file content. Therefore, the file object protected by Smalley's security metadata and access-control arrangement is reasonably understood as unencrypted file content protected by security metadata.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify Tsai's file management driver based file protection system to include the SELinux file security content, extended attribute, and kernel access-control arrangement provided by Smalley, in order to enforce file access protections at the operating-system level for files whose content is not encrypted, thereby providing system-wide file access control across applications. Therefore, Tsai in view of Smalley provides for the limitations of claim 1.
Regarding claim 2, claim 2 depends from claim 1 and further recites "receiving a protected encrypted file that includes an encrypted portion and a security information portion" and "decrypting the encrypted portion to generate the unencrypted content using a data decryptor." As discussed above with respect to claim 1, Tsai in view of Smalley provides for the limitations of claim 1.
As to receiving the protected encrypted file, Tsai provides for this limitation because Tsai discloses that files stored in the first memory unit are not limited to files created or stored in the client device, and may be stored in a cloud apparatus, mobile storage device, or other storage device (Tsai; [0051]). Tsai further discloses that the user may download files of the policy group from the server (Tsai; [0065]).
As to the protected encrypted file including an encrypted portion and a security information portion, Tsai provides for this limitation because Tsai discloses that "the certificate 3141 records the encrypted data and the authorized information for the policy group data (ex. the access control list of the policy group)" (Tsai; [0052]). The encrypted data corresponds to the encrypted portion, and the authorized information/access control list corresponds to security information used to control access to the protected file.
As to decrypting the encrypted portion to generate the unencrypted content using a data decryptor, Tsai provides for this limitation because Tsai discloses that when access is allowed, "the file management driver 313 operatively drives the file decryption program 3132 to execute the file decryption procedure and decrypt the file" (Tsai; [0096]). Tsai further discloses that the file decryption program generates decrypted keys and decrypts the file according to decrypted keys (Tsai; [0098]). The disclosed file decryption program corresponds to the claimed data decryptor. Therefore, Tsai in view of Smalley provides for the limitations of claim 2.
Regarding claim 3, claim 3 depends from claim 2 and further recites "identifying the application creating modified unencrypted content from the unencrypted content," "generating a modified protected encrypted file by encrypting the modified unencrypted content using the security information metadata," and "providing the modified protected encrypted file to an external client device." As discussed above with respect to claims 1 and 2, Tsai in view of Smalley provides for the limitations of claims 1 and 2.
As to identifying the application crating modified unencrypted content from the unencrypted content, Tsai provides for this limitation because Tsai discloses that the file management driver detects a request from a file access application to execute a file open procedure (Tsai; claim 1). Tsai further discloses that after decryption "the file access application opens the file and enables the user of the client device 31 to execute the file editing operations, such as file-browsing, file modification, and the like" (Tsai; [0099]).
As to generating a modified protected encrypted file by encrypting the modified unencrypted content using the security information metadata, Tsai provides for this limitation because Tsai discloses that when the user instructs the file access application to close the file, "the file management driver 313 can control the file encryption program 3131 to encrypt the file according to the certificate 3141" (Tsai; [0054]). Tsai further discloses generating encryption keys and encrypting the file with encryption data (Tsai; [0090] - [0092]). The certificate includes the authorized information/access control list associated with the file protection policy (Tsai; [0052]).
As for providing the modified protected encrypted file to an external client device, Tsai provides for this limitation because Tsai discloses that the file management driver determines whether to transmit the encrypted file to the server and may execute the transmission step (Tsai; [0093] - [0095]). Tsai also discloses that users may download files of the policy group from the server (Tsai; [0065]). This provides for transmitting the modified protected encrypted file outside the client device for access by another client device. Therefore, Tsai in view of Smalley provides for the limitations of claim 3.
Regarding claim 4, claim 4 depends from claim 3 and further recites that determining to grant limited access includes "receiving, in the file access request, a user identifier associated with the file access request," "determining that the security information metadata includes the user identifier associated with the limited access," and "enforcing the application to adhere to the limited access with respect to the unencrypted content." As discussed above with respect to claims 1-3, Tsai in view of Smalley provides for the limitations of claims 1-3.
As to receiving, in the file access request, a user identifier associated with the file access request, Tsai provides for this limitation because Tsai discloses identity data including account data of the client and device identification data of the client device (Tsai; claim 1). Tsai further discloses that the policy group data records identity data such as account information and device identification data associated with the clients of the policy group (Tsai; [0038]). This account/identity information corresponds to the claimed user identifier.
As to determining that the security information metadata includes the user identifier associated with the limited access, Tsai provides for the access-control information because Tsai discloses that the policy group data records identity data and an access control list associated with files of the policy group (Tsai; [0038]). Tsai further discloses that the certificate records authorized information for the policy group data, such as the access control list (Tsai; [0052]). In view of Smalley's file security context and extended-attribute arrangement discussed above for claim 1, it would have been obvious to maintain the file-associated access-control/security information in the file security metadata used to protect the unencrypted file.
As to enforcing the application to adhere to the limited access with respect to the unencrypted content, Tsai provides for allowing or denying the file access application access to the file based on the certificate (Tsai; claim 1). Smalley further provides for enforcing permissions to the file because file_has_perm checks whether a task can use an open file descriptor to access a file in a given way and checks the requested file permissions using inode_has_perm (Smalley; Sections 14.2.1 and 15.2.1). Therefore, Tsai in view of Smalley provides for the limitations of claim 4.
Regarding claim 5, claim 5 depends from claim 1 and further recites that "generating the security information metadata occurs at a system-wide-level," "generating the security information metadata is application-agnostic," "binding the security information metadata occurs at the system-wide level," and "binding the security information metadata is application-agnostic." As discussed above with respect to claim 1, Tsai in view of Smalley provides for the limitations of claim 1.
Tsai provides for operating-system level file protection because Tsai discloses that "the file management driver 313 is installed in the kernel mode of the operating system for controlling the file-accessing procedure of any files in the operation system belonging to the policy group" (Tsai; [0050]). Tsai further discloses that operations or data flow associated with file addition, file editing, and file accessing in the operating system are intercepted by the file management driver (Tsai; [0030]). This provides for file protection performed at the operating-system level rather than within one particular application.
Smalley further provides for generating and binding file security information at the system/file level because Smalley discloses that, when a new file is created, selinux_inode_init_security obtains the security attribute to assign to the new inode, sets up the security structure, and generates the SELinux attribute name and security context value for storage as the file security attribute (Smalley; Sections 14.1.4). Smalley further discloses checking access to the file through the inode/file permission arrangement rather than through an application-specific protection mechanism (Smalley; Sections 14.2.1 and 15.2.1). Because the security attribute is assigned to the file at creation and file access is thereafter enforced through operating-system file permission checks, the generation and binding of the security information is performed at a system-wide level and is application-agnostic. Therefore, Tsai in view of Smalley provides for the limitations of claim 5.
Regarding claim 6, claim 6 depends from claim 1 and further recites, "in response to receiving an additional protected unencrypted file from an external client device, generating an additional protected unencrypted file having an additional unencrypted content that is bound with an additional security information metadata, wherein the additional unencrypted content remains unencrypted while location on the client device." As discussed above with respect to claim 1, Tsai in view of Smalley provides for the limitations of claim 1.
As to receiving an additional file from outside the client device, Tsai provides for receiving files from an external source because Tsai discloses that "the file stored in the first memory unit 314 are not limited to the files created or stored in the client device 31," and that the files may be stored in a cloud apparatus, mobile storage device, or other storage device (Tsai; [0051]). Tsai further discloses that a user may download files of the policy group from the server (Tsai; [0065]).
Tsai does not explicitly provide for the received file remaining as protected unencrypted content on the client device with additional security information metadata bound to that content. Smalley provides for this missing arrangement because, when a file is created, selinux_inode_init_security obtains the security attribute to assign to the new inode and generates the SELinux attribute name and security context value associated with the inode (Smalley; Sections 14.1.4). Smalley further discloses that file security contexts are stored using extended attributes and that permissions to the file are checked using the associated inode/file security information (Smalley; Sections 4, 5.3.1, 14.2.1, and 15.2.1).
Smalley does not disclose encrypting the file content. Thus, the additional file content protected by Smalley's security metadata and access-control arrangement remains unencrypted while located on the client device.
Accordingly, it would have been obvious to apply the SELinux protected-unencrypted-file arrangement to additional files received or stored on the client device, so that the received file remains unencrypted while access is controlled by file security metadata. Therefore, Tsai in view of Smalley provides for the limitations of claim 6.
Regarding claim 7, claim 7 depends from claim 6 and further recites "receiving a share request to provide the additional protected unencrypted file to an external computing device," "in response to receiving the share request, encoding the additional unencrypted content according to the additional security information metadata to create additional encrypted content," "associating the additional security information metadata with the additional encrypted content to create an additional protected encrypted file," and "providing the additional protected encrypted file to the external client device in response to the share request." As discussed above with respect to claims 1 and 6, Tsai in view Smalley provides for the limitations of claims 1 and 6.
As to receiving a share request, Tsai provides for this limitation because Tsai discloses that the file management driver determines whether to transmit the encrypted file to the server based on file accessing operations made by the user (Tsai; [0093]). Tsai further discloses that the determination may be made according to whether the server transmits an upload instruction to the client device, or according to settings of the file management driver or the user (Tsai; [0095). These user/server instructions correspond to a request to provide the file externally.
As to encoding the additional unencrypted content according to the additional security information metadata to create additional encrypted content, Tsai provides for this limitation because Tsai discloses that "the file management driver 313 can control the file encryption program 3131 to encrypt the file according to the certificate 3141" (Tsai; [0054]). Tsai further discloses that the certificate records authorized information for the policy group data, such as the access control list, and that the file encryption program generates encryption keys and encrypts the file with encryption data (Tsai; [0052], [0090]-[0092]).
As to associating the additional security information metadata with the additional encrypted content to create an additional protected encrypted file, Tsai provides for the certificate/access-control information associated with the file protection policy because Tsai discloses that the certificate records encrypted data and authorized information for the policy group data, such as the access control list (Tsai; [0052]). In view of Smalley's file security metadata arrangement discussed above for claim 6, it would have been obvious to preserve or associate the access-control/security information with the encrypted file so that the file protection policy remains associated with the file when provided externally.
As to providing the additional protected encrypted file to the external client device in response to the share request, Tsai provides for this limitation because Tsai discloses that the encrypted file may be transmitted to the server and stored there (Tsai; [0065], [0093]-[0095]). Tsai also discloses that users may download policy-group files from the server (Tsai; [0065]). This provides for the encrypted file being made available externally through the server. Therefore, Tsai in view of Smalley provides for the limitations of claim 7.
Regarding claim 8, claim 8 depends from claim 1 and further recites "blocking application access to an additional protected unencrypted file with additional unencrypted content on the client device based on determining that a user identifier associated with an additional file access request is not included in an additional security information metadata bound to additional protected unencrypted content within the additional protected unencrypted file." As discussed above with respect to claim 1, Tsai in view of Smalley provides for the limitations of claim 1.
As to blocking application access based on an unauthorized user identifier, Tsai provides for this limitation because Tsai discloses that when the server determines that the client does not belong to the policy group, the server does not transmit the certificate to the client device and the client device cannot access files associated with the policy group (Tsai; [0040]). Tsai further discloses that when the client does not belong to the policy group, the client device is not allowed to access the file because the client device does not have the certificate (Tsai; [0041]). Tsai also discloses that if the file management driver determines the file access application is not allowed to open the file, the file management driver prohibits the file access application from executing the file open procedure (Tsai; [0104]-[0106]).
As to the user identifier being absent from the additional security information metadata, Tsai provides for the relevant user/access-control information because Tsai discloses that policy group data records identity data of clients associated with the policy group (Tsai; [0038]). Thus, when the client identity is not included in or authorized by the policy group/access-control information, Tsai blocks access.
Smalley provides for the additional protected unencrypted file having bound security information metadata because Smalley discloses assigning a security attribute to a newly created inode and generating the SELinux attribute name and security context value associated with the inode (Smalley; Section 14.1.4). Smalley further discloses checking requested permissions to the file based on the associated inode/file security information (Smalley; Sections 14.2.1 and 15.2.1). Smalley does not disclose encrypting the file content, so the file is protected by security metadata while remaining unencrypted. Therefore, Tsai in view of Smalley provides for the limitations of claim 8.
Regarding claim 9, claim 9 depends from claim 1 and further recites "where the security information metadata includes system-level information hidden from a user interface of the client device." As discussed above with respect to claim 1, Tsai in view of Smalley provides for the limitations of claim 1.
Smalley provides for this additional limitation because Smalley discloses that SELinux uses security contexts and SIDs as security labels and that "kernel SIDs are not exported to userspace; the kernel only returns security contexts to userspace" (Smalley; Section 4). Smalley further discloses that the inode security structure stores the SID and security class associated with the file/inode (Smalley; Section 14.1.4). Because the SID/security information is maintained at the kernel/system level and the kernel SID is not exported to userspace, Smalley provides for security information metadata including system-level information hidden from the ordinary user interface. Therefore, Tsai in view of Smalley provides for the limitations of claim 9.
Regarding claim 10, claim 10 depends from claim 1 and further recites "wherein receiving the file access request includes intercepting a communication to access the protected unencrypted file between the application and an operating system of the client device." As discussed above with respect to claim 1, Tsai in view of Smalley provides for the limitations of claim 1.
Tsai provides for this additional limitation because Tsai discloses that input/output operations of an application at user mode pass through the system IO manager and filter manager of kernel mode, and that the file management driver can be installed in kernel mode and linked with the filter manager so that "any operation or data flow associate with file addition, file edition, and file accessing in the operation system of the client device are to be intercepted by the file management driver." (Tsai; [0030]). Tsai further discloses that "the file management driver 313 is installed in the kernel mode of the operating system for controlling the file-accessing procedure of any files in the operation system belonging to the policy group." (Tsai; [0050]). Therefore, Tsai in view of Smalley provides for the limitations of claim 10.
Regarding claim 11, claim 11 recites "a client device having a processor" and "a computer memory including instructions that, when executed by the client device, cause the client device to carry out operations." Tsai provides for this limitation because Tsai discloses a client device including a first processing unit, a first memory unit, and a file management driver executed by the first processing unit (Tsai; [0009], [0047]-[0051], claim 10). The first processing unit corresponds to the claimed processor, and the first memory unit storing executable software corresponds to the claimed computer memory including instructions.
Claim 11 further recites "identifying an encrypted portion and a security information portion from a protected encrypted file." Tsai provides for this limitation because Tsai discloses that "the certificate 3141 records the encrypted data and the authorized information for the policy group data (ex. the access control list of the policy group)" (Tsai; [0052]). The encrypted data corresponds to the encrypted portion, and the authorized information/access control list corresponds to the security information portion associated with protecting the file.
Claim 11 further recites "decrypting the encrypted portion of the protected encrypted file to generate unencrypted content." Tsai provides for this limitation because Tsai discloses that, when access is permitted, "the file management driver 313 operatively drives the file decryption program 3132 to execute the file decryption procedure and decrypt the file" (Tsai; [0096]). Tsai further discloses that the file decryption program obtains decryption keys and decrypts the file according to the decryption keys (Tsai; [0098]).
Claim 11 further recites "generating security information metadata based on the security information portion" and "binding the security information metadata to the unencrypted content to create a protected unencrypted file on the client device." Tsai provides for the security/access-control information because Tsai discloses that the certificate includes authorized information for the policy group data, such as the access control list (Tsai; [0052]). However, Tsai does not expressly provide for binding security information metadata to the resulting unencrypting content to create a protected unencrypted file on the client device.
Smalley provides for the missing protected-unencrypted-file arrangement. In particular, Smalley discloses that the selinux_inode_init_security hook function is called when creating a new file in order to obtain the security attribute to assign to the new inode and to set up the inode security structure for the new inode. Smalley further discloses that this operation allows new inodes to be labeled as part of the inode creation transaction and generates the SELinux attribute name and the security context value for the inode for storage as the file security attribute (Smalley; Section 14.1.4). Smalley also discloses that file security contexts are stored in each filesystem using extended attributes (Smalley; Sections 4 and 5.3.1). The SELinux security context/extended attribute corresponds to the claimed security information metadata because it is file-associated security information used to control permissions for the file.
Claim 11 further recites "maintaining the protected unencrypted file on the client device for authorized access by one or more applications on the client device." Tsai provides for maintaining locally accessible file content because Tsai discloses that, after decryption, the file access application opens the file and enables the user to perform file-browsing and file-modification operations (Tsai; [0099]). Smalley further provides for maintaining file protection during authorized application access because inode_has_perm checks whether a task has a requested permission to an inode, and file_has_perm checks whether a task can use an open file descriptor to access a file in a requested way (Smalley, Sections 14.2.1 and 15.2.1).
Smalley does not disclose encrypting the file content. Therefore, the file object protected by Smalley's security metadata and access-control arrangement is reasonably understood as unencrypted file content protected by security metadata.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify Tsai's client-device file protection system to include the SELinux file security context, extended attribute, and kernel access-control arrangement provided by Smalley, in order to enforce file access protections at the operating-system level for files whose content is not encrypted, thereby providing system-wide file access control across applications. Therefore, Tsai in view of Smalley provides for the limitations of claim 11.
Regarding claim 12, claim 12 depends from claim 11 and further recites "receiving the protected encrypted file with the encrypted portion and the security information portion from an external client device" and "decrypting the encrypted portion using a data decryptor." As discussed above with respect to claim 11, Tsai in view of Smalley provides for the limitations of claim 11.
As to receiving the protected encrypted file from an external client device, Tsai provides for receiving the file from outside the client device because Tsai discloses that the files stored in the first memory unit are not limited to files created or stored in the client device (Tsai; [0051]). Tsai further discloses that the user of the client device may download files of the policy group from the server (Tsai; [0065]).
As to the protected encrypted file having an encrypted portion and a security information portion, Tsai provides for this limitation because Tsai discloses that the certificate records encrypted data and authorized information for the policy group data, such as an access control list (Tsai; [0052]). The encrypted data corresponds to the encrypted portion, and the authorized information/access control list corresponds to security information associated with the protected file.
As to decrypting the encrypted portion using a data decryptor, Tsai provides for this limitation because Tsai discloses that the file management driver drives the file decryption program to execute a file decryption procedure and decrypt the file (Tsai; [0096]-[0098]). The disclosed file decryption program corresponds to the claimed data decryptor. Therefore, Tsai in view of Smalley provides for the limitations of claim 12.
Regarding claim 13, claim 13 depends from claim 11 and further recites "receiving a file access request on the client device from an application requesting access to the protected unencrypted file," "determining, based on the security information metadata, to grant limited access to the unencrypted content," and "authorizing the application requesting file access with the limited access to the unencrypted content based on determining to grant the limited access to the unencrypted content." As discussed above with respect to claim 11, Tsai in view of Smalley provides for the limitations of claim 11.
As to receiving a file access request from an application requesting access to the protected unencrypted file, Tsai provides for this limitation because Tsai discloses that when the file management driver detects a request from a file access application for executing a file open procedure and opening the file, the file management driver determines whether to allow the file access application to execute the file open procedure and access the file based on the certificate received (Tsai; claim 1). Tsai further discloses that the file management driver determines whether the client device has authority for opening the file of the policy group (Tsai; [0081]).
As to determining, based on the security information metadata, to grant limited access to the unencrypted content, Tsai provides for determining access based on security/access information because Tsai discloses that the certificate records authorized information for the policy group data, such as the access control list, and that the file management driver determines whether the client device has authority to open the file according to the certificate (Tsai; [0052], [0081]). Smalley further provides for determining access based on file-associated security information because inode_has_perm checks whether a task has a requested permission to an inode by calling the access vector cache to check the requested permission to the inode (Smally; Section 14.2.1).
As to authorizing the application requesting file access with limited access to the unencrypted content, Tsai provides for allowing the file access application to access the file based on the certificate (Tsai; claim 1). Smalley further provides for enforcing limited access because file_has_perm checks whether a task can use an open file descriptor to access a file in a requested way and then checks the requested file permissions through inode_has_perm (Smalley, Section 15.2.1). Smalley also discloses that file access permissions may be separately controlled for operations including read and write (Smalley; Sections 14.2.6, 14.2.8, and 15.2.2). Therefore, Tsai in view of Smalley provides for the limitations of claim 13.
Regarding claim 14, claim 14 depends from claim 13 and further recites "wherein the security information metadata is enforced across multiple applications on the client device accessing the unencrypted content." As discussed above with respect to claims 11 and 13, Tsai in view of Smalley provides for the limitations of claims 11 and 13.
Tsai provides for operating-system-level enforcement applicable to applications on the client device because Tsai discloses that "the file management driver 313 is installed in the kernel mode of the operating system for controlling the file-accessing procedure of any files in the operation system belonging to the policy group" (Tsai; [0050]). Tsai further discloses that file-accessing operations instructed by the user may be managed and controlled by the file management driver (Tsai; [0053]). This provides for enforcing file access control outside of only one particular application.
Smalley further provides for enforcing the security information associated with the file across applications because Smaley discloses that file_has_perm checks whether a task can use an open file descriptor to access a file in a given way and that inode_has_perm checks the requested permission to the inode (Smalley; Sections 14.2.1 and 15.2.1). Because these file/inode permission checks apply at the operating-system-file-access level, the security information associated with the unencrypted file is enforced when applications attempt to access the file. Therefore, Tsai in view of Smalley provides for the limitations of claim 14.
Regarding claim 15, claim 15 depends from claim 13 and further recites "receiving an additional protected encrypted file from an external device," "creating an additional protected unencrypted file from the additional protected encrypted file, wherein the additional protected unencrypted file includes additional unencrypted content and additional security information," "authorizing limited access to the additional unencrypted content being met," and "re-encrypting the additional protected unencrypted file with the additional security information metadata." As discussed above with respect to claims 11 and 13, Tsai in view of Smalley provides for the limitations of claims 11 and 13.
As to receiving an additional protected encrypted file from an external device, Tsai provides for this limitation because Tsai discloses that files stored in the first memory unit are not limited to files created or stored in the client device and may be stored in a cloud apparatus, mobile storage device, or other storage device (Tsai; [0051]). Tsai further discloses that the user may download files of the policy group from the server (Tsai; [0065]).
As to creating an additional protected unencrypted file from the additional protected encrypted file, Tsai provides for generating the additional unencrypted content because Tsai discloses that the file management driver drives the file decryption program to execute the file decryption procedure and decrypt the file (Tsai; [0096]-[0098]). However, Tsai does not expressly provide for the resulting unencrypted file being protected through additional security information metadata bound to the additional unencrypted content.
Smalley provides for the missing protected-unencrypted-file arrangement because Smalley discloses that, when a new file is created, selinux_inode_init_security obtains the security attribute to assign to the new inode, sets up the inode security structure, and generates the SELinux attribute name and security context value for the inode for storage as the file security attribute (Smalley; Section 14.1.4). Smalley further discloses that file security contexts are stored using extended attributes (Smalley; Sections 4 and 5.3.1). Thus, Smalley provides for additional security information being associated with the resulting file.
Smalley does not disclose encrypting the file content. Therefore, the additional file context protected by Smalley's security metadata and access-control arrangement is reasonably understood as additional unencrypted content protected by additional security information.
As to authorizing limited access to the additional unencrypted content based on additional security information metadata bound to the additional unencrypted content being met, Tsai provides for determining whether access is allowed based on certificate/access-control information (Tsai; claim 1, [0052], [0081]). Smalley further provides for checking requested access to the labeled file through inode_has_perm and file_has_perm (Smalley; Sections 14.2.1 and 15.2.1).
As to re-encrypting the additional protected unencrypted file with the additional security information metadata, Tsai provides for re-encryption according to the security/access-control information because Tsai discloses that when the user instructs the file access application to close the file, "the file management driver 313 can control the file encryption program 3131 to encrypt the file according to the certificate 3141" (Tsai; [0054]). Tsai further discloses generating encryption keys and encrypting the file with encryption data (Tsai; [0090]-[0092]). The certificate includes authorized information for the policy group data, such as the access control list (Tsai; [0052]). Therefore, Tsai in view of Smalley provides for the limitations of claim 15.
Regarding claim 16, claim 16 recites "a non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, cause a computer device to carry out operations." Tsai provides for this limitation because Tsai discloses "a computer-readable recording medium, which stores a computer executable program" for executing the file protection method (Tsai; [0010]). Tsai further discloses that the computer-readable recording medium stores program code for executing the file protection method, file encryption method, file decryption method, offline working procedure, and policy group setting method (Tsai; [0112]; claim 14).
Claim 16 further recites "maintaining, on a client device, a protected unencrypted file having security information metadata bound to unencrypted content." Tsai provides for a client-device file protection arrangement and access-control information because Tsai discloses the file management driver, certificate, and authorized information for the policy group data, such as the access control list (Tsai; [0047]-[0052]). However, Tsai does not expressly provide for maintaining a protected unencrypted file having security information metadata bound to the unencrypted content.
Smalley provides for the missing protected-unencrypted-file arrangement because Smalley discloses that selinux_inode_init_security is called when creating a new file to obtain the security attribute to assign to the new inode and to set up the inode security structure for the new inode. Smalley further discloses that the new inode is labeled as part of the file creation transaction and that the function generates the SELinux attribute name and security context value for storage as the file security attribute (Smalley; Section 14.1.4). Smalley also discloses that file security contexts are stored in each filesystem using extended attributes (Smalley; Sections 4 and 5.3.1). The SELinux security context/extended attribute corresponds to the claimed security information metadata because it is security information associated with the file and used to control file permissions.
Smalley does not disclose encrypting the file content. Therefore, the file object protected by Smalley's security metadata and access-control arrangement is reasonably understood as unencrypted file content protected by security metadata.
Claim 16 further recites "receiving a file access request on the client device from an application requesting access to the protected unencrypted file." Tsai provides for this limitation because Tsai discloses that when the file management driver detects a request from a file access application for executing a file open procedure and opening the file, the file management driver determines whether to allow the file access application to execute the file open procedure and access the file based on the certificate received (Tsai; claim 1). Tsai further discloses that the file management driver is installed in kernel mode of the operating system for controlling the file-accessing procedure of files in the operating system belonging to the policy group (Tsai; [0050]).
Claim 16 further recites "determining, based on the security information metadata, to grant limited access to the unencrypted content" and "authorizing the application requesting file access with the limited access to the unencrypted content based on determining to grant the limited access to the unencrypted content." Tsai provides for determining and allowing access based on security/access information because Tsai discloses that the certificate records authorized information for the policy group data, such as an access control list, and that the file management driver determines whether the file access application may access the file based on the certificate (Tsai; claim 1, [0052], [0081]). Smalley further provides for enforcing limited access based on file-associated security information because inode_has_perm checks a requested permission to an inode, and file_has_perm checks whether a task can use an open file descriptor to access a file in a given way and checks the requested file permissions through inode_has_perm (Smalley; Sections 14.2.1 and 15.2.1).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify Tsai's computer-readable-medium file protection implementation to include the SELinux file security context, extended attribute, and kernel access-control arrangement provided by Smalley, in order to enforce file access protections at the operating system level for files whose content is not encrypted, thereby providing system-wide file access control across applications. Therefore, Tsai in view of Smalley provides for the limitations of claim 16.
Regarding claim 17, claim 17 depends from claim 16 and further recites "receiving a protected encrypted file that includes an encrypted portion and a security information portion," "decrypting encrypted content from the encrypted portion using a data decryptor to generate the unencrypted content," "generating the security information metadata based on copying the security information portion to the security information metadata," and "binding the security information metadata to the unencrypted content to create the protected unencrypted file on the client device." As discussed above with respect to claim 16, Tsai in view of Smalley provides for the limitations of claim 16.
As to receiving a protected encrypted file that includes an encrypted portion and a security information portion, Tsai provides for this limitation because Tsai discloses that files may be downloaded from the server and stored on the client device (Tsai; [0051], [0065]). Tsai further discloses that "the certificate 3141 records the encrypted data and the authorized information for the policy group data (ex. the access control list of the policy group)." (Tsai; [0052]). The encrypted data corresponds to the claimed encrypted portion, and the authorized information/access control list corresponds to security information associated with protecting the file.
As to decrypting encrypted content from the encrypted portion using a data decryptor to generate the unencrypted content, Tsai provides for this limitation because Tsai discloses that the file management driver drives the file decryption program to execute the file decryption procedure and decrypt the file (Tsai; [0096]-[0098]). The disclosed file decryption program corresponds to the claimed data decryptor.
As to generating the security information metadata based on copying the security information portion to the security information metadata, Tsai provides for the underlying security/access-control information because Tsai discloses that the certificate records authorized information for the policy group data, such as the access control list (Tsai; [0052]). Tsai further discloses that the certificate is received from the server and stored on the client device, and that modified certificate information may be transmitted to the client device to update the stored certificate (Tsai; [0080], [0111]). Smalley provides for storing file-associated security metadata because Smalley discloses that file security contexts are maintained as security attributes associated with files.
In view of these disclosures, it would have been obvious to preserve the security/access-control information associated with Tsai's protected encrypted file in the security metadata arrangement applied to the resulting unencrypted file, so that the access-control information used to protect the encrypted file continues to govern access to the decrypted file on the client device.
As to binding the security information metadata to the unencrypted content to create the protected unencrypted file on the client device, Smalley provides for this limitation because Smalley discloses that the selinux_inode_init_security hook function is called when creating a new file in order to obtain the security attribute to assign the new inode and to set up the inode security structure for the new inode. Smalley further discloses that this operation allows a new inode to be labeled as part of the inode creation transaction and generates the SELinux attribute name and security context value for storage as the file security attribute (Smalley; Section 14.1.4). Smalley also discloses that file security contexts are stored in each filesystem using extended attributes (Smalley; Sections 4 and 5.3.1).
Smalley does not disclose encrypting the file content. Therefore, the file object protected by Smalley's security metadata and access-control arrangement is reasonably understood as unencrypted file content protected by security metadata. Therefore, Tsai in view of Smalley provides for the limitations of claim 17.
Regarding claim 18, claim 18 depends from claim 17 and further recites that "the protected encrypted file corresponds to file protections associated with a first identifier," "the security information metadata preserves the file protections associated with the first identifier," and "a subsequent re-encryption of the unencrypted content is based on the file protections associated with the first identifier." As discussed above with respect to claims 16 and 17, Tsai in view of Smalley provides for the limitations of claim 16 and 17.
As to the protected encrypted file corresponding to file protections associated with a first identifier, Tsai provides for this limitation because Tsai discloses that the policy group data records identity data of clients associated with the policy group, including account information and device identification data, and an access control list associated with files of the policy group (Tsai; [0038], [0056]). Tsai further discloses that the certificate records authorized information for the policy group data, such as the access control list (Tsai; [0052]). The identity data associated with the client/policy group corresponds to the claimed first identifier, and the certificate/access-control-list information corresponds to file protections associated with that first identifier.
As to the security information preserving the file protections associated with the first identifier, Tsai provides for the access-control/security information associated with the protected file through the certificate and access control list (Tsai; [0052], [0056]). Smalley provides for storing file-associated security informationas a file security attribute because Smalley discloses labeling a new inode with a security context during file creation and storing file security contexts using extended attributes (Smalley; Sections 14.1.4, 4, and 5.3.1). Thus, the combination provides for maintaining the file protection information associated with the identifier in security metadata associated with the resulting protected unencrypted file.
As to subsequent re-encryption of the unencrypted content being based on the file protections associated with the first identifier, Tsai provides for this limitation because Tsai discloses that when the user instructs the file access application to close the file, "the file management driver 313 can control the file encryption program 3131 to encrypt the file according to the certificate 3141" (Tsai; [0054]). Tsai further discloses that the certificate records authorized information for the policy group data, such as the access control list, and that the file encryption program generates encryption keys and encrypts the file with encryption data (Tsai; [0052], [0090]-[0092]). Accordingly, Tsai's re-encryption is performed according to the certificate containing the file protection information associated with the client/policy group identifier. Therefore, Tsai in view of Smalley provides for the limitations of claim 18.
Regarding claim 19, claim 19 depends from claim 17 and further recites "wherein multiple applications on the client device access the unencrypted content according to the limited access indicated by the security information metadata bound to the unencrypted content." As discussed above with respect to claims 16 and 17, Tsai in view of Smalley provides for the limitations of claims 16 and 17.
Tsai provides for controlling application access to file content at the client device because Tsai discloses that "the file management driver 313 is installed in the kernel mode of the operating system for controlling the file-accessing procedure of any files in the operation system belonging to the policy group" (Tsai; [0050]). Tsai further discloses that "any file accessing operation" instructed by the user through the client device may be managed and controlled by the file management driver and that the file access application may perform file-browsing, file modification, copying, and pasting after access is permitted (Tsai; [0053]). Because the file management driver controls file-accessing operations in the operating system rather than only inside one particular application, Tsai provides for access control applicable to multiple applications on the client device.
Smalley provides for the security information metadata bound to the unencrypted content because Smalley discloses that, when creating a new file, selinux_inode_init_security obtains the security attribute to assign to the new inode, sets up the inode security structure, and generates the SELinux attribute name and security context value associated with the inode for storage as the file security attribute (Smalley; Section 14.1.4). Smalley further discloses that file security contexts are stored using extended attributes (Smalley; Sections 4 and 5.3.1).
Smalley further provides for access according to limited permissions indicated by the bound security information because Smalley discloses that inode_has_perm checks whether a task has a requested permission to an inode and file_has_perm checks whether a task can use an open file descriptor to access a file in a given way and then checks the requested permissions to the file using inode_has_perm (Smalley; Sections 14.2.1 and 15.2.1). Smalley also discloses separate permission checks for operations including read, write, getattr, and setattr (Smalley; Sections 14.2.6 and 14.2.8).
Smalley does not disclose encrypting the file content. Therefore, the file content accessed according to the file security metadata is reasonably understood as unencrypted content protected by the bound security metadata. Therefore, Tsai in view of Smalley provides for the limitations of claim 19.
Regarding claim 20, claim 20 depends from claim 16 and further recites that "the security information metadata includes user identifier access information, access type restrictions, and information sensitivity levels" and that "the limited access includes viewing rights, editing rights, copying rights, or printing rights." As discussed above with respect to claim 16, Tsai in view of Smalley provides for the limitations of claim 16.
As to the security information metadata including user identifier access information, Tsai provides for this limitation because Tsai discloses that policy group data records identity data of clients associated with the policy group, including account information and device identification data, and an access control list associated with files of the policy group (Tsai; [0038], [0056]). Tsai further discloses that the certificate records authorized information for the policy group data, such as the access control list (Tsai; [0052]). This provides for security/access information associated with a client or user identifier.
As to the security information metadata including access type restrictions, Smalley provides for this limitation because Smalley discloses that file permissions are checked based on file security labels, including permissions for operations such as read, write, getattr, and setattr (Smalley; Sections 14.2.1, 14.2.6, 14.2.8, and 15.2.1). These permissions correspond to restrictions on the type of access that is permitted for the file content.
As to the security information metadata including information sensitivity levels, Smalley provides for this limitation because Smalley discloses that the example SELinux security server may implement Role-Based Access Control, Type Enforcement, and optionally Multi-Level Security (MLS) (Smalley; Section 6). Multi-Level Security provides for security policy levels based on the sensitivity of information.
As to the limited access including viewing rights, editing rights, copying rights, or printing rights, Tsai provides for this limitation because Tsai discloses that, after access is permitted, the file access application enables the user to perform file editing operations including "file-browsing, file modification, copying, pasting, and the like" (Tsai; [0053]). File-browsing corresponds to viewing rights, file modification corresponds to editing rights, and copying corresponds to copying rights. Because claim 20 recites viewing rights, editing rights, copying rights, or printing rights in the alternative, Tsai is not required to separately disclose printing rights. Therefore, Tsai in view of Smalley provides for the limitations of claim 20.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZAIN J AHMED whose telephone number is (571)270-0251. The examiner can normally be reached 8am - 4pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/ZAIN JIM AHMED/Examiner, Art Unit 2432
Prosecution Insights