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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/25/2025 has been entered.
Response to Amendment
In the response filed on 12/11/2025. The applicant amended claims 1,10, and 11 are amended. No claims were added.
Response to Arguments
With respect to 135 U.S.C. §103 rejections:
Applicant's arguments filed on 12/11/2025 have been received and entered. Applicant's arguments with respect to the newly amended independents “Claim Rejections - 35 USC § 103” remarks pages 8-11, have been considered but are moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new 103 ground of rejection relies on new references in combination as presented below.
Claim Objections
Regarding claims 1, 10, and 11, Claims 1, 14 and 20 are objected to because of the following informalities: “each of at least one file” and “each of the at least one file” should read “each file” or “each file of at least one file ” and “each file of the at least one file” for the clarity purposes. Appropriate correction is required.
Regarding claim 6, Claim 3 is objected to because of the following informalities: In line 2, “at least one file is at least one first file” and “at least one second file is deployed” is unclear because it doesn’t properly introduce “a first file” as distinct element and creates ambiguity as to whether it refers to the previously recited “at least one file” or different file. Further, the introduction of “at least one second file” does not clearly define its relationship to previously recited file, making the scope of claim unclear. Appropriate correction is required.
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 1, 10, and 11 recite the limitation "wherein the deactivation rule associated with each file is a series of instructions that defines a time period with respect to the file after which the file expires” and further recites that “each deactivation rule is periodically updated with respect to the associated file of the deactivation rule while the associated file is deployed in the folder”. The scope of this limitation is unclear. Although the claim characterizes the deactivation rule as “series of instructions”. The claim does not define what distinguishes such series of instruction from merely a stored time parameter or expiration value, it is unclear that whether the “series of instructions’ is executable code, a set of configuration parameters, a timer value, a script, a policy entry, or some other form of logic. Thus, the claim does not provide objective boundaries for what qualifies as the required “series of instructions”. However, earlier in the claim, the deactivation rule is described as defining “ a time period…after which the file expires”. It is unclear whether the periodic updating modifies only the time period value, or the logical steps of the instruction sequence, or completely replaces the entire instruction sequence with a different one or, it simply means recalculating a time counter without altering any instruction structure. The claim does not specify what aspect of “series of instructions” is changed nor how the updating differs from merely adjusting a time duration parameter. Claim 1 also recites limitation “associating, by the computerized digital rights manager, a deactivation rule to each of at least one file deployed in the folder” and further recites “ wherein the unique identifier is periodically updated while each of the at least one file is stored in the folder” . The claim uses different terms (“deployed” vs “stored”) to describe the state of the file without clarifying whether these terms are synonymous or are conditions. Because the claim ties different functional requirement to different file states such as associating the deactivation rule to files deployed vs updating of identifiers while files are stored in the folder. Examiner suggest applicant to clarify the scope of the claims. Dependent claims 3-9 are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
Claims 1, 10, and 11 further recite the limitation “the security policy is enforced on the at least one file based on the respective unique identifier associated with each of the at least one file”. It is unclear how enforcement is based on the UID (identifier), because it can be interpreted multiple ways such as UID is used as index to look up the file and then apply policy, UID itself is a credential/token for access, or policy enforcement changes whenever UID changes. The specification suggest UID is used to identify the file and facilitate tracking /policy application, [0040] and metadata extraction, [00042]. Examiner suggest applicant to clarify the scope of the claims.
Claim 3 recites “receiving an electronic indication with respect to a first file of the at least one file that was triggered by an entity, wherein the electronic indication includes at least the unique identifier of the first file”. As written , the claim requires that the “first file” is triggered by receiving an electronic indication, which makes the scope unclear because a file cannot reasonably be “triggered” by the act of indication. The claim language fails to clarify what constitutes “triggering” of the file and the relationship between triggering event, the electronic indication, and the receiving the electronic indication. Secondly, the claim also refers the file being triggered “by an entity” but does not clearly define what action performed by the entity constitutes the triggering event. The claim further fails to specify whether electronic indication is triggering condition itself, a report generated in response to a triggering event performed by the entity. Examiner suggest applicant to clarify the scope of the claims. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 3-11, 13-19 are rejected under 35 U.S.C. 103 as being unpatentable over Panchapakesan (US 20170124342 A1) in view of Parkison (US 20150370827 A1) and in further view of Baskaran (US 20100146269 A1).
Regarding claim 1, Panchapakesan teaches a method for securing computerized environments using digital rights management, comprising:
applying, by a computerized digital rights manager, a security policy to a folder in a computerized environment such that the security policy is enforced on each file of the folder (Panchapakesan, The present disclosure relates to storing and retrieving files that are protected by information rights management (IRM) or digital rights management (DRM) technologies using data storage systems that are accessible to client devices over a network. In the context of this disclosure, although the term IRM is predominantly used, alternative rights management technologies, such as DRM technologies, can also be employed in the place of IRM technologies, [0012] A management service 119 manages a file management service 126 (i.e., a computerized digital rights manager) executed in the computing environment 103, [0019] The file management service 126 determine whether an IRM policy should be applied to a particular file when the file is downloaded by a user to a client device 106 or shared with another user. The file management service 126 determine which type of IRM policy should be applied in these scenarios, [0021] the content policy 137 is applied to certain folders or directories within a storage area associated with a user, [0024] The content policy 137 specifies that the file management service 126 or file management application 139 to apply a particular IRM policy to files that are stored in a third-party repository, [0025]) [Examiner interprets that applying content policy to explicitly certain folders or directories with in a storage area or third party repositories as applying, by a computerized digital rights manager, a security policy to a folder in a computerized environment such that the security policy is enforced on each file of the folder];
associating, by the computerized digital rights manager, a deactivation rule to each of at least one file deployed in the folder based on the security policy, wherein the deactivation rule associated with each file defines a time period with respect to the file after which the file expires (Panchapakesan, The file management service 126 (i.e. computerized digital rights manager) obtains and stores various information regarding files that are associated with one or more client devices 106 or the management service 119. The file management service 126 creates and maintain an activity log associated with a particular file. The activity log associated with a particular file specifies …… permissions (e.g., access rights) associated with the file…. For example, an activity log associated with a board meeting document can specify that the document: …..(2) was shared with the four board member users on October 26.sup.th; (3) was downloaded by the four board member users on October 27.sup.th at 1 PM, was stored on the four board member users' devices from 1 PM to 2 PM, and was removed from the four board member users' devices at 2 PM, [0020]) [Examiner interprets that making board meeting document accessible only between 1 PM and 2 PM and then removing at 2 PM so that the file is gone or unusable after that time as associating, by the computerized digital rights manager, a deactivation rule to each of at least one file deployed in the folder based on the security policy, wherein the deactivation rule associated with each file defines a time period with respect to the file after which the file expires]; and
associating, by the computerized digital rights manager, each of the at least one file with a unique identifier, wherein the security policy is enforced on the at least one file based on the respective unique identifier associated with each of the at least one file (Panchapakesan, file data 129 can store a reference to the file 136 stored in the third party repository along with a content policy 137 that is associated with the file 136, [0023] file data 129 can include a unique identifier, the location, an encryption key, permissions, the file version, access history, or other information for a particular file 136, [0024] A particular IRM layer is applied to a file so that access to the contents of the file using a particular viewer application is restricted until the user authenticates with the information rights server 109 using a username, password, or other form of credential, [0038] an information rights server 109 associated with a particular IRM technology can assign a globally unique identifier (GUID) to a file 136 or local file 155 that is protected using an IRM policy associated with the information rights server 109, The file management service 126 obtains the GUID associated with a particular file 136 or local file 155 and also obtain usage data with respect to the file 136 or local file 155. [0054]) [Examiner interprets that assigning unique identifier or GUID to each file and server deciding whether to allow or deny the access to the file or access the usage data of the file by recolonizing file’s GUID (i.e., identified by unique id) as associating, by the computerized digital rights manager, each of the at least one file with a unique identifier, wherein the security policy is enforced on the at least one file based on the respective unique identifier associated with each of the at least one file].
Panchapakesan does not explicitly teach:
wherein the deactivation rule associated with each file is a series of instructions that defines a time period with respect to the file after which the file expires, wherein each deactivation rule is periodically updated with respect to the associated file of the deactivation rule while the associated file is deployed in the folder, wherein updating each deactivation rule includes updating the series of instructions of the deactivation rule; the unique identifier is periodically updated while each of the at least one file is stored in the folder
However, Parkison teaches:
the unique identifier is periodically updated while each of the at least one file is stored in the folder (Parkison, cloud controllers track version information for each file in the distributed filesystem. Each cloud controller updates the tracked version information for a file whenever the cloud controller either updates the metadata for the file in response to a client write or receives a metadata update for the file from another cloud controller, [0007] cloud controllers send a version identifier for the most recent version of the file that they are currently aware of when sending a synchronization update request. The cloud controller receiving the request can use this version identifier to determine whether the file has been modified more recently locally and thus determine whether the version of the file that is currently available on the requesting cloud controller is out-of-date, [0009] Sending frequent snapshots ensures that changes are quickly propagated to other cloud controllers and the cloud storage system, [0050] cloud controllers may maintain records of past snapshots to allow file accesses to be rolled back across multiple different versions, thereby allowing clients to view historical versions of files and/or the changes made to files over time, [0052] updates to most of the files in the distributed filesystem can be propagated via lazy update techniques; e.g., large, incremental metadata snapshots that are periodically propagated to all cloud controllers to indicate changed data that can now be accessed via the cloud storage system, [0106] the distributed filesystem metadata maintained for each file on each cloud controller includes version information that tracks how that file has changed over time (e.g., one or more of a timestamp, file size, version identifier, etc.). Cloud controllers track and update the version information for files over time as changes are received for each file, [0110] Because file Z.slog has been identified as an append-only file, cloud controller 1400 knows to include the old EOF 1412 for its out-of-date status log file 1410 in this synchronization update request. Upon receiving this request, cloud controller 1404 compares the enclosed old EOF 1412 with its updated local EOF 1418, [0155]) [Examiner interprets that system associating each file with version identifier that uniquely identifies the file’s current version, cloud controllers updating this version identifier whenever the file’s metadata is modified or updated, metadata snapshots are periodically propagating between cloud controllers, and file remaining stored in the distributed system while its metadata and version identifier are repeatedly updated overtime as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Panchapakesan to include a concept of the unique identifier is periodically updated while each of the at least one file is stored in the folder as taught by Parkison for the purpose of tracking version information for each file in the distributed filesystem when each cloud controller updates the tracked version information for a file either updates the metadata for the file in response to a client write or receives a metadata update for the file from another cloud controller, [Parkison:0007].
Panchapakesan and Parkison does not explicitly teach:
wherein the deactivation rule associated with each file is a series of instructions that defines a time period with respect to the file after which the file expires, wherein each deactivation rule is periodically updated with respect to the associated file of the deactivation rule while the associated file is deployed in the folder, wherein updating each deactivation rule includes updating the series of instructions of the deactivation rule
However, Baskaran teaches:
wherein the deactivation rule associated with each file is a series of instructions that defines a time period with respect to the file after which the file expires (Baskaran, The proprietary wrapper file is configured for enforcing content usage policies on the electronic content and for performing or invoking various configurable functionalities. The content usage policies, among other records, are assembled and stored within the wrapper file, for example, in the file header of the wrapper file. In addition to the content usage policies, the file header may include one or more encryption/decryption keys for multi-level encryption and decryption of the electronic content, a location identifier for addressing the online resource, for example, an IP address, a location identifier for addressing the policy server, the original MIME type of the content, etc. A default set of content usage policies are established by the originator of the electronic content, or an administrator of the policy server associated with online resources. Additionally, tailor made policies specific to a user or a group of users are established on the policy server by the administrator, [0030] The user is then granted 104 controlled access to the electronic content by enforcing the content usage policies by the security client application through the wrapper file. The activities of the user on the electronic content are monitored and tracked 105 by the security client application to ensure compliance of the activities with the enforced content usage policies, [0033], The wrapper file provides IRM aspects, time aspects, location aspects, and environment control aspects in managing the electronic content security. Access to the electronic content is controlled based on predefined IRM policies, DLP policies, distribution lists, and location and environment restrictions, [0035] The content usage policy may comprise a predefined list of actions or a subset of the actions permitted on the electronic content…[0040] the IRM policies are enforced in an application-neutral manner, such that the content usage policy is enforced irrespective of the native application launched for opening the decapsulated electronic content. The file header may also comprise header records that implement life cycle management, such that the wrapper file expires or locks itself based on usage time, making the electronic content encapsulated within the wrapper file inaccessible. For example, the wrapper file encapsulating the electronic content expires after a predetermined number of calendar days or after a predetermined number of attempts to access the electronic content, [0061]) [Examiner interprets that system using content usage policies as structured rule records that govern/permit/deny actions and control access/usage (i.e., series of instructions) and expiration rule (i.e., deactivation rule) defining a time period after which the file becomes inaccessible (expires/locks) as limitation above];
wherein each deactivation rule is periodically updated with respect to the associated file of the deactivation rule while the associated file is deployed in the folder (Baskaran, The file header of the wrapper file contains or is populated with multiple records, including different versions of the content usage policies associated with the electronic content, different revisions of the electronic content, etc. among other records. In an embodiment, the security client application may periodically query the policy server, using the location identifier stored in the header records, for updates or changes to the content usage policies associated with the stored electronic content. The wrapper file is then configured to apply the latest set of policies for content usage, [0044] When the content usage policy corresponding to the electronic content has to be updated, an administrator updates the content usage policy on the policy database 201a. The updated policy is periodically accessed by the security client application 205 and reflected in the file header of the wrapper file, [0051]) [Examiner interprets that system periodically querying for updates to the policies associated with stored electronic content as limitation above];
wherein updating each deactivation rule includes updating the series of instructions of the deactivation rule (Baskaran, The file header of the wrapper file contains or is populated with multiple records, including different versions of the content usage policies associated with the electronic content, different revisions of the electronic content, etc. among other records. In an embodiment, the security client application may periodically query the policy server, using the location identifier stored in the header records, for updates or changes to the content usage policies associated with the stored electronic content. The wrapper file is then configured to apply the latest set of policies for content usage….the wrapper file stores all the previous versions of the encryption key in the header records and can revert to the original encryption key at any time, [0044] The updated policy is periodically accessed by the security client application 205 and reflected in the file header of the wrapper file, [0051]) [Examiner interprets that system updating policy rule definitions/records (multiple versions, updated set, reflected in header) (i.e., series of instructions) that implement the deactivation/expiration behavior as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Panchapakesan and Parkison to include a concept of wherein the deactivation rule associated with each file is a series of instructions that defines a time period with respect to the file after which the file expires, wherein each deactivation rule is periodically updated with respect to the associated file of the deactivation rule while the associated file is deployed in the folder, wherein updating each deactivation rule includes updating the series of instructions of the deactivation rule as taught by Baskaran for the purpose of periodically querying the policy server, using the location identifier stored in the header records, for updates or changes to the content usage policies associated with the stored electronic content applying the latest set of policies for content usage, [Baskaran :0044].
Regarding claim 3, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 1, further comprising:
receiving an electronic indication with respect to a first file of the at least one file that was triggered by an entity, wherein the electronic indication includes at least the unique identifier of the first file (Panchapakesan, file management application 139 query the management component 143 to determine whether the client device 106 is violating one or more compliance rules before retrieving the credential from the configuration profile. If the client device 106 (i.e., an entity) is violating a compliance rule, the file management application 139 can indicate to the user that access to the local file 155 is restricted or not permitted due to the violation of compliance rules, [0047] The file management application 139 and file management service 126 logs activity with respect to a file 136 or local file 155…. For example, a particular IRM technology associated with an IRM policy applied to a file 136 or local file 155 cause a viewer application to report any attempts to open or access the contents of a protected file to an information rights server 109. The file management service 126 obtains log data associated with a particular protected file or log data associated with unauthorized activity associated with a file from the information rights server 109 and viewer applications reports unauthorized attempts to access or share a protected file, [0053] an information rights server 109 associated with a particular IRM technology can assign a globally unique identifier (GUID) to a file 136 or local file 155 that is protected using an IRM policy associated with the information rights server 109. A viewer application in which the file 136 or local file 155 is viewed can report usage data associated with the file 136 or local file 155 to the information rights server 109. The file management service 126 can obtain the GUID associated with a particular file 136 or local file 155 and also obtain usage data with respect to the file 136 or local file 155, For example, an administrator or other user can access activity or audit logs with respect to a file 136 or local file 155 which allow a user to view when and how often a particular file 136 or local file 155 was accessed as well as whether the file 136 or local file 155 was redistributed to other users, if the IRM technology associated with an applied IRM policy permits redistribution of the file 136 or local file 155, [0054]) [Examiner interprets that viewer application reporting to the administrator or user about the violation of client device trying to access to the local file 155 is restricted or not permitted or unauthorized file or protected file and file management service obtaining GUID associated with a particular file 136 or local file 155 to obtain those report on viewer application as receiving an electronic indication with respect to a first file of the at least one file that was triggered by an entity, wherein the electronic indication includes at least the unique identifier of the first file].
extracting metadata for the first file using the unique identifier of the first file, wherein the extracted metadata indicates at least one circumstance of triggering of the first file (Panchapakesan, an information rights server 109 associated with a particular IRM technology can assign a globally unique identifier (GUID) to a file 136 or local file 155 that is protected using an IRM policy associated with the information rights server 109. A viewer application in which the file 136 or local file 155 is viewed can report usage data (metadata) associated with the file 136 or local file 155 to the information rights server 109. The file management service 126 can obtain the GUID associated with a particular file 136 or local file 155 and also obtain usage data with respect to the file 136 or local file 155 (i.e. metadata circumstance of triggering of the first file), For example, an administrator or other user can access activity or audit logs with respect to a file 136 or local file 155 which allow a user to view when and how often a particular file 136 or local file 155 was accessed as well as whether the file 136 or local file 155 was redistributed to other users (i.e. metadata), if the IRM technology associated with an applied IRM policy permits redistribution of the file 136 or local file 155, [0054]) [Examiner interprets that administrator extracting file usage data using file GUID in the viewer application to see the violation or unauthorized activities to a particular file as extracting metadata for the first file using the unique identifier of the first file, wherein the extracted metadata indicates at least one circumstance of triggering of the first file].
generating an electronic alert which includes at least a portion of the metadata (Panchapakesan, A viewer application in which the file 136 or local file 155 is viewed can report usage data (metadata) associated with the file 136 or local file 155 to the information rights server 109. The file management service 126 can obtain the GUID associated with a particular file 136 or local file 155 and also obtain usage data with respect to the file 136 or local file 155 (i.e. metadata circumstance of triggering of the first file), For example, an administrator or other user can access activity or audit logs with respect to a file 136 or local file 155 which allow a user to view when and how often a particular file 136 or local file 155 was accessed as well as whether the file 136 or local file 155 was redistributed to other users (i.e. metadata), if the IRM technology associated with an applied IRM policy permits redistribution of the file 136 or local file 155, [0054]) [Examiner interprets that administrator extracting file usage data in the viewer application to see the violation or unauthorized activities to a particular file as generating an electronic alert which includes at least a portion of the metadata].
Regarding claim 4, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 3, further comprising: sending the electronic alert to at least one predetermined computing device, wherein the at least one predetermined computing device is configured to perform at least one mitigation action with respect to the triggered first file based on the electronic alert (Panchapakesan, the management component 143 transmits data that indicates the status of settings for the client device 106, and the management service 119 uses this data to determine whether the client device 106 is operating in accordance with compliance rules. If it is determined that the client device 106 is not in compliance with one or more compliance rules, …. remedial action to be performed such as notifying a user of the device or an administrator of the management service 119, causing device settings to be changed so that the client device 106 becomes compliant with the compliance rules, and wiping data in the client device 106, [0033] A viewer application in which the file 136 or local file 155 is viewed can report usage data associated with the file 136 or local file 155 to the information rights server 109. The file management service 126 can obtain the GUID associated with a particular file 136 or local file 155 and also obtain usage data with respect to the file 136 or local file 155. For example, an administrator or other user (i.e., predetermined computing device) can access activity or audit logs with respect to a file 136 or local file 155 which allow a user to view when and how often a particular file 136 or local file 155 was accessed as well as whether the file 136 or local file 155 was redistributed to other users, if the IRM technology associated with an applied IRM policy permits redistribution of the file 136 or local file 155, [0054]) [ Examiner interprets that notifying administrator file usage data in the viewer application to see if the violation or unauthorized activities to a particular file is committed and sending remedial actions such as changing device settings of the client device 106 to be compliant with the compliance rules, and wiping data in the client device 106 etc., as sending the electronic alert to at least one predetermined computing device, wherein the at least one predetermined computing device is configured to perform at least one mitigation action with respect to the triggered first file based on the electronic alert].
Regarding claim 5, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 3, wherein the electronic alert indicates the unique identifier of the first file (Panchapakesan, A viewer application in which the file 136 or local file 155 is viewed can report usage data associated with the file 136 or local file 155 to the information rights server 109. The file management service 126 can obtain the GUID associated with a particular file 136 or local file 155 and also obtain usage data with respect to the file 136 or local file 155. For example, an administrator or other user (i.e., predetermined computing device) can access activity or audit logs with respect to a file 136 or local file 155 which allow a user to view when and how often a particular file 136 or local file 155 was accessed as well as whether the file 136 or local file 155 was redistributed to other users, if the IRM technology associated with an applied IRM policy permits redistribution of the file 136 or local file 155, [0054]) [ Examiner interprets that notifying administrator file usage data in the viewer application to see if the violation or unauthorized activities to a particular file is committed using its GUID as the electronic alert indicates the unique identifier of the first file].
Regarding claim 6, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 1, wherein the at least one file is at least one first file, wherein at least one second file is deployed to the folder such that the security policy is enforced on the at least one second file (Panchapakesan, multiple default content policies 137 are established for different files 136 that are newly created depending upon a host of factors. For example, separate default content policies 137 are established depending upon a storage location of a file 136, such as whether the file 136 is stored in a data store 116 associated with the enterprise or a third-party data storage service. Another default content policy 137 can apply to particular folders within a user's storage area. Content policies 137 are also established for different file types, users or user groups within an enterprise or based upon a location of a client device 106 when a particular file 136 is created, [0043]) [ Examiner interprets that managing multiple files across various folders repo or locations by establishing different content policies as the at least one file is at least one first file, wherein at least one second file is deployed to the folder such that the security policy is enforced on the at least one second file].
Regarding claim 7, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 1, wherein the time period defined by the deactivation rule associated with each file is defined further with respect to a time since the file is triggered (Panchapakesan, The file management service 126 creates and maintain an activity log associated with a particular file (i.e., each file). The activity log associated with a particular file specifies …… permissions (e.g., access rights) associated with the file…. For example, an activity log associated with a board meeting document can specify that the document: …..(2) was shared with the four board member users on October 26.sup.th; (3) was downloaded by the four board member users on October 27.sup.th at 1 PM (i.e. the file is triggered), was stored on the four board member users' devices from 1 PM to 2 PM, and was removed from the four board member users' devices at 2 PM, [0020]) [Examiner interprets that making board meeting document accessible only between 1 PM and 2 PM and then removing at 2 PM so that the file is gone or unusable after that time as the time period defined by the deactivation rule associated with each file is defined further with respect to a time since the file is triggered];
Regarding claim 8, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 1, wherein the security policy is a set of rules indicating at least one of restrictions and permissions for each file stored in the folder (Panchapakesan, The file management application 139 or file management service 126 applies an IRM policy specified by the content policy 137 (i.e. security policy) when the file is accessed or shared using the file management application 139(i.e., access restrictions and permissions), [0023] a content policy 137 specifies that a file 136 can be shared with other users within an enterprise without an IRM policy applied to the file 136 as well as a file 136 or local file 155 can only be shared with other users with a particular IRM policy applied that requires a recipient of the file 136 or local file 155 to also have a user account with an IRM server 109 corresponding to the IRM policy that is specified by the content policy 137 (i.e., sharing restrictions and permissions), [0049]) [Examiner interprets that content policy specifying certain restrictions or permissions related to sharing, accessing particular file in the folder as the security policy is a set of rules indicating at least one of restrictions and permissions for each file stored in the folder].
Regarding claim 9, Panchapakesan, Parkison, and Baskaran further teaches the method of claim 1, wherein the unique identifier associated with each file is unique to the respective file (Panchapakesan, The content policy 137 identifies an IRM policy that should be applied to a file 136 before the file 136 is shared with another user. The file data 129 includes include a unique identifier, the location, an encryption key, permissions, the file version, access history, or other information for a particular file 136, [0024] an information rights server 109 associated with a particular IRM technology can assign a globally unique identifier (GUID) to a file 136 or local file 155 that is protected using an IRM policy associated with the information rights server 109, [0054]).
Regarding claim 10, Claim 10 recite commensurate subject matter as claim 1. Therefore, it is rejected for the same reasons. Except additional elements:
A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising (Panchapakesan, software or program instructions in any non-transitory computer-readable medium in connection with an instruction execution system such as a processor in a computer system or other system to store, or maintain the software or program instructions, [0080]);
Regarding claim 11, Claim 11 recite commensurate subject matter as claim 1. Therefore, it is rejected for the same reasons. Except additional elements:
A system for securing computerized environments using digital rights management, comprising (Panchapakesan, the system storing and retrieving files that are protected by information rights management (IRM) or digital rights management (DRM) technologies using data storage systems that are accessible to client devices over a network,[0012] The information rights server 109 can include, for example, a server computer or any other system providing computing capabilities, [0036]);
a processing circuitry (Panchapakesan, The file management service 126, file management application 139, and other components contains hardware, as software components that are executable by hardware, or as a combination of software and hardware. Hardware are implemented as a circuit or state machine that employs any suitable hardware technology such as one or more microprocessors, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, programmable logic devices (e.g., field-programmable gate array (FPGAs), and complex programmable logic devices (CPLDs), [0079]);
a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to (Panchapakesan, software or program instructions in any non-transitory computer-readable medium in connection with an instruction execution system such as a processor in a computer system or other system to store, or maintain the software or program instructions, [0080] The computer-readable medium include physical media, such as, magnetic, optical, semiconductor, solid-state drives, magnetic drives, flash memory, [0081]);
Regarding claims 13-19, Claims 13-19 recite commensurate subject matter as claim 3-9. Therefore, they are rejected for the same reasons
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Panchapakesan (US 20170124342 A1) in view of Parkison (US 20150370827 A1) and in further view of Baskaran (US 20100146269 A1) in further view of Wee (US 20190147064 A1).
Regarding claim 20, Panchapakesan, Parkison, and Baskaran teaches the method of claim 1, wherein the deactivation rule for each of the at least one first file is periodically updated (Baskaran, The activities performed by the user with the electronic content are tracked using the security client application. The activities are monitored against the content usage policy and may be recorded for future reference with detailed forensic information. The security client application creates or updates an activity log at predetermined intervals of time. The activity log is transferred to the logging database at regular intervals when the computing device is connected to the network. Tracking the activities may comprise capturing and recording user inputs, for example, mouse clicks and keyboard inputs, number of unsuccessful authentication attempts, editing operations on the electronic content, copy and paste operations on the electronic content, "save as" operations, print commands, etc. Electronic transfers of the electronic content, for example, by facsimile (fax) or electronic mail, may also be tracked or prohibited based on the content usage policy., [0042] The file header of the wrapper file contains or is populated with multiple records, including different versions of the content usage policies associated with the electronic content, different revisions of the electronic content, etc. among other records. In an embodiment, the security client application may periodically query the policy server, using the location identifier stored in the header records, for updates or changes to the content usage policies associated with the stored electronic content. The wrapper file is then configured to apply the latest set of policies for content usage, [0044] The updated policy is periodically accessed by the security client application 205 and reflected in the file header of the wrapper file., [0051]) [Examiner interprets that system periodically updating content usage policies (i.e., deactivation rule) as limitation above]
Although, Baskaran teaches periodically updating content usage policies (i.e., deactivation rule) which inherently occurs according to configured schedule,
Panchapakesan, Parkison, and Baskaran does not explicitly teach:
updating every predetermined period of time
Wee further teaches:
updating every predetermined period of time (Wee, object states can be determined for all objects in a given database. These object states and related metadata can be stored in data stores. Subsequently, these object states can be recomputed periodically (e.g., hourly, daily, etc.) for all objects in the database that were created, deleted, or modified and these recomputed states can be stored in the data stores, [0025] An object can, therefore, represent data that remains stored and accessible through a given data source 132. In one example, a data source may correspond to a text file (e.g., a CSV file) that includes rows of values separated by commas, [0030] the scheduling engine 206 can be configured to run at pre-defined time intervals (e.g., every 24 hours, every week, etc.). When run, the scheduling engine 206 can evaluate each of the objects being managed for compliance with any data retention configurations that are applicable to those objects, For example, a data retention configuration may indicate that objects having a specified property should be deleted (or scheduled for deletion) after a specified time. In this example, the scheduling engine 206 can identify objects that satisfy this criterion, [0039]) [Examiner interprets that system recomputing retention configuration or state (i.e., deactivation rule) for all objects (i.e., at least one first file) in the database hourly, every 24 hours etc. (i.e., predetermined period of time) as the deactivation rule for each of the at least one first file is periodically updated every predetermined period of time].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Panchapakesan, Parkison, and Baskaran to include a concept of updating every predetermined period of time as taught by Wee for the purpose of recomputing object states periodically (e.g., hourly, daily, etc.) for all objects in the database that were created, deleted, or modified and these recomputed states can be stored in the data stores, [Wee:0025].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20140304836 A1: “relates to networked secure content, and more particularly to networked secure content sharing, viewing, and collaboration on mobile devices”
US 20140032759 A1: “relate to mobile computing devices. More specifically, aspects described herein relate to techniques for imposing control over managed applications executing on mobile computing devices”
US 20170228412 A1: “relates to file systems for storing objects, and more specifically relates to a file system that uses certificates to identify and remove file system objects that have expired”
US 20140095641 A1: “ relates to retention policies provide a technique for controlling this scenario to assist users in managing email, such as retaining or deleting email as desired”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436